Broken with Home Assistant 2023.3.0: menu reappears as "Loading..."

[celeduc]

Home Assistant 2023.3.0 Supervisor 2023.01.1 Operating System 9.5 Frontend 20230301.0 - latest

[flavioxavier]

Same behaviour here, showing loading

[benquan]

Have been trying to solve this but can't seem to solve it. The frontend has changed how it searches for Home Assistant Cloud. Any help aprecieted.

[rpouetpouet]

Thanks for keeping us posted! Hope somebody will help you on that. Or just the HA team will provide an official solution...

[dafunkydan]

I highly doubt HA help with that, given that they want to force the users to go cloud, and in the past refused to accept a PR for Users to decide. I wouldn't be surprised, if the recent change is somehow related to that great Addon.

I want to thank benquan for his great work, and hope that it isn't dead, but somehow adaptable.

[celeduc]

"Never ascribe to malice that which can be explained by incompetence" but in this case it sure feels like a targeted strike.

It's a pity. I'm a paying customer of theirs, but having multiple installations is extremely inconvenient in cloud and android mobile.

Oh well, all commercial open source software eventually succumbs to enshittification and requires a fork. I just didn't expect the horizon to be that close.

[PaulSchulz]

Given that I was able to use the code here to remove the cloud component from the config menu, what would I need to modify in the official 'homeassistant' cloud component code to do the same thing? (Approach 1)

There appears to be a bunch of code in this builtin component that the rest of the core now relies on. Watching the logs when starting up with benquan's code gives a list of errors from elements that are now required.. (see below). Maybe we can implement these elements with some minimal functions to remove the errors. (Approach 2)

I dont yet understand the Python code enough to do this myself.

2023-03-19 21:26:59.298 ERROR (MainThread) [homeassistant.setup] Error handling when_setup callback for frontend
Traceback (most recent call last):
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/helpers/network.py", line 295, in _get_cloud_url
    cloud_url = yarl.URL(cast(str, hass.components.cloud.async_remote_ui_url()))
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/loader.py", line 954, in __getattr__
    value = getattr(self._module, attr)
AttributeError: module 'custom_components.cloud' has no attribute 'async_remote_ui_url'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/setup.py", line 420, in when_setup
    await when_setup_cb(hass, component)
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/components/zeroconf/__init__.py", line 200, in _async_zeroconf_hass_start
    await _async_register_hass_zc_service(hass, aio_zc, uuid)
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/components/zeroconf/__init__.py", line 267, in _async_register_hass_zc_service
    params["external_url"] = get_url(hass, allow_internal=False)
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/helpers/network.py", line 156, in get_url
    return _get_external_url(
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/helpers/network.py", line 285, in _get_external_url
    return _get_cloud_url(hass, require_current_request=require_current_request)
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/helpers/network.py", line 296, in _get_cloud_url
    except hass.components.cloud.CloudNotAvailable as err:
  File "/home/paul/Documents/git/home-assistant-core/homeassistant/loader.py", line 954, in __getattr__
    value = getattr(self._module, attr)
AttributeError: module 'custom_components.cloud' has no attribute 'CloudNotAvailable'

[bkbartk]

this PR works for me https://github.com/benquan/cloud/pull/2

edit: only now I have this message where I'm not sure I'm happy with,

[daveyijzermans]

Surely, it must be possible to hide the offending list item with either JavaScript or CSS? Something that applies a display: none to the right selector when on the settings page? Custom component takes care of disabling the cloud back-end, and some other code to hide it on the front end?

[Progaros]

Surely, it must be possible to hide the offending list item with either JavaScript or CSS? Something that applies a display: none to the right selector when on the settings page? Custom component takes care of disabling the cloud back-end, and some other code to hide it on the front end?

A better approach would be to suppress this cloud related warning internally.

If that invalid config message had any side effects (now or at some point in the future), the display:none wouldn't prevent them

[richard-scott]

Remove this repo, and try mine if you want: https://github.com/richard-scott/cloud

[benquan]

Tried @richard-scott repo and does work. No sure I can follow the whole process, but I do get a basic idea of what its doing. Please use that one.

[bkbartk]

tried that one as well, and it seems to work @richard-scott can you enable issues on your git, just in case someone has an issue? and one question, if the default config changes in core, I assume an update on your side will be required to have the changes applied as well?

[richard-scott]

Sure, I can enable issues.

The process runs via the GitHub actions workflow and will (eventually) get updated automatically each time upstream makes a release and the files we need get changed.

Currently that part is manual, but I’m an active user of HA so will keep on top of it 👍

[ThomDietrich]

I'll wait till https://github.com/benquan/cloud/pull/3 is merged. Thanks @richard-scott for your work!

[richard-scott]

I've updated my PR to include a bin/update.sh script that does the grunt of the work... you can run this manually if you desire.

@benquan there is also a GitHub Action that will also run this script for you. That's currently set to run at midnight each day.

[abjugard]

I made this!

[richard-scott]

@abjugard Thanks for the link. The difference with your project to this is that you have to manually edit your default config file and this is what some people do not want to worry about. Nice idea tho.

[abjugard]

@abjugard Thanks for the link. The difference with your project to this is that you have to manually edit your default config file and this is what some people do not want to worry about. Nice idea tho.

Well, the problem for me was that I wanted to still keep tracking the default config automatically, even if it changes upstream. This way I can still do that, just without the cloud component loaded.

Now I can just replace:

default_config:

With:

mostly_default_config:
  excepting:
    - cloud

[ThomDietrich]

Hey @abjugard, that is a great idea. I might adapt it. Some immediate thoughts:

1. Your README does not talk about the fact that one first needs to add your custom component to their setup/file structure. Seems obvious to experienced users but I can already see people destroying their setup because default_config is missing from their config, with nothing defined replacing it...
2. You are using the keyword excepting. I don't know your background but this is the first time I am seeing this word used where the rest of the software world, including many other components in the Home Assistant ecosystem would use "exclude". Also see this interesting piece of work https://github.com/timvieira/justified-variables#7

[abjugard]

Hey @abjugard, that is a great idea. I might adapt it. Some immediate thoughts:

1. Your README does not talk about the fact that one first needs to add your custom component to their setup/file structure. Seems obvious to experienced users but I can already see people destroying their setup because default_config is missing from their config, with nothing defined replacing it...
2. You are using the keyword excepting. I don't know your background but this is the first time I am seeing this word used where the rest of the software world, including many other components in the Home Assistant ecosystem would use "exclude". Also see this interesting piece of work https://github.com/timvieira/justified-variables#7

Hehe, yeah I might change excepting, I wanted to use except, but that's a keyword in Python so then I couldn't name the variable the same, but I think I'll change it to without, that's a pretty descriptive term and the whole config becomes very readable e.g.:

mostly_default_config:
  without:
    - cloud

Good idea to remind people they first need to install my component in order to do so. The README.md was intended to be read in HACS, but I see how it might be confusing to some.

FYI, if you didn't know, it won't actually break the config, as there's a safe mode that engages if certain components are missing from the configuration, however it certainly might still cause totally preventable issues.

[abjugard]

Hmm... it strikes me now that homeassistant.loader has two methods, async_get_integration and async_get_custom_components. If I call my component default_config, might I still be able to access the manifest of the standard default_config through async_get_integration just like I am doing now? If so, there's no reason my component couldn't just be called default_config and all users would need to do is add the without: block, which I could make configurable through the integrations UI.

It's semantics I guess, if you're already tinkering with the config you may use mostly_default_config just as well as default_config.

[ThomDietrich]

Will a normal default_config fail with the unknown key without? If Home Assistant is willing to ignore it I think default_config is great. In any other case the explicit mostly_default_config might also have some benefits.

Just my personal opinion: I would love to see exclude to be consistent. This is one of the daily nuisances with yaml based DSLs these days. You always have to remember the correct identifiers wrt context. For example: Many lovelace cards support headlines. I saw the following keys to set it: name, title, label. It's just tedious :)

[abjugard]

Will a normal default_config fail with the unknown key without? If Home Assistant is willing to ignore it I think default_config is great. In any other case the explicit mostly_default_config might also have some benefits.

Yeah, I'll do some labbing before I decide which way to go here.

Just my personal opinion: I would love to see exclude to be consistent. This is one of the daily nuisances with yaml based DSLs these days. You always have to remember the correct identifiers wrt context. For example: Many lovelace cards support headlines. I saw the following keys to set it: name, title, label. It's just tedious :)

Alright, I'll make it exclude 🙂

[bkbartk]

Will a normal default_config fail with the unknown key without? If Home Assistant is willing to ignore it I think default_config is great. In any other case the explicit mostly_default_config might also have some benefits.

I think the key will be ignored

default_config:
  exclude:
    - cloud

or at least it would be able to start

I did not install the new solution on HACS

[abjugard]

Will a normal default_config fail with the unknown key without? If Home Assistant is willing to ignore it I think default_config is great. In any other case the explicit mostly_default_config might also have some benefits.

I think the key will be ignored

default_config:
  exclude:
    - cloud

or at least it would be able to start

I did not install the new solution on HACS

Good to know! I think I'll keep it as mostly_default_config for now. Version 1.1 is up there now and uses exclude instead of eXcEpTiNg 🤡

Anyway, I'm gonna stop spamming this issue now, you're all free to use my solution if you wish, I'll be maintaining it because I need it myself.

Might add some failsafe code which logs an error and defaults to the regular default_config if any errors happen. It could be made nearly crash proof using importlib and a try/catch around all of the code, with await async_setup_component(hass, DEFAULT_CONFIG, config) in the catch block, maybe I'll do that for 1.2.

[OdinVex]

entrypoint: /bin/sh -c "sed -i 's/\"cloud\",//g' /usr/src/homeassistant/homeassistant/components/default_config/manifest.json; sed -i 's/\"mobile_app\",//g' /usr/src/homeassistant/homeassistant/components/default_config/manifest.json; /init"

Now you don't need to mess with anything, you can keep the default_config and not have to worry about whether it's got cloud or mobile_app enabled (removed automatically) and you can get new stuff as they come along. Update it as you want things removed that have the fascist cloud crap forced. (Edit: You don't need anything else. Not this plugin, nothing. This works for Docker or any means of starting (adjust it to your service or whatever and use correct location...).

Edit: Let's time how long until Nabu Casa makes the cloud a requirement. At that point I'd suggest forking and using workflows to pull upstream to patch and build.

[richard-scott]

I did not install the new solution on HACS

use HACS it will save your sanity 👍