core: Octoprint Sensors Read Unavailable when printer is off

The problem

Before OctoPrint was an Integration you could set the tool and the bed this way even if the printer was off you would not receive an “Entity is currently unavailable”

Please can this be fixed.

What version of Home Assistant Core has the issue?

core-2021.11.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

No response

Link to integration documentation on our website

https://www.home-assistant.io/integrations/octoprint/

Example YAML snippet

octoprint:
  host: 192.168.0.XX
  api_key: XXXXXXXXX
  name: Ender 3V2
  number_of_tools: 1
  bed: 1

Anything in the logs that might be useful for us?

No response

Additional information

When it was YAML configured number of tools and bed could be configured as well as the name of the printer

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 4
  • Comments: 16 (4 by maintainers)

Most upvoted comments

@rfleming71: There is a confusion between the state of Octoprint and that of the printer.

Case 1: Printer = off ; Octoprint = reachable Case 2: Octoprint = unreachable

  • In case 1, we expect sensors to pass on the values from Octoprint. That is “-” and “0” (“Printed: -” ; “Bed temp: 0.0ºC”) and “State: Offline” for the printer itself. The printer is offline, the UI stays pretty 🤗 Awesome, right? 🎉

  • In case 2, marking printer sensors as unavailable shows “Unavailable” all over the dashboard (3 times in my case). This makes for a poor user experience 😢 Plus, it freaks us out the first time we see this because all sensors are red in the Entities list (unavailable, restored). 😱 😱 😱 What’s wrong with my configuration?!? You get the feeling 😉

I took a quick look at the sensors from the integration. They are all focused on the printer and the print job. How about adding a sensor that would reflect the reachability of Octoprint’s server? Something like “server_current_state” ? States could be “reachable, unreachable, unavailable”. Unavailable would be for when there’s an error with the integration (like all other integrations), “unreachable” for when the integration works but there’s no response from Octoprint, and “reachable” for, well… when we’re riding on awesomeness and everything works 💪🏻 🎉

Thoughts?

I’m finding this an issue myself.

If the OctoPrint server is online and available but the printer is off, I would much rather have the current state as “Offline” or “Disconnected” instead of “Unavailable”. It does not look nice and is quite confusing since “Unavailable” usually implies that the server is offline, which it is not.

So is there a way i can go back to the original config.Yamal settings, as this integration is taking over and supplying an ugly look to the front end. Agree or disagree with me all you want, but but being forced into using something that is ugly is not an option. At least make something that you can code into the display of a gauge like Offline, or Unavailable, but to leave it as that ERROR, is unsightly.

On 2021/11/18 14:20, Ryan Fleming wrote:

I understand what you are asking for, I just disagree with it. If the server cannot be be access for due to it being off or a networking issue, the whole integration is offline. The sensor has no meaning when the server cannot be accessed. 0 would not be an accurate value to report as we don’t actually know what the value is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/59552#issuecomment-972815846, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGEIOCVYMXBH76JOQWMK3Z3UMTVP5ANCNFSM5H25EV5A. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I understand what you are asking for, I just disagree with it. If the server cannot be be access for due to it being off or a networking issue, the whole integration is offline. The sensor has no meaning when the server cannot be accessed. 0 would not be an accurate value to report as we don’t actually know what the value is.