Utility Meter should support negative numbers reflecting usage from a reservoir

I am reading from a level sensor in a reservoir with a slowly declining value that is occasionally reset when the reservoir is refilled. The utility meter sees this sensor’s changes as a negative value, and it will only register negative changes if you switch it to a net consumption mode. In net mode when the reservoir is refilled, the delta of the sensor gets rolled back into the consumption, which is incorrect.

What is needed is for the utility meter to have a “negate consumption” flag, rather than force it to use net consumption for this application. This way I would correctly see a report of 8 gallons used in a day, instead of -8 gallons, and it should correctly handle the refill when the reservoir level sensor jumps back up.

What sensor are you feeding to the utility meter?

The tank level or flow in/out?

Net should be what you need if you are using a flow sensor.

The input sensor is the remaining level.

So, tank level.

That’s your problem.

Consider a battery. You feed the utility meter the Ah or Wh flow into (+) and out of (-) the battery and the utility meter in net mode tracks the battery charge.

You do not feed it a raw SOC, (state of charge) sensor.

Likewise for your tank, if you want to keep track of the capacity you would have to feed the utility meter in net mode the Litres (or pints or whatever) flowing in and out, not the remaining level.

Of course this should be a calculated flow, not some kind of measured flow, because with measured flow you get the usual integration problem, the error adds up over time.

Since this is such a common case and it is actually preferable to have an absolute measurement like a tank level, I think it would be a reasonable policy for Home Assistant integrations to prefer accepting absolute measurements and calculating the “flow” itself. This would discourage users from feeding in data that is prone to drift.

No, I don’t think it’s a battery - I do not need to track the reservoir level because the sensor already gives me that. I need to know how much stuff I consumed from the reservoir. The recharge of the reservoir comes from another source, I did not push stuff back across the feed line.

I think Utility Meter will do exactly the right thing if it negates the delta before accumulating it. In net mode, the meter treats the reservoir being refilled as if it was flow the other direction, which is the wrong behavior for my use case.

Then you need a flow sensor, with direction.

I think you need to use this to get your flow to/from the tank:

Then feed that to a utility meter.

I could be wrong but I’m guessing that is outside the scope of this integration. See the derivative integration instead.

Hm, interestingly the docs for the Derivative sensor say:

For sensors that reset to zero after a power interruption and need a “non-negative derivative”, such as bandwidth counters in routers, or rain gauges, consider using the Utility Meter integration instead. Otherwise, each reset will register a significant change in the derivative sensor.

That seems to be exactly @bretton.wade’s use case, so using the Utility Meter sensor seems the right way to do?

Maybe the only issue with @bretton.wade’s tank is that the number goes up when the tank is filled and down when it’s emptied? Maybe if he’d just invert the sign, making it a usage level instead of a remaining level, it would work properly?

1 Like

And the Utility Meter could do this for me if it had an “invert” option, and I’d have the nifty reset feature.

I think that’s a reasonable feature request, but for the time being you can always use a Template Sensor that inverts the value and then use that as the input sensor of the Utility Meter.

Not really. I either need to know how much was refilled each time, or I have to do what I’ve done with a template sensor that essentially implements the utility meter functionality without the reset. It’s a bubblegum and shoestring fix, though. The Utility Meter would be the right thing, just it’s missing a piece because it’s spec’d too narrowly for all the ways the function could be used.