Disaster recovery and virtualisation

[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.

[akbooer]

@therealdb

Thanks for that! I think the challenge in this case is that we are somewhat constrained by what the mqttthing is able to handle. It has some configurability, but I’m not sure whether we can use this approach. We will see.

[Crille]

@akbooer Perhaps an update of all or specified variables could be initiated by a topic in the startPub setting?

[christian_fabre]

I have a Shelly plug and a Tasmota sensor.
I installed the latest OpenLuup version (21.4.28c)
I have the Shelly and Tasmota bridges that appear automatically, but I don't have the child devices.
Error message in the logs:

2021-04-29 15: 02: 20.795 openLuup.context_switch :: ERROR: [dev # 75] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 20.795 openLuup.mqtt :: ERROR publishing application message for mqtt: tele / piscine / SENSOR: ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.216 openLuup.context_switch :: ERROR: [dev # 76] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.217 openLuup.mqtt :: ERROR publishing application message for mqtt: shellies / shellyplug-s-20E453 / relay / 0 / power: ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.219 openLuup.context_switch :: ERROR: [dev # 76] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.219 openLuup.mqtt :: ERROR publishing application message for mqtt: shellies / shellyplug-s-20E453 / relay / 0 / energy: ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.221 openLuup.context_switch :: ERROR: [dev # 76] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.221 openLuup.mqtt :: ERROR publishing application message for mqtt: shellies / shellyplug-s-20E453 / relay / 0: ./openLuup/api.lua:148: attempt to index field '? ' (a nil value)
2021-04-29 15: 02: 21.223 openLuup.context_switch :: ERROR: [dev # 76] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.223 openLuup.mqtt :: ERROR publishing application message for mqtt: shellies / shellyplug-s-20E453 / temperature: ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.225 openLuup.context_switch :: ERROR: [dev # 76] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.225 openLuup.mqtt :: ERROR publishing application message for mqtt: shellies / shellyplug-s-20E453 / temperature_f: ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.227 openLuup.context_switch :: ERROR: [dev # 76] ./openLuup/api.lua:148: attempt to index field '?' (a nil value)
2021-04-29 15: 02: 21.227 openLuup.mqtt :: ERROR publishing application message for mqtt: shellies / shellyplug-s-20E453 / overtemperature: ./openLuup/api.lua:148: attempt to index field '?' (a nil value)