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

[Diginix]

@AlCalzone HA!

Ändert man die Diagrammdarstellung und zoomt rein, sieht man doch etwas:

Immer wenn der RAM hochschnellt bekommt der js-controller ein Vielfaches an in states (>200 bei sonst <50).

[apollon77]

@diginix Interessant. Sind das controller eingehend oder ausgehend changes? Ansonsten: War das während dem Update auch so so?

Könntest DU während wir das versuchen zu analysieren den controler bitte auf info loglevel stellen ?

[Diginix]

@apollon77 Nur die eingehenden Events schnellen hoch. Das obere Diagramm mit >200 in Events war bei dem Update
Das untere Diagramm ist von heute morgen wo eigentlich keine Aktivitäten waren.
Loglevel ist auf info umgestellt.

[apollon77]

@diginix Wirklich "inputCount"?

[Diginix]

@apollon77 Ja, system.host.iobroker.inputCount geht von normal ca 40 auf >200

Die Entprellzeit für die Erfassung war sogar 5000 ms. Habe nun mal 1000 eingestellt, falls es mal in unter 5 Sek hochschnellt, bekäme man es sonst gar nicht mit.

Nun würde mich ja mal brennend interessieren woher die inEvents kommen (können)?

[AlCalzone]

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

Nun würde mich ja mal brennend interessieren woher die inEvents kommen (können)?

Magst du vielleicht noch die inputs/outputs für die bekannterweise etwas gesprächigeren Adapter aktivieren?
d.h. Javascript, Shelly (?), Influxdb, mihome-vacuum?

mihome-vacuum hab ich zur Sicherheit mit drin, weil der es bei mir auch mal geschafft hat mit tausenden Logs meinen Pi zum Absturz zu bringen.

[apollon77]

@diginix Ja ich denke es ist nicht direkt"diese Events" weil das sind viel zu wenige. Und die Zahl sagt auch nur das bei den (recht wenigen) States die der Controller selbst als Updates bekommt es mehr wurde ... Was nebenher ggf noch in der DB pot los ist ist damit nicht sichtbar.

Aber generell ists komisch, prüfe nochmal deine skripte ob davon ggf welche "spammen" könnten ... und ja die Idee mehr Adapterprozesse (alle?) mitzuloggen ist auch gut.

Setz nur das Reporting Interval nicht zu weit runter ...

[Diginix]

@apollon77 Allein der iobroker Neustart wegen Loglevel Umstellung hat 10 Uhr auch wieder diese Anomalie:

Somit müsste es sich doch eigentlich auch bei euch mit meinen Dateien nachstellen lassen? Hat es ja aber anscheinend nicht.

[apollon77]

@diginix Naja dann müsste man es mal schaffen es komplett nachzustellen - aber auch das tat ja bei dir letztens nicht ... Weil wenn du es nachstellen könntest dann wäre ne Idee mal unterschiedliche Adapter zu deaktivieren um zu schauen ob es passiert wenn mit denen was ist und und und

[Diginix]

@apollon77 Für den Javascript Adapter hatte ich in/out Events schon mit in der history habe nun noch influx, shelly, mihome-vacuum dazu genommen.

Zumindest gibt es bei in/out beim javascript Adapter zeitliche Zusammenhänge:

Die Spitzen alle 15min muss ich noch prüfen. Da läuft mind. 1 Cron in einem Skript, aber warum da dann >3000 Events fliegen, verstehe ich gerade noch nicht. Habe den einzigen 15min Cron den ich finden konnte mal auskommentiert. Bin gespannt ob die Spitzen dann weg sind.

Ganz rechts sieht man auch noch eine "out" Spitze vom Skript Adapter mit >260 kurz nachdem alle Skripte wieder liefen nach iobroker restart.

[Moko]

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

@moko Also nein kann damit nichts zu tun haben ... und ja Backitup 2.3.3 ist noch im Latest ... wie auch der controller 4

https://repo.iobroker.live/sources-dist.json (ist in iobroker als stable hinterlegt) zeigt mir auch die 2.3.3 an, iobroker selbst meint
"Installierte Instanzen: 1
Verfügbare Version: 2.2.3
Installierte Version: 2.2.3"
:(

[Diginix]

@moko Wo steht da 2.3.3?

[Moko]

@diginix latestVersion "2.3.3"

P.S. ich habe nicht behauptet dass die 2.3.3 als stable angezeigt wird.
Bei mir ist die letzte 2.2.3

P.S. mein Fehler: habe latest mit stable verwechselt.

[Diginix]

@moko Wenn du auf stable bist, wird dir keine latest Ver. angeboten.

[Diginix]

@AlCalzone Ich bin nun schon die ganze Zeit auf der Suche nach der Ursache für die Eventspitzen beim Javascript Adapter.
Alle Skripte zusammen haben laut Logausgabe <80 subscriptions. Wenn ich die javascript Instanz starte und somit auch alle Skripte, gibt es schon mal eine Spitze von 263 Event ausgehend. Wie wird dieser Wert ermittelt bzw. was zählt da mit rein?

Die Spitzen bei den eingehenden Events alle 15 min kann ich mir auch noch nicht erklären. Bin aber noch am Testen durch Deaktivieren von einzelnen Skripten die States von Adapter nutzen, die nur alle 15 min laufen (dwd, daswetter).

[AlCalzone]

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

Alle Skripte zusammen haben laut Logausgabe <80 subscriptions. Wenn ich die javascript Instanz starte und somit auch alle Skripte, gibt es schon mal eine Spitze von 263 Event ausgehend. Wie wird dieser Wert ermittelt bzw. was zählt da mit rein?

Jede State-Änderung jedes Wertes auf den du subscribest zählt da mit rein. By default subscribed der JS-Adapter aber alle States, selbst die die du nicht nutzt. So ermöglicht er, dass getState und setState trotz asynchroner DB synchron sind.

---

Ich hab grade nochmal versucht das nachzustellen. Testinstanz mit latest controller, die Adapter Web/WS/VIS, ein Skript welches 1000 changes/s generiert (also 15000 in- und out-events), und dabei fleißig Adapter aktualisiert. Nix... Der Controller dümpelt auf 180 MB RAM herum.

[Diginix]

@alcalzone Hm, ich werde mit meiner Analyse auch nicht schlauer.
Ich habe alle javascripte angehalten die ein "schedule" enthalten. Trotzdem habe ich weiterhin alle 15 min diese Spitzen.

Die gibt es wahrs. schon immer und machen auch keine direkten Probleme, aber nun habe ich mich durch das Erfassen der in/out Events bis dahin vorgearbeitet und wüsste gern den Ursprung.
Wenn ich den javascript Adapter anhalte kommt die ausgehende Spitze im Bild markiert. Sind aber nur 230, also ganz andere Skalierung. Meine Skripte schreiben beim Beenden keine states. Jedenfalls nicht wissentlich.

[e-i-k-e]

@apollon77

So siehts aus.

pi@raspberrypi-display2:~ $ iobroker upgrade self
internal/modules/cjs/loader.js:905
  throw err;
  ^

Error: Cannot find module '/opt/iobroker/node_modules/iobroker.js-controller/iobroker.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
    at Function.Module._load (internal/modules/cjs/loader.js:746:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:75:12)
    at internal/main/run_main_module.js:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

[apollon77]

@e-i-k-e also jetzt ist dein Controller ganz weg. Dann Versuch den mal mit nem npm install zu installieren am besten fang bei der 3.3.22 an

[gelberlemmy]

Hallo,

ich habe ein Update von 3.3.22 auf 4.0.15 getätigt. Das mit den "unsupportet Meldungen" habe ich gelesen. Habe da noch ein paar andere Meldung während des Updates bekommen.
Beim Hochfahren der Adapter auch einige Meldungen von ideversen Adaptern "Error DB closed" bekommen.
Nach dem Anschein sind jetzt aber alle Adapter wieder hochgefahren. Habt Ihr das auch schon einmal gehabt ? Oder soll ich erst einmal zurück auf 3.3.22 ? Ist auf einem Proxmox LXC Conatiner

Update js-controller from @3.3.22 to @4.0.15
NPM version: 6.14.16
npm install iobroker.js-controller@4.0.15 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call)
Server Objects 127.0.0.1:38870 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets"]
Server States 127.0.0.1:36652 Error from InMemDB: Error: GET-UNSUPPORTED for namespace meta.: Data=["meta.states.protocolVersion"]
Server Objects 127.0.0.1:38870 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.protocolVersion"]
Server States 127.0.0.1:36654 Error from InMemDB: Error: PSUBSCRIBE-UNSUPPORTED for namespace meta.: Data=["meta.*"]
Server Objects 127.0.0.1:38870 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:38870 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:38870 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:38870 Error from InMemDB: Error: SET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49]}]
Could not migrate objects to corresponding sets: Error SET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49]}]