Last will on umqtt.simple

[SpotlightKid]

You can also run the script I posted in the Github issue I linked above under the unix port of MicroPython. If the value for MQTT_ROOT in the script is changed to '' (empty string), this client will receive its own last will when restarted.

[guyd]

One way to test this is to run mosquitto_sub on a PC on the network.

and how to get the last will message?

[pythoncoder]

If you use mosquitto_sub to subscribe to the last will topic, it will display the message if the device has connected with a last will and keepalive time.

The message is sent by the broker to all subscribers to the topic. When a device connects to the broker it registers a last will with the broker, along with the keepalive time. If, during the keepalive period, the broker has had no contact with the device, the broker publishes the device's last will. So the device needs to keep accessing the broker to prevent the last will from being sent.

This asynchronous resilient MQTT implementation runs an asynchronous task to ensure that the broker is contacted periodically to hold off the last will message.

[SpotlightKid]

The last will also works with a keepalive time of zero. It's then up to the broker to decide when it deems the client to be inactive and send its last will. In most cases that will be when the TCP connection between the client and the broker is closed / lost without a prior DISCONNECT control packet from the client .

[pythoncoder]

Interesting, I hadn't appreciated that.

I wouldn't rely on it in a practical WiFi application. It looks like a feature designed for wired networks where you have a high level of confidence in continued connectivity. A wireless connection can't offer that. On a wireless network it seems to me that the device should specify a keepalive time and ensure it makes contact with the broker N times in each period. N > 1 because, in a WiFi network, messages can be lost due to events like radio interference. The value of N determines how many consecutive missed messages constitute a dropped connection.

In other words the device should give all possible help to enable the broker to determine connectivity failure.

This is one of a number of ways in which the official MQTT solution does not address the reality of WiFi connections.

[guyd]

If you use mosquitto_sub to subscribe to the last will topic, it will display the message if the device has connected with a last will and keepalive time.

The message is sent by the broker to all subscribers to the topic. When a device connects to the broker it registers a last will with the broker, along with the keepalive time. If, during the keepalive period, the broker has had no contact with the device, the broker publishes the device's last will. So the device needs to keep accessing the broker to prevent the last will from being sent.

This asynchronous resilient MQTT implementation runs an asynchronous task to ensure that the broker is contacted periodically to hold off the last will message.

ofcourse I mosquitto_sub to the topic that last_will was sent to.
i'll try use the resilient one ( though I kind of worked this issue arround )

[guyd]

The last will also works with a keepalive time of zero. It's then up to the broker to decide when it deems the client to be inactive and send its last will. In most cases that will be when the TCP connection between the client and the broker is closed / lost without a prior DISCONNECT control packet from the client .

in my case- broken did not send any last will message ( and YEs I was mosquitto_sub to same topic on a different terminal)

[SpotlightKid]

How did you disconnect the client?

[guyd]

How did you disconnect the client?

it is an ESP8266- I just pulled out the USB cable to power off

[guyd]

a quick look for 2 hour span.
1 device- the only one that last_will is defined in code, spits "last_will" from time to time - to the topic I'm monitoring, and No the device is not powered off and back on, since in that case a boot up message should have been shown ( as first line in quoted output below ):

Code: Select all

[2018-09-13 17:23:42.03] [HomePi/Dvir/Windows/kRoomWindow] Boot- Broker IP: [192.168.2.200], device ip: [192.168.2.128]
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
[2018-09-13 17:45:21.03] [HomePi/Dvir/Windows/pRoomWindow] Button Switch: [OFF]
[2018-09-13 17:45:21.03] [HomePi/Dvir/Windows/pRoomWindow] Button Switch: [UP]
last_will
last_will
last_will
last_will
last_will
last_will
[2018-09-13 17:53:01.03] [HomePi/Dvir/Windows/kRoomWindow] Status CMD: Button_UP:[0], Relay_UP:[0], Button_Down:[0], Relay_Down:[0]
[2018-09-13 17:54:29.03] [HomePi/Dvir/Windows/pRoomWindow] Status CMD: Button_UP:[1], Relay_UP:[1], Button_Down:[0], Relay_Down:[0]
[2018-09-13 17:54:29.03] [HomePi/Dvir/Windows/fRoomWindow] Status CMD: Button_UP:[0], Relay_UP:[0], Button_Down:[0], Relay_Down:[0]
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
last_will
[2018-09-13 19:53:05.03] [HomePi/Dvir/Windows/fRoomWindow] Button Switch: [UP]