Herbert K. schrieb: > Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation > zwischen dem GD... und dem nRF ? Das wird schon so gemacht, siehe weiter oben. Aber der verwendete NRF ist nicht nur ein Transmitter, sondern auch ein Mikrocontroller. Die Kommunikation zwischen GD und NRF lässt deswegen nicht direkt auf das HF-Geschehen schließen. Was aber noch nicht versucht wurde: versuchen, ob der Flash vom NRF auslesbar ist. Siehe meinen Vorschlag: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Herbert K. schrieb: > Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA > loslaufen lassen. Ich schlage vor, kurz vor der Stromversorgung des DTUs jeweils HF-Aufnahmen zu starten. Evtl auch mit etwas weniger Samplerate, damit es weniger Aussetzer gibt. Nach ein paar Aufnahmeversuchen müßte man zumindest die Start-Sequenz(en) des DTU finden können. Vielleicht kommt man dann etwas weiter. Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?
:
Bearbeitet durch User
Gute Idee! Und am besten auch mal ohne die Sniffer-NRFs, nicht dass wir uns mit deren ACKs oder dergleichen verrennen.
B. G. schrieb: > Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ? Hallo golf, ja, tatsächlich sind die so entstanden, zumindest was die DTU betrifft und die Kanäle 3 und 23. Man sieht das auch gut an den seriellen Aufnahmen. Die UART-Pegel sind zunächst auf Low, gehen dann auf High und dann kommt die Initialisierung des NRF24LE1E (3x Request/Response). Danach beginnt das Suchen nach Invertern. Kanal 40 habe ich dann im laufenden Betrieb aufgenommen, nachdem ich gemerkt hatte, dass da mehr los war. Bei allen Versuchen war der Inverter vorher schon an, da er immer eine Weile braucht bis er initialisiert ist.
Angehängte Dateien:
Hallo zusammen. Eine Frage an alle die hier fleißig die HF Daten analysieren. Ich habe, wie bereits gesagt, auch einen NRF24 Sniffer am Laufen. Leider kann dieser nur auf die eingestellten Adressen lauschen. Der Chip unterstützt mehrere Datapipes. (Siehe Anhang) Ich denke, die WR werden eine Datapipe betreiben, mit deren Seriennummer als Adresse. Es muss aber noch eine andere Pipe geben mit einer Art Broadcast Adresse, die für alle WR gleich ist?!? Ich komme darauf, weil ich mehrmals den Hochlauf der DTU gesnifft habe. Sinnvolle Kommunikation sehe ich nur auf den Kanälen 3, 23 und 40, wobei die DTU auf Kanal 40 sehr selten vertreten ist. In diesem Beispiel ist es so, dass die Wechselrichter (C1) auf einmal anfangen zu senden, ohne dass zuvor ein Telegramm von der DTU an die Wechselrichter (C3) zu sehen ist. Ich habe das ganze relativ häufig auf den einschlägigen Kanälen probiert. In der Regel sind die ersten Telegramme immer WR=>DTU, ohne dass ich eine initiale Aktion der DTU sehe. Die Bedeutung der einzelnen Spalten habe ich versucht im Anhang zu dokumentieren.
1 | C1 026566496 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
2 | C1 026570128 00 0590817201 0006 00 3 EA5A EA5A |
3 | C1 026573400 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
4 | C1 026595440 00 0590817201 0000 00 0 8A9C 8A9C |
5 | C1 026597740 00 0590817201 0002 00 1 AADE AADE |
6 | C1 026613740 00 0590817201 00B8 17 0 95 73104439 73104439 83000000F303E80185000581B4BA142F 142F 1 |
7 | C1 027707212 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
8 | C1 027713144 00 0590817201 0006 00 3 EA5A EA5A |
9 | C1 027716424 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
10 | C1 027740752 00 0590817201 0000 00 0 8A9C 8A9C |
11 | C1 027756120 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
12 | C1 027764348 00 0590817201 0002 00 1 AADE AADE |
13 | C1 027767624 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
14 | C1 029551548 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
15 | C1 029557480 00 0590817201 0006 00 3 EA5A EA5A |
16 | C1 029560760 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
17 | C1 029585088 00 0590817201 0000 00 0 8A9C 8A9C |
18 | C1 029601636 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
19 | C1 029609864 00 0590817201 0002 00 1 AADE AADE |
20 | C1 029613140 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
21 | C1 029635176 00 0590817201 0004 00 2 CA18 CA18 |
22 | C1 029637480 00 0590817201 0006 00 3 EA5A EA5A |
23 | C1 034225220 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
24 | C1 034235752 00 0590817201 0006 00 3 EA5A EA5A |
25 | C1 034239032 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
26 | C1 034261072 00 0590817201 0000 00 0 8A9C 8A9C |
27 | C1 035451152 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
28 | C1 035457080 00 0590817201 0006 00 3 EA5A EA5A |
29 | C1 035460360 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
30 | C1 035482388 00 0590817201 0000 00 0 8A9C 8A9C |
31 | C1 035484696 00 0590817201 0002 00 1 AADE AADE |
32 | C1 035500772 00 0590817201 00BC 17 2 95 73104619 73104619 83000500F603E8018300213960F485BA 85BA 1 |
33 | C1 035995516 00 0590817201 00D8 1B 0 95 73104439 73104439 010001014803A70BF5014803AC0C0600006AEB1C EB1C 1 |
34 | C1 036029056 00 0590817201 0004 00 2 CA18 CA18 |
35 | C1 036044500 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
36 | C1 036055028 00 0590817201 0006 00 3 EA5A EA5A |
37 | C1 036058312 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
38 | C1 036080352 00 0590817201 0000 00 0 8A9C 8A9C |
39 | C3 037978808 00 1946107301 00DE 1B 3 15 73104619 72819005 801200623DA4AB000000000000000098C8DD09E3 09E3 1 |
Ist Euch bei der Analyse der HF Daten schon mal eine andere Adresse aufgefallen?
:
Bearbeitet durch User
Hallo Oliver, Danke für Deine Logs. Ich habe dazu wiederum ein paar Fragen/Anmerkungen: (1) Nach meinem Verständnis kann der NRF24 zwar von bis zu 6 "Pipes" = "Adressen" empfangen, aber nur Pipe 0 ist unabhängig, Pipe 1-5 teilen sich die ersten 4 Bytes, d.h. dürfen sich nur im letzten Byte unterscheiden (siehe Kapitel 7.7 "Multiceiver"). Das würde erklären, warum Du nur Nachrichten von C1 und C3 siehst. (2) In Deinen Mitschnitten tauchen auch wieder diese 0-Byte Payload Pakete auf. Laut Datenblatt sind das ACK-Pakete, die der Chip automatisch sendet, wenn er auf der jeweiligen Adresse etwas empfangen hat. Ich meine, bisher sieht es so aus, als sei diese ACK Funktion bei den Hoymiles Geräten deaktiviert. Wir sollten diese auf jeden Fall bei jeglichen Sniffern auch deaktivieren (setAutoAck(false)), sonst greifen die ja aktiv in den Funkverkehr ein. Vielleicht kommt da auch manche der Verwirrung weiter oben her - denn die Adresse dieser ACK-Pakete ist ja jeweils gleich der Adresse des ursprünglich empfangenen Pakets. (3) Bzgl. Deiner Frage wegen anderer Adressen - ich meine, martin (Gast) hatte auch schon einmal Adressen beobachtet, die in 0x00 (anstatt 0x01) enden. Als "Broadcast" zwischen allen WR würde das aber nicht wirklich taugen, hierzu würde sich vielleicht am ehesten die DTU Adresse eignen. Vielleicht gibt es bei Inbetriebnahme auch Broadcasts an 0x0000000000 oder so - auf uC-Seite scheinen manche Pakete solch eine Adresse zu enthalten. -- Petersilie
Angehängte Dateien:
Hallo Martin. Also ich habe jetzt mal etwas mit dem RF25L01+ Chip experimentiert. So ganz bin ich noch nicht dahinter gestiegen wie er funktioniert. Es ist sicherlich irgend so ein ASIC der als Schrittschaltwerk funktioniert ohne abhängige Logic, bzw. ohne die eingestellten Parameter zu prüfen. Er macht etwas in Abhängigkeit der eingestellten Register. Es kann schon mal sein, dass er völlig durcheinander ist und nur ein Spannungsreset hilft. So meine Beobachtung. Zu Deinen Fragen/Anmerkungen: (1) So wie ich es verstehe besteht die Möglicheit, dass die Adressen von Pipe 0 und Pipe 1 5 Byte lang sind. Pipe 2-5 betrachte ich nicht, diese hängen natürlich von den restlichen Bytes der Pipe 1 ab. Ich habe die Pipes auf die beiden Wechselrichter programmiert:
1 | pipe 0 ( open ) bound = 0x3944107301 |
2 | pipe 1 ( open ) bound = 0x1946107301 |
3 | pipe 2 (closed) bound = 0xc3 |
4 | pipe 3 (closed) bound = 0xc4 |
5 | pipe 4 (closed) bound = 0xc5 |
6 | pipe 5 (closed) bound = 0xc6 |
Im Log werden die Einträge von C2 nicht angezeigt, weil die Abfrage der Pipe im Interrupt aus irgendeinem Grund nicht funktioniert. Darum stimmt die im Adurino generierte Prüfsumme nicht. Die Telegramme werden aber erfasst, jedoch der Pipe 1 zugeordnet, obwohl sie zu Pipe 0 gehören. Hier ein Beispiel, gehört eigentlich zu Pipe 0, die Abfrage
1 | radio2.available(&pipe) |
liefert aber Pipe 1, darum wird das Telegramm C3 zugeordnet und anschließend wegen falscher Prüfsumme (Die Berechnung legt die Adresse WR2 zugrunde) verworfen. In den Nutzdaten sieht man aber, dass das Telegramm eigentlich für 73104439 bestimmt ist.
1 | C3 019634660 00 1946107301 00DE 1B 3 15 73104439 72819005 800B00623DD84B00000005000000009117A9035D 1565 0 |
(2) Was Du sagst ist absolut richtig, aber wenn dann ist es in der RF24 Dokumentation missverständlich beschrieben. Die AutoAck Funktion ist bei allen "Sniffern" deaktiviert. Darum sollten die nicht für die Ack Frames verantwortlich sein. Die ACK Frames die ich sehe sind auch immer an die Adresse der DTU gerichtet. Meine RF24 sind so eingestellt, dass die TX_ADR auf Default steht:
1 | TX_ADDR = 0xe7e7e7e7e7 |
Das Datenblatt sagt ja, dass für die AutoAck Funktion TX und RX Addr. gleich sein müssen.
1 | TX5 device: TX_ADDR = 0xB3B4B5B605 |
2 | TX5 device: RX_ADDR_P0 = 0xB3B4B5B605 |
3 | RX device: RX_ADDR_P5 = 0xB3B4B5B605 |
Muss man sicherlich noch weiter hinterfragen. (3) Als Ursache für die Adressen die mit 0x00 enden habe ich für mich den yveaux Sniffer ausgemacht. (Gut wenn man einen Schuldigen hat). Dieser stellt im RF 24 immer fest eine Adressbreite von 4 Byte ein (Bzw. Parametrierte Adressbreite - 1).
1 | #define DEFAULT_RF_ADDR_PROMISC_WIDTH (DEFAULT_RF_ADDR_WIDTH-1)
|
Das fehlende 0x01 in der Adresse wird dann schon der Payload zugeordnet. Dies ist der Grund, warum ich in älteren Aufzeichnungen immer ein Bit vor dem 9-bit PCF hatte. (Siehe Anhang) Die 0x02 ist die 0x01 in Byte 5 der Adresse. Martin (Gast) hatte noch eine Anmerkung: > Was mir hier und auch in meinen Daten aufgefallen ist: In den > Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer > mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun > haben, der für die Antwort verwendet werden soll? Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) Turn unit off: C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 Turn unit on: C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 Turn unit off: C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 Turn unit on: C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1
:
Bearbeitet durch User
Angehängte Dateien:
Ich möchte gerne einen kleinen Teilerfolg vermelden. Ich kann meine WR ohne die DTU abfragen und erhalte sporadisch Antworten. Ein Muster erkenne ich noch nicht. Bisher kann ich meinen Aufbau nur mit RF24_PA_LOW betreiben. Aber die Sendeleistung reicht um die 30m entfernten WR zu erreichen. Beim Senden meldet sich bei einer höheren Sendeleistung immer der CH340 Chip USB zum Rechner ab. Zunächst ging sogar nur RF24_PA_MIN, bis ich die 3.3V zum RF Modul mit einem 100uF Elko gestützt habe. Die DTU Radio ID in dem Code kann ich beliebig ändern, die WR antworten dann auf die neue DTU ID. Als Anpassung sollte es reichen, die DTU Radio Ids zu ändern. Bei nur einem WR zunächst irgendeine Dummy Adresse verwenden oder diese belassen.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Die Wechselrichter scheinen irgendeinen proprietären Mechanismus bei dem Channel hopping zu verwenden. Den habe ich noch nicht verstanden. Der Trick ist, auf einer anderen Adresse zu empfangen als zu senden und beim Senden bis die maximale Retransmit rate mit 2ms Pause zu verwenden. Zur Zeit verwende ich die Kanäle 3 und 40. Auf einigen anderen Kanälen geht bei mir gar nichts, vermutlich wegen meinem WLAN. Muss man evtl. in jeder spezifischen Umgebung ausprobieren. Versucht habe ich es mit einer Kombination aus den bereits weiter oben erwähnten Kanälen:
1 | int channels[] = {3, 23, 40, 61, 75}; |
1 | #define DEFAULT_RECV_CHANNEL (3) // 3 = Default channel for Hoymiles
|
2 | #define DEFAULT_SEND_CHANNEL (40) // 40 = Default channel for Hoymiles
|
Kann dies jemand bei sich nachvollziehen? Oder liegt es bei mir daran, dass die WR schon mal mit der DTU kommuniziert haben und dadurch noch irgendeine Konfiguration haben? Bei Fragen oder Problemen einfach melden.
:
Bearbeitet durch User
Hallo Oliver, was genau wird bei dir zur Anforderung an den WR gesendet ? Vielleicht sende ich da was falsches. Bisher bei mir ohne Erfolg. Ich hab 14 retransmits eingschalten, hab auf jeder Megahertz - Frequenz 2400 - 2525 Mhz gesendet. Der WR hat nirgends geantwortet. Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, daß er irgendwo antwortet. Dann könnte ich immer noch mit Aufnahmen feststellen, wo. (Die Messung mit dem AD8318 funktioniert einwandfrei, wenn ich den an meinen NRF dran stelle.) Evtl fehlt dann doch irgendeine Grundinitialisierung an den WR, daß er was tut oder ich sende Schrott.
B. G. schrieb: > > was genau wird bei dir zur Anforderung an den WR gesendet ? > Hallo B.G. Der Quelltext ist dem Beitrag angehängt. Ich sende alle 200ms ein Telegramm an meine beiden Wechselrichter. Sie antworten nicht jedes mal, sondern gefühlt jedes 4-5 Mal. Ich denke das hat mit dem noch nicht durchschauten Channel Hopping zu tun. Es wird nacheinander auf CH40 das 0x80 Telegramm mit einer simulierten Unix Zeit gesendet, da ich auf dem nano keine Echtzeituhr habe. Das scheint dem WR aber egal zu sein. Dann das 0x81, 0x80, 0x83, 0xFF Telegramm, wie von Martin in der Protokollbeschreibung angegeben. Danke an Martin das ist sehr hilfreich. Nach dem Senden wird direkt wieder auf CH3 umgeschaltet und gehorcht.
1 | if (tel > 4) |
2 | tel = 0; |
3 | if (tel == 0) |
4 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
5 | else if (tel == 1) |
6 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x81); |
7 | else if (tel == 2) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x80); |
9 | else if (tel == 3) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
11 | else if (tel == 4) |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0xFF); |
13 | |
14 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
15 | |
16 | toggle = !toggle; |
17 | if (!toggle) |
18 | tel++; |
Ein Dump mit Ausgabe von Send und Receive ist angehängt. Die Zeilen mit diesem Inhalt sind dabei die vom WR empfangenen Daten.
1 | 048491820 00 1234567801 00DC 1B 2 95 73104619 73104619 010001014F027908470150026D08220000FB9CDF 9CDF 1 |
2 | 048540572 00 1234567801 00DE 1B 3 95 73104619 73104619 02FE300000F91307790762096413840FADF0AB62 AB62 1 |
"Send..." ist jeweils ein Send auf CH40. PL die Payload, WR1/2 gibt an an welche Adresse. Die 0 danach ist der Rückgabewert vom Write, da ja kein ACK von den WR kommt. Dann die millis() Zeit des Nano und die Dauer des Sendens in millis().
1 | Send... CH40 PL: 1573104439785634128182 WR2 0 48677140 29204 |
2 | Send... CH40 PL: 15731046197856341281A0 WR1 0 48877844 29204 |
:
Bearbeitet durch User
vielen Dank, wenn es jemand gibt, der Erfolg mit dem zurücklesen hat, ohne eigene DTU zu besitzen, dann bitte melden. bei martin müßte es ja evtl jetzt so funktionieren ?
Hallo @golf2010 und @of22, das ist tolle Arbeit. Muss man erst mal drauf kommen! Hoffentlich komme ich morgen dazu, das mit meinem Raspi-Setup auszuprobieren. Können wir eventuell noch weiter einschränken, welche Nachrichten wirklich notwendig sind? (1) @of22, Du wechselst zwischen den 5 Pakettypen im Kreis herum - hast Du mal probiert, ob weniger eventuell immernoch zum Erfolg führen? (2) Und habe ich das richtig verstanden, du hörst immer auf Kanal 3? D.h. angenommen, Du würdest nach dem Senden auf Kanal 40 bleiben, dann würdest Du nichts empfangen? (3) Und noch ne ganz ketzerische Frage: wenn Du garnichts sendest und nur auf Kanal 3 zuhörst, empfängst Du aber nie irgendwelche Nachrichten, oder doch?
Hallo Martin G. (1) Habe ich versucht nur das 0x80 mit dem Unix Timestamp zu senden, das reicht aus. Aber dann kommt nur der 01 00 01 Response. Mit den anderen zwischendurch kommt auch mal ganz selten eine andere Antwort. Ich hatte schon versucht mir die Saleae Captures von martin (Gast) 20.03.2022 13:37 anzusehen, um hier vielleicht anhand der Serial Captures ableiten zu können welche Requests erforderlich sind. Könnte man die vielleicht als ASCII Dump oder so zur Verfügung stellen? Ich habe kein Saleae und so wie ich es veerstehe gibt es keine Stand Alone Version der Software. (2) Das ist richtig, so ist meine Beobachtung. Gesendet und Empfangen wird immer auf einem unterschliedlichen Kanal. Bleibe ich auf dem Sendekanal, egal ob 40 oder 3, empfange ich keinen Response. (3) Nein, wenn ich aufhöre zu senden kommen keine Responses vom WR mehr. Er muss immer durch irgendein Telegramm getriggert werden.
:
Bearbeitet durch User
Hallo @of22, habe mir die Hardware mit dem Nano aufgebaut. Kommunikation mit dem NRF24 scheint zu tun. Also Register usw. werden ausgelesen. Nur kurz 2 Fragen bevor ich hier tiefer in den Code einsteige. 1. Muss die Seriennummer des WR auch Rückwärts angegeben werden? 2. Wie funktioniert das Menü? Wird gleich nach dem Startup schon gesendet oder muss man das Senden zuerst über die Serielle Konsole starten? Danke & Grüße Thomas
Angehängte Dateien:
-
ali-001.jpg
21 KB -
ali-005.jpg
18 KB
Hallo Thomas. Die Seriennummer muss in dem define umgekehrt angegeben werden. An meinem Beispiel: WR1 = xxxx73104619 WR2 = xxxx73104439 Und im Byte 5 der Adresse die 01 nicht vergessen. Die Adresse der DTU ist egal, da Du sie ja simulierts.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Das Menü ist erst einmal uninteressant. Der Code fängt direkt an zu senden. Es waren nur Tests um die Kommunikation auf einzelne Telegramme einzuschränken. Eine Anmerkung noch: Eventuell muss der Sendelevel angepasst werden. Ich habe die Module ali-005 mit externer Antenne im Einsatz. Damit komme ich nicht über PA_LOW sonst hängt sich etwas auf (CH340), oder ich bekomme keine Antworten. Vorhin habe ich es noch die ali-001 ausporbiert. Damit muss ich höher gehen auf PA_HIGH sonst bekomme ich keine Antwort von den ca. 30 m entfernten Wechselrichtern durch zwei Wände. Aber auch mit denen kann ich nicht auf PA_MAX gehen sonst kommt wiederum keine Antwort.
1 | radio1.setPALevel(RF24_PA_HIGH); |
Und dran denken, jetzt ist dunkel. Da kommt nichts mehr, weil der WR aus dem DC Kreis versorgt wird.
:
Bearbeitet durch User
Hallo Oliver, alles klar danke! Habe hier auch den ali-005. Habe aber schon einen 10uF angelötet. Werde es erstmal mit LOW versuchen und mich notfalls mit dem Laptop raus stellen. Ich bin ja sooo gespannt. Jetzt wenn schon Sonne vorhanden wäre :) Grüße Thomas
Angehängte Dateien:
B. G. schrieb: > Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen > und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, > daß er irgendwo antwortet. Ich hab tagelang völlig unnötig rumprobiert. Da war bei mir nur ein Zahlendreher in meiner eingegebenen WR-Seriennummer. Nachdem ich den heute Nacht gesehen hab, hat der WR heute morgen sofort geantwortet auf ein 80 Paket. Also brauchst doch keine extra Initialisierung. Anbei der Ausgang von meinem Pegelmesser AD8318, am Oszi angeschlossen. Ich muß jetzt schauen, wo er antwortet.
Angehängte Dateien:
B. G. schrieb: > Ich muß jetzt schauen, wo er antwortet. auf 2403 kam der gerade. auf der 2405 gibts hier noch einen weiteren NRF, wohl ein Nachbar. Der auf 2405 kommt etwas stärker rein.
:
Bearbeitet durch User
Hallo B.G. dein Testprogramm funzt einwandfrei. Es werden zwar nicht alle Anfragen beantwortet, aber so alle 1 - 2 Sekunden kriegt man Daten. Und das ist doch schon was.
Hallo Hubi, das Programm ist von Oliver. Ich kann kein C, nur Pascal(Avrco) und Delphi.
Hallo, kann es auch bestätigen. Daten werden empfangen. Ich kann auch bestätigen das es mit > RF24_PA_HIGH nicht funktioniert. Zumindest wenn ich den NRF24 via USB betreibe. Am Labornetzteil tut es.
Angehängte Dateien:
Hallo, das freut mich zu hören, dass es auch bei anderen klappt. Das man nicht jedes Mal eine Antwort erhält, liegt an dem noch nicht durchschauten Channel Hopping. Ich habe mal noch ein paar Sachen zum Nachdenken, wer möchte, kann sich gerne beteiligen. Ich habe meiner DTU und einem WR nochmal bei der Kommunikation mit diesem Aufbau zugehört: Zwei RF24 Chips. Einer lauscht auf Kanal x und der andere auf x + 40, jeweils für 60 s. Dann wird x inkrementiert von 0 bis 39. Dabei heraus gekommen ist diese Statistik. Das ist sicherlich eine Momentaufnahme, die sich aus meinem WLAN Umfeld und aus anderen Störern ergibt. Auch sind bei den Frames WR=>DTU die Antworten von dem zweiten Wechselrichter, dessen DTU Anfragen nicht geloggt werden, das könnte das Bild verfälschen. Kommunikation läuft auf mehr als den bisher angenommenen Kanälen, wobei es bei den Kanälen 7, 8, 9 auch ein Übersprechen sein könnte. WR an DTU sind am häufigsten auf Kanal 3 und 23 vertreten. DTU an WR springt lustig durch die anderen Kanäle, wobei 0, 7, 9, 23, 27, 35, und 40 die Spitzenreiter sind. Als Kommandos DTU=>WR sieht man die Ids 0x80, 0x81, 0x82, 0xFF.
1 | Kanal | Frames | DTU=>WR | WR=>DTU | 0x80 | 0x81 | 0x82 | 0xFF |
2 | ------+--------+---------+---------+------+------+------+------ |
3 | 0 | 11 | 11 | 0 | 5 | 0 | 0 | 6 |
4 | 3 | 81 | 8 | 73 | 5 | 4 | 1 | 2 |
5 | 7 | 10 | 10 | 0 | 8 | 0 | 0 | 2 |
6 | 8 | 3 | 3 | 0 | 2 | 0 | 1 | 0 |
7 | 9 | 12 | 12 | 0 | 9 | 0 | 3 | 0 |
8 | 11 | 9 | 9 | 0 | 8 | 0 | 1 | 0 |
9 | 14 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
10 | 20 | 3 | 3 | 0 | 2 | 0 | 0 | 1 |
11 | 23 | 59 | 12 | 47 | 7 | 1 | 4 | 1 |
12 | 27 | 13 | 13 | 0 | 9 | 1 | 1 | 2 |
13 | 29 | 8 | 8 | 0 | 4 | 0 | 3 | 1 |
14 | 35 | 11 | 11 | 0 | 5 | 2 | 1 | 3 |
15 | 37 | 8 | 8 | 0 | 6 | 0 | 2 | 0 |
16 | 39 | 8 | 8 | 0 | 5 | 0 | 2 | 1 |
17 | 40 | 10 | 10 | 0 | 6 | 0 | 1 | 3 |
18 | 61 | 13 | 9 | 4 | 6 | 0 | 2 | 1 |
19 | 75 | 8 | 3 | 5 | 2 | 1 | 0 | 0 |
Woher weiß die DTU, auf welchem Kanal der WR lauscht? Und woher weiß sie, auf welchem Kanal die Antwort vom WR kommt? So aus einem Bauchgefühl heraus: Könnte das 0xFF Telegramm die Aufforderung zum Kanalwechsel sein, aber wohin? Bei dem 0x80 Telegramm sehe ich im Byte hinter der 0x80 die Bytes 0x0B oder 0x11 (Siehe Screenshot). Die Bedeutung erschließt sich mir noch nicht. Beigefügt der Dump aus dem Minuten Scan als Rohdump und aufbereitete Excel.
:
Bearbeitet durch User
Hallo, es geht voran, aber nicht so direkt Beteilige verlieren den Überblick. So auch ich. Kann bitte jemand einmal kurz und knackig die benötigte Hardware skizzieren und die Software mit Sourcecode bereitstellen? Dann kann jeder Homiles Nutzer sich schnell zurechtfinden. Danke
@of22: Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen Uhrzeit stehen?
Bezugnehmend auf Sorbit (Gast) würde ich gerne https://github.com/grindylow/ahoy als Sammelstelle vorschlagen. Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf das Repository geben. @Sorbit, ich glaube, so hundertprozentig "einstecken und tut"-Lösungen haben wir noch nicht - jeder hat leicht andere Hard- und Software, aber gerade deshalb geht es erstaunlich voran! Aber Du hast natürlich Recht, ich denke wir haben alle ein Interesse daran, dass das ganze früher oder später einfach(er) nachzuvollziehen und zu nutzen wird.
Angehängte Dateien:
Martin G. schrieb: > @of22: > Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen > Uhrzeit stehen? Hallo Martin, gute Idee, das ist ja fast das Einzige was sich in den Telegrammen ändert. Beziehe ich in meine Grübeleien ein. > Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf > das Repository geben. Bisher ist das Ganze ja nur ein zusammengeklopptes Testprogramm. z.B. könnte man die CRC Generierung auf eine Bibliothek umstellen. https://github.com/RobTillaart/CRC oder so. Auch wird im Testprogramm Kanal 40 zum Senden und 3 zum Empfangen verwendet. Die Statistik oben zeigt ja, dass man auch auf 23 lauschen müsste und auf anderen senden. Aber Du kannst gerne den jetzigen Stand hochladen. @ Sorbit (Gast): Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in China bestellt hatte. Ich mag die Atmel Dinger aber ansonsten nicht. Dazu ein RF24 Modul ali-005 (Siehe weiter oben). Die Schaltung habe ich skizziert. Ich betreibe den nano mit den 5V vom Laptop USB. Problem ist hierbei noch die 3V3 Versorgung des RF24. Wie Thomas B. (tbnobody) herausgefunden hat verwendet man besser noch ein externes Netzteil. Die Leistung des Linearreglers im CH340 des nanos reicht nicht aus um die Versorgung bei höheren Sendeleistungen sicher zu stellen.
Hallo zusammen, im Source von Oliver sollten ja die verschiedenen Packages nacheinander durchprobiert werden. Daher hätte ich erwartet, dass die Antworten mit gleicher Häufigkeit vorkommen. Aber siehe capture.txt im Anhang sehe ich hauptsächlich 1er und 2er... die 3er Messages kommen kaum vor. Könnt ihr das Nachvollziehen, ist das bei euch ähnlich? Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, ggf. auch der Strom, aber spätestens bei der Leistung stimmt es zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe hier einen HM-1500) Ggf. sind die Telegramme je nach Typ unterschiedlich aufgebaut. Dann müsste man aber seinen Typ entweder in der Hoymiles Cloud einstellen können oder dieser wird irgendwo noch mitgeschickt.
Oliver F. schrieb: > Aber Du kannst gerne den jetzigen Stand hochladen. Gesagt - getan: https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv
Oliver F. schrieb: > @ Sorbit (Gast): > Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in > China bestellt hatte. Davon hab ich genug rumfliegen. Welcher Code läuft da drauf? RF Modul hab ich auch mal im 20 er Pack gekauft. Alles da, auch ein produktiver HM-1200... Danke
Hallo @of22, ich bin noch über Deine Zeile https://github.com/grindylow/ahoy/blob/82ce2c9d8864dcc465af804ab0130dd7a7322a6b/tools/nano/NRF24_SendRcv/src/hm_packets.cpp#L49 gestolpert:
1 | buf[19] = 0x05; |
Warum? Und was passiert, wenn das nicht gemacht wird (also an dieser Stelle ein 0-Byte verbleibt)? Ist das der von Dir beobachtete Zähler, der sich mit jedem Schaltbefehl erhöht?
Hallo, ich möchte mir schonmal die Hardware bestellen. Wir reden über sowas, richtig? https://www.ebay.de/itm/255283312809 (Einen Nano habe ich) Danke sehr!
Hallo @petersilie. Ja, dass ist richtig. Es ist wie weiter oben beschrieben. Ich habe gesehen, dass der Zähler mit jeder Schaltaktion inkrementiert wird. Es ist wahrscheinlich ein 16-bit Wert. Durch die ganze Probiererei scheint der Zähler aus der Cloud mittlerweile bei 0x0537 zu stehen?!? Es passiert erst einmal nichts offensichtliches, wenn man das weg lässt. Keine Ahnung was das ist.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
@Mag C. (magcode): Ja das Modul verwende ich auch. Wichtig ist, dass es ein NRF24L01*+* (Plus) ist.
:
Bearbeitet durch User
Thomas B. schrieb: > Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu > dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich > daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, > ggf. auch der Strom, aber spätestens bei der Leistung stimmt es > zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe > hier einen HM-1500) Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe geschaltet? Wenn wir die Verläufe über ein paar Stunden betrachten, idealerweise mit gleichzeitiger Beobachtung der Ausleuchtung der 4 Solarpanels, dann kommen wir bestimmt hinter die genaue Bedeutung der einzelnen Felder. Der WR-Typ wird ja vielleicht in einem der bisher als "unbekannt" gekennzeichneten Bytes/Bits übertragen. Oder vielleicht ist er in der Seriennummer kodiert? Oder die DTU fragt das bei der Einrichtung einmalig ab?
Angehängte Dateien:
martin schrieb: > Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden Hallo zusammen, leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, wie es hier voran geht. Danke an alle Beteiligte. Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher schon mal aufgenommen hatte: Könnte es vielleicht sein, dass der Inverter generell auf einem anderen aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die Interferenzen sind. Nur so eine Idee - auch wenn das von den im FCC Report genannten Frequenzen abweichen würde. Falls das den Hersteller überhaupt interessiert... (grübel)
Angehängte Dateien:
martin schrieb: > martin schrieb: >> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden > > Hallo zusammen, > leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, > wie es hier voran geht. Danke an alle Beteiligte. > > Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher > schon mal aufgenommen hatte: > Könnte es vielleicht sein, dass der Inverter generell auf einem anderen > aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner > Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. > Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das > wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben > erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die > Interferenzen sind. > > Nur so eine Idee - auch wenn das von den im FCC Report genannten > Frequenzen abweichen würde. Falls das den Hersteller überhaupt > interessiert... (grübel) Das ist momentan bei mir nicht der Fall. Die WR senden auf den festen Channel-Frequenzen, wie es aussieht. Keine Ahnung, was damals alles aktiv war bei Deinen Aufnahmen. Das war auch komisch mit den instabilen Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Der WR scannt die Kanäle durch bis er was empfangen hat und, wie es aussieht, sendet er dann immer 3 Antwort Telegramme, oft auf unterschiedlichen Frequenzen. (Telegramme nicht näher untersucht) Die Kanalwahl hat erst mal nichts zu tun mit der übermittelten Zeit. Das Sonagramm der Aufnahme ist etwas schwach, hatte nur ein Stück Draht als Antenne.
:
Bearbeitet durch User
B. G. schrieb: > Das war auch komisch mit den instabilen > Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Ok, danke für die Rückmeldung. Ich werde das bei Gelegenheit nochmal nachmessen.
> Der WR scannt die Kanäle durch bis er was empfangen hat.
Deshalb wird vmtl immer mit 15 Retransmits gesendet.
Auch der DTU scannt vmtl einfach die Kanäle durch, die Telegramme werden
ja genügend oft wiederholt.
Hallo, ich versuche gerade mal durch den Code zu gehen und diesen zu verstehen. Dabei ist mir aufgefallen, das der Wert 0x05 an Stelle 19 gesetzt wird:
1 | buf[19] = 0x05; |
dennoch ist er bei deiner Ausgabe aber immer an Stelle 18:
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben werden ? Vielen Dank
Marcel schrieb: > Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben > werden ? Hallo Marcel. Nein Du hast nichts übersehen. Das rudimentäre Testprogramm zur Simulation der DTU schreibt an dieser Stelle immer eine 0x05. So ist es momentan noch, weil wir die Bedeutung dieses Wertes noch nicht kennen. Siehe Nachricht vom 27.03.2022 19:34 an Petersillie. Das Beispiel was Du anführst ist aus einem aktuellen Scan der Kommunikation zwischen DTU und WR. Hier steht dieser "Zähler" jetzt schon auf 0x0537.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Siehe auch Nachricht vom 25.03.2022 15:35: Dieser Zähler inkrementiert sich, wenn man aus der Hoymiles Cloud heraus eine Schaltaktion durchführt.
1 | Turn unit off: |
2 | C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 |
3 | 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 |
4 | Turn unit on: |
5 | C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 |
6 | 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 |
7 | Turn unit off: |
8 | C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 |
9 | 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 |
10 | Turn unit on: |
11 | C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 |
12 | 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1 |
Vielen Dank, ist aber auch ein witziger Zufall, das genau 05 um eine Stelle nach vorne gerückt ist. Somit hat der Counter da 16 bit, ergo 4 Stellen. Danke
Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine erste Testimplementierung in Python für RaspberryPi. Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf Kanal 40, ansonsten immer auf Kanal 3 zuhören. Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit einer DTU in Kontakt war. Ergebnis: siehe Anhang. (Programm siehe https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)
:
Bearbeitet durch User
Hallo zusammen mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren. Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB Leistung der letzten Tage, Wochen, Insgesamt?
Martin G. schrieb: > Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine > erste > Testimplementierung in Python für RaspberryPi. > > Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf > Kanal 40, ansonsten immer auf Kanal 3 zuhören. > > Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit > einer DTU in Kontakt war. > > Ergebnis: siehe Anhang. > > (Programm siehe > https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py) Hardware Setup, Software? Viele unterstützen und sollten es auch nachbauen Können. Danke
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.
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
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😪😪
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.
Thomas B. schrieb: > Die Seriennummer habe ich leider bisher nur auf der Rückseite Schei....... Ohne die Nummer keine Kommunikation?
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 ;-)
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?
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 ;-(
Angehängte Dateien:
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
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
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
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
(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!
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
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...
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
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
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.
Angehängte Dateien:
-
Cloud-01.png
9,8 KB -
Cloud-02.png
180 KB -
Cloud-03.png
31 KB -
Cloud-04.png
29 KB -
Cloud-05.png
38 KB
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.
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.
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
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).
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 |
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
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?"
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
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?
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.
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
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]
...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?
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
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.
Angehängte Dateien:
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.
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
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?
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
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?
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
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
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
> 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
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
HM-1200 1161xxxxxxxx HM-1500 1161xxxxxxxx
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
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
HM-350: 1121 72xxxxxx HM-700: 1141 74xxxxxx
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
Angehängte Dateien:
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.
Angehängte Dateien:
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.
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
Hallo, hab nen HM-1200 116172216067 Tolles Projekt bin mal auf das Ergebnis gespannt.
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, ...
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?").
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
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
Angehängte Dateien:
Logs von meinem HM-600, auf die Schnelle ein altes Projekt umgeändert.
Angehängte Dateien:
-
response_packet.png
14 KB
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?
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.
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
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?
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.
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)
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.
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
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)
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?
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?
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...
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?
Angehängte Dateien:
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"
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
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.
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
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?
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!
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
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.
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
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
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
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.
...hier ein scan von meinen 2 (HM-350 und HM-700) WR
Carsten B. schrieb: > Ich habe sie einfach umbenannt... Ach das geht? lass uns das gerne mal in einem separaten Thread erörtern? :-)
Angehängte Dateien:
-
220422-excel-01.png
310 KB
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
Angehängte Dateien:
-
Diagramm.PNG
29 KB -
Diagramm2.PNG
8,5 KB
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 ? :)
Angehängte Dateien:
-
220422-excel-02.png
26 KB
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.
> 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
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
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 :-)
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
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.
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
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
Angehängte Dateien:
-
plot_response_times.png
39 KB
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".
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
Angehängte Dateien:
-
HM1200_Heinz.PNG
2 KB
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.
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?)
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
> 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?"
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
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!
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
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 ...
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.
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.
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... ch bekunde Interesse :-) Habe allerdings einen HM-1200
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.
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!
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 :)
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...
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... Da hätte ich großes Interesse :-)
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 ….
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.
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
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
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?
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.
Angehängte Dateien:
-
ChannelMID.png
3,9 KB
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
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.
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.
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 ?
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
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
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?"
Angehängte Dateien:
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.
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
Angehängte Dateien:
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
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.
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...
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
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.
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.
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.
Angehängte Dateien:
-
2022-04-06_19_05_49.png
28 KB
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.
@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
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
So langsam wird mir klar, warum ich auf dem WLAN-Band so einen hohen Hintergrundstörnebel gemessen habe. Echt bizarr.
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.
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
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.
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.
> 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.
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.
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...
Angehängte Dateien:
-
HM-1500_20220407_01.png
37 KB
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
Angehängte Dateien:
-
HM-1500_20220407_02.png
29 KB -
HM-1500_20220407_02_graph.png
140 KB
Und ich glaube ich habe auch die Temperatur gefunden...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.