M-integrations: replace term component by integration (#27795)

This commit is contained in:
c0ffeeca7 2023-06-19 12:28:24 +02:00 committed by GitHub
parent 450f8bd08e
commit 03e17ec286
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 11 additions and 11 deletions

View File

@ -26,7 +26,7 @@ Please note that all keys on cognitive services must be recreated every 90 days.
## Configuration
To enable the Microsoft Face component,
To enable the Microsoft Face integration,
add the following to your `configuration.yaml` file:
```yaml

View File

@ -58,7 +58,7 @@ mochad:
The `mochad` light platform lets you control an X10 enabled dimmer/light device.
To enable this sensor, you first have to set up the [mochad component](#configuration) and then add the following to your `configuration.yaml` file:
To enable this sensor, you first have to set up the [mochad integration](#configuration) and then add the following to your `configuration.yaml` file:
```yaml
# Example configuration.yaml entry
@ -95,7 +95,7 @@ brightness_levels:
The `mochad` switch platform lets you control an X10 enabled switch device.
To enable this sensor, you first have to set up the [mochad component](#configuration) and then add the following to your `configuration.yaml` file:
To enable this sensor, you first have to set up the [mochad integration](#configuration) and then add the following to your `configuration.yaml` file:
```yaml
# Example configuration.yaml entry

View File

@ -404,7 +404,7 @@ An automation to cast stored movie clips to a TV as they arrive.
### Debug Logging
To enable debug logging for both the component and the underlying client library,
To enable debug logging for both the integration and the underlying client library,
enable the following in your `configuration.yaml` and then restart:
```yaml

View File

@ -191,7 +191,7 @@ mosquitto_sub -h 127.0.0.1 -v -t "homeassistant/#"
The discovery of MQTT devices will enable one to use MQTT devices with only minimal configuration effort on the side of Home Assistant. The configuration is done on the device itself and the topic used by the device. Similar to the [HTTP binary sensor](/integrations/http/#binary-sensor) and the [HTTP sensor](/integrations/http/#sensor). To prevent multiple identical entries if a device reconnects, a unique identifier is necessary. Two parts are required on the device side: The configuration topic which contains the necessary device type and unique identifier, and the remaining device configuration without the device type.
{% details "Entity components supported by MQTT discovery" %}
{% details "Entity integrations supported by MQTT discovery" %}
- [Alarm control panel](/integrations/alarm_control_panel.mqtt/)
- [Binary sensor](/integrations/binary_sensor.mqtt/)
@ -232,7 +232,7 @@ The discovery topic needs to follow a specific format:
```
- `<discovery_prefix>`: The Discovery Prefix defaults to `homeassistant`. This prefix can be [changed](#discovery-options).
- `<component>`: One of the supported MQTT components, eg. `binary_sensor`.
- `<component>`: One of the supported MQTT integrations, eg. `binary_sensor`.
- `<node_id>` (*Optional*): ID of the node providing the topic, this is not used by Home Assistant but may be used to structure the MQTT topic. The ID of the node must only consist of characters from the character class `[a-zA-Z0-9_-]` (alphanumerics, underscore and hyphen).
- `<object_id>`: The ID of the device. This is only to allow for separate topics for each device and is not used for the `entity_id`. The ID of the device must only consist of characters from the character class `[a-zA-Z0-9_-]` (alphanumerics, underscore and hyphen).
@ -242,7 +242,7 @@ Best practice for entities with a `unique_id` is to set `<object_id>` to `unique
#### Discovery payload
The payload must be a serialized JSON dictionary and will be checked like an entry in your `configuration.yaml` file if a new device is added, with the exception that unknown configuration keys are allowed but ignored. This means that missing variables will be filled with the component's default values. All configuration variables which are *required* must be present in the payload. The reason for allowing unknown documentation keys is allow some backwards compatibility, software generating MQTT discovery messages can then be used with older Home Assistant versions which will simply ignore new features.
The payload must be a serialized JSON dictionary and will be checked like an entry in your `configuration.yaml` file if a new device is added, with the exception that unknown configuration keys are allowed but ignored. This means that missing variables will be filled with the integration's default values. All configuration variables which are *required* must be present in the payload. The reason for allowing unknown documentation keys is allow some backwards compatibility, software generating MQTT discovery messages can then be used with older Home Assistant versions which will simply ignore new features.
Subsequent messages on a topic where a valid payload has been received will be handled as a configuration update, and a configuration update with an empty payload will cause a previously discovered device to be deleted.
@ -653,7 +653,7 @@ Setting up a [light that takes JSON payloads](/integrations/light.mqtt/#json-sch
#### Use object_id to influence the entity id
The entity id is automatically generated from the entity's name. All MQTT components optionally support providing an `object_id` which will be used instead if provided.
The entity id is automatically generated from the entity's name. All MQTT integrations optionally support providing an `object_id` which will be used instead if provided.
- Configuration topic: `homeassistant/sensor/device1/config`
- Example configuration payload:
@ -670,9 +670,9 @@ In the example above, the entity_id will be `sensor.my_super_device` instead of
## Manual configured MQTT items
For most components it is also possible to manual set up MQTT items in `configuration.yaml`. Read more [about configuration in YAML](/docs/configuration/yaml).
For most integrations, it is also possible to manually set up MQTT items in `configuration.yaml`. Read more [about configuration in YAML](/docs/configuration/yaml).
{% details "MQTT components that support setup via YAML" %}
{% details "MQTT integrations that support setup via YAML" %}
- [Alarm control panel](/integrations/alarm_control_panel.mqtt/)
- [Binary sensor](/integrations/binary_sensor.mqtt/)
@ -705,7 +705,7 @@ The MQTT integration supports templating. Read more [about using templates with
## MQTT Notifications
The MQTT notification support is different than for the other [notification](/integrations/notify/) components. It is a service. This means you need to provide more details when calling the service.
The MQTT notification support is different than for the other [notification](/integrations/notify/) integrations. It is a service. This means you need to provide more details when calling the service.
**Call Service** section from **Developer Tools** -> **Services** allows you to send MQTT messages. Choose *mqtt.publish* from the list of **Available services:** and enter something like the sample below into the **Service Data** field and hit **CALL SERVICE**.