Feature Erweiterung: Leistungslimitierung (für z.B. geregelter Batteriewechselrichter oder um gesetzliche Grenzen einzuhalten) about ahoy

[klahus1]

Hallo zusammen,

hier das Protokoll zur Leistungsreduzierung HM300:
Erste Version quick and dirty mit dem openDTU implementiert und getestet:

limit = zwei Byte, eine Dezimalstelle. Z.B: 30.0W = 300dez = 0x01 0x2c

<0x51> <WR>     <DTU>    <0x81>   <0x0b 0x00> <0x01 0x2c> <0x01 0x00>            <crc16/modbus> <crc8>
<Cmd>  <target> <source> <subcmd> <ctrlmode>  <limit>     <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8>

Log:

22:28:13.964 > Fetch inverter: 112172615582
22:28:13.964 > sendPackSetPowerLimitCommand
22:28:13.966 > sendEsbPacket
22:28:13.969 > TX 51 72 61 55 82 78 56 34 12 81 0B 00 01 2C 01 00 C5 C0 3E 
...
22:28:14.897 > Interrupt received
22:28:14.897 > 
22:28:14.897 > >> RX  OK: D1 72 61 55 82 72 61 55 82 81 00 00 0B 00 14 07 48 
22:28:14.903 > 
22:28:15.271 > RX Period End
22:28:15.271 > getLastRequest() == RequestType::Cmd
22:28:15.275 > Success

Siehe auch :

usart_nrf3.cpp
UsartNrf_Send_DevControlUpdate()
...
                    MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[0] = (u8)(relative_value >> 8);
                    MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[1] = (u8)(relative_value);
                    MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[0] = 0;
                    MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[1] = 1;

...Happy coding...

Viele Grüße
Klaus

[aschiffler]

Sollte nun mit der Version 0.5.13 erfüllt sein.
Anleitung: hier

[allesgutewarweg]

Ich hatte eine DTU-pro zu Hause kann dazu einige Fragen beantworten wenn Infos fehlen sollten.

Generell ist das Gerät ganz nett, die Einrichtung als auch die Bedienung erinnert allerdings nicht an ein über 200€ teures Gerät daher habe ich es zurück geschickt.

Ohne zusätzlichen SmartMeter der über den RS-Port angeschlossen wird ist nur eine fixe Limitierung von 2 - 100% möglich. Zero-Export und Co benötigen mind. 1-2 zusätzliche Smartmeter von Hoymiles die über den RS-Port angeschlossen werden was für mich nicht in Frage kommt da ich schon einen Shelly 3EM verbaut habe, es wäre daher toll wenn die Ansteuerung anhand bereits vorhandener Verbrauchsdaten erfolgen könnte.

[lumapu]

Ich habe vor längerer Zeit schon ein Konzept entwickelt, das nur noch eine einzige Buffer loop hat und daraus die Payload zusammensetzt. Davor muss aber noch die NRF24 Kommunikation auf polling umgestellt werden um hoffentlich endlich stabil zu sein und ein fixes Timing zu bekommen.

Grundsätzlich bin ich schon dafür möglichst viel zu integrieren. Aber Stück für Stück, das ganze hier kann einen locker 40h in der Woche beschäftigen ;-)

[stefan123t]

@homeautomation2022 beide Features permantent / temporäres PowerLimit sind implementiert.
Bitte ggf. nochmals mit der v.0.5.9 überprüfen und ggf. als gelöst schließen. Danke

[DanielR92]

@homeautomation2022 wir sind aktuell bei v0.5.12.
Hattest du schon Zeit die obenen Punkte überprüfen? :)

Dann können wir dieses Issue closen. Gruß

[Sprinterfreak]

Hallo,
steht auf unserer Liste. Wir wissen nur noch nicht wie man das dem Wechselrichter mitteilt.

Hängt ab von umfangreichen original pcap's der Ansteuerung zum reverse-engineering. Solange die keiner anfertigt und bereitstellt kommen wir da nicht weiter.

[stefan123t]

Speziell ein Mitschnitt der Kommunikation mit einer DTU Pro wäre hierbei hilfreich. Dort gibt es sicher analog zur DTU Lite einen Testpunkt für RX/TX zwischen MCU und nRF24 an dem man die Daten abgreifen könnte.

[homeautomation2022]

Wäre ja für den aller ersten Anfang schonmal gut, wenn jemand mit DTU Pro überhaupt den Punkt im Webif/App findet und einstellen kann, wenn das klappt, dann kann man das sicher auch sniffen. Mehr als die oben geschriebenen Informationen konnte ich dazu leider nicht finden.

[stefan123t]

Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c):

Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und
speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz
vollständige Liste der DTUs im Besitz von Foren Teilnehmern. Auch ein
Salea Logic Analyzer habe ich mal ausprobiert und anhand den von martin
(Gast) in seiner DTU-Lite aufgenommenen Daten (RX/TX) Testpunkt
dokumentiert, wie man dabei zu den entsprechenden Logfiles kommt. Es
gibt da sog. Analyzer (speziell Async Serial funktioniert) und dann kann
man einen Export ins CSV Format machen.

Jetzt bräuchten wir nur noch einen Freiwilligen DTU-Pro Besitzer, der
das große Kästchen mal aufschraubt und an den RX/TX Punkten mißt was
passiert, wenn man per ModBus ein paar Kommandos gibt. Wenn die DTU
Besitzer ihre Geräte nicht aufschrauben wollen gäbe es immer noch andere
Methoden (NRF24_Sniffer, Ahoy zum Sniffen anpassen) die eventuell etwas
minimal-invasiver sind, jedoch wäre das vermutlich mit mehr Aufwand und
weniger Erkenntnisgewinn verknüpft, da die Pakete nicht so sicher
belauscht werden können wie am RX/TX Testpunkt auf der Platine.

Die Salea Logic Analyzer bzw. Clones gibt es übrigens für ca. 13,- Euro
aus der Bucht:

  https://www.ebay.de/itm/255283244102

• Trace / Sniffer Software:

  • Salea Logic / Clone

    • Sigrok Software (Pulseviwew)

      https://sigrok.org/
      https://sigrok.org/wiki/Downloads
      http://marcusjenkins.com/saleae-logic-analyser-clone-with-ubuntu/

    • Salea Logic

      https://www.saleae.com/downloads/

      chmod +x Logic-2.3.53-master.AppImage
      ./Logic-2.3.53-master.AppImage

        <1F> Analyzer (right side toolbar)
        Analyzers (+)
          Async Serial
            Input Channel: 00. Channel 0
            Bit Rate (Bits/s): 125000
            Bits per Frame: 8 Bits per Transfer (Standard)
            Stop Bits: 1 Stop Bit (Standard)
            Parity Bit: No Parity Bit (Standard)
            Significant Bit: Least Significant Bit Sent First (Standard)
            Signal Inversion: Non Inverted (Standard)
            Mode: Normal
            [x] Show in Protocol Results Table
            [x] Stream to terminal
          Save
        Analyzers (+)
          Async Serial
            Input Channel: 01. Channel 1
            Bit Rate (Bits/s): 125000
            Bits per Frame: 8 Bits per Transfer (Standard)
            Stop Bits: 1 Stop Bit (Standard)
            Parity Bit: No Parity Bit (Standard)
            Significant Bit: Least Significant Bit Sent First (Standard)
            Signal Inversion: Non Inverted (Standard)
            Mode: Normal
            [x] Show in Protocol Results Table
            [x] Stream to terminal
          Save
          Rename the two Async Serial Analyzers to RX / TX
          Data ... Export Table
            Export Table Data
              Columns: (*) All
              Data: (*) All
              Export Format: (*) CSV
              [x] Use ISO8601 Timestamps
            Export

• NRF24_Sniffer

      git clone https://github.com/Yveaux/NRF24_Sniffer
      ./nrf24-sniffer.py -a 90:65:23:74:01

• Wireshark

• Python ESP Variante zum Mitschneiden anpassen konfigurieren
• Pakete einer DTU und eines Wechselrichters (hier MI-1500) mit der
  ESP/Raspberry Pi Variante mitschneiden.
• Kommandos per Modbus an die DTU-Pro senden und diese mit einem
  LogicAnalyzer an den RX/TX Testpunkten in der DTU mitschneiden
• Payload und Kommandos aus den Datenpaketen extrahieren und analysieren

DTU Besitzer / Nutzer

DTU-Pro: Sascha D. (bandit7311), Ziyat T. (toe_c)
DTU-Lite: martin (Gast), Oliver F. (of22), Martin G. (petersilie)
DTU-W100: Arnaldo G. (arnaldo_g), Sergey S. (sergey_s632), Mike (Gast)
DTU ?: Daniel M. (daniel_m821), Martin P. (mpolak77)

DTU-Pro Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Sascha D. (bandit7311)
DTU-Pro Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Ziyat
T. (toe_c)

DTU-Lite xxxx72818832
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx martin
(Gast)
DTU-Lite xxxx72819005
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Oliver F.
(of22)
DTU-Lite Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Martin G. (petersilie)
DTU-Lite 10D972xxxxxx
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 10D9 martin
(Gast)

DTU-W100 10D373114359
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 10D3 Sergey S.
(sergey_s632)
DTU-W100 xxxx70535453
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Arnaldo G.
(arnaldo_g)
DTU-W100 10D373114359
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 10D3 Sergey S.
(sergey_s632)
DTU-W100 Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Mike
(Gast)

DTU Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Daniel M.
(daniel_m821)
DTU basic ? Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Martin P. (mpolak77)

Exoten MI & TSUN Wechselrichter:

MI-1500 xxxxxxx14456
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Arnaldo G.
(arnaldo_g)
MI-1500 xxxxxxx36590
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Arnaldo G.
(arnaldo_g)
MI-1500 Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Ziyat
T. (toe_c)

MI-600 1041xxxxxxxx
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 1041 David B.
(mystisch)
TSUN TSOL-M800 104163500316
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 1041 Daniel M.
(Gast)

---

Diskussionsausschnitte zum Thema DTU-Pro und Modbus Ansteuerung

Da ich meiene DTU-Pro über Modbus-RTU selber ansteuere, könnte ich den
WR gezielt ansteueren, ich waere bereit sie zu sniffen aber brauche
HW-maessig hilfe wie ich es machen soll.

Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-)
MOSI, MISO, usw.
https://www.az-delivery.de/products/saleae-logic-analyzer
Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom
LA klar kommst, dann die PINs im DTU-Lite :-) so ist das gemeint von
mir.
Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als
Hex anzeigen.

Den LA gibts natürlich auch bei anderen Anbietern.

Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner
DTU festgestellt hatte:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
handelt, der einen eigenen Controller drin hat.

Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für
RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal
anbei.

Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit
Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet.

Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in
zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten
und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was
angefragt wurde, um die Payload dekodieren zu können.

Wir sollten zukünftig also von:
Fragmenten, Paketen, und Payloads sprechen.
Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das
Paket enthält die Payload.

Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment

• 1 byte crc
  Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc
  Jede Payload kann demnach max 2046 byte haben.
  Vermutung, abgeleitet aus den bisher bekannten Umständen.

In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure
Daten rankommt, aber leider auch nicht identisch ist), sind Register zu
sehen, die dafür zuständig sind:
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über
ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit
dem Protokoll zum WR aussieht, aber es muss ja alles über NRF
funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70%
Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in
jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer
wieder zyklisch das aktuelle Limit geschrieben.
Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur
da das möglich bzw. freigegeben ist.

Nach Inbetriebnahme kann ich gerne auch Daten beisteuern.
Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu
unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion
zu "entschlüsseln".

Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie
Hat die HMT-Serie ein geändertes Protokoll?

Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern:
HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500 1200-4T HMS-1000
900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.

[klahus1]

Moin Moin,
in der Version 0.4.15 sind die Eingabemöglichkeiten für «Max Module Power (Wp)» vorhanden.
Gibt es schon Erkenntnisse, was dort einzugeben ist und welche Auswirkung es hat?
Vielen Dank für die tolle Arbeit in diesem Projekt...

[stefan123t]

@klahus1 ist zwar OT hier aber die Max Module Power errechnet aus der/n an einem Strang/Eingang angeschlossenen Modulleistung(en) die Irradiation in %.
Ich habe 2 Module mit je 375Wp an meinen beiden Eingängen eines HM-600, also trage ich 375,375,0,0 in die vier Felder ein. Aus der aktuellen Leistung zur max Modulleistung kann der Ahoy ESP code dann die Sonneneinstrahlung/-intensität in % berechnen.

[DanielR92]

Moin,
ich werde mich heute nochmal damit ausseinander setzen.
Habe aber noch eine Frage zu meinen Gedanke (ob ich das auch so testen kann).

Aktuell sind die Solarzellen noch in der Produktion, somit betreibe ich den WR mit einem Labornetzteil (30V bei 10A max. => 300W).

Mein WR (HM-1500) kann ja laut Datenblatt zwischen 1 bis 100% regeln. 1% entspricht hier dann 15W, 10% dann 150W.

Beim testen würde es für mich beudeten, das ich den WR sagen muss das er Bsp. auf 10% regeln soll. Damit ich mit meinem Netzteil überhaupt auch eine Änderung UND mit einem Energiemesszähler an der Steckdose vergleichen kann.

PS: Maximal schaffe ich 300W - ~10W verlust einzuspeisen.

Passt mein Gedanke so? =)

Danke

[klahus1]

Hallo DanielR92,
so ähnlich sind auch meine Gedanken.
Ich würde gerne nicht die vollen 300W pro Modul einspeisen, sondern nur so viel wie der aktuelle Verbrauch (die Grundlast) oder z.B. im ersten Schritt fix 70W pro Wechselrichter. ( Meine Konfiguration: Drei Solarmodule+Wechselrichter, Grundlast über den Tag ca. 200W )
Die Differenz zwischen Solarzellen-Leistungs-Abgabe und Wechselrichter-Leistungs-Aufnahme werde ich versuchen per Solar-Lade-Regler in Batterien "zwischenspeichern". Die Wechselrichter beziehen den Gleichstrom aus den Batterien via Solar-Lade-Regler.
Mit der reduzierten Wechselrichter-Leistung könnten auch mehr als zwei 300W Module / Wechselrichter konform zu den gesetzlichen Vorgaben einspeisen.
Und zusätzlich wird auch weitesgehend verhindert, dass überhaupt "kostbarere" Energie ins Netz zurückgespeißt und dem EVU zum "Nulltarif" zur Verfügung gestellt wird.
Ich hoffe, dass die Verluste der "Batterie-Pufferung" sich in Grenzen halten und sich der Aufwand daher auch lohnt.

[stefan123t]

Hallo @klahus1 ich finde den Gedanken den Wechselrichter zu steuern ja sehr interessant und auch die Batterie Pufferung (bei mir auf dem Balkon halt nicht) oder Brauchwassererwärmung sind sinnvolle Nutzungen der Energie. Was ich noch nicht verstehe ist warum man die Überschüssige Energie, die die PV Paneele eingefangen haben praktisch im Wechselrichter vernichten / in Wärme überführen muß, anstatt Sie zwar dem EVU zum "Nulltarif" aber letztendlich doch für uns alle gewinnbringend (weil ressourcen-schonend) ins Netz einspeißen kann.
Ich frage mich in diesem Zusammenhang ob es nicht politisch sinnvoll wäre, die deutsche 600VA Grenze im EU-weiten Rahmen (bis 1000VA geplant) einfach anzuheben auf 2100VA und statt jedem Bürger eine Einmalprämie von 300 Euro zu zahlen, jedem einen Gutschein für ein / zwei Solarpaneele plus Wechselrichter zu geben.
Meine beiden 375 Wpp Module liefern aktuell zwischen 2-4kWh am Tag. Mit dem zwei- bis vierfachen könnte ich unseren Strombedarf tagsüber komplett abdecken und auch noch einiges an Überschuß produzieren. Vor allem könnte ich für alle drei Phasen im Haus gleichmäßig einspeisen, wenn diese o.g. Regelung nicht auf 600VA pro Anschlußteilnehmer sondern pro Phase begrenzt wäre.
Warum die EVU nicht verpflichtet werden, die zusätzlich eingespeißte Energie einfach (zu einem günstigen Fixpreis wenigstens) mit der anderweitig abgenommenen Energie zu verrechnen verstehe ich auch nicht. Die digitalen Zähler sind m.W. alle prinzipiell zwei-Richtungs-fähig; könnten also sowohl Produktion als auch Verbrauch zählen & registrieren.

Ach ja hier noch das Bild aus der HM Dokumentation User-Manual_DTU-Pro-S_Global_EN_V202111

Dort und hier ist übrigens auch vom sog. DRM Port an der DTU Pro die Rede, der anscheinend für den Anschluß von Smartmetern in Australien und Neuseeland vorgeschrieben ist. Die Implementierung für DRM.c und DRM.h finden sich ggf. auch im bekannten Source Code.

[klahus1]

Hallo stefan123t,
klar ist es eine gute Idee, die "überschüssige" Leistung ins Netz der Gemeinschaft zur Verfügung zu stellen. Wenn diese zu dem Zeitpunkt auch sinnvoll und direkt genutzt wird. (Mehrfamilienhaus).
Wenn die Leistung jedoch dann im Netz des Versorgers nur hin und her "vagabundiert" hilft es auch niemandem (Leitungsverluste etc...).
Zudem haben wir bei Sonnenschein auch einen enormen Überschuss, der uns an wolkigen Tagen oder in der Nacht fehlt.
Das Problem wird sich zukünftig ja noch verschärfen, je mehr dezentrale Solaranlagen am Netz hängen.
Gemeinschaftliche Energiespeicher / Puffer im Versorgernetz sind aufwendig, teuer und werden den Preis für Strom noch weiter erhöhen.
Gerade die Summe der "Kleinanlagen" sollte nicht unterschätzt werden.
Mir geht es darum, meine Grundlast gleichmäßig zu decken / selbst zu "erzeugen".
Und ggf die Peaks im Netz klein zu halten.

[DanielR92]

Bytheway: Es wird gemunkelt das die Energielieferanten mit der Politiker unter einem Hut stecken. Wenn jeder sein Strom selbst erzeugen kann (was möglich ist!), kommen die großen Energielieferer zu kurz und bekommen kaum noch Geld vom Volk...

What ever, das ist meine Meinung und ich glaube einfach das "die da oben" zwar sehen was für uns Volk besser ist. Jedoch einfach nur $$$ sehen.

:)

PS: @klahus1 da bin ich Dakor, die Denkweise sehe ich genau so. Wenn man umbegrenzt Strom ins Netz einspeißen könnte... könnte es selten dazu kommen das Stromüberschuss besteht und dann hätten wir ein "Blackout?"?

Wobei ich bei mir es so machen möchte, wenn mehr Strom erzeugbar wäre. Möchte ich gerne später ein PC einschalten und dann kann es ja paar Bitcoins im Hintergrund rechnen.

[klahus1]

Hallo zusammen,
gibt es eine Sammlung von Informationen bzgl. Versuche und Tests zum Thema Leistungslimitierung?
@DanielR92 hast du noch weitere Informationen?
Gerne würde ich beim Thema unterstützen und es weiter voran treiben.
Zum Testen hätte ich einen HM300 leider keine DTU-PRO zum Mitlesen.
"Grundkenntnisse" beim Programmieren mit C/C++ und Python wären vorhanden ;-)
Viele Grüße
Klaus

[stefan123t]

@klahus1 Daniel und ich analysieren und erproben gerade einige Ansätze unter https://discord.gg/JdxgNJSm

[stefan123t]

@klahus1 Klasse super Arbeit mit @DanielR92 !!!
Ich würde an dieser Stelle gerne auf den #35 Leistungsreduzierung HM300 in der OpenDTU verweisen, da dort bereits mehr Details zur Implementierung dokumentiert sind.

[stefan123t]

Hier drei Device Control Commands für das Ein-/Ausschalten bzw. den Reset des Wechselrichters.

51 76543210 78563412 81 0000 B001 A5 ------ Type_TurnOn 0x00
51 76543210 78563412 81 0100 2000 55 ------ Type_TurnOff 0x01
51 76543210 78563412 81 0200 D000 7B ------ Type_Restart 0x02
^^-------------------------------------- MainCmd 0x51 DEVCONTROL_ALL
   ^^^^^^^^----------------------------- WR Serial ID
            ^^^^^^^^-------------------- DTU Serial ID
                     ^^----------------- SingleFrameID
                        ^^-------------- SubCmd siehe oben
                        ^^^^------------ Control Mode ? immer zwei Byte im Gen3 Protokoll
                              ^^^^------ CRC16 / CRC-Modbus über die Daten, excl. Frame ID!
                                   ^^--- CRC8

Die CRC16 und CRC8 läßt sich ggf. online berechnen, falls es jemand mal schnell kontrollieren will:

CRC-16/CRC-Modbus Input Data: 0x0200
Result CRC-16/CRC-Modbus value: 0xD000
https://crccalc.com/?crc=0x0200&method=CRC-16/MODBUS&datatype=hex&outtype=0

CRC-8 Input value: 0x51 76543210 78563412 81 0200 D000
Result CRC-8 value: 0x7B
https://crccalc.com/?crc=0x517654321078563412810200D000&method=CRC-8/ITU&datatype=hex&outtype=0

---

Und hier das Power Limit setzen

51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B
^^------------------------------------------------ MainCmd 0x51 DEVCONTROL_ALL
   ^^^^^^^^--------------------------------------- WR Serial ID
            ^^^^^^^^------------------------------ DTU Serial ID
                     ^^--------------------------- SingleFrameID
                        ^^------------------------ SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr
                        ^^^^---------------------- Control Mode
                             ^^^^----------------- PowerPFDev.SetValut 0x012C = 30.0 W
                                  ^^^^------------ PowerPFDev.Desc 0x0000 oder 0x0001 ?
                                       ^^^^------- CRC16 / CRC-Modbus über die Daten, excl. Frame ID!
                                            ^^---- CRC8

CRC-16/CRC-Modbus Input Data: 0x0B00 012C 0000
Result CRC-16/CRC-Modbus value: 0x55C1
https://crccalc.com/?crc=0x0B00012C0000&method=CRC-16/MODBUS&datatype=hex&outtype=0

CRC-8 Input value: 0x51 76543210 78563412 81 0B00 012C 0000 55C1
Result CRC-8 value: 0x0F
https://crccalc.com/?crc=0x517654321078563412810B00012C000055C1&method=CRC-8/ITU&datatype=hex&outtype=0

Die Antwort Pakete haben wir noch nicht entschlüsselt, aber es kommt immer (MainCmd | 0x80) also ANSWER_DEVCONTROL_ALL 0xD1 zurück.
Bei Fehlern in der Nachricht oder der CRC-16/CRC-Modbus Checksumme kommt 0xF1 oder 0xFF als Fehlercode je nachdem ob es sich um eine SingleFrame oder MultiFrame Anfrage/Fehler gehandelt hat.

[stefan123t]

@lumapu hast Du vor die o.g. Device Control Kommandos (Start/Stop/Restart) und ggf. Optionen zum Senden & Empfangen von allgemeinen SingleFrame / MultiFrame Kommandos in das ESP-Ahoy einzubauen ?
Das Thema mit den Alarm Message Log steht glaube ich auch noch auf unserer ToDo Liste... 😸

[stefan123t]

@lumapu das was in PR #109 von @aschiffler umgesetzt wurde ist prinzipiell richtig und funktioniert laut einigen im Discord Chat.
Es funktioniert halt bisher nur für einen WR und auch nur mit einem fixen Topic /home/huette/setpower.
Wenn man noch andere Kommandos, evtl. direkt aus dem UI senden könnte wäre es noch schöner.