UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Rupert S.]

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

Warum ist das so?

Ich vermute stark, dass Du die digitalen Ziffern in der falschen Reihenfolge definiert hast: Zählerstand ist 00042, raw value zeigt 24000. Sie müssen von links nach rechts parametiert werden (dig1 - dig5).

[Rupert S.]

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

Value aber einen anderen Wert hat.

Unabhängig von den vermutlich falsch angeordneten Digitalziffern: Ob raw value nach value übernommen wird, hängt wesentlich von Deiner Konfiguration im PostProcessing ab.

[da_ba_bw]

@rupert-s

Hab jetzt mal meine Digitalziffern in dem Dropdown Menü in der Reihenfolge getauscht. (Linke Ziffer ganz oben?) Dachte eigentlich das hatte ich so definiert.
Lustigerweise hatte ich auch schon RAW 002400 stehen.

Im Postprocessing hab ich glaube nur MaxRateValue auf 0,2 geändert da ich nur alle 10 Minuten auslese.

Edit: Die Reihenfolge der Ziffern scheint wirklich das Problem gewesen zu sein, jetzt ist RAW 00042.1061 und Value 42.1061

[jomjol]

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

@jomjol Ja, der Bericht war danach verfasst...

Dann schick mal deine config.ini und einen Screenshot von der Version. Idealerweise machst du einen Issue in Github. Hier verliere ich gerade den Überblick.

[spaceduck]

@jomjol

kannst Du mal schauen ob so eine 5 in den Trainigsdaten vorhanden ist? Die Erkennung tut sich recht schwer damit.

Danke...

[JoergH]

@jomjol Ich habe noch etwas rumgestellt in der Config und nachdem ich einfach mal Nachkommastellen eingetragen habe, ging es dann auf einmal. Genau verstanden habe ich es nicht, aber jetzt zeigt er alle Stellen an.

[jomjol]

@spaceduck Am einfachsten schickst du mir 2-3 Bilder von deiner "5" und ich nehme sie mit ins Training auf.

[Hc-Yami]

Hallo zusammen,
habe ich hier ggf. etwas falsches konfiguriert:

Ich verstehe hier nicht warum er unbedingt den Wert auf .148 setzen möchte. Er erkennt ja die .19N Das sollte trotz Prüfung ja i.O. sein, oder? Als Current Value hat er sich dann auch die 1121.148 eingetragen.

Danke für eure Antworten! :)

Git Base Branch: master - v9.1.1 - 2021-11-16
Build Time: 2021-11-16 07:06
HTML: 11.0.1

[MoosHam]

@jomjol Erstmal vielen Dank für das geile Projekt!

Ich habe ebenfalls Probleme mit bestimmten Zahlen bei meinem Stromzähler. Gerne die 6,8 und 9 einfach als 0 erkannt.

Allerdings stelle ich fest, dass das mit der Datei: "/config/dig1210s2q.tflite" deztlich besser funzt (links mit default, rechts mit 1210s2q):

Ich habe das Gefühl, dass je mehr neue Bilder angelernt werden, die Ergebnisse schlechter werden? Kann das sein?
Gibt es eine "einfache" Möglichkeit, sein eigenes KI-Modell zu traininieren, basierend auf dem "eigenen" Zähler?

Vielen Dank, und nochmal: Daumen hoch für dieses geile Projekt!

[jomjol]

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

Hallo zusammen,
habe ich hier ggf. etwas falsches konfiguriert:

Ich verstehe hier nicht warum er unbedingt den Wert auf .148 setzen möchte. Er erkennt ja die .19N Das sollte trotz Prüfung ja i.O. sein, oder? Als Current Value hat er sich dann auch die 1121.148 eingetragen.

Danke für eure Antworten! :)

Git Base Branch: master - v9.1.1 - 2021-11-16
Build Time: 2021-11-16 07:06
HTML: 11.0.1

Hast du "CheckDigitIncreaseConsistency" aktiviert? Das kann bei rein digitalen Zähler zu "unerwarteten" Ergebnisse führen. Bitte abschalten und weiter beobachten.

[jomjol]

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

@jomjol Erstmal vielen Dank für das geile Projekt!

Ich habe ebenfalls Probleme mit bestimmten Zahlen bei meinem Stromzähler. Gerne die 6,8 und 9 einfach als 0 erkannt.

Allerdings stelle ich fest, dass das mit der Datei: "/config/dig1210s2q.tflite" deztlich besser funzt (links mit default, rechts mit 1210s2q):

Ich habe das Gefühl, dass je mehr neue Bilder angelernt werden, die Ergebnisse schlechter werden? Kann das sein?
Gibt es eine "einfache" Möglichkeit, sein eigenes KI-Modell zu traininieren, basierend auf dem "eigenen" Zähler?

Vielen Dank, und nochmal: Daumen hoch für dieses geile Projekt!

Ja es kann sein, dass die unterschiedlichen Versionen unterschiedlich performen und dass eine ältere Version bei dir besser läuft. Daher "never change a running system".
Das Vorgehen und die Algos zum Training sind hier auch veröffentlicht, aber sicher nicht optimal dokumentiert: https://github.com/jomjol/neural-network-digital-counter-readout

[Hc-Yami]

@jomjol habe nun "CheckDigitIncreaseConsistency" deaktiviert, war tatsächlich aktiviert! Ich teste und melde mich zurück. :)

[MoosHam]

@jomjol SUUUPER, hat gut funktioniert, teste gerade meine "eignes" Zählermodel. Habe wie Du das Problem, dass mein Zähler nur eine Nachkommastelle hat, die Auflösung deshalb zu wünschen übrig lässt. Bin mal gespannt, wie deine "virtuelle 2. Nachkommastelle" funktioniert, arbeitest Du da noch dran?

vielen Dank,
MoosHam

[jomjol]

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

@jomjol SUUUPER, hat gut funktioniert, teste gerade meine "eignes" Zählermodel. Habe wie Du das Problem, dass mein Zähler nur eine Nachkommastelle hat, die Auflösung deshalb zu wünschen übrig lässt. Bin mal gespannt, wie deine "virtuelle 2. Nachkommastelle" funktioniert, arbeitest Du da noch dran?

vielen Dank,
MoosHam

Ja, da bin ich noch dran. Ist aber etwas aufwendiger wie gedacht und momentan habe ich etwas wenig Zeit. Aber das nächste größere Release (v10) sollte das dann haben.

[Hc-Yami]

@jomjol leider hat es das wohl noch nicht gebracht.

Von 1211.599 auf 1121.839 ist doch nicht "too high", warum zeigt er das hier an? :/

Danke für deine komemnde Antwort.

Grüße Hc-Yami

[jomjol]

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

@jomjol leider hat es das wohl noch nicht gebracht.

Von 1211.599 auf 1121.839 ist doch nicht "too high", warum zeigt er das hier an? :/

Danke für deine komemnde Antwort.

Grüße Hc-Yami

Das kann ich so nicht beurteilen, denn das hängt davon ab, welchen Wert du in der Config.ini eingestellt hast:

[Mann7]

Polarisationsfilter (linearer Filter reicht)

Hallo,
erst mal herzlichen Dank für das tolle Projekt und die viele bereits geleistete Vorarbeit.

Ich erfasse seit ein paar Tagen mit dem Modul die Werte meines Gaszählers und habe dort auch das Problem mit den Reflexionen der Zahlenrollen selbst und der Glasscheibe davor.

Der erste Ansatz waren 2 externe LED's - das war besser aber auch noch nicht toll - zumal es das kompakte Kamera-Gehäuse zunichte macht, weil dann auch die Positionierung der LED's mit berücksichtigt werden müsste.
Also ein Blick zu den Fotografen geworfen, wie die Reflexionen mit Blitz lösen...

Und der Ansatz heißt: 'Polarisierungsfolie'
Für 'unsere' Kamera und den Blitzt reicht ein normaler linearer Polarisierungsfilter.
Die beiden Folienstücke vor dem Blitz und vor der Kamera müssen dann um 90° zueinander verdreht angebracht werden.

1. Versuch: Nur die Polarisierungs-Filter:
   Da war der Blitz noch immer so stark, dass die Filter nicht geschafft hat alles zu filtern und noch immer Reflexionen da waren.

2. Versuch: Zusätzlich direkt auf den Polarisierungsfilter vor dem Blitz zwischen Filter und LED noch eine Satinato-Folie 'direkt' aufgelegt. (LED, 3mm Abstand zu Satinato-Folie, 0mm Abstand zu Polarisierungsfilter; Kamera: Linse dann 2 mm Abstand zu Polfilter)
   -> Das Ergebnis war schon deutlich besser Diese Kombi nutze ich aktuell.

Als 3. Versuch steht nun noch aus mit 1-2 Satinato-Folien mit Abstand zwischen LED ,Satinato und Filter zu arbeiten. Aber dazu muss ich nochmal ein angepasstes Gehäuse drucken. Platz gibt es ja noch genug vor der Blitz-Led ;-) Ich werde berichten...

Anbei auch 2 Fotos - jeweils vom Kamera in dem Gehäuse und dem Ergebnis-Bild.

[Mann7]

Und noch ein paar Wünsche von mir, das was Coding angeht ;-)
Keine Ahnung, ob das hier richtig aufgehoben ist, oder besser bei Github plaziert wird.

1. Messwerte als Log lokal mit speichern
   Es wäre super, wenn man parallel die Messwerte auch einfach lokal auf der Speicherkarte mit loggen kann ohne das komplette debugging aktivieren zu müssen. Damit wäre das ganze Projekt auch autonom ohne externe Anbindungen nutzbar um mal Daten detaillierter zu analysieren. Und der Zugriff auf die Logfiles ist ja schon sehr schön in der Weboberfläche implementiert.
   Denn wenn's um 'echte Analysen' geht ist man eh schnell in Excel oder Access (oder anderen DB's)
   Wunsch: extra Checkbox in der Konfig für ein Werte-Logging mit 3 Spalten:
   Zeitstempel, Messwert und 'raw Messwert'

2. API-Aufruf 'neutral' gestalten:
   aktuell:
   http://[IP]/wasserzaehler.html
   neutral z.B.
   http://[IP]/messwert.html

3. Für 'analoge' Zählwerke auch 'Zwischenzahlen' anlernen.
   Da insbesondere die 'letzte' Stelle bei analogen Rollenzählwerken in der Regel immer irgendwelche 'Zwischenwerte' auf dem Foto hat kommt es dort oft zu Erkennungsproblemen.
   Idee: Nicht nur 1,2,3,4,5,6,7,8,9,0 anlernen, sondern auch ein oder zwei 'Zwischenzahlen' um die Erkennungsrate zu verbessern.
   Als z.B.
   8,33 als 8
   8,66 als 9
   9 als 9
   9.33 als 9
   9,66 als 0
   0 als 0
   0,33 als 0
   0,66 als 1
   Ich weiß nicht ob da schon mal probiert wurde, in wie fern das klappt oder ob dadurch 'falsch Interpretationen' steigen.
   Evtl. kann man ja auch nur die 'letzte' Stelle jeweils mit diesen 'Zwischenzahlen' abgleichen.
   Alle Stelle davor stehen ja in der Regel 'richtig'

4. Wenn Zahlen nicht erkannt werden diese nicht 'immer 1:1 mit der alten Ziffer auf dieser Stelle ersetzen, sondern auch die Stelle links daneben betrachten. Wenn die Stelle links daneben im Vergleich zum alten Wert gestiegen ist sollte die 'unerkannte' Stelle auf 0 gesetzt werden.

Beispiel:
aktuell:
Raw 1234,16 -> 1234,16
Raw 1234,1N -> 1234,16 -> OK
Raw 1234,19 -> 1234,19
Raw 1234,2N -> 1234,29 -> wird als 1234,29 angezeigt, obwohl in Wirklichkeit z.B.1234,21
Raw 1234,25 -> 1234,29 -> bringt Fehler, da kleiner als Messwert
Wunsch:
Raw 1234,16 -> 1234,16
Raw 1234,1N -> 1234,16 -> OK
Raw 1234,19 -> 1234,19
Raw 1234,2N -> 1234,20 -> wird als 1234,20 angezeigt, da Stelle links von N größer als bei letzter Messung (in Wirklichkeit z.B.1234,21)
Raw 1234,25 -> 1234,25 -> wieder korrekte Messung/Messwerte

Anbei noch ein paar Beispielbilder zu 3)

Vielen Dank und schöne Grüße

[jomjol]

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

Und noch ein paar Wünsche von mir, das was Coding angeht ;-)
Keine Ahnung, ob das hier richtig aufgehoben ist, oder besser bei Github plaziert wird.

1. Messwerte als Log lokal mit speichern
   Es wäre super, wenn man parallel die Messwerte auch einfach lokal auf der Speicherkarte mit loggen kann ohne das komplette debugging aktivieren zu müssen. Damit wäre das ganze Projekt auch autonom ohne externe Anbindungen nutzbar um mal Daten detaillierter zu analysieren. Und der Zugriff auf die Logfiles ist ja schon sehr schön in der Weboberfläche implementiert.
   Denn wenn's um 'echte Analysen' geht ist man eh schnell in Excel oder Access (oder anderen DB's)
   Wunsch: extra Checkbox in der Konfig für ein Werte-Logging mit 3 Spalten:
   Zeitstempel, Messwert und 'raw Messwert'

2. API-Aufruf 'neutral' gestalten:
   aktuell:
   http://[IP]/wasserzaehler.html
   neutral z.B.
   http://[IP]/messwert.html

3. Für 'analoge' Zählwerke auch 'Zwischenzahlen' anlernen.
   Da insbesondere die 'letzte' Stelle bei analogen Rollenzählwerken in der Regel immer irgendwelche 'Zwischenwerte' auf dem Foto hat kommt es dort oft zu Erkennungsproblemen.
   Idee: Nicht nur 1,2,3,4,5,6,7,8,9,0 anlernen, sondern auch ein oder zwei 'Zwischenzahlen' um die Erkennungsrate zu verbessern.
   Als z.B.
   8,33 als 8
   8,66 als 9
   9 als 9
   9.33 als 9
   9,66 als 0
   0 als 0
   0,33 als 0
   0,66 als 1
   Ich weiß nicht ob da schon mal probiert wurde, in wie fern das klappt oder ob dadurch 'falsch Interpretationen' steigen.
   Evtl. kann man ja auch nur die 'letzte' Stelle jeweils mit diesen 'Zwischenzahlen' abgleichen.
   Alle Stelle davor stehen ja in der Regel 'richtig'

4. Wenn Zahlen nicht erkannt werden diese nicht 'immer 1:1 mit der alten Ziffer auf dieser Stelle ersetzen, sondern auch die Stelle links daneben betrachten. Wenn die Stelle links daneben im Vergleich zum alten Wert gestiegen ist sollte die 'unerkannte' Stelle auf 0 gesetzt werden.

Beispiel:
aktuell:
Raw 1234,16 -> 1234,16
Raw 1234,1N -> 1234,16 -> OK
Raw 1234,19 -> 1234,19
Raw 1234,2N -> 1234,29 -> wird als 1234,29 angezeigt, obwohl in Wirklichkeit z.B.1234,21
Raw 1234,25 -> 1234,29 -> bringt Fehler, da kleiner als Messwert
Wunsch:
Raw 1234,16 -> 1234,16
Raw 1234,1N -> 1234,16 -> OK
Raw 1234,19 -> 1234,19
Raw 1234,2N -> 1234,20 -> wird als 1234,20 angezeigt, da Stelle links von N größer als bei letzter Messung (in Wirklichkeit z.B.1234,21)
Raw 1234,25 -> 1234,25 -> wieder korrekte Messung/Messwerte

Anbei noch ein paar Beispielbilder zu 3)

Vielen Dank und schöne Grüße

Die Feature Wünsche bitte in ein GitHub-Issue, dort tracke ich alles. Aber gleich eine "Warnung" vorweg: die meisten Punkte laden erstmal auf der Feature-Request Liste. Dort sind alle Wünsche, die ich aktuell schlicht aus Kapagründen nicht angehe.
Ich bin i.W. der einzige Programmierer und mache das so nebenbei für lau, daher kann ich die vielen guten Ideen nicht immer auch umsetzen.
Falls du mitprogrammieren willst, kannst du gerne einen Folk machen und ich merge dann deine Verbesserungen mit ein.
Beste Grüße,
jomjol

[Mann7]

@jomjol Hi,
ja - das häufige Problem, dass viele den Nutzen aus etwas ziehen wollen, aber nur wenige sich aktiv beteiligen...

Ich bin nicht wirklich ein Hardcore-Programmiere - von daher muss ich mir das mal anschauen, ob ich mich im Coding zurecht finde oder mehr Chaos anrichte ;-)

Aber wenn ich mich zurecht finde und etwas anpasse lasse ich dir natürlich gerne die Änderungen auch zukommen.

Und das eine oder andere Thema lässt sich ja wahrscheinlich sogar relativ einfach und schnell implementieren.
Aber ich weiß schon - viel 'mal einfach und schnell' sind am Ende auch wieder ein paar Stunden ;-)

Schönen Abend