Octoprint: can't set up without enabling the Discovery plugin

[scgtrp]

The problem

I have an Octoprint instance without Discovery enabled. I do not want to enable Discovery, and I am comfortable with handling API keys.

Previously (before October), I could just provide a URL and an API key, and it would just work.

This is no longer an option; the integration configuration flow requires using Discovery, despite there being code there to handle the case of entering an API key.

What version of Home Assistant Core has the issue?

2022.3.6

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Octoprint

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

I did try temporarily enabling Discovery, but I never got the confirmation popup on the Octoprint side. I suspect this is my network being locked down and/or weird in some way rather than a bug in either software. Regardless, I would like to not need to do this.

[probot-home-assistant[bot]]

octoprint documentation octoprint source _{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @rfleming71, mind taking a look at this issue as it has been labeled with an integration (octoprint) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[rfleming71]

Try turning the discovery plugin on and then manually adding it in octoprint. The integration is just attempting to grab the UUID from the server, you should be able to disable the discovery plugin after that. Working on a method to get around the need for this, but not quite ready yet.

[onkelbeh]

First, thanks for this cool component.

Since deprecation of the YAML config, something strange here (now on Home Assitant 2022.4.1). Seems that some part of the old YAML config has been imported, but the Integration itself is NOT listed in Configuration -> Integrations. Think something went wrong with the import of the YAML.

Did not use the printer for a couple of weeks, and then, at first, all related entities have been 'unavailable'.

Tried to re-install it with the UI config flow, no request for the Key was shown in Octoprint, and the config flow waited for approval.

Octoprint was not discovered, manual installation showed again no request in Octoprint. A lot of Octoprints topics can be seen in MQTT under /homeassistant. Then, after reading this issue, I turned discovery on (in HA) and I messed up with 100s of dupe entities (most from zigbee).

Since the (unsuccessful config flow), many of it's entities now show up in Home Assistant again, but I believe that something is not like it should be, though it is working now.

For now, I can live with that, but this is something that should be cleaned up / repaired.

[Kilill]

Automatic discovery/configurations is cool and all, but there should definitely be an override for when all information is known and/or one does not want to have the discovery plugin enabled

[somehibs]

Entire integration does not work for me. Even with automatic discovery enabled. Used to work when I had it configured via YAML, which doesn't seem to work either. I assume updating to Octoprint 1.8.1 has caused some API incompatibility. I also have HomeAssistant configured with a read-only account, so if there's a new requirement for an administrative API key, that has not been made clear anywhere.

[tre4b]

This plugin does not work for me either because the discovery does not work and manual override is not available. HA discovers a new integration but when I try and configure it says it failed to retrieve an API key. As I cannot provide the key maunally this means I cannot use the integration.

Discovery is turned on but does not seem to do anything. Nothing pops up at all and I have checked the allow popups in the printer notification pluggin.

It feels like even if using discovery is preferable adding an advanced option to the pluggin that allowed Manual input of the API key would help.

[MrBrown666]

Both my main printers are Vorons and are running Mainsail, not Octoprint. Mainsail or alternatives like Fluidd are simply way better streamlined and optimized for klipper compared to using Octoprint with the OctoKlipper plugin.

Yet this issue still applies to Mainsail as it contains Moonraker API, which has the option to expose a partial Octoprint API. The relevant difference is that it does not require an API key (or rather accepts any key) and discovery is not available.

I had connected these printers to Home Assistant with the old YAML config without problems. But since the new integration requires discovery I cannot connect my printers anymore. This effectively locks out large portions of the Voron community and similar klipper based projects.

I would greatly appreciate if there was an advanced option to just use IP/hostname and an API key during setup.

[Gyosa3]

Hi I wanted to add another use case where this integration does not work when it could:

My home assistant and printers are not in the same network and both hosts are using Tailscale VPN to connect. They perfectly see each other network-wise but discovery/bonjour/upnp and the like do not cross the VPN.

The only way for me to add the printer to HA is to generate a key before and add the printer using the key generated, which is not an option is the config screen. So I'm stuck.

If there's any opportunity to have an option to declare the printer via IP address and Application key, that would be fantastic! Thanks :)

Thanks!

[Gyosa3]

OK, I browsed rapidly in the code, it is what I understand:

Step 1: you show the config panel where data is to be entered (but not input for the App key); Step 2: when the user validated the config you try to get the App key via

          return await self.async_step_get_api_key(user_input)

where it does

           try:
            user_input[CONF_API_KEY] = await octoprint.request_app_key(
                "Home Assistant", user_input[CONF_USERNAME], 300
            )

Already it is weird, because I have created an App key in Octoprint for application "Home Assistant" and the given user but it fails to retrieve it anyway. That probably involves the Discovery plugin and local discovery protocols that do not cross my VPN.

So I went a bit further and caught your comment:

        # When coming back from the progress steps, the user_input is stored in the
        # instance variable instead of being passed in

And it is interesting because when you loop back and the CONF_API_KEY is already populated you skip the key discovery part and jump directly to the end of the config!

      if CONF_API_KEY in user_input:
            errors = {}
            try:
                return await self._finish_config(user_input)

So I was thinking, but maybe it is too simplistic, for those of us who manage their App key in Octoprint directly, would this be as simple as adding an input field "App Key (if you have it already)" as Optional, and if the user provides the key in this field, then it would do exactly as you intended to, it will skip key discovery and just finalise the setup.

Or am I too simplistic? If you think it can work I can fork the code and propose a change to config_flow.py that you can review later on if that helps.

[AndreRH]

same issue here with 2022.9.2

[ciaranmcnulty]

This doesn't work for me because I'm running Octoprint and HA in containers on different machines; it's not possible to make it discoverable on the network the way this auto-discovery wants it to be.

I'd really appreciate the ability to just copy paste an application key

[tre4b]

For me the printer keeps getting discovered but the API key is never returned, no matter what I try. The octoprint intstance never asks me to confirm, and after a few moments the integration stops trying. It is annoying as I could just give it an API key if there was a way to do so.

[ciaranmcnulty]

I did eventually get this to work through reconfiguring the proxy etc but the steps were specific to my setup

Discovery is great but a manual fallback via a tiny link in the corner would help a lot if it doesn't work immediately :)

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[scgtrp]

I have just updated to 2023.1.5 and this does not appear to have changed.

[AndreRH]

seems to work for me now in 2023.2.5, can anyone confirm or was it just by luck?

[scgtrp]

@AndreRH Are you saying that Discovery now works for you, or that you now have a place to enter an API key? This issue is about the latter, which doesn't appear to have changed, and I see nothing in the commit history to suggest it should have.

[AndreRH]

HA detected OP as always, but now the automatic auth worked, because the popup dialogue on OP appeared. That's the detection I'd say.

[Kilill]

Tested on HA: 2023.3.1 OctoPrint: 1.8.7

Automatic setup works IF:

1. the Discovery plugin is installed and enabled.
2. "Enable Popups" in the Printer Notification plugin is set.
3. You are logged in on the octoprint webpage as the user that HA is to use.

In this case, HA will find and add it on the integration page with a "Configure" entry, adding the above user and accepting it will pop the authorization window on the octoprint page , accept that and HA completes the setup.

What does not work:

Is trying to set this up without the Discovery running and just trying to configure it manually. It seems to be something with name resolution, since trying to enter a host name fails immediately while using an ip address will will fail with an "unexpected" error, and the logs does not show anything of interest, and there is never a auth popup on the octo print page.

So it would still be nice to have a field for the API key on the configuration page....

[ciaranmcnulty]

In my case I know exactly why discovery isn't working - octoprint is in a container with very locked down ports.

As someone who 'knows what they are doing' I want a route to enter the correct configuration directly.

This is not an Issue about the various times discovery won't work, it's about offering an alternative without it

[disconn3ct]

For added fun, it doesn't even log the error if discovery is not enabled. It just shows "Unexpected error" and nothing in the logs.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[claycooper]

I'm seeing this issue with the latest Octoprint and Home Assistant. Manual setup leads to "Unexpected error".

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[claycooper]

Same issue on Home Assistant 2023.9.2

Error is:

2023-09-17 17:04:40.651 ERROR (MainThread) [homeassistant.components.octoprint.config_flow] Failed to get an application key : Server disconnected
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/octoprint/config_flow.py", line 113, in async_step_get_api_key
    await self.api_key_task
  File "/usr/src/homeassistant/homeassistant/components/octoprint/config_flow.py", line 250, in _async_get_auth_key
    user_input[CONF_API_KEY] = await octoprint.request_app_key(
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyoctoprintapi/octoprint_client.py", line 32, in request_app_key
    if not await self._api.check_appkeys_enabled():
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyoctoprintapi/api.py", line 60, in check_appkeys_enabled
    response = await self._session.get(self._base_url + APPKEY_PROBE_ENDPOINT)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/client.py", line 560, in _request
    await resp.start(conn)
  File "/usr/local/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 899, in start
    message, payload = await protocol.read()  # type: ignore[union-attr]
                       ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/streams.py", line 616, in read
    await self._waiter
aiohttp.client_exceptions.ServerDisconnectedError: Server disconnected

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.