What is the use cases for 'counter'? Why not to use input_number

I have recently found out that there is a counter in Home Assistant ( https://www.home-assistant.io/integrations/counter/ )

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:

2020-06-30 17.09.15

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)

The counter already has increment, decrement and reset services. You would have to write automations for the same functionality with an input number.

I wouldn’t use either of these though. I’d use a sensor. How are you getting the value into home assistant?

BTW, if you want an hourly/daily/monthly/yearly total from your ever increasing water meter sensor check out the utility meter:

Yes, thank you I’m using utility_meter with input_number and it works fine.

I’m not sure that I understand you first part of the answer. There are also services input_number. increment and input_number. decrement — https://www.home-assistant.io/integrations/input_number/#services

I was going from my poor memory. Ok, scratch that reason.

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.

But you could just have easily done that with an input number as the pointer.

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.

Ha. I thought that input_number has appeared earlier than the counter. Thank you for pointing that out.

Counters can only store integers, input_numbers can also store floats. Seems to be the only real difference

1 Like

Originally, input_numbers didn’t have an increment or decrement service. Over the past few years, the’ve come more in line.