Merge branch 'current' into next
This commit is contained in:
commit
5d0a917cdd
112 changed files with 1014 additions and 352 deletions
|
@ -46,7 +46,7 @@ If HA does not start, check the log file output for errors at `/var/opt/homeassi
|
|||
|
||||
### {% linkable_title Extra: Running commands before hass executes %}
|
||||
|
||||
If any commands need to run before executing hass (like loading a virutal environment), put them in PRE_EXEC. This command must end with a semicolon.
|
||||
If any commands need to run before executing hass (like loading a virtual environment), put them in PRE_EXEC. This command must end with a semicolon.
|
||||
|
||||
### {% linkable_title Daemon script %}
|
||||
|
||||
|
|
|
@ -16,14 +16,14 @@ Newer linux distributions are trending towards using `systemd` for managing daem
|
|||
$ ps -p 1 -o comm=
|
||||
```
|
||||
|
||||
If the preceding command returns the string `systemd`, you are likely using `systemd`.
|
||||
If the preceding command returns the string `systemd`, continue with the instructions below.
|
||||
|
||||
If you want Home Assistant to be launched automatically, an extra step is needed to setup `systemd`. A service file is needed to control Home Assistant with `systemd`. The template below should be created using a text editor. Note, root permissions via `sudo` will likely be needed. The following should be noted to modify the template:
|
||||
A service file is needed to control Home Assistant with `systemd`. The template below should be created using a text editor. Note, root permissions via `sudo` will likely be needed. The following should be noted to modify the template:
|
||||
|
||||
- `ExecStart` contains the path to `hass` and this may vary. Check with `whereis hass` for the location.
|
||||
- If running Home Assistant in a Python virtual environment or a Docker container, please skip to section below.
|
||||
- For most systems, the file is `/etc/systemd/system/home-assistant@[your user].service` with [your user] replaced by the user account that Home Assistant will run as - normally `homeassistant`. In particular, this is the case for Ubuntu 16.04.
|
||||
- If unfamiliar with command-line text editors, `sudo nano -w [filename]` can be used with `[filename]` replaced with the full path to the file. Ex. `sudo nano -w /etc/systemd/system/home-assistant@[your user].service`. After text entered, press CTRL-X then press Y to save and exit.
|
||||
- If you're running Home Assistant in a Python virtual environment or a Docker container, please skip to the appropriate template listed below.
|
||||
|
||||
```
|
||||
[Unit]
|
||||
|
@ -78,6 +78,8 @@ ExecStopPost=/usr/bin/docker rm -f home-assistant-%i
|
|||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
### Next Steps
|
||||
|
||||
You need to reload `systemd` to make the daemon aware of the new configuration.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -35,7 +35,7 @@ Upstart will launch init scripts that are located in the directory `/etc/init.d/
|
|||
#
|
||||
# Installation:
|
||||
# 1) If any commands need to run before executing hass (like loading a
|
||||
# virutal environment), put them in PRE_EXEC. This command must end with
|
||||
# virtual environment), put them in PRE_EXEC. This command must end with
|
||||
# a semicolon.
|
||||
# 2) Set RUN_AS to the username that should be used to execute hass.
|
||||
# 3) Copy this script to /etc/init.d/
|
||||
|
|
|
@ -61,7 +61,7 @@ homeassistant:
|
|||
| `homebridge_name` | Name of the entity in `HomeBridge`.
|
||||
| `hidden` | Set to `true` to hide the entity.
|
||||
| `homebridge_hidden` | Set to `true` to hide the entity from `HomeBridge`.
|
||||
| `emulated_hue` | Set to `false` to hide the entity from emulated_hue.
|
||||
| `emulated_hue_hidden` | Set to `true` to hide the entity from `emulated_hue`.
|
||||
| `entity_picture` | Url to use as picture for entity.
|
||||
| `icon` | Any icon from [MaterialDesignIcons.com](http://MaterialDesignIcons.com). Prefix name with `mdi:`, ie `mdi:home`.
|
||||
| `assumed_state` | For switches with an assumed state two buttons are shown (turn off, turn on) instead of a switch. By setting `assumed_state` to `false` you will get the default switch icon.
|
||||
|
|
|
@ -27,8 +27,8 @@ Event `state_changed` is fired when a state changes. Both `old_state` and `new_s
|
|||
Field | Description
|
||||
----- | -----------
|
||||
`entity_id` | Entity ID of the changed entity. Example: `light.kitchen`
|
||||
`old_state` | The previous state of the entity before it changed. This field is ommitted if the entity is new.
|
||||
`new_state` | The new state of the entity. This field is ommitted if the entity is removed from the state machine.
|
||||
`old_state` | The previous state of the entity before it changed. This field is omitted if the entity is new.
|
||||
`new_state` | The new state of the entity. This field is omitted if the entity is removed from the state machine.
|
||||
|
||||
|
||||
### {% linkable_title Event `time_changed` %}
|
||||
|
@ -68,11 +68,11 @@ Field | Description
|
|||
|
||||
|
||||
### {% linkable_title Event `platform_discovered` %}
|
||||
Event `platform_discovered` is fired when a new platform has been discovered by the discovery component.
|
||||
Event `platform_discovered` is fired when a new platform has been discovered by the [`discovery`](/components/discovery/) component.
|
||||
|
||||
Field | Description
|
||||
----- | -----------
|
||||
`service` | The service that is discovered. Example: `zwave`.
|
||||
`service` | The platform that is discovered. Example: `zwave`.
|
||||
`discovered` | Dictionary containing discovery information. Example: `{ "host": "192.168.1.10", "port": 8889}`.
|
||||
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ homeassistant:
|
|||
|
||||
The package configuration can include: `switch`, `light`, `automation`, `groups` or the majority of the Home Assistant components.
|
||||
|
||||
It can be specified inline or in a seperate YAML file using `!include`.
|
||||
It can be specified inline or in a separate YAML file using `!include`.
|
||||
|
||||
Inline example, main `configuration.yaml`:
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ footer: true
|
|||
redirect_from: /topics/platform_options/
|
||||
---
|
||||
|
||||
Any component that is based on the entity component allows various extra options to be set per platform.
|
||||
Some components or platforms (those that are based on the [entity](https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/helpers/entity.py) class) allows various extra options to be set.
|
||||
|
||||
### {% linkable_title Entity namespace %}
|
||||
|
||||
|
@ -25,7 +25,7 @@ light:
|
|||
|
||||
### {% linkable_title Scan Interval %}
|
||||
|
||||
Platforms that require polling will be polled in an interval specified by the main component. For example a light will check every 30 seconds for a changed state. It is possible to overwrite this scan interval for any platform that is being polled by specifying a `scan_interval` config key. In the example below we setup the Philips Hue lights but tell Home Assistant to poll the devices every 10 seconds instead of the default 30 seconds.
|
||||
Platforms that require polling will be polled in an interval specified by the main component. For example a light will check every 30 seconds for a changed state. It is possible to overwrite this scan interval for any platform that is being polled by specifying a `scan_interval` configuration key. In the example below we setup the Philips Hue lights but tell Home Assistant to poll the devices every 10 seconds instead of the default 30 seconds.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry to poll Hue lights every 10 seconds.
|
||||
|
|
|
@ -51,7 +51,7 @@ script:
|
|||
{% endif %}{% endraw %}
|
||||
```
|
||||
|
||||
[Jinja2](http://jinja.pocoo.org/) supports a width variety of operations:
|
||||
[Jinja2](http://jinja.pocoo.org/) supports a wide variety of operations:
|
||||
|
||||
- [Mathematical operation](http://jinja.pocoo.org/docs/dev/templates/#math)
|
||||
- [Comparisons](http://jinja.pocoo.org/docs/dev/templates/#comparisons)
|
||||
|
|
|
@ -28,10 +28,15 @@ notify:
|
|||
|
||||
The basics of YAML syntax are block collections and mappings containing key-value pairs. Each item in a collection starts with a `-` while mappings have the format `key: value`. If you specify duplicate keys, the last value for a key is used. This is somewhat similar to a Hashtable or more specifically a dictionary in Python. These can be nested as well.
|
||||
|
||||
Note that indentation (just like in Python) is an important part of specifying relationships using YAML. Things that are indented are nested "inside" things that are one level higher. So in the above example, `platform: pushbullet` is a property of (nested inside) the `notify` component.
|
||||
Note that indentation is an important part of specifying relationships using YAML. Things that are indented are nested "inside" things that are one level higher. So in the above example, `platform: pushbullet` is a property of (nested inside) the `notify` component.
|
||||
|
||||
Getting the right indentation can be tricky if you're not using an editor with a fixed width font. Tabs are not allowed to be used for indentation. Convention is to use 2 spaces for each level of indentation.
|
||||
You can use the online service [YAMLLint](http://www.yamllint.com/) to check if your YAML syntax is correct before loading it into Home Assistant which will save you some time. If you do so, be aware that this is a third-party service and is not maintained by the Home Assistant community. *Please pay attention on not storing private data (passwords, api-keys, etc.) directly in that file.*
|
||||
Private data can be stored in a [seperate file](/docs/configuration/secrets/) or in [environmental variables](/docs/configuration/yaml/#using-environment-variables), which circumvents this problem of security.
|
||||
|
||||
You can use the online service [YAMLLint](http://www.yamllint.com/) to check if your YAML syntax is correct before loading it into Home Assistant which will save you some time. If you do so, be aware that this is a third-party service and is not maintained by the Home Assistant community.
|
||||
|
||||
<p class='note'>
|
||||
Please pay attention on not storing private data (passwords, API keys, etc.) directly in your `configuration.yaml` file. Private data can be stored in a [separate file](/docs/configuration/secrets/) or in [environmental variables](/docs/configuration/yaml/#using-environment-variables), which circumvents this problem of security.
|
||||
</p>
|
||||
|
||||
Text following a `#` are comments and are ignored by the system.
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather
|
|||
- Durable variables and state - Variables can be kept between events to keep track of things like the number of times a motion sensor has been activated, or how long it has been since a door opened.
|
||||
- All the power of Python - use any of Python's libraries, create your own modules, share variables, refactor and re-use code, create a single App to do everything, or multiple Apps for individual tasks - nothing is off limits!
|
||||
|
||||
It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatsoever about what it is controlling, reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner. The bulk of the work after that was adding additonal functions to make things that were already possible easier.
|
||||
It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatsoever about what it is controlling, reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner. The bulk of the work after that was adding additional functions to make things that were already possible easier.
|
||||
|
||||
# How it Works
|
||||
|
||||
|
|
|
@ -495,7 +495,7 @@ Note: `old` and `new` can be used singly or together.
|
|||
|
||||
##### {% linkable_title duration = <seconds> (optional) %}
|
||||
|
||||
If duration is supplied as a parameter, the callback will not fire unless the state listened for is maintained for that number of seconds. This makes the most sense if a specific attribute is specified (or the default os `state` is used), an in conjunction with the `old` or `new` parameters, or both. When the callback is called, it is supplied with the values of `entity`, `attr`, `old` and `new` that were current at the time the actual event occured, since the assumption is that none of them have changed in the intervening period.
|
||||
If duration is supplied as a parameter, the callback will not fire unless the state listened for is maintained for that number of seconds. This makes the most sense if a specific attribute is specified (or the default os `state` is used), an in conjunction with the `old` or `new` parameters, or both. When the callback is called, it is supplied with the values of `entity`, `attr`, `old` and `new` that were current at the time the actual event occurred, since the assumption is that none of them have changed in the intervening period.
|
||||
|
||||
```python
|
||||
def my_callback(self, **kwargs):
|
||||
|
@ -643,7 +643,7 @@ Delay, in seconds before the callback is invoked.
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -677,7 +677,7 @@ A Python `time` object that specifies when the callback will occur. If the time
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -715,7 +715,7 @@ A Python `datetime` object that specifies when the callback will occur.
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -754,7 +754,7 @@ A Python `time` object that specifies when the callback will occur. If the time
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -792,7 +792,7 @@ A Python `time` object that specifies when the callback will occur, the hour com
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -829,7 +829,7 @@ A Python `time` object that specifies when the callback will occur, the hour and
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -871,7 +871,7 @@ After the initial callback has occurred, another will occur every `repeat` secon
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -944,7 +944,7 @@ All of the scheduler calls above support 2 additional optional arguments, `rando
|
|||
- `random_start` - start of range of the random time
|
||||
- `random_end` - end of range of the random time
|
||||
|
||||
`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be a an absolute or relative time or sunrise/sunset depending on whcih scheduler call you use and these values affect the base time by the spcified amount. If not specified, they will default to `0`.
|
||||
`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be a an absolute or relative time or sunrise/sunset depending on which scheduler call you use and these values affect the base time by the spcified amount. If not specified, they will default to `0`.
|
||||
|
||||
For example:
|
||||
|
||||
|
@ -987,7 +987,7 @@ The time in seconds that the callback should be delayed after sunrise. A negativ
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
@ -1030,7 +1030,7 @@ The time in seconds that the callback should be delayed after sunrise. A negativ
|
|||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
Arbitary keyword parameters to be provided to the callback function when it is invoked.
|
||||
Arbitrary keyword parameters to be provided to the callback function when it is invoked.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ class = HelloWorld
|
|||
- `logfile` (optional) is the path to where you want `AppDaemon` to keep its main log. When run from the command line this is not used - log messages come out on the terminal. When running as a daemon this is where the log information will go. In the example above I created a directory specifically for AppDaemon to run from, although there is no reason you can't keep it in the `appdaemon` directory of the cloned repository. If `logfile = STDOUT`, output will be sent to stdout instead of stderr when running in the foreground, if not specified, output will be sent to STDOUT.
|
||||
- `errorfile` (optional) is the name of the logfile for errors - this will usually be errors during compilation and execution of the apps. If `errorfile = STDERR` errors will be sent to stderr instead of a file, if not specified, output will be sent to STDERR.
|
||||
- `app_dir` (optional) is the directory the apps are placed in. If not specified, AppDaemon will look first in `~/.homeassistant` then `/etc/appdaemon` for a subdirectory named `apps`
|
||||
- `threads` - the number of dedicated worker threads to create for running the apps. Note, this will bear no resembelance to the number of apps you have, the threads are re-used and only active for as long as required to tun a particular callback or initialization, leave this set to 10 unless you experience thread starvation
|
||||
- `threads` - the number of dedicated worker threads to create for running the apps. Note, this will bear no resemblance to the number of apps you have, the threads are re-used and only active for as long as required to tun a particular callback or initialization, leave this set to 10 unless you experience thread starvation
|
||||
- `latitude`, `longitude`, `elevation`, `timezone` - should all be copied from your Home Assistant configuration file
|
||||
- `cert_path` (optional) - path to root CA cert directory - use only if you are using self signed certs.
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@ So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations
|
|||
- Durable variables and state - variables can be kept between events to keep track of things like the number of times a motion sensor has been activated, or how long it has been since a door opened
|
||||
- All the power of Python - use any of Python's libraries, create your own modules, share variables, refactor and re-use code, create a single app to do everything, or multiple apps for individual tasks - nothing is off limits!
|
||||
|
||||
It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatever about what it is controlling or reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner - the bulk of the work after that was adding additonal functions to make things that were already possible easier.
|
||||
It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatever about what it is controlling or reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner - the bulk of the work after that was adding additional functions to make things that were already possible easier.
|
||||
|
||||
## {% linkable_title How it Works %}
|
||||
|
||||
|
|
|
@ -19,4 +19,4 @@ AppDaemon can be installed exactly as per the instructions for every other versi
|
|||
|
||||
## {% linkable_title Windows Under the Linux Subsystem %}
|
||||
|
||||
Windows 10 now supports a full Linux bash environment that is capable of running Python. This is essentially an Ubuntu distribution and works extremely well. It is possible to run AppDaemon in exactly the same way as for Linux distributions, and none of the above Windows Caveats apply to this version. This is the reccomended way to run AppDaemon in a Windows 10 and later environment.
|
||||
Windows 10 now supports a full Linux bash environment that is capable of running Python. This is essentially an Ubuntu distribution and works extremely well. It is possible to run AppDaemon in exactly the same way as for Linux distributions, and none of the above Windows Caveats apply to this version. This is the recommended way to run AppDaemon in a Windows 10 and later environment.
|
||||
|
|
|
@ -18,7 +18,7 @@ You need two parts in order to get it working correctly.
|
|||
|
||||
Become the user that run Home Assistant.
|
||||
|
||||
- A seperate Python script that syncs a specific folder. Which can be found [here](https://gist.github.com/riemers/31e3350041fd3e47e489cbc811209d6f)
|
||||
- A separate Python script that syncs a specific folder. Which can be found [here](https://gist.github.com/riemers/31e3350041fd3e47e489cbc811209d6f)
|
||||
- The excellent [dropbox uploader script](https://github.com/andreafabrizi/Dropbox-Uploader/blob/master/dropbox_uploader.sh) you can grab the .sh file only.
|
||||
|
||||
Download those files to a folder of your liking, after that edit both files and change paths accordingly.
|
||||
|
@ -46,7 +46,7 @@ Do note, this will **backup your passwords to Dropbox**.
|
|||
|
||||
### {% linkable_title Automate the backup %}
|
||||
|
||||
So you just made a full backup, next time you want it to be done automaticly. Since your database can change and so do other files over time.
|
||||
So you just made a full backup, next time you want it to be done automatically. Since your database can change and so do other files over time.
|
||||
Add it to your crontab, edit the **path/to** part.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -30,7 +30,7 @@ Some best practices to consider before putting your configuration on GitHub:
|
|||
|
||||
- Extensive use of [secrets.yaml](https://home-assistant.io/topics/secrets/) to hide sensitive information like usernames, passwords, device information, and location
|
||||
- Exclusion of some files, including `secrets.yaml` and device-specific information using a [`.gitignore`](https://git-scm.com/docs/gitignore) file
|
||||
- Regularly commiting your configuration to GitHub to make sure that your backup is up to date
|
||||
- Regularly committing your configuration to GitHub to make sure that your backup is up to date
|
||||
- Use a README.md to document your configuration and include screenshots of your Home Assistant GUI
|
||||
|
||||
### {% linkable_title Step 1: Installing and Initializing Git %}
|
||||
|
@ -127,7 +127,7 @@ git push origin master
|
|||
exit
|
||||
```
|
||||
|
||||
Every time you run this script, you will be prompted for a comment to describe the change(s) that you are commiting. This comment will be displayed beside each changed file on GitHub and will be stored after each commit. You will also be asked to enter your GitHub username and password (or ssh key passphrase if you use [GitHub with ssh](https://help.github.com/categories/ssh/)).
|
||||
Every time you run this script, you will be prompted for a comment to describe the change(s) that you are committing. This comment will be displayed beside each changed file on GitHub and will be stored after each commit. You will also be asked to enter your GitHub username and password (or ssh key passphrase if you use [GitHub with ssh](https://help.github.com/categories/ssh/)).
|
||||
|
||||
### {% linkable_title Step 7: Configuration file testing %}
|
||||
|
||||
|
@ -162,7 +162,7 @@ home_elevation: 0
|
|||
|
||||
### {% linkable_title Extra commands %}
|
||||
|
||||
You can enter these commands to get a list of the files in your local git repository and a status of files that have changed but not commited yet:
|
||||
You can enter these commands to get a list of the files in your local git repository and a status of files that have changed but not committed yet:
|
||||
|
||||
|
||||
```bash
|
||||
|
|
|
@ -101,7 +101,7 @@ Change below path to where you placed the `usb_backup.sh` and run the following
|
|||
|
||||
### {% linkable_title Auto mount %}
|
||||
|
||||
This does not automaticly mount your USB drive at boot. You need to do that manually or add a line to your `/etc/fstab` file.
|
||||
This does not automatically mount your USB drive at boot. You need to do that manually or add a line to your `/etc/fstab` file.
|
||||
|
||||
If your drive is on `/dev/sda1`, you could add a entry to your `/etc/fstab` like so:
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ This guide was added by mf_social on 16/03/2017 and was valid at the time of wri
|
|||
* You are not currently running anything on port 80 on your network (you'd know if you were).
|
||||
* If you are not using Home Assistant on a Debian/Raspian/Hassbian system you will be able to convert any of the terminology I use in to the correct syntax for your system.
|
||||
* You understand that this is a 'guide' covering the general application of these things to the general masses and there are things outside of the scope of it, and it does not cover every eventuality (although I have made some notes where people may stumble). Also, I have used some turns of phrase to make it easier to understand for the novice reader which people of advanced knowledge may say is innacurate. My goal here is to get you through this guide with a satisfactory outcome and have a decent understanding of what you are doing and why, not to teach you advanced internet communication protocols.
|
||||
* Each step presumes you have fully completed the previous step succesfully, so if you did an earlier step following a different guide, please ensure that you have not missed anything out that may affect the step you have jumped to, and ensure that you adapt any commands to take in to account different file placements from other guides.
|
||||
* Each step presumes you have fully completed the previous step successfully, so if you did an earlier step following a different guide, please ensure that you have not missed anything out that may affect the step you have jumped to, and ensure that you adapt any commands to take in to account different file placements from other guides.
|
||||
|
||||
Steps we will take:
|
||||
|
||||
|
@ -358,11 +358,11 @@ If you were previously using a webapp on your phone/tablet to access your Home A
|
|||
https://home-assistant.io/docs/frontend/mobile/
|
||||
```
|
||||
|
||||
All done? Accessing your Home Assistant from across the world with your DuckDNS URL and a lovely secure logo on your browser? Ace! Now let's clean up our port forwards so that we are only exposing the parts of our network that are absolutely neccesary to the outside world.
|
||||
All done? Accessing your Home Assistant from across the world with your DuckDNS URL and a lovely secure logo on your browser? Ace! Now let's clean up our port forwards so that we are only exposing the parts of our network that are absolutely necessary to the outside world.
|
||||
|
||||
### {% linkable_title 6 - Clean up port forwards %}
|
||||
|
||||
In step 2 we created a port forwarding rule called `ha_test`. This opens port 8123 to the world, and is no longer neccessary.
|
||||
In step 2 we created a port forwarding rule called `ha_test`. This opens port 8123 to the world, and is no longer necessary.
|
||||
|
||||
Go to your router's configuration pages and delete the `ha_test` rule.
|
||||
|
||||
|
@ -402,7 +402,7 @@ $ sudo apt-get install ssl-cert-check
|
|||
```
|
||||
|
||||
<p class='note'>
|
||||
In cases where, for whatever reason, apt-get installing is not appropriate for your installation you can fetch the ssl-cert-check script from `http://prefetch.net/code/ssl-cert-check` bearing in mind that you will have to modify the command in the sensor code below to run the script from wherever you put it, modify permission if neccessary and so on.
|
||||
In cases where, for whatever reason, apt-get installing is not appropriate for your installation you can fetch the ssl-cert-check script from `http://prefetch.net/code/ssl-cert-check` bearing in mind that you will have to modify the command in the sensor code below to run the script from wherever you put it, modify permission if necessary and so on.
|
||||
</p>
|
||||
|
||||
To set up a senor add the following to your `configuration.yaml` (remembering to correct the URL for your DuckDNS):
|
||||
|
@ -433,7 +433,7 @@ If you are a TWO-RULE person (from step 6), you can automatically renew your cer
|
|||
There are a number of options for automating the renewal process:
|
||||
|
||||
#### Option 1:
|
||||
Your certificate can be renewed as a 'cron job' - cron jobs are background tasks run by the computer at specified intervals (and are totally independant of Home Assistant). Defining cron is outside of the scope of this guide but you will have had dealings with `crontab` when setting up DuckDNS in step 3
|
||||
Your certificate can be renewed as a 'cron job' - cron jobs are background tasks run by the computer at specified intervals (and are totally independent of Home Assistant). Defining cron is outside of the scope of this guide but you will have had dealings with `crontab` when setting up DuckDNS in step 3
|
||||
|
||||
To set a cron job to run the script at regular intervals:
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ There are no dependencies on Python modules that are not part of the standard li
|
|||
|
||||
### {% linkable_title Configuration %}
|
||||
Near the top of the configurator.py-file you will find some global variables you can change to customize the configurator. If you are unfamiliar with Python: when setting variables of the type _string_, you have to write that within quotation marks. The default settings are fine for just checking out the configurator quickly. With more customized setups you should change some settings though.
|
||||
To keep your settings across updates it is also possible to save settings in an external file. In that case copy [settings.conf](https://github.com/danielperna84/hass-configurator/blob/master/settings.conf) whereever you like and append the full path to the file to the command when starting the configurator. E.g. `sudo .configurator.py /home/homeassistant/.homeassistant/mysettings.conf`. This file is in JSON format. So make sure it has a valid syntax (you can set the editor to JSON to get syntax highlighting for the settings). The major difference to the settings in the py-file is, that `None` becomes `null`.
|
||||
To keep your settings across updates it is also possible to save settings in an external file. In that case copy [settings.conf](https://github.com/danielperna84/hass-configurator/blob/master/settings.conf) wherever you like and append the full path to the file to the command when starting the configurator. E.g. `sudo .configurator.py /home/homeassistant/.homeassistant/mysettings.conf`. This file is in JSON format. So make sure it has a valid syntax (you can set the editor to JSON to get syntax highlighting for the settings). The major difference to the settings in the py-file is, that `None` becomes `null`.
|
||||
|
||||
#### LISTENIP (string)
|
||||
The IP the service is listening on. By default it is binding to `0.0.0.0`, which is every interface on the system.
|
||||
|
|
|
@ -12,7 +12,7 @@ redirect_from: /ecosystem/ios/location/
|
|||
|
||||
## {% linkable_title Location tracking when outside a Home Assistant zone %}
|
||||
|
||||
Home Assistant for iOS receives _significant location updates_ from iOS. Whenever an update is received, it is sent to Home Assistant. Roughly, an update is received everytime that your device transfers to a new cellular tower, a significant amount of time has passed (usually a couple hours) or a connection state changes and the system notices your location recently changed.
|
||||
Home Assistant for iOS receives _significant location updates_ from iOS. Whenever an update is received, it is sent to Home Assistant. Roughly, an update is received every time that your device transfers to a new cellular tower, a significant amount of time has passed (usually a couple hours) or a connection state changes and the system notices your location recently changed.
|
||||
|
||||
Apple [defines][apple-location-programming-guide] significant significant-change location updates as:
|
||||
|
||||
|
|
|
@ -90,7 +90,7 @@ This output can be cut and pasted into your configuration.yaml file as required
|
|||
|
||||
Scenegen supports all documented effects for lights including transitions and flash effects, however generally it is easier to run scenegen to get the basic setup and add any effects manually later.
|
||||
|
||||
Note that depending on the type of light there may be a delay in actually setting up its parameters and Home Assistant actually recieving that state. For instance, if you set a scene up with the Hue App, Home Assistant won't see those changes for up to 10 seconds. Turning on a ZWave light might not be seen for an entire poll interval. For this reason, its good practice to wait for a while after the scene is setup before running scenegen. Alternatively, perform all setup using the Home Assistant frontend and it will instantly have the required state for capture.
|
||||
Note that depending on the type of light there may be a delay in actually setting up its parameters and Home Assistant actually receiving that state. For instance, if you set a scene up with the Hue App, Home Assistant won't see those changes for up to 10 seconds. Turning on a ZWave light might not be seen for an entire poll interval. For this reason, its good practice to wait for a while after the scene is setup before running scenegen. Alternatively, perform all setup using the Home Assistant frontend and it will instantly have the required state for capture.
|
||||
|
||||
## {% linkable_title Advanced Usage %}
|
||||
|
||||
|
|
20
source/_docs/glossary.markdown
Normal file
20
source/_docs/glossary.markdown
Normal file
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Glossary"
|
||||
description: "Home Assistant's Glossary."
|
||||
date: 2017-10-08 08:30
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
{% assign entries = site.data.glossary | sort: 'topic' %}
|
||||
|
||||
<ul>
|
||||
{% for entry in entries %}
|
||||
<li>
|
||||
<b>{{ entry.topic }}</b>: {{ entry.description | markdownify }}
|
||||
</li>
|
||||
{% endfor %}
|
||||
</ul>
|
|
@ -14,12 +14,14 @@ The easiest way to install Home Assistant on your Raspberry Pi is by using HASSb
|
|||
|
||||
1. [Download the Hassbian image][image-download] (364 MB)
|
||||
2. Use [Etcher][etcher] to flash the image to your SD card
|
||||
3. Ensure your Raspberry Pi has wired access to the internet for the entire process or configure your wireless network (details below).
|
||||
3. Ensure your Raspberry Pi has wired access to the internet for the entire process or configure your wireless network settings **before proceeding to step 4**.
|
||||
4. Insert SD card to Raspberry Pi and turn it on. Initial installation of Home Assistant will take about 5 minutes.
|
||||
|
||||
These instructions are also available as a [video](https://www.youtube.com/watch?v=iIz6XqDwHEk). Additional information is available in this [video](https://www.youtube.com/watch?v=tCGlQSsQ-Mc).
|
||||
|
||||
After initial boot an installer will run in the background and takes around 15 minutes to complete, after it has finished you can reach Home Assistant in your browser at [http://hassbian.local:8123]. If you want to login via SSH, the default username is `pi` and password is `raspberry` (please change this by running `passwd`). The Home Assistant configuration is located at `/home/homeassistant/.homeassistant/`.
|
||||
After initial boot an installer will run in the background and takes around 15 minutes to complete, after it has finished, you will be prompted to login: `hassbian login:`. Installation is complete at this point. The default username is `pi` and the password is `raspberry`.
|
||||
|
||||
Open a browser on a device that's connected to the same WiFi network as your Raspberry Pi and point it to Home Assistant at [http://hassbian.local:8123]. If you want to login via SSH, the default username is `pi` and password is `raspberry` (please change this by running `passwd`). The Home Assistant configuration is located at `/home/homeassistant/.homeassistant/`.
|
||||
|
||||
If you find that the web page is not reachable after 30 minutes or so, check that you have files in `/home/homeassistant/.homeassistant/`, if there are no files in this location then run the installer manually using this command: `sudo systemctl start install_homeassistant.service`.
|
||||
|
||||
|
@ -45,6 +47,7 @@ network={
|
|||
psk="YOUR_PASSWORD"
|
||||
}
|
||||
```
|
||||
You may need to adjust the country code depending upon where you are. A list of codes can be found [here](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements).
|
||||
|
||||
### {% linkable_title Technical Details %}
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ The [Raspberry Pi All-In-One Installer](https://github.com/home-assistant/fabric
|
|||
The only requirement is that you have a Raspberry Pi with a fresh installation of [Raspbian](https://www.raspberrypi.org/downloads/raspbian/) connected to your network.
|
||||
|
||||
<p class='note'>
|
||||
Note that as of 2016-11-30 SSH is disabled by default in the official Raspbian images. Adding an empty file called `ssh` to `/boot/` or the FAT32 partition will enable it. More information is on the Raspberry Pi Foundation [Blog](https://www.raspberrypi.org/blog/page/2/?fish#a-security-update-for-raspbian-pixel).
|
||||
Note that as of 2016-11-30 SSH is disabled by default in the official Raspbian images. Adding an empty file called `ssh` to `/boot/` on the FAT32 partition will enable it. More information is on the Raspberry Pi Foundation [Blog](https://www.raspberrypi.org/blog/page/2/?fish#a-security-update-for-raspbian-pixel).
|
||||
</p>
|
||||
|
||||
Irrespective of whether you use SSH to connect to the Pi from another computer or not, you need SSH to install Home Assistant. So go ahead and enable SSH.
|
||||
|
@ -62,7 +62,7 @@ To upgrade the All-In-One setup manually:
|
|||
|
||||
* Login to Raspberry Pi `ssh pi@your_raspberry_pi_ip`
|
||||
* Change to homeassistant user `sudo su -s /bin/bash homeassistant`
|
||||
* Change to virtual enviroment `source /srv/homeassistant/homeassistant_venv/bin/activate`
|
||||
* Change to virtual environment `source /srv/homeassistant/homeassistant_venv/bin/activate`
|
||||
* Update Home Assistant `pip3 install --upgrade homeassistant`
|
||||
* Type `exit` to logout the hass user and return to the `pi` user.
|
||||
|
||||
|
@ -70,7 +70,7 @@ To upgrade the All-In-One setup manually:
|
|||
**If you deployed Home Assistant via the AiO installer prior to December 2016**
|
||||
* Login to Raspberry Pi `ssh pi@your_raspberry_pi_ip`
|
||||
* Change to homeassistant user `sudo su -s /bin/bash hass`
|
||||
* Change to virtual enviroment `source /srv/hass/hass_venv/bin/activate`
|
||||
* Change to virtual environment `source /srv/hass/hass_venv/bin/activate`
|
||||
* Update Home Assistant `pip3 install --upgrade homeassistant`
|
||||
* Type `exit` to logout the hass user and return to the `pi` user.
|
||||
</div>
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Manual installation on a Raspberry Pi"
|
||||
description: "Instructions to install Home Assistant on a Raspberry Pi runnning Raspbian Lite."
|
||||
description: "Instructions to install Home Assistant on a Raspberry Pi running Raspbian Lite."
|
||||
date: 2016-09-05 16:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
@ -88,7 +88,7 @@ $ mosquitto_pub -h 127.0.0.1 -p 1883 -t "homeassistant/switch/irrigation/set" -m
|
|||
Setting up a sensor with multiple measurement values requires multiple consecutive configuration topic submissions.
|
||||
|
||||
- Configuration topic no1: `homeassistant/sensor/sensorBedroomT/config`
|
||||
- Configuration payload no1: `{"device_class": "sensor", "name": "Temperature", "state_topic": "homeassistant/sensor/sensorBedroom/state", "unit_of_measurement": "°C", "value_template": "{{ value_json.temperature}}" }`
|
||||
- Configuration payload no1: `{"device_class": "sensor", "name": "Temperature", "state_topic": "homeassistant/sensor/sensorBedroom/state", "unit_of_measurement": "°C", "value_template": "{% raw %}{{ value_json.temperature}}{% endraw %}" }`
|
||||
- Configuration topic no2: `homeassistant/sensor/sensorBedroomH/config`
|
||||
- Configuration payload no2: `{"device_class": "sensor", "name": "Humidity", "state_topic": "homeassistant/sensor/sensorBedroom/state", "unit_of_measurement": "%", "value_template": "{{ value_json.humidity}}" }`
|
||||
- Configuration payload no2: `{"device_class": "sensor", "name": "Humidity", "state_topic": "homeassistant/sensor/sensorBedroom/state", "unit_of_measurement": "%", "value_template": "{% raw %}{{ value_json.humidity}}{% endraw %}" }`
|
||||
- Common state payload: `{ "temperature": 23.20, "humidity": 43.70 }`
|
||||
|
|
|
@ -77,7 +77,7 @@ delay: {% raw %}'00:{{ states.input_number.minute_delay.state | int }}:00'{% end
|
|||
```
|
||||
### {% linkable_title Wait %}
|
||||
|
||||
Wait until some things are complete. We support at the moment `wait_template` for waiting until a condition is `true`, see also on [Template-Trigger](/docs/automation/trigger/#template-trigger). The Timeout has same syntax as `delay`. If you set a Timeout for 1 minute and the condition is not satified within that minute, the script will continue.
|
||||
Wait until some things are complete. We support at the moment `wait_template` for waiting until a condition is `true`, see also on [Template-Trigger](/docs/automation/trigger/#template-trigger). It is possible to set a timeout after which the script will abort its execution if the condition is not satisfied. Timeout has the same syntax as `delay`.
|
||||
|
||||
```yaml
|
||||
# wait until media player have stop the playing
|
||||
|
|
|
@ -19,7 +19,7 @@ Test any changes to your `configuration.yaml` file before launching Home Assista
|
|||
$ hass --script check_config
|
||||
```
|
||||
|
||||
### {% linkable_title Existance of configuration %}
|
||||
### {% linkable_title Existence of configuration %}
|
||||
|
||||
This script checks if the `configuration.yaml` file exists. If the file is not available, one is created.
|
||||
|
||||
|
@ -47,7 +47,7 @@ $ hass --script benchmark async_million_events
|
|||
|
||||
### {% linkable_title Old scripts %}
|
||||
|
||||
Usally those scripts were only used when a massive update happend and was announced in the release notes.
|
||||
Usually those scripts were only used when a massive update happened and was announced in the release notes.
|
||||
|
||||
- `db_migrator`: Migrate an existing SQLite database to the new schema.
|
||||
- `influxdb_migrator`: Convert an old InfluxDB to the new format.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue