I needed to create a sensor with the value from water meter. It has number and it is always increasing. So I’ve started to implement it with HA counter. But it turned out that in history it is showing as discrete values:
Some time ago I had similar problem with template sensor. I’ve fixed the graph for the template sensor by adding unit_of_measurement. But unit_of_measurement can’t be specified in counter.
So, I’ve stopped using counter and used input_number. And it works fine.
But now I’m interested. The counter and input_number are very similar. In both there are ways to increment/decrement/change value. Why we need counter when there is input_number?
(I’ve found PR where the counter was implemented https://github.com/home-assistant/core/pull/9146 but there is not info why it is needed and what problems it can solve that input_number can’t)
Yesterday, I found a need for using a counter. It serves as a list index.
The list is stored in an input_text. It contains lighting colors.
The counter indicates the index of the next color to be displayed.
Each color in the list is displayed in sequence (several minutes per color) and increments the counter.
When the counter reaches the list’s length, an automation is triggered. It resets the counter to 0 and then shuffles the list of colors. Now the list is in a new random order and ready for use again.
EDIT
Could I have used an input_number? Probably. However, at least for my purposes, the word “counter” is a better description of how I am using it as a list-index (so the code is a little more self-explanatory). I have no need to display the list-index nor its history.
Nevertheless, I do understand your point that the two have redundant functionality.
The counter integration was introduced in 0.53 and input_number in 0.54. It would be interesting to learn how two very similar integrations (in functionality, not presentation) were introduced nearly at the same time.