Das braucht alles ziemlich viel Arbeitsspeicher. Ich habe alles unnötige in VenusOS abgeschaltet, was ich denke, nicht zu benötigen. Aktuell läuft venus kostal pico nicht, da ich damit etwa alle 6h einen Systemabsturz provoziere. Jede einzelne Venus Kostal Pico Instanz benötigt etwa 40MB Ram. Das ganze Device hat 512MB Ram.
Mir schweben 3 Lösungen vor:
Meint ihr, venus kostal pico lässt sich in c o.Ä. umschreiben und hat dann eine geringere Speicherauslastung? Meine Programmierkenntnisse sind sehr beschränkt, ich hatte aber mal im Studium etwas c gehabt, habe ich noch minimales Basiswissen.
Ich will an der reinen Hardware ungern etwas ändern, aber kann ich ich ein zweites Venus OS auf einen RPI mit 2GB RAM nutzen? Muss ich dann ein MK3 Adapter nutzen, oder kann ich alle das bestehende GX-Device als MK3 nutzen?
Drei Wechselrichter laufen über einen eigenen Zwischenzäher. Dort könnte ich mit einem Shelly 3EM Zähler schonmal etwas Last sparen - wobei ich auch hier die Last im Arbeitsspeicher wohl noch sehr hoch ist.
40 MByte Speicher pro Instanz ist natürlich sehr viel. Die Plugins, die ich nutze verbrauchen meist unter 100 Kilobyte. Kann mir nicht vorstellen wofür man so viel Speicher wirklich benötigt.
Habe mir den Code nicht genau angesehen und nur überflogen, aber da ist sicherlich einiges optimierbar. Direkt aufgefallen sind mir die vielen re.findall()-Aufrufe. Das kostet zwar CPU, aber nicht so viel Speicher.
Wenn der Entwickler da keine Idee hat oder nicht antwortet, muss Du Dir mal den Code ansehen und debuggen wo so viel Speicher verwendet wird (in Listen oder Strings). Wie man das macht, gibt es einige Artikel im Internet, z.B. How do I profile memory usage in Python? - Stack Overflow
Ansonsten helfen häufig auch ein paar strategisch platzierte print() der verdächtigen Listen oder Strings.
ich hatte Kontakt zum Entwickler aufgenommen, so richtig helfen konnte er mir auch nicht.
Wenn ich mir jetzt Batteryaggregator und dbus Serialbattery anschaue, habe ich schon ordentliche RAM-Auslastungen:
2058 946 root S 29468 6% 1% python /data/BatteryAggregator/battery_service.py
1993 1988 root S 57456 11% 1% python /data/apps/dbus-serialbattery/dbus-serialbattery.py LltJbd_Ble A4:C1:37:04:C3:5A
1994 1990 root S 57200 11% 1% python /data/apps/dbus-serialbattery/dbus-serialbattery.py LltJbd_Ble A4:C1:37:04:C3:6F
Generell widerstrebt sich mir halt eine Lösung, bei der ich alles bei 0 aufsetzen muss. Bisher hat mein ganzes System einigermaßen gut funktioniert. Bevor ich Serialbattery und Batteryggregator genutzt habe, hatte ich mit den sechs Kostal-WR alle 1-2 Tage Systemabstürze. Seit den beiden neuen Batterien wurde es halt öfters (6h). Daher verzichte ich aktuell auf dei Integration der Wechselrichter und habe ein stabil laufendes System (trotz zwei per BLE verbundener BMS).
Nach wirklich brutalen Diskussionen mit Microsoft Copilot (der übrigens lügt, wenn er nicht weiter kommt) hatte ich kurzzeitig die Hoffnung verloren. Dann hab ich bei heise.de von einer KI „Grok“ gehört. Damit haben wir das Python Script auf mehrere Wechselrichter (und nur Variante 3) erweitert. Der Trick war den Code von einer KI schreiben und von der anderen prüfen zu lassen. Das Script läuft. Vom Ram wurden 80mb zusätzlich frei. Hat also schon eine Ersparnis gebracht. Jetzt versuche ich mir Gewalt eine Lösung in c zu bekommen.
Alle KIs lügen wenn sie nicht weiterwissen.. Das ist das größte Problem mit denen aktuell.. Die erfinden irgendeinen Schwachsinn dazu und verteidigen den auch noch..