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:
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):
We can’t control the host system (restart services on Synology)
We can’t read the hostname of our Synology (I’m not sure where it is used)
We can’t update the host-OS (which wouldn’t make sense anyway)
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'
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…
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 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.
First of all, the installation removed my container and replaced it with it own which basically not a big issue since all configuration files from my instance remain on Synology and I had not much configured there. Though I could be an issue for other people.
I managed to run hass.io after 3 times reinstalling SPK and removing all related containers. The issue was that I got whether empty page when clicked on “Supervisor” tab or the tab gave me know error “Unable to load the panel source: /api/hassio/app/entrypoint.js”. I think that the approach described in sticky topic in this thread “Current issues” can break installation. Because after I cliced “clear” on hassio_supervisor it did not start anymore looping with exception “cannot find docker socket”.
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.
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.
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:
with the bluetooth USB stick not inserted, do a 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.
insert the USB stick
wait ~10 seconds
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
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…
. I just remove the 
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.
.
