[Tester Gewünscht] PowerMeter Refactoring #1077
Conversation
it is important to separate the capabilities of each power meter provider into their own class/source file, as the providers work fundamentally different and their implementations must not be intermangled, which made maintenance and improvements a nightmare in the past.
the enum values did not change, but their name (only relevant in the code) are now more expressive.
the current power meter provider will be de-initialized, and a new instance will be initialized with the new settings.
instead of iterating a map with subscriptions, we now bind the target variable to the callback, which is executed once a message is arrived. this way, the target variable is already linked to the respective topic when the callback is executed. lock the mutex when writing the variable, as the MQTT callback is executed in a different context (MQTT task) than the main loop task, which otherwise accesses the variables.
the timestamp is potentially updated from a different thread, e.g., MQTT task, than the main loop, which typically reads that timestamp.
"powertotal" is always published and it is published by the base class directly. other values are still published by the derived classes, but use a base class method, which takes care that a common base topic is used in particular.
this setting was not used. the baud rate for the SDM is set to 9600 in the source code. until the baud rate being customizable is actually required by somebody, we remove the setting altogether.
make sure the wifiClient used by the httpClient lives longer than the httpClient, as it accesses the pointer to the wifiClient in its destructor.
this new class handles SML data. it uses the SML lib to decode values and manages those. this de-duplicates code as the class is applicable to all power meters that collect SML data.
avoid additional conversions and avoid double for the fact that calculations on type double are implemented in software, whereas float is handled in hardware on ESP32.
the parameters to peform an HTTP request by the HTTP(S)+JSON power meter have been generalized by introducing a new config struct. this is now used for all values which the HTTP(S)+JSON power meter can retrieve, and also used by the HTTP+SML power meter implementation. we anticipate that other feature will use this config as well. generalizing also allows to share serialization and deserialization methods in the configuration handler and the web API handler, leading to de-duplication of code and reduced flash memory usage. a new web UI component is implemented to manage a set of HTTP request settings.
the extractUrlComponents method did extract username and password from the URL and encoded it for basic authentication. however, the respective result string was never used. we only perform basic authentication if the auth type is "basic" and if username and password were supplied through the respective inputs.
this new class uses the newly introduced HttpRequestConfig and performs HTTP requests using this config. it will be reused for other power meters (SML over HTTP(S)) and may be reused by other features in the future (battery provider, solar power provider, etc.).
apply all config values from the webfrontend, then perform one polling cycle. display values seperately in the result, and show the resulting value as well.
all power meter providers now have their own configuration struct defined. a respective method to serialize and deserialize the provider config is implemented for each provider.
instead of reading the main config's powermeter struct(s), the individual power meters now are instanciated using a copy of their respective config. this allows to instanciate different power meters with different configs. as a first step, this simplifies instanciating power meters for test purposes.
this change makes the respective setting accessible from the web UI.
the MQTT power meter can now process the messages published at the respective topics as JSON and extract a power value using a JSON path (same as in HTTP+JSON power meter). additionally, selecting a unit for the power value as well as an option to invert the value's sign was added as well, similar to the HTTPS+JSON power meter.
avoid problems with chunked transfer encoding when using the client's stream to parse a JSON document. fixes the HTTP+JSON power meter to work with shelly and hichi (Tasmota).
|
Es geht mir darum das der neue DPL mehr schwankt...: bei den 100W schafft er es gut, aber den 140W schwankt er wie sau. Bei der Nulleinspeisung regelt er sich dort zu Tode und findet nicht den Ruhepunkt. Es gibt immer eine Sprungantwort und ein Überschwingen, er findet nie seinen eingeschwungenen Zustand. Schau mal bei 9:26 Uhr: (Ziel ist -5W mit 20W Hysterese) Stromverbrauch geht hoch, Regelung geht entgegen, nach unten... |
|
@schlimmchen ich möchte auf von esp32 DEV Board auf OpenDTU Fusion Board umsteigen und dortigen RS485 Chip für SDM Zähler nutzen. Dort muss man aber DE/RE Pins getrennt angegeben, was die SDM Library nicht kann. Auch kann SDM Lib (noch nicht released) mehrere Register auf einmal abfragen. Man könnte so Spannungen und Leistungen in einer Abfrage holen. Wollen wir das hier auch? es wäre klitzekleines Umbau nötig: reaper7/SDM_Energy_Meter#82 Ich könnte dann SDM Tests übernehmen, ich habe SDM72, SMD630 und SDM630MCT zur Hand (Hitchi SML auch wenn es sein muss) Und als ich damals SDM eingebaut habe (sorry für die schlechte Implementierung) habe ich geplant die Bitrate auch änderbar zu machen. Manchmal ist es eben nicht 9600... aber eher selten. Nicht mehr gewünscht? |
|
Hier mal meine Veränderungen mit der neuen Version des DPL. Letzte Release Version mit NRF24 ohne Antenne: Neue DPL Version (installiert am 02.07.2024) mit NRF24 ohne Antenne: Neue DPL Version (installiert am 02.07.2024) mit NRF24 mit Antenne: Man sieht schon eine Veränderung. Wir sind mit der neuen Version viel dichter an der gewünschten Nulleinspeisung dran! Der Empfang mit NRF24 mit Antenne ist leider laut Aktualisierung im Live View sowie laut Log schlechter geworden(middle missing, Retransmit timeout), jedoch sieht der Netzbezug besser aus. Ich habe gestern nochmal bei Makershop ein NRF24 mi Antenne, sowie ein NRF Breakout Board bestellt, ich bin gesapnnt! Der HM-1500 ist nämlich regelmäßig auf rot..
|
|
@DerHavey1994 |
Kann ich nicht bestätigen. meinen HMS-2000 (~10m weg durch 2 Außenwände) kann ich mit dem PR hier sauber aller 2s abfragen. Aber ja, HM und HMS können da unterschiedlich reagieren, allein schon weil sie unterschiedliche Chips und Frequenzen verwenden. 😄 |
@Adminius Guter Punkt. Lokal ändern und einen PR gegen das Original machen, schlage ich vor. Das hat vermutlich wenig Aussichten auf Erfolg, weil das ein Breaking Change ist. Die SDM lib sollte DE und RE getrennt akzeptieren, und Leute, die nur einen DERE pin haben, sollen den sowohl für DE als auch RE an SDM lib spezifizieren. Lass uns das bitte in einem neuen Issue behandeln. Magst du einen passenden Request aufmachen?
Finde ich ehrlich gesagt nicht spannend. Das betrifft doch nur die API zur SDM Lib, oder? Diese wird doch dann trotzdem jeden Wert einzeln abfragen? Da mit diesem PR das Polling in einem eigenen Thread läuft, sehe ich da keinen Vorteil. Außerdem ist das definitiv keine "klizekleine Anderung"^^
Jo, umgesetzt war aber eine Einstellung in der Web UI, die nichts tat. Also hab ich sie weggehauen. Und nachdem ich eingesehen habe, dass 9600 schon das Maximum zu sein scheint bei dem SDM Geräten, dachte ich wir nageln die User darauf fest die SDM auf 9600 Baud einzustellen, bis sich jemand beschwert. @Adminius Danke, dass du demnächst einen SDM mit 3 Phasen testen kannst. Ich wollte mir so einen nicht anschaffen, das ist dann doch preislich signifikant...
@knopers1 Ich frage mit 1s Intervall ab und habe keine Probleme. Und ich weiß (hab ich das in diesem PR schon erwähnt?), dass AhoyDTU die Pausen zwischen den Abfragen der WR nochmal verkürzt hat (auf Null). Es gibt nur noch eine Pause zwischen kompletten Runden (1 Runde = Alle WR einmal abfragen).
@DerHavey1994 Danke für das positive Feedback. Bitte versteift euch nicht so auf den DPL. Der DPL wird durch diesen PR nicht ernsthaft berührt. Es können sich höchstens zeitliche Zusammenhänge verschoben haben. Ein "Der DPL regelt jetzt in die falsche Richtung" macht in diesem Kontext keinen Sinn. |
Meinst mit Original die SDM Lib-selbst? in der pin-mapping Datei gibt es dann aber 3 Optionen: entweder dere oder de + re (de +re gibt heute schon bei der Batterie)
Nein, du kannst beim SDM-Zähler bis zu 40 Werte auf einmal abfragen, musst dann Register von / bis angeben.
passt. |
|
@schlimmchen
hast du mal geprüft, wie lange die Übertragungen dauern? Meinst du, wir bewegen uns da im Rahmen? Ich hab noch immer die 1% dutycycle im Hinterkopf (: in meinem Logs sehe ich ja immer nur die Zeit zwischen Start der Abfrage und der „success“ Meldung. Das sind halt so 400ms und auch mal >1s. Aber das sind ja anfrage plus Antwort, ggf. mit retransmit. |
Das entspricht nicht der Zeit, in der das Medium belegt ist. Das Medium ist für sehr viel kürzere Zeit belegt. Und du hast recht: es ist off-topic 😉 |
|
@schlimmchen Guten Morgen! So etwas habe ich jetzt zum 1. mal gesehen. Davon ab kommt es bei MQTT manchmal bei mir vor, dass er im Log beim Abfragen des Wertes plötzlich anzeigt: New Value: 50.00 Total: Nan Ist mir aufgefallen, weil dann im Live View die Zeile vom Stromzähler komplett verschwindet.. aber ist ja logisch, da kein Wert berechnet werden kann |
MQTT fragt keine Werte ab. Devices senden (publish) Daten zum MQTT Broker. Andere devices lassen sich bestimmte Daten weiterleiten (subscribe). Die Daten werden aber nicht explizit abgefragt. Die Weiterleitung kann nur passieren, wenn der ursprüngliche Sender auch gesendet hat. Bist du dir sicher, dass deine Daten fehlerfrei gesendet werden? Überwache mal den Datenstrom bspw mit MQTT Explorer und gucke, ob nicht solch fehlerhafte Daten gesendet werden. |
|
Lauft nun seit Tagen ohne Probleme mit einem 'Hichi' mit Intervall von 1 Sekunde, DTU hab ich auf 2 Sekunden Intervall, werde heute aber auf 1 Sekunde umstellen und beobachten. |
|
Läuft bei mir ebenfalls ohne Probleme
Soll ich noch was testen? |
|
Bei mir kommt es in den letzten Tagen zu „Problemen“. Auch ich frage den Shelly sekündlich an und zuletzt häufen sich timeouts. Also eher kein Problem der Firmware (: im Gegenteil, sie fällt artig zurück auf die Grundlast (Solar only) und geht dann wieder hoch, wenn der Shelly wieder mitspielt. Also alles top 👍 |
@Adminius Magst du das machen (neuer Pull-Request)? Das ist eine sinnvolle Verbesserung.
Hier ging es darum mehrere Werte auf einmal abzufragen. Ja, das geht auch später mal, hat für mich keine Prio, auch weil die Kommunikation deutlich beschleunigt ist mit den Updates an der SDM Lib.
@DerHavey1994 Das ist natürlich Mist. Allerdings kann ich mir das nicht so recht erklären. Kannst du das bitte weiter beobachten? Wenn das tatsächlich immer wieder auftritt, dann öffne dazu bitte ein neues Issue. Dann müssen wir einmal nachdenken, wie das sein kann. @SW-Niko @AndreasBoehm @spcqike Danke fürs positive Feedback. Mir reicht das ehrlich gesagt, ich möchte diesen PR nun mergen. |
|
TIBBER TEST Habe es mit ESP32-S3-WROOM -1-N16R8 und dem HM1500 mit TIBBER getestet und läuft ganz wunderbar. Alles mit Standard Werten belassen. |
|
@JuergenCarstensen Danke! Die Anweisungen in der Wiki sind für dich auch stimmig? Magst du mal schauen? https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Power-Meter#tibber-pulse-via-tibber-bridge |
Sieht alles logisch aus, so wie es soll. Danke |
|
Hallo! |
|
This pull request 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. |
Deutsch weiter unten.
Highlights
Firmware
Latest PR-Build-Run
English Description
This pull request includes a fundamental overhaul of the PowerMeter implementation. This enables us to solve annoying and sometimes old problems and prepares for the integration of further new features, which would have been a burden in the old PowerMeter implementation.
Testers Wanted
I have tested a lot myself, even against purchased hardware or a "Hichi-Simulator", but surely I missed something. Please help test this adjustment in your environment. Unfortunately, due to the issue with the sketch partition becoming too small, this is not as easy as usual for ESP32 (non-S3) users.
Positive feedback is explicitly desired. A "no one complains" is unfortunately not informative.
Please do not complain if something breaks! If you are eager to test but unsure, let experienced users go first and wait for positive feedback.
All Users
Create a backup of
config.json! If you want to "go back" to a release firmware after testing without having to redo the PowerMeter settings, then you must backup theconfig.jsonbefore the update. When upgrading, the settings are interpreted in the old format and ported to the new format. However, a downgrade is not possible.The partition with the pin mapping and configuration remains intact, whether with an OTA update or when flashing the factory firmware with esptool. Exception: If you explicitly erase the flash memory, then the configuration will of course be lost.
ESP32-S3
I assume no one has an ESP32-S3 with only 4MB of flash memory. If so, please let me know. Please install the linked firmware via OTA. An update of the partition table is not yet necessary. But since I am fairly sure that the new partition layout is final for this family of devices, there is nothing against flashing the factory firmware via esptool. This will update the partition table to the new layout.
ESP32 (non-S3)
8 MB Flash or more
Install the
generic_esp32_8mbfactory firmware via esptool and a USB cable on a computer. An OTA update will fail with HTTP 500 error! Afterward (new factory firmware installed via esptool), you can install newer and also older firmware via OTA.4 MB Flash
Install the
generic_esp32_4mb_no_otafactory firmware via esptool and a USB cable on a computer. OTA updates are not possible afterward, although this is not yet disabled in the Web-UI. If you have installedgeneric_esp32_4mb_no_otaand attempt an OTA update, you will shoot yourself in the foot. If you want to install any other firmware, you must do so via esptool and USB cable, using the factory firmware.Tibber-Bridge Support
The settings used in firmware from PR #915 will not be carried over when upgrading to this or the next release firmware. Please reconfigure the PowerMeter if you have used this feature.
Deutsche Beschreibung
Dieser Pull-Request beinhaltet einen grundlegenden Umbau an der Implementierung des PowerMeter. Dieser ermöglicht es, lästige und teils alte Probleme auszuräumen und bereitet weitere neue Feature vor, deren Integration in die alte PowerMeter Implementierung eine Bürde gewesen wäre.
Tester Gewünscht
Vieles habe ich selbst getestet, auch gegen angeschaffte Hardware oder einen "Hichi-Simulator", aber bestimmt ist mir irgendetwas entgangen. Bitte helft mit, diese Anpassung zu testen in eurer Umgebung. Leider ist dies wegen der Problematik um die zu klein gewordene Sketch-Partition nicht so einfach wie gewohnt für ESP32 (non-S3) Nutzer.
Positive Rückmeldungen sind ausdrücklich erwünscht. Ein "niemand schimpft" ist leider nicht aussagekräftig.
Bitte nicht schimpfen, falls etwas kaputt geht! Falls du Lust hast zu testen aber unsicher bist, lass erfahrene Nutzer den Vortritt und warte positive Rückmeldungen ab.
Alle Nutzer
Backup der
config.jsonerstellen! Wenn du nach einem Test wieder "zurück" auf eine Release-Firmware möchtest ohne die PowerMeter-Einstellungen erneut machen zu müssen, dann musst du dieconfig.jsonvor dem Update sichern. Bei einem Upgrade werden die Einstellungen im alten Format interpretiert und portiert. Ein Downgrade ist aber nicht möglich.Die Partition mit dem Pin-Mapping und der Konfiguration bleibt erhalten, egal ob mit OTA-Update oder beim Flashen der Factory-Firmware mit esptool. Ausnahme: Wenn du den Flashspeicher ausdrücklich löschst, dann geht die Konfiguration natürlich verloren.
ESP32-S3
Ich nehme an, dass niemand einen ESP32-S3 mit nur 4MB Flashspeicher hat. Falls doch, bitte melde dich. Bitte installiere die jeweils verlinkte Firmware per OTA. Eine Aktualisierung der Partitionstabelle ist noch nicht nötig. Da ich mir aber einigermaßen sicher bin, dass das neue Paritionslayout für diese Gerätefamilie endgültig ist, spricht nichts dagegen, die Factory-Firmware per esptool zu flashen. Dabei wird dann die Partitionstabelle auf das neue Layout aktualisiert.
ESP32 (non-S3)
8 MB Flash oder mehr
Installiere die
generic_esp32_8mbFactory-Firmware per esptool und USB-Kabel am Rechner. Ein OTA-Update wird mit Fehler HTTP 500 fehlschlagen! Anschließend (neue Factory-Firmware per esptool installiert) kannst du per OTA neuere und auch ältere Firmware installieren.4 MB Flash
Installiere die
generic_esp32_4mb_no_otaFactory-Firmware per esptool und USB-Kabel am Rechner. OTA-Updates sind danach nicht mehr möglich, obwohl dies in der Web-UI noch nicht abgestellt ist. Wenn dugeneric_esp32_4mb_no_otainstalliert hast und ein OTA Update versuchst, wirst du dir ins Bein schießen. Wenn du irgendeine andere Firmware installieren möchtest, musst du das bitte per esptool und USB-Kabel machen, und zwar wird die Factory-Firmware benötigt.Tibber-Bridge-Support
Die Einstellungen, die in Firmware aus PR #915 werden bei einem Upgrade auf diese oder auf die nächste Release-Firmware nicht übernommen. Bitte stellt den PowerMeter neu ein, wenn ihr dieses Feature genutzt habt.
Testplan
Related/Closed Issues
All related issues can be found using the power meter refactoring label.
Issues that are closed by this PR: