mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-07-24 01:37:23 +00:00
Merge branch 'current' into release-0-41
This commit is contained in:
Fabian Affolter
GitHub
commit
be3bc0e0fe
@ -28,6 +28,7 @@ This platform should work with all Hikvision cameras, and has been confirmed to
|
||||
- DS-2CD3132-I
|
||||
- DS-2CD2232-I5
|
||||
- DS-2CD2032-I
|
||||
- DS-2CD2042WD-I
|
||||
- DS-2CD2142FWD-I
|
||||
|
||||
To enable this sensor, the following lines are required in your `configuration.yaml`:
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Rflink Light"
|
||||
description: "Instructions how to integrate Rflink lights into Home Assistant."
|
||||
title: "RFLink Light"
|
||||
description: "Instructions how to integrate RFLink lights into Home Assistant."
|
||||
date: 2016-01-04
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -12,11 +12,11 @@ ha_category: Light
|
||||
ha_release: 0.38
|
||||
---
|
||||
|
||||
The `rflink` component support devices that use [Rflink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo Rflink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). Rflink gateway is an Arduino firmware that allows communication with 433Mhz devices using cheap hardware (Arduino + 433Mhz tranceiver).
|
||||
The `rflink` component support devices that use [RFLink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo RFLink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). RFLink gateway is an Arduino firmware that allows two-way communication with a multitude of RF wireless devices using cheap hardware (Arduino + transceiver).
|
||||
|
||||
First you have to set up your [rflink hub](/components/rflink/).
|
||||
|
||||
After configuring the Rflink hub lights will be automatically discovered and added.
|
||||
After configuring the RFLink hub lights will be automatically discovered and added.
|
||||
|
||||
New/unknown lights can be assigned to a default group automatically by specifying the `new_devices_group` option with a group name. If the group doesn't exist it will be created.
|
||||
|
||||
@ -29,7 +29,7 @@ sensor:
|
||||
new_devices_group: "New Rflink Lights"
|
||||
```
|
||||
|
||||
Rflink switch/light ID's are composed of: protocol, id, switch. For example: `newkaku_0000c6c2_1`.
|
||||
RFLink switch/light ID's are composed of: protocol, id, switch. For example: `newkaku_0000c6c2_1`.
|
||||
|
||||
Once the ID of a light is known it can be used to configure the light in HA, for example to add it to a different group, hide it or configure a nice name.
|
||||
|
||||
@ -39,6 +39,9 @@ Configuring a device as light with a nice name:
|
||||
# Example configuration.yaml entry
|
||||
light:
|
||||
platform: rflink
|
||||
device_defaults:
|
||||
fire_event: true
|
||||
signal_repetitions: 2
|
||||
devices:
|
||||
newkaku_0000c6c2_1:
|
||||
name: Living room
|
||||
@ -59,12 +62,15 @@ Device configuration variables:
|
||||
- **aliasses** (*Optional*): Alternative Rflink ID's this device is known by.
|
||||
- **fire_event** (*Optional*): Fire an `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **signal_repetitions** (*Optional*): Repeat every Rflink command this number of times (default: 1)
|
||||
- **fire_event_** (*Optional*): Set default `fire_event` for RFLink switch devices (see below).
|
||||
- **signal_repetitions** (*Optional*): Set default `signal_repetitions` for RFLink switch devices (see below).
|
||||
|
||||
|
||||
### {% linkable_title Light state %}
|
||||
|
||||
Initially the state of a light is unknown. When the light is turned on or off (via frontend or 433Mhz remote) the state is known and will be shown in the frontend.
|
||||
Initially the state of a light is unknown. When the light is turned on or off (via frontend or remote) the state is known and will be shown in the frontend.
|
||||
|
||||
Sometimes a light is controlled by multiple 433Mhz remotes, each remote has its own code programmed in the light. To allow tracking of the state when switched via other remotes add the corresponding remote codes as aliasses:
|
||||
Sometimes a light is controlled by multiple remotes, each remote has its own code programmed in the light. To allow tracking of the state when switched via other remotes add the corresponding remote codes as aliasses:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
@ -82,7 +88,7 @@ Any on/off command from any allias ID updates the current state of the light. Ho
|
||||
|
||||
### {% linkable_title Light types %}
|
||||
|
||||
Light devices can come in different forms. Some only switch on and off, other support dimming. Dimmable devices might not always respond nicely to repeated `on` command as they turn into a pulsating state until `on` is pressed again (for example KlikAanKlikUit). The Rflink component support three types of lights to make things work in every situation:
|
||||
Light devices can come in different forms. Some only switch on and off, other support dimming. Dimmable devices might not always respond nicely to repeated `on` command as they turn into a pulsating state until `on` is pressed again (for example KlikAanKlikUit). The RFLink component support three types of lights to make things work in every situation:
|
||||
|
||||
- *Hybrid*: This type sends a `dim` followed by an a `on` command; and `off` commands. This will make dimmable devices turn on at the requested dim level and on/off devices on. One caveat is this type is not compatible with signal repetition as multiple `on` signals will cause dimmers to go into disco mode.
|
||||
- *Switchable*: Device type that sends only `on` and `off` commands. It work for both on/off and dimmable type switches. However dimmables might have issues with signal repetition (see above).
|
||||
@ -93,7 +99,7 @@ By default new lights are assigned the `switchable` type. Protocol supporting di
|
||||
|
||||
### {% linkable_title Hiding/ignoring lights %}
|
||||
|
||||
Lights are added automatically when the Rflink gateway intercepts a 433Mhz command in the ether. To prevent cluttering the frontend use any of these methods:
|
||||
Lights are added automatically when the RFLink gateway intercepts a wireless command in the ether. To prevent cluttering the frontend use any of these methods:
|
||||
|
||||
- Configure a `new_devices_group` for lights and optionally add it to a different `view`.
|
||||
- Hide unwanted devices using [customizations](/getting-started/customizing-devices/)
|
||||
|
||||
@ -25,8 +25,8 @@ mqtt_eventstream:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **publish_topic** (*Required*): Topic for publishing local events
|
||||
- **subscribe_topic** (*Required*): Topic to receive events from the remote server.
|
||||
- **publish_topic** (*Optional*): Topic for publishing local events
|
||||
- **subscribe_topic** (*Optional*): Topic to receive events from the remote server.
|
||||
|
||||
## Multiple Instances
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Rflink"
|
||||
description: "Instructions how to integrate Rflink gateway into Home Assistant."
|
||||
title: "RFLink"
|
||||
description: "Instructions how to integrate RFLink gateway into Home Assistant."
|
||||
date: 2016-01-04
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -12,17 +12,23 @@ ha_category: Hub
|
||||
ha_release: 0.38
|
||||
---
|
||||
|
||||
The `rflink` component support devices that use [Rflink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo Rflink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). Rflink gateway is firmware for the Arduino MEGA 2560 that allows communication with 433 Mhz devices using cheap hardware (Arduino + 433 Mhz tranceiver).
|
||||
The `rflink` component support devices that use [RFLink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo RFLink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). RFLink gateway is an Arduino firmware that allows two-way communication with a multitude of RF wireless devices using cheap hardware (Arduino + transceiver).
|
||||
|
||||
The 433 Mhz spectrum is used by many manufacturers mostly using their own protocol/standard and includes devices like: light switches, blinds, weather stations, alarms and various other sensors.
|
||||
|
||||
A complete list of devices supported by Rflink can be found [here](http://www.nemcon.nl/blog2/devlist)
|
||||
RFLink Gateway supports a number of RF frequencies, using a wide range of low-cost hardware. Their website provides details for various RF transmitter, receiver and transceiver modules for 433Mhz, 868Mhz and 2.4 Ghz [here.](http://www.nemcon.nl/blog2/wiring)
|
||||
|
||||
<p class='note'>
|
||||
Note: Versions later than R44 adds support for Ikea Ansluta, Philips Living Colors Gen1, MySensors devices.
|
||||
</p>
|
||||
|
||||
A complete list of devices supported by RFLink can be found [here](http://www.nemcon.nl/blog2/devlist)
|
||||
|
||||
This component is tested with the following hardware/software:
|
||||
|
||||
- Nodo Rflink Gateway V1.4/Rflink R44
|
||||
- Nodo RFLink Gateway V1.4/RFLink R46
|
||||
|
||||
To enable Rflink in your installation, add the following to your `configuration.yaml` file:
|
||||
To enable RFLink in your installation, add the following to your `configuration.yaml` file:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
@ -32,9 +38,9 @@ rflink:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **port** (*Required*): The path to Rflink usb/serial device or TCP port in TCP mode.
|
||||
- **port** (*Required*): The path to RFLink USB/serial device or TCP port in TCP mode.
|
||||
- **host** (*Optional*): Switches to TCP mode, connects to host instead of to USB/serial.
|
||||
- **wait_for_ack** (*Optional*): Wait for Rflink to ackowledge commands sent before sending new command (slower but more reliable). Defaults to `True`
|
||||
- **wait_for_ack** (*Optional*): Wait for RFLink to ackowledge commands sent before sending new command (slower but more reliable). Defaults to `True`
|
||||
- **ignore_devices** (*Optional*): List of devices id's to ignore. Supports wildcards (*) at the end.
|
||||
- **reconnect_interval** (*Optional*): Time in seconds between reconnect attempts.
|
||||
|
||||
@ -52,9 +58,9 @@ rflink:
|
||||
|
||||
### {% linkable_title TCP mode %}
|
||||
|
||||
TCP mode allows connect to a Rflink device over TCP/IP network. This is for example useful if placing the Rflink device next to the HA server is not optimal or desired (eg: bad reception).
|
||||
TCP mode allows connect to a RFLink device over TCP/IP network. This is for example useful if placing the RFLink device next to the HA server is not optimal or desired (eg: bad reception).
|
||||
|
||||
To expose the usb/serial interface over TCP on a different host (Linux) the following command can be used:
|
||||
To expose the USB/serial interface over TCP on a different host (Linux) the following command can be used:
|
||||
|
||||
```bash
|
||||
$ socat /dev/ttyACM0,b57600 TCP-LISTEN:1234,reuseaddr
|
||||
@ -65,7 +71,7 @@ Other methods of exposing the serial interface over TCP are possible (eg: ESP826
|
||||
Tested with Wifi serial bridge [esp-link V2.2.3](https://github.com/jeelabs/esp-link/releases/tag/v2.2.3) running on a NodeMCU (ESP8266 Wifi module) with ESP8266 TXD0 (pin D10) and RXD0 (pin D9) connected to Arduino MEGA 2560 RX (Pin 2) and TX (Pin 3) respectively.
|
||||
|
||||
<p class='note warning'>
|
||||
Due to different logical levels, a voltage level shifter is required between the 3.3V NodeMCU and 5V Arduino MEGA 2560 pins.
|
||||
Due to different logic levels, a voltage level shifter is required between the 3.3V NodeMCU and 5V Arduino MEGA 2560 pins. The BSS138 bidirectional logic level converter has been tested for serial pins and the [link](https://www.aliexpress.com/item/8CH-IIC-I2C-Logic-Level-Converter-Bi-Directional-Module-DC-DC-5V-to-3-3V-Setp/32238089139.html) is recommended for the CC2500 transceiver (used for Ikea Ansluta and Living Colors)
|
||||
</p>
|
||||
|
||||
<p class='note'>
|
||||
@ -81,7 +87,7 @@ rflink:
|
||||
|
||||
### {% linkable_title Ignoring devices %}
|
||||
|
||||
Rflink platform can be configured to completely ignore a device on a platform level. This is useful when you have neighbors which also use 433 Mhz technology.
|
||||
RFLink platform can be configured to completely ignore a device on a platform level. This is useful when you have neighbors which also use 433 Mhz technology.
|
||||
|
||||
For example:
|
||||
|
||||
@ -102,15 +108,15 @@ Wildcards only work at the end of the ID, not in the middle of front!
|
||||
|
||||
### {% linkable_title Device support %}
|
||||
|
||||
Even though a lot of devices are supported by Rflink, not all have been tested/implemented. If you have a device supported by Rflink but not by this component please consider testing and adding support yourself or [create an issue](https://github.com/home-assistant/home-assistant/issues/new) and mention `@aequitas` in the description.
|
||||
Even though a lot of devices are supported by RFLink, not all have been tested/implemented. If you have a device supported by RFLink but not by this component please consider testing and adding support yourself or [create an issue](https://github.com/home-assistant/home-assistant/issues/new) and mention `@aequitas` in the description.
|
||||
|
||||
### {% linkable_title Device Incorrectly Identified %}
|
||||
|
||||
If you find a device is recognized differently, with different protocols or the ON OFF is swapped or detected as two ON commands, it can be overcome with the RFlink 'RF Signal Learning' mechanism from RFLink Rev 46 (11 March 2017). http://www.nemcon.nl/blog2/faq#RFFind.
|
||||
If you find a device is recognized differently, with different protocols or the ON OFF is swapped or detected as two ON commands, it can be overcome with the RFlink 'RF Signal Learning' mechanism from RFLink Rev 46 (11 March 2017). [Link to further detail.](http://www.nemcon.nl/blog2/faq#RFFind)
|
||||
|
||||
### {% 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.
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Rflink Sensor"
|
||||
description: "Instructions how to integrate Rflink sensors into Home Assistant."
|
||||
title: "RFLink Sensor"
|
||||
description: "Instructions how to integrate RFLink sensors into Home Assistant."
|
||||
date: 2016-01-04
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -12,11 +12,11 @@ ha_category: Sensor
|
||||
ha_release: 0.38
|
||||
---
|
||||
|
||||
The `rflink` component support devices that use [Rflink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo Rflink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). Rflink gateway is an Arduino firmware that allows communication with 433Mhz devices using cheap hardware (Arduino + 433Mhz tranceiver).
|
||||
The `rflink` component support devices that use [RFLink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo RFLink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). RFLink gateway is an Arduino firmware that allows two-way communication with a multitude of RF wireless devices using cheap hardware (Arduino + transceiver).
|
||||
|
||||
First you have to set up your [rflink hub](/components/rflink/).
|
||||
|
||||
After configuring the Rflink hub sensors will be automatically discovered and added.
|
||||
After configuring the RFLink hub sensors will be automatically discovered and added.
|
||||
|
||||
New/unknown sensors can be assigned to a default group automatically by specifying the `new_devices_group` option with a group name. If the group doesn't exist it will be created.
|
||||
|
||||
@ -26,10 +26,10 @@ For example:
|
||||
# Example configuration.yaml entry
|
||||
sensor:
|
||||
platform: rflink
|
||||
new_devices_group: "New Rflink Sensors"
|
||||
new_devices_group: "New RFLink Sensors"
|
||||
```
|
||||
|
||||
Rflink sensor ID's are composed of: protocol, id and type (optional). For example: `alectov1_0334_temp`. Some sensors emit multiple types of data. Each will be created as its own
|
||||
RFLink sensor ID's are composed of: protocol, id and type (optional). For example: `alectov1_0334_temp`. Some sensors emit multiple types of data. Each will be created as its own
|
||||
|
||||
Once the ID of a sensor is known it can be used to configure the sensor in HA, for example to add it to a different group, hide it or configure a nice name.
|
||||
|
||||
@ -52,14 +52,14 @@ Configuration variables:
|
||||
|
||||
Device configuration variables:
|
||||
|
||||
- **name** (*Optional*): Name for the device, defaults to Rflink ID.
|
||||
- **name** (*Optional*): Name for the device, defaults to RFLink ID.
|
||||
- **sensor_type** (*Required*): Override automatically detected type of sensor.
|
||||
- **unit_of_measurement** (*Optional*): Override automatically detected unit of sensor.
|
||||
- **aliasses** (*Optional*): Alternative Rflink ID's this device is known by.
|
||||
- **aliasses** (*Optional*): Alternative RFLink ID's this device is known by.
|
||||
|
||||
### {% linkable_title Hiding/ignoring sensors %}
|
||||
|
||||
Sensors are added automatically when the Rflink gateway intercepts a 433Mhz command in the ether. To prevent cluttering the frontend use any of these methods:
|
||||
Sensors are added automatically when the RFLink gateway intercepts a wireless command in the ether. To prevent cluttering the frontend use any of these methods:
|
||||
|
||||
- Configure a `new_devices_group` for sensors and optionally add it to a different `view`.
|
||||
- Hide unwanted devices using [customizations](/getting-started/customizing-devices/)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Rflink Switch"
|
||||
description: "Instructions how to integrate Rflink switches into Home Assistant."
|
||||
title: "RFLink Switch"
|
||||
description: "Instructions how to integrate RFLink switches into Home Assistant."
|
||||
date: 2016-01-04
|
||||
sidebar: true
|
||||
comments: false
|
||||
@ -12,13 +12,13 @@ ha_category: Switch
|
||||
ha_release: 0.38
|
||||
---
|
||||
|
||||
The `rflink` component support devices that use [Rflink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo Rflink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). Rflink gateway is an Arduino firmware that allows communication with 433Mhz devices using cheap hardware (Arduino + 433Mhz tranceiver).
|
||||
The `rflink` component support devices that use [RFLink gateway firmware](http://www.nemcon.nl/blog2/), for example the [Nodo RFLink Gateway](https://www.nodo-shop.nl/nl/21-rflink-gateway). RFLink gateway is an Arduino firmware that allows two-way communication with a multitude of RF wireless devices using cheap hardware (Arduino + transceiver).
|
||||
|
||||
First you have to set up your [rflink hub](/components/rflink/).
|
||||
|
||||
The Rflink component does not know the difference between a `switch` and a `light`. Therefore all switchable devices are automatically added as `light` by default.
|
||||
The RFLink component does not know the difference between a `switch` and a `light`. Therefore all switchable devices are automatically added as `light` by default.
|
||||
|
||||
Rflink switch/light ID's are composed of: protocol, id, switch. For example: `newkaku_0000c6c2_1`.
|
||||
RFLink switch/light ID's are composed of: protocol, id, switch. For example: `newkaku_0000c6c2_1`.
|
||||
|
||||
Once the ID of a switch is known it can be used to configure it as a switch type in HA, for example to add it to a different group, hide it or configure a nice name.
|
||||
|
||||
@ -43,21 +43,21 @@ Configuration variables:
|
||||
|
||||
- **devices** (*Optional*): A list of devices with their name to use in the frontend.
|
||||
- **device_defaults**: (*Optional*)
|
||||
- **fire_event_** (*Optional*): Set default `fire_event` for Rflink switch devices (see below).
|
||||
- **signal_repetitions** (*Optional*): Set default `signal_repetitions` for Rflink switch devices (see below).
|
||||
- **fire_event_** (*Optional*): Set default `fire_event` for RFLink switch devices (see below).
|
||||
- **signal_repetitions** (*Optional*): Set default `signal_repetitions` for RFLink switch devices (see below).
|
||||
|
||||
Device configuration variables:
|
||||
|
||||
- **name** (*Optional*): Name for the device, defaults to Rflink ID.
|
||||
- **aliasses** (*Optional*): Alternative Rflink ID's this device is known by.
|
||||
- **name** (*Optional*): Name for the device, defaults to RFLink ID.
|
||||
- **aliasses** (*Optional*): Alternative RFLink ID's this device is known by.
|
||||
- **fire_event_** (*Optional*): Fire an `button_pressed` event if this device is turned on or off (default: False).
|
||||
- **signal_repetitions** (*Optional*): Repeat every Rflink command this number of times (default: 1)
|
||||
- **signal_repetitions** (*Optional*): Repeat every RFLink command this number of times (default: 1)
|
||||
|
||||
### {% linkable_title Switch state %}
|
||||
|
||||
Initially the state of a switch is unknown. When the switch is turned on or off (via frontend or 433Mhz remote) the state is known and will be shown in the frontend.
|
||||
Initially the state of a switch is unknown. When the switch is turned on or off (via frontend or wireless remote) the state is known and will be shown in the frontend.
|
||||
|
||||
Sometimes a switch is controlled by multiple 433Mhz remotes, each remote has its own code programmed in the switch. To allow tracking of the state when switched via other remotes add the corresponding remote codes as aliasses:
|
||||
Sometimes a switch is controlled by multiple wireless remotes, each remote has its own code programmed in the switch. To allow tracking of the state when switched via other remotes add the corresponding remote codes as aliasses:
|
||||
|
||||
```yaml
|
||||
# Example configuration.yaml entry
|
||||
|
||||
@ -12,7 +12,7 @@ ha_category: Automation Examples
|
||||
|
||||
This will send a message when someone in your known devices list connects to your local network. In other words, when someone arrives home. It will only work if you are using the [nmap](/components/device_tracker.nmap_tracker/) device tracker or a similar component.
|
||||
|
||||
This example uses [/components/notify.telegram/](Telegram) to send the notification.
|
||||
This example uses [Telegram](/components/notify.telegram/) to send the notification.
|
||||
|
||||
```yaml
|
||||
notify:
|
||||
|
||||
@ -148,3 +148,20 @@ automation:
|
||||
# Event is either enter or leave
|
||||
event: enter # or "leave"
|
||||
```
|
||||
|
||||
|
||||
### {% linkable_title Multiple triggers %}
|
||||
|
||||
When your want your automation rule to have multiple triggers, just prefix the first line of each trigger with a dash (-) and indent the lines following accordingly. Whenever one of the triggers fires, your rule is executed.
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
trigger:
|
||||
# first trigger
|
||||
- platform: time
|
||||
minutes: 5
|
||||
seconds: 00
|
||||
# our second trigger is the sunset
|
||||
- platform: sun
|
||||
event: sunset
|
||||
```
|
||||
|
||||
@ -122,5 +122,5 @@ The `VACUUM` command cleans the your database.
|
||||
sqlite> VACUUM;
|
||||
```
|
||||
|
||||
For a more interactive way to work with the database or the create statistics, checkout our [Jupyther notebooks](http://nbviewer.jupyter.org/github/home-assistant/home-assistant-notebooks/tree/master/).
|
||||
For a more interactive way to work with the database or the create statistics, checkout our [Jupyter notebooks](http://nbviewer.jupyter.org/github/home-assistant/home-assistant-notebooks/tree/master/).
|
||||
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
layout: page
|
||||
title: "Apache Configuration"
|
||||
description: "Configure Apache to work with home assistant as a subdomain"
|
||||
title: "Apache Proxy"
|
||||
description: "Configure Apache to work with Home Assistant as a subdomain"
|
||||
date: 2016-06-20 13:05
|
||||
sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
redirect_from: /cookbook/apache_configuration/
|
||||
---
|
||||
|
||||
This example demonstrates how you can configure Apache to act as a proxy for Home Assistant.
|
||||
@ -22,7 +22,7 @@ This is useful if you want to have:
|
||||
|
||||
So you already have a working Apache server available at example.org. Your Home Assistant is correctly working on this web server and available at http://localhost:8123
|
||||
|
||||
Enable [`mod_proxy_wstunnel`]((https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.htm) by running if you encounter issues while serving Home Assistant through your proxy:
|
||||
Enable [`mod_proxy_wstunnel`](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.htm) by running if you encounter issues while serving Home Assistant through your proxy:
|
||||
|
||||
```bash
|
||||
$ sudo a2enmod proxy_wstunnel
|
||||
@ -7,7 +7,7 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
redirect_from: /cookbook/githubbackup/
|
||||
---
|
||||
|
||||
Backing up and regularly syncing your Home Assistant configuration to [GitHub](http://GitHub.com) has several benefits:
|
||||
@ -7,17 +7,19 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
redirect_from: /cookbook/tls_domain_certificate/
|
||||
---
|
||||
|
||||
If your Home Assistant instance is only accessible from your local network you can still protect the communication between your browsers and the frontend with SSL/TLS. You can use [Self-sign certificate](/cookbook/tls_self_signed_certificate/) but your browser will present a warning and some https-only features might not work.
|
||||
|
||||
### {% linkable_title Prerequirement for this guide %}
|
||||
|
||||
* Your Home Assistant instance is not exposed to the internet. If it is - use [this guide]({{site_root}}/blog/2015/12/13/setup-encryption-using-lets-encrypt/)
|
||||
* You control a public domain name. The domain doesn't have to point to a site. A domain controlled by a *trusted* friend will do. (A friend you trust not to MITM you)
|
||||
* Your home router supports custom DNS entries.
|
||||
|
||||
### {% linkable_title Run certbot %}
|
||||
|
||||
```bash
|
||||
$ mkdir certbot
|
||||
$ cd certbot
|
||||
@ -44,17 +46,21 @@ Press Enter to Continue
|
||||
```
|
||||
|
||||
* Deploy the value to TXT field using your domain registar.
|
||||
|
||||
* Go to a site that queries domain record. For example [this one](https://mxtoolbox.com/TXTLookup.aspx) and look if it sees your brand new TXT field (Don't forget to enter the full domain: `_acme-challenge.mydomain.com`)
|
||||
* Press Enter at certbot prompt.
|
||||
|
||||
### {% linkable_title Make mydomain.com point to your Home Assistant instance %}
|
||||
|
||||
If your router uses DNSMasq (for example DDWRT) add the following line to DNSMasq options:
|
||||
```
|
||||
|
||||
```text
|
||||
address=/mydomain.com/<hass ip>
|
||||
```
|
||||
|
||||
### {% linkable_title Edit your Home Assistant configuration to use your certificates %}
|
||||
|
||||
The [`http`](/components/http/) section must contain the full path to the needed files.
|
||||
|
||||
```yaml
|
||||
http:
|
||||
api_password: YOUR_SECRET_PASSWORD
|
||||
@ -62,4 +68,5 @@ http:
|
||||
ssl_certificate: /etc/letsencrypt/live/mydomain.com/fullchain.pem
|
||||
ssl_key: /etc/letsencrypt/live/mydomain.com/privkey.pem
|
||||
```
|
||||
|
||||
Make sure the files are accessible by the user that runs Home Assistant, eg. `homeassistant` for a HASSbian setup.
|
||||
@ -7,7 +7,7 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
redirect_from: /cookbook/tls_self_signed_certificate/
|
||||
---
|
||||
|
||||
If your Home Assistant instance is only accessible from your local network you can still protect the communication between your browsers and the frontend with SSL/TLS. [Let's encrypt]({{site_root}}/blog/2015/12/13/setup-encryption-using-lets-encrypt/) will only work if you have a DNS entry and remote access is allowed. The solution is to use a self-signed certificate. As you most likely don't have a certification authority (CA) your browser will conplain about the security. If you have a CA then this will not be an issue.
|
||||
@ -7,12 +7,10 @@ sidebar: true
|
||||
comments: false
|
||||
sharing: true
|
||||
footer: true
|
||||
ha_category: Infrastructure
|
||||
author: Nathan Freitas
|
||||
author_twitter: n8fr8
|
||||
redirect_from: /cookbook/tor_configuration/
|
||||
---
|
||||
|
||||
This is an example about how you can configure Tor to provide secure remote access to your Home Assistant instance as an Onion site, through Tor's Hidden Service feature. With this enabled, you do not need to open your firewall ports or setup HTTPS to enable secure remote access.
|
||||
This is an example about how you can configure Tor to provide secure remote access to your Home Assistant instance as an Onion site, through [Tor's Hidden Service](https://www.torproject.org/docs/hidden-services.html.en) feature. With this enabled, you do not need to open your firewall ports or setup HTTPS to enable secure remote access.
|
||||
|
||||
This is useful if you want to have:
|
||||
|
||||
@ -21,21 +19,19 @@ This is useful if you want to have:
|
||||
* Want to block attackers from even being able to access/scan your port and server at all
|
||||
* Want to block anyone from knowing your home IP address and seeing your traffic to your Home Assistant
|
||||
|
||||
#### {% linkable_title Background and Contact %}
|
||||
## {% linkable_title Background and Contact %}
|
||||
|
||||
This configuration is part of an effort to apply strong cryptography technologies (like Onion Routing and End-to-End Encryption) to technology we increasingly depend on in our day to day lives. Just like when WhatsApp enabled end-to-end encryption messaging for everyone, every home automation and IoT platform should do the same, because A) the technology is all there, freely licensed and open-source and B) up to this point, all the commercial manufacturers have been doing a horrific job with security.
|
||||
|
||||
You can learn more about how Tor can be used to secure home automation and IoT platforms through this short set of slides on the [Internet of Onion Things](https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Onion%20Things.pdf)
|
||||
|
||||
This configuration was provided by @n8fr8 ([github](https://github.com/n8fr8), [twitter](https://twitter.com/n8fr8)) of the [Guardian Project](https://guardianproject.info) and [Tor Project](https://torproject.org). You can send questions, feedback and ideas to [support@guardianproject.info](mailto:support@guardianproject.info).
|
||||
|
||||
#### {% linkable_title Hidden Services and Onion Sites %}
|
||||
## {% linkable_title Hidden Services and Onion Sites %}
|
||||
|
||||
Tor allows clients and relays to offer hidden services. That is, you can offer a web server, SSH server, etc., without revealing your IP address to its users. In fact, because you don't use any public address, you can run a hidden service from behind your firewall. Learn more about Hidden Services on the [Tor Project website](https://www.torproject.org/docs/tor-hidden-service.html.en).
|
||||
|
||||
Onion sites are websites that run on a Tor Hidden Service node. "dot onion" sites are an [IETF recognized special use domain name](https://datatracker.ietf.org/doc/rfc7686/).
|
||||
|
||||
#### {% linkable_title Setting up Tor on your Home Assistant %}
|
||||
## {% linkable_title Setting up Tor on your Home Assistant %}
|
||||
|
||||
First, install Tor. On a Debian-based system, you can install the package easily:
|
||||
|
||||
@ -82,7 +78,7 @@ abcdef1234567890.onion ABCDEF1122334455667789 # client: haremote1
|
||||
|
||||
You are now done with the Home Assistant Tor server configuration. Make sure your Home Assistant instance is running, and now you can move to client configuration.
|
||||
|
||||
#### {% linkable_title Tor Client Access Setup %}
|
||||
## {% linkable_title Tor Client Access Setup %}
|
||||
|
||||
Using this setup, you can access your Home Assistant instance over Tor from your laptop or mobile device, using Tor Browser and other software.
|
||||
|
||||
@ -100,7 +96,7 @@ For [Orbot: Tor on Android](https://guardianproject.info/apps/orbot), add it in
|
||||
|
||||
On iOS, we have not fully tested this yet, but you should be able to add custom torrc entries on [Onion Browser](https://mike.tig.as/onionbrowser/), Red Onion or TOBY browsers, all available in the iTunes App Store.
|
||||
|
||||
#### {% linkable_title Some More Advanced Ideas %}
|
||||
## {% linkable_title Some More Advanced Ideas %}
|
||||
|
||||
With this configuration, only you can access your Home Assistant instance Onion site through Tor, and no one else. You can share the authentication cookie with multiple devices and users, or you can generate a unique one for each - up to you! If you have multiple, say for an industrial, business or corporate configuration, this would provide an easy way to revoke access to a specific user or device.
|
||||
|
||||
@ -110,3 +106,5 @@ You could also use Tor as a means to connect your Home Assistant instance to a r
|
||||
|
||||
As mentioned, with Orbot on Android, you can enable a "full device" VPN mode, that allows any app you have to tunnel through Tor, even if it is not Tor or proxy aware. This means you should be able to enter your "dot onion" Onion site address into any app you want to access to your Home Assistant instance, and it should work.
|
||||
|
||||
This configuration was provided by @n8fr8 ([github](https://github.com/n8fr8), [twitter](https://twitter.com/n8fr8)) of the [Guardian Project](https://guardianproject.info) and [Tor Project](https://torproject.org). You can send questions, feedback and ideas to [support@guardianproject.info](mailto:support@guardianproject.info).
|
||||
|
||||
@ -63,9 +63,14 @@ To upgrade the All-In-One setup manually:
|
||||
* Update HA `pip3 install --upgrade homeassistant`
|
||||
* Type `exit` to logout the hass user and return to the `pi` user.
|
||||
|
||||
<p class='note note'>
|
||||
If you deployed Home Assistant via the AiO installer prior to December 2016, replace `sudo su -s /bin/bash homeassistant` with `sudo su -s /bin/bash hass` and `source /srv/homeassistant/homeassistant_venv/bin/activate` with `source /srv/hass/hass_venv/bin/activate`</p>
|
||||
|
||||
<div class='note note'>
|
||||
**If you deployed Home Assistant via the AiO installer prior to December 2016**
|
||||
* Login to Raspberry Pi `ssh pi@your_raspberry_pi_ip`
|
||||
* Change to homeassistant user `sudo su -s /bin/bash hass`
|
||||
* Change to virtual enviroment `source /srv/hass/hass_venv/bin/activate`
|
||||
* Update HA `pip3 install --upgrade homeassistant`
|
||||
* Type `exit` to logout the hass user and return to the `pi` user.
|
||||
</div>
|
||||
|
||||
To upgrade with fabric:
|
||||
|
||||
@ -96,9 +101,15 @@ To launch the OZWCP web application:
|
||||
* Open a web browser to `http://your_pi_ip:8888`
|
||||
* Specify your zwave controller, for example `/dev/ttyACM0` and hit initialize
|
||||
|
||||
<p class='note note'>
|
||||
If you deployed Home Assistant via the AiO installer prior to December 2016, replace `cd /srv/homeassistant/src/open-zwave-control-panel/` with `cd /srv/hass/src/open-zwave-control-panel/`
|
||||
</p>
|
||||
<div class='note note'>
|
||||
**If you deployed Home Assistant via the AiO installer prior to December 2016**
|
||||
* Make sure Home Assistant is not running! So stop that first
|
||||
* Login to Raspberry Pi `ssh pi@your_raspberry_pi_ip`
|
||||
* Change to the ozwcp directory `cd /srv/hass/src/open-zwave-control-panel/`
|
||||
* Launch the control panel `sudo ./ozwcp -p 8888`
|
||||
* Open a web browser to `http://your_pi_ip:8888`
|
||||
* Specify your zwave controller, for example `/dev/ttyACM0` and hit initialize
|
||||
</div>
|
||||
|
||||
<p class='note warning'>
|
||||
Don't check the USB box regardless of using a USB based device.
|
||||
|
||||
@ -22,7 +22,7 @@ mqtt:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **certificate** (*Optional*): The certificate authority certificate file that is to be treated as trusted by this client. This file should contain the root certificate of the certificate authority that signed your broker's certificate, but may contain multiple certificates. Example: `/home/user/identrust-root.pem`
|
||||
- **certificate** (*Optional*): 'auto' or the certificate authority certificate file that is to be treated as trusted by this client. 'auto' uses the bundled certificates. If a file is specified the file should contain the root certificate of the certificate authority that signed your broker's certificate, but may contain multiple certificates. Example: `/home/user/identrust-root.pem`
|
||||
- **client_key** (*Optional*): Client key, eg. `/home/user/owntracks/cookie.key`.
|
||||
- **client_cert** (*Optional*): Client certificate, eg. `/home/user/owntracks/cookie.crt`.
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ There is currently support for climate, covers, lights, locks, sensors, switches
|
||||
|
||||
### {% linkable_title Installation in Virtualenv (python-OpenZWave) %}
|
||||
|
||||
If you installed Home Assistant using a virtual environment then please read the instructions on [Installing python-OpenZWave in a virtualenv](https://home-assistant.io/getting-started/installation-virtualenv/#installing-python-openzwave-in-a-virtualenv).
|
||||
If you installed Home Assistant using a virtual environment then please read the instructions on [Installing python-OpenZWave in a virtualenv](https://home-assistant.io/docs/installation/virtualenv/#installing-python-openzwave-in-a-virtualenv).
|
||||
|
||||
### {% linkable_title Installation %}
|
||||
|
||||
|
||||
@ -136,7 +136,6 @@
|
||||
<li>{% active_link /docs/ecosystem/appdaemon/api/ AppDaemon API Reference %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
{% active_link /docs/ecosystem/hadashboard/ HADashboard %}
|
||||
<ul>
|
||||
@ -147,7 +146,6 @@
|
||||
<li>{% active_link /docs/ecosystem/hadashboard/updating/ Updating HADashboard %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
{% active_link /docs/ecosystem/notebooks/ Notebooks %}
|
||||
<ul>
|
||||
@ -179,9 +177,24 @@
|
||||
<li>{% active_link /docs/ecosystem/ios/integration/ Integration with other apps %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
Remote access
|
||||
<ul>
|
||||
<li>{% active_link /docs/ecosystem/apache/ Apache %}</li>
|
||||
<li>{% active_link /docs/ecosystem/nginx/ NGINX %}</li>
|
||||
<li>{% active_link /docs/ecosystem/tor/ Tor Onion Service %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
Certificates
|
||||
<ul>
|
||||
<li>{% active_link /docs/ecosystem/certificates/tls_self_signed_certificate/ Self-signed certificate %}</li>
|
||||
<li>{% active_link /docs/ecosystem/certificates/tls_domain_certificate/ Certificate domain owners %}</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>{% active_link /docs/ecosystem/scenegen/ scenegen %}</li>
|
||||
<li>{% active_link /docs/ecosystem/synology/ Synology %}</li>
|
||||
<li>{% active_link /docs/ecosystem/backup/backup_github/ Backup to GitHub %}</li>
|
||||
</ul>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user