@troy,
I looked this morning and the ffmpeg package is back in the latest repo. It looks like it was missing for a few days due to a fetch error on the build server. The quarterly repo should be more stable.
You can look at the current status of a port/package at FreshPorts. For example the ffmpeg page:
https://www.freshports.org/multimedia/ffmpeg/
If you scroll down on that page there is a grey table that lists what packages are available.
Kelly
That’s a relief to see it’s only missing by accident 
– I did manage to find the fresh ports link pretty quickly, however I could not figure out how the search for the reason –
It looks like it was missing for a few days due to a fetch error on the build server."
Thanks for clearing that up!
There is a side-effect to the current approach for using openssl-1.1.1 in the 11.3-RELEASE when ffmpeg is also installed. – If you have the following error trying to setup the Z-Wave integration
2020-06-21 21:06:44 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Z-Wave (import from configuration.yaml) for zwave
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/config_entries.py", line 217, in async_setup
hass, self
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/zwave/__init__.py", line 341, in async_setup_entry
from openzwave.option import ZWaveOption
File "/srv/homeassistant/lib/python3.7/site-packages/openzwave/option.py", line 29, in <module>
import libopenzwave
ImportError: /srv/homeassistant/lib/python3.7/site-packages/libopenzwave.so: Undefined symbol "libiconv"
For now, there is a manual fix that can be preformed.
iocage console $JAIL
# Press `0` to exit the menu
su - hass
export LDFLAGS=
source /srv/homeassistant/bin/activate
pip install --force-reinstall --no-cache homeassistant-pyozw==0.1.10
deactivate && exit
service homeassistant restart
I am currently testing an easier solution that will ( if successful ) be available in a near future update.
Hi.
Thank you making it so easy to install Home Assistant.
I have it working almost perfectly.
There’s two things I can’t get to work, and I think it may have to do with the jail configuration or maybe vnet
I have some TPlink Kasaa device and SenseMe (installed via HACS) unit, I can’t get them to find any devices.
Even playing with the command line binary (like aiosenseme --discover), no devices are found. I see errors about UDP broadcast when run
When I run the same set-up on a Linux box, it works well.
Both SenseMe and TPLink use UDP broadcast to find devices.
Is there anything special to do with the network configuration ? I used the defaults, using DHCP with ipv4, I have ipv6 on this network but it didn’t pick any config there.
Thank you.
JY
Hi!
I have installed configurator and appdeamon on TrueNAS Core 12. I have got error message, when test it on shell.
Testing virtualenv…
NO DIRECTORY: /srv/configurator
and
NO DIRECTORY: /srv/appdeamon
Can you help me, what do i wrong?
Thanks. Maxim
@jyavenard I’m sorry missed your post yesterday –
I am not aware of any special network setting, I’ve used TPLink in the past and the only requirement was to locate the device on the same network sub-net. I could not get it to work over VLAN but I’m not anything close to a network admin. I also use the default setting myself because they usually just work.
Sometime it’s just something random – for example, using emulated hue from a jail… I’ve seen people try to all sorts setting, both on HOST and in the JAIL, to get this working – At the end of the day, the easy solution ( required no system configuration ) was to just use a different port.
emulated_hue:
listen_port: 8300
upnp_bind_multicast: true
I’m sorry I can’t any offer any direct help, I’ve haven’t spent much time trying to configure jails with non-default settings. I’ll tell you this, don’t be scared because your using the “plugin” – If your trying to get something to work, you can do / try anything you would normally do in a manually created jail.
You are doing nothing wrong – I’ve been messing with the setting in the plugin – This is entire thing is getting completely refactored so using the TrueNAS beta plugin may be a little rough until I can this finished. – I’ve only been focused on Home Assistant Core ( appdaemon and configurator are not going away, these are not my primary concern ATM, since TN 12 is still beta )
The short story - right now the services are pulling $rcvars directly from the rc service scripts. These are the defaults I keep talking about changing – I have made some temporary changes already in TN 12 but in the process of all this I had a light bulb moment – I decided to trash this entire thing and started from scratch.
To get this fixed up, here’s what you can do right now.
# press `0` to EXIT the console menu
rm -rf /usr/local/srv/appdaemon
rm -rf /usr/local/srv/configurator
sysrc appdaemon_venv=/usr/local/srv/appdaemon
sysrc configurator_venv=/usr/local/srv/configurator
# restart the console menu
menu
Install appdaemon and configurator – Ignore message about existing configuration
I assure you this is for the best – This plugin is really just an install script that follows the same steps you would perform during a manual installation. At the end of the day, this is always a pip install homeassistant – The plugin’s post_install.sh simply does all step required leading up to any finally installing homeassistant – In fact, the only basic difference between this plugin and Installation of Home Assistant on your FreeNAS is was my choice of username and location for the virtualenv –
The provided configuration is nothing special, truth be told, it’s only there because I wanted to have some minimum defaults to test a clean installation.
All it does
Enable packages. Using a package, I can easily add the iframes ( HA side panel links to AppDaemon and File Editor ) without touching any other configuration files.
Provide a way to add your access token for appdaemon, before its installed. This not actually required either – but you will be spammed with endless “login attempted fail” if appdaemon is running and this is not correctly set.
The configurator ( File Editor ) technically does not need any configuration file at all! - but when it’s there, it will provide persistent settings. The access token is optional for the basic file editing, but it’s needed if you want to communicate with the HA api. I use this file to again provide some sane defaults. Most useful is setting that starts in $homeassistant_config_dir when you looking for a file to edit.
In the past, I came at this from the Home Assistant side. This approach seemed OK and was perfectly natural to me because I am a Linux user – That’s why the virtualenv was in /srv/homeassistant and I’m pretty sure I remember, waaay long ago ( I think around days of the AIO install ), hass was even the official username. ( It is still the core program name )
After much debate 
( Special thanks to @atxbyea @Tinkerer @jkhii for not blocking me on Discord ) I’m finally looking at this from the FreeBSD side.
Clean installs of the plugin will now use sane defaults that a BSD user would expect. The updated service script also includes some fragmented bits that were spread around this plugin and allows more settings via $rcvars. The new service should work for anyone already using some variation of the existing service script.
I’m hoping a guide for the new service script will bridge the gap between this plugin and the manual installation… also providing manual break down of what should be happening, and by reference how preform the same steps manually
Quick Example – This is still pip venv, but using the service, we do not have to always remember about who the user is or location of the virtualenv.
service homeassistant install [CMD]
That is equal to
su - $homeassistant_user
source $homeassistant_venv/bin/activate
pip install [CMD]
deactivate
Typical use cases
service homeassistant install --upgrade homeassistant
The thing is, even using iocage console homeassistant (the name of it)
and manually running the senseme python code; it can’t detect any devices.
I then tried the same thing outside the jail ; same deal.
For whatever reason, I can’t get it to work on this freenas box.
I’ve moved the code into a docker container and ran it with a linux host: all working fine.
I then found a spare Pine A64 board ; and ran it there. works fine too.
I would have preferred to have it all running on my freenas, it’s much more convenient. Can’t figure out what’s wrong.
The homeassistant jail was created with the default; I didn’t change a thing.
My configurator page is inaccessible from the menu icon in HA - its pointing to the wrong IP address. Any idea how I change the IP that this menu item points to? Can’t seem to find it in any of the config files.
Just need to change the url to your new ip address
Brilliant. Thanks Troy!
Hmm. My plugin update from 0.109.6 to latest (112?) failed. I went into the jail, checked the home assistant log and found:
2020-07-21 17:32:22 ERROR (MainThread) [homeassistant.auth.providers] Unable to load auth provider homeassistant: Shared object “libffi.so.6” not found, required by “_cffi_backend.so”
I reverted the snapshot, ensured it was working and just for fun did a python update as follows:
root@home-assistant:/ # pkg install python37
…
The following 3 package(s) will be affected (of 0 checked):New packages to be INSTALLED:
libffi321: 3.2.1Installed packages to be UPGRADED:
libffi: 3.2.1_3 → 3.3
python37: 3.7.7 → 3.7.8_1Number of packages to be installed: 1
Number of packages to be upgraded: 2
and this resulted in the exact same libffi library issue in the log after starting the homeassistant service. I tried the update from the 109.6 snapshot multiple times in case it was a transient upgrade bug and the failure is consistent. Thoughts?
Unable to load auth provider homeassistant: Shared object “libffi.so.6” not found, required by “_cffi_backend.so”
I’ve seen this error in a few plugins - I thought it was related to me trying to upgrade to the 12.1-RELEASE but seem you found this might be caused by a python update instead? – Good catch.
You don’t have to Plugin → UPDATE to get the latest Home Assistant - You can just use the console menu for that 
– In fact Plugin → UPDATE will never make any upgrades to the virtualenv themselves - That’s just to risky with breaking changes between Home Assistant releases.
Unfortunately, I’m still not sure why just updating python would break an existing install. I have tested a clean install it’s working just fine. If you want to Plugin → UPDATE in order to update the FreeBSD system, you will also get the updated service script – You can use this to try recreating the virtualenv after the plugin update. I’m sorry I can’t provide a better option at this time, I just assume this will work because a clean install does not have the same error.
With the updated service script, you can also try switching to python 3.8 in just a few steps as well
iocage console $jail
pkg install python38 py38-sqlite3
sysrc homeassistant_python=/usr/local/bin/python3.8
service homeassistant reinstall
service homeassistant config --check
service homeassistant start
Thanks Troy. With your help I got it working! Of the paths you offered me here’s what I did… performed the Plugin->UPDATE, installed and sysrc’d python3.8 with homeassistant. during the service reinstall it showed that I was ‘reinstalling’ 109.6 - showing the UPDATE did not actually update the homeassistant version. With these steps, it did successfully get my homeassistant 109.6 running but now with python3.8. next I followed your ‘recreating the virtualenv’ link and earlier on that page is a upgrading home assistant core section. I followed those instructions and am now successfully running home assistant 112.5 with python3.8.4.
Thanks again!
Anyone know how i can use this?
https://hass-apps.readthedocs.io/en/latest/getting-started.html#getting-started-configuration
Thanks!
I’ve not used hass-apps before but I know a few others have. I can at least help you get it installed –
I have not included any shortcuts for this purpose but you can still install manually. You’ll want to install this to the appdaemon virtualenv.
The basic steps would be something like this – if you installed this plugin before 07/20/2020
iocage console $jail
su - hass
source /srv/appdaemon/bin/activate
pip install --upgrade hass-apps
deactivate && exit
If you installed this plugin after 07/20/2020
homeassistant
/usr/local/share/appdaemon
It seems it could be possible to have this plugin create / manage its own nested datasets. This could potentially open up some interesting possibilities like taking snapshots of the virtualenv and / or configuration directory before an upgrade to Home Assistant. I think with a proper sudoers file in place, we could even trigger taking snapshots right from Home Assistant! and possibly use zfs send / receive to send these snapshots to another location. – So the question now is…
0 voters
I need to use port 80 but I understand this is not available as the plugin runs HA as a not-root user.
Basically, I want to run the emulated_hue integration and need to set the listen_port to 80 so that my Logitech Pop Hub can connect to it and therefore also my HA devices. On this page:
sudo setcap 'cap_net_bind_service=+ep' /srv/homeassistant/homeassistant_venv/bin/python3
I wondered if you had any suggestions for a workaround in a jail.
Thanks for all the hard work!
Hi @jony - IMHO, it’s musch easier to just use a different port for the Emulated Hue.
For example, here is how my configuration looks (and this works with my Harmony)
emulated_hue:
listen_port: 8300
upnp_bind_multicast: true
expose_by_default: true
exposed_domains:
## If exposed_by_default: true
- light
- switch
Hi Troy,
Thanks for repying so quickly. I would very much like to use it in the way you suggested. Unfortunately, the only way I have got the Logitech POP Hub to work in the past is to use port 80. Otherwise, when I try to pair the POP Hub with emulated_hue, I get stuck at a screen which says “To pair your Philips Hue, press the button in the center of the Hub”. Of course, I don’t have a button to press so I am stuck there.
I did try adding the line: upnp_bind_multicast: true which you have in your config but it did not make any difference for me. Do have any easy ideas about how I might expose port 80 for the emulated_hue component?
This is my current config:
emulated_hue:
listen_port: 8300
upnp_bind_multicast: true
host_ip: 10.1.102.1
expose_by_default: false
entities:
light.hallway_top_light:
name: Hallway Top
hidden: false
Thanks again
I had the same issue. It took me several tries before the connections was made. Have you confirmed the Emulated Hue has loaded and is running (using the alternate port)?
Also, give it a few tries without the host_ip: 10.1.102.1 line
No, not exactly. However, if running Home Assistant as root has allowed you to solve this in the past, you may be in luck. Assuming you have recently installed this plugin, it should fairly easy to switch users and run Home Assistant as root.
Just word of caution, I have not actually tested this. There are no guarantees this will work.
homeassistantConsider some simple back up options - Just in case
## Snaphot the jail
iocage snapshot homeassistant -n $name_your_snapshot
## Create zip back-up of the configuration directory
iocage console homeassistant
# Press `0` to exit the menu
service homeassistant config --backup
Run as root user (still inside the jail)
# Stop the service
service homeassistant stop
# Add 'root' to the homeassistant group
pw usermod root -G homeassistant
# Tell the service to run-as 'root'
sysrc homeassistant_user=root
# Change ownership to 'root' user
chown -R root /home/homeassistant/homeassistant
chown -R root /usr/local/share/homeassistant
# Start the service
service homeassistant start
You should now be running Home Assistant as root