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


Lesenswert?

Herbert K. schrieb:
> Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation
> zwischen dem GD... und dem nRF ?

Das wird schon so gemacht, siehe weiter oben. Aber der verwendete NRF 
ist nicht nur ein Transmitter, sondern auch ein Mikrocontroller. Die 
Kommunikation zwischen GD und NRF lässt deswegen nicht direkt auf das 
HF-Geschehen schließen.

Was aber noch nicht versucht wurde: versuchen, ob der Flash vom NRF 
auslesbar ist. Siehe meinen Vorschlag:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

von B. G. (golf2010)


Lesenswert?

Herbert K. schrieb:
> Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA
> loslaufen lassen.

Ich schlage vor, kurz vor der Stromversorgung des DTUs jeweils 
HF-Aufnahmen zu starten.
Evtl auch mit etwas weniger Samplerate, damit es weniger Aussetzer gibt.
Nach ein paar Aufnahmeversuchen müßte man zumindest die 
Start-Sequenz(en) des DTU finden können. Vielleicht kommt man dann etwas 
weiter.
Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?

: Bearbeitet durch User
von Daniel E. (Gast)


Lesenswert?

Gute Idee! Und am besten auch mal ohne die Sniffer-NRFs, nicht dass wir 
uns mit deren ACKs oder dergleichen verrennen.

von martin (Gast)


Lesenswert?

B. G. schrieb:
> Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?

Hallo golf,
ja, tatsächlich sind die so entstanden, zumindest was die DTU betrifft 
und die Kanäle 3 und 23. Man sieht das auch gut an den seriellen 
Aufnahmen. Die UART-Pegel sind zunächst auf Low, gehen dann auf High und 
dann kommt die Initialisierung des NRF24LE1E (3x Request/Response).
Danach beginnt das Suchen nach Invertern.
Kanal 40 habe ich dann im laufenden Betrieb aufgenommen, nachdem ich 
gemerkt hatte, dass da mehr los war.

Bei allen Versuchen war der Inverter vorher schon an, da er immer eine 
Weile braucht bis er initialisiert ist.

von Oliver F. (of22)



Lesenswert?

Hallo zusammen.

Eine Frage an alle die hier fleißig die HF Daten analysieren.
Ich habe, wie bereits gesagt, auch einen NRF24 Sniffer am Laufen.
Leider kann dieser nur auf die eingestellten Adressen lauschen.
Der Chip unterstützt mehrere Datapipes. (Siehe Anhang)
Ich denke, die WR werden eine Datapipe betreiben, mit deren Seriennummer 
als Adresse. Es muss aber noch eine andere Pipe geben mit einer Art 
Broadcast Adresse, die für alle WR gleich ist?!? Ich komme darauf, weil 
ich mehrmals den Hochlauf der DTU gesnifft habe. Sinnvolle Kommunikation 
sehe ich nur auf den Kanälen 3, 23 und 40, wobei die DTU auf Kanal 40 
sehr selten vertreten ist.

In diesem Beispiel ist es so, dass die Wechselrichter (C1) auf einmal 
anfangen zu senden, ohne dass zuvor ein Telegramm von der DTU an die 
Wechselrichter (C3) zu sehen ist. Ich habe das ganze relativ häufig auf 
den einschlägigen Kanälen probiert. In der Regel sind die ersten 
Telegramme immer WR=>DTU, ohne dass ich eine initiale Aktion der DTU 
sehe.
Die Bedeutung der einzelnen Spalten habe ich versucht im Anhang zu 
dokumentieren.
1
C1 026566496 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1              
2
C1 026570128 00 0590817201 0006 00 3  EA5A EA5A                                                                         
3
C1 026573400 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1              
4
C1 026595440 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
5
C1 026597740 00 0590817201 0002 00 1  AADE AADE                                                                         
6
C1 026613740 00 0590817201 00B8 17 0  95 73104439 73104439 83000000F303E80185000581B4BA142F 142F 1                      
7
C1 027707212 00 0590817201 00DC 1B 2  95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1              
8
C1 027713144 00 0590817201 0006 00 3  EA5A EA5A                                                                         
9
C1 027716424 00 0590817201 00DC 1B 2  95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1              
10
C1 027740752 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
11
C1 027756120 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1              
12
C1 027764348 00 0590817201 0002 00 1  AADE AADE                                                                         
13
C1 027767624 00 0590817201 00DE 1B 3  95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1              
14
C1 029551548 00 0590817201 00D8 1B 0  95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1              
15
C1 029557480 00 0590817201 0006 00 3  EA5A EA5A                                                                         
16
C1 029560760 00 0590817201 00D8 1B 0  95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1              
17
C1 029585088 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
18
C1 029601636 00 0590817201 00DA 1B 1  95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1              
19
C1 029609864 00 0590817201 0002 00 1  AADE AADE                                                                         
20
C1 029613140 00 0590817201 00DA 1B 1  95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1              
21
C1 029635176 00 0590817201 0004 00 2  CA18 CA18                                                                         
22
C1 029637480 00 0590817201 0006 00 3  EA5A EA5A                                                                         
23
C1 034225220 00 0590817201 00D8 1B 0  95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1              
24
C1 034235752 00 0590817201 0006 00 3  EA5A EA5A                                                                         
25
C1 034239032 00 0590817201 00D8 1B 0  95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1              
26
C1 034261072 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
27
C1 035451152 00 0590817201 00DA 1B 1  95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1              
28
C1 035457080 00 0590817201 0006 00 3  EA5A EA5A                                                                         
29
C1 035460360 00 0590817201 00DA 1B 1  95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1              
30
C1 035482388 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
31
C1 035484696 00 0590817201 0002 00 1  AADE AADE                                                                         
32
C1 035500772 00 0590817201 00BC 17 2  95 73104619 73104619 83000500F603E8018300213960F485BA 85BA 1                      
33
C1 035995516 00 0590817201 00D8 1B 0  95 73104439 73104439 010001014803A70BF5014803AC0C0600006AEB1C EB1C 1              
34
C1 036029056 00 0590817201 0004 00 2  CA18 CA18                                                                         
35
C1 036044500 00 0590817201 00DA 1B 1  95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1              
36
C1 036055028 00 0590817201 0006 00 3  EA5A EA5A                                                                         
37
C1 036058312 00 0590817201 00DA 1B 1  95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1              
38
C1 036080352 00 0590817201 0000 00 0  8A9C 8A9C                                                                         
39
C3 037978808 00 1946107301 00DE 1B 3  15 73104619 72819005 801200623DA4AB000000000000000098C8DD09E3 09E3 1

Ist Euch bei der Analyse der HF Daten schon mal eine andere Adresse 
aufgefallen?

: Bearbeitet durch User
von Martin G. (petersilie)


Lesenswert?

Hallo Oliver,

Danke für Deine Logs. Ich habe dazu wiederum ein paar 
Fragen/Anmerkungen:

(1)
Nach meinem Verständnis kann der NRF24 zwar von bis zu 6 "Pipes" = 
"Adressen" empfangen, aber nur Pipe 0 ist unabhängig, Pipe 1-5 teilen 
sich die ersten 4 Bytes, d.h. dürfen sich nur im letzten Byte 
unterscheiden (siehe Kapitel 7.7 "Multiceiver"). Das würde erklären, 
warum Du nur Nachrichten von C1 und C3 siehst.

(2)
In Deinen Mitschnitten tauchen auch wieder diese 0-Byte Payload Pakete 
auf. Laut Datenblatt sind das ACK-Pakete, die der Chip automatisch 
sendet, wenn er auf der jeweiligen Adresse etwas empfangen hat. Ich 
meine, bisher sieht es so aus, als sei diese ACK Funktion bei den 
Hoymiles Geräten deaktiviert. Wir sollten diese auf jeden Fall bei 
jeglichen Sniffern auch deaktivieren (setAutoAck(false)), sonst greifen 
die ja aktiv in den Funkverkehr ein. Vielleicht kommt da auch manche der 
Verwirrung weiter oben her - denn die Adresse dieser ACK-Pakete ist ja 
jeweils gleich der Adresse des ursprünglich empfangenen Pakets.

(3)
Bzgl. Deiner Frage wegen anderer Adressen - ich meine, martin (Gast) 
hatte auch schon einmal Adressen beobachtet, die in 0x00 (anstatt 0x01) 
enden. Als "Broadcast" zwischen allen WR würde das aber nicht wirklich 
taugen, hierzu würde sich vielleicht am ehesten die DTU Adresse eignen. 
Vielleicht gibt es bei Inbetriebnahme auch Broadcasts an 0x0000000000 
oder so - auf uC-Seite scheinen manche Pakete solch eine Adresse zu 
enthalten.

-- Petersilie

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

Hallo Martin.

Also ich habe jetzt mal etwas mit dem RF25L01+ Chip experimentiert. So 
ganz bin ich noch nicht dahinter gestiegen wie er funktioniert. Es ist 
sicherlich irgend so ein ASIC der als Schrittschaltwerk funktioniert 
ohne abhängige Logic, bzw. ohne die eingestellten Parameter zu prüfen. 
Er macht etwas in Abhängigkeit der eingestellten Register. Es kann schon 
mal sein, dass er völlig durcheinander ist und nur ein Spannungsreset 
hilft. So meine Beobachtung.

Zu Deinen Fragen/Anmerkungen:
(1)
So wie ich es verstehe besteht die Möglicheit, dass die Adressen von 
Pipe 0 und Pipe 1 5 Byte lang sind. Pipe 2-5 betrachte ich nicht, diese 
hängen natürlich von den restlichen Bytes der Pipe 1 ab.
Ich habe die Pipes auf die beiden Wechselrichter programmiert:
1
pipe 0 ( open ) bound   = 0x3944107301                                                                                  
2
pipe 1 ( open ) bound   = 0x1946107301                                                                                  
3
pipe 2 (closed) bound   = 0xc3                                                                                          
4
pipe 3 (closed) bound   = 0xc4                                                                                          
5
pipe 4 (closed) bound   = 0xc5                                                                                          
6
pipe 5 (closed) bound   = 0xc6
Im Log werden die Einträge von C2 nicht angezeigt, weil die Abfrage der 
Pipe im Interrupt aus irgendeinem Grund nicht funktioniert. Darum stimmt 
die im Adurino generierte Prüfsumme nicht. Die Telegramme werden aber 
erfasst, jedoch der Pipe 1 zugeordnet, obwohl sie zu Pipe 0 gehören. 
Hier ein Beispiel, gehört eigentlich zu Pipe 0, die Abfrage
1
radio2.available(&pipe)
liefert aber Pipe 1, darum wird das Telegramm C3 zugeordnet und 
anschließend wegen falscher Prüfsumme (Die Berechnung legt die Adresse 
WR2 zugrunde) verworfen. In den Nutzdaten sieht man aber, dass das 
Telegramm eigentlich für 73104439 bestimmt ist.
1
C3 019634660 00 1946107301 00DE 1B 3  15 73104439 72819005 800B00623DD84B00000005000000009117A9035D 1565 0

(2)
Was Du sagst ist absolut richtig, aber wenn dann ist es in der RF24 
Dokumentation missverständlich beschrieben. Die AutoAck Funktion ist bei 
allen "Sniffern" deaktiviert. Darum sollten die nicht für die Ack Frames 
verantwortlich sein.
Die ACK Frames die ich sehe sind auch immer an die Adresse der DTU 
gerichtet. Meine RF24 sind so eingestellt, dass die TX_ADR auf Default 
steht:
1
TX_ADDR         = 0xe7e7e7e7e7
Das Datenblatt sagt ja, dass für die AutoAck Funktion TX und RX Addr. 
gleich sein müssen.
1
TX5 device: TX_ADDR = 0xB3B4B5B605
2
TX5 device: RX_ADDR_P0 = 0xB3B4B5B605
3
RX device: RX_ADDR_P5 = 0xB3B4B5B605
Muss man sicherlich noch weiter hinterfragen.

(3)
Als Ursache für die Adressen die mit 0x00 enden habe ich für mich den 
yveaux Sniffer ausgemacht. (Gut wenn man einen Schuldigen hat). Dieser 
stellt im RF 24 immer fest eine Adressbreite von 4 Byte ein (Bzw. 
Parametrierte Adressbreite - 1).
1
#define DEFAULT_RF_ADDR_PROMISC_WIDTH  (DEFAULT_RF_ADDR_WIDTH-1)
Das fehlende 0x01 in der Adresse wird dann schon der Payload zugeordnet. 
Dies ist der Grund, warum ich in älteren Aufzeichnungen immer ein Bit 
vor dem 9-bit PCF hatte. (Siehe Anhang) Die 0x02 ist die 0x01 in Byte 5 
der Adresse.

Martin (Gast) hatte noch eine Anmerkung:
> Was mir hier und auch in meinen Daten aufgefallen ist: In den
> Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer
> mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun
> haben, der für die Antwort verwendet werden soll?

Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über 
die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)

Turn unit off:
C2 850194040 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5CD8000000080000000013DAD8A73B 3BA7 1
Turn unit on:
C2 067083344 00 1946107301 00DE 1B 3  15 73104619 72819005 
800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1
Turn unit off:
C2 055407012 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5DC20000000A0000000076413F7EAF AF7E 1
Turn unit on:
C2 086582484 00 1946107301 00DA 1B 1  15 73104619 72819005 
800B00623B5E4B0000000B000000002F872B6ABD BD6A 1

: Bearbeitet durch User
von Oliver F. (of22)



Lesenswert?

Ich möchte gerne einen kleinen Teilerfolg vermelden.
Ich kann meine WR ohne die DTU abfragen und erhalte sporadisch 
Antworten. Ein Muster erkenne ich noch nicht.

Bisher kann ich meinen Aufbau nur mit RF24_PA_LOW betreiben.
Aber die Sendeleistung reicht um die 30m entfernten WR zu erreichen.
Beim Senden meldet sich bei einer höheren Sendeleistung immer der CH340 
Chip USB zum Rechner ab.
Zunächst ging sogar nur RF24_PA_MIN, bis ich die 3.3V zum RF Modul mit 
einem 100uF Elko gestützt habe.

Die DTU Radio ID in dem Code kann ich beliebig ändern, die WR antworten 
dann auf die neue DTU ID.
Als Anpassung sollte es reichen, die DTU Radio Ids zu ändern. Bei nur 
einem WR zunächst irgendeine Dummy Adresse verwenden oder diese 
belassen.
1
#define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL) 
2
#define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
3
#define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
4
#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)

Die Wechselrichter scheinen irgendeinen proprietären Mechanismus bei dem 
Channel hopping zu verwenden. Den habe ich noch nicht verstanden.
Der Trick ist, auf einer anderen Adresse zu empfangen als zu senden und 
beim Senden bis die maximale Retransmit rate mit 2ms Pause zu verwenden.
Zur Zeit verwende ich die Kanäle 3 und 40. Auf einigen anderen Kanälen 
geht bei mir gar nichts, vermutlich wegen meinem WLAN. Muss man evtl. in 
jeder spezifischen Umgebung ausprobieren.
Versucht habe ich es mit einer Kombination aus den bereits weiter oben 
erwähnten Kanälen:
1
int channels[] = {3, 23, 40, 61, 75};
1
#define DEFAULT_RECV_CHANNEL (3)           // 3 = Default channel for Hoymiles
2
#define DEFAULT_SEND_CHANNEL (40)          // 40 = Default channel for Hoymiles

Kann dies jemand bei sich nachvollziehen?
Oder liegt es bei mir daran, dass die WR schon mal mit der DTU 
kommuniziert haben und dadurch noch irgendeine Konfiguration haben?

Bei Fragen oder Problemen einfach melden.

: Bearbeitet durch User
von B. G. (golf2010)


Lesenswert?

Hallo Oliver,

was genau wird bei dir zur Anforderung an den WR gesendet ?

Vielleicht sende ich da was falsches. Bisher bei mir ohne Erfolg.
Ich hab 14 retransmits eingschalten, hab auf jeder Megahertz - Frequenz 
2400 - 2525 Mhz gesendet. Der WR hat nirgends geantwortet.

Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen 
und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, 
daß er irgendwo antwortet. Dann könnte ich immer noch mit Aufnahmen 
feststellen, wo.
(Die Messung mit dem AD8318 funktioniert einwandfrei, wenn ich den an 
meinen NRF dran stelle.)

Evtl fehlt dann doch irgendeine Grundinitialisierung an den WR, daß er 
was tut oder ich sende Schrott.

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

B. G. schrieb:
>
> was genau wird bei dir zur Anforderung an den WR gesendet ?
>
Hallo B.G.

Der Quelltext ist dem Beitrag angehängt. Ich sende alle 200ms ein 
Telegramm an meine beiden Wechselrichter. Sie antworten nicht jedes mal, 
sondern gefühlt jedes 4-5 Mal. Ich denke das hat mit dem noch nicht 
durchschauten Channel Hopping zu tun.

Es wird nacheinander auf CH40 das 0x80 Telegramm mit einer simulierten 
Unix Zeit gesendet, da ich auf dem nano keine Echtzeituhr habe. Das 
scheint dem WR aber egal zu sein.

Dann das 0x81, 0x80, 0x83, 0xFF Telegramm, wie von Martin in der 
Protokollbeschreibung angegeben. Danke an Martin das ist sehr hilfreich.

Nach dem Senden wird direkt wieder auf CH3 umgeschaltet und gehorcht.
1
      if (tel > 4)
2
        tel = 0;
3
      if (tel == 0)
4
        size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8);
5
      else if (tel == 1)
6
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x81);
7
      else if (tel == 2)
8
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x80);
9
      else if (tel == 3)
10
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83);
11
      else if (tel == 4)
12
        size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0xFF);
13
14
      SendPacket(dest, (uint8_t *)&sendBuf, size);
15
16
      toggle = !toggle;
17
      if (!toggle)
18
        tel++;

Ein Dump mit Ausgabe von Send und Receive ist angehängt.

Die Zeilen mit diesem Inhalt sind dabei die vom WR empfangenen Daten.
1
 048491820 00 1234567801 00DC 1B 2  95 73104619 73104619 010001014F027908470150026D08220000FB9CDF 9CDF 1
2
 048540572 00 1234567801 00DE 1B 3  95 73104619 73104619 02FE300000F91307790762096413840FADF0AB62 AB62 1
"Send..." ist jeweils ein Send auf CH40. PL die Payload, WR1/2 gibt an 
an welche Adresse. Die 0 danach ist der Rückgabewert vom Write, da ja 
kein ACK von den WR kommt. Dann die millis() Zeit des Nano und die Dauer 
des Sendens in millis().
1
Send... CH40 PL: 1573104439785634128182  WR2 0 48677140 29204
2
Send... CH40 PL: 15731046197856341281A0  WR1 0 48877844 29204

: Bearbeitet durch User
von B. G. (golf2010)


Lesenswert?

vielen Dank,
wenn es jemand gibt, der Erfolg mit dem zurücklesen hat, ohne eigene DTU 
zu besitzen, dann bitte melden.

bei martin müßte es ja evtl jetzt so funktionieren ?

von Martin G. (petersilie)


Lesenswert?

Hallo @golf2010 und @of22,

das ist tolle Arbeit. Muss man erst mal drauf kommen! Hoffentlich komme 
ich morgen dazu, das mit meinem Raspi-Setup auszuprobieren.

Können wir eventuell noch weiter einschränken, welche Nachrichten 
wirklich notwendig sind?

(1)
@of22, Du wechselst zwischen den 5 Pakettypen im Kreis herum - hast Du 
mal probiert, ob weniger eventuell immernoch zum Erfolg führen?

(2)
Und habe ich das richtig verstanden, du hörst immer auf Kanal 3? D.h. 
angenommen, Du würdest nach dem Senden auf Kanal 40 bleiben, dann 
würdest Du nichts empfangen?

(3)
Und noch ne ganz ketzerische Frage: wenn Du garnichts sendest und nur 
auf Kanal 3 zuhörst, empfängst Du aber nie irgendwelche Nachrichten, 
oder doch?

von Oliver F. (of22)


Lesenswert?

Hallo Martin G.

(1)
Habe ich versucht nur das 0x80 mit dem Unix Timestamp zu senden, das 
reicht aus. Aber dann kommt nur der 01 00 01 Response. Mit den anderen 
zwischendurch kommt auch mal ganz selten eine andere Antwort.
Ich hatte schon versucht mir die Saleae Captures von martin (Gast) 
20.03.2022 13:37 anzusehen, um hier vielleicht anhand der Serial 
Captures ableiten zu können welche Requests erforderlich sind. Könnte 
man die vielleicht als ASCII Dump oder so zur Verfügung stellen? Ich 
habe kein Saleae und so wie ich es veerstehe gibt es keine Stand Alone 
Version der Software.

(2)
Das ist richtig, so ist meine Beobachtung. Gesendet und Empfangen wird 
immer auf einem unterschliedlichen Kanal. Bleibe ich auf dem Sendekanal, 
egal ob 40 oder 3, empfange ich keinen Response.

(3)
Nein, wenn ich aufhöre zu senden kommen keine Responses vom WR mehr.
Er muss immer durch irgendein Telegramm getriggert werden.

: Bearbeitet durch User
von Thomas B. (tbnobody)


Lesenswert?

Hallo @of22,

habe mir die Hardware mit dem Nano aufgebaut. Kommunikation mit dem 
NRF24 scheint zu tun. Also Register usw. werden ausgelesen. Nur kurz 2 
Fragen bevor ich hier tiefer in den Code einsteige.
1. Muss die Seriennummer des WR auch Rückwärts angegeben werden?
2. Wie funktioniert das Menü? Wird gleich nach dem Startup schon 
gesendet oder muss man das Senden zuerst über die Serielle Konsole 
starten?

Danke & Grüße
Thomas

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

Hallo Thomas.

Die Seriennummer muss in dem define umgekehrt angegeben werden.

An meinem Beispiel:
WR1 = xxxx73104619
WR2 = xxxx73104439

Und im Byte 5 der Adresse die 01 nicht vergessen.

Die Adresse der DTU ist egal, da Du sie ja simulierts.
1
#define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL) 
2
#define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
3
#define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
4
#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)

Das Menü ist erst einmal uninteressant. Der Code fängt direkt an zu 
senden.
Es waren nur Tests um die Kommunikation auf einzelne Telegramme 
einzuschränken.

Eine Anmerkung noch: Eventuell muss der Sendelevel angepasst werden.
Ich habe die Module ali-005 mit externer Antenne im Einsatz. Damit komme 
ich nicht über PA_LOW sonst hängt sich etwas auf (CH340), oder ich 
bekomme keine Antworten.
Vorhin habe ich es noch die ali-001 ausporbiert. Damit muss ich höher 
gehen auf PA_HIGH sonst bekomme ich keine Antwort von den ca. 30 m 
entfernten Wechselrichtern durch zwei Wände.
Aber auch mit denen kann ich nicht auf PA_MAX gehen sonst kommt wiederum 
keine Antwort.
1
radio1.setPALevel(RF24_PA_HIGH);

Und dran denken, jetzt ist dunkel. Da kommt nichts mehr, weil der WR aus 
dem DC Kreis versorgt wird.

: Bearbeitet durch User
von Thomas B. (tbnobody)


Lesenswert?

Hallo Oliver,

alles klar danke! Habe hier auch den ali-005. Habe aber schon einen 10uF 
angelötet. Werde es erstmal mit LOW versuchen und mich notfalls mit dem 
Laptop raus stellen. Ich bin ja sooo gespannt. Jetzt wenn schon Sonne 
vorhanden wäre :)

Grüße
Thomas

von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

B. G. schrieb:
> Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen
> und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen,
> daß er irgendwo antwortet.

Ich hab tagelang völlig unnötig rumprobiert. Da war bei mir nur ein 
Zahlendreher in meiner eingegebenen WR-Seriennummer. Nachdem ich den 
heute Nacht gesehen hab, hat der WR heute morgen sofort geantwortet auf 
ein 80 Paket. Also brauchst doch keine extra Initialisierung.

Anbei der Ausgang von meinem Pegelmesser AD8318, am Oszi angeschlossen.
Ich muß jetzt schauen, wo er antwortet.

von B. G. (golf2010)



Lesenswert?

B. G. schrieb:
> Ich muß jetzt schauen, wo er antwortet.

auf 2403 kam der gerade.
auf der 2405 gibts hier noch einen weiteren NRF, wohl ein Nachbar. Der 
auf 2405 kommt etwas stärker rein.

: Bearbeitet durch User
von Hubi (Gast)


Lesenswert?

Hallo B.G.
dein Testprogramm funzt einwandfrei. Es werden zwar nicht alle Anfragen 
beantwortet, aber so alle 1 - 2 Sekunden kriegt man Daten. Und das ist 
doch schon was.

von B. G. (golf2010)


Lesenswert?

Hallo Hubi,
das Programm ist von Oliver. Ich kann kein C, nur Pascal(Avrco) und 
Delphi.

von Thomas B. (tbnobody)


Lesenswert?

Hallo,

kann es auch bestätigen. Daten werden empfangen. Ich kann auch 
bestätigen das es mit > RF24_PA_HIGH nicht funktioniert. Zumindest wenn 
ich den NRF24 via USB betreibe. Am Labornetzteil tut es.

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

Hallo,
das freut mich zu hören, dass es auch bei anderen klappt.
Das man nicht jedes Mal eine Antwort erhält, liegt an dem noch nicht 
durchschauten Channel Hopping.
Ich habe mal noch ein paar Sachen zum Nachdenken, wer möchte, kann sich 
gerne beteiligen.
Ich habe meiner DTU und einem WR nochmal bei der Kommunikation mit 
diesem Aufbau zugehört: Zwei RF24 Chips. Einer lauscht auf Kanal x und 
der andere auf x + 40, jeweils für 60 s. Dann wird x inkrementiert von 0 
bis 39.
Dabei heraus gekommen ist diese Statistik. Das ist sicherlich eine 
Momentaufnahme, die sich aus meinem WLAN Umfeld und aus anderen Störern 
ergibt. Auch sind bei den Frames WR=>DTU die Antworten von dem zweiten 
Wechselrichter, dessen DTU Anfragen nicht geloggt werden, das könnte das 
Bild verfälschen.
Kommunikation läuft auf mehr als den bisher angenommenen Kanälen, wobei 
es bei den Kanälen 7, 8, 9 auch ein Übersprechen sein könnte.
WR an DTU sind am häufigsten auf Kanal 3 und 23 vertreten. DTU an WR 
springt lustig durch die anderen Kanäle, wobei 0, 7, 9, 23, 27, 35, und 
40 die Spitzenreiter sind. Als Kommandos DTU=>WR sieht man die Ids 0x80, 
0x81, 0x82, 0xFF.
1
Kanal | Frames | DTU=>WR | WR=>DTU | 0x80 | 0x81 | 0x82 | 0xFF
2
------+--------+---------+---------+------+------+------+------
3
    0 |     11 |      11 |      0  |    5 |    0 |    0 |    6
4
    3 |     81 |       8 |     73  |    5 |    4 |    1 |    2
5
    7 |     10 |      10 |      0  |    8 |    0 |    0 |    2   
6
    8 |      3 |       3 |      0  |    2 |    0 |    1 |    0   
7
    9 |     12 |      12 |      0  |    9 |    0 |    3 |    0 
8
   11 |      9 |       9 |      0  |    8 |    0 |    1 |    0
9
   14 |      1 |       1 |      0  |    1 |    0 |    0 |    0
10
   20 |      3 |       3 |      0  |    2 |    0 |    0 |    1
11
   23 |     59 |      12 |     47  |    7 |    1 |    4 |    1  
12
   27 |     13 |      13 |      0  |    9 |    1 |    1 |    2  
13
   29 |      8 |       8 |      0  |    4 |    0 |    3 |    1
14
   35 |     11 |      11 |      0  |    5 |    2 |    1 |    3
15
   37 |      8 |       8 |      0  |    6 |    0 |    2 |    0
16
   39 |      8 |       8 |      0  |    5 |    0 |    2 |    1
17
   40 |     10 |      10 |      0  |    6 |    0 |    1 |    3
18
   61 |     13 |       9 |      4  |    6 |    0 |    2 |    1
19
   75 |      8 |       3 |      5  |    2 |    1 |    0 |    0
Woher weiß die DTU, auf welchem Kanal der WR lauscht?
Und woher weiß sie, auf welchem Kanal die Antwort vom WR kommt?
So aus einem Bauchgefühl heraus:
Könnte das 0xFF Telegramm die Aufforderung zum Kanalwechsel sein, aber 
wohin?
Bei dem 0x80 Telegramm sehe ich im Byte hinter der 0x80 die Bytes 0x0B 
oder 0x11 (Siehe Screenshot). Die Bedeutung erschließt sich mir noch 
nicht.
Beigefügt der Dump aus dem Minuten Scan als Rohdump und aufbereitete 
Excel.

: Bearbeitet durch User
von Sorbit (Gast)


Lesenswert?

Hallo,

es geht voran, aber nicht so direkt Beteilige verlieren den Überblick.
So auch ich.

Kann bitte jemand einmal kurz und knackig die benötigte Hardware 
skizzieren und die Software mit Sourcecode bereitstellen?

Dann kann jeder Homiles Nutzer sich schnell zurechtfinden.

Danke

von Martin G. (petersilie)


Lesenswert?

@of22:
Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen 
Uhrzeit stehen?

von Martin G. (petersilie)


Lesenswert?

Bezugnehmend auf Sorbit (Gast) würde ich gerne 
https://github.com/grindylow/ahoy als Sammelstelle vorschlagen.

Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf 
das Repository geben.

@Sorbit, ich glaube, so hundertprozentig "einstecken und tut"-Lösungen 
haben wir noch nicht - jeder hat leicht andere Hard- und Software, aber 
gerade deshalb geht es erstaunlich voran! Aber Du hast natürlich Recht, 
ich denke wir haben alle ein Interesse daran, dass das ganze früher oder 
später einfach(er) nachzuvollziehen und zu nutzen wird.

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

Martin G. schrieb:
> @of22:
> Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen
> Uhrzeit stehen?

Hallo Martin,
gute Idee, das ist ja fast das Einzige was sich in den Telegrammen 
ändert.
Beziehe ich in meine Grübeleien ein.

> Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf
> das Repository geben.

Bisher ist das Ganze ja nur ein zusammengeklopptes Testprogramm.
z.B. könnte man die CRC Generierung auf eine Bibliothek umstellen.
https://github.com/RobTillaart/CRC oder so.
Auch wird im Testprogramm Kanal 40 zum Senden und 3 zum Empfangen 
verwendet.
Die Statistik oben zeigt ja, dass man auch auf 23 lauschen müsste und 
auf anderen senden.

Aber Du kannst gerne den jetzigen Stand hochladen.

@ Sorbit (Gast):
Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in 
China bestellt hatte. Ich mag die Atmel Dinger aber ansonsten nicht.
Dazu ein RF24 Modul ali-005 (Siehe weiter oben). Die Schaltung habe ich 
skizziert. Ich betreibe den nano mit den 5V vom Laptop USB. Problem ist 
hierbei noch die 3V3 Versorgung des RF24.
Wie Thomas B. (tbnobody) herausgefunden hat verwendet man besser noch 
ein externes Netzteil.
Die Leistung des Linearreglers im CH340 des nanos reicht nicht aus um 
die Versorgung bei höheren Sendeleistungen sicher zu stellen.

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

im Source von Oliver sollten ja die verschiedenen Packages nacheinander 
durchprobiert werden. Daher hätte ich erwartet, dass die Antworten mit 
gleicher Häufigkeit vorkommen. Aber siehe capture.txt im Anhang sehe ich 
hauptsächlich 1er und 2er... die 3er Messages kommen kaum vor. Könnt ihr 
das Nachvollziehen, ist das bei euch ähnlich?

Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu 
dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich 
daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, 
ggf. auch der Strom, aber spätestens bei der Leistung stimmt es 
zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe 
hier einen HM-1500)

Ggf. sind die Telegramme je nach Typ unterschiedlich aufgebaut. Dann 
müsste man aber seinen Typ entweder in der Hoymiles Cloud einstellen 
können oder dieser wird irgendwo noch mitgeschickt.

von Martin G. (petersilie)


Lesenswert?

Oliver F. schrieb:
> Aber Du kannst gerne den jetzigen Stand hochladen.

Gesagt - getan: 
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

von Wie bitte? (Gast)


Lesenswert?

Oliver F. schrieb:
> @ Sorbit (Gast):
> Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in
> China bestellt hatte.

Davon hab ich genug rumfliegen.
Welcher Code läuft da drauf?
RF Modul hab ich auch mal im 20 er Pack gekauft.

Alles da, auch ein produktiver HM-1200...


Danke

von Was bitte? (Gast)


Lesenswert?

Wie bitte? schrieb:
> Welcher Code läuft da drauf?

Siehe zwei Nachrichten weiter oben.

von Martin G. (petersilie)


Lesenswert?

Hallo @of22, ich bin noch über Deine Zeile 
https://github.com/grindylow/ahoy/blob/82ce2c9d8864dcc465af804ab0130dd7a7322a6b/tools/nano/NRF24_SendRcv/src/hm_packets.cpp#L49 
gestolpert:
1
  buf[19] = 0x05;

Warum? Und was passiert, wenn das nicht gemacht wird (also an dieser 
Stelle ein 0-Byte verbleibt)? Ist das der von Dir beobachtete Zähler, 
der sich mit jedem Schaltbefehl erhöht?

von Mag C. (magcode)


Lesenswert?

Hallo, ich möchte mir schonmal die Hardware bestellen. Wir reden über 
sowas, richtig? https://www.ebay.de/itm/255283312809
(Einen Nano habe ich)
Danke sehr!

von Oliver F. (of22)


Lesenswert?

Hallo @petersilie.

Ja, dass ist richtig. Es ist wie weiter oben beschrieben.
Ich habe gesehen, dass der Zähler mit jeder Schaltaktion inkrementiert 
wird.
Es ist wahrscheinlich ein 16-bit Wert. Durch die ganze Probiererei 
scheint der Zähler aus der Cloud mittlerweile bei 0x0537 zu stehen?!?
Es passiert erst einmal nichts offensichtliches, wenn man das weg lässt.
Keine Ahnung was das ist.
1
15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1

@Mag C. (magcode):
Ja das Modul verwende ich auch. Wichtig ist, dass es ein NRF24L01*+* 
(Plus) ist.

: Bearbeitet durch User
von Martin G. (petersilie)


Lesenswert?

Thomas B. schrieb:
> Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu
> dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich
> daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen,
> ggf. auch der Strom, aber spätestens bei der Leistung stimmt es
> zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe
> hier einen HM-1500)

Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in 
Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier 
unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe 
geschaltet?

Wenn wir die Verläufe über ein paar Stunden betrachten, idealerweise mit 
gleichzeitiger Beobachtung der Ausleuchtung der 4 Solarpanels, dann 
kommen wir bestimmt hinter die genaue Bedeutung der einzelnen Felder.

Der WR-Typ wird ja vielleicht in einem der bisher als "unbekannt" 
gekennzeichneten Bytes/Bits übertragen. Oder vielleicht ist er in der 
Seriennummer kodiert? Oder die DTU fragt das bei der Einrichtung 
einmalig ab?

von martin (Gast)



Lesenswert?

martin schrieb:
> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden

Hallo zusammen,
leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, 
wie es hier voran geht. Danke an alle Beteiligte.

Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher 
schon mal aufgenommen hatte:
Könnte es vielleicht sein, dass der Inverter generell auf einem anderen 
aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner 
Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen.
Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das 
wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben 
erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die 
Interferenzen sind.

Nur so eine Idee - auch wenn das von den im FCC Report genannten 
Frequenzen abweichen würde. Falls das den Hersteller überhaupt 
interessiert... (grübel)

von B. G. (golf2010)



Lesenswert?

martin schrieb:
> martin schrieb:
>> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden
>
> Hallo zusammen,
> leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega,
> wie es hier voran geht. Danke an alle Beteiligte.
>
> Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher
> schon mal aufgenommen hatte:
> Könnte es vielleicht sein, dass der Inverter generell auf einem anderen
> aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner
> Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen.
> Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das
> wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben
> erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die
> Interferenzen sind.
>
> Nur so eine Idee - auch wenn das von den im FCC Report genannten
> Frequenzen abweichen würde. Falls das den Hersteller überhaupt
> interessiert... (grübel)

Das ist momentan bei mir nicht der Fall. Die WR senden auf den festen 
Channel-Frequenzen, wie es aussieht. Keine Ahnung, was damals alles 
aktiv war bei Deinen Aufnahmen. Das war auch komisch mit den instabilen 
Sendern, als wenn entweder der HackRF oder eine NRF instabil war.
Der WR scannt die Kanäle durch bis er was empfangen hat und, wie es 
aussieht, sendet er dann immer 3 Antwort Telegramme, oft auf 
unterschiedlichen Frequenzen. (Telegramme nicht näher untersucht)
Die Kanalwahl hat erst mal nichts zu tun mit der übermittelten Zeit.

Das Sonagramm der Aufnahme ist etwas schwach, hatte nur ein Stück Draht 
als Antenne.

: Bearbeitet durch User
von martin (Gast)


Lesenswert?

B. G. schrieb:
> Das war auch komisch mit den instabilen
> Sendern, als wenn entweder der HackRF oder eine NRF instabil war.

Ok, danke für die Rückmeldung. Ich werde das bei Gelegenheit nochmal 
nachmessen.

von B. G. (golf2010)


Lesenswert?

> Der WR scannt die Kanäle durch bis er was empfangen hat.

Deshalb wird vmtl immer mit 15 Retransmits gesendet.
Auch der DTU scannt vmtl einfach die Kanäle durch, die Telegramme werden 
ja genügend oft wiederholt.

von Marcel (Gast)


Lesenswert?

Hallo,

ich versuche gerade mal durch den Code zu gehen und diesen zu verstehen. 
Dabei ist mir aufgefallen, das der Wert 0x05 an Stelle 19 gesetzt wird:
1
buf[19] = 0x05;

dennoch ist er bei deiner Ausgabe aber immer an Stelle 18:
1
15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1

Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben 
werden ?

Vielen Dank

von Oliver F. (of22)


Lesenswert?

Marcel schrieb:
> Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben
> werden ?

Hallo Marcel.

Nein Du hast nichts übersehen. Das rudimentäre Testprogramm zur 
Simulation der DTU schreibt an dieser Stelle immer eine 0x05. So ist es 
momentan noch, weil wir die Bedeutung dieses Wertes noch nicht kennen.

Siehe Nachricht vom  27.03.2022 19:34 an Petersillie.

Das Beispiel was Du anführst ist aus einem aktuellen Scan der 
Kommunikation zwischen DTU und WR. Hier steht dieser "Zähler" jetzt 
schon auf 0x0537.
1
15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1

Siehe auch Nachricht vom 25.03.2022 15:35:
Dieser Zähler inkrementiert sich, wenn man aus der Hoymiles Cloud heraus 
eine Schaltaktion durchführt.
1
Turn unit off:
2
C2 850194040 00 1946107301 00DA 1B 1  15 73104619 72819005 
3
800B00623B5CD8000000080000000013DAD8A73B 3BA7 1
4
Turn unit on:
5
C2 067083344 00 1946107301 00DE 1B 3  15 73104619 72819005 
6
800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1
7
Turn unit off:
8
C2 055407012 00 1946107301 00DA 1B 1  15 73104619 72819005 
9
800B00623B5DC20000000A0000000076413F7EAF AF7E 1
10
Turn unit on:
11
C2 086582484 00 1946107301 00DA 1B 1  15 73104619 72819005 
12
800B00623B5E4B0000000B000000002F872B6ABD BD6A 1

von Marcel (Gast)


Lesenswert?

Vielen Dank,

ist aber auch ein witziger Zufall, das genau 05 um eine Stelle nach 
vorne gerückt ist. Somit hat der Counter da 16 bit, ergo 4 Stellen.

Danke

von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine erste 
Testimplementierung in Python für RaspberryPi.

Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf 
Kanal 40, ansonsten immer auf Kanal 3 zuhören.

Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit 
einer DTU in Kontakt war.

Ergebnis: siehe Anhang.

(Programm siehe 
https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)

: Bearbeitet durch User
von Hubi (Gast)


Lesenswert?

Hallo zusammen
mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren.
Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB 
Leistung der letzten Tage, Wochen, Insgesamt?

von Sorbit (Gast)


Lesenswert?

Martin G. schrieb:
> Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine
> erste
> Testimplementierung in Python für RaspberryPi.
>
> Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf
> Kanal 40, ansonsten immer auf Kanal 3 zuhören.
>
> Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit
> einer DTU in Kontakt war.
>
> Ergebnis: siehe Anhang.
>
> (Programm siehe
> https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)

Hardware Setup, Software?
Viele unterstützen und sollten es auch nachbauen Können.

Danke

von Oliver F. (of22)


Lesenswert?

Hubi schrieb:
> Hallo zusammen
> mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren.
> Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB
> Leistung der letzten Tage, Wochen, Insgesamt?

Hallo Hubi,
das weiß ich zwar nicht zu 100% aber ich halte es für sehr 
unwahrscheinlich.
Das ist klassisch die Aufgabe der Cloud. Das wirst Du in ioBroker mit 
influxdb und/oder Grafana oer ähnlichem machen müssen.

von Martin G. (petersilie)


Lesenswert?

Sorbit schrieb:
> Hardware Setup, Software?

Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den 
ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja 
noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben. 
Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon.

https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md

Gruß

-- petersilie

von Sorbit (Gast)


Lesenswert?

Martin G. schrieb:
> Sorbit schrieb:
>> Hardware Setup, Software?
>
> Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den
> ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja
> noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben.
> Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon.
>
> https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md
>
> Gruß
>
> -- petersilie

Klasse, super Beschreibung, toll gemacht!

Woher bekommst Du die Seriennummer vom WR?
Meiner ist leider schon unter den Panels auf dem Dach verbaut😪😪

von Thomas B. (tbnobody)


Lesenswert?

Sorbit schrieb:
> Woher bekommst Du die Seriennummer vom WR?

Die Seriennummer habe ich leider bisher nur auf der Rückseite des WR 
gesehen. Dort sind 2 Labels mit der Seriennummer aufgebracht.

von Wie bitte? (Gast)


Lesenswert?

Thomas B. schrieb:
> Die Seriennummer habe ich leider bisher nur auf der Rückseite

Schei.......

Ohne die Nummer keine Kommunikation?

von Thomas B. (tbnobody)


Lesenswert?

Wie bitte? schrieb:
> Ohne die Nummer keine Kommunikation?

Das ist korrekt.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

Thomas B. schrieb:
> Dort sind 2 Labels mit der Seriennummer aufgebracht.

Genau. Damit man eines abziehen und auf den beigefügten 
Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu 
klettern ;-)

von temp (Gast)


Lesenswert?

mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max. 
Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden? 
Gibt es dafür Beispiele auf Protokollebene?

von Wie bitte? (Gast)


Lesenswert?

martin schrieb:
> Genau. Damit man eines abziehen und auf den beigefügten
> Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu
> klettern ;-)

Tja, nacher ist man immer schlauer  ;-(

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

temp schrieb:
> mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max.
> Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden?
> Gibt es dafür Beispiele auf Protokollebene?

Hallo.
Das ist genau der Grund warum ich mich mit der Materie beschäftige. Ich 
habe eine DTU-WLite. Eigentlich hätte ich mit der Cloud Integration von 
Hoymiles prima leben können. Leider ist es aber so, dass Hoymiles die 
Funktion zum Begrenzen der Leistung bei der Lite DTU gesperrt hat. Man 
braucht dazu die sündhaft teure DTU-Pro.
Noch ist es ein weiter Weg, weil nur ein geringer Teil der Payload 
zwischen DTU und WR entschlüsselt wurde. Wir stehen da erst am Anfang, 
zu verstehen wie es funktioniert. Dazu kommt, dass zwar schon viele 
Telgramme gesnifft wurden, aber eben nur zwischen DTU-Lite und WR. Die 
Möglichkeit mit einer DTU-Pro zu sniffen habe ich z.B. nicht. Darum ist 
es für mich fraglich ob ich jemals diese Funktion der 
Leistungsbegrenzung nutzen kann.
Ich bekomme sporadisch viele verschiedene Antworten vom WR. Die 
Bedeutung muss erst einmal verstanden werden. Aber da ist bestimmt auch 
etwas dabei für WR mit mehr als zwei MPP Trackern.
P.S.
Autark wirst Du die WR der HM- Serie nie betreiben können, da sie ja 
einen NA Schutz haben und immer ein vorhandenes Netz in bestimmten 
Grenzwerten sehen wollen.

: Bearbeitet durch User
von Mag C. (magcode)


Lesenswert?

Hallo,

ich habe die RF Hardware erhalten und werde es mal mit den Arduino 
Sourcen probieren.

Ich habs auf Anhieb nicht gefunden ... wo würde ich die Seriennummer 
eintragen?
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

Danke sehr!


Update: habs gefunden! -> WR1_RADIO_ID

: Bearbeitet durch User
von Marcel (Gast)


Lesenswert?

Hallo,

bei mir antwortet der WR ziemlich präzise jede Minute (ich warte immer 3 
Sekunden auf Antwort). Aber alle Anfragen unter einer Minute werden 
nicht beantwortet (zumindest nicht auf Kanal 3)

Ich denke mal, die haben da einen Schutz drin, dass man eben nicht jede 
Sekunde abfragt. Vielleicht kann das jemand mit DTU und cloud 
bestätigen, indem man sich die Auflösung der Daten anschaut.
1
Time Tue Mar 29 15:59:32 2022
2
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 24 00 88 00 00 40 A7 03 A5 08 EF E8  
3
4
Time Tue Mar 29 16:00:32 2022
5
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 F9 FD  
6
7
Time Tue Mar 29 16:00:40 2022
8
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 FA FE  
9
10
Time Tue Mar 29 16:01:40 2022
11
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7A 00 23 00 84 00 00 40 A7 03 A5 08 FA FA  
12
13
Time Tue Mar 29 16:01:48 2022
14
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 79 00 23 00 83 00 00 40 A7 03 A5 08 F6 F2  
15
16
Time Tue Mar 29 16:02:48 2022
17
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 78 00 22 00 7F 00 00 40 A8 03 A6 08 FC 08  
18
19
Time Tue Mar 29 16:03:48 2022
20
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 73 00 20 00 77 00 00 40 A8 03 A6 08 F5 00  
21
22
Time Tue Mar 29 16:04:49 2022
23
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 1D 00 6D 00 00 40 A8 03 A6 08 F7 20

Ich habe einen HM-400 (mit nur einem Anschluß für Solar Paneele). 
Dennoch sind haben bei mir die Position 18-23 Werte. Ich denke nicht, 
das diese den Wert Volt, Ampere und Power beinhalten. Die Positionen 
12-17 Stimmen mit meinen Messungen überein.
1
if (data[0] == 0x95 && data[9] == 0x01) {
2
        // Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7C 01 33 04 90 00 00 40 75 03 73 09 09 0B  
3
        DATA.voltage_pv1 = float(data[12] << 8 | data[13]) / 10;
4
5
        DATA.ampere_pv1 = float(data[14] << 8 | data[15]) / 100;
6
7
        DATA.power_pv1 = float(data[16] << 8 | data[17]) / 10;
8
9
        DATA.voltage_pv2 = float(data[18] << 8 | data[19]) / 10;
10
11
        DATA.ampere_pv2 = float(data[20] << 8 | data[21]) / 100;
12
13
        DATA.power_pv2 = float(data[22] << 8 | data[23]) / 10;
14
    } else if (data[0] == 0x95 && data[9] == 0x82) {
15
        // Received: 95 73 10 90 25 73 10 90 25 82 13 88 04 57 00 01 00 30 03 E8 01 5B 00 1F 2E 2A 44  
16
        DATA.frequency = float(data[10] << 8 | data[11]) / 100;
17
18
    }


Danke für die Arbeit bisher. Ich bin schon mal sehr happy, das ich 
einige Daten lesen kann.

Marcel

von Marcel (Gast)


Lesenswert?

Wobei, ich revidiere. Da hatte er nur ein mal ein guten Lauf :) Nach 
erneutem Flashen des ESPs gehts jetzt nicht mehr so präzise.

Marcel

von Martin G. (petersilie)


Lesenswert?

(1)
Das mit dem Abfragerhythmus ist noch mysteriös, aber je mehr Erfahrung 
wir sammeln, desto näher kommen wir der Sache.

Ich fände es logisch, wenn der WR ziemlich zeitnah auf eine Anfrage 
antwortet.

Aber er muss eben die Anfrage auch hören (in unserem Fall: gerade auf 
Kanal 40 lauschen), und sie dann (in unserem Fall) genau auf Kanal 3 
beantworten.

Ich meine, in einigen der frühen Posts hatten wir schon beobachtet, dass 
eine DTU auf jeden Fall immer gleich auf mehreren Kanälen anfragt. Ich 
spekuliere mal, dass der WR dann vielleicht auch immer gleich auf 
mehreren Kanälen antwortet.

Vielleicht ist garnicht viel mehr Magie dabei. Auf vielen Kanälen 
fragen. Auf vielen Kanälen antworten. Wenn auf einem Kanal "lange" nie 
eine Nachricht kommt, mal auf einen anderen der bekannten Kanäle 
wechseln. Presto, semi-verlässliche Kommunikation.

(2)
Nachrichten-Inhalte. Hier habe ich mir seit längerem keine Zeit mehr 
genommen, die Protokollbeschreibung upzudaten. Es gibt ja ein paar neue 
Erkenntnisse. Aber ich sammle jetzt eifrig Beispieldaten mit meinem WR, 
und Du und viele andere machen dasselbe. Da finden wir bestimmt nach 
einiger Zeit Muster/Werte, über die wir dann auf den Inhalt der 
jeweiligen Datenfelder schließen können.

Deine Daten von dem 1-kanaligen WR sind vielleicht ähnlich wie die von 
@tbnobody mit seinem HM-1500 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")? Er 
sagt ja auch, dass es sich hier nicht um V/A/W handeln kann.

Ruhig mal nen ganzen Tag mitloggen!

von Marcel (Gast)


Lesenswert?

Ich hab die Daten jetzt mal mit meinem Esphome und Homeassistant 
Messungen verglichen. Ich gehe davon aus, das die Position 20 und 21 die 
Gesamtproduktion in Watt des WR und die Position 22 und 23 die 
Tagesproduktion in Watt sind. Die passen ziemlich genau mit den Daten 
von meinem HomeAssistant (wo ich den Strom messe, den ich ins Netz 
gebe).
1
DATA.total_production = float(data[20] << 8 | data[21]) / 1000;
2
DATA.daily_production = float(data[22] << 8 | data[23]);

Aber ich denke das werden die anderen bestimmt bald bestätigen oder 
widerlegen können :)

Marcel

von Mag C. (magcode)


Lesenswert?

Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt. 
WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen.

Beim starten gibt die serielle Konsole aus:
1
-- Hoymiles test --
2
19:11:42.309 -> 
3
19:11:42.309 -> Radio 1:
4
19:11:42.309 -> SPI Speedz  = 10 Mhz
5
19:11:42.309 -> STATUS    = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
6
7
19:11:42.309 -> RX_ADDR_P0-1  = 0xdeadbeef01 0x1234567801
8
9
19:11:42.309 -> RX_ADDR_P2-5  = 0xc3 0xc4 0xc5 0xc6
10
11
19:11:42.309 -> TX_ADDR    = 0xdeadbeef01
12
13
19:11:42.309 -> RX_PW_P0-6  = 0x20 0x20 0x20 0x20 0x20 0x20
14
15
19:11:42.309 -> EN_AA    = 0x00
16
17
19:11:42.309 -> EN_RXADDR  = 0x02
18
19
19:11:42.309 -> RF_CH    = 0x03
20
21
19:11:42.309 -> RF_SETUP  = 0x23
22
23
19:11:42.309 -> CONFIG    = 0x37
24
25
19:11:42.309 -> DYNPD/FEATURE  = 0x00 0x00
26
27
19:11:42.309 -> Data Rate  = 250 KBPS
28
29
19:11:42.309 -> Model    = nRF24L01+
30
31
19:11:42.309 -> CRC Length  = Disabled
32
33
19:11:42.309 -> PA Power  = PA_LOW
34
35
19:11:42.309 -> ARC    = 15
36
37
19:11:42.309 ->

Das wars dann leider. Mehr kommt nicht. Auch nach einigen Minuten 
warten. Ich war bis auf 4m am HM-400 ran. Der HM-400 hat während des 
Tests Strom produziert, war also aktiv. Verkabelung habe ich 
kontrolliert. Allerdings habe ich den Kondensator nicht und das RF Modul 
direkt an den 3.3v Pin des Nano angeschlossen...

von Oliver F. (of22)


Lesenswert?

Mag C. schrieb:
> Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt.
> WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen.

Du darfst nichts in HEX wandeln, also umrechnen. Die dezimale 
Seriennummer wird einfach als Hex Wert eingetragen.

Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge 
angegeben werden:

An meinem Beispiel:
WR1 = xxxx73104619

Und im Byte 5 der Adresse die 01 nicht vergessen.
#define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = 
WR1

von Marcel (Gast)


Lesenswert?

Zusätzlich braucht der HM ein wenig Sonne, sonst ist er aus. Hier in 
Nord Deustchland antwortet mein HM nicht mehr.

Da musst Du wohl bis morgen warten.

Marcel

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe gerade bei meinem HM-1500 einen etwas längeren Auszug von 
Sonntag Ausgewertet. (Rohdaten, leider ohne Timestamp siehe Anhang)

Hierbei habe ich mir zuerst die 1er Messages angeschaut. Ich habe mich 
hierbei am -r5 Dokument orientiert: 
https://www.mikrocontroller.net/attachment/550551/hoymiles-datenformat-r5.txt

PV1.u und PV1.i konnte ich soweit nachvollziehen. Die nächsten beiden 
Bytes machen dann keinen Sinn. Allerdings entsprechen die weiteren 
beiden Bytes (was im Beispiel oben PV2.u wäre) genau den Produkt von 
PV1.u und PV1.i, also der Leistung in .1W
Im Excel im Anhang habe ich dies auf dem Sheet 
"output_2022-03-27_18-20-16__1er" dargestellt. Spalte D - N entsprechen 
den HEX Werten, In Spalte P - W habe ich diese in Dez Werte umgerechnet.

Bei den 2er Messages konnte ich keine parallelen zum -r5 Dokument 
finden. Also es sieht hier nicht nach AC Werten aus. Spalte S 
multipliziert mit Spalte T entspricht aber Spalte V (+/- ein bisschen). 
Könnte also wieder U, I und P sein.

Bei den 3er Messages könnte Spalte V die AC Spannung sein. Aber das ist 
nur geraten.

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Hier btw ein Link zu einer DTU Pro:
https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html

Interessanter als die Hardware finde ich aber den Link mit den 
Zugangsdaten.

Ich habe mal ein paar Bilder angefügt.
Irgendwo scheint also auch noch die Temperatur und die Firmware Version 
versteckt zu sein.

von Marcel (Gast)


Lesenswert?

Hallo,

danke für die Screenshots. Das mit der Temperatur ist sehr hilfreich - 
ich hatte auch ein paar mal ähnliche Werte gesehen.

Danke
Marcel

P.s.: ich würde ein paar Sachen/Informationen in deinen Screenshots 
unlesbar machen. Wer weiß wie die drauf sind.

von Marcel (Gast)


Lesenswert?

Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power) 
pro Solar Panel oder ist das immer pro WR zusammengefasst? Ich bin 
bisher der Meinung, das ma neben nur die Gesamtleistung sieht und nicht 
jedes PV einzeln.

Marcel

von Marcel (Gast)


Angehängte Dateien:

Lesenswert?

Sorry, für den SPAM. Basierend auf deinen Daten, könnte ich mir 
vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar 
Panel Nummer ist. Das würde auch Sinn machen, da ich in meinen Logs noch 
nie eine 02 gesehen habe und immer nur 01 gefunden habe (HM-400 hat nur 
einen Anschluß für einen Solar String).


WR1 - Solar Panel #1
1
95 71603546 71603546 01...
2
[code]
3
4
WR1 - Solar Panel #2
5
[code]
6
95 71603546 71603546 02...

Anbei auch mal meine Daten analyse, wobei ich mir mit den letzten 
Feldern nicht ganz sicher bin. Bei mir stimmen die Daten mit meinen 
Messungen überein, aber die von Thomas ergeben nicht so viel Sinn (ggf. 
bedeuten die Werte doch was anderes).

von Mag C. (magcode)


Lesenswert?

Oliver F. schrieb:


> Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge
> angegeben werden:
>
> An meinem Beispiel:
> WR1 = xxxx73104619
>
> Und im Byte 5 der Adresse die 01 nicht vergessen.
> #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL =
> WR1

Danke für den Tipp! Jetzt läuft's
1
 000486220 00 1234567801 00DE 1B 3  95 74950839 74950839 010001014C000B00240000062C0000093AEEE320 E320 1
2
 005286328 00 1234567801 00DA 1B 1  95 74950839 74950839 010001014B000B00240000062C0000093BE85281 5281 1
3
 008486552 00 1234567801 00DA 1B 1  95 74950839 74950839 010001014C000B00240000062C0000093BEF5260 5260 1
4
 013286980 00 1234567801 00DC 1B 2  95 74950839 74950839 010001014A000B00240000062C0000093AE8C1A9 C1A9 1
5
 016487192 00 1234567801 00DE 1B 3  95 74950839 74950839 010001014B000B00240000062C00000939EA86F1 86F1 1
6
 021287296 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014B000B00250000062C00000938EA01FD 01FD 1
7
 024487512 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014B000B00250000062C00000937E5E02C E02C 1
8
 026085360 00 1234567801 00DA 1B 1  95 74950839 74950839 010001014B000B00250000062C00000937E5A904 A904 1
9
 026132564 00 1234567801 00DC 1B 2  95 74950839 74950839 82138700230000000103E9003B000858D3F33E3C 3E3C 1
10
 027687708 00 1234567801 00DC 1B 2  95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1
11
 029285564 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1
12
 029321264 00 1234567801 00DA 1B 1  95 74950839 74950839 82138700230000000103EA003B00081468072891 2891 1
13
 032486288 00 1234567801 00D8 1B 0  95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1
14
 035685728 00 1234567801 00DC 1B 2  95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1
15
 037285832 00 1234567801 00DE 1B 3  95 74950839 74950839 010001014C000B00250000062C00000938EDDA64 DA64 1
16
 037333012 00 1234567801 00D8 1B 0  95 74950839 74950839 82138700230000000103EB003B0008D01AB0655A 655A 1

von Thomas B. (tbnobody)


Lesenswert?

Marcel schrieb:
> Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power)
> pro Solar Panel oder ist das immer pro WR zusammengefasst?

Hallo Marcel,

bei dem oben genannten Account handelt es sich ja um einen öffentlichen 
Test-Account den jeder verwenden kann (Es handelt sich nicht um meine 
Anlage). Aktuell zeigt die Detailansicht (siehe Cloud-05.png) für jedes 
Panel unterschiedliche Watt angaben (33 vs. 32W). Spannung und Strom 
sind beim Klick auf die Panels identisch (32,5V und 1,0A).
Es kann sich hier natürlich auch um Rundungsungenauigkeiten handeln und 
Strom/Spannung/Leistung ist trotzdem individuell.

Bzgl. dem Hex Wert nach den WR Seriennummern... Dann müsste ich aber bis 
zu 4 Nachrichten erhalten, zumindest hat der HM-1500 vier individuelle 
Ports.

Grüße
Thomas

von martin (Gast)


Lesenswert?

Marcel schrieb:
> asierend auf deinen Daten, könnte ich mir
> vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar
> Panel Nummer ist.

Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele 
angeschlossen und an der Stelle nie eine 02 gesehen.

Eine andere Frage:
Habt ihr schon mal andere Anfagecodes ausprobiert, um andere Daten zu 
erhalten?
Ich habe bei der seriellen Aufzeichnung mindestens 3 verschiedene 
Anfragepakete gesehen:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

von Marcel (Gast)


Angehängte Dateien:

Lesenswert?

Martin schrieb:
>Marcel schrieb:
>> basierend auf deinen Daten, könnte ich mir
>> vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar
>> Panel Nummer ist.

> Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele
>angeschlossen und an der Stelle nie eine 02 gesehen.

Hallo,

okay, das ist schon mal ein guter Hinweiß. Die Daten für das 02 Command 
machten auch nicht so viel Sinn.

Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten 
passen bisher mit meinem Messungen.

Werde heute auch mal probieren andere Requests zu senden und schauen ob 
und was zurück kommt.

Marcel

von Thomas B. (tbnobody)


Lesenswert?

Marcel schrieb:
> Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten
> passen bisher mit meinem Messungen.

Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu 
bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor.

Du hattest einen HM-400 oder?

von Mag C. (magcode)


Lesenswert?

Marcel schrieb:
> Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten
> passen bisher mit meinem Messungen.

Danke für die Doku! Kann ich so bestätigen mit meinem HM-400.

von Martin G. (petersilie)


Lesenswert?

Sorry bin gerade krankheitsbedingt ziemlich außer Gefecht.
Hier sind mal die Logs von meinem HM-700 (2 Kanäle) für die letzten 2 
Tage:

- https://filetransfer.io/data-package/QBOaWm7M#link

Geloggt wie unter 
https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md#example-run 
beschrieben.

Wie viele Posts weiter oben ja entdeckt haben, sind die Antworten wohl 
je nach Wechselrichtertyp leicht unterschiedlich. Bei meinem sieht man 
plausibel die U, I, P-Werte für die beiden angeschlossenen Panels.

Vielleicht fällt jemand zu den "unknown"-Werten was ein - vielleicht 
sind das die gleichen, die bei anderen Wechselrichtern in den Feldern 
für das "2te Panel" stehen?

Kandidaten sind u.a. Tages- und Gesamtenergie (in Wh) sowie die 
Temperatur (in Zehntel-°C).

Als "Auslöser" für die Antworten sende ich bisher wohlgemerkt nur im 
Sekundentakt eine 0x80-Nachricht. Das scheint ausreichend häufig zu 
einer Rückmeldung zu führen.

: Bearbeitet durch User
von Martin G. (petersilie)


Lesenswert?

So aus dem Bauch raus würde ich für CMD=0x02 mal tippen:

- uk4, uk5: Tages-Energie Panel 1, 2 [Wh] (läuft am nächsten Tag wieder 
mit 0 los)
- uk1, uk3: Gesamt-Energie seit Geburt (?), Panel 1, 2 [Wh]

von Martin G. (petersilie)


Lesenswert?

...und dann gibt es noch die mysteriöse 0x83-Antwort. Über die beiden 
Tage verteilt kam die nur 49 mal:
1
$ cat two-days-hm-700.log | grep '95 74 60 81 45 74 60 81 45 83' | cut -b 28-
2
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e8 00 67 00 06 86 06 1e
3
: 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 75 00 06 4f ee 3f
4
: 95 74 60 81 45 74 60 81 45 83 00 00 00 17 03 e8 00 7c 00 06 94 08 0c
5
: 95 74 60 81 45 74 60 81 45 83 00 01 00 23 03 e8 00 91 00 06 3d a0 d5
6
: 95 74 60 81 45 74 60 81 45 83 00 01 00 29 03 e8 00 9e 00 06 d5 43 db
7
: 95 74 60 81 45 74 60 81 45 83 00 01 00 2d 03 e8 00 a3 00 06 51 61 44
8
: 95 74 60 81 45 74 60 81 45 83 00 01 00 32 03 e8 00 a5 00 06 5f 15 27
9
: 95 74 60 81 45 74 60 81 45 83 00 01 00 40 03 e8 00 b2 00 06 90 be 26
10
: 95 74 60 81 45 74 60 81 45 83 00 00 00 65 03 e8 00 d3 00 06 4d f8 f8
11
: 95 74 60 81 45 74 60 81 45 83 00 00 00 5e 03 e8 00 eb 00 06 a9 9c 7b
12
: 95 74 60 81 45 74 60 81 45 83 00 00 00 5d 03 e8 00 f3 00 06 08 dc 81
13
: 95 74 60 81 45 74 60 81 45 83 00 01 00 41 03 e8 00 f8 00 06 58 71 6a
14
: 95 74 60 81 45 74 60 81 45 83 00 00 00 5a 03 e8 01 00 00 06 03 6e cd
15
: 95 74 60 81 45 74 60 81 45 83 00 03 00 a3 03 e8 01 1b 00 06 a1 88 68
16
: 95 74 60 81 45 74 60 81 45 83 00 00 00 82 03 e8 01 57 00 06 9a ef 5a
17
: 95 74 60 81 45 74 60 81 45 83 00 02 00 61 03 e8 01 75 00 06 9e 7f 0d
18
: 95 74 60 81 45 74 60 81 45 83 00 02 00 6d 03 e8 01 5b 00 06 0f b5 74
19
: 95 74 60 81 45 74 60 81 45 83 00 02 00 52 03 e8 01 4d 00 06 2e 30 f9
20
: 95 74 60 81 45 74 60 81 45 83 00 00 00 4a 03 e8 01 4e 00 06 4d ef 5c
21
: 95 74 60 81 45 74 60 81 45 83 00 00 00 47 03 e8 01 4d 00 06 5e 07 a9
22
: 95 74 60 81 45 74 60 81 45 83 00 01 00 44 03 e8 01 4c 00 06 ac 22 7d
23
: 95 74 60 81 45 74 60 81 45 83 00 01 00 27 03 e8 01 2b 00 06 45 4e fc
24
: 95 74 60 81 45 74 60 81 45 83 00 00 00 15 03 e8 01 13 00 06 c3 c5 fa
25
: 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 01 07 00 06 55 2f 96
26
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 fd 00 06 83 78 f6
27
: 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 78 00 06 8f ef 08
28
: 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 7b 00 06 25 2a 64
29
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7f 00 06 b3 43 77
30
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7e 00 06 35 4f fc
31
: 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 ea 00 82 00 06 ed 4b df
32
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 8b 00 06 1c 6e 0d
33
: 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 8f 00 06 ae 48 83
34
: 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 90 00 06 a6 5e 82
35
: 95 74 60 81 45 74 60 81 45 83 00 00 00 13 03 e8 00 92 00 06 70 46 4c
36
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 9c 00 06 38 74 24
37
: 95 74 60 81 45 74 60 81 45 83 00 00 00 16 03 e8 00 9d 00 06 c8 67 df
38
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a0 00 06 5d 79 71
39
: 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 a3 00 06 c5 e0 64
40
: 95 74 60 81 45 74 60 81 45 83 00 00 00 12 03 e8 00 ae 00 06 85 5a 98
41
: 95 74 60 81 45 74 60 81 45 83 00 00 00 07 03 e8 00 aa 00 06 ca b1 2d
42
: 95 74 60 81 45 74 60 81 45 83 00 00 00 08 03 e8 00 a5 00 06 88 74 aa
43
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 a3 00 06 55 16 10
44
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0a 03 e8 00 9c 00 06 c0 56 fb
45
: 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 9b 00 06 82 e1 13
46
: 95 74 60 81 45 74 60 81 45 83 00 00 00 09 03 e8 00 9d 00 06 10 5d 22
47
: 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 9c 00 06 ef a9 38
48
: 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a4 00 06 cd e2 7e
49
: 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 a1 00 06 b5 ce 31
50
: 95 74 60 81 45 74 60 81 45 83 00 00 00 04 03 e8 00 9d 00 06 0f ac c1

Vielleicht ist da was bzgl. Kanal-Hopping drin? Hat jemand Ideen?

von Marcel (Gast)


Lesenswert?

Hallo Thomas,

> Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu
> bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor.

Diese Antwort kommt bei mir so mehrmals auf 0x15er Request zurück
1
Send to channel: 40
2
Time Wed Mar 30 14:56:30 2022
3
4
Sending packet of size: 27
5
Now sending: 15 73 10 90 25 72 81 90 05 80 0B 00 62 44 6F 9E 00 00 00 05 00 00 00 00 94 87 EF  ok...
6
Listen channel: 3
7
Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 82 00 1C 00 6C 00 00 41 C6 01 18 08 F7 07  
8
Got reply: 
9
        Voltage: 38.60V, Ampere: 0.28A, Power: 10.80W
10
        Daily production: 280.000 W, AC Voltage: 229.5 V, Total production: 16.838 kW
11
        Frequency: 0.000, Temperature: 0.0 °C
12
Received: 95 73 10 90 25 73 10 90 25 82 13 87 00 67 00 00 00 04 03 E8 00 FE 00 06 BB 44 0C  
13
Got reply: 
14
        Voltage: 0.00V, Ampere: 0.00A, Power: 0.00W
15
        Daily production: 0.000 W, AC Voltage: 0.0 V, Total production: 0.000 kW
16
        Frequency: 49.990, Temperature: 25.4 °C
17
This round is over.

Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief 
wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die 
wichtigen Teile des Codes in mein Programm kopiert. Das gibt mir die 
Möglichkeit mit dem Code zu spielen, da ich auch alle Teile davon genau 
verstehe. Ebenfalls setze ich auch immer die korrekte Zeit (vielleicht 
ist es das).

Mein Script sendet den Request und hört dann 3 Sekunden auf dem Kanal 3. 
Dann wartet es erneut 3 Sekunden und beginnt von vorne.

> Du hattest einen HM-400 oder?

Genau.

Ich habe jetzt auch einen zweiten ESP32 mit einem NRF Chip und die habe 
ich jetzt so synchronisiert, das der eine eine Message sendet und der 
andere dann zur gleichen Zeit verschiedene Kanäle durch hört. Ich hoffe, 
das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber 
vorstellen, das es eine Weile dauert.

Marcel

von noreply@noreply.com (Gast)


Lesenswert?

martin schrieb:
> Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele
> angeschlossen und an der Stelle nie eine 02 gesehen.

Schaut mal in die Wechselrichter nach, ob die tatsächlich 2 seperate 
MPPT-Tracker habe könnten. Bei meinen SG700 werden die 2 Eingänge für 
die Module intern gebrückt.

von B. G. (golf2010)



Lesenswert?

Marcel schrieb:
> Ich hoffe,
> das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber
> vorstellen, das es eine Weile dauert.

Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen.
Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83  auf 
bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der 
Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz 
von den dreien kommen.
Wenn eine andere Sendefrequenz genutzt wird, dann sind das bei mir 3 
andere mögliche Antwortfrequenzen. z.b noch die 2475 Mhz.
Nochmal das jpg mit Kommentaren.

von Marcel (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe jetzt mal die Messages auf Kanal 40 gesendet und dann alle 
Kanäle einzeln von 1 - 128 für 3 Sekunden gehört. Da kam nie was, ausser 
eben auf Kanal 3.

Ebenfalls habe ich mal mit der Anfrage bits rumgespielt. Es kommen zwar 
bei einigen Kombinationen Antworten, aber die machen bisher noch keinen 
Sinn.

Hab die Daten mal angehängt.

Marcel

von Oliver F. (of22)


Lesenswert?

Marcel schrieb:
> Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief
> wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die
> wichtigen Teile des Codes in mein Programm kopiert.

Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 
schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack 
Overflows kämpfe.
- Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit 
PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die 
ganzen Libraries quält. Ist das normal?
- Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme 
gab es?

B. G. schrieb:
> Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen.
> Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83  auf
> bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der
> Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz
> von den dreien kommen.

Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61?
Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger 
mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80 
gelauscht.
Meine WR antworten nur auf Kanal 3 und 23.
Die DTU sendet abwechselnd auf:
0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61.
Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung 
abhängen? z.B. auf welchem Kanal WLAN aktiv ist?

von Marcel (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Oliver

> Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328
> schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack
> Overflows kämpfe.
Do it :)

> - Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit
> PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die
> ganzen Libraries quält. Ist das normal?

Also ich nutze auch Visual Studio Code mit der PlatformIO extension. 
Wenn bei mir alles ein mal gebaut ist, dann dauert das neu kompilieren 
unter 1sec. Das Hochladen und den Boot Button zu drücken ist das was am 
längsten dauert :). Ich hänge mal mein Programm hier mit an. Ist alles 
in einer Datei und ich nutze keine eigene CRC Berechnung, sondern eine 
externe offizielle Libs. Sobald alles einigermaßen geht, würde ich den 
Code dann sauber machen. Aber derzeit bin ich so schneller.

> - Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme
> gab es?

Um ehrlich zu sein, habe ich es noch nie hinbekommen Circular Buffer auf 
meinen ESPs zum laufen zu bekommen (ist aber auch schon Jahre her das 
ich es probiert habe). Soweit ich mich erinnern kann, muss man auf dem 
ESP Circular Buffer anders initialisieren und es gibt Probleme, die man 
beachten muss, mit irgendwelchen Integer Größen, die anders auf einem 
Nano und einem ESP32 sind. Bin mir da aber nicht mehr sicher. Ist 
wirklich schon sehr lange her und ich baue es immer um, wenn ich 
Circular Buffer sehe.

Marcel

von Mag C. (magcode)


Lesenswert?

Hallo, ich habe auf Basis des Arduino Sketch ein kleines MQTT Gateway 
geschrieben (in JAVA) und teste die nächsten Tage.


Nun frage ich mich wo die Reise hingeht. Ich persönlich finde folgendes 
Setup clever:

Microcontroller (Arduino oder ESP ohne aktivem WIFI) und RF als relativ 
"dumme Empfängerhardware" mit USB Anschluss.
Die "Software" (nodeJS, python, java oder auch Plugins für 
Homeautomation Systeme) dann auf einem beliebigen Computer (Raspi, 
Windows, Linux, Mac) laufen lassen.
Die meiste "Intelligenz" ist in der "Software". Dies betrifft das Parsen 
der Daten sowie das Aufbereiten und versenden via MQTT. Falls die 
verschiedenen Hoymiles tatsächlich unterschiedliches Parsing erfordern, 
ist es m.E. einfacher das in der "Software" anzupassen (anstatt C code 
schreiben und Firmware Flash).
Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den 
Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte.


Wie ist Eure Meinung?

von Marcel (Gast)


Lesenswert?

Hallo Mag,

ich finde schon, das es einen "Treiber" geben sollte der ein 
einheitliches Interface hat (unabhängig vom verwendetem Hoymiles). So 
wie du das beschreibst, klingt es ja wie ein Open MQTT Gateway 
Integration, die deine Anfrage in das jeweilige Protokoll (LORA oder 
dann eben Hoymiles umwandelt). Dann muss die Logic, in der Tat irgendwo 
anders sein.

Ich persönlich würde eine ESPHome Version bauen, die dann die Werte 
ebenfalls - in einem einheitlichem Format - via MQTT oder HomeAssistant 
API wegschreibt.

Höre aber auch sehr gerne andere Meinungen :)

Marcel

von B. G. (golf2010)


Lesenswert?

Oliver F. schrieb:
> Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61?
> Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger
> mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80
> gelauscht.
> Meine WR antworten nur auf Kanal 3 und 23.
> Die DTU sendet abwechselnd auf:
> 0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61.
> Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung
> abhängen? z.B. auf welchem Kanal WLAN aktiv ist?

Ich hab das vielleicht falsch beschrieben. Nicht mein DTU sendet auf 
2403, sondern mein Atmel, der mir als DTU-Ersatz dient. Dein 
Original-DTU wechselt wohl schon die Sendefrequenzen. Ich bleibe mit 
meinem AVR beim Senden immer auf einer gleichen Frequenz ( 2403) und 
dann antwortet der WR mir immer mit den Telegrammen 01,02,80 auf den 
maximal 3 Frequenzen 2423,2440,2461, siehe jpg. Wenn ich eine andere 
Sendefrequenz nehme, dann antwortet der WR z.b. auf 2475 2423 und 2403.

Aber mir scheint es, daß es vielleicht auch Unterschiede bei den 
jeweiligen WRs gibt. Ich selbst habe einen HM-600

von Marcel (Gast)


Lesenswert?

Hallo,

ich glaube die Bytes von den Seriennummern der Wechselrichter werden 
berücksichtigt. Wenn ich hier mal die letzten Daten anschaue und die 
Texte mit den Angaben zu dem Versionen der Wechselrichter lese, ergibt 
sich ein Muster. Ich denke, dieses Byte kann dazu genutzt um die 
Antworten auszuwerten. Weil meine HM-400 Antwort hat Fundamental andere 
Werte als die von einem HM-600 (Ampere, Volt etcpp).


Vielleicht kann ja jeder, der demnächst hier schreibt, seine Version des 
Wechselrichters (HM-XXX) reinschreiben und seine Seriennummer? Dann kann 
man meine These mal validieren.
1
HM-1500:
2
 - 71 60 35 46
3
HM-700:
4
 - 74 60 81 45
5
HM-600: 
6
 - 72 22 02 00 
7
HM-400: 
8
 - 73 10 90 25

Es sieht fast so aus, als wenn jede Version eines erste Byte hat.

Marcel

von Mag C. (magcode)


Lesenswert?

HM-400:
 - 74 95 08 39

von Marcel A. (a-marcel)


Lesenswert?

> 74 95 08 39

Verdammt :D Die passt nicht ins Schema.

Wobei die DTU ja die ganze Seriennummer kennt. Ggf. ist den ersten 4 
Zahlen die Version kodiert.

Meine wäre dann für den HM-400 Serial No: 1121 73109025

Marcel

: Bearbeitet durch User
von Thomas B. (tbnobody)


Lesenswert?

Schaut mal hier (Kapitel 6):

https://www.manualslib.de/manual/793350/Hoymiles-Mi-300.html?page=16#manual

Mit den ersten 4 Zeichen scheint man wohl Inverter als auch Version 
identifizieren können...
1
Fehlersuche
2
Hoymiles hat die interaktive Leistung des Mikroumwandlersystems Mitte 2020 aktualisiert.
3
Wenn Sie den Mikroumwandler mit Seriennummer "1022xxxxxxxx" verwenden, so beziehen Sie
4
sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikroumwandler mit
5
Seriennummer "1020xxxxxxxx" und "1021xxxxxxxx" verwenden, so beziehen Sie sich bitte auf
6
Abschnitt 6.2 und Abschnitt 6.4.
7
*Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von
8
Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und
9
DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren.


Gleiches gibt es wohl auch für die größere Reihe: 
https://www.manualslib.de/manual/811724/Hoymiles-Mi-1000.html?page=17#manual
1
Fehlersuche
2
Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems Mitte 2020 aktualisiert.
3
Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" verwenden, so beziehen
4
Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikrowechselrichter mit
5
Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen Sie sich bitte auf
6
Abschnitt 6.2 und Abschnitt 6.4.
7
*Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von
8
Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und
9
DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren.

: Bearbeitet durch User
von Mag C. (magcode)


Lesenswert?

Hm-400
11 21 74 95 08 39

von Thomas B. (tbnobody)


Lesenswert?

HM-1200
1161xxxxxxxx

HM-1500
1161xxxxxxxx

von Marcel A. (a-marcel)


Lesenswert?

Sehr gut,

das hilft schon mal wenn wir weitere Daten analysieren und später um den 
Parser zu schreiben. Ich denke mal, das die ersten 4 Ziffern immer eine 
Gruppe beschreiben und die Antworten im gleichen Format sind.

Danke
Marcel

von B. G. (golf2010)


Lesenswert?

Hm-600    11 41 xx xx xx xx

von isnoAhoy (Gast)


Lesenswert?

Hallo Zusammen,

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

Das mit den og. unterschiedlichen Versionen der Wechselrichter und DTUs 
könnte mit dem verbauten NRF24L01+ Chip gegenüber den bei Seriennummer 
1062x, bzw. DTU-Pro, DTU-G100 und DTU-W100 vermutlich verbauten NRF5x 
Chip zusammenhängen.

Folgendes Zitat aus dem Enhanced ShockBurst (ESB) Dokument scheint die 
beiden Modi und Kombinationen zu erklären:

Enhanced ShockBurst (ESB) - Features
https://developer.nordicsemi.com/nRF_Connect_SDK_dev/doc/PR-3842/nrf/ug_esb.html

* 1 to 32 bytes dynamic payload length in legacy mode
* 1 to 252 bytes static payload length between nRF5 Series devices

von Mo (Gast)


Lesenswert?

HM300: 11 21 71 ...

von Martin P. (mpolak77)


Lesenswert?

HM-350: 1121 72xxxxxx
HM-700: 1141 74xxxxxx

von Chris A. (cherio7)


Angehängte Dateien:

Lesenswert?

HM 1200

1161 70523283

ich habs mal einen Tag lang laufen lassen und sehe 4 arten von Antworten
hab sie mal beigefügt.

: Bearbeitet durch User
von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht 
und nach Bildern von Hoymiles Wechselrichtern mit Seriennummern gesucht.
Ebenfalls habe ich die Seriennummern aus diesem Thread verwendet.
Das Ergebnis, insgesamt 29 WR, befindet sich im Anhang. Als Bild habe 
ich noch das Ergebnis angehängt. Also das Mapping zwischen Typ und 
Prefix. Das sieht erstmal recht eindeutig aus.

von Mag C. (magcode)


Lesenswert?

Hier ist noch ein HM-800 :-) -> 1141
https://youtu.be/FL7BI6b4-00?t=139

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Mag C. schrieb:
> Hier ist noch ein HM-800 :-) -> 1141

Danke für den Hinweis :)
Habe ich noch in das Ergebnis aufgenommen (siehe Anhang).
Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten 
auch die Telegramme der farbig markierten Inverter kompatibel sein.

von Marcel A. (a-marcel)


Lesenswert?

Hallo Thomas,

> ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht

Das ist natürlich clever und erheblich effizienter als hier zu fragen. 
Chapeau

> Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten
> auch die Telegramme der farbig markierten Inverter kompatibel sein.

Davon gehe ich auch aus.

In hab mir vorhin noch mal den Thread durchgelesen und dabei die Bilder 
von der geöffnetem DTU angeschaut. Darin ist ja scheinbar eine RTC 
verbaut. Da ich in den vergangenen Tagen ein einziges mal wirklich aller 
60 Sekunden für einen längeren Zeitraum konstant Antworten vom WR 
bekommen habe, kann es sein, das der WR ggf. den Timestamp und die 
differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren 
ggf. die Uhren meiner ESP32 und des WR grob syncron.

Was denkt Ihr ?

Ebenfalls habe ich mich mal in das Konzept von channel hopping (grob) 
eingelesen und eine synchronisierte Zeit oder Tackt ist dabei wohl 
essentiell.

Ich hab vor ein paar Minuten mal ein RTC DS3231 an meinen ESP geklemmt 
und den code so verändert, das die Zeit immer von der RTC kommt. 
Vielleicht klappt es ja morgen bei Sonne.

Marcel

von Comix (Gast)


Lesenswert?

Hallo,
hab nen HM-1200 116172216067

Tolles Projekt
bin mal auf das Ergebnis gespannt.

von Hubi (Gast)


Lesenswert?

Mag C. schrieb:
> Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den
> Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte.

Da ich weder MQTT noch ESPHome oder sonstige Home-Automation nutze, wäre 
gerade das zitierte meine Lösung. Bei mir laufen mehrere ESPs und als 
Master fungiert ein RasPi, der mittels cron-Jobs die Daten von den ESPs 
sammelt, speichert, auswertet, grafisch darstellt, ...

Zu der "Software" : die brauch man nur einmal zu entwickeln, die 
Auswertung der empfangenen Daten könnte man über eine Tabelle (im 
EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so 
aussehen:
1141 HM-600 AC-Spannung 02 12 2 10
bedeutet: Die Wechselspannung ist im Telegramm 02, beginnt ab Byte 12, 
ist 2 bytes lang und muss noch durch 10 geteilt werden.
Wenn das Projekt so richtig in Software umgesetzt wird (Github), hätte 
ich folgenden Vorschlag:
1) Die Kommunikation in einen Kern packen, der für Arduino, ESP, RasPi 
passt, am besten in C.
2) Funktionalität darüber hinaus in Plugins packen, die man über #define 
mit dazu linkt. Weitere Funktionalität wären zB: MQTT, ESPHome, Display, 
Webserver, Upload, ...

von Martin G. (petersilie)


Lesenswert?

Marcel A. schrieb:
> kann es sein, das der WR ggf. den Timestamp und die
> differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren
> ggf. die Uhren meiner ESP32 und des WR grob syncron.

Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer 
konstanten 0x80-Anfrage (jede Sekunde) laufen:
1
15 74 60 81 45 78 56 34 12 80 0b 00 62 46 d3 0f 00 00 00 05 00 00 00 00 92 ea c3

Er scheint damit genauso häufig zu antworten wie zuvor, als ich jede 
Sekunde die aktuelle Uhrzeit mitgeschickt hatte (siehe 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?").

von Martin G. (petersilie)


Lesenswert?

Mag C. schrieb:
> Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den
> Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte.

Meine Interessen liegen da ähnlich, ich komme eher aus der 
RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für 
verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an 
seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen.

Das nette daran ist, dass man insbesondere während der 
Experimentierphase sehr einfach Anpassungen machen kann, ohne dass man 
immer gleich einen Controller neu flashen muss.

Aber na klar gibt es auch gute Gründe für Arduino/ESP32 
Implementierungen. Unsere Forschungen hier sind für beide Ansätze 
gleichermaßen hilfreich.

Habe soeben nochmals die in Entstehung befindliche `ahoy` 
Python-Software aktualisiert, diese sendet jetzt die empfangenen Daten 
gleich via MQTT raus.

* https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py

von Marcel A. (a-marcel)


Lesenswert?

Hallo petersilie,

> Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer
konstanten 0x80-Anfrage (jede Sekunde) laufen:

Ja, ich habe meinen Logger mit RTC seit heute morgen laufen und sehe 
ebenfalls keine Besserung in der Antworthäufigkeit :/


Marcel

von B. G. (golf2010)



Lesenswert?

Logs von meinem HM-600, auf die Schnelle ein altes Projekt umgeändert.

von martin (Gast)


Angehängte Dateien:

Lesenswert?

Hubi schrieb:
> Zu der "Software" : die brauch man nur einmal zu entwickeln, die
> Auswertung der empfangenen Daten könnte man über eine Tabelle (im
> EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so
> aussehen:
> 1141 HM-600 AC-Spannung 02 12 2 10

Hallo Hubi,
ich bin mir nicht sicher, ob dass so einfach möglich ist. In meinen 
Daten von früher habe ich gesehen, dass die gleiche Paket-ID wohl 
verschiedene Inhalte haben kann, je nach dem welcher Request zuvor kam 
(siehe Bild oder früherer Post):
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Anscheinend kommt es auf die vorige Abfrage an. Allerdings habe ich das 
bisher nicht in den Funk-Daten beobachtet, die Mitschnitte in der Excel 
sind von der DTU-internen seriellen Kommunikation.

Kann das jemand verifizieren?

von Sergey S. (sergey_s632)


Lesenswert?

Guten Tag! Ich habe H M 600 114170810815
und DTU W100 10D 373114359. Kann mir jemand helfen, die 
“S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer 
gibt es nicht an, sagt, dass er selbst der Installateur ist.

von Waldemar K. (wwkk)


Lesenswert?

Hello All.

I just bought 3 x Hoymiles HW1500 for my PV installation.
I will install them within one month.

How could I contribute to your project to proceed with creating a 
reverse-engineered and open source solution to communicate with those 
micro inverters.

I have some SDR usb dongle available to put it to work as well.

Kind regards
WK

von Heinz R. (heijz)


Lesenswert?

Martin G. schrieb:
> Meine Interessen liegen da ähnlich, ich komme eher aus der
> RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für
> verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an
> seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen.

Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder 
ESP32 zur Verfügung stellen könnte

Raspi, schön und gut - aber meiner ist zu weit weg vom WR - gerade die 
Hoymiles-WR sind ja eigentlich dafür gedacht auf dem Dach montiert zu 
werden?

von mtet (Gast)


Lesenswert?

Sergey S. schrieb:
> Guten Tag! Ich habe H M 600 114170810815
> und DTU W100 10D 373114359. Kann mir jemand helfen, die
> “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer
> gibt es nicht an, sagt, dass er selbst der Installateur ist.

Hallo,
eventuell können die helfen:
https://www.enercab.at/hoymiles/1067-hoymiles-pv-monitoring-dtu-wlite.html
Dort ist eine +49er Telefonnummer vorhanden.

Mein HM600 SNR: 114172609296 wartet noch auf die PV-Module.

von Thomas B. (tbnobody)


Lesenswert?

Heinz R. schrieb:
> Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder
> ESP32 zur Verfügung stellen könnte

Mein Plan wäre eine Library aka. https://github.com/atc1441/NETSGPClient

Durch die NRF24 Library wäre dies dann vmtl. auch sowohl für ESP32 als 
auch ESP8266 nutzbar (und mit etwas Glück auch nativ unter Linux). Was 
man außen rum baut ist wieder ein ganz anderes Thema. Aber wie 
@petersilie schon sagt, die Grundlegenden Dinge die aktuell laufen 
eignen sich sowohl für Python als auch für eine C Implementierung. 
Erstmal muss man allgemein verstehen was passiert :)

Habe heute einen ganzen Tag mitgelogged und werde das jetzt Auswerten. 
Spontan sehe ich aber nur 01er, 02er und 03er Nachrichten. (Gepulled 
habe ich die Daten mit dem ahoy.py Script)

von Martin G. (petersilie)


Lesenswert?

Waldemar K. schrieb:
> How could I contribute to your project to proceed with creating a
> reverse-engineered and open source solution to communicate with those
> micro inverters.
>
> I have some SDR usb dongle available to put it to work as well.

Hello Waldemar, and welcome!
One of the unsolved mysteries is how the inverters and DTU "hop" between 
different frequencies. Maybe scans with your SDR dongle can help.

von Martin G. (petersilie)


Lesenswert?

Ich habe mal wieder das Format-Beschreibungs-Dokument aktualisiert.

Leider immer noch ein bisschen durcheinander und unvollständig. Falls 
jemand Lust hat, hier mitzuhelfen - gerne melden!

https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt

: Bearbeitet durch User
von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Martin G. schrieb:
> Falls
> jemand Lust hat, hier mitzuhelfen - gerne melden!

Gerne. Ich bin dir gerade auch schon auf github gefolgt.

Also 0x83 Nachrichten sehe ich bei mir garnicht. Das ahoy.py Script 
liefert bei mir wie gesagt 1-3er Nachrichten. Ich habe in der Excel 
Datei im Anhang mal 3 Sheets gemacht. Für jede Nachricht eines. Ich habe 
aktuell am HM-1500 nur 3 Panels. Daher sollte irgendein Wert null sein. 
(Muss morgen mal prüfen welcher Kanal genau nicht angesteckt ist)

Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x 
übertragen, der Strom und die Leistung jedoch 4x.

Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung 
ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw. 
geben aktuell Sinn. (bzw. ich sehe es gerade nicht)

von Heinz R. (heijz)


Lesenswert?

Thomas B. schrieb:
> Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x
> übertragen, der Strom und die Leistung jedoch 4x.

Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel

Deshalb evtl. nur 2 Messwerte?

von Sergey S. (sergey_s632)


Lesenswert?

Heinz R. schrieb:
> Thomas B. schrieb:
>> Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x
>> übertragen, der Strom und die Leistung jedoch 4x.
>
> Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel
>
> Deshalb evtl. nur 2 Messwerte?

Und HM-600 auch zwei?

von Carsten B. (carstenb)


Lesenswert?

Sergey S. schrieb:
> Und HM-600 auch zwei?
Ja der HM-600 hat 2 Eingänge mit separaten MPT. Ich hoffe, dass ich dies 
Wochenende meines Setup endlich soweit bekomme, dass ich auch an meinem 
HM-600 lauschen kann...

von Martin G. (petersilie)


Lesenswert?

Thomas B. schrieb:
> Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung
> ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw.
> geben aktuell Sinn. (bzw. ich sehe es gerade nicht)

Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem 
HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten:

- Spalte T: Energie [Wh] seit letztem Start
- Spalte S: aktuelle AC-Leistung [W]
- Spalte R: Energie [Wh] seit Geburt
- Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum?
- Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung
  um die 0,6°C/0,7°C kalt?

von Mag C. (magcode)


Angehängte Dateien:

Lesenswert?

Hallo,

Ich habe mal ein paar Daten des HM-400 aufgezeichnet zum Vergleich mit 
meinem AC-seitigen Shelly Plus 1PM. Sieht alles sehr gut aus!

Das Setup mit Nano (FDTI Version) und nRF24L01+ zieht sich übrigens etwa 
0,35W aus dem USB.
Die Scanhäufigkeit habe ich verringert auf ca. 1 mal pro Minute.
Ich nutze "RF24_PA_MIN"

von Peter L. (leliep)



Lesenswert?

Es gibt ein Dokument mit der Modbus-Beschreibung. Evtl. helfen die dort 
vorhandenen Beschreibungen der Telegramme und Befehle.

Quelle:
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

von Thomas B. (tbnobody)


Lesenswert?

Martin G. schrieb:
> Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem
> HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten:
>
> - Spalte T: Energie [Wh] seit letztem Start
> - Spalte S: aktuelle AC-Leistung [W]
> - Spalte R: Energie [Wh] seit Geburt
> - Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum?
> - Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung
>   um die 0,6°C/0,7°C kalt?

Hallo Martin,
An dem Tag von dem die Aufzeichnung stammt hat ein Gosund 
Zwischenstecker ca. 1kWh gemessen. Die Gesamtproduktion die die Gosund 
gemessen hat seit Inbetriebnahme des Inverters liegt bei ca. 240kWh.
  - Spalte T: Wäre damit zu hoch, und ich würde eher einen Kommawert 
erwarten
  - Spalte S: Nachdem es ein ganzer Tag ist hätte ich einen ähnlichen 
Verlauf wie bei den DC Kurven erwartet. Also erst steigend, dann 
fallend.
  - Spalte R: Kommt mir für den Gesamtertrag zu hoch vor
  - Spalte P: Ggf. sind das auch Werte um 200 herum wenn man den Wert 
statt durch 10 durch 100 teilt. Muss ich beobachten wie sich das heute 
entwickelt. (Ggf. Gesamtleistung seit Geburt, dann würde aber der Gosund 
Mist messen)
  - Spalte E: Hätte die Temperatur v.a. unterm Tag eher im Bereich 5-10 
Grad geschätzt.

von Martin P. (mpolak77)


Lesenswert?

Marcel schrieb:
> Hallo Oliver
>
>> Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328
>> schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack
>> Overflows kämpfe.
> Do it :)

Hallo Marcel,

ich habe deinen Code mit einem ESP8266 Nodemcu am laufen:

-musste das getLocalTime(..) nachimplementieren, weil das das nur am 
ESP32 gibt
-musste natürlich die Pins ändern
-musste in der Receive-Loop ein yield(); einbauen, da sonst der wdt 
getriggert hat.

habe meine WR und DTU Serial eingetragen ....
.... sehe auf den Request zwar ein "ok"
.... dann kommt aber keine Antwort vom WR

von Carsten B. (carstenb)


Lesenswert?

Hurra, es hat geklappt :)

Ich empfange jetzt stabil Daten vom HM-600 aus etwa 15m Distanz.

Setup:
* HM-600 S/N 114172014650
* Arduin0 Nano V3
* NRF24L01 + separater Spannungsregler (damit geht bei mir RF24_PA_HIGH 
ohne Probleme)
* Software von 
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

Hilft es weiter, wenn ich einfach mal laufen lasse und den Output 
protokolliere und hochlade?

von Thomas B. (tbnobody)


Lesenswert?

Carsten B. schrieb:
> Hilft es weiter, wenn ich einfach mal laufen lasse und den Output
> protokolliere und hochlade?

Auf jeden Fall. Damit kann man das über einen längeren Zeitraum 
betrachten. Das macht es einfacher die Werte und Felder in den 
Telegrammen zu bestimmen!

von Solarliebhaber (Gast)


Lesenswert?

Hallo,

ich habe,
HM-1200
3*350 W Panels angeschlossen
Arduin0 Nano V3
NRF24L01 +

Ich koennte auch Daten sammeln, helfen.
Was muss ich tun um dieses Setup zum Fliegen zu bringen.
Kurzanleitung moeglich?
Danke

von Martin P. (mpolak77)


Lesenswert?

Ich hätte jetzt je eine Version von
-NR24_SendRcv
-Marcel's ESP32 code

der auch auf ESP8266/Nodemcu kompiliert und läuft. Wenn das für noch 
jemanden von Interesse ist bitte melden.

von Heinz R. (heijz)


Lesenswert?

Hallo Martin,

ich hätte großes Interesse an der ESP-Version.

Versuche mich hier gerade an einem Arduino Mini Pro - bekomme den in 
Platformio nicht geflasht...
ESP8266 würde es evtl einfacher machen

Viele Grüße

von Carsten B. (carstenb)


Lesenswert?

Auf die Schnelle:

Hardware

Nano V3 pin --- pin NRF24L01
D2  ----------- IRQ
D6  ----------- CSN
D9  ----------- CE
D11 ----------- MISO
D12 ----------- MOSI
D13 ----------- SCK

Software: 
https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv

Ich habe es im Arduino IDE übersetzt und hochgeladen

Seriennummer des HM musst du im Sourcecode eintragen wie folgt 
(NRF24_sniff.cpp):
#define WR1_RADIO_ID ((uint64_t)0x5046017201ULL) // WR1 HM-600

Das ist sind die letzten 4 Byte der S/N Rückwärts plus eine 01 am Ende. 
Meine S/N ist 114172014650

von Heinz R. (heijz)


Lesenswert?

Carsten B. schrieb:
> Ich habe es im Arduino IDE übersetzt und hochgeladen

welche Datei lädst Du hier in der Arduino IDE?
Müsste es hierzu nicht eine .ino geben

von Martin P. (mpolak77)


Angehängte Dateien:

Lesenswert?

Heinz R. schrieb:
> ich hätte großes Interesse an der ESP-Version.

Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die 
Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann 
trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von 
Links nach rechts ein ... das 5. byte muss 01 sein.

Ich habe den Code auf das originale CircularBuffer vom Arduino portiert, 
deshalb sind hier auch weniger Files dabei als im GitHub Link von weiter 
oben. Es sollte auch für Arduino Nano / Uno weiter kompilieren.

von Martin P. (mpolak77)


Angehängte Dateien:

Lesenswert?

...hier ein scan von meinen 2 (HM-350 und HM-700) WR

von Carsten B. (carstenb)


Lesenswert?

Heinz R. schrieb:
> Müsste es hierzu nicht eine .ino geben

Ich habe sie einfach umbenannt...

von Heinz R. (heijz)


Lesenswert?

Carsten B. schrieb:
> Ich habe sie einfach umbenannt...

Ach das geht?  lass uns das gerne mal in einem separaten Thread 
erörtern? :-)

von Carsten B. (carstenb)


Angehängte Dateien:

Lesenswert?

Thomas B. schrieb:
> Auf jeden Fall. Damit kann man das über einen längeren Zeitraum
> betrachten. Das macht es einfacher die Werte und Felder in den
> Telegrammen zu bestimmen!

Hallo in die Runde,

Angehängt die Daten, die ich heute mitgeschrieben habe mit dem HM-600. 
Zwischendrin hat der Nano 2x kurz neu gestartet (Wackelkontakt), die 
Bereiche ggf.raus löschen.

Ich bin grade dran, das mit der Excel, die hier gepostet wurde ein wenig 
auszuwerten. Mit den "01" Messages bin ich fertig und komme zu dem 
Ergebnis auf dem angehängten Sreenshot.

Spalte T enthält die addierten Leistungswerte bei der DC-Anschlüsse. 
Passt grafisch ganz gut überein mit dem, was mein Shelly heute auf der 
AC-Seite mitgeloggt hat.

Ich poste nachher noch meine Auswertung für die weiteren Messages.

Viele Grüße

Carsten

: Bearbeitet durch User
von Chris A. (cherio7)


Angehängte Dateien:

Lesenswert?

Hier mal ein Tageslog von meinem HM-1200

es sind 2x 19V Panels in reihe je 130W an einem der 4 Anschlüsse dran.
Das ergebniss passt noch nich ganz zu der format description.

Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert?
bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, 
was kann das sein ? :)

von Carsten B. (carstenb)


Angehängte Dateien:

Lesenswert?

Chris A. schrieb:
> Hier mal ein Tageslog von meinem HM-1200

> bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden,
> was kann das sein ? :)

Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02 
plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die 
Netzspannung und die Netzfrequenz drin ist. Siehe Bild.

von Chris A. (cherio7)


Lesenswert?

> Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02
> plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die
> Netzspannung und die Netzfrequenz drin ist. Siehe Bild.

ok, aber Netzspannung und Frequenz ist bei meiner 02.. Anwort nicht zu 
finden. Oder überseh ich was ?

auch bei der 01.. Antwort scheint es einen Unterschied zu geben.
Die Amps machen da keinen sinn oder ?

020000BC8B0000000F0009000100010000A6E639
010001015200020032000600A800000283D9A089

von Carsten B. (carstenb)


Angehängte Dateien:

Lesenswert?

Carsten B. schrieb:
> Ich poste nachher noch meine Auswertung für die weiteren Messages.

Hier nun meine Auswertung, soweit wie ich gekommen bin:

Ergebnis Excelauswertung 02.04.2022:

01 Telegramme:
Spalte N: U1 0,1V
Spalte O: I1 0,01A
Spalte O: P1 0,1W
Spalte Q: U2 0,1V
Spalte R: I2 0,01A
Spalte S: P2 0,1W

02 Telegramme:
Spalte N: E seit „Geburt“ ? Wh
Spalte O: E DC akt. Tag ? Wh
Spalte Q: E AC akt. Tag ? Wh
Spalte R: U AC 0,1V (Netzspannung)
Spalte S: F 0,01 Hz (Netzfrequenz)

Ob die kumulierten Tagesangaben zutreffen zeigt sich Morgen...

03 Telegramme: empfange ich keine

81 Telegramme: kann ich mir keinen Reim drauf machen

83 Telegramme: kann ich mir keinen Reim drauf machen

Ergänzung zum Setup des HM-600: An beiden Eingängen sind je 350Wp 
angeschlossen

Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum 
erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht 
messen.

: Bearbeitet durch User
von Carsten B. (carstenb)


Lesenswert?

Manchmal bin ich einfach naiv-pragmatisch und hin und wieder klappt das 
sogar...

Ich bin jetzt nicht der Programmierprofi und habe bisher nur die 
Arduino-Umgebung benutzt. Bevor ich mir die Mühe mache, eine neue 
Umgebung aufzusetzen, dachte ich, ich probiere es einfach mal :-)

von SM D. (bandit7311)


Lesenswert?

Carsten B. schrieb:
>
> Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum
> erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht
> messen.


Guten Abend,

die Wechselrichtern werden aus dem DC Anteil versorgt und deshalb sind 
sie bei wenig Licht bzw Nacht nicht ansprechbar.

ich lese hier schon eine ganze Weile mit. Momentan habe ich einfach 
keine freien Zeitslots mich hier einzubringen, leider.
Auch ich hätte gerne den momentan benutzten DTU Pro ausser Betrieb und 
würde gerne irgendwo auf meinem Synology NAS ein Datengrab schaffen um 
meine Ertragszahlen zu speichern.

Was mir persönlich aufgefallen ist, dass aus meinen 60 Wechselrichtern 
in allen Paketen die Seriennummern nicht fortlaufend einsortiert sind 
sondern immer in einer gewissen Struktur und hierbei meine ich nur die 
letzten 4 Ziffern. Kann es sein dass sich darin die Kanalnummern für den 
jeweiligen Wlan Kanal verschlüsseln, man stellt sich vor dass bei einer 
grösseren Anlage sonst schnell zu einer Menge Datenkollisionen kommen 
würde.

Viel Erfolg in die Runde, programmiere aus Leidenschaft in C und würde 
gerne helfen, habe aber momentan zu viel andere Dinge die in der 
Priorität weiter oben sind

Solong
B

von Thomas B. (tbnobody)


Lesenswert?

Chris A. schrieb:
> Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert?
> bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden,
> was kann das sein ? :)

Hallo Chris,

die Telegramme von HM-1200 und HM-600 werden nicht kompatibel sein.
Siehe: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"


Schau dir mal das Excel in 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" an

In den 1er Messages habe ich einmal die Spannung, 2x den Strom und 2x 
die Leistung.
In den 2er Messages habe ich bisher 1x die Spannung und 1x die Leistung 
gefunden. Ich habe nur 3 Panels dran, darum vmtl. nur insgesamt 3x Strom 
und Leistung.

In den 3er Messages habe ich nur die AC Spannung gefunden. Werde mir 
aber deinen Dump noch ansehen.

von Peter L. (leliep)


Lesenswert?

Carsten B. schrieb:
> 81 Telegramme: kann ich mir keinen Reim drauf machen
>
> 83 Telegramme: kann ich mir keinen Reim drauf machen
>
> E

Wenn Du in das von mir weiter oben bereitgestellte Dokument (Hoymiles 
Modbus implementation..., 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")
ab Seite 8 unter 4.2.1 schaust, dann wirst Du dort bei den Function 
Codes diese Werte als Antwort auf fehlerhaften "Read Single Device 
Status" und "Read Device Data" finden.

Könnte vielleicht passen...?

: Bearbeitet durch User
von Carsten B. (carstenb)


Lesenswert?

Moin Peter,

danke für den Hinweis, kann wirklich sein, dass 81 nur Fehlerhafte 
Übertragungen sind.

Bei den 02-Messages bin ich mir bei Spalte Q inzwischen recht sicher, 
dass Spalte T die WR-Temparatur ist. O und Q sind vermutlich eher der 
Tagesertrag je Kanal.

02 Telegramme:
Spalte N: E seit „Geburt“ Wh (sieht gut aus, zählte heute morgen weiter 
hoch)
Spalte O: E DC akt. Tag ? Wh (vielleicht doch E für Kanal 1 ?)
Spalte Q: E AC akt. Tag ? Wh (vielleicht doch E für Kanal 2 ?)
Spalte R: U AC 0,1V (Netzspannung) (passt)
Spalte S: F 0,01 Hz (Netzfrequenz) (passt)
Spalte T: Temperatur 0,01 °C (neu)

Mal sehen, was der Tag bringt...

Carsten

von Martin G. (petersilie)


Angehängte Dateien:

Lesenswert?

Mal zwischendurch ein Themenwechsel zu "Channel Hopping":

Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen 
"Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im 
Anhang.

Da zeichnet sich klar ab, dass

* die "0x01"-Nachrichten immer nach ca. 18 ms eingehen,
* die "0x02"-Antworten immer nach ca. 67 ms und
* die "0x83"-Antworten immer nach ca. 116 ms.

Das ist für "Anfrage auf Kanel 40, Antwort auf Kanal 3".

von Heinz R. (heijz)


Angehängte Dateien:

Lesenswert?

Martin P. schrieb:
> Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die
> Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann
> trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von
> Links nach rechts ein ... das 5. byte muss 01 sein.

Hallo Martin,

danke, scheint zu funktionieren

Ich bekomme jetzt beiliegende Daten - sieht richtig aus?

Es ist ein HM-1200 - nur 2 Eingänge belegt
Aktuell liefert er ca. 35W


Viele Grüße

von Chris A. (cherio7)


Angehängte Dateien:

Lesenswert?

Heinz R. schrieb:
> Ich bekomme jetzt beiliegende Daten - sieht richtig aus?
>
> Es ist ein HM-1200 - nur 2 Eingänge belegt
> Aktuell liefert er ca. 35W

Hi Heinz,

ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber 
keine Leistung.

An welchen Anschlüssen hast du die Panels dran ? links oder rechts?
Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann 
nichts sinnvolles mehr bei der 01 Antwort.

von Thomas B. (tbnobody)


Lesenswert?

Chris A. schrieb:
> Heinz R. schrieb:
>> Ich bekomme jetzt beiliegende Daten - sieht richtig aus?
>>
>> Es ist ein HM-1200 - nur 2 Eingänge belegt
>> Aktuell liefert er ca. 35W
>
> Hi Heinz,
>
> ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber
> keine Leistung.
>
> An welchen Anschlüssen hast du die Panels dran ? links oder rechts?
> Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann
> nichts sinnvolles mehr bei der 01 Antwort.

Das sieht so aus wie bei meinem HM-1500. Allerdings würde ich nur Spalte 
N als Spannung interpretieren.
- Spalte N: 26,2V
- Spalte O: 0,02A
- Spalte P: 0,03A
- Spalte Q: 0,6W (26,2 x 0,02 mit Rundungsfehlern?)
- Spalte R: 0,9W (26,2 x 0,03 mit Rundungsfehlern?)

von Heinz R. (heijz)


Angehängte Dateien:

Lesenswert?

Chris A. schrieb:
> ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber
> keine Leistung.
>
> An welchen Anschlüssen hast du die Panels dran ? links oder rechts?
> Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann
> nichts sinnvolles mehr bei der 01 Antwort.

Hallo Chris,

je ein Panel aktuell pro Seite

Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt
Ich messe an ihm ca. 23V, ca. 10mA

Das andere Panel hat aktuell ca. 29V, ca. 1 A

Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte 
ungefähr passen?

Hast Du DIr eine Excel-Vorlage gebaut?

Viele Grüße

von Chris A. (cherio7)


Lesenswert?

> Hallo Chris,
>
> je ein Panel aktuell pro Seite
>
> Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt
> Ich messe an ihm ca. 23V, ca. 10mA
>
> Das andere Panel hat aktuell ca. 29V, ca. 1 A
>
> Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte
> ungefähr passen?
>
> Hast Du DIr eine Excel-Vorlage gebaut?
>
> Viele Grüße

Hi Heinz,

ich hab das hier verwendet:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

von Lars B. (docbmuc)


Lesenswert?

Hallo zusammen,

endlich habe ich meinen WR HM-700 bekommen, läuft auch, aber antwortet 
nicht. grmpf

Ich habe sowohl eigene Entwicklungen als auch adaptierte Sniffer am 
Arduino Mega2560 erfolglos versucht. Zudem widersprechen sich aktuell 
die Aussagen bzgl. der nötigen Seriennummern-Bytes etwas:

Martin P. schrieb:
> Heinz R. schrieb:
> Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die
> Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann
> trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von
> Links nach rechts ein ... das 5. byte muss 01 sein.

In der (ursprünglichen) github-Doku von Petersilie heisst es:
> Hier werden 4-Byte-Adressen verwendet, die direkt aus den letzten 8 Stellen der 
Seriennummer des Wechselrichters bzw. der DTU gewonnen werden...

Verwirrung... ;-)
Sind es nun die ersten 4 oder die letzten 4? - Ich nehme mal an, es sind 
die letzten 4 BCD Bytes der Seriennummer.
Jetzt ist noch die Frage, wie rum die Dinger in das Define rein müssen.
MSB oder LSB neben der abschließenden 0x01?
Laut Doku würde ich mal annehmen, dass das MSB daneben kommt.
Also z.B. bei WR Serno. 11 41 74 60 84 85:
#define WR1_RADIO_ID ((uint64_t)0x8584607401ULL)


Ich habe beide Varianten schon getestet, die PA settings sowie SPI speed 
rauf und runter genudelt. - Nix geht... :-(
Config und erweiterte Ausgabe bei mir wie folgt - ich sende nur das 80er 
Telegramm:

Radio 1:
SPI Speedz  = 1 Mhz
STATUS    = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1  = 0xdeadbeef01 0x2888817201
RX_ADDR_P2-5  = 0xc3 0xc4 0xc5 0xc6
TX_ADDR    = 0xdeadbeef01
RX_PW_P0-6  = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA    = 0x00
EN_RXADDR  = 0x02
RF_CH    = 0x03
RF_SETUP  = 0x23
CONFIG    = 0x37
DYNPD/FEATURE  = 0x00 0x00
Data Rate  = 250 KBPS
Model    = nRF24L01+
CRC Length  = Disabled
PA Power  = PA_LOW
ARC    = 15

Send... CH40 157460848572818828800B00623C8EA30000000500000000375EC7 
Dest: 0174608485    WR1 TX error! 288828 37640
Send... CH40 157460848572818828800B00623C8EA5000000050000000097754A 
Dest: 0174608485    WR1 TX error! 2488380 37700

usw.

Achja: Ich habe das lustige PA-Modul mit externer Antenne, das hängt 
über den mitgelieferten LDO Adapter am Arduino 2560 folgendermaßen:

VCC->5V,
GND->GND,
SCK->52,
MI->50,
MO->51,
IRQ->2,
CE->7,
CSN->8

IMHO sollte das passen.

Was übersehe ich? Hat irgendjemand einen heissen Tipp?

Danke für die Geduld,
Lars

von Martin P. (mpolak77)


Lesenswert?

Lars B. schrieb:
> Also z.B. bei WR Serno. 11 41 74 60 84 85:
> #define WR1_RADIO_ID ((uint64_t)0x8584607401ULL)

ja genau so - sorry für die Verwirrung!

von Lars B. (docbmuc)


Angehängte Dateien:

Lesenswert?

Hi Martin,

danke für die Bestätigung. - Ich suche dann mal weiter, wo der Hund 
begraben liegt... ;-)

***UPDATE ***
Habe den begrabenen Hund gefunden! :-) :-) :-)

Der Receive-Interrupt im Arduino-Code wurde nicht aktiviert/deaktiviert.
Die Routine wird zwar über das attach eingehängt, aber die existierenden 
Defines
#define DISABLE_EINT EIMSK = 0x00
#define ENABLE_EINT EIMSK = 0x01
lassen den klassischen Arduino eher kalt. ;-)

Ich habs mal durch folgendes ersetzt und dann klappert das auch:
#define DISABLE_EINT   noInterrupts();
#define ENABLE_EINT    interrupts();

Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe 
anbei... :)

Cheers,
Lars

: Bearbeitet durch User
von Martin P. (mpolak77)


Lesenswert?

Lars B. schrieb:
> Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe
> anbei... :)

ja das mit den Interrupts musste ich für den ESP auch so machen ...

Ich lese ja auch einen HM-700 (und einen HM-350) aus und habe 
mittlerweile den von mir auf ESP angepassten NF24Send_Rcv Code auch um 
das parsing/printing und MQTT publishing erweitert ... bei der 
Unterscheidung der Geräte hapert es noch ein wenig ... und die 
Temperatur finde ich beim HM-700 nicht an der Stelle wie hier im Thread 
beschrieben.

Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch 
gerne ...

von Thomas B. (tbnobody)


Lesenswert?

Hallo,

ich wurde gerade hierauf verwiesen:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fgzll_02_user_guide.html&cp=4_1_0_5_0

Kann es sein das dieses Gazell unser Channel hopping ist?
Auch wenn sich oben genannte Doku auf einen nRF52833 bezieht steht bei 
den Features: Backward compatible with legacy nRF24L Series Gazell.

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Hallo,

hier scheint wohl so eine Implementierung des gzll Protokolls zu sein
https://github.com/wangdong/cpod/blob/master/lib/nrf24/gazell/common/gzll.c
Leider kann das wohl die nRF24 lib nicht.

von Heinz R. (heijz)


Lesenswert?

Martin P. schrieb:
> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
> gerne ...

ch bekunde Interesse :-)

Habe allerdings einen HM-1200

von Lars B. (docbmuc)


Lesenswert?

Hi Thomas,

guter Hinweis mit dem Gazell-Protokoll... das hatte ich schon 
erfolgreich verdrängt. ;-)

Das Kommunikationsschema von Gazell sieht aber IMHO anders aus. Das ist 
Device-getriggert und der Host lauscht erstmal nur und antwortet auf 
Anfragen der Devices.

Insofern müssten die HMs von sich aus auf einem Anker-Kanal "ungefragt" 
vor sich hin senden.
Das tun sie aber nach aktuellem Kenntnisstand nicht, sondern antworten 
auf Anfragen des Hosts. Das Kommunikationsschema stellt sich für mich 
eher "klassisch" dar, also Anfrage Host->Device, dann Antwort 
Device->Host.
Die max. Anzahl der für die DTUs spezifizierten "Solarmodule" ist mit 99 
auch deutlich höher, als die für Gazell maximal spezifizierten 8 
Teilnehmer.

...aber ich kann mich ja auch irren... ;-)

Beitrag #7024347 wurde vom Autor gelöscht.
von lpb (Gast)


Lesenswert?

Hallo zusammen,

ich habe auch ein wenig an meinem HM600 gelauscht.
Ich kann die Informationen für den HM600 wie im Anhang bestätigen.

Ich hoffe, das hilft dem einen oder anderen weiter.
Vielen Dank für die tollen Beiträge hier!

von lpb (Gast)


Angehängte Dateien:

Lesenswert?

Nanu, kein Anhang? Neuer Versuch...

von 1N 4. (1n4148)


Lesenswert?

Martin P. schrieb:
> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
> gerne ...

Ja, da hätten mein HM-600 und ich auch Interesse :)

von Carsten B. (carstenb)


Lesenswert?

lpb schrieb:
> Hallo zusammen,
>
> ich habe auch ein wenig an meinem HM600 gelauscht.
> Ich kann die Informationen für den HM600 wie im Anhang bestätigen.

Ich habe auch weiter gelauscht und die 01-Message kann ich so bestätigen 
an Hand meiner Daten.

Bei der 02-Message bin ich unsicher, was Gesamt-Ertrag und Wochenertrag 
angeht. Der letzte Wert ist die AC-Leistung und nicht wie Samstag noch 
von mir vermutet die Temperatur. Wenn ich mir die HM-Software ansehe, 
würde ich aber denken, das irgendwo noch die Temperatur versteckt ist...

von Carsten B. (carstenb)


Lesenswert?

Martin P. schrieb:
> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
> gerne ...
Da hätte ich großes Interesse :-)

von Martin P. (mpolak77)


Lesenswert?

Carsten B. schrieb:
> Martin P. schrieb:
>> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
>> gerne ...
> Da hätte ich großes Interesse :-)

Ok - ein Zipfile gibt es hier:

https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0

Hab leider gerade keine andere Möglichkeit den Code zu sharen (Handy)

Disclaimer: das Original ist nicht von mir - ich habe nur Code und 
Wissen aus dem Forum kombiniert, so wie es für
mich nützlich ist.

Es ist auch noch nicht besonders ausführlich getestet. Es unterstützt 
mehrere Wechselrichter, denen man in der Definition einen Namen geben 
kann um sie an der Konsole/Mqtt unterscheidbar zu machen. Das Mqtt topic 
und Format hab ich mal so gewählt, wie es zu meinem
Homesetup passt.

Was m.E. noch fehlt:
zB das Timing entspannen
Nur requests schicken, in der Nacht deepsleep
Und vieles mehr
Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe 
leider nur die Basic DTU und kann daher die Nachrichten nicht loggen ….

von Carsten B. (carstenb)


Lesenswert?

Martin P. schrieb:
> Carsten B. schrieb:
>> Martin P. schrieb:
>>> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch
>>> gerne ...
>> Da hätte ich großes Interesse :-)
>
> Ok - ein Zipfile gibt es hier:

> Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe
> leider nur die Basic DTU und kann daher die Nachrichten nicht loggen ….

Danke, sehr cool. Ich hoffe, ich finde morgen die Zeit es zu 
installieren. Das Thema Leistungsbegrenzung interessiert mich auch sehr. 
Gemeinsam mit mehreren kommen wir da sicher weiter.

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Hallo,

ich vermute die Inverter-Temperatur beim HM600 im cmd 131 (83), byte 4.
1
2022-04-04T11:23:54.973594Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=84, uk3=1000, uk4=393, uk5=1757, uk6=47334
2
2022-04-04T11:26:28.900800Z MSG src=72220143, dst=72220143, cmd=131,   uk1=1, uk2=36, uk3=1000, uk4=397, uk5=1765, uk6=13181
3
2022-04-04T12:16:51.839332Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=98, uk3=1000, uk4=460, uk5=1998, uk6=53222
4
2022-04-04T14:03:09.826004Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=59, uk3=1000, uk4=516, uk5=2492, uk6=12253
5
2022-04-04T14:36:51.087562Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=46, uk3=1000, uk4=496, uk5=2642, uk6=42061
6
2022-04-04T17:20:05.465478Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=0, uk3=0, uk4=327, uk5=3372, uk6=17290
7
2022-04-04T17:20:33.714355Z MSG src=72220143, dst=72220143, cmd=131,   uk1=0, uk2=0, uk3=0, uk4=327, uk5=3375, uk6=25778
Quelle: Relevanter Log-Output mit 
https://github.com/Sprinterfreak/ahoy/tree/dev

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Hallo,

habe gerade mal ein poormans Channel hopping über die bekannten Kanäle 
beim empfangen gefrickelt.
Siehe da: Mehr erfolgreiche Übertragungen als Fehlschläge.
Also wir reden jetzt von mindestens 3-4 vollständigen Datensätzen pro 
Minute.

Ich habe ein HM600 und bekomme cmd=1,2,131 nun etwa 4x/Minute.

https://github.com/Sprinterfreak/ahoy/commit/86715ac116188f27247d2beb65fe0f3a39a2eeab

von Hubi (Gast)


Lesenswert?

Hallo lpb
so ganz passen die Werte für Week und Total bei mir nicht. Ich notiere 
mir jetzt schon ein paar Tage day1 und day2 power (Summe ist 
Gesamtleistung am Tag). Die Summe der letzten 5 Tage + aktuell ergeben 
bei mir 10.000, aber im Telegramm gibt das week power nur 5102 (Stand 
jetzt) aus.
Da meine Anlage seit 1.1.2022 läuft, schätze ich mal eine Gesamtleistung 
von ca 100.000 Wh, im HM-Telegramm stehen aber 68.990 Wh. Scheint mir 
etwas wenig zu sein.
Bist du dir mit den Daten sicher?

von Thomas B. (tbnobody)


Lesenswert?

Jan-Jonas S. schrieb:
> habe gerade mal ein poormans Channel hopping über die bekannten Kanäle
> beim empfangen gefrickelt.

Also ich kann bestätigen, dass mit der Modifikation von Jan teilweise 
mehr Pakete empfangen werden. Also z.B. auf eine einzige 0x80 Anfrage 
kam folgendes:
1
2022-04-05 18:14:04.512796 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 01 00 01 01 36 00 08 00 08 00 1a 00 18 00 01 54 76 83
2
2022-04-05 18:14:04.559483 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 02 00 01 57 4e 00 b5 00 ac 01 33 00 07 00 02 00 17 b6
3
2022-04-05 18:14:04.595240 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 03 00 05 00 01 5e 4f 00 00 02 4e 00 a9 00 06 08 dd b5
4
2022-04-05 18:14:04.641578 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 84 13 89 00 49 00 c9 00 03 01 57 00 55 00 07 39 23 16

Ein 0x84 hatte ich vorher noch nie gesehen. Man achte auch auf die 
verschiedenen Kanäle.

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Ich hatte gerade auch die Möglichkeit von einem HM-600 eine Matrix über 
die Empfangenen Message ID's vs. Channel Number zu bilden (siehe 
Anhang).
1er und 2er scheinen nur auf Kanal 3 zu kommen. Ob das nun Zufall ist, 
oder Jans Implementierung so geschuldet ist (das zufällig durchs Timing 
immer die 1er und 2er auf Channel 3 erscheinen und andere ggf. verworfen 
werden) kann ich erstmal nicht sagen.
Also ich muss sagen, ich hab keine Ahnung von Channel Hopping 
Algorithmen usw... ich stochere hier nur etwas in den Daten.

: Bearbeitet durch User
von isnoAhoy (Gast)


Lesenswert?

Martin G. schrieb:
> Mal zwischendurch ein Themenwechsel zu "Channel Hopping":
>
> Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen
> "Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im
> Anhang.
>
> Da zeichnet sich klar ab, dass
>
> * die "0x01"-Nachrichten immer nach ca. 18 ms eingehen,
> * die "0x02"-Antworten immer nach ca. 67 ms und
> * die "0x83"-Antworten immer nach ca. 116 ms.
>
> Das ist für "Anfrage auf Kanal 40, Antwort auf Kanal 3".

Das würde doch dafür sprechen das Channel Hopping mal zufällig zu 
gestalten. Aktuell fängt die Implementierung von Jan-Jonas ja immer mit 
Kanal 3 an und macht dann mit den Kanälen 23, 61, 75 immer die selbe 
Reihe durch. Bei einer zufälligen Abfolge könnte man auch statistische 
Auswertungen der Daten vornhemen. So wie der Code aktuell ist bleibt die 
Präferenz für die schnellen Antworten auf Kanal 3 wie von Martin / 
Petersilie ausgewertet.

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Hallo,

bekomme jetzt bei meinem HM-600 nahezu sekündlich alle Daten.
https://github.com/Sprinterfreak/ahoy/tree/dev

Habe das Channel Hopping nochmal überarbeitet, sodass der RX Start 
Channel mit jeder Transaktion rotiert. Das empfängt jetzt auch cmd=1,2 
auf verschiedenen Channeln.

Nachdem ich AutoAck mal auf True gesetzt habe findet die Kommunikation 
jetzt nahezu zuverlässig statt.

An jemanden mit ner DTU und Sniffer:
Kann mal wer versuchen herauszufinden wie man das "Zero Export 
Control"-Feature setzt?
Laut Bedienungsanleitung kann der HM-600 ja auch noch Fehlercodes 
ausgeben. Eine Tabelle ist in der Bedienungsanleitung, jedoch finde ich 
keine halbwegs passenden Werte in den bisher bekannten Datensätzen.

von isnoAhoy (Gast)


Lesenswert?

In der nRF24L01+ Product Specs findet sich noch der folgende Absatz auf 
Seite 34 von 78: 
https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf?cp=12_4_0_0

> Two packet loss counters are incremented each time a packet is lost, ARC_CNT and 
PLOS_CNT in the
> OBSERVE_TX register. The ARC_CNT counts the number of retransmissions for the 
current transaction.
> You reset ARC_CNT by initiating a new transaction. The PLOS_CNT counts the total 
number of retrans-
> missions since the last channel change. You reset PLOS_CNT by writing to the 
RF_CH register. It is possi-
> ble to use the information in the OBSERVE_TX register to make an overall 
assessment of the channel
> quality.

Das würde dafür sprechen, daß es bei Übertragungsfehlern auf einem der 
bekannten Kanäle eine Retransmission auf einem der anderen Kanäle gibt 
um ggf. Störungen durch WLAN, PCM oder andere Funkteilnehmer 
auszugleichen. Offenbar scheint das "Channel-Hopping" ja auch speziell 
im Zusammenhang mit den vermuteten "Fehlermeldungen" 0x83 (und evtl. 
0x81 / 0x82 ?) in Verbindung zu stehen.

Oder täuscht mich da mein Eindruck ?

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Hi,
habe ein HM600;

0x83 (cmd=131) ist bei mir ein Werteblock, keine Fehlermeldung
  Hier stecken vmtl. load%, Temperatur, Status, Statuswechselzähler 
drin.
0x81 (cmd=129) ordne ich den Fehlern zu.
  Das kommt zurück, wenn man Müll mit korrekter CRC hin schickt.

https://www.alpha-solar.info/media/Dokumente/Wechselrichter/Hoymiles%20HM/Deutsch/Bedienungsanleitungen/HM-600%20%20HM-800%20Bedienungsanleitung.pdf
Alarmcode 129 deckt sich u.A. auch mit der Fehlertabelle in der 
Bedienungsanleitung vom HM-600. "Softwarefehlercode 129". Zufall?
Dann könnte der WR ja prinziepiell auch die anderen Alarmcodes senden. 
Dafür bräuchte es aber eine Art Session zwischen der DTU und dem WR. 
Weil ich habe noch keine unbekannten Pakete rein purzeln sehen, wenn ich 
z.B. das Netz abtrenne. Das müsste dann laut Anleitung 0x93/147 oder 
0x94/148 sein

von B. G. (golf2010)


Lesenswert?

zu den genutzten Frequenzen.
Bei meinem HM-600 ist es immer so:
Wenn ich ein 80 Telegramm sende auf 2403, dann antwortet der WR mit den 
Antworten 01,02,83  auf den möglichen Frequenzen 2423,2440,2461 MHz.
also bei TX 2403, Antworten auf 2423,2440,2461
     bei TX 2423, Antworten auf 2403,2440,2475
     bei TX 2440, Antworten auf 2403,2423,2475
     bei TX 2461, Antworten auf 2403,2423,2475
     bei TX 2475, Antworten auf 2403,2423,2440
Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt 
man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie 
empfangen.

: Bearbeitet durch User
von martin (Gast)


Lesenswert?

B. G. schrieb:
> Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt
> man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie
> empfangen.

Hallo BG,
hast du es mal mit einer 0x80 0x11 Anfrage versucht? Da dürften andere 
Daten zurückkommen, siehe hier:

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

von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

martin schrieb:
> Hallo BG,
> hast du es mal mit einer 0x80 0x11 Anfrage versucht?

Das muß ich mal testen.
Anbei noch ein jpg , NRF sendete auf 2475. HM-600 antwortete auf 
2440,2423,2423 (3. Antwort 83 nicht mehr auf jpg)
Man sieht, wann ich beim Scan auf die Frequenz kam und den Block 
quittiert habe.

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

Nach einiger Zeit hatte ich auch noch einmal Gelegenheit mich mit der 
Materie zu beschäftigen. Momentan bin ich noch der Meinung, dass das 
Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein 
Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen.
Auf den unterschiedlichen Kanälen kommen auf die 0x80 Anfrage immer 3 
verschiedene Antworten mit verschiedenen Ids, wenn Sie nicht durch 
irgendwelche Übertragungsprobleme gestört werden.
Ich empfange die Ids 0x01 bis 0x0B. Siehe beigefügter Beispiel Dump.
Da ist mit Sicherheit auch etwas dabei für Inverter mit mehr als 2 MPP 
Trackern.

Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt.
https://github.com/OFreddy/hm_poll
Eventuell kann man das nutzen und für verschiedene Platformen anpassen 
um solche Probleme zu vermeiden, dass bei einem nano z.B. andere 
Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu 
einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der 
hm_config_x.h geschehen.
Wer dort erweitern möchte ist herzlich willkommen.

Momentan unterstützt die Library 4 Inverter Instanzen, ist aber 
erweiterbar.
Das Channel Hopping kann noch optimiert werden.
Geplant habe ich eine Art Callback Funktion, bei der die Library 
empfangene gültige Pakete an die Applikation signalisiert. Diese könnten 
dann von der Applikation nach Datenpunkten zerlegt werden.

: Bearbeitet durch User
von B. G. (golf2010)


Angehängte Dateien:

Lesenswert?

martin schrieb:
> hast du es mal mit einer 0x80 0x11 Anfrage versucht?

Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85 
zurück, bei 800B 01,02,83

von Jan-Jonas S. (janjonas_s)


Angehängte Dateien:

Lesenswert?

Hallo Martin,

80 0b ist das "Zeit setzen" was mit normalen Werten antwortet
80 11 liefert bei mir cmd=129, Error
80 03 liefert ein ganzen Haufen, siehe Log.
u.A. cmd=1-7, wobei die Werte in 1 und 2 nicht identisch sind wie bei 0b

Hab das mal durchprobiert.
80 0b, 0c, 0d sind sehr ähnlich aber Werte scheinbar mit einem falschen 
Faktor.

Das ganze Tageslog muss ich mal aufarbeiten. Da ist auf jeden Fall 
einiges drin, was neu ist und bisher keinen Sinn ergibt, wenn man mit 
den Anfragen spielt und keinen Fehler schmeißt.

von Martin G. (petersilie)


Lesenswert?

Oliver F. schrieb:
> Momentan bin ich noch der Meinung, dass das
> Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein
> Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen.

Das mit dem "Gießkannenprinzip" ist bisher auch mein Eindruck: 
Vielleicht so etwas in diese Richtung:

- Die "DTU" sendet eine Anfrage auf mehreren Kanälen "zeitlich dicht 
hintereinander".
- Die WR hören permanent auf einem der Kanäle, und schalten nur mal 
einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hören.

- Die WR antworten auf mehreren Kanälen "zeitlich dicht hintereinander"
- Die DTU hört permanent auf einem der Kanäle, und schaltet nur mal 
einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hört.

Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen Empfänger 
scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes 
Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt.

Hier wäre es toll, wenn jemand mit einem SDR-Sniffer und DTU derartige 
Muster beobachten könnte. Ich meine, @tbnobody hat sowas zumindest 
ansatzweise mal gesehen?

Leider ist meine DTU noch immer nicht geliefert worden - und viel 
Hoffnung mache ich mir nicht mehr...

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Martin G. schrieb:
> Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen *Empfänger*
> scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes
> Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt.
Das ist das, was ahoy.py aus meinem Fork sieht.

> Ich meine, @tbnobody hat sowas zumindest ansatzweise mal gesehen?
Ja, in meinen Logs. Heute Nacht nach Einspeiseende werden meine Logs 
wieder untersucht. Mit Sicherheit. Mit entsprechenden Änderungen in 
ahoy.py, die genau das dämliche Verhalten mit verbessertem hopping-code 
zeigen, was ich so den Tag über bereits beobachtet habe.

: Bearbeitet durch User
von B. G. (golf2010)


Lesenswert?

Das glaube ich eher nicht.
Ich meine, die WR scannen die wenigen genutzten Kanäle durch. Durch das 
Retransmit erkennen sie immer die Nachricht. Ebenso können die DTUs oder 
eigene NRFs durch das Scannen sicher alle Telegramme empfangen. So hab 
ich das jedenfalls bei mir.
Wenn ich auf einer anderen Frequenz sende, kommen immer gleich die 
Antworten.
Ebenso ist es beim Empfang der Antworten.

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Das ist bei mir (HM600) eben anders.
Bei TX auf einem anderen Kanal als 40 kommt nichts. Nie.
Wenn ich nur auf einem fixen Kanal, auch über die Zeit empfange, bekomme 
ich nur hin und wieder mal ein einzelnes Paket. Wenn ich nach dem Tx 
über die Kanäle scanne, bekomme ich recht zuverlässig alle Pakete. Jedes 
mal auf anderen Kanälen. Auch nach einem Tx die Antwortpakete 
nacheinander auf unterschiedlichen Kanälen.

von Jan-Jonas S. (janjonas_s)


Angehängte Dateien:

Lesenswert?

Der Code, der das generiert ist hier:
https://github.com/Sprinterfreak/ahoy/blob/dev/tools/rpi/ahoy.py

Am Ende habe ich ein wenig mit den Tx-Daten gespielt, da sind sicher 
interessante Rohdaten dabei.

von Oliver F. (of22)


Angehängte Dateien:

Lesenswert?

Mein Testprogramm funktioniert jetzt so, dass die simulierte DTU die 
Kanäle durchwechselt und dann auf einem der Kanäle lauscht.
Empfängt es eine Antwort, so bleibt es auf dem Sendekanal und wechselt 
nur noch die Empfangskanäle durch. Dabei empfängt es immer auf einem der 
anderen Kanäle bis zu 3 verschiedene Frames. Siehe Screenshot.
Wechselt auch bei jedem mal auch der Sendekanal kommen deutlich weniger 
Antworten.

Voraussetzung ist allerdings, dass der Request mit 0x80 0x11 beginnt. 
Verwende ich die 0x80 0x0B kommen nur 0x01, 0x02 und 0x83 Antworten.

von Martin G. (petersilie)


Lesenswert?

@janjonas_s - Wow! Phänomenal! Mit Deinen Channel-Hopping-Versuchen 
kommen auf jeden Fall wesentlich häufigere Antworten. Und ein paar neue 
Feldbedeutungen hast Du auch eingepflegt.

Ich hab Deine Commits mal gemerged, danke!

Hatte noch ein paar lokale Änderungen, die sind jetzt auch drin. Die 
JSON-Daten enthalten jetzt alle Infos, die wir bisher erarbeitet haben.

* https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py

von Jan-Jonas S. (janjonas_s)


Lesenswert?

Hallo Martin,

danke. So ganz "richtig" kann das alles noch nicht sein. Speziell weil 
wohl  z.B. cmd=1,2,3 nicht immer den selben Inhalt haben. Dies ist wohl 
noch zwischen Modellen und je nachdem was man anfragt unterschiedlich. 
Siehe z.B. mein ahoy.log.gz um 17:46 rum. Da habe ich mit den 
Anfragedaten gespielt.

Bisher habe ich damit allerdings mit meinem HM600 die höchste 
Wahrscheinlichkeit erziehlt auf eine Anfrage möglichst alle Antworten zu 
bekommen.

Ich habe die ahoy.conf erweitert, sodass man da seine DTU-, Inverter 
serial und broker eintragen kann. Wenn man die außerhalb des Repos 
lagert und die ahoy.py vom Ort der ahoy.conf startet, geht das Updaten 
leichter.

: Bearbeitet durch User
von Abdul K. (ehydra) Benutzerseite


Lesenswert?

So langsam wird mir klar, warum ich auf dem WLAN-Band so einen hohen 
Hintergrundstörnebel gemessen habe. Echt bizarr.

von Martin P. (mpolak77)


Lesenswert?

also ich habe die ESP8266 Version jetzt auch soweit, dass man sie wo 
headless parken könnte (musste auch einen 100uF und Dipol-Antenne an die 
nrf24l01 Platine löten, um beide WR empfangen zu können) .. geschickt 
werden Messwerte per Mqtt und gelogged wird per rsyslog. Sonnenaufgang 
und Untergang wird berechnet um so über Nacht in DeepSleep gehen zu 
können.

Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht 
ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste, 
bekomme ich:

Vom HM700:
viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 
mit Temp (hier scheint der Wert auch nicht zu stimmen)

Vom HM350:
Bekomme ich nur 01 DC Daten und etwa halb so oft wie vom HM700

Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der 
Python Version breiter nach dem HM350 zu loggen.

von Oliver F. (of22)


Lesenswert?

Martin P. schrieb:
> Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der
> Python Version breiter nach dem HM350 zu loggen.

Hi.
Könntest Du mal die Bibliothek aus
https://github.com/OFreddy/hm_poll
ausprobieren? Es würde mich interessieren welche Antworen von anderen WR 
kommen. Ich kann nur mit HM-600 loggen.
Bei Fragen einfach melden.

: Bearbeitet durch User
von Jan-Jonas S. (janjonas_s)


Lesenswert?

Martin P. schrieb:
> Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht
> ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste,
> bekomme ich:
Das vermute ich, weil meine Versuche da eher blindes Huhn spielen. Wenn 
da tatsächlich Gazell, oder in Teilen Gazell, dahinter steckt wären die 
Channel vorhersagbar.

> Vom HM700:
> viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131
> mit Temp (hier scheint der Wert auch nicht zu stimmen)
Das kann gut sein. Habe ich ja gestern bei meinem HM600 auch provoziert, 
als ich das byte nach 0x80 im "Zeit setzen" verändert habe. Das hat die 
Werte im cmd=2,131 um irgendwas faktorisiert. Gut möglich, dass da jeder 
WR einen eigenen Requests braucht. Sicher jedenfalls sein eigenes Schema 
hat wie die Payload(s) aufgebaut ist. Glaube Thomas frickelt schon an 
Modellbezogenen Dekodern?

Thomas hat gestern aus meinen Daten auch komische Timing-Effekte 
extrapoliert Sah aus als ob über die Zeit (range unbekannt) mit meinem 
Hopping Werte nach einem Muster mal mehr und weniger werden.

> Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der
> Python Version breiter nach dem HM350 zu loggen.
Mein Gedanke war auch schon 5 nRF's als reinen Receiver, je einen Pro 
Kanal, laufen zu lassen. Ich hab leider nicht die Möglichkeit ein 
Spektrum im Gigahertz-Bereich aufzuzeichnen.

von Martin P. (mpolak77)


Angehängte Dateien:

Lesenswert?

Oliver F. schrieb:
> Hi.
> Könntest Du mal die Bibliothek aus
> https://github.com/OFreddy/hm_poll
> ausprobieren? Es würde mich interessieren welche Antworen von anderen WR
> kommen. Ich kann nur mit HM-600 loggen.

Hallo Oliver,

anbei ein Scan von HM350 und HM700.

das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem 
Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC 
erscheinen schlüssig und passen auch zu den Shelly Werten.

von Oliver F. (of22)


Lesenswert?

> Hallo Oliver,
>
> anbei ein Scan von HM350 und HM700.
>
> das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem
> Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC
> erscheinen schlüssig und passen auch zu den Shelly Werten.

Hallo Martin,
vielen Dank, super das Du das gemacht hast. Aber das verstehe ich nicht. 
Bei mir sieht das ganz anders aus. Ich erhalte eigentlich auf jede 
Anfrage eine Antwort von den Wechselrichtern.
Kann es sein, dass sie bei Dir nicht in Reichweite sind? Oder sind sie 
zu nahe? Du verwendest PA_HIGH. Ich hatte auch schon das Problem, dass 
das Verhalten schlechter wird, wenn die Sendeleistung zu hoch ist, oder 
die 3.3V Versorgung für die RF24 Module zu schlecht ist.

von Martin P. (mpolak77)


Lesenswert?

ja leider sind meine beiden WR ein Stück voneinander entfernt.
Bei meinem 2. Board mit ESP8266 + Dipol Antenne (selbstgebaut) kommen 
auch wesentlich mehr Messages ... vielleicht kann der Spannungsregler am 
NodeMCU einfach mehr leisten, als der des Nano.

Wenn der Laptop wieder aufgeladen ist (anders geht es leider nicht, wo 
ich beide WR empfange) kann ich es ja nochmals mit dem Dipol Board und 
PA_LOW probieren.

Morgen sollte ich außerdem so ein Board mit PA + LNA bekommen.

von Martin G. (petersilie)


Lesenswert?

Martin P. schrieb:
> Vom HM700:
> viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131
> mit Temp (hier scheint der Wert auch nicht zu stimmen)

Witzig, das deckt sich genau mit meiner Erfahrung (siehe 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?").

"Oft" 01, "seltener" 02, sehr selten 131.

Mysteriös. Aber wir sammeln eifrig weiter...

von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Hallo,

dank Jans Modifikation habe ich einen ganzen Tag aufgezeichnet und bei 
fast allen 0x80 vier Antworten bekommen. Dadurch konnte ich schon schon 
viele Felder identifizieren. Siehe Anhang. (Die #NV bitte ignorieren, 
die benötige ich zum Diagramme rendern)

Spalte F - G zeigen die Rohdaten. Spalte AH bis BA die bisher bekannten 
Felder. Vielleicht hilft es jemanden.

(Und DC1-4 sind bisher beliebig zugewiesen. Da müsste ich mal alle 
Panels bis auf eines abstecken und das genau machen)

: Bearbeitet durch User
von Thomas B. (tbnobody)


Angehängte Dateien:

Lesenswert?

Und ich glaube ich habe auch die Temperatur gefunden...

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.