Wo nimmt der SQL-Adapter die Datentypen her?

[Bluefox]

@Thisoft:

Wenn ich Zeile 559 ändere wie folgt funktioniert die Sache:

            //if (f.toString() == sqlDPs[_id].state.val) {
           if (f == parseFloat(sqlDPs[_id].state.val)) {

Hättest Du dagegegen Einwände?

Trotzdem bleibt die eigentliche Frage: Warum wird der Datentyp nicht vom Typ des Datenpunkts vererbt?

Gruß Thilo Dein Kode funktioniert nicht. > Trotzdem bleibt die eigentliche Frage: Warum wird der Datentyp nicht vom Typ des Datenpunkts vererbt? `
Weil die Leute es nicht pflegen. Und ich habe Gegenfrage: warum obwohl gesagt war, dass es ein Number ist wird trotzdem string geschrieben?

[Thisoft]

Ja, Sorry - mein Vorschlag war Unsinn.

Aber so würde es funktionieren (und vermutlich auch etwas Sinn ergeben )

if (!isNaN(sqlDPs[_id].state.val))

` > Trotzdem bleibt die eigentliche Frage: Warum wird der Datentyp nicht vom Typ des Datenpunkts vererbt?

Weil die Leute es nicht pflegen. Und ich habe Gegenfrage: warum obwohl gesagt war, dass es ein Number ist wird trotzdem string geschrieben? `

Deine Gegenfrage ist ja meine eigentliche Hauptfrage vom Anfang:

Warum ist

typeof sqlDPs[_id].state.val
````im Adapter = 'string' obwohl doch der DAtenpunkt eindeutig type:number ist (siehe mein 1.Posting)? Ich hatte gehofft, dass Du diese Frage besser beantworten kannst als ich ;)

[paul53]

Wenn common.type = "number" deklariert es, bedeutet es nicht, dass state.val auch einen Wert vom Typ "number" enthält. Man kann auch einen String in den Datenpunkt schreiben, denn es erfolgt keine Typprüfung - nur der JS-Adapter liefert neuerdings eine Warnung.

[Thisoft]

Achso - jetzt verstehe ich. Aus irgend einem Grund ist ioBroker wohl mit meinem Wert den ich (über MQTT-Adapter) für den Datenpunkt liefere nicht so recht zufrieden und schreibt dann einfach einen String in den als Number definierten DP - richtig?

Wenn das wirklich so ist - brrrr einfach grauslich diese ganzen impliziten Typkonvertierungen die sich Javascript da selbständig ausdenkt. Ich hatte ja anfangs gehofft, dass Javascript und ich doch noch Freunde werden, aber leider erhält diese Freundschaft immer wieder schmerzhafte Fußtritte

Dann vermute ich als Erstes, dass ich Komma und Punkt in den Dezimalwerten austauschen muss…

Trotzdem Vielen Dank für Eure Hilfe.

[paul53]

@Thisoft:

Aus irgend einem Grund ist ioBroker wohl mit meinem Wert den ich (über MQTT-Adapter) für den Datenpunkt liefere nicht so recht zufrieden und schreibt dann einfach einen String in den als Number definierten DP - richtig? `
Da es sich um Datenpunkte des MQTT-Adapters handelt, ist wohl der Adapter oder die eigentliche Quelle Ursache für den Typ "string".

[Thisoft]

Ja, wie gesagt. Ich gehe davon aus dass da über MQTT das "falsche" Dezimaltrennzeichen ankommt weil es nur bei den DP's passiert wo Dezimalwerte übertragen werden. Muss ich mir anschauen wenn ich wieder zuhause bin.

Aber um auf den Einwand von Bluefox dass "die Leute es nicht pflegen" zurückzukommen. Die Aussage ist sicherlich berechtigt, da ein "Nichtprogrammierer" vermutlich gar nicht wirklich weiß was er da pflegen soll. Und für Leute wie mich die eben andere Programmiersprachen gewohnt sind ist es auch nicht so einfach etwas zu pflegen wenn man keine Information bekommt dass was falsch läuft und stattdessen Javascript selbständig was zusammenmurkst was nicht zusammengehört. Woher soll ich eigentlich wissen, welches Dezimaltrennzeichen hier z.B. erwartet wird damit alles korrekt erkannt wird - das aus den Systemeinstellungen auf dem ioBroker-Host? oder ganz allgemein das englisch/amerikanische? oder ist das eine JS-Grundeinstellung? Noch schlimmer wird's dann mit Datums-/Zeitformaten…

Nix für ungut - vielleicht wäre es ja überlegenswert für zukünftige Verbesserungen in ioBroker die lobenswerter Weise in den JS-Adapter eingebaute Typprüfung systemweit auszubauen. Der Bedarf bzw. Sinn wurde ja offensichtlich bereits erkannt

Viele Grüße

Thilo

[paul53]

@Thisoft:

vielleicht wäre es ja überlegenswert für zukünftige Verbesserungen in ioBroker die lobenswerter Weise in den JS-Adapter eingebaute Typprüfung systemweit auszubauen. `
Das hatte ich bereits per http://iobroker.net:8000/projects/CONTROLLER/issues/CONTROLLER-7?filter=allopenissues vorgeschlagen, scheint aber Probleme bei der Umsetzung zu machen.

[Bluefox]

> Nichtprogrammierer" vermutlich gar nicht wirklich weiß was er da pflegen soll
Die Verantwortung liegt an der Adapter-Entwickler und das kann schlecht "Nichtprogrammierer" sein

Übrigens wer ist da für MQTT verantwortlich?…

Schande, wieder ich.

Keine Panik. Ich kriege das hin:

 `var _val = val.replace(',', '.').replace(/^\+/, '');

if (_val.indexOf('.') !== -1) {
	var i = _val.length - 1;
	while (_val[i] === '0') i--;
	if (_val[i] === '0') _val = _val.substring(0, i + 1);
}

if (parseFloat(_val) == _val)...`[/i][/i]

[Thisoft]

Hallo Bluefox,

da habe ich nun versucht, lang und breit diplomatisch darum herumzureden wer für das Problem verantwortlich ist. Und jetzt kommst Du und sagst einfach Du wärst der Schuldige :lol:

Es sieht wohl so aus, dass das wirklich im MQTT-Adapter gefixt werden muss. Soweit mir bekannt ist werden ja die MQTT-Topics generell als String verschickt, so dass dann der MQTT-Adapter erst wieder die Zahlenwerte "herausfischen" muss. Was ja offensichtlich bei Ganzzahlen auch funktioniert, nur die Floats erkennt er eben noch nicht als Zahlenwert.

Aber ich bin auch zuversichtlich dass Du das hinbekommst

[paul53]

Da offenbar niemand als Adapter-Entwickler perfekt ist, halte ich es für sinnvoll, den js-controller soweit rund zu machen (Typprüfung / Min-, Max-Korrektur bei Typ "numbers"), dass man bei der Adapter-Entwicklung auf mögliche Fehler per Warnung hingewiesen wird und sich so entsprechende Fehler leichter vermeiden lassen.

[Bluefox]

@Thisoft:

Hallo Bluefox,

da habe ich nun versucht, lang und breit diplomatisch darum herumzureden wer für das Problem verantwortlich ist. Und jetzt kommst Du und sagst einfach Du wärst der Schuldige :lol:

Es sieht wohl so aus, dass das wirklich im MQTT-Adapter gefixt werden muss. Soweit mir bekannt ist werden ja die MQTT-Topics generell als String verschickt, so dass dann der MQTT-Adapter erst wieder die Zahlenwerte "herausfischen" muss. Was ja offensichtlich bei Ganzzahlen auch funktioniert, nur die Floats erkennt er eben noch nicht als Zahlenwert.

Aber ich bin auch zuversichtlich dass Du das hinbekommst `
Kannst du vom git die Version ausprobieren?

[Thisoft]

Habe ausprobiert. Sieht gut aus:

mqtt.0 2016-07-19 23:03:51.209 debug mqtt.0 Send to client [GrillDuino01] "GrillDuino01/Licht": 72 
mqtt.0 2016-07-19 23:03:51.209 debug mqtt.0 onStateChange mqtt.0.GrillDuino01.Licht: {"val":72,"ack":true,"ts":1468962231193,"q":0,"from":"system.adapter.mqtt.0","lc":1468962180849} 
mqtt.0 2016-07-19 23:03:51.209 debug mqtt.0 stateChange mqtt.0.GrillDuino01.Licht: {"val":72,"ack":true,"ts":1468962231193,"q":0,"from":"system.adapter.mqtt.0","lc":1468962180849} 
mqtt.0 2016-07-19 23:03:51.209 debug inMem message *Grill* mqtt.0.GrillDuino01.Licht 
mqtt.0 2016-07-19 23:03:51.177 debug mqtt.0 Send to client [GrillDuino01] "GrillDuino01/TemperaturBack2": 7 
mqtt.0 2016-07-19 23:03:51.177 debug mqtt.0 onStateChange mqtt.0.GrillDuino01.TemperaturBack2: {"val":7,"ack":true,"ts":1468962231162,"q":0,"from":"system.adapter.mqtt.0","lc":1468962231162} 
mqtt.0 2016-07-19 23:03:51.177 debug mqtt.0 stateChange mqtt.0.GrillDuino01.TemperaturBack2: {"val":7,"ack":true,"ts":1468962231162,"q":0,"from":"system.adapter.mqtt.0","lc":1468962231162} 
mqtt.0 2016-07-19 23:03:51.177 debug inMem message *Grill* mqtt.0.GrillDuino01.TemperaturBack2 
mqtt.0 2016-07-19 23:03:51.177 debug mqtt.0 Server received "GrillDuino01/Licht" (number): 72 
mqtt.0 2016-07-19 23:03:51.177 debug mqtt.0 Send to client [GrillDuino01] "GrillDuino01/TemperaturBack1": 9 
mqtt.0 2016-07-19 23:03:51.146 debug mqtt.0 onStateChange mqtt.0.GrillDuino01.TemperaturBack1: {"val":9,"ack":true,"ts":1468962231115,"q":0,"from":"system.adapter.mqtt.0","lc":1468962210959} 
mqtt.0 2016-07-19 23:03:51.146 debug mqtt.0 stateChange mqtt.0.GrillDuino01.TemperaturBack1: {"val":9,"ack":true,"ts":1468962231115,"q":0,"from":"system.adapter.mqtt.0","lc":1468962210959} 
mqtt.0 2016-07-19 23:03:51.146 debug mqtt.0 Server received "GrillDuino01/TemperaturBack2" (number): 7 
mqtt.0 2016-07-19 23:03:51.146 debug inMem message *Grill* mqtt.0.GrillDuino01.TemperaturBack1 
mqtt.0 2016-07-19 23:03:51.131 debug mqtt.0 stateChange mqtt.0.GrillDuino01.TemperaturLuft: {"val":15.8,"ack":true,"ts":1468962231099,"q":0,"from":"system.adapter.mqtt.0","lc":1468962200865} 
mqtt.0 2016-07-19 23:03:51.131 debug inMem message *Grill* mqtt.0.GrillDuino01.TemperaturLuft 
mqtt.0 2016-07-19 23:03:51.131 debug mqtt.0 Send to client [GrillDuino01] "GrillDuino01/Luftfeuchte": 94.3 
mqtt.0 2016-07-19 23:03:51.131 debug mqtt.0 onStateChange mqtt.0.GrillDuino01.Luftfeuchte: {"val":94.3,"ack":true,"ts":1468962231099,"q":0,"from":"system.adapter.mqtt.0","lc":1468962221006} 
mqtt.0 2016-07-19 23:03:51.131 debug mqtt.0 stateChange mqtt.0.GrillDuino01.Luftfeuchte: {"val":94.3,"ack":true,"ts":1468962231099,"q":0,"from":"system.adapter.mqtt.0","lc":1468962221006} 
mqtt.0 2016-07-19 23:03:51.131 debug inMem message *Grill* mqtt.0.GrillDuino01.Luftfeuchte 
mqtt.0 2016-07-19 23:03:51.131 debug mqtt.0 Server received "GrillDuino01/TemperaturBack1" (number): 9 
mqtt.0 2016-07-19 23:03:51.131 debug mqtt.0 Server received "GrillDuino01/TemperaturLuft" (number): 15.8 
mqtt.0 2016-07-19 23:03:51.115 debug mqtt.0 Server received "GrillDuino01/Luftfeuchte" (number): 94.3 

Vielen Dank.