I created the “99-wyze.rules”, but there is no “docker-compose.yml”, correct?
Additionally, is my wyze usb dongle supposed to load as a “hidraw” subsystem?
Thanks, adding the hassio network manually before installing the package did the trick for me. For the new multicast container to work it’s important that com.docker.network.bridge.name=hassio is set which you can’t do via the Synology Docker GUI directly. I used:
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
Tinkerer
(aka DubhAd on GitHub)
Split this topic
628
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 ?
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.
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
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
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…
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.
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…