It is great that template sensors can now be added through the UI. However, for numerical sensors it is often very important to add an availability template. If you do not, often the template will revert to returning 0 values that will result in a mess when the template sensor is later used in derivatives, integrals, energy dashboards etc.
+1 More context here.
Will this help you?
1 Like
Even (or better: also because, cause the missing feature of this FR is blocking me a bit of doing so) Iām not using all my utility meters through the UI yet but still YAML based, I encourage this FR.
Coming from broken energy dashboard incidents.
Even I donāt get the ā ļø DANGER OF ELECTROCUTION ā ļø disclaimer at the end (thatās my way of telling you: yes, Iāve read that page to the bottom 
), that sounds quite interesting.
- What was your motivation of creating this repo / custom integration / macro?
- Whatās the actual benefit of this macro?
My understanding of the added benefit of this macro:
Making it syntactically a bit easier (well, the importing line adds a bit of charsā¦) to consistently filter unwanted states - right? - Why is HA
2023.11.0needed to install it (using HACS)? Whatās the specific dependency, is it using something only introduced with HA 2023.11.0?
- Because I like to share with the community. Sorry if thatās a problem.
- As described in the docs you read.
The main reason for using this template is not because it's complicated, it's because availability is something you will be using over and over when you are dealing with sensors, so being able to repeat the same action over and over is better if there is 1 place in your project that the code exists. - The list test is added added in 2023.11.0 new list test version
If you donāt like the sensor or donāt like your system to be less than 3 months behind in updates, you can look at prior versions and use the template with or without the macro functionality. The code is there and shared with license for you to use.
Iāll definitely give it a try, itās on my todo list once HA got upgraded. Currently my existing template sensors either already have an availability template or didnāt need one. For the latter ones your macro looks like an appropriate solution.
1 Like
You can go into the github releases and install the one before the version listed above. It worked fine and should work with your older version. I just wanted to clean up the code a bit and use the new list test that was released.
Then when you pull HA up you can just update the macro as well.
I think this would be a great idea. I had issues with a binary_sensor that I need to invert, and I couldnāt work out how to ignore unknown and unavailable values from the original sensor, since None values are automatically converted to false for binary sensors.
Currently, the only way I found to make it work is to purposefully raise an error, but I end up with lots of TemplateError('ZeroDivisionError: division by zero') in the logs.
{% if states('binary_sensor.12_000000000000_sensed_a') in ('unknown','unavailable') %}
{{ 0/0 }}
{% else %}
{{ not states('binary_sensor.12_000000000000_sensed_a') }}
{% endif %}
Working on it in Add Availability to sensor template config flow by epenet Ā· Pull Request #126806 Ā· home-assistant/core Ā· GitHub
I am disappointed to see the HA team has decided to reject this feature.
It seems like a mandatory function for any reasonable template sensor derived from a total or total_increasing sensor. 
3 Likes
Yeah itās ridiculous. They donāt want to crowd the UI? Put it under a collapsed advanced section or something.
2 Likes
The recommended solution is to do the check inside the template, and return None. Then you end up with unknown instead of unavailable but at least it doensāt error.
It seems that crowding the template instead of the UI is the recommended optionā¦
I donāt know if itās worth discussing more on the arch discussion Add Availability to UI templates Ā· home-assistant/architecture Ā· Discussion #1149 Ā· GitHub but I too am dis-heartened by the replies I got from the core team on this topic 
Note: the workaround doesnāt even work for binary templates as they canāt return None
1 Like
Can you give an example how to do that the proper way?
Something like this is what is expected:
{% if states('sensor.other') in ('unknown','unavailable') %}
{{ None }}
{% else %}
{{ states('sensor.other') }}
{% endif %}
2 Likes
Sorry so because this is not possible to do this via the UI I am going to do it through the template and I just want to make sure I understand this correctly so that I get a proper result. Here is a sample of my codeā¦ It takes the kWh of each child sensor of a utility meter (it has 3 tariffs)
{% if states('sensor.washer_utility_meter_mid_peak') in ['unknown','unavailable'] or
states('sensor.washer_utility_meter_off_peak') in ['unknown','unavailable'] or
states('sensor.washer_utility_meter_on_peak') in ['unknown','unavailable'] or
states('input_number.hydro_rates_midpeak') in ['unknown','unavailable'] or
states('input_number.hydro_rates_offpeak') in ['unknown','unavailable'] or
states('input_number.hydro_rates_onpeak') in ['unknown','unavailable'] %}
{{ None }}
{% else %}
{% set mid_usage = states('input_number.hydro_rates_mid_peak') | float(0) %}
{% set off_usage = states('input_number.hydro_rates_off_peak') | float(0) %}
{% set on_usage = states('input_number.hydro_rates_on_peak') | float(0) %}
{% set mid_rate = states('input_number.hydro_rates_midpeak') | float(0) %}
{% set off_rate = states('input_number.hydro_rates_offpeak') | float(0) %}
{% set on_rate = states('input_number.hydro_rates_onpeak') | float(0) %}
{{ (mid_usage * mid_rate) +
(off_usage * off_rate) +
(on_usage * on_rate) }}
{% endif %}
If I am following the rest of this thread correctly I need to test to test if ANY of the sensor values used in the equation are in an unknown or unavailable state. If so, return None which will be stored as an unknown state. If we didnāt do this and we did the math it would return a 0 for any unavailable sensor which would throw the calculation off because of the float(0) applied to each state would render the unknown or unavailable to 0.
Just double checking this is what was recommended way of doing this using the template section so you donāt have to use the configuration YAML
In my opinion, omitting the āavailabilityā feature from the graphical user interface for sensors may not be a prudent decision.
2 Likes
If anyone is available for testing, it would be good to test this PR:
It says āPull request successfully merged and closedā, does it mean "availability check"s will be in one of the next releases in the template UI?
added in 2025.8
3 Likes