Do you really need to transfer your template sensors from yaml? What is a reason?
Imho this feature is mainly for people who dislike yaml or have difficulties with it. (including beginners).
At this stage I prefer YAML because of the fine tuning you can do. It looks like they cover everything - and if they allow editing of everything I might change my mind. I’ll have a play.
It’s the issue for me with the Utility Meter. If you use the GUI, you lose the ability to change the source, unless you dig into the deep recesses of the config folder and that defeats the purpose.
Any Utility Meter I have set up in GUI does not allow you to change the source entity in the GUI.
It can be done but you have to go into core.config_entries……ie defeating the purpose of having a GUI. If you set up a Utility Meter in configuration.yaml, it is easy to change any parameters in that entry. I get it that a lot of people don’t want to fool around in YAML, but as long as that option remains all is well with the world.
The template GUI at least looks like you can edit the key parts via the GUI.
The new template helper isn’t acting the way I expected it to. I have this template in the helper. I didn’t select any device type or “show as”, because when I did, it showed it as “charging”, even though I’m in the living room and my phone is next to me and not plugged in.
{{ states('sensor.bedroom_plug_group') | float <1 and is_state('sensor.suzi_phone_charger_type','none') }}
When I use this code as a template in my automations, it works as I expect. But when I created a helper template with this exact same code, and put it into a condition so I could test it, it said, “condition did not pass”. Again, even though I’m in the living room, there’s nothing plugged into the bedroom plug, and my phone is not charging.
Is the template helper only to be used as a trigger, and not to be used as a condition and I just missed that in my excitement?
please avoid the FUD - just because it doesn’t work for you doesn’t mean it wasn’t tested, it just means that your exact scenario may not have been tested. That’s just an unfortunate reality of this system since we’re not getting direct support from the manufacturer itself, and there are plenty of configurations that will work with the updates without issue as I would imagine the people submitting the PRs are testing these on their own systems. As @cgarwood mentioned, your best bet is to open a GitHub issue and provide some logs so that the codeowners can look into it.
Of course you don’t. What I however do like is to cut down on the yaml files. I have a lot of them, and although it won’t get easier configuring by GUI, because you still need to figure out how the template works, for me it makes it easier to keep the overview. Besides, I really love the preview feature, thats something the yaml way lacks. And I don’t need to restart that often anymore.
I can do everything with this helper in GUI now what I did in yaml (isn’t that much, and mostly copy paste from other, much smarter people). Can’t completely remove the yaml, but hey… its a start.
Is there a way that I can upgrade but keep the old Envoy integration? I’m stuck at firmware 3.1.7 and there does not seem to be a way to upgrade it to any 5.x or higher version. I don’t feel like replacing the whole unit just for this.
Yes, you can download the old source and make your own custom component. I have done the same with the bayesian sensor that changed dramatically much a while back.
Thanks for the suggestion. I’ll look into it. I’ve downloaded the source, but it seems that it’s going to be quite some work to get it compiled and everything. And then figure out how to turn it into a custom component. Gonna be one of those long-term projects I guess.
Promising Release, Thanks Guys!
Like always, i’ll wait a couple of Days, then test it on another Machine, then move over to the Mains (Lession learned)
To be honest i favor the Development towards more GUI The more it can be used without ‘Programming-Knowledge’, the more open it is for everybody. e.g. my Wife wouldn’t be able to set up HA atm. Maybe she will in the Future, at least with the Basics
Regarding the Weather Forecast Service I am not sure if understood correctly what changed/will change with the Forecast-Attributes - can somebody please confirm if i got it right (or correct me)?
Dedicated Weather Cards need to get updated by their Authors, to activly pull the desired Forecast from a given Weather Entity whenever they get displayed
From 2024.03 on, if i want to make use of a particular Forecast aside a dedicated Weather Card:
either I need to pull the Data in an Automation/Script first, and work with the Respond-Variable. In this Case, i no longer can’t directly trigger “When Tomorrows Chance of Rain is higher than 70%”, but have to set up a Time Based Trigger (or whatever), and then check for the Respond-Variable.
Alternativly i could set up a Template in configuration.yaml, define the Time/Interval to fetch the desired Data, and use the Templates’ Output-Entity wherever i like to.
Correct?
So, i have set up some custom:button-card where i display a lot of Forecasts (and conditionally juggle between different weather Providers) - basically a custom Weather Card.
In this Case i would have to build a Template for every desired Forecast Value, and then use that in my Cards, right?
The more it can be used without ‘Programming-Knowledge’, the more open it is for everybody. e.g. my Wife wouldn’t be able to set up HA atm. Maybe she will in the Future, at least with the Basics