Allow MQTT device based auto discovery #118757
Conversation
|
Hey there @emontnemery, @bdraco, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
|
Since this is difficult to read for someone not involved. Does this still support specifying topics device-wide (ie. same for all entities), and then overriding them on a per-entity basis if required? |
Effectively the PR is the same is the previous PR, but we love to seem some test results. We will try to update this branch as good as possible. A documentation PR is linked. |
jbouwh
force-pushed
the
mqtt-device-based-discovery
branch
from
9d516dd
to
317bb4b
Compare
jbouwh
force-pushed
the
mqtt-device-based-discovery
branch
2 times, most recently
from
bdb0bf7
to
85d2546
Compare
| @@ -138,7 +138,9 @@ def remove_trigger_discovery_data( | |||
| hass: HomeAssistant, discovery_hash: tuple[str, str] | |||
| ) -> None: | |||
| """Remove discovery data.""" | |||
| del hass.data[DATA_MQTT].debug_info_triggers[discovery_hash] | |||
| discovery_data: DiscoveryInfoType | ||
|
|
||
|
|
||
| def clear_discovery_hash(hass: HomeAssistant, discovery_hash: tuple[str, str]) -> None: | ||
| """Clear entry from already discovered list.""" | ||
| hass.data[DATA_MQTT].discovery_already_discovered.remove(discovery_hash) |
homeassistant/components/mqtt/tag.py
Outdated
| @@ -180,5 +181,6 @@ async def async_tear_down(self) -> None: | |||
| self._sub_state = subscription.async_unsubscribe_topics( | |||
| self.hass, self._sub_state | |||
| ) | |||
| if self.device_id: | |||
jbouwh
force-pushed
the
mqtt-device-based-discovery
branch
from
ffd153b
to
51fda9a
Compare
Proposed change
Rework #109030 which introduces a new device based MQTT discovery schema.
The original PR was reverted during the beta of HA Core 2024.6.0. With PR and branch we aim to test and optimize large MQTT setups that run via MQTT discovery.
Context
The current MQTT discovery model only allows to setup per component, if a device has multiple entities to published, the device context, availability and origin information needs to be duplicated.
This PR reduces IO overhead in the paho client on processing discovery packages: The baseline was 10000 packets, with device discovery it 6250 packet reads so a 37.5% reduction in I/O. Processing less I/O reduced the paho client run time by ~18%. The grouped discovery reduced the run time in the HA client by ~12%.
This PR adds a way to discover all components for a device with one discovery. The device, availability and origin mapping is only submitted once. Also the following options are allowed in the shared context:
state_topiccommand_topicencodingqosExcept for
deviceandoriginoptions, supported shared options can be overridden in the component config.Discovery updates and removal is fully supported.
The device based discovery coexists with the component based discovery, so no deprecation is planned for discovery with the single component schema to guarantee older devices keep working.
Example
The example below is of a device based auto discovery that supplies a
sensorandbinary_sensor.Discovery topic:
Payload:
{ "dev": { "identifiers": [ "mysensors123" ] }, "avty": { "topic": "avty-topic" }, "cmp": { "bins1": { "platform": "binary_sensor", "name": "Beer", "state_topic": "test-topic" }, "sens1": { "platform": "sensor", "name": "Milk", "state_topic": "test-topic" } }, "o": { "name": "My org", "sw": "bla2mqtt" }, "qos": 0 }Note that a required
platformoption is added to identify the component platform. The keys under thecomponents(abbreviatedcmp), are treated asobject_idand are used to create a unique devicediscovery_id. In this case thediscover_id'saretest123 bins1andtest123 sens1.In case a
node_idis specified (e.g.node123) in the device discovery topic ...... this will become part of the
object_id.The
discovery_id's becometest123 node123 bins1andtest123 node123 sens1.Migration from single topic to device based discovery
To allow a smooth migration from single topic discovery to device based discovery, the
discovery_idfor anmqttitem must be the same. Migration is supported of the single topic id has anode_idand aobject_id. After migration theobjectid moves inside the discovery payload and the previousnode_idbecomes the newobject_idof the device discovery topic.The config to migrate to must have a
migrate_discoveryconfig option set toTrue. This will allow clearing the migrated discovery topics without removing them. So"migrate_discovery": trueneeds to be added to the JSON discovery payload(s) to migrate to. Migration is supported in both directions.Example (device automation):
Discovery topic single:
homeassistant/device_automation/0AFFD2/bla/configDiscovery id:
0AFFD2 blaDiscovery payload single:
{ "automation_type": "trigger", "device": { "identifiers": [ "0AFFD2" ] }, "o": { "name": "foobar" }, "payload": "short_press", "topic": "foobar/triggers/button1", "type": "button_short_press", "subtype": "button_1" }Migrated:
Discovery topic device:
homeassistant/device/0AFFD2/configDiscovery id:
0AFFD2 blaDiscovery payload device:
{ "device": { "identifiers": [ "0AFFD2" ] }, "o": { "name": "foobar" }, "cmp": { "bla": { "automation_type": "trigger", "payload": "short_press", "topic": "foobar/triggers/button1", "type": "button_short_press", "subtype": "button_1", "platform": "device_automation" } }, "migrate_discovery": true }If the new device discovery payload has the same
discovery_idand comes after the single discovery payload. Home Assistant will publishNone(retained) to the single discovery payload to remove it.Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.To help with the load of incoming pull requests: