Is there a plan, and perhaps a time frame in which support for when the “Component method” for adding discovery devices, will become obsolete?
What do you consider the (efficiency) benefits for “Device Method” of adding mqtt devices to HomeAssistant?
You get fewer mqtt config messages, but each message is significantly longer and more complicated with multiple nesting levels.
And the number of command and state messages is largely the same.
The documentation is incomprehansible because it mixes descriptions of “Component Method” and “Device Method” on the same page interwoven.
What is meant by “migration from single component to device-based discovery” ?
Step 1 … shows what your previous topic and payload would have been. (it is not a step I need to make when I am migrating)
Assuming I have previously published these discovery topics, then I would already have a “device” in homeassistant. (beause the single components both reference the “device” with ids and name"
What would migration do. What would go wrong without it?
And from a coding perspective. This migration is supposedly a one-time thing. After that I would use the Device-method??
Seems a lot of error-prone code for single time use?
Step 2
So then I publish {"migrate_discovery: : true} to all the config topics.
What happens? Do I temporarily get new components/devices?
IMPORTANT Check the logs to ensure this step executed correctly.
What would correct look like, what would incorrect look like?
Step 3 Publish the new device-based configuration.
ok, this seems straight forward enought. It is the new way to publish a device with multiple components.
Step 4 Clean up after migration
So Now I run the code that my old device had to remove the old configs
Removing a component from device-based topics:
publish an empty string to the discovery payload.
The example shows :
a full config for the device and the origin
a full configuration to one of the components.
the unique_id of the component to remove
the platform of the component to remove
but no further data
So then the humidity sensor is removed, but we are not sure the temperature sensor still has a valid configuration?? Even though we just sent the whole sensor configuration to the payload of the device ?
Can I remove a single component by publishing the empty string to the cmps part within the device, while omiting all the other cmps parts?
Can I add a single component by publishing a config payload to a device-topic (omitting the existing cmps, so they remain unchanged?)
If not, then the device-method is far less flexible than the object-method.
So again… what is the benefit of the device-method?
I’m new to Home Assistant myself, but am writing my own integration between a legacy system and HASS using MQTT.
You might find the merged pull request for the device-based discovery functionality useful:
In specific:
The efficiency improvement appears to have been focused primarily on the performance of the Paho MQTT library:
So even if it’s the same amount of data, fewer round trips thru paho seems to have made quite the performance improvement in HA overall.
I agree that the documentation is messy right now, and the advantages/disadvantages are not clearly delineated.
cmps does seem to be the right keyname, not cmp.
Trying to answering your other questions (I have not confirmed this against a live system, and again, I’m a new user, not an HA dev):
I think the idea is you’re still constructing the same discovery document, but you have a transitional mostly-empty component with the same unique ID and platform only, after which you re-publish without that component entirely.
The docs aren’t clear, but you probably need that intermediate document to be retained at the MQTT broker as well, so the delete logic is triggered in the case of HA being down when the removal occurs (whenever HA’s MQTT integration comes back online)
Doesn’t look like it, since you’re publishing at homeassistant/device/<device_id>/config and that’s expected to be a complete document for your sensor. I’m presuming the transitional mostly-empty record exists as a hint only to delete the entity/component, and that by completely omitting it, it doesn’t trigger the actual deletion.
It looks like you can just use the older single-component approach for this, as there seems to be no intent for deprecation. But if the sensor drops offline and comes back online again, wouldn’t you want to include everything in the Birth-triggered discovery message anyway? I’m not sure there’s a point in not just re-publishing a full device discovery payload, even if you think it’s redundant. At least, that’s what I intend to do whenever my integration restarts or encounters a Birth message.
Looks to me like faster HA due to less time spent in paho, at the expense of a mandatory two-step deletion process and a more verbose discovery payload.
Thank you for your detailed response.
First look, monday moring, will look more in next weekend.
I clearly have no idea of the stuff that happens on the paho(?), and between paho and HomeAssistant, etc etc.
Seems that some (zigbee?) devices, publish discovery topics every time they power on. In that case, you would have discovery topics more frequently, but still only once per power on cycle.
My devices are relatively simple. (at least the ones I have working so far with the old single component discovery)
Also, my devices don’t send discovery topics every time they come on-line. They just send new sensor values.
So perhaps that is the cause of so many of these messages in other peoples installation.
From what I read, the request started because some zigbee devices published so many single component discovery messages that normal zigbee traffic was interupted. Sounds to me to be a Zigbee problem. Maybe zigbee should have a resonable delay between sending those discovery messages. (as to not hog the bandwidth)
(Of course the efficiency of the mqtt process is important too)
Thanks again for those links and answers.
I think I will stick with my current single component method.