OctoPrint-MQTT
OctoPrint-MQTT copied to clipboard
OctoPrint
Is there a manual way to force an update of LWT by MQTT
I have an automation that sends out a broadcast message to my smart devices on Home Assistant reboot to get their status w/o waiting for telemetry from them. Can a similar command be published to your plugin to force it to issue a LWT update? I know I'll probably have to manually add some kind of subscription entry to a config file.
What were you doing?
Power cut this morning caused a device on my LAN to freak out and it hosed the whole thing. Once I got the trouble isolated I noticed the Pi was showing "Off" for printing status in HA, but all other data was showing "Unavailable."
Ideally provide exact steps to follow in order to reproduce your problem: -->
Last time this happened I loaded MQTT Explorer and saw that the Pi was still sending JSON data as expected. The LWT in Home Assistant had not received the "Connected" status from the Pi. Typically I have to reboot the Octopi to update the status. Rebooting HA doesn't fix the status.
What did you expect to happen?
The JSON data in HA should have begun to populate once the network was restored.
What happened instead?
Once I got the trouble isolated I noticed the Pi was showing "Off" for printing status (as expected) in HA, but all other data was showing "Unavailable."
Version of OctoPrint
1.3.11
Version of the MQTT plugin
0.8.6
Used MQTT broker and its version
This seems to happen when I have to restart Home Assistant on the Pi. I can publish "connected" through a 3rd party app on the PC, but what I'd like is to be able to query Octoprint for it's status when the service reboots. I have this on my sonoff/tasmota devices through an automation that runs at boot. Is there an mqtt message I can publish to this plugin to get it to update the LWT state?
How are you guys handling OctoPrint in Home Assistant, with this plugin? I'm tired of the API, where it's not handling things as it should, if i restart HA, while a print is ongoing, and other things, like that.
So; What are you guys doing :)?
I am seeing what is possibly the same problem, The LWT connected is not working reliably after a break in connection. If I stop Octoprint then I see the 'disconnected' message on the LWT topic and if I restart Octoprint then I see the 'connected' message, which is as it should be. However if I disable the network connection between the Octoprint server and the MQTT broker then the broker correctly publishes the 'disconnected' LWT message, but when I reconnect the network I do not see a connected message, instead I see another 'disconnected' message. The situation @ProfEngr is seeing is similar. He has retained topics enabled so any time a client subscribes to that whilst Octoprint is connected to the MQTT server then he/she should see 'connected' but if I interpret his issue correctly he is not seeing that.
Having done some debugging the problem appears to be that the connected message is sent in mqtt_connect() which is ok for the initial connection. However mqtt_connect() is not called on a re-connect after, for example, a temporary network failure. I believe that the connected publish should instead be in _on_mqtt_connect(). Hacking in a publish of 'connected' to the LWT topic before the logger info message "Connected to mqtt broker" appears to fix the issue.
I have submitted an issue for the LWT connected failure on re-connect. Issue #77
Actually I think this issue is also caused by #94 and isn't fixed yet. I pushed a PR #100 though, and since the reconnect message was already corrected I think will resolve the remaining cases. Note: this issue only happens when retain isn't being used globally.
FWIW: Rebroadcasting LWT on request isn't exactly the right solution. LWT has a specific meaning in MQTT for tracking state. If you continue to have the problem after these fixes you should also set a static client id. It is possible (though I think unlikely) for the OctoPrint server connection to the broker to timeout, reconnect with a new client id then post the connected state before the LWT disconnected is published and retained. It can mix things up. A static client ID should force a disconnect and LWT before the reconnect preventing this issue I believe.
Client ID is static. I had to turn global retain off in this plugin due to an issue w/ MQTT-Publish sending retain flags w/ a switch command I had set up in it. One of my LED strings would sometimes turn itself on w/o "reason" after a wifi glitch. The Pi is wired, but the ESP controlling the LED strip is wifi. Doesn't make sense to me why the other plugin was affected by this one, but turning off retain fixed the issue.
Edit: Enabled the global retain flag again. Toggled the LED control and MQTT Explorer doesn't show the retain flag anymore. Must have been more days that I thought since I changed things. Must have been before the last update. I don't see a retain flag on the LWT however. Shouldn't there be?
@ProfEngr the case you described should be fixed then by #100 once it is merged and released. LWTT has its own option for retain, which you should set to enable, and then you can leave the global settings disabled.