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

[Homoran]

@pfried
@TbsJah

Die Zahlen werden ja bis auf die letzte 7 richtig erkannt.
etwas kleiner kann nicht schaden, aber IMHO liegt die Ursache daran, dass ganz rechts das Bild dunkler und s8mit kontrastärmer ist als beim Rest.
Ggf hängt das auch mit der nicht unerheblichen Reflexion der LED in der Bildmitte zusammen.

[Rupert S.]

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

Ggf hängt das auch mit der nicht unerheblichen Reflexion der LED in der Bildmitte zusammen.

@TbsJah: Kleb' die reflektierende Stelle einfach mit z.B. Pflaster ab. Oder sogar alles außerhalb der ROI. Hat bei mir gut geholfen. Siehe Beitrag 1358.

[pfried]

@rupert-s Aber nicht vergessen die Alignment Punkte mit ausschneiden. Man kann, habe ich auch schon gesehen, siche eine schwarze Schablone zurechtlegen wo die ROI und Alignment Punkte ausgeschnitten werden (kein glattes Papier verwenden)

[Homoran]

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

Aber nicht vergessen die Alignment Punkte mit ausschneiden

wenn das Papier passt kann man die Alignment punkte sogar aufmalen

[Zwer2k]

Seit Anfang des Jahres läuft mein Zähler absolut stabil, auch mit der billigen SD-Karte die am Anfang paar mal neu bespielt werden musst. Super Arbeit .

@jomjol
Ich würde gerne freie GPIOs für andere Zwecke benutzen (z,.B. Bewegungsmelder). Währe es möglich die GPIOs einfach per MQTT durchzureichen? Dürfte glaube ich nicht so viel aufwand sein, müsste eventuell eine Einstellmöglichkeit in der Weboberfläche implementiert werden, am beste als Interrupts und/oder in Zeitabständen.

[Rupert S.]

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

Seit Anfang des Jahres läuft mein Zähler absolut stabil,

Hmmm, da frage ich mich: Mache ich was falsch?

• Immer wieder schwarze Bilder
• Blitzlicht blieb 2x auf Dauerlicht (hab's zufällig im Keller entdeckt und musste es durch Reboot lösen)
• Ausgelesener Zählerstand "robbt" sich davon obwohl stundenlang überhaupt kein Wasserverbrauch auftrat

Ich bin schon drauf und dran, auf das Vorgängerprojekt zu gehen: ESP32 macht nur Foto, AI wird auf einen meiner unterbeschäftigten, aber dauernd laufenden Pi's installiert. Da würde ich mir mehr Kontrolle und Einblicke erhoffen.

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. Ich habe zwei Versionen des Boards: 99E2 und 8E02. 8E02 zickt da rum, den 99E2 habe ich leider beim Versuch, auf externe Antenne umzulöten, zerstört (die Pads für den "0-Ohm-Widerstand" sind auch unverschämt klein, obwohl reichlich Platz wäre )

[jomjol]

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

@michmein danke Michael. Das hatte ich gelesen aber ich verstehe es nicht.
Was ist mit Netzgröße gemeint?

Version q gleich schlechter weil kleiner?

Nein, "q" bedeutet quantisierte Gewichte. Damit kann das Netz kompakter gespeichert werden (Datentyp mit geringerem Speicherbedarf). Aber die Genauigkeit nimmt nicht ab.
Generell kann man nicht sagen, dass "kleiner = schlechter". Zu groß gewählte Netzarchitekturen lernen, wenn es schlecht läuft, die Bilder nur auswendig, aber abstrahieren die Eigenschaften nicht. Dann sind kleiner Netze in der Tat besser.

[jomjol]

@rupert-s Ich habe die Erfahrung gemacht, dass es an der OV2640 liegt. Ich habe mehrere Kameras (unterschiedliche Versionen laut Beschriftung auf dem Flexband) probiert und musste auch feststellen, dass einige dazu neigen, sich aufzuhängen. Konnte noch keine Systematik finden.
Ich habe mir mal 2 weitere bestellt, um weiter zu experimentiren.

[jomjol]

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

Seit Anfang des Jahres läuft mein Zähler absolut stabil, auch mit der billigen SD-Karte die am Anfang paar mal neu bespielt werden musst. Super Arbeit .

@jomjol
Ich würde gerne freie GPIOs für andere Zwecke benutzen (z,.B. Bewegungsmelder). Währe es möglich die GPIOs einfach per MQTT durchzureichen? Dürfte glaube ich nicht so viel aufwand sein, müsste eventuell eine Einstellmöglichkeit in der Weboberfläche implementiert werden, am beste als Interrupts und/oder in Zeitabständen.

Im Prinzip schon, aber momentan arbeite ich an einem anderen Feature (mehrere getrennte Zahlen für Mehrfachzähler). Dein Wunsch ist schon eher speziell, Aufwand dafür vermutlich schon so 1 Nachmittag. Ggf. einen eigenen Fork machen?

[Zwer2k]

@rupert-s
Wie gesagt, solche Probleme kenne ich seit Anfang des Jahres nicht mehr. Hast du schon mal andere SD-Karte getestet? Wenn das Licht an geblieben ist, deutet darauf hin, dass der Zähler hängen geblieben ist, das wiederum kann von einer defekten SD-Karte kommen. Defekte SD-Karte kann auch Timig-Probleme verursachen, die eventuell auch schwarze Bilder erklären könnten.
Mit dem mickrigen Antennen-Wiederstad habe ich mich auch schon rumgeärgert.

[Zwer2k]

@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

[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