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
:
Bearbeitet durch User
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...
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
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?
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?
1 | setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms |
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
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)
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:
1 | #include <ESP8266HTTPClient.h> |
2 | |
3 | #define SERVERNAME "http://pvoutput.org/service/r2/addstatus.jsp"
|
4 | #define APIKEY "40digit-hex-API-Key" // pvoutput.org API-Key
|
5 | #define SYSTEMID 12345 // pvoutput.org systemID
|
... ... ...
1 | void app::loop(void) { |
... ... ...
1 | if (mSerialValues) { |
2 | if (++mSerialTicker >= mSerialInterval) { |
3 | mSerialTicker = 0; |
4 | uint16_t energy = 0; |
5 | for (uint8_t id = 0; id < mSys->getNumInverters(); id++) { |
6 | Inverter<> *iv = mSys->getInverterByPos(id); |
7 | if (NULL != iv) { |
8 | uint8_t modNum, pos; |
9 | switch (iv->type) { |
10 | default: modNum = 1; break; |
11 | case INV_TYPE_HM600: |
12 | case INV_TYPE_HM800: modNum = 2; break; |
13 | case INV_TYPE_HM1200: modNum = 4; break; |
14 | }
|
15 | |
16 | for (uint8_t ch = 1; ch <= modNum; ch ++) { |
17 | energy += iv->getValue(iv->getPosByChFld(ch, FLD_YD)); |
18 | }
|
19 | }
|
20 | }
|
21 | |
22 | char serverPath[255] = {0}; |
23 | 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); |
24 | |
25 | Serial.println(serverPath); |
26 | |
27 | HTTPClient http; |
28 | WiFiClient client; |
29 | |
30 | http.begin(client, serverPath); |
31 | |
32 | // Send HTTP GET request
|
33 | int httpResponseCode = http.GET(); |
34 | |
35 | if (httpResponseCode > 0) { |
36 | Serial.print("HTTP Response code: "); |
37 | Serial.println(httpResponseCode); |
38 | String payload = http.getString(); |
39 | Serial.println(payload); |
40 | }
|
41 | else { |
42 | Serial.print("Error code: "); |
43 | Serial.println(httpResponseCode); |
44 | }
|
45 | // Free resources
|
46 | http.end(); |
47 | |
48 | |
49 | |
50 | char topic[30], val[10]; |
51 | for (uint8_t id = 0; id < mSys->getNumInverters(); id++) { |
52 | Inverter<> *iv = mSys->getInverterByPos(id); |
53 | if (NULL != iv) { |
54 | for (uint8_t i = 0; i < iv->listLen; i++) { |
55 | if (0.0f != iv->getValue(i)) { |
56 | snprintf(topic, 30, "%s/ch%d/%s", iv->name, iv->assign[i].ch, iv->getFieldName(i)); |
57 | snprintf(val, 10, "%.3f %s", iv->getValue(i), iv->getUnit(i)); |
58 | DPRINTLN(String(topic) + ": " + String(val)); |
59 | }
|
60 | yield(); |
61 | }
|
62 | }
|
63 | }
|
64 | }
|
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?
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.
1 | - channel: [23,40] |
2 | mode: tx |
3 | ce_pin: n |
4 | - channel: [3,23,40,61] |
5 | mode: rx |
6 | 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? >
1 | > setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms |
2 | >
|
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
:
Bearbeitet durch User
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.
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 ?
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?
:
Bearbeitet durch User
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....
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.
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.
1 | 00 01 |
2 | 80 01 00 06 31 53 31 53 00 00 00 00 |
3 | 80 02 00 35 a7 fa a7 fa 00 00 00 07 |
4 | b0 02 00 36 00 32 00 32 ff ff ff fb |
5 | b0 02 00 37 00 39 00 39 00 00 00 05 |
6 | b0 02 00 38 05 c2 05 c2 ff ff ff fa |
7 | b0 02 00 39 05 c6 05 c6 00 00 00 06 |
8 | b0 02 00 3a 18 6c 18 6c ff ff ff fb |
9 | b0 02 00 3b 18 6f 18 6f 00 00 00 05 |
10 | b0 02 00 3c 23 5a 23 5a ff ff ff fb |
11 | b0 02 00 3d 23 5e 23 5e 00 00 00 05 |
12 | b0 02 00 3e 25 de 25 de ff ff ff fb |
13 | b0 02 00 3f 25 e3 25 e3 00 00 00 05 |
14 | b0 02 00 40 26 c9 26 c9 ff ff ff fa |
15 | b0 02 00 41 26 ce 26 ce 00 00 00 06 |
16 | b0 02 00 42 27 ea 27 ea ff ff ff fb |
17 | 39 f2 <- modbus crc |
Bei 0x12 habe ich einmal eine ähnliche Antwort bekommen und jetzt kommt bei 0x12 nur noch
1 | 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 |
2 | 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 |
3 | 2022-05-10 18:37:21.522190 Payload: 00 01 70 c0 |
4 | payload has valid modbus crc |
Gruß, Jan
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.
:
Bearbeitet durch User
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).
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!
:
Bearbeitet durch User
Neue Erkenntnisse: Die vermeintliche Liste in 80 11 wird länger, wenn man den Stecker zieht. Ereignisspeicher seit Einspeisebegin?
1 | Poll inverter 114172220143 |
2 | 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 |
3 | 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 |
4 | 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 |
5 | 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 |
6 | 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 |
7 | 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 |
8 | 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 |
9 | 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 |
10 | 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 |
11 | 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 |
12 | 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 |
13 | 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 |
14 | payload has valid modbus crc |
15 | 80 01 00 06 32 88 32 88 00 00 00 00: |
16 | BBLHl : (128, 1, 406152, 12936, 0) |
17 | BBBBBHHHB: (128, 1, 0, 6, 50, 34866, 34816, 0, 0) |
18 | 12B : (128, 1, 0, 6, 50, 136, 50, 136, 0, 0, 0, 0) |
19 | |
20 | 80 0d 00 07 68 3a 68 3a 01 ce 13 54: |
21 | BBLHl : (128, 13, 485434, 26682, 30282580) |
22 | BBBBBHHHB: (128, 13, 0, 7, 104, 14952, 14849, 52755, 84) |
23 | 12B : (128, 13, 0, 7, 104, 58, 104, 58, 1, 206, 19, 84) |
24 | |
25 | 40 94 00 09 68 3a 68 90 09 3d 07 53: <-- Netztrennung |
26 | BBLHl : (64, 148, 616506, 26768, 154994515) |
27 | BBBBBHHHB: (64, 148, 0, 9, 104, 14952, 36873, 15623, 83) |
28 | 12B : (64, 148, 0, 9, 104, 58, 104, 144, 9, 61, 7, 83) |
29 | |
30 | 80 0d 00 0a 68 c8 68 c8 02 60 12 45: |
31 | BBLHl : (128, 13, 682184, 26824, 39850565) |
32 | BBBBBHHHB: (128, 13, 0, 10, 104, 51304, 51202, 24594, 69) |
33 | 12B : (128, 13, 0, 10, 104, 200, 104, 200, 2, 96, 18, 69) |
34 | |
35 | 40 94 00 0c 68 c8 69 0f 09 47 08 58: <-- Netztrennung |
36 | BBLHl : (64, 148, 813256, 26895, 155650136) |
37 | BBBBBHHHB: (64, 148, 0, 12, 104, 51305, 3849, 18184, 88) |
38 | 12B : (64, 148, 0, 12, 104, 200, 105, 15, 9, 71, 8, 88) |
39 | |
40 | 80 02 00 0d 6a 25 6a 25 ff ff ff fb: |
41 | BBLHl : (128, 2, 879141, 27173, -5) |
42 | BBBBBHHHB: (128, 2, 0, 13, 106, 9578, 9727, 65535, 251) |
43 | 12B : (128, 2, 0, 13, 106, 37, 106, 37, 255, 255, 255, 251) |
44 | |
45 | 80 02 00 0e 6a 25 6a 25 00 00 00 05: |
46 | BBLHl : (128, 2, 944677, 27173, 5) |
47 | BBBBBHHHB: (128, 2, 0, 14, 106, 9578, 9472, 0, 5) |
48 | 12B : (128, 2, 0, 14, 106, 37, 106, 37, 0, 0, 0, 5) |
49 | |
50 | 80 02 00 0f 6b 29 6b 29 ff ff ff fb: |
51 | BBLHl : (128, 2, 1010473, 27433, -5) |
52 | BBBBBHHHB: (128, 2, 0, 15, 107, 10603, 10751, 65535, 251) |
53 | 12B : (128, 2, 0, 15, 107, 41, 107, 41, 255, 255, 255, 251) |
54 | |
55 | 80 02 00 10 6b 2c 6b 2c 00 00 00 05: |
56 | BBLHl : (128, 2, 1076012, 27436, 5) |
57 | BBBBBHHHB: (128, 2, 0, 16, 107, 11371, 11264, 0, 5) |
58 | 12B : (128, 2, 0, 16, 107, 44, 107, 44, 0, 0, 0, 5) |
59 | |
60 | 80 02 00 11 6b 66 6b 66 ff ff ff fa: |
61 | BBLHl : (128, 2, 1141606, 27494, -6) |
62 | BBBBBHHHB: (128, 2, 0, 17, 107, 26219, 26367, 65535, 250) |
63 | 12B : (128, 2, 0, 17, 107, 102, 107, 102, 255, 255, 255, 250) |
64 | |
65 | 80 02 00 12 6b 6b 6b 6b 00 00 00 05: |
66 | BBLHl : (128, 2, 1207147, 27499, 5) |
67 | BBBBBHHHB: (128, 2, 0, 18, 107, 27499, 27392, 0, 5) |
68 | 12B : (128, 2, 0, 18, 107, 107, 107, 107, 0, 0, 0, 5) |
69 | |
70 | 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 |
71 | 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 |
72 | 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 |
73 | 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 |
74 | 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 |
75 | 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
:
Bearbeitet durch User
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)
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
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?
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.
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
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…
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 ;-)
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
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
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
:
Bearbeitet durch User
Konnte Jans Erkenntnis bzgl. 0x80 0x11 nachvollziehen. mit seinem letzten Source bekommt man folgendes dekodiert:
1 | 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 |
2 | payload has valid modbus crc |
3 | 80 01 00 06 30 62 30 62 00 00 00 00: |
4 | uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start |
5 | BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0) |
6 | 00 d4 00 07 30 6a 00 00 00 00 00 00: |
7 | uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input |
8 | BBHHHHH: (0, 212, 7, 12394, 0, 0, 0) |
9 | b0 02 00 48 4c f7 4c f7 00 00 00 05: |
10 | uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power |
11 | BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5) |
12 | b0 02 00 49 55 da 55 da ff ff ff fb: |
13 | uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power |
14 | BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531) |
15 | b0 02 00 4a 55 ed 55 ed 00 00 00 05: |
16 | uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power |
17 | BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5) |
18 | b0 02 00 4b 56 72 56 72 ff ff ff fb: |
19 | uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power |
20 | BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531) |
21 | b0 02 00 4c 56 72 56 72 00 00 00 06: |
22 | uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power |
23 | BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6) |
24 | b0 02 00 4d 56 79 56 79 ff ff ff fb: |
25 | uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power |
26 | BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531) |
27 | b0 02 00 4e 56 82 56 82 00 00 00 05: |
28 | uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power |
29 | BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5) |
30 | b0 02 00 4f 56 e7 56 e7 ff ff ff fb: |
31 | uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power |
32 | BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531) |
33 | b0 02 00 50 56 f3 56 f3 00 00 00 05: |
34 | uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power |
35 | BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5) |
36 | b0 02 00 51 57 1d 57 1d ff ff ff fb: |
37 | uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power |
38 | BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531) |
39 | b0 02 00 52 57 23 57 23 00 00 00 05: |
40 | uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power |
41 | BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5) |
42 | b0 02 00 53 57 4f 57 4f ff ff ff fb: |
43 | uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power |
44 | BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531) |
45 | b0 02 00 54 57 51 57 51 00 00 00 05: |
46 | uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power |
47 | BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5) |
Bei 0x80 0x12 schaut kommt
1 | 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 |
2 | 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 |
3 | 2022-05-11 19:09:11.454623 Payload: 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb |
4 | payload has valid modbus crc |
5 | 00 d4 00 07 30 6a 00 00 00 00 00 00: |
6 | uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input |
7 | 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.
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 ?
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.
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.
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
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 ?
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
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. 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
1 | 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 |
2 | 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 |
3 | 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 |
4 | 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 |
5 | 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 |
6 | 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 |
7 | 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 |
8 | 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 |
9 | 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 |
10 | payload has valid modbus crc |
11 | 80 01 00 06 31 e3 31 e3 00 00 00 00: |
12 | uptime=3:32:51 a_count=6 opcode=128 a_code=1 a_text=Inverter start |
13 | BBHHHHH: (128, 1, 6, 12771, 12771, 0, 0) |
14 | 80 02 00 07 3b 9c 3b 9c ff ff ff fa: |
15 | uptime=4:14:20 a_count=7 opcode=128 a_code=2 a_text=Producing power |
16 | BBHHHHH: (128, 2, 7, 15260, 15260, 65535, 65530) |
17 | 80 02 00 08 3b 9c 3b 9c 00 00 00 06: |
18 | uptime=4:14:20 a_count=8 opcode=128 a_code=2 a_text=Producing power |
19 | BBHHHHH: (128, 2, 8, 15260, 15260, 0, 6) |
20 | 80 02 00 09 60 b1 60 b1 ff ff ff fb: |
21 | uptime=6:52:33 a_count=9 opcode=128 a_code=2 a_text=Producing power |
22 | BBHHHHH: (128, 2, 9, 24753, 24753, 65535, 65531) |
23 | 80 02 00 0a 60 c2 60 c2 00 00 00 05: |
24 | uptime=6:52:50 a_count=10 opcode=128 a_code=2 a_text=Producing power |
25 | BBHHHHH: (128, 2, 10, 24770, 24770, 0, 5) |
26 | 80 02 00 0b 60 d9 60 d9 ff ff ff fb: |
27 | uptime=6:53:13 a_count=11 opcode=128 a_code=2 a_text=Producing power |
28 | BBHHHHH: (128, 2, 11, 24793, 24793, 65535, 65531) |
29 | 80 02 00 0c 60 dd 60 dd 00 00 00 05: |
30 | uptime=6:53:17 a_count=12 opcode=128 a_code=2 a_text=Producing power |
31 | BBHHHHH: (128, 2, 12, 24797, 24797, 0, 5) |
32 | 80 02 00 0d 61 79 61 79 ff ff ff fb: |
33 | uptime=6:55:53 a_count=13 opcode=128 a_code=2 a_text=Producing power |
34 | BBHHHHH: (128, 2, 13, 24953, 24953, 65535, 65531) |
35 | 80 02 00 0e 61 81 61 81 00 00 00 05: |
36 | uptime=6:56:01 a_count=14 opcode=128 a_code=2 a_text=Producing power |
37 | BBHHHHH: (128, 2, 14, 24961, 24961, 0, 5) |
38 | 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 |
39 | 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 |
40 | 2022-05-12 08:56:33.204835 Payload: 00 01 70 c0 |
41 | payload has valid modbus crc |
42 | Poll inverter 114172220143 |
43 | 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 |
44 | 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 |
45 | 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 |
46 | 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 |
47 | 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 |
48 | 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
1 | ~ # python3 |
2 | Python 3.9.2 (default, Mar 12 2021, 04:06:34) |
3 | [GCC 10.2.1 20210110] on linux |
4 | Type "help", "copyright", "credits" or "license" for more information. |
5 | >>> import struct |
6 | >>> 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]) |
7 | (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
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 ;-)
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?
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
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
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
1 | opcode, a_code, a_count, uptime, u, u, u = struct.unpack('>BBHHHHH', chunk) |
2 | |
3 | B B H H H H H |
4 | 00 d4 00 07 30 6a 00 00 00 00 00 00 |
5 | | | | | |
6 | | | | \_ uptime seconds(?) |
7 | | | \_ a_count |
8 | | \__ a_code |
9 | \_ opcode |
Das schöne an python ist, geht auch interaktiv. Auf der Konsole am Beispiel von Thomas die Payload von "Port 4 no input"
1 | ~ # python3 |
2 | Python 3.9.2 (default, Mar 12 2021, 04:06:34) |
3 | [GCC 10.2.1 20210110] on linux |
4 | Type "help", "copyright", "credits" or "license" for more information. |
5 | >>> import struct |
6 | >>> struct.unpack('>BBHHHHH', bytes.fromhex('00 d4 00 07 30 6a 00 00 00 00 00 00')) |
7 | (0, 212, 7, 12394, 0, 0, 0) |
8 | >>> |
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
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 !
Noch schöner ist, man kann die Decoder auch so auf der Konsole ausprobieren Im Verzeichnis tools/rpi/ python3 ausführen:
1 | root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3 |
2 | Python 3.9.2 (default, Mar 12 2021, 04:06:34) |
3 | [GCC 10.2.1 20210110] on linux |
4 | Type "help", "copyright", "credits" or "license" for more information. |
5 | >>> import hoymiles |
6 | >>> 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')) |
7 | payload has valid modbus crc |
8 | 80 01 00 06 30 62 30 62 00 00 00 00: |
9 | uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start |
10 | BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0) |
11 | 00 d4 00 07 30 6a 00 00 00 00 00 00: |
12 | uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input |
13 | BBHHHHH: (0, 212, 7, 12394, 0, 0, 0) |
14 | b0 02 00 48 4c f7 4c f7 00 00 00 05: |
15 | uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power |
16 | BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5) |
17 | b0 02 00 49 55 da 55 da ff ff ff fb: |
18 | uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power |
19 | BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531) |
20 | b0 02 00 4a 55 ed 55 ed 00 00 00 05: |
21 | uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power |
22 | BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5) |
23 | b0 02 00 4b 56 72 56 72 ff ff ff fb: |
24 | uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power |
25 | BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531) |
26 | b0 02 00 4c 56 72 56 72 00 00 00 06: |
27 | uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power |
28 | BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6) |
29 | b0 02 00 4d 56 79 56 79 ff ff ff fb: |
30 | uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power |
31 | BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531) |
32 | b0 02 00 4e 56 82 56 82 00 00 00 05: |
33 | uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power |
34 | BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5) |
35 | b0 02 00 4f 56 e7 56 e7 ff ff ff fb: |
36 | uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power |
37 | BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531) |
38 | b0 02 00 50 56 f3 56 f3 00 00 00 05: |
39 | uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power |
40 | BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5) |
41 | b0 02 00 51 57 1d 57 1d ff ff ff fb: |
42 | uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power |
43 | BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531) |
44 | b0 02 00 52 57 23 57 23 00 00 00 05: |
45 | uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power |
46 | BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5) |
47 | b0 02 00 53 57 4f 57 4f ff ff ff fb: |
48 | uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power |
49 | BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531) |
50 | b0 02 00 54 57 51 57 51 00 00 00 05: |
51 | uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power |
52 | BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5) |
1 | import hoymiles # läd das Modul hoymiles |
2 | # hoymiles.decoders korrespondiert zu hoymiles/decoders/__init__.py |
3 | 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.
:
Bearbeitet durch User
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
1 | mMqttTicker = 0; |
statt
1 | 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
:
Bearbeitet durch User
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
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.
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.
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
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 ?
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? :)
:
Bearbeitet durch User
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...
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.
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ß
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.
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?
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.
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.
Meine Prototype mit ESP8266 im Gehäuse. Trotz der dichten Packung funktioniert die Kommunikation mit dem WR.
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.
:
Bearbeitet durch User
Daniel R. schrieb: > Die Frage, woher bekomme ich die SNr. habe ein 1500. Steht auf der glatten Seite / Rückseite auf 2 Aufklebern.
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
:
Bearbeitet durch User
“Danke, boa darauf muss man erstmal kommen.” Handbuch lesen sollte wohl möglich sein;-( Auch mit Schreib- und Leseschwäche…
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
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(); } } }
:
Bearbeitet durch User
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.
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
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
1 | +-----------+ +-----------+ |
2 | | ESP8266 |--colour--| nRF24L01+ | |
3 | | | | | |
4 | | GND |---black--|[GND] | |
5 | | +3.3V |----red---| VCC | |
6 | | D4 |---grey---| CE | |
7 | | D8 |--purple--| CSN | |
8 | | D5 |---blue---| SCK | |
9 | | D7 |---green--| MOSI | |
10 | | D6 |---brown--| MISO | |
11 | | D3 |--yellow--| IRQ | |
12 | +-----------+ +-----------+ |
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)
:
Bearbeitet durch User
Hallo Zusammen, ist das RF module von Kuman nRF24L01+PA+LNA ist dafür auch zu nutzen? Gruss david
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. :)
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
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
:
Bearbeitet durch User
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
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.
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
:
Bearbeitet durch User
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...
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
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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)?
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.
:
Bearbeitet durch User
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 ;)
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.
Gute Idee, dann könnte man ein FAQ einrichten und und und... =)
> 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 ?
1 | PDbusConfigMO pDbusConfigMO = (PDbusConfigMO) obj; |
2 | 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(); |
3 | |
4 | InvInfoAddrMO invInfoAddrMO = (InvInfoAddrMO) obj; |
5 | return (((getEn() == invInfoAddrMO.getEn()) && getFc() == invInfoAddrMO.getFc()) && getStartAddr() == invInfoAddrMO.getStartAddr()) && getLength() == invInfoAddrMO.getLength(); |
6 | |
7 | InvRealAddrMO invRealAddrMO = (InvRealAddrMO) obj; |
8 | return (((getEn() == invRealAddrMO.getEn()) && getFc() == invRealAddrMO.getFc()) && getStartAddr() == invRealAddrMO.getStartAddr()) && getLength() == invRealAddrMO.getLength(); |
9 | |
10 | PvStrAddrMO pvStrAddrMO = (PvStrAddrMO) obj; |
11 | return (getVAddr() == pvStrAddrMO.getVAddr()) && getIAddr() == pvStrAddrMO.getIAddr(); |
12 | |
13 | InvConfigMO invConfigMO = (InvConfigMO) obj; |
14 | 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(); |
15 | |
16 | 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(); |
17 | |
18 | 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(); |
19 | |
20 | LoggerConfigMO loggerConfigMO = (LoggerConfigMO) obj; |
21 | 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(); |
22 | |
23 | ConfigParaMO configParaMO = (ConfigParaMO) obj; |
24 | return ((getPdbusCfgList().equals(configParaMO.getPdbusCfgList())) && getInvCfgList().equals(configParaMO.getInvCfgList())) && getLogCfgList().equals(configParaMO.getLogCfgList()); |
25 | |
26 | WriteHRegResDTO writeHRegResDTO = (WriteHRegResDTO) obj; |
27 | 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()); |
28 | |
29 | WriteHRegReqDTO writeHRegReqDTO = (WriteHRegReqDTO) obj; |
30 | 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(); |
31 | |
32 | ReadHRegReqDTO readHRegReqDTO = (ReadHRegReqDTO) obj; |
33 | 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()); |
34 | |
35 | ReadHRegResDTO readHRegResDTO = (ReadHRegResDTO) obj; |
36 | return ((((getOffset() == readHRegResDTO.getOffset()) && getTime() == readHRegResDTO.getTime()) && getAction() == readHRegResDTO.getAction()) && (getGwSn() > readHRegResDTO.getGwSn() ? 1 : (getGwSn() == readHRegResDTO.getGwSn() ? 0 : -1)) == 0) && getLogSn() == readHRegResDTO.getLogSn(); |
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
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"
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.
:
Bearbeitet durch User
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/
Sehr cool, vielen dank! Dann kann man sich heute nach der Arbeit mal alles durch arbeiten und weiter schauen. :) Besten Dank Yoshi
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
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. =)
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
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.
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
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?
:
Bearbeitet durch User
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
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 ;-)
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. :)
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
ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze) behoben
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
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.
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.
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ß
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
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. =)
:
Bearbeitet durch User
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.
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?
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
:
Bearbeitet durch User
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.
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
Hatte das gleiche Problem, dann erstmal alle libraries geupdated. Nochmals kompiliert und upload. Danach funktioniert es wieder problemlos.
Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die Möglichkeit, die Daten per JSON String zu übermitteln ?
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.
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.
:
Bearbeitet durch User
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...
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)
@ 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.
vielleicht so ähnlich :-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
Herbert K. schrieb: > und noch eines aus dem MI-1200 Hallo Herbert, konntest du den MI1200 schon ansprechen?
Ziyat T. schrieb: > Hallo Herbert, konntest du den MI1200 schon ansprechen? Hallo Ziyat, ich habe selbst den MI1200 nicht. Ich habe HM350/400.
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
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
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
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?
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. :)
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
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.
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.
> Weil ein einzelnes Frame bzw. damit auch > automatisch, und das letzte Frame nicht retransmittet werden kann. Niemand kann diesen Satz verstehen.
Beitrag #7070975 wurde vom Autor gelöscht.
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
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
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.
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.
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.
Ich nehm (fast) alles zurück. Von wegen man kann das letzte Paket nicht retransmitten...
1 | Poll inverter 114172220143 |
2 | 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 |
3 | 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 |
4 | 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 |
5 | Error while retrieving data: Missing packet: Last packet 2 |
6 | 2022-05-21 18:08:58.788941 Transmit 11 | 15 72 22 01 43 78 56 34 12 83 8c |
7 | 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 |
8 | 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 |
9 | 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
:
Bearbeitet durch User
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.
Der Akkusativ wäre auch noch passend. Aber das lernt wohl niemand mehr in der Schule, traurig. 😪😪😪😪
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
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
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
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
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?
:
Bearbeitet durch User
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.
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.
@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 :-)
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.
Moin Lukas, Github Issue ist raus. Hoffe passt, wenn du mehr Infos brauchst einfach melden. :)
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.
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
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
:
Bearbeitet durch User
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.
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?
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.
:
Bearbeitet durch User
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 :-)
Alles klar, dann baue ich mir mal eine Version mit 4 WR. Kann dann ja berichten ob es klappt.
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
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.
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
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.
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
:
Bearbeitet durch User
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
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 :-)
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
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
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
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
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
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 :-(.
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
:
Bearbeitet durch User
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
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
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
:
Bearbeitet durch User
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:
1 | 7E09635003166350031600097F |
2 | 7E11635003166350031600117F |
3 | 7E09635003166350031600097F |
4 | 7E11635003166350031600117F |
5 | 7E09635003166350031600097F |
6 | 7E11635003166350031600117F |
7 | 7E11635003166350031600117F |
8 | 7E09635003166350031600097F |
9 | 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:
1 | 7E8963500316635003160157000E0961138601CB005900AE117F |
2 | 7E9163500316635003160157000E0962138601C1005300AE0A7F |
3 | 7E88635003166350031600030000000000008B7F |
4 | 7E8963500316635003160158000E0962138601CB005900AE1D7F |
5 | 7E9263500316635003160003000000000000917F |
6 | 7E9163500316635003160157000E0962138601C1005300AF0B7F |
7 | 7E8963500316635003160158000F0962138601CB005900AF1D7F |
8 | 7E9163500316635003160157000E0962138601C1005300AF0B7F |
9 | 7E88635003166350031600030000000000008B7F |
10 | 7E8963500316635003160158000F0962138601CB005900AE1C7F |
11 | 7E9263500316635003160003000000000000917F |
12 | 7E9163500316635003160158000F0962138601C1005300AE047F |
13 | 7E88635003166350031600030000000000008B7F |
14 | 7E8963500316635003160159000F0963138601EF005900AD3B7F |
15 | 7E9263500316635003160003000000000000917F |
16 | 7E9163500316635003160159000F0963138601E4005300AD227F |
17 | 7E88635003166350031600030000000000008B7F |
18 | 7E8963500316635003160159000F0963138601EF005900AD3B7F |
19 | 7E9263500316635003160003000000000000917F |
20 | 7E9163500316635003160159000F0963138701E4005300AE207F |
21 | 7E88635003166350031600030000000000008B7F |
22 | 7E896350031663500316015900100963138701EF005900AE267F |
23 | |
24 | 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:
1 | 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.
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, ...)
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.
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
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.
:
Bearbeitet durch User
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.
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
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/
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.
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.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.