Hi,
I was trying your solution by stopping restarting the Hass service then go and clear the supervisor container, however I do not have that container. If I watch the containers status page.It gets created thenruns for few seconds then it gos in a cycle. Create-run-delete …and so on. So it never gets me the supervisor page.
Any suggestions?
Thank you
There seems to be something that is breaking it after less than 24 hrs. If left untouched the supervisor crashes and I have to restart the whole NAS. Then it comes right back. Last restart wiped off all the Google Cast devices I had setup. The Google cast disappeared from my install and can’t even find it in the available addons
Was it removed ? Anyone seen this ?
Thank you
I’ve lost all Google Cast devices after update to 0.109 - there is bug report I opened also.
Depending on the network setup you may not be able to get them back at this point.
I wasn’t able to use Integration for adding them previously and was using manual setup.
Docker install issue are solved after DSM 6.2.3-25423 update.
Thanks for support !!
1 Like
Received a new update to 0.109.2 that brought my Cast devices back However the supervisor still gives me grief. I just updated the DSM to 6.2.3.25423 Will see if that makes any difference
My supervisor container is still crashing and goes into a loop every day. I don’t have much insight in the logs as it gets deleted and recreated in matter of seconds.I have to restart the whole NAS in order to get it back
Is there a fix for this? I’m sorry if I missed the obvious but the thread is very long. The solution proposed at the very beginning to restart just the Hassio service doesn’t seem to help.
Found some logs
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/synology_dsm/init.py”, line 160, in update
await self._hass.async_add_executor_job(self._dsm.update)
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.7/site-packages/synology_dsm/synology_dsm.py”, line 261, in update
data = self.get(SynoCoreUtilization.API_KEY, “get”)
File “/usr/local/lib/python3.7/site-packages/synology_dsm/synology_dsm.py”, line 169, in get
return self._request(“GET”, api, method, params, **kwargs)
File “/usr/local/lib/python3.7/site-packages/synology_dsm/synology_dsm.py”, line 227, in _request
raise SynologyDSMAPIErrorException(api, response[“error”][“code”])
synology_dsm.exceptions.SynologyDSMAPIErrorException:
Code: 1052
Reason: Unknown
2020-05-03 10:59:33 ERROR (MainThread) [homeassistant.components.hassio.handler] Client error on /homeassistant/info request Cannot connect to host 172.30.32.2:80 ssl:None [Connect call failed (‘172.30.32.2’, 80)]
2020-05-03 10:59:33 WARNING (MainThread) [homeassistant.components.hassio] Can’t read last version:
2020-05-03 11:12:19 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
2020-05-03 11:14:06 ERROR (MainThread) [homeassistant.components.hassio.http] Client error on api app/entrypoint.js request Cannot connect to host 172.30.32.2:80 ssl:None [Connect call failed (‘172.30.32.2’, 80)]
The errors that pertain to the HACS are not making the system to crash because The system crashed without them
Thank you
Is your Synology Firewall perhaps enabled?
Nope ! FW is disabled! The only thing that I “think” can maybe affect it is the PieHole But I whitelisted the hass.io.
Are there maybe any FW rules that I need to be aware of? That need to be done on the router
Hey folks,
I’ve just switched to hass.io on Synology (DS 216+) from regular docker installation on SBC and everything works fine for me except one thing.
Every 5 minute Supervisor tries to connect to HA and fails, this is what it logs:
20-05-05 10:25:57 ERROR (MainThread) [supervisor.auth] Can’t request auth on Home Assistant!
While in HA in logs I’ve got:
2020-05-05 10:25:57 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from 172.30.32.2
Does anyone know why it fails and how to fix it? It’s fresh install…
I was getting the exact same error and have been for quite some time. Your post prompted me to try and fix it. Are you using Node Red? If yes this might help, it fixed it for me: https://community.home-assistant.io/t/node-red-and-172-30-32-1/142390/4?u=eoin
Ok I think I found an issue. Since I was moving some services as part of the migration from docker based stuff to hass.io I think my MQTT devices are causing HA and Supervisor to log this stuff in a weird manner.
Thans for your great job!
I believe that this is the best choice to run homeassistant on Synology!
My journey of homeassistant, for reference:
- home-assistant (now called core) on Ubuntu (vmware on Windows 10 on a notebook)
- home-assistant on RaspberryPi 3B+
- home-assistant on docker of Synology
- hassio on vmm of Synology
- hassio on docker of Synology. the cpu load is less than vmm, about 10% vs 5%
1 Like
@fredrike does this affect hass.io package somehow? https://www.home-assistant.io/blog/2020/05/09/deprecating-home-assistant-supervised-on-generic-linux/
3 Likes
What is the best way to reboot this? The Server Controls menu doesn’t work as items that require a restart still request it. The only way I’ve been able to get this to work is by manually rebooting the docker containers.
Well, it would still work but be unsupported by HA. As people probably have noticed there is no reference to Home Assistant Supervised on Synology on the install instructions. That is because this method mentioned here is just that, unsupported. I’ve spent countless hours building the package and making sure it runs as smooth as possible but…
I think this is quite true:
Installing is fine, everyone can follow a tutorial, but after that when things break, people come to us, not the author of the tutorial. And this workload keeps growing, to a problematic extent.
But what we have seen over the last few months in this thread is more and more like:
@fredrike: this * integration/special setup doesn’t work, fix it!
Not a community effort in helping out or debugging the issues, just high expectations on fixing stuff.
Wich have made me lose faith and interest in this, I built it to help you guys, but don’t quite feel the love…
7 Likes
My setup on Synology works like a charm quite long ago (at least happy a year) without any issues. I tried different configurations, and this configuration is the best for me. It is the most convenient way to setup HA without additional hardware, and to manage different addons without special knowledge and efforts how to integrate them.
So I love. Hopefully, there are quite a lot of us.
4 Likes
I’ve gone from RPi to docker on Synology to docker on Mac mini to this outstanding Hass.io on Synology.
It’s by far the best solution. Love it!
Thank you for your time and expertise.
5 Likes
Dear @fredrike,
yesterday I was kind of shocked to read HA is moving away from Linux generic install (which I guess your great package is built on). In the meantime they are reconsidering their decission.
Reading that you already walked away from your DSM package is no less shocking as this reinforces the point the HA crew yesterday made: the growing ingratitude and lack of respect of (some|many?) users to the ones that make great software (for free!) and contribute to the concept of open source.
In the internet it is mostly the bad things that are brought up. There is less attention for the good. So I want to raise my voice for the good things!
I want to commend you and appreciate your hard work! And I hope, that you may change your mind eventually and keep providing us this totally hassle free experience installing HA supervised on our diskstations.
Thanks much!
6 Likes