Numeric_state - why no 'equal to'?

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.

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
1 Like

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.

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.

You are quoting a post of 4 years ago. Maybe you should not necropost ?