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

Complete deprecation of hidden attribute (#13824)

Browse Source
This commit is contained in:
Franck Nijhof 2020-06-24 01:04:07 +02:00 committed by GitHub
parent ef8938ac2a
commit 17170ded95
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
17 changed files with 39 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
source/_docs/configuration/customizing-devices.markdown
View File

@ -35,11 +35,6 @@ friendly_name:
description: Name of the entity as displayed in the UI.
required: false
type: string
hidden:
description: Set to `true` to hide the entity in the automatically generated Lovelace view.
required: false
type: boolean
default: false
entity_picture:
description: URL to use as picture for entity.
required: false
@ -94,8 +89,6 @@ homeassistant:
customize:
# Add an entry for each entity that you want to overwrite.
sensor.living_room_motion:
hidden: true
thermostat.family_room:
entity_picture: https://example.com/images/nest.jpg
friendly_name: Nest
@ -118,7 +111,7 @@ homeassistant:
"light.kitchen_*":
icon: mdi:description
"scene.month_*_colors":
hidden: true
icon: mdi:other
```
### Reloading customize

35
source/_docs/configuration/state_object.markdown
View File

@ -10,28 +10,27 @@ If you overwrite a state via the states dev tool or the API, it will not impact
All states will always have an entity id, a state and a timestamp when last updated and last changed.
Field | Description
----- | -----------
`state.state` | String representation of the current state of the entity. Example `off`.
`state.entity_id` | Entity ID. Format: `<domain>.<object_id>`. Example: `light.kitchen`.
`state.domain` | Domain of the entity. Example: `light`.
`state.object_id` | Object ID of entity. Example: `kitchen`.
`state.name` | Name of the entity. Based on `friendly_name` attribute with fall back to object ID. Example: `Kitchen Ceiling`.
`state.last_updated` | Time the state was written to the state machine in UTC time. Note that writing the exact same state including attributes will not result in this field being updated. Example: `2017-10-28 08:13:36.715874+00:00`.
`state.last_changed` | Time the state changed in the state machine in UTC time. This is not updated when there are only updated attributes. Example: `2017-10-28 08:13:36.715874+00:00`.
`state.attributes` | A dictionary with extra attributes related to the current state.
| Field | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `state.state` | String representation of the current state of the entity. Example `off`. |
| `state.entity_id` | Entity ID. Format: `<domain>.<object_id>`. Example: `light.kitchen`. |
| `state.domain` | Domain of the entity. Example: `light`. |
| `state.object_id` | Object ID of entity. Example: `kitchen`. |
| `state.name` | Name of the entity. Based on `friendly_name` attribute with fall back to object ID. Example: `Kitchen Ceiling`. |
| `state.last_updated` | Time the state was written to the state machine in UTC time. Note that writing the exact same state including attributes will not result in this field being updated. Example: `2017-10-28 08:13:36.715874+00:00`. |
| `state.last_changed` | Time the state changed in the state machine in UTC time. This is not updated when there are only updated attributes. Example: `2017-10-28 08:13:36.715874+00:00`. |
| `state.attributes` | A dictionary with extra attributes related to the current state. |
The attributes of an entity are optional. There are a few attributes that are used by Home Assistant for representing the entity in a specific way. Each integration will also have its own attributes to represent extra state data about the entity. For example, the light integration has attributes for the current brightness and color of the light. When an attribute is not available, Home Assistant will not write it to the state.
When using templates, attributes will be available by their name. For example `state.attributes.assumed_state`.
Attribute | Description
--------- | -----------
`friendly_name` | Name of the entity. Example: `Kitchen Ceiling`.
`icon` | Icon to use for the entity in the frontend. Example: `mdi:home`.
`entity_picture` | URL to a picture that should be used instead of showing the domain icon. Example: `http://example.com/picture.jpg`.
`assumed_state` | Boolean if the current state is an assumption. [More info](/blog/2016/02/12/classifying-the-internet-of-things/#classifiers) Example: `True`.
`unit_of_measurement` | The unit of measurement the state is expressed in. Used for grouping graphs or understanding the entity. Example: `°C`.
`hidden` | Boolean if the entity should not be shown in the frontend. Example: `true`. This does not apply to the Lovelace UI, and is only relevant for the old `states` UI.
| Attribute | Description |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `friendly_name` | Name of the entity. Example: `Kitchen Ceiling`. |
| `icon` | Icon to use for the entity in the frontend. Example: `mdi:home`. |
| `entity_picture` | URL to a picture that should be used instead of showing the domain icon. Example: `http://example.com/picture.jpg`. |
| `assumed_state` | Boolean if the current state is an assumption. [More info](/blog/2016/02/12/classifying-the-internet-of-things/#classifiers) Example: `True`. |
| `unit_of_measurement` | The unit of measurement the state is expressed in. Used for grouping graphs or understanding the entity. Example: `°C`. |
When an attribute contains spaces, you can retrieve it like this: `states.sensor.livingroom.attributes["Battery numeric"]`.

4
source/_integrations/binary_sensor.template.markdown
View File

@ -141,9 +141,7 @@ binary_sensor:
### Switch as Sensor
Some movement sensors and door/window sensors will appear as a switch. By using
a Template Binary Sensor, the switch can be displayed as a binary sensors. The
original switch can then be hidden by
[customizing](/getting-started/customizing-devices/).
a Template Binary Sensor, the switch can be displayed as a binary sensors.
{% raw %}

2
source/_integrations/config.markdown
View File

@ -65,4 +65,4 @@ This section enables you to control your Z-Wave network and devices from within
### Customization
This section enables you to customize entities within Home Assistant. Use this to set friendly names, change icons, hide entities, and modify other attributes.
This section enables you to customize entities within Home Assistant. Use this to set friendly names, change icons, and modify other attributes.

2
source/_integrations/cover.rflink.markdown
View File

@ -54,7 +54,7 @@ After configuring the RFLink Somfy RTS you have to add the cover to the `configu
RFLink cover ID's are composed of: protocol, id, and gateway. For example: `RTS_0100F2_0`.
Once the ID of a cover is known, it can be used to configure the cover in Home Assistant, for example, to add it to a different group, hide it or set a nice name.
Once the ID of a cover is known, it can be used to configure the cover in Home Assistant, for example, to add it to a different group or set a nice name.
Configuring devices as a cover:

2
source/_integrations/egardia.markdown
View File

@ -12,7 +12,7 @@ ha_codeowners:
ha_domain: egardia
---
The `egardia` platform enables the ability to control an [Egardia](https://egardia.com/)/[Woonveilig](https://woonveilig.nl) control panel. These alarm panels are known under different brand names across the world, including Woonveilig in the Netherlands. This was tested on the WL-1716, GATE-01, GATE-02 and GATE-03 versions of the Egardia/Woonveilig platform. Not only will you integrate your alarm control panel, supported sensors (door contacts at this moment) will be added automatically (hidden by default).
The `egardia` platform enables the ability to control an [Egardia](https://egardia.com/)/[Woonveilig](https://woonveilig.nl) control panel. These alarm panels are known under different brand names across the world, including Woonveilig in the Netherlands. This was tested on the WL-1716, GATE-01, GATE-02 and GATE-03 versions of the Egardia/Woonveilig platform. Not only will you integrate your alarm control panel, supported sensors (door contacts at this moment) will be added automatically.
You will need to know the IP of your alarm panel on your local network. Test if you can login to the panel by browsing to the IP address and log in using your Egardia/Woonveilig account.

2
source/_integrations/homematic.markdown
View File

@ -44,7 +44,7 @@ Since CCU Version 3, the internal firewalls are enabled by default. You have to
If you want to see if a specific device you have is supported, head over to the [pyhomematic](https://github.com/danielperna84/pyhomematic/tree/master/pyhomematic/devicetypes) repository and browse through the source code. A dictionary with the device identifiers (e.g., HM-Sec-SC-2) can be found within the relevant modules near the bottom. If your device is not supported, feel free to contribute.
We automatically detect all devices we currently support and try to generate useful names. If you enable name-resolving, we try to fetch names from Metadata (Homegear), via JSON-RPC or the XML-API you may have installed on your CCU. Since this may fail this is disabled by default.
You can manually rename the created entities by using Home Assistant's [Customizing](/docs/configuration/customizing-devices/) feature. With it you are also able to hide entities you don't want to see in the UI. The Homematic integration is also supported by the [Entity Registry](https://developers.home-assistant.io/docs/en/entity_registry_index.html), which allows you to change the friendly name and the entity ID directly in the Home Assistant UI.
You can manually rename the created entities by using Home Assistant's [Customizing](/docs/configuration/customizing-devices/) feature. The Homematic integration is also supported by the [Entity Registry](https://developers.home-assistant.io/docs/en/entity_registry_index.html), which allows you to change the friendly name and the entity ID directly in the Home Assistant UI.
To set up the component, add the following information to your `configuration.yaml` file:

2
source/_integrations/light.rflink.markdown
View File

@ -17,7 +17,7 @@ After configuring the RFLink hub, lights will be automatically discovered and ad
RFLink binary_sensor/switch/light ID's are composed of: protocol, id, switch/channel. 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.
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 or configure a nice name.
Configuring devices as a light:

2
source/_integrations/lock.template.markdown
View File

@ -13,7 +13,7 @@ The `template` platform creates locks that combines components.
For example, if you have a garage door with a toggle switch that operates the motor and a sensor that allows you know whether the door is open or closed, you can combine these into a lock that knows whether the garage door is open or closed.
This can simplify the GUI and make it easier to write automations. You can mark the integrations you have combined as `hidden` so they don't appear themselves.
This can simplify the GUI and make it easier to write automations.
In optimistic mode, the lock will immediately change state after every command. Otherwise, the lock will wait for state confirmation from the template. Try to enable it, if experiencing incorrect lock operation.

4
source/_integrations/rflink.markdown
View File

@ -116,9 +116,9 @@ sensor:
automatic_add: true
```
[RFLink Switches](/integrations/switch.rflink/) and [RFLink Binary Sensors](/integrations/binary_sensor.rflink/) cannot be added automatically.
[RFLink Switches](/integrations/switch.rflink/) and [RFLink Binary Sensors](/integrations/binary_sensor.rflink/) cannot be added automatically.
The RFLink integration does not know the difference between a binary sensor, a switch and a light. Therefore all switchable devices are automatically added as light by default. However, once the ID of a switch is known, it can be used to configure it as a switch or a binary sensor type in Home Assistant, for example, to add it to a different group, hide it or configure a nice name.
The RFLink integration does not know the difference between a binary sensor, a switch and a light. Therefore all switchable devices are automatically added as light by default. However, once the ID of a switch is known, it can be used to configure it as a switch or a binary sensor type in Home Assistant, for example, to add it to a different group or configure a nice name.
### Ignoring devices

3
source/_integrations/sensor.rflink.markdown
View File

@ -19,7 +19,7 @@ After configuring the RFLink hub, sensors will be automatically discovered and a
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 Home Assistant, for example to add it to a different group, hide it or configure a nice name.
Once the ID of a sensor is known, it can be used to configure the sensor in Home Assistant, for example to add it to a different group or configure a nice name.
Configuring a device as a sensor:
@ -108,7 +108,6 @@ Sensor type values:
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:
- Disable automatically adding of unconfigured new sensors (set `automatic_add` to `false`).
- Hide unwanted devices using [customizations](/getting-started/customizing-devices/)
- [Ignore devices on a platform level](/integrations/rflink/#ignoring-devices)
## Device support

2
source/_integrations/switch.rflink.markdown
View File

@ -16,7 +16,7 @@ The RFLink integration does not know the difference between a `switch`, a `binar
RFLink binary_sensor/switch/light ID's are composed of: protocol, id, switch/channel. 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 and, for example, to add it to a different group, hide it or configure a nice name.
Once the ID of a switch is known, it can be used to configure it as a switch type in HA and, for example, to add it to a different group or configure a nice name.
Configuring devices as switch :

2
source/_integrations/switch.template.markdown
View File

@ -13,7 +13,7 @@ The `template` platform creates switches that combines components.
For example, if you have a garage door with a toggle switch that operates the motor and a sensor that allows you know whether the door is open or closed, you can combine these into a switch that knows whether the garage door is open or closed.
This can simplify the GUI and make it easier to write automations. You can mark the integrations you have combined as `hidden` so they don't appear themselves.
This can simplify the GUI and make it easier to write automations.
## Configuration

6
source/_integrations/universal.markdown
View File

@ -137,7 +137,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 hidden [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 can hide the Kodi Media Player too, and only show the universal one, which 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 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).
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.
@ -148,10 +148,6 @@ The complete configuration is:
```yaml
homeassistant:
customize:
input_boolean.kodi_tv_state:
hidden: true
media_player.kodi:
hidden: true
media_player.kodi_tv:
friendly_name: Kodi

2
source/_integrations/vera.markdown
View File

@ -64,4 +64,4 @@ Please note that some Vera sensors (such as _motion_ and _flood_ sensors) are _
Home Assistant will display the state of these sensors regardless of the _armed_ state.
To allow you to change the _armed state_ - Home Assistant will create a switch as well as a sensor for each _Armable_ sensor. You can hide these switches using customization if you wish.
To allow you to change the _armed state_ - Home Assistant will create a switch as well as a sensor for each _Armable_ sensor.

2
source/_integrations/wink.markdown
View File

@ -435,7 +435,7 @@ The above devices are confirmed to work, but others may work as well.
Wink Cover garage door functionality varies on the product. Home Assistant can open, close, and view state of GoControl/Linear openers. For Chamberlain MyQ-enabled openers, Home Assistant is limited to show current state (open or closed) only using this Wink cover. This restriction was imposed by Chamberlain for third party control. Wink suggests that MyQ customers should contact Chamberlain directly to inquire about expanding permissions.
The [MyQ Cover](/integrations/myq) does provide full functionality for opening and closing Chamberlain MyQ-enabled garage doors. If installed along with the Wink Component, a duplicate garage door entity may exist. In that case, the semi-functional Wink garage door entity can be hidden via `customize.yaml`.
The [MyQ Cover](/integrations/myq) does provide full functionality for opening and closing Chamberlain MyQ-enabled garage doors. If installed along with the Wink Component, a duplicate garage door entity may exist.
The requirement is that you have setup [Wink](/integrations/wink/) from above.

12
source/_integrations/zwave.markdown
View File

@ -50,7 +50,7 @@ To get your Z-Wave thermostat or HVAC unit working with Home Assistant, follow t
Thermostats with support for fan modes or different operating modes, will be handled like a HVAC device and will also be detected as one.
If the thermostat supports different operating modes, you will get one thermostat entity for each mode. These can be hidden with settings using the customize setting in the `configuration.yaml` file.
If the thermostat supports different operating modes, you will get one thermostat entity for each mode.
</div>
@ -130,8 +130,8 @@ To get your Z-Wave locks working with Home Assistant, follow the instructions fo
Z-Wave locks will expose three services under the lock domain to manage usercodes if the lock supports it:
| Service | Description |
| ------- | ----------- |
| clear_usercode | Clears a usercode at code_slot X. Valid code_slots are 1-254, but max is defined by the lock. |
| get_usercode | Get a usercode from the lock at code_slot. Valid code_slots are 1-254, but max is defined by the lock. |
| set_usercode | Sets usercode to X at code_slot Y. Valid usercodes are at least 4 digits, and max defined by the lock. |
| Service | Description |
| -------------- | ------------------------------------------------------------------------------------------------------ |
| clear_usercode | Clears a usercode at code_slot X. Valid code_slots are 1-254, but max is defined by the lock. |
| get_usercode | Get a usercode from the lock at code_slot. Valid code_slots are 1-254, but max is defined by the lock. |
| set_usercode | Sets usercode to X at code_slot Y. Valid usercodes are at least 4 digits, and max defined by the lock. |