Wasserzähler - Version 2 - all-in-device

stan23

@rupert-s said in Wasserzähler - Version 2 - all-in-device:

Nebenbei: Gibt es von dem ESP32-CAM AI-Thinker Board Versionen ohne integriertem Pullup-Widerstand an IO0? Ich habe Boards, die nach dem Drücken des Reset-Knopfes in den Download-Mode gehen anstatt das Programm zu starten. Laut diesem Schaltplan sollte ein Pullup da sein.

Der ESP32 hat sogar einen internen Pull-up an IO0 und anderen Pins.
Du könntest im stromlosen Zustand messen ob an IO0 nicht ein Kurzschluss nach GND vorliegt, und wenn nicht, einen externen Widerstand nach VCC setzen. Der kann ja auch bedrahtet sein wenn es in SMD nicht klappt.

Rupert S.

@zwer2k said in Wasserzähler - Version 2 - all-in-device:

Hast du schon mal andere SD-Karte getestet?

Ich hatte für dieses Projekt extra zwei frische SanDisk Ultra microSDHC UHS-I Karten mit 16GB gekauft. Class 10 und bis zu 80 MB/s.

Was ich vergaß zu schreiben: Ich verwende die Version "master" vom 23.05.21. Das ist nicht die absolut neueste. @jomjol: Sind in den neueren (master oder rolling) diese Themen adressiert? Ich hatte hier ja den Hinweis auf den möglichen Konflikt um GPIO4 gepostet.

Rupert S.

@stan23 said in Wasserzähler - Version 2 - all-in-device:

externen Widerstand nach VCC

Mit zusätzlichen 10k nach 5V bootet der ESP zuverlässig...

Rupert S.

@jomjol said in Wasserzähler - Version 2 - all-in-device:

Ich habe die Erfahrung gemacht, dass es an der OV2640 liegt.

Meine drei Kameras sind alle identisch mit "TY-OV2 640-V2.0" beschriftet.

jomjol

@zwer2k sagte in Wasserzähler - Version 2 - all-in-device:

@jomjol sagte in Wasserzähler - Version 2 - all-in-device:

Dein Wunsch ist schon eher speziell, Aufwand dafür vermutlich schon so 1 Nachmittag. Ggf. einen eigenen Fork machen?

Würdest du den Fork dann mergen? Will schon noch von deinen Updates profitieren

Eine Ausgabe der Firmware-Version und der Up-Time per MQTT währe auch nicht schlecht

Grundsätzlich schon. Die GPIOs sind eigentlich schon durch als Ausgabe-PINs für einen anderen Feature Request belegt - also schon ein Interessenkonflikt. Wenn du das parametrisierbar machst und gut kapselst, dann kann ich das übernehmen.
Early Warning: wenn der Platz auf dem Speicher (aktuelle Auslastung 92%) für zentrale Features knapp wird, ist das ein möglicher Streichkandidat.
Beste Grüße,
jomjol

jomjol

@rupert-s sagte in Wasserzähler - Version 2 - all-in-device:

@zwer2k said in Wasserzähler - Version 2 - all-in-device:

Hast du schon mal andere SD-Karte getestet?

Ich hatte für dieses Projekt extra zwei frische SanDisk Ultra microSDHC UHS-I Karten mit 16GB gekauft. Class 10 und bis zu 80 MB/s.

Was ich vergaß zu schreiben: Ich verwende die Version "master" vom 23.05.21. Das ist nicht die absolut neueste. @jomjol: Sind in den neueren (master oder rolling) diese Themen adressiert? Ich hatte hier ja den Hinweis auf den möglichen Konflikt um GPIO4 gepostet.

Ja - in den neueren Versionen wird die SD-Karte im 1-Line Modus angesprochen. Dort ist der GPIO4 dann nicht in Benutzung, bzw. nur für die LED frei.

Zwer2k

@jomjol sagte in Wasserzähler - Version 2 - all-in-device:

Grundsätzlich schon. Die GPIOs sind eigentlich schon durch als Ausgabe-PINs für einen anderen Feature Request belegt - also schon ein Interessenkonflikt.

Du meinst vermutlich die Anfrage um Externe Flash-LED ansprechen zu können.

Welche GPIOs könnten überhaupt für andere Zwecke verwendet werden?
So wie ich es sehe sind die meisten für die SD-Karte verwendet.
GPIO16 sollte als einziger ohne Einschränkungen nutzbar sein.
Serielle Schnittstelle wird ja fast nie benutzt, somit können doch GPIO1 und 3 für andere Zwecke verwendet werden.
GPIO 0 könnte bei richtiger Beschaltung auch verwendet werden, ist halt wichtig das hier beim Booten HI anliegt.
In FeatureRequest.md steht was davon, dass GPIO 12 und 13 verfügbar sind. Werden die nicht auch von der SD-Karte mitbenutzt?

jomjol

@zwer2k Verfügbar sind GPIO 12 und 13, jedoch jetzt schon per http steuerbar für eine Spezialanwendung. Die Serielle Schnittstelle wird zwar im Betrieb nicht genutzt, ich benötige sie aber sehr intensiv für die Entwicklung und das Debugging. Daher müsste deine Implementierung sehr einfach deaktivierbar sein.
Mit GPIO0 habe ich bisher keine guten Erfahrungen gemacht. Es schein irgendwie auch noch mit der SD-Karte verknüpft zu sein.

Rupert S.

Hallo,

mein verlängertes Wochenende habe ich damit verbracht, ESP-Boards, Kameras und SD-Karten hin und her zu tauschen. Meine Erkenntnis: Auch mit einem externen 10k-Widerstand von IO0 nach +5V gerät ein Board in den Download-Modus -- vielleicht ist es doch einfach nur defekt...
Von den beiden SD-Karten ist jetzt die andere im Einsatz. Mal schau'n.

Bin nun auf Version master - v7.1.1 - 2020-05-30.
Was mir beim vielen Konfigurieren aufgefallen ist: In der config.ini steht (via Fileserver)

[System]
TimeZone = CET-1CEST,M3.5.0,M10.5.0/3

Die Website /index_configure.html zeigt aber nur "Timezone: CET-1CEST". Das wird beim Speichern (Update Config.ini) dann auch übernommen, so dass die Erweiterung mit den Schalttagen verloren geht.

Ist es richtig, dass der ESP intern mit Zulu-Time rechnet? Ich hatte mich gewundert, dass beim Auslesen der SD-Karte (mit dem Desktop) die config.ini einen Zeitstempel in der Zukunft hatte.

So ganz stabil und mit zuverlässigen Ergebnissen läuft's bei mir immer noch nicht. Wenn ich daher "meine 5 Ct" für Verbesserungen einbringen darf: Zum Debuggen fände ich weitere MQTT-Kanäle sehr hilfreich. Z.B. einen für den RAW-Value (inkl. der N für nicht erkannte Ziffern) und einen für corrected oder checked value -- welcher auch immer vom "Topic" abweichen kann. Ich hätte es ja fast selbst in einen fork eingebaut, aber die Komplexität überfordert mich dann doch. Und: Den Error-Kanal sollte man m.E. nur befeuern, wenn tatsächlich ein Fehler vorliegt. Die kontinuierlichen "no error" oder früher " " finde ich nicht optimal...

Viele Grüße, Rupert

Rupert S.

@rupert-s said in Wasserzähler - Version 2 - all-in-device:

Von den beiden SD-Karten ist jetzt die andere im Einsatz. Mal schau'n.

Nein, kein Erfolg: in <90 min 2x Dauerlicht. Es kommen dann auch keine Daten mehr. Der Webserver antwortet zwar noch, z.B. auf /capture_with_flashlight, aber das reaktiviert die Bilderkennung auch nicht. Immerhin funktioniert ein /reboot aus der Ferne...

RolandR

Ich habe in den letzten Tagen auch meine ersten Gehversuche mit dem AI-on-the-edge Wasserzähler-Leser gemacht. Nach diversen Fehlversuchen (zwischendrin hat der esp32-cam alle 20 Sekunden gebootet, weil ich wohl irgendwas in der config.ini hatte, was ihm nicht gefallen hat) und einem regelmäßig bei der Configuration verschwindenen config.ini (inzwischen habe ich immer ein Backup zur Hand, das ich zur Not wieder hochladen kann), sieht jetzt eigentlich alles ganz gut aus, außer dass die digits nicht zuverlässig erkannt werden:

Manchmal erkennt er die 8 als 8, meistens allerdings als 0. Und die Einerstelle des Zählerstandes (zwischen 6 und 7, sollte also 6 oder zur Not "N" sein), wird inzwischen auch als 0 erkannt
Was kann ich dagegen tun?
Ich habe schon so lange am Rohr gedreht, dass ich jetzt genau bei 90° liege und keine zusätzlichen Artefakte durch die Rotation des Bildes dazu kommen, aber das löst das Problem leider auch nicht.
Gibt es vielleicht irgendwo eine andere Datenbank für weiße Zahlen auf schwarzem Grund?
Oder kann ich die selber anlernen?

Gruß
Roland

TbsJah

@jomjol Wie ist der Ablauf bei der Erkennung?
Es wird ein Bild erstellt
Gemäß den Vorgaben gedreht
Jede Markierung analysiert?

Ich habe immer wieder dieses Phänomen. Als würde die Erkennung bereits starten obwohl das Bild noch nicht korrekt gedreht ist

Negative Rate - Returned old value - read value: 111.711 - raw value: N0N11.NN1 - checked value: 111.710999

Log Eintrag
Durch das scheinbar nicht fertige Drehen sind dann leider auch Falscherkennungen vorhanden.
Ist von 162.791 auf 162.885 gesprungen obwohl eigentlich 162.805
Die errechnete Flow Rate wäre aber auch nicht korrekt oder habe ich da einen Denkfehler?
Wäre doch 0.094 und nicht 0.018799

Vermutlich habe ich jedoch etwas falsch eingestellt. Werde auf alle Fälle noch abkleben wie weiter oben empfohlen

jomjol

@tbsjah
Normaler Ablauf:

Bildaufnehmen
Alignment (Analyse der beiden Referenzmarken)
Analyse der Zahlen
Analyse der Zeiger
Zusammensetzen, Konsistenzprüfung, Verschicken

Es mindestens drei Ursachen, warum das Bild komisch aussehen kann:
a) Zwischen Bildaufnahme und Alignment, wird das Zwischenbild angezeigt, da nicht genug RAM vorhanden ist, um das alte Bild weiter vorzuhalten, bis die neue Analyse vollständig ist.
Dann sollten aber keine falsch erkannten Ziffern erkannt werden, da die alten noch angezeigt werden

b) Etwas mit der Kameraaufnahme ging schief, dann wird manchmal noch das alte Bild ververarbeitet und z.B. nochmal gedreht --> führt zu völlig falschen Werten

c) Alignmentmarken nicht richtig gefunden --> Versatz um bis zu 40 Pixel und entsprechen unpassende Erkennung.

Ich tippe bei deinem Bild auf c), da der Kontrast der Referenzmarken sehr schwach aussieht. Kannst du andere Marken wählen oder vielleicht etwas Dunkles aufkleben, und das als Marke verwenden?

Gruß,
jomjol

b) Alignmentmarken nicht gefunden

TbsJah

@jomjol Danke für die Erklärung

Sieht jetzt soweit gut aus

pfried

@tbsjah Ich glaube Du könntest noch was verbessern, wenn Du zwischen die beiden weißen Quadrate noch einen schwarzen Filz, oder Stoffstücken aufklebst.

Xsev

Was auch relativ gut geht, ich hab den ESP in ein Stück Kabelkanal gesetzt, nur die Linse schaut durch ein kleines Loch raus. Der Blitz wird durch das weiße Kunststoff ein bissel abgeschwächt (leuchtet aber gut durch), was zu deutlich weniger Reflektionen führt.

jomjol

@tbsjah sagte in Wasserzähler - Version 2 - all-in-device:

@jomjol Danke für die Erklärung

Sieht jetzt soweit gut aus

Klingt gut, noch ein kleiner Tip zu deinen ROIs. Du kannst sie ruhig ein bisschen größer wählen. Es ist nicht schlimm, wenn sich die ROIs leicht überlappen. Insbesondere deine "1" ist ziemlich an der Kante und das könnte zu Problemen führen.

wingfighter

Hallo jomjol,

ich habe das Projekt seit drei Wochen aktiv und nutze die Werte, die per MQTT übertragen werden.
Leider ist der Rate-Topic immer 0.000000.
Gibt es eine Einstellung, die ich vergessen haben könnte? Oder ist die Berechnung der Rate noch nicht aktiv?

Viele Grüße
wingfighter

Nachtrag: Nun hatte ich mich entschlossen, mal nachzufragen, da steht heute eine Rate drin. OK. Zurzeit läuft die Beregnung, da führt der konstante Wasserverbrauch zu mehr Messwerten und eben auch einer Rate.

Bedeutet 0.000000 = 1 m³ und ist die ganz rechte Stelle demnach 1ml?

WernerS

@jomjol

Hallo

ich habe bei meinem Stromzähler jetzt ein update von 4.1.0 auf 7.1.1 master gemacht. Jetzt erkennt er allerdings fast nichts mehr. Da sind jetzt auch 2 Rechtecke bei den Digits zu einstellen zu sehen. Was muss ich ändern?

Gruß
Werner

jomjol

@werners Hallo Werner,
hast du auch die tflite übernommen oder bei der alten belassen? Nur diese allein beeinflußt eigentlich die Erkennung. Ansonsten müsstes du mal ein Logfile und insbesondere ein Bild von der Oberfläche posten. Bei mir hatte der Wechsel ohne Probleme funktioniert.

NEWS

Wasserzähler - Version 2 - all-in-device

Wasserzähler - Version 2 - all-in-device

Support us

567

32.4k

81.3k

1.3m