I want to compare two humidity sensors that usually have similar numbers but may be a bit different, but one would spike up during a shower. I want a fan to turn on when the bathroom humidity sensor goes significantly above the hallway humidity sensor. But at rest, like now, the bathroom is just a little higher, so I need to add some fake buffer humidity to the hallway value for comparison to the automation.
#How do I create a fake sensor that adds 10 to a humidity sensor?
quiet gull
quiet gull
Answer: Create a Helper, of type "Template" Pick Sensor. Give it a name, Enter the state like {{states('sensor.my_ecobee_current_humidity') | float + 10}} Set the other other stuff like it is a humidity sensor. Done.
kindred mesa
To avoid errors if the ecobee humidity sensor is ever unavailable, you can set a default by doing float(x) where x is the value HA should use if the sensor is unavailable. I usually just set it to zero
quiet gull
So {{states('sensor.my_ecobee_current_humidity') | float(90) + 10}} ?
I'm trying to keep another value below this, so I don't want to undershoot this value.
brisk viper
Or even better, test if the source sensor is valid and only then use the valid number
{% set num = states('sensor.my_ecobee_current_humidity') %}
{% if num | is_number %}
{{ num | float + 10 }}
{% else %}
unavailable
{% endif %}
Why is this better:
- It only shows humidity when the source sensor really exists and has valid value
- You can use the
from/toin the automations forunavailableto know when you should not react because sensor doesn't exists.
Or if you prefer it shorter form:
{% set num = states('sensor.living_room_average_temperature') %}
{{ iif(num | is_number, num | float + 10, 'unavailable') }}
delicate iron
```yaml
{% set num = states('sensor.my_ecobee_current_humidity') %}
{% if num | ...
This isn’t the way to make the sensor unavailable. It will result in errors if the sensor has a device_class or unit_of_measurement defined.
Use the availability_template option to define when the sensor should be unavailable. That is the sole reason that field exists.
brisk viper
Even better. But this can't be done from the UI, or it can be?
delicate iron
Yes, it is under “advanced options” since a few releases ago
brisk viper
but if he uses the state trigger, it should work with my proposal to have the not_from unavailable, no?
what errors may it trigger?
delicate iron
When the template renders a result that isn’t a number, the template sensor will show errors in the log that it expected a number and didn’t get one
I don’t recall what the state of the sensor does, if it just keeps the previous result or changes to unknown or unavailable. So there’s a chance it might still achieve the goal but it’s still not a good idea
brisk viper
this is what I get. So there seems to be a difference. But I am not sure it will apply to his case.
Because the worst case it can happen to him is that sensor isn't available and he adds +10% and automation will get triggered if he has a test like "below 30%" or whatever
delicate iron
You’ve got to stop trusting AI
Try it out for yourself. I refuse to argue with someone who is a proxy for AI garbage
brisk viper
I am not saying it is true 😄
but you are master of templates, I'd be happy to hear from your side the diff between setting template value to unknown or unavailable vs device_availability ?
especially in a context of triggers and from/to and not_from/to settings
hard blaze
Unknown and unavailable from within the template should never be done. It uses things people shoehorned into the entity classes. I’m making a release in the future that will allow unknown and unavailable from within the template.
(While handing everything properly).
That pr will be a breaking change and will likely be in a few releases
brisk viper
so it means if the state will return unavailable, it will be detected same as if device_availability sets the device as unavailable?
hard blaze
Yes
brisk viper
Honestly, I have been always using unavailable as a state when one of my sensors for average wasn't available. Otherwise I got dumb down spikes before I uses the / count(valid_sensors)
hard blaze
But right now, using unavailable does bad things for most template entities
brisk viper
fair, thanks.
hard blaze
Yeah, you shouldn’t do that because it doesn’t actually do anything
delicate iron
In the current release, the sensor will hold its previous value
brisk viper
in the history chart it shows empty area for the time it is unavailable or unknown, but not spike because the average is not average of all sensors - this is my case at least.
now the question is, is there a way to have a feature that would make sensor unavailable of at least one of the sensors referenced in the template isn't available, similar to like group has feature (but there we select entities)
delicate iron
Are you confusing a template sensor helper with a “combine the state” helper?
brisk viper
There is no sensor in HA that could compute the weighted average. I do it with the template.
delicate iron
if you have a device_class or a unit_of_measurement set in your template sensor, then it won't accept any text (like unavailable) as a result. It will put errors in your logs, and the state of the template sensor will remain as the last valid numerical result. If you reboot while in this errored-but-last-value state, the template sensor will come back as unknown. As soon as the template sensor gets a valid numerical result it will resume behaving normally and will stop spamming your logs.
The error will be slightly different depending on what you choose for a device class or unit of measurement, but a representative example:
ValueError: Sensor sensor.your_template_sensor has device class 'temperature', state class 'measurement' unit '°C' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: 'unavailable' (<class 'str'>)
cedar salmon
If you return any string in a sensor which expects a numeric value, it will become unavailable and return this error
To avoid the error, use an availability template, or return none which will make the sensor become unknown
delicate iron
the behavior I think is different from last time I tested it, but with the latest HA version (2025.12.1) the error comes up under
Error while dispatching event for sensor.whatever_sensor_is_referenced_by_the_template_sensor ...
It eventually says the error I listed above (ValueError) but it's at the very end of all the detail.
And the value of the template sensor doesn't go to unavailable instead it remains at its last known good value
Using none does still result in the sensor becoming unknown
hard blaze
I wouldn't commit any of this to memory for too long. I'm going to be putting in a PR that allows all template entities to be set None, none, unknown, and unavailable from within the template and it will properly handle those istead of writing strings to places where it shouldn't (I.e. create exceptions)
And all entities will behave the same way as well in regards to those values.
delicate iron
Nice, that will be a welcome improvement