Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entities Unavailable after HASS Restart #55

Closed
Yukigamine opened this issue Dec 21, 2020 · 25 comments
Closed

Entities Unavailable after HASS Restart #55

Yukigamine opened this issue Dec 21, 2020 · 25 comments
Assignees
Labels
bug Something isn't working

Comments

@Yukigamine
Copy link

Yukigamine commented Dec 21, 2020

I'm not sure if this is an issue with my Octoprint setup, HASS setup, or MQTT setup, but since this is where those three meet, I figured I'd start looking around here to see if you can help.

When I restart Home Assistant, OR if I go for too long without printing anything, the entities that this plugin allows Home Assistant to discover become unavailable. Once this happens, the only way to fix it is to restart Octoprint. Not even starting a new print or having one going at the time will refresh things. (Which isn't ideal if I happen to restart Home Assistant during a multi-day print)

I believe the issue is that the MQTT messages time out after a while or get discarded and for some reason it stops pulling in new ones that may be published? However, I am honestly not sure whether it is this plugin or the main MQTT plugin that causes the majority of information to be published to the broker.

EDIT: I just restarted OctoPrint and used HomeAssistant to listen to the MQTT events for temperature to verify that messages are coming in. Everything seems like it should be working, but everything is still showing unavailable. I'm at a bit of a loss here.

Any help is appreciated. Let me know what logs if any I can get you. Thanks!

image

@Erozionn
Copy link

I am getting the same issue. One thing that works for me as a temporary fix is changing the device name to anything then changing it back. HA will then pick the entities back up.

@Yukigamine
Copy link
Author

Yukigamine commented Dec 24, 2020

I am getting the same issue. One thing that works for me as a temporary fix is changing the device name to anything then changing it back. HA will then pick the entities back up.

Your workaround got it re-integrated for me for now. Cheers!

@Lefey
Copy link

Lefey commented Jan 3, 2021

Same problem, restart octoprint helps.

@charredchar
Copy link

I've been noticing this same issue, a reboot of OctoPrint usually corrects the issue and it shows back up in Home Assistant, issue is when you're in the middle of a print and can't do such a thing...

To double check, I have MQTT subscribed in Node-RED and it still is seeing communication so it isn't that it goes away, just seems what ever method Home Assistant and this Plugin is using to communicate is not reconnecting when HA reboots but does when OctoPrint reboots.

@Yukigamine
Copy link
Author

To double check, I have MQTT subscribed in Node-RED and it still is seeing communication so it isn't that it goes away, just seems what ever method Home Assistant and this Plugin is using to communicate is not reconnecting when HA reboots but does when OctoPrint reboots.

That's what I noticed as well when I was troubleshooting. Octoprint is still publishing new messages. It just seems that the advertisement that associates the devices/entities with the MQTT topics is failing for some reason.

@narfel
Copy link

narfel commented Jan 15, 2021

I'm having the same issue. However i get almost bogus MQTT messages if I don't restart Octoprint, as if it stuck at some sort of timestamp. Funny enough some of the sensors work though. Notably sensor.octoprint_job_percentage,
sensor.octoprint_actual_bed_temp and sensor.octoprint_target_bed_temp. Then again sensor.octoprint_bed_temperature does not work. Maybe some sort of name collision?

@cmroche
Copy link
Owner

cmroche commented Jan 22, 2021

I'm having the same issue. However i get almost bogus MQTT messages if I don't restart Octoprint, as if it stuck at some sort of timestamp.

Can you provide samples of the bogus message please.

@cmroche
Copy link
Owner

cmroche commented Jan 22, 2021

Would someone confirm for me, when this happens, does restarting the home assistant server by itself fix the issue?

Which MQTT integration are you using? Mosquito, or the built-in MQTT service?

Also, please check the MQTT information from the device, in particular the "MQTT" topic, see the screenshot:

image

Expand the messages and copy and paste here please. The latest message you received should always be connected.

@cmroche cmroche added the bug Something isn't working label Jan 22, 2021
@Yukigamine
Copy link
Author

does restarting the home assistant server by itself fix the issue?

Restarting home assistant (or just waiting a few days) is what breaks it.
The current fix seems to be some combination of restarting Octoprint and/or renaming the Octoprint device in HASS Discovery plugin.

Which MQTT integration are you using?

I'm using Mosquito hosted on the same server as HomeAssistant for the MQTT broker. The only integration I know of is the one built into Home Assistant, I couldn't find one specific to Mosquito.

please check the MQTT information from the device, in particular the "MQTT" topic, see the screenshot:

Looks like the "octoPrint/mqtt" topic says "Disconnected", but directly below you can see that values are still being updated to MQTT.

image

Thanks for getting back to us!

@cmroche
Copy link
Owner

cmroche commented Jan 22, 2021

Hmmm, might be an issue with retained if there is no connected message waiting. I tried to run a few different tests locally with restarting both HA and Mosquito, couldn't reproduce a problem myself unfortunately.

In OctoPrint MQTT plugin, would you check the following settings please.

image

@cmroche
Copy link
Owner

cmroche commented Jan 22, 2021

Lol, note I'm changing my password now :D

@narfel
Copy link

narfel commented Jan 22, 2021

Ha, you sacrificed your password for a good cause, though. While smiling about that i realized i had not supplied user/password. Entered credentials: everything showed up in the sensors as it should :)

@Yukigamine
Copy link
Author

My "enable retain flag" button was not checked, so I enabled that.
I also applied your hot fix and rebooted octoPrint which brought everything live again in HomeAssistant.

I also rebooted HomeAssistant and so far everything still seems to be loaded and happy. I'll give it a few days and a few reboots to see if that fixes it!

One other thing of note: the "static client id" setting on my MQTT settings page is checked where yours is not. So I'm not sure if I should mimic that setting or just ride it out and see if it is good now.

@cmroche
Copy link
Owner

cmroche commented Jan 22, 2021

I suspect that the retained flag setting is going to be the common cause of issue, unfortunately a fix for this needs to come from the OctoPrint-MQTT plugin.

I'll investigate if I can add a warning or something in the mean time, and add a note to documentation to help anyone else seeing the same issue.

Thanks for the help everyone.

@cmroche cmroche self-assigned this Jan 22, 2021
@Yukigamine
Copy link
Author

I suspect that the retained flag setting is going to be the common cause of issue, unfortunately a fix for this needs to come from the OctoPrint-MQTT plugin.

So far so good. I'm several reboots into HomeAssistant and it's holding steady. I'm just a little worried about some of my automation getting caught on a retained message and messing up a print (which is why I had that off in the first place). But I'll cross that bridge if it happens at this point.

@cmroche
Copy link
Owner

cmroche commented Mar 27, 2021

PR is pushed to OctoPrint-MQTT to help address this: OctoPrint/OctoPrint-MQTT#100

@Sennevds
Copy link

Sennevds commented Feb 1, 2022

I have another problem when HASS restarts not only my entities become unavailable but when I'm printing the printer stops until HASS is fully started again. Anybody has the same problem?

@RJ-Make
Copy link

RJ-Make commented May 1, 2022

This issue persists for me, even with the latest build and setting set as above.

Setup:
mosquitto 64 bit as a windows service
mosquitto HA Integration (client Only)
HAOS (latest Version)

@cmroche
Copy link
Owner

cmroche commented May 1, 2022

Sounds like a problem with retain sending a pause command on startup. I would recommend that you disable the use of retain in the MQTT plugin, and you might have to manually delete the topics on your MQTT server to clear the retained status.

@cmroche cmroche closed this as completed May 1, 2022
@cmroche cmroche reopened this May 1, 2022
@RJ-Make
Copy link

RJ-Make commented May 1, 2022

Ok, Will make the change and report back, Thank you

@RJ-Make
Copy link

RJ-Make commented May 5, 2022

Sounds like a problem with retain sending a pause command on startup. I would recommend that you disable the use of retain in the MQTT plugin, and you might have to manually delete the topics on your MQTT server to clear the retained status.

Made the changes but the problem persist.

I get other messages from Octoprint, but not from the Plugin (hass)

@RJ-Make
Copy link

RJ-Make commented May 8, 2022

I started a print (which I was getting updated information (after a Octoprint restart of course)) and re-started HA.

Sure enough everything went "Unavailable" in HA, but I'm still seeing the OctoPrint plugin sending information.

Inside HA, Listening to topic mk3octoprint/hass/# I receive this.

Message 0 received on mk3octoprint/hass/printing at 12:41 PM:

{
    "state": {
        "text": "Printing",
        "flags": {
            "operational": true,
            "printing": true,
            "cancelling": false,
            "pausing": false,
            "resuming": false,
            "finishing": false,
            "closedOrError": false,
            "error": false,
            "paused": false,
            "ready": false,
            "sdReady": true
        },
        "error": ""
    },
    "job": {
        "file": {
            "name": "ESP_Home_Sensor_Box_top_0.2mm_ABS_MK3MMU2_2h9m.gcode",
            "path": "ESP_Home_Sensor_Box_top_0.2mm_ABS_MK3MMU2_2h9m.gcode",
            "display": "ESP_Home_Sensor_Box_top_0.2mm_ABS_MK3MMU2_2h9m.gcode",
            "origin": "local",
            "size": 3325321,
            "date": 1652024148
        },
        "estimatedPrintTime": 5759.943530904131,
        "averagePrintTime": null,
        "lastPrintTime": null,
        "filament": {
            "tool0": {
                "length": 8252.02432999782,
                "volume": 19.848444556342244
            }
        },
        "user": "XXXXXXX",
        "estimatedPrintTimeFormatted": "1:35:59"
    },
    "currentZ": 2.2,
    "progress": {
        "completion": 54.12896980471961,
        "filepos": 1799962,
        "printTime": 3781,
        "printTimeLeft": 3533,
        "printTimeLeftOrigin": "linear",
        "printTimeLeftFormatted": "0:58:53",
        "printTimeFormatted": "1:03:01"
    },
    "offsets": {},
    "resends": {
        "count": 0,
        "transmitted": 65962,
        "ratio": 0
    },
    "_timestamp": 1652028110
}

Inside HA

2022-05-08_12-43-17

@TheHolyRoger
Copy link
Contributor

@cmroche as I understand it, MQTT devices should periodically re-send the device registration although I could be wrong there.

I'm not a fan of having the systemwide retain flag on though so with a small patch to your code I made a HA automation to re-send device registration periodically and when entities become unavailable:

alias: '[Ender] Fix Unavailable MQTT'
description: ''
trigger:
  - platform: template
    value_template: '{{ is_state(''binary_sensor.octoprint_printing'', ''unavailable'') }}'
  - platform: time_pattern
    minutes: /8
condition: []
action:
  - service: mqtt.publish
    data:
      topic: octoPrint/mqtt
      payload: connected
mode: single

The only change required was this one to decode the message bytes to string:
https://github.com/cmroche/OctoPrint-HomeAssistant/pull/93/files

@cmroche
Copy link
Owner

cmroche commented Jun 11, 2022

@TheHolyRoger Merged, thanks for looking into this.

@cmroche cmroche closed this as completed Jun 11, 2022
@TheHolyRoger
Copy link
Contributor

@cmroche thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

9 participants