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).
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.
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.
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?
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.
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)
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.
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)
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
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)
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 :-)
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.
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?
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!
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?
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
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°
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!
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
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
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ß
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" ?
1
// Packet control field - PID Packet identification
2
uint8_t val = (p.packet[1] >> 1) & 0x03;
3
Serial.print(val);
4
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
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)
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
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.
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"
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.
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...
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.
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.
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
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.
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
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?
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
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.
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?
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 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
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
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.
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
> 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..
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
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:
1
floatextractValue4(uint8_t*p,intdivisor){
2
//-------------------------------------------
3
uint32_tret=*p++;
4
for(uint8_ti=1;i<=3;i++)
5
ret=(ret<<8)+*p++;
6
return(ret/divisor);
7
}
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.
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
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?)...
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.
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!
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)
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 ;-)
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 :)
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.
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
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
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.
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
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.
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.
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.
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.
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.
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
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 !!!
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
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!
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 :-(
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.
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!
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.
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.
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.
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?
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
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.
> 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.
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…
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.
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
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.
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
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?
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.
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.
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.
@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.
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!?
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
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
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.
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:
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 !
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).
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)
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.
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
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?
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.
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'?
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…
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).
> 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.
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
> 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/
> 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 ?
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.
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
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.
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.
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.
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.
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?
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.
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.
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
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:
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ä.
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.
> 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 :)
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 ;-)
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.
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 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?
@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.
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.
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 schrieb:> Ist das die letzte Version mit der Routine Serial2RadioID?> Seriennummer auch richtig eingetragen, also> Seriennummer zb 114172607952 dann>
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
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
:-)
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.
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
@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 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
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+)
@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 ?
@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.
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#L97Petra-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)
@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.
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 ?
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.
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
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:
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?
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!
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:
1
CMDs:
2
0x01:18
3
0x02:0
4
0x03:0
5
0x81:55
6
0x84:0
7
other:13
8
9
CHANNELs:
10
23:0
11
40:9
12
61:44
13
75:33
@Herbert K.
Welche Erweiterungen hast Du für den 400er denn vorgenommen?
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.
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:>
1
CMDs:
2
>0x01:18
3
>0x02:0
4
>0x03:0
5
>0x81:55
6
>0x84:0
7
>other:13
8
>
9
>CHANNELs:
10
>23:0
11
>40:9
12
>61:44
13
>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
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 ;-)
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
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.
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 ?
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?
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
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.
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]]).
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.
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
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 ?
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 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.
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.
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.
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:
1
//-------------------------------------
2
// HM400 (vermutlich auch HM-350 und HM-300)
3
//-------------------------------------
4
constbyteAssign_thm400assignment[]={
5
{FLD_UDC,UNIT_V,CH1,CMD01,14,2,10},
6
{FLD_IDC,UNIT_A,CH1,CMD01,16,2,100},
7
{FLD_PDC,UNIT_W,CH1,CMD01,18,2,10},
8
{FLD_YT,UNIT_KWH,CH2,CMD01,20,4,1000},
9
{FLD_YD,UNIT_KWH,CH2,CMD01,24,2,1000},
10
{FLD_UAC,UNIT_V,CH0,CMD01,26,2,10},
11
{FLD_F,UNIT_HZ,CH0,CMD82,12,2,100},
12
{FLD_PAC,UNIT_W,CH0,CMD82,14,2,10},
13
{FLD_IAC,UNIT_A,CH0,CMD82,18,2,100},
14
{FLD_T,UNIT_C,CH0,CMD82,22,2,10}
15
};
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:
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.
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
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.
1
/**
2
* indices are built for the buffer starting with cmd-id in first byte
3
* (complete payload in buffer)
4
* */
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
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.
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!
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?
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)?
1
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.
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.
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).
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
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:
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 ?
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 =)