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

[Ziyat T. (toe_c)]

Mike schrieb:
> 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).

Leider nicht,
z.Bsp.
Zeile 3,Spalte 2, B7(port2) ist nicht belegt, PW=0, Spalte AX 1.18, geht 
nicht auf
Zeile 2,Spalte 2, B8(port2) ist belegt, PW=75.4, Spalte AX 0.01 geht 
nicht auf

[Heinz R. (heijz)]

Lukas P. schrieb:
> 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 =)

Es gibt z.B. bei ESPEasy Blank-Files - habe Dir mal eines angehängt

[Lukas P. (lumapu)]

Jetzt fällt mir noch was ein in hmRadio.h:83 ist noch immer 
'RF24_PA_MAX' definiert, bei mir funktioniert es, evtl. bricht beim 
ersten Sendeversuch die Spannung ein. Ich habe an den 3.3V einen dicken 
Elco, man sieht aber trotzdem, dass die LEDs kurz dunkler werden.

@Heinz
Dein blank.bin sieht aus wie ein frisch gelöschter Speicher, alles 0xFF 
=). Vielen Dank.

[Bert 0. (maschinist)]

Mit ESP-12e:
Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis 
zum Löschen des EEPROMs, dann schlägt der WDT zu.

Gruß... Bert

[Lukas P. (lumapu)]

Bert 0. schrieb:
> Mit ESP-12e:
> Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis
> zum Löschen des EEPROMs, dann schlägt der WDT zu.
>
> Gruß... Bert

Super, danke für den Hinweis, die Fehler sind dann eindeutig in der 
eep.h und zwar in Zeile 40 und 81
Die For loops werden mit einem 8-bit zähler niemals die 16bit length 
zählen können -> Endlosschleifen

Commit ist gleich unterwegs ;-)

Kann bitte einer nochmal kurz die Sonne einschalten zum Testen? :-P

[Bert 0. (maschinist)]

Jop, mit dem letzten Commit startet die Applikation wieder korrekt, Fix 
reviewed OK!
;-)

Gruß... Bert

[Thomas B. (tbnobody)]

Ich kann btw. auch bestätigen, dass die Zuordnung auch für den HM-1500 
sinn macht: 
https://github.com/grindylow/ahoy/blob/bf8c1628973eb1dc53b2604b6a7bc1561174f004/tools/esp8266/hmInverters.h#L100

Hab die Zuordnung mit einem meiner Dumps getestet... sieht alles 
plausibel aus

[Mich@ (Gast)]

Die neue Version läuft auf dem Wemos D1!
Besten Dank.

[Heinz R. (heijz)]

Mich@ schrieb:
> Die neue Version läuft auf dem Wemos D1!
> Besten Dank.

Gibt es die evtl. auch als fertig kompiliertes bin?

[Lukas P. (lumapu)]

Ja im Anhang ist die neuste Verison
- hat jetzt eine Erase Application data Option
- Cmds 0x82 und 0x83 tauchen in Statistik auf

[Robert S. (Gast)]

Ich springe auch mal auf den Zug auf ;-)

Erstmal ***VIELEN DANK*** an alle Beteiligten!!!!
Ich bin noch an den Vorbereitungen, mein HM1200 ist noch nicht 
geliefert,
und ich habe auch noch kein NRF, daher derzeit nur beschränkte 
Möglichkeiten.

Die aktuelle 0.2.6 läuft aber schon mal auf einem Wemos D1 mini (clone) 
:-)
- WIFI-Connection ist ok
- Webseite funktioniert
- MQTT ist inkl. user/pass eingetragen wird aber als "not connected"
  angezeigt. Im MQTT-Sniffer sehe ich aber das Topic und den 
FirmwareRelease.
  Sonst nichts, es gibt aber ja auch noch keine Daten.

Meine Fragen:
- Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber 
in (s)
  Stimmt das?
- Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein 
Satzzeichen,
  ist das ok (erlaubt)?

viele Grüße
Robert

[Marcel A. (a-marcel)]

Hallo,

ich bin leider kein C++ Programmierer und habe jetzt einen Status 
erreicht, wo ich nicht weiter kann. Ich wollte den Code auf ESP32 
anpassen und hab auch viele Sachen angepasst, aber jetzt verlangt es 
langsam bessere C Knowledge.

Ich würd mich freuen, wenn jemand da helfen kann ! Ich pack mal das 
error rein, welches ich bekomme wenn ich kompiliere.

Ich nutze auch PlatformIo und habe da die Ordner Struktur angepasst.

Zu finden sind die Änderungen in dem Fork in meinem Account: 
https://github.com/a-marcel/ahoy

Ich würde mich freuen, wenn es auch für ESP32 geht, weil der ja mehr 
Speicher hat es einfacher sein sollte.

[Lukas P. (lumapu)]

Hallo Marcel,

finde ich super! Mal ein paar Dinge, die offensichtlich sind. Er findet 
die Datei "eep.cpp" nicht und er kommt nicht mit den 'Tickern' zurecht. 
Evtl. benötigt er eine Library / Include dafür.

Evtl. tut man sich leichter, wenn man den Code erst mal für den ESP8266 
in PlatformIO kompiliert.

Robert S. schrieb:
> Meine Fragen:
> - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber
> in (s)
>   Stimmt das?
> - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein
> Satzzeichen,
>   ist das ok (erlaubt)?

- Inverval wird korrigiert, ist auch in ms
- Das Passwort wird einfach als String (char-array) gespeichert, daher 
ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen 
begrenzt und der User auf 16 Zeichen.
- der Status des MQTT Brokers war invertiert -> korrigiert

[Robert S. (Gast)]

Lukas P. schrieb:
> - Inverval wird korrigiert, ist auch in ms
> - Das Passwort wird einfach als String (char-array) gespeichert, daher
> ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen
> begrenzt und der User auf 16 Zeichen.
> - der Status des MQTT Brokers war invertiert -> korrigiert

Genial, funktioniert!
Vielen Dank für den superschnellen Fix!
Robert

[Marcus (Gast)]

Heinz R. schrieb:
> funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266
> flashst?

Auch hier kommt der Watchdog (Wemos D1 mini). Auch ein

esptool.py erase_flash

 hilft nicht.

[isnoAhoy (Gast)]

Hallo Lukas P.,

danke für die vielen Commits und Fixes heute abend, nur das mit der 
Sonne hat nicht mehr gereicht =^D
Ich schaue mir morgen bei Tag nochmal die HM-600 Werte an, da hast Du ja 
zuletzt noch etwas gefixt.

Habe gerade nochmal die 0.2.7 geflashed, nach einem mutigen ERASE 
SETTINGS (not WiFi) kam auch folgender Fehler nicht mehr:
00:25:38.848 -> add inverter: oymiles A, SN: 114173123456, type: 0
00:25:38.848 -> no assignment for type found!add inverter: , SN: 
480000000000, type: 3
Irgendwie hat er im EEProm wohl daneben gegriffen und das "H" des ersten 
WR Namens als SN für einen weiteren Wechselrichter interpretiert.
Danke für die Funktion zum beibehalten der SSID und des WiFi Passworts 
das ist sehr praktisch und hilfreich!

Auch die PA_MIN, PA_LOW, PA_HIGH, PA_MAX Einstellung funktioniert jetzt 
laut Debug Ausgabe:
00:29:55.769 -> add inverter: Hoymiles HM-600, SN: 114173123456, type: 0
00:29:55.802 -> RF24 Amp Pwr: RF24_PA_MAX

Wie gesagt Device Name könnte noch mit ESP-<WIFIMAC> vorbelegt sein.

[isnoAhoy (Gast)]

Hallo Heinz R.,

kannst Du mal zum Flashen den Serial Monitor der Arduino IDE schließen.
Ich meine das ist eine häufige Fehlerquelle wenn er die Firmware 
übertragen will und dabei vorzeitig abbricht.
Vielleicht hilft das ja auch in Deinem Fall.

[isnoAhoy (Gast)]

Hallo Heinz R.,

jetzt habe ich mal den weiter oben genannten Stack Trace von Dir 
versucht zu analysieren.

Schau Dir doch mal bitte folgende Seite an:
https://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html
Dort wird die Vorgehensweise bei solchen Exceptions Problemen 
beschrieben.
Den ESP Exception Decoder habe ich nach der Anleitung ausgepackt und 
installiert
https://github.com/me-no-dev/EspExceptionDecoder#installation

Leider habe ich nicht den zugehörigen Source Code bzw. das ELF Binary um 
daraus Sinn zu machen bzw. Deinen alten Stack Trace zu analysieren. Mir 
fehlt auch der Exception Code um das Problem prinzipiell eingrenzen.

Ich hatte übrigens gestern abend auch einen Stacktrace gesehen.
Nach einigen Restarts geht es jetzt aber sauber, kann es also nicht 
einfach reproduzieren.

Hast Du evtl. einige Clients die auf den ESP per WiFi zugreifen wollen 
oder wird viel per Serial geloggt ?
I.d.R. treten solche WDT Exceptions auf, wenn der ESP seine WiFi 
Schnittstelle nicht parallel zum Programm bedienen/abarbeiten kann.
Vielleicht kann man es ja an der richtigen Stelle mit einem yield() 
beheben ?

Was für Einstellungen hast Du denn für Deinen ESP8266 im Tools Menü 
gewählt ?
Eventuell liegt es ja an etwas einfachem wie der Frequenz, Debug 
Optionen, o.a.

[Lukas P. (lumapu)]

Guten Morgen,

ich weiß nicht, ob ich es schon genannt hatte: die Seriennumer muss 
jetzt genauso wie sie auf dem WR steht eingetragen werden, ohne ":".

Im Anhang noch die Version 0.2.7 und im zip das .elf zum debuggen von 
Stack-Traces.

Mit meinem HM1200 geht die Firmware bei Tageslicht =)

[isnoAhoy (Gast)]

Guten Morgen Lukas P.,

also ich habe (nach wie vor) seltsame Werte für meinen zweiten Kanal am 
HM-600 (bisher unbelegt daher vermutlich free-floating):
CHANNEL 1 230.40 V U_DC 2.27 A I_DC 804.10 W P_DC 50467.00 Wh YieldDay
CHANNEL 2 1557.50 V U_DC 393.21 A I_DC 3932.10 W P_DC 10711.00 Wh 
YieldDay

Die Yield Total und Week sowie AC Werte / Temperatur werden aktuell noch 
nicht angezeigt bzw. deren u.g. Werte erscheinen mir fraglich.
Kann man die rohen Datenpakete wieder ausgeben lassen, das war m.W. 
dumpBuf o.a. ?

Hier mal die Werte aus dem Serial Monitor:
08:42:04.674 -> hm600/ch1/U_DC: 230.400 V
08:42:04.674 -> hm600/ch1/I_DC: 2.300 A
08:42:04.674 -> hm600/ch1/P_DC: 190.600 W
08:42:04.674 -> hm600/ch2/U_DC: 1368.500
08:42:04.674 -> hm600/ch2/I_DC: 393.210 A
08:42:04.707 -> hm600/ch2/P_DC: 3932.100
08:42:04.707 -> hm600/ch0/YieldWeek: 1024.000
08:42:04.707 -> hm600/ch0/YieldTotal: 94.000 Wh
08:42:04.707 -> hm600/ch1/YieldDay: 32133.000
08:42:04.707 -> hm600/ch2/YieldDay: 10985.000
08:42:04.707 -> hm600/ch0/U_AC: 3932.100
08:42:04.707 -> hm600/ch0/Freq: 393.210 H
08:42:04.707 -> hm600/ch0/I_AC: 3932.100
08:42:04.707 -> hm600/ch0/Temp: 2218.900

Wenn dies eine CSV Ausgabe in einer Zeile wäre, dann könnte das der 
Serial Plotter in der Arduino IDE darstellen:
1U_DC1,1I_DC1,1P_DC1,1U_DC2,1I_DC2,1P_DC2,1YW,1YT,1YD1,1YD2,1U_AC,1Freq, 
1I_AC,1Temp: 
230.400,2.300,190.600,1368.500,393.210,3932.100,1024.000,94.000,32133.00 
0,10985.000,3932.100,393.210,3932.100,2218.900
Am Besten könnte man noch die Spalten auswählen, die per Serial Monitor 
als "CSV" oder im bisherige "MQTT" Format ausgegeben werden =^D

Die Channel Statistik in app.h/.cpp habe ich wieder aktiviert und er 
schickt bei mir alles auf Kanal 61.
Hast Du das Channel Hopping adaptiv angepaßt, d.h. daß es erst bei 
Fehlern (ACK) den Kanal wechselt ?

[Lukas P. (lumapu)]

Habe hin und wieder Exceptions gesehen, daher die 0.2.8

@isnoAhoy: das channel hopping ist aus (hmRadio.h), bringt bei mir 
keinen Vorteil
Ich würde eher die RAW oder Payload Daten plotten lassen und das dann 
per Excel auswerten

[isnoAhoy (Gast)]

Hallo Lukas P.

habe die dumpBuf Aufrufe in hmRadio.h und app.cpp gefunden und wieder 
aktiviert.
Das wäre als Debug Option im Setup sicher auch noch praktisch!

Dazu musste ich die Methode in hmRadio.h vor den private: Bereich 
verschieben,
da sie sonst nicht aus app.ccp aufgerufen werden konnte: declared 
private!

Folgender einfacher Zusatz in dumpBuf() gibt übrigens auch HEX mit 
führender Null aus,
dann klappt es m.E. leichter mit dem Excel Sheet zum dekodieren.

if (buf[i] < 10) Serial.print("0");

[Ziyat T. (toe_c)]

An de NRF Spezialisten,

Ich sehe diese RAWDaten vom MI1500 neben den "Regulaeren", was könnten 
sie sein?

Kann immer noch den MI1500 nicht ansprechen, Daten bekomme ich nur, wenn 
die DTU-Pro eingeschaltet ist.

[Hubi (Gast)]

Hallo  Ziyat

soviel ich noch von weiter oben weiß benutzt du meine SW.
Dass nur Daten kommen wenn DTU an ist bedeutet für mich, dass die DTU 
wohl dem WR einen Anstoß gibt. Weiter oben habe ich auch beschrieben, 
dass beim Senden des Zeit-setzen-Pakets mit einem Wert <> 0B hinter dem 
0x80 ganz neue Antworten kommen. Also vllt braucht dein MI1500 kein 0B 
sondern was anderes.
Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert 
buf[10] von 00 bis FF durchlaufen lassen. etwa so:

static uint8_t cid = 0;

int32_t HM_Packets::GetTimePacket(uint8_t *buf, uint32_t wrAdr, uint32_t 
dtuAdr) {
  prepareBuffer(buf);

  buf[0] = 0x15;
  copyToBufferBE(&buf[1], wrAdr);
  copyToBufferBE(&buf[5], dtuAdr);
  buf[9] = 0x80;

        buf[10] = cid++;   // statt 0x0B
  buf[11] = 0x00;

  copyToBuffer(&buf[12], unixTimeStamp);
.....
Hast du auch schon die einzelnen Sendestärken durchprobiert?

[Marcus (Gast)]

Hi Lukas,

heute ein erster Test mit dem HM-400 und der nun lauffähigen Version. 
Die Werte sind hier auch merkwürdig:

[c]8:05:08.357 -> HM-400/ch1/I_DC: 105.600 A
18:05:08.357 -> HM-400/ch1/P_DC: 4785.400
18:05:08.390 -> HM-400/ch1/YieldTotal: 1056938.3
18:05:08.390 -> HM-400/ch1/YieldDay: 39.321 Wh
18:05:08.390 -> HM-400/ch0/U_AC: 3932.100
18:05:08.390 -> HM-400/ch0/Freq: 473.600 H
18:05:08.390 -> HM-400/ch0/P_AC: 158.300 W
18:05:08.390 -> HM-400/ch0/I_AC: 319.610 A
18:05:08.390 -> HM-400/ch0/Temp: 3932.100[c/]

Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich schau 
mir das mal an...

Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe 
ich da etwas?

Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus 
der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung 
ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob 
die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen 
HM-400 und HM-300 testen.

[Mich@ (Gast)]

Hallo Lukas,

Die neue Version läuft gut auf dem Wemos. Vielen Dank!

Ist es möglich das in den MQTT Einstellungen der Port über das 
webinterface eingestellt werden kann?

[Marcus (Gast)]

Marcus schrieb:
> Ich vermute hier werden die falschen Datenblöcke extrahiert.

Ich bin in C nicht so fit, aber wird hier wirklich der richtige Wert 
extrahiert?

Als Beispiel ein CMD82 Paket:
&p->packet[0] = 00DE957310xxyy7310xxyy82138600350000000203E8009E000AF1

In app.c übergibst Du das Paket ab Position 11:

mSys->addValue(iv, i, &p->packet[11]);

Damit beginnt es ab dem CMD 82:
&p->packet[11] = 82138600350000000203E8009E000AF1

Nun zum addValue Aufruf, welcher hier auf die HM-400 Werte zurück 
greift:

{ FLD_F,   UNIT_HZ,  CH0, CMD82, 12, 2, 100  }

void addValue(inverter_t *p, uint8_t pos, uint8_t buf[]) {
    uint8_t ptr  = p->assign[pos].start; // das müsste ja die 12 sein
    uint8_t end  = ptr + p->assign[pos].num; // 12 plus die Länge von 2
    uint16_t div = p->assign[pos].div; => der Divisorwert 100

    uint32_t val = 0;
        do {
          val <<= 8;  // val = val << 8
          val |= buf[ptr]; // val = val OR buf[12];  aber da buf[] ja die Adresse von packet[11] übergeben bekommt, entspricht dann buf[12] nicht &p->packet[11]+12 Bytes (uint8) weiter?
        } while(++ptr != end);

=> Value hat damit die Werte aus den Positionen packet[23] und 
packet[24] (2 Byte), es muss aber die Werte packet[14] und packet[15] 
haben (das dritte Byte nach dem CMD ist der Start). D.h. start beginnt 
bei 3 (packet[11] + 3), Länge ist mit 2 korrekt.

Oder ich liege völlig falsch?!

[Heinz R. (heijz)]

Hallo Lukas,

habe die neue Version zumindest mal geflasht bekommen und komme auf die 
Weboberfläche
(Ich habe direkt das bin geflasht)

Leider erhalte ich aber keine Daten vom WR
(Das Setup lief so schon mal mit einer SW von weiter oben)

Unten die Ausgabe des seriellen Schnittstelle

Ich habe versucht die RF Power von Max niedriger zu stellen - es springt 
nach dem Speichern leider immer wieder auf Max?

Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 
erkannt werden?

Kleiner Tip noch für zukünftige Versionen:  Gib über die serielle 
Schnittstelle auch die IP-Adresse mit aus, spart langes suchen?

Viele Grüße

load 0x4010f000, len 3460, room 16

tail 4

chksum 0xcc

load 0x3fff20b8, len 40, room 4

tail 4

chksum 0xc9

csum 0xc9

v00057520

~ld

wait for network
.
add inverter: , SN: 116474903203, type: 1

RF24 Amp Pwr: RF24_PA_MAX

Radio Config:

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  = 15

Multicast    = Disabled

Custom ACK Payload  = Disabled

Dynamic Payloads  = Disabled

Auto Acknowledgment  = Disabled

Primary Mode    = RX

TX address    = 0xdeadbeef01

pipe 0 (closed) bound  = 0xdeadbeef01

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

[Lukas P. (lumapu)]

Marcus schrieb:
> Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe
> ich da etwas?
>
> Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus
> der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung
> ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob
> die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen
> HM-400 und HM-300 testen.

Ja Channel 0 wird noch nicht visualisiert, man kann aber durch ein 
define auch hier einfach die Liste der Werte ausgeben lassen.

Das mit der SN habe ich mit anfangs auch gedacht, aber ich finde das 
noch nicht endgültig geklärt - jetzt ist es implementiert und würde ich 
vorerst so lassen. Sind nur 8Bit + alles drin rum ;-)


Mich@ schrieb:
> Ist es möglich das in den MQTT Einstellungen der Port über das
> webinterface eingestellt werden kann?

ja das ist möglich, werde ich demnächst einbauen.


Heinz R. schrieb:

> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt
> nach dem Speichern leider immer wieder auf Max?

ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger 
alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden 
kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert.

> Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01
> erkannt werden?

Habe zufällig so eine Funktion in der Beschreibung der RF24 lib gesehen. 
Kann ich mal testweise einbauen.

> Kleiner Tip noch für zukünftige Versionen:  Gib über die serielle
> Schnittstelle auch die IP-Adresse mit aus, spart langes suchen?

Ja die Rufe werden lauter - wird eingebaut

[Heinz R. (heijz)]

Lukas P. schrieb:
>> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt
>> nach dem Speichern leider immer wieder auf Max?
>
> ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger
> alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden
> kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert.

Hallo Lukas,

auch nach einem Reboot oder gar Reset steht RF Power wieder auf High?

Ich versuche gerade den Fehler einzugrenzen - evtl. doch 
Kommunikationsprobleme mit dem NRF24L?

[Lukas P. (lumapu)]

Das kann dann nur an der Speicherroutine liegen. Ich prüfe es bei mir 
nochmal. Das hat mir dem externen Bauteil nichts zu tun.

[Marcel A. (a-marcel)]

Hallo,

ich probiere noch immer den Code auf ESP32 zum laufen zu bekommen. Ich 
würde da Hilfe von einem, der besser CPP coden kann, gebrauchen.

Mehrere Ticker in der Form von:

mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this));

compilieren mit folgendem Fehler:

src/app.cpp:97:75: error: no matching function for call to 'Ticker::attach_ms(uint16_t&, std::_Bind_helper<false, void (app::*)(), app*>::type)'
         mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this));

Auf Stackoverflow habe ich genau diesen Fehler gefunden, wo auch eine 
Lösung präsentiert wurde. Leider kann ich diese nicht auf den o.g. Code 
anwenden.

https://stackoverflow.com/questions/60985496/arduino-esp8266-esp32-ticker-callback-class-member-function

Vielleicht hat ja ein CPP Pro hier eine Antwort für mich.

Vielen Dank
Marcel

[lpb (Gast)]

Mal wieder ein paar (Wenigstens für mich) neue Erkenntnisse von meinem 
HM600, die aber das vermutlich auch das Protokoll im allgemeinen 
betreffen müssten, und ich glaube, das habe ich hier so noch nicht 
gelesen.

Ich habe versucht, die Zuverlässigkeit des Empfangs der 
Nachrichtenpakete zu verbessern. Einen letztlich guten Hinweis dazu habe 
ich in dem DTU log aus 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" gefunden.

Ganz allgemein, je nach Anfrage sendet der Inverter verschiedene 
Nachrichten als Antwort.
Meine 'Standard' Anfrage basiert auf der GetTimePacket Nachricht, die 
auch in dem DTU log enthalten ist.
Darauf hin kommen die Antworten 0x01, 0x02, und 0x83 zurück. Für die 
Antworten spielt es offensichtlich keine Rolle, ob das Byte 19 0 oder 5 
ist (die Anfragen der DTU logs haben 0, daher habe ich das mal versucht 
- wie gesagt ohne wirklichen Unterschied).

Beim Anschauen der DTU logs habe ich auch eine Anfrage gesehen, die im 
Byte 10 statt 0x0B eine 0x11 hat.
Wenn ich das an den HM600 sende, bekomme ich (nach anpassen des Rx 
channel scans) zuverlässig die Antworten 0x01, 0x02, ... 0x0B, 0x8C.

Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* 
Nachrichten das letzte Antwortpaket markieren. Das diese oft nicht so 
oft empfangen werden könnte Dara liegen, dass alle Nachrichten auf einem 
Kanal erwartet werden. Das ist aber nicht der Fall - dazu später mehr.

Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das 
Anfordern eines nicht erhaltenen Pakets.
Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket 
anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'.

Das habe ich heute so erfolgreich getestet:

19:12:16.870 -> sending data request...
19:12:16.973 -> [75] 024A2F0000505F00B400BE08C8138500C76618A1 
19:12:16.973 -> AC_Power: 19.9W, AC_Voltage: 224.8V, Frequency: 49.97Hz
19:12:16.973 -> Day_Production: 370Wh (180 + 190)
19:12:16.973 -> Total_Production: 39.6kWh (18991 + 20575)
19:12:17.007 -> [75] 830000000903E800840B5E8BB6188E89 
19:12:17.007 -> Level(?): 0
19:12:17.007 -> Status: 1000
19:12:17.007 -> AC_Current: 0.09A
19:12:17.007 -> Temperature: 13.2°C
19:12:17.308 -> 
19:12:17.308 -> sending re-transmit request 01...
19:12:17.375 -> [75] 010001014B001F006701480020006A0000A46F02 
19:12:17.375 -> PV1-V: 33.1V, PV1-C: 0.31A, PV1-P: 10.3W
19:12:17.375 -> PV2-V: 32.8V, PV2-C: 0.32A, PV2-P: 10.6W

Wie man sehen kann, fehlt die erste Antwort. Diese frage ich dann noch 
einmal dediziert an, und habe dann alle Pakete (Anfrage ist immer auf 
Kanal 40, hier alle Antworten auf Kanal 75).

Das erklärt dann eventuell auch, warum AutoAck nicht verwendet wird; has 
hat mich bei der Suche nach einem Schema für den Kanalwechsel immer 
wieder etwas verwirrt.

Ich dachte eigentlich, dass das Fehlen von Nachrichten an meinem 
'simplen' Kanal-Scannen liegt, aber in DTU log kann man diese erneute 
Anfrage ebenfalls schön sehen. Könnte also ein Hinweis darauf sein, dass 
es keine feste Synchronisation der Kanalwechsel gibt, und daher 
Paketverluste 'eingeplant' sind.

Durch die 'vielen' Antworten auf die '11er' Anfrage habe ich dann auch 
gesehen, dass ich meine channel List anpassen musste.
Mit

rx_channels[] = {3, 23, 40, 61, 75, 83};

 und dem Re-transmit request bekomme ich bei mir jetzt ganz gut alle 15 
Sekunden ein komplettes Datenpaket zusammen. Meine Logik ist noch nicht 
ganz ausgereift, so dass ich im Moment nur ein fehlendes Paket neu 
anfordere, aber es gibt auch mal keine Antwort, oder nur eine.

Heute ist die Sonne wieder zu früh untergegangen, aber es sieht so aus, 
dass die Kanäle in einem festen Schema von oben nach unten gewechselt 
werden (da ich nicht weiß, was in den Nachrichten ist, habe ich die mal 
abgekürzt):

19:13:32.105 -> sending data request...
19:13:32.139 -> [03] 010... 
19:13:32.174 -> [75] 020... 
19:13:32.242 -> [75] 030... 
19:13:32.312 -> [61] 040... 
19:13:32.346 -> [61] 050...
19:13:32.379 -> [61] 060... 
19:13:32.446 -> [40] 070... 
19:13:32.482 -> [40] 080... 
19:13:32.550 -> [40] 090... 
19:13:32.586 -> [23] 0A0... 
19:13:32.656 -> [23] 0B0... 
19:13:32.694 -> [03] 8C0...

Wie man an den unterschiedlichen Abständen sehen kann, fehlt noch eine 
'korrekte' Synchronisation (im Moment mache ich das Timing basierend auf 
meinem Senden), aber es ist erstaunlich, wie gut das im Vergleich zu 
vorher zu funktionieren scheint.

[Lukas P. (lumapu)]

Version 0.2.9 ist da!

Changelog:
- added: IP Adresse wird auf Serieller Console ausgegeben, wenn 
erfolgreich mit WLAN verbunden
- fix: RF24 Konfiguration des Power Amplifiers
- added: RF24 Verbindung wird geprüft; prüft nur, ob SPI erreichbar, 
wenn kein Power an RF24 Modul ist, bleibt der ganze ESP hängen (ohne 
Serielle Ausgabe)
- added: MQTT port Konfiguration
- fix: offsets für HM400 und HM600 Wechselrichter, diese sollten jetzt 
korrekte Werte anzeigen. Bitte um Feedback
- added: Warnung, wenn die Konfiguration geändert wurde, ohne neu zu 
booten auf der index.html

Viel Spaß damit =)

[Lukas P. (lumapu)]

lpb schrieb:
> Ich habe versucht, die Zuverlässigkeit des Empfangs der
> Nachrichtenpakete zu verbessern.

Hallo lpb,

genial, dass du weiter auf diesem Gebiet forschst! Ich finde das super, 
dass sich so die Kompetenzen der einzelnen ergänzen.
Wenn man statisch auf Kanal 40 das 'Zeit-setzen' schickt und nur auf 
Kanal 3 horcht, bekommt man sehr unzuverlässig Pakete rein.

Verstehe ich das richtig, man sendet in Byte 10 eine 0x11 statt 0x0b und 
bekommmt dadurch viele neue Cmds in den Antworten.

das erinnert bisschen an das was @Hubi schon mal kurz angesprochen 
hatte:

Hubi (Gast) schrieb:
> Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal 
gelesen zu haben.

Auf eine Anfrage hin kommen dann viele Antworten und zuletzt ein 0x83? 
Wie bekommt man die Zuordnung von Kanal und CMD in der Antwort? Ich muss 
ja dann vorher wissen wo die nächste Antwort kommt.

Bin gespannt wie es hier weitergeht.

[Marcus (Gast)]

Die Werte für den HM-400 stimmen nun:

10:17:40.209 -> HM-400/ch1/U_DC: 41.200 V
10:17:40.209 -> HM-400/ch1/I_DC: 5.570 A
10:17:40.209 -> HM-400/ch1/P_DC: 229.400 W
10:17:40.209 -> HM-400/ch1/YieldTotal: 67.629 kW
10:17:40.209 -> HM-400/ch1/YieldDay: 0.315 Wh
10:17:40.209 -> HM-400/ch0/U_AC: 235.400 V
10:17:40.209 -> HM-400/ch0/Freq: 50.040 Hz
10:17:40.242 -> HM-400/ch0/P_AC: 218.200 W
10:17:40.242 -> HM-400/ch0/I_AC: 0.930 A
10:17:40.242 -> HM-400/ch0/Temp: 28.800 °

Ein paar Kleinigkeiten waren zu korrigieren (siehe app.cpp und 
hmInverters.h in
https://github.com/dad401/ahoy/tree/main/tools/esp8266)
- das h von kWh und das C von °C wird abgeschnitten => meine Änderungen 
scheinen da aber doch nicht zu helfen, bitte mal prüfen
- YieldDay korrigiert - es wird nun wie bei HM-600 Wattstunden angezeigt
(möchte nicht ständig im Thread das übermitteln - ich kann aber leider 
auch keinen zweiten Fork auf Lukas-Fork erstellen, daher PR auf das 
Haupt-Repo)

P.S. ggü. Hubis NRF24 Receiver empfängt die aktuelle Version aber 
irgendwie schlechter. Es dauert mehrere Minuten bis etwas ankommt - 
früher kamen Pakete sofort nach dem Start?!

[Lukas P. (lumapu)]

Hallo Marcus,
den PR hast du garnicht durchgeführt oder? Lt. dieser Anleitung solltest 
du den auch meinem Repo zuweisen können:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

Yield total sollte doch in kWh sein oder, daher war der Teiler 1000. In 
Wh ist es sehr bald eine unnötig große Zahl.

Bzgl. der Empfang: versuche mal in hmRadio.h den Channel-Hop (define) 
wieder zu aktivieren, evlt. geht es dann wieder besser.

[Marcus (Gast)]

Habe noch keinen PR gemacht, weil die Änderungen in der app.cpp nicht 
funktionieren. Ich teste das mal, ob ich Dein Repo hier verbinden kann - 
bin da zu unerfahren mit GIT da ich nur gelegentlich damit zu habe.

Yield total stimmt. Aber das h wird hinten bei der Ausgabe 
abgeschnitten.
Yield daily wird derzeit beim 400er in kWh ausgegeben, aber als Einheit 
ist Wh angezeigt - das habe ich korrigiert. Wenn Du aber eh 3 
Nachkommastellen ausgibst, könnte man YD auch generell auf kWh setzen. 
Ist aber alles Geschmackssache - Hauptsache einheitlich :-)

Ich probiere das mal mit dem Channelhopping. War das früher aktiv? Mit 
der ersten Version nach Behebung des Watchdog-Crashes ging es m.E. sehr 
gut. Jetzt dauert es 10min bis erste Pakete empfangen werden.

[Lukas P. (lumapu)]

Bei mir liegt es stark an der Ausrichtung der Antenne, sie muss bei mir 
mit der abstrahlenden Seite Richtung WR zeigen. Das ist bei mir noch 
sehr empfindlich, daher finde ich es super, dass sich hier auch welche 
um besseren Empfang kümmern.

[martin (Gast)]

lpb schrieb:
> Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8*
> Nachrichten das letzte Antwortpaket markieren

Hallo lpb,
diese Vermutung hatte ich auch schon, nachdem ich meine Messungen an der 
seriellen Schnittstelle hier gepostet hatte (siehe auch Bild):
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Aber die Erkenntnis mit dem Retransmit eines speziellen Pakets ist 
natürlich sehr nützlich.

Ich hatte hier im Thread schon mal darauf hingewiesen, dass es einen 
Unterschied in der Antwort des Wechselrichters macht, welche Anfrage 
vorausging. Das dürfte vielleicht die ein oder anderen "seltsamen" Werte 
bei manchen hier erklären. Die 0x80 0x11 Anfrage liefert andere 
Antwortpakete als die 0x80 0x0B Anfrage, obwohl sie den gleichen Index 
haben (siehe Bild).

Leider habe ich auch keine Ahnung, wie man das empfangene Paket 
plausibilisieren könnte. Evtl. lohnt es sich, das Channel Hopping 
systematischer zu untersuchen, um die komplette Antwortsequenz in einer 
gewissen Zeit zu erhalten.

Bald sind meine Module auf dem Dach montiert, dann kann ich auch wieder 
hier mitmischen...

[martin (Gast)]

martin schrieb:
> Evtl. lohnt es sich, das Channel Hopping
> systematischer zu untersuchen, um die komplette Antwortsequenz in einer
> gewissen Zeit zu erhalten.

Vielleicht ist die Messung von B.G. ja schon ein entscheidender Hinweis:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Es scheint eine Systematik in den Kanalwechseln zu geben, nämlich "von 
oben nach unten":
Kommt Paket 1 auf Kanal 40, dann wird auf 23 weitergehorcht. Kommt dort 
02,83 ist es Antwort auf 0x80 0x0B, kommt 02,03,04 wird auf Kanal 3 
weitergehorcht, bis 85 kommt. Dann ist es die Antwort auf 0x80 0x11 (?)

[Ziyat T. (toe_c)]

Hubi schrieb:
> Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert
> buf[10] von 00 bis FF durchlaufen lassen. etwa so:

Hallo Hubi
Danke für den Vorschlag, hatte auch mal so durchlaufen lassen wie du 
vorgeschlagen hast, ohne Erfolg.
Bisher habe ich alle Kombinationen MID/CMD/CID durchprobiert.
Ich denke die MI-Series braucht was ganz anderes, denn die Antworten 
sind auch ganz anders, bei den MI-Antworten gibts keine regelmaessige

SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc..

Ich muss die DTU-Pro sniffen aber, vorerst bin ich mit meinen 
Möglichkeiten am Ende.

Ehrlich gesagt ich kann es auch fast nicht glauben, dass die Chinesen 
für die HM'S vollig etwas anderes erfunden haben..

Andere Signalstaerken hab nicht probiert, es steht auf PA_MAX, hab einen 
NRF mit Antenne und WR ist etwa 7m weit, ich denke, was ich sende kommt 
an.

[martin (Gast)]

Ziyat T. schrieb:
> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc..

Achtung, das waren die seriellen Daten INNERHALB der DTU!
7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht 
zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den 
Adressen.

[Ziyat T. (toe_c)]

martin schrieb:
> Ziyat T. schrieb:
>> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc..
>
> Achtung, das waren die seriellen Daten INNERHALB der DTU!
> 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht
> zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den
> Adressen.

Sorry, richtig!

[Marcus (Gast)]

Ich habe Hubis Code ebenfalls mal eingecheckt. Hoffe es verwirrt nicht, 
denn es gibt noch einen weiteren Code unter "Nano" - der ist m.E. aber 
etwas anderes?!

[Mich@ (Gast)]

Hallo Leute,

Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der 
Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles 
perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er 
nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht 
mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein 
stärkeres Netzteil habe ich bereits getestet…

Ansonsten läuft die neue Version gut. Die Daten meines HM350 sehen 
plausibel aus. Auch die Abfrage per MQTT läuft.

[Lukas P. (lumapu)]

Ich habe gleiches beobachtet, habe einfach den USB Stecker vom Laptop in 
ein USB-Netzteil gesteckt und auch Abstürze gesehen, auch ca. 15-20 
Minuten geschätzt. Noch habe ich keine Idee woran es liegen könnte. MQTT 
war bei mir auch an.
Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann 
können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.

[Marcel A. (a-marcel)]

Hallo,

sagt mal, gibt es irgendeine Möglichkeit die Core Funktionen in eine 
Library auszugliedern?

Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch 
auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder 
andere NTP/WiFi implementierungen.

Das wäre wirklich von Vorteil ggf. für mehrere Personen.

Vielen Dank für all eure Arbeit

Marcel

[Lukas P. (lumapu)]

Hallo Marcel,

das ist doch im Prinzip jetzt schon so. Ich habe alles so angelegt, 
damit es möglichst unabhängig vom ESP8266 ist.
Im wesentlichen sind hierfür die Dateien 'hmSystem.h', 'hmRadio.h', 
'hmInverters.h' und 'CircularBuffer.h' notwendig. Evtl. ist noch das 
eine oder andere #define aus 'defines.h' nötig.

Die 'Library' wird dann ungefähr so aufgerufen (kopiert aus app.h):

typedef CircularBuffer<packet_t, PACKET_BUFFER_SIZE> BufferType;
typedef HmRadio<RF24_CE_PIN, RF24_CS_PIN, RF24_IRQ_PIN, BufferType> RadioType;
typedef HmSystem<RadioType, BufferType, MAX_NUM_INVERTERS, float> HmSystemType;

HmSystemType sys;

aus deiner .ino setup() musst du noch diese Routine aufrufen

sys.setup();

jetzt kannst du mit dem Objekt sys alles anstellen, z.B. einen Inverter 
hinzufügen:

sys.addInverter("HM_XY", 116100000000, 0);

danach muss man sich noch überlegen, was man alles in der loop() machen 
will, hierfür einfach in der app.cpp schauen.

[Marcel A. (a-marcel)]

Okay super. Schaue ich mir mal an. Danke.
Marcel

[Robert S. (Gast)]

Mich@ schrieb:
> Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der
> Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles
> perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er
> nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht
> mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein
> stärkeres Netzteil habe ich bereits getestet…

Ich habe hier einen Wemos D1 clone mit der 2.9er im Testbetrieb an einer 
Powerbank. Er läuft jetzt seit mehr als 3h 30min, das Webinterface ist 
erreichbar, die Zeit und Uptime zählen hoch.
Unterschied, er läuft ohne NRF-Board (wird erst geliefert) und bekommt 
daher auch keine Daten. Vielleicht hilft das ja bei der Fehlersuche.

SG
Robert

[isnoAhoy (Gast)]

Hallo Marcel,

schau Dir doch mal die folgenden beiden ebenfalls passenden SE&SO 
Artikel an:

[1] 
https://arduino.stackexchange.com/questions/76138/error-in-defining-ticker-in-esp32-library
[2] 
https://stackoverflow.com/questions/53091205/how-to-use-non-static-member-functions-as-callback-in-c

Ich habe versucht an der Stelle etwas Neues zu lernen, offenbar muß ich 
dazu auch noch Einiges mehr [TM] verstehen...
Das Beispiel im ersten u.a. Link fand ich dazu für mich etwas klarer, da 
es eine ESP8266 Vorlage und ein ESP32 Ergebnis gibt.

Die beiden Funktionen sendTicker und mqttTicker muss man m.E. in der 
app.h als public deklarieren.

static void appSendTicker_helper(app* appl) {
   //needs to be public!
   appl->sendTicker();
}

static void appMqttTicker_helper(app* appl) {
   //needs to be public!
   appl->mqttTicker();
}

...
    mSendTicker->attach_ms(interval, &appSendTicker_helper, this);
...
        mMqttTicker->attach_ms(interval, &appMqttTicker_helper, this);

Analog dazu sollte es auch in der main.cpp/.h möglich sein

Interessant fand ich, daß der Umbau für den ESP32 dann auch unter 
ESP8266 funktionieren soll.

Es sind also offenbar keine extra #if defined (ARDUINO_ARCH_ESP8266) 
#elif defined(ESP32) Blöcke für die Ticker notwendig.

Für die Bibliotheken die unter ESP8266 i.d.R. auch dies als Präfix haben 
und die ESP32 Varianten ohne dieses Präfix hast Du m.W. ja schon die 
entsprechenden konditionalen include's eingepflegt.

[Herbert K. (avr-herbi)]

Guten Morgen !
Ist schon jemand dahinter gekommen, was für eine Bedeutung die "81" er 
Telegramme vom HM350 / HM400 haben ?
005E ... 14 79 CF
005C ... 14 7F 25
0058 ... 14 72 F1

00 1234567801 005E 0B 3  95 [WR] [WR] 811479CF 1

00 1234567801 005C 0B 2  95 [WR] [WR] 81147F25 1

00 1234567801 0058 0B 0  95 [WR] [WR] 811472F1 1


00 1234567801 005E 0B 3  95 [WR] [WR] 811479CF 1

00 1234567801 005C 0B 2  95 [WR] [WR] 81147F25 1

00 1234567801 0058 0B 0  95 [WR] [WR] 811472F1 1

[Lars B. (docbmuc)]

Hi Lukas und alle dies es interessiert,

erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr 
gut lesbar.

Nach ersten Tests auf einem klassischen Arduino bin ich nun auf ein 
ESP8266 Modul umgestiegen.
Man braucht für den Code wirklich aktuelle Tools zum compileren, da wohl 
erst vor gar nicht langer Zeit die String-Conversion von uint64_t 
eingebaut wurde. Bei schickte das die Umsetzung der Seriennummern in 
eine Byte-Wurscht auf die Bretter... ;-)
Danach übersetzte das Ganze aber klaglos und lief auch auf Anhieb.

Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich 
musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom 
"Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC 
Leistung. Also habe ich Zeile
{ FLD_IAC, UNIT_A,   CH0, CMD02, 15, 2, 10   },
gegen
{ FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
getauscht. - Jetzt passt es.

Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
{ FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  },


=> Kann das bitte mal jemand mit einem HM600 checken, ob das beim HM600 
auch so ist? - Sonst müsste man die HM600/700 Werte defines 
separieren...

Die Visualisierung habe ich für mich noch auf die Schnelle um die 
AC-Werte erweitert. - Siehe Screenshot. :-)

Ein Issue habe ich noch:
=> Ich habe ab und zu (gemittelt alle 10-20 Minuten) Stacktraces, also 
Abstürze mit Exception 0. Meist im Zusammenhang mit der ISR für den 
externen Interrupt und gleichzeitigem Bedienen des WLAN-TX.
=> Das Modul startet dann korrekt neu, bekommt aber keine IP-Adresse 
zugewiesen (IP unset). Ein Reset behebt das aber (temporär).

Ich beobachte das weiter und prüfe heute noch, ob es ein HW-Thema 
(Spannungseinbrüche o.ä.) ist oder eher nicht.

Cheers,
Lars

[Hubi (Gast)]

Hallo zusammen
Im Anhang meine neueste Version, da ich gesehen habe, dass doch einige 
diese ausprobieren.
Kommentare dazu:
- Projekt jetzt umgenannt in HoyDtuSim (Hoymiles DTU Simulation)
-Läuft auf Arduino (bei mir auf Pro Mini) und ESP (Wemos D1 mini), je 
nachdem wie man kompiliert
- Channel hopping für senden und Empfangen (poor man's ...) ist 
eingebaut und bringt konstante Antworten; obige Erkenntnisse über Kanäle 
abwärts sind noch nicht eingebaut
- da manchmal ein Abbruch der RF-Verbindung vorkam (auch schon oben 
erwähnt)  wird jetzt nach ca 50 Sekunden ohne Empfang das RF-Modul neu 
initialisiert und es geht problemlos weiter
- Definitionen für HM-600 und HM-1200 sind implementiert, andere können 
anhand der beiden Beispiele sicher leicht impl. werden
- Anpassungen sind in der Settings.h zu machen

Marcus hat in das lumapu-Repo meine Version vom 13.04. eingecheckt. Wäre 
nett wenn er dies durch diese hier ersetzen würde.
Wenn ich Zugang zu diesem Branch hätte und wenn ich wüßte wie das geht 
würde ich das auch selbst machen. Aber ich kann neue Versionen auch an 
Lukas P. (lumapu) per Mail schicken.

@Herbert: Die 81er habe ich auch dauernd, besonders 8114. Fehlermeldung?

[Sorbit (Gast)]

Beim compilieren mit der aktuelle IDE und aktuellen Bibliotheken kommt 
folgende Fehlermeldung:

app.cpp:58:95: error: call of overloaded 'String(uint64_t&, int)' is 
ambiguous

Liegt das an der fehlenden Seriennummer die ich noch nicht eingetragen 
habe, weil ich nicht weiß wo?

Sorry für die Anfängerfragen.

Danke

[Hubi (Gast)]

Hallo Sorbit
für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das 
aber keinen Fehler werfen.
 Wenn du die Serial ausgeben willst, kannst du das so machen

  sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned long)(serial&0xFFFFFFFFULL));

[Marcus (Gast)]

Marcel A. schrieb:
> Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch
> auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder
> andere NTP/WiFi implementierungen.

Ich bastel gerade an einer Testversion für Tasmota - muss mir aber immer 
recht viel zusammensuchen, da ich nicht so tief drin stecke im 
Programmieren wie z.B. Lukas. Die Integration kompiliert inzwischen - 
einiges musste ich anpassen, konnte aber viele der Dateien von Lukas 
weiterverwenden. Ob es auch läuft konnte ich noch nicht testen.
Kann das gerne in mein GIT einstellen 
([[https://github.com/dad401/Tasmota]] Tasmota-Fork) - ist aber sicher 
noch nicht so toll der Code. Learning by Doing auch was GIT betrifft.

@all:

Wie plausibel haltet ihr die Werte für P_AC und Power total/daily => 
sind das die Werte, welcher ein Wechselstromzähler messen sollte oder 
könnte das ggf. doch (tlw.) Werte für DC sein? Wenn das passt, dann kann 
man damit auch z.B. einen SonOff besser kalibrieren. Dieser weicht 
derzeit nur wenige kWh von der Tagesproduktion ab.

[Marcus (Gast)]

Lukas P. schrieb:
> Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann
> können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.

Ich glaube Du musst da "Discussions" in den "Settings" anwählen - in 
Deinem GIT habe ich irgendwie (ohne PR) keine Möglichkeit gefunden zum 
Austausch.

[Marcus (Gast)]

Hubi schrieb:
> Wäre
> nett wenn er dies durch diese hier ersetzen würde.

Ist bei mir drin und PR für das Hauptrepo angefordert.
Mit einen GIT Account könntest Du das auch selbst. Ich kann Dir die 
Schritte, wenn Du den Account hast gerne sagen (so wie ich es 
mache/gelesen habe). Am besten aber dann hier [[Du bräuchtest einen git 
Account]] sonst sprengen wir die Server von mikrokontroller.net ;-)

[Marcus (Gast)]

Marcus schrieb:
> Am besten aber dann hier [[Du bräuchtest einen git
> Account]]

[[https://github.com/dad401/ahoy/discussions]]

[Hubi (Gast)]

So, ich habe mir einen Git account zugelegt und meine SW dort mal 
reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation.
Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt 
geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, 
bitte gerne.

[Marcus (Gast)]

Hubi schrieb:
> So, ich habe mir einen Git account zugelegt und meine SW dort mal
> reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation.
> Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt
> geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will,
> bitte gerne.

Das ist nun die Frage - belassen wir alles im Haupt-Repo 
[[https://github.com/grindylow/ahoy]] oder führt jeder Entwickler sein 
eigenes? Ich kann diese Frage nicht beantworten.

Man könnte es ja so machen:
Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software 
lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas).

Aber das müsst ihr wissen. Mir wird nur etwas schwindlig wenn man immer 
alles zwischen den Forks synct ;)
Für mich wäre es einfacher wenn ich als Nutzer Hubis-Repo und Lukas-Repo 
bei mir forken kann und dort Änderungen per PR einbringen kann. Derzeit 
ist das irgendwie über zwei Ecken. <just my 2 cents>

Marcus

[Lukas P. (lumapu)]

Hallo Marcus,

wir sollten bei dem Hauptrepository bleiben, aber evtl. kannst du mich 
als 'Colloborator' hinzufügen, dann kann ich direkt die Pull-Request 
managen - denke ich (ich hab leider auch keine Github Erfahrung)

Repository -> Settings -> Colloborators

[Hubi (Gast)]

Hallo Lukas
Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie 
bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann 
meine weitere Entwicklung per Mail zukommen lassen. Bin auch der 
Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und 
wird dann unübersichtlich. Bin da offen. Deine wirklich sehr gute OOP 
Entwicklung wäre schon wert unterstützt zu werden.

[Sorbit (Gast)]

Hubi schrieb:
> Hallo Sorbit
> für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das
> aber keinen Fehler werfen.
>  Wenn du die Serial ausgeben willst, kannst du das so machen1
> sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned
> long)(serial&0xFFFFFFFFULL));

Hallo Ahoi, Hubi, oder wer auch immer dahinter steckt😄

Im Git Repository steht doch geschrieben, das der Code für Arduino mit 
ESP8266 als Taget gedacht ist.
Dann sollte der Compiler doch sauber durchlaufen.
Ich verstehe den Zusammenhang nicht.
Kann mir jemand auf die Sprünge helfen?

Danke

[Martin G. (petersilie)]

Ich lade gerne "Collaborators" in das AHOY Repository ein.

Schreibt doch hier im Thread kurz Eure Github-Namen und Euren 
Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als 
Collaborators hinzu.

Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich 
hier im Forum in der Minderheit!), aber ich stimme Marcus und den 
anderen zu, dass es insbesondere für Nutzer hilfreich ist, wenn die 
Entwicklung nicht an zu vielen unterschiedlichen Forks läuft.

Gruß

Martin (petersilie) / https://github.com/grindylow/ahoy


ps.
Habe gerade mal das Haupt-README mit direkten Verweisen auf die 
Unterprojekte aktualisiert. Für die Übersicht wäre es super, wenn jeder 
Autor für "sein" Tool ein kleines README hinzufügen könnte. Dann finden 
sich auch Fremde schnell zurecht. Als Beispiel/Vorlage kann z.B. 
https://github.com/grindylow/ahoy/tree/main/tools/rpi dienen.

[Petra R. (petra-kathi)]

Hallo Martin,

> Mein Interesse ist immer noch eher auf der Raspi-Version

Schön! Ich halte zumindest davon auch noch am meisten, was das effektive 
Entwickeln angeht, wenn auch der Ressourceneinsatz etwa bei einem ESP32 
deutlichst kleiner ausfällt, wenn er dann einmal als Webserver läuft.

Übrigens habe ich heute meinen NRF24_Sniffer zugeschickt bekommen und 
werde wohl in den nächsten Tagen das Dingens mal aktivieren. Wenn's dann 
klappt, hoffe ich, was zum HM-1500 beitragen zu können. Wobei ich hoffe, 
weitestgehend die Auslesung des HM-1200 übernehmen zu können.   ;-)

Tschüssi,
Petra

[Hubi (Gast)]

Hallo Sorbit
mit der Arduino IDE und Einstellung Lolin(Wemos) D1 R2 & mini lässt sich 
zB ein

Serial.println(String(serialNr,HEX))

ohne Fehler kompilieren. Ich benutze die IDE 1.8.13, nicht die neueste.

[Heinz R. (heijz)]

Martin G. schrieb:
> Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich
> hier im Forum in der Minderheit!),

welche Vorteile versprichst Du Dir davon?
Denke man sollte es möglichst einfach halten - und möglichst einfach ist 
halt der ESP8266

[andreas5232 (Gast)]

Nachdem ich bisher nur stiller Mitleser war, hier mein erster Beitrag. 
Sehr cool, was ihr hier schon gemeinsam geschafft habt! :-)

Heinz R. schrieb:
> welche Vorteile versprichst Du Dir davon?
> Denke man sollte es möglichst einfach halten - und möglichst einfach ist
> halt der ESP8266

Der ESP ist sicherlich ein guter Start, universell und aus meiner Sicht 
eine schöne Plattform. Ich persönlich würde es auf Dauer aber auch 
bevorzugen, wenn das System auf einem bestehenden Raspberry 
untergebracht werden könnte und ich keine zusätzliche Hardware dafür 
laufen lassen muss.

Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display 
zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell 
ablesbar zu machen.

[Martin G. (petersilie)]

Heinz R. schrieb:
> welche Vorteile versprichst Du Dir davon?
> Denke man sollte es möglichst einfach halten - und möglichst einfach ist
> halt der ESP8266

Der ESP8266/ESP32 ist sicher eine tolle Sache. Ich habe persönlich nicht 
primär das Nachbauen einer "DTU" im Kopf, sondern die Integration der 
Hoymiles-Wechselrichter in ein größeres Ökosystem.

Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man 
durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den 
Wechselrichtern einfach noch mitmachen lassen. Webinterface/Archivierung 
etc ist dann nicht Aufgabe der Hoymiles-Anbindung, sondern des 
übergeordneten Systems. Vielleicht ein bisschen wie die 
"DTU-Pro"-Anbindung via Modbus (wobei die DTU-Pro ja wohl auch ein 
Webinterface etc etc bietet).

Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier 
eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit 
NRF24 als auch mit Wifi auf 2.4 GHz.

Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" 
experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf.

Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. 
Das sind alles absolut gute Wege, und jede Alternative trägt ein 
bisschen zum Erkenntnisgewinn bei. Ich finde es prima, wie wir alle 
unsere Erfahrungen mit dem Protokoll zusammensammeln!

[Petra R. (petra-kathi)]

> Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display
> zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell
> ablesbar zu machen.

Jenau, man schaue z.B. unter 
https://tutorials-raspberrypi.de/esp8266-grafikdisplay-ssd1306-oled-bilder-text-anzeigen/

Wobei ich eher zum esp32 tendiere, weil der wohl bei minimalem Aufpreis 
etwas besser ausgestattet ist?

Tschüssi,
Petra

[Petra R. (petra-kathi)]

> Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier
> eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit
> NRF24 als auch mit Wifi auf 2.4 GHz.

Scho'recht, allerdings ist die Frage, wie stark die Hoymiles-Abfragerei 
das WLAN belastet. Ich möchte auch mal hinterfragen, ob es einen Sinn 
macht, sekündlich Werte abzufragen? Ich denke, wenn man alle 30 s 
einen Wertesatz holt, wird sich die Statistik nur sehr unwesentlich 
verschlechtern.

> Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv"
> experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf.

Das auf jeden Fall - das ist auch bei mir der Antrieb, damit anzufangen, 
um ...

> Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen.

... später, wenn alles so weit ausexperimentiert ist und nur noch 
gelegentlich mal nach dem Zustand geschaut wird, so was als 
Standardanzeige zu etablieren.

Zumindest fände ich es nett, hier eine Low-Power-Alternative zur 
Verfügung zu haben.  ;-)

Tschüssi,
Petra

[Marcus (Gast)]

Lukas P. schrieb:
> aber evtl. kannst du mich
> als 'Colloborator' hinzufügen

Das wäre dann aber petersilie - das Hauptrepo ist seins, hat er aber 
darunter bereits geschrieben:

Martin G schrieb:
> Ich lade gerne "Collaborators" in das AHOY Repository ein.
> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren
> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als
> Collaborators hinzu.

Mein GIT: [[https://github.com/dad401]]

Fokus: Nutzertests mit HM-400 (und HM-300), ggf. 
Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste 
Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht 
commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren 
Programmierkenntnissen beteiligt.

Martin G schrieb:
> Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man
> durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den
> Wechselrichtern einfach noch mitmachen lassen.

Ich finde es gut, dass es auch diese Alternative gibt, denn auch ich 
würde mir ggf. ein zusätzliches Gerät sparen. Ich habe inzw. alles 
kompiliert/konfiguriert, aber bekomme es noch nicht zum Laufen. Benötige 
ich da zwingend den MQTT-Server? Ich muss das nochmal genauer prüfen.
Einzig nachteilig (IMHO) ist leider das "Gefummel" (kompilieren statt 
einfach per apt installieren) mit den Bibliotheken. Solang das alles 
fehlerfrei klappt ist gut, aber wer weiß was mit dem nächsten RPi-Update 
passiert.

Petra R. schrieb:
> Ich möchte auch mal hinterfragen, ob es einen Sinn
> macht, sekündlich Werte abzufragen?

Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools 
berücksichtigt werden. Ich denke dies ist immer noch des ersten 
funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer 
stabil kommen. Ggf. macht man das Abfrageinterval einstellbar. Meine 
RRD-Datenbank befülle ich (von einem SonOff Pow R2) jede Minute. Wenn 
also stabil bei einer Abfrage eine Antwort kommt, dann reichen sicher 
30s Intervall aus.

[Ziyat T. (toe_c)]

Marcus schrieb:
> Hubi schrieb:

> Man könnte es ja so machen:
> Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software
> lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas).
>
Diesen Weg sollten wir gehen, denn es gibt noch viele ungelöste Dinge!
IMHO, es sollten unbedingt alle Infos Zentral sein.

Ich habe das Gefühl, dass bisher "nur" ein Paar WR Daten (und diese nur 
von HM's!) sichtbar sind, und schon wird hier über HW-Plattform 
diskutiert;-)

[Marcus (Gast)]

Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die 
Dokumente.

Hier eine weitere HM-300 Seriennummer:
11216281xxyy

Also ich leg mich fest, die HM-3xx und HM-400er beginnen mit immer 1121 
;)

[st_b (Gast)]

Vorweg: Super Arbeit - vielen Dank!

Die ESP8266 Version funktioniert mit einem HM-800 (114174...) 
Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc 
erwähnten Installation der Library "PubSubClient"):

    { FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
    { FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  }

In der kurzen Testphase kam es zu Hängern - ich vermute einen 
Zusammenhang mit geöffnetem Webinterface.

lg

[Lukas P. (lumapu)]

st_b schrieb:
> Die ESP8266 Version funktioniert mit einem HM-800 (114174...)
> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc
> erwähnten Installation der Library "PubSubClient"):

Hallo st_b ,
auf welcher Definition basiert deine Änderung, auf der vom HM600?
Doku werde ich nachziehen, danke für den Hinweis.

[Lukas P. (lumapu)]

Hubi schrieb:
> Hallo Lukas
> Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie
> bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann
> meine weitere Entwicklung per Mail zukommen lassen. Bin auch der
> Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und
> wird dann unübersichtlich. Bin da offen.

Hallo Hubi,
das liegt bei dir, ich finde es nicht falsch wenn du einen Git Account 
hast und direkt Änderungen per pull request einfließen lässt. Per Mail 
geht auch, dann checke ich es ein.

Deine wirklich sehr gute OOP
> Entwicklung wäre schon wert unterstützt zu werden.


Vielen Dank für die Blumen ;-)

[Lukas P. (lumapu)]

Lars B. schrieb:
> erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr
> gut lesbar.

Das ist mein Ziel: so wenig wie möglich kommentieren, lieber sprechen 
Code schreiben. Ist nicht immer ganz einfach, aber so bleibt das gesamte 
auch über Monate wartbar.

> Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich
> musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom
> "Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC
> Leistung. Also habe ich Zeile
> { FLD_IAC, UNIT_A,   CH0, CMD02, 15, 2, 10   },
> gegen
> { FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
> getauscht. - Jetzt passt es.
>
> Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
> { FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  },

Ich kann leider nicht nachvollziehen, ob diese Änderungen bereits per PR 
in das repo gekommen sind, falls nicht bitte noch anlegen.

> Die Visualisierung habe ich für mich noch auf die Schnelle um die
> AC-Werte erweitert. - Siehe Screenshot. :-)

Auch hier freue ich mich über einen PR in Git.

[st_b (Gast)]

Lukas P. schrieb:
> st_b schrieb:
>> Die ESP8266 Version funktioniert mit einem HM-800 (114174...)
>> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc
>> erwähnten Installation der Library "PubSubClient"):
>
> Hallo st_b ,
> auf welcher Definition basiert deine Änderung, auf der vom HM600?
> Doku werde ich nachziehen, danke für den Hinweis.

Ich habe die Definition des HM-600 angepasst. Vollständigkeitshalber sei 
erwähnt, dass die Werte ursprünglich von Lars B. stammen)

const byteAssign_t hm800assignment[] = {
    { FLD_UDC, UNIT_V,   CH1, CMD01,  3, 2, 10   },
    { FLD_IDC, UNIT_A,   CH1, CMD01,  5, 2, 100  },
    { FLD_PDC, UNIT_W,   CH1, CMD01,  7, 2, 10   },
    { FLD_UDC, UNIT_V,   CH2, CMD01,  9, 2, 10   },
    { FLD_IDC, UNIT_A,   CH2, CMD01, 11, 2, 100  },
    { FLD_PDC, UNIT_W,   CH2, CMD01, 13, 2, 10   },
    { FLD_YW,  UNIT_WH,  CH0, CMD02,  1, 2, 1    },
    { FLD_YT,  UNIT_KWH, CH0, CMD02,  3, 4, 1000 },
    { FLD_YD,  UNIT_WH,  CH1, CMD02,  7, 2, 1    },
    { FLD_YD,  UNIT_WH,  CH2, CMD02,  9, 2, 1    },
    { FLD_UAC, UNIT_V,   CH0, CMD02, 11, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH0, CMD02, 13, 2, 100  },
    { FLD_PAC, UNIT_W,   CH0, CMD02, 15, 2, 10   },
    { FLD_IAC, UNIT_A,   CH0, CMD83,  3, 2, 100  },
    { FLD_T,   UNIT_C,   CH0, CMD83,  7, 2, 10   }
};
#define HM800_LIST_LEN     (sizeof(hm800assignment) / sizeof(byteAssign_t))

[isnoAhoy (Gast)]

Hallo Marcus,

> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.

ich habe die Statistik der Seriennummern noch einmal sauber aufgeräumt 
und nach Seriennummer sortiert.
Wenn Ihr wollt, könnt Ihr die gerne einchecken, ich habe die auch nur 
weitergeführt.

Ich habe jetzt auch die Usernamen aus dem Forum ergänzt um zu sehen, von 
wem evtl. noch eine führende Ziffer zu bekommen wäre:

Arnaldo G. (arnaldo_g), martin (Gast), Oliver F. (of22), heijz, Carsten 
B. (carstenb) könntet Ihr eventuell hier im Forum oder direkt in der 
Tabelle Eure führenden Ziffern bzw. die Serien-/Modellnummer Eures 
Wechselrichters / DTU Modells ergänzen ?

Auch die ForistInnen mit einem MI- Wechselrichter der älteren Bauart 
müssten ggf. Ihre Seriennummern beisteuern, da hiervon außer dem TSUN 
TSOL-M800 von Daniel M. (Gast) noch keine hier bekanntgegeben wurde.

[isnoAhoy (Gast)]

Hier eine auf die ersten vier Stellen gekürzte Liste aus dem Excel,
das ich letzte Woche aktualisiert habe:

Name      | Serien
--------- | ------
MI-250    | 1020
MI-300    | 1021
MI-?      | 1022
MI-500    | 1040
TSOL-M800 | 1041
MI-1000   | 1060
MI-1200   | 1061
MI-1500   | 1061
MI-?      | 1062
HM-300    | 1121
HM-350    | 1121
HM-400    | 1121
HM-600    | 1141
HM-700    | 1141
HM-800    | 1141
HM-1200   | 1161
HM-1500   | 1161
DTU-G100  | 10D2
DTU-W100  | 10D3
DTU-Pro   | 10F7
DTU-Pro   | 10F8

Wie man sehen kann sind die Seriennummern nicht ganz eindeutig.
Aber es sollte von der Zahl der Anschlüsse bzw. MPPT die im 
Wechselrichter verbaut sind
eigentlich hinkommen, daß alle mit der selben Seriennummer zumindest 
einen ähnlichen
inneren Aufbau haben sollten.
Lediglich die maximale Leistung der Kanäle scheint sie noch zu 
unterscheiden.
Ich habe auch mal die Seriennummern der DTUs und unseres Exoten TSUN 
"TSOL-M800" aufgenommen.

[Martin G. (petersilie)]

Marcus schrieb:
>> Ich lade gerne "Collaborators" in das AHOY Repository ein.
>> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren
>> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als
>> Collaborators hinzu.
>
> Mein GIT: [[https://github.com/dad401]]
>
> Fokus: Nutzertests mit HM-400 (und HM-300), ggf.
> Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste
> Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht
> commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren
> Programmierkenntnissen beteiligt.

Einladung ist erfolgt!

> Man könnte es ja so machen:
> Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software
> lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas).

Das könnten wir auch gerne so halten. Ich habe leider ein bisschen den 
Überblick verloren, wer an welchem Teilprojekt in welcher Repo am 
aktivsten ist.

Gerne kann ich in der Haupt-Repo im README auf die jeweiligen anderen 
Repos verweisen, und dann im Laufe der Zeit auch die (dann veralteten) 
Unterverzeichnisse entfernen. Am besten würde ich dann auch die 
jeweiligen Autoren mit auflisten, oder?

Persönlich fände ich es gut, wenn wir die Doku 
(https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) 
im Hauptrepo (https://github.com/grindylow/ahoy) pflegen würden. Die 
können wir dann gerne auch versuchen, auszubauen und evtl. auf 
readthedocs.io o.ä. zu hosten. Mir fehlt nur gerade ein bisschen die 
Zeit - aber über die nächsten Wochen wird sich schon wieder Zeit 
finden...

[Martin G. (petersilie)]

isnoAhoy schrieb:
>> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.

Habe die aktuelle von @isnoAhoy zusammengestellte Liste jetzt zumindest 
mal dem Repo hinzugefügt: 
https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx

Ja, die Erkenntnisse daraus sollte ich (?) dann mal in die Haupt-Doku 
(https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) 
einfließen lassen...

[Martin G. (petersilie)]

Marcus schrieb:
> Petra R. schrieb:
>> Ich möchte auch mal hinterfragen, ob es einen Sinn
>> macht, sekündlich Werte abzufragen?
>
> Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools
> berücksichtigt werden. Ich denke dies ist immer noch des ersten
> funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer
> stabil kommen.

In manchen Programmen war/ist auch immernoch das "AutoACK" 
eingeschaltet. Das geht in die selbe Richtung: da wir schlüssig 
nachgewiesen haben, dass die WR kein AutoACK machen, bedeutet das 
faktisch, dass unsere Programme das jeweilige Paket mehrfach (ich meine 
15-fach) hintereinander aussenden. Das führt vermutlich zu 
"verlässlicherer" Kommunikation, flutet aber natürlich "unnötigerweise" 
das 2.4 GHz Band. Die bisherigen Erfahrungen zeigen, dass das eine DTU 
auf jeden Fall nicht ganz so "extrem" macht, und trotzdem "verlässlich" 
kommuniziert.

Langer Rede kurzer Sinn: später muss

* das AutoACK ausgeschaltet und
* das Poll-Intervall auf einen "sinnvollen" Wert (15s, 30s, evtl. noch 
langsamer)

...eingestellt werden.

[Robert Bleumer (Gast)]

HM1500 funktioniert hier auch mit ESP8266 und NFR24L01+ und die letzte

Seriennummer meine 1500 fangt auch mit 1161 an.

Steht upload nach PvOutput.org noch auf's Programm?

[Thomas B. (tbnobody)]

Hallo zusammen,

Jan (HM-600) und ich (HM-1500) haben gerade den ESP8266 und Python Code, 
die Byte Assignments usw. für beide Wechselrichter angeschaut.

Dadurch sind wir auf folgende Erkenntnisse / Theorien gekommen:
* Beim HM-600 macht der Weekly Counter keinen Sinn (bei Jan ist dieser 
höher als der vermeintliche Total)
* Der HM-1500 hat Total Spalten für jeden seiner 4 Eingänge
* Wenn der HM-600 der gleichen Struktur folgt, müsste dieser 2 Total 
Werte haben.
* Diese beiden Werte müssten jedoch 4 Byte haben
* Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 
keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht
* Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1)

Folgende Überlegungen:
Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen 
Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet.

Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert 
übergelaufen?
Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null 
sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4


Unabhängig davon haben wir einen Pull Request für AC I und P mit einem 
HM-600 erstellt:
https://github.com/grindylow/ahoy/pull/21

[Marcel A. (a-marcel)]

Guten morgen,

der Code von ahoy läuft jetzt auf meinem ESP32. Vielen Dank dafür. Ich 
habe einen HM400 und mir mal die Daten angeschaut und dazu mal eine 
Frage.

Es scheint ja ch0 und ch1 zu geben ? Ich gehe mal davon aus, das diese 
channel die MPPT Channels sind - stimmt das ? Wenn ja, dann wäre das für 
den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem 
Anschluss hat.

Was war denn der Plan hinter diesen Channel ? Ich kann es für den HM400 
ändern, sobald ich weiß wie das Konzept ist.

HM_400/ch1/U_DC: 38.000
HM_400/ch1/I_DC: 3.260
HM_400/ch1/P_DC: 123.700
HM_400/ch1/YieldTotal: 39.363
HM_400/ch1/YieldDay: 183.000
HM_400/ch0/U_AC: 229.400
HM_400/ch0/Freq: 50.030
HM_400/ch0/P_AC: 120.600
HM_400/ch0/I_AC: 0.530
HM_400/ch0/Temp: 30.100

Danke Marcel

[Marcel A. (a-marcel)]

Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das 
Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz 
abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra 
Steckdose brauchen würde.

Marcel

[Thomas B. (tbnobody)]

Hallo Marcel,

> Was war denn der Plan hinter diesen Channel ?

Channel 0 stellt Parameter dar die keinem direkten Input auf der DC 
Seite zugeordnet werden können (also z.B. AC Strom der AC Spannung). Da 
es beim HM-400 nur einen Eingang gibt, gibt es neben dem CH0 auch nur 
einen weiteren Kanal (CH1) welcher die DC Seite darstellt.

> Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das 
Einspeisen?
Nachdem es diesen Wert sowohl für den HM-600 (und kompatible) sowie für 
den HM-1500 (und kompatible wie HM-1200) gibt, würde ich vermuten das 
dieser auch für die Einkanal Geräte existiert. Es wurde wohl nur noch 
nicht herausgefunden welcher Wert dem entspricht.

[Sorbit (Gast)]

Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen 
ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?

Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert.
Meine Skills reichen nicht aus um die Fehler selbst zu beheben.

Wo stelle ich HM1200 und die Seriennummer ein?

[isnoAhoy (Gast)]

> Es scheint ja ch0 und ch1 zu geben ?
Richtig, CH0 dürfte allegemeiner Natur sein, sowas wie AC Seite des 
Wechselrichters und evtl. Temperatur.

> Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das?
Nicht ganz CH1..4 sind die MPPT Channel.

> Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT 
mit nur einem Anschluss hat.

In der Hoymiles Dokumentation bzw. der App zur Hoymiles DTU-Lite-S heißt 
CH0 auch "Output grid port" und die anderen Kanäle CH1 .. CH4 "Input 
port1..4".

Ich habe gestern noch ein wenig in den offiziellen Dokus gelesen und 
dabei habe ich noch eine Menge DTU und WR Seriennummern gefunden. Ich 
werde diese die Tage evtl. mal noch im Seriennummern XLSX nachtragen.

[isnoAhoy (Gast)]

Hallo Thomas B. und Jan,

> * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2
> keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht
> * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1)
Ich glaube die Vermutung hatten wir auch schon weiter oben auf Seite 4. 
Aber ich habe gerade keine Referenz. Vielleicht war das auch nur ein 
Gedanke als es sich herausgestellt hat, daß die Yield Total Werte in kWh 
ja vier Byte belegen.

> Folgende Überlegungen:
> Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen
> Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet.

Das wäre in der Tat sinnvoll, da die einzelnen Telegramme ja über den 
Rahmen jeweils mit einem CRC8 und ggf. CRC_M/16 (Modbus) gecheckt werden 
können. Vielleicht gibt es am Ende (0x8x Telegramm) ja auch noch eine 
weitere Prüfsumme ?

> Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert
übergelaufen?

Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die 
dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn 
diese Telegramme wie bisher immer einzeln verarbeitet werden.
@Lukas P. bei den HM-1000/1200/1500 habt ihr ja alle vier Byte in einem 
Telegramm. Für die HM-600/700/800 bräuchten wir in der Tat so einen 
Übertrag oder eine Kombination aller Teilinformationen der Telegramme um 
die ganze Nachricht zu parsen.

> Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null
> sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4

Wie gesagt das hatte ich auch angenommen, weiß jetzt aber nicht ob 
wirklich jemand seinen HM-600/700/800 schon zum "Überlauf" in das erste 
Telegramm gebracht hat. Dauert ja logischerweise auch doppelt so lange 
wie bei den größeren HM-1000/1200/1500 =^D
Meiner wartet noch auf die Montage der Solarpanele bevor er richtig 
einspeißen darf.

[isnoAhoy (Gast)]

> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?
>
> Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert.
> Meine Skills reichen nicht aus um die Fehler selbst zu beheben.
>
> Wo stelle ich HM1200 und die Seriennummer ein?

Hallo Sorbit, schau mal auf der Anleitung nach:
https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den 
ESP8266 zu kompilieren. Prüfe mal folgendes:
* Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support 
herunterladen)
* die beiden RF24 und TimeLib Bibliotheken im Library Manager 
installieren.
@Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der 
ESP8266 Boards Umgebung ?

Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem 
o.g. Github aufmachen, damit wir die Dokumentation erweitern und die 
Schritte die Dir fehlen nachreichen ?

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

[Lukas P. (lumapu)]

isnoAhoy schrieb:
> brauchen wir auch die Ticker Bibliothek oder ist die Teil der
> ESP8266 Boards Umgebung ?

Ich denke nicht, da diese direkt von der ESP8266 Bibliothek mitgeliefert 
wird. (Hier wird sich in naher Zukunft auch noch was ändern, ich 
diskutiere hier gerade mit stefan123t auf Github.)

Sorbit schrieb:
> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?

Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier 
angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP 
auf die /setup Seite gehen und dort alles konfigurieren.

Marcel A. schrieb:
> Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das
> Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz
> abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra
> Steckdose brauchen würde.

Das Yield Total ist doch genau das Feld. In der neuen Version sind auch 
Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, 
dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 
habe ich mal 4 beispielhafte Berechnungen definiert)

[Thomas B. (tbnobody)]

isnoAhoy schrieb:
> Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die
> dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn
> diese Telegramme wie bisher immer einzeln verarbeitet werden.

Die Schwierigkeit wäre dann auch noch, wenn es wenn es zu Paketverlusten 
beim Überlauf kommt. Also wenn man z.B. beim HM-600 bleibt und der Total 
Wert wirklich über zwei Telegramme verteilt ist könnte es ja zu 
folgendem Szenario kommen:

* Anfrage senden
* Antwort Paket ID 1 geht verloren
* Antwort Paket ID 2 kommt durch und der Total Wert steht bei 0xFF 
0xFF...
* Paket ID 1 wird erneut angefordert
* Jetzt gab es den überlauf, die letzten beiden Bytes in Paket 1 sind 
0x00 und 0x01.
* Sollte man jetzt beide Pakete einfach zusammensetzen hätte man ja 0x00 
0x01 0xFF 0xFF
* In Wirklichkeit sollte es aber 0x00 0x01 0x00 0x00 sein
* Man müsste also auch Paket 2 neu anfordern

[Marcel A. (a-marcel)]

Hallo,

Lukas P. schrieb:
> Das Yield Total ist doch genau das Feld. In der neuen Version sind auch
> Berechnungen möglich, die werden auch in der hmDefines.h eingetragen,
> dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200
> habe ich mal 4 beispielhafte Berechnungen definiert)

Da würde ich nicht mitgehen. Das was ich gemessen habe, entspricht nicht 
dem Yield Total. Es weicht 1% ab. Ich würde sagen, das YieldTotal eben 
die Gesamtenergie der SolarPanele ist. Laut Datenblatt haben die 
Hoymiles auch einen Wirkungsgrad in dem Bereich - 99%.

Rechnen bringt mir leider nicht viel, da ich einen totalen Wert (immer 
steigend) brauch (auch nach einem Neustart). Was man simulieren könnte, 
wäre das ich 1% vom Yield Total abziehe und diesen Wert dann als AC 
Energy Total nutze.

Anbei ein Screenshot wo man den Unterschied zwischen AC und DC sieht.

Marcel

[IsnoAhoy (Gast)]

Hallo Thomas B.,
ja das ist noch ein zusätzliches Grund. Ich dachte nur daran was es für 
Werte mit den niederwertigen Daten aus Paket 2 ohne die höherwertigen 
Daten aus Paket 1 ergibt, bzw. wie man diese zwischenspeichert bis das 
zweite Paket auch da ist.
In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, 
[0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn 
alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind.

@Lukas P. da könnte der Link zur State-Machine vielleicht nochmal 
hilfreich sein:
https://hackaday.com/2015/09/04/embed-with-elliot-practical-state-machines/

[Lukas P. (lumapu)]

IsnoAhoy schrieb:
> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …,
> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn
> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind.

Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben 
hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. 
geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) 
oder einen Gesamt-CRC.

Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu 
anderen Messeinrichtungen? Ich messe mit einem selbst programmierten 
Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung.
Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh 
gemessen hat. Das enspricht einer Abweichung von ca. 4%.
Wenn ich die aktuelle Leistung vergleiche, dann sind beide Messungen bis 
100W nahezu identisch, bei 1000W habe ich schon eine Abweichung von 
knapp 100W.

Danke für den State-Machine Link - sehr schön beschrieben. Ungefähr bei 
der hälfte habe ich schon an Funktionpointer gedacht ;-)

@ESP8266: neue Version 0.3.3 liegt im Git. Umstellung von Ticker zu 
millis(), Visualisierung zeigt jetzt alle bekannten Werte.

[Peter L. (leliep)]

Lukas P. schrieb:
> Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu
> anderen Messeinrichtungen? Ich messe mit einem selbst programmierten
> Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung.
> Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh
> gemessen hat. Das enspricht einer Abweichung von ca. 4%.

Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut 
AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% 
Abweichung.

[Marcel A. (a-marcel)]

Hallo Lukas,

> Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu
> anderen Messeinrichtungen?

Also ich messe mit einem ESP und einem PZEM-004T mit Stromklemme. Ich 
hatte die Werte damals mit einer Fritz! Steckdose verglichen und die 
stimmten immer sehr genau.

Jetzt, wo wir die Werte vom Hoymiles haben, sehe ich, dass die ziemlich 
die gleichen sind, wie gemessen. Ich werde die aber mal demnächst genau 
übereinander legen. Hab seit heute alle Daten in HomeAssistant.

Das einzige was ich sagen kann ist, das die Totalsumme 1% abweicht. Da 
vermute ich aber, dass dieses nicht die AC Leistung ist sondern DC.

Marcel

[Mich@ (Gast)]

Hallo Leute,

Vielen dank für die neue Version.
Die 0.3.2 läuft stabil mit dem Wemos.
MQTT läuft auch reibungslos. Einen Wunsch hätte ich noch, wenn die 
Verbindung zum Wechselrichter nach Sonnenuntergang abreißt bleiben die 
letzten Werte noch im Webinterface und in MQTT stehen. Ist es möglich 
die Werte nach Sonnenuntergang wenn zb. 10 Minuten lang keine Werte 
kommen auf 0 zu setzen? Außer natürlich die Ertragswerte…

Vielen Dank

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> IsnoAhoy schrieb:
>> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …,
>> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn
>> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind.
>
> Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben
> hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl.
> geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge)
> oder einen Gesamt-CRC.

Das ist richtig. Hilft nicht gegen nicht empfangene Pakete. Andere 
Baustelle. Soweit verschlechtert das sogar die Empfangsrate, ist aber 
für den HM-600 zwingend notwendig, weil z.B. der DC kWh total von String 
1 sehr sicher genau fragmentiert ist.

Vorab, die fragmentierten Werte aus verschiedenen Requests zusammen zu 
stückeln ist nicht möglich, weil bei einer Werteänderung über das 
Fragment hinaus zu unterschiedlichen Zeiten sehr falsche Werte heraus 
kommen. Also kein Cache einzelner Fragmente (cmd'd) möglich! Man kann 
allerdings versuchen trotzdem irgendwie Werte zu retten, die nicht über 
mehrere Fragmente verteilt sind. Währe aber sehr viel Aufwand.

Die Fragmente werden darüber henaus auch nicht in der richtigen 
Reihenfolge empfangen.

Ich werde die Tage noch ein PR für ein Rewrite der 
Python-Implementierung einreichen. Ich bin gerade dabei das in Klassen 
und ein Hoymiles Modul zu zerlegen, so kann man dann damit besser 
Tinkern oder z.B. auch mal ein Logfile mit Rohdaten durch pipen.

Und soweit ich das sehe ich das letzte byte in den 0x8n-Responses die 
crc8 über die zusammengesetzte Payload. Jedenfalls stimmt das verdächtig 
zuverlässig.
Also der Ansatz mit den cmd's und channeln ist damit mal begraben, würde 
ich sagen.

Das wars jetzt mit dem Wochenende. Ist eh vorbei :)

Gruß,
Jan

[Marcus (Gast)]

Martin G. schrieb:
> In manchen Programmen war/ist auch immernoch das "AutoACK"
> eingeschaltet.

Auf der Suche nach Gründen, warum der ESP8266 oft hängt bzw. einen 
Watchdog-Reset auslöst habe ich auch folgendes interessante Detail 
gefunden:
 [[https://github.com/nRF24/RF24/issues/244#issuecomment-357210585]]

AutoACK sollte demnach am besten aus sein. Es gibt wohl (gefälschte) 
NRF-Chips, welche damit Probleme machen.
Allerdings ist AutoACK bereits bei den hier verwendeten Tools (esp8266, 
NRF24_SendRecv) aus.

> Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu
> anderen Messeinrichtungen?

Bei meinem HM-400 sind YieldTotal/YieldDay recht nah an meinem SonOff 
Pow R2 (ebenfalls mit 60W, oder waren es 100W Glühlampe?, kalibriert.) 
Der HM-Wert ist leicht höher. Hier sollte man aber am besten einen 
kalibrierten Wechselstromzähler als Vergleich nehmen. Die Kalibrierung 
der SonOff könnte da nicht so gut sein.

Es scheint also weiter unklar, ob YT und YD beim 400er nun AC oder DC 
Werte sind. Mit Blick auf die 600er/1200er müssten es ja auch DC-Werte 
(Modulwerte) sein. Entweder die Typen sind da komplett unterschiedlich 
zu bewerten oder es fehlt generell der AC Wert für YT/Yx.

Idee: Anhand der DC Werte für P kann man ja YT/YD für einen bestimmten 
Zeitraum selbst berechnen und dies mit dem ausgelesenen Werten YT/YD 
vergleichen.
Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher 
sein, da der WR in die Begrenzung geht und damit bei AC weniger 
"herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in 
dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für 
das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert 
anliegt, da Begrenzung).
Ich rechne das mal für den 400er YD/YT Wert nach.

[Nomen est Omen (Gast)]

Lukas P. schrieb:
> Sorbit schrieb:
>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?
>
> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier
> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP
> auf die /setup Seite gehen und dort alles konfigurieren.

Das ist supernett, danke!

Ich probier es ASAP aus.

BG

[Sorbit (Gast)]

Nomen est Omen schrieb:
> Lukas P. schrieb:
>> Sorbit schrieb:
>>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen
>>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…?
>>
>> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier
>> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP
>> auf die /setup Seite gehen und dort alles konfigurieren.
>
> Das ist supernett, danke!
>
> Ich probier es ASAP aus.
>
> BG

Sorry für den faschen Namen, ich bin an einem anderen Rechner in einer 
anderen "Welt"...

Richtig wäre Sorbit, gewesen.
Der Ersteller des Threads, der sich wundert was er hier "angestellt" 
hat.
Toll welcher Enthusiasmus sich hier verbreitet hat!

Hut ab

[Andreas E. (andreas5232)]

Peter L. schrieb:
> Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut
> AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2%
> Abweichung.

Ich habe hier einen Sonoff Dual R3, um den Ertrag meines HM-600 zu 
messen. Kalibriert habe ich damals mit einer 60W Glühbirne. Bei mir sind 
es heute bisher 1,318 kWh (Sonoff) und 1,426 kWh (AHOY 0.3.3). Bei den 
gemessenen Watt liegt der Sonoff aktuell (keine Voll-Last) jeweils ca. 
10-20 Watt unter dem per AHOY gemessenen Wert.

Marcus schrieb:
> Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher
> sein, da der WR in die Begrenzung geht und damit bei AC weniger
> "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in
> dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für
> das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert
> anliegt, da Begrenzung).

Falls uns das hilft: Ich habe auch Zugriff auf eine zweite Anlage mit
HM-600 und zwei "großen" Modulen, die bei guter Sonne regelmäßig in die 
Begrenzung des Wechselrichters laufen. Evtl. können wir durch die 
Beobachtungen ja das AC/DC Rätsel lösen.

[Hubi (Gast)]

Meine Anlage besteht aus HM-600 und 2 Module mit je 370 Wp, also 740 Wp. 
Der höchste gemessene Wert für die aktuelle Leistung war 612 W. Wenn das 
DC sein sollte müsste es schon mehr sein, m.E.
Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal 
kurzzeitig (wie hier) drüber sein?

[Carsten B. (carstenb)]

Hubi schrieb:
> Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal
> kurzzeitig (wie hier) drüber sein?

Hallo,

ich habe 700Wp an meinem HM600 und auf meinem shelly habe ich AC-seitig 
schon etwas über 600W gesehen. Meist so um die 620W.

Lieder habe ich grade keine DC-Daten, da ich nicht mitlogge. Ich habe 
leider etwas den Anschluss zum Projekt verloren. Was ist denn der 
sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich 
da.


Carsten

[isnoAhoy (Gast)]

> Ich habe  leider etwas den Anschluss zum Projekt verloren. Was ist denn der
> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich
> da.

Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten 
zu empfangen.
Den kannst Du entweder mit
* Deinem D1mini (ESP8266/ESP32) und der ahoy Software unter 
tools/esp8266 (v0.3.2/3) von Lukas P.oder
* einem Raspberry Pi und der ahoy Software unter tools/pi von Martin G. 
betreiben.

Anleitung zur Verdrahtung des ESP findet sich unter
https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

@Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine 
config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte 
Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben 
könnte. Dann müsste man sich nicht immer erst mit dem Access Point 
verbinden und könnte diese Settings hart verdrahten. Zumindest in der 
Entwicklungsphase würde mir das eine Menge Tipparbeit im WebInterface 
ersparen. Ich habe nämlich jetzt mehrfach den kompletten Flash erased, 
da ich hier Probleme bei der Umstellung des Speicher-Layouts der 
Konfigurationsdaten vermutet habe. Auch scheint er den Access Point 
aufzumachen, wenn er das lokale WiFi Netzwerk (wegen Empfang) nicht 
erreichen kann. Gibt es auch einen Fallback, daß er immer mal wieder 
versucht das Netzwerk zu erreichen ?

[Herbert K. (avr-herbi)]

isnoAhoy schrieb:
> @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine
> config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte
> Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben
...
Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im 
EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update 
(Fehlerbehebung) sich nicht ändern.
Ganz am Anfang dann die Länge von so einem Block.
Darüber dann eine CRC bilden.
Beim Neustart, dann die Länge aus dem EEPROM lesen. CRC abchecken und 
wenn so weit ok, dann mit den Werten starten ?
Am Ende von so einem Block würde ich das so gestalten, das sich die 
Anzahl der WR ändern kann, evt. auch einzelne CRC s  über WR Blöcke. 
Wenn sich dann jemand einen zusätzlichen WR kauft und einhängen will, 
kann alles so bleiben und er muss nur die SN / Typ des neuen WR 
eingeben. Dann wird der entsprechende Block am Ende drangehängt, mit 
einer CRC versehen und man kann weiter Software Updates machen ohne 
irgendwas einzugeben.
Ist nur mal so eine Ideeeeeee  :-)

[Petra R. (petra-kathi)]

Hallo zusammen,

nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern 
mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der 
ahoy.conf für einen HM-1500
(...
[inverter]
serial = 116173415022
)

... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo 
pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 
ahoy.py" leider den Anschiss ...

ModuleNotFoundError: No module named 'RF24'

Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit 
...

ModuleNotFoundError: No module named 'cross.crossunixccompiler'

... hängen. Ich habe darauf hin mit

"sudo pip3 install cross" das umfassende Modul nachinstalliert, das ja 
dieses 'crossunixccompiler' enthalten sollte. Das ist auch ohne 
Fehlermeldung durchgelaufen. Es bleibt aber das Problem mit dem RF24, 
weil nach wie vor die Compilation von RF24 nicht durchläuft:

Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.
ERROR: Could not find a version that satisfies the requirement RF24
ERROR: No matching distribution found for RF24

Eine Suche nach "crossunixccompiler" war leider erfolglos, so dass ich 
da aktuell nicht weiter komme.

Der Vollständigkeit halber: uname -a liefert:
Linux raspberrypi 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 
armv7l GNU/Linux

Bliebe die Frage: Wo ist der Haken?


Ergänzungs-Verständnisfrage zum Ahoy-Paket:
Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles 
wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann?

Tschüssi,
Petra

[Lukas P. (lumapu)]

Vielen Dank für die zahlreichen Infos zu euren Vergeleichsmessungen. 
Jetzt habe ich einfach mal den Multiplikator meiner Kalibrierung 
(Sonoff) wieder auf 1.00 gestellt und habe jetzt identische Werte mit 
dem WR. Bei Gelegenheit werde ich nochmal mit einer Fritz! Steckdose 
gegenchecken.

isnoAhoy schrieb:
> Gibt es auch einen Fallback, daß er immer mal wieder
> versucht das Netzwerk zu erreichen ?

Das prüfe ich nochmal, sowas hatte ich mal im Sinn weiß aber nicht ob's 
hier implementiert ist. Finde ich auf jeden Fall sinnvoll.

Herbert K. schrieb:
> Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im
> EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update
> (Fehlerbehebung) sich nicht ändern.
> Ganz am Anfang dann die Länge von so einem Block.
> Darüber dann eine CRC bilden.

Danke fürs Feedback. Ja hier ist noch Handlungsbedarf, ich weiß nicht 
mehr wie oft ich die Daten schon neu eingegeben habe. Ich werde es 
nochmal durchdenken und evtl. auch gleich umsetzen. Meiner Meinung sind 
nach der Aufteilung von WiFi und Sonstigen Settings (haben jeweils einen 
unabhängigen CRC) in getrennte Bereiche keine WiFi-Daten mehr verloren 
gegangen. (Klar da war noch der Issue mit der Passwortlänge, diese wurde 
auf 63 Zeichen angehoben)

[Martin G. (petersilie)]

Petra R. schrieb:
> Hallo zusammen,
>
> nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern
> mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der
> ahoy.conf für einen HM-1500
> (...
> [inverter]
> serial = 116173415022
> )
>
> ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo
> pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3
> ahoy.py" leider den Anschiss ...
>
> ModuleNotFoundError: No module named 'RF24'
>
> Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit
> ...

Hallo Petra,

die Installation des RF24-Moduls ist leider etwas komplizierter. Ich 
habe versucht, das in 
https://github.com/grindylow/ahoy/tree/main/tools/rpi einigermaßen zu 
beschreiben.

Im Prinzip sollte es reichen, der Anleitung für Python 3 auf

* https://nrf24.github.io/RF24/md_docs_python_wrapper.html

...zu folgen.

Wobei ich auf meinen beiden Raspis zuvor jeweils auch

* https://nrf24.github.io/RF24/md_docs_linux_install.html

...gemacht habe. Bin mir aber nicht mehr ganz sicher, ob das wirklich 
notwendig ist.

Einfach nur mit "pip" geht bei dieser Bibliothek wohl (noch) nicht.


> Ergänzungs-Verständnisfrage zum Ahoy-Paket:
> Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles
> wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann?

Ja leider richtig. Das entstand, als wir noch der Annahme waren, dass 
die WR AutoACK aktiviert hätten. Schön wär's gewesen :-(. So findet es 
nur andere NRF24-Empfänger, die AutoACK aktiviert haben. Leider quasi 
nutzlos.

-- petersilie

[Martin G. (petersilie)]

Ich habe jetzt wider Erwartens doch noch meine DTU-lite bekommen, und 
würde mal versuchen, sie in Betrieb zu nehmen.

Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem 
Einrichtungsvorgang "zuhören"? Kanal 40?

-- petersilie

[Herbert K. (avr-herbi)]

Martin G. schrieb:
...
> Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem
> Einrichtungsvorgang "zuhören"? Kanal 40?
...
> -- petersilie

Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen  :-)
MOSI, MISO, usw.
https://www.az-delivery.de/products/saleae-logic-analyzer
Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom 
LA klar kommst, dann die PINs im DTU-Lite :-)  so ist das gemeint von 
mir.
Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als 
Hex anzeigen. Bin mir aber nicht mehr 100% sicher.
Muss ja beim 1. Schuss am DTU-Lite zu 100% funktionieren - wir wissen ja 
nicht, was sich der alles merkt.  :-)
Den LA gibts natürlich auch bei anderen Anbietern.

[martin (Gast)]

Herbert K. schrieb:
> Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen  :-)
> MOSI, MISO, usw.

Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner 
DTU festgestellt hatte:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E 
handelt, der einen eigenen Controller drin hat.

[Olaf A. (Gast)]

Erstmal für Seriennummernsammlung vorweg.

HM-800  11417420xxyy
HM-1500 11616320xxyy
MI-1200 10616090xxyy

Ich bin diesem Thread schon lange gefolgt, wollte mich aber erst melden, 
wenn ich Daten von meinen beiden Wechselrichtern empfangen konnte.

Hatte mir das NRF24LE01+ mit externer Antenne gekauft und einige D1 mini 
V3, hatte jedoch nie Empfang. Kaufte verschiedene NRF24LE01+ und testete 
alle möglichen Kombinationen durch. Erst als ich D3 und D4 auf D1 und D2 
umverdrahtete, mit der entsprechenden Setup-Änderung, konnte ich 
problemlos alles empfangen.

Vielleicht kann sich einer von euch einen Reim darauf machen, warum D3, 
D4 bei mir nicht funktionieren.
-- olaf

[Carsten B. (carstenb)]

isnoAhoy schrieb:
>> Ich habe  leider etwas den Anschluss zum Projekt verloren. Was ist denn der
>> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich
>> da.
>
> Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten
> zu empfangen.

Hallo,

danke für den Input. Mit einem Arduino nano hatte ich hier ja Anfangs 
schon Daten mitgeloggt... Dann schau ich mal, ob ich es heute Abend 
vielleicht auf dem ESP zum laufen bekomme.

Carsten

[Herbert K. (avr-herbi)]

martin schrieb:
> Herbert K. schrieb:
...
> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
> handelt, der einen eigenen Controller drin hat.
...
Entschuldigung !  Daran hatte ich nicht mehr gedacht.

[isnoAhoy (Gast)]

Hallo martin & Herbert,

> > Herbert K. schrieb:
> ...
> > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
> > handelt, der einen eigenen Controller drin hat.
> ...
> Entschuldigung !  Daran hatte ich nicht mehr gedacht.

Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für 
RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal 
anbei.

Eventuell könnte man auch mit dem openocd Debugger am SWD Port den 
GD32F303 anhalten und Flash Programm, etc. genauer analysieren. Es gibt 
m.W. eine eigene target/gd32f30x.cfg mit der es m.E. nach bei mir 
funktioniert hat den GD in einem MH-Z19C Sensor anzusprechen.

https://github.com/gd32-rs/gd32-openocd/blob/master/target/gd32f30x.cfg

Bei einer schnellen Suche nach "openocd gd32" kamen gerade noch die 
folgenden beiden evtl. interessanten Links heraus:

https://registry.platformio.org/tools/communitygd32cores/tool-openocd-gd32
https://github.com/stlink-org/stlink/issues/769

Wobei ich in meinem Fall keinen Erfolg mit dem bestehenden 
target/st-linkv2.cfg hatte.

[B. G. (golf2010)]

Martin G. schrieb:
> Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem
> Einrichtungsvorgang "zuhören"? Kanal 40?

Ideal wäre halt eine breitbandige Aufzeichnugsmöglichkeit mit einem 
HackRF oder ähnlichem besseren SDR, da ja mehrere Frequenzen in Frage 
kommen. Ich hab meine Aufzeichnungen mit einem BladeRF gemacht, der 
macht dann ca 60 Mhz Bandbreite. Vorhanden ist bei mir u.a. der LimeSDR 
, BladeRF, HackRF.

Oder evtl reicht auch ein NRF24L01-Sniffer, der zuverlässig die in Frage 
kommenden Frequenzen abscannen kann. Durch die Sende-Wiederholungen 
gibts da  normal keine Zeitprobleme.

[Sorbit (Gast)]

isnoAhoy schrieb:
> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
>
> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den
> ESP8266 zu kompilieren. Prüfe mal folgendes:
> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support
> herunterladen)
> * die beiden RF24 und TimeLib Bibliotheken im Library Manager
> installieren.
> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der
> ESP8266 Boards Umgebung ?
>
> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem
> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die
> Schritte die Dir fehlen nachreichen ?

@ Lukas, @isnoahoy,

der Geier weiß warum; Erfolg;-)
Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen 
und nun läuft der Compiler fehlerfrei durch!!!

DANKE!!!

[Sorbit (Gast)]

Sorbit schrieb:
> isnoAhoy schrieb:
>> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
>>
>> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den
>> ESP8266 zu kompilieren. Prüfe mal folgendes:
>> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support
>> herunterladen)
>> * die beiden RF24 und TimeLib Bibliotheken im Library Manager
>> installieren.
>> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der
>> ESP8266 Boards Umgebung ?
>>
>> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem
>> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die
>> Schritte die Dir fehlen nachreichen ?
>
> @ Lukas, @isnoahoy,
>
> der Geier weiß warum; Erfolg;-)
> Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen
> und nun läuft der Compiler fehlerfrei durch!!!
>
> DANKE!!!

Ich habe den NRF noch nicht angeschlossen (verdammt wo liegt der rum?)
Mit dem AP kann ich mich verbinden, anpingen, Webseite bleibt aber leer.

Ich denke das ist "normal" so wenn der NRF noch nicht dranhängt?
Danke,


ich suche weiter...

[Petra R. (petra-kathi)]

Sodele,

ich habe jetzt das ahoy.py auf einem Raspi 3B mit einem HM-1500 zur 
Kommunikation bekommen und sehe erste Returns:

2022-05-03T07:20:30.553251Z MSG src=73415022, dst=73415022, cmd=1:
{"ts_unixtime": 1651555230.553251, "isodate": 
"2022-05-03T07:20:30.553251", "rawdata": "95 73 41 50 22 73 41 50 22 01 
00 01 01 4e 00 1a 00 14 00 56 00 42 00 00 08 0b c3", "crc8_valid": true, 
"mid": 149, "response_time_ns": 18257366, "ch_rx": 3, "ch_tx": 40, 
"src": "73415022", "name": "dcdata", "dst": "73415022", "cmd": 1, 
"u1_V": 33.4, "i1_A": 0.26, "p1_W": 2.0, "u2_V": 8.6, "i2_A": 0.66, 
"p2_W": 0.0, "p_W": 2.0, "unknown1": 1, "unknown2": 2059}
2022-05-03 09:20:30.601844 Received 27 bytes on channel 3 pipe 1: 95 73 
41 50 22 73 41 50 22 02 00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c 
e3
2022-05-03T07:20:30.602257Z MSG src=73415022, dst=73415022, cmd=2:
{"ts_unixtime": 1651555230.602257, "isodate": 
"2022-05-03T07:20:30.602257", "rawdata": "95 73 41 50 22 73 41 50 22 02 
00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c e3", "crc8_valid": true, 
"mid": 149, "response_time_ns": 67262961, "ch_rx": 3, "ch_tx": 40, 
"src": "73415022", "name": "acdata", "dst": "73415022", "cmd": 2, "u_V": 
2.3, "f_Hz": 0.21, "p_W": 7.6, "wtot1_Wh": 0, "wtot2_Wh": 12, 
"wday1_Wh": 9, "wday2_Wh": 334, "uk2": 2939}

So ganz glauben tu' ich den Werten allerdings noch nicht.  :-)
Nicht mal u1_V und i1_A: Auch wenn die Sonne gerade nicht prall auf das 
180 W_p Modul scheint, sollten da doch etwas mehr als 0,26 A bzw. 2 W 
kommen, oder?

Fragt sich jetzt, wie ich den Interpretations-Gurus unter euch 
bestmöglich in die Seite treten kann?

Noch eine Beobachtung, den Raspi betreffend: Wenn ich den (aus 
Stöpsel-Faulheit) nur per WLAN anspreche, scheint der des Öfteren hängen 
zu bleiben. Nach Anschluss per LAN-Kabel scheint dies nicht mehr 
aufzutreten. Kann es sein, dass dessen WLAN und der nRF24 sich 
gegenseitig beim Funken ins Gehege kommen?

Tschüssi,
Petra

[Andreas E. (andreas5232)]

Robert Bleumer schrieb:
> Steht upload nach PvOutput.org noch auf's Programm?

Ich denke aktuell liegt das Hauptaugenmerk noch auf dem korrekten 
auslesen der Daten. Aber später gibt es bestimmt die Möglichkeit, eine 
Anbindung zu PvOutput.org einzubauen.

Die Doku dazu sieht relativ ausführlich aus, sodass es denke ich gut 
machbar wäre. https://pvoutput.org/help/index.html

[Petra R. (petra-kathi)]

Hallo Martin,

danke schön für deine Erklärungen! Mittlerweile läuft's ja, wie man an 
meinem letzten Post sehen kann.  thumbs_up

> Im Prinzip sollte es reichen, der Anleitung für Python 3 auf
>
> * https://nrf24.github.io/RF24/md_docs_python_wrapper.html
>
> ...zu folgen.

Das habe ich gemacht, bin aber auf einige Ungereimtheiten in der Abfolge 
gestoßen. Dies nur als Warnung für Nachfolgende, die es nach dieser 
Anleitung wortwörtlich probieren.

Letztlich muss ich übrigens das ahoy.py auch mit sudo aufrufen, sonst 
will es nicht.

Irgendwie scheine ich mich aber insgesamt wohl durchgewurschtelt zu 
haben.  ;-)

Viele Grüße,
Petra

[Herbert K. (avr-herbi)]

Guten Morgen !
Wie und wann und unter welchen Umständen die Kanäle gewechselt werden 
weiss ja scheinbar noch niemand (oder doch?).
Nur mal so als Idee: Die NRF24L01+ Module kosten ja nicht die Welt. Was 
spricht denn gegen den Einsatz von 5 Stk. - jedes auf einem festen Kanal 
?
Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?

[Jan-Jonas S. (janjonas_s)]

Moin,

ich baue ja in der Python-Implementierung am empfang der vollständigen 
Payload vom Wechselrichter. Weil noch sehr "work in progress" gibts da 
noch kein PR zu. Nur so zur Info. Oben schrieb ich, die Zusammengesetzte 
Payload ist mit der crc8 im letzten byte der Payload der 0x8n-Fragmente 
signiert. Es ist jedoch ModbusCRC. Definitiv.

Ich hab das bei mir so nebenbei laufen und bekomme sehr gute Ergebnisse. 
Zur Zeit ist nur der HM-600 implementiert, weil der mit dem Ansatz des 
Auswertens von Payload-Fragmenten eben nicht vollständig lesbar ist. Was 
anderes habe ich nicht.

Was ich vor dem PR noch tun will:
 * Dekoder neu implementieren (bloß schnell hin gepfuscht als Beiwerk 
zum PoC)
 * PayloadBuilder bauen
 * Inverter-Klasse als Interface
 * Multi-Inverter

Wie in der test.py zu sehen ist, lassen sich damit auch Logfiles mit 
Rohdaten neu auswerten. Sehr gut zum nachts entwickeln. ;)

https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi (Preview, 
wird sicher noch ein paar mal amended)

Der Output läuft bei mir aus Faulheitsgründen in eine vergleichbare 
Topic-Struktur, wie auch Shelly sie verwendet. Damit frisst der telegraf 
das gleich in die richtigen Influx measurements weg.

Gruß,
Jan

[Klaus K. (Gast)]

Ich hätte da mal eine grundsätzliche Frage: beim Nordic Protokoll, dass 
die Daten seriell fliessen ist schon klar aber wird da eigentlich MSB 
oder LSB zuerst geschickt?

Ich dachte bisher immer MSB first, aber das passt überhaut nicht mir der 
Anzeige meines LA (SALEAE/Sigrok) zusammen. Die Anzeige meines DSO 
(Batronix Rigol DS1054Z, alle Optionen freigeschaltet) decken sich damit 
auch nicht.

Ich habe schon probiert wie wild, komme damit aber nicht so recht 
weiter. Wer kann helfen?

[B. G. (golf2010)]

Herbert K. schrieb:
> Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?

Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme 
vermissen.

[isnoAhoy (Gast)]

> > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?
> Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme
> vermissen.

Das hatte Oliver F. bereits am 16.04.2022 auf Seite 3 mit einem hübschen 
Modell mit insgesamt sechs NRF24L01+ vorgeschlagen.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

@Oliver F., was ist denn daraus geworden ?

[Mich@ (Gast)]

Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana 
visualisiert. Anbei einige Diagramme.

Die AC-Leistung stimmt mit meiner Kalibrierten Sonoff Steckdose bis auf 
wenige Watt Unterschied überein.

Danke und großes Lob an alle.

[Jan-Jonas S. (janjonas_s)]

Mich@ schrieb:
> Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana
> visualisiert. Anbei einige Diagramme.

Netter Versuch :) Anbei mal Ausschnitte aus meinem Dashboard. Die 
zugehörige Telegraf-Config hab ich oben mal gepostet.
Das Dash braucht Influx2 (Flux)

Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus 
dem HM600 raus geholt.

Request 80 02 + time

2022-05-03 20:27:56.781439 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 2c 00 00 00 05 00 00 00 00 86 3c 79
2022-05-03 20:27:56.844744 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:27:56.887237 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:27:56.935143 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:27:56.977203 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:27:57.025358 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:27:57.073432 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:27:57.115671 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:27:57.163807 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:27:57.211908 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:05.613912 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 35 00 00 00 05 00 00 00 00 16 9b 57
2022-05-03 20:28:05.689287 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:05.737622 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:05.785561 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:05.827717 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:05.875809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:05.923963 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:05.966142 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:06.014271 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:06.056376 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:13.833624 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 3d 00 00 00 05 00 00 00 00 d6 fc f8
2022-05-03 20:28:13.890903 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:13.939259 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:13.981286 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:14.029283 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:14.071458 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:14.119636 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:14.167809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:14.209973 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:14.258033 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:40.145516 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 58 00 00 00 05 00 00 00 00 84 6b 58
2022-05-03 20:28:40.214575 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:40.262608 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:40.304763 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:40.352869 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:40.401014 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:40.443199 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:40.491307 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:40.533532 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:40.581560 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:42.355754 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5a 00 00 00 05 00 00 00 00 e4 72 23
2022-05-03 20:28:42.454595 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:42.490861 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:42.526965 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:42.592729 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:42.629048 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:42.671269 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:42.719446 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:42.791353 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:42.839432 Received 23 bytes channel 3: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd
2022-05-03 20:28:44.815962 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5c 00 00 00 05 00 00 00 00 44 59 ae
2022-05-03 20:28:44.885060 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19
2022-05-03 20:28:44.933349 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4
2022-05-03 20:28:44.975352 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd
2022-05-03 20:28:45.029316 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c
2022-05-03 20:28:45.071513 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c
2022-05-03 20:28:45.113829 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf
2022-05-03 20:28:45.161987 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6
2022-05-03 20:28:45.210197 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a
2022-05-03 20:28:45.252331 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd

Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche 
Transaktionen mit valider crc über die 140 byte. Viel Spaß beim 
dechiffrieren *duckundweg

Eine Antwort auf 80 0b "Zeit setzen" sieht zum Vergleich so aus:

2022-05-03 20:27:07.155080 Transmit | 15 72 22 01 43 78 56 34 12 80 0b 00 62 71 73 fb 00 00 00 05 00 00 00 00 a0 3f 85
2022-05-03 20:27:07.219066 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 24 00 04 00 0b 01 25 00 04 00 0c 00 00 93
2022-05-03 20:27:07.267618 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 97 5f 00 00 8e 5f 07 b2 07 b9 08 e2 13 8a 00 00 f6
2022-05-03 20:27:07.316231 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 00 00 00 00 ca 00 06 0a 1b cb
2022-05-03 20:27:07.316231 Decoded: 44 string1= 29.2VDC 0.04A 1.1W 38751Wh 1970Wh/day string2= 29.3VDC 0.04A 1.2W 36447Wh 1977Wh/day phase1= 227.4VAC 0.0A 0.0W inverter=114172220143 50.02Hz 20.2°C

Gruß,
Jan

[Sorbit (Gast)]

@ahoy,


Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat 
und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt?
Ich bleibe immer auf der Konfig Seite kleben..

[Andi (Gast)]

Hallo Freunde,
solange ihr noch aktiv am Loggen und Entschlüsseln der CMD´s seit, 
möchte ich euch nochmal an ein in den Hintergrund gerücktes aber 
wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft 
werden oder hier wichtige Leute abspringen:
Es wäre toll, wenn ihr herausfindet, wie sich die Wechselrichter in der 
Leistung limitieren lassen, pro Kanal muss nicht unbedingt sein, die 
Gesamtleistung wäre schonmal ein sehr guter Anfang. (am besten diesen 
Thread nach "limit" durchsuchen, um die bisherigen Informationen dazu zu 
finden)
Dann hätten wir endlich mal einen qualitativ hochwertigen Wechselrichter 
zum guten Preis/Leistungsverhältnis, der an einen kleinen Speicher 
angeschlossen werden kann, um z.B. die Grundlast oder zumindest ein Teil 
davon nachts mit dem Speicher zu decken.
Es gibt bereits ein älteres Projekt aus dem photovoltaikforum mit dem 
MI-300 und neuerdings auch ein Update mit dem HM-800 (und natürlich 
baugleiche Modelle in den jeweils 3 Leistungsstufen), bei dem vorsichtig 
ein Loch an der richtigen Stelle in das Gehäuse gebohrt werden muss und 
mit einer kleinen Schaltung per PWM über einem Operationsverstärker ein 
falscher Strommesswert vorgegaukelt wird, so kann man den WR also auch 
regeln. Das hat natürlich den Nachteil, dass man etwas basteln muss und 
die Garantie weg ist. Gut, als Batteriewechselrichter sind die auch 
nicht gedacht, also wie es da mit der Garantie aussieht ist fraglich, 
aber sie sind zumindest geeignet und man lässt den ja auch nicht 
permanent mit 100% laufen, sondern regelt ihn ja dann intelligent je 
nach Bedarf oder Speicherfüllung. Diese guten Mikrowechselrichter sind 
jedenfalls besser als der Chinaschrott, der ähnlich viel kostet und noch 
dazu größer, lauter und ineffizienter ist.
Es wäre daher toll, wenn quasi die gleiche Regelung per Funk einfach 
möglich ist.
Deshalb würde ich euch darum bitten, dieses Signal mal zu sniffen und zu 
implementieren.

Aber schonmal ein großes DANKE an alle, für eure bisherige tolle Arbeit, 
gemeinsam bekommen wir den Rest auch noch implementiert!

Sonnige Grüße, Andi

[Heinz R. (heijz)]

Andi schrieb:
> möchte ich euch nochmal an ein in den Hintergrund gerücktes aber
> wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft
> werden oder hier wichtige Leute abspringen:

wozu willst den WR regeln?
Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, 
bringt paar Euro

Eine Abregelung macht nur wegen der 70% Grenze- die eh keinen 
Interessiert - Sinn - oder wenn man den WR als Batterie-WR nutzen möchte

[Sorbit (Gast)]

> wozu willst den WR regeln?
> Der soll so viel wie möglich bringen- der Überschuss geht ins Netz,
> bringt paar Euro
>

Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein 
hat.

[IsnoAhoy (Gast)]

> Es wäre toll, wenn ihr herausfindet,
> wie sich die Wechselrichter in der
> Leistung limitieren lassen, pro
> Kanal muss nicht unbedingt sein, die
> Gesamtleistung wäre schonmal ein
> sehr guter Anfang. (am besten diesen
> Thread nach "limit" durchsuchen, um
> die bisherigen Informationen dazu zu
> finden)

> Es wäre daher toll, wenn quasi die
> gleiche Regelung per Funk einfach
> möglich ist. Deshalb würde ich euch
> darum bitten, dieses Signal mal zu
> sniffen und zu implementieren.

Hallo Andi,
das ist in der Tat ein interessantes und mE wichtiges Thema.

1. Zero Export Restrictions Mode
Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. 
Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU 
setzen.

> 4.1 Work Mode (page 9)
> Normal: In this mode, the microinverter operates normally and converts DC power 
into AC power to support the household loads and feeds into the public grid.
> Zero Export Control: In this mode, the microinverter’s generation is limited 
based on the current household loads, and there is no extra power fed into the 
public grid.
> Standby: There are several circumstances in which the microinverter will be in 
Standby mode:
> • The current condition contradicts with the microinverter operating 
requirements.
> • No household loads or the export control value has been set as “0” on the DTU 
in the Zero Export Control mode.

2. Grid Power Profile
Zusätzlich gibt es noch ein sog. Grid Profile in der DTU/Hoymiles Cloud. 
Ich weiß aber nicht ob man das zB von AT auf DE oder PT ändern kann…
Es wird u.a. auf den Screenshots von Enercab bzw in deren Hoymiles Cloud 
ausgegeben.

> Grid Profile Version: 2.0.0 (AT_TOR_Erzeuger_default)

3.
Als drittes ist mir in den Fehlercodes des HM-600/700/800 (6.1 
Troubleshooting List, page 14ff) aufgefallen, dass es u.a. auch einen
Code „149 Island detected“ gibt. Einige dieser Fehler sollte man ja ggf. 
Provozieren und auslesen können.

4. Communication with DTU changes Status LED Indicator

> 6.2 Status LED Indicator
> The LED flashes five times at startup. All green flashes (1s gap) indicate 
normal startup.
> Status LED
> (1) Startup Process
> • Five green flashes (0.3s gap): Startup success
> • Five red flashes (0.3s gap): Startup failure
> (2) Running Process
> • Fast green flashing (1s gap): Producing power.
> • Slow green flashing (2s gap): Producing power, but one input is abnormal.
> • Slow green flashing (4s gap): Producing power, but there is no communication 
with DTU.
> • Red flashing (1s gap): Not producing power, AC grid fault (voltage or 
frequency out of range).
> • Red flashing (0.5s gap): Non-grid abnormality fault.
> (3) Other Status
> • Alternating red and green flashing: Firmware is corrupted.
> *Note: All faults are reported to the DTU, refer to the local DTU app or S-Miles 
Cloud (Hoymiles Monitoring
Platform) for more information.

https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_HM-600700800_Global_EN_V202203.pdf

[Heinz R. (heijz)]

Sorbit schrieb:
> Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein
> hat.

IsnoAhoy schrieb:
> 1. Zero Export Restrictions Mode
> Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog.
> Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU
> setzen.

kann es sein das hier die 70%-Regelung (harte/ weiche Abregelung) 
durcheinander gebracht wird?
Für den Zero Export Control mode reicht es sicher nicht diesen zu setzen 
- an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU 
regelt die WR dynamisch

IsnoAhoy schrieb:
> 2. Grid Power Profile

Damit ist wohl die Einstellung des CosPhi gemeint

[Herbert K. (avr-herbi)]

Heinz R. schrieb:
> - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU
> regelt die WR dynamisch

Interessant wäre das schon.
Leider können da nur die weiterhelfen, die auch die DTU-Pro haben 
vermute ich.

Bei möglichen Fehlern (wie bei MODBUS erklärt), da sind wohl auch die 
DTU-Pro Besitzer gefragt ?

Ich habe beim HM-350 und HM-400 mal auf DC-Plus und DC-Minus einen 
Kurzschluß zu "Erde" gemacht. Begonnen mit 100K Ohm bis herunter zu 0 
Ohm mit verschiedenen Werten. Das hat beide nicht gejuckt. Weder Mitten 
im Betrieb, noch bevor sie mit dem PV Modul verbunden waren. Die gehen 
ganz Normal in Betrieb wie immer. Erwartet hätte ich einen 
"Isolationsfehler", ohne das sie in Betrieb gehen, wie z.B. bei den SMA 
WR. Bisher habe ich keine DTU-....

Grundsätzlich wäre auch erst mal Interessant, wer welche Fehlermeldungen 
über die DTU-... dann in der Cloud gesehen hat. So was wie falsche 
Netzfrequenz zu simulieren, wird schwierig.

[Sorbit (Gast)]

Sorbit schrieb:
> @ahoy,
>
> Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat
> und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt?
> Ich bleibe immer auf der Konfig Seite kleben..

Ahoy, wo bist DU ?;-)

[franz (Gast)]

Hallo,
ich habe mir vor ein paar Wochen 2 Balkonmodule vom Stromanbieter mit 2 
(vermutlich HM-350) Wechselrichtern gekauft, und ahoy.py dafür 
angepasst, damit ich die Ergebnisse in den io-broker bekomme. Vielen 
Dank was da alles schon an Vorarbeit geleistet wurde!

Softwareinstallation wie im repository beschrieben, hardware raspi4, 
Kabel aus https://www.amazon.de/gp/product/B078JGQKWP weil ich so die 
gleichen Farben wie in der Anleitung verwenden konnte 😊 und Radiomodul 
aus https://www.amazon.de/gp/product/B07PBBC4H9 (sind also NRF24L01+ und 
das + bezieht sich nicht auf die anderen Teile). Damit lässt sich das 
ohne Aufwand zusammenstecken.

Habe mir das Forum von Anfang an durchgelesen und noch hoffentlich noch 
für HM300,  HM450, HM600, HM700, HM-800, HM-1200, HM1500 support 
eingebaut, indem ich die ersten 4 Stelen der Seriennummer auswerte und 
entsprechend verzweige. Außerdem Support für mehrere Wechselrichter und 
etwas weniger Radio Noise nachdem das Programm nach einer Meldung 10 
Sekunden wartet um einen Inverter der geantwortet hat nochmals zu 
fragen. Programm liegt in franzongit branch.
Ich hoffe das erleichtert den Einstieg für technisch nicht so versierte.

lg Franz

[Jan-Jonas S. (janjonas_s)]

franz schrieb:
> für HM300,  HM450, HM600, HM700, HM-800, HM-1200, HM1500 support
> eingebaut...

Die alte ahoy.py, sowie das C-Projekt brauchen einen full-rewrite.
Am Python bin ich gerade dran und bau da ein flexibles Modul draus, was 
im Idealfall so einfach instanzierbar ist wie der mqtt-client, und 
Framing, Fragmentierung beim senden einer arbiträr langen Payload, sowie 
Transport-Layer und Dekodierung übernimmt.

Im Wesentlichen senden die Wechselrichter halt größere Payloads über 
mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die 
längste Payload, die ich von einem HM600 empfangen habe ist 140 byte 
lang. Da die crc stimmt, confirmed.
Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt 
in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich 
einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten.

Ich gehe bisher davon aus, dass der Fragment-Zähler (ehem. cmd) von 
0x01-0x80 zählen kann und 0x80-0xNN (0xNN = Fragment-Zähler größer 0x80) 
die Anzahl der Fragmente des Pakets angibt. Schon passt da eine ganze 
Firmware rein.

Die einzelnen Fragmente isoliert zu verarbeiten ist ein Dead-End.

Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit 
Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet.

Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in 
zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten 
und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was 
angefragt wurde, um die Payload dekodieren zu können.

Wir sollten zukünftig also von:
Fragmenten, Paketen, und Payloads sprechen.
Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das 
Paket enthält die Payload.

Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment 
+ 1 byte crc
Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc
Jede Payload kann demnach max 2046 byte haben.
Vermutung, abgeleitet aus den bisher bekannten Umständen.

Man müsste jetzt mal schauen, ob man aus dem 1. byte Payload vielleicht 
Rückschlüsse auf den Inhalt der Payload gewinnen kann.

Gruß,
Jan

[IsnoAhoy (Gast)]

Hallo Sorbit,
ich habe keine Ahnung wen Du mit Ahoy meinst. Ich glaube Martin G. / 
Petersilie hat das Logo gemalt und das Projekt so genannt ? Ich nenne 
mich isnoAhoy also eben nicht Ahoy :)

> Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur 
eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf 
der Konfig Seite kleben..

Das Problem habe ich auch. Das Programm macht beim Neustart mehrere 
Versuche das konfigurierte WLAN zu kontaktieren. Wenn es nicht klappt 
oder die Verbindung später abreißt dann kommt man ausser über den Serial 
Port oder ggf den AccessPoint nicht mehr an die Oberfläche.
Lukas P. versucht das Problem einzugrenzen bzw zu beheben.
Siehe auch:

https://github.com/grindylow/ahoy/issues/15

Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je 
nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN 
Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet.

Evtl. kann man in Zukunft die beiden Oberflächen vereinheitlichen und 
den Reconnect mit dem WLAN alle X Minuten einstellen oder per Serial 
Command forcieren?

[Andi (Gast)]

@Heinz
Ja, natürlich macht im ersten Moment eine Limitierung keinen Sinn, man 
verschenkt ja dadurch gratis Energie, wenn man Module dran hängen hat. 
Aber ich habe ja auch geschrieben, um ihn als günstigen und guten 
Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) 
Der beliebte Chinawechselrichter GTIL SUN-1000 bewegt sich auch in der 
Preisspanne des HM-800, allerdings ist der Wirkungsgrad davon schlecht 
und die Leistungssteuerung muss man sich auch mehr oder weniger selbst 
zusammen basteln mit z.B. elektronischen Poti. Noch dazu hat das Ding 
einen Lüfter der recht laut wird bei 1000W, hängt aber wohl damit 
zusammen, das die recht hohe Verlustleistung ja irgendwie gekühlt werden 
muss. Ein Victron Wechselrichter übersteigt die Kosten enorm und ist 
auch viel zu viel Leistung um die Grundlast über die ca. 10 Stunden 
Nacht zu decken. Lastspitzen lohnen sich nie die ausgleichen zu können, 
mit denen muss man leben, das darf ruhig der Stromanbiete rübernehmen, 
ist einfach am billigsten und macht Insgesamt nur einen kleinen Anteil 
der Autarkie aus.
Das ich den HM-800 nicht permanent mit 800W betreiben sollte ist mir 
klar, aber darum möchte ich ihn ja auch begrenzen und um halt dynamisch 
die Grundlast nachts zu decken, die keine 800W beträgt.
Böse Zungen würden jetzt sagen, das Netz ist der beste Speicher, das ist 
aber illegal und nur mit einem rückwärtsdrehendem Ferraiszähler möglich.
Ich und viele andere haben bereits einen digitalen Zweirichtungszähler 
verbaut und der wird nach und nach bei allen kommen...
Und ja, eine EIGENBAU PV-Anlage mit Batteriespeicher lohnt sich, aber es 
dauert natürlich ca. doppelt so lange bis die Investition wieder rein 
ist gegenüber nur Module + nötiges Zubehör. Einen Fertigspeicher oder am 
besten noch PV-Anlage montieren lassen würde ich auch nicht, da dauert 
es mal ebend locker 15+ Jahre bis das wieder rein ist, da die Kosten 
deutlich höher sind. Mit meinem Eigenbauprojekt komme ich auf knapp 6 
Jahre(bei steigenden Strompreise, wovon auszugehen ist, noch eher und 
bevor die Kritiker kommen: gute LiFePo4-Akkus halten noch ein paar Jahre 
länger, wenn man die richtig betreibt). Ja ist eine ganze Weile, aber 
was will man machen, mehr Wp und Einspeisen rechnet sich noch weniger, 
davon holt man die Nacht auch nicht rein und auf die Bürokratie habe ich 
auch keine Lust...
Außerdem selbst wenn man nach 6 Jahren rechnerisch bei +-0 ist, hat man 
immernoch die Hardware(Panel, Wechselrichter, Laderegler, Akku mit 
Restkapazität ...), die einen Restwert hat, beim Stromanbieter sieht man 
von seinem Geld nichts mehr wieder, das hat mich überzeugt, dieses 
Projekt zu starten. Warnung: PV macht süchtig! :D ...alles beginnt mit 
einem einfachen Balkonkraftwerk und nach dem ersten Jahr will man mehr.

Aber zurück zum Thema:
In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure 
Daten rankommt, aber leider auch nicht identisch ist), sind Register zu 
sehen, die dafür zuständig sind: 
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über 
ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit 
dem Protokoll zum WR aussieht, aber es muss ja alles über NRF 
funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70% 
Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in 
jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer 
wieder zyklisch das aktuelle Limit geschrieben.
Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur 
da das möglich bzw. freigegeben ist.

Grüße

[Manuel M. (petrosiliuszwackelm)]

Ich konnte der (esp8266) Anleitung sehr gut folgen und kann seit heute 
meinen HM-800 auslesen. Super wie schnell dies hier entwickelt wurde!

Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry 
über MQTT.

Mir sind zwei Dinge aufgefallen:
1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche 
Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel 
vom Wert des 2. Channels sofort überschrieben.

2) In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay 
angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der 
Channels.
Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler 
wenn dieser Wert direkt angezeigt wird.

Gruß Manuel

[Lukas P. (lumapu)]

IsnoAhoy schrieb:
> Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je
> nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN
> Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet.

Im Prinzip ist alles gleich, nur dass im AP Modus standardmäßig auf die 
Setup Seite verwiesen wird.
Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem 
WLAN zu verbinden.
Achtung, einige Einstellungen gehen beim Upgrade verloren, das wurde 
noch nicht bearbeitet. Changelog = Git-Log 
(https://github.com/grindylow/ahoy/commits/main)

Wie gewünscht sind jetzt alle Einstellungen, die zur Kompilierzeit 
gemacht werden können in einer config.h

Manuel M. schrieb:
> In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay
> angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der
> Channels.

Sehr schön, dass es auf Anhieb geklappt hat. Ich verwende ioBroker als 
MQTT Server, dieser erstellt dann "Unterordner" da jedes Topic mit 
Slashes getrennt geschickt wird, z.B.:
/inverter/hm1200/ch1/u_dc
/inverter/hm1200/ch2/u_dc
...
Bei mir wird hierdurch nichts überschrieben, da alles eindeutig und 
unique ist.

> Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler
> wenn dieser Wert direkt angezeigt wird.

Die Summe lässt sich recht einfach bilden, indem du in der hmDefines.h 
für den HM800 folgende beiden Zeilen hinzufügst (kopiert vom HM1200):

{ FLD_YD,  UNIT_WH,  CH0, CMDFF, CALC_YD_CH0,   0, 0 },
{ FLD_YT,  UNIT_KWH, CH0, CMDFF, CALC_YT_CH0,   0, 0 },

Andi schrieb:
> Aber ich habe ja auch geschrieben, um ihn als günstigen und guten
> Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt)

Tolles Thema, gibt es hierzu auch ein Forum? Bin auch interessiert an 
einer Selbstbau-Speicherlösung. Wäre super wenn man hier eine ähnliche 
Community hätte wie diese hier, wobei bei Geschwindigkeit kann uns hier 
keiner was vormachen! ;-)

[Robert S. (Gast)]

Lukas P. schrieb:
> Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem
> WLAN zu verbinden.

Super, wie schnell die Entwicklung voranschreitet!
Habe die neue Version gleich installiert :-P
Ist leider in mehreren Versuchen nur jeweils wenige Minuten erreichbar,
WIFI wurde nur einmal aut. restarted.
Nach welchem Zeitraum sollte das WIFI neustarten, muss ich länger 
warten?
Ausserdem ist mir aufgefallen, dass nach dem aut. restart die MQTT
Verbindung nicht mehr connected war. Wird die auch restarted?

SG
Robert

[Martin G. (petersilie)]

Herbert K. schrieb:
> martin schrieb:
>> Herbert K. schrieb:
> ...
>> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
>> handelt, der einen eigenen Controller drin hat.
> ...
> Entschuldigung !  Daran hatte ich nicht mehr gedacht.

Hatte schonmal jemand den Mut, seinen WR aufzuschrauben? Mit etwas Glück 
ist ja darin direkt ein NRF24L01+ verbaut anstelle des NRF24LE1E?

[Manuel M. (petrosiliuszwackelm)]

Lukas P. schrieb:
> { FLD_YD,  UNIT_WH,  CH0, CMDFF, CALC_YD_CH0,   0, 0 },
> { FLD_YT,  UNIT_KWH, CH0, CMDFF, CALC_YT_CH0,   0, 0 },

Danke - das klappt so - kann man das in der hmDefines.h
für den HM800 so einchecken?

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
>
> Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus
> dem HM600 raus geholt.
>
> Request 80 02 + time
> [code]
....
04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c
....
> Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche
> Transaktionen mit valider crc über die 140 byte. Viel Spaß beim
> dechiffrieren *duckundweg
> Gruß,
> Jan

Hallo Jan, kann ich so bestätigen für HM-350/HM-400.
Telegramm "04" sieht bei einem von meinen identisch aus.
Telegramm "89" sieht bei einem von meinen anders aus bei einigen Bytes, 
einige sind identisch.
Mehr habe ich noch nicht verglichen. Was auch immer das bedeutet. Ich 
lass das mal ne Zeit mitlaufen, ob sich da Werte ändern.

[Damian B. (damian_b)]

Hallo,
Ich entschuldige mich für meinen deutschen Übersetzer

Ich möchte einen externen MQTT-Server verwenden, jetzt kann ich die 
IP-Adresse angeben (1.2.3.4), kann ich Unterstützung für Hostnamen 
hinzufügen?

[franz (Gast)]

Jan-Jonas S. schrieb:
> Im Wesentlichen senden die Wechselrichter halt größere Payloads über
> mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die
> längste Payload, die ich von einem HM600 empfangen habe ist 140 byte
> lang. Da die crc stimmt, confirmed.
> Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt
> in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich
> einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten.

ja, das ist sicher so, nur bei meinen kleinen 3xx geht/ginge sich alles 
in je einem Paket aus. Allerdings ist die python version schon so 
schlau, alle Antworten einer Sendung einzusammeln und dann 
hintereinander zu verarbeiten, somit konnte ich einbauen, mit globalen 
Variablen Daten zwischen 2 Fragmenten auszutauschen, ob es funktioniert, 
kann ich mangels entsprechender WR nicht testen. Ich nehme an, beim 
HM-600 ist das highword von total power 1 in 0x02 das letzte Word in 
0x01, das das schon aufgetreten?

Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das 
letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich alles 
im 2. ausgehen, ist aber geteilt.

Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder 
konstant oder springen. Ich erwische aber jedenfalls auch nicht alle 
Pakete, auch wenn ich 10 Sekunden Pause mache. Zumindest in 87% der 
Fälle wo ich die Antwort erwische, habe ich beide, so ich mit 40 sende. 
Bei 23 als Sendechannel ist es bei mir um 25% besser, allerdings 
erwische ich da ingesamt auch nur auf 40% der Sendungen eine Antwort, 
wobei auch wieder fast alle auf je 2 channels kommen (40 ->3,75, 23-> 
61,75). Den in einem C source aufgeführten Channel 83 habe ich noch nie 
gesehen, in der DTU-W100 Doku für MI-... steht aber auch nur von 5 und 
nicht 6 Channels.

Habe die von lbp beschriebene Logik zum Holen der Pakete 
nachimplementiert, war aber bei mir auch nicht besser. Ich denke auch, 
dass auf dem Channel für weitere Pakete bleiben wie zZ implementiert gar 
nicht zielführend ist, da nicht nach x-Paketen die Suche beendet wird, 
greift der Algorithmus aber sowieso zwischen Versendungen nicht. Auch 
aus Sicht des WR wäre es unklug alles auf je einen Channel zu setzen.

Seine Beschreibung zum Nachfordern habe ich noch nicht versucht, diese 
Sonnenabhängigkeit ist eine echte Programmierbehinderung :-)

lg,
Franz

[Petra R. (petra-kathi)]

Hallo zusammen,

ich habe in den letzten Tagen Martin G.'s Raspi-Programm ahoy.py für den 
HM-1500 adaptiert und die (ich meine, auch von ihm) als Farbgrafik 
gepostete Feldbedeutung der CMDs durchgesehen und in Teilen ein wenig 
nachkorrigiert. Jetzt sind die Ausgaben jedenfalls stimmig und für mich 
mit meiner PV-Paneel-Anordnung nachvollziehbar. (Ich habe 4 180 W 
bp-Solar Paneele auf dem Balkon liegen.)

Um einen besseren Überblick über noch nicht zuweisbare Feldeinträge aus 
den Commands (1, 2, 3, 132 - was Anderes scheint's beim HM-1500 nicht zu 
geben) zu bekommen, habe ich das Logging zwecks visueller Inspektion ein 
wenig umgestellt und die Variablen anders benannt. Alle Änderungen 
beziehen sich auf die Subroutine on_receive(), die ich in der neuen Form 
als Anhang dranhänge.

Die sich durchaus stark ändernden Blöcke des 132er Commands scheinen 
wesentlich mit der Verfügbarkeit des AC-Anschlusses zu tun zu haben. Um 
das zu untersuchen, habe ich den HM-1500 mal stromlos geschaltet und 
dann wieder eingestöpselt (entspricht ja einem Stromausfall). Die 
kondensierte Logdatei hängt dazu ebenfalls an.

Meine Schlüsse daraus:

- Die Variable uk_132_1 korreliert mit einer bemerkten AC-Frequenz
- Die Variable uk_132_2 korreliert mit der Stromabgabe

Weiter bin ich allerdings leider noch nicht vorgedrungen.

Aber vielleicht finden ja einige Gurus hier noch was dazu raus ...  ;-)

Viele Grüße,
Petra

[Petra R. (petra-kathi)]

Nachtrag:

- Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des 
Wechselrichters.

[Mc_K (Gast)]

Einen Wunderschönen guten Tag,

da ich so gut es geht vermeiden will, mit China-Servern verbunden zu 
sein, bin ich auf das Forum gestoßen und bin Erstaunt darüber, was 
bereits zustande gekommen ist. Applaus dafür!
War beim lesen der Postings schon nervös, ob dieses Projekt überhaupt 
was wird. (Beim Thema sniffen der internen Kommunikation der DTU-W100).

In den nächsten Tagen bekomme ich einen HM-1500 und 4x 450Wp Panele, die 
ich unbedingt begrenzen möchte. Im Idealfall mit Zero-Export-Funktion. 
(Mir ist bewusst dass hierzu zusätzliche Messinstrumente usw. 
installiert werden müssten)
Die Drosselung des Inverters auf fixe Maximalwerte, wird wohl etwas 
einfacher zu realisieren sein.
Beispiel:
Geringer Eigenverbrauch = Inverter auf 50%
Höherer Verbrauch = Inverter auf 90%

Es gibt auch Möglichkeiten in Form von Zuschaltung zusätzlicher 
Verbraucher.

Habe einige ESP32, ESP8266 und Gosund(Tasmota) Steckdosen zuhause. 
NRF24L01+ sind auch bestellt.

Nach inbetriebnahme kann icht gerne auch Daten beisteuern.
Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu 
unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion 
zu "entschlüsseln".

Fragen:
Habe zu diesem Thema nichts gelesen (möglicherweise überlesen):

Wenn die Inverter/DTUs ausgeliefert werden, sind sie ja auf einer 
bestimmten FW, die vermutlich übers Internet upgedatet werden kann.
Kann es sein, dass das Verhalten der Kommunikation je nach FW anders 
ist?
Dann müssten wir am besten alle auf der selben FW sein um 
weiterzukommen..

Besteht bzw. wie hoch ist die Gefahr, dass Hoymiles die Inverter und 
DTUs updatet und verschlüsselt, wenn man sich zu ihren Servern 
verbinden?

Sollte ich mir vorbeugend jetzt schon einen weiteren HM1500 für eine 
Zukünftige Erweiterung besorgen?
Gehe davon aus, dass Hoymiles die Geräte durch weitere 
Hardware/Softwareeingriffe noch "sicherer" machen werden und die 
Inverter in Zukunft keine Seemanssprache verstehen.

(Siehe Playstation 4 Jailbreaks)

Freue mich darauf, eure Meinungen zu hören.

[Damian B. (damian_b)]

Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie
Hat die HMT-Serie ein geändertes Protokoll?


Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern: 
HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500  1200-4T HMS-1000  
900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.

[Sorbit (Gast)]

Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist.
Hoymiles 1200.

[IsnoAhoy (Gast)]

Hallo Franz,

> Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das
> letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich
> alles im 2. ausgehen, ist aber geteilt.
>
> Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder
> konstant oder springen.

Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD 
genannt wird/wurde.
Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y 
gesetzt, also das höchstwertige Bit 8 wird gesetzt.
Bei zwei Paketen also 0x01, 0x82
Bei drei Paketen 0x01, 0x02, 0x83
Und bei vier 0x01, 0x02, 0x03, 0x84
etc pp

Die CRC8 der Pakete sind jeweils die letzten Bytes vor 0x7F
Und die CRC_M/CRC16 sind die letzten beiden Bytes vor dem CRC8 des 0x8y 
Pakets.

Wie Jan Jonas schon schrieb wäre es sinnvoll statt von CMD von einem 
Paket Counter zu sprechen, dessen höchstwertiges Bit 8 gleichzeitig als 
Nachrichtende Flag dient

[Jan-Jonas S. (janjonas_s)]

Python voraus!

ich habe heute mal einen weiteren riesigen Dev-Snapshot gepushed.

ahoy.py implementiert jetzt
 - Multi-Inverter
 - Transport-Layer und Retransmits von verlorenen Frames
 - Full Payload Decode mit Device- und Request- abhändigen Decodern
 - Dynamisches mqtt-publishen, jenachdem wieviel Phasen/Strings

TBD:
 - mehr als nur den HM-600 supporten
 - code cleanup
 - irgendwie noch eine Strategie für Struktur der Decoder einfallen 
lassen

Ist halt noch ein PoC und enthält mit Sicherheit Fehler.

Hier: https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi

Das mit den Retransmits sieht dann so aus:

2022-05-05 18:46:56.432521 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 73 ff 7e 00 00 00 05 00 00 00 00 59 ad e5
2022-05-05 18:46:56.525429 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 e4
2022-05-05 18:46:56.579134 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 0f 03 e8 00 f5 00 2a 6b f2 b4
Error while retrieving data: Frame 1 missing: Request Retransmit
2022-05-05 18:46:57.083093 Transmit 11 | 15 72 22 01 43 78 56 34 12 81 8e
2022-05-05 18:46:57.137897 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 86
2022-05-05 18:46:57.641794 Payload: 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 00 00 00 0f 03 e8 00 f5 00 2a 6b f2
2022-05-05 18:46:57.641794 Decoded: 24.5 phase0=voltage:227.5, current:1.5, power:33.7, frequency:49.98 string0=voltage:31.5, current:0.55, power:17.5, total:41.482, daily:1595 string1=voltage:31.5, current:0.57, power:17.8, total:39.191, daily:1600

Gruß,
Jan

[Peter L. (leliep)]

Sorbit schrieb:
> Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist.
> Hoymiles 1200.

Das kann ich bestätigen. HM-1200 mit AHOY 0.3.6

[Hans W. (hans_w801)]

Servus,

habe das ganze jetzt auch laufen. MQTT Broker läuft in Home Assistant.
Emfange damit auch alle anderen Geräte, die über das MQTT Protokoll 
senden.

Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected 
ist.

CMDs:
0x1: 97
0x2: 193
0x3: 145
0x81: 0
0x82: 0
0x83: 0
0x84: 65
other: 0

Send Cnt: 245

MQTT: connected

Kann ich das irgendwie anders prüfen ?

[Robert S. (Gast)]

Hans W. schrieb:
> Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected
> ist.

Hast schon mit einem MQTT Sniffer die Topics geprüft?
Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem //

SGR

[Hans W. (hans_w801)]

Robert S. schrieb:
> Hast schon mit einem MQTT Sniffer die Topics geprüft?
> Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem //

hab das ganze mal mit iobroker versucht und da wird ein ganzer 
Ordnerstamm erstellt. Scheint also an Home Assistant zu liegen...

Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( 
/inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA.
Aber das kommt dann im Sekundentakt rein.

Muss ich wohl noch ein wenig suchen, woran es das liegt im HA.

ESP-DTU funktioniert also !!! Top !!!

[Robert S. (Gast)]

Hans W. schrieb:
> Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde (
> /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA.
> Aber das kommt dann im Sekundentakt rein.
>
> Muss ich wohl noch ein wenig suchen, woran es das liegt im HA.

Ich habe bei mir folgendes in der configuration.yaml:

 - platform: mqtt
   state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal"
   name: "Gesamtproduktion PV-Gartenhaus"
   device_class: energy
   unit_of_measurement: "kWh"

Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein

   value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | 
float) | round(2)) }}"

will einfach nicht funktionieren.

[Lukas P. (lumapu)]

Sorbit schrieb:
> Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist.
> Hoymiles 1200.

Kann mir vorstellen, dass das an den MPPT Reglern liegt. Der HM1200 hat 
nur zwei, also sind je zwei Anschlüsse parallel geschaltet. Hier 
entsteht wahrscheinlich ein geringer Fehler beim messen.
Die Spannung wird übertragen, da es für den WR nur 2 DC Spannungen gibt.


Petra R. schrieb:
> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des
> Wechselrichters.

Das ist kein Last-%-Grad, sondern der Power-Factor. 
https://de.wikipedia.org/wiki/Leistungsfaktor


Jan-Jonas S. schrieb:
> Transport-Layer und Retransmits von verlorenen Frames

Lohnt es sich das Re-Transmit der Pakete zu implementieren? Aktuell ist 
meine Statistik fast jeden Tag gleich von der Verteilung her. Ich frage, 
da es ja noch nicht so genau bekannt ist, welche Sendekanäle der WR 
wirklich benutzt. Hat jemand schon mal eine DTU beim Re-Transmit 
erwischt?

CMDs:
0x1: 3617
0x2: 11571
0x3: 9310
0x81: 0
0x82: 0
0x83: 0
0x84: 4332
other: 0

Send Cnt: 20883

[franz (Gast)]

Hallo IsnoAhoy

IsnoAhoy schrieb:
> Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD
> genannt wird/wurde.
> Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y
> gesetzt, also das höchstwertige Bit 8 wird gesetzt.
> Bei zwei Paketen also 0x01, 0x82

ja, dass die "cmd" paketzaehler sind ist mir klar, dass das leftmost bit 
die endmarkierung ist, leuchtet mir jetzt auch ein. Ich hatte 
fälschlicherweise geglaubt, dass es bei anderen Modellen sowas wie 
anfragenübergreifende Nachrichtenzähler gibt den meine einfachen 3xx 
inverter mit 112174.. nicht haben - obwohl ich sie beim Zusammensuchen 
der dortigen Felder nicht gesehen hatte. Als ich mit anderen 
Sendekombinationen experimentiert hatte, war ich bis (durchgängig) 7 
gekommen, allerdings habe ich das 0x88er dann wohl immer verpasst.

Fast schade, dass ich Dienstag soviel Zeit hatte andere Modelle 
dazuzusuchen und die Struktur anzupassen (z.B. 3 mal umüberlegt ob mit 0 
oder 1 bei DC zu starten, in der micro version ist es ja 1), immerhin 
habe ich nur heute abend ein wenig erfolglos refetching probiert.

Ich habe mir aber als ich es merkte gleich Jans neue Version geholt.
Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein 
Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-(

lg,
Franz

[Sorbit (Gast)]

Kann ich mit Daten aus meinem HM1200 helfen?
Wenn ja, welche werden benötigt?

[Hans W. (hans_w801)]

Robert S. schrieb:
> Ich habe bei mir folgendes in der configuration.yaml:
>
>  - platform: mqtt
>    state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal"
>    name: "Gesamtproduktion PV-Gartenhaus"
>    device_class: energy
>    unit_of_measurement: "kWh"
>
> Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein
>
>    value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' |
> float) | round(2)) }}"
>
> will einfach nicht funktionieren.

ich hab es jetzt mal so eingetragen. Morgen sehen wir weiter.

- platform: mqtt
    state_topic: "/inverter/hm1500/ch0/YieldTotal"
    name: "Gesamtproduktion PV-Gartenhaus"
    device_class: energy
    unit_of_measurement: "kWh"
    value_template: >
        {{value|round(2)}}
    state_class: total_increasing
    unique_id: "pv_gartenhaus_total"
    last_reset_topic: "/inverter/hm1500/ch0/YieldTotal"
    last_reset_value_template: "1970-01-01T00:00:00+00:00"

[Petra R. (petra-kathi)]

Lukas P. schrieb:
>> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des
>> Wechselrichters.
>
> Das ist kein Last-%-Grad, sondern der Power-Factor.
> https://de.wikipedia.org/wiki/Leistungsfaktor

Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" 
getaufte Variable (Werte typisch bei 980 => 0,98) meintest?

Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" 
(oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und 
"uk_132_4" (wild im einige Zehntausenderbereich schwankend).

Any ideas?

Tschüssi,
Petra

[Thomas B. (tbnobody)]

Petra R. schrieb:
> Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2"
> getaufte Variable (Werte typisch bei 980 => 0,98) meintest?
>
> Blieben vor allem noch die Interpretationen der Werte von "uk_132_1"
> (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und
> "uk_132_4" (wild im einige Zehntausenderbereich schwankend).
>
> Any ideas?

Hallo Petra,

ich kann bestätigen, uk_132_2 verläuft nahezu genauso wie der 
Leistungsfaktor den meine Gosund Zwischensteckdose ausgibt. Dies ist 
auch so bei [1] und [2] implementiert.

Was Jan herausgefunden hat steht im letzten empfangenen Paket (also das 
mit 0x8*) in den letzten beiden Bytes (bei dir uk_132_4) der CRC über 
die gesamte Payload. Dies ist auch in seiner Implementierung so 
umgesetzt.

Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl 
0x00 0x07

Dein uk_132_1 konnte ich hier ebenfalls noch nicht zuordnen.


[1] 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h
[2] 
https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py


Güße
Thomas

[Jan-Jonas S. (janjonas_s)]

franz schrieb:
> Ich habe mir aber als ich es merkte gleich Jans neue Version geholt.
> Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein
> Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-(

Sehr schön :)

Übrigens kann man mit dem python-Modul auch "offline" debuggen
[code]
root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hoymiles
>>> response = bytes.fromhex("00 01 01 3b 00 03 00 0b 01 3c 00 04 00 0d 00 00 a2 
16 00 00 99 24 06 47 06 4d 08 dc 13 8a 00 00 00 00 00 00 00 00 00 d8 00 5a b1 89")
>>> hoymiles.decoders.HM600_Decode0B(response).__dict__()
{'phases': [{'voltage': 226.8, 'current': 0.0, 'power': 0.0}], 
'strings': [{'voltage': 31.5, 'current': 0.03, 'power': 1.1, 
'energy_total': 41494, 'energy_daily': 1607}, {'voltage': 31.6, 
'current': 0.04, 'power': 1.3, 'energy_total': 39204, 'energy_daily': 
1613}], 'temperature': 21.6, 'frequency': 50.02}
>>>
[code]

Die response ist dabei eine komplette Payload, wie sie in meinem obigen 
Logauszug zum retransmit-Beispiel zu finden ist.

Die Decoder sind Klassen in hoymiles/decoders/__init__.py

class {model}_Decoder{req_cmd}(AntwortTypElternklasse)
also
HM600_Decoder0B(StatusResponse)
Bisher gibts 2 Hautklassen UnknownResponse und StatusResponse
StatusResponse ist hauptsächlich für die 0b-Werte zu verwenden und 
stellt den __dict__() accessor bereit.

Dann muss man noch in der ResponseDecoderFactory-Klasse in 
hoymiles/__init__.py die ser_db um die Seriennummern-Maske erweitern, 
wenn die Liste das gewünschte Modell bisher nicht abdeckt.

Wie gesagt, die Struktur ändert sich wohl noch. Das hab ich jetzt alles 
schnell um den eigentlichen Transport-Layer drumrum gehackt.

Teaser:
Es gibt dann schon eine Vorbereitung für einen command_queue, um später 
auch WR per mqtt steuern zu können.

Bei mir geht übrigens ein Interval von 4 Sekunden. Bei mehreren WR würde 
ich sagen interval + 5s für jeden WR.

Nachtabregelung muss noch implementiert werden. Ich würde das aber 
lieber an Anzahl TX ohne Antwort binden statt an Uhrzeiten. Also wenn 
nach 30 Anfragen keine Antwort, interval auf 5 Minuten oder so.

Jede Payload wird im Übrigen bis zu 4x je interval wiederholt, wenn 
keine Antwort kommt. Das ist Absicht, brauchen wir spätestens wenn wir 
steuern wollen und außerdem will ich meine Antworten garantiert 
innerhalb des interval bekommen.

[Petra R. (petra-kathi)]

Hi Thomas,

> Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl
> 0x00 0x07

Da kommen bei mir aktuell häufig Werte 11 und 12.

Vielleicht kann ja mal ein DTU-behafteter Kollege nachschauen, welche 
Werte man über die bereits zuweisbaren hinaus als Information abfragen 
kann?

Tschüssi,
Petra

[Ha F. (harry_f)]

Hallo bin neu hier. Habe heute meine Hardware bekommen:
NodeMCU + NRF24L01.
Compilieren, Upload und Config hat funktioniert.
Daten vom HM600 bekomme ich noch keine, evtl. bin ich zu weit weg.
NRF24L01 wird erkannt, MQTT ist connected (IoBroker).

Folgendes ist mir aber bis jetzt aufgefallen:

Nach einem Reboot klappt scheinbar die NTP-Abfrage nicht immer. In der 
seriellen Console steht oft [NTP]: 1970-00-00+00:00:00, selten das 
korrekte Datum/Uhrzeit.

Im WebIf steht immer 1970-00-00+00:00:00.
Habe den Timerserver auch schon auf fritz.box geändert, bringt nichts.
Evtl ist die Abfrage ja zu schnell nach dem Wifi-Connect.

Update:  Die ersten Daten sind angekommen.
Wenn ich mit irgendwelchen Rohdaten helfen kann, bitte melden.

[IsnoAhoy (Gast)]

Hallo Harry F.
Daten bekommst Du erst wenn Du die Seriennummer im Setup eingetragen 
hast. Das sollte selbst ohne WLAN Verbindung zum NTP server 
funktionieren.
Ich weiss aber nicht ob der WR auf Epoch 1970-01-01 reagiert, die 
Anfrage für die Statusdaten ist ja im Prinzip das Zeit setzen Kommando.
Was sagt er denn bzgl RF24 und Anschlüssen. Irgendjemand hat auch hier 
oder im github unter Issues gemeldet dass die IRQ Leitung nicht an allen 
/ beliebigen ESP8266 Anschlüssen funktioniert. Der Anschluss muss 
Interrupt fähig sein.
Mit besten Grüßen
Stefan

[H. E. (h_e)]

Hallo zusammen,

erst mal tausend Dank für die super Arbeit die ihr bisher gemacht habt. 
Der ganze Thread liest sich echt wie ein Krimi. Ich habe einen HM600 mit 
zwei Modulen und heute mal den Lötkolben angeschmissen und das ganze auf 
einem Wemos D1 Mini zum laufen gebracht.

Wenn ich die Statistik-Werte mit den anderen hier geposteten vergleiche, 
kommt es mir so vor, als würden bei mir deutlich weniger Pakete 
ankommen. Mein ESP6288 ist nur ca. 2m vom WR entfernt. Ist bei meinem 
Setup irgendwas schief gelaufen oder ist das im Rahmen?

Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast 
doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen 
erzeugt worden.

[IsnoAhoy (Gast)]

Hallo Lukas,

habe gerade mal nachgesehen mein ESP8266 (v0.3.6) hatte vor 2:15h wohl 
einen Reset. Das Datum steht immer noch auf 1970 aber er zeigt Werte 
(Temperatur, Yield Total, Spannung, Strom, etc.) an und ist auch per 
WLAN Router erreichbar. D.h. nach erfolgreicher Verbindung mit dem WLAN 
Router erfolgt kein erneuter NTP Abgleich.

[Herbert K. (avr-herbi)]

H. E. schrieb:
...
> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast
> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen
> erzeugt worden.
Wieso ist Dein HM600 auf 72% abgeregelt ?  Absicht ?  Nicht bemerkt ?

292,70 + 290,80 = 583,50 P_DC
583,50 P_DC /// 420,00 P_AC --->  72% ?

Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%

[Chris (Gast)]

Hallo und danke an alle die hier so tolle Arbeit leisten! Auch ich habe 
heute meine Anlage bekommen (HM-1500) und habe die ersten Daten 
empfangen. Allerdings war das erste NRF24 Modul defekt. Erst nach dem 
Austausch lief alles. Aber dann wirklich wunderbar. Die Daten sind 
plausibel und die Pakete kommen in hoher Anzahl. Auch mit einer 
Entfernung von aktuell ca. 6-7m.

Hab den MQTT Client in FHEM eingebunden. Daten kommen sauber rüber. 
Allerdings wird der Client nach jedem Neustart als neues Device erkannt. 
Könnte da noch etwas angepasst werden? Ich hab die AHOY:0.3.2 auf einem 
NodeMCU. Könnte der
Device Host Name genutzt werden?

[H. E. (h_e)]

Herbert K. schrieb:
> H. E. schrieb:
> ...
>> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast
>> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen
>> erzeugt worden.
> Wieso ist Dein HM600 auf 72% abgeregelt ?  Absicht ?  Nicht bemerkt ?
>
> 292,70 + 290,80 = 583,50 P_DC
> 583,50 P_DC /// 420,00 P_AC --->  72% ?
>
> Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%

Ne, abgeriegelt habe ich nichts. Ich habe auch keine DTU mit der ich das 
tun könnte. Ich glaube das liegt daran, dass die Daten der beiden 
Channel nicht synchron mit den oberen Daten sind. Die Daten dort sind 
auch lange auf 0 stehen geblieben (außer YieldDay), bis dann nach ca. 
einer Stunde das erste 0x1 Signal kam. Läuft also noch nicht so rund bei 
mir.

[Jan-Jonas S. (janjonas_s)]

Hallo,

habe gerade meine Python-Implementierung [1] nochmal gepusht.

Hinzugekommen sind:
  * Support für den HM-1500
  * Mqtt {topic}/command payload-relay
  * Default decoder zur einfacheren Protokollanalyse

$ mosquitto_pub -t hoymiles/11417/command -m 800b00tttttttt0000000500000000

Injiziert z.B. ein Zeit-Setzen-Kommando. tttttttt ist eine Variable für 
die Zeit. So kann man sehr einfach und zur Laufzeit neue Payloads 
ausprobieren.

Gruß,
Jan

[1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi

[Jan-Jonas S. (janjonas_s)]

H. E. schrieb:
> Herbert K. schrieb:
>> Wieso ist Dein HM600 auf 72% abgeregelt ?  Absicht ?  Nicht bemerkt ?
>
> Channel nicht synchron mit den oberen Daten sind.

Genau, weil es keine "channel" gibt. Das passiert, wenn man 
Datenfragmente die zu unterschiedlichen Zeitpunkten "aus dem Kontext 
gerissen" wurden korelliert.

Bei einer Abregelung sinken zwingend DC und AC-Werte um die gleiche 
Summe.
Blieben die DC-Werte hoch würde der WR massiv Energie vernichten müssen. 
Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung 
einfach der falschen Datenerhebung geschuldet und wenn mans richtig 
machen würde, wie es aktuell das Python-Ding tut, ist das der 
Wirkungsgrad des WR. Unabhängig von der Abregelung.

[Lukas P. (lumapu)]

Hallo Jan-Jonas

ich finde es toll mit welchem Elan du an die Sache dann gehst. Echt 
schön zu sehen, dass auch andere viel Zeit investieren.

> Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung
> einfach der falschen Datenerhebung geschuldet und wenn mans richtig
> machen würde, wie es aktuell das Python-Ding tut, ist das der
> Wirkungsgrad des WR. Unabhängig von der Abregelung.

Allerdings finde ich hast du dich hier im Ton vergriffen. Ich fühle mich 
in keinem Wettbewerb und ich will schon gar keine zwei Lager bilden. 
Bitte lass uns weiterhin an einem Strang ziehen. Jeder kann per PR 
beitragen. Die aktuelle Implementierung ist bei allen noch ein PoC oder? 
Es gibt noch kein richtig oder falsch sondern eher Fortschritte. Die 
Version des ESP8266 ist halt Stand heute nicht mehr 'up to date'.

[Hans W. (hans_w801)]

Guten Morgen,

soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr 
zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum 
MQTT Broker. z.B. bei mir gestern um 16 Uhr.

Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine 
Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den 
Logs.

Also ESP reboot und dann ist er sofort wieder connected.

Sonst noch jemand Probleme mit MQTT ?

[Lukas P. (lumapu)]

Wir diskutieren schon länger auf github über Stabilität.
https://github.com/grindylow/ahoy/issues

MQTT läuft bei mir stabil, hatte vor 20h den letzten Komplettabsturz, 
danach hat alles von selbst wieder funktioniert. (Version 0.3.6)

[H. E. (h_e)]

Hans W. schrieb:
> Guten Morgen,
> soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr
> zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum
> MQTT Broker. z.B. bei mir gestern um 16 Uhr.
> Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine
> Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den
> Logs.
> Also ESP reboot und dann ist er sofort wieder connected.
> Sonst noch jemand Probleme mit MQTT ?

Bei mir selbiges. Das Wlan läuft stabil, aber der MQTT-Client schließt 
die Verbindung und macht sie nicht wieder neu auf.

[Robert S. (Gast)]

Mein Wemos D1 mini mit 0.3.6 läuft leider gar nicht stabil. Die Uptime 
ist selten höher als 1 Stunde, die automatischen reboots dauern oft sehr 
lange oder vielleicht findet er auch keine SSID oder DHCP. Jedenfalls 
habe ich in der Statistik manchmal stundenlange Lücken. Vermutlich auch 
deshalb weil er nur ca. jedes zweite Mal den MQTT connected. Die onboard 
LED blinkt übrigens unregelmäßig, weist das auf Ausfälle hin?

WIFI Probleme glaube ich eher nicht, RSSI ist bei ca. -70dbM,
andere ESP8266 in der Nähe funktionieren ohne Probleme.
Kann es sein dass das NRF Modul stört, es sendet und empfängt ja auf 
derselben Frequenz. Das NRF-Modul scheint recht stabil zu sein, der WR 
ist durch ein Fenster mit Jalousie und dann noch ca. 20m Luftlinie 
entfernt.

Wäre es möglich den WIFI-RSSI auf der Webpage anzuzeigen oder via MQTT 
zu publishen? Damit könnten wir schlechte Verbindungen leichter 
erkennen.

[Hans W. (hans_w801)]

Also heute ist es wie gestern ... um 16 Uhr MQTT Abbruch aber der Wemos 
ist noch up

[isnoAhoy (Gast)]

Hallo Zusammen,

ich habe heute mal versucht den HM-600 aufzuschrauben. Leider habe ich 
ihn nicht komplett aufbekommen. Ich vermute daß man irgendwie die 
Kabelzugentlastungen lösen muß und evtl. auch noch mit etwas Wärme aus 
einem Heißluft-/-fön die Dichtungen lösen muß. Das habe ich meinem neuen 
Geräte dann doch nicht alles zumuten wollen, es soll ja nachher wieder 
wasserdicht und möglichst lange seinen Dienst verrichten.

Vielleicht hat ja jemand einen gebrauchten, defekten HM den er mal zu 
Anschauungszwecken defilieren kann ?

@Jan-Jonas, ich habe Deine Paketanalyse mal nachvollzogen. M.E. hast Du 
Recht mit dem Paketzähler und dem höchstwertigen Bit 0x8y das das letzte 
Paket oder eben die Anforderung für einen Request (vielleicht sogar 
einen Retransmit) bedeutet.

Ich habe die Ergebnisse dieser Paketanalyse vorläufig hier im Github 
Issue dokumentiert, das kann man ggf. auch in die hoymiles Doku 
aufnehmen.
https://github.com/grindylow/ahoy/issues/24

Hat das (so einen Retransmit oder die Spezialanfrage mit X Paketen von 
Jan Jonas) bei den auf Seite 1 & 2 gemachten HackRF und anderen 
Funkprotokollmitschnitten der Original DTU auch sonst noch jemand 
feststellen können ? Vielleicht können ja noch ein paar alte Hasen (die 
schon vor Ostern hier geforscht haben) hierzu etwas beitragen ?

[Lukas P. (lumapu)]

lpb schrieb:
> Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das
> Anfordern eines nicht erhaltenen Pakets.
> Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket
> anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'.

@isnoAhoy
Hier wurden die Retransmits bereits im DTU Log gefunden.

Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal 
die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein 
Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die 
Statistiken, also die Counter wie oft welches Paket kam.
"CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x 
0x84

Anfrageinterval war 1s auf Kanal 40, empfangen statisch auf Kanal 3.

[Chris (Gast)]

Bei mir werden die Werte per MQTT alle Sekunde geschickt obwohl es auf 
10 Sekunde  eingestellt ist. Änderungen der Zeit haben keinen 
Einfluss.Ist das auch bei anderen so? ESP-DTU 0.3.6

[isnoAhoy (Gast)]

Hallo Lukas P.,
Du hast Recht in Spalte AA bis AE stehen drei Pakete der 
Standardantwort.
Man kann gut sehen, daß der GD32 das Paket 0x01 nicht empfangen hat und 
damit in Spalte AD nochmal mit 0x81 und CRC8 0x94 anfordert. Die Antwort 
mit dem fehlenden Paket kommt dann in Spalte AE.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Nur die Paketcounter sind eben nicht in Zeile 16 wie von martin (Gast) 
im Excel vermutet. Sondern wie richtig von lbp und Jan-Jonas bemerkt das 
in Zeile
10 bisher als CMD bezeichnete Byte. Zeile 13-16 ist hingegen die Zeit in 
Unix-Epoch wie anderweitig bereits herausgefunden wurde.

In Spalte AU-AZ taucht dann auch die Anfrage mit 0x80 0x11 auf, die 
Jan-Jonas als bisher größtes Antwortnachricht mit den Paketen 0x01..0x85 
des WR identifiziert hat.

@martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in 
der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export 
Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt 
zwischen GD32 und nRF24 aufzuzeichnen ?

[Lukas P. (lumapu)]

Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) 
werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, 
ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen 
Sinn ständig die Zeit neu zu setzen. Gedacht habe ich an sowas wie ein 
Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die 
Retransmits.

@Jan-Jonas S. (janjonas_s)
Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der 
C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu 
prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh 
oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den 
Payload gebildet werden.

Beispiel, so wie es aktuell verstehe, aber die CRC8s und CRC16_P stimmen 
nie:

01 [...] CRC8 CRC16_H CRC16_L
02 [...] CRC8 CRC16_H CRC16_L
....
8X [...] CRC16P_H CRC16P_L CRC8 CRC16_H CRC16_L

CRC8: über Paketpayload ohne CRC8 und CRC16
CRC16: ist implementiert und funktioniert
CRC16P: über die gesamte Payload aller Pakete - mit oder ohne dem 
Paketcounter?

[franz (Gast)]

Hallo Jan,

Jan-Jonas S. schrieb:
> Hinzugekommen sind:
>   * Support für den HM-1500

ich dachte bisher dass ich HM-350 haette (steht leider nicht lesbar 
drauf ohne den WR vom Modul zu lösen, das ja auch noch montiert ist),

Aber HM-4xx macht keinen Sinn, da ich pro Modul nur 325Wp habe. 
Allerdings war ja die Vermutung dass die 3xx und 400 gleiches Protokoll 
haben, darum hatte ich die bei mir alles als 300 zusammengefasst. Ich 
habe daher im angefügten diff meine (mit 112174..) als 3XX  bezeichnet, 
aber vermutlich könnte man die letzte Stelle weglassen und 3xx und 4xx 
damit covern. Ich habe ein diff attached.

Ad Retransmit, das hatte bei mir nicht funktioniert, bis ich die +6e7 ns 
bei empfangenen Paketen entfernt hatte, dann erwischte ich ueberhaupt 
fast alles, das hast Du jetzt auf +5e8, meine Antworten kommen zwischen 
1ms und 10ms, geht sich also locker aus.
Sollte auch in der Mikrocontrollerversion also mindestens so hoch sein.

Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages 
auch flat in ein kompaktes File schreiben zu können, hab mir sowas für 
einen geplanten remote site implementiert wo ich keine db hinter 
iobroker haben werde.

lg,
Franz

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen)
> werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich,
> ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen
> Sinn ständig die Zeit neu zu setzen.
Ich glaube der WR hat keine RTC und braucht daher die Updates der Zeit 
über die Luft, damit er z.B. weiß wann die daily counter resetet wetden 
müssen.

> Gedacht habe ich an sowas wie ein
> Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die
> Retransmits.
Da stehen wir noch vor dem Anfang.
Ich glaube, dass das byte nach 0x80 (normal 0x0b) das Kommando ist. Die 
Zeit, die wir dahinter setzen die Parameter zum Kommando.

Ich hab das mal durchgesweept und bekomme da alle möglichen langen und 
kurzen Antworten, die sich meist auch unterscheiden jenachdem welche 
Parameter man anhängt. Da sind wir auf mehr DTU Captures angewiesen um 
das verstehen zu können. Aber da war in python spätestens auch Schluss 
mit den cmd'd, weil jede Antwort mindestens ein Fragment 1 enthält, wo 
keine bekannten Werte drin stehen. Das macht dann graphen sehr kaputt, 
wenn man random binärdaten zu Zahlen macht.

Übrigens zum sweepen s.O. das /command-Topic. Sehr handy.

> @Jan-Jonas S. (janjonas_s)
> Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der
> C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu
> prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh
> oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den
> Payload gebildet werden.

in hoymiles/__init__.py InverterTransaction.get_payload()

# check crc
pcrc = struct.unpack('>H', payload[-2:])[0]
if f_crc_m(payload[:-2]) != pcrc:
    raise ValueError('Payload failed CRC check.')

Jedes Frame besteht aus
0x95, 4byte dst_addr, 4byte src_addr, 1byte sequence, bis 16byte(?) 
data, 1byte crc8

sequence:
 0x01 - 0x80 ist ein forlaufendes Fragment
 0x81 - 0xFF(?) markiert das letzte Paket, und die Gesamtzahl der 
Fragmente

Wenn sequence größer 0x80:
    int(sequence - 0x80) = Anzahl Fragmente

Das Endpaket zählt mit in den Paketzähler, 0x80 kann daher kein Wert des 
Endpakets sein. 0 Pakete = keine Übertragung ;)

Wenn mann alle data bytes in der richtigen Reihenfolge zusammen setzt 
(Payload), sind am Ende die 2 byte die modbus crc über die ganze Payload

Fehlt das Endpaket ist die Transaktion verloren. Die Pakete werden 
meistens nicht in der richtigen Reihenfolge empfangen. Kann sein, dass 
man die in der Reihenfolge 84, 01, 03, 02 liest.

Neu ist für mich auch, dass bei längeren Payloads, der WR auch auf Ch 40 
antwortet.

Den ersten Re-Transmit habe ich hier gefunden
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Jan-Jonas S. (janjonas_s)]

Hallo franz,

vielen Dank für das HM3XX-Mapping! Pulled-in.

franz schrieb:
> Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages
> auch flat in ein kompaktes File schreiben zu können, hab mir sowas für
> einen geplanten remote site implementiert wo ich keine db hinter
> iobroker haben werde.

Sowas ist geplant und möglich.
Ich stelle mir das python-modul später mal so vor, dass man es ähnlich 
wie auch den paho mqtt-client irgendwo rein laden kann und ein 
on_message-Callback bekommt, indem man Daten aus der Response nach 
belieben verarbeiten kann.

Ich plane z.B. einen direkten Influx2-Exporter, so umzusetzen. Das soll 
dann jeder selber modular bauen können, weil jeder sein eigenes Backend 
hat und die Zahl der Output-Plugins den Rahmen des Projekts sprengen 
würde.

Da bin ich aber noch nicht soweit, weil wir mit Sicherheit im Kern noch 
Dinge entdecken die möglicheriweise grundlegend überarbeitet werden 
müssen. Da liegt im Moment mein Fokus drauf. Bis dahin würde ich gerne 
die Komplexität außen rum so gering wie möglich halten.

Gruß,
Jan

[franz (Gast)]

Hallo Jan,

Jan-Jonas S. schrieb:
> Pulled-in.

hab die germergte version ausprobiert, funktioniert. Überinges war meine 
timing Aussage vorher falsch es sind 1-10 hundertstel-, nicht 1-10ms.

Ich hatte mir mehrere (7) NRF module bestellt, weil ich mir nicht sicher 
war, ob die wayintop + sind, die + von AZ so billig waren und laut 
Kommentaren und eigenen Beobachtungen gibt es öfters Aufälle, bzw 
schlimmer, funktioniert dann nicht zuverläßig. Ich habe nur in ca einen 
von 1000 Fällen eine Antwort am Sendekanal (40) und 90% auf 3 und 75. 
ALso kann ich mit einem chip staendig auf 3 und mit dem Sender gleich 
auf 75 umschalten, um zu sehen ob was kommt. Mit einem 2. Rapsi kann ich 
dann auch noch auf 2 weiteren Kanälen lauschen, sollte von der library 
her gehen und werde das mal ausprobieren :)

lg,
Franz