Is there a way to monitor mqtt message did not come in predefined interval?
In other words, I want to monitor mqtt publisher is alive and sending messages.
Have you thought about utilising MQTT's Last Will and Testament functionality on the publisher's/broker's side for this?
https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/
https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over/
It would allow you to set a status to say, something like OFFLINE when the publisher is no longer alive.
1 Like
Thanks for the hint. I think this is robust enough.
I think I don't need to experiment with LWT (Last Will and Testament) which is, when looking for the purity of mqtt, the only "proper" solution 
Trigger works as expected. I am able to send the mail "no mqtt - internet disconnected" when there are not mqtt messages within preset perriod.
But what about to send an e-mail when mqtt communication is restored.
One message only of course...
I am lost...
Try something like this
Msgs are OK gets sent on 1st message but it isn't sent again unless the node times out and then the messages start up again
Great. Works. This was not really obvious from the trigger node description (When triggered, can send a message, and then optionally a second message, unless extended or reset.)
Thanks for your help.
For future readers of this topic, if set up with LWT, a message can be published to report the publisher went down, and with an initial message to be send when the publisher comes back online all you need is a switch node behind the MQTT-in. One output for the LWT message to handle when it goes offline, one output when it comes back online and send the email, and one output to handle all normal data.
Note that this is supported on a protocol level, and added to MQTT specifically for situations similar to this. Sure, you can solve it with a trigger node, but MQTT itself already has a solution for this.
2 Likes
Agreed about LWT.
But in my case, if I want to use LWT it is necessary to write additional code in my MQTT publisher (RPI + Python Paho MQTT).
So much easier solution to me was to use a Trigger Node.
Of course if you used node-red to publish the data then it would be trivial to add the LWT messages.
As I am thinking about the case more deeply, the LWT "all in node-red" solution can be:
- receiving original msg/topic using Node-red "in node" subscriber
- re-publish it with the LWT properly configured using Node-red "out node" (note the other naming used - see screenshot below)
- subscribe for this new message using an other "in node" subscriber
- connect the necessary logic to this subscriber
I don't know which machines the node red publishers and subscribers and the MQTT server reside in, but note that the scheme you have described will only send the LWT messages when the node-red instance described in point 2 in your post becomes disconnected from (or connected to) the MQTT server. It will not send them if the node-red in point 1 stops publishing data.
I see. Misunderstanding of MQTT messaging/protocol on my side.
Thanks
If what you are actually looking for is an indication that the publisher stops publishing new values, rather than an indication that it has disconnected, then the Trigger node is the right solution.
Yes, "Trigger Node" solved my case perfectly. Thank you anyway.
Hello,
I have the same requirement and have setup a trigger node appropriately. From the MQTT in node I can see messages coming in at 5 second intervals with a debug however because the data isn't actually changing (its a temperature sensor) the trigger node is not seeing them as new messages and timing out.
Any suggestions of a way to resolve?
Cheers
James
Do you have "Extend delay if new message arrives" ticked?
