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 =)
:
Bearbeitet durch User
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
leider nicht mehr brandaktuell, es gibt schon die 0.4.13.
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 ;-)
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
:
Bearbeitet durch User
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
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
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?"
@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
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.
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.
Hallo Lukas P. warum ist in hmRadio.h eigentlich Kanal 40 nicht als Receive Channel mit angegeben ?
1 | #define RX_CHANNELS 5 |
2 | ... |
3 | // Depending on the program, the module can work on 2403, 2423, 2440, 2461 or 2475MHz. |
4 | // Channel List 2403, 2423, 2440, 2461, 2475MHz |
5 | mRxChLst[0] = 03; |
6 | mRxChLst[1] = 23; |
7 | mRxChLst[2] = 40; |
8 | mRxChLst[3] = 61; |
9 | mRxChLst[4] = 75; |
10 | ... |
11 | uint8_t getRxNxtChannel(void) {
|
12 | if(++mRxChIdx >= RX_CHANNELS) |
13 | ... |
14 | 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.
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 :-)
:
Bearbeitet durch User
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?
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. 😅
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
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.
:
Bearbeitet durch User
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 ?
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.
:
Bearbeitet durch User
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.
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.
Ich habe von meinem MI-300 nun geschafft Antworten zu empfangen, wenngleich auch noch keine nutzbaren Daten: Anfrage via nrf24 (on-air):
1 | Address 1319406101 Data 15 77665544 88776655 81 58 |
2 | WR-rev mid DTU dummy cmd crc |
Antwort vom WR (on-air):
1 | Address 4455667701 Data 15 77665544 61401913 81 bf |
2 | 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
:
Bearbeitet durch User
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?
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 :-)
1 | MID+ dtu + wr +CMD+crc |
2 | zb 07 77665544 61401913 81 aa |
Werde berichten... Hoffentlich zerschiesse ich mir den WR damit nicht
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/
:
Bearbeitet durch User
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.
Alles klar, danke für die Arbeit. Wichtig natührlich alles fleißig zu loggen... :D
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.
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
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?
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.
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
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.
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 ?
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
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
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"
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
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?
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
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.
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
Mehr DTU-Pro <-> MI1500 logs Diesmal WR ist stumm, weil Nacht, DTU-Pro neu gestartet
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?
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
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
Der Tip mit den Modulen mit Antenne, die irgendwie nicht so ganz laufen, war gut. Ardunio-Konsole:
1 | 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 |
2 | 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 |
3 | 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 |
4 | 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 |
5 | 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:
1 | 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:
1 | 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 |
2 | Error while retrieving data: max() arg is an empty sequence |
3 | |
4 | 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 |
5 | Error while retrieving data: Frame 1 missing: Request Retransmit |
6 | |
7 | 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 |
8 | 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 |
9 | Error while retrieving data: Missing packet: Last packet 2 |
10 | |
11 | 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 |
12 | 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 |
13 | Error while retrieving data: Missing packet: Last packet 2 |
14 | |
15 | 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 |
16 | Error while retrieving data: Missing packet: Last packet 3 |
17 | |
18 | 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 |
19 | 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 |
20 | Error while retrieving data: Missing packet: Last packet 2 |
21 | |
22 | 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 |
23 | Error while retrieving data: Missing packet: Last packet 3 |
24 | |
25 | 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 |
26 | Error while retrieving data: Missing packet: Last packet 1 |
27 | |
28 | 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 |
29 | Error while retrieving data: Missing packet: Last packet 2 |
30 | |
31 | 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 |
32 | Error while retrieving data: Missing packet: Last packet 3 |
33 | |
34 | 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 :)
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.
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:
1 | 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 |
2 | channel 40: b2 6b 50 03 16 63 50 07 16 00 03 00 00 02 00 20 02 91 |
3 | channel 23: a8 6b 50 03 36 63 50 03 16 00 13 00 00 0a d7 26 af bb |
4 | 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 |
5 | channel 3: b2 63 50 03 36 63 50 03 16 00 13 01 00 00 00 80 08 93 c3 93 3a aa |
6 | channel 3: 94 63 50 03 16 63 50 03 14 00 43 00 00 00 10 00 01 91 |
7 | 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 :)
Ich hab gerade nochmal ein PR für python auf gemacht. Habe den DebugDecodeAny Dekoder nochmal überarbeitet. Beispiel: (auf der Kommandozeile)
1 | tools/rpi$ python3 -c 'import hoymiles; hoymiles.decoders.DebugDecodeAny(bytes.fromhex("5c 00 00 b4 91 00 00 ab bf 03 71 03 78"))'
|
2 | payload has 13 bytes |
3 | |
4 | Field view: int |
5 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
6 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
7 | >B 92 0 0 180 145 0 0 171 191 3 113 3 120 |
8 | |
9 | Field view: shorts |
10 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
11 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
12 | >H 23552 180 37120 171 48899 28931 |
13 | >H 0 46225 0 43967 881 888 |
14 | |
15 | Field view: longs |
16 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
17 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
18 | >L 1543504052 2432696491 3204673795 |
19 | >L 46225 43967 57738104 |
20 | >L 11833600 11255555 |
21 | >L 3029401600 2881422193 |
22 | type utf-8 : utf-8 decode error |
23 | 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:
1 | 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 |
2 | 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.
@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?
Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu bekommen. Wie habt ihr das gemacht (ohne eine DTU)?
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.
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?
Also so:
1 | python3 py-nrf24/send.py --crc 1 1319406101 15776655446140191381 |
2 | ..sendet die payload 15776655446140191381+crc8 an 13:.19:40:61:01 |
3 | 77665544 ist die erfundene SN meines Raspi |
4 | 61401913 ist die echte SN meines WR. |
5 | |
6 | Sent: to Address 1319406101 Data 15 77665544 88776655 81 58 |
7 | Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf |
8 | |
9 | Das geht auch ohne der S/N des WR in der Anfrage |
10 | python3 py-nrf24/send.py --crc 1 1319406101 15776655440000000081 |
11 | |
12 | Sent: to Address 1319406101 Data 15 77665544 00000000 81 94 |
13 | 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.
:
Bearbeitet durch User
Habe was neues gefunden:
1 | nrf24-dest pcf payload |
2 | anfrage: 13 19 40 61 01 (16/0/0) df 02 00 776655441111111100fcaf85 0b |
3 | 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.
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
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..
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.
1 | sende 15:77665544:22222222:80 an WR |
2 | empfange 15:77665544:61401913:80 als Antwort an Adresse 44:55:66:77:01 |
3 | 10sek pause |
4 | sende df0200:7766 55443333 3333:00 an WR |
5 | 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
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.
Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ und CE zu tauschen.
@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.
@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!
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 :)
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.
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
:
Bearbeitet durch User
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. schrieb: > Hallo zusammen, Nachtrag: Hier eine bessere Quelle: https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt
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.
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!?
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?
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 ?
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".
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Hallo zusammen, ich versuche gerade das NRF auf dem Raspi zum laufen zu bringen. Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".
1 | sudo python3 -um hoymiles --log-transactions --verbose --config /home/dtu/ahoy.yml | tee -a log2.log |
2 | Traceback (most recent call last): |
3 | File "/usr/lib/python3.7/runpy.py", line 183, in _run_module_as_main |
4 | mod_name, mod_spec, code = _get_module_details(mod_name, _Error) |
5 | File "/usr/lib/python3.7/runpy.py", line 142, in _get_module_details |
6 | return _get_module_details(pkg_main_name, error) |
7 | File "/usr/lib/python3.7/runpy.py", line 109, in _get_module_details |
8 | __import__(pkg_name) |
9 | File "/home/Hoymiles_NRF24/hoymiles/__init__.py", line 14, in <module> |
10 | 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 |
11 | 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?
:
Bearbeitet durch User
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.
1 | ----------------------- |
2 | rcv CH:75 00 1234567801 00BE 17 3 95 72014650 72014650 830000000403E8012900163010E7B896 B896 1 |
3 | Udc.CH1=29.4 V |
4 | Idc.CH1=0.14 A |
5 | Pdc.CH1=4.2 W |
6 | Udc.CH2=30.0 V |
7 | Idc.CH2=0.15 A |
8 | Pdc.CH2=4.6 W |
9 | E-Total.CH1=145.471 KWh |
10 | E-Total.CH2=146.316 KWh |
11 | E-Tag.CH1=1568 Wh |
12 | E-Tag.CH2=1610 Wh |
13 | Uac=233.6 V |
14 | Freq.ac=49.99 Hz |
15 | Pac=8.4 W |
16 | Ipv=0.04 A |
17 | WR-Temp=29.7 °C |
18 | Status=1000 |
19 | E-heute=3178 Wh |
20 | 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
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
:
Bearbeitet durch User
> Was die DTU sendet ist dauernd: 00 f2 bis 00 fd
Das liest sich so:
1 | 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...?
:
Bearbeitet durch User
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. :)
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
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
1 | 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ß
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 >
1 | If the DTU cannot detect all the microinverters in the system over |
2 | > 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...
@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 ;-)
:
Bearbeitet durch User
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.
1 | 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2] <-anfrage vom Raspi |
2 | 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...
@ 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
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
Bei mir so - ich habe nun einfach mal deine Adressen kopiert.
1 | 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 |
2 | 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.
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?"
:
Bearbeitet durch User
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.
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
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?
@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
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. ;)
:
Bearbeitet durch User
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.
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
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
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. schrieb: > Bei mir so - ich habe nun einfach mal deine Adressen kopiert. > >
1 | > 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- |
2 | > raspi an WR |
3 | |
4 | das hier sollte 5a 5a 9e 0b sein |
5 | |
6 | > 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- |
7 | > antwort vom WR |
8 | > |
> > 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
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?"
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
:
Bearbeitet durch User
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.
Hallo, ich habe scheinbar ein Händchen für Suchfunktionen. :-) Im file usart_nrf.c ist definiert: UsartNrf_Send_PackSetLockOnOffCommand(...) Andreas
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 :)
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.
:
Bearbeitet durch User
Angehängte Dateien:
Also bei mir hat es funktioniert. Die ZIP ist 148MB groß.
Sieht nach den "Kronjuwelen" aus! Der Source Code lässt vermutlich keine Fragen mehr offen.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
Danke ! ! ! für den Link ! ! ! Danke Andreas ! ! !
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
@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
Angehängte Dateien:
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.
:
Bearbeitet durch User
Bingooo!!!!
1 | /*********************************************** |
2 | ** Function name: //Stellen Sie die Anti-Rückfluss-Parameter ein |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | |
7 | ** Returned value: ? |
8 | *************************************************/ |
9 | uint8_t UsartNrf_Send_PackSetRefluxPowerCommand(uint16_t reflux_power, uint8_t MainCmd, uint16_t SubCmd) |
10 | {
|
11 | uint8_t i = 0; |
12 | uint16_t j; |
13 | uint8_t temp_dat[UART_LEN]; |
14 | memset(temp_dat, 0, sizeof(temp_dat)); |
15 | Uart_SendBuffer[0] = STX;//Kopf |
16 | temp_dat[0] = MainCmd; //Anweisung |
17 | memset(&temp_dat[1], 0, 4); |
18 | memset(&temp_dat[5], 0, 4); |
19 | // |
20 | // MIReal[PortNO].Data.NetCmd = NET_TURN_ON; |
21 | // if(MIReal[PortNO].Data.NetCmd == NET_TURN_ON) //开机状态 |
22 | // {
|
23 | temp_dat[9] = SubCmd & 0XFF00 >> 8; |
24 | temp_dat[10] = SubCmd & 0XFF; |
25 | temp_dat[11] = reflux_power * 100 / (EVERY_PORT_POWER * 10 * Dtu3Detail.Property.PortNum); //Prozentsatz der Leistungsbegrenzung |
26 | temp_dat[12] = reflux_power >> 8; //Hohe 8-Bit-Leistungsbegrenzung |
27 | temp_dat[13] = reflux_power & 0x00ff; //Niedrige Leistungsgrenze 8 Bit |
28 | // } |
29 | // else //开低功耗 |
30 | // {
|
31 | // temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a |
32 | // temp_dat[10] = SubCmd & 0XFF; |
33 | // temp_dat[11] = 0; |
34 | // temp_dat[12] = 20&0x00ff; |
35 | // temp_dat[13] = 20&0xff00>>16; |
36 | // } |
37 | temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC |
38 | i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //Vorwärtssubstitution |
39 | Uart_SendBuffer[i + 1] = ETX; //Ende |
40 | memset(temp_dat, 0, sizeof(temp_dat)); |
41 | return (i + 2); |
42 | } |
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
:
Bearbeitet durch User
Ich kann mit der Frage nichts Anfangen. Was möchtest du nochmal genau wissen? :)
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 )
:
Bearbeitet durch User
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.
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.
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
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.
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
Hier ist eine englische Übersetzung des RF communication protocol-V6.5xlsx
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.
Angehängte Dateien:
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.
Bingo - habe meinem MI-300 eine Antwort entlockt:
1 | Anfrage: |
2 | 13 19 40 61 01 (11/1/0) 09(61 40 19 13|51 22 22 22)00 51[cc 1a] |
3 | Antworten: |
4 | 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 ??] |
5 | 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 ??] |
6 | 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 ??] |
7 | |
8 | 0x0142 = 32,2 V_PVA_AVG |
9 | 0x0003 = 0,3 I_PVA_AVG |
10 | 0x091c = 233,2 GridVol_AVG |
11 | 0x1389 = 50,01 GridFre_AVG |
12 | 0x0071 = 11,3 APower_AVG |
13 | 0x0018 = 2,4 AEnergy |
14 | 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.
:
Bearbeitet durch User
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.
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
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
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.
:
Bearbeitet durch User
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.
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/
:
Bearbeitet durch User
Beitrag #7093597 wurde von einem Moderator gelöscht.
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 :)
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.
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
:
Bearbeitet durch User
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?
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.
:
Bearbeitet durch User
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..
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?
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.
Und diese Nummer ist dann bei Adress inverter einzutragen? Oder muss die noch irgendwie gewandelt werden?
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.
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 ;-)
Angehängte Dateien:
-
ESP_DTU_Platine1.jpg
68 KB -
ESP_DTU_Platine2.jpg
130 KB -
ESP_DTU_Platine3.jpg
140 KB
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...
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
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 !!!
Die Library von Git maniacbug/RF24 hab ich installiert...
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.
Beitrag #7095391 wurde von einem Moderator gelöscht.
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)
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...
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.
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 ?
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!
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.
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 ?
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.
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
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.
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:
1 | void sendTimePacket(uint64_t invId, uint32_t ts) { |
2 | //DPRINTLN(F("hmRadio.h:sendTimePacket"));
|
3 | sendCmdPacket(invId, 0x11, 0x91, false); |
4 | mTxBuf[9] = 0x00; // cid |
5 | mTxBuf[10] = 0x11; |
6 | //CP_U32_LittleEndian(&mTxBuf[12], ts);
|
7 | //mTxBuf[19] = 0x05;
|
8 | |
9 | uint16_t crc = crc16(&mTxBuf[10], 14); |
10 | mTxBuf[11] = (crc >> 2) & 0xff; |
11 | mTxBuf[12] = (crc ) & 0xff; |
12 | mTxBuf[13] = crc8(mTxBuf, 13); |
13 | |
14 | sendPacket(invId, mTxBuf, 14, true); |
15 | }
|
Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine geänderten Dateien?
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
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
@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?
:
Bearbeitet durch User
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.
Habe den Code von Hubi etwas angepasst: NRF24_SendRcv.ino:
1 | if (tel == 0) { |
2 | #ifdef ESP8266
|
3 | hmPackets.SetUnixTimeStamp (getNow()); |
4 | #endif
|
5 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
6 | }
|
7 | else if (tel == 1) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x89); |
9 | else if (tel == 2) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x91); |
11 | else if (tel == 3) { |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
13 | //tel = 0;
|
14 | }
|
15 | else if (tel == 4) |
16 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x88); |
17 | else if (tel == 5) |
18 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x92); |
19 | |
20 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
21 | |
22 | tel++; |
Settings.h
1 | // WR und DTU
|
2 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
3 | #define SerialWR 0x104163500316ULL // <<<<<<<<<<<<<<<<<<<<<<< anpassen
|
4 | uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); // ((uint64_t)0x5279607201ULL); |
5 | #define DTU_RADIO_ID ((uint64_t)0x7311880801ULL)
|
Das Ergebnis:
1 | 20:19:58.728 -> Send... CH75 |
2 | 20:19:58.774 -> 00 7311880801 0092 12 1 92 63500316 63500316 000300000000000091D09E 1 |
3 | 20:19:58.774 -> ---- neues cmd=0 |
4 | 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 |
5 | 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 |
6 | |
7 | 20:20:03.760 -> 00 7311880801 0094 12 2 88 63500316 63500316 00030000000000008B7436 1 |
8 | 20:20:03.760 -> ---- neues cmd=0 |
9 | 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 |
10 | 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 |
11 | |
12 | 20:20:49.802 -> 00 7311880801 00C0 18 0 91 63500316 63500316 012D0001095D1389003D085D00FFE550EF 1 |
13 | 20:20:49.802 -> P1.Udc :26.50 |
14 | 20:20:49.802 -> P1.Idc :238.27 |
15 | 20:20:49.802 -> P1.Pdc :3507.20 |
16 | 20:20:49.802 -> P2.Udc :1562.40 |
17 | 20:20:49.802 -> P2.Idc :238.08 |
18 | 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!
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.
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
1 | Error while retrieving data: last frame missing: Request Retransmit |
2 | Error while retrieving data: last frame missing: Request Retransmit |
3 | Free heap: 0x430f8 |
4 | Inverter #0 no Payload received! (retransmits: 0) |
5 | 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 ?
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.
:
Bearbeitet durch User
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++;
:
Bearbeitet durch User
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.
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
1 | sudo apt install cmake git python3-dev libboost-python-dev python3-pip python3-rpi.gpio |
2 | 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 |
3 | git clone https://github.com/nRF24/RF24.git |
4 | export RF24_DRIVER=SPIDEV |
5 | cd RF24 |
6 | rm Makefile.inc #just to make sure there is no old stuff |
7 | mkdir build && cd build |
8 | cmake .. |
9 | make |
10 | sudo make install |
11 | cd ../pyRF24 |
12 | rm -r ./build/ ./dist/ ./RF24.egg-info/ ./__pycache__/ #just to make sure there is no old stuff |
13 | python3 -m pip install --upgrade pip |
14 | python3 -m pip install . |
15 | python3 -m pip list #watch for RF24 module - if its there its installed |
16 | cd .. |
17 | cd examples_linux/ |
18 | 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 :)
:
Bearbeitet durch User
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.
Hallo, die Platinen sind wahrscheinlich schon weg oder? Konnte leider nichts finden und könnte 3 Stück gebrauchen. Danke und Gruß
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
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.
Angehängte Dateien:
-
2022-06-16-A.jpg
69 KB -
2022-06-16-A1.jpg
48 KB
nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden
Angehängte Dateien:
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 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
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
Für das Wemos D1 mini-Board ist das hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Daniel R. schrieb: >
1 | sudo python3 -um hoymiles --log-transactions --verbose --config |
2 | > from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, |
3 | > RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16 |
4 | > ImportError: |
5 | > /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: |
6 | > undefined symbol: _ZN4RF2410setPALevelEh |
7 | > |
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' ```
Ameise schrieb: > nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden Da hat sich ja die Arbeit der Community gelohnt…
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.
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?
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...
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
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 ... ???
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?
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
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)
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.
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?
:
Bearbeitet durch User
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
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.
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
@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!
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);
}
```
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.