Maybe its just me, but I like being able to browse my yaml, see 50+ lines of code on the screen, scroll through multiple entities and their code, copy code and insight as needed, and to see the whole context of my code including comments and the preserved order in which I customarily write the code.
The UI doesn’t do that. That said, I really like the developer > services UI<>YAML toggle. Give me that in the larger UI, and I might just use the UI for a bit more. BTW, “packages” are a great way to bundle your thoughts and objectives.
I have automations that are more than a full screen high in my vim editor display. Looking at them in the UI, I can’t tell what the heck they do.
Yup, I made a mistake when I cut that out of my script and hardcoded the entity in the dev template tool . But I’ve gotten into states where my scripts stopped working and couldn’t find the entities. This is commonly after hammering a ton in the dev template tool (typically fixed by a reboot). I did just reboot now and the scripts are working.
This weekend I’ll spend more time on new similar scripts and see if I can replicate and capture more error info. I’ve only been on HA for a few months, other than the default log, any places to look to capture more error data?
Yup. Good call out (and I responded to the other individual too) … I made a mistake when I cut that out of my script and hardcoded the entity in the dev template tool . I did just reboot and my scripts are fine. But I am seeing the weird state issue where it won’t retrieve the entities from the sonos speakers after continually hammering the dev template tool (I used it a lot to figure out how to code out the jinja). I’ll do more this weekend and try to capture more error info. Other than error logs, any other place I can look for failure information?
Not sure if this is an obvious question, but would we benefit from the database optimizations if using mariadb? If not, is there still a benefit to using mariadb over the default?
Yes you still get to benefit from optimizations. I’m not sure if all have the same effect but you get some.
That being said, my understanding is that the performance benefits of using mariadb over the native SQLite db are largely eliminated in most cases. Ymmv as databases are complex but a ton of optimizations have been done and I don’t think there’s a strong performance argument for using mariadb anymore.
However I still use the addon for a different reason - I don’t want the db in my backups. The db is just history and it’s huge, IMO including it in my emergency backups is a waste of time and resources. I want my backups small and just containing the necessary config to get up and running again. You can’t exclude the native SQLite db from backups since it’s a file in /config but you can exclude an addon from backups so I still use the addon.
I was actually drafting a PR to add configflow to backup to be able to exclude files don’t know if I’ll finish it before someone else beats me to it though, still working my way around configflow
The discussion in that link doesn’t seem super applicable. In fact, the decision is a pretty narrow and clear line about which should be YAML and which should be config flow based.
From the Decision section:
To protect project goals and to provide clarity to our users and contributors, we’re introducing the following rules on how integrations need to be configured:
Integrations that communicate with devices and/or services are only configured via the UI. In rare cases, we can make an exception.
All other integrations are configured via YAML or via the UI.
This makes total sense for the reasons they’ve given and I support that. The decision is sensible based on identifying that the following situations are a worse experience in YAML (e.g. due to OAuth flows, etc):
Integrations that integrate devices. Examples include Hue, TP-Link.
Integrations that integrate services. Examples include AdGuard, Snapcast.
Again, this makes total sense.
So why is the sql integration dropping YAML support? It isn’t either of those categories and it doesn’t abide by the actual decision that was written up (unless we are calling the database “a service”…).
All other integrations are configured via YAML or via the UI.
You are reading it the wrong way. It doesn’t mean that the user has the option of configuring via YAML or UI. It means that the author has the choice whether to offer UI or YAML (or both).
. But I’ve gotten into states where my scripts stopped working and couldn’t find the entities. This is commonly after hammering a ton in the dev template tool (typically fixed by a reboot). I did just reboot now and the scripts are working.
don’t know if I’ll finish it before someone else beats me to it though, still working my way around configflow