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
* Added documentation for "autobypass" option added to the AlarmDecoder integration
* Update source/_integrations/alarmdecoder.markdown
Co-Authored-By: Franck Nijhof <frenck@frenck.nl>
* Removed the autobypass option from the default configuration, as suggested
* Minor text change
* Jekyll build is failing, so trying to spot the problem
* Update source/_integrations/alarmdecoder.markdown
Co-Authored-By: Franck Nijhof <frenck@frenck.nl>
* Restored original zone numbers in the example configuration, as it was not related to the preview-deploy problem
Co-authored-by: Franck Nijhof <frenck@frenck.nl>
The converter used in the configuration plugin is not aware of
references declared outside of the block and therefore fails to render
reference links. This replaces them with explicit links.
Resolves#11643
The previous edit I made was not completely correct and only worked (partially) because I already had the Google Assistant Component API (not voice) activated.
This is my previous pull request: https://github.com/home-assistant/home-assistant.io/pull/11600
Hi all - my first proposed change, and it's minor. I ran into this issue where I misread the original and believed other devices (HS103's in my case) were supported for everything (control and sensors) when it's really just the HS110 that can create sensors. Anyway, I thought I would make it more clear for anyone else who may have misread it like I did. Cheers!
* 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.
* Improved & simplified documentation
* New amendments tested and validated on both IOS and Android - instructions updated to reflect this.
* Improved & simplified documentation. I've gone through the menus on Android and IOS and can confirm this is where the information required is located
* Minor grammar tweaks
* Update source/_integrations/doorbird.markdown
Co-Authored-By: Franck Nijhof <frenck@frenck.nl>
* Update source/_integrations/doorbird.markdown
Co-Authored-By: Franck Nijhof <frenck@frenck.nl>
* Update source/_integrations/doorbird.markdown
Co-Authored-By: Franck Nijhof <frenck@frenck.nl>
* Update source/_integrations/doorbird.markdown
Co-Authored-By: Franck Nijhof <frenck@frenck.nl>
Co-authored-by: Franck Nijhof <frenck@frenck.nl>
