diff --git a/source/_integrations/actiontec.markdown b/source/_integrations/actiontec.markdown index 53bf8fc6564..a7d1afc6707 100644 --- a/source/_integrations/actiontec.markdown +++ b/source/_integrations/actiontec.markdown @@ -37,7 +37,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges, usually `admin`. + description: The username of a user with administrative privileges, usually `admin`. required: true type: string password: diff --git a/source/_integrations/alarm_control_panel.template.markdown b/source/_integrations/alarm_control_panel.template.markdown index a17f3f5bc18..7f82d294c55 100644 --- a/source/_integrations/alarm_control_panel.template.markdown +++ b/source/_integrations/alarm_control_panel.template.markdown @@ -108,6 +108,6 @@ panels: ## Considerations -If you are using the state of a integration that takes extra time to load, the Template Alarm Control Panel may get an `unknown` state during startup. This results in error messages in your log file until that integration has completed loading. If you use `is_state()` function in your template, you can avoid this situation. +If you are using the state of an integration that takes extra time to load, the Template Alarm Control Panel may get an `unknown` state during startup. This results in error messages in your log file until that integration has completed loading. If you use `is_state()` function in your template, you can avoid this situation. For example, you would replace {% raw %}`{{ states.switch.source.state == 'on' }}`{% endraw %} with this equivalent that returns `true`/`false` and never gives an unknown result: {% raw %}`{{ is_state('switch.source', 'on') }}`{% endraw %} diff --git a/source/_integrations/aruba.markdown b/source/_integrations/aruba.markdown index 2264bbc4b41..f0f5e85eaae 100644 --- a/source/_integrations/aruba.markdown +++ b/source/_integrations/aruba.markdown @@ -37,7 +37,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges, usually `admin`. + description: The username of a user with administrative privileges, usually `admin`. required: true type: string password: diff --git a/source/_integrations/azure_event_hub.markdown b/source/_integrations/azure_event_hub.markdown index 4379094428d..b84a0a9fd7f 100644 --- a/source/_integrations/azure_event_hub.markdown +++ b/source/_integrations/azure_event_hub.markdown @@ -24,7 +24,7 @@ Once you have the name of your namespace, instance, Shared Access Policy and the The alternative approach is to use a connection string, this can be retrieved in the same way as the Shared Access Policy and this can also be gotten for a device in an IoT Hub (Event Hub-compatible connection string). -The final thing to consider is how often you want the integration to send messages in a batch to your hub, this is set with the `send_interval`, with a default of 5 seconds. The other thing to look at is what the maximum delay you want to use, since this component runs in a asynchronous way there is no guarantee that the sending happens exactly on time, so depending on your semantics you might want messages discarded. The actual check of the time happens with `max_delay` plus `send_interval`, so that even with a long `send_interval` the semantics are the same. +The final thing to consider is how often you want the integration to send messages in a batch to your hub, this is set with the `send_interval`, with a default of 5 seconds. The other thing to look at is what the maximum delay you want to use, since this component runs in an asynchronous way there is no guarantee that the sending happens exactly on time, so depending on your semantics you might want messages discarded. The actual check of the time happens with `max_delay` plus `send_interval`, so that even with a long `send_interval` the semantics are the same. ## Configuration diff --git a/source/_integrations/cisco_ios.markdown b/source/_integrations/cisco_ios.markdown index 8a2ee6a43a4..8e82d99aa0a 100644 --- a/source/_integrations/cisco_ios.markdown +++ b/source/_integrations/cisco_ios.markdown @@ -65,7 +65,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges. + description: The username of a user with administrative privileges. required: true type: string password: diff --git a/source/_integrations/ddwrt.markdown b/source/_integrations/ddwrt.markdown index 44cac97c061..4729c5e1e77 100644 --- a/source/_integrations/ddwrt.markdown +++ b/source/_integrations/ddwrt.markdown @@ -29,7 +29,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges, usually `admin`. + description: The username of a user with administrative privileges, usually `admin`. required: true type: string password: diff --git a/source/_integrations/fireservicerota.markdown b/source/_integrations/fireservicerota.markdown index 777759b72a0..d63bbeaf708 100644 --- a/source/_integrations/fireservicerota.markdown +++ b/source/_integrations/fireservicerota.markdown @@ -80,7 +80,7 @@ This entity reflects the duty you have scheduled, the value can be `on` = on dut ### Incident Response Switch -With this switch you can respond to a incident, either by manually controlling the switch via the GUI, or by using an automation action. +With this switch you can respond to an incident, either by manually controlling the switch via the GUI, or by using an automation action. It gets reset to `unknown` value with every incident received. Switching it to `on` means you send a response acknowledgement, switching it back `off` sends a response rejected. The following attributes are available: diff --git a/source/_integrations/homematic.markdown b/source/_integrations/homematic.markdown index 4b484675dfc..1846d13772b 100644 --- a/source/_integrations/homematic.markdown +++ b/source/_integrations/homematic.markdown @@ -28,7 +28,7 @@ ha_platforms: - switch --- -The [Homematic](https://www.homematic.com/) integration provides bi-directional communication with your CCU/Homegear. It uses a XML-RPC connection to set values on devices and subscribes to receive events the devices and the CCU emit. +The [Homematic](https://www.homematic.com/) integration provides bi-directional communication with your CCU/Homegear. It uses an XML-RPC connection to set values on devices and subscribes to receive events the devices and the CCU emit. If you are using Homegear with paired [Intertechno](https://intertechno.at/) devices, uni-directional communication is possible as well. There is currently support for the following device types within Home Assistant: diff --git a/source/_integrations/influxdb.markdown b/source/_integrations/influxdb.markdown index 6ed20e981c9..3f8ced175a1 100644 --- a/source/_integrations/influxdb.markdown +++ b/source/_integrations/influxdb.markdown @@ -61,7 +61,7 @@ port: default: 8086 path: type: string - description: Path to use if your InfuxDB is running behind an reverse proxy. + description: Path to use if your InfuxDB is running behind a reverse proxy. required: false username: type: string diff --git a/source/_integrations/isy994.markdown b/source/_integrations/isy994.markdown index cd329855a39..bbdc9070558 100644 --- a/source/_integrations/isy994.markdown +++ b/source/_integrations/isy994.markdown @@ -184,7 +184,7 @@ Send a "raw" (e.g., `DON`, `DOF`) ISY REST Device Command to a Node using its Ho #### Service `isy994.get_zwave_parameter` -Request a Z-Wave Device parameter via the ISY. The parameter value will be returned as a entity extra state attribute with the name "ZW#" where "#" is the parameter number. +Request a Z-Wave Device parameter via the ISY. The parameter value will be returned as an entity extra state attribute with the name "ZW#" where "#" is the parameter number. | Service data attribute | Optional | Description | | ---------------------- | -------- | ----------------------------------------------------------------------------------------------- | @@ -193,7 +193,7 @@ Request a Z-Wave Device parameter via the ISY. The parameter value will be retur #### Service `isy994.set_zwave_parameter` -Update a Z-Wave Device parameter via the ISY. The parameter value will also be returned as a entity extra state attribute with the name "ZW#" where "#" is the parameter number. +Update a Z-Wave Device parameter via the ISY. The parameter value will also be returned as an entity extra state attribute with the name "ZW#" where "#" is the parameter number. | Service data attribute | Optional | Description | | ---------------------- | -------- | ----------------------------------------------------------------------------------------------- | diff --git a/source/_integrations/light.template.markdown b/source/_integrations/light.template.markdown index 92cf57d5a71..a5526929d1a 100644 --- a/source/_integrations/light.template.markdown +++ b/source/_integrations/light.template.markdown @@ -174,7 +174,7 @@ light: required: false type: action set_effect: - description: Defines an action to run when the light is given a effect command. + description: Defines an action to run when the light is given an effect command. required: inclusive type: action {% endconfiguration %} diff --git a/source/_integrations/luci.markdown b/source/_integrations/luci.markdown index 64b163239aa..29c6c839894 100644 --- a/source/_integrations/luci.markdown +++ b/source/_integrations/luci.markdown @@ -37,7 +37,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges, usually `admin`. + description: The username of a user with administrative privileges, usually `admin`. required: true type: string password: diff --git a/source/_integrations/mcp23017.markdown b/source/_integrations/mcp23017.markdown index 69f3e6df95f..f8ccfd7f30a 100644 --- a/source/_integrations/mcp23017.markdown +++ b/source/_integrations/mcp23017.markdown @@ -29,7 +29,7 @@ The pin numbers are from 0 to 15 where: 0-7 correspond to port A (A1-A8) and 8-1 ### Configuration -To use the I/O pins of an mcp23017 connected to an I2C bus of your Raspberry Pi as binary sensors, add the following to your `configuration.yaml` file: +To use the I/O pins of a mcp23017 connected to an I2C bus of your Raspberry Pi as binary sensors, add the following to your `configuration.yaml` file: ```yaml # Example configuration.yaml entry @@ -87,7 +87,7 @@ The pin numbers are from 0 to 15 where: 0-7 correspond to port A (A1-A8) and 8-1 ### Configuration -To use the I/O pins of an mcp23017 connected to an I2C bus of your Raspberry Pi as switches, add the following to your `configuration.yaml` file: +To use the I/O pins of a mcp23017 connected to an I2C bus of your Raspberry Pi as switches, add the following to your `configuration.yaml` file: ```yaml # Example configuration.yaml entry diff --git a/source/_integrations/modbus.markdown b/source/_integrations/modbus.markdown index 8c843a25607..2ad94f1918d 100644 --- a/source/_integrations/modbus.markdown +++ b/source/_integrations/modbus.markdown @@ -436,7 +436,7 @@ covers: default: 0 type: integer state_opening: - description: A value in `status_register` or `register` representing a opening cover. Note that this state should be also supported on your connected Modbus cover. If it won't report the state, this state won't be detected. + description: A value in `status_register` or `register` representing an opening cover. Note that this state should be also supported on your connected Modbus cover. If it won't report the state, this state won't be detected. required: false default: 2 type: integer @@ -446,7 +446,7 @@ covers: default: 3 type: integer status_register: - description: An address of an register, from which all the cover states will be read. If you specified `register` attribute, and not `status_register` attribute, your main register will also be used as a status register. + description: An address of a register, from which all the cover states will be read. If you specified `register` attribute, and not `status_register` attribute, your main register will also be used as a status register. required: false type: integer status_register_type: diff --git a/source/_integrations/nest.markdown b/source/_integrations/nest.markdown index c774c59a353..f7080e34058 100644 --- a/source/_integrations/nest.markdown +++ b/source/_integrations/nest.markdown @@ -349,7 +349,7 @@ action: image: /api/camera_proxy/camera.front_door ``` -The action in this section uses the [Android Companion App](https://companion.home-assistant.io/docs/notifications/notifications-basic/) and the camera proxy to send an notification with a snapshot from the camera. +The action in this section uses the [Android Companion App](https://companion.home-assistant.io/docs/notifications/notifications-basic/) and the camera proxy to send a notification with a snapshot from the camera. # Legacy Works With Nest API diff --git a/source/_integrations/numato.markdown b/source/_integrations/numato.markdown index 09eb5b166f9..a516fd58199 100644 --- a/source/_integrations/numato.markdown +++ b/source/_integrations/numato.markdown @@ -179,7 +179,7 @@ documentation](https://numato.com/docs/32-channel-usb-gpio-module-with-analog-in ## Device IDs -This integration uses a internal device ID to identify the device, which is +This integration uses an internal device ID to identify the device, which is _not_ the Linux device path. The Linux device path (e.g., `/dev/ttyACM0`) can change, for example, when you disconnect and re-connect the device or if you connect the device to a different USB port. diff --git a/source/_integrations/pi4ioe5v9xxxx.markdown b/source/_integrations/pi4ioe5v9xxxx.markdown index f28b0f6685f..526ab65d634 100644 --- a/source/_integrations/pi4ioe5v9xxxx.markdown +++ b/source/_integrations/pi4ioe5v9xxxx.markdown @@ -33,7 +33,7 @@ The pin numbers are from 1 to X where: 1-8 correspond to port 0 (00-07) and 9-16 ### Configuration -To use the I/O pins of an pi4ioe5v9xxxx connected to an I2C bus of your Raspberry Pi as binary sensors, add the following to your `configuration.yaml` file: +To use the I/O pins of a pi4ioe5v9xxxx connected to an I2C bus of your Raspberry Pi as binary sensors, add the following to your `configuration.yaml` file: ```yaml # Example configuration.yaml entry @@ -91,7 +91,7 @@ The pin numbers are from 1 to X, where 1-8 correspond to port A (A1-A8) and 9-16 ### Configuration -To use the I/O pins of an pi4ioe5v9xxxx connected to an I2C bus as switches, add the following to your `configuration.yaml` file: +To use the I/O pins of a pi4ioe5v9xxxx connected to an I2C bus as switches, add the following to your `configuration.yaml` file: ```yaml # Example configuration.yaml entry diff --git a/source/_integrations/rpi_gpio_pwm.markdown b/source/_integrations/rpi_gpio_pwm.markdown index c2b0b5a9e31..c37c29e3f25 100644 --- a/source/_integrations/rpi_gpio_pwm.markdown +++ b/source/_integrations/rpi_gpio_pwm.markdown @@ -103,7 +103,7 @@ light: type: rgbw ``` -### RGB LED connected to the GPIO pins of an remote Raspberry Pi. +### RGB LED connected to the GPIO pins of a remote Raspberry Pi. On the Raspberry Pi the pigpio daemon is running on the default port 6666. diff --git a/source/_integrations/scrape.markdown b/source/_integrations/scrape.markdown index 654aa408980..08adea24ebc 100644 --- a/source/_integrations/scrape.markdown +++ b/source/_integrations/scrape.markdown @@ -12,7 +12,7 @@ ha_platforms: - sensor --- -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 web pages and it can be time-consuming to get the right section. +The `scrape` sensor platform is scraping information from websites. The sensor loads an 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 web pages and it can be time-consuming to get the right section. To enable this sensor, add the following lines to your `configuration.yaml` file: diff --git a/source/_integrations/sensehat.markdown b/source/_integrations/sensehat.markdown index c3376342bdf..f2adbcc264c 100644 --- a/source/_integrations/sensehat.markdown +++ b/source/_integrations/sensehat.markdown @@ -185,7 +185,7 @@ sudo reboot ``` Unfortunately enabling the SenseHAT Sensor integration for a Virtual Environment install of Home Assistant fails with errors. -_(The Raspberry Pi All-In-One installer run Home Assistant in an virtual environment)._ +_(The Raspberry Pi All-In-One installer run Home Assistant in a virtual environment)._ These issues have been discussed in the repository issue [#5093](https://github.com/home-assistant/home-assistant/issues/5093) This fix has been tested with a clean install of: diff --git a/source/_integrations/serial_pm.markdown b/source/_integrations/serial_pm.markdown index e07f2863b2c..ef29975c235 100644 --- a/source/_integrations/serial_pm.markdown +++ b/source/_integrations/serial_pm.markdown @@ -12,7 +12,7 @@ ha_platforms: Particulate matter sensors measure the amount of very small particles in the air. A short introduction how these sensors work can be found on [Open Home Automation](https://www.open-homeautomation.com/2016/07/19/measuring-air-quality/). -Cheap LED based sensors usually use a GPIO interface that is hard to attach to computers. However, there are a lot of laser LED based sensors on the market that use a serial interface and can be [connected to your Home Assistant system easily with an USB to serial converter](https://www.open-homeautomation.com/2016/07/20/connecting-an-particulate-matter-sensor-to-your-pc-or-mac/). +Cheap LED based sensors usually use a GPIO interface that is hard to attach to computers. However, there are a lot of laser LED based sensors on the market that use a serial interface and can be [connected to your Home Assistant system easily with a USB to serial converter](https://www.open-homeautomation.com/2016/07/20/connecting-an-particulate-matter-sensor-to-your-pc-or-mac/). ## Supported Sensors diff --git a/source/_integrations/shell_command.markdown b/source/_integrations/shell_command.markdown index 0b77b8a4fd0..9ff98e724a5 100644 --- a/source/_integrations/shell_command.markdown +++ b/source/_integrations/shell_command.markdown @@ -56,7 +56,7 @@ shell_command: ### Automation example -This is a an example of an shell command used in conjunction with an input +This is an example of a shell command used in conjunction with an input helper and an automation. {% raw %} diff --git a/source/_integrations/sia.markdown b/source/_integrations/sia.markdown index 6a4947db996..990a73b3e62 100644 --- a/source/_integrations/sia.markdown +++ b/source/_integrations/sia.markdown @@ -43,10 +43,10 @@ ping_interval: zones: description: The number of zones configured in your alarm. additional_account: - description: Used to ask if a additional account needs to be included, if so will open a dialog for the next account, after checking the current input. + description: Used to ask if an additional account needs to be included, if so will open a dialog for the next account, after checking the current input. {% endconfiguration_basic %} -ASCII characters are 0-9 and ABCDEF, so a account is something like `346EB` and the encryption key has the same characters but needs to be 16, 24 or 32 characters in length. +ASCII characters are 0-9 and ABCDEF, so an account is something like `346EB` and the encryption key has the same characters but needs to be 16, 24 or 32 characters in length. ### Note on monitoring multiple alarm systems @@ -54,7 +54,7 @@ If you have multiple accounts (alarm systems) that you want to monitor you can c ### Port usage -The port used with this component must be a port no other processes use on the machine your HA instance is running. If you have a complex network setup or want to monitor alarm systems at other locations you will most likely have to open firewalls and/or create network routes for that purpose, the integration will just listen for messages coming into that port, and will not proactively send, only responding with a acknowledgement to the alarm system. +The port used with this component must be a port no other processes use on the machine your HA instance is running. If you have a complex network setup or want to monitor alarm systems at other locations you will most likely have to open firewalls and/or create network routes for that purpose, the integration will just listen for messages coming into that port, and will not proactively send, only responding with an acknowledgement to the alarm system. ### Entities diff --git a/source/_integrations/smartthings.markdown b/source/_integrations/smartthings.markdown index 450af8f345c..69873a3e079 100644 --- a/source/_integrations/smartthings.markdown +++ b/source/_integrations/smartthings.markdown @@ -60,7 +60,7 @@ The PAT is used to create a Home Assistant SmartApp in your SmartThings account ### Webhook -This integration requires an internet accessible incoming webhook to receive push updates from SmartThings. The preferred approach is to subscribe to [Home Assistant Cloud (Nabu Casa)](https://www.nabucasa.com/) and the integration will configure and use a cloudhook automatically. Alternatively, you will have to configure and setup a internet accessible webhook in Home Assistant as described below: +This integration requires an internet accessible incoming webhook to receive push updates from SmartThings. The preferred approach is to subscribe to [Home Assistant Cloud (Nabu Casa)](https://www.nabucasa.com/) and the integration will configure and use a cloudhook automatically. Alternatively, you will have to configure and setup an internet accessible webhook in Home Assistant as described below: 1. Setup [remote access](/docs/configuration/remote/) via a domain name secured with SSL. *Self-signed SSL certificates are not supported by the SmartThings Cloud API.* 1. Set the external URL in the Home Assistant [configuration](/docs/configuration/basic) to the URL that Home Assistant is available on the internet (this must start with `https://`). diff --git a/source/_integrations/solaredge_local.markdown b/source/_integrations/solaredge_local.markdown index 6ef55234a72..620760f7361 100644 --- a/source/_integrations/solaredge_local.markdown +++ b/source/_integrations/solaredge_local.markdown @@ -18,7 +18,7 @@ The `solaredge_local` platform uses the local API available on some SolarEdge In Only specific models support the local API. The local API is available on inverters that do not have an LCD character screen. You can also check the datasheets if in the section "Additional Features", sub-section "Inverter Commissioning" is present the following line "With the SetApp mobile application using built-in Wi-Fi access point for local connection". These inverters also have a part number that ends with a 4. For example: SEXXK-XXXXXBXX4 or SEXXXXH-XXXXXBXX4 -You can check if the local API works by finding the IP address of your inverter and visiting it in a browser. If it supports the local API, you'll see a HTML page with the SolarEdge logo and a "Commissioning" menu. +You can check if the local API works by finding the IP address of your inverter and visiting it in a browser. If it supports the local API, you'll see an HTML page with the SolarEdge logo and a "Commissioning" menu.
diff --git a/source/_integrations/telegram.markdown b/source/_integrations/telegram.markdown index 55c5243a0ce..fd1d2a104ed 100644 --- a/source/_integrations/telegram.markdown +++ b/source/_integrations/telegram.markdown @@ -245,11 +245,11 @@ action: {% configuration %} url: - description: A remote path to an video. Either this or the `file` configuration option is required. + description: A remote path to a video. Either this or the `file` configuration option is required. required: true type: string file: - description: A local path to an video. Either this or the `url` configuration option is required. + description: A local path to a video. Either this or the `url` configuration option is required. required: true type: string caption: diff --git a/source/_integrations/thomson.markdown b/source/_integrations/thomson.markdown index ec7d72412c9..26d79ac69b4 100644 --- a/source/_integrations/thomson.markdown +++ b/source/_integrations/thomson.markdown @@ -31,7 +31,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges, usually *admin*. + description: The username of a user with administrative privileges, usually *admin*. required: true type: string password: diff --git a/source/_integrations/tomato.markdown b/source/_integrations/tomato.markdown index 5a9b6f6e25c..558f8d5c3ce 100644 --- a/source/_integrations/tomato.markdown +++ b/source/_integrations/tomato.markdown @@ -60,7 +60,7 @@ verify_ssl: type: [string, boolean] default: true username: - description: "The username of an user with administrative privileges, usually *admin*." + description: "The username of a user with administrative privileges, usually *admin*." required: true type: string password: diff --git a/source/_integrations/tts.markdown b/source/_integrations/tts.markdown index 39e370ec8a7..14cf93d0069 100644 --- a/source/_integrations/tts.markdown +++ b/source/_integrations/tts.markdown @@ -26,7 +26,7 @@ tts:
-Depending on your setup, you might need to set a external URL (`external_url`) inside the [configuration](/docs/configuration/basic/) or in the parameters of this component. +Depending on your setup, you might need to set an external URL (`external_url`) inside the [configuration](/docs/configuration/basic/) or in the parameters of this component.
@@ -97,7 +97,7 @@ The Google cast devices (Google Home, Chromecast, etc.) present the following pr * They [reject self-signed certificates](#self-signed-certificates). -* They do not work with URLs that contain hostnames established by local naming means. Let's say your Home Assistant instance is running on a machine made known locally as `ha`. All your machines on your local network are able to access it as `ha`. However, try as you may, your cast device won't download the media files from your `ha` machine. That's because your cast device ignores your local naming setup. In this example, the `say` service creates a URL like `http://ha/path/to/media.mp3` (or `https://...` if you are using SSL). If you are _not_ using SSL then setting a internal URL that contains the IP address of your server works around this issue. By using an IP address, the cast device does not have to resolve the hostname. +* They do not work with URLs that contain hostnames established by local naming means. Let's say your Home Assistant instance is running on a machine made known locally as `ha`. All your machines on your local network are able to access it as `ha`. However, try as you may, your cast device won't download the media files from your `ha` machine. That's because your cast device ignores your local naming setup. In this example, the `say` service creates a URL like `http://ha/path/to/media.mp3` (or `https://...` if you are using SSL). If you are _not_ using SSL then setting an internal URL that contains the IP address of your server works around this issue. By using an IP address, the cast device does not have to resolve the hostname. * If you are using an SSL (e.g., `https://yourhost.example.org/...`) then you _must_ use the hostname in the certificate (e.g., `base_url: https://yourhost.example.org`). You cannot use an IP address since the certificate won't be valid for the IP address, and the cast device will refuse the connection. diff --git a/source/_integrations/ubus.markdown b/source/_integrations/ubus.markdown index 98d47915cb5..4ed1603edf2 100644 --- a/source/_integrations/ubus.markdown +++ b/source/_integrations/ubus.markdown @@ -68,7 +68,7 @@ host: required: true type: string username: - description: The username of an user with administrative privileges, usually `root`. + description: The username of a user with administrative privileges, usually `root`. required: true type: string password: diff --git a/source/_integrations/universal.markdown b/source/_integrations/universal.markdown index 2a46a6f807b..6d644ccd858 100644 --- a/source/_integrations/universal.markdown +++ b/source/_integrations/universal.markdown @@ -13,7 +13,7 @@ ha_platforms: Universal Media Players combine multiple existing entities in Home Assistant into one media player entity. This is used for creating a single entity that controls an entire media center. -Multiple media player entities can be controlled from an universal media player. Additionally, the universal media player allows volume and power commands to be re-routed to other entities in Home Assistant. This allows the power and volume to control external devices like a television or audio receiver. +Multiple media player entities can be controlled from a universal media player. Additionally, the universal media player allows volume and power commands to be re-routed to other entities in Home Assistant. This allows the power and volume to control external devices like a television or audio receiver. A Universal Media Player is created in `configuration.yaml` as follows. @@ -161,7 +161,7 @@ media_player: In this example, a [Kodi Media Player](/integrations/kodi) runs in a CEC capable device (OSMC/OpenElec running in a Raspberry Pi 24/7, for example), and, with the JSON-CEC Kodi add-on installed, it can turn on and off the attached TV. -We store the state of the attached TV in a [input boolean](/integrations/input_boolean/), so we can differentiate the TV being on or off, while Kodi is always 'idle', and use the universal media player to render its state with a template. We now can differentiate between the 'idle' and the 'off' state (being the second when it is idle and the TV is off). +We store the state of the attached TV in an [input boolean](/integrations/input_boolean/), so we can differentiate the TV being on or off, while Kodi is always 'idle', and use the universal media player to render its state with a template. We now can differentiate between the 'idle' and the 'off' state (being the second when it is idle and the TV is off). Because the input boolean used to store the TV state is only changing when using the Home Assistant `turn_on` and `turn_off` actions, and Kodi could be controlled by so many ways, we also define some automations to update this Input Boolean when needed. diff --git a/source/_integrations/yeelight.markdown b/source/_integrations/yeelight.markdown index 4b96ebea7eb..1290ccd22dc 100644 --- a/source/_integrations/yeelight.markdown +++ b/source/_integrations/yeelight.markdown @@ -35,10 +35,10 @@ Possible transitions are `RGBTransition`, `HSVTransition`, `TemperatureTransitio Where the array values are as per the following: -- RGBTransition: [red, green, blue, duration, brightness] with red/green/blue being an number between 0 and 255, the duration being in milliseconds (with a minimum of 50) and the final brightness to transition to 1-100 (%). -- HSVTransition: [hue, saturation, duration, brightness] with hue being an number between 0 and 359, saturation 0 -100, the duration in milliseconds (with a minimum of 50) and the final brightness 1-100 (%). +- RGBTransition: [red, green, blue, duration, brightness] with red/green/blue being a number between 0 and 255, the duration being in milliseconds (with a minimum of 50) and the final brightness to transition to 1-100 (%). +- HSVTransition: [hue, saturation, duration, brightness] with hue being a number between 0 and 359, saturation 0 -100, the duration in milliseconds (with a minimum of 50) and the final brightness 1-100 (%). - TemperatureTransition: [temp, duration, brightness] with temp being the final color temperature between 1700 and 6500, the duration in milliseconds (with a minimum of 50) and the final brightness to transition to 1-100 (%). -- SleepTransition: [duration] with duration being an number for the effect time in milliseconds (with a minimum of 50). +- SleepTransition: [duration] with duration being a number for the effect time in milliseconds (with a minimum of 50). More info about transitions and their expected parameters can be found in [python-yeelight documentation](https://yeelight.readthedocs.io/en/stable/flow.html).