HA has made leaps and bounds over the years in making it more user friendly to non-tech savvy people. Automations are much simpler and the UI for them improves every year. But right now, something as simple as creating a number, and then comparing it to another number, is overly complex for something that should be extremely simple.
I am looking at a numeric state of an input number in an if statement in the automation UI. I have to use a bloody value template! For a single digit integer! Are you serious? If I asked my roommate to create his own automation, he’d just install the HA app instead.
The UI’s options include attribute, which uselessly lists init value, min, max, step, and mode. None of these are the current value, so I can skip that. The next sections are lower limit and upper limit. Well, I am trying to see if the number is set to 7. The lower limit is useless here of course, because that’s 0, and upper limit is 100 because I happened to create the input number ten minutes ago and set it to 0-100 because HA, for some reason, wants a stupid range on an integer. Does a normal user have any use for that? Not that I can think of. A min and max, in general, sounds like some weird thing people with extremely specific use cases want. I want to count from zero to some positive number and frankly have no reason to set a maximum limit. Normal people don’t go around thinking about maximum limits on integers. Enough about limits. The UI does not seem to offer the option to check the actual existing state of the input number. Is that not the only thing people ever want to do with a number? Check what the number is set to?
I can of course just use the stupid value template, which I can never remember the syntax of so I have to google it, and I end up with
{{ states('input_number.days_since_thing_used') | int >= 7 }}
Great, can’t wait to recommend this to my friend who would rather use Google Home over Home Assistant because it’s too complicated. Clearly, it is!
I created an action type of “If/Then”, and then chose a condition of “Numeric State”. The entity is my input number. Attribute, Lower limit, Upper limit, and Value template are my options as described above.
If you don’t know what those things mean, just ask.
Your original criticism was based on a faulty premise because you didn’t read the docs.
Can HA be simpler to use? For sure. It’s not being sold for profit by a multi-billion corporation, though. It’s an open-source project and you can contribute even if all you’ve got is ideas. Put them in the right place, though, like the feature suggestions forum, or by following the link on every documentation page for suggestions about how to improve the documentation.
“Lower limit” is needlessly confusing. If that’s what should be used to check if X > Y, it should be renamed. Factorio has better number comparison UX, and that game’s a nightmare to program basic things in.
If you use the input number to set a temperatur value for your thermostat, then you will be happy for the step value to set it to .5, so you can make smaller steps and max and min values, so you do not have a slider that do nothing between 0-7 and 27-100.
[quote=“smugleafdev, post:1, topic:924253”]
I happened to create the input number ten minutes ago and set it to 0-100 because HA, for some reason, wants a stupid range on an integer. Does a normal user have any use for that? Not that I can think of. A min and max, in general, sounds like some weird thing people with extremely specific use cases want.
[/quote]
Sorry, but you’re just wrong. Many of us ‘normal people’ have an automation or a script that sets an entity’s state or attribute when an input_number changes, and that means that the number should be within the range that the entity expects because many entities will not accept an state or attribute change if the number is outside the expected range. For example, a light may expect a brightness range of between 0-100 (or 0-255). Many of us normies also use an input_number to act as a filter, like setting a range of 60-85 for an input number to ensure that no one can set the thermostat outside that range. Another example is would be a upper limit of 90 for window blinds to ensure that the window blinds never open all of the way.
There are many reasons that upper or lower limits can be used.
A “numeric_state” needs either an “above” value or a “below” value. For example, if the number value you want to check is 7 (integer) then those would be equivalent to “>=8” or “<=6”.
if you instead want to know if the value is exactly 7 then you need to use a “state” condition instead of “numeric_state”. then you just set the “state” option to 7.
Sounds like you should have been using a counter all along then. All those things you complain about are optional for counters.
Attributes are optional in an automation. You don’t need to populate them. Just fill in below & above values, or just use state like others have suggested.
Clearly, you’ve been here since 2019 and still haven’t read the docs
As the OP, assigning the solution tag is your prerogative… but can you explain how using a conditional card fixed an issue you were having with an automation?
I wanted the first automation to increment it each day at midnight, and the second automation to set a flag (show = true) based on checking the integer value upon state change. I wanted the flag for deciding whether or not to show it.
By skipping the flag and instead using the surprisingly simple conditional logic in a conditional card, I can have it show the card or not and be done. I don’t know why the conditional card UI is so much better for this than automations.
