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

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

[Diginix]

@apollon77 3.2.7 hatte ich übersprungen.
Der Adapterinstanz (re)start funktioniert sowohl in der Kommandozeile, als auch mit dem exec im Skript, aber nicht immer sofort. Manchmal bleibt die Instanz einfach aus. Daher hatte ich das als Schleife. Wenn radar2.0.connected nicht nach 20 sec auf true ist, dann wird erneut ein "iobroker restart radar2.0" ausgeführt. Bis JS-C 3.1.x gab es da nicht ein einziges mal ein Problem. Eigentlich sollte ja ein zweiter restart maximal eine bereits laufende Instanz erst beenden und wieder starten. Aber selbst wenn die zu schnell hintereinander kämen, dann dürften keine Prozesse unbeendet liegen bleiben.
Wie ich an weitere Details dazu komme (CLI Ausgabe), habe ich keine Ahnung. Da bräuchte ich Zuarbeit.

Ich habe nun eben mal im Skript das Kommando von "restart" auf "iobroker start radar2.0" geändert, weil die Instanz ja vorher gestoppt wurde und somit eh nicht läuft.
Die Instanz wurde mit "start" auch gestartet, aber als Antwort kam dann

Cannot load "custom": Error: Connection is closed.

Und das aber 61660 mal. Das Log ist dadurch explodiert.

Aber auch bei "start" statt "restart" blieben eben wieder die Prozesse liegen:

iobroker   19476  0.0  0.0  10156  3692 ?        S    10:00   0:00 /bin/bash /usr/bin/iobroker start radar2.0
root       19477  0.0  0.1  12640  4960 ?        S    10:00   0:00 sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js start radar2.0
iobroker   19478 99.5  3.2 754936 128628 ?       Rl   10:00  19:21 node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js start radar2.0

Neben dem letsencrypt Problem gerade das für mich störendste an JS-C 3.2
Ich will noch nicht aufgeben, aber wenn ich es nicht stabil bekomme, muss vorerst leider ein rollback her.

[apollon77]

@diginix Hasz Du bitte mal mehr vom log ... am besten log BEVOR dieser Connection closed Fehler das erste mal kommt. Und wieterhin, wie oben gefragt, würde mich echt mal mehr log interessieren, auch was der Controller bei deinen manuellen restart dingen da ausgibt ... alsio quasi die Info wann hat edein skript was getan und das zeitlich zu dem log dann zuzuordnen.

Ohne da jetzt in dein spezielles Problem tiefer rein zu gehen wiss ich nicht wie der fix ist. bzw kannst Du das skript mal posten was Du nutzt?

EDIT: Ok ich habe einen Code-Fall gefunden wo es passieren kann das er in eine endlos Schleife läuft ... Wir verstehen nur nicht wie er da hin kommen kann ...

[crunchip]

@apollon77 hab ne Verständnisfrage, bzw ein Problem. Habe gerade

• Js-C upgrade von 3.2.7 auf 3.2.8
• danach iobroker fix durchlaufen lassen
  
  nun erhalte ich im Adapter linux-control folgendes

linux-control.0	2021-01-23 11:37:26.716	error	at LinuxControl.onReady (/opt/iobroker/node_modules/iobroker.linux-control/main.js:54:5)
linux-control.0	2021-01-23 11:37:26.716	error	at LinuxControl.refreshHost (/opt/iobroker/node_modules/iobroker.linux-control/main.js:87:5)
linux-control.0	2021-01-23 11:37:26.716	error	at LinuxControl.userCommand (/opt/iobroker/node_modules/iobroker.linux-control/main.js:196:9)
linux-control.0	2021-01-23 11:37:26.716	error	at LinuxControl.userCommandExecute (/opt/iobroker/node_modules/iobroker.linux-control/main.js:251:21)
linux-control.0	2021-01-23 11:37:26.716	error	at processTicksAndRejections (internal/process/task_queues.js:97:5)
linux-control.0	2021-01-23 11:37:26.716	error	at runMicrotasks (<anonymous>)
linux-control.0	2021-01-23 11:37:26.716	error	at LinuxControl.sendCommand (/opt/iobroker/node_modules/iobroker.linux-control/main.js:874:26)
linux-control.0	2021-01-23 11:37:26.716	error	(22907) [userCommandExecute] iobroker (10.1.1.10:22, id: root-verzeichnis, description: ): response error: /root/.bashrc: Zeile 24: /root/.iobroker/iobroker_completions: Datei oder Verzeichnis nicht
linux-control.0	2021-01-23 11:37:26.680	error	at LinuxControl.onReady (/opt/iobroker/node_modules/iobroker.linux-control/main.js:54:5)
linux-control.0	2021-01-23 11:37:26.680	error	at LinuxControl.refreshHost (/opt/iobroker/node_modules/iobroker.linux-control/main.js:82:5)
linux-control.0	2021-01-23 11:37:26.680	error	at LinuxControl.servicesInfo (/opt/iobroker/node_modules/iobroker.linux-control/main.js:485:21)
linux-control.0	2021-01-23 11:37:26.680	error	at processTicksAndRejections (internal/process/task_queues.js:97:5)
linux-control.0	2021-01-23 11:37:26.680	error	at runMicrotasks (<anonymous>)

[KHK]

@apollon77
Mit dem Update auf einem RPi4 habe ich schon beim Start folgende Fehler:

wenn ich iobroker fix mache kommt ähnliches :

Karl

[Diginix]

@apollon77 mein Host lief bisher mit loglevel warn. Ob es daran liegt, dass man nicht mehr sieht weiß ich nicht.
Hier mal von 11:00 Uhr und 11:30 wieder so ein Fall wo die Instanz nicht gestartet wurde und jeweils zweimal die 3 Prozesse zum Restart der Instanz nicht beendert wurden. 11:45 Uhr hat es dann funktioniert. Aber die Zombies von den 2 Läufen davor blieben. Die CPU Last steigt mit jedem mal wo die 3 Prozesse bleiben um ca. 1-2.

iobroker   28628  0.0  0.0  10156  2888 ?        S    11:00   0:00 /bin/bash /usr/bin/iobroker restart radar2.0
root       28629  0.0  0.1  12640  4944 ?        S    11:00   0:00 sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js restart radar2.0
iobroker   28630 98.2  3.4 743112 134900 ?       Rl   11:00  45:34 node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js restart radar2.0
iobroker   32996  0.0  0.0  10156  2900 ?        S    11:30   0:00 /bin/bash /usr/bin/iobroker restart radar2.0
root       32997  0.0  0.1  12636  4932 ?        S    11:30   0:00 sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js restart radar2.0
iobroker   32998 95.8  2.9 743352 118528 ?       Rl   11:30  15:42 node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js restart radar2.0
iobroker   35355 16.2  1.9 638660 77188 ?        Sl   11:46   0:03 io.radar2.0

Und hier das Log:

Spoiler

2021-01-23 11:00:06.485  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock radar2.0.alive: false / radar2.0.connected: false
2021-01-23 11:00:14.150  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: unlocked #1
2021-01-23 11:00:17.152  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: #1 Starting radar2
2021-01-23 11:00:27.096  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: #1 Unable to increase LUA script timeout: Error: Connection is closed.
 Cannot load "custom": Error: Connection is closed.
 Cannot load "custom": Error: Connection is closed.
 [...]
over 40000 mal die Zeile "Cannot load "custom": Error: Connection is closed."
 [...]
 Cannot load "custom": Error: Connection is closed.
 Cannot load "custom": Error: Connection is clos
2021-01-23 11:30:48.377  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: #1 radar2.0.connected: false
2021-01-23 11:30:48.378  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: #2 Starting radar2
2021-01-23 11:30:55.122  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: #2 The adapter "radar2.0" was started.
2021-01-23 11:31:15.124  - info: javascript.0 (1408) script.js.automatization.Door_Window.Smart_Lock: *** Smart Lock: #2 radar2.0.connected: true
2021-01-23 11:31:58.030  - error: daswetter.0 (33006) force terminate
2021-01-23 11:31:58.036  - warn: daswetter.0 (33006) Terminated (15): Without reason
2021-01-23 11:32:04.439  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.440  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.441  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.442  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.442  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.443  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.444  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.444  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.445  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.446  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.447  - warn: daswetter.0 (33006) get state Error: DB closed
2021-01-23 11:32:04.451  - error: daswetter.0 (33006) exception in await insertIntoList [Error: DB closed]
2021-01-23 11:32:05.765  - error: daswetter.0 (33006) 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-23 11:32:05.766  - error: daswetter.0 (33006) unhandled promise rejection: Cannot read property 'setState' of null
2021-01-23 11:32:05.812  - error: daswetter.0 (33006) TypeError: Cannot read property 'setState' of null
    at Adapter.setState (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:6065:35)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
2021-01-23 11:32:05.813  - error: daswetter.0 (33006) Cannot read property 'setState' of null
2021-01-23 11:32:06.187  - error: host.BT3-PRO instance system.adapter.daswetter.0 terminated with code 15 (15)
2021-01-23 11:40:23.212  - warn: ical.0 (34385) get state Error: Connection is closed.
2021-01-23 11:40:23.232  - warn: ical.0 (34385) get state Error: DB closed

Die Konsolenausgaben bei "iobroker restart radar2.0" sind entweder: "The adapter "radar2.0" was started." oder gar keine.
Im Fall von "...was started" läuft nicht zwingend die Instanz wieder. Deswegen prüfe ich den .connected state.
Wenn gar keine Ausgabe kommt, ist es der zur Zeit der Fall mit "Cannot load "custom": Error: Connection is closed."

Das Skript ist eigentlich ein Blockly, aber hier mal der Teil zum Stoppen und Starten der Instanz als Javascript:

Spoiler

var command, restart_count, run_count, result, timeout_keyble, check_radar_running, timeout_radar_restart;

// Smart Lock Control
async function control_smart_lock(command) {
  run_count = (typeof run_count == 'number' ? run_count : 0) + 1;
  exec('iobroker stop radar2.0', async function (error, result, stderr) {
      // 5000 ms bis 2020-05-25
    timeout_keyble = setTimeout(async function () {
      console.log((['*** Smart Lock radar2 alive: ',getState("system.adapter.radar2.0.alive").val,' / connected: ',getState("system.adapter.radar2.0.connected").val].join('')));
      exec('keyble-sendcommand --address 00:11:22:33:44:55 --user_id 2 --user_key *** --command status', async function (error, result, stderr) {
          console.log(('*** Smart Lock: ' + String(result)));
        // war 20s und nach exec keyble, nicht innerhalb
        // bis 2020-05-25
        //
        // seit 2020-06-25 7s statt 2s damit bei unlock/lock
        // retry radar2 nicht erst zwischen gestartet wird
        timeout_radar_restart = setTimeout(async function () {
          await start_radar2(1);
        }, 3000);
      });
    }, 2000);
  });
}

// Beschreibe diese Funktion …
async function start_radar2(restart_count) {
  console.log((['*** Smart Lock: #',restart_count,' Starting radar2'].join('')));
  exec('iobroker restart radar2.0', async function (error, result, stderr) {
      console.log((['*** Smart Lock: #',restart_count,' ',result].join('')));
    check_radar_running = setTimeout(async function () {
      console.log((['*** Smart Lock: #',restart_count,' radar2 connected: ',getState("system.adapter.radar2.0.connected").val].join('')));
      if (getState("system.adapter.radar2.0.connected").val != true && restart_count < 3) {
        restart_count = (typeof restart_count == 'number' ? restart_count : 0) + 1;
        await start_radar2(restart_count);
      } else if (getState("system.adapter.radar2.0.connected").val != true && restart_count >= 3) {
        console.log((['*** Smart Lock radar2 running: ',getState("system.adapter.radar2.0.connected").val,', kein ',restart_count + 1,'. Versuch'].join('')));
      }
    }, 20000);
  });
}


await control_smart_lock('status');