diff --git a/source/_docs/configuration/customizing-devices.markdown b/source/_docs/configuration/customizing-devices.markdown index 9222c54e5f7..a86fed5ba2a 100644 --- a/source/_docs/configuration/customizing-devices.markdown +++ b/source/_docs/configuration/customizing-devices.markdown @@ -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 diff --git a/source/_docs/configuration/state_object.markdown b/source/_docs/configuration/state_object.markdown index 8699d0220c6..a926437760e 100644 --- a/source/_docs/configuration/state_object.markdown +++ b/source/_docs/configuration/state_object.markdown @@ -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: `.`. 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: `.`. 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"]`. diff --git a/source/_integrations/binary_sensor.template.markdown b/source/_integrations/binary_sensor.template.markdown index 37ad46f32b9..e99744508ac 100644 --- a/source/_integrations/binary_sensor.template.markdown +++ b/source/_integrations/binary_sensor.template.markdown @@ -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 %} diff --git a/source/_integrations/config.markdown b/source/_integrations/config.markdown index 8f24cfdd54b..7d563b166e0 100644 --- a/source/_integrations/config.markdown +++ b/source/_integrations/config.markdown @@ -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. diff --git a/source/_integrations/cover.rflink.markdown b/source/_integrations/cover.rflink.markdown index d1892f9f857..b83284d6b26 100644 --- a/source/_integrations/cover.rflink.markdown +++ b/source/_integrations/cover.rflink.markdown @@ -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: diff --git a/source/_integrations/egardia.markdown b/source/_integrations/egardia.markdown index b813e82bc82..4b5e3f82333 100644 --- a/source/_integrations/egardia.markdown +++ b/source/_integrations/egardia.markdown @@ -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. diff --git a/source/_integrations/homematic.markdown b/source/_integrations/homematic.markdown index 7cc47097c41..2dcc9e86193 100644 --- a/source/_integrations/homematic.markdown +++ b/source/_integrations/homematic.markdown @@ -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: diff --git a/source/_integrations/light.rflink.markdown b/source/_integrations/light.rflink.markdown index 89170dc512f..cfc2a0891c7 100644 --- a/source/_integrations/light.rflink.markdown +++ b/source/_integrations/light.rflink.markdown @@ -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: diff --git a/source/_integrations/lock.template.markdown b/source/_integrations/lock.template.markdown index 81a597977ee..ecab0fe932e 100644 --- a/source/_integrations/lock.template.markdown +++ b/source/_integrations/lock.template.markdown @@ -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. diff --git a/source/_integrations/rflink.markdown b/source/_integrations/rflink.markdown index beae0a5ccab..825a03a0778 100644 --- a/source/_integrations/rflink.markdown +++ b/source/_integrations/rflink.markdown @@ -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 diff --git a/source/_integrations/sensor.rflink.markdown b/source/_integrations/sensor.rflink.markdown index 32a74659580..213c182631d 100644 --- a/source/_integrations/sensor.rflink.markdown +++ b/source/_integrations/sensor.rflink.markdown @@ -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 diff --git a/source/_integrations/switch.rflink.markdown b/source/_integrations/switch.rflink.markdown index 635759a4536..2d9279e58d0 100644 --- a/source/_integrations/switch.rflink.markdown +++ b/source/_integrations/switch.rflink.markdown @@ -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 : diff --git a/source/_integrations/switch.template.markdown b/source/_integrations/switch.template.markdown index 3901272e8bf..58d15e643b5 100644 --- a/source/_integrations/switch.template.markdown +++ b/source/_integrations/switch.template.markdown @@ -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 diff --git a/source/_integrations/universal.markdown b/source/_integrations/universal.markdown index 3c2ab8fe5f0..116e6b8ceb4 100644 --- a/source/_integrations/universal.markdown +++ b/source/_integrations/universal.markdown @@ -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 diff --git a/source/_integrations/vera.markdown b/source/_integrations/vera.markdown index a89b1fa349b..4ff7aa9cd98 100644 --- a/source/_integrations/vera.markdown +++ b/source/_integrations/vera.markdown @@ -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. diff --git a/source/_integrations/wink.markdown b/source/_integrations/wink.markdown index b455272e61d..a964ec8239a 100644 --- a/source/_integrations/wink.markdown +++ b/source/_integrations/wink.markdown @@ -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. diff --git a/source/_integrations/zwave.markdown b/source/_integrations/zwave.markdown index e22038fa17b..eb78e3f7c0e 100644 --- a/source/_integrations/zwave.markdown +++ b/source/_integrations/zwave.markdown @@ -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. @@ -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. |