I have an automations.yaml in my packages folder… also one for scripts… then I don’t need to include them as long as I include packages…
1 Like
yep, I use packages for EVERYTHING. I just hope yaml and packages never go away otherwise I’m screwed! (NOTE TO ALL READING THIS: no it has not been mentioned that I know of so please dont start any rants about things being deprecated as have happened earlier in this thread…)
2 Likes
Interestingly, I haven’t yet dabbled with Home Assistant’s packages.
I continue to rely on another home automation software (Premise) that I use in conjunction with Home Assistant. The following sceenshot shows a Premise ‘module’ and it’s effectively a superset of a Home Assistant package:
You can have as many modules as you want (the one shown is named “Global” and I have many others). Each module can contain scripts in GlobalScripts (organized by sub-folder). These are traditional functions and subroutines you can define (in VBScript) and call from anywhere else in Premise. The same is true for Variables which let you define strongly-typed global variables.
Logic holds logic diagrams which look and behave like Node-Red flows. You can build a complete automation visually. You can even drop an integration into the diagram and it appears as a node with inputs and outputs.
Macros are simple scripts.
Classes are typically defined when creating a new integration. You can build a complete integration using a module.
Timers contains simple countdown timers (like Home Assistant) as well as cron-based timers (schedule things to run at specific times and dates).
You can export a module by simply right-clicking the module’s name and select export (optionally specify what should or should not be exported); it’s stored in XML format (this is 20 year old software). When imported, a module is immediately live (no restart, no reload).
I’m gradually migrating away from Premise and transferring all my automations to Home Assistant. Eventually, I imagine I will explore packages.
The beauty of packages is the structure is the same as if you had them in the config yaml… so you can have auto, sensors, scripts, binary_sensors etc etc etc… in one file relating to say one thing like lights for example. Then you can just disable everything to do with that package by simply renaming it to be not .yaml and restart… Super easy to find everything for one domain (say) if everything is in the one package…
Fully agree! I discovered packages just few weeks ago and fall in love instantly. Everything related to single ‘area’ (like garage sensors and automations, irrigation system, my systems monitoring, etc) kept in single place, so easy to find, files are smaller, so easir to navigate and edit. I went even far enough to create emty template for future use, so can keep exactly the same structure of package file across all of them.
Just a question: Is that issue forgotten? I thought it must be trivial fix, then could be delivered in first patches.
That is just a minor annoyment
Wait for 0.115
Yes it is. But since it has been introduced by latest version, one would expect it to be fixed in one of that version patches.
Anyway thank you for info @makai
Managed to change all of my sql platform sensors to history stats and templates with some forrmulas. Much faster and now works with 0.114!
Finally could upgrade.
1 Like
Has there been a github issue be logged
What a massive difference taking out the sql sensors!! Managed to create history stats sensors and value templates from the sensors to calculate kwh costs etc.
5 time faster to restart and upgraded to 0.114.4!!
The history stats work well with mariadb and you see the values increasing dynamically on your lovelace cards! Excellent!!