Unknown error see supervisor home assistant

Mosquitto — «Failed to save add-on configuration, Unknown error, see supervisor logs» since 5.1.1 #2079

The problem

When trying to save Mosquitto configuration, I am presented with an «Failed to save add-on configuration, Unknown error, see supervisor logs» error. Checking Home Assistant logs, I see these two lines:

Until this week, I hadn’t touched my Mosquitto configuration and everything was working without issue. Upon adding a few new Tasmota devices in my home and thus needing to add new usernames and passwords into Mosquitto, I encountered this error. Apparently after months of not touching my configuration, this issue went unnoticed. Having saved snapshots back to 2020, I was able to isolate the specific update that introduced this problem in my environment. Rolling back to 5.1.1, the issue is present. Rolling back to 5.1.0, the issue is not. Error appears to be present in 5.1.1 but not in 5.1.0 — would suspect one or more changes between these two versions to be the cause. It would seem that there’s something happening with the validation code but without any more helpful error message than the one I posted, and without knowing how to get more information/verbose logging, I’m not sure what to check next.

Environment

• Add-on with the issue: Mosquitto
• Add-on release with the issue: 5.1.1 and up
• Last working add-on release (if known): 5.1.0
• Operating environment (OS/Supervised): Intel NUC, Debian 10.9, Home Assistant Supervised install

Problem-relevant configuration

Traceback/Error logs

Additional information

Video showing the difference between 5.1.0 and 5.1.1 with nothing else changing:
https://www.youtube.com/watch?v=OcWZJlDB5_8

The text was updated successfully, but these errors were encountered:

Источник

Failed to to call /addons/a0d7b954_esphome/start — Unknown error, see supervisor #54901

The problem

Logger: homeassistant.components.hassio
Source: components/hassio/websocket_api.py:109
Integration: Home Assistant Supervisor (documentation, issues)
First occurred: 02:56:31 (2 occurrences)
Last logged: 02:56:41

Failed to to call /addons/a0d7b954_esphome/start — Unknown error, see supervisor

What is version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Link to integration documentation on our website

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

The text was updated successfully, but these errors were encountered:

These are not valid Home Assistant versions:

Anything in those logs?

There hasn’t been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Backup — Unknown error, see supervisor logs #3954

Describe the issue you are experiencing

I ask to create a full backup, and, after a few minutes, this is what I see on the screen:

There is absolutely no error in the Supervisor Log.

I’m facing exactly the same issue as this.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Steps to reproduce the issue

Create a full backup

Anything in the Supervisor logs that might be useful for us?

System Health information

System Information

Home Assistant Community Store

Home Assistant Cloud

Home Assistant Supervisor

Dashboards

Recorder

Supervisor diagnostics

Additional information

The text was updated successfully, but these errors were encountered:

It looks like you use the NGINX Home Assistant SSL proxy addon. When you were making this backup, were you using the external URL by any chance?

If so I’m pretty sure what happened is when supervisor started making a backup for the proxy addon the connection was cut off. Since your browser was actually talking to that addon and that was talking to supervisor. And then that connection was cut when supervisor started backing up that addon.

It looks like the backup actually did complete successfully according to your logs. Is that true? Can you see it in the list of backups?

If the backup didn’t complete successfully then that’s definitely a problem and we can iterate here to try and figure it out. But if the backup did complete successfully and I’m right about you using the external URL then I don’t think there’s really much that can be done here. The proxy has to be backed up in the full addon and that means the connection has to be cut. And when that happens the frontend is going to show a generic error because there’s no way for it to know why the connection was cut, just that it was cut unexpectedly.

If you make your backups via the internal URL or (obviously) the CLI then you shouldn’t see anything like this. But if you use the external URL and the backup includes the proxy addon then you’re going to have to expect this error unfortunately and check that the backup succeeded manually (via logs and/or the backup list).

Thank you for looking into this 😃

When you were making this backup, were you using the external URL by any chance?

Well. It depends on the definition of «using» in this context. I started the backup procedure using the internal URL (http://192.168.1.203:8123). I think it’s totally possible that, during the backup, some sensor from my mobile phone generated a connection to the external URL.

22-10-14 08:50:28 INFO (MainThread) [supervisor.addons.addon] Building backup for add-on core_nginx_proxy
22-10-14 08:50:28 INFO (MainThread) [supervisor.addons.addon] Finish backup for addon core_nginx_proxy

In the logs, as far as I understand, core_nginx_proxy was properly backed up. If the connection cut is to be considered an error, I think it should be clearly added to the logs.

It looks like the backup actually did complete successfully according to your logs. Is that true? Can you see it in the list of backups?

That’s what I was wondering 😃 How can I know whether the resulting backup was valid or not? According to what you say, if it appears in the list, then it would be valid (completely valid? valid, except core_nginx_proxy ? valid, except some other addon?). But, then, there is something unclear: is the Unknown error, see supervisor logs a false error report? If not, where would the error be, if the resulting backup is fully valid?

If you make your backups via the internal URL or (obviously) the CLI then you shouldn’t see anything like this.

Источник

Unable to restart supervisor (or core) if core block startup #2519

Describe the issue

(Disclaimer, it’s really unclear to me whether this issue is with core, supervisor, or even the OS. It’s possible I have a corrupted database or installation. My gut is saying to start here though.)

After updating to 2021.2.0 last night, my instance booted up, but never finishes loading. That is, the message saying «Home Assistant is starting, not everything will be available until it is finished.» at the bottom never goes away.

When trying to restart core via UI or via CLI, I get these errors in Supervisor logs:

When trying to restart supervisor via UI or via CLI, I get the «Unknown error, see supervisor» error message. The Supervisor logs show this:

Not sure if it’s related, but in my core logs I see this:

Steps to reproduce

I can reproduce the errors consistently by:

1. Going to Supervisor -> System
2. Clicking «Restart Supervisor»
3. Refreshing Supervisor logs

1. Going to Terminal
2. Typing ha supervisor restart

Enviroment details

System Health

Home Assistant Community Store

Home Assistant Cloud

Hass.io

Lovelace

Spotify

### Supervisor logs Supervisor logs

System Information

The text was updated successfully, but these errors were encountered:

I decided my instance was more-or-less FUBAR, so I went through the reflash process on my odroid using 5.11 and restored a recent snapshot.

My instance is working normally now on the previous core version (2021.1.5). I’ll leave this issue open until after I try updating to 2021.2.0 again. Hopefully it’ll just work this time and then I’ll close this issue.

This is not an issue, your Supervisor was not yet finished starting up. Until it has some features like restart/stop/snapshots will be disabled.

@ludeeus It was an issue because it would never finish its startup. A full day passed and it still wasn’t finished, making it impossible to restart the server, update, or downgrade core, etc. I had to reflash the operating system on my Odroid and restore from snapshot to get back a working server.

I have this exact issue right now. How long does it take for Supervisor to load? I had this same issue with 2021.2.0 as well. Previously I could update to the beta of supervisor and then load a snapshot but doesnt look to be an option this time. I see this issue closed — should I open a new one?

How long does it take for Supervisor to load?

For my instance, it’s usually about 1-2 minutes. But it obviously depends on how many entities/addons/etc you have. When I posted this issue, it hadn’t finished after 10-12 hours. So I assume it would never have finished.

I see this issue closed — should I open a new one?

I would think we’d just re-open this one unless:
a) your exact issue has notable differences from mine, or
b) this issue doesn’t belong in the Supervisor repo

I don’t have the power to reopen though.

Also, FWIW, after wiping my Odroid and restoring to 2021.1.5, I still haven’t tried updating back to 2021.2.x. Too scared to 🙂

@donkawechico That was not clear from your logs and description. A similar issue is open here #2534

I said «it never goes away» twice, but I guess I could have included the «10 hours» bit so you’d know I wasn’t just being impatient 😉

By the way, after installing latest core locally on my mac, I’m seeing similar issues. I’m still poking around, but one thing that’s standing out is a failing installation of PyTurboJpeg==1.4.0

Looking through forums, I see that it can also take multiple hours to install PyTurboJpeg on some platforms. But in my case, it’s flat out failing to build, recommending an upgrade to pip version that Home Assistant doesn’t accept.

One thing that might be worth asking folks experiencing this issue is whether they use Apple Homekit integrations, as it looks like Homekit is the only integration requiring PyTurboJpeg

@jakethomasarnold Do you use any homekit device, by chance?

@donkawechico sorry for the delay. I dont. Edit: the only ‘major change’ I did before the latest update was released is adding the MariaDB add-on and the Bookstack add-on. And maybe I added the Glances add-on as well. I migrated to HA Blue from RPi4 around mid-January using an updated snapshot of the the current release at the time.

I have the same issue. Only a couple of add-ons are installed (FileEditor, OpenZWave, Deconz). All elements have been updated. Now I can’t neither restart HA, no restore from snapshot.

21-02-10 10:11:46 WARNING (MainThread) [supervisor.jobs] ‘SnapshotManager.do_restore_full’ blocked from execution, system is not running — CoreState.STARTUP
21-02-10 10:12:21 ERROR (MainThread) [supervisor.utils] Can’t execute restart while a task is in progress

2021-02-10 13:00:50 WARNING (Recorder) [homeassistant.components.recorder] Ended unfinished session (id=6 from 2021-02-10 09:43:40.271901)

In my case removing OZW-Addon and Integration worked.

I have the same issue. For me it is impossible to restart HA via GUI, make an update, restart supervisor.
Also no snapshot ist possible because the system is in startup.
Supervisor Log: WARNING (MainThread) [supervisor.jobs] ‘Supervisor.restart’ blocked from execution, system is not running — CoreState.STARTUP

I don’t know what to do.

This is an output from ha core —log-level=debug restart

time=»2021-02-16T12:20:28+01:00″ level=debug msg=»Adding homedir to searchpath» homedir=/root
time=»2021-02-16T12:20:28+01:00″ level=info msg=»No configfile found»
time=»2021-02-16T12:20:28+01:00″ level=debug msg=»Debug flags» apiToken=d369c4fb36cf2eec5a370f1d8e351348b46dd7424c4092474df23b33a3f673c3319fdd403a4f51e36a780e8bc5b0c9123bff206ef810cc37 cfgFile= endpoint=supervisor logLevel=debug noProgress=false rawJSON=false
time=»2021-02-16T12:20:28+01:00″ level=debug msg=»core restart» args=»[]»
time=»2021-02-16T12:20:28+01:00″ level=debug msg=»[GenerateURI]» base=supervisor command=restart section=core
time=»2021-02-16T12:20:28+01:00″ level=debug msg=»[GenerateURI] Result» uri=»http://supervisor/core/restart» url=»http://supervisor/core/restart» url(string)=»http://supervisor/core/restart»
Error: Unknown error, see supervisor
time=»2021-02-16T12:20:28+01:00″ level=debug msg=Response body=»<«result»: «error», «message»: «Unknown error, see supervisor»>» fields.time=7.432682ms headers=»map[Content-Length:[63] Content-Type:[application/json; charset=utf-8] Date:[Tue, 16 Feb 2021 11:20:28 GMT] Server:[Python/3.8 aiohttp/3.7.3]]» received-at=»2021-02-16 12:20:28.453180018 +0100 CET m=+0.014872291″ request=»&» status=»400 Bad Request» statuscode=400

@andiaa734 I ended up reflashing home assistant. Loaded a snapshot. Removed all the OZW addons/integrations. Restarted home assistant. Created a new snapshot. Reflashed home assistant. Then loaded the OZW-free snapshot. Upgraded to latest core. Then re-added all the OZW addons/integrations. I am not sure how much of that is needed/not needed but ended up working. Edit: I was having this kind of issue on both Raspberry Pi 4 (previous hardware) and Home Assistant Blue (current hardware). It started on HA Blue but I had just upgraded hardware recently so I was able to fall back/test a bit.

Источник

For some reason ESPHome stopped working (this morning, or sometime through the night) and I was getting the following error in the supervisor logs when trying to start the addon:

21-01-21 16:20:58 ERROR (MainThread) [supervisor.addons.addon] Add-on 15ef4d2f_esphome can't write options
21-01-21 16:21:27 ERROR (MainThread) [supervisor.utils.json] Can't write /data/addons/data/15ef4d2f_esphome/options.json: [Errno 2] No such file or directory: '/data/addons/data/15ef4d2f_esphome/tmplqdjsmm3'

After doing a bit of googling and finding people with similar issues I decided to uninstall the addon and reinstall it, but after waiting for a little while I’m now getting this error:

21-01-21 16:31:47 ERROR (SyncWorker_2) [supervisor.docker.interface] Can't install esphome/esphome-hassio-amd64:1.15.3 -> 404 Client Error for http+docker://localhost/v1.40/images/esphome/esphome-hassio-amd64:1.15.3/json: Not Found ("no such image: esphome/esphome-hassio-amd64:1.15.3: No such image: esphome/esphome-hassio-amd64:1.15.3"). 

which other users seem to have gotten in the past, but I can’t find any posts with updates on how/if they fixed it.

This is the first time I’ve had issues with ESPHome since I started using it, and I haven’t made any changes to it in close to a year, so I’m not sure what might have caused it. The only changes I’ve made to my HA configuration today is installing the Unifi Controller addon, but I don’t see how that could have messed up ESPHome. Everything else is working fine within HA.

Currently running HassOS 2021.1.4

EDIT: After another attempt, I’m getting the following in the log:

21-01-21 17:21:57 ERROR (SyncWorker_3) [supervisor.docker.interface] Can't install esphome/esphome-hassio-amd64:1.15.3 -> 404 Client Error for http+docker://localhost/v1.40/images/esphome/esphome-hassio-amd64:1.15.3/json: Not Found ("no such image: esphome/esphome-hassio-amd64:1.15.3: No such image: esphome/esphome-hassio-amd64:1.15.3").
21-01-21 17:21:57 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-195510' coro=<Job.__call__.<locals>.wrapper() done, defined at /usr/src/supervisor/supervisor/jobs/decorator.py:38> exception=AddonsError()>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 268, in _raise_for_status
    response.raise_for_status()
  File "/usr/local/lib/python3.8/site-packages/requests/models.py", line 943, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.40/images/esphome/esphome-hassio-amd64:1.15.3/json
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/docker/interface.py", line 158, in _install
    docker_image = self.sys_docker.images.pull(f"{image}:{version!s}")
  File "/usr/local/lib/python3.8/site-packages/docker/models/images.py", line 455, in pull
    return self.get('{0}{2}{1}'.format(
  File "/usr/local/lib/python3.8/site-packages/docker/models/images.py", line 316, in get
    return self.prepare_model(self.client.api.inspect_image(name))
  File "/usr/local/lib/python3.8/site-packages/docker/utils/decorators.py", line 19, in wrapped
    return f(self, resource_id, *args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/docker/api/image.py", line 253, in inspect_image
    return self._result(
  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 274, in _result
    self._raise_for_status(response)
  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 270, in _raise_for_status
    raise create_api_error_from_http_exception(e)
  File "/usr/local/lib/python3.8/site-packages/docker/errors.py", line 31, in create_api_error_from_http_exception
    raise cls(e, response=response, explanation=explanation)
docker.errors.ImageNotFound: 404 Client Error for http+docker://localhost/v1.40/images/esphome/esphome-hassio-amd64:1.15.3/json: Not Found ("no such image: esphome/esphome-hassio-amd64:1.15.3: No such image: esphome/esphome-hassio-amd64:1.15.3")
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/addons/__init__.py", line 182, in install
    await addon.instance.install(store.version, store.image)
  File "/usr/src/supervisor/supervisor/utils/__init__.py", line 33, in wrap_api
    return await method(api, *args, **kwargs)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/supervisor/supervisor/docker/addon.py", line 403, in _install
    super()._install(version, image, latest)
  File "/usr/src/supervisor/supervisor/docker/interface.py", line 176, in _install
    raise DockerError() from err
supervisor.exceptions.DockerError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 63, in wrapper
    raise err
  File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 61, in wrapper
    return await self._method(*args, **kwargs)
  File "/usr/src/supervisor/supervisor/addons/__init__.py", line 185, in install
    raise AddonsError() from err
supervisor.exceptions.AddonsError

I’ve noticed that it looks like it’s using HTTP to install the addon; I’m not sure if it’s of importance or not, but I’m using HTTPS for Home Assistant (using DuckDNS/LetsEncrypt).

EDIT #2: I’ve tried installing the ESPHome beta, and still getting the same error:

21-01-21 18:52:42 ERROR (SyncWorker_1) [supervisor.docker.interface] Can't install esphome/esphome-hassio-amd64:1.16.0b4 -> 404 Client Error for http+docker://localhost/v1.40/images/esphome/esphome-hassio-amd64:1.16.0b4/json: Not Found ("no such image: esphome/esphome-hassio-amd64:1.16.0b4: No such image: esphome/esphome-hassio-amd64:1.16.0b4").

EDIT #3: I’ve tried installing the dev build and now I’m getting the following error:

21-01-22 19:58:52 INFO (MainThread) [supervisor.addons] Creating Home Assistant add-on data folder /data/addons/data/15ef4d2f_esphome-dev
21-01-22 19:58:52 INFO (SyncWorker_3) [supervisor.docker.addon] Starting build for 15ef4d2f/amd64-addon-esphome-dev:dev
21-01-22 20:08:18 ERROR (SyncWorker_3) [supervisor.docker.addon] Can't build 15ef4d2f/amd64-addon-esphome-dev:dev: failed to register layer: error creating overlay mount to /mnt/data/docker/overlay2/20de79f5f615ab960a07e688ac658b3e9647dc72b49c9ec9631d1accf348ccce/merged: too many levels of symbolic links
21-01-22 20:08:18 ERROR (SyncWorker_3) [supervisor.docker.addon] Build log: 
Step 1/12 : ARG BUILD_FROM=esphome/esphome-hassio-base-amd64:2.0.0
Step 2/12 : FROM ${BUILD_FROM}

Describe the issue you are experiencing

I installed hassio-supervised using https://github.com/home-assistant/supervised-installer

21-12-01 15:14:19 ERROR (MainThread) [supervisor.plugins.observer] Can’t start observer plugin
21-12-01 15:14:19 ERROR (MainThread) [supervisor.misc.tasks] Observer watchdog reanimation failed!
21-12-01 15:15:19 WARNING (MainThread) [supervisor.misc.tasks] Watchdog/Docker found a problem with observer plugin!
21-12-01 15:15:19 INFO (MainThread) [supervisor.plugins.observer] Starting observer plugin
21-12-01 15:15:19 INFO (SyncWorker_1) [supervisor.docker.interface] Cleaning hassio_observer application
21-12-01 15:15:20 ERROR (SyncWorker_1) [supervisor.docker] Can’t start hassio_observer: 500 Server Error for http+docker://localhost/v1.41/containers/6c73204a32c791a50179c16c364df5a74af5458d6e25a1c226e7988083b0cadb/start: Internal Server Error («driver failed programming external connectivity on endpoint hassio_observer (3903d7e867dd7f181798322046e403822ad54cea2b9cf8fc52e113f02faab68f): (iptables failed: iptables —wait -t filter -A DOCKER ! -i hassio -o hassio -p tcp -d 172.30.32.6 —dport 80 -j ACCEPT: iptables v1.8.2 (nf_tables): Chain ‘DOCKER’ does not exist
(exit status 1))»)
21-12-01 15:15:20 ERROR (MainThread) [supervisor.plugins.observer] Can’t start observer plugin
21-12-01 15:15:20 ERROR (MainThread) [supervisor.misc.tasks] Observer watchdog reanimation failed!

What is the used version of the Supervisor?

supervisor-2021.10.8

What type of installation are you running?

Home Assistant Supervised

Which operating system are you running on?

Debian

What is the version of your installed operating system?

Debian GNU/Linux 10 (buster)

What version of Home Assistant Core is installed?

core-2021.11.5

Steps to reproduce the issue

I just installed and performed the initial setup (setting up home zone).
Afterwards i checke the logs to find that the above mentioned issue occured.
Directly on the machine an nginx is installed on port 80 / 443 which is proxiying home assistant.
This works only the above error keeps me from using addons.

In the logs there’s a «-dport 80» command line.
May it be that this is the issue? Any chance to make this configurable?

Anything in the Supervisor logs that might be useful for us?

21-12-01 15:21:21 WARNING (MainThread) [supervisor.misc.tasks] Watchdog/Docker found a problem with observer plugin!
21-12-01 15:21:21 INFO (MainThread) [supervisor.plugins.observer] Starting observer plugin
21-12-01 15:21:21 INFO (SyncWorker_0) [supervisor.docker.interface] Cleaning hassio_observer application
21-12-01 15:21:21 ERROR (SyncWorker_0) [supervisor.docker] Can't start hassio_observer: 500 Server Error for http+docker://localhost/v1.41/containers/38c7c48a48de247399f8a10f1225c0f7545a094261c41e0abd5082a14f2d7856/start: Internal Server Error ("driver failed programming external connectivity on endpoint hassio_observer (fc6da60499be58d08063335e61cfa4eff9f0e0073981c1aa925839e17e141e0a):  (iptables failed: iptables --wait -t filter -A DOCKER ! -i hassio -o hassio -p tcp -d 172.30.32.6 --dport 80 -j ACCEPT: iptables v1.8.2 (nf_tables): Chain 'DOCKER' does not exist
 (exit status 1))")
21-12-01 15:21:21 ERROR (MainThread) [supervisor.plugins.observer] Can't start observer plugin
21-12-01 15:21:21 ERROR (MainThread) [supervisor.misc.tasks] Observer watchdog reanimation failed!

Additional information

No response

Вчера вышла новость. Ребята из Home Assistant заявили что
установка HA в виде набора докер контейнеров под управлением
супервизора более не поддерживается (ссылка).

Я устанавливал Home Assistant именно тем способом, который стал deprecated,
поэтому я пошел думать как мне дальше жить с Home Assistant.

В итоге я даже рад что этот способ стал deprecated.
После того как я обдумал что делать дальше, я понял что мне
супервизор вообще не нужен. И это действие команды Home Assistant
сподвигло меня полностью отказаться от супервизора,
а запускать все нужные мне вещи с помощью docker-compose.

Я уже реализовал эту идею. Переделал свою инсталляцию HA на
использование docker-compose. Супервизора у меня больше нет.
У меня очень небольшая инсталляция Home Assistant, поэтому
в моем случае это было просто.

В этом тексте я описываю что, как и зачем я делал. Это не
руководство к действию что всем нужно делать именно так,
это только рассказ о моем опыте.

Как работало раньше

Home Assistant можно установить несколькими разными способами.
Самый простой способ — это скачать официальный образ специальной
операционной системы в котором уже правильным способом существует HA.
Этот образ ставится на хост и Home Assistant работает.
Это способ никуда и не делся. Анонс про deprecated никак не
влияет на этот способ установки — этот способ все еще
официально поддерживается.

Плюс этого способа — он очень простой. Скачивается образ, заливается
на носитель — компьютер загружается — все, Home Assistant работает.

Но у этого способа есть недостаток: очень ограниченная возможность
делать что-то свое на операционной системе из этого образа.

Поэтому я использовал другой вариант установки:

• сам ставлю нужную мне операционную систему
• устанавливаю докер в это систему
• запускаю скрипт, который устанавливает набор докер контейнеров в которых живет HA

Вот ровно этот скрипт установки и объявили deprecated.

Почему я ставил HA не в виде официального образа, на собственноручно
установленную операционную систему? Во-первых, мне так удобнее.
Эту операционную систему я понимаю, ту которую тащит с собой HA — я не понимаю.
Удобно зайти, что-то там посмотреть-сделать.
Кроме Home Assistant у меня на этой операционной системе еще и крутятся мои
скрипты, с помощью которых у меня настроен удаленный доступ к HA (я делаю
проброску ssh туннелей, подробнее о том как это настроено тут).

Home Assistant заработает на том что за деньги предоставляют удаленный доступ к инсталляции HA.
Забавно что в моем случае то что задеприкейтили как раз используется для того
чтобы не платить им деньги, а сделать удаленный доступ другим способом.

Что такое супервизор и зачем он нужен?

Супервизор для меня решает две задачи:

• возможность в один клик поставить какой-то дополнительный аддон
• возможность в один клик обновить Home Assistant

Супервизор HA это отдельный докер контейнер, который управляет другими контейнерами.
Если на моем компьютере с HA выполнить команду «docker ps -a», то появится список
запущенных контейнеров:

CONTAINER ID        IMAGE                                              COMMAND                  CREATED             STATUS              PORTS                                                                NAMES
3f8575bf6af7        homeassistant/armv7-hassio-supervisor              "/init"                  27 hours ago        Up 27 hours                                                                              hassio_supervisor
b4a1cb189587        dwelch2101/zigbee2mqtt-armhf:1.13.0                "/init ./run.sh"         7 days ago          Up 7 days           0.0.0.0:8485->8485/tcp                                               addon_7ad98f9c_zigbee2mqtt
c8896eb85798        homeassistant/raspberrypi3-homeassistant:0.109.0   "/init"                  10 days ago         Up 9 hours                                                                               homeassistant
07e5228c90eb        homeassistant/armv7-addon-mosquitto:5.1            "/run.sh"                3 weeks ago         Up 3 weeks          0.0.0.0:1883-1884->1883-1884/tcp, 0.0.0.0:8883-8884->8883-8884/tcp   addon_core_mosquitto
6f2ac7d1dd27        homeassistant/armv7-hassio-multicast:2             "/init"                  3 weeks ago         Up 27 hours                                                                              hassio_multicast
679ba6c7d255        homeassistant/armv7-hassio-cli:25                  "/init /bin/bash -c …"   3 weeks ago         Up 3 weeks                                                                               hassio_cli
63e8df3820de        homeassistant/armv7-hassio-dns:9                   "/init coredns -conf…"   3 weeks ago         Up 27 hours                                                                              hassio_dns
74d8df79e422        homeassistant/armv7-hassio-audio:14                "/init"                  3 weeks ago         Up 3 weeks                                                                               hassio_audio

Тут видно:

• сам супервизор
• Home Assistant
• аддон в котором работает mqtt сервер mosquitto
• аддон в котором работает zigbee2mqtt

Но кроме этих понятных для меня штук еще и работают вещи которые я совершенно не
понимаю зачем нужны:
* audio — зачем? у меня к этому компьютеру не подключены колонки, никакое аудио я на нем не играю
* dns — а это зачем? почему не использовать данные о dns с хост машины

Я вполне могу запустить руками и сервер mosquitto и zigbee2mqtt.
Мне не ясно зачем тащить все вот это которое делает непонятно что.

Есть и другая вещь, почему я рад отказаться от супервизора.
Я тут недавно узнал что супервизор обновляется сам. Они
выпустили версию с багом (тред про баг,
а потом сами раскатили исправление.

В случае системы автоматизации я считаю что это неприемлемое поведение.
Они сами заявляют local first, а тут что-то автоматом без моего
ведома приезжает из облака. В случае HA я хочу контролировать
что приходит с обновлениями и иметь возможность это не поставить
если мне это не нравится.

Так что, все обдумав я решил перестать использовать супервизор
докера, а запускать все самостоятельно.

Шаг 1. Убрать то что есть

Убираю из автозапуска:

root@raspberrypi:~# mv /etc/systemd/system/hassio-supervisor.service /root/
root@raspberrypi:~# mv /etc/systemd/system/multi-user.target.wants/hassio-supervisor.service /root/

Перезагружаю компьютер и убиваю все контейнеры:

root@raspberrypi:~# docker ps -a|perl -nalE '`docker rm -f $F[0]`'

И еще раз перезагружаюсь

Шаг 2. Установить docker-compose

Удивительно, но одна из самых сложных вещей в переезде на docker-compose это
была установка docker-compose.

В итоге я успешно установил docker-compose с помощью команд:

root@raspberrypi:~# apt-get update && apt install -y python3-pip
root@raspberrypi:~# pip3 install docker-compose

Но до этого я пробовал еще несколько способов и там все шло совсем не так.

Шаг 3. Создание docker-compose.yaml

Через некоторое время я соорудил yaml файл с описанием всех
контейнеров которые мне нужно запускать. Их всего 3:

• Home Assistant
• mqtt сервер mosquitto
• zigbee2mqtt

Я положил этот файл в /root/ha/docker-compose.yaml

homeassistant:
  container_name: homeassistant
  image: homeassistant/raspberrypi3-homeassistant:0.109.0
  volumes:
    - /usr/share/hassio/homeassistant/:/config/
  ports:
    - "8123:8123"
  restart: always

mosquitto:
  container_name: mosquitto
  image: eclipse-mosquitto:1.6.9
  volumes:
    - ./mosquitto_data/:/mosquitto/data/
  ports:
    - "1883:1883"
  restart: always

zigbee2mqtt:
  container_name: zigbee2mqtt
  image: koenkk/zigbee2mqtt:1.13.0
  volumes:
    - ./zigbee2mqtt_data/:/app/data/
    - /run/udev:/run/udev:ro
  devices:
    - /dev/ttyACM0:/dev/ttyACM0
  restart: always
  privileged: true
  environment:
    - TZ=Europe/Moscow

И еще там же лежат 2 скрипта

restart

docker-compose build; ./stop; docker-compose up -d

stop:

docker-compose stop; docker-compose rm -f

Тут у меня написано что Home Assistant использует данные из той же папки
с которой раньше работал Home Assistant из супервизора, так что все что
у меня было настроено в HA осталось без изменений.

Я запускаю этот контейнер стандартным способом: он живет в своей собственной
сети и только порт 8123 проброшен наружу. Для моих целей достаточно такого
способа запуска, но вполне возможно это этот вариант подойдет не всем. Если у
вас есть какие-то проблемы с тем как HA общается с сетевыми устройствами, то, возможно,
вот этот вариант решит ваши проблемы (при таком способе сеть в контенере
точно такая же как на хосте):

homeassistant:
  container_name: homeassistant
  image: homeassistant/raspberrypi3-homeassistant:0.109.0
  volumes:
    - /usr/share/hassio/homeassistant/:/config/
  net: "host"
  restart: always

MQTT сервер работает со всеми настройками по умолчанию. Т.е. для
того чтобы к нему подключится можно ввести любой логин-пароль (или вообще не вводить).
В качестве первого подхода это нормально, но в будущем нужно будет
перенастроить. От старого MQTT сервера тут ничего не осталось.
В моем случае это не сильно страшно. MQTT в основном это «получил, передал и тут же забыл»,
потерялись только сообщения с флагом retain. В моем случае это
было совершенно не критично.

Хуже всего с zigbee2mqtt. Кроме описания в docker-compose.yaml я еще написал конфиг
/root/ha/zigbee2mqtt_data/configuration.yaml

homeassistant: true

permit_join: false

mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://192.168.31.86:1883'

serial:
  port: /dev/ttyACM0
  disable_led: true

advanced:
  channel: 25

device_options:
  retain: true

devices: devices.yaml
groups: groups.yaml

Я не стал разбираться как перетащить старый конфиг zigbee2mqtt в мою
новую инсталляцию, а просто переспарил все все устройства заново.
У меня устройств мало, так что мне это подошло.

Плюс мне все равно нужно было это рано или поздно делать. Раньше
у меня был выбран для zigbee канал по умолчанию 11, но сейчас ко
мне едут несколько Konke кнопок.
Они не могут работать на этом канале, поэтому я тут заодно
и сменил канал, а это действие требует переспаривания.

Итак. раньше я использовал супервизор для двух вещей:

• обновить HA
• простая установка аддонов

Сейчас чтобы обновить HA мне нужно поменять одну строчку в docker-compose.yaml файле
и запустить ./restart (но чтобы HA был поменьше в дауне стоит сначала сделать
docker pull на нужный образ)

У меня пропала возможность устанавливать аддоны в один клик. Но мне это
и не особо нужно. Если нужно что-то поднять я вполне могу сделать это сам.

Зато настройка программ совершенно обычная (как-то я очень много времени
провел пытаясь настроить аддон zigbee2mqtt прежде чем узнал что его
настройка через аддон отличается от настройки в обычном режиме).

Итого

В итоге я даже рад что случилось это изменение. Это меня сподвигло к тому чтобы уйти
от супервизора который мне и не нужен к запуску через docker-compose, который я
понимаю и могу контролировать.

Несколько часов на переезд и и меня опять все работает.
Даже, похоже, что это жрет немного меньше ресурсов (хотя это все неважно, раньше
проц был загружен на 4%, сейчас на 2%, все то же самое).

Я только-только это сделал, и пока не пожил с этим. Вполне возможно
что какие-то вещи я переделаю, но пока мне кажется очень верным решение
вообще отказаться от супервизора.

Пока я не понимаю, будет ли Home Assistant продолжать выпускать официальные
докер образы с системой. По моим ощущениям, должны, но я слышал
некоторые сомнения от разных людей. Но даже если они не будут
сами делать образы, придется самому заворачивать код в образ, что
вполне решаемо.