With the integration of Theengs Decoder the code has been refactored so that the discovery is more structured.
The unique id of entities will be (not implemented yet) -, example: "uniq_id":"882D777014C-pres"
before it was: "uniq_id":"882D7770014C-CLEARGRASSTRHKPA-pres"
For new devices and users, this will not be an issue but for existing users, the following consequences will occur:
you will see duplicate entities into the device view:
you will have to remove the old entities(topics and payload) from the broker and remap the new ones into your dashboard and automation
I think this change is necessary to refactor the code but will have user impacts. Any thoughts on this?
Note that the v0.9.9beta is already changing this but in a way that is not the one defined above (I will implement the change depending on the discussion)
As background I’m not a heavy user of BLE, but a heavy user of the MQTT Device Discovery api. In the sample, is 882D7770014C a unique identifier from the BLE device or is it the ESP32? I believe it is the BLE device.
Looking at my DT24 device, am thinking the change will be this
"uniq_id":"200507161361-DT24-volt"
to
"uniq_id":"200507161361-volt"
Which isn’t an issue as I only have the single device, and 200507161361 is the BLE device and not the ESP32.
The consequence of this change is that you will lose the link between the new entity and the previous entity data history. You will have 2 entities for the same upcoming data if you keep the previous retained message format.
If you restart the broker and doesn’t persist messages you will have only one entity, the new one (as long as all your gateways are running the same OMG version).
Your historical data will be lost.
