Zahlenüberlauf

[LineF]

Hallo jomjol,

tolles Projekt, das Du da auf die Beine gestellt hast! Musste ich gleich nachbauen und funktioniert auch soweit prima!

Nun hat meine Wasseruhr den Wechsel auf den nächsten Kubikmeter vollzogen, allerdings ist die Ziffer noch nicht vollständig zu sehen, so daß sie als NaN erkannt wird und durch den bisherigen Wert ersetzt wird. Die Zeiger sind aber bereits von der 9999 wieder zur 0000 weitergelaufen, so daß der Gesamtwert nun zu niedrig ist und der aktuelle Wert damit nicht ausgegeben wird. Siehe auch Bild anbei.

Muß ich noch was berücksichtigen in der Konfiguration, oder fehlt da noch etwas Logik im Programm?

BTW: die Software macht noch mehrmals pro Tag Restarts (bei geöffneter Web-Seite) - aber ich glaube, das weißt Du schon... Noch eine Frage: Ließe sich das Projekt auch für einen Stromzähler verwenden?

Vielen Dank nochmals für die tolle Software und Projekt! Martin

[LineF]

[simonscheib]

Hi Martin,

hatte ich vor ein paar Wochen schon als Feature Request eingetütet und jomjol hat mit meinen Beispielbildern der Zahlen vom Gas sowie Stromzähler das CNN weiter trainiert und bisher läuft die erkennung für Wasser/Gas/Strom seit einer Woche Problemlos. Siehe https://github.com/jomjol/AI-on-the-edge-device/issues/37

[LineF]

Sehr schön! Dann werde ich das auch mal noch in Angriff nehmen. Ich befürchte allerdings, daß der Platz zwischen Zähler und Schaltschranktür zu knapp wird (wie auch auf Deinem Bild zu sehen). Aber da muss ich mal noch mit der Kameralinse probieren...

Danke! Martin

[simonscheib]

Meine Tür musste auch weichen ;). Tipp für Strom/Gas Zähler: Da die Zahlenwalzen - weil schwarz glänzend - extrem reflektieren ist eine gute Beleuchtung ohen Reflexion das A und O. Mit dem LED Flash hatte ich teilweise massive Reflexionen in den Walzen und bin auf einen 5V USB LED Stripe gewechselt um das etwas indirekter zu beleuchten.

[jomjol]

Hallo Martin, hast du die neuste Version (Build jünger wie 2020-11-03 22:12) und in der Config.ini folgenden Paramter auf true?

[PostProcessing]
...
CheckDigitIncreaseConsistency = True
...

Letzerer sollte eigentlich solche Inkonsistenzen prüfen und beseitigen. Kann natürlich sein, dass die Implementierung auch nicht einen Fehler enthält.

Gruß, jomjol

[LineF]

Ich habe noch die Version von 03.11. im Einsatz und hatte den Parameter auf False stehen. Ein Ändern des Parameters auf True hat zunächst mal nichts gebracht - vielleicht auch, weil der Zahlenüberlauf bereits stattgefunden hat (beim Parameterwert "False"). Ich werde heute mal die Version vom 08.11. versuchen.

Viele Grüße, Martin

[LineF]

[LineF]

Die neue Version vom 08.11 mit aktiviertem Parameter korrigiert den Wert auch nicht - vielleicht liegt's ja wirklich daran, daß der Parameter erst nach dem Zählerüberlauf aktiviert wurde...

Gruss, Martin

[LineF]

Was ich auch noch festgestellt habe: In MQTT werden (unkorrigierte?) Zahlenwerte mit "N" gesendet:

Viele Grüße, Martin

[jomjol]

Hallo Martin, ist genau dasselbe Thema. Solange er das "N" noch nicht verarbeiten konnte (noch kein vollständiger Wert gelesen, bzw. Korrekturmechanismus nicht erfolgreich) überträgt er auch das "N" mit. Hier ist es ja direkt nach dem Reboot und offensichtlich ist dein PreValue noch nicht richtig konfiguriert, sonst hätte er da "N" korrigiert. Poste mal deine Config.ini und die prevalue.ini aus dem config Verzeichnis. Dann schaue ich mir die mal an.

[LineF]

Die prevalue.ini sieht derzeit so aus: 2020-11-08_18-17-31 535.283997

und die config.ini so: [MakeImage] ;LogImageLocation = /log/source WaitBeforeTakingPicture=3 ImageQuality = 5 ImageSize = VGA

[Alignment] InitialRotate = 180 /config/ref0.jpg 100, 179 /config/ref1.jpg 449, 84 SearchFieldX = 15 SearchFieldY = 15

[Digits] Model=/config/dig0650s3.tflite ;LogImageLocation = /log/digit ModelInputSize 20, 32 digit1, 200, 70, 30, 55 digit2, 247, 72, 33, 59 digit3, 295, 70, 30, 55 digit4, 345, 71, 31, 56 digit5, 392, 71, 30, 55

[Analog] Model=/config/ana0630s2.tflite ;LogImageLocation = /log/analog ModelInputSize 32, 32 analog1, 423, 233, 107, 107 analog2, 357, 310, 105, 105 analog3, 260, 334, 103, 103 analog4, 143, 274, 105, 105

[PostProcessing] DecimalShift = 0 PreValueUse = True PreValueAgeStartup = 30 AllowNegativeRates = False MaxRateValue = 0.1 ErrorMessage = True CheckDigitIncreaseConsistency = True

[MQTT] Uri = mqtt://x.x.x.x:1883 Topic = watermeter/readout ClientID = wasser ;user = USERNAME ;password = PASSWORD

[AutoTimer] AutoStart= True Intervall = 4.85

[Debug] Logfile = True

[Ende]

Den Prevalue hatte ich ganz zu Beginn mal gesetzt (auf 534.6 in etwa) und dann nicht mehr angerührt...

Allerdings erkennt die SW derzeit den "5"er an Position 5 nicht - ich vermute, daß die Zacken am rechten Rand stören. Ich habe das Fenster jetzt mal entsprechend verkleinert - mal abwarten...

[LineF]

tatsächlich - mit dem verkleinerten Fenster ohne die Zacken erkennt er jetzt den 5er

[LineF]

Im Moment ist jetzt alles normal - mal den nächsten cbm abwarten - bis der 6er halb da hängt...

[jomjol]

Sieht erstmal sehr vernünftig aus. Ich würde nur den Wert PreValueAgeStartup deutlich höher setzen - so ca. auf einen halben Tag oder so. Denn wenn der ESP rebooted und es ist länger als 30 Minuten her, dass er einen vollständigen Wert wirklich gelesen hat (z.B. steht zwischen 2 Ziffern, ist gerade Nacht und länger kein Wasser gelaufen), dann benutzt er den PreValue nicht mehr. Daher der höhere Wert.

[LineF]

Hallo jomjol, das Problem, daß beim Überlauf der Zeiger von 9999 auf 0000 weiterhin der alte Dezimalwert benutzt wird, besteht weiterhin - auch mit der Version vom 03.11. :

[LineF]

[LineF]

Hallo jomjol, ...und die neue Version vom 13.11. verhält sich gleich und crasht immer noch sehr häufig... Es reicht, 2-3 Mal auf den Overview-Button zu klicken (quasi Refresh des Startbildes) und schon meldet sich der Webserver nicht mehr. Viele Grüße, Martin

[jomjol]

Hallo Martin, schade zu hören. Bei mir gab es von selbst immer wieder einen Reboot - Ursache war ein Speicherleck von 340 Byte in jedem Run. Das ist jetzt weg und ich habe jetzt fast 20 Stunden keinen Reboot. Allerding greife ich auch kaum auf die Oberfläche zu. Gruß, jomjol

[LineF]

Zu dem noch nicht funktionierenden Zählerüberlauf: Ich habe jetzt den PreValueAgeStartup von 1/2 auf 2 Tage erhöht. Mal den nächsten Überlauf abwarten...

[stan23]

Tipp für Strom/Gas Zähler: Da die Zahlenwalzen - weil schwarz glänzend - extrem reflektieren ist eine gute Beleuchtung ohen Reflexion das A und O. Mit dem LED Flash hatte ich teilweise massive Reflexionen in den Walzen und bin auf einen 5V USB LED Stripe gewechselt um das etwas indirekter zu beleuchten.

Leuchtet dein LED-Streifen dauerhaft? Und geht die LED am ESP zusätzlich an, oder hast du das abgeschaltet?

[jomjol]

Ich verwende den LED-Streifen nicht mehr, sondern nur die interne Flash-Light. Die Flash-LED (und früher auch die LEDs) schalte ich immer ca. 5 Sekunden vor der Bildaufnahme ein, damit die Kamera den automatisch die Belichtungsparameter einstellt.

[stan23]

Danke, dass die Kamera das in den 5 Sekunden adaptiert wusste ich nicht. Die 5 Sekunden habe ich durch deine Standardeinstellung auch, aber trotzdem die Reflexion. Beim Wasserzähler geht es, beim Gaszähler blendet es zu sehr.

[simonscheib]

@stan23 Hab bei mir lange rum probiert. Man kann die Reflexionen mit verschieben des ESP's auf der Vertikalen Achse zum Zählwerk etwas mildern bzw. was auch geholfen hat, den esp leicht schräg von oben/unten drauf schauen zu lassen.

Dauerhaft hab ich mir für Strom/Gaszähler ein Gehäuse gedruckt, an dessen Innenwänden ringsum der LED Streifen klebt um möglichst indeirekt zu beleuchten und Reflexionen eher im äußeren Bildausschnitt zu haben. Für die LED hab ich im Gehäuse kein Loch ausgespart, somit fürs Bildaufnehmen inaktiv.

[eki1503]

Ich habe jetzt auch wieder das beschriebene Verhalten. Meine Version ist von 2020-11-15 12:51. Bild ist angehängt.

[LineF]

Hallo jomjol, der Commit 1cba7d3e vom 19.11. bringt leider auch keine Verbesserung.

[jomjol]

Hallo zusammen,

das ist mir momentan echt ein Rätsel. Ich hatte heute auch einen Nulldurchang und bei mir lief es reibungslos (lasst euch von dem Kommentar nicht irritieren, der ist von meinem Parser und nur ein Zeichen, dass alles ohne Modifikation war:

2020-11-20_11-10-01 38.9700 - - M3 direkt umgewandelt (keine N) 2020-11-20_11-20-02 38.9700 - - M3 direkt umgewandelt (keine N) 2020-11-20_11-30-02 38.9700 - - M3 direkt umgewandelt (keine N) 2020-11-20_11-40-02 38.9780 - - M3 direkt umgewandelt (keine N) 2020-11-20_11-50-02 38.9829 - - M3 direkt umgewandelt (keine N) 2020-11-20_12-00-02 38.9907 - - M3 direkt umgewandelt (keine N) 2020-11-20_12-10-02 38.9932 - - M3 direkt umgewandelt (keine N) 2020-11-20_12-20-01 38.9949 - - M3 direkt umgewandelt (keine N) 2020-11-20_12-30-02 38.9951 - - M3 direkt umgewandelt (keine N) 2020-11-20_12-40-02 38.9955 - - M3 direkt umgewandelt (keine N) 2020-11-20_12-50-02 38.9955 - - M3 direkt umgewandelt (keine N) 2020-11-20_13-00-02 38.9955 - - M3 direkt umgewandelt (keine N) 2020-11-20_13-10-02 38.9955 - - M3 direkt umgewandelt (keine N) 2020-11-20_13-20-02 38.9955 - - M3 direkt umgewandelt (keine N) 2020-11-20_13-30-02 39.0020 - - M3 direkt umgewandelt (keine N) 2020-11-20_13-40-01 39.0060 - - M3 direkt umgewandelt (keine N) 2020-11-20_13-50-02 39.0087 - - M3 direkt umgewandelt (keine N) 2020-11-20_14-00-02 39.0087 - - M3 direkt umgewandelt (keine N) 2020-11-20_14-10-02 39.0088 - - M3 direkt umgewandelt (keine N) 2020-11-20_14-20-02 39.0088 - - M3 direkt umgewandelt (keine N) 2020-11-20_14-30-01 39.0088 - - M3 direkt umgewandelt (keine N) 2020-11-20_14-40-02 39.0088 - - M3 direkt umgewandelt (keine N) 2020-11-20_14-50-02 39.0088 - - M3 direkt umgewandelt (keine N) 2020-11-20_15-00-02 39.0088 - - M3 direkt umgewandelt (keine N) 2020-11-20_15-10-02 39.0098 - - M3 direkt umgewandelt (keine N)

Bei einen Nulldurchgang von Anfang November hatte ich auch das von euch berichtete Verhalten:

2020-11-05_12-30-01 34.9977 - - M3 direkt umgewandelt (keine N) 2020-11-05_12-40-01 34.9977 - - M3 direkt umgewandelt (keine N) 2020-11-05_12-50-02 34.9991 - - M3 direkt umgewandelt (keine N) 2020-11-05_13-00-02 34.9991 - - M3 direkt umgewandelt (keine N) 2020-11-05_13-10-03 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_13-20-02 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_13-30-01 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_13-40-02 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_13-50-02 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_14-00-02 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_14-10-02 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_14-20-02 34.9991 Negative Rate - Returned old value - read value: 34.0034 - - M3 direkt umgewandelt (keine N) 2020-11-05_14-30-02 34.9991 Negative Rate - Returned old value - read value: 34.0072 - - M3 direkt umgewandelt (keine N) 2020-11-05_14-40-02 34.9991 Negative Rate - Returned old value - read value: 34.0072 - - M3 direkt umgewandelt (keine N) 2020-11-05_14-50-02 34.9991 Negative Rate - Returned old value - read value: 34.0072 - - M3 direkt umgewandelt (keine N) 2020-11-05_15-00-02 34.9991 Negative Rate - Returned old value - read value: 34.0089 - - M3 direkt umgewandelt (keine N) 2020-11-05_15-10-03 03N.0102 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0102 DeltaNachKomma: -0.9889 2020-11-05_15-20-02 03N.0102 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0102 DeltaNachKomma: 2.4563684419832E-15 2020-11-05_15-30-02 03N.0102 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0102 DeltaNachKomma: 2.4563684419832E-15 2020-11-05_15-40-01 03N.0137 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0137 DeltaNachKomma: 0.0035000000000025 2020-11-05_15-50-01 03N.0137 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0137 DeltaNachKomma: -4.5102810375397E-17 2020-11-05_16-00-01 03N.0137 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0137 DeltaNachKomma: -4.5102810375397E-17 2020-11-05_16-10-03 03N.0139 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0139 DeltaNachKomma: 0.00019999999999995 2020-11-05_16-20-02 03N.0165 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0165 DeltaNachKomma: 0.0026000000000004 2020-11-05_16-30-03 03N.0169 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0169 DeltaNachKomma: 0.00039999999999937 2020-11-05_16-40-02 03N.0235 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0235 DeltaNachKomma: 0.0066000000000003 2020-11-05_16-50-02 03N.0235 - - M3 aus Nachkomma - Wert OCR nach Komma: 0.0235 DeltaNachKomma: 1.4779844015322E-15 2020-11-05_17-00-02 35.0293 - - M3 direkt umgewandelt (keine N) 2020-11-05_17-10-02 35.0293 - - M3 direkt umgewandelt (keine N) 2020-11-05_17-20-03 35.0293 - - M3 direkt umgewandelt (keine N) 2020-11-05_17-30-02 35.0293 - - M3 direkt umgewandelt (keine N) 2020-11-05_17-40-03 35.0360 - - M3 direkt umgewandelt (keine N) 2020-11-05_17-50-01 35.0360 - - M3 direkt umgewandelt (keine N) 2020-11-05_18-00-02 35.0360 - - M3 direkt umgewandelt (keine N) 2020-11-05_18-10-01 35.0360 - - M3 direkt umgewandelt (keine N) 2020-11-05_18-20-02 35.0361 - - M3 direkt umgewandelt (keine N)

Habe auch nochmal den Code gescreent und mir ist erstmal nichts noch weiteres aufgefallen.

Bin ratlos - Gruß, jomjol

[LineF]

Hallo jomjol,

wenn der Sprung von z.B. 536.9xxx auf 537.0xxx nicht funktioniert, dann konnte ich zumindest mit dem Setzen eines neuen Pre-Values von 537.0000 wieder auf korrektes Verhalten kommen. Genauso konnte ich zum Testen bei einem Zählerstand von z.B. 537.1234 (und Erkennung von 53N.1234) und Setzen des PreValues auf 536.9999 den Fehlerzustand wiederherstellen - es wird dann als letzter gültiger Wert 536.9999 geliefert, da ein "korrigierter Wert" von 536.1234 "negativ" ist und damit verworfen wird.

Kann ich beim Compilieren ein Debugging einschalten - am besten Logging in eine Datei?

BTW: Die aktuellen Werte im Postprocessing lauten: [PostProcessing] DecimalShift = 0 PreValueUse = True PreValueAgeStartup = 10080 AllowNegativeRates = False MaxRateValue = 0.6 ErrorMessage = True CheckDigitIncreaseConsistency = True

Viele Grüße, Martin

[eki1503]

Der einzige Unterschied, der mir auffällt, ist, dass bei mir im Zusammenhang mit dem Nulldurchgang auch vorher schon immer ein N an der letzten Stelle ist (ist ja bei der Art Zähler sozusagen systembedingt). Wenn ich Deine Logs richtig lese, dann ist das bei Dir nicht der Fall (keine N).

[jomjol]

An der Stelle gibt es kein weiteres Debugging sind auch nicht so viele Zeilen Code. Wenn du Muse hast, kannst du dir die ja mal anschauen - vielleicht findest du den Knoten in meinem Hirn. Leider aber vielleicht nicht ganz einfach nachvollziehbar. Du findest die Verarbeitung in der Funktion bool ClassFlowPostProcessing::doFlow(string zwtime) ab Zeile 256: https://github.com/jomjol/AI-on-the-edge-device/blob/rolling/code/components/jomjol_flowcontroll/ClassFlowPostProcessing.cpp

Ich muss auf den nächsten Nulldurchgang warten - passiert heute aber nicht mehr. Wenn bei dir die letzte Zimmer immer ein N ist, dann funktioniert der Algo natürlicht nicht richtig.

[eki1503]

Ich schau’s mir mal an. Ich habe natürlich nicht immer N‘s aber eben vor und nach dem Nulldurchgang ;)

[eki1503]

Ich habe mir den Code jetzt mal angeschaut, und aus meiner Sicht ist der von uns hier beschriebene Fall noch nicht berücksichtigt. Hier mal ein Beispiel, was, soweit ich es verstehe, aktuell passiert:

PreValue = 354.995 Raw value = 35N.001 zunächst werden die Ns korrigiert: PreValue = 354.995 New value = 354.001 (Wert der letzten digitalen Stelle aus PreValue) In der Methode checkDigitConsistency wird nichts geändert, weil alle digitalen Stellen identisch sind (Zeile 451 "if (aktdigit != olddigit)"). Danach kommt die Rundung und die Prüfung auf negativen Unterschied, die schlägt zu, die Fehlermeldung wird erzeugt und der Wert auf den PreValue gesetzt.

Es müsste eine Prüfung geben, die nach dem Ersetzen der Ns schaut, ob bei den Nachkommastellen ein großer Unterschied zwischen PreValue und neuem Wert ist (den minimalen Unterschied für die Korrektur könnte man ja auch als Parameter in die Konfig packen). Wenn der Unterschied entsprechend groß ist, geht man von einem Nulldurchgang aus, und erhöht den korrigierten Ganzzahlteil um 1. In meinem Beispiel würde das dann so aussehen: PreValue = 354.995 Raw value = 35N.001 zunächst werden die Ns korrigiert: PreValue = 354.995 New value = 354.001 (Wert der letzten digitalen Stelle aus PreValue) Der neue Check würde feststellen, dass der Unterschied zwischen New Value und PreValue ist negativ aber der Unterschied bei den Nachkommastellen ist größer als z.B. 0.8 und damit wird die Ganzzhal des neuen Wertes um 1 erhöht: New Value = 355.001

[jomjol]

Hi Eki, ich denke, dass ist des Pudelskern. Einen solchen Fehlerfall habe ich nicht durchdacht, da bisher immer zuerst das N verschwunden ist und erst dann der Nulldurchgang stattfindet. Ich muss mir mal überlegen, wie ich das Abfange, komme aber vermutlich erst am Wochenende dazu. Danke für deine Hartnäckigkeit!

Gruß, jomjol

[stener2009]

Ich muss auch mal was zum Überlauf schreiben. Aber erst mal vielen Dank an dich Jomjol eine wirklich gute Arbeit.

Bei meinem Zähler erfolgt der Überlauf erst nach so ca 400 Litern. das heißt: z.b. nach 273,9xxx kommt bei mir 273,1xxx und dann bekomme ich halt den negativ rate und der Zahlerstand wird verworfen Der Überlauf ist dann erst bei über bei 274,4xx vollzogen.

Ich würde den Überlauf wie folgt behandel.

bei einem Zählerstand von etwa xxx,9xxx einen Flag setzen "vor Überlauf" bei einem Zählerstand von xxx,1xx und dem Flag "vor Überlauf" die Digitalen um eins erhöhen xx(x+1), und nur die Nachkommastellen übernehmen wenn der reale digitalen Zählerstand mit dem errechneten übereinstimmt dann flag löschen und alles wie beim alten

Zur Info mein System

CheckDigitIncreaseConsistency = True master - v4.0.0 - 2020-11-15 Build 2020-11-19 18:57

[jomjol]

Dein Vorschlag funktioniert so ähnlich bis +/-300 Liter. Damit fällst du gerade so raus. Idee dahinter ist, dass ich nicht bis auf +/-500 gehen kann, weil dann eigentlich immer die Korrektur anspricht und die Ziffern nie wirklich gezählt werden würden. Es gab mal eine Implementierung, wo die Ziffern eigentlich immer errechnet wurden, aber dann hast du das Problem, dass sich ein Fehler nie von selbst korrigiert. Eine optimale Lösung habe ich da auch noch nicht.

[jomjol]

@eki1503 Ich habe jetzt den Algorithmus erweitert, um Nulldurchgang im Nachkomma, aber Ziffer selbst noch auf Vorgängerziffer --> dann wird jetzt die Ziffer um +1 erhöht. Bitte mal testen (Rolling mit heutigem Datum). Danke und Gruß, jomjol

[eki1503]

Ich habe jetzt mal ein Update mit der neuen Version gemacht, werde berichten (kann aber etwas dauern bis der nächste Nulldurchgang kommt)

[LineF]

Ich habe jetzt auch mal die neue FW hochgeladen (die vorcompilierte). Bei mir brauchts aber auch einige Tage bis zum nächsten Nulldurchgang...

[stener2009]

Habe die neue Firmware installiert... hatte aber gerade einen Überlauf, es dauert noch was bis zum nächsten, werde berichten.

Danke

[eki1503]

Bei mir war jetzt ein Nulldurchgang und das hat mit der neuen Version perfekt geklappt.

Danke @jomjol!!

[jomjol]

Thema gelöst!

[LineF]

Ich hatte jetzt auch einen Nulldurchgang und die Zählung lief bestens weiter. Damit auch bei mir gelöst. Vielen Dank auch nochmal an alle Beteiligten!

[SilentBob83]

Hallo das ist ja ein echt tolles Porjekt.... Ist es auch möglich das kleine Zahnrädchen der Wasseruhr zu überwachen ? um eine Leckage zu erkennen ? viele Grüße Andreas

[friedpa]

Genügt DIr da nicht die Literanzeige? Die löst auch auf Zehntel auf!

[SilentBob83]

Ich möchte eine tropfende Leckage finden. Da bewegt sich fast nichts. Die Frage ist ob man das erkennen kann ? wenn das kleinste Mengenrädchen sich in einer Minute nur 1-2 mm bewegt. An dem mini Rädchen stehen leider keine Zahlen dran die man erkennen könnte …

Und mit der 0,1l Anzeige weiß man halt nicht ob gerade jmd. ein glas Wasser gezogen hat.

Mein Vater arbeitet gerade an einer Lösung bei der er 2cm³ / min finden kann. Ziemlich aufwendig und Oldschool. Da ist die Kamera eine ziemlich coole Lösung.

Hintergrund ist dass man nicht erst etliche Liter Wasser in der Wand haben möchte bevor man es erkennt.

Übrigens geben die Hersteller und Installateure keine Garantie auf diese exorbitant teuren Gerätschaften.

Viele Grüße

Andrea

Gesendet von Mail für Windows

Von: Paul Fried Gesendet: Donnerstag, 23. September 2021 13:10 An: jomjol/AI-on-the-edge-device Cc: SilentBob83; Comment Betreff: Re: [jomjol/AI-on-the-edge-device] Zahlenüberlauf(#40)

Genügt DIr da nicht die Literanzeige? Die löst auch auf Zehntel auf! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[eki1503]

Grundsätzlich löst das Ganze immer soweit auf, wie Du definierst (also bei mir sind das 4 analoge "Rädchen" und das kleinste löst auf 1/10 Liter auf). Nur das kleinste Rädchen zu überwachen macht keinen Sinn, da Du von der Größenordnung nur ca. alle paar Minuten (< 2 macht nach meiner Erfahrung keinen Sinn) ein Bild machen kannst und auch bei kleinem Leck das Rädchen sich dann ja möglicherweise mehrmals gedreht hat. Wenn Du den absoluten Wert überwachst, bekommst Du alle paar Minuten einen absoluten Messwert (in meinem Fall auf 0.1 Liter genau). Daraus könnte man dann, allerdings nur wenn in der Zeit keine anderen Verbräuche stattgefunden haben, ermitteln, dass das Ganze z. B. nie ganz auf Null geht.

[friedpa]

Ich verwende genau diesen Mechanismus und steuere damit ein Magnetventil bei Leckerkennung an. Die angeführten 2 min sind sehr sportlich, ein ESP braucht laut meinen Messungen immer über drei Minuten und was dazu kommt, das kleine Rädchen hat auch keinen Indikator, aber das Hauptgegenargument ist, dass der ESP für jeden Durchlauf circa 3 Minuten braucht. In 3 Minuten fließt eh schon viel Wasser bei einem Leck ....

[SilentBob83]

Nicht wenn es nur ganz wenig tropft.

Ich glaub des Rätsels Lösung ist die Camera + Drucksensor.

Druckabfall + Menge > X Liter -> Rohrbruch (X = z.B. 200l – Badewanne) Druckabfall + Menge < X Liter alles i.O. Normaler Verbrauch

Mini leck: Kein Druckabfall und Menge ändert sich ….

Oder ?

Gesendet von Mail für Windows

Von: Paul Fried Gesendet: Donnerstag, 23. September 2021 15:56 An: jomjol/AI-on-the-edge-device Cc: SilentBob83; Comment Betreff: Re: [jomjol/AI-on-the-edge-device] Zahlenüberlauf(#40)

Ich verwende genau diesen Mechanismus und steuere damit ein Magnetventil bei Leckerkennung an. Die angeführten 2 min sind sehr sportlich, ein ESP braucht laut meinen Messungen immer über drei Minuten und was dazu kommt, das kleine Rädchen hat auch keinen Indikator, aber das Hauptgegenargument ist, dass der ESP für jeden Durchlauf circa 3 Minuten braucht. In 3 Minuten fließt eh schon viel Wasser bei einem Leck .... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.