Misc fixes: e.g. -> e.g., and proper case for Home Assistant (#4942)
* e.g. to e.g., and proper case for Home Assistant * Instructions how to -> Instructions on how to
This commit is contained in:
Alok Saboo
Franck Nijhof
parent
3fd5cd5f94
commit
1aca7b08cf
764 changed files with 883 additions and 885 deletions
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Asterisk Voicemail Server Installation"
|
||||
description: "Instructions how to integrate your existing Asterisk voicemail within Home Assistant."
|
||||
description: "Instructions on how to integrate your existing Asterisk voicemail within Home Assistant."
|
||||
date: 2017-06-30 18:30
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Autostart Home Assistant"
|
||||
description: "Instructions how to setup Home Assistant to launch on start."
|
||||
description: "Instructions on how to setup Home Assistant to launch on start."
|
||||
date: 2015-9-1 22:57
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Autostart on macOS"
|
||||
description: "Instructions how to setup Home Assistant to launch on Apple macOS."
|
||||
description: "Instructions on how to setup Home Assistant to launch on Apple macOS."
|
||||
date: 2015-9-1 22:57
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Autostart on Synology NAS boot"
|
||||
description: "Instructions how to setup Home Assistant to launch on boot on Synology NAS."
|
||||
description: "Instructions on how to setup Home Assistant to launch on boot on Synology NAS."
|
||||
date: 2015-9-1 22:57
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Autostart using systemd"
|
||||
description: "Instructions how to setup Home Assistant to launch on boot using systemd."
|
||||
description: "Instructions on how to setup Home Assistant to launch on boot using systemd."
|
||||
date: 2015-9-1 22:57
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Autostart using Upstart"
|
||||
description: "Instructions how to setup Home Assistant to launch on boot using Upstart."
|
||||
description: "Instructions on how to setup Home Assistant to launch on boot using Upstart."
|
||||
date: 2015-9-1 22:57
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Group Visibility"
|
||||
description: "Instructions how to change group visibility using automations."
|
||||
description: "Instructions on how to change group visibility using automations."
|
||||
date: 2016-10-29 13:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ light:
|
|||
|
||||
There are some rules for packages that will be merged:
|
||||
|
||||
1. Component names may only use the basic form (e.g. `switch`, but not `switch 1` or `switch aa`).
|
||||
1. Component names may only use the basic form (e.g., `switch`, but not `switch 1` or `switch aa`).
|
||||
2. Platform based components (`light`, `switch`, etc) can always be merged.
|
||||
3. Components where entities are identified by a key that will represent the entity_id (`{key: config}`) need to have unique 'keys' between packages and the main configuration file.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Securing"
|
||||
description: "Instructions how to secure your Home Assistant installation."
|
||||
description: "Instructions on how to secure your Home Assistant installation."
|
||||
date: 2016-10-06 06:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Templating"
|
||||
description: "Instructions how to use the templating feature of Home Assistant."
|
||||
description: "Instructions on how to use the templating feature of Home Assistant."
|
||||
date: 2015-12-12 12:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ There are several circumstances under which `initialize()` might be called:
|
|||
- 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).
|
||||
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:
|
||||
|
||||
|
|
@ -150,7 +150,7 @@ light = light.garage
|
|||
|
||||
## {% linkable_title 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.
|
||||
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.
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ constrain_input_boolean = input_boolean.enable_motion_detection,off
|
|||
```
|
||||
|
||||
### {% linkable_title 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.
|
||||
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
|
||||
|
|
@ -272,7 +272,7 @@ Any other attributes such as brightness for a lamp will only be present if the e
|
|||
|
||||
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.
|
||||
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.
|
||||
|
||||
### {% linkable_title get_state() %}
|
||||
|
||||
|
|
@ -294,9 +294,9 @@ All parameters are optional, and if `get_state()` is called with no parameters i
|
|||
|
||||
##### {% linkable_title 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
##### {% linkable_title attribute %}
|
||||
|
||||
|
|
@ -345,11 +345,11 @@ set_state(entity_id, **kwargs)
|
|||
|
||||
##### {% linkable_title entity_id %}
|
||||
|
||||
Entity id for which the state is to be set, e.g. `light.office_1`.
|
||||
Entity id for which the state is to be set, e.g., `light.office_1`.
|
||||
|
||||
##### {% linkable_title 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.
|
||||
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.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
|
@ -461,7 +461,7 @@ handle = listen_state(callback, entity = None, **kwargs)
|
|||
|
||||
#### {% linkable_title 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`.
|
||||
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`.
|
||||
|
||||
#### {% linkable_title Parameters %}
|
||||
|
||||
|
|
@ -473,9 +473,9 @@ Function to be invoked when the requested state change occurs. It must conform t
|
|||
|
||||
##### {% linkable_title 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
##### {% linkable_title attribute (optional) %}
|
||||
|
||||
|
|
@ -949,11 +949,11 @@ All of the scheduler calls above support 2 additional optional arguments, `rando
|
|||
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
|
||||
# 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
|
||||
# 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
|
||||
# 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)
|
||||
```
|
||||
|
||||
|
|
@ -1150,11 +1150,11 @@ None
|
|||
|
||||
##### {% linkable_title service %}
|
||||
|
||||
The service name, e.g. `light.turn_on`.
|
||||
The service name, e.g., `light.turn_on`.
|
||||
|
||||
##### {% linkable_title \*\*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.
|
||||
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.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
|
@ -1187,7 +1187,7 @@ None
|
|||
|
||||
##### {% linkable_title entity_id %}
|
||||
|
||||
Fully qualified entity_id of the thing to be turned on, e.g. `light.office_lamp` or ```scene.downstairs_on```
|
||||
Fully qualified entity_id of the thing to be turned on, e.g., `light.office_lamp` or ```scene.downstairs_on```
|
||||
|
||||
##### {% linkable_title \*\*kwargs %}
|
||||
|
||||
|
|
@ -1219,7 +1219,7 @@ None
|
|||
|
||||
##### {% linkable_title entity_id %}
|
||||
|
||||
Fully qualified entity_id of the thing to be turned off, e.g. `light.office_lamp` or `scene.downstairs_on`.
|
||||
Fully qualified entity_id of the thing to be turned off, e.g., `light.office_lamp` or `scene.downstairs_on`.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
|
@ -1246,7 +1246,7 @@ None
|
|||
|
||||
##### {% linkable_title entity_id %}
|
||||
|
||||
Fully qualified entity_id of the thing to be toggled, e.g. `light.office_lamp` or `scene.downstairs_on`.
|
||||
Fully qualified entity_id of the thing to be toggled, e.g., `light.office_lamp` or `scene.downstairs_on`.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
|
@ -1273,7 +1273,7 @@ None
|
|||
|
||||
##### {% linkable_title entity_id %}
|
||||
|
||||
Fully qualified entity_id of the input_number to be changed, e.g. `input_number.alarm_hour`.
|
||||
Fully qualified entity_id of the input_number to be changed, e.g., `input_number.alarm_hour`.
|
||||
|
||||
##### {% linkable_title value %}
|
||||
|
||||
|
|
@ -1303,7 +1303,7 @@ None
|
|||
|
||||
##### {% linkable_title entity_id %}
|
||||
|
||||
Fully qualified entity_id of the input_select to be changed, e.g. `input_select.mode`.
|
||||
Fully qualified entity_id of the input_select to be changed, e.g., `input_select.mode`.
|
||||
|
||||
##### {% linkable_title value %}
|
||||
|
||||
|
|
@ -1385,7 +1385,7 @@ A standard Python object reference.
|
|||
|
||||
#### {% linkable_title event_name %}
|
||||
|
||||
Name of the event that was called, e.g. `call_service`.
|
||||
Name of the event that was called, e.g., `call_service`.
|
||||
|
||||
#### {% linkable_title data %}
|
||||
|
||||
|
|
@ -1528,7 +1528,7 @@ def service(self, event_name, data):
|
|||
|
||||
#### {% linkable_title event_name %}
|
||||
|
||||
The name of the event that caused the callback, e.g. `"MODE_CHANGE"` or `call_service`.
|
||||
The name of the event that caused the callback, e.g., `"MODE_CHANGE"` or `call_service`.
|
||||
|
||||
#### {% linkable_title data %}
|
||||
|
||||
|
|
@ -1617,7 +1617,7 @@ A string representing the location of the tracker.
|
|||
|
||||
##### {% linkable_title tracker_id %}
|
||||
|
||||
Fully qualified entity_id of the device tracker to query, e.g. `device_tracker.andrew`.
|
||||
Fully qualified entity_id of the device tracker to query, e.g., `device_tracker.andrew`.
|
||||
|
||||
#### {% linkable_title Examples %}
|
||||
|
||||
|
|
@ -1871,7 +1871,7 @@ self.log("{} ({}) is {}".format(tracker, self.friendly_name(tracker), self.get_
|
|||
|
||||
### {% linkable_title 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`.
|
||||
`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`.
|
||||
|
||||
#### {% linkable_title Synopsis %}
|
||||
|
||||
|
|
@ -1925,7 +1925,7 @@ MyApp.turn_light_on()
|
|||
|
||||
### {% linkable_title 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.
|
||||
`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.
|
||||
|
||||
#### {% linkable_title Synopsis %}
|
||||
|
||||
|
|
@ -1941,7 +1941,7 @@ A list of split devices with 1 or more entries.
|
|||
|
||||
```python
|
||||
for sensor in self.split_device_list(self.args["sensors"]):
|
||||
do something for each sensor, e.g. make a state subscription
|
||||
do something for each sensor, e.g., make a state subscription
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations
|
|||
|
||||
- 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 config file
|
||||
- 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 config 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
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Configuration Backup to Dropbox"
|
||||
description: "Instructions how backup your Home Assistant configuration to Dropbox"
|
||||
description: "Instructions on how backup your Home Assistant configuration to Dropbox"
|
||||
date: 2017-04-24 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Configuration Backup to GitHub"
|
||||
description: "Instructions how backup your Home Assistant configuration to GitHub"
|
||||
description: "Instructions on how backup your Home Assistant configuration to GitHub"
|
||||
date: 2017-01-05 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Configuration Backup to USB drive"
|
||||
description: "Instructions how backup your Home Assistant configuration to USB drive"
|
||||
description: "Instructions on how backup your Home Assistant configuration to USB drive"
|
||||
date: 2017-04-29 08:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ There are no dependencies on Python modules that are not part of the standard li
|
|||
|
||||
### {% linkable_title Configuration %}
|
||||
Near the top of the `configurator.py`-file you will find some global variables you can change to customize the configurator. If you are unfamiliar with Python: when setting variables of the type _string_, you have to write that within quotation marks. The default settings are fine for just checking out the configurator quickly. With more customized setups you should change some settings though.
|
||||
To keep your settings across updates it is also possible to save settings in an external file. In that case copy [settings.conf](https://github.com/danielperna84/hass-configurator/blob/master/settings.conf) wherever you like and append the full path to the file to the command when starting the configurator. E.g. `sudo .configurator.py /home/homeassistant/.homeassistant/mysettings.conf`. This file is in JSON format. So make sure it has a valid syntax (you can set the editor to JSON to get syntax highlighting for the settings). The major difference to the settings in the py-file is, that `None` becomes `null`.
|
||||
To keep your settings across updates it is also possible to save settings in an external file. In that case copy [settings.conf](https://github.com/danielperna84/hass-configurator/blob/master/settings.conf) wherever you like and append the full path to the file to the command when starting the configurator. e.g., `sudo .configurator.py /home/homeassistant/.homeassistant/mysettings.conf`. This file is in JSON format. So make sure it has a valid syntax (you can set the editor to JSON to get syntax highlighting for the settings). The major difference to the settings in the py-file is, that `None` becomes `null`.
|
||||
|
||||
#### LISTENIP (string)
|
||||
The IP the service is listening on. By default it is binding to `0.0.0.0`, which is every interface on the system.
|
||||
|
|
@ -66,11 +66,11 @@ Set credentials in the form of `"username:password"` if authentication should be
|
|||
#### ALLOWED_NETWORKS (list)
|
||||
Limit access to the configurator by adding allowed IP addresses / networks to the list, e.g `ALLOWED_NETWORKS = ["192.168.0.0/24", "172.16.47.23"]`
|
||||
#### BANNED_IPS (list)
|
||||
List of statically banned IP addresses, e.g. `BANNED_IPS = ["1.1.1.1", "2.2.2.2"]`
|
||||
List of statically banned IP addresses, e.g., `BANNED_IPS = ["1.1.1.1", "2.2.2.2"]`
|
||||
#### BANLIMIT (integer)
|
||||
Ban IPs after `n` failed login attempts. Restart the service to reset banning. The default of `0` disables this feature. `CREDENTIALS` has to be set for this to work.
|
||||
#### IGNORE_PATTERN (list)
|
||||
Files and folders to ignore in the UI, e.g. `IGNORE_PATTERN = [".*", "*.log", "__pycache__"]`.
|
||||
Files and folders to ignore in the UI, e.g., `IGNORE_PATTERN = [".*", "*.log", "__pycache__"]`.
|
||||
#### DIRSFIRST (bool)
|
||||
If set to `True`, directories will be displayed at the top of the filebrowser.
|
||||
#### GIT (bool)
|
||||
|
|
@ -81,7 +81,7 @@ __Note regarding `ALLOWED_NETWORKS`, `BANNED_IPS` and `BANLIMIT`__:
|
|||
The way this is implemented works in the following order:
|
||||
|
||||
1. (Only if `CREDENTIALS` is set) Check credentials
|
||||
- Failure: Retry `BANLIMIT` times, after that return error 420 (unless you try again without any authentication headers set, e.g. private tab of your browser)
|
||||
- Failure: Retry `BANLIMIT` times, after that return error 420 (unless you try again without any authentication headers set, e.g., private tab of your browser)
|
||||
- Success: Continue
|
||||
2. Check if client IP address is in `BANNED_IPS`
|
||||
- Yes: Return error 420
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Synology"
|
||||
description: "Instructions how to get Home Assistant up and running on Synology"
|
||||
description: "Instructions on how to get Home Assistant up and running on Synology"
|
||||
release_date: 2016-12-07 15:00:00 -0500
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Installation of Home Assistant"
|
||||
description: "Instructions how to install Home Assistant to launch on start."
|
||||
description: "Instructions on how to install Home Assistant to launch on start."
|
||||
date: 2017-02-15 08:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ The steps would be:
|
|||
* Wait for some time until your NAS has pulled the image
|
||||
* Move to the "Image"-section of the Docker-app
|
||||
* Click on "Launch"
|
||||
* Choose a container-name you want (e.g. "homeassistant")
|
||||
* Choose a container-name you want (e.g., "homeassistant")
|
||||
* Click on "Advanced Settings"
|
||||
* Set "Enable auto-restart" if you like
|
||||
* Within "Volume" click on "Add Folder" and choose either an existing folder or add a new folder. The "mount point" has to be "/config", so that Home Assistant will use it for the configs and logs.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Common tasks on Hassbian"
|
||||
description: "Instructions how to do common tasks on Hassbian."
|
||||
description: "Instructions on how to do common tasks on Hassbian."
|
||||
date: 2016-09-26 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Upgrading Hassbian"
|
||||
description: "Instructions how to upgrade Hassbian to the latest version."
|
||||
description: "Instructions on how to upgrade Hassbian to the latest version."
|
||||
date: 2016-09-26 21:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Create homeassistant config directory & switch to it
|
|||
# chmod 755 /volume1/homeassistant
|
||||
# cd /volume1/homeassistant
|
||||
```
|
||||
Hint: alternatively you can also create a "Shared Folder" via Synology WebUI (e.g. via "File Station") - this has the advantage that the folder is visible via "File Station".
|
||||
Hint: alternatively you can also create a "Shared Folder" via Synology WebUI (e.g., via "File Station") - this has the advantage that the folder is visible via "File Station".
|
||||
|
||||
Create hass-daemon file using the following code (edit the variables in uppercase if necessary)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Birth and Last will"
|
||||
description: "Instructions how to setup MQTT birth and last will messages within Home Assistant."
|
||||
description: "Instructions on how to setup MQTT birth and last will messages within Home Assistant."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Brokers"
|
||||
description: "Instructions how to setup MQTT brokers for Home Assistant."
|
||||
description: "Instructions on how to setup MQTT brokers for Home Assistant."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -62,7 +62,7 @@ mqtt:
|
|||
{% configuration %}
|
||||
broker:
|
||||
required: false
|
||||
description: The IP address or hostname of your MQTT broker, e.g. 192.168.1.32.
|
||||
description: The IP address or hostname of your MQTT broker, e.g., 192.168.1.32.
|
||||
type: string
|
||||
port:
|
||||
required: false
|
||||
|
|
@ -109,7 +109,7 @@ If you get this error `AttributeError: module 'ssl' has no attribute 'PROTOCOL_T
|
|||
</p>
|
||||
|
||||
<p class='note'>
|
||||
If you are running a Mosquitto instance on the same server as Home Assistant then you must ensure that the Mosquitto service starts before Home Assistant. For a Linux instance running Systemd (Raspberry Pi, Debian, Ubuntu and others) then you should edit the file /etc/systemd/system/home-assistant@homeassistant.service as root (e.g. sudo nano /etc/systemd/system/home-assistant@homeassistant.service) and add the mosquitto service:
|
||||
If you are running a Mosquitto instance on the same server as Home Assistant then you must ensure that the Mosquitto service starts before Home Assistant. For a Linux instance running Systemd (Raspberry Pi, Debian, Ubuntu and others) then you should edit the file /etc/systemd/system/home-assistant@homeassistant.service as root (e.g., sudo nano /etc/systemd/system/home-assistant@homeassistant.service) and add the mosquitto service:
|
||||
```
|
||||
[Unit]
|
||||
Description=Home Assistant
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Certificate"
|
||||
description: "Instructions how to setup MQTT with a certificate in Home Assistant."
|
||||
description: "Instructions on how to setup MQTT with a certificate in Home Assistant."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Discovery"
|
||||
description: "Instructions how to setup MQTT Discovery within Home Assistant."
|
||||
description: "Instructions on how to setup MQTT Discovery within Home Assistant."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Logging"
|
||||
description: "Instructions how to setup MQTT Logging within Home Assistant."
|
||||
description: "Instructions on how to setup MQTT Logging within Home Assistant."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Processing JSON"
|
||||
description: "Instructions how to process the MQTT payload."
|
||||
description: "Instructions on how to process the MQTT payload."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Publish service"
|
||||
description: "Instructions how to setup the MQTT Publish service within Home Assistant."
|
||||
description: "Instructions on how to setup the MQTT Publish service within Home Assistant."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "MQTT Testing"
|
||||
description: "Instructions how to test your MQTT setup."
|
||||
description: "Instructions on how to test your MQTT setup."
|
||||
date: 2015-08-07 18:00
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ It is also possible to use dummy variables, e.g., in scripts, when using `wait_t
|
|||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# Service call, e.g. from an automation.
|
||||
# Service call, e.g., from an automation.
|
||||
service: script.do_something
|
||||
data_template:
|
||||
dummy: "{{ input_boolean.switch }}"
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Service Calls"
|
||||
description: "Instructions how to call services in Home Assistant."
|
||||
description: "Instructions on how to call services in Home Assistant."
|
||||
date: 2016-03-12 12:00 -0800
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ Or, if there is no result, try to find detailed USB connection info with:
|
|||
$ dmesg | grep USB
|
||||
```
|
||||
|
||||
If Home Assistant (`hass`) runs with another user (e.g. *homeassistant* on Hassbian) give access to the stick with:
|
||||
If Home Assistant (`hass`) runs with another user (e.g., *homeassistant* on Hassbian) give access to the stick with:
|
||||
|
||||
```bash
|
||||
$ sudo usermod -a -G dialout homeassistant
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The `zwave` component exposes multiple services to help maintain the network. Al
|
|||
| remove_failed_node | Remove a failed node from the network. The Node should be on the controller's Failed Node List, otherwise this command will fail. |
|
||||
| replace_failed_node | Replace a failed device with another. If the node is not in the controller's Failed Node List, or the node responds, this command will fail. |
|
||||
| reset_node_meters | Reset a node's meter values. Only works if the node supports this. |
|
||||
| set_config_parameter | Lets the user set a config parameter to a node. NOTE: Use the parameter option's `label` string as the `value` for list parameters (e.g. `"value": "Off"`). For all other parameters use the relevant integer `value` (e.g. `"value": 1`). |
|
||||
| set_config_parameter | Lets the user set a config parameter to a node. NOTE: Use the parameter option's `label` string as the `value` for list parameters (e.g., `"value": "Off"`). For all other parameters use the relevant integer `value` (e.g., `"value": 1`). |
|
||||
| soft_reset | Tells the controller to do a "soft reset." This is not supposed to lose any data, but different controllers can behave differently to a "soft reset" command. |
|
||||
| start_network | Starts the Z-Wave network. |
|
||||
| stop_network | Stops the Z-Wave network. |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue