Test js-controller v2.0.x (GitHub)

[apollon77]

@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.

[apollon77]

@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

[Adnim]

@apollon77

ja hat etwas gedauert, aber dann direkt gefunzt und hochgelaufen!

[e-i-k-e]

@apollon77

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

[apollon77]

@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

[AlCalzone]

@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?

[msauer]

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

[apollon77]

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.

[apollon77]

@msauer

Fixe ich. Danke fürs melden

[darkiop]

@apollon77

Hab das heute nochmal nachgestellt:

Ausgangsbasis:

1. iobroker-master 1.5.14, im docker-container unter node 8, file/file
2. iobroker-hwr 1.5.14, auf RPI4 unter Node 10, file/file
3. 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:

[apollon77]

@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

[MathiasJ]

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.

[darkiop]

@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  - warn: ical.0 (7513) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:21.906  - warn: ical.4 (7597) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:21.908  - warn: ical.2 (7529) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:21.903  - warn: ical.3 (7585) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:21.915  - warn: ical.1 (7520) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:21.914  - warn: yr.0 (7507) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:21.933  - warn: ical.5 (7603) Cannot connect/reconnect to objects DB. Terminating
2019-09-30 18:00:23.491  - info: host.iobroker-master iobroker.js-controller version 2.0.14 js-controller starting
2019-09-30 18:00:23.504  - info: host.iobroker-master Copyright (c) 2014-2019 bluefox, 2014 hobbyquaker
2019-09-30 18:00:23.505  - info: host.iobroker-master hostname: iobroker-master, node: v8.16.1
2019-09-30 18:00:23.508  - info: host.iobroker-master ip addresses: 192.168.1.82
2019-09-30 18:00:26.487  - info: host.iobroker-master connected to Objects and States
2019-09-30 18:00:26.944  - info: host.iobroker-master 86 instances found
2019-09-30 18:00:27.048  - info: host.iobroker-master starting 42 instances
2019-09-30 18:00:28.007  - info: host.iobroker-master instance system.adapter.admin.0 started with pid 8270
2019-09-30 18:00:28.162  - warn: host.iobroker-master Multihost discovery server: service started on 0.0.0.0:50005
2019-09-30 18:00:28.178  - warn: Error from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f
2019-09-30 18:00:28.179  - warn: 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.

[Stuebi]

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

[apollon77]

@MathiasJ 1.0.8 war kaputt, 1.0.9 ist da

[apollon77]

@darkiop Und was ist 18 Uhr passiert? oder da wo der Spuk los ging?

[e-i-k-e]

erledigt

[lobomau]

Muss man auch den Master beenden um das Update auf den slave zu spielen? Habe ich noch nicht ausprobiert.
Bisheriger Versuch auf Pi3-Slave zu installieren schlug fehl.
Probleme: iobroker status sagt immer iobroker running obwohl vorher beendet. Fix habe ich auch schon vorher durchlaufen lassen.
Version:
npm: 6.9.0
nodejs: 10.6.3

pi@Pi3:/opt/iobroker $ sudo iobroker status
iobroker is running

Objects type: file
States  type: file
pi@Pi3:/opt/iobroker $ sudo iobroker stop
pi@Pi3:/opt/iobroker $ sudo npm install ioBroker/ioBroker.js-controller
npm ERR! code 128
npm ERR! Command failed: git clone --mirror -q git://github.com/ioBroker/ioBroker.js-controller.git /root/.npm/_cacache/tmp/git-clone-ca0fa90a/.git
npm ERR! fatal: could not create leading directories of '/root/.npm/_cacache/tmp/git-clone-ca0fa90a/.git'
npm ERR!

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-09-30T19_54_21_045Z-debug.log
pi@Pi3:/opt/iobroker $ sudo iobroker status
iobroker is running

Objects type: file
States  type: file

[febea]

@apollon77 said in [Aufruf] js-controller 2.0 Beta Test:

@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

Wie kann ich das log sichern? Einfach alles markieren und speichern oder gibt es da direkt ein file?

[darkiop]

@lobomau Prüf mal mit

ps -ef | grep ^io

Ob noch ein Prozess vom ioBroker läuft, und wenn ja kannst du diesen per

kill -9 PROCESS-ID

oder

pgrep -f '^io.*' | xargs kill -9

auf die sanfte Art beenden