ich will heute noch ein Paar Arbeiten am Unterverteiler vornehmen und muss ihn hierzu stromlos machen. Der Cerbo GX hängt momentan an einem 12V Netzteil was ebenfalls am Unterverteiler hängt.
Früher habe ich mir nie eine Platte gemacht und alles ausgeschaltet.
Aber irgendwie ist das nicht gut und eine Linux Kiste fahre ich ja immer mit shutdown runter.
Kommt der Cerbo GX (ssh ist frei für root) dann wieder hoch (restart), wenn er wieder mit Power versorgt wurde nach einem Shutdown?
Der Cerbo hat ein RAM Filesystem und somit geht da nichts kaputt. Nur als Tip: Wenn Du den Cerbo per Netzteil am AC-OUT betreibst, ist das keine richtig gute Idee … wenn der MP2 bei einem Update kurz neu startet, hast Du ein Problem. Der Cerbo gehört immer auf die DC Schiene.
nun ja, wenn ich sowas lese: RAM Filesystem, da kann nichs schief gehen,
muss ich immer etwas schmunzeln. RAM ist nicht gleich RAM. Wenn man SRAM mit Stützbatterie (Lithiumknopfzelle) verbaut hat, dann geht nichts verloren bei Stromausfall. Bei DRAM ist alles Futsch, wenn nicht entsprechende Akkublöcke und eine spezielle Elektronik verbaut ist, die alles bei Stromausfall auf ein entsprechendes Storage Device schreibt.
Laut TAM 3517 Manual gibt es zumindest eine externe SRAM Anbindung, aber ich habe keinen blassen, was auf dem Baseboard verbaut ist.
In meinem Eingangspost schrieb ich übrigens das Wort “momentan”.
“Der Cerbo GX hängt momentan an einem 12V Netzteil”
Der Cerbo GX kommt bei mir an eine ohnehin vorhandene USV, denn wenn sie am AC Out oder DC hinge, würde ich bei einem möglichen Akkuausfall oder anderen Problemen die Diagnoseverbindung zum Cerbo GX verlieren.
Das RAM Filesystem ist in diesem Fall sogar read only. Da kann nichts am eigentlichen System kaputt gehen. Die Config Daten liegen auf einem anderen Device. Der Grund ist, den Storage Chip nicht mit ständigen Schreiboperationen zu stressen , damit er länger hält. Nicht mehr, nicht weniger.
Diagnosedaten sollte normalerweise das BMS liefern … wenn da nichts mehr geloggt wird, kommt auch nichts mehr beim Cerbo an.
Also, gesagt getan, zuerst die Multis per virtuellem Schalter auf AUS und dann den Unterverteiler abgeschaltet. Die Akkus habe ich auf Ein gelassen, weil die bei Stromausfall auch nicht abgeschaltet werden. Die Multiplus Hardwareschalter habe ich auch nicht angefasst. Mag sein, dass dies nicht die richtige Vorgehensweise ist, aber bei einem Netzausfall läuft das ja auch alles, wenn auch ungeordnet so ab.
Nach den Klemmarbeiten am Unterverteiler:
UV wieder eingeschaltet und die Multis blieben aus, was ja schon mal dafür spricht, dass diese Einstellung nicht verloren gegangen ist. Also alles wie erwartet.
Kommunikation mit dem Cerbo GX war dann wieder da und in der GUI habe ich dann den virtuellen Schalter für die Multis von AUS auf AN geschaltet, aber dann kam die Meldung Multiplus II Batteriespannung niedrig. In der GUI wurde 49,9V angezeigt. SoC war 65%.
Es erfolgte dann aber 0 Akku “Entladung”, obwohl gerade vom Netz 4kW gezogen wurden. Uhrzeit 18:30. Keine Sonne, keine PV.
Habe dann noch 5 Minuten gewartet und dann den virtuellen Switch vom Multiplus in der GUI wieder auf AUS und anschließend wieder auf EIN gesetzt und erst dann haben die Pylonen angefangen sich zu entladen. Allerdings hat es ca. weitere 3 Minuten gedauert, dass die Pylonen auf 4kW gegangen sind (Sauna).
D.h., man konnte zusehen, wie die Leistung immer in 20Watt Paketen erhöht wurde. Vollkommen crazy.
Hier musst Du mir mal auf die Sprünge helfen. Bei mir auf dem Cerbo GX ist der RAM mit RW gemountet, oder sehe ich das falsch
root@einstein:~# mount
/dev/mmcblk1p3 on / type ext4 (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=465376k,nr_inodes=116344,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /var/volatile type tmpfs (rw,relatime)
/dev/mmcblk1p5 on /data type ext4 (rw,noatime)
/dev/mmcblk0p1 on /run/media/mmcblk0p1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /service type tmpfs (rw,nosuid,nodev,mode=755)
