Merge branch 'current' into next
This commit is contained in:
Fabian Affolter
commit
eb55a27248
23 changed files with 157 additions and 63 deletions
|
|
@ -17,4 +17,4 @@ The `Mercedes me` platform allows you to get data from your [Mercedes me connect
|
|||
|
||||
They will be automatically discovered if the Mercedes me component is loaded.
|
||||
|
||||
For more configuration information see the [Mercedes me component](/components/mercedes me/) documentation.
|
||||
For more configuration information see the [Mercedes me component](/components/mercedesme/) documentation.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: pre 0.7
|
|||
---
|
||||
|
||||
|
||||
The `history` component will track everything that is going on within Home Assistant and allows the user to browse through it. It depends on the `recorder` component for storing the data and uses the same database setting. If any entities are excluded from being recorded, no history will be available for these entities as well.
|
||||
The `history` component will track everything that is going on within Home Assistant and allows the user to browse through it. It depends on the `recorder` component for storing the data and uses the same database setting. If any entities are excluded from being recorded, no history will be available for these entities.
|
||||
|
||||
To enable the history option in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
@ -42,9 +42,9 @@ Configuration variables:
|
|||
- **entities** (*Optional*): The list of entity ids to be included to the history.
|
||||
- **domains** (*Optional*): The list of domains to be included to the history.
|
||||
|
||||
Without any `include` or `exclude` configuration the history displays graphs for every entity (well that's not exactly true - for instance `hidden` entities or `scenes` are never shown) on a given date. If you are only interested in some of the entities you several options:
|
||||
Without any `include` or `exclude` configuration the history displays graphs for every entity (well that's not exactly true - for instance `hidden` entities or `scenes` are never shown) on a given date. If you are only interested in some of the entities you have several options:
|
||||
|
||||
Define domains and entities to `exclude` (aka. blacklist). This is convenient when you are basically happy with the information displayed, but just want to remove some entities or domains. Usually these are entities/domains which do not change (like `weblink`) or rarely change (`updater` or `automation`).
|
||||
Define domains and entities to `exclude` (aka. blacklist). This is convenient when you are basically happy with the information displayed, but just want to remove some entities or domains. Usually these are entities/domains which do not change (like `weblink`) or rarely change (like `updater` or `automation`).
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry with exclude
|
||||
|
|
@ -59,7 +59,7 @@ history:
|
|||
- sensor.date
|
||||
```
|
||||
|
||||
Define domains and entities to display by using the `include` configuration (aka. whitelist). If you have a lot of entities in your system and your `exclude` lists possibly get very large, it might be better just to define the entities or domains to display.
|
||||
Define domains and entities to display by using the `include` configuration (aka. whitelist). If you have a lot of entities in your system and your `exclude` list is getting too large, it might be better just to define the entities or domains to `include`.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry with include
|
||||
|
|
@ -104,7 +104,7 @@ history:
|
|||
|
||||
#### {% linkable_title Implementation details %}
|
||||
|
||||
The history is stored in a SQLite database `home-assistant_v2.db` within your configuration directory if the `recorder` component is not set up differently.
|
||||
The history is stored in a SQLite database `home-assistant_v2.db` within your configuration directory unless the `recorder` component is set up differently.
|
||||
|
||||
- events table is all events except `time_changed` that happened while recorder component was running.
|
||||
- states table contains all the `new_state` values of `state_changed` events.
|
||||
|
|
@ -129,4 +129,4 @@ datetime.fromtimestamp(1422830502)
|
|||
|
||||
#### {% linkable_title API %}
|
||||
|
||||
The history information are also available through the [RESTful API](/developers/rest_api/#get-apihistory).
|
||||
The history information is also available through the [RESTful API](/developers/rest_api/#get-apihistory).
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ redirect_from: /components/input_slider/
|
|||
---
|
||||
|
||||
<p class='note'>
|
||||
Before version 0.55 this component was known as `input_slider` and did not have the `mode` configuration option.
|
||||
Before version 0.55 this component was known as `input_slider` and did not have the `mode` configuration option. Also, service `select_value` is now `set_value`.
|
||||
</p>
|
||||
|
||||
The `input_number` component allows the user to define values that can be controlled via the frontend and can be used within conditions of automation. The frontend can display a slider, or a numeric input box. Changes to the slider or numeric input box generate state events. These state events can be utilized as `automation` triggers as well.
|
||||
|
|
@ -39,7 +39,6 @@ input_number:
|
|||
mode: box
|
||||
```
|
||||
|
||||
|
||||
{% configuration %}
|
||||
input_number:
|
||||
description: Alias for the input. Multiple entries are allowed.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ ha_category: Automation
|
|||
ha_release: 0.53
|
||||
---
|
||||
|
||||
The `input_text` component allows the user to define values that can be controlled via the frontend and can be used within conditions of automation. Changes to the value stored in the text box generate state events. These state events can be utilized as `automation` triggers as well.
|
||||
The `input_text` component allows the user to define values that can be controlled via the frontend and can be used within conditions of automation. Changes to the value stored in the text box generate state events. These state events can be utilized as `automation` triggers as well. It can also be configured in password mode (obscured text).
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entries
|
||||
|
|
@ -27,6 +27,9 @@ input_text:
|
|||
text3:
|
||||
name: Text 3
|
||||
pattern: '[a-fA-F0-9]*'
|
||||
text4:
|
||||
name: Text 4
|
||||
mode: password
|
||||
```
|
||||
|
||||
{% configuration %}
|
||||
|
|
@ -59,6 +62,11 @@ input_text:
|
|||
required: false
|
||||
type: String
|
||||
default: empty
|
||||
mode:
|
||||
description: Can specify `text` or `password`. Elements of type "password" provide a way for the user to securely enter a value.
|
||||
required: false
|
||||
type: String
|
||||
default: text
|
||||
{% endconfiguration %}
|
||||
|
||||
### {% linkable_title Restore State %}
|
||||
|
|
|
|||
|
|
@ -47,10 +47,12 @@ Notice that all parameters are optional, and discovery should configure everythi
|
|||
|
||||
The component has been developed for Portuguese TV operators currently using the Mediaroom platform, but should also work in other deployments in which the STB can be controlled remotely through a socket on port 8082.
|
||||
|
||||
In most cases (single STB) you just need to setup the *name* and discovery will do the rest. In case you have more than one STB you are required to set the *host* in each one of the entries.
|
||||
In most cases (single STB) you just need to setup the *platform* and discovery will do the rest. In case you have more than one STB you are required to set the *host* in each one of the entries.
|
||||
|
||||
If the STB is on the same network segment as Home Assistant, it can determine whether the device is turned on or off. Without this, the component will fail to determine the Set-top box status, and you are required to add the *optimistic* configuration variable.
|
||||
|
||||
## {% linkable_title Examples %}
|
||||
|
||||
### {% linkable_title Example `press_button` script %}
|
||||
|
||||
The `play_media` function can be used in scripts to change channels.
|
||||
|
|
@ -65,4 +67,16 @@ press_button:
|
|||
entity_id: media_player.mediaroom_stb
|
||||
media_content_id: "{{ value }}"
|
||||
media_content_type: "channel"
|
||||
|
||||
### {% linkable_title Example configuration with 2 STB %}
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry for 2 STB
|
||||
media_player:
|
||||
- platform: mediaroom
|
||||
host: 192.168.1.64
|
||||
name: Living Room STB
|
||||
- platform: mediaroom
|
||||
host: 192.168.1.65
|
||||
name: Bedroom STB
|
||||
```
|
||||
|
|
|
|||
|
|
@ -48,4 +48,8 @@ scan_interval:
|
|||
required: true
|
||||
default: 30
|
||||
type: int
|
||||
{% endconfiguration %}
|
||||
{% endconfiguration %}
|
||||
|
||||
<p class='note'>
|
||||
The requirement `lxml` has to be [installed](http://lxml.de/installation.html) manually `pip install lxml` on some devices.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -90,6 +90,12 @@ SELECT * FROM states WHERE entity_id='binary_sensor.xyz789' GROUP BY state ORDER
|
|||
|
||||
### {% linkable_title Database size in Postgres %}
|
||||
|
||||
```sql
|
||||
SELECT pg_size_pretty(pg_database_size('Database Name'));
|
||||
```yaml
|
||||
- platform: sql
|
||||
db_url: postgresql://user:password@host/dbname
|
||||
queries:
|
||||
- name: db_size
|
||||
query: "SELECT (pg_database_size('dsmrreader')/1024/1024) as db_size;"
|
||||
column: "db_size"
|
||||
unit_of_measurement: MB
|
||||
```
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ ha_release: 0.14
|
|||
|
||||
The Steam component will allow you to track the online status of public [Steam](https://steamcommunity.com) accounts.
|
||||
|
||||
You need an API key which is [free](https://steamcommunity.com/dev/apikey) to use the component
|
||||
You need a [free API key](https://steamcommunity.com/dev/apikey) to use the component
|
||||
|
||||
To find an account's 64-bit SteamID you can check the URL of the profile page, if it ends with a long string on numbers then that's the 64-bit SteamID. However, if the profile has a custom URL you will have to copy the it and enter it into [STEAMID I/O](https://steamid.io/) to find the 64-bit SteamID.
|
||||
To find an account's 64-bit SteamID on profiles without a custom URL you can check the URL of the profile page, the long string of numbers at the end is the 64-bit SteamID. If the profile has a custom URL you will have to copy the URL into [STEAMID I/O](https://steamid.io/) to find the 64-bit SteamID.
|
||||
|
||||
To use Steam in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -60,15 +60,6 @@ The table contains types and their argument to use in your `configuration.yaml`
|
|||
| last_boot | |
|
||||
| since_last_boot | |
|
||||
|
||||
**Note**: Some `type:` names used in the `configuration.yaml` file differ from the entity names.
|
||||
|
||||
| Sensor type | Entity ID |
|
||||
| :------------------ |:-------------------------|
|
||||
| memory_free | sensor.ram_available |
|
||||
| memory_use_percent | sensor.ram_used |
|
||||
| processor_use | sensor.cpu_used |
|
||||
| disk_use | sensor.disk_used |
|
||||
|
||||
## {% linkable_title Linux specific %}
|
||||
|
||||
To retrieve all available network interfaces on a Linux System, execute the `ifconfig` command.
|
||||
|
|
|
|||
|
|
@ -32,10 +32,13 @@ Configuration variables:
|
|||
- **ports** array (*Required*): Array of used ports.
|
||||
- **port: name** (*Required*): Port numbers and corresponding names (GPIO #).
|
||||
- **invert_logic** (*Optional*): If true, inverts the output logic to ACTIVE LOW. Default is false (ACTIVE HIGH).
|
||||
- **shared_gpio** (*Optional*): If true, forces a GPIO.setup() before each write. Default is false.
|
||||
|
||||
For more details about the GPIO layout, visit the Wikipedia [article](https://en.wikipedia.org/wiki/Raspberry_Pi#GPIO_connector) about the Raspberry Pi.
|
||||
|
||||
<p class='note warning'>
|
||||
Note that a pin managed by HASS is expected to be exclusive to HASS.
|
||||
</p>
|
||||
|
||||
A common question is what does Port refer to, this number is the actual GPIO # not the pin #.
|
||||
For example, if you have a relay connected to pin 11 its GPIO # is 17.
|
||||
|
||||
|
|
@ -47,14 +50,4 @@ switch:
|
|||
17: Speaker Relay
|
||||
```
|
||||
|
||||
In case you have any other python scripts running that use RPi.GPIO no values will be written after the initial HASS-start.
|
||||
Setting **shared_gpio** to true will reinit the pin before each write, working around this issue.
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
switch:
|
||||
- platform: rpi_gpio
|
||||
shared_gpio: true
|
||||
ports:
|
||||
19: LED-Red
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue