Thank you for replying, since I just need someone to talk with me :D:D
1.: What do you mean by “assuming you’re logged into the Synology running Fredrike’s SPK”? Yes, im running Frederikes SPK installed via the Community Store. I was one of the early user and never had issues. Its just the Bluetooth Dongle that is driving me crazy.
2. Where should I do the command? There is a terminal window in the docker container (wich I can’t use somehow), and the regular terminal of my macbook (with this I’m logging in via SSH to the Synology).
3. Doing a ls -alrt /dev/ is giving me a huge list. These are all possible interfaces maybe?
4. Doing a docker exec -it homeassistant bash -c 'ls -lart /dev/' is giving me nearly the same?
Typing lsusb shows me this:
Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 003: ID f400:f400
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID f400:f400 Synology DiskStation
Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Does this mean, that the docker is reading the bt-dongle correctly?
EDIT:
I recognized also something else. When I insert this command docker exec -it homeassistant bash -c 'bluetoothctl' I get this result:
Waiting to connect to bluetoothd...dbus[822]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5905.
This is normally a bug in some application using the D-Bus library.
D-Bus not compiled with backtrace support so unable to print a backtrace
I really don’t know how to fix this. I appreciate any help …
Tinkerer
(aka DubhAd on GitHub)
Split this topic
599
Okay… this I weird. I have absolutely no clue what I did, but now its working. I have still no other hardware added. I still get the “D-Bus error” but don’t get the “Bluez.py” error anymore.
One thing that I changed was this:
Checking synoservice --status bluetoothd showed me this:
Service [bluetoothd] status=[disable]
required upstart job:
[bluetoothd] is start.
I started this first with synoservicecfg --start bluetoothd.
I also switched the hci0 to down with hciconfig hci0 down and switched it back to up with hciconfig hci0 up.
After doing this I restarted the Synology.
I don’t know if this had something to do with it, but I don’t think to be honest. I also realized, that there were bluetooth devices added yesterday while trying. I don’t know how, but it is working now and debugging the device_tracker shows me, that it is searching for devices.
EDIT: I still get the Bluez.py Error, but the tracker is working… so I don’t care about it anymore.
I see you’ve got the problem solved, but it might be difficult to repro the solution (" I have absolutely no clue what I did, but now its working"). It’s important to record as much of the solution as you can in this thread or a blog episode that google can find: the next person can repeat your steps, and might see what part fixed it.
Maybe it’s key that your Synology started with the bluetooth connected, maybe that made hci start up properly by detecting the USB at boot rather than hot plug.
FWIW,
ls -alrt /dev/ is giving me a huge list
it will. The key is that the new things are at the end of the list. That steps 2-4 are about looking for devices to be added without sifting logs, but you’re clearly much more skilled. Leaving these notes for the next person.
Does this mean, that the docker is reading the bt-dongle correctly?
I think you’ve found a better way to see that your bluetooth is available. Nice work
Well, I just tried to list all things that I did, but I don’t know which part did the trick, since there was no part that did the trick :D:D … sound weird but yeah. Maybe it worked from the beginning, since the errors are still present. But since the devices are tracked correctly now… which was my target, I don’t care anymore.
I hope this will help out people somehow…
Hi, this package is awesome, and has been running great for a while. I decided to remove it and start again as my system was a mess. I’ve updated everything and am running HA 108.3 but my supervisor container is rebooting every few minutes. I’ve stopped the package and cleared the supervisor docker but it’s still doing it. Any thoughts?
Running your latest package with Home-Assistant version 108.5
Everything works fine, except every few days ZHA doesn’t work anymore (HUSBZB-1)
all the devices appear “Unavailable”
I tried:
restarting Home-Assistant from “config/server_control”
unplug/replug HUSBZB-1
listing the usb devices through SSH lsusb (it shows up just fine)
but that didn’t bring it back.
Only solution so far was to reboot the whole NAS.
This is not specific to version 108.5, been noticing it since at least version 100.0 (don’t remember)
Any trick?
Hi. I’m using Hass.io on Synology from the package center and am getting this error: “curl: (6) Could not resolve host: plex.tv”. I found issue #7 in hassio-addons github saying what to do. I’ve created this file /etc/docker/daemon.json on my host Synology NAS with my router ip and 1.1.1.1, and restarted the NAS. Still not working. Any ideas?
It says the using VMM was better then docker because of the issues with TCP/UDP port conflicts and USB dongles.
Assuming its correct this install is not as good as VMM? But is that correct?
What I can’t figure out is this? Using a VDI image on synology VMM I CAN NOT get samba addon to show shares on my network under the hassIO IP. However I went ahead and did a second install this time inside the docker package you made for synology. Whats interesting is samba now works and I want to know WHY?
I believe it has something to do with the shared IP between the NAS and the Hass.io install. In one case (docker) the IP is shared and in the other synology VMM its not shared. I thought a seperate IP was an advantage at first but maybe not.
Also I have surveillance station running on my synology and wonder has your package been updated to deal with the IP conflict? I think the answer is YES because when I look under network i see bridge and hassio with 172.17 and 172.30 respectively. So does this note still apply?
Synology packages that show network information such as the VPN and Surveillance Station package does not play nice with the way the hassio network is created. The workaround is to remove the hassio network from the Docker -> Network panel and create a network with the same settings (IPv4, Subnet: 172.30.32.0/23,IP Range: 172.30.33.0/24, Gateway 172.30.32.1) and assign all related Home Assistant containers to that network.
@fredrike Well I tried virtual machine manager on my synology and hit a road block with samba shares. They would not work no matter what i did.
Samba works great in docker so I’m moving over to docker but now I wondering about.
The issues in your note about surveillance station, Is that still a concern? does the internal network using 172.30 and 172.17 address this or no? It seems when I installed i did not need to make any changes, is that right?
Is the USB issues with docker a problem i’ll be running into? or is that also fixed in your latest beta?
Hi!
I have used this package for a long time, but on my system it is very unstable.
Every time I need to restart the Home Assistant I have to pray to get it working again.
I need to restart Synology several times for hass.io to work. I have reinstalled the system several times and I am almost giving up on using Home Assistant in Synology.
Is there a more stable way to install Hass.io on Synology?
Im using Hassio with Docker on Synology.
You either run HomeAssistant-core in Docker (without addon capabilities), or you use this package (which might have some drawbacks) to get an almost complete hass.io experience. Hass.io is a dockerized solution where the supervisor is controlling Docker and several Docker containers.
Hi @fredrike!
Sorry for not explaining my installation correctly. Im using this package on synology, however every time that i needed restart the Home Assistant the system crash and i have to restart synology several times until it works again.
Is there a more stable way to use hassio on synology?
@doors.sl are you using xpenology by chance? If you are xpen is super picky over hardware and my guess is you are seeing a hardware issue surface with hass.io. Just an idea. I also have xpenology but I have a very similar board to a real synology and it works the same as the real deal.
Its not as straightforward as you would think because synology does not have git or apt and the docker command line option listed on that git repo does not work for the synology docker.
Anyway love your input on this?
I also still wondering about your notes on surveillance station causing issues with hass.io. (so far I’ve seen none) so is this just an old issue that no longer comes up? Or something else? I was seeing issue with samba for a bit but its gone now, the IP address of my synology is shared with the hass.io and it works, which is kinda amazing. Also curious about the USB note, again is that just an old issue since fixed?
