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

[watcherkb]

hat schon jemand versucht mit der Camera "ums Eck" zu schauen, z.B. mit einem Spiegel? Würde gerne den Gaszähler auswerten, aber nach vorne hin habe ich überhaupt kein Platz. Würde mich über Erfahrungen freuen.

[pfried]

@watcherkb Ich kann mich erinnern, dass jemand bereits das mit dem "ums Eck" schauen realisiert hat. @jomjol hat dann auch was in die SW eingebaut um die "Spiegelung" des Bildes wieder zu beseitigen.

[pfried]

@Hasont Was für ein Script brauchst Du? Wir haben in dem Vorgänger Thread einige Scripte erarbeitet.

[worbis]

@jomjol einen Verbesserungsvorschlag um auch andere Sensoren gut ablesen zu können, wäre eine Option das jeder erkannter Wert (Ziffer oder Zeiger) in einer MQTT Nachricht verschickt wird. Entweder als eine Nachricht z.b. mit Strichpunkt getrennt oder als mehrere Nachrichten. Damit könnten auch Anzeigwerte erkannt werden wo die Berechnungslogik wie sie aktuell ist nicht gut funktioniert. Auch die Logik wie sich der Wert errechnet kann damit ausgelagert werden. Und am besten wäre es noch den confidence Wert aus dem Modell mitzuschicken. z.B.: Zahl 8, confidence 80%.

[watcherkb]

@pfried ja kann mich auch dran erinnern. Müsste im alten Thread gewesen sein.

[stan23]

Eine Sache ist mir noch aufgefallen:
mein ESP macht immer wieder spontane Reboots und verliert dabei scheinbar die preValue, denn nach einem solchen Reboot werden die Digitalzahlen statt 569 als 509, 559 oder 599 erkannt, und dieser Rücksprung oder große Sprung nicht abgefangen.

Wie kann ich hier unterstützen?
Soll ich einen Raspi + FTDI dranhängen und die seriellen Ausgaben protokollieren?
Wenn es einen Coredump/Stacktrace gibt, hilft das zur Analyse weiter?

Version: master - v3.1.0 - 2020-10-26

[jomjol]

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

hat schon jemand versucht mit der Camera "ums Eck" zu schauen, z.B. mit einem Spiegel? Würde gerne den Gaszähler auswerten, aber nach vorne hin habe ich überhaupt kein Platz. Würde mich über Erfahrungen freuen.

Hi watchkerb,
der Parameter zum Spiegeln des Kamerabildes lautet:

[Alignment]
InitalMirror = true

Details siehe wiki: https://github.com/jomjol/AI-on-the-edge-device/wiki/Configuration-Parameter-Details

Gruß,
jomjol

[jomjol]

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

Eine Sache ist mir noch aufgefallen:
mein ESP macht immer wieder spontane Reboots und verliert dabei scheinbar die preValue, denn nach einem solchen Reboot werden die Digitalzahlen statt 569 als 509, 559 oder 599 erkannt, und dieser Rücksprung oder große Sprung nicht abgefangen.

Wie kann ich hier unterstützen?
Soll ich einen Raspi + FTDI dranhängen und die seriellen Ausgaben protokollieren?
Wenn es einen Coredump/Stacktrace gibt, hilft das zur Analyse weiter?

Version: master - v3.1.0 - 2020-10-26

Das ist leider ein dauerhaftes Problem, welche teilweise auf die verwendeten Bildverarbeitungsbibliotheken zurück verfolgen kann.
Leider habe ich es nicht geschafft, einen Debugger an das ESP32-CAM Modul anzubinden, da aufgrund Kamera und SD-Card auch die Standart-Debugging Port belegt sind.

Wenn sich dort jeman auskennt, wäre das sehr hilfreich!

@stan23: eine Zwischenlösung, um bei Auftretten des Fehlers nicht in die von dir benannten Probleme zu laufen ist, den Parameter PreValueAgeStartup auf einen sehr großen Wert zu setzen. Denn der steuert, wieviele Minuten der PreValue gut ist.
Ein kurzer Wert führt in folgender Situationen zu dem benannten Problem: Da gerade ein ungültiger Wert "N" gelesen wird, wird der PreValue nicht aktualisiert. Wenn kein Wasser gebraucht wird (z.B. Nacht) kann dies auch mehrere Stunden andauern. Nun startet der ESP32 irgendwann zufällig neu und viola - er verwendet den PreValue nicht und kann die Zahlen auch nicht korrigieren. Empfehlung: Parameter auf mehrere Stunden einstellen.

[hike]

@jomjol

Hilfe gesucht: Problem beim Druck des Kameradeckels 3d_AI-on-the-edge_Cover.stl.

Hallo,
Ich habe mich zum ersten Mal an einem 3D-Druck versucht ( Cura 4.7 , Conrad Monoprice Mini V2, Velleman PLA)

Meine ersten Versuche habe ich mit dem Kameragehäuse gemacht.

Ich habe das Gehäuse (3b) und den Einsatz(3c) problemlos gedruckt bekommen.

Der Drucker scheitert aber immer am Deckel, weil die Software den Deckel auf 4 Beinchen stellt und die großen Zwischenräume nicht überbrückt werden konnten.
Gibt es eine Möglichkeit , den Deckel um 180° zu drehen und dann zu sclicen?

Gruß Hike

[jomjol]

Hi @hike,

drehen in CURA ist kein Problem. Einfach das Objekt auswählen und auf der linken Seite das Tool zum Drehen wählen:

Gruß,
jomjol

[MichMein]

Hallo @jomjol,

zu allererst mal alle Daumen hoch für Dein Superprojekt hier. Ich habe schon ein ganze Zeit mitgelesen und habe es dann diese Woche geschafft den ESP zu flashen und heute habe ich mir provisorisch ne Pappschachtel über den Wasserzähler gestülpt und den ESP im Gehäuse oben drauf geklebt. Nach ein wenig Justierung und drehen am Fokus klappt das sehr gut, Weltklasse! Nächste Woche werde ich mir mal Deine Adapterringe für die Wasseruhr drucken.

Ich habe versucht den MQTT Diesnt im Sonoff Adapter zu nutzen, das hat leider nicht geklappt da dieser scheinbar eine ganz bestimmt Art der Nachrichten erwartet. Mit dem MQTT Server Adapter hat es dann geklappt.

Hat jemand der anderen Nutzer es durch Einstellungen in der Config.ini geschafft das gute Stück in den Sonoff Adapter zu bekommen? Dadurch könnte ich mir den zusätzlichen Adapter sparen.

Fazit: SPITZENPROJEKT!

PS. als nächstes ist der Gaszähler am dran.

Schönes Wochenende noch, Gruß Michael

EDIT: kann ich irgendwie die Uhrzeit des ESP einstellen?

[hike]

@jomjol Danke für den Tip, jetzt druckt er auch den Deckel.

Thema Gaszähler / Wasserzähler:

Die Rebootzs haben bei mir zwei unterscheidbare und reproduzierbare Ursachen.

1. Wenn ein Flow läuft, führt ein Aufruf der Startseite bei mir zum Reboot.
2. Nach etwa 43 Flows erfolgt ein Reboot.

zu 1: Ich habe die Ausgaben im Seriellen Monitor vom vielen Reboots im ESP-Exception-Decoder analysiert.
Es werden immer wieder andere Stellen im Code von FtLite angezeigt.
Für mich sieht das so aus, als wären die verwendten Routinen in den Bibliotheken nicht reentrant.
Ich habe deshalb die sysInfo weiter ausgebaut um mehr über den Status der Flows zu erfahren.
Wartet man bis der aktuelle Flow abgeschlossen ist, bleibt das System stabil. Die Startseite ruft zum Aufbau mehrfach den Webserver über verschiedene url's auf. Das scheint das RTOS-Beriebssystem zu überfordern, wenn gleichzeitig noch sehr rechen- und zeitintensive Prozesse zur Bildanalyse laufen.

zu 2: Der zweite Fehler sieht danach aus, dass Speicher ( möglicherweise in den Bibliotheken ) nicht richtig freigegeben wird und die Heaps damit immer kleiner werden bis es kracht. Ich hatte ein ähnliches Problem bei der Verwendung von fmt2jpg aus img_converters.h. Leider ist das Interface zu fmt2jpg schlecht kommentiert, man muss in den Code reinsehen um zu erkennen, das die Routine selber für die Auagabe Speicher alloziert die man anschließened selber freigeben muss.

Ich arbeite weiter daran.

Gruß Hike

[jomjol]

Hallo @MichMein,

die Uhrzeit stellt sich immer bei einem Hard-Reboot ein. Sollte eigentlich auch bei einem Softreboot passieren - tut aber noch nicht :-).

Gruß,
jomjol

[MichMein]

@jomjol hi, der ESP ist meiner Zeit 1 Stunde voraus, das hätte ich gerne geändert.

Danke

[jomjol]

Hi @hike,
an deinen Debugging Fähigkeiten wäre ich interessiert - vielleicht können wir uns dazu mal austauschen - Der Reboot ist die "letzte" große Baustelle, an der ich scheitere und die mit einigen Work-Arounds halbwegs erträglich halte. Ist aber immer nur eine Krücke.
Bin gespannt, was du rausfindest.
Gruß,
jomjol

[jomjol]

@MichMein Habe mir gerade den Quellcode angeschaut und den ersten Fehler gefunden. Bei einem Soft-Reboot wird der Time-Server nicht gesetzt und dann kann er natürlich auch die Zeit nicht synchronisieren. Bin gerade aber nicht zuhause und kann es daher nicht testen. Ich probiere es nächste Woche und melde mich. Wenn es daran liegt, könnte ich

1. entweder Menüpunkt zur Synchroniserung oder
2. einmal alle 24h einen Sync

oder beides implementieren. Danke für den Hinweis.
Gruß,
jomjol

[MichMein]

@jomjol hi, ist letztendlich nichts schlimmes, mach Dir also keinen Stress. Im ioBroker DP wird die Zeit der ankommenden Daten über MQTT richtig geschrieben, mir war es in den Log nur aufgefallen.

Wenn Du mal ganz viel Zeit und Lust hast wäre es ne tolle Sache wenn Du das MQTT Zeugs für den Sonoff-Adpater im ioBroker konform gestalten könntest.

... Bin gerade aber nicht zuhause und kann es daher nicht testen ...

Noch darfst Du weg, ab Montag ist das erstmal wieder vorbei

[hike]

@jomjol

Hallo
Ich habe die Rolling Version vom 25.9.2020 als Ausgangspunkt genommen und diverse Änderungen im Code vorgenommen. Leider habe ich nur sehr,sehr rudimentäre Erfahrungen mit collaborativen Arbeiten mit GIT.
In den neueren Code habe ich noch nicht reingesehen.

Da ich den Wasserzähler leider nicht stabil bekommen habe, habe ich mich an meinem Gaszähler versucht.
Da werden doch häufiger Ziffern richtig erkannt.

Um die Beleuchtung regulieren zu können, habe ich ledc_timer verwendet. da muss man wegen der Verwendung einiger Timer durch die Kamera aufpassen. Ich verwende LEDC_Timer_2 und LED_Channel_7.
Die SD-Card habe ich auf slot_config.width = 1 eingestellt, damit wird GPIO04 frei.

Alle Versuche, den zweiten I2C-Bus zu nutzen ( z.B. für ein OLED-Display) sind gescheitert

Ich habe viele Logging- Funktionen auf ESP_LOGI(TAG," "); umgestellt
Die Logfilegröße habe ich beschränkt und lege die alten Log_files in einem separaten Verzeichnis ab.

Du verwendest stb_xx.h files . Gibt es dazu eine API-Dokumentation?
Wo werden Funktionen verwendet, die in Referenzparametern Ergebnisse zurückliefern,
Bekommen die beim Aufruf einen Ergebnisspeicherblock mitgeliefert oder allozieren die selber Speicher.
Du verwendest an verschiedenen Stelllen user_ctx->scratch, da steht meistens nur ein Namesstring drin, ich habe aber irgendwo auch einmal ein Malloc gesehen, finde das aber nicht mehr

Gruß Hike

[jomjol]

Hallo @hike,

die Diskussion zu den Programmierdetails könnte etwas ausführlicher werden und nur wenige im ioBroker Forum werden die Details verfolgen wollen. Daher schlage ich vor, diese in einem Issue in GitHub zu führen:

https://github.com/jomjol/AI-on-the-edge-device/issues/39

Meine Antwort zu deinen Fragen findest du dort. Ich hoffe, das passt für dich!

Gruß,
jomjol

jomjol created this issue in jomjol/AI-on-the-edge-device

closed Improved Debugging #39

[stan23]

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

@stan23: eine Zwischenlösung, um bei Auftreten des Fehlers nicht in die von dir benannten Probleme zu laufen ist, den Parameter PreValueAgeStartup auf einen sehr großen Wert zu setzen. Denn der steuert, wie viele Minuten der PreValue gut ist.

Danke, das probiere ist momentan.

In der Zwischenzeit habe ich mich um meinen Gaszähler gekümmert. Leider habe ich bei der ersten Gehäuseversion nicht berücksichtigt dass die erste Nachkommastelle hinter dem dicken roten Rahmen versteckt ist, 3 und 8 sind nicht zu unterscheiden.
Also werde ich das Teil nochmal anpassen und neu drucken müssen.