It is not. Straight form one of my dashboards:
1 Like
In Real you don’t change the Sensors Precision, You Round(x) The Output, , And yes as you see/saw, You Can round to 1 digits
PS: Some Cards don’t “respect” this Setting, so it will show i.e 3 digits/6 Digits, what ever the Sensor Provide ( You can solve this with Templates )
Sorry, Don’t Complain here, Complain to the Manufacturer of the Device(s) or Author Card(s)
1 Like
If this was in the feature requests, I would probably vote for the topic of the post. I was a programmer for a long time, and I know enough about floating point arithmatic to be able to say isn’t easy to explain. And we want Home Assistant to be usable by people who aren’t programmers. The above discussion makes clear why something is needed to bridge the gap.
I also always struggle with the below and above to know if they are inclusive or exclusive. Even the documentation isn’t very clear. The condition says nothing about it, the trigger hints to exclusive, so does the label (if my English is good enough, but many here are non native speakers). Someone in the thread above claims it is inclusive. So how is anyone to know that an integer can be tested with state is 0, with decimals it gets ugly, 0.0 might work or not. And a numeric state above 0 and below 0 may or may not work, so you may need above -0.001 and below 0.001 to test for equal to 0?
As stated above, a target value and precision is what is often used to do this kind of comparison, and I think it would help.
1 Like
That was me, and I’ve retracted that claim. The test is False if the new value is equal to above or below.
From the source, homeassistant/helpers/condition.py (used as the basis for the trigger too), currently around line 340 (with lots of omissions and my own comments):
# where 'below' is an entity:
if fvalue >= float(below_entity.state):
condition_trace_set_result(
False,
state=fvalue,
wanted_state_below=float(below_entity.state),
)
return False
# where 'below' is a number:
elif fvalue >= below:
condition_trace_set_result(False, state=fvalue, wanted_state_below=below)
return False
# where 'above' is an entity:
if fvalue <= float(above_entity.state):
condition_trace_set_result(
False,
state=fvalue,
wanted_state_above=float(above_entity.state),
)
return False
# where 'above' is a number:
elif fvalue <= above:
condition_trace_set_result(False, state=fvalue, wanted_state_above=above)
return False
# where none of the 'False' conditions has been met
condition_trace_set_result(True, state=fvalue)
return True
2 Likes
I can see how at first sight someone would draw wrong conclusions. I had to read twice. Now I’ll never forget.
I try to avoid digging into the code, because normal users wouldn’t be able to do so also. With the exception above, I find the documentation to be of very high quality. It always gives me the answers I need. Even this example, it is there in the words above and below, although it is hard to gauge because people often use language imprecise. But I should have known, if a programmer wrote it, it is precise.
1 Like
The documentation is also open source, of course. You can submit a pull request or provide feedback via the links at the bottom of each page.
As a software developer, I am disgusted by this message. Instead of attempting to understand the problem and offer a reasonable solution, you leave this garbage.
1 Like
You are quoting a post of 4 years ago. Maybe you should not necropost ?
I came across an automation where I wish to check if an entity is 1 or 3 or 5 in order to turn on a switch else turn off.
The entity to be checked “power_level” will be set with values 0-6 in another place (it will be an “input” type sensor) based on some dynamic conditions.
In the automation configuration interface there are conditions for check > or < or template.
How do I check if the number is ==, more than that ==1 OR ==3 OR ==5?
I know it seems pretty simple but I’m confused the way to go?
An example with OR conditions in value template would very helpful.
(LE:
temporary I managed to set conditions >0.1 + <2 as workaround for checking the value ==1, >2 and <4 for checking value 3, and so on)
Thanks a lot.
for equal to, just use a normal state condition.
- condition: state
entity_id: ...
state: "1"
If the value is numeric then you have to manually modify it to be state: 1 instead of state:"1". At least if this hasn’t been implemented yet in the past 2 months: Add visual editor support for numeric values in state trigger/condition · home-assistant/frontend · Discussion #21946 · GitHub
1 Like
You’re referring to using the UI over yaml?
It doesn’t matter if the UI sets up the yaml or you, if you check equality between a string and a number, it will never be true.
Yes, that’s why you add the quotes to the yaml, to ensure it’s a string.
Adding the quotes is what breaks it. If you are using the visual editor then you have to manually edit the yaml to remove the quotes.
States are strings, so what you’re saying doesn’t make sense unless there’s code in the backend that converts the states to a numerical result.
Ah, on my link it’s the position attribute of a cover that needs to have the quotes removed. For states that include numbers, you do need the quotes but you also need to use the correct precision, like “0.000” to make it equal.
Thanks guys.
Too complicated.
It has to be simple (and preferably) in GUI, visual.
Where do I write that condition in automation GUI? (I know the question looks stupid)
I know most of coders likes to write code but I am not one.
The workaround I mentioned works ok for the moment.
same place as any other condition. Literally just add a state condition. There’s nothing more too it.
Thanks. I figured out later.
Being a number, usually I check values.
(long story, I had this discussion in the past, why a “number” is not considered a number and see a graph history)
This is a different approach, checking state, I did’t think about.
Conclusion:
It does not work. In yaml the state is “1”.
The yaml edit>save is not possible since if “” removed it reclaims some malformat error.