Announcement: there is an English version of this forum on Hallo, diese Wechselrichter verfügen über einen RF 2,4 GhZ Nordic. Hat jemand eine Idee wie dieses Protokoll aufgebaut ist? Hat jemand das schon einmal "angezapft" um ein eigenes Monitoring ohne deren Cloudzwang zu realsieren? Es gibt offensichtlich einen "Adapter", der das "2,4 GhZ Signal umsetzt und dann via WLAN an deren Cloudsysteme versendet. Google, Hersteller, etc. schweigen sich leider aus. Danke für sachdienliche Hinweise
sorbit schrieb: > Hat jemand eine Idee wie dieses Protokoll aufgebaut ist? Könnte auf der Basis von ShockBurst™ sein. Eine Beschreibung findest du z.B. im NRF24L01+ Datenblatt
Wenn die sich das einfach gemacht haben ist das ein properietäres Uart Signal.
Häng mich mal ran .... interessiert mich auch
Scheint leider niemand zu wissen… Schade, die WR sind eigentlich sehr verbreitet. Das Ding sendet ungenutzt dauernd wertvolle Daten in den Äther..
Bekomme demnächst auch den HM-600, von daher interessiere ich mich auch für das Thema. Zumal das Originalzubehör ziemlich teuer und hässlich ist...
Martin M. schrieb: > Bekomme demnächst auch den HM-600, von daher interessiere ich mich > auch > für das Thema. > Zumal das Originalzubehör ziemlich teuer und hässlich ist... Die schweigen sich da so ziemlich aus. Auf jeden Fall Cloudzwang mit Kosten und dieser wohl nicht verfügbare, teure wlan Stick
Ist da inzwischen jemand weitergekommen? Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine ID länger ist werden ignoriert. Erstes Problem: Das LC12S lässt sich nicht konfigurieren - zumindest spuckt dies die serielle Konsole aus. Beschaltet ist das LC12S so: VCC - 3V3 GND - GND CS - GND SET - IO4 Rx - IO16 Tx - IO 17 --> D.h. wenn, dann läuft es mit irgendwelchen Defaultwerten In der Konsole bekomme ich folgenden Nonsense bei aktuell schwankend 20-40W AC über Steckdose gemessen (klar, der WR ist ein anderer und hat ja bspw. 2 Strings usw...)
1 | 14:19:13.023 -> Received Inverter Status |
2 | 14:19:13.023 -> Device: 7201xxxx |
3 | 14:19:13.023 -> Status: 0 |
4 | 14:19:13.023 -> DC_Voltage: 46.00V |
5 | 14:19:13.023 -> DC_Current: 629.00A |
6 | 14:19:13.023 -> DC_Power: 28934.00W |
7 | 14:19:13.023 -> AC_Voltage: 0.00V |
8 | 14:19:13.023 -> AC_Current: 0.00A |
9 | 14:19:13.023 -> AC_Power: 0.00W |
10 | 14:19:13.023 -> Power gen total: 0.00 |
11 | 14:19:13.023 -> Temperature: 0 |
Sieht sich jemand in der Lage das Programm anzupassen? Hier ein Ausschnitt, welche Bytes überhaupt ausgewertet und wie sie verrechnet werden. Ich wüsste jtzt nicht welche Bytes wie rum zu shiften und verrechnen sind...
1 | void NETSGPClient::fillInverterStatusFromBuffer(const uint8_t* buffer, InverterStatus& status) |
2 | {
|
3 | status.deviceID = buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF); |
4 | //status.deviceID = buffer[5] << 32 | buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF);
|
5 | const uint32_t tempTotal = buffer[10] << 24 | buffer[11] << 16 | buffer[12] << 8 | (buffer[13] & 0xFF); |
6 | status.totalGeneratedPower = *((float*)&tempTotal); |
7 | |
8 | // CRC = buffer[14]
|
9 | status.dcVoltage = (buffer[15] << 8 | buffer[16]) / 100; |
10 | |
11 | status.dcCurrent = (buffer[17] << 8 | buffer[18]) / 100; |
12 | status.dcPower = status.dcVoltage * status.dcCurrent; |
13 | |
14 | status.acVoltage = (buffer[19] << 8 | buffer[20]) / 100; |
15 | status.acCurrent = (buffer[21] << 8 | buffer[22]) / 100; |
16 | status.acPower = status.acVoltage * status.acCurrent; |
17 | |
18 | status.state = buffer[25]; // not fully reversed |
19 | status.temperature = buffer[26]; // not fully reversed |
20 | }
|
Ich würde mal "bluetooth-clients" in der Umgebung suchen. Vielleicht hat man Glück. ;-) Was steht auf den Nordic-Chip?
Eule schrieb: > Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm > ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo > von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID > habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine > ID länger ist werden ignoriert. Hi Eule, ich habe das gleiche bei meinem HM-1200 versucht. Allerdings bekomme ich einfach keine Antwort nach: "Sending request now" wie hast du denn die InverterID im code eingegeben ? einfach die komplette Seriennummer vom WR (12 stellen) wie hier ? constexpr const uint64_t inverterID = 0x11617052xxxx ;
Hallo Eule habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann verworfen. Also, ich schau's mir mal an. Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und im Klartext als auch als Hex-Dump hättest. Hast du am Original-Code was geändert, oder so wie in Github zu finden?
> > Hi Eule, > > ich habe das gleiche bei meinem HM-1200 versucht. > Allerdings bekomme ich einfach keine Antwort nach: "Sending request now" > > wie hast du denn die InverterID im code eingegeben ? > einfach die komplette Seriennummer vom WR (12 stellen) wie hier ? > > constexpr const uint64_t inverterID = 0x11617052xxxx ; Hallo Chris, ja genau. Geht aber genauso gut oder schlecht, wie wenn ich die ersten 4 Stellen einfach weglasse und nur die letzten 8 verwende. Es scheint, dass sich irgendwas verändert, wenn ich das Modul in der Hand habe. Auf dem Tisch liegtnd bekomme ich meist auch keine Antwort, halte ich es in der Hand oder an den Kabeln tut sich meist etwas. Entweder diene ich als Antenne oder ich habe einen Wackler, den ich trotz mehrmaligem Auftrennen und Neuverbinden nicht wegbekomme. Bin einfach zu lange raus aus dem C++, mich verwirrt die Polldemo. :( Gruß Eule
Hubi schrieb: > Hallo Eule > habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles > HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, > aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe > ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann > verworfen. > Also, ich schau's mir mal an. > Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und > im Klartext als auch als Hex-Dump hättest. > Hast du am Original-Code was geändert, oder so wie in Github zu finden? Hallo Hubi, ich habe mir so ein LC12S Modul besorgt und an die 2. UART eines Lolin Boards gehängt. Die Polldemo habe ich lediglich um meine Inverter ID angepasst. Ansonsten habe ich inzwischen auch an zig Stellen im Code rumgedoktert - aber ich bin was das angeht mittlerweile einfach ein richtiger Anfänger. Mal alles was der WR ausgibt mitschneiden war auch meine Idee, bekomme ich aber auf die Schnelle nicht hin. Ich frage mich eh, wie der Aaron das "entschlüsselt" hat. Wenn die Werte halbwegs mit irgendwas zusammenpassen, kann man es sich ja noch zusammenreimen. Aber das passt bei mi gar nicht. Auch frage ich mich, woher kennt er den "command" mit 0xc0, 0xc1 usw.? Woher kennt er das Magic Byte? Ist das alles beim HM gleich oder anders? Gruß Eule
Hi Eule
hier auf die Schnelle der Code zur Ausgabe des Dumps:
void printBuffer (char * richtung) { // rein oder raus, send oder rcv
int i;
uint8_t ch;
Serial.println(richtung);
// drucke zuerst als Zeichen
for (int i = 0; i < sizeof(mBuffer); i++) {
ch = mBuffer[i];
if (ch >= 32 && ch < 127) Serial.print(ch); else Serial.print ('.');
}
Serial.println();
// jetzt das ganze in Hex
for (i = 0; i < sizeof(mBuffer); i++) {
ch = mBuffer[i];
if (ch < 10) Serial.print('0');
Serial.print (ch, HEX);
}
Serial.println();
}
Moin es wäre auch von Vorteil, wenn man nach dem sendCommand in der Methode getStatus den Buffer mBuffer wieder komplett löschen würde, etwa durch memset (mBuffer, 0, sizeof(mBuffer)) Da ab der Stelle 6 im mBuffer die DeviceId gefüllt wird (beim Senden) und dort nach Empfang des Status auch wieder steht, könnte man durch das vorherige Löschen ersehen, ob der Sender, also der WR, die DeviceId eingetragen hat. Dann wüßte man wenigstens, dass der WR richtig antwortet.
Kleines Update: Rx und Tx gehören anders herum, als im Code-Kommentar. D.h. alles was ich ab und zu "gelesen" habe, waren Geister. Nach dem Drehen von Rx/Tx erste Erkenntnis: die beiden Tx haben sich nicht weh getan, denn nun wird zumindest mal die Konfiguration des LC12S geschluckt! :) Aber vom Wechselrichter höre ich mit den gegeben Einstellungen für Channel und Network ID nichts. Ich bin dann auf dieses tolle Repository gestoßen: https://github.com/Yogui79/IntexPureSpa Da gibt's unter Tools was zum Suchen des Channels und der Network ID. Der klappert einfach einen nach dem anderen durch. Dauert halt... bisher noch kein Treffer beim Channel. Naja vielleicht hat der Hoymiles ja doch garkein LC12S verbaut...? Mal abwarten. Gruß Eule
OK, mal wieder was gelernt... Aber ans Ziel kam ich damit nicht. Die Kanalsuche schlägt nicht an. Also nochmal nach dem DTU gesucht und siehe da, ein Bild mit der aufgedruckten FCC ID gefunden. Die dokumentieren ja üblicherweise ihre Tests. Aha! https://fcc.report/FCC-ID/2ARNB-DTUW100 Wie man bei den internal photos sieht - kein LC12S verbaut. Sieht nach Eigenentwicklung - oder zumindest -layout aus. Wieso nicht noch weiter bei der FCC nach Hoymiles suchen? Achja, da gibt's ja auch ein RF Modul namens HM2401 einzeln - zum Verbau im WR vermutlich: https://fccid.io/2ARNB-HM2401 Auch hier gibt's nette Bilder. Das schaut tatsächlich nach was anderem aus, als das LC12S (https://fccid.io/2ARNB-HM2401/Internal-Photos/Internal-Photos-4572280) Aha! Ein NRF 24LE1E! Ich muss mal in den Keller, glaube sowas habe ich auch noch wo rumfliegen. Gruß Eule
Usr-c210 ist ein uart total WiFi modul von pusr
Tach in der Zwischenzeit habe ich einen RF24-Scanner in meinem Gartenhaus laufen lassen. Scanner sind bei diversen RF24 Libs als Beispiel dabei. Es wird nach Carriern auf den Kanälen gesucht. Mein bisheriges Resultat: - auf den Kanälen 1-14 ist recht viel los, sind ja auch die vom WLan - auf Kanal 64, der bei dem Polldemo benutzt wird, war rein garnichts los - meiste Aktivität war auf Kanal 16 bei 2 Mbps Mein nächster Ansatz, falls sonst keine neueren Erkenntnisse, wird sein, auf dem Kanal mal etwas zu senden, evtl sowas wie die Statusabfrage, und die Antwort abzuwarten. Übrigens: im Arduino-Repository gibt es die Lib nrf-hal, die stammt aus dem Hause Nordic und könnte die schon erwähnte proprietäre Lib für die Hoymiles sein.
Moin zusammen, kann ich hier mitmischen? Ich habe grade meine "Versuchsanlage" mit einem HM-600 in Betrieb genommen. Auf Grund dieses Beitrags habe ich jetzt ein NRF24-Mudul und einen Arduino zusammengesteckt und einen Scanner am laufen. Leider noch ohne Erfolg. Welche Scansoftware habt ihr eingesetzt und wie groß ist der Abstand HM und NRF-Modul (bei mir etwa 10m)? Wahrscheinlich ist es sinnvoll, den Empfänger mal direkt neben den HM zu setzen, oder? Kann ich erst machen, wenn es wieder hell ist. Finkt der HM überhaupt, wenn die Panels keine Spannung liefern? Viele Grüße Carsten
Hallo, ich hatte gesehen, dass in den FCC-Dokumenten, die weiter oben verlinkt sind, ein user manual enthalten ist. Dort ist angegeben: Channel List 2403, 2423, 2440, 2461, 2475MHz Vielleicht hilf das, die Suche einzugrenzen?
Carsten B. schrieb: > einen > Scanner am laufen. Leider noch ohne Erfolg. Hast du denn das Hoymiles Kommunikationsmodul (DTU-W100 ) laufen? Vielleicht antwortet der Wechselrichter nur auf Anfragen von diesem Gerät.
Hallo, DTU habe ich keine, war mir zu teuer und ich hätte es gern "cloudfree". Den Fehler beim Scanner habe ich gefunden, ich hatte noch zwei Pins vertauscht läuft jetzt. Noch kann ich aber keinen Kanal dem HM zuordnen.
Hallo meine Versuche mit dem Scanner hatte bisher keinen Erfolg. Oben gab es die Nachfrage welche Scanner eingesetzt wurden, ich nutzte die von den Libs rf24 und nrf_hal. Soviel ich weiß haben die nrf24l01 nur bis zu 126 Kanäle. Der Abstand zum HM-600 war nur knapp 2 m, und durch die Holzdecke + Schindeln. Bin jetzt leider am Ende meines Lateins, wenn noch jmd eine Idee hat mache ich gerne weiter.
Modul überprüfen. https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285 Direkt an TxD (oder auch RxD, das ist Definitionssache) des Moduls lauschen, ob Daten kommen. Und ganz böse: Sein eigenes Adapter-Modul einbauen. ;-)
ich bin auch interessiert - aber leider momentan viel zu wenig Zeit Aber schaut Euch doch das mal an: https://github.com/Koenkk/zigbee2mqtt/issues/4221 Hoymiles kommt aus dem gleichen Haus wie APSystems - denke das Protokoll ist sehr ähnlich Dort sind ein paar sehr fixe Jungs unterwegs die gerne behilflich sind
Angehängte Dateien:
Hallo zusammen, ich hänge mich hier mal rein, weil ich auch Cloud-Free
den "MI" auslesen will. In meinem Fall 2 HM-600.
Hoymiles kommuniziert über "Nordic proprietary"... siehe Anhang
Nordic proprietary != Zigbee
anderes Adress-/CRC-Protokol... mehr hab ich leider noch nicht erfahren
können... versuche auch schon mit 'nem NRF24l01 irgendwas zu
empfangen... fürchte aber, dass der Inverter wie beim NETSGPClient
getriggert werden muss... also aktiv Daten geholt werden.
Ansonten werden laut FCC-Test nur Kanal 13, 40 und 76 getestet
("Fundamental frequency")
Grüße^^
Das Gerät wird nicht ständig Senden. Wenn dann nur Keep Alive Packets mit größeren Abständen. Es könnte sogar sein, dass der Empfänger auch nicht ununterbrochen aktiv ist und zum Einschalten der Träger erst ein paar Sekunden anstehen muss. Die Hoymiles sind mit < 50mW Verbrauch bei Dunkelheit angegeben. Für permanentes Wlan reicht das nicht. Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die Kommunikation mitschneiden.
Einhart P. schrieb: > Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die > Kommunikation mitschneiden. Ich bin am überlegen, ob ich mir DTU-Wlite bestelle, gibt es momentan für 79€. Ist immer noch viel Geld...und beschränkt auf 4 Module... Bisher hat keiner der Beteiligten hier eine DTU? Mein Testaufbau mit den NRF24 und dem Arduino funktioniert, zwischen meinen beiden NRF-Modulen kann ich erfolgreich Daten austauschen. So bald das Wetter es zulässt, packe ich einen Empfänger neben den Hoymiles.
Sorry, sehe grade. dass ich als Gast geschrieben habe. Ich wars...
Tja, vllt findet sich ja einer mit DTU, der hier mitmachen will, wäre super. Meine Tests von heute morgen brachten folgende Resultate: - es scheint kein alive-Paket zu geben, das von den Hoymiles verschickt wird - Test auf Carrier-Signal auf den Kanälen, 13, 40 und 75 , dass nur auf Kanal 40 ein Carrier-Signal gefunden wurde, innerhalb einer Minute mehrere hundert.Auf den beiden anderen Kanälen war ab und zu ein Carrier, kann auch Rauschen sein. Ich denke, ohne dass man da die Kommunikation mitschneidet wird es sehr aufwendig. Ich versuch mal, ähnlich wie bei dem o.g. Projekt mit APsystems zu pollen.
Hallo zusammen, mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite bestellt, sowie einen HackRF SDR zur Protokoll-Analyse. Mein Ziel ist, die Kommunikation mitzuschneiden und die Daten mit einem nRF24 und ESP ins Heimnetz zu bringen. Die Info über die verwendeten Kanäle ist schon mal nützlich zur Eingrenzung der Suche. Ich melde mich, wenn dann mal alles da ist und ich Messungen machen konnte.
Klasse! Ich bin auf Ergebnisse gespannt.
Toll dass es hier weitergeht. Meine Tests haben zu keinem Ergebnis geführt. Das große Problem dabei ist, dass zuviele Parameter zueinander passen müssen, nämlich Kanal, (5-byte) Adressen der NRFs, Protokoll (Shockburst oder enhanced SB), Aufbau Datenpaket, "Magic" Byte, Füllbytes, CRC etc. Wenn meine Programmierkenntnisse gebraucht werden, gerne.
Angehängte Dateien:
-
spektrum.png
210 KB -
dtu_paket_zeitverlauf.png
67 KB -
dtu_top.jpg
170 KB -
dtu_bot.jpg
170 KB -
dtu_gd32.jpg
240 KB -
dtu_nrf24.jpg
240 KB
martin schrieb: > Hallo zusammen, > mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite > bestellt, sowie einen HackRF SDR zur Protokoll-Analyse. Hallo zusammen. Die Teile sind da und ich habe bereits erste Versuche durchgeführt, wovon ich euch einen Zwischenstand mitteilen möchte. Zum Funkprotokoll: Die Kanäle 3,23,40,75 scheinen zu passen, hier sieht man im Spektrum die Datenpakete, die per NRF gesendet werden. Die DTU scheint auch regelmäßig alle Kanäle zu bedienen - ob der Inverter immer auf dem selben Antwortet oder ob die Pakete redundant sind kann ich noch nicht sagen. Im Zeitverlauf kann man die Datenpakete auch schön sehen, allerdings bin ich mir nicht sicher ob der Universal Radio Hacker sie richtig dekodieren kann - mir fehlt der Vergleich, welche Daten es denn sein sollen. Dann hab ich mir die DTU mal genauer angeschaut. Alles in allem keine Raketentechnik. -Ein GD32F303 (Gigadevice, ein STM-Klon) mit SPI Flash 25Q128 . -Ein ESP8266 für die WLAN Kommunikation -Ein NRF24LE1E mit 2401C (RF Front End) Nachdem ich die beschriftete SPI-Schnittstelle gesehen habe, dachte ich "Da kann ich ja direkt die NRF-Kommunikation abfangen und mit den Funkpaketen vergleichen" - war aber leider nix, die Schnittstelle wird nicht benutzt. Ich muss jetzt also herausfinden, wo der NRF mit dem anderen uC kommuniziert. Ich vermute mal, dass irgendwo noch eine UART lauert. Den "USB"-Anschluss werde ich mir auch noch genauer ansehen, der scheint nämlich der Beschriftung nach ebenfalls eine UART zu sein. Mal schauen, was die ausgibt. Gibt also noch bisschen was zu tun... Soweit für heute, ich melde mich, wenn ich mehr herausgefunden habe. Schönen Sonntag euch allen.
Hallo Martin, sehr cool. Ich bin leider wehen ständigem Streß auf der Arbeit und Mistwetter nicht weiter gekommen. Ich wollte eines meiner NRF24-Module dicht an den Hoymiles auf dem Dach positionieren. Mal sehen, grad kommt die Sonne raus ... Carsten
Super Martin, wenn etwas brauchbares herauskommt, beteilige ich mich an den Aufwand gern mit einer Spende! Danke an ALLE
Fritzdect schrieb: > Ich hab hier ein Projekt gefunden: > https://github.com/Eule01x/NETSGPClient-for-Hoymiles Sorry, ist oben bereits erwähnt
Ich hab den HM-600 erst bekommen. Sobald er in Betrieb ist, werde ich das Example hier mal auf einem Nordic Board testen. Mal sehen ob dieses Protokoll verwendet wurde: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fesb_users_guide.html&cp=5_0_0_5_2
Ich steige mal wieder mit ein. Folgende Überlegung: wenn dieses Teil über USB eine Programmierschnittstelle hat, könnte man doch die Firmware mittels esptool auslesen. Und es gibt einige Reverse engeneering tools (wie zB Ghidra) , mit denen man wieder C-code generieren kann. Vllt lässt sich darüber etwas über die benötigten Infos wie Kanal, Adressen etc rausfinden.
Angehängte Dateien:
-
rf_signal.png
63 KB -
rf_demod.png
40 KB -
rx_tx.jpg
200 KB -
serial.png
9 KB
Hallo zusammen, ein kleines bisschen bin ich auch weiter gekommen mit meinem Reverse Engineering der DTU. Zuerst musste ich aber lernen, dass das erste Funksignal im meinem oberen Beitrag k*cke aussieht. War nicht richtig abgetastet. Hier ein Bild wie es aussehen muss. Das kann man dann auch schön demodulieren, um daraus die Bitfolge auslesen zu können. Damit muss ich allerdings noch ein bisschen hin und her experimentieren, weil ich nicht genau weiß wie viele Bits der NRF tatsächlich sendet. Deshalb habe ich mir gleichzeitig die Platine noch ein bisschen näher angeschaut. Die im Bild markierten Testpunkte sind Rx/Tx einer seriellen Schnittstelle zwischen dem NRF und dem GigaDevice, welche ich mir dann mit dem Logic angeschaut habe - die Baudrate ist übrigens 125.000 Baud/sec. Dadurch erhoffe ich mir Rückschlüsse, ob das Funksignal auch richtig demoduliert wurde - ich habe jedenfalls schon übereinstimmende Sequenzen gefunden. Aber für belastbare Daten und eine saubere Analyse brauche ich mehr Zeit... Wenn ich dann mal weiß, wie viele Byte der NRF sendet werden und was die Adressen sind, versuche ich einen eigenen NRF mithorchen zu lassen. Schönen Rest-Sonntag noch. Gruß, Martin
Danke Martin, mit dem Ansatz hast du eine gute Grundlage geschaffen.
Hallo Martin hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte.
Angehängte Dateien:
-
Enhanced_Shockburst.png
52 KB -
Protokoll_analyse.png
300 KB -
DTU_Protokoll_vorlaeufig.png
7 KB
Hubi schrieb: > Hallo Martin > hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von > Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die > Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, > und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte. Hallo Hubi, ja, das Enhanced Shockburst hab ich mir angeschaut - dürfte passen. Ich habe hier mehrere Re-Transmits eines Pakets untereinandergelegt, die sich (halbwegs) sauber demodulieren ließen (bisschen Jitter ist in den einzelnen Bitfolgen). Es tauchen vertraute Zahlenfolgen darin auf, nämlich jeweils die letzten 8 Ziffern (=Hex) der Seriennummern von Inverter und DTU. Siehe Beispiel - möchte meine Seriennummern nicht preisgeben ;-) Die eigentliche RF-Payload ist 27 Byte. Das passt auch zu dem, was der NRF seriell an den Controller schickt - das sind 29 Byte, wobei das erste und letzte Byte immer gleich sind (0x7E..0x7F). Ich vermute mal, die werden als Start- und Endmarker benutzt oder als Commands für den uC. Die Datenrate müsste 250 kbps sein, das habe ich mal mit einem eigenen NRF und einem Sendetest quergeprüft. Ich konnte bisher noch nicht herausfinden, welche CRC verwendet wird und ob die Payload selbst auch nochmal mit einer CRC versehen ist. Als nächstes will ich deshalb untersuchen, welche Daten in der Payload versteckt sind. Da müssten sich ja theoretisch die Leistungs- und Stromwerte finden lassen, die die App anzeigt. Das wird aber nochmal ein größerer Brocken Arbeit... Vielleicht gelingt mit diesen Informationen ja dem ein oder anderen auch schon eine Kommunikation?
Ich lobe mal einen Preis von 50€ aus für einen funktionierenden Clone. Das Biest auf meinem Dach soll mir sagen was los ist;-)
Hubi schrieb: > Dein Abtast sieht danach aus, denn da findet man die > Startsequenz 0x55. Ein 0x55 sagt über das Protokoll eher wenig aus. Das ist eine Standardsequenz, die eigentliche jede Funkübertragung benötigt, damit sich der Empfänger einpegeln kann.
Hallo Martin, hast du in der Spec vom Nordic den Abschnitt von der CRC gesehen: CRC (Cyclic Redundancy Check) The CRC is the error detection mechanism in the packet. It may either be 1 or 2 bytes and is calculated over the address, Packet Control Field and Payload. The polynomial for 1 byte CRC is X8 + X2 + X + 1. Initial value 0xFF. The polynomial for 2 byte CRC is X16+ X12 + X5 + 1. Initial value 0xFFFF. No packet is accepted by Enhanced ShockBurstTM if the CRC fails. Das könnte helfen, die verwendete crc herauszufinden https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
Angehängte Dateien:
-
nrf_sniff.png
7,4 KB -
wireshark_nrf24.png
180 KB
Hallo zusammen, hier mal wieder ein Update zur Protokoll-Analyse. Ich habe nun etwas mehr Durchblick bei der Kommunikation erreicht. Also es ist definitiv das Enhanced Shockburst Protokoll. Das direkt per RadioHacker zu analysieren ist schwierig, da es nicht immer exakt demoduliert wird - hinzu kommen die 9 Bit Status-"Byte", die die erkannte Bitfolge um 1 verschieben ggü. der eigentlichen Payload. Ziemlich unschön. Aber wenn man damit die Randbedingungen geklärt hat, gibt es eine bessere Methode: Sniffen mit dem nrf24sniffer von yveaux. Er hat ein kleines Arduino-Programm für einen Nano mit nrf24, sowie ein Windows-Tool, das mit Wireshark gekoppelt wird - Anleitung auf seiner Homepage, siehe GitHub-Link. https://github.com/Yveaux/NRF24_Sniffer Dazu muss man noch folgende Startparameter wissen: -Die Empfängeradresse des Inverters entspricht den letzten 8 Stellen der Seriennummer, aber umgedreht (Little Endian) - 00 anhängen nicht vergessen, da die gesamte Adresse des NRF 5 Byte lang ist. -Die Datenrate ist 250 kbps, max. Payload 32. Man kann das Tool dann hiermit starten (siehe Screenshot) und bekommt die Datenpakete in Wireshark serviert. Der oben bereits beschriebene Protokoll-Aufbau (innerhalb der Payload) scheint zu passen, eine CRC konnte ich darin nicht ausfindig machen - die des NRF wird mit diesem Tool automatisch geprüft. So konnte ich das was die DTU sendet direkt auf dem Rechner empfangen. Im nächsten Schritt hänge ich einen 2. NRF mit der Adresse der DTU dran, um das was der Inverter zurück schickt abzufangen. Und dann geht es darum, den Inhalt zu identifizieren - einen offensichtlichen Zusammenhang zu den physikalischen Größen habe ich leider noch nicht entdeckt. Scheint aber eine Menge Overhead drin zu sein...
Hallo Martin
ich verfolge sehr intensiv deine "Forschung". Bin gerade dabei, das
ganze mit einem Aruino pro mini und eine nrf24 nachzubauen, aber es
kommt keine Kommunikation zustande, WR antwortet nicht.
Vllt könntest du mir folgendes kommentieren:
(nur zur Info: ich benutze Lib RadioHead, die macht von Hause aus schon
das enhanced SB)
1) wenn mein WR die Ser.Nr. 112233445566 (dezimal), so nehme ich letzte
8 Stellen, also 33445566, daraus in Hex 0x01FE56BE und setzte damit im
nRF die Adresse mit dem byte-Array {BE,56,FE,01,00}, oder muss das 0x00
vorne hin?
2) in der payload setzte ich nach der 0x15 wiederum die Adresse des WR
(BE,56,FE,01) und danach den Rest wie in deinem Bild vom WireShark (72
81 88 ...).
Aber es passiert nichts, keine Antwort vom WR.
Eine Idee? Wenn nicht wartete ich weitere Ergebnisse ab.
mein Punkt 2 ist falsch: ich schreibe die Adresse des WR natürlich in umgekehrter Reihenfolge, also (01,FE,56,BE)
Hallo Hubi, nein, die Adresse des WR nicht in Hex umwandeln sondern direkt (die ist quasi schon Hex). Also aus deiner SN wird Ox66554433 als erste 4 Byte der Adresse für den NRF im Inverter. Plus vermutlich 01 als 5. Byte. Dann die Ox15 als (irgendein) Kommando. Der WR antwortet an dieser Stelle mit 0x95. Danach die Empfangsadresse nochmal richtig rum innerhalb der Payload, sowie die Sendeadresse. Die 72818832 ist die Seriennr. meiner DTU, da kannst du also theoretisch irgendwas nehmen, was du deinem NRF als "DTU"-Adresse gibst. Die 0x80 OB nach den Adressen scheint auch immer da zu sein. Ich weiß noch nicht, wofür das steht. Genauso wenig wie ich bisher über die restlichen 16 Byte weiß...
Martin, Danke für die ausführliche Erklärung. Aber auch damit habe ich bisher keinen Erfolg, leider. Da muss noch irgendwas anderes nicht stimmen, payload dynamisch oder fix, auto ack, ???
Hallo Hubi, ich vermute Mal, dass die "DTU" zuerst eine Initialisierung schicken muss. Habe aber keine Ahnung wie die aussehen muss. Dieses Wochenende komme ich auch nicht mehr dazu weiterzumachen, bin unterwegs... Melde mich, wenn ich mehr weiß.
1 | WLAN Nordic |
2 | 2.4 GHz |
3 | \|/ \|/ |
4 | | | |
5 | +-------+ (A)(?) +-----------+ |
6 | | ESP32 | <------------> | NRF24LE1E | |
7 | +-------+ +-----------+ |
8 | ^ ^ |
9 | | | |
10 | | +----------+ | |
11 | +-----> | GD32F303 | <-----+ |
12 | (B) +----------+ (C) |
13 | |
14 | ABBILDUNG 1: Systemübersicht "DTU" |
Hallo zusammen, ich stelle mir gerade die Frage, welche Wechselrichter ich mir für mein geplantes "Balkonkraftwerk" zulegen soll. Auch für mich wäre eine direkte Kommunikation zum Wechselrichter (ohne Hersteller-"Cloud"-Zwang) sehr attraktiv. Die Ermittlungen von @martin sind sehr interessant. Da ich auch beruflich mit ähnlich aufgebauten Systemen zu tun habe, wollte ich mal darstellen, welche Möglichkeiten ich kenne, solch ein System aufzubauen. Vielleicht hilft das ja, mit der Analyse weiterzukommen. Also: Das "DTU" scheint nach @martins Analyse aus folgenden drei Hauptkomponenten zu bestehen (siehe Abbildung 1): - ESP-12F: Das ist ein komplettes "System on Module" mit ESP8266 Mikrocontroller und integriertem WLAN. Theoretisch könnte die gesammte "Intelligenz" darauf programmiert sein. - NRF24LE1E: Das ist auch ein komplettes "System on Chip": (https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [1]). Es besteht aus einem direkt an einen allgemeinen Mikrocontroller gekoppelten RF-Frontend. Wenn wir auf der Schnittstelle zwischen Controller und RF-Frontend lauschen könnten, hätten wir gewonnen. Aber das wird nix, denn die ist "im Chip". - GD32F303: Der dritte Controller im System. Allein die Tatsache, dass dieser überhaupt vorhanden ist, deutet IMHO darauf hin, dass die "Hauptintelligenz" des "DTU" hierauf implementiert ist. Denn technisch hätten die anderen beiden Subsysteme beide genug Rechenpower/Speicher/etc, um ohne weitere Hilfe die Aufgabe des "DTU" zu erledigen. Belauschen können wir die Kommunikation zwischen den Chips, also die Wege (A), (B) und (C). (A) gibt es vermutlich nicht, wenn der GD32F303 die zentrale Steuerung macht - dann muss WLAN und Nordic nie miteinander reden. Die Kommunikation (B) zum WLAN ist im ersten Schritt vermutlich eher uninteressant. Bleibt also die Verbindung (C) zwischen GD32F303 und NRF24LE1E. Hier können wir nun "Glück" oder "Pech" haben, oder irgendetwas dazwischen: "Glück"-Szenario: Auf dem Mikrocontroller des NRF24LE1E läuft nur eine ganz einfache Software, die eingehende Bytes/Pakete 1:1 an das eingebaute RF-Frontend durchreicht. "Pech"-Szenario: Auf dem Mikrocontroller des NRF24LE1E ist eine Software implementiert, die "Kommandos" vom GD32F303 empfängt, und diese dann selbst in passende RF-Pakete übersetzt. Und eventuell auch mit einem fest im Controller hinterlegten Schlüssel verschlüsselt (die eingebaute Verschlüsselungs-Hardware ist ein Grund, warum man solch ein System so entwerfen würde). Im "Glück"-Szenario hätten wir so gut wie gewonnen. Wir könnten quasi die RF-Kommunkation mitlesen, und sie somit auch mit einem eigenen NRF24LE1E nachbauen. Ganz unwahrscheinlich ist das nicht, denn dieses Szenario ist natürlich (von Herstellerseite) einfacher zu implementieren, als auch noch für den NRF24LE1 "kompliziertere" Software zu schreiben. Und mir scheint, es steht zumindest nirgendwo in der Werbung, dass die Wechselrichter "verschlüsselt" kommunizieren. Meine Frage an @martin wäre also: Kannst Du die Verbindung (C) irgendwo entdecken und darauf mithören? Am wahrscheinlichsten sind das einfach eine RX und eine TX Leitung zwischen den beiden Chips (UART). Der Mikrocontroller hat laut Datenblatt ([1], s.o.) genau eine serielle Schnittstelle, bei dem verbauten 32-pin-Gehäuse sollten die hier sein: - P0.4 (Pin 7): RXD - P0.3 (Pin 10): TXD Auf Deinen Fotos passt das auch insofern, als diese Pins jeweils in ein Via gehen. Da könntest Du mal versuchen, die Leiterbahnen zu verfolgen. Oder direkt da mit einem Tastkopf abgreifen. An einem Oszi sollte sich da schnell ein Signal zeigen und die Datenrate lässt sich dann rausmessen. (Die GND, CVV, ROG, SCK, SI, SO, SCN, RST Kontakte sind vermutlich "nur" die Programmierschnittstelle für den NRF24LE1 und werden im Betrieb keine Daten übertragen.) Jetzt bin ich mal gespannt, ob Ihr mit meiner Analyse übereinstimmt, und natürlich, ob @martin auf den Pins sinnvolle Signale mitlesen kann! Viele Grüße -- Petersilie (sorry, Vorname ist auch "Martin" - davon haben wir schon mehrere in diesem Thread...)
:
Bearbeitet durch User
Hallo Martin/Petersilie ;-) ja, die beiden Testpunkte gehen an die Rx/Tx Pins des NRF24LE1E. Ich habe auch schon die Kommunikation zwischen NRF24LE1E und GD32F303 mit dem Logic Analyzer mitgeschnitten. Es sieht tatsächlich so aus, als würde der NRF nur "stupide" als Transceiver benutzt. Ich vermute, wie du oben beschrieben hast, dass die Logik im Gigadevice sitzt und der ESP ebenfalls nur als Gateway zur Cloud dient. Die DTU stellt übrigens auch permanent ein WLAN zum direkten Zugriff bereit per App (das ist eher unschön, wenn man das Ding dauerhaft im Einsatz hat). Die bisherige Untersuchung zeigt, dass die Pakete "on air" 1:1 den seriellen Datenpaketen entsprechen. Jetzt geht es also darum, aus den seriellen Daten schlau zu werden. Ein paar Randbedingungen konnte ich schon klären, z.B. kommt immer die Seriennummer des Inverters bzw. der DTU im Paket vor (Absender und Empfänger-Adresse). Leider habe ich im Moment wenig Zeit, weiter an dem Protokoll zu forschen. Ich versuche euch demnächst mal eine Excel-Tabelle mit den aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit den Daten bereits was anfangen. (Einschalten der DTU, Verbindung zum Inverter, Regelmäßige Abfrage).
martin schrieb: > Ich versuche euch demnächst mal eine Excel-Tabelle mit den > aufeinanderfolgenden Paketen bereitzustellen, Das wäre spitze. Einfach mitschneiden. Muss nicht aufwendig aufbereitet sein. Eventuell kannst Du auch einfach ein Terminalprogram (HTerm o.ä.) aufzeichnen lassen. Was auch super funktioniert sind diese Saleae Logik-Analyser, falls Du zufällig so einen hast. Wäre doch gelacht, wenn wir bei diesen Erkenntnissen und der Vorarbeit dem Protokoll nicht vollends auf die Schliche kommen würden!
Bin auch dabei, wenn genügend Daten über die Kommunikation da sind, an einem Klon mit zu programmieren. Man müßte halt vom 1. Anschalten der DTU, über Registrierung des WR bis hin zur dauernden Übertragung der Daten von WR zu DTU mal alles aufgezeichnet haben. Verschlüsselt ist da wohl nichts, sonst könnte man die Seriennrn nicht rauslesen. Bin schon ganz gespannt auf die Daten!
Hab mir die Bedienungsanleitungen für die DTUs mal durchgelesen. Sieht mir so aus, als müsse es eventuell gar keine "Verbindungsaufnahme" o.ä. geben. Der DTU sagt man einfach, welche Seriennummern die Wechselrichter haben, und die DTU fragt dann regelmäßig alle eingetragenen Wechselrichter ab. Insofern also "einfach" mal die RX und TX Bytes für einige Zeit mitschneiden (ein ganzer Tag wäre ultimativ), dann sehen wir hoffentlich irgendwelche Muster in der Payload, über die wir dann auf den Inhalt schließen können.
Super Projekt das ihr da Versucht umzusetzen. Ich habe seit ein paar Tagen einen HM700 und eine DTU WLite. Ich habe allerdings sogar das Probelm das die DTU bei mir gar nicht richtig hochfährt und ich nur ein WLAN das AiThinker heisst angezeigt bekomme. Fahre ich ein paar Kilometer weit weg, fährt der Stick hoch und zeigt mir das DTU WLAN an. Habt ihr dazu eine Idee? Eine Alternative zu dem Stick wäre mir auch am liebsten! Die Cloud braucht ja keiner ;) LG Martin
Hab ich mir am Anfang auch gedacht, nur sind fast keine anderen WLAN Signale in der nähe. Hab dann auch schon mein eignes Mesh Wlan abgedreht, bringt keine Besserung. Auch in der restlichen Ortschaft funktioniert es nicht. Nur beim Bahnhof... sehr strange das ganze... Aber egal, ich beobachte eure Vortschritte weiter, der Stick geht aber auf jeden Fall wieder zurück. LG Martin
Hallo, ich würde sehr gerne helfen, da ich auch einen HM-400 habe und dessen Daten auslesen möchte. Ich hab den Thread hier schon verfolgt, aber bisher noch keinen Code gesehen. Wie schafft Ihr es, dass der Wechselrichter antwortet? Ich würde sehr gerne helfen und die Antworten des Wechselrichters auswerten / analysieren. Derzeit bekomme ich aber noch nicht mal eine Antwort.
1 | #include <Arduino.h> |
2 | #include <SPI.h> |
3 | #include <nRF24L01.h> |
4 | #include <RF24.h> |
5 | |
6 | /**
|
7 | * CSN 5
|
8 | * CE 4
|
9 | * MOSI 23
|
10 | * SCK 18
|
11 | * IRQ
|
12 | * MISO 19
|
13 | *
|
14 | * FCC URL: https://fcc.report/FCC-ID/2ARNB-DTUW100
|
15 | * Allowed Frequency: 2403, 2423, 2440, 2461 or 2475MHz
|
16 | * Channel: 1 1 8 10 13
|
17 | * Tested Channels: 1, 3, 6, 9, 11 (FCC)
|
18 | */
|
19 | |
20 | // ---- Radio Setup ----
|
21 | RF24 radio(4, 5); // CE, CSN |
22 | |
23 | // serial no hoymiles: 112234567890
|
24 | |
25 | const uint64_t deviceID[1] = { 0x0987654301 }; |
26 | |
27 | |
28 | // ---- Program Values ----
|
29 | const int unitNumber = 0; // Sets the pair out of the 6 programmed channels |
30 | |
31 | int dataSend = 0; |
32 | int dataReceive = 0; |
33 | |
34 | int channels[5] = {3, 23, 40, 61, 75}; |
35 | |
36 | //============ Send/Recieve Function ============
|
37 | void rxtx() { |
38 | |
39 | for( int i = 0; i < sizeof(channels)/sizeof(channels[0]); i++ ) { |
40 | int iChannel = channels[i]; |
41 | |
42 | Serial.print("rxtx Start"); |
43 | Serial.print(" "); |
44 | Serial.println(iChannel); |
45 | |
46 | uint8_t deadPool = 0x15; |
47 | uint8_t frankCastle = 0; |
48 | int iTx = 0; |
49 | int iRx = 0; |
50 | |
51 | radio.setChannel(iChannel); |
52 | |
53 | radio.printPrettyDetails(); |
54 | |
55 | //Begin Transmission and send for 10ms
|
56 | for (int iTx=0; iTx <= 10; iTx++){ |
57 | radio.stopListening(); |
58 | radio.write(&deadPool, 1); |
59 | delay(1); |
60 | }
|
61 | |
62 | //Begin Receive and listen for 10ms
|
63 | for (int iRx=0; iRx <= 10; iRx++){ |
64 | radio.startListening(); |
65 | radio.read(&frankCastle, 1); |
66 | delay(100); |
67 | }
|
68 | dataSend = deadPool; |
69 | dataReceive = frankCastle; |
70 | Serial.println("RxTx Cycle Finished"); |
71 | Serial.println(dataSend); |
72 | Serial.println(dataReceive); |
73 | Serial.println(""); |
74 | }
|
75 | }
|
76 | |
77 | |
78 | void setup() { |
79 | // ---- Activate Radio ----
|
80 | Serial.begin(115200); |
81 | |
82 | radio.begin(); |
83 | radio.openWritingPipe(deviceID[unitNumber]); |
84 | radio.openReadingPipe(unitNumber, deviceID[unitNumber]); |
85 | radio.setPALevel(RF24_PA_MIN); |
86 | radio.setPayloadSize(1); // Sets payload to 1 byte |
87 | radio.setDataRate(RF24_250KBPS); |
88 | radio.setAutoAck(unitNumber, false); |
89 | |
90 | // radio.printDetails();
|
91 | }
|
92 | |
93 | void loop() { |
94 | // Serial.println("Loop Start");
|
95 | rxtx(); |
96 | // Serial.println("Loop End");
|
97 | |
98 | delay(1000); |
99 | |
100 | }
|
Vielen Dank Marcel
martin schrieb: > Ich versuche euch demnächst mal eine Excel-Tabelle mit den > aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit > den Daten bereits was anfangen. Hallo zusammen, im Anhang findet ihr eine Excel-Tabelle mit Daten die ich vor kurzem aufgezeichnet hatte. Es handelt sich dabei um die INTERNE Kommunikation in der DTU zwischen dem GD32 und dem NRF - die ersten 15 Sekunden nach Einschalten. Diese Daten entsprechen nach meinem Kenntnisstand fast 1:1 der Funkkommunikation mit dem Inverter (siehe Tab 3 in der Excel). Einiges, was ich identifizieren konnte, habe ich bereits markiert - vielleicht könnt ihr weitere Teile entschlüsseln. Leider ist es nicht ganz so offensichtlich, wo sich die Daten zu Strom, Spannung und Leistung wiederfinden lassen. Aber vielleicht könnt ihr mit diesen Infos ja bereits einen NRF mit eurem Inverter kommunizieren lassen. Ich vermute, dass die Kommunikation von der DTU initiiert werden muss, da man dort die Seriennr. des Inverters einträgt. Der antwortet dann nur, wenn er seine Nummer "hört" (ab dem 2. großen Kommunikationsblock im Tab 2).
Hallo Martin, vielleicht eine blöde Frage, aber hast du mal mit einem Hexeditor auf die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Die Aufbereitung in Excel ist Klasse für die Doku, aber für das Handling der Daten finde ich es eher unpraktisch. Vielleicht kannst du auch noch die Rohdaten als Binärfiles zur Verfügung stellen? Da ich mittelfristig eh einen zweiten HM brauche, habe ich gestern einen bestellt. Dann kann ich den "unter den Schreibtisch" legen und komme vielleicht auch weiter. Vom Dach empfange ich keine Daten, bzw. kann sie in all den "Stördaten" nicht identifizieren. Ich würde es dann mal mit HM und dem NRF24 in einer "Blechkiste" zur Abschirmung versuchen. Sendet der HM eigentlich auch Daten, wenn die Panels nichts liefern? VG Carsten
Angehängte Dateien:
-
raw_data_display.png
22 KB
Carsten B. schrieb: > hast du mal mit einem Hexeditor auf > die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Hallo Carsten, habe deinen Vorschlag mal mit den vorhandenen Daten umgesetzt, siehe Binary anbei. Mit HxD war auch kein Muster direkt erkennbar, neben dem von mir bereits markierten Aufbau der Datenpakete. Wegen der verschieden Länge der Pakete habe ich diese jeweils mit 00 aufgefüllt - so sieht es wenigstens angenehmer aus ;-)
Marcel schrieb: > Wie schafft Ihr es, dass der > Wechselrichter antwortet? Hallo Marcel, mit einem eigenen NRF hat es bisher noch keiner hier geschafft. Ich hatte mir die DTU ("Data Transfer Unit"?) vom Hersteller gekauft, um damit das Protokoll abzufangen und analysieren zu können. Darin werkelt ebenfalls ein NRF auf den ich mich in meinen bisherigen Texten bezogen habe.
Angehängte Dateien:
Hi, ich bin auch am Überlegen mir eine PV zu kaufen. Die meinsten Angebote sind mit dem HM Wechselrichtern. Für die Integration in meine Hauselektronik will ich aber keine Cloud. Daher kommt mir der Bertrag sehr gelegen. Mal sehen, wo ich helfen kann. Ich hab mir mal die Binärdaten angesehen und noch Werten gesucht, welche normalerweise stabil sind. (Netzfrequenz und Netzspannung) Wenn mich nicht alles teucht, könnten es die Bytes (Big-Endian) im Screenshot sein. Gruß Pascal PS: Hier gibt es noch die Modbus Register der DTU Pro. Vielleicht läst sich daraus etwas ableiten. https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
Angehängte Dateien:
Hi, hab noch was rausgefunden: Das letzte Byte vor dem EOF (0x7F) ist ein CRC8 mit poly=1 init=0 xor=0 Hoffe, dass konnte weiterhelfen. Gruß Pascal
Angehängte Dateien:
Noch mehr Bytes.
Hallo Pascal, sehr gut, das sind schon mal hilfreiche Infos - das erste Byte nach den Seriennummern scheint zu kennzeichnen, welche Werte folgen. Bei den von dir vermuteten Netz-Ausgangsdaten (scheint zu passen) war es jeweils die ID 0x02 an Byte[10].
Hi Martin, mit der 0x02 passt nicht immer. In deiner Excel Datei Spalte AW ist eine Antwort, wo es nicht passt.
Angehängte Dateien:
-
excel.png
28 KB
Hallo Pascal, stimmt. Auf den ersten Blick würde ich vermuten, dass es an der Abfrage durch die DTU liegt. Die 0x80 an Byte[10] heißt wohl lesen - danach folgt i.d.R. die 0x0B für Ist-Werte. In dem von dir genannten Fall (Spalte AW) ist es aber die 0x11. Es dürften also irgendwelche anderen Werte folgen.
Hi Martin, hast du noch mehr Daten zu deinem Wechselrichter? Vielleicht sind es Daten zu Einstellungen, Firmware, ...
Pascal A. schrieb: > hast du noch mehr Daten zu deinem Wechselrichter? > Vielleicht sind es Daten zu Einstellungen, Firmware, ... Hallo Pascal, morgen kann ich dir mehr sagen - heute komme ich nicht dazu, weil mein Wechselrichter leider noch nicht fest installiert ist. Ich würde ihn ja gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn dadurch abschieße...
martin schrieb: > Ich würde ihn ja > gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn > dadurch abschieße... Spannung im zulässigen Bereich und passende Strombegrenzung - dann kann nichts passieren. Am besten die Spannung niedrig halten damit der MPPT noch nicht arbeitet. Dann kannst du wunderbar verschiedene nahezu konstante Bedingungen schaffen und die zugehörigen Daten untersuchen.
Hallo, ich bin auch interessiert, da eine Anschaffung geplant ist. Ich habe mir die Daten auch mal angeschaut. Der 'PackageCounter' und die drei davorliegenden Bytes sind die Uhrzeit in BigEndian time_t 32-bit => 13.02.2022 13:16:04. Sieht man in der Oberfläche die Today Production / Total Production in Wh? Laut Modbus Beschreibung sollten dies 2 bzw 4byte sein. Interessant sind die beiden vorletzten Bytes vor dem 0x7F; ggf auch eine Art zusätzliche Prüfsumme? Das Byte direkt vor dem 7F ist ja eine CRC8. Hilfreich wäre m.E. auch mal eine andere Seriennummer zusätzlich zu probieren um zu sehen was sich bei der Anfrage hier ändert. VG Frank
Super! Ich habe mal versucht, die bisherigen Erkenntnisse in der angehängten Textdatei zusammenzufassen. Vielleicht gewährt das ja noch neue Einblicke. Gerne erweitern!
Das 1. Init (mit den 8 Nullen) scheint mir eine Broadcast zu sein, aber über welche Adresse wird das verschickt? In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn Adresse WR ist ja noch nicht bekannt, aber der sch... WR antwortet einfach nicht.
Hubi schrieb: > In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn > Adresse WR ist ja noch nicht bekannt So wie ich das Verstanden habe gibt man die Seriennummer(n) der WR in der DTU (oder in der Cloud) ein bevor eine Kommunikation möglich ist. Dadurch wäre die Adresse des WR schon bekannt. Aber andererseits antwortet der WR mit der Adresse der DTU. Die ja nicht bekannt wäre wenn die nicht im ersten Frame enthalten wäre. Könntest du ggf. dein Testprogramm sharen? Habe hier einen HM-1500 sowie NRF24 Module. (nur aktuell noch keine Zeit gehabt einen Testaufbau zu machen bzw. Abends ist der WR meist schon aus)
:
Bearbeitet durch User
Anbei mein Testprogramm. Wer will kann es gerne weiterbenutzen und anpassen. Vllt hat ja jmd mehr Erfolg als ich.
Danke für den Sourcecode! Ich mag mich täuschen, aber sollte das hier:
1 | void tele7 () { |
2 | //=============
|
3 | memset (data, 0, 32); |
4 | data[0] = 0x07; |
5 | data[10] = 0x07; |
6 | datalen = 11; |
7 | }
|
nicht eher so aussehen:
1 | void tele7 () |
2 | {
|
3 | memset(data, 0, 32); |
4 | data[0] = 0x7e; |
5 | data[1] = 0x07; |
6 | data[11] = 0x07; |
7 | data[12] = 0x7f; |
8 | datalen = 13; |
9 | }
|
Nachdem im Excel vorher die komplette Payload dargestellt ist müsste doch das 0x7e und 0x7f mit dazu oder verstehe ich was falsch?
Hallo Thomas so wie ich die Excel-Tabelle verstanden habe ist das ein Mitschnitt innerhalb der DTU, also zwischen der "CPU" und dem NRF. Und diese Kommunikation startet mit 7E und endet mit 7F. Aber Martin kann das bestimmt klären.
Wir müssen unterscheiden zwischen (a) den Nachrichten zwischen dem GD32F303 und dem NRF24LE1E [1], und (b) den Nachrichten, die der µC im NRF24LE1E an den darin eingebauten "nRF24L01+"-kompatiblen Transceiver sendet. Martins Radio-Mitschnitt hat bewiesen, dass der "nRF24L01+"-Teil nach dem Nordic "enhanced Shockburst" Protokoll funkt. Dieses beinhaltet insbesondere immer eine Zieladresse. Siehe [1], Kapitel 3.4.3: - Preamble 1 byte - Address 3-5 byte - Packet Control Field 9 bit - Payload 0-32 byte - CRC 1-2 byte Für Shockburst gibt es leider keinen einfachen (d.h. NRF24LE1E-basierten) "Sniffer", um alle Nachrichten mitzulesen. Daher das weiter oben erwähnte Projekt in [2]. Unser Ziel ist ja wohl, mit einem einfachen "nRF24L01+" direkt mit einem/mehreren Wechselrichtern zu sprechen. Dazu müssen wir zu jeder der von Martin zwischen GD32F303 und NRF23LE1E mitgeschnittenen Nachrichten auch wissen, wie diese Nachricht schließlich (als "enhanced Shockburst"-Nachricht) versendet wird. Glücklicherweise scheint es sich herauszukristallisieren, dass die beiden sich sehr ähnlich sind. Alternativ könnte man eventuell an diese Pakete "direkt" drankommen, wenn man im Wechselrichter mitliest - was ist denn dort verbaut? Auch ein NRF24LE1E, oder eventuell ein "nRF24L01+" Transceiver? Ich könnte mir auch gut vorstellen, dass gewisse Nachrichten übernaupt nicht an den Transceiver (und somit in den Äther) gehen, so zum Beispiel die "Init" Nachricht. Vielleicht ist das lediglich eine Nachricht an den NRF24LE1E à la "mach' Dich bereit" oder so? -- petersilie [1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [2] https://github.com/Yveaux/NRF24_Sniffer
Übersicht erweitert: Nachrichten "02 28 23" und "82 00 03" ergänzt. Sauberer ausgerichtet. Python Beispiel für CRC.
petersilie, du hast recht. Ich hatte verdrängt das auf den NRF24 selbst auch noch Logik vorhanden sein kann. Ich würde jetzt mal unterstellen, dass der WR immer auf seine Seriennummer (= Adresse) lauscht und der DTU ebenfalls auf seiner Seriennummer. In Init 1 (siehe deine Text File) würde die DTU zwar an die Adresse des WR ein Paket senden aber der WR würde nicht wissen an welche Adresse er antworten soll. Dies ginge erst ab Init 2 weil dort die DTU seine eigene Adresse an den WR schickt. Bei der Durchsicht des Datenblattes [1] ist mir noch etwas im Kapitel 3.4.3.3 aufgefallen. Dort wird u.a. das No Acknowledgment flag beschrieben. Im Post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" wird beschrieben das das PCF 0D8 (== b011011000) ist. Was ja bedeutet das NO_ACK 0 ist. "Setting the flag high, tells the receiver that the packet is not to be auto acknowledged." Es ist low, also muss AutoAck true sein. Das wäre zumindest etwas was mir im Code von Hubi aufgefallen ist. Ebenso wird im oben genannten Post beschrieben das Channel 3 verwendet wird.
1 | radio.setAutoAck(true); |
2 | radio.setChannel(3); |
[1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
Ich hab mir jetzt mal solche NRF24-Platinchen geordert. Wir kennen die verwendeten Adressen. Somit können wir doch einen NRF24 auf die gleiche Adresse konfigurieren wie den Wechselrichter. Dann sollte der doch genau die Pakete von der DTU empfangen, oder was meint ihr? Damit hätten wir dann einen 1:1 Mitschnitt der tatsächlichen Pakete in die Richtung DTU --> WR. Später drehen wir das Spiel um, und konfigurieren den NRF24 auf die Adresse des DTU. Und hören wiederum zu. Eventuell macht das "auto-ACK" Probleme - das man eventuell empfängerseitig nicht abschalten kann. Aber vielleicht reicht es, den "Zuhörer" schön weit weg zu platzieren, damit das ACK vom echten Empfänger gewinnt. Leider habe ich (noch) keinen WR/DTU. Lieferprobleme überall. Wenn das mit den NRF24 klappt, könnte ich eventuell einen vorkonfigurierten Raspi zur Verfügung stellen, den dann ein stolzer Besitzer einer DTU (Martin?) mal lauschen lassen könnte... Hubi hat ja wohl auch nur einen WR, aber keine DTU. Da ist nach den bisherigen Erkenntnissen mit Zuhören allein wohl leider nichts zu holen, da der WR ohne passende Frage auch nie antwortet.
Angehängte Dateien:
-
Comm_Schema.png
130 KB
Hallo zusammen, gestern hatte ich versucht, den Wechselrichter mit einem Netzteil zu speisen - leider hat mir der MPP-Regler dazwischengefunkt und es hat sich kein stabiler Arbeitspunkt eingestellt. Ich glaube, es wird doch endlich mal Zeit für ein ordentliches Labornetzteil... Freut mich, dass hier so viele helfen, das Protokoll zu knacken. Aber ich glaube, es herrscht hier noch ein bisschen Unklarheit über die von mir bereitgestellten Daten. Deshalb nochmal ein Schema zur Klarstellung. Die obige Excel/Binärdaten zeigen die serielle Kommunikation innerhalb der DTU! Der NRF24LE1E ändert diese Pakete nochmal ab, bevor er sie an den Inverter rausschickt, inklusive Neuberechnung der CRC8. Die Initialisierungssequenz dürfte also nur dazu da sein, den NRF24LE1E mit den benötigten Adressen zu versorgen. Die erste Kommunikation "on air" beginnt dann erst nach den 3 Init-Sequenzen - das wäre der Ansatzpunkt, den jeder mit einem Inverter und ein paar NRF24 Modulen mal in Angriff nehmen könnte: -Enhanced Shockburst (ist voreingestellt) -CRC 2 Byte -250 kbit -Kanal 3, 23, 40, 61 oder 75 -Paketlänge 27 Byte -Empfänger-Adresse: Letzte 8 Stellen Inverter Seriennr. BCD in "Little Endian" Und wenn dann das im Bild dargestellte Datenpaket gesendet wird, müsste euer Inverter theoretisch antworten.
Macht er aber nicht!
Ich habe folgendes
15 72 60 79 52 72 81 88 32 80 B 0 62 9 4 9B 0 0 0 0 0 0 0 0 2 29 31
an addrWR[5] = {0x52, 0x79, 0x60, 0x72, 0x01} gesendet, aber das
Drecksding muckst sich nicht.
Meine Seriennummer WR ist xxxx72607952.
Die 31 ist die CRC8 der vorangehenden Bytes.
Das sollte doch alles passen!?
Hallo Hubi, ja, die Sequenz sieht m.M.n. richtig aus. Hast du es mal auf den anderen Kanälen probiert? Ist das in deinem Beispielcode enthalten? Dann könnte ich es mal bei mir probieren. Oder es könnte doch noch weitere Inbetriebnahmeschritte geben. Vielleicht wird die DTU-Adresse bei der Einrichtung per S-Miles App im Inverter gespeichert? Dazu müsste ich das ganze Setup nochmal neu machen, während ich die Pakete mitschneide.
Habe alle Kanäle ausprobiert, aber nix. Vllt ist auch die Entfernung zum WR zu groß. Sende hier vom Wohnzimmer durch Glastür in Richtung Gartenhaus mit dem WR aufm Dach. Im Anhang nochmals das Testprogramm. Als RF24 Lib benutze ich die von TMRh20 und die CRC-Lib findet man hier https://github.com/RobTillaart/CRC (bin zu blöd um Link einzufügen)
Hello all, First of all, I don´t speak german, so I am following this thread using google translator, it´s not a problem for me. I have a DTU-W100 and five MI-1500 microinverters. I have flashed a Logitech Unifying Dongle with the firmware from this repo https://github.com/BastilleResearch/nrf-research-firmware I left it running on channels 1,3,6,9,11,23,40,61 and 75 for all night, I don´t know if logged packages came from PV system. The dongle is a bit far from the MI and DTU, but today morning I put it about 2-3 meters from two MI-1500 and now I waiting for new data, but the code use DWELL for channel scanning, so probaly I am losting some packages. If anyone need a specific channel scanner or sniffer or any other test, I can help in my spare time. I hope this project will go forward!
Hi Arnaldo, Welcome to the party! Thanks for offering to help out with scanning/sniffing, and thanks for providing some results already! Looking at the received packets, it seems to me that these are unlikely to be coming from your MI-1500s for the following reason: I think we have already established that the devices (DTU/MIs) use the last 8 decimal digits of their respective serial numbers converted to BCD code as their "Shockburst" address. This implies that the address will never contain any of the hex digits A...F. From your list, this only leaves a handful (if your hand happens to be six-fingered, that is) of packets, but these don't look familiar:
1 | [2022-03-10 19:17:25.477] 11 21 55:15:57:55:BD 9A:AA:A8:2A:AA:AA:AA:AA:A2:97:AA:6A:AB:A9:AE:EA:AE:DA:79:2B:AA |
2 | [2022-03-11 04:14:56.172] 3 4 22:34:55:93:10 4C:01:2E:77 |
3 | [2022-03-11 05:46:00.747] 6 0 24:01:05:45:0B |
4 | [2022-03-11 06:17:57.783] 75 1 14:01:51:14:25 25 |
5 | [2022-03-11 07:00:49.999] 75 0 03:24:85:46:EA |
6 | [2022-03-11 07:06:58.018] 3 18 23:85:84:40:1F 23:5D:89:FA:D8:D5:B5:54:FA:FA:BA:A7:AC:90:C5:55:A8:C7 |
However, knowing the address that the inverters use means that we should be able to "sniff" specifically for packets to/from those addresses. I am not familiar with the "nrf-research-firmware" tools, but it appears to me that you might be able to use the "nrf24-sniffer.py" tool to specifically follow packets sent to/from a particular address. If your DTU serial number is, say, xxxx12345678, then this address should be 0x78,0x56,0x34,0x12 (possibly followed by 0x01 - not sure about that). But first, let's see what today's data contains! Very excited about this project gaining more participants. -- petersilie
Hello Arnaldo, thanks for the dump. I can see that your dump was mainly during the night. If i’m correct, the Hoymiles is not active in the night because the required start voltage is not generated by the solar panels. It would be beneficial if you try to “sniff” during a more or less sunny day. Even the last 5 byte pairs of your devices and DTU could be helpful for analyzing the dump. Thanks a lot Marcel
@hubi,@tbnobody Zumindest was den Kommentar in Zeile 35 (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") angeht ("// !!!! muss false sein sonst klappt senden nicht") kann ich Euch glaube ich beruhigen. Das Senden geht nicht schief, wenn Auto-ACK aktiviert wird. Vielmehr gibt die write()-Funktion zurück, ob ein ACK empfangen wurde (true), oder eben nicht (false), siehe [1]. Somit geht zwar das Senden nicht schief (das Senden gelingt wohl laut Spezifikation "immer"), aber der WR antwortet nicht (mit einem ACK). [1] https://nrf24.github.io/RF24/classRF24.html#a4cd4c198a47704db20b6b5cf0731cd58
@martin Bist Du sicher, dass die Pakete 5-Byte-Adressen verwenden, und nicht etwa nur vier? Mir fiel nämlich auf, dass "Shockburst" das Einstellen der Adresslänge (zwischen 3 und 5 Bytes) zulässt. Die RF24-Lib hat dazu die Funktion setAddressWidth() ([1]). Es scheinen ja nur die letzten 8 Dezimalziffern der Seriennummer in die (ersten vier Bytes der) Adresse umgesetzt zu werden. Bisher haben die Versuche oben dann als fünftes Byte ein "0x01" genommen, aber wo kommt das her? Hast Du das so auf dem Funk gesehen, oder ist das geraten? [1] https://nrf24.github.io/RF24/classRF24.html#ad5aea7f9a3bd9c7d357fb296ce751f21)
Hallo Petersilie habe mir den Source-Code angesehen und bin zu gleicher Erkenntnis gekommen. Mich hat halt nur gestört, dass das Senden immer das Ergebnis false lieferte. Aber was ist nun besser fürs testen, mit AutoACK=TRUE und Ergebnis=false oder doch besser Ack abschalten? Frage weil du halt geschrieben hast dass wohl AutoAck eingeschaltet ist laut deiner Mitschnitte (im PCF)? Bist du da sicher?
Was "besser" ist, ist eine gute Frage. Tatsache ist, es ist sehr unwahrscheinlich, dass der WR antworten wird, wenn er nicht einmal ein ACK sendet. Insofern würde ich sagen, es ist "besser", mit eingeschaltetem AutoACK zu arbeiten. Die Mitschnitte sind von einem anderen Martin - insofern muss ich die Frage weitergeben, ob das ACK-Bit in der beobachteten Kommunikation wirklich gesetzt ist, oder nicht... -- petersilie
I attached the log from today, I think tomorrow I will listen just on channel 1, or if someonte have another idea please tell me. @parsley it´s my first time using the nrf-research-firmware tools, so I am trying to do something that can help, I need to identify a address and after it sniff just this address with nr24-sniffer.py. To add a MI in hoymiles plataform you need to use the serial number of the MI so, I think, it is used to reach the device using the serial number. @Marcel yes, the dump was done in the night, because I flashed the dongle after the work and leave it running to try to catch something... today I got a few packages, I really don´t know if it´s working as expected, but the main reason, I think, is because the DWELL for each frequency, tomorrow I will leave it on channel 1 and after I post the result here again.... last 5 bytes of the serial DTU and the nearests MI1500 DTU: 35453 MI1500: 36590 MI1500: 14456
@arnaldo_g Your nrf-research sniffing efforts are much appreciated. This certainly has the potential to be very helpful indeed. Unfortunately, there might yet be some obstacles to overcome: I noticed that the "nrf24-scanner.py" uses "promiscuous mode" (which by itself seems to be a major hack, see posts above). This should not necessarily be a problem, since we think we know the addresses of the devices involved, and can therefore listen for packets specifically addressed to these. But to make matters worse, it seems to me that the on-air bitrate is hardcoded to 2 MBit/s (https://github.com/BastilleResearch/nrf-research-firmware/blob/02b84d1c4e59c0fb98263c83b2e7c7f9863a3b93/src/radio.c#L41). The Hoymiles inverters communicate at 250 kbit/s, so until you can switch the sniffer to that lower bitrate, you won't be seeing any meaningful data.
@martin, hattest du auch schon den traffic zwischen WR und DTU "in the air" mitgeschnitten? Ich frage mich nur, ob da das 5. byte auch immer 0x01 ist wie bei der Kommunikation zwischen DTU und WR. Nicht das hier noch ein Problem liegt
@arnaldo_g Another quick note regarding addresses. You helpfully list the serial numbers of your devices: > last 5 bytes of the serial DTU and the nearests MI1500 > DTU: 35453 > MI1500: 36590 > MI1500: 14456 However, you will need the last 8 (not 5) digits to determine the address: > DTU: 35453 --> Address will be 0x53,0x54,0x?5,0x?? (,0x01) > MI1500: 36590 --> Address will be 0x90,0x65,0x?3,0x?? (,0x01) > MI1500: 14456 --> Address will be 0x56,0x44,0x?1,0x?? (,0x01)
Hi! @petersilie, you are right the datarate is wrong! Thanks for the support, I recompiled the firmware for 250K and flashed the dongle again, and now I am seeing some packets with the serial numbers of MI, see the attached file, now I think we can go forward, I know the data is update at Hoymiles every 15 minutes the last number in address is always xx:xx:xx:xx:01. The dongle with this results is far from the MI, I will take it close again. If anyone have a idea to what channel/address to scan I can provide it.
Brilliant!!! These all appear to be messages from your DTU (serial number ...70:53:54:53) to various inverters. They're all 11 Bytes long, and we're not seeing any replies. Maybe some sort of "ping"? Are your inverters running? Not sure why we think that the DTU only communicates on the given channels (1 3 6 9 11 23 40 61 75). My guess is that maybe the channels are selected based on serial number. Or maybe they are switched dynamically somehow... Maybe you could try monitoring "all" available channels? Not sure how well that will work though - since at any given moment in time you will likely be looking at the "wrong" channel!
@petersilie @arnaldo_g, if all the messages are from the DTU towards the inverter we have a new message id. In this document: https://www.mikrocontroller.net/attachment/549922/hoymiles-datenformat-r2.txt and also in martins excel the MID 0x83 was only shown as a response form the inverter towards the DTU. But now we see 0x83 also from the DTU towards the inverter. 0x82 seems to be completly new
My inverters are running, attached a new log from a closest place with more log. This is the DTU: [2022-03-12 09:17:15.329] 40 0 90:65:23:74:01 I am running a scanner on all channels, but it´s seens losting a lot of package, I will leave it running for some hours and post here after!
Thanks Arnaldo, just to clarify. In an older post you wrote, that your serial number of your DTU ends with 35453 ? > DTU: 35453 > MI1500: 36590 > MI1500: 14456 But in your last post, you wrote "90:65:23:74:01". For me there are no similarities. Would you be so kind and give us the last 8 digits of the serial number from your DTU and your Hoymiles please ? Thanks a lot for your work Marcel
Marcel, Sorry I made a mistake, is not that line, see below, you can see it in last log nrf24_4.txt file, the serial is 70535453. [2022-03-12 09:16:58.926] 23 0 53:54:53:70:01 this is another MI. [2022-03-12 09:17:15.329] 40 0 90:65:23:74:01
Angehängte Dateien:
I just wrote a small parser to analyze the data from @arnaldo_g. It's maybe easier to find some logic in the channel selection. Unfortunatly it seems that all messages from the inverters to the DTU are empty.
:
Bearbeitet durch User
Correct, the reason for this result is that arnaldo is using the scanner. This one only shows the connections between the devices. Based on the code it analyses only the first bytes of the protocol. Arnaldo (@arnaldo_g) can you use the ./nrf24-sniffer.py. I'm not quite sure about the params. Maybe ./nrf24-sniffer.py -a 90:65:23:74:01 or ./nrf24-sniffer.py -a 53:54:53:70:01 I think this should result in a more detailed output. Marcel
Yes, sure I will run! Attached is a scanner in all channells with a DWELL of 10s.
Hi all!
seens the firmware for the dongle have some hardcoded parameters, I
leaved it running for about a hour and nothing was catch by sniffer,
after I analysed the code and change another point to 250K, maybe it
need some ajusts to sniff the packages.
I also changed (in radio.c / line 388) to RATE_250K recompile and
reflashed the device, but running "./nrf24-sniffer.py -a 36:49:51:70:01"
nothing is recorded...
// 2Mbps data rate, enable RX, 16-bit CRC
configure_phy(EN_CRC | CRC0 | PRIM_RX | PWR_UP, RATE_2M, 0);
If anyone is familiar with the radio and it´s parameters can look the
code, maybe can help more!
If someone have a idea please let me know to try again....
Grasping at straws here, but you could try reversing the order of the bytes to the -a parameter:
1 | ./nrf24-sniffer.py -a 01:70:51:49:36 |
(The source code reverses them before passing them on to the underlying layer "enter_sniffer_mode()", but it appears to do no such thing when printing the results coming from there.)
Martin G. schrieb: > Grasping at straws here, but you could try reversing the order of the > bytes to the -a parameter: > >
1 | ./nrf24-sniffer.py -a 01:70:51:49:36 |
> > (The source code reverses them before passing them on to the underlying > layer "enter_sniffer_mode()", but it appears to do no such thing when > printing the results coming from there.) Martin, about a hour running and nothing was logged..... root@retropie:/home/pi/nrf-research-firmware/tools# date Sat 12 Mar 17:09:04 -03 2022 root@retropie:/home/pi/nrf-research-firmware/tools# ./nrf24-sniffer.py -a 01:70:51:49:36
Hallo um sichern zu sein, dass meine Pseudo-DTU (Arduino ProMini + nRF24L01) funzt, habe ich mir ein Testprogramm geschrieben, das den WR simuliert. FDaten kommen an, ich setzte das Bit 8 und sende an die "DTU" zurück. Und die kriegt das auch, zwar nicht bei jedem Senden, aber wenigstens kommt was an. Und ich bin sicher, dass meine Hardware funktioniert. Aber weiterhin kommt von richtigen WR aufm Gartenhaus nix. Ich vermute entweder eine spezielle Einstellung der RF24-Parameter oder eine spezielle Sequenz von Telegrammen von DTU->WR. Meine RF24-Parameter sind: Kanal 3 Speed 250000 kbps payload=27 autoAck=true adressbreite=5 Sollte doch passen, oder?
Angehängte Dateien:
-
ali-002.jpg
24 KB -
ali-001.jpg
21 KB -
ali-003.jpg
24 KB -
ali-004.jpg
25 KB -
ali-005.jpg
18 KB
Hallo, eine Frage an diejenigen, bei denen es scheinbar schon ein bischen klappt mit dem Senden / Empfangen: Welches nrF24 Modul nutzt Ihr ? Es gibt ja verschiedene ? Ich wollte mir eines bestellen. Danke. Einen schönen Sonntag wünsche ich Dir / Euch.
ich habe hier ein ali-005 @Hubi: das mit der Kanalauswahl ist sehr seltsam. Weil bzgl. der Dumps von @arnaldo_g scheinen ja alle möglichen Kanäle involviert zu sein. Wann welcher ausgewählt wird ist mir noch nicht klar.
Hallo, Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen der Beiträge durch den Kopf ging: nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are used. In nrf24_4.txt we have a lot of packages with the address of the DTU and zero payload. Could this be ACK packages from the DTU to the WR? When the WR answers, could it be, that it uses the address of the DTU? However we see only data from the DTU. Maybe the usb sniffer has a 'weak' antenna. @arnaldo_g Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, 75, 83 but put the sniffer as near as possible (minimum wall in between) to one of the MIs? @hoymiles-datenformat-r3.txt Regarding the first xlsx from martin I think []=Spekulation: 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)] 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02] VG Frank
Frank H. schrieb: > Hallo, > Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen > der Beiträge durch den Kopf ging: > > nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are > used. > In nrf24_4.txt we have a lot of packages with the address of the DTU and > zero payload. Could this be ACK packages from the DTU to the WR? > When the WR answers, could it be, that it uses the address of the DTU? > However we see only data from the DTU. Maybe the usb sniffer has a > 'weak' antenna. > @arnaldo_g > Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, > 75, 83 but put the sniffer as near as possible (minimum wall in > between) to one of the MIs? > > @hoymiles-datenformat-r3.txt > Regarding the first xlsx from martin I think []=Spekulation: > 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)] > 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 > 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02] > > VG > Frank Hi Frank, I tried the sniffer in the same place but I can´t get anything, I think the code for the sniffer have something different... The distance for the DTU is about 3 meters and for 1 MI is about 1 meter, for another MI 1,5meters and the others is about 4-5 meters.... the wall is just a thin wooden about 4-5mm..... Yes the antenna of the sniffer is tiny, it´s a logitech unify dongle, but for 250k and the frequency it´s should work nice... When using the dongle with the logitech keyboard I can go far and it´s still working.... Also I have tried some changes on scripts and code of the nrf-research-firmware but no luck, I think the sniffer is not working, maybe because the CRC, payload or another radio configuration....
Hi! More one log, I think it will not help anything, but just to see the difference, I changed the script parameters and run it, then I runned the original code.....
I agree with arnaldo_g, fh_, etc. There might well be some setting that we're missing - therefore we're not seeing the packets we expect to see. CRC and Baud Rate settings seem fine to me. Not sure what to do about the different channels. Until we figure out how the devices "hop" between channels, we will miss packets. But we should be able to see at least some. It would be interesting to see if the inverters always stay on the same channel, or if they switch channels... "martin (Gast)" seems to have the most insight into how the RF side of things work. Maybe he has some more ideas? Also, maybe the Logitech dongle isn't quite the same as an "NRF24L01+", and the nrf-research-firmware definitely has some quirks. I bought some NRF24L01+ modules and will try to interface them to a RaspberryPi. This might give better results. @arnaldo_g - do you have any NRF24L01+ modules that you could try instead of the Logitech dongle?
Hi Martin, I have a Nrf24l01 module that I buyed, and put on my drawer to wait the results, when I found this forum.... :) After that I found the nrf-research-firmware, and I found a Logitech dongle that can run it... And started with some test and put the results here... This Logitech dongle model C-U0007 seens to have a NRF24L01+ IC, but I don´t have much time to code a new firmware and try....
Another thought: Could we try to "ping" the known addresses, cycling through "all" channels? I believe the NRF24s should answer to a "ping" (empty payload) all by themselves. I should be able to try this with my NRF24s in a couple of days' time.
Hi Guys, sorry for my late reply - I have a roof reconstruction going on at home, so little time for playing with my inverter and no panels installed at the moment ;-) As I mentioned in my post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" I got good results with the NRF sniffer from yveaux. Since you have dedicated addresses and CRC checked packages, you can filter out a lot of garbage. Downside is, that you can only sniff one side of the communication (per computer - so I have to setup a second one to sniff both sides). As you can see in the wireshark screenshot, the packets are acknowledged. So ACK is on. @Arnaldo: I would limit sniffing to the channels 3/23/40/61/75 since these are approved in the FCC report and I have verified them with a spectrum analysis. see: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" My guess(!) about the channels is, that the information is redundant. That would mean, the DTU hops to every channel and transmits the same information - to have a chance of getting data even in wifi contaminated areas. So for the beginning, it should be sufficient to focus on one channel. A first glance at the RF data on channel 23 instead of 3 seems to support my guess.
Angehängte Dateien:
-
last2bytes.png
3,7 KB
Hi everyone, I started another quick test without the inverter (DTU trying to connect), to compare the serial data on the DTU with the RF packets sniffed with Wireshark. An important part in the request by the DTU seems to be coded in the last 2 Bytes before the CRC8. They alter with the time stamp, but I have no idea what they encode. Maybe some flags?
Hi, I also join the party as I'll receive soon a HM-600 inverter. I don't favour cloud services and try to keep my data in-house. Concerning the last two bytes before the CRC: Is that lower nibble of the first byte always "B"? To me it seems unlikely to put changing flags in an initial connect request which contains the same data besides the changing time stamp. IMHO it could be 1. some kind of pseudo random number (drawn from an internal µC counter) and used as a packet number. In this case the answer of the inverter should include somewhere the same number. or 2. some kind of authentication, e.g. a ciphered time value using a shared secret between the DTU and the inverter. just an idea... ;-)
or 3. Yet another CRC/"checksum"? (It changes whenever the content changes.) In that case: how is it calculated? Since it doesn't change when the source address gets swapped out by the µC, if it is some kind of checksum, it is likely only influenced by the bytes following the address information. Have we ever seen a reply from the inverter in response to a 0x80 message? That might give us some more clues.
Angehängte Dateien:
Success! Thanks, @docbmuc and @martin (Gast)! I cycled through some predefined CRC functions. Turns out our mystery bytes are the same type of CRC as used by the "Modbus" protocol, see picture. Works for all the examples in "martin" (Gast)'s SerialData_RFSniff.xlsx, and for the one I originally documented in hoymiles-datenformat-r3.txt. New revision of said document attached.
Hallo Martin, das heisst Du hast es jetzt geknackt? :-) Bin gespannt, hier wartet auch nich ein HM-1200 DTu werde ich mir keine kaufen - eher kommt der ganze Hoymiles-Schrott weg...
Amazing! Based on @petersilie info I adjusted the test program. I cannot test it at the moment (lack of sun) but the crc calculation should work as expected. Maybe it helps someone. (used libraries are also documented in the platformio.ini file) I tested the source with an ESP32
:
Bearbeitet durch User
@petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter oben [1]. Dort ist ein ESP-12F abgebildet. [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Thomas das setzen des CRC16-Polynom in Zeile 66 kann aber nicht ganz stimmen, das sind mehr als 16 bit. Und wenn ich nur 0x8005 und bei online-CRC16M Rechnern eingebe kriege ich nicht das gewünschte Ergebnis. Vllt bin ich auch etwas irritiert. Ich bin ganz g... auf deine Klarstellung und dann werde ich morgen wieder meinen ProMini bruzzeln bis er durchbrennt oder endlich eine Antwort kommt.
Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut Spitze wie sich das hier entwickelt. Auf meinem Vordach sonnt sich ein HM-600 und wartet darauf seine Daten preiszugeben. Ein NRF24-Modul ist im Zulauf, also bin ich hier auch bald bereit zum Mitspielen 😉 Mit freundlichen Grüßen Matthias
Hallo Hubi, jetzt hast du mich etwas blank erwischt :) Also in Python klappt es so:
1 | import crcmod |
2 | f = crcmod.mkCrcFun(0x18005, initCrc=0xFFFF, xorOut=0x0000) |
3 | payload = bytes((0x0B,0x00,0x62,0x09,0x04,0x94,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00)) |
4 | print(hex(f(payload))) |
Das Ergebnis ist wie erwartet: 0x229 (Wichtig ist hier, dass die kompletten 14 byte angegeben werden) Und auch hier wenn man es im Online Calculator eingibt erscheint das korrekte Ergebnis: https://crccalc.com/?crc=0B00620904940000000000000000&method=CRC-16/MODBUS&datatype=hex&outtype=0 Die 0x18005 habe ich aus der Doku von crcmod: http://crcmod.sourceforge.net/crcmod.predefined.html
:
Bearbeitet durch User
Sorry Thomas, mit 0x8005 passt es doch
Angehängte Dateien:
-
crc_modbus.png
110 KB
Hallo Martin, perfekt - damit wissen wir jetzt das komplette Anfrage-Paket. Ich habe auch nochmal ein paar Datenpakete überprüft, es passt auch für das Paket ausgehend von der DTU mit 0x11 anstatt 0x0B im ersten Byte (nach den Adressen). In den Antworten vom WR habe ich die Modbus-CRC bisher aber nicht entdecken können. Für diejenigen, die ihre CRC-Berechnungsfunktion oder weitere Pakete prüfen wollen, siehe Einstellungen für HxD im Screenshot. Thomas B. schrieb: > Maybe it helps someone. (used libraries are also documented in the > platformio.ini file) > I tested the source with an ESP32 @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. War gestern Abend aber auch nicht sicher, ob die Speisung mit Netzteil funktioniert hat - zumindest hatte der WR mal grün geblinkt... Matthias B. schrieb: > Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut > Spitze wie sich das hier entwickelt. @Matthias, ja ich bin auch begeistert, wie das hier Fahrt aufgenommen hat ;-)
Habe mit meinem Testprogramm (mit CRC16) bisher auch keinen Erfolg, es kommt einfach keine Antwort. Ich vermute, da fehlt die richtige Initialsequenz. Ein Mitschnitt der Kommunikation vom Einschalten der DTU an wäre bestimmt sehr hilfreich.
Ich habe mir jetzt auch mal diese Logitech Dongles von Arnold geholt. Ich bin mir irgendwie nicht sicher, was die NRF library raus sendet. Ich hab das Gefühl, die fügt noch was hinzu. Ich teste dann mal mit meinem ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht vorstellen, das es eine genaue Schrittfolge geben soll. Marcel
Thomas B. schrieb: > @petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um > einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter > oben [1]. Dort ist ein ESP-12F abgebildet. > > [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Du hast natürlich Recht, danke. Ich werde das anpassen.
Marcel schrieb: > [...] > Ich teste dann mal mit meinem > ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die > einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht > vorstellen, das es eine genaue Schrittfolge geben soll. Dass es eine genau einzuhaltende Reihenfolge geben soll, scheint mir auch unwahrscheinlich. Ich denke aber, der WR wird (für längere Zeit/nur) auf einem der verfügbaren Kanäle zuhören. Und vielleicht nur jede Stunde oder so den Kanal wechseln, wenn er in der Zeit nichts sinnvolles empfangen hat. Die DTU, bzw. unsere Version davon, muss also zuerst mal auf allen Kanälen ein "PING" schicken, um zu sehen, ob der WR vielleicht zufällig gerade auf diesem Kanal zuhört. Erst dann sind weitere Anfragen überhaupt sinnvoll. Die DTU scheint das nach den Logs hier im Thread ja auch so in der Art zu machen. Ich meine, im Datenblatt zum NRF24 gelesen zu haben, dass ein "0-Payload"-Paket wie ein "PING" funktioniert, d.h. die Gegenstelle wird brav mit "ACK" antworten. Vielleicht könnten wir als ersten Schritt probieren, solch einen "PING" auf die jeweils bekannte(n) Seriennummer(n) auf allen Kanälen zu programmieren? Danach stellt sich die Frage, welche Anfrage wir dann schicken sollten. Die mit der Uhrzeit ist eventuell nicht die hilfreichste - welche Antwort erwarten wir denn darauf? Wie wäre es mit der "Nachricht 0x81: DTU an WR: "Anfrage DC-Daten""? Da würde ich dann die DC-Daten als Antwort erwarten.
:
Bearbeitet durch User
Einfach anfangen klingt sinnvoll :) Ich habe auch gesehen es gibt einen Dynamic Payload Length Modus. Im Excel von martin haben wir ja verschieden lange Pakete. Das Payload control field in [1] war 0x0d8 = 11011000 Laut Kapitel 7.3.3.1 in [2] ist wird die Payload Length (6 bit lang, siehe Kapitel 7.3.3) nur verwendet wenn die Dynamic Payload Length function aktiv ist. Vielleicht ist das auch noch ein Punkt der zum Erfolg fehlt... Hätte an meinem Code das hier geändert:
1 | //radio.setPayloadSize(27);
|
2 | radio.enableDynamicPayloads(); |
[1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" [2] https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf
:
Bearbeitet durch User
Hallo, was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 Frequenzen abgeklappert werden. "Channel List 2403, 2423, 2440, 2461, 2475MHz" Nur einen Channel zu testen bringt doch nix bzw. wäre Zufall, das der WR genau da horcht. Ich kenne mich mit "C" leider nicht so aus. Ich vermisse da jedenfalls eine Schleife die alle 5 Frequenzen abcheckt. @Petersilie: Vielleicht mal die Frequenzen in r6 mit aufnehmen :-) Viele Grüße an Alle, die hier mitarbeiten.
:
Bearbeitet durch User
Herbert K. schrieb: > was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 > Frequenzen abgeklappert werden. Siehe Anhang... hatte das bei mir schonmal implementiert aber aktuell hats keine Sonne :-(
Nur zur Info: bei irgendwelchen neuen Erkenntnissen über die Kommunikation klappere ich mit meinem Testprogramm alle bekannten Kanäle ab. Bin mal gespannt wie oft ich noch bruzzeln kann, bis der uC die Krätsche macht.
Hallo, Marcel schrieb: > int channels[5] = {3, 23, 40, 61, 75}; > 35 mit diesen Kanälen hatte ich damals immer getestet und habe diese dann irgendwann mal auf int channels[9] = {1, 3, 6, 9, 11, 23, 40, 61, 75}; angepasst. Alle Informationen, die hier im Forum herausgefunden wurden, habe ich in meinem Script angepasst und immer auf diesen Kanälen getestet. Leider bisher noch kein Erfolg in Form von einem ACK oder sogar Statistiken vom WR. Marcel
Marcel schrieb: > Alle Informationen, die hier im Forum herausgefunden wurden, > habe ich in meinem Script angepasst und immer auf diesen Kanälen > getestet. Hast du die dynamicPayload auch schon getestet oder erst alle Dinge die vor heute Abend hier standen? Ich halte das aktuell für vielversprechend.
Bin zwar nicht angesprochen, aber DynamicPayload und Payload 27 (siehe Erkenntnisse irgendwo oben) probiere ich ständig abwechsenld aus.
@martin (Gast), hattest du schonmal versucht mit einem NRF24 den WR zu pollen? Falls die DTU im initialen Setup $Dinge im WR einstellt damit dieser antwortet, müsste das ja bei dir passiert sein und er sollte dann auch einem "eigenen" NRF24 antworten?
martin schrieb: > @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom > Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 > eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. Hallo Thomas. Ja, ich hatte es getestet - leider ohne Erfolg. Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und NRF24 - sobald es etwas neues gibt, melde ich mich.
Angehängte Dateien:
-
1647617263224.jpg
120 KB -
1647617263215.jpg
270 KB
martin schrieb: > Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und > NRF24 Also meine bisherigen Versuche mit eurer als auch eigener Software sind fehlgeschlagen - obwohl 2 NRFs miteinander Pingpong spielen (Funkmodul tut also). Aber was ich sagen kann, der Inverter lässt sich mit einem 24V Netzteil (nominal 2,5 A/60W) speisen und funktioniert dann auch. Das ermöglicht mir zumindest auch mal Abends zu testen. Pascal A. schrieb: > hast du noch mehr Daten zu deinem Wechselrichter? > Vielleicht sind es Daten zu Einstellungen, Firmware, .. @Pascal, hier noch die Daten, die ich dir schuldig geblieben bin -> Siehe Screenshot.
kann es vielleicht sein, daß die eigenen NRF24L01 1 Mbps statt 256kbps nutzen. Meiner jedenfalls will trotz Programmierung nach den SDR-Aufnahmen keine 256kB senden. Liegt aber evtl auch an mir ?
NRF24L01 = 1 MHz u 2 MHz NRF24L01+ = 256 K u. 1 u 2 MHz (ohne Gewähr)
Herbert K. schrieb: > NRF24L01 = 1 MHz u 2 MHz > NRF24L01+ = 256 K u. 1 u 2 MHz daran liegts dann bei mir bzw. meinen Modulen. Ich werd mir 24LE01 bestellen, wie sie verwendet werden.
Mit Interesse lese ich hier schon seit ein paar Tagen mit. Mein WR (ein HM600) kommt hoffentlich im April, die nrf24 Module sind schon da. Laut Datenblättern sieht es tatsächlich so aus, dass der nrf24L01+ die 250kbit/s kann: https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf#page24 Der nrf24L01 (ohne +) kann nur bis 1Mbit/s runter: https://www.mouser.com/datasheet/2/297/nRF24L01_Product_Specification_v2_0-9199.pdf Ich bin gespannt, wie es weiter geht und hoffe dass ich demnächst auch ordentlich mitmischen und programmieren kann sobald der WR da ist
Hallo, ich habe mir mal zwei NRFs aufgebaut und der eine sendet die Daten so, wie der WR sie eigentlich empfangen soll und wie es hier im Forum gepostet wurde. Den zweiten NRF habe ich mit einer Scanner logig beschrieben (https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183). Dieser Scanner findet auch ein paar valide Nachrichten in meinem Umfeld - aber leider nicht die, die ich mit dem anderen NRF sende. Dazu habe ich im Scanner mal nur den channel = 3 (und im while loop das channel++ auskommentiert) eingestellt und der 2. NRF sendet auch aller 140ms auf diesem Kanal. Sind wir denn sicher, das die CRC Berechnung korrekt ist (ich bin leider kein Experte in Bit Operatoren und Bit Verschiebung). Zeile, die prüft ob die CRC die empfangen wurde auch einer Berechnung stand hält befindet sich hier: https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183 Marcel
Ein anderer Ansatz: man könnte versuchen, die Firmware aus dem nRF24LE1 auszulesen. Die SPI-Schnittstelle dafür ist auf der DTU-Platine beschriftet. Sollte das Flash nicht lesegeschützt sein, könnte man sich die Initialisierung/Kommunikation mit dem RF-Kram via Disassembler ansehen. Zum Auslesen gibt es verschiedene Möglichkeiten: FTDI FT232R: https://github.com/jdelfes/nrf24le1_flasher
1 | nrf24le1_flasher --read-flash readout.bin |
RaspberryPi: https://github.com/derekstavis/nrf24le1-libbcm2835
1 | nrf24le1 show |
2 | nrf24le1 read firmware readout.bin |
Arduino: https://github.com/DeanCording/nRF24LE1_Programmer/blob/master/Read_Mainpage/Read_Mainpage.ino
Mein Wechselrichter ist angekommen!
Leider bisher ohne DTU ("Lieferschwierigkeiten" - große Hoffnungen habe
ich nicht).
Mein Testsetup besteht aus 2 RaspberryPis mit jeweils einem NRF24L01+
Modul.
Auf einem Pi läuft der "pretender", der sich wie ein WR verhalten soll.
Auf dem anderen Pi läuft der "discoverer", der nacheinander eine
Testnachricht an alle einprogrammierten Seriennummern auf allen Kanälen
sendet, und jeweils anzeigt, falls er ein ACK zurückbekommt.
Der "discoverer" findet auch brav den "pretender", auch wenn ich diesen
zwischendurch auf einen anderen Kanal wechsle.
ABER mein Wechselrichter antwortet nicht.
Das führt mich zu folgender Schlussfolgerung:
Der Auto-ACK-Modus ist Wechselrichter-seitig vermutlich doch nicht
aktiv.
Hat jemand auf der Funkschnittstelle schon mal wirkliche ACK Pakete
gesehen? Das "nACK" Bit im "PCF" sagt ja nur, ob der RF-Transceiver das
Paket bestätigen soll, sofern Auto-Ack eingeschaltet ist. Wenn das
nicht der Fall ist, wird er auch keine Bestätigung senden, egal welchen
Zustand das nACK Bit hat.
Ich habe mal ein Github-Repo für die Hoymiles-Kommunikation angefangen.
Vielleicht können wir das gemeinsam erweitern?
Mein Quellcode liegt hier: https://github.com/grindylow/ahoy
Ein zielführender nächster Schritt wäre, zu versuchen, einen 'pretender'
als weiteren Wechselrichter an eine DTU anzulernen.
Dann sollten wir sehen, welche Pakete die DTU an die entsprechende
Seriennummer schickt, und können von dort Stück für Stück die weitere
Kommunikation beobachten. Hat jemand die Möglichkeit, das
auszuprobieren?
@arnaldo_g, do you think you might be able to program your receiver to respond to the same address as one of your inverters? That way it should receive the queries from the DTU directly, without us having to guess what the sniffer tool may or may not be doing to the received packets. Also, at night, the inverters will stop replying, but traffic to the 'pretend' receiver should continue.
Hallo zusammen, ich habe hier nochmal ein paar Captures zusammengestellt, vielleicht hilft es dem Projekt ja weiter, wenn da noch jemand anderes draufschaut. Es sind .sal (Saleae Logic) Captures der seriellen Schnittstelle in der DTU. Und .pcapng (Wireshark captures) mit dem yveaux NRF24 sniffer, jeweils auf den bekannten Adressen. Interessanterweise antwortete der Inverter nur auf einem Kanal von den 3 betrachteten. Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung stellen, diese können im Universal Radio Hacker geöffnet werden. Sind aber mehrere Hundert MB groß, deshalb nur auf Anfrage. Ich vermute, dass die DTU alle Kanäle durchtestet und wenn der Inverter antwortet, diesen Kanal dann weiterhin verwendet. Kann das aber im Moment leider nicht verifizieren, da der Java Spectrum Analyzer seit dem Firmwareupdate des HackRF nicht mehr tut... Schönen Sonntag noch.
Hallo in die Runde, ich möchte eure interessante „Forschung“ nicht stören, habe aber vielleicht einen hilfreichen Hinweis: Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese zuallererst bei der Basis registrieren musste, bevor eine Kommunikation möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn man eine andere DTU verwenden wollte, musste man den WR zuerst de-registrieren und dann neu registrieren. Die Registrierung erfolgte mit der Master-ID, der Seriennummer der DTU. Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ erfolgen.
Angehängte Dateien:
martin schrieb: > Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung > stellen, diese können im Universal Radio Hacker geöffnet werden. Sind > aber mehrere Hundert MB groß, deshalb nur auf Anfrage. Hallo Martin, solche RF-Aufnahmen, z.b. als IQ-File, wären sicher am besten. Da würden ganz kurze Ausschnitte davon mit den Sendungen ja voll ausreichen. Die könnte man dann selbst demodulieren, falls nötig. Als Anhang eine demodulierte Sendung von meinen Versuchen. Ich hab da momentan kein 16-bit CRC dran. Ist dieser immer vorhanden beim Senden ? ( da die demodulierte Sendung nicht mittig liegt, hab ich eine relativ große Frequenzabweichung. Da muß ich den Quarz am NRF noch besser abgleichen) Gruß golf
:
Bearbeitet durch User
Angehängte Dateien:
-
stream.png
7,3 KB
Hallo zusammen. Ich habe auch zwei Hoymiles Modulwechselrichter und eine DTU Lite. Ich habe mir nun, inspiriert durch die bisherigen Inhalte, zwei NRF24L01+ Module besorgt und diese mit einem Arduino nano gekoppelt. Ein Modul bekommt als Adresse die Adresse der DTU, das andere die Adresse eines der Wechselrichter. Damit schneide ich den Datenverkehr zwischen DTU und Wechselrichter mit. Ich nutze dazu den yveaux NRF24 sniffer in abgewandelter Form. Zunächst ist dabei nur ein Daten Durcheinander herausgekommen. Wenn man allerdings den gelesenen Nutzdaten Stream jeweils um ein Bit nach links verschiebt, sieht das Ganze ein wenig besser aus. Meine DTU hat die Adresse 0x50908172. Die Wechselrichter haben diese Adressen: WR1 0x19461073. WR2 0x39441073. Am Beispiel eines empfangenen Rohdatenstreams wird aus:
1 | 01-6C-4A-B9-88-23-0C-B9-88-23-0C-80-80-00-80-AC-00-AE-02-55-00-AB-00-AA-82-46-00-00-5A-17 |
Beim Schieben des ganzen Streams um ein Bit nach links diese Bytefolge:
1 | 02-D8-95-*73-10-46-19-73-10-46-19*-01-00-01-01-58-01-5C-04-AA-01-56-01-55-04-8C-00-00-B4-2E |
Ab Byte 3 wird darin zweimal hintereinander die Adresse eines der Wechselrichter gesendet. Allerdings wird die Wertigkeit gedreht, aus 0x19461073 wird 73-10-46-19. Wende ich dies auf die empfangenen Streams an und formatiere es ein wenig, so tauchen an den Stellen im Stream nur die bekannten Bytefolgen der Adressen auf, allerdings in umgekehrter Reihenfolge. Siehe Anhang. Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen Seriennummern bestätigen?
Super! Tolle Mitschnitte und Erkenntnisse! Das mit dem Verschieben um 1 Bit macht Sinn, da das "Enhanced Shockburst"-Protokoll seinen Vorgänger, das "Shockburst"-Protokoll, um ein 9-bit "Packet Control Field" erweitert. Alles nach diesem "PCF" erscheint dann um ein Bit verschoben. So wie ich das verstehe, arbeitet der "Sniffer" im "normalen" Shockburst Modus, wo man dem Chip wohl beibringen kann, auch Pakete durchzuleiten, die nicht CRC-geprüft sind. Eventuell gehen allerdings dafür die letzten Bytes verloren, das würde erklären, wenn Dir am Ende die protokoll-eigene CRC fehlt. Shockburst ist wohl auf 30 Bytes beschränkt, und da gehen die 5 Adressbytes noch weg, also können 27 Byte lange Nachrichten inkl. CRC evtl. nicht mehr ganz gelesen werden. Das ist aber kein Problem, denn wenn wir so weit sind, können wir die Nachrichten ja auch im echten "Enhanced Shockburst" Modus mitlesen. Zu Deiner Nachricht: Das passt super. Mit den verschobenen Bits ergibt sich nämlich direkt die Nachricht [0x01: WR an DTU: "Aktuelle DC Daten"], siehe hoymiles-datenformat-r5.txt.
1 | 02-D8-95-*73-10-46-19-73-10-46-19*- [01-00-01-] |
2 | 01-58- 01-5C- 04-AA- |
3 | 01-56- 01-55- 04-8C- 00-00- B4- 2E xx |
Dein WR Seriennummer xxxx73104619 sieht * Auf Kanal 1: 34.4 V; 3.48 A; 119.4 W * Auf Kanal 2: 34.2 V; 3.41 A; 116.4 W Die Bedeutung der anfänglichen [01-00-01] kennen wir noch nicht genau. Die erste 01 ist vermutlich ein Befehlscode.
:
Bearbeitet durch User
Angehängte Dateien:
Oliver F. schrieb: > Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen > Seriennummern bestätigen? Hallo Oliver, ja, das sieht vertraut aus. Ich erkenne darin die bereits analysierte Paketstruktur wieder. Man sieht die Anfrage von der DTU mit der Kennung 0x15, danach das übliche 0x80 0x0B, die Unix-Zeit 0x62... Die Antwort vom Inverter beginnt mit 0x95 und enthält die Daten wie Martin G. oben schon aufgeschlüsselt hat. Was mir hier und auch in meinen Daten aufgefallen ist: In den Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun haben, der für die Antwort verwendet werden soll? Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden, wenn die DTU nach dem Inverter "sucht". Demnächst werde ich noch aufzeichnen was passiert, wenn der Inverter dann antwortet. Anbei noch wie von golf angemerkt eine kurze Sequenz auf Kanal 40 als IQ File zur Analyse mit dem Radio Hacker.
Angehängte Dateien:
-
NRF_Block3.JPG
180 KB -
NRF-Block_MomentanFM.JPG
88 KB
vielen Dank Martin für deine Aufnahmen. Es reicht eigentlich eine Realwandlung des IQ-Files, um die Bits abzulesen. Auch der Momentanfrequenzverlauf ist sehr sauber.
B. G. schrieb: > Auch der Momentanfrequenzverlauf ist sehr sauber. Hallo golf, mit welchem Programm hast du die Auswertung auf dem zweiten Bild gemacht? Die Bits sieht man hier viel deutlicher, als bei der Auswertung mit dem Universal Radio Hacker (URH). Durch die Verschiebung der Daten um 1 Bit wegen des 9-Bit Packet Control Fields ist auch die Hex-Ausgabe im URH nicht wirklich hilfreich. Ich hatte mir deshalb mit folgendem Excel-Template beholfen - ist natürlich Quick & Dirty, da die Bits nicht immer 100% passen, aber mir hat es definitv weitergeholfen, den Signalaufbau besser zu verstehen.
martin schrieb: > mit welchem Programm hast du die Auswertung auf dem zweiten Bild > gemacht? Hallo Martin, das ist alles von mir mal in Delphi selbst geschrieben im Programm für meinen Eigenbau-SDR. Ich hab auch einen Modulator gebaut, damit hab ich deine Aufnahme einfach wieder mit dem SDR empfangen können. Leider bringen Dir die Programme nichts ohne die Hardware dazu. Ich hab die Aufnahme erst auf 16 bit gebracht und als Wave gespeichert, da mein SDR nur 16 bits verarbeitet. Das Programm für die Complex to Realwandlung könnte ich evtl versuchen anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise demodulieren.
emhopa schrieb: > Hallo in die Runde, > > ich möchte eure interessante „Forschung“ nicht stören, habe aber > vielleicht einen hilfreichen Hinweis: > Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese > zuallererst bei der Basis registrieren musste, bevor eine Kommunikation > möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn > man eine andere DTU verwenden wollte, musste man den WR zuerst > de-registrieren und dann neu registrieren. Die Registrierung erfolgte > mit der Master-ID, der Seriennummer der DTU. > > Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ > erfolgen. So etwas dachte ich Anfangs auch. Ich mag mich täuschen, aber es sollte doch zumindest bei @martin (Gast) funktionieren, da bei ihm ja die Seriennummer der DTU schon im WR registriert sein müsste.
Liest sich wie ein Krimi. Ich drücke Euch die Daumen. Tolle Teamarbeit.
Finde ich auch! Ich drücke die Daumen. Mein DTU-loser Hoy HM-400 würde sich sehr gerne mit einem billigen Nachbau einlassen!
Angehängte Dateien:
B. G. schrieb: > Das Programm für die Complex to Realwandlung könnte ich evtl versuchen > anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise > demodulieren. Ich hab mal eine 1.Version meines Complex2Real Wandlers mit opt. Demodulation versucht, die auch die HackRF Files bearbeiten kann (.complex16s). Ich selbst habe keinen HackRF, nur meine Eigenbauten. Leider machen die aktuellen Delphi-Compiler auch aus einem kleinen Programm gleich Megabytes. Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von martin. Die Ausgabe des Programms ist immer ein Wavefile.
:
Bearbeitet durch User
Angehängte Dateien:
-
protocol.png
73 KB
B. G. schrieb: > Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten > Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von > martin. Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner Analyse-Excel.
gut daß es soweit funktioniert. bei den bei mir vorliegenden Hf-Aufnahmen sind nur Blöcke vom Inverter. sendet der DTU denn auf einer anderen Frequenz ? gibts HF-Aufnahmen oder demodulierte Sendungen vom NRF24 des DTU, die wären interessant ?
:
Bearbeitet durch User
Hallo golf, anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. Die zugehörigen seriellen Pakete und Wireshark Captures hatte ich bereits oben angehängt jeweils unter "Session 1". Wer wann auf welcher Frequenz sendet scheint momentan noch eines der größten Rätsel zu sein. Bei meinem Test am Sonntag spielte sich das meiste offenbar auf Kanal 40 ab. emhopa schrieb: > Wenn > man eine andere DTU verwenden wollte, musste man den WR zuerst > de-registrieren und dann neu registrieren. Die Registrierung erfolgte > mit der Master-ID, der Seriennummer der DTU. Ja, das kann schon sein - aber bei mir sind die beiden Teilnehmer bereits registriert. Also sollte doch theoretisch irgendwas durchkommen?
martin schrieb: > B. G. schrieb: >> Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten >> Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von >> martin. > > Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit > deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner > Analyse-Excel. Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen Auswertungen war das doch immer 0x01?
Thomas B. schrieb: > Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen > Auswertungen war das doch immer 0x01? Hallo Thomas, ja ist mir auch aufgefallen. Ebenso bei Olivers Daten: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" In den Wireshark Captures allerdings nicht, da ist Addr[0] = 0x01.
Angehängte Dateien:
martin schrieb: > anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. was mir aufgefallen ist. Da ist im Frequenzbereich noch ein 2 Inverter aktiv. Wenn ich die Samplerate mit 20 Mhz richtig interpretiert habe, dann sendet der 3 Mhz tiefer. Jpg ist Teil der auf Real gewandelten Aufnahme. sowas wie Start, $32,88,81,72,01, 011011000, $95,72,22,02,00,72,22,02,00, $01,00,01,00,E4,01,64,03,2D,00,02,00,02,00,00,00,00,3A,33,41.. wenn ich mich nicht verschaut hab. Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ?
B. G. schrieb: > Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich > darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ? Also die Pakete werden tatsächlich ein paar mal im Block so gesendet. Das ist vermutlich das automatische Retry, die Pause zwischen den Paketen beträgt ca. 1 ms. 3 MHz tiefer wäre dann Kanal 20? Ist das tatsächlich ein Signal oder kann das ein Fehler von meiner SDR-Messung sein? Das wäre natürlich ein wichtiger Hinweis, wenn der Inverter gar nicht auf den gleichen Kanälen antwortet wie die DTU...
martin schrieb: > kann das ein Fehler von meiner SDR-Messung sein? da der 2. NRF-Sender gleichzeitig (etwas verzögerter Start) mit auf der Aufnahme ist muß das so stimmen, auch die Frequenzen. Vorausgesetzt daß meine Annahme der Samplerate mit 20 Mhz stimmt. (gewandelte Realfiles haben bei meinem Programm dann immer doppelte Samplerate, da aus dem IQ-Stereo File ein Monofile wird). Aber ich hab das wohl falsch beschrieben. Es dürfte wohl so sein, daß auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz tiefer (2420 Mhz) der Inverter antwortet. Das Verhalten läßt sich bestimmt mit neuen Aufnahmen prüfen. Ob die Abweichnung der beiden Sendefrequenzen immer gleich bleibt, muß man sehen. (Ich weiss allerdings nicht, ob der HackRF irgendwas gemischt hat in diesen Bereich, da ich den nicht kenne, glaub das aber eher nicht).
:
Bearbeitet durch User
Angehängte Dateien:
-
HackRF_session1_2423MHz.png
120 KB
B. G. schrieb: > Es dürfte wohl so sein, daß > auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz > tiefer (2420 Mhz) der Inverter antwortet. Im Universal Radio Hacker (UHR) sieht es für mich so aus, als ob auf der Spektrummitte zwei Sender unterwegs wären. Einer mit stärkerem Signal (DTU, weil näher am HackRF?) und ein schwächerer (Inverter?).
Angehängte Dateien:
Hallo Daniel, das stimmt schon. Ich weiss halt nur nicht, ob das alles Aufnahmeschnipsel sind von mehreren Aufnahmen oder ob das alles am Stück auf der 2423 Mhz so statt gefunden hat. Das sind ja immmer nur kleine Teilstücke. Das kann nur Martin beantworten. Da wäre evtl so ein Bild eines Sonogramms einer Aufnahme aussgefähiger ohne ausgeschnittene Stellen.
:
Bearbeitet durch User
Angehängte Dateien:
Da wäre z.b. ein Sonagrammbild des ganzen Ablaufs ( der Aufnahme ) evtl aussagefähiger ohne die Aussetzer. Oder nimmt der HackRF squelchgesteuert auf oder sowas ? Ich lass bei mir immer die Aufnahmen durchlaufen (geht theoretisch bis die platte voll ist) ohne Sampleverluste. Hab hier nur keine DTU-Signale. Nachtrag: doppelt gesendet, das ist was schief gelaufen bei mir
:
Bearbeitet durch User
@martin (Gast) - könntest Du vielleicht die großen Originalcaptures bei einem Filesharing-Dienst hochladen? Wetransfer kann zum Beispiel kostenlos bis 2 GB. https://filetransfer.io/ wohl bis zu 6 GB.
Hallo Martin, golf und Daniel, leider war mein Studienschwerpunkt Automatisierungstechnik, deshalb bin ich bei den HF-Themen nicht ganz so fit - was heißt Squelch? ;-) Anbei die 3 Mitschnitte bei 3, 23 und 40 MHz als komplette Files (zeitgleich aufgenommen wie die Logic und Wireshark Captures). https://filetransfer.io/data-package/1Z2bKt05#link Samplerate und Bandbreite je 20M (samples/s bzw. Hz). In der RF-Aufnahme ist viel Mist dazwischen, weil Inverter und DTU ja offensichtlich immer zwischen den Kanälen hin und her wechseln und halt unvermeidlich WLAN oder sonst was in der Gegend rumfunkt. Kann das "Doppelbild" daher kommen, dass ich gleichzeitig zwei Arduino/NRF24 Sniffer mitlaufen habe lassen? Theoretisch müssten diese doch rein passiv zuhören, oder?
Angehängte Dateien:
-
test_setup.png
31 KB
Hier zum besseren Verständnis noch ein Bild, wie bzw. was ich gemessen hatte mit allen Teilnehmern. 3 Versuche auf den jeweiligen Frequenzen (2403, 2423 und 2440 MHz).
Angehängte Dateien:
-
HackRF_0_2403_Mhz__NRFs_auf_ca_2403_Mhz___mehr_als_2_Umtastfrequenzen_erkennbar.JPG
65 KB -
HackRF_0_2403_Mhz_2_NRFs_auf_ca_2403_Mhz_und_ca_2402_Mhz.JPG
52 KB -
HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG
79 KB -
HackRF_1_2423Mhz_2_NRFs_auf_ca_2423_Mhz_und_ca_2420_Mhz.JPG
74 KB -
HackRF_2_2440Mhz_2_NRFs_auf_ca_2441_Mhz_und_ca_2443_2_Mhz.JPG
75 KB -
HackRF_2_2440Mhz__NRFs_auf_ca_2441_Mhz__2441_5_und_ca_2443_Mhz.JPG
66 KB -
HackRF_2_2440Mhz__1_NRFs_auf_ca_2441_Mhz.JPG
68 KB -
HackRF_2_2440Mhz__1_NRFs_auf_ca_2443_Mhz.JPG
72 KB -
HackRF_2_2440Mhz_2_NRFs_auf_ca_2441_Mhz_und_ca_2443_Mhz.JPG
77 KB
hallo martin, squelchgesteuerte Aufnahmen nehmen nur auf, wenn ein bestimmter Empfangspegel überschritten wird. Aber bei dem HackRF kann das Verhalten auch durch die 8-bit bedingt sein, das sind jedenfalls für mich teils recht ungewöhliche Aufnahmen. Es gibt NRFs mit teils sehr unterschiedlichen Pegeln, dann bricht die Aufnahme teils abrupt ab. Das sind Aussetzer, weil der PC mit der Datenrate überfordert ist. Die 40 MB/sec sind halt ziemlich das Maximum für USB2, was geht. Evtl zur Sicherheit mal bei weiteren Aufnahmne die Sniffer-NRFs aus lassen. Bei kurzer Durchsicht gab es mehrere Stellen mit verschiedenen Frequenzlagen. bei der 2403 wurde teilweise fast auf der gleichen Frequenz gesendet. Dann sieht man scheinbar mehr als 2 Umtastfrequenzen. Siehe Bilder bei dem HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG sind wohl auch 2 NRFs fast auf der gleichen Frequenz. Scheinbar auch mehr als 2 Umtastfrequenzen. Muß näher untersucht werden
:
Bearbeitet durch User
Angehängte Dateien:
die unterchiedlichen Pegel der einzelnen NRFs verwundern etwas.
Angehängte Dateien:
Beim Überfliegen der Aufnahmen mit "inspectrum" (zum Öffnen: *.complex16s in *.cs8 umbenennen) ist mir angehängter Abschnitt aufgefallen. Zwei verschiedene Sender? Ein Paket mit Länge 27 und cmd=0x95 (-> Inverterdaten) und das andere ein 0-Byte-Paket - ist das ein ACK? Vielleicht vom Sniffer-NRF?
Angehängte Dateien:
Ich meine auch, daß da diese Sniffer vielleicht mitmischen. Anbei eine grobe Darstellung der Blöcke auf den Frequenzen mit diversen Pegeln. Ob die Blöcke von DTU/INV oder teilweise von den Sniffern sind ? Bei den beschriebenen Blöcken mit mehr als 2 Frequenzen scheint der Sender irgendwie instabil, sieht eher nicht nach 2 NRFs aus. Vielleicht sollten wir auf eine neue Aufnahme warten ohne die Sniffer-NRFs.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, leider habe ich keine DTU um mitzumischen. Warum versteift Ihr Euch so auf den HF Teil ? Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation zwischen dem GD... und dem nRF ? Einen Logic Analyzer da dran, der gleich die Kommunikation dort decodiert ? Mann müsste vielleicht mal alles in den Werkszustand versetzen. Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA loslaufen lassen. Wer weiss, ob die ganzen Register vom nRF überhaupt schon zu dem passen, was hier durch obige Programme und LIBs gemacht wird ? Vielleicht ist es nur 1 Bit in irgendeinem Register, was noch nicht passt ? Ist nur so eine Überlegung von mir. Ich will niemanden einen Vorwurf machen (falls sich jemand auf den Schlips getreten fühlt) ! ! ! ! Danke an alle, die schon eine DTU haben und Ihr Bestes geben ! ! ! Foto ist von (C)Martin. Nur die Aufmerksamkeit.
Herbert K. schrieb: > Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation > zwischen dem GD... und dem nRF ? Das wird schon so gemacht, siehe weiter oben. Aber der verwendete NRF ist nicht nur ein Transmitter, sondern auch ein Mikrocontroller. Die Kommunikation zwischen GD und NRF lässt deswegen nicht direkt auf das HF-Geschehen schließen. Was aber noch nicht versucht wurde: versuchen, ob der Flash vom NRF auslesbar ist. Siehe meinen Vorschlag: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Herbert K. schrieb: > Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA > loslaufen lassen. Ich schlage vor, kurz vor der Stromversorgung des DTUs jeweils HF-Aufnahmen zu starten. Evtl auch mit etwas weniger Samplerate, damit es weniger Aussetzer gibt. Nach ein paar Aufnahmeversuchen müßte man zumindest die Start-Sequenz(en) des DTU finden können. Vielleicht kommt man dann etwas weiter. Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?
:
Bearbeitet durch User
Gute Idee! Und am besten auch mal ohne die Sniffer-NRFs, nicht dass wir uns mit deren ACKs oder dergleichen verrennen.
B. G. schrieb: > Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ? Hallo golf, ja, tatsächlich sind die so entstanden, zumindest was die DTU betrifft und die Kanäle 3 und 23. Man sieht das auch gut an den seriellen Aufnahmen. Die UART-Pegel sind zunächst auf Low, gehen dann auf High und dann kommt die Initialisierung des NRF24LE1E (3x Request/Response). Danach beginnt das Suchen nach Invertern. Kanal 40 habe ich dann im laufenden Betrieb aufgenommen, nachdem ich gemerkt hatte, dass da mehr los war. Bei allen Versuchen war der Inverter vorher schon an, da er immer eine Weile braucht bis er initialisiert ist.
Angehängte Dateien:
Hallo zusammen. Eine Frage an alle die hier fleißig die HF Daten analysieren. Ich habe, wie bereits gesagt, auch einen NRF24 Sniffer am Laufen. Leider kann dieser nur auf die eingestellten Adressen lauschen. Der Chip unterstützt mehrere Datapipes. (Siehe Anhang) Ich denke, die WR werden eine Datapipe betreiben, mit deren Seriennummer als Adresse. Es muss aber noch eine andere Pipe geben mit einer Art Broadcast Adresse, die für alle WR gleich ist?!? Ich komme darauf, weil ich mehrmals den Hochlauf der DTU gesnifft habe. Sinnvolle Kommunikation sehe ich nur auf den Kanälen 3, 23 und 40, wobei die DTU auf Kanal 40 sehr selten vertreten ist. In diesem Beispiel ist es so, dass die Wechselrichter (C1) auf einmal anfangen zu senden, ohne dass zuvor ein Telegramm von der DTU an die Wechselrichter (C3) zu sehen ist. Ich habe das ganze relativ häufig auf den einschlägigen Kanälen probiert. In der Regel sind die ersten Telegramme immer WR=>DTU, ohne dass ich eine initiale Aktion der DTU sehe. Die Bedeutung der einzelnen Spalten habe ich versucht im Anhang zu dokumentieren.
1 | C1 026566496 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
2 | C1 026570128 00 0590817201 0006 00 3 EA5A EA5A |
3 | C1 026573400 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
4 | C1 026595440 00 0590817201 0000 00 0 8A9C 8A9C |
5 | C1 026597740 00 0590817201 0002 00 1 AADE AADE |
6 | C1 026613740 00 0590817201 00B8 17 0 95 73104439 73104439 83000000F303E80185000581B4BA142F 142F 1 |
7 | C1 027707212 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
8 | C1 027713144 00 0590817201 0006 00 3 EA5A EA5A |
9 | C1 027716424 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
10 | C1 027740752 00 0590817201 0000 00 0 8A9C 8A9C |
11 | C1 027756120 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
12 | C1 027764348 00 0590817201 0002 00 1 AADE AADE |
13 | C1 027767624 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
14 | C1 029551548 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
15 | C1 029557480 00 0590817201 0006 00 3 EA5A EA5A |
16 | C1 029560760 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
17 | C1 029585088 00 0590817201 0000 00 0 8A9C 8A9C |
18 | C1 029601636 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
19 | C1 029609864 00 0590817201 0002 00 1 AADE AADE |
20 | C1 029613140 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
21 | C1 029635176 00 0590817201 0004 00 2 CA18 CA18 |
22 | C1 029637480 00 0590817201 0006 00 3 EA5A EA5A |
23 | C1 034225220 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
24 | C1 034235752 00 0590817201 0006 00 3 EA5A EA5A |
25 | C1 034239032 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
26 | C1 034261072 00 0590817201 0000 00 0 8A9C 8A9C |
27 | C1 035451152 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
28 | C1 035457080 00 0590817201 0006 00 3 EA5A EA5A |
29 | C1 035460360 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
30 | C1 035482388 00 0590817201 0000 00 0 8A9C 8A9C |
31 | C1 035484696 00 0590817201 0002 00 1 AADE AADE |
32 | C1 035500772 00 0590817201 00BC 17 2 95 73104619 73104619 83000500F603E8018300213960F485BA 85BA 1 |
33 | C1 035995516 00 0590817201 00D8 1B 0 95 73104439 73104439 010001014803A70BF5014803AC0C0600006AEB1C EB1C 1 |
34 | C1 036029056 00 0590817201 0004 00 2 CA18 CA18 |
35 | C1 036044500 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
36 | C1 036055028 00 0590817201 0006 00 3 EA5A EA5A |
37 | C1 036058312 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
38 | C1 036080352 00 0590817201 0000 00 0 8A9C 8A9C |
39 | C3 037978808 00 1946107301 00DE 1B 3 15 73104619 72819005 801200623DA4AB000000000000000098C8DD09E3 09E3 1 |
Ist Euch bei der Analyse der HF Daten schon mal eine andere Adresse aufgefallen?
:
Bearbeitet durch User
Hallo Oliver, Danke für Deine Logs. Ich habe dazu wiederum ein paar Fragen/Anmerkungen: (1) Nach meinem Verständnis kann der NRF24 zwar von bis zu 6 "Pipes" = "Adressen" empfangen, aber nur Pipe 0 ist unabhängig, Pipe 1-5 teilen sich die ersten 4 Bytes, d.h. dürfen sich nur im letzten Byte unterscheiden (siehe Kapitel 7.7 "Multiceiver"). Das würde erklären, warum Du nur Nachrichten von C1 und C3 siehst. (2) In Deinen Mitschnitten tauchen auch wieder diese 0-Byte Payload Pakete auf. Laut Datenblatt sind das ACK-Pakete, die der Chip automatisch sendet, wenn er auf der jeweiligen Adresse etwas empfangen hat. Ich meine, bisher sieht es so aus, als sei diese ACK Funktion bei den Hoymiles Geräten deaktiviert. Wir sollten diese auf jeden Fall bei jeglichen Sniffern auch deaktivieren (setAutoAck(false)), sonst greifen die ja aktiv in den Funkverkehr ein. Vielleicht kommt da auch manche der Verwirrung weiter oben her - denn die Adresse dieser ACK-Pakete ist ja jeweils gleich der Adresse des ursprünglich empfangenen Pakets. (3) Bzgl. Deiner Frage wegen anderer Adressen - ich meine, martin (Gast) hatte auch schon einmal Adressen beobachtet, die in 0x00 (anstatt 0x01) enden. Als "Broadcast" zwischen allen WR würde das aber nicht wirklich taugen, hierzu würde sich vielleicht am ehesten die DTU Adresse eignen. Vielleicht gibt es bei Inbetriebnahme auch Broadcasts an 0x0000000000 oder so - auf uC-Seite scheinen manche Pakete solch eine Adresse zu enthalten. -- Petersilie
Angehängte Dateien:
Hallo Martin. Also ich habe jetzt mal etwas mit dem RF25L01+ Chip experimentiert. So ganz bin ich noch nicht dahinter gestiegen wie er funktioniert. Es ist sicherlich irgend so ein ASIC der als Schrittschaltwerk funktioniert ohne abhängige Logic, bzw. ohne die eingestellten Parameter zu prüfen. Er macht etwas in Abhängigkeit der eingestellten Register. Es kann schon mal sein, dass er völlig durcheinander ist und nur ein Spannungsreset hilft. So meine Beobachtung. Zu Deinen Fragen/Anmerkungen: (1) So wie ich es verstehe besteht die Möglicheit, dass die Adressen von Pipe 0 und Pipe 1 5 Byte lang sind. Pipe 2-5 betrachte ich nicht, diese hängen natürlich von den restlichen Bytes der Pipe 1 ab. Ich habe die Pipes auf die beiden Wechselrichter programmiert:
1 | pipe 0 ( open ) bound = 0x3944107301 |
2 | pipe 1 ( open ) bound = 0x1946107301 |
3 | pipe 2 (closed) bound = 0xc3 |
4 | pipe 3 (closed) bound = 0xc4 |
5 | pipe 4 (closed) bound = 0xc5 |
6 | pipe 5 (closed) bound = 0xc6 |
Im Log werden die Einträge von C2 nicht angezeigt, weil die Abfrage der Pipe im Interrupt aus irgendeinem Grund nicht funktioniert. Darum stimmt die im Adurino generierte Prüfsumme nicht. Die Telegramme werden aber erfasst, jedoch der Pipe 1 zugeordnet, obwohl sie zu Pipe 0 gehören. Hier ein Beispiel, gehört eigentlich zu Pipe 0, die Abfrage
1 | radio2.available(&pipe) |
liefert aber Pipe 1, darum wird das Telegramm C3 zugeordnet und anschließend wegen falscher Prüfsumme (Die Berechnung legt die Adresse WR2 zugrunde) verworfen. In den Nutzdaten sieht man aber, dass das Telegramm eigentlich für 73104439 bestimmt ist.
1 | C3 019634660 00 1946107301 00DE 1B 3 15 73104439 72819005 800B00623DD84B00000005000000009117A9035D 1565 0 |
(2) Was Du sagst ist absolut richtig, aber wenn dann ist es in der RF24 Dokumentation missverständlich beschrieben. Die AutoAck Funktion ist bei allen "Sniffern" deaktiviert. Darum sollten die nicht für die Ack Frames verantwortlich sein. Die ACK Frames die ich sehe sind auch immer an die Adresse der DTU gerichtet. Meine RF24 sind so eingestellt, dass die TX_ADR auf Default steht:
1 | TX_ADDR = 0xe7e7e7e7e7 |
Das Datenblatt sagt ja, dass für die AutoAck Funktion TX und RX Addr. gleich sein müssen.
1 | TX5 device: TX_ADDR = 0xB3B4B5B605 |
2 | TX5 device: RX_ADDR_P0 = 0xB3B4B5B605 |
3 | RX device: RX_ADDR_P5 = 0xB3B4B5B605 |
Muss man sicherlich noch weiter hinterfragen. (3) Als Ursache für die Adressen die mit 0x00 enden habe ich für mich den yveaux Sniffer ausgemacht. (Gut wenn man einen Schuldigen hat). Dieser stellt im RF 24 immer fest eine Adressbreite von 4 Byte ein (Bzw. Parametrierte Adressbreite - 1).
1 | #define DEFAULT_RF_ADDR_PROMISC_WIDTH (DEFAULT_RF_ADDR_WIDTH-1)
|
Das fehlende 0x01 in der Adresse wird dann schon der Payload zugeordnet. Dies ist der Grund, warum ich in älteren Aufzeichnungen immer ein Bit vor dem 9-bit PCF hatte. (Siehe Anhang) Die 0x02 ist die 0x01 in Byte 5 der Adresse. Martin (Gast) hatte noch eine Anmerkung: > Was mir hier und auch in meinen Daten aufgefallen ist: In den > Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer > mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun > haben, der für die Antwort verwendet werden soll? Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) Turn unit off: C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 Turn unit on: C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 Turn unit off: C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 Turn unit on: C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1
:
Bearbeitet durch User
Angehängte Dateien:
Ich möchte gerne einen kleinen Teilerfolg vermelden. Ich kann meine WR ohne die DTU abfragen und erhalte sporadisch Antworten. Ein Muster erkenne ich noch nicht. Bisher kann ich meinen Aufbau nur mit RF24_PA_LOW betreiben. Aber die Sendeleistung reicht um die 30m entfernten WR zu erreichen. Beim Senden meldet sich bei einer höheren Sendeleistung immer der CH340 Chip USB zum Rechner ab. Zunächst ging sogar nur RF24_PA_MIN, bis ich die 3.3V zum RF Modul mit einem 100uF Elko gestützt habe. Die DTU Radio ID in dem Code kann ich beliebig ändern, die WR antworten dann auf die neue DTU ID. Als Anpassung sollte es reichen, die DTU Radio Ids zu ändern. Bei nur einem WR zunächst irgendeine Dummy Adresse verwenden oder diese belassen.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Die Wechselrichter scheinen irgendeinen proprietären Mechanismus bei dem Channel hopping zu verwenden. Den habe ich noch nicht verstanden. Der Trick ist, auf einer anderen Adresse zu empfangen als zu senden und beim Senden bis die maximale Retransmit rate mit 2ms Pause zu verwenden. Zur Zeit verwende ich die Kanäle 3 und 40. Auf einigen anderen Kanälen geht bei mir gar nichts, vermutlich wegen meinem WLAN. Muss man evtl. in jeder spezifischen Umgebung ausprobieren. Versucht habe ich es mit einer Kombination aus den bereits weiter oben erwähnten Kanälen:
1 | int channels[] = {3, 23, 40, 61, 75}; |
1 | #define DEFAULT_RECV_CHANNEL (3) // 3 = Default channel for Hoymiles
|
2 | #define DEFAULT_SEND_CHANNEL (40) // 40 = Default channel for Hoymiles
|
Kann dies jemand bei sich nachvollziehen? Oder liegt es bei mir daran, dass die WR schon mal mit der DTU kommuniziert haben und dadurch noch irgendeine Konfiguration haben? Bei Fragen oder Problemen einfach melden.
:
Bearbeitet durch User
Hallo Oliver, was genau wird bei dir zur Anforderung an den WR gesendet ? Vielleicht sende ich da was falsches. Bisher bei mir ohne Erfolg. Ich hab 14 retransmits eingschalten, hab auf jeder Megahertz - Frequenz 2400 - 2525 Mhz gesendet. Der WR hat nirgends geantwortet. Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, daß er irgendwo antwortet. Dann könnte ich immer noch mit Aufnahmen feststellen, wo. (Die Messung mit dem AD8318 funktioniert einwandfrei, wenn ich den an meinen NRF dran stelle.) Evtl fehlt dann doch irgendeine Grundinitialisierung an den WR, daß er was tut oder ich sende Schrott.
B. G. schrieb: > > was genau wird bei dir zur Anforderung an den WR gesendet ? > Hallo B.G. Der Quelltext ist dem Beitrag angehängt. Ich sende alle 200ms ein Telegramm an meine beiden Wechselrichter. Sie antworten nicht jedes mal, sondern gefühlt jedes 4-5 Mal. Ich denke das hat mit dem noch nicht durchschauten Channel Hopping zu tun. Es wird nacheinander auf CH40 das 0x80 Telegramm mit einer simulierten Unix Zeit gesendet, da ich auf dem nano keine Echtzeituhr habe. Das scheint dem WR aber egal zu sein. Dann das 0x81, 0x80, 0x83, 0xFF Telegramm, wie von Martin in der Protokollbeschreibung angegeben. Danke an Martin das ist sehr hilfreich. Nach dem Senden wird direkt wieder auf CH3 umgeschaltet und gehorcht.
1 | if (tel > 4) |
2 | tel = 0; |
3 | if (tel == 0) |
4 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
5 | else if (tel == 1) |
6 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x81); |
7 | else if (tel == 2) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x80); |
9 | else if (tel == 3) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
11 | else if (tel == 4) |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0xFF); |
13 | |
14 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
15 | |
16 | toggle = !toggle; |
17 | if (!toggle) |
18 | tel++; |
Ein Dump mit Ausgabe von Send und Receive ist angehängt. Die Zeilen mit diesem Inhalt sind dabei die vom WR empfangenen Daten.
1 | 048491820 00 1234567801 00DC 1B 2 95 73104619 73104619 010001014F027908470150026D08220000FB9CDF 9CDF 1 |
2 | 048540572 00 1234567801 00DE 1B 3 95 73104619 73104619 02FE300000F91307790762096413840FADF0AB62 AB62 1 |
"Send..." ist jeweils ein Send auf CH40. PL die Payload, WR1/2 gibt an an welche Adresse. Die 0 danach ist der Rückgabewert vom Write, da ja kein ACK von den WR kommt. Dann die millis() Zeit des Nano und die Dauer des Sendens in millis().
1 | Send... CH40 PL: 1573104439785634128182 WR2 0 48677140 29204 |
2 | Send... CH40 PL: 15731046197856341281A0 WR1 0 48877844 29204 |
:
Bearbeitet durch User
vielen Dank, wenn es jemand gibt, der Erfolg mit dem zurücklesen hat, ohne eigene DTU zu besitzen, dann bitte melden. bei martin müßte es ja evtl jetzt so funktionieren ?
Hallo @golf2010 und @of22, das ist tolle Arbeit. Muss man erst mal drauf kommen! Hoffentlich komme ich morgen dazu, das mit meinem Raspi-Setup auszuprobieren. Können wir eventuell noch weiter einschränken, welche Nachrichten wirklich notwendig sind? (1) @of22, Du wechselst zwischen den 5 Pakettypen im Kreis herum - hast Du mal probiert, ob weniger eventuell immernoch zum Erfolg führen? (2) Und habe ich das richtig verstanden, du hörst immer auf Kanal 3? D.h. angenommen, Du würdest nach dem Senden auf Kanal 40 bleiben, dann würdest Du nichts empfangen? (3) Und noch ne ganz ketzerische Frage: wenn Du garnichts sendest und nur auf Kanal 3 zuhörst, empfängst Du aber nie irgendwelche Nachrichten, oder doch?
Hallo Martin G. (1) Habe ich versucht nur das 0x80 mit dem Unix Timestamp zu senden, das reicht aus. Aber dann kommt nur der 01 00 01 Response. Mit den anderen zwischendurch kommt auch mal ganz selten eine andere Antwort. Ich hatte schon versucht mir die Saleae Captures von martin (Gast) 20.03.2022 13:37 anzusehen, um hier vielleicht anhand der Serial Captures ableiten zu können welche Requests erforderlich sind. Könnte man die vielleicht als ASCII Dump oder so zur Verfügung stellen? Ich habe kein Saleae und so wie ich es veerstehe gibt es keine Stand Alone Version der Software. (2) Das ist richtig, so ist meine Beobachtung. Gesendet und Empfangen wird immer auf einem unterschliedlichen Kanal. Bleibe ich auf dem Sendekanal, egal ob 40 oder 3, empfange ich keinen Response. (3) Nein, wenn ich aufhöre zu senden kommen keine Responses vom WR mehr. Er muss immer durch irgendein Telegramm getriggert werden.
:
Bearbeitet durch User
Hallo @of22, habe mir die Hardware mit dem Nano aufgebaut. Kommunikation mit dem NRF24 scheint zu tun. Also Register usw. werden ausgelesen. Nur kurz 2 Fragen bevor ich hier tiefer in den Code einsteige. 1. Muss die Seriennummer des WR auch Rückwärts angegeben werden? 2. Wie funktioniert das Menü? Wird gleich nach dem Startup schon gesendet oder muss man das Senden zuerst über die Serielle Konsole starten? Danke & Grüße Thomas
Angehängte Dateien:
-
ali-001.jpg
21 KB -
ali-005.jpg
18 KB
Hallo Thomas. Die Seriennummer muss in dem define umgekehrt angegeben werden. An meinem Beispiel: WR1 = xxxx73104619 WR2 = xxxx73104439 Und im Byte 5 der Adresse die 01 nicht vergessen. Die Adresse der DTU ist egal, da Du sie ja simulierts.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Das Menü ist erst einmal uninteressant. Der Code fängt direkt an zu senden. Es waren nur Tests um die Kommunikation auf einzelne Telegramme einzuschränken. Eine Anmerkung noch: Eventuell muss der Sendelevel angepasst werden. Ich habe die Module ali-005 mit externer Antenne im Einsatz. Damit komme ich nicht über PA_LOW sonst hängt sich etwas auf (CH340), oder ich bekomme keine Antworten. Vorhin habe ich es noch die ali-001 ausporbiert. Damit muss ich höher gehen auf PA_HIGH sonst bekomme ich keine Antwort von den ca. 30 m entfernten Wechselrichtern durch zwei Wände. Aber auch mit denen kann ich nicht auf PA_MAX gehen sonst kommt wiederum keine Antwort.
1 | radio1.setPALevel(RF24_PA_HIGH); |
Und dran denken, jetzt ist dunkel. Da kommt nichts mehr, weil der WR aus dem DC Kreis versorgt wird.
:
Bearbeitet durch User
Hallo Oliver, alles klar danke! Habe hier auch den ali-005. Habe aber schon einen 10uF angelötet. Werde es erstmal mit LOW versuchen und mich notfalls mit dem Laptop raus stellen. Ich bin ja sooo gespannt. Jetzt wenn schon Sonne vorhanden wäre :) Grüße Thomas
Angehängte Dateien:
B. G. schrieb: > Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen > und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, > daß er irgendwo antwortet. Ich hab tagelang völlig unnötig rumprobiert. Da war bei mir nur ein Zahlendreher in meiner eingegebenen WR-Seriennummer. Nachdem ich den heute Nacht gesehen hab, hat der WR heute morgen sofort geantwortet auf ein 80 Paket. Also brauchst doch keine extra Initialisierung. Anbei der Ausgang von meinem Pegelmesser AD8318, am Oszi angeschlossen. Ich muß jetzt schauen, wo er antwortet.
Angehängte Dateien:
B. G. schrieb: > Ich muß jetzt schauen, wo er antwortet. auf 2403 kam der gerade. auf der 2405 gibts hier noch einen weiteren NRF, wohl ein Nachbar. Der auf 2405 kommt etwas stärker rein.
:
Bearbeitet durch User
Hallo B.G. dein Testprogramm funzt einwandfrei. Es werden zwar nicht alle Anfragen beantwortet, aber so alle 1 - 2 Sekunden kriegt man Daten. Und das ist doch schon was.
Hallo Hubi, das Programm ist von Oliver. Ich kann kein C, nur Pascal(Avrco) und Delphi.
Hallo, kann es auch bestätigen. Daten werden empfangen. Ich kann auch bestätigen das es mit > RF24_PA_HIGH nicht funktioniert. Zumindest wenn ich den NRF24 via USB betreibe. Am Labornetzteil tut es.
Angehängte Dateien:
Hallo, das freut mich zu hören, dass es auch bei anderen klappt. Das man nicht jedes Mal eine Antwort erhält, liegt an dem noch nicht durchschauten Channel Hopping. Ich habe mal noch ein paar Sachen zum Nachdenken, wer möchte, kann sich gerne beteiligen. Ich habe meiner DTU und einem WR nochmal bei der Kommunikation mit diesem Aufbau zugehört: Zwei RF24 Chips. Einer lauscht auf Kanal x und der andere auf x + 40, jeweils für 60 s. Dann wird x inkrementiert von 0 bis 39. Dabei heraus gekommen ist diese Statistik. Das ist sicherlich eine Momentaufnahme, die sich aus meinem WLAN Umfeld und aus anderen Störern ergibt. Auch sind bei den Frames WR=>DTU die Antworten von dem zweiten Wechselrichter, dessen DTU Anfragen nicht geloggt werden, das könnte das Bild verfälschen. Kommunikation läuft auf mehr als den bisher angenommenen Kanälen, wobei es bei den Kanälen 7, 8, 9 auch ein Übersprechen sein könnte. WR an DTU sind am häufigsten auf Kanal 3 und 23 vertreten. DTU an WR springt lustig durch die anderen Kanäle, wobei 0, 7, 9, 23, 27, 35, und 40 die Spitzenreiter sind. Als Kommandos DTU=>WR sieht man die Ids 0x80, 0x81, 0x82, 0xFF.
1 | Kanal | Frames | DTU=>WR | WR=>DTU | 0x80 | 0x81 | 0x82 | 0xFF |
2 | ------+--------+---------+---------+------+------+------+------ |
3 | 0 | 11 | 11 | 0 | 5 | 0 | 0 | 6 |
4 | 3 | 81 | 8 | 73 | 5 | 4 | 1 | 2 |
5 | 7 | 10 | 10 | 0 | 8 | 0 | 0 | 2 |
6 | 8 | 3 | 3 | 0 | 2 | 0 | 1 | 0 |
7 | 9 | 12 | 12 | 0 | 9 | 0 | 3 | 0 |
8 | 11 | 9 | 9 | 0 | 8 | 0 | 1 | 0 |
9 | 14 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
10 | 20 | 3 | 3 | 0 | 2 | 0 | 0 | 1 |
11 | 23 | 59 | 12 | 47 | 7 | 1 | 4 | 1 |
12 | 27 | 13 | 13 | 0 | 9 | 1 | 1 | 2 |
13 | 29 | 8 | 8 | 0 | 4 | 0 | 3 | 1 |
14 | 35 | 11 | 11 | 0 | 5 | 2 | 1 | 3 |
15 | 37 | 8 | 8 | 0 | 6 | 0 | 2 | 0 |
16 | 39 | 8 | 8 | 0 | 5 | 0 | 2 | 1 |
17 | 40 | 10 | 10 | 0 | 6 | 0 | 1 | 3 |
18 | 61 | 13 | 9 | 4 | 6 | 0 | 2 | 1 |
19 | 75 | 8 | 3 | 5 | 2 | 1 | 0 | 0 |
Woher weiß die DTU, auf welchem Kanal der WR lauscht? Und woher weiß sie, auf welchem Kanal die Antwort vom WR kommt? So aus einem Bauchgefühl heraus: Könnte das 0xFF Telegramm die Aufforderung zum Kanalwechsel sein, aber wohin? Bei dem 0x80 Telegramm sehe ich im Byte hinter der 0x80 die Bytes 0x0B oder 0x11 (Siehe Screenshot). Die Bedeutung erschließt sich mir noch nicht. Beigefügt der Dump aus dem Minuten Scan als Rohdump und aufbereitete Excel.
:
Bearbeitet durch User
Hallo, es geht voran, aber nicht so direkt Beteilige verlieren den Überblick. So auch ich. Kann bitte jemand einmal kurz und knackig die benötigte Hardware skizzieren und die Software mit Sourcecode bereitstellen? Dann kann jeder Homiles Nutzer sich schnell zurechtfinden. Danke
@of22: Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen Uhrzeit stehen?
Bezugnehmend auf Sorbit (Gast) würde ich gerne https://github.com/grindylow/ahoy als Sammelstelle vorschlagen. Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf das Repository geben. @Sorbit, ich glaube, so hundertprozentig "einstecken und tut"-Lösungen haben wir noch nicht - jeder hat leicht andere Hard- und Software, aber gerade deshalb geht es erstaunlich voran! Aber Du hast natürlich Recht, ich denke wir haben alle ein Interesse daran, dass das ganze früher oder später einfach(er) nachzuvollziehen und zu nutzen wird.
Angehängte Dateien:
Martin G. schrieb: > @of22: > Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen > Uhrzeit stehen? Hallo Martin, gute Idee, das ist ja fast das Einzige was sich in den Telegrammen ändert. Beziehe ich in meine Grübeleien ein. > Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf > das Repository geben. Bisher ist das Ganze ja nur ein zusammengeklopptes Testprogramm. z.B. könnte man die CRC Generierung auf eine Bibliothek umstellen. https://github.com/RobTillaart/CRC oder so. Auch wird im Testprogramm Kanal 40 zum Senden und 3 zum Empfangen verwendet. Die Statistik oben zeigt ja, dass man auch auf 23 lauschen müsste und auf anderen senden. Aber Du kannst gerne den jetzigen Stand hochladen. @ Sorbit (Gast): Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in China bestellt hatte. Ich mag die Atmel Dinger aber ansonsten nicht. Dazu ein RF24 Modul ali-005 (Siehe weiter oben). Die Schaltung habe ich skizziert. Ich betreibe den nano mit den 5V vom Laptop USB. Problem ist hierbei noch die 3V3 Versorgung des RF24. Wie Thomas B. (tbnobody) herausgefunden hat verwendet man besser noch ein externes Netzteil. Die Leistung des Linearreglers im CH340 des nanos reicht nicht aus um die Versorgung bei höheren Sendeleistungen sicher zu stellen.
Hallo zusammen, im Source von Oliver sollten ja die verschiedenen Packages nacheinander durchprobiert werden. Daher hätte ich erwartet, dass die Antworten mit gleicher Häufigkeit vorkommen. Aber siehe capture.txt im Anhang sehe ich hauptsächlich 1er und 2er... die 3er Messages kommen kaum vor. Könnt ihr das Nachvollziehen, ist das bei euch ähnlich? Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, ggf. auch der Strom, aber spätestens bei der Leistung stimmt es zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe hier einen HM-1500) Ggf. sind die Telegramme je nach Typ unterschiedlich aufgebaut. Dann müsste man aber seinen Typ entweder in der Hoymiles Cloud einstellen können oder dieser wird irgendwo noch mitgeschickt.
Oliver F. schrieb: > Aber Du kannst gerne den jetzigen Stand hochladen. Gesagt - getan: https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv
Oliver F. schrieb: > @ Sorbit (Gast): > Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in > China bestellt hatte. Davon hab ich genug rumfliegen. Welcher Code läuft da drauf? RF Modul hab ich auch mal im 20 er Pack gekauft. Alles da, auch ein produktiver HM-1200... Danke
Hallo @of22, ich bin noch über Deine Zeile https://github.com/grindylow/ahoy/blob/82ce2c9d8864dcc465af804ab0130dd7a7322a6b/tools/nano/NRF24_SendRcv/src/hm_packets.cpp#L49 gestolpert:
1 | buf[19] = 0x05; |
Warum? Und was passiert, wenn das nicht gemacht wird (also an dieser Stelle ein 0-Byte verbleibt)? Ist das der von Dir beobachtete Zähler, der sich mit jedem Schaltbefehl erhöht?
Hallo, ich möchte mir schonmal die Hardware bestellen. Wir reden über sowas, richtig? https://www.ebay.de/itm/255283312809 (Einen Nano habe ich) Danke sehr!
Hallo @petersilie. Ja, dass ist richtig. Es ist wie weiter oben beschrieben. Ich habe gesehen, dass der Zähler mit jeder Schaltaktion inkrementiert wird. Es ist wahrscheinlich ein 16-bit Wert. Durch die ganze Probiererei scheint der Zähler aus der Cloud mittlerweile bei 0x0537 zu stehen?!? Es passiert erst einmal nichts offensichtliches, wenn man das weg lässt. Keine Ahnung was das ist.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
@Mag C. (magcode): Ja das Modul verwende ich auch. Wichtig ist, dass es ein NRF24L01*+* (Plus) ist.
:
Bearbeitet durch User
Thomas B. schrieb: > Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu > dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich > daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, > ggf. auch der Strom, aber spätestens bei der Leistung stimmt es > zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe > hier einen HM-1500) Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe geschaltet? Wenn wir die Verläufe über ein paar Stunden betrachten, idealerweise mit gleichzeitiger Beobachtung der Ausleuchtung der 4 Solarpanels, dann kommen wir bestimmt hinter die genaue Bedeutung der einzelnen Felder. Der WR-Typ wird ja vielleicht in einem der bisher als "unbekannt" gekennzeichneten Bytes/Bits übertragen. Oder vielleicht ist er in der Seriennummer kodiert? Oder die DTU fragt das bei der Einrichtung einmalig ab?
Angehängte Dateien:
martin schrieb: > Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden Hallo zusammen, leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, wie es hier voran geht. Danke an alle Beteiligte. Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher schon mal aufgenommen hatte: Könnte es vielleicht sein, dass der Inverter generell auf einem anderen aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die Interferenzen sind. Nur so eine Idee - auch wenn das von den im FCC Report genannten Frequenzen abweichen würde. Falls das den Hersteller überhaupt interessiert... (grübel)
Angehängte Dateien:
martin schrieb: > martin schrieb: >> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden > > Hallo zusammen, > leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, > wie es hier voran geht. Danke an alle Beteiligte. > > Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher > schon mal aufgenommen hatte: > Könnte es vielleicht sein, dass der Inverter generell auf einem anderen > aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner > Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. > Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das > wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben > erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die > Interferenzen sind. > > Nur so eine Idee - auch wenn das von den im FCC Report genannten > Frequenzen abweichen würde. Falls das den Hersteller überhaupt > interessiert... (grübel) Das ist momentan bei mir nicht der Fall. Die WR senden auf den festen Channel-Frequenzen, wie es aussieht. Keine Ahnung, was damals alles aktiv war bei Deinen Aufnahmen. Das war auch komisch mit den instabilen Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Der WR scannt die Kanäle durch bis er was empfangen hat und, wie es aussieht, sendet er dann immer 3 Antwort Telegramme, oft auf unterschiedlichen Frequenzen. (Telegramme nicht näher untersucht) Die Kanalwahl hat erst mal nichts zu tun mit der übermittelten Zeit. Das Sonagramm der Aufnahme ist etwas schwach, hatte nur ein Stück Draht als Antenne.
:
Bearbeitet durch User
B. G. schrieb: > Das war auch komisch mit den instabilen > Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Ok, danke für die Rückmeldung. Ich werde das bei Gelegenheit nochmal nachmessen.
> Der WR scannt die Kanäle durch bis er was empfangen hat.
Deshalb wird vmtl immer mit 15 Retransmits gesendet.
Auch der DTU scannt vmtl einfach die Kanäle durch, die Telegramme werden
ja genügend oft wiederholt.
Hallo, ich versuche gerade mal durch den Code zu gehen und diesen zu verstehen. Dabei ist mir aufgefallen, das der Wert 0x05 an Stelle 19 gesetzt wird:
1 | buf[19] = 0x05; |
dennoch ist er bei deiner Ausgabe aber immer an Stelle 18:
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben werden ? Vielen Dank
Marcel schrieb: > Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben > werden ? Hallo Marcel. Nein Du hast nichts übersehen. Das rudimentäre Testprogramm zur Simulation der DTU schreibt an dieser Stelle immer eine 0x05. So ist es momentan noch, weil wir die Bedeutung dieses Wertes noch nicht kennen. Siehe Nachricht vom 27.03.2022 19:34 an Petersillie. Das Beispiel was Du anführst ist aus einem aktuellen Scan der Kommunikation zwischen DTU und WR. Hier steht dieser "Zähler" jetzt schon auf 0x0537.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Siehe auch Nachricht vom 25.03.2022 15:35: Dieser Zähler inkrementiert sich, wenn man aus der Hoymiles Cloud heraus eine Schaltaktion durchführt.
1 | Turn unit off: |
2 | C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 |
3 | 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 |
4 | Turn unit on: |
5 | C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 |
6 | 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 |
7 | Turn unit off: |
8 | C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 |
9 | 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 |
10 | Turn unit on: |
11 | C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 |
12 | 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1 |
Vielen Dank, ist aber auch ein witziger Zufall, das genau 05 um eine Stelle nach vorne gerückt ist. Somit hat der Counter da 16 bit, ergo 4 Stellen. Danke
Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine erste Testimplementierung in Python für RaspberryPi. Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf Kanal 40, ansonsten immer auf Kanal 3 zuhören. Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit einer DTU in Kontakt war. Ergebnis: siehe Anhang. (Programm siehe https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)
:
Bearbeitet durch User
Hallo zusammen mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren. Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB Leistung der letzten Tage, Wochen, Insgesamt?
Martin G. schrieb: > Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine > erste > Testimplementierung in Python für RaspberryPi. > > Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf > Kanal 40, ansonsten immer auf Kanal 3 zuhören. > > Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit > einer DTU in Kontakt war. > > Ergebnis: siehe Anhang. > > (Programm siehe > https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py) Hardware Setup, Software? Viele unterstützen und sollten es auch nachbauen Können. Danke