Viel zu großer Sprung V10.03

[blaumsass]

es wird bei Digital Wechsel oft im 1.XXm³ gesprungen. Bei den alten Verison stand immer in der Config.ini maximum change per read.

Jetzt steht da" per minute". Heißt das ich muss da 30Liter oder so eintragen? Was ich aber sogar hatte. Aber wenn man Nachts kein Wasser entnimmt werden aus 30 Liter ja auch gerne mal 3000Liter. Oder wie ist sonst der Sprung zu erklären.

[jomjol]

Da spricht du ein aktuelles Problem an. Je nach dem Fehlerbild ist eine Rate (pro Zeiteinheit) oder eine absolute Veränderung (einfach Vergleich zum letzten Wert) sinnvoll.

Ich habe keine gute Lösung bisher. Ich könnte es parametrisieren, aber der geneigte Gelegenlichkeitsbenutzer wird die Auswirkung der Unterschiede nicht überblicken.

[blaumsass]

Ich hätte gerne ein Vergleich zum letzten. das war bei version 9.xx besser. Bzw könnte man nicht die Wahl haben? Weil er macht bei mir immer den gleichen Sprung.

Gruß

[b3nn0]

Habe genau das selbe Problem - springt plötzlich von 111.93 auf 112.93 obwohl der MaxRateValue Parameter gesetzt ist. Kann es sein dass dieser gar nicht zieht/buggy ist?
EDIT: hm.. hab den preValue nochmal runter gesetzt, jetzt wird korrekt der "rate too high" error ausgespuckt. Keine Ahnung warum beim ersten Mal nicht.
Leider verliere ich nun so lange die werte, bis ich tatsächlich die 112 erreiche. Denkbar wäre ggf. hier zu ermitteln, welche Stelle für die zu hohe Rate verantwortlich war (hier der Wechsel von 1 auf 2) und diese wie NAN zu behandeln. Dann würde so lange 111.xxx ausgespuckt werden bis wirklich 112 erreicht wird.
EDIT2: Jetzt ist er wieder gesprungen. Irgendwie scheint das MaxRateValue nicht zuverlässig zu funktionieren.

[Frank-Huber]

Ich kann das Fehlverhalten auch bestätigen.
Habe es auch schon mit der 10.2 beobachtet, aber eher auf ein Problem meines Setup getippt. scheint aber wohl doch globaler Natur zu sein.

[friedpa]

Bitte einmal die config.ini von Dir posten. Bitte daran denken: der Wert der in MaxRateValue steht ist der erlaubte "Sprung" pro Minute (dies gilt ab der Version 10.x). D.h. wenn da als Wert z.B. 0,2, steht sind das bei einer Abtsatrate von z.B. 5 Minuten 1m3.

[b3nn0]

Bei mir sieht diese so aus. Das CheckDigitIncreaseConsistency war anfangs auf false - war nur ein Versuch wegen der beobachteten Problematik. Hat aber keinen sichtbaren Unterschied gemacht.

[MakeImage]
;LogImageLocation = /log/source
WaitBeforeTakingPicture = 5
;LogfileRetentionInDays = 15
Brightness = 0
Contrast = 0
Saturation = 0
LEDIntensity = 50
ImageQuality = 12
ImageSize = VGA
FixedExposure = false

[Alignment]
InitialRotate = 232
InitialMirror = false
SearchFieldX = 20
SearchFieldY = 20
AlignmentAlgo = default
FlipImageSize = false
/config/ref0.jpg 153 100
/config/ref1.jpg 348 256

[Digits]
Model = /config/dig-s2-q-20220104.tflite
;LogImageLocation = /log/digit
;LogfileRetentionInDays = 3
ModelInputSize = 20 32
main.dig1 274 91 29 53
main.dig2 308 90 30 54
main.dig3 345 89 31 56
main.dig4 382 87 32 58

[Analog]
Model = /config/ana-s3-q-20220105.tflite
;LogImageLocation = /log/analog
;LogfileRetentionInDays = 3
ModelInputSize = 32 32
main.ana1 394 214 104 104
main.ana2 325 314 104 104

[PostProcessing]
main.DecimalShift = 0
PreValueUse = true
PreValueAgeStartup = 720
AllowNegativeRates = false
main.MaxRateValue = 0.05
main.ExtendedResolution = true
;main.IgnoreLeadingNaN = false
ErrorMessage = true
CheckDigitIncreaseConsistency = true

[MQTT]
Uri = mqtt://hass:1883
MainTopic = wasserzaehler
ClientID = wasser
user = XXXXX
password = XXXX

;[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 
LEDType = WS2812
LEDNumbers = 2
LEDColor = 150 150 150

[AutoTimer]
AutoStart = true
Intervall = 1

[Debug]
Logfile = false
LogfileRetentionInDays = 3

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

[Frank-Huber]

Hier meine Config.ini

Er springt manchmal einfach 1 qm hoch. hab jetzt negative Werte erlaubt, dadurch korrigiert er sich selbst beim nächsten Lauf.

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

[Alignment]
InitialRotate = 0
InitialMirror = false
SearchFieldX = 20
SearchFieldY = 20
AlignmentAlgo = default
FlipImageSize = false
/config/ref0.jpg 243 193
/config/ref1.jpg 461 161

[Digits]
Model = /config/dig0850s1q.tflite
;LogImageLocation = /log/digit
;LogfileRetentionInDays = 3
ModelInputSize = 20 32
default.digit1 357 149 30 55
default.digit2 390 149 31 55
default.digit3 422 149 30 54

[Analog]
Model = /config/ana0700s1lq.tflite
;LogImageLocation = /log/analog
;LogfileRetentionInDays = 3
ModelInputSize = 32 32
default.analog1 455 228 66 66
default.analog2 416 297 66 66
default.analog3 347 326 66 66
default.analog4 262 293 64 64

[PostProcessing]
default.DecimalShift = 0
PreValueUse = true
PreValueAgeStartup = 720
AllowNegativeRates = true
default.MaxRateValue = 0.05
default.ExtendedResolution = false
default.IgnoreLeadingNaN = true
ErrorMessage = true
CheckDigitIncreaseConsistency = true

[MQTT]
Uri = mqtt://192.168.12.151:8084
MainTopic = wasserzaehler/zaehlerstand
ClientID = wasser
user = mqtt
password = none

;[GPIO]
;IO0 = input disabled false false
;IO1 = input disabled false false
;IO3 = input disabled false false
;IO4 = input disabled false false
;IO12 = input disabled false false
;IO13 = input disabled false false
LEDType = WS2812
LEDNumbers = 2
LEDColor = 50 50 50

[AutoTimer]
AutoStart = true
Intervall = 4.85

[Debug]
Logfile = false
LogfileRetentionInDays = 3

[System]
TimeZone = CET-1CEST
;TimeServer = 192.168.12.254
;AutoAdjustSummertime =
;Hostname = watermeter
;SetupMode = false
`

[Frank-Huber]

Und wieder. Siehe Anhang

.

[friedpa]

@b3nn0 Nur am Rand: Dein Intervall steht auf "1" sollte aber wie in der Beschreibung des Projektes festgehalten auf jeden Fall > "3" Minuten sein. Ich weis jetzt nicht genau, wie sich das auswirkt.....
@Frank-Huber wie war den der zeitliche Abstand zwischen den Sprüngen? Nur einmal gedanklich: Beim ersten Durchgang nach einem erfolgreichen Lesen, darf der Wert nur <242,5 Liter (4,85 * 0,05) sein. Wird da nicht richtig gelesen, wird beim nächsten Durchgang schon 2 * 242,5 Liter erlaubt usw. Also beim vierten Durchgang sind dann schon 4 * 4,85 Minuten vergangen und der erlaubte Sprung ist 4 * 242,5 Liter = 970 Liter usw. Als wichtig wäre zu wissen wieviel Minuten zwischen den zwei Werten vergangen ist, wo der dbzgl Sprung stattgefunden hat. Ich muss auch noch dazu sagen, das die 4,85 Minuten nicht immer exakt genommen werden. Es zählt wie schnell der ESP die Auswertung vornehmen kann, d.h. bei Benutzung der WebUI kann das schon einmal länger dauern.

[Frank-Huber]

Wie ich die Config gepostet habe war alles OK, vorhin dann nicht mehr.
Aber wie kommt er auf die 380? das sind doch eindeutige 379.

Ich lasse mir jetzt mal von fhem jede Wert Änderung pushen und erhöhe die erlaubte Steigerung.
dann kann ich da genaueres sagen. denke aber daß das Grund-Problem die falsche Auswertung auf 380 ist.

[friedpa]

Was steht denn genau bei einem solchen Fall in der Prevoius Value (in der WebUI unter Configuration)?

[jomjol]

Um das ganze noch etwas zusammenzufassen. Es gibt zwei Effekte, die hier eine Rolle spielen:

1. CheckDigitIncreasConsistency
   Wenn das auf true steht, wird geprüft, ob aus der ersten Nachkommastelle (0.1x analoger Zähler) auf einen Wechsel der 1m³ Ziffer geschlossen werden kann oder eben noch nicht.
   Beispiel:

• Gelesen 548.9 -> aber eigentlich ist es noch 547.9, da vorher 547.6 da war und jetzt die "8" schon soweit gedreht ist, dass sie erkannt wird.
• Der Algo soll erkennen, dass es keinen Nulldurchgang gab --> x.6 --> x.9 und korrigiert daher die gelesenen 548.9 auf 547.9.

2. MaxRateValue
   Es ist genauso wie @friedpa schreibt: aktuell ist es eine Rate/Minute. Selbst wenn du dort auch nur 0.01 einstellst (10Liter/Minute). sind nach 100 Minuten schon maximal 1m³ möglich und damit wird ein falscher Wert aktzeptiert.

Momentan gibt es keinen Algorythmus, der allen gerecht wird.

Was wären eure Vorschläge, um das Problem allgemein zu lösen?

[blaumsass]

Ganz einfach falls es möglich ist. Lasse dem Nutzer einfach die Wahl ob: pro Minute (wie ab v10.x) oder wie vorher Wert zu Wert (bis v9.2)

[jomjol]

Ja - aber inzwischen gibt es schon so viele Parameter, dass du bald ein "Buch" brauchst, um zu verstehen, was die genau tuen. Ich habe bewußt schon den Expertenmodus eingebaut.

Ca. 80% meiner Zeit mit Mails (>30 Stück/Tag) verbringe ich damit, zu erklären, was die Parameter genau machen und warum sie bei dem ein oder anderen falsch eingestellt sind. Manche machen sich halt nicht die Mühe das WIKI zu lesen :-(

[Frank-Huber]

Ich glaube bei mir kommt das Problem dadurch dass er manchmal das Bild dreht. Dadurch werden Werte falsch erkannt und die digitalincrease schlägt zu. Weil nach x.9 x.1 kommt. x.9 war eine falscherkennung aber das weiß er ja nicht.

Ich weiß nicht mehr welche Version ich vorher drauf hatte, aber da hatte ich das Problem nicht.
Ich hänge mal paar Bilder an. Vielleicht sagt dir das ja was oder du kannst was ableiten.

[blaumsass]

Glaube ich sofort. Mega deine Arbeit aber das hörst du sicher ständig.

[Frank-Huber]

Manche machen sich halt nicht die Mühe das WIKI zu lesen :-(

Bei solchen Emails einfach mal die 4 Buchstaben mit smiley Antworten. "RTFM 😉"

Aber ja, auf jeden Fall Danke für dein Projekt und deine Zeit die du reinsteckst.

[jomjol]

@Frank-Huber Das mit dem verkippten Bild hängt an den Alignmentmarken. Da musst du vielleicht ein paar besser erkennbare finden oder vielleicht auch mit einem Aufkleber auf dem Glas ein paar einfache selbst kreieren.

[Frank-Huber]

Das waren aber vor dem Update die gleichen. Und da lief es lange Zeit stabil. Dass das Bild nicht optimal ist weiß ich.
Langfristig will ich das Rohr kürzen um näher ran zu kommen.

[b3nn0]

Ich habe jetzt nochmal laufen lassen und dabei geloggt.

Config (auszug):

[PostProcessing]
main.DecimalShift = 0
PreValueUse = true
PreValueAgeStartup = 720
AllowNegativeRates = false
main.MaxRateValue = 0.05
main.ExtendedResolution = true
;main.IgnoreLeadingNaN = false
ErrorMessage = true
CheckDigitIncreaseConsistency = true


[AutoTimer]
AutoStart = true
Intervall = 3

Situation (danach):

-> Erwartete Werte zwischen 112.0 und 112.5.

Log (das relevante ist ziemlich am Ende): https://gist.github.com/b3nn0/6e566743ec1d5548bb984290fa23081e

Zusammenfassung:

1. Um 09:06:46 wurde das erste Mal fälschlicherweise 113.xxx statt 112.xxx gelesen. => Error: Rate too high
2. Um 09:18:46 wurde wieder korrekt 112.xxx gelesen -> Wert akzeptiert
3. Danach wieder einige Falschlesungen ab 09:21:45 (113.xxx)
4. Um 09:39:47 wurde die 113.xxx dann endgültig akzeptiert.

Analyse:
zwischen 9:21 und 9:39 sind ~18 Minuten vergangen. 18*0,05 sind ~0,9m³. Die Implementierung liegt also gar nicht so falsch:
da alle Werte dazwischen verworfen wurden, wurde die maxRate irgendwann überschritten, da für längeren Zeitraum nichts "korrektes" kam.
Das erklärt auch, warum das Verhalten erst durch die Parameteränderung von "flow pro reading" zu "flow pro Minute" entstanden ist.

Vorschlag:
Wie wäre es, wenn - im Falle eines maxRate Fehlers - der Wert nicht komplett verworfen wird, sondern stattdessen die "least significant"-Stelle die für das Auslösen des Fehlers (hier also die 2 die zur 3 wurde) als NaN deklariert wird. Diese ist ja ganz offenbar die, die für den Fehler verantwortlich ist. Somit würde nicht das komplette reading verworfen werden, sondern nur die fehlerhafte Stelle.
Es wäre dann gar nie zu einer 18 Minuten Pause gekommen, da die anderen Stellen korrekt gelesen und verwendet werden.

[Gunter1710]

Ich habe das selbe Problem. Hab auch mal das Log mitlaufen lassen. Es fängt eigentlich damit an, dass um 2022-02-07T22:04:05 eine 2 als 1 gelesen wird und dann wird alles nur noch schlimmer.
Eine Reduzierung der MaxRateValue würde beim zweiten Fehler 2022-02-08T06:04:16 nicht wirklich helfen, da der Lesefehler (also ne 1 anstatt ner 2) über eine Sunde anhält.

Vielleicht hat ja jemand eine Idee wie eine Korrektur aussehen könnt?!? Was aber auf jeden Fall nicht passieren darf ist, dass die Kubikmeter um einen erhöht wird obwohl klar eine 6 ausgelesen wird.

2022-02-07T21:54:23: PostProcessing - Raw: 00106.224 Value: 106.224 Error: no error
2022-02-07T21:59:14: PostProcessing - Raw: 00106.224 Value: 106.224 Error: no error
2022-02-07T22:04:05: PostProcessing - Raw: 00106.136 Value: Error: Rate too high - Read: 107.136 - Pre: 106.224
2022-02-07T22:08:56: PostProcessing - Raw: 00106.136 Value: Error: Rate too high - Read: 107.136 - Pre: 106.224
2022-02-07T22:13:47: PostProcessing - Raw: 00106.136 Value: Error: Rate too high - Read: 107.136 - Pre: 106.224
2022-02-07T22:18:38: PostProcessing - Raw: 00106.136 Value: 107.136 Error: no error
2022-02-07T22:23:29: PostProcessing - Raw: 00106.136 Value: 107.136 Error: no error
.
2022-02-08T05:59:25: PostProcessing - Raw: 00106.237 Value: 107.237 Error: no error
2022-02-08T06:04:16: PostProcessing - Raw: 00106.137 Value: Error: Rate too high - Read: 116.137 - Pre: 107.237
.
2022-02-08T07:07:19: PostProcessing - Raw: 00106.137 Value: Error: Rate too high - Read: 116.137 - Pre: 107.237
2022-02-08T07:12:10: PostProcessing - Raw: 00106.144 Value: Error: Rate too high - Read: 116.144 - Pre: 107.237
2022-02-08T07:17:01: PostProcessing - Raw: 00106.247 Value: 107.247 Error: no error

PS: Ich hab auch das komische Problem mit der flaschen Rotation seit 10.3.0

[Frank-Huber]

Ich habe jomjols Tipp umgesetzt und mit Aufklebern neue Alignment Marker gesetzt. (die zwei "41")
läuft jetzt seit ca halb 9 ohne auch nur mit einer Kommastelle zu zucken.

@Gunther1710,
versuche Du auch mal bessere Alignment Marker zu setzen. bei mir hat das das Problem gelöst.

[Gunter1710]

@Frank-Huber ich hab mir jetzt auch neue Marker auf dem Ring gesetzt (ein Punkt aufmalen reicht schon).
Habe nun seit mehreren Stunden kein Error mehr.
Werde das nun beobachten. Hab mir ein Notify gesetzt, so dass ich sofort ne Mail bekomme, wenn wieder ein Fehler auftaucht.

EDIT:
Es haben sich vereinzelt Errors eingeschlichen, aber bis dato keine Sprünge mehr

[schlami]

@jomjol das ist wirklich ein tolles Projekt und auch ich danke dir sehr für deine Mühe und den Einsatz.

Wäre es sinnvoll den Auswertealgorithmus wie folgt zu ändern um die Auswertung um eine automatische Korrektur zu ergänzen?

• Option1:
  jedes Mal, wenn der Wert erhöht wird, schaut sich der Algorithmus z.B. die vorherigen drei Werte an. Wenn der Durchschnitt der drei letzten Werte deutlich geringer ist als der aktuelle Wert, dann bedeutet das, dass der aktuelle Wert zu hoch und damit ungültig ist. In diesem Fall sollte der Algorithmus wieder zum vorletzten gültigen Wert springen.

• Option2:
  wenn der aktuelle Wert einen zu großen Sprung (sei es positiv oder negativ) aufweist, dann schaut der Algorithmus die nächsten drei Ablesungen an um festzustellen, ob sie auch in dem Bereich liegen. Wenn ja, dann wird der letzte Wert als gültig erkannt, wenn nicht dann wird der letzte Wert vor dem großen Sprung als gültig erkannt.

In beiden Fällen könnte der Algorithmus eine fehlerhafte Ablesung automatisch korrigieren, wobei ich Option2 vorziehen würde.

[ThiloAm]

Ich denke eine nachträgliche Korrektur über zu hohe oder niedrige Werte ist nicht der einzige Weg um das Problem zu lösen. Mein Ansatz wäre über eine eindeutige Erkennung der Ziffern. Falsch über MQTT übertragende Werte, die nachträglich korrigiert werden, sind für eine Auswertung fast tödlich.

Überlegung

Eine Ziffer ist nur dann gültig, wenn diese eindeutig erkannt wird. „Eindeutig“ bedeutet die Ziffer liegt innerhalb des inneren Rechteck und füllt dieses aus. Es gibt, innerhalb dieses Rechtecks, oben oder unten keinen Leerraum.
Wird ein Leerraum festgestellt findet ein Ziffernwechsel statt.
Ziffern die im Rechteck liegen und falsch erkannt werden sind nicht richtig angelernt. Diese Ziffern müssen zwingend angelernt werden.

Meinen Überlegungen liegt zu Grunde das die vollständigen Ziffern richtig erkannt werden. Und das der Ablese Intervall so eingestellt ist das keine Ziffern übersprungen werden. Somit ist immer die Aktuelle, Vorherige und Zukünftige Ziffer bekannt. Bei Ausfall des „watermeter“ muss der „Previous Value“ manuell gesetzt werden.

Aus dieser Überlegung ergibt sich das bei einer Ungütigen Ziffer der letzte aktuelle Wert gilt.

Ich hoffe meine Annahmen und Folgerungen ergeben Sinn.

[Duese123]

Hallo ich habe das letzte Rolling vor der 10.04 benutzt und habe auch immer wieder mit Sprüngen zu kämpfen.. Manchmal wird der erste Analoge Zähler falsch erkannt und dann ist natürlich ein zu großer Sprung. Wobei insgesamt auf die kommastellle genau geht nur irgendwie in einer bestimmten Stellung erkennt er gerne mal die 5 als 9. Absurd.

Aber schlimmer ist das er einfach den vorderen Zähler eins erhöht ohne ersichtlichen Grund.

Hier der Log

2022-02-13T09:09:09: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:09:17: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:09:26: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:09:26: PostProcessing - Raw: 0019N.1358 Value: Error: Neg. Rate - Read: 192.1358 - Raw: 0019N.1358 - Pre: 192.1449
2022-02-13T09:09:26: FlowControll.doFlow - ClassFlowMQTT
2022-02-13T09:09:26: task_autodoFlow - round done
2022-02-13T09:09:26: CPU Temperature: 67.2
2022-02-13T09:11:38: task_autodoFlow - next round - Round #370
2022-02-13T09:11:38: FlowControll.doFlow - ClassFlowMakeImage
2022-02-13T09:11:47: FlowControll.doFlow - ClassFlowAlignment
2022-02-13T09:12:09: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:12:16: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:12:26: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:12:26: PostProcessing - Raw: NNNNN.3459 Value: 192.3459 Error: no error
2022-02-13T09:12:26: FlowControll.doFlow - ClassFlowMQTT
2022-02-13T09:12:26: task_autodoFlow - round done
2022-02-13T09:12:26: CPU Temperature: 67.8
2022-02-13T09:14:38: task_autodoFlow - next round - Round #371
2022-02-13T09:14:38: FlowControll.doFlow - ClassFlowMakeImage
2022-02-13T09:14:48: FlowControll.doFlow - ClassFlowAlignment
2022-02-13T09:15:09: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:15:17: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:15:26: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:15:26: PostProcessing - Raw: 0019N.1359 Value: 193.1359 Error: no error
2022-02-13T09:15:26: FlowControll.doFlow - ClassFlowMQTT
2022-02-13T09:15:27: task_autodoFlow - round done
2022-02-13T09:15:27: CPU Temperature: 67.8
2022-02-13T09:17:38: task_autodoFlow - next round - Round #372
2022-02-13T09:17:38: FlowControll.doFlow - ClassFlowMakeImage
2022-02-13T09:17:48: FlowControll.doFlow - ClassFlowAlignment
2022-02-13T09:18:10: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:18:17: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:18:27: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:18:27: PostProcessing - Raw: 0019N.1359 Value: 193.1359 Error: no error
2022-02-13T09:18:27: FlowControll.doFlow - ClassFlowMQTT
2022-02-13T09:18:27: task_autodoFlow - round done
2022-02-13T09:18:27: CPU Temperature: 68.3
2022-02-13T09:20:38: task_autodoFlow - next round - Round #373
2022-02-13T09:20:38: FlowControll.doFlow - ClassFlowMakeImage
2022-02-13T09:20:48: FlowControll.doFlow - ClassFlowAlignment
2022-02-13T09:21:09: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:21:17: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:21:27: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:21:27: PostProcessing - Raw: 0019N.1359 Value: 193.1359 Error: no error
2022-02-13T09:21:27: FlowControll.doFlow - ClassFlowMQTT
2022-02-13T09:21:27: task_autodoFlow - round done
2022-02-13T09:21:27: CPU Temperature: 67.8
2022-02-13T09:23:38: task_autodoFlow - next round - Round #374
2022-02-13T09:23:38: FlowControll.doFlow - ClassFlowMakeImage
2022-02-13T09:23:48: FlowControll.doFlow - ClassFlowAlignment
2022-02-13T09:24:10: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:24:18: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:24:28: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:24:28: PostProcessing - Raw: 0019N.1359 Value: 193.1359 Error: no error
2022-02-13T09:24:28: FlowControll.doFlow - ClassFlowMQTT
2022-02-13T09:24:28: task_autodoFlow - round done
2022-02-13T09:24:28: CPU Temperature: 66.1
2022-02-13T09:26:38: task_autodoFlow - next round - Round #375
2022-02-13T09:26:38: FlowControll.doFlow - ClassFlowMakeImage
2022-02-13T09:26:48: FlowControll.doFlow - ClassFlowAlignment
2022-02-13T09:27:10: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:27:18: FlowControll.doFlow - ClassFlowCNNGeneral
2022-02-13T09:27:27: FlowControll.doFlow - ClassFlowPostProcessing
2022-02-13T09:27:27: PostProcessing - Raw: 0019N.1519 Value: 193.1519 Error: no error
2022-02-13T09:27:27

Ich habe den neuesten Absolute Rate wert gesetzt dieser hat denke ich verhindert, dass der neue Wert geschrieben wurde (auch wenn dies nirgends im Log steht...)

[jomjol]

@Duese123:
Der Algo hat gemacht, was er soll:

1. 192.3459 (9:12) - wobei der Rohwert (NNNNN.3459) ganz stark darauf hindeutet, dass dein Alignment nicht gut funktioniert.
2. 193.1359 (9:15) - der Sprung in der m³ von 192 auf 193 kommt daher, dass deine Nachkomma mit 0.1xxx kleiner ist als der vorherige 0.3xx --> daher geht der Algorithmus von einem Nulldurchgang aus und erhöht die erste Ziffer daher.

Ich würde aber erstmal das Alignment prüfen ein Wert von NNNN.3459 ist sehr ungewöhnlich und deutet darauf hin, dass das Bild total schief o.ä. war. Vermutlich, weil du keine stabil erkennbaren Referenzstrukturen hast.

[jomjol]

@ThiloAm
Danke für deine Überlegungen. Dein Algorithmus setzt aber einige Dinge voraus, die du auf einem ESP32 einfach nicht umsetzen kannst:

1. Erkennung, wo genau die Ziffer im Bild ist. Das bedarf aufwendiger Bildanalyse z.B. mit OpenCV oder ähnlichem und läßt sich auf dem ESP32 nicht umsetzen. Zur Orientierung bzgl. des Flashspeichers: es können aufgrund OTA nur ca. 2MB Firmware erzeugt werden. Aktuell sind noch ca. 10% des Flash für weitere Features frei - das entspricht 200kb.
2. Es müsste ein dynamischen Lernen auf dem ESP32 implementiert werden, auch das ist nicht möglich.

[Duese123]

@jomjol danke für deine Rückmeldung.

Das Aligning sollte eigentlich passen jedoch erkennt er manchmal die analogen Werte sichtlich falsch. Ich habe jetzt mal ein sehr altes File für die analogen Zeiger genommen. Das neueste zeigt mir zwischen 5 und 6 falsche Werte (erkennt dann gerne mal.ne 8 etc)

Hier ein Bild nachdem aligning.

[ThiloAm]

@jomjol Danke für deine Anmerkungen. Das der ESP32 limitiert ist ist mir bewusst. Dennoch möchte ich meine Überlegung einmal genauer beschreiben. Eventuell ist etwas dabei was genutzt werden kann.

Plausiprüfung:
Zu einem definierten Zeitpunkt wird ein gültiger/sicheren Zählerstand benötigt! Entweder durch manuelle Erfassung oder durch auslesen und erkennen der digitalen Ziffern und der Ziffernblätter.

Plausiprüfung Wasserzähler:

1. Zählerstand besteht aus 5 digitalen gültigen Ziffern und 4 Nachkommastellen (analogen Ziffer auf den Zifferblättern)

2. Der neue Zählerstand ist immer gleich oder größer. (kleiner ist nicht möglich)

3. Die maximal Dauerdurchfluss Menge (Q3) ergibt sich aus dem Wasserzähler. Auf dem Wasserzähler ist die Bezeichnung Q3 zu finden.
   Q3 4 -> Dauerdurchfluss von maximal 4m³/h
   Daraus lässt sich die maximal Durchflussmenge pro Zeiteinheit(Ableseintervall) errechnen.
   Bei einem Ableseintervall von 5 Minuten ergibt sich ~333,34 Liter
   In diesen Fall darf der neue Zählerstand maximal 333,34 Liter größer sein und die letzte digitale Ziffer darf sich nur um 1 erhöht haben(Achtung Rundung!).

4. Anders sieht es bei den analogen Werten aus: Die erste analoge Stelle kann sich nur um 3 erhöht haben. (1000 / 333,34 = 3). Hierbei muss das Runden über die 9 hinaus beachtet werden. Weitere Werte lassen sich nicht errechnen da ab der nächsten analogen Ziffer ein mehrmaliges runden möglich ist.

Mit dieser Logik sollte die Genauigkeit bei nicht eindeutigen erkennen der Ziffern auf 99 Liter eingegrenzt werden.

Fehler erkennen:
Zu 1. Eine Ziffer ist nicht gültig(N). Somit wird die letzte gültige Ziffer genommen.
Zu 2. Zählerstand ist kleiner. Letzter Zählerstand wird genommen
Zu 3. Der neue Zählerstand hat sich um mehr als die maximale Durchflussmenge erhöht. Letzter Zählerstand wird genommen.

Folgende Informationen müssen gespeichert werden:
Zählerstand (und Datum/Uhrzeit)
Ableseintervall
Alle aktuelle digitale Ziffern (neu)
Erste Stelle der analogen Werte (neu)

Anmerkungen sind willkommen!

[jomjol]

@ThiloAm : danke für deine Überlegungen - genauso ist es implementiert + noch ein paar Plausibilitätschecks. Z.B. ob ein Nulldurchgang stattgefunden hat oder nicht.

Gesteuert wird das über die Parameter:

1. PreValueUse = true --> letzer gültiger Wert
2. AllowNegativeRates = false kleinere Raten werden nicht aktzeptiert
3. main.MaxRateValue = 0.5 limitiert die maximale Veränderungsrate
4. MaxRateType = AbsoluteChange hier kannst du sogar noch entscheiden, ob eine absolute Veränderung oder eine Rate (m³/Minute) berücksichtigit werden soll
5. CheckDigitIncreaseConsistency = true --> Erweiterte Konistenzprüfung (Nulldurchgang etc.)

Ich schließe den Issue mal, denn für Außenstehende dürfte er aufgrund seiner Länge nicht mehr hilfreich sein. Wir können ihn aber zum Ideenaustausch weiter nutzen.

[lanwin]

Was mir aufgefallen ist, ist das bei mir der Analog 0.x öfters mal erst nach dem Digitalen umspringt. Das heißt 00100.9 wird dann 00101.9 und dann beim nächsten read erst 00101.0 was dann natürlich zu nem Error führt, da der Wert plötzlich wieder kleiner ist.

Passt das zu eurem Problem?

[jomjol]

Ich habe mal angefangen, den Korrekturalgorithmus zu beschreiben. Ist noch nicht vollständig und im Code eventuell auch noch verbesserungswürdig. Aber das könnte helfen, das Verhalten besser zu verstehen oder Fehler zu finden:

https://github.com/jomjol/AI-on-the-edge-device/wiki/Correction-Algorithm

[ThiloAm]

@jomjol Ich habe angefangen deine Anmerkungen zum Algorithmus anzuschauen.

Unter Terms and definitions schreibst du zum PreValue, dass dieser der Letzte Korrekte Wert ist. Weiter oben schreibst du aber, dass dieser auch falsch sein kann. Das kann aus meiner Sicht nicht sein. Entweder wurde der Wert manuell durch den User gesetzt oder der Algorithmus liefert diesen. Korrekt muss dieser sein. Also User oder Algorithmus muss einen gültigen wert setzten und dies ist auch möglich. Eine Annahme das der PreValue falsch sein kann ist überflüssig(mit Einschreckungen, siehe unten).

Mir werden die technischen Eigenschaften des Wasserzählers nicht genügend berücksichtigt. Der Wasserzähler mit der Spezifikation Q3 4 hat eine Dauerdurchflussmenge von 4000 Liter die Stunde. Dies kann in Relation zum Intervall gesetzt werden. Daraus ergibt sich die maximal Durchflussmenge.
Maximale Durchflussmenge pro Intervall. 4m³ / 60 * Intervall (4m³/60 * 5 = 0,33333334m³) Also etwa 334 Liter pro 5 Minuten
Mit dieser MaimalDurchflussmenge kann die Plausibilität des erkannten Wertes bewerten werden.

1. Maximaler neuer Wert
2. (WICHTIG) Für die Werte der einzelnen Ziffern ergibt sich:
   a. Der Wert 334 passt in die Hundert Liter Anzeige das ist der erste Analoge Wert. In diesen pass der Wert DREI mal. Das heißt der alte Wert kann sich hier nur um maximal 3 erhöht haben. Zu berücksichtigen ist der Sprung über die 9.
   b. Die Nachfolgenden Kommastellen(Ziffern) lassen sich NICHT ermitteln!
   c. Wird bei a. Eine Rundung erkannt erhöht sich auch die Stelle davor um1. Dies kann wider mit dem Ergebnis verglichen werden.

Jedes Mal wenn die Plausibilität nicht wahr ist wird für die einzelne Ziffer der Vorherige Wert gesetzt.

[jomjol]

@ThiloAm Ich kann den Widerspruch gerade nicht finden. Was genau meinst du mit "weiter oben".
Anmerkung: der PreValue kann natürlich trotzdem falsch werden, denn nicht alle Fehler sind detektierbar. Dann hilft nur ein manueller Eingriff.

Die technischen Details der Zähler werde ich nicht weiter berücksichtigen. Die Firmware wird für alle möglichen Zähler verwendet (Gas, Strom, beliebige LCD Display). Ich kann für diese kostenlose Software nicht leisten, dass alles mit aufzunehmen, zumal die meisten User damit dann auch nichts anfangen können.

Kann verstehen, dass du damit deinen Zähler noch sicherer auslesen - würde empfehlen, dafür eine eigene Version anzulegen und die auf dein System zu optimieren.

[lanwin]

Neg. Rate - Read: 659.9936 - Raw: 00749.9936 - Pre: 748.9496
Ich hab gerade das. Der Raw scheint korrekt. Aber wie kommt er auf den Read?

[jomjol]

Fehler gefunden --> v10.5.0

[friedpa]

@jomjol Kann es sein, dass der Fehler noch immer auftritt? Ich habe das selbe Verhalten nun auf beiden Systemen wieder.
z.B.: Read: 269.10882 (Note.: eine Nachkommastelle mehr) Raw: 269.0992 (Note: richtiger Wert) Ergebnis: Rate to high und zwar mit Vergleichswert: 270.0992! Woher kommen die 270?

[lanwin]

Bei mir scheinen die Werte derzeit korrekt zu kommen. Allerdings steht bei "Previous Value" permanent "PreValue too old"

[jomjol]

@friedpa : bei mir ist er nicht aufgetreten, kann aber sein, ist aber noch nicht so viel Wasser durchgelaufen. Kannst du mir mal dein Logfile mit den entsprechenden Runs schicken, dann rechne ich es von Hand nach. Dabei hatte ich auch den letzten Fehler gefunden (verwendung von round(), statt floor()).

[friedpa]

Ich Depp hab das File mit den rauskopierten Zeitpunkten gelöscht, werde also bis zum nächsten Auftreten warten müssen.....

[ThiloAm]

@jomjol Habe das Problem jetzt mit der neusten Version 10.5.0 das die Werte nicht mehr passen. Als Anlage die Logs der letzten drei Tage.

log_2022-02-21.txt
log_2022-02-19.txt
log_2022-02-20.txt

Nachtrag sehe gerade git eine neue Version 10.5.1. Installiere diese erst mal.

Nicht off genug gesagt, Tolle Arbeit!

[jomjol]

@ThiloAm : hast du auf v10.5.1 upgedated? Da wurde ein Bug behoben.

[ThiloAm]

@jomjol Ja ich habe die Version 10.5.1 installiert. Es gibt aber leider keine Besserung.
Der ermittelte Wert ist immer zu Hoch. die digitalen Zahlen sind im Raw immer richtig. der ermittelte Wert aber falsch. So wie auf dem Bild.

festgestellt habe ich das ich noch ein Problem mit den analogen Zahlen habe. Diese werden nicht immer richtig erkannt. Dadurch kommt es das der ermittelte Wert zu hoch oder zu nidrieg ist. Die analogen Zahlen müssen noch durch dich anglernt werden. der Zeiger ist etwas speziell(siehe Bild). Was benötigts du dafür?

[jomjol]

Also das Problem ist aufgetreten um:

2022-02-20T21:43:57: sent publish successful in MQTTPublish, msg_id=16420, wasserzaehler/main/json, {"value":455.5487,"raw":"00455.5487","error":"no error","rate":"","timestamp":"2022-02-20T21:43:07"}
2022-02-20T21:48:57: sent publish successful in MQTTPublish, msg_id=38213, wasserzaehler/main/error, Rate too high - Read: 1455.4498 - Pre: 566.5487

Aus mir erstmal (noch) nicht ersichtlichen Gründen wurde dort der PreValue auf 566.5487 gesetzt.
Seitdem mach die letzte Stelle einen Nulldurchgang auf der 100er Stelle (455 vs. 566) und daher meint er das auch die 1000er Stelle hochgezählt werden müsste.
Eigentliches Problem ist tatslich der Sprung im PreValue auf 566.5487.

[ThiloAm]

Version 10.5.2 installiert. Das Problem bleibt bestehen.

log_2022-02-24.txt

[jomjol]

Ursache kann aus dem Logfile nicht erkannt werden, da es schon im ersten Umlauf zu sehen ist (und dort auch verständlich):

2022-02-24T00:06:17:   sent publish successful in MQTTPublish, msg_id=64458,   wasserzaehler/main/json,   {"value":"","raw":"00456.5754","error":"Neg.   Rate - Read:  - Raw: 00456.5754 - Pre:   557.5794   ","rate":"","timestamp":"2022-02-23T23:54:08"}

PreValue ist 557.5794 --> warum da schon eine 7 steht muss du im vorherigen Log nachschauen.
Da aber auf dem Nachkomma kein Nulldurchgang stattfindet: (0.5 --> 0.5) setzt der Algo den die gelesene 6 auf die 7.

Der Algo ist hier erklärt: https://github.com/jomjol/AI-on-the-edge-device/wiki/Correction-Algorithm

[ThiloAm]

@jomjol Immer noch keine Besserung.
Ich habe das Logfile etwas genauer unter die Lupe genommen und folgende gefunden.

2022-02-25T20:55:48: sent publish successful in MQTTPublish, msg_id=63146, wasserzaehler/main/json, {"value":458.1153,"raw":"00457.1153","error":"no error","rate":0.064207,"timestamp":"2022-02-25T20:54:57"}

An dieser Stelle ist (erstmalig) der value wert deutlich zu hoch.
In dem Logfile habe ich die Tage 25/26.2 zusammen kopiert. Das Log startet Nachmittag. Zu diesem Zeitpunkt hatte ich den Prevalue manuell gesetzt und das System neu gestartet. In den Zipfiles sind die Image der Uhr. Vielleicht hilft dies um den Fehler zu finden.
Kannst du dir die Analogen Zahlen einmal anschauen. Habe ich hier ein Problem?

WasserUhr.log
26-2-2022_ 23-22-21.zip
26-2-2022_23-20-21.zip

[jomjol]

@ThiloAm : völlig klar, was da passiert. Schau dir bitte mal den letzten gültigen Eindruck ebenfalls an:

2022-02-25T20:41:48: sent publish successful in MQTTPublish, msg_id=39108, wasserzaehler/main/json, {"value":457.2164,"raw":"00457.2164","error":"no error","rate":0.001430,"timestamp":"2022-02-25T20:40:57"}
2022-02-25T20:45:18: sent publish successful in MQTTPublish, msg_id=64180, wasserzaehler/main/json, {"value":"","raw":"00457.2153","error":"Neg. Rate - Read:  - Raw: 00457.2153 - Pre: 457.2164 ","rate":"","timestamp":"2022-02-25T20:40:57"}
2022-02-25T20:48:48: sent publish successful in MQTTPublish, msg_id=40799, wasserzaehler/main/json, {"value":"","raw":"00457.2154","error":"Neg. Rate - Read:  - Raw: 00457.2154 - Pre: 457.2164 ","rate":"","timestamp":"2022-02-25T20:40:57"}
2022-02-25T20:52:18: sent publish successful in MQTTPublish, msg_id=21802, wasserzaehler/main/json, {"value":"","raw":"00457.2153","error":"Neg. Rate - Read:  - Raw: 00457.2153 - Pre: 457.2164 ","rate":"","timestamp":"2022-02-25T20:40:57"}
2022-02-25T20:55:48: sent publish successful in MQTTPublish, msg_id=63146, wasserzaehler/main/json, {"value":458.1153,"raw":"00457.1153","error":"no error","rate":0.064207,"timestamp":"2022-02-25T20:54:57"}

Letzer gültiger Wert: 2022-02-25T20:41:48: 457.2164
Dann: 2022-02-25T20:55:48 457.1153 --> aufgrund Nulldurchgang: 458.1153

Und damit der große Sprung. Da die maximale Rate offensichtlich kleiner wie dein MaxRate sein müsste, wird der Wert aktzeptiert.

Die Details für den Ablauf findest du hier nochmal: https://github.com/jomjol/AI-on-the-edge-device/wiki/Correction-Algorithm - RTFM :-)

So einen Fehler kann immer mal vorkommen. Das bekommst du nur über den MaxRate Value in den Griff. Du könntest in statt auf eine Rate (m³/minute) auf eine absolute Veränderung stellen und dann z.B. 0.5 als Grenzwert einstellen, dann wird so ein Fehler erkannt und der neue Wert kommt erst, wenn die Nachkommastelle wieder stimmt.

[ThiloAm]

@jomjol Leider verstehe ich es noch nicht genau. Kannst du mir etwas auf die Sprünge helfen.
Was meinst du genau mit "Und damit der große Sprung. Da die maximale Rate offensichtlich kleiner wie dein MaxRate sein müsste, wird der Wert aktzeptiert."

Meine Einstellungen sind MaxRateValue = 0,334 und MaxRateTape = RateChange.

Auch hat um 2022-02-25T20:55:48 kein Nulldurchlauf stattgefunden.

Ich habe jetzt erstmal auf AbsoluteChange umgestellt.

[jomjol]

RateChange bedeutet, dass du die Rate in m³/Minute angibst. Zwischen dem letzten guten Wert (20:41) und dem Sprung (20:55) sind 14 Minuten vergangen 14minuten * 0,334 m³/minut = 4,7m³ sind maximal zulässig. Der Sprung ist aber nur ca. 1m³ also zulässig.
Wenn du den Wert von RateChange auf AbsoluteChange änderst, dann wären tatsächlich nur 0,334m³ zulässig, egal wieviel Zeit vergangen wäre.

Bezüglich "Nulldurchang": natürlich hat in der Realität kein Nulldurchgang stattgefunden. Aber da die erste Nachkommastelle kleiner ist, wie die beim letzten Mal, glaubt der Algo, dass ein Nulldurchgang stattgefunden hat.

[ThiloAm]

Nachtrag:
Generrel sehe ich in dem Log das bei mir die Analogen Ziffern nicht immer richtig erkannt werden. Das erkenne ich an den Neg.Rate.
Darüber hinaus sehe ich Sprünge die ich nicht erklären kann.
Z.B. Ab Round 69.
Runde 69 Value Ok. 457.2164
Runde 70 Raw ist kleiner 457.2153
Runde 71 Raw ist kleiner 457.2154
Runde 72 Raw ist kleiner 457.2153
und dann gibt es einen Sprung
Runde 73 Value 458.2161 wird als "no error" erkannt.
Das ist aber definitiv falsch.

Zu deiner Antwort: Deine Antwort erklärt für mich jetzt warum zu große mengen akzepiert werden. Dies passe ich jetzt nochmal an.
Aber: Warum wird die RateChange auf eine Minute heruntergerechnet. Der Teiler ist das Intervall! Aus meiner Sicht muss geschaut werden welche Menge im Intervall durch den Zähler gegangen ist.

[friedpa]

@ThiloAm Du kannst am Wasserzhäler die maximale Durchflussmenge pro Minute ablesen; Q3 4 bedeutet in 1h => 4m3 Wasser, daraus kann man den Minutenwert errechnen.

[ThiloAm]

@friedpa Danke für den Hinweis. Siehe meine Anmerkungen dazu #643 (comment)
Hier hatte ich schon einmal darauf hingewiesen das darüber(maximale Durchflussmenge) eine weitere Prüfung auf Plausibilität eingebaut werden kann. In Anhängigkeit mit dem Intervall kann ermittelt werden welche einzelne Zahlen sich ändern können. Sprünge über die maximale Durchflussmenge pro Intervall sind zu verwerfen. @jomjol #643 (comment). Bestimmte Nulldurchgänge könnten damit auch ausgeschlossen werden.
Bei mir kommt es vor das der als mit "no error" erkannte wert um 100m³ höher liegt als der preValue und das bei einem Durchgang. Damit sind alle folgenden Messungen Wertlos.
Eine Einfache Prüfung ist preValue + mailmaleDruchflussmenge pro Intervall. Ist der errechnete neue Wert (value) größer ist dieser zu verwerfen.