js-controller 3.3 jetzt im Beta
-
@thomas-braun sagte in js-controller 3.3 jetzt im Latest:
Immer diese Ungeduld...
Jupp, habe ja ein Test-System, würde ich beim produktiven System nie machen.
-
@sigi234
Gerade mein produktiv System umgestellt und sehr langweilig, außer dass sehr viele Adapter nun Objekte und Strings anmeckern, wie oben schon geschrieben wurde, und die nun alle Loglevel "error" bekommen haben, nichts was ich weiter tun könnte und das bei dem sau Wetter
-
@sigi234 ich mache das immer direkt in PROD...wer nicht wagt der nicht gewinnt oder so
NACHTRAG: hab aber auch immer nen Proxmox-Backup und ioBroker-BKP an der Hand
-
3.3.2 versucht ja Massen an Warnmeldungen. Besonders stark bei mir betroffen sind netatmo und stiebel-isg
-
@th-g
Issues mit den Meldungen öffnen, danach vielleicht das log level auf error setzen. -
@jan1 Gib mal deine UUID von der Installation ... ich bau extra für dich in die nächste Version ein paar schöne Fehler ein, ok?
-
@apollon77
Nein, bitte keine extra Mühen, nur weil das hier fast zu rund läuft
-
Hallo,
habe das update gemacht und es kommen jetzt diese Meldungen.
Die verstehe ich zwar, nur kommen die von verschiedenen Adaptern und diese habe ich ja nicht selber angelegt.
Könnte es was damit zu tun haben ?
-
@knallix
Für jeden betroffenen Adapter auf github ein entsprechendes Issue eröffnen, falls es noch keines gibt.Exemplarisch für den info-Adapter z. B.:
https://github.com/iobroker-community-adapters/ioBroker.info/issues/269
closed Log-Eintrag mit js-Controller 3.3.1 #269
-
@homoran sagte in js-controller 3.3 jetzt im Latest:
leider bekomme ich den iobroker nicht gestoppt,
Ich konnte ioBroker auch nicht stoppen und zwar ohne weitere Meldung... habe dann den admin gestoppt und wieder gestartet, dann ging es.
@apollon77 ein issue wert? -
@fredf ist schon bekannt
-
@fredf sagte in js-controller 3.3 jetzt im Latest:
Ich konnte ioBroker auch nicht stoppen und zwar ohne weitere Meldung
ich hatte bei mir dann einfach den NUC rebooted, danach ging es.
später hatte ich einige code7 (already running) im log vor dem reboot gesehen.
wahrscheinlich hatte das den stop vereitelt -
@thomas-braun said in js-controller 3.3 jetzt im Latest:
@knallix
Für jeden betroffenen Adapter auf github ein entsprechendes Issue eröffnen, falls es noch keines gibt.Exemplarisch für den info-Adapter z. B.:
https://github.com/iobroker-community-adapters/ioBroker.info/issues/269
Okay mache ich. Danke
Hatte erst gedacht das es vielleicht am Update liegt.. Da so viele betroffen sind -
@knallix sagte in js-controller 3.3 jetzt im Latest:
Hatte erst gedacht das es vielleicht am Update liegt
Klar liegt das 'am Update'. Der js-controller ist jetzt etwas strenger was die types angeht. Da sind jetzt ganz viele Adapter von betroffen. Deswegen ja auch die Issues bei den einzelnen Adaptern, das muss dann dort im Code angepasst werden.
-
Eine notlösung ist ein Downgrade auf js-controller@3.2.16 ist halt ein aspirin.
-
@stratos-gkrekidis
Naja, ist keine Notlösung oder Aspirin sondern die vorgesehene stable-Version, wenn man kein Beta-Testing betreiben kann und/oder will.
Und auch die entsprechenden Informationen zu den Beta-Versionen nicht lesen will. -
@apollon77 sagte: if it's a number we perform additional checks for min and max
Dies hatte ich schon vor langer Zeit angeregt, wurde von @Bluefox aber nur im Javascript-Adapter umgesetzt. Wenn jetzt der js-controller die Prüfungen macht, kann man sie aus dem Javascript-Adapter wieder entfernen. Unterschied: Javascript gibt keine Warnung aus, sondern begrenzt den Wert zwischen min und max.
adapter.js, ab Zeile 1756:
if (!(obj.common.type === 'mixed' || obj.common.type === typeof state.val || obj.common.type === 'array' && typeof state.val === 'string' || obj.common.type === 'json' && typeof state.val === 'string' || obj.common.type === 'file' && typeof state.val === 'string' || obj.common.type === 'object' && typeof state.val === 'string')ist nicht korrekt.
obj.common.type === 'array' && typeof state.val === 'object' || // typeof Array ist objecttypeof state.val sollte bei "object" kein "string" sein.
-
@stratos-gkrekidis leider geht bei mir auch der Downgrade nicht =(, habs installiert, zeigt mir via Shell auch an das 3.2.16 ist,aber im Interface immernoch 3.3.2, hab leider kein bock auf die Fehlermeldungen im log..
gibts ne andere lösung? Im log steht als resultat wenn ich " npm install iobroker.js-controller@3.2.16
> iobroker.js-controller@3.2.16 preinstall /home/pi/node_modules/iobroker.js-controller > node lib/preinstallCheck.js NPM version: 6.14.12 > iobroker.js-controller@3.2.16 install /home/pi/node_modules/iobroker.js-controller > node iobroker.js setup first object _design/system updated npm WARN saveError ENOENT: no such file or directory, open '/home/pi/package.json' npm WARN enoent ENOENT: no such file or directory, open '/home/pi/package.json' npm WARN pi No description npm WARN pi No repository field. npm WARN pi No README data npm WARN pi No license field. npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) + iobroker.js-controller@3.2.16 updated 1 package and audited 930 packages in 18.746s 16 packages are looking for funding run `npm fund` for details found 3 high severity vulnerabilities run `npm audit fix` to fix them, or `npm audit` for details -
@fredf Den kenne wir schon und sind dran, jetzt aber erstmal Family Time sonst krieg ich ärger
3.3.3 kommt heute Abend noch -
@paul53 Der Controller wird jetzt warnen, in einer Späteren version das "set" ablehnen. Die Entwickler müssen sauber arbeiten. Der Javascript Adapter ist eher auf die "End-Nutzer" ausgerichtet, daher wird dort der Wert angepasst ... ist netter und weniger frustrierend für die Entwickler.
Das andere ist korrekt! Die Typen "array", "json", "file" und "Object" erwarten als Wert einen JSON-stringified Wert des inhaltes.
