Wasserzähler - Selfmade
-
@Atifan sagte in Wasserzähler - Selfmade:
Ich hab übrigens seit einiger Zeit auf den Bildern die die CAM macht 2 Bereiche mit schwarzen Balken, welche auch nach einem Reboot nicht verschwinden.
Hat einer ne Ahnung was das sein kann, ist da evtl. die Linse defekt oder was am ESP32-Modul?
Im Moment funktioniert die Cam ohne Einschränkungen, da die Balken noch ausserhalb des relevanten Bereichs sind.
Das Problem habe ich auch seit einige Zeit - bei mir ist es ein Balken am oberen Rand. Ich vermute, dass nach mehr als einem Jahr die Kamera langsam einen Schaden nimmt. Ist halt doch etwas feucht über der kalten Wasseruhr.
Eventuell könnte ein anderes Deckeldesign helfen, in dem nur noch die Leuchte und die Kamera durch kleine Fenster offen gehalten werden und der Rest im "Trockenraum" ist und wärmer und mit weniger Feuchte.
Wäre eine Version 2.1, muss ich mal überdenken. -
@jomjol Guten Abend jomjol, ich habe im Beitrag 605 eine Lösung gegen die Feuchtigkeit vorgestellt. Probier doch das mal aus. Ich habe seit dem kein einziges mal mehr ein angelaufenes Schauglas oder sonstige Feuchtigkeit im Aufbau. Einfach herumwickeln und mit einem Spagat festzurren.
Kostenpunkt circa 17,-- Euro -
Also bei mir rennt der Wasserzähler-Sensor jetzt sehr gut und zuverlässig mit meiner aktuellen Config
[Imagesource] TimeoutLoadImage=30 #IP durch die IP des ESP32 ersetzen! URLImageSource=http://192.168.178.238/capture_with_flashlight?quality=10&size=SV GA #LogImageLocation=./log/source_image # Falls nur schlechte / fehlerhafte Bilder gelockt werden sollen, naechste Zeile Kommentar entfernen #LogOnlyFalsePictures=True [ConsistencyCheck] Enabled=True ReadPreValueFromFileAtStartup=True #Maximum Time spanning since last startup for use of preValue from Filestorage i n minutes ReadPreValueFromFileMaxAge=525600 AllowNegativeRates=True #Stores the last Value in a file for the case of a restart (e.g. Docker containe r after update) #Maximum Change of new to old value (+ or -) MaxRateValue=0.5 #Return in Case of Error: Value = OldValue or NewValue # ErrorMessage = Return Text with problem (seperated by Tabstopp) if nothing, then no error message # Readout = Real Readout without corrections (NewValue) ErrorReturn=OldValue, ErrorMessage, Readout #ErrorReturn=OldValue, ErrorMessage #ErrorReturn=NewValue, ErrorMessage [AnalogReadOut] #If enabled analog counters will be read, if disabled only digital counters will be read. Enabled=True [alignment] initial_rotation_angle=0 [alignment.ref0] image=./config/Ref_M100_x547_y193.jpg pos_x=547 pos_y=193 [alignment.ref1] image=./config/Ref_m3_x456_y158.jpg pos_x=456 pos_y=158 [alignment.ref2] image=./config/Ref_x0_x321_y421.jpg pos_x=321 pos_y=421 [Digital_Digit] names=ziffer1, ziffer2, ziffer3, ziffer4, ziffer5 Modelfile=./config/neuralnets/Train_CNN_Digital-Readout_Version_4.1.0.h5 #LogImageLocation=./log/digital_digit #LogNames=zeiger3, zeiger4 [Analog_Counter] names=zeiger1, zeiger2, zeiger3, zeiger4 Modelfile=./config/neuralnets/CNN_Analog-Readout_Version-4.0.1.h5 #LogImageLocation=./log/analog_counter #LogNames=zeiger3, zeiger4 [Analog_Counter.zeiger1] pos_x=491 pos_y=262 dx=125 dy=125 [Analog_Counter.zeiger2] pos_x=432 pos_y=395 dx=125 dy=125 [Analog_Counter.zeiger3] pos_x=298 pos_y=446 dx=125 dy=125 [Analog_Counter.zeiger4] pos_x=157 pos_y=383 dx=125 dy=125 [Digital_Digit.ziffer1] pos_x=203 pos_y=164 dx=36 dy=55 [Digital_Digit.ziffer2] pos_x=248 pos_y=164 dx=36 dy=55 [Digital_Digit.ziffer3] pos_x=295 pos_y=166 dx=36 dy=55 [Digital_Digit.ziffer4] pos_x=343 pos_y=167 dx=36 dy=55 [Digital_Digit.ziffer5] pos_x=390 pos_y=167 dx=36 dy=55 $ -
Hallo zusammen,
ich habe eine neue Version zunächst in die Rolling Versionen (Synology und Raspberry) eingespielt.
Es ist ein Update auf Tensorflow 2.1. Vielleicht ist damit das Speicherleck behoben. Ich habe leider keine Zeit es zu testen, freue mich aber über jedes Feedback.Beste Grüße,
jomjol -
Wie kann ich denn auf die neue Version updaten? Würde es dann mal testen.
-
@Atifan sudo docker pull jomjol/wasserzaehler:raspi-rolling
-
Test heute 17:45h gestartet, mal sehen
-
Habe auch mal geupdetet. Aktuell braucht er 950 MB RAM.
Werde mal beobachten was der RAM macht.
-
Ich habe auch mal einen Docker in proxmox erstellt (vorher auf QNAP) und dann gerade die neueste Version installiert, frage mich wieso er bei dir @Atifan jetzt schon so viel RAM frisst?!
Edit: Es läuft bei mir im Docker nur der Wasserzähler, sonst nichts.
-
Hm, keine Ahnung. Ich hab eine komplette VM mit Debian 10.2 und dem Docker, wahrscheinlich deswegen?
-
@Atifan ah ok, ja ich sehe jetzt erst dass du ne VM nutzt kein Container, dann kann dass natürlich sein
-
@jomjol Hallo,
das Setup sieht beeindruckend aus und gibt vor allem absolute Werte aus, was mir besser gefällt als ein Zähler (der ja auch mal einen Puls übersehen könnte).
Einen Raspberry Pi habe ich (für die Auswertung) und ein ESP32-CAM Board mit fertig eingerichtetem Arduino IDE auch. Ich frage mich aber, wo ich die 3D-Druck Teile bekommen kann, mangels 3d-Drucker kann ich die nicht selber herstellen. Und einige Dienstleister fragen dann nach Material (PP, PE, etc.), da bin ich auch unsicher.
Kannst du mir einen Dienstleister empfehlen?
Bzw. wo hast du die Teile machen lassen?Außerdem: mein Gaszähler ist gleich nebenan, ich habe mir einen Reedkontakt besorgt, welcher auf den Magnet im letzten Zahlenrad des Zählers reagieren müsste. Ich würde im zweiten Schritt mal versuchen, die Software zu erweitern, so dass auch der Gaszähler-Wert erfasst wird (hier haben wir dann aber nur relative Werte). Dafür müsste doch einer der GPIO-Pins taugen, oder?
Danke & Gruß
-
-
@pfried Hier der Vergleich des Speicherverbrauch auf einer Synology DS918+ mit Version 5.4.1 und 6.0.0 (gleichzeitig gestartet um 23:45 Uhr)
-
Also bei mir braucht er aktuell 1.07 GB.
Bei Start waren es 950 MB.
Es wird schon kontinuierlich mehr, aber steig anscheinend weitaus langsamer.
-
Ich bin momentan bei 170MB, bei Start waren es ca. 93MB. Mal abwarten ob es weiter steigt.
-
@Jens77 sagte in Wasserzähler - Selfmade:
Hallo Jens,
die Teile habe ich bei mir selbst gedruckt, Material ist PLA (schwarz - wegen der Beleuchtung). Hast du genau dieselbe Wasseruhr wie ich oder musst du etwas neu konstruieren? Du kannst mich ja mal über den persönlichen Chat kontaktieren. Vielleicht kann ich dir helfen.Auf dem ESP-Board sollten noch genügend Kontakte frei sein, um noch einen weiteren Kanal auszulesen. Allerdings musst du beachten, wie du das ohne Blockade des HTTP-Servers hin bekommst. Die jetztige Software ist nicht für Multitasking ausgelegt. Halt uns doch gerne hier im Forum oder bei Github auf dem Laufenden.
Beste Grüße,
jomjol -
@jomjol Hallo!
Einen 3D-Drucker besitze ich leider nicht, aber ich habe eine CRI-Wasseruhr, die Zeiger sehen etwas anders aus als bei Dir (und das schwarze Zahnrad hat mehr Zähne). Die Maße müsste ich mal genau ausmessen. Dann melde ich mich
Wie liest du den Heizungsverbrauch aus (oder habt ihr keine Gasheizung)? Ich experimentiere gerade per Arduino IDE mit den Pulszähler-Features des ESP32 herum ("pcnt"), der hat offenbar eingebaute Hardware, die das unabhängig von der CPU kann, inkl. Entprellen und diversen anderen Optionen. Damit könnte man dem Hauptprozess (Webserver) einfach einen zweiten Wert zur Verfügung stellen, der dann zusätzlich zum Bild über eine zweite URL angeboten wird.
Was ich noch nicht weiß, ist wie ich beim Pulszähler für den Gasverbrauch mit Stromausfällen und Unterbrechungen umgehen soll. Irgendwie muss der ESP32 sich entweder den Wert merken oder der ioBroker dann automatisch "weiterzählen", wenn die Werte wieder bei Null anfangen.
Oder ich speichere nur die Anzahl Pulse pro Minute o.ä. und integriere das dann erst in Grafana auf. Vielleicht die beste Lösung, da kann man dann auch fehlende Werte einfacher manuell nachtragen.Sobald es bei mir läuft, mache ich einen PR auf Github.
-
Also ich behaupte mal das Memory-Leak ist nicht behoben. Aktuell bei mir 1110 MB RAM-Auslastung.
Das sind 160MB mehr innerhalb von 3 Tagen, d.h. der RAM wird pro Tag etwas mehr als 50MB voller.
Aber der Leak ist glaube ich weniger als vorher, ich denke vor dem Update war der RAM-Verbrauch und Anstieg höher.
Vermutlich ist der Leak auch abhängig von der Anzahl an Bildern die man macht. Bei mir sind es 1 Bild alle 60 Sekunden.
Das Leak ist jedenfalls nicht so schlimm, hochgerechnet auf den Monat wären es ca. 1,5GB an RAM.
Man kann ja notfalls über eine CRON in bestimmten Zeitabständen einen Neustart des Docker-Containers machen.
-
@Jens77 sagte in Wasserzähler - Selfmade:
Ich experimentiere gerade per Arduino IDE mit den Pulszähler-Features des ESP32 herum ("pcnt"), der hat offenbar eingebaute Hardware, die das unabhängig von der CPU kann, inkl. Entprellen und diversen anderen Optionen. Damit könnte man dem Hauptprozess (Webserver) einfach einen zweiten Wert zur Verfügung stellen, der dann zusätzlich zum Bild über eine zweite URL angeboten wird.
Ich habe für meine Leckageüberwachung vor ca. 3 Jahren (s. Homematic-Forum) kurzen Prozeß gemacht: 2 Stück ESP8266 per serieller Schnittstelle verbunden. Für diese Kommunikation gab es irgendwo eine fertige lib.
Der eine zählt Impulse, der zweite macht Webseite, Statistik, Datenauslieferung, in meinem Fall an Homematic - ioBroker wäre auch möglich. Der "Zählprozessor" zählt per Interrupt nicht durch pollen. Da kommt man auf einige kHz, was für so ein Sternrad einer Wasseruhr mehr als ausreicht. Webseitenaufrufe etc stören dann nicht mehr. Beim ESP8266 geht dann halt lediglich die serielle Schnittstelle (HW-Serial) für debugzwecke verloren.Was ich noch nicht weiß, ist wie ich beim Pulszähler für den Gasverbrauch mit Stromausfällen und Unterbrechungen umgehen soll. Irgendwie muss der ESP32 sich entweder den Wert merken oder der ioBroker dann automatisch "weiterzählen", wenn die Werte wieder bei Null anfangen.
Ich habe zwei Methoden implementiert und getestet:
- Speicherung des kumulierten Wertes in der Homematic-CCU (ioBroker wäre auch möglich), aber Verarbeitung auf dem (zweiten) ESP8266. Beim Start fordert der ESP den letzten kumulierten Wert an und setzt darauf auf. Er übermittel neue kumulierte Werte wieder zurück an die CCU. Würde also mit der Datenbasis des ioBroker auch gehen (simpleApi).
- Speicherung des kumulierten Wertes in einem I2C EEPROM. Die Speicherzyklen reichen auch ohne wear leveling viele Jahre. Beim Start holt der ESP den kumulierten Wert aus diesem EEPROM und verarbeitet ihn weiter. Das Ergebnis wird an die CCU geschickt, wobei das nach einigen Litern oder nach einer gewissen Zeit getan wird. Einen ähnlichen Mechanismus gibt es auch beim Zurückschreiben des kumulierten Wertes zum EEPROM.
Oder ich speichere nur die Anzahl Pulse pro Minute o.ä. und integriere das dann erst in Grafana auf. Vielleicht die beste Lösung, da kann man dann auch fehlende Werte einfacher manuell nachtragen.
So etwas habe ich bei einem S0-Zähler gemacht, bei dem ich mit einen ESP8266 mit dem ESPEasy framework experimentiert habe. Das ESPEasy Framework kann auch Werte kumulieren, aber leider nicht persistent, wodurch das für Zählezwecke wertlos wird. Bei jenem Projekt habe ich die Pulse innerhalb eines Zeitintervalls an den ioBroker geschickt und dort per Skript in Leistung umgerechnet sowie die Ticks kumuliert und damit die Energie ohne kumulierende Rundungsfehler berechnet. Mittlerweile gibt es in ioBroker auch Adapter, die so etwas können (statistics und sourceanalytix)
Alle 3 Methoden funktionieren.
