Hallo,

habe heute auf die neue Version 4.0 aktualisiert, aber in der Info steht noch 3.1:

Grüße

Hatte nun noch weitere Probleme:

Daten waren in MySQL und in InfluxDB als unterschiedliche Formate gespeichert und teilweise hatten sich in MySQL die Datentypen über die Zeit geändert, sodass ein Messwert in mehreren Datentabellen (z.B. ts_number & ts_string) vorhanden war.
Da das Skript den Datentyp über die Quelltabelle ermittelt (ts_number => Zahl, ts_bool => Wahrheitswert, ts_string => Zeichenfolge) führt dieses zu Problemen.
In der Übersichtstabelle (datapoints) gibt es nur eine Angabe des Datentypes. Diese ist in meinen Auge der aktuell gewünschte Datentyp. Daher habe ich das Skript um eine Abfrage des Datentypes aus datapoints erweitert und eine Konvertierung in diesen Datentyp eingebaut.
Nun können Daten z.B. in den Tabellen ts_string und ts_number vorliegen. Bei der Migration werden die Daten dann in den Datentyp konvertiert, der in datapoints angegeben ist.
Damit reicht es das InfluxDB und MySQL für jeden Wert den gleichen Datentypen verwenden.

Da ich früher meist als Datentyp "Automatisch" angegeben hatte, konnte dieses hier zu Problemen führen. Nach dem ich alle Datentypen händisch gerade gezogen habe, teilweise direkt in der MySQL-Datenbank, funktionierte die Migration mit der Skriptanpassung problemlos.

Meine Änderungen des Skriptes sind in einem Fork abgelegt und einen Pull request habe ich gestellt.

Aus meiner Sicht könnte man nun noch als Anpassung vornehmen, das er den gewünschten Datentypen nicht aus der MySQL-Datenbank bezieht, sondern aus der InfluxDB, wenn man vorher den Wert dort bereits über iobroker eingefügt hat.

In Summe nochmal danke für das Skript, es hat mir sehr weiter geholfen.

Hatte nun noch weitere Probleme:

Daten waren in MySQL und in InfluxDB als unterschiedliche Formate gespeichert und teilweise hatten sich in MySQL die Datentypen über die Zeit geändert, sodass ein Messwert in mehreren Datentabellen (z.B. ts_number & ts_string) vorhanden war.
Da das Skript den Datentyp über die Quelltabelle ermittelt (ts_number => Zahl, ts_bool => Wahrheitswert, ts_string => Zeichenfolge) führt dieses zu Problemen.
In der Übersichtstabelle (datapoints) gibt es nur eine Angabe des Datentypes. Diese ist in meinen Auge der aktuell gewünschte Datentyp. Daher habe ich das Skript um eine Abfrage des Datentypes aus datapoints erweitert und eine Konvertierung in diesen Datentyp eingebaut.
Nun können Daten z.B. in den Tabellen ts_string und ts_number vorliegen. Bei der Migration werden die Daten dann in den Datentyp konvertiert, der in datapoints angegeben ist.
Damit reicht es das InfluxDB und MySQL für jeden Wert den gleichen Datentypen verwenden.

Da ich früher meist als Datentyp "Automatisch" angegeben hatte, konnte dieses hier zu Problemen führen. Nach dem ich alle Datentypen händisch gerade gezogen habe, teilweise direkt in der MySQL-Datenbank, funktionierte die Migration mit der Skriptanpassung problemlos.

Meine Änderungen des Skriptes sind in einem Fork abgelegt und einen Pull request habe ich gestellt.

Aus meiner Sicht könnte man nun noch als Anpassung vornehmen, das er den gewünschten Datentypen nicht aus der MySQL-Datenbank bezieht, sondern aus der InfluxDB, wenn man vorher den Wert dort bereits über iobroker eingefügt hat.

In Summe nochmal danke für das Skript, es hat mir sehr weiter geholfen.

Habe den Messwert nun aus der DB gelöscht und ihn über den Adapter in iobroker neu angelegt. Nun hat er nur noch einen value als boolean. Damit war der Datentransfer nun möglich.

@JackGruber
Mmh, das hat nicht ganz geklappt.
Habe es versucht, dann kam folgende Fehlermeldung:

wolf.0.cwl.158(ID: 98) (1/1)
Processing row 1 to 1,000 from LIMIT 0 / 100,000 ts_bool - wolf.0.cwl.158 (1/1)
InfluxDB error
400: {"error":"partial write: field type conflict: input field \"value\" on measurement \"wolf.0.cwl.158\" is type float, already exists as type boolean dropped=219"}

Dachte auch das die Daten in MySQL in float sind und ich diese nach InfluxDB als boolean überführen muss, also habe ich die Zeile angepasst:

fields["value"] = bool(record["value"])

Zu meiner Überraschung bekam ich dann folgende Meldung:

wolf.0.cwl.158(ID: 98) (1/1)
Processing row 1 to 1,000 from LIMIT 0 / 100,000 ts_bool - wolf.0.cwl.158 (1/1)
InfluxDB error
400: {"error":"partial write: field type conflict: input field \"value\" on measurement \"wolf.0.cwl.158\" is type boolean, already exists as type float dropped=148"}

Nun war ich verwundert, ist value nun ein float oder ein boolean in InfluxDB? Also habe ich mir den Aufbau in Influx angesehen mit folgendem Ergebnis:

name: wolf.0.cwl.158
fieldKey fieldType
-------- ---------
ack      boolean
from     string
q        float
value    boolean
value    float

value gibt es zweimal. Für mein Verständnis sollte es nur einmal da sein. Muss ich da die InfluxDB erst fixen?

@JackGruber Es sind nur 0 und 1 enthalten, deine Abfrage liefert also keine Zeilen zurück.

Hallo,

erstmal vielen Dank für das Skript.

ts_numeric lässt sich ohne Probleme überführen, aber mit bool gibt es Probleme. Scheinbar sind die Daten in der Quelle nicht als bool sondern als float abgelegt. Daher wird eine Konvertierung nach boolean benötigt. Was muss an dem Skript angepasst werden, damit ts_bool vor der Überführung entsprechen konvertiert wird?

Total metrics in ts_bool: 1
wolf.0.cwl.158(ID: 98) (1/1)
Processing row 1 to 1,000 from LIMIT 0 / 100,000 ts_bool - wolf.0.cwl.158 (1/1)
InfluxDB error
400: {"error":"partial write: field type conflict: input field \"value\" on measurement \"wolf.0.cwl.158\" is type float, already exists as type boolean dropped=200"}

Grüße

Hallo,

habe heute auf die neue Version 4.0 aktualisiert, aber in der Info steht noch 3.1:

Grüße

@Zwer2k
Danke, habe die Karte nochmal formatiert und die Daten wieder drauf kopiert, nun geht es.

@jomjol

Es stand auf Model=/config/dig0640s3.tflite und die Datei ist auch vorhanden.

Habe dann noch die Datei dig0650s3.tflite runter geladen und die config.ini entsprechend aktualisiert. Der Fehler bleibt aber.

Hallo,

erstmal vielen Dank für die tolle Arbeit an dem Projekt.
Bisher hatte ich mehrere Versionen im Einsatz. Leider durch schlechte WLAN Verbindung nicht wirklich produktiv. Da habe ich nun nachgerüstet → externe Antenne an der ESP32CAM. Die Verbindung ist nun deutlich besser und ich habe auf die aktuelle Version mit MQTT aktualisiert.
Nun stehe ich bei folgendem Problem, das er die Zahlen und Zeiger nicht mehr erkennt.

Hat da jemand einen Tipp für mich?

Grüße

@SVallant

ja, ich hätte aber gerne auch das flot über die ganze Breite, auch wenn danach noch was anderes kommt. Also nicht immer, nur wenn es von mir so gesetzt ist. Bräuchte also im Widget eine Option, die eine Streckung auf die gesamte Breite fordert.