Glad you found it helpful!

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!

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.

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: kzfaq.info/get/bejne/sJyPoM-E2KfHo5c.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.

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!

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! 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.

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.

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!

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.

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.

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 ;-)

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