openWB Forum

Bei mir in der Struktur haben alle Komponenten eigene Namen. Es geht also.

woupi hat geschrieben: Mo Sep 01, 2025 4:12 am Nein, nicht vergessen zu speichern:
Hier die eingegebene Bezeichnung unter Geräte und Komponente:


Und hier nochmal in der Strukturansicht:

Im ersten Screenshot sind nur die Geräte zu sehen. Die hast Du umbenannt. Die darin liegenden Komponenten vermutlich nicht.

seaspotter hat geschrieben: So Aug 31, 2025 6:09 pm

woupi hat geschrieben: So Aug 31, 2025 5:12 pm Ah, ok. Den http Zähler habe ich gelöscht.
MQTT muss ich dann noch deaktivieren. Mit den Daten aus der OpenWB laufen verschiede Skripte.
Muss ich mir genau ansehen.

Danke für die klarstellung.

Ich würde fast darauf wetten, dass genau das die Ursache deiner Problem ist. Wäre nicht das erste mal und sicher nicht das letzte Mal. Wenn auf einmal doch Werte überschrieben werden, dann arbeitet die openWB nicht mehr so wie sie soll. Daher Verbindung trennen und dann erstmal die openWB sauber zum Arbeiten bekommen. In letzter Zeit wurde auch einiges an den MQTT Topics geändert, wenn du diese Änderungen nicht auch in iob mitgezogen hast, kann es zu komischem Verhalten führen.

Ich habe in den letzten Wochen versucht, das Ganze Revue passieren zu lassen:

• Update irgendwann Ende Mai; davor lief das Laden der Citigos weitestgehend so, wie ich es mir vorstelle.

• Im Mai, Juni und Juli stand beim Laden immer deutlich mehr als die benötigten 7.500 W PV-Leistung zur Verfügung; in der Zeit keine Probleme festgestellt – oder nicht bewusst bemerkt.

• Im Juli hat mein Elektriker etwas am Zählerschrank gemacht (Steckdose verdrahtet).

• Mitte Juli war die Wetterlage nicht mehr so toll (hin und wieder bewölkt). Da sind mir die Abbrüche das erste Mal aufgefallen. Meine Aussage im ersten Post war also nicht ganz richtig – im Nachhinein betrachtet, sorry. Wichtig: Einer der Citigos kommt nur sonntags zum Laden; die Schnittmenge aus Sonntag und Bewölkung ist nicht so häufig.

• Mitte August habe ich dann – teils aus Unwissenheit, teils aus Zeitmangel – falsche Rückschlüsse gezogen, die mir erst gestern bei intensiver Recherche klar geworden sind:
  Die Server-URL unter „HTTP Zähler“ war vollkommen richtig und hat sich nicht geändert. Mein Fehler: Ich habe den hinteren Teil aus den openWB-Einstellungen nicht übernommen. Das war deppert. Danach habe ich viel probiert, die Adresse immer wieder geändert, dabei gelernt, wie es in der openWB eingestellt werden muss – und schlussendlich (ohne es bewusst zu wissen) wieder dieselbe URL gesetzt. Das ist meine Schlussfolgerung nach langem Überlegen; 100% sicher bin ich nicht.
  Was definitiv weg war: die Modbus-Adresse eines SMA-WR. Ob ich sie beim WR-Tausch im Oktober letztes Jahr einfach vergessen habe einzustellen, kann ich nicht sagen – ist aber möglich.

• Gestern ist mir zufällig aufgefallen, dass in meiner VIS (ioBroker) die Zählerstände meiner beiden Zweirichtungszähler vertauscht sind. Dann ging mir ein Licht auf:
  Der Elektriker hat die beiden IR-Leseköpfe abgenommen und vertauscht wieder angebracht. Schon vorher kamen zeitweise keine Daten – das lag an der unsauberen Platzierung. Dass sie vertauscht sein könnten, habe ich nicht bedacht.
  Dadurch hat die openWB am Ende falsche Werte bekommen.

Kurz zusammengefasst:

• Die openWB hat durch das Update im Mai höchstwahrscheinlich keine Daten verloren.

• Sie regelt seit dem Update aber definitiv nicht mehr so wie davor. Das haben @zut und @therobbot auch bestätigt. Zu viele Phasenumschaltungen führen dazu, dass die Citigos abschalten und erst durch Aus- und Wiedereinstecken wieder laden.

Für mich steht fest: Das hat nichts mit MQTT zu tun. Ich bin bei @therobbot:

Aus meiner Sicht sollte der Algorithmus ungefähr so funktionieren:

• Wenn die Bedingung zum Umschalten erfüllt ist, wird die Pufferzeit runtergezählt (das ist momentan schon so).

• Ist die Bedingung zum Umschalten nicht mehr erfüllt, wird die Pufferzeit wieder hochgezählt bis zur Maximaleinstellung (das ist momentan, soweit ich sehen kann, nicht so). Evtl. könnte man überlegen, das nur beim Hochschalten zu machen, damit man bei vorbeiziehenden Wolken eher konservativ lädt.

• Schließlich müsste aus meiner Sicht die Problematik des 1p-3p-Gaps explizit berücksichtigt werden. D.h. es sollte erst die Bedingung zum Hochschalten ausgelöst werden, wenn der Überschuss z.B. 500 W über dem kritischen Wert von 3,96 kW ist (einstellbar).

Die Lösung, die openWB auf 22 kW umzurüsten, ist zwar ein guter Hinweis, würde jedoch einen erheblichen technischen und administrativen Aufwand verursachen (stärkere Zuleitung, Anpassung der Absicherung sowie eine Genehmigung durch den VNB), der in meinem Fall voraussichtlich nicht realisierbar ist.

Dann noch kurz zum Hinweis:

In letzter Zeit wurde auch einiges an den MQTT Topics geändert, wenn du diese Änderungen nicht auch in iob mitgezogen hast, kann es zu komischem Verhalten führen.

Mir ist das im Mai aufgefallen, und ich habe alle Datenpunkte geändert.

LutzB hat geschrieben: Mo Sep 01, 2025 5:33 amIm ersten Screenshot sind nur die Geräte zu sehen. Die hast Du umbenannt. Die darin liegenden Komponenten vermutlich nicht.

Das war der richtig Punkt, Danke. Jetzt habe ich es eingetragen und es ist auch in der Struktur.

Ok - dann wird wohl ext. MQTT ursächlich sein.

aiole hat geschrieben: Mo Sep 01, 2025 6:02 am Ok - dann wird wohl ext. MQTT ursächlich sein.

Was meinst Du mit "dann wird wohl ext. MQTT ursächlich sein."?
Es wurde ja keine Daten in openWB gelöscht, wie oben richtig gestellt habe.

viewtopic.php?p=132179#p132179

dringende Bitte:
Mache jetzt dafür einen eigenen thread auf, da dein Problem des "Komponentenverschwindens" nichts mit dem thread-Thema zu tun hat.

Nun, hier hat ja alles mit allem zu tun. Da ist eine Rube-Goldberg Maschine gebaut worden und deren nicht-funktionieren hat sich irgendwann mit dem Symptom des Thread-Titels herausgestellt.

Also noch einmal: Bitte die MQTT-Verbindungen kappen (auch die vermeintlich nur lesenden) und dann so lange an der Grundkonfiguration arbeiten, bis alle Werte auf der openWB-Status-Seite mit denen der PV-Anlage übereinstimmen. Erst dann mit irgendwas anderem weitermachen.

edit: Der Thread-Titel ist übrigen auch einer, den Captain Obvious hätte schreiben können. Bei den meisten EVs führen häufige Ladestops und -starts zu einer Ladeverweigerung. Das macht aber das Auto.

aiole hat geschrieben: Mo Sep 01, 2025 8:08 am viewtopic.php?p=132179#p132179

dringende Bitte:
Mache jetzt dafür einen eigenen thread auf, da dein Problem des "Komponentnverschwindens" nichts mit dem thread-Thema zu tun hat.

Sorry, aber ich versuche es dir jetzt noch klarer mitzuteilen:

Es gibt kein Problem des "Komponentnverschwindens" und es geht nur noch um genau das Thema aus dem Thementitel.

Gero hat geschrieben: Mo Sep 01, 2025 8:16 am
Also noch einmal: Bitte die MQTT-Verbindungen kappen (auch die vermeintlich nur lesenden) und dann so lange an der Grundkonfiguration arbeiten,

Es gibt eine Instanz in iobroker mit der Verbindung zur openWB, diese habe ich nun deaktiviert.

bis alle Werte auf der openWB-Status-Seite mit denen der PV-Anlage übereinstimmen. Erst dann mit irgendwas anderem weitermachen.

Unter Status stimmen seit gestern Abend alle Aktuellen Werte.
Die Werte unter "Ertrag" für Heute und Monat stimmen nicht. Da kann ich gerade auch nicht nachvollziehen, wo die herkommen könnten, da sie utopisch sind z.B. bei den 5kW WR für Heute 396,293 kWh und Monat 396,3 kWh. Aber auch bei dem anderen passen die nicht.

Für mich sind die Ertrags Werte allerdings auch recht uninteressant und ob sie eine Auswirkung auf das Ladeverhalten haben, wage ich zu bezweifeln, dafür müssten nach meinem Verständnis die Aktuellen Werte reichen und die passen alle samt.
Habe sie aber auch schon vor abschalten der MQTT Instanz.

Bezogen auf die Ertrags Werte müsste ich, so habe ich es gestern verstanden, nach abschalten der MQTT Instanz, jetzt nochmal bis morgen warten, um dann sagen zu können, es lag an MQTT oder eben nicht, richtig?