Open Flightkick opened 1 year ago
Still no reaction from dev?
Thanks for the information amazing report👍, unfortunately the previous Dev has been away for the past year. I will look into this soon.
Same problem. Manually reload configuration and after workig good, but after HA restart and the pc is offline the problem come back. :(
If you have a WOL switch for the PC you could create an automation that reloads config entity when PC is turned on. In theory this might be a temporary solution.
- service: homeassistant.reload_config_entry
data:
entity_id: media_player.YOUR_PC
If you have a WOL switch for the PC you could create an automation that reloads config entity when PC is turned on. In theory this might be a temporary solution.
- service: homeassistant.reload_config_entry data: entity_id: media_player.YOUR_PC
I will have a look at this issue a bit more soon, but we are also considering removing support for local API in the forked version as there is a fair bit of stuff that it is disadvantaged in. As well as the fact that so many integrations are mqtt only now so it having it as a requirement isn't that much of an issue.
The problem with this issue is that it is difficult to tackle in a nice way. Because of the fact that local API is a one way data transfer it means that there is no way to send a message from hass.agent to ha when it is booted. The next best option is to check once every 60s or so if the PC is online, this is how other integrations tackle it, but it creates a lot of unnecessary traffic resource usage.
If you have a WOL switch for the PC you could create an automation that reloads config entity when PC is turned on. In theory this might be a temporary solution.
- service: homeassistant.reload_config_entry data: entity_id: media_player.YOUR_PC
I will have a look at this issue a bit more soon, but we are also considering removing support for local API in the forked version as there is a fair bit of stuff that it is disadvantaged in. As well as the fact that so many integrations are mqtt only now so it having it as a requirement isn't that much of an issue.
The problem with this issue is that it is difficult to tackle in a nice way. Because of the fact that local API is a one way data transfer it means that there is no way to send a message from hass.agent to ha when it is booted. The next best option is to check once every 60s or so if the PC is online, this is how other integrations tackle it, but it creates a lot of unnecessary traffic resource usage.
Simple heartbeat is probably the only way. I would not be concerned about extra traffic to be honest. The amount of telemetry IOT devices are sending it is more than acceptable.
Okay, I'll hopefully work on this later this week. But due to the current situation the only way it will be fixed for end users is manually installing and updating to v2.
If a HASS.Agent host is down at the time of Home Assistant startup, the setup process aborts with an error 'max retries reached'. The device stays in the 'Failed to set up' state even after the HASS.Agent host becomes available (see Integrations overview screenshot). While sending commands then continues to work as expected, other services (like sending notifications) stay unavailable.
To reproduce this behavior
System > Devices & Services > Integrations
and the 'Notifications: Send a notification with \<devicename>' is unavailable/missing inDeveloper Tools > Services
.Expected behavior Home Assistant should retry setting up the device after the device becomes available.
Error logs in Home Assistant