js-controller 3.3 jetzt im STABLE!
-
@bjoern77 Dennoch sehr komisch und ungewöhnlich
-
@paul53 java script ist auf 5.1.3 es ist nicht >5.2
ical kalender ist auf 1.11.2 -
@exitus sagte: java script ist auf 5.1.3 es ist nicht >5.2
ical kalender ist auf 1.11.2Dann ist iCal schon auf die Änderungen im js-controller (JSON statt Objekt) umgestellt, Javascript aber noch nicht. Passen also nicht zueinander, was zu dem Fehler führt.
-
Da Testsystem und nicht so oft benutzt habe ich nun nach Aktualisierung den folgenden Fehler:
Redis error:Error: Invalid Chunk: parse failed
obwohl dort redis für iobroker nicht konfiguriert ist.
Mehr Details hier:
https://forum.iobroker.net/topic/46803/redis-error-error-invalid-chunk-parse-failed?_=1628246890838 -
@oliverio Schaue dort, AUch die iobroker eigene DB nutzt seit controller 2.0 das Redis Protokoll unter der Haube
-
@paul53 danke paul ich habe unter einstellung auf Beta gestellt und dann musste ich Admin Adapter Updaten damit ich Java script updaten konnte.
Habe Admin Adapter auf 5.1.23 und java auf 5.2.6 danach lief es .
Danke -
@exitus Admin5 und die ganzen Deps kommen heute Abend
-
@apollon77
Vielen Dank für die stetige Aktualisierung und Weiterentwicklung!Mir juckt es etwas in den Fingern, aber da doch auf einige Meldungen verwiesen wird, würde ich gerne vorab das Fallback-Szenario erfragen (Linux)?
Falls Die Fehlermeldungen/Probleme doch zu massiv werden, gibt es eine empfohlene und erprobte Methode außer ggf. eine komplette Neuinstallation mit dem Restore eines Backups?
Besten Dank!
-
@pete0815 Steht zwar im ersten Post drin aber ich kopiere es gern nochmal hierher
Die alte Version des js-controller kann im Notfall einfach wieder per npm install iobroker.js-controller@version (ausgeführt im ioBroker-Verzeichnis, z.B. /opt/iobroker) installiert werden und sollte alles wieder herstellen.
-
@pete0815
Ein Restor eines Backup empfiehlt sich auch so ab und an mal zu tätigen, weil es das System sauber hält. Somit ist das die schnellste, einfachste und beste Art. Hier sollte dann auch der IOBroker Ordner sauber gelöscht werden und außer ner IOBroker Neuinstallation samt dem Backitup Adapter nichts drauf sein
Also alles andere als ne gefährliche Aktion bei der man ein Linux Nerd sein muss.
Edit:
Oder man machts wie apollon schon geschrieben hat, wie es im ersten Post dazu schon steht, was natürlich auch geht, aber das eventuell unsaubere System eben auch unsauber lässt. -
Dass der Admin5 und der Javascript Adapter nicht gleichzeitig mit dem js-controller ins stable gegangen sind war natürlich etwas unglücklich.
Aber ich muss jetzt echt mal sagen, nachdem ich jetzt alle Fehler bei mir im System ausgebügelt habe läuft mein System mit dem js-controller 3.3 1000 mal stabiler als vorher! Wirklich super arbeit!
-
@fabian1 Admin5 ist noch nicht im Stable.
-
@apollon77 said in js-controller 3.3 jetzt im STABLE!:
@pete0815 Steht zwar im ersten Post drin aber ich kopiere es gern nochmal hierher
Die alte Version des js-controller kann im Notfall einfach wieder per npm install iobroker.js-controller@version (ausgeführt im ioBroker-Verzeichnis, z.B. /opt/iobroker) installiert werden und sollte alles wieder herstellen.
Ups, vielmals sorry. Das habe ich dann mehrfach überlesen
@Jan1
Ja, das Restore ist auch weniger mein Problem. Eher die Neuinstallation wozu ich örtlichen Zugriff auf die SSD brauche(den ich erst heute Abend hab). Den Rest kann ich so übers Netzwerk erledigen/schon mal anstoßen. -
@ahnungsbefreit ja das meine ich ja! Das ist etwas unglücklich, da der Admin5 voraussetzung für den Javascript Adapter ist, der 100%ig mit dem js-controller 3.3 funktioniert. Also alle die im Moment auf stable sind, kriegen unter umständen Probleme mit ihren skripten. Aber wie apollon geschrieben hat, ändert sich das ja heute abend.
-
@pete0815
Hatte sich eben so angehört, das Du ein Restor des IOBroker als was "Großes" empfindest, deshalb auch mein Text dazu.
Ich hatte im Beta auch schon das ein oder andere Mal den Weg über das Kommando gewählt, weil es wenn sonst wirklich alles sauber ist, eben doch wesentlich schneller geht und ausreichend ist um die alte Version wieder herzustellen. -
Hi,
gestern Abend von JS-controller 3.2.16 auf 3.3.15 geupdated:Kurzfassung:
Fehler: KEIN JS-Script mehr in Script-Anzeige bzw. startend / arbeitend, obwohl offenbar alle noch vorhanden!Dabei keine Fehlermeldung bei Update oder (diesbzgl.) im Betrieb!
Details:
Brav wie in Anleitung beschrieben:- erst Master, dann die Slaves (1 Host-Master, insg. 8 Slaves, alle Raspi 4b bzw. 3b oder 3, bevor sich wer wundert: ist inkl. Remote angebundene Pflegewohnung der Eltern, lastverteilt wg. Wichtigkeit);
- Alle vorher auf aktuellem Stand gebracht bzgl. Adapter-Updates etc.
- alle Slaves nacheinander durchlaufen lassen, danach sogar erst einzelnes Reboot, bevor nächster dran war
- alles ohne Fehlermeldungen durchgelaufen, sauber wieder gestartet
- und bis auf diverse Wertebereichs- oder -typ-Meldungen auch alles fehlerfrei laufend
ABER nun:
- KEIN JS-Script wird mehr angezeigt unter "Scripts"
- und offenbar auch keins ausgeführt!
Neustart (Adapter, Javascript-Adapter tragende Slaves, Host-Master) bringt nichts,
keine Fehlermeldungen dazu im Log
im Gegenteil:-
Es werden bei Adapter-Neustart alle Script-Verzeichnisse korrekt als "registrierend" aufgelistet,
-
unter "Objekte" / "Javascript.n" liegen die Scripts alle noch unverändert da, ebenso auf dem externen Spiegel-Pfad (natürlich nicht auf Raspi-SD-Karte, sondern seit Jahren stabil auf gemountetem dafür exclusivem SSD-Drive im QNAP-NAS)
-
Alles funktioniert ansonsten problemlos und performant, auch übergreifend (Alexa-Befehle per IOT-Adapter, Steuerung per Szenen etc.),
nur starten / erscheinen im Editor absolut KEINE SCRIPTS !!:
- weder event-getriggert,
- noch scheduled
Konfiguration:
- REDIS-DB
auf exclusiver externer USB-SSD-Platte am HOST-Master (Raspi 4b / 8GB RAM), bisher noch nicht verteilt als 3-Disk-REDIS-Cluster - Javascript.0 (PROD) und .1 (DEV),
auf je einem Raspi4B/8GB, (zzgl. je einer rpi2-Instanz zur Raspi-Eigenüberwachung) exclusiv laufend - Script-File-Spiegel für beide Instanzen über Javascript.0
HOST-Master:
- Node.js: v12.21.0
- NPM: 6.14.11
Slave 6 (javascript.1) und Slave 7 (javascript.0):
- Node.js: v12.20.1
- NPM: 6.14.10
Woran kann das liegen?
-
ich habe KEINE JS-Instanz auf dem HOST-Master! Der hat wichtigeres zu tun: Alle Infos, Geräte und REDIS koordinieren! (Backitup meckert darüber zwar beim Konfigurieren der JS-Sicherung "keine JS-Instanz auf HOST (er kann ja nur auf Master intalliert werden), tut's dann aber doch.)
-
Ich habe noch nicht versucht, die Scripts neu einzuspielen. Sie sind ja (eigentlich) noch da..... Es erscheint eher, als wenn da wo ein "enabled" für die (sauber gün erscheinende) JS-Instanzen aus ist, finde aber nix dazu
-
keinen Bock / Zeit, schon wieder alles neu aufzusetzen! Noch etwas gefrustet von letztem Raspi-(3 -> 4) Transfer, als kein Einspielen einer Sicherung / auch nicht gespeicherte JS ging, sondern alle gut 100 Skripts brav neu einzeln aus dem alten Spiegel per copy/paste neu angelegt werden mussten.... Wochen knapper Zeit für Weiterentwicklung / Veröffentlichung hier verloren! Nun schon wieder???? grrrrrr.....
Nebenkriegsschauplätze
hier noch der Vollständigkeit halber einige andere Fehler (Werte-max- oder Typ-Fehler):
- HM-RPC: HM-IP-Heizungsthermostaten (HmIP-eTRV-2) Level Ventilöffnung max = 1.01, aber real Integer-Prozentwert (0..100) kommend
- HM-RPC: Cux / bei allem enocean-Devices (bei mir alle Hoppe-Fenstergriffe bzw. Solar-Magnetkontakte an Velux-Fenstern): max-Wert bei Chn 0: RSSI_PEER auf 0, ankommende Werte aber Integer > 0, der Min-Wert steht auf negativ (-255), offenbar missinterpretierter Wertebereich?
Update: Betrifft NICHT auch alle FS-20- oder HMS-100-Funk-Devices per Cux, da kommen RSSI-PEER-Werte wirklich negativ, max=0 rein! - Netatmo / alle Wetterstations-Geräte: ....LastUpdate" has to be type "datetime" but received type "string"
- Roomba: refreshedTimestamp" has to be type "string" but received type "number"
dto bei: commands.last.timestamp und states.signal, - Luftdaten: location.longitude" has to be type "number" but received type "string"
dto bei location.latitude und location.altitude
-
@bb61 Welche Version des Javascript Adapters und welche Admin version. Ich würde an deiner Stelle mal kurz auf beta umstellen und auf Admin5 und danach den javascript Adapter auf 5.2.8 updaten. Beides kommt heute abend sowieso ins stable.
-
@fabian1
wurden beide gestern abend noch VORHER aktuell (stable) gemacht, so nicht schon längst passiert:Admin: 4.2.2 (HOST-Master als auch Slaves mit JS-Instanz)
JS: 5.1.3 -
wg. Beta benutzen:
ähm..... wenn ich Zeit dafür hätte, gerne. Aber es geht hier um ausgefallene Benachrichtigung bei Vitalüberwachung und Notfall. Ich darf mich jetzt ins Auto setzen und 250km entfernt klassische Technik wieder hochfahren und Pflegedienst "uminformieren".Danach sicher nicht noch mehr "rumexperimentieren" werde. Das ging monatelang gut und sehr stabil! Wenn, dann maximal Rück-Downgrade auf alten Stand wie von Apollon oben beschrieben, das aber auch nicht vor Ende nächster Woche (ab mo auf Dienstreise....) Wenn, dann passt sowas natürlich BESTENS! :-(((
-
...und ganz sicher nicht noch ne weitere Baustelle an weiterer Kernkomponente aufmachen werde. Bei uns in der Firma wäre so etwas .... naja derjenige nicht mehr lange da.
Ich wollte nur fix das Problem loswerden und WARNEN was da an sauberen Systemen passiert!
Mitarbeit / eigene weitere Recherche und Versuche gerne, aber erst wenn ich wieder da bin. Real Live hat Prio!
