NEWS
js-controller 3.3 jetzt im STABLE!
-
@idlebit Zeig mal die ganze Zeile des Logs ... du hast oben nur nen ausschnitt gepostet!
-
Bitte nicht falsch verstehen! Ihr macht einen absolut super Job und wie schnell Fehler behoben werden und auf Github requests reagiert wird ist mega. ABER ich find es persönlich viel zu früh den js-controller 3.3 ins stable zu bringen.
Zumindest nicht ohne die Möglichkeit die wrong Type Meldungen mit einer Einstellung zu unterdrücken. Ich verstehe, dass ihr aufräumen wollt um den wildwuchs bei Adaptern in den Griff zu kriegen, aber da kann ja der normale User nichts für.
Ich zum Beispiel versuche meine logs super clean zu halten, da ich mir jede Info, Warnung und Error Meldung per Pushover schicken lasse und das hat bis jetzt hervorragend funktioniert, da ich selbst darauf achte, dass nichts unnötiges im log aufläuft. Jetzt mit dem js-controller 3.3 ist das unmöglich, da z.B. der WLED Adapter 100te von Meldungen rauswirft.
Gibt es die Möglichkeit, das Systemseitig zu unterdrücken OHNE das loglevel umzustellen. Wie gesagt, den normalen User interessiert es ja nicht ob irgend ein Wert mit dem falschenb Datentyp geschrieben wird, sondern nur die Entwickler!
-
@apollon77 Das ist nicht mein Log!
@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}"`Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@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,
-
Bitte nicht falsch verstehen! Ihr macht einen absolut super Job und wie schnell Fehler behoben werden und auf Github requests reagiert wird ist mega. ABER ich find es persönlich viel zu früh den js-controller 3.3 ins stable zu bringen.
Zumindest nicht ohne die Möglichkeit die wrong Type Meldungen mit einer Einstellung zu unterdrücken. Ich verstehe, dass ihr aufräumen wollt um den wildwuchs bei Adaptern in den Griff zu kriegen, aber da kann ja der normale User nichts für.
Ich zum Beispiel versuche meine logs super clean zu halten, da ich mir jede Info, Warnung und Error Meldung per Pushover schicken lasse und das hat bis jetzt hervorragend funktioniert, da ich selbst darauf achte, dass nichts unnötiges im log aufläuft. Jetzt mit dem js-controller 3.3 ist das unmöglich, da z.B. der WLED Adapter 100te von Meldungen rauswirft.
Gibt es die Möglichkeit, das Systemseitig zu unterdrücken OHNE das loglevel umzustellen. Wie gesagt, den normalen User interessiert es ja nicht ob irgend ein Wert mit dem falschenb Datentyp geschrieben wird, sondern nur die Entwickler!
@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.
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@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,
@oliverio Exakt. Ein Read only state kann per definition nicht kontrolliert werden weil er nur einen Wert bereitstellt :-) Daher die Meldung.
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@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" -
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" -
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"@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.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@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.
@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. :)
-
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"@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 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.
sind davon dann meine Blockly script betroffen ?
-
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.
-
@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!:
@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.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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?
-
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.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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). ;)
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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). ;)
451
Online32.6k
Users82.1k
Topics1.3m
Posts