Mein Victron-System mit Ohmpilot-Ansteuerung

[Letraz]

Hallo zusammen
Ich habe seit Ende 2024 ein Victron-System bestehend aus einem Cerbo GX, drei Multiplus II 5000 und einer DC-gekoppelten 23kWh Batterie von Modual. Zusätzlich war bereits ein Wechselrichter Symo 10.0-3-M von Fronius mit 10kW Leistung und die Fronius Wärmelösung mit einem Ohmpiloten vorhanden. Als Heizstab habe ich zwei 7.5kW Heizstäbe im Warmwasserboiler, wovon derzeit aber lediglich einer in Verwendung ist. Ebenfalls steuere ich über die Überschussproduktion (Regelung im Wechselrichter) bei einer Solarleistung > 6kW meine CTA-Wärmepumpe an. Da diese aber keinen SmartGrid-Eingang sondern lediglich einen Pseudo-SmartGrid hat, kann ich keine genaue Leistung vorgeben. Stattdessen kann ich sie lediglich zum Anlaufen anregen. Ob sie dann tatsächlich einschaltet, entscheidet die Heizung nach ihren eigenen Kriterien.

Mein Ziel war von Anfang an, den Solar-Überschuss sowohl in der erwähnten Heizung, der Batterie als auch gleichzeitig im Warmwasserboiler speichern, anstatt ihn zu lediglich 0.14 Rp./kWh an meinem Energielieferanten zu verkaufen.

Es galt folgende Herausforderungen zu meistern:

• Die Aufhebung der auf Modbus RTU basierten Regelung zwischen Wechselrichter und Ohmpilot
• Die Anzeige des Stromverbrauchs der Heizung
• Das Berechnen des aktuellen Energieüberschusses aus der Solaranlage
• Das Entwickeln einer eigenen Ohmpilot-Ansteuerung

Mir war von Anfang an klar, dass diese Anforderungen auf eine eigene Regelungstechnik hinauslaufen würde und es derzeit keine fertig verfügbare Lösung gibt. Ich fand nur heraus, dass offenbar einige Leute ebenfalls auf der Suche nach einer Ansteuerbarkeit eines Ohmpiloten mit einem Cerbo GX sind. Der Ingenieur in mir war also getriggert und als Hobby-Programmierer war ich herausgefordert

Während die Einbindung des Wechselrichters im Cerbo GX automatisch erfolgte, war die Anzeige des Energieverbrauchs der Heizung sowie die Ansteuerung des Ohmpiloten eine echte Herausforderung.

Einbindung des Energieverbrauchs der Heizung:
Ich messe den Energieverbrauch der Heizung bereits mit einem entsprechenden Drehstromzähler. Die Daten dazu sind auf einem Emu-Impulslogger mittels einem HTTP_Request im JSON-Format abrufbar. Nur wie kommen diese Daten in den Cerbo GX ? Nach einiger Recherche fand ich das Github-Projekt “https://github.com/freakent/dbus-mqtt-devices”. Damit lässt es sich realisieren, dass im Cerbo GX eine (oder in meinem Fall auch mehrere) virtuelle Ladepunkte generiert werden und mittels MQTT mit Daten gefüttert werden. Dank NodeRed auf dem Cerbo geht das gleich alles auf demselben Gerät.

Somit sehe ich nun den Energieverbrauch der Wärmepumpe, als auch diejenige des Ohmpiloten als EVCS, also Elektrofahrzeug-Ladepunkt.
Und übrigens: Ja, das funktioniert auch mit der neuen Cerbo GX Version 3.60. Ich bin mit dem Entwickler Martin Jarvis nicht verbandelt, aber er freut sich bestimmt über eine kleine Zuwendung, wenn ihr sein Projekt ebenfalls so hilfreich findet wie ich es tue

Steuerung des Ohmpiloten via Cerbo GX
Durch allgemein zugängliche Informationen fand ich heraus, dass sich der Ohmpilot entweder durch Modbus RTU oder auch Modbus TCP ansteuern lässt. Der Plan, die Modbus RTU-Verbindung zu kappen und die Ansteuerung dann via Modbus TCP via Cerbo GX vorzunehmen klingt verlockend einfach. Zu einfach, wie sich alsbald herausstellte. Der Ohmpilot ist erstaunlich hartnäckig und nachhaltig mit dem Wechselrichter bzw. dem Datalogger darin verbunden. Wird die serielle Leitung des Modbus RTU gekappt, reklamiert der Ohmpilot alsbald mit einer fehlenden Verbindung zum Datalogger. ABER einige Zeit später steht die Verbindung wieder, denn es wird nun automatisch Modbus TCP verwendet. Und eine Parallel-Ansteuerung von zwei Modbus TCP-Slaves macht weder Sinn, noch funktioniert es. Hier ist nach wie vor guter Rat teuer, denn selbst Fronius als Hersteller kann mir nicht mitteilen, wie ich die Kopplung zwischen Datalogger und Ohmpilot trennen kann. Das Ticket ist aber noch offen, wer weiss, plötzlich gibt es eine Lösung.
Edit: Gemäss Fronius gibt es derzeit KEINE Möglichkeit eine bestehende Kopplung eines Dataloggers mit einem Ohmpilot zu trennen. Bleibt also nur die Blockierung der Kommunikation via einer Firewall/Router.

Mein Plan B ist bisher die Verhinderung der Kommunikation via meiner Firewall. Dazu habe den Ohmpiloten IP-mässig in ein anderes VLAN konfiguriert und blockiere die Kommunikation auf Port 502 von und zum Datalogger. Mir ist dabei natürlich bewusst, dass ich mit Kanonen auf Spatzen schiesse, aber HEY es funktioniert

Um dann den Ohmpiloten via Modbus TCP steuern zu können ist wiederum etwas Zusatzsoftware auf dem Cerbo GX nötig. Dieses Mal aber lediglich in Form einer Zusatzpalette in NodeRed. Diese nennt sich “node-red-contrib-modbus”. Sobald installiert hat man Nodes zur Verfügung, mit welchen man via Modbus TCP kommunizieren kann.

Und dann wird lediglich noch etwas Hirnschmalz verwendet, um die Logik zu basteln. Auch hier gibt es ein paar Hürden zu meistern.

• Es darf unter keinen Umständen Leistung aus der Batterie für den Ohmpiloten verwendet werden
• Es darf unter keinen Umständen Leistung aus dem Netz für den Ohmpiloten verwendet werden
• Sollte die Heizung ebenfalls laufen, kann der Ohmpilot wahlweise abgeschaltet werden
• “Sanfte Regelung” um grössere Lastsprünge zu verhindern
• Berücksichtigung der Leistungen pro Phase und damit “Schonung” der Relaiskontakte des Ohmpiloten

Man kann sich fragen, warum ich nicht ein bereits vorhandenes Energiemanagement-System verwende, welches alle diese Funktionen bereits unterstützt. Die klare Antwort:
Ich möchte GLEICHZEITIG die Batterie, die Heizung und gegebenenfalls den Ohmpiloten ansteuern und nicht nur durch Prioritäten regeln müssen. Und das kann bisher kein anderes Energiemanagement-System !

Nach gut einem halben Jahr kann ich nun stolz eine funktionierende Lösung präsentieren:

Das Dashboard zeigt die entsprechenden Werte und die relevanten Steuerungsparameter lassen sich natürlich zur Laufzeit fein-tunen

In NodeRed gibt es dazu pro “Aufgabe” einen Flow:

1. Daten vom Ohmpiloten abholen
   

   

2. Daten von der Heizung abholen
   

   

3. Und hier die Logik der Regelung. Viel sieht man nicht, weil die Logik in den FunctionNodes “Überschussregelung”, “Glättungslogik 2.0” und “Schaltlogik 2.0” versteckt" ist

[sega]

@Letraz Lässig Arbeit, stellst du den Flow vielleicht zum Download?

[Letraz]

Hier meine Flows “as is”. Anpassungen an euere Gegebenheiten/Systeme sind notwendig.

flows.zip (19,6 KB)

[AL15 (Alois)]

Wow genau wonach ich suche

Kannst du mir vielleicht sagen wie du den ohmpilot am gx konfiguriert hast - werd aus dem git nicht ganz schlau was genau zu machen ist nach der installation?

danke!

glg

AL

[Letraz]

Hallo @AL15
Ich setze vor aus, dass du die nötige Software aus dem GitHub-Projekt Github-Projekt “https://github.com/freakent/dbus-mqtt-devices” erfolgreich und ohne Fehler installiert hast. Danach musst du mittels NodeRed-Flow via MQTT den Ohmpiloten anlegen. Das mache ich in meinem Flow im Tab “Ohmpilot” und “1) Gerät registrieren als “evcharger” und als Temperaturfühler”. Dort abonniere ich zuerst das topic “ohmpilot” im dbus des Cerbo. Danach publiziere ich eine Statusmeldung. –> also genau so, wie es im GitHub beschrieben ist.

Ab dann hast du den Ohmpiloten im Cerbo. Allerdings noch ohne irgendwelche Daten oder Steuermöglichkeit.
Ob du den Ohmpiloten korrekt via MQTT im Cerbo registriert hast, siehst du auch mit dem Befehl “dbus-spy”, wenn du dich via SSH in den Cerbo einloggst. Dort muss der Ohmpilot als Gerät ersichtlich sein (markierte Zeile). Eigentlich müsste das soweit funktionieren, wenn du meinen Flow verwendest.

Klappt das bei dir soweit erstmal ?

[AL15 (Alois)]

hi,

danke bin ein stück weiter

Ohmpilot wird angezeigt, verbrauch und temperatur, aber steuern kann ich ihn noch nicht. Denke, das liegt noch am fronius wechselrichter. Der ohmpilot ist per modbus kabel und LAN angeschlossen. kann es sein das das problem das modbus kabel ist?

Versuche auch gerade ein VLAN einzurichten komme aber nach IP Änderung am Ohmpilot noch nicht per web hin - muss schauen, woran das liegt - irgendwie mag mich mein ohmpilot wohl nicht so selbst ein laptop am gleichen switch mit dem selben IP range erreicht ihn mit der neune ip nicht…

Danke

lg

AL

PS: was muss ich den aus den flows allws löschen, um die Heizung zu entfernen?

[Letraz]

Hallo @AL15

Sehr gut, die erste Hürde ist damit geschafft. Die nächste ist die Ansteuerung des Ohmpiloten via Modbus TCP …

Bitte lies noch einmal GENAU meine initiale Beschreibung durch. Dort habe ich die Thematik der Ansteuerung vom Ohmpiloten beschrieben. Ja, die serielle Verbindung (Modbus RTU) zwischen Ohmpilot und Wechselrichter muss getrennt und die IP-Kommunikation der beiden Geräte miteinander verhindert werden. Ob du den Ohmpiloten gleich in ein separates VLAN oder nur in ein separates Subnetz nimmst und die Firewall den Zugriff regelt ist letzendlich egal und richtet sich nach deinen vorhandenen Möglichkeiten. Der Cerbo GX muss aber für den Ohmpiloten erreichen bleiben.
Tipp: Mach es dir doch einfach und ziehe erstmal einfach das LAN-Kabel des Wechselrichters (bsp. abends, wenn ohnehin kein Strom mehr erzeugt wird) ab. So kannst du dich um die Ansteuerung des Ohmpiloten kümmern ohne dass der Wechselrichter dazwischenfunkt. Denn das wird dich sicher noch etwas beschäftigen …

Um die Heizung aus den Flows herauszunehmen musst du dich mit NodeRed beschäftigen. Das ist ohnehin ratsam, da du verstehen musst, was der Cerbo GX dem Ohmpiloten mitteilen soll. Sei dir bewusst, du regelst hier u. U. grössere Lasten!
Bei mir ist die Heizung zentraler Bestandteil in den Funktionsnodes. Theoretisch kannst du einfach alles was mit “Heizung” zu tun hat rauslöschen. Hier kann ich dir im Rahmen dieses Forums nicht bis in das kleinste Detail helfen. Aber frag doch bsp. ChatGPT um Hilfe, wenn du dir unsicher bist. Die KI-Codes sind zwar nicht immer die besten, aber besser als die, wenn man kein JavaScript kann

[AL15 (Alois)]

Hi,

DANKE habs soweit hinbekommen - hätte noch ein paar fragen:

• kann man den manuellen bzw auto modus oder boost irgendwie über die Victron GX GUI steuern?

  

• In der GX GUI werden keine Wattzahlen angezeigt, wenn ich CTA entferne, kannst du mir nen tip geben ob es eine Möglichkeit mit einer anderen mqqt Adresse gibt dies anzuzeigen, wenn nur ein Gerät unter EVCS vorhanden ist??

• 
  

• hast du vielleicht nen link wo ich mehr Infos zu der Hysterese finden kann und wie du auf die Logik gekommen bist (versteh soweit glaub ich alles was passiert aber der Hintergrund würde mich interessieren)

DANKE nochmals für deine Hilfe und diese tolle Integration!

glg

AL

[Letraz]

Hallo @AL15

Sehr schön funktioniert das bei dir soweit

Der Modus bei EVCS spielt insofern keine Rolle, da ich diese Anzeige lediglich zur Visualisierung der aktuellen Leistung meiner CTA-Heizung oder des Ohmpiloten verwende. Du kannst damit deinen Ohmpiloten also NICHT steuern. Ich habe mich aber auch nicht weiter damit beschäftigt, ob man den Modus in NodeRed auswerten und verwenden kann, da ich hierzu das NodeRed-Dashboard verwende.

Da ich zwei EVCS registriere (Heizung und Ohmpilot) habe ich in den Übersicht ebenfalls keine Wattzahlen. Die einzelnen Leistungen sehe ich erst, wenn ich EVCS anklicke und dann die einzelnen “Ladestationen” sehe. Ich vermute, du hast zumindest einmalig ebenfalls zwei EVCS registriert (das siehtst du mit dbus-spy), daher hast du das gleiche Verhalten. Wahrscheinlich genügt es bei dir, wenn du CTA entfernst bzw. den Wert “Connected” auf 0 setzt. Dann musst du natürlich auch dafür sorgen, dass du die Heizung bei einem Neustart des Cerbo nicht wieder registrierst (den entsprechenden Flow löschen oder deaktivieren)

Kriegst du denn nun die Leistungswerte des Ohmpiloten via Modbus ? Die Werte solltest du im Flow unterhalb des entsprechenden Modbus-Nodes sehen. Ebenfalls muss MQTT verbunden sein, um die Werte an den “virtuellen” EVCS zu übertragen. Es gibt dazu keine andere MQTT-Adresse, du musst die verwenden, mit welcher du den Ohmpiloten registriert hast.

Ich kann dir keinen Link geben, welcher die verwendete Hysterese erklärt. Das ist eine Eigenentwicklung von mir. Vor x Jahren hatte ich mal Regelungstechnik in meinem Studium. Ich kann dir daher lediglich meinen Denkansatz verraten. Die gesamte Logik ist in den drei Functionnodes “Überschussberechnung“, “Glättungslogik 2.0“ und “Schaltlogik 2.0“ eingebaut. Der Grund für diese drei Nodes ist die Gliederung des Codes zwecks Übersichtlichkeit.

• Überschussberechnung:
  Wie der Name schon sagt, berechne ich in diesem Node primär den verfügbaren Überschuss. Ich gehe davon einzig und allein von der vorhandenen PV-Leistung abzüglich aller Verbraucher wie die angeschlossene AC-Last (bei mir ist das ganze Haus), allenfalls die Leistung für die Ladung der Batterie und einer regelungstechnischen Pauschale (weil die Werte ja ständig schwanken und damit ein Schwingen der Regelung verhindert wird). Wie du vielleicht siehst, überlasse ich das Laden der Batterie den Experten, also dem Cerbo und dem BMS. Da fummle ich nicht daran herum. Ich beziehe einzig die Ladeleistung in die Berechnung ein, wenn der Ladestand unter 80% ist, wobei das Benuterdefiniert geändert werden kann. Bis die Batterie dann auf 95% geladen ist, wird noch die Hälfte des Überschuss für den Ohmpiloten verwendet. Zudem ein paar Sicherheitsüberlegungen und Verhinderungen, dass der Ohmpilot zuviel Leistung bezieht und die Batterie entleeren könnte.

• Glättungslogik 2.0
  Hier wird der berechnete Überschuss etwas geglättet und ein Durchschnittswert über eine konfigurierbare Anzahl an Werten gemittelt. Standardmässig werden die letzten 5 Werte verwendet, was einer Glättung über 10 Sekunden entspricht. Das kann man in den Einstellungen verändern. Zusätzlich arbeite ich hier mit einer Hysterese und einer Schrittweite für die Leistungsanpassung (welche sich ebenfalls verändern lassen). Damit erzeuge ich eine gewisse Trägheit, damit die Steuerung nicht ins Schwingen kommt und zu viele und vor Allem zu grosse Änderungen an der Leistung des Ohmpiloten vornimmt. Lieber mehrere kleinere Änderungen als zu viele Grosse. Zudem ist hier die Logik verbaut, damit der Ohmpilot einerseits abgeschaltet, manuell mit einer gewissen Leistung betrieben oder eben im Automatik-Modus arbeitet.
  Deine Frage zur verwendeten Hysterese-Logik lässt sich somit wie folgt beantworten:

  • Ist die berechnete Leistungsänderung zwischen zwei Berechnungen (also alle 2 Sekunden, weil ich in diesem Intervall die Daten aus dem Wechselrichter abfrage) kleiner oder grösser als die gesetzte Hysterese passiert gar nichts und der aktuelle Wert wird beibehalten.

  • Ist die berechnete Leistungsänderung zwischen zwei Berechnungen grösser/kleiner als die Hysterese aber kleiner als die definierte Schrittweite wird der halbe Wert der berechneten Laständerung entweder nach oben oder nach unten verrwendet. Somit resultiert eine kleine Anpassung.

  • Andernfalls wird die definierte Schrtittweite für die Leistungsanpassung verwendet. Dies dient der Verhinderung von grossen Lastsprüngen und da die Multiplus II ohnehin max. 400W pro Sekunde Laständerungen durchführen kann (oder darf ?) habe ich mich daran orientiert.

  Dann wiederum ein paar Sicherheitsüberprüfungen, damit nur die konfigurierte max. Leistung an den Ohmpiloten abgegeben wird. Ich habe hier zwar 8000W definiert, obwohl ich nur einen 7.5kW Heizstab habe, aber die Erfahrung hat gezeigt, dass der Heizstab eben bis 8000 Leistung beziehen kann.

• Schaltlogik 2.0
  Hier wird verhindert, dass zu viele Male die Leistung geschaltet wird, welche mehrere Phasen betreffen. Es ist bekannt, dass die Relais im Ohmpiloten zwar für 16A ausgelegt sind, aber auch bei kleineren Leistungen und zu vielen Schaltvorgängen verbacken (also zusammenkleben können). Da mir das nun schon dreimal passiert ist und Fronius in der OIriginal Ohmpilot-Steuerung offensichtlich nur marginale Anpassungen vorgenommen hat, habe ich mich diesem Problem ebenfalls selber angenommen. Muss ich ja auch, wenn nun der Cerbo die Leistungsvorgabe macht und nicht mehr der Wechselrichter bzw. Datamanager.
  Mein Heizstab hat total 7.5kW Leistung, also 2500W pro Phase.
  Die Logik ist ist also wie folgt (grob umschrieben):
  Die angeforderte Leistung muss während mind. 30s höher sein, als die derzeit geschaltete Anzahl an Phasen es hergibt. Gleiches gilt für ein Abschalten einer Phase. Das Erreiche ich bsp. damit, dass jede Phase nur alle 30s geschaltet werden kann. Und da ich nicht die einzelnen Phasen schalten kann (der Ohmpilot entscheidet selber, ob er nun Phase 2 (L2) oder Phase 3 (L3) einschaltet oder abschaltet bei einer Leistungsänderung von > 2500W) regle ich das eben mit der Angabe der totalen Leistung (=des Überschusses)

Reicht dir diese Erklärung erstmal so ?

[AL15 (Alois)]

Super danke für die ausführliche Antwort and deine Arbeit!!!

GLG

Alois

[Free_1]

Wirklich sehr tolles Projekt!

Auch ich hätte das eine oder andere Projekt umzusetzen und bräuchte wirklich dringend Hilfe!

Gibt es eine Möglichkeit mit dir in Kontakt zu treten? Eine Privatnachricht Funktion gibt es hier ja leider nicht?

LG und Hochachtung nochmal für deine Leistung!

[AL15 (Alois)]

Hallo,

habe jetzt die Regelung ein paar Tage beobachtet und ich glaube es gibt bei mir noch ein Problem mit der Überschussberechnung - konkret geht es um diesen Teil des Codes:

// Berechnung des Überschusses inkl. Berücksichtigung des Batterielevels
let surplus = 0;
if (soc < battery_level_priority) {
surplus = solar_power - aclast - battery_power - pauschal; //SOC berücksichtigt
if (surplus < 0) {
surplus = 0;
}
if (battery_power > 1000 && surplus > 500) { // Sicherstellen, dass die Batterie möglichst schnell geladen wird
surplus = 500;
}
k_grund = ⚠️ Batterie hat Ladepriorität da SOC (${soc}) < Schwellenwert (${battery_level_priority});
}
else {
surplus = solar_power - aclast - pauschal; //SOC ignoriert = gleichzeitiges Laden Batterie & Ohmpilot
if (soc < 95) {
surplus = Math.floor(surplus * 0.5); //In der Zielzone SOC > 80 bis SOC = 95 Batterieladung mit 50% surplus
if ((surplus + 200) > battery_power) { // Sicherstellen, dass nicht der Ohmpilot mehr Leistung bezieht als die Batterie
surplus = battery_power -200;
}
k_grund = ⚠️ Surplus auf 50% begrenzt weil SOC (${soc}%) < 95%;
}
}

Bei mir startet der Ohmpilot seine Arbeit sofort, wenn die ersten Sonnenstrahlen Strom erzeugen (was ich ja eigentlich nicht will da der Akku auf 65% ist) - wenn ich den code richtig verstehe liegt es an dieser Zeile:

if (battery_power > 1000 && surplus > 500) { // Sicherstellen, dass die Batterie möglichst schnell geladen wird
surplus = 500;
}

Warum steht hier battery_power > 1000 ? Denke dieser Wert wird nicht erreicht da sofort der Ohmpilot Energie zieht und der Akku nur minimal Strom bekommt - in meinem Fall sieht das so aus zu dem Zeitpukt:

Kannst du mir vielleicht kurz erklären was du mit der battery_power = 1000W abprüfst und wie du auf den Wert kommst? Sollte ds vielleicht statt battery_power solar_power sein?

Auch die sureplus 500W würden mich Interessieren - denke der Wert ist definiert um zumindest 500W immer für den OhmPilot zur Verfügung zu stellen - stimmt meine Annahme?

Danke nochmals

lg

AL

[Letraz]

Hallo @AL15

Ich denke bei dir ist die Batterie nicht korrekt in den Flow implementiert oder du hast allenfalls andere Variablennamen verwendet als ich. Der Batterie-Node bei dir hat den Namen “Batteriy”, heisst allenfalls auch die Variable so ? Ich sehe, dass die Batterie offenbar mit 174.4 W geladen wird, aber im Status der Überschussberechnung ist der Wert 0. Hier ist der Fehler zu suchen. Zudem mache ich an der Batterieladung nichts, das knobelt der Cerbo und das BMS miteinander aus.

Ohne Batterieladung berechnet die Steuerung 5300W Überschuss und der Ohmpilot verbraucht davon 5249 W. So gesehen arbeitet die Steuerung korrekt

[AL15 (Alois)]

Hallo,

danke für den Hinweis - hab, denke ich das Problem gefunden:

Gespeichert wurde als global.Battery_power

aber in der Überschussberechnung wurde es mit

flow.get(“Battery_power”) versucht zu laden…

Hab mal auf global.get(“Battery_power”) geändert und schau dann morgen wie es läuft

Kannst du mir noch sagen, was es mit den 500W auf sich hat - ist meine Annahme das wenn zm Zeitpunkt x der Akku mit mehr als 1000W geladen wird und noch mehr als 500W zusätzlich verfügbar sind (zb surplus 1250W), 500W fix für den OhmPilot verwendet werden aber eben nicht mehr (1250W) ?

if (battery_power > 1000 && surplus > 500) { // Sicherstellen, dass die Batterie möglichst schnell geladen wird
    surplus = 500;
}

Falls das so stimmt, warum hast du 500W gewählt?

DANKE nochmals

lg

AL

[Letraz]

Ja, fast

Wenn die Batterie mit mehr als 1000W geladen wird und immer noch mehr als 500W Überschuss vorhanden ist, wird der verfügbare Überschuss und damit natürlich auch die Leistung des Ohmpiloten auf 500W begrenzt. Dies aber nur solande der SOC unterhalb der definierten Batterieladepriorität liegt. Die Idee dahinter ist, dass der Cerbo die Batterie bei tiefem Ladestand mit mehr Leistung laden kann (daher auch der Kommentar “Sicherstellen, dass die Batterie möglichst schnell geladen wird” im Code), aber eben gleichzeitig auch 500W für den Ohmpilot zur Verfügung steht. Hier helfe ich der Regelung etwas nach, weil es bei mir am Morgen bei tiefem Ladestand der Batterie zu einer Art Wettbewerb zwischen Ladeleistung der Batterie und Ohmpilot kam. So schaffe ich klare Bedingungen. Deshalb nenne ich es ja auch “battery_level_priority”, also eine Art Batterieladepriorität. Das siehst du etwas weiter oben im Code und beginnt mit: if (soc < battery_level_priority)

Und warum ausgerechnet 500W ? Nun, die habe ich exerimentell ermittelt. Damit funktioniert die Regelung nun (bei mir) wie erwartet.

[AL15 (Alois)]

super danke dann hab ich jetzt glaube ich auch verstanden und vor allem geht jetzt alles

Bei einem cerbo neustart hat er die default werte nicht geladen habe da einfach den trigger auf das werte laden gesetzt und auch das scheint jetzt zu passen.

Hab mal alles auch in home assistant integriert und kann jetzt auch von da die Steuerung (also auto, manual , aus und die manuelle leistung) direkt von da steuern - yeah

Danke nochmals für deine tolle Arbeit und Unterstützung!

lg

AL