Forum: Mikrocontroller und Digitale Elektronik Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von sorbit (Gast)


Lesenswert?

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

von EAF (Gast)


Lesenswert?

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

von PhilippK_59 (Gast)


Lesenswert?

Wenn die sich das einfach gemacht haben ist das ein properietäres Uart 
Signal.

von Christian Strickmann (Gast)


Lesenswert?

Häng mich mal ran .... interessiert mich auch

von Sorbit (Gast)


Lesenswert?

Scheint leider niemand zu wissen…
Schade, die WR sind eigentlich sehr verbreitet.
Das Ding sendet ungenutzt dauernd wertvolle Daten in den Äther..

von Martin M. (Firma: mcmaier.net) (mcmaier)


Lesenswert?

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...

von Sorbit (Gast)


Lesenswert?

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

von Paul (Gast)


Lesenswert?

Den Stick gibt es, aber sauteuer.
https://www.ebay.de/itm/164230252118

von sorbit (Gast)


Lesenswert?


von Eule (Gast)


Lesenswert?

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
}

von noreply@noreply.com (Gast)


Lesenswert?

Ich würde mal "bluetooth-clients" in der Umgebung suchen. Vielleicht hat 
man Glück. ;-)

Was steht auf den Nordic-Chip?

von noreply@noreply.com (Gast)


Lesenswert?

Es wird ein LC12S laut yt-Video verwendet.

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

von Chris A. (cherio7)


Lesenswert?

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 ;

von Hubi (Gast)


Lesenswert?

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?

von Eule (Gast)


Lesenswert?

>
> 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

von Eule (Gast)


Lesenswert?

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

von Hubi (Gast)


Lesenswert?

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();
}

von Hubi (Gast)


Lesenswert?

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.

von Eule (Gast)


Lesenswert?

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

von Eule (Gast)


Lesenswert?

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

von Herbert K. (avr-herbi)


Lesenswert?

TOP Informationen EULE !  Grossartig !

von Martin (Gast)


Lesenswert?

Usr-c210 ist ein uart total WiFi modul von pusr

von hubi (Gast)


Lesenswert?

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.

von Carsten B. (carstenb)


Lesenswert?

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

von Carsten B. (carstenb)


Lesenswert?

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?

von Einhart P. (einhart)


Lesenswert?

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.

von Carsten B. (carstenb)


Lesenswert?

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.

von hubi (Gast)


Lesenswert?

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.

von noreply@noreply.com (Gast)


Lesenswert?

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. ;-)

von Heinz R. (heijz)


Lesenswert?

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

von roman1528 (Gast)


Angehängte Dateien:

Lesenswert?

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^^

von roman1528 (Gast)


Lesenswert?

ich korrigiere...

Kanal 3, 40 und 75

von Einhart P. (einhart)


Lesenswert?

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.

von 31 (Gast)


Lesenswert?

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.

von Carsten B. (carstenb)


Lesenswert?

Sorry, sehe grade. dass ich als Gast geschrieben habe. Ich wars...

von hubi (Gast)


Lesenswert?

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.

von martin (Gast)


Lesenswert?

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.

von Einhart P. (einhart)


Lesenswert?

Klasse! Ich bin auf Ergebnisse gespannt.

von Chris K. (kathe)


Lesenswert?


von hubi (Gast)


Lesenswert?

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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Carsten B. (carstenb)


Lesenswert?

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

von Super (Gast)


Lesenswert?

Super Martin,

wenn etwas brauchbares herauskommt, beteilige ich mich an den Aufwand 
gern mit einer Spende!

Danke an ALLE

von Fritzdect (Gast)


Lesenswert?

Ich hab hier ein Projekt gefunden:
https://github.com/Eule01x/NETSGPClient-for-Hoymiles

von Fritzdect (Gast)


Lesenswert?

Fritzdect schrieb:
> Ich hab hier ein Projekt gefunden:
> https://github.com/Eule01x/NETSGPClient-for-Hoymiles

Sorry, ist oben bereits erwähnt

von Fritzdect (Gast)


Lesenswert?

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

von Hubi (Gast)


Lesenswert?

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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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

von Einhart P. (einhart)


Lesenswert?

Danke Martin,
mit dem Ansatz hast du eine gute Grundlage geschaffen.

von Hubi (Gast)


Lesenswert?

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.

von martin (Gast)



Lesenswert?

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?

von Super (Gast)


Lesenswert?

Ich lobe mal einen Preis von 50€ aus für einen funktionierenden Clone.

Das Biest auf meinem Dach soll mir sagen was los ist;-)

von Wolfgang (Gast)


Lesenswert?

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.

von Fritzdect (Gast)


Lesenswert?

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

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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...

von Hubi (Gast)


Lesenswert?

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.

von Hubi (Gast)


Lesenswert?

mein Punkt 2 ist falsch: ich schreibe die Adresse des WR natürlich in 
umgekehrter Reihenfolge, also (01,FE,56,BE)

von martin (Gast)


Lesenswert?

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ß...

von Hubi (Gast)


Lesenswert?

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, 
???

von martin (Gast)


Lesenswert?

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ß.

von Martin G. (petersilie)


Lesenswert?

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
von martin (Gast)


Lesenswert?

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).

von Martin G. (petersilie)


Lesenswert?

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!

von Hubi (Gast)


Lesenswert?

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!

von Martin G. (petersilie)


Lesenswert?

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.

von Martin K. (Gast)


Lesenswert?

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

von Hubi (Gast)


Lesenswert?

Überlagerung der Wifi-Kanäle?

von Martin K. (Gast)


Lesenswert?

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

von Marcel (Gast)


Lesenswert?

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

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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).

von Carsten B. (carstenb)


Lesenswert?

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

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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 ;-)

von martin (Gast)


Lesenswert?

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.

von Pascal A. (pasarn)


Angehängte Dateien:

Lesenswert?

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

von Pascal A. (pasarn)


Angehängte Dateien:

Lesenswert?

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

von Pascal A. (pasarn)


Angehängte Dateien:

Lesenswert?

Noch mehr Bytes.

von martin (Gast)


Lesenswert?

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].

von Pascal A. (pasarn)


Lesenswert?

Hi Martin,
mit der 0x02 passt nicht immer. In deiner Excel Datei Spalte AW ist eine 
Antwort, wo es nicht passt.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Pascal A. (pasarn)


Lesenswert?

Hi Martin,

hast du noch mehr Daten zu deinem Wechselrichter?
Vielleicht sind es Daten zu Einstellungen, Firmware, ...

von martin (Gast)


Lesenswert?

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...

von Einhart P. (einhart)


Lesenswert?

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.

von Frank H. (fh_)


Lesenswert?

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

von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

Super!

Ich habe mal versucht, die bisherigen Erkenntnisse in der angehängten 
Textdatei zusammenzufassen. Vielleicht gewährt das ja noch neue 
Einblicke. Gerne erweitern!

von Hubi (Gast)


Lesenswert?

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.

von Thomas B. (tbnobody)


Lesenswert?

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
von Hubi (Gast)


Angehängte Dateien:

Lesenswert?

Anbei mein Testprogramm. Wer will kann es gerne weiterbenutzen und 
anpassen. Vllt hat ja jmd mehr Erfolg als ich.

von Thomas B. (tbnobody)


Lesenswert?

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?

von Hubi (Gast)


Lesenswert?

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.

von Martin G. (petersilie)


Lesenswert?

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

von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

Übersicht erweitert:
Nachrichten "02 28 23" und "82 00 03" ergänzt. Sauberer ausgerichtet. 
Python Beispiel für CRC.

von Thomas B. (tbnobody)


Lesenswert?

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

von Martin G. (petersilie)


Lesenswert?

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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Hubi (Gast)


Lesenswert?

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!?

von martin (Gast)


Lesenswert?

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.

von Hubi (Gast)


Angehängte Dateien:

Lesenswert?

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)

von Arnaldo G. (arnaldo_g)


Angehängte Dateien:

Lesenswert?

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!

von Martin G. (petersilie)


Lesenswert?

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

von Marcel (Gast)


Lesenswert?

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

von Martin G. (petersilie)


Lesenswert?

@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

von Martin G. (petersilie)


Lesenswert?

Marcel schrieb:
> I can see that your dump was mainly during the night.

Excellent point!

von Martin G. (petersilie)


Lesenswert?

@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)

von Hubi (Gast)


Lesenswert?

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?

von Martin G. (petersilie)


Lesenswert?

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

von Arnaldo G. (arnaldo_g)


Angehängte Dateien:

Lesenswert?

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

von Martin G. (petersilie)


Lesenswert?

@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.

von Thomas B. (tbnobody)


Lesenswert?

@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

von Martin G. (petersilie)


Lesenswert?

@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)

von Arnaldo G. (arnaldo_g)


Angehängte Dateien:

Lesenswert?

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.

von Martin G. (petersilie)


Lesenswert?

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!

von Thomas B. (tbnobody)


Lesenswert?

@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

von Arnaldo G. (arnaldo_g)


Angehängte Dateien:

Lesenswert?

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!

von Marcel (Gast)


Lesenswert?

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

von Arnaldo G. (arnaldo_g)


Lesenswert?

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

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

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
von Marcel (Gast)


Lesenswert?

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

von Arnaldo G. (arnaldo_g)


Angehängte Dateien:

Lesenswert?

Yes, sure I will run!

Attached is a scanner in all channells with a DWELL of 10s.

von Arnaldo G. (arnaldo_g)


Lesenswert?

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....

von Martin G. (petersilie)


Lesenswert?

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.)

von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

Aktualisierte Nachrichtenliste

von Arnaldo G. (arnaldo_g)


Lesenswert?

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

von Hubi (Gast)


Lesenswert?

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?

von Herbert K. (avr-herbi)


Angehängte Dateien:

Lesenswert?

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.

von Hubi (Gast)


Lesenswert?

Meins sieht aus wie ali-001

von Thomas B. (tbnobody)


Lesenswert?

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.

von Frank H. (fh_)


Lesenswert?

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

von Arnaldo G. (arnaldo_g)


Lesenswert?

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....

von Arnaldo G. (arnaldo_g)


Angehängte Dateien:

Lesenswert?

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.....

von Martin G. (petersilie)


Lesenswert?

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?

von Arnaldo G. (arnaldo_g)


Lesenswert?

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....

von Martin G. (petersilie)


Lesenswert?

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.

von martin (Gast)


Lesenswert?

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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Lars B. (docbmuc)


Lesenswert?

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... ;-)

von Martin G. (petersilie)


Lesenswert?

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.

von Martin G. (petersilie)



Lesenswert?

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.

von Heinz R. (heijz)


Lesenswert?

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...

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

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
von Thomas B. (tbnobody)


Lesenswert?

@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?"

von Hubi (Gast)


Lesenswert?

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.

von Matthias B. (matthias882)


Lesenswert?

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

von Thomas B. (tbnobody)


Lesenswert?

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
von Hubi (Gast)


Lesenswert?

Sorry Thomas, mit 0x8005 passt es doch

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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 ;-)

von Hubi (Gast)


Lesenswert?

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.

von Marcel (Gast)


Lesenswert?

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

von Martin G. (petersilie)


Lesenswert?

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.

von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

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
von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

r5

von Thomas B. (tbnobody)


Lesenswert?

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
von Herbert K. (avr-herbi)


Lesenswert?

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
von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

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 :-(

von Hubi (Gast)


Lesenswert?

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.

von Marcel (Gast)


Lesenswert?

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

von Thomas B. (tbnobody)


Lesenswert?

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.

von Hubi (Gast)


Lesenswert?

Bin zwar nicht angesprochen, aber DynamicPayload und Payload 27 (siehe 
Erkenntnisse irgendwo oben) probiere ich ständig abwechsenld aus.

von Thomas B. (tbnobody)


Lesenswert?

@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?

von martin (Gast)


Lesenswert?

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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von golf (Gast)


Lesenswert?

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 ?

von Herbert K. (avr-herbi)


Lesenswert?

NRF24L01 = 1 MHz u 2 MHz
NRF24L01+ = 256 K u. 1 u 2 MHz
(ohne Gewähr)

von golf (Gast)


Lesenswert?

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.

von Lukas M. (miltechniks)


Lesenswert?

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

von Marcel (Gast)


Lesenswert?

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

von Daniel E. (Gast)


Lesenswert?

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

von Martin G. (petersilie)


Lesenswert?

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?

von Martin G. (petersilie)


Lesenswert?

@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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von emhopa (Gast)


Lesenswert?

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.

von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

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
von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

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?

von Martin G. (petersilie)


Lesenswert?

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
von martin (Gast)



Lesenswert?

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.

von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

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.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von B. G. (golf2010)


Lesenswert?

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.

von Thomas B. (tbnobody)


Lesenswert?

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.

von Der Kommissar (Gast)


Lesenswert?

Liest sich wie ein Krimi.
Ich drücke Euch die Daumen.
Tolle Teamarbeit.

von Mag C. (magcode)


Lesenswert?

Finde ich auch! Ich drücke die Daumen.
Mein DTU-loser Hoy HM-400 würde sich sehr gerne mit einem billigen 
Nachbau einlassen!

von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

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
von martin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von B. G. (golf2010)


Lesenswert?

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
von martin (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Thomas B. (tbnobody)


Lesenswert?

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?

von martin (Gast)


Lesenswert?

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.

von B. G. (golf2010)



Lesenswert?

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 ?

von martin (Gast)


Lesenswert?

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...

von B. G. (golf2010)


Lesenswert?

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
von Daniel E. (Gast)


Angehängte Dateien:

Lesenswert?

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?).

von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

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
von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

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
von Martin G. (petersilie)


Lesenswert?

@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.

von martin (Gast)


Lesenswert?

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?

von martin (Gast)


Angehängte Dateien:

Lesenswert?

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).

von B. G. (golf2010)



Lesenswert?

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
von B. G. (golf2010)



Lesenswert?

die unterchiedlichen Pegel der einzelnen NRFs verwundern etwas.

von Daniel E. (Gast)


Angehängte Dateien:

Lesenswert?

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?

von B. G. (golf2010)



Lesenswert?

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
von Herbert K. (avr-herbi)


Angehängte Dateien:

Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.