first of all, thanks for your great work concerning Hass.io on DSM. I think it’s pretty cool from what I read here, unfortunately it’s not working on my DS.
I’ve just freshly installed it on my DS216+ II (with DSM DSM 6.2.3-25426 Update 2) and followed your special instructions here in post #2, however, after stopping the Hass.io thru package center and then clearing the data for the hassio_supervisor to hopefully make the same work within the UI, this container keeps continously restarting itself after less than 1 minute. It’s an endless loop.
It means that it stopps itself, then starts while (of course) CPU usage and RAM increase, but then suddenly fall and stopping again, and so on.
Any clue how to fix that?
Thanks and BR
Stefan
EDIT: After another forceful stop of the hassio_supervisor it suddenly works as expected!
I had a same thing. Few months if not year ago. But after few hours met.no was back online and all was ok. Did you try later to see if it works (restart HA).
yes, I’m kinda happy that it works… but… my setup does not find my Hue Bridge. Always tells that it’s unable to detect one but mine is actually there and operating (even already restarted).
When I used to play a bit with the HA core setup, I could add it! With the Hassio it does not work for some reason, same with the embedded weather widget.
Could this be related to the network config of the container(s)? I mean, the HA core I had configured as “use host network” and the current runs on defaults which is different for some of the containers. Just the HA itself uses the “host network” obviously.
maayybe explain a bit more? What’s not working? If you are reffering to one of the “errors” above regarding deconz - please refer to that, then maybe one someone in the forum has a solution
sure… I could now figure out the following log errors related to the not working discovery of my Hue Bridge:
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:115
First occurred: 2:02:06 PM (3 occurrences)
Last logged: 2:11:44 PM
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/aiohttp/connector.py", line 829, in _resolve_host
addrs = await \
File "/usr/local/lib/python3.8/site-packages/aiohttp/resolver.py", line 29, in resolve
infos = await self._loop.getaddrinfo(
File "/usr/local/lib/python3.8/asyncio/base_events.py", line 825, in getaddrinfo
return await self.run_in_executor(
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.8/socket.py", line 918, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Try again
But, from the SSH terminal in HA I can ping my bridge… kinda weird. Any hints are much appreciated!
This topic is very interesting but also really long. Is there somewhere any kind of digest? Something like a Wiki page regarding this topic?
The main question (and I’m not sure wether this has been asked before, though my search on this topic didn’t yield any results):
Some (all?) add-ons are run in their own containers. These containers are started on the fly. Can I influence somehow the volume settings for these containers?
Specifically I’m using ‘appdaemon’ and would like to write the logs to a specific volume. But this volume is not present in the appdaemon’s container. Is there a way for me to configure a container volume for these add-on containers?
There are so many things here that could be issue and why do you think this is related to Philips Hue bridge?
Is Hue bridge on the same subnet as your HA/Synology? Not sure that this could affect it, but could be. - do you use one Ethernet port or two? If 2 are they separate IP address or bridge?
Do you have firewall on in Synology?
Hi, yes I know that it could be many thing but my feeling is that it’s related to network settings (somewhere and eventually related with Docker).
My firewall in the Synology is currently off for testing purposes. The Hue Bridge is on same subnet as my Synology, yes.
The network config in Docker is currently like this (install defaults):
I could figure out that (on my system) when the hassio_supervisor is operating properly, I cannot find my Hue Bridge! However, when the supervisor is not working and HA throws the "Unable to load the panel source: /api/hassio/app/entrypoint.js" error message, then I can find my Hue Bridge!
I have the same issue on DS218+, but for me the restart is not helping, i restarted it several times and the supervisor container keeps restarting all the time. Anyone any idea? thanks!
I finally could make it work stable, even after some reboot of the DS and/or just the Homeassistant container itself.
Seems to be working pretty smooth.
I’m pretty much sure that it’s fully dependent on (virtual) network settings. So I executed once again the script here from 2nd post of Fredrike twice and successively. Since then, all fine!
sudo su -
# Stop the containers and remove them from the hassio network.
HASSIO_CONTAINERS=$(docker network inspect hassio |\
jq -r '[.[0].Containers[]|.Name]|join(" ")')
docker stop $HASSIO_CONTAINERS
for CONTAINER in $HASSIO_CONTAINERS; do
docker network disconnect hassio $CONTAINER
done
# Recreate the hassio network (remove it and create it again).
docker network remove hassio
docker network create -o com.docker.network.bridge.name=hassio \
--driver=bridge --subnet=172.30.32.0/23 --ip-range=172.30.32.0/24 \
--gateway=172.30.32.1 hassio
# Add the containers to the new network and start them.
for CONTAINER in $HASSIO_CONTAINERS; do
docker network connect hassio $CONTAINER
done
docker start $HASSIO_CONTAINERS
#Restart just to make sure things are going the right way.
docker restart hassio_supervisor
After running this script the restarts are gone or at least seems that way for now, but is still get the entrypoint.js error:(
The script left the hassio_multicast container untouched, it has a host network and the supervised container has two: bridge and hassio.Is this ok?
That was the result of the script:
Stop:
hassio_audio
hassio_dns
hassio_observer
hassio_cli
hassio - i don’t know what is this, maybe the supervisor
Then it gave me back the network id and after the restart:
hassio_audio
hassio_dns
hassio_observer
hassio_cli
Error response from daemon: Cannot restart container hassio_supervisor: Address already in use
i have, but the script didn’t restart it, but now i stopedd it from package center and started it, and it is restarting again after it has started, run the script again, now the supervisor was there:
hassio_audio
hassio_observer
hassio_cli
hassio_dns
hassio_supervisor
hassio
296d0dfd95d84216710e4678599a9cce847511bbca6ceda256625b456c16dee9
hassio_audio
hassio_observer
hassio_cli
hassio_dns
hassio_supervisor
hassio_supervisor
But it is still restarting over and over again…Maybe i’ll try to reinstall the whole thing, i don’t have any idea now.
And the multicast container is still untouched
Yes, try to remove the package (any configuration you have should be safe) - and check that all containers are removed as well as hassio network. ¨That could help.
Of course you can try a complete re-install from scratch but eventually it’s not neccessary.
Try to “clear” the hassio_supervisor once it’s (forcefully) stopped and after this, run the mentioned script once again.
It seems the reinstall worked for now, i was able to access the supervisor page. When i’ll face this error again, i’ll try the script way again. By forcefully stop you mean stop from package center?
