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-21 16:27:19 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add Hue to breaking changes (#11773)

Browse Source 
* Add Hue to breaking changes

* Update hue docs

* Remove breaking change, will mark it deprecated in 104.1

* Hue breaking change

* Reinstate formatting config
This commit is contained in:
Paulus Schoutsen 2020-01-16 11:28:45 -08:00 committed by GitHub
parent ee3ce9405a
commit 1e2586bd84
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 12 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
source/_integrations/hue.markdown
View File

@ -7,11 +7,11 @@ ha_category:
- Light
ha_iot_class: Local Polling
featured: true
ha_release: '0.60'
ha_release: "0.60"
ha_config_flow: true
ha_quality_scale: platinum
ha_codeowners:
- '@balloob'
- "@balloob"
---
Philips Hue support is integrated into Home Assistant as a hub that can drive the light and sensor platforms. The preferred way to set up the Philips Hue platform is by enabling the [discovery component](/integrations/discovery/).
@ -46,10 +46,6 @@ allow_unreachable:
required: false
type: boolean
default: false
filename:
description: Make this unique if specifying multiple Hue bridges.
required: false
type: string
allow_hue_groups:
description: Disable this to stop Home Assistant from importing the groups defined on the Hue bridge.
required: false
@ -70,18 +66,14 @@ hue:
### Multiple Hue bridges
Multiple Hue bridges work transparently with discovery, so you don't have to do anything special to set them up. If you prefer to configure them manually and use multiple Hue bridges, then you need to provide a configuration file for every bridge. The bridges can't share a single configuration file.
Add `filename` to your Hue configuration entry in your `configuration.yaml` file:
Multiple Hue bridges work transparently with discovery, so you don't have to do anything special to set them up.
```yaml
# Example configuration.yaml entry
hue:
bridges:
- host: BRIDGE1_IP_ADDRESS
filename: phue.conf
- host: BRIDGE2_IP_ADDRESS
filename: phue2.conf
```
### Using Hue Groups in Home Assistant
@ -135,12 +127,12 @@ script:
scene_name: "Porch Orange"
```
| Service data attribute | Optional | Description |
| ---------------------- | -------- | ----------- |
| `group_name` | no | The group/room name of the lights. Find this in the official Hue app.
| `scene_name` | no | The name of the scene. Find this in the official Hue app.
| Service data attribute | Optional | Description |
| ---------------------- | -------- | --------------------------------------------------------------------- |
| `group_name` | no | The group/room name of the lights. Find this in the official Hue app. |
| `scene_name` | no | The name of the scene. Find this in the official Hue app. |
*Note*: `group_name` is not a reference to a Home Assistant group name. It can only be the name of a group/room in the Hue app.
_Note_: `group_name` is not a reference to a Home Assistant group name. It can only be the name of a group/room in the Hue app.
### Finding Group and Scene Names

6
source/_posts/2020-01-15-release-104.markdown
View File

@ -235,6 +235,8 @@ Make sure to fill in all fields of the issue template, that is helping us a lot!
([@balloob] - [#23789]) ([automation docs]) ([calendar docs]) ([cover docs]) ([device_tracker docs]) ([fan docs]) ([light docs]) ([lock docs]) ([plant docs]) ([remember_the_milk docs]) ([remote docs]) ([script docs]) ([switch docs]) ([vacuum docs]).
- __Hue__ - Hue will no longer import existing authentication from disk. It has not written this authentication to disk since March 2018. The config option has been deprecated and will be removed in 0.106. ([@balloob] - [#30000]) ([hue docs])
- __UPnP__ - UPnP/IGD units of measurement have been aligned with other integrations and common uses, they're now kB and kB/s instead of kbyte and kbyte/sec respectively. - ([@scop] - [#29552]) ([upnp docs])
- __Worx Landroid__ - The `worxlandroid` sensor has been changed to not return the hardcoded state values `manual-stop`, `charging`, `charging-complete`, `going-home`, `mowing`, instead use the states given from the Landroid to Home Assistant.
@ -242,7 +244,7 @@ Make sure to fill in all fields of the issue template, that is helping us a lot!
This includes the state `idle`, which means that something is broken with the mower. You can use this as a notification to check the physical state of the mower.
You need to update any automations that depend on the state of the sensor.
([@geraldhansen] - [#27453]) ([worxlandroid docs])
- __Apple iCloud__ - The iCloud component is no longer part of the device tracker platform and is now an integration, which is configurable via the UI. The iCloud cookie folder moved from `[HA_dir]/icloud` to `[HA_dir]/.storage/icloud`.- ([@Quentame] - [#28968]) ([icloud docs])
@ -366,7 +368,7 @@ Make sure to fill in all fields of the issue template, that is helping us a lot!
- __Binary Sensor (Locks)__ - Updated ON/OFF condition and triggers to match the documentation and UI. This change inverts the logic of automations relating to binary sensor with the `lock` device class, but only for automations triggering on the lock state (rather than triggering a lock/unlock action).
If you already created automations, you will need to check those, as they probably need to be inverted. The text displayed in the trigger or condition dropdowns in Lovelace will now be correct.
One possible scenario is if you have set an automation using the state of one lock to trigger an action on other lock(s). This change would cause the action to trigger on `locking` if it was previously triggering on `unlocking`. - ([@davet2001] - [#30663]) ([binary_sensor docs])
## Beta Fixes