Thanks for today's video about packages, it's still too early in my journey for me to need this but it is good to have an understanding. Something that old-time programmers used and lived by were automatically generated cross-reference listings which showed everywhere a label was used in a program and where it was defined, either locally or externally, that may apply here as well.
I definitely find that as my Home Assistant grows larger and both Home Assistant and I get older, the more important my documentation becomes! Unlike development in a group environment, my comments and documentation are primarily just for me (unless I am sharing my YAML). But I find the ability to add these comments, and organize my YAML in a way that helps me recall 'why' a couple of years down the road invaluable. As always, thanks for the comment!
For the “Where the heck” problem. Most editors (VSCode, vim, etc. ) have a feature that easily and quickly lets you search all the files in a directory. Software developers use this all the time to find which file a piece of code resides in.
Hi, your Home Assistant 101 tutorials are concise and informative. Does the packages: domain need to go directly under the homeassistant:: domain? I ask this question as I do not have, nor ever had the homeassistant:: domain in my configuration.yaml file. Don't know were it is, default_config?? I am running the following versions baremetal on a NUC. Core 2024.6.4 Supervisor 2024.06.2 Operating System 12.4 Regards Jon
The default_config provides a number of default integrations. If you remove it, you are basically 'taking over' the configuration or moving to an 'advanced' configuration and you would have to add back any of the default integrations that you use manually. However, after a little searching, it looks like you can add the homeassistant: section just above the default_config: line and specify your package include statement under that. For example (and don't try to copy/paste this from here as I'm sure spaces and indentation would be lost and I'm using periods to represent spaces... don't use periods in your YAML)... homeassistant: ..packages: !include_dir_named packages default_config: _then the rest of your config_ I haven't tested this, but others report that it works. As always, validate your YAML before restarting Home Assistant and you an always remove the new homeassistant: section if it throws an error.
@@ResinChemTech Thanks for the quick reply, I will try this.(In the morning, I live in the land down under!) I still have default_config in configuration.yaml. Again, thanks for your great content and informative replies.
@@ResinChemTech That works😃 ``` homeassistant: packages: !include_dir_named packages # Loads default set of integrations. Do not remove. default_config: ``` As I hvae a new/clean HASS installation I will use a combination of splitting and packages, thanks.
Great! Thanks for letting me know. I might be able to pass it along to someone else down the road. I never had a default_config as that came along well after I started using Home Assistant. But I'm happy that it worked out for you... and you are wise to get an organizational structure setup from the start.
In packages, how does the automation editor work? Are they all listed still in the automation section or you edit them yaml only? If they show under normal editor do they just seamlessly get edited in the package file? Same question about the script editor. I know you’re a yaml guy first so you might never use the UI editor. I was just curious on how the script editor and the automation editor worked with packages.
Unfortunately, no. The automation and script editors only work with the YAML files that are auto-generated in the default automations.yaml and scripts.yaml files. If you move or create YAML in any other files, the UI editors cannot be used and you have to manually edit the YAML for any future changes. So it is a bit of a trade-off. You are correct that I always do everything manually in YAML (because that's all there was when I first started), but it does allow me to add comments/documentation to the YAML and organize my files; something that isn't possible with the auto-generated YAML files that are created via the UI editors.
Thanks for today's video about packages, it's still too early in my journey for me to need this but it is good to have an understanding. Something that old-time programmers used and lived by were automatically generated cross-reference listings which showed everywhere a label was used in a program and where it was defined, either locally or externally, that may apply here as well.
I definitely find that as my Home Assistant grows larger and both Home Assistant and I get older, the more important my documentation becomes! Unlike development in a group environment, my comments and documentation are primarily just for me (unless I am sharing my YAML). But I find the ability to add these comments, and organize my YAML in a way that helps me recall 'why' a couple of years down the road invaluable.
As always, thanks for the comment!
Thanks! This video was a great help for a newbie like me! Helped me out a lot! Thanks for you trouble and effort making this video. 👍
You are most welcome. Glad you found it helpfu.
For the “Where the heck” problem. Most editors (VSCode, vim, etc. ) have a feature that easily and quickly lets you search all the files in a directory. Software developers use this all the time to find which file a piece of code resides in.
Hi, your Home Assistant 101 tutorials are concise and informative.
Does the packages: domain need to go directly under the homeassistant:: domain?
I ask this question as I do not have, nor ever had the homeassistant:: domain in my configuration.yaml file. Don't know were it is, default_config??
I am running the following versions baremetal on a NUC.
Core 2024.6.4
Supervisor 2024.06.2
Operating System 12.4
Regards Jon
The default_config provides a number of default integrations. If you remove it, you are basically 'taking over' the configuration or moving to an 'advanced' configuration and you would have to add back any of the default integrations that you use manually.
However, after a little searching, it looks like you can add the homeassistant: section just above the default_config: line and specify your package include statement under that. For example (and don't try to copy/paste this from here as I'm sure spaces and indentation would be lost and I'm using periods to represent spaces... don't use periods in your YAML)...
homeassistant:
..packages: !include_dir_named packages
default_config:
_then the rest of your config_
I haven't tested this, but others report that it works. As always, validate your YAML before restarting Home Assistant and you an always remove the new homeassistant: section if it throws an error.
@@ResinChemTech Thanks for the quick reply, I will try this.(In the morning, I live in the land down under!) I still have default_config in configuration.yaml. Again, thanks for your great content and informative replies.
@@ResinChemTech That works😃
```
homeassistant:
packages: !include_dir_named packages
# Loads default set of integrations. Do not remove.
default_config:
```
As I hvae a new/clean HASS installation I will use a combination of splitting and packages, thanks.
Great! Thanks for letting me know. I might be able to pass it along to someone else down the road. I never had a default_config as that came along well after I started using Home Assistant. But I'm happy that it worked out for you... and you are wise to get an organizational structure setup from the start.
In packages, how does the automation editor work? Are they all listed still in the automation section or you edit them yaml only? If they show under normal editor do they just seamlessly get edited in the package file? Same question about the script editor.
I know you’re a yaml guy first so you might never use the UI editor.
I was just curious on how the script editor and the automation editor worked with packages.
Unfortunately, no. The automation and script editors only work with the YAML files that are auto-generated in the default automations.yaml and scripts.yaml files. If you move or create YAML in any other files, the UI editors cannot be used and you have to manually edit the YAML for any future changes.
So it is a bit of a trade-off. You are correct that I always do everything manually in YAML (because that's all there was when I first started), but it does allow me to add comments/documentation to the YAML and organize my files; something that isn't possible with the auto-generated YAML files that are created via the UI editors.