jeans/home-assistant.io
jeans/home-assistant.io
1
0
Fork 0
mirror of https://github.com/home-assistant/home-assistant.io.git synced 2025-07-25 02:07:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clean-up

Browse Source
This commit is contained in:
Fabian Affolter 2017-04-24 09:30:36 +02:00
parent 7280afc7d7
commit 24fd53f45b
No known key found for this signature in database
GPG Key ID: DDF3D6F44AAB1336
10 changed files with 41 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
source/_components/homematic.markdown
View File

@ -41,10 +41,10 @@ Configuration variables (global):
Configuration variables (host):
- **ip** (*Required*): IP of CCU/Homegear
- **port** (*Optional*): Port of CCU/Homegear XML-RPC Server (default is 2001, use 2000 for wired and 2010 for IP)
- **callback_ip** (*Optional*): Set this, if HASS is reachable under a different IP from the CCU (NAT, Docker etc.)
- **callback_port** (*Optional*): Set this, if HASS is reachable under a different port from the CCU (NAT, Docker etc.)
- **ip** (*Required*): IP address of CCU/Homegear device.
- **port** (*Optional*): Port of CCU/Homegear XML-RPC Server. Default is 2001, use 2000 for wired and 2010 for IP.
- **callback_ip** (*Optional*): Set this, if Home Assistant is reachable under a different IP from the CCU (NAT, Docker etc.).
- **callback_port** (*Optional*): Set this, if Home Assistant is reachable under a different port from the CCU (NAT, Docker etc.).
- **resolvenames** (*Optional*): [`metadata`, `json`, `xml`] Try to fetch device names. Defaults to `false` if not specified.
- **username** (*Optional*): When fetching names via JSON-RPC, you need to specify a user with guest-access to the CCU.
- **password** (*Optional*): When fetching names via JSON-RPC, you need to specify the password of the user you have configured above.
@ -87,8 +87,8 @@ Resolving names can take some time. So when you start Home Assistant you won't s
### {% linkable_title Multiple hosts %}
In order to allow communication with multiple hosts or different protocols in parallel (wireless, wired and ip), multiple connections will be established, each to the configured destination. The name you choose for the host has to be unique and limited to ASCII letters.
Using multiple hosts has the drawback, that the services (explained below) may not work as expected. Only one connection can be used for services, which limits the devices/variables a service can use to the scope/protocol of the host.
In order to allow communication with multiple hosts or different protocols in parallel (wireless, wired and ip), multiple connections will be established, each to the configured destination. The name you choose for the host has to be unique and limited to ASCII letters.
Using multiple hosts has the drawback, that the services (explained below) may not work as expected. Only one connection can be used for services, which limits the devices/variables a service can use to the scope/protocol of the host.
This does *not* affect the entites in Home Assistant. They all use their own connection and work as expected.
### {% linkable_title Reading attributes of entities %}
@ -107,7 +107,7 @@ sensor:
### {% linkable_title Variables %}
It is possible to read and set values of system variables you have setup on the CCU/Homegear. The supported types for setting values are float- and bool-variables.
It is possible to read and set values of system variables you have setup on the CCU/Homegear. The supported types for setting values are float- and bool-variables.
The states of the variables are available through the attributes of your hub entity (e.g. `homematic.rf`). Use templates (as mentioned above) to make your variables available to automations or as entities.
The values of variables are polled from the CCU/Homegear in an interval of 30 seconds. Setting the value of a variable happens instantly and is directly pushed.
@ -184,10 +184,9 @@ action:
value: true
```
#### {% linkable_title Advanced examples %}
If you are familiar with the internals of HomeMatic devices, you can manually set values on the devices. This can serve as a workaround if support for a device is currently not available, or only limited functionality has been implemented.
If you are familiar with the internals of HomeMatic devices, you can manually set values on the devices. This can serve as a workaround if support for a device is currently not available, or only limited functionality has been implemented.
Using this service provides you direct access to the setValue-method of the primary connection. If you have multiple hosts, you may select the one hosting a specific device by providing the proxy-parameter with a value equivalent to the name you have chosen. In the example configuration from above `rf`, `wired` and `ip` would be valid values.
Manually turn on a switch actor

18
source/_components/keyboard_remote.markdown
View File

@ -100,18 +100,22 @@ automation:
```
## {% linkable_title Permissions %}
There might be permissions problems with the event input device file. If this is the case, the user that hass runs as must be allowed read and write permissions with:
There might be permissions problems with the event input device file. If this is the case, the user that Home Assistant runs as must be allowed read and write permissions with:
```bash
$ sudo setfacl -m u:HASS_USER:rw /dev/input/event*
```
sudo setfacl -m u:HASS_USER:rw /dev/input/event*
```
where `HASS_USER` is the user hass runs as.
where `HASS_USER` is the user who runs Home Assistant.
If you want to make this permanent, you can use a udev rule that sets it for all event input devices. Add a file `/etc/udev/rules.d/99-userdev-input.rules` containing:
```
```bash
KERNEL=="event*", SUBSYSTEM=="input", RUN+="/usr/bin/setfacl -m u:HASS_USER:rw $env{DEVNAME}"
```
You can check ACLs permissions with
```
getfacl /dev/input/event*
```bash
$ getfacl /dev/input/event*
```

2
source/_components/notify.html5.markdown
View File

@ -239,7 +239,7 @@ You will receive an event named `html5_notification.closed` when the notificatio
### {% linkable_title Making notifications work with NGINX proxy %}
If you use [NGINX](/ecosystem/nginx/) as an proxy with authentication in front of HASS, you may have trouble with receiving events back to HASS. It's because of authentication token that cannot be passed through the proxy.
If you use [NGINX](/ecosystem/nginx/) as an proxy with authentication in front of your Home Assistant instance, you may have trouble with receiving events back to Home Assistant. It's because of authentication token that cannot be passed through the proxy.
To solve the issue put additional location into your nginx site's configuration:

2
source/_components/notify.nfandroidtv.markdown
View File

@ -15,7 +15,7 @@ ha_release: 0.32
Notification platform for [Notifications for Android TV](https://play.google.com/store/apps/details?id=de.cyberdream.androidtv.notifications.google&hl=de) and [Notifications for FireTV](https://play.google.com/store/apps/details?id=de.cyberdream.firenotifications.google).
The notifications are in the global scope of your Android TV device. They will be displayed regardless of which application is running.
The In-App purchases only apply to the client for Android smartphones, so there isn't any limit when pushing notifications from HASS.
The In-App purchases only apply to the client for Android smartphones, so there isn't any limit when pushing notifications from Home Assistant.
To enable the notification platform, add the following to your `configuration.yaml` file:

15
source/_components/remote.harmony.markdown
View File

@ -36,9 +36,9 @@ remote:
Configuration variables:
- **name** (*Required*): The hub's name to display in the front end.
- **name** (*Required*): The hub's name to display in the frontend.
- **host** (*Required*): The Harmony device's IP address.
- **port** (*Optional*): The Harmony device's port. 5222 is default.
- **port** (*Optional*): The Harmony device's port. Defaults to 5222.
- **activity** (*Optional*): Activity to use when turnon service is called without any data.
- **scan_interval** (*Optional*): Amount in seconds in between polling for device's current activity. Defaults to 30 seconds.
@ -52,10 +52,10 @@ Upon startup one file will be written to your Home Assistant configuration direc
Supported services:
- **Turn Off**: Turn off all devices that were switched on from the start of the current activity
- **Turn On**: Start an activity, will start the default activity from configuration.yaml if no activity is specified. The specified activity can either be the activity name or the activity ID from the configuration file written to your HASS config directory. The service will respond faster if the activity ID is passed instead of the name
- **Send Command**: Send a command to one device, device ID and available commands are written to the configuration file at startup
- **Sync**: Synchronizes the Harmony device with the Harmony web service if any changes are made from the web portal or app
- **Turn Off**: Turn off all devices that were switched on from the start of the current activity.
- **Turn On**: Start an activity, will start the default activity from configuration.yaml if no activity is specified. The specified activity can either be the activity name or the activity ID from the configuration file written to your [Home Assistant configuration directory](/docs/configuration/). The service will respond faster if the activity ID is passed instead of the name.
- **Send Command**: Send a command to one device, device ID and available commands are written to the configuration file at startup.
- **Sync**: Synchronizes the Harmony device with the Harmony web service if any changes are made from the web portal or app.
### {% linkable_title Examples %}
@ -91,7 +91,7 @@ sensor:
```
The example below shows how to control an `input_boolean` switch using the Harmony remote's current activity. The switch will turn on when the remote's state changes and the Kodi activity is started and off when the remote's state changes and the current activity is PowerOff.
The example below shows how to control an `input_boolean` switch using the Harmony remote's current activity. The switch will turn on when the remote's state changes and the Kodi activity is started and off when the remote's state changes and the current activity is PowerOff.
```yaml
automation:
@ -118,6 +118,7 @@ automation:
````
The automation example below shows how to send a command via the harmony remote using the `send_command` service to send the 'Pause' command to the hub, which is already defined as an IR code for each device to be used via the Harmony app. It is checking for the activity name as exposed through the sensor in the harmony remote component using Jinga if statements to set the device_id, sending the correct Pause command for the given activity. This requires checking your activity list and device_id from the `harmony_REMOTENAME.conf` file created when you start the component. In this example, the harmony hub is named bedroom.
```yaml
automation:
- alias: Harmony Pause contextual for activity

4
source/_components/rflink.markdown
View File

@ -117,7 +117,7 @@ If you find a device is recognized differently, with different protocols or the
### {% linkable_title Technical overview %}
- The`rflink` Python module a asyncio transport/protocol is setup that fires an callback for every (valid/supported) packet received by the RFLink gateway.
- This component uses this callback to distribute 'rflink packet events' over the HASS bus which can be subscribed to by entities/platform implementations.
- This component uses this callback to distribute 'rflink packet events' over Home Assistant's bus which can be subscribed to by entities/platform implementations.
- The platform implementions take care of creating new devices (if enabled) for unsees incoming packet id's.
- Device entities take care of matching to the packet ID, interpreting and performing actions based on the packet contents. Common entitiy logic is maintained in this main component.
@ -135,7 +135,7 @@ logger:
This will give you output looking like this:
```
```bash
17-03-07 20:12:05 DEBUG (MainThread) [rflink.protocol] received data: 20;00;Nod
17-03-07 20:12:05 DEBUG (MainThread) [rflink.protocol] received data: o RadioFrequencyLink - R
17-03-07 20:12:05 DEBUG (MainThread) [rflink.protocol] received data: FLink Gateway V1.1 - R45

4
source/_components/sensor.dnsip.markdown
View File

@ -15,7 +15,7 @@ ha_release: "0.40"
The `dnsip` sensor will expose an IP address, fetched via DNS resolution, as its value. There are two operational modes:
1. When you enable the sensor with minimal configuration, it will query [OpenDNS](https://www.opendns.com/)' nameserver with the hostname `myip.opendns.com`, which will resolve to your external/public IP address.
1. When you enable the sensor with minimal configuration, it will query the [OpenDNS](https://www.opendns.com/) nameservers with the hostname `myip.opendns.com`, which will resolve to your external/public IP address.
2. If you specify a `hostname`, a regular DNS lookup will be performed, providing you the IP the hostname resolves to.
You may also override the nameserver that is being used by setting the `resolver` parameter to any nameserver you like.
@ -32,7 +32,7 @@ Configuration variables:
- **hostname** (*Optional*): The hostname for which to perform the DNS query. Default: `myip.opendns.com` (special hostname that resolves to your public IP)
- **resolver** (*Optional*): The DNS server to target the query at. Default: `208.67.222.222` (OpenDNS)
- **ipv6** (*Optional*): Set this to `true` or `false` if IPv6 should be used. When resolving the public IP, this will be the IP of the machine HASS is running on.
- **ipv6** (*Optional*): Set this to `true` or `false` if IPv6 should be used. When resolving the public IP, this will be the IP of the machine where Home Assistant is running on.
- **resolver_ipv6** (*Optional*): The IPv6 DNS server to target the query at. Default: `2620:0:ccc::2` (OpenDNS)
- **scan_interval** (*Optional*): Defines number of seconds for polling interval. Default: `120` seconds.

7
source/_components/sensor.modem_callerid.markdown
View File

@ -11,7 +11,7 @@ ha_category: Sensor
ha_release: "0.40"
---
The `modem_callerid` sensor platform uses an available modem for collecting caller ID information. It requires a Hayes AT compatible modem that supports caller ID detection (via AT+VCID=1).
The `modem_callerid` sensor platform uses an available modem for collecting caller ID information. It requires a Hayes AT compatible modem that supports caller ID detection (via AT+VCID=1).
To enable the sensor, add the following lines to your `configuration.yaml`:
@ -19,7 +19,6 @@ To enable the sensor, add the following lines to your `configuration.yaml`:
# Example configuration.yaml entry
sensor:
- platform: modem_callerid
```
Configuration variables:
@ -31,7 +30,7 @@ To find the path of your USB modem, run:
`$ ls /dev/ttyACM*`
If `hass` runs with another user (e.g. *homeassistant* on Hassbian) give access to the stick with:
If Home Assistant (`hass`) runs with another user (e.g. `homeassistant` on Hassbian) give access to the stick with:
`$ sudo usermod -a -G dialout homeassistant`
@ -46,7 +45,7 @@ Some example automations:
trigger:
platform: state
entity_id: sensor.modem_callerid
state: "callerid"
state: "callerid"
action:
service: notify.notify
data:

2
source/_docs/installation/virtualenv.markdown
View File

@ -63,7 +63,7 @@ The `su` command means 'switch' user. We use the '-s' flag because the `homeassi
All this step does is stick a Python environment in the directory we're using. That's it. It's just a directory. There's nothing special about it, and it is entirely self-contained.
It will include a `bin` directory, which will contain all the executables used in the virtualenv (including hass itself). It also includes a script called `activate` which we will use to activate the virtualenv.
It will include a `bin` directory, which will contain all the executables used in the virtualenv (including Home Assistant itself). It also includes a script called `activate` which we will use to activate the virtualenv.
```bash
$ virtualenv -p python3 /srv/homeassistant

7
source/_docs/z-wave.markdown
View File

@ -62,6 +62,7 @@ With this installation, your `config_path` needed below will resemble:
```
If you followed along with setting up a virtual environment, your path will be:
```bash
/srv/homeassistant/python-openzwave/openzwave/config
```
@ -85,8 +86,8 @@ Configuration variables:
- **ignored** (*Optional*): Ignore this entity completely. It won't be shown in the Web Interface and no events are generated for it.
- **refresh_value** (*Optional*): Enable refreshing of the node value. Only the light component uses this. Defaults to False.
- **delay** (*Optional*): Specify the delay for refreshing of node value. Only the light component uses this. Defaults to 2 seconds.
- **invert_openclose_buttons** (*Optional*): Inverts function of the open and close buttons for the cover domain. Defaults to False
- **debug** (*Optional*): Print verbose z-wave info to log. Defaults to False.
- **invert_openclose_buttons** (*Optional*): Inverts function of the open and close buttons for the cover domain. Defaults to `False`.
- **debug** (*Optional*): Print verbose z-wave info to log. Defaults to `False`.
To find the path of your Z-Wave USB stick or module, run:
@ -99,7 +100,7 @@ Or, on some other systems (such as Raspberry Pi), use:
```bash
$ ls /dev/ttyACM*
# If `hass` runs with another user (e.g. *homeassistant* on Hassbian) give access to the stick with:
# If Home Assistant (`hass`) runs with another user (e.g. *homeassistant* on Hassbian) give access to the stick with:
$ sudo usermod -a -G dialout homeassistant
```