NEWS
Test js-controller v2.0.x (GitHub)
-
@Ritter wie es oben steht. Ins iobroker Verzeichnis wechseln. Dort den npm Befehl (der einfache ohne sudo kram)
-
Ok, hatte ich vorhin schon mal probiert. Unter VIS waren dann die eigenen Bilder die ich hinzugefügt habe nicht mehr vorhanden. Im iobroker Verzeichnis sind sie aber noch da, nur unter VIS edit sind sie nicht sichtbar (png und jpg getestet). Bei iqontrol sind keine Werte mehr vorhanden.
-
@Ritter iqontrol updaten... siehe text oben im ersten Beitrag.
Vis Bilder: kann es sein das du selbst Bilder ins iobroker-data/files reinkopiert hast? Dann siehe bitte faq im zweiten post.
-
Die Bilder sind in dem Verzeichnis und da waren sie schon immer. Die faq habe ich gelesen, verstehe aber trotzdem nicht was zu tun ist.
-
Habe heute ein neues System aufgesetzt, dann den js-controller installiert. Während der Installation alles OK nur Warnungen, aber im Hosts wird weiterhin 1.5.x angezeigt, nix von 2.x zu sehen. Alles läuft weiter wie vorher.
Kann ich nachsehen ob 2.x wirklich installiert ist? mfg Christian -
@Ritter da waren sie schon immer heißt nicht das das offiziell vom System unterstützt wird. Bitte in Eis der validen Verzeichnisse legen wie vis.0 oder so. Und ja dann leider Pfade anpassen.
Das das bisher tat war gelinde gesagt Zufall. Eigene files sind nicht im Backup und hätten auch sonst jederzeit kaputtzugehen können.
-
@febea wenn im Host noch 1.5.x angezeigt wird dann Hatvda was nicht geklappt. Hast damals das install log vom js-Controller Update? Sonst mach’s nochmal drüber
-
ja hat etwas gedauert, aber dann direkt gefunzt und hochgelaufen!
-
anbei mein log mit dem Versuch in eine neuer und saubere ioBroker installation das backup von meinem Master (nach deinen Steps) einzufügen.
iobroker.2019-09-28.log -
@e-i-k-e Naja bei sowas ist das Konsolenlog (also was stand wie in der Konsole als Du es gemacht hast) nötig ... das iobroker log sagt nur das deine DB leer ist
-
@febea sagte in [Aufruf] js-controller 2.0 Beta Test:
Alles läuft weiter wie vorher.
Hast du ioBroker neu gestartet bzw. vor dem Upgrade beendet?
-
Ich habe, wegen einem Fehler im Adapter NINA, diesen mal deinstalliert. Letztens hatte ich so was schon mal, habe dem aber keine Beachtung geschenkt.
Heute jedoch wollte ich das doch mal posten, da iobroker bzw. der js-controller komplett neu gestartet ist.host.MSNUC-IOB 2019-09-30 09:28:48.591 error at Timer.processTimers (timers.js:223:10) host.MSNUC-IOB 2019-09-30 09:28:48.591 error at listOnTimeout (timers.js:263:5) host.MSNUC-IOB 2019-09-30 09:28:48.591 error at tryOnTimeout (timers.js:300:5) host.MSNUC-IOB 2019-09-30 09:28:48.591 error at ontimeout (timers.js:436:11) host.MSNUC-IOB 2019-09-30 09:28:48.591 error at Timeout.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobroker.js-controller/main.js:3272:43) host.MSNUC-IOB 2019-09-30 09:28:48.591 error TypeError: Cannot read property 'process' of undefined host.MSNUC-IOB 2019-09-30 09:28:48.589 error uncaught exception: Cannot read property 'process' of undefined host.MSNUC-IOB 2019-09-30 09:28:47.768 info iobroker npm uninstall iobroker.nina --silent --save --prefix "/opt/iobroker" (System call) host.MSNUC-IOB 2019-09-30 09:28:47.768 info Do not restart adapter system.adapter.nina.0 because disabled or deleted host.MSNUC-IOB 2019-09-30 09:28:47.767 error instance system.adapter.nina.0 terminated with code 156 (156) host.MSNUC-IOB 2019-09-30 09:28:47.587 info stopInstance system.adapter.nina.0 send kill signal host.MSNUC-IOB 2019-09-30 09:28:47.585 info stopInstance system.adapter.nina.0 host.MSNUC-IOB 2019-09-30 09:28:47.584 info object deleted system.adapter.nina.0
-
Hey All, ich habe gerade radar2 1.0.8 veröffentlicht mit dem Fix. Das wird quasi die offiziell kompatible Version. GitHub Stand bleibt erst einmal kaputt bis Frank wieder verfügbar ist.
-
Fixe ich. Danke fürs melden
-
Hab das heute nochmal nachgestellt:
Ausgangsbasis:
- iobroker-master 1.5.14, im docker-container unter node 8, file/file
- iobroker-hwr 1.5.14, auf RPI4 unter Node 10, file/file
- Upgrade mit sudo -H -u iobroker npm install ioBroker/ioBroker.js-controller, zuerst der Slave, dann der Master
Nach den beiden Upgrades folgendes im Log:
Dann Reboot des Slaves + Master, Log:
Der Slave kommt dann auch nicht mehr automatisch auf die Beine nach einen Reboot, starte ich ihn aber manuell mit iobroker start schafft er es:
-
@darkiop Ok, ich sehe im Log folgendes. Bitte sag mal ob das ok ist:
- 13:59-14:05 hast Du den Slave auf 2.0.4 aktualisiert. Der Master lief noch. Der Slave hat danach (weil Master alt war) im "Fallback Modus" sich verbunden
- 14:16 hast Du den Master beendet, 14:25 war er zurück. Der Slave hat sich in der zwischenzeit immer wieder neu gestartet und dann sah es aber so aus als ob 14:25 wieder alles ok war.
Dann schreibst DU das Du rebootest hast alle beide und sich dann der Slave so verhalten hat ?! Komisch
Der Slave sagt das er Port 9001 vom Master nicht erreichen kann. ENETUNREACH. Sieht mir also eher nach irgendwas netzwerkigem aus ... Der -hwr meldet sich mit ner 10er IP ... ist das bei dir so aufgesetzt auf dem Raspi?
Mit dem was ich generell sehe hat sich alles korrekt verhalten. Die Frage ist was zu dem EHOSTUNREACH geführt hat
-
Radar2-Downgrade auf 1.08, Objekt UWZ (Unwetterwarnung) fehlt,
Keine BT LE-Scan mehr möglich. mein G-Tag wird nicht mehr gefunden.
Update zurück auf 1.2.0
Zurück auf 1.2.0 ist mein G-Tag wieder erreichbar.
dafür wieder die Fehlrmeldung:radar2.0 2019-09-30 18:28:00.577 warn (13080) No geo location data found configured in admin to calculate UWZ AREA ID or ID not valid!
Jetzt kommt auch noch ein
host.pivccu 2019-09-30 18:54:04.523 info instance system.adapter.radar2.0 terminated with code NaN () host.pivccu 2019-09-30 18:54:04.523 warn instance system.adapter.radar2.0 terminated due to SIGSEGV
Ein pkill -f Radar2 hat nichts gebracht.
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
EHOSTUNREACH
Ja passt so wie du es beschrieben hast. Bin auch gerade nach Hause gekommen und musste feststellen das mein Schalter fürs Garagentor ohne Funktion war. Auf master und slave hat sich jeweils der komplette Stack verabschiedet.
Aktuell habe ich jetzt jeweils nen tail -f laufen und beobachte ...
Das mit der IP passt, der Raspi ist in einem VLAN für IOT Geräte, der Docker Container aber noch nicht - trotzdem sollte hier seitens Netzwerk nichts im argen liegen ... das läuft auch so schon einige Monate.
Folgendes hab ich im Log von vorhin gefunden:
2019-09-30 18:00:21.905 - [33mwarn[39m: ical.0 (7513) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:21.906 - [33mwarn[39m: ical.4 (7597) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:21.908 - [33mwarn[39m: ical.2 (7529) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:21.903 - [33mwarn[39m: ical.3 (7585) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:21.915 - [33mwarn[39m: ical.1 (7520) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:21.914 - [33mwarn[39m: yr.0 (7507) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:21.933 - [33mwarn[39m: ical.5 (7603) Cannot connect/reconnect to objects DB. Terminating 2019-09-30 18:00:23.491 - [32minfo[39m: host.iobroker-master iobroker.js-controller version 2.0.14 js-controller starting 2019-09-30 18:00:23.504 - [32minfo[39m: host.iobroker-master Copyright (c) 2014-2019 bluefox, 2014 hobbyquaker 2019-09-30 18:00:23.505 - [32minfo[39m: host.iobroker-master hostname: iobroker-master, node: v8.16.1 2019-09-30 18:00:23.508 - [32minfo[39m: host.iobroker-master ip addresses: 192.168.1.82 2019-09-30 18:00:26.487 - [32minfo[39m: host.iobroker-master connected to Objects and States 2019-09-30 18:00:26.944 - [32minfo[39m: host.iobroker-master 86 instances found 2019-09-30 18:00:27.048 - [32minfo[39m: host.iobroker-master starting 42 instances 2019-09-30 18:00:28.007 - [32minfo[39m: host.iobroker-master instance system.adapter.admin.0 started with pid 8270 2019-09-30 18:00:28.162 - [33mwarn[39m: host.iobroker-master Multihost discovery server: service started on 0.0.0.0:50005 2019-09-30 18:00:28.178 - [33mwarn[39m: Error from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f 2019-09-30 18:00:28.179 - [33mwarn[39m: Error from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f
Edit:
Kurzer Blick aufs LAN, da passt alles wenn er denn läuft.
Edit 2:
Beide laufen jetzt seit einer guten Stunde ohne Auffälligkeiten. Hab auch diverese Aktionen ausgelöst, alles wie gewohnt. Ich befürchte nur, wenn ich durch starte braucht der -hwr wieder Start-Hilfe Ich lass das jetzt mal noch 1-2 Stunden so laufen zum beobachten und starte dann den Slave nochmal durch.
-
Ich habe eben das update auf den js-controller 2.0 Beta auf meinem Entwicklerrechner (macbook, nodejs 10) durchgeführt. Seit dem wird im Visual Studio Code (VSC) kein Logging im Debug Modus angezeigt. Jemand eine Idee was ich dort ändern muss.
hier meine launch.json im .vscode Verzeichnis:
"version": "0.2.0", "configurations": [ { "type": "node", "request": "launch", "name": "Programm starten", "program": "${workspaceFolder}/shelly.js", "cwd": "${workspaceRoot}", "args": [ "--debug", "--force", "--logs", "--trace-warnings" ] }, { "type": "node", "request": "attach", "name": "An den Prozess anfügen", "port": 5858 } ] }
VG
Stübi -
@MathiasJ 1.0.8 war kaputt, 1.0.9 ist da