I tried to update the plugin including the jail but i get this message:
Error: [EFAULT] No updates available for homeassistant
Then I totally removed homeassistant and did a fresh install, tried your solution, no luck. I tried to update the plugin again, still the message:
Error: [EFAULT] No updates available for homeassistant
Has it something to do with the truenas version? I’m running on TrueNAS-12.0-U1.1
but I see I can update to the Beta 12.0-U2
If your not running else mission critical, I think it’s worth a shot… just to be clear we are talking about the same thing – you mean the version shown here, correct?
My TrueNAS update to date on the STABLE train and I am at 12.0-U2
Yea, i’m at TrueNAS-12.0-U1.1, gonna try to update then 
By the way @troy, thanks for the help and quick response! It helps me alot
There’s a new version of zwavejs2mqtt available – The upgrade using the console menu went ok but there were a few things I wanted to improve. Please run Plugin UPDATE from TrueNAS UI before you try upgrading zwavejs2mqtt using the console menu.
Also, if you want to upgrade zwavejs2mqtt during a Plugin UPDATE, you can set the following rcvar inside the plugin’s jail
sysrc plugin_upgrade_service="YES"
Thanx man! Its hard to know if it started exactly then but it never happened on freenas and it started around the time of the switch.
i get this output when its not working, so i guess its still there, one question: what do the date and time mean in the output?
crw-rw---- 1 uucp dialer 0xfe Feb 18 00:32 cuaU0
crw-rw---- 1 uucp dialer 0xff Feb 18 00:29 cuaU0.init
crw-rw---- 1 uucp dialer 0x100 Feb 18 00:29 cuaU0.lock
crw-rw---- 1 uucp dialer 0x104 Feb 18 07:38 cuaU1
crw-rw---- 1 uucp dialer 0x105 Feb 18 00:29 cuaU1.init
crw-rw---- 1 uucp dialer 0x106 Feb 18 00:29 cuaU1.lock
your method for recovery worked, so no more having to reboot truenas.
thank you!
No luck mate… did a fresh install after the upgrade to 12.0-U2
root@homeassistant:~ # service homeassistant install --no-cache-dir --force-reinstall "pytradfri[async]==7.0.6"
Collecting pytradfri[async]==7.0.6
Downloading pytradfri-7.0.6-py3-none-any.whl (30 kB)
Collecting DTLSSocket==0.1.12; extra == "async"
Downloading DTLSSocket-0.1.12.tar.gz (150 kB)
|████████████████████████████████| 150 kB 6.8 MB/s
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing wheel metadata ... done
Collecting aiocoap==0.4b3; extra == "async"
Downloading aiocoap-0.4b3.tar.gz (178 kB)
|████████████████████████████████| 178 kB 2.7 MB/s
Collecting Cython
Downloading Cython-0.29.21-py2.py3-none-any.whl (974 kB)
|████████████████████████████████| 974 kB 2.8 MB/s
Building wheels for collected packages: DTLSSocket, aiocoap
Building wheel for DTLSSocket (PEP 517) ... error
ERROR: Command errored out with exit status 1:
command: /usr/local/share/homeassistant/bin/python3.8 /usr/local/share/homeassistant/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /tmp/tmp6dce2r1n
cwd: /tmp/pip-install-4od1js99/dtlssocket
Complete output (55 lines):
running bdist_wheel
running build
running build_py
creating build
creating build/lib.freebsd-12.2-RELEASE-p3-amd64-3.8
creating build/lib.freebsd-12.2-RELEASE-p3-amd64-3.8/DTLSSocket
copying DTLSSocket/__init__.py -> build/lib.freebsd-12.2-RELEASE-p3-amd64-3.8/DTLSSocket
copying DTLSSocket/DTLSSocket.py -> build/lib.freebsd-12.2-RELEASE-p3-amd64-3.8/DTLSSocket
running build_ext
autom4te-2.69: need GNU m4 1.4 or later: /usr/local/bin/gm4
Running: autoconf
Traceback (most recent call last):
File "/usr/local/share/homeassistant/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 280, in <module>
main()
File "/usr/local/share/homeassistant/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 263, in main
json_out['return_val'] = hook(**hook_input['kwargs'])
File "/usr/local/share/homeassistant/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 204, in build_wheel
return _build_backend().build_wheel(wheel_directory, config_settings,
File "/tmp/pip-build-env-gah2yf4o/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 216, in build_wheel
return self._build_with_temp_dir(['bdist_wheel'], '.whl',
File "/tmp/pip-build-env-gah2yf4o/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 202, in _build_with_temp_dir
self.run_setup()
File "/tmp/pip-build-env-gah2yf4o/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 253, in run_setup
super(_BuildMetaLegacyBackend,
File "/tmp/pip-build-env-gah2yf4o/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 145, in run_setup
exec(compile(code, __file__, 'exec'), locals())
File "setup.py", line 27, in <module>
setup(
File "/tmp/pip-build-env-gah2yf4o/overlay/lib/python3.8/site-packages/setuptools/__init__.py", line 153, in setup
return distutils.core.setup(**attrs)
File "/usr/local/lib/python3.8/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/local/lib/python3.8/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/tmp/pip-build-env-gah2yf4o/overlay/lib/python3.8/site-packages/wheel/bdist_wheel.py", line 299, in run
self.run_command('build')
File "/usr/local/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/local/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/local/lib/python3.8/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/usr/local/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/local/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "setup.py", line 21, in run
run_command(command)
File "setup.py", line 12, in run_command
subprocess.check_call(args, cwd=os.path.join(os.path.dirname(__file__), "DTLSSocket","tinydtls"))
File "/usr/local/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['autoconf']' returned non-zero exit status 1.
----------------------------------------
ERROR: Failed building wheel for DTLSSocket
Building wheel for aiocoap (setup.py) ... done
Created wheel for aiocoap: filename=aiocoap-0.4b3-py3-none-any.whl size=190274 sha256=2731f44e069328c2db29e9482987c62b93652f68596dc4df0c86daf45c5a0ee6
Stored in directory: /tmp/pip-ephem-wheel-cache-zdb8tfg7/wheels/4b/7c/8b/002a6f0cfc24a00011d4b8a32b88ec09f3798195f55564ef61
Successfully built aiocoap
Failed to build DTLSSocket
ERROR: Could not build wheels for DTLSSocket which use PEP 517 and cannot be installed directly
WARNING: You are using pip version 20.2.4; however, version 21.0.1 is available.
You should consider upgrading via the '/usr/local/share/homeassistant/bin/python3.8 -m pip install --upgrade pip' command.
I have checked, but autom4te-2.69: need GNU m4 1.4 or later: /usr/local/bin/gm4, is installed:
root@homeassistant:/ # pkg which /usr/local/bin/gm4
/usr/local/bin/gm4 was installed by package m4-1.4.18_1,1
It is working now. Really strange. Life is full of surprises and end-users breaking things. 
Can anyone help identify my Zigbee sensor problem? I have Xiaomi and Phillips Hue sensors and they keep becoming unavailable every few hours. Only remedy is to re-start the jail.
I’m using a Conbee 2 usb stick which I suspect the problem is with.
I’m running TrueNas 12.0-U2 and Home Assistant 2021.2.2.
Grateful for suggestions.
@shanghaiultra - you are the second person to be report faulty Zigbee operation… now I am starting to suspect something weird is going on.
I’m sorry, I don’t have any advice to offer at this time. Do you have other Zigbee devices ? If so, does all Zigbee fail or only the sensors ?
I’m primarily a Z-Wave user, but I think if there was some TrueNAS issue with the USB device pass through, I would still be effected – I mean, how would TrueNAS know what the device is, and only fail on Zigbee
I think I still have a few Zigbee devices laying around somewhere - I’ll try to connecting a few and let them run for a few days, to see if I have Zigbee dropout as well
I’m sorry this turning into so much trouble for you @ymestechwey - I have no idea what we are missing - the only other thing I can think right now is that I installed TrueNAS back MAY while it was still in ALPHA.
I realize this should not matter, because we are both on 12.0-STABLE train and we both have the most recent version installed. Still I will make a clean install of TrueNAS with Home Assistant and try to add the tradfri integration. If I can at least reproduce the same error you have, I’ll have a better shot at figuring it out.
Sorry again for all this trouble
@troy I only have the one Conbee 2 stick attached to my Truenas machine. No other peripherals other than an extra network card.
I have 5 Zigbee sensors and one Phillips hue. They all fail together. One of the sensors is literally two metres away from the Conbee stick, so it can’t be Zigbee network problems. I’ve tried putting the Conbee stick on a USB extension cable just in case, but no change.
I found these links, similar problems:
But I’m a bit out of my depth here. I also updated the firmware to the latest version on my Conbee stick, but no improvement.
Sometimes the sensors will stay online for a whole day. Other times just an hour or so after I restart the jail, they’re down again.
Output from my Truenas console suggests some kind of constant disconnection:
Feb 19 19:06:41 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH ConBee II> at usbus1 (disconnected)
Feb 19 19:06:41 voidserver umodem0: at uhub3, port 2, addr 3 (disconnected)
Feb 19 19:06:41 voidserver umodem0: detached
Feb 19 19:06:43 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH product 0x0030> at usbus1
Feb 19 19:06:43 voidserver umodem0 on uhub3
Feb 19 19:06:43 voidserver umodem0: <dresden elektronik ingenieurtechnik GmbH product 0x0030, class 2/0, rev 2.01/1.00, addr 3> on usbus1
Feb 19 19:06:43 voidserver umodem0: data interface 1, has CM over data, has no break
Feb 19 19:06:45 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH product 0x0030> at usbus1 (disconnected)
Feb 19 19:06:45 voidserver umodem0: at uhub3, port 2, addr 3 (disconnected)
Feb 19 19:06:45 voidserver umodem0: detached
Feb 19 19:06:46 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH ConBee II> at usbus1
Feb 19 19:06:46 voidserver umodem0 on uhub3
Feb 19 19:06:46 voidserver umodem0: <dresden elektronik ingenieurtechnik GmbH ConBee II, class 2/0, rev 2.01/1.00, addr 3> on usbus1
Feb 19 19:06:46 voidserver umodem0: data interface 1, has CM over data, has no break
Feb 19 19:07:19 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH ConBee II> at usbus1 (disconnected)
Feb 19 19:07:19 voidserver umodem0: at uhub3, port 2, addr 3 (disconnected)
Feb 19 19:07:19 voidserver umodem0: detached
Feb 19 19:07:20 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH ConBee II> at usbus1
Feb 19 19:07:20 voidserver umodem0 on uhub3
Feb 19 19:07:20 voidserver umodem0: <dresden elektronik ingenieurtechnik GmbH ConBee II, class 2/0, rev 2.01/1.00, addr 3> on usbus1
Feb 19 19:07:20 voidserver umodem0: data interface 1, has CM over data, has no break
Feb 19 19:07:23 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH ConBee II> at usbus1 (disconnected)
Feb 19 19:07:23 voidserver umodem0: at uhub3, port 2, addr 3 (disconnected)
Feb 19 19:07:23 voidserver umodem0: detached
Feb 19 19:07:24 voidserver ugen1.3: <dresden elektronik ingenieurtechnik GmbH ConBee II> at usbus1
Feb 19 19:07:24 voidserver umodem0 on uhub3
Feb 19 19:07:24 voidserver umodem0: <dresden elektronik ingenieurtechnik GmbH ConBee II, class 2/0, rev 2.01/1.00, addr 3> on usbus1
Feb 19 19:07:24 voidserver umodem0: data interface 1, has CM over data, has no break
Feb 19 19:15:58 voidserver kernel: in6_purgeaddr: err=65, destination address delete failed
But I’m not sure how to interpret the above. As always thanks Troy for taking the time to check it out.
Z-Wave JS to MQTT - TN CORE Plugin Updategit-lite | rsync | wget
Here’s a simple command line sensor you can use to watch for future plugin updates.
sensor:
- name: "Z-Wave JS to MQTT"
scan_interval: 86400
platform: command_line
command: "curl https://raw.githubusercontent.com/tprelog/iocage-zwavejs2mqtt/master/overlay/root/.PLUGIN_VERSION"
There’s also an undocumented… shall we say, advanced setting available (Copied from the Dockerfile) – It is updateDevices - When enabled, this will download the latest zwave device config from the master branch of the zwavejs repo, while building zwavejs2mqtt. Typically, most users should leave this disabled - However, I will mention it in case there is ever a need to have it.
sysrc updateDevices=true
sysrc -x updateDevices
node14
git-lite | rsync | wget
plugin_upgrade_service will default to YES
@Kai74 @wmn79 – When version 2 is released, please let me know how the Plugin UPDATE goes.
No problem mate, no worries. I’m gonna figure it out also why it isnt working.
Hi @troy, I’ve been using HA via your plugin on TrueNAS-12.0-U1 for a few months & it’s been working brilliantly (thank you for your hard work making the plugin so user friendly!).
I have had AppDaemon installed & working, however today I was trying to get hass-apps installed so that I can use the schedy scheduler.
I upgraded both HA & AppDaemon via the shell GUI, but now I can’t seem to get the AppDaemon service to start. I’ve tried uninstalling / reinstalling AppDaemon, but each time the start fails with the message: “/usr/local/share/appdaemon/bin/appdaemon is not found or is not executable”.
The AppDaemon files are being generated and are viewable within /home/homeassistant/appdaemon, but the service won’t start. Any ideas?
Hello and welcome @CT846 - sorry for the delayed response
Give this a try
iocage console $JAIL_NAME
# Press `0` to exit menu
rm -rf /usr/local/share/appdaemon
menu_service install appdaemon
service appdaemon start
Thanks @troy. I tried this, but unfortunately it gives the same error.
I’m using the configuration in an external dataset & I’ve been considering trying deleting / reinstalling the plugin to test out the recovery process. Do you think that would sort the issue?
This is always a good idea to practice – What I do is
When your done. you can just stop the “test” plugin and restart your original – If you do this a few time, you will find it is no longer so such a big deal when things go wrong.
Yes, and with config on external dataset this is rather trivial – but I don’t now if we need to go this far just yet.
Can you please share the output from the following command
iocage console $JAIL_NAME
# Press `0` to exit menu
ls -al /usr/local/etc/rc.d
root@homeassistant-1:~ # ls -al /usr/local/etc/rc.d
total 44drwxr-xr-x 2 root wheel 7 Dec 26 17:03 .
drwxr-xr-x 11 root wheel 25 Dec 26 17:03 ..
-rwxr-xr-x 1 root wheel 6084 Dec 26 17:03 appdaemon-rwxr-xr-x 1 root wheel 6726 Dec 26 17:03 configurator
-rwxr-xr-x 1 root wheel 11819 Dec 26 17:03 homeassistant
-rwxr-xr-x 1 root wheel 1239 Dec 10 06:26 tcsd
-rwxr-xr-x 1 root wheel 628 Dec 10 06:22 tpmd
Is this file really named this way 
– Or is it copy/paste gone wild ?
-rwxr-xr-x 1 root wheel 6084 Dec 26 17:03 appdaemon-rwxr-xr-x
Let’s double check that please
ls -al /usr/local/etc/rc.d | grep appdaemon
sorry - yep, copy/paste gone wild
I find that copying from the TrueNAS shell can be very hit & miss…
-rwxr-xr-x 1 root wheel 6084 Dec 26 17:03 appdaemon