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

[apollon77]

@diginix mach doch parallel ... also schick Ihm die files und mach mal stop und start und schau ob es wieder passiert ... Wäre denke auch für @AlCalzone ne interessante info

[homecineplexx]

@apollon77 said in js-controller 4.0 jetzt im BETA/LATEST!:

Ausser es auf echte Aliases umzubauen, dann brauchst Du solche Skripte nicht

geb ich dir absolut recht, allerdings lass ich dort auch zusätzlich gleich gewisse Datenpunkte in die Influxdb schreiben und zusätzlich überwachen. ich weiß nicht ob ich das mit Alias kann?

[apollon77]

@homecineplexx Auch wenn ziemlich Off-Topic hier: Für Aliase kannst du auch Influxdb logging aktivieren und für "überwachen" wirst Du ggf eigene Skripte brauchen. Lange Rede ... Wenn die Skripte das tun was Du sagst und da "so viel Changes" zusammenkommen wie Du oben geschrieben hast ist doch erstmal alles ok ... Wichtig ist zu unterscheiden ob so soll oder da ein Skript Amok läuft

[Diginix]

@apollon77 Hm, ein iob stop mit anschließendem Reboot des Servers, also komplette Proxmox Host (gab Kernel Updates) und somit ja dann im Anschluss auch wieder ein iob start hat keinerlei Peak erzeugt. Nun wird nat. der RAM vom js-c über history erfasst und der Adapter muss natürlich erstmal laufen. Was ja aber gestern auch funktionierte.

Daher habe ich direkt noch mal ein iob stop, ps auxww | grep "io.", iob status, iob start gemacht.
"Leider" auch ohne Auffälligkeiten.

Aber ich vermute, dass genau der Controller Peak von gestern auch in der Vergangenheit seit 4.x für die OOM Kills bei mir ursächlich war. Was den Peak selbst auslöst, ist leider weiterhin unbekannt.
Wird nach einem js-controller Update noch etwas gemacht was bei einem Neustart der selben Controller Version dann nicht mehr geschieht?

[AlCalzone]

@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Wird nach einem js-controller Update noch etwas gemacht was bei einem Neustart der selben Controller Version dann nicht mehr geschieht?

iobroker setup first vielleicht @apollon77 ?

[foxriver76]

@alcalzone Ja, wird ausgeführt und darin werden paar Objekte aufgeräumt, sichergestellt, dass systemSecret, certs da sind + Sets Migration.

Habe jetzt nicht viel gelesen, aber Sets Migration sind approx. n calls gegen die DB, wobei n die Anzahl an Objekten ist.

[AlCalzone]

Hmm also mit den Dateien, die ich von @Diginix bekommen hab, startet der Controller-Prozess problemlos und dümpelt dann bei so 300 MB RAM. Ich probier jetzt mal nur setup first zu debuggen.

[apollon77]

@alcalzone hab ich auch schon überlegt aber am Ende werden von CLI Kommandos keine Reporting Werte geliefert! Also wenn die daten so in den system-host.NAME.x States stehen können SIe nur von einem "normal laufenden controller" kommen.

Auch ein "erster Start nach Update" ist an sich nicht unterschiedlich zu jedem anderen Start

[AlCalzone]

Ich bin neugierig und wollte es doch nochmal bestätigt haben. setup first mit den Datenbanken ging bei mir auch max. auf 350 MB RAM.

[Diginix]

@alcalzone Tja, dann muss es vorerst als mehrmals vorkommender Einzelfall abgehakt werden.
Ich lasse das RAM Logging mal für den js-controller weiterlaufen mit Vorhaltezeit von 3 Tagen.
Aber das wird zur Ursachenforschung wahrs. nicht viel beitragen.

[Johannes Bauerstatter]

Hallo mit Typ: js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr. Kann ich den js-controller auch auf eine bestimmte Version downgraden? Mit Version 4.0.9 hat noch alles funktioniert.

[JohGre]

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr

Kann ich so nicht bestätigen: Shelly-Adapter 5.2.0 läuft bei mir

[amg_666]

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr

bei mir läuft der shelly 5.2.0 ohne Probleme mit js 4.0.12

[Johannes Bauerstatter]

@amg_666 welche Firmware habt ihr in den Shellies? Letzte Frage weil falscher Threads.

[da_Woody]

@johannes-bauerstatter bin zwar erst auf 4.0.10, aber keine probleme mit shelly.
ich hab 1.11.8, bis auf die H&T, die haben wieder 1.11.7...

[Diginix]

@johgre sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr

Kann ich so nicht bestätigen: Shelly-Adapter 5.2.0 läuft bei mir

Bei mir auch alles ok mit Shelly 5.2 und js-c 4.0.12
Firmware sollte keine Rolle spielen zumindest bei Gen.1 Shellys.

[amg_666]

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

welche Firmware habt ihr in den Shellies?

1.11.8 auf allen Shellys

[Johannes Bauerstatter]

Vielen Dank. Nach mehrmaliger Neuinstallation funktioniert der Adapter wieder. Da hat's irgendwo anscheinend gehakelt.

[da_Woody]

@amg_666 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

1.11.8 auf allen Shellys

bei den H&T dürfte das wieder zurückgezogen worden sein. mir wurde wieder die 1.11.7 angeboten. hatte auch bei 2 von 10 WLAN aussetzer. nach ca 10min keine verbindung mehr...
zurück auf 1.11.7 keine aussetzer mehr.

[wendy2702]

So,

gerade problemlos upgrade meiner drei Produktiv iob installeátionen von 4.0.8 --> 4.0.12 gemacht.

Master läuft auf Proxmox, CPU nur kurz beim starten etwas erhöht, RAM nahezu unverändert:

rote linie zeigt den neustart.

Lediglich bei einem Slave bin ich etwas verwundert über das verhalten. Hier gab es zwar den BackitUp Adapter allerdings ohne Instanz. Die wurde mir 4.0.12 von alleine wieder angelegt.... ist das so gewollt?

pi@pi-iobroker:~ $ iob update
Used repository: Beta (latest)
Adapter    "admin"        : 5.3.0    , installed 5.3.0
Adapter    "backitup"     : 2.3.3    , installed 2.3.0  [Updatable]
Adapter    "discovery"    : 2.7.5    , installed 2.7.5
Controller "js-controller": 4.0.12   , installed 4.0.8  [Updatable]
Adapter    "modbus"       : 3.4.17   , installed 3.4.17
Adapter    "net-tools"    : 0.1.7    , installed 0.1.7
Adapter    "rpi2"         : 1.3.2    , installed 1.3.1  [Updatable]
Adapter    "smartmeter"   : 3.2.1    , installed 3.2.1
Adapter    "tr-064"       : 4.2.15   , installed 4.2.15
pi@pi-iobroker:~ $ iob upgrade self
Update js-controller from @4.0.8 to @4.0.12
Stopped Objects DB
Stopped States DB
NPM version: 6.14.16
Installing iobroker.js-controller@4.0.12... (System call)

> iobroker.js-controller@4.0.12 preinstall /opt/iobroker/node_modules/iobroker.js-controller
> node lib/preinstallCheck.js

NPM version: 6.14.16

> iobroker.js-controller@4.0.12 install /opt/iobroker/node_modules/iobroker.js-controller
> node iobroker.js setup first

object _design/system updated
host.pi-iobroker create instance backitup
host.pi-iobroker object system.adapter.backitup.0.alive created
host.pi-iobroker object system.adapter.backitup.0.connected created
host.pi-iobroker object system.adapter.backitup.0.compactMode created
host.pi-iobroker object system.adapter.backitup.0.cpu created
host.pi-iobroker object system.adapter.backitup.0.cputime created
host.pi-iobroker object system.adapter.backitup.0.memHeapUsed created
host.pi-iobroker object system.adapter.backitup.0.memHeapTotal created
host.pi-iobroker object system.adapter.backitup.0.memRss created
host.pi-iobroker object system.adapter.backitup.0.uptime created
host.pi-iobroker object system.adapter.backitup.0.inputCount created
host.pi-iobroker object system.adapter.backitup.0.outputCount created
host.pi-iobroker object system.adapter.backitup.0.eventLoopLag created
host.pi-iobroker object system.adapter.backitup.0.sigKill created
host.pi-iobroker object system.adapter.backitup.0.logLevel created
host.pi-iobroker object backitup.0.info created
host.pi-iobroker object backitup.0.info.latestBackup created
host.pi-iobroker object backitup.0.info.ccuNextTime created
host.pi-iobroker object backitup.0.info.iobrokerNextTime created
host.pi-iobroker object backitup.0.history created
host.pi-iobroker object backitup.0.history.html created
host.pi-iobroker object backitup.0.history.json created
host.pi-iobroker object backitup.0.history.ccuLastTime created
host.pi-iobroker object backitup.0.history.iobrokerLastTime created
host.pi-iobroker object backitup.0.history.ccuSuccess created
host.pi-iobroker object backitup.0.history.iobrokerSuccess created
host.pi-iobroker object backitup.0.oneClick created
host.pi-iobroker object backitup.0.oneClick.ccu created
host.pi-iobroker object backitup.0.oneClick.iobroker created
host.pi-iobroker object backitup.0.output created
host.pi-iobroker object backitup.0.output.line created
host.pi-iobroker Set default value of backitup.0.info.ccuNextTime: none
host.pi-iobroker Set default value of backitup.0.info.iobrokerNextTime: none
host.pi-iobroker Set default value of backitup.0.history.html: No backups yet
host.pi-iobroker Set default value of backitup.0.history.json: []
host.pi-iobroker Set default value of backitup.0.history.ccuLastTime: No backups yet
host.pi-iobroker Set default value of backitup.0.history.iobrokerLastTime: No backups yet
host.pi-iobroker Set default value of backitup.0.history.ccuSuccess: false
host.pi-iobroker Set default value of backitup.0.history.iobrokerSuccess: false
host.pi-iobroker Set default value of backitup.0.oneClick.ccu: false
host.pi-iobroker Set default value of backitup.0.oneClick.iobroker: false
host.pi-iobroker Set default value of backitup.0.output.line:
host.pi-iobroker object system.adapter.backitup.0 created
{