[Summary] Hoymiles HMS / Firmware 1.1.12 & 2.0.4 / 'ActivePowerControl'-Kommando aka. 'Limits'

[OutdoorRob]

Inhalt

• Übersicht
• Erkenntnisse
• Analyse des Verhaltens WR-Firmware 1.0.x vs. 2.0.4 (relative Limits)
• Lösung: Ideen / Vorschläge
• weiterführende Informationen / Sammlung von Links:

Übersicht

Dieser Issue behandelt die Erkenntnisse zum abweichenden Verhalten der Hoymiles HMS-Wechselrichter mit 'Power Distribution Logic' / ab Firmware 1.1.12 bzw. 2.0.4 bezüglich des ActivePowerControl-Kommandos.

Die damit verbundene, abweichende SystemConfigPara-Antwort ('Typ' 0x0003) wird in einem separaten Issue behandelt.

Erkenntnisse:

• Die Umsetzung des ActivePowerControl-Kommando wurde ursprünglich auf Basis der HM-Serie zurückentwickelt.
• Es funktionierte bis zur WR-Firmware 1.0.x auch bei der HMS-Serie identisch.
• Seit WR-Firmware 1.1.12 bzw. 2.0.4 gibt es damit aber Abweichungen im Verhalten der WR (keine persistenten Limits mehr möglich / abweichende SystemConfigPara-Antwort).
• Die notwendige Modifikation des ActivePowerControl-Kommando bzw. des damit gesendeten PowerLimitControlType zum Setzen eines relativen, persistenten Limits ist bekannt (0x0003 statt 0x0101). Die Werte für die anderen drei Kombinationen für nicht-persistente und absolute Limits nicht.
• Wichtig dabei ist:
  • Dieses modifizierte ActivePowerControl-Kommando wird von der Hoymiles DTU-S-Serie für HMS-Wechselrichter schon immer so gesendet (Trace von Februar 2023 vorhanden / Danke an Lukas) und funktioniert deshalb auch korrekt mit den WR-Firmware Versionen 1.0.x (siehe letzte Spalte in Analyse des Verhaltens)
  • Es wurde bisher nur noch nie beachtet, da die für die HM-Serie verwendeten Kommandos bis jetzt auch für die HMS-Serie funktionierten.
• Das Problem ist also:
  • Die Verwendung von eigentlich 'falschen' ActivePowerControl-Kommandos für die HMS-Serie.
  • Das geänderte Verhalten der WR, welches sich aber erst mit Hoymiles Firmware-Versionen ab 1.1.12 (bzw. 2.0.4) bemerkbar macht.

Analyse des Verhaltens WR-Firmware 1.0.27 vs. 2.0.4

relative Limits / Vergleich PowerLimitControlType 'HM' vs. 'HMS'

	ActivePowerControl-Command (aka Limit)
Firmware	rel. temp. 'HM' (0x0001)	rel. pers. 'HM' (0x0101)	rel. pers. 'HMS' (0x0003)
1.0.27	✅ - Power output is adjusted to limit. - Limit is not persistent. - SystemConfigPara response contains the actual limit.	✅ - Power output is adjusted to limit. - Limit is persistent after restart / power cycle. - SystemConfigPara response contains the actual limit.	✅ - Power output is adjusted to limit. - Limit is persistent after restart / power cycle. - SystemConfigPara response contains the actual limit.
2.0.4	✅ - Power output is adjusted to limit. - Limit is not persistent. ❌ - SystemConfigPara response does NOT contain the actual limit.	✅ - Power output is adjusted to limit. ❌ - Limit is not persistent. - SystemConfigPara response does NOT contain the actual limit.	✅ - Power output is adjusted to limit. - Limit is persistent after restart / power cycle. - SystemConfigPara response (type 0x0003) does contain the actual limit.

---

Vergleich PowerLimitControlType 'HMS' vs. Firmware

	ActivePowerControl-Command (aka Limit)
Firmware	abs. temp. (0x00)	rel. temp. (0x01)	abs. pers. (0x02)	rel. pers. (0x03)
1.0.27	✅ Power output ✅ Limit temp. ✅ SystemConfigPara	✅ Power output ✅ Limit temp. ✅ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara
1.1.12	✅Power output ✅ Limit temp. ✅ SystemConfigPara	✅Power output ✅ Limit temp. ✅ SystemConfigPara	❓Power output ❓ Limit pers. ❓ SystemConfigPara	✅Power output ✅ Limit pers. ✅ SystemConfigPara
2.0.4	✅ Power output ✅ Limit temp. ❌ SystemConfigPara	✅ Power output ✅ Limit temp. ❌ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara

Lösung: Ideen / Vorschläge

• Ermittlung der noch unbekannten ActivePowerControl-Kommandos für die nicht-persistenten und absoluten Limits.
  • Die Hoymiles-Cloud erlaubt nur das direkte Senden des relativen, persistenten Limits.
  • Für die Analyse der anderen Limits könnte die Hoymiles Zero-Export-Funktion geeignet sein. Zumindest die nicht-persistenten Limits sollten dort verwendet werden.
• Die Kommandos für die relativen Limits (0x01 und 0x03) der HMS-Serie konnten per Hoymiles DTU-Pro-S + Modbus ermittelt / bestätigt werden (für Details siehe diesen Kommentar).
• Die Kommandos für die absoluten Limits der HMS-Serie wurden 'geraten' und durch Tests verifiziert. Das Bit für die Persistenz ist im Gegensatz zur HM-Serie (dort niederwertigstes Bit im zweiten Byte) jetzt im zweiten Bit des ersten Byte zu finden.

  typedef enum {
      AbsolutNonPersistent = 0x0000,
      RelativNonPersistent = 0x0001,
      AbsolutPersistent = 0x0002,       // 0b10 statt 0x0100
      RelativPersistent = 0x0003        // 0b11 statt 0x0101
  } PowerLimitControlType;

• Der einzige Unterschied im Verhalten der Hoymiles Firmware 1.0.27 vs. 2.0.4 zeigt sich jetzt noch darin, dass die temporären / nicht persistenten Limits nicht mehr in der SystemParaConfig-Response 'gespiegelt' werden. Ob das ein Bug oder bewusstes Feature seitens Hoymiles ist, muss noch herausgefunden werden.
• Es muss beim Senden des ActivePowerControl-Kommandos dann entsprechend der Wechselrichterserie (HM / HMS) unterschieden werden.

weiterführende Informationen / Sammlung von Links:

Woher stammen die Werte für den PowerLimitControlType, welche mit dem ActivePowerControl-Kommando gesendet werden?

• Die Werte stammen aus dem Quellcode einer DTU-Pro (ohne S) und Reverse Engineering + Verifizierung mit Wechselrichtern der HM-Serie

  • Leistungsreduzierung HM300 #35
  • Leistungsreduzierung HM300 #35 (comment)
  • Leistungsreduzierung HM300 #35 (comment)
  • https://discord.com/channels/984173303147155506/992502836304822323/1009198596635230238
  • https://discord.com/channels/984173303147155506/992502836304822323/1019117274747125820 (und folgende Nachrichten)

• Die Werte funktionierten nach wie vor auch bei HMS / HMT Wechselrichtern mit Firmware bis 1.0.x

  • ab Firmware 1.1.12 wurde das persistente Limit nicht mehr übernommen (Link)
  • darauf hin wurde ein Bugix erstellt (Link)
  • bei diesem waren aber alle Limits persistent (Link)
  • Das dieser Bugfix nicht wie erwartet funktioniert ist aus meiner Sicht erklärbar.
    • Es wurden auf Basis eines Hoymiles DTU-Logs des relativen, persistenten Limits alle anderen Varianten des modifizierten ActivePowerControl-Kommandos abgeleitet.

Liste der damaligen Hauptakteure (to be continued)

• Ichirou / Modbus Energy-Meter
• lumapu / damalige Logs
• klahus1

[tbnobody]

Danke für diese Zusammenfassung. Nur damit ich das richtig verstanden habe. Bei HMS (und HMT?) Geräten sind die Werte anders (HM bleibt wie gehabt).

Das hier:

typedef enum { // ToDo: to be verified by field tests
    AbsolutNonPersistent = 0x0000, // 0
    RelativNonPersistent = 0x0001, // 1
    AbsolutPersistent = 0x0100, // 256
    RelativPersistent = 0x0101 // 257
} PowerLimitControlType;

wird zu dem hier:

typedef enum { // ToDo: to be verified by field tests
    AbsolutNonPersistent = 0x0000,
    RelativNonPersistent = 0x0001,
    AbsolutPersistent = 0x0100,
    RelativPersistent = 0x0003
} PowerLimitControlType;

Wenn man das Limit persistent setzt, kann es mit dem bestehenden SystemConfigParaCommand ausgelesen werden. (Die entsprechenden Limits befinden sich an den gleichen Byte Positionen)
Das setzen vom temporären relativen Limit funkioniert wie gehabt. Das Auslesen vom temporären relativen Limit funktioniert nicht?

Generell wird dass zur Folge haben das die WebAPI zum setzten leicht umgebaut werden muss. Hier wird aktuell der "rohe" Wert übergeben. Das ist unschön und verlangt vom Benutzer den Wert zu kennen. (Die Implementierung war damals schon nicht schön).

[OutdoorRob]

Kleines Update / weitere Analyse läuft noch

• Hoymiles DTU-Pro-S fürs Logging verdrahtet + Modbus läuft

• temporäres Limit per Modbus (Register 0xD001) auf 50% gesetzt

  51 A00B0FA2 A00B0FA2 81 0B00 01F4 0001 AE80 01
  D1 A00B0FA2 74438799 81 0000 0B00 1407 67
  

  • Bestätigt den bisher ebenfalls verwendeten PowerControlType 0x0001 für das nicht-persistente Limit
  • Was das Rücklesen dieses Limits über die SystemParaConfig-Response bei den neuen WR-Firmware-Versionen angeht müsste man mal abwarten, ob Hoymiles dort vllt. bald nachbessert und es sich dann wieder verhält wie bisher. Ich habe das Gefühl, die haben große Mühe Ihre Firmwaren fehlerfrei zu bekommen. Die DTU stürzt z.B. regelmäßig bei ModbusTCP Zugriffen ab (Stand Februar 2024 / Version 0.2.22). Auch mit der neusten Version 0.6.5, welche ich jetzt bei mir drauf habe, konnte ich dieses Verhalten noch beobachten.

• persistentes Limit per Modus (Register 0xD002) auf 10 % gesetzt

  51 A00B0FA2 A00B0FA2 81 0B00 0064 0003 BE00 02
  D1 A00B0FA2 74438799 81 0000 0B00 1407 67
  

  • Bestätigt den neuen PowerControlType 0x0003 für das persistente Limit

• Dokumentation der Modbus-Register enthält keine Register für das Setzen von absoluten Werten (muss aber nicht heißen, dass es nicht doch über Funk geht).

• Hier muss mit der OpenDTU probiert werden, wie der WR mit der Firmware 2.0.4 auf absolute Limits reagiert.

• Eine Theorie zu den Werten für die HMS / HMT Serie, die ich mal testen möchte, sieht wie folgt aus:

  typedef enum {
      AbsolutNonPersistent = 0x0000, --> to be tested
      RelativNonPersistent = 0x0001,
      AbsolutPersistent = 0x0002, --> to be tested
      RelativPersistent = 0x0003
  } PowerLimitControlType;

Kann leider erst Ende nächster Woche weitermachen - bin bis dahin unterwegs.

[stefan123t]

@OutdoorRob danke für das planvolle Vorgehen und setzen der Limits per ModBus Register und die Verkabelung Deiner DTU Pro S zum mitloggen der Commands.

So kommen wir glaube ich schneller zum Ziel als wenn wir die Commands per S-Miles Cloud anstoßen, die Cloud Software scheint ja nicht alle Optionen zu implementieren.

[OutdoorRob]

Update + Zusammenfassung: Setzen der absoluten Limits für HMS-Serie

• Die Kommandos für die relativen Limits (0x01 und 0x03) der HMS-Serie konnten per Hoymiles DTU-Pro-S + Modbus ermittelt / bestätigt werden (für Details siehe diesen Kommentar).

• Die Kommandos für die absoluten Limits der HMS-Serie wurden 'geraten' und durch Tests verifiziert. Dafür wurde eine OpenDTU-Testversion mit der folgenden Struktur erstellt und das entsprechende ActivePowerControl-Kommando per WebAPI getriggert. Das Bit für die Persistenz ist im Gegensatz zur HM-Serie (dort niederwertigstes Bit im zweiten Byte) jetzt im zweiten Bit des ersten Byte zu finden.

  typedef enum {
      AbsolutNonPersistent = 0x0000,
      RelativNonPersistent = 0x0001,
      AbsolutPersistent = 0x0002,       // 0b10 statt 0x0100
      RelativPersistent = 0x0003        // 0b11 statt 0x0101
  } PowerLimitControlType;

• Zusammenfassend entsteht damit folgende Tabelle für das Verhalten des PowerLimitControlType der HMS-Serie für die Hoymiles Firmwareversionen 1.0.27 vs. 2.0.4 (jeweils getestet mit einem HMS-1600-4T)

  	ActivePowerControl-Command (aka Limit)
  Firmware	abs. temp. (0x00)	rel. temp. (0x01)	abs. pers. (0x02)	rel. pers. (0x03)
  1.0.27	✅ Power output ✅ Limit temp. ✅ SystemConfigPara	✅ Power output ✅ Limit temp. ✅ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara
  1.1.12	✅Power output ✅ Limit temp. ✅ SystemConfigPara	✅Power output ✅ Limit temp. ✅ SystemConfigPara	❓Power output ❓ Limit pers. ❓ SystemConfigPara	✅Power output ✅ Limit pers. ✅ SystemConfigPara
  2.0.4	✅ Power output ✅ Limit temp. ❌ SystemConfigPara	✅ Power output ✅ Limit temp. ❌ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara	✅ Power output ✅ Limit pers. ✅ SystemConfigPara

• Der einzige Unterschied zeigt sich jetzt noch darin, dass die temporären / nicht persistenten Limits nicht mehr in der SystemParaConfig-Response 'gespiegelt' werden. Ob das ein Bug oder bewusstes Feature seitens Hoymiles ist, muss noch herausgefunden werden.

Update 2025-08-22: added version 1.1.12 with logs from Dirk-Ahoy

[stefan123t]

@OutdoorRob thanks for the concise overview and lots of testing and verification involved in this!

Regarding the SystemConfigPara I do recall that we have seen the response (version 0x0003 if I recall right) being somewhat more explicit (having multiple response packets and breaking our previous buffer size) for the latter version 2.0.4.
Maybe the temp Limit value is simply somewhere else, where we haven't been looking or parsing it yet ?

[OutdoorRob]

@stefan123t
Thanks for your feedback 🙏

Regarding your question see the description here.

My own HMS-1600-4T with firmware version 2.0.4 always and steady sends the additional bytes as 0x00.
The only other log with SystemParaConfig-Response version 0x0003 I know of is from Bernhard Roths HMS-2000-4T (firmware 2.0.4) (see here). In this log there are indeed other bytes different from 0x00 but none of them seem to relate to the limit of 30 % (0x012C) he used in this log.

For me this 'new' SystemParaConfig-Response seems like an unfinished product or accident by Hoymiles.
As you already noticed here - and I can confirm this in my own logs - packet 0x01 always and steady contains the CRC16 of the last SystemConfigPara-Response version 0x0001 that was send before updating to firmware 2.0.4 and sending the ActivePowerControl-Command with 0x0003 the very first time.
This old, frozen CRC16 makes no sense and seems more like a buggy firmware implementation rather than a new feature.

[stefan123t]

Hi @OutdoorRob thanks for reviewing this.

I have since searched for the initial discussion on Discord https://discord.com/channels/984173303147155506/993500210271629393/1373673726578528297

So you are also getting the additional packets but all 0x0000 ?

I asked Bernhard Roth for his results if he now also gets 0x0000 with the Hoymiles DTU Pro S.

[OutdoorRob]

@stefan123t
Yes, the only inverter I updated to firmware 2.0.4 so far, sends the extended SystemConfigPara-Response (type 3) with all additional payload bytes set to 0x0000.

---

Als Zusammenfassung anbei die Erkenntnisse zum Verhalten der Firmware-Versionen bezüglich der von mir und Dirk-Ahoy bzw. dirk3958 (Version 1.1.12) getesteten Parameter.

Zur Erklärung der Tabelle:

• PDL = Hoymiles Power Distribution Logic im Wechselrichter
• temp. Limits = temporäre (nicht-persistente) Limits funktionieren wie erwartet
• pers. Limits = persistente Limits funktionieren wie erwartet
• SystemParaConfig = 'Typ' / temp. und pers. Limits werden zurück gemeldet
• OpenDTU = mit aktueller Release-Version (OpenDTU bzw. AhoyDTU) voll nutzbar
• ❓ = to be tested
• ❌ = nicht verfügbar
• ➕ = nach Erweiterung / Fix nutzbar

Firmware	PDL	temp. Limits	pers. Limits	SystemParaConfig	OpenDTU
1.0.x	❌	✅	✅	'Typ' 1 / ✅	✅
1.1.12	✅	✅	✅	'Typ' 1 / ✅	➕
1.1.18	❓	❓	❓	'Typ' ❓ / ❓	❓
2.0.4	✅	✅	✅	'Typ' 1 / ❌ 'Typ' 3 / ❌	❌

Important

Das Setzen der Limits wurde mit den nachfolgenden Werten für das ActivePowerControl-Kommando (bzw. PowerControlType) durchgeführt. Diese sind noch nicht Bestandteil der aktuellen Release-Version von Ahoy- bzw. OpenDTU!

typedef enum {
    AbsolutNonPersistent = 0x0000,    // identisch zu bisherigem Kommando
    RelativNonPersistent = 0x0001,    // identisch zu bisherigem Kommando
    AbsolutPersistent = 0x0002,       // also 0b10 (binär!) statt 0x0100
    RelativPersistent = 0x0003        // also 0b11 (binär!) statt 0x0101
} PowerLimitControlType;

Daraus ergibt sich für mich, dass wohl aktuell die Firmware 1.1.12 die beste Variante ist, sofern man die Hoymiles Power Distribution Logic nutzen möchte.
Um diese vollständig zu nutzen, d.h. inkl. dem Setzen von persistenten Limits, sind aber noch Anpassungen in der jeweilligen DTU-Firmware nötig.

Die Firmware 2.0.4 enthält aus meiner Sicht noch einen Bug in der SystemParaConfig-Response, wodurch keine temporären Limits mehr zurückgemeldet werden.

Ich habe dieses Problem der 2.0.4 bezüglich des veränderten Verhaltens der SystemParaConfig-Response auch 'durch die Blume' an Hoymiles gemeldet. Aussage von Gestern seitens Hoymiles ist, dass es jetzt untersucht wird.
Falls sie es das Problem finden und als Bug beheben wird es da sicherlich irgendwann eine entsprechende WR-Firmware geben.

Auch Die Hoymiles DTU-Pro-S verwendet, wenn ich das richtig beobachtet habe, nämlich ebenfalls die SystemParaConfig-Response vom WR, um die Werte des aktuell gesetzten Limits wieder per Modbus lesend zur Verfügung zu stellen. D.h., dieses Problem schränkt auch die vollständige Verwendbarkeit der Hoymiles eigenen DTU ein - eigentlich Grund genug für sie es zu fixen ;)

Anbei zum direkten Überblick noch der Changelog zur Hoymiles WR-Firmware welcher hier mal gepostet wurde.

• V02.00.04

  • Add group control command frame and zero export management parameter analysis
  • Optimize code space
  • (The zero export management optimization function has been implemented on the equipment side, but the market opening has not been implemented and is still pending R&D testing. After confirmation, the headquarters window will inform the overseas locals)

• V01.01.18

  • Optimierung des Blindleistungskompensationsschemas
  • Verbesserung der Blindleistungs- und Leistungsfaktorgenauigkeit
  • Optimierung der FW- und FW_UF-Wiederherstellungslogik
  • Einführung einer Standard-RST-Zeit von 100 ms

• V01.01.12

  • Funktion zur dynamischen Wirkleistungszuweisung hinzugefügt (PDL !?)
  • Die Inselfunktion wurde optimiert
  • Das Problem der dynamischen MPPT-Effizienz unter 99 % wurde optimiert
  • APC-Priorität und VW-Funktion mit höchster Priorität reagierten nicht
  • Die UL1741 SB-Funktion wurde hinzugefügt

[tbnobody]

Danke für die detallierte Rückmeldung! Ich habe gerade die neuen Commands mit einem HMS-2000 mit Firmware 1.0.12 getestet und das funktionierte problemlos. (Soll heißen, dass ist kompatibel)

Falls jemand testen möchte:
generic_esp32.zip

Aber vorsicht bei der Verwendung der WebAPI

[AndreasBoehm]

@tbnobody Kannst du den passenden commit öffentlich machen oder ein diff bzw patch bereitstellen?
Ich würde die Änderung gerne testen, bin aber an OpenDTU-OnBattery gebunden.

Danke