Object/Array Datentyp zu string?

[holomekc]

Hallo zusammen,

ich habe ein bisschen in dem Forum nach dem Thema gesucht bei dem es um Meldungen dieser Art geht:

State value to set for "bshb.0.intrusionDetectionSystem.IntrusionDetectionControl.faults" has to be stringified but received type "object"

Bisher konnte ich nur finden das seit der neuen js-controller Version diese eben als Text abgespeichert werden sollen. Also bspw.

setState('bshb.0.intrusionDetectionSystem.IntrusionDetectionControl.faults', {val: JSON.stringify(value), ack: true});

Ich versuche gerade zu verstehen warum das so entschieden wurde, da es sich mit Texten in der Regel schlecht arbeiten lässt. Ich vermute auch das ich dann ein JSON.parse() beim auslesen machen muss, wenn ich mit dem Objekt arbeiten will? Ist das nur wegen der Anzeige?

Der iobroker.bshb Adapter nimmt die Daten so wie sie vom Bosch Controller kommen, ohne zu Wissen um was es eigentlich genau geht. Ein string bleibt string und ein object ein object. Ich denke das ich damit ganz gut umgehen kann, da der Adapter auch nicht wirklich die Werte auslesen/interpretieren muss.

Was ich mich frage ist jedoch, ob dann die Leute, die eine eigene Logik basierend auf den Werten gebaut haben, nun auf einmal ein String in der Hand halten. Dadurch ist dann die Logik solange unbrauchbar, bis sie selber ein JSON.parse eingebaut haben?

Gibt es irgendwo eine Seite wo solche Änderungen genauer beschrieben sind?

Vielen Dank
Christopher

[paul53]

@holomekc sagte: nun auf einmal ein String in der Hand halten. Dadurch ist dann die Logik solange unbrauchbar, bis sie selber ein JSON.parse eingebaut haben?

Nein, das macht der Javascript-Adapter ab Version 5.2.x in beide Richtungen automatisch, wenn der Datenpunktyp "object" oder "array" ist.

Issue gibt es bereits zum Adapter BSHB.

[holomekc]

@paul53
Hi das mit dem issue weiß ich . Ok dann scheint es der node-red Adapter aber noch nicht zu tun, da erhalte ich einen String. Ich schaue nachher nochmal, ob es dafür dann eine Einstellung gibt, oder das dort dann fehlt, oder ob ich da schlecht geschaut habe.

[mickym]

@holomekc Beim NodeRed Adapter musst Du wie bisher alles selbst beschreiben, da ist nichts automatisch. So wie ich @paul53 verstanden habe, ist es bei anderen Adapter Aufgabe des Adapterentwicklers darauf zu achten, dass keine Objekte direkt geschrieben werden, bei NodeRed schreibst Du aber diese Werte selbst, also bist Du auch selbst verantwortlich. Im Gegenteil würde ich mir das verbieten, wenn hier der Adapter selbstständig in meinen Datentypen rumpfuscht. Ich finde es schon schlimm genug, wenn man die automatische Stringkonvertierung defaultmässig immer ausschalten muss.

[holomekc]

@mickym
Bei NodeRed meine ich aber auch eher

iobroker.bshb schreibt „{\“test\“: 123}“ weil JSON.stringify

Aber nodered ließt dann halt auch einen String. Obwohl object/array als Typ definiert ist. Da ist dann die Einstellung „iobroker-Werte in Zeichenkette konvertieren“ deaktivieren ohne Funktion für object/array. Für zahlen, boolean funktioniert es weiterhin.

Edit: Vielleicht noch deutlicher. Natürlich wie @mickym erwähnte mit deaktivierter Einstellung für Stringkonvertierung.

Vorher:
iobroker.bshb schreibt: {“test“: 123}
iobroker.node-red ließt: {“test“: 123}

Jetzt:
iobroker.bshb schreibt: „{\“test\“: 123}“, da object & array serialisiert werden sollen
iobroker.node-red ließt: „{\“test\“: 123}“

Das finde ich für einen Benutzer verwirrend und das ist die Stelle wo ich meine das Logiken auf die Nase fallen, da der Benutzer dann erst ein JSON.parse selber einbauen muss.

Aber wenn das so gewollt ist, ist das für mich auch ok.

[mickym]

@holomekc Das ist aber ein Problem vom dem bshb Adapter. Normal - so habe ich @paul53 verstanden, muss jedes Objekt vom Adapter als JSON-String abgespeichert werden und darf deshalb die Anführungszeichen der Objekteigenschaft nicht escapen - sprich das Ding muss immer als „{“test“: 123}“ geschrieben werden.

[holomekc]

@mickym
Siehe edit vom post darüber. Genau das will ich ja ändern. Will nur wissen das diese Verhalten wirklich so gewünscht ist.

[mickym]

@holomekc Na wie gesagt, ich kann das mit dem Escapen der Anführungszeichen nicht glauben, dann würde auch die JSON Nodes nicht mehr funktionieren - oder Du hast Recht der Node Red Adapter bzw. die iobroker IN müssten in diesem Fall beim Lesen gleich Objekte liefern. OK - hab es verstanden.

[holomekc]

@mickym
Ehm nicht escapen? "{"test": 123}" ist kein valider String, sondern ein Fehler:

Edit:

[paul53]

@mickym sagte: muss jedes Objekt vom Adapter als JSON-String abgespeichert werden

So ist es. Objekte müssen vom Adapter mit JSON.stringify(obj) in den Datenpunkt geschrieben werden.

[paul53]

@holomekc sagte: "{"test": 123}" ist kein valider String, sondern ein Fehler

Ja, aber nicht

'{"test": 123}'

[mickym]

@holomekc Wollte ich gerade sagen: Eigenschaften von Objekten gehören nicht in Anführungszeichen:

gibt keine Probleme.

[holomekc]

@paul53
Das ist das gleiche in Pink:

[paul53]

@mickym sagte: Eigenschaften von Objekten gehören nicht in Anführungszeichen:

Es sind auch Anführungszeichen zulässig.

[mickym]

@paul53 Aber mit dem gleichen Ergebnis:

Sprich wenn ich partout Anführungszeichen in einer Eigenschaft mitgeben will - müsste es heißen:

und dann sieht man ist das Ergebnis wie unten:

{"\"test\"":123}

[holomekc]

@holomekc
ok ok noch einmal nur das technische:

const test = {test:123};
const result = JSON.stringify(test);

result war immer und bleibt immer "{"test":123}", denn wenn das nicht so wäre, dann würde gar nix mehr funktionieren. Das Javascript bei der Notation sehr entgegenkommend ist liegt einfach an der Sprache. Dennoch muss der Text unter der Haube escaped sein, denn das Programm leißt von " zu " und dazwischen ist Text.

Das eine Console die escapten Zeichen interpretieren kann ist wieder ein ganz anderes Thema.

Aber ehrlich gesagt ging es mir auch nicht um das Thema wie Strings funktionieren, sondern um halt das Thema was mir @mickym im Prinzip mit seiner Antwort schon gegeben hat.

Also für mich heißt das ich passe das in iobroker.bshb an, wie es mit der neuen js-controller version gewünscht ist. Dann wird entweder noch node-red angepasst oder aber die Nutzer müssen es halt dann selber anpassen.

Danke für die ganzen Infos! Wäre dennoch schön einen Übersichtsseite solcher Änderungen zu sehen, falls es das gibt. Wurde bisher nicht fündig.

[paul53]

@holomekc sagte: Wäre dennoch schön einen Übersichtsseite solcher Änderungen zu sehen, falls es das gibt.

Changelog

[holomekc]

@paul53
Dankeschön!