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

[smartboart]

@Homoran die kann ich nicht einsparen... Will ich auch nicht... Boot to desktop in kiosk mode fuer Anzeige Im Verteiler..

Hatte ich auch schon vor den Problemen...

[smartboart]

@Homoran said in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Bist du sicher dass das RAM wirklich belegt war und nicht nur zur schnelleren Abarbeitung reserviert?
Free ist der falsche Parameter. Available ist entscheidend

ja hatte vorher 500MB verfügbar und seit ein paar Tagen ist mir aufgefallen , dass ich nur noch 150MB verfügbar habe...Habe dazu ne Vis und hatte nach dem Display projekt ein Screenshot von der Auslatung gamacht..Hatte sich zu vorher nur minimal verändert...Irgendwann ich vermute mit umstellung auf redis hat sich die Auslastung geändert... Habe nur 5 Adapter auf dem Slave laufen...

so sieht es jetzt aus nachdem ich noch 2 Adapter rüber geschupst habe und auf file umgestellt habe.

[Homoran]

@smartboart sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

ja hatte vorher 500MB verfügbar und seit ein paar Tagen ist mir aufgefallen , dass ich nur noch 150MB verfügbar habe

Was soll der arme Raspi mit 1000mb denn machen, wenn du ihm noch ne grafische Oberfläche verpasst?

@smartboart sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Hatte ich auch schon vor den Problemen...

Klar.
Aber WENN schon 50% des sowieso knappen RAM durch das GUI draufgehen ist nicht viel Spielraum.

Dann anscheinend den Slave auch noch als Frontend für bis missbrauchen killt den letzten Speicher

[smartboart]

@Homoran ja das das alles knapp ist ist mir schon bewusst. Es lief ja alles stabil für ein halbes jahr... und aktuell habe ich ja auch wieder fast 500MB verfügbar...Auf dem Slave lese ich nur den modbus und die gpio ein. Habe noch nen zigbee stick laufen, welcher aber nur ein paar sensoren im Keller einliest..Sont hat der Raspi nix zu tun...

[smartboart]

und nach der Umstellung sieht auch top wieder vernünftig aus..

[Homoran]

@smartboart sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

.Sont hat der Raspi nix zu tun

Wenn ich es richtig verstehe wird dort aber auch ein visview dargestellt.

Das braucht viel Speicherplatz.
Die gesamte Grafik wird dort berechnet.
Auf dem vis Server werden nur die Rohdaten bereitgestellt

[smartboart]

@Homoran ja das stimmt...lasse mir mein vis projekt dort zusätztlich zu den wall tablets anzeigen...
der Raspi übernimmt auch die Spannungsüberwachung über gpio.. eine javascript instanz läuft auch mit drauf...um bei spannungseinbruch bzw. ausfall nach Autonomiezeit der USV die Systeme geordnet runter zu fahren.

[Homoran]

@smartboart
Netzteil wäre auch noch ein Thema.
2.x A bei am besten 5.1V.
Dazu noch ein gutes Kabel

[smartboart]

@Homoran die Teile werden ueber meine DC ups 12v gespeist.. Jeder Verbraucher hat sein eigenen 12v auf 5V converter welche jeweils 3A koennen... Natürlich extra abgesichert. Das ist leider nicht das Thema...

[Homoran]

@smartboart
Wenn es nicht die Stromversorgung (Kabel micro USB Stecker) oder die SOC Temperatur ist, tippe ich wirklich auf die Überlastung des RasPi mit Aufgaben.

Es ist, auch wenn es manchmal so dargestellt wird, eben kein vollwertiger PC.

[smartboart]

@Homoran ja ich befürchte es fast... Die soc temp pendelt sich auf 57 Grad ein... Ohne fremdbelüftung.. Vlt sollte ich das noch probieren beim tinker habe eine zusätzliche Belüftung. Welche temp ist denn vertretbar... Hab leider keinen Vergleich... Ausser snips aber der ist noch wärmer...

[Homoran]

@smartboart
60° ist schon eine Hausnummer.

Irgendwo ist Temperatur max im Betriebssystem hinterlegt.
Hast du wenigstens einen Kühlkörper drauf?

[AlCalzone]

@smartboart sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

2019-04-06 20:43:15.437 - error: TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
at Function.Buffer.from (buffer.js:183:11)
at Buffer (buffer.js:158:17)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1936:24)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1940:29)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1940:29)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1940:29)
at _getObjectList (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:2863:39)
at checkObjectRights (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:2912:28)
at checkObjectRights (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1869:20)
at ObjectsInMemServer.getObjectList (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:2908:13)

Auch wenn der Raspi am Limit läuft, das sieht mir schwer nach einem Bug aus. Lässt sich irgendwie eingrenzen, was der Auslöser ist?

[smartboart]

@Homoran ja habe wo es geht habe ich einen Kühlkörper sitzen, glaube 3 stück...Ist halt im geschlossenen Verteilerkasten mit Hutschienengehäuse auch geschlossen. Der Tinker war jenseits von gut und böse und hat deshalb habe ich dem nen Lüfter spendiert bekommen. Geht natürlich beim Raspi auch....

[smartboart]

@AlCalzone nicht wirklich habe schon mehrere Sachen probiert...Auf USB Betrieb umgestellt ohne SD, wo es ging Adapter auf den Master geschoben, und von redis auf file system umgestellt. Letzteres brachte eine Verbesserung, läuft bis jetzt stabil. Auch die Skripte reagieren bis jetzt noch wieder ohne aussetzer.

[RoE19xx]

Kurzes Zwischenfeedback:

Seit dem 03.04.2019 ist es zu keinem Absturz mehr gekommen.
Ich habe wie angekündigt den BackitUp Adapter (Verison 1.1.3) mal testweise deaktiviert.

Das beweißt zwar noch nicht das diese die Ursache ist/war aber es ist schon mal ein Fortschritt.
Ich werde das jetzt noch eine Zeit lang mit deaktiviertem Adapter beobachten.

Wenn es keine Probleme mehr gibt, werde ich für das Standardbackup eine andere, markante Zeit einstellen und den Adapter wieder aktivieren. Dann sollte sich zeigen ob der Adapter die Ursache bzw. ein Mitverursacher ist.

[Homoran]

@RoE19xx
Der Adapter wird sicher nicht der Verursacher sein.

Allerdings braucht er z.B. zum komprimieren der Daten wahrscheinlich etwas mehr RAM als du noch hast.

[RoE19xx]

@Homoran
"Gewagte Aussage" ;-)
Warum wird der Adapter "sicher" nicht der Verursacher sein?
Das war ja auch keine Kritik an dem Adapter oder ähnliches. Ich versuche ja nur das Problem einzugrenzen.
Wenn das gelingt, kann man ein Problem per Github melden. Der Entwickler ist für entsprechende Informationen sicher dankbar.

Das mit dem Ram würde ich nicht gleich in Betracht ziehen. Ich weiß zwar nicht wie es zum Zeitpunkt vom Absturz ausgeschaut hat. Aber die (betroffene) ioBroker Hauptinstanz läuft auf einer VM in einem NUC und hat 4 GB RAM zur Verfügung (davon aktuell laut ioBroker noch 1,3 GB frei).

Nach Deiner Theorie müßte der Adapter (beim komprimieren der Daten) die meistens ioBroker RPi's mit 1 GB Gesamtspeicher an ihre Grenzen bringen.

[Homoran]

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Warum wird der Adapter "sicher" nicht der Verursacher sein?

Weil der Adapter bei hunderten usern ohne Probleme läuft.
Lediglich bei usern, bei denen das RAM zu knapp ist, kommt es zu Speicherproblemen.

Also ist in fiesen Fällen nicht der Adapter, sondern das mangelnde RAM der Verursacher.

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Ich weiß zwar nicht wie es zum Zeitpunkt vom Absturz ausgeschaut hat.

Das wäre aber bei deiner Argumentationskette schon wichtig.

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

auf einer VM in einem NUC und hat 4 GB RAM zur Verfügung (davon aktuell laut ioBroker noch 1,3 GB frei).

Auch in solchen Fällen kam es kurzfristig zu Speicherproblemen.

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Nach Deiner Theorie müßte der Adapter (beim komprimieren der Daten) die meistens ioBroker RPi's mit 1 GB Gesamtspeicher an ihre Grenzen bringen.

Nur wenn das backup extrem umfangreich ist.
So war es bei einem user eindeutig immer ein total backup, während das minimal brav durchlief

[RoE19xx]

Es ging mir hier nie eine Schuldfrage, sondern immer nur um die Ursache meiner Systemabstürze.

Ich ziehe meinen Hut davor, wieviel von so vielen zu diesem Projekt beigetragen wird. Und es wird würde mir nicht in den Sinn kommen mit dem Finger auf irgendjemand oder irgendetwas zu zeigen nur weil es bei meiner Installation zu Problemen kommt.
Das war auch nie die Absicht, falls das irgendwie so rübergekommen ist.

Ich bin schwer begeistert vom ioBroker und das schon ziemlich lange. Mein System ist mittlerweile doch schon etwas gewachsen und lief bis zum ersten erwähnten Absturz absolut stabil.

Nachdem es dann einige Änderungen am System gab (die genannten Updates), aber auch von Zeit zu Zeit neue Adapter getestet dazugekommen sind, gibt es viele mögliche Ursachen.

Und mit „Ursache“ meine ich lediglich, „welche Änderung hat dazu geführt, das es nun zu Systemabstürzen kommt“.

Ob das nun ein neu verwendeter Adapter ist, oder Updates oder auch eine Kombination aus alledem ist im Grunde erst mal egal. Ich möchte nur herausfinden, so dass ich Maßnahmen setzen kann um mein System wieder in einen stabilen Zustand zu bringen.

Da ich bei der Analyse irgendwann angestanden bin, ging es eben mit Try & Error und dem Ausschließungsprinzip weiter. Nach dem Denkanstoß von @darkiop habe ich dann einfach mal auf gut Glück den BackitUp Adapter wieder deaktiviert.

Und wenn mein System nach dem deaktivieren von einem (in meiner Installation) neuen Adapter wieder stabil laufen sollte und nach erneutem Aktivieren wieder Abstürze auftreten, dann Freue ich mich im ersten Moment einfach nur die Ursache gefunden zu haben.

Wenn es mit dem Adapter am Ende gar nichts zu tun hat, dann geht die Suche eben weiter.

Da ich aber dazu beitragen möchte das Problem genauer zu analysieren, lasse ich nun im ersten Schritt vorerst den Adapter noch eine gewisse Zeit deaktiviert.
Wenn es dabei nicht zu Abstürzen kommt, werde ich eine andere (markante) Backup Zeit als 02:00 einstellen und schauen ob die Abstürze wieder auftreten.
Wenn ja dann finde ich hier ja ggf. Unterstützung wie ich mein System monitoren (Speicherauslastung aufzeichnen) kann um herauszufinden ob wirklich ein Speicherengpass den Absturz hervorruft.

Das würde den Entwickler vermutlich auch interessieren, da zwangsläuft mit wachsenden Installationen (wird bei den meisten begeisterten Anwendern der Fall sein) auch mit zunehmenden Ausfällen zu rechnen wäre. Und ein Backup Adapter findet sicher bei sehr vielen Anwendern Anklang.

Soweit erst mal mein Plan wie ich weiter vorgehen möchte.

Beim BackitUp Adapter hatte ich bisher nur das Standardbackup im Einsatz. Das Komplettbackup oder auch andere Möglichkeiten habe ich noch gar nicht genutzt bzw. aktiviert.