InfluxDB: History Ersatz schreibt keine String Werte?

[apollon77]

Schau mal in den Einstellungen von dem Datenpunkt bei InfluxDB. Da kannst du den datentyp vorgeben. Bzw gibt das log was her?

[PerfectAnswer]

Der Datentyp ist schon auf string gestellt.

Früher gab es eine WebGUI für influxdb die unter localhost:8083 erreichbar war. In der aktuellen Version gibt es die aber nicht mehr

Gibt es noch alternative Ideen?

[apollon77]

Das ist der Typ des Objekts. Ich meine das was bei dir unter "storageType" steht und das ist leer. Das heißt das er das nimmt was kommt.

Ich würde schauen was in der db landet. Die alternative zur Web ui von InfluxDB ist das Konsolenkommando "influx". Da kannst du queries absetzen.

Weiterhin kannst du ggf den Adapter mal in Debug laufen lassen (Adapter - expertenmodus - loglevel auf Debug) dann schauen was ggf noch für logausgaben kommen bzw gibt es sonst logausgaben die relevant sind?

Bei mir werden strings geschrieben.

[PerfectAnswer]

Das mit dem Debug war schon mal ein guter Hinweis.

influxdb.0	2017-09-24 21:45:01.056	debug	redis pmessage io.* io.javascript.0.OpenWeather.0.Icon {"val":"http://openweathermap.org/img/w/10n.png","ack":false,"ts":1506282301031,"q":0,"from":"system.adapter.javascript.0","lc":1506265200340}

das ack:false sollte schon true sein, ist es aber bei allen String-Werten nicht.

Der val wird auch als string übergeben, aber anscheinend gefällt es der influxdb nicht…

Ich habe das mal paralell in die history.0 laufen, da gibt es keine Probleme; was aber auch zu erwarten war.

Eigentlich besteht doch der Charme der influxdb genau darin, dass eben nicht vorher ein Datentyp festgelegt wird.

Was die Konsolenanwendung angeht, da fehlt mir der Skill was die Abfragen angeht.

[apollon77]

Ack ist beides ok (true und false) und wird auch korrekt geloggt.

> Eigentlich besteht doch der Charme der influxdb genau darin, dass eben nicht vorher ein Datentyp festgelegt wird.
Ich weiss nicht was Du genau meinst. Der Datentyp ist bei InfluxDB quasi nach dem ersten Schreiben fest gelegt und es gibt Schreibfehler wenn er geändert wird danach (ok Formal "für den aktuellen Shard")! ALso wenn Du dachtest das InfluxDB den Datentyp nie festlegt und da flexibel ist ist das falsch!

Auch interessant ist das eigentlich "null" als Wert in der InfluxDB nicht erlaubt ist. Ich habe mal bei mir geschaut … es wird bei Strings im Admin auch "null" angezeigt ... also ... Lass es Dir doch mal mit Grafana anzeigen und denke wird tun

[apollon77]

Du hast da nen Bug gefunden, gratuliere!

Die "getHistory-Funktion" hat die Werte immer in Zahlen umgewandelt. Und da kommt bei Texten halt "null" raus

Versuch mal die neueste Version vom GitHub

[PerfectAnswer]

Dann macht es ja auch Sinn, dass Grafana 'null' anzeigt, denn null ist als 'null' String in die DB geschrieben worden. Klassiker…

Ich habe das gerade aktualisiert und jetzt landen alle Strings in der DB

Vielen Dank für Deinen Einsatz :!:

[apollon77]

@PerfectAnswer:

Dann macht es ja auch Sinn, dass Grafana 'null' anzeigt, denn null ist als 'null' String in die DB geschrieben worden. Klassiker… `
Interessant, das sollte nur vorkommen wenn wirklich "Null" als String dort landet! Daran hab ich nichts geändert. Ichhabe nur Änderungen beim lesen per "getHistory"-Funktion gemacht.

Aber wenn es jetzt tut ist ja super

[PerfectAnswer]

@apollon77:

Interessant, das sollte nur vorkommen wenn wirklich "Null" als String dort landet! `

in der main.js ist das hier doch raus geflogen:````
Math.round(rows[qr][rr].val * adapter.config.round

wenn dort ein string im .val steht kam vermutlich null raus und dieser Wert wurde dann als string "null" in die db geschrieben.

Meine Theorie :)

Aber egal, ich bin Happy das es nun läuft und die Welt wieder ein bisschen besser geworden ist - ein bug weniger :lol:

[apollon77]

@PerfectAnswer:

@apollon77:

Interessant, das sollte nur vorkommen wenn wirklich "Null" als String dort landet! `

in der main.js ist das hier doch raus geflogen:Math.round(rows[qr][rr].val * adapter.config.round `
Jupp, aber im Codeteil von "getHistory" … also in der DB steht es an sich korrekt nur beim auslesen wird es zu "Null"