hm800assignment ist gleich zu hm600assignment about ahoy

[Sprinterfreak]

Weil der Code älter ist als die Erkenntnis. Wir haben noch sehr wenig Informationen darüber, was die DTU mit den Wechselrichtern über längere Zeiträume spricht. Uns fehlen einfach Rohdaten vom Original zum analysieren. Die aktuelle Entwicklung basiert mehr auf Brute-Force.
WIr wissen zum Beispiel auch seit kurzem, dass wir mit dem ursprünglichen Ansatz des verarbeitens der Responses, die Wechselrichter mit 2 MPPT nicht komplett auslesen können und restliche Wechselrichter nicht korrekt auslesen können.
Der Neubau der Software, um die Daten "korrekter" lesen zu können ist aktuell Priorität. Entdeckt wurde das kürzlich mit dem python-Script. Das ist aktuell noch auf dem Stand "Entwicklungs-Snapshot" des ersten Erfolges. @lumapu passt zur Zeit soweit ich das mitbekommen habe die C-Implementierung entsprechend an.

[lumapu]

genau so stimmt es. Ich bin noch dran die aktuellen Erkenntnisse in die ESP Version zu implementieren.
Ein kleiner Fortschritt wurde bereits veröffentlicht: die Umschaltung des RX Channels. Noch nicht ganz zufriedenstellend, da das Paket mit der ID 0x01 seltener als die anderen kommt. @Sprinterfreak ist das in der Python Version auch so?

Übersicht meiner heutigen Quoten:
0x01: 75%
0x02: 99%
0x03: 99%
0x84: 100%
Quoten basieren auf dem häufigsten empfangenen Paket 0x84. Meine Erwartung wäre, das sie Erfolgsquote bei 0x01 auch bei 99% liegt. Die Ursache ist mir bislang unklar.

Das zusammenfassen der Payload ist nahezu fertig, ich will es aber noch testen bevor ich es veröffentliche. Die Detektion von fehlenden Paketen funktioniert, der request für den retransmit fehlt noch, dürfte aber nicht schwierig sein.

um auf die ursprüngliche Frage zurückzukommen: das kann gut sein, ich bin selbst nicht im Besitz dieser WR, ich habe nur einen HM1200. Ich schaue mir die Definitionen nochmal an, es macht ja keinen Sinn doppelten Code / Definitionen zu pflegen.

[lumapu]

Oder man kann vorhersehen wie viele Pakete kommen müssen, da wir die Daten ja selbst anfordern und das Protokoll schon so weit verstehen.
Die ESP Version verwirft die Pakete ohne letztes Paket auf jeden Fall.

@homeautomation2022 ist in der neuesten Version berücksichtigt.

[Sprinterfreak]

@stefan123t

Poll inverter 114172220143
2022-05-21 17:02:19.698326 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 88 fe fb 00 00 00 05 00 00 00 00 2d 84 c7
2022-05-21 17:02:19.757089 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 00 01 01 40 00 72 01 6b 01 59 00 51 01 18 00 01 dd
2022-05-21 17:02:19.792870 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 01 3d 00 00 f8 54 06 80 06 66 08 e6 13 8e 02 66 f6
Error while retrieving data: Missing packet: Last packet 2
2022-05-21 17:02:20.298197 Transmit 11 | 15 72 22 01 43 78 56 34 12 83 8c
2022-05-21 17:02:20.336411 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 00 00 1b 03 e8 01 31 00 07 7d a2 0e
2022-05-21 17:02:20.840023 Payload: 00 01 01 40 00 72 01 6b 01 59 00 51 01 18 00 01 01 3d 00 00 f8 54 06 80 06 66 08 e6 13 8e 02 66 00 00 00 1b 03 e8 01 31 00 07 7d a2
2022-05-21 17:02:20.840023 Decoded: 30.5 phase0=voltage:227.8, current:2.7, power:61.4, frequency:50.06 string0=voltage:32.0, current:1.14, power:36.3, total:65.853, daily:1664 string1=voltage:34.5, current:0.81, power:28.0, total:63.572, daily:1638

o.O

[Sprinterfreak]

Ich fertige keine Empfangsstatistik an, welches Fragment ich tendenziell seltener bekomme.
Was ich bei mir so sehe kommt es immer mal wieder vor, dass irgendein Fragment fehlt, ich sehe da aber kein Muster.
Das Fragmente verloren gehen, ist Teil des physikalischen Layers. Es funkt halt viel dazwischen.

Re-Transmitts fixen das allermeiste, selten ist mal ein vollständig neuer Request nötig. Ich hab in den letzten Tagen keinen wirklichen Verlust der Payload innerhalb eines Interval (5s) beobachtet.

Allerdings ist mein NRF auch nicht weit vom Wechselrichter weg und die Gegend hier funktechnisch auch nicht massiv überlastet. Das beeinflusst natürlich die Stabilität der Kommunikation wesentlich.

Die 0x84: 100% sind merkwürdig. Bei mir geht hin und wieder auch mal das letzte Paket flöten. dann bleibt nur eine komplett neue Anfrage. Ist das ein Erhebungsfehler oder Glück?

[stefan123t]

Hier nochmal die Liste aus dem Excel bzw. zuerst die Kurzfassung von Andi:

Seriennummer	MPPT / Eingänge	Modellnummer
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

Seriennummern (Details) - Click to expand!

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

[lumapu]

@Sprinterfreak wie oben geschrieben habe ich die 0x84 als Referenz genommen. Mein Modul läuft Tag und Nacht, da in der Nacht keine Antworten kommen wären sonst die Quoten sehr schlecht.

[Sprinterfreak]

Stimmt in gewisser Weise, weil wenn das letzte Paket fehlt ist praktisch auch keins der vorherigen verwendbar. Dann muss man sofort einen neuen vollständigen Request absetzen. Im letzten Paket ist die CRC und die Information aus wie vielen Fragmenten die Übertragung bestand. Ohne die Informationen kann man keine Daten verarbeiten. Soweit ich weiß, kann man das letzt Paket auch nicht zum re-transmit anfordern. Du kannst ja nicht wissen was es war. Kann 0x81-0xff gewesen sein. Kannste nur raten.

bzw. müsste ich mal ausprobieren, ob man das mit 0x80 neu anfordern kann.

[Sprinterfreak]

Man kann es schätzen, aber nicht wissen. Sonst gäbe es die information im Datenstrom nicht. Spätestens bei 0x11 kann man es auch nicht mal mehr schätzen, weil je nach Log-Länge vollständig variabel. Ohnehin sind die Daten nur valide, wenn alle Fragmente des Datensatzes da sind. Sonst fällt das eh durch den crc check. Moment, welche crc, wenn das letzte Fragment fehlt ^^

[lumapu]

@Sprinterfreak ok, ich habe gerade Mal mit der gesamt Payload nachgezogen, aber es gibt schon ein neues Topic zum nachziehen .. meine Aussage stimmt also nur für das Zeit setzen Kommando.
Ist ja auch egal, ich denke wir sind hier gleicher Meinung: -> kein letztes Paket -> kein CRC -> komplett neu anfordern / komplett verwerfen

[Sprinterfreak]

Jo, gerade ausprobiert. Das letzte Paket kann man nicht anfordern.
Probiert mit
0x80 (Sequenz ohne Zähler)
0x83 (Sequenz mit geratenem Zähler bei HM600)

Beides initiiert einen komplett neuen Request mit Länge 1 und scheinbar eine Fehlermedlung als Payload.

[stefan123t]

@Sprinterfreak und wenn Du einfach Paket 0x03 nochmal anforderst ? Ob es tatsächlich das letzte war weißt man ja nie vor der Antwort.
Also 0x80 0x03 etc. Ich meine so einen Eintrag auch in den DTU Logs von martin (Gast) gesehen zu haben … muss mal nachsehen.