UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[coyote]

@apollon77 was brauchst du denn genau? Reicht ein redis-cli ping und es kommt ein PONG zurück?
Oder brauchst du redis-cli info?
Redis Server habe ich in der gleichen VM installiert wie iobroker

[darkiop]

@apollon77 Das habe ich, siehe ein paar Beiträge weiter oben. Mit nem sleep 10 bzw. zur Sicherheit sleep 15 läuft es erstmal Quick n Dirty.

Aktuell habe ich das Probelm, das sich ioBroker nicht merkt welche Adapter gestartet sind. Nach einen Reboot sind alle bis auf admin.0 und backitup.0 deaktiviert. Das war der Ausgangszustand nach dem Restore aus dem minimal Backup. Fixer hab ich bereits laufen lassen.

Wo wird denn gespeichert welcher Adapter aktiv sein soll?

[darkiop]

@Stabilostick der Master ist ein Docker Container welcher mit

--network=mac0 \
--ip=192.168.1.82 \
--dns=192.168.1.43 \

mit einer fixen IPv4 versehen wurde. Auf diese IP habe ich hier im lokalen LAN auch einen DNS Namen vergeben.

IPv6 ist aktuell noch eine Blackbox für mich

[paul53]

@darkiop sagte:

Wo wird denn gespeichert welcher Adapter aktiv sein soll?

In der Eigenschaft common.enabled des Instanz-Objektes system.adapter.adaptername.N.

[Stabilostick]

@darkiop

Im Ernst:

Hast Du einen Pi 4? Da haben mehr Leute Probleme:

https://github.com/raspberrypi/linux/issues/3034

https://github.com/raspberrypi/linux/issues/3108

mii-tool -r eth0

ist da der Workaround.

[darkiop]

@Stabilostick Ja ist ein Pi4. Danke schaue ich gleich mal rein.

[darkiop]

@paul53 Hier? Da gibt es die nicht.

[paul53]

@darkiop sagte:

Hier?

Nein, das ist ein Datenpunkt, der den Zustand anzeigt.
Direkt darüber ist das Objekt "system.adapter.bring.0", dessen Eigenschaften man mit dem Bleistift-Symbol rechts sehen kann.

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