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 ?
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.
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.
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
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.
(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).
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
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.
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
intchannels[]={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.
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.
"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().
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.
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
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.
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.
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
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.
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.
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,
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.
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.
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.
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
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.
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:> @ 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
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.
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?
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)
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.
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:
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.
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)
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:> 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 ;-(
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.
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
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.
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)
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).
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:
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.
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
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.
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]
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...
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.
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
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
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.
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
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:
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
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.
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?
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"
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.
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
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 ? :)
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.
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...?
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
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
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
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
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 ...
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... ;-)
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...
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,
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:
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.
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.
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?"
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.
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.
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.
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.
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.
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...
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)
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang