first poc for power set via mqtt #109
Conversation
|
Der Ansatz ist, dass sich die Applikation auf eine topic subscribed z.B. "home/system_name/wr_id/powerset" und immer wenn dort eine Nachricht abgesetzt wird z.B. "400" im entsprechenden Inverter die Leistung entsprechend limitiert wird. Es wird dann ein Packet gesendet entsprechend der Funktion "UsartNrf3_Send_PackDevControl" (siehe auch: https://www.mikrocontroller.net/topic/525778#7134280 |
|
rein interessehalber: was würde passieren wenn ich z.b. bei einem HM-600 das neue Limit auf 700 setzen würde? |
|
Vermutung: Die Firmware der Umrichter hat die Leistungsgrenzen hinterlegt. Die Ansteuerung via "Funk" ist nur eine Schnittstelle und die Firmware prüft gegen die Version des Umrichters. Also es wird wohl nicht mehr Leistung "rauskommen". |
|
@aschiffler danke für die Implementierung des PowerLimit aus den Erfahrungen der UsartNrf3_Send_PackDevControl() Methode. Ich habe ein paar Bemerkungen in den Code Review gepackt, vor allem:
|
|
wie ist der pull Request zu sehen, soll ich ihn mergen? Habe leider aktuell wenig Zeit mich näher mit der Thematik auseinanderzusetzen. |
|
Hi, ich werde den Request schließen. Es war wohl eine etwas überstürtze Aktion meinerseits. Ich wollte damit einen dokumentierten Sartpunkt setzen wie ein Seting bzw. eine Eingabe an die Umrichter in der Architektur verankert werden könnte. Ich bin hier weiter dran das umzusetzten auch unter Berücksichtigung der gelisteten Punkte von @stefan123t
|
|
@aschiffler Danke für den Hinweis dass die Limitierung nach einem Hard-Reset (über Nacht) wieder auf unlimited steht. Das war mW bisher von @DanielR92 und @De-Ichirou noch nicht beobachtet worden. Wir hatten nur den Soft-Reset per Device Control Command versucht. |
|
@aschiffler für das MQTT Topic kannst Du vielleicht auch mal sehen wie die anderen das in #111 für die Ablage des Last Will Testament (LWT) umsetzen. Sollte mE ja unterhalb der WR Struktur sein. |
|
Das werde ich heute mal testen, zur Not 24H mal im Leerlauf probieren. Die Sache mit PF ist mir auch aufgefallen, das muss ich mir nochmal genauer anschauen. Bin heute gegen 16Uhr dann aktiv dran. =) |
|
@aschiffler Vielen Dank erst mal für das Implementieren der Power Limit Funktion! |
|
@homeautomation2022 Hinsichtlich der Regelung ist es m.E. so, dass der wir mittels dem implementieren Befehl nur den Wirkleistungssollwert sezten. Der Leistungsfaktor hat -- per Default -- den Sollwert 1. Das Bedeutet -- so meine Beobachtung am Leisungsmessgerät -- dass die Regelung / Wirkleistungs-Limitierung nur dann den Sollwert ereicht wenn auch die zweite Regelsollgröße (PF) im "Zielkoridor" ist. Sprich man muss innerhalb des WR genug Scheinleistung haben damit der Hochsetzsteller funktioniert. Bei mir (HM1500) funktioniert eine Wirkleistungslimitierung mit PF_soll=1 nur wenn eine Gesamt DC-Leistung von > 200 W anliegt. |
|
@homeautomation2022 dass die beiden Eingänge des Wechselrichters gemeinsame + und - Potentiale haben durch den Anschluß der Batterie wird nicht jedem sofort klar. M.E. führt das zu einem Regelungsproblem das zwangsläufig (stochastisch) auseinander laufen muss. |
|
Habe ja inzwischen (wie im Discord geschrieben) zumindest das Problem umgangen, wenn auch immer noch nicht richtig, in dem ich exakt gleich lange Plus und Minus Kabel verwende, jetzt ist der Massestrom, in dem auch der intern Messshunt sitzt auf beiden Seiten fast annähernd gleich, allerdings der Plus Strom nicht, das bekomme ich nicht hin, es ist eine Differenz von ca. 4A zwischen Kanal 1 und 2(desto mehr Leistung, umso geringer die Differenz! bei 3A kommt z.B. alles über nur einen Plus-Anschluss, bei 9A kommt immerhin 7A vom anderen Plus-Anschluss), aber er muss die intern verbinden im Betrieb! Ich habe ja auch beobachten können wie er die zyklisch für 45s verbindet und dann 15s lang trennt, wenn man nur eine Masse anschließt und beide Plus an eine Quelle und den Strom jeweils einzeln misst. Sinn dahinter ist noch unbekannt, eigentlich sollten beide Kanäle komplett unabhängig voneinander arbeiten. Die Massen sind intern permanent verbunden, kann man auch messen im abgeklemmten Zustand. Die Stelle konnte ich aber anhand der Platinen Fotos nicht eindeutig finden. @aschiffler Danke auch für die Info, dass deiner ebenfalls das Limit vergisst, wenn die Elkos entladen sind. Es scheint hier wohl Unterschiede zu geben. |
| @@ -166,6 +166,28 @@ class HmRadio { | |||
| return mTxChLst[mTxChIdx]; | |||
| }*/ | |||
|
|
|||
| void sendControlPacket(uint64_t invId, uint16_t data) { | |||
There was a problem hiding this comment.
The function name is not that optimal. We will have more ControlPackages in the future (ON/OFF/RESET/RESTART). This name should be dedicated for power limiting. In my fork i implemented already a function call for these: https://github.com/a-marcel/ahoy/blob/main/tools/esp8266/hmRadio.h#L221
There was a problem hiding this comment.
@a-marcel Thanks for the input. My intention was /is to be as close to the implementation as it is done on the original DTU. There is that kind of function call but of course, extended with the parameter 'subcmd' aka: on/off/reset/activepowercontro/reactivepowercontrol/powerfactor which all use the same main cmd "devcontrol"
But as stated before this merge request is closed due to missing code quality / functionality
No description provided.