js-controller 3.3 jetzt im STABLE!
-
@michael-schmitt Ja das hatte ich auch. Ist aber wie in der Anleitung beschrieben.
Ich habe die Datenpunkte alle gelöscht (des Callmonitors) und dann den Adapter neu gestartet und der Adapter hat die Objekte dann mit dem korrekten Typ angelegt.
Also zum Beispiel den Callmonitor.
Es geht Dir halt die Historie verloren. - Vielleicht auch nicht, aber ich habe nicht jeden Datenpunkt geprüft.
Also vielleicht hätte es auch getan, wenn ich nur den monierten Punkt gelöscht hätte. -
@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
-
@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:
Jain ... gibt auch genügend Fälle in Visus oder JavaScript wo User-Skripte komische und falsche Dinge tun.
Jo so habe ich heute festgestellt, dass mein NodeRed Flow Strings in ein Zahlenobjekt geschrieben hat. Ich finde diese Meldungen auch als "Nicht-Adapter" Entwickler durchaus nützlich.
-
@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
-
sind davon dann meine Blockly script betroffen ?
-
@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.
-
@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.
-
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?
-
@oliverio So weit ich das System durchschaue - aber da bist Du schlauer, muss man den Typ glaub in dem Objekt ändern.
-
@mickym sagte: muss man den Typ glaub in dem Objekt ändern.
Ja, common.type im Objekt vom Typ "state".
-
@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).
-
@mickym
Genau dort erfolgt die Korrektur. -
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.
-
@mickym Bei info hängt es davon ab welche Statistiken man alles so aktiviert hat, können auch mehr sein.
-
@paul53 Vollkommen korrekt
-
@apollon77
Wer merged eigentlich meinen PR im Deconz-Adapter? -
@paul53 Den kannte ich bisher nicht ... Kläre
-
@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.
-
@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
-
@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.
