openWB Forum

Hallo zusammen,

bin neu hier - daher kurze Vorstellung: Ich heiße Oliver, habe eine SolarEdge PV Anlage (18kWp) mit LG Speicher, eine Go-E Wallbox, open WB ganz frisch auf einem Raspi 4 installiert - läuft alles wunderbar.

Vielen Dank für das großartige Projekt!

Zu hause habe ich schon "immer" FHEM - und parallel/mit FHEM per MQTT angebunden NodeRed laufen.

Mein Thema ist: PV Überschuss in den Smarthome Komponenten zu verbraten. Ich kenne die SamrtHome 2.0 Konfiguration und habe mich durch viele Threads hier gelesen - aber mein Thema bisher nicht gefunden. Sollte ich es übersehen haben, freue ich mich über Links.

Konkret gehts mir darum, dass ich einige Aktoren (Tasmota/Shelly) im Betrieb habe, die pro Tag eine gewisse Mindestlaufzeit in Summe haben sollten (und je Einschaltzyklus auch eine gewisse Mindestdauer, aber das ist ja vorhanden).

Beispiel: Poolpumpe - die sollte bei uns im Sommer in Summe ca. 5h laufen. Wann ist mir egal. Aber am Ende des Tages (am Besten konfigurierbar) sollten 5 Stunden gelaufen sein. Sie kann also immer, wenn trotz EV-Ladung, Speicherladung, was auch immer noch Rest ist, für die Mindestlaufzeit pro Intervall (z.B. 10 Minuten) loslaufen, und so lange weiterlaufen, wie noch Überschuss da ist.
Zudem soll rechtzeitig vor vorgegebener Endzeit die benötigte Restlaufzeit stumpf eingeschaltet werden.

Beispiel: Durch die Intervalle haben sich über den Tag verteilt 3h40min Laufzeit kumuliert - dann fehlen noch 1h20min um das Tagessoll von 5h voll zu bekommen. Wenn das Tagessoll um 21:00 Uhr erreicht sein muss, heißt dass, die Pumpe wird um 19:40 Uhr angeschaltet - egal, was der Überschuss macht.

Das Ganze idealerweise optimiert durch eine Priorisierung mehrerer Smart Home Geräte und ggf. auch einer Berücksichtigung des erwarteten Verbrauchs des Gerätes (Beispiel wieder: Poolpumpe zieht 450W - bei 300W Überschuss passt die vielleicht gerade nicht, aber die Heizung vom Wasserbett kann angeschaltet werden, die zieht "nur" 240W max.)

Aktuell habe ich begonnen, sowas in NodeRed zu implementieren - Praxistests stehen noch aus, da aktuell wenig Sonne .
Die Überschusswerte bekomme ich per MQTT von OpenWB.
Ich finde es aber sinnvoller, die ganze Steuerung des Überschussverbrauches an einer Stelle zusammenzuführen - und OpenWB bietet sich dazu an.

Ich könnte natürlich auch die Regelung openWB überlassen - und die Mindestlaufzeit extern abbilden, aber schicker wärs an einer Stelle.

Jetzt ist mein Text doch etwas länger geworden - ich hoffe, es war verständlich und wurde nicht schon hundertmal diskutiert.

Ich freue mich jedenfalls über Tipps/Hinweise, wie ich sowas am sinnvollsten an OpenWB anbinden kann - oder noch mehr über eine passende Umsetzung in OpenWB.

Oliver

Ist bei mir ganz ähnlich. Die Poolpumpe soll eine Mindestanzahl an Stunden laufen, wenns geht tagsüber mit Überschuss, wenn nicht nachts.
Erschwerend kommt bei mir aber noch dazu, dass wir bei unserem Aufstellpool die Pumpe immer ausstecken wenn der Pool genutzt wird. Ohne PV war das kein Problem, da ist die Pumpe einfach immer nachts gelaufen, das ändert sich jetzt mit PV natürlich.
Ich werde es so lösen, dass ich ein "altes" HTTP-Smarthome-Gerät in openWB konfiguriere, und dann mit einem kleinem Skript den aktuellen Status des Devices in MQTT publish:
viewtopic.php?f=11&t=2181&p=20719#p20719
Dadurch bleibt openWB der zentrale Überschuss-Manager und kann zwischen Auto(s) und Geräten verteilen.

Die Poolpumpe ist an einen TP-Link Zwischenstecker mit Leistungsmessung angeschlossen.
Zusätzlich gibt es bei mir dann noch ein kleines Python Skript, dass die Poolpumpe entsprechend Überschuss eben Ein/Ausschaltet und die Poolpumpe nachts einschaltet wenn nicht genügend gelaufen. Und das Skript kann halt anhand der Leistungsmessung erkennen ob die Pumpe wirklich läuft, also auch eingesteckt ist, oder ob nur das Relais des Zwischensteckers geschlossen ist.

Da es eine so spezielle Lösung ist erwarte ich nicht dass das implementiert wird, aber eine einfache Mindestlaufzeit wäre denke ich trotzdem sinnvoll!

Vielen Dank, ja den Thread hatte ich auch gelesen - ist natürlich auch eine Variante mit den Scripten - und sowas hatte ich hiermit gemeint:

Ich könnte natürlich auch die Regelung openWB überlassen - und die Mindestlaufzeit extern abbilden, aber schicker wärs an einer Stelle.

Muss dann extern nur die Laufzeit mitzählen und gegen Ende entscheiden, ob noch laufen muss.
Könntest Du mir ggf. Dein Pumpenscript noch zur Verfügung stellen? Wenn DU das als Shellscripte implementiert hast - wo speicherst Du die Gesamtlaufzeit je Device?

dron72 hat geschrieben: ↑So Dez 27, 2020 7:48 pm .....

Mein Thema ist: PV Überschuss in den Smarthome Komponenten zu verbraten. Ich kenne die SamrtHome 2.0 Konfiguration und habe mich durch viele Threads hier gelesen - aber mein Thema bisher nicht gefunden. Sollte ich es übersehen haben, freue ich mich über Links.

Konkret gehts mir darum, dass ich einige Aktoren (Tasmota/Shelly) im Betrieb habe, die pro Tag eine gewisse Mindestlaufzeit in Summe haben sollten (und je Einschaltzyklus auch eine gewisse Mindestdauer, aber das ist ja vorhanden).

Beispiel: Poolpumpe - die sollte bei uns im Sommer in Summe ca. 5h laufen. Wann ist mir egal. Aber am Ende des Tages (am Besten konfigurierbar) sollten 5 Stunden gelaufen sein. Sie kann also immer, wenn trotz EV-Ladung, Speicherladung, was auch immer noch Rest ist, für die Mindestlaufzeit pro Intervall (z.B. 10 Minuten) loslaufen, und so lange weiterlaufen, wie noch Überschuss da ist.
Zudem soll rechtzeitig vor vorgegebener Endzeit die benötigte Restlaufzeit stumpf eingeschaltet werden.

Bezieht sich die Mindestlaufzeit pro Tag immer auf ein einzelnes Smarthome device ?

dron72 hat geschrieben: ↑So Dez 27, 2020 7:48 pm .....

Das Ganze idealerweise optimiert durch eine Priorisierung mehrerer Smart Home Geräte und ggf. auch einer Berücksichtigung des erwarteten Verbrauchs des Gerätes (Beispiel wieder: Poolpumpe zieht 450W - bei 300W Überschuss passt die vielleicht gerade nicht, aber die Heizung vom Wasserbett kann angeschaltet werden, die zieht "nur" 240W max.)

Hier hat es die heutige Priorisierung im Detail beschrieben. Du kannst über Einschaltschwelle und Einschaltverzögerung heute sehr viel steuern.
Dein Beispiel:
Wenn du bei ausreichendem Überschuss (z.b 500 Watt) Wasserbett vor Poolpumpe schalten willst
Poolpumpe Einschaltschwelle 450 Watt, Einschaltverzögerung 2 Minuten
Wasserbett Einschaltschwelle 250 Watt, Einschaltverzögerung 1 Minute
Wenn du bei ausreichendem Überschuss (z.b 500 Watt) Poolpumpe vor Wasserbett schalten willst
Poolpumpe Einschaltschwelle 450 Watt, Einschaltverzögerung 1 Minuten
Wasserbett Einschaltschwelle 250 Watt, Einschaltverzögerung 2 Minute
Wenn du nur 300 Watt Überschuss hast, wird immer Wasserbett geschaltet..
viewtopic.php?f=11&t=1808
Gruss (auch) Oliver

dron72 hat geschrieben: ↑Mo Dez 28, 2020 8:03 am Könntest Du mir ggf. Dein Pumpenscript noch zur Verfügung stellen? Wenn DU das als Shellscripte implementiert hast - wo speicherst Du die Gesamtlaufzeit je Device?

Das Skript ist noch nicht fertig.
Es ist aber ein Python Skript, dass bei mir auf einer VM läuft, also ganz unabhängig von oWB, auf dem oWB-Raspi sind nur die Skripte um den Status in MQTT zu publishen.

Das Regel-Skript rufe ich denke ich dann minütlich auf, das speichern der Laufzeit und anderer Variablen mache ich wahrscheinlich ganz trivial so dass ich die Daten einfach in InfluxDB schreibe und auch von dort wieder abrufe. Das hat für mich den Vorteil, dass ich alle Pumpendaten gleich in einem Grafana-Dashboard visualisieren kann.
Wenn das Skript fertig ist kann ich’s gerne posten, aber ich bin nur „Hobby-Informatiker“, das kann man sicher deutlich schöner lösen

okaegi hat geschrieben: ↑Mo Dez 28, 2020 8:38 am Bezieht sich die Mindestlaufzeit pro Tag immer auf ein einzelnes Smarthome device ?

Ja, genau. Ich wünsche mir eine Vorgabe der Mindestlaufzeit je Kalendertag je Smarthome Device.

- Poolpumpe muss 5h am Tag laufen
- Wasserbett muss 6h am Tag heizen
- Kühlschrank muss 4h am Tag kühlen
...
Wenn möglichst viel der Laufzeit genutzt werden kann, um die Einspeisung/den Bezug zu reduzieren und somit den Eigenverbrauch des PV Stroms zu optimieren wäre super. Es muss aber sichergestellt sein, dass auch an schlechten Tagen das Bett warm, der Pool gefiltert und der Kühlschrank kalt ist

EDIT:
Hier würde es zum Beispiel schön hinpassen:

okaegi hat geschrieben: ↑Mo Dez 28, 2020 8:38 am Hier hat es die heutige Priorisierung im Detail beschrieben. Du kannst über Einschaltschwelle und Einschaltverzögerung heute sehr viel steuern.
...
viewtopic.php?f=11&t=1808

Super! Vielen Dank für den Link und Deine Erklärungen hierzu an meinem Beispiel! Damit ist das Priorisierungsthema sicherlich gelöst.

JSAnyone hat geschrieben: ↑Mo Dez 28, 2020 9:58 am Das Skript ist noch nicht fertig.
Es ist aber ein Python Skript, dass bei mir auf einer VM läuft, also ganz unabhängig von oWB, auf dem oWB-Raspi sind nur die Skripte um den Status in MQTT zu publishen.

Das Regel-Skript rufe ich denke ich dann minütlich auf, das speichern der Laufzeit und anderer Variablen mache ich wahrscheinlich ganz trivial so dass ich die Daten einfach in InfluxDB schreibe und auch von dort wieder abrufe. Das hat für mich den Vorteil, dass ich alle Pumpendaten gleich in einem Grafana-Dashboard visualisieren kann.
Wenn das Skript fertig ist kann ich’s gerne posten, aber ich bin nur „Hobby-Informatiker“, das kann man sicher deutlich schöner lösen

Ok, gut, das bekomme ich dann auch mit NodeRed, FHEM oder eigenen Scripten hin.

Priorisierung kann über OpenWB laufen, wie ich eben gelernt habe.
NodeRed o.ä. zählt mit, wie lange jedes der Devices am Tag läuft - und schaltet bei Bedarf zusätzlich ein.
Muss man wohl "nur" je Device ein DummyDevice (wie es bei FHEM heißt) einrichten, das von OpenWB geschaltet wird - und NodeRed entscheidet dann, ob das reale Device geschaltet werden soll, oder nicht (z.B. abhängig vom Schaltstaus des Dummydevices, von Uhrzeit, erreichter Gesamtlaufzeit am Tag etc.). Wenn OpenWB und NodeRed beide gleich das reale Device schalten würden, gäbe es vermutlich komische Effekte...

Danke!

Wir haben im letzten Jahr unsere Poolsteuerung komplett automatisiert, inklusive Steuerung des 3 Wege Kugelhahn für Solarthermie. Erst wollte ich die Logik und Skripte in ioBroker auf meiner Synology laufen lassen. Letztlich haben wir aber die Steuerung direkt in einen ESP8266 ausgelagert. Die Statuswerte (Temperaturen (Heizung, Pool, Vorlauf), Status Pumpe, Chlorsteuerung und Laufzeiten) werden direkt per MQTT in den ioBroker gespielt. Außerdem lassen sich bestimmte Werte direkt per Lovelace Frontend anpassen. So kann das System auch laufen, falls mal die Wlan Verbindung abbricht (kommt leider vor) oder aber der ioBroker zickt. Wir sind damit ganz zufrieden. Mit der jetzt installierten PV Anlage wird es bzgl. der "Wenn-" Bedingungen aber wieder spannend
Ich bin auf jeden Fall glücklich bestimmte Funktionen aus dem "SmartHome"-System ausgegliedert zu haben, vielleicht ist das ja auch etwas für Dich?!

Ok, danke. Autonomie der Steuerung ist für den Pool sicherlich auch eine gute Überlegung. ESP8266 habe ich hier auch laufen - aber zu anderen Zwecken (Fingerprintsensor and Haustüre mit selbstgeschriebener Software... und natürlich stapelweise in Shellys und Tasmota Steckdosen.). Für den Pool ist das sicherlich eine Überlegung wert - für die anderen Verbraucher wohl eher nicht. Probleme mit WLAN auf der Strecke habe ich eigentlich nicht. Im Pumpenhäuschen liegt ein Netzwerkkabel; dort hängt ein Repeater dran, der auch die Wärmepumpe einbindet.
Ich werde wohl erstmal mit meiner NodeRed Variante starten, dabei Bezug/Einspeisung von OpenWB via MQTT beziehen und die Regelung NodeRed überlassen, bis es ggf. doch eine Option in OpenWB gibt.

Ich finde es vom Gefühl her sympathischer, wenn eine Stelle den Überschuss an die relevanten Verbraucher verteilt. Vielleicht wird das daher auch darauf hinauslaufen, dass NodeRed irgendwann auch die WallBox steuert - oder ich wusele mich mal in den SourceCode von OpenWB rein, wenn ich Mal Zeit habe und vertraue die Regelung komplett OpenWB an...
Noch ist ja Zeit und ich habe kaum Überschuss, den es zu Verteilen gilt

Ja, da hast Du recht. Im vergangenen Sommer hatte ich meine PV Anlage noch nicht. Ggf. werde ich die Überschussteuerung auch an die OpenWB delegieren und die darf dann ein übergeordnetes Flag setzen, auf das die Poolsteuerung reagiert. Das ließe sich ja recht simple realisieren.