Numeric_state - why no 'equal to'?

I’d rather not add noise to the feature requests if this isn’t valid.
So, is this a valid feature request?

Using ‘numeric_state’, if you want to know if an entity is exactly n you have to use below and above which is fine so long as you know the precision of the number you are dealing with.

What if you don’t?
I’m resorting to using the slightly ridiculous below: 0.001 to check for exactly zero which is fine as I am checking an input_number which I defined to have a step of 0.1 (and I know it can’t be negative). But what if the entity state was a floating number of indeterminate precision?

Or even what if in the future I change the step for my input_boolean? It could break some automations and that can’t be right.

1 Like

Can’t you just use state instead of numeric state?

I tried state but the config check didn’t like state: 0 as it seemed to want a string. I think
state: '0.0'
worked but again that requires knowing the precision of the number.

Unless of course I am entirely mistaken…

You can use a value_template to set what ever value you like.
In your case something like this :

value_template: '{{(states.sensor.yoursensor.state) == 0}}'

If you’re worried about precision, round the value to the nearest whole number like this:

value_template: '{{((states.sensor.yoursensor.state)|round(0)) == 0}}'

2 Likes

All said I think it’s a valid feature request to improve usability.

7 Likes

Of course!! Obviously!! Thanks.

I still think numeric_state could do with equal_to but maybe it’s not pressing enough to ask for…

3 Likes

Can you please tell me your real-life use case for this? Just curious.

If you look here you’ll see that there is a ‘check box’ used to ‘Skip’ a zone. If the duration is changed to 0 that box should be checked. If it is changed to not zero it is cleared.

The check box can also be checked manually if that zone is to be skipped only for the next run, in which case the duration is not set to zero.

(I hope that makes sense)

You are obviously not a programmer. No programmer ever checks a float to be equal to something. It is considered bad practice. The way a float is represented inside the cpu is different from what we see.

2 Likes

I was. Back in the 80s and 90s…

Therefore, you’re wrong about that because I just did :stuck_out_tongue_closed_eyes:

And writing YAML for HA is not even in the same ballpark as programming machine code.

Seriously though, yes, but I STILL say if there is function to compare a numeric state it should allow a comparison to Equal.

And we all know that zero (which I wanted to compare it to) is always a special case :wink:

11 Likes

only programmers should use HA?

9 Likes

No. But programmers don’t try to compare a float with 0 (or any other numeric value), because a float rarely is equal with what you have in mind.

1 Like

By definition with a float it is rare. 1 in infinity is pretty rare, which of course is true for integers too :slight_smile:
But what if there IS a reason you want to know if it IS what you have in mind.
Like I do…

3 Likes

OK, my case is that if the termperature is <0C, I want to use electric strip heat, if >0C, I want to use a heat pump. They can’t be on at the same time, and obviously I’d like not to fall in the middle and have no heat, so if I were programming I’d make one >=0, and one <0…so I concur that it would be handy to have the ability to do more comparisons than > and < within numeric state.

1 Like

I’ve run into this issue as well.
I’m changing colors of lights based on my heart rate. I’m retrieving the bpm via API which returns a whole number (string?) 109, 142, 163, etc.

The ranges are as follows:
Aqua: <109 bpm
Olive: 109 to 125
Gold: 126 to 142
Orange: 143 to 159
red: >160

My automation fails or doesn’t act as expected at the border cases. 142 for instance fails when I had my automation ranges set the same as the bpm ranges. If I set one condition to above 141, I’ve created a situation where two conditions are true at the same time which doesn’t seem ideal. A Greater than or Equal to state would alleviate this issue without adding more complexity or thinking to this non-programmer’s automation.

You could trigger on any change in bpm, no conditions and then in the action part determine the color that the light should be set to with an IF-ELIF-ELSE statement or with the choose function.

Use templates to get the triggers/conditions you want, not numeric_state.

I’m sure there are a myriad of ways around this, and I’d love to understand them, but mainly I’m reiterating that from the interface, for a non-professional programmer, not being able to specify ‘equal to’ is a surprising lack of functionality.

3 Likes

It’s not really surprising. It’s a fairly simple thing to do with a template. This is most likely the reason it hasn’t been added.

If you want it added to numeric_state, this is not the place to do it. Configuration is for support. Head over to feature requests and make a formal request for this functionality.

OK. Could you point me in a good direction regarding how to use templates here?

Here’s a link to my current script. Peloton support