OpenHAB sending out its LWT

I run OpenHAB in a docker on a Linux server. My MQTT Broker runs in a separate docker.

I’d like to make openhab to send openhab/LWT offline when it is shut down (or crashed).

I have configured the mqtt broker with lwtTopic="openhab/LWT", lwtMessage="offline", lwtRetain=true. This is confirmed in the GUI Things → MQTT Broker → Advanced settings.

However, this after shutting down OpenHAB, this mqtt LWT never showed up in the mqtt broker (which is of course still running).

Has anyone managed to get this working?

Can you tell us how you know? The message is not sent to the broker at drop-dead time, the broker itself publishes to subscribed listeners, after a time.

I understand that it wouldn’t be instantaneous. The broker would’ve needed to wait for some sort of timeout before deciding that the client (openhab) is dead before sending out its LWT.

I waited for several minutes after openhab stopped.

Have you used OpenHAB MQTT’s LWT and does it work properly for you?

Did you send an Online LWT from openHAB? LWT is only set to LastWill, if the Topic was published before.

Info from Mosquitto broker (and I guess other brokers)

If the client disconnects gracefully with a correct DISCONNECT message, the broker discards the stored LWT message.

That’s a fair question, and I thought I had, but no memory of the extent of testing at the time… But now had a proper review.

First surprise, retain. Like you I thought setting lwtRetain=true is a good idea, new subscribers coming along after a drop-dead will get told, surely.
Yep, after the kill test, that seems to work as expected.

But surprise - if you subscribe before drop-dead and openHAB is still running, you get the retained offline message from long ago. Mosquitto does not clear an old retained topic message just because we’ve signed up with a new lwt. (I think that’s by design - we might be using the topic for anything else as well)
Looks like we’ve got to manage that part ourselves by publishing an empty or online message to the lwt topic after OH is up and running (if using retain).

Testing is a bit risky because of the LWT not activating on an orderly disconnect, but I have a dev system where I can afford to rudely kill openHAB.
Yep, broker sends LWT message to subscribers when it sees the connection close (quite quickly for me)

If we want “LWT” notification action on an orderly closedown, it looks like we have to manage that ourselves too.
If others can verify my analysis here, I can see it might be a useful enhancement to the binding to
(a) auto-publish an ‘online’ message on successful broker connection - can be used to clear away retained LWT
(b) auto-publish an ‘offline’ message on voluntary disconnect - to supply a faux “LWT”

No surprise in question of “still shows offline”, it’s expected behavior, as mosquitto will only publish the last will, not a first will :wink:
But much surprise in question of proper shutdown. Uhh…

Maybe it’s worth to add a feature to the addon (when subscribing to a lwt topic (for a thing), there are options for online AND offline message, so the openHAB addon should also provide both values and of course care about correct publish…)

EDIT: Did a feature request: [mqtt] add a correct LWT mechanism · Issue #12104 · openhab/openhab-addons · GitHub

2 Likes

Thanks for the tips

  • Yes I have a rule that sends LWT ‘online’, retained, on startup, but if this can be done by the binding, that would be better
  • I tried killing openhab instead of doing a proper shutdown, and the LWT did get sent.

So the solution is to send an offline message on an orderly shutdown. Which brings us to my other question 'System shuts down' trigger?

I’ve not much else to add except to mention that I’ve a rule template which publishes ONLINE to a LWT message when the broker Thing goes ONLINE. MQTT Online Status

That can be used in the mean time until the binding gets updated.

Are you finding that rules get loaded before things are initialised / online? I would’ve expected that things are initialised / turn online first, before rules are executed, so that they are ready to use without rules having to check. Imagine if you have another rule on startup that sends mqtt message, but mqtt binding isn’t online yet. The rule would have to implement some sort of timer routine just to do this.

That’s the general intention, but many Things rely on external services before becoming available. You can’t rely on this.

Rules can have multiple triggers, remember - you can trigger off both system started and Thing status changing to ONLINE. No timers, deals with broker connection interruptions as well.

Yes, that’s why the rule template triggers on the broker Thing changing to ONLINE. That is guaranteed to happen after the rule engine starts (see below) and that means it also works if the Thing loses its connection to the broker or goes OFFLINE at other times and not just during system startup.

The ONLINE message needs to be published every time OH connects to the broker, not just when OH first starts up.

What if it never happens? For example, when the network is down, the Broker is down, the Zwave controller is unplugged, etc. We can’t keep rules from running forever.

For some Things even under normal operation it can take some time before they become ONLINE.

Even without these, when you look at the runlevels, rules are loaded at level 40, the rule engine starts at level 50, but it’s not until level 70 that Things start to initialize. So you could almost guarantee that a standard System started (which is level 40) will trigger before any Things are initialized. And even with a system level 100 trigger, you can’t guarantee that all the Things are initialized because of externalities. Frankly, there is no point in the life cycle of OH that you can guarantee that any Thing is going to be guaranteed to be ONLINE since their status depends on outside factors.

In this case we don’t need the system started because the rule engine starts running before any Things change to ONLINE. Therefore during startup you’ll never miss the trigger caused by the Broker Thing changing to ONLINE.

Not entirely convinced about that. It may well depend on the binding. Certainly little hardship to code for both before/after cases. Perhaps its just the observation that, no matter when a rule is triggered, it might not get to run anything useful while fighting bindings etc. for resource.

I’ve created a PR for this

2 Likes