I’ll make sure that this is not happening for the next version.
I think the latest version of hass-audio have fixed this:
That is the intended behaviour, and there is actually no other way of doing the setup.
You should not need to reinstall the package, just starting/stopping it seems to do the trick. If it’s not an issue with downloading the containers (@chickenandporn had a comment about making sure that the containers existed during package startup).
Thank you, but can you give me the link to be able to download the latest stable link? I have issues with the current install - it crashed, and I need to rebuild it from scratch - I hope I can import the backups. If not, I am in a big mess.
Thank you very much.
So im triying to get my bluetooth stick working and always getting this error:
Error looking up Bluetooth device
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/bluetooth/bluez.py", line 31, in discover_devices
lookup_class=lookup_class, device_id=device_id)
_bluetooth.error: (4, 'Interrupted system call')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/bluetooth_tracker/device_tracker.py", line 140, in perform_bluetooth_update
devices = await hass.async_add_executor_job(discover_devices, device_id)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/bluetooth_tracker/device_tracker.py", line 62, in discover_devices
device_id=device_id,
File "/usr/local/lib/python3.7/site-packages/bluetooth/bluez.py", line 34, in discover_devices
raise BluetoothError ("error communicating with local "
bluetooth.btcommon.BluetoothError: error communicating with local bluetooth adapter
Can anyone help me out here pls? My brain is exploding … im trying to get this to work since a few hours. My stick is recognized by the Synology and also showing devices in the bluetooth section. The Stick is on hci0 , which I also set in the configuration.yaml…, I still always get this error. Do I need to give other rights to the docker container maybe?
This is what I see in the Hardware-Section:
My usb_devices.txt file is empty…
I’m assuming you’re logged into the Synology running Fredrike’s SPK, and you’re not seeing bluetooth in the container. You might be able to do it this way:
ls -alrt /dev/ to see what devices are there. You’ll see that most have the exact date as when you started your Synology. Make a quick note of the ones that are different. with -lsrt you’ll see them at the bottom of the list of devices.ls -lart /dev/ and see what devices are newer than the others, that have a date in the last 30-40 seconds.docker exec -it homeassistant bash -c 'ls -lart /dev/' to repeat the check in the homeassistant container.I think Fredrike has done some additional work on top of bog-standard hassio to make very predictable devices based on type. If you’re just wanting to see them appear, this can give you a clue. I would expect the device to appear in both the host Synology, and the homeassistant container.
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
Typing docker exec -it homeassistant bash -c 'lsusb' shows me this:
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 …
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 just need someone to talk with me
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
Thank you for your words my friend! 
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?
Same problem here. I have try different solutions, reboot, reinstall and clear but with no luck.
@fredrike any other tips to try to fix it?
Thank you!!
What kind of problem are you referring to?
I have /api/hassio/app/entrypoint.js. error with hassio_supervisor container loop rebooting.
Thanks
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:
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?
@fredrike what are the benafits of this install over using synologys own Virtual machine manager?
I followed this guide originally: https://www.home-assistant.io/docs/installation/synology/
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.
Love to hear some input from you guys.
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.
THANKS
It gives better performance but also have some issues (the fast development of ha makes it hard to keep track of all changes).
@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?
THANKS
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.