Live-Data: Grid Power zeigt unplausible Werte (SDM630 Power Meter) #732
Comments
|
Das mag ich nicht so recht glauben, auch wenn du jetzt der zweite bist, weil immer noch deutlich mehr als zwei schon zurückgemeldet haben, dass es mit dem gestrigen Release (wieder) einwandfrei funktioniert. Kannst du einmal sicherstellen, dass du wirklich die 2024.03.07 installiert hast (Screenshot?)? Passiert dir das auf mehreren Geräten? Wenn ja auf welchen? Kannst du den Browser einmal schließen und neu öffnen und/oder Strg + F5 benutzen und zurückmelden, ob das Problem dann verschwindet? Der Browser könnte eine alte Version der WebApp ge-cache't haben.
Wenn du im Log neue Werte siehst, dann sollten die auch in der WebApp ankommen. Trotzdem danke für diese Info, vielleicht liegt es doch am Typ des PowerMeters. |
|
Neulich habe ich hier irgendwo gelesen, dass beim Compilieren die Webapp ggf. nicht aktualisiert wird und man das separat machen muss; ist das hier der Fall? Hmm, denke schon, dass die Version aktuell ist; in der Konsole gibt's auch etliche neue, mir bisher unbekannte Log-Meldungen des DPL. Bisher getestet unter Android 14, Graphene OS, Vanadium 122 und Android, Fire OS 5.1.7.0, Firefox 124. |
|
Jetzt, mit Sonnenlicht, kann ich bestätigen, dass der MPPT Total Power-Wert auch nicht aktualisiert wird (im Live Data -Block). |
Das ist der gleiche Fehler. Hast du die Firmware selbst gebaut oder ein Release heruntergeladen? Bei den Releases wird die Webapp jeweils gebaut und dann erst mit einkompiliert (es sei denn ich hab was übersehen). Aber es gäbe keine Bestätigungen, dass alles gut sei wenn der github Build einen Defekt hätte. |
|
Die Firmware ist selbst compiliert. Ich habe Deinen Beitrag zum separaten Bauen der Webapp gefunden, es so erstmals gemacht und mit der anschließend neu compilierten Firmware werden die MPPT-Werte in 'Live Data' wieder aktualisiert. Auch die 'Grid Power'-Werte werden aktualisiert, allerdings nur sporadisch, längst nicht so oft, wie in der Konsole zu sehen, und nur selten auf genau die gleichen Werte wie in der Konsole (teilweise liegen die 'Live'-Werte in der Nähe der Konsolen-Werte, teilweise haben die gar nichts miteinander zu tun, ab und zu kommt tatsächlich der gleiche Wert). Kann man eigentlich irgendwo in den Quellen (leicht) erkennen, ob vor dem Compilieren auch ein Neubau der Webapp notwendig ist? |
|
Recherche bei mir ergibt, dass ich wohl den Buffer für das JSON zu klein gewählt habe in https://github.com/helgeerbe/OpenDTU-OnBattery/blob/c42d68812c57aa5153d8e44507d032a51ce0c97c/src/WebApi_ws_live.cpp#L102 Verdopple das doch mal testweise und sag uns, ob das Problem dann bei dir verschwindet.
Leider weiß ich das nicht. Wenn es möglich wäre, würde ich vorschlagen platformio vor dem Bau der Firmware auch die Webapp bauen zu lassen, wenn es denn nötig ist. Das aber immer zu machen ist lästig. Das wird der Grund sein, warum es tbnobody so gelöst hat, stelle ich mir vor. |
Ja, so ist es deutlich besser: Alle Powermeter-Werte, die in der Konsole erscheinen, werden auch in die 'Live Data'-Ansicht übernommen. Allerdings tauchen zwischen diesen Werten ab und zu noch andere Powermeter-Werte im Live-View auf, die nichts mit dem aktuellen Verbrauch zu tun haben (also bevor vom Powermeter überhaupt neue Werte eingetroffen sind). |
|
Okay, damit ist das sicher, dass dieser Buffer größer werden muss. Pflege ich ein. Warum du Phantasiewerte sieht, kann ich dir nicht erklären. Bist du dir sicher, dass das bis zuletzt nie so war? Würde schon helfen zu wissen, falls das ein älterer Fehler ist. Wie funktioniert dieser Power-Meter? Iteriert der die Phasen nacheinander und könnte es passieren, dass ein Power-Meter Wert an die WebApp geschickt wird, während die einzelnen Phasen abgeholt werden, sodass der Wert inkonsistent ist? |
Du hast Recht, ich habe testweise Releases aus dem Januar und Februar installiert und es kamen auch dort, asynchron zu den Konsolen-Werten, andere Grid Power-Werte im Live View an. Und zwar nur selten genau die gleichen Werte — wohingegen mit der aktuellen Version alle Werte, die in der Konsole mit 'PowerMeterClass: TotalPower: xxx' erscheinen auch in den Live View übernommen werden (zwischen diesen kommen dann halt ab und zu noch andere).
Puh, das kann ich nicht sagen… Könnte durchaus sein, was Du sagst, aber ich durchschaue den Code da nicht… |
schlimmchen
changed the title
Danke fürs Testen. Dann konzentrieren wir uns in diesem Issue nun darauf, dass dir unplausible Werte präsentiert werden unter Verwendung deines Power-Meters. Der Rest ist geklärt. |
|
Seit dem letzten Uodate muss ich gefühlt 3x Täglich den Wechselrichter neustarten, damit die DTU mit Einspeisen anfängt. Komischerweise blinkt der Wechselrichter nicht wie im Standby Rot, sondern langsam Grün. |
Vielen Dank schon mal! Es könnte durchaus sein, dass die 'Phantasiewerte' Verbrauchswerte sind, die zwischen zwei in der Konsole geloggten Powermeter-Werten gemessen werden (?), denn meistens liegen die zusätzlichen Werte in der Nähe der Konsolen-Werte. Nur selten sind die Werte sehr weit von den Konsolen-Werten entfernt — das könnten aber auch kurzzeitige Überschwinger sein. Allerdings war ich bisher der Meinung, dass das SDM ca. alle 15s abgefragt wird; wo kommen dann aber zusätzliche Messwerte her? Kann ich noch irgendwie helfen bzw. etwas zum Thema beitragen? |
the SDM power meter (among others) writes the power consumption of three phases in multiple steps. this change helps to prevent getTotalPower() reading intermediate values, i.e., reading a new value for phase 1 but old values for phase 2 and 3 since phase 2 is currently read. cache the values, and write them all at once, protected by a mutex, later. closes #732.
|
Ach herrje, dieser SDM code ist... fragwürdig. Das wundert mich sehr, dass sich Benutzter dieser Schnittstelle nicht schon häufiger über diverse Probleme beschwert haben. Also das wird jede Phase einzeln abgefragt, und jede Abfrage ist eine synchrone serielle Kommunikation, die die Haupt-Loop blockiert. Sehr spannend... Jedenfalls ist es absolut kein Wunder, dass du dieses Verhalten siehst. Alle zehn Sekunden werden alle aktuellen Werte für die Live-Ansicht übertragen, und es ist absolut plausibel, dass es häufig passiert, dass diese Abfrage des Power Meters dann einen Moment trifft, in dem mindestens eine aber noch nicht alle drei Phasen abgefragt wurden. Die Ausgabe auf der Konsole erscheint aber immer erst nach einer vollständigen Runde an Abfragen, weshalb die einigermaßen konsistent ist. Nur einigermaßen, weil zwischen den Abfragen auch signifikante Zeit vergeht und die Leistungswerte daher nie so recht zum gleichen Zeitpunkt gemessen wurden. Da bleibt nichts anderes übrig, als die ganzen Abfragen möglichst zügig hintereinander zu erledigen und die Ergebnisse aber zwischenzuspeichern und dann (am besten geschützt durch einen Mutex) gesammelt in die jeweiligen Variablen zu schreiben, sodass en Zugriff auf Ich bin mir nur unschlüssig, ob ich das wirklich noch mit einem Pflaster versehen soll, wo der PowerMeter eigentlich dringend ein Refactoring bräuchte... Ach komm, lass ein Pflaster basteln. Schau mal in #749 und spiele die dort in der Build-Pipeline gebaute Firmware ein (Abschnitt Artefakte in https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/8240226059?pr=749) und sag uns, ob dein PowerMeter weiterhin funktioniert und ob er jetzt konsistente Werte liefert. Jedenfalls sollte im LiveView nun nichts mehr auftauchen, was nicht auch in der Konsole steht. Dass die Leistungswerte der einzelnen Phasen nie so recht zum gleichen Zeitpunkt bestimmt sind, kann ich nicht ändern, das ist dem Protokoll geschuldet -- oder wenigstens der Implementierung in der SDM Lib (die ich nicht anfassen möchte). |
|
Oh, super, dass Du direkt hier weiter machst! |
|
Klar! Vergiss nicht die Web App zu bauen^^
Ja, das müssen wir auch noch angehen... |
|
Hmm, habe den branch 2ba57e2 ausgecheckt, dort die Web App und dann die Firmware gebaut: |
|
Ohje... Also es ist möglich, dass ich deine Zeit verschwende. Falls dem so ist, tut mir das leid. Lass mich morgen mal schauen, nicht dass ich einen doofen Fehler gemacht habe... |
|
Kein Problem, so ein Test tut nicht weh — bin froh, dass Du Dich überhaupt diesem Thema angenommen hast… |
the SDM power meter (among others) writes the power consumption of three phases in multiple steps. this change helps to prevent getTotalPower() reading intermediate values, e.g., reading a new value for phase 1 but old values for phase 2 and 3 since phase 2 is currently read. cache the values, and write them all at once, protected by a mutex, later. closes #732.
|
So. Ich dachte mir ja schon, dass ich versuchte das Mutex rekursiv zu sperren, aber ich musste jetzt erst einmal genau hinsehen, bevor es offensichtlich wurde, wo das passiert. Bau doch mal b101ce4 mit den Anpassungen für die Pins und versuch es nochmal. Jedenfalls ist dieser grobe Schnitzer jetzt raus. Die vorherige Version hat bei mir ehrlich gesagt auch nicht funktioniert, ich war mir meiner Sache vorgestern aber so sicher, dass ich nur das Kompilieren geprüft habe... Sorry. |
|
Mit b101ce4 sind die Live-Daten wieder da und die Konsole spricht wieder. |
|
Danke fürs Testen! ❤️
Aber es ist der zuletzt auf der Konsole ausgegebene Wert? Und wie hast du das festgestellt? Die Wwebsocket-Implementierung für die Live-Daten schickt alle 10 Sekunden alle Daten. Wenn dein PowerMeter seltener abgefragt wird, dann kommt es vor, dass im Websocket der gleiche Power-Meter-Wert zweimal landet, bevor dein PowerMeter tatsächlich einen neuen Wert abholt. |
|
Vielleicht habe ich’s nicht genau genug beschrieben. |
|
Wow, websocat, nice! 💪 Wir meinen das gleiche. Das ist richtig so, das soll so sein. Die einzige verbleibende spannende Frage wäre, ob alle Werte im Live-View bzw. im websocat (das muss dasselbe sein) die gleichen sind seit der letzten Ausgabe in der Konsole. Wenn das nicht so ist, ist das ein Fehler. Aber falls im websocat so lange dieselben Werte kommen, bis in der Konsole ein neuer Wert auftaucht, dann ist alles wie erwartet. |
|
Von der Möglichkeit, sich per Websocket mit OpenDTU zu verbinden, bzw. von websocat habe ich hier erfahren. Sorry, aber mir ist nicht klar, was genau zu untersuchen ist, bzw. ob die zusätzlichen Powermeter-Werte, die ich in den Live-Daten sehe nun ok sind, oder nicht auftauchen sollen.
Ich war der Meinung, dass der Websocket Ich habe also die in der Konsole auftauchenden Powermeter-Werte (via websocat) mit denen in den Live-Daten verglichen und in den Live-Daten tauchen zusätzliche, sich von den Konsolen-Werten unterscheidende Werte auf.
Ist das
eine Forderung, die wir beweisen wollen, oder ist das eine Tatsache? (Live-View = websocat) Hier bin ich abgehängt:
Meinst Du mit 'Konsole' auch 'Info|Console' der Webapp? Ich sehe z. B. Folgendes:
Darf das so sein? |
|
Ne, da stimmt dann was nicht. Aber du hast ja offenbar einen langen Atem, vielen Dank dafür! Dann lass uns mal weiter schauen. Ich verstehe, was du mit dem websocat gemacht hast. Du siehst da genau den Inhalt, der auch auf der Seite Info -> Console ausgegeben wird. Und das ist wiederum genau das, was auch auf der seriellen Schnittstelle über USB ausgespuckt wird. Da landen alle "printfs". Und wenn du es wie angedeutet mit grep filterst, siehst du natürlich nur die Zeilen, die deinem Filter entsprechen. Ich hatte gedacht du würdest mit dem websocat auf dem Websocket für die Live-Daten horchen und die Konsole live lesen im Browser oder am seriellen Port. Die Live-Daten siehst du an Im Livedata Websocket siehst du dann auch schön, dass da immer mal wieder Teil-Daten kommen, und alle zehn Sekunden kommt "alles", oder jedenfalls "mehr". Und ich sehe, dass es noch einen Fehler gibt, der aber nichts hiermit zu tun hat, dennoch danke dass ich den jetzt sehe, weil ich websocat einmal auf das livedata angesetzt habe 👍 So. Jedenfalls sollte im Live-View nicht öfter als in der Konsole ein neuer Wert auftauchen. Das ist nicht richtig. Und ich hab dafür leider keine vernünftige Erklärung. Schalte mal Verbose Logging möglichst überall aus und beobachte dann nochmal. Vielleicht gehen Nachrichten den PowerMeters verloren weil irgendein Puffer voll ist. Kommen die Ausgaben vom PowerMeter in einem sehr regelmäßigen Abstand? Das sollten sie nämlich. Kannst du einen Weg finden, die Angaben mit Zeitstempel zu versehen, sodass man vielleicht aus der zeitlichen Abfolge etwas ableiten kann? |
|
Danke für die ausführliche Erklärung — denke, jetzt hab’ ich’s kapiert, wo das Missverständnis lag. Zunächst dachte ich, mich laust der Affe, keine zusätzlichen Powermeter-Werte mehr in den Live-Daten. Jetzt frage ich mich: Stört der Wechselrichter irgendwie physikalisch die Datenübertragung vom Powermeter oder macht die Software etwas unerwartetes? |
|
Sehr gute Arbeit.
Warum wird laut Konsole frisch der Wert 294W gelesen, aber dann 2443W in die Live-Daten geschrieben? Hm, ist vielleicht nur ein Timing-Problem, scheinbar wird nach jeder Ausgabe auf der Konsole anschließend noch einmal der alte Power-Meter-Wert im Live-Data ausgespuckt, aber dann kurz darauf der neue. Das hier sieht mir ehrlich gesagt auch nicht sooo falsch aus. Der Abstand zwischen den Ausgaben auf der Konsole ist weiterhin 14 Sekunden. Aber dass dazwischen weitere, neue Werte kommen ist absolut merkwürdig. Warte mal... Ich such mal einen anderen Aufrufer von Äh... Sowohl der PowerLimiter, als auch der HuaweiCan Controller, als auch die PowerMeter Implementierung selbst rufen Puh. Also das ist super unschön. Aber es ist kein Fehler. Es sollte natürlich so sein, dass jeder PowerMeter (außer der über MQTT, der ja Event-Driven ist) ein einstellbares Polling-Intervall bekommt, und dass der PowerMeter genau in diesem Zeitraster Daten abholt. Und jeder, der dann nach der aktuellen Leistung am PowerMeter fragt, erhält dann die zwischengespeicherten Werte. Und dann würdest du auch die Daten so vorfinden, wie du es zurecht erwartest, nämlich in den Live-Daten wird bestenfalls ein PowerMeter Wert wiederholt, aber es wird kein neuer abgeholt. Ich änder den Titel dieses Issue nochmal, um wiederzugeben, was tatsächlich zu tun ist. Ich danke die nochmal für diese wunderbare Datenaufbereitung! Ist das Thema wird dich hinreichend erklärt und du kannst OpenDTU-OnBattery uneingeschränkt nutzen, oder führt das zu häufige Abfragen der PowerMeter Werte auch zu einem Problem? |
schlimmchen
changed the title
|
Danke sehr für Analyse und Erklärungen! Nein, bisher habe ich keine Probleme im Zusammenhang mit den Powermeter-Werten gefunden. Bzgl. Polling-Frequenz: ist die momentan, aus Sicht des DPL, identisch mit den genannten 1/10s? |
du willst den WR nicht häufig stellen. Dafür gibt es die hystwrese, dass er eben nicht jeden Watt unterschied nachregeln muss. Du willst auf größere leistungsänderungen nur zeitnah reagieren. Und eben nicht erst nach 5 bis 10 Sekunden, wenn denn der neue Wert von powermerrrr da ist. Ich befürworte ein gezieltes Abfragen des powermeters in jedem powerlimiter Durchgang (so es denn möglich ist), um schnell reagieren zu können |
|
Ah, ok, auf möglichst schnelles Reagieren auf größere Änderungen kommt es an - danke. Mir ist aufgefallen, dass seit ca. zwei Tagen (?) (seit der Installation von b101ce4 (?)) der Zähler 'Inverter Total Yield Day' in den Live -Daten nicht mehr nachts zurückgesetzt wird. |
|
Also mit dem genannten Commit hat es sicherlich nichts zu tun. Kann ich mir jedenfalls gerade nicht vorstellen. Ich nehme an du hast ein System mit Batterie, sonst würde der Inverter nachts in jedem Fall neu starten müssen, weil keine Energie da ist für die Logik im Inverter. Hast du den nächtlichen Inverter-Neustart aktiviert? Meiner wurde um 1 Uhr wie geplant neu gestartet. |
Stimmt. Natürlich habe ich zeitgleich noch an anderen Stellen geändert: Bei leerem Akku deaktiviere ich jetzt den DPL, um dann den Inverter stoppen zu können (jeweils per API), weil mir die '0.0W' bei 'Inverter Total Power' besser gefallen als die ca. 20W, die dort ohne gestoppten Inverter angezeigt werden (Vorher hatte ich nur das 'upper power limit' des DPL auf '0' gesetzt. Was macht der DPL eigentlich, wenn 'upper power limit' < 'lower power limit' ist? Kommen dann 'upper' oder 'lower' raus?). Da der Inverter-Restart wohl vom DPL getriggert wird, kann das nur funktionieren, wenn letzterer aktiviert ist (?). Ist es aber möglicherweise bzgl. des Stromverbrauchs des Inverters irrelevant, ob der gestoppt ist, oder vom DPL als Zielwert '0W' vorgegeben bekommt? Mit dem kosmetischen Unterschied, dass im ersten Fall halt '0W' angezeigt wird, weil ausgeschaltet (aber die DC-Seite ist ja nach wie vor verbunden)? Anscheinend ist es aktuell so (mit früheren Firmware-Ständen schien mir das nicht so (?)), dass ein 'Disable' des DPL schon ausreicht, um die in den Live-Daten angezeigte 'Inverter Total Power' auf '0W' zu bringen (und ein Stop des Inverters nicht mehr notwendig ist)? (Sollte ich diese Fragen ggf. in ein anderes Thema umziehen, da dies mit dem Powermeter-Thema, bzw. Live-Data-Aktualisierung nichts mehr zu tun hat?) |
Hierzu fällt mir noch etwas ein: Hintergrund ist: |
Dann wird der Inverter auch nicht neu gestartet.
Check ich nicht. Der DPL macht doch den Inverter aus, wenn die Batterie leer ist, das ist doch eine seine Hauptaufgaben?! Und wenn der Inverter im Standby ist, ist auch Inverter Total Power 0W (bei mir).
Vorstellbar, aber ich frage mich, ob wir das einfach umstellen können. Kann den jeder SDM PowerMeter liefern, diesen Wert? Falls ja, ist es natürlich Unfug, dass der SDM-PowerMeter die Phasen einzeln abholt und addiert. Das ließe sich einigermaßen leicht umsetzen, nachdem die ganze PowerMeter-Implementierung einem Refactor unterzogen wurde. Das ist zwar nötig, aber gerade nicht hoch priorisiert, jedenfalls nicht bei mir. |
ist es nicht in manchen Ländern Pflicht, eine echte Nulleinspeisung zu machen? Und haben wir nicht auch daher die Möglichkeit, einzelne Phasen abzufragen? Sollte man den SDM Code überarbeiten, vielleicht kann man dann direkt die Option vorhalten, die Summe abzufragen oder aber auch die Phasen einzeln. Bisher kann der DPL zwar nicht damit umgehen (außer, wie manche User es machen, man nutzt 3 opendtu mit je einem hoymiles auf einer Phase), aber künftig wäre es ja vorstellbar. 3 hoymiles und jeder bedient eine Phase. |
|
In dem von dir skizzierten Szenario nutzt man "SDM1 Phase" und da gibt es das Problem ja nicht (dass die Summe der Phasen nicht wirklich den aktuellen Bezug darstellt, weil man sie nacheinander abfragt). |
the SDM power meter (among others) writes the power consumption of three phases in multiple steps. this change helps to prevent getTotalPower() reading intermediate values, e.g., reading a new value for phase 1 but old values for phase 2 and 3 since phase 2 is currently read. cache the values, and write them all at once, protected by a mutex, later. closes #732.
Ja, genau, bei mir auch. Mein Anwendungsfall ist halt folgender:
Hier habe ich mich getäuscht, ein 'Disable' des DPL hat wohl schon immer gereicht, um 'Inverter Total Power' auf 0W zu bringen.
In
Gar kein Problem. Ich wollte diese Möglichkeit für das SDM630 nur mal festhalten… |
schlimmchen
changed the title
Mach dafür mal einen Feature-Request auf. Ach, ich sehe ich habe dieses Ticket geschlossen als ich #749 ge-merge't habe. Meh. Das kommt davon, wenn man drei Themen in einem Issue abarbeitet. Wir hätten neue aufmachen sollen, als wir jeweils den Fokus gewechselt haben. Ich lass dieses hier geschlossen und wir machen ein neues für das verbliebene Thema. |
|
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?
Grid Power -Wert wird nur bei manuellem Reload aktualisiert.
To Reproduce Bug
Live-Data
Expected Behavior
Aktualisierung des Grid-Power-Werts alle 15s, so wie in der Console.
Install Method
Self-Compiled
What git-hash/version of OpenDTU?
2024.03.07
Relevant log/trace output
No response
Anything else?
Verwendetes Powermeter: SDM630 via RS485-Adapter.
Möglicherweise wird auch der MPPT Total Power-Wert nicht aktualisiert.
Die Inverter-Werte werden jetzt zuverlässig aktualisiert (im Gegensatz zum vorigen Release).
The text was updated successfully, but these errors were encountered: