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

[Jan-Jonas S. (janjonas_s)]

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

So, wie es halt das python-modul seit einiger Zeit macht. Was ich ja 
alles schon geschrieben habe. Offensichtlich lest Ihr nicht.

> 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
Was für einen Nährwert hat diese Satistik?
Das ist wie wenn man hin und wieder mal aus dem Fenster schaut und über 
den Tag die Autos nach Farbe zählt, die gerade zufällig vorbei fuhren.

Die Daten aus dem 220507_PayloadHm1200.log machen für mich überhaupt 
keinen Sinn. Je Frame gibts max 16 byte Payload-Fragment.

In der Payload gibts garkeinen Bezug mehr, in welchem Frame ein 
Schnipsel mal rein kam.

Im Anhang nochmal valide Daten von einem HM600 als Referenz.
Daran könnt Ihr eure Implementierung mal testen, bis diese zu den 
gleichen Werten kommt.

Die Transaktion:
  * Transmit Request (gesendete Daten merken)
  * Alle innerhalb $Timeout empfangenen Daten per Frame-CRC (letztes 
byte) virifizieren und wenn valide den Datenteil und die sequenz in ein 
stack aus (seq, data) appenden. Die Adressen und Frame-CRC können da 
schon verworfen werden.
  * buffer nach sequenz größer 0x80 durchsuchen, damit man weiß wieviele 
Frames der WR gesendet hat
  * über den stack iterieren range(1, int(sequenz - 0x80)) und alle 
daten der reihe nach zusammensetzen + daten letztes Frame oder wenn man 
kein frame mit der sequenz findet, re-transmit anfordern und response 
auf den stack werfen. Schritt Wiederholen.
  * modbus_crc(data ohne letzten beiden byte) == data letzten beiden 
byte checken
  * final payload = data[:-2] (2 byte checksum weg)

Dann wird der Request der Transaktion wieder wichtig, weil man daran den 
Decoder wählt, dem man die finale Payload überreicht.

Nach aktuellem Kenntnisstand ist der Dekoder anhand des byte 11 (0b bei 
Zeit setzen) aus dem Request zu wählen. In der Payload gibts wohl keinen 
Identifier der enthaltenen Daten.

Der Wesentliche Teil findet sich da in 
hoymiles/__init__.py:InverterTransaction.get_payload()
Dort wird die Payload zusammengebaut.

Gruß,
Jan

[martin (Gast)]

isnoAhoy schrieb:
> @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 ?

Leider habe ich nur die DTU Lite, damit kann ich nichts regeln. Die 
Anzeige der Live-Werte im Installationsmodus kann ich mal testen. Bisher 
schneide ich die Kommunikation nur mit dem Logic Analyzer mit, was einen 
gewissen Aufwand darstellt - stattdessen möchte ich mir demnächst mal 
einen Logger basteln, damit ich längerfristig die Daten mitschreiben 
kann. Die werde ich dann gerne bereitstellen.

Für die Statistik hier noch meine Seriennummern:
DTU Lite: 10D9-72...
HM-600: 1141-72...

[Andi (Gast)]

Danke martin,
dass du es zumindest schonmal kurz versuchst hast dir anzusehen.
Das Power Limit lässt sich aber defintiv nur mit der DTU-Pro einstellen.
Ich habe dazu auch noch eine kleine Anleitung gefunden vom letzten Jahr, 
für die DTU-Pro Nutzer, die es Testen wollen/können:
https://www.shinetech-power.de/wp-content/uploads/2021/11/Shinetech_DTU_Set70Percent_Hoymiles.pdf
Die Oberfläche sieht vielleicht inzwischen etwas anders aus, aber 
irgendwo sollte der Punkt versteckt sein.
Der Zero Export Modus wird logischerweise ohne externe Modbus 
Messeinrichtung nicht funktionieren und falls es dort 70% Festwert zur 
Auswahl gibt, könnte es sein, dass er einfach nur als beliebiges Limit 
die 70% an den WR sendet. Egal welcher Weg, es wird am Ende wohl immer 
nur ein Prozentwert in ein Register des WR gesendet werden und das lässt 
sich wohl am besten mit der frei wählbaren Option testen/loggen.
Ich würde mich sehr freuen, wenn das noch klappt, ansonsten muss ich in 
knapp einem Monat ein Loch in meinen WR bohren und etwas löten. Mehr zu 
meinem Grund/Vorhaben dafür habe ich bereits eher geschrieben.

Das mit den Seriennummern sollte ja inzwischen fest stehen, wie es auch 
Sprinterfreak im Git und isnoahoy hier geschrieben hat:
Hoymiles HM Serie:
SN 1121 = 1 MPPT/Eingang  -> HM-300/350/400
SN 1141 = 2 MPPT/Eingänge -> HM-600/700/800
SN 1161 = 4 MPPT/Eingänge -> (HM-1000)/1200/1500

Mein frisch gelieferter HM-800 hat die SN 114180...

Grüße

[Mc_K (Gast)]

Danke für die Info. Sollte dieses "Funfact" bezug auf mein Posting 
nehmen, so möchte ich darauf hinweisen dass ich von der DTU in der 
Mehrzahl (Plural) geschrieben habe und nicht explitit die DTU-Pro-S 
erwähnt habe.

Ist es Empfehlenswert, die Inverter vorerst nicht mit einer DTU zu 
verbinden, um mögliche komplikationen durch Updates zu vermeiden?

[Lukas P. (lumapu)]

Jan-Jonas S. schrieb:
> Im Anhang nochmal valide Daten von einem HM600 als Referenz.
> Daran könnt Ihr eure Implementierung mal testen, bis diese zu den
> gleichen Werten kommt.

Das war sehr hilfreich. Habe jetzt den CRC8 und den CRC16 korrekt 
nachvollziehen können.

Kanal-Switching auf RX Seite habe ich eingebaut, die Ergebnisse sind 
gemischt:
Was mir aufgefallen ist: Wenn ich TX auf 40 stelle, dann bekomme ich nie 
Antworten auf Kanal 40. Habe den vorerst mal rausgenommen, evtl. kann 
man hierdurch die Retransmits zu reduzieren, da man in dieser Zeit auf 
anderen Kanälen lauschen kann.
Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus 
bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten 
liegen.

Gibt es schon Erkenntnisse wie oft der WR seine Daten erneuert? Ich 
glaube im Python Code ein 5s Interval erkannt zu haben.

Hat schon jemand bei diesem Kommando mit den Parametern experimentiert?

setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms

[Thomas B. (tbnobody)]

Ich habe aktuell das Python in der letzten Version von Jan am laufen [1]
Die Ergebnisse sind toll. Habe ein 5 Sek. Intervall eingestellt und 
bekomme dort zuverlässig Daten.

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

[Thomas B. (tbnobody)]

Lukas P. schrieb:
> Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus
> bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten
> liegen.

Ja, das ist mir auch schonmal aufgefallen. Eine Änderung der 
Antennenausrichtung hat hier wunder gewirkt. (Zusätzlich zu dem 
Kondensator den ich sowieso am NRF Modul habe)

[st_b (Gast)]

in der app.cpp hab ich folgendes beim Serial-Output (mit 
mSerialInterval=600) reingefrickelt - sorry, ich hatte keine Zeit mich 
in den Code ernsthaft einzulesen - vielleicht bringt es trotzdem 
jemanden etwas:

#include <ESP8266HTTPClient.h>

#define SERVERNAME "http://pvoutput.org/service/r2/addstatus.jsp"
#define APIKEY "40digit-hex-API-Key" // pvoutput.org API-Key
#define SYSTEMID 12345 // pvoutput.org systemID

...
...
...

void app::loop(void) {

...
...
...

    if (mSerialValues) {
      if (++mSerialTicker >= mSerialInterval) {
        mSerialTicker = 0;
       uint16_t energy = 0;
        for (uint8_t id = 0; id < mSys->getNumInverters(); id++) {
          Inverter<> *iv = mSys->getInverterByPos(id);
          if (NULL != iv) {
            uint8_t modNum, pos;
            switch (iv->type) {
              default:              modNum = 1; break;
              case INV_TYPE_HM600:
              case INV_TYPE_HM800:  modNum = 2; break;
              case INV_TYPE_HM1200: modNum = 4; break;
            }

            for (uint8_t ch = 1; ch <= modNum; ch ++) {
              energy += iv->getValue(iv->getPosByChFld(ch, FLD_YD));
            }
          }
        }

        char serverPath[255] = {0};
        sprintf(serverPath, "%s?key=%s&sid=%d&d=%04d%02d%02d&t=%02d:%02d&v1=%d", SERVERNAME, APIKEY, SYSTEMID, year(mTimestamp), month(mTimestamp), day(mTimestamp), hour(mTimestamp), minute(mTimestamp), energy);

        Serial.println(serverPath);

        HTTPClient http;
        WiFiClient client;

        http.begin(client, serverPath);

        // Send HTTP GET request
        int httpResponseCode = http.GET();

        if (httpResponseCode > 0) {
          Serial.print("HTTP Response code: ");
          Serial.println(httpResponseCode);
          String payload = http.getString();
          Serial.println(payload);
        }
        else {
          Serial.print("Error code: ");
          Serial.println(httpResponseCode);
        }
        // Free resources
        http.end();



        char topic[30], val[10];
        for (uint8_t id = 0; id < mSys->getNumInverters(); id++) {
          Inverter<> *iv = mSys->getInverterByPos(id);
          if (NULL != iv) {
            for (uint8_t i = 0; i < iv->listLen; i++) {
              if (0.0f != iv->getValue(i)) {
                snprintf(topic, 30, "%s/ch%d/%s", iv->name, iv->assign[i].ch, iv->getFieldName(i));
                snprintf(val, 10, "%.3f %s", iv->getValue(i), iv->getUnit(i));
                DPRINTLN(String(topic) + ": " + String(val));
              }
              yield();
            }
          }
        }
      }

[st_b (Gast)]

oben sollte eine Antwort auf folgenden Beitrag sein - sorry
Robert Bleumer schrieb:
> 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?

[Jan-Jonas S. (janjonas_s)]

Lukas P. schrieb:
> Was mir aufgefallen ist: Wenn ich TX auf 40 stelle, dann bekomme ich nie
> Antworten auf Kanal 40. Habe den vorerst mal rausgenommen, evtl. kann
> man hierdurch die Retransmits zu reduzieren, da man in dieser Zeit auf
> anderen Kanälen lauschen kann.

Auf 40 antwortet der WR einiges, wenn man ihn was fragt wo es längere 
Payloads als 4 Frames gibt. Also bei mir bleibt der definitiv drin. ;)
8002tttttttt00000500000000 z.B. liefert mir fast immer ein Teil der 
Response auf Ch40 aus.

Dafür habe ich vom WR noch nie was bekommen, wenn ich auf was anderem 
als 40 anfrage. Oli hat aber glaub ich auch schon Antworten auf Anfragen 
auf anderen Kanälen bekommen? Solange 40 bei allen funktionert bin ich 
glücklich. Eine Hoplist ist zumindest auch für TX schon so halb 
vorbereitet. Ich sehe gerade keinen Grund dafür. Meine Idee währe 
ohnehin eine Transceiver-List im YAML-File hinzuzufügen wo man sagen 
kann.

- channel: [23,40]
  mode: tx
  ce_pin: n
- channel: [3,23,40,61]
  mode: rx
  ce_pin: n

z.B. Da ich aber auch mit nem 2s Interval eigentlich kein cycel 
verliere, sehe ich dafür absolut kein Bedarf mehr. (Also 
multi-transceiver Setup)

> Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus
> bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten
> liegen.

Da wir keinem Funkplan folgen und kenie Rücksicht drauf nehmen ob wir 
irgendwas dazwischen funken was gerade schon auf Welle ist, ist eine 
Kollision sehr wahrscheinlich. Dann versteht natürlich niemand mehr was, 
da können wir nichts machen außer re-transmitten bis wir eine Antwort 
bekommen. Also quasi das Band solange jammen bis andere aufgeben. :D
Dann kommt noch dazu, dass die Antenne tatsächlich kein wirklicher 
Rundstrahler ist und schon recht optimal stehen muss.

> Gibt es schon Erkenntnisse wie oft der WR seine Daten erneuert? Ich
> glaube im Python Code ein 5s Interval erkannt zu haben.

On Request. Ich hab auch wenn ich den mit 1s polle immer neue Daten. 
Schneller lässt das Protokoll das nicht zu.

> Hat schon jemand bei diesem Kommando mit den Parametern experimentiert?
>

> setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms
>

SEHR viel. Hätte ich einen Sketch so oft kompillieren und auf einen ESP 
schreiben müssen, hätte ich einen hohen Chip-Verbrauch gehabt. :D
Die Settings haben bei mir damals son sweet spot getroffen. Scheint aber 
wohl sehr von der Funk-Umgebung abzuhängen wie sich rausstellt.

Gruß,
Jan

[isnoAhoy (Gast)]

Hallo Jan-Jonas,

ich habe mir mal Deine Transmit Pakete angesehen und folgendes Byte >05< 
ist mir dabei aufgefallen:

2022-05-08 15:24:27.553664 Transmit 27                 | 15  72 22 01 43 
78 56 34 12  80  0b 00 62 77 c4 8b 00 00 00>05<00 00 00 00 27 f2  0e

Bei den von martin (Gast) am RX/TX zwischen GD32 und nRF24 
aufgezeichneten Daten seiner DTU Lite wurde hier immer >00< übertragen. 
Hast Du einen Grund an der Stelle einen anderen Wert zu übertragen, bzw. 
bekommst Du hier andere Antworten je nach Anfrage ?

Ich habe auf der Suche nach diesem Byte auch noch folgende Anmerkung und 
Beobachtung von Oliver F. gefunden:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

> Martin (Gast) hatte noch eine Anmerkung:
>> Was mir hier und auch in meinen Daten aufgefallen ist: In den
>> Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer
>> mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun
>> haben, der für die Antwort verwendet werden soll?
>
> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
>
> Turn unit off:
> C2 850194040 00 1946107301 00DA 1B 1  15 73104619 72819005
> 800B00623B5CD8000000>08<0000000013DAD8A73B 3BA7 1
> Turn unit on:
> C2 067083344 00 1946107301 00DE 1B 3  15 73104619 72819005
> 800B00623B5D5A000000>09<00000000B0CEEDD61D 1DD6 1
> Turn unit off:
> C2 055407012 00 1946107301 00DA 1B 1  15 73104619 72819005
> 800B00623B5DC2000000>0A<0000000076413F7EAF AF7E 1
> Turn unit on:
> C2 086582484 00 1946107301 00DA 1B 1  15 73104619 72819005
> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1

Das 0x8y bedeutet m.E. daß die letzten beiden Byte (vor dem letzten 
CRC8) einen CRC_M bzw CRC16 enthalten. 0x8y kann ja sowohl bei Anfragen 
als auch bei Antworten auftauchen.

Das mit dem Kanal/allen Kanälen jammen konnte ich auch in martins Logic 
Analyzer Aufzeichnungen im Excel sehen (Spalte O-Z), dort wird die 
Anfrage insgesamt 12x wiederholt, lediglich der time_t Zeitstempel und 
somit auch die CRC16 & CRC8 werden ggf. angepaßt.

Jetzt müssten wir also die Antworten auf 0x800b, 0x8011 und 0x8003 je 
Wechselrichter Modellreihe, z.B. 1121, 1141 und 1161 dekodieren. Das ist 
für die 0x800b Statusanfrage m.W. auch soweit schon alles funktional.

Es fehlen aber noch das Verständnis für die Antworten auf 0x8011 und 
0x8003 die Einige (martin, Oliver, Hubi & Herbert, etc.) hier vorher 
beobachtet haben. 0x8003 geht dabei sogar von 0x01, 0x02, .., 0x09, 
0x0A, 0x0B bis 0x8C. Diese Anfragen & deren Antworten sind vermutlich 
auch wieder in Abhängigkeit von der Modellreihe zu untersuchen. Anbei 
das Beispiel aus martin's RX/TX Logic Analyser Excel als Screenshot.

[isnoAhoy (Gast)]

Hallo Jan-Jonas,

> SEHR viel. Hätte ich einen Sketch so oft kompillieren und auf einen ESP
> schreiben müssen, hätte ich einen hohen Chip-Verbrauch gehabt. :D

Ich weiß, ziemlich Off-Topic, aber wie macht ihr das eigentlich auf 
Eurem Raspberry Pi die vielen MQTT Daten in eine InfluxDB o.a. zu 
speichern.
Da müsste ja jede SD Karte den Geist aufgeben.
Habt Ihr dafür irgendeine (m)SATA / m.2 SSD eingebaut ?
Wenn ja, welchen Adapter (USB->SATA) verwendet ihr und wie groß bzw. 
welcher Bauart ist die SSD ?

[Jan-Jonas S. (janjonas_s)]

Hallo,

isnoAhoy schrieb:
> Ich habe auf der Suche nach diesem Byte auch noch folgende Anmerkung und
> Beobachtung von Oliver F. gefunden:
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Das. Was genau es bedeutet, keine Ahnung. Zu dem Zeitpunkt habe ich das 
Projekt gejoined und hab das so aus der alten ahoy.py übernommen.
Nein, ich sehe keine Änderung, wenn ich da was anderes übertrage.

>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
05
>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1

Guter Fund!

> Das 0x8y bedeutet m.E. daß die letzten beiden Byte (vor dem letzten
> CRC8) einen CRC_M bzw CRC16 enthalten.

Nicht ganz. Die Adressen, der Frame-Counter und das letzte Byte gehören 
zum ESB-Frame. Die CRC16_M, zufällig in dem ESB-Frame mit Counter größer 
0x80, ist zu diesem Zeitpunkt nur Payload und hat nichts mit dem 
Transport-Layer zu tun.

Die CRC16_M existiert für uns also am besten nur in der Payload, wenn 
sie wieder defragmentiert ist. Ich könnte jetzt natürlich auch mal 
schauen, ob die letzten beiden Byte anderer Payloads auf random Requests 
auch eine CRC16_M ist ... Das würde die Anzahl zu erratener Bytes 
reduzieren :D

> InfluxDB
> Da müsste ja jede SD Karte den Geist aufgeben.
Richtig. SD ist by design kaputt.

> Habt Ihr dafür irgendeine (m)SATA / m.2 SSD eingebaut ?

So habe ich meine 0-Einspeise-Regelung realisiert. Rechenzentrum zu 
Hause. Da steht ein i3 mit Proxmox und NVME. Sicher radiert das da auch 
ganz schön trotz wear leveling (Was die SD nicht hat). Aber ich mag 
bunte Grafiken, wo ich rein zoomen kann und trotzdem keine Auflösung 
verliere. Ich halte die Daten 1 Woche mit voller Auflösung und danach 
reduziert ein CQ das runter auf 10 Minuten. So bleibt das dann ewig. Die 
paar Wechselrichter-Werte sind da aber nur ein ganz kleiner Teil vom 
Rauschen. :)

Gruß,
Jan
mqtt->telegraf->InfluxDB. Beispiel habe ich oben auch schon mal 
gepostet.

Append:
Der incrementierende Counter verrät dem WR im Grunde wieviele Commands 
er hinterher hängt. Wie verhält sich denn das erste Byte der Payload zum 
Command-Counter. Könnte das vielleicht die Differenz angeben, damit die 
verpassten Nachrichten nochmal hinterher geschoben werden können?

[Sorbit (Gast)]

Jan-Jonas S. schrieb:
> So habe ich meine 0-Einspeise-Regelung realisiert.

Wie hast Du diese denn realisiert?
Du benötigst ja einen steuerbaren WR....

[isnoAhoy (Gast)]

Hallo Jan-Jonas,
danke für die Antwort.

Ich habe nochmal den Github Kommentar nachgelesen, in dem ich 
exemplarisch Mal eine 0x8002 Anfrage und Antwort von Dir untersucht 
hatte.

https://github.com/grindylow/ahoy/issues/24#issuecomment-1120237280

Hier mal die Antwort auf die 0x8011 wie von martin im Excel zwischen 
GD32 und nRF24 getraced.

$ xxd 0x8011.bin
00000000: 0001 b001 0001 0d34 0d34 0000 0000 708f  .......4.4....p.
00000010: 0004 0d3c 0d97 0002 07a3 7093 0005 0d3c  ...<......p....<
00000020: 0d97 0000 0000 a00e 0006 0d9c 0d9c 0705  ................
00000030: 0542 708f 0009 0d9c 0dd8 01e2 07a3 7091  .Bp...........p.
00000040: 000a 0d9c 0dd8 0000 12c0 d16a 377f       ...........j7.

Wir haben also nicht nur dei Anfragen 0x800b und 0x8011 gesehen, sondern 
auch wie von Hubi/Herbert berichtet eine 0x8003 und die von Dir geloggte 
0x8002. Die Anfragen sollte man vielleicht auch nach ein paar Tagen 
nochmal wiederholen, da es wohl nicht besonders schnell veränderliche 
Daten sind. Zumindest taucht die Anfrage 0x8011 in martin's DTU Logic 
Analyzer Daten nur einmal auf.

Bzgl. dem RF24 am Raspberry habe ich noch eine weitere Frage:
Warum funktioniert es da auch ohne Interrupt, beim ESP8266 schliessen 
wir extra den Interrupt an. Ich hatte irgendwo ein Issue im RF24 github 
gelesen, das aber schon geschlossen war bzgl. optionaler pigpio 
Unterstützung für Interrupts.

[Jan-Jonas S. (janjonas_s)]

Hallo isnoAhoy,

ich habe mal die Payload aus dem Screenshot abgetippt. Nicht nur, dass 
die ganz anders aussieht als bei mir, die crc stimmt auch nicht.

Dafür habe ich mal 0x11 bei mein HM600 angefragt und ein wenig rum 
probiert. Ich hab fast die Vermutung, dass das eine Daily history von 
energy total von einem String ist. In meiner Payload sieht das sehr nach 
Tabelle von irgendwas aus. Ich hab hier mal kurz die Payload mit 
Linebreaks versehen. Ich sehe da ein Muster.

00 01
80 01 00 06 31 53 31 53 00 00 00 00 
80 02 00 35 a7 fa a7 fa 00 00 00 07 
b0 02 00 36 00 32 00 32 ff ff ff fb 
b0 02 00 37 00 39 00 39 00 00 00 05 
b0 02 00 38 05 c2 05 c2 ff ff ff fa 
b0 02 00 39 05 c6 05 c6 00 00 00 06 
b0 02 00 3a 18 6c 18 6c ff ff ff fb 
b0 02 00 3b 18 6f 18 6f 00 00 00 05 
b0 02 00 3c 23 5a 23 5a ff ff ff fb 
b0 02 00 3d 23 5e 23 5e 00 00 00 05 
b0 02 00 3e 25 de 25 de ff ff ff fb 
b0 02 00 3f 25 e3 25 e3 00 00 00 05 
b0 02 00 40 26 c9 26 c9 ff ff ff fa 
b0 02 00 41 26 ce 26 ce 00 00 00 06 
b0 02 00 42 27 ea 27 ea ff ff ff fb 
39 f2 <- modbus crc

Bei 0x12 habe ich einmal eine ähnliche Antwort bekommen und jetzt kommt 
bei 0x12 nur noch

2022-05-10 18:37:20.973622 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 12 00 62 7a 94 bd 00 00 00 00 00 00 00 00 b2 61 7f
2022-05-10 18:37:21.019035 Received 15 bytes channel 3: 95 72 22 01 43 72 22 01 43 81 00 01 70 c0 a5
2022-05-10 18:37:21.522190 Payload: 00 01 70 c0
 payload has valid modbus crc

Gruß,
Jan

[Herbert K. (avr-herbi)]

Beim Beschiessen der HM350 + HM400 mit 0x11 bekomme ich 2 verschieden 
lange Antworten:
a) 5+1 Telegramme (letztes = 86....)
b) 8+1 Telegramme (letztes = 89....)
c) oder 8114 als Kurztelegramm (Payload=0x14)
Wobei die letzten Telegramme (also 86..., 89...) weniger Lang sind nach 
dem was mir angezeigt wird.
Auf jeden Fall wiederholt sich öfters ...8002... in der Payload.
Entschlüsselt habe ich noch nix.

[Lukas P. (lumapu)]

Jan-Jonas S. schrieb:
> Auf 40 antwortet der WR einiges, wenn man ihn was fragt wo es längere
> Payloads als 4 Frames gibt. Also bei mir bleibt der definitiv drin. ;)
> 8002tttttttt00000500000000 z.B. liefert mir fast immer ein Teil der
> Response auf Ch40 aus.

Ok, du bist da schon weiter - dann nehme ich es wieder auf.

Jan-Jonas S. schrieb:
> Dafür habe ich vom WR noch nie was bekommen, wenn ich auf was anderem
> als 40 anfrage.

Das sehe ich genauso, anfangs habe ich mit 4 Kanälen gearbeitet. Wenn 
man nicht auf 40 sendet, bekommt man nur 0x81 Pakete ohne Payload -> 
Fehlermeldung?

Jan-Jonas S. schrieb:
> On Request. Ich hab auch wenn ich den mit 1s polle immer neue Daten.
> Schneller lässt das Protokoll das nicht zu.

Wegen Zeit setzen und mit Unix-Timestamp? Dürfte auch mehr als genug 
sein.

Sorbit schrieb:
> Jan-Jonas S. schrieb:
>> So habe ich meine 0-Einspeise-Regelung realisiert.
>
> Wie hast Du diese denn realisiert?
> Du benötigst ja einen steuerbaren WR....

Oder man verheizt die Energie einfach kommt auch bei 0 raus, ist halt 
weniger nachhaltig (je nach dem was man mit dem Überschuss anstellt).

[Raik E. (raik85)]

Hallo,
bin noch neu hier aber erstmal meinen Respekt an all die hie reverse 
engeneered haben. Find ich super, da brauch ich mir jetzt die DTU für 
100Euro kaufen.
So ein Mini 8266 von AZDelivery tuts auch mit ein paar Modifikationen.

Kleines Feedback an die Developer von Ahoy:

-Tsun M800 läuft ohne Probleme, im Setup HM600 ausgewählt und 
Seriennummer eingetragen (114173307xxx)
-MQTT funktioniert noch nicht (vielleicht schon bekannt)
-Ich wünsche mir ein JSON file als Alternative zu MQTT

Lukas P. schrieb:
> Sorbit schrieb:
>> Jan-Jonas S. schrieb:
>>> So habe ich meine 0-Einspeise-Regelung realisiert.
>>
>> Wie hast Du diese denn realisiert?
>> Du benötigst ja einen steuerbaren WR....
>
> Oder man verheizt die Energie einfach kommt auch bei 0 raus, ist halt
> weniger nachhaltig (je nach dem was man mit dem Überschuss anstellt).

Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um 
Warmwasserspeicher.

Danke Jungs!

[Jan-Jonas S. (janjonas_s)]

Neue Erkenntnisse:
Die vermeintliche Liste in 80 11 wird länger, wenn man den Stecker 
zieht. Ereignisspeicher seit Einspeisebegin?

Poll inverter 114172220143
2022-05-11 09:47:14.398816 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 11 00 62 7b 69 fe 00 00 00 00 00 00 00 00 47 d7 80
2022-05-11 09:47:14.462357 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 01 00 01 80 01 00 06 32 88 32 88 00 00 00 00 80 0d 9f
2022-05-11 09:47:14.497777 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 00 07 68 3a 68 3a 01 ce 13 54 40 94 00 09 68 3a 97
2022-05-11 09:47:14.533164 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 68 90 09 3d 07 53 80 0d 00 0a 68 c8 68 c8 02 60 eb
2022-05-11 09:47:14.574203 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 12 45 40 94 00 0c 68 c8 69 0f 09 47 08 58 80 02 44
2022-05-11 09:47:14.639077 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 00 0d 6a 25 6a 25 ff ff ff fb 80 02 00 0e 6a 25 5a
2022-05-11 09:47:14.680307 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 6a 25 00 00 00 05 80 02 00 0f 6b 29 6b 29 ff ff 54
2022-05-11 09:47:14.751142 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 ff fb 80 02 00 10 6b 2c 6b 2c 00 00 00 05 80 02 83
2022-05-11 09:47:14.786377 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 00 11 6b 66 6b 66 ff ff ff fa 80 02 00 12 6b 6b 19
2022-05-11 09:47:14.827522 Received 19 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 6b 6b 00 00 00 05 01 69 71
2022-05-11 09:47:15.331532 Payload: 00 01 80 01 00 06 32 88 32 88 00 00 00 00 80 0d 00 07 68 3a 68 3a 01 ce 13 54 40 94 00 09 68 3a 68 90 09 3d 07 53 80 0d 00 0a 68 c8 68 c8 02 60 12 45 40 94 00 0c 68 c8 69 0f 09 47 08 58 80 02 00 0d 6a 25 6a 25 ff ff ff fb 80 02 00 0e 6a 25 6a 25 
00 00 00 05 80 02 00 0f 6b 29 6b 29 ff ff ff fb 80 02 00 10 6b 2c 6b 2c 00 00 00 05 80 02 00 11 6b 66 6b 66 ff ff ff fa 80 02 00 12 6b 6b 6b 6b 00 00 00 05 01 69
 payload has valid modbus crc
80 01 00 06 32 88 32 88 00 00 00 00:
 BBLHl  : (128, 1, 406152, 12936, 0)
 BBBBBHHHB: (128, 1, 0, 6, 50, 34866, 34816, 0, 0)
 12B    : (128, 1, 0, 6, 50, 136, 50, 136, 0, 0, 0, 0)

80 0d 00 07 68 3a 68 3a 01 ce 13 54: 
 BBLHl  : (128, 13, 485434, 26682, 30282580)
 BBBBBHHHB: (128, 13, 0, 7, 104, 14952, 14849, 52755, 84)
 12B    : (128, 13, 0, 7, 104, 58, 104, 58, 1, 206, 19, 84)

40 94 00 09 68 3a 68 90 09 3d 07 53: <-- Netztrennung
 BBLHl  : (64, 148, 616506, 26768, 154994515)
 BBBBBHHHB: (64, 148, 0, 9, 104, 14952, 36873, 15623, 83)
 12B    : (64, 148, 0, 9, 104, 58, 104, 144, 9, 61, 7, 83)

80 0d 00 0a 68 c8 68 c8 02 60 12 45: 
 BBLHl  : (128, 13, 682184, 26824, 39850565)
 BBBBBHHHB: (128, 13, 0, 10, 104, 51304, 51202, 24594, 69)
 12B    : (128, 13, 0, 10, 104, 200, 104, 200, 2, 96, 18, 69)

40 94 00 0c 68 c8 69 0f 09 47 08 58: <-- Netztrennung
 BBLHl  : (64, 148, 813256, 26895, 155650136)
 BBBBBHHHB: (64, 148, 0, 12, 104, 51305, 3849, 18184, 88)
 12B    : (64, 148, 0, 12, 104, 200, 105, 15, 9, 71, 8, 88)

80 02 00 0d 6a 25 6a 25 ff ff ff fb: 
 BBLHl  : (128, 2, 879141, 27173, -5)
 BBBBBHHHB: (128, 2, 0, 13, 106, 9578, 9727, 65535, 251)
 12B    : (128, 2, 0, 13, 106, 37, 106, 37, 255, 255, 255, 251)

80 02 00 0e 6a 25 6a 25 00 00 00 05: 
 BBLHl  : (128, 2, 944677, 27173, 5)
 BBBBBHHHB: (128, 2, 0, 14, 106, 9578, 9472, 0, 5)
 12B    : (128, 2, 0, 14, 106, 37, 106, 37, 0, 0, 0, 5)

80 02 00 0f 6b 29 6b 29 ff ff ff fb: 
 BBLHl  : (128, 2, 1010473, 27433, -5)
 BBBBBHHHB: (128, 2, 0, 15, 107, 10603, 10751, 65535, 251)
 12B    : (128, 2, 0, 15, 107, 41, 107, 41, 255, 255, 255, 251)

80 02 00 10 6b 2c 6b 2c 00 00 00 05: 
 BBLHl  : (128, 2, 1076012, 27436, 5)
 BBBBBHHHB: (128, 2, 0, 16, 107, 11371, 11264, 0, 5)
 12B    : (128, 2, 0, 16, 107, 44, 107, 44, 0, 0, 0, 5)

80 02 00 11 6b 66 6b 66 ff ff ff fa: 
 BBLHl  : (128, 2, 1141606, 27494, -6)
 BBBBBHHHB: (128, 2, 0, 17, 107, 26219, 26367, 65535, 250)
 12B    : (128, 2, 0, 17, 107, 102, 107, 102, 255, 255, 255, 250)

80 02 00 12 6b 6b 6b 6b 00 00 00 05: 
 BBLHl  : (128, 2, 1207147, 27499, 5)
 BBBBBHHHB: (128, 2, 0, 18, 107, 27499, 27392, 0, 5)
 12B    : (128, 2, 0, 18, 107, 107, 107, 107, 0, 0, 0, 5)

2022-05-11 09:47:15.345973 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 7b 6a 02 00 00 00 05 00 00 00 00 96 a1 c7
2022-05-11 09:47:15.409633 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3f 02 e4 09 35 01 40 02 e9 09 48 00 00 9a
2022-05-11 09:47:15.450519 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 ba 0a 00 00 b1 2d 01 53 01 52 08 ed 13 88 11 a8 7d
2022-05-11 09:47:15.485233 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 04 00 c6 03 e8 01 7b 00 12 59 e7 e9
2022-05-11 09:47:15.989314 Payload: 00 01 01 3f 02 e4 09 35 01 40 02 e9 09 48 00 00 ba 0a 00 00 b1 2d 01 53 01 52 08 ed 13 88 11 a8 00 04 00 c6 03 e8 01 7b 00 12 59 e7
2022-05-11 09:47:15.989314 Decoded: 37.9 phase0=voltage:228.5, current:19.8, power:452.0, frequency:50.0 string0=voltage:31.9, current:7.4, power:235.7, total:47.626, daily:339 string1=voltage:32.0, current:7.45, power:237.6, total:45.357, daily:338

Gruß,
Jan

[Martin P. (mpolak77)]

so eine Art Gedächtnis muss es geben. Ich hatte schon beobachtet, dass 
die DTU den HM350 plötzlich nicht mehr sah ... und am nächsten Tag waren 
plötzlich Daten zum Tag da.

Was ich mit meiner SW (Fork vom alten C-Code auf ESP8266) plötzlich 
beobachte (bis vor kurzem funktionierte es ganz passabel) ist, dass der 
etwas weiter entfernte HM350 von der Früh weg Werte schickt und dann 
plötzlich damit aufhört, bzw sehe ich am ESP keine Nachrichten mehr .... 
er verschwindet dann um ca 9:00 auch immer von der DTU .... speist aber 
weiterhin ein und auch die Led blinkt grün.
Am nächsten Tag kommen wieder Nachrichten und nach 1-2h hören sie auf.

Kann es sein, dass es so eine Art "denial of service" Schutz ist, wo der 
WR nach einer größeren Anzahl mit CRC fails oder einfach zu vielen 
Anfragen zu schweigen beginnt? Hat jemand ähnliches beobachten können?

Ich habe viel mit RX Channel hopping und unterschiedlichen Zeiten 
zwischen den ticks experimentiert .... nichts scheint das zu verbessern. 
Der HM700, der näher zu ESP und DTU ist liefert viel mehr Werte pro 
Zeiteinheit. Was sich geändert hat seit Anfang April ist die gesteigerte 
Vegetation zwischen HM350 und ESP ... ich habe aber auch mehrere 
Antennen getestet um das zu kompensieren (bus zu 9dBi omni)

[Jan-Jonas S. (janjonas_s)]

Martin P. schrieb:
> er verschwindet dann um ca 9:00 auch immer von der DTU .... speist aber
> weiterhin ein und auch die Led blinkt grün.
> Am nächsten Tag kommen wieder Nachrichten und nach 1-2h hören sie auf.

Ich vermute eher, da beginnt jemand sein HomeOffice und DDoSed das wlan 
in Teams. Oder verwendet sonst welche Funk-Gadgets. NRF ist da sehr 
empfindlich. Schon mal die Antenne schief angeschaut? Bei Thomas hat das 
wohl geholfen.
Mein WR hat noch nicht aufgehört mir Daten zu schicken und ich hol da 
echt raus, was geht. Aber über die Eventualität habe ich auch schon 
nachgesacht, dass die loggen und irgendwann ihren Flash kaputt 
schreiben? Wer weiß.

Egal. So lange hab ich ein buntes Leben :D

[Sorbit (Gast)]

Raik E. schrieb:
> Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um
> Warmwasserspeicher.

Bitte etwas konkreter.
Wie regelt Ihr das?

Welche Hardware benötigt man dazu?

[Jan-Jonas S. (janjonas_s)]

Sorbit schrieb:
> Wie regelt Ihr das?

Am Verbraucher:
- Shelly
- Sonoff

HomeAssistant übernimmt dabei die Logik, Verbraucher bedarfsgereicht 
ein-/abzuschalten.

Am Wechselrichter garnicht. Wir wissen ja noch nicht wie... Aber bei 600 
Wp habe ich auch nur sehr kurz, sehr wenig, wenn überhaupt Überchuss. 
Wenn ich Energie über hätte, würde ich ein Miner anschmeißen. Das 
Problem hab ich leider nicht.

> Welche Hardware benötigt man dazu?

Energiemessgerät am Hausanschluss, was schon halbwegs Echtzeitdaten 
liefern kann. Ich hab ein Shelly 3EM und polle dessen http api 
sekündlich. EVU-Meter scheinen dazu nicht geeignet zu sein, liefern zu 
selten Daten. Ferrais-Zähler gehen garnicht.
Dann halt irgendein Logik-Element dazwischen was die Daten vergleicht 
und dann, sobald wir endlich wissen wie man den WR steuert, könnte mein 
HASS jetzt schon per mqtt {topic}/command die Steuer-Payload einwerfen.

[Pintopf (Gast)]

Hallo!

Auch ich habe mir vor einigen Wochen ein Mini-Solarkraftwerk mit 2 Stück 
375W Modulen und einem HM600 Inverter in den Garten gestellt.
Da ich unser Haus mit einer Homematic teilautomatisiert habe, benutze 
ich zur Messung des Ertrags ein Schaltmodul mit Energiezähler, welches 
ich "rückwärts" betreibe.
Zum weiteren Erkenntnisgewinn und aus reinem Spieltrieb habe ich das 
Netz auf der Suche nach einer Möglichkeit durchsucht, an die internen 
Daten des Controllers, ohne Cloudzwang, heranzukommen. Auf dieser Seite 
hier bin ich nun fündig geworden.
Einen ESP8266 hatte ich noch in meiner Basteliste, die NRF-Platine habe 
ich von AZ Delivery. Dort habe ich nur noch einen Elko über die 
Versorgungsspannungs-Pins gelötet, beide Platinchen verdrahtet, das 
Git-Repository geclont, das Projekt in den ESP gebrannt, meine gemachten 
Fehler gesucht und behoben....und nun kann ich meinen Wechselrichter 
auslesen.

Herzlichen Dank an alle Beteiligten, welche dieses tolle Projekt 
realisiert haben und viel Zeit und Mühe dort hineingesteckt haben!

Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge 
(YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic 
gemessenen Werte.
Jetzt habe ich mir mal die RF24 Payload über die serielle Schnittstelle 
ausgeben lassen und nach den fehlenden Daten gesucht. In dem Bild im 
Anhang habe ich den vermeindlichen Fundort markiert.
Könnte jemand von euch das verifizieren?

Was ich auch nicht hinbekomme, ist die MQTT-Verbindung. Ich habe mir auf 
der Homematic mit Mosquitto und Node-Red einen Broker gebaut, mit dem 
sich der ESP laut Statusmeldung auch connectet, aber ich bekomme keine 
Daten heraus.
Allerdings bin ich auch totaler MQTT-Anfänger, der Fehler liegt 
sicherlich irgendwo in meiner Konfiguration versteckt.

Vielen Dank noch einmal für die hervorragende Arbeit!
Peter

[Peter L. (leliep)]

Pintopf schrieb:
> Was ich auch nicht hinbekomme, ist die MQTT-Verbindung. Ich habe mir auf
> der Homematic mit Mosquitto und Node-Red einen Broker gebaut, mit dem
> sich der ESP laut Statusmeldung auch connectet, aber ich bekomme keine
> Daten heraus.
> Allerdings bin ich auch totaler MQTT-Anfänger, der Fehler liegt
> sicherlich irgendwo in meiner Konfiguration versteckt.
>
> Vielen Dank noch einmal für die hervorragende Arbeit!
> Peter

Versuch doch mal, einen MQTT-Client wie z.B. MQTT Inspector (iPad) zu 
verwenden, um die Daten des MQTT-Brokers auszulesen. Nach meiner 
Erfahrung hilft das sehr dabei, zu erkennen, welche Namen Deine Werte im 
Broker haben.

Von der Kommandozeile gehts auch mit: mosquitto_sub -u <user> -P <passw> 
-v -t +/#

Dann siehst Du, was rauskommt von dem, was Du reinschickst…

[rosch99 (Gast)]

Pintopf schrieb:
> Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge
> (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic
> gemessenen Werte.

Die beiden Channels (PV-Module) zusammengezählt ergeben doch 45kWh wie 
gemessen, das passt doch eh.

@MQTT kontrolliere genau die / in den jeweiligen Topics, oft hakt es 
daran ;-)

[pintopf (Gast)]

Ich habe schon einen MQTT-Sniffer laufen, der findet auch mein 
selbsdefiniertes Topic nebst Inhalt, was mir sagt, dass der Broker auf 
der CCU3 wohl läuft.(Screenshot)
Muss ich den Inhalt des vom ESP gesendeten Topics vielleicht irgendwo 
selbst definieren? Steht da zur Zeit nur nichts drin?
Wenn nein, welche Meldungen werden übermittelt? Als String?

Viele Grüße,
Peter

[pintopf (Gast)]

rosch99 schrieb:
> Die beiden Channels (PV-Module) zusammengezählt ergeben doch 45kWh wie
> gemessen, das passt doch eh.

Das ist wohl war, jedoch wird auf der vom ESP generierten Webseite nur 
der Wert des zweiten Channels als Gesamt-Energiemenge angezeigt.

Da stand beim meiner obigen Messung eben 23,3 kWh Gesamtertrag.


Gruß, Peter

[Jan-Jonas S. (janjonas_s)]

Hi,

neues von 0x11 und 0x12 Requests. Siehe Logfile. Sieht wohl so aus, als 
währe ich da auf der richtigen Fährte. Die a_text's sind die a_codes aus 
der DTU-Modbus und User manual [1]. a_code 1 und 2 sind geraten. Sonst 
ist noch ne Menge unbekannt. Bei der Uptime bin ich mir auch 
unschlüssig. Ginge um ne Stunde falsch und scheint irgendwann 
übergelaufen zu sein? Aber mit long statt short dekodieren gibt an der 
Stelle keinen sinnvollen Output.

Wo ist der Unterschied zwischen 0x11 und 0x12? Glaube die Art des 
Fehlers.
0x11 scheint ein allgemeines Log zu sein, 0x12 Grid related?

[1] 
https://www.hoymiles.com/wp-content/uploads/2021/11/User-manual_HMS-160018002000-4T-NA_EN_V202201.pdf
--
Gruß,
Jan

[Thomas B. (tbnobody)]

Konnte Jans Erkenntnis bzgl. 0x80 0x11 nachvollziehen.
mit seinem letzten Source bekommt man folgendes dekodiert:

2022-05-11 19:17:29.045241 Payload: 00 01 80 01 00 06 30 62 30 62 00 00 00 00 00 d4 00 07 30 6a 00 00 00 00 00 00 b0 02 00 48 4c f7 4c f7 00 00 00 05 b0 02 00 49 55 da 55 da ff ff ff fb b0 02 00 4a 55 ed 55 ed 00 00 00 05 b0 02 00 4b 56 72 56 72 ff ff ff fb b0 02 00 4c 56 72 56 72 00 00 00 06 b0 02 00 4d 56 79 56 79 ff ff ff fb b0 02 00 4e 56 82 56 82 00 00 00 05 b0 02 00 4f 56 e7 56 e7 ff ff ff fb b0 02 00 50 56 f3 56 f3 00 00 00 05 b0 02 00 51 57 1d 57 1d ff ff ff fb b0 02 00 52 57 23 57 23 00 00 00 05 b0 02 00 53 57 4f 57 4f ff ff ff fb b0 02 00 54 57 51 57 51 00 00 00 05 05 ab
 payload has valid modbus crc
80 01 00 06 30 62 30 62 00 00 00 00:
 uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0)
00 d4 00 07 30 6a 00 00 00 00 00 00:
 uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input
 BBHHHHH: (0, 212, 7, 12394, 0, 0, 0)
b0 02 00 48 4c f7 4c f7 00 00 00 05:
 uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5)
b0 02 00 49 55 da 55 da ff ff ff fb:
 uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531)
b0 02 00 4a 55 ed 55 ed 00 00 00 05:
 uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5)
b0 02 00 4b 56 72 56 72 ff ff ff fb:
 uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531)
b0 02 00 4c 56 72 56 72 00 00 00 06:
 uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6)
b0 02 00 4d 56 79 56 79 ff ff ff fb:
 uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531)
b0 02 00 4e 56 82 56 82 00 00 00 05:
 uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5)
b0 02 00 4f 56 e7 56 e7 ff ff ff fb:
 uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531)
b0 02 00 50 56 f3 56 f3 00 00 00 05:
 uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5)
b0 02 00 51 57 1d 57 1d ff ff ff fb:
 uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531)
b0 02 00 52 57 23 57 23 00 00 00 05:
 uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5)
b0 02 00 53 57 4f 57 4f ff ff ff fb:
 uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531)
b0 02 00 54 57 51 57 51 00 00 00 05:
 uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5)

Bei 0x80 0x12 schaut kommt

2022-05-11 19:09:10.888401 Transmit 27 | 15 71 60 35 46 78 56 34 12 80 12 00 62 7b fb c4 00 00 00 00 00 00 00 00 52 59 c0
2022-05-11 19:09:10.951495 Received 27 bytes channel 3: 95 71 60 35 46 71 60 35 46 81 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb 36
2022-05-11 19:09:11.454623 Payload: 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb
 payload has valid modbus crc
00 d4 00 07 30 6a 00 00 00 00 00 00:
 uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input
 BBHHHHH: (0, 212, 7, 12394, 0, 0, 0)

Ich hätte das so interpretiert, dass 0x11 ein allgemeines Log ist und 
0x12 nur kritische Dinge anzeigt. Aber ist nur eine vermutung.

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
> Hi,
>
> neues von 0x11 und 0x12 Requests. Siehe Logfile. Sieht wohl so aus, als

Hallo Jan, 0x11 habe ich seit Mittag am Laufen für 350 + 400. Hab aber 
noch keine Zeit gehabt, mir das anzuschauen. Hab nur gesehen, das einer 
schon bei den Antworten bei ..8C... angekommen ist, so auf die Schnelle. 
"C" wären ja 12 Payloads zum zusammensetzen ?

[rosch99 (Gast)]

pintopf schrieb:
> Muss ich den Inhalt des vom ESP gesendeten Topics vielleicht irgendwo
> selbst definieren? Steht da zur Zeit nur nichts drin?
> Wenn nein, welche Meldungen werden übermittelt? Als String?

Ok, du verwendest NodeRed, damit ist es einfach.
Versuch mal /inverter/# zu subscriben und einen debug node dranzuhängen, 
das  # entspricht im MQTT einem *. Du bekommst dann alle Topics und 
Werte als String im debug fenster und kannst dir die passenden 
raussuchen.

Ich schicke es dann in einen change node und mache aus dem string eine 
number und anschliessend noch einen smooth node zum runden der Werte.
Kann man natürlich auch mit einem function node lösen.

[Raik E. (raik85)]

Sorbit schrieb:
> Raik E. schrieb:
>> Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um
>> Warmwasserspeicher.
>
> Bitte etwas konkreter.
> Wie regelt Ihr das?
>
> Welche Hardware benötigt man dazu?
Ein wenig Off-topic:

Ich habe in meiner Unterverteilung direkt hinter dem Hauptzähler ein 
Eastron SDM72M installieren lassen, dieser wird mittels einem ESP32 
ausgelesen und übermittelt den Verbrauch/Einspeisung wattgenau an einen 
Thyristor Leistungssteller (Schwingungspaketsteuerung) an dem dann ein 
Heizstab im Warmwasserspeicher hängt.

Auf diese weise kann ich den Heizstab genau steuern (dimmen) und so fast 
jedes erzeugte Watt nutzen.

[Heinz R. (heijz)]

Raik E. schrieb:
> Ich habe in meiner Unterverteilung direkt hinter dem Hauptzähler ein
> Eastron SDM72M installieren lassen, dieser wird mittels einem ESP32
> ausgelesen und übermittelt den Verbrauch/Einspeisung wattgenau an einen
> Thyristor Leistungssteller (Schwingungspaketsteuerung) an dem dann ein
> Heizstab im Warmwasserspeicher hängt.

sorry, falsches Topic, bitte kapere nicht den Thread
Mach gerne einen Neuen auf - genau das was Du hier beschreibst - 
Schwingungspaketsteuerung - funktioniert nämlich so überhaupt nicht

[isnoAhoy (Gast)]

Hallo Jan-Jonas,

das sieht ja schon sehr vielversprechend aus mit den Logfiles vom 
Hoymiles WR!

Ich habe zwar noch nicht nachvollziehen können wie man auf die uptime 
Werte kommt, aber dazu muß ich wohl mal in den Python code schauen. Und 
für a_count und opcode existiert bisher noch keine Erklärung. Aber Deine 
Erklärung und Übersetzung von a_code erscheint mir plausibel. Das könnte 
man ggf. auch mal mit einem Schaltnetzteil am Eingang nachprüfen, indem 
man z.B. die Über- und Unterspannungsfehler 215..222 provoziert.

>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1
> Guter Fund!

Das ist ja in einem 0x80 Request (hier 0x0B) Zeitsetzen und Status 
abfragen.

Kann man bei den beiden Statuslog 0x11 und Errolog 0x12 Requests evtl. 
darüber einen Offset mitgeben, damit man nur die letzten X-Meldungen 
geschickt bekommt ?

[Jan-Jonas S. (janjonas_s)]

isnoAhoy schrieb:
> noch nicht nachvollziehen können wie man auf die uptime
> Werte kommt

ich bin mir auch unsicher. Hab lange probiert das mit unterschiedlichen 
typen-mappings zu dekodieren und Muster zu erkennen. Hab ja selber auch 
0 Dokumentation dazu, was ich da überhaupt erwarten könnte. Hab ja auch 
keine S-Cloud oder DTU zum probieren. Glaube dann währe das Protokoll 
schon fertig analysiert. :D
> für a_count und opcode existiert bisher noch keine Erklärung.

a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass 
das letzte byte payload[40:42] in der 800b response den aktuellen 
Zählerstand angibt. So kann die DTU ein 8011 initiieren, wenn er 
incrementiert um den neuen Log-Eintrag abzurufen. Würde Sinn machen, 
muss ich aber noch genauer beobachten. Das es den Zählerstand irgendwie 
gibt steht in der DTU-Pro Modbus Tech-Note [1] und der Manual von den 
jeweiligen Invertern drin.

> Erklärung und Übersetzung von a_code erscheint mir plausibel.

Zufallsfund.

> man ggf. auch mal mit einem Schaltnetzteil am Eingang nachprüfen, indem
> man z.B. die Über- und Unterspannungsfehler 215..222 provoziert.

Freiwillige vor :D

>>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über
>>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off)
>>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1
>> Guter Fund!

Stehen die Schaltaktionen im 8011 Log? Ist die Zahl vielleicht ein 
message ack von der DTU?

> Das ist ja in einem 0x80 Request (hier 0x0B) Zeitsetzen und Status
> abfragen.

Ich würde generell sagen Poll. "Zeit setzen" scheint bei vielen (allen?) 
Commands außer re-transmit mit dabei zu sein. Weil ich vermute, dass der 
WR keine RTC besitzt, sondern die Zeit mit jedem Kommando mit bekommt.

> Kann man bei den beiden Statuslog 0x11 und Errolog 0x12 Requests evtl.
> darüber einen Offset mitgeben, damit man nur die letzten X-Meldungen
> geschickt bekommt ?

Gibt nix gutes, außer man tut es. :)

Müsste man mal mehr Mitschnitte von einer DTU haben um die Bedeutung der 
bytes hinter der Zeit zu erraten. Weil die 18 byte zu brute-forcen, wenn 
man nichtmal weiß wonach man sucht, ist aussichtslos. VOr allem über die 
Zeit mal so beobachten, was die da noch so kommuniziert.
Vor allem währe interessant, ob die modbus-Abfragen direkt an den WR 
durchgereicht werden oder aus dem DTU cache kommen. Wenn die direkt 
durch gehen dürfte es sehr leicht sein das nach zu bauen. Zudem hätte 
man Referenzwerte, dass man wenigstens weiß wonach man in den riesen 
random dekodierten Zahlenhaufen ausschau halten muss.

Gurß,
Jan

[1] 
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

[Pintopf (Gast)]

rosch99 schrieb:
> Ok, du verwendest NodeRed, damit ist es einfach.
> Versuch mal /inverter/# zu subscriben und einen debug node dranzuhängen,
> das  # entspricht im MQTT einem *. Du bekommst dann alle Topics und
> Werte als String im debug fenster und kannst dir die passenden
> raussuchen.

Hallo Rosch, genauso habe ich es jetzt gemacht, mein MQTT Sniffer zeigt 
jetzt auch alle Daten an.


Ich fand hier:
https://www.hivemq.com/mqtt-essentials/
die entscheidenden Hinweise.
Allerdings steht dort auch, dass der Slash (/) nicht an erster Stelle im 
Topic stehen sollte.

Allerdings werden die Daten sekündlich aktualisiert, der Parameter auf 
dem Web-UI hat bei mir auf die Aktualisierungsrate keinen Einfluss.

Viele Grüße,
Peter

[Jan-Jonas S. (janjonas_s)]

Jan-Jonas S. schrieb:
> a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass
> das letzte byte payload[40:42] in der 800b response den aktuellen
> Zählerstand angibt

Confirmed

2022-05-12 08:56:31.787164 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 11 00 62 7c af 9c 00 00 00 00 00 00 00 00 72 99 58
2022-05-12 08:56:31.847991 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 00 01 80 01 00 06 31 e3 31 e3 00 00 00 00 80 02 90
2022-05-12 08:56:31.883198 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 00 07 3b 9c 3b 9c ff ff ff fa 80 02 00 08 3b 9c b8
2022-05-12 08:56:31.917849 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 3b 9c 00 00 00 06 80 02 00 09 60 b1 60 b1 ff ff bc
2022-05-12 08:56:31.987761 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 ff fb 80 02 00 0a 60 c2 60 c2 00 00 00 05 80 02 9a
2022-05-12 08:56:32.028280 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 00 0b 60 d9 60 d9 ff ff ff fb 80 02 00 0c 60 dd ac
2022-05-12 08:56:32.092314 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 60 dd 00 00 00 05 80 02 00 0d 61 79 61 79 ff ff a4
2022-05-12 08:56:32.132800 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 87 ff fb 80 02 00 0e 61 81 61 81 00 00 00 05 cd 30 62
2022-05-12 08:56:32.637981 Payload: 00 01 80 01 00 06 31 e3 31 e3 00 00 00 00 80 02 00 07 3b 9c 3b 9c ff ff ff fa 80 02 00 08 3b 9c 3b 9c 00 00 00 06 80 02 00 09 60 b1 60 b1 ff ff ff fb 80 02 00 0a 60 c2 60 c2 00 00 00 05 80 02 00 0b 60 d9 60 d9 ff ff ff fb 80 02 00 0c 60 dd 60 dd 00 00 00 05 80 02 00 0d 61 79 61 79 ff ff ff fb 80 02 00 0e 61 81 61 81 00 00 00 05 cd 30
 payload has valid modbus crc
80 01 00 06 31 e3 31 e3 00 00 00 00: 
 uptime=3:32:51 a_count=6 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 6, 12771, 12771, 0, 0)
80 02 00 07 3b 9c 3b 9c ff ff ff fa: 
 uptime=4:14:20 a_count=7 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 7, 15260, 15260, 65535, 65530)
80 02 00 08 3b 9c 3b 9c 00 00 00 06: 
 uptime=4:14:20 a_count=8 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 8, 15260, 15260, 0, 6)
80 02 00 09 60 b1 60 b1 ff ff ff fb: 
 uptime=6:52:33 a_count=9 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 9, 24753, 24753, 65535, 65531)
80 02 00 0a 60 c2 60 c2 00 00 00 05: 
 uptime=6:52:50 a_count=10 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 10, 24770, 24770, 0, 5)
80 02 00 0b 60 d9 60 d9 ff ff ff fb: 
 uptime=6:53:13 a_count=11 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 11, 24793, 24793, 65535, 65531)
80 02 00 0c 60 dd 60 dd 00 00 00 05: 
 uptime=6:53:17 a_count=12 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 12, 24797, 24797, 0, 5)
80 02 00 0d 61 79 61 79 ff ff ff fb: 
 uptime=6:55:53 a_count=13 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 13, 24953, 24953, 65535, 65531)
80 02 00 0e 61 81 61 81 00 00 00 05: 
 uptime=6:56:01 a_count=14 opcode=128 a_code=2 a_text=Producing power
 BBHHHHH: (128, 2, 14, 24961, 24961, 0, 5)
2022-05-12 08:56:32.645194 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 12 00 62 7c af 9c 00 00 00 00 00 00 00 00 71 9a 5b
2022-05-12 08:56:32.702398 Received 15 bytes channel 75: 95 72 22 01 43 72 22 01 43 81 00 01 70 c0 a5
2022-05-12 08:56:33.204835 Payload: 00 01 70 c0
 payload has valid modbus crc
Poll inverter 114172220143
2022-05-12 08:56:33.206615 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 7c af a1 00 00 00 05 00 00 00 00 39 42 ea
2022-05-12 08:56:33.258071 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 8c
2022-05-12 08:56:33.293355 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 ec
2022-05-12 08:56:33.363660 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 03 00 a1 03 e8 01 6c 00 0f 42 e7 98
2022-05-12 08:56:33.866489 Payload: 00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 00 03 00 a1 03 e8 01 6c 00 0f 42 e7
2022-05-12 08:56:33.866489 Decoded: 36.4 phase0=voltage:229.1, current:16.1, power:369.6, frequency:49.99 string0=voltage:32.2, current:5.98, power:192.7, total:49.378, daily:211 string1=voltage:32.4, current:6.01, power:194.3, total:47.099, daily:215

wobei

~ # 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 struct
>>> struct.unpack('>HHHHHHLLHHHHHHHHHHH', bytes.fromhex('00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 00 03 00 a1 03 e8 01 6c 00 0f 42 e7')[:42])
(1, 322, 598, 1927, 324, 601, 127336448, 3236036608, 47099, 211, 215, 2291, 4999, 3696, 3, 161, 1000, 364, 15)

Oben sind doch erst 14 Fehler im Speicher? Richtig. Dazwischen ist aber 
noch der 8012-Request (leer). Der setzt einen zusätzlichen Fehler (code 
2). 15.

Gruß,
Jan

[rosch99 (Gast)]

Pintopf schrieb:
> Ich fand hier:
> https://www.hivemq.com/mqtt-essentials/
> die entscheidenden Hinweise.
> Allerdings steht dort auch, dass der Slash (/) nicht an erster Stelle im
> Topic stehen sollte.

Ja, im Gegensatz zu filesystemen ist das bei MQTT nicht üblich.
Dazu muss aber der Default-Eintrag in der setup page geändert werden, 
ich habe das bei mir angepasst. Ebenso sollte am Ende kein / stehen, das 
wird aut. angehängt. Ich habe das auch erst mit dem Sniffer bemerkt weil 
nix "angekommen" ist ;-)

[Hubi (Gast)]

Hallo zusammen
ich logge nun seit mehreren Wochen die Werte meines HM-600 alle 5 
Minuten pro Tag mit. Wenn ich mir die Tagesendezahlen ansehe fällt mir 
folgendes auf:
1) Ertrag Woche steigt permanent an; das sollte doch eigentlich immer in 
etwa gleich sein.
2) Die Differenz von 2 Tagen Ertrag Woche und 2 Tagen Ertrag gesamt 
passt nie.
3) die Differenz Tagesanfang zu Tagesende von Ertrag Woche und Ertrag 
Gesamt sollte doch gleich sein, aber passt auch nie; da gibt da 
Differenzen bis über 100 Wh.
4) Ertrag Total kann nicht stimmen, denn wenn ich meine Dachanlage von 
3,87 KWp runterrechne auf 0,6 KWp müsste der Gesamtertrag mindestens 
doppelt so hoch sein.

Hat schon jmd ähnliches beobachtet oder sind die beiden Werte was ganz 
anderes?

[Thomas B. (tbnobody)]

Hubi schrieb:
> Hat schon jmd ähnliches beobachtet oder sind die beiden Werte was ganz
> anderes?

Hallo Hubi,

ich gehe davon aus du nutzt die ESP8266 Version aus [1]?

In dieser Version stimmt die Byte Zuordnung vmtl. nicht. Dies hängt auch 
damit zusammen, dass hier wohl noch keine Fragmentübergreifenden 
Datenwerte unterstützt werden (diese kommen laut aktuellem Stand wohl 
nur beim HM-600 vor).

Die Python Version implementiert dies bereits.

Hintergrund ist, dass der Wert der beim HM-600 als Weekly Wert angegeben 
wird in Wahrheit der Total Wert für den 2. Kanal ist. Dieser läuft aber 
ggf. wöchentlich über. Der Überlauf wird in einem anderen Datenfragment 
übertragen (man müsste wie im Python Code alle übertragenen Fragmente 
zusammenfügen und Auswerten)

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

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
> Jan-Jonas S. schrieb:
>> a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass

Hallo Jan,
leider kann ich kein py.
So wie ich es verstehe, ergibt sich z.B. bei mir folgender zerlegter 
Block (Hand bearbeitet):

W1   W2   W3   W4   W5   W6
B1 2  3 4  5 6  7 8 9 10 11 12
0001                             Hex    Dez
8001 0006 1698 1698 0000 0000 ; 1698 > 5784 /60 = 96 /60=1:36:xx ;
8002 0007 4F16 4F16 FFFF FFDF ; 4F16 > 20246/60 = 337/60=5:37:xx ;
8002 0008 5CC9 5CC9 FFFF F261 ; 5CC9 > 23753/60 = 395/60=6:35:xx ;F2=242
8002 0009 5D0E 5D0E FFFF FFA7 ; 5D0E > 23822/60 = 397/60=6:37:xx ;
8002 000A 641D 641D FFFF F8F1 ; 641D > 25629/60 = 427/60=7:07:xx ;F8=248
8002 000B 64DE 64DE FFFF FF3F ; 64DE > 25822/60 = 430/60=7:10:xx ;
8002 000C 657D 657D FFFF FF61 ; 657D > 25981/60 = 433/60=7:13:xx ;
8002 000D 6679 6679 FFFF FF18 ; 6679 > 26233/60 = 437/60=7:17:xx ;
8002 000E 754A 754A FFFF F12F ; 754A > 30026/60 = 500/60=8:00:xx ;F1=241
34E7

a) Nur was sollen mir die Worte W1 bis W6 sagen ?
Ich habe gegen 12:41 Uhr mit der Aufzeichnung begonnen.
Der WR arbeitet aber schon sehr viel früher.
Also "Uptime" in der Zeile 8001 mit 1:36:xx kann nicht sein.

b) Welches Wort/Byte (W1 bis W6/B1 bis B12) soll Bitte der Alarmcode 
sein?

[Pintopf (Gast)]

Zu deiner Feststellung:
Hubi schrieb:
> 4) Ertrag Total kann nicht stimmen, denn wenn ich meine Dachanlage von
> 3,87 KWp runterrechne auf 0,6 KWp müsste der Gesamtertrag mindestens
> doppelt so hoch sein.

zitiere ich mich mal selber:

Pintopf schrieb:
> Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge
> (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic
> gemessenen Werte.
> Jetzt habe ich mir mal die RF24 Payload über die serielle Schnittstelle
> ausgeben lassen und nach den fehlenden Daten gesucht. In dem Bild im
> Anhang habe ich den vermeindlichen Fundort markiert.
> Könnte jemand von euch das verifizieren?


Danke für die Mitteilung, dass es bei dir genauso ist.
In meinem Originalbeitrag habe ich auch die Stelle im Datenfeld 
markiert, wo ich den Gesamtertrag des ersten Moduls vermute.


Gruß
Peter

[Jan-Jonas S. (janjonas_s)]

Herbert K. schrieb:
> b) Welches Wort/Byte (W1 bis W6/B1 bis B12) soll Bitte der Alarmcode
> sein?

Hier 
https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py#L310 
ist die zeile, wo ich zuordne.

Lass mich versuchen das ein wenig zu veranschaulichen

opcode, a_code, a_count, uptime, u, u, u = struct.unpack('>BBHHHHH', chunk)

B   B   H      H      H      H      H
00  d4  00 07  30 6a  00 00  00 00  00 00
|   |   |      |
|   |   |      \_ uptime seconds(?) 
|   |   \_ a_count
|   \__ a_code
\_ opcode

Das schöne an python ist, geht auch interaktiv.

Auf der Konsole am Beispiel von Thomas die Payload von "Port 4 no input"

~ # 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 struct
>>> struct.unpack('>BBHHHHH', bytes.fromhex('00 d4 00 07 30 6a 00 00 00 00 00 00'))
(0, 212, 7, 12394, 0, 0, 0)
>>>

Alle Zeilen mit ">>>" sind manuelle Eingaben. So kann man recht fix und 
effektiv an den Payloads rum doktorn. `import struct` macht das Modul 
struct verfügbar.
struct.unpack string '>' endian-big, 'B' sind 2 byte (unsigned char), 
'H' sind 4 byte (unsigned short)

chunk = bytes.fromhex('00 11 22 33 44 55')
wandelt einen schön lesbaren byte string in ein byte array um, mit dem 
struct arbeiten kann.

Gruß,
Jan

[Herbert K. (avr-herbi)]

Jan-Jonas S. schrieb:
> Herbert K. schrieb:
...
> B   B   H      H      H      H      H
> 00  d4  00 07  30 6a  00 00  00 00  00 00
> |   |   |      |
> |   |   |      \_ uptime seconds(?)
> |   |   \_ a_count
> |   \__ a_code
> \_ opcode

DANKE Jan !

[Jan-Jonas S. (janjonas_s)]

Noch schöner ist, man kann die Decoder auch so auf der Konsole 
ausprobieren

Im Verzeichnis tools/rpi/ python3 ausführen:

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
>>> hoymiles.decoders.HM1200_Decode11(bytes.fromhex('00 01 80 01 00 06 30 62 30 62 00 00 00 00 00 d4 00 07 30 6a 00 00 00 00 00 00 b0 02 00 48 4c f7 4c f7 00 00 00 05 b0 02 00 49 55 da 55 da ff ff ff fb b0 02 00 4a 55 ed 55 ed 00 00 00 05 b0 02 00 4b 56 72 56 72 ff ff ff fb b0 02 00 4c 56 72 56 72 00 00 00 06 b0 02 00 4d 56 79 56 79 ff ff ff fb b0 02 00 4e 56 82 56 82 00 00 00 05 b0 02 00 4f 56 e7 56 e7 ff ff ff fb b0 02 00 50 56 f3 56 f3 00 00 00 05 b0 02 00 51 57 1d 57 1d ff ff ff fb b0 02 00 52 57 23 57 23 00 00 00 05 b0 02 00 53 57 4f 57 4f ff ff ff fb b0 02 00 54 57 51 57 51 00 00 00 05 05 ab'))
 payload has valid modbus crc
80 01 00 06 30 62 30 62 00 00 00 00: 
 uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start
 BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0)
00 d4 00 07 30 6a 00 00 00 00 00 00: 
 uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input
 BBHHHHH: (0, 212, 7, 12394, 0, 0, 0)
b0 02 00 48 4c f7 4c f7 00 00 00 05: 
 uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5)
b0 02 00 49 55 da 55 da ff ff ff fb: 
 uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531)
b0 02 00 4a 55 ed 55 ed 00 00 00 05: 
 uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5)
b0 02 00 4b 56 72 56 72 ff ff ff fb: 
 uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531)
b0 02 00 4c 56 72 56 72 00 00 00 06: 
 uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6)
b0 02 00 4d 56 79 56 79 ff ff ff fb: 
 uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531)
b0 02 00 4e 56 82 56 82 00 00 00 05: 
 uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5)
b0 02 00 4f 56 e7 56 e7 ff ff ff fb: 
 uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531)
b0 02 00 50 56 f3 56 f3 00 00 00 05: 
 uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5)
b0 02 00 51 57 1d 57 1d ff ff ff fb: 
 uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531)
b0 02 00 52 57 23 57 23 00 00 00 05: 
 uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5)
b0 02 00 53 57 4f 57 4f ff ff ff fb: 
 uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531)
b0 02 00 54 57 51 57 51 00 00 00 05: 
 uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power
 BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5)

import hoymiles # läd das Modul hoymiles
# hoymiles.decoders korrespondiert zu hoymiles/decoders/__init__.py
hoymiles.decoders.HM1200_Decode11(bytes payload)

HM1200_Decode11 erwartet als Argument die payload bytes. Die kann man 
sich wieder mit bytes.fromhex() aus dem lesbaren String aus den Logs hin 
konvertieren und mit einer Payload so oft wie man will verschiedene 
Änderungen am Code ausprobieren.

[Siggi U. (sude)]

Moin,
ich habe seit gestern auch einen HM-1500 im Einsatz, es sollen noch ein 
paar weitere folgen.
Ich nutze einen ESP8266 mit dem Funkmodul und der Ahoi-Software.

Das Auslesen und Anzeigen der Werte per Weboberfläche hat auf Anhieb 
geklappt, ich bin begeistert.

Danke an die Community für dieses starke Projekt.

Ich versuche auch meinen Teil beizutragen, falls es irgendwie möglich 
ist.

Im MQTT war mir aufgefallen, dass die Werte trotz Einstellung von 10s 
Intervall im Sekundentakt gesetzt wurden. Ich habe den Wert dann mal 
höher gesetzt, aber nach einiger Zeit war der 1s Intervall wieder da.

In der Datei
\tools\esp8266\app.cpp
sollte es in der Zeile 181 wahrscheinlich

mMqttTicker = 0;

statt

mMqttInterval = 0;

sein, damit klappt es bei mir jedenfalls.
Leider wird mir im Git-Commit die ganze Datei als Änderung angezeigt 
statt nur der einen Zeile, ich versuche zu klären warum und mache dann 
einen PullRequest wenn gewünscht. Aber die kleine Änderung könnte ja 
auch jemand anderes schnell übernehmen.

Gruß, sude

[ST2 (Gast)]

Hallo, erst einmal vielen Dank für die tolle Software, sie funktioniert 
ausgezeichnet mit meinem HM-400.

Nun eine Frage an die Experten:

Ich habe an meinem Smart-Meter bereits einen Energieverbrauchsmanager 
von Iungo (www.iungo.nl) angeschlossen, der kann auch Solaranlagen über 
einen Modbus Energiezähler monitoren, dazu kann mann z.B. einen Standard 
RS485 Modbus/USB Adapter verwenden und ihn in den USB Port vom Iungo 
verbinden. Ich frage mich nun ob ich nicht den Wemos D1 mini in den USB 
Port stöpseln könnte um einen Modbus Energiezähler und USB Adapter zu 
emulieren. Würde das funktionieren und was müsste ich grob dafür 
implementieren?

Vielen Dank für die Hilfe.

Grüße,
Stefan

[Daniel R. (daniel92)]

Hallo zusammen,

ich habe seit heute auch einen HM-1500. =)

Würde hier beim reenginering mit Unterstützen.
Gibt es hier zufällig jemand der auf Github etwas voran getragen hat was 
man alles braucht?

Ich habe bei mir noch mehrere ESP8266 und irgendwo in der schublade 3x 
NRF24LE1E.

Um hier zwecks logging zu helfen, wie wird es miteinander verdrahten und 
auf welcher Basis wird das ganze in das ESP geflasht?

Ich würde mir heute wenn ich dazu komme die App decompilen und mir 
schauen ob man weitere Interessante Infos rausziehen kann.

PS: Wie wäre es mit einem IRC-Chat und/oder Discord, dann könnte man 
doch mal ein Abend damit verbringen sich zusammen das anzuschauen. Was 
sagt ihr dazu?

Beste Grüße.

[Daniel R. (daniel92)]

Hallo,

kleiner Fortschritt (weiß nicht inwieweit das vom Nutzen her hilft):

this.memoizedIsInitialized = (byte) -1;
this.pvSn_ = 0L;
this.pvPort_ = 0;
this.pvVol_ = 0;
this.pvCur_ = 0;
this.pvPower_ = 0;
this.pvEnergyTotal_ = 0;
this.gridVol_ = 0;
this.gridVolMax_ = 0;
this.gridFreq_ = 0;
this.gridP_ = 0;
this.gridQ_ = 0;
this.gridI_ = 0;
this.gridPf_ = 0;
this.pvTemp_ = 0;
this.pvRunStatus_ = 0;
this.pvFaultNum_ = 0;
this.pvFaultCnt_ = 0;
this.pvWarnningCnt_ = 0;
this.pvLinkStatus_ = 0;
this.pvSendP_ = 0;
this.pvRevP_ = 0;
this.pvTime_ = 0;
this.pvEnergy_ = 0;
this.miSignal_ = 0;

So bin später wieder aktiv da.

[isnoAhoy (Gast)]

Hallo Stefan,
das mit dem Modbus Energiezähler der dann an den ESP angeschloßen wird 
klingt interessant. Ob das an dem Modell von Dir so einfach geht kann 
ich nicht sagen, da ich keine Ahnung habe was der für Kommandos über 
Modbus absetzt, oder ob der nur abgefragt werden kann ?
Auf der anderen Seite der ESP8266 mit Ahoy Software ist aktuell auch 
noch nicht so weit, daß er bereits Kommandos an die Hoymiles 
Wechselrichter senden könnte. Wir können m.W. bisher nur lesen, die 
aktuellen Leistungsdaten 0x0B und den Ereignis- 0x11 bzw. Fehlerspeicher 
0x12.
Die Modbus Kommandos, die z.B. die Hoymiles DTU Pro versteht und 
unterstützt kann unsere Software (Python oder ESP) bisher auch noch 
nicht.

Hallo Daniel,
die ESP Verdrahtung ist im Verzeichnis doc/getting-started-ESP8266:

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

Viel Erfolg beim basteln und kompilieren. Was die Liste der Definitionen 
von Dir angeht, hab ich keine Ahnung wie uns das so weiterhelfen soll, 
vielleicht kannst Du noch ein bisschen mehr dazu schreiben. Andererseits 
sind in tools/esp8266/hmDefines.h die entsprechenden Felder der Payloads 
bereits hinterlegt. Lukas arbeitet aktuell daran die Frames/Pakete 
einzeln zu verifizieren und dann die gesamte Payload auf einmal zu 
lesen. Da steht ja auch nochmal eine CRC16/CRC_M Prüfsumme am Ende (0x8y 
Paket).

https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h#L59

[isnoAhoy (Gast)]

Hallo Stefan,
hier ist die Anleitung zum Modbus Adapter Deiner iungo Anlage:
https://www.iungo.nl/images/pdf/handleiding_modbus_16012019.pdf
Die Anleitung habe ich nur auf niederländisch gefunden. Maar meijn 
Nederlands is nit prittig.
Auf dem Titelbild ist ein Eastron SDM630/Modbus V2 abgebildet. Hast Du 
den auch ?

[Daniel R. (daniel92)]

Moin zusammen,

@isnoAhoy: vielen dank für die Info mit der Verdrahtung. Das werde ich 
mir anschauen und das ganze mal in Ruhe Aufbauen. :)

Zu meiner Infos von weiter oben, da gebe ich dir recht und hole noch 
etwas weiter aus.
Ich habe in der Vergangenheit auch bei anderen Programmen reingeneering 
durchgeführt (Haupts. nur C# decompiliert).

Nun da ich kein Programm habe um es mir am PC anzuschauen, habe ich 
einfach die App im Google Appstore angeschaut. Da ich mit Java kaum was 
am Hut habe, ist es für mich hier etwas schwierig passende Infos raus zu 
ziehen.

Die Infos oben ist ein Schnipsel von der App "S-Miles Endbenutzer". - 
Das ist doch die App?

Es bringt denke ich soweit uns an Infos was alles damit ausgelesen 
werden kann. Natürlich fehlen bestimmt weitere Dinge (Volt, Ampere, 
Watt, Blindleistung, Leistungsfaktor (Pf.), ...).

Im Anhang mal ein Screenshot. Ich muss noch schauen wie die App genauer 
Aufgebaut ist.
Oder gibt es ein PC Programm wo man es Runterladen kann? :)

[isnoAhoy (Gast)]

Hallo Daniel,

jetzt hast Du mich neugierig gemacht, ich habe zwei Apps von Hoymiles 
gefunden:
S-Miles Enduser und S-Miles Installer. Welche hast Du denn runtergeladen 
und vor allem wie ? Ich finde keinen Link zum Download auf dem PC.

https://play.google.com/store/apps/developer?id=Hoymiles+Converter+Technology+Co.,+Ltd.&gl=US

Welchen Decompiler hast Du verwendet ? Ich habe meist gute Ergebnisse 
mit jd-gui von Emmanuel Dupuy gehabt. Auch der Support ist Klasse, falls 
mal was nicht geht, so wie Lambda Functions, dann hatte er das innerhalb 
von wenigen Tagen eingebaut!

https://github.com/java-decompiler/jd-gui/

Das Ganze ist dann zwar nur die Mobile App, die mit der DTU kommuniziert 
und vermutlich nicht alles abdeckt, was z.B. die DTU Pro über den Modbus 
einstellen kann, aber es wäre immerhin eine gute Option herauszufinden, 
was die App mit den ersten vier Stellen der Seriennummer macht, bzw. wie 
die Datenpakete von der DTU zur App übertragen werden...

[Sorbit (Gast)]

https://youtu.be/5m5caOjApVw

[J.Rasper (Gast)]

Hallo zusammen. Wenn es nur um das Monitoring des Ertrags geht, waere 
das Shelly Plug hier nuetzlich 
(https://www.gartenkraftwerke.de/c/unsere-pakete/zubehoer). Das Teil 
baut sein eigenes WLAN auf und bietet eine Webseite, von der man dann 
mit z.B. wget die Daten von Interesse auslesen kann. Das habe ich mit 
einem Kostal 10.1 so gemacht und habe z.B. fuer jede volle Stunde den 
Tagesertrag und den Gesamtertrag ueber die Lebensdauer des WR.

Hoffe, das hilft dem einen oder andern.

[Sorbit (Gast)]

Netsgp ?

https://github.com/atc1441/NETSGPClient

[Daniel R. (daniel92)]

Moin,

richtig es existieren zwei Apps. Die Version "Installer" ist für den 
Techniker für großen Anlagen gedacht (leite ich jetzt mal so heraus).

Für den Endbenutzer gibt es die andere App. Diese konnte ich (wie weiter 
oben beschrieben) mit den Zugangsdaten einloggen und Daten auslesen.

Jetzt muss ich hier jedoch sagen, ich weiß natührlich nicht ob die App 
mit einer DTU direkt kommuniziert (hab keine DTU) und/oder ob es mit der 
Cloud sich verbindet. Die Endbenutzer-App funtioniert bei mir 
anscheinend mit der Cloud.

Ich habe die App bei mir Installiert (direkt aus der Google PlayStore) 
und danach mittels einer weiteren App als apk exportiert (App 
Extractor).

Diese apk, habe ich auf meinem PC übertragen und nutze aktuell JADX-GUI 
(https://github.com/skylot/jadx).

Java ist nicht mein Favorit, da muss ich ehrlich sein.
Jedoch gibt es leider meines wissens nach nur die Weboberfläche und die 
Mobile Variante um die Daten auszuwerten.

-----------------------------------------------

Die Apps sind teils obfuskiert (namen von variabeln sind umbenannt). Das 
Tool JADX leistet hier aber soweit ich das einschätzen kann gute Arbeit 
beim deobfuskieren (Tools -> Deobfuskierung).

Die Hauptstruktur ist von der Baumstruktur so:
/com/hoymiles/... da liegen ganze classen, methoden und co ab.
p000 besitzt auch hier Teils Interessante Daten.

Was mich stutzig macht: Wenn man eine globale Textsuche startet (Info: 
Am Anfang wird die ganze APK dann Dekompiliert. Dauert bevor man eine 
Suche starten kann), dann kam mir auch Methoden/Classen entgegen mit dem 
Namen "Miner". Ich dachte erstmal, wird die App als Miner im Hintergrund 
verwendet? O.o - Naja habe das aber nicht weiter beachtet.

Info: Es gibt ein Indiz das auch die Cloud bei Alibaba gehostet wird.
Einerseits da es als Klasse benammt wird und zweitens die hinterlegten 
Domain:

>ping m.hoymiles.com
Ping wird ausgeführt für m.hoymiles.com [119.3.31.20] mit 32 Bytes 
Daten:
Antwort von 119.3.31.20: Bytes=32 Zeit=312ms TTL=37

Die IP-Adresse zeigt nach China 
(https://ipinfo.io/AS55990/119.3.0.0/19-119.3.31.0/25)

Gruß

[Martin P. (mpolak77)]

Also ich würde mir da nicht zuviel versprechen von den Apps .... ich 
denk' mir, die kommunizieren sicher nur der Hoymiles Cloud .....

a) die App funktioniert ja überall, also muss sie mit der Hoymiles Cloud 
in Verbindung stehen

b) was sollte die App mit der DTU direkt zu bereden haben, wenn die 
Cloud bereits alle Funktionen abbildet.

[Daniel R. (daniel92)]

Moin Martin,

ein Stückweit gebe ich dir hier recht. Jedoch können wir uns doch über 
die App Informationen gewinnen, was für Daten übertragen werden können 
und somit später bei der Indentifizierung uns dabei helfen? - Können die 
App auch gern vorerst beiseite legen und erstmal weiter mit der 
Auswertung kümmern. :)

Idee: Hat schon jemand die den WR ausseinander genommen und mittels 
einem LogicAnalyzer kurz vor dem TX die Daten mitgelauscht und 
gleichzeitig beim Empfänger nach dem RX die Daten verglichen?

[isnoAhoy (Gast)]

Hallo Daniel,

bitte lies erstmal die vorangegangenen 4 Seiten dieses Threads, da steht 
nämlich u.a. wie Martin seine DTU zerlegt und genau am RX/TX zwischen 
GD32 MCU und nRF24 Radio die ersten Mitschnitte gemacht hat. Andere 
haben mit einem HackRF Mitschnitte des Funkverkehrs gemacht. Darauf 
basiert auch der aktuelle Code für ESP (Lukas) als auch die noch 
aktuellere Version für Python (Jan-Jonas)

Aktuell fehlen weitere Mitschnitte für Kommandos die die DTU an den 
Wechselrichter sendet, z.B. aktiv/disabled, Limit setzen, Zero Export 
Control, etc. Die alten Hoymiles String-Wechselrichter hießen MI (= 
MicroInverter), daher stammt vielleicht auch das Präfix Mi in den 
Klassen, Methoden und Variablennamen der App ? Aber Ausschließen will 
ich nichts an der Stelle.

@Sorbit,

ja ich habe Aaron (atc1441) schon gefragt was er von den aktuellen 
Versuchen der Hoymiles Inverter hier im Forum hält. Er hat leider keinen 
HM Wechselrichter und kann daher wenig zur Entwicklung beitragen, obwohl 
ihn das Thema BLE speziell mit nRF52 etc. nach wie vor interessiert. 
Wenn jemand will, kann er ihn ja in Hamburg kontaktieren, vielleicht hat 
er ja ein bißchen Zeit neben seinem neuen Job und schaut mal in einen 
Hoymiles Wechselrichter rein.
Ich habe versucht meinen aufzuschrauben bin aber an den 
Kabelzugentlastungen und der Verklebung der Metallplatte gescheitert. Da 
ich meinen auf dem Balkon installieren möchte sollte er auch weiter 
wasserdicht bleiben. Beim "Freundlichen Händler" meines Vertrauens hat 
man mir auch gesagt, dieser hätte bisher keine Rückläufer mit Defekt, 
die man mal aufschrauben könnte.

[Daniel R. (daniel92)]

Ich habe zwar alle Seiten mir angeschaut, aber bin bei den großen 
Mitschnitten via HackRF nicht komplett durchgegangen. ^^

Cool ist es aufjedenfall was ihr schon alles herausgefunden habt.
Da kann ich definitiv euch nur loben!

Die fehlenden Kommandos die die DTU an den Wechselrichter senden, könnte 
man doch nur mit der DTU-Pro version herausbekommen oder?

Dein Ansatz mit dem Präfix kann gut möglich sein.
Ich bin mir am überlegen so ein Pro zu Organisieren, aber aktuell nicht 
ganz einfach.

https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html

PS: Die Login Daten im Shop kann man auch mit der App nutzen, aber das 
wisst ihr bestimmt schon.

[Peter L. (leliep)]

Meine Prototype mit ESP8266 im Gehäuse. Trotz der dichten Packung 
funktioniert die Kommunikation mit dem WR.

[Daniel R. (daniel92)]

Hallo zusammen,

habe nun alles zusammengebaut...
Leider bekomme ich folgende Meldung:

Warn: your settings are not valid! check [IP]/setup
Was ist denn falsch?

Edit: Hat sich erledigt, ich komme drauf und bin alles am Eintragen.
Die Frage, woher bekomme ich die SNr. habe ein 1500.

[Herbert K. (avr-herbi)]

Daniel R. schrieb:
> Die Frage, woher bekomme ich die SNr. habe ein 1500.

Steht auf der glatten Seite / Rückseite auf 2 Aufklebern.

[Daniel R. (daniel92)]

Danke, boa darauf muss man erstmal kommen. Aber stimmt, wenn ich die 
ersten Zeichen hier Suche gibt es überschneidungen. :)

Mercii!

PS: Spannung kommt von meinem Labornetzteil. Solarmodule brauchen noch 
bis sie da sind. :)

Erste Log:

Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 6D AD 39
Solarkraftwerk/ch3/U_DC: 22.000 V
Solarkraftwerk/ch3/I_DC: 0.010 A
Solarkraftwerk/ch3/P_DC: 0.200 W
Solarkraftwerk/ch4/I_DC: 0.050 A
Solarkraftwerk/ch4/P_DC: 1.200 W
Solarkraftwerk/ch0/Temp: 25.100 °
Solarkraftwerk/ch4/U_DC: 22.000 V
0 (0000) 1 (0001) 2 (0002) 2 (0020)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
AP will be closed in 152 seconds
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FA 00 13 AD FC A9
0 (0000) 1 (0001) 1 (0001) 3 (0030)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 6D AD 39
Solarkraftwerk/ch3/U_DC: 22.000 V
Solarkraftwerk/ch3/I_DC: 0.010 A
Solarkraftwerk/ch3/P_DC: 0.200 W
Solarkraftwerk/ch4/I_DC: 0.050 A
Solarkraftwerk/ch4/P_DC: 1.200 W
Solarkraftwerk/ch0/Temp: 25.100 °
Solarkraftwerk/ch4/U_DC: 22.000 V
0 (0000) 1 (0001) 2 (0002) 2 (0020)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
AP will be closed in 142 seconds
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 6D AD 39
0 (0000) 6 (3003) 2 (0020) 2 (0200)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DD 00 
01 00 05 00 02 4C
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
FB 00 13 FD B1 B5
Solarkraftwerk/ch3/U_DC: 22.100 V
Solarkraftwerk/ch3/I_DC: 0.010 A
Solarkraftwerk/ch3/P_DC: 0.200 W
Solarkraftwerk/ch4/I_DC: 0.050 A
Solarkraftwerk/ch4/P_DC: 1.200 W
Solarkraftwerk/ch0/Temp: 25.100 °
Solarkraftwerk/ch4/U_DC: 22.100 V
0 (0000) 5 (2003) 3 (0030) 2 (0200)  -> missing: 1
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
0 (0000) 0 (0000) 0 (0000) 0 (0000)  -> missing: 4
AP will be closed in 132 seconds
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 
01 00 05 00 02 4D
Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 9A
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
F9 00 13 AD 0C 5A

[Socke (Gast)]

“Danke, boa darauf muss man erstmal kommen.”

Handbuch lesen sollte wohl möglich sein;-(
Auch mit Schreib- und Leseschwäche…

[isnoAhoy (Gast)]

Hallo Daniel,

wo Du doch schon den Source Code der App decompiliert hast. Wir haben 
eine Liste mit Status / alarm_codes von den Wechselrichtern. Kannst Du 
mal schauen ob Du die auch irgendwo im App Code findest ?

https://github.com/Sprinterfreak/ahoy/commit/e473583a5536b4f8ffb7099d3510912db84928a1

[Daniel R. (daniel92)]

Hallo Ahoy,

ich schau mal fix drauf. Rest mach ich morgen. :)
Wenn ich gleich noch was finde, gebe ich eine Rückmeldung.

Gibt es die möglichkeit die Logs irgendwo gesammelt zusammen zu tragen?
Vielleicht können auch andere Infos herauslesen die Interessant sind, 
was denkt ihr?

Edit: --------------------------------

Folgendes konnte ich auf anhieb finden (code gekürzt):

private APPDtuInfoMO(CodedInputStream input, ExtensionRegistryLite 
extensionRegistry) throws InvalidProtocolBufferException {
            this();
            boolean z = false;
            while (!z) {
                try {
                    try {
                        int readTag = input.readTag();
                        switch (readTag) {
                            case 0:
                                break;
                            case 8:
                                this.deviceKind_ = input.readInt32();
                                continue;
                            case 16:
                                this.dtuSw_ = input.readInt32();
                                continue;
                            case 24:
                                this.dtuHw_ = input.readInt32();
                                continue;
                            case 32:
                                this.dtuStepTime_ = input.readInt32();
                                continue;
                            case 40:
                                this.dtuRfHw_ = input.readInt32();
                                continue;
                            case 48:
                                this.dtuRfSw_ = input.readInt32();
                                continue;
                            case 56:
                                this.accessModel_ = input.readInt32();
                                continue;
                            case 64:
                                this.communicationTime_ = 
input.readInt32();
                                continue;
                            case 72:
                                this.signalStrength_ = 
input.readInt32();
                                continue;
                            case 82:
                                this.gprsVsn_ = input.readBytes();
                                continue;
                            case 90:
                                this.wifiVsn_ = input.readBytes();
                                continue;
                            case 98:
                                this.kaNub_ = input.readBytes();
                                continue;
                            case 104:
                                this.dtuRuleId_ = input.readInt32();
                                continue;
                            case 112:
                                this.dtuErrorCode_ = input.readInt32();
                                continue;
                            case 120:
                                this.dtu485Mode_ = input.readInt32();
                                continue;
                            case 128:
                                this.dtu485Addr_ = input.readInt32();
                                continue;
                            case 136:
                                this.sub1GFqband_ = input.readInt32();
                                continue;
                            case 144:
                                this.sub1GChtnum_ = input.readInt32();
                                continue;
                            case 152:
                                this.sub1GChnum_ = input.readInt32();
                                continue;
                            case Opcodes.IF_ICMPNE /* 160 */:
                                this.sub1GRp_ = input.readInt32();
                                continue;
                            case 168:
                                this.sub1GChtotal_ = input.readInt32();
                                continue;
                            case Opcodes.GETSTATIC /* 178 */:
                                this.gprsImei_ = input.readBytes();
                                continue;
                            default:
                                if (!input.skipField(readTag)) {
                                    break;
                                } else {
                                    continue;
                                }
                        }
                        z = true;
                    } catch (InvalidProtocolBufferException e) {
                        throw e.setUnfinishedMessage(this);
                    } catch (IOException e2) {
                        throw new 
InvalidProtocolBufferException(e2).setUnfinishedMessage(this);
                    }
                } finally {
                    makeExtensionsImmutable();
                }
            }
        }

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> Erste Log:
>
> Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00
> 01 00 05 00 02 4D
> Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 9A
> Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00
> FB 00 13 6D AD 39

Die Payload währe:
( 16 byte fehlen ) 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 FB 00 13 6D AD

Wobei 6D AD die Modbus CRC ist. Natürlich falsch, weil die Payload nicht 
vollständig ist. Irgendwie fehlt da immer das erste Fragment. Aus den 
Logs lassen sich so keine korrekten Daten lesen.

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> Gibt es die möglichkeit die Logs irgendwo gesammelt zusammen zu tragen?

Gute Idee.

Man müsste sich dann noch auf das Format einigen.
Den Output, wie es das python-script macht kann ich jederzeit wieder 
parsen.

Zeilen mit
- "Transmit" beginnen eine Transaktion oder sind ein Re-Transmit
- "Received" werden als Fragment gelesen und der zuvor gestarteten 
Transaktion appended
- "Payload" (mit crc) werden statt den Received-Fragmenten anhand der 
Transmit-Payload direkt dekodiert

gefolgt von den byte hexlified rohdaten dahinter.

> private APPDtuInfoMO(CodedInputStream input, ExtensionRegistryLite
> ...

sieht sehr nach den technischen Daten der DTU aus und ist damit eher 
uninteressant. Wir wollen ja den WR und nicht die DTU abfragen.

Trotzdem währe es aber interessant ob die App Rohdaten über die DTU zum 
WR senden kann. Wenn es also irgendwelche tx payloads gäbe könnte man 
das mal an die WR senden und gucken was passiert.

Gruß,
Jan

[isnoAhoy (Gast)]

Hallo Lukas P.,
kannst Du den Feature Request noch aufnehmen, d.h. die Daten mit 
Transmit und Received per Serial (ggf. auch WebSerial oder MQTT o.a.) 
im "Unified Format" mitzuloggen, damit man die Daten auch mit dem Python 
Code nachverarbeiten könnte ?
Es gibt zwar ein paar Zeilen, die bereits die "sent packet: #" und "RAW 
/ CMD" im entsprechenden Format ausgeben.
Diese sind jedoch meist inaktiv und ich muss die immer von Hand 
einschalten vor dem Kompilieren, damit ich die Rohdaten sehe.

Transmit
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L239-L240
Received
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L142-L151

Bzgl. der blauen LED auf dem NodeMCU / Wemos D1 mini ist es evtl. keine 
so gute Idee gewesen den Anschluss D4 (GPIO2) für CE des nRF24 Moduls zu 
verwenden. Sobald CE low wird leuchtet die blaue LED. Das passiert wohl 
auch im Falle eines TX per Serial IO.

Soll ich die Fritzing Layouts nochmal anpassen und gibt es eine 
empfohlene Verdrahtung, bzw. sollten noch andere GPIOs evtl. nicht / 
anders verwendet werden ?

https://www.computerhilfen.de/info/esp8266-blaue-led-ausschalten-oder-blinken-lassen.html

Aktuell ist die Belegung in der getting started ESP8266 Dokumentation:

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

Wire Connections

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

[Daniel R. (daniel92)]

Also cool wäre es, wenn man in das Webinterface von ESP drauf 
zugreift... das man dort aktzeptiert die Logs irgendwo gesammelt 
hochzuladen.
Dann könnte man mittels Datenbank, das ganze super analysieren.

Problem nur: Datenschutz... aber die meisten, die das Projekt 
Unterstützen wollen würden das Freiwilig ja machen. :) Mich 
eingeschlossen.

Habe ich richtig gelesen, du betreibst das NRF24L01+ direkt am Raspi?
Würde ich dann nähmlich bei mir auch umbauen und direkt alles auf dem Pi 
ablegen und verwalten. Aktuell habe ich alles auf einem Breadboard am 
Tisch.

Wenn ich heute Zuhause bin, kann ich mal weiter decompilen und schauen 
ob ich was finde.

Nachtrag: Gern kann ich zusätzlich später mit meinem gebastelten DVB-T 
mal die Frequenzen anschauen, ob sich da was auffäliges verhält. Bzgl. 
Channel Hopping oder ob vlt sogar auf mehrere Kanälen gleichzeitig 
gefunkt wird? (nur eine Mutmassung)

[David (Gast)]

Hallo Zusammen,
ist das RF module von Kuman nRF24L01+PA+LNA ist dafür auch zu nutzen?
Gruss
david

[Daniel R. (daniel92)]

Hallo David,

sollte soweit ich weiß auch gehen. Die Endungen sagen soweit ich weiß 
nur aus das es mit einer extra Antenne versehen ist, statt einer auf dem 
PCB.

Korrigiert mich wenn ich falsch liege. :)

[David B. (mystisch)]

Hallo Daniel,

gut danke Dir. Im Moment bekomme ich keine Verbindung zum Inverter, 
nicht dass ich weiter den Fehler suche und dabei ist das RF Modul das 
Falsche ;)

Grad war ich irgendwie nicht angemeldet.

david

[Daniel R. (daniel92)]

Wie verwendest du es denn?
Arduino, ESP, Raspberry Pi,... ?

Im falle vom ESP (wie ich) und du alles schon geflasht hast, musst du 
mit einem Endgerät mit WLAN dich darauf verbinden und kannst die WLAN 
Daten und co anpassen...

Das schafst du schon. :)

An die Experten, was könnte das bedeuten (gestern stand missing, statt 
all):

das hier > 2 (0002) 3 (0003) 2 (0002) 3 (0030)  -> all
Payload 95 74 40 33 29 74 40 33 29 01 00 01 00 00 00 01 00 01 00 00 00 
00 00 00 00 00 95
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 
01 00 03 00 02 BA
Payload 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 9F
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
DC 00 09 BB 71 0E
das hier > 2 (0002) 3 (0003) 1 (0010) 3 (0030)  -> all
Payload 95 74 40 33 29 74 40 33 29 01 00 01 00 00 00 01 00 01 00 00 00 
00 00 00 00 00 95
Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 
01 00 03 00 02 BA
Payload 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 9F
Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 
DC 00 09 BB 71 0E

[David B. (mystisch)]

Habe ein ESP-8266, darauf läuft die Ahoy Version 0.4.0.
Noch kommt kein Bit vom Inverter ...
Das denke ich auch, dass ich es hinbekomme ;) werde

[Lukas P. (lumapu)]

Das sieht doch super aus, du bekommst Daten vom WR. Ich würde empfehlen, 
die ganz aktuelle Version 0.4.1 zu verwenden, die jetzt wie die Python 
Version die gesamte Payload sammelt + prüft und erst dann 
weiterverarbeitet.

[Daniel R. (daniel92)]

Hab mal was angehängt, könnte das eine heiße Spur sein?

Ich habe noch die 0.3.9, OTA Update wird wie gemacht?
Möchte keine EInstellung verlieren.^^

Hat sich erledigt, selbst gefunden. :P

[David B. (mystisch)]

Problem:
inverter type can't be detected!

In der Beschreibung ist angegeben, dass man den Inverter Typ angeben 
muss. Ist damit das Feld Name unter dem Adress gemeint?
dort hab ich MI-600 eingetragen, adresse startet mit 1041...

[Daniel R. (daniel92)]

So ich habe es nun auch geupdated auf 0.4.1. Danke :)

Man muss den Typ nicht mehr Eintragen.
@lumapu: Gebe dir hierfür recht, der 1500 hat nur zwei Spannungen und 4 
Ströme. - https://github.com/grindylow/ahoy/issues/38

Inverter #0 no Payload received!
Requesting Inverter SN xxxxxxxxxxx (ersetzt)
Transmit 27 | 15 74 40 33 29 78 56 34 12 80 0B 00 62 83 DE 4B 00 00 00 
05 00 00 00 00 A4 95 F8
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Error while retrieving data: Frame 1 missing: Request Retransmit
Transmit 11 | 15 74 40 33 29 78 56 34 12 81 B2
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Payload (62): 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 01 2C 00 01 00 03 00 02 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A
Balkonkraftwerk/ch1/U_DC: 0.200 V
Balkonkraftwerk/ch1/I_DC: 0.010 A
Balkonkraftwerk/ch2/U_DC: 0.200 V
Balkonkraftwerk/ch2/I_DC: 0.010 A
Balkonkraftwerk/ch3/U_DC: 30.000 V
Balkonkraftwerk/ch3/I_DC: 0.010 A
Balkonkraftwerk/ch3/P_DC: 0.200 W
Balkonkraftwerk/ch4/U_DC: 30.000 V
Balkonkraftwerk/ch4/I_DC: 0.030 A
Balkonkraftwerk/ch4/P_DC: 0.800 W
Balkonkraftwerk/ch4/YieldTota: 0.001 kWh
Balkonkraftwerk/ch0/Temp: 23.100 °
Balkonkraftwerk/ch0/YieldTota: 0.001 kWh
Transmit 27 | 15 74 40 33 29 78 56 34 12 80 0B 00 62 83 DE 50 00 00 00 
05 00 00 00 00 54 2B AD
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 
00 01 00 01 00 00 00 00 00 00 00 00 97
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 
00 00 00 00 01 2C 00 01 00 03 00 02 BA
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 
00 00 00 00 00 01 00 00 00 00 00 00 9F
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 
00 00 00 00 00 00 00 E7 00 0A 75 E0 69
Payload (62): 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 01 2C 00 01 00 03 00 02 00 08 00 00 00 00 00 00 00 01 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A
Balkonkraftwerk/ch1/U_DC: 0.200 V
Balkonkraftwerk/ch1/I_DC: 0.010 A
Balkonkraftwerk/ch2/U_DC: 0.200 V
Balkonkraftwerk/ch2/I_DC: 0.010 A
Balkonkraftwerk/ch3/U_DC: 30.000 V
Balkonkraftwerk/ch3/I_DC: 0.010 A
Balkonkraftwerk/ch3/P_DC: 0.200 W
Balkonkraftwerk/ch4/U_DC: 30.000 V
Balkonkraftwerk/ch4/I_DC: 0.030 A
Balkonkraftwerk/ch4/P_DC: 0.800 W
Balkonkraftwerk/ch4/YieldTota: 0.001 kWh
Balkonkraftwerk/ch0/Temp: 23.100 °
Balkonkraftwerk/ch0/YieldTota: 0.001 kWh

[Lukas P. (lumapu)]

David B. schrieb:
> Problem:
> inverter type can't be detected!

Sorry mein Fehler, ich werde das später noch fixen, habe wohl die Liste 
der Inverter zu schnell gelesen.
Passe doch bei dir temporär mal in hmSystem.h:40 die 0x11 auf 0x10 an.

[David B. (mystisch)]

Ok, das mit dem Fehler
inverter type can't be detected!

ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht.

ändere ich die S/N auf 1141..., ist der Fehler weg, aber Daten werden 
noch immer nicht empfangen.
@lumapu: Codestelle korrigiert, der error trace ist auch mit regulärer 
S/N weg. Aber der Inverter bleibt stumm.

[Lukas P. (lumapu)]

David B. schrieb:
> ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht.

Soweit ich weiß haben wir es noch nicht geschafft einen Inverter der 
MI-Serie auszulesen. Daher werden egal welche Veränderungen gemacht 
werden auch weiterhin keine Daten rauskommen.
Auf der 3ten Seite dieses Threads hat Ziyat T. (toe_c) schon einiges zu 
MI-1500 geschrieben:

Ziyat T. schrieb:
> Hallo
> Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?

[Daniel R. (daniel92)]

Ich habe schwierigkeite bei der App was zu finden, was für uns wichtig 
seien könnte.

Ich durchsuche quasi alles, was Interessant für uns seien könnte. Das 
näheste was ich gefunden habe ist im Anhang zu finden.

Zeile 5506, 6760

Kennt sich jemand noch mit dem ... aus? ^^
Mein wissen stößt langsam bei Java an meine grenzen.

[David B. (mystisch)]

Lukas P. schrieb:
> David B. schrieb:
>> ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht.
>
> Soweit ich weiß haben wir es noch nicht geschafft einen Inverter der
> MI-Serie auszulesen. Daher werden egal welche Veränderungen gemacht
> werden auch weiterhin keine Daten rauskommen.
> Auf der 3ten Seite dieses Threads hat Ziyat T. (toe_c) schon einiges zu
> MI-1500 geschrieben:
>
> Ziyat T. schrieb:
>> Hallo
>> Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?

achso, ja dann, das hab ich dann wohl überlesen.
Hier wäre dann noch einer im Besitz eines WR der MI Serie ;)

[Lukas P. (lumapu)]

Was haltet ihr davon wenn wir zur Dokumentation ähnlich wie Tasmota eine 
Github.io Seite einrichten. Das geht so wie es gelesen habe direkt im 
Repository zu aktivieren, wäre also eine Aufgabe für Martin G. 
(petersilie)

Hat jemand Erfahrungen mit Github-Actions? Habe mal kurz bei Tasmota 
gespickt und gesehen, dass hier platformio installiert wird und damit 
gebaut wird.

[Daniel R. (daniel92)]

Gute Idee, dann könnte man ein FAQ einrichten und und und...  =)

[isnoAhoy (Gast)]

> Ich habe Schwierigkeiten bei der App was zu finden, was für uns wichtig
> seien könnte.
> Ich durchsuche quasi alles, was Interessant für uns seien könnte. Das
> näheste was ich gefunden habe ist im Anhang zu finden.
> Zeile 5506, 6760

Ja das habe ich auch gesehen in Deinem DevConfigSMLPE.txt Anhang.

Ich fand die folgende MO (Message Objekte?) sehr interessant, da hat man 
alles nochmal in einer Zeile.
Die sind jeweils kurz vor den dazugehörigen Checksum Berechnungen mit 
`int hashcode` und den von Dir z.B. ab Zeile 5506 gefundenen und jeweils 
zugehörigen writeTo/getSerializedSize Methoden.
U.a. scheint es darin auch eine acPSf (?) und die invSwAddr zu geben.

Ob das Ganze aber für die Kommunikation mit der Hoymiles Cloud oder 
direkt mit der DTU gedacht ist kann ich nicht sagen.
Vielleicht können wir ja später mehr Sinn darin sehen, wenn wir noch ein 
paar Ergebnisse aus der DTU Pro Analyse haben ?

            PDbusConfigMO pDbusConfigMO = (PDbusConfigMO) obj;
            return (((((((((((((((((((((((((((((((((((((((((getSysType() == pDbusConfigMO.getSysType()) && getSysCfg() == pDbusConfigMO.getSysCfg()) && getDevNum() == pDbusConfigMO.getDevNum()) && getStrNum() == pDbusConfigMO.getStrNum()) && getReserve1() == pDbusConfigMO.getReserve1()) && getSmlpeAdVer() == pDbusConfigMO.getSmlpeAdVer()) && getCmdInterval() == pDbusConfigMO.getCmdInterval()) && getHbsInterval() == pDbusConfigMO.getHbsInterval()) && getTBd() == pDbusConfigMO.getTBd()) && getDataSampMode() == pDbusConfigMO.getDataSampMode()) && getPdbusComErrCnt() == pDbusConfigMO.getPdbusComErrCnt()) && getSmlpeComErrCnt() == pDbusConfigMO.getSmlpeComErrCnt()) && getDayModeCheckTm() == pDbusConfigMO.getDayModeCheckTm()) && getDayModeSmlpePercent() == pDbusConfigMO.getDayModeSmlpePercent()) && getReserve2() == pDbusConfigMO.getReserve2()) && getEnexSearchCnt() == pDbusConfigMO.getEnexSearchCnt()) && getEnSearchHbsCnt() == pDbusConfigMO.getEnSearchHbsCnt()) && getClearSearchDataCnt() == pDbusConfigMO.getClearSearchDataCnt()) && getSearchHostErrCnt() == pDbusConfigMO.getSearchHostErrCnt()) && getSearchSlaveCnt() == pDbusConfigMO.getSearchSlaveCnt()) && getSearchHostTout() == pDbusConfigMO.getSearchHostTout()) && getCompeteHostReceiptnone() == pDbusConfigMO.getCompeteHostReceiptnone()) && getSearchHost1ReciptnoneCnt() == pDbusConfigMO.getSearchHost1ReciptnoneCnt()) && getSearchHost2RecipterrCnt() == pDbusConfigMO.getSearchHost2RecipterrCnt()) && getRegMasterRssiTh() == pDbusConfigMO.getRegMasterRssiTh()) && getRegMasterReplyErrCnt() == pDbusConfigMO.getRegMasterReplyErrCnt()) && getSlaveRegMasterRssiTh() == pDbusConfigMO.getSlaveRegMasterRssiTh()) && getRegMasterCnt() == pDbusConfigMO.getRegMasterCnt()) && getCloseStrCnt() == pDbusConfigMO.getCloseStrCnt()) && getCancelMasterRegCnt() == pDbusConfigMO.getCancelMasterRegCnt()) && getTurnOnStrCnt() == pDbusConfigMO.getTurnOnStrCnt()) && getTurnOnStrHbsCnt() == pDbusConfigMO.getTurnOnStrHbsCnt()) && getSearchSlave1Reciptnone() == pDbusConfigMO.getSearchSlave1Reciptnone()) && getSearchSlave2SeciptsrrCnt() == pDbusConfigMO.getSearchSlave2SeciptsrrCnt()) && getRegSlaveCnt() == pDbusConfigMO.getRegSlaveCnt()) && getSeedNum() == pDbusConfigMO.getSeedNum()) && getReserve3() == pDbusConfigMO.getReserve3()) && getReserve4() == pDbusConfigMO.getReserve4()) && getReserve5() == pDbusConfigMO.getReserve5()) && getReserve6() == pDbusConfigMO.getReserve6()) && getReserve7() == pDbusConfigMO.getReserve7()) && getReserve8() == pDbusConfigMO.getReserve8();

            InvInfoAddrMO invInfoAddrMO = (InvInfoAddrMO) obj;
            return (((getEn() == invInfoAddrMO.getEn()) && getFc() == invInfoAddrMO.getFc()) && getStartAddr() == invInfoAddrMO.getStartAddr()) && getLength() == invInfoAddrMO.getLength();

            InvRealAddrMO invRealAddrMO = (InvRealAddrMO) obj;
            return (((getEn() == invRealAddrMO.getEn()) && getFc() == invRealAddrMO.getFc()) && getStartAddr() == invRealAddrMO.getStartAddr()) && getLength() == invRealAddrMO.getLength();

            PvStrAddrMO pvStrAddrMO = (PvStrAddrMO) obj;
            return (getVAddr() == pvStrAddrMO.getVAddr()) && getIAddr() == pvStrAddrMO.getIAddr();

            InvConfigMO invConfigMO = (InvConfigMO) obj;
            return ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((getInvVer() == invConfigMO.getInvVer()) && getDs().equals(invConfigMO.getDs())) && getModel().equals(invConfigMO.getModel())) && getFBoost() == invConfigMO.getFBoost()) && getFInv() == invConfigMO.getFInv()) && getMpptNum() == invConfigMO.getMpptNum()) && getStrNumMax() == invConfigMO.getStrNumMax()) && getPvSampCfg() == invConfigMO.getPvSampCfg()) && getAcMode() == invConfigMO.getAcMode()) && getEsReady() == invConfigMO.getEsReady()) && getLoadMonitorMode() == invConfigMO.getLoadMonitorMode()) && getComMode() == invConfigMO.getComMode()) && getEndian() == invConfigMO.getEndian()) && getInvInterval() == invConfigMO.getInvInterval()) && getStartDelay() == invConfigMO.getStartDelay()) && getRefreshDelayTm() == invConfigMO.getRefreshDelayTm()) && getInvDataSafetyMode() == invConfigMO.getInvDataSafetyMode()) && getComErrDelay() == invConfigMO.getComErrDelay()) && getNightModeDetectTm() == invConfigMO.getNightModeDetectTm()) && getDayModeCheckTm() == invConfigMO.getDayModeCheckTm()) && getBatteryEn() == invConfigMO.getBatteryEn()) && getLoadMonitorEn() == invConfigMO.getLoadMonitorEn()) && getLinkMode() == invConfigMO.getLinkMode()) && getInvSlaveAddr() == invConfigMO.getInvSlaveAddr()) && getInvIp().equals(invConfigMO.getInvIp())) && getInvPort() == invConfigMO.getInvPort()) && getInvBd() == invConfigMO.getInvBd()) && getInvParity() == invConfigMO.getInvParity()) && getInvStart() == invConfigMO.getInvStart()) && getInvStop() == invConfigMO.getInvStop()) && getInvInfoAddrList().equals(invConfigMO.getInvInfoAddrList())) && getInvRealAddrList().equals(invConfigMO.getInvRealAddrList())) && getAcPSf() == invConfigMO.getAcPSf()) && getAcEhSf() == invConfigMO.getAcEhSf()) && getLoadPSf() == invConfigMO.getLoadPSf()) && getGridPSf() == invConfigMO.getGridPSf()) && getLoadEhSf() == invConfigMO.getLoadEhSf()) && getBatSocSf() == invConfigMO.getBatSocSf()) && getBatPSf() == invConfigMO.getBatPSf()) && getPvStrVSf() == invConfigMO.getPvStrVSf()) && getPvStrISf() == invConfigMO.getPvStrISf()) && getPvStrPSf() == invConfigMO.getPvStrPSf()) && getPvStrEhSf() == invConfigMO.getPvStrEhSf()) && getAcPAddr() == invConfigMO.getAcPAddr()) && getAcPFc() == invConfigMO.getAcPFc()) && getAcPNum() == invConfigMO.getAcPNum()) && getAcEhAddr() == invConfigMO.getAcEhAddr()) && getAcEhFc() == invConfigMO.getAcEhFc()) && getAcEhNum() == invConfigMO.getAcEhNum()) && getLoadPAddr() == invConfigMO.getLoadPAddr()) && getLoadPFc() == invConfigMO.getLoadPFc()) && getLoadPNum() == invConfigMO.getLoadPNum()) && getLoadEhAddr() == invConfigMO.getLoadEhAddr()) && getLoadEhFc() == invConfigMO.getLoadEhFc()) && getLoadEhNum() == invConfigMO.getLoadEhNum()) && getPvPAddr() == invConfigMO.getPvPAddr()) && getPvPFc() == invConfigMO.getPvPFc()) && getPvPNum() == invConfigMO.getPvPNum()) && getGridPAddr() == invConfigMO.getGridPAddr()) && getGridPFc() == invConfigMO.getGridPFc()) && getGridPNum() == invConfigMO.getGridPNum()) && getBuyPAddr() == invConfigMO.getBuyPAddr()) && getBuyPFc() == invConfigMO.getBuyPFc()) && getBuyPNum() == invConfigMO.getBuyPNum()) && getSailPAddr() == invConfigMO.getSailPAddr()) && getSailPFc() == invConfigMO.getSailPFc()) && getSailPNum() == invConfigMO.getSailPNum()) && getBatSocAddr() == invConfigMO.getBatSocAddr()) && getBatSocFc() == invConfigMO.getBatSocFc()) && getBatSocNum() == invConfigMO.getBatSocNum()) && getBatPAddr() == invConfigMO.getBatPAddr()) && getBatPFc() == invConfigMO.getBatPFc()) && getBatPNum() == invConfigMO.getBatPNum()) && getPvStrTotalPAddr() == invConfigMO.getPvStrTotalPAddr()) && getPvStrTotalPFc() == invConfigMO.getPvStrTotalPFc()) && getPvStrTotalPNum() == invConfigMO.getPvStrTotalPNum()) && getPvStrTotalEhAddr() == invConfigMO.getPvStrTotalEhAddr()) && getPvStrTotalEhFc() == invConfigMO.getPvStrTotalEhFc()) && getPvStrTotalEhNum() == invConfigMO.getPvStrTotalEhNum()) && getPvStrRealAddrList().equals(invConfigMO.getPvStrRealAddrList())) && getInvSwAddr() == invConfigMO.getInvSwAddr()) && getInvSwFc() == invConfigMO.getInvSwFc()) && getInvSwNum() == invConfigMO.getInvSwNum()) && getPdSwAddr() == invConfigMO.getPdSwAddr()) && getPdSwFc() == invConfigMO.getPdSwFc()) && getPdSwNum() == invConfigMO.getPdSwNum()) && getOpenVal() == invConfigMO.getOpenVal()) && getCloseVal() == invConfigMO.getCloseVal()) && getPdValType() == invConfigMO.getPdValType()) && getPdValSf() == invConfigMO.getPdValSf()) && getReserve9() == invConfigMO.getReserve9()) && getReserve10() == invConfigMO.getReserve10()) && getReserve11() == invConfigMO.getReserve11()) && getReserve12() == invConfigMO.getReserve12()) && getReserve13() == invConfigMO.getReserve13()) && getReserve14() == invConfigMO.getReserve14()) && getSInterval() == invConfigMO.getSInterval()) && getReserve15() == invConfigMO.getReserve15()) && getDevMode() == invConfigMO.getDevMode()) && getDevAddr() == invConfigMO.getDevAddr()) && getBaudBd() == invConfigMO.getBaudBd()) && getParity() == invConfigMO.getParity()) && getStart() == invConfigMO.getStart()) && getStop() == invConfigMO.getStop()) && getReserve16() == invConfigMO.getReserve16();

            int acPSf = (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((hashCode * 37) + 33) * 53) + getAcPSf()) * 37) + 34) * 53) + getAcEhSf()) * 37) + 35) * 53) + getLoadPSf()) * 37) + 36) * 53) + getGridPSf()) * 37) + 37) * 53) + getLoadEhSf()) * 37) + 38) * 53) + getBatSocSf()) * 37) + 39) * 53) + getBatPSf()) * 37) + 40) * 53) + getPvStrVSf()) * 37) + 41) * 53) + getPvStrISf()) * 37) + 42) * 53) + getPvStrPSf()) * 37) + 43) * 53) + getPvStrEhSf()) * 37) + 44) * 53) + getAcPAddr()) * 37) + 45) * 53) + getAcPFc()) * 37) + 46) * 53) + getAcPNum()) * 37) + 47) * 53) + getAcEhAddr()) * 37) + 48) * 53) + getAcEhFc()) * 37) + 49) * 53) + getAcEhNum()) * 37) + 50) * 53) + getLoadPAddr()) * 37) + 51) * 53) + getLoadPFc()) * 37) + 52) * 53) + getLoadPNum()) * 37) + 53) * 53) + getLoadEhAddr()) * 37) + 54) * 53) + getLoadEhFc()) * 37) + 55) * 53) + getLoadEhNum()) * 37) + 56) * 53) + getPvPAddr()) * 37) + 57) * 53) + getPvPFc()) * 37) + 58) * 53) + getPvPNum()) * 37) + 59) * 53) + getGridPAddr()) * 37) + 60) * 53) + getGridPFc()) * 37) + 61) * 53) + getGridPNum()) * 37) + 62) * 53) + getBuyPAddr()) * 37) + 63) * 53) + getBuyPFc()) * 37) + 64) * 53) + getBuyPNum()) * 37) + 65) * 53) + getSailPAddr()) * 37) + 66) * 53) + getSailPFc()) * 37) + 67) * 53) + getSailPNum()) * 37) + 68) * 53) + getBatSocAddr()) * 37) + 69) * 53) + getBatSocFc()) * 37) + 70) * 53) + getBatSocNum()) * 37) + 71) * 53) + getBatPAddr()) * 37) + 72) * 53) + getBatPFc()) * 37) + 73) * 53) + getBatPNum()) * 37) + 74) * 53) + getPvStrTotalPAddr()) * 37) + 75) * 53) + getPvStrTotalPFc()) * 37) + 76) * 53) + getPvStrTotalPNum()) * 37) + 77) * 53) + getPvStrTotalEhAddr()) * 37) + 78) * 53) + getPvStrTotalEhFc()) * 37) + 79) * 53) + getPvStrTotalEhNum();

            int invSwAddr = (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((acPSf * 37) + 81) * 53) + getInvSwAddr()) * 37) + 82) * 53) + getInvSwFc()) * 37) + 83) * 53) + getInvSwNum()) * 37) + 84) * 53) + getPdSwAddr()) * 37) + 85) * 53) + getPdSwFc()) * 37) + 86) * 53) + getPdSwNum()) * 37) + 87) * 53) + getOpenVal()) * 37) + 88) * 53) + getCloseVal()) * 37) + 89) * 53) + getPdValType()) * 37) + 90) * 53) + getPdValSf()) * 37) + 91) * 53) + getReserve9()) * 37) + 92) * 53) + getReserve10()) * 37) + 93) * 53) + getReserve11()) * 37) + 94) * 53) + getReserve12()) * 37) + 95) * 53) + getReserve13()) * 37) + 96) * 53) + getReserve14()) * 37) + 97) * 53) + getSInterval()) * 37) + 98) * 53) + getReserve15()) * 37) + 99) * 53) + getDevMode()) * 37) + 100) * 53) + getDevAddr()) * 37) + 101) * 53) + getBaudBd()) * 37) + 102) * 53) + getParity()) * 37) + 103) * 53) + getStart()) * 37) + 104) * 53) + getStop()) * 37) + 105) * 53) + getReserve16()) * 29) + this.unknownFields.hashCode();

            LoggerConfigMO loggerConfigMO = (LoggerConfigMO) obj;
            return ((((((((((((((((getWorkMode() == loggerConfigMO.getWorkMode()) && getCommMode() == loggerConfigMO.getCommMode()) && getDhcpSw() == loggerConfigMO.getDhcpSw()) && getIp().equals(loggerConfigMO.getIp())) && getNetmask().equals(loggerConfigMO.getNetmask())) && getGw().equals(loggerConfigMO.getGw())) && getDns().equals(loggerConfigMO.getDns())) && getApSsid().equals(loggerConfigMO.getApSsid())) && getApPwd().equals(loggerConfigMO.getApPwd())) && getSpApn().equals(loggerConfigMO.getSpApn())) && getSpName().equals(loggerConfigMO.getSpName())) && getSpPwd().equals(loggerConfigMO.getSpPwd())) && getGprsNo().equals(loggerConfigMO.getGprsNo())) && getReserve19() == loggerConfigMO.getReserve19()) && getSvrPort() == loggerConfigMO.getSvrPort()) && getSvrHost().equals(loggerConfigMO.getSvrHost())) && getReserve20() == loggerConfigMO.getReserve20();

            ConfigParaMO configParaMO = (ConfigParaMO) obj;
            return ((getPdbusCfgList().equals(configParaMO.getPdbusCfgList())) && getInvCfgList().equals(configParaMO.getInvCfgList())) && getLogCfgList().equals(configParaMO.getLogCfgList());

            WriteHRegResDTO writeHRegResDTO = (WriteHRegResDTO) obj;
            return (((((((getOffset() == writeHRegResDTO.getOffset()) && getTime() == writeHRegResDTO.getTime()) && getAction() == writeHRegResDTO.getAction()) && (getGwSn() > writeHRegResDTO.getGwSn() ? 1 : (getGwSn() == writeHRegResDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > writeHRegResDTO.getLogSn() ? 1 : (getLogSn() == writeHRegResDTO.getLogSn() ? 0 : -1)) == 0) && getAp() == writeHRegResDTO.getAp()) && getCp() == writeHRegResDTO.getCp()) && getCfgParaList().equals(writeHRegResDTO.getCfgParaList());

            WriteHRegReqDTO writeHRegReqDTO = (WriteHRegReqDTO) obj;
            return ((((((getOffset() == writeHRegReqDTO.getOffset()) && getTime() == writeHRegReqDTO.getTime()) && getAction() == writeHRegReqDTO.getAction()) && (getGwSn() > writeHRegReqDTO.getGwSn() ? 1 : (getGwSn() == writeHRegReqDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > writeHRegReqDTO.getLogSn() ? 1 : (getLogSn() == writeHRegReqDTO.getLogSn() ? 0 : -1)) == 0) && getCp() == writeHRegReqDTO.getCp()) && getErrCode() == writeHRegReqDTO.getErrCode();

            ReadHRegReqDTO readHRegReqDTO = (ReadHRegReqDTO) obj;
            return (((((((getOffset() == readHRegReqDTO.getOffset()) && getTime() == readHRegReqDTO.getTime()) && getAction() == readHRegReqDTO.getAction()) && (getGwSn() > readHRegReqDTO.getGwSn() ? 1 : (getGwSn() == readHRegReqDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > readHRegReqDTO.getLogSn() ? 1 : (getLogSn() == readHRegReqDTO.getLogSn() ? 0 : -1)) == 0) && getAp() == readHRegReqDTO.getAp()) && getCp() == readHRegReqDTO.getCp()) && getCfgParaList().equals(readHRegReqDTO.getCfgParaList());

            ReadHRegResDTO readHRegResDTO = (ReadHRegResDTO) obj;
            return ((((getOffset() == readHRegResDTO.getOffset()) && getTime() == readHRegResDTO.getTime()) && getAction() == readHRegResDTO.getAction()) && (getGwSn() > readHRegResDTO.getGwSn() ? 1 : (getGwSn() == readHRegResDTO.getGwSn() ? 0 : -1)) == 0) && getLogSn() == readHRegResDTO.getLogSn();

[Olaf A. (Gast)]

Ich habe folgendes im Netz gefunden.

Bedienungsanleitung MI-1000/MI-1200/MI-1500
Version 2.0 (Juni 2020)

6. Fehlersuche
Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems 
Mitte 2020 aktualisiert.
Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" 
verwenden, so beziehen
Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den 
Mikrowechselrichter mit
Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen 
Sie sich bitte auf
Abschnitt 6.2 und Abschnitt 6.4.


*Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann 
nur mit dem neuen Gateway von
Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 
( Seriennummer: 10D2xxxxxxxx) und
DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren

[Olaf A. (Gast)]

Hier im Forum gibt es unter

nRF24L01+ und PA Kombi gibt kein Acknowledge

Hinweise zu Inkompatibilitäten zwischen Orginal-Chip's und Nachbauten.

Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"

[Daniel R. (daniel92)]

Hallo zusammen,

@isnoAhoy: das ist mir auch aufgefallen, jedoch war das ganze schon sehr 
lang. Das müsste man sich nochmal anschauen. In erster linie war mir 
wichtig etwas "pregnantes" zu finden. Was uns direkt weiterhelfen 
könnte.

@Olaf A: Danke für die Info, ich habe nämlich beim decompilen 
herausgefunden das es tatsächlich Geräte hinterlegt sind mit einer 
bestimmten Kennung.
Wobei ich diese eher als Test entnommen habe und nicht dachte das diese 
eventuell was für uns aussagt.

Siehe Zeile ab 38 im Anhang.

Gruß Daniel

Nachtrag: Ich meine diese Einträge sagen aus, wie die App mit der DTU zu 
arbeiten hat. Da jedes Produkt eine eigene Kennung besitzt und diese im 
ganzen System Automatisch hinterlegt wird.

Beispiel: Mikrowechselrichter mit Batterie und einem Energiemessgerät 
zusammen in einer App... und welcher DTU im System ist, handelt es sich 
um eine Pro oder um eine Lite Version.

Im Handbuch steht im Punkt 4.1 was Interessantes: 
https://www.hoymiles.com/wp-content/uploads/2021/05/BENUTZERHANDBUCH_HM-100012001500_Global_DE_V202203.pdf 
- Ich glaube man muss hier nur denn Wert definitiv irgendwie ändern. Das 
Suchen wir ja aktuell. Aber mehr steht dort auch nicht.

Kopfschmerzen habe ich beim Thema 0 Einspeisung, da hier der WR 
irgendwie mit einem Messgerät zusammen Kommunizieren muss. Damit der WR 
regeln kann.

Generell die Leistung vom WR auf einem festen Wert zu regeln, erlese ich 
aber dort leider nicht. :( Das wäre für uns ja fundamental, damit wir 
diese automatisiert regeln können.

[Mel Yoshi (Gast)]

Grüezi mitenand,

hier sind ein paar Videos und Bilder zum Hoymiles Wechselrichter 
(MI-1200 und HM-800):
 - zum Thema Nulleinspeisung:
   https://www.youtube.com/watch?v=BVWrG8nCMPQ

 - zum Innenleben des Wechselrichters:
   https://www.youtube.com/watch?v=Ho02aQxyX20
   https://www.youtube.com/watch?v=AtOjcIZpGKI
   https://www.youtube.com/watch?v=cgw11fTxhH8
   https://www.youtube.com/watch?v=Tu75J9IIhUg
   https://www.photovoltaikforum.com/thread/171257-hoymiles-hm800-leistungssteuerung-per-pwm/

[Daniel R. (daniel92)]

Sehr cool, vielen dank!
Dann kann man sich heute nach der Arbeit mal alles durch arbeiten und 
weiter schauen. :) Besten Dank Yoshi

[Jan-Jonas S. (janjonas_s)]

Hi,

das letzte Paket kann wohl nicht zum re-transmit angefragt werden. Wenn 
das fehlt ist wohl zwingend eine neue Transaktion nötig.

Lukas P. schrieb:
> Was haltet ihr davon wenn wir zur Dokumentation ähnlich wie Tasmota eine
> Github.io Seite einrichten. Das geht so wie es gelesen habe direkt im
> Repository zu aktivieren, wäre also eine Aufgabe für Martin G.
> (petersilie)
Wird spaßig, weil wir 2 Softwaren in dem repo haben. Ich glaube wir sind 
mit Markdown besser bedient.

> Hat jemand Erfahrungen mit Github-Actions? Habe mal kurz bei Tasmota
> gespickt und gesehen, dass hier platformio installiert wird und damit
> gebaut wird.

Pipelines. Spätestens da macht es dann Sinn das Projekt in die einzelnen 
Implementierungen zu splitten. Ich arbeite normal mit Drone oder Gitlab 
Runner. Sehr praktisch, aber Entwicklungsaufwand mal 2.

Daniel R. schrieb:
> Kopfschmerzen habe ich beim Thema 0 Einspeisung, da hier der WR
> irgendwie mit einem Messgerät zusammen Kommunizieren muss. Damit der WR
> regeln kann.

Eher wenig Kopfschmerzen. Aber da brauchen wir noch sehr viel 
Protokoll-Analyse. Ich meine damit, Tage an Rohdatenmittschnitten vom 
Original im Idealfall unter verschiedenen Betriebsbedingungen. Natürlich 
muss dem Wechselrichter irgendwo ein Bit gesetzt werden, dass die DTU 
die Leistungsvorgabe setzen muss (der WR damit ohne Kommunikation 
abschaltet) und dann muss die DTU die Leistungsanforderung eben 
regelmäßig in der WR schreiben. Die DTU fragt das dann wohl via Modbus 
vom Energiezähler ab und provisierniert mit dem Einspeisebudget alle 
paar Sekunden die Wechselrichter.

Ich denke dabei gerade daran das Einspeisebudget aus den 
Zählerinformationen via Mqtt zu lesen bzw. die nötigen Payloads via HASS 
generieren zu lassen und dann via Command-Topic an den WR zu relayen.

Gruß,
Jan

[Daniel R. (daniel92)]

Moin Jan,

zu deiner letzten Passage, da gebe ich dir recht. Habe mir im Nachhinein 
die YT-Videos die Yoshi hinterlegt hat angeschaut und wird sehr sauber 
beschrieben:

- zum Thema Nulleinspeisung: https://www.youtube.com/watch?v=BVWrG8nCMPQ

Das ist genau so wie du beschrieben hast, nur das hier zwischen DTU und 
Messzähler eine RS485 zum Einsatz kommt (3:35min). - Whatever, es geht 
aufjedenfall weiter. =)

[Jan-Jonas S. (janjonas_s)]

Daniel R. schrieb:
> nur das hier zwischen DTU und Messzähler eine RS485 zum Einsatz kommt

Jan-Jonas S. schrieb:
> Die DTU fragt das dann wohl via Modbus vom Energiezähler ab

[Tobi D. (tobidd)]

Ich nutze einen shelly3em zur aktuellen energiemessung meines 
Haushaltes. Wäre prima wenn die Nulleinspeisung auf zb Werte die per 
Mqtt kommen weiterverarbeitet werden, so ist es für viele Systeme offen 
und nicht auf den energiemesser den hoymiles vorgibt beschränkt.

[Marcel A. (a-marcel)]

Das wäre doch alles viel zu langsam, wenn die DTU jetzt was von einem 
Messgerät ließt und das dann dem Wechselrichter zukommen lässt und das 
auch noch over the air. Da wird ja man ja an Strahlung gegrillt ;). In 
der Preisklasse der Wechselrichter gehe ich davon aus, das man a) einen 
festen Leistungswert oder b) einen prozentualen leistungswert an den 
Wechselrichter übermittelt.

Alles andere sehe ich nicht in diesem Preisbereich und muss selber 
gebaut werden. Deswegen wäre es eben cool wenn wir mal Mitschnitte haben 
wo die DTU mit dem WR kommuniziert und man mehrfach die Leistungswerte 
ändert.

Marcel

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Ich habe eine DTU-Pro

Hallo Ziyat, bist du hier noch aktiv?
Wäre es möglich uns hierbei einige Infos über das teil zukommen zu 
lassen?

Oder wäre es möglich es auszuleihen um weitere Recherchen daran zu 
betreiben?

Wer hat noch so ein DTU-Pro?

@Jan: Sorry ^^

Gruß Daniel

Edit: Ich bin nun aktiv dabei weiter die Logs mal auszuwerten.
Nur das ich auf dem richtigen weg bin, habe ich dazu eine Frage:

Ich vergleiche aktuell die Logs untereinander und versuche durch die 
Logs eine Symmetrie zu finden. Dazu habe ich auch Logs mir erstellt, wo 
ich versuche die Werte manuell zu ändern. Zb: "kein PV Spannung", PV 
Spannung, kein AC Spannung und wieder AC Spannung habe, um zum Beispiel 
eine Inkrimierte Variabel zu finden. Oder den aktuellen Status des WR zu 
erlesen ist.  - Was haltet ihr von der vorgehensweiße?

[Daniel R. (daniel92)]

Moin zusammen,

könnte man in der Log das ganze bisschen ausbauen?

Aktuell muss ich mühsehlig alles ausseinander ziehen und schauen welches 
Bit noch undefiniert ist. Oder hat jemand eine Excel geschrieben, wo ich 
das reinhauen kann um zu sehen was übrig bleibt?

Danke

[Lukas P. (lumapu)]

Daniel R. schrieb:
> könnte man in der Log das ganze bisschen ausbauen?

Baue dir am besten eine Firmware oder noch besser verwende Jan's Python 
Code als  Basis und lass dir die Roh-Daten ausgeben. Ich denke in Python 
geht das fixer, Code umbauen und sofort testen, nicht erst kompilieren 
und updaten. Nach und nach kannst du dann einen Parser für die Daten 
entwickeln.
Die entgültige Erkenntnis kannst du dann wieder in den ESP portieren 
sofern er dir dann noch zusagt ;-)

[Daniel R. (daniel92)]

Hi Lukas,

danke, ja aktuell mach ich das über ESP. Muss das echt mal auf den 
Raspberry portieren...

hmm alles klar, so kann man das auch machen. Danke. :)

[Daniel R. (daniel92)]

Morgen,

hab was neues entdeckt in einer Anleitung.
Auf dieser Seite https://www.shinetech-power.de/en/inverter/hoymiles/ 
werden Produkte anscheinend verkauft. Unter dem Punkt "Hoymiles DTU-Pro" 
sind auch Anleitung in PDF hinterlegt.

Darunter auch Modbus Protokoll mit einer riesen Tabelle.
Ich bin heute nach der Arbeit beim Grillfest, vielleicht kann es sich 
jemand von euch mal anschauen?

https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

Gruß Daniel

[Lukas P. (lumapu)]

ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze) 
behoben

[Markus (Gast)]

Hi tbnobody,
wäre es möglich, dass du hier einen Export(json) deines Grafana Boards 
zur Verfügung stellst?

Danke dir.

Viele Grüße

[isnoAhoy (Gast)]

Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c):

Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und 
speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz 
vollständige Liste der DTUs im Besitz von Foren Teilnehmern. Auch ein 
Salea Logic Analyzer habe ich mal ausprobiert und anhand den von martin 
(Gast) in seiner DTU-Lite aufgenommenen Daten (RX/TX) Testpunkt 
dokumentiert, wie man dabei zu den entsprechenden Logfiles kommt. Es 
gibt da sog. Analyzer (speziell Async Serial funktioniert) und dann kann 
man einen Export ins CSV Format machen.

Jetzt bräuchten wir nur noch einen Freiwilligen DTU-Pro Besitzer, der 
das große Kästchen mal aufschraubt und an den RX/TX Punkten mißt was 
passiert, wenn man per ModBus ein paar Kommandos gibt. Wenn die DTU 
Besitzer ihre Geräte nicht aufschrauben wollen gäbe es immer noch andere 
Methoden (NRF24_Sniffer, Ahoy zum Sniffen anpassen) die eventuell etwas 
minimal-invasiver sind, jedoch wäre das vermutlich mit mehr Aufwand und 
weniger Erkenntnisgewinn verknüpft, da die Pakete nicht so sicher 
belauscht werden können wie am RX/TX Testpunkt auf der Platine.

Die Salea Logic Analyzer bzw. Clones gibt es übrigens für ca. 13,- Euro 
aus der Bucht:

      https://www.ebay.de/itm/255283244102

* Trace / Sniffer Software:

  - Salea Logic / Clone

    + Sigrok Software (Pulseviwew)

      https://sigrok.org/
      https://sigrok.org/wiki/Downloads
      http://marcusjenkins.com/saleae-logic-analyser-clone-with-ubuntu/

    + Salea Logic

      https://www.saleae.com/downloads/
      chmod +x Logic-2.3.53-master.AppImage
      ./Logic-2.3.53-master.AppImage

        <1F> Analyzer (right side toolbar)
        Analyzers (+)
          Async Serial
            Input Channel: 00. Channel 0
            Bit Rate (Bits/s): 125000
            Bits per Frame: 8 Bits per Transfer (Standard)
            Stop Bits: 1 Stop Bit (Standard)
            Parity Bit: No Parity Bit (Standard)
            Significant Bit: Least Significant Bit Sent First (Standard)
            Signal Inversion: Non Inverted (Standard)
            Mode: Normal
            [x] Show in Protocol Results Table
            [x] Stream to terminal
          Save
        Analyzers (+)
          Async Serial
            Input Channel: 01. Channel 1
            Bit Rate (Bits/s): 125000
            Bits per Frame: 8 Bits per Transfer (Standard)
            Stop Bits: 1 Stop Bit (Standard)
            Parity Bit: No Parity Bit (Standard)
            Significant Bit: Least Significant Bit Sent First (Standard)
            Signal Inversion: Non Inverted (Standard)
            Mode: Normal
            [x] Show in Protocol Results Table
            [x] Stream to terminal
          Save
          Rename the two Async Serial Analyzers to RX / TX
          Data ... Export Table
            Export Table Data
              Columns: (*) All
              Data: (*) All
              Export Format: (*) CSV
              [x] Use ISO8601 Timestamps
            Export

  - NRF24_Sniffer

      git clone https://github.com/Yveaux/NRF24_Sniffer
      ./nrf24-sniffer.py -a 90:65:23:74:01

  - Wireshark

* Python  ESP Variante zum Mitschneiden anpassen  konfigurieren
* Pakete einer DTU und eines Wechselrichters (hier MI-1500) mit der 
ESP/Raspberry Pi Variante mitschneiden.
* Kommandos per Modbus an die DTU-Pro senden und diese mit einem 
LogicAnalyzer an den RX/TX Testpunkten in der DTU mitschneiden
* Payload und Kommandos aus den Datenpaketen extrahieren und analysieren



DTU Besitzer / Nutzer
---------------------

DTU-Pro: Sascha D. (bandit7311), Ziyat T. (toe_c)
DTU-Lite: martin (Gast), Oliver F. (of22), Martin G. (petersilie)
DTU-W100: Arnaldo G. (arnaldo_g), Sergey S. (sergey_s632), Mike (Gast)
DTU ?: Daniel M. (daniel_m821), Martin P. (mpolak77)

DTU-Pro    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
Sascha D. (bandit7311)
DTU-Pro    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Ziyat 
T. (toe_c)

DTU-Lite  xxxx72818832 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  martin 
(Gast)
DTU-Lite  xxxx72819005 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Oliver F. 
(of22)
DTU-Lite    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
Martin G. (petersilie)
DTU-Lite  10D972xxxxxx 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  10D9  martin 
(Gast)

DTU-W100  10D373114359 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  10D3  Sergey S. 
(sergey_s632)
DTU-W100  xxxx70535453 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Arnaldo G. 
(arnaldo_g)
DTU-W100  10D373114359 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  10D3  Sergey S. 
(sergey_s632)
DTU-W100    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Mike 
(Gast)

DTU    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Daniel M. 
(daniel_m821)
DTU basic ?    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
Martin P. (mpolak77)


Exoten MI & TSUN Wechselrichter:

MI-1500  xxxxxxx14456 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Arnaldo G. 
(arnaldo_g)
MI-1500  xxxxxxx36590 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  xxxx  Arnaldo G. 
(arnaldo_g)
MI-1500    Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"    Ziyat 
T. (toe_c)

MI-600  1041xxxxxxxx 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  1041  David B. 
(mystisch)
TSUN TSOL-M800  104163500316 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"  1041  Daniel M. 
(Gast)


---

Diskussionsausschnitte zum Thema DTU-Pro und Modbus Ansteuerung
---------------------------------------------------------------

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

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.

Den LA gibts natürlich auch bei anderen Anbietern.

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.

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

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.

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.

Nach Inbetriebnahme kann ich 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".

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.

[Jan-Jonas S. (janjonas_s)]

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

Good point. Das ist mir auch schon aufgefallen, dass die HM's bei der 
serial von der DTU recht picky sind. Die 10F... aus dem Excel sheet 
gehen z.B. garnicht.

[Daniel R. (daniel92)]

Hallo isnoAhoy ,

vielen Dank für die tolle zusammenfassung.
Ich habe gestern Abend einige Lieferanten angeschrieben bezügl. DTU-Pro, 
um sein Teil zu erhalten. Bis jetzt noch keine Antwort erhalten.

Wenn ich eins habe, könnte ich es ohne Probleme ausseinander nehmen.
Zum Analysieren habe ich ein "Salea Logic 16 clone", der wunderbar mit 
der Software von Salea funktioniert.

Der einzige Punkt wo ich stutzig bin: Denn WR ausseinander zu nehmen, 
würde ich ungern tun (zwecks Dichtung und co.). Wieso sollte es hier 
nicht ausreichen, direkt am DTU (hinter dem NRF) TX & RX zu belauschen? 
Da sollten ja keine Packete vom NRF modifiziert sein?

Wäre nicht auch die SPI NRF <-> MCU Übertragung mitzusniffen sinnvoll?

Gruß

[Herbert K. (avr-herbi)]

Daniel R. schrieb:

Hallo Daniel,

ich schätze Deine Mitarbeit sehr.
ABER
Du hast Dich irgendwann hier eingeklingt, ohne alle Beiträge zu lesen.
Das Du sie nicht gelesen hast - oder vergessen hast - oder wie auch 
immer ist eindeutig an Deinen Äußerungen zu sehen.

Nach dem nRF24L01+ brauchst zu Equipment für 2,4 GHz ! Das ist HF ! Da 
nutzt Dir der SALEA LA. gar nix.

In den DTU´s sitzt nach unseren bisherigen Erkenntnissen ein 
Kombi-Baustein nämlich ein nRF24 inkl. 80x51 CPU = NRF24LE1E. LE1E ist 
was anderes als LE1+ ! Dazwischen wirst Du kaum Sniffen können.
Alles kalter Kaffee wenn Du alles gelesen hättest.

ModBus sniffen nutzt auch niemand was.

Einzig ein oder mehrere nRF24L01+ die auf allen Kanälen mithören und in 
zeitlich korrekter Reihenfolge Telegramme mithören nutzen etwas.
Ausgelöste Aktionen über ein DTU-Pro oder/und die Cloud, die wir ja 
umgehen wollen.

Es wäre sehr schön, wenn Du uns mit Deiner Erfahrung in dieser Richtung 
weiter unterstützen würdest. Danke schon mal.

Viele Grüße Herbert

[Daniel R. (daniel92)]

Hallo Herbert,

ich verstehe dich sehr gut. Ich gebe dir auch recht das ich mich hier 
relativ spät eingeklingt habe. Dennoch bin ich nicht auf die Nase 
gefallen. - Vorschlag: Alle Fortschritte und Todos in Github zu 
hinterlegen (Wiki)?

Ich habe weder ein Spectrum Analyzer, noch ein Oszi um HF messen zu 
können. Das habe ich alles auf der Arbeit, kann es aber dort schlecht 
privat nutzen. ;) - Via DVB-T und einem SDR, das ist bei mir aber 
aktuell irgendwie nicht möglich (Treiber problem? -> zuletzt vor über 1 
Jahr benutzt).

Um kurz mein Gedanke nochmal neu zu Formulieren, damit ihr wisst wie ich 
gerne euch Unterstützen kann und möchte:

Ich habe Zuhause aktuell ein HM-1500 und einen "NRF24L01+" der an einem 
ESP32 angebunden ist. Wenn ich später einen DTU-Pro haben sollte, wird 
sich auch später zeigen was im inneren steckt.

Aufjedenfall meine ich mit dem oberen Post, das man auf dem PCB (wird ja 
nach der Antenne, mit Filter, etc... auch irgendwo ein IC sein der die 
Signale in Pakete umwandelt) mitlauschen kann. Sei es Seriel oder 
anderweitig.
Da ich den WR ungern ausseinander nehmen möchte und auch nicht so auf 
die schnelle die fliegende Pakete in der Luft aufnehmen kann (ohne 
Equipment nicht möglich, höhö), bleibt mir aktuell nur die Möglichkeit 
hinter dem NFR-IC am DTU mit zu lauschen.

Ich weis, am besten were Zeitgleiche protokolierung auf beiden Seiten WR 
+ DTU um beide Pakete vergleichen zu können, um die genaue reihenfolge 
zu erkennen und und und...

Aber danke Herbert.

PS: Die Funktion "Bearbeiten" nutze ich um nicht Unnötig denn Thread zu 
spamen. Wenn ich Neuinformation habe die für jemand Hilfreich seien 
können, schreibe ich es eben nachträglich rein. =)

[Ralf B. (ralf_b210)]

Lukas P. schrieb:
> ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze)
> behoben

Moin,
hm...
funtzt bei mir leider nicht.
Hatte vorher die 0.3.6 am laufen.

[Lukas P. (lumapu)]

Ralf B. schrieb:
> funtzt bei mir leider nicht.

Schöne Fehlerbeschreibung =) bitte auf Github und mit mehr Details:
- Serielle Konsole, kommt was?
- Visualisierung von ESP, ist alles Null?
- Wechselrichter 1,2 oder 4 Kanäle?
- Pinout in der Setup nochmal gegengecheckt?
- woran machst du fest, dass es nicht geht?

[Ziyat T. (toe_c)]

isnoAhoy schrieb:
> Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c):
>
> Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und
> speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz
> vollständige Liste der DTUs im Besitz von Foren Teilnehmern.

Hallo isnoAhoy
Da ich der einzige mit einem MI1500 bin, und hier alles um den HM dreht, 
hab mal "aufgehört" weiter zu bohren, aber ich werde bald einen HM1500 
bekommen..
Ich habe mit der NRF24_Sniff/wireshark von Ivo Pullens gespielt, kam 
aber  nicht weiter. Das Protokoll für MI ist chaotisch;-)


> 0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über
> ein Relais lösen könnte).

Was ich bisher über Modbus gefunden habe, für MI series:
- 0xC000 on/off geht bei MI nicht
- 0xC001 nur bis 10% der angeschlossene PV-Nennleistung limitierbar, 
darum zero export (ich meine eine NULL) mit dem MI nicht machbar
- 0xC006x/0xC007x Steuerungen der Ports gehen nicht

Grüsse, Ziyat

[isnoAhoy (Gast)]

Hallo Ziyat T. und Daniel R.,

die Aufnahmen mit dem Salea Logic Analyzer sind auf der Platine der DTU 
/ DTU-Pro an den RX/TX Testpunkten. Hier nochmal das Bild von martin 
(Gast) der das bei seiner DTU-Lite sehr schön dokumentiert hat.
Die Aufnahme ist bei 115200 Baud mit dem Salea sehr gut möglich und hat 
sowohl senden als auch empfangen, inklusive evtl. vorhandener Retransmit 
Requests.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ziyat T. schrieb:
>> Ich habe eine DTU-Pro
>
> Hallo Ziyat, bist du hier noch aktiv?

Hallo Daniel
Ich pausiere mal, da ich einen MI1500 habe und nicht weiter gekommen 
bin, bald bekomme ich einen HM1500, hoffe ich mal, dann gehts weiter.

Ich konnte den MI nicht ansprechen, aber wenn die DTU eingeschaltet ist 
konnte ich mithören und aufschlüsseln, siehe Anhang. Die Werte stimmen 
exact.

Meine DTU-Pro kann ich nicht ausleihen, da sie im Betrieb ist und ich 
bin ca. 2000km weit weg..
Grüsse

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:

> @Ziyat willst Du,,,,,,,, uns Bilder schicken ?

Guck mal

[Robert Bleumer (Gast)]

Hatte das gleiche Problem, dann erstmal alle libraries geupdated.

Nochmals kompiliert und upload. Danach funktioniert es wieder 
problemlos.

[Hans W. (hans_w801)]

Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die 
Möglichkeit, die Daten per JSON String zu übermitteln ?

[Lukas P. (lumapu)]

Robert Bleumer schrieb:
> Hatte das gleiche Problem, dann erstmal alle libraries geupdated.
>
> Nochmals kompiliert und upload. Danach funktioniert es wieder
> problemlos.

Das wusste ich nicht, habe eigentlich nichts verändert was neue 
Versionen braucht -zumal ich die genauen Abhängigkeiten gar nicht kenne.

[Lukas P. (lumapu)]

Hans W. schrieb:
> Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die
> Möglichkeit, die Daten per JSON String zu übermitteln ?

Auch bei JSON String würden wir auf eine externe Library setzen. Was 
haben wir dann gewonnen? Wer sagt und das es stabiler ist? Wir können es 
als Option vorsehen, genauso wie MQTT auch eine Option und kein Muss 
ist.
Wenn du sowas implementierst kannst du es gerne per Pull Request 
beitragen.

Schau mal auf GitHub, da hat @isnoAhoy aka stefan123t unter issue #24 
einiges zu abstürzen geschrieben.
Ich bin der Meinung, das sehr viel auch von der Powerversorgung abhängt. 
Evtl. sollen wir alle den Code um den MQTT Bereich nochmal genau 
reviewen.

[Hans W. (hans_w801)]

Lukas P. schrieb:
> Wenn du sowas implementierst kannst du es gerne per Pull Request
> beitragen.

Ich bin leider kein Coder, sondern eher Copy & Paste'er...

[Martin G. (petersilie)]

Komme gerade echt mit dem Hoymiles nicht hinterher. Habe das Projekt 
aber nicht vergessen. Meine DTU liegt noch unbenutzt im Schrank. Toll, 
was wir schon alles rausgefunden haben. Sobald ich ein bisschen mehr 
Zeit habe, mache ich nochmal einen Anlauf. Liebe Grüße - Martin 
(petersilie)

[Andi (Gast)]

@ Ziyat T. (toe_c)
Danke für die Bilder, ich habe mir die mal auf die schnelle angeschaut 
und dabei ist mir aufgefallen, dass in der DTU-Pro das gleiche NRF Modul 
aufgelötet wurde wie in den HM Wechselrichtern selbst verbaut ist(siehe 
HM800 Zerlegtbilder). Ich konnte allerdings auch nach einer halben 
Stunde im Netz suchen dieses Modul nicht finden, da das Pinout natürlich 
interessant wäre. Auf dem Abschirmdeckel scheint leider auch kein Typ 
aufgedruckt zu sein (die HM800 Bilder waren dafür eh zu unscharf).
Da das Modul aber anscheinend HMRF-SMD-V1.1.0 heißt, gehe ich mal stark 
davon aus, dass Hoymiles die Module für sich selbst fertigen lässt(darum 
HMRF) und es keine vergleichbaren NRF Module auf dem freien Markt gibt.

Die Rückseite der Platine(vorallem zwischen STM und NRF Modul) wäre 
sicherlich auch interessant ;-)

Jetzt kommen die Vermutungen von mir (bin kein Platinenexperte, werden 
andere hier sicher noch besser herausfinden, aber um einen Anfang zu 
haben):

erstmal das wohl wichtigste: auf dem NRF Modul sind zum Glück 3 Pins 
beschriftet, diese scheinen für mich recht eindeutig zu sein:
G - Ground
R - Rx
T - Tx
ob die direkt zum NRF Sender gehen ist derzeit noch unbekannt, auch ob 
sich auf der Rückseite Lötpads dazu befinden oder vielleicht mit dem 
nachfolgenden Connector(gegenüber) verbunden sind

P201_NC geht ja offensichtlich zu einer kompletten Seite des NRF Moduls, 
eventuell steckt da mehr darunter, als nur ein NRF-Chip, da so viele 
Pins entweder auf Debug oder programmierbar hindeuten. Wenn wir Pech 
haben ist da noch ein extra Mikrokontroller auf der Platine und die 
Kommunikation zum STM findet über ein eigenes Protokoll statt, nicht 
direkt die NRF Datenkommunikation.

CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn 
unteranderem zu Programmieren oder Debuggen.

Wer es sich zutraut und überhaupt machen möchte/kann, von den DTU-Pro 
Besitzern, kann gern die Abschirmhaube ablöten, dann wäre ein Geheimnis 
mehr gelüftet, muss aber nicht unbedingt sein, da wir auch andere Wege 
haben an die Daten zu kommen.

[Herbert K. (avr-herbi)]

vielleicht so ähnlich  :-)

[Daniel R. (daniel92)]

Guten Abend zusammen,

ich melde mich erst jetzt. Huii die Bilder sind Interessant, aber 
nochmal von Anfang an.

@ Ziyat T.: Alles klar, ist doch kein Problem. Wenn wir es geschaft 
haben, könne wir bestimmt an diesem 2000km weiten Ort Urlaub machen? :P 
- Spaß hehe

Die Bilder sind schonmal sehr gut, könntest du in Zukunft eine komplette 
Aufnahme vom Board (Vorder und Rückseite) machen? Dann kann man sich 
auch besser vorstellen wo was ist. Muss aber nicht sein, die Bilder 
sollten auch so schon reichen. :)

@Martin G(petersilie): Kein Ding, ich bin dabei alles auch aufzuholen 
und das ist wahnsinnig was hier schon geleistet wurde.

@ Andi: Da gebe ich dir recht, die Schnittstelle P201_NC könnte uns 
vielleicht helfen... wer weiß vielleicht auch ein Terminal zum lesen und 
schreiben? Anyway, die PINS auf dem Modul mit  G R T sind Goldwert (wenn 
es nicht intern deaktiviert wurde).

Ich gehe mal davon aus das sie auch nicht rausgeführt wurde.
Oder es geht unter dem Modul weiter.

Hätte ich eine DTU-Pro würde ich das machen, hab alles hier bei mir zum 
Ablöten. ^^

Edit: Gerade was geschrieben, schon eine neue Nachricht.
@ Herbert K: Super! Es geht weiter, sieht sehr ähnlich aus.
Laut Tabelle ist CN201_NC eine SPI Schnittstelle.

[Herbert K. (avr-herbi)]

und noch eines aus dem MI-1200

[Ziyat T. (toe_c)]

Herbert K. schrieb:
> vielleicht so ähnlich  :-)

Genau A6! Super :-)

[martin (Gast)]

Andi schrieb:
> und dabei ist mir aufgefallen, dass in der DTU-Pro das gleiche NRF Modul
> aufgelötet wurde wie in den HM Wechselrichtern selbst verbaut ist

Das ist ein von Hoymiles entwickeltes und FCC freigegebenes Modul, wie 
auf Seite 1 des Threads schon verlinkt wurde:
https://fcc.report/FCC-ID/2ARNB-HM2401/
Macht es sicher einfacher mit der Zulassung, das als Modul auszulagern, 
sonst müssten sie vermutlich jeden Inverter einzeln zertifizieren 
lassen...

Im Endeffekt ist es aber immer die gleiche Funkschnittstelle. Die DTU 
(Lite) hat es nicht als Modul sondern direkt onboard.
Bei der DTU Lite kommt über SPI vom NRF24LE1E keine Kommunikation - ich 
gehe davon aus, dass es bei den Modulen nicht anders ist. Jemand hatte 
mal vorgeschlagen, den NRF24LE1E Flash auszulesen und den Code zu 
reassemblieren, um so evtl. einen Hinweis auf die darin laufende 
Software und das Channel-Hopping zu bekommen. Was bräuchte ich denn 
dazu?

[Ziyat T. (toe_c)]

Herbert K. schrieb:
> und noch eines aus dem MI-1200

Hallo Herbert, konntest du den MI1200 schon ansprechen?

[Herbert K. (avr-herbi)]

Ziyat T. schrieb:
> Hallo Herbert, konntest du den MI1200 schon ansprechen?
Hallo Ziyat, ich habe selbst den MI1200 nicht. Ich habe HM350/400.

[isnoAhoy (Gast)]

Hallo martin (Gast),

das mit dem einen Standard nRF24 Modul von Hoymiles HM2401 klingt 
logisch. Da spart man sich sicher einen Haufen Papierkram auf diese Art 
und Weise. Deswegen ist das Modul wahrscheinlich auch mit einer Platte 
abgeschirmt, damit es eben ein Standardtestobjekt für die EMV Messungen 
ist.
Hier die anderen FCC Reports von Hoymiles:
https://fcc.report/company/Hoymiles-Converter-Technology-Co-L-T-D

Der Microprozessor auf der Platine ist ein STM32F402/STM32F407 und ich 
nehme auch an der Port CN201_NC ist ein SWD / JTAG Port.

@Ziyat T., ich konnte die letzte Ziffer der MCU auf der DTU-Pro nicht 
lesen, kannst Du diese bitte nochmal mit Adleraugen erspähen und ggf. 
bestätigen ? Auch eine FCC-ID der DTU-Pro wäre hilfreich um diese ggf. 
in den einschlägigen Datenbanke zu finden. Danke!


Auf der Suche nach der FCC ID der DTU-Pro habe ich auch noch ein Projekt 
von Arek Kubaki gefunden mit dem man die DTU-Pro per Modbus steuert:
https://github.com/ArekKubacki/Hoymiles-Plant-DTU-Pro


Für das Auslesen des Flash Speichers brauchst Du im Prinzip OpenOCD und 
einen Debugger, z.B. ein bluepill STM32 oder eines der üblichen 
USB-Dongles STLinkV2 / JLink ab 6 Euro oder direkt mit dem Raspberry Pi 
als Interface.

Dann bringt man den nRF24 oder auch den STM32F4x in den JTAG / SWD Modus 
und kann ihn dann anhalten bzw. den Flash langsam auslesen.

OpenOCD startet man mit mehreren Config Files, hier eines für das 
Interface, mein STLinkV2 USB Dongle und als zweites die Zielarchitektur 
/ CPU, die man steuern / debuggen möchte:

openocd -f interface/stlink.cfg -f target/stm32f4x_stlink.cfg

https://www.openocd.org/doc/html/Flash-Commands.html

Den Flash Speicher selbst kann man dann mit Ghidra (OpenSource aus dem 
Sonder-Programm der CIA) zurück zu C dekompilieren, wenn man kein IDA 
Pro sein Eigen nennt.

CAVE CANEM: Zu beachten ist dass evtl. auch die Read Out Protection 
aktiviert sein kann. I.d.R. machen das die Produzenten aber m.W. aus den 
selben Gründen nicht wie wir, es ist einfacher den Code überzubügeln 
ohne die ganze Security =^/

https://stackoverflow.com/questions/32509747/stm32-read-out-protection-via-openocd

[isnoAhoy (Gast)]

Prima, hier (https://fccid.io/2ARNB) gibt es neben den bekannten drei 
Prüfberichten auch noch das Sub-1G Modul HMS10.

* 2ARNB-HMS10 Sub-1G Module
* 2ARNB-HM2401 2.4G RF Module
* 2ARNB-MI1200 Microinverter
* 2ARNB-DTUW100 Data Logger

Mit einem kompletten UserGuide und den Pin Belegungen:
https://fccid.io/2ARNB-HMS10/User-Manual/User-manual-5204741

2.2   Pin Definition
This Table 1 describes the interface pins.

Table 1 HM2401 interface pins

NO.   Symbol   I/O Type   Function
1     Gnd      P          Power supply reference ground pin
2     NC       I          Null pin, no internal connection
3     P1.5     I/O        RESERVED, P1.5, which is connected to P1.5 on 
the IC
4     P1.6     I/O        RESERVED, P1.6, which is connected to P1.6 on 
the IC
5     P0.1     I/O        RESERVED, P0.1, which is connected to P0.1 on 
the IC
6     P0.6     I/O        RESERVED, P0.6, which is connected to P0.6 on 
the IC
7     NC       I/O        Serial peripheral interface clock pin
8     GND      P          Power supply reference ground pin
9     RXD      I/O        UART_RX, which is connected to P0.4 on the IC
10    TXD      Output     UART_TX, which is connected to P0.3 on the IC
11    GND      P          Power supply reference ground pin
12    VCC      P          Power supply pin
13    PRG      I/O        Set high to enter flash programming mode
14    SCK      I/O        Serial peripheral interface clock pin
15    RST      I/O        Hardware reset pin (active at a low level)
16    GPIO     I/O        Reserved
17    MI       I/O        Reserved
18    SCN      I/O        Reserved
19    GND      P          Power supply reference ground pin
20    GND      P          Power supply reference ground pin

4.1 NRF Channel List
Depending on the program, the module can work on 915MHz for North 
America and 868MHz for Europe. Unless necessary, it’s forbidden to 
change the module program.

sic

[isnoAhoy (Gast)]

Sorry for spamming, das HMS2401 enthält ebenfalls die gesuchte Pin 
Belegung, nur leicht geändert. Selbst die Tabellenüber/-unterschrift 
scheint prinzipiell beides mal "HM2401 interface pins" zu sein:

UserGuide und den Pin Belegungen:
https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285

2.2 Pin Definition
This Table 1 describes the interface pins.

Table 1 HM2401 interface pins

NO.   Symbol   I/O Type   Function
1     Gnd      P          Power supply reference ground pin
2     NC       I          Null pin, no internal connection
3     P1.5     I/O        RESERVED, P1.5, which is connected to P1.5 on 
the IC
4     P1.6     I/O        RESERVED, P1.6, which is connected to P1.6 on 
the IC
5     P0.1     I/O        RESERVED, P0.1, which is connected to P0.1 on 
the IC
6     P0.6     I/O        RESERVED, P0.6, which is connected to P0.6 on 
the IC
7     SCK      I/O        Serial peripheral interface clock pin
8     GND      P          Power supply reference ground pin
9     RXD      I/O        UART_RX, which is connected to P0.4 on the IC
10    TXD      Output     UART_TX, which is connected to P0.3 on the IC
11    GND      P          Power supply reference ground pin
12    VCC      P          Power supply pin
13    PRG      I/O        Set high to enter flash programming mode
14    SCK      I/O        Serial peripheral interface clock pin
15    MO       O          Serial peripheral interface data output pin
16    MI       I          Serial peripheral interface data input pin
17    SCN      I/O        Serial peripheral interface Chip selection pin
18    RST      I/O        Hardware reset pin (active at a low level)
19    GND      P          Power supply reference ground pin
20    GND      P          Power supply reference ground pin

3.2 Summarize the specific operational use conditions
**This module can be used in DTU, micro-converter and other equipment**. 
The input voltage to the module should be nominally 1.9~3.6 VDC and the 
ambient temperature of the module should not exceed 80°C. HM2401 uses a 
PCB antenna with max antenna gain 2 dBi. If the antenna needs to be 
changed, the certification should be re-applied.

4. Basic Operation
4.1 NRF Channel List
Depending on the program, the module can work on 2403, 2423, 2440, 2461 
or
2475MHz. Unless necessary, it’s forbidden to change the module program.

6. Technical Data
Model             HM2401
Type              2.4G RF
Channel List      2403, 2423, 2440, 2461, 2475MHz
Modulation Type   GFSK
Antenna Gain      2dBi
Working Voltage   1.9~3.6V
Power Consumption 40mW typical

[Heinz R. (heijz)]

Ich bekomme merkwürdigerweise die Ahoy-Software nicht zum laufen

Auf der Konsole kommt nur

Requesting Inverter SN 116474903203
Transmit 27 | 15 74 90 32 03 78 56 34 12 80 0B 00 62 87 96 11 00 00 00 
05 00 00 00 00 09 81 AC
Error while retrieving data: last frame missing: Request Retransmit
Transmit 27 | 15 74 90 32 03 78 56 34 12 80 0B 00 62 87 96 11 00 00 00 
05 00 00 00 00 09 81 AC
Error while retrieving data: last frame missing: Request Retransmit

Merkwürdigerweise funktioniert das Ganze mit Hubis NRFSendRcv - einen 
Hardwarefehler kann ich somit eigentlich ausschließen?

Das Thema IRQ an D1 oder D3 ist mir bekannt, auch ein flashen einer 
blank.bin brachte nichts

Hat jemand zufällig ähnliche Erfahrungen und eine Lösung gefunden?

[Daniel R. (daniel92)]

Hallo Heinz R,

dieses Problem hatte ich auch. Prüf mal ob im Webinterface auch die 
S.Nr. hinterlegt ist vom WR.

Danach sollte es gehen. :)

[Harald (Gast)]

Daniel R. schrieb:
> Hallo Heinz R,
>
> dieses Problem hatte ich auch. Prüf mal ob im Webinterface auch die
> S.Nr. hinterlegt ist vom WR.
>
> Danach sollte es gehen. :)


Was glaubst Du was das wohl bedeutet Du Quasselstrippe:
Requesting Inverter SN 116474903203

[Daniel R. (daniel92)]

Joa bei so einer patzigen Antwort kann ich auch nicht viel sagen.

Kann ja sein das ein Zahlendreher drinnen ist. Hatte auch mal zum Testen 
123456 geschrieben und wurde im Log angezeigt.

[Jan-Jonas S. (janjonas_s)]

Heh, Harald. Trollen ist meine Aufgabe !!1!

Ist denn 1164... richtig? Sollte das nicht 1161 sein?

Was noch merkwürdig ist, wenn kein Frame empfangen wurde kann man auch 
kein retransmit anfordern. Weil ein einzelnes Frame bzw. damit auch 
automatisch, und das letzte Frame nicht retransmittet werden kann.

[Harald (Gast)]

> Weil ein einzelnes Frame bzw. damit auch
> automatisch, und das letzte Frame nicht retransmittet werden kann.

Niemand kann diesen Satz verstehen.

[Heinz R. (heijz)]

Jan-Jonas S. schrieb:
> Ist denn 1164... richtig? Sollte das nicht 1161 sein?

Danke Jan-Jonas, das war der entscheidende Tipp, es läuft jetzt

Ich hatte mal mit dem Handy ein Foto vom WR gemacht , die Nummer 
eingegeben
Aber ich hatte vergessen das ich danach auch mal ein Foto von einem 
HMS.2000 gemacht habe :-)

Wollte es gerade hier hochladen - sehe es mir genau an - ich Depp...

Viele Grüße

[S. W. (bd72)]

Guten Abend,

ich habe einen HM-600 und würde gern die Daten auslesen. Hierfür wollte 
ich einen ESP-01 sowie  das Funkmodul NRF24L01+. Nun stehe ich vor der 
Frage, wie verbinde ich beide Module miteinander. Das ESP-01 scheint ja 
den SPI-Bus nicht nach außen zu legen, und das wird für die 
Kommunikation mit dem NRF24L01+ benötigt. Sehe ich das richtig? Also 
bleibt mir nur, einen anderes ESP8266-Modul zu besorgen, welches SPI 
über Pins verfügbar macht?

Viele Grüße

[Lukas P. (lumapu)]

Harald schrieb:
>> Weil ein einzelnes Frame bzw. damit auch
>> automatisch, und das letzte Frame nicht retransmittet werden kann.
>
> Niemand kann diesen Satz verstehen.

Doch ich ;-)
Ich habe es so implementiert, dass beim Fehlen des letzten Pakets 
nochmal alles mit dem gleichen Zeitstempel angefordert wird.

[Daniel R. (Gast)]

S. W. schrieb:
> Sehe ich das richtig? Also bleibt mir nur, einen anderes ESP8266-Modul
> zu besorgen, welches SPI über Pins verfügbar macht?

Moin S.W.,

so sehe ich das auch.
Das sollte ja kein Problem sein, ein neues ESP Kosten ja fast nichts. :)

Ich empfehle dir ein ESP32, dann kannst du für spätere Projekte diesen 
auch weiter verwenden.

[Chris (Gast)]

Kurze Info:
Seit dem Update von Ahoy 0.3.9 auf Ahoy Version 0.4.5 ist die MQTT 
Verbindung viel stabiler. Vorher ist die Verbindung nach max. 5h 
abgebrochen. Aktuell steht die Verbindung seit 31h.

[Jan-Jonas S. (janjonas_s)]

Ich nehm (fast) alles zurück. Von wegen man kann das letzte Paket nicht 
retransmitten...

Poll inverter 114172220143
2022-05-21 18:08:58.192865 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 89 0e 9a 00 00 00 05 00 00 00 00 80 20 5e
2022-05-21 18:08:58.244718 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 41 00 68 01 4e 01 42 00 6a 01 56 00 01 8d
2022-05-21 18:08:58.285863 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 01 60 00 00 f8 70 06 a3 06 82 08 e0 13 8b 02 85 a8
Error while retrieving data: Missing packet: Last packet 2
2022-05-21 18:08:58.788941 Transmit 11 | 15 72 22 01 43 78 56 34 12 83 8c
2022-05-21 18:08:58.832128 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 1c 03 e8 01 19 00 07 18 15 f3
2022-05-21 18:08:59.334726 Payload: 00 01 01 41 00 68 01 4e 01 42 00 6a 01 56 00 01 01 60 00 00 f8 70 06 a3 06 82 08 e0 13 8b 02 85 00 00 00 1c 03 e8 01 19 00 07 18 15
2022-05-21 18:08:59.334726 Decoded: 28.1 phase0=voltage:227.2, current:2.8, power:64.5, frequency:50.03 string0=voltage:32.1, current:1.04, power:33.4, total:65.888, daily:1699 string1=voltage:32.2, current:1.06, power:34.2, total:63.6, daily:1666

Edit. Mistiges Mistforum kann kein Markdown

[Sorbit (Gast)]

Aber sicher Herr Düsentrieb, die sind ja auch binärkompatibel.
> Ich empfehle dir ein ESP32, dann kannst du für spätere Projekte diesen
> auch weiter verwenden.

[Sorbit (Gast)]

Der Akkusativ wäre auch noch passend.
Aber das lernt wohl niemand mehr in der Schule, traurig.


😪😪😪😪

[Thomas H. (thomasm17)]

Hallo,

ich lese hier sonst nur mit und hab mich jetzt angemeldet und komme 
leider mit einer OT Frage

Hat jemand auf dem DTU Pro Board schon eine serielle Schnittstelle oder 
eine Terminalschnittstelle gefunden? Meine DTU ist tot. Weder per IP 
erreichbar, noch spannt sie ein WLAN auf.

Danke

[Daniel R. (daniel92)]

Moin Thomas,

laut einer Excel-Tabelle "Hoymiles-SerialNumbers.xlsx" gibt es nur einer 
der ein DTU-Pro hat (indirekt noch einer).

Die Frage, ist es frisch gekauft oder gebraucht gekauft?
Es gibt Bilder die vom inneren einer DTU zeigen 
"DxTxUxPxRxOinnereien.zip", hier wird auch eine Schnittstelle gezeigt.

Andi schrieb:
> CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn
> unteranderem zu Programmieren oder Debuggen.

- SPI Schnittstelle -

Ob jemand sich da schon reingehängt hat, kann ich aktuell nicht sagen. 
Soweit ich weiß haben wir keine weiteren Infos darüber.

Kannst ja gern mal schauen.

Ansonsten zum Problem:
Erstmal die einfachen Fragen, Liefert das Netzteil die Spannung? Nicht 
das hier der Fehler liegt. :P

2.) Wenn du es am LAN-Port hängst bekommst du ein Link? - LED leuchtet, 
oder die gegenstelle (Switch) blinkt fröhlich?

3.) Netzwerkkabel defekt? - Kann ja sein^^
4.) Sieht man sonst irgendeine Status LED?


Gruß Daniel

[Tobi D. (tobidd)]

hi zusammen,

hab jetzt meine esp version von 4.4 auf 4.8 geupdatet. jetzt gibt es im 
setup die möglichkeit dort die maximale wp vom angeschlossenen modul 
anzugeben. wofür ist das gut? davon abgesehen das ich bei meinem hm-400 
nur 1 modul anschließen kann, habe ich die auswahl von 4 modulen zum 
eintragen.

offtopic.: hat jemand schon nen gehäuse für nen wemos d1mini und dem 
nrf24 modul mit der externen antenne für nen 3d drucker konstruiert? bei 
thingi hab ich nix passendes gefunden mit der kombi

[Thomas H. (thomasm17)]

Daniel R. schrieb:
> Moin Thomas,
>
> laut einer Excel-Tabelle "Hoymiles-SerialNumbers.xlsx" gibt es nur einer
> der ein DTU-Pro hat (indirekt noch einer).
>
> Die Frage, ist es frisch gekauft oder gebraucht gekauft?
> Es gibt Bilder die vom inneren einer DTU zeigen
> "DxTxUxPxRxOinnereien.zip", hier wird auch eine Schnittstelle gezeigt.
>
> Andi schrieb:
>> CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn
>> unteranderem zu Programmieren oder Debuggen.
>
> - SPI Schnittstelle -
>
> Ob jemand sich da schon reingehängt hat, kann ich aktuell nicht sagen.
> Soweit ich weiß haben wir keine weiteren Infos darüber.
>
> Kannst ja gern mal schauen.
>
> Ansonsten zum Problem:
> Erstmal die einfachen Fragen,
  Liefert das Netzteil die Spannung? Nicht: Netzteil hab ich schon 
gewechselt
> das hier der Fehler liegt. :P
>
> 2.) Wenn du es am LAN-Port hängst bekommst du ein Link? - LED leuchtet,
> oder die gegenstelle (Switch) blinkt fröhlich?
  LEDs blinken alle
>
> 3.) Netzwerkkabel defekt? - Kann ja sein^^
Switch zeigt an, das Rx und Tx Pakete drüber gehen und link ist auf 
100Mbit
er holt sich aber keine DHCP Adresse mehr.

Anderer Switch und anderes NIC Kabel erfolglos getestet.

muss mir dann einen Notebook mit Wireshark fertig machen und die 
Kommunikation mit der betreffenden MAC ansehen

> 4.) Sieht man sonst irgendeine Status LED?
Die Status-LEDs zeigen, dass kein Internet und keine Cloud da ist.
Anderer Switch und anderes NIC Kabel getestet

PS:
Das Gerät war ein Neukauf und lief 18 Monate störungsfrei.

>
>
> Gruß Daniel

Dankeschön ..

Gruß Thomas

[Daniel R. (daniel92)]

Hi,

habe meins nun auch geupdated 0.4.4 auf 4.8.
Aktuell habe ich damit nun immense WiFi probleme.

Ping wird ausgeführt für 192.168.10.149 mit 32 Bytes Daten:
Antwort von 192.168.10.149: Bytes=32 Zeit=46ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=85ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=99ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=2ms TTL=255

Ping-Statistik für 192.168.10.149:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 2ms, Maximum = 99ms, Mittelwert = 58ms

Firefox (v100.0.2) lädt sich ins Nimmerleinstag. =(
ESP Serial Verbindung bleibt leer, irgendwann schmeist er mir paar logs 
entgegen.

@Thomas: Uiii, das ist ja Interessant... hmm sag mal bescheid wie weit 
du gekommen bist. Wobei, ich habe die Vermutung (da es länger ohne 
Probleme lief), das hier eventuell am Board probleme gibt.

Ich kenn es nur von einem 48-Port Switch (uralt), das hier ein DC/DC + 
Elkos flöten gegangen sind. Aber da es an sich "Neu" ist, hmm ... :/

Zur Not Werksreset durchführen?

[Andi (Gast)]

Die WLAN Probleme mit der neuesten Version kann ich ebenfalls 
bestätigen.
Ca. 3 Sekunden nach dem ersten Success + Inverter available scheint der 
ESP abzuschmieren(Builtin-LED bleibt aus, Webif/ESP nicht mehr 
erreichbar), dann fliegt er sehr oft aus dem WLAN(scheint hin und wieder 
sehr langsam erreichbar zu sein). Ist am einfachsten zu testen, wenn man 
ihn hochfährt und direkt danach auf der Statusseite bleibt, da sieht man 
das Pairing und danach bleibt die Uptime und alle anderen Zähler stehen.
Ich habe mich jetzt nicht weiter damit rumgeschlagen und bin erstmal 
wieder auf die 0.4.4 zurück.

[Lukas P. (lumapu)]

Andi schrieb:
> Die WLAN Probleme mit der neuesten Version kann ich ebenfalls
> bestätigen.
> Ca. 3 Sekunden nach dem ersten Success + Inverter available scheint der
> ESP abzuschmieren(Builtin-LED bleibt aus, Webif/ESP nicht mehr
> erreichbar), dann fliegt er sehr oft aus dem WLAN(scheint hin und wieder
> sehr langsam erreichbar zu sein).

Sehr schade, könnt ihr mir sagen welchen WR ihr habt. Es genügt 1, 2 
oder 4 Kanäle. Gerne auch über Github issues.
Ich kann keine Abstürze sehen (mehr als 6h Uptime) und habe das 4-Kanal 
Setup.

[Andi (Gast)]

@lumapu
Da ich die Version nur kurz getestet habe, kann ich nur Aussagen aus dem 
Kopf machen und nicht 100% genau Infos liefern, darum habe ich kein 
Issue im Git aufgemacht.
Ich habe einen HM800, also 2 Eingänge.
Ich habe mir den Code noch nicht so genau angesehen, aber rein vom 
Gefühl her ist die LED normalerweise an und beim Rx und/oder Tx flackert 
sie kurz, beim Fehlerfall war sie allerdings dauerhaft aus und im Router 
war der ESP nicht mehr verbunden, also scheint er sich wohl komplett 
aufzuhängen an irgendeiner Stelle nach den ersten Daten. Jetzt weiß ich 
aber nicht mehr genau, ob der nach paar Sekunden wieder langsam 
erreichbar war oder weil ich Resettet habe. Ich hatte auch beim 
rumspielen bei dem Fehler auf einmal alle Daten verloren(macht der ESP 
trotz einfach Stecker ziehen ja normalerweise nicht). Deswegen bin ich 
mir mit der WLAN aussage nicht ganz sicher, eventuell war die LED und 
WLAN auch nach dem Verlorengehen der Daten aus.

Was ich aber sehr sicher sagen kann ist, dass der Zugriff auf das Webif 
grottig bis hin zu nicht erreichbar war, als er noch die gespeicherte 
Konfig hatte und das kurz nachdem der Inverter als available in den paar 
Zeilen auf dem Homescreen war.
Vielleicht kann ich es ja morgen nochmal genauer testen, wenn es bis 
dahin nicht schon behoben ist :-)

[Lukas P. (lumapu)]

Tobi D. schrieb:
> jetzt gibt es im
> setup die möglichkeit dort die maximale wp vom angeschlossenen modul
> anzugeben. wofür ist das gut? davon abgesehen das ich bei meinem hm-400
> nur 1 modul anschließen kann, habe ich die auswahl von 4 modulen zum
> eintragen.

Der ESP berechnet die Einstrahlung in Prozent, sodass man sehen kann wie 
gut die Module ausgerichtet sind / wie klar die Luft ist.
Während man die Wechselrichter einträgt hat man noch keine Möglichkeit 
zu wissen wie viele Kanäle es geben wird, daher immer die Maximale 
Anzahl von 4.

[Daniel R. (daniel92)]

Moin Lukas,

Github Issue ist raus. Hoffe passt, wenn du mehr Infos brauchst einfach 
melden. :)

[Herbert K. (avr-herbi)]

Lukas P. schrieb:
.... wofür ist das gut? davon abgesehen das ich bei meinem hm-400
>> nur 1 modul anschließen kann....

Das ist ja wohl Quatsch !
Natürlich kann man da auch mehr Module anschließen !
Es ist halt nur 1 MPPT Eingang da mit 1 Paar Steckkontakten. Ich habe 
z.B. am HM350 2 Stk. Module. Das kommt ja auf die Daten der Module und 
der WR drauf an, das es zusammenpaßt zu Strömen, Spannungen und 
Leistungen.

[Tobi D. (tobidd)]

Ja natürlich kann ich auch mehrere module in Reihe oder parallel im 
hm-400 anschließen aber dann müssen die Werte von allen Modulen meiner 
Meinung nach dann trotzdem in das erste Feld eingetragen werden, da ja 
nur 1 Eingang da ist

[Daniel M. (daniel_m821)]

Ich meld mich auch mal wieder, nachdem GreenAkku das TSUN-Gateway statt 
mit 1-2 Tagen Lieferzeit dann nach knapp 6 Wochen doch endlich mal 
verschickt hat.

Gut sichtbar ist der Controller STM32F103, danach kommt der UART-WIFI 
Converter und selbstverständlich der NRF 24LE1E.

Das Platinenlayout ist relativ ähnlich zu Hoymiles.
Ich schaue mir die Kommunikation an, wenn ich weiß, wo ich was 
sinnvolles aus der Platine bekomme. Die Rx/Tx Pins sind bei mir 3 
Tastpunkte in etwas anderer Anordnung.

Die ID'S laufen nach dem Muster: 10D573118xxx
Die x sind laufende Nummerierung. Habe mehrere hier.

Ist eher Hyperterminal oder Putty für die serielle Verbindung ratsam?
Gibt es irgendwas, wo ich besonderen Fokus drauflegen sollte?

lg
Daniel M.

edit: Bilder nachgereicht, nachdem es erstmal nicht ging

[Siggi U. (sude)]

Hallo,
gibt es eigentlich einen praktischen Grund für die Beschränkung auf drei 
Geräte im ESP8266? Ich habe 4 HM-1500 und würde die gerne mit einem ESP 
auslesen.

[Jan-Jonas S. (janjonas_s)]

Hi Siggi,
glaube an so viele Inverter in einem Setup hat hier bisher keiner 
gedacht. Ich währe schon froh ein Setup zum testen für 2 gleichzeitig zu 
haben.
Python hat da jedenfalls kein Limit gesetzt, ist aber glaube ich noch 
nie mit mehr als einem gleichzeitig in Betrieb gewesen. Theoretisch 
sollte es gehen.

Hat jemand die rpi-Variante mit mehr als einem am Laufen?

[Daniel R. (daniel92)]

Habe zwar ein rpi, jedoch nur ein WR.

[Lukas P. (lumapu)]

Siggi U. schrieb:
> Hallo,
> gibt es eigentlich einen praktischen Grund für die Beschränkung auf drei
> Geräte im ESP8266? Ich habe 4 HM-1500 und würde die gerne mit einem ESP
> auslesen.

Klar gibt es die Option, schon sehr lange:
https://github.com/grindylow/ahoy/blob/2199d46890ea826a19068253c36e7b4973b65775/tools/esp8266/config.h#L33

Der Code ESP ist theoretisch auch nicht limitiert - nur wird irgendwan 
der Speicher im Chip selbst knapp.

[Herbert K. (avr-herbi)]

Hallo, ich habe per ESP8266 und Hubis Ur-Version 4 WR die ich Seriell 
abfrage wenn mir danach ist. Funktioniert auch schon mal den ganzen Tag 
und schreibt schön ein LOG voll auf´m PC. Reicht mir so erst mal um zu 
sehen, das die WR tun, was sie sollen  :-)

[Siggi U. (sude)]

Alles klar, dann baue ich mir mal eine Version mit 4 WR. Kann dann ja 
berichten ob es klappt.

[Ziyat T. (toe_c)]

Thomas H. schrieb:
> Hallo,
>
> ich lese hier sonst nur mit und hab mich jetzt angemeldet und komme
> leider mit einer OT Frage
>
> Hat jemand auf dem DTU Pro Board schon eine serielle Schnittstelle oder
> eine Terminalschnittstelle gefunden? Meine DTU ist tot. Weder per IP
> erreichbar, noch spannt sie ein WLAN auf.
>
> Danke

Hallo Thomas
DTU-Pro hat noch Ethernet(RJ45) und RS485-Modbus SS

[Peter L. (leliep)]

Tobi D. schrieb:
> offtopic.: hat jemand schon nen gehäuse für nen wemos d1mini und dem
> nrf24 modul mit der externen antenne für nen 3d drucker konstruiert? bei
> thingi hab ich nix passendes gefunden mit der kombi

Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich 
ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls 
jemand Interesse hat, stelle ich die .stl gern zur Verfügung.

[Lars B. (docbmuc)]

Hi Daniel,

Daniel M. schrieb:

>
> Das Platinenlayout ist relativ ähnlich zu Hoymiles.

ich würde mal meinen, dass TSUN und Hoymiles Geräte eher sowas wie 
"bei-der-Geburt-getrennte-Zwillinge" sind. Die Dinger - auch die DTUs - 
fallen sicherlich vom selben Band. ;-)

> Ich schaue mir die Kommunikation an, wenn ich weiß, wo ich was
> sinnvolles aus der Platine bekomme. Die Rx/Tx Pins sind bei mir 3
> Tastpunkte in etwas anderer Anordnung.

Ich weiss nicht, ob Dir die UART Testpoints des STM etwas nützen. Um die 
Kommunikation zwischen STM und Nordic belauschen zu können, musst Du 
Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO 
(Output Nordic) und SCK (Clock der SPI) mit einem entsprechenden Logic 
Analyzer oder SPI Sniffer verbinden und mitloggen... :)

Mich würde es allerdings sehr wundern, wenn das Protokoll was ganz 
anderes wäre als bei den HMs.

LG,
Lars

[martin (Gast)]

Lars B. schrieb:
> Um die
> Kommunikation zwischen STM und Nordic belauschen zu können, musst Du
> Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO
> (Output Nordic) und SCK (Clock der SPI)

Nein, bei der UART bist du schon richtig. Wie schon mehrfach im Thread 
beschrieben, findet über die SPI-Schnittstelle des NRF keine 
Kommunikation statt, die ist nur zur Programmierung des NRF-internen 
Controllers - zumindest bei der HM-DTU. Wird dann hier vermutlich 
genauso sein.

[Herbert K. (avr-herbi)]

Heute gabs 2 neue Videos von hoymiles:

1)
https://www.youtube.com/watch?v=ed7rJvYVuJg
Ich sag da mal lieber nix zu. Kann sich jeder seine Meinung selbst 
bilden. Einzig interessant ist der Unterschied zu den DTU..."S" Modellen 
bei der Reichweite.

2) Anschauen kann man sich auch sparen:
https://www.youtube.com/watch?v=9GbAhf3pU7I

[rosch99 (Gast)]

Peter L. schrieb:
> Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich
> ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls
> jemand Interesse hat, stelle ich die .stl gern zur Verfügung.

Hallo Peter,
ich hätte Interesse an dem .stl :-)
Bitte hier oder auf github hochladen.

Grüße
rosch

[Peter L. (leliep)]

rosch99 schrieb:
> Peter L. schrieb:
>> Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich
>> ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls
>> jemand Interesse hat, stelle ich die .stl gern zur Verfügung.
>
> Hallo Peter,
> ich hätte Interesse an dem .stl :-)
> Bitte hier oder auf github hochladen.
>
> Grüße
> rosch

https://github.com/grindylow/ahoy/pull/59

:-)

[Tom M. (tom_m)]

Hab mal auf die schnelle ein Gehäuse gebastelt für die mit externer 
Antenne.
Bisschen filigran aber lässt sich drucken.
(Sorry, bin leider kein Zeichen-Profi ;-) )

https://www.thingiverse.com/thing:5395556



Grüße
Thomas

[Bernd (Gast)]

sorbit schrieb:
> Hat jemand das schon einmal "angezapft" um ein eigenes Monitoring ohne
> deren Cloudzwang zu realsieren?
>
> Es gibt offensichtlich einen "Adapter", der das "2,4 GhZ Signal umsetzt
> und dann via WLAN an deren Cloudsysteme versendet.

Eine Anmerkung von mir zur Ausgangsfrage:
Mit einer DTU-PRO von Hoymiles für knapp 200 € kann man zwar Daten auch 
in die Cloud senden. Muss man aber nicht. Man kann die DTU-PRO aber über 
MODBUS-TCP lokal auslesen und alle Daten aller angeschlossenen 
Wechselrichter auslesen.

Ein konkretes Beispiel mit iobroker findet ihr unter 
https://forum.iobroker.net/topic/55115/gel%C3%B6st-ben%C3%B6tige-hilfe-modbus-tcp-hoymiles-hm-1500-dtu-pro/6

[Jan-Jonas S. (janjonas_s)]

Hi Bernd,

das ist wohl richtig. Allerdings haben wir Spaß am reverse Engineering 
und wollen die Daten nach Mqtt bzw. Influx exportieren. Kann die DTU-Pro 
das auch?
Spaß bei Seite. Natürlich nicht.

Für 200€ kauft man sich lieber ein Panel mehr, anstatt die 
Wirtschaftlichkeit endgültig zu begraben. Wir machen das mit 20€ :)

Nichts desto Trotz brauchen wir die DTU-Pro um sie zu belauschen. Nicht 
um sie per Modbus-TCP zu befragen. Das kann jeder ^^
Denn wir wollen mehr Daten! ...und besser verstehen, was Hoymiles mit 
ihrem trojanischen Pferd so in unseren Netzen treibt.

Gruß,
Jan

[Lars B. (docbmuc)]

martin schrieb:
> Lars B. schrieb:
>> Um die
>> Kommunikation zwischen STM und Nordic belauschen zu können, musst Du
>> Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO
>> (Output Nordic) und SCK (Clock der SPI)
>
> Nein, bei der UART bist du schon richtig. Wie schon mehrfach im Thread
> beschrieben, findet über die SPI-Schnittstelle des NRF keine
> Kommunikation statt, die ist nur zur Programmierung des NRF-internen
> Controllers - zumindest bei der HM-DTU. Wird dann hier vermutlich
> genauso sein.

richtig - mein Fehler! Der UART zwischen dem GD Controller und dem nRF 
liegt ja IMHO auf den beiden Testpoints beim Knopf der DTU...

Sorry für die Verwirrung,
Lars

[Daniel R. (daniel92)]

Hallo zusammen,

bei der Bucht wird ein DTU-Pro verkauft. Was denkt ihr, macht es Sinn 
darauf zu Bieten? Oder könnte es sein, das die DTU beim Hersteller mit 
einem Account verknüpft ist und diese eventuell probleme aufkommen 
könnte?

Thomas H. schrieb:
> Meine DTU ist tot.

Könnte ich eventuell dein DTU-Pro mir anschauen, vielleicht kann man da 
noch was retten? :)

Gruß Daniel

[Maik R. (bastelbarney)]

Servus,

Martin G. schrieb vor einer ganzen Weile im Beitrag #7016238:
> Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in
> Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier
> unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe
> geschaltet?

Zumindest schaltet der HM-1500  Gen3  H00.04.00 / V01.00.16 seine 4 
Eingänge nicht vor der separaten Messung zusammen, denn in der Cloud und 
S-Miles-App sehe ich separate, leicht unterschiedliche  Leistungsdaten 
meiner 4 identischen Panels. Aber nur als DC-Leistung. DC current und DC 
voltage bekomme ich nicht.

Habe seit gestern endlich meine DTU-Wlite  Gen3  H06.01.01 / 
V00.03.05. Gibt's in Mödling (AT) erheblich günstiger als bei den 
Preußen.

Habe aber (noch) kein Sniffer-Equipment und die Panels nur provisorisch 
auf Holzgestell. Stockschrauben, Bituplan und ein regenfreier Tag fehlen 
noch. Wenn die Mechanik erledigt ist, steige ich mit Eurer Starthilfe 
gerne mit ins Sniffen ein. Erste ESP8266 Erfahrungen mit ArduinoIDE und 
VSCode habe ich schon mit ein paar Mods an Airrohr/DNMS gesammelt.

Aber Warnung: bei HF-Technik bin ich keine Hilfe. Hatte ich zugunsten 
Stromrichterantriebstechnik abgewählt (WPU-ET-m88-sg3) und auch davon 
inzwischen vieles vergessen :-(.

[Maik R. (bastelbarney)]

Daniel R. schrieb:
> bei der Bucht wird ein DTU-Pro verkauft. Was denkt ihr, macht es Sinn
> darauf zu Bieten? Oder könnte es sein, das die DTU beim Hersteller mit
> einem Account verknüpft ist und diese eventuell probleme aufkommen
> könnte?

Wenn Du (wie ich) ein Installateur-Account bei HOYMILES hast und der 
Verkäufer den DTU bei sich austrägt (oder der Verkäufer Dir seine 
Accountdaten überlässt), kannst Du das Ding nehmen. Ob man den DTU auch 
"kapern" kann, nur weil man die Seriennummer weiß? Ich hoffe nicht!
Vermutlich kann man ihn nur übernehmen, wenn man Seriennummer und Zugang 
zum internen WLAN-AP hat. Den spannt er wie viele ESP-Devices auf, wenn 
er seinen bisherigen externen AP nicht findet.
In JEDEM FALL muss die Seriennummer auf dem Gehäuse noch lesbar sein, 
sonst kannst Du ihn nicht übernehmen!

Liegt gerade bei ca. 160€ und läuft noch 11 Stunden. Hatte ich auch in 
Erwägung gezogen, dann kam der W-Lite aber doch noch an. Zwei erlaubt 
die Finanzministerin nicht.

Wenn Du keinen Installateur-Account bei HOYMILES hast: ich könnte den 
DTU zur Not bei mir mit eintragen und Dir ein Kunden-Account darauf 
erstellen. Ich wäre dann quasi Dein Solateur und Du der Besitzer.

Servus,
BastelBarney

[Maik R. (bastelbarney)]

Maik R. schrieb:
> Wenn Du keinen Installateur-Account bei HOYMILES hast: ich könnte den
> DTU zur Not bei mir mit eintragen und Dir ein Kunden-Account darauf
> erstellen. Ich wäre dann quasi Dein Solateur und Du der Besitzer.

Argh! Das ginge natürlich nur, wenn ich einmal physischen Zugriff auf 
Deinen DTU habe!
Kann man im Grunde auch per TeamViewer oder so machen, aber das wird 
dann arg kompliziert, weil das Gerät, das Du mit der DTU per WLAN 
verbindest zusätzlich auch per 2. Netzwerkinterface per TeamViewer aus 
dem Internet erreichbar sein muß. Du willst nicht Deinen PC per TV an 
mich freigeben. Müßtest also erstmal einen separaten PC dafür einrichten 
(oder ein Live-Linux booten), nur zu diesem Zweck. Wenn das für Dich ein 
"kein Problem, mache ich oft" ist, wäre das ein Weg...

Ergo: Du brauchst ein Installateur-Account bei HOYMILES oder jemanden in 
Deiner Nähe, der einen hat.

Servus,
BastelBarney

[Maik R. (bastelbarney)]

Sergey S. schrieb:
> Guten Tag! Ich habe H M 600 114170810815
> und DTU W100 10D 373114359. Kann mir jemand helfen, die
> “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer
> gibt es nicht an, sagt, dass er selbst der Installateur ist.

Du benötigst das Installer-Konto nicht unbedingt. Der Verkäufer sollte 
Dir aber ein User-Account anlegen und geben. Damit greifst Du per 
global.hoymiles.com auf Deine Daten zu. Oder per "S-Miles-User App".

HTH,
BastelBarney

[Daniel R. (daniel92)]

Guten Morgen bastelbarney,

vielen dank für die Info. Ich verstehe nicht warum der Hersteller das so 
kompliziert macht... Oh mann. Naja an sich wäre es kein Problem, würde 
es sogar einfach zu dir schicken wenn es einfacher wäre, dann könntest 
du es später wieder zurück schicken (Wenn ich dich zwekcs Einrichtung 
richtig verstanden habe).

Ich kenne jemand der die WR verkauft, aber er hat bisher kein DTU-Pro im 
Sortiment.

Edit: Aktuell liegt der Preis in der Bucht bei EUR 157,00 (S.Nr lautet 
10f874435634, wie auf dem Bild zu sehen).

Da kann ich mir es gleich aus AT bestellen. - 
https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html

Gruß Daniel

[Daniel M. (daniel_m821)]

Guten Morgen zusammen,

wie erwartet, kochen TSUN und Hoylmiles ein ähnliches Süppchen.
Die Tastpunkte auf der Platine sind Rx/Tx zwischen dem NRF und meinem 
STM. Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein.
Die Verbindung läuft ebenfalls mit 125000 BAUD, war nicht so einfach, 
ein Programm zu finden, dass mir das unter Windows 10 auch in Hex 
ausgibt. Nutze dafür Realterm.

Die Requests sehen so aus und sind als capture.txt-Datei noch im Anhang:

7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E11635003166350031600117F                                                                                                                            
7E09635003166350031600097F                                                                                                                            
7E11635003166350031600117F

Darauf die Antworten in der capture-rx.txt, allerdings unsortiert zu den 
Requests. Ich konnte noch nicht beides parallel anschauen, da mir die 
USB-Schnittstellen ausgegangen sind:

7E8963500316635003160157000E0961138601CB005900AE117F                                                                                                  
7E9163500316635003160157000E0962138601C1005300AE0A7F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160158000E0962138601CB005900AE1D7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160157000E0962138601C1005300AF0B7F                                                                                                  
7E8963500316635003160158000F0962138601CB005900AF1D7F                                                                                                  
7E9163500316635003160157000E0962138601C1005300AF0B7F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160158000F0962138601CB005900AE1C7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160158000F0962138601C1005300AE047F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160159000F0963138601EF005900AD3B7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160159000F0963138601E4005300AD227F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E8963500316635003160159000F0963138601EF005900AD3B7F                                                                                                  
7E9263500316635003160003000000000000917F                                                                                                              
7E9163500316635003160159000F0963138701E4005300AE207F                                                                                                  
7E88635003166350031600030000000000008B7F                                                                                                              
7E896350031663500316015900100963138701EF005900AE267F

7E896350031663500316014F00360960138806EB00A300DC917F

63500316 ist meine WR-ID. Auch hier wird diese 2x hintereinander 
aufgeführt, jedoch nicht in umgekehrter Reihenfolge.

Greife ich mir die letzten beiden Zeilen:
7E896350031663500316 0159 0010 0963 1387 01EF 00 5900 AE 26 7F
früh   Dezimal       345  16   2403 4999 495          174
7E896350031663500316 014F 0036 0960 1388 06EB 00 A300 DC 91 7F
später Dezimal       335  54   2400 5000 1771         220

7E916350031663500316 0159 000F 0963 1387 01E4 00 5300 AE 20 7F
früh  Dezimal        345  15   2403 4999 484          174
7E916350031663500316 0155 0036 0960 1388 06EE 00 9B00 DC AE 7F
später Dezimal       341  54   2400 5000 1774         220
DC V/10 | DC I/10 | AC V/10 | AC Frequenz/100 | AC Power/10 | ??? | 
Temperatur/10 | Daily Production/1000?

Modul 1 und 2 jeweils identifiziert über die 89 und 91 am Anfang. 7E ist 
der Beginn der Übertragung, 7F das Ende.
Eine CRC habe ich so nicht entdeckt, außer die vorletzten beiden Byte.

Von Abends habe ich zu den 88 und 92 noch diese Infos:
7E88635003166350031600020000000000008A7F
7E9263500316635003160002000000000000907F

Tagsüber:
7E88635003166350031600030000000000008B7F
7E9263500316635003160003000000000000917F

die 02 bzw. 03 Tagsüber ist der Modulstatus. Diese Nummer taucht auch in 
der Cloud auf:
Spekulation! - wird beobachtet
02 - MPPT inaktiv, Modul verbunden und arbeitet
03 - MPPT aktiv, Modul verbunden und arbeitet
05 - ? Modul liefert zu wenig Leistung
00 - Modul aus

Ich habe den Netzwerkverkehr zwischen DTU und Server aufgefangen. 
Mobiler Hotspot und Wireshark, Datei raw.txt:

a55600104291f008881173d510020001010116051c0910067800020a160350634110014f01350060098713bc069c009e0e0000d7000300000000000100000000000a160350634110025601340061098713bf0694008e0e0000d7000300000000000100000000001415

Hier haben wir meine DTU: 08881173d510 in umgekehrter Reihenfolge
Datum und Uhrzeit YYMMDDhhmmss: 16051c091006
Die WR-ID: 16035063 in umgekehrter Reihenfolge
DC- und AC-Daten, Produktion tägl. und gesamt sowie Modulstatus, 
Modulfehler-Zähler, Verbindungsstatus (Module?), Temperaturen.

Die Zeile oben ist etwa im gleichen Zeitraum übertragen worden als ich 
die einzelnen Daten (Zeile "später") abgegriffen habe. Meine Freundin 
hat mir geholfen, ein kleines Python-Script zu schreiben, mit dem ich 
die Daten dekodieren kann.
Das Script analyse.py ist sehr einfach gehalten, es erfüllt seinen 
Zweck, ist allerdings noch nicht auf dem Stand, dass man es groß 
braucht. Es analysiert nur die Daten, die an den Tsun-Server gehen.
Hier passiert automatisch alle 15min eine Übertragung mit allen Daten 
seitens der DTU ohne vorher einen Request des Server, weiterhin jede 
Minute ein Request der DTU nach der Uhrzeit mit passender Antwort vom 
Server.
Request: a500001047c62508881173d510020001013f15
Response: 
a50d001017c72508881173d510000201013f0016051c0a090878000100002715

Das dürfte zugleich eine Art Ping für den Server sein, dass die DTU noch 
online ist.
In der DTU kann ich Server- und Port des Ziel ändern, außerdem die 
Kommunikationseinstellungen zum USR-C210.

Da ich noch keinerlei Datentransfer durch die Luft gesehen habe, 
discover und pretender aus dem ahoy-Repo nichts finden, benötige ich 
hier etwas Starthilfe.
Ich habe noch einen Wemos-D1 mini hier, den ich gerne mit entweder ahoy 
oder dem anderen Prog flashen würde. Könnte mir jemand eine Vorlage 
dafür machen oder erklären, wo ich was ändern muss? Bin mit Arduino noch 
nicht ganz warm.

Vielen Dank für eure Hilfe :)

lg
Daniel M.

[Herbert K. (avr-herbi)]

Daniel M. schrieb:
> Guten Morgen zusammen,...

Guten Morgen Daniel M. !
Super Arbeit von Dir und Deiner Freundin !
Endlich geht es mal mit den Protokollen weiter !
(Bits, Bytes und Status, ...)

[IsnoAhoy (Gast)]

Jan-Jonas,
ich finde die von Bernd vorgeschlagene „Abfrage“ über Modbus TCP nicht 
so falsch. Speziell wenn wir jemand wie Arnaldo G oder Ziyat T. mit 
einer DTU Pro und Modbus Schnittstelle haben dann ist das doch die 
ideale Möglichkeit per Modbus „Kommandos“ an die WR zu stellen und 
parallel an den RX/TX Punkten das MCU/nRF Protokoll abzugreifen. Wenn 
wir also ein klares Testszenario per Modbus vorgeben könnten, wäre uns 
allen doch geholfen da wir dann auch die gwünschten Testdaten bekämen.
Was wäre denn per Modbus möglich und nötig ?
* Werte aller Art abfragen
* WR auf X% Leistung limitieren
* WR wieder unlimitiert betreiben
etc.
Wenn wir die Anforderungen an das Testszenario schon mal definieren und 
ein klares Testprogramm für Modbus haben dann klappt es vielleicht auch 
schneller die gesuchten Daten zu bekommen.

[Daniel R. (daniel92)]

Moin zusammen,

@ Daniel M: Super Arbeit! Hast du zufällig vom Mitschnitt ein *.pcap 
File?
Ich gehe hier jetzt noch davon aus, wie du oben beshrieben hast, das es 
sich um ein "TSUN" handelt?

Daniel M. schrieb:
> Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein.

Konntest du hier mit einem Multimeter das nachprüfen auf einen 
Durchgang?
Wenn es kein GND Verbindung hat, wäre es Interessant füher oder später 
auch zu wissen wo dieser hinführt. :)

Die Frage die sich mir noch stellt (spez. an Arnaldo G & Ziyat T.), 
besitzt Ihr zufällig auch ein DTSU666? - Dann hätte man nähmlich ein 
kompletten Aufbau von einer 0-Einspeisung System. Dann wäre es ja noch 
einfacher alles weiter zu Analysieren. Jedoch gehe ich hier mal davon 
aus das ein DTSU666 noch fehlt?

Gruß Daniel

[Daniel M. (daniel_m821)]

Kleiner Nachtrag:
weiteres Decoding der einzelnen Werte wie folgt:
7E 89 63500316 63500316 014A 002D 0962 1383 04A2 0269   0123  FB  7F
                        330  40   2402 4995 1186 617    291   251
                        DCV  DCI  ACV  ACF  ACP  DProd. Temp.
7E 91 63500316 63500316 014E 0026 0961 1383 049D 0261   0122   D9  7F
                        334  38   2401 4995 1181 609    290  217
DCV=DC Voltage /10
DCI=DC Strom /10
ACV=AC Voltage /10
ACF=AC Frequenz /100
ACP=AC Leistung /10
DProd.= tägliche Produktion /1000
Temp.=Temperatur /10
Die letzten Werte sind Fragezeichen, könnte CRC sein, weiß ich aber 
nicht.


Die Daten an den Server zusammen mit fast passender Abfrage der 
DTU-Daten:
7E 89 63500316 63500316 014D 002E 095A 1386 05A6 02C7 0126 6C 7F
                        333  46   2394 4998 1446 711  294  108
7E 91 63500316 63500316 0151 002B 095A 1386 059D 02BE 0126 2F 7F
                        337  43   2394 4998 1437 702  294  47
-
a55600104254b308881173d510020001010116051c0c1f097800020a160350634110014d 
012b0059098613a605c702c910000025010300000000000100000000000a160350634110 
0251012b00590986139d05be02b810000025010300000000000100000000009a15
DTU id:  08881173d510
WR id:  160350634110
Datum:  28 . 5 . 22  | Zeit:  12 : 31 : 9
Panel: 1
DC Volt:  33.3 V | DC Amp:  4.3 A | AC Volt:  239.3 | Temperatur:  3.7 
C | A02 01 1
AC Freq:  49.98 Hz | AC Power:  144.6 W | P today:  0.711 kWh | P total: 
4.297 MWh
Modulstatus:  3 | Anz. Modulfehler: 0 | Connectionstatus:  1
-
Panel: 2
DC Volt:  33.7 V | DC Amp:  4.3 A | AC Volt:  239.3 | Temperatur:  3.7 
C | A02 01 1
AC Freq:  49.98 Hz | AC Power:  143.7 W | P today:  0.702 kWh | P total: 
4.28 MWh
Modulstatus:  3 | Anz. Modulfehler: 0 | Connectionstatus:  1

Die Temperatur funktioniert offenbar nicht mehr, warum auch immer. Der 
Rest der Daten kommt jedoch hin. Das schwächere Modul 2 liegt leider 
unterhalb des Dachfirst, der zu gerne von Vögeln als Toilette benutzt 
wird, daher ist auch, denke ich, recht gut erkennbar, wie die Zuordnung 
ist:
89 ist Panel 1, 91 ist Panel 2

lg
Daniel M.

Edit: Am Anfang ist eine Zeile zu den Werten verrutscht.

[Daniel M. (daniel_m821)]

Daniel R. schrieb:

> @ Daniel M: Super Arbeit! Hast du zufällig vom Mitschnitt ein *.pcap
> File?
> Ich gehe hier jetzt noch davon aus, wie du oben beshrieben hast, das es
> sich um ein "TSUN" handelt?

Hi, hängt hier dran :)
Ja, ist ein TSUN TSOL-M800 mit 2 MPPT-Trackern.

> Daniel M. schrieb:
>> Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein.
>
> Konntest du hier mit einem Multimeter das nachprüfen auf einen
> Durchgang?
> Wenn es kein GND Verbindung hat, wäre es Interessant füher oder später
> auch zu wissen wo dieser hinführt. :)

Der Tastpunkt ist 3,3V.
Mit dem Durchgangsprüfer hatte ich Verbindung nach VDD, VSS und GND. 
Maximale Verwirrung.

lg
Daniel M.

[Maik R. (bastelbarney)]

Servus,
die Verdrahtung für https://github.com/grindylow/ahoy geht immer(?) von 
einem ESP8266 "Wemos D1mini" aus. Daran mangelt es mir gerade.
Doch habe ich noch paar AZDelivery ESP8266 "NodeMCU v3" herumliegen ... 
weiss jmd von Euch aus dem Stehgreif, ob die PIN-Bezeichnungen bei 
beiden identisch ist?

Muss ich sonst im Source die Pins anpassen?

Merci,
BastelBarney

[Heinz R. (heijz)]

Maik R. schrieb:
> Muss ich sonst im Source die Pins anpassen?

Wemos hat die Dx-Bezeichnungen

Nichts im Code ändern, einfach passend anlöten - die GPIO-Bezeichnungen 
sind die gleichen

https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

[Maik R. (bastelbarney)]

Heinz R. schrieb:
> Wemos hat die Dx-Bezeichnungen
> Nichts im Code ändern, einfach passend anlöten [...]
> https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

Dankeschön! Und guter Link, sehr schnell überblickbar dort.

[IsnoAhoy (Gast)]

Hallo Bastel Barney,
habe auch eine NodeMCU und die selben PINs wie am Wemos verwendet. Wenn 
ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und 
Raspberry Pi hochladen.

[Daniel R. (daniel92)]

Moin Ahoy,

ich glaube das es Sinnvoll ist. Damit andere User am Projekt mitwirken 
wollen, aber nicht das technische "know-how" haben dennoch mitwirken 
können. :)

Fritzing ist ja denke ich schnell gemacht.

[Ziyat T. (toe_c)]

Hallo
Ich habe, wie schon früher gemeldet:
-DTU-Pro
-DTSU666
-MI1500
-Raspi+python(pymodbus+mqtt+nodered)
ausser WR alle mit Modbus verbunden um den zero export zu realisieren, 
DTU-Pro+MI-Series kann den zero export nicht wirklich.

Da ich einen MI1500 habe kann ich euch nicht helfen, da die MI-Serie 
völlig anders funktioniert:
- RF Protokoll komplett anders
- Modbus auf Port/WR Ebene schwach implementiert

Ich werde aber bald einen HM1500 bekommen, dann kann ich weiter

[Misch O. (misch_o)]

Hallo,
suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem 
Link dazu helfen .... den neuesten Code bekomme ich mit der Arduino IDE 
nicht kompiliert warum auch immer .'
im Moment benutze ich die Version 0.4.4 mit einem HM1500, funktioniert 
gut
Danke !!!
Vielen Dank im voraus
misch