Raspberry "friert ein" nach Aufruf von ioBroker
-
@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. -
@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. -
@greenhorn NAS geht, ob du dir als "Greenhorn" damit aber einen gefallen tust weiss ich ehrlich gesagt nicht.
-
@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
-
@codierknecht
Synology 216dj oder so… -
@greenhorn
Vergiss es.
-
@codierknecht
OK, ich bleib beim Raspi
Der Raspi hat immerhin 4GB.
-
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? -
@greenhorn Per Konsole stoppen wäre der erste Versuch.
iob stop <instanz.X>
-
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… -
@greenhorn soweit mir bekannt geht immer nur eine Instanz.
aber hinter dem Shelly noch die ID der Instanz angeben.
-
@wendy2702 Oh, dann wirds tricky: Die IDs der Instanzen weiß ich nicht auswendig. Kann ich die auf der Konsole auslesen?
-
-
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?
-
@greenhorn Zu Jarvis kann ich nichts sagen aber besorg dir einfach ne zweite SD Karte, dann hast du die alte als Backup.
-
@wendy2702
Neue SD-Karte ist bestellt. Dann werde ich eine Neuinstallation mit Einspielung des Backups versuchen und hoffen, dass nicht irgendwelche Fehler übernommen werden. Frage zur Formatierung der SD-Karte: Bisher habe ich immer in FAT32 formatiert, wäre aber ext4 nicht besser da eh Linux ? -
Wenn da per Raspberry Imager das richtige Image geflasht würd ist es ohnehin ext4.
-
@thomas-braun Ich will es mit dem Befehl
curl -sLf https://iobroker.net/install.sh | bash -
aufsetzen. Die SD-Karte muss aber doch vor dem Einsetzen formatiert werden, oder bin ich da falsch? -
@greenhorn sagte in Raspberry "friert ein" nach Aufruf von ioBroker:
Die SD-Karte muss aber doch vor dem Einsetzen formatiert werden
Da muss zunächst mal ein Betriebssystem drauf.
Da Formatieren sollte m.W.n. der Raspberry Imager übernehmen. -
Nein, ist nicht erforderlich. Macht der Raspberry Pi Imager wenn das Betriebssytem aufgespielt wird.
