Home Assistant MQTT Changes & Moving to Packages
HTML-код
- Опубликовано: 21 июл 2024
- Starting with Home Assistant release 2022.9, there will be major changes in how MQTT entities are defined in YAML. See how to migrate your YAML and why this change has driven me to move to YAML packages.
If you've never used packages, I'll show the initial setup process and an example of creating a package.
Chapter Breaks
==============
00:00 Intro
00:26 Announcement of MQTT breaking change
01:00 Overview of code changes
02:06 Migrating YAML MQTT entities to new format
07:06 Organizational issues with new MQTT entities
09:00 Using nested !include statements
10:00 Overview of Home Assistant Packages
11:38 Package example
13:16 Merging new MQTT entities into a package
13:53 Getting more examples of packages
14:15 Setting up Home Assistant to use packages
15:35 A couple more points on packages
16:00 Migrating over time
16:47 Wrap up
Links:
======
A big shoutout to Jeff for all his info on advanced YAML (and more):
@SlackerLabs - / slackerlabs
While many of my videos feature Home Assistant, here are a few that focus primarily on HA automations:
- Recreate a YAML automation using the UI Editor: • Home Assistant 101: Re...
- Managing Voice Notifications with Home Assistant: • Home Assistant 101: Ma...
- Automated Garage Lighting with Home Assistant: • Automated Garage Light...
- Washer and Dryer Notifications for Home Assistant: • Washer and Dryer Notif...
- Parking Assistant and Vehicle Presence for Home Assistant: • Parking Assistant and ...
- An ESP32-based Mailbox Sensor for Home Assistant: • An ESP32-based Mailbox...
If you find my videos useful and you’d like to say thanks or help support future videos, you can:
Buy Me a Coffee - www.buymeacoffee.com/resinche...
#homeassistant
#mqtt
#yaml 
Наука
@ResinChem Tech, I am really grateful for this video. Forced migration through SD corruption has been painful. Your clear advice on how to make changes has been a God send.
Glad you found it helpful!
This video really helps me as a beginner, thank you, Suhu👍🙏
New Subscriber Well done! Thanks
Have a door sensor that falls into the binary sensor thing with two entities, for door status and one for battery.
I had gotten a warning to make some changes in prep for 2022.9, which I /thought/ I addressed. Noticed at some point the sensor stopped working and have been trying to figure this out for almost a month with random trouble shooting off and on. Finally was able to sit down and fully play with things attempting to get it working again. Came across your video and it was the ah ha moment for me to get it working again.
I dont like the new everything mqtt in the mqtt.yaml file thing they are doing now. I only have this one sensor so I am going just suck it up. Will keep the packages trick in mind if I end up expanding my mqtt stuff. Hopefully they do not nuke that trick.
Thanks so much for doing this video, it was super helpful! I am so happy this is working again for me.
Glad I could help! I don't always understand (or like) some of the changes that the Home Assistant devs decide to make, but I'm sure they have their reasons. I think that they often don't consider the potential impact on their long time users in lieu of making things easier on the newbies. I agree that this particular change makes things much less organized for us long time YAML users... and is what drove me to packages.
Thanks for watching... and taking time to post a kind comment!
The packages: line has to be indented because its a part of the top level homeassistant: entity. Things like automation: entity are also top level entities.
@ResinChem Tech To return your help, using PSPAD freeware allows you to open and search in multiple files all in one go. This would mean that you use samba but may help you locate your entities. I note that you moved to packages and this may not be of help.
Thanks for the tip, but I did move completely to packages a few years back. I actually have a more updated video that covers the process for moving from a single or split configuration to packages in Home Assistant: ruclips.net/video/z6_mlSsAcsc/видео.html
@@ResinChemTech I did watch more of your videos including re the possible death of homeassistant due to matter. I think that this is no bad thing as some microprocessors will not be reflashable. I bought some TUYA radiator valve devices that used a different processor.
I think one of the biggest things letting homeassitant down is the unhelpful documentation and the yaml editor which means things that should take 5 minutes take hours as no one understands the yaml or its errors.
The documentation needs to be practical advice including on breaking changes.
I had no idea of the mqtt top down directive which was not mentioned on the yaml code check which told me to remove platform line.
Anyway thanks again for the pointers.
For anyone reading my comment on the PSPAD:
The use of a text editor like pspad is useful when using samba to allow access to the files but no one tells you that yaml uses different end of lines chr(10) etc in the format causing errors.
*** You need to copy and paste it into the inbuilt file editor if new lines where the linefeed is different *** I have no knowledge of Visual Code Studio which is likely a lot better.
THe search and replace, and the use of copying and pasting a template structure that works has saved me time e.g. adding 10 button rf remote control buttons (of which I have a few), or PIRs.
etc.etc.
Did not work for me unless I moved the two-spaced packages EXACTLY at the same place you have it - then the HA worked OK :) Thanks for sharing this!
Yeah... someone explained why you have to indent the package declaration instead of making it like a top level domain. That's YAML for you! I initially had the same issue... wouldn't work unless the packages: statement is indented by exactly two spaces.
I've been pretty happy with my configuration in packages... although there are times when I kind of liked it the older way... with each entity type in its own YAML file. Both ways have pros and cons but they are both better than having everything in one great big configuration.yaml file.
Thanks for watching!
super :-)
Thanks! I think the upcoming MQTT changes may catch a lot of folks off-guard. Especially those that don't pour over the Home Assistant release notes. Hopefully this video will catch a few of those folks and give them a little time to make the necessary changes in their Home Assistant installs before the September release breaks everything!
Thanks for watching and taking time to comment.
Sir, how to control raspberry gpio using mqtt homeassistant?
packages are part of the "homeassistant:" integration from the "default_config:" if you remove default config you need to enter it this way
#########################################
### Package Setups & Customizations
#########################################
homeassistant:
customize: !include customize.yaml
packages: !include_dir_named packages
hope that clears it up a little
Thanks! That makes sense. I just have all my 'includes' grouped together, and most of those are the default entities (e.g. lights, sensors, etc.). I know that I ran into the same issue reported by many others that tried to move to packages... they put the !include statement for packages at the same level as the other entity integrations and got the "packages are not an integration' error. The resulting solution was to indent by two spaces, but nowhere did I see an explanation as to why this was the case... it just worked!
Thanks for taking time to clear that up! Makes sense that since packages are part of the root 'homeassistant:" integration, that's why the two space YAML indentation is needed. I appreciate the clarification that I couldn't find anywhere else!
Does that also mean that packages should be a child of default_config? When I put it in a random place in my configuration.yaml file, I get an error about mapping, but when I put it right below default_config:, the error disappears. Sadly, it doesn't seem to load the packages either though.
HA PR 71676 says: "The background for this PR is that the MQTT integration itself is setup via a config entry, with entities setup via discovery.
MQTT entities can also be setup through configuration.yaml though, and those entities are not aware of the MQTT config entry and thus are not removed if the MQTT config entry is disabled or removed." but I still don't agree with this change.
Thanks for digging that up! Although it would have been nice to have received some sort of reasoning/justification for the change (maybe in plain English) from the developers as part of the release notes or some other medium. I'm always waiting for the next shoe to drop every time a new release comes out (I read the breaking changes before I even look at the new features... worrying that another "MQTT update style" change is going to require me to spend hours 'fixing' my system with some new change). Again, I'm sure they had their reasons, but when they make these sort of (what appears to be) arbitrary changes, it has the most impact on their longest term (and probably their most loyal) user base that have years of development and potentially thousands of lines of YAML that are impacted by the change. Again... to me, it just goes back to a lack of communication and a clear roadmap/plans to their user base.
Thanks again for taking time to share the PR. I guess for now, it's water under the bridge... until the next time they decide to pull another major change like this 'out of thin air' with no general communication for the reasoning behind it.
QQ, If I define a switch or sensor in a package, is it usable in other package files?
Yep... it will be a normal entity like any others, accessible from anywhere. This is also why you cannot duplicate an entity name in different packages... so you can't define and name a switch 'switch.bedroom' in one package and define another switch with the same entity type an name in another package. Behind the scenes (to greatly simplify it), Home Assistant is really combining and reading everything as one big file anyway. Packages just provide a different way of organizing all that YAML as opposed to split YAML files or putting it all in one great big configuration.yaml or automation.yaml file. Each method has it's own pros and cons.
All MQTT devices and entities used to appear under MQTT integration. Not for a long time, why is that and how do I find out now?
You'd have to ask the developers of Home Assistant for the reason 'why', but I believe it is because more devices are now using native integrations and/or APIs. For example, older versions of Tasmota used something called 'MQTT discovery', which would automatically add the MQTT entities to Home Assistant. Newer versions use the native Tasmota integration, so the entities would now show up under that integration... and not MQTT.... even if they are using MQTT in the background. I think older versions of WLED worked the same way, but now use the native WLED integration. Also note that anything you manually define in YAML will not show up under the MQTT integration either.
If you want to see everything using MQTT, then you can use a tool like MQTT Explorer, which will connect to your MQTT broker and show all the entities, topics and payloads that are talking to the MQTT broker. I find this to be an invaluable tool, not only to see what is using MQTT, but also to troubleshoot when a device isn't behaving as expected.
@@ResinChemTech Many thanks for the information, opinion and tip.
With mqtt explorer i finally find my entities and values.
Unfortunately, it is still very complicated for me, e.g. to query my electricity or photovoltaic meter in Homeassistant. But time will tell ;-)
By making separation like this, configuration.yaml is neater and more structured
Yes, that is correct. If you start to do a lot of customizations or wish to have things like your YAML-based automations and scripts separated out from the UI-generated versions (so you can better organize and include #comments), having everything in a single configuration.yaml file becomes nearly unmanageable. Packages have pros and cons, but another option that I mentioned is to use the split configuration option and !include: statements in your main configuration.yaml. This is also just a bit easier to setup than packages. Using the split configuration also allows you to migrate a little at a time... you don't have to move everything all at once.
But either method leads to a more organized overall configuration when you end up with a lot of manual YAML.
Thanks devs.... got to change 600 lines now... dont fix if it aint broke
I hear ya! I'm sure they must have their reasons for the change... but sometimes it just seems that they are punishing all of us 'old-time' YAML guys.. and trying to force us into built-in integrations and UI-generated automations!
just adding an id to my automations in packages doesnt seem to do the trick. is there anything else I need to do?
I'm going to need more information that what you provided. Adding an ID really has nothing to do with packages... it only provide a unique identifier and allows you to do things like access your automations via the tracing and other debugging tools. So, I'm not sure what you are referring to when you say "doesn't seem to do the trick". What are you referring to?
Moving to packages is a completely different way to organize your YAML. It will likely involve redoing most of what you already have.. but this is somewhat depending on how you currently have your YAML organized. I'll be happy to try to help, but you need to provide a lot more information.
@@ResinChemTech oh sorry ive already been on packages for a while. and I was thinking I was forced to migrate all of my automation that were done previously. I didn't even know if packages were still possible. Im just trying to make them editable and traceable while in the packages I already have. do you do id: '123432414'? or no ''?
OK... that helps a little. First, you don't absolutely have to move your automations if you don't want to. Home Assistant will work just fine in a "mixed" mode... some things in packages and other things still in separate YAML files (I still have a few things like certain sensors that don't fit nicely in a package as I've organized them, so I still maintain a separate sensors.yaml file out side of any packages).
As far as the ID goes, I believe you can use any unique combination of letter and numbers... as long as each is truly unique. I generally use an online UUID generator to create the ID for my automations so that I'm reasonably guaranteed that a number is never duplicated. Then you simply include the ID in your automation, similar to:
- alias: My Automation
id: fe580fa1-915b-4bd9-845e-dcb337e8151a
trigger: ...
Now, note that this will not allow you to edit the automation with the UI automation editor. Only automations created via the UI (and kept in the automations.yaml file in the root of your config) can be edited via the UI. However, it should make your automations available in the trace tool. I'm not 100% sure, but the automation may need to be triggered after adding the ID before a trace will be available. I hope that helps. Let me know if you have follow up questions.
@@ResinChemTech yeah that does seem accurate actually they all have unique ids but I can trace them. NOT edit them. seems like a missed opportunity that should be part of the advanced mode lol
Why don't use the pencil button. Just mark all Lines and hit the comments or tab bitten and all will get the action
Thanks! I for one never knew about the pencil functions, had to fix the indent setting but that is great to have learned. Still hope to get things set up so I can edit in notepad++ someday but other squirrels keep nibbling at my brain.