Heizstab aus PV-Überschuss vertreiben

[Flohlaus]

Hi,

es scheint einige Installationen zu geben, wo ein Heizstab direkt vom Wechselrichter entlang des PV-Überschusses geladen wird. Dabei werden die Heizstäbe schon bei recht niedriger Leistung aktiviert. Die Wallbox wartet also vergebens, bis 1,4kW übrig sind.
Falls dem Auto Vorrang gegeben werden soll:
Wenn die Wallbox weiß, wie viel gerade in den Heizstab fließt (z.B. vom WR per json), könnte die Ladung ja starten, wenn der Heizstab 1,4kW (oder xkW) verbraucht, auch wenn es offenbar keinen PV-Überschuss gibt. Der Heizstab wird dann verdrängt und schält ab oder drosselt.
Einfachere grobe Variante: Geladen wird anhand der PV-Produktion, ggf. mit einem festen geschätzten Offset für den Hausverbrauch.

Allgemein scheint es sehr viele individuelle Ansprüche an Laderegeln zu geben. Wäre es nicht genial, wenn man eigene Regeln aufstellen könnte? Simple Regeln beliebig verkettet?
Wenn PV-Überschuss > 5kW +
Wenn Verbraucher 3 < 2kW +
Wenn SOC1 < 70% +
Wenn zwischen halb 3 und 4 Uhr
Dann:
Laden 3phasig mit 12A
(Oder: Laden mit so viel, dass die Regeln oben grad noch erfüllt sind)
.....

Das reduziert die Komplexität weil nicht jeder Sonderfall hart integriert werden muss und gleichzeitig hat man unendlich viele Möglichkeiten.

[okaegi]

In dem Smarthomehandler ist für direkt an Openwb angeschlossenen Heizstäbe genau die Funktion bereits realisiert. Wenn ein Smarthomedevice mit "bei Autoladen Auschalten" = ja definiert wird, wird die aktuelle Leistungsaufnahme von diesem Smarthomedevice in die Überschussberechnung mit einbezogen (im Pv Modus). (Sieht man auch im Status)..
Jetzt müssten wir nur die aktuelle Leistungsaufnahme vom Heizstab der direkt am Wr angeschlossen kriegen.
@Flohlaus
Hast du so ein Teil ?
Gruss Oliver

[Flohlaus]

OK, das ist ja schonmal super.

Beim Fronius Ohmpilot kann man die Daten des Heizstabs über GetOhmPilotRealtimeData abfragen. Darunter aktuelle Leistung und verbrauchte Energie.
(Z.B. als allgemeinen json Verbraucher)

Ich habe bei mir den Ohmpilot gespart und steuere die drei Stäbe des Heizstabs jeweils über einen Ausgang des Lastmanagements vom Wechselrichter. So könnte ich über passende Schwellwerte im WR und in der OpenWB die Priorisierung regeln. Tatsächlich ist der Heizstab (2kW) aber mit dem Brauchwasser morgens relativ schnell fertig, sodass das Auto vermutlich auch solange warten kann (der erste Sommer steht bevor). Im Winter ist der Heizstab abgeschaltet, da dann eh mit Holz geheizt wird.

Wurde in Richtung einfache selbst konfigurierbare Regeln schonmal was gemacht/angedacht?


Grüße,
Florian

[openWB]

Den Smarthome 2.0 Sektor hast du dir mal angeschaut?

[Flohlaus]

Ja, das ist schon recht mächtig, steuert aber ja nur Smarthome-Zubehör, nicht den Lademodus, oder?
Mit einer übersichtlichen Art, eigene Regeln aufzustellen könnte man umgehen, dass für jeden speziellen Fall eine eigene Option programmiert wird.

[Gero]

Ich hänge mich mal hier dran. Ich habe einen PWM-geregelten Heizstab namens ATON von der Technischen Alternative aus Österreich. Der wird bei mir von einem RSM610 angesteuert, die Messdaten des Hausanschlusses kommen per modbus direkt vom S10 der Firma e3dc. In der Steuerung des RSM610 gibt es die Funktion "Energiemanager" der über die Kenntnis der per modbus bekannten Einspeiseleistung den Heizstab von 0-3kW regelt. (Das macht er so, dass er ein bisschen "aufmacht" und schaut, ob die Einspeiseleistung Null wird. Geliefert wird er allerdings mit einem per Funk angeschlossenen Meßwandler für den Einbau in der Hauptverteilung.) Nun ist es ja so, dass wenn gleichzeitig die openWB und der Heizstab den Überschuss wegregeln, da nichts Gutes bei rauskommen wird. Weshalb ja bei den smarthome 2.0-Verbrauchern gesagt werden kann, wenn das Auto geladen wird, möge dieser Verbraucher nun ausgeschaltet werden.

Nun zum Feature-Request:
Wie bekomme ich aus der openWB die Information, dass ladebereite Autos angesteckt sind, die nur darauf warten, geladen zu werden? Solange das der Fall ist, würde ich gerne den Heizstab gar nicht erst anschalten wollen.

Es gibt ja mehrere Vorbedingungen, dass PV-Laden in den Startlöchern steckt:
- Lademodus ist PV
- Ladepunkt aktiv
- Auto am Ladepunkt angeschlossen
Alle diese Punkte sind ja per modbus oder mqtt abgreifbar. Aber es wird ja erst geladen, sobald genügend PV-Überschuss vorhanden ist ***und*** das Auto auch Ladeleistung abnehmen kann. Also stellt sich die Frage nach der letzten erfolgreich gestarteten Ladung, wieviel kWh da reingingen und ob das Auto die Ladung gestoppt hat oder der PV-Überschuss nicht mehr gereicht hat. Denn erst wenn das Auto keine Leistung mehr abnehmen kann, soll der Heizstab freigeschaltet werden. All das könnte man sich ja bestimmt auch im ioBroker oder sonstwo zurechtprogrammieren, eine Einstellmöglichkeit in der openWB (wieviel kWh wurden geladen und Pausenzeit bis es wieder probiert wird) und ein Datenpunkt "Ladepunkt x wartet auf PV-Überschuss" per modbus oder mqtt wäre aber schöner.

Oder man bastelt ein neues Smarthome-Gerät "Selbstregeler" welches man bei Freigabe selbstständig die "Lücken" zwischen den anderen Verbrauchern ausregeln läßt. Die openWB sagt dann nur noch: Schalt ein und regele zwischen 0 und 3kW den aktuellen Überschuss weg. Die anderen Verbraucher haben ja wegen einer Phase immer eine Leistung zwischen 0 und 3600W. Aber dann müsste aber eine Rückmeldung der aktuell verbratenen Leistung zur openWB gehen, damit die dann den nächsten nur Ein/Aus schaltbaren Verbraucher dazu schalten kann. Denn einfach nur auf Überschuss kucken reicht ja nicht, denn der wird ja schon vom selbstregelnden Gerät verbraten.

Es gibt ja ein smarthome 2.0 "http", welchem man die aktuelle Überschussleistung mitgeben kann. Das reicht für meine Zwecke ja nicht ganz, denn ich kann dem Heizstab m.W. nach keinen direkten Heizwert mitgeben. (Da müsste ich ihm eine berechnete Einspeiseleistung vorgaukeln.)

Nun gibt es ja durchaus auch anderer Hersteller von diesen regelnden Heizstäben - myPV ist da so ein anderer, der wird wohl direkt von e3dc unterstützt - aber bei dem würde ja auch die Ladeleistungsregelung der Wallbox die Regelung zerschießen. Gesucht wird also eine einfache Möglichkeit, einen solchen Heizstab mit der openWB bekannt zu machen

[okaegi]

Die Geräte von MyPv laufen direkt mit openWB (elwa, acthor). Auf die schnelle hab ich keine Modbus Schnittstelle für Aton gefunden.
So funktioniert das Abschalten heute:
Der smarthomehändler steltt so fest ob eine Ladung tatsächlich läuft .

file_charge= '/var/www/html/openWB/ramdisk/llkombiniert
testcharge = 0
if os.path.isfile(file_charge):
f = open( file_charge, 'r')
testcharge =int(f.read())
f.close()
if testcharge == 0:
chargestatus = 0
else:
chargestatus = 1

Bei min + pv fängt ein Auto so oder so zu laden. Dann wird llkombiniert grösser 0 gesetzt und der Heizstab fliegt raus.
Bei nur pv wird der Überschuss inklusive dem Wert der abschaltbaren Smarthomedevices ( die aktuelle Leistungsaufnahme ) berechnet. Den findest du auf der Statusseite. Wenn dann das Auto mit det Ladungs startet ist llkombinert > 0 und die Heizstäbe werden ausgeschaltet.
Gruss Oliver

[Gero]

Hallo Oliver,

vielen Dank für die schnelle Rückmeldung. Es ist nicht weiter verwunderlich, dass Du kein direktes modbus gefunden hast, denn die Regelgerätewelt der Technischen Alternative kommuniziert untereinander über "DatenLeitung-Bus" oder CAN-Bus. Um von dort aus in die "normale" Welt zu kommen, ist ein weiteres Gerät, ein CMI notwendig, welches nach draußen per modbus (oder nur abgebend JSON) kommuniziert. Modbus soll auch schreibend gehen, aber das habe ich noch nicht hinbekommen. (Wenn alle Stricke reißen, schalte ich potentialfrei einen freien Eingang irgendeines TA-Reglers.)

Der Pufferspeicher wird durch vier Wärmequellen gespeist: Solar, Kamin, PV und Öl und alle Regelungen sind von TA. Da wollte ich für den Heizstab nicht noch eine neue Regelung. Aber nun triff's mich dann doch

Wenn ich Dein Coding richtig interpretiere, kann ich so aus der ramdisk die aktuelle LadeLeistungKombiniert - das müsste ja die Summe der Ladeleistungen aller Ladepunkte sein - auslesen und wenn da ein Wert ungleich null drinsteht, wird ein Auto geladen. (Das ginge ja auch per modbus oder mqtt, wenn ich alles so richtig verstanden habe) Soweit so gut. Aber wie stelle ich sicher, dass der Heizstab nicht schon vor dem Auto angefangen hat zu heizen und somit den Hausverbrauch hochgetrieben hat? Damit wäre der Überschuss für openWB um bis zu 3kW kleiner als ohne heizenden Heizstab und die Autos bekämen keinen Ladestrom, da nicht (mehr) genügend Überschuss vorhanden ist. Leider hat der Energiemanager des RSM610 keinen Parameter zur EInschaltverzögerung. Verzögerung um ein paar Sekunden deswegen, weil so die openWB die Chance bekäme, den Ladestrom der Wallbox anzuknipsen, bevor der Heizstab anfängt.

Gruss,

Gero

PS: (Eine Lösung wäre ja, die Freigabe des Heizstabs irgendwo im ioBroker um ein paar Sekunden zu verzögern) Das fällt mir gerade ein, während ich diesen Text tippe.

[okaegi]

Aber wie stelle ich sicher, dass der Heizstab nicht schon vor dem Auto angefangen hat zu heizen und somit den Hausverbrauch hochgetrieben hat? Damit wäre der Überschuss für openWB um bis zu 3kW kleiner als ohne heizenden Heizstab und die Autos bekämen keinen Ladestrom, da nicht (mehr) genügend Überschuss vorhanden ist. Leider hat der Energiemanager des RSM610 keinen Parameter zur EInschaltverzögerung. Verzögerung um ein paar Sekunden deswegen, weil so die openWB die Chance bekäme, den Ladestrom der Wallbox anzuknipsen, bevor der Heizstab anfängt.

Gruss,

Gero

PS: (Eine Lösung wäre ja, die Freigabe des Heizstabs irgendwo im ioBroker um ein paar Sekunden zu verzögern) Das fällt mir gerade ein, während ich diesen Text tippe.

Openwb startet im Modus pv + min immer eine Ladung mit mindest Amp unabhängig ob ein Pv Überschuss vorliegt. Dann als Folge ist llkombiniert > 0 und der smarthomehandler reagiert drauf und schmeist den Heiztrab raus.
Du kannst z.b. folgendes machen: definiere ein Http device mit bei " ladung ausschalten". Wenn dieses Device aktiviert wird, aktivierst du deinen Heizstab und änderst den Modus von Openwb von pv auf pv + min. Dann wird das http device automatisch ausgeschaltet wenn eine Autoladung begint.
Gruss Oliver

[Gero]

Openwb startet im Modus pv + min immer eine Ladung

Genau. Das min+PV hat vielleicht seine Daseinsberechtigung für Leute, die täglich eine feste Strecke zurücklegen und damit den Akku so weit leerfahren, dass es für die Strecke am nächsten Tag nicht nochmal reicht. Mein Anwendungsfall ist aber "Nur PV" und wenn ich weite Strecken vor mir haben sollte, schalte ich manuell am Abend vorher auf "Sofort laden", wenn es die PV der letzten Tage nicht weit genug geschafft haben sollte.

"Nur PV" bietet einem halt die Problemstellung "Lädt er oder lädt er nicht?" in Abhängigkeit vom PV-Überschuss. Den möchte ich in erster Linie ins Auto laden und in zweiter Linie in Wärme verwandeln. Und da weiß die openWB halt nicht, ob der Überschuss echter Überschuss ist, weil der Heizstab noch nicht verbraucht oder der Heizstab aus dem Hausverbrauch rausgerechnet werden muss.
Und wenn ich's ganz genau nehmen würde, müsste Überschuss jenseits der 11kW die ins Auto passen, in den Heizstab. Und so wie ich das Coding aus dem vorletzen Post verstehe, werden beim Autoladen alle smarthomeverbraucher abgeworfen und der noch vorhandene Restüberschuss eingespeist Das soll aber erst einmal egal sein, denn diese Situation stellt sich ja eh nur im Sommer ein und da ist naturgemäß der zu stillende Wärmebedarf weniger relevant

Dein Kunstgriff über ein http-Gerät klingt interessant, aber mir ist nicht klar, wie die Wallbox im Modus min+PV bei Bewölkung oder Sonnenuntergang das Laden beenden soll. Dass der smarthomehändler die aktuelle Leistung des Heizstabs kennen muss, bekäme man vielleicht noch beigefummelt.

Ich lerne jetzt erst mal ioBroker um der openWB ein wenig Vorsprung zu verschaffen, damit sie den Überschuss ins Auto packen kann, bevor der Heizstab loslegt.

Gruss,

Gero

PS: Ich stehe glaube ich generell mit dem "min+PV"-Modus auf dem Kriegsfuß, denn mir fällt dafür kein Anwendungsszenario ein. Selbst das oben genannte wäre mit "PV+ Netz auf n kWh" sinnvoller implementiert: PV lädt so viel wie kommt und falls die n kWh nicht erreicht sind, wird in der Nacht aus dem Netz nachgeladen. Also sowas wie Zielladen mit unbekanntem SoC des Autos.