MQTT – setup and use
-
@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.
-
@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.
-
akbooerreplied to ArcherS on Apr 30, 2021, 8:54 PM last edited by akbooer Apr 30, 2021, 4:54 PM
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!
-
rafale77replied to akbooer on Apr 30, 2021, 9:02 PM last edited by rafale77 Apr 30, 2021, 5:05 PM
@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.
-
@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 -
@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.
-
@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.
-
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
-
ArcherSreplied to christian_fabre on May 1, 2021, 7:59 AM last edited by ArcherS May 1, 2021, 4:05 AM
@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.
-
-
-
Try this: delete the Shelly bridge and restart openLuup.
-
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
....................... -
@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 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.
-
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 -
61/107