Home Assistant Core -- TrueNAS CORE Community Plugin

Did you ever find any solution to this? I am encountering the same thing - trying to run aiosenseme from the jail shell or the truenas shell (or do raw UDP broadcast) results in the same thing. Points to it being a truenas configuration or issue?

No.

I gave up and moved to a docker image on a linux host (I refurbished an old Pine64 board for that)

I’m going to guess that is something to do with the jails using VNET. Even in my own setup. I’m not sure why some integrations seem to always be detected (brother printers, chrome-cast, wled) but others remain a PIA to get connected (Logitech Harmony and Emulated HUE)

This is one example why I’m curious if anyone is thinking about switching over to TrueNAS SCALE , when it’s released next year. The most obvious reason I wonder about this, is do to the number of available docker contains VS available iocage plugins.

All the Kubernetes stuff is way over my head… but I understand this part

SCALE allows Kubernetes to be disabled. The user will then have access to the native container services within Debian. This will include Docker, LXC (Q1 2021) or any other Kubernetes distribution.

I can already tell you, I have successfully converted a test machine from TrueNAS CORE to SCALE. Since both platforms use the same middle-ware, the web UI is largely the same. I had no trouble importing a zpool (that contained a dataset with my HA configuration) I had previously created on CORE. While SCALE has only released the first ALPHA build, some feature are still incomplete. Among others, there is not yet a UI for managing containers. Still, I was able to install Home Assistant using docker-compose in a matter of minutes. I pointed the /path/to/config at my existing dataset and HA started up the first time, just like I had left it!

Interesting, I’ll have to do some reading on SCALE. Glad your test was so successful - I think in the long run, linux will definitely be easier to work with than BSD.

@jyavenard @troy I dug into this a bit further and it seems that it has to do with the way that BSD handles UDP broadcasts - won’t forward them to multiple interfaces and has some opaque (to me) logic about how they are routed. You can read more here: https://www.freebsd.org/cgi/man.cgi?ip(4) (search for IP_ONESBCAST). I wrote a little python script to broadcast over UDP and then used tcpdump to figure out what the packets looked like. They were sending to 255.255.255.255 - but who knows if they actually made it to a real network interface (see link above). On my Mac (ironically BSD based, but I’m sure this has been addressed), the packets are sent to my default NIC’s subnet (in my case 192.168.1.255), and are broadcast out to all hosts on that subnet.

As a quick and dirty workaround for Haiku SenseMe, you can pop into your jail’s copy of the aiosenseme library and force it to broadcast to a specific subnet’s broadcast ip. Force the subnet by changing

sendto(message, ("<broadcast>", port))
to
sendto(message, ("192.168.1.255", port))

in your local copy of aiosenseme (for me it was located in /usr/local/share/homeassistant/lib/python3.8/site-packages/aiosenseme/discovery from the jail shell).

Changing this allowed me to run senseme discovery and found my devices. This hack will probably break any time the integration is updated, and I’m not even sure if it’s required past the discovery phase. Sounds like both of you have found workarounds, but wanted to post this here in case it’s helpful. I think maybe a more robust fix would be for affected integrations to stop relying on the broadcast shortcut and either iterate through network interfaces and send broadcast packets to each individually, or allow the selection of an interface as an option.

edit: quick follow up to note that python doesn’t seem to support the IP_ONESBCAST socket option, even when specified as an integer (I looked it up, it is 23). It’s possible that setting that option if available would fix it. If I’m bored later I’ll try that out in C (or a quick googling shows that Ruby supports it).

:warning: Attention FreeNAS usersThe FreeBSD 11.3-RELEASE is now past it’s EOL date .

This has been causing various issues for this plugin on FreeNAS , that seem beyond my control. To my understanding, as packages in the FreeBSD repos have been updated, some are no longer compatible with the 11.3-RELEASE. From the limited number of Google results I can find, the solution is upgrading to a supported RELEASE.

I am not able to support using this plugin with the expired 11.3-RELEASE base.


At this time, ix-systems has no plans for switching the FreeNAS plugins to the 11.4-RELEASE and I have not found another way to make a plugin use the next release. - To my knowledge, using the 11.4-RELEASE can only be accomplished by manually creating jail.

This leaves two options:

  1. Manually creating an 11.4-RELEASE jail on FreeNAS 11.3
  2. Switch your FreeNAS to the TrueNAS-12.0-Stable train

There are several people who have opted for upgrading to TrueNAS Core. So far, everyone has been able to restore Home Assistant to full functionality after doing so. If your ready to upgrade, I think this is the best option. An updated version of OpenSSL is already included in the FreeBSD base, which requires no workarounds for Home Assistant. Other issue that are appearing in the 11.3-RELEASE, simply do not exist.

I’ve started a wiki page to help get your existing plugin working again on TrueNAS Core

Plugin Upgrade from FreeNAS to TrueNAS Core

2 Likes

I recently upgraded to TrueNAS and have upgrade all my jails except homeassistant. I am having an odd problem running the upgrade on my 11.3 plugin. I have successfully upgraded other plugins with this approach, but I’m not sure how to proceed here. Any thoughts would be appreciated.

The homeassistant.json file exists and is readable in the iocage/jails/homeassistant directory. There are no errors that I can see in it’s formation… Odd

Error:

# iocage upgrade homeassistant
Snapshotting homeassistant...
Snapshot already exists
Updating plugin INDEX...
A plugin manifest matching homeassistant could not be found!

I have been using it for quite a few days now, maybe like a month?
And its pretty good, I actually like having Node-red separated from HASSIO in case anything happens to the HASSIO install…

does anybody else seem to have a “slow” performance when loading entities history? Mine is taking a few seconds to load and show the graphs, when it was done instantly on my old Managed HASSIO Install

Hi @davids777 - This is an odd error indeed – I think I’ve seen this happen before with others as well. I can’t remember exactly how ATM but I’m pretty sure I was able to get it resolved.

Any chance this is a simple oversight? Please use the next command to list your jails and confirm the name your $_JAIL_NAME is in fact named homeassistant

iocage list

Have you tried to REFRESH INDEX (be sure to select community from the drop down menu first)

Also please confirm the homeassistant.json is also in the following directory

iocage/.plugins/github_com_ix-plugin-hub_iocage-plugin-index_git/

Finally please check and share with me the output from these to commands

iocage get plugin_name $_JAIL_NAME
iocage get plugin_repository $_JAIL_NAME

Troy,

thanks for responding:
refreshing the index didn’t change the behavior

#Iocage list
+-----+---------------+-------+--------------+--------------+
| JID |     NAME      | STATE |   RELEASE    |     IP4 
+=====+===============+=======+============
+-----+---------------+-------+--------------+--------------+
| 8   | homeassistant | up    | 11.3-RELEASE | DHCP     
+-----+---------------+-------+--------------+--------------+

#ls iocage/.plugins/github_com_ix-plugin-hub_iocage-plugin-index_git/homeassistant.json
-rw-r--r--  1 root  wheel   905B Oct 31 00:14 .plugins/github_com_ix-plugin-hub_iocage-plugin-index_git/homeassistant.json

[root@freenas /mnt/zfs_data2/iocage]# iocage get plugin_name homeassistant
homeassistant

[root@freenas /mnt/zfs_data2/iocage]# iocage get plugin_repository homeassistant
https://github.com/tprelog/freenas-plugin-index.git

I think this is the problem

Please try switching your plugin to ix-system repository (Edited to add missing =)

iocage set plugin_repository=https://github.com/ix-plugin-hub/iocage-plugin-index.git $_JAIL_NAME
[root@freenas /mnt/zfs_data2/iocage]# iocage set plugin_repository https://github.com/ix-plugin-hub/iocage-plugin-index.git homeassistant

plugin_repository is is missing a value!

:man_facepalming: Sorry, forgot the =

iocage set plugin_repository=https://github.com/ix-plugin-hub/iocage-plugin-index.git homeassistant

That did it! Thanks.

1 Like

Interesting side note: After running iocage upgrade homeassistant, I had to update the jail via the UI as the upgrade process left the jail in a bad state, missing many key libraries and packages. Fortunately, the “update” process via the UI is robust enough to address that issue and re-install much of what was missing. Weird stuff.

There’s been a few people that have had similar trouble immediately after the upgrade. Another user had informed me of these commands, which also seems to correct the problems.

pkg-static update -f
pkg-static upgrade -f

I never thought to try that. It makes sense when you say it though.

When you update the plugin via the UI, it is not just running a pkg upgrade.

Instead it works by first removing all FreeBSD packages that have been installed, then packages are reinstalled according to what is listed in the most recent plugin manifest.

Thanks for letting me know that works well.

Hi Troy. I just casually ran the HomeAssistant update from the shell menu and I got an OpenSSL runtime error and my instance is no longer working. Any ideas?
Error reads “You are running against OpenSSL 1.0.2 which is no longer supported by the OpenSSL project” and tells me I need to upgrade it.

Hi @axg20202

I might suggest trying to upgrade openssl, however the 11.3-RELEASE has now past it’s EOL date. I’m no longer able to support using this plugin with the expired release

Please read this post for more info, before attempting to upgrade openssl in your 11.3-RELEASE jail.

Great, thanks Troy. Somehow I skipped past that post! I might go for the TrueNas upgrade route. I assume people are updating their jails to 12.1 as part of this process?

1 Like

Yes, but it’s a two step process

  1. Upgrade to TrueNAS
  2. Upgrade your jails

The latter is not automatic, and must be preformed separately for each jail.

After the upgrade, this plugin will be using either 12.2-RC3 or 12.2-RELEASE.

1 Like