* Revert Home Assistant configuration to `/config`
With the new add-on config feature the intention is to provide a good
location for add-on specific configurations. Currently, add-ons such
as Node RED or ESPHome use the Home Assistant config directory because
this location is accessible to the user (via Samba VSCode add-on etc.).
To make it clear to add-on developer that the new intention is to use
add-on specific config, the implementation now bind mounts the add-on
configuration directory to `/config`. And since some add-ons still need
access to the Home Assistant configuration, its config folder is mounted
to `/homeassistant` under the new scheme.
However, users do know the path `/config`, and edit things e.g. through
the SSH or VS Code add-on. Also `/config` is still the
directory from inside the Core container.
For SSH/VS Code add-on we could work around using a symlink, but that
only works as long as these add-ons don't have a add-on config
themselfs.
This all has very high confusion potential, for not much gain. The
renaming is mainly "developer friendly", but not really user friendly.
Let's minimize potential confusion, and keep things where they are.
The Home Assistant config directory stays at `/config, in all cases,
everwhere.
Map the new add-on configuration directory to `/addon_config`.
* Adjust tests/comments
* Cache common version checks
We check core version quite frequently in the code, and its a bit expensive to do
all the comparsions everywhere. Since its mostly the same check happening over and
over we can cache it
* Cache common version checks
We check core version quite frequently in the code, and its a bit expensive to do
all the comparsions everywhere. Since its mostly the same check happening over and
over we can cache it
* fix import
* Don't check if Core is running to trigger rollback
Currently we check for Core API access and that the state is running. If
this is not fulfilled within 5 minutes, we rollback to the previous
version.
It can take quite a while until Home Assistant Core is in state running.
In fact, after going through bootstrap, it can theoretically take
indefinitely (as in there is no timeout from Core side).
So to trigger rollback, rather than check the state to be running, just
check if the API is accessible in this case. This prevents spurious
rollbacks.
* Check Core status with and timeout after a longer time
Instead of checking the Core API just for response, do check the
state. Use a timeout which is long enough to cover all stages and
other timeouts during Core startup.
* Introduce get_api_state and better status messages
* Update supervisor/homeassistant/api.py
Co-authored-by: J. Nick Koston <nick@koston.org>
* Add successful start test
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
* Reload Pulseaudio modules on hardware change
In the past the audio plug-in restarted Pulseaudio on hardware change.
This broke with the s6 updates. However, it also turns out that this is
quite racy: The Supervisor reloads audio data much too quickly, when
Supervisor isn't restarted yet.
Instead, let's reload the relevant modules from Supervisor itself.
This works well with a USB microphone on Home Assistant Green.
Related change: https://github.com/home-assistant/plugin-audio/pull/153
* Fix linter issue
This reverts commit b1010c3c6167c127510a5021fb7dd03995f8b24e.
It seems that the git version deployed with the latest Alpine doesn't
play nice with Supervisor. Specifically it leads to "fatal: cannot exec
'remote-https': Permission denied" errors.
* Remove race with watchdog during backup, restore and update
* Fix pylint issues and test
* Stop after image pull during update
* Add test for max failed attempts for plugin watchdog
* Support proxy of binary messages from addons to HA
* Added tests for proxy
* Move instantiation into init
* Mock close method on server
* Add invalid auth test and remove auth mock
