js-controller 3.3 jetzt im Beta
-
Der Installer ist jetzt auch auf 3.3.21 und damit stable auch
-
-
@bbtown Repo sollte zwar jetzt gebaut sein, denke aber das das CDN noch bissl braucht bis es sich verteilt hat ...
-
@apollon77
na gut
-
Last login: Sun Nov 28 22:38:13 2021 from 100.75.198.95 pi@chet:~ $ iobroker update -u Used repository: live-beta hash changed or no sources cached => force download of new sources update done Controller "js-controller" : 3.3.21 , installed 3.3.20 [Updateable] All adapters are up to date pi@chet:~ $ -
@thomas-braun
@apollon77
jupp, nun ist er auch bei mir verfügbar
EDIT
keine Auffälligkeiten mit der v3.3.21
(hatte ich allerdings auch nicht mit der v3.3.20)
ich habe ein Single Host System -
Hier auch alles sauber mit 3.3.21 wie schon mit .20 als single Host.
-
auch da alles sauber gestartet. bisschen zäh wars diemal...
single host -
@apollon77 sagte in js-controller 3.3 jetzt im Beta:
Der Installer ist jetzt auch auf 3.3.21 und damit stable auch
Wird mir im stable nicht angeboten. Habe gestern Mittag von 3.3.18 auf 3.3.20 aktualisiert. Erst nach Umstellung auf beta wird die 3.3.21 angezeigt. Wieder zurück auf stable verschwindet die Anzeige aber wieder (Synology mit Buanet-Docker-Image).
-
Ist wohl gerade im Anmarsch. Wir sprechen gerade hier darüber:
https://forum.iobroker.net/topic/49823/update-host-unter-windows/13?_=1638273689714
-
@ofbeqnpolkkl6mby5e13 sagte in js-controller 3.3 jetzt im Beta:
@apollon77
Zu den im JS-Controller eingeführten Warn-Meldungen (State-Änderung eines nicht vorhandenen Objekts) habe ich eine Frage. Da wurden jetzt viele Adapter angepasst, aber bestimmte Situationen sind bisher nicht berücksichtigt worden. Z. B. wenn man ein neues Gerät bei einem Cloud-Adapter hinzufügt (Alexa2 oder HMIP), dann gibt es zurzeit auch noch diese Meldungen. Was soll geschehen, wenn ihr zukünftig restriktiver damit umgehen wollt?@apollon77
War meine Frage so dumm oder hast du es übersehen? -
@ofbeqnpolkkl6mby5e13 Es wird in der kommenden 4.0 noch nicht restriktiver damit umgegangen. Danach werden vermutlich auch erst mal invalide Objekte nicht mehr angelegt, da hier die meisten Probleme meines Wissens nach behoben sind.
Die State Meldungen werden voraussichtlich erst mal von
infoaufwarnhochgestuft, aber das hat alles noch etwas Zeit (nicht v4) und Hoffnung, dass bis dahin die meisten Adapter gefixt sind.Kurzum: Als Nutzer sollte man sich hierum keine Sorgen machen, wir werden nichts ändern was 100 Adapter kaputt macht ohne diese vorher anzupassen.
-
@foxriver76
Okay, danke für die Rückmeldung! -
@ofbeqnpolkkl6mby5e13 Klar übersehen, aber @foxriver76 hat schon geantwortet.
Wichtig ist das es bitte GitHub Issues gibt wenn solche Fälle passieren. Alexa2 und auch HMIP sollte das Problem aber in den aktuellest ( ggf Beta) VErsionen nicht mehr haben
-
Wo darf denn der Bug hin dass die default debounce Zeit des history Adapters bei bestimmten states nicht genommen wird und dann gar kein Wert im RAW steht? Das führt dazu dass beim Editieren des Feldes ein Fehler fliegt bis eine Zahl >= 500 enthalten ist.
Hat mMn nichts mit dem history Adapter selbst zu tun.
Ich hatte lange Zeit den materialUI Adapter in Verwendung und mittlerweile deinstalliert.
Im RAW einiger 300 Objekte stehen nun noch weiterhin die material Settings. Das bläht durch base64 Icons usw. die object.json bei mir um mehrere MB auf. Wenn ich es im RAW lösche, wird es beim Speichern wieder reingeschrieben.
Wie wird man derartige Altlasten los? -
@apollon77
Ich dachte mir schon, dass das missverstanden wurde. Ich rede von einem Fall, der vermutlich nur bei Cloud-Adaptern auftritt. Nur darum geht es:HmIP-Adapter: Füge ein neues Gerät dem HAP hinzu. Dann rauschen über die API State-Änderungen für ein Gerät rein, die der Adapter noch nie zuvor gesehen hat.
Alexa2-Adapter: Bestelle einen neuen Echo bei Amazon. Amazon wird das Gerät zu deinem Konto hinzufügen noch bevor das Gerät überhaupt bei dir angekommen ist. Der Alexa2-Adapter traut seinen Augen nicht wegen der State-Änderungen eines Gerätes, das er noch nie gesehen hat.
-
@diginix sagte in js-controller 3.3 jetzt im Beta:
Wo darf denn der Bug hin dass die default debounce Zeit des history Adapters bei bestimmten states nicht genommen wird und dann gar kein Wert im RAW steht? Das führt dazu dass beim Editieren des Feldes ein Fehler fliegt bis eine Zahl >= 500 enthalten ist.
Formal zu aadmin weil der adapter machts richtig in der jsonConfig ... aber admin zeigt das nicht korrekt darzustellen
-
@ofbeqnpolkkl6mby5e13 Ahh ok .. .ja beides Sonderfälle ... bräuchte man mal Debug logs von so einem fall das man das anschauen kann
-
@apollon77
Mache ich bei Gelegenheit. -
@apollon77 sagte in js-controller 3.3 jetzt im Beta:
@diginix sagte in js-controller 3.3 jetzt im Beta:
Wo darf denn der Bug hin dass die default debounce Zeit des history Adapters bei bestimmten states nicht genommen wird und dann gar kein Wert im RAW steht? Das führt dazu dass beim Editieren des Feldes ein Fehler fliegt bis eine Zahl >= 500 enthalten ist.
Formal zu aadmin weil der adapter machts richtig in der jsonConfig ... aber admin zeigt das nicht korrekt darzustellen
Ne, also in der object.json steht dann auch "debounce": "". Aber ich mach mal ein admin issue auf.
