Last Will not working on my side

#1

Hello,
i have an issue with receiving LWT messages.
From the Will inspector i can see my devices using the topic device_name/alive, QoS 0, retain and Msg “timeout”.
I have a paho-client running in python which is subscribed to those device_name/alive topics as reported in the hub.
If i restart my devices i’m not receiving anything on that paho client.
If i subscribe to a normal channel the paho-client receive the information normally though.

I might be missing something but my assumption is that the LWT shall be sent by myqtthub as soon as there is an ungraceful disconnection like a normal message.
Am i missing something?

as per

i’ve tried

./mosquitto_sub.exe
    -h node02.myqtthub.com
    -i ****
    -u ****
    -P '****'
    -t 'device/test'
    -q 2
    -d
    --will-topic 'device/alive'
    --will-retain
    --will-qos 2
    --will-payload 'Device stopped without clean disconnect'

but nothing got listed in “Last” tab in my domain after Ctrl-C is issued

#2

Any help is appreciated @anon79473925

#3

Hello,

You are following steps as expected to generate a will message. Possibly, the problem comes from that Control-C.

Maybe, for some reason, your terminal is grabing that keystroke, and redirecting it to your application as a graceful termination signal, and hence, your mosquitto_sub finishes ok sending DISCONNECT, and thus, causing that will to not be fired.

We have created several tests using mosquitto_sub just like you and works as expected:

   >> mosquitto_sub -h node02.myqtthub.com -i xxx.consumer.example1.xxx -u xxxx.consumer.example1.xxx -P 'xxxx' -t 'gestion/#' -q 2 -d --will-qos 2 --will-topic 'device/alive' --will-retain --will-payload '667: Device 000a failed without proper connection'

…after pressing control-C (here a Linux terminal) we see will published in your Last record as expected.

Also, we see will configured at the Will Inspector just after it connects with mosquitto_sub.

Best Regards,

#4

Hello,
My devices are embedded so the mosquito test was only to prove it was not working on x86 as well.
I do have 3x ESP32 and I’m calling a straight ESP.restart() without proper connection closure.
I’ll try in Linux as well and let you know.

#5

Hello,
I’ve tried with Linux terminal and while ctrl-c on mosquitto command is still sending DISCONNECT packet if i kill the process with SIGSEV the LWT is correctly registered on the portal.
My only guess is that ESP.Restart() is somehow gracefully disconnecting the broker before restarting the uC.
In a real case scenario (uC hangs, WiFi connection is lost, ISP is down) it will probably work.
I guess i will try to cut the power entirely

@anon77475845
REST API POST /devices/connected shows the list of connected devices, can one subscribe to /devices/connected via MQTT to have access to the same information?
Do you have the list of myqtthub default subscribeable channels?

#6

anyone can help with my last question?

#7

Hello,

REST API POST /devices/connected shows the list of connected devices, can one subscribe to /devices/connected via MQTT to have access to the same information?

Currently, there is no support for such interaction. See related info about this: Is it possible to access /devices/connected from a device which is not the domain admin?

Do you have the list of myqtthub default subscribeable channels?

Assuming you are talking about channels like topics, just confirm in MQTT, there is no such concept. A topic does not exists in an independent form or needs to be declared before hand… you just announce messages with a certain topics, and they are routed to subscriberss according to topic filters.

As you can see, there is no way for the platform to know what will be the list of topic that your publishers will use. This is something that is under control by publishers and also, in collaboration with subcribers (otherwise, information will not flow from publishers to subscribers).

Best Regards,