MQTT 102: Updates to Home Assistant MQTT Discovery for 2024.11
ฝัง
- เผยแพร่เมื่อ 5 ก.พ. 2025
- Are you a DIY'er or developer who relies on MQTT discovery for your devices? If so, you'll want to watch this video for the changes introduced in release 2024.11 of Home Assistant! In this video, I'll cover into the latest changes and improvements to Home Assistant's MQTT discovery process. I'll cover:
• New Topic and Payload Options: Now you can publish a single topic and payload to create a device with multiple entities.
• How the changes also impact the process to delete or remove a discovered device or entity.
If you are brand new or want to know more about how to use Home Assistant MQTT Discovery to have your custom devices automatically added and configured in Home Assistant, please watch this video first: • MQTT 102: Add Home Ass...
Additional Links and Info:
=========================
Official Home Assistant MQTT Discovery Documenation: www.home-assis...
It takes significant time, effort and occasionally substantial expense to create these videos. If you'd like to help support this channel and future content, or just say thanks, you can consider buying me a cup of coffee:
www.buymeacoff...
#homeassistant #mqtt #diy #esp32 #esp8266
Wow, thanks... I discovered this video about 5 days into my Home Assistant jouney, and about 10 hours AFTER I figured out the MQTT Discovery stuff - this answers a lot of the questions I had, fills in the gaps and satisfies my tech brains quest for not only HOW but WHY - I am moving from Domoticz to Home Assistant ( 3rd platform shift - started with Homeseer about 20 years ago.....) - new concepts and new terminology but I am liking what I am finding. This content is GOLD for me right now.
Glad you at least found it when you did! As usually happens when I do a Home Assistant video, shortly after I release it, an update happens that makes my video wrong or obsolete! Often the changes are small enough that I can just pin a comment to the original. But this one was substantial enough to justify an "update" video.
While it does make many of my videos much longer than the "normal" TH-cam video, I do always try to include the "why" as well as the "how"... especially for folks that might just be starting out and want to adapt one of my projects... not necessarily blindly clone it.
I almost went with Domoticz when I started out around 6-7 years ago. At the time, the primary reason I selected Home Assistant was that it appeared to have a more active community and I knew I was going to need a lot of help! I do have a whole playlist of Home Assistant 101 videos (with some other MQTT videos in there as well) that you may find helpful. Of course, I'm happy to answer any specific questions as well.
Good luck with your Home Assistant journey... and thanks for the comment!
Thanks for the update video, I was just looking into the new update and how it affected my MQTT processes.
Kinda' rushed this one out a bit (that's why it was a bit late today)... but I knew that eventually I'd start to get comments on the older original video (I added a pinned comment to that video, but ya' know...).
I just hope the old method will continue to be supported for a while. Otherwise, a lot of my prior projects' code will need to be updated. I'll probably get around to doing that at some point anyway, but not having a short deadline of just a couple of months would be nice!
As always, thanks for the comment. It is greatly appreciated!
That’s neat. When adding auto discovery to my project I was surprised by the amount of repetition involved. This seems like a nice improvement. Cheers.
Agreed! And at least for now, the prior method is also still supported. Which is great for those that may have multiple projects published out there with the original method... although I do suspect that a time will come when the prior technique is no longer supported. But at least that isn't in the next month or so!
Thanks for watching... and taking the time to leave a comment!
I love this! They previous way always bugged me because when using MQTT Explorer, it's annoying to inspect the data on the topics of a certain device because the entities were scattered across multiple domains. That ends now! 🥳
I'm just starting to play with this myself and have enjoyed your MQTT series. One question though on the example new discovery message (at about 1:51 in). Shouldn't the discovery topic really be homeassistant/device/devlD01/config so it matches the unique ID you have listed? I'm also finding the terms unique id, device id, component id, entity id, and name rather confusing. Some, I'm sure are synonyms, while some must surely be different and truly "Unique".
It might help a bit if you watch the full version of this video, as this was just a quick update to cover a small change in how device discovery is done.
But I don't disagree about the various unique identifiers involved. Even the official documentation is a bit confusing and it would not be unusual for me to 'switch' up the terms when discussing. But there are really two important unique identifiers involved... one is for the discovery message itself, as each discovery must have a unique identifier so that the entities/device discovered can later be edited by sending a new payload to the same topic.
Then there are the unique identifiers for each entity. In Home Assistant, each entity must have a unique ID or the enity cannot be edited using the Home Assistant interface. If the discovery only involves a single entity, then the message and entity can both use the same unique identifier, but they don't have to. Despite what they are called (object ID, U_ID, entity ID, etc.), you just need to make sure that the message and each entity uses some sort of unique identifier that isn't duplicated among other entities of the same type.
Sorry... kinda' wordy... but it's a difficult concept to initially grasp. Take a look as some sample code and it might help.
@@ResinChemTech I actually found the full video and watched it several times BEFORE I found this one ;-). Unfortunately I still find myself confused. Yes, I also found the documentation even MORE confusing (much more so than your videos!), even with 40 years as an engineer!
I'm brand new to HA and decided to do generic python code for RPis that will support any of 3 different Temp/Humidity/Pressure/VOC sensors (BME280, BME680, and SHT45). For initial debug, I have all 3 connected to the same RPi 5 which also hosts my multiple IOTStack Pi Docker containers.
So I think I understand your point about device and entity/component UIDs. I still have my original question, shouldn't the Discovery topic "UID" be the same as the Device's UID?
i.e. homeassistant/device/devID01/config
My other question is regarding what is an entity (or here a component)? Specifically the 3 sensors I have each provide multiple readings. So, is each reading an Entity, i.e. Temperature from the SH45 is a separate entity from the Pressure from the SH45, or is the entity the sensor itself, regardless of the number of readings it can provide?
Sorry... I was tossing around terms like "entities" while forgetting that you are somewhat new to Home Assistant. An 'entity' is more or less the lowest unit of an object in Home Assistant. Each individual sensor, switch, light.. and even things like individual automations or scripts are considered entities. A single 'device' might have multiple entities... like temperature and humidity from a single device.
Pretty much everything in Home Assistant is kept in a database. When it comes to the discovery message, it is just a special topic (or 'command') that creates devices and entities. It is kept in a table, with a unique identifier (or primary key) so that if the same 'command' or MQTT message is later received on the same topic and unique ID, Home Assistant knows to modify the related entities and not to create new ones.
Now, entities like sensors, are kept in another table. It too has a unique ID or primary key field (the id is really only part of the primary key in this case). But if an entity has a unique ID, it can be edited in Home Assistant (for thinks like changing the entity name). But the primary keys in this table are independent of the ones in the discovery table. A primary key can be duplicated in both tables or both tables can have complete different ID. So the object ID (or unique ID) in the discovery topic can be anything... and has no impact on the ID of any generated entities. Think about it like this: a single discovery message could create five different sensors. You couldn't use the same unique ID for the topic and all five sensors (since each sensor needs its own unique ID and if the topic ID was used, all five sensors would get the same ID). If you have a discovery message that is only creating one sensor, then its true that the same ID could be used... but they can be different as well.
In short, the unique identifiers used must be unique within a particular 'type' or table. All UIDs used in discovery topics must be unique. And all UIDs for sensors must be unique among all other sensors. But a UID can be repeated in different "tables". That doesn't mean that the two are directly related (at least not in this particular relationship). So each discovery 'topic' must have its own UID (called object ID in the docs), while each generated entity in the payload must also have a unique id (actually called 'unique_id'). If you look at some of the examples in my code, hopefully this makes a bit more sense.
The video shows the auto-discovery topic as /homeassistant in my (very new) installation the default for this starts with homeassistant (there is no / at the beginning) and discovery doesn't work with a /
Yes.. you are correct. That was a "leftover" typo in the slides that I used. I initially had a section where I showed modifying the default _homeassistant_ discovery topic and I used a prefix in front of homeassistant. I decided that very few people would need or want to change the default topic, so I cut that portion of the video. But I forgot to remove the added "/" at the start of those slides. The blog and all my sample code in Github/Gists are correct and show the topic without the leading backslash.
Thanks for the correction.
Is there a way to send payload to a home assistant that is outside of the network?
There are multiple ways, but probably the easiest or most straightforward is to use a cloud-based MQTT broker. There are a number available out there. But instead of using the Home Assistant MQTT add-on as the broker, you'd configure your Home Assistant MQTT integration to communicate with the cloud broker.
You could then send an MQTT topic/payload to the cloud broker from anywhere outside the network. Since Home Assistant would be connected to this broker and assuming it is subscribed to the topic, it will receive the payload.
There are other ways (such as broker-to-broker), especially if you are subscribed to Nabu Casa and your Home Assistant instance is accessible via an external URL. But using a cloud MQTT broker would probably be the easiest way to send MQTT messages to Home Assistant outside of the local network. I suspect there might be a little lag and devices won't react as quickly as when the broker is local, but it shouldn't be any worse than other cloud integrations.
I think I'll have to have a HomeAssistant week set aside soon to update and clean up my HA systems. I always had a question about relationships within entities in XML, JSON and YAML, and knowing that my assumptions were never guaranteed to be correct, even if I'm always the most logical.
I could stand to spend a few days doing nothing but cleaning up my Home Assistant as well... abandoned entities, old automations that are no longer in use, etc. Plus I'd really like to play around with the new dashboards.
Oh well... winter's coming up so maybe I can find a little extra time at some point. Thanks for the comment... always good to hear from you!
Hi, since finding your channel, I’ve tried to match buying all the components you have as I’m in the 🇬🇧 for my wled projects. Thanks to Aliexpress it has made it easier.
I am however stuck when it comes to the power part of my first board. Do you have a way to receive direct messages? It is a very beginner question 😀
First, have you watched this video on building your first WLED controller: amzn.to/3PDV5mB and this one that addresses most of the common LED/WLED questions: th-cam.com/video/GZv5Ztj6i6I/w-d-xo.html ?
Those two videos cover the most common issues related to building an LED project with WLED. If you still have specific questions after those videos, please feel free to post your specific question under the comments of either of those videos and I will do my best to try to help out.
@ yeah I have, I’ve watched all you videos at least twice. Shame TH-cam doesn’t still have the old direct messaging facility, as to explain I needed to really post some pictures. I think I’ve worked it out from your videos. In the mean time I have just found a Facebook group called WLED support group. I’ve posted in there so hopefully someone will just confirm I’ve got the right power supply option.
Appreciate the advice as always 😀
I agree with you about having additional options here on TH-cam... but I hear something Discord-like may be coming down the road.
As I mentioned, I'm happy to try to help out. I generally don't provide direct contact info as I already get dozens of daily requests from vendor/manufacturers to review projects, accept a sponsored video, etc. But I also don't want someone to get stuck, frustrated and give up on a project because they cannot get the answers they need. To that end, if you don't get the desired response elsewhere, you can find my email address on my TH-cam channel page (click the 'More...' next to the channel description near the top of the page). Just be sure to put something in the subject so that I recognize that the email is from you. I generally don't respond to "unsolicited" emails asking for help. But in this case, I've invited you to contact me via email.
Sorry for all the hoops, but I hope you can understand why I simply can't provide my email to everyone as I just wouldn't have time to respond appropriate to each and every individual question.
@ that’s ok buddy. I’ll figure it eventually 😀. I can imagine you get many messages, and time is important. Would be good if TH-cam did improve the connect method, find a happy balance somewhere. Appreciate the offer though 😀👍🏻
Just found the change in the HA update message.
I seriously don't see the benefits.
Other than that it may seem logical(??) to publish the Device and then specify (include) all related entities under it, rather than publish an Entity and specify the Device it belongs to. (Its six of one or half a dozen of the other)
- How often do you need to publish new devices to HA (unless you are developing a device) After all, this is JUST the discovery topic.
- The repetitie inclusion of a few items of the Device , is not a problem, its one function call for every entity I publish.
The increase of nested keys and reduced number of mqtt publishes, means those mqtt messages are substantially larger.
(Meaning I need to reserve a larger Json doc)
It would not reduce the number of published mqtt messages that are related to the actual entities.
I often don't understand why some of the changes are made either (I'm sure there are reasons), but it seems like just about every month, some sort of MQTT breaking change is listed. The worst was when they moved MQTT from a platform to a top-level domain. So instead of sensor->MQTT, it had to be MQTT->sensor. With hundreds of MQTT entities defined in YAML, this was NOT a lot of fun... and I still have no idea why it was necessary or what benefit came from it.
For me, I do think the new payload format is just a bit easier to comprehend... as it is has the distinct device, origin and component "sections". But at least for now, luckily they've allowed the original method to still be used. I agree that it is generally a process that runs one time (outside of development), but as someone with numerous projects/devices with code that uses MQTT discovery, I really don't want to have to go back and update all that old code (like when the previous MQTT entities in Home Assistant had to be changed).
Personally, for me, some of the worst parts of these changes is they seem to happen just shortly after I publish a video on the topic. The changes always seem to make the video details incorrect or obsolete. Then I have to create a "correction" video like this one. Oh well... I guess that will always be part of making videos related to any sort of technology.
@ResinChemTech LoL.. I feel the frustration.
The MQTT auto discovery implementation is very powerful, but there is a learning curve.
(I started a few months back, when I saw your ?second? video about MQTT)
I made a few very easy to use functions (in Arduino class) that take an Entity (struct) and a Device (struct) as parameters, then publish the entity with the nested Device. Works good enough to easily add entities during development.
Lucky, I have not actually replaced any of my existing projects with MQTT.
Will have to rework before I actually start using anything in HA automations.
HA documentation does mention migration methods, but doesn't mention a timeframe for making the old method obsolete.
Thanks for the video and your reply.