Hi @doum - Sorry I’m not familiar with this integration but I’ve a few guesses for you to try
First. Please check your yaml indentation
I think it should look like this
rfxtrx:
device: /dev/cuaU0
That being said, I checked the integration docs and I don’t see any yaml configuration. Have you tried to add the integration manually, using the Home Assistant UI.
(You should remove any yaml configuration for this integration, before trying these steps)
Hi @troy when will I be able to update HomeAssistant core on Truenass to the newest HomeAssistant december update 2021.12? Is the release of the update coming soon to the community plugin on Truenass ?
I don’t know what problem you have because I’ve been on 21.12 nearly two weeks.
Go to Jails,
click on home assistant to expand,
click on Shell,
a menu will appear, select 1
another menu will appear,
select 4 to upgrade,
upgrade will occur,
when finished, press Enter and you are done.
Hi! Been using your plugin successfully for more than a year now - Thank you!
TLDR: cannot restart HA via web UI after upgrade from 2021.6.x to 2021.12.4 – but restart/start/stop from the plugin all work well.
I dug around and found this error:
==> /var/log/homeassistant_daemon.log <==
Home Assistant attempting to restart.
ld-elf.so.1: /usr/local/lib/libpython3.9.so.1.0: Undefined symbol "close_range@FBSD_1.6"
Current TrueNAS Versions TrueNAS-12.0-U4 and freebsd-version -u says 12.2-RELEASE-p6
Current HA Jail version (after upgrade) freebsd-version -u → 12.1-RELEASE-p13
HA is: 2021.12.4
truenas plugin version is: v7-2021.11.2
Steps taken:
first updated the plugin via the TrueNAS UI
then shelled in to the plugin menu and ran 4) upgrade
started verifying things - seems like all integrations migrated successfully.
Hi @troy,
thx for your reply.
Indentation on yaml is good, not my copy/paste… sorry for that.
I tried both methods, manual and with Mybutton (integration docs).
But I had the same error.
Could switching from Truenas Core to Truenas Scale help me in my case? Does the installation by containers allow easier management of USB peripherals?
A Plugin UPDATE is not an update to Home Assistant or other included services. In this plugin, each service is installed in a separate python virtualenv. A Plugin UPDATE is for everything outside of the virtualenvs, like the system requirements, startup scripts and console menu.
Most of the time, you can update Home Assistant (and other services) as soon as a new version is released. Here we are updating the application inside each virtualenv. This can be done using the jail’s console menu, as mentioned by @Tromperie
At this time, the supported Python versions for Home Assistant are changing. For this installation method, expect this change at the end of every year. The latest plugin version includes the required python in the system requirements. If you’re using a previous version, this is an occasion where a Plugin UPDATE would be desired to install new requirements before updating Home Assistant.
There’s been at a dozen people who’ve reported this issue over time. I’ve never been able to reproduce it myself or figure out how to troubleshoot it with someone else. I keep this in mind if it comes up again. Thanks!
Yep, I think you need to upgrade the jail - Honestly, this is the part I hate about plugins… I’m not sure exactly what to do. First here’s some good news… Running Plugin or Jail UPDATES from the UI will take a snapshot first, so worst case, you can always revert back. If something does go wrong, it can usually be figured out with some trial and error but sometimes it’s just quicker and easier to install a new plugin and migrate your config.
When possible, I always recommend having an updated system - TrueNAS-12.0-U7`
Did you select Update jail as well check box? If not, please try again with the box checked.
If your jail version is still 12.1-RELEASE-p13 can you try running the Jail UPDATE
After the jail version is changed, if Home Assistant does not work or you still need to switch python versions, the next step is to reinstall the virtualenv. From the jail’s console
# press 0 to exit menu
sysrc homeassistant_python=/usr/local/bin/python3.9
service homeassistant reinstall homeassistant
Please let me know how it goes, or if you decide to just clean install, then migrate your config
I really have no idea why it would show up but not work - Are you sure that’s the correct device? - I mean, if you have a zigbee or z-wave radio for example, they are also cua* devices and the U0 part can change?
It depends, TrueNAS SCALE is still a work in progress. TrueCharts has already added over 180 apps and I’m pretty sure you can pass a USB device through by checking a box during the Home Assistant setup. On the other hand, I don’t think you can enable host-networking so things that rely on mdns like discovery, won’t work. For some people that’s a big deal, others could care less.
when I try to add rfxcom integration through the GUI having the rfxcom unplugged, I see only 1 line:
‘/dev/cuau0 - n/a, s/n: n/a’
when I try to add rfxcom integration through the GUI having the rfxcom plugged, I see2 lines:
‘/dev/cuau0 - n/a, s/n: n/a’ and ‘/dev/cuaU0 - n/a, s/n: n/a’
It’s why I think rfxcom is on /dev/cuaU0.
Morever, there is a configuration file on Truenas which forwards the tty* ports to the cua* ports.
But what I don’t understand is that the result of dmesg | grep -i ftdi is:
‘uftdi0 on uhub2
uftdi0: on usbus1
uftdi0: at uhub2, port 7 addr 5 (disconnected)
uftdi0: detached
uftdi0 on uhub2
uftdi0: on usbus1’
I don’t understand what is usbus1.
On /dev, I don’t have anything called usbus1.
Does this speak to you?
TL;DR - The OP was using a USB Conbee II stick for Zigbee hub. The Home Assistant plugin recognized the USB dongle, but no devices would connect. Here is the solution claimed to work
Thanks! Yeah, I’ve figured it out.
I’ve set the following parameters:
devfs_ruleset = 2
allow_mount = enabled
allow_mount_devfs = enabled
enforce_statfs = lower than two
I didn’t find a way how to set enforce_statfs from the GUI.
Had to use following command in the shell: “iocage set enforce_statfs=1 jailname”
Do you know how to set the parameters mentioned above? If so, can you give it a try and let me know if it works or not… If you need help setting the parameters, let me know. I can try to get some screen shots together in the next day or two.
You can set the above parameters from the TrueNAS console (not inside the jail)
iocage stop $jail_name
iocage set devfs_ruleset=2 $jail_name
iocage set allow_mount=enabled $jail_name
iocage set allow_mount_devfs=enabled $jail_name
iocage set enforce_statfs=1 $jail_name $jail_name
iocage start $jail_name
@troy I’m not in a huge rush - so before I do any of that if you want we could pick a time and discord/share screen/troubleshoot. Up to you! I probably won’t fiddle with it until at least after new years.
WARNING: FreeBSD 12.2-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 1 month.
I’m expecting just like every previous release since FreeNAS 11.0, once it’s past EOL this plugin will start to shit out. And like before, there’s not much I can do. The solution will be updating to a supported version of FreeBSD.
So here’s the kicker - based on FreeNAS 11 → TrueNAS 12 transition - ixsystems is not likely to make a 12.3-RELEASE branch for plugins on TN CORE 12 – Instead there will be TN CORE 13, and plugins will go to FreeBSD 13.x - Development of TN CORE 13 has just begun and beta versions should start in early 2022. I haven’t seen a target date for release yet.
I’ve opened an issue asking about plans to add a 12-3-RELEASE plugin branch. Hopefully I’m wrong and this will turn out to be a non-issue.
I’m pretty sure it’s already possible to install a 12.3-RELEASE jail, but it’s up to ix-systems to switch the plugins over. This again has me thinking about the future of plugins, and most experienced users (on TrueNAS forum) will tell you not to plugins anyways. It really won’t take much to convert my plugins to a scripted install for a regular jail (that’s what they started as). We’ll lose the install “button”, but honestly, this plugin requires manual intervention anyways. If a few more lines to copy and paste in a terminal is a deal breaker, this installation is probably not for you I think, just about everything else would remain the same or even get easier.
Speaking only for myself, of course, I’d be happy to do the whole lot by command line, if that is the best option. Your selfless work is very much appreciated.
It’s nice to see this is getting fixed - I think when 12.2 goes EOL I’ll be able to block further updates. That is to say, I’ll try to make the pre-update fail before there is a chance to remove existing packages. If that works, it should help keep existing plugin installs from breaking until the next release is ready.
This is obviously something I should have looked up 4 yrs ago. Oh well, better late than never
Supported FreeBSD releases
Each release is supported by the Security Officer for a limited time only.
The designation and expected lifetime of all currently supported branches and their respective releases are given below. The Expected EoL (end-of-life) column indicates the earliest date on which support for that branch or release will end. Please note that these dates may be pushed back if circumstances warrant it.
Older releases are not supported and users are strongly encouraged to upgrade to one of these supported releases:
Branch
Release
Release Date
Expected EoL
stable/13
n/a
n/a
January 31, 2026
releng/13.0
13.0-RELEASE
April 13, 2021
13.1-RELEASE + 3 months
stable/12
n/a
n/a
June 30, 2024
releng/12.3
12.3-RELEASE
December 7, 2021
12.4-RELEASE + 3 months
releng/12.2
12.2-RELEASE
October 27, 2020
March 31, 2022
In the run-up to a release, a number of -BETA and -RC releases may be published for testing purposes. These releases are only supported for a few weeks, as resources permit, and will not be listed as supported on this page. Users are strongly discouraged from running these releases on production systems.
The FreeBSD support model
Under the current support model, each major version’s stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release.
Also, an ix-systems team member responded to my question on github
We are working towards a quick 13.0 release to try and sync with the EOL of 12.2.
So, no 12.3-RELEASE pluginson TN CORE 12. I’ve asked if it will be possible using a regular (clone) jail. (plugins are base jails, btw) - I’ve also asked if it’s possible to convert a plugin (base) jail to a regular (clone) jail. - The only other option, I think, will be an upgrade to TN CORE 13.0
Hi @troy,
I tried to change these parameters but I have always the same timeout.
I dit another test: I tried to add rfcvom integration on another USB port, and I can see the same line ‘/dev/cuaU0 - n/a, s/n: n/a’. So I have doubts about the path of the USB device.
Is there a way to be sure you know this path?
I’m not sure how helpful this we be… It’s my understanding the parameters you’ve already tried setting, should pass everything from the host into the Home Assistant jail.
Next guess is to look at devices on TrueNAS host itself, not inside the jail or using an integration.
So, start with the USB in question unplugged. From the TrueNAS console, run the following command and make note of all devices that appear
ls -al /dev
Next, plugin in USB and run the same command again. With any luck, you should see a new device listed… This would be the path of device we need to pass into Home Assistant and also path that should be used by the integration.
This thread is rather short and provides a great explanation on the different types of jails…
TLDR;
The choice of jail type determines: the size on disk, the ease of updating/upgrading, and the suitability to keep it around across releases.
The typical approach of most tutorials and scripts in this [TrueNAS] forum is to keep your “data” in a dataset outside of the iocage jail dataset. With your data separate from the jail, it’s trivial to:
stop existing jail
create a new jail based on the latest release and/or patches
(re)mount the data in new jail
nuke existing jail if everything works as desired in new jail
If you stick to this recommendation, you’ll avoid a lot of heartburn and, unless you manage a very large number of jails, the jail type won’t have a huge long term impact.
- I’m just making some guesses here…
Well, this is gonna suck…
I think, just about everything else would remain the same or even get easier.