NEWS
Datenpunkt Typen nicht mehr konsistent
-
Kann mir vielleicht jemand erklären, was mit dem java Skript Adapter los ist?
Ich habe sehr viele Skripte laufen. Der Adapter hat die Version 5.2.18
Wenn ich ein altes Skript öffne, die Blöcke ein bisschen verschiebe, bietet er mir sofort an, das ich es speichern soll. Faktisch hat sich am Skript nichts geändert außer die Position auf dem Bildschirm.
Als Folge dieses neuen speichern produziert das Skript aber Warnmeldungen, das der Typ nicht stimmt - warum das plötzlich. Es kommt aber noch besser. Passt man den Typen wie gefordert in den RAW Daten an, ist genau das, was vorher gefordert wurde, wieder falsch.
Hier ein Beispiel: Erst war der Typ
number
falsch und es wurdestring
gefordert. Passt man das ganze wie gefordert an, wird es wieder genau anders herum gefordert.Ich verstehe das nicht. Ich habe an den Skripten nichts geändert außer neu zu speichern.
mqtt.2 9028 2021-12-18 20:21:37.362 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number" mqtt.2 9028 2021-12-18 20:21:27.286 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number" mqtt.2 9028 2021-12-18 20:21:17.231 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number" mqtt.2 9028 2021-12-18 20:21:07.552 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number" mqtt.2 9028 2021-12-18 20:20:57.707 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "number" but received type "string" mqtt.2 9028 2021-12-18 20:20:47.820 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "number" but received type "string" mqtt.2 9028 2021-12-18 20:20:37.681 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "number" but received type "string" mqtt.2 9028 2021-12-18 20:20:27.703 info State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "number" but received type "string"
Hier haben wir noch so einen Fall. Auch das Skript wurde geöffnet und neu gespeichert. Auch hier hagelt es plötzlich Warn Meldungen. Auch hier das gleiche wie oben. Passt man den Typen an, ist es wieder falsch - WHY?
javascript.0 1516 2021-12-18 20:29:11.983 warn at processImmediate (internal/timers.js:461:21) javascript.0 1516 2021-12-18 20:29:11.983 warn at Immediate._onImmediate (C:\iobroker\GLT\node_modules\iobroker.js-controller\lib\adapter.js:5706:41) javascript.0 1516 2021-12-18 20:29:11.982 warn at Object.stateChange (C:\iobroker\GLT\node_modules\iobroker.javascript\main.js:530:29) javascript.0 1516 2021-12-18 20:29:11.981 warn at Object.callback (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1082:38) javascript.0 1516 2021-12-18 20:29:11.981 warn at Object.<anonymous> (script.js.Solar.Eigenverbrauch_2:21:5) javascript.0 1516 2021-12-18 20:29:11.981 warn at setState (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1437:20) javascript.0 1516 2021-12-18 20:29:11.980 warn You are assigning a undefined to the state "javascript.0.PV_Eigenverbrauch.DP_Verbraucher3" which expects a boolean. Please fix your code to use a boolean or change the state type to undefined. This warning might become an error in future versions. javascript.0 1516 2021-12-18 20:29:11.979 warn at processImmediate (internal/timers.js:461:21) javascript.0 1516 2021-12-18 20:29:11.979 warn at Immediate._onImmediate (C:\iobroker\GLT\node_modules\iobroker.js-controller\lib\adapter.js:5706:41) javascript.0 1516 2021-12-18 20:29:11.979 warn at Object.stateChange (C:\iobroker\GLT\node_modules\iobroker.javascript\main.js:530:29) javascript.0 1516 2021-12-18 20:29:11.979 warn at Object.callback (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1082:38) javascript.0 1516 2021-12-18 20:29:11.979 warn at Object.<anonymous> (script.js.Solar.Eigenverbrauch_2:20:5) javascript.0 1516 2021-12-18 20:29:11.979 warn at setState (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1437:20) javascript.0 1516 2021-12-18 20:29:11.978 warn You are assigning a undefined to the state "sonoff.0.DEKO_4.POWER1" which expects a boolean. Please fix your code to use a boolean or change the state type to undefined. This warning might become an error in future versions. javascript.0 1516 2021-12-18 20:29:11.977 warn at processImmediate (internal/timers.js:461:21) javascript.0 1516 2021-12-18 20:29:11.977 warn at Immediate._onImmediate (C:\iobroker\GLT\node_modules\iobroker.js-controller\lib\adapter.js:5706:41) javascript.0 1516 2021-12-18 20:29:11.977 warn at Object.stateChange (C:\iobroker\GLT\node_modules\iobroker.javascript\main.js:530:29) javascript.0 1516 2021-12-18 20:29:11.977 warn at Object.callback (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1082:38) javascript.0 1516 2021-12-18 20:29:11.977 warn at Object.<anonymous> (script.js.Solar.Eigenverbrauch_2:16:5) javascript.0 1516 2021-12-18 20:29:11.976 warn at setState (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1437:20) javascript.0 1516 2021-12-18 20:29:11.975 warn You are assigning a undefined to the state "javascript.0.PV_Eigenverbrauch.DP_Verbraucher1" which expects a boolean. Please fix your code to use a boolean or change the state type to undefined. This warning might become an error in future versions. javascript.0 1516 2021-12-18 20:29:11.975 warn at processImmediate (internal/timers.js:461:21) javascript.0 1516 2021-12-18 20:29:11.975 warn at Immediate._onImmediate (C:\iobroker\GLT\node_modules\iobroker.js-controller\lib\adapter.js:5706:41) javascript.0 1516 2021-12-18 20:29:11.975 warn at Object.stateChange (C:\iobroker\GLT\node_modules\iobroker.javascript\main.js:530:29) javascript.0 1516 2021-12-18 20:29:11.974 warn at Object.callback (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1082:38) javascript.0 1516 2021-12-18 20:29:11.974 warn at Object.<anonymous> (script.js.Solar.Eigenverbrauch_2:15:5) javascript.0 1516 2021-12-18 20:29:11.974 warn at setState (C:\iobroker\GLT\node_modules\iobroker.javascript\lib\sandbox.js:1437:20) javascript.0 1516 2021-12-18 20:29:11.972 warn You are assigning a undefined to the state "sonoff.0.E-Bike Ladestation.POWER" which expects a boolean. Please fix your code to use a boolean or chang
-
@jb_sullivan Ich denke das ist wieder ein Admin5 Problem. Habe das auch - das Problem ist das mqtt eigentlich nur Strings überträgt man früher aber problemlos auch andere Datentypen da rein schreiben konnte.
Ich hatte ja auch schon mal angeregt, dass man 0_userdata und mqtt von dieser ganzen Prüfungen ausnimmt. Insbesondere wenn Du irgendein topic subscribst das nicht auf root Ebene angelegt ist fehlen die ganzen Objekte. Auch dieses Verhalten, dass Du beobachtest hatte ich schon öfter. Du kannst versuchen mit Datentyp mixed das Ganze aufzulösen - aber besser wäre einfach man würde diesen beiden Namensräumen wieder die Freiheiten von vorher geben.
Wenn ich zum BEispiel mit einer Instanz die Datenpunkte einer Instanz publishe und mit einer anderen wieder subscribe ist mein Log rot und Du darfst alles händisch nachbearbeiten. Also wer sich das ausgedacht hat, .....
-
@mickym sagte: Ich denke das ist wieder ein Admin5 Problem.
Die Warnungen zum Typ kommen vom js-controller.
-
@jb_sullivan sagte: You are assigning a undefined to the state
Das ist ein Fehler im Skript, denn es darf nie undefined in einen Datenpunkt geschrieben werden.
-
@paul53 Ok - das weißt Du sicher besser - nur die Grundaussage, dass man diese Art Prüfungen aus bestimmten Namensräumen herausnehmen sollte, halte ich nach wie vor für richtig.
-
@paul53 sagte in Datenpunkt Typen nicht mehr konsistent:
@jb_sullivan sagte: You are assigning a undefined to the state
Das ist ein Fehler im Skript, denn es darf nie undefined in einen Datenpunkt geschrieben werden.OK, dann muss ich suchen - ist nur die Frage wonach, denn das Skript hat vorher ohne Fehler funktioniert. Nur geöffnet, weil ich was nachsehen wollte, dabei wohl die Blöcke ein bisschen verschoben und neu gespeichert.
Zack und einen Sack voll Meldungen - im Moment habe ich keine Ahnung, was da ggf. undefined sein könnte. Alle Geräte die in dem Skript verarbeitet werden, sind erreichbar und liefern so wie immer ihre Werte.
-
Hi, ich habe aktuell das selbe Problem.
Im Objekt ist das aber korrekt...
{
"_id": "javascript.0.scriptEnabled.Meine_Geräte.Rollo_TE_schedule",
"common": {
"name": "scriptEnabled.Meine_Geräte.Rollo_TE_schedule",
"desc": "controls script activity",
"type": "boolean",
"write": true,
"read": true,
"role": "switch.active"
},
"native": {
"script": "script.js.Meine_Geräte.Rollo_TE_schedule"
},
"type": "state",
"from": "system.adapter.javascript.0",
"user": "system.user.admin",
"ts": 1587374022784,
"acl": {
"object": 1636,
"state": 1636,
"owner": "system.user.admin",
"ownerGroup": "system.group.administrator"
}
}Das Script wird Abends regelmäßig nicht gestartet, da das der einzie Logeintrag ist denke ich es liegt daran.
Anbei mein Blocklyscript.
-
@benziman sagte: Das Script wird Abends regelmäßig nicht gestartet
Die Warnung kommt um 8:09 Uhr, nicht um 22:30 Uhr.
Das fehlerhafte Skript ist "Meine_Geräte.Rollo_TE_schedule", in dem auf einen Tuya-Datenpunkt geschrieben wird (in Zeile 12 der Javascript-Ansicht).Zu dem Blockly-Bild: Tausche die Variable true gegen den Block "wahr" aus.
-
danke, hatte heute früh das Script nochmal gestartet deswegen die falsche Zeit.
Ich teste das danke!