Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?

[Lukas P. (lumapu)]

Guten Abend,

anbei die neusete Version.
Danke an @Jan-Jonas, diese Version hat jetzt auch den Retransmit des 
letzten Pakets, sobald bekannt ist welches das letzte Paket ist.
Ich hoffe die Stabilität konnte weiter verbessert werden und stellt 
einigermaßen zufrieden.

Durch den last-Paket-Retransmit kommen bei mir deutlich mehr komplette 
Payloads zustande (mit einem 5s Interval). Aktuell funke ich durch 3 
Betondecken vom Keller aufs Dach.

Edit 22:20: 0.4.12 mit Boot-Loop fix
Wir haben 1000 Beiträge =)

Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =)

[rosch99 (Gast)]

Misch O. schrieb:
> suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem
> Link dazu helfen

Hier die brandaktuelle 0.4.11 kompiliert für den Wemos D1 mini

[Lukas P. (lumapu)]

leider nicht mehr brandaktuell, es gibt schon die 0.4.13.

[rosch99 (Gast)]

Lukas P. schrieb:
> Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =)

oh, mein Artikel kam zu spät, lumapu ist so schnell am committen,
ich komme mit dem kompilieren nicht nach ;-)

[Daniel R. (daniel92)]

Moin zusammen,

nach der Arbeit schaue ich mir mal den Code und alles an. :)
Ich nutzte aktuell VS Studio und aktuell für den Arduino, die eigene 
IDE. VSCode läuft bei mir irgendwie nicht rund.

Oder kennt jemand ne gute Anlauf stelle um mit VS Studio direkt zu 
compilieren? - Bitte keine "nutz Google" Antworten.

Aktuell habe ich das gefunden: 
https://marketplace.visualstudio.com/items?itemName=VisualMicro.ArduinoIDEforVisualStudio

Was nutzt ihr denn?

Vielen Dank und den neuen Code teste ich sobald ich heute wieder Zuhause 
bin. :)

1003 Einträge, Mensch haben wir ein neuen Rekord aufgestellt? :D

[Günter H. (gnter_h534)]

Einen Link dazu kenne ich auch nicht.

Bei mir klappt es mit der Arduino IDE 1.8.19 und

- aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4)

sowie den LIBRARIES

- Time 1.6.1
- RF24 1.4.2
- PubSubClient 2.8

ohne Probleme.

Gruß Günter

[Christian P. (pocki)]

Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht.
Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut 
werden kann?

Hardware hätte ich alles schon da: Raspberry Pi, nRF24, ESP8266, 
Arduino-Nano.

LG, Pocki

[isnoAhoy (Gast)]

Hallo Christian P.,
leider gibt es noch keine klare Information zu den älteren MI-Modellen 
von Hoymiles. Es gab bereits einige Foristen mit einem MI- 
Wechselrichter, u.a. Ziyat T. mit einem MI-1500, Arnaldo G. mit zwei 
MI-1500 und Daniel B. mit einem MI-600, Daniel M. mit einem TSUN 
TSOL-M800 vermutlich ein re-brandeter MI-800 und jetzt Du mit einem 
MI-300.
Leider haben wir bisher relativ wenig Informationen über das ältere 
MI-Protokoll. Ziyat. T. hat mal eine Auswertung in Excel als Screenshot 
MI1500data.png und DTUPro.log angehängt und Arnaldo G. hatte sehr zu 
Beginn dieses Threads seine nrf24.txt und nrf24_2.txt Ergebnisse vom 
mitsniffen ihrer DTU Pro bekannt gegeben.
Vielleicht wollt Ihr auch mal ein Issue auf github aufmachen um den 
aktuellen Wissensstand zur MI-Serie zusammenzutragen. Da könnte dann 
z.B. Ziyat noch mal erklären wie er zu den Ergebnissen bei seiner 
Auswertung gekommen ist. M.E. sah das was die Spannung und sonstigen 
Werte angeht schon sehr vielversprechend aus ...
Das fehlende Glied sind die Aufforderungen zum Tanz die die DTU-Pro den 
MI-Wechselrichter schickt. Hier müsste man am besten und einfachsten an 
den RX/TX Testpunkten in der DTUPro den Verkehr mit einem Logic Analyzer 
mitschneiden. Anleitung für eine DTU-Lite hatte martin (Gast) hier 
bereits geliefert:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Du kannst auch einfach nochmal auf der Single Page Ansicht nach "MI-", 
"MI1500", "Salea" etc. suchen.

Ziyat & Arnaldo, do you have an Logic Analyzer at hand or would you get 
one for a dozen bucks to make those traces ?
I have given you a short summary for the Software Decoding / Analysis 
under Linux in a recent post, where I documented my approach to 
successfully decode the files DTU_Captures.zip from martin:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[isnoAhoy (Gast)]

@Ziyat & Arnaldo, I believe Sigrok / Pulseview may be even able to read 
raw data from Raspberry Pis GPIO pins, just in case you do not have a 
Logic Analyzer at hand.

Read here for two projects with the same goal and helpful input on how 
to best secure the GPIO Pins against overvoltage / current.
https://github.com/superzerg/logic-analyzer
https://github.com/richardghirst/Panalyzer

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht.
> Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut
> werden kann?

Hallo Christian P. und  @isnoAhoy
Bisher funktionieren alle SW-Versionen nur mit der HM-Serie, MI-Serie 
werden (imho) nicht unterstützt.

Meine Motivation um den MI zu analysieren (zur Zeit) ziemlich klein 
geworden:
- Hoylimoly hat die Produktion der MI's abgestellt
- Die MI's als 2.gen haben wenige Funktionen, vor allem man kann sie 
nicht unter 10% limitieren, das passt mir überhaupt nicht (zero import? 
wenn kein load)
- MI-Ports können nicht einzeln limitiert oder ein/ausgeschaltet werden

Ich habe bisher durch meine DTU-Pro Hilfe (wenn sie eingeschaltet ist 
konnte ich die WR-RF-Messages mitlesen) alle Werte in MI-Messages 
entschlüsseln, den MI konnte nicht ansprechen, bisher das ist alles.

Ich werde weiter machen wenn ich den HM bekomme, sorry.

[Christian P. (pocki)]

Ja, ist nachvollziehbar. Die MI Serie ist schwierig zu knacken.

Ich habe mich soweit durch die 1000+ Postings gearbeitet, speziell die 
Logfiles nrf24.txt bis hin zu nrf24_5.txt und weitere. Scheint als fehle 
noch das initiale Aktivierungskommando der DTU. Schon versucht, die DTU 
abzustecken, abzuwarten bis die Inverter verstummen und dann beim 
Wiedereinschalten der DTU dessen Init-Kommando zu erwischen? Eventuell 
ist genau der setTime-Command der Key?

Ich kämpfe noch, um Raspi, nrf24-modul, esp8266, nano und die Software 
zum Laufen zu bringen. Hoffe ich habe das bald bei'nander.

[isnoAhoy (Gast)]

Hallo Lukas P.

warum ist in hmRadio.h eigentlich Kanal 40 nicht als Receive Channel mit 
angegeben ?

#define RX_CHANNELS             5
...
            // Depending on the program, the module can work on 2403, 2423, 2440, 2461 or 2475MHz.
            // Channel List      2403, 2423, 2440, 2461, 2475MHz
            mRxChLst[0] = 03;
            mRxChLst[1] = 23;
            mRxChLst[2] = 40;
            mRxChLst[3] = 61;
            mRxChLst[4] = 75;
...
        uint8_t getRxNxtChannel(void) {
            if(++mRxChIdx >= RX_CHANNELS)
...
        uint8_t mRxChLst[RX_CHANNELS];

würde das um den Kanal 40 erweitern.
laut FCC Dokumentation soll das nRF Modul ja auf allen fünf Kanälen 
funktionieren.

@Christian P., Ziyat T., etc.

mit der o.g. Erweiterung könnte man ggf. auch seine DTU als 
"Dummy"-Wechselrichter eintragen,
also DTU Serien Nummer stattdessen mit führender 1121, 1141 oder 1161 
eingeben.

Er würde dann zwar auch versuchen der DTU die bekannten 
Status/setTime-Kommandos zu schicken,
aber gleichzeitig müsste er auch alles was von der DTU kommt als 
Received bytes channel XX im
Serial Monitor ausgeben.

[Christian P. (pocki)]

Ich selbst habe leider keine DTU, und plane auch nicht eine zu kaufen.

Ich fürchte es wird nötig sein, dass ein DTU-User einen MI-WR aus seinem 
Setup entfernt (de-registriert) und neu einrichtet/registriert. Und am 
besten BEIDES mitschneiden :-)

[Christian P. (pocki)]

Die Benutzeranleitung der DTU-Pro App erwähnt eine Funktion zur 
automatischen Erkennung naher Microinverter:

https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf 
Seite 16:
>3. You can add microinverter via “Automatic Search” or typing in...
>4. The search result of microinverters and microinverter added will be displayed

Die Screenshots wurden mit Inverter-Seriennummern 1121xxxxxxxx gemacht, 
also vermutlich MI-Serie.

Könnte jemand mit einer DTU und dieser App das mal ausprobieren und ggf. 
den nrf24-Traffic versuchen einzufangen?

[Daniel R. (Gast)]

Hi Pocki,

ui das klingt ja mal Interessant. Wenn es tatsächlich klappen sollte, 
könnte man das als Feature mit einbauen um einfacher die WR zu 
hinterlegen.

Sehr cool, glaub ich sollte auch mal das ganze Handbuch studieren. 😅

[Ziyat T. (toe_c)]

Wenn Ihr schon mit solchen guten Vorschlaegen kommt, bitte liest Ihr das 
HB 
(https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf 
) nochmals schön durch:-)
Es handelt sich um DTU-Pro-S
Microinverter Compatibility
Microinverter model HMS series, HMT series

[Christian P. (pocki)]

Hm, stimmt allerdings.
Ich erinnere mich Ende 2020 an ein Handbuch mit Screenshots zur DTUlite 
von schlecht designten HTML-Seiten zur Einrichtung der WR. Und da gab es 
auch einen "search"-Button. Und das war zu Zeiten bevor es die HM-Serie 
gab.

[isnoAhoy (Gast)]

Hallo martin (Gast) & Christian P.,

das sieht in der Tat interessant aus. Die Funktion scheint es auch in 
der DTU-Lite-S zu geben. Ich weiß natürlich nicht ob es das nur in der 
-S Version und/oder auch in der WLite Version gibt ?

User Manual_DTU-Lite-S_Global_EN_V202202
https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_DTU-Lite-S_Global_EN_V202202.pdf

> 3. You can click "Automatic Search" to add microinverter,
> or you can type in / scan the microinverter ID.

@martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic 
Analyzer ausprobieren und mitschneiden ?

[Daniel M. (daniel_m821)]

Mal eine blöde Frage zwischendurch:
Wenn ich versuche aus der Arduino-IDE meinen Wemos D1 Mini zu flashen, 
rennt er in eine Boot-Loop und kommt nicht.
Ich möchte nicht ausschließen, dass ich falsche Einstellungen habe, kann 
mir jemand die richtigen geben? Auch könnte der Flash mittlerweile 
hinüber sein, was ich auch nicht ausschließen kann.
Ich nutze aktuell Arduino 1.8.19 und habe es mit der ahoy-Version 0.4.13 
von Github probiert.

Mit etwas Überzeugungshilfe habe ich esptool 3.3 dann dazu bekommen, das 
bin-file direkt zu flashen und es klappte nach einigen Schwierigkeiten.

Danach wäre ein kurzer Exkurs in das Programm interessant, an welchen 
Stellen die Adressen und Befehle zusammengebaut werden.
Würde mich da mal mit den Anpassungen auf den TSUN beschäftigen und 
schauen, was ich mit meiner Unkenntniss hinbekomme.

Dankeschön :)

Edit: ein neuer Git Pull hat geholfen, habe noch eine Vorversion mit dem 
Bug drin gehabt. Die Einstellungen mal vergleichen wäre trotzdem 
Hilfreich.

[martin (Gast)]

isnoAhoy schrieb:
> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic
> Analyzer ausprobieren und mitschneiden ?

Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.

[Christian P. (pocki)]

martin schrieb:
> isnoAhoy schrieb:
>> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic
>> Analyzer ausprobieren und mitschneiden ?
>
> Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.

Das wäre ganz super :-)
Ich habe inzwischen mein Klump zusammen und kann gleichzeitig nrf24 
sniffen (noise wird über crc-check verworfen) und auch custom-payloads 
senden :-)

Sobald ich also einen Anhaltspunkt bekomme, an welche 
Destination-Adresse mit welchem Payload man Pakete senden könnte, kann 
ich starten.

[Christian P. (pocki)]

Ich habe von meinem MI-300 nun geschafft Antworten zu empfangen, 
wenngleich auch noch keine nutzbaren Daten:

Anfrage via nrf24 (on-air):

Address 1319406101    Data 15 77665544 88776655 81 58
          WR-rev           mid  DTU    dummy   cmd crc

Antwort vom WR (on-air):

Address 4455667701    Data 15 77665544 61401913 81 bf
          DTU-rev          mid  DTU    WR      cmd crc

Nach ein bisserl Herumspielen stelle ich fest:
1) Der WR antwortet an die Adresse, welche in der Anfrage-Payload bytes 
2,3,4,5 steht, reversed und mit 0x01 ergänzt. hier also 77665544 liefert 
die WR-Antwort an die Adresse 4455667701

2) Die Felder WR und DTU sind somit vertauscht (hinter dem MID): zuerst 
kommt die DTU (an welche der WR seine Antwort senden soll), und dann der 
WR.

3) Die Länge der Antwort ist immer gleich lange wie die Länge der 
Anfrage.

Keine der bekannten Anfragen (MID 0x07, 0x15 und CMDs 0x00, 0x80 bis 
0x83) liefern brauchbare Payload retour: es kommt immer nur genau das 
zurück, was in der Anfrage gesendet wurde. Einziger Unterschied ist die 
S/N des WR (bei mir 61401913) und dann natürlich die 8bit payload-crc.

So, und was nun? :-)
Ideen willkommen

[Daniel R. (daniel92)]

Hmm, interessant...

Ich hätte die Idee das man die MID inkrementiert und darauf lauscht.
0x00 bis 0xFF sind 255 steps.

Wie lang dauert das Senden + Empfangen + Delay? 1sek.?
Dann hätte man nach 255sek. wenigsten die Info ob bei allen MIDs die 
gleiche Antwort zurück kommt.

Oder was meint ihr?

[Christian P. (pocki)]

Ok, rennt schon. Leider nicht so simpel, weil der WR nicht bei jeder 
Sendung antwortet. Ich vermute, das liegt am Channelhopping des WR: der 
scannt umher auf den Kanälen.
Ich sende und sniffe aber nur Channel 0x03, daher kann es sein, dass ich 
ein Paket 5-10x senden muss, um eine Antwort zu bekommen.

Ein erster Durchlauf bestätigt das. Was ich schon mal sagen kann:
Pakete mit MID größer als 0x80 werden nicht beantwortet. Auch MID=0x00 
bleibt stumm.

Ich lasse mal laufen für MID=0x00-0xFF und CMD=0x00-0xFF folgende 
Payloads jeweils 4x mit 15 retransmissions :-)

  MID+  dtu   +   wr   +CMD+crc
zb 07 77665544 61401913 81 aa

Werde berichten...

Hoffentlich zerschiesse ich mir den WR damit nicht

[Daniel R. (daniel92)]

Hmm, soviele retransmissions macht doch kein Sinn?

Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu 
schalten, damit man mehrere Kanäle sich anhört.

Apropo Channel hopping, irgendwo muss doch eine Komunikation stattfinden 
das beide, WR + DTU, im selben Channel zuhören/reden. Oder?

Gerade gefunden: 
https://hackaday.com/2017/03/21/ask-hackaday-frequency-hopping-on-the-nrf24l01/

https://paulplusx.wordpress.com/2017/03/19/frequency-hopping-with-nrf24l01/

[Christian P. (pocki)]

Daniel R. schrieb:
> Hmm, soviele retransmissions macht doch kein Sinn?
>
> Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu
> schalten, damit man mehrere Kanäle sich anhört.

Ich habe 2 NRF-Module: eines am GPIO eines Raspberry zum Versenden und 
eines an einem Arduino-Nano zum Sniffen. Der liefert via serial an den 
gleichen Raspi ab, wo ich dann auf die Empfängeradresse filtere.

Die 15 Retramsmissions alle 250µs sind im Python-Initscript fix drinnen, 
habe es nicht geschafft das zu reduzieren. Die macht er, weil der WR ja 
kein ACK sendet.
Das 4x-Senden in 500ms Abständen loope ich bewusst, damit ich sicher 
gehen kann, dass es der WR auch gehört hat und nicht antworten will.

Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch. 
Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen, 
also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende. 
Hoffe nur wir können dann etwas beobachten.

[Daniel R. (daniel92)]

Alles klar, danke für die Arbeit.
Wichtig natührlich alles fleißig zu loggen... :D

[Christian P. (pocki)]

Ich bin noch skeptisch, ob uns das weiterbringt.
Bis jetzt habe ich ausnahmslos nur "gespiegelte" Antworten gesehen, also 
egal welcher MID oder CMD: es kam immer genau die selbe Nachricht 
retour, nur mit der anderen Seriennummer. Sonst: gleicher Inhalt, 
gleiche Länge.

Kann also sein, dass wir ohne Kenntniss des *echten 
Einrichtungs-Dialogs* zwischen einer DTU und einem MI-WR nicht 
weiterkommen.

[martin (Gast)]

Christian P. schrieb:
>> isnoAhoy schrieb:
>>> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic
>>> Analyzer ausprobieren und mitschneiden ?
>>
>> Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.

Hallo,
ich konnte zwischenzeitlich mal ein paar Captures aufnehmen.
In Capture0 und 1 habe ich mich per App mit der DTU verbunden (die baut 
ja ihr eigenes WLAN auf) und dann auf "Inverter Hinzufügen und 
Automatische Suche" geklickt. In Capture2 habe ich mal die 
Echtzeitdatenabfrage laufen lassen (Zeigt die Istwerte auf dem 
Inverter).

Habe heute leider keine Zeit mehr, die Daten aufzubereiten, daher die 
Rohausgabe als .txt und die Logic-Captures direkt mit im Anhang, für 
eure eigenen Analysen (Saleae Logic-Software kann man kostenlos 
runterladen und die Captures öffnen).

Zur Info nochmal:
Inverter 1141 72220200
DTU Lite 10D9 72818832

[Christian P. (pocki)]

Danke, mir fällt insbesonders alles ausser mid=15 und =95 auf auf:

capture_1.txt
7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 
0a,8d,7f
7e,81,72,81,88,32,72,81,88,32,00,81,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,81,72,81,88,32,72,81,88,32,01,80,7f
7e,06,72,22,02,00,72,22,02,00,00,06,7f
7e,06,72,22,02,00,72,22,02,00,00,06,7f
7e,01,72,81,88,32,72,81,88,32,00,01,7f
7e,01,72,81,88,32,72,81,88,32,01,00,7f
7e,02,72,22,02,00,72,22,02,00,00,02,7f

Verstehe ich das korrekt: das sind die Daten von "on-wire" zwischen dem 
Onboard-Chip und dem NRF24-Modul der DTU? Weil: leider kann man da nicht 
klar herauslesen, an selche destination-address das nrf24-paket dann 
geschickt wird. Oder?

[martin (Gast)]

Christian P. schrieb:
> das sind die Daten von "on-wire" zwischen dem
> Onboard-Chip und dem NRF24-Modul der DTU?

Ja genau, auf der UART zwischen GD32 und NRF24.
Um die Richtung zu erkennen habe ich die Saleae-Files mit hochgeladen.
Dort kann man anhand des Kanals erkennen, ob es der DTU-Controller an 
den NRF schickt (sprich: die DTU an den Inverter) oder ob es vom 
Inverter zurückkommt.

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Daniel R. schrieb:
.....
> Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch.
> Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen,
> also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende.
> Hoffe nur wir können dann etwas beobachten.

Habe schon vor 2 Monaten ausprobiert, bei mir kam nichts...
Ich habe mehrere logs vom MI1500 hier veröffentlicht

[isnoAhoy (Gast)]

Christian P.,
ja die Salea Captures haben noch en 0x7e Prefix und Postfix 0x7f 
vor/nach den uns sonst geläufigen Nachrichten / Paketen.

7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 
0a,8d,7f
ist also eigentlich
MID=0x86
Destination=72220200
Source/DTU=72220200
Paket/CMD=0x02
Payload=11,41,72,22,02,00,00,b0,00,00,00,b0,01,0a
CRC8=0x8d

Ich sehe da also zwei Addressen:
* 72220200
* 72818832
Vielleicht sind die im capture1.txt genannten Adressen ja so eine Art 
Broadcast Adresse für die jeweiligen Modellreihen ?

Interessant dürften für die MI Wechselrichter in der Tat die MIDs außer 
0x15 und 0x95 der HM Baureihen sein: Speziell 0xc2 und 0x06 stechen mir 
ins Auge, ich meine so etwas auch in Ziyat T. bzw. Arnaldos Logfiles 
bereits gesehen zu haben.

[isnoAhoy (Gast)]

Hallo martin (Gast),
Danke für die Aufnahmen!

Hast Du die Aufnahmen während des Tages gemacht, d.h. dabei war ein WR 
anwesend und hat geantwortet.
Interessant wäre ja auch das Verhalten der DTU in einer abgeschirmten 
Umgebung.
Hier sollte die DTU ja prinzipiell einmal alle Discovery Optionen 
ausspielen, die ggf. auch eine MI-Wechselrichter interessieren könnten.

In der Payload steht ja eine HM-600/700/800 Serien Nummer: 114172220200
Damit hat die DTU wohl einen jungen Fisch gefangen ?

[isnoAhoy (Gast)]

Noch eine (Broadcast) Adresse 10,d9,42,7f ?

grep '^7e' capture0.txt | less
/(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83)

bzw.

grep '^7e' capture0.txt | grep -v '72,22,02,00' | less
/(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83)

um den ganzen Smalltalk mit 114172220200 auszufiltern ergibt:

7e,81,72,81,88,32,72,81,88,32,00,81,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,c2,72,81,88,32,10,d9,42,7f
7e,81,72,81,88,32,72,81,88,32,01,80,7f
7e,01,72,81,88,32,72,81,88,32,00,01,7f
7e,01,72,81,88,32,72,81,88,32,01,00,7f

[Ziyat T. (toe_c)]

Hallo
im Anhang sind die wireshark logs zwischen DTU-Pro und MI1500 mit 
versch. channels.
Hatte sie mit NRF24_Sniff von Ivo Pullens generiert.
Adr:1284..DTU, 6071..MI, Adr sind verkehrt!

z.Bsp: im NRF24_Sniff die DTU Adresse eingegeben, auf CH3, das ist die 
Antwort vom WR, ist von mir entschlüsselt, siehe früheren Beitrag:
ch3-2-12842272.pcapng
b6:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 
05:05:b1
b8:63:70:71:60:63:70:71:60:01:bb:00:0c:09:86:13:87:02:23:01:da:01:16:03: 
00:01:fa
b7:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 
05:05:b0
b9:63:70:71:60:63:70:71:60:01:bb:00:06:09:85:13:87:01:2b:01:3f:01:16:03: 
00:01:1c

im NRF24_Sniff die WR Adresse eingegeben, auf CH23:
ch23-60717063.pcapng
51:63:70:71:60:72:22:84:12:5a:5a:1a:8f
51:63:70:71:60:72:22:84:12:5a:5a:1a:8f
51:63:70:71:60:72:22:84:12:5a:5a:0b:9e


36:63:70:71:60:72:22:84:12:00:f2
37:63:70:71:60:72:22:84:12:00:f3
38:63:70:71:60:72:22:84:12:00:fc
39:63:70:71:60:72:22:84:12:00:fd



Villeicht hilfts euch weiter.

[Jan-Jonas S. (janjonas_s)]

Ich habe heute mal die c2 und 81 er Payloads bei mir in die Luft 
geworfen und von meinem HM600 keine Reaktion bekommen. Die Frage ist 
natürlich, ob die Dinge wirklich on-air gehen oder nur setup-commands an 
das NRF-Modul sind?

Christian P. schrieb:
> MID+  dtu   +   wr   +CMD+crc
> zb 07 77665544 61401913 81 aa

Damit hast Du ja nur ein Re-Transmit angefordert(?).
So einfach ist das nicht mit durch iterieren, weil viele Anfragen 
einfach eine definierte payload mit Parametern erwarten.

Interessant ist eigentlich nach jedem Kommando mal ein 80 11 abzufragen 
(event log). Das wird bestimmt überlaufen mit a_code=2, was ich denke 
wird soviel sagen wie Software-Fehler, Parameter-Fehler oder 
Kommunikationsfehler (Spekulation)

Leider scheint im Dump auch die Anfrage auf die Antwort mit der 
Seriennummer zu fehlen.

[Christian P. (pocki)]

Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das 
Shockburst-Frame des nrf24-Protololls gesendet wird?

Wenn die Daten ein Dump aus der internen DTU-Schnittstelle zum
nrf24-Modul sind, zeigen die ja nur (?) den Payload oder?

Oder steuert das erste Feld (MID) das Verhalten des nrf24 hinsichtlich 
Destination-Adresse/Adresslänge/ShockburstOnOff?

Hat sonst noch jemand captures von on-air Daten?

[Friedhelm E. (fritsche)]

Hallo Hubi(Gast)
Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme 
aber beim kompilieren folgende Fehlermeldung:
In file included from 
/home/papalapap/Arduino/HoyDtuSim/HoyDtuSim.ino:86:
/home/papalapap/Arduino/HoyDtuSim/ModWebserver.h: In function 'void 
handleRoot()':
ModWebserver.h:55:33: error: 'getSerialNoTxt' was not declared in this 
scope
   55 |     out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";
      |                                 ^~~~~~~~~~~~~~
exit status 1
'getSerialNoTxt' was not declared in this scope

Vielleicht sagt dir die Fehlermeldung in der ModWebserver.h etwas.
Wünsche frohe Pfingsten

Arduino: 1.8.19 (Linux), Board: "LOLIN(WEMOS) D1 R2 & mini, 160 MHz, 
Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most 
compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for 
IRAM/PROGMEM, 4MB (FS:1MB OTA:~1019KB), v2 Lower Memory, Serial, None, 
All Flash Contents, 921600"

[Ziyat T. (toe_c)]

DTU-Pro <-> MI1500 logs

WR -> DTU
----------
len } 2a:
hdr } 2c:67:b7:0f:00:63:70:71:60: 63:70:71:60:
data} 
01:b2:00:0f:09:22:13:89:02:77:01:02:01:b7:03:00:03:74:48:9e:3e:aa:77:de: 
ab:ec:b6:a6:40:
U DC    I DC    U AC    Hz AC    P DC        C
1  b2  0  0f  9  22  13  89  2  77  1  2  1  b7


DTU -> WR
---------
16: d4:cf:21:0f:00:63:70:71:60: 72:22:84:12:5a:5a:1b:8e:ee:12:3d:b6:08

[Jan-Jonas S. (janjonas_s)]

Christian P. schrieb:
> Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das
> Shockburst-Frame des nrf24-Protololls gesendet wird?

Die Richtung kann man nicht erkennen.
Aus beobachtungen weiß ich bisher, dass 0x15 dtu->wr und 0x95 die 
Antwort vom wr ist. Oder man kennt die Adressen seiner Geräte. 7e,7f 
markiert start und ende der spi-kommunikation in der dtu. Das geht nicht 
on-air.

0xc2 und 0x81 sind neu für mich und enthalten z.T. keinen gewöhnlichen 
ESB-Aufbau. Vermutlich könnte es also sein, dass die dtu da den nrf-chip 
konfiguriert oder status register abfragt. (Spekulation)
Könnte aber auch genauso gut sein, dass 0xc2 Übertragungsart ist, 
broadcast vs. 0x15 unicast?

[Tobi D. (tobidd)]

ich habe meinen HM-400 heute endlich in Betrieb nehmen können. Der WR 
läuft und produziert auch,aber ich bekomme mit meinem WemosD1 und dem 
NRF Modul leider keinerlei Rückemeldungen vom WR.

Uptime: 0 Tage, 00:54:20
Time: 2022-06-05 14:09:30
Statistics:
Receive success: 0
Receive fail: 652
Send Cnt: 1304
Free Heap: 0x98c8
Inverter 'HM-400' is not available and is not producing
MQTT: connected

Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die 
Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu 
haben.

im seriellen log steht folgendes:

Free heap: 0x9fb0
Inverter #0 no Payload received!
Requesting Inverter SN 1121xxxxxxxx
Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 
05 00 00 00 00 B0 39 B9
Error while retrieving data: last frame missing: Request Retransmit
Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 
05 00 00 00 00 B0 39 B9
Free heap: 0x9fb0
Inverter #0 no Payload received!
Requesting Inverter SN 1121xxxxxxxx

Version nutze ich die aktuelle 0.4.15

[Jan-Jonas S. (janjonas_s)]

Hast Du einen Kondensator an VCC vom NRF-Modul? Wichtig.
Manchmal hilft, die Sendeleistung von der "DTU" zu ändern. Habe das 
schon gehabt, dass WR nicht antworten, wenn man die zu laut fragt.
Auch die Ausrichtung der Antenne kann Wunder wirken.

[Tobi D. (tobidd)]

ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe 
ich auch alle low, min, high und max probiert.

genauso wie die entfernung zwischen paar cm und einigen metern geändert 
wurde

[Ziyat T. (toe_c)]

Mehr DTU-Pro <-> MI1500 logs
Diesmal WR ist stumm, weil Nacht, DTU-Pro neu gestartet

[Lukas P. (lumapu)]

Tobi D. schrieb:
> Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die
> Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu
> haben.

Seriennummer muss so eingetragen werden, wie sie auf dem Aufkleber zu 
lesen ist.
Hast du mal mit der Ausrichtung der Antenne gespielt? Stimmt dein 
Pinout, vor allem der IRQ Pin darf nicht auf GPIO16 liegen?

[Hubi (Gast)]

Friedhelm E. schrieb:
> Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme
> aber beim kompilieren folgende Fehlermeldung:
> In file included from

Hallo Friedhelm
hol dir die neueste Version von 
[[https://github.com/hm-soft/Hoymiles-DTU-Simulation]], das sollte 
klappen

[rosch99 (Gast)]

Tobi D. schrieb:
> ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe
> ich auch alle low, min, high und max probiert.

Viele der NRF-Module haben geclonte Chips, manche funktionieren besser, 
manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit 
ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht 
funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne 
auf der Platine bestellt, die funktionieren problemlos.

rosch99

[Daniel M. (daniel_m821)]

Der Tip mit den Modulen mit Antenne, die irgendwie nicht so ganz laufen, 
war gut.

Ardunio-Konsole:

14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB 
14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB 
14:40:00.684 -> Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 4A 00 11 09 5F 13 85 02 2D 03 61 00 F2 AC
14:42:57.596 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4 
14:42:57.644 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4

Hauptsächlich jedoch kommt diese Meldung:

14:43:00.590 -> Error while retrieving data: last frame missing: Request Retransmit

Das passiert fast immer, wenn vom WR eine Antwort eingeht.

Raspi mit ahoy python-tool:

2022-06-06 14:43:06.908846 Received 24 bytes channel 23: 89 63 50 0b 16 e3 50 0b 16 81 4a 40 17 09 5b 53 88 82 dc 0b 64 80 f2 d3
Error while retrieving data: max() arg is an empty sequence

2022-06-06 14:43:13.198405 Received 24 bytes channel 75: 8b 63 50 03 16 63 51 0b 56 95 5a 09 53 19 5b 33 8a 92 de 0b 6c 91 f6 d1
Error while retrieving data: Frame 1 missing: Request Retransmit

2022-06-06 14:49:57.395157 Received 18 bytes channel 61: 88 63 50 03 16 63 50 13 16 00 03 00 80 08 01 00 03 89
2022-06-06 14:49:57.401382 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:50:01.087613 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56
2022-06-06 14:50:01.098937 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:50:02.584152 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 3

2022-06-06 14:52:42.631804 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 13 86 01 c4 03 6d 00 f6 55
2022-06-06 14:52:42.643443 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 53 86 05 c5 03 6d 01 f6 55
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:52:44.136428 Received 18 bytes channel 40: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 3

2022-06-06 14:52:46.298238 Received 24 bytes channel 75: 91 63 50 03 16 63 50 03 16 01 47 00 0e 09 58 13 86 01 c1 03 67 00 f6 4f
Error while retrieving data: Missing packet: Last packet 1

2022-06-06 14:52:47.289513 Received 18 bytes channel 3: 94 63 50 02 16 63 50 02 16 00 03 00 00 00 00 00 00 91
Error while retrieving data: Missing packet: Last packet 2

2022-06-06 14:52:47.851089 Received 18 bytes channel 40: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 01 00 03 89
Error while retrieving data: Missing packet: Last packet 3

2022-06-06 14:56:22.534647 Received 18 bytes channel 3: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91

Der Raspi empfängt etwas alle ca. 30s, wenn die DTU die Requests sendet.
Den Tx hab ich rausgelassen, da wir wissen, dass mein WR nicht darauf 
reagiert.

Ich hab aus dem Log von Raspi mal diese größeren Abschnitte mit nur Tx 
gelöscht.

Ich bin mit Arduino und C++ nicht wirklich gut unterwegs und brauche 
Starthilfe, an welchen Stellen die Sendebefehle wie zusammengebaut 
werden.

Mein Tsun hat 2 Kanäle, füge ich ihn über 1141 statt 1041 hinzu, 
funktioniert das schonmal :)

[Jan-Jonas S. (janjonas_s)]

Das Python-Script wird damit auch nichts automatisch dekodieren können, 
weil für die Wahl des Dekoders die Anfrage ausschlaggebend ist, die 
python selbst abgesetzt hat.

Du kannst höchstens manuell den Datenstrom aufzeichnen, zusammensetzen 
und einen Dekoder dafür in Python bauen und das dann copy&pasta mit 
bytes.fromhex() da durch schieben. Das geht tatsächlich sehr gut und man 
kann dann auch schön am Dekoder rum tweaken bis die Ergebnisse sinnvoll 
sind. Beispiele habe ich ja schonmal gepostet.

Bis die gesamte Transaktion implementiert ist, wird das mit dem 
python-Script, automatisch, keine Daten dekodieren können ohne den Tx 1. 
zu haben und 2. sinnvoll verstanden zu haben. Also aus dem Tx muss man 
erkennen können welche Daten angefragt wurden.

Theoretisch könnte die DTU ja auch gerade ein Firmware-Update hochladen. 
Die Fragmente der Transaktion kann man schon durch einen Status-Dekoder 
schieben, bekommt dann aber keine sinnvollen Werte. Der Dekoder wird 
schon dekodieren. Der kann nicht erkennen ob das sinnvoll ist oder 
nicht, oder ob er für die Daten die man ihm gibt überhaupt geeignet ist. 
Zumindest solange der buffer groß genug ist und man nicht in einen 
IndexError läuft.

Du bekommst da zwar Daten aber ohne Kontext. Binärdaten ohne Kontext 
sind nicht mehr als Rauschen.

[Daniel M. (daniel_m821)]

Hi Jan,

aktuell zeichne ich einfach auf, was durch die Luft fliegt.
Die Requests habe ich da, kann sie nur nicht senden, allerdings macht 
das, was ich so empfange Sinn zu dem, was ich in der DTU sehe.
Die bytes kann ich soweit dekodieren und nachvollziehen, nutze das eher 
als sniffer, den ich bedienen kann.
Dass ich mit dem Python-Script nicht viel weiter komme, ist mir klar :)
Leider bin ich nicht so tief in der Programmierung drin, wie einige 
andere hier, so dass ich sehr froh bin, die Scripte soweit überhaupt hab 
starten können und ihnen was sinnvolles entlocken konnte.

Primäres Ziel war erstmal:
 - funktionieren die NRF-Platinen? -> mit externer Antenne nicht, 
integriert ja
 - auf welchen Kanälen wird empfangen? -> 3, 23, 40, 61, 75
 - ist das, was ich empfange, sinnvoll? -> weitestgehend ja
 - kriege ich es hin, mit dem D1 mini was zu sehen? -> nur zufällig, 
eher nein

Beim rumschnüffeln in der Luft hab ich noch 2-4 byte lange Antworten 
gesehen sowie solche Konstrukte:

channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d fa 01 3a 33
channel 40: b2 6b 50 03 16 63 50 07 16 00 03 00 00 02 00 20 02 91
channel 23: a8 6b 50 03 36 63 50 03 16 00 13 00 00 0a d7 26 af bb
channel 3: a9 63 50 03 16 63 50 07 16 01 35 00 04 09 4a 13 8a 00 8e 85 03 01 3a d0
channel 3: b2 63 50 03 36 63 50 03 16 00 13 01 00 00 00 80 08 93 c3 93 3a aa
channel 3: 94 63 50 03 16 63 50 03 14 00 43 00 00 00 10 00 01 91
channel 3: 8b 63 50 03 16 63 51 03 16 01 2e 00 02 09 51 13 8e 80 51 05 04 01 2b 1b

Was es damit aufsich hat, schau ich mir später noch an, da es 
wiederkehrende Muster aller paar Minuten sind.

Ohne Hilfe beim Code werd ich aber nicht viel machen können, da mir 
einfach die Grundlagen fehlen. Ich komme aus dem Dickstrombereich, das 
hier ist Hobby ;)

Deine Beispiele sehen gut aus, hab die versucht und bin (erstmal) 
gescheitert. Ich werd meine Freundin mal fragen, ob die damit weiter 
kommt. Wird aber etwas dauern. Trotzdem danke für den Ansatz, mit Geduld 
wirds werden :)

[Jan-Jonas S. (janjonas_s)]

Ich hab gerade nochmal ein PR für python auf gemacht. Habe den 
DebugDecodeAny Dekoder nochmal überarbeitet.

Beispiel: (auf der Kommandozeile)

tools/rpi$ python3 -c 'import hoymiles; hoymiles.decoders.DebugDecodeAny(bytes.fromhex("5c 00 00 b4 91 00 00 ab bf 03 71 03 78"))'
 payload has 13 bytes

Field view: int
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12
Hex       5c    00    00    b4    91    00    00    ab    bf    03    71    03    78
>B        92     0     0   180   145     0     0   171   191     3   113     3   120

Field view: shorts
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12
Hex       5c    00    00    b4    91    00    00    ab    bf    03    71    03    78
>H           23552         180       37120         171       48899       28931
>H                     0       46225           0       43967         881         888

Field view: longs
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12
Hex       5c    00    00    b4    91    00    00    ab    bf    03    71    03    78
>L                  1543504052              2432696491              3204673795
>L                             46225                   43967                57738104
>L                                11833600                11255555
>L                                    3029401600              2881422193
 type utf-8  : utf-8 decode error
 type ascii  : ascii decode error

*payload gekürzt, weil dieses dämliche Forum Zeilenumbrüche in Code, und 
damit Leserlichkeit kaputt macht.
Würde die komplette Payload in die DebugDecodeAny-Klasse gepastet werden 
würde es uns noch sagen, dass sich um die Payload eine valide Modbus CRC 
(oder CRC8) befindet.

Referenz:

2022-05-10 11:39:49.447628 Payload: 00 01 01 35 03 a8 0b 4a 01 37 03 aa 0b 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 09 08 13 87 15 a1 00 00 00 ef 03 e8 01 ef 00 06 99 3a
2022-05-10 11:39:49.447628 Decoded: 49.5 phase0=voltage:231.2, current:23.9, power:553.7, frequency:49.99 string0=voltage:30.9, current:9.36, power:289.0, total:46.225, daily:881 string1=voltage:31.1, current:9.38, power:290.8, total:43.967, daily:888

Wir finden aber Zahlen wieder und sehen schön an welcher Position in den 
Hex-Daten die stehen.

Meiner Meinung nach sind in den tsun-Daten viele korrupte Pakete mit 
Bitfehlern drin. Die Payload CRC8 stimmt oft nicht. Manchmal auch 
offensichtlich durch korrumpierte Adresse. Nicht, dass wir da jetzt 
Unsinn lernen. Grundsätzlich würde ich das auf der Luft-Schnittstelle 
aber erwarten, da wir das Protokoll nicht implementiert haben.

[Ziyat T. (toe_c)]

@Daniel M. schrieb:
@Jan-Jonas S
> Hi Jan,
>
> aktuell zeichne ich einfach auf, was durch die Luft fliegt.

Hallo
Die Antwort
channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d 
fa 01 3a 33
Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert. 
D.h. dieser TSUN ist ein MI?
Konntest du schon einen request schicken und TSUN hat geantwortet?

[Christian P. (pocki)]

Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu 
bekommen. Wie habt ihr das gemacht (ohne eine DTU)?

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu
> bekommen. Wie habt ihr das gemacht (ohne eine DTU)?

Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine 
Logs v. früher.
Ich sehe die WR-Antworten nur wenn meine DTU-Pro die request schickt.
Ich glaube, ich habe alle logs zusammen, WR-Antworten decodiert aber wie 
die request funktioniert hab nicht rausgefunden.

[Christian P. (pocki)]

Ziyat T. schrieb:
> Christian P. schrieb:
>> Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu
>> bekommen. Wie habt ihr das gemacht (ohne eine DTU)?
>
> Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine
> Logs v. früher.

Ja das las ich, ist also immer noch stand der Dinge wie es scheint :(

Ich bin nur auf Funk-Ebene unterwegs, also versuche die Messages einer 
DTU mit einem nrf24-Modul nachzumachen, um die Funk-Antworten meines WR 
zu erhalten. Dabei fiel mir auf:

Der WR antwortet NUR, wenn das nrf-paket im Funkheader die Zieladresse 
des WR hat (also SN=102161401913 -> Zieladresse 13:19:40:61:01 mit Länge 
5). Das wäre die Unicast-Variante. Ich konnte keine 
Broadcast-Empfangsadresse für den WR hier im Forum bislang ausmachen, 
auch nicht anhand der jüngsten Logs zu "automatische Suche". Sowas 
könnte eine 2-5 bytige Addresse sein, auf die jeder WR in der zweiten 
Pipe lauscht.

Außerdem: Die bekannten Payloads dokumentieren immer nach dem MID die 
S/N der DTU und danach die S/N des WR. Bei mir ist das umgekehrt! Der WR 
antwortet auf die Anfragen immer an jene Adresse, welche der ERSTEN S/N 
in der Payload entspricht. Das würde für mich bedeuten: die erste S/N 
der Payload sollte die DTU sein, an die deer WR seine Antwort 
adressiert.
Die bislang dokumentierte Payload stellt aber als erstes die S/N des WR 
dar, und erst danach die S/N der DTU.

Kann das jemand bestätigen?

[Christian P. (pocki)]

Also so:

python3 py-nrf24/send.py --crc 1 1319406101 15776655446140191381
..sendet die payload 15776655446140191381+crc8 an 13:.19:40:61:01 
77665544 ist die erfundene SN meines Raspi
61401913 ist die echte SN meines WR.

Sent: to Address 1319406101 Data 15 77665544 88776655 81 58
Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf

Das geht auch ohne der S/N des WR in der Anfrage
python3 py-nrf24/send.py --crc 1 1319406101 15776655440000000081

Sent: to Address 1319406101 Data 15 77665544 00000000 81 94
Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf

Ergo:
1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed, 
0x01 als 5. byte).
2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5, 
reveresed mit 0x01 ergänzt
3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload
4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 
und 0x7f beginnen.

[Christian P. (pocki)]

Habe was neues gefunden:

         nrf24-dest      pcf     payload
anfrage: 13 19 40 61 01 (16/0/0) df 02 00 776655441111111100fcaf85 0b
antwort: 13 19 40 61 01 (16/3/0) df 02 00 776661401913111100fcaf85 31

der Payload-Anfang df0200 bewirkt, dass der WR die Antwort-Adresse 
irgendwie ändert. Hier am Beispiel sendet er nicht an die DTU laut SN in 
den bytes 2.. retour, sondern an sich selbst?! Nachgefolgde MDI=15 
anfragen werden ebenfalls an diese Andresse dann beantwortet.

Ich hoffe ich habe mir nun nichts zerschossen. Scheinbar aber bewirkt 
der PRefix df0200 aber mal was anderes als nur MID=15.

[Tobi D. (tobidd)]

rosch99 schrieb:
> Tobi D. schrieb:
>> ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe
>> ich auch alle low, min, high und max probiert.
>
> Viele der NRF-Module haben geclonte Chips, manche funktionieren besser,
> manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit
> ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht
> funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne
> auf der Platine bestellt, die funktionieren problemlos.
>
> rosch99

hab mir jetzt auch noch ein nrf modul bei az del. ohne externe antenne 
bestellt, leider auch keine besserung

[Ziyat T. (toe_c)]

Christian P. schrieb:

> 1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed,
> 0x01 als 5. byte).
> 2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5,
> reveresed mit 0x01 ergänzt
> 3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload
> 4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00
> und 0x7f beginnen.

interresant, bei mir sieht es ganz anders aus..

[Christian P. (pocki)]

Ziyat T. schrieb:
> interresant, bei mir sieht es ganz anders aus..

naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit 
Schluss sind.

Ich habe inzwischen folgendes nachstellen können.

sende    15:77665544:22222222:80 an WR
empfange 15:77665544:61401913:80 als Antwort an Adresse 44:55:66:77:01
10sek pause
sende    df0200:7766 55443333 3333:00 an WR
empange  df0200:7766:61401913:333300 als Antwort an Adresse 22:22:22:22

Bei der ersten Nachricht setze ich im WR eine DTU-Adresse, die sich der 
WR merkt.
Bei der zweiten Nachricht verwendet der WR die DTU-Adresse von zuvor und 
überschriebt nur die Bytes 4..7 mit der eigenen SN.


> Christian P. schrieb:
>>4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00
>> und 0x7f beginnen.

ich revidiere, punkt 4 stimmt nicht

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ziyat T. schrieb:
>> interresant, bei mir sieht es ganz anders aus..
>
> naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit
> Schluss sind.

Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die 
Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du?
Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die 
gleiche SW verwenden würden, kommen wir ev. besser vorwaerts.

[Olaf A. (Gast)]

Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ 
und CE zu tauschen.

[IsnoAhoy (Gast)]

@Tobi B.
Beschreibe mal Deine Schaltung bzw. Überprüfe ob es evtl wie von Olaf 
geschrieben am IRQ Eingang liegt. Nicht alle Pins am ESP sind 
Interruptfähig.
Laut Deinem Log hat Dein HM-400 folgende Seriennummer:

> Inverter SN 1121xxxxxxxx Transmit 27 | 15 80 13 52 94

112180135294 stimmt das ?

Ich sehe in Deinem „kurzen“ Log nämlich nur TX aber kein einziges RX 
Paket. D.h. dein ESP und nRF24 scheinen zu senden, aber der HM-400 fühlt 
sich offenbar nicht angesprochen.

Alternativ kannst Du gerne auch mal ein längeres Log anhängen, 
vielleicht sieht man da mehr. Nach dem Booten sollte der ESP auch einen 
Block mit den nRF24 Settings ausgeben, etc pp.

[IsnoAhoy (Gast)]

@Daniel M. und Freundin, Ziyat T.,
Das sieht doch schon ganz vielversprechend aus. Ich meine auch das mit 
den „reversed“ 5 Byte (das letzte 01) bei der MI- Baureihe am Anfang des 
Threads gelesen zu haben. Habe mich immer gewundert, dass die HM- 
Baureihe die Seriennummer in der richtigen Reihenfolge und mit nur 4 
Byte annimmt. Da scheint es wohl einen Unterschied zu geben.
Viel Erfolg weiterhin!

[Tobi D. (tobidd)]

Olaf A. schrieb:
> Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ
> und CE zu tauschen.

das hats gebracht, vielen dank für den tipp :)

[Christian P. (pocki)]

Ziyat T. schrieb:
> Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die
> Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du?
> Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die
> gleiche SW verwenden würden, kommen wir ev. besser vorwaerts.

Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+ 
modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und 
bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit 
sehe ich alle pakete (inkl. der destination adresse).
Quelle des sketch kann ich nimmer sagen: habe ich Sept. 2020 
organisiert, Author ist J. Coliz inspired by cpixip.
Diesen Sketch habe ich etwas modifiziert, damit das 9bit PCF als 3 
dezimale angezeigt wird und alles danach um das 1 Bit verschoben ist: so 
kann man viel leichter die Payload erkennen.
Ergänzend habe ich ein Skript gebaut, dass die CRC des nrf24-Pakets 
prüft, so kann ich leichter die Noise aus dem gesnifften Kauderwelsch 
rausfiltern und es bleiben nur "echte" Pakete übrig.

Zum Senden nutze ich einen Raspberry Pi 2B mit einem nrf24+ Modul an den 
GPIO Pins. Software ist von https://github.com/bjarne-hansen/py-nrf24 
mit kleinen Modifikationen, um z.B. einen crc8 automatisch anzufügen.

Ich sende und sniffe nur auf CH 0x03.

[Daniel R. (daniel92)]

Hallo zusammen,

ich bin aktuell ein stiller leser geworden.
Habe aber folgende Infos mitbekommen (speziell für die MI-WR) und denke 
das es hier noch nicht im Forum diskutiert wurde?

In dieser PDF Seite 8, sieht man die ältere Generation der DTU.
https://cdn.webshopapp.com/shops/296982/files/328732372/mi-500-mi-600-mi-700-microinverter-user-manual-rev.pdf

Das müsste genauer gesagt diese DTU sein: 
https://loja.opussolar.com.br/produto/transmissor-dados-hoymiles-dtu-mi/

Und hier sieht man eine DTU mit S.Nr.(10F052403668) aufgeklebt: 
https://ae01.alicdn.com/kf/H91aaca10736b4450a21891509dfeb934v.png

Mit der Info will ich nur aussagen, dass die MI-WR die S.Nr. von der 
alten DTU wahrscheinlich hören wollen. Wie Olaf schon die Erkenntnis 
hatte, kann man nicht jede DTU mit jeden WR kommunizieren. :)

Olaf A. schrieb:
> *Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann
> nur mit dem neuen Gateway von
> Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100
> ( Seriennummer: 10D2xxxxxxxx) und
> DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren

Somit könnte man bei der Abfrage die DTU(alt), die S.Nr. 10F0xxxxxxxx 
hinterlegen.

@IsnoAhoy: Hier könnte man die Excel aktualisieren, oder?
https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx
Und wenn mein Gedanke richtig ist und das so auch funktioniert,... 
könnte man später im Code hinterlegen mit welcher DTU-S.Nr. die 
Kommunikation stattfinden soll.

Bsp:
HM-800  11417420xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx)
HM-1500 11616320xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx)
MI-1200 10616090xxyy => DTU-Alt? (10F0xxxxxxxx)

Gruß Daniel

[isnoAhoy (Gast)]

Hallo Olaf A. / Tobi D.,

danke für die positive Rückmeldung. Könnt Ihr bitte unter github oder 
hier Eure Verkabelung zwischen ESP (welches Modul) und dem nRF24 
Funkmodul dokumentieren bzw. mit der Verkabelung dort vergleichen ?
Danke!

ESP8266: Discussion Verkabelung / Pinout #36
https://github.com/grindylow/ahoy/issues/36

[Daniel R. (daniel92)]

Daniel R. schrieb:
> Hallo zusammen,

Nachtrag: Hier eine bessere Quelle:
https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt

[Frank (Gast)]

Daniel R. schrieb:
> Daniel R. schrieb:
>
>> Hallo zusammen,
>
> Nachtrag: Hier eine bessere Quelle:
> https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt

Quatsch mit Soße.

[Daniel R. (daniel92)]

Hallo Frank,

danke für die Ausführliche Rückmeldung. ;)
Die Quelle soll sich eher auf die DTU-MI (Bilder) beziehen.

Ich weiß ja nicht inwieweit es "Quatsch mit Soße" seien soll.
Lieber verweise ich auf die Quelle woher die S.Nr. stammt.

Schließlich ist doch jede Hilfe (auch wenn es nur eine S.Nr. ist) 
brauchbar.
Vielleicht könnte man die Daten aus dem MI-WR mithilfe dieser DTU S.Nr 
beziehen. Bisher wird meines wissens nach in der "hmRadio.h" mit einer 
festen S.Nr. vorgegaukelt welche DTU spricht.

Vielleicht macht es Sinn hier die ersten 4 stellen diese mit 
einzubeziehen.

So, erkläre mir jetzt mal wieso das Quatsch mit Soße ist!?

[Ziyat T. (toe_c)]

Christian P. schrieb:
>>>
> Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+
> modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und
> bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit
> sehe ich alle pakete (inkl. der destination adresse).
>>>>
Das ist interresant, habe wie gesagt bisher die aurduinoUno+nrf24 kombi 
und SW von Ivo Pullens verwendet.
Ich würde gerne mal deine aurduino Sketches ausprobieren um zu sehen ob 
ich die gleichen Daten sehe wie du, geht das?

[IsnoAhoy (Gast)]

Hallo Daniel R.,

ja das ist evtl ein interessanter Fakt, ich habe noch keine Rückmeldung 
von den anderen DTU Besitzern erhalten welches Prefix die denn haben, 
sonst könnte ich die Tabelle gerne mal ergänzen/aktualisieren. Ich habe 
schon ein paar zusätzliche Informationen gesammelt aber noch keine. 
commit gemacht.

@Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg 
wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer 
versendet ?

10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ?

@Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. 
Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf 
0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten 
auf dem Kanal 2403GHz.

@Oliver F. das wäre doch was für Deinen nRF24 hexa-Decker mit sechs nRF 
Modulen kannst Du dann senden und alle fünf Kanäle (2403-2475) 
mitschneiden.


Ebenfalls interessant ist mE die Beschreibung unter Seite 8 des von 
Daniel R. verlinkten „historischen“ Dokuments:

Fig.2. MI-500 /MI-600 /MI-700 Microinverter wiring diagram
Note 1: DTU connects the power production of each microinverter. If the 
asymmetry current is going to exceed 16 A, DTU will send stop signal to 
one or more microinverters to let the asymmetry current lower than 16A.

Das sind ja die Signale die uns noch fehlen, also wie kann die DTU die 
WR dazu bringen ihre Kanäle abzuschalten. Evtl. kann man mit diesem 
Wissen und einem regelbaren Netzteil am Eingang der WR eine DTU in den 
Panikmodus versetzen und die Nachricht abfangen ?

[Daniel R. (daniel92)]

Hallo IsnoAhoy;

IsnoAhoy schrieb:
> am Eingang der WR eine DTU in den
> Panikmodus versetzen

Das klingt an sich nicht schlecht, nur ist die Frage ob der Flag im 
Speicher vom WR sich automatisch zurücksetzen lässt (durch ein 
Neustart?).

Sonst bestünde die Gefahr das der WR für immer in dem Modus bleibt, 
außer man schickt den richtigen Befehl... wobei ich behaupte mal das die 
Entwickler hierfür bestimmt was vorgesehen haben.

Hier würde ich mal das ganze mit vorsicht "genießen".

[IsnoAhoy (Gast)]

Hallo Daniel R.
ich gehe mal davon aus, wenn die Differenz der Leistung wieder unter 16A 
fällt sollte eine ordentliche DTU das auch wiedee freischalten, das 
könnte man dann auch aufnehmen. Hattest Du nicht Deinen WR mangels 
Modulen noch am Labornetzteil ? Ich nehme an das bezieht sich auf 
mehrere WR in der auf Seite 8 beschriebenen Modul-Konfiguration.

[Daniel R. (daniel92)]

Genau, ich betreibe es aktuell am Labornetzteil.
Nur habe ich ein HM-1500. Mein Netzteil kommt an sein Limit. :(

Besitze nur einen mit 30V und knapp 10A.

[Christian P. (pocki)]

IsnoAhoy schrieb:
> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code.
> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf
> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten
> auf dem Kanal 2403GHz.

Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte 
konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und 
0x00AA.

Achtung: man kann hiermit keine längeren Payloads mitlesen, weil ja 
wegen der Empfangskonfig 6 Bytes und 1 Bit zu früh empfangen wird und 
deshalb die hinteren bis zu 7 Byte fehlen.

Ziel dieses Sniff-Methode ist es, die Destination-Adresse im 
nrf24-Header zu identifizieren. Wenn man die mal genauer weiß, kann man 
den nrf24 auf diese Adresse und Adresslänge konfigurieren und dann die 
ganze Payload über die herkömmliche (=designte) Methode empfangen.

Anbei der Sketch und die verwendete RF24 library.
Mit readserial.py hole ich mir den Output am Raspberry Pi herein.
Mit verifyserial.py filtere ich nach Paketen mit gültigem CRC. Aus 
Performancegründen nur Pakete mit 5stelliger Zieladresse. Das kann man 
in Zeile 59 auf range(0,3) setzen, um 2 bis 5 byte lange Adressen 
durchzuanalysieren.

Achtung: Payloads länger als 23 Byte oder 24 Byte könnten hier übersehen 
werden.

LG

[Daniel R. (daniel92)]

Hallo zusammen,

ich versuche gerade das NRF auf dem Raspi zum laufen zu bringen.
Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".

sudo python3 -um hoymiles --log-transactions --verbose --config /home/dtu/ahoy.yml | tee -a log2.log
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.7/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.7/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/home/Hoymiles_NRF24/hoymiles/__init__.py", line 14, in <module>
    from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
ImportError: /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: undefined symbol: _ZN4RF2410setPALevelEh

Ich habe wie in der Beschreibung auf Github alles Installiert und auch 
den Wrapper drauf gepackt. Ich musste vorher noch die Module crcmod & 
RF24 nach installieren.

Aber irgendwie hängt das ganze. :(
Raspberry Pi 4
Python 2.7.16
Python 3.7.3

PS: Bei Step 4 "nano gettingstarted.cpp", habe ich diesen Punkt einfach 
ohne Änderung weiter gemacht. Ist das falsch?

[Carsten B. (carstenb)]

Hallo in die Runde,

nachdem ich eine Weile nur selten mitlesen konnte, habe ich nun mein 
Setup wieder aktiviert. Diese Software 
https://github.com/hm-soft/Hoymiles-DTU-Simulation läuft auf einem 
Arduino Nano V3 zuverlässig und liefert an meinem HM600 Werte, die gut 
zu dem passen, was ich am Shelly mitlogge.

-----------------------
rcv CH:75 00 1234567801 00BE 17 3  95 72014650 72014650 830000000403E8012900163010E7B896 B896 1
Udc.CH1=29.4 V
Idc.CH1=0.14 A
Pdc.CH1=4.2 W
Udc.CH2=30.0 V
Idc.CH2=0.15 A
Pdc.CH2=4.6 W
E-Total.CH1=145.471 KWh
E-Total.CH2=146.316 KWh
E-Tag.CH1=1568 Wh
E-Tag.CH2=1610 Wh
Uac=233.6 V
Freq.ac=49.99 Hz
Pac=8.4 W
Ipv=0.04 A
WR-Temp=29.7 °C
Status=1000 
E-heute=3178 Wh
E-Total=291.787 KWh

Tagesproduktion heute lt. Shelly 3100Wh und Total 290 KWh

Klasse, wie gut das schon funktioniert :-)

Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem 
ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g. 
Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht 
kompatibel sind.

Hat jemand eine lauffähige Version für ESP32?

Viele Grüße

Carsten

[Ziyat T. (toe_c)]

Christian P. schrieb:
> IsnoAhoy schrieb:
>> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code.
>> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf
>> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten
>> auf dem Kanal 2403GHz.
>
> Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte
> konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und
> 0x00AA.
>>>>
Hallo Christian P.
Danke für die SW!
Habe gerade ausprobiert ohne was zu aendern, also als sniffer:
 WR ist im Schlaf , die DTU-Pro sendet/sucht.
Zuerst mal bin ich beruhigt, die Daten sind gleiche was ich auch schon 
mit "meiner" SW gesehen habe.
Siehe Anhang, du kannst es sicher besser interpretieren..
Was die DTU sendet ist dauernd: 00 f2 bis 00 fd

[Christian P. (pocki)]

> Was die DTU sendet ist dauernd: 00 f2 bis 00 fd

Das liest sich so:

60 71 70 63 01 (11/0/0) 38(63 70 71 60|72 22 84 12)00 fc[a4 bb]

Erste 5 Bytes: Adresse, an welche das nrf24 Paket geschickt wird. Nur 
nrf24 Module empfangen das, die nach Paketen an diese Adresse 
"lauschen".

(11/0/0) ist das decodierte 9bit PCF:
11=Länge der payload, 0=message counter, 0=noack-flag

Die payload ist also 0x38 bis 0xfc. Danach in der eckigen Klammer ist 
der crc16 vom nrf24 Protokoll.

Die Payload habe ich mit (|) versucht zu untergliedern: erstes Byte ist 
das MID (sofern das stimmt). Danach 4 Byte mit S/N des WR, dann 4 Byte 
mit S/N der DTU, dann der CMD 0x00, dann ein CRC8 über die vorangegangen 
Bytes der Payload.

Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden 
Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn 
der WR antwortet steht an genau dieser Stelle die S/N des WR.

Nun gilt es herauszufinden, wie man dem WR "programmiert", an welche 
Adresse er seine Antwortpakete senden soll. Ich habe das zuletzt 
geschafft indem ich ein Paket mit MID=15 und CMD=80 an den WR geschickt 
habe (Inhalt nach der Logik wie oben). Danach hat der WR einige Minuten 
lang alle seine Antworten an die gesetzte Adresse geschickt 8-)

Leider aber konnte ich weiterhin keine Stromdaten aus dem WR 
herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von 
deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die 
PV-Kanäle 36:1, 37:2, 38:3 und 39:4...?

[Daniel R. (daniel92)]

Hallo zusammen,

Daniel R. schrieb:
> Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".

Zu meinem obigen problem bin ich nicht weiter gekommen. Alles neu 
gemacht aber irgendwie hänge ich nun an dem Wrapper.

Nunja, wollte euch nur zum Thema "NRF24 kann nicht senden" noch 
Informieren das man die Platine einpacken soll. Siehe:
https://github.com/nRF24/RF24/blob/master/COMMON_ISSUES.md

Falls es jemand interessiert. :)

[Ziyat T. (toe_c)]

Christian P. schrieb:
>>>
Ach so, danke für die Erklaerung!

> Leider aber konnte ich weiterhin keine Stromdaten aus dem WR
> herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von
> deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die
> PV-Kanäle 36:1, 37:2, 38:3 und 39:4...?

Ich hatte mal früher schon mit MID=00bisFF und CMD=00bisFF alle 
Kombinationen erfolgslos versucht, aber hab vielleicht was falsch 
gemacht..
Jetzt bin gespannt, was bei dir rauskommt.

> Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden
> Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn
> der WR antwortet steht an genau dieser Stelle die S/N des WR.

Das ist genau so, imho bei allen DTU's

[Daniel R. (daniel92)]

Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden.

Handbuch: 
http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf

Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text

If the DTU cannot detect all the microinverters in the system over 30 minutes, please use manual mode instead.

Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping" 
aussendet und die WR darauf eine Rückantwort ausgeben.

Hier müsste es auch in der DTU-Pro diese Funktion geben.
Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon" 
auffangen und mit Implementieren (Feature).

------------------------

In diesem Beitrag von einem anderen Forum: 
https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840

Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann, 
ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :)

Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf...

Gruß

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden.
>
> Handbuch:
> 
http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf
>
> Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text
>

If the DTU cannot detect all the microinverters in the system over 
> 30 minutes, please use manual mode instead.

> Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping"
> aussendet und die WR darauf eine Rückantwort ausgeben.
>
> Hier müsste es auch in der DTU-Pro diese Funktion geben.
> Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon"
> auffangen und mit Implementieren (Feature).
>

Das ist ein altes Manual. Bei meiner DTU-Pro geht das nicht mit dem 
MI-WR, man muss ihn zuerst in der APP/Cloud angeben

>
> In diesem Beitrag von einem anderen Forum:
> 
https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840
>
> Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann,
> ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :)
>
> Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf...
>
> Gruß

Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache 
seit einem Jahr per Modbus den zero export.
Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine 
früheren Beitraege hier...

[Ziyat T. (toe_c)]

@Christian P.
Anfrage DTU-Pro:
PV1: ...36(63 70 71 60|72 22 84 12)00
PV2: ...37(63 70 71 60|72 22 84 12)00
PV3: ...38(63 70 71 60|72 22 84 12)00
PV4: ...39(63 70 71 60|72 22 84 12)00

Anworten vom MI-WR:

PV1: ...b6(63 70 71 60|63 70 71 60)data
PV2: ...b7(63 70 71 60|63 70 71 60)data
PV3: ...b8(63 70 71 60|63 70 71 60)data
PV4: ...b9(63 70 71 60|63 70 71 60)data

36 00110110
b6 10110110   bit8 gesetzt

37 00110111
b7 10110111   bit8 gesetzt

;-)

[Christian P. (pocki)]

Ziyat T. schrieb:
> @Christian P.
> Anfrage DTU-Pro:
> PV1: ...36(63 70 71 60|72 22 84 12)00
> PV2: ...37(63 70 71 60|72 22 84 12)00
> PV3: ...38(63 70 71 60|72 22 84 12)00
> PV4: ...39(63 70 71 60|72 22 84 12)00
>
> Anworten vom MI-WR:
>
> PV1: ...b6(63 70 71 60|63 70 71 60)data
> PV2: ...b7(63 70 71 60|63 70 71 60)data
> PV3: ...b8(63 70 71 60|63 70 71 60)data
> PV4: ...b9(63 70 71 60|63 70 71 60)data

Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten 
vom WR.

13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2]   <-anfrage vom Raspi
44 55 66 77 01 (11/2/0) 36(77 66 55 44|61 40 19 13)00 1d[88 16]   <-antwort vom WR

Gleiches Ergebnis mit MID=37 bis 40.

Bei mir antwortet der WR nur, wenn die erste S/N die vom Raspi ist. 
Setze ich da die S/N vom WR ein, dann antwortet der nicht mehr.

Irgendwas macht deine DTU also zusätzlich, vielleicht auch nur alle $$ 
Minuten? Oder gar nur einmalig beim Hinzufügen des WR ins Setup?

Vielleicht passiert es auch auf einem der anderen Kanäle? Ich lausche ja 
nur auf 0x03. Den Kanal kann man in den Skripten ja auch mal ändern...

[Ziyat T. (toe_c)]

@ Christian P. (pocki)
Hier noch was:
DTU:
51(63 70 71 60|72 22 84 12)5a 5a 0b 9e
WR:
d1(63 70 71 60|63 70 71 60)5a 5a d1
51>d1 8 bit gesetzt

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Ziyat T. schrieb:
>> @Christian P.
>> Anfrage DTU-Pro:
>> PV1: ...36(63 70 71 60|72 22 84 12)00
>> PV2: ...37(63 70 71 60|72 22 84 12)00
>> PV3: ...38(63 70 71 60|72 22 84 12)00
>> PV4: ...39(63 70 71 60|72 22 84 12)00
>>
>> Anworten vom MI-WR:
>>
>> PV1: ...b6(63 70 71 60|63 70 71 60)data
>> PV2: ...b7(63 70 71 60|63 70 71 60)data
>> PV3: ...b8(63 70 71 60|63 70 71 60)data
>> PV4: ...b9(63 70 71 60|63 70 71 60)data
>
> Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten
> vom WR.
>
> [code]
> 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2]
> <-anfrage vom Raspi

ich glaube es muss so sein:
DTU>WR
36(63 70 71 60|72 22 84 12)00 f2
37(63 70 71 60|72 22 84 12)00 f3
38(63 70 71 60|72 22 84 12)00 fc
39(63 70 71 60|72 22 84 12)00 fd

[Christian P. (pocki)]

Bei mir so - ich habe nun einfach mal deine Adressen kopiert.

13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- raspi an WR
60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- antwort vom WR

sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt.
Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet 
der gar nicht.

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache
> seit einem Jahr per Modbus den zero export.
> Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine
> früheren Beitraege hier...

Ok, da ich ein HM besitze ist es bis auf 2% echt cool. 8-)

Ziyat T. schrieb:
> @Christian P.
> Anfrage DTU-Pro:
> PV1: ...36(63 70 71 60|72 22 84 12)00
> PV2: ...37(63 70 71 60|72 22 84 12)00
> PV3: ...38(63 70 71 60|72 22 84 12)00
> PV4: ...39(63 70 71 60|72 22 84 12)00

Sobald ich meine Probleme mit dem Raspi+NRF in den Griff bekommen habe, 
probiere ich das mal aus. Danke! :)

@pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt.
Hattest du die selben Probleme? -> 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Christian P. (pocki)]

Daniel R. schrieb:
> @pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt.
> Hattest du die selben Probleme? ->
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Ja, habe ich auch nicht hinbekommen und dann hingeschmissen.

[Andreas S. (drschiffler)]

Guten Tag,

ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500.

Mein interesse ist die "export limitierung" realisiert durch einen 
bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens 
der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24)

Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode 
der DTU-PRO nicht weiter um die Informationen besser zu decodieren?

Grüße
Andreas

[Ziyat T. (toe_c)]

Andreas S. schrieb:
> Guten Tag,
>
> ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500.
>
> Mein interesse ist die "export limitierung" realisiert durch einen
> bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens
> der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24)
>
> Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode
> der DTU-PRO nicht weiter um die Informationen besser zu decodieren?
>
> Grüße
> Andreas

Hallo Andreas
Hast du die Quellcode der DTU-PRO? Oder wo kann man sie finden?

[Ziyat T. (toe_c)]

@Christian P. (pocki)
Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann?
Ich möchte gerne die obige Diskussionen/Erkentmisse bei mir mal 
ausprobieren ohne lange deinen Sketch zu studieren und kaputt zu machen 
:-)
Es waere einfach wenn ich als data z.B.
36(63 70 71 60|72 22 84 12)00 f2
37(63 70 71 60|72 22 84 12)00 f3
38(63 70 71 60|72 22 84 12)00 fc
39(63 70 71 60|72 22 84 12)00 fd
schicken könnte

[Daniel R. (daniel92)]

Hallo Andreas,

wenn ich dich richtig verstanden habe ist an sich dein Gedanke nicht 
schlecht. Um an den Quellcode dran zu kommen ist es nötig das jemand die 
Mikrocontroller vom DTU-Pro dumped, diesen müsste man dann decompilieren 
und und und... wäre an sich möglich.

Die Frage jedoch, wer hat eine DTU-Pro UND das Equipment um ein Dump zu 
machen?  Bluepill, Blackpill,... 
https://medium.com/techmaker/reverse-engineering-stm32-firmware-578d53e79b3

Achtung: bei solch einem Dump werden natührlich auch die Daten (S.Nr, 
Email?, User-Infos) mit gesichert.

Wenn jemand sich das zutrauen könnte, wäre das an sich eine feine Sache. 
=)

Edit: Wie Ziyat schon geschrieben hat: Quellcode ist ja ein vom 
Hersteller geschrieben und ich kenne kaum eine Firma die denn Quellcode 
freigeben. ;)

[Christian P. (pocki)]

Ziyat T. schrieb:
> @Christian P. (pocki)
> Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann?

Leider nein, so gut bin ich mit Arduino-Sketches nicht. Deshalb mache 
ich das auch mit einem Raspi und einem zweiten nrf24 Modul an den 
GPIO-Pins. Software dazu siehe ein paar Posts weiter oben mit den zip 
Attachments.

[Ziyat T. (toe_c)]

Hallo an die HolyMolyDTU SW-Entwicker

Ich habe die letzte SW im April eingesetzt, sowohl ESP als auch Arduino 
Versionen, da die MI-WRs nicht mehr aktuell sind und ich war der einzige 
mit einem MI-WR, habe ich damals aufgehört weiter zu machen.
Seit dem habe keine Ahnung mehr über die SW-Staende etc..

Jetzt hat mich wieder ein bisschen durch Christan P. gepackt, den MI zu 
lauschen, ich denke wir sind bisschen weiter gekommen.
Ich möchte gerne eine der SW-Versionen (ESP oder Arduino) verwenden um 
einfach paar Msgs zu schicken und was zu empfangen.
Ich gestehe, bin etwas faul um irgend eine SW zu aendern.

Kann mir jemand von SW-Enwicklern eine Version anbieten mit der ich die 
folg. payload schicken kann:
MID..WR...........DTU..........CMD..
36...63 70 71 60..72 22 84 12..00 f2
37...63 70 71 60..72 22 84 12..00 f3
38...63 70 71 60..72 22 84 12..00 fc
39...63 70 71 60..72 22 84 12..00 fd
erwartete Antwort
b6...63 70 71 60..63 70 71 60..data.....

Danke

[Andreas S. (drschiffler)]

Hallo,

es gibt ein git-respository. Das parent-repository ist einige commits 
ahead aber privat. Die Aussage leite ich aus den merge requests 2020 ab. 
Aber vermutlich werden ein paar brauchbare Informationen vorhanden sein.
https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO
(Anmelden über den github oauth provider)

Allerdings enthält das repository keine Lizenz Informationen. Daher ist 
eine bedenkenlose Verwendung wohl fraglich.

Grüße
Andreas

[Daniel R. (daniel92)]

Christian P. schrieb:
> Deshalb mache ich das auch mit einem Raspi

Also funktioniert es bei dir doch. Hmm...
Gut dann gehe ich denn weg alleine.

Andreas S. schrieb:
> Das parent-repository ist einige commits
> ahead aber privat.

Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff 
darauf, kann man da etwas scrapen? :)

Dann könnte man das ganze hier sogar beschleunigen.

[Ziyat T. (toe_c)]

Christian P. schrieb:
> Bei mir so - ich habe nun einfach mal deine Adressen kopiert.
>
>

> 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- 
> raspi an WR

das hier sollte 5a 5a 9e 0b sein

> 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- 
> antwort vom WR
>

>
> sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt.
> Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet
> der gar nicht.

hab alle MID=51 von DTU im Anhang, dann antwortet MI regelmaessig mit 
MID=D1

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Christian P. schrieb:
>> Deshalb mache ich das auch mit einem Raspi
>
> Also funktioniert es bei dir doch. Hmm...
> Gut dann gehe ich denn weg alleine.
>
> Andreas S. schrieb:
>> Das parent-repository ist einige commits
>> ahead aber privat.
>
> Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff
> darauf, kann man da etwas scrapen? :)
>
> Dann könnte man das ganze hier sogar beschleunigen.

Christian P. hat zum Lauschen Arduino+nrf24 zum Senden Raspi+nrf24.
Versuch mal mit seiner Raspi SW ?:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Andreas S. (drschiffler)]

Daniel R. schrieb:
> Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff
> darauf, kann man da etwas scrapen? :)
Also:
- Gefunden mit dem Tool "google". ( 
https://www.google.de/search?q=gitee+hoymiles+dtu )
- Jeder hat Zugriff (siehe Link vorher oder erster Treffer in der google 
Suche) wenn man einen Account auf gitee erstellt. (github ist für die 
Welt, gitee ist für China)
- Ja sollte helfen, da kompletter Quellcode inklusive Bootloader, Doku, 
Tabellen, Logs,...

Grüße
Andreas

[Christian P. (pocki)]

Super - da findet sich im gitee repo ein excel file mit dem Titel 
RFxxxx-V6.5. Schon ohne Translator erkennt man darin Message-Schemen. 
Das haben wir gesucht!

Nun geht es ans übersetzen und auf die Suche des "PASSWORD/unlock codes" 
für die Commands MID=0x15 und 0x09... :-) Die finden sich vielleicht 
auch irgendwo dort im Repo.

[Andreas S. (drschiffler)]

Hallo,

ich habe scheinbar ein Händchen für Suchfunktionen. :-)

Im file usart_nrf.c ist definiert:
UsartNrf_Send_PackSetLockOnOffCommand(...)

Andreas

[Daniel R. (daniel92)]

Hallo  Ziyat T,

danke für den Link. Jedoch ging es eher von Ahoy Github 
(https://github.com/grindylow/ahoy/tree/main/tools/rpi). Das bekomme ich 
nicht zum laufen. :(

Christian nutzt die andere abgewandelte. ^^ Das würde ich dann nehmen, 
wenns nicht anders geht.

@Andreas S: Okay cool, Gitee kannte ich gar nicht und wo ich auf die 
Seite gekommen bin (mit translator), wurde ich indirekt abgewimmelt.

Ich versuche mich dort mal zu Registrieren. Mal schauen wie gut ich in 
Chinesisch bin. joke :)

[Herbert K. (avr-herbi)]

Hallo,
gibt es einen Trick das ganze Repo als ZIP herunterzuladen ?
Ich bekomme überall nur 404 wenn ich den Button "Clone or Download" und 
dann "Download as ZIP" versuche (bei gitee.com). Anmeldung hab ich 
hinbekommen.

[Daniel R. (daniel92)]

Also bei mir hat es funktioniert.
Die ZIP ist 148MB groß.

[Christian P. (pocki)]

Sieht nach den "Kronjuwelen" aus!
Der Source Code lässt vermutlich keine Fragen mehr offen.

[Daniel R. (daniel92)]

Andreas super arbeit!

Übrigens bin ich bisschen vorsichtig hier. Habe mal zwecks Dokumente 
lesen diese bei Virustotal geschoben. Aktuell nichts auffäliges.

https://www.virustotal.com/gui/file/a31fea2076e821eae5d783c75fa3814e7a3378002f21d80d4737d238a31e4b47?nocache=1

Würde das bei allen Files empfehlen, besonders die bat / exe. Die erste 
bat-File im root Ordner sieht bisschen suspekt aus.

Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich einige 
Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder 
besser Github pushe?

[Herbert K. (avr-herbi)]

Danke ! ! !  für den Link ! ! !   Danke Andreas  ! ! !

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Andreas super arbeit!
>
p> Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich 
einige
> Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder
> besser Github pushe?

Rechtlich sind wir sowieso alle Banditen hier, darum gefaellt es mir;-))
Die Chinesen haben seit mehr als 20 Jahren auch alles kopiert...
Für mich lieber Github, auch ohne Uebersetzung

[Ziyat T. (toe_c)]

@Christian P.

#define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF  0x51 
//ŒÓËø&ÏÞÖƹŠÂÊ

#define CONTROL_LOCK_MI_SUB                 0xa5a5
#define CONTROL_LIMIT_POWER_SUB             0x5a5a
#define CONTROL_ON_SUB                      0x55aa
#define CONTROL_OFF_SUB                     0xaa55

genau was ich heute bei mir gesehen habe ;-)
51(63 70 71 60|72 22 84 12)5a 5a

[Daniel R. (daniel92)]

Also in der Excel "RF通讯协议-V6.5.xlsx" 
(RF-Kommunikationsprotokoll-V6.5.xlsx) stehen viele Dinge über die alten 
MI-WR Serie. ;)

Da sollte in Zukunft Licht ins dunkle kommen.
Die Excel habe ich zu ca. 1/3 auf Deutsch übersetzt.

Ich breche hier ab und schaue mich noch in den anderen Dokumenten um.

[Daniel R. (daniel92)]

Bingooo!!!!

/***********************************************
** Function name:     //Stellen Sie die Anti-Rückfluss-Parameter ein
** Descriptions:
** input parameters:    ?
** output parameters:   ?

** Returned value:      ?
*************************************************/
uint8_t UsartNrf_Send_PackSetRefluxPowerCommand(uint16_t reflux_power, uint8_t MainCmd, uint16_t SubCmd)
{
    uint8_t i = 0;
    uint16_t j;
    uint8_t temp_dat[UART_LEN];
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//Kopf
    temp_dat[0] = MainCmd;   //Anweisung
    memset(&temp_dat[1], 0, 4);
    memset(&temp_dat[5], 0, 4);
    //
    //  MIReal[PortNO].Data.NetCmd = NET_TURN_ON;
    //    if(MIReal[PortNO].Data.NetCmd == NET_TURN_ON)        //开机状态
    //    {
    temp_dat[9]  = SubCmd & 0XFF00 >> 8;
    temp_dat[10] = SubCmd & 0XFF;
    temp_dat[11] = reflux_power * 100 / (EVERY_PORT_POWER * 10 * Dtu3Detail.Property.PortNum);  //Prozentsatz der Leistungsbegrenzung
    temp_dat[12] = reflux_power >> 8;    //Hohe 8-Bit-Leistungsbegrenzung
    temp_dat[13] = reflux_power & 0x00ff;             //Niedrige Leistungsgrenze 8 Bit
    //    }
    //    else                                                          //开低功耗
    //    {
    //        temp_dat[9]  = SubCmd & 0XFF00 >> 8;   //5a5a
    //        temp_dat[10] = SubCmd & 0XFF;
    //      temp_dat[11] = 0;
    //      temp_dat[12] = 20&0x00ff;
    //      temp_dat[13] = 20&0xff00>>16;
    //    }
    temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
    i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //Vorwärtssubstitution
    Uart_SendBuffer[i + 1] = ETX; //Ende
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

[Andreas S. (drschiffler)]

Guten Abend,

ich kann zwar programmieren -- denke ich -- aber ich bin eher der 
Anwender / Orchestrator. Daher meine vorsichtige Frage. Bekommen wir, 
ihr oder die Community es hin eine Arduino Bibliothek und/oder ein 
Python modul "ahoymilesdtu" zu erstellen?

Man könnte ja in die Kommentare der Files im Sinne "copyleft" das 
quellgebende repository nennen.

Danke und Grüße
Andreas

[Daniel R. (daniel92)]

Ich kann mit der Frage nichts Anfangen.
Was möchtest du nochmal genau wissen? :)

[Andreas S. (drschiffler)]

Daniel R. schrieb:
> Ich kann mit der Frage nichts Anfangen.
> Was möchtest du nochmal genau wissen? :)
Das Resultat der zahlreichen Stunden die hier investiert werden könnte 
doch so aussehen:
arduino
include <ahoydtu.h>
include <mysmartmeter.h>

AHOYDTU ahoydtu_nrf24(SS_PIN, RST_PIN,...);
MYSMMETER mysm('192.168.1.1',502); // Haus-Hauptanschluss

void setup() {
...
ahoydtu_nrf24522.Init();
...
}

void loop(){
...
if (mysm.read_active_pw_kw() < -0.6){
  ahoydtu_nrf24.reduce_pw_by(0.6 - math.abs(mysm.read_active_pw_kw()) );
} else {
  // no power limit
}
//wait some time
...
}

und/oder das gleiche in python

import ahoydtu as ahoy
....# usw.

So kann man 2kW installieren und speißt max. 600W ein. Und dank 
Blindleistungsregelung max. -60VA laut Richtlinien.
Das geht glaube ich so in der DTU Pro software (noch) nicht. (siehe 
file: AntiBackflow.c )

[Jan-Jonas S. (janjonas_s)]

Sieht ja vielversprechend aus. Die Frage der Lizensierung ist sehr 
berechtigt. Ich würde meine Werke gerne unter der GPLv2 lizensiert 
sehen.
Das wäre auch ein Grund für die Teilung der Repos. Meinetwegen bleiben 
sie bei Petersilie.
Früher oder später muss das eh passieren, wenn wir python mal als 
richtiges installierbares Package bauen wollen.

Für den MI-Teil bin ich sogut wie raus, weil ich hier kein DuT habe.
Ich kann die Grundsubstanz des Python-Codes vielleicht mal modularer 
gestalten, dass das MI-Protokoll parallel hinzugefügt werden kann.

Grundsätzlich bietet python ja schon die Idee, rohe Payloads via mqtt zu 
injecten. Jedoch bisher nur als Payload in zu einem HM, ohne ESB-Frame. 
Könnte man aber anpassen. Schwieriger wird dann das empfangen.

[Jan-Jonas S. (janjonas_s)]

Andreas S. schrieb:
> So kann man 2kW installieren und speißt max. 600W ein. Und dank

Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein 
Zertifikat sehen, dass das auch funktioniert.
Im Wesentlichen wird das EVU fordern bei Dir eine 
Fern-Abschalteinrichtung einzubauen.
Physikalisches Limit != Software Limit.
Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine 
DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in 
Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal 
wegen Unterproduktion die Computer aus.

[Heinz R. (heijz)]

Jan-Jonas S. schrieb:
> Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine
> DIY Frickelei ohne Siegel und Plombe eh nicht sein.

Doch, ist sie, das ist gar kein Problem
Zeig mir einen WR an dem die 70% Grenze verplombbar ist - entweder den 
Installateur interessiert es nicht oder man nimmt sie raus nachdem er 
weg ist
Mit Kontrollen ist hier auch nicht zu rechnen  auf welcher rechtlichen 
Grundlage sollte das passieren?

Und selbst wenn es so passieren sollte - Pressemitteilung "900.000 
PV-Anlagen in Deutschland still gelegt weil sie 3% zu viel eingespeist 
haben"- lächerlich

[isnoAhoy (Gast)]

Hallo Andreas S.,
das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges.

Hier die usart_nrf.c übersetzt ins Englische. Ich traue den 
Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht.

Man sollte halt keinen Source Code 1:1 aus dem Original übernehmen, dann 
ist das ja auch nur eine Referenz und keine Kopie -> Urheberrecht. Bei 
dem Python Code von Jan-Jonas und den anderen Pythonistas sehe ich da 
sowieso eher kein Problem. Wenn es um die Portierung des Protokolls von 
der C in eine C++ Variante geht scheint mir der C++ Code von Lukas auch 
viel eleganter als das doch recht prozedurale C der Hoymiles Bibliothek. 
Vor allem der Parser für die Pakete ist m.E. bereits viel hübscher und 
modularer geraten.

[Christian P. (pocki)]

isnoAhoy schrieb:
> Hallo Andreas S.,
> das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges.
>
> Hier die usart_nrf.c übersetzt ins Englische. Ich traue den
> Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht.

Danke, super.
Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch 
den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden. 
Kann mir wer damit helfen?

Verdächtig sind da ein paar Commands in der Übersicht:
0x02 broadcast commands to collect terminal device IDs in the network
0x13 Set query RF ID
0x18 All wRFID retrieval, respond as long as there is retrieval
0x1a Set MI-NRF ID

[isnoAhoy (Gast)]

Hier ist eine englische Übersetzung des RF communication 
protocol-V6.5xlsx

[isnoAhoy (Gast)]

Anbei noch einige übersetzte Dokumente. Laut dem Filesystem Design 
Dokument speichert die DTU 96 Werte pro Tag, das sind bei 1440 / 96 = 15 
Minuten Intervalle.

[isnoAhoy (Gast)]

Hallo Christian P.,

> Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch
> den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden.
> Kann mir wer damit helfen?

Ich habe das Excel-Dokument noch ein bißchen formatiert damit es 
leichter lesbar ist.

Ich vermute das ist das Legacy poll data command 0x09 auf Seite 3 Data 
Collection instructions. Für den/die anderen Kanäle der zwei bzw. vier 
Kanal-Wechselrichter Varianten gibt es noch das Command 0x11 Kanal B, 
bzw. 0x36, 0x37, 0x38, 0x39 (=Kanäle A1, B1, A2, B2).

Für die Suche nach einem WR kann man Command 0x02 verwenden siehe Seite 
5 Data acquisition RF dedicated.

Eventuell hast Du unbeabsichtigt auch das Kommando 0x01 Switch DTU-NRF 
air baud rate 2M / 250K an Deinen WR abgesetzt ?
Versuche es doch mal mit 0x01 im User data wieder auf 250K zurück zu 
setzen. Ich meine so etwas auch in martin (Gast)'s DTULite Logfiles an 
den RX/TX Punkten gesehen zu haben. Ich vermute die Kommunikation mit 
250K ist um einiges stabiler als die 2M Baudrate, vor allem in unseren 
Breitengraden mit einem vollen 2.4GHz Band.

[Christian P. (pocki)]

Bingo - habe meinem MI-300 eine Antwort entlockt:

Anfrage:
13 19 40 61 01 (11/1/0) 09(61 40 19 13|51 22 22 22)00 51[cc 1a]
Antworten:
22 22 22 51 01 (24/1/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1c.13 89.00 71.00 18.00 a4.8b[cb ??]
22 22 22 51 01 (24/3/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1d.13 89.00 6b.00 19.00 a4.91[fb ??]
22 22 22 51 01 (24/0/0) 89(61 40 19 13|61 40 19 13)01 3f.00 03.09 20.13 89.00 69.00 19.00 a4.d3[ad ??]

0x0142 = 32,2  V_PVA_AVG
0x0003 = 0,3   I_PVA_AVG
0x091c = 233,2 GridVol_AVG
0x1389 = 50,01 GridFre_AVG
0x0071 = 11,3  APower_AVG
0x0018 = 2,4   AEnergy
0x00a4 = 16,4  Temp_AVG

Hoffe die Kommaverschiebungen habe ich richtig inerpretiert.

Zu dem Zeitpunkt liefert der WR etwa 92mA und 6W

Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so 
dokumentiert.

[Daniel R. (daniel92)]

Sehr cool Pocki! :)

Damit alle Dokumente hier Hand und Fuß hat, würde ich mir wünschen statt 
alles in dem Forum zu Posten. Stattdessen auf Github zu laden, die Frage 
ist jedoch: Macht das Sinn?

Beste grüße.

[Ziyat T. (toe_c)]

Christian P. schrieb:
Super Christian!

> 0x0018 = 2,4   AEnergy
Das sollte 24Wh sein.

D.h. MI-300 und MI-1500 wegen der Anzahl Ports anders anzusprechen, echt 
mühsam

[Richard K. (laserrichi)]

Hallo,

da ich die bisher immer nur stiller mitleser war habe ich mich jetzt 
endlich angemeldet.

Ich habe einen Mi-600 und ich weis nicht ob ich hier was dazu beitragen 
kann.

Zuerst hatte ich etwas schwierigkeiten den ESP8266 zum laufen zu 
bringen.
Ich hatte die FW compiliert und geflasht und sah aber keinen acesspoint, 
auch der connect ins heimische wlan ging nicht (hatte es direkt beim 
compilieren schon mit rein)

Ffertige .bin von hier probiert, die 0.4.11  und 0.4.13 mit selben 
Ergebniss.
Die version 220519_ahoy_0.4.4_esp8266.bin  hatte endlich funktioniert, 
und konnte auch auf die 0.4.13 upgraden... dabei war mir aufgefallen das 
die settings mit vielen yyyyyy gefüllt waren.

Meine SN fängt mit 104161 an

[Daniel R. (daniel92)]

Hallo Richard,

also der letzte Update auf Github war vor ca 40min.
An sich gibt es verschiedene wege wie man das ganze auf den ESP bekommt.

Meines wissens nach ist der ganze Code noch nicht für den 
MI-Wechselrichter angepasst. Wäre es ein HM, dann wäre würde es schon 
besser klappen.

Du musst dich noch ein bisschen gedulden für die MI-Serie, da neue 
Erkentnisse erlangt worden sind und das demnächst nach und nach weiter 
aufgebaut wird. ;)

PS: yyyy sind übrigens nur "Platzhalter", die müsste man ersetzen.

[Andreas S. (drschiffler)]

Jan-Jonas S. schrieb:
> Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein
> Zertifikat sehen, dass das auch funktioniert.
> Im Wesentlichen wird das EVU fordern bei Dir eine
> Fern-Abschalteinrichtung einzubauen.
> Physikalisches Limit != Software Limit.
> Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine
> DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in
> Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal
> wegen Unterproduktion die Computer aus.
Hallo Jan-Jonas,

das sehe absolut genauso. Die Herausforderung ist nicht die Software.
Ich könnte meinem EVU sogar eine REST-API zur Fernabschaltung anbieten 
aber ich vermute wenn ich aktuell den vereinfachten Antrag ("600W") 
stelle mit: "Balkonanlage mit 2kwWp und Null-Export-Begrenzung" wird man 
damit nichts anfangen können und ggf. sagen, "...ja aber was ist mit der 
Blindleistung...". Selbst wenn ich das mit gekaufter Hardware mache. (Es 
gibt ja hier auch Nutzer von MI-1500, wie ist es hier gelaufen?)

Ich frage mich daher, es gibt ja diese Funktion. Das wird dann wohl von 
großen Anlagen genutzt (+ Blindleistungsanpassung)?

Hat da jemand Dokumente / Zertitikate von hoymiles die diese 
Regelungsfunktion laut Standard XY durch TüV, VDE o.ä. zertifizieren?
Danke für Hinweise.

[Daniel R. (daniel92)]

Konformitätszertifikat Erzeugungseinheit VDE AR-N-4105:2018-11
https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_EZE.pdf

Konformitätszertifikat NA-Schutz VDE AR-N-4105:2018-11
https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_NA.pdf

Nur das konnte ich finden.

EDIT: Hier gibts von jedem Hoymiles-WR ein Zertifikat.
https://www.shinetech-power.de/wechselrichter/hoymiles/

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> Konformitätszertifikat Erzeugungseinheit

Das gilt aber nicht für das Gerät mit selbst geschriebener Software oder 
selbst gebastelten Teilen des Komplettsystems :)

[isnoAhoy (Gast)]

Hallo Christian P.,
> Bingo - habe meinem MI-300 eine Antwort entlockt:
Na das ist doch mal eine freudige Nachricht!

> Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so
dokumentiert.

Das ist m.E. die Fehler Antwort, wenn der WR einige Events im Log hat, 
die man sich genauer ansehen soll. M.W. hat Jan-Jonas die Event Log 
Abfrage für die aktuellen HM-XXX Wechselrichter in der Raspberry 
Pi/Python Software bereits umgesetzt.

@Christian P., Ziyat T. & Richard K.,
vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos 
in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen 
?
Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das 
Programm an der Stelle zu testen / verifzieren..


Hallo Daniel R.,

> Damit alle Dokumente Hand und Fuß haben, würde ich mir wünschen - statt
alles hier ins Forum zu Posten - es stattdessen auf Github zu laden. Die 
Frage
ist jedoch: Macht das Sinn?

Es gab diverse Meinungen dass es nicht unbedingt sinnvoll ist den 
OpenSource Code mit den Closed Source Dokumenten auf GitHub zu mischen. 
Aber es spricht sicher Niemand dagegen, wenn Du die Dokumente auf Deinem 
Github in einem separaten Repository ablegst.

[Ziyat T. (toe_c)]

isnoAhoy schrieb:

> @Christian P., Ziyat T. & Richard K.,
> vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos
> in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen
> ?
> Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das
> Programm an der Stelle zu testen / verifzieren..
>
Ich würde gerne die ESP8266+nrf24 / Arduino+nrf24 Variante für den 
MI-1500 einsetzen.
Die SW-Staende kenne ich nicht (mehr).
Ich weiss dass die SW komplett auf HM zugeschnitten sind, darum ich 
braeuchte eine "Anleitung", wo und wie ich die Kommandos eingeben kann, 
natürlich auch die Antworten zu parsen.

Edit: hier sind die Kommandos/Antworten welche ich in der Luft gesehen 
habe. DTU-Pro<>MI1500
Daten
======================================================================== 
=
Anfrage v. DTU-Pro:
MID,WR,DTU,CMD
PV1: ...36(63 70 71 60|72 22 84 12)00
PV2: ...37(63 70 71 60|72 22 84 12)00
PV3: ...38(63 70 71 60|72 22 84 12)00
PV4: ...39(63 70 71 60|72 22 84 12)00

Anworten v. MI-WR:
MID,WR,WR,Data

PV1: ...b6(63 70 71 60|63 70 71 60)data
PV2: ...b7(63 70 71 60|63 70 71 60)data
PV3: ...b8(63 70 71 60|63 70 71 60)data
PV4: ...b9(63 70 71 60|63 70 71 60)data

36 00110110 > b6 10110110   bit8 gesetzt

37 00110111 > b7 10110111   bit8 gesetzt

Limitierung
======================================================================== 
=
Anfragen v. DTU-Pro:
51(63 70 71 60|72 22 84 12)5a 5a 0b 9e         0b = 11% power 
limitierung
Anworten v. MI-WR:
d1(63 70 71 60|63 70 71 60)5a 5a d1
51>d1 8 bit gesetzt

#define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF  0x51
//ŒÓËø&ÏÞÖƹŠÂÊ

#define CONTROL_LOCK_MI_SUB                 0xa5a5
#define CONTROL_LIMIT_POWER_SUB             0x5a5a
#define CONTROL_ON_SUB                      0x55aa
#define CONTROL_OFF_SUB                     0xaa55

[IsnoAhoy (Gast)]

Hallo Ziyat T.,
ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für 
HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80, 
MI-250/300/400 MID = 0x09, MI-600/700/800 MID = 0x09 & 0x11 sowie 
MI-1000/1200/1500 MID = 0x36..0x39
In der hmInverter.h müssen die Inverter Model ebenfalls mit getModel und 
setModel implementiert werden
In der hmSystem.h kann man dann in addInverter das Protokoll in einem 
switch je nach Modellnummer setzen.
Und dann kann man in der hmRadio.h die Methoden sendTimePacket den 
sendCmdPacket Aufruf anpassen mit case je nach Inverter getModel.
Das Mapping der Inverter Daten erfolgt dann wieder über die in hmDefines 
zu definierenden byteAssign_t miXchAssignment[] und deren Länge

Irgendwie müssen wir dem Code dann noch beibringen dass für die 
MI-Serien teilweise zwei/vier Cmd Pakete geschickt und ausgewertet 
werden müssen. Aber mit den og Anpassungen sollte es erstmal den ersten 
Kanal der MI-Modelle abfragen können.

@Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei 
so was umzusetzen?

[Lukas P. (lumapu)]

IsnoAhoy schrieb:

> @Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei
> so was umzusetzen?

Nein bin ich nicht und habe es auch nicht vor.

Ich fände es am besten, wenn man die Inverter Serie per template 
Parameter übergibt und sich damit vor dem kompilieren entscheiden muss.

Weiter würde ich es bevorzugen die hm*.h Dateien zu duplizieren und als 
mi*.h umbenennen. Dann bekommen wir jetzt nicht ein riesen Chaos und 
ständige if-else-switch Konstrukte. In naher Zukunft kann man dann 
Gemeinsamkeiten suchen und diese wieder generisch anlegen.

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:
> Hallo Ziyat T.,
> ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für
> HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80,

Danke,
Habe die https://github.com/lumapu/ahoy/tree/main/tools/esp8266 runter 
geladen, ohooo, ist ja was implementiert worden. Muss sagen da blicke 
ich nicht einfach schnell durch.
Ich habe die Version von April hier, mache mal damit weiter, ich muss ja 
zuerst sicher sein, was ich in der Luft sehe sollte auch implementiert 
werden und soll so laufen..

[Holger Skusa (Gast)]

Hallo, ich habe mit großem Interesse diesen thread gelesen und mir die 
4.4. Bin auf einem Wemos geflasht. Mir ist nur nicht klar was ich bei 
inverter Adress eintragen soll. Ich habe mehrere HM-300 die ich anfragen 
möchte. Irgendwie scheint die serial number ne Rolle zu spielen,aber wo 
finde ich die.
Kann mir mal jemand auf die Sprünge helfen. Habe ich was überlesen?

[Herbert K. (avr-herbi)]

Holger Skusa schrieb:
> ...Irgendwie scheint die serial number ne Rolle zu spielen,aber wo
> finde ich die.

Die S/N der WR findest Du auf der Rückseite vom WR. Also auf der planen 
Seite.

[Holger Skusa (Gast)]

Und diese Nummer ist dann bei Adress inverter  einzutragen? Oder muss 
die noch irgendwie gewandelt werden?

[Lukas P. (lumapu)]

normaler Weise so eintragen wie sie drauf steht.
Ich würde dir empfehlen die aktuelle 0.4.17 zu installieren, die muss 
allerdings selbst kompiliert werden.

[oxylog (Gast)]

Hallo euch allen!
Ich wollte euch allen, die an der großartigen Entwicklung beteiligt 
sind, danken.
Ich bin ein stummer „Mitleser“ mit einem HM-300, der zufällig auf dieses 
Forum und die Topic stieß.
Was „Elektrotechnik" angeht bin ich maximal Anfänger; Was 
Mikrocontroller angeht kompletter Laie und was Funk angeht mit noch 
weniger Fachwissen ausgestattet.
Leider kann ich nicht so viel zur Programmierung beitragen, da ich auch 
hier komplett fachfremd bin und mir die Zeit momentan fehlt, mir das 
alles anzueignen.

Dank euch und eurer tollen Dokumentation konnte ich das Projekt mittels 
eines „D1 mini“-clones und einem NRF24L01+PA+LNA (jetzt mit zusätzlicher 
„Schirmung“) realisieren.  Funktionierte, wie dokumentiert, problemlos 
„out of the box“.

Danke für euer Engagement! Ihr habt da „etwas Lust am Basteln" bei mir 
etwas geweckt ;-)

[Oliver R. (esp_loeter)]

Hallo zusammen,
ich habe einige Platinen machen lassen.
Wemos D1 mini und NRF24 zusammen auf einer Platine mit der Verdrahtung 
wie im GitHub beschrieben.
Ich habe noch einige Platinen übrig und würde die für 2€ pro Stück 
abgeben.
Einfach in ebay-Kleinanzeigen nach esp-dtu suchen...

[Ert (Gast)]

Hallo zusammen,

wollte auch ein Danke loswerden! also: DANKE! Geile Arbeit! Dickes Lob 
an die Community!

Ich habe es jezt alles auf einem Nodemcu laufen.

Meine PV Module sind noch nicht da, also hab ich dem HM-300 ans 
Labornetztteil gepackt. Wenn keine DC-Spannung anliegt geht das 
Funkmodul vom Umrichter nicht. AC muss aber nicht anliegen um das System 
zu testen.

Gruß Ert

[Holger Skusa (Gast)]

Hallo,
ich wünschte ich könnte mich auch bedanken. Aber leider will es noch 
nocht so richtig.
Ich habe die Serial Nummer meines HM-300 nun gefunden und in der 4.4 
eingetragen. Leider kommen keine Daten.
Nun versuche ich dem Tipp von Lukas zu folgen und die 4.17 zu 
kompilieren.

Meine Arduino ide bricht aber immer mit:


In file included from app.cpp:1:0:
app.h:4:18: fatal error: RF24.h: No such file or directory
 #include <RF24.h>
 ab.

HELP !!!

[Holger Skusa (Gast)]

Die Library von Git maniacbug/RF24 hab ich installiert...

[Günter H. (gnter_h534)]

Mit der Arduino IDE 1.8.19 und

- aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4)

sowie den LIBRARIES

- Time 1.6.1
- RF24 1.4.2
- PubSubClient 2.8

klappt es bei mir problemlos.

Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt.

[Alexander P. (drdownload)]

Eine Frage, gab es auch schon Versuche Werte zu setzen so wie es die DTU 
Pro macht? Die kann ja den Output begrenzen bzw. ein "Country Protection 
File" hochladen (theoretisch braucht man das für den regelkonformen 
Betrieb)

[Holger Skusa (Gast)]

Günter H. schrieb:
> Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt.

Du bist mein Retter des Abends !!!
Soeben habe ich meine ersten Werte empfangen. Das hat jetzt aber auch 
Stunden gekostet. Aber Danke für die Datei. Mit der Arduino IDE hab ich 
schon immer auf Kriegsfuss gestanden. Die mag mich irgendwie nicht.

Ich hab die IDE nun ganz neu installiert und alle von Dir angegebenen 
Librarys installiert. Das Board nach installiert usw.

Was soll ich sagen, nun geht auch das kompilieren.

Na dann kann ich wenigstens zukünftige Versionen selber bauen.

Vielen Dank an alle die das hier möglich gemacht haben. Klasse Sache !!!

Eine Frage hab ich noch:

Wie viele Inverter kann ein Wemos mit einem RF24 empfangen. Das ist ja 
im Sketch einstellbar. Ist da bei 3 Stück Schluss, oder würden auch 6 
gehen ?

Gruß Skusi, und allen einen schönen Wochenanfang...

[isnoAhoy (Gast)]

Hallo Holger Skusa,

also prinzipiell werden die WR nacheinander abgefragt, es wären also 
auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen:

#define MAX_NUM_INVERTERS       3
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/config.h#L33

Irgendwann wird halt der Speicher knapp und ich weiß noch nicht sicher, 
ob sich der Code problemlos auch auf einem ESP32 kompilieren läßt.

[isnoAhoy (Gast)]

Hallo Alexander P.,
bitte schau mal in das letzte Excel File hier im Thread:
* RF_communication_protocol-V6.5.xlsx (78,3 KB)
dort sind die offiziellen Hoymiles Kommandos und Antworten dokumentiert. 
Damit ist es dieser Tage auch gelungen, die MI-Wechselrichter zum reden 
zu bringen.

Auch die offizielle "Bibliothek" von Hoymiles ist hier im Thread:
* usart_nrf.c (147 KB)
dort habe ich beim Übersetzen auch die Power Profile und Firmware Upload 
Routinen gesehen.

Wenn Du die Raspberry Pi/Python Software von Jan-Jonas verwendest, dann 
kannst Du u.a. über MQTT eigene Kommandos an den Wechselrichter senden. 
In der ESP8266 Variante ist eine derartige Option aktuell noch nicht 
vorgesehen.

@Lukas P., hast Du evtl. vor eine derartige MQTT-Schnittstelle, o.a. zur 
Fernsteuerung der Wechselrichter einzubauen oder bist Du mit der reinen 
Auswertung der Daten soweit zufrieden ?

[isnoAhoy (Gast)]

Hallo Oliver R.,
kannst Du das Platinen Layout evtl. noch im GitHub committen bzw. einen 
PR erstellen ? Ich glaube ich habe nur die Fritzing Layouts gemacht aber 
kein Layout hochgeladen. Danke!

[Daniel M. (daniel_m821)]

Ziyat T. schrieb:
> Hallo
> Die Antwort
> channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d
> fa 01 3a 33
> Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert.
> D.h. dieser TSUN ist ein MI?
> Konntest du schon einen request schicken und TSUN hat geantwortet?

Hi,
habe noch keine Requests rausbekommen. Dieser Part scheint mir auch 
defekt zu sein, da Abweichungen in den Bytes sind, z.B. die WR-Adresse 
im ersten Teil.

Es könnte sein, dass der MI1500 mit dem TSUN ähnlich ist, auch die 
Chinesen erfinden nicht 3x das Rad neu.

Bin jetzt erst von Montage wiedergekommen und schaue die Tage, was ich 
noch rauskriege.

[Holger S. (skusi)]

isnoAhoy schrieb:
> also prinzipiell werden die WR nacheinander abgefragt, es wären also
> auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen:
Hallo, ich hab jetzt mit der Einstellung

#define MAX_NUM_INVERTERS       6

kompiliert. Funktioniert aber nur bis 5 Stk !
Ab 6 Inverter startet der Wemos nicht mehr durch.
In der Console meckert er:

Settings not valid, erasing ...

Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?

[Daniel M. (daniel_m821)]

IsnoAhoy schrieb:
> @Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg
> wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer
> versendet ?
>
> 10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ?
>
> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code.
> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf
> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten
> auf dem Kanal 2403GHz.

Ich kriege aktuell nichtmal ein Kommando raus, da ich mit Arduino noch 
nicht so fit bin und Python auch nicht gerade ein Küchenlicht ist.
Meine Freundin ist immer erst ca. 19 uhr zuhause, da ist auch nicht mehr 
viel mit Code und Sonne, es zieht sich also etwas. Bin aber auch 
gespannt auf dem Code am Ende :)
Eine Kurzanleitung, wie für den ESP die Kommandos zusammengesetzt 
werden, wäre hilfreich, Strom in allen Formen, Farben und 
Geschmacksrichtungen sind für mich kein Problem, aber Bytes schubbsen in 
C++ ist ne andere Geschichte.

Seriennummern drehen hab ich mit dem anderen NRF-Chip ohne externe 
Antenne noch nicht getestet, mache ich die Woche noch.

Ich hab noch nicht so ganz verstanden, was meine DTU zwischen dem was am 
NRF reinkommt und am Ende in der Luft landet, noch macht, da sind 
Unterschiede.

[Lukas P. (lumapu)]

Holger S. schrieb:
> #define MAX_NUM_INVERTERS       6
>
> kompiliert. Funktioniert aber nur bis 5 Stk !
> Ab 6 Inverter startet der Wemos nicht mehr durch.
> In der Console meckert er:
>
> Settings not valid, erasing ...
>
> Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?

Nein es gibt keine Limitierung auf 6 Stück. Ich glaube in main.cpp oä 
wird new EEP(1000) oä aufgerufen. Die 1000 ist die Länge des 
zugreifbaren Eeproms oder besser gesagt emuliertes Eeprom also Flash.
Diese Zahl darf maximal 4096 sein. Zusätzlich muss in defines.h noch die 
Speicherposition vom SettingsCRC nach oben verschoben werden z.B. 1500

[Ziyat T. (toe_c)]

Hallo
@Daniel M.,@IsnoAhoy, @Hubi

Da ich schon früher Hubi's code verwendet habe, hab die letzte 
Git-Version von ihm angepasst/vergewaltigt;-)
Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD)
36 63 70 71 60 72 22 84 12 00
37 63 70 71 60 72 22 84 12 00
38 63 70 71 60 72 22 84 12 00
39 63 70 71 60 72 22 84 12 00
oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts!
nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an 
meine DTU-Pro, wenn sie eingeschaltet ist.
Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde 
ein neues nrf24 besorgen und damit ausprobieren.

[Daniel M. (daniel_m821)]

Ziyat T. schrieb:
> Da ich schon früher Hubi's code verwendet habe, hab die letzte
> Git-Version von ihm angepasst/vergewaltigt;-)
> Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD)

Hi, das selbe an meiner Front gerade.
D1 mini: 11 63 50 03 16 63 50 03 16 00 11 2E BA

> oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts!
> nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an
> meine DTU-Pro, wenn sie eingeschaltet ist.
> Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde
> ein neues nrf24 besorgen und damit ausprobieren.

Futsch isser sicher nicht. Solange wir nicht klar sagen können, was 
unsere Außenseiter genau hören wollen, bleiben die für uns stumm.

Die Scanner-Programme, die ich probiert habe, kriegen entweder nix 
(falsche Rx-Adressen) oder ich sehe z.B. in der originalen 
scanner-Anwendung der NRF-Libary aus den Beispielen nur die Kanäle wo 
was aufploppt, jedoch nicht was.

Ich kann bisher nicht sagen, wie die CRC aufgebaut ist oder was genau 
durch die Luft gesendet wird.

Morgen neuer Versuch, WR geht gleich schlafen :)

Angepasst habe ich erstmal in der hmRadio.h:

 void sendTimePacket(uint64_t invId, uint32_t ts) {
            //DPRINTLN(F("hmRadio.h:sendTimePacket"));
            sendCmdPacket(invId, 0x11, 0x91, false);
            mTxBuf[9] = 0x00; // cid
            mTxBuf[10] = 0x11;
            //CP_U32_LittleEndian(&mTxBuf[12], ts);
            //mTxBuf[19] = 0x05;

            uint16_t crc = crc16(&mTxBuf[10], 14);
            mTxBuf[11] = (crc >> 2) & 0xff;
            mTxBuf[12] = (crc     ) & 0xff;
            mTxBuf[13] = crc8(mTxBuf, 13);

            sendPacket(invId, mTxBuf, 14, true);
        }

Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine 
geänderten Dateien?

[isnoAhoy (Gast)]

Hallo Daniel M.,
also Du musst zwei Pakete senden, aber zwischendrin erstmal die Antwort 
abwarten:
Probiere mal:
1. sendCmdPacket(invId, 0x09, 0x00, true);
2. laß den Rest der Routine unter sendTimePacket einfach mal weg.

Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen 
timestamp oder gar eine CRC_16.
Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true 
berechnet und angehängt wird sollte eigentlich genug sein.

Er sollte dann z.B. folgendes Senden:
D1 mini: >09< <52 40 36 68> <63 50 03 16> >00< 11
Hier ist die 11 ganz vorne die MID (s.o.) dann die sollte die Serien 
Nummer der DTU als Routing Addresse (hier die antike DTU 10F052403668) 
folgen und dann erst die Serien Nummer des WR als Target Adresse 
(Routing und Target Adresse ist offenbar bei den MI-Wechselrichtern 
vertauscht). Die 00 sind die User data und dann kommt nur noch die CRC_8 
hier einfach mal 11 gelassen, sollte eigentlich richtig berechnet 
werden. Die Start und Stop-Bytes 0x7e und 0x7f hängt i.d.R. der 
nRF25L01+ automatisch dran.
Als Antwort bekommst Du dann 0x88 (status) / 0x89 (data) ...

Das selbe sollte auch mit 0x11 als MID funktionieren für den zweiten 
Kanal.
Also Antwort kommt dann eben 0x91 (data?) / 0x92 (status?) ...

Warum bei 0x11 die Reihenfolge von status und data umgekehrt sein soll, 
wissen vermutlich nichtmal die Hoymiles-Götter. Aber das Excel Sheet 
"RF_communication_protocol-V6.5.xlsx" widerspricht sich hier auch 
selbst. Vermutlich wurde es erst nachträglich korrigiert (rot auf "Data 
collection instructions" in Zellen B94 und B99)

@Ziyat T.,
Für Dich gilt m.E. genau das selbe, lediglich sollte als MID 0x36..0x39 
für die vier Kanäle verwendet werden.

Als Antwort kommt dann 0xB6... .. 0xB9... (data & status)

Viel Erfolg

[isnoAhoy (Gast)]

Hallo Holger,
wie Lukas schon erwähnt hat in eep.h:
            EEPROM.begin(4096);

und in den defines.h das Ganze gleich dynamisch gestalten:

#define ADDR_SETTINGS_CRC   ADDR_NEXT          + CRC_LEN

#if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
#error address overlap!
#endif

#if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
#error EEPROM size exceeded! Configure less inverters?
#endif

[Ziyat T. (toe_c)]

@Daniel M.
> Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine
> geänderten Dateien?

Wie gesagt, ich verwende Hubi's Code auf Arduino+nrf24, kein 
hmRadio.h,app.cpp

@isnoAhoy
> Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen
> timestamp oder gar eine CRC_16.
> Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true
> berechnet und angehängt wird sollte eigentlich genug sein.

Welches ist das alte MI-Protokoll? bis zum MI-600?
Meine DTU-Pro sendet zum MI-1500 ganz klar CMD 0x36 bis 0x39 mit SubCMD 
0x00, CRC 0xFx, sonst nichts:
60 71 70 63 01 (11/3/0) 39(63 70 71 60|72 22 84 12)00 fd[67 ed]
60 71 70 63 01 (11/1/0) 38(63 70 71 60|72 22 84 12)00 fc[a2 51]

Ich muss mal andere Kanaele nochmals lauschen, ob der WR was anderes 
braucht

Ps: Könnten wir uns auf die Bezeichnungen CMD und SubCMD einigen?

[Holger S. (skusi)]

Vielen Dank isnoAhoy, ich werde das mal bei Gelegenheit so versuchen. 
Fließt das dann auch in die nächste Version mit ein ?

Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen 
Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem 
Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate 
ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten 
und den Namen ändern.
Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.

[Daniel M. (daniel_m821)]

Habe den Code von Hubi etwas angepasst:
NRF24_SendRcv.ino:

    if (tel == 0) {
      #ifdef ESP8266
      hmPackets.SetUnixTimeStamp (getNow());
      #endif
      size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8);
    }
    else if (tel == 1)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x89);
    else if (tel == 2)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x91);
    else if (tel == 3) {
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83);
      //tel = 0;
    }
    else if (tel == 4)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x88);
    else if (tel == 5)
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x92);

    SendPacket(dest, (uint8_t *)&sendBuf, size);

    tel++;

Settings.h

// WR und DTU
#define DUMMY_RADIO_ID          ((uint64_t)0xDEADBEEF01ULL) 
#define SerialWR                0x104163500316ULL        // <<<<<<<<<<<<<<<<<<<<<<< anpassen
uint64_t WR1_RADIO_ID           = Serial2RadioID (SerialWR);    // ((uint64_t)0x5279607201ULL);          
#define DTU_RADIO_ID            ((uint64_t)0x7311880801ULL)

Das Ergebnis:

20:19:58.728 -> Send... CH75
20:19:58.774 -> 00 7311880801 0092 12 1  92 63500316 63500316 000300000000000091D09E 1
20:19:58.774 -> ---- neues cmd=0
20:19:58.774 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 145.00 37328.00 53406.00 40502.00 13878.00 13981.00 
20:19:58.774 -> analyse words:50331648.00 0.00 0.00 0.00 145.00 37328.00 9556126.00 2446368256.00 3500029440.00 2654353152.00 909548928.00 916290496.00 

20:20:03.760 -> 00 7311880801 0094 12 2  88 63500316 63500316 00030000000000008B7436 1
20:20:03.760 -> ---- neues cmd=0
20:20:03.760 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 139.00 35700.00 29750.00 13867.00 11083.00 19437.00 
20:20:03.760 -> analyse words:50331648.00 0.00 0.00 0.00 139.00 35700.00 9139254.00 2339649024.00 1949707136.00 908807168.00 726396352.00 1273878016.00

20:20:49.802 -> 00 7311880801 00C0 18 0  91 63500316 63500316 012D0001095D1389003D085D00FFE550EF 1
20:20:49.802 -> P1.Udc  :26.50 
20:20:49.802 -> P1.Idc  :238.27 
20:20:49.802 -> P1.Pdc  :3507.20 
20:20:49.802 -> P2.Udc  :1562.40 
20:20:49.802 -> P2.Idc  :238.08 
20:20:49.802 -> P2.Pdc  :6550.90

Log anbei.
Die etwas anders aussehenden Zeilen sind aus dem Python-Mitschnitt und 
zeitlich relativ passend.
Die Werte stimmen natürlich noch nicht, aber hey, der WR redet mit mir 
:)

Der tel==3 Part passt noch nicht, wird aber offenbar nicht benötigt.

Ein kleiner weiterer Schritt in die richtige Richtung.

Danke Euch allen!

[Lukas P. (lumapu)]

Holger S. schrieb:
> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen
> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem
> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate
> ein neues Gerät zu bekommen.

Das wurde einfach aus dem Beispiel der MQTT lib übernommen, schau mal in 
der mqtt.h relativ weit unten, der neue Name wird 'extra' erzeugt, warum 
kann ich nicht sagen, evtl. findet man bei PubSubClient (so heißt die 
lib) etwas darüber.

Bei der nächsten Speicheränderung können wir den CRC wie isnoAhoy 
geschrieben hat noch weiter nach hinten schieben. Mit 6 WR bist du 
aktuell Spitzenreiter und musst sowieso selbst kompilieren. Bin gespannt 
ob das funktioniert. Ich glaube bis zu 4 wurden schon getestet.

[Marcel A. (a-marcel)]

Hallo,

habe seit langem mal wieder den Code geupdated und vorher hat alles sehr 
gut funktioniert aber mit dem neusten update bekomme ich gar keine Daten 
mehr. Ich sehe nur noch

Error while retrieving data: last frame missing: Request Retransmit
Error while retrieving data: last frame missing: Request Retransmit
Free heap: 0x430f8
Inverter #0 no Payload received! (retransmits: 0)
Requesting Inverter SN val = 0x112173109025

Gerät wurde nicht bewegt (Antenne ist gleich) und vor dem update ging es 
tadellos. Habe einen HM-400. Hat noch jemand das Problem ?

Vielen dank

P.s.: Ich habe was gelesen, das man jetzt schon weit ist die Einspeisung 
zu kontrollieren ? Ist das korrekt ?

[Lukas P. (lumapu)]

Hast du auch den Gegencheck mit der alten Version gemacht?
Ich habe zugegeben auch immer wieder Probleme, aber ich denke es liegt 
sehr stark an der Umgebung und die ändert sich doch mehr als man es 
erwarten würde. Gestern habe ich den ESP unters Dach getragen und 
ständig mit Abstürzen zu helfen gehabt (Wifi?) und heute konnte ich 
wieder aus dem Keller funken (aber auch nur in einer exakten 
Ausrichtung). Liegt die Antenne bisschen anders bekomme ich keine Frames 
rein. Ich hoffe die Ausrichtung passt morgen noch ...

Die Einspeisung zu reduzieren gilt bisher nur für die MI Serie - und 
dort wird grad heftig an der Kommunikation der ersten Daten geschraubt. 
Also bisher kann man noch keinen WR begrenzen.

[Ziyat T. (toe_c)]

Daniel M. schrieb:
> Habe den Code von Hubi etwas angepasst:
> NRF24_SendRcv.ino:

Gratuliere :-)

Ich mache so, aber ohne erfolg:

uint8_t MID = 0x36;   //0xB9=0x39      0xB8 38
uint8_t CMD = 0;
.
.
if (tel > 5)
tel = 0;

if (MID > 0x0039)
MID= 0x0036;

if (tel == 0) {
  #ifdef ESP8266
  hmPackets.SetUnixTimeStamp (getNow());
  #endif
  //do not need size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest 
>> 8, DTU_RADIO_ID >> 8);
  }
else
  size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, 
DTU_RADIO_ID >> 8, MID, CMD);

SendPacket (dest, (uint8_t *)&sendBuf, size);
MID++;
tel++;

[IsnoAhoy (Gast)]

Hallo Marcel A.,
bzgl Power Limitation würde ich Doch auf das o.a. Excel Sheet 
"RF_communication_protocol-V6.5.xlsx" verweisen.
Da steht mE alles drin was in der DTU Pro an Request und Response von 
MI-&HM-Wechselrichtern verstanden und gesendet wird. U.a. sind da auch 
die Kommandos zur Power Limitierung auf X % enthalten. Speziell auf der 
Seite „control commands“ findet sich das Limit Power command word 0x51 
subcommand 0x5A5A und die Antwort 0xD1.
Die Implementierung der Kommandos von Hoymiles dazu findest Du in der 
o.a. usart_nrf.c (147 KB).

@Ziyat T. und Daniel M.,
ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer 
noch ein Timestamp mitgesendet zu werden.
Laut der Command Word Summary sind die Commands words (früher hier MID) 
für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11 
(optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse 
MI-1000..1500)
Das Command word für die HM-Serie ist durchweg 15 und die Antwort 95.
Bitte schaut Euch doch mal die Screenshots aus dem Excel bzw. die 
entsprechenden Command words auf der Seite „data collection 
instructions“ unterhalb der Zeile „Legacy poll data command“ an.
Dort ist nach der Target Address nur noch das Subcommand / Userdata 00 
und die CRC-8, aber kein Timestamp wie beim Command word 15 für die 
HM-Serie.

[Ms L. (mslookup)]

Hallo zusammen,
auch wenn es nicht ganz zum aktuellen Stand der Unterhaltungen hier im 
Forum passt: Nachdem ich mehrere Stunden an mehreren Tagen verzweifelt 
probiert habe die NRF24 Python Library, also die Dependency für die 
Raspberry Version von Ahoy, korrekt zu installieren, habe ich mich 
gestern direkt an den Entwickler von NRF24 über github gewendet 
(https://github.com/nRF24/RF24/issues/845) - da ich, egal wie ichs 
gedreht und gewendet bekommen habe, den Python Wrapper für NRF24 nicht 
installiert bekommen habe.

Ich würde gerne meine Schritte weitergeben, sollte jemand an dem selben 
Punkt verzweifelt sein wie ich.

- Install Raspberry Pi OS lite x86 with raspberry pi imager
- Connect nrf24 module to raspberry pi (as described in github)
- Login with user pi
- Execute "sudo apt update && sudo apt -y upgrade"
- Execute "sudo raspi-config" and
-- "Expand filesystem" in "Advanced Options"
-- Activate "SPI" in "Interface Options"
-- "Finish" to exit raspi-config Tool, reboot YES!
- Login as pi user again

sudo apt install cmake git python3-dev libboost-python-dev python3-pip python3-rpi.gpio
sudo ln -s $(ls /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3*.so | tail -1) /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3.so
git clone https://github.com/nRF24/RF24.git
export RF24_DRIVER=SPIDEV
cd RF24
rm Makefile.inc #just to make sure there is no old stuff
mkdir build && cd build
cmake ..
make
sudo make install
cd ../pyRF24
rm -r ./build/ ./dist/ ./RF24.egg-info/ ./__pycache__/ #just to make sure there is no old stuff
python3 -m pip install --upgrade pip
python3 -m pip install .
python3 -m pip list #watch for RF24 module - if its there its installed
cd ..
cd examples_linux/
python3 getting_started.py # to test and see whether RF24 class can be loaded as module in python correctly

Wenn im letzten Schritt keine Fehlermeldungen kommen, dann sollte der 
NF24 Wrapper erfolgreich installiert sein.

Danke euch allen für eure Arbeit :)

[Daniel M. (daniel_m821)]

IsnoAhoy schrieb:
> @Ziyat T. und Daniel M.,
> ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer
> noch ein Timestamp mitgesendet zu werden.
> Laut der Command Word Summary sind die Commands words (früher hier MID)
> für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11
> (optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse
> MI-1000..1500)

Die 0x09 und 0x11 mit den Antworten 0x88,0x89 sowie 0x91 unx 0x92 sind 
beim TSUN identisch mit dem was ich aus der MI-Serie gesehen habe. 
Offenbar haben die Chinesen einfach das MI-Modell kopiert.

Der Timestamp wird gesendet, die Funktion bewirkt aber garnichts, der WR 
ignoriert das einfach.
Hubi verwendet einfach ein i++ um den CMD hochzuzählen und entsprechende 
Abfragen zu schicken, zu sehen in dem Post weiter oben. Die passende pid 
für die Antwort wird gleich mitgegeben.

Mittlerweile hab ich auch die Felder zu den Antworten passend gemappt.
Der Part nach der WR-Temperatur fehlt mir noch, ich bin nicht sicher ob 
das CRC16 oder noch Werte sind, da mit die Gesamtproduktion der MPPT 
noch fehlt.
Weiter fehlen auch noch die Statusbytes. Vielleicht kriege ich das heute 
abend noch hin.

> Probiere mal:
> 1. sendCmdPacket(invId, 0x09, 0x00, true);
> 2. laß den Rest der Routine unter sendTimePacket einfach mal weg.

Der Teil ist mir ehrlich gesagt, zu hoch. Ich weiß nicht an welcher 
Stelle ich das einfügen soll.
Wenn du mir da kurz auf die Sprünge hilfst, teste ich das gerne.
Eventuell kannst du auch kurz was zaubern, womit ich 0x09 und 0x11 im 
Wechsel senden kann, dann probier ich mich mit dem Einbau daran aus.

[redien (Gast)]

Hallo,
die Platinen sind wahrscheinlich schon weg oder? Konnte leider nichts 
finden und könnte 3 Stück gebrauchen.
Danke und Gruß

[IsnoAhoy (Gast)]

Hallo Daniel M.,
ja, der TSUN scheint nur ein rebrandeter Hoymiles MI-Wechselrichter zu 
sein. Das hatten wir aufgrund der Seriennummer auch schon vermutet.

Meine Angaben bezogen sich auf den code von Lukas unter tools/esp8266 da 
ich den Rest für Nano und die nrfScan tools von Hubi und anddren nie 
genutzt habe.

Speziell bezog sich 1. & 2. auf die hmRadio.h Zeile 162ff

https://github.com/grindylow/ahoy/blob/e05d2220cb1f99bbbf4083d62b0281d096ceeccb/tools/esp8266/hmRadio.h#L162

[IsnoAhoy (Gast)]

Hallo Daniel M.,

habe mir den code nochmal genauer angesehen und vermutlich kannst Du die 
beiden Aufrufe von sendTimePacket und die anderen Aufrufe von 
sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe 
ersetzen und anpassen.

app::loop
Ab Zeile 295ff kommt die Senderoutine:
https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L339

app::processPayload
hier erfolgt das Lesen und Sammeln der Payload Fragmente und der bisher 
HM spezifische Retransmit:

https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L413

Im zweiten Teil dem processPayload könntest Du also nach Empfang der 
ersten Antwort 0x89 die zweite Anfrage 0x11 stellen und auf die Antwort 
0x91/0x92 warten. Dann solltest Du die Antworten jeweils in den 
Variablen/Strukturen ablegen und mit den Definitionen in miDefines.h 
(Kopie von hmDdfines.h) auslesen.

[Ameise (Gast)]

nur zur Info:  Habe ich bei ebay-kleinanzeigen gefunden

[oxylog (Gast)]

Guten Morgen!
Leider bin ich noch Anfänger auf dem Gebiet, habe mich aber an einem 
PCB-Design versucht, welches ich hier angehängt habe (habe keinen 
Github-Account; kann bei Gefallen gerne dort übernommen werden).

Designt mit EasyEDA;
Ich habe versucht, Platinenplatz einzusparen und gleichzeitig auch noch 
die Pins nochmals anzulegen (für weitere Spielereien wie 5/3,3v externe 
Stromversorgung ohne Löten etc). Ebenfalls habe ich den 100µF (oder 
andere Größe nach Belieben; das µ wollte mir das Programm nicht auf das 
Board beschriften ;-)) Kondensator zwischen GND und 3,3v auf das Board 
gepackt.

Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€.

Verbesserungsvorschläge gerne willkommen

[oxylog (Gast)]

oxylog schrieb:
> Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€.

kleiner Edit: 3 Boards habe ich bei Aisler für unter 10€ geordert

[Damian B. (damian_b)]

Hallo, ich habe ein Problem mit meiner ide. Ich bin weit weg von zu 
Hause und kann es nicht lösen. Könnte jemand bitte hier eine bin-Datei 
mit der neuesten Version für ESP anhängen. Danke im Voraus

[Günter H. (gnter_h534)]

Für das Wemos D1 mini-Board ist das hier:

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
>

sudo python3 -um hoymiles --log-transactions --verbose --config 
>     from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, 
> RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
> ImportError: 
> /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: 
> undefined symbol: _ZN4RF2410setPALevelEh
>

Sieht nach einer kaputten Installation des RF24-Moduls aus. Warte noch 
ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01, was man 
einfach komplett mit pip installieren kann. Kein fuckery mehr mit 
irgendwelchen selbst kompillierten blobs im System verteilen, die nur 
kompillieren, wenn man sie im richtigen Unterverzeichnis kompilliert.

```
ModuleNotFoundError: No module named 'cross.crossunixccompiler'
```

[Peter L. (leliep)]

Ameise schrieb:
> nur zur Info:  Habe ich bei ebay-kleinanzeigen gefunden

Da hat sich ja die Arbeit der Community gelohnt…

[Daniel M. (daniel_m821)]

IsnoAhoy schrieb:
> Hallo Daniel M.,
>
> habe mir den code nochmal genauer angesehen und vermutlich kannst Du die
> beiden Aufrufe von sendTimePacket und die anderen Aufrufe von
> sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe
> ersetzen und anpassen.

Hi,

Danke, ich versuche es mal die kommenden Tage.
Mit etwas experimentieren habe ich zumindest schonmal eine Payload 
gesehen, auch wenn das noch nicht zuverlässig geklappt hatte.

Deine Hinweise auf die Stellen schaue ich mir genauer an, an einigen 
Stellen war ich schon dran.

[Damian B. (damian_b)]

Meine ESP-Version 4.17 hat ein Problem, ich kann es nicht anpingen, das 
www funktioniert nicht, manchmal ist es 2 Minuten nach dem Start. Mir 
ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1 
Sekunde aktualisiert wird, ist das richtig?

[Holger S. (skusi)]

Ameise schrieb:
> nur zur Info:  Habe ich bei ebay-kleinanzeigen gefunden

Sauerei, das sich da wieder jemand dran bereichern muß.
Kann man da nix gegen machen ?

Pfui ! von mir...

[Holger S. (skusi)]

Ein paar Fragen:
Wenn ich in der config.h folgendes eintrage:

// fallback WiFi info
#define FB_WIFI_SSID    "Flackerlighter"
#define FB_WIFI_PWD     "meinPasswort"

1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem 
WLan auf ?
Console:

Main::setupStation
connect to network 
'⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮ 
⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮'  ...
...............................
........................................................................ 
............................
Main::setupAp

---------
AP MODE
SSDI: AHOY-DTU
PWD: esp_8266
Active for: 60 seconds
---------

2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert 
verwendet ?

3. Wie genau sind die Statistic Werte zu verstehen:
Receive success: 18
Receive fail: 17
Send Cnt: 128

sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ?

Gruß Skusi

[Holger S. (skusi)]

isnoAhoy schrieb:
> Hallo Holger,
> wie Lukas schon erwähnt hat in eep.h:
>             EEPROM.begin(4096);
>
> und in den defines.h das Ganze gleich dynamisch gestalten:
>
> #define ADDR_SETTINGS_CRC   ADDR_NEXT          + CRC_LEN
>
> #if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
> #error address overlap!
> #endif
>
> #if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
> #error EEPROM size exceeded! Configure less inverters?
> #endif

Hallo isnoAhoy,
ich habe die Änderungen so in die Dateien eingepflegt, aber sobald ich 
mehr als 4 inverter in die config.h eintrage bootet der Wemos nicht und 
sendet.
Settings not valid, erasing ...

???

[Einhart P. (einhart)]

Holger S. schrieb:
> Sauerei, das sich da wieder jemand dran bereichern muß.
> Kann man da nix gegen machen ?
>
> Pfui ! von mir...

Kannst du ausschließen dass jemand die Software selbst entwickelt hat?

[Daniel R. (daniel92)]

Jan-Jonas S. schrieb:
> Warte noch
> ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01

Moin Jonas, danke für die Antwort. :)
Ok, du bist schon dabei das ganze miteinander zu kombinieren?

Kann ich irgendwie helfen?

Mein Ziel ist es zukünftig alles direkt am Pi zu betreiben. Dann brauch 
ich nicht extra noch ein WiFi-Client ins Netz zu halten. :P

[Lukas P. (lumapu)]

Damian B. schrieb:
> Mir ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1
> Sekunde aktualisiert wird, ist das richtig?

ja, das hat isnoAhoy geändert und führt bei uns zu stabileren Systemen. 
Es hängt jetzt fix am Abfrageintervall, die Zeit wird sogar auf der 
Index Seite ausgegeben
(also wie lange das Intervall ist)

[Lukas P. (lumapu)]

Holger S. schrieb:
> 1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem
> WLan auf ?

Habe es selbst nie getestet, nur implementiert. Evtl findest du den 
Fehler?

> 2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert
> verwendet ?

Die kWp der angeschlossenen Module. Hiermit wird die Einstrahlung in 
Prozent berechnet, ganz interessant um zu wissen wie optimal deine 
einzelnen Module stehen.

> 3. Wie genau sind die Statistic Werte zu verstehen:
> Receive success: 18
> Receive fail: 17
> Send Cnt: 128
>
> sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ?

Success heißt die komplette Payload wurde empfangen. Fail sind 
dementsprechend die fehlgeschlagenen Payloads.
SendCnt sind alle gesendeten Frames, auch Retransmits. In besten Fall 
wäre success und SendCnt identisch und fail auf 0.

[Lukas P. (lumapu)]

Einhart P. schrieb:
> Holger S. schrieb:
>> Sauerei, das sich da wieder jemand dran bereichern muß.
>> Kann man da nix gegen machen ?
>>
>> Pfui ! von mir...
>
> Kannst du ausschließen dass jemand die Software selbst entwickelt hat?

Kann man nicht, aber sie wird sehr sicher auf unseren Erkenntnissen 
aufbauen. Wie sieht es denn lizenztechnisch hier aus? Ich denke ua., 
dass Christian Bauer hier auch mitliest.
@Jan-Jonas: Ich glaube du bist auf diesem Gebiet fit, was sollen wir für 
die (nahe) Zukunft machen?

Für mich sieht es so aus als würde sich jemand mit unserem Wissen zu 
bereichern, irgendwie arm, hoffentlich ein Einzelfall. Bei einem Preis 
von 10€ könnte man nichts sagen, aber hier ist eine Marge von 40€ 
veranschlagt.
Der kostenlose Support wird von Mikrokontroller.net geleistet oder wie?

[isnoAhoy (Gast)]

Hallo Holger S.,

ja das ist erstmal richtig, Du hast ja eine größere Config und die CRC 
Summe ist weiter nach hinten gerutscht, somit stimmt das nicht mehr und 
er löscht alle Settings (außer den WiFi Settings).

Du mußt dann im Setup die Wechselrichter Daten wieder eintragen. Ich 
glaube da gab es ein Problem, daß er aktuell keine sinnigen Default 
Werte einträgt sondern alles mit 0xFF auffüllt. D.h. Du mußt Alles in 
den Settings entfernen und nur die relevanten Teile eintragen. Da auch 
die Pin Settings fehlen kann er auch keinen nRF24 finden und startet 
immer wieder neu bzw. den Access Point.

Du kannst auch mal die folgenden u.a. Einträge mit #pragma error 
versuchen, vielleicht bekommst Du dann auch etwas mehr Debug Output. Ich 
weiß nämlich ehrlich gesagt nicht, wieviele Bytes eine Inverter Config 
groß ist ?

#define INV_CH_CH_NAME_LEN  MAX_NUM_INVERTERS  MAX_NAME_LENGTH  4 // 
(4 channels)

Laut der defines.h reserviert er immer vier Kanalnamen plus den 
Inverternamen à 16 Byte, also 5*16 Byte. Das sollten bei ca. 200 Byte 
für die WIFI und MQTT Settings ca. 100 Byte mal sechs Inverter weit 
unter 4096 sein.

#define ADDR_SETTINGS_CRC   ADDR_NEXT          + CRC_LEN

#if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
#pragma error "address overlap! (ADDR_SETTINGS_CRC="+ ADDR_SETTINGS_CRC 
+", ADDR_NEXT="+ ADDR_NEXT +")"
#endif

#if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
#pragma error "EEPROM size exceeded! (ADDR_SETTINGS_CRC="+ 
ADDR_SETTINGS_CRC +", CRC_LEN="+ CRC_LEN +")"
#pragma error "Configure less inverters? (MAX_NUM_INVERTERS=" + 
MAX_NUM_INVERTERS +")"
#endif

PS: Support-Anfragen der Käufer solange unsere Software noch so schöne 
Macken wie "Settings not valid, erasing ..." hat sind da bestimmt schon 
inklusiv =^p

[Lukas P. (lumapu)]

So das Angebot in Kleinanzeigen ist deaktiviert, Dank meiner Frau.

Evtl. sollten wir zusätzlich diese Lizenz aufnehmen um unsere Belange 
besser auszudrücken:

https://commonsclause.com/

Wir machen das hier für die Community, also Maker und nicht für 
jedermann. Alle anderen sollen bei hoymiles eine DTU kaufen.

[Peter L. (leliep)]

Einhart P. schrieb:
> Holger S. schrieb:
>> Sauerei, das sich da wieder jemand dran bereichern muß.
>> Kann man da nix gegen machen ?
>>
>> Pfui ! von mir...
>
> Kannst du ausschließen dass jemand die Software selbst entwickelt hat?

Das Gehäusedesign stammt jedenfalls von mir.
https://github.com/grindylow/ahoy/tree/main/tools/esp8266/WemosD1_NRF24_Case

[isnoAhoy (Gast)]

@Jan-Jonas & Lukas

the current implementation we use for HM-inverters seems to be in the 
Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or 
`usart_nrf3.h`.
There are also the user data starting with `0x80` in `byte[10]` and 
after that the Sub Command mentioned in the Excel sheet.

```
/***********************************************
** Function name: �豸����
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
uint8_t UsartNrf3_Send_PackDevControl(uint8_t *target_adr, uint8_t 
*rout_adr, uint16_t ControlMode, uint8_t *ControlData, uint8_t Num)
{
    uint8_t i = 0;
    uint16_t TempCrc = 0;
    uint8_t temp_dat[UART_LEN];
    uint16_t DatCrc = 0xffff;
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//ͷ
    temp_dat[0] = DEVCONTROL_ALL;   //command
    memcpy(&temp_dat[1], target_adr, 4);//Դ��ַ
    memcpy(&temp_dat[5], rout_adr, 4);//Ŀ���ַ
    temp_dat[9] = 0x80;//
    temp_dat[10] = ControlMode >> 8; //��������
    temp_dat[11] = ControlMode;//��������
    //CurSendPackageDataType = ControlMode;
    memcpy(&(temp_dat[11]), ControlData, Num); //���Ʋ���

    for(i = 10; i < 11 + Num + 1; i++)
    {
        if((i - 10) % 2 == 1)
        {
            TempCrc = (temp_dat[i - 1] << 8) | (temp_dat[i]);
            DatCrc =  CalcCRC16t(TempCrc, DatCrc);
        }
    }

    temp_dat[12 + Num] = DatCrc >> 8;
    temp_dat[13 + Num] = DatCrc;
    temp_dat[14 + Num] = Get_crc_xor(&temp_dat[0], 15 + Num);
    i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], (15 + 
Num)); //�����滻
    Uart_SendBuffer[(i + 1)] = ETX; //β
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}
```

According to the implementation in `usart_nrf3.h` the Sub Command is 
defined as `DataType` in `usart_nrf3.h`:
```
typedef enum
{
    InverterDevInform_Simple = 0, // 0x00
    InverterDevInform_All = 1, // 0x01
    GridOnProFilePara = 2, // 0x02
    HardWareConfig = 3, // 0x03
    SimpleCalibrationPara = 4, // 0x04
    SystemConfigPara = 5, // 0x05
    RealTimeRunData_Debug = 11, // 0x0B
    RealTimeRunData_Reality = 12, // 0x0C
    RealTimeRunData_A_Phase = 13, // 0x0D
    RealTimeRunData_B_Phase = 14, // 0x0E
    RealTimeRunData_C_Phase = 15, // 0x0F
    //RealTimeRunData_Password = 16, // 0x10
    AlarmData = 17, // 0x11
    RecordData = 18, // 0x12
    InternalData = 19, // 0x13
    ExternalData = 20, // 0x14
} DataType;
```
Especially the 0x0B rings a bell with me and the traces so far!

[isnoAhoy (Gast)]

Sorry that was the wrong function / method and the references in the 
Excel sheet e.g. `byte[10]` are including the SOF `0x7E`, whilst the 
implementation first sets up `temp_dat[]` which is without the SOF and 
EOF `0x7F`, hence the shift.

```
/***********************************************
** Function name: �豸������Ϣ���
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
uint8_t UsartNrf3_Send_PackDataCommand(uint8_t *target_adr, uint8_t 
*rout_adr, uint8_t DataType, uint8_t DataMode, uint8_t Gap, uint8_t 
*Password)
{
    uint8_t i = 0;
    uint16_t TempCrc = 0;
    uint8_t temp_dat[UART_LEN];
    uint16_t DatCrc = 0xffff;
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//ͷ
    temp_dat[0] = 0x15;   //command
    memcpy(&temp_dat[1], target_adr, 4);//Դ��ַ
    memcpy(&temp_dat[5], rout_adr, 4);//Ŀ���ַ
    temp_dat[9] = 0x80;//��֡��ʶ
    temp_dat[10] = DataType;//�û�����:��������
    CurSendPackageDataType = DataType;//��ǰ�������������
    temp_dat[11] = DataMode;//�û�����:����ģʽ
    // 
memcpy(&(temp_dat[12]),&(RTC_GetWorldSecond(Dtu3Detail.Property.timezone 
)),4);//�û�����:΢��ͬ��ʱ��
    temp_dat[12] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >> 
24;
    temp_dat[13] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >> 
16;
    temp_dat[14] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >> 
8;
    temp_dat[15] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone);
    //RTC_GetWorldSecond(Dtu3Detail.Property.timezone);
    temp_dat[16] = Gap;//�û�����:�����ϴ����������
    temp_dat[17] = Gap >> 8;
    memset(&(temp_dat[18]), 0, 2); //�û�����:���������յ��ĸ澯���
    memcpy((&temp_dat[20]), Password, 4); //�û�����:��������

    for(i = 10; i < 24; i++)
    {
        if((i - 10) % 2 == 1)
        {
            TempCrc = (temp_dat[i - 1] << 8) | (temp_dat[i]);
            DatCrc =  CalcCRC16t(TempCrc, DatCrc);
        }
    }

    temp_dat[24] = DatCrc >> 8;
    temp_dat[25] = DatCrc;
    temp_dat[26] = Get_crc_xor(temp_dat, 26);
    i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 27); 
//�����滻
    Uart_SendBuffer[(i + 1)] = ETX; //β
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}
```