diff --git a/.gitpod.yml b/.gitpod.yml
deleted file mode 100644
index 6a0df4ab419..00000000000
--- a/.gitpod.yml
+++ /dev/null
@@ -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
diff --git a/.slugignore b/.slugignore
deleted file mode 100644
index 0a41d01373a..00000000000
--- a/.slugignore
+++ /dev/null
@@ -1,3 +0,0 @@
-plugins
-sass
-source
diff --git a/.theia/tasks.json b/.theia/tasks.json
deleted file mode 100644
index fa5f725110c..00000000000
--- a/.theia/tasks.json
+++ /dev/null
@@ -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}"
- }
- }
- ]
-}
\ No newline at end of file
diff --git a/Gemfile b/Gemfile
index 8de1d420268..39721347d46 100644
--- a/Gemfile
+++ b/Gemfile
@@ -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'
diff --git a/Gemfile.lock b/Gemfile.lock
index 675392f13df..568f7e4d472 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -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)
diff --git a/_config.yml b/_config.yml
index 1ae1d2ad2bb..f4d63b4680e 100644
--- a/_config.yml
+++ b/_config.yml
@@ -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.
diff --git a/source/_docs/autostart/systemd.markdown b/source/_docs/autostart/systemd.markdown
index 270fd374e70..9d7eeabc4de 100644
--- a/source/_docs/autostart/systemd.markdown
+++ b/source/_docs/autostart/systemd.markdown
@@ -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]
diff --git a/source/_docs/ecosystem/appdaemon.markdown b/source/_docs/ecosystem/appdaemon.markdown
deleted file mode 100644
index e9b7263cc45..00000000000
--- a/source/_docs/ecosystem/appdaemon.markdown
+++ /dev/null
@@ -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/).
diff --git a/source/_docs/ecosystem/appdaemon/api.markdown b/source/_docs/ecosystem/appdaemon/api.markdown
deleted file mode 100644
index f3dbef57289..00000000000
--- a/source/_docs/ecosystem/appdaemon/api.markdown
+++ /dev/null
@@ -1,2133 +0,0 @@
----
-title: "AppDaemon API Reference"
-description: "AppDaemon API Reference"
-redirect_from: /ecosystem/appdaemon/api/
----
-
-## Anatomy of an App
-
-Automations in AppDaemon are performed by creating a piece of code (essentially a Python Class) and then instantiating it as an Object one or more times by configuring it as an App in the configuration file. The App is given a chance to register itself for whatever events it wants to subscribe to, and AppDaemon will then make calls back into the Object's code when those events occur, allowing the App to respond to the event with some kind of action.
-
-The first step is to create a unique file within the apps directory (as defined in the `[AppDaemon]` section of configuration file). This file is in fact a Python module, and is expected to contain one or more classes derived from the supplied `AppDaemon` class, imported from the supplied `homeassistant.appapi` module. The start of an app might look like this:
-
-```python
-import homeassistant.appapi as appapi
-
-
-class MotionLights(appapi.AppDaemon):
- """Motion lights implementation."""
-```
-
-When configured as an app in the configuration file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to its `initialize()` function - this function must appear as part of every app:
-
-```python
- def initialize(self):
- """Perform initialization."""
-```
-
-The initialize function allows the app to register any callbacks it might need for responding to state changes, and also any setup activities. When the `initialize()` function returns, the App will be dormant until any of its callbacks are activated.
-
-There are several circumstances under which `initialize()` might be called:
-
-- Initial start of AppDaemon
-- Following a change to the Class code
-- Following a change to the module parameters
-- Following initial configuration of an app
-- Following a change in the status of Daylight Savings Time
-- Following a restart of Home Assistant
-
-In every case, the App is responsible for recreating any state it might need as if it were the first time it was ever started. If `initialize()` is called, the app can safely assume that it is either being loaded for the first time, or that all callbacks and timers have been canceled. In either case, the APP will need to recreate them. Depending upon the application it may be desirable for the App to establish state such as whether or not a particular light is on, within the `initialize()` function to ensure that everything is as expected or to make immediate remedial action (e.g., turn off a light that might have been left on by mistake when the app was restarted).
-
-After the `initialize()` function is in place, the rest of the app consists of functions that are called by the various callback mechanisms, and any additional functions the user wants to add as part of the program logic. Apps are able to subscribe to 2 main classes of events:
-
-- Scheduled Events
-- State Change Events
-
-These, along with their various subscription calls and helper functions, will be described in detail in later sections.
-
-To wrap up this section, here is a complete functioning App (with comments):
-
-```python
-import homeassistant.appapi as appapi
-import datetime
-
-# Declare Class
-class NightLight(appapi.AppDaemon):
- # initialize() function which will be called at startup and reload
- def initialize(self):
- # Create a time object for 7pm
- time = datetime.time(19, 00, 0)
- # Schedule a daily callback that will call run_daily() at 7pm every night
- self.run_daily(self.run_daily_callback, time)
-
- # Our callback function will be called by the scheduler every day at 7pm
- def run_daily_callback(self, kwargs):
- # Call to Home Assistant to turn the porch light on
- self.turn_on("light.porch")
-```
-
-To summarize - an App's lifecycle consists of being initialized, which allows it to set one or more state and/or schedule callbacks. When those callbacks are activated, the App will typically use one of the Service Calling calls to effect some change to the devices of the system and then wait for the next relevant state change. That's all there is to it!
-
-## About the API
-
-The implementation of the API is located in the AppDaemon class that Apps are derived from. The code for the functions is therefore available to the App simply by invoking the name of the function from the object namespace using the `self` keyword, as in the above examples. `self.turn_on()` for example is just a method defined in the parent class and made available to the child. This design decision was made to simplify some of the implementation and hide passing of unnecessary variables during the API invocation.
-
-## Configuration of Apps
-Apps are configured by specifying new sections in the configuration file. `[AppDaemon]` is a reserved section, for configuration of AppDaemon itself. The name of the section is the name the App is referred to within the system in log files etc. and must be unique.
-
-To configure a new App you need a minimum of two directives:
-
-- `module` - the name of the module (without the `.py`) that contains the class to be used for this App
-- `class` - the name of the class as defined within the module for the APPs code
-
-Although the section/App name must be unique, it is possible to re-use a class as many times as you want, and conversely to put as many classes in a module as you want. A sample definition for a new App might look as follows:
-
-```ini
-[newapp]
-module = new
-class = NewApp
-```
-
-When AppDaemon sees the following configuration it will expect to find a class called `NewApp` defined in a module called `new.py` in the apps subdirectory. Apps can be placed at the root of the Apps directory or within a subdirectory, an arbitrary depth down - wherever the App is, as long as it is in some subdirectory of the Apps dir, or in the Apps dir itself, AppDaemon will find it. There is no need to include information about the path, just the name of the file itself (without the `.py`) is sufficient. If names in the subdirectories overlap, AppDir will pick one of them but the exact choice it will make is undefined.
-
-When starting the system for the first time or when reloading an App or Module, the system will log the fact in its main log. It is often the case that there is a problem with the class, maybe a syntax error or some other problem. If that is the case, details will be output to the error log allowing the user to remedy the problem and reload.
-
-## Steps to writing an App
-
-1. Create the code in a new or shared module by deriving a class from AppDaemon, add required callbacks and code
-2. Add the App to the configuration file
-3. There is no number 3
-
-## Reloading Modules and Classes
-
-Reloading of modules is automatic. When the system spots a change in a module, it will automatically reload and recompile the module. It will also figure out which Apps were using that Module and restart them, causing all of their existing callbacks to be cleared, and their `initialize()` function to be called.
-
-The same is true if changes are made to an App's configuration - changing the class, or arguments (see later) will cause that app to be reloaded in the same way. The system is also capable of detecting if a new app has been added, or if one has been removed, and it will act appropriately, starting the new app immediately and removing all callbacks for the removed app.
-
-The suggested order for creating a new App is to add the module code first and work until it compiles cleanly, and only then add an entry in the configuration file to actually run it. A good workflow is to continuously monitor the error file (using `tail -f` on Linux for instance) to ensure that errors are seen and can be remedied.
-
-## Passing Arguments to Apps
-
-There wouldn't be much point in being able to run multiple versions of an App if there wasn't some way to instruct them to do something different. For this reason it is possible to pass any required arguments to an App, which are then made available to the object at runtime. The arguments themselves can be called anything (apart from `module` or `class`) and are simply added into the section after the 2 mandatory directives like so:
-
-```ini
-[MyApp]
-module = myapp
-class = MyApp
-param1 = spam
-param2 = eggs
-```
-
-Within the Apps code, the 2 parameters (as well as the module and class) are available as a dictionary called `args`, and accessed as follows:
-
-```python
-param1 = self.args["param1"]
-param2 = self.args["param2"]
-```
-
-A use case for this might be an App that detects motion and turns on a light. If you have 3 places you want to run this, rather than hardcoding this into 3 separate Apps, you need only code a single app and instantiate it 3 times with different arguments. It might look something like this:
-
-```ini
-[downstairs_motion_light]
-module = motion_light
-class = MotionLight
-sensor = binary_sensor.downstairs_hall
-light = light.downstairs_hall
-[upstairs_motion_light]
-module = motion_light
-class = MotionLight
-sensor = binary_sensor.upstairs_hall
-light = light.upstairs_hall
-[garage_motion_light]
-module = motion_light
-class = MotionLight
-sensor = binary_sensor.garage
-light = light.garage
-```
-
-## Callback Constraints
-
-Callback constraints are a feature of AppDaemon that removes the need for repetition of some common coding checks. Many Apps will wish to process their callbacks only when certain conditions are met, e.g., someone is home, and it's after sunset. These kinds of conditions crop up a lot, and use of callback constraints can significantly simplify the logic required within callbacks.
-
-Put simply, callback constraints are one or more conditions on callback execution that can be applied to an individual App. An App's callbacks will only be executed if all of the constraints are met. If a constraint is absent it will not be checked for.
-
-For example, the presence callback constraint can be added to an App by adding a parameter to its configuration like this:
-
-```ini
-[some_app]
-module = some_module
-class = SomeClass
-constrain_presence = noone
-```
-
-Now, although the `initialize()` function will be called for MyClass, and it will have a chance to register as many callbacks as it desires, none of the callbacks will execute, in this case, until everyone has left. This could be useful for an interior motion detector App for instance. There are several different types of constraints:
-
-- input_boolean
-- input_select
-- presence
-- time
-
-An App can have as many or as few as are required. When more than one constraint is present, they must all evaluate to true to allow the callbacks to be called. Constraints becoming true are not an event in their own right, but if they are all true at a point in time, the next callback that would otherwise been blocked due to constraint failure will now be called. Similarly, if one of the constraints becomes false, the next callback that would otherwise have been called will be blocked.
-
-They are described individually below.
-
-### input_boolean
-By default, the input_boolean constraint prevents callbacks unless the specified input_boolean is set to "on". This is useful to allow certain Apps to be turned on and off from the user interface. For example:
-
-```ini
-[some_app]
-module = some_module
-class = SomeClass
-constrain_input_boolean = input_boolean.enable_motion_detection
-```
-
-If you want to reverse the logic so the constraint is only called when the input_boolean is off, use the optional state parameter by appending ",off" to the argument, e.g.:
-
-```ini
-[some_app]
-module = some_module
-class = SomeClass
-constrain_input_boolean = input_boolean.enable_motion_detection,off
-```
-
-### input_select
-The input_select constraint prevents callbacks unless the specified input_select is set to one or more of the nominated (comma separated) values. This is useful to allow certain Apps to be turned on and off according to some flag, e.g., a house mode flag.
-
-```ini
-# Single value
-constrain_input_select = input_select.house_mode,Day
-# or multiple values
-constrain_input_select = input_select.house_mode,Day,Evening,Night
-```
-
-### presence
-The presence constraint will constrain based on presence of device trackers. It takes 3 possible values:
-- `noone` - only allow callback execution when no one is home
-- `anyone` - only allow callback execution when one or more person is home
-- `everyone` - only allow callback execution when everyone is home
-
-```ini
-constrain_presence = anyone
-# or
-constrain_presence = someone
-# or
-constrain_presence = noone
-```
-
-### time
-The time constraint consists of 2 variables, `constrain_start_time` and `constrain_end_time`. Callbacks will only be executed if the current time is between the start and end times.
-- If both are absent no time constraint will exist
-- If only start is present, end will default to 1 second before midnight
-- If only end is present, start will default to midnight
-
-The times are specified in a string format with one of the following formats:
-- HH:MM:SS - the time in Hours Minutes and Seconds, 24 hour format.
-- `sunrise`|`sunset` [+|- HH:MM:SS]- time of the next sunrise or sunset with an optional positive or negative offset in Hours Minutes and seconds
-
-The time based constraint system correctly interprets start and end times that span midnight.
-
-```ini
-# Run between 8am and 10pm
-constrain_start_time = 08:00:00
-constrain_end_time = 22:00:00
-# Run between sunrise and sunset
-constrain_start_time = sunrise
-constrain_end_time = sunset
-# Run between 45 minutes before sunset and 45 minutes after sunrise the next day
-constrain_start_time = sunset - 00:45:00
-constrain_end_time = sunrise + 00:45:00
-```
-
-### days
-The day constraint consists of as list of days for which the callbacks will fire, e.g.
-
-```ini
-constrain_days = mon,tue,wed
-```
-
-Callback constraints can also be applied to individual callbacks within Apps, see later for more details.
-
-## A Note on Threading
-
-AppDaemon is multithreaded. This means that any time code within an App is executed, it is executed by one of many threads. This is generally not a particularly important consideration for this application; in general, the execution time of callbacks is expected to be far quicker than the frequency of events causing them. However, it should be noted for completeness, that it is certainly possible for different pieces of code within the App to be executed concurrently, so some care may be necessary if different callback for instance inspect and change shared variables. This is a fairly standard caveat with concurrent programming, and if you know enough to want to do this, then you should know enough to put appropriate safeguards in place. For the average user however this shouldn't be an issue. If there are sufficient use cases to warrant it, I will consider adding locking to the function invocations to make the entire infrastructure threadsafe, but I am not convinced that it is necessary.
-
-An additional caveat of a threaded worker pool environment is that it is the expectation that none of the callbacks tie threads up for a significant amount of time. To do so would eventually lead to thread exhaustion, which would make the system run behind events. No events would be lost as they would be queued, but callbacks would be delayed which is a bad thing.
-
-Given the above, NEVER use Python's `time.sleep()` if you want to perform an operation some time in the future, as this will tie up a thread for the period of the sleep. Instead use the scheduler's `run_in()` function which will allow you to delay without blocking any threads.
-
-## State Operations
-
-### A note on Home Assistant State
-
-State within Home Assistant is stored as a collection of dictionaries, one for each entity. Each entity's dictionary will have some common fields and a number of entity type specific fields The state for an entity will always have the attributes:
-
-- `last_updated`
-- `last_changed`
-- `state`
-
-Any other attributes such as brightness for a lamp will only be present if the entity supports them, and will be stored in a sub-dictionary called `attributes`. When specifying these optional attributes in the `get_state()` call, no special distinction is required between the main attributes and the optional ones - `get_state()` will figure it out for you.
-
-Also bear in mind that some attributes such as brightness for a light, will not be present when the light is off.
-
-In most cases, the attribute `state` has the most important value in it, e.g., for a light or switch this will be `on` or `off`, for a sensor it will be the value of that sensor. Many of the AppDaemon API calls and callbacks will implicitly return the value of state unless told to do otherwise.
-
-### get_state()
-
-#### Synopsis
-
-```python
-get_state(entity=None, attribute=None)
-```
-
-`get_state()` is used to query the state of any integration within Home Assistant. State updates are continuously tracked so this call runs locally and does not require AppDaemon to call back to Home Assistant and as such is very efficient.
-
-#### Returns
-
-`get_state()` returns a `dictionary` or single value, the structure of which varies according to the parameters used.
-
-#### Parameters
-
-All parameters are optional, and if `get_state()` is called with no parameters it will return the entire state of Home Assistant at that given time. This will consist of a dictionary with a key for each entity. Under that key will be the standard entity state information.
-
-##### entity
-
-This is the name of an entity or device type. If just a device type is provided, e.g., `light` or `binary_sensor`, `get_state()` will return a dictionary of all devices of that type, indexed by the entity_id, containing all the state for each entity.
-
-If a fully qualified `entity_id` is provided, `get_state()` will return the state attribute for that entity, e.g., `on` or `off` for a light.
-
-##### attribute
-
-Name of an attribute within the entity state object. If this parameter is specified in addition to a fully qualified `entity_id`, a single value representing the attribute will be returned, or `None` if it is not present.
-
-The value `all` for attribute has special significance and will return the entire state dictionary for the specified entity rather than an individual attribute value.
-
-#### Examples
-
-```python
-# Return state for the entire system
-state = self.get_state()
-
-# Return state for all switches in the system
-state = self.get_state("switch")
-
-# Return the state attribute for light.office_1
-state = self.get_state("light.office_1")
-
-# Return the brightness attribute for light.office_1
-state = self.get_state("light.office_1", attribute="brightness")
-
-# Return the entire state for light.office_1
-state = self.get_state("light.office_1", attribute="all")
-```
-
-### set_state()
-
-`set_state()` will make a call back to Home Assistant and make changes to the internal state of Home Assistant. This is not something that you would usually want to do and the applications are limited however the call is included for completeness. Note that for instance, setting the state of a light to `on` won't actually switch the device on, it will merely change the state of the device in Home Assistant so that it no longer reflects reality. In most cases, the state will be corrected the next time Home Assistant polls the device or someone causes a state change manually. To effect actual changes of devices use one of the service call functions.
-
-One possible use case for `set_state()` is for testing. If for instance you are writing an App to turn on a light when it gets dark according to a luminance sensor, you can use `set_state()` to temporarily change the light level reported by the sensor to test your program. However this is also possible using the developer tools.
-
-At the time of writing, it appears that no checking is done as to whether or not the entity exists, so it is possible to add entirely new entries to Home Assistant's state with this call.
-
-#### Synopsis
-
-```python
-set_state(entity_id, **kwargs)
-```
-
-#### Returns
-
-`set_state()` returns a dictionary representing the state of the device after the call has completed.
-
-#### Parameters
-
-##### entity_id
-
-Entity id for which the state is to be set, e.g., `light.office_1`.
-
-##### values
-
-A list of keyword values to be changed or added to the entities state. e.g., `state = "off"`. Note that any optional attributes such as colors for bulbs etc, need to reside in a dictionary called `attributes`; see the example.
-
-#### Examples
-
-```python
-status = self.set_state("light.office_1", state="on", attributes={"color_name": "red"})
-```
-
-### About Callbacks
-
-A large proportion of home automation revolves around waiting for something to happen and then reacting to it; a light level drops, the sun rises, a door opens etc. Home Assistant keeps track of every state change that occurs within the system and streams that information to AppDaemon almost immediately.
-
-An individual App however usually doesn't care about the majority of state changes going on in the system; Apps usually care about something very specific, like a specific sensor or light. Apps need a way to be notified when a state change happens that they care about, and be able to ignore the rest. They do this through registering callbacks. A callback allows the App to describe exactly what it is interested in, and tells AppDaemon to make a call into its code in a specific place to be able to react to it - this is a very familiar concept to anyone familiar with event-based programming.
-
-There are 3 types of callbacks within AppDaemon:
-
-- State Callbacks - react to a change in state
-- Scheduler Callbacks - react to a specific time or interval
-- Event Callbacks - react to specific Home Assistant and AppDaemon events.
-
-All callbacks allow the user to specify additional parameters to be handed to the callback via the standard Python `**kwargs` mechanism for greater flexibility.
-
-### About Registering Callbacks
-
-Each of the various types of callback have their own function or functions for registering the callback:
-
-- `listen_state()` for state callbacks
-- Various scheduler calls such as `run_once()` for scheduler callbacks
-- `listen_event()` for event callbacks.
-
-Each type of callback shares a number of common mechanisms that increase flexibility.
-
-#### Callback Level Constraints
-
-When registering a callback, you can add constraints identical to the Application level constraints described earlier. The difference is that a constraint applied to an individual callback only affects that callback and no other. The constraints are applied by adding Python keyword-value style arguments after the positional arguments. The parameters themselves are named identically to the previously described constraints and have identical functionality. For instance, adding:
-
-`constrain_presence="everyone"`
-
-to a callback registration will ensure that the callback is only run if the callback conditions are met and in addition everyone is present although any other callbacks might run whenever their event fires if they have no constraints.
-
-For example:
-
-`self.listen_state(self.motion, "binary_sensor.drive", constrain_presence="everyone")`
-
-#### User Arguments
-
-Any callback has the ability to allow the App creator to pass through arbitrary keyword arguments that will be presented to the callback when it is run. The arguments are added after the positional parameters just like the constraints. The only restriction is that they cannot be the same as any constraint name for obvious reasons. For example, to pass the parameter `arg1 = "home assistant"` through to a callback you would register a callback as follows:
-
-`self.listen_state(self.motion, "binary_sensor.drive", arg1="home assistant")`
-
-Then in the callback you could use it as follows:
-
-```python
-def motion(self, entity, attribute, old, new, **kwargs):
- self.log("Arg1 is {}".format(kwargs["arg1"]))
-```
-
-### State Callbacks
-
-AppDaemons's state callbacks allow an App to listen to a wide variety of events, from every state change in the system, right down to a change of a single attribute of a particular entity. Setting up a callback is done using a single API call `listen_state()` which takes various arguments to allow it to do all of the above. Apps can register as many or as few callbacks as they want.
-
-### About State Callback Functions
-
-When calling back into the App, the App must provide a class function with a known signature for AppDaemon to call. The callback will provide various information to the function to enable the function to respond appropriately. For state callbacks, a class defined callback function should look like this:
-
-```python
-def my_callback(self, entity, attribute, old, new, **kwargs):
- """Handle state callback."""
- # do some useful work here
-```
-
-You can call the function whatever you like - you will reference it in the `listen_state()` call, and you can create as many callback functions as you need.
-
-The parameters have the following meanings:
-
-#### self
-
-A standard Python object reference.
-
-#### entity
-
-Name of the entity the callback was requested for or `None`.
-
-#### attribute
-
-Name of the attribute the callback was requested for or `None`.
-
-#### old
-
-The value of the state before the state change.
-
-#### new
-
-The value of the state after the state change.
-
-`old` and `new` will have varying types depending on the type of callback.
-
-#### \*\*kwargs
-
-A dictionary containing any constraints and/or additional user specific keyword arguments supplied to the `listen_state()` call.
-
-### listen_state()
-
-`listen_state()` allows the user to register a callback for a wide variety of state changes.
-
-#### Synopsis
-
-```python
-handle = listen_state(callback, entity=None, **kwargs)
-```
-
-#### Returns
-
-A unique identifier that can be used to cancel the callback if required. Since variables created within object methods are local to the function they are created in, and in all likelihood the cancellation will be invoked later in a different function, it is recommended that handles are stored in the object namespace, e.g., `self.handle`.
-
-#### Parameters
-
-All parameters except `callback` are optional, and if `listen_state()` is called with no additional parameters it will subscribe to any state change within Home Assistant.
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard State Callback format documented above.
-
-##### entity
-
-This is the name of an entity or device type. If just a device type is provided, e.g., `light` or `binary_sensor`, `listen_state()` will subscribe to state changes of all devices of that type. If a fully qualified `entity_id` is provided, `listen_state()` will listen for state changes for just that entity.
-
-When called, AppDaemon will supply the callback function, in old and new, with the state attribute for that entity, e.g., `on` or `off` for a light.
-
-##### attribute (optional)
-
-Name of an attribute within the entity state object. If this parameter is specified in addition to a fully qualified `entity_id`, `listen_state()` will subscribe to changes for just that attribute within that specific entity. The new and old parameters in the callback function will be provided with a single value representing the attribute.
-
-The value `all` for attribute has special significance and will listen for any state change within the specified entity, and supply the callback functions with the entire state dictionary for the specified entity rather than an individual attribute value.
-
-##### new = (optional)
-
-If `new` is supplied as a parameter, callbacks will only be made if the state of the selected attribute (usually `state`) in the new state match the value of `new`.
-
-##### old = (optional)
-
-If `old` is supplied as a parameter, callbacks will only be made if the state of the selected attribute (usually `state`) in the old state match the value of `old`.
-
-Note: `old` and `new` can be used singly or together.
-
-##### duration = (optional)
-
-If duration is supplied as a parameter, the callback will not fire unless the state listened for is maintained for that number of seconds. This makes the most sense if a specific attribute is specified (or the default os `state` is used), an in conjunction with the `old` or `new` parameters, or both. When the callback is called, it is supplied with the values of `entity`, `attr`, `old` and `new` that were current at the time the actual event occurred, since the assumption is that none of them have changed in the intervening period.
-
-```python
-def my_callback(self, **kwargs):
- """Handle state change."""
- # do some useful work here
-```
-
-(Scheduler callbacks are documented in detail later in this document)
-
-##### \*\*kwargs
-
-Zero or more keyword arguments that will be supplied to the callback when it is called.
-
-#### Examples
-
-```python
-# Listen for any state change and return the state attribute
-self.handle = self.listen_state(self.my_callback)
-
-# Listen for any state change involving a light and return the state attribute
-self.handle = self.listen_state(self.my_callback, "light")
-
-# Listen for a state change involving light.office1 and return the state attribute
-self.handle = self.listen_state(self.my_callback, "light.office_1")
-
-# Listen for a state change involving light.office1 and return the entire state as a dict
-self.handle = self.listen_state(self.my_callback, "light.office_1", attribute="all")
-
-# Listen for a state change involving the brightness attribute of light.office1
-self.handle = self.listen_state(
- self.my_callback, "light.office_1", attribute="brightness"
-)
-
-# Listen for a state change involving light.office1 turning on and return the state attribute
-self.handle = self.listen_state(self.my_callback, "light.office_1", new="on")
-
-# Listen for a state change involving light.office1 changing from brightness 100 to 200 and return the state attribute
-self.handle = self.listen_state(
- self.my_callback, "light.office_1", old="100", new="200"
-)
-
-# Listen for a state change involving light.office1 changing to state on and remaining on for a minute
-self.handle = self.listen_state(
- self.my_callback, "light.office_1", new="on", duration=60
-)
-```
-
-### cancel_listen_state()
-
-Cancel a `listen_state()` callback. This will mean that the App will no longer be notified for the specific state change that has been canceled. Other state changes will continue to be monitored.
-
-#### Synopsis
-
-```python
-cancel_listen_state(handle)
-```
-
-#### Returns
-
-Nothing
-
-#### Parameters
-
-##### handle
-
-The handle returned when the `listen_state()` call was made.
-
-#### Examples
-
-```python
-self.cancel_listen_state(self.office_light_handle)
-```
-
-### info_listen_state()
-
-Get information on state a callback from its handle.
-
-#### Synopsis
-
-```python
-entity, attribute, kwargs = self.info_listen_state(self.handle)
-```
-
-#### Returns
-
-entity, attribute, kwargs - the values supplied when the callback was initially created.
-
-#### Parameters
-
-##### handle
-
-The handle returned when the `listen_state()` call was made.
-
-#### Examples
-
-```python
-entity, attribute, kwargs = self.info_listen_state(self.handle)
-```
-
-## Scheduler
-
-AppDaemon contains a powerful scheduler that is able to run with 1 second resolution to fire off specific events at set times, or after set delays, or even relative to sunrise and sunset. In general, events should be fired less than a second after specified but under certain circumstances there may be short additional delays.
-
-### About Schedule Callbacks
-
-As with State Change callbacks, Scheduler Callbacks expect to call into functions with a known and specific signature and a class defined Scheduler callback function should look like this:
-
-```python
-def my_callback(self, **kwargs):
- """Handle scheduler callback."""
- # do some useful work here
-```
-
-You can call the function whatever you like; you will reference it in the Scheduler call, and you can create as many callback functions as you need.
-
-The parameters have the following meanings:
-
-#### self
-A standard Python object reference
-
-#### \*\*kwargs
-
-A dictionary containing Zero or more keyword arguments to be supplied to the callback.
-
-### Creation of Scheduler Callbacks
-
-Scheduler callbacks are created through use of a number of convenience functions which can be used to suit the situation.
-
-#### run_in()
-
-Run the callback in a defined number of seconds. This is used to add a delay, for instance a 60 second delay before a light is turned off after it has been triggered by a motion detector. This callback should always be used instead of `time.sleep()` as discussed previously.
-
-#### Synopsis
-
-```python
-self.handle = self.run_in(callback, delay, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### vcallback %}
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### delay
-
-Delay, in seconds before the callback is invoked.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-self.handle = self.run_in(self.run_in_c)
-self.handle = self.run_in(self.run_in_c, title="run_in5")
-```
-#### run_once()
-
-Run the callback once, at the specified time of day. If the time of day is in the past, the callback will occur on the next day.
-
-#### Synopsis
-
-```python
-self.handle = self.run_once(callback, time, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### time
-
-A Python `time` object that specifies when the callback will occur. If the time specified is in the past, the callback will occur the next day at the specified time.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Run at 4pm today, or 4pm tomorrow if it is already after 4pm
-import datetime
-
-...
-runtime = datetime.time(16, 0, 0)
-handle = self.run_once(self.run_once_c, runtime)
-```
-
-#### run_at()
-
-Run the callback once, at the specified date and time.
-
-#### Synopsis
-
-```python
-self.handle = self.run_at(callback, datetime, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer. `run_at()` will raise an exception if the specified time is in the past.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### datetime
-
-A Python `datetime` object that specifies when the callback will occur.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Run at 4pm today
-import datetime
-
-...
-runtime = datetime.time(16, 0, 0)
-today = datetime.date.today()
-event = datetime.datetime.combine(today, runtime)
-handle = self.run_once(self.run_once_c, event)
-```
-#### run_daily()
-
-Execute a callback at the same time every day. If the time has already passed, the function will not be invoked until the following day at the specified time.
-
-#### Synopsis
-
-```python
-self.handle = self.run_daily(callback, time, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### time
-
-A Python `time` object that specifies when the callback will occur. If the time specified is in the past, the callback will occur the next day at the specified time.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Run daily at 7pm
-import datetime
-
-...
-time = datetime.time(19, 0, 0)
-self.run_daily(self.run_daily_c, runtime)
-```
-
-#### run_hourly()
-
-Execute a callback at the same time every hour. If the time has already passed, the function will not be invoked until the following hour at the specified time.
-
-#### Synopsis
-
-```python
-self.handle = self.run_hourly(callback, time=None, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### time
-
-A Python `time` object that specifies when the callback will occur, the hour integration of the time object is ignored. If the time specified is in the past, the callback will occur the next hour at the specified time. If time is not supplied, the callback will start an hour from the time that `run_hourly()` was executed.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Run every hour, on the hour
-import datetime
-
-...
-time = datetime.time(0, 0, 0)
-self.run_daily(self.run_daily_c, runtime)
-```
-#### run_minutely()
-
-Execute a callback at the same time every minute. If the time has already passed, the function will not be invoked until the following minute at the specified time.
-
-#### Synopsis
-
-```python
-self.handle = self.run_minutely(callback, time=None, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### time
-
-A Python `time` object that specifies when the callback will occur, the hour and minute components of the time object are ignored. If the time specified is in the past, the callback will occur the next hour at the specified time. If time is not supplied, the callback will start a minute from the time that `run_minutely()` was executed.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Run Every Minute on the minute
-import datetime
-
-...
-time = datetime.time(0, 0, 0)
-self.run_minutely(self.run_minutely_c, time)
-```
-
-#### run_every()
-
-Execute a repeating callback with a configurable delay starting at a specific time.
-
-#### Synopsis
-
-```python
-self.handle = self.run_every(callback, time, repeat, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### time
-
-A Python `time` object that specifies when the initial callback will occur.
-
-##### repeat
-
-After the initial callback has occurred, another will occur every `repeat` seconds.
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Run every 17 minutes starting in 2 hours time
-import datetime
-
-...
-self.run_every(self.run_every_c, time, 17 * 60)
-```
-
-#### cancel_timer()
-Cancel a previously created timer
-
-#### Synopsis
-
-```python
-self.cancel_timer(handle)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### handle
-
-A handle value returned from the original call to create the timer.
-
-#### Examples
-
-```python
-self.cancel_timer(handle)
-```
-
-### info_timer()
-
-Get information on a scheduler event from its handle.
-
-#### Synopsis
-
-```python
-time, interval, kwargs = self.info_timer(handle)
-```
-
-#### Returns
-
-time - datetime object representing the next time the callback will be fired
-
-interval - repeat interval if applicable, `0` otherwise.
-
-kwargs - the values supplied when the callback was initially created.
-
-#### Parameters
-
-##### handle
-
-The handle returned when the scheduler call was made.
-
-#### Examples
-
-```python
-time, interval, kwargs = self.info_timer(handle)
-```
-
-### Scheduler Randomization
-
-All of the scheduler calls above support 2 additional optional arguments, `random_start` and `random_end`. Using these arguments it is possible to randomize the firing of callbacks to the degree desired by setting the appropriate number of seconds with the parameters.
-
-- `random_start` - start of range of the random time
-- `random_end` - end of range of the random time
-
-`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be an absolute or relative time or sunrise/sunset depending on which scheduler call you use and these values affect the base time by the specified amount. If not specified, they will default to `0`.
-
-For example:
-
-```python
-# Run a callback in 2 minutes minus a random number of seconds between 0 and 60, e.g., run between 60 and 120 seconds from now
-self.handle = self.run_in(callback, 120, random_start=-60, **kwargs)
-# Run a callback in 2 minutes plus a random number of seconds between 0 and 60, e.g., run between 120 and 180 seconds from now
-self.handle = self.run_in(callback, 120, random_end=60, **kwargs)
-# Run a callback in 2 minutes plus or minus a random number of seconds between 0 and 60, e.g., run between 60 and 180 seconds from now
-self.handle = self.run_in(callback, 120, random_start=-60, random_end=60, **kwargs)
-```
-
-## Sunrise and Sunset
-
-AppDaemon has a number of features to allow easy tracking of sunrise and sunset as well as a couple of scheduler functions. Note that the scheduler functions also support the randomization parameters described above, but they cannot be used in conjunction with the `offset` parameter`.
-
-### run_at_sunrise()
-
-Run a callback at or around sunrise.
-
-#### Synopsis
-
-```python
-self.handle = self.run_at_sunrise(callback, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### offset =
-
-The time in seconds that the callback should be delayed after sunrise. A negative value will result in the callback occurring before sunrise. This parameter cannot be combined with `random_start` or `random_end`
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-import datetime
-
-# ...
-
-# Run 45 minutes before sunset
-self.run_at_sunrise(self.sun, offset=datetime.timedelta(minutes=-45).total_seconds())
-# or you can just do the math yourself
-self.run_at_sunrise(self.sun, offset=30 * 60) # Sunrise +30 mins
-# Run at a random time +/- 60 minutes from sunrise
-self.run_at_sunrise(self.sun, random_start=-60 * 60, random_end=60 * 60)
-# Run at a random time between 30 and 60 minutes before sunrise
-self.run_at_sunrise(self.sun, random_start=-60 * 60, random_end=30 * 60)
-```
-
-### run_at_sunset()
-
-Run a callback at or around sunset.
-
-#### Synopsis
-
-```python
-self.handle = self.run_at_sunset(callback, offset, **kwargs)
-```
-
-#### Returns
-
-A handle that can be used to cancel the timer.
-
-#### Parameters
-
-##### callback
-
-Function to be invoked when the requested state change occurs. It must conform to the standard Scheduler Callback format documented above.
-
-##### offset =
-
-The time in seconds that the callback should be delayed after sunrise. A negative value will result in the callback occurring before sunrise. This parameter cannot be combined with `random_start` or `random_end`
-
-##### \*\*kwargs
-
-Arbitrary keyword parameters to be provided to the callback function when it is invoked.
-
-#### Examples
-
-```python
-# Example using timedelta
-import datetime
-
-# ...
-
-self.run_at_sunset(
- self.sun, datetime.timedelta(minutes=-45).total_seconds()
-) # Sunset -45 mins
-# or you can just do the math yourself
-self.run_at_sunset(self.sun, 30 * 60) # Sunset +30 mins
-# Run at a random time +/- 60 minutes from sunset
-self.run_at_sunset(self.sun, random_start=-60 * 60, random_end=60 * 60)
-# Run at a random time between 30 and 60 minutes before sunset
-self.run_at_sunset(self.sun, random_start=-60 * 60, random_end=30 * 60)
-```
-### sunrise()
-
-Return the time that the next Sunrise will occur.
-
-#### Synopsis
-
-```python
-self.sunrise()
-```
-
-#### Returns
-
-A Python datetime that represents the next time Sunrise will occur.
-
-#### Examples
-
-```python
-rise_time = self.sunrise()
-```
-### sunset()
-
-Return the time that the next Sunset will occur.
-
-#### Synopsis
-
-```python
-self.sunset()
-```
-
-#### Returns
-
-A Python datetime that represents the next time Sunset will occur.
-
-#### Examples
-
-```python
-set_time = self.sunset()
-```
-### sun_up()
-
-A function that allows you to determine if the sun is currently up.
-
-#### Synopsis
-
-```python
-result = self.sun_up()
-```
-
-#### Returns
-
-`True` if the sun is up, False otherwise.
-
-#### Examples
-
-```python
-if self.sun_up():
- do_something()
-```
-
-### sun_down()
-
-A function that allows you to determine if the sun is currently down.
-
-#### Synopsis
-
-```python
-result = self.sun_down()
-```
-
-#### Returns
-
-`True` if the sun is down, False otherwise.
-
-#### Examples
-
-```python
-if self.sun_down():
- do_something()
-```
-
-## Calling Services
-
-### About Services
-
-Services within Home Assistant are how changes are made to the system and its devices. Services can be used to turn lights on and off, set thermostats and a whole number of other things. Home Assistant supplies a single interface to all these disparate services that take arbitrary parameters. AppDaemon provides the `call_service()` function to call into Home Assistant and run a service. In addition, it also provides convenience functions for some of the more common services making calling them a little easier.
-
-### call_service()
-
-Call service is the basic way of calling a service within AppDaemon. It can call any service and provide any required parameters. Available services can be found using the developer tools in the UI. For listed services, the part before the first period is the domain, and the part after is the service name. For instance, `light.turn_on` has a domain of `light` and a service name of `turn_on`.
-
-#### Synopsis
-
-```python
-self.call_service(service, **kwargs)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### service
-
-The service name, e.g., `light/turn_on`.
-
-##### \*\*kwargs
-
-Each service has different parameter requirements. This argument allows you to specify a comma separated list of keyword value pairs, e.g., `entity_id = light.office_1`. These parameters will be different for every service and can be discovered using the developer tools. Most if not all service calls require an `entity_id` however, so use of the above example is very common with this call.
-
-#### Examples
-
-```python
-self.call_service("light/turn_on", entity_id="light.office_lamp", color_name="red")
-self.call_service("notify/notify", title="Hello", message="Hello World")
-```
-### turn_on()
-
-This is a convenience function for the `homeassistant.turn_on` function. It is able to turn on pretty much anything in Home Assistant that can be turned on or run:
-
-- Lights
-- Switches
-- Scenes
-- Scripts
-
-And many more.
-
-#### Synopsis
-
-```python
-self.turn_on(entity_id, **kwargs)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### entity_id
-
-Fully qualified entity_id of the thing to be turned on, e.g., `light.office_lamp` or ```scene.downstairs_on```
-
-##### \*\*kwargs
-
-A comma separated list of key value pairs to allow specification of parameters over and above `entity_id`.
-
-#### Examples
-
-```python
-self.turn_on("switch.patio_lights")
-self.turn_on("scene.bedroom_on")
-self.turn_on("light.office_1", color_name="green")
-```
-
-### turn_off()
-
-This is a convenience function for the `homeassistant.turn_off` function. Like `homeassistant.turn_on`, it is able to turn off pretty much anything in Home Assistant that can be turned off.
-
-#### Synopsis
-
-```python
-self.turn_off(entity_id)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### entity_id
-
-Fully qualified entity_id of the thing to be turned off, e.g., `light.office_lamp` or `scene.downstairs_on`.
-
-#### Examples
-
-```python
-self.turn_off("switch.patio_lights")
-self.turn_off("light.office_1")
-```
-
-### toggle()
-
-This is a convenience function for the `homeassistant.toggle` function. It is able to flip the state of pretty much anything in Home Assistant that can be turned on or off.
-
-#### Synopsis
-
-```python
-self.toggle(entity_id)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### entity_id
-
-Fully qualified entity_id of the thing to be toggled, e.g., `light.office_lamp` or `scene.downstairs_on`.
-
-#### Examples
-
-```python
-self.toggle("switch.patio_lights")
-self.toggle("light.office_1", color_name="green")
-```
-
-### select_value()
-
-This is a convenience function for the `input_number.select_value` function. It is able to set the value of an input_number in Home Assistant.
-
-#### Synopsis
-
-```python
-self.select_value(entity_id, value)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### entity_id
-
-Fully qualified entity_id of the input_number to be changed, e.g., `input_number.alarm_hour`.
-
-##### value
-
-The new value to set the input number to.
-
-#### Examples
-
-```python
-self.select_value("input_number.alarm_hour", 6)
-```
-
-### select_option()
-
-This is a convenience function for the `input_select.select_option` function. It is able to set the value of an input_select in Home Assistant.
-
-#### Synopsis
-
-```python
-self.select_option(entity_id, option)
-```
-
-#### Returns
-
-None
-
-#### Parameters
-
-##### entity_id
-
-Fully qualified entity_id of the input_select to be changed, e.g., `input_select.mode`.
-
-##### value
-
-The new value to set the input number to.
-
-#### Examples
-
-```python
-self.select_option("input_select.mode", "Day")
-```
-
-### notify()
-
-This is a convenience function for the `notify.notify` service. It will send a notification to your default notification service. If you have more than one, use `call_service()` to call the specific notification service you require instead.
-
-#### Synopsis
-
-```python
-notify(message, title=None)
-```
-#### Returns
-
-None
-
-#### Parameters
-
-##### message
-
-Message to be sent to the notification service.
-
-##### title
-
-Title of the notification - optional.
-
-#### Examples
-
-```python
-self.notify("", "Switching mode to Evening")
-```
-
-## Events
-
-### About Events
-
-Events are a fundamental part of how Home Assistant works under the covers. HA has an event bus that all integrations can read and write to, enabling integrations to inform other integrations when important events take place. We have already seen how state changes can be propagated to AppDaemon - a state change however is merely an example of an event within Home Assistant. There are several other event types, among them are:
-
-- `homeassistant_start`
-- `homeassistant_stop`
-- `state_changed`
-- `service_registered`
-- `call_service`
-- `service_executed`
-- `platform_discovered`
-- `component_loaded`
-
-Using AppDaemon, it is possible to subscribe to specific events as well as fire off events.
-
-In addition to the Home Assistant supplied events, AppDaemon adds 2 more events. These are internal to AppDaemon and are not visible on the Home Assistant bus:
-
-- `appd_started` - fired once when AppDaemon is first started and after Apps are initialized
-- `ha_started` - fired every time AppDaemon detects a Home Assistant restart
-
-### About Event Callbacks
-
-As with State Change and Scheduler callbacks, Event Callbacks expect to call into functions with a known and specific signature and a class defined Scheduler callback function should look like this:
-
-```python
-def my_callback(self, event_name, data, kwargs):
- """Handle event callback."""
- # do some useful work here
-```
-
-You can call the function whatever you like - you will reference it in the Scheduler call, and you can create as many callback functions as you need.
-
-The parameters have the following meanings:
-
-#### self
-
-A standard Python object reference.
-
-#### event_name
-
-Name of the event that was called, e.g., `call_service`.
-
-#### data
-
-Any data that the system supplied with the event as a dict.
-
-#### kwargs
-
-A dictionary containing Zero or more user keyword arguments to be supplied to the callback.
-
-### listen_event()
-
-Listen event sets up a callback for a specific event, or any event.
-
-#### Synopsis
-
-```python
-handle = listen_event(function, event=None, **kwargs)
-```
-#### Returns
-
-A handle that can be used to cancel the callback.
-
-#### Parameters
-
-##### function
-
-The function to be called when the event is fired.
-
-##### event
-
-Name of the event to subscribe to. Can be a standard Home Assistant event such as `service_registered` or an arbitrary custom event such as `"MODE_CHANGE"`. If no event is specified, `listen_event()` will subscribe to all events.
-
-##### \*\*kwargs (optional)
-
-One or more keyword value pairs representing App specific parameters to supply to the callback. If the keywords match values within the event data, they will act as filters, meaning that if they don't match the values, the callback will not fire.
-
-As an example of this, a Minimote controller when activated will generate an event called `zwave.scene_activated`, along with 2 pieces of data that are specific to the event - `entity_id` and `scene`. If you include keyword values for either of those, the values supplied to the `listen_event()` call must match the values in the event or it will not fire. If the keywords do not match any of the data in the event they are simply ignored.
-
-Filtering will work with any event type, but it will be necessary to figure out the data associated with the event to understand what values can be filtered on. This can be achieved by examining Home Assistant's logfiles when the event fires.
-
-#### Examples
-
-```python
-self.listen_event(self.mode_event, "MODE_CHANGE")
-# Listen for a minimote event activating scene 3:
-self.listen_event(self.generic_event, "zwave.scene_activated", scene_id=3)
-# Listen for a minimote event activating scene 3 from a specific minimote:
-self.listen_event(
- self.generic_event, "zwave.scene_activated", entity_id="minimote_31", scene_id=3
-)
-```
-
-### cancel_listen_event()
-
-Cancels callbacks for a specific event.
-
-#### Synopsis
-
-```python
-cancel_listen_event(handle)
-```
-#### Returns
-
-None.
-
-#### Parameters
-
-##### handle
-
-A handle returned from a previous call to `listen_event()`.
-
-#### Examples
-
-```python
-self.cancel_listen_event(handle)
-```
-
-### info_listen_event()
-
-Get information on an event callback from its handle.
-
-#### Synopsis
-
-```python
-service, kwargs = self.info_listen_event(handle)
-```
-
-#### Returns
-
-service, kwargs - the values supplied when the callback was initially created.
-
-#### Parameters
-
-##### handle
-
-The handle returned when the `listen_event()` call was made.
-
-#### Examples
-
-```python
-service, kwargs = self.info_listen_event(handle)
-```
-
-
-### fire_event()
-
-Fire an event on the Home Assistant bus, for other integrations to hear.
-
-#### Synopsis
-
-```python
-fire_event(event, **kwargs)
-```
-
-#### Returns
-
-None.
-
-#### Parameters
-
-##### event
-
-Name of the event. Can be a standard Home Assistant event such as `service_registered` or an arbitrary custom event such as `"MODE_CHANGE"`.
-
-##### \*\*kwargs
-
-Zero or more keyword arguments that will be supplied as part of the event.
-
-#### Examples
-
-```python
-self.fire_event("MY_CUSTOM_EVENT", jam="true")
-```
-
-### Event Callback Function Signature
-
-Functions called as an event callback will be supplied with 2 arguments:
-
-```python
-def service(self, event_name, data):
- """Handle event."""
-```
-
-#### event_name
-
-The name of the event that caused the callback, e.g., `"MODE_CHANGE"` or `call_service`.
-
-#### data
-
-A dictionary containing any additional information associated with the event.
-
-### Use of Events for Signaling between Home Assistant and AppDaemon
-
-Home Assistant allows for the creation of custom events and existing integrations can send and receive them. This provides a useful mechanism for signaling back and forth between Home Assistant and AppDaemon. For instance, if you would like to create a UI Element to fire off some code in Home Assistant, all that is necessary is to create a script to fire a custom event, then subscribe to that event in AppDaemon. The script would look something like this:
-
-```yaml
-alias: Day
-sequence:
-- event: MODE_CHANGE
- event_data:
- mode: Day
-```
-
-The custom event `MODE_CHANGE` would be subscribed to with:
-
-```python
-self.listen_event(self.mode_event, "MODE_CHANGE")
-```
-
-Home Assistant can send these events in a variety of other places - within automations, and also directly from Alexa intents. Home Assistant can also listen for custom events with its automation component. This can be used to signal from AppDaemon code back to Home Assistant. Here is a sample automation:
-
-```yaml
-automation:
- trigger:
- platform: event
- event_type: MODE_CHANGE
- ...
- ...
-```
-
-This can be triggered with a call to AppDaemon's fire_event() as follows:
-
-```python
-self.fire_event("MODE_CHANGE", mode="Day")
-```
-
-## Presence
-
-Presence in Home Assistant is tracked using Device Trackers. The state of all device trackers can be found using the `get_state()` call, however AppDaemon provides several convenience functions to make this easier.
-
-### get_trackers()
-
-Return a list of all device trackers. This is designed to be iterated over.
-
-#### Synopsis
-
-```python
-tracker_list = get_trackers()
-```
-#### Returns
-
-An iterable list of all device trackers.
-
-#### Examples
-
-```python
-trackers = self.get_trackers()
-for tracker in trackers:
- do_something(tracker)
-```
-
-### get_tracker_state()
-
-Get the state of a tracker. The values returned depend in part on the configuration and type of device trackers in the system. Simpler tracker types like `Locative` or `Nmap` will return one of 2 states:
-
-- `home`
-- `not_home`
-
-Some types of device tracker are in addition able to supply locations that have been configured as Geofences, in which case the name of that location can be returned.
-
-#### Synopsis
-
-```python
-location = self.get_tracker_state(tracker_id)
-```
-
-#### Returns
-
-A string representing the location of the tracker.
-
-#### Parameters
-
-##### tracker_id
-
-Fully qualified entity_id of the device tracker to query, e.g., `device_tracker.andrew`.
-
-#### Examples
-
-```python
-trackers = self.get_trackers()
-for tracker in trackers:
- self.log("{} is {}".format(tracker, self.get_tracker_state(tracker)))
-```
-
-### everyone_home()
-
-A convenience function to determine if everyone is home.
-
-#### Synopsis
-
-```python
-result = self.everyone_home()
-```
-#### Returns
-
-Returns `True` if everyone is at home, `False` otherwise.
-
-#### Examples
-
-```python
-if self.everyone_home():
- do_something()
-```
-### anyone_home()
-
-A convenience function to determine if one or more person is home.
-
-#### Synopsis
-
-```python
-result = self.anyone_home()
-```
-
-#### Returns
-
-Returns `True` if anyone is at home, `False` otherwise.
-
-#### Examples
-
-```python
-if self.anyone_home():
- do_something()
-```
-### noone_home()
-
-A convenience function to determine if no people are at home.
-
-#### Synopsis
-
-```python
-result = self.noone_home()
-```
-
-#### Returns
-
-Returns `True` if no one is home, `False` otherwise.
-
-#### Examples
-
-```python
-if self.noone_home():
- do_something()
-```
-
-## Miscellaneous Helper Functions
-
-### time()
-
-Returns a Python `time` object representing the current time. Use this in preference to the standard Python ways to discover the current time, especially when using the "Time Travel" feature for testing.
-
-#### Synopsis
-
-```python
-time()
-```
-
-#### Returns
-
-A localized Python time object representing the current AppDaemon time.
-
-#### Parameters
-
-None
-
-#### Example
-
-```python
-now = self.time()
-```
-
-### date()
-
-Returns a Python `date` object representing the current date. Use this in preference to the standard Python ways to discover the current date, especially when using the "Time Travel" feature for testing.
-
-#### Synopsis
-
-```python
-date()
-```
-
-#### Returns
-
-A localized Python time object representing the current AppDaemon date.
-
-#### Parameters
-
-None
-
-#### Example
-
-```python
-today = self.date()
-```
-
-### datetime()
-
-Returns a Python `datetime` object representing the current date and time. Use this in preference to the standard Python ways to discover the current time, especially when using the "Time Travel" feature for testing.
-
-#### Synopsis
-
-```python
-datetime()
-```
-
-#### Returns
-
-A localized Python datetime object representing the current AppDaemon date and time.
-
-#### Parameters
-
-None
-
-#### Example
-
-```python
-now = self.datetime()
-```
-
-
-### convert_utc()
-
-Home Assistant provides timestamps of several different sorts that may be used to gain additional insight into state changes. These timestamps are in UTC and are coded as ISO 8601 Combined date and time strings. `convert_utc()` will accept one of these strings and convert it to a localized Python datetime object representing the timestamp
-
-#### Synopsis
-
-```python
-convert_utc(utc_string)
-```
-
-#### Returns
-
-`convert_utc(utc_string)` returns a localized Python datetime object representing the timestamp.
-
-#### Parameters
-
-##### utc_string
-
-An ISO 8601 encoded date and time string in the following format: `2016-07-13T14:24:02.040658-04:00`
-
-#### Example
-
-###parse_time()
-
-Takes a string representation of a time, or sunrise or sunset offset and converts it to a `datetime.time` object.
-
-#### Synopsis
-
-```python
-parse_time(time_string)
-```
-
-#### Returns
-
-A `datetime.time` object, representing the time given in the `time_string` argument.
-
-#### Parameters
-
-##### time_string
-
-A representation of the time in a string format with one of the following formats:
-
-- HH:MM:SS - the time in Hours Minutes and Seconds, 24 hour format.
-- sunrise | sunset [+ | - HH:MM:SS]- time of the next sunrise or sunset with an optional positive or negative offset in Hours Minutes and seconds
-
-#### Example
-
-```python
-time = self.parse_time("17:30:00")
-time = self.parse_time("sunrise")
-time = self.parse_time("sunset + 00:30:00")
-time = self.parse_time("sunrise + 01:00:00")
-```
-
-### now_is_between()
-
-Takes two string representations of a time, or sunrise or sunset offset and returns true if the current time is between those 2 times. `now_is_between()` can correctly handle transitions across midnight.
-
-#### Synopsis
-
-```python
-now_is_between(start_time_string, end_time_string)
-```
-
-#### Returns
-
-`True` if the current time is within the specified start and end times, `False` otherwise.
-
-#### Parameters
-
-##### start_time_string, end_time_string
-
-A representation of the start and end time respectively in a string format with one of the following formats:
-
-- HH:MM:SS - the time in Hours Minutes and Seconds, 24 hour format.
-- sunrise | sunset [+ | - HH:MM:SS]- time of the next sunrise or sunset with an optional positive or negative offset in Hours Minutes and seconds
-
-#### Example
-
-```python
-if self.now_is_between("17:30:00", "08:00:00"):
- do_something()
-if self.now_is_between("sunset - 00:45:00", "sunrise + 00:45:00"):
- do_something_else()
-```
-
-### friendly_name()
-
-`friendly_name()` will return the Friendly Name of an entity if it has one.
-
-#### Synopsis
-
-```python
-Name = self.friendly_name(entity_id)
-```
-
-#### Returns
-
-The friendly name of the entity if it exists or the entity id if not.
-
-#### Example
-
-```python
-tracker = "device_tracker.andrew"
-self.log(
- "{} ({}) is {}".format(
- tracker, self.friendly_name(tracker), self.get_tracker_state(tracker)
- )
-)
-```
-
-### split_entity()
-
-`split_entity()` will take a fully qualified entity id of the form `light.hall_light` and split it into 2 values, the device and the entity, e.g., `light` and `hall_light`.
-
-#### Synopsis
-
-```python
-device, entity = self.split_entity(entity_id)
-```
-
-#### Parameters
-
-##### entity_id
-
-Fully qualified entity id to be split.
-
-#### Returns
-
-A list with 2 entries, the device and entity respectively.
-
-#### Example
-
-```python
-device, entity = self.split_entity(entity_id)
-if device == "scene":
- do_something_specific_to_scenes()
-```
-
-
-### get_app()
-
-`get_app()` will return the instantiated object of another app running within the system. This is useful for calling functions or accessing variables that reside in different apps without requiring duplication of code.
-
-#### Synopsis
-
-```python
-get_app(self, name)
-```
-#### Parameters
-
-##### name
-
-Name of the app required. This is the name specified in header section of the configuration file, not the module or class.
-
-#### Returns
-
-An object reference to the class.
-
-#### Example
-```python
-MyApp = self.get_app("MotionLights")
-MyApp.turn_light_on()
-```
-
-### split_device_list()
-
-`split_device_list()` will take a comma separated list of device types (or anything else for that matter) and return them as an iterable list. This is intended to assist in use cases where the App takes a list of entities from an argument, e.g., a list of sensors to monitor. If only one entry is provided, an iterable list will still be returned to avoid the need for special processing.
-
-#### Synopsis
-
-```python
-devices = split_device_list(list)
-```
-
-#### Returns
-
-A list of split devices with 1 or more entries.
-
-#### Example
-
-```python
-for sensor in self.split_device_list(self.args["sensors"]):
- do_something(sensor) # e.g., make a state subscription
-```
-
-
-### Writing to Logfiles
-
-AppDaemon uses 2 separate logs - the general log and the error log. An AppDaemon App can write to either of these using the supplied convenience methods `log()` and `error()`, which are provided as part of parent `AppDaemon` class, and the call will automatically pre-pend the name of the App making the call. The `-D` option of AppDaemon can be used to specify what level of logging is required and the logger objects will work as expected.
-
-### log()
-
-#### Synopsis
-
-```python
-log(message, level="INFO")
-```
-
-#### Returns
-
-Nothing
-
-#### Parameters
-
-##### Message
-
-The message to log.
-
-##### level
-
-The log level of the message - takes a string representing the standard logger levels.
-
-#### Examples
-
-```python
-self.log("Log Test: Parameter is {}".format(some_variable))
-self.log("Log Test: Parameter is {}".format(some_variable), level="ERROR")
-```
-
-### error()
-
-#### Synopsis
-
-```python
-error(message, level="WARNING")
-```
-#### Returns
-
-Nothing
-
-#### Parameters
-
-##### Message
-
-The message to log.
-
-##### level
-
-The log level of the message - takes a string representing the standard logger levels.
-
-#### Examples
-
-```python
-self.error("Some Warning string")
-self.error("Some Critical string", level="CRITICAL")
-```
-
-## Sharing information between Apps
-
-Sharing information between different Apps is very simple if required. Each app gets access to a global dictionary stored in a class attribute called `self.global_vars`. Any App can add or read any key as required. This operation is not however threadsafe so some car is needed.
-
-In addition, Apps have access to the entire configuration if required, meaning they can access AppDaemon configuration items as well as parameters from other Apps. To use this, there is a class attribute called `self.config`. It contains a `ConfigParser` object, which is similar in operation to a `Dictionary`. To access any apps parameters, simply reference the ConfigParser object using the Apps name (form the configuration file) as the first key, and the parameter required as the second, for instance:
-
-```python
-other_apps_arg = self.config["some_app"]["some_parameter"]
-```
-
-To get AppDaemon's configuration parameters, use the key "AppDaemon", e.g.:
-
-```python
-app_timezone = self.config["AppDaemon"]["time_zone"]
-```
-
-And finally, it is also possible to use the AppDaemon as a global area for sharing parameters across Apps. Simply add the required parameters to the AppDaemon section of your configuration:
-
-```ini
-[AppDaemon]
-ha_url =
-ha_key =
-...
-global_var = hello world
-```
-
-Then access it as follows:
-
-```python
-my_global_var = conf.config["AppDaemon"]["global_var"]
-```
-
-## Development Workflow
-
-Developing Apps is intended to be fairly simple but is an exercise in programming like any other kind of Python programming. As such, it is expected that apps will contain syntax errors and will generate exceptions during the development process. AppDaemon makes it very easy to iterate through the development process as it will automatically reload code that has changed and also will reload code if any of the parameters in the configuration file change as well.
-
-The recommended workflow for development is as follows:
-
-- Open a window and tail the `appdaemon.log` file
-- Open a second window and tail the `error.log` file
-- Open a third window or the editor of your choice for editing the App
-
-With this setup, you will see that every time you write the file, AppDaemon will log the fact and let you know it has reloaded the App in the `appdaemon.log` file.
-
-If there is an error in the compilation or a runtime error, this will be directed to the `error.log` file to enable you to see the error and correct it. When an error occurs, there will also be a warning message in `appdaemon.log` to tell you to check the error log.
-
-## Time Travel
-
-OK, time travel sadly isn't really possible but it can be very useful when testing Apps. For instance, imagine you have an App that turns a light on every day at sunset. It might be nice to test it without waiting for Sunset - and with AppDaemon's "Time Travel" features you can.
-
-### Choosing a Start Time
-
-Internally, AppDaemon keeps track of its own time relative to when it was started. This make is possible to start AppDaemon with a different start time and date to the current time. For instance to test that sunset App, start AppDaemon at a time just before sunset and see if it works as expected. To do this, simply use the "-s" argument on AppDaemon's command line. e,g,:
-
-```bash
-$ appdaemon -s "2016-06-06 19:16:00"
-2016-09-06 17:16:00 INFO AppDaemon Version 1.3.2 starting
-2016-09-06 17:16:00 INFO Got initial state
-2016-09-06 17:16:00 INFO Loading Module: /export/hass/appdaemon_test/conf/test_apps/sunset.py
-...
-```
-
-Note the timestamps in the log - AppDaemon believes it is now just before sunset and will process any callbacks appropriately.
-
-### Speeding things up
-
-Some Apps need to run for periods of a day or two for you to test all aspects. This can be time consuming, but Time Travel can also help here in two ways. The first is by speeding up time. To do this, simply use the `-t` option on the command line. This specifies the amount of time a second lasts while time traveling. The default of course is 1 second, but if you change it to `0.1` for instance, AppDaemon will work 10x faster. If you set it to `0`, AppDaemon will work as fast as possible and, depending in your hardware, may be able to get through an entire day in a matter of minutes. Bear in mind however, due to the threaded nature of AppDaemon, when you are running with `-t 0` you may see actual events firing a little later than expected as the rest of the system tries to keep up with the timer. To set the tick time, start AppDaemon as follows:
-
-```bash
-$ appdaemon -t 0.1
-```
-
-AppDaemon also has an interval flag - think of this as a second multiplier. If the flag is set to 3600 for instance, each tick of the scheduler will jump the time forward by an hour. This is good for covering vast amounts of time quickly but event firing accuracy will suffer as a result. For example:
-
-```bash
-$ appdaemon -e 3600
-```
-
-### Automatically stopping
-
-AppDaemon can be set to terminate automatically at a specific time. This can be useful if you want to repeatedly rerun a test, for example to test that random values are behaving as expected. Simply specify the end time with the `-e` flag as follows:
-
-```bash
-$ appdaemon -e "2016-06-06 10:10:00"
-2016-09-06 17:16:00 INFO AppDaemon Version 1.3.2 starting
-2016-09-06 17:16:00 INFO Got initial state
-2016-09-06 17:16:00 INFO Loading Module: /export/hass/appdaemon_test/conf/test_apps/sunset.py
-...
-```
-
-The `-e` flag is most useful when used in conjunction with the -s flag and optionally the `-t` flag. For example, to run from just before sunset, for an hour, as fast as possible:
-
-```bash
-$ appdaemon -s "2016-06-06 19:16:00" -s "2016-06-06 20:16:00" -t 0
-```
-
-
-### A Note on Times
-
-Some Apps you write may depend on checking times of events relative to the current time. If you are time traveling this will not work if you use standard Python library calls to get the current time and date etc. For this reason, always use the AppDamon supplied `time()`, `date()` and `datetime()` calls, documented earlier. These calls will consult with AppDaemon's internal time rather than the actual time and give you the correct values.
diff --git a/source/_docs/ecosystem/appdaemon/configuration.markdown b/source/_docs/ecosystem/appdaemon/configuration.markdown
deleted file mode 100644
index 599a8fa9af4..00000000000
--- a/source/_docs/ecosystem/appdaemon/configuration.markdown
+++ /dev/null
@@ -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
diff --git a/source/_docs/ecosystem/appdaemon/example_apps.markdown b/source/_docs/ecosystem/appdaemon/example_apps.markdown
deleted file mode 100644
index ca34797c993..00000000000
--- a/source/_docs/ecosystem/appdaemon/example_apps.markdown
+++ /dev/null
@@ -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.
diff --git a/source/_docs/ecosystem/appdaemon/installation.markdown b/source/_docs/ecosystem/appdaemon/installation.markdown
deleted file mode 100644
index 61361d02a64..00000000000
--- a/source/_docs/ecosystem/appdaemon/installation.markdown
+++ /dev/null
@@ -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.
diff --git a/source/_docs/ecosystem/appdaemon/operation.markdown b/source/_docs/ecosystem/appdaemon/operation.markdown
deleted file mode 100644
index a80ae58307c..00000000000
--- a/source/_docs/ecosystem/appdaemon/operation.markdown
+++ /dev/null
@@ -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.
diff --git a/source/_docs/ecosystem/appdaemon/reboot.markdown b/source/_docs/ecosystem/appdaemon/reboot.markdown
deleted file mode 100644
index 386cd39e291..00000000000
--- a/source/_docs/ecosystem/appdaemon/reboot.markdown
+++ /dev/null
@@ -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.
diff --git a/source/_docs/ecosystem/appdaemon/running.markdown b/source/_docs/ecosystem/appdaemon/running.markdown
deleted file mode 100644
index 615ad1d356d..00000000000
--- a/source/_docs/ecosystem/appdaemon/running.markdown
+++ /dev/null
@@ -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 /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
- -e ENDTIME, --endtime ENDTIME
- end time for scheduler
- -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.
diff --git a/source/_docs/ecosystem/appdaemon/tutorial.markdown b/source/_docs/ecosystem/appdaemon/tutorial.markdown
deleted file mode 100644
index c5a81f7fe6a..00000000000
--- a/source/_docs/ecosystem/appdaemon/tutorial.markdown
+++ /dev/null
@@ -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!
-
diff --git a/source/_docs/ecosystem/appdaemon/updating.markdown b/source/_docs/ecosystem/appdaemon/updating.markdown
deleted file mode 100644
index 9f3b1e3b876..00000000000
--- a/source/_docs/ecosystem/appdaemon/updating.markdown
+++ /dev/null
@@ -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.
diff --git a/source/_docs/ecosystem/appdaemon/windows.markdown b/source/_docs/ecosystem/appdaemon/windows.markdown
deleted file mode 100644
index e886ef1529b..00000000000
--- a/source/_docs/ecosystem/appdaemon/windows.markdown
+++ /dev/null
@@ -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.
diff --git a/source/_docs/ecosystem/hadashboard.markdown b/source/_docs/ecosystem/hadashboard.markdown
deleted file mode 100644
index d0d28079e71..00000000000
--- a/source/_docs/ecosystem/hadashboard.markdown
+++ /dev/null
@@ -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.
-
-
-
- Default Theme
-
-
-
-
- Obsidian Theme
-
-
-
-
- Zen Theme
-
-
-
-
- Simply Red Theme
-
-
-
-
- Glassic Theme
-
-
-For full installation instructions see the HADashboard section in the [AppDaemon Project Documentation](http://appdaemon.readthedocs.io/en/stable/DASHBOARD_INSTALL.html).
\ No newline at end of file
diff --git a/source/_docs/installation.markdown b/source/_docs/installation.markdown
index 94f822f7b73..d1219130041 100644
--- a/source/_docs/installation.markdown
+++ b/source/_docs/installation.markdown
@@ -47,7 +47,7 @@ These install options are fully supported by Home Assistant's documentation. For
-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.
@@ -112,10 +112,4 @@ These guides are provided as-is. Some of these install methods are more limited
FreeNAS
-
-
-

-
- Home Assistant Supervised
on generic Linux server
-
diff --git a/source/_docs/installation/docker.markdown b/source/_docs/installation/docker.markdown
index c1754bfc98f..4c32c3dfc26 100644
--- a/source/_docs/installation/docker.markdown
+++ b/source/_docs/installation/docker.markdown
@@ -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/).
-
## Platform Installation
diff --git a/source/_docs/installation/raspberry-pi.markdown b/source/_docs/installation/raspberry-pi.markdown
index b7796158449..4dcb787a92a 100644
--- a/source/_docs/installation/raspberry-pi.markdown
+++ b/source/_docs/installation/raspberry-pi.markdown
@@ -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`.
diff --git a/source/_docs/mqtt/discovery.markdown b/source/_docs/mqtt/discovery.markdown
index a9e7664f548..40fd16e8499 100644
--- a/source/_docs/mqtt/discovery.markdown
+++ b/source/_docs/mqtt/discovery.markdown
@@ -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)
diff --git a/source/_docs/z-wave/device-specific.markdown b/source/_docs/z-wave/device-specific.markdown
index e50db11b4d8..531df1bd806 100644
--- a/source/_docs/z-wave/device-specific.markdown
+++ b/source/_docs/z-wave/device-specific.markdown
@@ -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
+
+
+ On Off Status After Power Failure. Default: all relays restore to previous state
+
+
+
+
+
+
+
+ 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)
+
+
+
+
+
+
+ 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)
+
+
+
+
+
+
+ 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)
+
+
+
+
+
+
+ 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
+
+
+
+
+
+
+ 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)
+
+
+ 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)
+
+
+ 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)
+
+
+ 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)
+
+
+ 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)
+
+
+ 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)
+
+
+ Enable/Disable Manual Control for SW1. Default: enabled
+
+
+
+
+
+ Enable/Disable Manual Control for SW2. Default: enabled
+
+
+
+
+
+ Enable/Disable Manual Control for SW3. Default: enabled
+
+
+
+
+
+ Choose between second, minutes, and hours as the unit for Auto Turn-Off time for Relay 1. Default: minutes
+
+
+
+
+
+ Choose between second, minutes, and hours as the unit for Auto Turn-On time for Relay 1. Default: minutes
+
+
+
+
+
+ Choose between second, minutes, and hours as the unit for Auto Turn-Off time for Relay 2. Default: minutes
+
+
+
+
+
+ Choose between second, minutes, and hours as the unit for Auto Turn-On time for Relay 2. Default: minutes
+
+
+
+
+
+ Choose between second, minutes, and hours as the unit for Auto Turn-Off time for Relay 3. Default: minutes
+
+
+
+
+
+ Choose between second, minutes, and hours as the unit for Auto Turn-On time for Relay 3. Default: minutes
+
+
+
+
+
+```
\ No newline at end of file
diff --git a/source/_includes/asides/docs_navigation.html b/source/_includes/asides/docs_navigation.html
index ae72edaa8de..f3c5b3ba8b5 100644
--- a/source/_includes/asides/docs_navigation.html
+++ b/source/_includes/asides/docs_navigation.html
@@ -261,12 +261,6 @@
{% active_link /docs/autostart/synology/ Synology NAS %}
-
- {% active_link /docs/ecosystem/appdaemon/ AppDaemon %}
-
-
- {% active_link /docs/ecosystem/hadashboard/ HADashboard %}
-
Remote access
diff --git a/source/_integrations/cover.template.markdown b/source/_integrations/cover.template.markdown
index e4c01e0e1d4..852fee2690e 100644
--- a/source/_integrations/cover.template.markdown
+++ b/source/_integrations/cover.template.markdown
@@ -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:
diff --git a/source/_integrations/deconz.markdown b/source/_integrations/deconz.markdown
index e35dcbdd4b2..26e27104d7c 100644
--- a/source/_integrations/deconz.markdown
+++ b/source/_integrations/deconz.markdown
@@ -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.
diff --git a/source/_integrations/frontier_silicon.markdown b/source/_integrations/frontier_silicon.markdown
index 89b1b30ff66..bef63567654 100644
--- a/source/_integrations/frontier_silicon.markdown
+++ b/source/_integrations/frontier_silicon.markdown
@@ -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].
diff --git a/source/_integrations/homekit.markdown b/source/_integrations/homekit.markdown
index dab9f296453..b1bf6012d9e 100644
--- a/source/_integrations/homekit.markdown
+++ b/source/_integrations/homekit.markdown
@@ -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
{% 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)
diff --git a/source/_integrations/lutron_caseta.markdown b/source/_integrations/lutron_caseta.markdown
index 68230f6458a..a109643ca0a 100644
--- a/source/_integrations/lutron_caseta.markdown
+++ b/source/_integrations/lutron_caseta.markdown
@@ -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'
diff --git a/source/_integrations/modbus.markdown b/source/_integrations/modbus.markdown
index ddd70ad94a3..5692e4a753f 100644
--- a/source/_integrations/modbus.markdown
+++ b/source/_integrations/modbus.markdown
@@ -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]` |
diff --git a/source/_integrations/mycroft.markdown b/source/_integrations/mycroft.markdown
index 833a013367b..02e95a70676 100644
--- a/source/_integrations/mycroft.markdown
+++ b/source/_integrations/mycroft.markdown
@@ -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"
+```
diff --git a/source/_integrations/panasonic_viera.markdown b/source/_integrations/panasonic_viera.markdown
index 912e9cc6efe..399ab3f8624 100644
--- a/source/_integrations/panasonic_viera.markdown
+++ b/source/_integrations/panasonic_viera.markdown
@@ -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
diff --git a/source/_integrations/pi4ioe5v9xxxx.markdown b/source/_integrations/pi4ioe5v9xxxx.markdown
index 1e1184c9074..2083a0943b6 100644
--- a/source/_integrations/pi4ioe5v9xxxx.markdown
+++ b/source/_integrations/pi4ioe5v9xxxx.markdown
@@ -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)
diff --git a/source/_integrations/python_script.markdown b/source/_integrations/python_script.markdown
index 3e9312a9619..ae7737083de 100644
--- a/source/_integrations/python_script.markdown
+++ b/source/_integrations/python_script.markdown
@@ -21,15 +21,15 @@ This integration allows you to write Python scripts that are exposed as services
-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/)
## Writing your first script
- - Add to `configuration.yaml`: `python_script:`
- - Create folder `/python_scripts`
- - Create a file `hello_world.py` in the folder and give it this content:
+- Add to `configuration.yaml`: `python_script:`
+- Create folder `/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.
diff --git a/source/_integrations/raincloud.markdown b/source/_integrations/raincloud.markdown
index dcb6b3b5063..c682c0e2170 100644
--- a/source/_integrations/raincloud.markdown
+++ b/source/_integrations/raincloud.markdown
@@ -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
diff --git a/source/_integrations/rejseplanen.markdown b/source/_integrations/rejseplanen.markdown
index 7c41be042f9..8942066bb08 100644
--- a/source/_integrations/rejseplanen.markdown
+++ b/source/_integrations/rejseplanen.markdown
@@ -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
+
+
+
+
+
+
+```
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
+
+
+
+
+
+
```
-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:
diff --git a/source/_integrations/roomba.markdown b/source/_integrations/roomba.markdown
index 64fce7992ca..e49507045db 100644
--- a/source/_integrations/roomba.markdown
+++ b/source/_integrations/roomba.markdown
@@ -21,7 +21,7 @@ The `roomba` integration allows you to control your [iRobot Roomba](https://www.
-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.
## 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
diff --git a/source/_integrations/smtp.markdown b/source/_integrations/smtp.markdown
index e85b8242cba..9d0e3ee7ac5 100644
--- a/source/_integrations/smtp.markdown
+++ b/source/_integrations/smtp.markdown
@@ -181,9 +181,7 @@ The optional `html` field makes a custom text/HTML multi-part message, allowing