Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[haus-automatisierung]

Hi zusammen,

wenn ich Adapter entwickle, dann benutze ich eigentlich nur States vom Typ number, string, und boolean. Bisher auch ein paar mal file für binary states, aber der Typ ist ja deprecated. mixed ignoriere ich generell, weil ich schon gerne einen Datentyp festlege.

Wenn man jetzt allerdings auf das + im Admin im Objekt-Tab klickt, dann kann man noch weitere Typen anlegen:

• json
• object
• array
• multistate

Dazu ein paar Fragen:

1. Warum gibt es den common.type = 'json' überhaupt? Um json zu speichern, nutze ich eigentlich common.type = 'string' + common.role = 'json' - wie es auch hier dokumentiert ist. Was ist der Unterschied, wenn ich direkt json als Typ festlege?
2. object und array verwende ich nie, weil ich wie gesagt immer einen JSON-String speichere. Früher hatte ich das mal genutzt, aber irgendwo wurde ich darauf hingewiesen dass man die Typen nicht mehr verwenden sollte. Was ist da "best practice"?
3. Was ist multistate? Ich habe doch unabhängig vom Datentyp die Option eine Art Enum mit gültigen Werten auf dem Objekt zu definieren (mit states: {a: 'jo', b: 'no'}).

Für mich gibt es eigentlich nur die 3 Basis-Datentypen + entsprechende Rollen um diese genauer zu beschreiben. Warum bietet der Admin-Adapter dem Nutzer da noch mehr an? Das wird die meisten Nutzer doch nur verwirren.

Angenommen ich möchte das Objekt {test: "jo", bla: true}speichern, dann habe ich ja aktuell 3 Möglichkeiten:

a)

// common.type = 'json', common.role = 'state'
setState('xxx', {val: JSON.stringify({test: "jo", bla: true}), ack: true});

b)

// common.type = 'string', common.role = 'json'
setState('xxx', {val: JSON.stringify({test: "jo", bla: true}), ack: true});

c)

// common.type = 'object', common.role = 'state'
setState('xxx', {val: {test: "jo", bla: true}, ack: true});

Und am Ende landet wahrscheinlich alles auf die gleiche Art in der State-DB :)

Siehe auch: https://www.iobroker.net/#de/documentation/basics/states.md

[paul53]

@haus-automatisierung sagte: object und array verwende ich nie

Die beiden Typen werden im Javascript-Adapter automatisch beim Schreiben und Lesen gewandelt. Gespeichert werden sie als JSON. Ein Adapter-Entwickler muss selbst dafür sorgen, dass sie als JSON gespeichert werden.

@haus-automatisierung sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

irgendwo wurde ich darauf hingewiesen dass man die Typen nicht mehr verwenden sollte.

Wirklich?

@haus-automatisierung sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Was ist multistate?

Wird mir im Tab "Objekte" bei der Datenpunkterstellung nicht angeboten (gab es aber mal).

[haus-automatisierung]

@paul53 sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Ein Adapter-Entwickler muss selbst dafür sorgen, dass sie als JSON gespeichert werden.

Okay, aber dann gibt es ja absolut gar keinen Unterschied zu common.type = 'json' mehr?! Wahrscheinlich einfach nur "hisorisch gewachsen" - oder wie sagt man so schön?

@paul53 sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Wirklich?

Ja, müsste ich mal suchen. Zumindest habe ich damals alle meine Adapter auf String umgestellt.

@paul53 sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Wird mir im Tab "Objekte" bei der Datenpunkterstellung nicht angeboten (gab es aber mal).

Beim erstellen nicht, aber beim bearbeiten. Siehe auch https://github.com/ioBroker/ioBroker.admin/issues/1889

[paul53]

@haus-automatisierung sagte: alle meine Adapter auf String umgestellt.

Ja, früher wurden Arrays und Objekte direkt (ohne Wandlung in JSON) gespeichert. Das wurde geändert.

[haus-automatisierung]

Ah, das kann gut sein. Ich weiß nur noch dass ich aktiv werden musste. Also hätte es ein stringify auch getan und ich hätte nicht den Typ umstellen müssen.

Bleibt bei mir totzdem die Frage, warum es so 3 Wege für das gleiche Ergebnis gibt.

@paul53 sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Die beiden Typen werden im Javascript-Adapter automatisch beim Schreiben und Lesen gewandelt.

Okay, dann wäre es für den Endnutzer ja sogar besser, wenn man nicht common.type = 'string' + common.role = 'json' nutzen würde, da man dort ja immer noch ein JSON.parse braucht.

[paul53]

@haus-automatisierung sagte: Also hätte es ein stringify auch getan und ich hätte nicht den Typ umstellen müssen.

Ja.

@haus-automatisierung sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

common.type = 'json' mehr?! Wahrscheinlich einfach nur "hisorisch gewachsen" - oder wie sagt man so schön?

"Historisch gewachsen" eher nicht, denn common.type = 'json' gibt es noch nicht so lange. Weshalb es eingeführt wurde, entzieht sich meiner Kenntnis. Vielleich kann @apollon77 aufklären?

[carsten04]

Wie groß darf denn ein JSON.stringify(mein_wirklich_grosses_object) maximal werden? Gibt es da irgendeine ioBroker-seitige Begrenzung?

[apollon77]

@paul53 sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Vielleich kann @apollon77 aufklären?

Leider nicht, haben wir gefunden als wir mal die Prüfungen etwas strikter gemacht haben.

Mit der Idee das die Rollen primär dazu da sind um Visus u.ä. mehr Informationen zum Content zu geben könnte ich durchaus schon Unterschiede zwischen "object", "json" und "array" (um am Ende drei zu nennen die effektiv alles "stringified javascript Strukturen" sind) konstruieren.

[apollon77]

@carsten04 Hm ... Ich denke JSON-stringify hat ein Limit bzw JavaScript dabei wie groß/lang ein String werden darf. Dann geht es weiter das Objekte im js-controller oder im Redis im RAM liegen. Und noch weiter das am Ende alle Objekte und States von Backup in ein großes JSON gepackt werden für das wiederum die Limits von oben gelten.

Wenn deine Objects+States-DB größer als 2GB (nicht drauf fest nageln aber glaube sowas wars) wird dann ists blöd ... :-) Rest darfst du gern zurückrechnen was das dann heisst für das einzelne "mein_wirklich_grosses_object".

Aber Spass beiseite. Wenn es wirklich groß ist empfehle ich es eher als File abzulegen und nicht als JSON object weil am Ende ja die Frage ist wer was damit tut und ob das auch performance und sonstwas Sicht sinn macht.

[haus-automatisierung]

@apollon77 Was ist denn Dein Vorgehen für neue Adapter - also was verwendest Du primär? Mindestens json wäre dann ja redundant (kann ja auch ein object oder array sein).

Und was ist mit multistate- gibts da noch? Oder kann das aus dem Admin verschwinden? Findet man ja auch nur im Edit-Dialog und nicht beim Anlegen. Heißt Multistate wirklich "mehrere" Werte? Also wie Checkboxen quasi? Oder wie war das mal gedacht?

[paul53]

@haus-automatisierung: Heißt Multistate wirklich "mehrere" Werte?

Multistate heißt, dass die Werte per common.states übersetzt werden und im Admin selektierbar sind.

[haus-automatisierung]

@paul53 Aber das kann ich doch aktuell mit jedem Datentyp machen - zumindest prüft der admin nicht auf common.type. Daher die Frage ob der Typ überhaupt noch relevant ist.

[paul53]

@haus-automatisierung sagte: Aber das kann ich doch aktuell mit jedem Datentyp machen

Richtig. Deshalb sollte es aus der Typauswahl verschwinden.

Anmerkung: Der Ursprung geht zurück auf die "Werteliste" in der HomeMatic CCU.

[apollon77]

• Frage zu "json": hab ich persönlich gerade keine echte Meinung. Wäre vllt ein Thema fürs Dev Meeting
• Multistate kenn ich als offiziellen Typ gar nicht wenn ich ehrlich bin? Oder fehlt mir das was?

[haus-automatisierung]

@apollon77 sagte in Welche Datentypen + Rollen gibt es denn jetzt noch?:

Multistate kenn ich als offiziellen Typ gar nicht wenn ich ehrlich bin? Oder fehlt mir das was?

Wie ich das jetzt verstanden habe gab es den ganz früher mal und es wurde nur an der einen Stellt im Admin vergessen dieses Überbleibsel zu entfernen. Ich erstelle mal einen PR