NEWS
Wasserzähler - Version 2 - all-in-device
-
Hallo zusammen.
Folgendes Problem:
2 Wasseruhren
MQTT Adapter (1 Instanz)Schreiben in die Influx mit Alias:
wasserzaehler-garten = Influs ID alias = Wasser-CAM-Garten
wasserzaehler-haus = Influs ID alias = Wasser-CAM-HausWenn von Wasseruhr Garten mal ein falscher Wert kommt zB: 5N55N kommt ein Fehler im iobroker Protokoll:
warn: influxdb.0 (938) Error on writePoint("{"value":"5N55N","time":"2023-05-09T21:14:06.561Z","from":"system.adapter.mqtt.0","q":0,"ack":true}): HttpError: failure writing points to database: partial write: field type conflict: input field "value" on measurement "Wasser-CAM-Haus" is type string, already exists as type float dropped=1 / "failure writing points to database: partial write: field type conflict: input field \"value\" on measurement \"Wasser-CAM-Haus\" is type string, already exists as type float dropped=1"" {1}
Ab dem Zeitpunkt werden KEINE weiteren Werte mehr gespeichert.
Die Alias von Wasser-CAM-Haus wird plötzlich in Wasser-CAM-Garten geänderter (vom iobroker oder Adapter).
Warum wird der Wert nicht einfach verworfen und die nächste Zahl wieder geschrieben.
Warum wird einfach der Alias Name geändert? -
@bitwicht , Fehler/Log Ausgaben bitte in der Code Box posten.
-
@bitwicht , auf welche Firmware bezieht sich das? Neuste? Sonst zurück flashen.
Ich kann nach wie vor diese empfehlen: Release: v15.0.1 (Commit: 22e4b39+)
und InfluxDB gehört hier nicht hin, ganz andere Baustelle. -
Die Uhren haben die Firmware: Release: v15.1.0 (Commit: 7d33c3e+)
Hier ein Auszug aus dem Log.
Die Cam sendet einfach 5N55N obwohl es ja eine Zahl sein müsste.
Der iobrokr erwartet einen Zahl die er in die Influx schreiben kann, erhält aber 5N55N.Die Frage ist, warum die CAM bei einer fehlerhaften Erkennung den Wert nicht verwirft?
Warum der iobroker oder adapter dann so blöd reagiert wäre an anderer stelle zu prüfen.
[8d07h54m42s] 2023-05-09T23:13:51 <WRN> [CNN] Value Rejected due to Threshold (Fit: 0.496610, Threshold: 0.500000) [8d07h54m57s] 2023-05-09T23:14:05 <WRN> [CNN] Value Rejected due to Threshold (Fit: 0.477635, Threshold: 0.500000) [8d07h54m57s] 2023-05-09T23:14:06 <ERR> [POSTPROC] main: Raw: 5N55N, Value: , Status: Neg. Rate - Read: - Raw: 5N55N - Pre: 78195 [8d07h59m48s] 2023-05-09T23:18:57 <ERR> [POSTPROC] main: Raw: 00196, Value: , Status: Neg. Rate - Read: - Raw: 00196 - Pre:
-
@bitwicht , wurde die Cam überhaupt eingerichtet. Wenn der Setup Durchlauf nicht richtig abgeschlossen wurde, passiert genau sowas. Weil die Zahlen nicht richtig erkannt werden.
Wurden überhaupt die Marker und die Rois richtig ausgerichtet?
Poste mal die Auschnitte der Uhren. -
Das setup ist gelaufen.
Die Ausrichtung der Uhr ist nicht ganz perfekt da es bei der kleinen Uhr irgendwie schwieriger ist wie bei der großen uhr.Aber es kann doch immer mal vorkommend das die Zahl nicht erkannt wird.
Das würde heißen, dass es dann immer meine Datenbank zerschießt - kann ja nicht sein.
Ich würde erwarten, dass die Uhr dann einfach keine Daten zur Verfügung stellt.So alle 5-8 Tage kommt der Fehler einmal, was mir egal wäre wenn die Uhr nicht alles "zerschießt".
-
@bitwicht , kein Wunder. Die Roi`s sind unterschiedlich groß, nicht vernünftig in einer Reihe und dermaßen unscharf.....von den Markern ganz zu schweigen. Am besten du fängst von vorn an und machst die Einstellungen gewissenhaft....so wird das nichts. Zudem ist das Bild nicht gerade ausgerichtet. So ein schlechtes Bild sieht man hier selten....ach noch was, du hast eine unheimliche Schattenbildung. Den würde ich auch nach gehen. Man sieht teilweise doppelt und dreifach.
Hier eine Referenz zu deinem....Auch deine Pre ist falsch. Wahrscheinlich verkehrt eingetragen. RAW stimmt
-
wie gesagt das ist kein große Uhr (die ist sauber) sondern eine kleine Uhr.
Aber das ist doch auch "egal".
Das heißt. Wenn es perfekt ausgerichtet ist und es dann mal einen Fehler gibt zerschießt es immer die Datenbank.
Keine sehr resiliente Lösung .... -
@bitwicht , du hast mein Beitrag nicht verstanden. Warum deine Datenbank hopps geht, keine Ahnung. Nehme an, weil die Zahlen nicht richtig erkannt werden und NNN eingetragen wird und nicht damit umgehen kann.
Ich bin raus hier.
-
du schreibst ich soll das Setup neu durchlaufen bzw. schauen das ich ein sauberes Bild habe.
OK, kann ich machen.Der Kern des Problems wird nicht gelöst.
Was ist wenn dann die perfekt ausgerichtete Kamera ein mal einen Wert falsch erzeugt.
Dann wird es an den iobroker gesendet, der schreibt ein String (bzw. stellt die influx um) obwohl da ein Float hingehört.2023-05-09 23:14:06.436 - info: mqtt.0 (1034) Server: Changed type of "mqtt.0.wasserzaehler-garten.main.raw" from "number" to "string" 2023-05-09 23:14:06.473 - info: influxdb.0 (938) enabled logging of Wasser-CAM-Haus, Alias=true 2023-05-09 23:14:06.625 - warn: influxdb.0 (938) Point could not be written to database: iobroker 2023-05-09 23:14:06.625 - warn: influxdb.0 (938) Error on writePoint("{"value":"5N55N","time":"2023-05-09T21:14:06.561Z","from":"system.adapter.mqtt.0","q":0,"ack":true}): HttpError: failure writing points to database: partial write: field type conflict: input field "value" on measurement "Wasser-CAM-Haus" is type string, already exists as type float dropped=1 / "failure writing points to database: partial write: field type conflict: input field \"value\" on measurement \"Wasser-CAM-Haus\" is type string, already exists as type float dropped=1"" 2023-05-09 23:14:06.626 - warn: influxdb.0 (938) Add Wasser-CAM-Haus to conflicting Points (1 now) 2023-05-09 23:14:06.631 - warn: influxdb.0 (938) setObject Wasser-CAM-Haus (type=undefined) property common.custom must not exist. 2023-05-09 23:14:06.641 - info: influxdb.0 (938) disabled logging of Wasser-CAM-Haus 2023-05-09 23:14:06.643 - info: influxdb.0 (938) changed history configuration to pin detected datatype for Wasser-CAM-Haus 2023-05-09 23:15:00.111 - info: javascript.0 (957) script.js.Strom_Shelly_Verbrauchs-Historie: Shelly Verbrauch: Verbrauchswerte aktualisiert: 18 | Reboots korrigiert: 0 | Unveränderte Werte: 59 2023-05-09 23:18:57.841 - info: mqtt.0 (1034) Server: Changed type of "mqtt.0.wasserzaehler-garten.main.raw" from "string" to "number" 2023-05-09 23:18:57.847 - info: influxdb.0 (938) enabled logging of Wasser-CAM-Haus, Alias=true 2023-05-09 23:18:57.861 - warn: influxdb.0 (938) Point could not be written to database: iobroker 2023-05-09 23:18:57.862 - warn: influxdb.0 (938) Error on writePoint("{"value":"5N55N","time":"2023-05-09T21:18:57.848Z","from":"system.adapter.influxdb.0","q":0,"ack":true}): HttpError: failure writing points to database: partial write: field type conflict: input field "value" on measurement "Wasser-CAM-Haus" is type string, already exists as type float dropped=1 / "failure writing points to database: partial write: field type conflict: input field \"value\" on measurement \"Wasser-CAM-Haus\" is type string, already exists as type float dropped=1"" 2023-05-09 23:18:57.862 - warn: influxdb.0 (938) Add Wasser-CAM-Haus to conflicting Points (1 now) 2023-05-09 23:18:57.867 - warn: influxdb.0 (938) setObject Wasser-CAM-Haus (type=undefined) property common.custom must not exist. 2023-05-09 23:18:57.871 - info: influxdb.0 (938) disabled logging of Wasser-CAM-Haus 2023-05-09 23:18:57.872 - info: influxdb.0 (938) changed history configuration to pin detected datatype for Wasser-CAM-Haus {1}
Für mich ganz klar das es an 2 Stellen ein Bug gibt:
- die CAM darf nur Zahlen (Float) senden, wenn sie Buchstaben erkennt kann sie ja einen Fehler in das Log schreiben, aber darf nicht per MQTT senden
- im iobroker oder influd adapter (weiß nicht geanu wer das auslöst) gehört gefixed, dass ankommenden "müll" verworfen wird. Also sendet die CAM "müll" muss der iobroker das wegwerfen und darf nicht einfach die DB "umstellen".
somit wäre das ganze System etwas resilienter ...
-
@bitwicht , ich habe dir schon mal geschrieben, das InfluxDB hier nicht hin gehört. Beschwere dich bei InfluxDB.....und nicht hier. Ich betreibe das nicht.
-
@bitwicht sagte in Wasserzähler - Version 2 - all-in-device:
Für mich ganz klar das es an 2 Stellen ein Bug gibt:
- die CAM darf nur Zahlen (Float) senden, wenn sie Buchstaben erkennt kann sie ja einen Fehler in das Log schreiben, aber darf nicht per MQTT senden
- im iobroker gehört gefixed, dass ankommenden "müll" verworfen wird. Also sendet die CAM "müll" muss der iobroker das wegwerfen und darf nicht einfach die DB "umstellen".
Das ist Quatsch, es werden nur korrekte Daten über MQTT gesendet. Dann stimmen deine Einstellungen nicht. Wenn bei mir was falsch läuft, werden die Daten erst garnicht aktualisiert und das ist Standard und schon immer so gewesen.
-
ich habe dir doch oben die Los geschrieben:
CAM:
[8d07h54m57s] 2023-05-09T23:14:06 <ERR> [POSTPROC] main: Raw: 5N55N, Value: , Status: Neg. Rate - Read: - Raw: 5N55N - Pre: 78195
Die CAM erzeugt 5N55N und sent dies pr MQTT an den iobroker.
iobroker:
2023-05-09 23:14:06.436 - info: mqtt.0 (1034) Server: Changed type of "mqtt.0.wasserzaehler-garten.main.raw" from "number" to "string" 2023-05-09 23:14:06.473 - info: influxdb.0 (938) enabled logging of Wasser-CAM-Haus, Alias=true 2023-05-09 23:14:06.625 - warn: influxdb.0 (938) Point could not be written to database: iobroker 2023-05-09 23:14:06.625 - warn: influxdb.0 (938) Error on writePoint("{"value":"5N55N","time":"2023-05-09T21:14:06.561Z","from":"system.adapter.mqtt.0","q":0,"ack":true}): HttpError: failure writing points to database: partial write: field type conflict: input field "value" on measurement "Wasser-CAM-Haus" is type string, already exists as type float dropped=1 / "failure writing points to database: partial write: field type conflict: input field \"value\" on measurement \"Wasser-CAM-Haus\" is type string, already exists as type float dropped=1"" 2023-05-09 23:14:06.626 - warn: influxdb.0 (938) Add Wasser-CAM-Haus to conflicting Points (1 now)
Der iobroker bekommt die Daten, merkt das es keine zahl mehr ist und stellt die influx um. Will schreiben aber die Influx sagt das sie eine Zahl erwartet und plötzlich ein Buchstabe kommt.
Die CAM sendet "plötrzlich" ganz klar 5N55N (string statt float)
Genau das könnte die CAM-Software abfangen.
-
@bitwicht, ich möchte dein MQtt Ordner sehen.
Bei mir erscheint ein error wenn was verkehrt gelesen wird und es wird kein Wert aktualisert.
Wo hast du das her? Du nimmst anscheinend einen falschen Wert. Ich habe das noch nie beobachtet. -
ich finde unter Setting, Configuration, Expert Mode keine Einstellung bei der ich einstellen kann das per MQTT nur Zahlen versendet werden aber keine Buchstaben
-
ich nehme den RAW Wert
-
@bitwicht , was hat das mit Buchstaben zu tun, es werden beim ERORR keine Daten aktualisert....zum letzte mal jetzt. Dann bin ich raus hier. Wo steht denn das N dann. In welcher Zeile.
-
Aber das Log (iobroker) sagt doch das es 5N55N von der CAM erhält.
Das deutet doch darauf hin, dass die Cam den Wert auch sendet. Woher soll es denn sonst kommen?
im Cam Log steht vor dem Eintrag <ERR>
Du sagst dann sendet die Cam nichts.Aber der iobroker bekommt die Daten.
Vergleiche die Uhrzeit, die passt exakt.Ich würde denken, dass hier der BUG ist.
Es scheint, als sendet die CAM eben doch die Daten die sie als ERR erkennt.CAM: 2023-05-09T23:14:06 <ERR> ------> iobroker: 2023-05-09 23:14:06.436
-
@bitwicht , das ist absolut egal das Log. Das ist für die Fehlersuche und nochmal:
Es werden keine Werte übertragen bzw. aktualisiert, wenn ein Fehler vorhanden ist.......und flash die Firmware die ich für gut befunden habe....ich habe das Change Log nicht gelesen.
Vielleicht ist oder war da was. So ein Theater hier.Falls dort was war, dann ein Issue auf dem Github anlegen.
und ein Feedback nach der Erstellung hier posten. -
Ich verstehe deine Reaktion leider nicht.
Die Cam schreibt 2023-05-09T23:14:06 den ERR (Fehler) 5N55N
Der iobroker bekommt 23:14:06.436 die Daten und will es in die influx speichert die den Fehler wirft.
value":"5N55N","time":"2023-05-09T21:14:06.561Z","from":"system.adapter.mqtt.0
WERT 5N55N VOM MQTT Adapter -> und das ist die CAM
Es wird also dieser Wert übertragen. (keine Ahnung ob das jetzt als Fehler gewertet wird oder nicht).
Deine genannte ältere FW kann ich testen ..