openWB Forum

Lutz wird genau das selbe machen wie Du machen könntest: alle Werte abwarten und dann erst für die Regelung übernehmen. Am einfaxhsten macht Lutz das so, dass er die Schnittstelle umstellt auf ein JSON-objekt, in dem alle Werte drinstehen. Wenn er was mit warten implementiert und ggf. die eine oder andere Regelschleife überspringt, setzt er sich der Kritk aus, die Werte zu spät zu übernehmen oder gar zu ignorieren.

Ja, es ist schwierig, asynchron ankommende, aber nur gemeinsam sinnergebende Werte synchron zu bekommen. Die Node, die nur alle n messages den Inhalt weitergibt, hilft da nur begrenzt. Besser man schreibt alles in ein Flow-Memory, welches man wieder initialisiert, wenn alle Werte da sind und man die gemeinsame Message losgeschickt hat. Wenn der Absender es macht (also du) hast du den Vorteil, dass du weißt in welchem Timing die einzelnen Werte kommen.

Wie bereits geschrieben: die Publisher sind hier separate Komponenten, die unabhängig voneinander ihre Nachrichten versenden. Es liegt nicht in meiner Hand, wie oft Nachrichten veröffentlicht werden. Es gibt keine Komponente dazwischen (wie z.B. Node-RED), und die möchte ich auch nicht einführen, denn das sehe ich nicht in der Zuständigkeit des Anwenders. Ich möchte als Anwender auch keine Annahmen über die internen Timings der openWB machen, die dürfen sich ja jederzeit ändern. Insofern liegt der richtige Ort für die Synchronisation aus meiner Sicht innerhalb der openWB-Software. Und wenn ich die vorigen Beiträge richtig verstehe, scheint ja auch alles so implementiert zu sein, nur hat sich halt ein kleiner Fehler eingeschlichen.

Ah, Ok. Bislang war es immer so, dass die MQTT-Nutzer selbst die Daten mit irgendeiner Middleware eingesammelt und an die openWB weitergeleitet haben. Und ich verstehe gut, dass du da nicht extra noch eine für aufbauen willst.

Also ist nun Lutz am Zug.

Lutz ist hier nicht am Zug. Der angesprochene Fix ist schon länger im Master und auch den 2.1.8 RC enthalten.

Generell wird es je nach Zeitversatz, Größe von schnellen Leistungsschwankungen und Höhe des nicht erfassten Verbrauchs ("Hausverbrauch") immer mal wieder zu einem "ungültigem Hausverbrauch" kommen. Das liegt in der Natur der Verrechnung vieler Einzelwerte.

Vielen Dank.

LutzB hat geschrieben: So Sep 21, 2025 10:33 am Der angesprochene Fix ist schon länger im Master und auch den 2.1.8 RC enthalten.

Verstehe ich das so richtig: in 2.1.7 ist er noch nicht enthalten, in 2.1.8 wird er enthalten sein?

Genau so ist das gemeint mit 2.1.8

LutzB hat geschrieben: So Sep 21, 2025 10:33 am Lutz ist hier nicht am Zug.

Doch. Eenn er weiß:

Der angesprochene Fix ist schon länger im Master und auch den 2.1.8 RC enthalten.

Ich antworte mal in diesem etwas Faden, auch wenn er nicht mehr ganz aktuell ist:

Ist folgender Fix wirklich drin und korrekt:

LutzB hat geschrieben: Sa Apr 05, 2025 3:58 pm Es gibt aktuell einen "unschönen Effekt" bei MQTT Komponenten. Die werden quasi einen Regelzyklus versetzt zu den anderen Komponenten verarbeitet. Ein Fix ist in Arbeit.

Hintergrund ist nämlich, dass ich gerade bei mir das Zusammenspiel aus MQTT-Hauszähler und PV-Laden beobachte, und

• sehe ich Schwingungen in der Steuerung von ca. 2 kW (!) bei schönstem Wetter und sonst eigentlich konstantem Verbrauch

• sehe ich beim Zuschauen auf der openWB-Hauptseite, dass wohl der Hausverbrauch aus Zyklus t_0 für die Steuerung der Ladung zu t_1 benutzt wird, d.h. wenn die Seite aktualisiert werden gleichzeitig der neue Hausverbrauch angezeigt und die PV-Ladeleistung angepasst, aber basierend auf dem alten Hausverbrauch des Vorzyklus

Wenn ein Log dazu hilfreich ist: was soll ich hochladen?

efuture hat geschrieben: Sa Mär 07, 2026 1:41 pm Wenn ein Log dazu hilfreich ist: was soll ich hochladen?

Ein Main Log auf Details (komplettes Log, nicht nur die letzten 3 Durchgänge): viewtopic.php?t=1526

Hmm, beim Durchschauen des Main-Logs gestern ist mir noch aufgefallen, dass die Konfiguration der dynamischen Strompreise mit dem Modul "Feste Tarifstunden" zwar plausibel aussah, aber Exceptions verursachte; nachdem ich die Config veränderte und so keine Exceptions mehr auftreten, scheint auch das Schwingen in der Steuerung weg zu sein.

Genauer:
Bei uns hat es Hoch- und Niedertarifzeiten. Diese habe ich so angelegt, und als Standardpreis 0 belassen. Das schien mir inhaltlich plausibel, da immer entweder HT oder NT ist, der Standardpreis also nie zum Tragen kommt. Er verursachte aber die Exception, die mir erst gestern im Log auffiel. Seit ich hier nun einen hohen Fantasiepreis eingetragen habe, gibt es keine Exceptions mehr. Evtl. verlängerte sich dadurch die Laufzeit so, dass die MQTT-Zählerdaten immer zu spät kamen?

Sollte das Schwingen doch nochmals auftreten, werde ich es hier posten.