How to retrieve the status of my mqtt

[jbudd]

@Paul

I'd like to set up something like a ping that tests the communication between MQTT and Node-RED every 5 seconds, for instance. If the ping doesn't return, I'd receive an email.

This does have the advantage over LWT that it's on your own system, so if the MQTT broker goes down you have the chance of noticing.

But if your internet connection goes down you can't send an email.

To catch that event you could have the second part of the flow repeated on another machine on a different network.

[zenofmud]

There is a great tutorial MQTT Essentials - All Core Concepts Explained you should read. It will give you a better understanding of how it works and the terminology that is used.

[dceejay]

On your original flow... Note... the status node reports it's information on msg.status and not msg.payload - so your switch needs to monitor msg.status....

[kitori]

Because of some difficult networks where i deploy some maschines, i use a public reachable https://github.com/louislam/uptime-kuma instance with a push monitor(alternative https://healthchecks.io/ ) to monitor my devices:

so you can add a http request node to the mqtt subscribe node to ping the http endpoint. Then you get a notification when the local internet is down.

[Paul]

Hello, I'm sorry for not having responded. Do you know where I can find a guide to understand how to set it up and what to fill in the fields?

[Trying_to_learn]

mqtt-v3.1.1-os.pdf

This may help.

Or:

MQTT

Or:

http://www.steves-internet-guide.com/mqtt/

Or:

MQTT Explained: The Complete Guide

I'm not sure exactly what part of it you need help.

Or maybe this:

Introducing the MQTT Protocol – MQTT Essentials: Part 1

Free public MQTT broker available too.

[Paul]

Hello,

Thank you for your response, which seems interesting to me. Is the software paid? I see that the server is a demonstration server. How did you implement it in Node-RED?

[Paul]

Thank you for your documentation. I need help to understand and to know what I need to fill in.

[Trying_to_learn]

MQTT is free.

The program, the protocol and all parts.

The only paid part is the broker.
But there are free ones out there too.

[Trying_to_learn]

You need to look at the first tab.

That one is the THIRD one.

connection.

There isn't much there either.

Only the IP address of the broker.

The MQTT IN and MQTT OUT nodes are the ones you need to do things with.

[Paul]

Yes, I understand, but I was referring to his proposition of "uptime-kuma." I was wondering if the service is paid.

[Trying_to_learn]

hivemq have a free broker.

@Paul

uptime-kuma.

Mind showing me where this is?

[Paul]

Steve told me earlier in the discussion that to receive a message upon server disconnection, it's configured here. That's why I asked him if he knew what I needed to fill in for it to work and for me to understand how it works for future reference.

[Trying_to_learn]

Install a MQTT BROKER on one of your machines - Ubuntu/similar preferred.

Then you can learn and not worry about anything.

EVERYTHING will be in your control.

I learnt in about 3 hours.

[Paul]

Kitori told me

Because of some difficult networks where i deploy some maschines, i use a public reachable GitHub - louislam/uptime-kuma: A fancy self-hosted monitoring tool instance with a push monitor(alternative https://healthchecks.io/ ) to monitor my devices:

so you can add a http request node to the mqtt subscribe node to ping the http endpoint. Then you get a notification when the local internet is down.

[Trying_to_learn]

I am not exactly sure how to describe how to do that with an EXTERNAL broker.

On my LOCAL broker I do this - example:

From that last link I posted:

What is MQTT Last Will and Testament (LWT)? – MQTT Essentials: Part 9

When does the MQTT Broker Send the LWT Message?

According to the MQTT 3.1.1 specification, the broker sends a client’s Last Will and Testament (LWT) message in the following situations:

    I/O error or network failure: If the broker detects any issues with the input/output or network connection, it will distribute the LWT message.

    Failed communication within Keep Alive period: If the client fails to communicate with the broker within the specified Keep Alive period, the LWT message is sent. In Part-10 of our MQTT Essentials, we will explore the concept of MQTT Keep Alive time and delve into its significance it.

    Client closes connection without DISCONNECT: When the client terminates the network connection without sending a DISCONNECT packet, the broker ensures the LWT message is distributed.

    Broker closes connection due to protocol error: If the broker closes the network connection due to a protocol error, it will send the LWT message.

Understanding when and why the broker sends the Last Will and Testament (LWT) messages lays the groundwork for implementing best practices in leveraging this feature, which we will delve into in the next section.

[Paul]

Alright, I understand, thank you. Have you added any other parameters or just those? Because I have additional parameters, and how do you handle the payload you receive? Is it in a debug? Is it possible to receive it via email? Or is the payload only visible in the MQTT server?

[Trying_to_learn]

No.

The messages are sent with the given conditions are met.

The message is received with the topic of EOM (Which is a stuff up, it should have been EOL, but anyway....)

To I have a MQTT IN node with the topic of EOM.

Any messages received in that node is that machine's EOM message.
Sorry, the BROKER's message.

I'm getting confused now.
But I suspect that is what you want.

Ok, sorry.

This is on ANOTHER machine which uses/talks to the other BROKER

So on each machine you have to define the broker.

So here you see I am using TIMEPI
This is TELEPI.

So on TELEPI when I set up the broker I put in TIMEPI IP address, (in the first tab) then on the third tab I do this with the name TELEPI.

So if the link fails between TIMEPI and TELEPI:
TIMEPI broadcasts a message on the EOM topic and you can process that and see who died, and act accordingly.

[Trying_to_learn]

Set up a broker.
Local or remote.

All devices talk to eachother via the BROKER.

On each of your devices configure the broker - setting the IP address.
On the third tab (messages) set up the bottom one with a TOPIC (I chose EOL) and a message that will identify the machine.

If the link from the BROKER to that machine fails the BROKER will send out a message containing the message you entered above.
So you have a MQTT IN node subsribing to that topic.
Do this on ANOTHER machine.

Break the link to the other machine.
Wait for the time out and you will/should see the message arrive via that MQTT IN node.
You then add code (nodes) there to alert you that that machine has died.

Having a LOCAL BROKER you can do this on the BROKER machine.
But if you use a REMOTE one, you can't.

This is a graphical attempt to explain what I said.
(given that "machine 1" is the problematic one.)
and "machine 2" is another local machine.

[jbudd]

I am rather puzzled by all this focus on the MQTT LWT message.

@Paul seems to believe that the broker is going down.
If that happens, nobody is going to be sending out LWT messages.

The LWT message will be issued, after a couple of minutes, if Paul's device goes down or looses internet connection.
He would have to be monitoring that topic from a third machine since his will be off-line when it is published. (The behaviour might be different if the birth, death and last will messages are persistent, which I advise against)

If it's the broker that's unreliable, he should be tracking the Birth message which will be issued when either the broker or his own server comes back on line.