Last will on umqtt.simple
-
- Posts: 463
- Joined: Wed Apr 08, 2015 5:19 am
Re: Last will on umqtt.simple
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.
Re: Last will on umqtt.simple
and how to get the last will message?pythoncoder wrote: ↑Wed Sep 12, 2018 4:56 pmOne way to test this is to run mosquitto_sub on a PC on the network.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Last will on umqtt.simple
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.
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
Index to my micropython libraries.
Index to my micropython libraries.
-
- Posts: 463
- Joined: Wed Apr 08, 2015 5:19 am
Re: Last will on umqtt.simple
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
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Last will on umqtt.simple
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.
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
Index to my micropython libraries.
Index to my micropython libraries.
Re: Last will on umqtt.simple
ofcourse I mosquitto_sub to the topic that last_will was sent to.pythoncoder wrote: ↑Thu Sep 13, 2018 8:31 amIf 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.
i'll try use the resilient one ( though I kind of worked this issue arround )
Re: Last will on umqtt.simple
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 wrote: ↑Thu Sep 13, 2018 8:42 amThe 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 .
-
- Posts: 463
- Joined: Wed Apr 08, 2015 5:19 am
Re: Last will on umqtt.simple
How did you disconnect the client?
Re: Last will on umqtt.simple
it is an ESP8266- I just pulled out the USB cable to power off
Re: Last will on umqtt.simple
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 ):
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]