Disaster recovery and virtualisation

[Buxton]

@akbooer Tasmota energy sensor

{
  "Time": "2021-03-28T21:51:01",
  "ENERGY": {
    "TotalStartTime": "2020-06-07T00:10:43",
    "Total": 2356.063,
    "Yesterday": 7.056,
    "Today": 6.459,
    "Period": 24,
    "Power": 285,
    "ApparentPower": 302,
    "ReactivePower": 99,
    "Factor": 0.95,
    "Voltage": 123,
    "Current": 2.453
  }
}

[ArcherS]

And a Tasmota IR receiver that can also be used for HVACs.
IR remotes for HVACs are a bit special, they send/receive all data fields every time.

Received IR from a Logitech remote:
tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"0x10EF08F7","DataLSB":"0x08F710EF","Repeat":0}}

Received from a noname led-lights remote:
tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"LUTRON","Bits":3,"Data":"0x700000000","DataLSB":"0xE000000000","Repeat":0}}

The Tasmota IR receive/transmitter also supports HVAC remotes, this is an example of a received message from my Fujitsu remote:
tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x0x1463001010FE0930400400000000206C","Repeat":0,"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

I have not tested sending yet since my Mqtt is not fully up and running yet, but it should be something like this:
IRsend{"Protocol":"NEC","Bits":32,"Data":"0x10EF08F7","DataLSB":"0x08F710EF","Repeat":0}

and for IRHVAC:
IRHVAC{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

[therealdb]

@akbooer shelly 1 seems to be good, but I'm mostly using them as binary sensors (shelly 1 can detach the input from the button, so it's very handy ie for doorbell, PIR or similar, since it's 12v or 110/220).

It also discovered my shelly plug, but as a scene controller. Here's the info part:

{"wifi_sta":{"connected":true,"ssid":"XXX","ip":"192.168.1.46","rssi":-47},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"08:57","unixtime":1617001074,"serial":30,"has_update":false,"mac":"XXXX","cfg_changed_cnt":12,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"timer"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1617008274,"counters":[0.000, 0.000, 0.000],"total":0}],"temperature":31.77,"overtemperature":false,"tmp":{"tC":31.77,"tF":89.18, "is_valid":true},"update":{"status":"idle","has_update":false,"new_version":"20210323-105718/v1.10.1-gf276b51","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":38444,"fs_size":233681,"fs_free":166413,"uptime":222282}

It's a plug with KWH and internal temp sensor, for overheat protection.

[therealdb]

I will also probably just send an announce message upon start of the broker. This will enable automatical discover of new devices, with no user intervention.

[akbooer]

@therealdb said in MQTT – setup and use:

shelly 1 seems to be good, but I'm mostly using them as binary sensors (shelly 1 has the ability to detach the input from the button

Yes, I think all their switches can do that. I’ll add the appropriate logic to give each child device the scene controller variables.

[akbooer]

I think we need a separate Tasmota thread, or this will get confusing.

@therealdb for the Shelly input devices I see:

  for switch in "momentary" mode: 
  input_event/n = {"event":"S","event_cnt":11}
		S = shortpush 	
		L = longpush 	
		SS = double shortpush 	
		SSS = triple shortpush 	
		SL = shortpush + longpush 	
		LS = longpush + shortpush 	

and this can be for multiple inputs (eg. ix3 has three.)

So we need to agree on how to map these to scene numbers. Perhaps the easiest thing is to repesent each one by increments of 10.

For example:

    scene_no = {
		S = 10,  -- shortpush 	
		L = 20,  -- longpush 	
		SS = 30, -- double shortpush 	
		SSS = 40,  -- triple shortpush 	
		SL = 50, -- shortpush + longpush 	
		LS = 60, --longpush + shortpush 
    }	

so a short push on button 0 would be 10, a long push on button 1 would be 21.

[akbooer]

After an embarassing three attempts, v21.3.29c has this multi-push scene numbering implemented for shelly-ix3 (only, at the moment.)

[therealdb]

@akbooer yeah, I think the numbering is OK.

What I was referring to detached mode is that when in this mode, you have input and switch not in sync, so imho we should map them as a BinarySwitch and a generic security sensor for the input. You'll get both \input and \relay mqtt message.

I think it's OK to discuss Tasmota in this thread, since it's basically all dedicated to MQTT

[akbooer]

@therealdb said in MQTT – setup and use:

we should map them as a BinarySwitch and a generic security sensor for the input.

Can't be a generic security sensor if you want to capture the different switch press modes, so I think just the sl_SceneActivated and time makes more sense.

[Crille]

Just wanted to say big thanks to all for the great work!
I've read all the progress with the broker and Tasmota bridge with joy and now managed to switch my Sonoffs from rules and Virtual HTTP Devices completely to MQTT using homebridge-mqttthing and Virtual Sensor plugin.

[akbooer]

@crille

Excellent news. Yes, I am using homebridge-mqttthing too, for my few-remaining Zwave devices bridged to openLuup from Vera. The Homebridge-Shelly accessory is also very functional.

All this means that the Apple Home app is my primary UI (well, actually secondary, since Siri on the HomePod takes care of most things.)

[rafale77]

Awesome to see the MQTT implementation. Only if I could get myself the motivation to migrate to homebridge and get everything (Z-way/openLuup/HomeAssistant/Homebridge) to talk through MQTT instead of http as they are at the moment... It seems to be a lot of work...

For me too, the Apple Home app has become my primary (yet rarely used) UI.

[Crille]

@akbooer said in MQTT – setup and use:

for my few-remaining Zwave devices bridged to openLuup from Vera

I'm trying to get rid of the old Vera plugin for Homebridge.

What topics do I put in mqttthing to get/set bridged Vera devices?
I got the "getOn" to reflect the status when I had luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true) in the Lua Startup Code, is that necessery for this purpose?
Do I need to write a handler for this?
I tried a generic handler but never got it to work.
Do you have an example of a handler if it's required?

[akbooer]

@crille said in MQTT – setup and use:

What topics do I put in mqttthing to get/set bridged Vera devices?

Depends what you want to get/set. Currently, I'm just using this for on/off switches, so using the mqttthing type Light bulb - on/off. I'm sure you can be more sophisticated, but I haven't tried it.

As an example, I'll use a Vera-attached Zwave switch (device #30186 – it's actually a Fibaro relay, but it could be anything)

The first thing you need to ensure is that you have set the openLuup MQTT server to publish variable updates, using this line in Lua Startup:

luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true)   -- publish variable updates

So, then, in order to reflect the relevant variable in the mqttthing you need in MQTT Topics :

• Get on – openLuup/update/30186/SwitchPower1/Status

and in order to control it:

• Set on – relay/30186

The relay command above is just a convenient openLuup shortcut to turn devices on/off which works both in MQTT and as an HTTP request.

That should be all for basic control.

[Crille]

@akbooer Thank you, I never understood that the relay/ command was available to MQTT as well.
I guess there's no easy way to handle setBrightness?

[akbooer]

I knew that was going to be the next question... I’ll add something modelled after the Shelly commands (like /relay,except that this takes 1 and 0 as arguments instead of turn=on, etc.)

[akbooer]

@Crille

OK, latest development version (21.4.28c) has HTTP and MQTT requests to change a dimmer:

for device #51 to brightness level 42:

HTTP:

http://openLuupIP:3480/light/51?brightness=42

MQTT:

• topic: light/51
• message: 42

There's been some fairly drastic internal refactoring of the openLuup API, but you shouldn't notice anything changed...

[Crille]

@akbooer Wow, that was fast! Thanks, works like a charm.
May I bother you with my next issue? Every time I restart Homebridge my sensor values and current state of bridged devices are lost to mqttthing and shows 0 or OFF until there is an update from the device. Is there a way to retain the values from openLuup/update?

[akbooer]

As you’re probably aware, retain is the relevant word here. Currently. The MQTT server does not treat device variable updates as retained messages, so that when Homebridge subscribes it does not send the latest value. I need to consider that further...

[therealdb]

In my own broker I have a Vera/VeraID/update message causing an update from the bridge on demand. I find it useful when subscribing from my windows app, so I get all the updates. It’s similar to what Shelly or tasmota is doing. Maybe it’s easier to implement than retained messages.