custom-components
Proxy Services broken in HA 2023.6
Proxy Services seems broken in HA 2023.6. I use it to forward evohome_cc services from slave to the main instance. The error on the main is always the same with a random KeyError value. With a browser Home Assistant starts and continuous to work until I hit F5 and it's stuck in an endless loop. The companion app results directly in an endless loop of HA.
Issue on Home Assistant 2023.6.1 docker and core Last working instance: Home Assistant core 2023.5.3
The errors doesn't trace back to proxy services, but after lot's of debugging I narrowed it down to disable the proxy services and made it stable. I also can reproduced the same behavior between 2 different systems in a test environment.
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 26, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 382, in handle_get_services
payload = await _async_get_all_descriptions_json(hass)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 363, in _async_get_all_descriptions_json
descriptions = await async_get_all_descriptions(hass)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 614, in async_get_all_descriptions
domain_yaml = loaded[domain]
~~~~~~^^^^^^^^
KeyError: 'rest'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 26, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 382, in handle_get_services
payload = await _async_get_all_descriptions_json(hass)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 363, in _async_get_all_descriptions_json
descriptions = await async_get_all_descriptions(hass)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 614, in async_get_all_descriptions
domain_yaml = loaded[domain]
~~~~~~^^^^^^^^
KeyError: 'text'
+1 I experienced the same issue and had to revert the upgrade.
In order for me to debug it a bit on my end, did you update HA on both instances (the main one and the remote one) or only one of the two?
Thanks @Wesley-Vos. I think you should look on the main one. I updated the remote one and downgraded the main one to the old version. Then there are no errors.
I conti ue to have this issue. This integration is essential for me. Hopefully there is a workaround.
The only option is to stay on 2023.5.4, upgrading the main HA to 2023.6 or 2023.7 doesn't cause an issue, only when the slaves are upgraded do they fail. This also prevents the front-end from loading, disabling remote home assistant fixes the front end issue
I have researched the problem a bit and came to the following conclusion: if you have the remote home assistant integration installed and are proxying services from the remote instance which are not available on your main instance, it fails and you get the error.
A temporary workaround in my situation was to add the integration from which I was proxying the services in my main instance as well.
I have researched the problem a bit and came to the following conclusion: if you have the remote home assistant integration installed and are proxying services from the remote instance which are not available on your main instance, it fails and you get the error.
A temporary workaround in my situation was to add the integration from which I was proxying the services in my main instance as well.
This completely defeats the purpose. I've built my homeassistants around a single VPS "cloud" homeassistant for cloud connected integrations, and then proxy those entities to each of my home entities that manage mostly local integrations. I don't want to have to maintain the login token for my toyota-na integration in 3 different places.
I conti ue to have this issue. This integration is essential for me. Hopefully there is a workaround.
The only option is to stay on 2023.5.4
Seems to be resolved in v3.9
This was fixed in the latest ha remote update 2023.7.x but is now broken in 2023.8.x
hopefully this doesn't have to be broken for each update into the future
problem solved, BUT now it's there again Home Assistant 2023.8.1 Supervisor 2023.07.1 Operating System 10.4 Frontend 20230802.0 - latest
ugh, still stuck on 2023.7.x
There's some conflict because my sending HA is able to update to 2023.9.x, but the receiving can't update past 2023.7.x
is it solved in 2023.9.x? i'm trying to update to that right now
No I've updated each time and have had to roll back
me too the problem is that it completely kills my lovelace frontend and with remote_assistant enabled i'm not able to use homeassistant via web inerface anymore
me too the problem is that it completely kills my lovelace frontend and with remote_assistant enabled i'm not able to use homeassistant via web inerface anymore
Just to clarify I have an HA in my private cloud with a very simple configuration on 2023.9 which is the source of some cloud entities. My receiving HA are stuck on 2023.7
So it seems the issue could likely be the receiving component is what's incompatible with newer HA
The problem is with a change in the ‘get all services call’ a few releases ago. This call is used by Lovelace for I think the quick menu to quickly start a service. The problem is that you probably have components in your remote system that are not available in your main one, for example ones from HACS or platforms (such as sensor, switch, etc. but I don’t expect that). The services exposed by the custom components on the remote are not known by the main HA and that makes it fail to load. Unfortunately, for now, the only workaround (which I use because it works in my scenario) is to setup the same integration on the main and just use a dummy implementation so that at least the services of that particular integration are known by the main HA. But… as you said that you have on cloud instance, you probably doesn’t want or cannot load those instances in the main one.
Maybe this can be a start for a developer to have a look at it (maybe I can do it myself but can’t promise anything). In technical terms, the problem is that the service descriptions of integrations that only exist in the remote one are not available in the main one.
:( still a broken issue and stuck on 2023.7.3. It's a shame because I can't find a more straightforward bullet proof way to attach remote entities, especially services which is a critical functionality
Edit: i considered @Wesley-Vos statement about get-all services call for some time, and I was frustrated because I don't want to add the integrations in multiple areas. However this is solved in my case simply by installing the custom integration that provides the missing service, I did not have to actually configure the integration.
If someone can replicate this since I only have one effected custom integration, this can be considered #notabug
The workaround from @Wesley-Vos works for me in other cases, but it doesn't work with the custom integration ramses_cc which started the problem for me. To bypass the issue I have changed my setup of devices and I don't need proxy services any more.
To try if it's still a problem for others I have tested the custom integration but it can't be loaded as a dummy and the custom services won't be created. Proxy services are needed in that case. The workaround can work in a lot of situations, but I think it is still a bug.