openWB Forum

ID4U hat geschrieben: ↑Mi Okt 09, 2024 6:45 am Was genau ist bezüglich des Dimmens denn noch unklar?

Das ist ja die Aussage seitens @openWB, dass man an der Stelle erst anfangen wolle zu programmieren, wenn die Dinge umsetzbar sind. Ich denke mal, dass es da hauptsächlich um andere Geräte als Wallboxen geht. Bei den Wallboxen könnte man das dimmen eigentlich sofort umsetzen, da weiß man ja wie's geht und kann auch sofort testen. Bei den Wärmepumpen fehlt es ja seitens der Hersteller noch an Ansteuerungsmöglichkeiten. Es programmiert sich leichter, wenn man auch schon Anschauungsmaterial hat. Sonst programmiert man gegen eine Spezifikation und testet ein halbes Jahr später. Auf diese Weise muss man sich zweimal mit dem Kram beschäftigen.

Gero hat geschrieben: ↑Mi Okt 09, 2024 8:17 am Bei den Wallboxen könnte man das dimmen eigentlich sofort umsetzen, da weiß man ja wie's geht und kann auch sofort testen.

Das wäre doch ein schöner erster Schritt (allerdings können die meisten Netzbetreiber im Moment wohl eh noch nicht steuern)

Das sollte schon genau durchdacht werden. Allein die LP reichen nicht. Für die Vorzugsvariante "openWB-HEMS" (statt Direktsteuerung) mit PV-Nutzung sowie weiterer SteuVE ist schon ein bisschen was an Konfig-Aufwand nötig. Dafür wird sicher erst einmal ein Konzept erstellt.

Natürlich. Wobei der größte Teil wohl schon damit zufrieden wäre wenn zunächst erst mal die openWB's entsprechend den Vorgaben dimmbar wären. Zudem kennt die openWB ja auch schon jetzt den PV-Überschuss. Das dürfte also noch relativ einfach umzusetzen sein.

Zusätzliche SteuVE wie WP, Speicher, Klima etc. hat nicht jeder. Die könnten später Schritt für Schritt folgen. Muss ja nicht alles sofort sein. Ist bei anderen Herstellern ja auch nicht so.

ID4U hat geschrieben: ↑Do Okt 10, 2024 5:39 am ...
Zusätzliche SteuVE wie WP, Speicher, Klima etc. hat nicht jeder. Die könnten später Schritt für Schritt folgen. Muss ja nicht alles sofort sein. Ist bei anderen Herstellern ja auch nicht so.

Bei einem guten Konzept sollte das schon mit berücksichtigt werden, da ansonsten erhöhter Entwicklungsaufwand entsteht. Beim detaillierten Ausarbeiten stimme ich dir zu.

christoph.link hat geschrieben: ↑Di Okt 08, 2024 1:01 pm Nur wie wird dann die Wärmepumpe gedimmt oder abgeschaltet. Ist da Speziell für Lambda was vorgesehen? Oder kann ich dann mit dem Controlkit über die openWB einen Aktor schalten der die EVU Sperre von der Wärmepumpe aktiviert?

Gero hat geschrieben: ↑Di Okt 08, 2024 3:38 pm Wenn die Lambda per modbus dimmbar ist, ist das bestimmt der bessere Weg die per LAN zu dimmen.

Die Lambda kann nicht per Modbus/TCP gedimmt werden und der Hersteller plant aktuell auch nicht, dies umzusetzen (ich habe nachgefragt). Der aktuell einzig praktikable Weg wäre es, dass das Dimmkit das Dimmsignal auf den Ausgängen durchreicht und man dann den potentialfreien Kontakt für die EVU-Sperre der Lambda daran anschließt. Dann wäre es keine Dimmung, sondern eine Abschaltung. Aber es wäre generisch, also kompatibel mit allen Wärmepumpen, die einen potentialfreien Kontakt für die EVU-Sperre haben. Und damit wären alle Nutzer einer solchen WB und einer openWB 14a-konform unterwegs. Das ist doch die lowest hanging fruit, denn das Signal bloß durchzureichen kann auch auch entwicklungstechnisch nicht der größte Aufwand sein. Im Prinzip hat openWB das ja hier auch schon bestätigt:

ChristophR hat geschrieben: ↑Sa Aug 31, 2024 7:44 pm

tiffman hat geschrieben: ↑Mo Aug 05, 2024 8:42 pm

ChristophR hat geschrieben: ↑Mo Aug 05, 2024 7:37 pm Genau, die WPs werden ja über die SG Ready Kontakte oder Modbus o.ä. gesteuert. Sie haben aber trotzdem noch einen EVU-Kontakt, der zur Abschaltung (über das Dimmkit) dient.
-> Steuerung bleibt wie sie ist, sie kann dann nur ggf. zusätzlich abgeschaltet werden.
Zum Messen habe ich mich ja schon geäußert...

openWB hat geschrieben: ↑Mo Aug 05, 2024 6:48 pm Das Signal "durchreichen" für die Abschaltung reicht.

Klingt für mich nach einem Plan für den ersten Wurf. Dann kann auch der Satz im Shop raus, dass die Ausgänge noch nicht funktionieren. Dokumentationspflichten und gerätespezifische Entwicklung kann man ja nachher anbauen.

Hallo @openWB,
ist das Thema jetzt für die 2.1.6 mit auf der Agenda oder müssen wir noch weiter warten?

Ich verstehe nicht, weshalb das nicht möglichst schnell umgesetzt wird. Das würde alle von uns, die ihre WP und WB als mit EMS dimmbar angemeldet haben auf die rechtlich sichere Seite stellen. Mit Christoph.link ist es jetzt wieder einer mehr.

Meine uralt WP hat den EVU Kontakt bereits beschaltet, da ich ursprünglich einen WP Tarif hatte. In meiner WP lässt sich auch einstellen, welche Funktionen dann abgeschaltet werden. Also z.B Nachheizregister aus, aber Verdichter noch an...

Evtl. Mal schauen, was andere WPs da für Einstellungen mitbringen.

VG
Det

tiffman hat geschrieben: ↑Sa Okt 12, 2024 4:47 pm
Die Lambda kann nicht per Modbus/TCP gedimmt werden und der Hersteller plant aktuell auch nicht, dies umzusetzen (ich habe nachgefragt). Der aktuell einzig praktikable Weg wäre es, dass das Dimmkit das Dimmsignal auf den Ausgängen durchreicht und man dann den potentialfreien Kontakt für die EVU-Sperre der Lambda daran anschließt. Dann wäre es keine Dimmung, sondern eine Abschaltung. Aber es wäre generisch, also kompatibel mit allen Wärmepumpen, die einen potentialfreien Kontakt für die EVU-Sperre haben. Und damit wären alle Nutzer einer solchen WB und einer openWB 14a-konform unterwegs. Das ist doch die lowest hanging fruit, denn das Signal bloß durchzureichen kann auch auch entwicklungstechnisch nicht der größte Aufwand sein. ...

Bei so etwas bitte immer vorsichtig sein, wenn man es nicht selbst entwickelt .

Ins Konzept sollten die openWB-LP (dimmbar) und mehrere, andere SteuVE (meist WP, Heizstäbe, Shellies, usw.) zunächst mit der 0/1-Abschaltoption für's Dimm-&Control-Kit rein. Die Betonung liegt auf mehrere SteuVE, was zur Folge hat, dass da ein matrixähliches Konfig-Gebilde entsteht, um die Optimalvariante "HEMS-basierte §14a-Steuerung" nutzen zu können (nur dort wird Mitnutzung ggf. vorh. PV-Leistung erlaubt).

aiole hat geschrieben: ↑Sa Okt 12, 2024 6:35 pm

tiffman hat geschrieben: ↑Sa Okt 12, 2024 4:47 pm
Die Lambda kann nicht per Modbus/TCP gedimmt werden und der Hersteller plant aktuell auch nicht, dies umzusetzen (ich habe nachgefragt). Der aktuell einzig praktikable Weg wäre es, dass das Dimmkit das Dimmsignal auf den Ausgängen durchreicht und man dann den potentialfreien Kontakt für die EVU-Sperre der Lambda daran anschließt. Dann wäre es keine Dimmung, sondern eine Abschaltung. Aber es wäre generisch, also kompatibel mit allen Wärmepumpen, die einen potentialfreien Kontakt für die EVU-Sperre haben. Und damit wären alle Nutzer einer solchen WB und einer openWB 14a-konform unterwegs. Das ist doch die lowest hanging fruit, denn das Signal bloß durchzureichen kann auch auch entwicklungstechnisch nicht der größte Aufwand sein. ...

Bei so etwas bitte immer vorsichtig sein, wenn man es nicht selbst entwickelt .

Ins Konzept sollten die openWB-LP (dimmbar) und mehrere, andere SteuVE (meist WP, Heizstäbe, Shellies, usw.) zunächst mit der 0/1-Abschaltoption für's Dimm-&Control-Kit rein. Die Betonung liegt auf mehrere SteuVE, was zur Folge hat, dass da ein matrixähliches Konfig-Gebilde entsteht, um die Optimalvariante "HEMS-basierte §14a-Steuerung" nutzen zu können (nur dort wird Mitnutzung ggf. vorh. PV-Leistung erlaubt).

Genauso, wie im Dimm- und Controlkit hardcodiert ist, dass die ersten beiden Eingänge genutzt werden, könnte auch hardcodiert hinterlegt werden, dass z.B. die Ausgänge 1 und 2 (oder einfach alle) pauschal geschaltet werden.
Da die Ausgänge sowohl NC als auch NO angeschlossen werden können, wären sie sofort mit allen Geräten, die eine Abschaltung hierüber vornehmen kompatibel.
Diese Schaltung kann (und muss vermutlich auch) direkt in der Firmware des Dimm- und Controlkit umgesetzt werden, da es die Geräte bei Ausfall der Netzwerkverbindung zur openWB trotzdem abschalten muss.
Die openWB 2.x Software muss dafür noch gar nicht angepasst werden, daher verstehe ich nicht, warum das nicht als Stufe 0 bereits umgesetzt ist oder wenigstens auf Rückfragen zum Zeitplan geantwortet wird.
Ich rede bewusst nur von Abschaltung, da die Dimmung sehr gerne erst nach einem vollständigen Konzept umgesetzt werden sollte.
Wie lange die Umsetzung der Dimmung dann dauert ist mir recht egal, da ich dann bereits rechtskonform bin.

Aktuell kann ich leider noch keine Anmeldung der WP als neue SteuVE über EMS vornehmen und auch noch keinen Elektriker dies anschließen lassen.
Mein Dimm- und Controlkit liegt daher seit dem Kauf noch sinnlos im Karton rum.
Das würde ich gerne zeitnah ändern.

Die §14a-Steuerung ist primär in sw2 angesiedelt. Das ist Stufe 0.

Zusätzliche Absicherungen über FW sind sicher denkbar, aber wir sollten nicht gleich übertreiben.
Der "Fall der Fälle" ist ein seltenes worst case-Szenario, wo Strom knapp ist, aber für Steuergeräte und ein paar SteuVE noch vorhanden ist (wenn nicht, ist auch die SteuVE stromlos und überlastet nichts mehr). Auch stört es das Netz nicht, wenn mal ein paar % der Netzteilnehmer §14a falsch konfiguriert haben oder es nicht korrekt arbeitet. Für so etwas sind Reserven eingeplant.

Vor weiterer quick&dirty §14a-Implementierung möchte ich eindringlich warnen. Das Team hat §14a auf dem Schirm. Wie bei vielen features äußert sich openWB aber erst, wenn etwas spruchreif ist. Das war zumindest in der Vergangenheit immer so.

Eigene PR machen leider auch wenig Sinn, wenn man das angestrebte Konzept nicht kennt. Dahingehend bleibt nur, sich in Geduld üben, auch wenn verringerte Netzentgelte locken.