Disaster recovery and virtualisation

[akbooer]

@crille said in MQTT – setup and use:

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?

In the latest testing branch release (v21.4.30) the MQTT server now subscribes to the topic openLuup/query. If you publish a message with the format: devNo.serviceId.variable, for example,

• topic: openLuup/query
• message: 2.openLuup.Memory_Mb

it will force an immediate update message:

• topic: openLuup/update/2/openLuup/Memory_Mb
• message: 8.7 (or whatever)

You should be able to use this to get an initial value for any mqttthing.

Notice the formatting difference between the message and the returned topic ('.' instead of '/') this is intentional because it is in line with openLuup's existing dev.srv.var notation and it reminds you that it's not a part of the query topic, but it goes in the message, and avoids the need for openLuup to use a wildcard subscription.

[ArcherS]

@christian_fabre I added my Shelly 1PM today to OpenLuup v21.4.29b.

At first it did not work, and I could not figure out why. Then I found a post on the Shelly forum that said that there in some cases (or for some devices) could be a problem with the latest Shelly firmware and Mqtt.

I had the latest v1.10.3 in my 1PM. After I downgraded the Shelly to v1.9.4 it worked.

Check what firmware you have in your plug and if you have the latest you can try to downgrade and see if it works.
Go to https://www.shelly-support.eu/index.php?shelly-firmware-archive/ and enter your IP address, select the right plug variant (there are a few to choose from) and firmware release. Then you copy the url that is generated into a browser.
If you have blocked the Shelly in your router from Internet access you probably have to open it temporary for the downgrade.

I also added my Shelly Button to OpenLuup and for some reason I could not downgrade it, but I managed to get it working anyway after a few attempts.
(A bit strange since the post I found on the forum was on problems with the Button and v1.10.3.)

Another tip is to use MqttExplorer if you do not already use it and see if the Shelly shows up there. If it does, then at least the Mqtt part of the Shelly most likely works.

[akbooer]

@archers

Excellent diagnosis. Let's hope that's the root cause.

Entirely exaplins why I couldn't reproduce this ... my Shelly 2.5s are on 1.9.4, but telling me there's a 1.10.3, so I'll be sure NOT to do that!

I don't follow the Shelly forum much, so please pass on when it's safe again to upgrade.

@rafale77 Shellies are manual update... a good choice, as I'm sure you'll agree!

[rafale77]

@akbooer said in MQTT – setup and use:

I don't follow the Shelly forum much, so please pass on when it's safe again to upgrade.

@rafale77 Shellies are manual update... a good choice, as I'm sure you'll agree!

Ha! Indeed, There is an ongoing train wreck on the QNAP forum with people humorously (to me at least, maybe not to them) finding out the firmware autoupdate being enabled on the new firmware which itself has a lot of connectivity problems forcing many to downgrade... sounds familiar? No one is immune to a problematic upgrade or a use case where something breaks. And this came as a knee jerk reaction to a security breach for which the firmware upgrade itself does nothing because the exposure comes from an app.

[ArcherS]

@akbooer I routinely updated the two new Shellies and then I got v1.10.3, bad decision as it turnes out.
My two older Shellies are on v1.9.0 and worked directly when I enabled Mqtt.

Manual update is better, automatic is a pain, Win 10 is a good example on that. I assume I will get it on my Qnap when I update it.
I have also blocked the Shellies and Tasmotas in the the router

[Crille]

@akbooer Awesome!
This keeps HomeKit in sync after a restart. Thank you for the quick update, top notch as always!

[therealdb]

@archers said in MQTT – setup and use:

@akbooer I routinely updated the two new Shellies and then I got v1.10.3, bad decision as it turnes out.

I usually wait a couple of days, then update them in batch via MQTT. all good at the moment. I've blocked them from the reaching the Internet as well.

[akbooer]

@therealdb said in MQTT – setup and use:

update them in batch via MQTT

That’s a great idea! I’ve been doing them individually over HTTP up to now.

[christian_fabre]

Thank you very much to all.
in fact I had updated the Shelly plug (v1.10.3)
I installed v1.9.4 following the instructions of ArcherS.
but unfortunately I still have the same problem.
I have the creation of the Shelly Bridge, but no child.

here are the logs

2021-05-01 08:52:42.237   openLuup.io.server:: MQTT:1885 connection from 192.168.1.149 tcp{client}: 0x2ec6018
2021-05-01 08:52:42.267   luup.create_device:: [80] D_ShellyBridge.xml / I_ShellyBridge.xml / D_ShellyBridge.json   (ShellyBridge)
2021-05-01 08:52:42.268   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.268   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/online : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.269   openLuup.scheduler:: [80] Shelly device startup
2021-05-01 08:52:42.269   luup.set_failure:: status = 0
2021-05-01 08:52:42.270   luup.variable_set:: 80.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: EMPTY now: 0 #hooks:0
2021-05-01 08:52:42.270   luup.variable_set:: 80.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: EMPTY now: 0 #hooks:0
2021-05-01 08:52:42.270   openLuup.scheduler:: [80] Shelly device startup completed: status=true, msg=OK, name=ShellyBridge
2021-05-01 08:52:42.271   luup.shelly:0: New Shelly announced: shellyplug-s-20E453
2021-05-01 08:52:42.271   openLuup.luup:: creating room [10] Shellies
2021-05-01 08:52:42.272   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:226: attempt to index field '?' (a nil value)
2021-05-01 08:52:42.272   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/announce : ./L_ShellyBridge.lua:226: attempt to index field '?' (a nil value)
2021-05-01 08:52:42.273   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.273   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/announce : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.275   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.275   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/relay/0/power : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.276   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.276   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/relay/0/energy : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.305   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.306   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/relay/0 : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.307   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.307   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/temperature : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.308   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.309   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/temperature_f : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.310   openLuup.context_switch::  ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.310   openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/overtemperature : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 08:52:42.311   openLuup.mqtt:: shellyplug-s-20E453 SUBSCRIBE to shellies/command tcp{client}: 0x2ec6018
2021-05-01 08:52:42.313   openLuup.mqtt:: shellyplug-s-20E453 SUBSCRIBE to shellies/shellyplug-s-20E453/command tcp{client}: 0x2ec6018
2021-05-01 08:52:42.314   openLuup.mqtt:: shellyplug-s-20E453 SUBSCRIBE to shellies/shellyplug-s-20E453/relay/0/command tcp{client}: 0x2ec6018

I have the same problem with the Tasmota bridge

[ArcherS]

@christian_fabre said in MQTT – setup and use:

I have the same problem with the Tasmota bridge

Regarding the Tasmota bridge it creates one device per Tasmota, i.e. no additional child devices as for the Shellies. These you instead need to create yourself by e.g. using the Virtual Sensor plugin.
In this post you can find more on how I have done that.

Did you try with Mqtt Explorer? It is a very good tool to see that the Mqtt devices, both Tasmota and Shellies are working as they should, and also to look at what they send.

[akbooer]

@archers said in MQTT – setup and use:

Did you try with MqttBridge?

Do you mean MQTT Explorer?

[ArcherS]

@akbooer yepp, edited that typo.

[christian_fabre]

MQTT Explorer
 It seems that the Shelly plug is sending some info, as well as the Tasmota module

The Shelly and Tasmota bridges are well created, and that's it.
See log file above

[akbooer]

@christian_fabre

Try this: delete the Shelly bridge and restart openLuup.

[christian_fabre]

ok i just did it.
After starting OpenLuup, the Shelly Bridge is created ...
I attach the log
2021-05-01 10:40:39.029 openLuup.mqtt:: mqtt-explorer-8cd8e0cf SUBSCRIBE to # tcp{client}: 0x1a575f0
2021-05-01 10:40:39.032 luup.create_device:: [82] D_ShellyBridge.xml / I_ShellyBridge.xml / D_ShellyBridge.json (ShellyBridge)
2021-05-01 10:40:39.033 openLuup.context_switch:: ERROR: [dev #0] ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 10:40:39.033 openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/shellyplug-s-20E453/online : ./L_ShellyBridge.lua:343: attempt to index field 'hadevice' (a nil value)
2021-05-01 10:40:39.277 openLuup.server:: request completed (509175 bytes, 32 chunks, 994 ms) tcp{client}: 0x1a51f78
2021-05-01 10:40:39.277 openLuup.scheduler:: [82] Shelly device startup
2021-05-01 10:40:39.277 luup.set_failure:: status = 0
2021-05-01 10:40:39.277 luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: EMPTY now: 0 #hooks:0
2021-05-01 10:40:39.278 luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: EMPTY now: 0 #hooks:0
2021-05-01 10:40:39.278 openLuup.scheduler:: [82] Shelly device startup completed: status=true, msg=OK, name=ShellyBridge
2021-05-01 10:40:39.279 luup.shelly:0: New Shelly announced: shellyplug-s-20E453
2021-05-01 10:40:39.279 openLuup.context_switch:: ERROR: [dev #0] ./L_ShellyBridge.lua:226: attempt to index field '?' (a nil value)
2021-05-01 10:40:39.279 openLuup.mqtt:: ERROR publishing application message for mqtt:shellies/announce : ./L_ShellyBridge.lua:226: attempt to index field '?' (a nil value)
2021-05-01 10:40:39.280 openLuup.mqtt:: mqtt-explorer-8cd8e0cf SUBSCRIBE to $SYS/# tcp{client}: 0x1a575f0
.......................

[ArcherS]

@christian_fabre my Plug (not the S version) looks like this in Mqtt Explorer:

For some reason there is no announce message from your plug when comparing with my plug.

[christian_fabre]

I just redid a screenshot of MQTT Explorer
My Shelly plug has just been plugged in (control of the swimming pool pump)
I have the announcement message

[ArcherS]

@christian_fabre that is good news, then it looks as the Shelly works as it should in respect of the Mqtt settings.

Just to rule out the obvious; the Shelly devices and Tasmota devices should show up in OpenLuup in the two rooms "Shellies" and "Tasmota" and not in "No room".

Maybe deleting the Shelly bridge and reloading as @akbooer suggests now that you have the announce message.

[christian_fabre]

I have removed several of the Shelly and Tasmota bridges. But after the Reload, they are created in NoRoom.
The last thing I did was reload the OpenLuup files from GitHub OpenLuup Development, but I still have the same problem

[christian_fabre]

more
I notice that the variable OffSet is missing in the variables of the Shelly bridge