js-controller 3.3 jetzt im STABLE!
-
@idlebit Na ok :-))
Laut Quellcode ist die einzige Stelle für den Teil so:
`${this.namespaceLog} Read-only state "${id}" has been written without ack-flag with value "${state.val}"` -
@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:
@idlebit Na ok :-))
Laut Quellcode ist die einzige Stelle für den Teil so:
`${this.namespaceLog} Read-only state "${id}" has been written without ack-flag with value "${state.val}"`also das heisst, das readonly states eigentlich nur von adaptern erstellt und beschrieben werden sollen und wenn dann immer mit ack=true geschrieben werden soll.
wenn man in skripten eigene datenpunkte als readonly (warum auch immer) erstellt, dann muss man den ebenfalls mit ack=true beschreiben, da es ansonsten ein fehler gibt,
-
@fabian1 Ich kann dich verstehen, aber in meinen/unseren Augen ist es nicht zu früh. Wir haben jetzt ca. 3 Monate an den Adaptern gearbeitet und dabei über 80 Adapter aktualisiert welche Meldungen geworfen haben. Irgendwann ist auch mal ok und es muss weiter gehen.
Daher gab es auch eine Info-Adapter-Meldung dazu und so weiter.
Daher, falls noch noch einzelne Adapter übrig sind, bitte melden und Loglevel hochsetzen auf "warn". Das Logging der Meldungen erfolgt nur auf "info". Sollte sich also mit deinem "warn/error per pushover senden" nicht kollidieren.
EDIT: Für Wled sollte richtung Wochenende ein Update kommen (ml mindestens im Latest)
Wie gesagt, den normalen User interessiert es ja nicht ob irgend ein Wert mit dem falschenb Datentyp geschrieben wird, sondern nur die Entwickler!
Jain ... gibt auch genügend Fälle in Visus oder JavaScript wo User-Skripte komische und falsche Dinge tun.
-
@oliverio Exakt. Ein Read only state kann per definition nicht kontrolliert werden weil er nur einen Wert bereitstellt
Daher die Meldung. -
Hallo,
was bedeutet diese Meldung im Log ???State value to set for "tr-064.0.callmonitor.lastCall.callee" has to be type "number" but received type "string" -
bzw
fritzdect.0 2021-08-05 13:17:21.675 info (2739) State value to set for "fritzdect.0.DECT_099950270252.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.674 info (2739) State value to set for "fritzdect.0.DECT_099950270252.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.673 info (2739) State value to set for "fritzdect.0.DECT_099950270252.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.579 info (2739) State value to set for "fritzdect.0.DECT_099950276783.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.574 info (2739) State value to set for "fritzdect.0.DECT_099950276783.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.573 info (2739) State value to set for "fritzdect.0.DECT_099950276783.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.470 info (2739) State value to set for "fritzdect.0.DECT_099950696353.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.468 info (2739) State value to set for "fritzdect.0.DECT_099950696353.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.467 info (2739) State value to set for "fritzdect.0.DECT_099950696353.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.393 info (2739) State value to set for "fritzdect.0.DECT_133560170728.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.391 info (2739) State value to set for "fritzdect.0.DECT_133560170728.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.390 info (2739) State value to set for "fritzdect.0.DECT_133560170728.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.300 info (2739) State value to set for "fritzdect.0.DECT_133560175984.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.298 info (2739) State value to set for "fritzdect.0.DECT_133560175984.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.281 info (2739) State value to set for "fritzdect.0.DECT_133560175984.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.135 info (2739) State value to set for "fritzdect.0.DECT_133560155800.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.126 info (2739) State value to set for "fritzdect.0.DECT_133560155800.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.124 info (2739) State value to set for "fritzdect.0.DECT_133560155800.windowopenactiveendtime" has to be type "number" but received type "string" -
@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.
