Moved across to this implementation a couple of weeks ago from an RPI based deployment.
All was good until I discovered it had stopped writing to my InfluxDB (Also in a Docker container on the same host).
However it could still write to the MariaDB which is a native install on the same SynologyNAS. So both DB’s have the same IP set in configuration.yaml but are talking to different ports.
Poking with the network it turned out it that the Home Assistant container couldn’t make a network connection to the Influx port on the IP for the Synology, but would talk to the MariaDB. Odd, since they’re the same IP…
But, it would talk directly to the IP of the InfluxDB container. Updating configuration.yaml with the actual IP of the InfluxDB container has resolved the problem, but it doesn’t explain why it wouldn’t talk to the host IP (which is how other systems access it).
This may help someone else, and if anyone know’s why it won’t work using the external IP the same way other servers do that would be useful to me to understand…
I just installed this and everything seemed to work fine. But when i log into Home Assistant there is no “hass.io” button which is usually below “Developer Tools”.
Now i have “supervisor” in it’s place but after opening i only see an empty page, not the add-on store or the other tabs i would expect.
Did i do anything wrong?
Edit: I just figured out the tab is supposed to be called “supervisor” now. Anyway, it still doesn’t have any content
Edit2: After reboot (stop Docker container) it’s okay now.
I do not want to use DSM letsencrypt client as it does not support DNS validation. However, I can simply copy the certs from letsencrypt container to homeassistant container similar to the solution you referenced.
I did without manually creating folders in hass.io/audio. In my case, it was enough to create an audio group in DSM before installation. Thanks to FizzBlizz!
hassio_x64-6.1_20191006-3c5c9bce.spk are working very well with Docker 18.09.0-0506.
But, SynoCommunity version hass.io (291224-1) can’t be install due to missing docker notice.
There were issues with an old Docker package so I did pin the version on the SynoCommunity to Docker>=18.09.0-0506 it is very strange as it seems like you already have Docker 18.09.0-0506 installed.
Could you test the following (from an terminal on your NAS):
synopkg list|grep Docker
synopkg version Docker
This is my outputs:
$ synopkg list|grep Docker
Docker-18.09.0-0506: Docker is a lightweight virtualization application that gives you the ability to run thousands of containers created by developers from all over the world on DSM. The hugely popular built-in image repository, Docker Hub, allows you to find shared applications from other talented developers.
I’ve used the same workaround to let it work! @fredrike: I’m working on a local Home Assistant Core installation, because I’m testing a Lutron integration which is requiring to modify also a dependency (pylutron.py).
Is there a way to updated the docker installation to my modified version when I’m ready, or it doesn’t make sense?
and my output are like below ( There are some Koreans but meaning are same as yours )
admin@DATA:~$ synopkg list|grep Docker
Docker-18.09.0-0506: Docker는 전 세계의 개발자들이 DSM에서 만든 수천개의 컨테이너를 실행할 수 있는 능력을 제공하는 경량형 가상화 응용 프로그램입니다. 인기있는 거대한 내장 이미지 리포지토리인 Docker 허브에서는 재능있는 다른 개발자들의 공유된 응용 프로그램을 찾을 수 있습니다.
For some reason, after several weeks and days of stable running hassio 106.6 i just now lost the dashboard in the supervisor, it does not show installed add-ons.
Also, the add-on store is not showing any results.
Nothing in the log-files, and the only change done recently is signing up and connecting to Nabu Casa. I offcourse disabled this, restarted the package from DSM, and so on. Still no data in the supervisor.
Also tried to restore to an 6 days old image, i know the store worked then, but even when restored, it does not show anything in dashboard, or in the add-on store.
Oh, that’s really unfortunate. Usually the issue with the supervisor tab is resolved by restarting (either the package or sometimes the whole NAS). I don’t know what is causing this but it is a sync-problem between the supervisor and hass-core.
hej @fredrike
Could you also upload your package to some other location like Google Drive / Dropbox etc in parallel to SynoCommunity?
Synocommunity is super unstable last weeks. And almost every time I look in there - it’s down. Now it’s down as well.
I’d like to try out your package after it matured in the last months but can’t download it
EDIT: SynoCommunity got up and I installed it!
First observations:
Encountered the issue with restart loop of the hassio_audio container. Fixed by creating audio group in DSM GUI. I think it’s worth to mention this in your 1st post in current issues. Hope the next release will be free of this bug. I think creation of the audio group should be part of the package installation
the homeassistant container did not start automatically. I waited until I saw the download is finished and started it manually from docker. Something is probably wrong in the package script. restarting the package didn’t help. Only manual start possible.
Great work BTW! Will be testing this in the next days and hopefully will replace my current docker-based HA Core with this hass.io package. Seamless addon functionality is a bless and a real HA added value. Thanks for your efforts!
Hi @fredrike !
Thanks actioning so quickly and for the reply.
No, actually I haven’t But next time if something fails - I definitely will.
I decided to play a little bit with this package (as I’m running it in parralel for now with my HA Core and this was a clean install, so I don’t lose anything) as I thought you’d like to get some feedback how does it go to fix any bugs for the future releases.
I uninstalled the package from SynoCommunity and here my observations after uninstall:
Is this intended that only addon containers are removed by the uninstall script? hassio_audio, hassio_cli and homeassistant containers stayed in Docker. Addon containers were removed
Should the hass.io folder stay after uninstall? It stayed in my case. Actually I wonder what happens when I install the package again. Is it recommended to remove the folder priori reinstallation? Can any conflicts occur?
Then I decided to give a try of two attempts - with the hass.io folder intact and without it (again a clean install). Every time I tried - I deleted the remaining containers (homeassistant, hassio_cli, hassio_audio).
I. 1st attempt
I left the hass.io folder, and planned to remove the audio group, but I forgot to do this prior installation of the package version from your Dropbox and the installation failed saying that it cannot create group:
Probably it was about the audio group. I think it’ll be good to handle this in the install script and not create one when it exists or ask the user what to do (delete and recreate or leave it).
The installation succeeded anyway and all containers got up! Including the homeassistant container. So no error this time (not sure why did this happen the first time I installed te package - perhaps some docker issue.
Addon containers were recreated. All went back to the state before uninstall which is great!
II. 2nd attempt
Removed the audio group in DSM GUI prior installation and installed the package from Dropbox you provided.Also removed the hass.io folder prior the installation
Here’re my observations:
There’s a message shown regarding the group creation: , but seems it doesn’t do anything wrong with the installation. Perhaps not necessary to show it?
The group was created successfully!
All containers were created. No boot loop of hassio_audio - problem fixed
Everything started well and all good!
Independently from the approach I took there are warnings in logs - probably related to the fact that Synology is not the officially supported platform.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.systemd] No systemd support on the host. Host control has been disabled.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.hostname] No hostname support on the host. Hostname functions have been disabled.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.rauc] Host has no rauc support. OTA updates have been disabled.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.nmi_dns] No DnsManager support on the host. Local DNS functions have been disabled.
But do you know what each of them means to us? What functionalities are missing in this package comapring to e.g. installation on RPi becuase of this?
But next time if something fails - I definitely will.
Including the 
, but seems it doesn’t do anything wrong with the installation. Perhaps not necessary to show it?