This guide has been migrated from our website and might be outdated. Feel free to edit this guide to update it, and to remove this message after that.
Setting up Home Assistant to run as a background service is simple; macOS will start Home Assistant after the system has booted, the user has logged in, and make sure it’s always running.
To get Home Assistant installed as a background service, run:
$ hass --script macos install
Home Assistant has been installed. Open it here: http://localhost:8123
Home Assistant will log to ~/Library/Logs/homeassistant.log
Configuration is kept in ~/.homeassistant
To uninstall the service, run:
$ hass --script macos uninstall
Home Assistant has been uninstalled.
Note: automake is required for hass to start. If you are missing this on your system, you can install this by running:
The above may work under certain circumstances, but in my installation on a Mac running Catalina and HA in a VENV, it didn’t (and I’ve seen the same from others in the forums). The updated way to automate jobs on Mac is using launchd; see more at this link (but I will replicate the important parts herein):
In order to use launchd you create a .plist file in the appropriate folder and the system will see it and run the payload, in this case at system startup. If you’ve set things up the way I did with your user as the HA user, you would put the .plist file in /Users/YOURUSERNAME/Library/LaunchAgents; otherwise use the appropriate path for your HA user. That’s it- create the file as below and make sure to proof the paths.
In my case ~/homeassistant is the VENV.; by calling it that way you’re activating it. This is a .plist not a script. I could be wrong… not a guru, just a guy that experimented a lot
I had to go to Google on this one but I think this answers our question…. Sourcing the activation file (which is just a scipt) just ensures that the PATH is correct. I guess you need to activate it to work with the VENV from the command line but apparently you can run the VENV without that step. Done so through a .plist as above presumably obviates issues with loading the wrong python binary because we’ve specified the entire path. If anyone feels otherwise please correct me.
Note that, as I said above, the HA user will be the username in the path of the .../library/launchagents from which the .plist loads. You could create a non-admin user just for HA but then it would have to be logged in every time the server restarts. You don’t want to put it in /library/launchagents because then it would load as root.
Yeah they’re not talking about running a VENV there though.
Edit: they’re not specifying a path to the VENV of interest
It’s been working beautifully for me this way. I think the only criticism is that an admin user is running my HA.
Well it will work as long as the dependencies on your system are met. These can change if you install something else. This is avoided by using venv and the big advantage.
You are NOT running inside the venv.
I do the same at the moment, primarily, because I can’t get launchd working with venv…
That’s interesting and makes complete sense. Will cron run a script? It’s deprecated but still functional.
On the other hand, I just read a whole article about running scripts as launch agents/daemons. Maybe this would work? <string>/Users/server/runha.sh</string>
@davinci Check your permissions- I just got it to work like below. The script has permissions 711. Now if we can figure out how to use sudo -u or su to specify a non-admin user then it’s all worked out.
Ideally HA runs as a non-admin user because it’s the safest thing if it gets hacked (it is the entity exposed to the web via the port forward after all). But… I don’t want to have to log in multiple users every time I restart the server. So, I think what we could do is actually put the .plist in library/launchagents which would be run by root at any startup of the system, but use something in the script like: sudo -u homeassistant "/Users/username/homeassistant/bin/activate && /Users/username/homeassistant/bin/hass"
If we get it right then everything in the shell runs as the homeassistant user, not root (sudo means substitute user do, NOT superuser do). If we blow it then HA runs as root which is even worse than an admin user.