A common question in the support channels involves the `UndefinedError` returned when an automation that references a trigger state object in the action is manually triggered. Hopefully this note will reduce those questions in the future. I also tweaked the example automations.
It was a bit unclear what happens if one omits continue_on_timeout (i.e what's its default value) so I decided to test it and fill the gap so others shouldn't do it again
We get a regular trickle of folks installing on Windows, who're then stuck on things like auto-starting, and almost everything else.
As much as I don't like removing community provided guides, I think this one needs to disappear.
With this instruction a have an error after starting service:
```
# sysrc homeassistant_enable="YES"
homeassistant_enable: -> YES
# service homeassistant start
install: : No such file or directory
Starting homeassistant.
daemon: open: Permission denied
/usr/local/etc/rc.d/homeassistant: WARNING: failed to start homeassistant
```
There is needs to define logfile variable in rc.d script
* Be consistent with Home Assistant spelling
* Refer to the Configurator without "HASS"
That's what's it calls itself and how it is in the add-on store.
* Be consistent with Hass.io spelling
* Tell vscode to spell HassOS like that
* updated rc.d script
Add extra_commands
check_config - checks config using `hass --script check_config`
upgrade - stops HA / upgrade / checks config / starts HA (only starts if config check passes)
test - simple test to check directories / activate venv / check version of python and homeassistant
restart - (modified) check_config / stop HA /start HA (only restart if config check passes)
NOTE: All extra_commands REQUIRE bash to be installed
`pkg install bash`
I also removed the check_config from the pre_start function because because it will prevent HA from starting
if the configuration is missing (Like a clean install from example). NO BUENO!
Another case to consider haveing no configuration even after initial install is troubleshooting or testing.
For instance with rc.d script createing a fresh config is simple.
Let's suppose my working config is at
`/home/hass/homeassistant`
Now to get a clean configuration I can just do this
service homeassistant stop
sysrc sysrc homeassistant_config_dir="/home/hass/ha_test_config"
service homeassistant start
That's it! Configuration wise, it's a clean install. To switch back to working config I just
service homeassistant stop
sysrc sysrc homeassistant_config_dir="/home/hass/homeassistant"
service homeassistant start
Awesome right?! But that doesn't work if check_config fails during pre_start
* add pkgs
These are not required to install HA but they are quickly missed once you start to actual use it. Let's just avoid
some fustration from the start. I don't think this list should be all inclusive but these basic things seem to be
frequently needed from the start.
autoconf |
gmake | - looking at you Z-Wave, Stream, IKEA Tradfri
pkgconf |
bash - Give me bash or give me death! Seriously, it makes life easier. There's not alot of *BSD focus
around HA. I only use *BSD because of FreeNAS -- Typically (with the exception of jails) FreeNAS is webui.
I'm ok with Linux cli and it's very similiar to FreeNAS but not the same. It's not bash. I don't think it
needs to be for the root user either. But having bash installed and used by the HA user makes it easier
to follow along with exising documentation for other virtualenv type installs when trying to further expand
your HA installation
* give me bash or give me death!
Most people won't notice a differene but we'll know in our hearts we did the right thing.
* fix typo
I'm lucky I can spell my name
* whitespace
* use venv
Use the built-in venv instead of virtualenv which must be installed seperate.
Users experiencing issues / interference by ModemManager are still commonly popping up in the forum. I changed the wording, so hopefully users will more easily recognize this applies to them.
By including the prompts in the shell commands, it breaks the copy/paste functionality provided on the webpage https://www.home-assistant.io/docs/installation/raspberry-pi/. I understand it was to indicate a change for the user but that should be in the surrounding text.
Looks like a similar change was made to `automation_sun.markdown` in #10532, attributed to #10315.
As someone trying to add an automation for the sun's elevation, the inconsistency was confusing. I don't know if other parts of this page should be updated in a similar way.
