Node red is for automation and automation in ha still uses yaml.
Edit any json at your peril.
Anyway now we cleared that up, thanks for your positivity.
Node red is for automation and automation in ha still uses yaml.
Edit any json at your peril.
Anyway now we cleared that up, thanks for your positivity.
Youāre welcome! Positivity means to have something to be positive about!
Another thing that did not change:
Configuration invalid
Invalid config for [sensor.template]: [...] (See ?, line ?).
Very helpful! Whatās the point of having a āconfiguration validationā button if you canāt find where the error is?!?
One year of new features, docker containers, ā¦ and this is still a thing???
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.
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.
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:
My current take (which Iām very much a HA newbie, and probably wrong so feel free to correct):
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:
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.
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.