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" RUclips 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!
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 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!
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.
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: ruclips.net/video/GZv5Ztj6i6I/видео.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 RUclips 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 RUclips... 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 RUclips 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 RUclips 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.
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" RUclips 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 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!
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.
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: ruclips.net/video/GZv5Ztj6i6I/видео.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 RUclips 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 RUclips... 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 RUclips 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 RUclips 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.