Home Assistant Supervised (previously known as Hass.io) on Synology DSM as native package (not supported or working atm)

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 :slight_smile:. 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):

  • 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)
  • We can’t set DNS settings on host

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.

image

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.

1 Like

@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…

1 Like

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 :thinking: 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! :slight_smile: Great job indeed! :+1:

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 :slight_smile:

@fredrike Hi, can you give me a link with the latest stable version for Synology? I do not have a Dropbox account :frowning: .

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.

  1. 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.
  2. 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.

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:
Bildschirmfoto 2020-04-12 um 00.39.45
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:

  1. 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.
  2. insert the USB stick
  3. wait ~10 seconds
  4. ls -lart /dev/ and see what devices are newer than the others, that have a date in the last 30-40 seconds.
  5. 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 …

3 posts were split to a new topic: Nginx SSL plugin on synology install?

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

:slight_smile:

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 :slight_smile:

Thank you for your words my friend! :slight_smile:

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. :slight_smile:
I hope this will help out people somehow…

1 Like