The other day, my CloudMQTT instance stopped responding. This is used in combination with OwnTracks. I was only aware of this after a few days.
After a restart everything was working fine again.
To prevent this, I would like to be able to monitor if the broker is still alive. Since the OwnTracks topics did not get updated (the app was unable to post and queued messages) I am looking for another way.
Can I subscribe to a system topic $… that should be regularly updated or is there a better way to achieve this?
@sihui, does the LWT get sent if the broker itself goes down? I was under the assumption that the LWT was sent by the broker when a client goes down and there is no LWT message for when the broker itself goes down.
One approach I documented here. Basically, have a Switch get updated to ON every time a message is received and set a Timer (Expire binding) to set it to OFF after a certain period of time. When it goes to OFF you know that the device hasn’t reported in awhile and is probably offline.
This works best if you have relatively regular messages so you can say with confidence “if I don’t receive a message in x minutes I know the service is down.”
One thing you can do is implement this heartbeat yourself inside OH itself. Set up two MQTT Items, one outgoing and one incoming on the same topic. Periodically post a message and set the timer described above on the incoming Item.
That’s a valid question
I thought because of
When will a broker send the LWT message?
According to the MQTT 3.1.1 specification the broker will distribute the LWT of a client in the following cases:
An I/O error or network failure is detected by the server.
The client fails to communicate within the Keep Alive time.
The client closes the network connection without sending a DISCONNECT packet first.
The server closes the network connection because of a protocol error.
in this case the “server” is the broker.
Fortunately in my two years of experience with openHAB my mosquitto broker has never failed so I was not able to test
Hmmm. I can see lots of interpretations from that text. It says “the broker will distribute the LWT” which implies that if the broker goes down, particularly if it doesn’t go down cleanly, there won’t be anything to send the LWT. The last sentence leaves some hope but I think it still reads like the LWT only gets sent if the broker itself is still up and happy. If it isn’t then there wouldn’t be a server around to close the network connection.
From a technical perspective, the only way a LWT from the broker could cause a LWT to be delivered is if it pre-delivers the LWT to all the clients and the clients wait around to actually process it until either told to by the broker or they lose connection to the broker. That sounds kind of brittle to me.
Also, since the broker already “informs” the clients when it goes down through the connection error (see the OH logs when you restart Mosquitto) so I’m not surprised if there is not a LWT for the Broker itself.
The real problem is the MQTT binding doesn’t have a way to expose its connection status to OH where it can be used in Rules/Sitemap, etc.
Perhaps a connected channel when/if the 2.x bindings gets written could solve this.