Merge branch 'current' into next
This commit is contained in:
Fabian Affolter
commit
73ed694fed
40 changed files with 313 additions and 230 deletions
|
|
@ -290,7 +290,7 @@ First create a file called `alexa_confirm.yaml` with something like the followin
|
|||
] | random }} {% endraw %}
|
||||
```
|
||||
|
||||
Then, wherever you would but some simple text for a response like`OK`, replace it with a reference to the file so that:
|
||||
Then, wherever you would put some simple text for a response like `OK`, replace it with a reference to the file so that:
|
||||
|
||||
```
|
||||
text: OK
|
||||
|
|
|
|||
|
|
@ -20,11 +20,12 @@ To set it up, add the following information to your `configuration.yaml` file:
|
|||
climate:
|
||||
platform: honeywell
|
||||
username: YOUR_USERNAME
|
||||
password: YOUR_PASSWORD
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **username** (*Required*: The username of an user with access.
|
||||
- **username** (*Required*): The username of an user with access.
|
||||
- **password** (*Required*): The password for your given admin account.
|
||||
- **away_temperature** (*optional*): Heating setpoint when away mode is on. If omitted it defaults to 16.0 deg C.
|
||||
- **region** (*optional*): Region identifier (either 'eu' or 'us'). Defaults to 'eu' if not provided.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: page
|
||||
title: "Radiotherm Thermostat"
|
||||
description: "Instructions how to integrate Radiotherm thermostats within Home Assistant."
|
||||
title: "Radio Thermostat (3M Filtrete) Thermostat"
|
||||
description: "Instructions how to integrate Radio Thermostat (3M Filtrete) thermostats within Home Assistant."
|
||||
date: 2015-10-18 17:15
|
||||
sidebar: true
|
||||
comments: false
|
||||
|
|
@ -12,7 +12,7 @@ ha_category: Climate
|
|||
---
|
||||
|
||||
|
||||
The `radiotherm` climate platform let you control a thermostat from [Radio Thermostat](http://www.radiothermostat.com/).
|
||||
The `radiotherm` climate platform let you control a thermostat from [Radio Thermostat](http://www.radiothermostat.com/) or [3M Filtrete](http://www.radiothermostat.com/filtrete/products/). Your thermostat must have the Wi-Fi module installed and connected to your network.
|
||||
|
||||
The underlying library supports:
|
||||
|
||||
|
|
@ -32,11 +32,15 @@ climate:
|
|||
Configuration variables:
|
||||
|
||||
- **host** (*Optional*): List of your Radiotherm thermostats. If not provided the thermostats will be auto-detected.
|
||||
- **away_temperature_heat** (*Optional*): Target heating temperature in Fahrenheit for away mode. This is separate from away mode in the app. Defaults to '60'.
|
||||
- **away_temperature_cool** (*Optional*): Target cooling temperature in Fahrenheit for away mode. This is separate from away mode in the app. Defaults to '85'.
|
||||
- **hold_temp** (*Optional*): Boolean to control if Home Assistant temperature adjustments hold (`True`) or are temporary (`False`). Defaults to `False`.
|
||||
|
||||
Temperature settings from Home Assistant will be sent to thermostat and then hold at that temperature. Set to `False` if you set a thermostat schedule on the thermostat itself and just want Home Assistant to send temporary temperature changes.
|
||||
Set `hold_temp: True` if you want temperature settings from Home Assistant to override a thermostat schedule on the thermostat itself. Otherwise Home Assistant will perform temporary temperature changes.
|
||||
|
||||
Multiple thermostats could be assigned by using `host:` if auto-detection is not used.
|
||||
The away mode functions similarly to the away mode feature of the website and apps, but cannot detect if you set away mode outside of Home Assistant.
|
||||
|
||||
Multiple thermostats can be assigned by using `host:` if auto-detection is not used.
|
||||
|
||||
```yaml
|
||||
climate:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ This tracker discovers new devices on boot and in regular intervals and tracks b
|
|||
Devices discovered are stored with 'BLE_' as the prefix for device mac addresses in `known_devices.yaml`.
|
||||
|
||||
<p class='note'>
|
||||
Requires PyBluez. If you are on Raspbian, make sure you first install `bluetooth` and `libbluetooth-dev` by running `sudo apt install bluetooth libbluetooth-dev`
|
||||
Requires PyBluez. If you are on Raspbian, run the following command to install the needed dependencies. `sudo apt install bluetooth libbluetooth-dev pkg-config libboost-python-dev libboost-thread-dev libglib2.0-dev python-dev`
|
||||
</p>
|
||||
|
||||
<p class='note warning'>
|
||||
|
|
|
|||
|
|
@ -34,4 +34,4 @@ To configure Locative, you must set up the app to send a `GET` request to your H
|
|||
|
||||
When you enter a geofence, your location name in Home Assistant will be set to the name of the geofence in Locative. When you exit a geofence, your location name in Home Assistant will be set to "not home".
|
||||
|
||||
To use Locative in combination with another device tracker, such as [nmap](/components/device_tracker.nmap_scanner/) or [Netgear](/components/device_tracker.netgear/), fill in the `mac` field to the Locative entry in `known_devices.yaml` with the MAC address of the device you want to track. The state of the device will be determined by the source that reported last.
|
||||
To use Locative in combination with another device tracker, such as [nmap](/components/device_tracker.nmap_tracker/) or [Netgear](/components/device_tracker.netgear/), fill in the `mac` field to the Locative entry in `known_devices.yaml` with the MAC address of the device you want to track. The state of the device will be determined by the source that reported last.
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ device_tracker:
|
|||
track_new_devices: yes
|
||||
```
|
||||
|
||||
Multiple device trackers can be used in parallel, such as [Owntracks](/components/device_tracker.owntracks/) and [Nmap](/components/device_tracker.nmap_tracker/). The state of the device will be determined by the source that reported last.
|
||||
Multiple device trackers can be used in parallel, such as [Owntracks](/components/device_tracker.owntracks/#using-owntracks-with-other-device-trackers) and [Nmap](/components/device_tracker.nmap_tracker/). The state of the device will be determined by the source that reported last.
|
||||
|
||||
# {% linkable_title `known_devices.yaml` %}
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Configuration variables:
|
|||
|
||||
- **max_gps_accuracy** (*Optional*): Sometimes Owntracks can report GPS location with a very low accuracy (few kilometers). That can trigger false zoning in your Home Assistant installation. With the parameter, you can filter these GPS reports. The number has to be in meter. For example, if you put 200 only GPS report with an accuracy under 200 will be take in account.
|
||||
- **waypoints** (*Optional*): Owntracks users can define [waypoints](http://owntracks.org/booklet/features/waypoints/) (a.k.a regions) which are similar in spirit to Home Assistant zones. If this configuration variable is `True`, the Owntracks users who are in `waypoint_whitelist` can export waypoints from the device and Home Assistant will import them as zone definitions. Defaults to `True`.
|
||||
- **waypoint_whitelist** (*Optional*): A list of user names (as defined for [Owntracks](https://home-assistant.io/components/device_tracker.owntracks/)) who can export their waypoints from Owntracks to Home Assistant. Defaults to all users who are connected to Home Assistant via Owntracks.
|
||||
- **waypoint_whitelist** (*Optional*): A list of user names (as defined for [Owntracks](/components/device_tracker.owntracks/)) who can export their waypoints from Owntracks to Home Assistant. Defaults to all users who are connected to Home Assistant via Owntracks.
|
||||
|
||||
A full sample configuration for the `owntracks` platform is shown below:
|
||||
|
||||
|
|
@ -46,7 +46,19 @@ device_tracker:
|
|||
```
|
||||
|
||||
### {% linkable_title Using Owntracks with other device trackers %}
|
||||
Owntracks can also be used with other device trackers, such as [Nmap](/components/device_tracker.nmap_scanner/) or [Netgear](/components/device_tracker.netgear/). To do this, fill in the `mac` field to the Owntracks entry in `known_devices.yaml` with the MAC address of the device you want to track. This way the state of the device will be determined by the source that reported last. The naming convention for known device list is `<username>_<device-id>` and could be set in app configuration. More details about this config can found in [device tracker](/components/device_tracker/).
|
||||
Owntracks can also be used with other device trackers, such as [Nmap](/components/device_tracker.nmap_tracker/) or [Netgear](/components/device_tracker.netgear/). To do this, fill in the `mac` field to the Owntracks entry in `known_devices.yaml` with the MAC address of the device you want to track. This way the state of the device will be determined by the source that reported last. The naming convention for known device list is `<username>_<device-id>` and could be set in app configuration. More details about this config can found in [device tracker](/components/device_tracker/).
|
||||
|
||||
An example showing the inclusion of the `mac` field for multiple component tracking. The `mac` field will need to be added to the `owntracks` device and will enable tracking by all components that track via the `mac` address.
|
||||
|
||||
```yaml
|
||||
<username>_<device-id>:
|
||||
name: Friendly Name
|
||||
mac: EA:AA:55:E7:C6:94
|
||||
picture: https://home-assistant.io/images/favicon-192x192.png
|
||||
gravatar: test@example.com
|
||||
track: yes
|
||||
hide_if_away: no
|
||||
```
|
||||
|
||||
### {% linkable_title Using Owntracks regions %}
|
||||
Owntracks can track regions, and send region entry and exit information to Home Assistant (HA). You set up a region in the Owntracks app which you should name the same as your HA Zone, and then make sure to turn on the `share` option for the region in the owntracks app. Please see the [owntracks documentation](http://owntracks.org/booklet/guide/waypoints/).
|
||||
|
|
|
|||
|
|
@ -41,6 +41,19 @@ automation:
|
|||
entity_id: script.my_action
|
||||
```
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: Send notification of RSS feed title when updated
|
||||
trigger:
|
||||
platform: event
|
||||
event_type: feedreader
|
||||
action:
|
||||
service: notify.notify
|
||||
data_template: "{{ trigger.event.data.title }}"
|
||||
```
|
||||
|
||||
*Any field under the `<entry>` tag in the feed can be used for example `tigger.event.data.content` will get the body of the feed entry.
|
||||
|
||||
For more advanced use cases, a custom component registering to the `feedreader` event type could be used instead:
|
||||
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ logo: home-assistant.png
|
|||
ha_category: Organization
|
||||
---
|
||||
|
||||
Groups allow the user to combine multiple entities into one. A group can be promoted to a **view** by setting the `view` option to `yes`. This will make the group available as a new tab in the frontend.
|
||||
Groups allow the user to combine multiple entities into one. A group can be promoted to a **view** by setting `view: yes` under the group definition. This will make the group available as a new tab in the frontend.
|
||||
|
||||
Check the **Set State** <img src='/images/screenshots/developer-tool-states-icon.png' class='no-shadow' height='38' /> page from the **Developer Tools** and browse the **Current entities:** listing for all available entities.
|
||||
|
||||
By default, every group appears in the HOME tab. If you name a group `default_view` it will REPLACE the contents of the HOME tab so you can customize it as you wish.
|
||||
By default, every group appears in the HOME tab. If you create a group `default_view` it will REPLACE the contents of the HOME tab so you can customize the HOME tab as you wish.
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
|
@ -23,6 +23,7 @@ group:
|
|||
default_view:
|
||||
view: yes
|
||||
entities:
|
||||
- group.kitchen
|
||||
- group.awesome_people
|
||||
- group.climate
|
||||
kitchen:
|
||||
|
|
@ -38,11 +39,26 @@ group:
|
|||
- camera.demo_camera
|
||||
- device_tracker.demo_paulus
|
||||
- group.garden
|
||||
climate:
|
||||
name: Climate
|
||||
view: no
|
||||
entities:
|
||||
- sensor.bedroom_temp
|
||||
- sensor.porch_temp
|
||||
- sensor.bathroom_humidity
|
||||
awesome_people:
|
||||
name: Awesome People
|
||||
view: no
|
||||
entities:
|
||||
- device_tracker.dad_smith
|
||||
- device_tracker.mom_smith
|
||||
- device_tracker.dog_smith
|
||||
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **view** (*Optional*): If yes then the entry will be shown as a view (tab).
|
||||
- **view** (*Optional*): If yes then the entry will be shown as a view (tab) at the top.
|
||||
- **name** (*Optional*): Name of the group.
|
||||
- **icon** (*Optional*): If the group is a view, this icon will show at the top in the frontend instead of the name. If it's not a view, then the icon shows when this group is used in another group.
|
||||
- **control** (*Optional*): If hidden then the group switch will be hidden.
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Configuration variables:
|
|||
- **ssl_certificate** (*Optional*): Path to your TLS/SSL certificate to serve Home Assistant over a secure connection.
|
||||
- **ssl_key** (*Optional*): Path to your TLS/SSL key to serve Home Assistant over a secure connection.
|
||||
- **cors_allowed_origins** (*Optional*): A list of origin domain names to allow [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) requests from. Enabling this will set the `Access-Control-Allow-Origin` header to the Origin header if it is found in the list, and the `Access-Control-Allow-Headers` header to `Origin, Accept, X-Requested-With, Content-type, X-HA-access`. You must provide the exact Origin, i.e. `https://home-assistant.io` will allow requests from `https://home-assistant.io` but __not__ `http://home-assistant.io`.
|
||||
- **use_x_forwarded_for** (*Optional*): Enable parsing of the `X-Forwarded-For` header, passing on the client's correct IP address in proxied setups. You should only enable this in a trustworthy network environment, as clients passing that header could easily spoof their source IP address.
|
||||
- **use_x_forwarded_for** (*Optional*): Enable parsing of the `X-Forwarded-For` header, passing on the client's correct IP address in proxied setups. You should only enable this in a trustworthy network environment, as clients passing that header could easily spoof their source IP address. Defaults to False.
|
||||
- **trusted_networks** (*Optional*): List of trusted networks, consisting of IP addresses or networks, that are allowed to bypass password protection when accessing Home Assistant.
|
||||
- **ip_ban_enabled** (*Optional*): Flag indicating whether additional IP filtering is enabled. Defaults to False.
|
||||
- **login_attempts_threshold** (*Optional*): Number of failed login attemt from single IP after which it will be automatically banned if `ip_ban_enabled` is True. Defaults to -1, meaning that no new automatic bans will be added.
|
||||
|
|
@ -49,6 +49,7 @@ http:
|
|||
cors_allowed_origins:
|
||||
- https://google.com
|
||||
- https://home-assistant.io
|
||||
use_x_forwarded_for: True
|
||||
trusted_networks:
|
||||
- 127.0.0.1
|
||||
- ::1
|
||||
|
|
@ -81,4 +82,4 @@ After a ban is added a Persistent Notification is populated to the Home Assistan
|
|||
|
||||
<p class='note warning'>
|
||||
Please note, that sources from `trusted_networks` won't be banned automatically.
|
||||
</p>
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ automation:
|
|||
entity_id: binary_sensor.motion_garage
|
||||
to: 'on'
|
||||
condition:
|
||||
platform: state
|
||||
condition: state
|
||||
entity_id: input_boolean.notify_home
|
||||
state: 'on'
|
||||
action:
|
||||
|
|
@ -50,3 +50,11 @@ automation:
|
|||
title: ""
|
||||
message: "Honey, I'm home!"
|
||||
```
|
||||
|
||||
You can also set or change the status of an `input_boolean` by using `input_boolean.turn_on` and `input_boolean.turn_off` in your automations.
|
||||
|
||||
```yaml
|
||||
- service: input_boolean.turn_on
|
||||
data:
|
||||
entity_id: input_boolean.notify_home
|
||||
```
|
||||
|
|
|
|||
|
|
@ -46,14 +46,16 @@ The 2nd generation Hue app only allows to create a `Room`. You need to use the f
|
|||
Example:
|
||||
|
||||
To create a `LightGroup` named `Ceiling lights` that contains the lights 1, 2 and 3, execute the following command:
|
||||
```shell
|
||||
|
||||
```bash
|
||||
$ curl -XPOST -d '{"name": "Ceiling lights", "lights": ["1", "2", "3"]}' http://<bridge>/api/<username>/groups
|
||||
```
|
||||
|
||||
The `<username>` is the string that is used to register Home Assistant on the bridge, you can find it in the `phue.conf` file in your configuration path. `<bridge>` is the IP address or hostname of your Hue bridge.
|
||||
|
||||
You can find out the ids of your lights by executing the following command:
|
||||
```shell
|
||||
|
||||
```bash
|
||||
$ curl http://<bridge>/api/<username>/lights
|
||||
```
|
||||
|
||||
|
|
@ -68,17 +70,9 @@ More information can be found on the [Philips Hue API documentation](https://www
|
|||
|
||||
### {% linkable_title Using Hue Scenes in Home Assistant %}
|
||||
|
||||
The Hue platform has it's own concept of Scenes for setting the colors
|
||||
of a group of lights at once. Hue Scenes are very cheap, get created
|
||||
by all kinds of apps (as it is the only way to have 2 or more lights
|
||||
change at the same time), and are rarely deleted. A typical Hue hub
|
||||
might have hundreds of scenes stored in them, many that you've never
|
||||
used, almost all very poorly named.
|
||||
The Hue platform has it's own concept of Scenes for setting the colors of a group of lights at once. Hue Scenes are very cheap, get created by all kinds of apps (as it is the only way to have 2 or more lights change at the same time), and are rarely deleted. A typical Hue hub might have hundreds of scenes stored in them, many that you've never used, almost all very poorly named.
|
||||
|
||||
To avoid user interface overload we don't expose Scenes
|
||||
directly. Instead there is a
|
||||
[light.hue_activate_scene](/components/light/#service-lighthue_activate_scene)
|
||||
service which can be used by `automation` or `script` components. For
|
||||
To avoid user interface overload we don't expose Scenes directly. Instead there is a [light.hue_activate_scene](/components/light/#service-lighthue_activate_scene) service which can be used by `automation` or `script` components. For
|
||||
instance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -95,27 +89,15 @@ script:
|
|||
|
||||
How do you find these names?
|
||||
|
||||
The easiest way to do this is only use the scenes from the 2nd
|
||||
generation Hue app. That is organized by Room (Group) and Scene
|
||||
Name. Use the values of Room name and Scene name that you see in the
|
||||
app. You can test these work on the `dev-service` console of your Home
|
||||
Assistant instance.
|
||||
The easiest way to do this is only use the scenes from the 2nd generation Hue app. That is organized by Room (Group) and Scene
|
||||
Name. Use the values of Room name and Scene name that you see in the app. You can test these work on the `dev-service` console of your Home Assistant instance.
|
||||
|
||||
Alternatively, you can dump all rooms and scene names using this
|
||||
[gist](https://gist.github.com/sdague/5479b632e0fce931951c0636c39a9578). This
|
||||
does **not** tell you which groups and scenes work together but it's
|
||||
sufficient to get values that you can test in the `dev-service` console.
|
||||
Alternatively, you can dump all rooms and scene names using this [gist](https://gist.github.com/sdague/5479b632e0fce931951c0636c39a9578). This does **not** tell you which groups and scenes work together but it's sufficient to get values that you can test in the `dev-service` console.
|
||||
|
||||
*** Caveats ***
|
||||
|
||||
The Hue API doesn't activate Scenes directly, only on a Hue Group
|
||||
(typically Rooms, especially if using the 2nd gen app). But Hue Scenes
|
||||
don't actually reference their group. So heuristic matching is used.
|
||||
The Hue API doesn't activate Scenes directly, only on a Hue Group (typically Rooms, especially if using the 2nd gen app). But Hue Scenes don't actually reference their group. So heuristic matching is used.
|
||||
|
||||
Neither Group names or Scene names are guarunteed unique in Hue. If
|
||||
you are getting non deterministic behavior, adjust your Hue scenes via
|
||||
the App to be more identifying.
|
||||
Neither Group names or Scene names are guaranteed unique in Hue. If you are getting non deterministic behavior, adjust your Hue scenes via the App to be more identifying.
|
||||
|
||||
The Hue hub has limitted spaces for Scenes, and will delete Scenes if
|
||||
new ones get created that would overflow that space. The API docs say
|
||||
this is based on Least Recently Used.
|
||||
The Hue hub has limitted spaces for Scenes, and will delete Scenes if new ones get created that would overflow that space. The API docs say this is based on Least Recently Used.
|
||||
|
|
|
|||
|
|
@ -19,9 +19,12 @@ The `lifx` platform allows you to integrate your [LIFX](http://www.lifx.com) int
|
|||
# Example configuration.yaml entry
|
||||
light:
|
||||
- platform: lifx
|
||||
- broadcast: 192.168.1.255
|
||||
```
|
||||
Configuration variables:
|
||||
|
||||
- **server** (*Optional*): Your server address. Only needed if using more than one network interface. Omit if you are unsure.
|
||||
- **broadcast** (*Optional*): The broadcast address, set to reach all LIFX bulbs.
|
||||
|
||||
If there is an issue with lights not showing up when Home Assistant is restarted, add broadcast to your configuration.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ ha_release: 0.25
|
|||
|
||||
The `x10` light platform allows you to control your X10 based lights with Home Assistant.
|
||||
|
||||
Requires [Heyu x10 interface](http://www.heyu.org).
|
||||
Requires [Heyu x10](http://www.heyu.org) and a CM11A interface; the CM17A "FireCracker" interface is not supported.
|
||||
|
||||
To enable those lights, add the following lines to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -47,11 +47,13 @@ Currently known supported models:
|
|||
- EH5600
|
||||
- F6400AF
|
||||
- D6505
|
||||
- D6300SF
|
||||
|
||||
Currently tested but not working models:
|
||||
|
||||
- KU6300 - Shows in GUI but unable to control.
|
||||
- H6400 - Shows in GUI but unable to control.
|
||||
- J5200 - Unable to see state and unable to control
|
||||
|
||||
If your model is not on the list then give it a test, if everything works correctly then add it to the list on [GitHub](https://github.com/home-assistant/home-assistant.github.io/tree/current/source/_components/media_player.samsungtv.markdown).
|
||||
The first letter (U, P, L, H & K) represent the screen type, e.g. LED or Plasma. The second letter represents the region, E is Europe, N is North America and A is Asia & Australia. The two numbers following that represent the screen size.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ ha_iot_class: "Local Polling"
|
|||
The `fritzbox_callmonitor` sensor monitors the call monitor exposed by [AVM Fritz!Box](http://avm.de/produkte/fritzbox/) routers
|
||||
on TCP port 1012. It will assume the values `idle`, `ringing`, `dialing`, or `talking` with the phone numbers involved contained in the state attributes.
|
||||
|
||||
To activate the call monitor on your Fritz!Box, dial #96*5* from any phone connected to it.
|
||||
To activate the call monitor on your Fritz!Box, dial #96\*5\* from any phone connected to it.
|
||||
|
||||
To use the Fritz!Box call monitor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -13,36 +13,54 @@ ha_release: 0.29
|
|||
ha_iot_class: "Local Polling"
|
||||
---
|
||||
|
||||
The [Mi Flora plant sensor](https://www.open-homeautomation.com/2016/08/23/reverse-engineering-the-mi-plant-sensor/) is a small Bluetooth Low Energy device that monitors not only the moisture, but also light, temperature and
|
||||
conductivity. As only a single BLE device can be polled at the same time, the library implements locking to make sure this is the case.
|
||||
The [Mi Flora plant sensor](https://www.open-homeautomation.com/2016/08/23/reverse-engineering-the-mi-plant-sensor/) is a small Bluetooth Low Energy device that monitors not only the moisture, but also light, temperature and conductivity. As only a single BLE device can be polled at the same time, the library implements locking to make sure this is the case.
|
||||
|
||||
To use your Mi Flora plant sensor in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor
|
||||
platform: miflora
|
||||
mac: xx:xx:xx:xx:xx:xx
|
||||
name: Flower 1
|
||||
force_update: false
|
||||
median: 3
|
||||
monitored_conditions:
|
||||
- moisture
|
||||
- light
|
||||
- temperature
|
||||
- conductivity
|
||||
- platform: miflora
|
||||
mac: xx:xx:xx:xx:xx:xx
|
||||
monitored_conditions:
|
||||
- temperature
|
||||
```
|
||||
|
||||
- **mac** (*Required*): The MAC address of your sensor. You can find this be running `hcitool lescan` from command line.
|
||||
- **monitored_conditions** array (*Required*): The paramaters that should be monitored.
|
||||
- **moisture**: Moisture in the soil.
|
||||
- **light**: Brightness at the sensor's location.
|
||||
- **temperature**: Temperature at the sensor's location.
|
||||
- **conductivity**: Conductivity in the soil.
|
||||
- **battery**: Battery details.
|
||||
- **name** (*Optional*): The name displayed in the frontend.
|
||||
- **force_update** (*Optional*): Sends update events even if the value hasn't changed.
|
||||
- **median** (*Optional*): Sometimes the sensor measurements show spikes. Using this parameter, the poller will report the median of the last
|
||||
3 (you can also use larger values) measurements. This filters out single spikes. Median: 5 will also filter double spikes.
|
||||
If you never have problems with spikes, median=1 will work fine.
|
||||
- **monitored_conditions** (*Required*): The paramaters that should be monitored.
|
||||
- **median** (*Optional*): Sometimes the sensor measurements show spikes. Using this parameter, the poller will report the median of the last 3 (you can also use larger values) measurements. This filters out single spikes. Median: 5 will also filter double spikes. If you never have problems with spikes, `median: 1` will work fine.
|
||||
- **timeout** (*Optional*): Define the timeout value in seconds when polling (defaults to 10 if not defined)
|
||||
- **retries** (*Optional*): Define the number of retries when polling (defaults to 2 if not defined)
|
||||
- **cache** (*Optional*): Define cache expiration value in seconds (defaults to 1200 if not defined)
|
||||
|
||||
Note that by default the sensor is only polled once every 15 minutes. This means with the median=3 setting, it will take as least 30 minutes before the sensor will report a value after a Home Assistant restart. As the values usually change very slowly, this isn't a big problem.
|
||||
Note that by default the sensor is only polled once every 15 minutes. This means with the `median: 3` setting will take as least 30 minutes before the sensor will report a value after a Home Assistant restart. As the values usually change very slowly, this isn't a big problem.
|
||||
Reducing polling intervals will have a negative effect on the battery life.
|
||||
|
||||
A full configuration example could looks the one below:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor
|
||||
- platform: miflora
|
||||
mac: xx:xx:xx:xx:xx:xx
|
||||
name: Flower 1
|
||||
force_update: false
|
||||
median: 3
|
||||
monitored_conditions:
|
||||
- moisture
|
||||
- light
|
||||
- temperature
|
||||
- conductivity
|
||||
- battery
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -12,6 +12,10 @@ ha_category: Weather
|
|||
ha_iot_class: "Cloud Poll"
|
||||
---
|
||||
|
||||
<p class='note warning'>
|
||||
**This platform is currently not available. It's possible that `nest_weather` will be removed in the future.**
|
||||
</p>
|
||||
|
||||
|
||||
The `nest` weather sensor platform let you monitor current weather conditions based on the location of your [Nest](https://nest.com) thermostat.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,6 @@ sensor:
|
|||
api_key: YOUR_API_KEY
|
||||
monitored_conditions:
|
||||
- weather
|
||||
- temperature
|
||||
- wind_speed
|
||||
- humidity
|
||||
- pressure
|
||||
- clouds
|
||||
- rain
|
||||
- snow
|
||||
```
|
||||
|
||||
Configuration variables:
|
||||
|
|
@ -54,4 +47,3 @@ Details about the API are available in the [OpenWeatherMap documentation](http:/
|
|||
|
||||
Only metric measurements are supported at the moment.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ ha_release: 0.31
|
|||
---
|
||||
|
||||
|
||||
The `scrape` sensor platform is scraping information from websites. The sensor loads a HTML page and gives you the option to search and split out a value. As this is not a full-blown web scraper like [scrapy](https://scrapy.org/). It will most likely only works with simple webpage and it can be time-consuming to get the right section.
|
||||
The `scrape` sensor platform is scraping information from websites. The sensor loads a HTML page and gives you the option to search and split out a value. As this is not a full-blown web scraper like [scrapy](https://scrapy.org/). It will most likely only work with simple webpages and it can be time-consuming to get the right section.
|
||||
|
||||
To enable this sensor, add the following lines to your `configuration.yaml` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ To add this platform to your installation, add the following to your `configurat
|
|||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
switch:
|
||||
- platform: mfi
|
||||
host: IP_ADDRESS
|
||||
username: USERNAME
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue