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

[darkiop]

@paul53 Ok, wieder was gelernt

Aber ... ich habe darüber die Instanz bring.0 aktiviert und nach dem durchstarten des iobroker vergisst er das wieder ... irgendwie ist bei mir der Wurm drin

[darkiop]

@Stabilostick hat hier leider nicht geholfen.

[darkiop]

Bin zurück mit beiden auf 1.5.14 - jetzt klappt das auch wieder mit dem Merken welchen Instanzen aktiv sein sollen nach einem Neustart ...

[Stuebi]

@ChrisXY sagte in [Aufruf] js-controller 2.0 Beta Test:

@Stuebi Uhh das hört sich ja sehr gut an. Bin sehr gespannt Danke

kannst du bitte nochmals die Version 1.0.5 von Github installieren und den Adapter neu starten. ich bin auf Dein Testergebnis gespannt.

[Stabilostick]

@darkiop was hast Du denn gemacht? War die IPv4 dann da und es ging trotzdem nicht?

Ist bei 1.5.14 immer eine IPv4 beim Start des js-Controllers im Log an der Stelle vorhanden?

[darkiop]

@Stabilostick @apollon77

was hast Du denn gemacht? War die IPv4 dann da und es ging trotzdem nicht?

Den Workaround mii-tool -r eth0ausprobiert, dann den Sleep im Startkskript rausgenommen und durchgebootet.

Ist bei 1.5.14 immer eine IPv4 beim Start des js-Controllers im Log an der Stelle vorhanden?

Wir kommen der Sache näher! Nein unter 1.5.14 war auch keine IPv4 zu diesem Zeitpunkt vergeben, was aber keine Auswirkung auf den js-controller hatte - der wurde trotzdem gestartet. Mach ich das selbe mit 2.0.x crasht der js-controller.

Log / Erklärung:

20:08 --> sleep im Start Skript deaktiviert und reboot
20:11 --> sleep im Stark Skript aktiviert und reboot

┬─[darkiop@iobroker-hwr:/opt/iobroker/log]─[20:12:12]
╰─>$ cat iobroker.2019-10-01.log | grep "host.iobroker-hwr ip addresses"
2019-10-01 20:08:49.178  - info: host.iobroker-hwr ip addresses: 
2019-10-01 20:11:10.254  - info: host.iobroker-hwr ip addresses: 10.3.1.22 fe80::dea6:32ff:fe17:78f5

js-controller crash mit 2.0.x ohne IP beim Start des Prozesses:

2019-10-01 19:02:15.589  - info: host.iobroker-hwr ip addresses: 
2019-10-01 19:02:15.610  - error: host.iobroker-hwr uncaught exception: connect ENETUNREACH 192.168.1.82:9001 - Local (0.0.0.0:0)
2019-10-01 19:02:15.611  - error: host.iobroker-hwr Error: connect ENETUNREACH 192.168.1.82:9001 - Local (0.0.0.0:0)
    at internalConnect (net.js:881:16)
    at defaultTriggerAsyncIdScope (internal/async_hooks.js:294:19)
    at defaultTriggerAsyncIdScope (net.js:971:9)
    at process._tickCallback (internal/process/next_tick.js:61:11)

[e-i-k-e]

Zu meinem Backup Problem.

Umzug Rock64 Master auf Intel NUC (Debian) . (Js-controller 2.0.17)

Nach langem hin und her läuft das System jetzt einigermaßen.

Mein ioBroker hat Probleme einige "vis" npm Pakete zu installieren (ab ca. 20.30 Uhr) . Anbei der aktuelle log. iobroker.2019-10-01.log

[ChrisXY]

@Stuebi Danke. Schaut gut aus kein Fehler und die History sachen rasen bei Debug sauber durch.

[Stuebi]

@ChrisXY , Klasse dann publishe ich das nachher auf npm

[ChrisXY]

@apollon77 also Redis scheint zu klappen.
Habe den Redis im selben Docker. Ping ist möglich und auch root@iobroker:/opt/iobroker# redis-cli -h 192.168.2.203 ping
PONG

Sollte also nicht das problem sein ?

[apollon77]

@lobomau Zwei Dinge dazu:

iobroker status liefert die Info ob das ipBroker-System läuft. Auf einem Slave gestartet mit einem laufenden Master wird immer die Meldung sein "iobroker running" weil der Master läuft.

Um das Update einzuspielen reicht es aber wenn der Slave beendet ist.

Zu deinem Fehler: Siehe oben erster Beitrag. Leider gibt es diesen Fehler aktuell wegen NPM-foo ... "sudo -u iobroker -H nom install ioBroker/ioBroker.js-controller" ausführen. Das tut wohl

[apollon77]

@darkiop Also das darf an sich nicht passieren. Ja, nach dem Restore sind erstmal alle Adapter ausser Admin deaktiviert. Kann er bei änderungen das objects.json File (glaube bist ja nicht auf Redis) neu schreiben? Nicht das da was kaputt ist. Wenn Du den Adapter im Admin wieder aktivierst muss das persistiert werden ... Schau mal ob sich das File Date ändert.

[lobomau]

@apollon77 top. Installation scheint zu laufen. Danke.

[apollon77]

@darkiop Ok, das war alles super. Ich habe gefunden das "ioredis" (Die Redis Protokoll Lib) default "family" IPv4 hat ... mal schauen was ich da setzen kann ... Ich mache gleich eine neue Version, bitte damit neu testen, damit sollten an sich beide gehen (laut doku )

[apollon77]

@e-i-k-e Da steht überall Version 1.2.1 ... das kann nicht passen. Am besten installiere einfach die "npm latest" version entweder per npm direkt oder per Admin neu.

[apollon77]

@ChrisXY Vllt liegt es wie bei @darkiop an IPv4 vs IPv6 auch bei dem connect auf localhost .. am besten auch mal die nächste Version checken

[apollon77]

Version 2.0.18 ist auf GitHub, und sollte jetzt IPv4 UND IPv6 machen ... please check

[apollon77]

@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:

Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.

Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?

[apollon77]

@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:

Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.

Lass doch mal in Debug Modus laufen und schau mal log an

[Stabilostick]

@darkiop

Ändert ein

sudo rpi-update

etwas am Verhalten?