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.
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.
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.
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.
By definition with a float it is rare. 1 in infinity is pretty rare, which of course is true for integers too
But what if there IS a reason you want to know if it IS what you have in mind.
Like I do…
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.
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.
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.
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.
