I’m not even sure if it’s possible but at my level of understanding, I think it would be more trouble than it’s worth. Hass.io is technically still running Home Assistant. It’s just a complete solution created for easy installation / use and people that are unfamiliar with Linux and/or using the CLI.
Please don’t mistake me, I have nothing against hass.io and even if you don’t need the preconfigured OS, having easy access to all those add-ons would be great have. It’s just my opinion, at this time the best choice for hass.io is a dedicated Intel NUC. I think using FreeNAS to run hass.io is just adding an extra layer of over-head and complication. If it is possible, I don’t think it would be so straight forward. I think you’re gonna need at least some basic knowledge of both FreeNAS and Linux, as well as be comfortable using the CLI.
Still if I was going to try this first attempt would be create a VM running Ubuntu Server and try to install hass.io manually.
Hi, I’ve followed your manual install and at the point of making my rc.d script I have followed everything but when it comes to run the service it states “daemon: open: Permission denied” .
I am unsure what I have done to not have it work but all group permissions seem correct across the jail and the mounted dataset.
I am able to run home assistant manually and as a daemon using --daemon, it has populated all the files in the /home/hass/homeassistant folder on the drive as well.
Any ideas on what I could have done to mess it up!?
When you try to start homeassistant using the rc.d script are you logged in as user hass?
The rc script needs to be started by user root. Don’t worry… It will still run homeassistant as the correct user hass but still you must root to start the service.
Yes I am running as root which is why I find it strange it says Permission Denied.
I have done a bit of google-fu and have found people with similar issues not having made the file executable but I have definitely done that. Other than that I am pretty stumped.
#!/bin/sh
#
# PROVIDE: homeassistant
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# homeassistant_enable: Set to YES to enable the homeassistant service.
# Default: NO
# homeassistant_user: The user account used to run the homeassistant daemon.
# This is optional, however do not specifically set this to an
# empty string as this will cause the daemon to run as root.
# Default: hass
# homeassistant_group: The group account used to run the homeassistant daemon.
# This is optional, however do not specifically set this to an
# empty string as this will cause the daemon to run with group wheel.
# Default: hass
# homeassistant_dir: Directory where config files are located.
# Default: ~/.homeassistant
#
# sysrc homeassistant_enable=yes
# service homeassistant start
. /etc/rc.subr
name=homeassistant
rcvar=${name}_enable
pidfile_child="/var/run/${name}.pid"
pidfile="/var/run/${name}_daemon.pid"
logfile="/var/log/${name}_daemon.log"
load_rc_config ${name}
: ${homeassistant_enable:="NO"}
: ${homeassistant_user:="hass"}
: ${homeassistant_group:="hass"}
: ${homeassistant_config_dir:="/home/hass/homeassistant"}
command="/usr/sbin/daemon"
start_precmd=${name}_precmd
homeassistant_precmd()
{
rc_flags="-f -o ${logfile} -P ${pidfile} -p ${pidfile_child} /srv/homeassistant/bin/hass --config ${homeassistant_config_dir} ${rc_flags}"
if [ ! -e "${pidfile_child}" ]; then
install -g ${homeassistant_group} -o ${homeassistant_user} -- /dev/null "${pidfile_child}";
fi
if [ ! -e "${pidfile}" ]; then
install -g ${homeassistant_group} -o ${homeassistant_user} -- /dev/null "${pidfile}";
fi
if [ ! -d "${homeassistant_config_dir}" ]; then
install -d -g ${homeassistant_group} -o ${homeassistant_user} -- "${homeassistant_config_dir}";
fi
}
stop_postcmd=${name}_postcmd
homeassistant_postcmd()
{
rm -f -- "${pidfile}"
rm -f -- "${pidfile_child}"
}
run_rc_command "$1"
Heres a copy of the code but its pretty much verbatim to what was in your original post.
@scooper86 It turns out the rc.d script in the manual install was the problem but I did not catch this sooner because it’s only a bug the first time the service is used to start home assistant.
It’s my fault - When I added the the log file for the daemon I forgot to add a check to create the file and set permissions if it did not exist.
When I replaced the existing rc.d in my script install jail it was not affected because log file had already been created.
Adding the following code resolved the issue
if [ ! -e "${logfile}" ]; then
install -g ${homeassistant_group} -o ${homeassistant_user} -- /dev/null "${logfile}";
fi
I have noticed a few other minor changes I’ve made to the homeassistant rc.d script that were not reflected in the manual install guide ( This has now been updated as well )
Please instead use this updated version and homeassistant service should work
#!/bin/sh
# PROVIDE: homeassistant
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# homeassistant_enable: Set to YES to enable the homeassistant service.
# Default: NO
# homeassistant_user: The user account used to run the homeassistant daemon.
# This is optional, however do not specifically set this to an
# empty string as this will cause the daemon to run as root.
# Default: USER_NAME
# homeassistant_group: The group account used to run the homeassistant daemon.
# This is optional, however do not specifically set this to an
# empty string as this will cause the daemon to run with group wheel.
# Default: USER_GROUP
# homeassistant_config_dir: Directory where homeassistant config is located.
# Default: ~/homeassistant
#
# copy file to /usr/local/etc/rc.d/homeassistant
# chmod +x /usr/local/etc/rc.d/homeassistant
#
# sysrc homeassistant_enable=yes # to enable
# sysrc homeassistant_config_dir="~/homeassistant" # to change
# service homeassistant start # to start
. /etc/rc.subr
name=homeassistant
rcvar=${name}_enable
pidfile_child="/var/run/${name}.pid"
pidfile="/var/run/${name}_daemon.pid"
logfile="/var/log/${name}_daemon.log"
load_rc_config ${name}
: ${homeassistant_enable:="NO"}
: ${homeassistant_user:="hass"}
: ${homeassistant_group:="hass"}
: ${homeassistant_config_dir:="/home/hass/homeassistant"}
command="/usr/sbin/daemon"
start_precmd=${name}_precmd
homeassistant_precmd()
{
rc_flags="-f -o ${logfile} -P ${pidfile} -p ${pidfile_child} /srv/homeassistant/bin/hass --config ${homeassistant_config_dir} ${rc_flags}"
if [ ! -e "${pidfile_child}" ]; then
install -g ${homeassistant_group} -o ${homeassistant_user} -- /dev/null "${pidfile_child}";
fi
if [ ! -e "${pidfile}" ]; then
install -g ${homeassistant_group} -o ${homeassistant_user} -- /dev/null "${pidfile}";
fi
if [ ! -e "${logfile}" ]; then
install -g ${homeassistant_group} -o ${homeassistant_user} -- /dev/null "${logfile}";
fi
if [ ! -d "${homeassistant_config_dir}" ]; then
install -d -g ${homeassistant_group} -o ${homeassistant_user} -m 775 -- "${homeassistant_config_dir}"
fi
}
stop_postcmd=${name}_postcmd
homeassistant_postcmd()
{
rm -f -- "${pidfile}"
rm -f -- "${pidfile_child}"
}
run_rc_command "$1"
Just wondering if you have looked at the stream component for HA. I did try it with my setup but I ran into the errors:
2019-03-12 08:49:59 ERROR (MainThread) [homeassistant.requirements] Not initializing stream because could not install requirement av==6.1.2
2019-03-12 08:49:59 ERROR (MainThread) [homeassistant.setup] Setup failed for stream: Could not install all requirements.
Do you think there is a way around this on the Freenas?
I installed libudev-devd in the jail and tried to manually upgrade to homeassistant-pyozw==0.1.3
That did not go so well and I have managed to break z-wave.
Had to leave for work but I’ll look into this more over the weekend
Thanks Troy. I did get the stream component working last night but then I thought I should upgrade to 0.91.0. Then I also ran into the same issues. Zwave crapped out. Rolled back to 0.90.2 for now.
I think you are correct - Ubuntu VM running on bhyve is the way forward.
IMO it should be considered the only way (Not to diminish the sterling work you are doing to help run HA in a FN jail)
I run freenas (admittedly 9.10 not 11.2) but I am running it in a VM on esxi.
I also run a ubuntu VM with docker and hassio, and going from downloading ubuntu ISO to a working hassio is a matter of 30 mins work (really).
IMO (again its opinion) is that hassio brings so many benefits for managing peripheral software such as node red that it should be considered the #1 route to run HA.
Now that FN11.x allows you to run VMs on bhyve as well as jails this should be considered.
For the record I was never a fan as freenas as my base OS. Its a wonderful NAS OS, but I can see the limitations on its support for “other stuff” e.g. plex etc. Now that freenas officially support virtualisation (e.g. pass through HBA) I think that running FN in a VM in parallel with other VMs on a hypervisor such as esxi gives ultimate flexibility. For folks who already settled on FN as the base OS/hypervisor then bhyve VMs also have very very good performance.
BTW this blog has some very excellent guides:
Install FN on ESXi: (this is what I used a few years back)
I would love to run a VM on my FreeNAS but I cannot seem to make it work in anyway. I have followed all kinds of guides all over the internet and forums with no luck. All I get when trying to start the VM is errors.
Error: Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 165, in call_method
result = await self.middleware.call_method(self, message)
File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 1141, in call_method
return await self._call(message['method'], serviceobj, methodobj, params, app=app, io_thread=False)
File "/usr/local/lib/python3.6/site-packages/middlewared/main.py", line 1081, in _call
return await methodobj(*args)
File "/usr/local/lib/python3.6/site-packages/middlewared/schema.py", line 664, in nf
return await f(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/middlewared/plugins/vm.py", line 1139, in start
await self._manager.start(vm)
File "/usr/local/lib/python3.6/site-packages/middlewared/plugins/vm.py", line 62, in start
list(done)[0].result()
File "/usr/local/lib/python3.6/site-packages/middlewared/plugins/vm.py", line 317, in run
raise CallError(f'VM {self.vm["name"]} failed to start: {output}')
middlewared.service_exception.CallError: [EFAULT] VM ubuntu failed to start: vm_create: Device not configured
Can’t make heads or tails of what it could be. Wondering if it is my hardware.
Would know of anything I could check, change or do to make it work?
Im afraid I’m not able to help.
I am running both FN and hassio as VMs on VMWare ESXi hypervisor.
Also I run FN 9.10, which does not have bhyve VM capability.
If I had to guess it would be that you need to boot into your bios and enable virtualization (AMD-V? I never did VMs on AMD).
Your best bet would be google or the FN forums.
E.g. here:
In FreeNAS 11.2-U3, I installed Ubuntu Server 18.04 as a VM. In Ubuntu Server, I installed then Hass.io (amd Ombi, but that’s another story) and it works pretty well, with some caveats:
it seems that the Ubuntu VM gets into sleep mode or something, and I have no idea how to keep it alive all the time
Hass.io would NOT update if you use the Dashboard command.
It looks like openzwave has been updated to 0.1.4 but I don’t believe home assistant has been updated beyond 0.91.1 to include the changes, I assume it will be in the next update
and I have managed to break z-wave.
(Not to diminish the sterling work you are doing to help run HA in a FN jail)