PV-Überschussladen via DOIFs und Go-E-Charger

[Muschelpuster]

Moin zusammen,

Ich will mal meine Regelung zum Solar-Überschussladen mit DOIFs posten. Das ist keine hohe Schule, funktioniert aber.

Ausgangslage:
Meine Solaranlage hat keinen Speicher und nur 4,2kWp. Da unser Auto hauptsächlich halbtags auf Kurzstrecken unterwegs ist bekommt es genug Sonne ab um es primär mit Sonnenstrom zu laden.
Mein E-Zähler hat eine IR-Schnittstelle die ich durch die räumliche Trenung und die Einfachheit mit NodeRed auslese und die Werte per MQTT an FHEM sende. Ursprünglich habe ich das mit dem Volkszähler gemacht, aber NodeRed ist einfach einfacher. Daher nutze ich NodeRed auch dazu Durchschnittswerte des Verbrauchs der ca. letzen 1, 5, 10 und 15 Minuten zu ermitteln und zu senden.
In der Garage hängt mein Go-E und wird über das Go-E-Modul im FHEM ausgelesen und gesteuert.

Funktion:
Ich kann einen Zukaufswert einstellen, da unsere Solaranlage ja nicht so groß ist. Das geht in 1A-Schritten. Der Go-E wird am Laden gehindert, indem die RFID-Autorisierung aktiv ist. Möchte ich manuell laden, dann kann ich einfach den Chip vorhalten oder das Laden über die App starten. Dabei sind alle Solar-Regeln außer Gefecht gesetzt, da diese sehen, dass das Auto trotz Mode RFID lädt. Zur Solarladung wird der Charger auf Mode Open gestellt.

Einschränkungen / offene Punkte:
Derzeit mache ich die Phasenumschaltung manuell. Auch wird die Leistung nach dem Ladestart zumeist erst einmal erhöht, da ich bislang die erste Anpassung der Ladeleistung nicht in Abhängigkeit der Startzeit der Ladung verzögere.
Ich hatte das Ganze ursprünglich in einem DOIF und habe das zur anfänglichen Fehlersuche etwas entzerrt. Jetzt könnte wieder alles in ein DOIF, so ist es aber auch erst einmal ok.

Zählerwerte mit User-Readings Ladesteuerung_Auto_*

Code Auswählen Erweitern


defmod MQTT2_node_red_e_zaehler MQTT2_DEVICE node_red_e_zaehler
attr MQTT2_node_red_e_zaehler IODev mqtt_Broker
attr MQTT2_node_red_e_zaehler alias E-Zähler
attr MQTT2_node_red_e_zaehler group E-Zähler
attr MQTT2_node_red_e_zaehler readingList node_red__e_zaehler:e-zaehler\x5cwerte:.* { json2nameValue($EVENT) }
attr MQTT2_node_red_e_zaehler room Energie
attr MQTT2_node_red_e_zaehler stateFormat Einkauf: einkauf_gerundet kWh | Verkauf: verkauf_gerundet kWh | Aktuell: aktuell W
attr MQTT2_node_red_e_zaehler userReadings einkauf_gerundet {int(ReadingsVal("MQTT2_node_red_e_zaehler","einkauf",0)+0.5)},\
verkauf_gerundet {int(ReadingsVal("MQTT2_node_red_e_zaehler","verkauf",0)+0.5)},\
letzte_5min {int(ReadingsVal("MQTT2_node_red_e_zaehler","letzte_5min",0))},\
letzte_10min {int(ReadingsVal("MQTT2_node_red_e_zaehler","letzte_10min",0))},\
letzte_15min {int(ReadingsVal("MQTT2_node_red_e_zaehler","letzte_15min",0))},\
Ladesteuerung_Auto {ReadingsVal("MQTT2_node_red_e_zaehler","aktuell",10000)-ReadingsVal("di_ueberschussladen","Zukauf",0)},\
Ladesteuerung_Auto_05 {int(ReadingsVal("MQTT2_node_red_e_zaehler","letzte_5min",10000))-ReadingsVal("di_ueberschussladen","Zukauf",0)},\
Ladesteuerung_Auto_10 {int(ReadingsVal("MQTT2_node_red_e_zaehler","letzte_10min",10000))-ReadingsVal("di_ueberschussladen","Zukauf",0)},\
Ladesteuerung_Auto_15 {int(ReadingsVal("MQTT2_node_red_e_zaehler","letzte_15min",10000))-ReadingsVal("di_ueberschussladen","Zukauf",0)}

Hier werden aus den gesendeten Werten einige User-Readings unter Beihilfe meines Zukauf-Sliders Zukauf aus dem DOIF di_ueberschussladen genutzt. Diese Werte habe ich in den Zähler ausgelagert, weil sie dann automatisch triggern. Grundsätzlich ziehe ich den Zukaufswert nur vom echten wert ab und kann so das Regelverhalten über oder unter die Nulllinie verschieben.

Ein-/Ausschalten der Ladung:

Code Auswählen Erweitern


defmod di_ueberschussladen DOIF ## cmd_1: Starte Ladung wenn genug Überschuss vorhanden ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_15]<-1400 and \
[MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_10]<-1400 and \
[MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]<-1400 and \
([myGoE:car_state]==3 or [myGoE:car_state]==4) and\
[myGoE:access_control_state] eq "by_RFID_or_App" and\
[di_schaltsperre:state] ne "cmd_2")\
(set myGoE amp_current 6) (set myGoE allow_charging 1)\
(set myGoE access_control_state access_open)\
(set di_schaltsperre cmd_4)\
DOELSEIF\
## cmd_2: Stoppe Ladung, wenn nicht genug Überschuss vorhanden ist: \
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]>100 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and \
[myGoE:amp_current]<7 and\
[myGoE:allow_charging]==1 and\
[di_schaltsperre:state] ne "cmd_4") \
(set myGoE allow_charging 0)\
(set myGoE amp_current 12)\
(set myGoE access_control_state by_RFID_or_App)\
(set di_schaltsperre cmd_2)\
DOELSEIF\
## cmd_3: Breche Timer für Ladestopp ab, wenn Bedingung nicht stabil ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]<100 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and \
[myGoE:amp_current]<7 and\
[myGoE:allow_charging]==1 and\
[di_ueberschussladen:wait_timer]=~"cmd_2") \
()\
DOELSEIF\
## cmd_4: Sperre Wallbox wenn kein Auto angesteckt ist (verhindert automatischen Ladestart beim nächsten Stecken)\
([myGoE:car_state]<2) \
(set myGoE access_control_state by_RFID_or_App)\
(set myGoE amp_current 12)\
(set di_einschaltsperre cmd_1)\

attr di_ueberschussladen alias Auto Start/Stop Ladung
attr di_ueberschussladen devStateIcon disabl.*:general_aus:enable initi.*|cmd.*:general_an:disable .*rro.*:icoTool
attr di_ueberschussladen group Auto
attr di_ueberschussladen readingList Zukauf
attr di_ueberschussladen repeatsame 1:1:0:1
attr di_ueberschussladen room Energie
attr di_ueberschussladen setList Zukauf:slider,-460,230,3680
attr di_ueberschussladen wait 0,2,2:180,2,2,1,1:0:0,2,1
attr di_ueberschussladen webCmd Zukauf
attr di_ueberschussladen webCmdLabel erlaubter Zukauf in W

Hier ist also der oben erwähnte Slider Zukauf zu sehen. Ansonsten gibt es eben den Start und den Stop der Ladung mit etwas Verzögerung dazu und ein Abbruch der Wait-Timer, wenn die Bedingungen nicht stabil gegeben sind. Zudem sieht man, dass ich auf das di_schaltsperre zugreife. Das ist meine 'Eieruhr' um ein zu schnelles Ein- und Ausschalten zu verhinden. Würde ich das hier mit einem Wait-Timer machen, so müsste der immer erst einmal ablaufen, auch wenn die letzte Statusänderung schon lange genug her ist. Daher habe ich das ausgelagert.

Anpassung der Ladeleistung:

Code Auswählen Erweitern


defmod di_ueberschussladen_reglung DOIF ## cmd_1: Erhöhe Ladung, wenn genug Überschuss vorhanden ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]<-250 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and \
[myGoE:amp_current]<16 and\
[myGoE:allow_charging]==1)\
(set myGoE amp_current {([myGoE:amp_current]+1)})\
DOELSEIF\
## cmd_2: Breche Timer für Erhöhung der Ladung ab, wenn Bedingung nicht stabil ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]>-250 and \
[myGoE:access_control_state] eq "access_open" and\
[di_ueberschussladen_reglung:wait_timer]=~"cmd_1") \
()\
DOELSEIF\
## cmd_3: Reduziere Ladung, wenn nicht genug Überschuss vorhanden ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]>50 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and\
[myGoE:amp_current]>6 and\
[myGoE:allow_charging]==1)\
(set myGoE amp_current {([myGoE:amp_current]-1)})\
DOELSEIF\
## cmd_4: Breche Timer für Reduktion der Ladung ab, wenn Bedingung nicht stabil ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]<50 and \
[di_ueberschussladen_reglung:wait_timer]=~"cmd_3") \
()\

attr di_ueberschussladen_reglung alias Auto Regelung Ladeleistung
attr di_ueberschussladen_reglung devStateIcon disabl.*:general_aus:enable initi.*|cmd.*:general_an:disable .*rro.*:icoTool
attr di_ueberschussladen_reglung do always
attr di_ueberschussladen_reglung group Auto
attr di_ueberschussladen_reglung readingList Zukauf
attr di_ueberschussladen_reglung room Energie
attr di_ueberschussladen_reglung wait 120:0:120:0

Wie schon geschrieben kann das auch in die Start- / Stop-Regel mit rein. Mal sehen, ob ich das mal wieder alles zusammen klebe.

Die Eieruhr:

Code Auswählen Erweitern


defmod di_schaltsperre DOIF ([di_schaltsperre:state] eq "cmd_2") ()\
DOELSEIF\
([di_schaltsperre:state] eq "cmd_X") ()\
DOELSEIF\
([di_schaltsperre:state] eq "cmd_4") ()\
DOELSEIF\
([di_schaltsperre:state] eq "cmd_Y") ()
attr di_schaltsperre alias Timer Schaltverzögerung
attr di_schaltsperre devStateIcon cmd_2:time_timer:initialize \
disabl.*:general_aus:enable\
initi.*|cmd.*:general_an:disable\
.*rro.*:icoTool
attr di_schaltsperre group Auto
attr di_schaltsperre room Energie
attr di_schaltsperre wait 720:0:720:0

Die Eieruhr wird einfach auf cmd_2 oder cmd_4 gesetzt um sie 'aufzuziehen- damit triggert man sie selber und der Wait-Timer läuft ab und sie 'schaltet um'. Daiman meinte, dass das garnicht geht, hat es jetzt aber 'abgenickt'

Fehlerabsicherung:

Code Auswählen Erweitern


defmod di_ueberschussladen_fehlerabschaltung DOIF ## cmd_1: Stoppe Ladung, falls Abregelung nicht funktioniert:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_15]>750 and\
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and \
[myGoE:allow_charging]==1) \
(set myGoE allow_charging 0)\
(set myGoE amp_current 12)\
(set myGoE access_control_state by_RFID_or_App)\
(set di_schaltsperre cmd_2)\
DOELSEIF\
## cmd_2: Reset des DOIF, wenn automatische Ladung startet\
([di_ueberschussladen:state] eq "cmd_1") ()\

attr di_ueberschussladen_fehlerabschaltung alias Laderegelung Auto Fehlerabsicherung
attr di_ueberschussladen_fehlerabschaltung devStateIcon disabl.*:general_aus:enable initi.*|cmd.*:general_an:disable .*rro.*:icoTool
attr di_ueberschussladen_fehlerabschaltung group Auto
attr di_ueberschussladen_fehlerabschaltung room Energie
attr di_ueberschussladen_fehlerabschaltung wait 4500,2,2,1:0

Ich hatte es 2x, dass die Reduzierung der Ladeleistung scheinbar artig ausgeführt wurde, der Charger oder das Modul sich aber nicht darum geschert haben. Daher habe ich diese Fehlerabsicherung eingebaut, die rein grätscht, wenn das mal wieder passieren sollte.


Soweit also der Ausflug in meine bescheidenen Ideen dazu - vielleicht kann der Eine oder Andere ja einige Anregungen für seine eigen Ladereglung gebrauchen. Ud natürlich freue ich mich über Optimierungen

Niels

[raumhafen]

Hallo Niels,

vielen Dank für die Vorstellung deiner Lösung.
Ich bin aktuell dabei das ganze so ähnlich auch bei uns umzusetzen. Hier haben mir Deine Beiträge zu diesem Thema bisher sehr geholfen.
Obwohl ich seit Jahren schon viel mit FHEM mache sind mir die DOIFs an vielen Stellen allerdings immer noch ein Buch mit sieben Siegeln.
Ich glaube ich muss mich bei den DOIFs da wohl noch etwas tiefer einarbeiten...
Ich bin daher auch noch nicht durch alle Punkte in Deinem Beitrag hier durchgestiegen habe aber zum Verständnis jetzt schon folgende Fragen:

Erste Frage:
Vor allem das Thema mit der "Eieruhr" ist mir noch nicht ganz klar.
Wenn ich das richtig verstehe ist der Zweck hier, dass das Ein/Ausschalten der Wallbox nicht zu oft stattfindet wenn der PV Überschuss stark schwankt bspw. an wolkigen Tagen.
Das heißt, nach dem Abschalten wegen zu kleinem Überschuss startet die Eieruhr und läuft dann 720 Sekunden bevor ein erneutes Einschalten stattfinden kann. Ist das der Hintergrund?

Zweite Frage:
Beim Ausschalten wartet das DOIF per wait-timer zunächst 180 Sekunden bevor wirklich ausgeschaltet wird und beim Anpassen der Ladeleistung wird 120 Sekunden vorab gewartet.
Was ist der Hintergrund für das Warten? Damit nicht zu schnell hoch/runter geregelt wird falls es starke Schwankungen gibt beim Überschuss? Ich dachte das wird sowieso damit kompensiert, dass du Durchschnittswerte der letzten 15 bzw. 5 Minuten prüfst beim PV-Überschuss?

Letzte Frage:
Du hast in den DOIFs beim Ein/Ausschalten und bei der Anpassung der Ladeleistung eine Abfrage drin, bei der du den Wait-Timer abbrichst wenn die "Bedingungen
nicht stabil" sind. Was genau bedeutet nicht stabil?

Vielen Dank vorab, LG
Michael

[papa]

Ich habe anfangs auch versucht, meine Keba Wallbox mit FHEM zu steuern. Bin dann auf eine openWB Installation umgeschwenkt. Diese kann auch einfach zum Steuern von anderen Wallboxen eingesetzt werden. Allerdings benötigt openWB (meiner Meinung nach) zu viele Resourcen. Jetzt bin ich bei evcc gelandet. Das braucht kaum Resourcen, unterstützt jede Menge Hardware und kann über einen MQTT-Server auch recht einfach in FHEM eingebunden werden.
Nur mal so als alternative Option - ohne viel Arbeit.

[raumhafen]

Jetzt bin ich bei evcc gelandet. Das braucht kaum Resourcen, unterstützt jede Menge Hardware und kann über einen MQTT-Server auch recht einfach in FHEM eingebunden werden.

Hallo papa, vielen Dank für diesen Hinweis. Ich habe das gerade mal überflogen und gesehen, dass meine im Haus verbaute Hardware auch komplett unterstützt wird.
Demnach wäre das ja wirklich eine gute Alternative. Einen Versuch ist es auf jeden Fall wert
Grüße
Michael

[Muschelpuster]

Moin Michael,

sorry für meine späte Antwort, Du bist mir durchgerutscht

Erste Frage:
Vor allem das Thema mit der "Eieruhr" ist mir noch nicht ganz klar.
Wenn ich das richtig verstehe ist der Zweck hier, dass das Ein/Ausschalten der Wallbox nicht zu oft stattfindet wenn der PV Überschuss stark schwankt bspw. an wolkigen Tagen.
Das heißt, nach dem Abschalten wegen zu kleinem Überschuss startet die Eieruhr und läuft dann 720 Sekunden bevor ein erneutes Einschalten stattfinden kann. Ist das der Hintergrund?

Korrekt. Ich hatte zu Anfang die WB mal auf 3 Phasen stehen, da ging die Ladung immer an und aus und man konnte schön sehen, wie das nicht zu schnell hintereinander passierte.

Zweite Frage:
Beim Ausschalten wartet das DOIF per wait-timer zunächst 180 Sekunden bevor wirklich ausgeschaltet wird und beim Anpassen der Ladeleistung wird 120 Sekunden vorab gewartet.
Was ist der Hintergrund für das Warten? Damit nicht zu schnell hoch/runter geregelt wird falls es starke Schwankungen gibt beim Überschuss? Ich dachte das wird sowieso damit kompensiert, dass du Durchschnittswerte der letzten 15 bzw. 5 Minuten prüfst beim PV-Überschuss?

In der Tat sind das Altlasten und die können (eigentlich) weg. Das war  der Versuch, ohne die Eieruhr auszukommen.

Letzte Frage:
Du hast in den DOIFs beim Ein/Ausschalten und bei der Anpassung der Ladeleistung eine Abfrage drin, bei der du den Wait-Timer abbrichst wenn die "Bedingungen
nicht stabil" sind. Was genau bedeutet nicht stabil?

Wenn während des Wartens auf den Verzögerungstimer die Werte wieder unter/über die Schaltgrenze gehen, würde der Befehl nach Zeitablauf trotzdem ausgeführt werden, wenn kein anderer Befehl durch eine Bedingung getriggert wird. Das habe ich damit erschlagen. Nimmt man jetzt die Schaltverzögrung weg, weil die Eieruhr diese bedient, dann wäre die ablaufende Eieruhr ja auch der Trigger und so könnte dieser Punkt dann wohl auch weg.

Das ist eben Schritt 2 vom Basteln - so viele Karten aus dem Kartenhaus ziehen wie möglich, ohne die Stabilität zu gefährden.


Niels

[ThomasFh]

Hallo,

stehe temporär nur in diesem Jahr vor der Herausforderung, dass mir zwischen 11 und 16 Uhr so um die 1,6kW an PV Überschuss bleiben, die ich gerne in eines der gerade angestöpselten E-Autos loswerden möchte. Habe einen Go-E und kann das was aktuell ins Netz geht, aus dem dbus des Victron Multiplus auslesen.
An Tagen mit Sonne/Wolke/Sonne/Wolke möchte ich nur dann laden, wenn die Sonne gerade scheint. Ist vermutlich nicht so toll für die Akkus, beschränkt sich aber auf dieses Jahr und der Ladestrom ist dann eh nur 6A.

Mit openWB möchte ich mich nicht beschäftigen, das wäre mir dann eine "Baustelle" zu viel.

@Muschelpuster,

hat sich Deine Lösung als funktional herausgestellt? D.h., nutzt Du sie noch?

Oder gibt es in FHEM schon ein fertiges Modul für das PV Überschussladen?

Danke

[Muschelpuster]

Moin Thomas,

ja, meine Lösung läuft sehr zuverlässig. Unser Auto fährt vom Mai bis zum Oktober quasi nur mit Solarstrom. Die Einschränkung ist einfach die in der Regelung bewusst eingebaute Trägheit, welche die Ladetechnik schonen soll. Ich denke da eher an die Netzteile und nicht, dass die Akkus die schwankende Ladung mit so geringen Strömen juckt, da haben die mehr Probleme mit dem Schnellladen. Allerdings lade ich ab & zu mal ohne Regelung auf 100%, damit die Zellen ausbalanciert werden. Das passiert meistens vor einer etwas längeren Fahrt.
Ich habe das Ganze jetzt leicht durch die Revision von Michael entschlackt:

Code Auswählen Erweitern

defmod di_ueberschussladen DOIF ## cmd_1: Starte Ladung wenn genug Überschuss vorhanden ist:\
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_15]<-1400 and \
[MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_10]<-1400 and \
[MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]<-1400 and \
([myGoE:car_state]==3 or [myGoE:car_state]==4) and\
[myGoE:access_control_state] eq "by_RFID_or_App" and\
[di_schaltsperre:state] ne "cmd_2")\
(set myGoE amp_current 6) (set myGoE allow_charging 1)\
(set myGoE access_control_state access_open)\
(set di_schaltsperre cmd_4)\
DOELSEIF\
## cmd_2: Stoppe Ladung, wenn nicht genug Überschuss vorhanden ist: \
([MQTT2_node_red_e_zaehler:Ladesteuerung_Auto_05]>100 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and \
[myGoE:amp_current]<7 and\
[myGoE:allow_charging]==1 and\
[di_schaltsperre:state] ne "cmd_4") \
(set myGoE allow_charging 0)\
(set myGoE amp_current 12)\
(set myGoE access_control_state by_RFID_or_App)\
(set di_schaltsperre cmd_2)\
DOELSEIF\
## cmd_3: Sperre Wallbox wenn kein Auto angesteckt ist (verhindert automatischen Ladestart beim nächsten Stecken)\
([myGoE:car_state]<2) \
(set myGoE access_control_state by_RFID_or_App)\
(set myGoE amp_current 12)\
(set di_einschaltsperre cmd_1)\

attr di_ueberschussladen alias Auto Start/Stop Ladung
attr di_ueberschussladen devStateIcon disabl.*:general_aus:enable initi.*|cmd.*:general_an:disable .*rro.*:icoTool
attr di_ueberschussladen group Auto
attr di_ueberschussladen readingList Zukauf
attr di_ueberschussladen repeatsame 1:1:1
attr di_ueberschussladen room Energie
attr di_ueberschussladen setList Zukauf:slider,-460,230,3680
attr di_ueberschussladen wait 0,2,2:0,2,2,1,1:0,2,1
attr di_ueberschussladen webCmd Zukauf
attr di_ueberschussladen webCmdLabel erlaubter Zukauf in W

Anbei mal eine Tageskurve von einem recht 'wildem' Tag mit Wolken, kurz Mittag kochen und vielleicht auch noch etwas Geschirrspüler.

Niels

[ThomasFh]

vielen Dank für das Update und vor allem die Grafik

[Muschelpuster]

Anbei mal eine Tageskurve von einem sonnigen Tag. Mittags kam meine Frau nach Hause, hat das Auto angesteckt und die Ladung hat begonnen. Dann wurde Mittag gekocht, die Ladung wurde 'regelkonform' verzögert unterbrochen und am Nachmittag hat das Auto die volle Sonne genossen. Hier bin ich noch am überlegen, ob und wie ich verhindere, dass die Ladung sofort beginnt, wenn das Auto Mittags angeschlossen wird, da das der normale Tagesablauf meiner Frau ist und so die Wahrscheinlichkeit groß ist, dass kurze  Zeit später erst einmal der Herd die Energie braucht.

Niels

[ch.eick]

Anbei mal eine Tageskurve von einem sonnigen Tag. Mittags kam meine Frau nach Hause, hat das Auto angesteckt und die Ladung hat begonnen. Dann wurde Mittag gekocht, die Ladung wurde 'regelkonform' verzögert unterbrochen und am Nachmittag hat das Auto die volle Sonne genossen. Hier bin ich noch am überlegen, ob und wie ich verhindere, dass die Ladung sofort beginnt, wenn das Auto Mittags angeschlossen wird, da das der normale Tagesablauf meiner Frau ist und so die Wahrscheinlichkeit groß ist, dass kurze  Zeit später erst einmal der Herd die Energie braucht.

Niels

Moin,
Du kannst doch im DOIF,FHEM Modus mit einem Attribut verzögern und durch eine weitere Bedingung den Timer dann auch komplett stoppen.
Beim Perl Modus kannst Du Timer setzen und diese auch gezielt abfragen.

VG
   Christian

[Muschelpuster]

Du kannst doch im DOIF,FHEM Modus mit einem Attribut verzögern und durch eine weitere Bedingung den Timer dann auch komplett stoppen.

Ja, Danke das ist bekannt. Die Verzögerung soll aber nur Werktags um die Mittagszeit greifen und sonst nicht.

Niels

[ch.eick]

Ja, Danke das ist bekannt. Die Verzögerung soll aber nur Werkrags um die Mittagszeit greifen und sonst nicht.

Hallo Niels,
dann kannst Du das auf zwei Bedingungen aufteilen, die WE und Werktag unterscheiden, den einen dann verzögert und den anderen halt nicht.
Im Perl Modus könntest Du es dann wiederum noch durch Sub Funktionen optimieren, damit der Code nicht unnötig lang wird.

VG   Christian

[satprofi]

Bin ich froh das einfacher gelöst zu haben.
ein paar Zeilen DOIF,  die den Überschuss abfragen und den ladestrom dementsprechend steuern. Ohne Eieruhr,  etc.

[Muschelpuster]

Bin ich froh das einfacher gelöst zu haben.

Super, nehmen wir gerne als Anregung

Niels

[satprofi]

Code Auswählen Erweitern




   DEF        ([10:00-17:00] and [GoECharger:amp_max_cable] > 6 and [GoECharger:allow_charging] eq "0" and [solarlog_totalpac] >= 2500) ((set GoECharger allow_charging 1),( set GoECharger amp_current 6))
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "11" and [PowerMeter] >250) (set GoECharger amp_current 12)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "10" and [PowerMeter] >250) (set GoECharger amp_current 11)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "9" and [PowerMeter] >250) (set GoECharger amp_current 10)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "8" and [PowerMeter] >250) (set GoECharger amp_current 9)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "7" and [PowerMeter] >250) (set GoECharger amp_current 8)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "6" and [PowerMeter] >250) (set GoECharger amp_current 7)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "12" and [PowerMeter] <1) (set GoECharger amp_current 11)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "11" and [PowerMeter] <1) (set GoECharger amp_current 10)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "10" and [PowerMeter] <1) (set GoECharger amp_current 9)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "9" and [PowerMeter] <1) (set GoECharger amp_current 8)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "8" and [PowerMeter] <1) (set GoECharger amp_current 7)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "7" and [PowerMeter] <1) (set GoECharger amp_current 6)
DOELSEIF ((([16:00-18:00] and [GoECharger:car_state] eq "2") and [solarlog_totalpac] >= 1 and [PowerMeter] <1) or ([GoECharger:amp_max_cable] < 6)) (set GoECharger allow_charging 0)
   FUUID      60df41ee-f33f-6917-5616-b762a43e10c0e91a
   MODEL      FHEM
   NAME       go_e_Steuerung
   NOTIFYDEV  global
   NR         100
   NTFY_ORDER 50-go_e_Steuerung
   STATE      deactivated
   TYPE       DOIF
   VERSION    24643 2021-06-16 07:26:15
   READINGS:
     2022-04-30 04:02:24   mode            deactivated
     2022-04-30 04:02:24   state           deactivated
   Regex:
   attr:
     cmdState:
       0:
         6
       1:
         12
       10:
         8
       11:
         7
       12:
         6
       13:
         off
       2:
         11
       3:
         10
       4:
         9
       5:
         8
       6:
         7
       7:
         11
       8:
         10
       9:
         9
     wait:
       0:
         15
       1:
         15
       10:
         15
       11:
         15
       12:
         15
       13:
         600
       2:
         15
       3:
         15
       4:
         15
       5:
         15
       6:
         15
       7:
         15
       8:
         15
       9:
         15
   condition:
   do:
     0:
   helper:
     DEVFILTER  ^global$
     NOTIFYDEV  global
Attributes:
   cmdState   6|12|11|10|9|8|7|11|10|9|8|7|6|off
   disable    1
   do         always
   room       DOIF
   wait       15:15:15:15:15:15:15:15:15:15:15:15:15:600