Options flow crashes on recent Home Assistant: config_entry property has no setter

[Kayhofm]

On recent Home Assistant versions, opening the integration options causes:

Config flow could not be loaded: 500 Internal Server Error

Traceback:
AttributeError: property 'config_entry' of 'OptionsFlowHandler' object has no setter

Root cause:
In config_flow.py, OptionsFlowHandler.init assigns:
self.config_entry = config_entry

But config_entry is now a read-only property in HA.

Workaround / fix:
Rename the attribute, e.g.
self._config_entry = config_entry
and update references accordingly.

Integration works otherwise; only the options/config UI crashes.

HAOS, HA Core Version

[dlarrick]

Thanks.

I need to rewrite the config flow entirely in light of dlarrick/pykumo#58 but it sounds like this is worth fixing in the interim.

I'm out of time for HA work this weekend though so don't expect a quick fix. Pull requests welcome :-)

[kut]

Hey @Kayhofm @dlarrick I'm seeing the above error as well as the below error (pasted below) on HA startup as well as integration reload now, is this what you're experiencing too? Integration has stopped working for me since a reboot a couple of hours ago but I don't know if this is just another Kumo outage or related to the issue you're describing.

(Same HA environment as @Kayhofm)

Logger: homeassistant.config_entries
Source: config_entries.py:762
First occurred: 1:26:29 AM (3 occurrences)
Last logged: 1:48:23 AM

Setup of config entry 'xxxxxxxxxx@gmail.com' for kumo integration cancelled
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 762, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/kumo/__init__.py", line 98, in async_setup_entry
    pykumos = await hass.async_add_executor_job(account.make_pykumos, timeouts, True)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
asyncio.exceptions.CancelledError: Global task timeout: Bootstrap stage 2 timeout

[rmpratt1]

Hey @Kayhofm @dlarrick I'm seeing the above error as well as the below error (pasted below) on HA startup as well as integration reload now, is this what you're experiencing too? Integration has stopped working for me since a reboot a couple of hours ago but I don't know if this is just another Kumo outage or related to the issue you're describing.

(Same HA environment as @Kayhofm)

Logger: homeassistant.config_entries
Source: config_entries.py:762
First occurred: 1:26:29 AM (3 occurrences)
Last logged: 1:48:23 AM

Setup of config entry 'xxxxxxxxxx@gmail.com' for kumo integration cancelled
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 762, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/kumo/__init__.py", line 98, in async_setup_entry
    pykumos = await hass.async_add_executor_job(account.make_pykumos, timeouts, True)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
asyncio.exceptions.CancelledError: Global task timeout: Bootstrap stage 2 timeout

I’m experiencing the same issue.

[dlarrick]

The steps at Interactive Use of pykumo are able to get account info from the cloud for me this evening. But if it's hitting their old service there may well be poor availability. (Accessing the indoor units from my dev system is not working though my production HomeAssistant is OK, but this seems like another issue, a step or two beyond what's shown in this ticket).

If any users have not switched to "prefer_cache=True" as recommended in the README here, it seems time may be of the essence, at least until I can get time to finish out dlarrick/pykumo#58

[dlarrick]

I think I fixed this in 0.4.0-beta2 . Can you confirm?

[arkzrlo]

Fixed for me on 0.4.0-beta-2