Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?

[Thomas B. (tbnobody)]

Und ich glaub ich hab den Power Faktor gefunden. Zumindest korreliert 
der Graph recht gut zu dem was der Gosund Zwischenstecker aufzeichnet 
(und im Grafana landet).

[Thomas B. (tbnobody)]

B. G. schrieb:
> 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 B. G.,

könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse 
nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere 
Pakete und Frequenzen interessieren.

[B. G. (golf2010)]

Thomas B. schrieb:
> könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse
> nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere
> Pakete und Frequenzen interessieren.

Das Bild vom 6.4. ist ja noch verfügbar.
Ich hab gerade nochmal so eine Aufnahme gemacht. Komischerweise sendet 
der HM-600 gerade andere Pakete.
Anbei der Frequenzverlauf über die Zeit und die empfangenen Pakete.

[B. G. (golf2010)]

nochmal eine kleine Aufnahme. Jetzt sendet der HM-600 wieder anders.
Aufnahme ist etwas schwach, aber man erkennt die Frequenzen noch.

[Thomas B. (tbnobody)]

Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig 
machen können. Die Port Zuordnung ist ggf. noch zu verifizieren.

In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen 
enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt 
zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der 
täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes 
gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem 
was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man 
summiert die letzten 3 Wochen).
Kann jemand ein ähnliches Phänomen beobachten?

[Mike (Gast)]

Thomas B. schrieb:
> Habe noch die Gesamtproduktion sowie die täglichen Counter
> ausfindig
> machen können. Die Port Zuordnung ist ggf. noch zu verifizieren.
>
> In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen
> enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt
> zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der
> täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes
> gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem
> was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man
> summiert die letzten 3 Wochen).
> Kann jemand ein ähnliches Phänomen beobachten?

Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in 
Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen 
später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt 
habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst.

[Thomas B. (tbnobody)]

Mike schrieb:
> Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in
> Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen
> später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt
> habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst.

Das ist wunderbar dass das so passt!

Ich habe eine ähnliche Tabelle auch für einen HM-600 erstellt. 
Vielleicht findet der ein oder andere darin noch Werte die er bisher 
noch nicht hat. (AC_I z.B.)

Die letzten 4 Bytes in der HM-600 0x83 Message sind im gleichen 
unbekannten Format wie die letzten 4 Bytes in der 0x84 Message des 
HM-1500 (letzte 4 Bytes ohne die letzte CRC)

[Mike (Gast)]

Thomas B. schrieb:

> Vielleicht findet der ein oder andere darin noch Werte die er bisher
> noch nicht hat. (AC_I z.B.)

Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw. 
die S-Miles Enduser App zeigt keine an.

[Thomas B. (tbnobody)]

Mike schrieb:
> Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw.
> die S-Miles Enduser App zeigt keine an.

Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die 
entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese 
entsprechen exakt der Leistung (P) durch der Spannung (V).


[1] 
https://www.mikrocontroller.net/attachment/553106/HM-1500_20220408_01.png
[2] 
https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png

[Mike (Gast)]

Desweiteren kann die Energie (Wh) und die Leistung (W) jeweis für 
Tag/Monat/Jahr/Gesamt angezeigt werden.

Jedes PV Modul hat auch eine Ortangabe (0,0 / 0,1 / 0,2 / 0,3)

[Martin P. (mpolak77)]

Thomas B. schrieb:
> Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die
> entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese
> entsprechen exakt der Leistung (P) durch der Spannung (V).

Also ich kann die HM-600 Decodierung auch für den HM-700 bestätigen.

Beim HM-350 bin ich auch etwas weiter gekommen:
Da sind die DC Daten im 0x1:
DC_V, DC_A, DC_P (and der selben Stelle wie bei HM600 .. der erste byte 
ist 10 und das letzte ist 0.

und AC Daten kommen in 0x82:
2byte Frequenz /100
2 byte Power /10
2 byte u1 (entweder 1 oder 0)
2 byte Strom /100
2 byte u2 (1000 dezimal)
... die restlichen Bytes geben für mich noch keinen Sinn. Spannung fehlt

Mit dem NRF24Sniff code, der TimePacket, gefolgt von 0x81,0x80,0x82 
Pakete schickt, bekomme ich vom HM-350 sehr oft mit einem 0x81? Das ist 
doch Command-Error?
Schicke ich nur das TimePacket, kommen nur die 01/02/82 zurück

[Martin P. (mpolak77)]

Thomas B. schrieb:
> Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig
> machen können. Die Port Zuordnung ist ggf. noch zu verifizieren.

Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die 
Tagesleistung pro Eingang sind?

Das ist nämliche meine Theorie bei der Auswertung des HM-700 .... die 
Werte sind mir zu ähnlich (und wir hatten sehr wechselhaftes Wetter)

[Martin P. (mpolak77)]

Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut)

01:
2bytes unbekannt "1"
2bytes dc_volt  / 10
2bytes dc_amps  / 100
2bytes dc_power / 10
2bytes unbekannt "0"
2bytes Total_w
2bytes Daily_w
2bytes ac_volt / 10

82:
2bytes ac_freq / 100
2bytes ac_power / 10
2byte  unbekannt "0"
2bytes ac_current / 100
2byte  unbekannt  "1000" vielleicht /10 Power Factor in %?
2bytes temp / 10
2bytes unbekannt ansteigend
2bytes random

[Mag C. (magcode)]

Oliver F. schrieb:

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

Hallo, super Arbeit! Das ist sehr sauber aufgesetzt.
Wäre es möglich die "Konfiguration via Seriell" zu unterstützen?

Mit Konfiguration meine ich: Die Seriennummer der/des Hoys. 
(Idealerweise nutzerfreundlich mit der "richtigen" Seriennummer.)
Weiterhin fände ich es gut, wenn man das Senden/Empfangen pausieren 
könnte sowie den Scanintervall einstellen könnte.
Ich werde selber mal bisschen probieren, aber an Deine C++ Skills komme 
ich sicher nicht ran :-)

[Thomas B. (tbnobody)]

Martin P. schrieb:
> Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die
> Tagesleistung pro Eingang sind?

Aehm ja, die  Day1 - 4 ist jeweils pro Port. Was ich noch nicht 
verfiziert habe ist die genaue Portzuordnung.

[Oliver F. (of22)]

Mag C. schrieb:
> Hallo, super Arbeit! Das ist sehr sauber aufgesetzt.
> Wäre es möglich die "Konfiguration via Seriell" zu unterstützen?

Hallo Mag.
Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas 
dauern, da ich in Osterurlaub fahre.
Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im 
EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du 
willst ja sicher nicht bei jedem Start erst die Seriennummern wieder 
schreiben, oder?

[Mag C. (magcode)]

Oliver F. schrieb:
> Mag C. schrieb:
>> Hallo, super Arbeit! Das ist sehr sauber aufgesetzt.
>> Wäre es möglich die "Konfiguration via Seriell" zu unterstützen?
>
> Hallo Mag.
> Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas
> dauern, da ich in Osterurlaub fahre.
> Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im
> EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du
> willst ja sicher nicht bei jedem Start erst die Seriennummern wieder
> schreiben, oder?

Ich nutze einen Arduino Nano.
Der Gedanke bei den Seriennummern war dass man anderen/nicht so 
versierten Hoymiles Nutzern vielleicht den Einstieg etwas leichter 
machen könnte.
Man braucht im Falle des Nano ja immer noch ein weiteres Stück Software 
um die Daten auszulesen, weiterzusenden oder zu speichern. (Etwas in der 
Art baue ich gerade.) Das könnte dann auch die Konfiguration übernehmen, 
also beim Starten die Seriennummer(n) übergeben und z.b. das Scannen 
Nachts abschalten.

Wenn man das Ganze standalone auf einem ESP aufbaut (Siehe oben 
"ESPHome" Beitrag von Marcel), dann würde es vielleicht ein UI geben, wo 
man die Seriennummern eintippt...

Kein Stress! Schönen Urlaub!

[Hubi (Gast)]

Moin
Das mit der Temperatur würde mich auch interessiern, das fehlt mir noch. 
Aufbauend auf der Nano-Variante von der ahoy-Seite habe ich mir eine 
ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt, 
die recht gut funzt (siehe Bild).
Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die 
Temp?

[Thomas B. (tbnobody)]

Hubi schrieb:
> Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die
> Temp?

Hallo Hubi,

siehe [1]. Die Temperatur sollte in Telegramm 0x83 in den Bytes 17 und 
18 (wenn man bei 1 zu zählen anfängt) stehen. Der dort enthaltene Wert 
muss durch 10 geteilt werden.



[1] 
https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png

[B. G. (golf2010)]

Hubi schrieb:
> 83er, aber wo ist da die
> Temp?

ich hab die aktuellen Werte beim HM-600 mal angehängt von heute.
Temperatur steigt an von 5,1 bis aktuell 26,6°

[lpb (Gast)]

Hallo,

für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert:
Message 0x83    Start  Bytes  Unit  Factor
--------------------------------------------------
Output Level 0-5?  10    2    -    x1
Grid Cuurent    12    2    A    x100
0 or 1000      14    2    -    -1    Status info?
Temperature      16    2    °C    x10

Das, was ich 'Output Level' nenne passt in den Stufen prinzipiell recht 
gut mit meiner Ausgangsleistung zusammen (siehe Anhang). Allerdings wird 
der Wert immer wieder Null, obwohl ich eine Ausgangsleistung habe - von 
daher passt das noch nicht ganz - aber eine bessere 
Beschreibung/Erklärung habe ich noch nicht gefunden :)

Die 0x02 Daten habe ich auch überarbeitet. Die total 1 und 2 steigen 
täglich mit den Werten daily 1 und 2, von daher sollte das jetzt so 
passen:
Message 0x2      Start  Bytes  Unit  Factor
--------------------------------------------------
Total Production 1  10    2    Wh    x1
Total Production 2  14    2    Wh    x1
Daily Production 1  16    2    Wh    x1
Daily Production 2  18    2    Wh    x1
Grid Voltage    20    2    V    x10
Grid Frequency    22    2    Hz    x100
Grid Power      24    2    W    x10

Ich vermute, dass die Hoymiles Cloud die anderen Werte für die Wochen- 
und Monatsdaten ermittelt. Ebenso könnte der Power Level in % aus der 
Maximal-Leistung des Inverters und der aktuellen Leistung von der Cloud 
berechnet werden.

Ich habe übrigens auch mit dem 'poor man rx channel switching' die 
Empfangsquote der Nachrichten deutlich erhöhen können (ich sende alle 6 
Sekunden eine Anfrage), aber ich erwische damit immer noch nicht alle, 
evtl ist dabei neben dem Timing auch noch die Reihenfolge wichtig...

Auf alle Fälle reicht das schon mal, um die wesentlichen Daten erfassen 
zu können, was ich sehr cool finde. Dafür ein großes Danke an alle, die 
hier so fleißig beigetragen haben!

[Herbert K. (avr-herbi)]

Hubi schrieb:
> Moin
> ... habe ich mir eine
> ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt,...

Hallo Hubi,
würdest Du mir Bitte Deinen Source zur Verfügung stellen ? Ich habe 8266 
und auch 32 hier. "C++" kann ich allerdings noch nicht. Mir würde das 
auch erst mal so reichen, wie Du es bisher hinbekommen hast.
Viele Grüße und einen schönen Sonntag wünscht Dir Herbert

[Daniel M. (Gast)]

Hallo meine Lieben Tüftler,

den ganzen Thread am Stück lesen war jetzt doch ne Menge Input, Respekt 
für eure Arbeit.

Ich habe zwar keinen Hoymiles, allerdings eine abgewandelte Variante: 
TSUN TSOL-M800.
Dieser hat die Seriennummer 104163500316
Passend dazu könnte der Hoymiles 1141... passen.

Datenstick und die große Basisstation sind identisch, auch in den 
Anleitungen zur Cloud ist Hoymiles drin.

Ich hätte einen Wemos D1 Mini hier, suche aber noch ein passendes NRF 
Modul.
Gefunden habe ich dieses hier: 
https://smile.amazon.de/DollaTek-NRF24L01-Funk-Transceiver-Modul-antistatischem-kompatibel/dp/B07PQPFTWZ/
Alternativ hat AZDelivery noch was im Sortiment. Wäre davon was richtig?

Auch den Sourcecode für einen ESP8266, den ich mit der Arduino-Software 
laden kann, wäre hilfreich.

Parallel habe ich noch 2 SG700MD hier, deren Protokoll ich aber schon 
habe und demnächst in NodeRed die Steuerung weiterbaue.
Die Databox habe ich schon versucht, jedoch ist keine Kommunikation mit 
dem TSUN möglich. Hier ist der Chip Beken bk2461 verbaut. Was in den WR 
drin ist, werde ich nochmal schauen, wenn ich die Folien der Silikonpads 
entferne.

Zur Software an sich: ich bevorzuge NodeRed und habe dazu einen Raspi am 
start. Hier könnte man auch wegen Python schauen, jedoch bin ich damit 
nie wirklich warm geworden. NodeRed finde ich da irgendwie angenehmer :)

Programmierskills habe ich keine, finde mich aber in Beispielcode 
zurecht. C/C++ ist mir weitgehend fremd, Python ist nicht so meins, 
Arduino geht, JS in NodeRed basics vorhanden.

Wäre cool, wenn ihr mir den Start erleichtert und wir den TSUN-Kunden 
einen ähnlichen Kompfort ermöglichen können :)

lg
Daniel

[Hubi (Gast)]

Hallo Herbert u. Daniel
anbei mein Fork von der ahoy-Seite. Läuft bei mir auf einem Wemos D1 
mini.
Was ist anzupassen:

in wifi.h :
 - SSID_PREFIX zur Suche des besten WLan; wenn auskommentiert, werden 
alle WLans in der Nähe beachtet
 - password für Wlan

in ModWebserver.h: die defines für Serverport und OTA-Zugriff

Einfach im Browser die IP eingeben, dann kommt die Tabelle wie oben.
Wenn man IP/data eingibt, kommen nur die Werte als Text, das ist meine 
einfache Datenschnittstelle, die ich dann mittels RasPi und cron 
abspeichere.

Ich benutze die Arduino IDE, also wer platform.io benutzt muss sich das 
anpassen.

Viel Spaß

[Herbert K. (avr-herbi)]

@Hubi,
Herzlichen Dank, die Beschäftigung die nächsten Stunden (Tage) ist nun 
gesichert  :-)
Einen schönen Abend wünsche ich Dir. Danke nochmals.

[Marcel A. (a-marcel)]

Hallo,

mithilfe von

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

hab ich jetzt auch das Programm (mit Circular Buffer) auf meinem ESP32 
zum laufen bekommen. Danke Martin.

Heute lief das ganze mal ein paar Stunden und ich habe dazu mal ein paar 
Fragen.

Was genau ist denn dieses "// Packet control field - PID Packet 
identification" ?

// Packet control field - PID Packet identification
    uint8_t val = (p.packet[1] >> 1) & 0x03;
    Serial.print(val);
    Serial.print(F("  "));

Ebenfalls habe ich mal ein paar Debugausgaben mit hier rangehangen. Ich 
hab ja einen HM-400 und bekomme jetzt sehr viele dieser 0x81 Antworten. 
Wobei diese immer gleich per PID sind.

Und ich hatte sogar eine 0x82 dabei.

Weiß da schon jemand etwas mehr über dessen Bedeutung?

Marcel

[Martin P. (mpolak77)]

Der HM-400 ist ja auch ein Single Modul Inverter … wahrscheinlich wirst 
du da die Dekodierung für den HM-350 verwenden können, wie ich sie 
gestern gepostet habe.

Bei mir hat es auch gereicht nur das TimePacket zu schicken … damit 
liefern beide Wechselrichter (350 und 700) die relevanten Nachrichten.

Ich habe mal alles aus dem ursprünglichen Code geschmissen was ich nicht 
brauche und schicke die Dekodierung für beide WR per RSyslog und Mqtt 
raus (der ESP ist am Dachboden installiert, damit er beide WR sieht)

[Marcel A. (a-marcel)]

Hallo Martin,

die Werte des HM hatte ich selber schon rausgefunden und gepostet. Ich 
nutze die schon seit ein paar Wochen. Mit deinem Code konnte ich es 
jetzt aber auf diese Interrupt Methode und CircularBuffer umstellen und 
sehe jetzt die o.g. Daten. Würde schon gerne wissen was das ist und wozu 
das gut ist ;)

Ebenfalls wäre ich super dankbar, wenn jemand den Request von der DTU 
Pro rausfindet um die Einspeisung zu limitieren. Dann könnte ich 
demnächst auf Akkubetrieb mit Konstanteinspeisung umstellen.

Marcel

[Ziyat T. (toe_c)]

lpb schrieb:
> Hallo,
>
> für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert:
> Message 0x83    Start  Bytes  Unit  Factor
> --------------------------------------------------
> Output Level 0-5?  10    2    -    x1

hallo
dieser "output level" wert ist interessant!
in hoymiles modbus register 0xC001 oder 0x9D9D "Limit Active Power" wird 
der wert als % eingegeben, und zwar für MI series zwischen 10-100% für 
MH series 2-100% der wr-nennleistung.
die frage ist, wie passt das zusammen? oder gibt es ein anderer befehl 
zur limitierung?

Ziyat T.

[Herbert K. (avr-herbi)]

Manchmal sind es die kleinen Dinge dieser Welt, über die man sich freut 
:-)
Nach dem ich noch einige LIBs zu meiner Arduino: 1.8.13 hinzufügen 
mußte,
habe ich mich durch div. warnings gekämpft bis ich gefunden habe, was 
der Grund für "exit status 1" war:

wifi.h:76:54: error: ...

....

....

exit status 1

cannot pass objects of non-trivially-copyable type 'class String' 
through '...'

(Source von "Hubi" vom 10.04.2022 17:49)

in wifi.h habe ich dann diese Zeile auskommentiert:

//    DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID);

Keine Ahnung, warum da gemeckert wird. Dafür reichen meine Kenntnisse 
leider nicht aus.

Nun sehe ich die Webseite und muss jetzt noch die Verbindung zum 
nRF24L01+ Modul herstellen.
Ich freue mich jedenfalls, das ich schon mal bis hier hin gekommen bin. 
Danke "hubi"

[Hubi (Gast)]

Sorry, dass ich nicht erwähnt habe welche libs ich noch benutze 
(TimeLib, Pinger). Warum du den error mit exit status=1 in wifi.h hast 
ist mir unverständlich. Ich habe dort nur eine warning und mit
DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID.c_str());
ist die warning weg.

[Daniel R. (Gast)]

Ein herzliches DANKE an alle beteiligten für die großartige Arbeit 
bisher! Vielen Dank Hubi für deinen Arduino-Code für den D1 mini. Die 
Beobachtungen von Herbert K. kann ich bestätigen. Mit DEBUG_OUT.printf 
("Bestes Wifi unter: %s\n", SSID.c_str()); habe ich jedoch keinen Fehler 
mehr, sodass ich nun den Webserver erreiche. Tests mit dem HM-600 stehen 
noch aus...

[Martin P. (mpolak77)]

Marcel A. schrieb:
> Was genau ist denn dieses "// Packet control field - PID Packet
> identification" ?

Hallo Marcel,

https://www.sparkfun.com/datasheets/Wireless/Nordic/nRF24L01P_Product_Specification_1_0.pdf

Section 7.3.3.2
The 2 bit PID field is used to detect if the received packet is new or 
retransmitted. PID prevents the PRX device from presenting the same 
payload more than once to the receiving host MCU. The PID field is 
incremented at the TX side for each new packet received through the SPI. 
The PID and CRC fields are used by the PRX device to determine if a 
packet is retransmitted or new. When several data packets are lost on 
the link, the PID fields may become equal to the last received PID. If a 
packet has the same PID as the previous packet, nRF24L01+ compares the 
CRC sums from both packets. If the CRC sums are also equal, the last 
received packet is considered a copy of the previously received packet 
and discarded.

Was es allerdings in dem Code macht, hab ich nicht weiter nachgeforscht. 
Ich hab ja auch nur den Code von Github genommen und das stdinout / 
CircularBuffer Thema für den ESP aus dem Weg geschafft.

[Martin P. (mpolak77)]

Früher oder später wird auch eine etwas robustere Hardware interessant 
werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 
Combo gefunden:

http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge
Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein. 
Sollte als Ersatz-DTU aber auch seinen Dienst machen.

Hier noch etwas minimalistischer:

https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/

was mich bei letzterem allerdings verwundert, sind die fehlenden 
Widerstände, die der ESP12 normalerweise braucht.

[Thomas B. (tbnobody)]

Martin P. schrieb:
> Früher oder später wird auch eine etwas robustere Hardware interessant
> werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01
> Combo gefunden:

Mit einem ESP32 sähe das hier auch ganz nett aus:
https://www.openhardware.io/view/698/MY-ESP32-GW

[Herbert K. (avr-herbi)]

Wieder einen kleinen Schritt weiter  :-)  worüber ich mich freuen kann 
:-)
Dies habe ich aktualisiert. "....SSID.c_str());" Nun klappt das 
Compilieren auch damit  :-)
Durch Ändern der S/N meiner HM400 bekomme ich die ersten 3 Werte 
vermutlich sogar richtig :-)  wieder ein kleiner Schritt  :-)
Die restlichen Werte sind leider noch "0"  . Aber so weiss ich jetzt das 
die HW schon mal tut  :-)  ali-003.jpg hat nicht funktioniert. Mit 
ali-005.jpg klappt es so weit schon mal.

[Dietrich (Gast)]

Moin moin,

ich habe gerade mal probiert das Ganze für mein Wemos D1 zu compilieren. 
Bekomme das Programm auch hochgeladen und eine IP. Nur leider kann ich 
nicht auf die Website zugreifen. Pingen kann ich den D1, somit sollte 
die Netzwerkverbidung stehen.

Habe hier noch einen PiHole usw. laufen und somit nicht wirklich 
"Standard" Netzwerksettings. Kann es sein das sich der D1 in einer 
Whileschleife verläuft?
Kann ich das Debuggin irgendwie aktivieren? Habe schon DEBUG_SEND auf 1 
gesetzt, im Serial-Monitor ändert das jedoch die Ausgabe nicht.

Grüße aus HH
Jan

[Herbert K. (avr-herbi)]

Herbert K. schrieb:
ali-003.jpg funktioniert ebenfalls (konnte meinen Beitrag leider nicht 
mehr editieren)

[Herbert K. (avr-herbi)]

Dietrich schrieb:
...
Hallo Jan,
Keine Ahnung, welchen Source Du verwendest. Ich habe den von Hubi und 
der Start in der Seriellen Console sieht zu Beginn so aus wie in der 
Anlage.
Vielleicht hilft Dir das als Vergleich. Webserver ist vom Firefox und 
Chrome erreichbar. Egal ob der NRF24L01+ vorhanden ist oder nicht.

[Dietrich (Gast)]

Moin Herbert,

ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl. 
SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und 
mich wieder melden.

Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss 
sich mein D1 weghängen.

[Hubi (Gast)]

Hallo
da inzwischen einige Leute meine Source benutzen und noch Probleme 
haben, meine Frage: Soll ich eine Version bereitstellen mit einer 
Settings.h, in der genau beschrieben ist was einzustellen ist?

[Marcel A. (a-marcel)]

Hubi schrieb:
> Hallo
> da inzwischen einige Leute meine Source benutzen und noch Probleme
> haben, meine Frage: Soll ich eine Version bereitstellen mit einer
> Settings.h, in der genau beschrieben ist was einzustellen ist?

Würde sich anbieten denke ich, da sonst viele Fragen bzgl. des Programms 
aufkommen, wir aber noch herausfinden  müssen wie Channel Hopping und 
Werte setzen funktioniert sowie weitere Antworten/Werte herausfinden 
müssen.

Bisher ist ja alles noch in Entwicklung.

Marcel

[Herbert K. (avr-herbi)]

Martin P. schrieb:
> Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut)
>
> 01:
> 2bytes unbekannt "1"
> 2bytes dc_volt  / 10
> 2bytes dc_amps  / 100
> 2bytes dc_power / 10
> 2bytes unbekannt "0"
> 2bytes Total_w

Hallo Martin P., vielen Dank für Deine Analyse.
Im Telegram "01" für die HM-Single (300/350/400) ist dies
-- 2bytes unbekannt "0" --
evt. der Überlauf von
-- 2bytes Total_w --

Bei einem WR habe ich schon einen Überlauf, bei einem 2. WR erwarte ich 
den Überlauf in ca. 5 Tagen je nach Sonne. Dann werde ich das sehen.

Habe die Telegramme "01" und "82" erst mal so von Dir übernommen und bei 
meinen 2 HM 400 scheint das auch zu passen.

Danke an ALLE für die bisherige Arbeit.

[Martin P. (mpolak77)]

Herbert K. schrieb:
> Im Telegram "01" für die HM-Single (300/350/400) ist dies
> -- 2bytes unbekannt "0" --
> evt. der Überlauf von
> -- 2bytes Total_w --

das ist ein guter Tipp - und macht auch Sinn, weil die 64 kWh (mit nur 
16 bit) sind ja doch bald mal erreicht" .... bei mir dauert das noch .. 
bin erst bei 20 kWh...


Was mir generell noch aufgefallen ist: Gestern war meine Hoymiles DTU 
als Offline im System und die Cloud zeigte auch keine aktuellen Daten. 
Mein ESP hingegen loggte ganz normal in den IOBroker mit.
Heute Früh zeigt die Cloud plötzlich die fehlenden Daten von gestern 
bist Mitternacht an. Nach einem Aus/Einstecken der DTU loggt sie heute 
wieder normal.

Entweder hatte die Cloud gestern ein Problem, oder die WR dürften eine 
Art Historie speichern und die DTU hat sie heute nach Sonnenaufgang noch 
irgendwie rausgeschickt?

[Dietrich (Gast)]

Hubi schrieb:
> Hallo
> da inzwischen einige Leute meine Source benutzen und noch Probleme
> haben, meine Frage: Soll ich eine Version bereitstellen mit einer
> Settings.h, in der genau beschrieben ist was einzustellen ist?

Hallo Hubi,

ich denke das ist eine gute Idee um die Source von dir besser Nutzbar zu 
machen.

Grüße
Jan

[Dietrich (Gast)]

Dietrich schrieb:
> Moin Herbert,
>
> ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl.
> SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und
> mich wieder melden.
>
> Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss
> sich mein D1 weghängen.

Hallo zusammen,

soo Fehler gefunden. Ich habe keine Fritzbox, daher funktiniert der 
TimeServer define #define TIMESERVER_NAME "fritz.box" natürlich nicht. 
Einfach auskommentieren und Hubis Angabe "pool.ntp.org" benutzen.

Nun läuft der Webserver - jetzt muss nur noch der WR ankommen... :)

Grüße
Jan

[Marcel A. (a-marcel)]

Hallo,

ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp.

Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten 
im Log ?

1649772015 00 00DC 1B 2  95 73109025 73109025 010001017F00C702F900005E44039E08FBA3F89D AF08 A2DC DAA8 AF08 E3D3 E787 AF08 A2DC AF08 1F4A AF08 7860 0978 A436 A2DC A9E2 AEB6 08FE AF08 A2DC AF08 A9E2 25BB A2DC A9E2 F891
hm400:  Voltage: 38.30V, Ampere: 1.990A, Power: 76.10W
        Total Production: 24.132kW, Daily Production: 926.00W, AC Voltage: 229.90V

(erste spalte ist epochtime, welches ich hinzugefügt habe)

Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen 
des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ?

Marcel

[Herbert K. (avr-herbi)]

Marcel A. schrieb:
> Hallo,
>
> ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp.
>
> Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten
> im Log ?

Hallo Marcel, ja bei mir kommt auch des öfteren etwas merkwürdiges. 
Bisher mache ich mir da nicht viel drauss.
Bin froh, das ich das mit 2 Stk. HM400 so weit hinbekommen habe, trotz 
fehlender "C++" Kenntnisse.
Ich versuche die nä. Tage mal Fehler zu produzieren, ob man die in den 
unbekannten Feldern wiederfindet.

An die "C++" Programmierer:  Bitte was muss ich wo ändern, um die 4 Byte 
zu
Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr 
als 65535 werden können ? Danke schon mal.

[Dietrich (Gast)]

Martin P. schrieb:
> Früher oder später wird auch eine etwas robustere Hardware interessant
> werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01
> Combo gefunden:
>
> 
http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge
> Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein.
> Sollte als Ersatz-DTU aber auch seinen Dienst machen.
>
> Hier noch etwas minimalistischer:
>
> https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/
>
> was mich bei letzterem allerdings verwundert, sind die fehlenden
> Widerstände, die der ESP12 normalerweise braucht.

Hallo,

ich habe mal den Creator angeschrieben ob es okay ist, wenn wir uns ein 
paar Platinen machen lassen. Wenn das okay bist, bestelle ich mal 5 
Stück. 4 davon würde ich dann kostenlos an die Hauptverantwortlichen 
hier verschicken, wenn ihr was damit anfangen könnt. Quasi als Support 
:)

Grüße
Jan

[Martin P. (mpolak77)]

> Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen
> des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ?
> Marcel

Ich habe solche bei mir auch gesehen … habe aber auch die gleiche 
CodeBase..

[Chris (Gast)]

Hallo zusammen, ich bin heute auf der Suche nach einer DTU alternative 
auf euren Thread gestoßen. Dies ist mein erster Eintrag hier im Forum. 
Ich bin absolut beeindruckt was hier alles geleistet wurde. Ich bekomme 
auch bald einen HM-1500 und möchte die Daten selbst per MQTT auslesen. 
So wie ich es gelesen habe, besteht die Hardware aus ESP8266 + NRF24L01. 
Die hab ich zufällig schon rumliegen. Wo finde ich denn den Code?

Viele Grüße an die großartigen Unterstützer, Analysten, Programmierer 
hier!!!!

Gruß Chris

[Hubi (Gast)]

Herbert K. schrieb:
> An die "C++" Programmierer:  Bitte was muss ich wo ändern, um die 4 Byte
> zu
> Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr
> als 65535 werden können ? Danke schon mal.

Ich mache das so:

float extractValue4 (uint8_t *p, int divisor) {
//-------------------------------------------
  uint32_t ret  = *p++;
  for (uint8_t i = 1; i <= 3; i++)
    ret = (ret << 8) + *p++;
  return (ret / divisor);
}

Du übergibts einen Zeiger auf die Stelle in der Payload wo dein 4-byte 
Wert beginnt und als Divisor 1 (kannst du also auch weglassen), etwa so:
[b]
float wert = extractValue (&payload[??], 1)
[/b]
Das findest du aber alles in meinem am 10.4. geposteten Code.

[Hubi (Gast)]

Im Anhang überarbeitete Version meiner Software, die auf ESP als auch 
Arduinos läuft. Neu ist:
- extra Settings.h mit den möglichen Einstellungen
- automatische Konvertierung der WR-Seriennummer in diese umgedrehte 
Radio-ID
- Source Sonne.h enthält Berechnung von Sonnenauf- und -untergang => 
nachts nicht mehr den WR abfragen

[Jan-Jonas S. (janjonas_s)]

@Hubi, kannst Du das bitte via git bereitstellen? Sourcen in zip-Files 
ohne Versionierung in Foren teilen ist wenig hilfreich. Danke.

[Peter L. (leliep)]

Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss 
der Funkmoduls an den ESP8266 D1 mit Hubis Software (Danke dafür!) nicht 
korrekt gemacht habe. Die Software an sich läuft und verbindet sich 
problemlos mit meinem WLAN, die Web-Oberfläche kann ich auch aufrufen, 
aber alles 0.

Möglicherweise bin ich nicht der Einzige, der nicht sicher ist, welche 
Pins ausser den in Settings.h erwähnten mit dem ESP verbunden werden 
müssen.

Meine Bitte: wäre jemand so nett, die komplette Verschaltung dieser 
Konfiguration zu dokumentieren...? Dankeschön!

aus Settings.h:
// Hardware configuration
#ifdef ESP8266
#define RF1_CE_PIN  (D4)
#define RF1_CS_PIN  (D8)
#define RF1_IRQ_PIN (D3)

GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für 
den NRF24) sind klar.

Aber was ist mit MO (D7?) und MI (D6?)...

[Herbert K. (avr-herbi)]

Peter L. schrieb:
> Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss
....
> Aber was ist mit MO (D7?) und MI (D6?)...

Hallo, natürlich musst Du MISO, MOSI, CLK anschliessen, damit die RF24 
LIB funktioniert. Einfach mal in die Datenblätter schauen vom ESP8266 
und NRF24...
Hab die HW gerade nicht zur Hand.

[Daniel M. (daniel_m821)]

Peter L. schrieb:

> aus Settings.h:
> // Hardware configuration
> #ifdef ESP8266
> #define RF1_CE_PIN  (D4)
> #define RF1_CS_PIN  (D8)
> #define RF1_IRQ_PIN (D3)
>
> GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für
> den NRF24) sind klar.
>
> Aber was ist mit MO (D7?) und MI (D6?)...

Ich habe:
D4 -> CE
D8 -> CSN
D3 -> IRQ
D5 -> SCK
D6 -> MIso
D7 -> MOsi
VCC und GND ergeben sich.

Leider auch noch kein Signal.

@Hubi: war da nicht noch was mit der "ersten Taufe" damit der Gerät 
spricht?
Sonnenoffest hab ich mal auf 120min gestellt, du verwendest da UTC, 
oder?

Sonst sehr gute Arbeit :)
Vielen dank!

[Martin P. (mpolak77)]

Es gibt viele Bespiele in Google - aber halte dich nicht an die … 
sondern Google nach nrf24l01 Pinout und welchen Controller du hast. 
Verbinde die SPI Pins wie sie der Controller hat und wähle für CE und 
CSN und IRQ Die Pins aus dem Code. Beachte, dass es unterschiedliche 
Nomenklatur gibt (deshalb haben diese Pinout Bilder immer mehrere Namen)

[Peter L. (leliep)]

OK, wie auch von Daniel geschrieben, habe ich es so gemacht:

NRF24       ESP8266
----------------------
RF1_CE_PIN  D4
RF1_CS_PIN  D8
RF1_IRQ_PIN D3

RF1_MO_PIN  D7
RF1_MI_PIN  D6
RF1_SCK_PIN D5

GND         G
VCC(5V)     5V (NRF24 mit Spannungsregler-Platine)
VCC(3,3V)   3V3

Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>.
Morgen kommt die Sonne wieder ;-)

[Daniel M. (daniel_m821)]

Peter L. schrieb:
> OK, wie auch von Daniel geschrieben, habe ich es so gemacht:
>
> NRF24       ESP8266
> ----------------------
> RF1_CE_PIN  D4
> RF1_CS_PIN  D8
> RF1_IRQ_PIN D3
>
> RF1_MO_PIN  D7
> RF1_MI_PIN  D6
> RF1_SCK_PIN D5
>
> GND         G
> VCC(5V)     5V (NRF24 mit Spannungsregler-Platine)
> VCC(3,3V)   3V3
>
> Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>.
> Morgen kommt die Sonne wieder ;-)

Wir werden sehen ob ein Reboot über Nacht hilft. Ic hvermute trotzdem 
eher den initialen "Hello" Schritt, der noch fehlt, quasi ein Setup, 
damit erstmal WR und "Databox" zueinander finden.
Sonst muss ich sagen, ist der Arduino-Code echt genial, sehr sauber und 
übersichtlich.

Danke Hubi :)

[Hubi (Gast)]

Hallo zusammen
da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In 
meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob 
Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS) 
und dazu eine CS( Chip select).
Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als 
ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe.
Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software 
in Verbindung mit einem RasPi als "Datensammler" und Webserver mit 
grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder 
meine neue Weiterentwicklung kann sich bitte hier gern melden.

[Daniel M. (daniel_m821)]

Hubi schrieb:
> Hallo zusammen
> da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In
> meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob
> Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS)
> und dazu eine CS( Chip select).
> Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als
> ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe.
> Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software
> in Verbindung mit einem RasPi als "Datensammler" und Webserver mit
> grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder
> meine neue Weiterentwicklung kann sich bitte hier gern melden.

Ein Git-Account sollte nicht kompliziert sein, wäre halt praktisch.
Welche Belegung nutzt du an deinem Wemos? Vielleicht kann man das 
zusammen dort in die readme packen.

Ich warte mal auf den Reboot über Nacht, vielleicht hilft der.
Ich hab noch das große Fragezeichen, weil ich einen potentiell 
kompatiblen Typ nutze, kein originalteil.
Laut Anleitung soll ein initiales binding durchgeführt werden, ob das 
wirklich nötig ist, weiß ich nicht.
Ist es sehr aufwändig, so ein "Hello" zu implementieren, das man über 
Konsole oder Webserver anstoßen kann?

Du hast gerade den vielversprechendsten Ansatz für den ESP8266.
Ein Paypal-Spendenlink für den einen oder anderen Kaffee würde ich auch 
sehr begrüßen, genauso von den anderen, die hier so einiges beigetragen 
haben :)

Ich hoffe noch auf die Leistungsregulierung, wenn das mit der 
Kommunikation komplett klappt. Dann kann man auf Nulleinspeisung oder 
Akku-laden via NodeRed schauen, der SDM z.B. ist ja auch keine 
Raketentechnik. Da würde ich mich dann mehr einbringen, wenn ich das 
ganze richtig zum laufen gebracht hab.

lg

[Marcel A. (a-marcel)]

Hallo Daniel,

mich würde mal Interessieren, woher die Annahme kommt, das der TSUN 
gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja 
schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu 
sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche 
Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen 
technischen Angaben weichen beide eben ab.

Zusätzlich die Information, das es ein hello signal geben soll weisen 
ggf. sogar schon drauf hin, das es eine andere Software hat.

Und Hubi hat doch schon die Software bereitgestellt und erhebliche 
Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf 
GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde 
den Github Link zu einer anderen Code Version und mache einen Pull 
Request und füge diesen Code hinzu.

Marcel

[Daniel M. (daniel_m821)]

Marcel A. schrieb:
> Hallo Daniel,
>
> mich würde mal Interessieren, woher die Annahme kommt, das der TSUN
> gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja
> schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu
> sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche
> Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen
> technischen Angaben weichen beide eben ab.

In der Anleitung zu den Kommunikationsadaptern beider Hersteller steht 
Hoymiles drin. Die cloud bei Tsun läuft auf einer anderen URL, 
allerdings identisch aufgebaut. Es würde mich nicht wundern, wenn es 
eine Kopie ist.
Die Initialisierung beider Geräte auf Kommunikationsebene ist identisch 
beschrieben. Was am Ende im Protokoll passiert, kann anders sein, ganz 
klar.

> Zusätzlich die Information, das es ein hello signal geben soll weisen
> ggf. sogar schon drauf hin, das es eine andere Software hat.

Das Hello wurde schon in anderen Postings beschrieben, ebenfalls steht 
es in der Anleitung.

> Und Hubi hat doch schon die Software bereitgestellt und erhebliche
> Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf
> GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde
> den Github Link zu einer anderen Code Version und mache einen Pull
> Request und füge diesen Code hinzu.

Und ich bin ihm sehr dankbar dafür. Einen ESP8266 als Interface nutzen 
zu können, ist ein großer Vorteil.
Da ich noch einen Raspi und ein 2. RF24 Interface habe, schau ich die 
Tage mal, was ich tun kann. Werde auch noch einen Stick von Tsun 
besorgen und schauen, was der tut. Es wäre ungewöhnlich, wenn bei dieser 
Schnittmenge zwischen den Geräten, das nicht einfach nur eine Kopie mit 
kleinen Änderungen in der Ziel-URL ist, zumal selbst die 
Bedienoberfläche des Stick laut Anleitung beim Tsun identisch zu der von 
Hoymiles ist.

Das mit Git werd ich gerne mit machen, sofern Hubi nichts dagegen hat.

[Herbert K. (avr-herbi)]

Hallo,
Hubi´s Code funktioniert bei mir ohne Probleme. Ich habe auch keine 
DTU...
Der Code hat sofort funktioniert, nachdem ich die WR SN eingetragen 
habe.

1. Es muss (!) der nRF24L01+   sein. Das PLUS ist wichtig !  Ein "alter" 
nRF24L01 (ohne Plus) funktioniert NICHT !

2. Sucht im Code nach
"// radio1.printPrettyDetails();"

und übersetzt den Code mal, in dem Ihr das wieder einkommentiert
"radio1.printPrettyDetails();"

Dann findet Ihr in der Seriellen Konsole was das - sofern der RF24 
richtig verdrahtet ist - so aussieht.

Steht da NICHT  "RF Data Rate            = 250 KBPS " ist was Faul in 
der Kommunikation zum nRF24L01+ .


SPI Frequency           = 10 Mhz
                                Channel                 = 3 (~ 2403 MHz)
RF Data Rate            = 250 KBPS
RF Power Amplifier      = PA_MAX
RF Low Noise Amplifier  = Enabled
CRC Length              = Disabled
Address Length          = 5 bytes
Static Payload Length   = 32 bytes
Auto Retry Delay        = 250 microseconds
Auto Retry Attempts     = 0 maximum
Packets lost on
                   current channel      = 0
Retry attempts made for
                           last transmission    = 0
Multicast               = Disabled
Custom ACK Payload      = Disabled
Dynamic Payloads        = Disabled
Auto Acknowledgment     = Disabled
Primary Mode            = RX
TX address              = 0xe7e7e7e7e7
pipe 0 (closed) bound   = 0xe7e7e7e7e7
pipe 1 ( open ) bound   = 0x1234567801
pipe 2 (closed) bound   = 0xc3
pipe 3 (closed) bound   = 0xc4
pipe 4 (closed) bound   = 0xc5
pipe 5 (closed) bound   = 0xc6

[Martin P. (mpolak77)]

Ja, wenn die Kommunikation mit dem nrf24l01+ erst mal funktioniert, kann 
es immer noch an der Funkschnittstelle scheitern.

Einen Kondensator an +- des Moduls anlöten.
Eine Zwischenplatine mit eigenem LDO (hier scheint es auch 2 Varianten 
am Markt zu geben: mit kleinen und großen SMD caps drauf)

Eine nrf24l01+ Variante mit PA/LNA und   SMA Antenne verwenden.

Eine Dipolantenne an das kleine Modul löten.

Wenn Kondensator dran ist, auch mal PA_MODE_HIGH oder PA_MODE_MAX 
probieren.

[Hubi (Gast)]

Hallo
anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine 
Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja 
nur ein paar Strippen zu löten.
Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht 
nur für den HM-600, und auch für mehrere (unterschiedliche) WR 
gleichzeitig.
Eine Version für RasPi könnte da auch noch drin sein.
Ich überleg's mir mal. Vllt könten sich auch ein paar von uns 
zs-schließen und das mit Git machen, Aufgaben verteilen etc.

[Ziyat T. (toe_c)]

Hubi schrieb:
> Hallo
> anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine
> Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja
> nur ein paar Strippen zu löten.
> Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht
> nur für den HM-600, und auch für mehrere (unterschiedliche) WR
> gleichzeitig.
> Eine Version für RasPi könnte da auch noch drin sein.
> Ich überleg's mir mal. Vllt könten sich auch ein paar von uns
> zs-schließen und das mit Git machen, Aufgaben verteilen etc.

Hallo Hubi
Herzlichen Dank für die SW und die Bilder.
Und natürlich an dieser Stelle Danke auch an allen Beteiligten am 
Projekt.
Ich habe eine DTU-Pro und MI1500 am Laufen, da die Zero Export Funktion 
nicht so lief, wie sie sollte (und wie die Hotmiles behauptet), steuere 
ich mit einem Python/Modbus script über die DTU den MI1500, so wie ich 
es richtig halte.

Ich möchte gerne die DTU-Pro ersetzen, die SW hat Fehler (bei kleineren 
Loads) und die Hoymiles will es nicht korrigieren.

Ich werde deine SW verwenden, mit WEMOS D1 mini und nrf24l01+ PA/LNA/SMA 
Antenne.

Mich interessiert die WR Steuerung bzw. Limitierung, ich würde gerne 
hier mit machen, da ich den MI1500 über myPython/DTU prozentual 
limitieren und dort halten kann, könnte ich ev. die Limitierung heraus 
finden.

Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die 
raw-Packete beobachten?

Danke und grüsse aus dem Süden.
Ziyat T.

[Hubi (Gast)]

Toe C. schrieb:
> Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die
> raw-Packete beobachten?

Meine SW arbeitet auf Telegramm-Ebene. Ich weiß nicht so genau was du 
mit raw-Paketen meinst, wahrscheinlich eher sowas wie oben mittels 
Sniffer mitgeschnittenen Datenverkehr. Musst wohl doch den Thread 
nochmals lesen.
Steuerung des WR wäre natürlich auch ganz nett, also dass man 
limitieren kann bzw diese auch aufheben kann. Wenn da was zu 
programmieren ist bin ich dabei, auch wenn ich keine DTU habe.

[Herbert K. (avr-herbi)]

Eine Frage an die DTU-Wlite und DTU-Pro Besitzer:

Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR 
über die offiziellen hoymiles Wege bekommen und auf welche 
Kommunikatiosart ?
(also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem 
Smartphone, RS485 ?, ...)
Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU... 
übertragen werden.

[Ziyat T. (toe_c)]

Herbert K. schrieb:
> Eine Frage an die DTU-Wlite und DTU-Pro Besitzer:
>
> Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR
> über die offiziellen hoymiles Wege bekommen und auf welche
> Kommunikatiosart ?
> (also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem
> Smartphone, RS485 ?, ...)
> Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU...
> übertragen werden.

Hallo Herbert
Ich steuere meinen MI1500 über DTU-Pro/ModbusRTU selber.
Ich habe bisher an der DTU-Pro die folg. WR-Port-Status herausgefunden:

PORT_STATUS = ["can't read", "?", "?", "Normal", "?", "(ev.)PV not 
connected", "?", "?", "Reduced"]
Die 8=Reduced wird im S-miles als "remote shutdown" ersichtlich, 
manchmal;-).

Grüsse
Ziyat

[Hans W. (hans_w801)]

Hallo,

auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich 
hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann 
es noch nicht montieren.

Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1 
laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht 
verpackt und hatte beim Transport ganz schön gelitten.

Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine 
Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht 
weiß, ob er den Transport überlebt hat.

Gruß Hans ...und Hut ab vor eurer Arbeit hier !!!

[Daniel M. (daniel_m821)]

Hallo in die Runde,

wie versprochen kommt meine DTU für den TSUN am Dienstag. Bin gespannt 
wie das Innenleben aussieht.

Mit welchen Tools macht es am meissten Sinn, die DTU auf rx/tx zu 
überwachen?
Ich hätte USB-Serial Adapter hier und kann vom ersten Einschalten 
beobachten, theoretisch.

Bislang komme ich mit dem Wemos nicht weiter, keine Kommunikation mit 
dem WR, was ich aber fast erwartet habe.

Ich hab mal dein Stück des Bootvorgang und der Kommunikation mit 
angehängt.
Debug ist aktiviert und die Sendedaten lasse ich mir mit anzeigen.

lg
Daniel

[Reinhard B. (reinhardb)]

Hans W. schrieb:
> Hallo,
>
> auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich
> hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann
> es noch nicht montieren.
>
> Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1
> laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht
> verpackt und hatte beim Transport ganz schön gelitten.
>
> Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine
> Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht
> weiß, ob er den Transport überlebt hat.
>
> Gruß Hans ...und Hut ab vor eurer Arbeit hier !!!

Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem 
"+" bekommt?
Vielen Dank!

[Martin P. (mpolak77)]

Ich habe diese:
WayinTop 2pcs NRF24L01+PA+LNA... https://www.amazon.de/dp/B07PBBC4H9
(Mit PA und LNA - die breakout boards dabei sind nicht gut)

Und die:
AZDelivery 5 x NRF24L01 mit 2,4... https://www.amazon.de/dp/B075DBDS3J

[Marcus (Gast)]

Hallo,

kann man eigentlich auch einen RF-NANO (z.B. 
https://de.aliexpress.com/item/1005003513445043.html) verwenden?
NRF24_SendRcv kompiliert, aber hier scheint es keinen IRQ zu geben?!

[Marcus (Gast)]

Der RF-Nano verhält sich merkwürdig:
- isPVariant liefert true also PLUS
- setDataRate liefert mit 250KBPS false - unterstützt also keine 250KBPS

Insofern also wohl nicht brauchbar :-(

[Hubi (Gast)]

Hakko Marcus
das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem 
Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben, 
also sollte D2 der INT0 sein.
Bei den Kundenbewertungen ist auch erwähnt, dass wohl nicht die 
Plus-Variante des RF-Moduls verbaut wurde, also keine 250 kbps.

[Peter L. (leliep)]

Reinhard B. schrieb:
> Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem
> "+" bekommt?

bei mir gerade von AZ-Delivery angekommen: funktioniert! :-)

Der Tip mit dem "PLUS" war entscheidend, Danke für Eure Unterstützung, 
mein HM-1200 spricht nun mit mir!

[Martin G. (petersilie)]

Hubi schrieb:
> Vllt könten sich auch ein paar von uns
> zs-schließen und das mit Git machen, Aufgaben verteilen etc.

Also mein Vorschlag steht ja und wird auch schon fleißig geforkt:

* https://github.com/grindylow/ahoy

Persönlich bin ich eher an der Raspi-Seite interessiert, aber die beiden 
ergänzen sich ja gegenseitig.

[Martin G. (petersilie)]

Wir bräuchten dringend mal noch längere Logs von Datenverkehr mit echten 
DTUs.

Ich meine, in den ursprünglichen Mitschnitten war das 0x80 ja garnicht 
notwendigerweise als das fortwährend zu sendende Paket zu erkennen - 
macht ja eigentlich auch keinen Sinn, sekündlich die Uhrzeit neu zu 
setzen. Vielleicht bringt das ja auch jedesmal das Channel Hopping 
wieder durcheinander?

Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu 
belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24 
zu tun. Das wäre spitze, aber natürlich Hardware-intensiv...

Meine DTU kam immernoch nicht - und die Hoffnung schwindet.

[Oliver F. (of22)]

Martin G. schrieb:
> Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu
> belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24
> zu tun. Das wäre spitze, aber natürlich Hardware-intensiv...

Hallo Martin.
Das war mein Plan.
Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die 
erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren 
bin. Konnte es leider noch nicht richtig ausprobieren.
Aber ich denke, das wird neue Erkenntnisse bringen.
Erste Tests haben aber schon gezeigt, dass die DTU leider auf mehr als 6 
Kanälen sendet.

[Marcus (Gast)]

Hubi schrieb:
> das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem
> Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben,

Mhh - ich dachte der IRQ wird (beim Aufbau Wemos D1/NRF-Modul) 
verwendet, um einen IRQ bei Empfang auszulösen (für die ISR). Der 
IRQ-Pin des NRF auf dem RF-Nano ist nicht verbunden. Meinst Du der Nano 
löst dennoch einen Interrupt auf D2 / D3 aus? Kann ich mir jetzt nicht 
vorstellen - außer man würde den IRQ-Pin des NRF mit dem Nano PIN D2 
oder D3 verbinden. Normal ist da ja bei einem Nano nichts verbunden 
(außer eben wenn man ein externes NRF-Modul anschliesst).

Fazit für das Topic:
Der RF-Nano ist für das Auslesen der Hoymiles weniger (bzw. nicht) 
geeignet. Wenn man diesen dennoch testen möchte, dann ist zu prüfen, ob 
er wirklich ein NRF+ Modul hat (am besten die Datenrate von 250KPBS 
setzen und überprüfen). Es scheint wohl welche mit und ohne zu geben. 
Wenn er ein NRF+ Modul hätte, müsste man aber vermutlich auch die 
Software bzgl. der ISR / IRQ Thematik anpassen.

Ich habe mir nun die hier im Thread genannten Module bestellt: 
[[https://www.amazon.de/dp/B075DBDS3J]]
Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca. 
10-15m LOS + 1 Holzdach überbrückt?

[SUNPOWER (Gast)]

Hallo,

habe einen HM1200.
Aufschrift 1200HR. EU .HM.
Die Seriennummer ist rein numerisch 116170522231, kann das sein?
Habe die leider nicht vorher aufgeschrieben und nun mit einer
Iphone/Holzlattenkombination auf dem Dach abgefilmt......

Danke

[Hubi (Gast)]

Marcus schrieb:
> Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca.
> 10-15m LOS + 1 Holzdach überbrückt?

Hallo Marcus
genau diese benutze ich auch. Die reihen hier vom Wohnzimmer, wo 
programmiere und teste bis zum WR auf dem Gartenhaus, ca. 20 m entfernt, 
dazwischen eine Tür mit Isolierglas und Büsche/Bäume.

[Lukas P. (lumapu)]

> Die Seriennummer ist rein numerisch 116170522231, kann das sein?

Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch 
mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde 
ein 0x vorangestellt sein.

[Marcus (Gast)]

@Thomas B.
Noch etwas für die Statistik 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" - da ich 
gerade den WR fotografiert habe:

Die Seriennummer meines HM-400 beginnt mit: 1121

[Peter L. (leliep)]

11617… mein HM-1200

[Was (Gast)]

Lukas P. schrieb:
>> Die Seriennummer ist rein numerisch 116170522231, kann das sein?
>
> Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch
> mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde
> ein 0x vorangestellt sein.

Danke,

wo fange ich an?
Der Thread ist etwas unüberschaubar.
Ich habe NRF, Atmega, Espxxxx und Raspi…

[isnoAhoy (Gast)]

Danke an Hubi für das Update des ESP8266/ESP32 Codes und die anderen die 
hier schon fleißig getraced haben!

Seit ich meine HM-600 Seriennummer (beginnt mit 1141 7310 xxxx) 
eingetragen habe und das in der alten Version (vom 10.4.) fehlende 
Debug.h auskommentiert habe funktioniert es bei Tageslicht problemlos.

Ich habe diese Bibliotheken extra installiert:
* RF24
* TimeLib
* Pinger (braucht man in der neuen Version vom 13.4.  evtl. nicht mehr 
?)

Hier sind die Verbindungen meiner beiden Komponenten:

* Pinout des PA nRF24L01+ Moduls:

Ich habe dieses hier von derpaule auf eBay bestellt, scheint nur jetzt 
vergriffen zu sein.
Aber man kann wie bei den AZ-Delivery aus der Zone sehr gut das nRFL01 
"+" sehen.
https://www.ebay.de/itm/165071116650

Die Debug Ausgaben sollte m.E. immer das og. 
radio1.printPrettyDetails(); aktiviert haben, damit man etwas über die 
korrekte Belegung des nRF24L01 Moduls erfährt.

|Colour|Description|Pin|Pin|Description|Colour|
|------|-----------|---|---|-----------|------|
|black | GND       |[1]|[2]| VCC +3.3V |white |
|grey  | CE        |[3]|[4]| CSN       |purple|
|blue  | SCK       |[5]|[6]| MOSI      |green |
|brown | MISO      |[7]|[8]| IRQ       |yellow|

* ESP8266 / NodeMCU Anschlüsse:

Wire Connections

    +-----------+          +-----------+
    | nRF24L01+ |--colour--| ESP8266   |
    |           |          |           |
    |       GND |---black--| GND       |
    |       VCC |----red---| +3.3V     |
    |        CE |---grey---| D4        |
    |       CSN |--purple--| D8        |
    |       SCK |---blue---| D5        |
    |      MOSI |---green--| D7        |
    |      MISO |---brown--| D6        |
    |       IRQ |--yellow--| D3        |
    +-----------+          +-----------+

Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in 
das Readme.md auf dem Ahoy Github einchecken.

@Hubi unter welcher Lizenz steht denn Dein Source Code und darf der 
ebenfalls eingecheckt werden ?
Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter 
verbessern.

Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter 
(Liste/Array mit WR IDs) in einer Schleife abfragen kann ?
Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher 
praktisch.

Eine Ausgabe der Daten im Serial Plotter Format wäre für einfache Tests 
ohne MQTT, etc. ebenfalls geschickt.
Hier ist die PDF Dokumentation [1] und hier die offizielle Markdown Doku 
[2] der Arduino Software zum Serial Plotter Protokoll.

[1] 
https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.pdf

[2] 
https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.md

[Lukas P. (lumapu)]

Hallo,

seit Mitte Februar lese ich begeistert in diesem Thread. Leider hatte 
ich bis jetzt nur Zeit die unglaubliche Anzahl der Beiträge zu lesen. 
Vielen Dank für eure Arbeit, es ist einfach toll zu sehen wie schnell es 
hier weitergeht!

Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier 
möchte ich was beitragen. Ein pull-request habe ich erstellt.

Mein Setup:
- HM1200
- NRF24L01+ https://www.ebay.de/itm/255283312809
- ESP8266 (ESP-07)
- Verdrahtung wie in dem Post darüber

Aktueller Stand:

Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich 
es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station).
Ich konnte damit auch schon loggen, allerdings habe ich festgestellt, 
dass ich nur Antworten mit Command 0x81 bekomme. Wenn ich den Code von 
Hubi direkt verwende, dann kommen auch andere Commands.

Zur Verifizierung der Werte habe ich einen Sonoff-POW-R2 vor dem 
Wechselrichter und kann damit die Leistung vergleichen. Die Werte aus 
Hubi's Webinterface stimmen nicht für meinen HM1200.

[Hubi (Gast)]

isnoAhoy schrieb:
> @Hubi unter welcher Lizenz steht denn Dein Source Code und darf der
> ebenfalls eingecheckt werden ?
> Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter
> verbessern.
>
> Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter
> (Liste/Array mit WR IDs) in einer Schleife abfragen kann ?
> Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher
> praktisch.

Moin zusammen
Meine Source hat keine Lizenz, stammt ja ursprünglich auch nicht von mir 
sondern von der ahoy-Seite bei Github.
Ja, im Moment bin ich noch am aufräumen und verbessern.
Eine Version für mehrere WR ist in Arbeit. Die abzufragenden Messwerte 
hinterlege ich in einer Liste, pro Messwert eine Zeile mit
WR, Messwertname, Einheit, Telgramm-ID, Offset, Länge, Funktion. Als 
Funktion kann man einen Divisorwert oder eine selbst definierte Funktion 
nehmen, zb wenn man die Stromstärke haben will mittels P/U.
Da das ganze auch für Arduinos (zB Pro mini) laufen soll, musste ich 
etwas aufräumen. Besonders in der crc.cpp konnte ich über 500 byte 
einsparen, indem ich eine crc-Lib benutzt habe. Aber es läuft ohne 
Speicherwarnung auch auf dem Pro Mini, natürlich nicht mit webinterface, 
aber mit Ausgabe über Serial.
Wenn der Autor von der ursprünglichen NRF24-SendRcv (ahoy) nichts 
dagegen hat dann stelle ich meine Entwicklung ins Git.
Meine Source ist im Moment nur für den HM-600. Für andere WR-Typen wird 
das nicht funktionieren, denn da sind die Requests und Antworten anders 
mit anderen Telegram-IDs und offsets. Wenn mir jmd seine Erkenntnisse 
über seinen WR zuschickt, bringe ich das in meine Source mit ein.
Schöne Ostern

[Martin P. (mpolak77)]

Wenn mir jmd seine Erkenntnisse
> über seinen WR zuschickt, bringe ich das in meine Source mit ein.
> Schöne Ostern

Ich habe weiter oben gepostet, dass HM-700 gleich wie der HM-600 tut und 
wie die Interpretation für HM-350 ist (und HM-400 scheint gleich zu 
sein)

Brauchst du trotzdem meinen Code dazu auch?

[Hubi (Gast)]

Source brauche ich im Moment noch, die nötigen Daten suche ich mir oben 
zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst 
Mehr-WR-Fähigkeit entwickeln will.

[Hubi (Gast)]

Source brauche ich im Moment noch nicht, die nötigen Daten suche ich mir 
oben zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst 
Mehr-WR-Fähigkeit entwickeln will.

[rejoe2 (Gast)]

Oliver F. schrieb:
> yveaux NRF24 sniffer

Hallo, Oliver F.,
könntest du eventuell den Code posten? Wollte auch mal ein serielles 
MySensors-GW umflashen und zum sniffen nutzen, aber leider bekomme ich 
schon den Ausgangs-Sketch von Yveaux nicht via Arduino-IDE compiliert. 
Konkret wird die "wrong number of template arguments" bzgl. des 
CircularBuffer (Zeile 97?) bemängelt...

Wäre toll, wenn du da helfen könntest.

[Ziyat T. (toe_c)]

@Hubi, @Martin G(petersilie)

Hallo zusammen

Mein Setup:
DTU-Pro
MI1500 (nur Port3/4 mit PV's)
WemosD1mini
NRF24L01+ wie https://www.ebay.de/itm/255283312809

Ich verwende Hubi's letzte Version(mit settings.h):
- NRF24L01+ mit 256KBPS funktioniert, siehe init in log Dateien
- MI1500 gibt keine Antwort, siehe NRF24_DTU_OFF.log


Aber wenn ich DTU-Pro einschalte:
  - erhalte ich etwas, die PV/AC/etc. Werte stimmen nicht 
(wahrscheinlich auch, da MI1500 4 Ports hat), siehe NRF24_DTU_ON.log
  - ich sehe neue CMD's, siehe NRF24_CMDXX, CMD 00,5A,55

Grüsse
Ziyat T.

[Hubi (Gast)]

Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine 
eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das 
Telegramm mit command 00 müsstest du mal untersuchen, zu was die 
aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die 
Werte der unbestückten Ports sein!?

[Ziyat T. (toe_c)]

Hubi schrieb:
> Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine
> eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das
> Telegramm mit command 00 müsstest du mal untersuchen, zu was die
> aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die
> Werte der unbestückten Ports sein!?

Habe schon versucht die Daten zu analysieren, wie ich sie anschaue ist 
gleich, bekomme ich keine gescheitere Werte, siehe Anhang

[Ziyat T. (toe_c)]

Hallo
wenn sich jemand interessiert im Anhang
MI1500 > DTU-pro log

[Peter L. (leliep)]

Falls noch nicht bekannt, mein HM-1200 sendet auch 84er-Telegramme. 
Nicht so oft, aber immer wieder.

Panels: 2 + 1, aktuelle Leistung: 800.69W, 4.895kWh letzte 24h, heute 
2.322kWh, total 73.528kWh

[Robert Bleumer (Gast)]

Leider, mein 1500 wird auch noch nicht unterstutzt, aber wenn ich mal 
helfen kann, schick mir mail auf robert (at) bleumer.nl

Kein DTU Pro dabei übrigens.

[Lukas P. (lumapu)]

Hallo zusammen,

ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück 
weitergekommen. Dank des Excel-Screenshots von tbnobody 
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") habe ich so 
ziemlich alle Felder der Commands 01, 02, 03 und 84 für den HM1200 
zuordnen können.

Ich habe als Input die Firmware von Hubi verwendet und das serielle Log 
ausgewertet. Heute habe ich den ganzen Tag mitgeloggt und konnte dadurch 
sehr gut die Zuordnung bestimmen. (220418_log_out.xlsx ist das Log von 
heute)
Die Werte stimmen mit meinen durch einen vorgeschalteten Sonoff POW R2 
gemessenen Werte sehr gut überein (vor allem bezogen auf die 
Tagesproduktion und die Gesamtproduktion).

Falls jemand meine Schritte nachvollziehen will, hier so ein grober 
Fahrplan:
- ESP Firmware von Hubi, seriellen Output mitloggen
- Log bei https://regexr.com/ reinladen und mit folgender Regex filtern, 
die ausgegebene Liste dann wieder in ein File kopieren (Input für 
main.cpp)
- main.cpp kompilieren (VS2019 Projekt kann ich auch noch teilen)
- ausgegebenes CSV in LibreOffice / Excel öffnen und verschönern

Regex:

([0-9]+\s[0-9]+\s[0-9A-F]+\s[0-9A-F]+\s.\s+[0-9]+\s[0-9]+\s[0-9]+\s[0-9A-F]+\s[0-1])

[Herbert K. (avr-herbi)]

Lukas P. schrieb:
> Hallo zusammen,
>
> ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück
> weitergekommen. .... Commands 01, 02, 03 und 84 für den HM1200

Auch wenn ich aktuell keinen HM1200 habe, sage ich einfach mal Danke für 
die Arbeit !

[Lukas P. (lumapu)]

Jetzt ist mir aufgefallen, dass die 16bit vor den jeweiligen 
Gesamterträgen 0 sind, daher nehme ich an, dass die Gesamterträge als 
32bit Wert geführt werden. Weitere 8 Byte geklärt.

Byte 1 und 2 vom Command 01 könnte ein AC-Enable sein oder eine Art 
Netz-Sync boolean.

Was mir noch aufgefallen ist: es gibt nur 2 DC Spannungen, kann es sein, 
dass diese für jeweils 2 Eingänge gelten (HM1200 hat 4 Eingänge, aber 
nur 2 MPPT, also hat jeder MPPT eine Spannung).

[Was (Gast)]

wo fange ich an?
Der Thread ist etwas unüberschaubar.
Ich habe NRF, Atmega, Espxxxx und Raspi…

[Herbert K. (avr-herbi)]

analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.81 
PV-DC.P:163.10 PTotal-Ueberlauf-Unbekannt.W:0.00 PTotal.W:65535.00 
PToDay.W:106.00 AC.V:238.10

analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.69 
PV-DC.P:157.80 PTotal-Ueberlauf-Unbekannt.W:1.00 PTotal.W:0.00 
PToDay.W:107.00 AC.V:237.90

HM400 der "Überlauf"  :-)  ist gerade eben passiert  :-)
Also (P-Total) ist 4 Byte  :-) wie vermutet  :-)

Euch Allen einen schönen Tag

[Herbert K. (avr-herbi)]

Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank 
holt, müssten in den Telegrammen ja auch noch Hardware und Software 
Version versteckt sein ?
(wird in der Cloud ja angezeigt)

[lpb (Gast)]

Herbert K. schrieb:
> HM400 der "Überlauf"  :-)  ist gerade eben passiert  :-)
> Also (P-Total) ist 4 Byte  :-) wie vermutet  :-)

Super, dann stimmt die 4 Byte Größe wie im Manual angegeben - dann war 
ich am Anfang doch nicht ganz auf der falschen Spur.
Ich habe einen HM600, da müssen dann die 'Überlauf' Bytes in 2 
Nachrichten verteilt sein, sonst geht das nicht auf.
Ich vermute dann mal die letzten beiden 'null' Bytes (24/25) in Msg 01 
für P1 total, und die beiden Bytes vor P2 Total in Msg 02 (12/13).
Mal sehen, ob/wann das jemand mit einem HM600 bestätigen kann - bei mir 
dauert das wohl noch ...

In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein 
inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen 
Nachricht um 1 erhöht wird (ich sende aktuell alle 15 Sekunden eine 
Anfrage ab).
Da ich mir die Nachrichten der anderen Inverter nicht so genau 
angeschaut habe, gibt es sowas da auch (ich glaube, ich hatte da was 
gelesen - ansteigender Wert)?
Das könnte dann ein Hinweis sein, dass sich dahinter mehr verbirgt.
Evtl. lässt sich ja damit irgendwie der Inhalt der letzten 4 Bytes 
dieser Nachricht entschlüsseln, aber ein Muster (oder Wiederholungen, 
die z.B. auf die noch fehlenden SW/HW Version hindeuten könnten) habe 
ich bislang noch nicht gefunden.

In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder 
abends das Licht schwach ist und keine Einspeisung passiert, ist dieser 
Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) 
ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und 
'1002' gesehen. Leider habe ich keine passenden Codes in den Manuals 
gefunden, aber es schaut plausibel aus.

[Herbert K. (avr-herbi)]

lpb schrieb:
...
> In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder
> abends das Licht schwach ist und keine Einspeisung passiert, ist dieser
> Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null)
> ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und
> '1002' gesehen. ...
Ich biete zusätzlich noch 1003,1004,1008,1038

[Martin G. (petersilie)]

lpb schrieb:
> In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein
> inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen
> Nachricht um 1 erhöht wird

An welcher Position?

[Lukas P. (lumapu)]

Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden, 
einzig die Energieproduktionen sind monoton steigend.

Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir 
eine Gesamtübersicht / Doku der Bytes machen können?

Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander 
die Module ab und wieder angeklemmt habe -> sie stimmt.

[Lukas P. (lumapu)]

Herbert K. schrieb:
> Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank
> holt, müssten in den Telegrammen ja auch noch Hardware und Software
> Version versteckt sein ?
> (wird in der Cloud ja angezeigt)

Ich denke, es gibt weitere Kommandos, die nur am Anfang ausgetauscht 
werden, wenn z.B. die DTU mit dem Wechelrichter Kontakt aufnimmt.
Hat jemand mit einer DTU schon mal während der Einstellung der Begrenzng 
der Nennleistung die Kommandos 'gesnifft'?

[Was (Gast)]

Lukas P. schrieb:
> Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden,
> einzig die Energieproduktionen sind monoton steigend.
>
> Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir
> eine Gesamtübersicht / Doku der Bytes machen können?
>
> Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander
> die Module ab und wieder angeklemmt habe -> sie stimmt.

Ich hätte da Daten, darf aber nicht mitspielen:

wo fange ich an?
Der Thread ist etwas unüberschaubar.
Ich habe NRF, Atmega, Espxxxx und Raspi…

[lpb (Gast)]

Martin G. schrieb:
> lpb schrieb:
>> In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein
>> inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen
>> Nachricht um 1 erhöht wird
>
> An welcher Position?

Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in 
dem angehängtem Auszug der dekodierten Daten).

[Was (Gast)]

Wer erbarmt sich?😪

[isnoAhoy (Gast)]

> wo fange ich an?
> Der Thread ist etwas unüberschaubar.
> Ich habe NRF, Atmega, Espxxxx und Raspi…

NRF24L01+ und ESP8266/ESP32 funktionieren anhand des o.g. Schaltplans 
(Fritzing) und mit der Software NRF24_SendRcv.zip (18,2 KB) von Hubi vom 
13.4.2022 für einen Hoymiles HM-600 recht zuverlässig. Solltest Du einen 
anderen HM-1200, etc. Wechselrichter haben, ist wohl noch etwas 
Detailarbeit nötig.
Auch die Kommandos der DTU (pro) um ggf. den Zero-Export-Restriction 
Modus (z.B. Limitierung der Asugangsleistung auf 600W bzw. 600VA) 
umzustellen sind bisher noch nicht bekannt. Einzelne Bytes der 
Nachrichten sind aktuell auch noch nicht zweifellos geklärt, u.a. 
Hardware-, Software- und Netzprofilversion wie in der Hoymiles Cloud 
ausgegeben sind noch unbekannt. Dazu ggf. die letzten Beiträge von 
lumapu und avr-herbi nochmal lesen.

Wenn ich es richtig aufgefaßt habe stehen aktuell noch einige große 
Themen an:
* DFU (pro) Kommunikation bei der Einrichtung der Hoymiles App (am 
besten auf mehreren / allen Kanälen) mitschneiden.
* genaueres Verständnis für das sog. Channel Hopping, damit hängt evtl. 
auch die laufende Nummer der Nachrichten und der CRC Algorithmus 
zusammen.
* die ModBus Schnittstelle scheint die meisten Datagramme zu 
beschreiben.
   Hierzu sollte man die Dokumentation mit dem bisher erforschten 
nochmals vergleichen und ggf. bestehende Lücken auf unserer Seite 
dokumentieren bzw. untersuchen.
* HM-600, HM-1200, etc. Protokoll genauer untersuchen bzw. länger 
Protokoll Aufzeichnungen analysieren (wg. Überlauf).
* Inverter Status Codes 1000, 1001, 1002, 1003, 1004, 1008, 1038 in der 
0x83 Nachricht interpretieren.
* NRF24_SendRcv aktuell nur für HM-600, daher für andere Wechselrichter 
HM-1200, etc. erweitern.
* NRF24_SendRcv erweitern um mehrere Inverter / Wechselrichter 
nacheinander abzufragen.

[Marcel A. (a-marcel)]

Herbert K. schrieb:
> Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank
> holt, müssten in den Telegrammen ja auch noch Hardware und Software
> Version versteckt sein ?
> (wird in der Cloud ja angezeigt)

Bis auf die Softwareversion sollte alles in der Seriennummer enthalten 
sein. Diese, soweit ich das verstanden habe, gibt man ja beim Einrichten 
der DTU an.

Marcel

[isnoAhoy (Gast)]

> Wer erbarmt sich?😪

Du kannst auch das Ahoy [1] GitHub Repo von Martin G. (Petersilie) 
auschecken, dort befindet sich nun auch die von lumapu um ein ESP 
WiFi-Setup und OTA erweiterte ESP8266 Version, wie auch die bereits im 
Vorfeld von den Ersten hier im Thread benutzte Python Variante des ahoy 
Tools. Dafür brauchst Du dann halt einen Raspberry Pi 2+ das NRF24L01+ 
Modul und die Verkabelung. Was Du verwenden und erreichen möchtest 
entscheidet jede/r selbst.

[1] https://github.com/grindylow/ahoy/

[isnoAhoy (Gast)]

Herbert K. schrieb:
>> In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder
>> abends das Licht schwach ist und keine Einspeisung passiert, ist dieser
>> Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null)
>> ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und
>> '1002' gesehen. ...
> Ich biete zusätzlich noch 1003,1004,1008,1038

In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von 
Registern angegeben,
hängt das eventuell miteinander zusammen ?

4.3.2 Microinverter Data Register List

The following registers provide a microinverter data register list, 
which can be read-only
with the function code 0x03

| Registers | Name             | Decimal | Units | Remark 
|
| --------- | ---------------- | ------- | ----- | 
------------------------------------------------------------ |
| 0x1000    | Data Type        | /       | /     | Default, 0x3C 
|
| 0x1001    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1002    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1003    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1004    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1005    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1006    | Microinverter SN | /       | /     | 12-digit decimal number 
Big-Endian For example, 116151200012 |
| 0x1007    | Port Number      | /       | /     | 
|
| 0x1008    | PV Voltage       | 1       | V     | 
|
| 0x1009    | PV Voltage       | 1       | V     | 
|
| 0x100A    | PV Current       | 1/2     | A     | 1 for MI Series, 2 for HM 
Series                             |
| 0x100B    | PV Current       | 1/2     | A     | 1 for MI Series, 2 for HM 
Series                             |
| 0x100C    | Grid Voltage     | 1       | V     | 
|
| 0x100D    | Grid Voltage     | 1       | V     | 
|
| 0x100E    | Grid frequency   | 2       | Hz    | 
|
| 0x100F    | Grid frequency   | 2       | Hz    | 
|
| 0x1010    | PV Power         | 1       | W     | 
|
| 0x1011    | PV Power         | 1       | W     | 
|
| 0x1012    | Today Production | /       | Wh    | 
|
| 0x1013    | Today Production | /       | Wh    | 
|
| 0x1014    | Total Production | /       | Wh    | 
|
| 0x1015    | Total Production | /       | Wh    | 
|
| 0x1016    | Total Production | /       | Wh    | 
|
| 0x1017    | Total Production | /       | Wh    | 
|
| 0x1018    | Temperature      | 1       | °C    | Microinverter internal 
temperature                           |
| 0x1019    | Temperature      | 1       | °C    | Microinverter internal 
temperature                           |
| 0x101A    | Operating Status | /       | /     | 
|
| 0x101B    | Operating Status | /       | /     | 
|
| 0x101C    | Alarm Code       | /       | /     | 
|
| 0x101D    | Alarm Code       | /       | /     | 
|
| 0x101E    | Alarm Count      | /       | /     | 
|
| 0x101F    | Alarm Count      | /       | /     | 
|
| 0x1020    | Link Status      | /       | /     | Communication status with DTU 
|
| 0x1021    | /                | /       | /     | Fixed, 0x07 
|
| 0x1022    | Reserved         | /       | /     | 
|
| 0x1023    | Reserved         | /       | /     | 
|
| 0x1024    | Reserved         | /       | /     | 
|
| 0x1025    | Reserved         | /       | /     | 
|
| 0x1026    | Reserved         | /       | /     | 
|
| 0x1027    | Reserved         | /       | /     | 
|
| 0x1028    | Data Type        | /       | /     | Default, 0x3C 
|
| 0x1029    |                  | /       | /     | 
|

Die Daten können offenbar mit dem entsprechenden 0x03 Kommando 
angefordert werden und aus der entsprechenden 0x03 Antwort entnommen 
werden:

4.2.3 Read Device Data

* Command sending format

| Name             | Length | Value | Remark        |
| ---------------- | ------ | ----- | ------------- |
| Address          | 1      |       | RS485 Address |
| Function Code    | 1      | 0x03  |               |
| Register Address | 2      |       | Big-Endian    |
| Register Count   | 2      |       | Big-Endian    |
| CRC              | 2      |       | CRC16         |

* Command response format (if success)

| Name            | Length | Value | Remark        |
| --------------- | ------ | ----- | ------------- |
| Address         | 1      |       | RS485 Address |
| Function Code   | 1      | 0x03  |               |
| Data Length     | 2      |       |               |
| Data 1          | 2      |       | Big-Endian    |
| Data 2          | 2      |       | Big-Endian    |
| ......          |        |       |               |
| CRC             | 2      |       | CRC16         |

* Command response format (if failed)

| Name            | Length | Value | Remark        |
| --------------- | ------ | ----- | ------------- |
| Address         | 1      |       | RS485 Address |
| Function Code   | 1      | 0x83  |               |
| Wrong Data Code | 1      | 0x01  |               |
| CRC             | 2      |       | CRC16         |

[1] 
https://www.mikrocontroller.net/attachment/552319/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

[isnoAhoy (Gast)]

> Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier
> möchte ich was beitragen. Ein pull-request habe ich erstellt.
>
> Aktueller Stand:
> Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich
> es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station).

Hallo Lukas P., habe mir mal Deinen Code aus dem ahoy github geclont und 
versucht zu deployen.

Folgende Punkte sind mir aufgefallen:

* Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F. 
bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am 
nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die 
Spannung am +3.3V Anschluß des ESP8266 ein.

* das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine 
Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt 
wie die ino Datei.

* ich habe versucht die WiFi und Wechselrichter Daten auf der Setup 
Seite einzutragen. Leider ist das Programm die ganze Zeit schon 
beschäftigt im Hintergrund per nRF24L01+ und vermutlich Dummy 
Adress-Daten an den Hoymiles zu senden und zu empfangen. Dadurch 
verliere ich immer die Verbindung, bevor ich die WiFi und Device Daten 
eingeben kann.
Gibt es eine Möglichkeit das Hauptprogramm (im unkonfigurierten Zustand) 
anzuhalten bzw. eine längere Wartezeit (z.B. 5 Minuten) zwischen den 
Anfragen zu konfigurieren ?

* Alternativ könnte man diese evtl. auch in der defines.h hinterlegen, 
nur habe ich die korrekten define / settings nicht herausgefunden:
#define SSID "meineSSID"
#define PWD "meinPasswort"
#define DEVNAME "ahoy-esp"
#define HOY_ADDR 0x1141 7312 3456

* ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder 
bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73 
01 ?

[Was (Gast)]

Danke @isnoAhoy!

Am Woende werfe ich mal den Lötkolben an.
Mal schauen was ich dem HM1200 entlocken kann.

Ich bin auch an einer Nulleinspeisung interessiert.
Habe noch keinen Plan wie man so etwas erreichen kann.
Ggf. auch ein Projekt hier im Forum unter anderem Thread, oder gibt es 
das gar schon?

Danke für die Zusammenfassung.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> Folgende Punkte sind mir aufgefallen:
>
> * Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F.
> bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am
> nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die
> Spannung am +3.3V Anschluß des ESP8266 ein.

ich sehe aktuell kein Problem. Danke für den Hinweis, ich werde die 
anderen Settings mal ausprobieren. Aktuell kommen die 3.3V aus meinem 
FTDI USB Adpater. Habe auch schon mal extern versorgt, das hat aber 
nichts verbessert.
Was mir aufgefallen ist: Ich bin relativ weit weg vom WR (eine 
Betondecke und 10m durch den Garten). Wenn ich allerdings direkt zum WR 
gehe, bekomme ich keine Pakete mehr. Hier im Keller muss die Antenne 
auch sehr genau liegen.

> * das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine
> Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt
> wie die ino Datei.
>  [...]

Danke für dein Feedback, ich habe eine neue Version eingecheckt, die 
hoffentlich alle deine Probleme beseitigt, hier das commit-log:

- renamed .ino (must be identical to parent folder name)
- build CRC over settings, only if the CRC matches settings are applied
- send command 0x80 (set time was wrong)
- improved crc16 routine
- added statistics for received commands and send statistics (channels 
are not correct for now!)
- receive of commands 0x01, 0x02, 0x03, 0x81 and 0x84 working

[Lukas P. (lumapu)]

Im Anhang mal ein Screenshot der aktullen Verison. Wie im Commit-log 
schon geschrieben, stimmt die Statistik der Kanäle nicht, da diese Info 
nicht synchron erfasst wird, die Statistik der Cmds ist korrekt.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder
> bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73
> 01 ?

Die Seriennummer muss man so angeben, wie sie auf dem WR steht. Nach 
jedem Byte muss ein ":" eingefügt werden, also z.B.

11:61:11:22:33:44

[Hubi (Gast)]

Hallo Lukas P.
ich habe mir mal deinen Code im Git angeschaut, das ist ja super, alles 
sauber in C++.
Mit meiner Programmierung bin ich schon weiter gekommen, auch schon für 
mehrere WR. So ganz gefällt mir das noch nicht, denn ist noch sehr 
RAM-intensiv, da die Konstanten halt alle dort abgelegt sind.
Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen, 
melde dich.

[Ziyat T. (toe_c)]

Hallo
Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?

[Martin G. (petersilie)]

isnoAhoy schrieb:
> In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von
> Registern angegeben,
> hängt das eventuell miteinander zusammen ?

Modbus ist ein eigenes Kommunikationsprotokoll, siehe 
[https://de.wikipedia.org/wiki/Modbus]. Der "Funktionscode 0x03" dort 
bedeutet "Register lesen". Das hat nichts direkt mit unserem CMD=0x03 zu 
tun.

Aber die Infos sind natürlich trotzdem nützlich. Zum Beispiel sehen wir 
anhand der Registerliste, welche Werte die Wechselrichter vermutlich 
liefern können, und was man vermutlich einstellen können sollte.

Und mindestens der 0x80 Befehl ("Uhrzeit setzen") verwendet die gleiche 
CRC16 wie das Modbus Protokoll.

[Martin G. (petersilie)]

lpb schrieb:
>> An welcher Position?
>
> Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in
> dem angehängtem Auszug der dekodierten Daten).

Hallo lpb,

ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in 
meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im 
Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses 
Ergebnis bzw. wie genau fragst Du den WR ab?

[Lukas P. (lumapu)]

Hubi schrieb:
> Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen,
> melde dich.

Danke für dein Lob. Ohne deine Vorarbeit hätte ich das nicht so schnell 
auf die Beine gestellt, danke für die Vorlage =)
Ja ich habe interesse, wie du mich erreichst? - in jedem Git commit 
findet man in den ersten Zeilen die E-Mail des Autors - sofern diese 
richitg angegeben ist:

Einfach ein '.patch' an die URL hängen und schon hast du sie ;-)
https://github.com/grindylow/ahoy/commit/7d2437828830d7825953844d632aed72940d942c

Anbei noch ein Screenshot meiner Darstellung der Werte - ich werde den 
Stand heute noch committen.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in
> das Readme.md auf dem Ahoy Github einchecken.

@petersilie würdest du die Diagramme in Git übernehmen, ich fände das 
super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann 
könnte man bei Fragen immer öfter auf das Repository verweisen.

[Martin G. (petersilie)]

Lukas P. schrieb:
> isnoAhoy schrieb:
>> Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in
>> das Readme.md auf dem Ahoy Github einchecken.
>
> @petersilie würdest du die Diagramme in Git übernehmen, ich fände das
> super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann
> könnte man bei Fragen immer öfter auf das Repository verweisen.

Gute Idee. Hab mal die Diagramme und einen Anfang eines 
Quickstart-Guides hochgeladen:

https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

[lpb (Gast)]

Martin G. schrieb:
> Hallo lpb,
>
> ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in
> meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im
> Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses
> Ergebnis bzw. wie genau fragst Du den WR ab?

Vielen Dank für die Blumen, aber ohne die vielen Hinweise und 
Diskussionen hier hätte ich das sicher nicht hinbekommen.
Im wesentlichen nutze ich das hier geteilte nrf24_sendrcv. Ich habe das 
ganze in der Arduino IDE auf den D1 mini mit einem EPS32 portiert.

Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des 
'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer 
festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine 
Nachricht(en) empfangen habe.
Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal 
3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte.
Je nach der eingestellten 'Wartezeit' habe ich mehr oder weniger oft 
alle 3 Nachrichten von meinem HM600 empfangen. Empirisch ermittelt war 
4ms in meinem Code ein ganz guter Wert.
Ebenfalls habe ich verschiedene Rx Kanäle und Reihenfolgen probiert. 
Dabei habe ich einige nie gesehen und daher wieder verworfen.
Falls das jemand ausprobieren möchte, ich habe das so realisiert:

uint8_t rx_channels[] = {3, 23, 61, 75, 83};
uint8_t rx_chn_num = 5;
uint8_t intvl = 4;
  ...
  // NRF rx/tx handling
  if (millis() >= tickMillis)
  {
    tickMillis += intvl;
    // rx channel switching
    chn_id++;
    if (chn_id >= rx_chn_num)
      chn_id = 0;
    rx_channel = rx_channels[chn_id];
    DISABLE_EINT;
    radio.stopListening();
    radio.setChannel(rx_channel);
    radio.startListening();
    ENABLE_EINT;

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Hallo
> wenn sich jemand interessiert im Anhang
> MI1500 > DTU-pro log

Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC 
Freq. und U_AC) konnte ich schon identifizieren, natürlich alles 
angenommen.
Beim 01er Command (Spalte A, ich weiß nicht ob das ein Command ist) 
sieht es für mich so aus, als gäbe es in Spalte D noch ein Sub-Command.
Wenn Spalte A auf 5A steht bedeutet das wahrscheinlich Fehler oä.

[Lukas P. (lumapu)]

lpb schrieb:
> Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des
> 'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer
> festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine
> Nachricht(en) empfangen habe.
> Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal
> 3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte.

Das ist sehr interessant. Ich habe den Empfang fix auf Kanal 3 stehen 
und gemerkt, dass ich quasi nur Antworten bekommen habe wenn ich auf 
Kanal 61 sende. Ich sende jede Sekunde ein Paket, nach 6 Paketen 
wechsele ich zum nächsten Kanal, aktuell sind das 4 Stück (23, 40, 61 
und 75). Mal beobachten wie es sich die nächsten Tage verhält.

Was ich noch nicht verstehe: Sendest du deine Nachricht mit 0x80-0x84 
commands und bekommst eine 0x83 Nachricht zurück?

Vom HM1200 kann ich folgendes beobachten: Senden von 0x80-0x84 führt zur 
Antwort von 0x01-0x03, 0x81 und 0x84.

[lpb (Gast)]

> Was ich noch nicht verstehe: denSest du deine Nachricht mit 0x80-0x84
> commands und bekommst eine 0x83 Nachricht zurück?

Ich sende jedesmal die 0x80 Zeit setzen Nachricht.
Ich nehme einfach an, dass darauf hin der WR seinen aktuellen Status 
sendet, beim HM600 dann die 0x01, 0x02, und 0x83 Nachrichten.
Mit den anderen Anfragen könnte ich allerdings auch noch mal spielen, 
das habe ich bislang nicht gemacht.

Als nächstes wollte ich noch mal die Antwort-Zeiten und die Kanäle 
auswerten, ob sich da eventuell ein Muster erkennen lässt, denn hin und 
wieder verpasse ich einzelne Antwort-Nachrichten, oder bekomme gar keine 
Antwort auf eine Anfrage. Leider ist es nicht so einfach zu sagen, ob 
das an der SW oder evtl der HF Umgebung liegt.

Die Anzeige in einem Webserver ist übrigens auch sehr schick, ich sende 
meine Daten allerdings an emoncms auf einem Raspberry, das ist dann fast 
so schick wie in der Hoymiles Cloud :)

[Ziyat T. (toe_c)]

Lukas P. schrieb:
> Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC
> Freq. und U_AC) konnte ich schon identifizieren, natürlich alles
> angenommen.

Hallo Lukas
Vielen Dank für deine Bemühungen!
Habe auch die Daten von der V/Freq gefunden.
Allerdings deine Deutung der U_DC, P_DC, AC stimmen leider nicht.

Ich habe im Anhang die neue (meine) Ordnung der Daten, ganz rechts 
siehst du die reale Daten, bei meinen PV's ist die UDC 37-45V.
Ich bin mir sicher dass die Spalte C die MPPT sind:
0xB6/0xB7 > MPPT1 ,2 ports nicht angeschlossen
0xB8/0xB9 > MPPT2 ,2 ports mit PV belegt

ansonsten bin ich leider nicht weiter gekommen, muss mal pausieren ;-)

[Hubi (Gast)]

Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread 
mal gelesen zu haben.
Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter 
der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen 
zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die 
Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88.
Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten:
08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch.

Diese Zahl hinter der 80 scheint mir eine Einstellung für den WR zu 
sein, in welchem Format er senden soll.
Hat jmd schon ähnliche Beobachtungen gemacht?
Vllt ist es auch ein Kennzeichen der DTU, welche sie ist DTU-Prlo oder 
lite.

[Herbert K. (avr-herbi)]

Hubi schrieb:
> Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter
> der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen
> zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die
> Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88.
> Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten:
> 08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch.

Hallo Hubi, wo hast Du das Senden Bitte im Source geändert ?
(Wo die Pakete aufgedröselt werden, weiss ich)
Dann könnte ich das mal mit einem HM-400 und die nä. Tage auch mit 
HM-350 mal testen.

[Hubi (Gast)]

in HM_Packets::GetTimePacket die Zeile
buf[10] = 0x03;

[Herbert K. (avr-herbi)]

Hubi schrieb:

Spannend  :-)
Mit buf[10] = 0x0B;
habe ich beim HM400 Antwort Telegramme 01 und ab und zu 82 bekommen.

Mit buf[10] = 0x03;
bekomme ich beim HM400 die Telegramme 01,02,03,04 als Antwort.

04: aber sehr sehr selten

044060000040C066663FA6CCCD412CEB85AA7F42
044060000040C066663FA6CCCD412CEB85AA366A
044060000040C066663FA6CCCD412CEB85AA366A

01: die Werte sind jetzt statisch und ändern sich nicht mehr

Alles im Allen bisher nur nix wo man DC V,A,W / AC V,A,W / Hz 
wiederfinden kann über analyseWords / analyseLongs

Aber eine Interessante Entdeckung. Vielleicht löst jemand das Rätsel 
noch?

[isnoAhoy (Gast)]

@Lukas P.
Der neue Commit ließ sich übersetzen und nun auch Konfigurieren.
Sowohl die Auswahl einer existierenden WiFi Connection (Liste der 
gescannten WiFi SSIDs) als auch das Speichern des Passworts und des 
Device Names waren am Tablet etwas knifflig.
Es gab keine Ausgabe der Konfiguration (DNS Name / IP) per Serial 
Monitor bzw. Redirect auf die Status Seite (/) und auch nach einem 
Neustart war nicht klar,
ob und wie man den ESP per DNS erreichen kann, bzw. welche DHCP Adresse 
er vom Router bekommen hat.
Meine HM-600 Adresse (sowie die anderen Parameter) wurden aber 
offensichtlich gesetzt, nach einem Hard Reset waren alle noch da.
Aber der Device Name beim Router ESP-429DF0 blieb wie beim ersten Start 
vergeben, eventuell wäre es hier besser den Device Name (ESP-<MAC>) 
einfach anzuzeigen.
Uptime lag am Ende bei 10 Minuten und die Time wurde offensichtlich vom 
NTP Server (o.a.) synchronisiert.
Die /livedata URL ist noch nicht verlinkt und Daten vom HM-600 wurden 
keine empfangen, daher blieb vermutlich auch die /hoymiles Seite leer 
"Every 10 seconds the values are updated".
Ich vermute mal daß die HM-1200 Konfiguration aus Deinem letzten Commit 
die HM-600 Konfiguration von Hubi überschrieben hat ?

@Martin G.
Ja das mit dem ModBus Protokoll hatte ich auch gesehen, aber die Codes 
erschienen mir zu ähnlich zu den Register Adressen.
An anderer Stelle CRC16 und 0x80 scheint es ja auch diverse 
Gemeinsamkeiten zu geben.
Laut dem Abschnitt 4.3.3 Device SN Register List scheint es auch ein 
Register für die Seriennummern der DTU und der WR zu geben.
Ich habe daher mal die DTU Modell und Seriennummern dazu notiert. Das 
scheint ja in der Zukunft evtl. interessant zu werden.
Eventuell könnte man auch den DTU Pro per ModBus ansprechen um die o.g. 
Informationen zu lesen / setzen und dabei das nRF Protokoll mit 
einem/mehreren nRF24L01+ im Promisuous Modus tracen.
So könnten wir das Kommunikationsprotokoll der DTU Pro relativ einfach 
und reproduzierbar analysieren.

Danke auch für die Übernahme der Verbindungsskizze in das GitHub Repo.
Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für 
Diagramme [1] wie ditaa Diagrams through ASCII Art  [2], mermaid-js [3] 
und WaveDrom [4] herum.
Z.B. könnten wir die  hoymiles-format-description.txt einfach umbenennen 
zu hoymiles-format-description.md.
Wenn Du die Diagramme im Markdown rendern möchtest einfach mit folgendem 
einem ditaa Code Tag umgeben.
Ein Export von Markdown zu PDF funktioniert soweit ich weiß aber nur mit 
dem mermaid-js Plugin.

[1] Markdown Diagrams 
https://gist.github.com/blackcater/1701e845a963216541591106c1bb9d3b
[2] ditaa Diagrams through ASCII Art 
https://github.com/stathissideris/ditaa
[3] mermaid-js https://mermaid-js.github.io/mermaid/#/gantt
[4] WaveDrom https://github.com/drom/wavedrom

@Ziyat T.
das weiß ich nicht sicher, laut der gestern von mir aktualisierten 
Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread, 
oder sind das mehrmals die selben (mal Prefix und mal Postfix)?

[1] 1161xxxxxxxx Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
[2] xxxxxxx14456 & xxxxxxx36590 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Eventuell sollten wir die Kürzel der Nutzer aus dem Forum 
dahinterschreiben, damit wir ggf. die Seriennummern besser korrigieren 
können ?
Du kannst auch alles auf einer Seite anzeigen lassen und einfach nach 
1500 suchen, da findest Du dann Thomas B. und Arnaldo G. und Waldemar K.
Zumindest Arnaldo hat auch fünf MI1500. M.E. ist die Bezeichnung MI / HM 
austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter) 
für den Typ Wechselrichter. Ich glaube auf meinem Typenschild / 
Aufkleber am Karton stehen auch beide Bezeichnungen.

[Ziyat T. (toe_c)]

isnoAhoy schrieb:
>
> @Ziyat T.
> das weiß ich nicht sicher, laut der gestern von mir aktualisierten
> Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread,

Hallo isnoAhoy
Danke für die WR-Liste

Ich bin mir ziemlich sicher dass die MI series HW/SW-maessig nicht 
gleich sind, HM 3.gen./MI 2.gen.

MI series:
- untere Limitierung 10%, WR nur als ganzer limitierbar.
- mehrere DTU-ModbusRegister funktionieren nicht, da wahrscheinlich 
nicht im WR vorhanden
HM series:
- untere Limitierung bis 2%, auch port based limitierbar.
- alle Modbus DTU-ModbusRegister funktionieren

Ich bekomme von meinem MI1500 ganz andere antworten (bisher nur, wenn 
ich die DTU-Pro einschalte), bisher konnte ich den MI auch nicht direkt 
ansprechen.

Da ich meiene DTU-Pro über Modbus-RTU selber ansteuere, könnte ich  den 
WR gezielt ansteueren, ich waere bereit sie zu sniffen aber brauche 
HW-maessig hilfe wie ich es machen soll.

[Ziyat T. (toe_c)]

Hallo
Ich habe versucht 2 Tage lang meinen MI1500 zu wecken.
Ich verwende Hubi's SW auf ESP,
habe alle MSGid & CMD Kombination durchgespilet, keine Antwort.

Send... CH40
[15]6370716072228412[81]50  hier 0x15 und 0x81

[0x0-0xFF]6370716072228412[0x0-0xFF]50 Kombinationen

(NRF24 funktioniert, ich sehe WR-Antworten wenn die DTU einschalte)
Hat jemand nen Vorschlag?
Danke

[Hubi (Gast)]

Ist das die letzte Version mit der Routine Serial2RadioID?
Seriennummer auch richtig eingetragen, also
Seriennummer zb 114172607952 dann

#define SerialWR       0x114172607952ULL
uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR);

in der Settings.h

[Ziyat T. (toe_c)]

Hubi schrieb:
> Ist das die letzte Version mit der Routine Serial2RadioID?
> Seriennummer auch richtig eingetragen, also
> Seriennummer zb 114172607952 dann
>

> #define SerialWR       0x114172607952ULL
> uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR);
>

> in der Settings.h

Ja, genau
#define SerialWR      0x106163707160ULL        //
uint64_t WR1_RADIO_ID           = Serial2RadioID (SerialWR);    //
//#define DTU_RADIO_ID  ((uint64_t)0x1234567801ULL)
//10F8---72228412  12842272
#define DTU_RADIO_ID ((uint64_t)0x1284227201ULL)

[Maik R. (bastelbarney)]

Hi isnoAhoy,
Du schriebst im Beitrag #7042229:
> M.E. ist die Bezeichnung MI / HM
> austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter)
> für den Typ Wechselrichter.

Auf der Seite https://www.hoymiles.com/de-eu/microinverter-single-phase 
ziemlich in der Mitte wird zwischen beiden Modellreihen unterschieden:

"MI-Mikro-Wechselrichter
Unsere MI-Mikro-Wechselrichter sind die kompaktesten Modelle in unserem 
Sortiment und ideal für jede Anlage."

vs.

"HM-Mikro-Wechselrichter
Mit einem Gerät der HM-Serie erhalten Sie Blindleistungsregelung und 
eine bessere Datenverbindung dank einer externen Antenne."

-

Ich lese hier schon eine Weile sehr erfreut mit und werde meinen heute 
gelieferten HM-1500 gerne auch sniffen und die Mitschnitte hier 
verfügbar machen, sobald ich die Panels bekommen und aufs Dach gebracht 
habe. Und sofern ich mich durchringe, den Gateway-Stick für 90€ zu 
kaufen - bin da noch unentschieden :-)

Maik

[Herbert K. (avr-herbi)]

Hallo,
ist jemand da dran, die Anzahl der WR zu erweitern ?
Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die 
Serielle (war ja im Prinzip schon fast drin, aber auskommentiert).
Hab nun heute Nachschub bekommen HM-350. Dafür fliegen andere Hersteller 
raus, die nicht so tun, wie ich es erwartet habe. Wenn ich anfange im 
Code herumzuwurschteln, wird jeder "C" Programmierer die Hände über den 
Kopf zusammenschlagen vermute ich.
Eine Idee dazu: Solange wir nicht wissen, wie man aus den S/N oder den 
Telegrammen auf das Modell inkl. HW Vers. / SW Vers. kommt, wären 
Tabellen sicher nicht schlecht:
1. Tab: Alle bisher bekannten Typen von WR., Anzahl MPPT Tracker, Anzahl 
DC-Inputs
2. Tab: Länder Kennungen (gibt scheinbar auch je nach Vorschriften in 
den Ländern verschiedene Funktionen / Verhaltensweisen. EU und 
Österreich für den Anfang  :-)
3. Tab: Tabelle mit S/N, Modell (aus Tab 1), HW Vers., SW Vers., Land
Ist nur mal so eine Idee ....

Ergänzung: Eben mal einen alten WR rausgeworfen (der auch schon 
abgeschaltet hatte), S/N von einem 400 auf eine neue S/N vom 350 
geändert. :-)  Funktioniert sofort  :-)  P-Total = 0.0  :-)  und der 
350er speisst sogar noch ein. Nun kann ich ohne schlaflose Nacht träumen 
:-)

[Hubi (Gast)]

Herbert K. schrieb:
> ist jemand da dran, die Anzahl der WR zu erweitern ?
> Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die
> Serielle (war ja im Prinzip schon fast drin, aber auskommentiert).

Ich habe da schon ein Konzept entwickelt (funzt auch für minsdestens 2 
WR, auch mit Arduino, obwohl wenig Speicher) und Lukas P. will das (oder 
ähnlich) in seine ESP-Version auf der ahoy-Seite einbauen.
Also, etwas Geduld, und das wird schon was tolles.

[Petra-Kathi (Gast)]

Hallo zusammen,

als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5 
anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden) 
und würde ihm gerne ein wenig auf die Finger gucken. Ich habe die 
bisherigen 3 Seiten weitestgehend durchgelesen und dabei zu verstehen 
versucht, über was ihr schreibt, habe dabei aber ziemliche 
Verständnisprobleme.

Ich habe einen Raspi 3, einen alten Arduino Mega und einen ESP32 und auf 
allen schon ein paar Sachen in Richtung Midi + BTLE und ein wenig 
Anwendungsprogrammierung (Zusammenführen von Sensorsignalen und daraus 
rechnerisch Meta-Informationen erzeugen) gemacht. Das Jonglieren mit / 
Bitfieseln von irgendwelchen sonstigen Protokollen / ModBus ist mir 
allerdings noch unbekannt/fremd.

Mit den Voraussetzungen: Wo kann ich mich einigermaßen linear in die 
aktuelle Problematik einlesen? Wie kann ich euch ggf. z.B. durch 
Datensammeln unterstützen?

Viele Grüße aus Aachen,
Petra

[Maik R. (bastelbarney)]

Petra-Kathi schrieb:
> Wo kann ich mich einigermaßen linear in die aktuelle Problematik einlesen?
> Wie kann ich euch ggf. z.B. durch Datensammeln unterstützen?

https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
und
https://github.com/Yveaux/NRF24_Sniffer

Sind für mich die Einstiege. Ein nRF24 Modul (5€) ist auf eBay bestellt, 
ein mini-DUT für 88€ auch.

HTH,
Maik

[Ziyat T. (toe_c)]

@Lukas P.(lumapu)
@Hubi

Hallo
Ich habe heute die 
https://github.com/grindylow/ahoy/tree/main/tools/esp8266 geladen und 
laufen lassen. Ich finde die SW sauber!

Mit Hubi's SW konnte ich, wenn ich die DTUpro einschaltete, die DTUpro 
msg's 00/01 empfangen.(siehe 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")

Mit der ahoy SW kann ich nichts empfangen, fand ich merkwürdig.

Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte 
ich:
mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
Serial.println("sent packet: #" + String(mSendCnt));
dumpBuf(mSendBuf, size);


DTU und WR Adressen sind richtig:
CH: 23 sent packet: #15
1563707160722284128352
CH: 23 sent packet: #16
1563707160722284128253
CH: 23 sent packet: #17
1563707160722284128455
CH: 23 sent packet: #18
15637071607222841280b06263d9e6000500002ad398
CH: 40 sent packet: #19
1563707160722284128150

[Petra-Kathi (Gast)]

Hallo Maik,

danke für deine Einstiegshilfe!

> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Hierüber bin ich noch auf die Langstory 
https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt 
gestoßen und habe mir diese erst mal durchgelesen.

Was ich daraus und aus deinem zitierten
> https://github.com/Yveaux/NRF24_Sniffer
noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features 
des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den 
Beiden dieses Sniffer-Modul ebenfalls noch erforderlich?

Tschüssi,
Petra

[SUNPOWER (Gast)]

Petra-Kathi schrieb:
> noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features
> des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den
> Beiden dieses Sniffer-Modul ebenfalls noch erforderlich?

ja; DU BENÖTIGST EINEN NRF

[Peter L. (leliep)]

SUNPOWER schrieb:
> Petra-Kathi schrieb:
>> noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features
>> des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den
>> Beiden dieses Sniffer-Modul ebenfalls noch erforderlich?
>
> ja; DU BENÖTIGST EINEN NRF

Wichtig: einen mit “Plus” (nRF24L01+)

[IsnoAhoy (Gast)]

@Lukas P. (lumapu)
Danke für die neuen Versionen auf Deinem github repo ich habe sowohl die 
von Dir mit HM-1200 als auch die von in grindylow gemergte Version 
versucht. Ich bekomme leider keine Antworten mehr vom HM-600. Was/wo 
sollte ich untersuchen. Wie gesagt mit Hubis Version vom 13.4. hat es 
funktioniert ?

@Mail & @Ziyat,
ja da habt ihr wohl Recht. Ob sich noch mehr geändert hat von 
2.Generation MI zu 3.Gen HM müsste man evtl durch Fotos anhand der FCCID 
oder eigenes Begutachten des Mainboards in Erfahrung bringen. Eventuell 
gibt es ja auch eine Verbesserung von nRF24L01 zu nRF24L01+ o.a. was 
eine andere Datenrate erfordern würde ?
Ich hatte auch schon vermutet dass die DTU pro evtl. einen nRF51/2 MCU 
verbaut hat da sich damit scheinbar mehr Wechselrichter abfragen lassen.
@Ziyat willst Du Deine mal aufschrauben und uns Bilder schicken ?

[Lukas P. (lumapu)]

@IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git 
geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat 
mir hier sehr guten Input gegeben, wir versuchen das ganze so 
Leichtgewichtig wie möglich aufzusetzen.

Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die 
alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie 
ist eine gute Basis für sowas.

Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine 
C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und 
dynamisch ist, dass sie auch auf z.B. einem proMini läuft und 
gleichzeitig mehrere Wechselrichter unterstützt.

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte
> ich:
> mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
> Serial.println("sent packet: #" + String(mSendCnt));
> dumpBuf(mSendBuf, size);

Damit solltest du nur die gesendeten Pakete sehen, die empfangenen 
kannst du in dieser Zeile anzeigen lassen: 
https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97

Petra-Kathi schrieb:
> als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5
> anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden)

Ich habe vor mehr als 4 Module an meinem HM1200 zu betreiben, testweise 
habe ich immer mal wieder 5 dran. Zwei sind parallel mit Dioden an einem 
Anschluss, der Screenshot spricht für sich. (Channel 3)

[Ziyat T. (toe_c)]

@Lukas P.
> schrieb:
> Damit solltest du nur die gesendeten Pakete sehen, die empfangenen
> kannst du in dieser Zeile anzeigen lassen:
> 
https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97
>

Ich habe die Version ohne MQTT vor 4 Tagen, ich denke, ich habe die 
richtige Zeile auskommentiert:

void app::loop(void) {
    Main::loop();
    if(!mBufCtrl->empty()) {
        uint8_t len, rptCnt;
        NRF24_packet_t *p = mBufCtrl->getBack();
//toe
        mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
//toe



Ich werde mal die Innereien der DTU-Pro mal anschauen.

[Petra-Kathi (Gast)]

Peter L. schrieb:
> Wichtig: einen mit “Plus” (nRF24L01+)

Danke für den Hinweis. Dingens ist bereits bestellt.

Tschüssi,
Petra

[isnoAhoy (Gast)]

Hallo Lukas P.
danke für die Bestätigung, daß es aktuell noch nicht mit dem HM-600 
geht.
Ich hatte das schon vermutet, da es bisher nur eine hm1200Decode.h gibt.
Die Punkte bzgl. der Software hatte ich auch eher als ein Review 
verstanden,
falls Du / andere das irgendwie noch aufhübschen wollt.
Bzgl. Speicherverbrauch und "leichtgewichtig" ist mir aufgefallen,
daß die html/h/*.h Dateien zwar in einer Zeile untergebracht sind,
aber immer noch sehr viele Leerzeichen für die Einrückungen enthalten.
Evtl. könnte man das mit FileConv.exe oder sed unter Linux noch etwas 
anders gestalten ?
Ich nehme an da die {VARIABLE} Ausdrücke ersetzt werden sollen,
kann man die HTML Seiten auch nicht im Flash Memory des ESP speichern ?

[Lukas P. (lumapu)]

Hallo isnoAhoy,

ja ich fände es super das ganze noch aufzuhübschen. Das ist das erste 
Mal, dass ich was in dieser Richtung veröffentlich habe - ich habe 
diesen ESP (app und main Klasse) schon in diversen Projekten verwendet 
und es hat sich immer gezeigt, dass man es schnell für ein neues Projekt 
verwenden kann. Bisher habe ich mich geweigert Tasmota irgendwo zu 
installieren - ich mach das selbst ;-), z.B für den Sonoff-POW-R2 und 
RGB-LED Streifen

Das Fileconv.exe habe ich mir aus der Not gebaut und es kürzt der 
einfachheit halber alle Whitespaces auf ein Space ein. Ich habe mich 
nicht näher mit der Thematik auseinandergesetzt und bin hier offen für 
Input. Schön ist halt aktuell nur ein Binary zu haben und es ist alles 
drin.

Die geschweiften Klammern sind die Bereiche, die ich im Code dann 
ersetze, richtig z.B.

html.replace("{VERSION}", mVersion);

[Peter L. (leliep)]

Lukas P. schrieb:
> @IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git
> geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat
> mir hier sehr guten Input gegeben, wir versuchen das ganze so
> Leichtgewichtig wie möglich aufzusetzen.
>
> Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die
> alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie
> ist eine gute Basis für sowas.
>
> Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine
> C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und
> dynamisch ist, dass sie auch auf z.B. einem proMini läuft und
> gleichzeitig mehrere Wechselrichter unterstützt.

Deinen Code teste ich gleich morgen, wenn es wieder hell ist...

Da ist ein Fehlerchen: 
https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/mqtt.h#L54

[Lukas P. (lumapu)]

Peter L. schrieb:
> Da ist ein Fehlerchen:

ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke

[isnoAhoy (Gast)]

Hallo Lukas P.,

Prinzipiell ist es bei ESP8266 und ESP32 vorteilhaft größere Strings im 
PROGMEM [2] (bis zu 4 MB Flash Memory) abzulegen.
Das ist zwar nicht ganz so schnell und flexibel wie das normale RAM / 
ROM aber dafür gibt es eben viel Platz.

Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:

static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"

Ich habe mal nachgesehen, hier ist ein Beispiel von Sebastian Glahn wie 
man string.replace() und FPSTR() für das WebServer Modul verwenden kann 
[2].

String body = FPSTR(HTTP_BODY);
body.replace("{{variable}}", configuration.variable);
page += body;

[1] https://arduino-esp8266.readthedocs.io/en/latest/PROGMEM.html
[2] 
https://blog.tldnr.org/2017/10/25/how-to-deliver-larger-web-pages-with-an-esp8266/

[Martin G. (petersilie)]

isnoAhoy schrieb:
> Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für
> Diagramme [1] wie ditaa Diagrams through ASCII Art  [2], mermaid-js [3]
> und WaveDrom [4] herum.
> Z.B. könnten wir die  hoymiles-format-description.txt einfach umbenennen
> zu hoymiles-format-description.md.

Danke für Deine Arbeit. Die Nachfragen nach einem "zusammenhängenden" 
Dokument häufen sich ja (macht auch Sinn).

Ich frage mich, ob wir so etwas vielleicht mit Hilfe von readthedocs.io 
aufbauen können?

[Peter L. (leliep)]

Lukas P. schrieb:
> Peter L. schrieb:
>> Da ist ein Fehlerchen:
>
> ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke

Sowas kommt vor, kenne ich aus eigener Erfahrung ;-)
Nach Korrektur funktioniert es mit meinem MQTT-Broker perfekt!

Auch die Daten des HM-1200 mit nur drei Panels sehen gut aus; vielen 
Dank für die gute Arbeit!

[Marcus (Gast)]

Ich habe meine NRF-Module nun erhalten.

Ich habe mich die ganze Zeit gewundert, warum 
[[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen 
Empfang brachte, mit Hubis Code jedoch alles funktioniert.
Verkabelung ist nach diesem Schema: 
[[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]]

Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:

//-------------------------------------
// PINOUT
//-------------------------------------
#define RF24_IRQ_PIN        (D3)
#define RF24_CE_PIN         (D4)
#define RF24_CS_PIN         (D8)

Ist das so gewollt (GIT Verkabelung vs. Code)?

Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten 
(also keine AC Spannung/Energie/Frequenz)
Das ist die Statistik nach einigen Minuten:

CMDs:
0x01: 18
0x02: 0
0x03: 0
0x81: 55
0x84: 0
other: 13

CHANNELs:
23: 0
40: 9
61: 44
75: 33

@Herbert K.
Welche Erweiterungen hast Du für den 400er denn vorgenommen?

[Marcus (Gast)]

Lukas P. schrieb:
> Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die
> alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie
> ist eine gute Basis für sowas.

Eine Integration in Tasmota wäre super - würde mich auch daran mit einem 
POC versuchen, sobald ich einen halbwegs lauffähigen Code mit meinem 
HM-400 hinbekomme.

[Herbert K. (avr-herbi)]

Marcus schrieb:
> Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten
> (also keine AC Spannung/Energie/Frequenz)
> Das ist die Statistik nach einigen Minuten:
>

CMDs:
> 0x01: 18
> 0x02: 0
> 0x03: 0
> 0x81: 55
> 0x84: 0
> other: 13
> 
> CHANNELs:
> 23: 0
> 40: 9
> 61: 44
> 75: 33

> @Herbert K.
> Welche Erweiterungen hast Du für den 400er denn vorgenommen?

Ich bekomme nur "01", "81" (keine Ahnung wozu die gut sind) und ab und 
zu - sehr selten - "82" Antworten für 350/400 die sinnig sind nach den 
bisherigen Analysen.
02,03,04,84 hab ich nicht mit Hubis Vorarbeit (alter Code).
In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur 
und Unbekanntes

[Ziyat T. (toe_c)]

Marcus schrieb:

> Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:
> [c]//-------------------------------------
> // PINOUT
> //-------------------------------------
> #define RF24_IRQ_PIN        (D3)
> #define RF24_CE_PIN         (D4)


Habe auch erst heute gemerkt ;-)

[Mich@ (Gast)]

Hallo Leute,
Ich verfolge die Entwicklung der selbstbau DTU schon eine Weile. Großes 
Lob an die Macher der Software. Nun wollte ich auch mal meine beiden 
Wechselrichter belauschen. Die Software ist auf dem ESP das Webinterface 
läuft aber leider bekomme ich keine Verbindung zum Funkmodul. Ich denke 
es liegt wie oben beschreiben an den falschen Pins in der Firmware. Wenn 
ich die Pins in der defines.h ändere kann ich die Firmware nicht mehr 
auf den ESP laden da es Fehlermeldungen gibt. Ist es möglich das jemand 
eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP 
gebügelt werden muss?

Vielen Dank

[Marcus (Gast)]

Herbert K. schrieb:
> In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur

Aha, dann werde ich mir das mal ansehen - kannst Du Deine 
"Entschlüsselung" hier mitteilen? Unter 
[[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]] 
ist es noch nicht zu finden.

Ergänzend folgende Erfahrungen mit dem HM-400 und diesen Modulen 
[[https://www.amazon.de/dp/B06XJN417D]]:

Noch mal etwas Statistik (ESP8266-Code)

CMDs:
0x01: 490
0x02: 0
0x03: 0
0x81: 0
0x84: 0
other: 227

CHANNELs:
23: 2
40: 494
61: 186
75: 3

Zur Reichweite - das Modul ist hier ca. 30-40m über 2 Wände zum WR 
entfernt. Also ich finde das sehr gut.

Was mich noch interessieren würde - es gibt ja immer diese P1 und P2 
Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen 
dann nicht 2 bei einem HM-1200?
Und warum habe ich bei meinem HM-400 (1 Panel) einen Wert bei P2 von 0 
bei der DC-Spannung, aber unplausible Werte bei Strom und Leistung? Die 
Werte bei P1 sind plausibel.

[isnoAhoy (Gast)]

Hallo Marcus,

> Ich habe mich die ganze Zeit gewundert, warum
> [[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen
> Empfang brachte, mit Hubis Code jedoch alles funktioniert.
> Verkabelung ist nach diesem Schema:
> [[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]]

> Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:
> //-------------------------------------
> // PINOUT
> //-------------------------------------
> #define RF24_IRQ_PIN        (D3)
> #define RF24_CE_PIN         (D4)
> #define RF24_CS_PIN         (D8)

> Ist das so gewollt (GIT Verkabelung vs. Code)?

Danke für das Auffinden des Fehlers, ich habe mich ja auch schon 
gewundert.
Die Diagramme hatte ich für Hubis Source Code gemacht und Lukas hatte 
derweil
den  Source Code mit den WebSeiten angepaßt und hochgeladen.
Auf die Idee die RF Pins zu überprüfen bin ich leider nicht gekommen.

Ach ja die aktuelle github Version scheint nur HM1200 zu unterstützen.
Der Decoder für HM600 und HM400 etc. scheint noch zu fehlen.

@Lukas P., wollen wir die Anpassung im Code machen oder soll ich neue 
Diagramme generieren ?

[Lukas P. (lumapu)]

Hallo,

ich werde die Pins konfigurierbar machen und den default im Source auf 
die Diagramme anpassen. Dann muss man im besten Fall keine Änderungen am 
Code machen. Mein Code passt aktuell zu meiner Hardware.

Den HM600 unterstützt meine Firmware schon fast, ich habe es in einen 
dev Branch auf meinem github Account und werde es sobald ich es für gut 
befinde ins Hauptrepository mergen. Gefühlt bin ich fast schon soweit.

Marcus schrieb:
> Was mich noch interessieren würde - es gibt ja immer diese P1 und P2
> Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen
> dann nicht 2 bei einem HM-1200?

Wir haben das alles selbst ermittelt, du kannst gerne Änderungen 
vorschlagen bzw. diese ermitteln. Im jeweiligen Code gibt es eigentlich 
immer eine Möglichkteit sich die Rohen Daten ausgeben zu lassen.

Mich@ schrieb:
> Ist es möglich das jemand
> eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP
> gebügelt werden muss?

könnte man doch in Github über Releases machen, allerdings denke ich, 
dass wir noch viel zu früh im Projekt stehen um es Release zu nennen.

Marcus schrieb:
> würde mich auch daran mit einem
> POC versuchen

was ist ein POC?

[Marcel A. (a-marcel)]

Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern 
das es für esp8266 und esp32 geht.

> Marcus schrieb:
>> würde mich auch daran mit einem
>> POC versuchen
>
> was ist ein POC?
Proof of concept

Marcel

[Lukas P. (lumapu)]

Marcel A. schrieb:
> Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern
> das es für esp8266 und esp32 geht.

finde ich super! Verwende am besten als Basis meinen aktuellen 
Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen 
veröffentlichten neuen Stand in main-Branch.

[Silvio R. (silre)]

Hallo zusammen,
ich finde das ein super interessantes Projekt.
Eine Frage wird der HM-700 auch unterstützt werden?

[Marcus (Gast)]

Zur Auswertung/Datenanalyse:

Ich habe mich nochmal durch den Thread gewühlt und folgende Theorie für 
meinen HM-400 und damit wohl "Single"-Wechselrichter - das kann ich an 
einen HM-300, wenn ich vor Ort bin, mal prüfen.

Single-WR senden keine 02er (cmd / Byte 9) Nachrichten, diese senden 
vermutlich nur WR mit >= 2 Panels. Bei WR mit nur einem Panel stecken 
die (bisher erkannten) Daten in folgenden Nachrichten-Bytes (vieles IMHO 
schon bekannt, aber es hier jedenfalls "verlorengegangen": 
[[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]]).

cmd 01 =>
12/13: DC-Spannung, Divisor 10
14/15: DC-Strom, Divisor 100
16/17: DC-Leistung, Divisor 10
18/19: unbekannt, bei mir immer 0
hier ist IMHO bei WR mit >= 2 Panels die DC-Spannung des 2. Panels enthalten
20/21: Gesamtleistung kWh, Divisor 1000 - (mir) unklar ob DC/AR Wert
hier ist IMHO bei WR mit >= 2 Panels der DC-Strom des 2. Panels enthalten
22/23: tägliche Leistung Wh, Divisor 1? - (mir) unklar ob DC/AC Wert
hier ist IMHO bei WR mit >= 2 Panels die DC-Leistung des 2. Panels enthalten
24/25: Spannung, Divisor 100

cmd 82 =>
10/11: Frequenz, Divisor 10
20/21: Temperatur, Divisor 10

Einen GIT-Account habe ich. Könnte o.g. Format-Beschreibung ergänzen. 
Diese müsste nach meiner Vermutung dann aber nach WR-Bauart (Anzahl 
Panels) unterscheiden.
Für einen HM-400 sind somit erstmal die wesentlichsten Daten bekannt. 
Das mit den Leistungswerten (Gesamt/Tag) will ich selbst noch mal bei 
mir verifizieren.

[Martin P. (mpolak77)]

Hallo Markus,

ich fände es auch gut, das Wissen wo Zentral zu sammeln.
Zum Thema HM-400/350 habe ich am 9.4 gepostet:
(Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")

Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut)

01:
2bytes unbekannt "1"
2bytes dc_volt  / 10
2bytes dc_amps  / 100
2bytes dc_power / 10
4bytes Total_w
2bytes Daily_w
2bytes ac_volt / 10

82:
2bytes ac_freq / 100
2bytes ac_power / 10
2byte  unbekannt "0"
2bytes ac_current / 100
2byte  unbekannt  "1000" vielleicht /10 Power Factor in %?
2bytes temp / 10
2bytes unbekannt ansteigend
2bytes random

Die Total Werte scheinen immer 4byte Werte zu sein.
Das muss wohl bei HM-600/700 auch so sein .... allerdings geht sich das 
dort nicht so einfach aus

[Marcel A. (a-marcel)]

Lukas P. schrieb:
> Marcel A. schrieb:
>> Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern
>> das es für esp8266 und esp32 geht.
>
> finde ich super! Verwende am besten als Basis meinen aktuellen
> Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen
> veröffentlichten neuen Stand in main-Branch.

Ich hatte mir bisher nur das Repo https://github.com/grindylow/ahoy 
angeschaut und da gibt es keinen Dev Branch. Welchen Code meinst du ?

[Lukas P. (lumapu)]

Da ich nicht der Eigentümer des Hauptrepositories bin habe ich einen 
Fork in meinem Account. Ich verlinke es nicht, da das Hauptrepository 
die Referenz für alles bleiben soll. Suche einfach nach dem Fork (auf 
der rechten Seite unter "About") von "lumapu" und dort im "dev" Branch.

[Marcus (Gast)]

Martin P. schrieb:
> ich fände es auch gut, das Wissen wo Zentral zu sammeln.

Habe das ergänzt und einen Pullrequest (PR) im git ausgelöst.
Zu:

4bytes Total_w
2bytes Daily_w

1. ist das eigentlich die Leistung DC oder AC?
2. Total_w sind doch auch nur 2 Bytes, oder?
Siehe hier (PR) unter cmd 01: 
[[https://github.com/grindylow/ahoy/pull/7/commits/dfa7975fedaa3993bd3655aa52bdaa83614dbac4]]

[Martin P. (mpolak77)]

Marcus schrieb:
> 1. ist das eigentlich die Leistung DC oder AC?

Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher, 
dass es DC ist: der HM400 hat daily/total nur einmal .... der 2-port 
HM600 hat diese Werte je 2x (wie die DC Daten)

> 2. Total_w sind doch auch nur 2 Bytes, oder?
Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil 
die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter 
oben hat es Herbert K. schon gezeigt, dass es so ist.

[Marcus (Gast)]

Martin P. schrieb:
>Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher,
>dass es DC ist:
Wenn es aber die Leistungswerte für DC sind - gibt es die Gesamtwerte 
für AC gar nicht? Pro Panel mag das ja interessant sein, aber die Summe 
ist eben m.E. nur näherungsweise gleich der Summe AC seitig (beim 
Wandeln entstehen ja auch noch "Verluste") - oder wird das ggf. mit 
einem Faktor abgebildet, der weniger Bytes benötigt, als nochmal 2+4 
Bytes für AC zu benötigen (Spekulation).
Die momentane Leistung für AC ist ja inzw. bekannt - fehlt irgendwie 
Ptotal und Pdaily für AC.

> Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil
> die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter
> oben hat es Herbert K. schon gezeigt, dass es so ist.

Ahhh - das hatte ich übersehen - hab mich schon immer über die ständigen 
Nuller gewundert in den vorderen 2 Bytes - ich bin noch nicht über 65535 
Wh ;-). Muss das in meiner Beschreibung noch korrigieren. Für den HM-400 
habe ich jetzt alles sauber aufgeschrieben und versuche es in das GIT 
einzuchecken.

[Lukas P. (lumapu)]

Hallo zusammen,

es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist 
die 0.2.4
Sie bassiert auf dem Konzept von Hubi, Vielen Dank nochmal. Wir haben 
weitere Ideen, die dann in die nächste Version einfließen werden.

Das sollte möglich sein:
- mehrere Wechselrichter, aktuell sind per define 3 voreingestellt
- verschiedene Wechselrichter, aktuell ist zwischen HM600 und HM1200 die 
Wahl
- Pinout kann konfiguriert werden, voreingestellt ist das des Wemos 
D1mini
- die Konvertierung der HMTL Seiten passiert jetzt mit python und sie 
werden im PROGMEM abgelegt
- der code wurde soweit verändert, dass prinzipiell auch eine 'einfache' 
Portierung auf den proMini (328p) denkbar ist
- ein MQTT client wurde eingebaut um die Werte woanders zu visualisieren 
(z.B. ioBroker)

Über Feedback und Tests würde ich mich freuen, viel Spaß mit der neuen 
Firmware!

Im Anhang habe ich mal meinen Build gehängt, damit man auch ohne 
Kompilieren auf die neue Version updaten kann - mal sehen ob das klappt.

[Heinz R. (heijz)]

Hallo Lukas,

Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur 
den unten gezeigten Output


Der D1- Mini lief schon mal mit einem viel weiter oben im Thread 
gezeigten Programm

Ich habe ihn zum Test auch mal mit einem blank-File geflasht - leider 
auch erfolglos

Viele Grüße


 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00057330
~ld

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Soft WDT reset

>>>stack>>>

ctx: cont
sp: 3ffffb40 end: 3fffffc0 offset: 01a0
3ffffce0:  00000000 3ffe901c 3ffeeff0 40204b01
3ffffcf0:  00000000 00000000 00000000 00000000
3ffffd00:  00000000 00000000 00000000 00000000
3ffffd10:  00000000 00000000 00000000 00000000
3ffffd20:  00000000 00000000 00000000 00000000
3ffffd30:  00000000 00000000 00000000 00000000
3ffffd40:  00000000 00000000 00000000 00000000
3ffffd50:  00000000 00000000 00000000 00000000
3ffffd60:  00000000 00000000 00000000 00000000
3ffffd70:  00000000 00000000 00000000 00000000
3ffffd80:  00000000 00000000 00000000 00000000
3ffffd90:  00000000 00000000 00000000 00000000
3ffffda0:  00000000 00000000 00000000 00000000
3ffffdb0:  00000000 00000000 00000000 00000000
3ffffdc0:  00000000 00000000 00000000 00000000
3ffffdd0:  00000000 00000000 00000000 00000000
3ffffde0:  00000000 00000000 00000000 00000000
3ffffdf0:  00000000 00000000 00000000 00000000
3ffffe00:  00000000 00000000 00000000 00000000
3ffffe10:  00000000 00000000 00000000 00000000
3ffffe20:  00000000 00000000 00000000 00000000
3ffffe30:  00000000 00000000 3ffe0000 40212768
3ffffe40:  00000000 3ffe901c 3ffeeff0 402080cb
3ffffe50:  3fff0f84 feefeffe 402045cc 40212848
3ffffe60:  40207694 00000000 3ffeeff0 00000000
3ffffe70:  40206f9c 00000000 3ffeeff0 feefeffe
3ffffe80:  feefeffe feefeffe feefeffe feefeffe
3ffffe90:  3fff0054 3fff0054 0000000f feefeffe
3ffffea0:  feefeffe feefeffe feefeffe 3ffef324
3ffffeb0:  3ffeeff0 00000000 3ffeeff0 402033ba
3ffffec0:  feefeffe feefeffe feefeffe feefeffe
3ffffed0:  feefeffe feefeffe feefeffe feefeffe
3ffffee0:  feefeffe feefeffe feefeffe feefeffe
3ffffef0:  feefeffe feefeffe feefeffe feefeffe
3fffff00:  feefeffe feefeffe feefeffe feefeffe
3fffff10:  feefeffe feefeffe feefeffe feefeffe
3fffff20:  feefeffe feefeffe feefeffe feefeffe
3fffff30:  feefeffe feefeffe feefeffe feefeffe
3fffff40:  feefeffe feefeffe feefeffe feefeffe
3fffff50:  feefeffe feefeffe feefeffe feefeffe
3fffff60:  feefeffe feefeffe feefeffe feefeffe
3fffff70:  feefeffe feefeffe feefeffe feefeffe
3fffff80:  feefeffe feefeffe feefeffe 3ffef324
3fffff90:  3fffdad0 00000000 3ffeeff0 4020458b
3fffffa0:  feefeffe feefeffe 3ffef310 4021038c
3fffffb0:  feefeffe feefeffe 3ffe85d8 40100e65
<<<stack<<<

[Marcus (Gast)]

Lukas P. schrieb:
> es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist
> die 0.2.4

Würde ich gerne auch testen, habe aber nur einen HM-400. Da ich heute eh 
im Thema stecke, hier die Tabelle aller bisher bekannten Werte um den 
400er ggf. leicht zu ergänzen:

//-------------------------------------
// HM400 (vermutlich auch HM-350 und HM-300)
//-------------------------------------
const byteAssign_t hm400assignment[] = {
    { FLD_UDC, UNIT_V,  CH1, CMD01, 14, 2, 10  },
    { FLD_IDC, UNIT_A,  CH1, CMD01, 16, 2, 100 },
    { FLD_PDC, UNIT_W,  CH1, CMD01, 18, 2, 10  },
    { FLD_YT,  UNIT_KWH,CH2, CMD01, 20, 4, 1000 },
    { FLD_YD,  UNIT_KWH,CH2, CMD01, 24, 2, 1000 },
    { FLD_UAC, UNIT_V,  CH0, CMD01, 26, 2, 10  },
    { FLD_F,   UNIT_HZ, CH0, CMD82, 12, 2, 100 },
    { FLD_PAC, UNIT_W,  CH0, CMD82, 14, 2, 10  },    
    { FLD_IAC, UNIT_A,  CH0, CMD82, 18, 2, 100 },
    { FLD_T,   UNIT_C,  CH0, CMD82, 22, 2, 10  }
};

Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du 
aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf 
Deine komme.
Beispielnachricht:

95 7310xxyy 7310xxyy 010001 0198 004001060000FA7B00190922F8C75E 1

Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0 
anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC 
Spannung des 1. Moduls. Ggf. muss das noch angepasst werden.

[Ziyat T. (toe_c)]

Lukas P. schrieb:
> Hallo zusammen,
>
> es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist
> die 0.2.4
Danke für die Arbeit!

Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR 
als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird? 
(WR Library?)
Wollte drauf hinweisen, dass das MI-Series Datenformat völlig 
verschieden ist (CMD,MID,Ports etc.)

Bisherige Erkentnisse vom MI1500, siehe Anhang

[Lukas P. (lumapu)]

Marcus schrieb:
> Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du
> aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf
> Deine komme.
> Beispielnachricht:95 7310xxyy 7310xxyy 010001 0198
> 004001060000FA7B00190922F8C75E 1
> Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0
> anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC
> Spannung des 1. Moduls. Ggf. muss das noch angepasst werden.

Deine Definition habe ich mal eingebaut und commited. Dabei habe ich 
noch geringfügige Änderungen gemacht. Aufgefallen ist mir, dass für den 
HM1200 alle Idizes ungerade sind, deine sind alle gerade.
Meine Zählweise ist so:
Byte 0 = cmd
Byte 1 .. x Daten

Ich wollte das durch diesen Kommentar (über den Definitionen) 
ausdrücken, evtl. muss man es umformulieren.

/**
 *  indices are built for the buffer starting with cmd-id in first byte
 *  (complete payload in buffer)
 * */

Die Kanäle habe ich wie folgt aufgebaut:
CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten
CH1-CH4: je nach Wechselrichter die Anschlüsse für Module

[Lukas P. (lumapu)]

Heinz R. schrieb:
> Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur
> den unten gezeigten Output

Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der 
Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären.

[Lukas P. (lumapu)]

Ziyat T. schrieb:
> Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR
> als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird?
> (WR Library?)

Klar wir sind für alles offen, wir versuchen jetzt mal das schon 
bekannte in einer Firmware zusammenzufassen. Wenn du Input / Ideen hast 
kannst du sie gerne jederzeit beitragen. Ich würde sagen: Je mehr und 
je vollständiger die WR unterstützt werden umso besser!

[Heinz R. (heijz)]

Lukas P. schrieb:
> Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der
> Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären.

funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 
flashst?

[Marcus (Gast)]

Lukas P. schrieb:

Zur Zählweise - hier erkennst Du es denk ich ganz deutlich (ich warte 
noch auf einen PR in das offizielle Repo-Doku): 
[[https://github.com/dad401/ahoy/blob/main/doc/HM-400%20data.xlsx]]

> Die Kanäle habe ich wie folgt aufgebaut:
> CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten
> CH1-CH4: je nach Wechselrichter die Anschlüsse für Module

Ja, ich habe es mir inzwischen so gedacht - hatte mir vorher Channels = 
cmd01 etc. bzw. Radio-Channels vorgestellt. Demnach hat der HM-400 CH0 
(AC, Freq, Spannung, Temp) und CH1 den Rest vom Panel.

Habe den 400er auch in Deinen Code eingebaut/-bastelt, kann nur wegen 
Dunkelheit nicht mehr testen. Kommt morgen...
Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch 
das CMD82 (hminverters.h)?

enum {CMD01 = 0x01, CMD02, CMD03, CMD83 = 0x83, CMD84};

Der Code ist eine gute Grundlage für Tasmota - bin da zwar eher Amateur, 
aber man lernt daran und einen adaptierten SDM230-Treiber 
(Wechselstromzähler) wurde auch als PR schon angenommen :-) - Bin 
gespannt ob das klappt. Einzig die Ressourcen sind da arg knapp und die 
Anzahl der WR sollte man da auch beschränken. Aber Web und MQTT kommt 
von Haus aus mit.

[Mich@ (Gast)]

Hallo Lukas,

Ich kann auch bestätigen das die neue Firmware nicht auf dem Wemos D1 
Mini läuft. Weder das bin file (mit Tadtomizer und mit ESP-Easy flasher 
getestet) sowie auch die Version von Github mit Arduino IDE neu 
Kompiliert und geflasht. Bei beiden Varianten das gleiche Ergebnis wie 
Heiz bereits geschrieben hat.

[Mike (Gast)]

Ziyat T. schrieb:
>
> Bisherige Erkentnisse vom MI1500, siehe Anhang

Ich bin der Meinung, das die Werte in der letzten Spalte das 
Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der 
aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt 
(Nur in der Webansicht).

[Lukas P. (lumapu)]

Sehr schade, worin liegt der Unterschied zwischen meinem ESP-07 und dem 
Wemos D1mini? Ich glaube der ESP-07 hat 1MB Flash.
Ich habe bisher keinen Wemos.

Marcus schrieb:
> Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch
> das CMD82 (hminverters.h)?

wird nachgereicht, du hast Recht

[isnoAhoy (Gast)]

Hallo Lukas,

ich habe mal Deinen dev branch ausgecheckt und übersetzt.

Dabei habe ich folgende Änderungen für Linux hinzugefügt:

tools/fileConv.sh:

#!/bin/bash
echo String $3 = \"$(cat $1 | tr '\n' ' ' | sed 's/"/\\"/g;s/\s\{4\}/\t/g')\"\; > $2

html/conv.sh:

#!/bin/bash
../tools/fileConv.sh index.html h/index_html.h index_html
../tools/fileConv.sh setup.html h/setup_html.h setup_html
../tools/fileConv.sh hoymiles.html h/hoymiles_html.h hoymiles_html
../tools/fileConv.sh style.css h/style_css.h style_css

platform.txt:

# add a prebuild hook to generate minified h files from html templates
recipe.hooks.prebuild.1.pattern={build.path}/html/conv.sh
recipe.hooks.prebuild.2.pattern={build.path}\html\conv.bat

Wobei die prebuild hooks in der platform.txt offenbar noch nicht 
greifen. Vielleicht kennt sich ja jemand damit aus, wie man das HTML/CSS 
minify der templates im html Verzeichnis richtig anstoßen kann.

Auch die folgende Speicheroptimierung habe ich noch nicht in den o.g. 
Generator eingebaut.

> Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:

static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"
String body = FPSTR(HTTP_BODY);
body.replace("{{variable}}", configuration.variable);
page += body;

Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das 
halt im Dev Branch =^D

Dafür sind die ganzen versprochenen Anpassungen schon da !
* WiFi mit SSID und Password
* Device Name: ESP-AHOY
* bis zu vier Inverter 0-3 (wahlweise HM600 / HM1200) mit Adresse im 
114173123456 Format plus ein sprechender Name für jeden
* Abfrage Intervall der Wechselrichter: 1000 ms
* Pin Out Definition CS: D8 (GPIO15), CE: D4 (GPIO2) und IRQ: D3 (GPIO0) 
im Default und wählbar.
* MQTT Settings mit Broker / Server IP, Username & Password, Topic 
(/inverter) sowie Interval (10000 seconds)

Besonders gefällt mir das flexible Mapping der Bytes in den Nachrichten 
auf die enstprechenden Felder (DC U/I/P und AC U/I/P/Freq, etc.) der 
Wechselrichter in der hmInverters.h.
Ich muß mir das mal genauer ansehen, ich meine es gab auch Felder die 
u.a. auf zwei Nachrichten 0x01 Buffer Byte 15/16 und 0x02 Buffer Byte 
1/2 aufgeteilt waren ?
Das habe ich gestern bei meinen Versuchen eine hm600Decode.h 
zusammenzubasteln nicht gebacken bekommen.
Die bei meinem Hoymiles immer wieder auftretenden 0x83 Nachrichten 
werden aktuell unter other summiert. Evtl. wäre es da hilfreich diese 
Nachrichten sowie die 0x82 bei anderen WR gesondert zu zählen ?

[Mich@ (Gast)]

Hallo Lukas,

Der D1 Mini hat 4mb fashspeicher…
Die Vorgänger Version in dem nur der HM1200 unterstützt wurde lief ohne 
Probleme.

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das
> halt im Dev Branch =^D

Bin ich froh, dass es bei dir klappt. Jetzt wäre es noch toll wenn du 
den heutigen main Branch verwenden würdest.
Damit die Wifi Settings nicht ständig weg sind, wenn man die Liste der 
zu speichernden Parameter erweitert, habe ich jetzt einen weiteren CRC 
eingeführt, der nur über die Wifi Settings geht.

Dein conv.sh ist leider fast überflüssig, aber wir können es parallel 
ablegen. Ich habe heute auf python umgestellt, dadurch sind wir 
plattformunabhängig.

Heinz R. schrieb:
> leeren ESP8266
> flashst?

Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle 
mich von OTA Update zu Update =)
Das erinnert mit daran in der Konfiguraiton einen Erase Button 
einzuführen =)