Rückmeldungen software2 2.1.8-Alpha.1

[Gero]

…viel Text…

Hallo Lutz, danke für die Erklärungen, das hat mein Verständnis in die richtige Richtung geschibst.
ich hab einen neuen Vorschlag:

Bitte die Ladepunkte und/oder digitalen Ausgänge auswählen, auf welche das Verhalten angewendet werden soll. Es können mehrere Einträge ausgewählt werden.Ladepunkte werden auf 4,2kW gedimmt, eine Verrechnung mit PV-Erzeugung findet nicht statt.

Bitte die Ladepunkte und/oder digitale Ausgänge auswählen, welche berücksichtigt werden sollen. Es können mehrere Einträge ausgewählt werden. Bei steuerbaren Verbrauchseinrichtungen, die über einen digitalen Ausgang angesteuert werden, wird eine Leistung von 4,2 kW bei aktiver Dimmung angenommen. Ladepunkte werden so gesteuert, dass die angegebene Leistung am EVU-Punkt nicht ünerschritten wird. Dadurch wird eigene PV-Erzeugung verrechnet.

Und ja, mit „Kaskadierend“ meinte ich den Gleichzeitigkeitsfaktor. Aber das wird ja erst dann klappen, wenn mit einer Leistungserfassung aller geschalteten SteuVE im HEMS-Fall bekannt ist, ob sie gerade eingeschaltet sind. Dann kann ja auch die Angabe der max. Leistung am EVU-Punkt entfallen, weil sie ja über die Anzahl der ausgewählten Ladepunkte plus Ausgänge errechnet werden kann. Hier wird wahrscheinlich eines Tages eine anklickbare Liste von smarthome-Geräten mit Leistungserfassung stehen.

Edit: man könnte ja jetzt auch schon mal Zwischenzähler mit den Ausgangskontakten kombinierbar machen, so dass man einstellen kann, welcher Kontakt auf welchen konfigurierten Zähler geht. Unzugewiesene, aber aktivierte Kontakte werden mit 4,2kW angenommen.

[gpr]

Die Box schaltet immer noch bei jeder Wolke auf 1 Phase herunter. Ankündigung war dass das mit der 2.1.8 wieder entfernt wird? Verzeiht die Ungeduld, ich warte seit 3,5 Jahren auf einen SW-Stand der in meiner Konfiguration keine klar unnötigen Schaltungen macht...

[ChristophR]

Eigentlich dürfte es aus diesem Grund ja keine SteuVE geben, die auf einen im Dimmfall schließenden Kontakt lauscht. Das müsste immer anders herum sein.

Daher ist es nicht unüblich das ein NC Kontakt den Normalzustand beschreibt.
Das ist ja so auch anschließbar.
im Fehlerfall oder beim durchgehackten Kabel hast du dann die Aktivierung.
Das handhaben aber nicht alle so. Die Wechsler geben dann die nötige Freiheit.

Wir sind uns einig das das recht konstruiert ist

Nur nochmal, damit ich nicht falsch verstanden werde:
Bei der E.DIS wurde immer viel Wert darauf gelegt, dass die Ausführung als NC erfolgt, ich vermute, dass sie das auch in der neuen Regelung so umsetzen werden.
Es geht bei den digitalen Ausgängen des DuC-Kit häufig um Wärmepumpen.
Alle (oder ganz viele) älteren Wärmepumpen haben einen klassischen EVU Kontakt, der geschlossen abschaltet.
Neuere Wärmepumpen regeln das über die 2 vorhandenen SG-Ready Kontakte, auch die reagieren auf geschlossene Kontakte.
Ausgangssituation ist also NC, wobei C abgeschaltet oder gedimmt ist.

Ich kann das also an DO1/NC des Dimmkits anschließen, dann wird bei Unterbrechung und auch selbst dann, wenn das DuC-Kit mal stromlos sein sollte, gedimmt.
Nun kommt die Steuerung der openWB dazu.
Im jetzigen Zustand belässt sie den Kontakt jedoch ungesteuert, er bleibt also geschlossen.
Erst wenn sie den Steuerbefehl zur Dimmung sendet, wird der Kontakt geöffnet und die Geräte laufen ungedimmt.
Die Steuerung der openWB muss also invertiert werden.

Es hilft übrigens auch nichts, wenn ich über ein weiteres Koppelrelais die Steuerung nochmal invertiere. Dadurch bleibt der Ruhezustand trotzdem ungesteuert/gedimmt. Es kann also nicht anders gelöst werden.
Der VDE hatte auf so einen Fall extra hingewiesen, daher wäre die Umsetzung schon wichtig für uns als Betreiber.

[LutzB]

Wir klären intern, wie das umgesetzt wird. Konfigurierbar oder fix invertiert.

Ziel ist dann die SteuVE NO anzuschließen und im Normalbetrieb den Ausgang aktiv, also C zu haben.

[aiole]

Sry, aber jetzt hat das hier eine Eigendynamik, wo es nochmal zusammenfassend klar kommuniziert werden sollte.

@Christoph
a) Du schreibst, dass bei der E.DIS darauf geachtet wird, dass der Normalfall (Nichtdimmung) bei einer SteuVE mit NC abgedeckt wird.
b) schreibst du Bsp., wo es genau umgedreht ist. Normalfall = NO
Also gibt es 2 Outputszenarien.

Beide Fälle sind durch die DuC-Wechsler-Outputs und den passend gewählten Anschluss NC oder NO an die SteuVE realisierbar.

WAS sichergestellt werden muss ist nur, dass ein Verbindungsverlust des DuC die Outputs genauso schaltet wie ein realer VNB-Dimmbefehl.

Bei Stromausfall braucht es die komplette Dimmung nicht mehr.
Wir können noch mehr Ausfallszenarien wie Einzel-Ausfall openWB und/oder DuC konstruieren, aber aus VNB-Sicht sind einzelne Nichtbeachtungen einer Dimmung (, die selbst nur extrem selten oder nie kommt) unproblematisch.

Desweiteren, wenn das openWB-HEMS ausfällt, wird das schnell von der Kundschaft bemerkt. Fällt das DuC aus, gibt's Hinweise durch fehlenden heartbeat -> HEMS an den user.

[ChristophR]

Sry, aber jetzt hat das hier eine Eigendynamik, wo es nochmal zusammenfassend klar kommuniziert werden sollte.

@Christoph
a) Du schreibst, dass bei der E.DIS darauf geachtet wird, dass der Normalfall (Nichtdimmung) bei einer SteuVE mit NC abgedeckt wird.
b) schreibst du Bsp., wo es genau umgedreht ist. Normalfall = NO
Also gibt es 2 Outputszenarien.

Beide Fälle sind durch die DuC-Wechsler-Outputs und den passend gewählten Anschluss NC oder NO an die SteuVE realisierbar.

WAS sichergestellt werden muss ist nur, dass ein Verbindungsverlust die Outputs genauso schaltet wie ein realer VNB-Dimmbefehl.

Bei Stromausfall braucht es die komplette Dimmung nicht mehr.
Wir können noch mehr Ausfallszenarien wie Einzel-Ausfall openWB und/oder DuC konstruieren, aber aus VNB-Sicht sind einzelne Nichtbeachtungen einer Dimmung (, die selbst nur extrem selten oder nie kommt) unproblematisch.

Desweiteren, wenn das openWB-HEMS ausfällt, wird das schnell von der Kundschaft bemerkt. Fällt das DuC aus, gibt's Hinweise durch fehlenden heartbeat -> HEMS an den user.

Sorry, dass ich so viel Verwirrung verursache.

Ich versuche es mal anders zu formulieren:
NC oder NO am AUSGANG des DimmKit ist der openWB ja egal, da es beide Ausgänge als Wechsler gibt und man es sich dann passend anschließen kann.
Wichtig ist nur, dass der Ruhezustand (Keine Verbindung, DimmKit oder openWB ausgefallen), Dimmung entspricht.
Die openWB muss also die Ausgänge immer schalten, wenn keine Dimmung erfolgen soll.
Wenn gedimmt werden soll, müssen die Ausgänge in den Ruhezustand versetzt, also nicht geschaltet werden.
Das ist eigentlich schon alles.

Ich denke man sollte bei den Ausgängen nicht die Bezeichnungen offen/geschlossen verwenden, da das ja je nach Anschluss genau falsch sein kann.
Besser fände ich z.B. Geschaltet oder Ruhzustand(Normally?), da es nur darauf ankommt, ob das Relais in dem Dimmkit geschaltet wird (LED des Ausganges leuchtet).
Hierbei könnte jedoch verirren, dass Ruhezustand(Gedimmt) und Geschaltet(Ungedimmt) bedeutet.
Vielleicht fallen Euch ja bessere Bezeichnungen ein.

Ist es so verständlich, was ich meine?

[aiole]

Wichtig ist nur, dass der Ruhezustand (Keine Verbindung, DimmKit oder openWB ausgefallen), Dimmung entspricht.
Die openWB muss also die Ausgänge immer schalten, wenn keine Dimmung erfolgen soll.
Wenn gedimmt werden soll, müssen die Ausgänge in den Ruhezustand versetzt, also nicht geschaltet werden.
Das ist eigentlich schon alles.

Danke. Soweit verstanden.

Ich habe dazu eine andere Meinung. Falls die Outputs des DuC monostabile Relais sind, würden Fehlalarme viel wahrscheinlicher werden, weil die Relais für den Normalfall (Nichtdimmung) ständig angezogen sein müssten. Von mehr Standbyverbrauch im DuC mal abgesehen.

Ich denke, dass man durch die DuC-heartbeat-Überwachung genug getan hat, um eine hohe Funktionssicherheit für §14a zu gewährleisten (wir sind hier ja nicht bei Raketentechnik und das ganze Thema ist mehr Lobbyismus als echter use case.).
Wenn openWB und DuC zu >90% funktionieren, dann ist doch eine Überschneidung mit einem <0,01% Ereignis wie VNB-Dimmung extrem unwahrscheinlich.

Sprich - den Fall die openWB steigt aus, würde ich für §14a nicht beachten (wird eh zügig bemerkt, da ein HEMS alle wichtigsten Energieflüsse optimal steuert).
Das passive Verhalten im Normalfall (Nichtdimmung) macht vieles einfacher und sichert einen komplikationslosen 99,99% Normalbetrieb.

Die ev. Nichtbeachtung einer Dimmung ist
a) extrem unwahrscheinlich und
b) aus VNB-Sicht kein Beinbruch, da ja das gleichzeitige Versagen mehrerer openWB-HEMS noch unwahrscheinlicher ist. Eine Einzel-Nicht-Dimmung merken sie vermutlich nicht einmal.

Mir geht's hier um Verhältnismäßigkeit. Eine Dimmung ist kein 3. Weltkriegsszenario.

[Frank-H]

Softwarestand Master
2.1.8-Alpha.1
2025-03-20 12:58:37 +0100 [7551eeb38]

Es erfolgt unentwegt beim Überschussladen (1-phasig) die Meldung, dass die maximale Leistung an Zähler "E3DC" erreicht ist.
Den Phasenwechsel konnte ich nicht testen, da unsere PV, bedingt durch den Sahara-Staub. nicht genug Leistung erbracht hat.E3DC Zähler.gifE3DC Zähler.gif

Bei mir ebenfalls am SMA-Zähler. Eine Fehlfuntktion darüber hinaus konnte ich nicht feststellen.

Screenshot 2025-03-23 101441.png (12.49 KiB) 453 mal betrachtet

Hier das Log:
https://paste.openwb.de/WtG4PXmD8i5yhDQ

[raudi]

Da nun die Tage ja wieder sonniger werden habe ich mal wieder begonnen im PV Modus zu laden, erst mit der 2.1.7 und nun auch mit der 2.1.8.

Ich dachte, ich aktualisiere, weil mein Enyaq scheinbar bei Phasenwechseln auf Störung geht, und im Change-Log stand was von Phasen, da dachte ich, ich versuch es mal. Aber leider nach wie vor das gleiche Verhalten, ab und zu geht der Enyaq auf Stötung, Am Stecker leuchtet es rot und er schreibt: Bitte Hinweise an Ladesäule beachten, oder andere Säule benutzen. Und unter dem Ladebalken steht "Keine Verbindung".

Dazu kommt auch noch, dass der Mii beim PV Laden irgendwie nach einigen Minuten einfach aufhört zu laden. Es wird weiterhin angezeigt, dass die Ladung gestartet wurde und es ist auch Strom freigegeben, aber der Stecker ist gelb und es fließt kein Strom. Ziehe ich einmal das Kabel vom PKW ab und stecke erneut, dann lädt er wieder für ein paar Minuten. Nun habe ich ihn auf Sofortladen umgestellt und nun lädt er problemlos.

Main-Log https://paste.openwb.de/N5QmYI7A6zZMGZO
MQTT-Log https://paste.openwb.de/CVIPYo4mPj5tReH
SoC-Log https://paste.openwb.de/H07nWAAK5v6qm7f

Als ich hier den mindest SoC Strom geändert hatte, habe ich dann auch hier Meldungen bezüglich des Stroms am Zähler XY gesehen, so wie es hier auch bereits von anderen berichtet wurde. Das machte aber absolut keinen Sinn, er hat dann danach auch das beladen fortgeführt.

Irgendwie ist da beim Lademodus PV der Wurm drin...

Komischer weise lädt der Enyaq nun schon seit beginn auf einer Phase mit 16A, es wird nicht auf 3 Phasen umgeschaltet, ob wohl da noch 5kW über sind...

[raudi]

Der Mii ist geladen, der Hausakku auf 90%, das bedeutet er ist über 50% und es wird dafür nichts reserviert, aber er wird mit 8 kW beladen, ins Netz werden 6 kW eingespeist, aber der Enyaq wird weiter mit einer phase und 16 A geladen.

Warum wird nicht auf 3 Phasen gewechselt?

Main-Log: https://paste.openwb.de/cRg8joyuC8OvqPX
MQTT-Log: https://paste.openwb.de/L6MSVJEjrU9spvn
SoC-Log: https://paste.openwb.de/Oy3gaFEXAmlDn3r