I have a problem with some of my templates. The templates use input sensors that every once in a while become “unavailable”. I already tried to catch this case with the following template definition:
However, this doesn’t seem to work. I still get errors when sensor.daily_yield_2 becomes “unavailable”. Can someone advise how to change the template definition so that when sensor.daily_yield_2 becomes “unavailable” the template sensor then simply keeps its old value?
You don’t want the availability template (as explained by Taras). You need to adjust your test and you need to provide an else case for your if statement.
- name: "Solarertrag heute"
unique_id: solar_daily_yield
unit_of_measurement: 'kWh'
icon: mdi:solar-panel
state: >
{% if states('sensor.battery_day_charge_1')|is_number and
states('sensor.battery_day_discharge_1')|is_number and
states('sensor.daily_yield_1')|is_number and
states('sensor.daily_yield_2')|is_number
%}
{{ states('sensor.daily_yield_1') | float(0) + states('sensor.daily_yield_2') | float(0) + states('sensor.battery_day_charge_1') | float(0) - states('sensor.battery_day_discharge_1') | float(0) }}
{% else %}
{{ this.state }}
{% endif %}
device_class: energy
Also using an availability template as you did does not produce “errors”. Unavailable is a valid state. It’s the whole purpose of the availability template.
Thanks for the very helpful answers! I had a bit of a misunderstanding of the availability template. I thought if any of the sensors in the availability template are “unavailable” then the state would not be evaluated. But now I understand how it works. Many thanks for that!
That’s exactly how it works. The state template is not evaluated and the Template Sensor’s value is reported to be unavailable. That’s how the availability option works.
If in this situation you want the Template Sensor’s value to remain unchanged (i.e. report it’s existing value) then you must do what tom_l suggested: remove the availability option and enhance the state template so that it reports the existing value if any of the referenced entities is unavailable.
Ok. But I thought at the same time, the value would remain unchanged. Because if it throws an “unavailable” state for the template, then some other things down the road might not work properly. In my case, I’m using a lot of mushroom cards in the dashboard. And they can’t handle “unavailable” sensors well. That’s why I needed a way to work around that case where, due to any of the input sensors being unavailable, the dashboard hangs because the cards can’t deal with that state. The solution that tom_I suggested seems to work well in my case (further tests still pending).
I usually apply a mix of trial-and-error and reading the Home Assistant documentation. I find the template documentation not very easy to understand (even though I have an IT background) and also not very well structured. Given the complexity of templating, you easily miss important pieces of information as it must have been the case here. So if things are getting to confusing based on the docs, I tend to search for examples and adopt them. Not always the best strategy, but it has brought me quite far in my 5 years or so of using HA. I have quite a complex setup with hundreds of devices and that is also why I often prefer to apply this 80/20 mentality.
Just saw your second question: As I said, I had to handle the case of one of the input sensors being unavailable because the mushroom cards cannot deal with this situation. So I thought the availability option would be a way to handle this.
I think my point is more that the documentation in total is not well structured so that I simply did not come across this exact sentence. So why, for example, is there a documentation on “template” and one on “templating”? I was using “templating” together with the forum to search for examples and never came across that passage on the “template” page explaining how “availability” works. In my very personal opinion this is all very confusing. But maybe it is intended this way as templates are only used by the more advanced crowd.
That was certainly not well specified from me. There were no errors in a sense that the log would show an error. It was simply that the template did return something (an “unavailable” state) which the mushroom cards could not handle, leading to the “error” that the cards freeze.
Each option of a Template Sensor is documented, including the availability option.
“Templating” introduces the basics of the Jinja templating language. It describes the specific native capabilities of the Jinja language as well as various additional things that were added specifically for use with Home Assistant. Templating can be used in various places throughout Home Assistant so the topic is in the Advanced Configuration chapter (because templating is not always required but when it is, you must first learn the basics of the Jinja templating language in order to use it).
“Templates” describes how they can be used with the trigger variable that’s created by an automation’s triggers so it’s in the Automations chapter. On a related note, it also applies to the triggers of a Trigger-based Template entity and its documentation thoughtfully includes a link back to the “Templates” section on templating the trigger variable.
Because if availability was described there, then one would have a valid argument that the documentation is not “well structured”. As explained, the “Templates” section explains how templates can be used with the trigger variable.
You’re creating a Template Sensor, so if you want to understand the purpose of a Template Sensor’s many options, such as the availability option, you should read the documentation for Template Sensors (links to it have been posted above).
Honestly, I don’t know why you keep blaming me that this was all my fault and by the way you answer, you always try to suggest that I was just too stupid to understand how it works. Maybe. You sound like an engineer for cars who tries to explain a confused customer that it is his fault when he is too stupid to understand your well thought out engineering. Guess what. That doesn’t help the customer.
I never asked anything to be changed. I simply had a problem which I posted on the forum and tom_I helped me with a great answer. However, you keep coming back at me blaming me that I just don’t get it. I guess, it’s best if we just move. I always loved the HA forums, because of the lack of hostility. Let’s keep it this way.
What I have done is explain where the information is located and why it’s there, not to insult you in any way.
If my explanations, for how the documentation is structured and where to find specific information, have only served to upset you then I agree with you that there’s no value in continuing the discussion.
Good luck with all of your future projects with Home Assistant.
Anyways, happy that tom_I suggested an alternative which fits my use case.