Add a flag to manage always incrementing total counters

[FlyingDomotic]

I have few modules that are sending a total incrementing counter (meaning, new value is always greater than (or equal to) previous one).

When changing batteries, the counter goes back to zero, and starts incrementing again. This may also occur when restarting some MCU based devices, or using counter that are reset to zero at midnight, as some energy providers do when sending only today's value.

When using a "classical" counter, daily, weekly and yearly values (in Meter_Calendar) are false (producing a spike into graphs), as computed as higher value - lower value (done in SQLHelper.cpp, (AddCalendarUpdateMeter) line 7625)

Suggestion, when such kind of counter (we may find thought a new "always incrementing counter" flag) is updated, is to compute new value as follow:
- when new value is greater (or equal to) saved previous one, add difference (new - previous) to current one
- else add new value to current one

In all cases, save new value into previous one, to be able to compare next turn.

This could be seen either as a specific type of incremental counter, whose value is computed or a specific type of classical counter.

[HvdW]

In such cases you can rely on the manual.
Search 'Replace device', plus there are items on this forum that discuss this topic.

Maybe this is usefull in your case.

[waltervl]

I have counters that are cumulative but also could be giving negative delta values (so counter value not always greater than previous) so your proposed logic will not work.

In your case that the counter starts from zero, deleting the first erroneous value from the Meter_Calender (by shift-clicking) on the month graph value will solve the issue. The only downside is you will loose a day of values.

How are your battery power modules sending counter data? As I am not aware of Zigbee/Zwave devices doing this. Are those self build devices?

[FlyingDomotic]

In such cases you can rely on the manual.
Search 'Replace device', plus there are items on this forum that discuss this topic.

Maybe this is usefull in your case.

I RTFMed, but this is not the solution. Using it, my counter is back to low value, and total is lost.

Not to say it's hard to replace a device by ... itself!

[FlyingDomotic]

I have counters that are cumulative but also could be giving negative delta values (so counter value not always greater than previous) so your proposed logic will not work.

In your case that the counter starts from zero, deleting the first erroneous value from the Meter_Calender (by shift-clicking) on the month graph value will solve the issue. The only downside is you will loose a day of values.

How are your battery power modules sending counter data? As I am not aware of Zigbee/Zwave devices doing this. Are those self build devices?

Among them, there's a ZigBee water meter counter device, which cumulates drawn liters, and looses total when reset by a battery change.

I also have a external site providing daily counter (reset by construction to zero at midnight) I want to cumulate to keep my Domoticz total counter in sync with provider's total.

[waltervl]

I also have a external site providing daily counter (reset by construction to zero at midnight) I want to cumulate to keep my Domoticz total counter in sync with provider's total.

This is easily done by dzvents scripting:
Read the current total Domoticz counter at 0:01 and store that in a persistant attribute
Read the daily counter value from external site and send 0:01 value from attribute + daily counter value to the counter.

[FlyingDomotic]

I already implemented this kind a workaround. It uses 2 counters, one being useless as containing bad data. Idea was to have only one counter, with right data.

As it seems to me that daily counters and batteries changes are common events for lot of users, I did propose this suggestion.

[waltervl]

Daily counter perhaps more frequent but battery counters I have never heard of until you mentioned this in this topic. For watermeters mostly the incremental counters are used that only send something when there is something to report.

Do you have a link to that zigbee watermeter? I have never seen it and I have a zigbee environment so interested.

[FlyingDomotic]

ZigBee device is a DYI one build around a CC2652RB with a TI stack and 2x1,5V batteries. I wrote code some years ago, it's still working

As there's no MCU (just s single CC2652RB chip), there's no storage to save counter, so it's lost each time batteries are changed (CC2652 never crashed).

[PierreT]

I'm not really following this. I know this thread started from a comment made in another topic about P1 data, which is probably the only meter device that allows numbers to decrease because the report is always considered to be actual. That said, for day reports this should only pose an issue on the very day that you change the battery at which point the counter may go from several thousand kWh to zero. The logical response to this is to delete the *calendar entry for that day if it contains a huge negative. I'm actually not even sure it does though because as far as I know the P1 interface doesn't allow negative at all and I think it will show zero in the day report.

[FlyingDomotic]

I may eventually delete a daily value, but this also ruin a leak detector script, which uses one minute, one hour and one day consumption to find a potential leak.

But I'll still have a incorrect total counter, while I at least want it to be in line with real one on my meter, to compare it with my invoices.

Not to say I'll delete every day values for provider's midnight reset counters, making Domoticz not very helpful for them

As written in title, this is a suggestion to improve Domoticz, making it closer to user's needs. Being in IT since it's very beginning (1975), I learn that user satisfaction is mandatory to have good products