Closed PhilJaro closed 6 months ago
Hallo, ich muss leider gleich weg und kann euch bei der Fehlersuche heute nicht mehr unterstützen. Darum schnell noch ein Tipp von mir: Es gibt mehrere Faktoren die eine Regelschleife zum schwingen bringen. Darum würde ich vorschlagen erst mal die Komponente Zeit auf Eis zu legen. Bremst die Regelung auf 10 - 30 Sekunden aus. if (PowerMeter.getLastPowerMeterUpdate() <= lastUpdateCmd *+ 20 1000**) { return announceStatus(Status::PowerMeterPending); } und schaut euch dann die Werte vom Powermeter an ob sie sich bis zu nächsten Regelvorgang grob verändern.
Falls das nicht der Fall ist: Dann regeln wir zu schnell. Wir verarbeiten Messwerte die zu alt sind. Ja richtig ... genau in dieser Abfrage stellen wir sicher das die Werte vom Powermeter junger sind. Aber ist das wirklich so? Ich denke das können wir nicht mit Sicherheit sagen. Sicher können wir nur sagen "Die Werte vom Powermeter sind zu diesem Zeitpunkt angekommen". Aber eigentlich benötigen wir: "Die Werte vom Powermeter wurden zu diesem Zeitpunkt gemessen". Aber genau diese Information haben wir nicht.
Falls das der Fall ist: Könnte es an der Messtoleranz liegen wie hier beschrieben: https://github.com/helgeerbe/OpenDTU-OnBattery/discussions/861#discussioncomment-9073696
Aber eigentlich benötigen wir: "Die Werte vom Powermeter wurden zu diesem Zeitpunkt gemessen". Aber genau diese Information haben wir nicht.
In der Theorie hast du vollkommen recht. In der Praxis machen wir die Annahme, dass die PowerMeter-Messungen nicht länger als ein paar Hundert Millisekunden im Äther sind. Meiner Meinung nach ist das eine vernünftige Annahme.
Der Log ist durchaus aussagekräftig.
13:16:37.709 > Ein neues Limit wird übertragen 13:16:39.692 > Das Limit wird vom Wechselrichter angenommen 13:16:40.704 > Inverter-Statistik und PowerMeter Messung sind jünger als das zuletzt abgesetzte Limit 13:16:40.759 > Der Inverter sagt er macht jetzt weniger Strom, aber der PowerMeter hat das noch nicht bemerkt
Also mir fallen zwei mögliche Erklärungen ein: Die Überprüfung, ob der PowerMeter Wert jünger ist als das Limit-Kommando, funktioniert nicht richtig. Oder mit deinem Setup des PowerMeters ist etwas nicht wie erwartet.
Ich schau mal genauer in den Code, und @PhilJaro erläutert mal genauer, wie sein PowerMeter funktioniert. IR-Leser? Also Hichi? Oder ein Shelly 3EM oder sowas? Und dann MQTT, oder HTTPS+JSON? Direkt, oder ist da ein Mediator dazwischen?
@schlimmchen Als IR-Leser habe ich den Tibber Pulse, die Zählerdaten werden hiermit einmal die Sekunde abgelesen und von HomeAssistant direkt per MQTT bereitgestellt. Das funktioniert eigentlich gut so und ist etwas performanter als über die Tibber Cloud. Der Zähler sendet etwa alle 1–3 Sekunden den aktuellen Verbrauch, stelle ich mich davor und vergleiche die Anzeige am Display (diese aktualisiert ein mal pro Sekunde) mit den Daten die per MQTT kommen, so stimmt das zum jeweiligen Zeitpunkt immer überein.
@PhilJaro Bist du schon länger dabei und hast du dieses Problem erst seit 8b6e57cda bzw. Release 2024.03.07?
Es besteht die Möglichkeit, dass der Inverter zwar sein neues Limit erhalten hat und auch bestätigt, dass er das eingestellt hat, aber dass er noch auf dem Weg ist das Limit einzuhalten. Wenn in dieser Zeit ein PowerMeter Wert reinkommt, dann ist der jünger als das letzte Limit-Kommando. Aber der Output des Inverters könnte zu diesem Zeitpunkt noch weit weg vom neuen Limit sein. Dann warten wir außerdem auf neue Inverter-Statistiken. Bis die eintrödeln, ist der Inverter am neuen Limit tatsächlich angekommen. Der DPL fängt dann sofort an zu rechnen. Die Statistik und der PowerMeter-Wert passen allerdings nicht zueinander. Der PowerMeter-Wert wurde gemessen, als der Inverter noch hohe Ausgangsleistung hatte. Die Statistik ist jünger und sagt, dass der Inverter schon das neue Limit einhält.
Ob das konstruiert ist, weiß ich nicht. Mein Wechselrichter hat gefühlt keine Verzögerung zwischen "neues Limit erhalten" und "neues Limit wird tatsächlich berücksichtigt". Jedoch ist das echt nur ein Gefühl, ich hab keine Daten dazu.
Wenn wir das umdrehen, also darauf bestehen, dass der PowerMeter Wert jünger sein muss, als die Statistik, ist auch nicht viel gewonnen: Theoretisch kann die Statistik zwar jünger sein als das letzte Limit Kommando, aber der Inverter könnte noch auf dem Weg sein zum neuen Limit zu regeln. Auch dann kann es passieren, dass der PowerMeter Wert nicht zur Statistik passt.
Man könnte eine Statistik abwarten, die preisgibt, dass die Inverterleistung hinreichend nahe am eingestellten Limit ist. Aber: Was ist hinreichend nahe? Und wie vermeidet man, dass die Menschen mit Skalierung oder 24V Batterien Schnappatmung erleiden? Dann müsste man nach einer kurzen Zeit sowieso ins Timeout gehen und die Daten nehmen, die man hat. Gilt auch für Setups ohne Batterie, wo die Leistung dem Limit aus gutem Grund ggf. nicht entsprechen kann.
die Zählerdaten werden hiermit einmal die Sekunde abgelesen und von HomeAssistant direkt per MQTT bereitgestellt
Das klingt so als wäre meine Vermutung richtig, nämlich dass per MQTT Daten ge-publish't werden, die aber schon mehrere Sekunden alt sind. Also dieses Tool publish't jede Sekunde, auch wenn die Daten vor drei Sekunden gemessen wurden. Der DPL nimmt aber an, dass die Daten aktuell sind, wenn sie über MQTT empfangen wurden. So kommt es, dass der DPL losläuft um zu rechnen, im Glauben, dass der neue PowerMeter Wert hinreichend jung ist und die neue Ausgangsleistung des Inverters bereits berücksichtigt, während der Wert in Wahrheit noch von einer Messung stammt, bevor der Inverter das neue Limit eingestellt hat.
Ist das zutreffend?
Nein, das ist leider falsch. Das Tool frägt 1 mal die Sekunde den aktuellen Wert vom Pulse ab, ist dort ein neuer Wert vorhanden, wird ge-publish't. Somit ist der übermittelte Wert im worst case 1 Sekunde "alt".
Schau mal, ob diese Firmware dein Problem behebt. Hier wird vor der Berechnung eines neuen Limits gewartet bis ein neuer PowerMeter Wert eintrifft nicht nur nachdem die Limit-Kommandos angekommen sind, sondern auch erst nachdem neue Inverterstatistiken angekommen sind, und zwar mit 2 Sekunden Abstand.
Habe die Firmware installiert, gebe morgen bescheid, wenn das mal einige Zeit gelaufen ist.
Danke Dir aufjedenfall schonmal 👍
Sieht wesentlich besser aus, drei mal wurde allerdings trotzdem neu gestartet. Wobei ein mal fast 4 Minuten ?! Kann natürlich sein, dass das jetzt andere Probleme sind… Ist in der Firmware die Logik bzgl. Base load schon dabei?
Da hab ich mir wohl selber ein Ei gelegt :D Um 0 Uhr startet der Wechselrichter neu um die Daten zurückzusetzen… somit kann man den reboot nicht zählen.
Nur glaube ich macht der DPL jetzt gar nichts mehr …
Websocket: [/livedata][2] disconnect 07:42:31.552 > Websocket: [/vedirectlivedata][2] disconnect 07:42:31.562 > Websocket: [/batterylivedata][2] disconnect 07:42:31.729 > Fetch inverter: 116183073478 07:42:32.313 > Success 07:42:32.518 > PowerMeterClass: TotalPower: 7.00 07:42:33.748 > Fetch inverter: 116183073478 07:42:34.361 > All missing 07:42:34.364 > Nothing received, resend whole request 07:42:34.873 > Success 07:42:35.795 > Fetch inverter: 116183073478 07:42:36.305 > Success 07:42:37.843 > Fetch inverter: 116183073478 07:42:38.353 > Success 07:42:38.867 > Admin AP remaining seconds: 160 / 180 07:42:38.868 > [DPL::announceStatus] waiting for sufficiently recent power meter reading 07:42:39.789 > Fetch inverter: 116183073478 07:42:40.402 > Success 07:42:41.841 > Fetch inverter: 116183073478 07:42:42.348 > Success 07:42:42.553 > PowerMeterClass: TotalPower: 20.00 07:42:43.782 > Fetch inverter: 116183073478 07:42:44.398 > Success 07:42:45.830 > Fetch inverter: 116183073478 07:42:46.344 > Success 07:42:47.878 > Fetch inverter: 116183073478 07:42:48.393 > Success 07:42:48.902 > Admin AP remaining seconds: 170 / 180 07:42:48.904 > [DPL::announceStatus] waiting for sufficiently recent power meter reading 07:42:49.823 > Fetch inverter: 116183073478 07:42:50.435 > Success 07:42:51.873 > Fetch inverter: 116183073478 07:42:52.335 > Success 07:42:52.588 > PowerMeterClass: TotalPower: 28.00 07:42:53.817 > Fetch inverter: 116183073478 07:42:54.432 > Middle missing 07:42:54.434 > Request retransmit: 1 07:42:54.476 > Success 07:42:55.867 > Fetch inverter: 116183073478 07:42:56.377 > Success 07:42:57.811 > Fetch inverter: 116183073478 07:42:58.425 > Middle missing 07:42:58.427 > Request retransmit: 1 07:42:58.483 > Success 07:42:58.938 > [DPL::announceStatus] waiting for sufficiently recent power meter reading 07:42:58.939 > Admin AP remaining seconds: 180 / 180 07:42:59.859 > Fetch inverter: 116183073478 07:42:59.861 > Admin mode disabled 07:43:00.370 > Success 07:43:01.907 > Fetch inverter: 116183073478 07:43:02.419 > Success 07:43:02.624 > PowerMeterClass: TotalPower: 14.00 07:43:03.955 > Fetch inverter: 116183073478 07:43:04.467 > Middle missing 07:43:04.469 > Request retransmit: 1 07:43:04.501 > Success 07:43:05.901 > Fetch inverter: 116183073478
DPL ist auf verbose. Die Inverter Leistung bleib die ganze Zeit bei 90W base load wäre 50W.
Jup, macht Sinn, mein Fehler. Wenn immer neue Statistiken kommen, und so soll es ja sein, darf der DPL nicht immer auf einen noch neueren Power-Meter-Wert warten. Erforderlich ist lediglich, dass es eine neuere Statistik gibt als das letzte Update-Kommando, und dass ein neuer Power-Meter-Wert kommt nach dieser ersten neuen Statistik.
Bitte entschuldige.
Ich habe die Logik angepasst (siehe #872) und lade dich ein, neue Firmware auszuprobieren.
Läuft seit heute Morgen ohne jeglichen Neustart 👍 Würde mal behaupten, dass Deine Lösung funktioniert.
Danke Dir.
Nein, das ist leider falsch. Das Tool frägt 1 mal die Sekunde den aktuellen Wert vom Pulse ab, ist dort ein neuer Wert vorhanden, wird ge-publish't. Somit ist der übermittelte Wert im worst case 1 Sekunde "alt".
Ich habe (notgedrungen) meinen vorherigen IR-Lesekopf durch den Pulse ersetzt und falls sich dein Exemplar nicht elementar von meinem unterscheidet, werden die eigentlichen Messwerte nur alle 3-4 Sekunden aktualisiert.
Das System besteht aus zwei Komponenten: Der Pulse selbst hängt direkt am Smartmeter und funkt über ein eigenes (proprietäres?) Protokoll zur Tibber Bridge, die die Daten dann per Webserver/MQTT bereitstellt. Ich nehme mal an, du hast im HA das Abfrageintervall auf eine Sekunde gestellt, die Bridge liefert damit auch sekündlich Daten, diese sind dann aber in 75% der Fälle identisch/veraltet, weil der Pulse in der Zwischenzeit noch kein Update geliefert hat. Sieht man sogar in im WebUI:
Erschwerend kommt hinzu, dass oftmals unvollständige/kaputte SML-Pakete übermittelt werden, so dass man dann im Extremfall 7 Sekunden lang einen alten Messwert übermittelt. Für eine aktive Einspeiseregelung ist das System in dieser Form also relativ schlecht geeignet. Ich habe daher 3 Dinge unternommen:
Ich habe (notgedrungen) meinen vorherigen IR-Lesekopf durch den Pulse ersetzt und falls sich dein Exemplar nicht elementar von meinem unterscheidet, werden die eigentlichen Messwerte nur alle 3-4 Sekunden aktualisiert.
Das ist meines Wissens nach abhängig vom verbauten Zählermodel meiner sendet, laut dem, was ich dazu im Netz finden konnte „nur“ alle 1–3 Sekunden neue Werte über die IR Schnittstelle.
Ich nehme mal an, du hast im HA das Abfrageintervall auf eine Sekunde gestellt, die Bridge liefert damit auch sekündlich Daten, diese sind dann aber in 75% der Fälle identisch/veraltet, weil der Pulse in der Zwischenzeit noch kein Update geliefert hat. Sieht man sogar in im WebUI:
Ja, ich habe das Abfrageintervall auf eine Sekunde gestellt, dass hierbei dann zum großteil die gleichen alten Daten vorhanden sind, ist seitens HomeAssistant kein Problem, dort werden die Daten des Sensors nur dann erneuert, wenn auch ein neuer Wert vorliegt und somit bekommt Open-DTU auch nur dann einen neuen Wert per MQTT wenn auch ein neuer vorliegt.
Erschwerend kommt hinzu, dass oftmals unvollständige/kaputte SML-Pakete übermittelt werden, sodass man dann im Extremfall 7 Sekunden lang einen alten Messwert übermittelt. Für eine aktive Einspeiseregelung ist das System in dieser Form also relativ schlecht geeignet.
Das Verhalten kann ich bei meinem Aufbau so nicht bestätigen, dort sind so gut wie alle Pakete vollständig und können ausgewertet werden.
Abtastfrequenz erhöht: Mit ein bisschen Gewurschtel in den Node-Parametern bekommt man relativ zuverlässige ~2 Sekunden hin
Welchen Wert hast du hierfür angepasst, wenn ich fragen darf. Ich hatte mich auch schon etwas in den Parametern ausprobiert, könnte allerdings keine signifikanten Änderungen feststellen.
Das ist meines Wissens nach abhängig vom verbauten Zählermodel meiner sendet, laut dem, was ich dazu im Netz finden konnte „nur“ alle 1–3 Sekunden neue Werte über die IR Schnittstelle.
Unabhängig davon überträgt der Pulse aber in der Standardeinstellung immer nur alle 3-4 Sekunden (was auch für den eigentlichen Use Case mehr als ausreichend ist, kostet ja alles Batterielaufzeit). Mit dem USB-Lesekopf vorher wurde ich von meinem Zähler so massiv mit Daten zugesch(m)issen, dass ich die Abfrage auf 1x pro Sekunde reduzieren musste.
somit bekommt Open-DTU auch nur dann einen neuen Wert per MQTT wenn auch ein neuer vorliegt.
Dann habe ich nichts gesagt :-) Blöd wäre halt nur, wenn der stumpf den vorliegenden Wert sekündlich per MQTT rausschickt.
dort sind so gut wie alle Pakete vollständig und können ausgewertet werden.
Könnte mir gut vorstellen, dass das zählerabhängig ist. Ironischerweise ist in meinem Fall die Anzahl defekter Pakete signifikant gesunken, seit ich die Abtastrate erhöht habe. Mit dem USB-Lesekopf hatte ich dieses Verhalten btw gar nicht (oder es hat keinen Fehler geschmissen)
Welchen Wert hast du hierfür angepasst, wenn ich fragen darf.
Genau kann ich das leider auch nicht mehr sagen, war ein ziemlich wilder Nachmittag und die Defaults sind nicht wiederherstellbar. Probier mal meter_throttle_ms (bei mir jetzt 500) und short_poll_interval_qs auf 8. Nach dem Speichern immer etwas warten und die "Last data"-Statistik beobachten, dauert etwas bis das Ganze übernommen wird. Bei zu kleinen Werten scheint er überfordert zu sein, dann steigt die Latenz nach einigen erfolgreichen Übertragungen ins Unermessliche.
@PhilJaro War so freundlich, meinen Fix aus #872 zu testen, und das Ergebnis war ja positiv. Auf meinem System läuft diese Anpassung ebenfalls seit Tagen. Daher schließe ich dieses Issue.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.
What happened?
Der Wechselrichter schaltet sich oftmals ab wenn eine größere Last wegfällt und der IR Stromzähler noch „veraltete“ Daten liefert. Diese kommen in etwa alle 1-3 Sekunden.
To Reproduce Bug
Eine Last abzuschalten führt meistens zu diesem Verhalten.
Expected Behavior
Der Wechselrichter sollte nicht sofort ausgehen wenn das Limit kurz unter dem Minimum liegt.
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
g446f5d9
Relevant log/trace output
Anything else?
No response