Last will on umqtt.simple

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
SpotlightKid
Posts: 380
Joined: Wed Apr 08, 2015 5:19 am

Re: Last will on umqtt.simple

Post by SpotlightKid » Wed Sep 12, 2018 5:02 pm

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
Posts: 81
Joined: Fri Jul 20, 2018 6:08 am

Re: Last will on umqtt.simple

Post by guyd » Thu Sep 13, 2018 4:48 am

pythoncoder wrote:
Wed Sep 12, 2018 4:56 pm
One way to test this is to run mosquitto_sub on a PC on the network.
and how to get the last will message?

User avatar
pythoncoder
Posts: 3538
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Last will on umqtt.simple

Post by pythoncoder » Thu Sep 13, 2018 8:31 am

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.
Peter Hinch

SpotlightKid
Posts: 380
Joined: Wed Apr 08, 2015 5:19 am

Re: Last will on umqtt.simple

Post by SpotlightKid » Thu Sep 13, 2018 8:42 am

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 .

User avatar
pythoncoder
Posts: 3538
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Last will on umqtt.simple

Post by pythoncoder » Thu Sep 13, 2018 9:05 am

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.
Peter Hinch

guyd
Posts: 81
Joined: Fri Jul 20, 2018 6:08 am

Re: Last will on umqtt.simple

Post by guyd » Thu Sep 13, 2018 10:37 am

pythoncoder wrote:
Thu Sep 13, 2018 8:31 am
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
Posts: 81
Joined: Fri Jul 20, 2018 6:08 am

Re: Last will on umqtt.simple

Post by guyd » Thu Sep 13, 2018 10:39 am

SpotlightKid wrote:
Thu Sep 13, 2018 8:42 am
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
Posts: 380
Joined: Wed Apr 08, 2015 5:19 am

Re: Last will on umqtt.simple

Post by SpotlightKid » Thu Sep 13, 2018 12:43 pm

How did you disconnect the client?

guyd
Posts: 81
Joined: Fri Jul 20, 2018 6:08 am

Re: Last will on umqtt.simple

Post by guyd » Thu Sep 13, 2018 1:22 pm

SpotlightKid wrote:
Thu Sep 13, 2018 12:43 pm
How did you disconnect the client?
it is an ESP8266- I just pulled out the USB cable to power off

guyd
Posts: 81
Joined: Fri Jul 20, 2018 6:08 am

Re: Last will on umqtt.simple

Post by guyd » Thu Sep 13, 2018 4:59 pm

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]

Post Reply