Detecting link closure - options?

General
1

Ok, not the best description.

I know I have explored MQTT before and have got things working.

Alas I am back with that and am (again) stuck.
Well, I don’t know of a good way to do this thing.

Back story:
I have a RPI WAP.
I have an Arduino connected to it (via WiFi) and DHCP.

I’ve got around the problem of non-static IP addresses.
When the device first connects, it gets its IP address and sends it on a MQTT topic with the IP and its name.

Then NR modifies part of the flow to identify it by name rather than by “random” IP.

All good.

So, I can’t look at the condition of a particular PING to see if the device is there or not.

I was thinking of using MQTT’s will message, but it seems not to be as easy as I expected.
Though I now realise that it is probably because I haven’t set it up on the ARDUINO - rather than the RPI. So there isn’t really a LWT message.

Ok, I may look at setting that up on the Arduino side of things.

But can anyone think of another way of detecting if the WiFi link goes down?

As it is via DHCP (the only way I can get it all working. Static IP seems to be a real pain).

I’ll shut up now.
:slight_smile:

2

Are you saying that is not practical to set fixed IP address on the Arduinos? I don’t use them but find that difficult to understand.
If so then possibly you could you use ping via the exec node.

3

Just set lwt up properly, it isn’t hard. https://www.hivemq.com/blog/mqtt-client-library-encyclopedia-arduino-pubsubclient/

4

I'm with colin, I'm using ESP modules and used a static IP for them, much easier to control, however it will not change anything so far, I guess you will have some sensor that is sending the value every specific time, or maybe you have some other telemetry send by mqtt like uptime or whatever, if yes, you can use a trigger node asuming you expect to receive a message from this station every certain amount of time, if is not received then means your station is down.

image
image.png521×606 17.3 KB

I don't know if that helps you.

Regards

5

No, the “problem” is the RPI and NOT using DHCP.

Also the RPI is NOT my main gateway.

(Back-back story)
I have a network with FIXED IP addresses. That connects to a ROUTER. And I prefer FIXED IP addresses on my LAN.

I have a RPI as a “WAP” (not really the right term I think) as its WiFi addresses are different to the LAN. There is NAT in there somewhere but read on.

It is … what ever.

When I connect to the RPI WAP, I get full access to the LAN - and web. That part works. Though it doesn’t work 100% as it should.
THAT RPI can surf the net, access all other devices on the LAN, save one. The gateway/modem.
I just won’t ping it. But that’s another story.

So, back to the WAP thing.

If I connect to the RPI - for which I only found notes to do it with DHCP - the connection works.
If I program the Arduino with a FIXED IP - even in the DHCP range - it (the Arduino) can’t see the MQTT broker/server. Which is on that RPI.

I’ve tried for hours/days trying to get it working and have given up.

SO, when the Arduino connects, it has to get a dynamic IP.
Granted I set the lease as long as I want, but the thing is if the IP is dynamic, I don’t want to use the IP allocated by DHCP because one day it may change. Then I have to go and change the IP addresses used to detect it being connected to the new one.

Does that help?
I would like to get FIXED IP addresses working on the WiFi side as well, but it just isn’t going to happen now.

It is handy having DHCP on it as well, as now and then I connect to it to control things with my phone and so the IP is not relevant and it saves messing about with setting the IP when it doesn’t really matter in that case.

The RPI is running Jessie. Not Stretch and I don’t want to update to Stretch as there are a lot of things to do and I just don’t need the hassle just now. (Enough Yaks to shave as it is.)

End of back-back story.

That’s about it.

So what I am wanting to do is get something happening (MQTT LWT would do it) but reading the Arduino MQTT docs I can’t see where/how to add LWT to the connection, so if the connection is abruptly terminated, the program knows.

As stated, I have a couple of tricks working in NR now so when it connects, it is identified. But I haven’t tried it with multiple DHCP devices that are Arduinos and have that trick at their end to make it all work.

6

Thanks.

I shall look at the link.

What I have seen so far I didn’t see mention of LWT on the MQTT side of things.

7

Read Usage section, heading 4

8

Well, this is what I see - if I am looking in the right place:

byte willQoS = 0;
const char* willTopic = "willTopic";
const char* willMessage = "My Will Message";
boolean willRetain = false;
 
boolean rc = mqttClient.connect("myClientID", willTopic, willQoS, willRetain, willMessage);

Good, but that’s where it all falls over.

I have the Arduino pubsubclient.library installed.
V 2.6
But where it says: mqttClient.connect( ) the code that came with the library I have says:
client.connect( )

And fully it says:
client.connect(mqtt_server)

So mqqt_server I get.
myClientID… Isn’t mentioned.

Or, I can’t equate it to what is in the docs with the library I have.

And, just to save a bit of time,I checked and it is the latest version so I can’t update it.

I won’t post the code because it is just an expansion of what is included with the library.
Sorry if I am not getting how it is supposed to work. The format is not recognised by me.

But thanks.

P.S.
Tried the included sketch (on the page) and it errors.
I’ll put that down to the fact it is written for ETHERNET and I am using WiFi and the include is missing.

I’ll see if I can get something working from it.
Oh, and the example doesn’t have the LWT part, so I am even more “flying in the dark” in how to do it.

But I shall try. Alas it maybe on tomorrow’s job list.

9

Not sure what docs you are reading but the normal way is to create the client object (with parameters like the server and port) then call client.connect with parameters like the lwt etc.

The full Api is here https://pubsubclient.knolleary.net/api.html

10

Thanks for that link.

But indulge me this observation:
That link shows the command structure like this:

boolean connect (clientID, willTopic, willQoS, willRetain, willMessage)

The first link ( https://www.hivemq.com/blog/mqtt-client-library-encyclopedia-arduino-pubsubclient/ )
shows command structure like this:

mqttClient.connect("myClientID", willTopic, willQoS, willRetain, willMessage);

So to me they are two different … libraries?

The one I have supports the

boolean connect (clientID

format, but in the readme and stuff that came with it there was no mention of LWT and that.
So I can’t know what isn’t in the docs supplied with the library.

As I said, I shall look into trying some of the permutations of the command but it is going to take time.

11

No, they are exactly the same - the hivemq blog post is providing example code, the api documentation shows the function signature, so they may look slightly different, but they are expressing the same thing.

If you look at the API documentation, you’ll see the library has four different connect functions:

boolean connect (clientID)
boolean connect (clientID, willTopic, willQoS, willRetain, willMessage)
boolean connect (clientID, username, password)
boolean connect (clientID, username, password, willTopic, willQoS, willRetain, willMessage)

You are currently using the first connect function - you provide a clientID and it returns a boolean to say if it has connected or not.

You want to use the second connect function where, in addition to the clientID you also provide the four require properties to configure the LWT - just as the hivemq blog post shows.

In your previous post you got confused by the use of mqttClient.connect(...) vs client.connect(...). Let me clear that up for you. mqttClient is simply the variable name they have chosen to use for the PubSubClient instance in their examples. Your sketch uses the variable name client. It’s nothing more than that - they both point at an instance of the PubSubcClient.

Note - I’m the author of the PubSubClient library, so please take this with some authority.

12

Thanks much.

It wasn’t that I was upset. Just confused. Now that that part about the mqttClient.connect( ) is cleared up, I can progress.

In the mean time I did try it and added the LWT stuff.

But - typically - it has brought more confusion.

Ok, this is what I think as of NOW.
MQTT LWT is sent FROM THE REMOTE DEVICE to the BROKER.
It is a message that the broker “on sends” if the link from the device to the broker is lost in a bad way.

So in my Adruino code I have this (only the relevant parts are shown to keep it compact)

byte willQoS = 0;
const char* willTopic = "EOM";
const char* willMessage = "GPS comms failure";
boolean willRetain = false;


void reconnect() 
{
  // Loop until we're reconnected
  Serial.println("Reconnecting");
  while (!client.connected()) 
  {
    Serial.print("Attempting MQTT connection...");
    // Attempt to connect
    if (client.connect(mqtt_server, willTopic, willQoS, willRetain, willMessage)) 
    {
      Serial.println("connected");
      // Once connected, publish an announcement...
      client.publish(outTopic, "hello world");

And all is supposed to be good.

Thing is (and I know there will be problems with DHCP lease times, but …)

When I plug my device in (power up the arduino) it connects.

I un-plug it and … nothing.

Plug it back in and then I get the LWT AFTER it reconnects.

Isn’t it supposed to be when it DISCONNECTS?

When it connects it gets the Birth Certificate - or something like that.

So that’s where I am at now.

Sorry guys.
But I am slowly getting the jist of it.

And thanks again to all.

13

When you disconnect the device it can take a little while for the broker to notice - it will depend on a few different things. In your testing, keep an eye on the mqtt broker log as it will report when it sees clients disappearing. Do some tests to see how long it takes - it could be up to a minute.

The reason you got the lwt after reconnecting is because the reconnection was the first sign to the broker that your device had gone - it hadn’t yet timed out the previous connection. So it sent the lwt for the previous session.

14

Yeah, ok, I’ll buy that, but what about subsequent times on THIS cycle?

eg:
I plug it in the first time and as you say after RE-connecting I get the LWT because it was the first sign in to the broker that the device had done (I’m guessing that’s what you meant and not Gone.)

But then if I unplug it AGAIN, I should get a LWT when it is disconnected.

ARGH!

Just tested it again and it (the program/something) is playing games with me.

Yes. You are (obviously) right. It was when I was testing I was just a bit too quick in plugging it back in.

My bad.

So, now what I can do is detect that LWT and action things to happen.

Problem … solved? (Well, one square further towards being solved.)

Again: Thanks.