search

lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
953 stars 224 forks source link

Unterstützung für HM-1500 mit firmware 01.00.18 #247

Closed FFW-Scripter closed 2 years ago

FFW-Scripter commented 2 years ago

Wir haben eine neue Charge HM-1500 bekommen. Diese lassen sich mit der aktuellen Master-Version nicht auslesen:

18:08:09.662 -> I: Zaun 3/ch0/FWVersion: 10018.000 18:08:09.662 -> I: Zaun 3/ch0/FWBuildYear: 2021.000 18:08:09.662 -> I: Zaun 3/ch0/FWBuildMonthDay: 1224.000 18:08:09.662 -> I: Zaun 3/ch0/HWPartId: 100.000 18:08:09.662 -> I: 18:08:09.662 -> I: enqueued cmd failed/timeout 18:08:09.662 -> I: Inverter #0 I: no Payload received! (retransmits: 0) 18:08:09.662 -> I: Requesting Inverter SN 1161xxxxx80 18:08:09.662 -> I: enqueuedCmd: 11 18:08:10.641 -> I: enqueued cmd failed/timeout 18:08:10.641 -> I: Inverter #0 I: no Payload received! (retransmits: 0) 18:08:10.641 -> I: Requesting Inverter SN 1161xxxxx80 18:08:10.689 -> I: enqueuedCmd: 11 18:08:11.665 -> I: enqueued cmd failed/timeout 18:08:11.665 -> I: Inverter #0 I: no Payload received! (retransmits: 0) 18:08:11.665 -> I: Requesting Inverter SN 1161xxxxx80 18:08:11.665 -> I: enqueuedCmd: 11 18:08:12.634 -> I: enqueued cmd failed/timeout 18:08:12.634 -> I: Inverter #0 I: no Payload received! (retransmits: 0) 18:08:12.634 -> I: Requesting Inverter SN 1161xxxxx80 18:08:12.681 -> I: enqueuedCmd: 11

Laut Typenschild ist folgende Firmware auf den HM-1500:

Hardwarevers. H00.04.10 Softwarevers V01.00.18

Mit der originalen DTU lässt sich der Inverter jedoch korrekt auslesen, weshalb ich einen Defekt ausschließen kann. Falls noch weitere Informationen benötigt werden, kann ich versuchen diese zu liefern.

Danke schon einmal an dieses coole Projekt :+1:

aschiffler commented 2 years ago

Wie lauten die ersten 4 Zahlen der Seriennummer?

EDIT: Sehe sie ja oben im log.

Verbindung scheint ja zu klappen, da ja die Firmware auch ausgelesen werden kann. Könnte tatsächlich sein, dass bei der Abfrage der "normalen" Daten andere Parameter erwartet werden. Z.b. Passwort o.ä.

Richtig aufschlüsseln kann man das nur wenn man den Datenverkehr zwischen DTU und HM1500 mithört wenn es funktioniert.

stefan123t commented 2 years ago

Wir hatten doch auch das Master AdminPasswd aus dem DTU Pro Source Code: 10, 16, 50, 82 bzw 0A, 10, 32, 52 als Hex. Damit sollte man den Inverter Unlocken können. Ansonsten muss man das aktuelle Password bei jeder Anfrage mitschicken, das ist mW noch nicht implementiert.

FFW-Scripter commented 2 years ago

Wenn Ihr Unterstützung beim testen der commits benötigt, lasst es mich Wissen 🙂

stefan123t commented 2 years ago

Eventuell auch mal probieren ob es auf 1MBps statt mit 250kBps funktioniert ?

FFW-Scripter commented 2 years ago

@stefan123t Wenn du mir verrätst wie ich das mache, teste ich das gerne aus. Die IDE + Testaufbau habe ich da.

Edit: Ich denke die stelle in der hmRadio.c gefunden zu haben:

mNrf24.setDataRate(RF24_1MBPS);

Allerdings ändert sich da leider nichts… Die Serielle Konsole meldet:

12:17:29.797 > I: Requesting Inverter SN 1161xxxx96

Nicht wundern das sich die Seriennummer geändert hat, das ist ein anderer Inverter aus der gleichen Charge.

stefan123t commented 2 years ago

Okay danke, war nur eine Vermutung. Dann müsstest Du das mit dem Lock Password ausprobieren.

Das gehört an die Stelle an der 0x00000000 in der normalen Status Abfrage steht. Das sollte in Byte mTxBuf[20]..[23] des sendTimePacket gut aufgehoben sein.

// DTU-Pro SourceCode: AdminPasswd = 0x0A 10 32 52 
// Reset des bestehenden LockPasswords sollte mit AntitheftParaSet möglich sein
// LockOldPassword 0xFFFFFFFF und LockNewPassword 0x00000000 
mTxBuf[20] = 0x00; // e.g. 0x12
mTxBuf[21] = 0x00; // 0x34
mTxBuf[22] = 0x00; // 0x56
mTxBuf[23] = 0x00; // 0x78

Die werden bisher nicht gesetzt, also zwischen 200 und 201 einfügen.

https://github.com/grindylow/ahoy/blob/5402e9b0a2cf1c80012dcf62d89179693abc15b5/tools/esp8266/hmRadio.h#L188-L207

Die Parameter kann man irgendwann über die bisher nicht implementierten setParamPacket setzen: https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-parameter-setzen-paraset_all-0x52-kommandos-gibt-es

typedef enum
{
    SysParaSet = 0,
    EleEnergySet = 1,
    TempSampleCalibration = 2,
    PortEleParaCalibration = 3,
    AntitheftParaSet = 4,
} ParaSetType;
FFW-Scripter commented 2 years ago

Hmm, also irgendwie wird es nicht besser.

Ich habe mittlerweile den dritten Inverter am Start. Mit dem aktuell main Zweig und der vorgeschlagenen Änderung in hmRadio.c:201 klappt es auch nicht.

Ich muss dazu sagen, das mit oder ohne diese Änderung mittlerweile nicht mal mehr die Firmware erkannt wird.

@stefan123t wo müsste denn noch das typedef hin?

Aktuell wird auch nur folgendes in der Oberfläche angezeigt:

Inverter #0: TestInverter (v0) is not available and is not producing

In der Serialkonsole kommt auch nur:

15:32:21.319 > I: Requesting Inverter SN 1161xxx62 15:32:22.318 > I: Requesting Inverter SN 1161xxx62 15:32:23.318 > I: Requesting Inverter SN 1161xxx62 15:32:24.318 > I: Requesting Inverter SN 1161xxx62 15:32:25.318 > I: Requesting Inverter SN 1161xxx62

bluespiano commented 2 years ago

laut Ahoy habe ich die v10018 (auch HM-1500) … wird schon immer und auch aktuell unterstützt.

FFW-Scripter commented 2 years ago

Jetzt bin ich vollkommen verwirrt.

Wenn ich den Release Stand v0.5.17 Nutze wird der Inverter ausgelesen. Nach dem OTA Update mit der esp3266*.bin klappts…

Mache ich einen Build mit PlatformIO aus dem main Zweig geht nichts.

Laut ahoy kommt nun die Firmware v10016 aus diesem genutzen Inverter mit der 62 hinten dran...

Inverter #0: TestInverter (v10016) is available and is producing

Der Inverter wird nun auch korrekt ausgelesen… Dann würde ich das noch einmal mit dem anderen Inverter 1161xxxxx80 probieren welcher zum Anfang Probleme gemacht hatte…

stefan123t commented 2 years ago

Das typedef kommt aus dem DTU Pro Source Code und dient nur der Dokumentation / Verdeutlichung welche Parameter man setzen kann.

FFW-Scripter commented 2 years ago

So, ich habe mir mal den esp und eine Powerbank geschnappt und bin mal durch den Hof gelaufen um eventuelle Verbindungsprobleme auszuschließen.

Kurzum der HM1500 (TestInverter) wird korrekt ausgelesen. Der HM1500 (Zaun 3) nicht. Die Firmware kommt, allerdings keine Daten…

Ich habe dazu kurz einen Screenshot gemacht: https://bilderupload.org/bild/cbef64357-photo-2022-09-07-17-25-22

Mit dem Main Build komme ich leider aber auch nicht weiter, da geht anscheinend gar nix… 😐

Sorentodriver commented 2 years ago

Laut Ahoy habe ich die v10018 (auch HM-1500) wird aktuell unterstützt. SN.1161......77

bluespiano commented 2 years ago

bei mir stellt es sich so dar, dass direkt nach Update auf .17 beide Inverter produziert haben, paar sekunden später bekommen sie ja dann anscheinen das Limit (in meinem Fall "no limit") gesetzt und verlieren daraufhin wieder die Verbindung (not available and not producing) dieser Prozess dauert nun wesentlich länger als mit .15 oder .16 und ein Wechselrichter, der produziert, wird auch noch ein zweites mal autom. getrennt, bis er dann wieder produziert - insgesamt nach dem reboot hat es ca 5-6 Minuten gedauert, bis hier alles ok war - vorher 2-3 Minuten. Vielleicht hilft meine Darstellung.

FFW-Scripter commented 2 years ago

Nach ca. 8 Minuten (v0.5.17):

Receive success: 121 Receive fail: 347 Frames received: 1491 Send Cnt: 470

Inverter #0: TestInverter (v10016) is available and is producing Inverter #1: Zaun 3 (v10018) is not available and is not producing -> last successful transmission: 2022-09-07 18:14:25 Inverter #2: 1161xxxxxx96 (v10012) is available and is producing MQTT: not connected

aschiffler commented 2 years ago

Hi,

etwas durcheinander wenn ich mir das so durchlesen. Schwierig hier tiefer/weiter zu kommen. Ich habe verstanden:

Sorentodriver commented 2 years ago

Statistics:

Receive success: 1467 Receive fail: 2712 Frames received: 11669 Send Cnt: 19568

Inverter 'Hoymiles 1500 (FW-Version: 10018)' is available and is producing Inverter 1 not (correctly) configured Inverter 2 not (correctly) configured MQTT: not connected

buffcode commented 2 years ago

Ich konnte mangels Kabellänge den ESP noch nicht näher an meinen WR bewegen, aber aktuell bekomme ich mit der 0.5.17 ebenfalls keine Verbindung zum HM-1500 (1161xxxxxx72). Serial wie auch UI sagen (v0) is not available and is not producing. In der Serial kommt ansonsten nichts darüber hinaus.

Luftstrecke ist maximal ein Meter und nur die Fertigbetondecke der Garage dazwischen, wobei es einen Luftschacht gibt wo auch die Kabel Richtung WR durchlaufen. Dort hab ich die Antenne ebenfalls bereits reingehalten, ohne Veränderung. Ich probiere morgen nochmal die Antenne bis neben den WR durchzuführen.

Wemos D1 mit folgendem Modul (NRF24L01+): https://www.ebay.de/itm/255283312809

Test durchgeführt tagsüber während der WR auch produzierte. Lief auch schon mal mehrere Stunden tagsüber, ohne das sich ein erfolgreiches Paket ergeben hätte.

Edit: Verkabelungsfehler

DanielR92 commented 2 years ago

Gibt es WR die bei dir mit dieser Version laufen? Ich frage um evtl. falsche Verkabelung oder falsches Modul auszuschließen...

buffcode commented 2 years ago

Gibt es WR die bei dir mit dieser Version laufen? Ich frage um evtl. falsche Verkabelung oder falsches Modul auszuschließen...

TLDR: Verkabelung war scheinbar falsch oder Kabel defekt.

Konnte den HM-600 meines Nachbarn auch nicht auslesen, habe daher alle Kabel getauscht und neu verbunden, seit dem klappt es auch mit dem HM-1500, ebenfalls Firmware 10018 von 2021.

FFW-Scripter commented 2 years ago

@buffcode Meinst du damit die Kabel vom Wemos/ESP zum NRF24? Wenn ja, würde ich das auch noch einmal probieren, woebei wir mit zwei ESPs und zwei unterschiedlichen NRF Modulen gearbeitet hatten…

buffcode commented 2 years ago

@FFW-Scripter Genau. Ich hatte zuerst beides per Breadboard miteinander verbunden und nun nochmal direkt und neu miteinander verkabelt um Kabel und Breadboard auszuschließen.

stefan123t commented 2 years ago

@FFW-Scripter da Du der Thread Opener warst hier noch eine kurze Zusammenfassung:

  1. Zwei HM-1500 Inverter werden von einem AhoyDTU nicht immer gefunden (Receive Failure bzw not available and is not producing)

  2. zu einem späteren Zeitpunkt zeigt der ESP Werte für beide bzw alle drei WR an aber erreicht weder die WR noch das MQTT Netzwerk sicher/immer.

Receive success: 121
Receive fail: 347
Frames received: 1491
Send Cnt: 470
Inverter #0: TestInverter (v10016) is available and is producing
Inverter #1: Zaun 3 (v10018) is not available and is not producing
-> last successful transmission: 2022-09-07 18:14:25
Inverter #2: 1161xxxxxx96 (v10012) is available and is producing
MQTT: not connected

Eventuell ist das Power Setting für den NRF24 zu hoch eingestellt, der bekommt manchmal nicht genug Strom.

  1. Du hast zwei ESPs im Einsatz. Diese können sich evtl gegenseitig stören weil sie die selbe DTU ID verwenden und so sich gegenseitig aus dem Tritt bringen.

Da die Kommunikation mit allen drei WR stellenweise geklappt hat sehen wir aktuell kein Problem auf Seite der Software. Kabel sauber verlöten und es sollte funktionieren wenn der Empfang gegeben ist.

FFW-Scripter commented 2 years ago

Hallo, ich hoffe ich darf zu dem Thema noch einmal etwas beitragen :-)

Folgende Schritte habe ich nach dem letzten Post von stefan123t noch gemacht:

photo_2022-10-12_11-55-10

Ich habe auch ein Log aus der Serialkonsole mit angehangen. Die Firmware (v10018) wird wie bisher auch korrekt gelesen.

11:46:40 I: procPyld: cmd: 5 11:46:40 I: procPyld: txid: 0x95 11:46:40 I: Payload (14): 00 01 03 e8 00 00 03 e8 ff ff ff ff 01 68 11:46:40 I: resetPayload: id: 0

Anschließend geht aber der RX no answer und RX fail count hoch:

RX success: 2 RX fail: 101 RX no anwser: 476 Frames received: 488 TX Cnt: 579

ahoy_log_1.txt

Da die Firmware ja korrekt gefunden wird, schließe ich ein Verkabelungsproblem aus, die Stromversorgung sollte auch passen. Eventuell wird jemand aus den Logs schlauer, aber mehr wie no Payload received! sehe ich da aktuell nicht.

Danke für eure Mühe und Geduld :+1:

Edit sagt:

Nach ca. einer halben Stunde Uptime:

RX success: 3 RX fail: 381 RX no anwser: 1772 Frames received: 1932 TX Cnt: 2156 Inverter #0: Testinverter (v10018) is not available and is not producing -> last successful transmission: 12.10.2022, 12:11:35 INFO: MQTT is connected

stefan123t commented 2 years ago

@aschiffler hier ist irgendwas seltsam (siehe ahoy_log1.txt): Es werden nacheinander die Pakete 01, 02, 02 (doppelt auf Ch23) und das letzte Paket 84 empfangen. Ich hätte erwartet dass der Code an der Stelle Paket 03 per Retransmit mit 83 nochmals anfordert. Aber er bricht sofort mit enqueued cmd failed/timeout 

11:46:24 I: TX 27B Ch40 | 15 81 84 95 80 84 85 80 15>80<0b 00 63 46 a9 10 00 00 00 00 00 00 00 00 6a 75 99 
11:46:34 I: RX 27B Ch03 | 95 81 84 95 80 81 84 95 80>01<00 01 01 a9 01 84 00 fc 06 72 04 2e 00 00 df b3 76 
11:46:34 I: RX 27B Ch03 | 95 81 84 95 80 81 84 95 80>02<00 00 b9 f6 00 f8 00 e7 01 88 00 90 03 c6 02 35 2c 
11:46:34 I: RX 27B Ch23 | 95 81 84 95 80 81 84 95 80>02<00 00 b9 f6 00 f8 00 e7 01 88 00 90 03 c6 02 35 2c 
11:46:34 I: RX 27B Ch03 | 95 81 84 95 80 81 84 95 80>84<13 89 1a 38 00 e8 01 17 03 e7 01 40 00 03 97 75 13 
11:46:35 I: enqueued cmd failed/timeout

PS: Ich habe die Paket IDs mit >ID< markiert und die Ch3 Ausgabe mit vorangestellter Null, also Ch03 optisch etwas aufgeräumt.

PPS: 80 im DevInfo Command ist glaube ich eine ältere Version, sollte das nicht 81 in der Zwischenzeit sein ?

PPPS: @FFW-Scripter warum schickt der WR (81 84 95 80) seine Pakete an die DTU mit der selben Serial ID 81 84 95 80 ? Beim Senden wird die DTU Serial ID als 84 85 80 15 angegeben, oder war es andersherum ? Ich glaube da hast Du ein wenig zu viel Information Hiding betrieben und wir können mit den Paketen so herzlich wenig anfangen... außer irgendwelche Mutmaßungen anstellen.

FFW-Scripter commented 2 years ago

Mittlerweilen haben wir noch eine originale DTU hier stehen, diese versuchen wir gerade via Modbus auszulesen - was so mittelmäßig klappt :-/

Kann es sein das diese dazwischen funkt?