js-controller 3.3 jetzt im STABLE!

[apollon77]

@michael-schmitt Die Meldung bedeutet das das Objekt definiert hat das es eine Nummer/Zahl ist, aber der Adapter hat eine Zeichenkette reingeschrieben ... Das kann ein Fehler sein weil das Objekt falsch ist oder nur ein Fall von -- Adapter schreibt "22" anstelle 22 -- rein

[Michael Schmitt]

sind davon dann meine Blockly script betroffen ?

[apollon77]

@michael-schmitt sagte in js-controller 3.3 jetzt im STABLE!:

sind davon dann meine Blockly script betroffen ?

Wenn Sie die richtigen Datentypen in die States schreiben nein ... falls die was falsch machen wirst Du auch Meldungen bekommen.

[mickym]

@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:

@mickym sagte in js-controller 3.3 jetzt im STABLE!:

Es geht Dir halt die Historie verloren.

Nur die Settings für History ... man kann es danach wieder aktivieren. Ja das ist leider blöd, aber aktuell leider so.

Die Alternative ist per Admin im Export-Modus das Objekt zu editierne und den Datentyp dort anzulassen. Für die mit History-Settings vllt schneller

Ja ich schrieb ja dass ich zu faul war, jetzt zu warten welche Datenpunkte alle moniert werden, da das ja auch nicht immer gleich funktioniert. Am Besten müsste das ja der Adapterentwickler wissen, aber keine Ahnung ob man als Adapterentwickler auch den Typ eines Objektes nachträglich ändern kann. Ich geh mal davon aus, dass das geht, aber ist halt zusätzliche Arbeit für die Entwickler.

[OliverIO]

@mickym

schön wäre eine musterlösung für eine migration.
dann könnte man die genau so in den adapter einbauen
und es müsste sich nicht jeder eine eigene Funktion ausdenken.

idee für eine Funktionssignatur wäre:

function migrateStateType(id,fromType,toType)

oder müsste es eigentlich Object heißen?

[mickym]

@oliverio So weit ich das System durchschaue - aber da bist Du schlauer, muss man den Typ glaub in dem Objekt ändern.

[paul53]

@mickym sagte: muss man den Typ glaub in dem Objekt ändern.

Ja, common.type im Objekt vom Typ "state".

[mickym]

@paul53 Das Objekt ist doch das, was unter "raw" steht, das war mein Verständnis:

EDIT: Ach so ich verstehe was Du meinst vom Typ state (letzte Zeile).

[paul53]

@mickym
Genau dort erfolgt die Korrektur.

[mickym]

So noch ein Info - zum Info Adapter - da gibt es auch wenn man sonst keine Systemdaten monitoren will noch 5 Objekte, die man auch löscht, damit der Adapter die korrekten Typen wieder anlegt:

info.0	2021-08-05 13:29:38.945	info	(5272) State value to set for "info.0.sysinfo.cpu.info.cache-l3" has to be type "number" but received type "string"
info.0	2021-08-05 13:29:38.941	info	(5272) State value to set for "info.0.sysinfo.cpu.info.cache-l2" has to be type "number" but received type "string"
info.0	2021-08-05 13:29:38.936	info	(5272) State value to set for "info.0.sysinfo.cpu.info.cache-l1i" has to be type "number" but received type "string"
info.0	2021-08-05 13:29:38.886	info	(5272) State value to set for "info.0.sysinfo.cpu.info.cache-l1d" has to be type "number" but received type "string"
info.0	2021-08-05 13:29:38.849	info	(5272) State value to set for "info.0.sysinfo.cpu.info.speed" has to be type "string" but received type "number"

Es langt aber wirklich nur diese 5 Punkte zu löschen!!!

Selbst als ich dann das Laden der Systemdaten mal kurzzeitig aktiviert habe, wurden keine weiteren Inkonsistenzen festgestellt.

[apollon77]

@mickym Bei info hängt es davon ab welche Statistiken man alles so aktiviert hat, können auch mehr sein.

[apollon77]

@paul53 Vollkommen korrekt

[paul53]

@apollon77
Wer merged eigentlich meinen PR im Deconz-Adapter?

[apollon77]

@paul53 Den kannte ich bisher nicht ... Kläre

[mickym]

@apollon77 Noch ein blöde Frage:

Wenn ich selbsterstellte Datenpunkte mit dem Typ: gemischt anlege:

unterbleibt dann die Typprüfung?

Ich könnte es zwar selbst ausprobieren, aber vielleicht wäre das einfach für alle eine wichtige Info.

[apollon77]

@mickym Naja bei gemischt kann ja kein Datentyp geprüft werden ... also ja es wird auch nichts geprüft. man muss dann aber ahlt bei eigenen Skripten auch mit allem möglichen Klarkommen was man da selbst reinschreibt

[mickym]

@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:

@mickym Naja bei gemischt kann ja kein Datentyp geprüft werden ... also ja es wird auch nichts geprüft. man muss dann aber ahlt bei eigenen Skripten auch mit allem möglichen Klarkommen was man da selbst reinschreibt

OK danke - ich weiß ist sicher nicht im Sinne des Erfinders - nur habe ich eben festgestellt, dass sich manche Adapterentwickler dieser Methode bedienen. Aber alles gut.

[apollon77]

@mickym sagte in js-controller 3.3 jetzt im STABLE!:

dass sich manche Adapterentwickler dieser Methode bedienen.

genau die sollten das nur in absoluten Ausnahmefällen tun

[apollon77]

Nicht wundern. Rainer und ich räumen den Thread gerade ein bissl auf und Splitten Diskussionsthemen die länger werden könnten in eigene Threads und verlinken Sie oben im zweiten Post.

[Fabian1]

@mickym Ich auch Und ich hab bei meinen eigenen Skripten auch schon nachgearbeitet. Darum ging es mir auch nicht, ich find es ja vom Prinzip eine super Sache. ABER guck dir z.B. mal den Radar2 Adapter an oder WLED oder Zigbee. Das sind Adapter die FAST jeder benutzt und trotzdem werfen sie zur Zeit noch MASSENHAFT infos ins LOG, man kann jetzt zwar auf warn umstellen, dann sieht man z.B. bei WLED und Zigbee aber im log auch nicht mehr, wenn sich Geräte neu verbunden haben. Und ich weiß halt nicht, ob das für den NORMALEN Anwender so clever ist, das jetzt so ins stable zu packen. Und es kann dann ja auch nicht sein, dass andere Leute hingehen, wie z.B. im Radar2 und die ganzen ack-flag fehler beseitigen und seit Mai nicht gemerged wird.