NEWS
Wasserzähler - Version 2 - all-in-device
Wasserzähler - Version 2 - all-in-device
-
Hallo @jomjol
nach einer längeren Pause habe ich meinen Wasserzähler reaktiviert. Die wesentliche Änderung ist eine ordentliche Spannungsversorgung: Hatte ich den ESP vorher über eine ca. 12m lange Leitung aus den 5V meines Raspberry Pi versorgt, ist es jetzt ein separates 1A-USB-Netzteil direkt am ESP -- und schon läuft's stabil
. Kein Wunder, zieht der ESP doch gerne mal Impulse bis zu 500 mA (mit dem Labornetzteil gesehen).Nun habe ich gerade frisch die Version 9.1.0 geflasht (hatte von letzter Woche noch 9.0.0), weil ich im Changelog gesehen habe, dass Du einen Fehler im decimal shift korrigiert hast. Ich meine aber, da ist immer noch was faul: Ich habe decimal shift = -3, weil die ersten drei Nachkommastellen der m³ noch digital vorliegen. Nur die 4. ist bei meinem Modell analog:
Obwohl Raw Value perfekt erkannt wird mit 4 Nachkommastellen, ist Value auf 1 Nachkommastelle gerundet. Wie bekomme ich die höhere Auflösung?
(Aktiviere ich Extended Resolution, gibt's im Raw Value eine 5. Stelle und beim Value eine zweite...) -
Hallo @jomjol
nach einer längeren Pause habe ich meinen Wasserzähler reaktiviert. Die wesentliche Änderung ist eine ordentliche Spannungsversorgung: Hatte ich den ESP vorher über eine ca. 12m lange Leitung aus den 5V meines Raspberry Pi versorgt, ist es jetzt ein separates 1A-USB-Netzteil direkt am ESP -- und schon läuft's stabil
. Kein Wunder, zieht der ESP doch gerne mal Impulse bis zu 500 mA (mit dem Labornetzteil gesehen).Nun habe ich gerade frisch die Version 9.1.0 geflasht (hatte von letzter Woche noch 9.0.0), weil ich im Changelog gesehen habe, dass Du einen Fehler im decimal shift korrigiert hast. Ich meine aber, da ist immer noch was faul: Ich habe decimal shift = -3, weil die ersten drei Nachkommastellen der m³ noch digital vorliegen. Nur die 4. ist bei meinem Modell analog:
Obwohl Raw Value perfekt erkannt wird mit 4 Nachkommastellen, ist Value auf 1 Nachkommastelle gerundet. Wie bekomme ich die höhere Auflösung?
(Aktiviere ich Extended Resolution, gibt's im Raw Value eine 5. Stelle und beim Value eine zweite...)@rupert-s Das ist komisch, da genau dieser Fehler eigentlich in der 9.1.0 beseitigt sein sollte. Ich kann es leider selbst nicht testen. Aber im Issue (https://github.com/jomjol/AI-on-the-edge-device/issues/385) gab es die RM, dass das Problem gelöst ist. Änderung im Code ist auch enthalten.
-
@jomjol sagte in Wasserzähler - Version 2 - all-in-device:
Was verstehst du unter "Überlaufproblem"?
wie man im Bild sieht, wandert die letzte Stelle aus dem Sichtbereich (im o.g. Beispiel die 3). Diese Ziffer wird dann nicht mehr erkannt. Als Wert wird dann ein N (51N.93159) übergeben.
Der letzte richtig erkannte Wert war 513,8898. Ich könnte mir also eine Lösung vorstellen, einfach die 513 weiter zu verwenden und nur die Nachkommastellen zu aktualisieren (solange das plausible ist)... -
@jomjol sagte in Wasserzähler - Version 2 - all-in-device:
Was verstehst du unter "Überlaufproblem"?
wie man im Bild sieht, wandert die letzte Stelle aus dem Sichtbereich (im o.g. Beispiel die 3). Diese Ziffer wird dann nicht mehr erkannt. Als Wert wird dann ein N (51N.93159) übergeben.
Der letzte richtig erkannte Wert war 513,8898. Ich könnte mir also eine Lösung vorstellen, einfach die 513 weiter zu verwenden und nur die Nachkommastellen zu aktualisieren (solange das plausible ist)...@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
ch könnte mir also eine Lösung vorstellen, einfach die 513 weiter zu verwenden und nur die Nachkommastellen zu aktualisieren (solange das plausible ist)...
und woher weisst die KI, dass es nicht schon der Wechsel von 5 auf 6 ist?
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
ch könnte mir also eine Lösung vorstellen, einfach die 513 weiter zu verwenden und nur die Nachkommastellen zu aktualisieren (solange das plausible ist)...
und woher weisst die KI, dass es nicht schon der Wechsel von 5 auf 6 ist?
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
-
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
ch könnte mir also eine Lösung vorstellen, einfach die 513 weiter zu verwenden und nur die Nachkommastellen zu aktualisieren (solange das plausible ist)...
und woher weisst die KI, dass es nicht schon der Wechsel von 5 auf 6 ist?
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
-
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
ch könnte mir also eine Lösung vorstellen, einfach die 513 weiter zu verwenden und nur die Nachkommastellen zu aktualisieren (solange das plausible ist)...
und woher weisst die KI, dass es nicht schon der Wechsel von 5 auf 6 ist?
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
-
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
@rene_hm ich hab es schon nach dem ersten mal verstanden
Aber du setzt Wissen voraus, das die KI nicht hat.
Die KI sieht außerdem nur alle 5 Minuten eine Momentaufnahme, kann also gar nicht wissen wie viele Nulldurchläufe in der Zwischenzeit existierten -
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
Hallo zusammen,
die Software hat genau den von euch beschriebenen Algorithmus:- wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt.
- wenn der Parameter "CheckDigitIncreaseConsisstency" aktiviert ist, dann findet auch genau dies Konsistenzprüfung statt, ob die Stellen vorher schon einen Nulldurchgang hatten. Wie @rene_hm richtig bemerkt hat, funktioniert das nur zuverlässig, wenn zwischen zwei Messungen nicht mehrere Nulldurchläufe stattgefunden haben. Daher ist die Funktion nur bei hybriden Zählern (analog + digital) sinnvoll, da man dann genau davon ausgehen kann.
-
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
Hallo zusammen,
die Software hat genau den von euch beschriebenen Algorithmus:- wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt.
- wenn der Parameter "CheckDigitIncreaseConsisstency" aktiviert ist, dann findet auch genau dies Konsistenzprüfung statt, ob die Stellen vorher schon einen Nulldurchgang hatten. Wie @rene_hm richtig bemerkt hat, funktioniert das nur zuverlässig, wenn zwischen zwei Messungen nicht mehrere Nulldurchläufe stattgefunden haben. Daher ist die Funktion nur bei hybriden Zählern (analog + digital) sinnvoll, da man dann genau davon ausgehen kann.
@jomjol Dann ist da aber noch was nicht optimal...
Mein Beispiel.. ich habe vor kurzem einen neuen Zähler bekommen, der hat also bei 0 angefangen zu zählen..
Leider ist noch eine relativ große Luftblase drin, die wandert, so dass die Erkennung noch nicht opimal ist..
Wir haben also aktll 26.xxx Der Konsistenzcheck ist eingeschaltet und korrigier die Fehlerkennungen "meistens"
Aber scheinbar wir der Prevalue immer wieder mal vergessen...
Ich bin jetzt aus dem Urlaub zurückgekomen und er hat nicht mehr nur 26.xxx auf der Uhr gehabt sondern angeblich 04026.xxx also 4000 qm mehr als vorher...
Der Prevalue war dabei leer... Ich habe ihn neu gesetzt und jetzt ignoriert er die erkannte 4 an der 2 Stelle von links wieder..
Diesen Fehler hatte ich in den letzten Wochen schon einige male...
-
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
Hallo zusammen,
die Software hat genau den von euch beschriebenen Algorithmus:- wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt.
- wenn der Parameter "CheckDigitIncreaseConsisstency" aktiviert ist, dann findet auch genau dies Konsistenzprüfung statt, ob die Stellen vorher schon einen Nulldurchgang hatten. Wie @rene_hm richtig bemerkt hat, funktioniert das nur zuverlässig, wenn zwischen zwei Messungen nicht mehrere Nulldurchläufe stattgefunden haben. Daher ist die Funktion nur bei hybriden Zählern (analog + digital) sinnvoll, da man dann genau davon ausgehen kann.
@jomjol sagte in Wasserzähler - Version 2 - all-in-device:
CheckDigitIncreaseConsisstency
ich habe den CheckDigitIncreaseConsisstency jetzt mal eingeschaltet. Mal schauen, was passiert.
wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt
sollte das auch ohne o.g. check passieren?
-
@ecki945 Dann ist vermutlich irgendetwas beim SD-Kartezugriff schief gegangen. Vielleicht hilft einfach ein kompletter Restart. Im Zweifelsfall nochmals die SD-Karte formatieren und bespielen.
@jomjol Habe nun eine 2te SD Karte genommen. gleiche Fehlermeldung. Augenscheinlich kann der ESP32 nicht auf die Karte schreiben. Verstehe ich nicht ganz. Habe den Inhalt des SD-Karte Vereichniss der heruntergeladenen Version 9.11 auf die SD Karte kopiert und nach Spannungsversorgung kommt ja auch der Assistent. Schreibschutz gibt es ja keinen.
Vielleicht könnte jemand anders das mal mit einer neuen SD-Karte probieren und ggf Rückmeldung geben.
-
@rupert-s Das ist komisch, da genau dieser Fehler eigentlich in der 9.1.0 beseitigt sein sollte. Ich kann es leider selbst nicht testen. Aber im Issue (https://github.com/jomjol/AI-on-the-edge-device/issues/385) gab es die RM, dass das Problem gelöst ist. Änderung im Code ist auch enthalten.
@jomjol said in Wasserzähler - Version 2 - all-in-device:
in der 9.1.0 beseitigt
Ok, ich sehe die Veränderung im Code für NUMBERS[j]->Nachkomma.
Hab' grad das Update auf 9.1.1 gemacht, jetzt funktioniert's: PreValue wird mit ausreichend Nachkommastellen abgespeichert. Danke schön! -
@rene_hm sagte in Wasserzähler - Version 2 - all-in-device:
@homoran weil im o.g. Beispiel nach der 513 die 514 kommt und solange die Nachkommstellen größer werden und den Nulldurchlauf noch nicht gesehen haben, könnte man das annehmen. Klar, das gilt nur dann, wenn der Wasserverbrauch in der gegebenen Abtastrate keinen weiteren oder mehrere Nulldurchläufe verursachen, was m.E. aber eher unwahrscheinlich ist (zumindest in meiner Anwendung)
Hallo zusammen,
die Software hat genau den von euch beschriebenen Algorithmus:- wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt.
- wenn der Parameter "CheckDigitIncreaseConsisstency" aktiviert ist, dann findet auch genau dies Konsistenzprüfung statt, ob die Stellen vorher schon einen Nulldurchgang hatten. Wie @rene_hm richtig bemerkt hat, funktioniert das nur zuverlässig, wenn zwischen zwei Messungen nicht mehrere Nulldurchläufe stattgefunden haben. Daher ist die Funktion nur bei hybriden Zählern (analog + digital) sinnvoll, da man dann genau davon ausgehen kann.
@jomjol said in Wasserzähler - Version 2 - all-in-device:
Hallo zusammen,
die Software hat genau den von euch beschriebenen Algorithmus:wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt.
Ich habe ja einen ähnlichen Zähler wie @rene_hm: Die einzelnen Liter sind die letzte Digitalstelle, der eine analoge Zeiger dreht 1x pro Liter. Bei mir schiebt sich die letzte Digitalstelle (also der Liter) kontinuierlich vor.
Von x.0 bis ca. x.2 wird "x" korrekt erkannt.
Von x.3 bis x.7 wird x nicht erkannt und durch "N" ersetzt bzw. aus PreValue abgeleitet.
Von x.7 bis x.99999 wird x falsch, nämlich schon eins zu hoch erkannt, weil der Vorschub schon so weit ist.Dieses Phänomen liegt in der Bauweise des Zählers und kann in der Bild- bzw. Ziffernerkennung erst mal nicht gelöst werden. Ich habe nur ca. 50% Chance, die letzte Digitalstelle zu erkennen. Der Algorithmus mit Betrachtung, was war vorher und was kann alles nicht sein (Rückwärtslauf usw.), muss es heilen.
Hier ist es möglicherweise aber etwas kurz gesprungen, sich nur den letzten Wert zu merken (PreValue) unabhängig davon, ob er eindeutig erkannt, oder wg. eines oder mehrerer "N" abgeleitet wurde. Beispiel:
401.09N1 kann mehrmals hintereinander so erkannt werden, auch wenn ich zwischen zwei Fotos ein exaktes Vielfaches von 1 ltr gezapft habe. Natürlich -- und das ist viel wahrscheinlicher -- kann es auch Stillstand gewesen sein. (Dass die letzte Stelle, hier 1, wenn sie sehr nahe an 2 liegt, trotz Stillstands mal als 1 und dann als 2 und wieder als 1 erkannt werden kann -- also Rücklauf, oder doch 0,9ltr Zuwachs?? -- ist ein eigenes Problem.)
Wenn dann irgendwann 401.10xx erkannt wird, habe ich vielleicht den MaxRateValue überschritten und damit das nächste Problem.
Daher mein Gedanke: Der Algorithmus sollte sich nicht nur den letzten "irgendwie" ermittelten Wert merken, sondern (auch?) den letzten klar (ohne "N") erkannten oder vom Benutzer eingegebenen Zählerstand, inkl. Zeitstempel. Der sollte zum Gegencheck des aktuellen Werts mit MaxRateValue und AllowNegativRates verwendet werden -- denn meine letzte "Ableitung" kann ja auch mal deutlich falsch gewesen sein, dann sollte sie durch einen sehr zuverlässig erkannten Zählerstand korrigiert werden können.Nebenbei: Gibt es bei der Erkennung der einzelnen Ziffer eigentlich so was wie einen "Verlässlichkeitslevel", also eine Art Selbsteinschätzung, mit welcher Wahrscheinlichkeit die Bilderkennung korrekt ist?
-Rupert
PS: Mir ist klar, ich entwerfe hier tolle Ideen zur Verbesserung, ohne selbst auch nur annähernd in der Lage zu sein, so einen Algorithmus zu realisieren.
-
@jomjol said in Wasserzähler - Version 2 - all-in-device:
Hallo zusammen,
die Software hat genau den von euch beschriebenen Algorithmus:wenn ein "N" erkannt wird, dann wird es mit dem letzten Wert (aus Previous Value) ersetzt.
Ich habe ja einen ähnlichen Zähler wie @rene_hm: Die einzelnen Liter sind die letzte Digitalstelle, der eine analoge Zeiger dreht 1x pro Liter. Bei mir schiebt sich die letzte Digitalstelle (also der Liter) kontinuierlich vor.
Von x.0 bis ca. x.2 wird "x" korrekt erkannt.
Von x.3 bis x.7 wird x nicht erkannt und durch "N" ersetzt bzw. aus PreValue abgeleitet.
Von x.7 bis x.99999 wird x falsch, nämlich schon eins zu hoch erkannt, weil der Vorschub schon so weit ist.Dieses Phänomen liegt in der Bauweise des Zählers und kann in der Bild- bzw. Ziffernerkennung erst mal nicht gelöst werden. Ich habe nur ca. 50% Chance, die letzte Digitalstelle zu erkennen. Der Algorithmus mit Betrachtung, was war vorher und was kann alles nicht sein (Rückwärtslauf usw.), muss es heilen.
Hier ist es möglicherweise aber etwas kurz gesprungen, sich nur den letzten Wert zu merken (PreValue) unabhängig davon, ob er eindeutig erkannt, oder wg. eines oder mehrerer "N" abgeleitet wurde. Beispiel:
401.09N1 kann mehrmals hintereinander so erkannt werden, auch wenn ich zwischen zwei Fotos ein exaktes Vielfaches von 1 ltr gezapft habe. Natürlich -- und das ist viel wahrscheinlicher -- kann es auch Stillstand gewesen sein. (Dass die letzte Stelle, hier 1, wenn sie sehr nahe an 2 liegt, trotz Stillstands mal als 1 und dann als 2 und wieder als 1 erkannt werden kann -- also Rücklauf, oder doch 0,9ltr Zuwachs?? -- ist ein eigenes Problem.)
Wenn dann irgendwann 401.10xx erkannt wird, habe ich vielleicht den MaxRateValue überschritten und damit das nächste Problem.
Daher mein Gedanke: Der Algorithmus sollte sich nicht nur den letzten "irgendwie" ermittelten Wert merken, sondern (auch?) den letzten klar (ohne "N") erkannten oder vom Benutzer eingegebenen Zählerstand, inkl. Zeitstempel. Der sollte zum Gegencheck des aktuellen Werts mit MaxRateValue und AllowNegativRates verwendet werden -- denn meine letzte "Ableitung" kann ja auch mal deutlich falsch gewesen sein, dann sollte sie durch einen sehr zuverlässig erkannten Zählerstand korrigiert werden können.Nebenbei: Gibt es bei der Erkennung der einzelnen Ziffer eigentlich so was wie einen "Verlässlichkeitslevel", also eine Art Selbsteinschätzung, mit welcher Wahrscheinlichkeit die Bilderkennung korrekt ist?
-Rupert
PS: Mir ist klar, ich entwerfe hier tolle Ideen zur Verbesserung, ohne selbst auch nur annähernd in der Lage zu sein, so einen Algorithmus zu realisieren.@rupert-s Hi Rupert,
die Idee mit dem letzten "klar erkannten Wert" ist nicht schlecht, aber die Frage, ob die Zahl auch richtig erkannt wurde, oder falsch löse ich darüber nicht. Das könnte man natürlich über einen "Verlässlichkeitswert" berücksichtigten. Das neuronale Netz liefert mit der Wahrscheinlichkeit auch einen Wert dafür. Das wird aber aktuell im Algorithmus nicht berücksichtigt. Dafür fehlt mir schlicht die Zeit, dass auszuarbeiten und vor allem zu implementieren und zu testen.
Gruß jomjol -
Ich hab an meinem Stromzähler den Effekt das die "6" nicht oder nur sehr schlecht erkannt wird. Könnte das mit der Darstellung / Schreibweise dieser Ziffer zusammenhängen? Anbei mal ein Bild. Beeinflusst das die Erkennung? Wird im RAW Value als "0" erkannt.
-
Ich hab an meinem Stromzähler den Effekt das die "6" nicht oder nur sehr schlecht erkannt wird. Könnte das mit der Darstellung / Schreibweise dieser Ziffer zusammenhängen? Anbei mal ein Bild. Beeinflusst das die Erkennung? Wird im RAW Value als "0" erkannt.
@spaceduck Danke für den Hinweis. Zwei Punkte:
- genau so eine "6" habe ich in der Tat nich in den Trainingsdaten
- mit deinem Hinweis habe ich gesehen, dass eine "6" versehentlich als "0" deklariert wurde --> könnte die Ursache sein
Ich werde das mit dem nächsten Training korrigieren.
-
@spaceduck Danke für den Hinweis. Zwei Punkte:
- genau so eine "6" habe ich in der Tat nich in den Trainingsdaten
- mit deinem Hinweis habe ich gesehen, dass eine "6" versehentlich als "0" deklariert wurde --> könnte die Ursache sein
Ich werde das mit dem nächsten Training korrigieren.
Support us
538
Online32.4k
Users81.3k
Topics1.3m
Posts