Check your logs, the actual file not the UI. If you have a question about your configuration, please make a new post. Also, please be respectful in future posts. Thanks.
Sorry, but this is even better.
2021-12-23 10:26:36 ERROR (MainThread) [homeassistant.config] Invalid config for [automation]: invalid template (TemplateSyntaxError: unexpected ')') for dictionary value @ data['value_template']. Got None. (See ?, line ?).
Understood, I’ll take my business elsewhere.
1 Like
You have too many parenthesis in your template, a condition or a trigger… It says it right there in the error. Malformed yaml isn’t going to have straight forward errors. If you have this much trouble, I suggest using the UI instead.
I have about 50-60 automations spread across 8 files. How do you suggest to go about doing that? I don’t even know which file to look into! I modified pretty much all of them because (silly me!) I wanted to get rid of warnings in the config about deprecating default values for int() and float() conversions, another useless change!
[...] but no default was specified. Currently 'float' will return '0', however this template will fail to render in Home Assistant core 2022.1
Why a default of zero is not good enough, beats me!!!
What this change will do is it will hide all the proper errors, will make yaml even more unreadable (it’s not even yaml, it is jinja!), and you won’t be able to even figure out why your automation does not work.
Sorry, quite frustrated here. Revert to my git repo and start again I guess.
1 Like
It wasn’t useless, it was to solve an issue with unknown states on template sensors. Might be useless for you, but many people take advantage of it.
For the default change all you need to know is: If you’re grabbing a state (e.g. states(entity_id)) and you’re converting it to a float, you need to provide a default. All other floats and ints do not need it if it’s not converting from a string.
I made a thread about it if you’re interested.
Well, this can be tough if you edited them all at once. You should search for value_template templates. That will narrow it down. If you’re still having trouble, make a post and tag me and I’ll look through your config with you.
however, I would recommend starting over with what I said about the default.
So to recap: You only need a default when converting a string to a float or int. States are strings so…
If you have
states('xyz.abc') | float
update it to
states('xyz.abc') | float(0)
for identical functionality.
if you have some crazy ass function where you KNOW you always have numbers, don’t bother providing a default as it’s doing nothing.
e.g. this won’t need a default.
{{ ((4 + 7) / 2342890.542 ) | int }}
Really appreciate the willingness to help here, @petro, even after my outburst here.
I’d be honestly interested in reading the thread about the default value. My values are deterministic, they are always something defined (I do take care of that). The only case in which I’d have an unknown value is if I have a bug (which I’d like to know about), or at the system startup (in which case I don’t care about it and I like the behavior of having a zero default). I fail to grasp the need for a non-zero default value, especially at the cost of more complex templates and hiding potential bugs.
As for the “(See ?, line ?)” - please make me the courtesy to acknowledge that is a bug/limitation and a horrible user experience 
(sorry for hijacking this thread)
It’s specifically for energy managment. sensors dropping to zero’s adds false data jumps and we needed a way to account for that in template sensors. Unfortunately, the built in jinja filter for float didn’t have default built in, it always goes to zero. All around, it was an un-fun necessary change.
It’s more of a ‘here’s how to do it’ thread.
Noted!
Questions for someone that wants to try finally to adopt HA in earnest (sorry I tried to read as much of this thread as I could).
QUESTIONS:
- As someone starting from scratch that would prefer doing everything in YAML, how much will I have to rely on the UI? Say I wanted to start from scratch with just me an my YAML what would I have to hand-configure again?
- Are there other HA alternatives (openHAB?) which allow ‘infrastructure as code’-style workflow and allow you to do everything in YAML/JSON/XML/etc that I should consider before I jump back in to HA?
My current take (which I’m very much a HA newbie, and probably wrong so feel free to correct):
- It looks like device_ids are not persistent (not easy to do it sounds), but I’m happy to find new device_ids and translate them over if I ever have to use a new dongle, say. I’m fine with that.
- UI Dashboard and automations all support YAML
- However some new integrations going forward will require me to use the UI with no easy way see the configuration as code
- But maybe I can still have MOST my config in yaml?
WHY I ASK/SOAPBOX:
I do AWS-related work where infrastructure-as-code is a best practice. I’ve also been knee-deep in linux for a long time. (It was clear that HA would probably be moving away from the power users ever since they were writing logs to /etc 
). So in almost all cloud technologies, or samba, cron, i3 (or any WM really), nginx, X11, pfsense, unraid, syslog, zabbix, postfix etc etc etc, I’ve always been used to running the app right from the config, or minimally exporting the config to a simple ascii file of some sort. For infrastructure (which HA very much is), or something on a server that provides a service (like HA) code always made more sense to me. It’s where I’m comfortable. I can:
- version (sounds like I can’t with the integrations anymore here?)
- understand better: txt config lets you view entire config at a glance without menu drilling and you can really understand the logic better
- start from a completely clean slate: Sorry I don’t trust some devs, but it’s nice to know FOR SURE by not saving some DB for all time that you’re not suffering from config bloat or some new issue creeps up and you know for sure what your input is. Plus backing up YAML is so much cleaner than backing up a DB.
Well the other part of HA that is partially ‘UI forced’ is the setup of some Integrations. You can still do all Automations, Scripts, Scenes, Customisation, Lovelace etc in YAML. (that’s how I do it) Setting up the Integrations via the GUI is actually quite a nice change and I really don’t see the issue with it.
The GUI setup Integrations save the data in .storage which you can still backup as part of version control.
Really not an issue.
Simply exclude the DB from your backups, I do.
Thanks for the reply dave. I think you convinced me to stick with it. I looked at openHAB and I don’t like that the community is so much smaller (though I THINK it looks like they get the ‘infrastructure-as-code’ idea right). I’m going to stick with HA, version all the YAML (and maybe .config, though the HA gui settings aren’t really a big issue), and I’ll just take good notes of the UI moves. I’ll test it with a single sensor, automation etc, destroy everything and start from scratch and see how hard it is to reconstruct.
Yeah don’t want to backup and keep permanent database for the next 20 versions. It seems like such an anti-pattern to me. (I know HA–and other apps–rely on this method, and far be it for me to question the devs who put in all their time on this–but I find it odd that it’s not possible to have some Middleware API solution that would allow UI/DB<->YAML, translation abstracting YAML management away from all contributors. I think unraid does this with their plugin system; also symfony and other web frameworks.)
Would this be possible without using any addons?
Yes, just specify a folder for the DB to be saved in (modify the directory in your recorder: setting) and exclude that from your backup.
1 Like
According to the article, it’s only the device-specific config is moved away from YAML, UI config isn’t. Yet, all these new helpers, for example Switch as X, is only available through the UI. Why is that?
Because they never existed before in yaml. The ADR states that the author can choose how they implement any new integration. The author decided to not add these to yaml.
Lastly, these are not helpers. It’s an integration. Looking into this, it looks like the future intention is to be a helper in the next release. We’ll have to watch and see if yaml is added. For 2022.4, it’s an integration so it falls into the ADR requirements for integrations.
What other helpers are you referring to?
I looked at the release notes, and everything had only GUI configuration described. In the list of this chapter, I only checked Switch as X, because that’s the only one that’s relevant to me. Now I checked the others and they actually have YAML configurations.
I also didn’t check any of the other new features, because they don’t have direct links from the release notes to the documentation, which of course doesn’t help when trying to understand them.
That’s not what the ADR says. The ADR-0010 says this:
- 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 means that integrations which communicate with devices and/or services must be UI-configurable (new ones anyway, pre-existing ones are still given a pass but encouraged to migrate). For everything else the choice is left up to the developer. They can do whatever they feel makes the most sense (UI only, YAML only or both).
Switch as X is new and does not communicate with devices and services. So the developer can choose whatever configuration option they feel is best. They were not required to support YAML nor were they required to make it UI-configurable. The chosen path is also not a final decision, if someone wants to submit a PR to make it YAML configurable I’m sure it will be considered.
Yes because none of the others are new. All the others existed as yaml configurable integrations prior to 2022.4. The ability to configure them in the UI is the new feature.
And that strengthens my concern that new feature → no YAML is becoming a trend now. While the article says that YAML is not going away for non-device configuration, the ADR is phrased so that in practice it is quietly pushed to the background.
2 Likes
As per this thread, only “Time will tell”.
It is allowed to add yaml to that integration, as it is not connecting to a device or service. Feel free to contribute it.
3 Likes