Letzte digitale Ziffer springt zu weit trotz korrekt erkannter Zahlen #590
Comments
|
Nachtrag: Letzter Stand war ja die korrekte Erkennung im vorherigen post oben, jetzt steht er wieder bei 698,11xx m³. Auffällig hier, das wieder die erste Nachkommastelle um 0,1 zu niedrig erkannt wird, und dies nun den Sprung um einen Kubikmeter nach oben bewirkt. Zunächst 697,2008 m³
LOG:
|
|
Noch ein Nachtrag: |
|
Danke für die Details und sorry, dass du den vorherigen Issue nicht öffnen kannst. Ich denke, da kommen zwei Sachen zusammen:
|
|
Danke für die Info. Das ist vermutlich auch bei mir der Grund gewesen. Bei mir funktioniert die Erkennen mit der Version master - v10.1.0 - 2022-01-09 und den beiden Dateien dig-s2-q-20220104.tflite und ana-s3-q-20220105.tflite jetzt so gut, dass der Wert nicht mehr springt. @Cumulus7 du könntest vielleicht verschiedene tflite Dateien über den File Server hochladen und ausprobieren. |
Das Problem hier ist ja hier ja gar nicht einmal eine falsch erkannt letzte digitale VORkommastelle:
Ich hätte den Algorithmus für den Übergang von Digital auf Analog jetzt so gemacht:
Aktuell denke ich machst Du nur (2). D.h. auch wenn der digitale Wert noch eindeutig erkannt wird, setzt Du den Zähler hoch. Was passiert, wenn die erste Nachkommastelle einmal von 0,4 auf 0,3 zurück springt bei der Erkennung? Oder von 0,90 auf 0,89? [Alternativ wäre ggf. zu prüfen, ob die erste Nachkommastelle vor dem Erkennen eines Nulldurchgangs wenigsten einmal > 0,5 gewesen sein muss. Das würde aber z.B. einen digitalen Sprung nicht verhindern der von einem Rücksprung von z.B. 0,70 auf 0,69 ausgelöst wird. Das wäre ja wieder ein Nulldurchgang.] Übersehe ich hier was? Edit:
Edit2: |
Die von dir angegebenen Dateien verwende ich schon.... Erkennung ist auch echt gut, nur bei der ersten Nachkommastelle im Bereich 0 bis 0,2 gibt es wohl Probleme.... Und die sorgen dann für den digitalen Zählersprung, obwohl da eigentlich noch die Zahl perfekt erkannt wird. |
|
Off-Topic Info für jomjol: die Version 10.2 ist MEGA-Stabil. Seit gestern 10:44 kein Reboot! |
|
@Cumulus7 : welche Hardware genau verwendest du? Insbesondere Kamera und Beleuchtung würde mich interessieren. Mit v10.2 gibt es genau zwei Fraktionen:
Bei mir laufen aktuell 3 Devices in Option 1 und ein ESP32 quasi gar nicht mehr. Der einzige Unterschied ist die LED-Beleuchtung und die Stromversorgung. Leider fehlt mir diese Woche die Zeit dem nachzugehen, aber ich bin für jeden Hinweis dankbar. |
|
@jomjol Guten Abend :o) bei mir laufen meine zwei ESPs nicht. Wie können wir eine Liste von funktionierenter und nicht funktionierenter HW anlegen? Wie kann man die Key Infos über das Board auslesen? Vielleicht sollten wir das Problem methodisch eingrenzen, da es ja offensichtlich kein SW Problem ist... LG Paul Note: ich meinte lauft nicht ab 10.0, mit 9.2 laufen beide ESPs so wie vorher (2-5 Reboots pro Tag) |
|
Ich bin auch von dem Problem mit den 1m³ Sprüngen betroffen. Mit früheren Version 7.x.x hatte ich dieses Problem nicht. Ich denke, dass die Änderung von MaxRateValue auf eine zeitbasierte Einheit Vorteile hat, dennoch sollte diese nicht beliebig weit in die Zukunft gelten um solche großen Sprünge herauszufiltern. Ansonsten bringt dieser Konfigurationswert nicht viel, oder? |
|
Die MaxRateValue ist nun auf Liter pro Minute bezogen, daher Achtung, wenn z,B. 5 Minuten zwischen zwei Messungen eingestellt wurde bedeutet das 200 Liter mal 5 Minuten = 1000 Liter ist also 1 m3, also MaxRateValue wie von @jomjol beschrieben anpassen! |
|
Hi, könnten wir die Diskussion um die nicht laufenden ESPs eventuell in einem anderen Thread weiterführen? Und hier bei dem 1-Kubikmeter Problem bleiben? Heute morgen wieder passiert: |
|
Das Anpassen des MaxRateValue reicht ja nicht aus, um das Problem zu lösen. Siehe Post #590 (comment) Ich hatte heute einen Sprung von 383,9987 auf 384,9987. Leider hatte ich kein Log aktiviert. Habe ich nun nachgeholt. |
|
Bezüglich der Sprünge: Ursache ist klar und verstanden und benötigt zwei Dinge:
Dagegen gibt es nur zwei Möglichkeiten
Es gibt KEINE andere Möglichkeit, also diese beiden, da der Algorythmus keine Chance hat, zwischen einer falschen Ziffer und einem tatsächlichen Nulldurchgang zu unterscheiden. Aktuell habe ich kein besseres neuronales Netz. Ihr könntet natürlich Trainingsbilder erzeugen. Da ich eigentlich aber nur vollständige Sätze trainiere, ist der Aufwand relativ groß. Die einzige Möglichkeit, dies zu blocken ist dann der zweite Check über |
|
Hi jomjol, was wäre denn damit, den Nulldurchgang zum Hochzählen erst zu erlauben, wenn sowohl die nächste Zahl erkannt wird als auch ein Nulldurchgang registriert wurde? Ich habe mir das Repository gestern einmal ausgecheckt und mit VSCode angeschaut. Ich programmiere aber normalerweise nur C# beruflich (neben SQL) und habe keine noch Ahnung, wie ich das kompilieren muss, um mir eine eigene Firmware-Version zu bauen :-(. Du hast Dir ja schon erheblich mehr Gedanken um diesen Algorithmus gemacht als ich... also sag ruhig wenn der/die Vorschläge oben Blödsinn ist! Danke für Deine Zeit und Gruß |
|
Hi Markus, Müssten in jedem Fall konfigurierbar sein. Aber inzwischen gibt es schon so viele Parameter, dass viele damit schon nicht mehr zurecht kommen. Da fehlt mir noch eine Idee, wie man damit in der Freeware Community mit umgeht. Ich komme kaum noch hinterher mit Supportanfragen. Eigentlich müsste ich mal §einen Zaun bauen, statt die Hühner zu fangen" |
|
Ich schließe den Request hier jetzt mal, um den Überblick zu behalten. Willst du das Thema in ein Feature Request? (Bitte trotz geschlossenen Issue antworten - sehe das trotzdem). |
|
Hi Jomjol, ja, ein Feature-Request wäre Klasse, evtl. bearbeite ich den auch selber. Bin mir noch nicht klar, WIE ich das von der Logik her angehen würde, täte es aber wohl erst mal selber versuchen. Kann ich dir unabhängig davon ggf. die nächsten Wochen mal ein Set von Bildern zum Anlernen zukommen lassen für die roten Zeiger? Komme zur Zeit leider aus beruflichen Gründen zu nix... :-(. Gruß |
|
Okay - nehme das als "extended CheckConsistency" Logik auf (#21) Und klar, du kannst mir gerne einen Satz Bilder zuschicken - aber bitte die Einstellung gemäß dem Wiki berücksichtigen |
Hi,
mein letzter issue ist leider doch nicht gelöst - da ich ihn nicht erneut öffnen kann, mache ich einen neuen auf... evtl. verschieben?
alter issue:
Mein Zähler sprang heute Nacht von
697.1667
direkt auf
698.0761
Richtig gewesen wäre
697.0761
Man sieht dies wunderbar im Log - eigentlich wurden die Werte WIEDER gut erkannt, es erfolgte jedoch ein Sprung von 1 m³.
Könnte dies mit dem "Fehler" der Erkennung der ersten analogen Nachkommastelle zusammenhängen?
Die erste Nachkommastelle wurde gestern Abend immer als ,1 erkannt obwohl sie eigentlich ,0 war.
Und zum Zeitpunkt, als dann endlich die richtige Nachkommastelle erkannt wurde (,0) ist der Sprung erfolgt.
LOG vom Zeitpunkt des Sprunges:
Zuerst wird noch ein error erkannt - weiter unten dann der Wert übernommen.
aktuelle Config:
Sagt mir bitte ob ich hier noch weiter Daten liefern kann. Bin gerne bereit hier weiter aktiv dran mitzuarbeiten.
Jetzt, nach einem manuellen Reset der Pre-Value ist die Erkennung perfekt..... Aber das hilft ja nicht, wenn die m³ bei jedem vollen Kubikmeter immer einen zusäztlichen Sprung machen Schulterzuck
Gruß
Markus
PS: sagt bitte Bescheid, falls ich nerve :)
The text was updated successfully, but these errors were encountered: