jeans/home-assistant.io
jeans/home-assistant.io
1
0
Fork 0
mirror of https://github.com/home-assistant/home-assistant.io.git synced 2025-07-28 11:47:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'current' into next

Browse Source
This commit is contained in:
Franck Nijhof 2020-05-09 00:30:24 +02:00
commit e46594bbb2
No known key found for this signature in database
GPG Key ID: D62583BA8AB11CA3
600 changed files with 335 additions and 3047 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
.gitpod.yml
View File

@ -1,15 +0,0 @@
tasks:
- init: gem install bundler -v 2.0.1 && bundle install && bundle exec rake generate
ports:
- port: 4000
onOpen: open-browser
github:
prebuilds:
master: true
branches: true
pullRequests: true
pullRequestsFromForks: true
addCheck: true
addComment: false
addBadge: false
addLabel: false

3
.slugignore
View File

@ -1,3 +0,0 @@
plugins
sass
source

30
.theia/tasks.json
View File

@ -1,30 +0,0 @@
{
"tasks": [
{
"label": "Generate",
"type": "shell",
"command": "bundle",
"args": [
"exec",
"rake",
"generate"
],
"options": {
"cwd": "${workspaceFolder}"
}
},
{
"label": "Preview",
"type": "shell",
"command": "bundle",
"args": [
"exec",
"rake",
"preview"
],
"options": {
"cwd": "${workspaceFolder}"
}
}
]
}

2
Gemfile
View File

@ -4,7 +4,7 @@ ruby '> 2.5.0'
group :development do
gem 'rake', '13.0.1'
gem 'jekyll', '4.0.0'
gem 'jekyll', '4.0.1'
gem 'compass', '1.0.3'
gem 'sass-globbing', '1.1.5'
gem 'stringex', '2.8.5'

4
Gemfile.lock
View File

@ -31,7 +31,7 @@ GEM
http_parser.rb (0.6.0)
i18n (1.8.2)
concurrent-ruby (~> 1.0)
jekyll (4.0.0)
jekyll (4.0.1)
addressable (~> 2.4)
colorator (~> 1.0)
em-websocket (~> 0.5)
@ -121,7 +121,7 @@ PLATFORMS
DEPENDENCIES
compass (= 1.0.3)
jekyll (= 4.0.0)
jekyll (= 4.0.1)
jekyll-commonmark (= 1.3.1)
jekyll-paginate (= 1.1.0)
jekyll-redirect-from (= 0.16.0)

4
_config.yml
View File

@ -101,8 +101,8 @@ social:
# Home Assistant release details
current_major_version: 0
current_minor_version: 109
current_patch_version: 4
date_released: 2020-05-04
current_patch_version: 5
date_released: 2020-05-06
# Either # or the anchor link to latest release notes in the blog post.
# Must be prefixed with a # and have double quotes around it.

2
source/_docs/autostart/systemd.markdown
View File

@ -27,6 +27,7 @@ After=network-online.target
[Service]
Type=simple
User=%i
WorkingDirectory=/home/%i/.homeassistant
ExecStart=/usr/bin/hass
[Install]
@ -45,6 +46,7 @@ After=network-online.target
[Service]
Type=simple
User=%i
WorkingDirectory=/home/%i/.homeassistant
ExecStart=/srv/homeassistant/bin/hass -c "/home/%i/.homeassistant"
[Install]

103
source/_docs/ecosystem/appdaemon.markdown
View File

@ -1,103 +0,0 @@
---
title: "AppDaemon"
description: "AppDaemon is a loosely coupled, multithreaded, sandboxed Python execution environment for writing automation apps for Home Assistant"
redirect_from: /ecosystem/appdaemon/
---
AppDaemon is a loosely coupled, multithreaded, sandboxed Python execution environment for writing automation apps for Home Assistant.
# Another Take on Automation
AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather complement them. For a lot of things, automations work well and can be very succinct. However, there is a class of more complex automations for which they become harder to use, and AppDaemon then comes into its own. It brings quite a few things to the table:
- New paradigm - Some problems require a procedural and/or iterative approach, and `AppDaemon` Apps are a much more natural fit for this. Recent enhancements to Home Assistant scripts and templates have made huge strides, but for the most complex scenarios, Apps can do things that automations can't.
- Ease of use - AppDaemon's API is full of helper functions that make programming as easy and natural as possible. The functions and their operation are as "Pythonic" as possible; experienced Python programmers should feel right at home.
- Reuse - write a piece of code once and instantiate it as an App as many times as you need with different parameters; e.g., a motion light program that you can use in five different places around your home. The code stays the same, you just dynamically add new instances of it in the configuration file.
- Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to its loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it, and restart them to use the new code without the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple Apps and have them picked up dynamically. For a final trick, removing or adding Apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
- Complex logic - Python's If/Else constructs are clearer and easier to code for arbitrarily complex nested logic.
- 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 additional functions to make things that were already possible easier.
# How it Works
The best way to show what AppDaemon does is through a few simple examples.
## Sunrise/Sunset Lighting
Let's start with a simple App to turn a light on every night at sunset and off every morning at sunrise. Every App when first started will have its `initialize()` function called, which gives it a chance to register a callback for AppDaemons's scheduler for a specific time. In this case, we are using `run_at_sunrise()` and `run_at_sunset()` to register two separate callbacks. The argument `0` is the number of seconds offset from sunrise or sunset and can be negative or positive. For complex intervals, it can be convenient to use Python's `datetime.timedelta` class for calculations. When sunrise or sunset occurs, the appropriate callback function, `sunrise_cb()` or `sunset_cb()`, is called, which then makes a call to Home Assistant to turn the porch light on or off by activating a scene. The variables `args["on_scene"]` and `args["off_scene"]` are passed through from the configuration of this particular App, and the same code could be reused to activate completely different scenes in a different version of the App.
```python
import appdaemon.plugins.hass.hassapi as hass
class OutsideLights(hass.Hass):
def initialize(self):
self.run_at_sunrise(self.sunrise_cb)
self.run_at_sunset(self.sunset_cb)
def sunrise_cb(self, kwargs):
self.turn_on(self.args["off_scene"])
def sunset_cb(self, kwargs):
self.turn_on(self.args["on_scene"])
```
This is also fairly easy to achieve with Home Assistant automations, but we are just getting started.
## Motion Light
Our next example is to turn on a light when motion is detected and it is dark, and turn it off after a period of time. This time, the `initialize()` function registers a callback on a state change (of the motion sensor) rather than a specific time. We tell AppDaemon that we are only interested in state changes where the motion detector comes on by adding an additional parameter to the callback registration - `new = "on"`. When the motion is detected, the callback function `motion()` is called, and we check whether or not the sun has set using a built-in convenience function: `sun_down()`. Next, we turn the light on with `turn_on()`, then set a timer using `run_in()` to turn the light off after 60 seconds, which is another call to the scheduler to execute in a set time from now, which results in `AppDaemon` calling `light_off()` 60 seconds later using the `turn_off()` call to actually turn the light off. This is still pretty simple in code terms:
```python
import appdaemon.plugins.hass.hassapi as hass
class FlashyMotionLights(hass.Hass):
def initialize(self):
self.listen_state(self.motion, "binary_sensor.drive", new="on")
def motion(self, entity, attribute, old, new, kwargs):
if self.sun_down():
self.turn_on("light.drive")
self.run_in(self.light_off, 60)
def light_off(self, kwargs):
self.turn_off("light.drive")
```
This is starting to get a little more complex in Home Assistant automations, requiring an automation rule and two separate scripts.
Now let's extend this with a somewhat artificial example to show something that is simple in AppDaemon but very difficult if not impossible using automations. Let's warn someone inside the house that there has been motion outside by flashing a lamp on and off ten times. We are reacting to the motion as before by turning on the light and setting a timer to turn it off again, but in addition, we set a 1-second timer to run `flash_warning()`, which, when called, toggles the inside light and sets another timer to call itself a second later. To avoid re-triggering forever, it keeps a count of how many times it has been activated and bails out after ten iterations.
```python
import appdaemon.plugins.hass.hassapi as hass
class MotionLights(hass.Hass):
def initialize(self):
self.listen_state(self.motion, "binary_sensor.drive", new="on")
def motion(self, entity, attribute, old, new, kwargs):
if self.self.sun_down():
self.turn_on("light.drive")
self.run_in(self.light_off, 60)
self.flashcount = 0
self.run_in(self.flash_warning, 1)
def light_off(self, kwargs):
self.turn_off("light.drive")
def flash_warning(self, kwargs):
self.toggle("light.living_room")
self.flashcount += 1
if self.flashcount < 10:
self.run_in(self.flash_warning, 1)
```
Of course, if I wanted to make this App or its predecessor reusable, I would have provide parameters for the sensor, the light to activate on motion, the warning light, and even the number of flashes and delay between flashes.
In addition, Apps can write to `AppDaemon`'s log files, and there is a system of constraints that allows you to control when and under what circumstances Apps and callbacks are active to keep the logic clean and simple.
For full installation instructions, see the [AppDaemon Project Documentation pages](http://appdaemon.readthedocs.io/en/stable/).

2133
source/_docs/ecosystem/appdaemon/api.markdown
View File

File diff suppressed because it is too large Load Diff

9
source/_docs/ecosystem/appdaemon/configuration.markdown
View File

@ -1,9 +0,0 @@
---
title: "Configuration"
description: "AppDaemon Configuration"
redirect_from: /ecosystem/appdaemon/configuration/
---
the documentation for configuring AppDaemon can be found in its own documentation.
https://appdaemon.readthedocs.io/en/latest/CONFIGURE.html

7
source/_docs/ecosystem/appdaemon/example_apps.markdown
View File

@ -1,7 +0,0 @@
---
title: "Example Apps"
description: "AppDaemon Example Apps"
redirect_from: /ecosystem/appdaemon/example_apps/
---
There are a number of example apps under conf/examples, and the `conf/examples.cfg` file gives sample parameters for them.

9
source/_docs/ecosystem/appdaemon/installation.markdown
View File

@ -1,9 +0,0 @@
---
title: "Installation"
description: "AppDaemon Installation"
redirect_from: /ecosystem/appdaemon/installation/
---
Installation is either by `pip3` or Docker.
Follow [these instructions](https://github.com/home-assistant/appdaemon/blob/dev/README.rst) for full details.

7
source/_docs/ecosystem/appdaemon/operation.markdown
View File

@ -1,7 +0,0 @@
---
title: "Operation"
description: "Operation"
redirect_from: /ecosystem/appdaemon/tutorial/
---
Since `AppDaemon` under the covers uses the exact same APIs as the frontend UI, you typically see it react at about the same time to a given event. Calling back to Home Assistant is also pretty fast especially if they are running on the same machine. In action, observed latency above the built in automation integration is usually sub-second.

7
source/_docs/ecosystem/appdaemon/reboot.markdown
View File

@ -1,7 +0,0 @@
---
title: "Starting at Reboot"
description: "Starting at Reboot"
redirect_from: /ecosystem/appdaemon/reboot/
---
To run `AppDaemon` at reboot, I have provided a sample init script in the `./scripts` directory. These have been tested on a Raspberry Pi - your mileage may vary on other systems. There is also a sample Systemd script.

89
source/_docs/ecosystem/appdaemon/running.markdown
View File

@ -1,89 +0,0 @@
---
title: "Running AppDaemon"
description: "Running AppDaemon"
redirect_from: /ecosystem/appdaemon/running/
---
As configured, `AppDaemon` comes with a single HelloWorld App that will send a greeting to the logfile to show that everything is working correctly.
## Docker
Assuming you have set the configuration up as described above for Docker, you can run it with the command:
```bash
$ docker run -d -v <Path to Config>/conf:/conf --name appdaemon acockburn/appdaemon:latest
```
In the example above you would use:
```bash
$ docker run -d -v /Users/foo/ha-config:/conf --name appdaemon acockburn/appdaemon:latest
```
Where you place the `conf` and `conf/apps` directory is up to you - it can be in downloaded repository, or anywhere else on the host, as long as you use the correct mapping in the `docker run` command.
You can inspect the logs as follows:
```bash
$ docker logs appdaemon
2016-08-22 10:08:16,575 INFO Got initial state
2016-08-22 10:08:16,576 INFO Loading Module: /export/hass/appdaemon_test/conf/apps/hello.py
2016-08-22 10:08:16,578 INFO Loading Object hello_world using class HelloWorld from module hello
2016-08-22 10:08:16,580 INFO Hello from AppDaemon
2016-08-22 10:08:16,584 INFO You are now ready to run Apps!
```
Note that for Docker, the error and regular logs are combined.
## `pip3`
You can then run AppDaemon from the command line as follows:
```bash
$ appdaemon -c conf/appdaemon.cfg
```
If all is well, you should see something like the following:
```bash
$ appdaemon -c conf/appdaemon.cfg
2016-08-22 10:08:16,575 INFO Got initial state
2016-08-22 10:08:16,576 INFO Loading Module: /export/hass/appdaemon_test/conf/apps/hello.py
2016-08-22 10:08:16,578 INFO Loading Object hello_world using class HelloWorld from module hello
2016-08-22 10:08:16,580 INFO Hello from AppDaemon
2016-08-22 10:08:16,584 INFO You are now ready to run Apps!
```
## AppDaemon arguments
```txt
usage: appdaemon [-h] [-c CONFIG] [-p PIDFILE] [-t TICK] [-s STARTTIME]
[-e ENDTIME] [-i INTERVAL]
[-D {DEBUG,INFO,WARNING,ERROR,CRITICAL}] [-v] [-d]
optional arguments:
-h, --help show this help message and exit
-c CONFIG, --config CONFIG
full path to config file
-p PIDFILE, --pidfile PIDFILE
full path to PID File
-t TICK, --tick TICK time in seconds that a tick in the schedular lasts
-s STARTTIME, --starttime STARTTIME
start time for scheduler <YYYY-MM-DD HH:MM:SS>
-e ENDTIME, --endtime ENDTIME
end time for scheduler <YYYY-MM-DD HH:MM:SS>
-i INTERVAL, --interval INTERVAL
multiplier for scheduler tick
-D {DEBUG,INFO,WARNING,ERROR,CRITICAL}, --debug {DEBUG,INFO,WARNING,ERROR,CRITICAL}
debug level
-v, --version show program's version number and exit
-d, --daemon run as a background process
```
-c is the path to the configuration file. If not specified, AppDaemon will look for a file named `appdaemon.cfg` first in `~/.homeassistant` then in `/etc/appdaemon`. If the file is not specified and it is not found in either location, AppDaemon will raise an exception.
-d and -p are used by the init file to start the process as a daemon and are not required if running from the command line.
-D can be used to increase the debug level for internal AppDaemon operations as well as apps using the logging function.
The -s, -i, -t and -s options are for the Time Travel feature and should only be used for testing. They are described in more detail in the API documentation.

137
source/_docs/ecosystem/appdaemon/tutorial.markdown
View File

@ -1,137 +0,0 @@
---
title: "AppDaemon Tutorial"
description: "AppDaemon Tutorial"
redirect_from: /ecosystem/appdaemon/tutorial/
---
## Another Take on Automation
If you haven't yet read Paulus' excellent Blog entry on [Perfect Home Automation](/blog/2016/01/19/perfect-home-automation/) I would encourage you to take a look. As a veteran of several Home Automation systems with varying degrees success, it was this article more than anything else that convinced me that Home Assistant had the right philosophy behind it and was on the right track. One of the most important points made is that being able to control your lights from your phone, 9 times out of 10 is harder than using a light switch - where Home Automation really comes into its own is when you start removing the need to use a phone or the switch - the "Automation" in Home Automation. A surprisingly large number of systems out there miss this essential point and have limited abilities to automate anything which is why a robust and open system such as Home Assistant is such an important part of the equation in bring this all together in the vast and chaotic ecosystem that is the "Internet of Things".
So given the importance of Automation, what should Automation allow us to do? I am a pragmatist at heart so I judge individual systems by the ease of accomplishing a few basic but representative tasks:
- Can the system respond to presence or absence of people?
- Can I turn a light on at Sunset +/- a certain amount of time?
- Can I arrive home in light or dark and have the lights figure out if they should be on or off?
- As I build my system out, can I get the individual pieces to co-operate and use and re-use (potentially complex) logic to make sure everything works smoothly?
- Is it open and expandable?
- Does it run locally without any reliance on the cloud?
In my opinion, Home Assistant accomplishes the majority of these very well with a combination of Automations, Scripts and Templates, and its Restful API.
So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather complement them. For a lot of things, automations work well and can be very succinct. However, there is a class of more complex automations for which they become harder to use, and AppDaemon then comes into its own. It brings quite a few things to the table:
- New paradigm - some problems require a procedural and/or iterative approach, and `AppDaemon` Apps are a much more natural fit for this. Recent enhancements to Home Assistant scripts and templates have made huge strides, but for the most complex scenarios, Apps can do things that Automations can't
- Ease of use - AppDaemon's API is full of helper functions that make programming as easy and natural as possible. The functions and their operation are as "Pythonic" as possible, experienced Python programmers should feel right at home.
- Reuse - write a piece of code once and instantiate it as an app as many times as you need with different parameters e.g., a motion light program that you can use in 5 different places around your home. The code stays the same, you just dynamically add new instances of it in the configuration file
- Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to its loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it and restart them to use the new code with out the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple apps and have them picked up dynamically, and for a final trick, removing or adding apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
- Complex logic - Python's If/Else constructs are clearer and easier to code for arbitrarily complex nested logic
- 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 additional functions to make things that were already possible easier.
## How it Works
The best way to show what AppDaemon does is through a few simple examples.
### Sunrise/Sunset Lighting
Lets start with a simple App to turn a light on every night fifteen
minutes (900 seconds) before sunset and off every morning at sunrise.
Every App when first started will have its ``initialize()`` function
called which gives it a chance to register a callback for AppDaemons's
scheduler for a specific time. In this case we are using
`run_at_sunrise()` and `run_at_sunset()` to register 2 separate
callbacks. The named argument `offset` is the number of seconds offset
from sunrise or sunset and can be negative or positive (it defaults to
zero). For complex intervals it can be convenient to use Python's
`datetime.timedelta` class for calculations. In the example below,
when sunrise or just before sunset occurs, the appropriate callback
function, `sunrise_cb()` or `before_sunset_cb()` is called which
then makes a call to Home Assistant to turn the porch light on or off by
activating a scene. The variables `args["on_scene"]` and
`args["off_scene"]` are passed through from the configuration of this
particular App, and the same code could be reused to activate completely
different scenes in a different version of the App.
```python
import appdaemon.plugins.hass.hassapi as hass
class OutsideLights(hass.Hass):
def initialize(self):
self.run_at_sunrise(self.sunrise_cb)
self.run_at_sunset(self.before_sunset_cb, offset=-900)
def sunrise_cb(self, kwargs):
self.turn_on(self.args["off_scene"])
def before_sunset_cb(self, kwargs):
self.turn_on(self.args["on_scene"])
```
This is also fairly easy to achieve with Home Assistant automations, but we are just getting started.
### Motion Light
Our next example is to turn on a light when motion is detected and it is dark, and turn it off after a period of time. This time, the `initialize()` function registers a callback on a state change (of the motion sensor) rather than a specific time. We tell AppDaemon that we are only interested in state changes where the motion detector comes on by adding an additional parameter to the callback registration - `new = "on"`. When the motion is detected, the callback function `motion()` is called, and we check whether or not the sun has set using a built-in convenience function: `sun_down()`. Next, we turn the light on with `turn_on()`, then set a timer using `run_in()` to turn the light off after 60 seconds, which is another call to the scheduler to execute in a set time from now, which results in `AppDaemon` calling `light_off()` 60 seconds later using the `turn_off()` call to actually turn the light off. This is still pretty simple in code terms:
```python
import appdaemon.appapi as appapi
class FlashyMotionLights(appapi.AppDaemon):
def initialize(self):
self.listen_state(self.motion, "binary_sensor.drive", new="on")
def motion(self, entity, attribute, old, new, kwargs):
if self.sun_down():
self.turn_on("light.drive")
self.run_in(self.light_off, 60)
def light_off(self, kwargs):
self.turn_off("light.drive")
```
This is starting to get a little more complex in Home Assistant automations requiring an Automation rule and two separate scripts.
Now lets extend this with a somewhat artificial example to show something that is simple in AppDaemon but very difficult if not impossible using automations. Lets warn someone inside the house that there has been motion outside by flashing a lamp on and off 10 times. We are reacting to the motion as before by turning on the light and setting a timer to turn it off again, but in addition, we set a 1 second timer to run `flash_warning()` which when called, toggles the inside light and sets another timer to call itself a second later. To avoid re-triggering forever, it keeps a count of how many times it has been activated and bales out after 10 iterations.
```python
import homeassistant.appapi as appapi
class MotionLights(appapi.AppDaemon):
def initialize(self):
self.listen_state(self.motion, "binary_sensor.drive", new="on")
def motion(self, entity, attribute, old, new, kwargs):
if self.self.sun_down():
self.turn_on("light.drive")
self.run_in(self.light_off, 60)
self.flashcount = 0
self.run_in(self.flash_warning, 1)
def light_off(self, kwargs):
self.turn_off("light.drive")
def flash_warning(self, kwargs):
self.toggle("light.living_room")
self.flashcount += 1
if self.flashcount < 10:
self.run_in(self.flash_warning, 1)
```
Of course if I wanted to make this App or its predecessor reusable I would have provide parameters for the sensor, the light to activate on motion, the warning light and even the number of flashes and delay between flashes.
In addition, Apps can write to `AppDaemon`'s logfiles, and there is a system of constraints that allows you to control when and under what circumstances Apps and callbacks are active to keep the logic clean and simple.
I have spent the last few weeks moving all of my (fairly complex) automations over to `AppDaemon` and so far it is working very reliably.
Some people will maybe look at all of this and say "what use is this, I can already do all of this", and that is fine, as I said this is an alternative not a replacement, but I am hopeful that for some users this will seem a more natural, powerful and nimble way of building potentially very complex automations.
If this has whet your appetite, feel free to give it a try.
Happy Automating!

13
source/_docs/ecosystem/appdaemon/updating.markdown
View File

@ -1,13 +0,0 @@
---
title: "Updating AppDaemon"
description: "Updating AppDaemon"
redirect_from: /ecosystem/appdaemon/updating/
---
To update AppDaemon after I have released new code, just run the following command to update your copy:
```bash
sudo pip3 install --upgrade appdaemon
```
If you are using Docker, rerun the steps to grab the latest Docker image.

16
source/_docs/ecosystem/appdaemon/windows.markdown
View File

@ -1,16 +0,0 @@
---
title: "Windows Support"
description: "Windows Support"
redirect_from: /ecosystem/appdaemon/windows/
---
AppDaemon runs under windows and has been tested with the official 3.5.2 release of Python. There are a couple of caveats however:
- The `-d` or `--daemonize` option is not supported owing to limitations in the Windows implementation of Python.
- Some internal diagnostics are disabled. This is not user visible but may hamper troubleshooting of internal issues if any crop up
AppDaemon can be installed exactly as per the instructions for every other version using pip3.
## 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 recommended way to run AppDaemon in a Windows 10 and later environment.

34
source/_docs/ecosystem/hadashboard.markdown
View File

@ -1,34 +0,0 @@
---
title: "HADashboard"
description: "HADashboard is a dashboard for Home Assistant that is intended to be wall mounted, and is optimized for distance viewing."
redirect_from: /ecosystem/hadashboard/
---
HADashboard is a modular, skinnable dashboard for [Home Assistant](/) that is intended to be wall mounted, and is optimized for distance viewing.
<p class='img'>
<img src='/images/hadashboard/dash1.png' />
Default Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash2.png' />
Obsidian Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash3.png' />
Zen Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash4.png' />
Simply Red Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash5.png' />
Glassic Theme
</p>
For full installation instructions see the HADashboard section in the [AppDaemon Project Documentation](http://appdaemon.readthedocs.io/en/stable/DASHBOARD_INSTALL.html).

8
source/_docs/installation.markdown
View File

@ -47,7 +47,7 @@ These install options are fully supported by Home Assistant's documentation. For
<div class='note'>
The only installation methods that allow you to use Home Assistant Add-ons is using the Home Assistant image and [manual Supervised installer](/hassio/installation/#alternative-install-home-assistant-supervised-on-a-generic-linux-host). All other methods only install the base Home Assistant packages, however the software from the add-ons may still usually be installed manually like any other program.
The only installation methods that allow you to use Home Assistant Add-ons is using the Home Assistant image. All other methods only install the base Home Assistant packages, however the software from the add-ons may still usually be installed manually like any other program.
</div>
@ -112,10 +112,4 @@ These guides are provided as-is. Some of these install methods are more limited
</div>
<div class='title'>FreeNAS</div>
</a>
<a class='option-card' href='/hassio/installation/#alternative-install-home-assistant-supervised-on-a-generic-linux-host'>
<div class='img-container'>
<img src='https://brands.home-assistant.io/homeassistant/icon.png' />
</div>
<div class='title'>Home Assistant Supervised <br> on generic Linux server</div>
</a>
</div>

2
source/_docs/installation/docker.markdown
View File

@ -10,8 +10,6 @@ These below instructions are for an installation of Home Assistant Core running
Note that Docker command line option `--net=host` or the compose file equivalent `network_mode: host` must be used to put put Home Assistant on the host's network, otherwise certain functionality - including mDNS and UPnP - will break. The `-p` command line option or the compose file equivalent `ports:` is not compatible with host networking mode and must not be used.
For an installation of Home Assistant Supervised, which includes Home Assistant's add-on ecosystem, see the instructions for installing [Home Assistant Supervised on a generic Linux host](/hassio/installation/#alternative-install-home-assistant-supervised-on-a-generic-linux-host/).
</div>
## Platform Installation

2
source/_docs/installation/raspberry-pi.markdown
View File

@ -41,7 +41,7 @@ sudo apt-get upgrade -y
Install the dependencies.
```bash
sudo apt-get install python3 python3-dev python3-venv python3-pip libffi-dev libssl-dev
sudo apt-get install python3 python3-dev python3-venv python3-pip libffi-dev libssl-dev autoconf
```
Add an account for Home Assistant Core called `homeassistant`.

2
source/_docs/mqtt/discovery.markdown
View File

@ -267,7 +267,7 @@ Supported abbreviations for device registry configuration:
The following software has built-in support for MQTT discovery:
- [Sonoff-Tasmota](https://github.com/arendst/Sonoff-Tasmota) (starting with 5.11.1e)
- [Tasmota](https://github.com/arendst/Tasmota) (starting with 5.11.1e)
- [ESPHome](https://esphome.io)
- [ESPurna](https://github.com/xoseperez/espurna)
- [Arilux AL-LC0X LED controllers](https://github.com/mertenats/Arilux_AL-LC0X)

119
source/_docs/z-wave/device-specific.markdown
View File

@ -1291,3 +1291,122 @@ Example Event:
- service: switch.toggle
entity_id: switch.office_fan
```
### Zooz S2 MultiRelay (Zen16)
Contact Zooz to obtain the over the air firmware update instructions and new user manual for the MultiRelay.
Once the firmware is updated, the the new configuration parameters will have to be added to the `zwcfg` file. Replace the existing `COMMAND_CLASS_CONFIGURATION` with the one of the following options:
```xml
<CommandClass id="112">
<Value type="list" genre="config" index="1" label="On Off Status After Power Failure" size="1" min="0" max="4" value="1">
<Help>On Off Status After Power Failure. Default: all relays restore to previous state</Help>
<Item label="all relays forced off" value="0"/>
<Item label="all relays restore to previous state" value="1"/>
<Item label="all relays forced on" value="2"/>
<Item label="relays 1/2 restore, 3/4 forced off" value="3"/>
<Item label="relays 1/2 restore, 3/4 forced on" value="4"/>
</Value>
<Value type="list" genre="config" index="2" label="Switch Type for Relay 1 (Sw1)" size="1" min="0" max="3" value="2">
<Help>Switch Type for Relay 1 (Sw1). Choose the wall switch type you want to connect to the Sw1 terminal. Default: toggle switch (state changes whenever the switch is toggled)</Help>
<Item label="momentary switch" value="0"/>
<Item label="toggle switch (light on when switch is up/off when down)" value="1"/>
<Item label="toggle switch (state changes whenever the switch is toggled)" value="2"/>
<Item label="garage door (momentary mode for Z-Wave control)" value="3"/>
</Value>
<Value type="list" genre="config" index="3" label="Switch Type for Relay 2 (Sw2)" size="1" min="0" max="3" value="2">
<Help>Switch Type for Relay 2 (Sw2). Choose the wall switch type you want to connect to the Sw2 terminal. Default: toggle switch (state changes whenever the switch is toggled)</Help>
<Item label="momentary switch" value="0"/>
<Item label="toggle switch (light on when switch is up/off when down)" value="1"/>
<Item label="toggle switch (state changes whenever the switch is toggled)" value="2"/>
<Item label="garage door (momentary mode for Z-Wave control)" value="3"/>
</Value>
<Value type="list" genre="config" index="4" label="Switch Type for Relay 3 (Sw3)" size="1" min="0" max="3" value="2">
<Help>Switch Type for Relay 3 (Sw3). Choose the wall switch type you want to connect to the Sw3 terminal. Default: toggle switch (state changes whenever the switch is toggled)</Help>
<Item label="momentary switch" value="0"/>
<Item label="toggle switch (light on when switch is up/off when down)" value="1"/>
<Item label="toggle switch (state changes whenever the switch is toggled)" value="2"/>
<Item label="garage door (momentary mode for Z-Wave control)" value="3"/>
</Value>
<Value type="list" genre="config" index="5" label="LED Indicator Control" size="1" min="0" max="3" value="0">
<Help>LED Indicator Control. Choose if you want the LED indicator to turn on when any of the relays are on or if all of them are off, or if you want it to remain on or off at all times. Default: On when all relays are off</Help>
<Item label="On when all relays are off" value="0"/>
<Item label="On when any relays are on" value="1"/>
<Item label="Always Off" value="2"/>
<Item label="Always On" value="3"/>
</Value>
<Value type="int" genre="config" index="6" label="Auto Turn-Off Timer for Relay 1" size="4" min="0" max="65535" value="0" units="minutes">
<Help>Auto Turn-Off Timer for Relay 1. Sets the time (in minutes) after which you want relay 1 to automatically turn off once it has been turned on. Range: 1-65535. Default: 0 (disabled)</Help>
</Value>
<Value type="int" genre="config" index="7" label="Auto Turn-On Timer for Relay 1" size="4" min="0" max="65535" value="0" units="minutes">
<Help>Auto Turn-On Timer for Relay 1. Sets the time (in minutes) after which you want relay 1 to automatically turn on once it has been turned off. Range: 1-65535. Default: 0 (disabled)</Help>
</Value>
<Value type="int" genre="config" index="8" label="Auto Turn-Off Timer for Relay 2" size="4" min="0" max="65535" value="0" units="minutes">
<Help>Auto Turn-Off Timer for Relay 2. Sets the time (in minutes) after which you want relay 2 to automatically turn off once it has been turned on. Range: 1-65535. Default: 0 (disabled)</Help>
</Value>
<Value type="int" genre="config" index="9" label="Auto Turn-On Timer for Relay 2" size="4" min="0" max="65535" value="0" units="minutes">
<Help>Auto Turn-On Timer for Relay 2. Sets the time (in minutes) after which you want relay 2 to automatically turn on once it has been turned off. Range: 1-65535. Default: 0 (disabled)</Help>
</Value>
<Value type="int" genre="config" index="10" label="Auto Turn-Off Timer for Relay 3" size="4" min="0" max="65535" value="0" units="minutes">
<Help>Auto Turn-Off Timer for Relay 3. Sets the time (in minutes) after which you want relay 3 to automatically turn off once it has been turned on. Range: 1-65535. Default: 0 (disabled)</Help>
</Value>
<Value type="int" genre="config" index="11" label="Auto Turn-On Timer for Relay 3" size="4" min="0" max="65535" value="0" units="minutes">
<Help>Auto Turn-On Timer for Relay 3. Sets the time (in minutes) after which you want relay 3 to automatically turn on once it has been turned off. Range: 1-65535. Default: 0 (disabled)</Help>
</Value>
<Value type="list" genre="config" index="12" label="Enable/Disable Manual Control for SW1" size="1" min="0" max="2" value="1">
<Help>Enable/Disable Manual Control for SW1. Default: enabled</Help>
<Item label="disabled" value="0"/>
<Item label="enabled" value="1"/>
<Item label="local control disabled with enable on/off reports" value="2"/>
</Value>
<Value type="list" genre="config" index="13" label="Enable/Disable Manual Control for SW2" size="1" min="0" max="2" value="1">
<Help>Enable/Disable Manual Control for SW2. Default: enabled</Help>
<Item label="disabled" value="0"/>
<Item label="enabled" value="1"/>
<Item label="local control disabled with enable on/off reports" value="2"/>
</Value>
<Value type="list" genre="config" index="14" label="Enable/Disable Manual Control for SW3" size="1" min="0" max="2" value="1">
<Help>Enable/Disable Manual Control for SW3. Default: enabled</Help>
<Item label="disabled" value="0"/>
<Item label="enabled" value="1"/>
<Item label="local control disabled with enable on/off reports" value="2"/>
</Value>
<Value type="list" genre="config" index="15" label="Auto Turn-Off Timer Unit for Relay 1" size="1" min="0" max="2" value="0">
<Help>Choose between second, minutes, and hours as the unit for Auto Turn-Off time for Relay 1. Default: minutes</Help>
<Item label="minutes" value="0"/>
<Item label="seconds" value="1"/>
<Item label="hours" value="2"/>
</Value>
<Value type="list" genre="config" index="16" label="Auto Turn-On Timer Unit for Relay 1" size="1" min="0" max="2" value="0">
<Help>Choose between second, minutes, and hours as the unit for Auto Turn-On time for Relay 1. Default: minutes</Help>
<Item label="minutes" value="0"/>
<Item label="seconds" value="1"/>
<Item label="hours" value="2"/>
</Value>
<Value type="list" genre="config" index="17" label="Auto Turn-Off Timer Unit for Relay 2" size="1" min="0" max="2" value="0">
<Help>Choose between second, minutes, and hours as the unit for Auto Turn-Off time for Relay 2. Default: minutes</Help>
<Item label="minutes" value="0"/>
<Item label="seconds" value="1"/>
<Item label="hours" value="2"/>
</Value>
<Value type="list" genre="config" index="18" label="Auto Turn-On Timer Unit for Relay 2" size="1" min="0" max="2" value="0">
<Help>Choose between second, minutes, and hours as the unit for Auto Turn-On time for Relay 2. Default: minutes</Help>
<Item label="minutes" value="0"/>
<Item label="seconds" value="1"/>
<Item label="hours" value="2"/>
</Value>
<Value type="list" genre="config" index="19" label="Auto Turn-Off Timer Unit for Relay 3" size="1" min="0" max="2" value="0">
<Help>Choose between second, minutes, and hours as the unit for Auto Turn-Off time for Relay 3. Default: minutes</Help>
<Item label="minutes" value="0"/>
<Item label="seconds" value="1"/>
<Item label="hours" value="2"/>
</Value>
<Value type="list" genre="config" index="20" label="Auto Turn-On Timer Unit for Relay 3" size="1" min="0" max="2" value="0">
<Help>Choose between second, minutes, and hours as the unit for Auto Turn-On time for Relay 3. Default: minutes</Help>
<Item label="minutes" value="0"/>
<Item label="seconds" value="1"/>
<Item label="hours" value="2"/>
</Value>
</CommandClass>
```

6
source/_includes/asides/docs_navigation.html
View File

@ -261,12 +261,6 @@
<li>{% active_link /docs/autostart/synology/ Synology NAS %}</li>
</ul>
</li>
<li>
{% active_link /docs/ecosystem/appdaemon/ AppDaemon %}
</li>
<li>
{% active_link /docs/ecosystem/hadashboard/ HADashboard %}
</li>
<li>
Remote access
<ul>

2
source/_integrations/cover.template.markdown
View File

@ -26,6 +26,7 @@ cover:
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door"
value_template: "{{ states('sensor.garage_door')|float > 0 }}"
open_cover:
@ -149,6 +150,7 @@ cover:
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door"
position_template: "{{ states('sensor.garage_door') }}"
open_cover:

141
source/_integrations/deconz.markdown
View File

@ -230,145 +230,6 @@ automation:
{% endraw %}
### AppDaemon
#### AppDaemon event helper
Helper app that creates a sensor `sensor.deconz_event` with a state that represents the id from the last event and an attribute to show the event data.
Put this in `apps.yaml`:
{% raw %}
```yaml
deconz_helper:
module: deconz_helper
class: DeconzHelper
```
Put this in `deconz_helper.py`:
```python
import appdaemon.plugins.hass.hassapi as hass
import datetime
from datetime import datetime
class DeconzHelper(hass.Hass):
def initialize(self) -> None:
self.listen_event(self.event_received, "deconz_event")
def event_received(self, event_name, data, kwargs):
event_data = data["event"]
event_id = data["id"]
event_received = datetime.now()
self.log(f"Deconz event received from {event_id}. Event was: {event_data}")
self.set_state(
"sensor.deconz_event",
state=event_id,
attributes={
"event_data": event_data,
"event_received": str(event_received),
},
)
```
{% endraw %}
Note: the event will not be visible before one event gets sent.
#### AppDaemon remote template
{% raw %}
```yaml
remote_control:
module: remote_control
class: RemoteControl
event: deconz_event
id: dimmer_switch_1
```
```python
import appdaemon.plugins.hass.hassapi as hass
class RemoteControl(hass.Hass):
def initialize(self):
if "event" in self.args:
self.listen_event(self.handle_event, self.args["event"])
def handle_event(self, event_name, data, kwargs):
if data["id"] == self.args["id"]:
self.log(data["event"])
if data["event"] == 1002:
self.log("Button on")
elif data["event"] == 2002:
self.log("Button dim up")
elif data["event"] == 3002:
self.log("Button dim down")
elif data["event"] == 4002:
self.log("Button off")
```
{% endraw %}
#### AppDaemon IKEA Tradfri remote template
Community app from [Teachingbirds](https://community.home-assistant.io/u/teachingbirds/summary). This app uses an IKEA Tradfri remote to control Sonos speakers with play/pause, volume up and down, next and previous track.
{% raw %}
```yaml
sonos_remote_control:
module: sonos_remote
class: SonosRemote
event: deconz_event
id: sonos_remote
sonos: media_player.sonos
```
{% endraw %}
{% raw %}
```python
import appdaemon.plugins.hass.hassapi as hass
class SonosRemote(hass.Hass):
def initialize(self):
self.sonos = self.args["sonos"]
if "event" in self.args:
self.listen_event(self.handle_event, self.args["event"])
def handle_event(self, event_name, data, kwargs):
if data["id"] == self.args["id"]:
if data["event"] == 1002:
self.log("Button toggle")
self.call_service("media_player/media_play_pause", entity_id=self.sonos)
elif data["event"] == 2002:
self.log("Button volume up")
self.call_service("media_player/volume_up", entity_id=self.sonos)
elif data["event"] == 3002:
self.log("Button volume down")
self.call_service("media_player/volume_down", entity_id=self.sonos)
elif data["event"] == 4002:
self.log("Button previous")
self.call_service(
"media_player/media_previous_track", entity_id=self.sonos
)
elif data["event"] == 5002:
self.log("Button next")
self.call_service("media_player/media_next_track", entity_id=self.sonos)
```
{% endraw %}
## Binary Sensor
The following sensor types are supported:
@ -509,6 +370,8 @@ The sensor also has an attribute called "daylight" that has the value `true` whe
These states can be used in automations as a trigger (e.g., trigger when a certain phase of daylight starts or ends) or condition (e.g., trigger only if in a certain phase of daylight).
Please note that the deCONZ daylight sensor is disabled by default in Home Assistant. It can be enabled manually by going to your deCONZ controller device in the Home Assistant UI.
## Switch
Switches are devices like power plugs and sirens.

2
source/_integrations/frontier_silicon.markdown
View File

@ -14,7 +14,7 @@ This integration provides support for Internet Radios based on the [Frontier Sil
* Hama: [IR110], [DIR3110]
* Medion: [Medion Radios]
* Silvercrest: [SIRD 14 C2]
* Some models from: Auna, Technisat, Revo, Pinell
* Some models from: Auna, Technisat, Revo, Pinell, Como Audio
This integration was developed and tested with a Hama [DIR3110] and a Medion [MD 87466].

24
source/_integrations/homekit.markdown
View File

@ -102,7 +102,7 @@ homekit:
type: boolean
default: false
zeroconf_default_interface:
description: By default, zeroconf will attempt to bind to all interfaces. For systems running using network isolation or similar, this may result HomeKit not being seen on the network. Change this option to `true` if HomeKit cannot be discovered.
description: By default, zeroconf will attempt to bind to all interfaces. For systems running using network isolation or similar, this may result in HomeKit not being seen on the network. Change this option to `true` if HomeKit cannot be discovered.
required: true
type: boolean
default: false
@ -237,7 +237,6 @@ homekit:
available options: copy, libopus
{% endconfiguration %}
## Setup
To enable the HomeKit integration in Home Assistant, add the following to your configuration file:
@ -281,7 +280,7 @@ The HomeKit Accessory Protocol Specification only allow a maximum of 150 unique
### Persistence Storage
Unfortunately `HomeKit` doesn't support any persistent storage - only the configuration for accessories that are added to the `Home Assistant Bridge` are kept. To avoid problems, it is recommended to use an automation to always start `HomeKit` with at least the same entities setup. If for some reason some entities are not set up, their configuration will be deleted. (State unknown or similar will not cause any issues.)
Unfortunately, `HomeKit` doesn't support any persistent storage - only the configuration for accessories that are added to the `Home Assistant Bridge` are kept. To avoid problems, it is recommended to use an automation to always start `HomeKit` with at least the same entities setup. If, for some reason, some entities are not set up, their configuration will be deleted. (State unknown or similar will not cause any issues.)
A common situation might be if you decide to disable parts of the configuration for testing. Please make sure to disable `auto start` and `turn off` the `Start HomeKit` automation (if you have one).
@ -298,6 +297,7 @@ Please remember that you can only have a single `automation` entry. Add the auto
</div>
{% raw %}
```yaml
# Example for Z-Wave
homekit:
@ -315,11 +315,13 @@ automation:
action:
- service: homekit.start
```
{% endraw %}
For a general delay where your integration doesn't generate an event, you can also do:
{% raw %}
```yaml
# Example using a delay after the start of Home Assistant
homekit:
@ -334,11 +336,13 @@ automation:
- delay: 00:05 # Waits 5 minutes
- service: homekit.start
```
{% endraw %}
In some cases it might be desirable to check that all entities are available before starting `HomeKit`. This can be accomplished by adding an additional `binary_sensor` as follows:
{% raw %}
```yaml
# Example checking specific entities to be available before start
homekit:
@ -363,6 +367,7 @@ automation:
continue_on_timeout: false
- service: homekit.start
```
{% endraw %}
## Configure Filter
@ -370,6 +375,7 @@ automation:
By default, no entity will be excluded. To limit which entities are being exposed to `HomeKit`, you can use the `filter` parameter. Keep in mind only [supported components](#supported-components) can be added.
{% raw %}
```yaml
# Example filter to include specified domains and exclude specified entities
homekit:
@ -380,6 +386,7 @@ homekit:
exclude_entities:
- light.kitchen_light
```
{% endraw %}
Filters are applied as follows:
@ -388,14 +395,14 @@ Filters are applied as follows:
2. Includes, no excludes - only include specified entities
3. Excludes, no includes - only exclude specified entities
4. Both includes and excludes:
* Include domain specified
- Include domain specified
- if domain is included, and entity not excluded, pass
- if domain is not included, and entity not included, fail
* Exclude domain specified
- Exclude domain specified
- if domain is excluded, and entity not included, fail
- if domain is not excluded, and entity not excluded, pass
- if both include and exclude domains specified, the exclude domains are ignored
* Neither include or exclude domain specified
- Neither include or exclude domain specified
- if entity is included, pass (as #2 above)
- if entity include and exclude, the entity exclude is ignored
@ -438,8 +445,8 @@ Restart your Home Assistant instance. This feature requires running an mDNS forw
If you have a firewall configured on your Home Assistant system, make sure you open the following ports:
- UDP: 5353
- TCP: 51827
- UDP: 5353
- TCP: 51827 (or the configured/used `port` in the integration settings).
## Supported Components
@ -519,6 +526,7 @@ You might have paired the `Home Assistant Bridge` already. If not, follow the ab
#### `Home Assistant Bridge` doesn't appear in the Home App (for pairing)
This is often setup and network related. Make sure to check the other issues below as well, but things that might work include:
- Check your router configuration
- Try with Wi-Fi **and** LAN
- Change the default [port](#port)

2
source/_integrations/lutron_caseta.markdown
View File

@ -10,7 +10,7 @@ ha_category:
- Fan
- Binary Sensor
ha_release: 0.41
ha_iot_class: Local Polling
ha_iot_class: Local Push
ha_domain: lutron_caseta
ha_codeowners:
- '@swails'

2
source/_integrations/modbus.markdown
View File

@ -149,7 +149,7 @@ modbus:
| Attribute | Description |
| --------- | ----------- |
| hub | Hub name (defaults to 'default' when omitted) |
| unit | Slave address (set to 255 you talk to Modbus via TCP) |
| unit | Slave address (1-255, mostly 255 if you talk to Modbus via TCP) |
| address | Address of the Register (e.g., 138) |
| value | A single value or an array of 16-bit values. Single value will call modbus function code 6. Array will call modbus function code 16. Array might need reverse ordering. E.g., to set 0x0004 you might need to set `[4,0]` |

28
source/_integrations/mycroft.markdown
View File

@ -29,4 +29,30 @@ host:
description: The IP address of your Mycroft instance.
required: true
type: string
{% endconfiguration %}
{% endconfiguration %}
## Using notifications
To use Mycroft for sending notifications, add the following to your `configuration.yaml` file:
```yaml
# Example configuration.yaml entry
notify:
- platform: mycroft
name: mycroft
```
{% configuration %}
name:
description: Frendly name of your Mycroft instance.
required: true
type: string
{% endconfiguration %}
## Examples
Send a mesage to Mycroft by calling `notify.mycroft` service:
```yaml
message: "hey"
```

5
source/_integrations/panasonic_viera.markdown
View File

@ -21,6 +21,8 @@ Once the integration is loaded, with your TV turned on and connected to your loc
If your TV needs to be paired, you will be prompted to type the PIN code that will be displayed on it.
To allow your TV to be turned on or controlled while off, enable `Powered On By Apps` in the TV Settings: **Network > TV Remote App Settings**
## Manual configuration
If you prefer to use YAML to set up your Panasonic Viera TV, you can still do it. It also allows for some extra settings.
@ -95,16 +97,19 @@ script:
### Currently known supported models
- TC-P50ST50
- TC-P55ST50
- TC-P60S60
- TC-P65VT30
- TX-32AS520E
- TX-32DSX609
- TX-40DX700B
- TX-49DX650B
- TX-50DX700B
- TX-55CX700E
- TX-55CX680B
- TX-55EXW584
- TX-55EXW604S
- TX-58DX700B
- TX-65EXW784
- TX-L42ET50
- TX-P42STW50

2
source/_integrations/pi4ioe5v9xxxx.markdown
View File

@ -13,7 +13,7 @@ ha_codeowners:
- '@antonverburg'
---
The `pi4ioe5v9xxxx` integration provides support for the quasi-bidirectional devices PI4IOE5V9570, PI4IOE5V9674, PI4IOE5V9673, PI4IOE5V96224 and PI4IOE5V96248 from digital.com.
The `pi4ioe5v9xxxx` integration provides support for the quasi-bidirectional devices PI4IOE5V9570, PI4IOE5V9674, PI4IOE5V9673, PI4IOE5V96224 and PI4IOE5V96248 from [diodes.com](https://www.diodes.com).
For more details about the pi4ioe5v9xxxx I2C I/O port expander you can find the datasheets here:
- [PI4IOE5V9570](https://www.diodes.com/assets/Datasheets/PI4IOE5V9570.pdf)

15
source/_integrations/python_script.markdown
View File

@ -21,15 +21,15 @@ This integration allows you to write Python scripts that are exposed as services
<div class='note'>
It is not possible to use Python imports with this integration. If you want to do more advanced scripts, you can take a look at [AppDaemon](/docs/ecosystem/appdaemon/)
It is not possible to use Python imports with this integration. If you want to do more advanced scripts, you can take a look at [AppDaemon](https://appdaemon.readthedocs.io/en/latest/)
</div>
## Writing your first script
- Add to `configuration.yaml`: `python_script:`
- Create folder `<config>/python_scripts`
- Create a file `hello_world.py` in the folder and give it this content:
- Add to `configuration.yaml`: `python_script:`
- Create folder `<config>/python_scripts`
- Create a file `hello_world.py` in the folder and give it this content:
```python
name = data.get("name", "world")
@ -37,8 +37,8 @@ logger.info("Hello %s", name)
hass.bus.fire(name, {"wow": "from a Python script!"})
```
- Start Home Assistant
- Call service `python_script.hello_world` with parameters
- Start Home Assistant
- Call service `python_script.hello_world` with parameters
```yaml
name: you
@ -62,6 +62,7 @@ if entity_id is not None:
service_data = {"entity_id": entity_id, "rgb_color": rgb_color, "brightness": 255}
hass.services.call("light", "turn_on", service_data, False)
```
The above `python_script` can be called using the following YAML as an input.
```yaml
@ -78,7 +79,7 @@ You can add descriptions for your Python scripts that will be shown in the Call
```yaml
# services.yaml
turn_on_light:
description: Turn on a light and set its color.
description: Turn on a light and set its color.
fields:
entity_id:
description: The light that will be turned on.

1
source/_integrations/raincloud.markdown
View File

@ -1,7 +1,6 @@
---
title: Melnor RainCloud
description: Instructions on how to integrate your Melnor Raincloud sprinkler system within Home Assistant.
logo: raincloud.jpg
ha_category:
- Irrigation
- Binary Sensor

93
source/_integrations/rejseplanen.markdown
View File

@ -10,31 +10,6 @@ ha_domain: rejseplanen
The `rejseplanen` sensor will provide you with travel details for Danish public transport, using timetable data from [Rejseplanen](https://www.rejseplanen.dk/).
## Setup
The `stop_id` can be obtained through the following steps:
If you know the exact name of the stop you can search the stop_id with the following URL [http://xmlopen.rejseplanen.dk/bin/rest.exe/location?format=json&input=STOP_NAME](http://xmlopen.rejseplanen.dk/bin/rest.exe/location?format=json&input=STOP_NAME) and put in the name of the stop instead of "STOP_NAME" in the end of the URL.
If you don't know the name of the stop follow this guide:
- Go to [https://www.openstreetmap.org](https://www.openstreetmap.org)
- Make a search and fill in the location you want to find for.
- The URL will look like this [https://www.openstreetmap.org/#map=18/56.15756/10.20674](https://www.openstreetmap.org/#map=18/56.15756/10.20674)
- Now insert the coordinates for the location in the URL, in this example it will be: [http://xmlopen.rejseplanen.dk/bin/rest.exe/stopsNearby?coordX=56.15756&coordY=10.20674&](http://xmlopen.rejseplanen.dk/bin/rest.exe/stopsNearby?coordX=56.15756&coordY=10.20674&)
- You will now see the 30 stops closest to your location.
You will see an output like this:
```text
"StopLocation":[{
"name":"Engdalsvej/Århusvej (Favrskov Kom)",
"x":"10078598",
"y":"56243456",
"id":"713000702"
```
Find the name of your stop in the list and the "id" is the one you are looking for to us as value for `stop_id:`.
## Configuration
Add a sensor to your `configuration.yaml` file as shown in the example:
@ -70,13 +45,46 @@ departure_type:
type: [string, list]
{% endconfiguration %}
## stop_id
The `stop_id` can be obtained through the following steps:
- Go to [https://www.openstreetmap.org](https://www.openstreetmap.org)
- Make a search and fill in the location you want to find for.
- The URL will look like this [https://www.openstreetmap.org/#map=18/56.15756/10.20674](https://www.openstreetmap.org/#map=18/56.15756/10.20674)
- Now insert the coordinates for the location in the URL, in this example it will be: [http://xmlopen.rejseplanen.dk/bin/rest.exe/stopsNearby?coordX=56.15756&coordY=10.20674&](http://xmlopen.rejseplanen.dk/bin/rest.exe/stopsNearby?coordX=56.15756&coordY=10.20674&)
- You will now see the 30 stops closest to your location.
You will see an output like this:
```text
"StopLocation":[{
"name":"Engdalsvej/Århusvej (Favrskov Kom)",
"x":"10078598",
"y":"56243456",
"id":"713000702"
```
Find the name of your stop in the list and the "id" is the one you are looking for to us as value for `stop_id:`.
## Direction
If you use the `direction` filter it's important to put correct final destination(s) or else the sensor will not work at all.
The `direction` has to be the final destination(s) for the `Departure type` - ***NOT the stop where you want to get off***.
- Check [https://rejseplanen.dk/](https://rejseplanen.dk/)
- Make a search and use **all variations** for the final destination(s) for the needed `Departure type` in your configuration under `direction`. Make sure you use the exact name for final destination(s).
- Replace YOUR_STOP_ID with the id for your stop and go to [http://xmlopen.rejseplanen.dk/bin/rest.exe/departureBoard?id=YOUR_STOP_ID](http://xmlopen.rejseplanen.dk/bin/rest.exe/departureBoard?id=YOUR_STOP_ID)
- The values under `finalStop` is the ones you need to put under `direction`. Make sure you use the exact name and insert all possible finalstops.
You will see an output like this:
```text
<Departure name="Bus 200" type="BUS" stop="Engdalsvej/Århusvej (Favrskov Kom)" time="10:15" date="06.05.20" id="713000701" line="200" messages="0" finalStop="Bjergegårdsvej/Rylevej (Favrskov Kom)" direction="Hinnerup">
<JourneyDetailRef ref="http://xmlopen.rejseplanen.dk/bin/rest.exe/journeyDetail?ref=248868%2F117643%2F641354%2F237721%2F86%3Fdate%3D06.05.20" />
</Departure>
<Departure name="Bus 200" type="BUS" stop="Engdalsvej/Århusvej (Favrskov Kom)" time="10:25" date="06.05.20" id="713000702" line="200" messages="0" finalStop="Skanderborg Busterminal (Skanderborg Kom)" direction="Skanderborg Busterminal (Skanderborg Kom)">
<JourneyDetailRef ref="http://xmlopen.rejseplanen.dk/bin/rest.exe/journeyDetail?ref=512592%2F205637%2F693742%2F176008%2F86%3Fdate%3D06.05.20" />
</Departure>
```
A working example on how to use this sensor with direction:
@ -84,25 +92,30 @@ A working example on how to use this sensor with direction:
# Example configuration.yaml entry with the correct use of direction.
sensor:
- platform: rejseplanen
stop_id: '008600615'
stop_id: '713000702'
direction:
- 'CPH Lufthavn'
- 'Helsingør St.'
- 'Bjergegårdsvej/Rylevej (Favrskov Kom)'
- 'Skanderborg Busterminal (Skanderborg Kom)'
```
A NOT WORKING example use this sensor with direction:
## Route
```yaml
# Example configuration.yaml entry with the correct use of direction.
sensor:
- platform: rejseplanen
stop_id: '008600615'
direction:
- 'København H'
If you use the `route` filter it's important to put correct route name(s) or else the sensor will not work at all.
- Replace YOUR_STOP_ID with the id for your stop and go to [http://xmlopen.rejseplanen.dk/bin/rest.exe/departureBoard?id=YOUR_STOP_ID](http://xmlopen.rejseplanen.dk/bin/rest.exe/departureBoard?id=YOUR_STOP_ID)
- The values under `Departure name` is the ones you need to put under `route`. Make sure you use the exact name.
You will see an output like this:
```text
<Departure name="Bus 1A" type="BUS" stop="Elmegade (Nørrebrogade)" time="10:19" date="06.05.20" id="45739" line="1A" messages="0" rtTime="10:21" rtDate="06.05.20" finalStop="Avedøre St." direction="Avedøre St.">
<JourneyDetailRef ref="http://xmlopen.rejseplanen.dk/bin/rest.exe/journeyDetail?ref=138234%2F58362%2F751742%2F329795%2F86%3Fdate%3D06.05.20" />
</Departure>
<Departure name="Bus 5C" type="BUS" stop="Elmegade (Nørrebrogade)" time="10:22" date="06.05.20" id="45739" line="5C" messages="0" rtTime="10:23" rtDate="06.05.20" finalStop="Husum Torv, Sløjfen (Sløjfen)" direction="Husum Torv">
<JourneyDetailRef ref="http://xmlopen.rejseplanen.dk/bin/rest.exe/journeyDetail?ref=899547%2F321443%2F654384%2F27343%2F86%3Fdate%3D06.05.20" />
</Departure>
```
It fails because the final destination for the train from the departure station is NOT 'københavn H', but 'CPH Lufthavn' and 'Helsingør St.'.
## Examples
A more extensive example on how to use this sensor:

7
source/_integrations/roomba.markdown
View File

@ -21,7 +21,7 @@ The `roomba` integration allows you to control your [iRobot Roomba](https://www.
</p>
<div class='note'>
This platform has been tested and is confirmed to be working with the iRobot Roomba s9+, Roomba 980, Roomba 890, and Braava jet m6 models, but should also work fine with any Wi-Fi enabled Roomba or Braava like the 690 or the 960.
This platform has been tested and is confirmed to be working with the iRobot Roomba s9+, Roomba 980, Roomba 960, Roomba 890, and Braava jet m6 models, but should also work fine with any Wi-Fi enabled Roomba or Braava like the 690.
</div>
## Configuration
@ -51,11 +51,6 @@ password:
description: The password for your device.
required: true
type: string
certificate:
description: "**(Deprecated)** Path to your certificate store."
required: false
type: string
default: /etc/ssl/certs/ca-certificates.crt
continuous:
description: Whether to operate in continuous mode.
required: false

2
source/_integrations/smtp.markdown
View File

@ -181,9 +181,7 @@ The optional `html` field makes a custom text/HTML multi-part message, allowing
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.5/js/bootstrap.min.js"></script>
</html>
```
Obviously, this kind of complex html email reporting is done much more conveniently using Jinja2 templating from an [AppDaemon app](/docs/ecosystem/appdaemon/tutorial/), for example.
This platform is fragile and not able to catch all exceptions in a smart way because of the large number of possible configuration combinations.

22
source/_integrations/synology_dsm.markdown
View File

@ -12,15 +12,15 @@ ha_codeowners:
ha_config_flow: true
---
The `synology_dsm` sensor platform allows getting various statistics from your [Synology NAS](https://www.synology.com).
The `synology_dsm` sensor platform provides access to various statistics from your [Synology NAS](https://www.synology.com).
## Configuration
There are two ways to integrate Synology DSM in Home Assistant.
There are two ways to integrate your Synology DSM into Home Assistant.
### Via the frontend
Menu: *Configuration* -> *Integrations*. Search for "Synology DSM", fill the configuration form, click submit.
Menu: *Configuration* -> *Integrations*. Search for "Synology DSM", fill in the configuration form with your username and password, and then click **Submit**.
### Via the configuration file
@ -29,14 +29,14 @@ Add the following section to your `configuration.yaml` file:
```yaml
# Example configuration.yaml entry
synology_dsm:
- host: IP_ADDRESS_OR_DNS_OF_SYNOLOGY_NAS
- host: IP_ADDRESS_OR_HOSTNAME_OF_SYNOLOGY_NAS
username: YOUR_USERNAME
password: YOUR_PASSWORD
```
{% configuration %}
host:
description: The IP address or DNS of the Synology NAS to monitor.
description: The IP address or DNS hostname of the Synology NAS to monitor.
required: true
type: string
port:
@ -50,7 +50,7 @@ ssl:
default: true
type: boolean
username:
description: An user to connect to the Synology NAS (a separate account is advised, see the (Separate User Configuration)[#separate-user-configuration] section below for details).
description: The account username to connect to the Synology NAS. Using a separate account is advised, see the [Separate User Configuration](#separate-user-configuration) section below for details.
required: true
type: string
password:
@ -58,11 +58,11 @@ password:
required: true
type: string
volumes:
description: "Array of volumes to monitor. Defaults to all volumes. Replace any spaces in the volume name with underscores, e.g., `volume 1` with `volume_1`."
description: "Array of volumes to monitor. Defaults to all volumes. Replace any spaces in the volume name with underscores. For example, replace `volume 1` with `volume_1`."
required: false
type: list
disks:
description: "Array of disks to monitor. Defaults to all disks. Use only disk names like `sda`, `sdb`, etc."
description: "Array of disks to monitor. Defaults to all disks. Use only disk names like `sda`, `sdb`, and so on."
required: false
type: list
{% endconfiguration %}
@ -82,15 +82,15 @@ When creating the user, it is possible to deny access to all locations and appli
<div class='note warning'>
Using two-factor authentication is not supported. Please use a strong, randomly generated password.
The Home Assistant integration doesn't support two-factor authentication for Synology DSM accounts. Use a strong, randomly generated password to improve security.
</div>
## Created sensors
Sensors are :
- `cpu_other_load`: Displays unspecified load in percentage.
Sensors are:
- `cpu_other_load`: Displays unspecified (that is, not user or system) load in percentage.
- `cpu_user_load`: Displays user load in percentage.
- `cpu_system_load`: Displays system load in percentage.
- `cpu_total_load`: Displays combined load in percentage.

108
source/_integrations/telegram_bot.markdown
View File

@ -275,6 +275,7 @@ action:
An example to show the use of event_data in action:
{% raw %}
```yaml
- alias: 'Kitchen Telegram Speak'
trigger:
@ -288,6 +289,7 @@ An example to show the use of event_data in action:
message: >
Message from {{ trigger.event.data["from_first"] }}. {% for state in trigger.event.data["args"] %} {{ state }} {% endfor %}
```
{% endraw %}
### Sample automations with callback queries and inline keyboards
@ -301,6 +303,7 @@ A quick example to show some of the callback capabilities of inline keyboards wi
Text repeater:
{% raw %}
```yaml
- alias: 'Telegram bot that repeats text'
trigger:
@ -317,11 +320,13 @@ Text repeater:
- "Edit message:/edit_msg, Don't:/do_nothing"
- "Remove this button:/remove button"
```
{% endraw %}
Message editor:
{% raw %}
```yaml
- alias: 'Telegram bot that edits the last sent message'
trigger:
@ -348,11 +353,13 @@ Message editor:
Message id: {{ trigger.event.data.message.message_id }}.
Data: {{ trigger.event.data.data }}
```
{% endraw %}
Keyboard editor:
{% raw %}
```yaml
- alias: 'Telegram bot that edits the keyboard'
trigger:
@ -372,11 +379,13 @@ Keyboard editor:
inline_keyboard:
- "Edit message:/edit_msg, Don't:/do_nothing"
```
{% endraw %}
Only acknowledges the 'NO' answer:
{% raw %}
```yaml
- alias: 'Telegram bot that simply acknowledges'
trigger:
@ -390,11 +399,13 @@ Only acknowledges the 'NO' answer:
callback_query_id: '{{ trigger.event.data.id }}'
message: 'OK, you said no!'
```
{% endraw %}
Telegram callbacks also support arguments and commands the same way as normal messages.
{% raw %}
```yaml
- alias: 'Telegram bot repeats arguments on callback query'
trigger:
@ -409,102 +420,7 @@ Telegram callbacks also support arguments and commands the same way as normal me
callback_query_id: '{{ trigger.event.data.id }}'
message: 'I repeat: {{trigger.event.data["args"]}}'
```
{% endraw %}
In this case, having a callback with `/repeat 1 2 3` with pop a notification saying `I repeat: [1, 2, 3]`
For a more complex usage of the `telegram_bot` capabilities, using [AppDaemon](/docs/ecosystem/appdaemon/tutorial/) is advised.
This is how the previous 4 automations would be through a simple AppDaemon app:
```python
import appdaemon.plugins.hass.hassapi as hass
class TelegramBotEventListener(hass.Hass):
"""Event listener for Telegram bot events."""
def initialize(self):
"""Listen to Telegram Bot events of interest."""
self.listen_event(self.receive_telegram_text, "telegram_text")
self.listen_event(self.receive_telegram_callback, "telegram_callback")
def receive_telegram_text(self, event_id, payload_event, *args):
"""Text repeater."""
assert event_id == "telegram_text"
user_id = payload_event["user_id"]
msg = "You said: ``` %s ```" % payload_event["text"]
keyboard = [
[("Edit message", "/edit_msg"), ("Don't", "/do_nothing")],
[("Remove this button", "/remove button")],
]
self.call_service(
"telegram_bot/send_message",
title="*Dumb automation*",
target=user_id,
message=msg,
disable_notification=True,
inline_keyboard=keyboard,
)
def receive_telegram_callback(self, event_id, payload_event, *args):
"""Event listener for Telegram callback queries."""
assert event_id == "telegram_callback"
data_callback = payload_event["data"]
callback_id = payload_event["id"]
chat_id = payload_event["chat_id"]
# keyboard = ["Edit message:/edit_msg, Don't:/do_nothing",
# "Remove this button:/remove button"]
keyboard = [
[("Edit message", "/edit_msg"), ("Don't", "/do_nothing")],
[("Remove this button", "/remove button")],
]
if data_callback == "/edit_msg": # Message editor:
# Answer callback query
self.call_service(
"telegram_bot/answer_callback_query",
message="Editing the message!",
callback_query_id=callback_id,
show_alert=True,
)
# Edit the message origin of the callback query
msg_id = payload_event["message"]["message_id"]
user = payload_event["from_first"]
title = "*Message edit*"
msg = "Callback received from %s. Message id: %s. Data: ``` %s ```"
self.call_service(
"telegram_bot/edit_message",
chat_id=chat_id,
message_id=msg_id,
title=title,
message=msg % (user, msg_id, data_callback),
inline_keyboard=keyboard,
)
elif data_callback == "/remove button": # Keyboard editor:
# Answer callback query
self.call_service(
"telegram_bot/answer_callback_query",
message="Callback received for editing the " "inline keyboard!",
callback_query_id=callback_id,
)
# Edit the keyboard
new_keyboard = keyboard[:1]
self.call_service(
"telegram_bot/edit_replymarkup",
chat_id=chat_id,
message_id="last",
inline_keyboard=new_keyboard,
)
elif data_callback == "/do_nothing": # Only Answer to callback query
self.call_service(
"telegram_bot/answer_callback_query",
message="OK, you said no!",
callback_query_id=callback_id,
)
```

14
source/_integrations/webostv.markdown
View File

@ -211,6 +211,20 @@ script:
command: "media.controls/rewind"
```
## Consecutive volume steps delay
In the case where a sound output that only supports relative volume stepping is used, the receiving speaker may have issues dealing with several volume step commands arriving at the same time. Therefore it's possible to configure a time delay so that at least the configured amount of time has elapsed between two consecutive volume steps before the second one is fired. The configured value is in milliseconds.
```yaml
# Example
webostv:
host: 192.168.0.10
name: Living Room TV
consecutive_volume_steps_delay: 300
media_player:
```
## Notifications
The `webostv` notify platform allows you to send notifications to a LG webOS Smart TV.

4
source/_integrations/yandextts.markdown
View File

@ -10,9 +10,7 @@ ha_domain: yandextts
The `yandextts` text-to-speech platform uses [Yandex SpeechKit](https://tech.yandex.com/speechkit/) Text-to-Speech engine to read a text with natural sounding voices.
<div class='note warning'>
This integration is working only with old API keys.
For the new API keys this intergration is not working. There is a custom component that is working with new API keys [Yandex-tts-speechkit-FIX](https://github.com/tayanov/Yandex-tts-speechkit-FIX).
This integration is working only with old API keys. For the new API keys, this integration cannot be used.
</div>
## Configuration

44
source/_posts/2020-04-29-release-109.markdown
View File

@ -530,6 +530,50 @@ Pushetta has been offline since September 2019 and the Yahoo Weather API has bee
[uvc docs]: /integrations/uvc/
[websocket_api docs]: /integrations/websocket_api/
## Release 0.109.5 - May 6
- Add retry on empty modbus messages for serial protocol ([@janiversen] - [#34678]) ([modbus docs])
- Change Modbus switch to use verify_register when defined ([@janiversen] - [#34679]) ([modbus docs])
- Catch samsungtv timeout exception ([@escoand] - [#35205]) ([samsungtv docs])
- Broader Notion exception handling ([@bachya] - [#35265]) ([notion docs])
- UniFi - Support SSID filter of SSIDs from access points with extra configuration ([@Kane610] - [#35295]) ([unifi docs])
- Fix SMS doing I/O in event loop ([@balloob] - [#35313]) ([sms docs])
[#34678]: https://github.com/home-assistant/core/pull/34678
[#34679]: https://github.com/home-assistant/core/pull/34679
[#35205]: https://github.com/home-assistant/core/pull/35205
[#35265]: https://github.com/home-assistant/core/pull/35265
[#35295]: https://github.com/home-assistant/core/pull/35295
[#35313]: https://github.com/home-assistant/core/pull/35313
[@Kane610]: https://github.com/Kane610
[@bachya]: https://github.com/bachya
[@balloob]: https://github.com/balloob
[@escoand]: https://github.com/escoand
[@janiversen]: https://github.com/janiversen
[modbus docs]: /integrations/modbus/
[notion docs]: /integrations/notion/
[samsungtv docs]: /integrations/samsungtv/
[sms docs]: /integrations/sms/
[unifi docs]: /integrations/unifi/
## Release 0.109.6 - May 7
- Fix roomba 980 position report ([@shenxn] - [#35316]) ([roomba docs])
- Update pymyq to 2.0.2 ([@bdraco] - [#35330]) ([myq docs])
- Fix Synology DSM discovery can't be ignored ([@Quentame] - [#35331]) ([synology_dsm docs])
- Remove panasonic_viera from legacy discovery (@joogps - #34909)
- Fix Islamic prayer sensor timestamp format (@engrbm87 - #35243)
[#35316]: https://github.com/home-assistant/core/pull/35316
[#35330]: https://github.com/home-assistant/core/pull/35330
[#35331]: https://github.com/home-assistant/core/pull/35331
[@Quentame]: https://github.com/Quentame
[@bdraco]: https://github.com/bdraco
[@shenxn]: https://github.com/shenxn
[myq docs]: /integrations/myq/
[roomba docs]: /integrations/roomba/
[synology_dsm docs]: /integrations/synology_dsm/
## All changes
<details>

6
source/docs/index.markdown
View File

@ -36,11 +36,11 @@ The documentation covers beginner to advanced topics around the installation, se
</div>
<div class='title'>Lovelace user interface</div>
</a>
<a class='option-card' href='/docs/ecosystem/ios/'>
<a class='option-card' href='https://companion.home-assistant.io/'>
<div class='img-container'>
<img src='https://brands.home-assistant.io/ios/icon.png' />
<img src='https://brands.home-assistant.io/mobile_app/icon.png' />
</div>
<div class='title'>iOS</div>
<div class='title'>Android and iOS</div>
</a>
</div>

95
source/hassio/installation.markdown
View File

@ -104,94 +104,6 @@ If you would like to test next release before anyone else, you can install the b
3. Select _System_ tab from the _Supervisor_ menu, then select _Join Beta Channel_ under _Supervisor_, then select _Reload_.
4. Select _Dashboard_ tab from the _Supervisor_ menu, and then select _Update_.
## Alternative: install Home Assistant Supervised on a generic Linux host
You can also install Home Assistant on a Linux operating system of choice, called Home Assistant Supervised.
Home Assistant Supervised, will still give you access to most features Home Assistant has to offer, including add-ons.
<div class='note warning'>
The Supervisord system is designed to provide a full-featured environment that is comparable with Kubernetes, which is also a bad idea to run it by the side of another orchestrator on the same Host. The Supervisor is also not caring for other software they run on your Host, and it can affect things bad on both sides. You also need to know that the Home Assistant OS runs with less overhead on your Proxmox or other Hypervisor as if you install first Debian and Ubuntu. In most cases, it's not the best choice to run the Supervisord on top of a Linux, if you not 100% sure what you do. **It is not just a container inside Docker!**
</div>
### Supported systems and limitations
While Home Assistant Supervised can be run on practically any Linux systems,
the Home Assistant project limits support for this installation method.
Only the use of Debian or Ubuntu is supported. Other Linux-based system may work
but is not part of our testing and thus not supported.
Furthermore, if you choose to run Home Assistant Supervised, the operating
system of your choosing (including Debian/Ubuntu) is **your** responsibility.
Both in terms of systems upgrade and system configuration.
Customizations to your custom operating system may interfere with Home Assistant.
For that reason, please be sure you have to knowledge to manage, configure and
maintain the operating system of your choosing.
When in doubt, we highly recommend using the regular installation of Home
Assistant as provided above. In that case, Home Assistant will manage and update
the Home Assistant Operating System for you.
### Preparation
To prepare your machine for the Home Assistant installation, run the following commands:
If you run Ubuntu, first run this command:
```bash
sudo add-apt-repository universe
```
Next run the following commands (for both Debian and Ubuntu):
```bash
sudo -i
apt-get update
apt-get install -y software-properties-common apparmor-utils apt-transport-https avahi-daemon ca-certificates curl dbus jq network-manager socat
systemctl disable ModemManager
systemctl stop ModemManager
curl -fsSL get.docker.com | sh
```
### Installation of Home Assistant Supervised
The following script will then install Home Assistant on a variety of operating systems and machine types.
```bash
curl -sL "https://raw.githubusercontent.com/home-assistant/supervised-installer/master/installer.sh" | bash -s
```
Some installation types require flags to identify the computer type, for example, when using a Raspberry Pi 4, the flag `-- -m raspberrypi4` is required. The install script would then look like this:
```bash
curl -sL "https://raw.githubusercontent.com/home-assistant/supervised-installer/master/installer.sh" | bash -s -- -m raspberrypi4
```
#### Other machine types
- `intel-nuc`
- `raspberrypi`
- `raspberrypi2`
- `raspberrypi3`
- `raspberrypi3-64`
- `raspberrypi4`
- `raspberrypi4-64`
- `odroid-c2`
- `odroid-n2`
- `odroid-xu`
- `tinker`
- `qemuarm`
- `qemuarm-64`
- `qemux86`
- `qemux86-64`
See the [installer](https://github.com/home-assistant/supervised-installer) GitHub page for an up-to-date listing of supported machine types.
If you can not find your machine type in the list, you should pick the `qemu` release. i.e., `qemux86-64` for a normal 64-bit Linux distribution, or `qemuarm-64` for most modern ARM-based target like Raspberry Pi clones, or TV boxes.
[balenaEtcher]: https://www.balena.io/etcher
[hassos-network]: https://github.com/home-assistant/operating-system/blob/dev/Documentation/network.md
@ -204,15 +116,14 @@ If you can not find your machine type in the list, you should pick the `qemu` re
[pi4-64]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_rpi4-64-3.13.img.gz
[tinker]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_tinker-3.13.img.gz
[odroid-c2]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_odroid-c2-3.13.img.gz
[odroid-n2]: https://github.com/home-assistant/operating-system/releases/download/4.5/hassos_odroid-n2-4.5.img.gz
[odroid-n2]: https://github.com/home-assistant/operating-system/releases/download/4.6/hassos_odroid-n2-4.6.img.gz
[odroid-xu4]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_odroid-xu4-3.13.img.gz
[intel-nuc]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_intel-nuc-3.13.img.gz
[vmdk]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_ova-3.13.vmdk.gz
[vhdx]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_ova-3.13.vhdx.gz
[vdi]: https://github.com/home-assistant/operating-system/releases/download/3.13/hassos_ova-3.13.vdi.gz
[qcow2]: https://github.com/home-assistant/operating-system/releases/download/4.5/hassos_ova-4.5.vdi.gz
[Virtual Appliance]: https://github.com/home-assistant/operating-system/releases/download/4.5/hassos_ova-4.5.ova
[linux]: https://github.com/home-assistant/supervised-installer
[qcow2]: https://github.com/home-assistant/operating-system/releases/download/4.6/hassos_ova-4.6.qcow2.gz
[Virtual Appliance]: https://github.com/home-assistant/operating-system/releases/download/4.6/hassos_ova-4.6.ova
[local]: http://homeassistant.local:8123
[samba]: /addons/samba/
[ssh]: /addons/ssh/

BIN
source/images/architecture/home_automation_landscape.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

BIN
source/images/blog/2015-09-glances/sensors.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.4 KiB

After

Width:  |  Height:  |  Size: 4.3 KiB

BIN
source/images/blog/2015-09-glances/web-glances.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 29 KiB

After

Width:  |  Height:  |  Size: 29 KiB

BIN
source/images/blog/2015-09-ifttt/og_facebook.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.0 KiB

After

Width:  |  Height:  |  Size: 7.9 KiB

BIN
source/images/blog/2015-09-ifttt/recipe-do.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.0 KiB

After

Width:  |  Height:  |  Size: 3.0 KiB

BIN
source/images/blog/2015-09-ifttt/recipe-geo.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.7 KiB

After

Width:  |  Height:  |  Size: 2.7 KiB

BIN
source/images/blog/2015-09-ifttt/recipe-github.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.3 KiB

After

Width:  |  Height:  |  Size: 6.3 KiB

BIN
source/images/blog/2015-09-ifttt/recipe-twitter.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.9 KiB

After

Width:  |  Height:  |  Size: 3.8 KiB

BIN
source/images/blog/2015-09-ifttt/recipe-weather.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 7.0 KiB

After

Width:  |  Height:  |  Size: 6.9 KiB

BIN
source/images/blog/2015-09-mqtt/arduino-shield.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 109 KiB

After

Width:  |  Height:  |  Size: 109 KiB

BIN
source/images/blog/2015-09-mqtt/arduino.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.5 KiB

After

Width:  |  Height:  |  Size: 3.5 KiB

BIN
source/images/blog/2015-09-mqtt/lottery.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.6 KiB

After

Width:  |  Height:  |  Size: 2.6 KiB

BIN
source/images/blog/2015-09-mqtt/mood.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.7 KiB

After

Width:  |  Height:  |  Size: 1.7 KiB

BIN
source/images/blog/2015-10-esp8266-temp/ha-sensor.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.6 KiB

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
source/images/blog/2015-11-survey/alarm-cameras.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.6 KiB

After

Width:  |  Height:  |  Size: 2.6 KiB

BIN
source/images/blog/2015-11-survey/components.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 7.2 KiB

After

Width:  |  Height:  |  Size: 7.1 KiB

BIN
source/images/blog/2015-11-survey/lights.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.2 KiB

After

Width:  |  Height:  |  Size: 4.1 KiB

BIN
source/images/blog/2015-11-survey/notifications.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.2 KiB

After

Width:  |  Height:  |  Size: 4.2 KiB

BIN
source/images/blog/2015-11-survey/os.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.4 KiB

After

Width:  |  Height:  |  Size: 4.3 KiB

BIN
source/images/blog/2015-11-survey/platforms.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.5 KiB

After

Width:  |  Height:  |  Size: 2.4 KiB

BIN
source/images/blog/2015-11-survey/players.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.5 KiB

After

Width:  |  Height:  |  Size: 3.5 KiB

BIN
source/images/blog/2015-11-survey/releases.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.6 KiB

After

Width:  |  Height:  |  Size: 2.6 KiB

BIN
source/images/blog/2015-11-survey/sensors.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 11 KiB

BIN
source/images/blog/2015-11-survey/switches.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.6 KiB

After

Width:  |  Height:  |  Size: 6.4 KiB

BIN
source/images/blog/2015-11-survey/thermostats.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.9 KiB

After

Width:  |  Height:  |  Size: 1.9 KiB

BIN
source/images/blog/2015-11-survey/trackers.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 5.8 KiB

After

Width:  |  Height:  |  Size: 5.7 KiB

BIN
source/images/blog/2015-12-influxdb/grafana-graph.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 40 KiB

BIN
source/images/blog/2015-12-influxdb/grafana-settings.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.3 KiB

After

Width:  |  Height:  |  Size: 9.2 KiB

BIN
source/images/blog/2015-12-influxdb/influxdb-frontend.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

BIN
source/images/blog/2015-12-lets-encrypt/letsencrypt-secured-fb.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

BIN
source/images/blog/2015-12-philips-hue-3rd-party/mirror.png vendored
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 59 KiB

BIN
source/images/blog/2015-12-release-09/facebook-09.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.0 KiB

After

Width:  |  Height:  |  Size: 8.0 KiB

BIN
source/images/blog/2015-12-release-10/alexa-fb.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 45 KiB

After

Width:  |  Height:  |  Size: 45 KiB

BIN
source/images/blog/2015-12-tasker/screenshot-1.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

BIN
source/images/blog/2015-12-tasker/screenshot-3.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 17 KiB

BIN
source/images/blog/2015-12-tasker/tasker-logo.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

BIN
source/images/blog/2016-01-release-12/social.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.3 KiB

After

Width:  |  Height:  |  Size: 8.3 KiB

BIN
source/images/blog/2016-01-release-12/views.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.6 KiB

After

Width:  |  Height:  |  Size: 6.5 KiB

BIN
source/images/blog/2016-02-classifying-internet-of-things/social.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

BIN
source/images/blog/2016-02-release-13/input_select__input_boolean__weblink.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.5 KiB

BIN
source/images/blog/2016-02-release-13/social-img.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

BIN
source/images/blog/2016-02-release-14/social.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 38 KiB

BIN
source/images/blog/2016-02-smartthings/social.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

BIN
source/images/blog/2016-02-smartthings/splash.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

BIN
source/images/blog/2016-02-snapcast/diagram.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.6 KiB

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
source/images/blog/2016-04-display/ha-display.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

BIN
source/images/blog/2016-04-ibeacons/owntracks_beacon_setup.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 26 KiB

BIN
source/images/blog/2016-04-ibeacons/owntracks_red_beacon.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

BIN
source/images/blog/2016-04-release-18/social.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 82 KiB

After

Width:  |  Height:  |  Size: 82 KiB

BIN
source/images/blog/2016-05-ibeacons/keys_device.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.2 KiB

After

Width:  |  Height:  |  Size: 3.2 KiB

BIN
source/images/blog/2016-05-openiot/preview-video.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 37 KiB

After

Width:  |  Height:  |  Size: 37 KiB

BIN
source/images/blog/2016-05-video-configuring-home-assistant/preview-video.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 46 KiB

BIN
source/images/blog/2016-06-community-highlights/video_preview.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 131 KiB

After

Width:  |  Height:  |  Size: 130 KiB

BIN
source/images/blog/2016-07-data-exploration/graph.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

Some files were not shown because too many files have changed in this diff Show More