Raspberry "friert ein" nach Aufruf von ioBroker

[Greenhorn]

Gleich ab morgen werde ich mich mit dem Thema Backup beschäftigen...
Mann oh Mann, was ein Schock Ich bin soo froh dass das wieder geht.
Nochmal allerherzlichsten Dank an euch

[wendy2702]

@greenhorn sagte in Raspberry "friert ein" nach Aufruf von ioBroker:

Gleich ab morgen werde ich mich mit dem Thema Backup beschäftigen...
Mann oh Mann, was ein Schock Ich bin soo froh dass das wieder geht.
Nochmal allerherzlichsten Dank an euch

Tippe schnell in die Konsole

iob backup 

Dann hast du wenigsten schonmal eins

[Greenhorn]

@wendy2702
Das habe ich gestern leider nicht mehr gemacht, hatte es nicht mehr gesehen.
Heute morgen habe ich festgestellt, dass einige Instanzen nicht aktiv waren. Habe sie dann nacheinander aktiviert, mit dem Ergebnis, dass der Raspi so rödelt, dass er keinen Befehl mehr annimmt. Diesmal lasse ich ihn aber laufen bis ich heute nachmittag nachhause komme. Vielleicht hat er sich bis dahin beruhigt…

[Codierknecht]

@greenhorn

dass einige Instanzen nicht aktiv waren

Weiß Du noch welche?

Mir scheint auch die objects.json etwas groß.
Ich habe z.B. fast doppelt so viele Objekte, die Datei ist aber nur 1/4 so groß.

@Thomas-Braun
Kann man im diag-Script an die Liste der aktiven Instanzen auch deren Speicherverbrauch prömpeln?
Mir fällt immer wieder auf, dass die Anwender häufig Probleme mit dem RAM haben.
Wäre doch praktisch, wenn man in der Ausgabe auch gleich sehen könnte, wo die "dicken Hunde" stecken.
Zumindest was die ioBroker-Instanzen betrifft.

[Thomas Braun]

@codierknecht sagte in Raspberry "friert ein" nach Aufruf von ioBroker:

Kann man im diag-Script an die Liste der aktiven Instanzen auch deren Speicherverbrauch prömpeln?

In einer Beta-Version ist ein Snapshot von 'top' drin.
Das ganze ist aber halt nur ein Snapshot und damit nur bedingt Aussage kräftig.

[Greenhorn]

@codierknecht
Nicht genau, aber ca. die Hälfte war nicht aktiv. U.a. die Influx, die habe ich aber vorsichtshalber gar nicht aktiviert, weil ich die am meisten in Verdacht hatte, alles zu blockieren…

[Codierknecht]

@greenhorn sagte in Raspberry "friert ein" nach Aufruf von ioBroker:

weil ich die am meisten in Verdacht hatte, alles zu blockieren

Hätte ich auch.

Ich befürchte, der kleine Pi hat ein Speicherproblem.
Mit 4 GB RAM darf man von dem halt keine Wunderdinge erwarten.

Ich habe keine Ahnung, wie Speicherhungrig Influx so ist.
Könnte mir aber gut vorstellen, dass der arme kleine Pi damit überfordert ist.

[Greenhorn]

@codierknecht
Wenn ich es richtig verstanden habe, könnte ich den iobroker auch auf der NAS laufen lassen? Das wäre dann eine Alternative, einen richtigen Rechner will ich nicht auch noch extra laufen laufen lassen.

[wendy2702]

@greenhorn NAS geht, ob du dir als "Greenhorn" damit aber einen gefallen tust weiss ich ehrlich gesagt nicht.

[Codierknecht]

@wendy2702
Und potent genug sollte die Kiste dann auch sein.
Also ordentliche CPU und genügend RAM.

Ist das gegeben, hätte das den Vorteil dass man ioBroker und Influx in getrennten Containern laufen lassen könnte (so man denn Docker verwendet).

Aber Du hast natürlich Recht: Einfacher wird das nicht wirklich.
Und @Thomas-Braun würde sich dann ausklinken

[Greenhorn]

@codierknecht
Synology 216dj oder so…

[Codierknecht]

@greenhorn
Vergiss es.

[Greenhorn]

@codierknecht
OK, ich bleib beim Raspi

Der Raspi hat immerhin 4GB.

[Greenhorn]

Der Raspi bzw. iobroker ist über VPN immer noch nicht verreichbar, also rödelt er immer noch vor sich hin.
Kann ich die Instanzen über die Konsole zwecks Fehlereingrenzung alle zusammen killen und dann einzeln starten?

[wendy2702]

@greenhorn Per Konsole stoppen wäre der erste Versuch.

iob stop <instanz.X>

[Greenhorn]

@wendy2702

Also z.B.: iob stop <shelly> ?
Kann ich die Instanzen auch alle auf einmal nennen, da ich befürchte, dass ich wieder nur kurze Zeit draufkomme…

[wendy2702]

@greenhorn soweit mir bekannt geht immer nur eine Instanz.

aber hinter dem Shelly noch die ID der Instanz angeben.

[Greenhorn]

@wendy2702 Oh, dann wirds tricky: Die IDs der Instanzen weiß ich nicht auswendig. Kann ich die auf der Konsole auslesen?

[Thomas Braun]

@greenhorn

Per

iobroker list instances

[Greenhorn]

So, nachdem ich alle Instanzen gestoppt hatte und nach und nach wieder welche gestartet hatte, kristallisierte sich ein Problem mit der Zigbee-Instanz heraus, die vorher einwandfrei lief. Besonders wenn ich die Javascript-Instanz gestartet habe, die ein paar Scripts mit Zigbee-Geräten enthält war wieder Feierabend. Auch Jarvis machte Probleme, zeigte die Werte vieler Shelly-Geräte gar nicht an. Da ich ja jetzt ein Backup gemacht habe, frage ich mich jetzt, ob nicht eine Neuinstallation mit dem Backup sinnvoller wäre als ewig Fehler zu suchen.
So sah die Meldung zum Backup aus:

simon@iobroker:~ $ iob backup
host.iobroker 3267 states saved
host.iobroker 4002 objects saved
Backup created: /opt/iobroker/backups/2024_02_26-19_22_25_backupiobroker.tar.gz
This backup can only be restored with js-controller version up from 4.1
simon@iobroker:~ $

Habe ich nach Einspielen des Backups alle Objekte, Scripts, Jarvis- und IQontrol-Oberflächen wieder oder sind die dann futsch?