mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-23 01:06:52 +00:00
Merge branch 'current' into next
This commit is contained in:
Fabian Affolter
commit
73ed694fed
@ -136,4 +136,4 @@ date_released: 2016-12-17
|
||||
|
||||
# Either # or the anchor link to latest release notes in the blog post.
|
||||
# Must be prefixed with a # and have double quotes around it.
|
||||
patch_version_notes: "#release-0344---december-7"
|
||||
patch_version_notes: "#release-0345---december-12"
|
||||
|
||||
@ -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
|
||||
|
||||
@ -7,8 +7,6 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
HADashboard is a dashboard for [Home Assistant](https://home-assistant.io/) that is intended to be wall mounted, and is optimized for distance viewing.
|
||||
|
||||
@ -7,22 +7,22 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
(All installations)
|
||||
|
||||
Hadashboard is a Dashing app, so make sure to read all the instructions on http://dashing.io to learn how to add widgets to your dashboard, as well as how to create new widgets.
|
||||
Hadashboard is a Dashing application, so make sure to read all the instructions on http://dashing.io to learn how to add widgets to your dashboard, as well as how to create new widgets.
|
||||
|
||||
Make a copy of dashboards/example.erb and call it 'main.erb', then edit this file to reference the items you want to display and control and to get the layout that you want. Leave the original example.erb intact and unchanged so that you don't run into problems when trying to update using the git commands mentioned later in "Updating the Dashboard".
|
||||
Make a copy of `dashboards/example.erb` and call it `main.erb`, then edit this file to reference the items you want to display and control and to get the layout that you want. Leave the original `example.erb` intact and unchanged so that you don't run into problems when trying to update using the git commands mentioned later in "Updating the Dashboard".
|
||||
|
||||
The basic anatomy of a widget is this:
|
||||
|
||||
``` html
|
||||
<li data-row="" data-col="1" data-sizex="1" data-sizey="1">
|
||||
<div data-id="office" data-view="Hadimmer" data-title="Office Lamp"></div>
|
||||
</li>
|
||||
```
|
||||
|
||||
- **data-row**, **data-col**: The position of the widget in the grid.
|
||||
- **data-sizex**, **data-sizey**: The size of the widget in terms of grid tile.
|
||||
- **data-id**: The homeassitant entity id without the entity type (e.g. `light.office` becomes `office`).
|
||||
@ -34,47 +34,39 @@ The basic anatomy of a widget is this:
|
||||
Note that although it is legal in XML terms to split the inner `<div>` like this:
|
||||
|
||||
``` html
|
||||
<li data-row="" data-col="1" data-sizex="1" data-sizey="1">
|
||||
<div data-id="office"
|
||||
data-view="Hadimmer"
|
||||
data-title="Office Lamp">
|
||||
</div>
|
||||
</li>
|
||||
<li data-row="" data-col="1" data-sizex="1" data-sizey="1">
|
||||
<div data-id="office"
|
||||
data-view="Hadimmer"
|
||||
data-title="Office Lamp">
|
||||
</div>
|
||||
</li>
|
||||
```
|
||||
|
||||
This may break `hapush`'s parsing of the file, so keep to the line format first presented.
|
||||
|
||||
Please, refer to the Dashing website for instructions on how to change the grid and tile size, as well as more general instructions about widgets, their properties, and how to create new widgets.
|
||||
|
||||
# Supported Widgets
|
||||
## {% linkable_title Supported Widgets %}
|
||||
|
||||
At this time I have provided support for the following Home Assistant entity types.
|
||||
|
||||
- switch: Widget type **Haswitch**
|
||||
- lock: Widget type **Halock**
|
||||
- devicetracker: Widget type **Hadevicetracker**
|
||||
- light: Widget type **Hadimmer**
|
||||
- cover: Widget type **Hacover**
|
||||
- input_boolean: Widget type **Hainputboolean**
|
||||
- scene: Widget type **Hascene**
|
||||
|
||||
## switch
|
||||
Widget type ***Haswitch***
|
||||
## lock
|
||||
Widget type ***Halock***
|
||||
## devicetracker
|
||||
Widget type ***Hadevicetracker***
|
||||
## light
|
||||
Widget type ***Hadimmer***
|
||||
## cover
|
||||
Widget type ***Hacover***
|
||||
## input_boolean
|
||||
Widget type ***Hainputboolean***
|
||||
## scene
|
||||
Widget type ***Hascene***
|
||||
- **data-ontime** (optional): The amount of time the scene icon lights up when pressed, in milliseconds, default 1000.
|
||||
|
||||
**data-ontime** (optional): The amount of time the scene icon lights up when pressed, in milliseconds, default 1000.
|
||||
|
||||
## script
|
||||
### {% linkable_title script %}
|
||||
|
||||
Widget type ***Hascript***
|
||||
|
||||
**data-ontime** (optional): The amount of time the scene icon lights up when pressed, in milliseconds, default 1000.
|
||||
|
||||
## mode
|
||||
### {% linkable_title mode %}
|
||||
|
||||
The `Hamode` widget alows you to run a script on activation and to link it with a specified `input_select` so the button will be highlighted for certain values of that input select. The usecase for this is that I maintain an `input_select` as a flag for the state of the house to simplify other automations. I use scripts to switch between the states, and this feature provides feedback as to the current state by lighting up the appropriate mode button.
|
||||
|
||||
@ -85,37 +77,41 @@ A `Hamode` widget using this feature will look like this:
|
||||
<div data-id="day" data-view="Hamode" data-title="Good Day" data-icon="sun-o" data-changemode="Day" data-input="house_mode"></div>
|
||||
</li>
|
||||
```
|
||||
**data-changemode**: The value of the `input_select` for which this script button will light up
|
||||
|
||||
**data-input**: The `input_select` entity to use (minus the leading entity type)
|
||||
- **data-changemode**: The value of the `input_select` for which this script button will light up
|
||||
- **data-input**: The `input_select` entity to use (minus the leading entity type)
|
||||
|
||||
## input_select (read only)
|
||||
Widget type ***Hainputselect***
|
||||
### {% linkable_title input_select (read only) %}
|
||||
Widget type **Hainputselect**
|
||||
|
||||
## sensor
|
||||
Widget type ***Hasensor***
|
||||
### {% linkable_title sensor %}
|
||||
Widget type **Hasensor**
|
||||
|
||||
Text based output of the value of a particular sensor.
|
||||
|
||||
The Hasensor widget supports an additional paramater `data-unit` - this allows you to set the unit to whatever you want - Centigrade, %, lux or whatever you need for the sensor in question. For a temperature sensor you will need to explicitly include the degree symbol like this:
|
||||
The Hasensor widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, %, lux or whatever you need for the sensor in question. For a temperature sensor you will need to explicitly include the degree symbol like this:
|
||||
|
||||
```html
|
||||
data-unit="°F"
|
||||
```
|
||||
|
||||
If omitted, no units will be shown.
|
||||
|
||||
## sensor
|
||||
Widget type ***Hameter***
|
||||
### {% linkable_title sensor %}
|
||||
Widget type **Hameter**
|
||||
|
||||
An alternative to the text based `Hasensor` that works for numeric values only.
|
||||
|
||||
The Hameter widget supports an additional paramater `data-unit` - this allows you to set the unit to whatever you want - Centigrade, %, lux or whatever you need for the sensor in question. For a temperature sensor you will need to explicitly include the degree symbol like this:
|
||||
The Hameter widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, %, lux or whatever you need for the sensor in question. For a temperature sensor you will need to explicitly include the degree symbol like this:
|
||||
|
||||
```html
|
||||
data-unit="°F"
|
||||
```
|
||||
|
||||
If omitted, no units will be shown.
|
||||
|
||||
## binary_sensor
|
||||
Widget type ***Habinary***
|
||||
### {% linkable_title binary_sensor %}
|
||||
Widget type **Habinary**
|
||||
|
||||
An icon-based option for generic binary sensors. Useful for things like door contact sensors. In addition to the standard widget parameters, Habinary supports two additional parameters:
|
||||
|
||||
@ -124,12 +120,12 @@ An icon-based option for generic binary sensors. Useful for things like door con
|
||||
|
||||
If no icons are specified, the widget defaults to a flat gray line for "off" and a green bullseye for "on".
|
||||
|
||||
## group
|
||||
Widget type ***Hagroup***
|
||||
### {% linkable_title group %}
|
||||
Widget type **Hagroup**.
|
||||
|
||||
The Hagroup widget uses the homeassistant/turn_on and homeassistant/turn_off API call, so certain functionality will be lost. For example, you will not be able to use control groups of locks or dim lights.
|
||||
|
||||
# Alarm Control Panel
|
||||
## {% linkable_title Alarm Control Panel %}
|
||||
|
||||
These widgets allow the user to create a working control panel that can be used to control the Manual Alarm Control Panel component (https://home-assistant.io/components/alarm_control_panel.manual). The example dashboard contains an arrangement similar to this:
|
||||
|
||||
@ -138,31 +134,31 @@ These widgets allow the user to create a working control panel that can be used
|
||||
The Alarm Panel
|
||||
</p>
|
||||
|
||||
Widget type ***Haalarmstatus***
|
||||
Widget type **Haalarmstatus**
|
||||
|
||||
The Haalarmstatus widget displays the current status of the alarm_control_panel entity. It will also display the code as it is being entered by the user.
|
||||
|
||||
The data-id must be the same as the alarm_control_panel entity_id in Home Assistant.
|
||||
|
||||
Widget type ***Haalarmdigit***
|
||||
Widget type **Haalarmdigit**
|
||||
|
||||
The Haalarmdigit widget is used to create the numeric keypad for entering alarm codes.
|
||||
|
||||
data-digit holds the numeric value you wish to enter. The special value of "-" creates a 'clear' button which will wipe the code and return the Haalarmstatus widget display back to the current alarm state.
|
||||
`data-digit` holds the numeric value you wish to enter. The special value of "-" creates a 'clear' button which will wipe the code and return the Haalarmstatus widget display back to the current alarm state.
|
||||
|
||||
data-alarmentity holds the data-id of the Haalarmstatus widget, so that the status widget can be correctly updated. It is mandatory for a 'clear' type digit and optional for normal numeric buttons.
|
||||
`data-alarmentity` holds the data-id of the Haalarmstatus widget, so that the status widget can be correctly updated. It is mandatory for a 'clear' type digit and optional for normal numeric buttons.
|
||||
|
||||
Widget type ***Haalarmaction***
|
||||
Widget type **Haalarmaction**
|
||||
|
||||
The Haalarmaction widget creates the arm/disarm/trigger buttons. Bear in mind that alarm triggering does not require a code, so you may not want to put this button near the other buttons in case it is pressed accidentally.
|
||||
|
||||
data-action must contain one of the following: arm_home/arm_away/trigger/disarm.
|
||||
|
||||
# weather (requires dark sky)
|
||||
### {% linkable_title weather (requires DarkSky) %}
|
||||
|
||||
Widget type ***Haweather***
|
||||
Widget type **Haweather**.
|
||||
|
||||
In order to use the weather widget you must configure the dark sky component, and ensure that you configure at least the following monitored conditions in your Home Assistant sensor config:
|
||||
In order to use the weather widget you must configure the [DarkSky component](/component/senor.darksky/), and ensure that you configure at least the following monitored conditions in your Home Assistant sensor configuration:
|
||||
|
||||
- temperature
|
||||
- humidity
|
||||
@ -176,22 +172,26 @@ In order to use the weather widget you must configure the dark sky component, an
|
||||
|
||||
The `data-id` of the Haweather widget must be set to `weather` or the widget will not work.
|
||||
|
||||
The Hatemp widget supports an additional paramater `data-unit` - this allows you to set the unit to whatever you want - Centigrade, Farenheight or even Kelvin if you prefer ;) You will need to explicitly include the degree symbol like this:
|
||||
The Hatemp widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, Fahrenheit or even Kelvin if you prefer. You will need to explicitly include the degree symbol like this:
|
||||
|
||||
```html
|
||||
data-unit="°F"
|
||||
```
|
||||
|
||||
If omitted, no units will be shown.
|
||||
|
||||
## news
|
||||
Widget type ***News*** (contributed by [KRiS](https://community.home-assistant.io/users/kris/activity))
|
||||
### {% linkable_title News %}
|
||||
Widget type ***News*** (contributed by [KRiS](https://community.home-assistant.io/users/kris/activity))
|
||||
|
||||
This is an RSS widget that can be used for displaying travel information, news etc. on the dashboard. The RSS feed will update every 60 minutes. To configure this, first it is necessary to add your desired feeds in `homeassistant/lib/ha_conf.rb` in the `$news_feeds` section. By default it comes with 2 sample feeds:
|
||||
|
||||
This is an RSS widget that can be used for displaying travel information, news etc. on the dashboard. The RSS feed will update every 6o minutes. To configure this, first it is necessary to add your desired feeds in `homeassistant/lib/ha_conf.rb` in the `$news_feeds` section. By default it comes with 2 sample feeds:
|
||||
```ruby
|
||||
$news_feeds = {
|
||||
"Traffic" => "http://api.sr.se/api/rss/traffic/2863",
|
||||
"News" => "http://feeds.bbci.co.uk/news/rss.xml",
|
||||
}
|
||||
```
|
||||
|
||||
You can add as many as you want. The important point is that the key value (e.g. "Traffic" or "News" in the example above is used to tie the feed to your widget in the dashboard file. Here is an example of the Traffic widget that displays the first feed in the list:
|
||||
|
||||
```html
|
||||
@ -201,33 +201,33 @@ You can add as many as you want. The important point is that the key value (e.g.
|
||||
```
|
||||
The value of thee `data-id` tag must match the key value in the `$news_feeds` configuration.
|
||||
|
||||
- ***data-interval*** (optional) - the time in seconds that each entry in the RSS feed is displayed before the next one is shown, default is 30 seconds.
|
||||
- **data-interval** (optional): The time in seconds that each entry in the RSS feed is displayed before the next one is shown, default is 30 seconds.
|
||||
|
||||
|
||||
***The follwing widget types have been deprecated in favor of the more flexible `Hasensor` and `Hameter` widgets. They will be removed in a future release.***
|
||||
**The follwing widget types have been deprecated in favor of the more flexible `Hasensor` and `Hameter` widgets. They will be removed in a future release.**
|
||||
|
||||
## sensor (humidity)
|
||||
Widget type ***Hahumidity***
|
||||
### {% linkable_title sensor (humidity) %}
|
||||
Widget type **Hahumidity**.
|
||||
|
||||
## sensor (humidity)
|
||||
Widget type ***Hahumiditymeter*** (contributed by [Shiv Chanders](https://community.home-assistant.io/users/chanders/activity))
|
||||
### {% linkable_title sensor (humidity) %}
|
||||
Widget type **Hahumiditymeter** (contributed by [Shiv Chanders](https://community.home-assistant.io/users/chanders/activity))
|
||||
|
||||
This is an alternative to the the text based humidity widget above, it display the humidity as an animated meter from 0 to 100%.
|
||||
|
||||
## sensor (luminance)
|
||||
Widget type ***Halux***
|
||||
### {% linkable_title sensor (luminance) %}
|
||||
Widget type **Halux**.
|
||||
|
||||
### {% linkable_title sensor (temperature) %}
|
||||
Widget type **Hatemp**.
|
||||
|
||||
## sensor (temperature)
|
||||
Widget type ***Hatemp***
|
||||
The Hatemp widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, Fahrenheit or even Kelvin if you prefer. You will need to explicitly include the degree symbol like this:
|
||||
|
||||
The Hatemp widget supports an additional paramater `data-unit` - this allows you to set the unit to whatever you want - Centigrade, Farenheight or even Kelvin if you prefer ;) You will need to explicitly include the degree symbol like this:
|
||||
```html
|
||||
data-unit="°F"
|
||||
```
|
||||
If omitted, no units will be shown.
|
||||
|
||||
# Customizing CSS styles
|
||||
## {% linkable_title Customizing CSS styles %}
|
||||
If you want to customize the styles of your dashboard and widgets, there are two options:
|
||||
|
||||
1. You can edit the application.scss file (and the individual widget .scss files) directly (not recommended; if you pull down updates from the master repository, your changes might conflict/be overwritten)
|
||||
@ -239,13 +239,13 @@ If you want to customize the styles of your dashboard and widgets, there are two
|
||||
|
||||
__Note: The `_variables.scss` file (and your customizations from `_variables_custom.scss`) get imported into nearly every widget's SCSS file, so it is a best practice to define varaibles for colors in `_variables.scss` or `_variables_custom.scss` and reference those variables in the widget SCSS.__
|
||||
|
||||
# Changes and Restarting
|
||||
## {% linkable_title Changes and Restarting %}
|
||||
|
||||
When you make changes to a dashboard, Dashing and `hapush` will both automatically reload and apply the changes without a need to restart.
|
||||
|
||||
Note: The first time you start Dashing, it can take up to a minute for the initial compilation of the pages to occur. You might get a timeout from your browser. If this occurs, be patient and reload. Subsequent reloads will be a lot quicker.
|
||||
|
||||
# Multiple Pages
|
||||
## {% linkable_title Multiple Pages %}
|
||||
|
||||
It is possible to have multiple pages within a dashboard. To do this, you can add an arbitary number of gridster divisions (you need at least one).
|
||||
|
||||
@ -265,9 +265,10 @@ The divisions are implicitly numbered from 1 so it is a good idea to comment the
|
||||
<div data-id="cpage1" data-view="ChangePage" data-icon="cogs" data-title="Upstairs" data-page="3" data-stagger="false" data-fasttransition="true" data-event-click="onClick"></div>
|
||||
</li>
|
||||
```
|
||||
|
||||
- ***data-page*** : The name of the page to switch to
|
||||
|
||||
# Multiple Dashboards
|
||||
## {% linkable_title Multiple Dashboards %}
|
||||
You can also have multiple dashboards, by simply adding a new .erb file to the dashboards directory and navigating to the dashboards via `http://<IP address>:3030/dashboard-file-name-without-extension`
|
||||
|
||||
For example, if you want to deploy multiple devices, you could have one dashboard per room and still only use one hadashboard app installation.
|
||||
|
||||
@ -7,8 +7,6 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
# Installing hapush (Manual install only)
|
||||
@ -28,18 +26,21 @@ $ sudo pip3 install configobj
|
||||
```
|
||||
|
||||
Some users are reporting errors with `InsecureRequestWarning`:
|
||||
|
||||
```
|
||||
Traceback (most recent call last):
|
||||
File "./hapush.py", line 21, in <module>
|
||||
from requests.packages.urllib3.exceptions import InsecureRequestWarning
|
||||
ImportError: cannot import name 'InsecureRequestWarning'
|
||||
```
|
||||
|
||||
This can be fixed with:
|
||||
```
|
||||
|
||||
```bash
|
||||
$ sudo pip3 install --upgrade requests
|
||||
```
|
||||
|
||||
# Configuring hapush (all installation methods)
|
||||
## {% linkable_title Configuring hapush (all installation methods) %}
|
||||
|
||||
When you have all the prereqs in place, copy the hapush.cfg.example file to hapush.cfg then edit it to reflect your environment:
|
||||
|
||||
@ -57,7 +58,7 @@ logfile = "/etc/hapush/hapush.log"
|
||||
- `dash_dir` is the path on the machine that stores your dashboards. This will be the subdirectory `dashboards` relative to the path you cloned `hadashboard` to. For Docker installs this should be set to `/app/dashboards`
|
||||
- `logfile` is the path to where you want `hapush` to keep its logs. When run from the command line this is not used - log messages come out on the terminal. When running as a daemon this is where the log information will go. In the example above I created a directory specifically for hapush to run from, although there is no reason you can't keep it in the `hapush` subdirectory of the cloned repository. For Docker installs this should be set to `/app/hapush/hapush.log`
|
||||
|
||||
# Running hapush
|
||||
## {% linkable_title Running hapush %}
|
||||
|
||||
For a manual installation you can then run hapush from the command line as follows:
|
||||
|
||||
@ -67,9 +68,9 @@ $ ./hapush.py hapush.cfg
|
||||
|
||||
For docker installs, hapush will be started automatically when you run the startup command.
|
||||
|
||||
If all is well, you should start to see `hapush` responding to events as they occur. For a docker install you should see these messages in hapush/hapush.log
|
||||
If all is well, you should start to see `hapush` responding to events as they occur. For a docker installation you should see these messages in `hapush/hapush.log`.
|
||||
|
||||
```
|
||||
```bash
|
||||
2016-06-19 10:05:59,693 INFO Reading dashboard: /srv/hass/src/hadashboard/dashboards/main.erb
|
||||
2016-06-19 10:06:12,362 INFO switch.wendy_bedside -> state = on, brightness = 50
|
||||
2016-06-19 10:06:13,334 INFO switch.andrew_bedside -> state = on, brightness = 50
|
||||
|
||||
@ -7,17 +7,15 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
Installation can be performed using Docker (Contributed by [marijngiesen](https://github.com/marijngiesen)) or manually if Docker doesn't work for you. We also have a Raspberry PI version of Docker contributed by [snizzleorg](https://community.home-assistant.io/users/snizzleorg/activity)
|
||||
|
||||
## Using Docker (Non Raspian)
|
||||
## {% linkable_title Using Docker (Non Raspian) %}
|
||||
|
||||
Assuming you already have Docker installed, installation is fairly easy.
|
||||
|
||||
### Clone the Repository
|
||||
### {% linkable_title Clone the Repository %}
|
||||
Clone the **hadashboard** repository to the current local directory on your machine.
|
||||
|
||||
``` bash
|
||||
@ -30,7 +28,7 @@ Change your working directory to the repository root. Moving forward, we will be
|
||||
$ cd hadashboard
|
||||
```
|
||||
|
||||
### Build the docker image
|
||||
### {% linkable_title Build the docker image %}
|
||||
|
||||
```bash
|
||||
$ docker build -t hadashboard .
|
||||
@ -52,12 +50,11 @@ This will use all of the same configuration files as specified below in the conf
|
||||
|
||||
By default, the docker instance should pick up your timezone but if you want to explicitly set it you can add an environment variable for your specific zone as follows:
|
||||
|
||||
```
|
||||
```bash
|
||||
-e "TZ=Europe/Amsterdam"
|
||||
```
|
||||
|
||||
|
||||
### Docker on Raspberry Pi
|
||||
### {% linkable_title Docker on Raspberry Pi %}
|
||||
|
||||
Raspberry pi needs to use a different docker build file so the build command is slightly different:
|
||||
|
||||
@ -69,9 +66,9 @@ Apart from that the other steps are identical.
|
||||
|
||||
*Note - this is pretty slow even on a PI3, be prepared for it to take an hour or two to build all of the extensions and install everything*
|
||||
|
||||
## Manual Installation
|
||||
## {% linkable_title Manual Installation %}
|
||||
|
||||
### Clone the Repository
|
||||
### {% linkable_title Clone the Repository %}
|
||||
Clone the **hadashboard** repository to the current local directory on your machine.
|
||||
|
||||
``` bash
|
||||
@ -84,7 +81,7 @@ Change your working directory to the repository root. Moving forward, we will be
|
||||
$ cd hadashboard
|
||||
```
|
||||
|
||||
### 2. Install Dashing and prereqs
|
||||
### {% linkable_title 2. Install Dashing and prereqs %}
|
||||
|
||||
Essentially, you want to make sure that you have Ruby installed on your local machine. Then, install the Dashing gem:
|
||||
|
||||
@ -118,7 +115,7 @@ You will need to research what works on your particular architecture and also be
|
||||
|
||||
Note: This is currently running on various versions of Ruby and there are no strong dependencies however your mileage may vary.
|
||||
|
||||
## Updating configuration (Manual and Docker)
|
||||
## {% linkable_title Updating configuration (Manual and Docker) %}
|
||||
|
||||
Next, in the `./lib` directory, copy the ha_conf.rb.example file to ha_conf.rb and edit its settings to reflect your installation, pointing to the machine Home Assistant is running on and adding your api_key.
|
||||
|
||||
@ -143,8 +140,9 @@ You can leave these alone for now or if you prefer customize them as described i
|
||||
|
||||
When you are done, you can start a local webserver like this or if you are on docker it should start when you start the container.
|
||||
|
||||
``` bash
|
||||
```bash
|
||||
$ dashing start
|
||||
```
|
||||
|
||||
Point your browser to **http://localhost:3030** to access the hadashboard on your local machine.and you should see the supplied default dashboard. If you want to access it remotely ensure you have opened any required firewall rules.
|
||||
|
||||
|
||||
@ -7,8 +7,6 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
To run Dashing and `hapush` at reboot, I have provided sample init scripts in the `./init` directory. These have been tested on a Raspberry PI - your mileage may vary on other systems.
|
||||
|
||||
@ -7,8 +7,6 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
To update the dashboard after new code has been released, just run the following command to update your copy:
|
||||
@ -18,6 +16,7 @@ $ git pull origin
|
||||
```
|
||||
|
||||
For some releases you may also need to rerun the bundle command:
|
||||
|
||||
``` bash
|
||||
$ bundle
|
||||
```
|
||||
|
||||
@ -7,8 +7,6 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
The Home Assistant for iOS app offers a companion app for iOS which is deeply integrated into both Home Assistant and iOS. Its basic features include:
|
||||
|
||||
@ -7,8 +7,6 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
regenerate: true
|
||||
hide_github_edit: true
|
||||
---
|
||||
|
||||
Scenegen is a scene generation tool for [Home Assistant](https://home-assistant.io/) home automation software. It creates scenes by example, by reading the current states of devices and outputting a corresponding scene. Scenegen is written in python using Home Assistant's RESTFul API so can be run from anywhere. It currently supports lights and switches only.
|
||||
|
||||
24
source/_ecosystem/synology.markdown
Normal file
24
source/_ecosystem/synology.markdown
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Synology"
|
||||
description: "Instructions how to get Home Assistant up and running on Synology"
|
||||
release_date: 2016-12-07 15:00:00 -0500
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
Synology NAS are the perfect companion to running Home Assistant.
|
||||
|
||||
### {% linkable_title HTTP Configuration %}
|
||||
|
||||
Synology will require some extra configuration to get the Home Assistant frontend working.
|
||||
|
||||
- Copy the Home Assistant specific Reverse Proxy settings from the existing `/etc/nginx/app.d/server.ReverseProxy.conf` to `/usr/local/etc/nginx/conf.d/http.HomeAssistant.conf`
|
||||
- Include these lines in the location declaration:
|
||||
|
||||
```
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection "upgrade";
|
||||
```
|
||||
@ -147,7 +147,7 @@ The validation of the configuration is still on-going. Approximatly 80 % is done
|
||||
[Temper]: /components/sensor.temper/
|
||||
[mqtt-fan]: /components/fan.mqtt/
|
||||
[Xbox]: /components/sensor.xbox_live/
|
||||
[Nmap]: /components/device_tracker.nmap_scanner/
|
||||
[Nmap]: /components/device_tracker.nmap_tracker/
|
||||
[automatic]: /components/device_tracker.automatic/
|
||||
[Owntracks]: /components/device_tracker.owntracks/
|
||||
[OpenweatherMap]: /components/sensor.openweathermap/
|
||||
|
||||
@ -120,11 +120,18 @@ We are working on a better solution for 0.35.
|
||||
- Fix incorrect ordering of service calls which could cause delays inbetween turning on multiple entities ([@balloob])
|
||||
- Fix Nest Climate temperature issues ([@technicalpickles])
|
||||
|
||||
### {% linkable_title Release 0.34.5 - December 12 %}
|
||||
|
||||
- Fix Nest sensors doing I/O inside event loop ([@balloob])
|
||||
- Fix Nest version bump not triggering re-install ([@R1chardTM])
|
||||
- Fix Nest cameras without activity zones ([@technicalpickles])
|
||||
- Fix Plex doing I/O inside event loop ([@balloob])
|
||||
|
||||
### {% linkable_title Breaking changes %}
|
||||
|
||||
- The [HomeMatic][homematic] component now uses a different syntax for hosts and the `set_value` service has been renamed.
|
||||
- All [RFXtrx][rfxtrx] sensors will get a new entity ID.
|
||||
- If you are using NGINX, you will have to [adapt your configuration][nginx].
|
||||
- The frontend now uses websockets. If you run a server in front of Home Assistant, you will have to update your config (example [nginx][nginx])
|
||||
- [Nest][nest] contains changes which will require your attention.
|
||||
|
||||
### {% linkable_title If you need help... %}
|
||||
@ -135,6 +142,7 @@ We are working on a better solution for 0.35.
|
||||
|
||||
Experiencing issues introduced by this release? Please report them in our [issue tracker](https://github.com/home-assistant/home-assistant/issues). Make sure to fill in all fields of the issue template.
|
||||
|
||||
[@R1chardTM]: https://github.com/R1chardTM
|
||||
[@armills]: https://github.com/armills
|
||||
[@jawilson]: https://github.com/jawilson
|
||||
[@rubund]: https://github.com/rubund
|
||||
|
||||
@ -61,7 +61,7 @@ zwave:
|
||||
mqtt:
|
||||
broker: 127.0.0.1
|
||||
```
|
||||
As with the core snippet, indentation makes a difference. The component headers (`mqtt:`) should be fully left aligned (aka no indent), and the parameters (`port:`) should be indented two (2) spaces.
|
||||
As with the core snippet, indentation makes a difference. The component headers (`mqtt:`) should be fully left aligned (aka no indent), and the parameters (`broker:`) should be indented two (2) spaces.
|
||||
|
||||
While some of these components can technically be moved to a separate file they are so small or "one off's" where splitting them off is superfluous. Also, you'll notice the # symbol (hash/pound). This represents a "comment" as far as the commands are interpreted. Put another way, any line prefixed with a `#` will be ignored. This makes breaking up files for human readability really convenient, not to mention turning off features while leaving the entry intact. (Look at the `zigbee:` entry above and the b entry further down)
|
||||
|
||||
|
||||
@ -44,13 +44,12 @@ script:
|
||||
msg_who_is_home:
|
||||
sequence:
|
||||
- service: notify.notify
|
||||
data_template:
|
||||
message: >
|
||||
{% raw %}{% if is_state('device_tracker.paulus', 'home') %}
|
||||
Ha, Paulus is home!
|
||||
{% else %}
|
||||
Paulus is at {{ states('device_tracker.paulus') }}.
|
||||
{% endif %}{% endraw %}
|
||||
message: >
|
||||
{% raw %}{% if is_state('device_tracker.paulus', 'home') %}
|
||||
Ha, Paulus is home!
|
||||
{% else %}
|
||||
Paulus is at {{ states('device_tracker.paulus') }}.
|
||||
{% endif %}{% endraw %}
|
||||
```
|
||||
|
||||
[Jinja2](http://jinja.pocoo.org/) supports a width variety of operations:
|
||||
@ -132,7 +131,7 @@ Print out a list of all the sensor states.
|
||||
|
||||
{{ as_timestamp(states.binary_sensor.garage_door.last_changed) }}
|
||||
|
||||
{{ as_timestamp(now) - as_timestamp(states.binary_sensor.garage_door.last_changed) }}{% endraw %}
|
||||
{{ as_timestamp(now()) - as_timestamp(states.binary_sensor.garage_door.last_changed) }}{% endraw %}
|
||||
```
|
||||
|
||||
### {% linkable_title Distance examples %}
|
||||
|
||||
@ -9,9 +9,7 @@ sharing: true
|
||||
footer: true
|
||||
---
|
||||
|
||||
Home Assistant requires a web browser to show the frontend. Not all browsers include features which are needed to use the Home Assistant frontend. If you are running into trouble, check the list below.
|
||||
|
||||
We don't test the web interface against all available browsers but this page tracks different browsers on various operating systems and should help you to pick a browser which works.
|
||||
Home Assistant requires a web browser to show the frontend and supports all major modern browsers. We don't test the web interface against all available browsers but this page tracks different browsers on various operating systems and should help you to pick a browser which works.
|
||||
|
||||
We would appreciate if you help to keep this page up-to-date and add feedback.
|
||||
|
||||
@ -19,8 +17,8 @@ We would appreciate if you help to keep this page up-to-date and add feedback.
|
||||
|
||||
| Browser | Release | State | Comments |
|
||||
| :------------------------ |:---------------|:-----------|:-------------------------|
|
||||
| Internet Explorer ([IE]) | 11 | partially | Streaming updates not working. Display issues |
|
||||
| Microsoft [Edge] | deli. Win 10 | partially | Streaming updates not working. |
|
||||
| Internet Explorer ([IE]) | 11 | Not supported | Does not support promises. |
|
||||
| Microsoft [Edge] | deli. Win 10 | works | Streaming updates not working. |
|
||||
| [Chrome] | 50.0.2661.102 | works | |
|
||||
| [Firefox] | 43.0.1 | works | |
|
||||
| [Iridium] | 48.2 | works | |
|
||||
@ -52,8 +50,8 @@ We would appreciate if you help to keep this page up-to-date and add feedback.
|
||||
|
||||
| Browser | Release | State | Comments |
|
||||
| :-------------------- |:---------------|:-----------|:-------------------------|
|
||||
| [Chrome] | 50.0.2661.89 | works | |
|
||||
| [Firefox] | 46.0.1 | works | |
|
||||
| [Chrome] | 50.0.2661.89 | works | Can also be added to desktop |
|
||||
| [Firefox] | 46.0.1 | works | Can also be added to desktop |
|
||||
|
||||
## {% linkable_title iOS %}
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ Some extra tips:
|
||||
|
||||
### {% linkable_title Technical Details %}
|
||||
|
||||
- Home Assistant is installed in a virtual Python environment at `/src/homeassistant/`
|
||||
- Home Assistant is installed in a virtual Python environment at `/srv/homeassistant/`
|
||||
- Home Assistant will be started as a service run by the user `homeassistant`
|
||||
- The configuration is located at `/home/homeassistant/.homeassistant`
|
||||
|
||||
|
||||
@ -74,12 +74,13 @@ For above, the condition passes if `value >= above`. For below, the condition pa
|
||||
You can optionally use a `value_template` to process the value of the state before testing it.
|
||||
|
||||
```yaml
|
||||
condition: numeric_state
|
||||
entity_id: sensor.temperature
|
||||
above: 17
|
||||
below: 25
|
||||
# If your sensor value needs to be adjusted
|
||||
value_template: {% raw %}{{ float(state.state) + 2 }}{% endraw %}
|
||||
condition:
|
||||
condition: numeric_state
|
||||
entity_id: sensor.temperature
|
||||
above: 17
|
||||
below: 25
|
||||
# If your sensor value needs to be adjusted
|
||||
value_template: {% raw %}{{ float(state.state) + 2 }}{% endraw %}
|
||||
```
|
||||
|
||||
### {% linkable_title State condition %}
|
||||
@ -87,14 +88,15 @@ value_template: {% raw %}{{ float(state.state) + 2 }}{% endraw %}
|
||||
Tests if an entity is a specified state.
|
||||
|
||||
```yaml
|
||||
condition: state
|
||||
entity_id: device_tracker.paulus
|
||||
state: not_home
|
||||
# optional: trigger only if state was this for last X time.
|
||||
for:
|
||||
hours: 1
|
||||
minutes: 10
|
||||
seconds: 5
|
||||
condition:
|
||||
condition: state
|
||||
entity_id: device_tracker.paulus
|
||||
state: not_home
|
||||
# optional: trigger only if state was this for last X time.
|
||||
for:
|
||||
hours: 1
|
||||
minutes: 10
|
||||
seconds: 5
|
||||
```
|
||||
|
||||
### {% linkable_title Sun condition %}
|
||||
@ -104,10 +106,11 @@ The sun condition can test if the sun has already set or risen when a trigger oc
|
||||
[sun_trigger]: /getting-started/automation-trigger/#sun-trigger
|
||||
|
||||
```yaml
|
||||
condition: sun
|
||||
after: sunset
|
||||
# Optional offset value
|
||||
after_offset: "-1:00:00"
|
||||
condition:
|
||||
condition: sun
|
||||
after: sunset
|
||||
# Optional offset value
|
||||
after_offset: "-1:00:00"
|
||||
```
|
||||
|
||||
### {% linkable_title Template condition %}
|
||||
@ -115,8 +118,9 @@ after_offset: "-1:00:00"
|
||||
The template condition will test if the [given template][template] renders a value equal to true. This is achieved by having the template result in a true boolean expression or by having the template render 'true'.
|
||||
|
||||
```yaml
|
||||
condition: template
|
||||
value_template: '{% raw %}{{ states.device_tracker.iphone.attributes.battery > 50 }}{% endraw %}'
|
||||
condition:
|
||||
condition: template
|
||||
value_template: '{% raw %}{{ states.device_tracker.iphone.attributes.battery > 50 }}{% endraw %}'
|
||||
```
|
||||
|
||||
Within an automation, template conditions also have access to the `trigger` variable as [described here][automation-templating].
|
||||
@ -129,14 +133,15 @@ Within an automation, template conditions also have access to the `trigger` vari
|
||||
The time condition can test if it is after a specified time, before a specified time or if it is a certain day of the week
|
||||
|
||||
```yaml
|
||||
condition: time
|
||||
# At least one of the following is required.
|
||||
after: '15:00:00'
|
||||
before: '02:00:00'
|
||||
weekday:
|
||||
- mon
|
||||
- wed
|
||||
- fri
|
||||
condition:
|
||||
condition: time
|
||||
# At least one of the following is required.
|
||||
after: '15:00:00'
|
||||
before: '02:00:00'
|
||||
weekday:
|
||||
- mon
|
||||
- wed
|
||||
- fri
|
||||
```
|
||||
|
||||
Valid values for `weekday` are `mon`, `tue`, `wed`, `thu`, `fri`, `sat`, `sun`.
|
||||
@ -147,9 +152,10 @@ Time condition windows can span across the midnight threshold. In the example ab
|
||||
Zone conditions test if an entity is in a certain zone. For zone automation to work, you need to have setup a device tracker platform that supports reporting GPS coordinates. Currently this is limited to the [OwnTracks platform](/components/device_tracker.owntracks/) and the [iCloud platform](/components/device_tracker.icloud/).
|
||||
|
||||
```yaml
|
||||
condition: zone
|
||||
entity_id: device_tracker.paulus
|
||||
zone: zone.home
|
||||
condition:
|
||||
condition: zone
|
||||
entity_id: device_tracker.paulus
|
||||
zone: zone.home
|
||||
```
|
||||
|
||||
### {% linkable_title Examples %}
|
||||
|
||||
@ -29,11 +29,12 @@ Have you found an issue in your Home Assistant installation? Please report it. R
|
||||
|
||||
### {% linkable_title Videos, interviews, talks, and alike %}
|
||||
|
||||
- [Home Assistant - Erweiterungen (Platforms/Components)](https://github.com/home-assistant/home-assistant-assets/tree/master/german/2016-puzzle) at [Puzzle ITC](https://www.puzzle.ch/de/) - December 2016
|
||||
- [Automating Your Life - Home Automation](http://slides.com/teagan42/life_automation#/) at Develop Denver 2016 - August
|
||||
- [Building Online Communities: Home Assistant](https://medium.com/@gitter/building-online-communities-home-assistant-8818dff671ad#.och4x4rhx) - July 2016
|
||||
- [Home Assistant Support 101 - Getting around in Home Assistant](https://www.youtube.com/watch?v=dRfk9JAlPJk) ([Slides](https://docs.google.com/presentation/d/1PUnOpeFZxNj4LEjaohGqH_1hOGQGuS5yRHD1ThHr6nk/edit?usp=sharing)) - June 2016
|
||||
- [Awaken your home: Python and the Internet of Things](https://www.youtube.com/watch?v=Cfasc9EgbMU&list=PLKsVm4cWHDQB9JBcD7_ZfNcvC6xx47QHT&index=1) at PyCon 2016 - June 2016
|
||||
- [Automating your Home with Home Assistant](https://www.youtube.com/watch?v=4-6rTwKl6ww&list=PLKsVm4cWHDQB9JBcD7_ZfNcvC6xx47QHT&index=2) at OpenIoT 2016 - March 2016
|
||||
- [Automating Your Life - Home Automation](http://slides.com/teagan42/life_automation#/) at Develop Denver 2016 - August
|
||||
|
||||
Looking for [talking points](/help/talking-points/) or [trivia](/help/trivia)?
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user