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

[apollon77]

@josh Wenn Du ein Redis/Redis System hast (also beide DBs States und Ibjects auf Redis) dann ist die Reihenfolge komplett schnuppe weil es keinen "iobroker Master" mehr gibt ... der Redis ist "der Master". Reihenfolge in dem Fall egal

[myssv]

@apollon77 Die Meldung kommt an der Konsole, die ich im Portainer sehe

Im ioBroker Log finde ich sie nicht

[Josh]

@apollon77
OK, verstanden. Dann ist es auch egal, wenn ich es so mache, wie es beschrieben ist.

Ich gucke nochmal nach, ob ich beides (States und Objects) verbunden habe. Die Redis-Einrichtung ist schon 'ne ganze Zeit her...

EDIT:
Der Befehl

iobroker multihost status

gibt beim Master folgendes zurück

Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 0.0.0.0
States:                     redis on 127.0.0.1

und beim Slave

Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 192.168.178.115
States:                     redis on 192.168.178.115

Ist das die von DIr beschriebene redis/redis config?

[Diginix]

@apollon77
Update von 3.1.6 auf 3.2.8 liefert folgende Logeinträge:

2021-01-22 09:59:39.552 - error: web.0 (593419) [LE] {"code":"E_FAIL_DRY_CHALLENGE","context":"cert_renewal","subject":"***.myfritz.net","altnames":["***.myfritz.net"]}
2021-01-22 10:04:06.915 - error: dwd.0 (593900) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2021-01-22 10:04:06.920 - error: dwd.0 (593900) unhandled promise rejection: DB closed
2021-01-22 10:04:06.957 - error: dwd.0 (593900) Error: DB closed
at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:179:25)
at Socket. (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:146:20)
at Object.onceWrapper (events.js:421:26)
at Socket.emit (events.js:314:20)
at Socket.EventEmitter.emit (domain.js:483:12)
at TCP. (net.js:675:12)
2021-01-22 10:04:06.958 - error: dwd.0 (593900) DB closed

Port 80 ist bei mir nur für iob auf wenn ich das letsencrypt cert verlängern muss. Sonst ist der anderweitig belegt.
Kommt die Meldung daher?

Die DWD Meldungen sind nur FYI oder relevant?

Und das MaterialUI Frontend kann mit lokaler IP gar nicht mehr aufgerufen werden.

nodejs: 12.20.1
JS-Controller: 3.2.8
dwd: 2.7.2
web: 3.2.3

[apollon77]

@myssv Dann denke ich wäre das eine Frage für buanet

[apollon77]

@josh neeee objects -> file ... also hast du den Objects Server weiterhin vom iobroker "master"

[apollon77]

@diginix Der Fehler von web sollte daher kommen das er certs updaten will aber nicht kann ... Wenn du "auto renewal" aktiviert hast dann solltest du auch "immer" den Port verfügbar haben ... sonst musst du das automatisch update deaktivieren.

dwd: haste mal ganzes log von dem "lauf"?`

[apollon77]

@diginix sagte in js-controller 3.2 jetzt im Latest!:

Und das MaterialUI Frontend kann mit lokaler IP gar nicht mehr aufgerufen werden.

das liegt leider daran das das neue letsencrypt ohne "einmal zertifikate" so reagiert und keine hat. Da ist schon ein Bug offen ... also: lass ihn einmal updaten, dann sollte das wieder gehen

[Diginix]

@apollon77
Nun verhält sich DWD unauffällig. Vllt war es nur der erste Start mit neuem JS-C.?

2021-01-22 11:14:27.226 - info: dwd.0 (614954) starting. Version 2.7.2 in /opt/iobroker/node_modules/iobroker.dwd, node: v12.20.1, js-controller: 3.2.8
2021-01-22 11:14:29.664 - info: dwd.0 (614954) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2021-01-22 11:15:03.610 - info: dwd.0 (615085) starting. Version 2.7.2 in /opt/iobroker/node_modules/iobroker.dwd, node: v12.20.1, js-controller: 3.2.8
2021-01-22 11:15:23.530 - info: dwd.0 (615085) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

Letsencypt ist in der web Instanz so konfiguriert. Kein auto renewal.

Wo trigger ich die Ernerung in iob?
Bisher habe ich es immer in der Kommandozeile nach 2,9 Monaten gemacht.

[apollon77]

@diginix Ich denke das pOrblem ist jetzt das folgende: Neue Lib, neue Speicherorte ... er hat also kein Zertifikat, damit nicht erreichbar. Musst es quasi einmal machen lassen damit er eins hat ... dann geht vllt wieder so? (Ja ich rate weilich LE nicht nutze)

[Diginix]

@apollon77 Per Domain und SSL komme ich aber mit validem Zertifikat auf MaterialUI.
Also gar kein Cert stimmt auch nicht. Das unter /opt/iobroker/iobroker-data/letsencrypt/ wird also weiterhin vom web Adapter korrekt ausgeliefert.

Wo ist denn der neue Speicherort?

In der Admin Instanz, wo auch die Domain und LE Konto festgelegt wird, hat sich der Pfad auch nicht geändert:

Der grün markierte Link hilft leider auch nicht wirklich.

Welcher Entwickler hat denn LE selbst in Verwendung und könnte sachdienliche Hinweise geben bzw. beim Abgleich meines Dateisystems helfen?

[apollon77]

@diginix Ich glaube das neue legt in node_modules/iobroker.js-controller ein .greenlockrc Verzeichnis an ... (Achtung absolutes Halbwissen)

[Diginix]

@apollon77
.greenlockrc ist eine Datei an der von dir genannten Stelle und enthält den alten von mir korrekt mit Cert bedienten Pfad:

{"configDir":"/opt/iobroker/iobroker-data/letsencrypt"}

Ich kann später gern mal den letsencrypt Ordner wegnehmen und versuchen ihn über iob Boardmittel neu erzeugen zu lassen.
Das Problem betrifft auch nicht nur MaterialUI sondern wahrs. alles was mit dem web Adapter ausgeliefert wird. Bei mir auch habpanel und jarvis. Alle Frontend URLs mit lokaler IP liefern:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Mit https://FQDN läuft es. Das ist schon mal gut und wichtig. Aber im Heimnetz natürlich langsamer als der direkte Zugriff. Welcher mit JS-C 3.1 funktionierte. Bei mir gab es auch bisher keine letsencrypt Probleme mit der alten Ver.

[apollon77]

@diginix Interessant ... im zweifel muss man da mal ein issue bei greenlock anlegen

[Josh]

Sehe ich das richtig, dass das Warning

... has no existing object, this might lead to an error in future versions

welches von mehreren Adapter (Proxmox, Tankerkönig, ...) ausgeworfen wird, nur durch den Entwickler zu beheben sind?

[Thomas Braun]

@josh
Ja. Issue beim entsprechenden Adapter eröffnen.

[Diginix]

@apollon77
Ich stoppe/starte Adapterinstanzen zyklisch per Skript um z.B. meine Bluetooth Hardware temporär frei zu haben um damit kurzzeitig andere Dinge machen zu können.

Seit JS-C 3.2.8 erhalte ich dadurch Zombie Prozesse. Vorhin hatte ich diese "3 restart radar2" Prozessen 4 mal, also 12 Prozesse. Habe es erst durch die eskalierende CPU Last bemerkt.
Mit JS-C 3.1.x gab es das nie.

iobroker  718539  0.0  0.0  10156  3764 ?        S    23:15   0:00 /bin/bash /usr/bin/iobroker restart radar2.0
root      718540  0.0  0.1  12644  4984 ?        S    23:15   0:00 sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js restart radar2.0
iobroker  718541 99.6  3.2 743904 126812 ?       Rl   23:15  27:21 node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js restart radar2.0
iobroker  721986  4.9  1.4 635896 58900 ?        Sl   23:41   0:04 io.radar2.0

Wie man sieht läuft die radar2 Instanz längst wieder mit höhere PID, die restart Prozesse werden aber nie mehr beendet.
Im Skript rufe ich auch nur "exec iobroker restart radar2.0" auf. Die "js-controller/iobroker.js restart radar2.0" Prozesse scheinen daraufhin vom System erzeugt zu werden.

[apollon77]

@diginix wenn du die restarts per Hand an der konsole machst bleiben auch welche hängen?

[apollon77]

@diginix Und 3.2.7 hatte das nicht?

[apollon77]

@diginix pps: kommst du irgendwie an die Ausgaben des cli Kommandos ran? Bzw steht was im logfile? Und ich verstehe korrekt das das Kommando seine Arbeit macht und adapter restarted aber das cli command selbst hängen bleibt. Korrekt?