Home Assistant Core -- TrueNAS CORE Community Plugin

Ok, so from what I understand.
If I use the TrueNAS gui to update the jail, it will update your files(rc.d/startup, etc).
And if I want to update HA itself, I can do it from the Jail’s shell?

Yes, also using the TrueNAS gui updates the jail its self - basically the same as running pkg update and pkg upgrade

You got it!

1 Like


I’ve been having some problems with my current supervised Hassio, so I will give this TrueNAS a go tonight :slight_smile:

Hi there, thanks for instructions, upgrading python worked ok but when running the reinstall command I get:

/usr/local/etc/rc.d/homeassistant: unknown directive 'reinstall'.
Usage: /usr/local/etc/rc.d/homeassistant [fast|force|one|quiet](start|stop|restart|rcvar|enabled|describe|extracommands|check_config|restart|test|upgrade|status|poll)

So I tried upgrade, it upgraded from 0.116 to 0.116.2 but when I test the homeassitant it still shows python version 3.7.6. How to overcome that?

Ok, so I have a question that is a little offtopic, but still related.
Where can I set up users for your mosquitto TrueNAS plugin?

Hi @adorobis

/usr/local/etc/rc.d/homeassistant: unknown directive 'reinstall'.
Usage: /usr/local/etc/rc.d/homeassistant [fast|force|one|quiet](start|stop|restart|rcvar|enabled|describe|extracommands|check_config|restart|test|upgrade|status|poll)

Seems like your using an older version of the rc.d script. Please update the plugin itself using Plugins > (select your Home Assistant jail ) > UPDATE from the FreeNAS UI – after updating the plugin itself, the following should work. (when asked, answer YES to also clear the pip cache)

iocage console $_JAIL_NAME
# Press 0 to exit the menu
sysrc homeassistant_python=/usr/local/bin/python3.8
service homeassistant reinstall

@YamiFrankc, I’m glad you asked - There have been some recent contributions to that plugin by @sam-harry, allowing some basic configuration using iocage set commands!

Using the TrueNAS shell, NOT the jail shell

  • Change allow_anonymous setting to false
iocage set -P allow_anonymous=false $JAIL_NAME
  • Add users to the default password file
iocage set -P adduser=username,password $JAIL_NAME
  • Delete users from the default password file
iocage set -P deluser=username $JAIL_NAME

mosquitto can also be configured from inside the jail, as shown in the official docs.

iocage console $JAIL_NAME

The configuration file is located at


Examples using mosquitto_passwd

  • Add a user to a new password file
mosquitto_passwd  `-c`  /usr/local/etc/mosquitto/pwfile  `ral`
  • Delete a user from a password file
mosquitto_passwd  `-D`  /usr/local/etc/mosquitto/pwfile  `ral`
1 Like

@troy thanks for quick reply. The update fails and rolls back from snapshot. The last message shown is pkg.FreeBSD.org could not be reached via DNS, check hacore's network configuration
But I don’t think it is correct message as I can access that domain from the jail. Where are logs stored so I could check what is going on?

I’ve found it. I should have updated the plugin from jails menu not from plugins (or is it the same?). Anyway, the second attempt worked ok and I’m on python 3.8.6 now :slight_smile:
But after the update I have some other errors:

INFO:homeassistant.util.package:Attempting install of PyNaCl==1.3.0
ERROR: Failed building wheel for PyNaCl
ERROR: Could not build wheels for PyNaCl which use PEP 517 and cannot be installed directly

and in the log:

2020-10-13 18:39:53 ERROR (MainThread) [homeassistant.setup] Setup failed for mobile_app: Requirements for mobile_app not found: ['PyNaCl==1.3.0'].

Any suggestions? Tried to install this package manually with pip but with the same effect.

That’s a really good question… I don’t ever recall seeing that documented, nor have I come across any iocage logs myself. Typically, when I need to see what’s happening, I ssh into my NAS and run ‘iocage’ commands from the console. In this case, to update an installed plugin.

iocage update -P $JAIL_NAME

I thought it was the same but I could be wrong, either way I’m glad it worked the second time.

FreeBSD version 11.3-RELEASE-p14 seems to have some issues with gcc
/lib/libc.so.7: version FBSD_1.6 required by /usr/local/bin/gcc not found

Fortunately using gcc9 seems to resolve the PyNaCl issue. I have a pull request to switch the plugin manifest to gcc9. For now, I think this should do the trick (gcc9 is already installed, so we only need to remove gcc)

iocage console $_JAIL_NAME
# Press 0 to exit the menu
pkg delete gcc
service homeassistant install --force-reinstall --no-cache PyNaCl==1.3.0
service homeassistant restart

Great, so this fixed the PyNaCl issue. :slight_smile: Now there is one more thing: the appdaemon does not start after the python update. Have no clue yet where to look for solution but I’m assuming some dependencies with python version. Strange thing here:

[email protected]:~ # service appdaemon test

Testing virtualenv...

 CWD: /srv/appdaemon
 Python 3.7.9
 AppDaemon 4.0.5

[email protected]:~ # sysrc appdaemon_python
appdaemon_python: /usr/local/bin/python3.8

Need some more help :slight_smile:

Ah, that was easy :slight_smile:

service appdaemon install

did the trick. Uff. So I’m almost done :slight_smile: Now just need to fix my own service to control ventilation unit via serial port, stopped working after python upgrade as well. Maybe you would have a suggestion? When I try to run it in python3.7 I get error:

[email protected]:/srv/ca350/bin # python3.7 ca350
* CA350 MQTT Home Assistant *
13-10-2020 18:29:54 WARNING: Opening serial port exception:
13-10-2020 18:29:54 WARNING: (<class 'AttributeError'>, AttributeError("module 'serial' has no attribute 'Serial'"), <traceback object at 0x801fb1d20>)

when running in python3.8 it can’t find the paho-mqtt component:

[email protected]:/srv/ca350/bin # python3.8 ca350
Traceback (most recent call last):
  File "ca350", line 26, in <module>
    import paho.mqtt.client as mqtt
ModuleNotFoundError: No module named 'paho'

the package is installed but python3.8 can’t find it…

1 Like

I’m wondering if appdaemon did not like combination appdaemon_python: /usr/local/bin/python3.8 and service appdaemon install to the existing (I assume was previously python3.7) virtualenv

Can you try again using the console menu - The command is simply menu - Then select 3 for the appdaemon menu. Number 8 should be remove - When appdaemon has been removed, number 8 will change to install.

Just running the service appdaemon install solved the problem, all good now but… the test still shows the 3.7.9 virtual environment:

Testing virtualenv...

 CWD: /srv/appdaemon
 Python 3.7.9
 AppDaemon 4.0.5

OK, so I’ve removed and installed using menu now it seems all fixed:

Testing virtualenv...

 CWD: /usr/local/share/appdaemon
 Python 3.8.6
 AppDaemon 4.0.5

I know why now, (had to go look at the post_install.sh)

[email protected]:~ # sysrc appdaemon_python
appdaemon_python: /usr/local/bin/python3.8

This is because the python version is only used when creating a new virtualenv – The script will check for an existing virtaulenv at the location set by sysrc appdaemon_venv – If it finds an existing venv, it will use whatever version of python it was created with.

The test command should always be accurate to the python version inside the venv. This is because the command will actually run python --version from inside the activated venv

1 Like

Thanks for your support @troy . This python upgrade was a bit painful, strange things were happening, also to my own service, some modules were installed but not seen by 3.8, some the other way round - seen by 3.8 but not by 3.7. Some service files stopped working although were working ok before the upgrade… Finally, all is back and running smoothly.

Fun Fact: It was this comment by @wmn79 that started this all

Always useful for others to share what you did to make it working. I’m still working with an old jail version for which I used the “ALLOW UNSUPPORTED SYSTEM=true” solution to keep it running. Need to make the switch to the new IOCAGE jails some time as well so all help is appreciated.

1 Like

Haha, that is quite some time ago :smile:

And this plugin is about 800 lines of code, that still do the same thing as that first guide :rofl: – Only the python version has changed. Sometimes I wonder if we are actually any further ahead, or if this is just taking something simple and making it complicated :rofl:

I’m curious if anyone is thinking about switching over to TrueNAS SCALE, when it’s released next year.

I’m currently using FreeNAS TrueNAS Core because, IMO, it is the best (only?) NAS solution that has native support for zfs. With TrueNAS Scale, that’s (sort of) going to change. Along with being a Debian based OS, there will be support for Kubernetes / Docker. Personally, I’m just getting my feet wet with Docker and I know even less about Kubernetes.

From a non-technical stand point, I’m not so much hung up on if the underlying OS is FreeBSD (Core) or Linux (Scale). For my NAS (home file server) point of use, both Core and Scale are identical, so for me, it comes down to adding extra services to the NAS (plugins)…

The goal of TrueNAS SCALE container services is to provide easy-to-use infrastructure for deploying and managing container workloads on either a single node or a cluster of nodes. The container workloads may be simple Docker containers or a set of complex multi-container Pods that have been custom developed. The REST APIs and web UI for using these services are simple and powerful.

In some cases, users have specific container management tools that they would like to continue using. SCALE allows for this with some reasonable flexibility.

The approach with SCALE to solve this problem is three pronged:

  • SCALE includes a Kubernetes distribution (K3s) that has been integrated with middleware to provide a simple web UI and REST API for managing containers. Kubernetes will operate first on a single node (later as a cluster) and support Docker containers or Kubernetes pods defined by Helm Charts. This integration will provide an approximation of the Jails and Plugins capability provided by TrueNAS CORE. The initial WebUI for plugins is planned for the 20.12 release.
  • 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. There will be a CSI (Container Storage Interface) that can couple the container services with the SCALE storage capabilities. Users would script these capabilities and then use 3rd party tools like Portainer to manage them. This approach can be used on SCALE 20.10 and later.
  • SCALE provides very reliable VMs (via KVM) for guest OSes with specific container management features. Users can create these VMs with any OS (including Windows, Linux and FreeBSD) with any software stack they wish. These VMs would allow full integration with existing Container management clusters. This is supported on SCALE 20.10 and later.