Rate too high error even on unchanged value

[derandiunddasbo]

There seems to be something wrong with the plausibility check when MaxRateValue is activated as I'm getting "rate too high" errors immediately after enabling the option, even when the new value didn't change at all:

2021-07-14T16:25:23: task_autodoFlow - next round - Round #2
2021-07-14T16:25:23:    FlowControll.doFlow - ClassFlowMakeImage
2021-07-14T16:25:27:    FlowControll.doFlow - ClassFlowAlignment
2021-07-14T16:25:58:    FlowControll.doFlow - ClassFlowDigit
2021-07-14T16:26:08:    FlowControll.doFlow - ClassFlowPostProcessing
2021-07-14T16:26:08:    FlowControll.doFlow - ClassFlowMQTT
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=39102, wasserzaehler/zaehlerstand/connection, connected
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=62617, wasserzaehler/zaehlerstand/uptime, 345
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=3334, wasserzaehler/zaehlerstand/freeMem, 2989464
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=24486, wasserzaehler/zaehlerstand/main/value, 375.270
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=5754, wasserzaehler/zaehlerstand/main/error, Rate too high - Read: 375.270 - Pre: 375.270 
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=24221, wasserzaehler/zaehlerstand/main/rate, 0.000000
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=6423, wasserzaehler/zaehlerstand/main/timestamp, 2021-07-14T16:20:36
2021-07-14T16:26:08: sent publish successful in MQTTPublish, msg_id=4280, wasserzaehler/zaehlerstand/main/json, {"value":375.270,"error":"Rate too high - Read: 375.270 - Pre: 375.270 ","rate":0.000000,"timestamp":"2021-07-14T16:20:36"}
2021-07-14T16:26:08: task_autodoFlow - round done
2021-07-14T16:26:08: CPU Temperature: 42.2

This is my config:

[MakeImage]
;LogImageLocation = /log/source
WaitBeforeTakingPicture = 5
;LogfileRetentionInDays = 15
;Brightness = -2
;Contrast = 0
;Saturation = 0
ImageQuality = 5
ImageSize = VGA
FixedExposure = true

[Alignment]
InitialRotate = 90
InitialMirror = false
SearchFieldX = 20
SearchFieldY = 20
;AlignmentAlgo = default
FlipImageSize = false
/config/ref0.jpg 150 107
/config/ref1.jpg 390 315

[Digits]
Model = /config/dig1040s1q.tflite
;LogImageLocation = /log/digit
;LogfileRetentionInDays = 3
ModelInputSize = 20 32
main.digit1 87 193 50 90
main.digit2 136 194 50 90
main.digit3 185 194 50 90
main.digit4 231 194 50 90
main.digit5 279 195 50 90
main.digit6 326 197 50 90
main.digit7 375 198 50 90
main.digit8 420 198 50 90

;[Analog]
Model = /config/ana0700s1lq.tflite
;LogImageLocation = /log/analog
;LogfileRetentionInDays = 3
ModelInputSize = 32 32
ExtendedResolution = false
main.analog1 444 225 92 92
main.analog2 391 329 92 92
main.analog3 294 369 92 92
main.analog4 168 326 92 92

[PostProcessing]
main.DecimalShift = -3
PreValueUse = true
PreValueAgeStartup = 720
AllowNegativeRates = false
main.MaxRateValue = 0.1
ErrorMessage = true
CheckDigitIncreaseConsistency = true

[MQTT]
Uri = mqtt://xxx:1883
MainTopic = wasserzaehler/zaehlerstand
ClientID = wasserzaehler
user = wasserzaehler
password = yyy

;[GPIO]
;MainTopicMQTT = wasserzaehler/GPIO
;IO0 = input disabled 10 false false 
;IO1 = input disabled 10 false false 
;IO3 = input disabled 10 false false 
;IO4 = built-in-led disabled 10 false false 
;IO12 = input-pullup disabled 10 false false 
;IO13 = input-pullup disabled 10 false false 

[AutoTimer]
AutoStart = true
Intervall = 4.85

[Debug]
Logfile = true
LogfileRetentionInDays = 3

[System]
TimeZone = CET-1CEST,M3.5.0,M10.5.0/3
;TimeServer = fritz.box
;AutoAdjustSummertime = 
;Hostname = watermeter
;SetupMode = false

And here's the version info:

[jomjol]

Known bug in that rolling version. Try to update to the newest rolling (= master v8.0.0), there the error is correctet.

[derandiunddasbo]

Ok, the rate too high error seems to be gone with version 8.0.0.

Yet, there's still an issue with the device stubbornly publishing previous values, even if the current raw value is a valid number and should pass all post processing. I don't know if this may still be related to the former rate check bug:

[jomjol]

Please put CheckDigitIncreaseConsistency to false. This switch might cause trouble with purely digital devices, as it relies on continious last digts (375.377 --> 375.378 --> 375.379 ...). If due to a higher consumption one of these digits is skipped, the algo start to fail.

[derandiunddasbo]

I'm not sure, if deactivating CheckDigitIncreaseConsistency will lead to better results in my case.

I intentionally activated this setting, because I observed the algorithm never updating the value, if one of the digits was not recognized (NaN). This may not be a big deal for the rightmost one or two digits, but some days ago the value was stuck at 374,922 for almost two days, and only updated again, when the meter showed more than 375,1xx m³, because the digits on my meter most of the times are a tad too low to be fully visible, as long as a digit right next to it is still at "0".

So for now I could try with deactivating this setting, but I probably won't get updates for weeks, when the 10m³ digit ("7") is rolling over the next time.

[jomjol]

Maybe an advance checkconsistency algo is needed, that only works starting on the second last digit. This one really relies on the fact, that each number after the other is detected. I'll think about it.

[jomjol]

No further acitivties - please reopen in case further questions.