search

peterhinch / micropython-mqtt

A 'resilient' asynchronous MQTT driver. Recovers from WiFi and broker outages.
MIT License
549 stars 116 forks source link

Will not sending update #47

Closed mytechnotalent closed 3 years ago

mytechnotalent commented 3 years ago

I have will enabled in my config.py as such: config['will'] = ('myfeed', 'Offline', True, 1)

When it goes offline this feed never is seen on the server.

peterhinch commented 3 years ago

When it goes offline this feed never is seen on the server.

I'm unsure what you mean by this. When your client goes offline, after a period the broker should publish to the topic myfeed and the message should be picked up by all clients subscribed to that topic.

Which broker are you using? All testing was done with mosquitto.

mytechnotalent commented 3 years ago

Hi @peterhinch thank you for getting back so quickly! I am using the Adafruit IO. Perhaps this service is not compatible with the feature. If it is not do you have any suggestions how I might find a device offline?

nevercast commented 3 years ago

Make sure you're matching the requirements stated here: https://io.adafruit.com/blog/tips/2016/06/24/last-will/

For example, it must be an abrupt disconnect, you cannot call disconnect() or close(), you must lose connection instead. The config you have looks correct Adafruit also requires 5 minutes before it publishes the LWT, and if you connect within that time it is not sent.

To reproduce, connect as you are, with your config correctly set as it is. Then disconnect the WiFi on what I assume is an ESP32, and then wait more than 5 minutes. You should see the LWT published under those conditions.

mytechnotalent commented 3 years ago

@nevercast I have killed the connection and it still have not published the LWT.

nevercast commented 3 years ago

You might like to try https://test.mosquitto.org/ or https://www.hivemq.com/public-mqtt-broker/ or install your own MQTT server to test this separately from Adafruit to see if the issue is with the ESP32 or with the broker.

peterhinch commented 3 years ago

@mytechnotalent At risk of stating the obvious, it's worth bearing in mind how the last will (LW) feature works.

The client, on initial connection to the broker, sends a connect message informing it of its LW. From then on the broker maintains its own timeout on client connectivity. When the timeout occurs, the broker publishes the LW. The client firmware has stopped running long before this event occurs - after all, the plug may literally have been pulled. It would seem that failure modes are:

  1. Client: on initialisation it failed to send the LW message to the broker.
  2. Communications: broker did not receive the message.
  3. Broker: last will feature or client timeout not working correctly.
  4. Communications: broker published LW but it was not received by other clients.
  5. Other clients: not correctly subscribed to LW.

I think 1. and 2. are unlikely for two reasons.

  1. The LW feature has been extensively tested with a local broker.
  2. The communications protocol awaits a CONNACK message from the broker. The fact that an OSError did not occur on initial connection means that the broker responded correctly to the initial connection with its LW content.

I recommend testing with a different broker, preferably mosquitto as this was used for our testing. Either install a local version or adopt the suggestion of @nevercast and use the mosquitto public broker.

mytechnotalent commented 3 years ago

@peterhinch @nevercast I will try out Mosquitto. Thank you both for the help!