The minimum and maximum does not always serve a purpose, neither does step size. Unfortunately, the fields are mandatory. Filling out a maximum number of 999999 isn’t a very elegant solution. But it’s necessary to prevent errors when a service tries to set it to a number higher than its maximum:
I am usually not planning to modify the number helper from the dashboard, but occasionally I might. But this also results in an error.
+1 for this. I’m often creating automations where I need some intermediate values, e.g. to sum values from multiple sensors, capture states at certain times, and so on. I actually DON’T want mins or maxes (a pain when summing things that always grow, like cumulative values) and DON’T want a UI (I don’t want to change a value I recorded with an automation; but the UI shows up just when I want to display the value).
So… after reading some more, it seems the “right” want to do this is to use a “template sensor”, one form of which is a number computed from other numbers when they change, according to some function (expressed as a template, hence the name). So this also gets rid of the automations I defined to update input_numbers.
Would be great if the documentation on this could be clearer, e.g. the docs for “input_number” should say “if you really want and internal variable used by other rules, then…” or something.
Not completely sure that template sensors replace all instances of what a general “number” helper would provide. While I can use template sensors to replace “derived” values (e.g. updating “net energy” as a difference of inputs and outputs) it’s harder to do things like capture a value at a specific point in time (e.g. the state of my battery at the start of the day, to use as a basis for other calculations, to set a baseline for daily calculations, etc).
Well… templates can have triggers, and time of day can be used as a trigger. So I guess it’s possible, but not obvious.
Another way mentioned for my particular problem is to use a “utility meter” helper, which resets periodically and only shows the change relative to the reset point.
@msp1974 I was aware, but it’s quite an advanced third party integration for a feature that is supposed to be present in Home Assistant. After all, the reason that variables haven’t been added to Home Assistant as a native feature is because you should be able to use helpers to achieve the same thing.
The problem is that the input number helper is actually too advanced by default, which creates limitations.
Hence my response: what the heck!?
I try to avoid unofficial integrations unless they contribute significantly (meaning I’m still using a bunch of them… sigh…) just to keep the maintenance burden as low as possible.
Another not so great solution is to use an automation to fire and event and use a template sensor that’s triggered by the event and sets the value as its state.
home-assistant-variables mentioned by @msp1974 is probably a better option though as the above will become quite complicated.
