Here it is: Dropbox - File Deleted - Simplify your life
This version is supposed to fix it (I never had this issue though): Dropbox - File Deleted - Simplify your life
It is the supervisor’s job to start homeassistant, I’m not sure what is going on there. Did you save the logs?
Hi @fredrike !
Thanks actioning so quickly and for the reply.
No, actually I haven’t 
But next time if something fails - I definitely will.
I decided to play a little bit with this package (as I’m running it in parralel for now with my HA Core and this was a clean install, so I don’t lose anything) as I thought you’d like to get some feedback how does it go to fix any bugs for the future releases.
I uninstalled the package from SynoCommunity and here my observations after uninstall:
hassio_audio, hassio_cli and homeassistant containers stayed in Docker. Addon containers were removedhass.io folder stay after uninstall? It stayed in my case. Actually I wonder what happens when I install the package again. Is it recommended to remove the folder priori reinstallation? Can any conflicts occur?Then I decided to give a try of two attempts - with the hass.io folder intact and without it (again a clean install). Every time I tried - I deleted the remaining containers (homeassistant, hassio_cli, hassio_audio).
I. 1st attempt
I left the hass.io folder, and planned to remove the audio group, but I forgot to do this prior installation of the package version from your Dropbox and the installation failed saying that it cannot create group:
Probably it was about the audio group. I think it’ll be good to handle this in the install script and not create one when it exists or ask the user what to do (delete and recreate or leave it).
The installation succeeded anyway and all containers got up! 
Including the homeassistant container. So no error this time (not sure why did this happen the first time I installed te package - perhaps some docker issue.
Addon containers were recreated. All went back to the state before uninstall which is great!
II. 2nd attempt
Removed the audio group in DSM GUI prior installation and installed the package from Dropbox you provided.Also removed the hass.io folder prior the installation
Here’re my observations:
, but seems it doesn’t do anything wrong with the installation. Perhaps not necessary to show it?hassio_audio - problem fixed Independently from the approach I took there are warnings in logs - probably related to the fact that Synology is not the officially supported platform.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.systemd] No systemd support on the host. Host control has been disabled.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.hostname] No hostname support on the host. Hostname functions have been disabled.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.rauc] Host has no rauc support. OTA updates have been disabled.
20-03-31 16:15:29 WARNING (MainThread) [supervisor.dbus.nmi_dns] No DnsManager support on the host. Local DNS functions have been disabled.
But do you know what each of them means to us? What functionalities are missing in this package comapring to e.g. installation on RPi becuase of this?
Thanks again for the great work!
Well, it is supposed to remove all containers with this snippit that is executed during uninstall:
docker rm --force hassio_supervisor hassio_dns
if [ `docker inspect --format='{{.Config.Image}}' homeassistant|grep -q homeassistant/qemux86-64` ]; then
docker rm --force homeassistant && docker image rm ${HOMEASSISTANT}
fi
docker image rm ${SUPERVISOR} ${HASSIO_DNS}
docker network rm hassio
if [ "${wizard_remove_addons}" == "true" ]; then
# Remove addons
ADDONS_FILE=$(jq -r '.data + "/addons.json"' ${CFG_FILE})
docker rm --force $(jq -r '.user| keys| map("addon_"+.)| join(" ")' $ADDONS_FILE)
docker rmi --force $(jq -r '[.user | keys[] as $k | .[$k].image] | join(" ")' $ADDONS_FILE)
fi
Yes it should stay, it contains good stuff . I just remove the config.json file. You should not need to touch your hass.io` folder.
# Move config.json so hassio_supervisor will create a new homeassistant container.
mv "${HASSIO_DATA}/config.json" "${HASSIO_DATA}/config-$(date '+%s').bak"
Good, and I guess you are testing with the hassio_x64-6.1_20200330-1.spk file.
The whole audio group issue is magical for me as I can’t reproduce it. I’m just following the suggestion from @raphii. Perhaps he have more info on how to make it fully transparent during installation.
I must mention that I’m running core 0.107.5 with supervisor 214 without audio group in my system:
fer@SynHome:~$ sudo synogroup --get audio
Lastest SynoErr=[group_db_get.c:26]
SYNOGroupGet failed, synoerr=0x1800
It would be interesting to see if you can do an installation without the audio group now. (I’m really close on moving to hassio live so will not have much possibility to test more)
It means that we might miss some things (I don’t consider any of them crucial):
Edit: This is the script used for installation/upgrade/uninstallation: spksrc/spk/hassio/src/service-setup.sh at 7abccb3988f59f16613d1ef40d05b528833fae33 · fredrike/spksrc · GitHub
I’ve just installed this and it’s mostly working great, but I can’t connect to the cloud, it says it cannot connect. I also noticed that the DNS container keep stopping and the seems to get recreated every few seconds.
In the log for the container I see this
/config/corefile:16 - Error during parsing: Unknown directive 'fallback'
The logs are full of these errors
20-04-03 08:42:32 ERROR (MainThread) [supervisor.dns] Can't start CoreDNS plugin
20-04-03 08:42:32 ERROR (MainThread) [supervisor.tasks] Watchdog CoreDNS reanimation fails!
20-04-03 08:42:52 WARNING (MainThread) [supervisor.tasks] Watchdog found a problem with CoreDNS plugin!
20-04-03 08:42:52 INFO (MainThread) [supervisor.dns] Start CoreDNS plugin
20-04-03 08:42:52 ERROR (SyncWorker_10) [supervisor.docker] Can't create container from hassio_dns: 404 Client Error: Not Found ("No such image: homeassistant/amd64-hassio-dns:3")
20-04-03 08:42:52 ERROR (MainThread) [supervisor.dns] Can't start CoreDNS plugin
20-04-03 08:42:52 ERROR (MainThread) [supervisor.tasks] Watchdog CoreDNS reanimation fails!
What’s the best way to restart HA when running this? Server Controls don’t appear to actually restart anything, I find I have to manually stop and start the docker container for anything to happen.
@fredrike: I just tested the installation on a new DS918+. No Audio group needed.
I’ve seen that the audio container checks at startup, if the kernel has audio-support.
I’ll test this again with Audio Station installed.
EDIT: I’ve tested it with Audio Station installed. Works like a charm. Even my USB speaker is working again with hass.io-audio containers like my snapcast-client container or spotify connect.
Maybe the guys at hassio-audio have fixed some stuff…
Can anyone help me here to integrate a bluetooth dongle connected to a ds218+? Is it possible to ingerate in in HA?
Hi, I get an error on login (see Hassio: login not working from custom domain with SSL - #3 by Djiest) and I think I need to configure something in my firewall or router, but I’m not sure what. Can you elaborate?
Yeah, it looks ok, but for some reason removed only addon containers 
I uninstalled twice and both times the core HA containers stayed intact. When you do the same on your Synology does it remove them? Not a big issue tough.
Yes
That’s not a major issue. It’s only aesthetics. I imagine some users don’t have this problem. DSM looks and feels the same on all Synology NAS devices, but in details it isn’t the same. Under the hood there are various differences. Perhaps that’s the reason why some experience this, and some not. I own DS216+II model running the newest DSM 6.2.2
Yeah, I did this already as described. The installation went fine. The audio group was created by the install script. The only drawback was the info message I mentioned. Again just aesthetics.
I don’t use the package much, but setup some integrations and they all work fine in the background. The core container runs smoothly. No sudden stops or hickups, so I’m also thinking to migrate to it and run it productively within a month. I tested upgrade from 0.107 to 0.108.2 today triggered from Supervisor - all went smooth. Looks like everything I want works fine, which is great! Great job indeed! 
Thanks for the explanation. All of these are not important to me and I would even don’t want some of them to work (like hostOS update).
Thanks again for all the good work. Running hass.io instead of just HA Core is a whole new UX level to me
@fredrike Hi, can you give me a link with the latest stable version for Synology? I do not have a Dropbox account 
.
Thank you very much.
@fredrike I really appreciate your amazing work on Hass.io integration with Synology. It is absolutely useful project and this soft and your support are excellent!
I do understand that it is beta so I expect some issue along the way. This is what I found. I had hass-core container on my Synology installed from Synology docker Registry.
I observed the same for both hassio_x64-6.1_20190709-1.spk and hassio_x64-6.1_20200330-1.spk
Let me know if you need more info on the issue.
Thank you one more time for your amazing work.
Slava
@lostprophet you don’t have to have Dropbox account. There is little link at the bottom of download page something like “Continue with view”
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.