Hello everyone, I’m new to the forum and Openhab so please forgive me if my question may sound trivial to some of you.
I’ve got a few Sonoff devices flashed with Tasmota firmware that works with MQTT. So far I have everything up and running as expected, with a few switches in my sitemap that command my Sonoff devices via MQTT and update the state of the Switch item after receiving the relevant response again through MQTT.
The issue I am facing is that currently, I can’t tell if a device in Online or Offline after it has been powered off from the mains. I have read a few topics on this matter and came to the assumption that this can somehow be achieved with MQTT’s Last Will & Testament (LWT). But I can’t figure out how to set it up. By default each Sonoff devices when first powered up broadcasts an MQTT message with its state (Online) to the topic “tele//LWT”.
What I would like to achieve is get the sitemap to grey out any items that have gone OFFLINE and maybe even update the state of the switch to OFF.
The switch being OFF and the device being offline are very different. If the device is online then it should report it’s status (either on or off) at set intervals. For the device being offline have a look at the topic below.
Do you know if that “Online” message is retained? Does it publish anything to that topic when it goes offline (presumably it would be “Offline”)? That’s the whole point of a LWT topic and the fact that it publishes to a topic called LWT indicates it’s already configured for that.
If so it’s super simple. Create a switch type Channel on the Thing you have for each of your Sonoff devices. Link a Switch Item to the Channel and when the Item is ON the device is online. When it is OFF, the device is offline. Then you would use the visibility tag on the sitemap to hide the “active” rows for controlling those devices and show a read only version of that row when the Switch is OFF.
But you will need to know what messages are published when the Sonoff goes offline to configure the Channel correctly.
If the messages are retained, then OH will see the current status of the Sonoffs whether or not OH was online and able to receive the LWT message or not. The retained messages will be received as soon as OH reconnects to the broker.
Thanks for your replay, I came across this topic before but I found it a little bit complicated for what I’m trying to achieve. Baring in mind that I’m just getting to know Openhab, I may find it complicated just because I don’t fully understand it.
Thank you for your reply. Your suggestions have pointed me in the right direction. I had a look at the Tasmota console and from what I understand the Online message is published as retained “tele/sonoffRF-1/LWT = Online (retained)”. I then used a standalone MQTT client to subscribe to the LWT topic and I got the “Online” message straight away. Up to this point all is good, I can see how this can be used as you’ve suggested to trigger an ON state. I then powered off the device from the mains, but I noticed that no “Offline” message was published on the tele/sonoffRF-1/LWT topic.
Strangely after powering on the devices again, I got an Offline message published to the LWT topic followed immediately by an Online message. I’m not sure why this is happening, my guess is that the device loses power before the Offline message is published to the topic and then sends it out once it regains power?
Either way, I can’t see how I can get the Offline message once the device loses power, although I could be missing something here.
How long did you wait. The broker won’t publish the offline message until the device fails to respond to the heartbeat it keeps going with it after a time.
No, that can’t be it because it’s actually the Broker that publishes the LWT message. It’s like you see in the movies. You give the incriminating evidence to someone else to publish in the event that you die. In this case, the Sonoff tells the Broker to publish Offline to the LWT topic if the Broker determines the Sonoff has died. Maybe it was just a fluke of the timing? Does it happen that way every time with different amounts of time before plugging the device back in?
You were correct, it was a timing issue. Although I did try powering my devices on and off twice, oddly I managed to get the timing right both times giving me the impression that I was getting the Offline message after powering ON.
Tried it now again, and I let it sit there for a while, and what do you know, about 30 seconds later I get an Offline message. It seems that my impatience has gotten the best of me. Now that I know I’m receiving the Online and Offline message I can get back to implementing the sitemap switch.
Thank you very much for your guidance, it really helped me get things straight. I’ll get back to you once a have everything up and running to let you know what it all went.
This seems straight I’m getting to it right away. I’d just like to know regarding best practice, should I create a separate Thing for every Sonoff device? At the moment I’ve setup a Generic MQTT Thing, with the name “MQTT Devices (Sonoff)”, and in this Thing I’ve added all my Sonoff switch channels. Is the setup is not ok? It works fine, I’d just like to know if it’s good practice to do so.
Best practice is to stick with the model defined in the Concepts section of the docs. A Thing represents a single device. A Channel represents a single actuator (i.e. something you can command) or a single sensor (i.e. something that provides information only). So it would be best practice to generate a separate Thing for each Sonoff device.
Given that they will all be the same, what I recommend is creating the first one through PaperUI, query for that new Thing using the REST API Docs, edit the JSON you get back with the topics and UID needed for the next Sonoff and then submit the edited JSON using the REST API Docs. You can very rapidly create lots of similar Things in this way.
@Kyriakos_Lo here is a link (with pictures, ) I have bookmarked and found very helpful regarding Rich’s suggestion for creating Things via REST API. It’s more for converting from files to PaperUI but good guide either way.
@H102 Thank you, very helpful. I’ll give it a read and hopeful I’ll get the hang of it quickly. So far I’ve been using a mixture of the PaperUI and the text editor to setup my Things and Items, but this method looks promising as I found my self creating similar Things over and over again.
) I have bookmarked and found very helpful regarding Rich’s suggestion for creating Things via REST API. It’s more for converting from files to PaperUI but good guide either way.
So far I’ve been using a mixture of the PaperUI and the text editor to setup my Things and Items, but this method looks promising as I found my self creating similar Things over and over again.