Home Assistant Core -- TrueNAS CORE Community Plugin

troy · May 9, 2020, 12:50am

I would think a fresh install / migrate config will be quicker than trying to fix the existing jail.

Also the 11.3 plugin is slightly improved from the 11.2 version ( you would not get these changes by upgrading the release )

angyp74 · May 9, 2020, 1:45am

Wow, can’t believe it, After I sorted out the pkg version stuff I was able to get FFmpeg installed. So I thought I would try your instructions on radarloop and this time it worked? Thanks a heap. I will look at upgrading soon but.

root@homeassistant:~ # su - hass
[hass@homeassistant ~]$ source /srv/homeassistant/bin/activate
(homeassistant) [hass@homeassistant ~]$ pip3 install --upgrade wheel
Requirement already up-to-date: wheel in /srv/homeassistant/lib/python3.7/site-packages (0.34.2)
(homeassistant) [hass@homeassistant ~]$ pip3 install --upgrade bomradarloop==0.1.4
Collecting bomradarloop==0.1.4
  Using cached bomradarloop-0.1.4-py3-none-any.whl (8.8 kB)
Collecting Pillow
  Using cached Pillow-7.1.2.tar.gz (38.9 MB)
Requirement already satisfied, skipping upgrade: requests in /srv/homeassistant/lib/python3.7/site-packages (from bomradarloop==0.1.4) (2.23.0)
Requirement already satisfied, skipping upgrade: idna<3,>=2.5 in /srv/homeassistant/lib/python3.7/site-packages (from requests->bomradarloop==0.1.4) (2.8)
Requirement already satisfied, skipping upgrade: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in /srv/homeassistant/lib/python3.7/site-packages (from requests->bomradarloop==0.1.4) (1.25.9)
Requirement already satisfied, skipping upgrade: chardet<4,>=3.0.2 in /srv/homeassistant/lib/python3.7/site-packages (from requests->bomradarloop==0.1.4) (3.0.4)
Requirement already satisfied, skipping upgrade: certifi>=2017.4.17 in /srv/homeassistant/lib/python3.7/site-packages (from requests->bomradarloop==0.1.4) (2020.4.5.1)
Building wheels for collected packages: Pillow
  Building wheel for Pillow (setup.py) ... done
  Created wheel for Pillow: filename=Pillow-7.1.2-cp37-cp37m-freebsd_11_3_RELEASE_p7_amd64.whl size=524722 sha256=6351f02109988bc472e70acf2773be977af4d14a19a70a6855d7a9649ef46b0a
  Stored in directory: /home/hass/.cache/pip/wheels/cf/32/de/5148f306c80538c3a88a3c2dece714317dbf484b8fa7bf2916
Successfully built Pillow
Installing collected packages: Pillow, bomradarloop
Successfully installed Pillow-7.1.2 bomradarloop-0.1.4
(homeassistant) [hass@homeassistant ~]$ deactivate && exit
logout

troy · May 9, 2020, 4:12am

I think I finally figured this out – turns out to be some needed options for persistence in the mosquitto.conf

Mosquitto, by default on FreeBSD, runs as user nobody - I could not get this working as user nobody so I created a new, non-root user mosquitto to run the broker.
I also created a directory and set permissions ( this will be location for mosquitto.db )

iocage console mosquitto

# Add non-root user
pw adduser -u 1883 -n mosquitto -w no

# Create directory and set permissions
mkdir /var/db/mosquitto
chown mosquitto:mosquitto /var/db/mosquitto

Finally added the options for persistence to /usr/local/etc/mosquitto/mosquitto.conf

updated example for mosquitto.conf

pid_file /var/run/mosquitto.pid
user mosquitto
port 1883
cafile /usr/local/share/certs/ca-root-nss.crt

persistence true
persistence_file mosquitto.db
persistence_location /var/db/mosquitto/

# Uncomment to require username/password access to the broker
#password_file /usr/local/etc/mosquitto/pwfile
#allow_anonymous false

troy · May 11, 2020, 3:08pm

~~# Attention – Z-Wave is going to break on FreeNAS!~~

Well sort of… If you are using a USB Z-Wave stick, with USB pass through to the Home Assistant plugin/jail please be aware of these upcoming changes! This will directly affect us - Bitter / Sweet

There is currently no plan to deprecate the existing Z-Wave integration. But the hope is that the new integration, in the future, will offer a simpler, more stable and more feature-rich experience than the current Z-Wave integration.

I am open to the possibility of creating a separate FreeNAS plugin for ozwdaemon (aka qt-openzwave) in the future, but as of now, it seems far out reach to accomplish this myself.

~~I’m not sure the exact HA version when the current Z-Wave integration will be replaced but I suggested you begin to prepare now.~~ If you want to use the new OpenZ-Wave Beta, you will need to move your USB Z-Wave to a secondary device that is able to run docker.

I’m using raspbian-lite on a RPI 3 B+ with docker, to run ozwdaemon. I’m powering the PI with POE, so basically, it has just become a simple Z-Wave hub that can be placed in a better location for my Z-Wave network, away from my FreeNAS server in the basement.

Of course, I took some notes – If you’re like me and have never used docker, I’ll have a little “Quick Start” you can follow to set up a PI for running ozwdaemon.

8three · May 12, 2020, 2:44pm

Hi Troy, thanks so much for all you’ve done.

I just finished installing HA on FreeNAS 11.3 using your plugin and it worked great! I followed your steps on getting my Z-Wave USB Stick attached though and just keep striking out. One issue I noticed is that I used your suggested dataset 99, and when I tell the jail to use that dataset it works just fine but as soon as the jail actually starts it switches to dataset 5… So I went through and switched the script from 99 to 5 to see if that would work, still no luck. I’m trying to enter the path to my Z-Wave USB in my HA system, that’s where I’m stuck. Any suggestions?

On this note of yours, are you using your Pi as a gateway for MQTT? This is actually the first solution I had tried last week without success. I ran HA in an Ubuntu Server VM and then had my Z-Wave USB on my Pi gateway and it actually “worked” and I could get my devices into my HA configuration. The problem that I was running into is that most of my devices are dimmers, and even though HA could see them they just wouldn’t function. Is this the system you’re running?

Thanks!

troy · May 12, 2020, 4:28pm

Hello @8three

FN auto-generates these ( starting at 5 ) with some voodoo in the middle-ware, I just picked 99 because it seems unlikely FN would use it.

For what you’re seeing, there is an open issue in iocage

github.com/iocage/iocage

Various issues with devfs_rulesets

opened 07:59PM - 20 Feb 20 UTC

grembo

bug enhancement needs docs

While working on https://github.com/iocage/iocage/pull/1106 I stumbled over a co…uple of issues which should be addressed: - The iocage man page doesn't reflect how devfs_rulesets work these days (it hasn't been updated since the changes to how devfs_rulesets work last year). It e.g. suggests that setting it to "0" would set no ruleset whatsoever (which isn't true). It also should point out that devfs_ruleset 4 is very special and does not consider what is in ruleset number 4. - The devfs_ruleset configuration contains the devfs_ruleset_id the jail currently uses, which always is a dynamically generated one. This means that it is not the configured one, which is used as a template. This can be quite confusing (and leads to issues like the one in #1130). It would make sense to split the devfs_ruleset which the jail uses and the value stored in the configuration on disk. See below for an example why the current behaviour is suboptimal: ``` [root@host ~]# iocage get devfs_ruleset testjail 1001 [root@host ~]# iocage stop testjail [root@host ~]# iocage get devfs_ruleset testjail 4 [root@host ~]# iocage start testjail [root@host ~]# iocage set devfs_ruleset=4 testjail devfs_ruleset: 1001 -> 4 [root@host ~]# iocage set devfs_ruleset=4 testjail devfs_ruleset: 1001 -> 4 [root@host ~]# iocage get devfs_ruleset testjail 1001 ``` - `fetch_plugin` in `ioc_plugin.py` calls `iocage_lib.ioc_common.generate_devfs_ruleset` without doing anything with its return value and therefore leaks resources/pollutes the system with unused dynamically created devfs_rulesets:https://github.com/iocage/iocage/blob/10c218f3df971ab6cc8506cb69f44e4ae3547ba4/iocage_lib/ioc_plugin.py#L258-L315 - There are many ways iocage can leak resources if something goes wrong during `iocage start`, one of them is that it leaks dynamically generated devfs_rulesets - In general, the way devfs_ruleset == 4 was made special last year was kind of unfortunate, as it uses the existing id, but doesn't use the rules the system has configured for this ruleset. It would be nice if there was a way to correct this somehow (e.g. setting it to 0 or not having it configured could trigger the default behavior while setting it to 4 would use the system's devfs_ruleset 4). Make sure to follow and check these boxes before submitting an issue! Thank you. - [x] Supply `iocage --version`: master - [x] Supply the commands used, along with any steps to recreate it: see above - [x] Provide the output from the command you issued: see above - [x] Supply what you expected the result or output to be: see above - [x] Checked that the problem has not already been fixed on `master` if using a stable release: did

There’s a couple ways around this but as usual, require using the console

If you just need to restart the jail, use a -s soft restart

$ sudo iocage restart -s homeassistant
Soft restarting homeassistant (homeassistant)

Otherwise you need to use a three step process

$ sudo iocage stop homeassistant
Password:
* Stopping homeassistant
  + Executing prestop OK
  + Stopping services OK
  + Tearing down VNET OK
  + Removing devfs_ruleset: 99 OK
  + Removing jail process OK
  + Executing poststop OK

## re-enable the rulseset on FreeNAS
$ sudo ./zwave-ruleset.sh 

$ sudo iocage start homeassistant
No default gateway found for ipv6.
* Starting homeassistant
  + Started OK
  + Using devfs_ruleset: 99
  + Configuring VNET OK
  + Using IP options: vnet
  + Starting services OK
  + Executing poststart OK
  + DHCP Address: 10.10.20.25/24

Best thing is, just try to avoid restarting the entire jail - Restarting the HA service will work just fine – My HA jail only gets restarted when I reboot my FreeNAS – and that only happens during a FN update. – Anyways this is not gonna be an issue when Z-Wave is no longer a direct integration with Home Assistant.

I’m using the Mosquitto FN plugin…
Right now, the PI is only running a single docker container with qt-openzwave

I have only used the current built in Z-Wave integration ( and built in zha for ZigBee ). – I have never used a mqtt bridge to anything… In fact, before this upcoming change, I only relied on Home Assistant Core for all critical functions in my home. ( Sure, I already used mqtt, but not for anything critical )

I have moved to UI configuration for Z-Wave – but I still need this entry in my configuration.yaml for my dimmers to work correctly

zwave:
  device_config_domain:
    light:
      refresh_value: true
      delay: 2

Edit:
Just to clarify about Z-Wave and MQTT – The upcoming switch to using ozwdaemon ( aka qt-openzave ) for Z-Wave, will require a using MQTT… Still ozwdaemon is something new, it is not the existing Z-Wave2Mqtt

8three · May 12, 2020, 4:49pm

Thanks so much for the reply!

Before I start the troubleshooting process with your suggestions, would you suggest I find a way to make my MQTT gateway work with my dimmers (on my VM) before trying to get my Z-Wave USB Stick working in the actual FreeNAS install since it sounds like this is going away anyway? My gateway is running Z-Wave2MQTT

The trouble I was running into with my VM install of HA is that I installed with Docker which I believe uses Hass.io and it seems to be tough to get under the hood and play around with the configuration.yaml file. I have the file editor installed but when I view the configuration.yaml file it doesn’t show anything about the devices that I can go in and manually edit. Maybe I’ll have to play around with this more…

I’d love to try the entry you used to get your dimmers working, maybe that would work for my setup as well!

troy · May 12, 2020, 5:12pm

Don’t worry, configuring HA is not considered “under the hood” - If you have file editor - For a simple test, you can just add the entry I shared to the bottom of your configuration.yaml –

8three · May 12, 2020, 5:59pm

Just tried adding your entry to the bottom of the configuration.yaml, still no luck getting my devices working. They all still show, but when I toggle the switch to turn a light on it hangs in the on position for about a second then goes back to off (the light never actually turns on at all). Physically turning on a switch doesn’t change anything in my HA interface. I’ve tried tweaking a number of settings in the MQTT gateway, and nothing I do fixes anything.

Even though this seems the “better” route because of the changes to Z-Wave coming in FreeNAS, I can’t for the life of me figure how to get this working! I’ve spent hours searching around the internet for different settings and examples but can’t seem to find the right one yet…

troy · May 12, 2020, 6:12pm

Yes exactly how it works for me too – except in my case the light is actually changing state – After the delay:2 seconds - HA finally toggles to the correct state – I had to use a as much as delay:5 with some gen1 GE dimmers – with updated switches, I have been able to reduce the delay

You bring up a good point – I am not sure how this will work for me in the future either – I have not tested any dimmers with ozwdaemon, only a spare switch I have laying around

8three · May 12, 2020, 7:24pm

Interesting. I’ve been messing with it for the past hour or so (both my VM instance of HA and the MQTT gateway) and nothing seems to work. Maybe I’ll just rebuild the gateway and start over, and remove all devices from HA and start over there as well. It’s getting quite frustrating trying to get this all to work, was expecting some issues but this has been quite a roadblock for me!

adrianwi · May 12, 2020, 7:28pm

I came along looking for some more help, as updating my Home Assistant jail broke things again, and noticed that Troy had turned the previous installation into a community plugin. I hadn’t used a plugin since 9.3.1 and after some bad experiences trying to update them, learnt enough to create most things as manual jails.

I never got into creating Python environments though, but knowing how well things worked with Troys previous instructions, and the great support he’s provided getting things working, thought I’d give the plugin a spin. Nice and easy to set-up and I’ve been meaning to start again with Home Assistant as my configuration was a mess.

Thanks for all of your efforts Troy and keep up the great work. It’s much appreciated.

CypSteel · May 13, 2020, 8:30pm

@troy, Thank you so much for this awesome work you do. Your tenacity to continue putting out these walk thru’s is super beneficial. The “Not all hero’s don’t wear capes” quote comes to mind.

My question is around the USB Zwave controllers. I upgrade my Freenas 9.10.2 instance recently to 11.3. I ended up just building a brand new Home Assistant instance, but I can’t seem to see my Aeotec Z-Stick Gen5 via a ‘usbconfig’ command. I did follow your guide above around implementing the rules for the jail, but some of your previous guides included installing drivers. Can you comment if I need to install special drivers for Freenas 11.3 for the Aeotec Z-Stick Gen5?

Thanks in advance to anyone who can help!

troy · May 13, 2020, 11:49pm

Hi @CypSteel

All of my recent guides ( and the plugin ) should install everything you need. There are a few exceptions but mostly, I include all dependencies now by default.

The devfs_ruleset should be all you need… There is a bug in iocage to be aware though. If you restart or stop the jail, it will remove the custom ruleset – It’s annoying – If you stop the jail – you’ll need to run the ruleset script again before you restart it – There is more about this a few posts up.

I can say though, if the Aeotec Z-Stick Gen5 is available inside the jail, it will show up as a /dev/cuaU* device. You can use a simple ls /dev to check for the Z-Stick.

 ls /dev | grep cua

root@homeassistant:~ # ls /dev | grep cua
cuaU0
cuaU0.init
cuaU0.lock

CypSteel · May 14, 2020, 1:15am

Thank you once again.

Rafal · May 17, 2020, 5:33pm

Many thanks for your plug-in. I have tried it, and I am glad to say it works, except for the Homekit integration, see this issue on GH. I think it is because /usr/bin/openssl is a much older version, and installing the newer from ports requires a change to the PATH: it looks like HA is taking it from /usr/bin, as per the system-wide path order. Looking at your rc.d/homeassistant script I saw that sh is used to run hass so I created /home/hass/.profile containing a re-ordered path. This made the error about the missing ChaCha algorithm go away, but I am afraid Homekit still does not work for me: the iOS Home app still returns Couldn't add Home Assistant Bridge error, but this time I do not see anything in the HA log. Indeed, HA thinks it has paired, but on restart it goes back to wanting to pair-up. Do you have any pointers how to debug that?

On another note, I was wondering to what extent I could customise a jail created using your plug-in and not lose those customisations upon update. In my other jails I like to have my standard ssh, zsh+oh-my-zsh set-up and a few other bits and bobs. From what I have seen in other FreeNAS plugins they can take a rough approach to updates, effectively deleting prior configs. Do you have any feelings about that?

Finally…I also use ZWave, though it runs on a remote Pi, over socat/ser2net. I’d rather keep the Pi light-weight and keep all real processing on the FreeBSD server. I hope you figure something out before the big change comes.

Many thanks again for your valuable time.

troy · May 17, 2020, 11:36pm

Hi @Rafal

You are correct about the issue with openssl version and Home Kit. Sorry, I do not own any Apple or Home Kit devices to help trouble shoot a work around or solution. If anyone figures this out, I will include the required changes to the plugin. – At very worst case, this will finally be resolved in TrueNAS 12 since we will finally have an updated base.

That is just the way the “plugin update” works – rather than simple update, all non-base packages are removed, then reinstalled according to what is included in the manifest. The configuration files should not be removed during this process. Normally this means anything not included in the manifest would be removed with every update… In this plugin however, I have included a step that should automagically reinstall anything you have installed outside of the included packages in manifest.

Mostly this plugin is about providing an easy install and some scripts for convenience. This is not intended to be a managed system that does everything for you – With this in mind, I see no reason to prevent you from adding your own bits and bobs. - I would only caution that you mind these files included in the overlay – These files are always replaced when running a “plugin update” so any manual edits will be lost.

I’ve already got a PI setup with a single docker container to run qt-openwave. When HA 0.110 is released, I’m going to start using the new OpenZWave Beta integration

troy · May 19, 2020, 4:42am

I’m glad I was wrong about the current Z-Wave integration being removed.

This is mentioned in the 0.110 release blog

There is currently no plan to deprecate the existing Z-Wave integration. But the hope is that the new integration, in the future, will offer a simpler, more stable and more feature-rich experience than the current Z-Wave integration.

It’s too late for me though. I already drank some of that sweet, new integration cool-aid. There’s no turning back now

troy · May 20, 2020, 6:10pm

OpenZWave (beta) has arrived!

From the 0.110 release blog under “OpenZWave integration now in beta”

If you want to give it a shot, you should be comfortable with setting up custom add-ons and MQTT. There is no migration from the current Z-Wave integration yet, this is still to come.

The plan is to add more platforms in the future, making it super simple to set up the integration. Stay tuned.

There is currently no plan to deprecate the existing Z-Wave integration. But the hope is that the new integration, in the future, will offer a simpler, more stable and more feature-rich experience than the current Z-Wave integration.

The OpenZWave (beta) integration connects to ozwdaemon.

ozwdaemon is provided by qt-openzwave. In other words, ozwdaemon == qt-openzwave, They are the same thing. You may hear either term mentioned around the forums or on discord.

Unfortunately, there is currently no easy solution for running qt-openzwave on FreeNAS but do not despair, the is still a relatively easy solution. As I mentioned before, I have moved my Z-Stick (from my FreeNAS) to a RPI 3B+ running Raspbian Buster Lite with Docker to provide qt-openzwave. There are already, many guides and videos to provide details about installing and using both Raspbian and Docker. Based on such guides, I have put together an outline of the minimal steps I used to setup my RPI for running qt-openzwave.

Outline: Minimal steps to use a RPI for qt-openzwave

adrianwi · May 21, 2020, 1:37pm

I’ve been playing a little more with this over the past few days, and Home Assistant is certainly feeling a little more polished since I last played with it in anger. It’s much easier to configure now, and most of the things I’m using could be setup without even looking at a .yaml file

I’ve just setup NGINX Proxy Manager, which looks like a much nicer way of managing all my external services rather than manually editing nginx.conf files in a jail. There’s a plugin for HA, but it looks to be using a different ‘store’ to the one installed here. Is this something that would be easy to add?

Thanks again!