Announcement: there is an English version of this forum on Hallo, diese Wechselrichter verfügen über einen RF 2,4 GhZ Nordic. Hat jemand eine Idee wie dieses Protokoll aufgebaut ist? 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. Google, Hersteller, etc. schweigen sich leider aus. Danke für sachdienliche Hinweise
sorbit schrieb: > Hat jemand eine Idee wie dieses Protokoll aufgebaut ist? Könnte auf der Basis von ShockBurst™ sein. Eine Beschreibung findest du z.B. im NRF24L01+ Datenblatt
Wenn die sich das einfach gemacht haben ist das ein properietäres Uart Signal.
Häng mich mal ran .... interessiert mich auch
Scheint leider niemand zu wissen… Schade, die WR sind eigentlich sehr verbreitet. Das Ding sendet ungenutzt dauernd wertvolle Daten in den Äther..
Bekomme demnächst auch den HM-600, von daher interessiere ich mich auch für das Thema. Zumal das Originalzubehör ziemlich teuer und hässlich ist...
Martin M. schrieb: > Bekomme demnächst auch den HM-600, von daher interessiere ich mich > auch > für das Thema. > Zumal das Originalzubehör ziemlich teuer und hässlich ist... Die schweigen sich da so ziemlich aus. Auf jeden Fall Cloudzwang mit Kosten und dieser wohl nicht verfügbare, teure wlan Stick
Ist da inzwischen jemand weitergekommen? Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine ID länger ist werden ignoriert. Erstes Problem: Das LC12S lässt sich nicht konfigurieren - zumindest spuckt dies die serielle Konsole aus. Beschaltet ist das LC12S so: VCC - 3V3 GND - GND CS - GND SET - IO4 Rx - IO16 Tx - IO 17 --> D.h. wenn, dann läuft es mit irgendwelchen Defaultwerten In der Konsole bekomme ich folgenden Nonsense bei aktuell schwankend 20-40W AC über Steckdose gemessen (klar, der WR ist ein anderer und hat ja bspw. 2 Strings usw...)
1 | 14:19:13.023 -> Received Inverter Status |
2 | 14:19:13.023 -> Device: 7201xxxx |
3 | 14:19:13.023 -> Status: 0 |
4 | 14:19:13.023 -> DC_Voltage: 46.00V |
5 | 14:19:13.023 -> DC_Current: 629.00A |
6 | 14:19:13.023 -> DC_Power: 28934.00W |
7 | 14:19:13.023 -> AC_Voltage: 0.00V |
8 | 14:19:13.023 -> AC_Current: 0.00A |
9 | 14:19:13.023 -> AC_Power: 0.00W |
10 | 14:19:13.023 -> Power gen total: 0.00 |
11 | 14:19:13.023 -> Temperature: 0 |
Sieht sich jemand in der Lage das Programm anzupassen? Hier ein Ausschnitt, welche Bytes überhaupt ausgewertet und wie sie verrechnet werden. Ich wüsste jtzt nicht welche Bytes wie rum zu shiften und verrechnen sind...
1 | void NETSGPClient::fillInverterStatusFromBuffer(const uint8_t* buffer, InverterStatus& status) |
2 | {
|
3 | status.deviceID = buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF); |
4 | //status.deviceID = buffer[5] << 32 | buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF);
|
5 | const uint32_t tempTotal = buffer[10] << 24 | buffer[11] << 16 | buffer[12] << 8 | (buffer[13] & 0xFF); |
6 | status.totalGeneratedPower = *((float*)&tempTotal); |
7 | |
8 | // CRC = buffer[14]
|
9 | status.dcVoltage = (buffer[15] << 8 | buffer[16]) / 100; |
10 | |
11 | status.dcCurrent = (buffer[17] << 8 | buffer[18]) / 100; |
12 | status.dcPower = status.dcVoltage * status.dcCurrent; |
13 | |
14 | status.acVoltage = (buffer[19] << 8 | buffer[20]) / 100; |
15 | status.acCurrent = (buffer[21] << 8 | buffer[22]) / 100; |
16 | status.acPower = status.acVoltage * status.acCurrent; |
17 | |
18 | status.state = buffer[25]; // not fully reversed |
19 | status.temperature = buffer[26]; // not fully reversed |
20 | }
|
Ich würde mal "bluetooth-clients" in der Umgebung suchen. Vielleicht hat man Glück. ;-) Was steht auf den Nordic-Chip?
Eule schrieb: > Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm > ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo > von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID > habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine > ID länger ist werden ignoriert. Hi Eule, ich habe das gleiche bei meinem HM-1200 versucht. Allerdings bekomme ich einfach keine Antwort nach: "Sending request now" wie hast du denn die InverterID im code eingegeben ? einfach die komplette Seriennummer vom WR (12 stellen) wie hier ? constexpr const uint64_t inverterID = 0x11617052xxxx ;
Hallo Eule habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann verworfen. Also, ich schau's mir mal an. Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und im Klartext als auch als Hex-Dump hättest. Hast du am Original-Code was geändert, oder so wie in Github zu finden?
> > Hi Eule, > > ich habe das gleiche bei meinem HM-1200 versucht. > Allerdings bekomme ich einfach keine Antwort nach: "Sending request now" > > wie hast du denn die InverterID im code eingegeben ? > einfach die komplette Seriennummer vom WR (12 stellen) wie hier ? > > constexpr const uint64_t inverterID = 0x11617052xxxx ; Hallo Chris, ja genau. Geht aber genauso gut oder schlecht, wie wenn ich die ersten 4 Stellen einfach weglasse und nur die letzten 8 verwende. Es scheint, dass sich irgendwas verändert, wenn ich das Modul in der Hand habe. Auf dem Tisch liegtnd bekomme ich meist auch keine Antwort, halte ich es in der Hand oder an den Kabeln tut sich meist etwas. Entweder diene ich als Antenne oder ich habe einen Wackler, den ich trotz mehrmaligem Auftrennen und Neuverbinden nicht wegbekomme. Bin einfach zu lange raus aus dem C++, mich verwirrt die Polldemo. :( Gruß Eule
Hubi schrieb: > Hallo Eule > habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles > HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, > aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe > ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann > verworfen. > Also, ich schau's mir mal an. > Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und > im Klartext als auch als Hex-Dump hättest. > Hast du am Original-Code was geändert, oder so wie in Github zu finden? Hallo Hubi, ich habe mir so ein LC12S Modul besorgt und an die 2. UART eines Lolin Boards gehängt. Die Polldemo habe ich lediglich um meine Inverter ID angepasst. Ansonsten habe ich inzwischen auch an zig Stellen im Code rumgedoktert - aber ich bin was das angeht mittlerweile einfach ein richtiger Anfänger. Mal alles was der WR ausgibt mitschneiden war auch meine Idee, bekomme ich aber auf die Schnelle nicht hin. Ich frage mich eh, wie der Aaron das "entschlüsselt" hat. Wenn die Werte halbwegs mit irgendwas zusammenpassen, kann man es sich ja noch zusammenreimen. Aber das passt bei mi gar nicht. Auch frage ich mich, woher kennt er den "command" mit 0xc0, 0xc1 usw.? Woher kennt er das Magic Byte? Ist das alles beim HM gleich oder anders? Gruß Eule
Hi Eule
hier auf die Schnelle der Code zur Ausgabe des Dumps:
void printBuffer (char * richtung) { // rein oder raus, send oder rcv
int i;
uint8_t ch;
Serial.println(richtung);
// drucke zuerst als Zeichen
for (int i = 0; i < sizeof(mBuffer); i++) {
ch = mBuffer[i];
if (ch >= 32 && ch < 127) Serial.print(ch); else Serial.print ('.');
}
Serial.println();
// jetzt das ganze in Hex
for (i = 0; i < sizeof(mBuffer); i++) {
ch = mBuffer[i];
if (ch < 10) Serial.print('0');
Serial.print (ch, HEX);
}
Serial.println();
}
Moin es wäre auch von Vorteil, wenn man nach dem sendCommand in der Methode getStatus den Buffer mBuffer wieder komplett löschen würde, etwa durch memset (mBuffer, 0, sizeof(mBuffer)) Da ab der Stelle 6 im mBuffer die DeviceId gefüllt wird (beim Senden) und dort nach Empfang des Status auch wieder steht, könnte man durch das vorherige Löschen ersehen, ob der Sender, also der WR, die DeviceId eingetragen hat. Dann wüßte man wenigstens, dass der WR richtig antwortet.
Kleines Update: Rx und Tx gehören anders herum, als im Code-Kommentar. D.h. alles was ich ab und zu "gelesen" habe, waren Geister. Nach dem Drehen von Rx/Tx erste Erkenntnis: die beiden Tx haben sich nicht weh getan, denn nun wird zumindest mal die Konfiguration des LC12S geschluckt! :) Aber vom Wechselrichter höre ich mit den gegeben Einstellungen für Channel und Network ID nichts. Ich bin dann auf dieses tolle Repository gestoßen: https://github.com/Yogui79/IntexPureSpa Da gibt's unter Tools was zum Suchen des Channels und der Network ID. Der klappert einfach einen nach dem anderen durch. Dauert halt... bisher noch kein Treffer beim Channel. Naja vielleicht hat der Hoymiles ja doch garkein LC12S verbaut...? Mal abwarten. Gruß Eule
OK, mal wieder was gelernt... Aber ans Ziel kam ich damit nicht. Die Kanalsuche schlägt nicht an. Also nochmal nach dem DTU gesucht und siehe da, ein Bild mit der aufgedruckten FCC ID gefunden. Die dokumentieren ja üblicherweise ihre Tests. Aha! https://fcc.report/FCC-ID/2ARNB-DTUW100 Wie man bei den internal photos sieht - kein LC12S verbaut. Sieht nach Eigenentwicklung - oder zumindest -layout aus. Wieso nicht noch weiter bei der FCC nach Hoymiles suchen? Achja, da gibt's ja auch ein RF Modul namens HM2401 einzeln - zum Verbau im WR vermutlich: https://fccid.io/2ARNB-HM2401 Auch hier gibt's nette Bilder. Das schaut tatsächlich nach was anderem aus, als das LC12S (https://fccid.io/2ARNB-HM2401/Internal-Photos/Internal-Photos-4572280) Aha! Ein NRF 24LE1E! Ich muss mal in den Keller, glaube sowas habe ich auch noch wo rumfliegen. Gruß Eule
Usr-c210 ist ein uart total WiFi modul von pusr
Tach in der Zwischenzeit habe ich einen RF24-Scanner in meinem Gartenhaus laufen lassen. Scanner sind bei diversen RF24 Libs als Beispiel dabei. Es wird nach Carriern auf den Kanälen gesucht. Mein bisheriges Resultat: - auf den Kanälen 1-14 ist recht viel los, sind ja auch die vom WLan - auf Kanal 64, der bei dem Polldemo benutzt wird, war rein garnichts los - meiste Aktivität war auf Kanal 16 bei 2 Mbps Mein nächster Ansatz, falls sonst keine neueren Erkenntnisse, wird sein, auf dem Kanal mal etwas zu senden, evtl sowas wie die Statusabfrage, und die Antwort abzuwarten. Übrigens: im Arduino-Repository gibt es die Lib nrf-hal, die stammt aus dem Hause Nordic und könnte die schon erwähnte proprietäre Lib für die Hoymiles sein.
Moin zusammen, kann ich hier mitmischen? Ich habe grade meine "Versuchsanlage" mit einem HM-600 in Betrieb genommen. Auf Grund dieses Beitrags habe ich jetzt ein NRF24-Mudul und einen Arduino zusammengesteckt und einen Scanner am laufen. Leider noch ohne Erfolg. Welche Scansoftware habt ihr eingesetzt und wie groß ist der Abstand HM und NRF-Modul (bei mir etwa 10m)? Wahrscheinlich ist es sinnvoll, den Empfänger mal direkt neben den HM zu setzen, oder? Kann ich erst machen, wenn es wieder hell ist. Finkt der HM überhaupt, wenn die Panels keine Spannung liefern? Viele Grüße Carsten
Hallo, ich hatte gesehen, dass in den FCC-Dokumenten, die weiter oben verlinkt sind, ein user manual enthalten ist. Dort ist angegeben: Channel List 2403, 2423, 2440, 2461, 2475MHz Vielleicht hilf das, die Suche einzugrenzen?
Carsten B. schrieb: > einen > Scanner am laufen. Leider noch ohne Erfolg. Hast du denn das Hoymiles Kommunikationsmodul (DTU-W100 ) laufen? Vielleicht antwortet der Wechselrichter nur auf Anfragen von diesem Gerät.
Hallo, DTU habe ich keine, war mir zu teuer und ich hätte es gern "cloudfree". Den Fehler beim Scanner habe ich gefunden, ich hatte noch zwei Pins vertauscht läuft jetzt. Noch kann ich aber keinen Kanal dem HM zuordnen.
Hallo meine Versuche mit dem Scanner hatte bisher keinen Erfolg. Oben gab es die Nachfrage welche Scanner eingesetzt wurden, ich nutzte die von den Libs rf24 und nrf_hal. Soviel ich weiß haben die nrf24l01 nur bis zu 126 Kanäle. Der Abstand zum HM-600 war nur knapp 2 m, und durch die Holzdecke + Schindeln. Bin jetzt leider am Ende meines Lateins, wenn noch jmd eine Idee hat mache ich gerne weiter.
Modul überprüfen. https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285 Direkt an TxD (oder auch RxD, das ist Definitionssache) des Moduls lauschen, ob Daten kommen. Und ganz böse: Sein eigenes Adapter-Modul einbauen. ;-)
ich bin auch interessiert - aber leider momentan viel zu wenig Zeit Aber schaut Euch doch das mal an: https://github.com/Koenkk/zigbee2mqtt/issues/4221 Hoymiles kommt aus dem gleichen Haus wie APSystems - denke das Protokoll ist sehr ähnlich Dort sind ein paar sehr fixe Jungs unterwegs die gerne behilflich sind
Angehängte Dateien:
Hallo zusammen, ich hänge mich hier mal rein, weil ich auch Cloud-Free
den "MI" auslesen will. In meinem Fall 2 HM-600.
Hoymiles kommuniziert über "Nordic proprietary"... siehe Anhang
Nordic proprietary != Zigbee
anderes Adress-/CRC-Protokol... mehr hab ich leider noch nicht erfahren
können... versuche auch schon mit 'nem NRF24l01 irgendwas zu
empfangen... fürchte aber, dass der Inverter wie beim NETSGPClient
getriggert werden muss... also aktiv Daten geholt werden.
Ansonten werden laut FCC-Test nur Kanal 13, 40 und 76 getestet
("Fundamental frequency")
Grüße^^
Das Gerät wird nicht ständig Senden. Wenn dann nur Keep Alive Packets mit größeren Abständen. Es könnte sogar sein, dass der Empfänger auch nicht ununterbrochen aktiv ist und zum Einschalten der Träger erst ein paar Sekunden anstehen muss. Die Hoymiles sind mit < 50mW Verbrauch bei Dunkelheit angegeben. Für permanentes Wlan reicht das nicht. Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die Kommunikation mitschneiden.
Einhart P. schrieb: > Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die > Kommunikation mitschneiden. Ich bin am überlegen, ob ich mir DTU-Wlite bestelle, gibt es momentan für 79€. Ist immer noch viel Geld...und beschränkt auf 4 Module... Bisher hat keiner der Beteiligten hier eine DTU? Mein Testaufbau mit den NRF24 und dem Arduino funktioniert, zwischen meinen beiden NRF-Modulen kann ich erfolgreich Daten austauschen. So bald das Wetter es zulässt, packe ich einen Empfänger neben den Hoymiles.
Sorry, sehe grade. dass ich als Gast geschrieben habe. Ich wars...
Tja, vllt findet sich ja einer mit DTU, der hier mitmachen will, wäre super. Meine Tests von heute morgen brachten folgende Resultate: - es scheint kein alive-Paket zu geben, das von den Hoymiles verschickt wird - Test auf Carrier-Signal auf den Kanälen, 13, 40 und 75 , dass nur auf Kanal 40 ein Carrier-Signal gefunden wurde, innerhalb einer Minute mehrere hundert.Auf den beiden anderen Kanälen war ab und zu ein Carrier, kann auch Rauschen sein. Ich denke, ohne dass man da die Kommunikation mitschneidet wird es sehr aufwendig. Ich versuch mal, ähnlich wie bei dem o.g. Projekt mit APsystems zu pollen.
Hallo zusammen, mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite bestellt, sowie einen HackRF SDR zur Protokoll-Analyse. Mein Ziel ist, die Kommunikation mitzuschneiden und die Daten mit einem nRF24 und ESP ins Heimnetz zu bringen. Die Info über die verwendeten Kanäle ist schon mal nützlich zur Eingrenzung der Suche. Ich melde mich, wenn dann mal alles da ist und ich Messungen machen konnte.
Klasse! Ich bin auf Ergebnisse gespannt.
Toll dass es hier weitergeht. Meine Tests haben zu keinem Ergebnis geführt. Das große Problem dabei ist, dass zuviele Parameter zueinander passen müssen, nämlich Kanal, (5-byte) Adressen der NRFs, Protokoll (Shockburst oder enhanced SB), Aufbau Datenpaket, "Magic" Byte, Füllbytes, CRC etc. Wenn meine Programmierkenntnisse gebraucht werden, gerne.
Angehängte Dateien:
-
spektrum.png
210 KB -
dtu_paket_zeitverlauf.png
67 KB -
dtu_top.jpg
170 KB -
dtu_bot.jpg
170 KB -
dtu_gd32.jpg
240 KB -
dtu_nrf24.jpg
240 KB
martin schrieb: > Hallo zusammen, > mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite > bestellt, sowie einen HackRF SDR zur Protokoll-Analyse. Hallo zusammen. Die Teile sind da und ich habe bereits erste Versuche durchgeführt, wovon ich euch einen Zwischenstand mitteilen möchte. Zum Funkprotokoll: Die Kanäle 3,23,40,75 scheinen zu passen, hier sieht man im Spektrum die Datenpakete, die per NRF gesendet werden. Die DTU scheint auch regelmäßig alle Kanäle zu bedienen - ob der Inverter immer auf dem selben Antwortet oder ob die Pakete redundant sind kann ich noch nicht sagen. Im Zeitverlauf kann man die Datenpakete auch schön sehen, allerdings bin ich mir nicht sicher ob der Universal Radio Hacker sie richtig dekodieren kann - mir fehlt der Vergleich, welche Daten es denn sein sollen. Dann hab ich mir die DTU mal genauer angeschaut. Alles in allem keine Raketentechnik. -Ein GD32F303 (Gigadevice, ein STM-Klon) mit SPI Flash 25Q128 . -Ein ESP8266 für die WLAN Kommunikation -Ein NRF24LE1E mit 2401C (RF Front End) Nachdem ich die beschriftete SPI-Schnittstelle gesehen habe, dachte ich "Da kann ich ja direkt die NRF-Kommunikation abfangen und mit den Funkpaketen vergleichen" - war aber leider nix, die Schnittstelle wird nicht benutzt. Ich muss jetzt also herausfinden, wo der NRF mit dem anderen uC kommuniziert. Ich vermute mal, dass irgendwo noch eine UART lauert. Den "USB"-Anschluss werde ich mir auch noch genauer ansehen, der scheint nämlich der Beschriftung nach ebenfalls eine UART zu sein. Mal schauen, was die ausgibt. Gibt also noch bisschen was zu tun... Soweit für heute, ich melde mich, wenn ich mehr herausgefunden habe. Schönen Sonntag euch allen.
Hallo Martin, sehr cool. Ich bin leider wehen ständigem Streß auf der Arbeit und Mistwetter nicht weiter gekommen. Ich wollte eines meiner NRF24-Module dicht an den Hoymiles auf dem Dach positionieren. Mal sehen, grad kommt die Sonne raus ... Carsten
Super Martin, wenn etwas brauchbares herauskommt, beteilige ich mich an den Aufwand gern mit einer Spende! Danke an ALLE
Fritzdect schrieb: > Ich hab hier ein Projekt gefunden: > https://github.com/Eule01x/NETSGPClient-for-Hoymiles Sorry, ist oben bereits erwähnt
Ich hab den HM-600 erst bekommen. Sobald er in Betrieb ist, werde ich das Example hier mal auf einem Nordic Board testen. Mal sehen ob dieses Protokoll verwendet wurde: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fesb_users_guide.html&cp=5_0_0_5_2
Ich steige mal wieder mit ein. Folgende Überlegung: wenn dieses Teil über USB eine Programmierschnittstelle hat, könnte man doch die Firmware mittels esptool auslesen. Und es gibt einige Reverse engeneering tools (wie zB Ghidra) , mit denen man wieder C-code generieren kann. Vllt lässt sich darüber etwas über die benötigten Infos wie Kanal, Adressen etc rausfinden.
Angehängte Dateien:
-
rf_signal.png
63 KB -
rf_demod.png
40 KB -
rx_tx.jpg
200 KB -
serial.png
9 KB
Hallo zusammen, ein kleines bisschen bin ich auch weiter gekommen mit meinem Reverse Engineering der DTU. Zuerst musste ich aber lernen, dass das erste Funksignal im meinem oberen Beitrag k*cke aussieht. War nicht richtig abgetastet. Hier ein Bild wie es aussehen muss. Das kann man dann auch schön demodulieren, um daraus die Bitfolge auslesen zu können. Damit muss ich allerdings noch ein bisschen hin und her experimentieren, weil ich nicht genau weiß wie viele Bits der NRF tatsächlich sendet. Deshalb habe ich mir gleichzeitig die Platine noch ein bisschen näher angeschaut. Die im Bild markierten Testpunkte sind Rx/Tx einer seriellen Schnittstelle zwischen dem NRF und dem GigaDevice, welche ich mir dann mit dem Logic angeschaut habe - die Baudrate ist übrigens 125.000 Baud/sec. Dadurch erhoffe ich mir Rückschlüsse, ob das Funksignal auch richtig demoduliert wurde - ich habe jedenfalls schon übereinstimmende Sequenzen gefunden. Aber für belastbare Daten und eine saubere Analyse brauche ich mehr Zeit... Wenn ich dann mal weiß, wie viele Byte der NRF sendet werden und was die Adressen sind, versuche ich einen eigenen NRF mithorchen zu lassen. Schönen Rest-Sonntag noch. Gruß, Martin
Danke Martin, mit dem Ansatz hast du eine gute Grundlage geschaffen.
Hallo Martin hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte.
Angehängte Dateien:
-
Enhanced_Shockburst.png
52 KB -
Protokoll_analyse.png
300 KB -
DTU_Protokoll_vorlaeufig.png
7 KB
Hubi schrieb: > Hallo Martin > hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von > Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die > Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, > und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte. Hallo Hubi, ja, das Enhanced Shockburst hab ich mir angeschaut - dürfte passen. Ich habe hier mehrere Re-Transmits eines Pakets untereinandergelegt, die sich (halbwegs) sauber demodulieren ließen (bisschen Jitter ist in den einzelnen Bitfolgen). Es tauchen vertraute Zahlenfolgen darin auf, nämlich jeweils die letzten 8 Ziffern (=Hex) der Seriennummern von Inverter und DTU. Siehe Beispiel - möchte meine Seriennummern nicht preisgeben ;-) Die eigentliche RF-Payload ist 27 Byte. Das passt auch zu dem, was der NRF seriell an den Controller schickt - das sind 29 Byte, wobei das erste und letzte Byte immer gleich sind (0x7E..0x7F). Ich vermute mal, die werden als Start- und Endmarker benutzt oder als Commands für den uC. Die Datenrate müsste 250 kbps sein, das habe ich mal mit einem eigenen NRF und einem Sendetest quergeprüft. Ich konnte bisher noch nicht herausfinden, welche CRC verwendet wird und ob die Payload selbst auch nochmal mit einer CRC versehen ist. Als nächstes will ich deshalb untersuchen, welche Daten in der Payload versteckt sind. Da müssten sich ja theoretisch die Leistungs- und Stromwerte finden lassen, die die App anzeigt. Das wird aber nochmal ein größerer Brocken Arbeit... Vielleicht gelingt mit diesen Informationen ja dem ein oder anderen auch schon eine Kommunikation?
Ich lobe mal einen Preis von 50€ aus für einen funktionierenden Clone. Das Biest auf meinem Dach soll mir sagen was los ist;-)
Hubi schrieb: > Dein Abtast sieht danach aus, denn da findet man die > Startsequenz 0x55. Ein 0x55 sagt über das Protokoll eher wenig aus. Das ist eine Standardsequenz, die eigentliche jede Funkübertragung benötigt, damit sich der Empfänger einpegeln kann.
Hallo Martin, hast du in der Spec vom Nordic den Abschnitt von der CRC gesehen: CRC (Cyclic Redundancy Check) The CRC is the error detection mechanism in the packet. It may either be 1 or 2 bytes and is calculated over the address, Packet Control Field and Payload. The polynomial for 1 byte CRC is X8 + X2 + X + 1. Initial value 0xFF. The polynomial for 2 byte CRC is X16+ X12 + X5 + 1. Initial value 0xFFFF. No packet is accepted by Enhanced ShockBurstTM if the CRC fails. Das könnte helfen, die verwendete crc herauszufinden https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
Angehängte Dateien:
-
nrf_sniff.png
7,4 KB -
wireshark_nrf24.png
180 KB
Hallo zusammen, hier mal wieder ein Update zur Protokoll-Analyse. Ich habe nun etwas mehr Durchblick bei der Kommunikation erreicht. Also es ist definitiv das Enhanced Shockburst Protokoll. Das direkt per RadioHacker zu analysieren ist schwierig, da es nicht immer exakt demoduliert wird - hinzu kommen die 9 Bit Status-"Byte", die die erkannte Bitfolge um 1 verschieben ggü. der eigentlichen Payload. Ziemlich unschön. Aber wenn man damit die Randbedingungen geklärt hat, gibt es eine bessere Methode: Sniffen mit dem nrf24sniffer von yveaux. Er hat ein kleines Arduino-Programm für einen Nano mit nrf24, sowie ein Windows-Tool, das mit Wireshark gekoppelt wird - Anleitung auf seiner Homepage, siehe GitHub-Link. https://github.com/Yveaux/NRF24_Sniffer Dazu muss man noch folgende Startparameter wissen: -Die Empfängeradresse des Inverters entspricht den letzten 8 Stellen der Seriennummer, aber umgedreht (Little Endian) - 00 anhängen nicht vergessen, da die gesamte Adresse des NRF 5 Byte lang ist. -Die Datenrate ist 250 kbps, max. Payload 32. Man kann das Tool dann hiermit starten (siehe Screenshot) und bekommt die Datenpakete in Wireshark serviert. Der oben bereits beschriebene Protokoll-Aufbau (innerhalb der Payload) scheint zu passen, eine CRC konnte ich darin nicht ausfindig machen - die des NRF wird mit diesem Tool automatisch geprüft. So konnte ich das was die DTU sendet direkt auf dem Rechner empfangen. Im nächsten Schritt hänge ich einen 2. NRF mit der Adresse der DTU dran, um das was der Inverter zurück schickt abzufangen. Und dann geht es darum, den Inhalt zu identifizieren - einen offensichtlichen Zusammenhang zu den physikalischen Größen habe ich leider noch nicht entdeckt. Scheint aber eine Menge Overhead drin zu sein...
Hallo Martin
ich verfolge sehr intensiv deine "Forschung". Bin gerade dabei, das
ganze mit einem Aruino pro mini und eine nrf24 nachzubauen, aber es
kommt keine Kommunikation zustande, WR antwortet nicht.
Vllt könntest du mir folgendes kommentieren:
(nur zur Info: ich benutze Lib RadioHead, die macht von Hause aus schon
das enhanced SB)
1) wenn mein WR die Ser.Nr. 112233445566 (dezimal), so nehme ich letzte
8 Stellen, also 33445566, daraus in Hex 0x01FE56BE und setzte damit im
nRF die Adresse mit dem byte-Array {BE,56,FE,01,00}, oder muss das 0x00
vorne hin?
2) in der payload setzte ich nach der 0x15 wiederum die Adresse des WR
(BE,56,FE,01) und danach den Rest wie in deinem Bild vom WireShark (72
81 88 ...).
Aber es passiert nichts, keine Antwort vom WR.
Eine Idee? Wenn nicht wartete ich weitere Ergebnisse ab.
mein Punkt 2 ist falsch: ich schreibe die Adresse des WR natürlich in umgekehrter Reihenfolge, also (01,FE,56,BE)
Hallo Hubi, nein, die Adresse des WR nicht in Hex umwandeln sondern direkt (die ist quasi schon Hex). Also aus deiner SN wird Ox66554433 als erste 4 Byte der Adresse für den NRF im Inverter. Plus vermutlich 01 als 5. Byte. Dann die Ox15 als (irgendein) Kommando. Der WR antwortet an dieser Stelle mit 0x95. Danach die Empfangsadresse nochmal richtig rum innerhalb der Payload, sowie die Sendeadresse. Die 72818832 ist die Seriennr. meiner DTU, da kannst du also theoretisch irgendwas nehmen, was du deinem NRF als "DTU"-Adresse gibst. Die 0x80 OB nach den Adressen scheint auch immer da zu sein. Ich weiß noch nicht, wofür das steht. Genauso wenig wie ich bisher über die restlichen 16 Byte weiß...
Martin, Danke für die ausführliche Erklärung. Aber auch damit habe ich bisher keinen Erfolg, leider. Da muss noch irgendwas anderes nicht stimmen, payload dynamisch oder fix, auto ack, ???
Hallo Hubi, ich vermute Mal, dass die "DTU" zuerst eine Initialisierung schicken muss. Habe aber keine Ahnung wie die aussehen muss. Dieses Wochenende komme ich auch nicht mehr dazu weiterzumachen, bin unterwegs... Melde mich, wenn ich mehr weiß.
1 | WLAN Nordic |
2 | 2.4 GHz |
3 | \|/ \|/ |
4 | | | |
5 | +-------+ (A)(?) +-----------+ |
6 | | ESP32 | <------------> | NRF24LE1E | |
7 | +-------+ +-----------+ |
8 | ^ ^ |
9 | | | |
10 | | +----------+ | |
11 | +-----> | GD32F303 | <-----+ |
12 | (B) +----------+ (C) |
13 | |
14 | ABBILDUNG 1: Systemübersicht "DTU" |
Hallo zusammen, ich stelle mir gerade die Frage, welche Wechselrichter ich mir für mein geplantes "Balkonkraftwerk" zulegen soll. Auch für mich wäre eine direkte Kommunikation zum Wechselrichter (ohne Hersteller-"Cloud"-Zwang) sehr attraktiv. Die Ermittlungen von @martin sind sehr interessant. Da ich auch beruflich mit ähnlich aufgebauten Systemen zu tun habe, wollte ich mal darstellen, welche Möglichkeiten ich kenne, solch ein System aufzubauen. Vielleicht hilft das ja, mit der Analyse weiterzukommen. Also: Das "DTU" scheint nach @martins Analyse aus folgenden drei Hauptkomponenten zu bestehen (siehe Abbildung 1): - ESP-12F: Das ist ein komplettes "System on Module" mit ESP8266 Mikrocontroller und integriertem WLAN. Theoretisch könnte die gesammte "Intelligenz" darauf programmiert sein. - NRF24LE1E: Das ist auch ein komplettes "System on Chip": (https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [1]). Es besteht aus einem direkt an einen allgemeinen Mikrocontroller gekoppelten RF-Frontend. Wenn wir auf der Schnittstelle zwischen Controller und RF-Frontend lauschen könnten, hätten wir gewonnen. Aber das wird nix, denn die ist "im Chip". - GD32F303: Der dritte Controller im System. Allein die Tatsache, dass dieser überhaupt vorhanden ist, deutet IMHO darauf hin, dass die "Hauptintelligenz" des "DTU" hierauf implementiert ist. Denn technisch hätten die anderen beiden Subsysteme beide genug Rechenpower/Speicher/etc, um ohne weitere Hilfe die Aufgabe des "DTU" zu erledigen. Belauschen können wir die Kommunikation zwischen den Chips, also die Wege (A), (B) und (C). (A) gibt es vermutlich nicht, wenn der GD32F303 die zentrale Steuerung macht - dann muss WLAN und Nordic nie miteinander reden. Die Kommunikation (B) zum WLAN ist im ersten Schritt vermutlich eher uninteressant. Bleibt also die Verbindung (C) zwischen GD32F303 und NRF24LE1E. Hier können wir nun "Glück" oder "Pech" haben, oder irgendetwas dazwischen: "Glück"-Szenario: Auf dem Mikrocontroller des NRF24LE1E läuft nur eine ganz einfache Software, die eingehende Bytes/Pakete 1:1 an das eingebaute RF-Frontend durchreicht. "Pech"-Szenario: Auf dem Mikrocontroller des NRF24LE1E ist eine Software implementiert, die "Kommandos" vom GD32F303 empfängt, und diese dann selbst in passende RF-Pakete übersetzt. Und eventuell auch mit einem fest im Controller hinterlegten Schlüssel verschlüsselt (die eingebaute Verschlüsselungs-Hardware ist ein Grund, warum man solch ein System so entwerfen würde). Im "Glück"-Szenario hätten wir so gut wie gewonnen. Wir könnten quasi die RF-Kommunkation mitlesen, und sie somit auch mit einem eigenen NRF24LE1E nachbauen. Ganz unwahrscheinlich ist das nicht, denn dieses Szenario ist natürlich (von Herstellerseite) einfacher zu implementieren, als auch noch für den NRF24LE1 "kompliziertere" Software zu schreiben. Und mir scheint, es steht zumindest nirgendwo in der Werbung, dass die Wechselrichter "verschlüsselt" kommunizieren. Meine Frage an @martin wäre also: Kannst Du die Verbindung (C) irgendwo entdecken und darauf mithören? Am wahrscheinlichsten sind das einfach eine RX und eine TX Leitung zwischen den beiden Chips (UART). Der Mikrocontroller hat laut Datenblatt ([1], s.o.) genau eine serielle Schnittstelle, bei dem verbauten 32-pin-Gehäuse sollten die hier sein: - P0.4 (Pin 7): RXD - P0.3 (Pin 10): TXD Auf Deinen Fotos passt das auch insofern, als diese Pins jeweils in ein Via gehen. Da könntest Du mal versuchen, die Leiterbahnen zu verfolgen. Oder direkt da mit einem Tastkopf abgreifen. An einem Oszi sollte sich da schnell ein Signal zeigen und die Datenrate lässt sich dann rausmessen. (Die GND, CVV, ROG, SCK, SI, SO, SCN, RST Kontakte sind vermutlich "nur" die Programmierschnittstelle für den NRF24LE1 und werden im Betrieb keine Daten übertragen.) Jetzt bin ich mal gespannt, ob Ihr mit meiner Analyse übereinstimmt, und natürlich, ob @martin auf den Pins sinnvolle Signale mitlesen kann! Viele Grüße -- Petersilie (sorry, Vorname ist auch "Martin" - davon haben wir schon mehrere in diesem Thread...)
:
Bearbeitet durch User
Hallo Martin/Petersilie ;-) ja, die beiden Testpunkte gehen an die Rx/Tx Pins des NRF24LE1E. Ich habe auch schon die Kommunikation zwischen NRF24LE1E und GD32F303 mit dem Logic Analyzer mitgeschnitten. Es sieht tatsächlich so aus, als würde der NRF nur "stupide" als Transceiver benutzt. Ich vermute, wie du oben beschrieben hast, dass die Logik im Gigadevice sitzt und der ESP ebenfalls nur als Gateway zur Cloud dient. Die DTU stellt übrigens auch permanent ein WLAN zum direkten Zugriff bereit per App (das ist eher unschön, wenn man das Ding dauerhaft im Einsatz hat). Die bisherige Untersuchung zeigt, dass die Pakete "on air" 1:1 den seriellen Datenpaketen entsprechen. Jetzt geht es also darum, aus den seriellen Daten schlau zu werden. Ein paar Randbedingungen konnte ich schon klären, z.B. kommt immer die Seriennummer des Inverters bzw. der DTU im Paket vor (Absender und Empfänger-Adresse). Leider habe ich im Moment wenig Zeit, weiter an dem Protokoll zu forschen. Ich versuche euch demnächst mal eine Excel-Tabelle mit den aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit den Daten bereits was anfangen. (Einschalten der DTU, Verbindung zum Inverter, Regelmäßige Abfrage).
martin schrieb: > Ich versuche euch demnächst mal eine Excel-Tabelle mit den > aufeinanderfolgenden Paketen bereitzustellen, Das wäre spitze. Einfach mitschneiden. Muss nicht aufwendig aufbereitet sein. Eventuell kannst Du auch einfach ein Terminalprogram (HTerm o.ä.) aufzeichnen lassen. Was auch super funktioniert sind diese Saleae Logik-Analyser, falls Du zufällig so einen hast. Wäre doch gelacht, wenn wir bei diesen Erkenntnissen und der Vorarbeit dem Protokoll nicht vollends auf die Schliche kommen würden!
Bin auch dabei, wenn genügend Daten über die Kommunikation da sind, an einem Klon mit zu programmieren. Man müßte halt vom 1. Anschalten der DTU, über Registrierung des WR bis hin zur dauernden Übertragung der Daten von WR zu DTU mal alles aufgezeichnet haben. Verschlüsselt ist da wohl nichts, sonst könnte man die Seriennrn nicht rauslesen. Bin schon ganz gespannt auf die Daten!
Hab mir die Bedienungsanleitungen für die DTUs mal durchgelesen. Sieht mir so aus, als müsse es eventuell gar keine "Verbindungsaufnahme" o.ä. geben. Der DTU sagt man einfach, welche Seriennummern die Wechselrichter haben, und die DTU fragt dann regelmäßig alle eingetragenen Wechselrichter ab. Insofern also "einfach" mal die RX und TX Bytes für einige Zeit mitschneiden (ein ganzer Tag wäre ultimativ), dann sehen wir hoffentlich irgendwelche Muster in der Payload, über die wir dann auf den Inhalt schließen können.
Super Projekt das ihr da Versucht umzusetzen. Ich habe seit ein paar Tagen einen HM700 und eine DTU WLite. Ich habe allerdings sogar das Probelm das die DTU bei mir gar nicht richtig hochfährt und ich nur ein WLAN das AiThinker heisst angezeigt bekomme. Fahre ich ein paar Kilometer weit weg, fährt der Stick hoch und zeigt mir das DTU WLAN an. Habt ihr dazu eine Idee? Eine Alternative zu dem Stick wäre mir auch am liebsten! Die Cloud braucht ja keiner ;) LG Martin
Hab ich mir am Anfang auch gedacht, nur sind fast keine anderen WLAN Signale in der nähe. Hab dann auch schon mein eignes Mesh Wlan abgedreht, bringt keine Besserung. Auch in der restlichen Ortschaft funktioniert es nicht. Nur beim Bahnhof... sehr strange das ganze... Aber egal, ich beobachte eure Vortschritte weiter, der Stick geht aber auf jeden Fall wieder zurück. LG Martin
Hallo, ich würde sehr gerne helfen, da ich auch einen HM-400 habe und dessen Daten auslesen möchte. Ich hab den Thread hier schon verfolgt, aber bisher noch keinen Code gesehen. Wie schafft Ihr es, dass der Wechselrichter antwortet? Ich würde sehr gerne helfen und die Antworten des Wechselrichters auswerten / analysieren. Derzeit bekomme ich aber noch nicht mal eine Antwort.
1 | #include <Arduino.h> |
2 | #include <SPI.h> |
3 | #include <nRF24L01.h> |
4 | #include <RF24.h> |
5 | |
6 | /**
|
7 | * CSN 5
|
8 | * CE 4
|
9 | * MOSI 23
|
10 | * SCK 18
|
11 | * IRQ
|
12 | * MISO 19
|
13 | *
|
14 | * FCC URL: https://fcc.report/FCC-ID/2ARNB-DTUW100
|
15 | * Allowed Frequency: 2403, 2423, 2440, 2461 or 2475MHz
|
16 | * Channel: 1 1 8 10 13
|
17 | * Tested Channels: 1, 3, 6, 9, 11 (FCC)
|
18 | */
|
19 | |
20 | // ---- Radio Setup ----
|
21 | RF24 radio(4, 5); // CE, CSN |
22 | |
23 | // serial no hoymiles: 112234567890
|
24 | |
25 | const uint64_t deviceID[1] = { 0x0987654301 }; |
26 | |
27 | |
28 | // ---- Program Values ----
|
29 | const int unitNumber = 0; // Sets the pair out of the 6 programmed channels |
30 | |
31 | int dataSend = 0; |
32 | int dataReceive = 0; |
33 | |
34 | int channels[5] = {3, 23, 40, 61, 75}; |
35 | |
36 | //============ Send/Recieve Function ============
|
37 | void rxtx() { |
38 | |
39 | for( int i = 0; i < sizeof(channels)/sizeof(channels[0]); i++ ) { |
40 | int iChannel = channels[i]; |
41 | |
42 | Serial.print("rxtx Start"); |
43 | Serial.print(" "); |
44 | Serial.println(iChannel); |
45 | |
46 | uint8_t deadPool = 0x15; |
47 | uint8_t frankCastle = 0; |
48 | int iTx = 0; |
49 | int iRx = 0; |
50 | |
51 | radio.setChannel(iChannel); |
52 | |
53 | radio.printPrettyDetails(); |
54 | |
55 | //Begin Transmission and send for 10ms
|
56 | for (int iTx=0; iTx <= 10; iTx++){ |
57 | radio.stopListening(); |
58 | radio.write(&deadPool, 1); |
59 | delay(1); |
60 | }
|
61 | |
62 | //Begin Receive and listen for 10ms
|
63 | for (int iRx=0; iRx <= 10; iRx++){ |
64 | radio.startListening(); |
65 | radio.read(&frankCastle, 1); |
66 | delay(100); |
67 | }
|
68 | dataSend = deadPool; |
69 | dataReceive = frankCastle; |
70 | Serial.println("RxTx Cycle Finished"); |
71 | Serial.println(dataSend); |
72 | Serial.println(dataReceive); |
73 | Serial.println(""); |
74 | }
|
75 | }
|
76 | |
77 | |
78 | void setup() { |
79 | // ---- Activate Radio ----
|
80 | Serial.begin(115200); |
81 | |
82 | radio.begin(); |
83 | radio.openWritingPipe(deviceID[unitNumber]); |
84 | radio.openReadingPipe(unitNumber, deviceID[unitNumber]); |
85 | radio.setPALevel(RF24_PA_MIN); |
86 | radio.setPayloadSize(1); // Sets payload to 1 byte |
87 | radio.setDataRate(RF24_250KBPS); |
88 | radio.setAutoAck(unitNumber, false); |
89 | |
90 | // radio.printDetails();
|
91 | }
|
92 | |
93 | void loop() { |
94 | // Serial.println("Loop Start");
|
95 | rxtx(); |
96 | // Serial.println("Loop End");
|
97 | |
98 | delay(1000); |
99 | |
100 | }
|
Vielen Dank Marcel
martin schrieb: > Ich versuche euch demnächst mal eine Excel-Tabelle mit den > aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit > den Daten bereits was anfangen. Hallo zusammen, im Anhang findet ihr eine Excel-Tabelle mit Daten die ich vor kurzem aufgezeichnet hatte. Es handelt sich dabei um die INTERNE Kommunikation in der DTU zwischen dem GD32 und dem NRF - die ersten 15 Sekunden nach Einschalten. Diese Daten entsprechen nach meinem Kenntnisstand fast 1:1 der Funkkommunikation mit dem Inverter (siehe Tab 3 in der Excel). Einiges, was ich identifizieren konnte, habe ich bereits markiert - vielleicht könnt ihr weitere Teile entschlüsseln. Leider ist es nicht ganz so offensichtlich, wo sich die Daten zu Strom, Spannung und Leistung wiederfinden lassen. Aber vielleicht könnt ihr mit diesen Infos ja bereits einen NRF mit eurem Inverter kommunizieren lassen. Ich vermute, dass die Kommunikation von der DTU initiiert werden muss, da man dort die Seriennr. des Inverters einträgt. Der antwortet dann nur, wenn er seine Nummer "hört" (ab dem 2. großen Kommunikationsblock im Tab 2).
Hallo Martin, vielleicht eine blöde Frage, aber hast du mal mit einem Hexeditor auf die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Die Aufbereitung in Excel ist Klasse für die Doku, aber für das Handling der Daten finde ich es eher unpraktisch. Vielleicht kannst du auch noch die Rohdaten als Binärfiles zur Verfügung stellen? Da ich mittelfristig eh einen zweiten HM brauche, habe ich gestern einen bestellt. Dann kann ich den "unter den Schreibtisch" legen und komme vielleicht auch weiter. Vom Dach empfange ich keine Daten, bzw. kann sie in all den "Stördaten" nicht identifizieren. Ich würde es dann mal mit HM und dem NRF24 in einer "Blechkiste" zur Abschirmung versuchen. Sendet der HM eigentlich auch Daten, wenn die Panels nichts liefern? VG Carsten
Angehängte Dateien:
-
raw_data_display.png
22 KB
Carsten B. schrieb: > hast du mal mit einem Hexeditor auf > die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Hallo Carsten, habe deinen Vorschlag mal mit den vorhandenen Daten umgesetzt, siehe Binary anbei. Mit HxD war auch kein Muster direkt erkennbar, neben dem von mir bereits markierten Aufbau der Datenpakete. Wegen der verschieden Länge der Pakete habe ich diese jeweils mit 00 aufgefüllt - so sieht es wenigstens angenehmer aus ;-)
Marcel schrieb: > Wie schafft Ihr es, dass der > Wechselrichter antwortet? Hallo Marcel, mit einem eigenen NRF hat es bisher noch keiner hier geschafft. Ich hatte mir die DTU ("Data Transfer Unit"?) vom Hersteller gekauft, um damit das Protokoll abzufangen und analysieren zu können. Darin werkelt ebenfalls ein NRF auf den ich mich in meinen bisherigen Texten bezogen habe.
Angehängte Dateien:
Hi, ich bin auch am Überlegen mir eine PV zu kaufen. Die meinsten Angebote sind mit dem HM Wechselrichtern. Für die Integration in meine Hauselektronik will ich aber keine Cloud. Daher kommt mir der Bertrag sehr gelegen. Mal sehen, wo ich helfen kann. Ich hab mir mal die Binärdaten angesehen und noch Werten gesucht, welche normalerweise stabil sind. (Netzfrequenz und Netzspannung) Wenn mich nicht alles teucht, könnten es die Bytes (Big-Endian) im Screenshot sein. Gruß Pascal PS: Hier gibt es noch die Modbus Register der DTU Pro. Vielleicht läst sich daraus etwas ableiten. https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
Angehängte Dateien:
Hi, hab noch was rausgefunden: Das letzte Byte vor dem EOF (0x7F) ist ein CRC8 mit poly=1 init=0 xor=0 Hoffe, dass konnte weiterhelfen. Gruß Pascal
Angehängte Dateien:
Noch mehr Bytes.
Hallo Pascal, sehr gut, das sind schon mal hilfreiche Infos - das erste Byte nach den Seriennummern scheint zu kennzeichnen, welche Werte folgen. Bei den von dir vermuteten Netz-Ausgangsdaten (scheint zu passen) war es jeweils die ID 0x02 an Byte[10].
Hi Martin, mit der 0x02 passt nicht immer. In deiner Excel Datei Spalte AW ist eine Antwort, wo es nicht passt.
Angehängte Dateien:
-
excel.png
28 KB
Hallo Pascal, stimmt. Auf den ersten Blick würde ich vermuten, dass es an der Abfrage durch die DTU liegt. Die 0x80 an Byte[10] heißt wohl lesen - danach folgt i.d.R. die 0x0B für Ist-Werte. In dem von dir genannten Fall (Spalte AW) ist es aber die 0x11. Es dürften also irgendwelche anderen Werte folgen.
Hi Martin, hast du noch mehr Daten zu deinem Wechselrichter? Vielleicht sind es Daten zu Einstellungen, Firmware, ...
Pascal A. schrieb: > hast du noch mehr Daten zu deinem Wechselrichter? > Vielleicht sind es Daten zu Einstellungen, Firmware, ... Hallo Pascal, morgen kann ich dir mehr sagen - heute komme ich nicht dazu, weil mein Wechselrichter leider noch nicht fest installiert ist. Ich würde ihn ja gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn dadurch abschieße...
martin schrieb: > Ich würde ihn ja > gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn > dadurch abschieße... Spannung im zulässigen Bereich und passende Strombegrenzung - dann kann nichts passieren. Am besten die Spannung niedrig halten damit der MPPT noch nicht arbeitet. Dann kannst du wunderbar verschiedene nahezu konstante Bedingungen schaffen und die zugehörigen Daten untersuchen.
Hallo, ich bin auch interessiert, da eine Anschaffung geplant ist. Ich habe mir die Daten auch mal angeschaut. Der 'PackageCounter' und die drei davorliegenden Bytes sind die Uhrzeit in BigEndian time_t 32-bit => 13.02.2022 13:16:04. Sieht man in der Oberfläche die Today Production / Total Production in Wh? Laut Modbus Beschreibung sollten dies 2 bzw 4byte sein. Interessant sind die beiden vorletzten Bytes vor dem 0x7F; ggf auch eine Art zusätzliche Prüfsumme? Das Byte direkt vor dem 7F ist ja eine CRC8. Hilfreich wäre m.E. auch mal eine andere Seriennummer zusätzlich zu probieren um zu sehen was sich bei der Anfrage hier ändert. VG Frank
Super! Ich habe mal versucht, die bisherigen Erkenntnisse in der angehängten Textdatei zusammenzufassen. Vielleicht gewährt das ja noch neue Einblicke. Gerne erweitern!
Das 1. Init (mit den 8 Nullen) scheint mir eine Broadcast zu sein, aber über welche Adresse wird das verschickt? In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn Adresse WR ist ja noch nicht bekannt, aber der sch... WR antwortet einfach nicht.
Hubi schrieb: > In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn > Adresse WR ist ja noch nicht bekannt So wie ich das Verstanden habe gibt man die Seriennummer(n) der WR in der DTU (oder in der Cloud) ein bevor eine Kommunikation möglich ist. Dadurch wäre die Adresse des WR schon bekannt. Aber andererseits antwortet der WR mit der Adresse der DTU. Die ja nicht bekannt wäre wenn die nicht im ersten Frame enthalten wäre. Könntest du ggf. dein Testprogramm sharen? Habe hier einen HM-1500 sowie NRF24 Module. (nur aktuell noch keine Zeit gehabt einen Testaufbau zu machen bzw. Abends ist der WR meist schon aus)
:
Bearbeitet durch User
Anbei mein Testprogramm. Wer will kann es gerne weiterbenutzen und anpassen. Vllt hat ja jmd mehr Erfolg als ich.
Danke für den Sourcecode! Ich mag mich täuschen, aber sollte das hier:
1 | void tele7 () { |
2 | //=============
|
3 | memset (data, 0, 32); |
4 | data[0] = 0x07; |
5 | data[10] = 0x07; |
6 | datalen = 11; |
7 | }
|
nicht eher so aussehen:
1 | void tele7 () |
2 | {
|
3 | memset(data, 0, 32); |
4 | data[0] = 0x7e; |
5 | data[1] = 0x07; |
6 | data[11] = 0x07; |
7 | data[12] = 0x7f; |
8 | datalen = 13; |
9 | }
|
Nachdem im Excel vorher die komplette Payload dargestellt ist müsste doch das 0x7e und 0x7f mit dazu oder verstehe ich was falsch?
Hallo Thomas so wie ich die Excel-Tabelle verstanden habe ist das ein Mitschnitt innerhalb der DTU, also zwischen der "CPU" und dem NRF. Und diese Kommunikation startet mit 7E und endet mit 7F. Aber Martin kann das bestimmt klären.
Wir müssen unterscheiden zwischen (a) den Nachrichten zwischen dem GD32F303 und dem NRF24LE1E [1], und (b) den Nachrichten, die der µC im NRF24LE1E an den darin eingebauten "nRF24L01+"-kompatiblen Transceiver sendet. Martins Radio-Mitschnitt hat bewiesen, dass der "nRF24L01+"-Teil nach dem Nordic "enhanced Shockburst" Protokoll funkt. Dieses beinhaltet insbesondere immer eine Zieladresse. Siehe [1], Kapitel 3.4.3: - Preamble 1 byte - Address 3-5 byte - Packet Control Field 9 bit - Payload 0-32 byte - CRC 1-2 byte Für Shockburst gibt es leider keinen einfachen (d.h. NRF24LE1E-basierten) "Sniffer", um alle Nachrichten mitzulesen. Daher das weiter oben erwähnte Projekt in [2]. Unser Ziel ist ja wohl, mit einem einfachen "nRF24L01+" direkt mit einem/mehreren Wechselrichtern zu sprechen. Dazu müssen wir zu jeder der von Martin zwischen GD32F303 und NRF23LE1E mitgeschnittenen Nachrichten auch wissen, wie diese Nachricht schließlich (als "enhanced Shockburst"-Nachricht) versendet wird. Glücklicherweise scheint es sich herauszukristallisieren, dass die beiden sich sehr ähnlich sind. Alternativ könnte man eventuell an diese Pakete "direkt" drankommen, wenn man im Wechselrichter mitliest - was ist denn dort verbaut? Auch ein NRF24LE1E, oder eventuell ein "nRF24L01+" Transceiver? Ich könnte mir auch gut vorstellen, dass gewisse Nachrichten übernaupt nicht an den Transceiver (und somit in den Äther) gehen, so zum Beispiel die "Init" Nachricht. Vielleicht ist das lediglich eine Nachricht an den NRF24LE1E à la "mach' Dich bereit" oder so? -- petersilie [1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [2] https://github.com/Yveaux/NRF24_Sniffer
Übersicht erweitert: Nachrichten "02 28 23" und "82 00 03" ergänzt. Sauberer ausgerichtet. Python Beispiel für CRC.
petersilie, du hast recht. Ich hatte verdrängt das auf den NRF24 selbst auch noch Logik vorhanden sein kann. Ich würde jetzt mal unterstellen, dass der WR immer auf seine Seriennummer (= Adresse) lauscht und der DTU ebenfalls auf seiner Seriennummer. In Init 1 (siehe deine Text File) würde die DTU zwar an die Adresse des WR ein Paket senden aber der WR würde nicht wissen an welche Adresse er antworten soll. Dies ginge erst ab Init 2 weil dort die DTU seine eigene Adresse an den WR schickt. Bei der Durchsicht des Datenblattes [1] ist mir noch etwas im Kapitel 3.4.3.3 aufgefallen. Dort wird u.a. das No Acknowledgment flag beschrieben. Im Post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" wird beschrieben das das PCF 0D8 (== b011011000) ist. Was ja bedeutet das NO_ACK 0 ist. "Setting the flag high, tells the receiver that the packet is not to be auto acknowledged." Es ist low, also muss AutoAck true sein. Das wäre zumindest etwas was mir im Code von Hubi aufgefallen ist. Ebenso wird im oben genannten Post beschrieben das Channel 3 verwendet wird.
1 | radio.setAutoAck(true); |
2 | radio.setChannel(3); |
[1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
Ich hab mir jetzt mal solche NRF24-Platinchen geordert. Wir kennen die verwendeten Adressen. Somit können wir doch einen NRF24 auf die gleiche Adresse konfigurieren wie den Wechselrichter. Dann sollte der doch genau die Pakete von der DTU empfangen, oder was meint ihr? Damit hätten wir dann einen 1:1 Mitschnitt der tatsächlichen Pakete in die Richtung DTU --> WR. Später drehen wir das Spiel um, und konfigurieren den NRF24 auf die Adresse des DTU. Und hören wiederum zu. Eventuell macht das "auto-ACK" Probleme - das man eventuell empfängerseitig nicht abschalten kann. Aber vielleicht reicht es, den "Zuhörer" schön weit weg zu platzieren, damit das ACK vom echten Empfänger gewinnt. Leider habe ich (noch) keinen WR/DTU. Lieferprobleme überall. Wenn das mit den NRF24 klappt, könnte ich eventuell einen vorkonfigurierten Raspi zur Verfügung stellen, den dann ein stolzer Besitzer einer DTU (Martin?) mal lauschen lassen könnte... Hubi hat ja wohl auch nur einen WR, aber keine DTU. Da ist nach den bisherigen Erkenntnissen mit Zuhören allein wohl leider nichts zu holen, da der WR ohne passende Frage auch nie antwortet.
Angehängte Dateien:
-
Comm_Schema.png
130 KB
Hallo zusammen, gestern hatte ich versucht, den Wechselrichter mit einem Netzteil zu speisen - leider hat mir der MPP-Regler dazwischengefunkt und es hat sich kein stabiler Arbeitspunkt eingestellt. Ich glaube, es wird doch endlich mal Zeit für ein ordentliches Labornetzteil... Freut mich, dass hier so viele helfen, das Protokoll zu knacken. Aber ich glaube, es herrscht hier noch ein bisschen Unklarheit über die von mir bereitgestellten Daten. Deshalb nochmal ein Schema zur Klarstellung. Die obige Excel/Binärdaten zeigen die serielle Kommunikation innerhalb der DTU! Der NRF24LE1E ändert diese Pakete nochmal ab, bevor er sie an den Inverter rausschickt, inklusive Neuberechnung der CRC8. Die Initialisierungssequenz dürfte also nur dazu da sein, den NRF24LE1E mit den benötigten Adressen zu versorgen. Die erste Kommunikation "on air" beginnt dann erst nach den 3 Init-Sequenzen - das wäre der Ansatzpunkt, den jeder mit einem Inverter und ein paar NRF24 Modulen mal in Angriff nehmen könnte: -Enhanced Shockburst (ist voreingestellt) -CRC 2 Byte -250 kbit -Kanal 3, 23, 40, 61 oder 75 -Paketlänge 27 Byte -Empfänger-Adresse: Letzte 8 Stellen Inverter Seriennr. BCD in "Little Endian" Und wenn dann das im Bild dargestellte Datenpaket gesendet wird, müsste euer Inverter theoretisch antworten.
Macht er aber nicht!
Ich habe folgendes
15 72 60 79 52 72 81 88 32 80 B 0 62 9 4 9B 0 0 0 0 0 0 0 0 2 29 31
an addrWR[5] = {0x52, 0x79, 0x60, 0x72, 0x01} gesendet, aber das
Drecksding muckst sich nicht.
Meine Seriennummer WR ist xxxx72607952.
Die 31 ist die CRC8 der vorangehenden Bytes.
Das sollte doch alles passen!?
Hallo Hubi, ja, die Sequenz sieht m.M.n. richtig aus. Hast du es mal auf den anderen Kanälen probiert? Ist das in deinem Beispielcode enthalten? Dann könnte ich es mal bei mir probieren. Oder es könnte doch noch weitere Inbetriebnahmeschritte geben. Vielleicht wird die DTU-Adresse bei der Einrichtung per S-Miles App im Inverter gespeichert? Dazu müsste ich das ganze Setup nochmal neu machen, während ich die Pakete mitschneide.
Habe alle Kanäle ausprobiert, aber nix. Vllt ist auch die Entfernung zum WR zu groß. Sende hier vom Wohnzimmer durch Glastür in Richtung Gartenhaus mit dem WR aufm Dach. Im Anhang nochmals das Testprogramm. Als RF24 Lib benutze ich die von TMRh20 und die CRC-Lib findet man hier https://github.com/RobTillaart/CRC (bin zu blöd um Link einzufügen)
Hello all, First of all, I don´t speak german, so I am following this thread using google translator, it´s not a problem for me. I have a DTU-W100 and five MI-1500 microinverters. I have flashed a Logitech Unifying Dongle with the firmware from this repo https://github.com/BastilleResearch/nrf-research-firmware I left it running on channels 1,3,6,9,11,23,40,61 and 75 for all night, I don´t know if logged packages came from PV system. The dongle is a bit far from the MI and DTU, but today morning I put it about 2-3 meters from two MI-1500 and now I waiting for new data, but the code use DWELL for channel scanning, so probaly I am losting some packages. If anyone need a specific channel scanner or sniffer or any other test, I can help in my spare time. I hope this project will go forward!
Hi Arnaldo, Welcome to the party! Thanks for offering to help out with scanning/sniffing, and thanks for providing some results already! Looking at the received packets, it seems to me that these are unlikely to be coming from your MI-1500s for the following reason: I think we have already established that the devices (DTU/MIs) use the last 8 decimal digits of their respective serial numbers converted to BCD code as their "Shockburst" address. This implies that the address will never contain any of the hex digits A...F. From your list, this only leaves a handful (if your hand happens to be six-fingered, that is) of packets, but these don't look familiar:
1 | [2022-03-10 19:17:25.477] 11 21 55:15:57:55:BD 9A:AA:A8:2A:AA:AA:AA:AA:A2:97:AA:6A:AB:A9:AE:EA:AE:DA:79:2B:AA |
2 | [2022-03-11 04:14:56.172] 3 4 22:34:55:93:10 4C:01:2E:77 |
3 | [2022-03-11 05:46:00.747] 6 0 24:01:05:45:0B |
4 | [2022-03-11 06:17:57.783] 75 1 14:01:51:14:25 25 |
5 | [2022-03-11 07:00:49.999] 75 0 03:24:85:46:EA |
6 | [2022-03-11 07:06:58.018] 3 18 23:85:84:40:1F 23:5D:89:FA:D8:D5:B5:54:FA:FA:BA:A7:AC:90:C5:55:A8:C7 |
However, knowing the address that the inverters use means that we should be able to "sniff" specifically for packets to/from those addresses. I am not familiar with the "nrf-research-firmware" tools, but it appears to me that you might be able to use the "nrf24-sniffer.py" tool to specifically follow packets sent to/from a particular address. If your DTU serial number is, say, xxxx12345678, then this address should be 0x78,0x56,0x34,0x12 (possibly followed by 0x01 - not sure about that). But first, let's see what today's data contains! Very excited about this project gaining more participants. -- petersilie
Hello Arnaldo, thanks for the dump. I can see that your dump was mainly during the night. If i’m correct, the Hoymiles is not active in the night because the required start voltage is not generated by the solar panels. It would be beneficial if you try to “sniff” during a more or less sunny day. Even the last 5 byte pairs of your devices and DTU could be helpful for analyzing the dump. Thanks a lot Marcel
@hubi,@tbnobody Zumindest was den Kommentar in Zeile 35 (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") angeht ("// !!!! muss false sein sonst klappt senden nicht") kann ich Euch glaube ich beruhigen. Das Senden geht nicht schief, wenn Auto-ACK aktiviert wird. Vielmehr gibt die write()-Funktion zurück, ob ein ACK empfangen wurde (true), oder eben nicht (false), siehe [1]. Somit geht zwar das Senden nicht schief (das Senden gelingt wohl laut Spezifikation "immer"), aber der WR antwortet nicht (mit einem ACK). [1] https://nrf24.github.io/RF24/classRF24.html#a4cd4c198a47704db20b6b5cf0731cd58
@martin Bist Du sicher, dass die Pakete 5-Byte-Adressen verwenden, und nicht etwa nur vier? Mir fiel nämlich auf, dass "Shockburst" das Einstellen der Adresslänge (zwischen 3 und 5 Bytes) zulässt. Die RF24-Lib hat dazu die Funktion setAddressWidth() ([1]). Es scheinen ja nur die letzten 8 Dezimalziffern der Seriennummer in die (ersten vier Bytes der) Adresse umgesetzt zu werden. Bisher haben die Versuche oben dann als fünftes Byte ein "0x01" genommen, aber wo kommt das her? Hast Du das so auf dem Funk gesehen, oder ist das geraten? [1] https://nrf24.github.io/RF24/classRF24.html#ad5aea7f9a3bd9c7d357fb296ce751f21)
Hallo Petersilie habe mir den Source-Code angesehen und bin zu gleicher Erkenntnis gekommen. Mich hat halt nur gestört, dass das Senden immer das Ergebnis false lieferte. Aber was ist nun besser fürs testen, mit AutoACK=TRUE und Ergebnis=false oder doch besser Ack abschalten? Frage weil du halt geschrieben hast dass wohl AutoAck eingeschaltet ist laut deiner Mitschnitte (im PCF)? Bist du da sicher?
Was "besser" ist, ist eine gute Frage. Tatsache ist, es ist sehr unwahrscheinlich, dass der WR antworten wird, wenn er nicht einmal ein ACK sendet. Insofern würde ich sagen, es ist "besser", mit eingeschaltetem AutoACK zu arbeiten. Die Mitschnitte sind von einem anderen Martin - insofern muss ich die Frage weitergeben, ob das ACK-Bit in der beobachteten Kommunikation wirklich gesetzt ist, oder nicht... -- petersilie
I attached the log from today, I think tomorrow I will listen just on channel 1, or if someonte have another idea please tell me. @parsley it´s my first time using the nrf-research-firmware tools, so I am trying to do something that can help, I need to identify a address and after it sniff just this address with nr24-sniffer.py. To add a MI in hoymiles plataform you need to use the serial number of the MI so, I think, it is used to reach the device using the serial number. @Marcel yes, the dump was done in the night, because I flashed the dongle after the work and leave it running to try to catch something... today I got a few packages, I really don´t know if it´s working as expected, but the main reason, I think, is because the DWELL for each frequency, tomorrow I will leave it on channel 1 and after I post the result here again.... last 5 bytes of the serial DTU and the nearests MI1500 DTU: 35453 MI1500: 36590 MI1500: 14456
@arnaldo_g Your nrf-research sniffing efforts are much appreciated. This certainly has the potential to be very helpful indeed. Unfortunately, there might yet be some obstacles to overcome: I noticed that the "nrf24-scanner.py" uses "promiscuous mode" (which by itself seems to be a major hack, see posts above). This should not necessarily be a problem, since we think we know the addresses of the devices involved, and can therefore listen for packets specifically addressed to these. But to make matters worse, it seems to me that the on-air bitrate is hardcoded to 2 MBit/s (https://github.com/BastilleResearch/nrf-research-firmware/blob/02b84d1c4e59c0fb98263c83b2e7c7f9863a3b93/src/radio.c#L41). The Hoymiles inverters communicate at 250 kbit/s, so until you can switch the sniffer to that lower bitrate, you won't be seeing any meaningful data.
@martin, hattest du auch schon den traffic zwischen WR und DTU "in the air" mitgeschnitten? Ich frage mich nur, ob da das 5. byte auch immer 0x01 ist wie bei der Kommunikation zwischen DTU und WR. Nicht das hier noch ein Problem liegt
@arnaldo_g Another quick note regarding addresses. You helpfully list the serial numbers of your devices: > last 5 bytes of the serial DTU and the nearests MI1500 > DTU: 35453 > MI1500: 36590 > MI1500: 14456 However, you will need the last 8 (not 5) digits to determine the address: > DTU: 35453 --> Address will be 0x53,0x54,0x?5,0x?? (,0x01) > MI1500: 36590 --> Address will be 0x90,0x65,0x?3,0x?? (,0x01) > MI1500: 14456 --> Address will be 0x56,0x44,0x?1,0x?? (,0x01)
Hi! @petersilie, you are right the datarate is wrong! Thanks for the support, I recompiled the firmware for 250K and flashed the dongle again, and now I am seeing some packets with the serial numbers of MI, see the attached file, now I think we can go forward, I know the data is update at Hoymiles every 15 minutes the last number in address is always xx:xx:xx:xx:01. The dongle with this results is far from the MI, I will take it close again. If anyone have a idea to what channel/address to scan I can provide it.
Brilliant!!! These all appear to be messages from your DTU (serial number ...70:53:54:53) to various inverters. They're all 11 Bytes long, and we're not seeing any replies. Maybe some sort of "ping"? Are your inverters running? Not sure why we think that the DTU only communicates on the given channels (1 3 6 9 11 23 40 61 75). My guess is that maybe the channels are selected based on serial number. Or maybe they are switched dynamically somehow... Maybe you could try monitoring "all" available channels? Not sure how well that will work though - since at any given moment in time you will likely be looking at the "wrong" channel!
@petersilie @arnaldo_g, if all the messages are from the DTU towards the inverter we have a new message id. In this document: https://www.mikrocontroller.net/attachment/549922/hoymiles-datenformat-r2.txt and also in martins excel the MID 0x83 was only shown as a response form the inverter towards the DTU. But now we see 0x83 also from the DTU towards the inverter. 0x82 seems to be completly new
My inverters are running, attached a new log from a closest place with more log. This is the DTU: [2022-03-12 09:17:15.329] 40 0 90:65:23:74:01 I am running a scanner on all channels, but it´s seens losting a lot of package, I will leave it running for some hours and post here after!
Thanks Arnaldo, just to clarify. In an older post you wrote, that your serial number of your DTU ends with 35453 ? > DTU: 35453 > MI1500: 36590 > MI1500: 14456 But in your last post, you wrote "90:65:23:74:01". For me there are no similarities. Would you be so kind and give us the last 8 digits of the serial number from your DTU and your Hoymiles please ? Thanks a lot for your work Marcel
Marcel, Sorry I made a mistake, is not that line, see below, you can see it in last log nrf24_4.txt file, the serial is 70535453. [2022-03-12 09:16:58.926] 23 0 53:54:53:70:01 this is another MI. [2022-03-12 09:17:15.329] 40 0 90:65:23:74:01
Angehängte Dateien:
I just wrote a small parser to analyze the data from @arnaldo_g. It's maybe easier to find some logic in the channel selection. Unfortunatly it seems that all messages from the inverters to the DTU are empty.
:
Bearbeitet durch User
Correct, the reason for this result is that arnaldo is using the scanner. This one only shows the connections between the devices. Based on the code it analyses only the first bytes of the protocol. Arnaldo (@arnaldo_g) can you use the ./nrf24-sniffer.py. I'm not quite sure about the params. Maybe ./nrf24-sniffer.py -a 90:65:23:74:01 or ./nrf24-sniffer.py -a 53:54:53:70:01 I think this should result in a more detailed output. Marcel
Yes, sure I will run! Attached is a scanner in all channells with a DWELL of 10s.
Hi all!
seens the firmware for the dongle have some hardcoded parameters, I
leaved it running for about a hour and nothing was catch by sniffer,
after I analysed the code and change another point to 250K, maybe it
need some ajusts to sniff the packages.
I also changed (in radio.c / line 388) to RATE_250K recompile and
reflashed the device, but running "./nrf24-sniffer.py -a 36:49:51:70:01"
nothing is recorded...
// 2Mbps data rate, enable RX, 16-bit CRC
configure_phy(EN_CRC | CRC0 | PRIM_RX | PWR_UP, RATE_2M, 0);
If anyone is familiar with the radio and it´s parameters can look the
code, maybe can help more!
If someone have a idea please let me know to try again....
Grasping at straws here, but you could try reversing the order of the bytes to the -a parameter:
1 | ./nrf24-sniffer.py -a 01:70:51:49:36 |
(The source code reverses them before passing them on to the underlying layer "enter_sniffer_mode()", but it appears to do no such thing when printing the results coming from there.)
Martin G. schrieb: > Grasping at straws here, but you could try reversing the order of the > bytes to the -a parameter: > >
1 | ./nrf24-sniffer.py -a 01:70:51:49:36 |
> > (The source code reverses them before passing them on to the underlying > layer "enter_sniffer_mode()", but it appears to do no such thing when > printing the results coming from there.) Martin, about a hour running and nothing was logged..... root@retropie:/home/pi/nrf-research-firmware/tools# date Sat 12 Mar 17:09:04 -03 2022 root@retropie:/home/pi/nrf-research-firmware/tools# ./nrf24-sniffer.py -a 01:70:51:49:36
Hallo um sichern zu sein, dass meine Pseudo-DTU (Arduino ProMini + nRF24L01) funzt, habe ich mir ein Testprogramm geschrieben, das den WR simuliert. FDaten kommen an, ich setzte das Bit 8 und sende an die "DTU" zurück. Und die kriegt das auch, zwar nicht bei jedem Senden, aber wenigstens kommt was an. Und ich bin sicher, dass meine Hardware funktioniert. Aber weiterhin kommt von richtigen WR aufm Gartenhaus nix. Ich vermute entweder eine spezielle Einstellung der RF24-Parameter oder eine spezielle Sequenz von Telegrammen von DTU->WR. Meine RF24-Parameter sind: Kanal 3 Speed 250000 kbps payload=27 autoAck=true adressbreite=5 Sollte doch passen, oder?
Angehängte Dateien:
-
ali-002.jpg
24 KB -
ali-001.jpg
21 KB -
ali-003.jpg
24 KB -
ali-004.jpg
25 KB -
ali-005.jpg
18 KB
Hallo, eine Frage an diejenigen, bei denen es scheinbar schon ein bischen klappt mit dem Senden / Empfangen: Welches nrF24 Modul nutzt Ihr ? Es gibt ja verschiedene ? Ich wollte mir eines bestellen. Danke. Einen schönen Sonntag wünsche ich Dir / Euch.
ich habe hier ein ali-005 @Hubi: das mit der Kanalauswahl ist sehr seltsam. Weil bzgl. der Dumps von @arnaldo_g scheinen ja alle möglichen Kanäle involviert zu sein. Wann welcher ausgewählt wird ist mir noch nicht klar.
Hallo, Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen der Beiträge durch den Kopf ging: nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are used. In nrf24_4.txt we have a lot of packages with the address of the DTU and zero payload. Could this be ACK packages from the DTU to the WR? When the WR answers, could it be, that it uses the address of the DTU? However we see only data from the DTU. Maybe the usb sniffer has a 'weak' antenna. @arnaldo_g Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, 75, 83 but put the sniffer as near as possible (minimum wall in between) to one of the MIs? @hoymiles-datenformat-r3.txt Regarding the first xlsx from martin I think []=Spekulation: 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)] 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02] VG Frank
Frank H. schrieb: > Hallo, > Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen > der Beiträge durch den Kopf ging: > > nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are > used. > In nrf24_4.txt we have a lot of packages with the address of the DTU and > zero payload. Could this be ACK packages from the DTU to the WR? > When the WR answers, could it be, that it uses the address of the DTU? > However we see only data from the DTU. Maybe the usb sniffer has a > 'weak' antenna. > @arnaldo_g > Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, > 75, 83 but put the sniffer as near as possible (minimum wall in > between) to one of the MIs? > > @hoymiles-datenformat-r3.txt > Regarding the first xlsx from martin I think []=Spekulation: > 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)] > 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 > 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02] > > VG > Frank Hi Frank, I tried the sniffer in the same place but I can´t get anything, I think the code for the sniffer have something different... The distance for the DTU is about 3 meters and for 1 MI is about 1 meter, for another MI 1,5meters and the others is about 4-5 meters.... the wall is just a thin wooden about 4-5mm..... Yes the antenna of the sniffer is tiny, it´s a logitech unify dongle, but for 250k and the frequency it´s should work nice... When using the dongle with the logitech keyboard I can go far and it´s still working.... Also I have tried some changes on scripts and code of the nrf-research-firmware but no luck, I think the sniffer is not working, maybe because the CRC, payload or another radio configuration....
Hi! More one log, I think it will not help anything, but just to see the difference, I changed the script parameters and run it, then I runned the original code.....
I agree with arnaldo_g, fh_, etc. There might well be some setting that we're missing - therefore we're not seeing the packets we expect to see. CRC and Baud Rate settings seem fine to me. Not sure what to do about the different channels. Until we figure out how the devices "hop" between channels, we will miss packets. But we should be able to see at least some. It would be interesting to see if the inverters always stay on the same channel, or if they switch channels... "martin (Gast)" seems to have the most insight into how the RF side of things work. Maybe he has some more ideas? Also, maybe the Logitech dongle isn't quite the same as an "NRF24L01+", and the nrf-research-firmware definitely has some quirks. I bought some NRF24L01+ modules and will try to interface them to a RaspberryPi. This might give better results. @arnaldo_g - do you have any NRF24L01+ modules that you could try instead of the Logitech dongle?
Hi Martin, I have a Nrf24l01 module that I buyed, and put on my drawer to wait the results, when I found this forum.... :) After that I found the nrf-research-firmware, and I found a Logitech dongle that can run it... And started with some test and put the results here... This Logitech dongle model C-U0007 seens to have a NRF24L01+ IC, but I don´t have much time to code a new firmware and try....
Another thought: Could we try to "ping" the known addresses, cycling through "all" channels? I believe the NRF24s should answer to a "ping" (empty payload) all by themselves. I should be able to try this with my NRF24s in a couple of days' time.
Hi Guys, sorry for my late reply - I have a roof reconstruction going on at home, so little time for playing with my inverter and no panels installed at the moment ;-) As I mentioned in my post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" I got good results with the NRF sniffer from yveaux. Since you have dedicated addresses and CRC checked packages, you can filter out a lot of garbage. Downside is, that you can only sniff one side of the communication (per computer - so I have to setup a second one to sniff both sides). As you can see in the wireshark screenshot, the packets are acknowledged. So ACK is on. @Arnaldo: I would limit sniffing to the channels 3/23/40/61/75 since these are approved in the FCC report and I have verified them with a spectrum analysis. see: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" My guess(!) about the channels is, that the information is redundant. That would mean, the DTU hops to every channel and transmits the same information - to have a chance of getting data even in wifi contaminated areas. So for the beginning, it should be sufficient to focus on one channel. A first glance at the RF data on channel 23 instead of 3 seems to support my guess.
Angehängte Dateien:
-
last2bytes.png
3,7 KB
Hi everyone, I started another quick test without the inverter (DTU trying to connect), to compare the serial data on the DTU with the RF packets sniffed with Wireshark. An important part in the request by the DTU seems to be coded in the last 2 Bytes before the CRC8. They alter with the time stamp, but I have no idea what they encode. Maybe some flags?
Hi, I also join the party as I'll receive soon a HM-600 inverter. I don't favour cloud services and try to keep my data in-house. Concerning the last two bytes before the CRC: Is that lower nibble of the first byte always "B"? To me it seems unlikely to put changing flags in an initial connect request which contains the same data besides the changing time stamp. IMHO it could be 1. some kind of pseudo random number (drawn from an internal µC counter) and used as a packet number. In this case the answer of the inverter should include somewhere the same number. or 2. some kind of authentication, e.g. a ciphered time value using a shared secret between the DTU and the inverter. just an idea... ;-)
or 3. Yet another CRC/"checksum"? (It changes whenever the content changes.) In that case: how is it calculated? Since it doesn't change when the source address gets swapped out by the µC, if it is some kind of checksum, it is likely only influenced by the bytes following the address information. Have we ever seen a reply from the inverter in response to a 0x80 message? That might give us some more clues.
Angehängte Dateien:
Success! Thanks, @docbmuc and @martin (Gast)! I cycled through some predefined CRC functions. Turns out our mystery bytes are the same type of CRC as used by the "Modbus" protocol, see picture. Works for all the examples in "martin" (Gast)'s SerialData_RFSniff.xlsx, and for the one I originally documented in hoymiles-datenformat-r3.txt. New revision of said document attached.
Hallo Martin, das heisst Du hast es jetzt geknackt? :-) Bin gespannt, hier wartet auch nich ein HM-1200 DTu werde ich mir keine kaufen - eher kommt der ganze Hoymiles-Schrott weg...
Amazing! Based on @petersilie info I adjusted the test program. I cannot test it at the moment (lack of sun) but the crc calculation should work as expected. Maybe it helps someone. (used libraries are also documented in the platformio.ini file) I tested the source with an ESP32
:
Bearbeitet durch User
@petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter oben [1]. Dort ist ein ESP-12F abgebildet. [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Thomas das setzen des CRC16-Polynom in Zeile 66 kann aber nicht ganz stimmen, das sind mehr als 16 bit. Und wenn ich nur 0x8005 und bei online-CRC16M Rechnern eingebe kriege ich nicht das gewünschte Ergebnis. Vllt bin ich auch etwas irritiert. Ich bin ganz g... auf deine Klarstellung und dann werde ich morgen wieder meinen ProMini bruzzeln bis er durchbrennt oder endlich eine Antwort kommt.
Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut Spitze wie sich das hier entwickelt. Auf meinem Vordach sonnt sich ein HM-600 und wartet darauf seine Daten preiszugeben. Ein NRF24-Modul ist im Zulauf, also bin ich hier auch bald bereit zum Mitspielen 😉 Mit freundlichen Grüßen Matthias
Hallo Hubi, jetzt hast du mich etwas blank erwischt :) Also in Python klappt es so:
1 | import crcmod |
2 | f = crcmod.mkCrcFun(0x18005, initCrc=0xFFFF, xorOut=0x0000) |
3 | payload = bytes((0x0B,0x00,0x62,0x09,0x04,0x94,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00)) |
4 | print(hex(f(payload))) |
Das Ergebnis ist wie erwartet: 0x229 (Wichtig ist hier, dass die kompletten 14 byte angegeben werden) Und auch hier wenn man es im Online Calculator eingibt erscheint das korrekte Ergebnis: https://crccalc.com/?crc=0B00620904940000000000000000&method=CRC-16/MODBUS&datatype=hex&outtype=0 Die 0x18005 habe ich aus der Doku von crcmod: http://crcmod.sourceforge.net/crcmod.predefined.html
:
Bearbeitet durch User
Sorry Thomas, mit 0x8005 passt es doch
Angehängte Dateien:
-
crc_modbus.png
110 KB
Hallo Martin, perfekt - damit wissen wir jetzt das komplette Anfrage-Paket. Ich habe auch nochmal ein paar Datenpakete überprüft, es passt auch für das Paket ausgehend von der DTU mit 0x11 anstatt 0x0B im ersten Byte (nach den Adressen). In den Antworten vom WR habe ich die Modbus-CRC bisher aber nicht entdecken können. Für diejenigen, die ihre CRC-Berechnungsfunktion oder weitere Pakete prüfen wollen, siehe Einstellungen für HxD im Screenshot. Thomas B. schrieb: > Maybe it helps someone. (used libraries are also documented in the > platformio.ini file) > I tested the source with an ESP32 @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. War gestern Abend aber auch nicht sicher, ob die Speisung mit Netzteil funktioniert hat - zumindest hatte der WR mal grün geblinkt... Matthias B. schrieb: > Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut > Spitze wie sich das hier entwickelt. @Matthias, ja ich bin auch begeistert, wie das hier Fahrt aufgenommen hat ;-)
Habe mit meinem Testprogramm (mit CRC16) bisher auch keinen Erfolg, es kommt einfach keine Antwort. Ich vermute, da fehlt die richtige Initialsequenz. Ein Mitschnitt der Kommunikation vom Einschalten der DTU an wäre bestimmt sehr hilfreich.
Ich habe mir jetzt auch mal diese Logitech Dongles von Arnold geholt. Ich bin mir irgendwie nicht sicher, was die NRF library raus sendet. Ich hab das Gefühl, die fügt noch was hinzu. Ich teste dann mal mit meinem ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht vorstellen, das es eine genaue Schrittfolge geben soll. Marcel
Thomas B. schrieb: > @petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um > einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter > oben [1]. Dort ist ein ESP-12F abgebildet. > > [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Du hast natürlich Recht, danke. Ich werde das anpassen.
Marcel schrieb: > [...] > Ich teste dann mal mit meinem > ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die > einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht > vorstellen, das es eine genaue Schrittfolge geben soll. Dass es eine genau einzuhaltende Reihenfolge geben soll, scheint mir auch unwahrscheinlich. Ich denke aber, der WR wird (für längere Zeit/nur) auf einem der verfügbaren Kanäle zuhören. Und vielleicht nur jede Stunde oder so den Kanal wechseln, wenn er in der Zeit nichts sinnvolles empfangen hat. Die DTU, bzw. unsere Version davon, muss also zuerst mal auf allen Kanälen ein "PING" schicken, um zu sehen, ob der WR vielleicht zufällig gerade auf diesem Kanal zuhört. Erst dann sind weitere Anfragen überhaupt sinnvoll. Die DTU scheint das nach den Logs hier im Thread ja auch so in der Art zu machen. Ich meine, im Datenblatt zum NRF24 gelesen zu haben, dass ein "0-Payload"-Paket wie ein "PING" funktioniert, d.h. die Gegenstelle wird brav mit "ACK" antworten. Vielleicht könnten wir als ersten Schritt probieren, solch einen "PING" auf die jeweils bekannte(n) Seriennummer(n) auf allen Kanälen zu programmieren? Danach stellt sich die Frage, welche Anfrage wir dann schicken sollten. Die mit der Uhrzeit ist eventuell nicht die hilfreichste - welche Antwort erwarten wir denn darauf? Wie wäre es mit der "Nachricht 0x81: DTU an WR: "Anfrage DC-Daten""? Da würde ich dann die DC-Daten als Antwort erwarten.
:
Bearbeitet durch User
Einfach anfangen klingt sinnvoll :) Ich habe auch gesehen es gibt einen Dynamic Payload Length Modus. Im Excel von martin haben wir ja verschieden lange Pakete. Das Payload control field in [1] war 0x0d8 = 11011000 Laut Kapitel 7.3.3.1 in [2] ist wird die Payload Length (6 bit lang, siehe Kapitel 7.3.3) nur verwendet wenn die Dynamic Payload Length function aktiv ist. Vielleicht ist das auch noch ein Punkt der zum Erfolg fehlt... Hätte an meinem Code das hier geändert:
1 | //radio.setPayloadSize(27);
|
2 | radio.enableDynamicPayloads(); |
[1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" [2] https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf
:
Bearbeitet durch User
Hallo, was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 Frequenzen abgeklappert werden. "Channel List 2403, 2423, 2440, 2461, 2475MHz" Nur einen Channel zu testen bringt doch nix bzw. wäre Zufall, das der WR genau da horcht. Ich kenne mich mit "C" leider nicht so aus. Ich vermisse da jedenfalls eine Schleife die alle 5 Frequenzen abcheckt. @Petersilie: Vielleicht mal die Frequenzen in r6 mit aufnehmen :-) Viele Grüße an Alle, die hier mitarbeiten.
:
Bearbeitet durch User
Herbert K. schrieb: > was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 > Frequenzen abgeklappert werden. Siehe Anhang... hatte das bei mir schonmal implementiert aber aktuell hats keine Sonne :-(
Nur zur Info: bei irgendwelchen neuen Erkenntnissen über die Kommunikation klappere ich mit meinem Testprogramm alle bekannten Kanäle ab. Bin mal gespannt wie oft ich noch bruzzeln kann, bis der uC die Krätsche macht.
Hallo, Marcel schrieb: > int channels[5] = {3, 23, 40, 61, 75}; > 35 mit diesen Kanälen hatte ich damals immer getestet und habe diese dann irgendwann mal auf int channels[9] = {1, 3, 6, 9, 11, 23, 40, 61, 75}; angepasst. Alle Informationen, die hier im Forum herausgefunden wurden, habe ich in meinem Script angepasst und immer auf diesen Kanälen getestet. Leider bisher noch kein Erfolg in Form von einem ACK oder sogar Statistiken vom WR. Marcel
Marcel schrieb: > Alle Informationen, die hier im Forum herausgefunden wurden, > habe ich in meinem Script angepasst und immer auf diesen Kanälen > getestet. Hast du die dynamicPayload auch schon getestet oder erst alle Dinge die vor heute Abend hier standen? Ich halte das aktuell für vielversprechend.
Bin zwar nicht angesprochen, aber DynamicPayload und Payload 27 (siehe Erkenntnisse irgendwo oben) probiere ich ständig abwechsenld aus.
@martin (Gast), hattest du schonmal versucht mit einem NRF24 den WR zu pollen? Falls die DTU im initialen Setup $Dinge im WR einstellt damit dieser antwortet, müsste das ja bei dir passiert sein und er sollte dann auch einem "eigenen" NRF24 antworten?
martin schrieb: > @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom > Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 > eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. Hallo Thomas. Ja, ich hatte es getestet - leider ohne Erfolg. Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und NRF24 - sobald es etwas neues gibt, melde ich mich.
Angehängte Dateien:
-
1647617263224.jpg
120 KB -
1647617263215.jpg
270 KB
martin schrieb: > Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und > NRF24 Also meine bisherigen Versuche mit eurer als auch eigener Software sind fehlgeschlagen - obwohl 2 NRFs miteinander Pingpong spielen (Funkmodul tut also). Aber was ich sagen kann, der Inverter lässt sich mit einem 24V Netzteil (nominal 2,5 A/60W) speisen und funktioniert dann auch. Das ermöglicht mir zumindest auch mal Abends zu testen. Pascal A. schrieb: > hast du noch mehr Daten zu deinem Wechselrichter? > Vielleicht sind es Daten zu Einstellungen, Firmware, .. @Pascal, hier noch die Daten, die ich dir schuldig geblieben bin -> Siehe Screenshot.
kann es vielleicht sein, daß die eigenen NRF24L01 1 Mbps statt 256kbps nutzen. Meiner jedenfalls will trotz Programmierung nach den SDR-Aufnahmen keine 256kB senden. Liegt aber evtl auch an mir ?
NRF24L01 = 1 MHz u 2 MHz NRF24L01+ = 256 K u. 1 u 2 MHz (ohne Gewähr)
Herbert K. schrieb: > NRF24L01 = 1 MHz u 2 MHz > NRF24L01+ = 256 K u. 1 u 2 MHz daran liegts dann bei mir bzw. meinen Modulen. Ich werd mir 24LE01 bestellen, wie sie verwendet werden.
Mit Interesse lese ich hier schon seit ein paar Tagen mit. Mein WR (ein HM600) kommt hoffentlich im April, die nrf24 Module sind schon da. Laut Datenblättern sieht es tatsächlich so aus, dass der nrf24L01+ die 250kbit/s kann: https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf#page24 Der nrf24L01 (ohne +) kann nur bis 1Mbit/s runter: https://www.mouser.com/datasheet/2/297/nRF24L01_Product_Specification_v2_0-9199.pdf Ich bin gespannt, wie es weiter geht und hoffe dass ich demnächst auch ordentlich mitmischen und programmieren kann sobald der WR da ist
Hallo, ich habe mir mal zwei NRFs aufgebaut und der eine sendet die Daten so, wie der WR sie eigentlich empfangen soll und wie es hier im Forum gepostet wurde. Den zweiten NRF habe ich mit einer Scanner logig beschrieben (https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183). Dieser Scanner findet auch ein paar valide Nachrichten in meinem Umfeld - aber leider nicht die, die ich mit dem anderen NRF sende. Dazu habe ich im Scanner mal nur den channel = 3 (und im while loop das channel++ auskommentiert) eingestellt und der 2. NRF sendet auch aller 140ms auf diesem Kanal. Sind wir denn sicher, das die CRC Berechnung korrekt ist (ich bin leider kein Experte in Bit Operatoren und Bit Verschiebung). Zeile, die prüft ob die CRC die empfangen wurde auch einer Berechnung stand hält befindet sich hier: https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183 Marcel
Ein anderer Ansatz: man könnte versuchen, die Firmware aus dem nRF24LE1 auszulesen. Die SPI-Schnittstelle dafür ist auf der DTU-Platine beschriftet. Sollte das Flash nicht lesegeschützt sein, könnte man sich die Initialisierung/Kommunikation mit dem RF-Kram via Disassembler ansehen. Zum Auslesen gibt es verschiedene Möglichkeiten: FTDI FT232R: https://github.com/jdelfes/nrf24le1_flasher
1 | nrf24le1_flasher --read-flash readout.bin |
RaspberryPi: https://github.com/derekstavis/nrf24le1-libbcm2835
1 | nrf24le1 show |
2 | nrf24le1 read firmware readout.bin |
Arduino: https://github.com/DeanCording/nRF24LE1_Programmer/blob/master/Read_Mainpage/Read_Mainpage.ino
Mein Wechselrichter ist angekommen!
Leider bisher ohne DTU ("Lieferschwierigkeiten" - große Hoffnungen habe
ich nicht).
Mein Testsetup besteht aus 2 RaspberryPis mit jeweils einem NRF24L01+
Modul.
Auf einem Pi läuft der "pretender", der sich wie ein WR verhalten soll.
Auf dem anderen Pi läuft der "discoverer", der nacheinander eine
Testnachricht an alle einprogrammierten Seriennummern auf allen Kanälen
sendet, und jeweils anzeigt, falls er ein ACK zurückbekommt.
Der "discoverer" findet auch brav den "pretender", auch wenn ich diesen
zwischendurch auf einen anderen Kanal wechsle.
ABER mein Wechselrichter antwortet nicht.
Das führt mich zu folgender Schlussfolgerung:
Der Auto-ACK-Modus ist Wechselrichter-seitig vermutlich doch nicht
aktiv.
Hat jemand auf der Funkschnittstelle schon mal wirkliche ACK Pakete
gesehen? Das "nACK" Bit im "PCF" sagt ja nur, ob der RF-Transceiver das
Paket bestätigen soll, sofern Auto-Ack eingeschaltet ist. Wenn das
nicht der Fall ist, wird er auch keine Bestätigung senden, egal welchen
Zustand das nACK Bit hat.
Ich habe mal ein Github-Repo für die Hoymiles-Kommunikation angefangen.
Vielleicht können wir das gemeinsam erweitern?
Mein Quellcode liegt hier: https://github.com/grindylow/ahoy
Ein zielführender nächster Schritt wäre, zu versuchen, einen 'pretender'
als weiteren Wechselrichter an eine DTU anzulernen.
Dann sollten wir sehen, welche Pakete die DTU an die entsprechende
Seriennummer schickt, und können von dort Stück für Stück die weitere
Kommunikation beobachten. Hat jemand die Möglichkeit, das
auszuprobieren?
@arnaldo_g, do you think you might be able to program your receiver to respond to the same address as one of your inverters? That way it should receive the queries from the DTU directly, without us having to guess what the sniffer tool may or may not be doing to the received packets. Also, at night, the inverters will stop replying, but traffic to the 'pretend' receiver should continue.
Hallo zusammen, ich habe hier nochmal ein paar Captures zusammengestellt, vielleicht hilft es dem Projekt ja weiter, wenn da noch jemand anderes draufschaut. Es sind .sal (Saleae Logic) Captures der seriellen Schnittstelle in der DTU. Und .pcapng (Wireshark captures) mit dem yveaux NRF24 sniffer, jeweils auf den bekannten Adressen. Interessanterweise antwortete der Inverter nur auf einem Kanal von den 3 betrachteten. Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung stellen, diese können im Universal Radio Hacker geöffnet werden. Sind aber mehrere Hundert MB groß, deshalb nur auf Anfrage. Ich vermute, dass die DTU alle Kanäle durchtestet und wenn der Inverter antwortet, diesen Kanal dann weiterhin verwendet. Kann das aber im Moment leider nicht verifizieren, da der Java Spectrum Analyzer seit dem Firmwareupdate des HackRF nicht mehr tut... Schönen Sonntag noch.
Hallo in die Runde, ich möchte eure interessante „Forschung“ nicht stören, habe aber vielleicht einen hilfreichen Hinweis: Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese zuallererst bei der Basis registrieren musste, bevor eine Kommunikation möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn man eine andere DTU verwenden wollte, musste man den WR zuerst de-registrieren und dann neu registrieren. Die Registrierung erfolgte mit der Master-ID, der Seriennummer der DTU. Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ erfolgen.
Angehängte Dateien:
martin schrieb: > Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung > stellen, diese können im Universal Radio Hacker geöffnet werden. Sind > aber mehrere Hundert MB groß, deshalb nur auf Anfrage. Hallo Martin, solche RF-Aufnahmen, z.b. als IQ-File, wären sicher am besten. Da würden ganz kurze Ausschnitte davon mit den Sendungen ja voll ausreichen. Die könnte man dann selbst demodulieren, falls nötig. Als Anhang eine demodulierte Sendung von meinen Versuchen. Ich hab da momentan kein 16-bit CRC dran. Ist dieser immer vorhanden beim Senden ? ( da die demodulierte Sendung nicht mittig liegt, hab ich eine relativ große Frequenzabweichung. Da muß ich den Quarz am NRF noch besser abgleichen) Gruß golf
:
Bearbeitet durch User
Angehängte Dateien:
-
stream.png
7,3 KB
Hallo zusammen. Ich habe auch zwei Hoymiles Modulwechselrichter und eine DTU Lite. Ich habe mir nun, inspiriert durch die bisherigen Inhalte, zwei NRF24L01+ Module besorgt und diese mit einem Arduino nano gekoppelt. Ein Modul bekommt als Adresse die Adresse der DTU, das andere die Adresse eines der Wechselrichter. Damit schneide ich den Datenverkehr zwischen DTU und Wechselrichter mit. Ich nutze dazu den yveaux NRF24 sniffer in abgewandelter Form. Zunächst ist dabei nur ein Daten Durcheinander herausgekommen. Wenn man allerdings den gelesenen Nutzdaten Stream jeweils um ein Bit nach links verschiebt, sieht das Ganze ein wenig besser aus. Meine DTU hat die Adresse 0x50908172. Die Wechselrichter haben diese Adressen: WR1 0x19461073. WR2 0x39441073. Am Beispiel eines empfangenen Rohdatenstreams wird aus:
1 | 01-6C-4A-B9-88-23-0C-B9-88-23-0C-80-80-00-80-AC-00-AE-02-55-00-AB-00-AA-82-46-00-00-5A-17 |
Beim Schieben des ganzen Streams um ein Bit nach links diese Bytefolge:
1 | 02-D8-95-*73-10-46-19-73-10-46-19*-01-00-01-01-58-01-5C-04-AA-01-56-01-55-04-8C-00-00-B4-2E |
Ab Byte 3 wird darin zweimal hintereinander die Adresse eines der Wechselrichter gesendet. Allerdings wird die Wertigkeit gedreht, aus 0x19461073 wird 73-10-46-19. Wende ich dies auf die empfangenen Streams an und formatiere es ein wenig, so tauchen an den Stellen im Stream nur die bekannten Bytefolgen der Adressen auf, allerdings in umgekehrter Reihenfolge. Siehe Anhang. Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen Seriennummern bestätigen?
Super! Tolle Mitschnitte und Erkenntnisse! Das mit dem Verschieben um 1 Bit macht Sinn, da das "Enhanced Shockburst"-Protokoll seinen Vorgänger, das "Shockburst"-Protokoll, um ein 9-bit "Packet Control Field" erweitert. Alles nach diesem "PCF" erscheint dann um ein Bit verschoben. So wie ich das verstehe, arbeitet der "Sniffer" im "normalen" Shockburst Modus, wo man dem Chip wohl beibringen kann, auch Pakete durchzuleiten, die nicht CRC-geprüft sind. Eventuell gehen allerdings dafür die letzten Bytes verloren, das würde erklären, wenn Dir am Ende die protokoll-eigene CRC fehlt. Shockburst ist wohl auf 30 Bytes beschränkt, und da gehen die 5 Adressbytes noch weg, also können 27 Byte lange Nachrichten inkl. CRC evtl. nicht mehr ganz gelesen werden. Das ist aber kein Problem, denn wenn wir so weit sind, können wir die Nachrichten ja auch im echten "Enhanced Shockburst" Modus mitlesen. Zu Deiner Nachricht: Das passt super. Mit den verschobenen Bits ergibt sich nämlich direkt die Nachricht [0x01: WR an DTU: "Aktuelle DC Daten"], siehe hoymiles-datenformat-r5.txt.
1 | 02-D8-95-*73-10-46-19-73-10-46-19*- [01-00-01-] |
2 | 01-58- 01-5C- 04-AA- |
3 | 01-56- 01-55- 04-8C- 00-00- B4- 2E xx |
Dein WR Seriennummer xxxx73104619 sieht * Auf Kanal 1: 34.4 V; 3.48 A; 119.4 W * Auf Kanal 2: 34.2 V; 3.41 A; 116.4 W Die Bedeutung der anfänglichen [01-00-01] kennen wir noch nicht genau. Die erste 01 ist vermutlich ein Befehlscode.
:
Bearbeitet durch User
Angehängte Dateien:
Oliver F. schrieb: > Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen > Seriennummern bestätigen? Hallo Oliver, ja, das sieht vertraut aus. Ich erkenne darin die bereits analysierte Paketstruktur wieder. Man sieht die Anfrage von der DTU mit der Kennung 0x15, danach das übliche 0x80 0x0B, die Unix-Zeit 0x62... Die Antwort vom Inverter beginnt mit 0x95 und enthält die Daten wie Martin G. oben schon aufgeschlüsselt hat. 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? Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden, wenn die DTU nach dem Inverter "sucht". Demnächst werde ich noch aufzeichnen was passiert, wenn der Inverter dann antwortet. Anbei noch wie von golf angemerkt eine kurze Sequenz auf Kanal 40 als IQ File zur Analyse mit dem Radio Hacker.
Angehängte Dateien:
-
NRF_Block3.JPG
180 KB -
NRF-Block_MomentanFM.JPG
88 KB
vielen Dank Martin für deine Aufnahmen. Es reicht eigentlich eine Realwandlung des IQ-Files, um die Bits abzulesen. Auch der Momentanfrequenzverlauf ist sehr sauber.
B. G. schrieb: > Auch der Momentanfrequenzverlauf ist sehr sauber. Hallo golf, mit welchem Programm hast du die Auswertung auf dem zweiten Bild gemacht? Die Bits sieht man hier viel deutlicher, als bei der Auswertung mit dem Universal Radio Hacker (URH). Durch die Verschiebung der Daten um 1 Bit wegen des 9-Bit Packet Control Fields ist auch die Hex-Ausgabe im URH nicht wirklich hilfreich. Ich hatte mir deshalb mit folgendem Excel-Template beholfen - ist natürlich Quick & Dirty, da die Bits nicht immer 100% passen, aber mir hat es definitv weitergeholfen, den Signalaufbau besser zu verstehen.
martin schrieb: > mit welchem Programm hast du die Auswertung auf dem zweiten Bild > gemacht? Hallo Martin, das ist alles von mir mal in Delphi selbst geschrieben im Programm für meinen Eigenbau-SDR. Ich hab auch einen Modulator gebaut, damit hab ich deine Aufnahme einfach wieder mit dem SDR empfangen können. Leider bringen Dir die Programme nichts ohne die Hardware dazu. Ich hab die Aufnahme erst auf 16 bit gebracht und als Wave gespeichert, da mein SDR nur 16 bits verarbeitet. Das Programm für die Complex to Realwandlung könnte ich evtl versuchen anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise demodulieren.
emhopa schrieb: > Hallo in die Runde, > > ich möchte eure interessante „Forschung“ nicht stören, habe aber > vielleicht einen hilfreichen Hinweis: > Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese > zuallererst bei der Basis registrieren musste, bevor eine Kommunikation > möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn > man eine andere DTU verwenden wollte, musste man den WR zuerst > de-registrieren und dann neu registrieren. Die Registrierung erfolgte > mit der Master-ID, der Seriennummer der DTU. > > Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ > erfolgen. So etwas dachte ich Anfangs auch. Ich mag mich täuschen, aber es sollte doch zumindest bei @martin (Gast) funktionieren, da bei ihm ja die Seriennummer der DTU schon im WR registriert sein müsste.
Liest sich wie ein Krimi. Ich drücke Euch die Daumen. Tolle Teamarbeit.
Finde ich auch! Ich drücke die Daumen. Mein DTU-loser Hoy HM-400 würde sich sehr gerne mit einem billigen Nachbau einlassen!
Angehängte Dateien:
B. G. schrieb: > Das Programm für die Complex to Realwandlung könnte ich evtl versuchen > anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise > demodulieren. Ich hab mal eine 1.Version meines Complex2Real Wandlers mit opt. Demodulation versucht, die auch die HackRF Files bearbeiten kann (.complex16s). Ich selbst habe keinen HackRF, nur meine Eigenbauten. Leider machen die aktuellen Delphi-Compiler auch aus einem kleinen Programm gleich Megabytes. Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von martin. Die Ausgabe des Programms ist immer ein Wavefile.
:
Bearbeitet durch User
Angehängte Dateien:
-
protocol.png
73 KB
B. G. schrieb: > Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten > Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von > martin. Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner Analyse-Excel.
gut daß es soweit funktioniert. bei den bei mir vorliegenden Hf-Aufnahmen sind nur Blöcke vom Inverter. sendet der DTU denn auf einer anderen Frequenz ? gibts HF-Aufnahmen oder demodulierte Sendungen vom NRF24 des DTU, die wären interessant ?
:
Bearbeitet durch User
Hallo golf, anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. Die zugehörigen seriellen Pakete und Wireshark Captures hatte ich bereits oben angehängt jeweils unter "Session 1". Wer wann auf welcher Frequenz sendet scheint momentan noch eines der größten Rätsel zu sein. Bei meinem Test am Sonntag spielte sich das meiste offenbar auf Kanal 40 ab. emhopa schrieb: > Wenn > man eine andere DTU verwenden wollte, musste man den WR zuerst > de-registrieren und dann neu registrieren. Die Registrierung erfolgte > mit der Master-ID, der Seriennummer der DTU. Ja, das kann schon sein - aber bei mir sind die beiden Teilnehmer bereits registriert. Also sollte doch theoretisch irgendwas durchkommen?
martin schrieb: > B. G. schrieb: >> Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten >> Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von >> martin. > > Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit > deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner > Analyse-Excel. Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen Auswertungen war das doch immer 0x01?
Thomas B. schrieb: > Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen > Auswertungen war das doch immer 0x01? Hallo Thomas, ja ist mir auch aufgefallen. Ebenso bei Olivers Daten: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" In den Wireshark Captures allerdings nicht, da ist Addr[0] = 0x01.
Angehängte Dateien:
martin schrieb: > anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. was mir aufgefallen ist. Da ist im Frequenzbereich noch ein 2 Inverter aktiv. Wenn ich die Samplerate mit 20 Mhz richtig interpretiert habe, dann sendet der 3 Mhz tiefer. Jpg ist Teil der auf Real gewandelten Aufnahme. sowas wie Start, $32,88,81,72,01, 011011000, $95,72,22,02,00,72,22,02,00, $01,00,01,00,E4,01,64,03,2D,00,02,00,02,00,00,00,00,3A,33,41.. wenn ich mich nicht verschaut hab. Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ?
B. G. schrieb: > Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich > darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ? Also die Pakete werden tatsächlich ein paar mal im Block so gesendet. Das ist vermutlich das automatische Retry, die Pause zwischen den Paketen beträgt ca. 1 ms. 3 MHz tiefer wäre dann Kanal 20? Ist das tatsächlich ein Signal oder kann das ein Fehler von meiner SDR-Messung sein? Das wäre natürlich ein wichtiger Hinweis, wenn der Inverter gar nicht auf den gleichen Kanälen antwortet wie die DTU...
martin schrieb: > kann das ein Fehler von meiner SDR-Messung sein? da der 2. NRF-Sender gleichzeitig (etwas verzögerter Start) mit auf der Aufnahme ist muß das so stimmen, auch die Frequenzen. Vorausgesetzt daß meine Annahme der Samplerate mit 20 Mhz stimmt. (gewandelte Realfiles haben bei meinem Programm dann immer doppelte Samplerate, da aus dem IQ-Stereo File ein Monofile wird). Aber ich hab das wohl falsch beschrieben. Es dürfte wohl so sein, daß auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz tiefer (2420 Mhz) der Inverter antwortet. Das Verhalten läßt sich bestimmt mit neuen Aufnahmen prüfen. Ob die Abweichnung der beiden Sendefrequenzen immer gleich bleibt, muß man sehen. (Ich weiss allerdings nicht, ob der HackRF irgendwas gemischt hat in diesen Bereich, da ich den nicht kenne, glaub das aber eher nicht).
:
Bearbeitet durch User
Angehängte Dateien:
-
HackRF_session1_2423MHz.png
120 KB
B. G. schrieb: > Es dürfte wohl so sein, daß > auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz > tiefer (2420 Mhz) der Inverter antwortet. Im Universal Radio Hacker (UHR) sieht es für mich so aus, als ob auf der Spektrummitte zwei Sender unterwegs wären. Einer mit stärkerem Signal (DTU, weil näher am HackRF?) und ein schwächerer (Inverter?).
Angehängte Dateien:
Hallo Daniel, das stimmt schon. Ich weiss halt nur nicht, ob das alles Aufnahmeschnipsel sind von mehreren Aufnahmen oder ob das alles am Stück auf der 2423 Mhz so statt gefunden hat. Das sind ja immmer nur kleine Teilstücke. Das kann nur Martin beantworten. Da wäre evtl so ein Bild eines Sonogramms einer Aufnahme aussgefähiger ohne ausgeschnittene Stellen.
:
Bearbeitet durch User
Angehängte Dateien:
Da wäre z.b. ein Sonagrammbild des ganzen Ablaufs ( der Aufnahme ) evtl aussagefähiger ohne die Aussetzer. Oder nimmt der HackRF squelchgesteuert auf oder sowas ? Ich lass bei mir immer die Aufnahmen durchlaufen (geht theoretisch bis die platte voll ist) ohne Sampleverluste. Hab hier nur keine DTU-Signale. Nachtrag: doppelt gesendet, das ist was schief gelaufen bei mir
:
Bearbeitet durch User
@martin (Gast) - könntest Du vielleicht die großen Originalcaptures bei einem Filesharing-Dienst hochladen? Wetransfer kann zum Beispiel kostenlos bis 2 GB. https://filetransfer.io/ wohl bis zu 6 GB.
Hallo Martin, golf und Daniel, leider war mein Studienschwerpunkt Automatisierungstechnik, deshalb bin ich bei den HF-Themen nicht ganz so fit - was heißt Squelch? ;-) Anbei die 3 Mitschnitte bei 3, 23 und 40 MHz als komplette Files (zeitgleich aufgenommen wie die Logic und Wireshark Captures). https://filetransfer.io/data-package/1Z2bKt05#link Samplerate und Bandbreite je 20M (samples/s bzw. Hz). In der RF-Aufnahme ist viel Mist dazwischen, weil Inverter und DTU ja offensichtlich immer zwischen den Kanälen hin und her wechseln und halt unvermeidlich WLAN oder sonst was in der Gegend rumfunkt. Kann das "Doppelbild" daher kommen, dass ich gleichzeitig zwei Arduino/NRF24 Sniffer mitlaufen habe lassen? Theoretisch müssten diese doch rein passiv zuhören, oder?
Angehängte Dateien:
-
test_setup.png
31 KB
Hier zum besseren Verständnis noch ein Bild, wie bzw. was ich gemessen hatte mit allen Teilnehmern. 3 Versuche auf den jeweiligen Frequenzen (2403, 2423 und 2440 MHz).
Angehängte Dateien:
-
HackRF_0_2403_Mhz__NRFs_auf_ca_2403_Mhz___mehr_als_2_Umtastfrequenzen_erkennbar.JPG
65 KB -
HackRF_0_2403_Mhz_2_NRFs_auf_ca_2403_Mhz_und_ca_2402_Mhz.JPG
52 KB -
HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG
79 KB -
HackRF_1_2423Mhz_2_NRFs_auf_ca_2423_Mhz_und_ca_2420_Mhz.JPG
74 KB -
HackRF_2_2440Mhz_2_NRFs_auf_ca_2441_Mhz_und_ca_2443_2_Mhz.JPG
75 KB -
HackRF_2_2440Mhz__NRFs_auf_ca_2441_Mhz__2441_5_und_ca_2443_Mhz.JPG
66 KB -
HackRF_2_2440Mhz__1_NRFs_auf_ca_2441_Mhz.JPG
68 KB -
HackRF_2_2440Mhz__1_NRFs_auf_ca_2443_Mhz.JPG
72 KB -
HackRF_2_2440Mhz_2_NRFs_auf_ca_2441_Mhz_und_ca_2443_Mhz.JPG
77 KB
hallo martin, squelchgesteuerte Aufnahmen nehmen nur auf, wenn ein bestimmter Empfangspegel überschritten wird. Aber bei dem HackRF kann das Verhalten auch durch die 8-bit bedingt sein, das sind jedenfalls für mich teils recht ungewöhliche Aufnahmen. Es gibt NRFs mit teils sehr unterschiedlichen Pegeln, dann bricht die Aufnahme teils abrupt ab. Das sind Aussetzer, weil der PC mit der Datenrate überfordert ist. Die 40 MB/sec sind halt ziemlich das Maximum für USB2, was geht. Evtl zur Sicherheit mal bei weiteren Aufnahmne die Sniffer-NRFs aus lassen. Bei kurzer Durchsicht gab es mehrere Stellen mit verschiedenen Frequenzlagen. bei der 2403 wurde teilweise fast auf der gleichen Frequenz gesendet. Dann sieht man scheinbar mehr als 2 Umtastfrequenzen. Siehe Bilder bei dem HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG sind wohl auch 2 NRFs fast auf der gleichen Frequenz. Scheinbar auch mehr als 2 Umtastfrequenzen. Muß näher untersucht werden
:
Bearbeitet durch User
Angehängte Dateien:
die unterchiedlichen Pegel der einzelnen NRFs verwundern etwas.
Angehängte Dateien:
Beim Überfliegen der Aufnahmen mit "inspectrum" (zum Öffnen: *.complex16s in *.cs8 umbenennen) ist mir angehängter Abschnitt aufgefallen. Zwei verschiedene Sender? Ein Paket mit Länge 27 und cmd=0x95 (-> Inverterdaten) und das andere ein 0-Byte-Paket - ist das ein ACK? Vielleicht vom Sniffer-NRF?
Angehängte Dateien:
Ich meine auch, daß da diese Sniffer vielleicht mitmischen. Anbei eine grobe Darstellung der Blöcke auf den Frequenzen mit diversen Pegeln. Ob die Blöcke von DTU/INV oder teilweise von den Sniffern sind ? Bei den beschriebenen Blöcken mit mehr als 2 Frequenzen scheint der Sender irgendwie instabil, sieht eher nicht nach 2 NRFs aus. Vielleicht sollten wir auf eine neue Aufnahme warten ohne die Sniffer-NRFs.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, leider habe ich keine DTU um mitzumischen. Warum versteift Ihr Euch so auf den HF Teil ? Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation zwischen dem GD... und dem nRF ? Einen Logic Analyzer da dran, der gleich die Kommunikation dort decodiert ? Mann müsste vielleicht mal alles in den Werkszustand versetzen. Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA loslaufen lassen. Wer weiss, ob die ganzen Register vom nRF überhaupt schon zu dem passen, was hier durch obige Programme und LIBs gemacht wird ? Vielleicht ist es nur 1 Bit in irgendeinem Register, was noch nicht passt ? Ist nur so eine Überlegung von mir. Ich will niemanden einen Vorwurf machen (falls sich jemand auf den Schlips getreten fühlt) ! ! ! ! Danke an alle, die schon eine DTU haben und Ihr Bestes geben ! ! ! Foto ist von (C)Martin. Nur die Aufmerksamkeit.
Herbert K. schrieb: > Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation > zwischen dem GD... und dem nRF ? Das wird schon so gemacht, siehe weiter oben. Aber der verwendete NRF ist nicht nur ein Transmitter, sondern auch ein Mikrocontroller. Die Kommunikation zwischen GD und NRF lässt deswegen nicht direkt auf das HF-Geschehen schließen. Was aber noch nicht versucht wurde: versuchen, ob der Flash vom NRF auslesbar ist. Siehe meinen Vorschlag: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Herbert K. schrieb: > Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA > loslaufen lassen. Ich schlage vor, kurz vor der Stromversorgung des DTUs jeweils HF-Aufnahmen zu starten. Evtl auch mit etwas weniger Samplerate, damit es weniger Aussetzer gibt. Nach ein paar Aufnahmeversuchen müßte man zumindest die Start-Sequenz(en) des DTU finden können. Vielleicht kommt man dann etwas weiter. Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?
:
Bearbeitet durch User
Gute Idee! Und am besten auch mal ohne die Sniffer-NRFs, nicht dass wir uns mit deren ACKs oder dergleichen verrennen.
B. G. schrieb: > Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ? Hallo golf, ja, tatsächlich sind die so entstanden, zumindest was die DTU betrifft und die Kanäle 3 und 23. Man sieht das auch gut an den seriellen Aufnahmen. Die UART-Pegel sind zunächst auf Low, gehen dann auf High und dann kommt die Initialisierung des NRF24LE1E (3x Request/Response). Danach beginnt das Suchen nach Invertern. Kanal 40 habe ich dann im laufenden Betrieb aufgenommen, nachdem ich gemerkt hatte, dass da mehr los war. Bei allen Versuchen war der Inverter vorher schon an, da er immer eine Weile braucht bis er initialisiert ist.
Angehängte Dateien:
Hallo zusammen. Eine Frage an alle die hier fleißig die HF Daten analysieren. Ich habe, wie bereits gesagt, auch einen NRF24 Sniffer am Laufen. Leider kann dieser nur auf die eingestellten Adressen lauschen. Der Chip unterstützt mehrere Datapipes. (Siehe Anhang) Ich denke, die WR werden eine Datapipe betreiben, mit deren Seriennummer als Adresse. Es muss aber noch eine andere Pipe geben mit einer Art Broadcast Adresse, die für alle WR gleich ist?!? Ich komme darauf, weil ich mehrmals den Hochlauf der DTU gesnifft habe. Sinnvolle Kommunikation sehe ich nur auf den Kanälen 3, 23 und 40, wobei die DTU auf Kanal 40 sehr selten vertreten ist. In diesem Beispiel ist es so, dass die Wechselrichter (C1) auf einmal anfangen zu senden, ohne dass zuvor ein Telegramm von der DTU an die Wechselrichter (C3) zu sehen ist. Ich habe das ganze relativ häufig auf den einschlägigen Kanälen probiert. In der Regel sind die ersten Telegramme immer WR=>DTU, ohne dass ich eine initiale Aktion der DTU sehe. Die Bedeutung der einzelnen Spalten habe ich versucht im Anhang zu dokumentieren.
1 | C1 026566496 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
2 | C1 026570128 00 0590817201 0006 00 3 EA5A EA5A |
3 | C1 026573400 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
4 | C1 026595440 00 0590817201 0000 00 0 8A9C 8A9C |
5 | C1 026597740 00 0590817201 0002 00 1 AADE AADE |
6 | C1 026613740 00 0590817201 00B8 17 0 95 73104439 73104439 83000000F303E80185000581B4BA142F 142F 1 |
7 | C1 027707212 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
8 | C1 027713144 00 0590817201 0006 00 3 EA5A EA5A |
9 | C1 027716424 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
10 | C1 027740752 00 0590817201 0000 00 0 8A9C 8A9C |
11 | C1 027756120 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
12 | C1 027764348 00 0590817201 0002 00 1 AADE AADE |
13 | C1 027767624 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
14 | C1 029551548 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
15 | C1 029557480 00 0590817201 0006 00 3 EA5A EA5A |
16 | C1 029560760 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
17 | C1 029585088 00 0590817201 0000 00 0 8A9C 8A9C |
18 | C1 029601636 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
19 | C1 029609864 00 0590817201 0002 00 1 AADE AADE |
20 | C1 029613140 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
21 | C1 029635176 00 0590817201 0004 00 2 CA18 CA18 |
22 | C1 029637480 00 0590817201 0006 00 3 EA5A EA5A |
23 | C1 034225220 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
24 | C1 034235752 00 0590817201 0006 00 3 EA5A EA5A |
25 | C1 034239032 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
26 | C1 034261072 00 0590817201 0000 00 0 8A9C 8A9C |
27 | C1 035451152 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
28 | C1 035457080 00 0590817201 0006 00 3 EA5A EA5A |
29 | C1 035460360 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
30 | C1 035482388 00 0590817201 0000 00 0 8A9C 8A9C |
31 | C1 035484696 00 0590817201 0002 00 1 AADE AADE |
32 | C1 035500772 00 0590817201 00BC 17 2 95 73104619 73104619 83000500F603E8018300213960F485BA 85BA 1 |
33 | C1 035995516 00 0590817201 00D8 1B 0 95 73104439 73104439 010001014803A70BF5014803AC0C0600006AEB1C EB1C 1 |
34 | C1 036029056 00 0590817201 0004 00 2 CA18 CA18 |
35 | C1 036044500 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
36 | C1 036055028 00 0590817201 0006 00 3 EA5A EA5A |
37 | C1 036058312 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
38 | C1 036080352 00 0590817201 0000 00 0 8A9C 8A9C |
39 | C3 037978808 00 1946107301 00DE 1B 3 15 73104619 72819005 801200623DA4AB000000000000000098C8DD09E3 09E3 1 |
Ist Euch bei der Analyse der HF Daten schon mal eine andere Adresse aufgefallen?
:
Bearbeitet durch User
Hallo Oliver, Danke für Deine Logs. Ich habe dazu wiederum ein paar Fragen/Anmerkungen: (1) Nach meinem Verständnis kann der NRF24 zwar von bis zu 6 "Pipes" = "Adressen" empfangen, aber nur Pipe 0 ist unabhängig, Pipe 1-5 teilen sich die ersten 4 Bytes, d.h. dürfen sich nur im letzten Byte unterscheiden (siehe Kapitel 7.7 "Multiceiver"). Das würde erklären, warum Du nur Nachrichten von C1 und C3 siehst. (2) In Deinen Mitschnitten tauchen auch wieder diese 0-Byte Payload Pakete auf. Laut Datenblatt sind das ACK-Pakete, die der Chip automatisch sendet, wenn er auf der jeweiligen Adresse etwas empfangen hat. Ich meine, bisher sieht es so aus, als sei diese ACK Funktion bei den Hoymiles Geräten deaktiviert. Wir sollten diese auf jeden Fall bei jeglichen Sniffern auch deaktivieren (setAutoAck(false)), sonst greifen die ja aktiv in den Funkverkehr ein. Vielleicht kommt da auch manche der Verwirrung weiter oben her - denn die Adresse dieser ACK-Pakete ist ja jeweils gleich der Adresse des ursprünglich empfangenen Pakets. (3) Bzgl. Deiner Frage wegen anderer Adressen - ich meine, martin (Gast) hatte auch schon einmal Adressen beobachtet, die in 0x00 (anstatt 0x01) enden. Als "Broadcast" zwischen allen WR würde das aber nicht wirklich taugen, hierzu würde sich vielleicht am ehesten die DTU Adresse eignen. Vielleicht gibt es bei Inbetriebnahme auch Broadcasts an 0x0000000000 oder so - auf uC-Seite scheinen manche Pakete solch eine Adresse zu enthalten. -- Petersilie
Angehängte Dateien:
Hallo Martin. Also ich habe jetzt mal etwas mit dem RF25L01+ Chip experimentiert. So ganz bin ich noch nicht dahinter gestiegen wie er funktioniert. Es ist sicherlich irgend so ein ASIC der als Schrittschaltwerk funktioniert ohne abhängige Logic, bzw. ohne die eingestellten Parameter zu prüfen. Er macht etwas in Abhängigkeit der eingestellten Register. Es kann schon mal sein, dass er völlig durcheinander ist und nur ein Spannungsreset hilft. So meine Beobachtung. Zu Deinen Fragen/Anmerkungen: (1) So wie ich es verstehe besteht die Möglicheit, dass die Adressen von Pipe 0 und Pipe 1 5 Byte lang sind. Pipe 2-5 betrachte ich nicht, diese hängen natürlich von den restlichen Bytes der Pipe 1 ab. Ich habe die Pipes auf die beiden Wechselrichter programmiert:
1 | pipe 0 ( open ) bound = 0x3944107301 |
2 | pipe 1 ( open ) bound = 0x1946107301 |
3 | pipe 2 (closed) bound = 0xc3 |
4 | pipe 3 (closed) bound = 0xc4 |
5 | pipe 4 (closed) bound = 0xc5 |
6 | pipe 5 (closed) bound = 0xc6 |
Im Log werden die Einträge von C2 nicht angezeigt, weil die Abfrage der Pipe im Interrupt aus irgendeinem Grund nicht funktioniert. Darum stimmt die im Adurino generierte Prüfsumme nicht. Die Telegramme werden aber erfasst, jedoch der Pipe 1 zugeordnet, obwohl sie zu Pipe 0 gehören. Hier ein Beispiel, gehört eigentlich zu Pipe 0, die Abfrage
1 | radio2.available(&pipe) |
liefert aber Pipe 1, darum wird das Telegramm C3 zugeordnet und anschließend wegen falscher Prüfsumme (Die Berechnung legt die Adresse WR2 zugrunde) verworfen. In den Nutzdaten sieht man aber, dass das Telegramm eigentlich für 73104439 bestimmt ist.
1 | C3 019634660 00 1946107301 00DE 1B 3 15 73104439 72819005 800B00623DD84B00000005000000009117A9035D 1565 0 |
(2) Was Du sagst ist absolut richtig, aber wenn dann ist es in der RF24 Dokumentation missverständlich beschrieben. Die AutoAck Funktion ist bei allen "Sniffern" deaktiviert. Darum sollten die nicht für die Ack Frames verantwortlich sein. Die ACK Frames die ich sehe sind auch immer an die Adresse der DTU gerichtet. Meine RF24 sind so eingestellt, dass die TX_ADR auf Default steht:
1 | TX_ADDR = 0xe7e7e7e7e7 |
Das Datenblatt sagt ja, dass für die AutoAck Funktion TX und RX Addr. gleich sein müssen.
1 | TX5 device: TX_ADDR = 0xB3B4B5B605 |
2 | TX5 device: RX_ADDR_P0 = 0xB3B4B5B605 |
3 | RX device: RX_ADDR_P5 = 0xB3B4B5B605 |
Muss man sicherlich noch weiter hinterfragen. (3) Als Ursache für die Adressen die mit 0x00 enden habe ich für mich den yveaux Sniffer ausgemacht. (Gut wenn man einen Schuldigen hat). Dieser stellt im RF 24 immer fest eine Adressbreite von 4 Byte ein (Bzw. Parametrierte Adressbreite - 1).
1 | #define DEFAULT_RF_ADDR_PROMISC_WIDTH (DEFAULT_RF_ADDR_WIDTH-1)
|
Das fehlende 0x01 in der Adresse wird dann schon der Payload zugeordnet. Dies ist der Grund, warum ich in älteren Aufzeichnungen immer ein Bit vor dem 9-bit PCF hatte. (Siehe Anhang) Die 0x02 ist die 0x01 in Byte 5 der Adresse. 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 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 Turn unit on: C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 Turn unit off: C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 Turn unit on: C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1
:
Bearbeitet durch User
Angehängte Dateien:
Ich möchte gerne einen kleinen Teilerfolg vermelden. Ich kann meine WR ohne die DTU abfragen und erhalte sporadisch Antworten. Ein Muster erkenne ich noch nicht. Bisher kann ich meinen Aufbau nur mit RF24_PA_LOW betreiben. Aber die Sendeleistung reicht um die 30m entfernten WR zu erreichen. Beim Senden meldet sich bei einer höheren Sendeleistung immer der CH340 Chip USB zum Rechner ab. Zunächst ging sogar nur RF24_PA_MIN, bis ich die 3.3V zum RF Modul mit einem 100uF Elko gestützt habe. Die DTU Radio ID in dem Code kann ich beliebig ändern, die WR antworten dann auf die neue DTU ID. Als Anpassung sollte es reichen, die DTU Radio Ids zu ändern. Bei nur einem WR zunächst irgendeine Dummy Adresse verwenden oder diese belassen.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Die Wechselrichter scheinen irgendeinen proprietären Mechanismus bei dem Channel hopping zu verwenden. Den habe ich noch nicht verstanden. Der Trick ist, auf einer anderen Adresse zu empfangen als zu senden und beim Senden bis die maximale Retransmit rate mit 2ms Pause zu verwenden. Zur Zeit verwende ich die Kanäle 3 und 40. Auf einigen anderen Kanälen geht bei mir gar nichts, vermutlich wegen meinem WLAN. Muss man evtl. in jeder spezifischen Umgebung ausprobieren. Versucht habe ich es mit einer Kombination aus den bereits weiter oben erwähnten Kanälen:
1 | int channels[] = {3, 23, 40, 61, 75}; |
1 | #define DEFAULT_RECV_CHANNEL (3) // 3 = Default channel for Hoymiles
|
2 | #define DEFAULT_SEND_CHANNEL (40) // 40 = Default channel for Hoymiles
|
Kann dies jemand bei sich nachvollziehen? Oder liegt es bei mir daran, dass die WR schon mal mit der DTU kommuniziert haben und dadurch noch irgendeine Konfiguration haben? Bei Fragen oder Problemen einfach melden.
:
Bearbeitet durch User
Hallo Oliver, was genau wird bei dir zur Anforderung an den WR gesendet ? Vielleicht sende ich da was falsches. Bisher bei mir ohne Erfolg. Ich hab 14 retransmits eingschalten, hab auf jeder Megahertz - Frequenz 2400 - 2525 Mhz gesendet. Der WR hat nirgends geantwortet. Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, daß er irgendwo antwortet. Dann könnte ich immer noch mit Aufnahmen feststellen, wo. (Die Messung mit dem AD8318 funktioniert einwandfrei, wenn ich den an meinen NRF dran stelle.) Evtl fehlt dann doch irgendeine Grundinitialisierung an den WR, daß er was tut oder ich sende Schrott.
B. G. schrieb: > > was genau wird bei dir zur Anforderung an den WR gesendet ? > Hallo B.G. Der Quelltext ist dem Beitrag angehängt. Ich sende alle 200ms ein Telegramm an meine beiden Wechselrichter. Sie antworten nicht jedes mal, sondern gefühlt jedes 4-5 Mal. Ich denke das hat mit dem noch nicht durchschauten Channel Hopping zu tun. Es wird nacheinander auf CH40 das 0x80 Telegramm mit einer simulierten Unix Zeit gesendet, da ich auf dem nano keine Echtzeituhr habe. Das scheint dem WR aber egal zu sein. Dann das 0x81, 0x80, 0x83, 0xFF Telegramm, wie von Martin in der Protokollbeschreibung angegeben. Danke an Martin das ist sehr hilfreich. Nach dem Senden wird direkt wieder auf CH3 umgeschaltet und gehorcht.
1 | if (tel > 4) |
2 | tel = 0; |
3 | if (tel == 0) |
4 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
5 | else if (tel == 1) |
6 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x81); |
7 | else if (tel == 2) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x80); |
9 | else if (tel == 3) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
11 | else if (tel == 4) |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0xFF); |
13 | |
14 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
15 | |
16 | toggle = !toggle; |
17 | if (!toggle) |
18 | tel++; |
Ein Dump mit Ausgabe von Send und Receive ist angehängt. Die Zeilen mit diesem Inhalt sind dabei die vom WR empfangenen Daten.
1 | 048491820 00 1234567801 00DC 1B 2 95 73104619 73104619 010001014F027908470150026D08220000FB9CDF 9CDF 1 |
2 | 048540572 00 1234567801 00DE 1B 3 95 73104619 73104619 02FE300000F91307790762096413840FADF0AB62 AB62 1 |
"Send..." ist jeweils ein Send auf CH40. PL die Payload, WR1/2 gibt an an welche Adresse. Die 0 danach ist der Rückgabewert vom Write, da ja kein ACK von den WR kommt. Dann die millis() Zeit des Nano und die Dauer des Sendens in millis().
1 | Send... CH40 PL: 1573104439785634128182 WR2 0 48677140 29204 |
2 | Send... CH40 PL: 15731046197856341281A0 WR1 0 48877844 29204 |
:
Bearbeitet durch User
vielen Dank, wenn es jemand gibt, der Erfolg mit dem zurücklesen hat, ohne eigene DTU zu besitzen, dann bitte melden. bei martin müßte es ja evtl jetzt so funktionieren ?
Hallo @golf2010 und @of22, das ist tolle Arbeit. Muss man erst mal drauf kommen! Hoffentlich komme ich morgen dazu, das mit meinem Raspi-Setup auszuprobieren. Können wir eventuell noch weiter einschränken, welche Nachrichten wirklich notwendig sind? (1) @of22, Du wechselst zwischen den 5 Pakettypen im Kreis herum - hast Du mal probiert, ob weniger eventuell immernoch zum Erfolg führen? (2) Und habe ich das richtig verstanden, du hörst immer auf Kanal 3? D.h. angenommen, Du würdest nach dem Senden auf Kanal 40 bleiben, dann würdest Du nichts empfangen? (3) Und noch ne ganz ketzerische Frage: wenn Du garnichts sendest und nur auf Kanal 3 zuhörst, empfängst Du aber nie irgendwelche Nachrichten, oder doch?
Hallo Martin G. (1) Habe ich versucht nur das 0x80 mit dem Unix Timestamp zu senden, das reicht aus. Aber dann kommt nur der 01 00 01 Response. Mit den anderen zwischendurch kommt auch mal ganz selten eine andere Antwort. Ich hatte schon versucht mir die Saleae Captures von martin (Gast) 20.03.2022 13:37 anzusehen, um hier vielleicht anhand der Serial Captures ableiten zu können welche Requests erforderlich sind. Könnte man die vielleicht als ASCII Dump oder so zur Verfügung stellen? Ich habe kein Saleae und so wie ich es veerstehe gibt es keine Stand Alone Version der Software. (2) Das ist richtig, so ist meine Beobachtung. Gesendet und Empfangen wird immer auf einem unterschliedlichen Kanal. Bleibe ich auf dem Sendekanal, egal ob 40 oder 3, empfange ich keinen Response. (3) Nein, wenn ich aufhöre zu senden kommen keine Responses vom WR mehr. Er muss immer durch irgendein Telegramm getriggert werden.
:
Bearbeitet durch User
Hallo @of22, habe mir die Hardware mit dem Nano aufgebaut. Kommunikation mit dem NRF24 scheint zu tun. Also Register usw. werden ausgelesen. Nur kurz 2 Fragen bevor ich hier tiefer in den Code einsteige. 1. Muss die Seriennummer des WR auch Rückwärts angegeben werden? 2. Wie funktioniert das Menü? Wird gleich nach dem Startup schon gesendet oder muss man das Senden zuerst über die Serielle Konsole starten? Danke & Grüße Thomas
Angehängte Dateien:
-
ali-001.jpg
21 KB -
ali-005.jpg
18 KB
Hallo Thomas. Die Seriennummer muss in dem define umgekehrt angegeben werden. An meinem Beispiel: WR1 = xxxx73104619 WR2 = xxxx73104439 Und im Byte 5 der Adresse die 01 nicht vergessen. Die Adresse der DTU ist egal, da Du sie ja simulierts.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Das Menü ist erst einmal uninteressant. Der Code fängt direkt an zu senden. Es waren nur Tests um die Kommunikation auf einzelne Telegramme einzuschränken. Eine Anmerkung noch: Eventuell muss der Sendelevel angepasst werden. Ich habe die Module ali-005 mit externer Antenne im Einsatz. Damit komme ich nicht über PA_LOW sonst hängt sich etwas auf (CH340), oder ich bekomme keine Antworten. Vorhin habe ich es noch die ali-001 ausporbiert. Damit muss ich höher gehen auf PA_HIGH sonst bekomme ich keine Antwort von den ca. 30 m entfernten Wechselrichtern durch zwei Wände. Aber auch mit denen kann ich nicht auf PA_MAX gehen sonst kommt wiederum keine Antwort.
1 | radio1.setPALevel(RF24_PA_HIGH); |
Und dran denken, jetzt ist dunkel. Da kommt nichts mehr, weil der WR aus dem DC Kreis versorgt wird.
:
Bearbeitet durch User
Hallo Oliver, alles klar danke! Habe hier auch den ali-005. Habe aber schon einen 10uF angelötet. Werde es erstmal mit LOW versuchen und mich notfalls mit dem Laptop raus stellen. Ich bin ja sooo gespannt. Jetzt wenn schon Sonne vorhanden wäre :) Grüße Thomas
Angehängte Dateien:
B. G. schrieb: > Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen > und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, > daß er irgendwo antwortet. Ich hab tagelang völlig unnötig rumprobiert. Da war bei mir nur ein Zahlendreher in meiner eingegebenen WR-Seriennummer. Nachdem ich den heute Nacht gesehen hab, hat der WR heute morgen sofort geantwortet auf ein 80 Paket. Also brauchst doch keine extra Initialisierung. Anbei der Ausgang von meinem Pegelmesser AD8318, am Oszi angeschlossen. Ich muß jetzt schauen, wo er antwortet.
Angehängte Dateien:
B. G. schrieb: > Ich muß jetzt schauen, wo er antwortet. auf 2403 kam der gerade. auf der 2405 gibts hier noch einen weiteren NRF, wohl ein Nachbar. Der auf 2405 kommt etwas stärker rein.
:
Bearbeitet durch User
Hallo B.G. dein Testprogramm funzt einwandfrei. Es werden zwar nicht alle Anfragen beantwortet, aber so alle 1 - 2 Sekunden kriegt man Daten. Und das ist doch schon was.
Hallo Hubi, das Programm ist von Oliver. Ich kann kein C, nur Pascal(Avrco) und Delphi.
Hallo, kann es auch bestätigen. Daten werden empfangen. Ich kann auch bestätigen das es mit > RF24_PA_HIGH nicht funktioniert. Zumindest wenn ich den NRF24 via USB betreibe. Am Labornetzteil tut es.
Angehängte Dateien:
Hallo, das freut mich zu hören, dass es auch bei anderen klappt. Das man nicht jedes Mal eine Antwort erhält, liegt an dem noch nicht durchschauten Channel Hopping. Ich habe mal noch ein paar Sachen zum Nachdenken, wer möchte, kann sich gerne beteiligen. Ich habe meiner DTU und einem WR nochmal bei der Kommunikation mit diesem Aufbau zugehört: Zwei RF24 Chips. Einer lauscht auf Kanal x und der andere auf x + 40, jeweils für 60 s. Dann wird x inkrementiert von 0 bis 39. Dabei heraus gekommen ist diese Statistik. Das ist sicherlich eine Momentaufnahme, die sich aus meinem WLAN Umfeld und aus anderen Störern ergibt. Auch sind bei den Frames WR=>DTU die Antworten von dem zweiten Wechselrichter, dessen DTU Anfragen nicht geloggt werden, das könnte das Bild verfälschen. Kommunikation läuft auf mehr als den bisher angenommenen Kanälen, wobei es bei den Kanälen 7, 8, 9 auch ein Übersprechen sein könnte. WR an DTU sind am häufigsten auf Kanal 3 und 23 vertreten. DTU an WR springt lustig durch die anderen Kanäle, wobei 0, 7, 9, 23, 27, 35, und 40 die Spitzenreiter sind. Als Kommandos DTU=>WR sieht man die Ids 0x80, 0x81, 0x82, 0xFF.
1 | Kanal | Frames | DTU=>WR | WR=>DTU | 0x80 | 0x81 | 0x82 | 0xFF |
2 | ------+--------+---------+---------+------+------+------+------ |
3 | 0 | 11 | 11 | 0 | 5 | 0 | 0 | 6 |
4 | 3 | 81 | 8 | 73 | 5 | 4 | 1 | 2 |
5 | 7 | 10 | 10 | 0 | 8 | 0 | 0 | 2 |
6 | 8 | 3 | 3 | 0 | 2 | 0 | 1 | 0 |
7 | 9 | 12 | 12 | 0 | 9 | 0 | 3 | 0 |
8 | 11 | 9 | 9 | 0 | 8 | 0 | 1 | 0 |
9 | 14 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
10 | 20 | 3 | 3 | 0 | 2 | 0 | 0 | 1 |
11 | 23 | 59 | 12 | 47 | 7 | 1 | 4 | 1 |
12 | 27 | 13 | 13 | 0 | 9 | 1 | 1 | 2 |
13 | 29 | 8 | 8 | 0 | 4 | 0 | 3 | 1 |
14 | 35 | 11 | 11 | 0 | 5 | 2 | 1 | 3 |
15 | 37 | 8 | 8 | 0 | 6 | 0 | 2 | 0 |
16 | 39 | 8 | 8 | 0 | 5 | 0 | 2 | 1 |
17 | 40 | 10 | 10 | 0 | 6 | 0 | 1 | 3 |
18 | 61 | 13 | 9 | 4 | 6 | 0 | 2 | 1 |
19 | 75 | 8 | 3 | 5 | 2 | 1 | 0 | 0 |
Woher weiß die DTU, auf welchem Kanal der WR lauscht? Und woher weiß sie, auf welchem Kanal die Antwort vom WR kommt? So aus einem Bauchgefühl heraus: Könnte das 0xFF Telegramm die Aufforderung zum Kanalwechsel sein, aber wohin? Bei dem 0x80 Telegramm sehe ich im Byte hinter der 0x80 die Bytes 0x0B oder 0x11 (Siehe Screenshot). Die Bedeutung erschließt sich mir noch nicht. Beigefügt der Dump aus dem Minuten Scan als Rohdump und aufbereitete Excel.
:
Bearbeitet durch User
Hallo, es geht voran, aber nicht so direkt Beteilige verlieren den Überblick. So auch ich. Kann bitte jemand einmal kurz und knackig die benötigte Hardware skizzieren und die Software mit Sourcecode bereitstellen? Dann kann jeder Homiles Nutzer sich schnell zurechtfinden. Danke
@of22: Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen Uhrzeit stehen?
Bezugnehmend auf Sorbit (Gast) würde ich gerne https://github.com/grindylow/ahoy als Sammelstelle vorschlagen. Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf das Repository geben. @Sorbit, ich glaube, so hundertprozentig "einstecken und tut"-Lösungen haben wir noch nicht - jeder hat leicht andere Hard- und Software, aber gerade deshalb geht es erstaunlich voran! Aber Du hast natürlich Recht, ich denke wir haben alle ein Interesse daran, dass das ganze früher oder später einfach(er) nachzuvollziehen und zu nutzen wird.
Angehängte Dateien:
Martin G. schrieb: > @of22: > Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen > Uhrzeit stehen? Hallo Martin, gute Idee, das ist ja fast das Einzige was sich in den Telegrammen ändert. Beziehe ich in meine Grübeleien ein. > Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf > das Repository geben. Bisher ist das Ganze ja nur ein zusammengeklopptes Testprogramm. z.B. könnte man die CRC Generierung auf eine Bibliothek umstellen. https://github.com/RobTillaart/CRC oder so. Auch wird im Testprogramm Kanal 40 zum Senden und 3 zum Empfangen verwendet. Die Statistik oben zeigt ja, dass man auch auf 23 lauschen müsste und auf anderen senden. Aber Du kannst gerne den jetzigen Stand hochladen. @ Sorbit (Gast): Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in China bestellt hatte. Ich mag die Atmel Dinger aber ansonsten nicht. Dazu ein RF24 Modul ali-005 (Siehe weiter oben). Die Schaltung habe ich skizziert. Ich betreibe den nano mit den 5V vom Laptop USB. Problem ist hierbei noch die 3V3 Versorgung des RF24. Wie Thomas B. (tbnobody) herausgefunden hat verwendet man besser noch ein externes Netzteil. Die Leistung des Linearreglers im CH340 des nanos reicht nicht aus um die Versorgung bei höheren Sendeleistungen sicher zu stellen.
Hallo zusammen, im Source von Oliver sollten ja die verschiedenen Packages nacheinander durchprobiert werden. Daher hätte ich erwartet, dass die Antworten mit gleicher Häufigkeit vorkommen. Aber siehe capture.txt im Anhang sehe ich hauptsächlich 1er und 2er... die 3er Messages kommen kaum vor. Könnt ihr das Nachvollziehen, ist das bei euch ähnlich? Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, ggf. auch der Strom, aber spätestens bei der Leistung stimmt es zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe hier einen HM-1500) Ggf. sind die Telegramme je nach Typ unterschiedlich aufgebaut. Dann müsste man aber seinen Typ entweder in der Hoymiles Cloud einstellen können oder dieser wird irgendwo noch mitgeschickt.
Oliver F. schrieb: > Aber Du kannst gerne den jetzigen Stand hochladen. Gesagt - getan: https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv
Oliver F. schrieb: > @ Sorbit (Gast): > Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in > China bestellt hatte. Davon hab ich genug rumfliegen. Welcher Code läuft da drauf? RF Modul hab ich auch mal im 20 er Pack gekauft. Alles da, auch ein produktiver HM-1200... Danke
Hallo @of22, ich bin noch über Deine Zeile https://github.com/grindylow/ahoy/blob/82ce2c9d8864dcc465af804ab0130dd7a7322a6b/tools/nano/NRF24_SendRcv/src/hm_packets.cpp#L49 gestolpert:
1 | buf[19] = 0x05; |
Warum? Und was passiert, wenn das nicht gemacht wird (also an dieser Stelle ein 0-Byte verbleibt)? Ist das der von Dir beobachtete Zähler, der sich mit jedem Schaltbefehl erhöht?
Hallo, ich möchte mir schonmal die Hardware bestellen. Wir reden über sowas, richtig? https://www.ebay.de/itm/255283312809 (Einen Nano habe ich) Danke sehr!
Hallo @petersilie. Ja, dass ist richtig. Es ist wie weiter oben beschrieben. Ich habe gesehen, dass der Zähler mit jeder Schaltaktion inkrementiert wird. Es ist wahrscheinlich ein 16-bit Wert. Durch die ganze Probiererei scheint der Zähler aus der Cloud mittlerweile bei 0x0537 zu stehen?!? Es passiert erst einmal nichts offensichtliches, wenn man das weg lässt. Keine Ahnung was das ist.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
@Mag C. (magcode): Ja das Modul verwende ich auch. Wichtig ist, dass es ein NRF24L01*+* (Plus) ist.
:
Bearbeitet durch User
Thomas B. schrieb: > Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu > dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich > daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, > ggf. auch der Strom, aber spätestens bei der Leistung stimmt es > zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe > hier einen HM-1500) 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? Wenn wir die Verläufe über ein paar Stunden betrachten, idealerweise mit gleichzeitiger Beobachtung der Ausleuchtung der 4 Solarpanels, dann kommen wir bestimmt hinter die genaue Bedeutung der einzelnen Felder. Der WR-Typ wird ja vielleicht in einem der bisher als "unbekannt" gekennzeichneten Bytes/Bits übertragen. Oder vielleicht ist er in der Seriennummer kodiert? Oder die DTU fragt das bei der Einrichtung einmalig ab?
Angehängte Dateien:
martin schrieb: > Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden Hallo zusammen, leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, wie es hier voran geht. Danke an alle Beteiligte. Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher schon mal aufgenommen hatte: Könnte es vielleicht sein, dass der Inverter generell auf einem anderen aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die Interferenzen sind. Nur so eine Idee - auch wenn das von den im FCC Report genannten Frequenzen abweichen würde. Falls das den Hersteller überhaupt interessiert... (grübel)
Angehängte Dateien:
martin schrieb: > martin schrieb: >> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden > > Hallo zusammen, > leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, > wie es hier voran geht. Danke an alle Beteiligte. > > Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher > schon mal aufgenommen hatte: > Könnte es vielleicht sein, dass der Inverter generell auf einem anderen > aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner > Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. > Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das > wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben > erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die > Interferenzen sind. > > Nur so eine Idee - auch wenn das von den im FCC Report genannten > Frequenzen abweichen würde. Falls das den Hersteller überhaupt > interessiert... (grübel) Das ist momentan bei mir nicht der Fall. Die WR senden auf den festen Channel-Frequenzen, wie es aussieht. Keine Ahnung, was damals alles aktiv war bei Deinen Aufnahmen. Das war auch komisch mit den instabilen Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Der WR scannt die Kanäle durch bis er was empfangen hat und, wie es aussieht, sendet er dann immer 3 Antwort Telegramme, oft auf unterschiedlichen Frequenzen. (Telegramme nicht näher untersucht) Die Kanalwahl hat erst mal nichts zu tun mit der übermittelten Zeit. Das Sonagramm der Aufnahme ist etwas schwach, hatte nur ein Stück Draht als Antenne.
:
Bearbeitet durch User
B. G. schrieb: > Das war auch komisch mit den instabilen > Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Ok, danke für die Rückmeldung. Ich werde das bei Gelegenheit nochmal nachmessen.
> Der WR scannt die Kanäle durch bis er was empfangen hat.
Deshalb wird vmtl immer mit 15 Retransmits gesendet.
Auch der DTU scannt vmtl einfach die Kanäle durch, die Telegramme werden
ja genügend oft wiederholt.
Hallo, ich versuche gerade mal durch den Code zu gehen und diesen zu verstehen. Dabei ist mir aufgefallen, das der Wert 0x05 an Stelle 19 gesetzt wird:
1 | buf[19] = 0x05; |
dennoch ist er bei deiner Ausgabe aber immer an Stelle 18:
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben werden ? Vielen Dank
Marcel schrieb: > Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben > werden ? Hallo Marcel. Nein Du hast nichts übersehen. Das rudimentäre Testprogramm zur Simulation der DTU schreibt an dieser Stelle immer eine 0x05. So ist es momentan noch, weil wir die Bedeutung dieses Wertes noch nicht kennen. Siehe Nachricht vom 27.03.2022 19:34 an Petersillie. Das Beispiel was Du anführst ist aus einem aktuellen Scan der Kommunikation zwischen DTU und WR. Hier steht dieser "Zähler" jetzt schon auf 0x0537.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Siehe auch Nachricht vom 25.03.2022 15:35: Dieser Zähler inkrementiert sich, wenn man aus der Hoymiles Cloud heraus eine Schaltaktion durchführt.
1 | Turn unit off: |
2 | C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 |
3 | 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 |
4 | Turn unit on: |
5 | C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 |
6 | 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 |
7 | Turn unit off: |
8 | C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 |
9 | 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 |
10 | Turn unit on: |
11 | C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 |
12 | 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1 |
Vielen Dank, ist aber auch ein witziger Zufall, das genau 05 um eine Stelle nach vorne gerückt ist. Somit hat der Counter da 16 bit, ergo 4 Stellen. Danke
Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine erste Testimplementierung in Python für RaspberryPi. Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf Kanal 40, ansonsten immer auf Kanal 3 zuhören. Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit einer DTU in Kontakt war. Ergebnis: siehe Anhang. (Programm siehe https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)
:
Bearbeitet durch User
Hallo zusammen mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren. Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB Leistung der letzten Tage, Wochen, Insgesamt?
Martin G. schrieb: > Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine > erste > Testimplementierung in Python für RaspberryPi. > > Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf > Kanal 40, ansonsten immer auf Kanal 3 zuhören. > > Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit > einer DTU in Kontakt war. > > Ergebnis: siehe Anhang. > > (Programm siehe > https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py) Hardware Setup, Software? Viele unterstützen und sollten es auch nachbauen Können. Danke
Hubi schrieb: > Hallo zusammen > mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren. > Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB > Leistung der letzten Tage, Wochen, Insgesamt? Hallo Hubi, das weiß ich zwar nicht zu 100% aber ich halte es für sehr unwahrscheinlich. Das ist klassisch die Aufgabe der Cloud. Das wirst Du in ioBroker mit influxdb und/oder Grafana oer ähnlichem machen müssen.
Sorbit schrieb: > Hardware Setup, Software? Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben. Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon. https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md Gruß -- petersilie
Martin G. schrieb: > Sorbit schrieb: >> Hardware Setup, Software? > > Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den > ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja > noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben. > Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon. > > https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md > > Gruß > > -- petersilie Klasse, super Beschreibung, toll gemacht! Woher bekommst Du die Seriennummer vom WR? Meiner ist leider schon unter den Panels auf dem Dach verbaut😪😪
Sorbit schrieb: > Woher bekommst Du die Seriennummer vom WR? Die Seriennummer habe ich leider bisher nur auf der Rückseite des WR gesehen. Dort sind 2 Labels mit der Seriennummer aufgebracht.
Thomas B. schrieb: > Die Seriennummer habe ich leider bisher nur auf der Rückseite Schei....... Ohne die Nummer keine Kommunikation?
Thomas B. schrieb: > Dort sind 2 Labels mit der Seriennummer aufgebracht. Genau. Damit man eines abziehen und auf den beigefügten Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu klettern ;-)
mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max. Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden? Gibt es dafür Beispiele auf Protokollebene?
martin schrieb: > Genau. Damit man eines abziehen und auf den beigefügten > Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu > klettern ;-) Tja, nacher ist man immer schlauer ;-(
Angehängte Dateien:
temp schrieb: > mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max. > Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden? > Gibt es dafür Beispiele auf Protokollebene? Hallo. Das ist genau der Grund warum ich mich mit der Materie beschäftige. Ich habe eine DTU-WLite. Eigentlich hätte ich mit der Cloud Integration von Hoymiles prima leben können. Leider ist es aber so, dass Hoymiles die Funktion zum Begrenzen der Leistung bei der Lite DTU gesperrt hat. Man braucht dazu die sündhaft teure DTU-Pro. Noch ist es ein weiter Weg, weil nur ein geringer Teil der Payload zwischen DTU und WR entschlüsselt wurde. Wir stehen da erst am Anfang, zu verstehen wie es funktioniert. Dazu kommt, dass zwar schon viele Telgramme gesnifft wurden, aber eben nur zwischen DTU-Lite und WR. Die Möglichkeit mit einer DTU-Pro zu sniffen habe ich z.B. nicht. Darum ist es für mich fraglich ob ich jemals diese Funktion der Leistungsbegrenzung nutzen kann. Ich bekomme sporadisch viele verschiedene Antworten vom WR. Die Bedeutung muss erst einmal verstanden werden. Aber da ist bestimmt auch etwas dabei für WR mit mehr als zwei MPP Trackern. P.S. Autark wirst Du die WR der HM- Serie nie betreiben können, da sie ja einen NA Schutz haben und immer ein vorhandenes Netz in bestimmten Grenzwerten sehen wollen.
:
Bearbeitet durch User
Hallo, ich habe die RF Hardware erhalten und werde es mal mit den Arduino Sourcen probieren. Ich habs auf Anhieb nicht gefunden ... wo würde ich die Seriennummer eintragen? https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv Danke sehr! Update: habs gefunden! -> WR1_RADIO_ID
:
Bearbeitet durch User
Hallo, bei mir antwortet der WR ziemlich präzise jede Minute (ich warte immer 3 Sekunden auf Antwort). Aber alle Anfragen unter einer Minute werden nicht beantwortet (zumindest nicht auf Kanal 3) Ich denke mal, die haben da einen Schutz drin, dass man eben nicht jede Sekunde abfragt. Vielleicht kann das jemand mit DTU und cloud bestätigen, indem man sich die Auflösung der Daten anschaut.
1 | Time Tue Mar 29 15:59:32 2022 |
2 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 24 00 88 00 00 40 A7 03 A5 08 EF E8 |
3 | |
4 | Time Tue Mar 29 16:00:32 2022 |
5 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 F9 FD |
6 | |
7 | Time Tue Mar 29 16:00:40 2022 |
8 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 FA FE |
9 | |
10 | Time Tue Mar 29 16:01:40 2022 |
11 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7A 00 23 00 84 00 00 40 A7 03 A5 08 FA FA |
12 | |
13 | Time Tue Mar 29 16:01:48 2022 |
14 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 79 00 23 00 83 00 00 40 A7 03 A5 08 F6 F2 |
15 | |
16 | Time Tue Mar 29 16:02:48 2022 |
17 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 78 00 22 00 7F 00 00 40 A8 03 A6 08 FC 08 |
18 | |
19 | Time Tue Mar 29 16:03:48 2022 |
20 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 73 00 20 00 77 00 00 40 A8 03 A6 08 F5 00 |
21 | |
22 | Time Tue Mar 29 16:04:49 2022 |
23 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 1D 00 6D 00 00 40 A8 03 A6 08 F7 20 |
Ich habe einen HM-400 (mit nur einem Anschluß für Solar Paneele). Dennoch sind haben bei mir die Position 18-23 Werte. Ich denke nicht, das diese den Wert Volt, Ampere und Power beinhalten. Die Positionen 12-17 Stimmen mit meinen Messungen überein.
1 | if (data[0] == 0x95 && data[9] == 0x01) {
|
2 | // Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7C 01 33 04 90 00 00 40 75 03 73 09 09 0B |
3 | DATA.voltage_pv1 = float(data[12] << 8 | data[13]) / 10; |
4 | |
5 | DATA.ampere_pv1 = float(data[14] << 8 | data[15]) / 100; |
6 | |
7 | DATA.power_pv1 = float(data[16] << 8 | data[17]) / 10; |
8 | |
9 | DATA.voltage_pv2 = float(data[18] << 8 | data[19]) / 10; |
10 | |
11 | DATA.ampere_pv2 = float(data[20] << 8 | data[21]) / 100; |
12 | |
13 | DATA.power_pv2 = float(data[22] << 8 | data[23]) / 10; |
14 | } else if (data[0] == 0x95 && data[9] == 0x82) {
|
15 | // Received: 95 73 10 90 25 73 10 90 25 82 13 88 04 57 00 01 00 30 03 E8 01 5B 00 1F 2E 2A 44 |
16 | DATA.frequency = float(data[10] << 8 | data[11]) / 100; |
17 | |
18 | } |
Danke für die Arbeit bisher. Ich bin schon mal sehr happy, das ich einige Daten lesen kann. Marcel
Wobei, ich revidiere. Da hatte er nur ein mal ein guten Lauf :) Nach erneutem Flashen des ESPs gehts jetzt nicht mehr so präzise. Marcel
(1) Das mit dem Abfragerhythmus ist noch mysteriös, aber je mehr Erfahrung wir sammeln, desto näher kommen wir der Sache. Ich fände es logisch, wenn der WR ziemlich zeitnah auf eine Anfrage antwortet. Aber er muss eben die Anfrage auch hören (in unserem Fall: gerade auf Kanal 40 lauschen), und sie dann (in unserem Fall) genau auf Kanal 3 beantworten. Ich meine, in einigen der frühen Posts hatten wir schon beobachtet, dass eine DTU auf jeden Fall immer gleich auf mehreren Kanälen anfragt. Ich spekuliere mal, dass der WR dann vielleicht auch immer gleich auf mehreren Kanälen antwortet. Vielleicht ist garnicht viel mehr Magie dabei. Auf vielen Kanälen fragen. Auf vielen Kanälen antworten. Wenn auf einem Kanal "lange" nie eine Nachricht kommt, mal auf einen anderen der bekannten Kanäle wechseln. Presto, semi-verlässliche Kommunikation. (2) Nachrichten-Inhalte. Hier habe ich mir seit längerem keine Zeit mehr genommen, die Protokollbeschreibung upzudaten. Es gibt ja ein paar neue Erkenntnisse. Aber ich sammle jetzt eifrig Beispieldaten mit meinem WR, und Du und viele andere machen dasselbe. Da finden wir bestimmt nach einiger Zeit Muster/Werte, über die wir dann auf den Inhalt der jeweiligen Datenfelder schließen können. Deine Daten von dem 1-kanaligen WR sind vielleicht ähnlich wie die von @tbnobody mit seinem HM-1500 (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")? Er sagt ja auch, dass es sich hier nicht um V/A/W handeln kann. Ruhig mal nen ganzen Tag mitloggen!
Ich hab die Daten jetzt mal mit meinem Esphome und Homeassistant Messungen verglichen. Ich gehe davon aus, das die Position 20 und 21 die Gesamtproduktion in Watt des WR und die Position 22 und 23 die Tagesproduktion in Watt sind. Die passen ziemlich genau mit den Daten von meinem HomeAssistant (wo ich den Strom messe, den ich ins Netz gebe).
1 | DATA.total_production = float(data[20] << 8 | data[21]) / 1000; |
2 | DATA.daily_production = float(data[22] << 8 | data[23]); |
Aber ich denke das werden die anderen bestimmt bald bestätigen oder widerlegen können :) Marcel
Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt. WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen. Beim starten gibt die serielle Konsole aus:
1 | -- Hoymiles test -- |
2 | 19:11:42.309 -> |
3 | 19:11:42.309 -> Radio 1: |
4 | 19:11:42.309 -> SPI Speedz = 10 Mhz |
5 | 19:11:42.309 -> STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 |
6 | |
7 | 19:11:42.309 -> RX_ADDR_P0-1 = 0xdeadbeef01 0x1234567801 |
8 | |
9 | 19:11:42.309 -> RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 |
10 | |
11 | 19:11:42.309 -> TX_ADDR = 0xdeadbeef01 |
12 | |
13 | 19:11:42.309 -> RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20 |
14 | |
15 | 19:11:42.309 -> EN_AA = 0x00 |
16 | |
17 | 19:11:42.309 -> EN_RXADDR = 0x02 |
18 | |
19 | 19:11:42.309 -> RF_CH = 0x03 |
20 | |
21 | 19:11:42.309 -> RF_SETUP = 0x23 |
22 | |
23 | 19:11:42.309 -> CONFIG = 0x37 |
24 | |
25 | 19:11:42.309 -> DYNPD/FEATURE = 0x00 0x00 |
26 | |
27 | 19:11:42.309 -> Data Rate = 250 KBPS |
28 | |
29 | 19:11:42.309 -> Model = nRF24L01+ |
30 | |
31 | 19:11:42.309 -> CRC Length = Disabled |
32 | |
33 | 19:11:42.309 -> PA Power = PA_LOW |
34 | |
35 | 19:11:42.309 -> ARC = 15 |
36 | |
37 | 19:11:42.309 -> |
Das wars dann leider. Mehr kommt nicht. Auch nach einigen Minuten warten. Ich war bis auf 4m am HM-400 ran. Der HM-400 hat während des Tests Strom produziert, war also aktiv. Verkabelung habe ich kontrolliert. Allerdings habe ich den Kondensator nicht und das RF Modul direkt an den 3.3v Pin des Nano angeschlossen...
Mag C. schrieb: > Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt. > WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen. Du darfst nichts in HEX wandeln, also umrechnen. Die dezimale Seriennummer wird einfach als Hex Wert eingetragen. Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge angegeben werden: An meinem Beispiel: WR1 = xxxx73104619 Und im Byte 5 der Adresse die 01 nicht vergessen. #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
Zusätzlich braucht der HM ein wenig Sonne, sonst ist er aus. Hier in Nord Deustchland antwortet mein HM nicht mehr. Da musst Du wohl bis morgen warten. Marcel
Hallo zusammen, ich habe gerade bei meinem HM-1500 einen etwas längeren Auszug von Sonntag Ausgewertet. (Rohdaten, leider ohne Timestamp siehe Anhang) Hierbei habe ich mir zuerst die 1er Messages angeschaut. Ich habe mich hierbei am -r5 Dokument orientiert: https://www.mikrocontroller.net/attachment/550551/hoymiles-datenformat-r5.txt PV1.u und PV1.i konnte ich soweit nachvollziehen. Die nächsten beiden Bytes machen dann keinen Sinn. Allerdings entsprechen die weiteren beiden Bytes (was im Beispiel oben PV2.u wäre) genau den Produkt von PV1.u und PV1.i, also der Leistung in .1W Im Excel im Anhang habe ich dies auf dem Sheet "output_2022-03-27_18-20-16__1er" dargestellt. Spalte D - N entsprechen den HEX Werten, In Spalte P - W habe ich diese in Dez Werte umgerechnet. Bei den 2er Messages konnte ich keine parallelen zum -r5 Dokument finden. Also es sieht hier nicht nach AC Werten aus. Spalte S multipliziert mit Spalte T entspricht aber Spalte V (+/- ein bisschen). Könnte also wieder U, I und P sein. Bei den 3er Messages könnte Spalte V die AC Spannung sein. Aber das ist nur geraten.
Angehängte Dateien:
-
Cloud-01.png
9,8 KB -
Cloud-02.png
180 KB -
Cloud-03.png
31 KB -
Cloud-04.png
29 KB -
Cloud-05.png
38 KB
Hier btw ein Link zu einer DTU Pro: https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html Interessanter als die Hardware finde ich aber den Link mit den Zugangsdaten. Ich habe mal ein paar Bilder angefügt. Irgendwo scheint also auch noch die Temperatur und die Firmware Version versteckt zu sein.
Hallo, danke für die Screenshots. Das mit der Temperatur ist sehr hilfreich - ich hatte auch ein paar mal ähnliche Werte gesehen. Danke Marcel P.s.: ich würde ein paar Sachen/Informationen in deinen Screenshots unlesbar machen. Wer weiß wie die drauf sind.
Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power) pro Solar Panel oder ist das immer pro WR zusammengefasst? Ich bin bisher der Meinung, das ma neben nur die Gesamtleistung sieht und nicht jedes PV einzeln. Marcel
Sorry, für den SPAM. Basierend auf deinen Daten, könnte ich mir vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar Panel Nummer ist. Das würde auch Sinn machen, da ich in meinen Logs noch nie eine 02 gesehen habe und immer nur 01 gefunden habe (HM-400 hat nur einen Anschluß für einen Solar String). WR1 - Solar Panel #1
1 | 95 71603546 71603546 01... |
2 | [code] |
3 | |
4 | WR1 - Solar Panel #2 |
5 | [code] |
6 | 95 71603546 71603546 02... |
Anbei auch mal meine Daten analyse, wobei ich mir mit den letzten Feldern nicht ganz sicher bin. Bei mir stimmen die Daten mit meinen Messungen überein, aber die von Thomas ergeben nicht so viel Sinn (ggf. bedeuten die Werte doch was anderes).
Oliver F. schrieb: > Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge > angegeben werden: > > An meinem Beispiel: > WR1 = xxxx73104619 > > Und im Byte 5 der Adresse die 01 nicht vergessen. > #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = > WR1 Danke für den Tipp! Jetzt läuft's
1 | 000486220 00 1234567801 00DE 1B 3 95 74950839 74950839 010001014C000B00240000062C0000093AEEE320 E320 1 |
2 | 005286328 00 1234567801 00DA 1B 1 95 74950839 74950839 010001014B000B00240000062C0000093BE85281 5281 1 |
3 | 008486552 00 1234567801 00DA 1B 1 95 74950839 74950839 010001014C000B00240000062C0000093BEF5260 5260 1 |
4 | 013286980 00 1234567801 00DC 1B 2 95 74950839 74950839 010001014A000B00240000062C0000093AE8C1A9 C1A9 1 |
5 | 016487192 00 1234567801 00DE 1B 3 95 74950839 74950839 010001014B000B00240000062C00000939EA86F1 86F1 1 |
6 | 021287296 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014B000B00250000062C00000938EA01FD 01FD 1 |
7 | 024487512 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014B000B00250000062C00000937E5E02C E02C 1 |
8 | 026085360 00 1234567801 00DA 1B 1 95 74950839 74950839 010001014B000B00250000062C00000937E5A904 A904 1 |
9 | 026132564 00 1234567801 00DC 1B 2 95 74950839 74950839 82138700230000000103E9003B000858D3F33E3C 3E3C 1 |
10 | 027687708 00 1234567801 00DC 1B 2 95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1 |
11 | 029285564 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1 |
12 | 029321264 00 1234567801 00DA 1B 1 95 74950839 74950839 82138700230000000103EA003B00081468072891 2891 1 |
13 | 032486288 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1 |
14 | 035685728 00 1234567801 00DC 1B 2 95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1 |
15 | 037285832 00 1234567801 00DE 1B 3 95 74950839 74950839 010001014C000B00250000062C00000938EDDA64 DA64 1 |
16 | 037333012 00 1234567801 00D8 1B 0 95 74950839 74950839 82138700230000000103EB003B0008D01AB0655A 655A 1 |
Marcel schrieb: > Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power) > pro Solar Panel oder ist das immer pro WR zusammengefasst? Hallo Marcel, bei dem oben genannten Account handelt es sich ja um einen öffentlichen Test-Account den jeder verwenden kann (Es handelt sich nicht um meine Anlage). Aktuell zeigt die Detailansicht (siehe Cloud-05.png) für jedes Panel unterschiedliche Watt angaben (33 vs. 32W). Spannung und Strom sind beim Klick auf die Panels identisch (32,5V und 1,0A). Es kann sich hier natürlich auch um Rundungsungenauigkeiten handeln und Strom/Spannung/Leistung ist trotzdem individuell. Bzgl. dem Hex Wert nach den WR Seriennummern... Dann müsste ich aber bis zu 4 Nachrichten erhalten, zumindest hat der HM-1500 vier individuelle Ports. Grüße Thomas
Marcel schrieb: > asierend auf deinen Daten, könnte ich mir > vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar > Panel Nummer ist. Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele angeschlossen und an der Stelle nie eine 02 gesehen. Eine andere Frage: Habt ihr schon mal andere Anfagecodes ausprobiert, um andere Daten zu erhalten? Ich habe bei der seriellen Aufzeichnung mindestens 3 verschiedene Anfragepakete gesehen: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Martin schrieb: >Marcel schrieb: >> basierend auf deinen Daten, könnte ich mir >> vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar >> Panel Nummer ist. > Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele >angeschlossen und an der Stelle nie eine 02 gesehen. Hallo, okay, das ist schon mal ein guter Hinweiß. Die Daten für das 02 Command machten auch nicht so viel Sinn. Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten passen bisher mit meinem Messungen. Werde heute auch mal probieren andere Requests zu senden und schauen ob und was zurück kommt. Marcel
Marcel schrieb: > Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten > passen bisher mit meinem Messungen. Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor. Du hattest einen HM-400 oder?
Marcel schrieb: > Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten > passen bisher mit meinem Messungen. Danke für die Doku! Kann ich so bestätigen mit meinem HM-400.
Sorry bin gerade krankheitsbedingt ziemlich außer Gefecht. Hier sind mal die Logs von meinem HM-700 (2 Kanäle) für die letzten 2 Tage: - https://filetransfer.io/data-package/QBOaWm7M#link Geloggt wie unter https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md#example-run beschrieben. Wie viele Posts weiter oben ja entdeckt haben, sind die Antworten wohl je nach Wechselrichtertyp leicht unterschiedlich. Bei meinem sieht man plausibel die U, I, P-Werte für die beiden angeschlossenen Panels. Vielleicht fällt jemand zu den "unknown"-Werten was ein - vielleicht sind das die gleichen, die bei anderen Wechselrichtern in den Feldern für das "2te Panel" stehen? Kandidaten sind u.a. Tages- und Gesamtenergie (in Wh) sowie die Temperatur (in Zehntel-°C). Als "Auslöser" für die Antworten sende ich bisher wohlgemerkt nur im Sekundentakt eine 0x80-Nachricht. Das scheint ausreichend häufig zu einer Rückmeldung zu führen.
:
Bearbeitet durch User
So aus dem Bauch raus würde ich für CMD=0x02 mal tippen: - uk4, uk5: Tages-Energie Panel 1, 2 [Wh] (läuft am nächsten Tag wieder mit 0 los) - uk1, uk3: Gesamt-Energie seit Geburt (?), Panel 1, 2 [Wh]
...und dann gibt es noch die mysteriöse 0x83-Antwort. Über die beiden Tage verteilt kam die nur 49 mal:
1 | $ cat two-days-hm-700.log | grep '95 74 60 81 45 74 60 81 45 83' | cut -b 28- |
2 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e8 00 67 00 06 86 06 1e |
3 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 75 00 06 4f ee 3f |
4 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 17 03 e8 00 7c 00 06 94 08 0c |
5 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 23 03 e8 00 91 00 06 3d a0 d5 |
6 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 29 03 e8 00 9e 00 06 d5 43 db |
7 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 2d 03 e8 00 a3 00 06 51 61 44 |
8 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 32 03 e8 00 a5 00 06 5f 15 27 |
9 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 40 03 e8 00 b2 00 06 90 be 26 |
10 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 65 03 e8 00 d3 00 06 4d f8 f8 |
11 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 5e 03 e8 00 eb 00 06 a9 9c 7b |
12 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 5d 03 e8 00 f3 00 06 08 dc 81 |
13 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 41 03 e8 00 f8 00 06 58 71 6a |
14 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 5a 03 e8 01 00 00 06 03 6e cd |
15 | : 95 74 60 81 45 74 60 81 45 83 00 03 00 a3 03 e8 01 1b 00 06 a1 88 68 |
16 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 82 03 e8 01 57 00 06 9a ef 5a |
17 | : 95 74 60 81 45 74 60 81 45 83 00 02 00 61 03 e8 01 75 00 06 9e 7f 0d |
18 | : 95 74 60 81 45 74 60 81 45 83 00 02 00 6d 03 e8 01 5b 00 06 0f b5 74 |
19 | : 95 74 60 81 45 74 60 81 45 83 00 02 00 52 03 e8 01 4d 00 06 2e 30 f9 |
20 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 4a 03 e8 01 4e 00 06 4d ef 5c |
21 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 47 03 e8 01 4d 00 06 5e 07 a9 |
22 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 44 03 e8 01 4c 00 06 ac 22 7d |
23 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 27 03 e8 01 2b 00 06 45 4e fc |
24 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 15 03 e8 01 13 00 06 c3 c5 fa |
25 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 01 07 00 06 55 2f 96 |
26 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 fd 00 06 83 78 f6 |
27 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 78 00 06 8f ef 08 |
28 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 7b 00 06 25 2a 64 |
29 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7f 00 06 b3 43 77 |
30 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7e 00 06 35 4f fc |
31 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 ea 00 82 00 06 ed 4b df |
32 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 8b 00 06 1c 6e 0d |
33 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 8f 00 06 ae 48 83 |
34 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 90 00 06 a6 5e 82 |
35 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 13 03 e8 00 92 00 06 70 46 4c |
36 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 9c 00 06 38 74 24 |
37 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 16 03 e8 00 9d 00 06 c8 67 df |
38 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a0 00 06 5d 79 71 |
39 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 a3 00 06 c5 e0 64 |
40 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 12 03 e8 00 ae 00 06 85 5a 98 |
41 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 07 03 e8 00 aa 00 06 ca b1 2d |
42 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 08 03 e8 00 a5 00 06 88 74 aa |
43 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 a3 00 06 55 16 10 |
44 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0a 03 e8 00 9c 00 06 c0 56 fb |
45 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 9b 00 06 82 e1 13 |
46 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 09 03 e8 00 9d 00 06 10 5d 22 |
47 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 9c 00 06 ef a9 38 |
48 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a4 00 06 cd e2 7e |
49 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 a1 00 06 b5 ce 31 |
50 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 04 03 e8 00 9d 00 06 0f ac c1 |
Vielleicht ist da was bzgl. Kanal-Hopping drin? Hat jemand Ideen?
Hallo Thomas, > Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu > bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor. Diese Antwort kommt bei mir so mehrmals auf 0x15er Request zurück
1 | Send to channel: 40 |
2 | Time Wed Mar 30 14:56:30 2022 |
3 | |
4 | Sending packet of size: 27 |
5 | Now sending: 15 73 10 90 25 72 81 90 05 80 0B 00 62 44 6F 9E 00 00 00 05 00 00 00 00 94 87 EF ok... |
6 | Listen channel: 3 |
7 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 82 00 1C 00 6C 00 00 41 C6 01 18 08 F7 07 |
8 | Got reply: |
9 | Voltage: 38.60V, Ampere: 0.28A, Power: 10.80W |
10 | Daily production: 280.000 W, AC Voltage: 229.5 V, Total production: 16.838 kW |
11 | Frequency: 0.000, Temperature: 0.0 °C |
12 | Received: 95 73 10 90 25 73 10 90 25 82 13 87 00 67 00 00 00 04 03 E8 00 FE 00 06 BB 44 0C |
13 | Got reply: |
14 | Voltage: 0.00V, Ampere: 0.00A, Power: 0.00W |
15 | Daily production: 0.000 W, AC Voltage: 0.0 V, Total production: 0.000 kW |
16 | Frequency: 49.990, Temperature: 25.4 °C |
17 | This round is over. |
Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief
wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die
wichtigen Teile des Codes in mein Programm kopiert. Das gibt mir die
Möglichkeit mit dem Code zu spielen, da ich auch alle Teile davon genau
verstehe. Ebenfalls setze ich auch immer die korrekte Zeit (vielleicht
ist es das).
Mein Script sendet den Request und hört dann 3 Sekunden auf dem Kanal 3.
Dann wartet es erneut 3 Sekunden und beginnt von vorne.
> Du hattest einen HM-400 oder?
Genau.
Ich habe jetzt auch einen zweiten ESP32 mit einem NRF Chip und die habe
ich jetzt so synchronisiert, das der eine eine Message sendet und der
andere dann zur gleichen Zeit verschiedene Kanäle durch hört. Ich hoffe,
das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber
vorstellen, das es eine Weile dauert.
Marcel
martin schrieb: > Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele > angeschlossen und an der Stelle nie eine 02 gesehen. Schaut mal in die Wechselrichter nach, ob die tatsächlich 2 seperate MPPT-Tracker habe könnten. Bei meinen SG700 werden die 2 Eingänge für die Module intern gebrückt.
Angehängte Dateien:
Marcel schrieb: > Ich hoffe, > das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber > vorstellen, das es eine Weile dauert. Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen. Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83 auf bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz von den dreien kommen. Wenn eine andere Sendefrequenz genutzt wird, dann sind das bei mir 3 andere mögliche Antwortfrequenzen. z.b noch die 2475 Mhz. Nochmal das jpg mit Kommentaren.
Hallo, ich habe jetzt mal die Messages auf Kanal 40 gesendet und dann alle Kanäle einzeln von 1 - 128 für 3 Sekunden gehört. Da kam nie was, ausser eben auf Kanal 3. Ebenfalls habe ich mal mit der Anfrage bits rumgespielt. Es kommen zwar bei einigen Kombinationen Antworten, aber die machen bisher noch keinen Sinn. Hab die Daten mal angehängt. Marcel
Marcel schrieb: > Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief > wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die > wichtigen Teile des Codes in mein Programm kopiert. Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack Overflows kämpfe. - Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die ganzen Libraries quält. Ist das normal? - Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme gab es? B. G. schrieb: > Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen. > Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83 auf > bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der > Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz > von den dreien kommen. Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61? Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80 gelauscht. Meine WR antworten nur auf Kanal 3 und 23. Die DTU sendet abwechselnd auf: 0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61. Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung abhängen? z.B. auf welchem Kanal WLAN aktiv ist?
Hallo Oliver > Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 > schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack > Overflows kämpfe. Do it :) > - Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit > PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die > ganzen Libraries quält. Ist das normal? Also ich nutze auch Visual Studio Code mit der PlatformIO extension. Wenn bei mir alles ein mal gebaut ist, dann dauert das neu kompilieren unter 1sec. Das Hochladen und den Boot Button zu drücken ist das was am längsten dauert :). Ich hänge mal mein Programm hier mit an. Ist alles in einer Datei und ich nutze keine eigene CRC Berechnung, sondern eine externe offizielle Libs. Sobald alles einigermaßen geht, würde ich den Code dann sauber machen. Aber derzeit bin ich so schneller. > - Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme > gab es? Um ehrlich zu sein, habe ich es noch nie hinbekommen Circular Buffer auf meinen ESPs zum laufen zu bekommen (ist aber auch schon Jahre her das ich es probiert habe). Soweit ich mich erinnern kann, muss man auf dem ESP Circular Buffer anders initialisieren und es gibt Probleme, die man beachten muss, mit irgendwelchen Integer Größen, die anders auf einem Nano und einem ESP32 sind. Bin mir da aber nicht mehr sicher. Ist wirklich schon sehr lange her und ich baue es immer um, wenn ich Circular Buffer sehe. Marcel
Hallo, ich habe auf Basis des Arduino Sketch ein kleines MQTT Gateway geschrieben (in JAVA) und teste die nächsten Tage. Nun frage ich mich wo die Reise hingeht. Ich persönlich finde folgendes Setup clever: Microcontroller (Arduino oder ESP ohne aktivem WIFI) und RF als relativ "dumme Empfängerhardware" mit USB Anschluss. Die "Software" (nodeJS, python, java oder auch Plugins für Homeautomation Systeme) dann auf einem beliebigen Computer (Raspi, Windows, Linux, Mac) laufen lassen. Die meiste "Intelligenz" ist in der "Software". Dies betrifft das Parsen der Daten sowie das Aufbereiten und versenden via MQTT. Falls die verschiedenen Hoymiles tatsächlich unterschiedliches Parsing erfordern, ist es m.E. einfacher das in der "Software" anzupassen (anstatt C code schreiben und Firmware Flash). Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte. Wie ist Eure Meinung?
Hallo Mag, ich finde schon, das es einen "Treiber" geben sollte der ein einheitliches Interface hat (unabhängig vom verwendetem Hoymiles). So wie du das beschreibst, klingt es ja wie ein Open MQTT Gateway Integration, die deine Anfrage in das jeweilige Protokoll (LORA oder dann eben Hoymiles umwandelt). Dann muss die Logic, in der Tat irgendwo anders sein. Ich persönlich würde eine ESPHome Version bauen, die dann die Werte ebenfalls - in einem einheitlichem Format - via MQTT oder HomeAssistant API wegschreibt. Höre aber auch sehr gerne andere Meinungen :) Marcel
Oliver F. schrieb: > Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61? > Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger > mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80 > gelauscht. > Meine WR antworten nur auf Kanal 3 und 23. > Die DTU sendet abwechselnd auf: > 0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61. > Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung > abhängen? z.B. auf welchem Kanal WLAN aktiv ist? Ich hab das vielleicht falsch beschrieben. Nicht mein DTU sendet auf 2403, sondern mein Atmel, der mir als DTU-Ersatz dient. Dein Original-DTU wechselt wohl schon die Sendefrequenzen. Ich bleibe mit meinem AVR beim Senden immer auf einer gleichen Frequenz ( 2403) und dann antwortet der WR mir immer mit den Telegrammen 01,02,80 auf den maximal 3 Frequenzen 2423,2440,2461, siehe jpg. Wenn ich eine andere Sendefrequenz nehme, dann antwortet der WR z.b. auf 2475 2423 und 2403. Aber mir scheint es, daß es vielleicht auch Unterschiede bei den jeweiligen WRs gibt. Ich selbst habe einen HM-600
Hallo, ich glaube die Bytes von den Seriennummern der Wechselrichter werden berücksichtigt. Wenn ich hier mal die letzten Daten anschaue und die Texte mit den Angaben zu dem Versionen der Wechselrichter lese, ergibt sich ein Muster. Ich denke, dieses Byte kann dazu genutzt um die Antworten auszuwerten. Weil meine HM-400 Antwort hat Fundamental andere Werte als die von einem HM-600 (Ampere, Volt etcpp). Vielleicht kann ja jeder, der demnächst hier schreibt, seine Version des Wechselrichters (HM-XXX) reinschreiben und seine Seriennummer? Dann kann man meine These mal validieren.
1 | HM-1500: |
2 | - 71 60 35 46 |
3 | HM-700: |
4 | - 74 60 81 45 |
5 | HM-600: |
6 | - 72 22 02 00 |
7 | HM-400: |
8 | - 73 10 90 25 |
Es sieht fast so aus, als wenn jede Version eines erste Byte hat. Marcel
> 74 95 08 39
Verdammt :D Die passt nicht ins Schema.
Wobei die DTU ja die ganze Seriennummer kennt. Ggf. ist den ersten 4
Zahlen die Version kodiert.
Meine wäre dann für den HM-400 Serial No: 1121 73109025
Marcel
:
Bearbeitet durch User
Schaut mal hier (Kapitel 6): https://www.manualslib.de/manual/793350/Hoymiles-Mi-300.html?page=16#manual Mit den ersten 4 Zeichen scheint man wohl Inverter als auch Version identifizieren können...
1 | Fehlersuche |
2 | Hoymiles hat die interaktive Leistung des Mikroumwandlersystems Mitte 2020 aktualisiert. |
3 | Wenn Sie den Mikroumwandler mit Seriennummer "1022xxxxxxxx" verwenden, so beziehen Sie |
4 | sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikroumwandler mit |
5 | Seriennummer "1020xxxxxxxx" und "1021xxxxxxxx" verwenden, so beziehen Sie sich bitte auf |
6 | Abschnitt 6.2 und Abschnitt 6.4. |
7 | *Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von |
8 | Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und |
9 | DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren. |
Gleiches gibt es wohl auch für die größere Reihe: https://www.manualslib.de/manual/811724/Hoymiles-Mi-1000.html?page=17#manual
1 | Fehlersuche |
2 | Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems Mitte 2020 aktualisiert. |
3 | Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" verwenden, so beziehen |
4 | Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikrowechselrichter mit |
5 | Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen Sie sich bitte auf |
6 | Abschnitt 6.2 und Abschnitt 6.4. |
7 | *Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von |
8 | Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und |
9 | DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren. |
:
Bearbeitet durch User
HM-1200 1161xxxxxxxx HM-1500 1161xxxxxxxx
Sehr gut, das hilft schon mal wenn wir weitere Daten analysieren und später um den Parser zu schreiben. Ich denke mal, das die ersten 4 Ziffern immer eine Gruppe beschreiben und die Antworten im gleichen Format sind. Danke Marcel
Hallo Zusammen, *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. Das mit den og. unterschiedlichen Versionen der Wechselrichter und DTUs könnte mit dem verbauten NRF24L01+ Chip gegenüber den bei Seriennummer 1062x, bzw. DTU-Pro, DTU-G100 und DTU-W100 vermutlich verbauten NRF5x Chip zusammenhängen. Folgendes Zitat aus dem Enhanced ShockBurst (ESB) Dokument scheint die beiden Modi und Kombinationen zu erklären: Enhanced ShockBurst (ESB) - Features https://developer.nordicsemi.com/nRF_Connect_SDK_dev/doc/PR-3842/nrf/ug_esb.html * 1 to 32 bytes dynamic payload length in legacy mode * 1 to 252 bytes static payload length between nRF5 Series devices
HM-350: 1121 72xxxxxx HM-700: 1141 74xxxxxx
HM 1200 1161 70523283 ich habs mal einen Tag lang laufen lassen und sehe 4 arten von Antworten hab sie mal beigefügt.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht und nach Bildern von Hoymiles Wechselrichtern mit Seriennummern gesucht. Ebenfalls habe ich die Seriennummern aus diesem Thread verwendet. Das Ergebnis, insgesamt 29 WR, befindet sich im Anhang. Als Bild habe ich noch das Ergebnis angehängt. Also das Mapping zwischen Typ und Prefix. Das sieht erstmal recht eindeutig aus.
Angehängte Dateien:
Mag C. schrieb: > Hier ist noch ein HM-800 :-) -> 1141 Danke für den Hinweis :) Habe ich noch in das Ergebnis aufgenommen (siehe Anhang). Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten auch die Telegramme der farbig markierten Inverter kompatibel sein.
Hallo Thomas, > ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht Das ist natürlich clever und erheblich effizienter als hier zu fragen. Chapeau > Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten > auch die Telegramme der farbig markierten Inverter kompatibel sein. Davon gehe ich auch aus. In hab mir vorhin noch mal den Thread durchgelesen und dabei die Bilder von der geöffnetem DTU angeschaut. Darin ist ja scheinbar eine RTC verbaut. Da ich in den vergangenen Tagen ein einziges mal wirklich aller 60 Sekunden für einen längeren Zeitraum konstant Antworten vom WR bekommen habe, kann es sein, das der WR ggf. den Timestamp und die differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren ggf. die Uhren meiner ESP32 und des WR grob syncron. Was denkt Ihr ? Ebenfalls habe ich mich mal in das Konzept von channel hopping (grob) eingelesen und eine synchronisierte Zeit oder Tackt ist dabei wohl essentiell. Ich hab vor ein paar Minuten mal ein RTC DS3231 an meinen ESP geklemmt und den code so verändert, das die Zeit immer von der RTC kommt. Vielleicht klappt es ja morgen bei Sonne. Marcel
Hallo, hab nen HM-1200 116172216067 Tolles Projekt bin mal auf das Ergebnis gespannt.
Mag C. schrieb: > Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den > Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte. Da ich weder MQTT noch ESPHome oder sonstige Home-Automation nutze, wäre gerade das zitierte meine Lösung. Bei mir laufen mehrere ESPs und als Master fungiert ein RasPi, der mittels cron-Jobs die Daten von den ESPs sammelt, speichert, auswertet, grafisch darstellt, ... Zu der "Software" : die brauch man nur einmal zu entwickeln, die Auswertung der empfangenen Daten könnte man über eine Tabelle (im EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so aussehen: 1141 HM-600 AC-Spannung 02 12 2 10 bedeutet: Die Wechselspannung ist im Telegramm 02, beginnt ab Byte 12, ist 2 bytes lang und muss noch durch 10 geteilt werden. Wenn das Projekt so richtig in Software umgesetzt wird (Github), hätte ich folgenden Vorschlag: 1) Die Kommunikation in einen Kern packen, der für Arduino, ESP, RasPi passt, am besten in C. 2) Funktionalität darüber hinaus in Plugins packen, die man über #define mit dazu linkt. Weitere Funktionalität wären zB: MQTT, ESPHome, Display, Webserver, Upload, ...
Marcel A. schrieb: > kann es sein, das der WR ggf. den Timestamp und die > differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren > ggf. die Uhren meiner ESP32 und des WR grob syncron. Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer konstanten 0x80-Anfrage (jede Sekunde) laufen:
1 | 15 74 60 81 45 78 56 34 12 80 0b 00 62 46 d3 0f 00 00 00 05 00 00 00 00 92 ea c3 |
Er scheint damit genauso häufig zu antworten wie zuvor, als ich jede Sekunde die aktuelle Uhrzeit mitgeschickt hatte (siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?").
Mag C. schrieb: > Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den > Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte. Meine Interessen liegen da ähnlich, ich komme eher aus der RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen. Das nette daran ist, dass man insbesondere während der Experimentierphase sehr einfach Anpassungen machen kann, ohne dass man immer gleich einen Controller neu flashen muss. Aber na klar gibt es auch gute Gründe für Arduino/ESP32 Implementierungen. Unsere Forschungen hier sind für beide Ansätze gleichermaßen hilfreich. Habe soeben nochmals die in Entstehung befindliche `ahoy` Python-Software aktualisiert, diese sendet jetzt die empfangenen Daten gleich via MQTT raus. * https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py
Hallo petersilie,
> Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer
konstanten 0x80-Anfrage (jede Sekunde) laufen:
Ja, ich habe meinen Logger mit RTC seit heute morgen laufen und sehe
ebenfalls keine Besserung in der Antworthäufigkeit :/
Marcel
Angehängte Dateien:
Logs von meinem HM-600, auf die Schnelle ein altes Projekt umgeändert.
Angehängte Dateien:
-
response_packet.png
14 KB
Hubi schrieb: > Zu der "Software" : die brauch man nur einmal zu entwickeln, die > Auswertung der empfangenen Daten könnte man über eine Tabelle (im > EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so > aussehen: > 1141 HM-600 AC-Spannung 02 12 2 10 Hallo Hubi, ich bin mir nicht sicher, ob dass so einfach möglich ist. In meinen Daten von früher habe ich gesehen, dass die gleiche Paket-ID wohl verschiedene Inhalte haben kann, je nach dem welcher Request zuvor kam (siehe Bild oder früherer Post): Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Anscheinend kommt es auf die vorige Abfrage an. Allerdings habe ich das bisher nicht in den Funk-Daten beobachtet, die Mitschnitte in der Excel sind von der DTU-internen seriellen Kommunikation. Kann das jemand verifizieren?
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.
Hello All. I just bought 3 x Hoymiles HW1500 for my PV installation. I will install them within one month. How could I contribute to your project to proceed with creating a reverse-engineered and open source solution to communicate with those micro inverters. I have some SDR usb dongle available to put it to work as well. Kind regards WK
Martin G. schrieb: > Meine Interessen liegen da ähnlich, ich komme eher aus der > RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für > verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an > seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen. Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder ESP32 zur Verfügung stellen könnte Raspi, schön und gut - aber meiner ist zu weit weg vom WR - gerade die Hoymiles-WR sind ja eigentlich dafür gedacht auf dem Dach montiert zu werden?
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. Hallo, eventuell können die helfen: https://www.enercab.at/hoymiles/1067-hoymiles-pv-monitoring-dtu-wlite.html Dort ist eine +49er Telefonnummer vorhanden. Mein HM600 SNR: 114172609296 wartet noch auf die PV-Module.
Heinz R. schrieb: > Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder > ESP32 zur Verfügung stellen könnte Mein Plan wäre eine Library aka. https://github.com/atc1441/NETSGPClient Durch die NRF24 Library wäre dies dann vmtl. auch sowohl für ESP32 als auch ESP8266 nutzbar (und mit etwas Glück auch nativ unter Linux). Was man außen rum baut ist wieder ein ganz anderes Thema. Aber wie @petersilie schon sagt, die Grundlegenden Dinge die aktuell laufen eignen sich sowohl für Python als auch für eine C Implementierung. Erstmal muss man allgemein verstehen was passiert :) Habe heute einen ganzen Tag mitgelogged und werde das jetzt Auswerten. Spontan sehe ich aber nur 01er, 02er und 03er Nachrichten. (Gepulled habe ich die Daten mit dem ahoy.py Script)
Waldemar K. schrieb: > How could I contribute to your project to proceed with creating a > reverse-engineered and open source solution to communicate with those > micro inverters. > > I have some SDR usb dongle available to put it to work as well. Hello Waldemar, and welcome! One of the unsolved mysteries is how the inverters and DTU "hop" between different frequencies. Maybe scans with your SDR dongle can help.
Ich habe mal wieder das Format-Beschreibungs-Dokument aktualisiert. Leider immer noch ein bisschen durcheinander und unvollständig. Falls jemand Lust hat, hier mitzuhelfen - gerne melden! https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt
:
Bearbeitet durch User
Martin G. schrieb: > Falls > jemand Lust hat, hier mitzuhelfen - gerne melden! Gerne. Ich bin dir gerade auch schon auf github gefolgt. Also 0x83 Nachrichten sehe ich bei mir garnicht. Das ahoy.py Script liefert bei mir wie gesagt 1-3er Nachrichten. Ich habe in der Excel Datei im Anhang mal 3 Sheets gemacht. Für jede Nachricht eines. Ich habe aktuell am HM-1500 nur 3 Panels. Daher sollte irgendein Wert null sein. (Muss morgen mal prüfen welcher Kanal genau nicht angesteckt ist) Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x übertragen, der Strom und die Leistung jedoch 4x. Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw. geben aktuell Sinn. (bzw. ich sehe es gerade nicht)
Thomas B. schrieb: > Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x > übertragen, der Strom und die Leistung jedoch 4x. Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel Deshalb evtl. nur 2 Messwerte?
Heinz R. schrieb: > Thomas B. schrieb: >> Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x >> übertragen, der Strom und die Leistung jedoch 4x. > > Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel > > Deshalb evtl. nur 2 Messwerte? Und HM-600 auch zwei?
Sergey S. schrieb: > Und HM-600 auch zwei? Ja der HM-600 hat 2 Eingänge mit separaten MPT. Ich hoffe, dass ich dies Wochenende meines Setup endlich soweit bekomme, dass ich auch an meinem HM-600 lauschen kann...
Thomas B. schrieb: > Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung > ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw. > geben aktuell Sinn. (bzw. ich sehe es gerade nicht) Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten: - Spalte T: Energie [Wh] seit letztem Start - Spalte S: aktuelle AC-Leistung [W] - Spalte R: Energie [Wh] seit Geburt - Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum? - Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung um die 0,6°C/0,7°C kalt?
Angehängte Dateien:
Hallo, Ich habe mal ein paar Daten des HM-400 aufgezeichnet zum Vergleich mit meinem AC-seitigen Shelly Plus 1PM. Sieht alles sehr gut aus! Das Setup mit Nano (FDTI Version) und nRF24L01+ zieht sich übrigens etwa 0,35W aus dem USB. Die Scanhäufigkeit habe ich verringert auf ca. 1 mal pro Minute. Ich nutze "RF24_PA_MIN"
Es gibt ein Dokument mit der Modbus-Beschreibung. Evtl. helfen die dort vorhandenen Beschreibungen der Telegramme und Befehle. Quelle: https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
Martin G. schrieb: > Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem > HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten: > > - Spalte T: Energie [Wh] seit letztem Start > - Spalte S: aktuelle AC-Leistung [W] > - Spalte R: Energie [Wh] seit Geburt > - Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum? > - Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung > um die 0,6°C/0,7°C kalt? Hallo Martin, An dem Tag von dem die Aufzeichnung stammt hat ein Gosund Zwischenstecker ca. 1kWh gemessen. Die Gesamtproduktion die die Gosund gemessen hat seit Inbetriebnahme des Inverters liegt bei ca. 240kWh. - Spalte T: Wäre damit zu hoch, und ich würde eher einen Kommawert erwarten - Spalte S: Nachdem es ein ganzer Tag ist hätte ich einen ähnlichen Verlauf wie bei den DC Kurven erwartet. Also erst steigend, dann fallend. - Spalte R: Kommt mir für den Gesamtertrag zu hoch vor - Spalte P: Ggf. sind das auch Werte um 200 herum wenn man den Wert statt durch 10 durch 100 teilt. Muss ich beobachten wie sich das heute entwickelt. (Ggf. Gesamtleistung seit Geburt, dann würde aber der Gosund Mist messen) - Spalte E: Hätte die Temperatur v.a. unterm Tag eher im Bereich 5-10 Grad geschätzt.
Marcel schrieb: > Hallo Oliver > >> Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 >> schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack >> Overflows kämpfe. > Do it :) Hallo Marcel, ich habe deinen Code mit einem ESP8266 Nodemcu am laufen: -musste das getLocalTime(..) nachimplementieren, weil das das nur am ESP32 gibt -musste natürlich die Pins ändern -musste in der Receive-Loop ein yield(); einbauen, da sonst der wdt getriggert hat. habe meine WR und DTU Serial eingetragen .... .... sehe auf den Request zwar ein "ok" .... dann kommt aber keine Antwort vom WR
Hurra, es hat geklappt :) Ich empfange jetzt stabil Daten vom HM-600 aus etwa 15m Distanz. Setup: * HM-600 S/N 114172014650 * Arduin0 Nano V3 * NRF24L01 + separater Spannungsregler (damit geht bei mir RF24_PA_HIGH ohne Probleme) * Software von https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv Hilft es weiter, wenn ich einfach mal laufen lasse und den Output protokolliere und hochlade?
Carsten B. schrieb: > Hilft es weiter, wenn ich einfach mal laufen lasse und den Output > protokolliere und hochlade? Auf jeden Fall. Damit kann man das über einen längeren Zeitraum betrachten. Das macht es einfacher die Werte und Felder in den Telegrammen zu bestimmen!
Hallo, ich habe, HM-1200 3*350 W Panels angeschlossen Arduin0 Nano V3 NRF24L01 + Ich koennte auch Daten sammeln, helfen. Was muss ich tun um dieses Setup zum Fliegen zu bringen. Kurzanleitung moeglich? Danke
Ich hätte jetzt je eine Version von -NR24_SendRcv -Marcel's ESP32 code der auch auf ESP8266/Nodemcu kompiliert und läuft. Wenn das für noch jemanden von Interesse ist bitte melden.
Hallo Martin, ich hätte großes Interesse an der ESP-Version. Versuche mich hier gerade an einem Arduino Mini Pro - bekomme den in Platformio nicht geflasht... ESP8266 würde es evtl einfacher machen Viele Grüße
Auf die Schnelle: Hardware Nano V3 pin --- pin NRF24L01 D2 ----------- IRQ D6 ----------- CSN D9 ----------- CE D11 ----------- MISO D12 ----------- MOSI D13 ----------- SCK Software: https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv Ich habe es im Arduino IDE übersetzt und hochgeladen Seriennummer des HM musst du im Sourcecode eintragen wie folgt (NRF24_sniff.cpp): #define WR1_RADIO_ID ((uint64_t)0x5046017201ULL) // WR1 HM-600 Das ist sind die letzten 4 Byte der S/N Rückwärts plus eine 01 am Ende. Meine S/N ist 114172014650
Carsten B. schrieb: > Ich habe es im Arduino IDE übersetzt und hochgeladen welche Datei lädst Du hier in der Arduino IDE? Müsste es hierzu nicht eine .ino geben
Heinz R. schrieb: > ich hätte großes Interesse an der ESP-Version. Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von Links nach rechts ein ... das 5. byte muss 01 sein. Ich habe den Code auf das originale CircularBuffer vom Arduino portiert, deshalb sind hier auch weniger Files dabei als im GitHub Link von weiter oben. Es sollte auch für Arduino Nano / Uno weiter kompilieren.
...hier ein scan von meinen 2 (HM-350 und HM-700) WR
Carsten B. schrieb: > Ich habe sie einfach umbenannt... Ach das geht? lass uns das gerne mal in einem separaten Thread erörtern? :-)
Angehängte Dateien:
-
220422-excel-01.png
310 KB
Thomas B. schrieb: > Auf jeden Fall. Damit kann man das über einen längeren Zeitraum > betrachten. Das macht es einfacher die Werte und Felder in den > Telegrammen zu bestimmen! Hallo in die Runde, Angehängt die Daten, die ich heute mitgeschrieben habe mit dem HM-600. Zwischendrin hat der Nano 2x kurz neu gestartet (Wackelkontakt), die Bereiche ggf.raus löschen. Ich bin grade dran, das mit der Excel, die hier gepostet wurde ein wenig auszuwerten. Mit den "01" Messages bin ich fertig und komme zu dem Ergebnis auf dem angehängten Sreenshot. Spalte T enthält die addierten Leistungswerte bei der DC-Anschlüsse. Passt grafisch ganz gut überein mit dem, was mein Shelly heute auf der AC-Seite mitgeloggt hat. Ich poste nachher noch meine Auswertung für die weiteren Messages. Viele Grüße Carsten
:
Bearbeitet durch User
Angehängte Dateien:
-
Diagramm.PNG
29 KB -
Diagramm2.PNG
8,5 KB
Hier mal ein Tageslog von meinem HM-1200 es sind 2x 19V Panels in reihe je 130W an einem der 4 Anschlüsse dran. Das ergebniss passt noch nich ganz zu der format description. Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert? bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, was kann das sein ? :)
Angehängte Dateien:
-
220422-excel-02.png
26 KB
Chris A. schrieb: > Hier mal ein Tageslog von meinem HM-1200 > bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, > was kann das sein ? :) Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02 plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die Netzspannung und die Netzfrequenz drin ist. Siehe Bild.
> Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02 > plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die > Netzspannung und die Netzfrequenz drin ist. Siehe Bild. ok, aber Netzspannung und Frequenz ist bei meiner 02.. Anwort nicht zu finden. Oder überseh ich was ? auch bei der 01.. Antwort scheint es einen Unterschied zu geben. Die Amps machen da keinen sinn oder ? 020000BC8B0000000F0009000100010000A6E639 010001015200020032000600A800000283D9A089
Carsten B. schrieb: > Ich poste nachher noch meine Auswertung für die weiteren Messages. Hier nun meine Auswertung, soweit wie ich gekommen bin: Ergebnis Excelauswertung 02.04.2022: 01 Telegramme: Spalte N: U1 0,1V Spalte O: I1 0,01A Spalte O: P1 0,1W Spalte Q: U2 0,1V Spalte R: I2 0,01A Spalte S: P2 0,1W 02 Telegramme: Spalte N: E seit „Geburt“ ? Wh Spalte O: E DC akt. Tag ? Wh Spalte Q: E AC akt. Tag ? Wh Spalte R: U AC 0,1V (Netzspannung) Spalte S: F 0,01 Hz (Netzfrequenz) Ob die kumulierten Tagesangaben zutreffen zeigt sich Morgen... 03 Telegramme: empfange ich keine 81 Telegramme: kann ich mir keinen Reim drauf machen 83 Telegramme: kann ich mir keinen Reim drauf machen Ergänzung zum Setup des HM-600: An beiden Eingängen sind je 350Wp angeschlossen Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht messen.
:
Bearbeitet durch User
Manchmal bin ich einfach naiv-pragmatisch und hin und wieder klappt das sogar... Ich bin jetzt nicht der Programmierprofi und habe bisher nur die Arduino-Umgebung benutzt. Bevor ich mir die Mühe mache, eine neue Umgebung aufzusetzen, dachte ich, ich probiere es einfach mal :-)
Carsten B. schrieb: > > Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum > erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht > messen. Guten Abend, die Wechselrichtern werden aus dem DC Anteil versorgt und deshalb sind sie bei wenig Licht bzw Nacht nicht ansprechbar. ich lese hier schon eine ganze Weile mit. Momentan habe ich einfach keine freien Zeitslots mich hier einzubringen, leider. Auch ich hätte gerne den momentan benutzten DTU Pro ausser Betrieb und würde gerne irgendwo auf meinem Synology NAS ein Datengrab schaffen um meine Ertragszahlen zu speichern. Was mir persönlich aufgefallen ist, dass aus meinen 60 Wechselrichtern in allen Paketen die Seriennummern nicht fortlaufend einsortiert sind sondern immer in einer gewissen Struktur und hierbei meine ich nur die letzten 4 Ziffern. Kann es sein dass sich darin die Kanalnummern für den jeweiligen Wlan Kanal verschlüsseln, man stellt sich vor dass bei einer grösseren Anlage sonst schnell zu einer Menge Datenkollisionen kommen würde. Viel Erfolg in die Runde, programmiere aus Leidenschaft in C und würde gerne helfen, habe aber momentan zu viel andere Dinge die in der Priorität weiter oben sind Solong B
Chris A. schrieb: > Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert? > bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, > was kann das sein ? :) Hallo Chris, die Telegramme von HM-1200 und HM-600 werden nicht kompatibel sein. Siehe: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Schau dir mal das Excel in Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" an In den 1er Messages habe ich einmal die Spannung, 2x den Strom und 2x die Leistung. In den 2er Messages habe ich bisher 1x die Spannung und 1x die Leistung gefunden. Ich habe nur 3 Panels dran, darum vmtl. nur insgesamt 3x Strom und Leistung. In den 3er Messages habe ich nur die AC Spannung gefunden. Werde mir aber deinen Dump noch ansehen.
Carsten B. schrieb: > 81 Telegramme: kann ich mir keinen Reim drauf machen > > 83 Telegramme: kann ich mir keinen Reim drauf machen > > E Wenn Du in das von mir weiter oben bereitgestellte Dokument (Hoymiles Modbus implementation..., Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") ab Seite 8 unter 4.2.1 schaust, dann wirst Du dort bei den Function Codes diese Werte als Antwort auf fehlerhaften "Read Single Device Status" und "Read Device Data" finden. Könnte vielleicht passen...?
:
Bearbeitet durch User
Moin Peter, danke für den Hinweis, kann wirklich sein, dass 81 nur Fehlerhafte Übertragungen sind. Bei den 02-Messages bin ich mir bei Spalte Q inzwischen recht sicher, dass Spalte T die WR-Temparatur ist. O und Q sind vermutlich eher der Tagesertrag je Kanal. 02 Telegramme: Spalte N: E seit „Geburt“ Wh (sieht gut aus, zählte heute morgen weiter hoch) Spalte O: E DC akt. Tag ? Wh (vielleicht doch E für Kanal 1 ?) Spalte Q: E AC akt. Tag ? Wh (vielleicht doch E für Kanal 2 ?) Spalte R: U AC 0,1V (Netzspannung) (passt) Spalte S: F 0,01 Hz (Netzfrequenz) (passt) Spalte T: Temperatur 0,01 °C (neu) Mal sehen, was der Tag bringt... Carsten
Angehängte Dateien:
-
plot_response_times.png
39 KB
Mal zwischendurch ein Themenwechsel zu "Channel Hopping": Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen "Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im Anhang. Da zeichnet sich klar ab, dass * die "0x01"-Nachrichten immer nach ca. 18 ms eingehen, * die "0x02"-Antworten immer nach ca. 67 ms und * die "0x83"-Antworten immer nach ca. 116 ms. Das ist für "Anfrage auf Kanel 40, Antwort auf Kanal 3".
Martin P. schrieb: > Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die > Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann > trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von > Links nach rechts ein ... das 5. byte muss 01 sein. Hallo Martin, danke, scheint zu funktionieren Ich bekomme jetzt beiliegende Daten - sieht richtig aus? Es ist ein HM-1200 - nur 2 Eingänge belegt Aktuell liefert er ca. 35W Viele Grüße
Angehängte Dateien:
-
HM1200_Heinz.PNG
2 KB
Heinz R. schrieb: > Ich bekomme jetzt beiliegende Daten - sieht richtig aus? > > Es ist ein HM-1200 - nur 2 Eingänge belegt > Aktuell liefert er ca. 35W Hi Heinz, ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber keine Leistung. An welchen Anschlüssen hast du die Panels dran ? links oder rechts? Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann nichts sinnvolles mehr bei der 01 Antwort.
Chris A. schrieb: > Heinz R. schrieb: >> Ich bekomme jetzt beiliegende Daten - sieht richtig aus? >> >> Es ist ein HM-1200 - nur 2 Eingänge belegt >> Aktuell liefert er ca. 35W > > Hi Heinz, > > ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber > keine Leistung. > > An welchen Anschlüssen hast du die Panels dran ? links oder rechts? > Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann > nichts sinnvolles mehr bei der 01 Antwort. Das sieht so aus wie bei meinem HM-1500. Allerdings würde ich nur Spalte N als Spannung interpretieren. - Spalte N: 26,2V - Spalte O: 0,02A - Spalte P: 0,03A - Spalte Q: 0,6W (26,2 x 0,02 mit Rundungsfehlern?) - Spalte R: 0,9W (26,2 x 0,03 mit Rundungsfehlern?)
Chris A. schrieb: > ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber > keine Leistung. > > An welchen Anschlüssen hast du die Panels dran ? links oder rechts? > Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann > nichts sinnvolles mehr bei der 01 Antwort. Hallo Chris, je ein Panel aktuell pro Seite Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt Ich messe an ihm ca. 23V, ca. 10mA Das andere Panel hat aktuell ca. 29V, ca. 1 A Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte ungefähr passen? Hast Du DIr eine Excel-Vorlage gebaut? Viele Grüße
> Hallo Chris, > > je ein Panel aktuell pro Seite > > Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt > Ich messe an ihm ca. 23V, ca. 10mA > > Das andere Panel hat aktuell ca. 29V, ca. 1 A > > Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte > ungefähr passen? > > Hast Du DIr eine Excel-Vorlage gebaut? > > Viele Grüße Hi Heinz, ich hab das hier verwendet: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo zusammen, endlich habe ich meinen WR HM-700 bekommen, läuft auch, aber antwortet nicht. grmpf Ich habe sowohl eigene Entwicklungen als auch adaptierte Sniffer am Arduino Mega2560 erfolglos versucht. Zudem widersprechen sich aktuell die Aussagen bzgl. der nötigen Seriennummern-Bytes etwas: Martin P. schrieb: > Heinz R. schrieb: > Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die > Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann > trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von > Links nach rechts ein ... das 5. byte muss 01 sein. In der (ursprünglichen) github-Doku von Petersilie heisst es: > Hier werden 4-Byte-Adressen verwendet, die direkt aus den letzten 8 Stellen der Seriennummer des Wechselrichters bzw. der DTU gewonnen werden... Verwirrung... ;-) Sind es nun die ersten 4 oder die letzten 4? - Ich nehme mal an, es sind die letzten 4 BCD Bytes der Seriennummer. Jetzt ist noch die Frage, wie rum die Dinger in das Define rein müssen. MSB oder LSB neben der abschließenden 0x01? Laut Doku würde ich mal annehmen, dass das MSB daneben kommt. Also z.B. bei WR Serno. 11 41 74 60 84 85: #define WR1_RADIO_ID ((uint64_t)0x8584607401ULL) Ich habe beide Varianten schon getestet, die PA settings sowie SPI speed rauf und runter genudelt. - Nix geht... :-( Config und erweiterte Ausgabe bei mir wie folgt - ich sende nur das 80er Telegramm: Radio 1: SPI Speedz = 1 Mhz STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xdeadbeef01 0x2888817201 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0xdeadbeef01 RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20 EN_AA = 0x00 EN_RXADDR = 0x02 RF_CH = 0x03 RF_SETUP = 0x23 CONFIG = 0x37 DYNPD/FEATURE = 0x00 0x00 Data Rate = 250 KBPS Model = nRF24L01+ CRC Length = Disabled PA Power = PA_LOW ARC = 15 Send... CH40 157460848572818828800B00623C8EA30000000500000000375EC7 Dest: 0174608485 WR1 TX error! 288828 37640 Send... CH40 157460848572818828800B00623C8EA5000000050000000097754A Dest: 0174608485 WR1 TX error! 2488380 37700 usw. Achja: Ich habe das lustige PA-Modul mit externer Antenne, das hängt über den mitgelieferten LDO Adapter am Arduino 2560 folgendermaßen: VCC->5V, GND->GND, SCK->52, MI->50, MO->51, IRQ->2, CE->7, CSN->8 IMHO sollte das passen. Was übersehe ich? Hat irgendjemand einen heissen Tipp? Danke für die Geduld, Lars
Lars B. schrieb: > Also z.B. bei WR Serno. 11 41 74 60 84 85: > #define WR1_RADIO_ID ((uint64_t)0x8584607401ULL) ja genau so - sorry für die Verwirrung!
Hi Martin, danke für die Bestätigung. - Ich suche dann mal weiter, wo der Hund begraben liegt... ;-) ***UPDATE *** Habe den begrabenen Hund gefunden! :-) :-) :-) Der Receive-Interrupt im Arduino-Code wurde nicht aktiviert/deaktiviert. Die Routine wird zwar über das attach eingehängt, aber die existierenden Defines #define DISABLE_EINT EIMSK = 0x00 #define ENABLE_EINT EIMSK = 0x01 lassen den klassischen Arduino eher kalt. ;-) Ich habs mal durch folgendes ersetzt und dann klappert das auch: #define DISABLE_EINT noInterrupts(); #define ENABLE_EINT interrupts(); Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe anbei... :) Cheers, Lars
:
Bearbeitet durch User
Lars B. schrieb: > Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe > anbei... :) ja das mit den Interrupts musste ich für den ESP auch so machen ... Ich lese ja auch einen HM-700 (und einen HM-350) aus und habe mittlerweile den von mir auf ESP angepassten NF24Send_Rcv Code auch um das parsing/printing und MQTT publishing erweitert ... bei der Unterscheidung der Geräte hapert es noch ein wenig ... und die Temperatur finde ich beim HM-700 nicht an der Stelle wie hier im Thread beschrieben. Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch gerne ...
Hallo, ich wurde gerade hierauf verwiesen: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fgzll_02_user_guide.html&cp=4_1_0_5_0 Kann es sein das dieses Gazell unser Channel hopping ist? Auch wenn sich oben genannte Doku auf einen nRF52833 bezieht steht bei den Features: Backward compatible with legacy nRF24L Series Gazell.
Hallo, hier scheint wohl so eine Implementierung des gzll Protokolls zu sein https://github.com/wangdong/cpod/blob/master/lib/nrf24/gazell/common/gzll.c Leider kann das wohl die nRF24 lib nicht.
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... ch bekunde Interesse :-) Habe allerdings einen HM-1200
Hi Thomas, guter Hinweis mit dem Gazell-Protokoll... das hatte ich schon erfolgreich verdrängt. ;-) Das Kommunikationsschema von Gazell sieht aber IMHO anders aus. Das ist Device-getriggert und der Host lauscht erstmal nur und antwortet auf Anfragen der Devices. Insofern müssten die HMs von sich aus auf einem Anker-Kanal "ungefragt" vor sich hin senden. Das tun sie aber nach aktuellem Kenntnisstand nicht, sondern antworten auf Anfragen des Hosts. Das Kommunikationsschema stellt sich für mich eher "klassisch" dar, also Anfrage Host->Device, dann Antwort Device->Host. Die max. Anzahl der für die DTUs spezifizierten "Solarmodule" ist mit 99 auch deutlich höher, als die für Gazell maximal spezifizierten 8 Teilnehmer. ...aber ich kann mich ja auch irren... ;-)
Beitrag #7024347 wurde vom Autor gelöscht.
Hallo zusammen, ich habe auch ein wenig an meinem HM600 gelauscht. Ich kann die Informationen für den HM600 wie im Anhang bestätigen. Ich hoffe, das hilft dem einen oder anderen weiter. Vielen Dank für die tollen Beiträge hier!
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... Ja, da hätten mein HM-600 und ich auch Interesse :)
lpb schrieb: > Hallo zusammen, > > ich habe auch ein wenig an meinem HM600 gelauscht. > Ich kann die Informationen für den HM600 wie im Anhang bestätigen. Ich habe auch weiter gelauscht und die 01-Message kann ich so bestätigen an Hand meiner Daten. Bei der 02-Message bin ich unsicher, was Gesamt-Ertrag und Wochenertrag angeht. Der letzte Wert ist die AC-Leistung und nicht wie Samstag noch von mir vermutet die Temperatur. Wenn ich mir die HM-Software ansehe, würde ich aber denken, das irgendwo noch die Temperatur versteckt ist...
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... Da hätte ich großes Interesse :-)
Carsten B. schrieb: > Martin P. schrieb: >> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch >> gerne ... > Da hätte ich großes Interesse :-) Ok - ein Zipfile gibt es hier: https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0 Hab leider gerade keine andere Möglichkeit den Code zu sharen (Handy) Disclaimer: das Original ist nicht von mir - ich habe nur Code und Wissen aus dem Forum kombiniert, so wie es für mich nützlich ist. Es ist auch noch nicht besonders ausführlich getestet. Es unterstützt mehrere Wechselrichter, denen man in der Definition einen Namen geben kann um sie an der Konsole/Mqtt unterscheidbar zu machen. Das Mqtt topic und Format hab ich mal so gewählt, wie es zu meinem Homesetup passt. Was m.E. noch fehlt: zB das Timing entspannen Nur requests schicken, in der Nacht deepsleep Und vieles mehr Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe leider nur die Basic DTU und kann daher die Nachrichten nicht loggen ….
Martin P. schrieb: > Carsten B. schrieb: >> Martin P. schrieb: >>> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch >>> gerne ... >> Da hätte ich großes Interesse :-) > > Ok - ein Zipfile gibt es hier: > Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe > leider nur die Basic DTU und kann daher die Nachrichten nicht loggen …. Danke, sehr cool. Ich hoffe, ich finde morgen die Zeit es zu installieren. Das Thema Leistungsbegrenzung interessiert mich auch sehr. Gemeinsam mit mehreren kommen wir da sicher weiter.
Hallo, ich vermute die Inverter-Temperatur beim HM600 im cmd 131 (83), byte 4.
1 | 2022-04-04T11:23:54.973594Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=84, uk3=1000, uk4=393, uk5=1757, uk6=47334 |
2 | 2022-04-04T11:26:28.900800Z MSG src=72220143, dst=72220143, cmd=131, uk1=1, uk2=36, uk3=1000, uk4=397, uk5=1765, uk6=13181 |
3 | 2022-04-04T12:16:51.839332Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=98, uk3=1000, uk4=460, uk5=1998, uk6=53222 |
4 | 2022-04-04T14:03:09.826004Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=59, uk3=1000, uk4=516, uk5=2492, uk6=12253 |
5 | 2022-04-04T14:36:51.087562Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=46, uk3=1000, uk4=496, uk5=2642, uk6=42061 |
6 | 2022-04-04T17:20:05.465478Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=0, uk3=0, uk4=327, uk5=3372, uk6=17290 |
7 | 2022-04-04T17:20:33.714355Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=0, uk3=0, uk4=327, uk5=3375, uk6=25778 |
Quelle: Relevanter Log-Output mit https://github.com/Sprinterfreak/ahoy/tree/dev
Hallo, habe gerade mal ein poormans Channel hopping über die bekannten Kanäle beim empfangen gefrickelt. Siehe da: Mehr erfolgreiche Übertragungen als Fehlschläge. Also wir reden jetzt von mindestens 3-4 vollständigen Datensätzen pro Minute. Ich habe ein HM600 und bekomme cmd=1,2,131 nun etwa 4x/Minute. https://github.com/Sprinterfreak/ahoy/commit/86715ac116188f27247d2beb65fe0f3a39a2eeab
Hallo lpb so ganz passen die Werte für Week und Total bei mir nicht. Ich notiere mir jetzt schon ein paar Tage day1 und day2 power (Summe ist Gesamtleistung am Tag). Die Summe der letzten 5 Tage + aktuell ergeben bei mir 10.000, aber im Telegramm gibt das week power nur 5102 (Stand jetzt) aus. Da meine Anlage seit 1.1.2022 läuft, schätze ich mal eine Gesamtleistung von ca 100.000 Wh, im HM-Telegramm stehen aber 68.990 Wh. Scheint mir etwas wenig zu sein. Bist du dir mit den Daten sicher?
Jan-Jonas S. schrieb: > habe gerade mal ein poormans Channel hopping über die bekannten Kanäle > beim empfangen gefrickelt. Also ich kann bestätigen, dass mit der Modifikation von Jan teilweise mehr Pakete empfangen werden. Also z.B. auf eine einzige 0x80 Anfrage kam folgendes:
1 | 2022-04-05 18:14:04.512796 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 01 00 01 01 36 00 08 00 08 00 1a 00 18 00 01 54 76 83 |
2 | 2022-04-05 18:14:04.559483 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 02 00 01 57 4e 00 b5 00 ac 01 33 00 07 00 02 00 17 b6 |
3 | 2022-04-05 18:14:04.595240 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 03 00 05 00 01 5e 4f 00 00 02 4e 00 a9 00 06 08 dd b5 |
4 | 2022-04-05 18:14:04.641578 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 84 13 89 00 49 00 c9 00 03 01 57 00 55 00 07 39 23 16 |
Ein 0x84 hatte ich vorher noch nie gesehen. Man achte auch auf die verschiedenen Kanäle.
Angehängte Dateien:
-
ChannelMID.png
3,9 KB
Ich hatte gerade auch die Möglichkeit von einem HM-600 eine Matrix über die Empfangenen Message ID's vs. Channel Number zu bilden (siehe Anhang). 1er und 2er scheinen nur auf Kanal 3 zu kommen. Ob das nun Zufall ist, oder Jans Implementierung so geschuldet ist (das zufällig durchs Timing immer die 1er und 2er auf Channel 3 erscheinen und andere ggf. verworfen werden) kann ich erstmal nicht sagen. Also ich muss sagen, ich hab keine Ahnung von Channel Hopping Algorithmen usw... ich stochere hier nur etwas in den Daten.
:
Bearbeitet durch User
Martin G. schrieb: > Mal zwischendurch ein Themenwechsel zu "Channel Hopping": > > Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen > "Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im > Anhang. > > Da zeichnet sich klar ab, dass > > * die "0x01"-Nachrichten immer nach ca. 18 ms eingehen, > * die "0x02"-Antworten immer nach ca. 67 ms und > * die "0x83"-Antworten immer nach ca. 116 ms. > > Das ist für "Anfrage auf Kanal 40, Antwort auf Kanal 3". Das würde doch dafür sprechen das Channel Hopping mal zufällig zu gestalten. Aktuell fängt die Implementierung von Jan-Jonas ja immer mit Kanal 3 an und macht dann mit den Kanälen 23, 61, 75 immer die selbe Reihe durch. Bei einer zufälligen Abfolge könnte man auch statistische Auswertungen der Daten vornhemen. So wie der Code aktuell ist bleibt die Präferenz für die schnellen Antworten auf Kanal 3 wie von Martin / Petersilie ausgewertet.
Hallo, bekomme jetzt bei meinem HM-600 nahezu sekündlich alle Daten. https://github.com/Sprinterfreak/ahoy/tree/dev Habe das Channel Hopping nochmal überarbeitet, sodass der RX Start Channel mit jeder Transaktion rotiert. Das empfängt jetzt auch cmd=1,2 auf verschiedenen Channeln. Nachdem ich AutoAck mal auf True gesetzt habe findet die Kommunikation jetzt nahezu zuverlässig statt. An jemanden mit ner DTU und Sniffer: Kann mal wer versuchen herauszufinden wie man das "Zero Export Control"-Feature setzt? Laut Bedienungsanleitung kann der HM-600 ja auch noch Fehlercodes ausgeben. Eine Tabelle ist in der Bedienungsanleitung, jedoch finde ich keine halbwegs passenden Werte in den bisher bekannten Datensätzen.
In der nRF24L01+ Product Specs findet sich noch der folgende Absatz auf Seite 34 von 78: https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf?cp=12_4_0_0 > Two packet loss counters are incremented each time a packet is lost, ARC_CNT and PLOS_CNT in the > OBSERVE_TX register. The ARC_CNT counts the number of retransmissions for the current transaction. > You reset ARC_CNT by initiating a new transaction. The PLOS_CNT counts the total number of retrans- > missions since the last channel change. You reset PLOS_CNT by writing to the RF_CH register. It is possi- > ble to use the information in the OBSERVE_TX register to make an overall assessment of the channel > quality. Das würde dafür sprechen, daß es bei Übertragungsfehlern auf einem der bekannten Kanäle eine Retransmission auf einem der anderen Kanäle gibt um ggf. Störungen durch WLAN, PCM oder andere Funkteilnehmer auszugleichen. Offenbar scheint das "Channel-Hopping" ja auch speziell im Zusammenhang mit den vermuteten "Fehlermeldungen" 0x83 (und evtl. 0x81 / 0x82 ?) in Verbindung zu stehen. Oder täuscht mich da mein Eindruck ?
Hi, habe ein HM600; 0x83 (cmd=131) ist bei mir ein Werteblock, keine Fehlermeldung Hier stecken vmtl. load%, Temperatur, Status, Statuswechselzähler drin. 0x81 (cmd=129) ordne ich den Fehlern zu. Das kommt zurück, wenn man Müll mit korrekter CRC hin schickt. https://www.alpha-solar.info/media/Dokumente/Wechselrichter/Hoymiles%20HM/Deutsch/Bedienungsanleitungen/HM-600%20%20HM-800%20Bedienungsanleitung.pdf Alarmcode 129 deckt sich u.A. auch mit der Fehlertabelle in der Bedienungsanleitung vom HM-600. "Softwarefehlercode 129". Zufall? Dann könnte der WR ja prinziepiell auch die anderen Alarmcodes senden. Dafür bräuchte es aber eine Art Session zwischen der DTU und dem WR. Weil ich habe noch keine unbekannten Pakete rein purzeln sehen, wenn ich z.B. das Netz abtrenne. Das müsste dann laut Anleitung 0x93/147 oder 0x94/148 sein
zu den genutzten Frequenzen.
Bei meinem HM-600 ist es immer so:
Wenn ich ein 80 Telegramm sende auf 2403, dann antwortet der WR mit den
Antworten 01,02,83 auf den möglichen Frequenzen 2423,2440,2461 MHz.
also bei TX 2403, Antworten auf 2423,2440,2461
bei TX 2423, Antworten auf 2403,2440,2475
bei TX 2440, Antworten auf 2403,2423,2475
bei TX 2461, Antworten auf 2403,2423,2475
bei TX 2475, Antworten auf 2403,2423,2440
Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt
man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie
empfangen.
:
Bearbeitet durch User
B. G. schrieb: > Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt > man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie > empfangen. Hallo BG, hast du es mal mit einer 0x80 0x11 Anfrage versucht? Da dürften andere Daten zurückkommen, siehe hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Angehängte Dateien:
martin schrieb: > Hallo BG, > hast du es mal mit einer 0x80 0x11 Anfrage versucht? Das muß ich mal testen. Anbei noch ein jpg , NRF sendete auf 2475. HM-600 antwortete auf 2440,2423,2423 (3. Antwort 83 nicht mehr auf jpg) Man sieht, wann ich beim Scan auf die Frequenz kam und den Block quittiert habe.
Nach einiger Zeit hatte ich auch noch einmal Gelegenheit mich mit der Materie zu beschäftigen. Momentan bin ich noch der Meinung, dass das Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen. Auf den unterschiedlichen Kanälen kommen auf die 0x80 Anfrage immer 3 verschiedene Antworten mit verschiedenen Ids, wenn Sie nicht durch irgendwelche Übertragungsprobleme gestört werden. Ich empfange die Ids 0x01 bis 0x0B. Siehe beigefügter Beispiel Dump. Da ist mit Sicherheit auch etwas dabei für Inverter mit mehr als 2 MPP Trackern. Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt. https://github.com/OFreddy/hm_poll Eventuell kann man das nutzen und für verschiedene Platformen anpassen um solche Probleme zu vermeiden, dass bei einem nano z.B. andere Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der hm_config_x.h geschehen. Wer dort erweitern möchte ist herzlich willkommen. Momentan unterstützt die Library 4 Inverter Instanzen, ist aber erweiterbar. Das Channel Hopping kann noch optimiert werden. Geplant habe ich eine Art Callback Funktion, bei der die Library empfangene gültige Pakete an die Applikation signalisiert. Diese könnten dann von der Applikation nach Datenpunkten zerlegt werden.
:
Bearbeitet durch User
Angehängte Dateien:
martin schrieb: > hast du es mal mit einer 0x80 0x11 Anfrage versucht? Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85 zurück, bei 800B 01,02,83
Hallo Martin, 80 0b ist das "Zeit setzen" was mit normalen Werten antwortet 80 11 liefert bei mir cmd=129, Error 80 03 liefert ein ganzen Haufen, siehe Log. u.A. cmd=1-7, wobei die Werte in 1 und 2 nicht identisch sind wie bei 0b Hab das mal durchprobiert. 80 0b, 0c, 0d sind sehr ähnlich aber Werte scheinbar mit einem falschen Faktor. Das ganze Tageslog muss ich mal aufarbeiten. Da ist auf jeden Fall einiges drin, was neu ist und bisher keinen Sinn ergibt, wenn man mit den Anfragen spielt und keinen Fehler schmeißt.
Oliver F. schrieb: > Momentan bin ich noch der Meinung, dass das > Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein > Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen. Das mit dem "Gießkannenprinzip" ist bisher auch mein Eindruck: Vielleicht so etwas in diese Richtung: - Die "DTU" sendet eine Anfrage auf mehreren Kanälen "zeitlich dicht hintereinander". - Die WR hören permanent auf einem der Kanäle, und schalten nur mal einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hören. - Die WR antworten auf mehreren Kanälen "zeitlich dicht hintereinander" - Die DTU hört permanent auf einem der Kanäle, und schaltet nur mal einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hört. Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen Empfänger scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt. Hier wäre es toll, wenn jemand mit einem SDR-Sniffer und DTU derartige Muster beobachten könnte. Ich meine, @tbnobody hat sowas zumindest ansatzweise mal gesehen? Leider ist meine DTU noch immer nicht geliefert worden - und viel Hoffnung mache ich mir nicht mehr...
Martin G. schrieb: > Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen *Empfänger* > scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes > Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt. Das ist das, was ahoy.py aus meinem Fork sieht. > Ich meine, @tbnobody hat sowas zumindest ansatzweise mal gesehen? Ja, in meinen Logs. Heute Nacht nach Einspeiseende werden meine Logs wieder untersucht. Mit Sicherheit. Mit entsprechenden Änderungen in ahoy.py, die genau das dämliche Verhalten mit verbessertem hopping-code zeigen, was ich so den Tag über bereits beobachtet habe.
:
Bearbeitet durch User
Das glaube ich eher nicht. Ich meine, die WR scannen die wenigen genutzten Kanäle durch. Durch das Retransmit erkennen sie immer die Nachricht. Ebenso können die DTUs oder eigene NRFs durch das Scannen sicher alle Telegramme empfangen. So hab ich das jedenfalls bei mir. Wenn ich auf einer anderen Frequenz sende, kommen immer gleich die Antworten. Ebenso ist es beim Empfang der Antworten.
Das ist bei mir (HM600) eben anders. Bei TX auf einem anderen Kanal als 40 kommt nichts. Nie. Wenn ich nur auf einem fixen Kanal, auch über die Zeit empfange, bekomme ich nur hin und wieder mal ein einzelnes Paket. Wenn ich nach dem Tx über die Kanäle scanne, bekomme ich recht zuverlässig alle Pakete. Jedes mal auf anderen Kanälen. Auch nach einem Tx die Antwortpakete nacheinander auf unterschiedlichen Kanälen.
Der Code, der das generiert ist hier: https://github.com/Sprinterfreak/ahoy/blob/dev/tools/rpi/ahoy.py Am Ende habe ich ein wenig mit den Tx-Daten gespielt, da sind sicher interessante Rohdaten dabei.
Angehängte Dateien:
-
2022-04-06_19_05_49.png
28 KB
Mein Testprogramm funktioniert jetzt so, dass die simulierte DTU die Kanäle durchwechselt und dann auf einem der Kanäle lauscht. Empfängt es eine Antwort, so bleibt es auf dem Sendekanal und wechselt nur noch die Empfangskanäle durch. Dabei empfängt es immer auf einem der anderen Kanäle bis zu 3 verschiedene Frames. Siehe Screenshot. Wechselt auch bei jedem mal auch der Sendekanal kommen deutlich weniger Antworten. Voraussetzung ist allerdings, dass der Request mit 0x80 0x11 beginnt. Verwende ich die 0x80 0x0B kommen nur 0x01, 0x02 und 0x83 Antworten.
@janjonas_s - Wow! Phänomenal! Mit Deinen Channel-Hopping-Versuchen kommen auf jeden Fall wesentlich häufigere Antworten. Und ein paar neue Feldbedeutungen hast Du auch eingepflegt. Ich hab Deine Commits mal gemerged, danke! Hatte noch ein paar lokale Änderungen, die sind jetzt auch drin. Die JSON-Daten enthalten jetzt alle Infos, die wir bisher erarbeitet haben. * https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py
Hallo Martin, danke. So ganz "richtig" kann das alles noch nicht sein. Speziell weil wohl z.B. cmd=1,2,3 nicht immer den selben Inhalt haben. Dies ist wohl noch zwischen Modellen und je nachdem was man anfragt unterschiedlich. Siehe z.B. mein ahoy.log.gz um 17:46 rum. Da habe ich mit den Anfragedaten gespielt. Bisher habe ich damit allerdings mit meinem HM600 die höchste Wahrscheinlichkeit erziehlt auf eine Anfrage möglichst alle Antworten zu bekommen. Ich habe die ahoy.conf erweitert, sodass man da seine DTU-, Inverter serial und broker eintragen kann. Wenn man die außerhalb des Repos lagert und die ahoy.py vom Ort der ahoy.conf startet, geht das Updaten leichter.
:
Bearbeitet durch User
So langsam wird mir klar, warum ich auf dem WLAN-Band so einen hohen Hintergrundstörnebel gemessen habe. Echt bizarr.
also ich habe die ESP8266 Version jetzt auch soweit, dass man sie wo headless parken könnte (musste auch einen 100uF und Dipol-Antenne an die nrf24l01 Platine löten, um beide WR empfangen zu können) .. geschickt werden Messwerte per Mqtt und gelogged wird per rsyslog. Sonnenaufgang und Untergang wird berechnet um so über Nacht in DeepSleep gehen zu können. Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste, bekomme ich: Vom HM700: viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 mit Temp (hier scheint der Wert auch nicht zu stimmen) Vom HM350: Bekomme ich nur 01 DC Daten und etwa halb so oft wie vom HM700 Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der Python Version breiter nach dem HM350 zu loggen.
Martin P. schrieb: > Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der > Python Version breiter nach dem HM350 zu loggen. Hi. Könntest Du mal die Bibliothek aus https://github.com/OFreddy/hm_poll ausprobieren? Es würde mich interessieren welche Antworen von anderen WR kommen. Ich kann nur mit HM-600 loggen. Bei Fragen einfach melden.
:
Bearbeitet durch User
Martin P. schrieb: > Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht > ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste, > bekomme ich: Das vermute ich, weil meine Versuche da eher blindes Huhn spielen. Wenn da tatsächlich Gazell, oder in Teilen Gazell, dahinter steckt wären die Channel vorhersagbar. > Vom HM700: > viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 > mit Temp (hier scheint der Wert auch nicht zu stimmen) Das kann gut sein. Habe ich ja gestern bei meinem HM600 auch provoziert, als ich das byte nach 0x80 im "Zeit setzen" verändert habe. Das hat die Werte im cmd=2,131 um irgendwas faktorisiert. Gut möglich, dass da jeder WR einen eigenen Requests braucht. Sicher jedenfalls sein eigenes Schema hat wie die Payload(s) aufgebaut ist. Glaube Thomas frickelt schon an Modellbezogenen Dekodern? Thomas hat gestern aus meinen Daten auch komische Timing-Effekte extrapoliert Sah aus als ob über die Zeit (range unbekannt) mit meinem Hopping Werte nach einem Muster mal mehr und weniger werden. > Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der > Python Version breiter nach dem HM350 zu loggen. Mein Gedanke war auch schon 5 nRF's als reinen Receiver, je einen Pro Kanal, laufen zu lassen. Ich hab leider nicht die Möglichkeit ein Spektrum im Gigahertz-Bereich aufzuzeichnen.
Oliver F. schrieb: > Hi. > Könntest Du mal die Bibliothek aus > https://github.com/OFreddy/hm_poll > ausprobieren? Es würde mich interessieren welche Antworen von anderen WR > kommen. Ich kann nur mit HM-600 loggen. Hallo Oliver, anbei ein Scan von HM350 und HM700. das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC erscheinen schlüssig und passen auch zu den Shelly Werten.
> Hallo Oliver, > > anbei ein Scan von HM350 und HM700. > > das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem > Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC > erscheinen schlüssig und passen auch zu den Shelly Werten. Hallo Martin, vielen Dank, super das Du das gemacht hast. Aber das verstehe ich nicht. Bei mir sieht das ganz anders aus. Ich erhalte eigentlich auf jede Anfrage eine Antwort von den Wechselrichtern. Kann es sein, dass sie bei Dir nicht in Reichweite sind? Oder sind sie zu nahe? Du verwendest PA_HIGH. Ich hatte auch schon das Problem, dass das Verhalten schlechter wird, wenn die Sendeleistung zu hoch ist, oder die 3.3V Versorgung für die RF24 Module zu schlecht ist.
ja leider sind meine beiden WR ein Stück voneinander entfernt. Bei meinem 2. Board mit ESP8266 + Dipol Antenne (selbstgebaut) kommen auch wesentlich mehr Messages ... vielleicht kann der Spannungsregler am NodeMCU einfach mehr leisten, als der des Nano. Wenn der Laptop wieder aufgeladen ist (anders geht es leider nicht, wo ich beide WR empfange) kann ich es ja nochmals mit dem Dipol Board und PA_LOW probieren. Morgen sollte ich außerdem so ein Board mit PA + LNA bekommen.
Martin P. schrieb: > Vom HM700: > viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 > mit Temp (hier scheint der Wert auch nicht zu stimmen) Witzig, das deckt sich genau mit meiner Erfahrung (siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"). "Oft" 01, "seltener" 02, sehr selten 131. Mysteriös. Aber wir sammeln eifrig weiter...
Angehängte Dateien:
-
HM-1500_20220407_01.png
37 KB
Hallo, dank Jans Modifikation habe ich einen ganzen Tag aufgezeichnet und bei fast allen 0x80 vier Antworten bekommen. Dadurch konnte ich schon schon viele Felder identifizieren. Siehe Anhang. (Die #NV bitte ignorieren, die benötige ich zum Diagramme rendern) Spalte F - G zeigen die Rohdaten. Spalte AH bis BA die bisher bekannten Felder. Vielleicht hilft es jemanden. (Und DC1-4 sind bisher beliebig zugewiesen. Da müsste ich mal alle Panels bis auf eines abstecken und das genau machen)
:
Bearbeitet durch User
Angehängte Dateien:
-
HM-1500_20220407_02.png
29 KB -
HM-1500_20220407_02_graph.png
140 KB
Und ich glaube ich habe auch die Temperatur gefunden...
Angehängte Dateien:
-
HM-1500_20220407_03.png
25 KB -
Leistungsfaktor_Grafana.png
93 KB -
Leistungsfaktor_RF24.png
43 KB
Und ich glaub ich hab den Power Faktor gefunden. Zumindest korreliert der Graph recht gut zu dem was der Gosund Zwischenstecker aufzeichnet (und im Grafana landet).
B. G. schrieb: > martin schrieb: >> hast du es mal mit einer 0x80 0x11 Anfrage versucht? > > Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85 > zurück, bei 800B 01,02,83 Hallo B. G., könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere Pakete und Frequenzen interessieren.
Angehängte Dateien:
Thomas B. schrieb: > könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse > nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere > Pakete und Frequenzen interessieren. Das Bild vom 6.4. ist ja noch verfügbar. Ich hab gerade nochmal so eine Aufnahme gemacht. Komischerweise sendet der HM-600 gerade andere Pakete. Anbei der Frequenzverlauf über die Zeit und die empfangenen Pakete.
Angehängte Dateien:
nochmal eine kleine Aufnahme. Jetzt sendet der HM-600 wieder anders. Aufnahme ist etwas schwach, aber man erkennt die Frequenzen noch.
Angehängte Dateien:
-
HM-1500_20220408_01.png
10 KB -
HM-1500_20220408_01_graph.png
14 KB
Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig machen können. Die Port Zuordnung ist ggf. noch zu verifizieren. In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man summiert die letzten 3 Wochen). Kann jemand ein ähnliches Phänomen beobachten?
Thomas B. schrieb: > Habe noch die Gesamtproduktion sowie die täglichen Counter > ausfindig > machen können. Die Port Zuordnung ist ggf. noch zu verifizieren. > > In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen > enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt > zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der > täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes > gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem > was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man > summiert die letzten 3 Wochen). > Kann jemand ein ähnliches Phänomen beobachten? Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst.
Angehängte Dateien:
-
HM-600_20220408_01.png
8,3 KB
Mike schrieb: > Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in > Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen > später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt > habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst. Das ist wunderbar dass das so passt! Ich habe eine ähnliche Tabelle auch für einen HM-600 erstellt. Vielleicht findet der ein oder andere darin noch Werte die er bisher noch nicht hat. (AC_I z.B.) Die letzten 4 Bytes in der HM-600 0x83 Message sind im gleichen unbekannten Format wie die letzten 4 Bytes in der 0x84 Message des HM-1500 (letzte 4 Bytes ohne die letzte CRC)
:
Bearbeitet durch User
Angehängte Dateien:
Thomas B. schrieb: > Vielleicht findet der ein oder andere darin noch Werte die er bisher > noch nicht hat. (AC_I z.B.) Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw. die S-Miles Enduser App zeigt keine an.
Mike schrieb: > Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw. > die S-Miles Enduser App zeigt keine an. Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese entsprechen exakt der Leistung (P) durch der Spannung (V). [1] https://www.mikrocontroller.net/attachment/553106/HM-1500_20220408_01.png [2] https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png
Angehängte Dateien:
Desweiteren kann die Energie (Wh) und die Leistung (W) jeweis für Tag/Monat/Jahr/Gesamt angezeigt werden. Jedes PV Modul hat auch eine Ortangabe (0,0 / 0,1 / 0,2 / 0,3)
Thomas B. schrieb: > Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die > entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese > entsprechen exakt der Leistung (P) durch der Spannung (V). Also ich kann die HM-600 Decodierung auch für den HM-700 bestätigen. Beim HM-350 bin ich auch etwas weiter gekommen: Da sind die DC Daten im 0x1: DC_V, DC_A, DC_P (and der selben Stelle wie bei HM600 .. der erste byte ist 10 und das letzte ist 0. und AC Daten kommen in 0x82: 2byte Frequenz /100 2 byte Power /10 2 byte u1 (entweder 1 oder 0) 2 byte Strom /100 2 byte u2 (1000 dezimal) ... die restlichen Bytes geben für mich noch keinen Sinn. Spannung fehlt Mit dem NRF24Sniff code, der TimePacket, gefolgt von 0x81,0x80,0x82 Pakete schickt, bekomme ich vom HM-350 sehr oft mit einem 0x81? Das ist doch Command-Error? Schicke ich nur das TimePacket, kommen nur die 01/02/82 zurück
:
Bearbeitet durch User
Thomas B. schrieb: > Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig > machen können. Die Port Zuordnung ist ggf. noch zu verifizieren. Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die Tagesleistung pro Eingang sind? Das ist nämliche meine Theorie bei der Auswertung des HM-700 .... die Werte sind mir zu ähnlich (und wir hatten sehr wechselhaftes Wetter)
Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut) 01: 2bytes unbekannt "1" 2bytes dc_volt / 10 2bytes dc_amps / 100 2bytes dc_power / 10 2bytes unbekannt "0" 2bytes Total_w 2bytes Daily_w 2bytes ac_volt / 10 82: 2bytes ac_freq / 100 2bytes ac_power / 10 2byte unbekannt "0" 2bytes ac_current / 100 2byte unbekannt "1000" vielleicht /10 Power Factor in %? 2bytes temp / 10 2bytes unbekannt ansteigend 2bytes random
Oliver F. schrieb: > Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt. > https://github.com/OFreddy/hm_poll > Eventuell kann man das nutzen und für verschiedene Platformen anpassen > um solche Probleme zu vermeiden, dass bei einem nano z.B. andere > Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu > einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der > hm_config_x.h geschehen. > Wer dort erweitern möchte ist herzlich willkommen. Hallo, super Arbeit! Das ist sehr sauber aufgesetzt. Wäre es möglich die "Konfiguration via Seriell" zu unterstützen? Mit Konfiguration meine ich: Die Seriennummer der/des Hoys. (Idealerweise nutzerfreundlich mit der "richtigen" Seriennummer.) Weiterhin fände ich es gut, wenn man das Senden/Empfangen pausieren könnte sowie den Scanintervall einstellen könnte. Ich werde selber mal bisschen probieren, aber an Deine C++ Skills komme ich sicher nicht ran :-)
Martin P. schrieb: > Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die > Tagesleistung pro Eingang sind? Aehm ja, die Day1 - 4 ist jeweils pro Port. Was ich noch nicht verfiziert habe ist die genaue Portzuordnung.
Mag C. schrieb: > Hallo, super Arbeit! Das ist sehr sauber aufgesetzt. > Wäre es möglich die "Konfiguration via Seriell" zu unterstützen? Hallo Mag. Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas dauern, da ich in Osterurlaub fahre. Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du willst ja sicher nicht bei jedem Start erst die Seriennummern wieder schreiben, oder?
Oliver F. schrieb: > Mag C. schrieb: >> Hallo, super Arbeit! Das ist sehr sauber aufgesetzt. >> Wäre es möglich die "Konfiguration via Seriell" zu unterstützen? > > Hallo Mag. > Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas > dauern, da ich in Osterurlaub fahre. > Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im > EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du > willst ja sicher nicht bei jedem Start erst die Seriennummern wieder > schreiben, oder? Ich nutze einen Arduino Nano. Der Gedanke bei den Seriennummern war dass man anderen/nicht so versierten Hoymiles Nutzern vielleicht den Einstieg etwas leichter machen könnte. Man braucht im Falle des Nano ja immer noch ein weiteres Stück Software um die Daten auszulesen, weiterzusenden oder zu speichern. (Etwas in der Art baue ich gerade.) Das könnte dann auch die Konfiguration übernehmen, also beim Starten die Seriennummer(n) übergeben und z.b. das Scannen Nachts abschalten. Wenn man das Ganze standalone auf einem ESP aufbaut (Siehe oben "ESPHome" Beitrag von Marcel), dann würde es vielleicht ein UI geben, wo man die Seriennummern eintippt... Kein Stress! Schönen Urlaub!
Angehängte Dateien:
-
hoy_webserver.png
33 KB
Moin Das mit der Temperatur würde mich auch interessiern, das fehlt mir noch. Aufbauend auf der Nano-Variante von der ahoy-Seite habe ich mir eine ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt, die recht gut funzt (siehe Bild). Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die Temp?
Hubi schrieb: > Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die > Temp? Hallo Hubi, siehe [1]. Die Temperatur sollte in Telegramm 0x83 in den Bytes 17 und 18 (wenn man bei 1 zu zählen anfängt) stehen. Der dort enthaltene Wert muss durch 10 geteilt werden. [1] https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png
Hubi schrieb: > 83er, aber wo ist da die > Temp? ich hab die aktuellen Werte beim HM-600 mal angehängt von heute. Temperatur steigt an von 5,1 bis aktuell 26,6°
Angehängte Dateien:
-
HM-PowerLevel.jpg
220 KB
Hallo, für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert: Message 0x83 Start Bytes Unit Factor -------------------------------------------------- Output Level 0-5? 10 2 - x1 Grid Cuurent 12 2 A x100 0 or 1000 14 2 - -1 Status info? Temperature 16 2 °C x10 Das, was ich 'Output Level' nenne passt in den Stufen prinzipiell recht gut mit meiner Ausgangsleistung zusammen (siehe Anhang). Allerdings wird der Wert immer wieder Null, obwohl ich eine Ausgangsleistung habe - von daher passt das noch nicht ganz - aber eine bessere Beschreibung/Erklärung habe ich noch nicht gefunden :) Die 0x02 Daten habe ich auch überarbeitet. Die total 1 und 2 steigen täglich mit den Werten daily 1 und 2, von daher sollte das jetzt so passen: Message 0x2 Start Bytes Unit Factor -------------------------------------------------- Total Production 1 10 2 Wh x1 Total Production 2 14 2 Wh x1 Daily Production 1 16 2 Wh x1 Daily Production 2 18 2 Wh x1 Grid Voltage 20 2 V x10 Grid Frequency 22 2 Hz x100 Grid Power 24 2 W x10 Ich vermute, dass die Hoymiles Cloud die anderen Werte für die Wochen- und Monatsdaten ermittelt. Ebenso könnte der Power Level in % aus der Maximal-Leistung des Inverters und der aktuellen Leistung von der Cloud berechnet werden. Ich habe übrigens auch mit dem 'poor man rx channel switching' die Empfangsquote der Nachrichten deutlich erhöhen können (ich sende alle 6 Sekunden eine Anfrage), aber ich erwische damit immer noch nicht alle, evtl ist dabei neben dem Timing auch noch die Reihenfolge wichtig... Auf alle Fälle reicht das schon mal, um die wesentlichen Daten erfassen zu können, was ich sehr cool finde. Dafür ein großes Danke an alle, die hier so fleißig beigetragen haben!
Hubi schrieb: > Moin > ... habe ich mir eine > ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt,... Hallo Hubi, würdest Du mir Bitte Deinen Source zur Verfügung stellen ? Ich habe 8266 und auch 32 hier. "C++" kann ich allerdings noch nicht. Mir würde das auch erst mal so reichen, wie Du es bisher hinbekommen hast. Viele Grüße und einen schönen Sonntag wünscht Dir Herbert
Hallo meine Lieben Tüftler, den ganzen Thread am Stück lesen war jetzt doch ne Menge Input, Respekt für eure Arbeit. Ich habe zwar keinen Hoymiles, allerdings eine abgewandelte Variante: TSUN TSOL-M800. Dieser hat die Seriennummer 104163500316 Passend dazu könnte der Hoymiles 1141... passen. Datenstick und die große Basisstation sind identisch, auch in den Anleitungen zur Cloud ist Hoymiles drin. Ich hätte einen Wemos D1 Mini hier, suche aber noch ein passendes NRF Modul. Gefunden habe ich dieses hier: https://smile.amazon.de/DollaTek-NRF24L01-Funk-Transceiver-Modul-antistatischem-kompatibel/dp/B07PQPFTWZ/ Alternativ hat AZDelivery noch was im Sortiment. Wäre davon was richtig? Auch den Sourcecode für einen ESP8266, den ich mit der Arduino-Software laden kann, wäre hilfreich. Parallel habe ich noch 2 SG700MD hier, deren Protokoll ich aber schon habe und demnächst in NodeRed die Steuerung weiterbaue. Die Databox habe ich schon versucht, jedoch ist keine Kommunikation mit dem TSUN möglich. Hier ist der Chip Beken bk2461 verbaut. Was in den WR drin ist, werde ich nochmal schauen, wenn ich die Folien der Silikonpads entferne. Zur Software an sich: ich bevorzuge NodeRed und habe dazu einen Raspi am start. Hier könnte man auch wegen Python schauen, jedoch bin ich damit nie wirklich warm geworden. NodeRed finde ich da irgendwie angenehmer :) Programmierskills habe ich keine, finde mich aber in Beispielcode zurecht. C/C++ ist mir weitgehend fremd, Python ist nicht so meins, Arduino geht, JS in NodeRed basics vorhanden. Wäre cool, wenn ihr mir den Start erleichtert und wir den TSUN-Kunden einen ähnlichen Kompfort ermöglichen können :) lg Daniel
Hallo Herbert u. Daniel anbei mein Fork von der ahoy-Seite. Läuft bei mir auf einem Wemos D1 mini. Was ist anzupassen: in wifi.h : - SSID_PREFIX zur Suche des besten WLan; wenn auskommentiert, werden alle WLans in der Nähe beachtet - password für Wlan in ModWebserver.h: die defines für Serverport und OTA-Zugriff Einfach im Browser die IP eingeben, dann kommt die Tabelle wie oben. Wenn man IP/data eingibt, kommen nur die Werte als Text, das ist meine einfache Datenschnittstelle, die ich dann mittels RasPi und cron abspeichere. Ich benutze die Arduino IDE, also wer platform.io benutzt muss sich das anpassen. Viel Spaß
@Hubi, Herzlichen Dank, die Beschäftigung die nächsten Stunden (Tage) ist nun gesichert :-) Einen schönen Abend wünsche ich Dir. Danke nochmals.
Hallo,
mithilfe von
> https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0
hab ich jetzt auch das Programm (mit Circular Buffer) auf meinem ESP32
zum laufen bekommen. Danke Martin.
Heute lief das ganze mal ein paar Stunden und ich habe dazu mal ein paar
Fragen.
Was genau ist denn dieses "// Packet control field - PID Packet
identification" ?
1 | // Packet control field - PID Packet identification |
2 | uint8_t val = (p.packet[1] >> 1) & 0x03; |
3 | Serial.print(val); |
4 | Serial.print(F(" "));
|
Ebenfalls habe ich mal ein paar Debugausgaben mit hier rangehangen. Ich hab ja einen HM-400 und bekomme jetzt sehr viele dieser 0x81 Antworten. Wobei diese immer gleich per PID sind. Und ich hatte sogar eine 0x82 dabei. Weiß da schon jemand etwas mehr über dessen Bedeutung? Marcel
Der HM-400 ist ja auch ein Single Modul Inverter … wahrscheinlich wirst du da die Dekodierung für den HM-350 verwenden können, wie ich sie gestern gepostet habe. Bei mir hat es auch gereicht nur das TimePacket zu schicken … damit liefern beide Wechselrichter (350 und 700) die relevanten Nachrichten. Ich habe mal alles aus dem ursprünglichen Code geschmissen was ich nicht brauche und schicke die Dekodierung für beide WR per RSyslog und Mqtt raus (der ESP ist am Dachboden installiert, damit er beide WR sieht)
Hallo Martin, die Werte des HM hatte ich selber schon rausgefunden und gepostet. Ich nutze die schon seit ein paar Wochen. Mit deinem Code konnte ich es jetzt aber auf diese Interrupt Methode und CircularBuffer umstellen und sehe jetzt die o.g. Daten. Würde schon gerne wissen was das ist und wozu das gut ist ;) Ebenfalls wäre ich super dankbar, wenn jemand den Request von der DTU Pro rausfindet um die Einspeisung zu limitieren. Dann könnte ich demnächst auf Akkubetrieb mit Konstanteinspeisung umstellen. Marcel
lpb schrieb: > Hallo, > > für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert: > Message 0x83 Start Bytes Unit Factor > -------------------------------------------------- > Output Level 0-5? 10 2 - x1 hallo dieser "output level" wert ist interessant! in hoymiles modbus register 0xC001 oder 0x9D9D "Limit Active Power" wird der wert als % eingegeben, und zwar für MI series zwischen 10-100% für MH series 2-100% der wr-nennleistung. die frage ist, wie passt das zusammen? oder gibt es ein anderer befehl zur limitierung? Ziyat T.
Angehängte Dateien:
Manchmal sind es die kleinen Dinge dieser Welt, über die man sich freut
:-)
Nach dem ich noch einige LIBs zu meiner Arduino: 1.8.13 hinzufügen
mußte,
habe ich mich durch div. warnings gekämpft bis ich gefunden habe, was
der Grund für "exit status 1" war:
wifi.h:76:54: error: ...
....
....
exit status 1
cannot pass objects of non-trivially-copyable type 'class String'
through '...'
(Source von "Hubi" vom 10.04.2022 17:49)
in wifi.h habe ich dann diese Zeile auskommentiert:
// DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID);
Keine Ahnung, warum da gemeckert wird. Dafür reichen meine Kenntnisse
leider nicht aus.
Nun sehe ich die Webseite und muss jetzt noch die Verbindung zum
nRF24L01+ Modul herstellen.
Ich freue mich jedenfalls, das ich schon mal bis hier hin gekommen bin.
Danke "hubi"
:
Bearbeitet durch User
Sorry, dass ich nicht erwähnt habe welche libs ich noch benutze
(TimeLib, Pinger). Warum du den error mit exit status=1 in wifi.h hast
ist mir unverständlich. Ich habe dort nur eine warning und mit
DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID.c_str());
ist die warning weg.
Ein herzliches DANKE an alle beteiligten für die großartige Arbeit
bisher! Vielen Dank Hubi für deinen Arduino-Code für den D1 mini. Die
Beobachtungen von Herbert K. kann ich bestätigen. Mit DEBUG_OUT.printf
("Bestes Wifi unter: %s\n", SSID.c_str()); habe ich jedoch keinen Fehler
mehr, sodass ich nun den Webserver erreiche. Tests mit dem HM-600 stehen
noch aus...
Marcel A. schrieb: > Was genau ist denn dieses "// Packet control field - PID Packet > identification" ? Hallo Marcel, https://www.sparkfun.com/datasheets/Wireless/Nordic/nRF24L01P_Product_Specification_1_0.pdf Section 7.3.3.2 The 2 bit PID field is used to detect if the received packet is new or retransmitted. PID prevents the PRX device from presenting the same payload more than once to the receiving host MCU. The PID field is incremented at the TX side for each new packet received through the SPI. The PID and CRC fields are used by the PRX device to determine if a packet is retransmitted or new. When several data packets are lost on the link, the PID fields may become equal to the last received PID. If a packet has the same PID as the previous packet, nRF24L01+ compares the CRC sums from both packets. If the CRC sums are also equal, the last received packet is considered a copy of the previously received packet and discarded. Was es allerdings in dem Code macht, hab ich nicht weiter nachgeforscht. Ich hab ja auch nur den Code von Github genommen und das stdinout / CircularBuffer Thema für den ESP aus dem Weg geschafft.
Früher oder später wird auch eine etwas robustere Hardware interessant werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 Combo gefunden: http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein. Sollte als Ersatz-DTU aber auch seinen Dienst machen. Hier noch etwas minimalistischer: https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/ was mich bei letzterem allerdings verwundert, sind die fehlenden Widerstände, die der ESP12 normalerweise braucht.
Martin P. schrieb: > Früher oder später wird auch eine etwas robustere Hardware interessant > werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 > Combo gefunden: Mit einem ESP32 sähe das hier auch ganz nett aus: https://www.openhardware.io/view/698/MY-ESP32-GW
Angehängte Dateien:
-
ali-003.jpg
24 KB -
ali-005.jpg
18 KB -
HM400-HUBI-SRC-2022-04-11-18-01.jpg
25 KB
Wieder einen kleinen Schritt weiter :-) worüber ich mich freuen kann :-) Dies habe ich aktualisiert. "....SSID.c_str());" Nun klappt das Compilieren auch damit :-) Durch Ändern der S/N meiner HM400 bekomme ich die ersten 3 Werte vermutlich sogar richtig :-) wieder ein kleiner Schritt :-) Die restlichen Werte sind leider noch "0" . Aber so weiss ich jetzt das die HW schon mal tut :-) ali-003.jpg hat nicht funktioniert. Mit ali-005.jpg klappt es so weit schon mal.
Moin moin, ich habe gerade mal probiert das Ganze für mein Wemos D1 zu compilieren. Bekomme das Programm auch hochgeladen und eine IP. Nur leider kann ich nicht auf die Website zugreifen. Pingen kann ich den D1, somit sollte die Netzwerkverbidung stehen. Habe hier noch einen PiHole usw. laufen und somit nicht wirklich "Standard" Netzwerksettings. Kann es sein das sich der D1 in einer Whileschleife verläuft? Kann ich das Debuggin irgendwie aktivieren? Habe schon DEBUG_SEND auf 1 gesetzt, im Serial-Monitor ändert das jedoch die Ausgabe nicht. Grüße aus HH Jan
Angehängte Dateien:
-
ali-003.jpg
24 KB
Herbert K. schrieb:
ali-003.jpg funktioniert ebenfalls (konnte meinen Beitrag leider nicht
mehr editieren)
Dietrich schrieb:
...
Hallo Jan,
Keine Ahnung, welchen Source Du verwendest. Ich habe den von Hubi und
der Start in der Seriellen Console sieht zu Beginn so aus wie in der
Anlage.
Vielleicht hilft Dir das als Vergleich. Webserver ist vom Firefox und
Chrome erreichbar. Egal ob der NRF24L01+ vorhanden ist oder nicht.
:
Bearbeitet durch User
Moin Herbert, ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl. SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und mich wieder melden. Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss sich mein D1 weghängen.
Hallo da inzwischen einige Leute meine Source benutzen und noch Probleme haben, meine Frage: Soll ich eine Version bereitstellen mit einer Settings.h, in der genau beschrieben ist was einzustellen ist?
Hubi schrieb: > Hallo > da inzwischen einige Leute meine Source benutzen und noch Probleme > haben, meine Frage: Soll ich eine Version bereitstellen mit einer > Settings.h, in der genau beschrieben ist was einzustellen ist? Würde sich anbieten denke ich, da sonst viele Fragen bzgl. des Programms aufkommen, wir aber noch herausfinden müssen wie Channel Hopping und Werte setzen funktioniert sowie weitere Antworten/Werte herausfinden müssen. Bisher ist ja alles noch in Entwicklung. Marcel
Martin P. schrieb: > Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut) > > 01: > 2bytes unbekannt "1" > 2bytes dc_volt / 10 > 2bytes dc_amps / 100 > 2bytes dc_power / 10 > 2bytes unbekannt "0" > 2bytes Total_w Hallo Martin P., vielen Dank für Deine Analyse. Im Telegram "01" für die HM-Single (300/350/400) ist dies -- 2bytes unbekannt "0" -- evt. der Überlauf von -- 2bytes Total_w -- Bei einem WR habe ich schon einen Überlauf, bei einem 2. WR erwarte ich den Überlauf in ca. 5 Tagen je nach Sonne. Dann werde ich das sehen. Habe die Telegramme "01" und "82" erst mal so von Dir übernommen und bei meinen 2 HM 400 scheint das auch zu passen. Danke an ALLE für die bisherige Arbeit.
Herbert K. schrieb: > Im Telegram "01" für die HM-Single (300/350/400) ist dies > -- 2bytes unbekannt "0" -- > evt. der Überlauf von > -- 2bytes Total_w -- das ist ein guter Tipp - und macht auch Sinn, weil die 64 kWh (mit nur 16 bit) sind ja doch bald mal erreicht" .... bei mir dauert das noch .. bin erst bei 20 kWh... Was mir generell noch aufgefallen ist: Gestern war meine Hoymiles DTU als Offline im System und die Cloud zeigte auch keine aktuellen Daten. Mein ESP hingegen loggte ganz normal in den IOBroker mit. Heute Früh zeigt die Cloud plötzlich die fehlenden Daten von gestern bist Mitternacht an. Nach einem Aus/Einstecken der DTU loggt sie heute wieder normal. Entweder hatte die Cloud gestern ein Problem, oder die WR dürften eine Art Historie speichern und die DTU hat sie heute nach Sonnenaufgang noch irgendwie rausgeschickt?
Hubi schrieb: > Hallo > da inzwischen einige Leute meine Source benutzen und noch Probleme > haben, meine Frage: Soll ich eine Version bereitstellen mit einer > Settings.h, in der genau beschrieben ist was einzustellen ist? Hallo Hubi, ich denke das ist eine gute Idee um die Source von dir besser Nutzbar zu machen. Grüße Jan
Dietrich schrieb: > Moin Herbert, > > ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl. > SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und > mich wieder melden. > > Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss > sich mein D1 weghängen. Hallo zusammen, soo Fehler gefunden. Ich habe keine Fritzbox, daher funktiniert der TimeServer define #define TIMESERVER_NAME "fritz.box" natürlich nicht. Einfach auskommentieren und Hubis Angabe "pool.ntp.org" benutzen. Nun läuft der Webserver - jetzt muss nur noch der WR ankommen... :) Grüße Jan
Hallo, ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp. Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten im Log ?
1 | 1649772015 00 00DC 1B 2 95 73109025 73109025 010001017F00C702F900005E44039E08FBA3F89D AF08 A2DC DAA8 AF08 E3D3 E787 AF08 A2DC AF08 1F4A AF08 7860 0978 A436 A2DC A9E2 AEB6 08FE AF08 A2DC AF08 A9E2 25BB A2DC A9E2 F891 |
2 | hm400: Voltage: 38.30V, Ampere: 1.990A, Power: 76.10W |
3 | Total Production: 24.132kW, Daily Production: 926.00W, AC Voltage: 229.90V |
(erste spalte ist epochtime, welches ich hinzugefügt habe) Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ? Marcel
Marcel A. schrieb: > Hallo, > > ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp. > > Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten > im Log ? Hallo Marcel, ja bei mir kommt auch des öfteren etwas merkwürdiges. Bisher mache ich mir da nicht viel drauss. Bin froh, das ich das mit 2 Stk. HM400 so weit hinbekommen habe, trotz fehlender "C++" Kenntnisse. Ich versuche die nä. Tage mal Fehler zu produzieren, ob man die in den unbekannten Feldern wiederfindet. An die "C++" Programmierer: Bitte was muss ich wo ändern, um die 4 Byte zu Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr als 65535 werden können ? Danke schon mal.
:
Bearbeitet durch User
Martin P. schrieb: > Früher oder später wird auch eine etwas robustere Hardware interessant > werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 > Combo gefunden: > > http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge > Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein. > Sollte als Ersatz-DTU aber auch seinen Dienst machen. > > Hier noch etwas minimalistischer: > > https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/ > > was mich bei letzterem allerdings verwundert, sind die fehlenden > Widerstände, die der ESP12 normalerweise braucht. Hallo, ich habe mal den Creator angeschrieben ob es okay ist, wenn wir uns ein paar Platinen machen lassen. Wenn das okay bist, bestelle ich mal 5 Stück. 4 davon würde ich dann kostenlos an die Hauptverantwortlichen hier verschicken, wenn ihr was damit anfangen könnt. Quasi als Support :) Grüße Jan
> Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen > des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ? > Marcel Ich habe solche bei mir auch gesehen … habe aber auch die gleiche CodeBase..
Hallo zusammen, ich bin heute auf der Suche nach einer DTU alternative auf euren Thread gestoßen. Dies ist mein erster Eintrag hier im Forum. Ich bin absolut beeindruckt was hier alles geleistet wurde. Ich bekomme auch bald einen HM-1500 und möchte die Daten selbst per MQTT auslesen. So wie ich es gelesen habe, besteht die Hardware aus ESP8266 + NRF24L01. Die hab ich zufällig schon rumliegen. Wo finde ich denn den Code? Viele Grüße an die großartigen Unterstützer, Analysten, Programmierer hier!!!! Gruß Chris
Herbert K. schrieb: > An die "C++" Programmierer: Bitte was muss ich wo ändern, um die 4 Byte > zu > Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr > als 65535 werden können ? Danke schon mal. Ich mache das so:
1 | float extractValue4 (uint8_t *p, int divisor) { |
2 | //-------------------------------------------
|
3 | uint32_t ret = *p++; |
4 | for (uint8_t i = 1; i <= 3; i++) |
5 | ret = (ret << 8) + *p++; |
6 | return (ret / divisor); |
7 | }
|
Du übergibts einen Zeiger auf die Stelle in der Payload wo dein 4-byte Wert beginnt und als Divisor 1 (kannst du also auch weglassen), etwa so: [b] float wert = extractValue (&payload[??], 1) [/b] Das findest du aber alles in meinem am 10.4. geposteten Code.
Im Anhang überarbeitete Version meiner Software, die auf ESP als auch Arduinos läuft. Neu ist: - extra Settings.h mit den möglichen Einstellungen - automatische Konvertierung der WR-Seriennummer in diese umgedrehte Radio-ID - Source Sonne.h enthält Berechnung von Sonnenauf- und -untergang => nachts nicht mehr den WR abfragen
@Hubi, kannst Du das bitte via git bereitstellen? Sourcen in zip-Files ohne Versionierung in Foren teilen ist wenig hilfreich. Danke.
Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss der Funkmoduls an den ESP8266 D1 mit Hubis Software (Danke dafür!) nicht korrekt gemacht habe. Die Software an sich läuft und verbindet sich problemlos mit meinem WLAN, die Web-Oberfläche kann ich auch aufrufen, aber alles 0. Möglicherweise bin ich nicht der Einzige, der nicht sicher ist, welche Pins ausser den in Settings.h erwähnten mit dem ESP verbunden werden müssen. Meine Bitte: wäre jemand so nett, die komplette Verschaltung dieser Konfiguration zu dokumentieren...? Dankeschön! aus Settings.h: // Hardware configuration #ifdef ESP8266 #define RF1_CE_PIN (D4) #define RF1_CS_PIN (D8) #define RF1_IRQ_PIN (D3) GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für den NRF24) sind klar. Aber was ist mit MO (D7?) und MI (D6?)...
Peter L. schrieb: > Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss .... > Aber was ist mit MO (D7?) und MI (D6?)... Hallo, natürlich musst Du MISO, MOSI, CLK anschliessen, damit die RF24 LIB funktioniert. Einfach mal in die Datenblätter schauen vom ESP8266 und NRF24... Hab die HW gerade nicht zur Hand.
Peter L. schrieb: > aus Settings.h: > // Hardware configuration > #ifdef ESP8266 > #define RF1_CE_PIN (D4) > #define RF1_CS_PIN (D8) > #define RF1_IRQ_PIN (D3) > > GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für > den NRF24) sind klar. > > Aber was ist mit MO (D7?) und MI (D6?)... Ich habe: D4 -> CE D8 -> CSN D3 -> IRQ D5 -> SCK D6 -> MIso D7 -> MOsi VCC und GND ergeben sich. Leider auch noch kein Signal. @Hubi: war da nicht noch was mit der "ersten Taufe" damit der Gerät spricht? Sonnenoffest hab ich mal auf 120min gestellt, du verwendest da UTC, oder? Sonst sehr gute Arbeit :) Vielen dank!
Es gibt viele Bespiele in Google - aber halte dich nicht an die … sondern Google nach nrf24l01 Pinout und welchen Controller du hast. Verbinde die SPI Pins wie sie der Controller hat und wähle für CE und CSN und IRQ Die Pins aus dem Code. Beachte, dass es unterschiedliche Nomenklatur gibt (deshalb haben diese Pinout Bilder immer mehrere Namen)
Angehängte Dateien:
OK, wie auch von Daniel geschrieben, habe ich es so gemacht: NRF24 ESP8266 ---------------------- RF1_CE_PIN D4 RF1_CS_PIN D8 RF1_IRQ_PIN D3 RF1_MO_PIN D7 RF1_MI_PIN D6 RF1_SCK_PIN D5 GND G VCC(5V) 5V (NRF24 mit Spannungsregler-Platine) VCC(3,3V) 3V3 Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>. Morgen kommt die Sonne wieder ;-)
Peter L. schrieb: > OK, wie auch von Daniel geschrieben, habe ich es so gemacht: > > NRF24 ESP8266 > ---------------------- > RF1_CE_PIN D4 > RF1_CS_PIN D8 > RF1_IRQ_PIN D3 > > RF1_MO_PIN D7 > RF1_MI_PIN D6 > RF1_SCK_PIN D5 > > GND G > VCC(5V) 5V (NRF24 mit Spannungsregler-Platine) > VCC(3,3V) 3V3 > > Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>. > Morgen kommt die Sonne wieder ;-) Wir werden sehen ob ein Reboot über Nacht hilft. Ic hvermute trotzdem eher den initialen "Hello" Schritt, der noch fehlt, quasi ein Setup, damit erstmal WR und "Databox" zueinander finden. Sonst muss ich sagen, ist der Arduino-Code echt genial, sehr sauber und übersichtlich. Danke Hubi :)
Hallo zusammen da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS) und dazu eine CS( Chip select). Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe. Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software in Verbindung mit einem RasPi als "Datensammler" und Webserver mit grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder meine neue Weiterentwicklung kann sich bitte hier gern melden.
Hubi schrieb: > Hallo zusammen > da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In > meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob > Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS) > und dazu eine CS( Chip select). > Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als > ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe. > Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software > in Verbindung mit einem RasPi als "Datensammler" und Webserver mit > grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder > meine neue Weiterentwicklung kann sich bitte hier gern melden. Ein Git-Account sollte nicht kompliziert sein, wäre halt praktisch. Welche Belegung nutzt du an deinem Wemos? Vielleicht kann man das zusammen dort in die readme packen. Ich warte mal auf den Reboot über Nacht, vielleicht hilft der. Ich hab noch das große Fragezeichen, weil ich einen potentiell kompatiblen Typ nutze, kein originalteil. Laut Anleitung soll ein initiales binding durchgeführt werden, ob das wirklich nötig ist, weiß ich nicht. Ist es sehr aufwändig, so ein "Hello" zu implementieren, das man über Konsole oder Webserver anstoßen kann? Du hast gerade den vielversprechendsten Ansatz für den ESP8266. Ein Paypal-Spendenlink für den einen oder anderen Kaffee würde ich auch sehr begrüßen, genauso von den anderen, die hier so einiges beigetragen haben :) Ich hoffe noch auf die Leistungsregulierung, wenn das mit der Kommunikation komplett klappt. Dann kann man auf Nulleinspeisung oder Akku-laden via NodeRed schauen, der SDM z.B. ist ja auch keine Raketentechnik. Da würde ich mich dann mehr einbringen, wenn ich das ganze richtig zum laufen gebracht hab. lg
Hallo Daniel, mich würde mal Interessieren, woher die Annahme kommt, das der TSUN gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen technischen Angaben weichen beide eben ab. Zusätzlich die Information, das es ein hello signal geben soll weisen ggf. sogar schon drauf hin, das es eine andere Software hat. Und Hubi hat doch schon die Software bereitgestellt und erhebliche Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde den Github Link zu einer anderen Code Version und mache einen Pull Request und füge diesen Code hinzu. Marcel
:
Bearbeitet durch User
Marcel A. schrieb: > Hallo Daniel, > > mich würde mal Interessieren, woher die Annahme kommt, das der TSUN > gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja > schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu > sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche > Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen > technischen Angaben weichen beide eben ab. In der Anleitung zu den Kommunikationsadaptern beider Hersteller steht Hoymiles drin. Die cloud bei Tsun läuft auf einer anderen URL, allerdings identisch aufgebaut. Es würde mich nicht wundern, wenn es eine Kopie ist. Die Initialisierung beider Geräte auf Kommunikationsebene ist identisch beschrieben. Was am Ende im Protokoll passiert, kann anders sein, ganz klar. > Zusätzlich die Information, das es ein hello signal geben soll weisen > ggf. sogar schon drauf hin, das es eine andere Software hat. Das Hello wurde schon in anderen Postings beschrieben, ebenfalls steht es in der Anleitung. > Und Hubi hat doch schon die Software bereitgestellt und erhebliche > Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf > GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde > den Github Link zu einer anderen Code Version und mache einen Pull > Request und füge diesen Code hinzu. Und ich bin ihm sehr dankbar dafür. Einen ESP8266 als Interface nutzen zu können, ist ein großer Vorteil. Da ich noch einen Raspi und ein 2. RF24 Interface habe, schau ich die Tage mal, was ich tun kann. Werde auch noch einen Stick von Tsun besorgen und schauen, was der tut. Es wäre ungewöhnlich, wenn bei dieser Schnittmenge zwischen den Geräten, das nicht einfach nur eine Kopie mit kleinen Änderungen in der Ziel-URL ist, zumal selbst die Bedienoberfläche des Stick laut Anleitung beim Tsun identisch zu der von Hoymiles ist. Das mit Git werd ich gerne mit machen, sofern Hubi nichts dagegen hat.
Hallo,
Hubi´s Code funktioniert bei mir ohne Probleme. Ich habe auch keine
DTU...
Der Code hat sofort funktioniert, nachdem ich die WR SN eingetragen
habe.
1. Es muss (!) der nRF24L01+ sein. Das PLUS ist wichtig ! Ein "alter"
nRF24L01 (ohne Plus) funktioniert NICHT !
2. Sucht im Code nach
"// radio1.printPrettyDetails();"
und übersetzt den Code mal, in dem Ihr das wieder einkommentiert
"radio1.printPrettyDetails();"
Dann findet Ihr in der Seriellen Konsole was das - sofern der RF24
richtig verdrahtet ist - so aussieht.
Steht da NICHT "RF Data Rate = 250 KBPS " ist was Faul in
der Kommunikation zum nRF24L01+ .
SPI Frequency = 10 Mhz
Channel = 3 (~ 2403 MHz)
RF Data Rate = 250 KBPS
RF Power Amplifier = PA_MAX
RF Low Noise Amplifier = Enabled
CRC Length = Disabled
Address Length = 5 bytes
Static Payload Length = 32 bytes
Auto Retry Delay = 250 microseconds
Auto Retry Attempts = 0 maximum
Packets lost on
current channel = 0
Retry attempts made for
last transmission = 0
Multicast = Disabled
Custom ACK Payload = Disabled
Dynamic Payloads = Disabled
Auto Acknowledgment = Disabled
Primary Mode = RX
TX address = 0xe7e7e7e7e7
pipe 0 (closed) bound = 0xe7e7e7e7e7
pipe 1 ( open ) bound = 0x1234567801
pipe 2 (closed) bound = 0xc3
pipe 3 (closed) bound = 0xc4
pipe 4 (closed) bound = 0xc5
pipe 5 (closed) bound = 0xc6
Ja, wenn die Kommunikation mit dem nrf24l01+ erst mal funktioniert, kann es immer noch an der Funkschnittstelle scheitern. Einen Kondensator an +- des Moduls anlöten. Eine Zwischenplatine mit eigenem LDO (hier scheint es auch 2 Varianten am Markt zu geben: mit kleinen und großen SMD caps drauf) Eine nrf24l01+ Variante mit PA/LNA und SMA Antenne verwenden. Eine Dipolantenne an das kleine Modul löten. Wenn Kondensator dran ist, auch mal PA_MODE_HIGH oder PA_MODE_MAX probieren.
Angehängte Dateien:
-
P1100204.JPG
280 KB -
P1100205.JPG
300 KB -
P1100206.JPG
360 KB -
P1100207.JPG
220 KB
Hallo anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja nur ein paar Strippen zu löten. Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht nur für den HM-600, und auch für mehrere (unterschiedliche) WR gleichzeitig. Eine Version für RasPi könnte da auch noch drin sein. Ich überleg's mir mal. Vllt könten sich auch ein paar von uns zs-schließen und das mit Git machen, Aufgaben verteilen etc.
Hubi schrieb: > Hallo > anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine > Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja > nur ein paar Strippen zu löten. > Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht > nur für den HM-600, und auch für mehrere (unterschiedliche) WR > gleichzeitig. > Eine Version für RasPi könnte da auch noch drin sein. > Ich überleg's mir mal. Vllt könten sich auch ein paar von uns > zs-schließen und das mit Git machen, Aufgaben verteilen etc. Hallo Hubi Herzlichen Dank für die SW und die Bilder. Und natürlich an dieser Stelle Danke auch an allen Beteiligten am Projekt. Ich habe eine DTU-Pro und MI1500 am Laufen, da die Zero Export Funktion nicht so lief, wie sie sollte (und wie die Hotmiles behauptet), steuere ich mit einem Python/Modbus script über die DTU den MI1500, so wie ich es richtig halte. Ich möchte gerne die DTU-Pro ersetzen, die SW hat Fehler (bei kleineren Loads) und die Hoymiles will es nicht korrigieren. Ich werde deine SW verwenden, mit WEMOS D1 mini und nrf24l01+ PA/LNA/SMA Antenne. Mich interessiert die WR Steuerung bzw. Limitierung, ich würde gerne hier mit machen, da ich den MI1500 über myPython/DTU prozentual limitieren und dort halten kann, könnte ich ev. die Limitierung heraus finden. Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die raw-Packete beobachten? Danke und grüsse aus dem Süden. Ziyat T.
Toe C. schrieb: > Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die > raw-Packete beobachten? Meine SW arbeitet auf Telegramm-Ebene. Ich weiß nicht so genau was du mit raw-Paketen meinst, wahrscheinlich eher sowas wie oben mittels Sniffer mitgeschnittenen Datenverkehr. Musst wohl doch den Thread nochmals lesen. Steuerung des WR wäre natürlich auch ganz nett, also dass man limitieren kann bzw diese auch aufheben kann. Wenn da was zu programmieren ist bin ich dabei, auch wenn ich keine DTU habe.
Eine Frage an die DTU-Wlite und DTU-Pro Besitzer: Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR über die offiziellen hoymiles Wege bekommen und auf welche Kommunikatiosart ? (also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem Smartphone, RS485 ?, ...) Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU... übertragen werden.
Herbert K. schrieb: > Eine Frage an die DTU-Wlite und DTU-Pro Besitzer: > > Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR > über die offiziellen hoymiles Wege bekommen und auf welche > Kommunikatiosart ? > (also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem > Smartphone, RS485 ?, ...) > Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU... > übertragen werden. Hallo Herbert Ich steuere meinen MI1500 über DTU-Pro/ModbusRTU selber. Ich habe bisher an der DTU-Pro die folg. WR-Port-Status herausgefunden: PORT_STATUS = ["can't read", "?", "?", "Normal", "?", "(ev.)PV not connected", "?", "?", "Reduced"] Die 8=Reduced wird im S-miles als "remote shutdown" ersichtlich, manchmal;-). Grüsse Ziyat
Hallo, auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann es noch nicht montieren. Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1 laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht verpackt und hatte beim Transport ganz schön gelitten. Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht weiß, ob er den Transport überlebt hat. Gruß Hans ...und Hut ab vor eurer Arbeit hier !!!
Hallo in die Runde, wie versprochen kommt meine DTU für den TSUN am Dienstag. Bin gespannt wie das Innenleben aussieht. Mit welchen Tools macht es am meissten Sinn, die DTU auf rx/tx zu überwachen? Ich hätte USB-Serial Adapter hier und kann vom ersten Einschalten beobachten, theoretisch. Bislang komme ich mit dem Wemos nicht weiter, keine Kommunikation mit dem WR, was ich aber fast erwartet habe. Ich hab mal dein Stück des Bootvorgang und der Kommunikation mit angehängt. Debug ist aktiviert und die Sendedaten lasse ich mir mit anzeigen. lg Daniel
Hans W. schrieb: > Hallo, > > auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich > hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann > es noch nicht montieren. > > Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1 > laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht > verpackt und hatte beim Transport ganz schön gelitten. > > Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine > Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht > weiß, ob er den Transport überlebt hat. > > Gruß Hans ...und Hut ab vor eurer Arbeit hier !!! Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem "+" bekommt? Vielen Dank!
Ich habe diese: WayinTop 2pcs NRF24L01+PA+LNA... https://www.amazon.de/dp/B07PBBC4H9 (Mit PA und LNA - die breakout boards dabei sind nicht gut) Und die: AZDelivery 5 x NRF24L01 mit 2,4... https://www.amazon.de/dp/B075DBDS3J
Hallo, kann man eigentlich auch einen RF-NANO (z.B. https://de.aliexpress.com/item/1005003513445043.html) verwenden? NRF24_SendRcv kompiliert, aber hier scheint es keinen IRQ zu geben?!
Der RF-Nano verhält sich merkwürdig: - isPVariant liefert true also PLUS - setDataRate liefert mit 250KBPS false - unterstützt also keine 250KBPS Insofern also wohl nicht brauchbar :-(
Hakko Marcus das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben, also sollte D2 der INT0 sein. Bei den Kundenbewertungen ist auch erwähnt, dass wohl nicht die Plus-Variante des RF-Moduls verbaut wurde, also keine 250 kbps.
Reinhard B. schrieb: > Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem > "+" bekommt? bei mir gerade von AZ-Delivery angekommen: funktioniert! :-) Der Tip mit dem "PLUS" war entscheidend, Danke für Eure Unterstützung, mein HM-1200 spricht nun mit mir!
Hubi schrieb: > Vllt könten sich auch ein paar von uns > zs-schließen und das mit Git machen, Aufgaben verteilen etc. Also mein Vorschlag steht ja und wird auch schon fleißig geforkt: * https://github.com/grindylow/ahoy Persönlich bin ich eher an der Raspi-Seite interessiert, aber die beiden ergänzen sich ja gegenseitig.
Wir bräuchten dringend mal noch längere Logs von Datenverkehr mit echten DTUs. Ich meine, in den ursprünglichen Mitschnitten war das 0x80 ja garnicht notwendigerweise als das fortwährend zu sendende Paket zu erkennen - macht ja eigentlich auch keinen Sinn, sekündlich die Uhrzeit neu zu setzen. Vielleicht bringt das ja auch jedesmal das Channel Hopping wieder durcheinander? Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24 zu tun. Das wäre spitze, aber natürlich Hardware-intensiv... Meine DTU kam immernoch nicht - und die Hoffnung schwindet.
Angehängte Dateien:
-
IMG-20220416-WA0009.jpg
240 KB
Martin G. schrieb: > Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu > belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24 > zu tun. Das wäre spitze, aber natürlich Hardware-intensiv... Hallo Martin. Das war mein Plan. Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren bin. Konnte es leider noch nicht richtig ausprobieren. Aber ich denke, das wird neue Erkenntnisse bringen. Erste Tests haben aber schon gezeigt, dass die DTU leider auf mehr als 6 Kanälen sendet.
Hubi schrieb: > das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem > Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben, Mhh - ich dachte der IRQ wird (beim Aufbau Wemos D1/NRF-Modul) verwendet, um einen IRQ bei Empfang auszulösen (für die ISR). Der IRQ-Pin des NRF auf dem RF-Nano ist nicht verbunden. Meinst Du der Nano löst dennoch einen Interrupt auf D2 / D3 aus? Kann ich mir jetzt nicht vorstellen - außer man würde den IRQ-Pin des NRF mit dem Nano PIN D2 oder D3 verbinden. Normal ist da ja bei einem Nano nichts verbunden (außer eben wenn man ein externes NRF-Modul anschliesst). Fazit für das Topic: Der RF-Nano ist für das Auslesen der Hoymiles weniger (bzw. nicht) geeignet. Wenn man diesen dennoch testen möchte, dann ist zu prüfen, ob er wirklich ein NRF+ Modul hat (am besten die Datenrate von 250KPBS setzen und überprüfen). Es scheint wohl welche mit und ohne zu geben. Wenn er ein NRF+ Modul hätte, müsste man aber vermutlich auch die Software bzgl. der ISR / IRQ Thematik anpassen. Ich habe mir nun die hier im Thread genannten Module bestellt: [[https://www.amazon.de/dp/B075DBDS3J]] Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca. 10-15m LOS + 1 Holzdach überbrückt?
Hallo, habe einen HM1200. Aufschrift 1200HR. EU .HM. Die Seriennummer ist rein numerisch 116170522231, kann das sein? Habe die leider nicht vorher aufgeschrieben und nun mit einer Iphone/Holzlattenkombination auf dem Dach abgefilmt...... Danke
Marcus schrieb: > Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca. > 10-15m LOS + 1 Holzdach überbrückt? Hallo Marcus genau diese benutze ich auch. Die reihen hier vom Wohnzimmer, wo programmiere und teste bis zum WR auf dem Gartenhaus, ca. 20 m entfernt, dazwischen eine Tür mit Isolierglas und Büsche/Bäume.
> Die Seriennummer ist rein numerisch 116170522231, kann das sein?
Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch
mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde
ein 0x vorangestellt sein.
@Thomas B. Noch etwas für die Statistik Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" - da ich gerade den WR fotografiert habe: Die Seriennummer meines HM-400 beginnt mit: 1121
Lukas P. schrieb: >> Die Seriennummer ist rein numerisch 116170522231, kann das sein? > > Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch > mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde > ein 0x vorangestellt sein. Danke, wo fange ich an? Der Thread ist etwas unüberschaubar. Ich habe NRF, Atmega, Espxxxx und Raspi…
Angehängte Dateien:
-
AhoyMiles_bb.png
62 KB -
AhoyMiles_schem.png
36 KB
Danke an Hubi für das Update des ESP8266/ESP32 Codes und die anderen die hier schon fleißig getraced haben! Seit ich meine HM-600 Seriennummer (beginnt mit 1141 7310 xxxx) eingetragen habe und das in der alten Version (vom 10.4.) fehlende Debug.h auskommentiert habe funktioniert es bei Tageslicht problemlos. Ich habe diese Bibliotheken extra installiert: * RF24 * TimeLib * Pinger (braucht man in der neuen Version vom 13.4. evtl. nicht mehr ?) Hier sind die Verbindungen meiner beiden Komponenten: * Pinout des PA nRF24L01+ Moduls: Ich habe dieses hier von derpaule auf eBay bestellt, scheint nur jetzt vergriffen zu sein. Aber man kann wie bei den AZ-Delivery aus der Zone sehr gut das nRFL01 "+" sehen. https://www.ebay.de/itm/165071116650 Die Debug Ausgaben sollte m.E. immer das og. radio1.printPrettyDetails(); aktiviert haben, damit man etwas über die korrekte Belegung des nRF24L01 Moduls erfährt.
1 | |Colour|Description|Pin|Pin|Description|Colour| |
2 | |------|-----------|---|---|-----------|------| |
3 | |black | GND |[1]|[2]| VCC +3.3V |white | |
4 | |grey | CE |[3]|[4]| CSN |purple| |
5 | |blue | SCK |[5]|[6]| MOSI |green | |
6 | |brown | MISO |[7]|[8]| IRQ |yellow| |
* ESP8266 / NodeMCU Anschlüsse: Wire Connections
1 | +-----------+ +-----------+ |
2 | | nRF24L01+ |--colour--| ESP8266 | |
3 | | | | | |
4 | | GND |---black--| GND | |
5 | | VCC |----red---| +3.3V | |
6 | | CE |---grey---| D4 | |
7 | | CSN |--purple--| D8 | |
8 | | SCK |---blue---| D5 | |
9 | | MOSI |---green--| D7 | |
10 | | MISO |---brown--| D6 | |
11 | | IRQ |--yellow--| D3 | |
12 | +-----------+ +-----------+ |
Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in das Readme.md auf dem Ahoy Github einchecken. @Hubi unter welcher Lizenz steht denn Dein Source Code und darf der ebenfalls eingecheckt werden ? Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter verbessern. Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter (Liste/Array mit WR IDs) in einer Schleife abfragen kann ? Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher praktisch. Eine Ausgabe der Daten im Serial Plotter Format wäre für einfache Tests ohne MQTT, etc. ebenfalls geschickt. Hier ist die PDF Dokumentation [1] und hier die offizielle Markdown Doku [2] der Arduino Software zum Serial Plotter Protokoll. [1] https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.pdf [2] https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.md
Hallo, seit Mitte Februar lese ich begeistert in diesem Thread. Leider hatte ich bis jetzt nur Zeit die unglaubliche Anzahl der Beiträge zu lesen. Vielen Dank für eure Arbeit, es ist einfach toll zu sehen wie schnell es hier weitergeht! Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier möchte ich was beitragen. Ein pull-request habe ich erstellt. Mein Setup: - HM1200 - NRF24L01+ https://www.ebay.de/itm/255283312809 - ESP8266 (ESP-07) - Verdrahtung wie in dem Post darüber Aktueller Stand: Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station). Ich konnte damit auch schon loggen, allerdings habe ich festgestellt, dass ich nur Antworten mit Command 0x81 bekomme. Wenn ich den Code von Hubi direkt verwende, dann kommen auch andere Commands. Zur Verifizierung der Werte habe ich einen Sonoff-POW-R2 vor dem Wechselrichter und kann damit die Leistung vergleichen. Die Werte aus Hubi's Webinterface stimmen nicht für meinen HM1200.
isnoAhoy schrieb: > @Hubi unter welcher Lizenz steht denn Dein Source Code und darf der > ebenfalls eingecheckt werden ? > Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter > verbessern. > > Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter > (Liste/Array mit WR IDs) in einer Schleife abfragen kann ? > Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher > praktisch. Moin zusammen Meine Source hat keine Lizenz, stammt ja ursprünglich auch nicht von mir sondern von der ahoy-Seite bei Github. Ja, im Moment bin ich noch am aufräumen und verbessern. Eine Version für mehrere WR ist in Arbeit. Die abzufragenden Messwerte hinterlege ich in einer Liste, pro Messwert eine Zeile mit WR, Messwertname, Einheit, Telgramm-ID, Offset, Länge, Funktion. Als Funktion kann man einen Divisorwert oder eine selbst definierte Funktion nehmen, zb wenn man die Stromstärke haben will mittels P/U. Da das ganze auch für Arduinos (zB Pro mini) laufen soll, musste ich etwas aufräumen. Besonders in der crc.cpp konnte ich über 500 byte einsparen, indem ich eine crc-Lib benutzt habe. Aber es läuft ohne Speicherwarnung auch auf dem Pro Mini, natürlich nicht mit webinterface, aber mit Ausgabe über Serial. Wenn der Autor von der ursprünglichen NRF24-SendRcv (ahoy) nichts dagegen hat dann stelle ich meine Entwicklung ins Git. Meine Source ist im Moment nur für den HM-600. Für andere WR-Typen wird das nicht funktionieren, denn da sind die Requests und Antworten anders mit anderen Telegram-IDs und offsets. Wenn mir jmd seine Erkenntnisse über seinen WR zuschickt, bringe ich das in meine Source mit ein. Schöne Ostern
Wenn mir jmd seine Erkenntnisse > über seinen WR zuschickt, bringe ich das in meine Source mit ein. > Schöne Ostern Ich habe weiter oben gepostet, dass HM-700 gleich wie der HM-600 tut und wie die Interpretation für HM-350 ist (und HM-400 scheint gleich zu sein) Brauchst du trotzdem meinen Code dazu auch?
Source brauche ich im Moment noch, die nötigen Daten suche ich mir oben zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst Mehr-WR-Fähigkeit entwickeln will.
Source brauche ich im Moment noch nicht, die nötigen Daten suche ich mir oben zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst Mehr-WR-Fähigkeit entwickeln will.
Oliver F. schrieb: > yveaux NRF24 sniffer Hallo, Oliver F., könntest du eventuell den Code posten? Wollte auch mal ein serielles MySensors-GW umflashen und zum sniffen nutzen, aber leider bekomme ich schon den Ausgangs-Sketch von Yveaux nicht via Arduino-IDE compiliert. Konkret wird die "wrong number of template arguments" bzgl. des CircularBuffer (Zeile 97?) bemängelt... Wäre toll, wenn du da helfen könntest.
@Hubi, @Martin G(petersilie) Hallo zusammen Mein Setup: DTU-Pro MI1500 (nur Port3/4 mit PV's) WemosD1mini NRF24L01+ wie https://www.ebay.de/itm/255283312809 Ich verwende Hubi's letzte Version(mit settings.h): - NRF24L01+ mit 256KBPS funktioniert, siehe init in log Dateien - MI1500 gibt keine Antwort, siehe NRF24_DTU_OFF.log Aber wenn ich DTU-Pro einschalte: - erhalte ich etwas, die PV/AC/etc. Werte stimmen nicht (wahrscheinlich auch, da MI1500 4 Ports hat), siehe NRF24_DTU_ON.log - ich sehe neue CMD's, siehe NRF24_CMDXX, CMD 00,5A,55 Grüsse Ziyat T.
Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das Telegramm mit command 00 müsstest du mal untersuchen, zu was die aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die Werte der unbestückten Ports sein!?
Hubi schrieb: > Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine > eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das > Telegramm mit command 00 müsstest du mal untersuchen, zu was die > aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die > Werte der unbestückten Ports sein!? Habe schon versucht die Daten zu analysieren, wie ich sie anschaue ist gleich, bekomme ich keine gescheitere Werte, siehe Anhang
Hallo wenn sich jemand interessiert im Anhang MI1500 > DTU-pro log
Angehängte Dateien:
Falls noch nicht bekannt, mein HM-1200 sendet auch 84er-Telegramme. Nicht so oft, aber immer wieder. Panels: 2 + 1, aktuelle Leistung: 800.69W, 4.895kWh letzte 24h, heute 2.322kWh, total 73.528kWh
:
Bearbeitet durch User
Leider, mein 1500 wird auch noch nicht unterstutzt, aber wenn ich mal helfen kann, schick mir mail auf robert (at) bleumer.nl Kein DTU Pro dabei übrigens.
Angehängte Dateien:
-
220418_HM1200_Bytes.png
57 KB
Hallo zusammen, ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück weitergekommen. Dank des Excel-Screenshots von tbnobody (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") habe ich so ziemlich alle Felder der Commands 01, 02, 03 und 84 für den HM1200 zuordnen können. Ich habe als Input die Firmware von Hubi verwendet und das serielle Log ausgewertet. Heute habe ich den ganzen Tag mitgeloggt und konnte dadurch sehr gut die Zuordnung bestimmen. (220418_log_out.xlsx ist das Log von heute) Die Werte stimmen mit meinen durch einen vorgeschalteten Sonoff POW R2 gemessenen Werte sehr gut überein (vor allem bezogen auf die Tagesproduktion und die Gesamtproduktion). Falls jemand meine Schritte nachvollziehen will, hier so ein grober Fahrplan: - ESP Firmware von Hubi, seriellen Output mitloggen - Log bei https://regexr.com/ reinladen und mit folgender Regex filtern, die ausgegebene Liste dann wieder in ein File kopieren (Input für main.cpp) - main.cpp kompilieren (VS2019 Projekt kann ich auch noch teilen) - ausgegebenes CSV in LibreOffice / Excel öffnen und verschönern Regex:
1 | ([0-9]+\s[0-9]+\s[0-9A-F]+\s[0-9A-F]+\s.\s+[0-9]+\s[0-9]+\s[0-9]+\s[0-9A-F]+\s[0-1]) |
Lukas P. schrieb: > Hallo zusammen, > > ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück > weitergekommen. .... Commands 01, 02, 03 und 84 für den HM1200 Auch wenn ich aktuell keinen HM1200 habe, sage ich einfach mal Danke für die Arbeit !
Angehängte Dateien:
-
220419_HM1200_Bytes.png
110 KB
Jetzt ist mir aufgefallen, dass die 16bit vor den jeweiligen Gesamterträgen 0 sind, daher nehme ich an, dass die Gesamterträge als 32bit Wert geführt werden. Weitere 8 Byte geklärt. Byte 1 und 2 vom Command 01 könnte ein AC-Enable sein oder eine Art Netz-Sync boolean. Was mir noch aufgefallen ist: es gibt nur 2 DC Spannungen, kann es sein, dass diese für jeweils 2 Eingänge gelten (HM1200 hat 4 Eingänge, aber nur 2 MPPT, also hat jeder MPPT eine Spannung).
wo fange ich an? Der Thread ist etwas unüberschaubar. Ich habe NRF, Atmega, Espxxxx und Raspi…
analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.81 PV-DC.P:163.10 PTotal-Ueberlauf-Unbekannt.W:0.00 PTotal.W:65535.00 PToDay.W:106.00 AC.V:238.10 analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.69 PV-DC.P:157.80 PTotal-Ueberlauf-Unbekannt.W:1.00 PTotal.W:0.00 PToDay.W:107.00 AC.V:237.90 HM400 der "Überlauf" :-) ist gerade eben passiert :-) Also (P-Total) ist 4 Byte :-) wie vermutet :-) Euch Allen einen schönen Tag
Angehängte Dateien:
Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank holt, müssten in den Telegrammen ja auch noch Hardware und Software Version versteckt sein ? (wird in der Cloud ja angezeigt)
Herbert K. schrieb: > HM400 der "Überlauf" :-) ist gerade eben passiert :-) > Also (P-Total) ist 4 Byte :-) wie vermutet :-) Super, dann stimmt die 4 Byte Größe wie im Manual angegeben - dann war ich am Anfang doch nicht ganz auf der falschen Spur. Ich habe einen HM600, da müssen dann die 'Überlauf' Bytes in 2 Nachrichten verteilt sein, sonst geht das nicht auf. Ich vermute dann mal die letzten beiden 'null' Bytes (24/25) in Msg 01 für P1 total, und die beiden Bytes vor P2 Total in Msg 02 (12/13). Mal sehen, ob/wann das jemand mit einem HM600 bestätigen kann - bei mir dauert das wohl noch ... In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen Nachricht um 1 erhöht wird (ich sende aktuell alle 15 Sekunden eine Anfrage ab). Da ich mir die Nachrichten der anderen Inverter nicht so genau angeschaut habe, gibt es sowas da auch (ich glaube, ich hatte da was gelesen - ansteigender Wert)? Das könnte dann ein Hinweis sein, dass sich dahinter mehr verbirgt. Evtl. lässt sich ja damit irgendwie der Inhalt der letzten 4 Bytes dieser Nachricht entschlüsseln, aber ein Muster (oder Wiederholungen, die z.B. auf die noch fehlenden SW/HW Version hindeuten könnten) habe ich bislang noch nicht gefunden. In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder abends das Licht schwach ist und keine Einspeisung passiert, ist dieser Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und '1002' gesehen. Leider habe ich keine passenden Codes in den Manuals gefunden, aber es schaut plausibel aus.
lpb schrieb: ... > In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder > abends das Licht schwach ist und keine Einspeisung passiert, ist dieser > Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) > ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und > '1002' gesehen. ... Ich biete zusätzlich noch 1003,1004,1008,1038
lpb schrieb: > In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein > inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen > Nachricht um 1 erhöht wird An welcher Position?
Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden, einzig die Energieproduktionen sind monoton steigend. Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir eine Gesamtübersicht / Doku der Bytes machen können? Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander die Module ab und wieder angeklemmt habe -> sie stimmt.
Herbert K. schrieb: > Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank > holt, müssten in den Telegrammen ja auch noch Hardware und Software > Version versteckt sein ? > (wird in der Cloud ja angezeigt) Ich denke, es gibt weitere Kommandos, die nur am Anfang ausgetauscht werden, wenn z.B. die DTU mit dem Wechelrichter Kontakt aufnimmt. Hat jemand mit einer DTU schon mal während der Einstellung der Begrenzng der Nennleistung die Kommandos 'gesnifft'?
Lukas P. schrieb: > Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden, > einzig die Energieproduktionen sind monoton steigend. > > Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir > eine Gesamtübersicht / Doku der Bytes machen können? > > Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander > die Module ab und wieder angeklemmt habe -> sie stimmt. Ich hätte da Daten, darf aber nicht mitspielen: wo fange ich an? Der Thread ist etwas unüberschaubar. Ich habe NRF, Atmega, Espxxxx und Raspi…
Angehängte Dateien:
-
hm600_msg0x83.png
120 KB
Martin G. schrieb: > lpb schrieb: >> In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein >> inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen >> Nachricht um 1 erhöht wird > > An welcher Position? Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in dem angehängtem Auszug der dekodierten Daten).
> wo fange ich an? > Der Thread ist etwas unüberschaubar. > Ich habe NRF, Atmega, Espxxxx und Raspi… NRF24L01+ und ESP8266/ESP32 funktionieren anhand des o.g. Schaltplans (Fritzing) und mit der Software NRF24_SendRcv.zip (18,2 KB) von Hubi vom 13.4.2022 für einen Hoymiles HM-600 recht zuverlässig. Solltest Du einen anderen HM-1200, etc. Wechselrichter haben, ist wohl noch etwas Detailarbeit nötig. Auch die Kommandos der DTU (pro) um ggf. den Zero-Export-Restriction Modus (z.B. Limitierung der Asugangsleistung auf 600W bzw. 600VA) umzustellen sind bisher noch nicht bekannt. Einzelne Bytes der Nachrichten sind aktuell auch noch nicht zweifellos geklärt, u.a. Hardware-, Software- und Netzprofilversion wie in der Hoymiles Cloud ausgegeben sind noch unbekannt. Dazu ggf. die letzten Beiträge von lumapu und avr-herbi nochmal lesen. Wenn ich es richtig aufgefaßt habe stehen aktuell noch einige große Themen an: * DFU (pro) Kommunikation bei der Einrichtung der Hoymiles App (am besten auf mehreren / allen Kanälen) mitschneiden. * genaueres Verständnis für das sog. Channel Hopping, damit hängt evtl. auch die laufende Nummer der Nachrichten und der CRC Algorithmus zusammen. * die ModBus Schnittstelle scheint die meisten Datagramme zu beschreiben. Hierzu sollte man die Dokumentation mit dem bisher erforschten nochmals vergleichen und ggf. bestehende Lücken auf unserer Seite dokumentieren bzw. untersuchen. * HM-600, HM-1200, etc. Protokoll genauer untersuchen bzw. länger Protokoll Aufzeichnungen analysieren (wg. Überlauf). * Inverter Status Codes 1000, 1001, 1002, 1003, 1004, 1008, 1038 in der 0x83 Nachricht interpretieren. * NRF24_SendRcv aktuell nur für HM-600, daher für andere Wechselrichter HM-1200, etc. erweitern. * NRF24_SendRcv erweitern um mehrere Inverter / Wechselrichter nacheinander abzufragen.
Herbert K. schrieb: > Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank > holt, müssten in den Telegrammen ja auch noch Hardware und Software > Version versteckt sein ? > (wird in der Cloud ja angezeigt) Bis auf die Softwareversion sollte alles in der Seriennummer enthalten sein. Diese, soweit ich das verstanden habe, gibt man ja beim Einrichten der DTU an. Marcel
> Wer erbarmt sich?😪 Du kannst auch das Ahoy [1] GitHub Repo von Martin G. (Petersilie) auschecken, dort befindet sich nun auch die von lumapu um ein ESP WiFi-Setup und OTA erweiterte ESP8266 Version, wie auch die bereits im Vorfeld von den Ersten hier im Thread benutzte Python Variante des ahoy Tools. Dafür brauchst Du dann halt einen Raspberry Pi 2+ das NRF24L01+ Modul und die Verkabelung. Was Du verwenden und erreichen möchtest entscheidet jede/r selbst. [1] https://github.com/grindylow/ahoy/
Herbert K. schrieb: >> In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder >> abends das Licht schwach ist und keine Einspeisung passiert, ist dieser >> Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) >> ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und >> '1002' gesehen. ... > Ich biete zusätzlich noch 1003,1004,1008,1038 In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von Registern angegeben, hängt das eventuell miteinander zusammen ? 4.3.2 Microinverter Data Register List The following registers provide a microinverter data register list, which can be read-only with the function code 0x03 | Registers | Name | Decimal | Units | Remark | | --------- | ---------------- | ------- | ----- | ------------------------------------------------------------ | | 0x1000 | Data Type | / | / | Default, 0x3C | | 0x1001 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1002 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1003 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1004 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1005 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1006 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1007 | Port Number | / | / | | | 0x1008 | PV Voltage | 1 | V | | | 0x1009 | PV Voltage | 1 | V | | | 0x100A | PV Current | 1/2 | A | 1 for MI Series, 2 for HM Series | | 0x100B | PV Current | 1/2 | A | 1 for MI Series, 2 for HM Series | | 0x100C | Grid Voltage | 1 | V | | | 0x100D | Grid Voltage | 1 | V | | | 0x100E | Grid frequency | 2 | Hz | | | 0x100F | Grid frequency | 2 | Hz | | | 0x1010 | PV Power | 1 | W | | | 0x1011 | PV Power | 1 | W | | | 0x1012 | Today Production | / | Wh | | | 0x1013 | Today Production | / | Wh | | | 0x1014 | Total Production | / | Wh | | | 0x1015 | Total Production | / | Wh | | | 0x1016 | Total Production | / | Wh | | | 0x1017 | Total Production | / | Wh | | | 0x1018 | Temperature | 1 | °C | Microinverter internal temperature | | 0x1019 | Temperature | 1 | °C | Microinverter internal temperature | | 0x101A | Operating Status | / | / | | | 0x101B | Operating Status | / | / | | | 0x101C | Alarm Code | / | / | | | 0x101D | Alarm Code | / | / | | | 0x101E | Alarm Count | / | / | | | 0x101F | Alarm Count | / | / | | | 0x1020 | Link Status | / | / | Communication status with DTU | | 0x1021 | / | / | / | Fixed, 0x07 | | 0x1022 | Reserved | / | / | | | 0x1023 | Reserved | / | / | | | 0x1024 | Reserved | / | / | | | 0x1025 | Reserved | / | / | | | 0x1026 | Reserved | / | / | | | 0x1027 | Reserved | / | / | | | 0x1028 | Data Type | / | / | Default, 0x3C | | 0x1029 | | / | / | | Die Daten können offenbar mit dem entsprechenden 0x03 Kommando angefordert werden und aus der entsprechenden 0x03 Antwort entnommen werden: 4.2.3 Read Device Data * Command sending format | Name | Length | Value | Remark | | ---------------- | ------ | ----- | ------------- | | Address | 1 | | RS485 Address | | Function Code | 1 | 0x03 | | | Register Address | 2 | | Big-Endian | | Register Count | 2 | | Big-Endian | | CRC | 2 | | CRC16 | * Command response format (if success) | Name | Length | Value | Remark | | --------------- | ------ | ----- | ------------- | | Address | 1 | | RS485 Address | | Function Code | 1 | 0x03 | | | Data Length | 2 | | | | Data 1 | 2 | | Big-Endian | | Data 2 | 2 | | Big-Endian | | ...... | | | | | CRC | 2 | | CRC16 | * Command response format (if failed) | Name | Length | Value | Remark | | --------------- | ------ | ----- | ------------- | | Address | 1 | | RS485 Address | | Function Code | 1 | 0x83 | | | Wrong Data Code | 1 | 0x01 | | | CRC | 2 | | CRC16 | [1] https://www.mikrocontroller.net/attachment/552319/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
> Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier > möchte ich was beitragen. Ein pull-request habe ich erstellt. > > Aktueller Stand: > Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich > es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station). Hallo Lukas P., habe mir mal Deinen Code aus dem ahoy github geclont und versucht zu deployen. Folgende Punkte sind mir aufgefallen: * Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F. bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die Spannung am +3.3V Anschluß des ESP8266 ein. * das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt wie die ino Datei. * ich habe versucht die WiFi und Wechselrichter Daten auf der Setup Seite einzutragen. Leider ist das Programm die ganze Zeit schon beschäftigt im Hintergrund per nRF24L01+ und vermutlich Dummy Adress-Daten an den Hoymiles zu senden und zu empfangen. Dadurch verliere ich immer die Verbindung, bevor ich die WiFi und Device Daten eingeben kann. Gibt es eine Möglichkeit das Hauptprogramm (im unkonfigurierten Zustand) anzuhalten bzw. eine längere Wartezeit (z.B. 5 Minuten) zwischen den Anfragen zu konfigurieren ? * Alternativ könnte man diese evtl. auch in der defines.h hinterlegen, nur habe ich die korrekten define / settings nicht herausgefunden: #define SSID "meineSSID" #define PWD "meinPasswort" #define DEVNAME "ahoy-esp" #define HOY_ADDR 0x1141 7312 3456 * ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73 01 ?
Danke @isnoAhoy! Am Woende werfe ich mal den Lötkolben an. Mal schauen was ich dem HM1200 entlocken kann. Ich bin auch an einer Nulleinspeisung interessiert. Habe noch keinen Plan wie man so etwas erreichen kann. Ggf. auch ein Projekt hier im Forum unter anderem Thread, oder gibt es das gar schon? Danke für die Zusammenfassung.
isnoAhoy schrieb: > Folgende Punkte sind mir aufgefallen: > > * Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F. > bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am > nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die > Spannung am +3.3V Anschluß des ESP8266 ein. ich sehe aktuell kein Problem. Danke für den Hinweis, ich werde die anderen Settings mal ausprobieren. Aktuell kommen die 3.3V aus meinem FTDI USB Adpater. Habe auch schon mal extern versorgt, das hat aber nichts verbessert. Was mir aufgefallen ist: Ich bin relativ weit weg vom WR (eine Betondecke und 10m durch den Garten). Wenn ich allerdings direkt zum WR gehe, bekomme ich keine Pakete mehr. Hier im Keller muss die Antenne auch sehr genau liegen. > * das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine > Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt > wie die ino Datei. > [...] Danke für dein Feedback, ich habe eine neue Version eingecheckt, die hoffentlich alle deine Probleme beseitigt, hier das commit-log: - renamed .ino (must be identical to parent folder name) - build CRC over settings, only if the CRC matches settings are applied - send command 0x80 (set time was wrong) - improved crc16 routine - added statistics for received commands and send statistics (channels are not correct for now!) - receive of commands 0x01, 0x02, 0x03, 0x81 and 0x84 working
Angehängte Dateien:
-
220420_esp.png
44 KB
Im Anhang mal ein Screenshot der aktullen Verison. Wie im Commit-log schon geschrieben, stimmt die Statistik der Kanäle nicht, da diese Info nicht synchron erfasst wird, die Statistik der Cmds ist korrekt.
isnoAhoy schrieb: > ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder > bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73 > 01 ? Die Seriennummer muss man so angeben, wie sie auf dem WR steht. Nach jedem Byte muss ein ":" eingefügt werden, also z.B.
1 | 11:61:11:22:33:44 |
Hallo Lukas P. ich habe mir mal deinen Code im Git angeschaut, das ist ja super, alles sauber in C++. Mit meiner Programmierung bin ich schon weiter gekommen, auch schon für mehrere WR. So ganz gefällt mir das noch nicht, denn ist noch sehr RAM-intensiv, da die Konstanten halt alle dort abgelegt sind. Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen, melde dich.
Hallo Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?
:
Bearbeitet durch User
isnoAhoy schrieb: > In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von > Registern angegeben, > hängt das eventuell miteinander zusammen ? Modbus ist ein eigenes Kommunikationsprotokoll, siehe [https://de.wikipedia.org/wiki/Modbus]. Der "Funktionscode 0x03" dort bedeutet "Register lesen". Das hat nichts direkt mit unserem CMD=0x03 zu tun. Aber die Infos sind natürlich trotzdem nützlich. Zum Beispiel sehen wir anhand der Registerliste, welche Werte die Wechselrichter vermutlich liefern können, und was man vermutlich einstellen können sollte. Und mindestens der 0x80 Befehl ("Uhrzeit setzen") verwendet die gleiche CRC16 wie das Modbus Protokoll.
lpb schrieb: >> An welcher Position? > > Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in > dem angehängtem Auszug der dekodierten Daten). Hallo lpb, ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses Ergebnis bzw. wie genau fragst Du den WR ab?
Angehängte Dateien:
-
220420_ESP_2.png
36 KB
Hubi schrieb: > Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen, > melde dich. Danke für dein Lob. Ohne deine Vorarbeit hätte ich das nicht so schnell auf die Beine gestellt, danke für die Vorlage =) Ja ich habe interesse, wie du mich erreichst? - in jedem Git commit findet man in den ersten Zeilen die E-Mail des Autors - sofern diese richitg angegeben ist: Einfach ein '.patch' an die URL hängen und schon hast du sie ;-) https://github.com/grindylow/ahoy/commit/7d2437828830d7825953844d632aed72940d942c Anbei noch ein Screenshot meiner Darstellung der Werte - ich werde den Stand heute noch committen.
isnoAhoy schrieb: > Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in > das Readme.md auf dem Ahoy Github einchecken. @petersilie würdest du die Diagramme in Git übernehmen, ich fände das super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann könnte man bei Fragen immer öfter auf das Repository verweisen.
Lukas P. schrieb: > isnoAhoy schrieb: >> Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in >> das Readme.md auf dem Ahoy Github einchecken. > > @petersilie würdest du die Diagramme in Git übernehmen, ich fände das > super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann > könnte man bei Fragen immer öfter auf das Repository verweisen. Gute Idee. Hab mal die Diagramme und einen Anfang eines Quickstart-Guides hochgeladen: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
:
Bearbeitet durch User
Martin G. schrieb: > Hallo lpb, > > ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in > meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im > Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses > Ergebnis bzw. wie genau fragst Du den WR ab? Vielen Dank für die Blumen, aber ohne die vielen Hinweise und Diskussionen hier hätte ich das sicher nicht hinbekommen. Im wesentlichen nutze ich das hier geteilte nrf24_sendrcv. Ich habe das ganze in der Arduino IDE auf den D1 mini mit einem EPS32 portiert. Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des 'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine Nachricht(en) empfangen habe. Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal 3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte. Je nach der eingestellten 'Wartezeit' habe ich mehr oder weniger oft alle 3 Nachrichten von meinem HM600 empfangen. Empirisch ermittelt war 4ms in meinem Code ein ganz guter Wert. Ebenfalls habe ich verschiedene Rx Kanäle und Reihenfolgen probiert. Dabei habe ich einige nie gesehen und daher wieder verworfen. Falls das jemand ausprobieren möchte, ich habe das so realisiert:
1 | uint8_t rx_channels[] = {3, 23, 61, 75, 83}; |
2 | uint8_t rx_chn_num = 5; |
3 | uint8_t intvl = 4; |
4 | ...
|
5 | // NRF rx/tx handling
|
6 | if (millis() >= tickMillis) |
7 | {
|
8 | tickMillis += intvl; |
9 | // rx channel switching
|
10 | chn_id++; |
11 | if (chn_id >= rx_chn_num) |
12 | chn_id = 0; |
13 | rx_channel = rx_channels[chn_id]; |
14 | DISABLE_EINT; |
15 | radio.stopListening(); |
16 | radio.setChannel(rx_channel); |
17 | radio.startListening(); |
18 | ENABLE_EINT; |
Ziyat T. schrieb: > Hallo > wenn sich jemand interessiert im Anhang > MI1500 > DTU-pro log Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC Freq. und U_AC) konnte ich schon identifizieren, natürlich alles angenommen. Beim 01er Command (Spalte A, ich weiß nicht ob das ein Command ist) sieht es für mich so aus, als gäbe es in Spalte D noch ein Sub-Command. Wenn Spalte A auf 5A steht bedeutet das wahrscheinlich Fehler oä.
lpb schrieb: > Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des > 'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer > festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine > Nachricht(en) empfangen habe. > Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal > 3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte. Das ist sehr interessant. Ich habe den Empfang fix auf Kanal 3 stehen und gemerkt, dass ich quasi nur Antworten bekommen habe wenn ich auf Kanal 61 sende. Ich sende jede Sekunde ein Paket, nach 6 Paketen wechsele ich zum nächsten Kanal, aktuell sind das 4 Stück (23, 40, 61 und 75). Mal beobachten wie es sich die nächsten Tage verhält. Was ich noch nicht verstehe: Sendest du deine Nachricht mit 0x80-0x84 commands und bekommst eine 0x83 Nachricht zurück? Vom HM1200 kann ich folgendes beobachten: Senden von 0x80-0x84 führt zur Antwort von 0x01-0x03, 0x81 und 0x84.
> Was ich noch nicht verstehe: denSest du deine Nachricht mit 0x80-0x84 > commands und bekommst eine 0x83 Nachricht zurück? Ich sende jedesmal die 0x80 Zeit setzen Nachricht. Ich nehme einfach an, dass darauf hin der WR seinen aktuellen Status sendet, beim HM600 dann die 0x01, 0x02, und 0x83 Nachrichten. Mit den anderen Anfragen könnte ich allerdings auch noch mal spielen, das habe ich bislang nicht gemacht. Als nächstes wollte ich noch mal die Antwort-Zeiten und die Kanäle auswerten, ob sich da eventuell ein Muster erkennen lässt, denn hin und wieder verpasse ich einzelne Antwort-Nachrichten, oder bekomme gar keine Antwort auf eine Anfrage. Leider ist es nicht so einfach zu sagen, ob das an der SW oder evtl der HF Umgebung liegt. Die Anzeige in einem Webserver ist übrigens auch sehr schick, ich sende meine Daten allerdings an emoncms auf einem Raspberry, das ist dann fast so schick wie in der Hoymiles Cloud :)
Lukas P. schrieb: > Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC > Freq. und U_AC) konnte ich schon identifizieren, natürlich alles > angenommen. Hallo Lukas Vielen Dank für deine Bemühungen! Habe auch die Daten von der V/Freq gefunden. Allerdings deine Deutung der U_DC, P_DC, AC stimmen leider nicht. Ich habe im Anhang die neue (meine) Ordnung der Daten, ganz rechts siehst du die reale Daten, bei meinen PV's ist die UDC 37-45V. Ich bin mir sicher dass die Spalte C die MPPT sind: 0xB6/0xB7 > MPPT1 ,2 ports nicht angeschlossen 0xB8/0xB9 > MPPT2 ,2 ports mit PV belegt ansonsten bin ich leider nicht weiter gekommen, muss mal pausieren ;-)
Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal gelesen zu haben. Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88. Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten: 08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch. Diese Zahl hinter der 80 scheint mir eine Einstellung für den WR zu sein, in welchem Format er senden soll. Hat jmd schon ähnliche Beobachtungen gemacht? Vllt ist es auch ein Kennzeichen der DTU, welche sie ist DTU-Prlo oder lite.
Hubi schrieb: > Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter > der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen > zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die > Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88. > Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten: > 08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch. Hallo Hubi, wo hast Du das Senden Bitte im Source geändert ? (Wo die Pakete aufgedröselt werden, weiss ich) Dann könnte ich das mal mit einem HM-400 und die nä. Tage auch mit HM-350 mal testen.
in HM_Packets::GetTimePacket die Zeile buf[10] = 0x03;
Hubi schrieb:
Spannend :-)
Mit buf[10] = 0x0B;
habe ich beim HM400 Antwort Telegramme 01 und ab und zu 82 bekommen.
Mit buf[10] = 0x03;
bekomme ich beim HM400 die Telegramme 01,02,03,04 als Antwort.
04: aber sehr sehr selten
044060000040C066663FA6CCCD412CEB85AA7F42
044060000040C066663FA6CCCD412CEB85AA366A
044060000040C066663FA6CCCD412CEB85AA366A
01: die Werte sind jetzt statisch und ändern sich nicht mehr
Alles im Allen bisher nur nix wo man DC V,A,W / AC V,A,W / Hz
wiederfinden kann über analyseWords / analyseLongs
Aber eine Interessante Entdeckung. Vielleicht löst jemand das Rätsel
noch?
@Lukas P. Der neue Commit ließ sich übersetzen und nun auch Konfigurieren. Sowohl die Auswahl einer existierenden WiFi Connection (Liste der gescannten WiFi SSIDs) als auch das Speichern des Passworts und des Device Names waren am Tablet etwas knifflig. Es gab keine Ausgabe der Konfiguration (DNS Name / IP) per Serial Monitor bzw. Redirect auf die Status Seite (/) und auch nach einem Neustart war nicht klar, ob und wie man den ESP per DNS erreichen kann, bzw. welche DHCP Adresse er vom Router bekommen hat. Meine HM-600 Adresse (sowie die anderen Parameter) wurden aber offensichtlich gesetzt, nach einem Hard Reset waren alle noch da. Aber der Device Name beim Router ESP-429DF0 blieb wie beim ersten Start vergeben, eventuell wäre es hier besser den Device Name (ESP-<MAC>) einfach anzuzeigen. Uptime lag am Ende bei 10 Minuten und die Time wurde offensichtlich vom NTP Server (o.a.) synchronisiert. Die /livedata URL ist noch nicht verlinkt und Daten vom HM-600 wurden keine empfangen, daher blieb vermutlich auch die /hoymiles Seite leer "Every 10 seconds the values are updated". Ich vermute mal daß die HM-1200 Konfiguration aus Deinem letzten Commit die HM-600 Konfiguration von Hubi überschrieben hat ? @Martin G. Ja das mit dem ModBus Protokoll hatte ich auch gesehen, aber die Codes erschienen mir zu ähnlich zu den Register Adressen. An anderer Stelle CRC16 und 0x80 scheint es ja auch diverse Gemeinsamkeiten zu geben. Laut dem Abschnitt 4.3.3 Device SN Register List scheint es auch ein Register für die Seriennummern der DTU und der WR zu geben. Ich habe daher mal die DTU Modell und Seriennummern dazu notiert. Das scheint ja in der Zukunft evtl. interessant zu werden. Eventuell könnte man auch den DTU Pro per ModBus ansprechen um die o.g. Informationen zu lesen / setzen und dabei das nRF Protokoll mit einem/mehreren nRF24L01+ im Promisuous Modus tracen. So könnten wir das Kommunikationsprotokoll der DTU Pro relativ einfach und reproduzierbar analysieren. Danke auch für die Übernahme der Verbindungsskizze in das GitHub Repo. Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für Diagramme [1] wie ditaa Diagrams through ASCII Art [2], mermaid-js [3] und WaveDrom [4] herum. Z.B. könnten wir die hoymiles-format-description.txt einfach umbenennen zu hoymiles-format-description.md. Wenn Du die Diagramme im Markdown rendern möchtest einfach mit folgendem einem ditaa Code Tag umgeben. Ein Export von Markdown zu PDF funktioniert soweit ich weiß aber nur mit dem mermaid-js Plugin. [1] Markdown Diagrams https://gist.github.com/blackcater/1701e845a963216541591106c1bb9d3b [2] ditaa Diagrams through ASCII Art https://github.com/stathissideris/ditaa [3] mermaid-js https://mermaid-js.github.io/mermaid/#/gantt [4] WaveDrom https://github.com/drom/wavedrom @Ziyat T. das weiß ich nicht sicher, laut der gestern von mir aktualisierten Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread, oder sind das mehrmals die selben (mal Prefix und mal Postfix)? [1] 1161xxxxxxxx Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" [2] xxxxxxx14456 & xxxxxxx36590 Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Eventuell sollten wir die Kürzel der Nutzer aus dem Forum dahinterschreiben, damit wir ggf. die Seriennummern besser korrigieren können ? Du kannst auch alles auf einer Seite anzeigen lassen und einfach nach 1500 suchen, da findest Du dann Thomas B. und Arnaldo G. und Waldemar K. Zumindest Arnaldo hat auch fünf MI1500. M.E. ist die Bezeichnung MI / HM austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter) für den Typ Wechselrichter. Ich glaube auf meinem Typenschild / Aufkleber am Karton stehen auch beide Bezeichnungen.
isnoAhoy schrieb: > > @Ziyat T. > das weiß ich nicht sicher, laut der gestern von mir aktualisierten > Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread, Hallo isnoAhoy Danke für die WR-Liste Ich bin mir ziemlich sicher dass die MI series HW/SW-maessig nicht gleich sind, HM 3.gen./MI 2.gen. MI series: - untere Limitierung 10%, WR nur als ganzer limitierbar. - mehrere DTU-ModbusRegister funktionieren nicht, da wahrscheinlich nicht im WR vorhanden HM series: - untere Limitierung bis 2%, auch port based limitierbar. - alle Modbus DTU-ModbusRegister funktionieren Ich bekomme von meinem MI1500 ganz andere antworten (bisher nur, wenn ich die DTU-Pro einschalte), bisher konnte ich den MI auch nicht direkt ansprechen. 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.
Hallo Ich habe versucht 2 Tage lang meinen MI1500 zu wecken. Ich verwende Hubi's SW auf ESP, habe alle MSGid & CMD Kombination durchgespilet, keine Antwort. Send... CH40 [15]6370716072228412[81]50 hier 0x15 und 0x81 [0x0-0xFF]6370716072228412[0x0-0xFF]50 Kombinationen (NRF24 funktioniert, ich sehe WR-Antworten wenn die DTU einschalte) Hat jemand nen Vorschlag? Danke
Ist das die letzte Version mit der Routine Serial2RadioID? Seriennummer auch richtig eingetragen, also Seriennummer zb 114172607952 dann
1 | #define SerialWR 0x114172607952ULL
|
2 | uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); |
in der Settings.h
Hubi schrieb: > Ist das die letzte Version mit der Routine Serial2RadioID? > Seriennummer auch richtig eingetragen, also > Seriennummer zb 114172607952 dann >
1 | > #define SerialWR 0x114172607952ULL |
2 | > uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); |
3 | >
|
> in der Settings.h
Ja, genau
#define SerialWR 0x106163707160ULL //
uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); //
//#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
//10F8---72228412 12842272
#define DTU_RADIO_ID ((uint64_t)0x1284227201ULL)
Hi isnoAhoy, Du schriebst im Beitrag #7042229: > M.E. ist die Bezeichnung MI / HM > austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter) > für den Typ Wechselrichter. Auf der Seite https://www.hoymiles.com/de-eu/microinverter-single-phase ziemlich in der Mitte wird zwischen beiden Modellreihen unterschieden: "MI-Mikro-Wechselrichter Unsere MI-Mikro-Wechselrichter sind die kompaktesten Modelle in unserem Sortiment und ideal für jede Anlage." vs. "HM-Mikro-Wechselrichter Mit einem Gerät der HM-Serie erhalten Sie Blindleistungsregelung und eine bessere Datenverbindung dank einer externen Antenne." - Ich lese hier schon eine Weile sehr erfreut mit und werde meinen heute gelieferten HM-1500 gerne auch sniffen und die Mitschnitte hier verfügbar machen, sobald ich die Panels bekommen und aufs Dach gebracht habe. Und sofern ich mich durchringe, den Gateway-Stick für 90€ zu kaufen - bin da noch unentschieden :-) Maik
Hallo, ist jemand da dran, die Anzahl der WR zu erweitern ? Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die Serielle (war ja im Prinzip schon fast drin, aber auskommentiert). Hab nun heute Nachschub bekommen HM-350. Dafür fliegen andere Hersteller raus, die nicht so tun, wie ich es erwartet habe. Wenn ich anfange im Code herumzuwurschteln, wird jeder "C" Programmierer die Hände über den Kopf zusammenschlagen vermute ich. Eine Idee dazu: Solange wir nicht wissen, wie man aus den S/N oder den Telegrammen auf das Modell inkl. HW Vers. / SW Vers. kommt, wären Tabellen sicher nicht schlecht: 1. Tab: Alle bisher bekannten Typen von WR., Anzahl MPPT Tracker, Anzahl DC-Inputs 2. Tab: Länder Kennungen (gibt scheinbar auch je nach Vorschriften in den Ländern verschiedene Funktionen / Verhaltensweisen. EU und Österreich für den Anfang :-) 3. Tab: Tabelle mit S/N, Modell (aus Tab 1), HW Vers., SW Vers., Land Ist nur mal so eine Idee .... Ergänzung: Eben mal einen alten WR rausgeworfen (der auch schon abgeschaltet hatte), S/N von einem 400 auf eine neue S/N vom 350 geändert. :-) Funktioniert sofort :-) P-Total = 0.0 :-) und der 350er speisst sogar noch ein. Nun kann ich ohne schlaflose Nacht träumen :-)
:
Bearbeitet durch User
Herbert K. schrieb: > ist jemand da dran, die Anzahl der WR zu erweitern ? > Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die > Serielle (war ja im Prinzip schon fast drin, aber auskommentiert). Ich habe da schon ein Konzept entwickelt (funzt auch für minsdestens 2 WR, auch mit Arduino, obwohl wenig Speicher) und Lukas P. will das (oder ähnlich) in seine ESP-Version auf der ahoy-Seite einbauen. Also, etwas Geduld, und das wird schon was tolles.
Hallo zusammen, als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5 anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden) und würde ihm gerne ein wenig auf die Finger gucken. Ich habe die bisherigen 3 Seiten weitestgehend durchgelesen und dabei zu verstehen versucht, über was ihr schreibt, habe dabei aber ziemliche Verständnisprobleme. Ich habe einen Raspi 3, einen alten Arduino Mega und einen ESP32 und auf allen schon ein paar Sachen in Richtung Midi + BTLE und ein wenig Anwendungsprogrammierung (Zusammenführen von Sensorsignalen und daraus rechnerisch Meta-Informationen erzeugen) gemacht. Das Jonglieren mit / Bitfieseln von irgendwelchen sonstigen Protokollen / ModBus ist mir allerdings noch unbekannt/fremd. Mit den Voraussetzungen: Wo kann ich mich einigermaßen linear in die aktuelle Problematik einlesen? Wie kann ich euch ggf. z.B. durch Datensammeln unterstützen? Viele Grüße aus Aachen, Petra
Petra-Kathi schrieb: > Wo kann ich mich einigermaßen linear in die aktuelle Problematik einlesen? > Wie kann ich euch ggf. z.B. durch Datensammeln unterstützen? https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md und https://github.com/Yveaux/NRF24_Sniffer Sind für mich die Einstiege. Ein nRF24 Modul (5€) ist auf eBay bestellt, ein mini-DUT für 88€ auch. HTH, Maik
@Lukas P.(lumapu) @Hubi Hallo Ich habe heute die https://github.com/grindylow/ahoy/tree/main/tools/esp8266 geladen und laufen lassen. Ich finde die SW sauber! Mit Hubi's SW konnte ich, wenn ich die DTUpro einschaltete, die DTUpro msg's 00/01 empfangen.(siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") Mit der ahoy SW kann ich nichts empfangen, fand ich merkwürdig. Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte ich: mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE); Serial.println("sent packet: #" + String(mSendCnt)); dumpBuf(mSendBuf, size); DTU und WR Adressen sind richtig: CH: 23 sent packet: #15 1563707160722284128352 CH: 23 sent packet: #16 1563707160722284128253 CH: 23 sent packet: #17 1563707160722284128455 CH: 23 sent packet: #18 15637071607222841280b06263d9e6000500002ad398 CH: 40 sent packet: #19 1563707160722284128150
Hallo Maik, danke für deine Einstiegshilfe! > https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Hierüber bin ich noch auf die Langstory https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt gestoßen und habe mir diese erst mal durchgelesen. Was ich daraus und aus deinem zitierten > https://github.com/Yveaux/NRF24_Sniffer noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den Beiden dieses Sniffer-Modul ebenfalls noch erforderlich? Tschüssi, Petra
Petra-Kathi schrieb: > noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features > des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den > Beiden dieses Sniffer-Modul ebenfalls noch erforderlich? ja; DU BENÖTIGST EINEN NRF
SUNPOWER schrieb: > Petra-Kathi schrieb: >> noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features >> des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den >> Beiden dieses Sniffer-Modul ebenfalls noch erforderlich? > > ja; DU BENÖTIGST EINEN NRF Wichtig: einen mit “Plus” (nRF24L01+)
@Lukas P. (lumapu) Danke für die neuen Versionen auf Deinem github repo ich habe sowohl die von Dir mit HM-1200 als auch die von in grindylow gemergte Version versucht. Ich bekomme leider keine Antworten mehr vom HM-600. Was/wo sollte ich untersuchen. Wie gesagt mit Hubis Version vom 13.4. hat es funktioniert ? @Mail & @Ziyat, ja da habt ihr wohl Recht. Ob sich noch mehr geändert hat von 2.Generation MI zu 3.Gen HM müsste man evtl durch Fotos anhand der FCCID oder eigenes Begutachten des Mainboards in Erfahrung bringen. Eventuell gibt es ja auch eine Verbesserung von nRF24L01 zu nRF24L01+ o.a. was eine andere Datenrate erfordern würde ? Ich hatte auch schon vermutet dass die DTU pro evtl. einen nRF51/2 MCU verbaut hat da sich damit scheinbar mehr Wechselrichter abfragen lassen. @Ziyat willst Du Deine mal aufschrauben und uns Bilder schicken ?
@IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat mir hier sehr guten Input gegeben, wir versuchen das ganze so Leichtgewichtig wie möglich aufzusetzen. Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie ist eine gute Basis für sowas. Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und dynamisch ist, dass sie auch auf z.B. einem proMini läuft und gleichzeitig mehrere Wechselrichter unterstützt.
Angehängte Dateien:
-
220422_hm1200_5x.jpg
81 KB
Ziyat T. schrieb: > Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte > ich: > mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE); > Serial.println("sent packet: #" + String(mSendCnt)); > dumpBuf(mSendBuf, size); Damit solltest du nur die gesendeten Pakete sehen, die empfangenen kannst du in dieser Zeile anzeigen lassen: https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97 Petra-Kathi schrieb: > als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5 > anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden) Ich habe vor mehr als 4 Module an meinem HM1200 zu betreiben, testweise habe ich immer mal wieder 5 dran. Zwei sind parallel mit Dioden an einem Anschluss, der Screenshot spricht für sich. (Channel 3)
@Lukas P. > schrieb: > Damit solltest du nur die gesendeten Pakete sehen, die empfangenen > kannst du in dieser Zeile anzeigen lassen: > https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97 > Ich habe die Version ohne MQTT vor 4 Tagen, ich denke, ich habe die richtige Zeile auskommentiert: void app::loop(void) { Main::loop(); if(!mBufCtrl->empty()) { uint8_t len, rptCnt; NRF24_packet_t *p = mBufCtrl->getBack(); //toe mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE); //toe Ich werde mal die Innereien der DTU-Pro mal anschauen.
Peter L. schrieb: > Wichtig: einen mit “Plus” (nRF24L01+) Danke für den Hinweis. Dingens ist bereits bestellt. Tschüssi, Petra
Hallo Lukas P.
danke für die Bestätigung, daß es aktuell noch nicht mit dem HM-600
geht.
Ich hatte das schon vermutet, da es bisher nur eine hm1200Decode.h gibt.
Die Punkte bzgl. der Software hatte ich auch eher als ein Review
verstanden,
falls Du / andere das irgendwie noch aufhübschen wollt.
Bzgl. Speicherverbrauch und "leichtgewichtig" ist mir aufgefallen,
daß die html/h/*.h Dateien zwar in einer Zeile untergebracht sind,
aber immer noch sehr viele Leerzeichen für die Einrückungen enthalten.
Evtl. könnte man das mit FileConv.exe oder sed unter Linux noch etwas
anders gestalten ?
Ich nehme an da die {VARIABLE} Ausdrücke ersetzt werden sollen,
kann man die HTML Seiten auch nicht im Flash Memory des ESP speichern ?
Hallo isnoAhoy, ja ich fände es super das ganze noch aufzuhübschen. Das ist das erste Mal, dass ich was in dieser Richtung veröffentlich habe - ich habe diesen ESP (app und main Klasse) schon in diversen Projekten verwendet und es hat sich immer gezeigt, dass man es schnell für ein neues Projekt verwenden kann. Bisher habe ich mich geweigert Tasmota irgendwo zu installieren - ich mach das selbst ;-), z.B für den Sonoff-POW-R2 und RGB-LED Streifen Das Fileconv.exe habe ich mir aus der Not gebaut und es kürzt der einfachheit halber alle Whitespaces auf ein Space ein. Ich habe mich nicht näher mit der Thematik auseinandergesetzt und bin hier offen für Input. Schön ist halt aktuell nur ein Binary zu haben und es ist alles drin. Die geschweiften Klammern sind die Bereiche, die ich im Code dann ersetze, richtig z.B.
1 | html.replace("{VERSION}", mVersion);
|
Lukas P. schrieb: > @IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git > geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat > mir hier sehr guten Input gegeben, wir versuchen das ganze so > Leichtgewichtig wie möglich aufzusetzen. > > Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die > alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie > ist eine gute Basis für sowas. > > Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine > C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und > dynamisch ist, dass sie auch auf z.B. einem proMini läuft und > gleichzeitig mehrere Wechselrichter unterstützt. Deinen Code teste ich gleich morgen, wenn es wieder hell ist... Da ist ein Fehlerchen: https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/mqtt.h#L54
Peter L. schrieb: > Da ist ein Fehlerchen: ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke
Hallo Lukas P., Prinzipiell ist es bei ESP8266 und ESP32 vorteilhaft größere Strings im PROGMEM [2] (bis zu 4 MB Flash Memory) abzulegen. Das ist zwar nicht ganz so schnell und flexibel wie das normale RAM / ROM aber dafür gibt es eben viel Platz. Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:
1 | static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"
|
Ich habe mal nachgesehen, hier ist ein Beispiel von Sebastian Glahn wie man string.replace() und FPSTR() für das WebServer Modul verwenden kann [2].
1 | String body = FPSTR(HTTP_BODY); |
2 | body.replace("{{variable}}", configuration.variable);
|
3 | page += body; |
[1] https://arduino-esp8266.readthedocs.io/en/latest/PROGMEM.html [2] https://blog.tldnr.org/2017/10/25/how-to-deliver-larger-web-pages-with-an-esp8266/
isnoAhoy schrieb: > Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für > Diagramme [1] wie ditaa Diagrams through ASCII Art [2], mermaid-js [3] > und WaveDrom [4] herum. > Z.B. könnten wir die hoymiles-format-description.txt einfach umbenennen > zu hoymiles-format-description.md. Danke für Deine Arbeit. Die Nachfragen nach einem "zusammenhängenden" Dokument häufen sich ja (macht auch Sinn). Ich frage mich, ob wir so etwas vielleicht mit Hilfe von readthedocs.io aufbauen können?
Lukas P. schrieb: > Peter L. schrieb: >> Da ist ein Fehlerchen: > > ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke Sowas kommt vor, kenne ich aus eigener Erfahrung ;-) Nach Korrektur funktioniert es mit meinem MQTT-Broker perfekt! Auch die Daten des HM-1200 mit nur drei Panels sehen gut aus; vielen Dank für die gute Arbeit!
Ich habe meine NRF-Module nun erhalten. Ich habe mich die ganze Zeit gewundert, warum [[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen Empfang brachte, mit Hubis Code jedoch alles funktioniert. Verkabelung ist nach diesem Schema: [[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]] Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:
1 | //-------------------------------------
|
2 | // PINOUT
|
3 | //-------------------------------------
|
4 | #define RF24_IRQ_PIN (D3)
|
5 | #define RF24_CE_PIN (D4)
|
6 | #define RF24_CS_PIN (D8)
|
Ist das so gewollt (GIT Verkabelung vs. Code)? Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten (also keine AC Spannung/Energie/Frequenz) Das ist die Statistik nach einigen Minuten:
1 | CMDs:
|
2 | 0x01: 18 |
3 | 0x02: 0 |
4 | 0x03: 0 |
5 | 0x81: 55 |
6 | 0x84: 0 |
7 | other: 13 |
8 | |
9 | CHANNELs: |
10 | 23: 0 |
11 | 40: 9 |
12 | 61: 44 |
13 | 75: 33 |
@Herbert K. Welche Erweiterungen hast Du für den 400er denn vorgenommen?
Lukas P. schrieb: > Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die > alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie > ist eine gute Basis für sowas. Eine Integration in Tasmota wäre super - würde mich auch daran mit einem POC versuchen, sobald ich einen halbwegs lauffähigen Code mit meinem HM-400 hinbekomme.
Marcus schrieb: > Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten > (also keine AC Spannung/Energie/Frequenz) > Das ist die Statistik nach einigen Minuten: >
1 | CMDs:
|
2 | > 0x01: 18 |
3 | > 0x02: 0 |
4 | > 0x03: 0 |
5 | > 0x81: 55 |
6 | > 0x84: 0 |
7 | > other: 13 |
8 | >
|
9 | > CHANNELs: |
10 | > 23: 0 |
11 | > 40: 9 |
12 | > 61: 44 |
13 | > 75: 33 |
> @Herbert K. > Welche Erweiterungen hast Du für den 400er denn vorgenommen? Ich bekomme nur "01", "81" (keine Ahnung wozu die gut sind) und ab und zu - sehr selten - "82" Antworten für 350/400 die sinnig sind nach den bisherigen Analysen. 02,03,04,84 hab ich nicht mit Hubis Vorarbeit (alter Code). In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur und Unbekanntes
Marcus schrieb: > Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen: > [c]//------------------------------------- > // PINOUT > //------------------------------------- > #define RF24_IRQ_PIN (D3) > #define RF24_CE_PIN (D4) Habe auch erst heute gemerkt ;-)
Hallo Leute, Ich verfolge die Entwicklung der selbstbau DTU schon eine Weile. Großes Lob an die Macher der Software. Nun wollte ich auch mal meine beiden Wechselrichter belauschen. Die Software ist auf dem ESP das Webinterface läuft aber leider bekomme ich keine Verbindung zum Funkmodul. Ich denke es liegt wie oben beschreiben an den falschen Pins in der Firmware. Wenn ich die Pins in der defines.h ändere kann ich die Firmware nicht mehr auf den ESP laden da es Fehlermeldungen gibt. Ist es möglich das jemand eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP gebügelt werden muss? Vielen Dank
Herbert K. schrieb: > In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur Aha, dann werde ich mir das mal ansehen - kannst Du Deine "Entschlüsselung" hier mitteilen? Unter [[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]] ist es noch nicht zu finden. Ergänzend folgende Erfahrungen mit dem HM-400 und diesen Modulen [[https://www.amazon.de/dp/B06XJN417D]]: Noch mal etwas Statistik (ESP8266-Code)
1 | CMDs:
|
2 | 0x01: 490 |
3 | 0x02: 0 |
4 | 0x03: 0 |
5 | 0x81: 0 |
6 | 0x84: 0 |
7 | other: 227 |
8 | |
9 | CHANNELs: |
10 | 23: 2 |
11 | 40: 494 |
12 | 61: 186 |
13 | 75: 3 |
Zur Reichweite - das Modul ist hier ca. 30-40m über 2 Wände zum WR entfernt. Also ich finde das sehr gut. Was mich noch interessieren würde - es gibt ja immer diese P1 und P2 Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen dann nicht 2 bei einem HM-1200? Und warum habe ich bei meinem HM-400 (1 Panel) einen Wert bei P2 von 0 bei der DC-Spannung, aber unplausible Werte bei Strom und Leistung? Die Werte bei P1 sind plausibel.
Hallo Marcus, > Ich habe mich die ganze Zeit gewundert, warum > [[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen > Empfang brachte, mit Hubis Code jedoch alles funktioniert. > Verkabelung ist nach diesem Schema: > [[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]] > Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen: > //------------------------------------- > // PINOUT > //------------------------------------- > #define RF24_IRQ_PIN (D3) > #define RF24_CE_PIN (D4) > #define RF24_CS_PIN (D8) > Ist das so gewollt (GIT Verkabelung vs. Code)? Danke für das Auffinden des Fehlers, ich habe mich ja auch schon gewundert. Die Diagramme hatte ich für Hubis Source Code gemacht und Lukas hatte derweil den Source Code mit den WebSeiten angepaßt und hochgeladen. Auf die Idee die RF Pins zu überprüfen bin ich leider nicht gekommen. Ach ja die aktuelle github Version scheint nur HM1200 zu unterstützen. Der Decoder für HM600 und HM400 etc. scheint noch zu fehlen. @Lukas P., wollen wir die Anpassung im Code machen oder soll ich neue Diagramme generieren ?
Hallo, ich werde die Pins konfigurierbar machen und den default im Source auf die Diagramme anpassen. Dann muss man im besten Fall keine Änderungen am Code machen. Mein Code passt aktuell zu meiner Hardware. Den HM600 unterstützt meine Firmware schon fast, ich habe es in einen dev Branch auf meinem github Account und werde es sobald ich es für gut befinde ins Hauptrepository mergen. Gefühlt bin ich fast schon soweit. Marcus schrieb: > Was mich noch interessieren würde - es gibt ja immer diese P1 und P2 > Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen > dann nicht 2 bei einem HM-1200? Wir haben das alles selbst ermittelt, du kannst gerne Änderungen vorschlagen bzw. diese ermitteln. Im jeweiligen Code gibt es eigentlich immer eine Möglichkteit sich die Rohen Daten ausgeben zu lassen. Mich@ schrieb: > Ist es möglich das jemand > eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP > gebügelt werden muss? könnte man doch in Github über Releases machen, allerdings denke ich, dass wir noch viel zu früh im Projekt stehen um es Release zu nennen. Marcus schrieb: > würde mich auch daran mit einem > POC versuchen was ist ein POC?
Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern das es für esp8266 und esp32 geht. > Marcus schrieb: >> würde mich auch daran mit einem >> POC versuchen > > was ist ein POC? Proof of concept Marcel
Marcel A. schrieb: > Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern > das es für esp8266 und esp32 geht. finde ich super! Verwende am besten als Basis meinen aktuellen Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen veröffentlichten neuen Stand in main-Branch.
Hallo zusammen, ich finde das ein super interessantes Projekt. Eine Frage wird der HM-700 auch unterstützt werden?
Zur Auswertung/Datenanalyse: Ich habe mich nochmal durch den Thread gewühlt und folgende Theorie für meinen HM-400 und damit wohl "Single"-Wechselrichter - das kann ich an einen HM-300, wenn ich vor Ort bin, mal prüfen. Single-WR senden keine 02er (cmd / Byte 9) Nachrichten, diese senden vermutlich nur WR mit >= 2 Panels. Bei WR mit nur einem Panel stecken die (bisher erkannten) Daten in folgenden Nachrichten-Bytes (vieles IMHO schon bekannt, aber es hier jedenfalls "verlorengegangen": [[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]]).
1 | cmd 01 => |
2 | 12/13: DC-Spannung, Divisor 10 |
3 | 14/15: DC-Strom, Divisor 100 |
4 | 16/17: DC-Leistung, Divisor 10 |
5 | 18/19: unbekannt, bei mir immer 0 |
6 | hier ist IMHO bei WR mit >= 2 Panels die DC-Spannung des 2. Panels enthalten |
7 | 20/21: Gesamtleistung kWh, Divisor 1000 - (mir) unklar ob DC/AR Wert |
8 | hier ist IMHO bei WR mit >= 2 Panels der DC-Strom des 2. Panels enthalten |
9 | 22/23: tägliche Leistung Wh, Divisor 1? - (mir) unklar ob DC/AC Wert |
10 | hier ist IMHO bei WR mit >= 2 Panels die DC-Leistung des 2. Panels enthalten |
11 | 24/25: Spannung, Divisor 100 |
12 | |
13 | cmd 82 => |
14 | 10/11: Frequenz, Divisor 10 |
15 | 20/21: Temperatur, Divisor 10 |
Einen GIT-Account habe ich. Könnte o.g. Format-Beschreibung ergänzen. Diese müsste nach meiner Vermutung dann aber nach WR-Bauart (Anzahl Panels) unterscheiden. Für einen HM-400 sind somit erstmal die wesentlichsten Daten bekannt. Das mit den Leistungswerten (Gesamt/Tag) will ich selbst noch mal bei mir verifizieren.
Hallo Markus, ich fände es auch gut, das Wissen wo Zentral zu sammeln. Zum Thema HM-400/350 habe ich am 9.4 gepostet: (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut) 01: 2bytes unbekannt "1" 2bytes dc_volt / 10 2bytes dc_amps / 100 2bytes dc_power / 10 4bytes Total_w 2bytes Daily_w 2bytes ac_volt / 10 82: 2bytes ac_freq / 100 2bytes ac_power / 10 2byte unbekannt "0" 2bytes ac_current / 100 2byte unbekannt "1000" vielleicht /10 Power Factor in %? 2bytes temp / 10 2bytes unbekannt ansteigend 2bytes random Die Total Werte scheinen immer 4byte Werte zu sein. Das muss wohl bei HM-600/700 auch so sein .... allerdings geht sich das dort nicht so einfach aus
Lukas P. schrieb: > Marcel A. schrieb: >> Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern >> das es für esp8266 und esp32 geht. > > finde ich super! Verwende am besten als Basis meinen aktuellen > Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen > veröffentlichten neuen Stand in main-Branch. Ich hatte mir bisher nur das Repo https://github.com/grindylow/ahoy angeschaut und da gibt es keinen Dev Branch. Welchen Code meinst du ?
Da ich nicht der Eigentümer des Hauptrepositories bin habe ich einen Fork in meinem Account. Ich verlinke es nicht, da das Hauptrepository die Referenz für alles bleiben soll. Suche einfach nach dem Fork (auf der rechten Seite unter "About") von "lumapu" und dort im "dev" Branch.
Martin P. schrieb: > ich fände es auch gut, das Wissen wo Zentral zu sammeln. Habe das ergänzt und einen Pullrequest (PR) im git ausgelöst. Zu:
1 | 4bytes Total_w |
2 | 2bytes Daily_w |
1. ist das eigentlich die Leistung DC oder AC? 2. Total_w sind doch auch nur 2 Bytes, oder? Siehe hier (PR) unter cmd 01: [[https://github.com/grindylow/ahoy/pull/7/commits/dfa7975fedaa3993bd3655aa52bdaa83614dbac4]]
Marcus schrieb: > 1. ist das eigentlich die Leistung DC oder AC? Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher, dass es DC ist: der HM400 hat daily/total nur einmal .... der 2-port HM600 hat diese Werte je 2x (wie die DC Daten) > 2. Total_w sind doch auch nur 2 Bytes, oder? Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter oben hat es Herbert K. schon gezeigt, dass es so ist.
Martin P. schrieb: >Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher, >dass es DC ist: Wenn es aber die Leistungswerte für DC sind - gibt es die Gesamtwerte für AC gar nicht? Pro Panel mag das ja interessant sein, aber die Summe ist eben m.E. nur näherungsweise gleich der Summe AC seitig (beim Wandeln entstehen ja auch noch "Verluste") - oder wird das ggf. mit einem Faktor abgebildet, der weniger Bytes benötigt, als nochmal 2+4 Bytes für AC zu benötigen (Spekulation). Die momentane Leistung für AC ist ja inzw. bekannt - fehlt irgendwie Ptotal und Pdaily für AC. > Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil > die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter > oben hat es Herbert K. schon gezeigt, dass es so ist. Ahhh - das hatte ich übersehen - hab mich schon immer über die ständigen Nuller gewundert in den vorderen 2 Bytes - ich bin noch nicht über 65535 Wh ;-). Muss das in meiner Beschreibung noch korrigieren. Für den HM-400 habe ich jetzt alles sauber aufgeschrieben und versuche es in das GIT einzuchecken.
Hallo zusammen, es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist die 0.2.4 Sie bassiert auf dem Konzept von Hubi, Vielen Dank nochmal. Wir haben weitere Ideen, die dann in die nächste Version einfließen werden. Das sollte möglich sein: - mehrere Wechselrichter, aktuell sind per define 3 voreingestellt - verschiedene Wechselrichter, aktuell ist zwischen HM600 und HM1200 die Wahl - Pinout kann konfiguriert werden, voreingestellt ist das des Wemos D1mini - die Konvertierung der HMTL Seiten passiert jetzt mit python und sie werden im PROGMEM abgelegt - der code wurde soweit verändert, dass prinzipiell auch eine 'einfache' Portierung auf den proMini (328p) denkbar ist - ein MQTT client wurde eingebaut um die Werte woanders zu visualisieren (z.B. ioBroker) Über Feedback und Tests würde ich mich freuen, viel Spaß mit der neuen Firmware! Im Anhang habe ich mal meinen Build gehängt, damit man auch ohne Kompilieren auf die neue Version updaten kann - mal sehen ob das klappt.
Hallo Lukas,
Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur
den unten gezeigten Output
Der D1- Mini lief schon mal mit einem viel weiter oben im Thread
gezeigten Programm
Ich habe ihn zum Test auch mal mit einem blank-File geflasht - leider
auch erfolglos
Viele Grüße
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00057330
~ld
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Soft WDT reset
>>>stack>>>
ctx: cont
sp: 3ffffb40 end: 3fffffc0 offset: 01a0
3ffffce0: 00000000 3ffe901c 3ffeeff0 40204b01
3ffffcf0: 00000000 00000000 00000000 00000000
3ffffd00: 00000000 00000000 00000000 00000000
3ffffd10: 00000000 00000000 00000000 00000000
3ffffd20: 00000000 00000000 00000000 00000000
3ffffd30: 00000000 00000000 00000000 00000000
3ffffd40: 00000000 00000000 00000000 00000000
3ffffd50: 00000000 00000000 00000000 00000000
3ffffd60: 00000000 00000000 00000000 00000000
3ffffd70: 00000000 00000000 00000000 00000000
3ffffd80: 00000000 00000000 00000000 00000000
3ffffd90: 00000000 00000000 00000000 00000000
3ffffda0: 00000000 00000000 00000000 00000000
3ffffdb0: 00000000 00000000 00000000 00000000
3ffffdc0: 00000000 00000000 00000000 00000000
3ffffdd0: 00000000 00000000 00000000 00000000
3ffffde0: 00000000 00000000 00000000 00000000
3ffffdf0: 00000000 00000000 00000000 00000000
3ffffe00: 00000000 00000000 00000000 00000000
3ffffe10: 00000000 00000000 00000000 00000000
3ffffe20: 00000000 00000000 00000000 00000000
3ffffe30: 00000000 00000000 3ffe0000 40212768
3ffffe40: 00000000 3ffe901c 3ffeeff0 402080cb
3ffffe50: 3fff0f84 feefeffe 402045cc 40212848
3ffffe60: 40207694 00000000 3ffeeff0 00000000
3ffffe70: 40206f9c 00000000 3ffeeff0 feefeffe
3ffffe80: feefeffe feefeffe feefeffe feefeffe
3ffffe90: 3fff0054 3fff0054 0000000f feefeffe
3ffffea0: feefeffe feefeffe feefeffe 3ffef324
3ffffeb0: 3ffeeff0 00000000 3ffeeff0 402033ba
3ffffec0: feefeffe feefeffe feefeffe feefeffe
3ffffed0: feefeffe feefeffe feefeffe feefeffe
3ffffee0: feefeffe feefeffe feefeffe feefeffe
3ffffef0: feefeffe feefeffe feefeffe feefeffe
3fffff00: feefeffe feefeffe feefeffe feefeffe
3fffff10: feefeffe feefeffe feefeffe feefeffe
3fffff20: feefeffe feefeffe feefeffe feefeffe
3fffff30: feefeffe feefeffe feefeffe feefeffe
3fffff40: feefeffe feefeffe feefeffe feefeffe
3fffff50: feefeffe feefeffe feefeffe feefeffe
3fffff60: feefeffe feefeffe feefeffe feefeffe
3fffff70: feefeffe feefeffe feefeffe feefeffe
3fffff80: feefeffe feefeffe feefeffe 3ffef324
3fffff90: 3fffdad0 00000000 3ffeeff0 4020458b
3fffffa0: feefeffe feefeffe 3ffef310 4021038c
3fffffb0: feefeffe feefeffe 3ffe85d8 40100e65
<<<stack<<<
Lukas P. schrieb: > es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist > die 0.2.4 Würde ich gerne auch testen, habe aber nur einen HM-400. Da ich heute eh im Thema stecke, hier die Tabelle aller bisher bekannten Werte um den 400er ggf. leicht zu ergänzen:
1 | //-------------------------------------
|
2 | // HM400 (vermutlich auch HM-350 und HM-300)
|
3 | //-------------------------------------
|
4 | const byteAssign_t hm400assignment[] = { |
5 | { FLD_UDC, UNIT_V, CH1, CMD01, 14, 2, 10 }, |
6 | { FLD_IDC, UNIT_A, CH1, CMD01, 16, 2, 100 }, |
7 | { FLD_PDC, UNIT_W, CH1, CMD01, 18, 2, 10 }, |
8 | { FLD_YT, UNIT_KWH,CH2, CMD01, 20, 4, 1000 }, |
9 | { FLD_YD, UNIT_KWH,CH2, CMD01, 24, 2, 1000 }, |
10 | { FLD_UAC, UNIT_V, CH0, CMD01, 26, 2, 10 }, |
11 | { FLD_F, UNIT_HZ, CH0, CMD82, 12, 2, 100 }, |
12 | { FLD_PAC, UNIT_W, CH0, CMD82, 14, 2, 10 }, |
13 | { FLD_IAC, UNIT_A, CH0, CMD82, 18, 2, 100 }, |
14 | { FLD_T, UNIT_C, CH0, CMD82, 22, 2, 10 } |
15 | };
|
Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf Deine komme. Beispielnachricht:
1 | 95 7310xxyy 7310xxyy 010001 0198 004001060000FA7B00190922F8C75E 1 |
Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0 anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC Spannung des 1. Moduls. Ggf. muss das noch angepasst werden.
Angehängte Dateien:
-
MI1500data.png
140 KB
Lukas P. schrieb: > Hallo zusammen, > > es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist > die 0.2.4 Danke für die Arbeit! Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird? (WR Library?) Wollte drauf hinweisen, dass das MI-Series Datenformat völlig verschieden ist (CMD,MID,Ports etc.) Bisherige Erkentnisse vom MI1500, siehe Anhang
Marcus schrieb: > Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du > aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf > Deine komme. > Beispielnachricht:95 7310xxyy 7310xxyy 010001 0198 > 004001060000FA7B00190922F8C75E 1 > Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0 > anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC > Spannung des 1. Moduls. Ggf. muss das noch angepasst werden. Deine Definition habe ich mal eingebaut und commited. Dabei habe ich noch geringfügige Änderungen gemacht. Aufgefallen ist mir, dass für den HM1200 alle Idizes ungerade sind, deine sind alle gerade. Meine Zählweise ist so: Byte 0 = cmd Byte 1 .. x Daten Ich wollte das durch diesen Kommentar (über den Definitionen) ausdrücken, evtl. muss man es umformulieren.
1 | /** |
2 | * indices are built for the buffer starting with cmd-id in first byte |
3 | * (complete payload in buffer) |
4 | * */ |
Die Kanäle habe ich wie folgt aufgebaut: CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten CH1-CH4: je nach Wechselrichter die Anschlüsse für Module
Heinz R. schrieb: > Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur > den unten gezeigten Output Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären.
Ziyat T. schrieb: > Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR > als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird? > (WR Library?) Klar wir sind für alles offen, wir versuchen jetzt mal das schon bekannte in einer Firmware zusammenzufassen. Wenn du Input / Ideen hast kannst du sie gerne jederzeit beitragen. Ich würde sagen: Je mehr und je vollständiger die WR unterstützt werden umso besser!
Lukas P. schrieb: > Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der > Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären. funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 flashst?
Lukas P. schrieb: Zur Zählweise - hier erkennst Du es denk ich ganz deutlich (ich warte noch auf einen PR in das offizielle Repo-Doku): [[https://github.com/dad401/ahoy/blob/main/doc/HM-400%20data.xlsx]] > Die Kanäle habe ich wie folgt aufgebaut: > CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten > CH1-CH4: je nach Wechselrichter die Anschlüsse für Module Ja, ich habe es mir inzwischen so gedacht - hatte mir vorher Channels = cmd01 etc. bzw. Radio-Channels vorgestellt. Demnach hat der HM-400 CH0 (AC, Freq, Spannung, Temp) und CH1 den Rest vom Panel. Habe den 400er auch in Deinen Code eingebaut/-bastelt, kann nur wegen Dunkelheit nicht mehr testen. Kommt morgen... Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch das CMD82 (hminverters.h)?
1 | enum {CMD01 = 0x01, CMD02, CMD03, CMD83 = 0x83, CMD84}; |
Der Code ist eine gute Grundlage für Tasmota - bin da zwar eher Amateur, aber man lernt daran und einen adaptierten SDM230-Treiber (Wechselstromzähler) wurde auch als PR schon angenommen :-) - Bin gespannt ob das klappt. Einzig die Ressourcen sind da arg knapp und die Anzahl der WR sollte man da auch beschränken. Aber Web und MQTT kommt von Haus aus mit.
Hallo Lukas, Ich kann auch bestätigen das die neue Firmware nicht auf dem Wemos D1 Mini läuft. Weder das bin file (mit Tadtomizer und mit ESP-Easy flasher getestet) sowie auch die Version von Github mit Arduino IDE neu Kompiliert und geflasht. Bei beiden Varianten das gleiche Ergebnis wie Heiz bereits geschrieben hat.
Angehängte Dateien:
Ziyat T. schrieb: > > Bisherige Erkentnisse vom MI1500, siehe Anhang Ich bin der Meinung, das die Werte in der letzten Spalte das Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt (Nur in der Webansicht).
Sehr schade, worin liegt der Unterschied zwischen meinem ESP-07 und dem Wemos D1mini? Ich glaube der ESP-07 hat 1MB Flash. Ich habe bisher keinen Wemos. Marcus schrieb: > Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch > das CMD82 (hminverters.h)? wird nachgereicht, du hast Recht
Hallo Lukas, ich habe mal Deinen dev branch ausgecheckt und übersetzt. Dabei habe ich folgende Änderungen für Linux hinzugefügt: tools/fileConv.sh:
1 | #!/bin/bash
|
2 | echo String $3 = \"$(cat $1 | tr '\n' ' ' | sed 's/"/\\"/g;s/\s\{4\}/\t/g')\"\; > $2 |
html/conv.sh:
1 | #!/bin/bash
|
2 | ../tools/fileConv.sh index.html h/index_html.h index_html |
3 | ../tools/fileConv.sh setup.html h/setup_html.h setup_html |
4 | ../tools/fileConv.sh hoymiles.html h/hoymiles_html.h hoymiles_html |
5 | ../tools/fileConv.sh style.css h/style_css.h style_css |
platform.txt:
1 | # add a prebuild hook to generate minified h files from html templates |
2 | recipe.hooks.prebuild.1.pattern={build.path}/html/conv.sh
|
3 | recipe.hooks.prebuild.2.pattern={build.path}\html\conv.bat
|
Wobei die prebuild hooks in der platform.txt offenbar noch nicht
greifen. Vielleicht kennt sich ja jemand damit aus, wie man das HTML/CSS
minify der templates im html Verzeichnis richtig anstoßen kann.
Auch die folgende Speicheroptimierung habe ich noch nicht in den o.g.
Generator eingebaut.
> Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:1 | static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"
|
2 | String body = FPSTR(HTTP_BODY); |
3 | body.replace("{{variable}}", configuration.variable);
|
4 | page += body; |
Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das halt im Dev Branch =^D Dafür sind die ganzen versprochenen Anpassungen schon da ! * WiFi mit SSID und Password * Device Name: ESP-AHOY * bis zu vier Inverter 0-3 (wahlweise HM600 / HM1200) mit Adresse im 114173123456 Format plus ein sprechender Name für jeden * Abfrage Intervall der Wechselrichter: 1000 ms * Pin Out Definition CS: D8 (GPIO15), CE: D4 (GPIO2) und IRQ: D3 (GPIO0) im Default und wählbar. * MQTT Settings mit Broker / Server IP, Username & Password, Topic (/inverter) sowie Interval (10000 seconds) Besonders gefällt mir das flexible Mapping der Bytes in den Nachrichten auf die enstprechenden Felder (DC U/I/P und AC U/I/P/Freq, etc.) der Wechselrichter in der hmInverters.h. Ich muß mir das mal genauer ansehen, ich meine es gab auch Felder die u.a. auf zwei Nachrichten 0x01 Buffer Byte 15/16 und 0x02 Buffer Byte 1/2 aufgeteilt waren ? Das habe ich gestern bei meinen Versuchen eine hm600Decode.h zusammenzubasteln nicht gebacken bekommen. Die bei meinem Hoymiles immer wieder auftretenden 0x83 Nachrichten werden aktuell unter other summiert. Evtl. wäre es da hilfreich diese Nachrichten sowie die 0x82 bei anderen WR gesondert zu zählen ?
Hallo Lukas, Der D1 Mini hat 4mb fashspeicher… Die Vorgänger Version in dem nur der HM1200 unterstützt wurde lief ohne Probleme.
isnoAhoy schrieb: > Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das > halt im Dev Branch =^D Bin ich froh, dass es bei dir klappt. Jetzt wäre es noch toll wenn du den heutigen main Branch verwenden würdest. Damit die Wifi Settings nicht ständig weg sind, wenn man die Liste der zu speichernden Parameter erweitert, habe ich jetzt einen weiteren CRC eingeführt, der nur über die Wifi Settings geht. Dein conv.sh ist leider fast überflüssig, aber wir können es parallel ablegen. Ich habe heute auf python umgestellt, dadurch sind wir plattformunabhängig. Heinz R. schrieb: > leeren ESP8266 > flashst? Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle mich von OTA Update zu Update =) Das erinnert mit daran in der Konfiguraiton einen Erase Button einzuführen =)
:
Bearbeitet durch User
Mike schrieb: > Ziyat T. schrieb: >> >> Bisherige Erkentnisse vom MI1500, siehe Anhang > > Ich bin der Meinung, das die Werte in der letzten Spalte das > Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der > aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt > (Nur in der Webansicht). Leider nicht, z.Bsp. Zeile 3,Spalte 2, B7(port2) ist nicht belegt, PW=0, Spalte AX 1.18, geht nicht auf Zeile 2,Spalte 2, B8(port2) ist belegt, PW=75.4, Spalte AX 0.01 geht nicht auf
Lukas P. schrieb: > Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle > mich von OTA Update zu Update =) > Das erinnert mit daran in der Konfiguraiton einen Erase Button > einzuführen =) Es gibt z.B. bei ESPEasy Blank-Files - habe Dir mal eines angehängt
Jetzt fällt mir noch was ein in hmRadio.h:83 ist noch immer 'RF24_PA_MAX' definiert, bei mir funktioniert es, evtl. bricht beim ersten Sendeversuch die Spannung ein. Ich habe an den 3.3V einen dicken Elco, man sieht aber trotzdem, dass die LEDs kurz dunkler werden. @Heinz Dein blank.bin sieht aus wie ein frisch gelöschter Speicher, alles 0xFF =). Vielen Dank.
Mit ESP-12e: Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis zum Löschen des EEPROMs, dann schlägt der WDT zu. Gruß... Bert
Bert 0. schrieb: > Mit ESP-12e: > Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis > zum Löschen des EEPROMs, dann schlägt der WDT zu. > > Gruß... Bert Super, danke für den Hinweis, die Fehler sind dann eindeutig in der eep.h und zwar in Zeile 40 und 81 Die For loops werden mit einem 8-bit zähler niemals die 16bit length zählen können -> Endlosschleifen Commit ist gleich unterwegs ;-) Kann bitte einer nochmal kurz die Sonne einschalten zum Testen? :-P
:
Bearbeitet durch User
Jop, mit dem letzten Commit startet die Applikation wieder korrekt, Fix reviewed OK! ;-) Gruß... Bert
Ich kann btw. auch bestätigen, dass die Zuordnung auch für den HM-1500 sinn macht: https://github.com/grindylow/ahoy/blob/bf8c1628973eb1dc53b2604b6a7bc1561174f004/tools/esp8266/hmInverters.h#L100 Hab die Zuordnung mit einem meiner Dumps getestet... sieht alles plausibel aus
Die neue Version läuft auf dem Wemos D1! Besten Dank.
Mich@ schrieb: > Die neue Version läuft auf dem Wemos D1! > Besten Dank. Gibt es die evtl. auch als fertig kompiliertes bin?
Ja im Anhang ist die neuste Verison - hat jetzt eine Erase Application data Option - Cmds 0x82 und 0x83 tauchen in Statistik auf
Ich springe auch mal auf den Zug auf ;-) Erstmal ***VIELEN DANK*** an alle Beteiligten!!!! Ich bin noch an den Vorbereitungen, mein HM1200 ist noch nicht geliefert, und ich habe auch noch kein NRF, daher derzeit nur beschränkte Möglichkeiten. Die aktuelle 0.2.6 läuft aber schon mal auf einem Wemos D1 mini (clone) :-) - WIFI-Connection ist ok - Webseite funktioniert - MQTT ist inkl. user/pass eingetragen wird aber als "not connected" angezeigt. Im MQTT-Sniffer sehe ich aber das Topic und den FirmwareRelease. Sonst nichts, es gibt aber ja auch noch keine Daten. Meine Fragen: - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber in (s) Stimmt das? - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein Satzzeichen, ist das ok (erlaubt)? viele Grüße Robert
Hallo, ich bin leider kein C++ Programmierer und habe jetzt einen Status erreicht, wo ich nicht weiter kann. Ich wollte den Code auf ESP32 anpassen und hab auch viele Sachen angepasst, aber jetzt verlangt es langsam bessere C Knowledge. Ich würd mich freuen, wenn jemand da helfen kann ! Ich pack mal das error rein, welches ich bekomme wenn ich kompiliere. Ich nutze auch PlatformIo und habe da die Ordner Struktur angepasst. Zu finden sind die Änderungen in dem Fork in meinem Account: https://github.com/a-marcel/ahoy Ich würde mich freuen, wenn es auch für ESP32 geht, weil der ja mehr Speicher hat es einfacher sein sollte.
Hallo Marcel, finde ich super! Mal ein paar Dinge, die offensichtlich sind. Er findet die Datei "eep.cpp" nicht und er kommt nicht mit den 'Tickern' zurecht. Evtl. benötigt er eine Library / Include dafür. Evtl. tut man sich leichter, wenn man den Code erst mal für den ESP8266 in PlatformIO kompiliert. Robert S. schrieb: > Meine Fragen: > - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber > in (s) > Stimmt das? > - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein > Satzzeichen, > ist das ok (erlaubt)? - Inverval wird korrigiert, ist auch in ms - Das Passwort wird einfach als String (char-array) gespeichert, daher ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen begrenzt und der User auf 16 Zeichen. - der Status des MQTT Brokers war invertiert -> korrigiert
:
Bearbeitet durch User
Lukas P. schrieb: > - Inverval wird korrigiert, ist auch in ms > - Das Passwort wird einfach als String (char-array) gespeichert, daher > ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen > begrenzt und der User auf 16 Zeichen. > - der Status des MQTT Brokers war invertiert -> korrigiert Genial, funktioniert! Vielen Dank für den superschnellen Fix! Robert
Heinz R. schrieb: > funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 > flashst? Auch hier kommt der Watchdog (Wemos D1 mini). Auch ein
1 | esptool.py erase_flash |
hilft nicht.
Hallo Lukas P., danke für die vielen Commits und Fixes heute abend, nur das mit der Sonne hat nicht mehr gereicht =^D Ich schaue mir morgen bei Tag nochmal die HM-600 Werte an, da hast Du ja zuletzt noch etwas gefixt. Habe gerade nochmal die 0.2.7 geflashed, nach einem mutigen ERASE SETTINGS (not WiFi) kam auch folgender Fehler nicht mehr: 00:25:38.848 -> add inverter: oymiles A, SN: 114173123456, type: 0 00:25:38.848 -> no assignment for type found!add inverter: , SN: 480000000000, type: 3 Irgendwie hat er im EEProm wohl daneben gegriffen und das "H" des ersten WR Namens als SN für einen weiteren Wechselrichter interpretiert. Danke für die Funktion zum beibehalten der SSID und des WiFi Passworts das ist sehr praktisch und hilfreich! Auch die PA_MIN, PA_LOW, PA_HIGH, PA_MAX Einstellung funktioniert jetzt laut Debug Ausgabe: 00:29:55.769 -> add inverter: Hoymiles HM-600, SN: 114173123456, type: 0 00:29:55.802 -> RF24 Amp Pwr: RF24_PA_MAX Wie gesagt Device Name könnte noch mit ESP-<WIFIMAC> vorbelegt sein.
Hallo Heinz R., kannst Du mal zum Flashen den Serial Monitor der Arduino IDE schließen. Ich meine das ist eine häufige Fehlerquelle wenn er die Firmware übertragen will und dabei vorzeitig abbricht. Vielleicht hilft das ja auch in Deinem Fall.
Hallo Heinz R., jetzt habe ich mal den weiter oben genannten Stack Trace von Dir versucht zu analysieren. Schau Dir doch mal bitte folgende Seite an: https://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html Dort wird die Vorgehensweise bei solchen Exceptions Problemen beschrieben. Den ESP Exception Decoder habe ich nach der Anleitung ausgepackt und installiert https://github.com/me-no-dev/EspExceptionDecoder#installation Leider habe ich nicht den zugehörigen Source Code bzw. das ELF Binary um daraus Sinn zu machen bzw. Deinen alten Stack Trace zu analysieren. Mir fehlt auch der Exception Code um das Problem prinzipiell eingrenzen. Ich hatte übrigens gestern abend auch einen Stacktrace gesehen. Nach einigen Restarts geht es jetzt aber sauber, kann es also nicht einfach reproduzieren. Hast Du evtl. einige Clients die auf den ESP per WiFi zugreifen wollen oder wird viel per Serial geloggt ? I.d.R. treten solche WDT Exceptions auf, wenn der ESP seine WiFi Schnittstelle nicht parallel zum Programm bedienen/abarbeiten kann. Vielleicht kann man es ja an der richtigen Stelle mit einem yield() beheben ? Was für Einstellungen hast Du denn für Deinen ESP8266 im Tools Menü gewählt ? Eventuell liegt es ja an etwas einfachem wie der Frequenz, Debug Optionen, o.a.
Guten Morgen, ich weiß nicht, ob ich es schon genannt hatte: die Seriennumer muss jetzt genauso wie sie auf dem WR steht eingetragen werden, ohne ":". Im Anhang noch die Version 0.2.7 und im zip das .elf zum debuggen von Stack-Traces. Mit meinem HM1200 geht die Firmware bei Tageslicht =)
Guten Morgen Lukas P., also ich habe (nach wie vor) seltsame Werte für meinen zweiten Kanal am HM-600 (bisher unbelegt daher vermutlich free-floating): CHANNEL 1 230.40 V U_DC 2.27 A I_DC 804.10 W P_DC 50467.00 Wh YieldDay CHANNEL 2 1557.50 V U_DC 393.21 A I_DC 3932.10 W P_DC 10711.00 Wh YieldDay Die Yield Total und Week sowie AC Werte / Temperatur werden aktuell noch nicht angezeigt bzw. deren u.g. Werte erscheinen mir fraglich. Kann man die rohen Datenpakete wieder ausgeben lassen, das war m.W. dumpBuf o.a. ? Hier mal die Werte aus dem Serial Monitor: 08:42:04.674 -> hm600/ch1/U_DC: 230.400 V 08:42:04.674 -> hm600/ch1/I_DC: 2.300 A 08:42:04.674 -> hm600/ch1/P_DC: 190.600 W 08:42:04.674 -> hm600/ch2/U_DC: 1368.500 08:42:04.674 -> hm600/ch2/I_DC: 393.210 A 08:42:04.707 -> hm600/ch2/P_DC: 3932.100 08:42:04.707 -> hm600/ch0/YieldWeek: 1024.000 08:42:04.707 -> hm600/ch0/YieldTotal: 94.000 Wh 08:42:04.707 -> hm600/ch1/YieldDay: 32133.000 08:42:04.707 -> hm600/ch2/YieldDay: 10985.000 08:42:04.707 -> hm600/ch0/U_AC: 3932.100 08:42:04.707 -> hm600/ch0/Freq: 393.210 H 08:42:04.707 -> hm600/ch0/I_AC: 3932.100 08:42:04.707 -> hm600/ch0/Temp: 2218.900 Wenn dies eine CSV Ausgabe in einer Zeile wäre, dann könnte das der Serial Plotter in der Arduino IDE darstellen: 1U_DC1,1I_DC1,1P_DC1,1U_DC2,1I_DC2,1P_DC2,1YW,1YT,1YD1,1YD2,1U_AC,1Freq, 1I_AC,1Temp: 230.400,2.300,190.600,1368.500,393.210,3932.100,1024.000,94.000,32133.00 0,10985.000,3932.100,393.210,3932.100,2218.900 Am Besten könnte man noch die Spalten auswählen, die per Serial Monitor als "CSV" oder im bisherige "MQTT" Format ausgegeben werden =^D Die Channel Statistik in app.h/.cpp habe ich wieder aktiviert und er schickt bei mir alles auf Kanal 61. Hast Du das Channel Hopping adaptiv angepaßt, d.h. daß es erst bei Fehlern (ACK) den Kanal wechselt ?
Habe hin und wieder Exceptions gesehen, daher die 0.2.8 @isnoAhoy: das channel hopping ist aus (hmRadio.h), bringt bei mir keinen Vorteil Ich würde eher die RAW oder Payload Daten plotten lassen und das dann per Excel auswerten
Hallo Lukas P. habe die dumpBuf Aufrufe in hmRadio.h und app.cpp gefunden und wieder aktiviert. Das wäre als Debug Option im Setup sicher auch noch praktisch! Dazu musste ich die Methode in hmRadio.h vor den private: Bereich verschieben, da sie sonst nicht aus app.ccp aufgerufen werden konnte: declared private! Folgender einfacher Zusatz in dumpBuf() gibt übrigens auch HEX mit führender Null aus, dann klappt es m.E. leichter mit dem Excel Sheet zum dekodieren.
1 | if (buf[i] < 10) Serial.print("0");
|
An de NRF Spezialisten, Ich sehe diese RAWDaten vom MI1500 neben den "Regulaeren", was könnten sie sein? Kann immer noch den MI1500 nicht ansprechen, Daten bekomme ich nur, wenn die DTU-Pro eingeschaltet ist.
Hallo Ziyat
soviel ich noch von weiter oben weiß benutzt du meine SW.
Dass nur Daten kommen wenn DTU an ist bedeutet für mich, dass die DTU
wohl dem WR einen Anstoß gibt. Weiter oben habe ich auch beschrieben,
dass beim Senden des Zeit-setzen-Pakets mit einem Wert <> 0B hinter dem
0x80 ganz neue Antworten kommen. Also vllt braucht dein MI1500 kein 0B
sondern was anderes.
Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert
buf[10] von 00 bis FF durchlaufen lassen. etwa so:
static uint8_t cid = 0;
int32_t HM_Packets::GetTimePacket(uint8_t *buf, uint32_t wrAdr, uint32_t
dtuAdr) {
prepareBuffer(buf);
buf[0] = 0x15;
copyToBufferBE(&buf[1], wrAdr);
copyToBufferBE(&buf[5], dtuAdr);
buf[9] = 0x80;
buf[10] = cid++; // statt 0x0B
buf[11] = 0x00;
copyToBuffer(&buf[12], unixTimeStamp);
.....
Hast du auch schon die einzelnen Sendestärken durchprobiert?
Hi Lukas, heute ein erster Test mit dem HM-400 und der nun lauffähigen Version. Die Werte sind hier auch merkwürdig: [c]8:05:08.357 -> HM-400/ch1/I_DC: 105.600 A 18:05:08.357 -> HM-400/ch1/P_DC: 4785.400 18:05:08.390 -> HM-400/ch1/YieldTotal: 1056938.3 18:05:08.390 -> HM-400/ch1/YieldDay: 39.321 Wh 18:05:08.390 -> HM-400/ch0/U_AC: 3932.100 18:05:08.390 -> HM-400/ch0/Freq: 473.600 H 18:05:08.390 -> HM-400/ch0/P_AC: 158.300 W 18:05:08.390 -> HM-400/ch0/I_AC: 319.610 A 18:05:08.390 -> HM-400/ch0/Temp: 3932.100[c/] Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich schau mir das mal an... Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe ich da etwas? Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen HM-400 und HM-300 testen.
Hallo Lukas, Die neue Version läuft gut auf dem Wemos. Vielen Dank! Ist es möglich das in den MQTT Einstellungen der Port über das webinterface eingestellt werden kann?
Marcus schrieb: > Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich bin in C nicht so fit, aber wird hier wirklich der richtige Wert extrahiert? Als Beispiel ein CMD82 Paket: &p->packet[0] = 00DE957310xxyy7310xxyy82138600350000000203E8009E000AF1 In app.c übergibst Du das Paket ab Position 11:
1 | mSys->addValue(iv, i, &p->packet[11]); |
Damit beginnt es ab dem CMD 82: &p->packet[11] = 82138600350000000203E8009E000AF1 Nun zum addValue Aufruf, welcher hier auf die HM-400 Werte zurück greift:
1 | { FLD_F, UNIT_HZ, CH0, CMD82, 12, 2, 100 } |
2 | |
3 | void addValue(inverter_t *p, uint8_t pos, uint8_t buf[]) { |
4 | uint8_t ptr = p->assign[pos].start; // das müsste ja die 12 sein |
5 | uint8_t end = ptr + p->assign[pos].num; // 12 plus die Länge von 2 |
6 | uint16_t div = p->assign[pos].div; => der Divisorwert 100 |
7 | |
8 | uint32_t val = 0; |
9 | do { |
10 | val <<= 8; // val = val << 8 |
11 | val |= buf[ptr]; // val = val OR buf[12]; aber da buf[] ja die Adresse von packet[11] übergeben bekommt, entspricht dann buf[12] nicht &p->packet[11]+12 Bytes (uint8) weiter? |
12 | } while(++ptr != end); |
=> Value hat damit die Werte aus den Positionen packet[23] und packet[24] (2 Byte), es muss aber die Werte packet[14] und packet[15] haben (das dritte Byte nach dem CMD ist der Start). D.h. start beginnt bei 3 (packet[11] + 3), Länge ist mit 2 korrekt. Oder ich liege völlig falsch?!
Hallo Lukas, habe die neue Version zumindest mal geflasht bekommen und komme auf die Weboberfläche (Ich habe direkt das bin geflasht) Leider erhalte ich aber keine Daten vom WR (Das Setup lief so schon mal mit einer SW von weiter oben) Unten die Ausgabe des seriellen Schnittstelle Ich habe versucht die RF Power von Max niedriger zu stellen - es springt nach dem Speichern leider immer wieder auf Max? Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 erkannt werden? Kleiner Tip noch für zukünftige Versionen: Gib über die serielle Schnittstelle auch die IP-Adresse mit aus, spart langes suchen? Viele Grüße load 0x4010f000, len 3460, room 16 tail 4 chksum 0xcc load 0x3fff20b8, len 40, room 4 tail 4 chksum 0xc9 csum 0xc9 v00057520 ~ld wait for network . add inverter: , SN: 116474903203, type: 1 RF24 Amp Pwr: RF24_PA_MAX Radio Config: SPI Frequency = 10 Mhz Channel = 3 (~ 2403 MHz) RF Data Rate = 250 KBPS RF Power Amplifier = PA_MAX RF Low Noise Amplifier = Enabled CRC Length = Disabled Address Length = 5 bytes Static Payload Length = 32 bytes Auto Retry Delay = 250 microseconds Auto Retry Attempts = 0 maximum Packets lost on current channel = 0 Retry attempts made for last transmission = 15 Multicast = Disabled Custom ACK Payload = Disabled Dynamic Payloads = Disabled Auto Acknowledgment = Disabled Primary Mode = RX TX address = 0xdeadbeef01 pipe 0 (closed) bound = 0xdeadbeef01 pipe 1 ( open ) bound = 0x1234567801 pipe 2 (closed) bound = 0xc3 pipe 3 (closed) bound = 0xc4 pipe 4 (closed) bound = 0xc5 pipe 5 (closed) bound = 0xc6
Marcus schrieb: > Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe > ich da etwas? > > Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus > der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung > ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob > die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen > HM-400 und HM-300 testen. Ja Channel 0 wird noch nicht visualisiert, man kann aber durch ein define auch hier einfach die Liste der Werte ausgeben lassen. Das mit der SN habe ich mit anfangs auch gedacht, aber ich finde das noch nicht endgültig geklärt - jetzt ist es implementiert und würde ich vorerst so lassen. Sind nur 8Bit + alles drin rum ;-) Mich@ schrieb: > Ist es möglich das in den MQTT Einstellungen der Port über das > webinterface eingestellt werden kann? ja das ist möglich, werde ich demnächst einbauen. Heinz R. schrieb: > Ich habe versucht die RF Power von Max niedriger zu stellen - es springt > nach dem Speichern leider immer wieder auf Max? ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert. > Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 > erkannt werden? Habe zufällig so eine Funktion in der Beschreibung der RF24 lib gesehen. Kann ich mal testweise einbauen. > Kleiner Tip noch für zukünftige Versionen: Gib über die serielle > Schnittstelle auch die IP-Adresse mit aus, spart langes suchen? Ja die Rufe werden lauter - wird eingebaut
:
Bearbeitet durch User
Lukas P. schrieb: >> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt >> nach dem Speichern leider immer wieder auf Max? > > ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger > alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden > kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert. Hallo Lukas, auch nach einem Reboot oder gar Reset steht RF Power wieder auf High? Ich versuche gerade den Fehler einzugrenzen - evtl. doch Kommunikationsprobleme mit dem NRF24L?
Das kann dann nur an der Speicherroutine liegen. Ich prüfe es bei mir nochmal. Das hat mir dem externen Bauteil nichts zu tun.
Hallo, ich probiere noch immer den Code auf ESP32 zum laufen zu bekommen. Ich würde da Hilfe von einem, der besser CPP coden kann, gebrauchen. Mehrere Ticker in der Form von:
1 | mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this)); |
compilieren mit folgendem Fehler:
1 | src/app.cpp:97:75: error: no matching function for call to 'Ticker::attach_ms(uint16_t&, std::_Bind_helper<false, void (app::*)(), app*>::type)' |
2 | mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this)); |
Auf Stackoverflow habe ich genau diesen Fehler gefunden, wo auch eine Lösung präsentiert wurde. Leider kann ich diese nicht auf den o.g. Code anwenden. https://stackoverflow.com/questions/60985496/arduino-esp8266-esp32-ticker-callback-class-member-function Vielleicht hat ja ein CPP Pro hier eine Antwort für mich. Vielen Dank Marcel
Mal wieder ein paar (Wenigstens für mich) neue Erkenntnisse von meinem HM600, die aber das vermutlich auch das Protokoll im allgemeinen betreffen müssten, und ich glaube, das habe ich hier so noch nicht gelesen. Ich habe versucht, die Zuverlässigkeit des Empfangs der Nachrichtenpakete zu verbessern. Einen letztlich guten Hinweis dazu habe ich in dem DTU log aus Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" gefunden. Ganz allgemein, je nach Anfrage sendet der Inverter verschiedene Nachrichten als Antwort. Meine 'Standard' Anfrage basiert auf der GetTimePacket Nachricht, die auch in dem DTU log enthalten ist. Darauf hin kommen die Antworten 0x01, 0x02, und 0x83 zurück. Für die Antworten spielt es offensichtlich keine Rolle, ob das Byte 19 0 oder 5 ist (die Anfragen der DTU logs haben 0, daher habe ich das mal versucht - wie gesagt ohne wirklichen Unterschied). Beim Anschauen der DTU logs habe ich auch eine Anfrage gesehen, die im Byte 10 statt 0x0B eine 0x11 hat. Wenn ich das an den HM600 sende, bekomme ich (nach anpassen des Rx channel scans) zuverlässig die Antworten 0x01, 0x02, ... 0x0B, 0x8C. Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* Nachrichten das letzte Antwortpaket markieren. Das diese oft nicht so oft empfangen werden könnte Dara liegen, dass alle Nachrichten auf einem Kanal erwartet werden. Das ist aber nicht der Fall - dazu später mehr. Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das Anfordern eines nicht erhaltenen Pakets. Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. Das habe ich heute so erfolgreich getestet:
1 | 19:12:16.870 -> sending data request... |
2 | 19:12:16.973 -> [75] 024A2F0000505F00B400BE08C8138500C76618A1 |
3 | 19:12:16.973 -> AC_Power: 19.9W, AC_Voltage: 224.8V, Frequency: 49.97Hz |
4 | 19:12:16.973 -> Day_Production: 370Wh (180 + 190) |
5 | 19:12:16.973 -> Total_Production: 39.6kWh (18991 + 20575) |
6 | 19:12:17.007 -> [75] 830000000903E800840B5E8BB6188E89 |
7 | 19:12:17.007 -> Level(?): 0 |
8 | 19:12:17.007 -> Status: 1000 |
9 | 19:12:17.007 -> AC_Current: 0.09A |
10 | 19:12:17.007 -> Temperature: 13.2°C |
11 | 19:12:17.308 -> |
12 | 19:12:17.308 -> sending re-transmit request 01... |
13 | 19:12:17.375 -> [75] 010001014B001F006701480020006A0000A46F02 |
14 | 19:12:17.375 -> PV1-V: 33.1V, PV1-C: 0.31A, PV1-P: 10.3W |
15 | 19:12:17.375 -> PV2-V: 32.8V, PV2-C: 0.32A, PV2-P: 10.6W |
Wie man sehen kann, fehlt die erste Antwort. Diese frage ich dann noch einmal dediziert an, und habe dann alle Pakete (Anfrage ist immer auf Kanal 40, hier alle Antworten auf Kanal 75). Das erklärt dann eventuell auch, warum AutoAck nicht verwendet wird; has hat mich bei der Suche nach einem Schema für den Kanalwechsel immer wieder etwas verwirrt. Ich dachte eigentlich, dass das Fehlen von Nachrichten an meinem 'simplen' Kanal-Scannen liegt, aber in DTU log kann man diese erneute Anfrage ebenfalls schön sehen. Könnte also ein Hinweis darauf sein, dass es keine feste Synchronisation der Kanalwechsel gibt, und daher Paketverluste 'eingeplant' sind. Durch die 'vielen' Antworten auf die '11er' Anfrage habe ich dann auch gesehen, dass ich meine channel List anpassen musste. Mit
1 | rx_channels[] = {3, 23, 40, 61, 75, 83}; |
und dem Re-transmit request bekomme ich bei mir jetzt ganz gut alle 15 Sekunden ein komplettes Datenpaket zusammen. Meine Logik ist noch nicht ganz ausgereift, so dass ich im Moment nur ein fehlendes Paket neu anfordere, aber es gibt auch mal keine Antwort, oder nur eine. Heute ist die Sonne wieder zu früh untergegangen, aber es sieht so aus, dass die Kanäle in einem festen Schema von oben nach unten gewechselt werden (da ich nicht weiß, was in den Nachrichten ist, habe ich die mal abgekürzt):
1 | 19:13:32.105 -> sending data request... |
2 | 19:13:32.139 -> [03] 010... |
3 | 19:13:32.174 -> [75] 020... |
4 | 19:13:32.242 -> [75] 030... |
5 | 19:13:32.312 -> [61] 040... |
6 | 19:13:32.346 -> [61] 050... |
7 | 19:13:32.379 -> [61] 060... |
8 | 19:13:32.446 -> [40] 070... |
9 | 19:13:32.482 -> [40] 080... |
10 | 19:13:32.550 -> [40] 090... |
11 | 19:13:32.586 -> [23] 0A0... |
12 | 19:13:32.656 -> [23] 0B0... |
13 | 19:13:32.694 -> [03] 8C0... |
Wie man an den unterschiedlichen Abständen sehen kann, fehlt noch eine 'korrekte' Synchronisation (im Moment mache ich das Timing basierend auf meinem Senden), aber es ist erstaunlich, wie gut das im Vergleich zu vorher zu funktionieren scheint.
Version 0.2.9 ist da! Changelog: - added: IP Adresse wird auf Serieller Console ausgegeben, wenn erfolgreich mit WLAN verbunden - fix: RF24 Konfiguration des Power Amplifiers - added: RF24 Verbindung wird geprüft; prüft nur, ob SPI erreichbar, wenn kein Power an RF24 Modul ist, bleibt der ganze ESP hängen (ohne Serielle Ausgabe) - added: MQTT port Konfiguration - fix: offsets für HM400 und HM600 Wechselrichter, diese sollten jetzt korrekte Werte anzeigen. Bitte um Feedback - added: Warnung, wenn die Konfiguration geändert wurde, ohne neu zu booten auf der index.html Viel Spaß damit =)
lpb schrieb: > Ich habe versucht, die Zuverlässigkeit des Empfangs der > Nachrichtenpakete zu verbessern. Hallo lpb, genial, dass du weiter auf diesem Gebiet forschst! Ich finde das super, dass sich so die Kompetenzen der einzelnen ergänzen. Wenn man statisch auf Kanal 40 das 'Zeit-setzen' schickt und nur auf Kanal 3 horcht, bekommt man sehr unzuverlässig Pakete rein. Verstehe ich das richtig, man sendet in Byte 10 eine 0x11 statt 0x0b und bekommmt dadurch viele neue Cmds in den Antworten. das erinnert bisschen an das was @Hubi schon mal kurz angesprochen hatte: Hubi (Gast) schrieb: > Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal gelesen zu haben. Auf eine Anfrage hin kommen dann viele Antworten und zuletzt ein 0x83? Wie bekommt man die Zuordnung von Kanal und CMD in der Antwort? Ich muss ja dann vorher wissen wo die nächste Antwort kommt. Bin gespannt wie es hier weitergeht.
:
Bearbeitet durch User
Die Werte für den HM-400 stimmen nun:
1 | 10:17:40.209 -> HM-400/ch1/U_DC: 41.200 V |
2 | 10:17:40.209 -> HM-400/ch1/I_DC: 5.570 A |
3 | 10:17:40.209 -> HM-400/ch1/P_DC: 229.400 W |
4 | 10:17:40.209 -> HM-400/ch1/YieldTotal: 67.629 kW |
5 | 10:17:40.209 -> HM-400/ch1/YieldDay: 0.315 Wh |
6 | 10:17:40.209 -> HM-400/ch0/U_AC: 235.400 V |
7 | 10:17:40.209 -> HM-400/ch0/Freq: 50.040 Hz |
8 | 10:17:40.242 -> HM-400/ch0/P_AC: 218.200 W |
9 | 10:17:40.242 -> HM-400/ch0/I_AC: 0.930 A |
10 | 10:17:40.242 -> HM-400/ch0/Temp: 28.800 ° |
Ein paar Kleinigkeiten waren zu korrigieren (siehe app.cpp und hmInverters.h in https://github.com/dad401/ahoy/tree/main/tools/esp8266) - das h von kWh und das C von °C wird abgeschnitten => meine Änderungen scheinen da aber doch nicht zu helfen, bitte mal prüfen - YieldDay korrigiert - es wird nun wie bei HM-600 Wattstunden angezeigt (möchte nicht ständig im Thread das übermitteln - ich kann aber leider auch keinen zweiten Fork auf Lukas-Fork erstellen, daher PR auf das Haupt-Repo) P.S. ggü. Hubis NRF24 Receiver empfängt die aktuelle Version aber irgendwie schlechter. Es dauert mehrere Minuten bis etwas ankommt - früher kamen Pakete sofort nach dem Start?!
Hallo Marcus, den PR hast du garnicht durchgeführt oder? Lt. dieser Anleitung solltest du den auch meinem Repo zuweisen können: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork Yield total sollte doch in kWh sein oder, daher war der Teiler 1000. In Wh ist es sehr bald eine unnötig große Zahl. Bzgl. der Empfang: versuche mal in hmRadio.h den Channel-Hop (define) wieder zu aktivieren, evlt. geht es dann wieder besser.
Habe noch keinen PR gemacht, weil die Änderungen in der app.cpp nicht funktionieren. Ich teste das mal, ob ich Dein Repo hier verbinden kann - bin da zu unerfahren mit GIT da ich nur gelegentlich damit zu habe. Yield total stimmt. Aber das h wird hinten bei der Ausgabe abgeschnitten. Yield daily wird derzeit beim 400er in kWh ausgegeben, aber als Einheit ist Wh angezeigt - das habe ich korrigiert. Wenn Du aber eh 3 Nachkommastellen ausgibst, könnte man YD auch generell auf kWh setzen. Ist aber alles Geschmackssache - Hauptsache einheitlich :-) Ich probiere das mal mit dem Channelhopping. War das früher aktiv? Mit der ersten Version nach Behebung des Watchdog-Crashes ging es m.E. sehr gut. Jetzt dauert es 10min bis erste Pakete empfangen werden.
Bei mir liegt es stark an der Ausrichtung der Antenne, sie muss bei mir mit der abstrahlenden Seite Richtung WR zeigen. Das ist bei mir noch sehr empfindlich, daher finde ich es super, dass sich hier auch welche um besseren Empfang kümmern.
Angehängte Dateien:
-
hm_600_comm.png
110 KB
lpb schrieb: > Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* > Nachrichten das letzte Antwortpaket markieren Hallo lpb, diese Vermutung hatte ich auch schon, nachdem ich meine Messungen an der seriellen Schnittstelle hier gepostet hatte (siehe auch Bild): Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Aber die Erkenntnis mit dem Retransmit eines speziellen Pakets ist natürlich sehr nützlich. Ich hatte hier im Thread schon mal darauf hingewiesen, dass es einen Unterschied in der Antwort des Wechselrichters macht, welche Anfrage vorausging. Das dürfte vielleicht die ein oder anderen "seltsamen" Werte bei manchen hier erklären. Die 0x80 0x11 Anfrage liefert andere Antwortpakete als die 0x80 0x0B Anfrage, obwohl sie den gleichen Index haben (siehe Bild). Leider habe ich auch keine Ahnung, wie man das empfangene Paket plausibilisieren könnte. Evtl. lohnt es sich, das Channel Hopping systematischer zu untersuchen, um die komplette Antwortsequenz in einer gewissen Zeit zu erhalten. Bald sind meine Module auf dem Dach montiert, dann kann ich auch wieder hier mitmischen...
martin schrieb: > Evtl. lohnt es sich, das Channel Hopping > systematischer zu untersuchen, um die komplette Antwortsequenz in einer > gewissen Zeit zu erhalten. Vielleicht ist die Messung von B.G. ja schon ein entscheidender Hinweis: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Es scheint eine Systematik in den Kanalwechseln zu geben, nämlich "von oben nach unten": Kommt Paket 1 auf Kanal 40, dann wird auf 23 weitergehorcht. Kommt dort 02,83 ist es Antwort auf 0x80 0x0B, kommt 02,03,04 wird auf Kanal 3 weitergehorcht, bis 85 kommt. Dann ist es die Antwort auf 0x80 0x11 (?)
Hubi schrieb: > Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert > buf[10] von 00 bis FF durchlaufen lassen. etwa so: Hallo Hubi Danke für den Vorschlag, hatte auch mal so durchlaufen lassen wie du vorgeschlagen hast, ohne Erfolg. Bisher habe ich alle Kombinationen MID/CMD/CID durchprobiert. Ich denke die MI-Series braucht was ganz anderes, denn die Antworten sind auch ganz anders, bei den MI-Antworten gibts keine regelmaessige SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. Ich muss die DTU-Pro sniffen aber, vorerst bin ich mit meinen Möglichkeiten am Ende. Ehrlich gesagt ich kann es auch fast nicht glauben, dass die Chinesen für die HM'S vollig etwas anderes erfunden haben.. Andere Signalstaerken hab nicht probiert, es steht auf PA_MAX, hab einen NRF mit Antenne und WR ist etwa 7m weit, ich denke, was ich sende kommt an.
:
Bearbeitet durch User
Ziyat T. schrieb: > SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. Achtung, das waren die seriellen Daten INNERHALB der DTU! 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den Adressen.
martin schrieb: > Ziyat T. schrieb: >> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. > > Achtung, das waren die seriellen Daten INNERHALB der DTU! > 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht > zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den > Adressen. Sorry, richtig!
Ich habe Hubis Code ebenfalls mal eingecheckt. Hoffe es verwirrt nicht, denn es gibt noch einen weiteren Code unter "Nano" - der ist m.E. aber etwas anderes?!
Hallo Leute, Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein stärkeres Netzteil habe ich bereits getestet… Ansonsten läuft die neue Version gut. Die Daten meines HM350 sehen plausibel aus. Auch die Abfrage per MQTT läuft.
Ich habe gleiches beobachtet, habe einfach den USB Stecker vom Laptop in ein USB-Netzteil gesteckt und auch Abstürze gesehen, auch ca. 15-20 Minuten geschätzt. Noch habe ich keine Idee woran es liegen könnte. MQTT war bei mir auch an. Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.
Hallo, sagt mal, gibt es irgendeine Möglichkeit die Core Funktionen in eine Library auszugliedern? Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder andere NTP/WiFi implementierungen. Das wäre wirklich von Vorteil ggf. für mehrere Personen. Vielen Dank für all eure Arbeit Marcel
Hallo Marcel, das ist doch im Prinzip jetzt schon so. Ich habe alles so angelegt, damit es möglichst unabhängig vom ESP8266 ist. Im wesentlichen sind hierfür die Dateien 'hmSystem.h', 'hmRadio.h', 'hmInverters.h' und 'CircularBuffer.h' notwendig. Evtl. ist noch das eine oder andere #define aus 'defines.h' nötig. Die 'Library' wird dann ungefähr so aufgerufen (kopiert aus app.h):
1 | typedef CircularBuffer<packet_t, PACKET_BUFFER_SIZE> BufferType; |
2 | typedef HmRadio<RF24_CE_PIN, RF24_CS_PIN, RF24_IRQ_PIN, BufferType> RadioType; |
3 | typedef HmSystem<RadioType, BufferType, MAX_NUM_INVERTERS, float> HmSystemType; |
4 | |
5 | HmSystemType sys; |
aus deiner .ino setup() musst du noch diese Routine aufrufen
1 | sys.setup(); |
jetzt kannst du mit dem Objekt sys alles anstellen, z.B. einen Inverter hinzufügen:
1 | sys.addInverter("HM_XY", 116100000000, 0); |
danach muss man sich noch überlegen, was man alles in der loop() machen will, hierfür einfach in der app.cpp schauen.
:
Bearbeitet durch User
Okay super. Schaue ich mir mal an. Danke. Marcel
Mich@ schrieb: > Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der > Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles > perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er > nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht > mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein > stärkeres Netzteil habe ich bereits getestet… Ich habe hier einen Wemos D1 clone mit der 2.9er im Testbetrieb an einer Powerbank. Er läuft jetzt seit mehr als 3h 30min, das Webinterface ist erreichbar, die Zeit und Uptime zählen hoch. Unterschied, er läuft ohne NRF-Board (wird erst geliefert) und bekommt daher auch keine Daten. Vielleicht hilft das ja bei der Fehlersuche. SG Robert
Hallo Marcel, schau Dir doch mal die folgenden beiden ebenfalls passenden SE&SO Artikel an: [1] https://arduino.stackexchange.com/questions/76138/error-in-defining-ticker-in-esp32-library [2] https://stackoverflow.com/questions/53091205/how-to-use-non-static-member-functions-as-callback-in-c Ich habe versucht an der Stelle etwas Neues zu lernen, offenbar muß ich dazu auch noch Einiges mehr [TM] verstehen... Das Beispiel im ersten u.a. Link fand ich dazu für mich etwas klarer, da es eine ESP8266 Vorlage und ein ESP32 Ergebnis gibt. Die beiden Funktionen sendTicker und mqttTicker muss man m.E. in der app.h als public deklarieren.
1 | static void appSendTicker_helper(app* appl) {
|
2 | //needs to be public! |
3 | appl->sendTicker(); |
4 | } |
5 | |
6 | static void appMqttTicker_helper(app* appl) {
|
7 | //needs to be public! |
8 | appl->mqttTicker(); |
9 | } |
10 | |
11 | ... |
12 | mSendTicker->attach_ms(interval, &appSendTicker_helper, this); |
13 | ... |
14 | mMqttTicker->attach_ms(interval, &appMqttTicker_helper, this); |
Analog dazu sollte es auch in der main.cpp/.h möglich sein Interessant fand ich, daß der Umbau für den ESP32 dann auch unter ESP8266 funktionieren soll. Es sind also offenbar keine extra #if defined (ARDUINO_ARCH_ESP8266) #elif defined(ESP32) Blöcke für die Ticker notwendig. Für die Bibliotheken die unter ESP8266 i.d.R. auch dies als Präfix haben und die ESP32 Varianten ohne dieses Präfix hast Du m.W. ja schon die entsprechenden konditionalen include's eingepflegt.
Guten Morgen ! Ist schon jemand dahinter gekommen, was für eine Bedeutung die "81" er Telegramme vom HM350 / HM400 haben ? 005E ... 14 79 CF 005C ... 14 7F 25 0058 ... 14 72 F1 00 1234567801 005E 0B 3 95 [WR] [WR] 811479CF 1 00 1234567801 005C 0B 2 95 [WR] [WR] 81147F25 1 00 1234567801 0058 0B 0 95 [WR] [WR] 811472F1 1 00 1234567801 005E 0B 3 95 [WR] [WR] 811479CF 1 00 1234567801 005C 0B 2 95 [WR] [WR] 81147F25 1 00 1234567801 0058 0B 0 95 [WR] [WR] 811472F1 1
Angehängte Dateien:
-
ahoyb.jpg
33 KB
Hi Lukas und alle dies es interessiert,
erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr
gut lesbar.
Nach ersten Tests auf einem klassischen Arduino bin ich nun auf ein
ESP8266 Modul umgestiegen.
Man braucht für den Code wirklich aktuelle Tools zum compileren, da wohl
erst vor gar nicht langer Zeit die String-Conversion von uint64_t
eingebaut wurde. Bei schickte das die Umsetzung der Seriennummern in
eine Byte-Wurscht auf die Bretter... ;-)
Danach übersetzte das Ganze aber klaglos und lief auch auf Anhieb.
Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich
musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom
"Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC
Leistung. Also habe ich Zeile
{ FLD_IAC, UNIT_A, CH0, CMD02, 15, 2, 10 },
gegen
{ FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 },
getauscht. - Jetzt passt es.
Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
{ FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 },
=> Kann das bitte mal jemand mit einem HM600 checken, ob das beim HM600
auch so ist? - Sonst müsste man die HM600/700 Werte defines
separieren...
Die Visualisierung habe ich für mich noch auf die Schnelle um die
AC-Werte erweitert. - Siehe Screenshot. :-)
Ein Issue habe ich noch:
=> Ich habe ab und zu (gemittelt alle 10-20 Minuten) Stacktraces, also
Abstürze mit Exception 0. Meist im Zusammenhang mit der ISR für den
externen Interrupt und gleichzeitigem Bedienen des WLAN-TX.
=> Das Modul startet dann korrekt neu, bekommt aber keine IP-Adresse
zugewiesen (IP unset). Ein Reset behebt das aber (temporär).
Ich beobachte das weiter und prüfe heute noch, ob es ein HW-Thema
(Spannungseinbrüche o.ä.) ist oder eher nicht.
Cheers,
Lars
:
Bearbeitet durch User
Hallo zusammen Im Anhang meine neueste Version, da ich gesehen habe, dass doch einige diese ausprobieren. Kommentare dazu: - Projekt jetzt umgenannt in HoyDtuSim (Hoymiles DTU Simulation) -Läuft auf Arduino (bei mir auf Pro Mini) und ESP (Wemos D1 mini), je nachdem wie man kompiliert - Channel hopping für senden und Empfangen (poor man's ...) ist eingebaut und bringt konstante Antworten; obige Erkenntnisse über Kanäle abwärts sind noch nicht eingebaut - da manchmal ein Abbruch der RF-Verbindung vorkam (auch schon oben erwähnt) wird jetzt nach ca 50 Sekunden ohne Empfang das RF-Modul neu initialisiert und es geht problemlos weiter - Definitionen für HM-600 und HM-1200 sind implementiert, andere können anhand der beiden Beispiele sicher leicht impl. werden - Anpassungen sind in der Settings.h zu machen Marcus hat in das lumapu-Repo meine Version vom 13.04. eingecheckt. Wäre nett wenn er dies durch diese hier ersetzen würde. Wenn ich Zugang zu diesem Branch hätte und wenn ich wüßte wie das geht würde ich das auch selbst machen. Aber ich kann neue Versionen auch an Lukas P. (lumapu) per Mail schicken. @Herbert: Die 81er habe ich auch dauernd, besonders 8114. Fehlermeldung?
Beim compilieren mit der aktuelle IDE und aktuellen Bibliotheken kommt folgende Fehlermeldung: app.cpp:58:95: error: call of overloaded 'String(uint64_t&, int)' is ambiguous Liegt das an der fehlenden Seriennummer die ich noch nicht eingetragen habe, weil ich nicht weiß wo? Sorry für die Anfängerfragen. Danke
Hallo Sorbit für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das aber keinen Fehler werfen. Wenn du die Serial ausgeben willst, kannst du das so machen
1 | sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned long)(serial&0xFFFFFFFFULL)); |
Marcel A. schrieb: > Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch > auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder > andere NTP/WiFi implementierungen. Ich bastel gerade an einer Testversion für Tasmota - muss mir aber immer recht viel zusammensuchen, da ich nicht so tief drin stecke im Programmieren wie z.B. Lukas. Die Integration kompiliert inzwischen - einiges musste ich anpassen, konnte aber viele der Dateien von Lukas weiterverwenden. Ob es auch läuft konnte ich noch nicht testen. Kann das gerne in mein GIT einstellen ([[https://github.com/dad401/Tasmota]] Tasmota-Fork) - ist aber sicher noch nicht so toll der Code. Learning by Doing auch was GIT betrifft. @all: Wie plausibel haltet ihr die Werte für P_AC und Power total/daily => sind das die Werte, welcher ein Wechselstromzähler messen sollte oder könnte das ggf. doch (tlw.) Werte für DC sein? Wenn das passt, dann kann man damit auch z.B. einen SonOff besser kalibrieren. Dieser weicht derzeit nur wenige kWh von der Tagesproduktion ab.
Lukas P. schrieb: > Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann > können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen. Ich glaube Du musst da "Discussions" in den "Settings" anwählen - in Deinem GIT habe ich irgendwie (ohne PR) keine Möglichkeit gefunden zum Austausch.
Hubi schrieb: > Wäre > nett wenn er dies durch diese hier ersetzen würde. Ist bei mir drin und PR für das Hauptrepo angefordert. Mit einen GIT Account könntest Du das auch selbst. Ich kann Dir die Schritte, wenn Du den Account hast gerne sagen (so wie ich es mache/gelesen habe). Am besten aber dann hier [[Du bräuchtest einen git Account]] sonst sprengen wir die Server von mikrokontroller.net ;-)
Marcus schrieb: > Am besten aber dann hier [[Du bräuchtest einen git > Account]] [[https://github.com/dad401/ahoy/discussions]]
So, ich habe mir einen Git account zugelegt und meine SW dort mal reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation. Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, bitte gerne.
Hubi schrieb: > So, ich habe mir einen Git account zugelegt und meine SW dort mal > reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation. > Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt > geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, > bitte gerne. Das ist nun die Frage - belassen wir alles im Haupt-Repo [[https://github.com/grindylow/ahoy]] oder führt jeder Entwickler sein eigenes? Ich kann diese Frage nicht beantworten. Man könnte es ja so machen: Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). Aber das müsst ihr wissen. Mir wird nur etwas schwindlig wenn man immer alles zwischen den Forks synct ;) Für mich wäre es einfacher wenn ich als Nutzer Hubis-Repo und Lukas-Repo bei mir forken kann und dort Änderungen per PR einbringen kann. Derzeit ist das irgendwie über zwei Ecken. <just my 2 cents> Marcus
Hallo Marcus, wir sollten bei dem Hauptrepository bleiben, aber evtl. kannst du mich als 'Colloborator' hinzufügen, dann kann ich direkt die Pull-Request managen - denke ich (ich hab leider auch keine Github Erfahrung) Repository -> Settings -> Colloborators
Hallo Lukas Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann meine weitere Entwicklung per Mail zukommen lassen. Bin auch der Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und wird dann unübersichtlich. Bin da offen. Deine wirklich sehr gute OOP Entwicklung wäre schon wert unterstützt zu werden.
Hubi schrieb: > Hallo Sorbit > für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das > aber keinen Fehler werfen. > Wenn du die Serial ausgeben willst, kannst du das so machen1 > sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned > long)(serial&0xFFFFFFFFULL)); Hallo Ahoi, Hubi, oder wer auch immer dahinter steckt😄 Im Git Repository steht doch geschrieben, das der Code für Arduino mit ESP8266 als Taget gedacht ist. Dann sollte der Compiler doch sauber durchlaufen. Ich verstehe den Zusammenhang nicht. Kann mir jemand auf die Sprünge helfen? Danke
Ich lade gerne "Collaborators" in das AHOY Repository ein. Schreibt doch hier im Thread kurz Eure Github-Namen und Euren Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als Collaborators hinzu. Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich hier im Forum in der Minderheit!), aber ich stimme Marcus und den anderen zu, dass es insbesondere für Nutzer hilfreich ist, wenn die Entwicklung nicht an zu vielen unterschiedlichen Forks läuft. Gruß Martin (petersilie) / https://github.com/grindylow/ahoy ps. Habe gerade mal das Haupt-README mit direkten Verweisen auf die Unterprojekte aktualisiert. Für die Übersicht wäre es super, wenn jeder Autor für "sein" Tool ein kleines README hinzufügen könnte. Dann finden sich auch Fremde schnell zurecht. Als Beispiel/Vorlage kann z.B. https://github.com/grindylow/ahoy/tree/main/tools/rpi dienen.
:
Bearbeitet durch User
Hallo Martin,
> Mein Interesse ist immer noch eher auf der Raspi-Version
Schön! Ich halte zumindest davon auch noch am meisten, was das effektive
Entwickeln angeht, wenn auch der Ressourceneinsatz etwa bei einem ESP32
deutlichst kleiner ausfällt, wenn er dann einmal als Webserver läuft.
Übrigens habe ich heute meinen NRF24_Sniffer zugeschickt bekommen und
werde wohl in den nächsten Tagen das Dingens mal aktivieren. Wenn's dann
klappt, hoffe ich, was zum HM-1500 beitragen zu können. Wobei ich hoffe,
weitestgehend die Auslesung des HM-1200 übernehmen zu können. ;-)
Tschüssi,
Petra
Hallo Sorbit mit der Arduino IDE und Einstellung Lolin(Wemos) D1 R2 & mini lässt sich zB ein
1 | Serial.println(String(serialNr,HEX)) |
ohne Fehler kompilieren. Ich benutze die IDE 1.8.13, nicht die neueste.
Martin G. schrieb: > Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich > hier im Forum in der Minderheit!), welche Vorteile versprichst Du Dir davon? Denke man sollte es möglichst einfach halten - und möglichst einfach ist halt der ESP8266
Nachdem ich bisher nur stiller Mitleser war, hier mein erster Beitrag. Sehr cool, was ihr hier schon gemeinsam geschafft habt! :-) Heinz R. schrieb: > welche Vorteile versprichst Du Dir davon? > Denke man sollte es möglichst einfach halten - und möglichst einfach ist > halt der ESP8266 Der ESP ist sicherlich ein guter Start, universell und aus meiner Sicht eine schöne Plattform. Ich persönlich würde es auf Dauer aber auch bevorzugen, wenn das System auf einem bestehenden Raspberry untergebracht werden könnte und ich keine zusätzliche Hardware dafür laufen lassen muss. Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell ablesbar zu machen.
Heinz R. schrieb: > welche Vorteile versprichst Du Dir davon? > Denke man sollte es möglichst einfach halten - und möglichst einfach ist > halt der ESP8266 Der ESP8266/ESP32 ist sicher eine tolle Sache. Ich habe persönlich nicht primär das Nachbauen einer "DTU" im Kopf, sondern die Integration der Hoymiles-Wechselrichter in ein größeres Ökosystem. Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den Wechselrichtern einfach noch mitmachen lassen. Webinterface/Archivierung etc ist dann nicht Aufgabe der Hoymiles-Anbindung, sondern des übergeordneten Systems. Vielleicht ein bisschen wie die "DTU-Pro"-Anbindung via Modbus (wobei die DTU-Pro ja wohl auch ein Webinterface etc etc bietet). Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit NRF24 als auch mit Wifi auf 2.4 GHz. Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf. Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. Das sind alles absolut gute Wege, und jede Alternative trägt ein bisschen zum Erkenntnisgewinn bei. Ich finde es prima, wie wir alle unsere Erfahrungen mit dem Protokoll zusammensammeln!
> Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display > zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell > ablesbar zu machen. Jenau, man schaue z.B. unter https://tutorials-raspberrypi.de/esp8266-grafikdisplay-ssd1306-oled-bilder-text-anzeigen/ Wobei ich eher zum esp32 tendiere, weil der wohl bei minimalem Aufpreis etwas besser ausgestattet ist? Tschüssi, Petra
> Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier > eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit > NRF24 als auch mit Wifi auf 2.4 GHz. Scho'recht, allerdings ist die Frage, wie stark die Hoymiles-Abfragerei das WLAN belastet. Ich möchte auch mal hinterfragen, ob es einen Sinn macht, sekündlich Werte abzufragen? Ich denke, wenn man alle 30 s einen Wertesatz holt, wird sich die Statistik nur sehr unwesentlich verschlechtern. > Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" > experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf. Das auf jeden Fall - das ist auch bei mir der Antrieb, damit anzufangen, um ... > Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. ... später, wenn alles so weit ausexperimentiert ist und nur noch gelegentlich mal nach dem Zustand geschaut wird, so was als Standardanzeige zu etablieren. Zumindest fände ich es nett, hier eine Low-Power-Alternative zur Verfügung zu haben. ;-) Tschüssi, Petra
Lukas P. schrieb: > aber evtl. kannst du mich > als 'Colloborator' hinzufügen Das wäre dann aber petersilie - das Hauptrepo ist seins, hat er aber darunter bereits geschrieben: Martin G schrieb: > Ich lade gerne "Collaborators" in das AHOY Repository ein. > Schreibt doch hier im Thread kurz Eure Github-Namen und Euren > Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als > Collaborators hinzu. Mein GIT: [[https://github.com/dad401]] Fokus: Nutzertests mit HM-400 (und HM-300), ggf. Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren Programmierkenntnissen beteiligt. Martin G schrieb: > Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man > durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den > Wechselrichtern einfach noch mitmachen lassen. Ich finde es gut, dass es auch diese Alternative gibt, denn auch ich würde mir ggf. ein zusätzliches Gerät sparen. Ich habe inzw. alles kompiliert/konfiguriert, aber bekomme es noch nicht zum Laufen. Benötige ich da zwingend den MQTT-Server? Ich muss das nochmal genauer prüfen. Einzig nachteilig (IMHO) ist leider das "Gefummel" (kompilieren statt einfach per apt installieren) mit den Bibliotheken. Solang das alles fehlerfrei klappt ist gut, aber wer weiß was mit dem nächsten RPi-Update passiert. Petra R. schrieb: > Ich möchte auch mal hinterfragen, ob es einen Sinn > macht, sekündlich Werte abzufragen? Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools berücksichtigt werden. Ich denke dies ist immer noch des ersten funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer stabil kommen. Ggf. macht man das Abfrageinterval einstellbar. Meine RRD-Datenbank befülle ich (von einem SonOff Pow R2) jede Minute. Wenn also stabil bei einer Abfrage eine Antwort kommt, dann reichen sicher 30s Intervall aus.
Marcus schrieb: > Hubi schrieb: > Man könnte es ja so machen: > Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software > lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). > Diesen Weg sollten wir gehen, denn es gibt noch viele ungelöste Dinge! IMHO, es sollten unbedingt alle Infos Zentral sein. Ich habe das Gefühl, dass bisher "nur" ein Paar WR Daten (und diese nur von HM's!) sichtbar sind, und schon wird hier über HW-Plattform diskutiert;-)
:
Bearbeitet durch User
Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente. Hier eine weitere HM-300 Seriennummer: 11216281xxyy Also ich leg mich fest, die HM-3xx und HM-400er beginnen mit immer 1121 ;)
Vorweg: Super Arbeit - vielen Dank! Die ESP8266 Version funktioniert mit einem HM-800 (114174...) Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc erwähnten Installation der Library "PubSubClient"):
1 | { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, |
2 | { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 } |
In der kurzen Testphase kam es zu Hängern - ich vermute einen Zusammenhang mit geöffnetem Webinterface. lg
st_b schrieb: > Die ESP8266 Version funktioniert mit einem HM-800 (114174...) > Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc > erwähnten Installation der Library "PubSubClient"): Hallo st_b , auf welcher Definition basiert deine Änderung, auf der vom HM600? Doku werde ich nachziehen, danke für den Hinweis.
Hubi schrieb: > Hallo Lukas > Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie > bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann > meine weitere Entwicklung per Mail zukommen lassen. Bin auch der > Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und > wird dann unübersichtlich. Bin da offen. Hallo Hubi, das liegt bei dir, ich finde es nicht falsch wenn du einen Git Account hast und direkt Änderungen per pull request einfließen lässt. Per Mail geht auch, dann checke ich es ein. Deine wirklich sehr gute OOP > Entwicklung wäre schon wert unterstützt zu werden. Vielen Dank für die Blumen ;-)
Lars B. schrieb: > erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr > gut lesbar. Das ist mein Ziel: so wenig wie möglich kommentieren, lieber sprechen Code schreiben. Ist nicht immer ganz einfach, aber so bleibt das gesamte auch über Monate wartbar. > Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich > musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom > "Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC > Leistung. Also habe ich Zeile > { FLD_IAC, UNIT_A, CH0, CMD02, 15, 2, 10 }, > gegen > { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, > getauscht. - Jetzt passt es. > > Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden: > { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 }, Ich kann leider nicht nachvollziehen, ob diese Änderungen bereits per PR in das repo gekommen sind, falls nicht bitte noch anlegen. > Die Visualisierung habe ich für mich noch auf die Schnelle um die > AC-Werte erweitert. - Siehe Screenshot. :-) Auch hier freue ich mich über einen PR in Git.
Lukas P. schrieb: > st_b schrieb: >> Die ESP8266 Version funktioniert mit einem HM-800 (114174...) >> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc >> erwähnten Installation der Library "PubSubClient"): > > Hallo st_b , > auf welcher Definition basiert deine Änderung, auf der vom HM600? > Doku werde ich nachziehen, danke für den Hinweis. Ich habe die Definition des HM-600 angepasst. Vollständigkeitshalber sei erwähnt, dass die Werte ursprünglich von Lars B. stammen)
1 | const byteAssign_t hm800assignment[] = { |
2 | { FLD_UDC, UNIT_V, CH1, CMD01, 3, 2, 10 }, |
3 | { FLD_IDC, UNIT_A, CH1, CMD01, 5, 2, 100 }, |
4 | { FLD_PDC, UNIT_W, CH1, CMD01, 7, 2, 10 }, |
5 | { FLD_UDC, UNIT_V, CH2, CMD01, 9, 2, 10 }, |
6 | { FLD_IDC, UNIT_A, CH2, CMD01, 11, 2, 100 }, |
7 | { FLD_PDC, UNIT_W, CH2, CMD01, 13, 2, 10 }, |
8 | { FLD_YW, UNIT_WH, CH0, CMD02, 1, 2, 1 }, |
9 | { FLD_YT, UNIT_KWH, CH0, CMD02, 3, 4, 1000 }, |
10 | { FLD_YD, UNIT_WH, CH1, CMD02, 7, 2, 1 }, |
11 | { FLD_YD, UNIT_WH, CH2, CMD02, 9, 2, 1 }, |
12 | { FLD_UAC, UNIT_V, CH0, CMD02, 11, 2, 10 }, |
13 | { FLD_F, UNIT_HZ, CH0, CMD02, 13, 2, 100 }, |
14 | { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, |
15 | { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 }, |
16 | { FLD_T, UNIT_C, CH0, CMD83, 7, 2, 10 } |
17 | };
|
18 | #define HM800_LIST_LEN (sizeof(hm800assignment) / sizeof(byteAssign_t))
|
Hallo Marcus,
> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.
ich habe die Statistik der Seriennummern noch einmal sauber aufgeräumt
und nach Seriennummer sortiert.
Wenn Ihr wollt, könnt Ihr die gerne einchecken, ich habe die auch nur
weitergeführt.
Ich habe jetzt auch die Usernamen aus dem Forum ergänzt um zu sehen, von
wem evtl. noch eine führende Ziffer zu bekommen wäre:
Arnaldo G. (arnaldo_g), martin (Gast), Oliver F. (of22), heijz, Carsten
B. (carstenb) könntet Ihr eventuell hier im Forum oder direkt in der
Tabelle Eure führenden Ziffern bzw. die Serien-/Modellnummer Eures
Wechselrichters / DTU Modells ergänzen ?
Auch die ForistInnen mit einem MI- Wechselrichter der älteren Bauart
müssten ggf. Ihre Seriennummern beisteuern, da hiervon außer dem TSUN
TSOL-M800 von Daniel M. (Gast) noch keine hier bekanntgegeben wurde.
Hier eine auf die ersten vier Stellen gekürzte Liste aus dem Excel, das ich letzte Woche aktualisiert habe:
1 | Name | Serien |
2 | --------- | ------ |
3 | MI-250 | 1020 |
4 | MI-300 | 1021 |
5 | MI-? | 1022 |
6 | MI-500 | 1040 |
7 | TSOL-M800 | 1041 |
8 | MI-1000 | 1060 |
9 | MI-1200 | 1061 |
10 | MI-1500 | 1061 |
11 | MI-? | 1062 |
12 | HM-300 | 1121 |
13 | HM-350 | 1121 |
14 | HM-400 | 1121 |
15 | HM-600 | 1141 |
16 | HM-700 | 1141 |
17 | HM-800 | 1141 |
18 | HM-1200 | 1161 |
19 | HM-1500 | 1161 |
20 | DTU-G100 | 10D2 |
21 | DTU-W100 | 10D3 |
22 | DTU-Pro | 10F7 |
23 | DTU-Pro | 10F8 |
Wie man sehen kann sind die Seriennummern nicht ganz eindeutig. Aber es sollte von der Zahl der Anschlüsse bzw. MPPT die im Wechselrichter verbaut sind eigentlich hinkommen, daß alle mit der selben Seriennummer zumindest einen ähnlichen inneren Aufbau haben sollten. Lediglich die maximale Leistung der Kanäle scheint sie noch zu unterscheiden. Ich habe auch mal die Seriennummern der DTUs und unseres Exoten TSUN "TSOL-M800" aufgenommen.
Marcus schrieb: >> Ich lade gerne "Collaborators" in das AHOY Repository ein. >> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren >> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als >> Collaborators hinzu. > > Mein GIT: [[https://github.com/dad401]] > > Fokus: Nutzertests mit HM-400 (und HM-300), ggf. > Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste > Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht > commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren > Programmierkenntnissen beteiligt. Einladung ist erfolgt! > Man könnte es ja so machen: > Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software > lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). Das könnten wir auch gerne so halten. Ich habe leider ein bisschen den Überblick verloren, wer an welchem Teilprojekt in welcher Repo am aktivsten ist. Gerne kann ich in der Haupt-Repo im README auf die jeweiligen anderen Repos verweisen, und dann im Laufe der Zeit auch die (dann veralteten) Unterverzeichnisse entfernen. Am besten würde ich dann auch die jeweiligen Autoren mit auflisten, oder? Persönlich fände ich es gut, wenn wir die Doku (https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) im Hauptrepo (https://github.com/grindylow/ahoy) pflegen würden. Die können wir dann gerne auch versuchen, auszubauen und evtl. auf readthedocs.io o.ä. zu hosten. Mir fehlt nur gerade ein bisschen die Zeit - aber über die nächsten Wochen wird sich schon wieder Zeit finden...
isnoAhoy schrieb: >> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente. Habe die aktuelle von @isnoAhoy zusammengestellte Liste jetzt zumindest mal dem Repo hinzugefügt: https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx Ja, die Erkenntnisse daraus sollte ich (?) dann mal in die Haupt-Doku (https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) einfließen lassen...
:
Bearbeitet durch User
Marcus schrieb: > Petra R. schrieb: >> Ich möchte auch mal hinterfragen, ob es einen Sinn >> macht, sekündlich Werte abzufragen? > > Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools > berücksichtigt werden. Ich denke dies ist immer noch des ersten > funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer > stabil kommen. In manchen Programmen war/ist auch immernoch das "AutoACK" eingeschaltet. Das geht in die selbe Richtung: da wir schlüssig nachgewiesen haben, dass die WR kein AutoACK machen, bedeutet das faktisch, dass unsere Programme das jeweilige Paket mehrfach (ich meine 15-fach) hintereinander aussenden. Das führt vermutlich zu "verlässlicherer" Kommunikation, flutet aber natürlich "unnötigerweise" das 2.4 GHz Band. Die bisherigen Erfahrungen zeigen, dass das eine DTU auf jeden Fall nicht ganz so "extrem" macht, und trotzdem "verlässlich" kommuniziert. Langer Rede kurzer Sinn: später muss * das AutoACK ausgeschaltet und * das Poll-Intervall auf einen "sinnvollen" Wert (15s, 30s, evtl. noch langsamer) ...eingestellt werden.
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?
Angehängte Dateien:
-
HM-600_Telegramm.png
17 KB
Hallo zusammen, Jan (HM-600) und ich (HM-1500) haben gerade den ESP8266 und Python Code, die Byte Assignments usw. für beide Wechselrichter angeschaut. Dadurch sind wir auf folgende Erkenntnisse / Theorien gekommen: * Beim HM-600 macht der Weekly Counter keinen Sinn (bei Jan ist dieser höher als der vermeintliche Total) * Der HM-1500 hat Total Spalten für jeden seiner 4 Eingänge * Wenn der HM-600 der gleichen Struktur folgt, müsste dieser 2 Total Werte haben. * Diese beiden Werte müssten jedoch 4 Byte haben * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1) Folgende Überlegungen: Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet. Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert übergelaufen? Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4 Unabhängig davon haben wir einen Pull Request für AC I und P mit einem HM-600 erstellt: https://github.com/grindylow/ahoy/pull/21
:
Bearbeitet durch User
Guten morgen, der Code von ahoy läuft jetzt auf meinem ESP32. Vielen Dank dafür. Ich habe einen HM400 und mir mal die Daten angeschaut und dazu mal eine Frage. Es scheint ja ch0 und ch1 zu geben ? Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das ? Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem Anschluss hat. Was war denn der Plan hinter diesen Channel ? Ich kann es für den HM400 ändern, sobald ich weiß wie das Konzept ist.
1 | HM_400/ch1/U_DC: 38.000 |
2 | HM_400/ch1/I_DC: 3.260 |
3 | HM_400/ch1/P_DC: 123.700 |
4 | HM_400/ch1/YieldTotal: 39.363 |
5 | HM_400/ch1/YieldDay: 183.000 |
6 | HM_400/ch0/U_AC: 229.400 |
7 | HM_400/ch0/Freq: 50.030 |
8 | HM_400/ch0/P_AC: 120.600 |
9 | HM_400/ch0/I_AC: 0.530 |
10 | HM_400/ch0/Temp: 30.100 |
Danke Marcel
Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra Steckdose brauchen würde. Marcel
Hallo Marcel, > Was war denn der Plan hinter diesen Channel ? Channel 0 stellt Parameter dar die keinem direkten Input auf der DC Seite zugeordnet werden können (also z.B. AC Strom der AC Spannung). Da es beim HM-400 nur einen Eingang gibt, gibt es neben dem CH0 auch nur einen weiteren Kanal (CH1) welcher die DC Seite darstellt. > Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das Einspeisen? Nachdem es diesen Wert sowohl für den HM-600 (und kompatible) sowie für den HM-1500 (und kompatible wie HM-1200) gibt, würde ich vermuten das dieser auch für die Einkanal Geräte existiert. Es wurde wohl nur noch nicht herausgefunden welcher Wert dem entspricht.
:
Bearbeitet durch User
Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert. Meine Skills reichen nicht aus um die Fehler selbst zu beheben. Wo stelle ich HM1200 und die Seriennummer ein?
> Es scheint ja ch0 und ch1 zu geben ? Richtig, CH0 dürfte allegemeiner Natur sein, sowas wie AC Seite des Wechselrichters und evtl. Temperatur. > Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das? Nicht ganz CH1..4 sind die MPPT Channel. > Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem Anschluss hat. In der Hoymiles Dokumentation bzw. der App zur Hoymiles DTU-Lite-S heißt CH0 auch "Output grid port" und die anderen Kanäle CH1 .. CH4 "Input port1..4". Ich habe gestern noch ein wenig in den offiziellen Dokus gelesen und dabei habe ich noch eine Menge DTU und WR Seriennummern gefunden. Ich werde diese die Tage evtl. mal noch im Seriennummern XLSX nachtragen.
Hallo Thomas B. und Jan, > * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 > keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht > * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1) Ich glaube die Vermutung hatten wir auch schon weiter oben auf Seite 4. Aber ich habe gerade keine Referenz. Vielleicht war das auch nur ein Gedanke als es sich herausgestellt hat, daß die Yield Total Werte in kWh ja vier Byte belegen. > Folgende Überlegungen: > Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen > Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet. Das wäre in der Tat sinnvoll, da die einzelnen Telegramme ja über den Rahmen jeweils mit einem CRC8 und ggf. CRC_M/16 (Modbus) gecheckt werden können. Vielleicht gibt es am Ende (0x8x Telegramm) ja auch noch eine weitere Prüfsumme ? > Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert übergelaufen? Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn diese Telegramme wie bisher immer einzeln verarbeitet werden. @Lukas P. bei den HM-1000/1200/1500 habt ihr ja alle vier Byte in einem Telegramm. Für die HM-600/700/800 bräuchten wir in der Tat so einen Übertrag oder eine Kombination aller Teilinformationen der Telegramme um die ganze Nachricht zu parsen. > Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null > sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4 Wie gesagt das hatte ich auch angenommen, weiß jetzt aber nicht ob wirklich jemand seinen HM-600/700/800 schon zum "Überlauf" in das erste Telegramm gebracht hat. Dauert ja logischerweise auch doppelt so lange wie bei den größeren HM-1000/1200/1500 =^D Meiner wartet noch auf die Montage der Solarpanele bevor er richtig einspeißen darf.
> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen > ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? > > Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert. > Meine Skills reichen nicht aus um die Fehler selbst zu beheben. > > Wo stelle ich HM1200 und die Seriennummer ein? Hallo Sorbit, schau mal auf der Anleitung nach: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den ESP8266 zu kompilieren. Prüfe mal folgendes: * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support herunterladen) * die beiden RF24 und TimeLib Bibliotheken im Library Manager installieren. @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der ESP8266 Boards Umgebung ? Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem o.g. Github aufmachen, damit wir die Dokumentation erweitern und die Schritte die Dir fehlen nachreichen ? https://github.com/grindylow/ahoy/issues
isnoAhoy schrieb: > brauchen wir auch die Ticker Bibliothek oder ist die Teil der > ESP8266 Boards Umgebung ? Ich denke nicht, da diese direkt von der ESP8266 Bibliothek mitgeliefert wird. (Hier wird sich in naher Zukunft auch noch was ändern, ich diskutiere hier gerade mit stefan123t auf Github.) Sorbit schrieb: > Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen > ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP auf die /setup Seite gehen und dort alles konfigurieren. Marcel A. schrieb: > Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das > Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz > abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra > Steckdose brauchen würde. Das Yield Total ist doch genau das Feld. In der neuen Version sind auch Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 habe ich mal 4 beispielhafte Berechnungen definiert)
isnoAhoy schrieb: > Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die > dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn > diese Telegramme wie bisher immer einzeln verarbeitet werden. Die Schwierigkeit wäre dann auch noch, wenn es wenn es zu Paketverlusten beim Überlauf kommt. Also wenn man z.B. beim HM-600 bleibt und der Total Wert wirklich über zwei Telegramme verteilt ist könnte es ja zu folgendem Szenario kommen: * Anfrage senden * Antwort Paket ID 1 geht verloren * Antwort Paket ID 2 kommt durch und der Total Wert steht bei 0xFF 0xFF... * Paket ID 1 wird erneut angefordert * Jetzt gab es den überlauf, die letzten beiden Bytes in Paket 1 sind 0x00 und 0x01. * Sollte man jetzt beide Pakete einfach zusammensetzen hätte man ja 0x00 0x01 0xFF 0xFF * In Wirklichkeit sollte es aber 0x00 0x01 0x00 0x00 sein * Man müsste also auch Paket 2 neu anfordern
Angehängte Dateien:
Hallo, Lukas P. schrieb: > Das Yield Total ist doch genau das Feld. In der neuen Version sind auch > Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, > dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 > habe ich mal 4 beispielhafte Berechnungen definiert) Da würde ich nicht mitgehen. Das was ich gemessen habe, entspricht nicht dem Yield Total. Es weicht 1% ab. Ich würde sagen, das YieldTotal eben die Gesamtenergie der SolarPanele ist. Laut Datenblatt haben die Hoymiles auch einen Wirkungsgrad in dem Bereich - 99%. Rechnen bringt mir leider nicht viel, da ich einen totalen Wert (immer steigend) brauch (auch nach einem Neustart). Was man simulieren könnte, wäre das ich 1% vom Yield Total abziehe und diesen Wert dann als AC Energy Total nutze. Anbei ein Screenshot wo man den Unterschied zwischen AC und DC sieht. Marcel
:
Bearbeitet durch User
Hallo Thomas B., ja das ist noch ein zusätzliches Grund. Ich dachte nur daran was es für Werte mit den niederwertigen Daten aus Paket 2 ohne die höherwertigen Daten aus Paket 1 ergibt, bzw. wie man diese zwischenspeichert bis das zweite Paket auch da ist. In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. @Lukas P. da könnte der Link zur State-Machine vielleicht nochmal hilfreich sein: https://hackaday.com/2015/09/04/embed-with-elliot-practical-state-machines/
IsnoAhoy schrieb: > In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, > [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn > alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) oder einen Gesamt-CRC. Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu anderen Messeinrichtungen? Ich messe mit einem selbst programmierten Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung. Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh gemessen hat. Das enspricht einer Abweichung von ca. 4%. Wenn ich die aktuelle Leistung vergleiche, dann sind beide Messungen bis 100W nahezu identisch, bei 1000W habe ich schon eine Abweichung von knapp 100W. Danke für den State-Machine Link - sehr schön beschrieben. Ungefähr bei der hälfte habe ich schon an Funktionpointer gedacht ;-) @ESP8266: neue Version 0.3.3 liegt im Git. Umstellung von Ticker zu millis(), Visualisierung zeigt jetzt alle bekannten Werte.
:
Bearbeitet durch User
Lukas P. schrieb: > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Ich messe mit einem selbst programmierten > Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung. > Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh > gemessen hat. Das enspricht einer Abweichung von ca. 4%. Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% Abweichung.
Hallo Lukas, > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Also ich messe mit einem ESP und einem PZEM-004T mit Stromklemme. Ich hatte die Werte damals mit einer Fritz! Steckdose verglichen und die stimmten immer sehr genau. Jetzt, wo wir die Werte vom Hoymiles haben, sehe ich, dass die ziemlich die gleichen sind, wie gemessen. Ich werde die aber mal demnächst genau übereinander legen. Hab seit heute alle Daten in HomeAssistant. Das einzige was ich sagen kann ist, das die Totalsumme 1% abweicht. Da vermute ich aber, dass dieses nicht die AC Leistung ist sondern DC. Marcel
Hallo Leute, Vielen dank für die neue Version. Die 0.3.2 läuft stabil mit dem Wemos. MQTT läuft auch reibungslos. Einen Wunsch hätte ich noch, wenn die Verbindung zum Wechselrichter nach Sonnenuntergang abreißt bleiben die letzten Werte noch im Webinterface und in MQTT stehen. Ist es möglich die Werte nach Sonnenuntergang wenn zb. 10 Minuten lang keine Werte kommen auf 0 zu setzen? Außer natürlich die Ertragswerte… Vielen Dank
Lukas P. schrieb: > IsnoAhoy schrieb: >> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, >> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn >> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. > > Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben > hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. > geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) > oder einen Gesamt-CRC. Das ist richtig. Hilft nicht gegen nicht empfangene Pakete. Andere Baustelle. Soweit verschlechtert das sogar die Empfangsrate, ist aber für den HM-600 zwingend notwendig, weil z.B. der DC kWh total von String 1 sehr sicher genau fragmentiert ist. Vorab, die fragmentierten Werte aus verschiedenen Requests zusammen zu stückeln ist nicht möglich, weil bei einer Werteänderung über das Fragment hinaus zu unterschiedlichen Zeiten sehr falsche Werte heraus kommen. Also kein Cache einzelner Fragmente (cmd'd) möglich! Man kann allerdings versuchen trotzdem irgendwie Werte zu retten, die nicht über mehrere Fragmente verteilt sind. Währe aber sehr viel Aufwand. Die Fragmente werden darüber henaus auch nicht in der richtigen Reihenfolge empfangen. Ich werde die Tage noch ein PR für ein Rewrite der Python-Implementierung einreichen. Ich bin gerade dabei das in Klassen und ein Hoymiles Modul zu zerlegen, so kann man dann damit besser Tinkern oder z.B. auch mal ein Logfile mit Rohdaten durch pipen. Und soweit ich das sehe ich das letzte byte in den 0x8n-Responses die crc8 über die zusammengesetzte Payload. Jedenfalls stimmt das verdächtig zuverlässig. Also der Ansatz mit den cmd's und channeln ist damit mal begraben, würde ich sagen. Das wars jetzt mit dem Wochenende. Ist eh vorbei :) Gruß, Jan
Martin G. schrieb: > In manchen Programmen war/ist auch immernoch das "AutoACK" > eingeschaltet. Auf der Suche nach Gründen, warum der ESP8266 oft hängt bzw. einen Watchdog-Reset auslöst habe ich auch folgendes interessante Detail gefunden: [[https://github.com/nRF24/RF24/issues/244#issuecomment-357210585]] AutoACK sollte demnach am besten aus sein. Es gibt wohl (gefälschte) NRF-Chips, welche damit Probleme machen. Allerdings ist AutoACK bereits bei den hier verwendeten Tools (esp8266, NRF24_SendRecv) aus. > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Bei meinem HM-400 sind YieldTotal/YieldDay recht nah an meinem SonOff Pow R2 (ebenfalls mit 60W, oder waren es 100W Glühlampe?, kalibriert.) Der HM-Wert ist leicht höher. Hier sollte man aber am besten einen kalibrierten Wechselstromzähler als Vergleich nehmen. Die Kalibrierung der SonOff könnte da nicht so gut sein. Es scheint also weiter unklar, ob YT und YD beim 400er nun AC oder DC Werte sind. Mit Blick auf die 600er/1200er müssten es ja auch DC-Werte (Modulwerte) sein. Entweder die Typen sind da komplett unterschiedlich zu bewerten oder es fehlt generell der AC Wert für YT/Yx. Idee: Anhand der DC Werte für P kann man ja YT/YD für einen bestimmten Zeitraum selbst berechnen und dies mit dem ausgelesenen Werten YT/YD vergleichen. Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher sein, da der WR in die Begrenzung geht und damit bei AC weniger "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert anliegt, da Begrenzung). Ich rechne das mal für den 400er YD/YT Wert nach.
Lukas P. schrieb: > Sorbit schrieb: >> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen >> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? > > Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier > angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP > auf die /setup Seite gehen und dort alles konfigurieren. Das ist supernett, danke! Ich probier es ASAP aus. BG
Nomen est Omen schrieb: > Lukas P. schrieb: >> Sorbit schrieb: >>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen >>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? >> >> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier >> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP >> auf die /setup Seite gehen und dort alles konfigurieren. > > Das ist supernett, danke! > > Ich probier es ASAP aus. > > BG Sorry für den faschen Namen, ich bin an einem anderen Rechner in einer anderen "Welt"... Richtig wäre Sorbit, gewesen. Der Ersteller des Threads, der sich wundert was er hier "angestellt" hat. Toll welcher Enthusiasmus sich hier verbreitet hat! Hut ab
Peter L. schrieb: > Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut > AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% > Abweichung. Ich habe hier einen Sonoff Dual R3, um den Ertrag meines HM-600 zu messen. Kalibriert habe ich damals mit einer 60W Glühbirne. Bei mir sind es heute bisher 1,318 kWh (Sonoff) und 1,426 kWh (AHOY 0.3.3). Bei den gemessenen Watt liegt der Sonoff aktuell (keine Voll-Last) jeweils ca. 10-20 Watt unter dem per AHOY gemessenen Wert. Marcus schrieb: > Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher > sein, da der WR in die Begrenzung geht und damit bei AC weniger > "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in > dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für > das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert > anliegt, da Begrenzung). Falls uns das hilft: Ich habe auch Zugriff auf eine zweite Anlage mit HM-600 und zwei "großen" Modulen, die bei guter Sonne regelmäßig in die Begrenzung des Wechselrichters laufen. Evtl. können wir durch die Beobachtungen ja das AC/DC Rätsel lösen.
Meine Anlage besteht aus HM-600 und 2 Module mit je 370 Wp, also 740 Wp. Der höchste gemessene Wert für die aktuelle Leistung war 612 W. Wenn das DC sein sollte müsste es schon mehr sein, m.E. Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal kurzzeitig (wie hier) drüber sein?
Hubi schrieb: > Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal > kurzzeitig (wie hier) drüber sein? Hallo, ich habe 700Wp an meinem HM600 und auf meinem shelly habe ich AC-seitig schon etwas über 600W gesehen. Meist so um die 620W. Lieder habe ich grade keine DC-Daten, da ich nicht mitlogge. Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich da. Carsten
> Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der > sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich > da. Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten zu empfangen. Den kannst Du entweder mit * Deinem D1mini (ESP8266/ESP32) und der ahoy Software unter tools/esp8266 (v0.3.2/3) von Lukas P.oder * einem Raspberry Pi und der ahoy Software unter tools/pi von Martin G. betreiben. Anleitung zur Verdrahtung des ESP findet sich unter https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben könnte. Dann müsste man sich nicht immer erst mit dem Access Point verbinden und könnte diese Settings hart verdrahten. Zumindest in der Entwicklungsphase würde mir das eine Menge Tipparbeit im WebInterface ersparen. Ich habe nämlich jetzt mehrfach den kompletten Flash erased, da ich hier Probleme bei der Umstellung des Speicher-Layouts der Konfigurationsdaten vermutet habe. Auch scheint er den Access Point aufzumachen, wenn er das lokale WiFi Netzwerk (wegen Empfang) nicht erreichen kann. Gibt es auch einen Fallback, daß er immer mal wieder versucht das Netzwerk zu erreichen ?
isnoAhoy schrieb: > @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine > config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte > Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben ... Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update (Fehlerbehebung) sich nicht ändern. Ganz am Anfang dann die Länge von so einem Block. Darüber dann eine CRC bilden. Beim Neustart, dann die Länge aus dem EEPROM lesen. CRC abchecken und wenn so weit ok, dann mit den Werten starten ? Am Ende von so einem Block würde ich das so gestalten, das sich die Anzahl der WR ändern kann, evt. auch einzelne CRC s über WR Blöcke. Wenn sich dann jemand einen zusätzlichen WR kauft und einhängen will, kann alles so bleiben und er muss nur die SN / Typ des neuen WR eingeben. Dann wird der entsprechende Block am Ende drangehängt, mit einer CRC versehen und man kann weiter Software Updates machen ohne irgendwas einzugeben. Ist nur mal so eine Ideeeeeee :-)
Hallo zusammen, nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der ahoy.conf für einen HM-1500 (... [inverter] serial = 116173415022 ) ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 ahoy.py" leider den Anschiss ... ModuleNotFoundError: No module named 'RF24' Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit ... ModuleNotFoundError: No module named 'cross.crossunixccompiler' ... hängen. Ich habe darauf hin mit "sudo pip3 install cross" das umfassende Modul nachinstalliert, das ja dieses 'crossunixccompiler' enthalten sollte. Das ist auch ohne Fehlermeldung durchgelaufen. Es bleibt aber das Problem mit dem RF24, weil nach wie vor die Compilation von RF24 nicht durchläuft: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output. ERROR: Could not find a version that satisfies the requirement RF24 ERROR: No matching distribution found for RF24 Eine Suche nach "crossunixccompiler" war leider erfolglos, so dass ich da aktuell nicht weiter komme. Der Vollständigkeit halber: uname -a liefert: Linux raspberrypi 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 armv7l GNU/Linux Bliebe die Frage: Wo ist der Haken? Ergänzungs-Verständnisfrage zum Ahoy-Paket: Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann? Tschüssi, Petra
Vielen Dank für die zahlreichen Infos zu euren Vergeleichsmessungen. Jetzt habe ich einfach mal den Multiplikator meiner Kalibrierung (Sonoff) wieder auf 1.00 gestellt und habe jetzt identische Werte mit dem WR. Bei Gelegenheit werde ich nochmal mit einer Fritz! Steckdose gegenchecken. isnoAhoy schrieb: > Gibt es auch einen Fallback, daß er immer mal wieder > versucht das Netzwerk zu erreichen ? Das prüfe ich nochmal, sowas hatte ich mal im Sinn weiß aber nicht ob's hier implementiert ist. Finde ich auf jeden Fall sinnvoll. Herbert K. schrieb: > Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im > EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update > (Fehlerbehebung) sich nicht ändern. > Ganz am Anfang dann die Länge von so einem Block. > Darüber dann eine CRC bilden. Danke fürs Feedback. Ja hier ist noch Handlungsbedarf, ich weiß nicht mehr wie oft ich die Daten schon neu eingegeben habe. Ich werde es nochmal durchdenken und evtl. auch gleich umsetzen. Meiner Meinung sind nach der Aufteilung von WiFi und Sonstigen Settings (haben jeweils einen unabhängigen CRC) in getrennte Bereiche keine WiFi-Daten mehr verloren gegangen. (Klar da war noch der Issue mit der Passwortlänge, diese wurde auf 63 Zeichen angehoben)
Petra R. schrieb: > Hallo zusammen, > > nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern > mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der > ahoy.conf für einen HM-1500 > (... > [inverter] > serial = 116173415022 > ) > > ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo > pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 > ahoy.py" leider den Anschiss ... > > ModuleNotFoundError: No module named 'RF24' > > Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit > ... Hallo Petra, die Installation des RF24-Moduls ist leider etwas komplizierter. Ich habe versucht, das in https://github.com/grindylow/ahoy/tree/main/tools/rpi einigermaßen zu beschreiben. Im Prinzip sollte es reichen, der Anleitung für Python 3 auf * https://nrf24.github.io/RF24/md_docs_python_wrapper.html ...zu folgen. Wobei ich auf meinen beiden Raspis zuvor jeweils auch * https://nrf24.github.io/RF24/md_docs_linux_install.html ...gemacht habe. Bin mir aber nicht mehr ganz sicher, ob das wirklich notwendig ist. Einfach nur mit "pip" geht bei dieser Bibliothek wohl (noch) nicht. > Ergänzungs-Verständnisfrage zum Ahoy-Paket: > Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles > wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann? Ja leider richtig. Das entstand, als wir noch der Annahme waren, dass die WR AutoACK aktiviert hätten. Schön wär's gewesen :-(. So findet es nur andere NRF24-Empfänger, die AutoACK aktiviert haben. Leider quasi nutzlos. -- petersilie
Ich habe jetzt wider Erwartens doch noch meine DTU-lite bekommen, und würde mal versuchen, sie in Betrieb zu nehmen. Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem Einrichtungsvorgang "zuhören"? Kanal 40? -- petersilie
Martin G. schrieb: ... > Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem > Einrichtungsvorgang "zuhören"? Kanal 40? ... > -- petersilie Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-) MOSI, MISO, usw. https://www.az-delivery.de/products/saleae-logic-analyzer Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom LA klar kommst, dann die PINs im DTU-Lite :-) so ist das gemeint von mir. Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als Hex anzeigen. Bin mir aber nicht mehr 100% sicher. Muss ja beim 1. Schuss am DTU-Lite zu 100% funktionieren - wir wissen ja nicht, was sich der alles merkt. :-) Den LA gibts natürlich auch bei anderen Anbietern.
:
Bearbeitet durch User
Herbert K. schrieb: > Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-) > MOSI, MISO, usw. Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner DTU festgestellt hatte: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E handelt, der einen eigenen Controller drin hat.
Erstmal für Seriennummernsammlung vorweg. HM-800 11417420xxyy HM-1500 11616320xxyy MI-1200 10616090xxyy Ich bin diesem Thread schon lange gefolgt, wollte mich aber erst melden, wenn ich Daten von meinen beiden Wechselrichtern empfangen konnte. Hatte mir das NRF24LE01+ mit externer Antenne gekauft und einige D1 mini V3, hatte jedoch nie Empfang. Kaufte verschiedene NRF24LE01+ und testete alle möglichen Kombinationen durch. Erst als ich D3 und D4 auf D1 und D2 umverdrahtete, mit der entsprechenden Setup-Änderung, konnte ich problemlos alles empfangen. Vielleicht kann sich einer von euch einen Reim darauf machen, warum D3, D4 bei mir nicht funktionieren. -- olaf
isnoAhoy schrieb: >> Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der >> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich >> da. > > Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten > zu empfangen. Hallo, danke für den Input. Mit einem Arduino nano hatte ich hier ja Anfangs schon Daten mitgeloggt... Dann schau ich mal, ob ich es heute Abend vielleicht auf dem ESP zum laufen bekomme. Carsten
martin schrieb: > Herbert K. schrieb: ... > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E > handelt, der einen eigenen Controller drin hat. ... Entschuldigung ! Daran hatte ich nicht mehr gedacht.
Angehängte Dateien:
-
rx_tx.jpg
180 KB
Hallo martin & Herbert, > > Herbert K. schrieb: > ... > > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E > > handelt, der einen eigenen Controller drin hat. > ... > Entschuldigung ! Daran hatte ich nicht mehr gedacht. Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal anbei. Eventuell könnte man auch mit dem openocd Debugger am SWD Port den GD32F303 anhalten und Flash Programm, etc. genauer analysieren. Es gibt m.W. eine eigene target/gd32f30x.cfg mit der es m.E. nach bei mir funktioniert hat den GD in einem MH-Z19C Sensor anzusprechen. https://github.com/gd32-rs/gd32-openocd/blob/master/target/gd32f30x.cfg Bei einer schnellen Suche nach "openocd gd32" kamen gerade noch die folgenden beiden evtl. interessanten Links heraus: https://registry.platformio.org/tools/communitygd32cores/tool-openocd-gd32 https://github.com/stlink-org/stlink/issues/769 Wobei ich in meinem Fall keinen Erfolg mit dem bestehenden target/st-linkv2.cfg hatte.
Martin G. schrieb: > Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem > Einrichtungsvorgang "zuhören"? Kanal 40? Ideal wäre halt eine breitbandige Aufzeichnugsmöglichkeit mit einem HackRF oder ähnlichem besseren SDR, da ja mehrere Frequenzen in Frage kommen. Ich hab meine Aufzeichnungen mit einem BladeRF gemacht, der macht dann ca 60 Mhz Bandbreite. Vorhanden ist bei mir u.a. der LimeSDR , BladeRF, HackRF. Oder evtl reicht auch ein NRF24L01-Sniffer, der zuverlässig die in Frage kommenden Frequenzen abscannen kann. Durch die Sende-Wiederholungen gibts da normal keine Zeitprobleme.
:
Bearbeitet durch User
isnoAhoy schrieb: > https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md > > Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den > ESP8266 zu kompilieren. Prüfe mal folgendes: > * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support > herunterladen) > * die beiden RF24 und TimeLib Bibliotheken im Library Manager > installieren. > @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der > ESP8266 Boards Umgebung ? > > Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem > o.g. Github aufmachen, damit wir die Dokumentation erweitern und die > Schritte die Dir fehlen nachreichen ? @ Lukas, @isnoahoy, der Geier weiß warum; Erfolg;-) Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen und nun läuft der Compiler fehlerfrei durch!!! DANKE!!!
Sorbit schrieb: > isnoAhoy schrieb: >> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md >> >> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den >> ESP8266 zu kompilieren. Prüfe mal folgendes: >> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support >> herunterladen) >> * die beiden RF24 und TimeLib Bibliotheken im Library Manager >> installieren. >> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der >> ESP8266 Boards Umgebung ? >> >> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem >> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die >> Schritte die Dir fehlen nachreichen ? > > @ Lukas, @isnoahoy, > > der Geier weiß warum; Erfolg;-) > Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen > und nun läuft der Compiler fehlerfrei durch!!! > > DANKE!!! Ich habe den NRF noch nicht angeschlossen (verdammt wo liegt der rum?) Mit dem AP kann ich mich verbinden, anpingen, Webseite bleibt aber leer. Ich denke das ist "normal" so wenn der NRF noch nicht dranhängt? Danke, ich suche weiter...
Sodele,
ich habe jetzt das ahoy.py auf einem Raspi 3B mit einem HM-1500 zur
Kommunikation bekommen und sehe erste Returns:
2022-05-03T07:20:30.553251Z MSG src=73415022, dst=73415022, cmd=1:
{"ts_unixtime": 1651555230.553251, "isodate":
"2022-05-03T07:20:30.553251", "rawdata": "95 73 41 50 22 73 41 50 22 01
00 01 01 4e 00 1a 00 14 00 56 00 42 00 00 08 0b c3", "crc8_valid": true,
"mid": 149, "response_time_ns": 18257366, "ch_rx": 3, "ch_tx": 40,
"src": "73415022", "name": "dcdata", "dst": "73415022", "cmd": 1,
"u1_V": 33.4, "i1_A": 0.26, "p1_W": 2.0, "u2_V": 8.6, "i2_A": 0.66,
"p2_W": 0.0, "p_W": 2.0, "unknown1": 1, "unknown2": 2059}
2022-05-03 09:20:30.601844 Received 27 bytes on channel 3 pipe 1: 95 73
41 50 22 73 41 50 22 02 00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c
e3
2022-05-03T07:20:30.602257Z MSG src=73415022, dst=73415022, cmd=2:
{"ts_unixtime": 1651555230.602257, "isodate":
"2022-05-03T07:20:30.602257", "rawdata": "95 73 41 50 22 73 41 50 22 02
00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c e3", "crc8_valid": true,
"mid": 149, "response_time_ns": 67262961, "ch_rx": 3, "ch_tx": 40,
"src": "73415022", "name": "acdata", "dst": "73415022", "cmd": 2, "u_V":
2.3, "f_Hz": 0.21, "p_W": 7.6, "wtot1_Wh": 0, "wtot2_Wh": 12,
"wday1_Wh": 9, "wday2_Wh": 334, "uk2": 2939}
So ganz glauben tu' ich den Werten allerdings noch nicht. :-)
Nicht mal u1_V und i1_A: Auch wenn die Sonne gerade nicht prall auf das
180 W_p Modul scheint, sollten da doch etwas mehr als 0,26 A bzw. 2 W
kommen, oder?
Fragt sich jetzt, wie ich den Interpretations-Gurus unter euch
bestmöglich in die Seite treten kann?
Noch eine Beobachtung, den Raspi betreffend: Wenn ich den (aus
Stöpsel-Faulheit) nur per WLAN anspreche, scheint der des Öfteren hängen
zu bleiben. Nach Anschluss per LAN-Kabel scheint dies nicht mehr
aufzutreten. Kann es sein, dass dessen WLAN und der nRF24 sich
gegenseitig beim Funken ins Gehege kommen?
Tschüssi,
Petra
Robert Bleumer schrieb: > Steht upload nach PvOutput.org noch auf's Programm? Ich denke aktuell liegt das Hauptaugenmerk noch auf dem korrekten auslesen der Daten. Aber später gibt es bestimmt die Möglichkeit, eine Anbindung zu PvOutput.org einzubauen. Die Doku dazu sieht relativ ausführlich aus, sodass es denke ich gut machbar wäre. https://pvoutput.org/help/index.html
Hallo Martin, danke schön für deine Erklärungen! Mittlerweile läuft's ja, wie man an meinem letzten Post sehen kann. thumbs_up > Im Prinzip sollte es reichen, der Anleitung für Python 3 auf > > * https://nrf24.github.io/RF24/md_docs_python_wrapper.html > > ...zu folgen. Das habe ich gemacht, bin aber auf einige Ungereimtheiten in der Abfolge gestoßen. Dies nur als Warnung für Nachfolgende, die es nach dieser Anleitung wortwörtlich probieren. Letztlich muss ich übrigens das ahoy.py auch mit sudo aufrufen, sonst will es nicht. Irgendwie scheine ich mich aber insgesamt wohl durchgewurschtelt zu haben. ;-) Viele Grüße, Petra
Guten Morgen ! Wie und wann und unter welchen Umständen die Kanäle gewechselt werden weiss ja scheinbar noch niemand (oder doch?). Nur mal so als Idee: Die NRF24L01+ Module kosten ja nicht die Welt. Was spricht denn gegen den Einsatz von 5 Stk. - jedes auf einem festen Kanal ? Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?
Moin, ich baue ja in der Python-Implementierung am empfang der vollständigen Payload vom Wechselrichter. Weil noch sehr "work in progress" gibts da noch kein PR zu. Nur so zur Info. Oben schrieb ich, die Zusammengesetzte Payload ist mit der crc8 im letzten byte der Payload der 0x8n-Fragmente signiert. Es ist jedoch ModbusCRC. Definitiv. Ich hab das bei mir so nebenbei laufen und bekomme sehr gute Ergebnisse. Zur Zeit ist nur der HM-600 implementiert, weil der mit dem Ansatz des Auswertens von Payload-Fragmenten eben nicht vollständig lesbar ist. Was anderes habe ich nicht. Was ich vor dem PR noch tun will: * Dekoder neu implementieren (bloß schnell hin gepfuscht als Beiwerk zum PoC) * PayloadBuilder bauen * Inverter-Klasse als Interface * Multi-Inverter Wie in der test.py zu sehen ist, lassen sich damit auch Logfiles mit Rohdaten neu auswerten. Sehr gut zum nachts entwickeln. ;) https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi (Preview, wird sicher noch ein paar mal amended) Der Output läuft bei mir aus Faulheitsgründen in eine vergleichbare Topic-Struktur, wie auch Shelly sie verwendet. Damit frisst der telegraf das gleich in die richtigen Influx measurements weg. Gruß, Jan
Ich hätte da mal eine grundsätzliche Frage: beim Nordic Protokoll, dass die Daten seriell fliessen ist schon klar aber wird da eigentlich MSB oder LSB zuerst geschickt? Ich dachte bisher immer MSB first, aber das passt überhaut nicht mir der Anzeige meines LA (SALEAE/Sigrok) zusammen. Die Anzeige meines DSO (Batronix Rigol DS1054Z, alle Optionen freigeschaltet) decken sich damit auch nicht. Ich habe schon probiert wie wild, komme damit aber nicht so recht weiter. Wer kann helfen?
Herbert K. schrieb: > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ? Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme vermissen.
> > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ? > Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme > vermissen. Das hatte Oliver F. bereits am 16.04.2022 auf Seite 3 mit einem hübschen Modell mit insgesamt sechs NRF24L01+ vorgeschlagen. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" @Oliver F., was ist denn daraus geworden ?
Angehängte Dateien:
Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana visualisiert. Anbei einige Diagramme. Die AC-Leistung stimmt mit meiner Kalibrierten Sonoff Steckdose bis auf wenige Watt Unterschied überein. Danke und großes Lob an alle.
Angehängte Dateien:
-
grafana_2h.png
140 KB -
grafana_today.png
120 KB
Mich@ schrieb: > Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana > visualisiert. Anbei einige Diagramme. Netter Versuch :) Anbei mal Ausschnitte aus meinem Dashboard. Die zugehörige Telegraf-Config hab ich oben mal gepostet. Das Dash braucht Influx2 (Flux) Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus dem HM600 raus geholt. Request 80 02 + time
1 | 2022-05-03 20:27:56.781439 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 2c 00 00 00 05 00 00 00 00 86 3c 79 |
2 | 2022-05-03 20:27:56.844744 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
3 | 2022-05-03 20:27:56.887237 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
4 | 2022-05-03 20:27:56.935143 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
5 | 2022-05-03 20:27:56.977203 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
6 | 2022-05-03 20:27:57.025358 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
7 | 2022-05-03 20:27:57.073432 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
8 | 2022-05-03 20:27:57.115671 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
9 | 2022-05-03 20:27:57.163807 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
10 | 2022-05-03 20:27:57.211908 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
11 | 2022-05-03 20:28:05.613912 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 35 00 00 00 05 00 00 00 00 16 9b 57 |
12 | 2022-05-03 20:28:05.689287 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
13 | 2022-05-03 20:28:05.737622 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
14 | 2022-05-03 20:28:05.785561 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
15 | 2022-05-03 20:28:05.827717 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
16 | 2022-05-03 20:28:05.875809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
17 | 2022-05-03 20:28:05.923963 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
18 | 2022-05-03 20:28:05.966142 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
19 | 2022-05-03 20:28:06.014271 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
20 | 2022-05-03 20:28:06.056376 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
21 | 2022-05-03 20:28:13.833624 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 3d 00 00 00 05 00 00 00 00 d6 fc f8 |
22 | 2022-05-03 20:28:13.890903 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
23 | 2022-05-03 20:28:13.939259 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
24 | 2022-05-03 20:28:13.981286 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
25 | 2022-05-03 20:28:14.029283 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
26 | 2022-05-03 20:28:14.071458 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
27 | 2022-05-03 20:28:14.119636 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
28 | 2022-05-03 20:28:14.167809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
29 | 2022-05-03 20:28:14.209973 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
30 | 2022-05-03 20:28:14.258033 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
31 | 2022-05-03 20:28:40.145516 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 58 00 00 00 05 00 00 00 00 84 6b 58 |
32 | 2022-05-03 20:28:40.214575 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
33 | 2022-05-03 20:28:40.262608 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
34 | 2022-05-03 20:28:40.304763 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
35 | 2022-05-03 20:28:40.352869 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
36 | 2022-05-03 20:28:40.401014 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
37 | 2022-05-03 20:28:40.443199 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
38 | 2022-05-03 20:28:40.491307 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
39 | 2022-05-03 20:28:40.533532 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
40 | 2022-05-03 20:28:40.581560 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
41 | 2022-05-03 20:28:42.355754 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5a 00 00 00 05 00 00 00 00 e4 72 23 |
42 | 2022-05-03 20:28:42.454595 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
43 | 2022-05-03 20:28:42.490861 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
44 | 2022-05-03 20:28:42.526965 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
45 | 2022-05-03 20:28:42.592729 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
46 | 2022-05-03 20:28:42.629048 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
47 | 2022-05-03 20:28:42.671269 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
48 | 2022-05-03 20:28:42.719446 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
49 | 2022-05-03 20:28:42.791353 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
50 | 2022-05-03 20:28:42.839432 Received 23 bytes channel 3: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
51 | 2022-05-03 20:28:44.815962 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5c 00 00 00 05 00 00 00 00 44 59 ae |
52 | 2022-05-03 20:28:44.885060 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
53 | 2022-05-03 20:28:44.933349 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
54 | 2022-05-03 20:28:44.975352 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
55 | 2022-05-03 20:28:45.029316 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
56 | 2022-05-03 20:28:45.071513 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
57 | 2022-05-03 20:28:45.113829 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
58 | 2022-05-03 20:28:45.161987 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
59 | 2022-05-03 20:28:45.210197 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
60 | 2022-05-03 20:28:45.252331 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche Transaktionen mit valider crc über die 140 byte. Viel Spaß beim dechiffrieren *duckundweg Eine Antwort auf 80 0b "Zeit setzen" sieht zum Vergleich so aus:
1 | 2022-05-03 20:27:07.155080 Transmit | 15 72 22 01 43 78 56 34 12 80 0b 00 62 71 73 fb 00 00 00 05 00 00 00 00 a0 3f 85 |
2 | 2022-05-03 20:27:07.219066 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 24 00 04 00 0b 01 25 00 04 00 0c 00 00 93 |
3 | 2022-05-03 20:27:07.267618 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 97 5f 00 00 8e 5f 07 b2 07 b9 08 e2 13 8a 00 00 f6 |
4 | 2022-05-03 20:27:07.316231 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 00 00 00 00 ca 00 06 0a 1b cb |
5 | 2022-05-03 20:27:07.316231 Decoded: 44 string1= 29.2VDC 0.04A 1.1W 38751Wh 1970Wh/day string2= 29.3VDC 0.04A 1.2W 36447Wh 1977Wh/day phase1= 227.4VAC 0.0A 0.0W inverter=114172220143 50.02Hz 20.2°C |
Gruß, Jan
@ahoy, Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf der Konfig Seite kleben..
Hallo Freunde, solange ihr noch aktiv am Loggen und Entschlüsseln der CMD´s seit, möchte ich euch nochmal an ein in den Hintergrund gerücktes aber wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft werden oder hier wichtige Leute abspringen: Es wäre toll, wenn ihr herausfindet, wie sich die Wechselrichter in der Leistung limitieren lassen, pro Kanal muss nicht unbedingt sein, die Gesamtleistung wäre schonmal ein sehr guter Anfang. (am besten diesen Thread nach "limit" durchsuchen, um die bisherigen Informationen dazu zu finden) Dann hätten wir endlich mal einen qualitativ hochwertigen Wechselrichter zum guten Preis/Leistungsverhältnis, der an einen kleinen Speicher angeschlossen werden kann, um z.B. die Grundlast oder zumindest ein Teil davon nachts mit dem Speicher zu decken. Es gibt bereits ein älteres Projekt aus dem photovoltaikforum mit dem MI-300 und neuerdings auch ein Update mit dem HM-800 (und natürlich baugleiche Modelle in den jeweils 3 Leistungsstufen), bei dem vorsichtig ein Loch an der richtigen Stelle in das Gehäuse gebohrt werden muss und mit einer kleinen Schaltung per PWM über einem Operationsverstärker ein falscher Strommesswert vorgegaukelt wird, so kann man den WR also auch regeln. Das hat natürlich den Nachteil, dass man etwas basteln muss und die Garantie weg ist. Gut, als Batteriewechselrichter sind die auch nicht gedacht, also wie es da mit der Garantie aussieht ist fraglich, aber sie sind zumindest geeignet und man lässt den ja auch nicht permanent mit 100% laufen, sondern regelt ihn ja dann intelligent je nach Bedarf oder Speicherfüllung. Diese guten Mikrowechselrichter sind jedenfalls besser als der Chinaschrott, der ähnlich viel kostet und noch dazu größer, lauter und ineffizienter ist. Es wäre daher toll, wenn quasi die gleiche Regelung per Funk einfach möglich ist. Deshalb würde ich euch darum bitten, dieses Signal mal zu sniffen und zu implementieren. Aber schonmal ein großes DANKE an alle, für eure bisherige tolle Arbeit, gemeinsam bekommen wir den Rest auch noch implementiert! Sonnige Grüße, Andi
Andi schrieb: > möchte ich euch nochmal an ein in den Hintergrund gerücktes aber > wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft > werden oder hier wichtige Leute abspringen: wozu willst den WR regeln? Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, bringt paar Euro Eine Abregelung macht nur wegen der 70% Grenze- die eh keinen Interessiert - Sinn - oder wenn man den WR als Batterie-WR nutzen möchte
> wozu willst den WR regeln? > Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, > bringt paar Euro > Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein hat.
> Es wäre toll, wenn ihr herausfindet, > wie sich die Wechselrichter in der > Leistung limitieren lassen, pro > Kanal muss nicht unbedingt sein, die > Gesamtleistung wäre schonmal ein > sehr guter Anfang. (am besten diesen > Thread nach "limit" durchsuchen, um > die bisherigen Informationen dazu zu > finden) > Es wäre daher toll, wenn quasi die > gleiche Regelung per Funk einfach > möglich ist. Deshalb würde ich euch > darum bitten, dieses Signal mal zu > sniffen und zu implementieren. Hallo Andi, das ist in der Tat ein interessantes und mE wichtiges Thema. 1. Zero Export Restrictions Mode Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU setzen. > 4.1 Work Mode (page 9) > Normal: In this mode, the microinverter operates normally and converts DC power into AC power to support the household loads and feeds into the public grid. > Zero Export Control: In this mode, the microinverter’s generation is limited based on the current household loads, and there is no extra power fed into the public grid. > Standby: There are several circumstances in which the microinverter will be in Standby mode: > • The current condition contradicts with the microinverter operating requirements. > • No household loads or the export control value has been set as “0” on the DTU in the Zero Export Control mode. 2. Grid Power Profile Zusätzlich gibt es noch ein sog. Grid Profile in der DTU/Hoymiles Cloud. Ich weiß aber nicht ob man das zB von AT auf DE oder PT ändern kann… Es wird u.a. auf den Screenshots von Enercab bzw in deren Hoymiles Cloud ausgegeben. > Grid Profile Version: 2.0.0 (AT_TOR_Erzeuger_default) 3. Als drittes ist mir in den Fehlercodes des HM-600/700/800 (6.1 Troubleshooting List, page 14ff) aufgefallen, dass es u.a. auch einen Code „149 Island detected“ gibt. Einige dieser Fehler sollte man ja ggf. Provozieren und auslesen können. 4. Communication with DTU changes Status LED Indicator > 6.2 Status LED Indicator > The LED flashes five times at startup. All green flashes (1s gap) indicate normal startup. > Status LED > (1) Startup Process > • Five green flashes (0.3s gap): Startup success > • Five red flashes (0.3s gap): Startup failure > (2) Running Process > • Fast green flashing (1s gap): Producing power. > • Slow green flashing (2s gap): Producing power, but one input is abnormal. > • Slow green flashing (4s gap): Producing power, but there is no communication with DTU. > • Red flashing (1s gap): Not producing power, AC grid fault (voltage or frequency out of range). > • Red flashing (0.5s gap): Non-grid abnormality fault. > (3) Other Status > • Alternating red and green flashing: Firmware is corrupted. > *Note: All faults are reported to the DTU, refer to the local DTU app or S-Miles Cloud (Hoymiles Monitoring Platform) for more information. https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_HM-600700800_Global_EN_V202203.pdf
Sorbit schrieb: > Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein > hat. IsnoAhoy schrieb: > 1. Zero Export Restrictions Mode > Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. > Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU > setzen. kann es sein das hier die 70%-Regelung (harte/ weiche Abregelung) durcheinander gebracht wird? Für den Zero Export Control mode reicht es sicher nicht diesen zu setzen - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU regelt die WR dynamisch IsnoAhoy schrieb: > 2. Grid Power Profile Damit ist wohl die Einstellung des CosPhi gemeint
Heinz R. schrieb: > - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU > regelt die WR dynamisch Interessant wäre das schon. Leider können da nur die weiterhelfen, die auch die DTU-Pro haben vermute ich. Bei möglichen Fehlern (wie bei MODBUS erklärt), da sind wohl auch die DTU-Pro Besitzer gefragt ? Ich habe beim HM-350 und HM-400 mal auf DC-Plus und DC-Minus einen Kurzschluß zu "Erde" gemacht. Begonnen mit 100K Ohm bis herunter zu 0 Ohm mit verschiedenen Werten. Das hat beide nicht gejuckt. Weder Mitten im Betrieb, noch bevor sie mit dem PV Modul verbunden waren. Die gehen ganz Normal in Betrieb wie immer. Erwartet hätte ich einen "Isolationsfehler", ohne das sie in Betrieb gehen, wie z.B. bei den SMA WR. Bisher habe ich keine DTU-.... Grundsätzlich wäre auch erst mal Interessant, wer welche Fehlermeldungen über die DTU-... dann in der Cloud gesehen hat. So was wie falsche Netzfrequenz zu simulieren, wird schwierig.
:
Bearbeitet durch User
Sorbit schrieb: > @ahoy, > > Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat > und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? > Ich bleibe immer auf der Konfig Seite kleben.. Ahoy, wo bist DU ?;-)
Angehängte Dateien:
-
simple_raspi_hoymiles.jpg
180 KB
Hallo, ich habe mir vor ein paar Wochen 2 Balkonmodule vom Stromanbieter mit 2 (vermutlich HM-350) Wechselrichtern gekauft, und ahoy.py dafür angepasst, damit ich die Ergebnisse in den io-broker bekomme. Vielen Dank was da alles schon an Vorarbeit geleistet wurde! Softwareinstallation wie im repository beschrieben, hardware raspi4, Kabel aus https://www.amazon.de/gp/product/B078JGQKWP weil ich so die gleichen Farben wie in der Anleitung verwenden konnte 😊 und Radiomodul aus https://www.amazon.de/gp/product/B07PBBC4H9 (sind also NRF24L01+ und das + bezieht sich nicht auf die anderen Teile). Damit lässt sich das ohne Aufwand zusammenstecken. Habe mir das Forum von Anfang an durchgelesen und noch hoffentlich noch für HM300, HM450, HM600, HM700, HM-800, HM-1200, HM1500 support eingebaut, indem ich die ersten 4 Stelen der Seriennummer auswerte und entsprechend verzweige. Außerdem Support für mehrere Wechselrichter und etwas weniger Radio Noise nachdem das Programm nach einer Meldung 10 Sekunden wartet um einen Inverter der geantwortet hat nochmals zu fragen. Programm liegt in franzongit branch. Ich hoffe das erleichtert den Einstieg für technisch nicht so versierte. lg Franz
franz schrieb: > für HM300, HM450, HM600, HM700, HM-800, HM-1200, HM1500 support > eingebaut... Die alte ahoy.py, sowie das C-Projekt brauchen einen full-rewrite. Am Python bin ich gerade dran und bau da ein flexibles Modul draus, was im Idealfall so einfach instanzierbar ist wie der mqtt-client, und Framing, Fragmentierung beim senden einer arbiträr langen Payload, sowie Transport-Layer und Dekodierung übernimmt. Im Wesentlichen senden die Wechselrichter halt größere Payloads über mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die längste Payload, die ich von einem HM600 empfangen habe ist 140 byte lang. Da die crc stimmt, confirmed. Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten. Ich gehe bisher davon aus, dass der Fragment-Zähler (ehem. cmd) von 0x01-0x80 zählen kann und 0x80-0xNN (0xNN = Fragment-Zähler größer 0x80) die Anzahl der Fragmente des Pakets angibt. Schon passt da eine ganze Firmware rein. Die einzelnen Fragmente isoliert zu verarbeiten ist ein Dead-End. Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet. Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was angefragt wurde, um die Payload dekodieren zu können. Wir sollten zukünftig also von: Fragmenten, Paketen, und Payloads sprechen. Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das Paket enthält die Payload. Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment + 1 byte crc Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc Jede Payload kann demnach max 2046 byte haben. Vermutung, abgeleitet aus den bisher bekannten Umständen. Man müsste jetzt mal schauen, ob man aus dem 1. byte Payload vielleicht Rückschlüsse auf den Inhalt der Payload gewinnen kann. Gruß, Jan
Hallo Sorbit, ich habe keine Ahnung wen Du mit Ahoy meinst. Ich glaube Martin G. / Petersilie hat das Logo gemalt und das Projekt so genannt ? Ich nenne mich isnoAhoy also eben nicht Ahoy :) > Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf der Konfig Seite kleben.. Das Problem habe ich auch. Das Programm macht beim Neustart mehrere Versuche das konfigurierte WLAN zu kontaktieren. Wenn es nicht klappt oder die Verbindung später abreißt dann kommt man ausser über den Serial Port oder ggf den AccessPoint nicht mehr an die Oberfläche. Lukas P. versucht das Problem einzugrenzen bzw zu beheben. Siehe auch: https://github.com/grindylow/ahoy/issues/15 Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Evtl. kann man in Zukunft die beiden Oberflächen vereinheitlichen und den Reconnect mit dem WLAN alle X Minuten einstellen oder per Serial Command forcieren?
@Heinz Ja, natürlich macht im ersten Moment eine Limitierung keinen Sinn, man verschenkt ja dadurch gratis Energie, wenn man Module dran hängen hat. Aber ich habe ja auch geschrieben, um ihn als günstigen und guten Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) Der beliebte Chinawechselrichter GTIL SUN-1000 bewegt sich auch in der Preisspanne des HM-800, allerdings ist der Wirkungsgrad davon schlecht und die Leistungssteuerung muss man sich auch mehr oder weniger selbst zusammen basteln mit z.B. elektronischen Poti. Noch dazu hat das Ding einen Lüfter der recht laut wird bei 1000W, hängt aber wohl damit zusammen, das die recht hohe Verlustleistung ja irgendwie gekühlt werden muss. Ein Victron Wechselrichter übersteigt die Kosten enorm und ist auch viel zu viel Leistung um die Grundlast über die ca. 10 Stunden Nacht zu decken. Lastspitzen lohnen sich nie die ausgleichen zu können, mit denen muss man leben, das darf ruhig der Stromanbiete rübernehmen, ist einfach am billigsten und macht Insgesamt nur einen kleinen Anteil der Autarkie aus. Das ich den HM-800 nicht permanent mit 800W betreiben sollte ist mir klar, aber darum möchte ich ihn ja auch begrenzen und um halt dynamisch die Grundlast nachts zu decken, die keine 800W beträgt. Böse Zungen würden jetzt sagen, das Netz ist der beste Speicher, das ist aber illegal und nur mit einem rückwärtsdrehendem Ferraiszähler möglich. Ich und viele andere haben bereits einen digitalen Zweirichtungszähler verbaut und der wird nach und nach bei allen kommen... Und ja, eine EIGENBAU PV-Anlage mit Batteriespeicher lohnt sich, aber es dauert natürlich ca. doppelt so lange bis die Investition wieder rein ist gegenüber nur Module + nötiges Zubehör. Einen Fertigspeicher oder am besten noch PV-Anlage montieren lassen würde ich auch nicht, da dauert es mal ebend locker 15+ Jahre bis das wieder rein ist, da die Kosten deutlich höher sind. Mit meinem Eigenbauprojekt komme ich auf knapp 6 Jahre(bei steigenden Strompreise, wovon auszugehen ist, noch eher und bevor die Kritiker kommen: gute LiFePo4-Akkus halten noch ein paar Jahre länger, wenn man die richtig betreibt). Ja ist eine ganze Weile, aber was will man machen, mehr Wp und Einspeisen rechnet sich noch weniger, davon holt man die Nacht auch nicht rein und auf die Bürokratie habe ich auch keine Lust... Außerdem selbst wenn man nach 6 Jahren rechnerisch bei +-0 ist, hat man immernoch die Hardware(Panel, Wechselrichter, Laderegler, Akku mit Restkapazität ...), die einen Restwert hat, beim Stromanbieter sieht man von seinem Geld nichts mehr wieder, das hat mich überzeugt, dieses Projekt zu starten. Warnung: PV macht süchtig! :D ...alles beginnt mit einem einfachen Balkonkraftwerk und nach dem ersten Jahr will man mehr. Aber zurück zum Thema: In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure Daten rankommt, aber leider auch nicht identisch ist), sind Register zu sehen, die dafür zuständig sind: https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf 0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit dem Protokoll zum WR aussieht, aber es muss ja alles über NRF funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70% Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer wieder zyklisch das aktuelle Limit geschrieben. Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur da das möglich bzw. freigegeben ist. Grüße
Angehängte Dateien:
Ich konnte der (esp8266) Anleitung sehr gut folgen und kann seit heute meinen HM-800 auslesen. Super wie schnell dies hier entwickelt wurde! Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry über MQTT. Mir sind zwei Dinge aufgefallen: 1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel vom Wert des 2. Channels sofort überschrieben. 2) In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der Channels. Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler wenn dieser Wert direkt angezeigt wird. Gruß Manuel
IsnoAhoy schrieb: > Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je > nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN > Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Im Prinzip ist alles gleich, nur dass im AP Modus standardmäßig auf die Setup Seite verwiesen wird. Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem WLAN zu verbinden. Achtung, einige Einstellungen gehen beim Upgrade verloren, das wurde noch nicht bearbeitet. Changelog = Git-Log (https://github.com/grindylow/ahoy/commits/main) Wie gewünscht sind jetzt alle Einstellungen, die zur Kompilierzeit gemacht werden können in einer config.h Manuel M. schrieb: > In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay > angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der > Channels. Sehr schön, dass es auf Anhieb geklappt hat. Ich verwende ioBroker als MQTT Server, dieser erstellt dann "Unterordner" da jedes Topic mit Slashes getrennt geschickt wird, z.B.: /inverter/hm1200/ch1/u_dc /inverter/hm1200/ch2/u_dc ... Bei mir wird hierdurch nichts überschrieben, da alles eindeutig und unique ist. > Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler > wenn dieser Wert direkt angezeigt wird. Die Summe lässt sich recht einfach bilden, indem du in der hmDefines.h für den HM800 folgende beiden Zeilen hinzufügst (kopiert vom HM1200):
1 | { FLD_YD, UNIT_WH, CH0, CMDFF, CALC_YD_CH0, 0, 0 }, |
2 | { FLD_YT, UNIT_KWH, CH0, CMDFF, CALC_YT_CH0, 0, 0 }, |
Andi schrieb: > Aber ich habe ja auch geschrieben, um ihn als günstigen und guten > Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) Tolles Thema, gibt es hierzu auch ein Forum? Bin auch interessiert an einer Selbstbau-Speicherlösung. Wäre super wenn man hier eine ähnliche Community hätte wie diese hier, wobei bei Geschwindigkeit kann uns hier keiner was vormachen! ;-)
:
Bearbeitet durch User
Lukas P. schrieb: > Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem > WLAN zu verbinden. Super, wie schnell die Entwicklung voranschreitet! Habe die neue Version gleich installiert :-P Ist leider in mehreren Versuchen nur jeweils wenige Minuten erreichbar, WIFI wurde nur einmal aut. restarted. Nach welchem Zeitraum sollte das WIFI neustarten, muss ich länger warten? Ausserdem ist mir aufgefallen, dass nach dem aut. restart die MQTT Verbindung nicht mehr connected war. Wird die auch restarted? SG Robert
Herbert K. schrieb: > martin schrieb: >> Herbert K. schrieb: > ... >> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E >> handelt, der einen eigenen Controller drin hat. > ... > Entschuldigung ! Daran hatte ich nicht mehr gedacht. Hatte schonmal jemand den Mut, seinen WR aufzuschrauben? Mit etwas Glück ist ja darin direkt ein NRF24L01+ verbaut anstelle des NRF24LE1E?
Lukas P. schrieb: > { FLD_YD, UNIT_WH, CH0, CMDFF, CALC_YD_CH0, 0, 0 }, > { FLD_YT, UNIT_KWH, CH0, CMDFF, CALC_YT_CH0, 0, 0 }, Danke - das klappt so - kann man das in der hmDefines.h für den HM800 so einchecken?
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > > Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus > dem HM600 raus geholt. > > Request 80 02 + time > [code] .... 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c .... > Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche > Transaktionen mit valider crc über die 140 byte. Viel Spaß beim > dechiffrieren *duckundweg > Gruß, > Jan Hallo Jan, kann ich so bestätigen für HM-350/HM-400. Telegramm "04" sieht bei einem von meinen identisch aus. Telegramm "89" sieht bei einem von meinen anders aus bei einigen Bytes, einige sind identisch. Mehr habe ich noch nicht verglichen. Was auch immer das bedeutet. Ich lass das mal ne Zeit mitlaufen, ob sich da Werte ändern.
Hallo, Ich entschuldige mich für meinen deutschen Übersetzer Ich möchte einen externen MQTT-Server verwenden, jetzt kann ich die IP-Adresse angeben (1.2.3.4), kann ich Unterstützung für Hostnamen hinzufügen?
Jan-Jonas S. schrieb: > Im Wesentlichen senden die Wechselrichter halt größere Payloads über > mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die > längste Payload, die ich von einem HM600 empfangen habe ist 140 byte > lang. Da die crc stimmt, confirmed. > Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt > in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich > einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten. ja, das ist sicher so, nur bei meinen kleinen 3xx geht/ginge sich alles in je einem Paket aus. Allerdings ist die python version schon so schlau, alle Antworten einer Sendung einzusammeln und dann hintereinander zu verarbeiten, somit konnte ich einbauen, mit globalen Variablen Daten zwischen 2 Fragmenten auszutauschen, ob es funktioniert, kann ich mangels entsprechender WR nicht testen. Ich nehme an, beim HM-600 ist das highword von total power 1 in 0x02 das letzte Word in 0x01, das das schon aufgetreten? Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich alles im 2. ausgehen, ist aber geteilt. Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder konstant oder springen. Ich erwische aber jedenfalls auch nicht alle Pakete, auch wenn ich 10 Sekunden Pause mache. Zumindest in 87% der Fälle wo ich die Antwort erwische, habe ich beide, so ich mit 40 sende. Bei 23 als Sendechannel ist es bei mir um 25% besser, allerdings erwische ich da ingesamt auch nur auf 40% der Sendungen eine Antwort, wobei auch wieder fast alle auf je 2 channels kommen (40 ->3,75, 23-> 61,75). Den in einem C source aufgeführten Channel 83 habe ich noch nie gesehen, in der DTU-W100 Doku für MI-... steht aber auch nur von 5 und nicht 6 Channels. Habe die von lbp beschriebene Logik zum Holen der Pakete nachimplementiert, war aber bei mir auch nicht besser. Ich denke auch, dass auf dem Channel für weitere Pakete bleiben wie zZ implementiert gar nicht zielführend ist, da nicht nach x-Paketen die Suche beendet wird, greift der Algorithmus aber sowieso zwischen Versendungen nicht. Auch aus Sicht des WR wäre es unklug alles auf je einen Channel zu setzen. Seine Beschreibung zum Nachfordern habe ich noch nicht versucht, diese Sonnenabhängigkeit ist eine echte Programmierbehinderung :-) lg, Franz
Hallo zusammen, ich habe in den letzten Tagen Martin G.'s Raspi-Programm ahoy.py für den HM-1500 adaptiert und die (ich meine, auch von ihm) als Farbgrafik gepostete Feldbedeutung der CMDs durchgesehen und in Teilen ein wenig nachkorrigiert. Jetzt sind die Ausgaben jedenfalls stimmig und für mich mit meiner PV-Paneel-Anordnung nachvollziehbar. (Ich habe 4 180 W bp-Solar Paneele auf dem Balkon liegen.) Um einen besseren Überblick über noch nicht zuweisbare Feldeinträge aus den Commands (1, 2, 3, 132 - was Anderes scheint's beim HM-1500 nicht zu geben) zu bekommen, habe ich das Logging zwecks visueller Inspektion ein wenig umgestellt und die Variablen anders benannt. Alle Änderungen beziehen sich auf die Subroutine on_receive(), die ich in der neuen Form als Anhang dranhänge. Die sich durchaus stark ändernden Blöcke des 132er Commands scheinen wesentlich mit der Verfügbarkeit des AC-Anschlusses zu tun zu haben. Um das zu untersuchen, habe ich den HM-1500 mal stromlos geschaltet und dann wieder eingestöpselt (entspricht ja einem Stromausfall). Die kondensierte Logdatei hängt dazu ebenfalls an. Meine Schlüsse daraus: - Die Variable uk_132_1 korreliert mit einer bemerkten AC-Frequenz - Die Variable uk_132_2 korreliert mit der Stromabgabe Weiter bin ich allerdings leider noch nicht vorgedrungen. Aber vielleicht finden ja einige Gurus hier noch was dazu raus ... ;-) Viele Grüße, Petra
Nachtrag: - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des Wechselrichters.
Einen Wunderschönen guten Tag, da ich so gut es geht vermeiden will, mit China-Servern verbunden zu sein, bin ich auf das Forum gestoßen und bin Erstaunt darüber, was bereits zustande gekommen ist. Applaus dafür! War beim lesen der Postings schon nervös, ob dieses Projekt überhaupt was wird. (Beim Thema sniffen der internen Kommunikation der DTU-W100). In den nächsten Tagen bekomme ich einen HM-1500 und 4x 450Wp Panele, die ich unbedingt begrenzen möchte. Im Idealfall mit Zero-Export-Funktion. (Mir ist bewusst dass hierzu zusätzliche Messinstrumente usw. installiert werden müssten) Die Drosselung des Inverters auf fixe Maximalwerte, wird wohl etwas einfacher zu realisieren sein. Beispiel: Geringer Eigenverbrauch = Inverter auf 50% Höherer Verbrauch = Inverter auf 90% Es gibt auch Möglichkeiten in Form von Zuschaltung zusätzlicher Verbraucher. Habe einige ESP32, ESP8266 und Gosund(Tasmota) Steckdosen zuhause. NRF24L01+ sind auch bestellt. Nach inbetriebnahme kann icht gerne auch Daten beisteuern. Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion zu "entschlüsseln". Fragen: Habe zu diesem Thema nichts gelesen (möglicherweise überlesen): Wenn die Inverter/DTUs ausgeliefert werden, sind sie ja auf einer bestimmten FW, die vermutlich übers Internet upgedatet werden kann. Kann es sein, dass das Verhalten der Kommunikation je nach FW anders ist? Dann müssten wir am besten alle auf der selben FW sein um weiterzukommen.. Besteht bzw. wie hoch ist die Gefahr, dass Hoymiles die Inverter und DTUs updatet und verschlüsselt, wenn man sich zu ihren Servern verbinden? Sollte ich mir vorbeugend jetzt schon einen weiteren HM1500 für eine Zukünftige Erweiterung besorgen? Gehe davon aus, dass Hoymiles die Geräte durch weitere Hardware/Softwareeingriffe noch "sicherer" machen werden und die Inverter in Zukunft keine Seemanssprache verstehen. (Siehe Playstation 4 Jailbreaks) Freue mich darauf, eure Meinungen zu hören.
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.
Angehängte Dateien:
Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. Hoymiles 1200.
Hallo Franz, > Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das > letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich > alles im 2. ausgehen, ist aber geteilt. > > Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder > konstant oder springen. Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD genannt wird/wurde. Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y gesetzt, also das höchstwertige Bit 8 wird gesetzt. Bei zwei Paketen also 0x01, 0x82 Bei drei Paketen 0x01, 0x02, 0x83 Und bei vier 0x01, 0x02, 0x03, 0x84 etc pp Die CRC8 der Pakete sind jeweils die letzten Bytes vor 0x7F Und die CRC_M/CRC16 sind die letzten beiden Bytes vor dem CRC8 des 0x8y Pakets. Wie Jan Jonas schon schrieb wäre es sinnvoll statt von CMD von einem Paket Counter zu sprechen, dessen höchstwertiges Bit 8 gleichzeitig als Nachrichtende Flag dient
Python voraus! ich habe heute mal einen weiteren riesigen Dev-Snapshot gepushed. ahoy.py implementiert jetzt - Multi-Inverter - Transport-Layer und Retransmits von verlorenen Frames - Full Payload Decode mit Device- und Request- abhändigen Decodern - Dynamisches mqtt-publishen, jenachdem wieviel Phasen/Strings TBD: - mehr als nur den HM-600 supporten - code cleanup - irgendwie noch eine Strategie für Struktur der Decoder einfallen lassen Ist halt noch ein PoC und enthält mit Sicherheit Fehler. Hier: https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi Das mit den Retransmits sieht dann so aus:
1 | 2022-05-05 18:46:56.432521 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 73 ff 7e 00 00 00 05 00 00 00 00 59 ad e5 |
2 | 2022-05-05 18:46:56.525429 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 e4 |
3 | 2022-05-05 18:46:56.579134 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 0f 03 e8 00 f5 00 2a 6b f2 b4 |
4 | Error while retrieving data: Frame 1 missing: Request Retransmit |
5 | 2022-05-05 18:46:57.083093 Transmit 11 | 15 72 22 01 43 78 56 34 12 81 8e |
6 | 2022-05-05 18:46:57.137897 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 86 |
7 | 2022-05-05 18:46:57.641794 Payload: 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 00 00 00 0f 03 e8 00 f5 00 2a 6b f2 |
8 | 2022-05-05 18:46:57.641794 Decoded: 24.5 phase0=voltage:227.5, current:1.5, power:33.7, frequency:49.98 string0=voltage:31.5, current:0.55, power:17.5, total:41.482, daily:1595 string1=voltage:31.5, current:0.57, power:17.8, total:39.191, daily:1600 |
Gruß, Jan
Sorbit schrieb: > Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. > Hoymiles 1200. Das kann ich bestätigen. HM-1200 mit AHOY 0.3.6
Servus, habe das ganze jetzt auch laufen. MQTT Broker läuft in Home Assistant. Emfange damit auch alle anderen Geräte, die über das MQTT Protokoll senden. Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected ist.
1 | CMDs:
|
2 | 0x1: 97 |
3 | 0x2: 193 |
4 | 0x3: 145 |
5 | 0x81: 0 |
6 | 0x82: 0 |
7 | 0x83: 0 |
8 | 0x84: 65 |
9 | other: 0 |
10 | |
11 | Send Cnt: 245 |
12 | |
13 | MQTT: connected |
Kann ich das irgendwie anders prüfen ?
Hans W. schrieb: > Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected > ist. Hast schon mit einem MQTT Sniffer die Topics geprüft? Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem // SGR
Robert S. schrieb: > Hast schon mit einem MQTT Sniffer die Topics geprüft? > Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem // hab das ganze mal mit iobroker versucht und da wird ein ganzer Ordnerstamm erstellt. Scheint also an Home Assistant zu liegen... Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA. Aber das kommt dann im Sekundentakt rein. Muss ich wohl noch ein wenig suchen, woran es das liegt im HA. ESP-DTU funktioniert also !!! Top !!!
Hans W. schrieb: > Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( > /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA. > Aber das kommt dann im Sekundentakt rein. > > Muss ich wohl noch ein wenig suchen, woran es das liegt im HA. Ich habe bei mir folgendes in der configuration.yaml: - platform: mqtt state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal" name: "Gesamtproduktion PV-Gartenhaus" device_class: energy unit_of_measurement: "kWh" Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | float) | round(2)) }}" will einfach nicht funktionieren.
Sorbit schrieb: > Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. > Hoymiles 1200. Kann mir vorstellen, dass das an den MPPT Reglern liegt. Der HM1200 hat nur zwei, also sind je zwei Anschlüsse parallel geschaltet. Hier entsteht wahrscheinlich ein geringer Fehler beim messen. Die Spannung wird übertragen, da es für den WR nur 2 DC Spannungen gibt. Petra R. schrieb: > - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des > Wechselrichters. Das ist kein Last-%-Grad, sondern der Power-Factor. https://de.wikipedia.org/wiki/Leistungsfaktor Jan-Jonas S. schrieb: > Transport-Layer und Retransmits von verlorenen Frames Lohnt es sich das Re-Transmit der Pakete zu implementieren? Aktuell ist meine Statistik fast jeden Tag gleich von der Verteilung her. Ich frage, da es ja noch nicht so genau bekannt ist, welche Sendekanäle der WR wirklich benutzt. Hat jemand schon mal eine DTU beim Re-Transmit erwischt?
1 | CMDs:
|
2 | 0x1: 3617 |
3 | 0x2: 11571 |
4 | 0x3: 9310 |
5 | 0x81: 0 |
6 | 0x82: 0 |
7 | 0x83: 0 |
8 | 0x84: 4332 |
9 | other: 0 |
10 | |
11 | Send Cnt: 20883 |
:
Bearbeitet durch User
Hallo IsnoAhoy IsnoAhoy schrieb: > Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD > genannt wird/wurde. > Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y > gesetzt, also das höchstwertige Bit 8 wird gesetzt. > Bei zwei Paketen also 0x01, 0x82 ja, dass die "cmd" paketzaehler sind ist mir klar, dass das leftmost bit die endmarkierung ist, leuchtet mir jetzt auch ein. Ich hatte fälschlicherweise geglaubt, dass es bei anderen Modellen sowas wie anfragenübergreifende Nachrichtenzähler gibt den meine einfachen 3xx inverter mit 112174.. nicht haben - obwohl ich sie beim Zusammensuchen der dortigen Felder nicht gesehen hatte. Als ich mit anderen Sendekombinationen experimentiert hatte, war ich bis (durchgängig) 7 gekommen, allerdings habe ich das 0x88er dann wohl immer verpasst. Fast schade, dass ich Dienstag soviel Zeit hatte andere Modelle dazuzusuchen und die Struktur anzupassen (z.B. 3 mal umüberlegt ob mit 0 oder 1 bei DC zu starten, in der micro version ist es ja 1), immerhin habe ich nur heute abend ein wenig erfolglos refetching probiert. Ich habe mir aber als ich es merkte gleich Jans neue Version geholt. Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-( lg, Franz
Kann ich mit Daten aus meinem HM1200 helfen? Wenn ja, welche werden benötigt?
Robert S. schrieb: > Ich habe bei mir folgendes in der configuration.yaml: > > - platform: mqtt > state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal" > name: "Gesamtproduktion PV-Gartenhaus" > device_class: energy > unit_of_measurement: "kWh" > > Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein > > value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | > float) | round(2)) }}" > > will einfach nicht funktionieren. ich hab es jetzt mal so eingetragen. Morgen sehen wir weiter.
1 | - platform: mqtt |
2 | state_topic: "/inverter/hm1500/ch0/YieldTotal" |
3 | name: "Gesamtproduktion PV-Gartenhaus" |
4 | device_class: energy |
5 | unit_of_measurement: "kWh" |
6 | value_template: > |
7 | {{value|round(2)}} |
8 | state_class: total_increasing |
9 | unique_id: "pv_gartenhaus_total" |
10 | last_reset_topic: "/inverter/hm1500/ch0/YieldTotal" |
11 | last_reset_value_template: "1970-01-01T00:00:00+00:00" |
Lukas P. schrieb: >> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des >> Wechselrichters. > > Das ist kein Last-%-Grad, sondern der Power-Factor. > https://de.wikipedia.org/wiki/Leistungsfaktor Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" getaufte Variable (Werte typisch bei 980 => 0,98) meintest? Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und "uk_132_4" (wild im einige Zehntausenderbereich schwankend). Any ideas? Tschüssi, Petra
Petra R. schrieb: > Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" > getaufte Variable (Werte typisch bei 980 => 0,98) meintest? > > Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" > (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und > "uk_132_4" (wild im einige Zehntausenderbereich schwankend). > > Any ideas? Hallo Petra, ich kann bestätigen, uk_132_2 verläuft nahezu genauso wie der Leistungsfaktor den meine Gosund Zwischensteckdose ausgibt. Dies ist auch so bei [1] und [2] implementiert. Was Jan herausgefunden hat steht im letzten empfangenen Paket (also das mit 0x8*) in den letzten beiden Bytes (bei dir uk_132_4) der CRC über die gesamte Payload. Dies ist auch in seiner Implementierung so umgesetzt. Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl 0x00 0x07 Dein uk_132_1 konnte ich hier ebenfalls noch nicht zuordnen. [1] https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h [2] https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py Güße Thomas
franz schrieb: > Ich habe mir aber als ich es merkte gleich Jans neue Version geholt. > Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein > Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-( Sehr schön :) Übrigens kann man mit dem python-Modul auch "offline" debuggen [code] root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3 Python 3.9.2 (default, Mar 12 2021, 04:06:34) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import hoymiles >>> response = bytes.fromhex("00 01 01 3b 00 03 00 0b 01 3c 00 04 00 0d 00 00 a2 16 00 00 99 24 06 47 06 4d 08 dc 13 8a 00 00 00 00 00 00 00 00 00 d8 00 5a b1 89") >>> hoymiles.decoders.HM600_Decode0B(response).__dict__() {'phases': [{'voltage': 226.8, 'current': 0.0, 'power': 0.0}], 'strings': [{'voltage': 31.5, 'current': 0.03, 'power': 1.1, 'energy_total': 41494, 'energy_daily': 1607}, {'voltage': 31.6, 'current': 0.04, 'power': 1.3, 'energy_total': 39204, 'energy_daily': 1613}], 'temperature': 21.6, 'frequency': 50.02} >>> [code] Die response ist dabei eine komplette Payload, wie sie in meinem obigen Logauszug zum retransmit-Beispiel zu finden ist. Die Decoder sind Klassen in hoymiles/decoders/__init__.py class {model}_Decoder{req_cmd}(AntwortTypElternklasse) also HM600_Decoder0B(StatusResponse) Bisher gibts 2 Hautklassen UnknownResponse und StatusResponse StatusResponse ist hauptsächlich für die 0b-Werte zu verwenden und stellt den __dict__() accessor bereit. Dann muss man noch in der ResponseDecoderFactory-Klasse in hoymiles/__init__.py die ser_db um die Seriennummern-Maske erweitern, wenn die Liste das gewünschte Modell bisher nicht abdeckt. Wie gesagt, die Struktur ändert sich wohl noch. Das hab ich jetzt alles schnell um den eigentlichen Transport-Layer drumrum gehackt. Teaser: Es gibt dann schon eine Vorbereitung für einen command_queue, um später auch WR per mqtt steuern zu können. Bei mir geht übrigens ein Interval von 4 Sekunden. Bei mehreren WR würde ich sagen interval + 5s für jeden WR. Nachtabregelung muss noch implementiert werden. Ich würde das aber lieber an Anzahl TX ohne Antwort binden statt an Uhrzeiten. Also wenn nach 30 Anfragen keine Antwort, interval auf 5 Minuten oder so. Jede Payload wird im Übrigen bis zu 4x je interval wiederholt, wenn keine Antwort kommt. Das ist Absicht, brauchen wir spätestens wenn wir steuern wollen und außerdem will ich meine Antworten garantiert innerhalb des interval bekommen.
Hi Thomas, > Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl > 0x00 0x07 Da kommen bei mir aktuell häufig Werte 11 und 12. Vielleicht kann ja mal ein DTU-behafteter Kollege nachschauen, welche Werte man über die bereits zuweisbaren hinaus als Information abfragen kann? Tschüssi, Petra
Angehängte Dateien:
-
esp_dtu.JPG
61 KB
Hallo bin neu hier. Habe heute meine Hardware bekommen: NodeMCU + NRF24L01. Compilieren, Upload und Config hat funktioniert. Daten vom HM600 bekomme ich noch keine, evtl. bin ich zu weit weg. NRF24L01 wird erkannt, MQTT ist connected (IoBroker). Folgendes ist mir aber bis jetzt aufgefallen: Nach einem Reboot klappt scheinbar die NTP-Abfrage nicht immer. In der seriellen Console steht oft [NTP]: 1970-00-00+00:00:00, selten das korrekte Datum/Uhrzeit. Im WebIf steht immer 1970-00-00+00:00:00. Habe den Timerserver auch schon auf fritz.box geändert, bringt nichts. Evtl ist die Abfrage ja zu schnell nach dem Wifi-Connect. Update: Die ersten Daten sind angekommen. Wenn ich mit irgendwelchen Rohdaten helfen kann, bitte melden.
:
Bearbeitet durch User
Hallo Harry F. Daten bekommst Du erst wenn Du die Seriennummer im Setup eingetragen hast. Das sollte selbst ohne WLAN Verbindung zum NTP server funktionieren. Ich weiss aber nicht ob der WR auf Epoch 1970-01-01 reagiert, die Anfrage für die Statusdaten ist ja im Prinzip das Zeit setzen Kommando. Was sagt er denn bzgl RF24 und Anschlüssen. Irgendjemand hat auch hier oder im github unter Issues gemeldet dass die IRQ Leitung nicht an allen / beliebigen ESP8266 Anschlüssen funktioniert. Der Anschluss muss Interrupt fähig sein. Mit besten Grüßen Stefan
Angehängte Dateien:
Hallo zusammen, erst mal tausend Dank für die super Arbeit die ihr bisher gemacht habt. Der ganze Thread liest sich echt wie ein Krimi. Ich habe einen HM600 mit zwei Modulen und heute mal den Lötkolben angeschmissen und das ganze auf einem Wemos D1 Mini zum laufen gebracht. Wenn ich die Statistik-Werte mit den anderen hier geposteten vergleiche, kommt es mir so vor, als würden bei mir deutlich weniger Pakete ankommen. Mein ESP6288 ist nur ca. 2m vom WR entfernt. Ist bei meinem Setup irgendwas schief gelaufen oder ist das im Rahmen? Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen erzeugt worden.
Hallo Lukas, habe gerade mal nachgesehen mein ESP8266 (v0.3.6) hatte vor 2:15h wohl einen Reset. Das Datum steht immer noch auf 1970 aber er zeigt Werte (Temperatur, Yield Total, Spannung, Strom, etc.) an und ist auch per WLAN Router erreichbar. D.h. nach erfolgreicher Verbindung mit dem WLAN Router erfolgt kein erneuter NTP Abgleich.
H. E. schrieb: ... > Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast > doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen > erzeugt worden. Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? 292,70 + 290,80 = 583,50 P_DC 583,50 P_DC /// 420,00 P_AC ---> 72% ? Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%
:
Bearbeitet durch User
Angehängte Dateien:
Hallo und danke an alle die hier so tolle Arbeit leisten! Auch ich habe heute meine Anlage bekommen (HM-1500) und habe die ersten Daten empfangen. Allerdings war das erste NRF24 Modul defekt. Erst nach dem Austausch lief alles. Aber dann wirklich wunderbar. Die Daten sind plausibel und die Pakete kommen in hoher Anzahl. Auch mit einer Entfernung von aktuell ca. 6-7m. Hab den MQTT Client in FHEM eingebunden. Daten kommen sauber rüber. Allerdings wird der Client nach jedem Neustart als neues Device erkannt. Könnte da noch etwas angepasst werden? Ich hab die AHOY:0.3.2 auf einem NodeMCU. Könnte der Device Host Name genutzt werden?
Herbert K. schrieb: > H. E. schrieb: > ... >> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast >> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen >> erzeugt worden. > Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? > > 292,70 + 290,80 = 583,50 P_DC > 583,50 P_DC /// 420,00 P_AC ---> 72% ? > > Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3% Ne, abgeriegelt habe ich nichts. Ich habe auch keine DTU mit der ich das tun könnte. Ich glaube das liegt daran, dass die Daten der beiden Channel nicht synchron mit den oberen Daten sind. Die Daten dort sind auch lange auf 0 stehen geblieben (außer YieldDay), bis dann nach ca. einer Stunde das erste 0x1 Signal kam. Läuft also noch nicht so rund bei mir.
Hallo,
habe gerade meine Python-Implementierung [1] nochmal gepusht.
Hinzugekommen sind:
* Support für den HM-1500
* Mqtt {topic}/command payload-relay
* Default decoder zur einfacheren Protokollanalyse
1 | $ mosquitto_pub -t hoymiles/11417/command -m 800b00tttttttt0000000500000000 |
Injiziert z.B. ein Zeit-Setzen-Kommando. tttttttt ist eine Variable für die Zeit. So kann man sehr einfach und zur Laufzeit neue Payloads ausprobieren. Gruß, Jan [1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi
H. E. schrieb: > Herbert K. schrieb: >> Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? > > Channel nicht synchron mit den oberen Daten sind. Genau, weil es keine "channel" gibt. Das passiert, wenn man Datenfragmente die zu unterschiedlichen Zeitpunkten "aus dem Kontext gerissen" wurden korelliert. Bei einer Abregelung sinken zwingend DC und AC-Werte um die gleiche Summe. Blieben die DC-Werte hoch würde der WR massiv Energie vernichten müssen. Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung einfach der falschen Datenerhebung geschuldet und wenn mans richtig machen würde, wie es aktuell das Python-Ding tut, ist das der Wirkungsgrad des WR. Unabhängig von der Abregelung.
Hallo Jan-Jonas ich finde es toll mit welchem Elan du an die Sache dann gehst. Echt schön zu sehen, dass auch andere viel Zeit investieren. > Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung > einfach der falschen Datenerhebung geschuldet und wenn mans richtig > machen würde, wie es aktuell das Python-Ding tut, ist das der > Wirkungsgrad des WR. Unabhängig von der Abregelung. Allerdings finde ich hast du dich hier im Ton vergriffen. Ich fühle mich in keinem Wettbewerb und ich will schon gar keine zwei Lager bilden. Bitte lass uns weiterhin an einem Strang ziehen. Jeder kann per PR beitragen. Die aktuelle Implementierung ist bei allen noch ein PoC oder? Es gibt noch kein richtig oder falsch sondern eher Fortschritte. Die Version des ESP8266 ist halt Stand heute nicht mehr 'up to date'.
Guten Morgen, soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum MQTT Broker. z.B. bei mir gestern um 16 Uhr. Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den Logs. Also ESP reboot und dann ist er sofort wieder connected. Sonst noch jemand Probleme mit MQTT ?
Wir diskutieren schon länger auf github über Stabilität. https://github.com/grindylow/ahoy/issues MQTT läuft bei mir stabil, hatte vor 20h den letzten Komplettabsturz, danach hat alles von selbst wieder funktioniert. (Version 0.3.6)
Hans W. schrieb: > Guten Morgen, > soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr > zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum > MQTT Broker. z.B. bei mir gestern um 16 Uhr. > Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine > Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den > Logs. > Also ESP reboot und dann ist er sofort wieder connected. > Sonst noch jemand Probleme mit MQTT ? Bei mir selbiges. Das Wlan läuft stabil, aber der MQTT-Client schließt die Verbindung und macht sie nicht wieder neu auf.
Mein Wemos D1 mini mit 0.3.6 läuft leider gar nicht stabil. Die Uptime ist selten höher als 1 Stunde, die automatischen reboots dauern oft sehr lange oder vielleicht findet er auch keine SSID oder DHCP. Jedenfalls habe ich in der Statistik manchmal stundenlange Lücken. Vermutlich auch deshalb weil er nur ca. jedes zweite Mal den MQTT connected. Die onboard LED blinkt übrigens unregelmäßig, weist das auf Ausfälle hin? WIFI Probleme glaube ich eher nicht, RSSI ist bei ca. -70dbM, andere ESP8266 in der Nähe funktionieren ohne Probleme. Kann es sein dass das NRF Modul stört, es sendet und empfängt ja auf derselben Frequenz. Das NRF-Modul scheint recht stabil zu sein, der WR ist durch ein Fenster mit Jalousie und dann noch ca. 20m Luftlinie entfernt. Wäre es möglich den WIFI-RSSI auf der Webpage anzuzeigen oder via MQTT zu publishen? Damit könnten wir schlechte Verbindungen leichter erkennen.
Also heute ist es wie gestern ... um 16 Uhr MQTT Abbruch aber der Wemos ist noch up
Hallo Zusammen, ich habe heute mal versucht den HM-600 aufzuschrauben. Leider habe ich ihn nicht komplett aufbekommen. Ich vermute daß man irgendwie die Kabelzugentlastungen lösen muß und evtl. auch noch mit etwas Wärme aus einem Heißluft-/-fön die Dichtungen lösen muß. Das habe ich meinem neuen Geräte dann doch nicht alles zumuten wollen, es soll ja nachher wieder wasserdicht und möglichst lange seinen Dienst verrichten. Vielleicht hat ja jemand einen gebrauchten, defekten HM den er mal zu Anschauungszwecken defilieren kann ? @Jan-Jonas, ich habe Deine Paketanalyse mal nachvollzogen. M.E. hast Du Recht mit dem Paketzähler und dem höchstwertigen Bit 0x8y das das letzte Paket oder eben die Anforderung für einen Request (vielleicht sogar einen Retransmit) bedeutet. Ich habe die Ergebnisse dieser Paketanalyse vorläufig hier im Github Issue dokumentiert, das kann man ggf. auch in die hoymiles Doku aufnehmen. https://github.com/grindylow/ahoy/issues/24 Hat das (so einen Retransmit oder die Spezialanfrage mit X Paketen von Jan Jonas) bei den auf Seite 1 & 2 gemachten HackRF und anderen Funkprotokollmitschnitten der Original DTU auch sonst noch jemand feststellen können ? Vielleicht können ja noch ein paar alte Hasen (die schon vor Ostern hier geforscht haben) hierzu etwas beitragen ?
lpb schrieb: > Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das > Anfordern eines nicht erhaltenen Pakets. > Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket > anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. @isnoAhoy Hier wurden die Retransmits bereits im DTU Log gefunden. Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die Statistiken, also die Counter wie oft welches Paket kam. "CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x 0x84 Anfrageinterval war 1s auf Kanal 40, empfangen statisch auf Kanal 3.
Bei mir werden die Werte per MQTT alle Sekunde geschickt obwohl es auf 10 Sekunde eingestellt ist. Änderungen der Zeit haben keinen Einfluss.Ist das auch bei anderen so? ESP-DTU 0.3.6
Hallo Lukas P., Du hast Recht in Spalte AA bis AE stehen drei Pakete der Standardantwort. Man kann gut sehen, daß der GD32 das Paket 0x01 nicht empfangen hat und damit in Spalte AD nochmal mit 0x81 und CRC8 0x94 anfordert. Die Antwort mit dem fehlenden Paket kommt dann in Spalte AE. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Nur die Paketcounter sind eben nicht in Zeile 16 wie von martin (Gast) im Excel vermutet. Sondern wie richtig von lbp und Jan-Jonas bemerkt das in Zeile 10 bisher als CMD bezeichnete Byte. Zeile 13-16 ist hingegen die Zeit in Unix-Epoch wie anderweitig bereits herausgefunden wurde. In Spalte AU-AZ taucht dann auch die Anfrage mit 0x80 0x11 auf, die Jan-Jonas als bisher größtes Antwortnachricht mit den Paketen 0x01..0x85 des WR identifiziert hat. @martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt zwischen GD32 und nRF24 aufzuzeichnen ?
Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen Sinn ständig die Zeit neu zu setzen. Gedacht habe ich an sowas wie ein Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die Retransmits. @Jan-Jonas S. (janjonas_s) Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den Payload gebildet werden. Beispiel, so wie es aktuell verstehe, aber die CRC8s und CRC16_P stimmen nie: 01 [...] CRC8 CRC16_H CRC16_L 02 [...] CRC8 CRC16_H CRC16_L .... 8X [...] CRC16P_H CRC16P_L CRC8 CRC16_H CRC16_L CRC8: über Paketpayload ohne CRC8 und CRC16 CRC16: ist implementiert und funktioniert CRC16P: über die gesamte Payload aller Pakete - mit oder ohne dem Paketcounter?
Hallo Jan, Jan-Jonas S. schrieb: > Hinzugekommen sind: > * Support für den HM-1500 ich dachte bisher dass ich HM-350 haette (steht leider nicht lesbar drauf ohne den WR vom Modul zu lösen, das ja auch noch montiert ist), Aber HM-4xx macht keinen Sinn, da ich pro Modul nur 325Wp habe. Allerdings war ja die Vermutung dass die 3xx und 400 gleiches Protokoll haben, darum hatte ich die bei mir alles als 300 zusammengefasst. Ich habe daher im angefügten diff meine (mit 112174..) als 3XX bezeichnet, aber vermutlich könnte man die letzte Stelle weglassen und 3xx und 4xx damit covern. Ich habe ein diff attached. Ad Retransmit, das hatte bei mir nicht funktioniert, bis ich die +6e7 ns bei empfangenen Paketen entfernt hatte, dann erwischte ich ueberhaupt fast alles, das hast Du jetzt auf +5e8, meine Antworten kommen zwischen 1ms und 10ms, geht sich also locker aus. Sollte auch in der Mikrocontrollerversion also mindestens so hoch sein. Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages auch flat in ein kompaktes File schreiben zu können, hab mir sowas für einen geplanten remote site implementiert wo ich keine db hinter iobroker haben werde. lg, Franz
Lukas P. schrieb: > Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) > werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, > ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen > Sinn ständig die Zeit neu zu setzen. Ich glaube der WR hat keine RTC und braucht daher die Updates der Zeit über die Luft, damit er z.B. weiß wann die daily counter resetet wetden müssen. > Gedacht habe ich an sowas wie ein > Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die > Retransmits. Da stehen wir noch vor dem Anfang. Ich glaube, dass das byte nach 0x80 (normal 0x0b) das Kommando ist. Die Zeit, die wir dahinter setzen die Parameter zum Kommando. Ich hab das mal durchgesweept und bekomme da alle möglichen langen und kurzen Antworten, die sich meist auch unterscheiden jenachdem welche Parameter man anhängt. Da sind wir auf mehr DTU Captures angewiesen um das verstehen zu können. Aber da war in python spätestens auch Schluss mit den cmd'd, weil jede Antwort mindestens ein Fragment 1 enthält, wo keine bekannten Werte drin stehen. Das macht dann graphen sehr kaputt, wenn man random binärdaten zu Zahlen macht. Übrigens zum sweepen s.O. das /command-Topic. Sehr handy. > @Jan-Jonas S. (janjonas_s) > Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der > C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu > prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh > oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den > Payload gebildet werden. in hoymiles/__init__.py InverterTransaction.get_payload()
1 | # check crc |
2 | pcrc = struct.unpack('>H', payload[-2:])[0]
|
3 | if f_crc_m(payload[:-2]) != pcrc: |
4 | raise ValueError('Payload failed CRC check.')
|
Jedes Frame besteht aus
0x95, 4byte dst_addr, 4byte src_addr, 1byte sequence, bis 16byte(?)
data, 1byte crc8
sequence:
0x01 - 0x80 ist ein forlaufendes Fragment
0x81 - 0xFF(?) markiert das letzte Paket, und die Gesamtzahl der
Fragmente
Wenn sequence größer 0x80:
int(sequence - 0x80) = Anzahl Fragmente
Das Endpaket zählt mit in den Paketzähler, 0x80 kann daher kein Wert des
Endpakets sein. 0 Pakete = keine Übertragung ;)
Wenn mann alle data bytes in der richtigen Reihenfolge zusammen setzt
(Payload), sind am Ende die 2 byte die modbus crc über die ganze Payload
Fehlt das Endpaket ist die Transaktion verloren. Die Pakete werden
meistens nicht in der richtigen Reihenfolge empfangen. Kann sein, dass
man die in der Reihenfolge 84, 01, 03, 02 liest.
Neu ist für mich auch, dass bei längeren Payloads, der WR auch auf Ch 40
antwortet.
Den ersten Re-Transmit habe ich hier gefunden
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo franz, vielen Dank für das HM3XX-Mapping! Pulled-in. franz schrieb: > Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages > auch flat in ein kompaktes File schreiben zu können, hab mir sowas für > einen geplanten remote site implementiert wo ich keine db hinter > iobroker haben werde. Sowas ist geplant und möglich. Ich stelle mir das python-modul später mal so vor, dass man es ähnlich wie auch den paho mqtt-client irgendwo rein laden kann und ein on_message-Callback bekommt, indem man Daten aus der Response nach belieben verarbeiten kann. Ich plane z.B. einen direkten Influx2-Exporter, so umzusetzen. Das soll dann jeder selber modular bauen können, weil jeder sein eigenes Backend hat und die Zahl der Output-Plugins den Rahmen des Projekts sprengen würde. Da bin ich aber noch nicht soweit, weil wir mit Sicherheit im Kern noch Dinge entdecken die möglicheriweise grundlegend überarbeitet werden müssen. Da liegt im Moment mein Fokus drauf. Bis dahin würde ich gerne die Komplexität außen rum so gering wie möglich halten. Gruß, Jan
Hallo Jan, Jan-Jonas S. schrieb: > Pulled-in. hab die germergte version ausprobiert, funktioniert. Überinges war meine timing Aussage vorher falsch es sind 1-10 hundertstel-, nicht 1-10ms. Ich hatte mir mehrere (7) NRF module bestellt, weil ich mir nicht sicher war, ob die wayintop + sind, die + von AZ so billig waren und laut Kommentaren und eigenen Beobachtungen gibt es öfters Aufälle, bzw schlimmer, funktioniert dann nicht zuverläßig. Ich habe nur in ca einen von 1000 Fällen eine Antwort am Sendekanal (40) und 90% auf 3 und 75. ALso kann ich mit einem chip staendig auf 3 und mit dem Sender gleich auf 75 umschalten, um zu sehen ob was kommt. Mit einem 2. Rapsi kann ich dann auch noch auf 2 weiteren Kanälen lauschen, sollte von der library her gehen und werde das mal ausprobieren :) lg, Franz
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 |
Angehängte Dateien:
-
20220509_Grafana.png
300 KB
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
Angehängte Dateien:
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).
Angehängte Dateien:
-
IMG_6141.JPG
230 KB
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.
Angehängte Dateien:
-
Hoymiles_001.png
26 KB
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 ;-)
Angehängte Dateien:
-
_MQTT_Test.png
41 KB
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 ?
Angehängte Dateien:
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.
Angehängte Dateien:
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.
Angehängte Dateien:
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
Angehängte Dateien:
-
Ahoy-44.JPG
72 KB
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
Angehängte Dateien:
-
rx_tx.jpg
180 KB
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.
Angehängte Dateien:
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.
Angehängte Dateien:
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
Angehängte Dateien:
und noch eines aus dem MI-1200
Angehängte Dateien:
-
dtu_lite.jpg
12 KB
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
Angehängte Dateien:
-
IMG_20220524_193539.jpg
230 KB -
IMG_20220524_194100.jpg
230 KB -
IMG_20220524_194121.jpg
230 KB -
IMG_20220524_194131.jpg
240 KB -
IMG_20220524_193651.jpg
210 KB -
IMG_20220524_193621.jpg
220 KB -
IMG_20220524_193539.jpg
230 KB
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
Guten Abend, anbei die neusete Version. Danke an @Jan-Jonas, diese Version hat jetzt auch den Retransmit des letzten Pakets, sobald bekannt ist welches das letzte Paket ist. Ich hoffe die Stabilität konnte weiter verbessert werden und stellt einigermaßen zufrieden. Durch den last-Paket-Retransmit kommen bei mir deutlich mehr komplette Payloads zustande (mit einem 5s Interval). Aktuell funke ich durch 3 Betondecken vom Keller aufs Dach. Edit 22:20: 0.4.12 mit Boot-Loop fix Wir haben 1000 Beiträge =) Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =)
:
Bearbeitet durch User
Misch O. schrieb: > suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem > Link dazu helfen Hier die brandaktuelle 0.4.11 kompiliert für den Wemos D1 mini
leider nicht mehr brandaktuell, es gibt schon die 0.4.13.
Lukas P. schrieb: > Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =) oh, mein Artikel kam zu spät, lumapu ist so schnell am committen, ich komme mit dem kompilieren nicht nach ;-)
Moin zusammen, nach der Arbeit schaue ich mir mal den Code und alles an. :) Ich nutzte aktuell VS Studio und aktuell für den Arduino, die eigene IDE. VSCode läuft bei mir irgendwie nicht rund. Oder kennt jemand ne gute Anlauf stelle um mit VS Studio direkt zu compilieren? - Bitte keine "nutz Google" Antworten. Aktuell habe ich das gefunden: https://marketplace.visualstudio.com/items?itemName=VisualMicro.ArduinoIDEforVisualStudio Was nutzt ihr denn? Vielen Dank und den neuen Code teste ich sobald ich heute wieder Zuhause bin. :) 1003 Einträge, Mensch haben wir ein neuen Rekord aufgestellt? :D
:
Bearbeitet durch User
Einen Link dazu kenne ich auch nicht. Bei mir klappt es mit der Arduino IDE 1.8.19 und - aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4) sowie den LIBRARIES - Time 1.6.1 - RF24 1.4.2 - PubSubClient 2.8 ohne Probleme. Gruß Günter
Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht. Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut werden kann? Hardware hätte ich alles schon da: Raspberry Pi, nRF24, ESP8266, Arduino-Nano. LG, Pocki
Hallo Christian P., leider gibt es noch keine klare Information zu den älteren MI-Modellen von Hoymiles. Es gab bereits einige Foristen mit einem MI- Wechselrichter, u.a. Ziyat T. mit einem MI-1500, Arnaldo G. mit zwei MI-1500 und Daniel B. mit einem MI-600, Daniel M. mit einem TSUN TSOL-M800 vermutlich ein re-brandeter MI-800 und jetzt Du mit einem MI-300. Leider haben wir bisher relativ wenig Informationen über das ältere MI-Protokoll. Ziyat. T. hat mal eine Auswertung in Excel als Screenshot MI1500data.png und DTUPro.log angehängt und Arnaldo G. hatte sehr zu Beginn dieses Threads seine nrf24.txt und nrf24_2.txt Ergebnisse vom mitsniffen ihrer DTU Pro bekannt gegeben. Vielleicht wollt Ihr auch mal ein Issue auf github aufmachen um den aktuellen Wissensstand zur MI-Serie zusammenzutragen. Da könnte dann z.B. Ziyat noch mal erklären wie er zu den Ergebnissen bei seiner Auswertung gekommen ist. M.E. sah das was die Spannung und sonstigen Werte angeht schon sehr vielversprechend aus ... Das fehlende Glied sind die Aufforderungen zum Tanz die die DTU-Pro den MI-Wechselrichter schickt. Hier müsste man am besten und einfachsten an den RX/TX Testpunkten in der DTUPro den Verkehr mit einem Logic Analyzer mitschneiden. Anleitung für eine DTU-Lite hatte martin (Gast) hier bereits geliefert: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Du kannst auch einfach nochmal auf der Single Page Ansicht nach "MI-", "MI1500", "Salea" etc. suchen. Ziyat & Arnaldo, do you have an Logic Analyzer at hand or would you get one for a dozen bucks to make those traces ? I have given you a short summary for the Software Decoding / Analysis under Linux in a recent post, where I documented my approach to successfully decode the files DTU_Captures.zip from martin: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
@Ziyat & Arnaldo, I believe Sigrok / Pulseview may be even able to read raw data from Raspberry Pis GPIO pins, just in case you do not have a Logic Analyzer at hand. Read here for two projects with the same goal and helpful input on how to best secure the GPIO Pins against overvoltage / current. https://github.com/superzerg/logic-analyzer https://github.com/richardghirst/Panalyzer
Christian P. schrieb: > Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht. > Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut > werden kann? Hallo Christian P. und @isnoAhoy Bisher funktionieren alle SW-Versionen nur mit der HM-Serie, MI-Serie werden (imho) nicht unterstützt. Meine Motivation um den MI zu analysieren (zur Zeit) ziemlich klein geworden: - Hoylimoly hat die Produktion der MI's abgestellt - Die MI's als 2.gen haben wenige Funktionen, vor allem man kann sie nicht unter 10% limitieren, das passt mir überhaupt nicht (zero import? wenn kein load) - MI-Ports können nicht einzeln limitiert oder ein/ausgeschaltet werden Ich habe bisher durch meine DTU-Pro Hilfe (wenn sie eingeschaltet ist konnte ich die WR-RF-Messages mitlesen) alle Werte in MI-Messages entschlüsseln, den MI konnte nicht ansprechen, bisher das ist alles. Ich werde weiter machen wenn ich den HM bekomme, sorry.
Ja, ist nachvollziehbar. Die MI Serie ist schwierig zu knacken. Ich habe mich soweit durch die 1000+ Postings gearbeitet, speziell die Logfiles nrf24.txt bis hin zu nrf24_5.txt und weitere. Scheint als fehle noch das initiale Aktivierungskommando der DTU. Schon versucht, die DTU abzustecken, abzuwarten bis die Inverter verstummen und dann beim Wiedereinschalten der DTU dessen Init-Kommando zu erwischen? Eventuell ist genau der setTime-Command der Key? Ich kämpfe noch, um Raspi, nrf24-modul, esp8266, nano und die Software zum Laufen zu bringen. Hoffe ich habe das bald bei'nander.
Hallo Lukas P. warum ist in hmRadio.h eigentlich Kanal 40 nicht als Receive Channel mit angegeben ?
1 | #define RX_CHANNELS 5 |
2 | ... |
3 | // Depending on the program, the module can work on 2403, 2423, 2440, 2461 or 2475MHz. |
4 | // Channel List 2403, 2423, 2440, 2461, 2475MHz |
5 | mRxChLst[0] = 03; |
6 | mRxChLst[1] = 23; |
7 | mRxChLst[2] = 40; |
8 | mRxChLst[3] = 61; |
9 | mRxChLst[4] = 75; |
10 | ... |
11 | uint8_t getRxNxtChannel(void) {
|
12 | if(++mRxChIdx >= RX_CHANNELS) |
13 | ... |
14 | uint8_t mRxChLst[RX_CHANNELS]; |
würde das um den Kanal 40 erweitern. laut FCC Dokumentation soll das nRF Modul ja auf allen fünf Kanälen funktionieren. @Christian P., Ziyat T., etc. mit der o.g. Erweiterung könnte man ggf. auch seine DTU als "Dummy"-Wechselrichter eintragen, also DTU Serien Nummer stattdessen mit führender 1121, 1141 oder 1161 eingeben. Er würde dann zwar auch versuchen der DTU die bekannten Status/setTime-Kommandos zu schicken, aber gleichzeitig müsste er auch alles was von der DTU kommt als Received bytes channel XX im Serial Monitor ausgeben.
Ich selbst habe leider keine DTU, und plane auch nicht eine zu kaufen. Ich fürchte es wird nötig sein, dass ein DTU-User einen MI-WR aus seinem Setup entfernt (de-registriert) und neu einrichtet/registriert. Und am besten BEIDES mitschneiden :-)
:
Bearbeitet durch User
Die Benutzeranleitung der DTU-Pro App erwähnt eine Funktion zur automatischen Erkennung naher Microinverter: https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf Seite 16: >3. You can add microinverter via “Automatic Search” or typing in... >4. The search result of microinverters and microinverter added will be displayed Die Screenshots wurden mit Inverter-Seriennummern 1121xxxxxxxx gemacht, also vermutlich MI-Serie. Könnte jemand mit einer DTU und dieser App das mal ausprobieren und ggf. den nrf24-Traffic versuchen einzufangen?
Hi Pocki, ui das klingt ja mal Interessant. Wenn es tatsächlich klappen sollte, könnte man das als Feature mit einbauen um einfacher die WR zu hinterlegen. Sehr cool, glaub ich sollte auch mal das ganze Handbuch studieren. 😅
Wenn Ihr schon mit solchen guten Vorschlaegen kommt, bitte liest Ihr das HB (https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf ) nochmals schön durch:-) Es handelt sich um DTU-Pro-S Microinverter Compatibility Microinverter model HMS series, HMT series
Hm, stimmt allerdings. Ich erinnere mich Ende 2020 an ein Handbuch mit Screenshots zur DTUlite von schlecht designten HTML-Seiten zur Einrichtung der WR. Und da gab es auch einen "search"-Button. Und das war zu Zeiten bevor es die HM-Serie gab.
:
Bearbeitet durch User
Hallo martin (Gast) & Christian P., das sieht in der Tat interessant aus. Die Funktion scheint es auch in der DTU-Lite-S zu geben. Ich weiß natürlich nicht ob es das nur in der -S Version und/oder auch in der WLite Version gibt ? User Manual_DTU-Lite-S_Global_EN_V202202 https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_DTU-Lite-S_Global_EN_V202202.pdf > 3. You can click "Automatic Search" to add microinverter, > or you can type in / scan the microinverter ID. @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic Analyzer ausprobieren und mitschneiden ?
Mal eine blöde Frage zwischendurch: Wenn ich versuche aus der Arduino-IDE meinen Wemos D1 Mini zu flashen, rennt er in eine Boot-Loop und kommt nicht. Ich möchte nicht ausschließen, dass ich falsche Einstellungen habe, kann mir jemand die richtigen geben? Auch könnte der Flash mittlerweile hinüber sein, was ich auch nicht ausschließen kann. Ich nutze aktuell Arduino 1.8.19 und habe es mit der ahoy-Version 0.4.13 von Github probiert. Mit etwas Überzeugungshilfe habe ich esptool 3.3 dann dazu bekommen, das bin-file direkt zu flashen und es klappte nach einigen Schwierigkeiten. Danach wäre ein kurzer Exkurs in das Programm interessant, an welchen Stellen die Adressen und Befehle zusammengebaut werden. Würde mich da mal mit den Anpassungen auf den TSUN beschäftigen und schauen, was ich mit meiner Unkenntniss hinbekomme. Dankeschön :) Edit: ein neuer Git Pull hat geholfen, habe noch eine Vorversion mit dem Bug drin gehabt. Die Einstellungen mal vergleichen wäre trotzdem Hilfreich.
:
Bearbeitet durch User
isnoAhoy schrieb: > @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic > Analyzer ausprobieren und mitschneiden ? Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.
martin schrieb: > isnoAhoy schrieb: >> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic >> Analyzer ausprobieren und mitschneiden ? > > Ja, das kann ich heute Abend oder morgen Nachmittag mal testen. Das wäre ganz super :-) Ich habe inzwischen mein Klump zusammen und kann gleichzeitig nrf24 sniffen (noise wird über crc-check verworfen) und auch custom-payloads senden :-) Sobald ich also einen Anhaltspunkt bekomme, an welche Destination-Adresse mit welchem Payload man Pakete senden könnte, kann ich starten.
Ich habe von meinem MI-300 nun geschafft Antworten zu empfangen, wenngleich auch noch keine nutzbaren Daten: Anfrage via nrf24 (on-air):
1 | Address 1319406101 Data 15 77665544 88776655 81 58 |
2 | WR-rev mid DTU dummy cmd crc |
Antwort vom WR (on-air):
1 | Address 4455667701 Data 15 77665544 61401913 81 bf |
2 | DTU-rev mid DTU WR cmd crc |
Nach ein bisserl Herumspielen stelle ich fest: 1) Der WR antwortet an die Adresse, welche in der Anfrage-Payload bytes 2,3,4,5 steht, reversed und mit 0x01 ergänzt. hier also 77665544 liefert die WR-Antwort an die Adresse 4455667701 2) Die Felder WR und DTU sind somit vertauscht (hinter dem MID): zuerst kommt die DTU (an welche der WR seine Antwort senden soll), und dann der WR. 3) Die Länge der Antwort ist immer gleich lange wie die Länge der Anfrage. Keine der bekannten Anfragen (MID 0x07, 0x15 und CMDs 0x00, 0x80 bis 0x83) liefern brauchbare Payload retour: es kommt immer nur genau das zurück, was in der Anfrage gesendet wurde. Einziger Unterschied ist die S/N des WR (bei mir 61401913) und dann natürlich die 8bit payload-crc. So, und was nun? :-) Ideen willkommen
:
Bearbeitet durch User
Hmm, interessant... Ich hätte die Idee das man die MID inkrementiert und darauf lauscht. 0x00 bis 0xFF sind 255 steps. Wie lang dauert das Senden + Empfangen + Delay? 1sek.? Dann hätte man nach 255sek. wenigsten die Info ob bei allen MIDs die gleiche Antwort zurück kommt. Oder was meint ihr?
Ok, rennt schon. Leider nicht so simpel, weil der WR nicht bei jeder Sendung antwortet. Ich vermute, das liegt am Channelhopping des WR: der scannt umher auf den Kanälen. Ich sende und sniffe aber nur Channel 0x03, daher kann es sein, dass ich ein Paket 5-10x senden muss, um eine Antwort zu bekommen. Ein erster Durchlauf bestätigt das. Was ich schon mal sagen kann: Pakete mit MID größer als 0x80 werden nicht beantwortet. Auch MID=0x00 bleibt stumm. Ich lasse mal laufen für MID=0x00-0xFF und CMD=0x00-0xFF folgende Payloads jeweils 4x mit 15 retransmissions :-)
1 | MID+ dtu + wr +CMD+crc |
2 | zb 07 77665544 61401913 81 aa |
Werde berichten... Hoffentlich zerschiesse ich mir den WR damit nicht
Hmm, soviele retransmissions macht doch kein Sinn? Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu schalten, damit man mehrere Kanäle sich anhört. Apropo Channel hopping, irgendwo muss doch eine Komunikation stattfinden das beide, WR + DTU, im selben Channel zuhören/reden. Oder? Gerade gefunden: https://hackaday.com/2017/03/21/ask-hackaday-frequency-hopping-on-the-nrf24l01/ https://paulplusx.wordpress.com/2017/03/19/frequency-hopping-with-nrf24l01/
:
Bearbeitet durch User
Daniel R. schrieb: > Hmm, soviele retransmissions macht doch kein Sinn? > > Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu > schalten, damit man mehrere Kanäle sich anhört. Ich habe 2 NRF-Module: eines am GPIO eines Raspberry zum Versenden und eines an einem Arduino-Nano zum Sniffen. Der liefert via serial an den gleichen Raspi ab, wo ich dann auf die Empfängeradresse filtere. Die 15 Retramsmissions alle 250µs sind im Python-Initscript fix drinnen, habe es nicht geschafft das zu reduzieren. Die macht er, weil der WR ja kein ACK sendet. Das 4x-Senden in 500ms Abständen loope ich bewusst, damit ich sicher gehen kann, dass es der WR auch gehört hat und nicht antworten will. Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch. Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen, also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende. Hoffe nur wir können dann etwas beobachten.
Alles klar, danke für die Arbeit. Wichtig natührlich alles fleißig zu loggen... :D
Ich bin noch skeptisch, ob uns das weiterbringt. Bis jetzt habe ich ausnahmslos nur "gespiegelte" Antworten gesehen, also egal welcher MID oder CMD: es kam immer genau die selbe Nachricht retour, nur mit der anderen Seriennummer. Sonst: gleicher Inhalt, gleiche Länge. Kann also sein, dass wir ohne Kenntniss des *echten Einrichtungs-Dialogs* zwischen einer DTU und einem MI-WR nicht weiterkommen.
Christian P. schrieb: >> isnoAhoy schrieb: >>> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic >>> Analyzer ausprobieren und mitschneiden ? >> >> Ja, das kann ich heute Abend oder morgen Nachmittag mal testen. Hallo, ich konnte zwischenzeitlich mal ein paar Captures aufnehmen. In Capture0 und 1 habe ich mich per App mit der DTU verbunden (die baut ja ihr eigenes WLAN auf) und dann auf "Inverter Hinzufügen und Automatische Suche" geklickt. In Capture2 habe ich mal die Echtzeitdatenabfrage laufen lassen (Zeigt die Istwerte auf dem Inverter). Habe heute leider keine Zeit mehr, die Daten aufzubereiten, daher die Rohausgabe als .txt und die Logic-Captures direkt mit im Anhang, für eure eigenen Analysen (Saleae Logic-Software kann man kostenlos runterladen und die Captures öffnen). Zur Info nochmal: Inverter 1141 72220200 DTU Lite 10D9 72818832
Danke, mir fällt insbesonders alles ausser mid=15 und =95 auf auf: capture_1.txt 7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 0a,8d,7f 7e,81,72,81,88,32,72,81,88,32,00,81,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,81,72,81,88,32,72,81,88,32,01,80,7f 7e,06,72,22,02,00,72,22,02,00,00,06,7f 7e,06,72,22,02,00,72,22,02,00,00,06,7f 7e,01,72,81,88,32,72,81,88,32,00,01,7f 7e,01,72,81,88,32,72,81,88,32,01,00,7f 7e,02,72,22,02,00,72,22,02,00,00,02,7f Verstehe ich das korrekt: das sind die Daten von "on-wire" zwischen dem Onboard-Chip und dem NRF24-Modul der DTU? Weil: leider kann man da nicht klar herauslesen, an selche destination-address das nrf24-paket dann geschickt wird. Oder?
Christian P. schrieb: > das sind die Daten von "on-wire" zwischen dem > Onboard-Chip und dem NRF24-Modul der DTU? Ja genau, auf der UART zwischen GD32 und NRF24. Um die Richtung zu erkennen habe ich die Saleae-Files mit hochgeladen. Dort kann man anhand des Kanals erkennen, ob es der DTU-Controller an den NRF schickt (sprich: die DTU an den Inverter) oder ob es vom Inverter zurückkommt.
Christian P. schrieb: > Daniel R. schrieb: ..... > Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch. > Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen, > also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende. > Hoffe nur wir können dann etwas beobachten. Habe schon vor 2 Monaten ausprobiert, bei mir kam nichts... Ich habe mehrere logs vom MI1500 hier veröffentlicht
Christian P., ja die Salea Captures haben noch en 0x7e Prefix und Postfix 0x7f vor/nach den uns sonst geläufigen Nachrichten / Paketen. 7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 0a,8d,7f ist also eigentlich MID=0x86 Destination=72220200 Source/DTU=72220200 Paket/CMD=0x02 Payload=11,41,72,22,02,00,00,b0,00,00,00,b0,01,0a CRC8=0x8d Ich sehe da also zwei Addressen: * 72220200 * 72818832 Vielleicht sind die im capture1.txt genannten Adressen ja so eine Art Broadcast Adresse für die jeweiligen Modellreihen ? Interessant dürften für die MI Wechselrichter in der Tat die MIDs außer 0x15 und 0x95 der HM Baureihen sein: Speziell 0xc2 und 0x06 stechen mir ins Auge, ich meine so etwas auch in Ziyat T. bzw. Arnaldos Logfiles bereits gesehen zu haben.
Hallo martin (Gast), Danke für die Aufnahmen! Hast Du die Aufnahmen während des Tages gemacht, d.h. dabei war ein WR anwesend und hat geantwortet. Interessant wäre ja auch das Verhalten der DTU in einer abgeschirmten Umgebung. Hier sollte die DTU ja prinzipiell einmal alle Discovery Optionen ausspielen, die ggf. auch eine MI-Wechselrichter interessieren könnten. In der Payload steht ja eine HM-600/700/800 Serien Nummer: 114172220200 Damit hat die DTU wohl einen jungen Fisch gefangen ?
Noch eine (Broadcast) Adresse 10,d9,42,7f ? grep '^7e' capture0.txt | less /(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83) bzw. grep '^7e' capture0.txt | grep -v '72,22,02,00' | less /(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83) um den ganzen Smalltalk mit 114172220200 auszufiltern ergibt: 7e,81,72,81,88,32,72,81,88,32,00,81,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,81,72,81,88,32,72,81,88,32,01,80,7f 7e,01,72,81,88,32,72,81,88,32,00,01,7f 7e,01,72,81,88,32,72,81,88,32,01,00,7f
Hallo im Anhang sind die wireshark logs zwischen DTU-Pro und MI1500 mit versch. channels. Hatte sie mit NRF24_Sniff von Ivo Pullens generiert. Adr:1284..DTU, 6071..MI, Adr sind verkehrt! z.Bsp: im NRF24_Sniff die DTU Adresse eingegeben, auf CH3, das ist die Antwort vom WR, ist von mir entschlüsselt, siehe früheren Beitrag: ch3-2-12842272.pcapng b6:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 05:05:b1 b8:63:70:71:60:63:70:71:60:01:bb:00:0c:09:86:13:87:02:23:01:da:01:16:03: 00:01:fa b7:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 05:05:b0 b9:63:70:71:60:63:70:71:60:01:bb:00:06:09:85:13:87:01:2b:01:3f:01:16:03: 00:01:1c im NRF24_Sniff die WR Adresse eingegeben, auf CH23: ch23-60717063.pcapng 51:63:70:71:60:72:22:84:12:5a:5a:1a:8f 51:63:70:71:60:72:22:84:12:5a:5a:1a:8f 51:63:70:71:60:72:22:84:12:5a:5a:0b:9e 36:63:70:71:60:72:22:84:12:00:f2 37:63:70:71:60:72:22:84:12:00:f3 38:63:70:71:60:72:22:84:12:00:fc 39:63:70:71:60:72:22:84:12:00:fd Villeicht hilfts euch weiter.
:
Bearbeitet durch User
Ich habe heute mal die c2 und 81 er Payloads bei mir in die Luft geworfen und von meinem HM600 keine Reaktion bekommen. Die Frage ist natürlich, ob die Dinge wirklich on-air gehen oder nur setup-commands an das NRF-Modul sind? Christian P. schrieb: > MID+ dtu + wr +CMD+crc > zb 07 77665544 61401913 81 aa Damit hast Du ja nur ein Re-Transmit angefordert(?). So einfach ist das nicht mit durch iterieren, weil viele Anfragen einfach eine definierte payload mit Parametern erwarten. Interessant ist eigentlich nach jedem Kommando mal ein 80 11 abzufragen (event log). Das wird bestimmt überlaufen mit a_code=2, was ich denke wird soviel sagen wie Software-Fehler, Parameter-Fehler oder Kommunikationsfehler (Spekulation) Leider scheint im Dump auch die Anfrage auf die Antwort mit der Seriennummer zu fehlen.
:
Bearbeitet durch User
Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das Shockburst-Frame des nrf24-Protololls gesendet wird? Wenn die Daten ein Dump aus der internen DTU-Schnittstelle zum nrf24-Modul sind, zeigen die ja nur (?) den Payload oder? Oder steuert das erste Feld (MID) das Verhalten des nrf24 hinsichtlich Destination-Adresse/Adresslänge/ShockburstOnOff? Hat sonst noch jemand captures von on-air Daten?
Hallo Hubi(Gast)
Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme
aber beim kompilieren folgende Fehlermeldung:
In file included from
/home/papalapap/Arduino/HoyDtuSim/HoyDtuSim.ino:86:
/home/papalapap/Arduino/HoyDtuSim/ModWebserver.h: In function 'void
handleRoot()':
ModWebserver.h:55:33: error: 'getSerialNoTxt' was not declared in this
scope
55 | out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";
| ^~~~~~~~~~~~~~
exit status 1
'getSerialNoTxt' was not declared in this scope
Vielleicht sagt dir die Fehlermeldung in der ModWebserver.h etwas.
Wünsche frohe Pfingsten
Arduino: 1.8.19 (Linux), Board: "LOLIN(WEMOS) D1 R2 & mini, 160 MHz,
Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most
compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for
IRAM/PROGMEM, 4MB (FS:1MB OTA:~1019KB), v2 Lower Memory, Serial, None,
All Flash Contents, 921600"
DTU-Pro <-> MI1500 logs WR -> DTU ---------- len } 2a: hdr } 2c:67:b7:0f:00:63:70:71:60: 63:70:71:60: data} 01:b2:00:0f:09:22:13:89:02:77:01:02:01:b7:03:00:03:74:48:9e:3e:aa:77:de: ab:ec:b6:a6:40: U DC I DC U AC Hz AC P DC C 1 b2 0 0f 9 22 13 89 2 77 1 2 1 b7 DTU -> WR --------- 16: d4:cf:21:0f:00:63:70:71:60: 72:22:84:12:5a:5a:1b:8e:ee:12:3d:b6:08
Christian P. schrieb: > Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das > Shockburst-Frame des nrf24-Protololls gesendet wird? Die Richtung kann man nicht erkennen. Aus beobachtungen weiß ich bisher, dass 0x15 dtu->wr und 0x95 die Antwort vom wr ist. Oder man kennt die Adressen seiner Geräte. 7e,7f markiert start und ende der spi-kommunikation in der dtu. Das geht nicht on-air. 0xc2 und 0x81 sind neu für mich und enthalten z.T. keinen gewöhnlichen ESB-Aufbau. Vermutlich könnte es also sein, dass die dtu da den nrf-chip konfiguriert oder status register abfragt. (Spekulation) Könnte aber auch genauso gut sein, dass 0xc2 Übertragungsart ist, broadcast vs. 0x15 unicast?
ich habe meinen HM-400 heute endlich in Betrieb nehmen können. Der WR läuft und produziert auch,aber ich bekomme mit meinem WemosD1 und dem NRF Modul leider keinerlei Rückemeldungen vom WR. Uptime: 0 Tage, 00:54:20 Time: 2022-06-05 14:09:30 Statistics: Receive success: 0 Receive fail: 652 Send Cnt: 1304 Free Heap: 0x98c8 Inverter 'HM-400' is not available and is not producing MQTT: connected Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu haben. im seriellen log steht folgendes: Free heap: 0x9fb0 Inverter #0 no Payload received! Requesting Inverter SN 1121xxxxxxxx Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 05 00 00 00 00 B0 39 B9 Error while retrieving data: last frame missing: Request Retransmit Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 05 00 00 00 00 B0 39 B9 Free heap: 0x9fb0 Inverter #0 no Payload received! Requesting Inverter SN 1121xxxxxxxx Version nutze ich die aktuelle 0.4.15
Hast Du einen Kondensator an VCC vom NRF-Modul? Wichtig. Manchmal hilft, die Sendeleistung von der "DTU" zu ändern. Habe das schon gehabt, dass WR nicht antworten, wenn man die zu laut fragt. Auch die Ausrichtung der Antenne kann Wunder wirken.
ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe ich auch alle low, min, high und max probiert. genauso wie die entfernung zwischen paar cm und einigen metern geändert wurde
Mehr DTU-Pro <-> MI1500 logs Diesmal WR ist stumm, weil Nacht, DTU-Pro neu gestartet
Tobi D. schrieb: > Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die > Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu > haben. Seriennummer muss so eingetragen werden, wie sie auf dem Aufkleber zu lesen ist. Hast du mal mit der Ausrichtung der Antenne gespielt? Stimmt dein Pinout, vor allem der IRQ Pin darf nicht auf GPIO16 liegen?
Friedhelm E. schrieb: > Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme > aber beim kompilieren folgende Fehlermeldung: > In file included from Hallo Friedhelm hol dir die neueste Version von [[https://github.com/hm-soft/Hoymiles-DTU-Simulation]], das sollte klappen
Tobi D. schrieb: > ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe > ich auch alle low, min, high und max probiert. Viele der NRF-Module haben geclonte Chips, manche funktionieren besser, manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne auf der Platine bestellt, die funktionieren problemlos. rosch99
Der Tip mit den Modulen mit Antenne, die irgendwie nicht so ganz laufen, war gut. Ardunio-Konsole:
1 | 14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB |
2 | 14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB |
3 | 14:40:00.684 -> Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 4A 00 11 09 5F 13 85 02 2D 03 61 00 F2 AC |
4 | 14:42:57.596 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4 |
5 | 14:42:57.644 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4 |
Hauptsächlich jedoch kommt diese Meldung:
1 | 14:43:00.590 -> Error while retrieving data: last frame missing: Request Retransmit |
Das passiert fast immer, wenn vom WR eine Antwort eingeht. Raspi mit ahoy python-tool:
1 | 2022-06-06 14:43:06.908846 Received 24 bytes channel 23: 89 63 50 0b 16 e3 50 0b 16 81 4a 40 17 09 5b 53 88 82 dc 0b 64 80 f2 d3 |
2 | Error while retrieving data: max() arg is an empty sequence |
3 | |
4 | 2022-06-06 14:43:13.198405 Received 24 bytes channel 75: 8b 63 50 03 16 63 51 0b 56 95 5a 09 53 19 5b 33 8a 92 de 0b 6c 91 f6 d1 |
5 | Error while retrieving data: Frame 1 missing: Request Retransmit |
6 | |
7 | 2022-06-06 14:49:57.395157 Received 18 bytes channel 61: 88 63 50 03 16 63 50 13 16 00 03 00 80 08 01 00 03 89 |
8 | 2022-06-06 14:49:57.401382 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
9 | Error while retrieving data: Missing packet: Last packet 2 |
10 | |
11 | 2022-06-06 14:50:01.087613 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56 |
12 | 2022-06-06 14:50:01.098937 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56 |
13 | Error while retrieving data: Missing packet: Last packet 2 |
14 | |
15 | 2022-06-06 14:50:02.584152 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
16 | Error while retrieving data: Missing packet: Last packet 3 |
17 | |
18 | 2022-06-06 14:52:42.631804 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 13 86 01 c4 03 6d 00 f6 55 |
19 | 2022-06-06 14:52:42.643443 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 53 86 05 c5 03 6d 01 f6 55 |
20 | Error while retrieving data: Missing packet: Last packet 2 |
21 | |
22 | 2022-06-06 14:52:44.136428 Received 18 bytes channel 40: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
23 | Error while retrieving data: Missing packet: Last packet 3 |
24 | |
25 | 2022-06-06 14:52:46.298238 Received 24 bytes channel 75: 91 63 50 03 16 63 50 03 16 01 47 00 0e 09 58 13 86 01 c1 03 67 00 f6 4f |
26 | Error while retrieving data: Missing packet: Last packet 1 |
27 | |
28 | 2022-06-06 14:52:47.289513 Received 18 bytes channel 3: 94 63 50 02 16 63 50 02 16 00 03 00 00 00 00 00 00 91 |
29 | Error while retrieving data: Missing packet: Last packet 2 |
30 | |
31 | 2022-06-06 14:52:47.851089 Received 18 bytes channel 40: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 01 00 03 89 |
32 | Error while retrieving data: Missing packet: Last packet 3 |
33 | |
34 | 2022-06-06 14:56:22.534647 Received 18 bytes channel 3: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
Der Raspi empfängt etwas alle ca. 30s, wenn die DTU die Requests sendet. Den Tx hab ich rausgelassen, da wir wissen, dass mein WR nicht darauf reagiert. Ich hab aus dem Log von Raspi mal diese größeren Abschnitte mit nur Tx gelöscht. Ich bin mit Arduino und C++ nicht wirklich gut unterwegs und brauche Starthilfe, an welchen Stellen die Sendebefehle wie zusammengebaut werden. Mein Tsun hat 2 Kanäle, füge ich ihn über 1141 statt 1041 hinzu, funktioniert das schonmal :)
Das Python-Script wird damit auch nichts automatisch dekodieren können, weil für die Wahl des Dekoders die Anfrage ausschlaggebend ist, die python selbst abgesetzt hat. Du kannst höchstens manuell den Datenstrom aufzeichnen, zusammensetzen und einen Dekoder dafür in Python bauen und das dann copy&pasta mit bytes.fromhex() da durch schieben. Das geht tatsächlich sehr gut und man kann dann auch schön am Dekoder rum tweaken bis die Ergebnisse sinnvoll sind. Beispiele habe ich ja schonmal gepostet. Bis die gesamte Transaktion implementiert ist, wird das mit dem python-Script, automatisch, keine Daten dekodieren können ohne den Tx 1. zu haben und 2. sinnvoll verstanden zu haben. Also aus dem Tx muss man erkennen können welche Daten angefragt wurden. Theoretisch könnte die DTU ja auch gerade ein Firmware-Update hochladen. Die Fragmente der Transaktion kann man schon durch einen Status-Dekoder schieben, bekommt dann aber keine sinnvollen Werte. Der Dekoder wird schon dekodieren. Der kann nicht erkennen ob das sinnvoll ist oder nicht, oder ob er für die Daten die man ihm gibt überhaupt geeignet ist. Zumindest solange der buffer groß genug ist und man nicht in einen IndexError läuft. Du bekommst da zwar Daten aber ohne Kontext. Binärdaten ohne Kontext sind nicht mehr als Rauschen.
Hi Jan, aktuell zeichne ich einfach auf, was durch die Luft fliegt. Die Requests habe ich da, kann sie nur nicht senden, allerdings macht das, was ich so empfange Sinn zu dem, was ich in der DTU sehe. Die bytes kann ich soweit dekodieren und nachvollziehen, nutze das eher als sniffer, den ich bedienen kann. Dass ich mit dem Python-Script nicht viel weiter komme, ist mir klar :) Leider bin ich nicht so tief in der Programmierung drin, wie einige andere hier, so dass ich sehr froh bin, die Scripte soweit überhaupt hab starten können und ihnen was sinnvolles entlocken konnte. Primäres Ziel war erstmal: - funktionieren die NRF-Platinen? -> mit externer Antenne nicht, integriert ja - auf welchen Kanälen wird empfangen? -> 3, 23, 40, 61, 75 - ist das, was ich empfange, sinnvoll? -> weitestgehend ja - kriege ich es hin, mit dem D1 mini was zu sehen? -> nur zufällig, eher nein Beim rumschnüffeln in der Luft hab ich noch 2-4 byte lange Antworten gesehen sowie solche Konstrukte:
1 | channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d fa 01 3a 33 |
2 | channel 40: b2 6b 50 03 16 63 50 07 16 00 03 00 00 02 00 20 02 91 |
3 | channel 23: a8 6b 50 03 36 63 50 03 16 00 13 00 00 0a d7 26 af bb |
4 | channel 3: a9 63 50 03 16 63 50 07 16 01 35 00 04 09 4a 13 8a 00 8e 85 03 01 3a d0 |
5 | channel 3: b2 63 50 03 36 63 50 03 16 00 13 01 00 00 00 80 08 93 c3 93 3a aa |
6 | channel 3: 94 63 50 03 16 63 50 03 14 00 43 00 00 00 10 00 01 91 |
7 | channel 3: 8b 63 50 03 16 63 51 03 16 01 2e 00 02 09 51 13 8e 80 51 05 04 01 2b 1b |
Was es damit aufsich hat, schau ich mir später noch an, da es wiederkehrende Muster aller paar Minuten sind. Ohne Hilfe beim Code werd ich aber nicht viel machen können, da mir einfach die Grundlagen fehlen. Ich komme aus dem Dickstrombereich, das hier ist Hobby ;) Deine Beispiele sehen gut aus, hab die versucht und bin (erstmal) gescheitert. Ich werd meine Freundin mal fragen, ob die damit weiter kommt. Wird aber etwas dauern. Trotzdem danke für den Ansatz, mit Geduld wirds werden :)
Ich hab gerade nochmal ein PR für python auf gemacht. Habe den DebugDecodeAny Dekoder nochmal überarbeitet. Beispiel: (auf der Kommandozeile)
1 | tools/rpi$ python3 -c 'import hoymiles; hoymiles.decoders.DebugDecodeAny(bytes.fromhex("5c 00 00 b4 91 00 00 ab bf 03 71 03 78"))'
|
2 | payload has 13 bytes |
3 | |
4 | Field view: int |
5 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
6 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
7 | >B 92 0 0 180 145 0 0 171 191 3 113 3 120 |
8 | |
9 | Field view: shorts |
10 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
11 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
12 | >H 23552 180 37120 171 48899 28931 |
13 | >H 0 46225 0 43967 881 888 |
14 | |
15 | Field view: longs |
16 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
17 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
18 | >L 1543504052 2432696491 3204673795 |
19 | >L 46225 43967 57738104 |
20 | >L 11833600 11255555 |
21 | >L 3029401600 2881422193 |
22 | type utf-8 : utf-8 decode error |
23 | type ascii : ascii decode error |
*payload gekürzt, weil dieses dämliche Forum Zeilenumbrüche in Code, und damit Leserlichkeit kaputt macht. Würde die komplette Payload in die DebugDecodeAny-Klasse gepastet werden würde es uns noch sagen, dass sich um die Payload eine valide Modbus CRC (oder CRC8) befindet. Referenz:
1 | 2022-05-10 11:39:49.447628 Payload: 00 01 01 35 03 a8 0b 4a 01 37 03 aa 0b 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 09 08 13 87 15 a1 00 00 00 ef 03 e8 01 ef 00 06 99 3a |
2 | 2022-05-10 11:39:49.447628 Decoded: 49.5 phase0=voltage:231.2, current:23.9, power:553.7, frequency:49.99 string0=voltage:30.9, current:9.36, power:289.0, total:46.225, daily:881 string1=voltage:31.1, current:9.38, power:290.8, total:43.967, daily:888 |
Wir finden aber Zahlen wieder und sehen schön an welcher Position in den Hex-Daten die stehen. Meiner Meinung nach sind in den tsun-Daten viele korrupte Pakete mit Bitfehlern drin. Die Payload CRC8 stimmt oft nicht. Manchmal auch offensichtlich durch korrumpierte Adresse. Nicht, dass wir da jetzt Unsinn lernen. Grundsätzlich würde ich das auf der Luft-Schnittstelle aber erwarten, da wir das Protokoll nicht implementiert haben.
@Daniel M. schrieb: @Jan-Jonas S > Hi Jan, > > aktuell zeichne ich einfach auf, was durch die Luft fliegt. Hallo Die Antwort channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d fa 01 3a 33 Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert. D.h. dieser TSUN ist ein MI? Konntest du schon einen request schicken und TSUN hat geantwortet?
Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu bekommen. Wie habt ihr das gemacht (ohne eine DTU)?
Christian P. schrieb: > Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu > bekommen. Wie habt ihr das gemacht (ohne eine DTU)? Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine Logs v. früher. Ich sehe die WR-Antworten nur wenn meine DTU-Pro die request schickt. Ich glaube, ich habe alle logs zusammen, WR-Antworten decodiert aber wie die request funktioniert hab nicht rausgefunden.
Ziyat T. schrieb: > Christian P. schrieb: >> Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu >> bekommen. Wie habt ihr das gemacht (ohne eine DTU)? > > Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine > Logs v. früher. Ja das las ich, ist also immer noch stand der Dinge wie es scheint :( Ich bin nur auf Funk-Ebene unterwegs, also versuche die Messages einer DTU mit einem nrf24-Modul nachzumachen, um die Funk-Antworten meines WR zu erhalten. Dabei fiel mir auf: Der WR antwortet NUR, wenn das nrf-paket im Funkheader die Zieladresse des WR hat (also SN=102161401913 -> Zieladresse 13:19:40:61:01 mit Länge 5). Das wäre die Unicast-Variante. Ich konnte keine Broadcast-Empfangsadresse für den WR hier im Forum bislang ausmachen, auch nicht anhand der jüngsten Logs zu "automatische Suche". Sowas könnte eine 2-5 bytige Addresse sein, auf die jeder WR in der zweiten Pipe lauscht. Außerdem: Die bekannten Payloads dokumentieren immer nach dem MID die S/N der DTU und danach die S/N des WR. Bei mir ist das umgekehrt! Der WR antwortet auf die Anfragen immer an jene Adresse, welche der ERSTEN S/N in der Payload entspricht. Das würde für mich bedeuten: die erste S/N der Payload sollte die DTU sein, an die deer WR seine Antwort adressiert. Die bislang dokumentierte Payload stellt aber als erstes die S/N des WR dar, und erst danach die S/N der DTU. Kann das jemand bestätigen?
Also so:
1 | python3 py-nrf24/send.py --crc 1 1319406101 15776655446140191381 |
2 | ..sendet die payload 15776655446140191381+crc8 an 13:.19:40:61:01 |
3 | 77665544 ist die erfundene SN meines Raspi |
4 | 61401913 ist die echte SN meines WR. |
5 | |
6 | Sent: to Address 1319406101 Data 15 77665544 88776655 81 58 |
7 | Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf |
8 | |
9 | Das geht auch ohne der S/N des WR in der Anfrage |
10 | python3 py-nrf24/send.py --crc 1 1319406101 15776655440000000081 |
11 | |
12 | Sent: to Address 1319406101 Data 15 77665544 00000000 81 94 |
13 | Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf |
Ergo: 1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed, 0x01 als 5. byte). 2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5, reveresed mit 0x01 ergänzt 3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload 4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 und 0x7f beginnen.
:
Bearbeitet durch User
Habe was neues gefunden:
1 | nrf24-dest pcf payload |
2 | anfrage: 13 19 40 61 01 (16/0/0) df 02 00 776655441111111100fcaf85 0b |
3 | antwort: 13 19 40 61 01 (16/3/0) df 02 00 776661401913111100fcaf85 31 |
der Payload-Anfang df0200 bewirkt, dass der WR die Antwort-Adresse irgendwie ändert. Hier am Beispiel sendet er nicht an die DTU laut SN in den bytes 2.. retour, sondern an sich selbst?! Nachgefolgde MDI=15 anfragen werden ebenfalls an diese Andresse dann beantwortet. Ich hoffe ich habe mir nun nichts zerschossen. Scheinbar aber bewirkt der PRefix df0200 aber mal was anderes als nur MID=15.
rosch99 schrieb: > Tobi D. schrieb: >> ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe >> ich auch alle low, min, high und max probiert. > > Viele der NRF-Module haben geclonte Chips, manche funktionieren besser, > manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit > ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht > funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne > auf der Platine bestellt, die funktionieren problemlos. > > rosch99 hab mir jetzt auch noch ein nrf modul bei az del. ohne externe antenne bestellt, leider auch keine besserung
Christian P. schrieb: > 1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed, > 0x01 als 5. byte). > 2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5, > reveresed mit 0x01 ergänzt > 3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload > 4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 > und 0x7f beginnen. interresant, bei mir sieht es ganz anders aus..
Ziyat T. schrieb: > interresant, bei mir sieht es ganz anders aus.. naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit Schluss sind. Ich habe inzwischen folgendes nachstellen können.
1 | sende 15:77665544:22222222:80 an WR |
2 | empfange 15:77665544:61401913:80 als Antwort an Adresse 44:55:66:77:01 |
3 | 10sek pause |
4 | sende df0200:7766 55443333 3333:00 an WR |
5 | empange df0200:7766:61401913:333300 als Antwort an Adresse 22:22:22:22 |
Bei der ersten Nachricht setze ich im WR eine DTU-Adresse, die sich der WR merkt. Bei der zweiten Nachricht verwendet der WR die DTU-Adresse von zuvor und überschriebt nur die Bytes 4..7 mit der eigenen SN. > Christian P. schrieb: >>4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 >> und 0x7f beginnen. ich revidiere, punkt 4 stimmt nicht
Christian P. schrieb: > Ziyat T. schrieb: >> interresant, bei mir sieht es ganz anders aus.. > > naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit > Schluss sind. Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du? Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die gleiche SW verwenden würden, kommen wir ev. besser vorwaerts.
Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ und CE zu tauschen.
@Tobi B.
Beschreibe mal Deine Schaltung bzw. Überprüfe ob es evtl wie von Olaf
geschrieben am IRQ Eingang liegt. Nicht alle Pins am ESP sind
Interruptfähig.
Laut Deinem Log hat Dein HM-400 folgende Seriennummer:
> Inverter SN 1121xxxxxxxx Transmit 27 | 15 80 13 52 94
112180135294 stimmt das ?
Ich sehe in Deinem „kurzen“ Log nämlich nur TX aber kein einziges RX
Paket. D.h. dein ESP und nRF24 scheinen zu senden, aber der HM-400 fühlt
sich offenbar nicht angesprochen.
Alternativ kannst Du gerne auch mal ein längeres Log anhängen,
vielleicht sieht man da mehr. Nach dem Booten sollte der ESP auch einen
Block mit den nRF24 Settings ausgeben, etc pp.
@Daniel M. und Freundin, Ziyat T., Das sieht doch schon ganz vielversprechend aus. Ich meine auch das mit den „reversed“ 5 Byte (das letzte 01) bei der MI- Baureihe am Anfang des Threads gelesen zu haben. Habe mich immer gewundert, dass die HM- Baureihe die Seriennummer in der richtigen Reihenfolge und mit nur 4 Byte annimmt. Da scheint es wohl einen Unterschied zu geben. Viel Erfolg weiterhin!
Olaf A. schrieb: > Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ > und CE zu tauschen. das hats gebracht, vielen dank für den tipp :)
Ziyat T. schrieb: > Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die > Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du? > Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die > gleiche SW verwenden würden, kommen wir ev. besser vorwaerts. Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+ modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit sehe ich alle pakete (inkl. der destination adresse). Quelle des sketch kann ich nimmer sagen: habe ich Sept. 2020 organisiert, Author ist J. Coliz inspired by cpixip. Diesen Sketch habe ich etwas modifiziert, damit das 9bit PCF als 3 dezimale angezeigt wird und alles danach um das 1 Bit verschoben ist: so kann man viel leichter die Payload erkennen. Ergänzend habe ich ein Skript gebaut, dass die CRC des nrf24-Pakets prüft, so kann ich leichter die Noise aus dem gesnifften Kauderwelsch rausfiltern und es bleiben nur "echte" Pakete übrig. Zum Senden nutze ich einen Raspberry Pi 2B mit einem nrf24+ Modul an den GPIO Pins. Software ist von https://github.com/bjarne-hansen/py-nrf24 mit kleinen Modifikationen, um z.B. einen crc8 automatisch anzufügen. Ich sende und sniffe nur auf CH 0x03.
Hallo zusammen, ich bin aktuell ein stiller leser geworden. Habe aber folgende Infos mitbekommen (speziell für die MI-WR) und denke das es hier noch nicht im Forum diskutiert wurde? In dieser PDF Seite 8, sieht man die ältere Generation der DTU. https://cdn.webshopapp.com/shops/296982/files/328732372/mi-500-mi-600-mi-700-microinverter-user-manual-rev.pdf Das müsste genauer gesagt diese DTU sein: https://loja.opussolar.com.br/produto/transmissor-dados-hoymiles-dtu-mi/ Und hier sieht man eine DTU mit S.Nr.(10F052403668) aufgeklebt: https://ae01.alicdn.com/kf/H91aaca10736b4450a21891509dfeb934v.png Mit der Info will ich nur aussagen, dass die MI-WR die S.Nr. von der alten DTU wahrscheinlich hören wollen. Wie Olaf schon die Erkenntnis hatte, kann man nicht jede DTU mit jeden WR kommunizieren. :) Olaf A. schrieb: > *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 Somit könnte man bei der Abfrage die DTU(alt), die S.Nr. 10F0xxxxxxxx hinterlegen. @IsnoAhoy: Hier könnte man die Excel aktualisieren, oder? https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx Und wenn mein Gedanke richtig ist und das so auch funktioniert,... könnte man später im Code hinterlegen mit welcher DTU-S.Nr. die Kommunikation stattfinden soll. Bsp: HM-800 11417420xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx) HM-1500 11616320xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx) MI-1200 10616090xxyy => DTU-Alt? (10F0xxxxxxxx) Gruß Daniel
:
Bearbeitet durch User
Hallo Olaf A. / Tobi D., danke für die positive Rückmeldung. Könnt Ihr bitte unter github oder hier Eure Verkabelung zwischen ESP (welches Modul) und dem nRF24 Funkmodul dokumentieren bzw. mit der Verkabelung dort vergleichen ? Danke! ESP8266: Discussion Verkabelung / Pinout #36 https://github.com/grindylow/ahoy/issues/36
Daniel R. schrieb: > Hallo zusammen, Nachtrag: Hier eine bessere Quelle: https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt
Daniel R. schrieb: > Daniel R. schrieb: > >> Hallo zusammen, > > Nachtrag: Hier eine bessere Quelle: > https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt Quatsch mit Soße.
Hallo Frank, danke für die Ausführliche Rückmeldung. ;) Die Quelle soll sich eher auf die DTU-MI (Bilder) beziehen. Ich weiß ja nicht inwieweit es "Quatsch mit Soße" seien soll. Lieber verweise ich auf die Quelle woher die S.Nr. stammt. Schließlich ist doch jede Hilfe (auch wenn es nur eine S.Nr. ist) brauchbar. Vielleicht könnte man die Daten aus dem MI-WR mithilfe dieser DTU S.Nr beziehen. Bisher wird meines wissens nach in der "hmRadio.h" mit einer festen S.Nr. vorgegaukelt welche DTU spricht. Vielleicht macht es Sinn hier die ersten 4 stellen diese mit einzubeziehen. So, erkläre mir jetzt mal wieso das Quatsch mit Soße ist!?
Christian P. schrieb: >>> > Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+ > modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und > bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit > sehe ich alle pakete (inkl. der destination adresse). >>>> Das ist interresant, habe wie gesagt bisher die aurduinoUno+nrf24 kombi und SW von Ivo Pullens verwendet. Ich würde gerne mal deine aurduino Sketches ausprobieren um zu sehen ob ich die gleichen Daten sehe wie du, geht das?
Hallo Daniel R., ja das ist evtl ein interessanter Fakt, ich habe noch keine Rückmeldung von den anderen DTU Besitzern erhalten welches Prefix die denn haben, sonst könnte ich die Tabelle gerne mal ergänzen/aktualisieren. Ich habe schon ein paar zusätzliche Informationen gesammelt aber noch keine. commit gemacht. @Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer versendet ? 10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ? @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten auf dem Kanal 2403GHz. @Oliver F. das wäre doch was für Deinen nRF24 hexa-Decker mit sechs nRF Modulen kannst Du dann senden und alle fünf Kanäle (2403-2475) mitschneiden. Ebenfalls interessant ist mE die Beschreibung unter Seite 8 des von Daniel R. verlinkten „historischen“ Dokuments: Fig.2. MI-500 /MI-600 /MI-700 Microinverter wiring diagram Note 1: DTU connects the power production of each microinverter. If the asymmetry current is going to exceed 16 A, DTU will send stop signal to one or more microinverters to let the asymmetry current lower than 16A. Das sind ja die Signale die uns noch fehlen, also wie kann die DTU die WR dazu bringen ihre Kanäle abzuschalten. Evtl. kann man mit diesem Wissen und einem regelbaren Netzteil am Eingang der WR eine DTU in den Panikmodus versetzen und die Nachricht abfangen ?
Hallo IsnoAhoy; IsnoAhoy schrieb: > am Eingang der WR eine DTU in den > Panikmodus versetzen Das klingt an sich nicht schlecht, nur ist die Frage ob der Flag im Speicher vom WR sich automatisch zurücksetzen lässt (durch ein Neustart?). Sonst bestünde die Gefahr das der WR für immer in dem Modus bleibt, außer man schickt den richtigen Befehl... wobei ich behaupte mal das die Entwickler hierfür bestimmt was vorgesehen haben. Hier würde ich mal das ganze mit vorsicht "genießen".
:
Bearbeitet durch User
Hallo Daniel R. ich gehe mal davon aus, wenn die Differenz der Leistung wieder unter 16A fällt sollte eine ordentliche DTU das auch wiedee freischalten, das könnte man dann auch aufnehmen. Hattest Du nicht Deinen WR mangels Modulen noch am Labornetzteil ? Ich nehme an das bezieht sich auf mehrere WR in der auf Seite 8 beschriebenen Modul-Konfiguration.
Genau, ich betreibe es aktuell am Labornetzteil. Nur habe ich ein HM-1500. Mein Netzteil kommt an sein Limit. :( Besitze nur einen mit 30V und knapp 10A.
:
Bearbeitet durch User
IsnoAhoy schrieb: > @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. > Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf > 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten > auf dem Kanal 2403GHz. Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und 0x00AA. Achtung: man kann hiermit keine längeren Payloads mitlesen, weil ja wegen der Empfangskonfig 6 Bytes und 1 Bit zu früh empfangen wird und deshalb die hinteren bis zu 7 Byte fehlen. Ziel dieses Sniff-Methode ist es, die Destination-Adresse im nrf24-Header zu identifizieren. Wenn man die mal genauer weiß, kann man den nrf24 auf diese Adresse und Adresslänge konfigurieren und dann die ganze Payload über die herkömmliche (=designte) Methode empfangen. Anbei der Sketch und die verwendete RF24 library. Mit readserial.py hole ich mir den Output am Raspberry Pi herein. Mit verifyserial.py filtere ich nach Paketen mit gültigem CRC. Aus Performancegründen nur Pakete mit 5stelliger Zieladresse. Das kann man in Zeile 59 auf range(0,3) setzen, um 2 bis 5 byte lange Adressen durchzuanalysieren. Achtung: Payloads länger als 23 Byte oder 24 Byte könnten hier übersehen werden. LG
:
Bearbeitet durch User
Hallo zusammen, ich versuche gerade das NRF auf dem Raspi zum laufen zu bringen. Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".
1 | sudo python3 -um hoymiles --log-transactions --verbose --config /home/dtu/ahoy.yml | tee -a log2.log |
2 | Traceback (most recent call last): |
3 | File "/usr/lib/python3.7/runpy.py", line 183, in _run_module_as_main |
4 | mod_name, mod_spec, code = _get_module_details(mod_name, _Error) |
5 | File "/usr/lib/python3.7/runpy.py", line 142, in _get_module_details |
6 | return _get_module_details(pkg_main_name, error) |
7 | File "/usr/lib/python3.7/runpy.py", line 109, in _get_module_details |
8 | __import__(pkg_name) |
9 | File "/home/Hoymiles_NRF24/hoymiles/__init__.py", line 14, in <module> |
10 | from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16 |
11 | ImportError: /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: undefined symbol: _ZN4RF2410setPALevelEh |
Ich habe wie in der Beschreibung auf Github alles Installiert und auch den Wrapper drauf gepackt. Ich musste vorher noch die Module crcmod & RF24 nach installieren. Aber irgendwie hängt das ganze. :( Raspberry Pi 4 Python 2.7.16 Python 3.7.3 PS: Bei Step 4 "nano gettingstarted.cpp", habe ich diesen Punkt einfach ohne Änderung weiter gemacht. Ist das falsch?
:
Bearbeitet durch User
Hallo in die Runde, nachdem ich eine Weile nur selten mitlesen konnte, habe ich nun mein Setup wieder aktiviert. Diese Software https://github.com/hm-soft/Hoymiles-DTU-Simulation läuft auf einem Arduino Nano V3 zuverlässig und liefert an meinem HM600 Werte, die gut zu dem passen, was ich am Shelly mitlogge.
1 | ----------------------- |
2 | rcv CH:75 00 1234567801 00BE 17 3 95 72014650 72014650 830000000403E8012900163010E7B896 B896 1 |
3 | Udc.CH1=29.4 V |
4 | Idc.CH1=0.14 A |
5 | Pdc.CH1=4.2 W |
6 | Udc.CH2=30.0 V |
7 | Idc.CH2=0.15 A |
8 | Pdc.CH2=4.6 W |
9 | E-Total.CH1=145.471 KWh |
10 | E-Total.CH2=146.316 KWh |
11 | E-Tag.CH1=1568 Wh |
12 | E-Tag.CH2=1610 Wh |
13 | Uac=233.6 V |
14 | Freq.ac=49.99 Hz |
15 | Pac=8.4 W |
16 | Ipv=0.04 A |
17 | WR-Temp=29.7 °C |
18 | Status=1000 |
19 | E-heute=3178 Wh |
20 | E-Total=291.787 KWh |
Tagesproduktion heute lt. Shelly 3100Wh und Total 290 KWh Klasse, wie gut das schon funktioniert :-) Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g. Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht kompatibel sind. Hat jemand eine lauffähige Version für ESP32? Viele Grüße Carsten
Christian P. schrieb: > IsnoAhoy schrieb: >> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. >> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf >> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten >> auf dem Kanal 2403GHz. > > Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte > konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und > 0x00AA. >>>> Hallo Christian P. Danke für die SW! Habe gerade ausprobiert ohne was zu aendern, also als sniffer: WR ist im Schlaf , die DTU-Pro sendet/sucht. Zuerst mal bin ich beruhigt, die Daten sind gleiche was ich auch schon mit "meiner" SW gesehen habe. Siehe Anhang, du kannst es sicher besser interpretieren.. Was die DTU sendet ist dauernd: 00 f2 bis 00 fd
:
Bearbeitet durch User
> Was die DTU sendet ist dauernd: 00 f2 bis 00 fd
Das liest sich so:
1 | 60 71 70 63 01 (11/0/0) 38(63 70 71 60|72 22 84 12)00 fc[a4 bb] |
Erste 5 Bytes: Adresse, an welche das nrf24 Paket geschickt wird. Nur nrf24 Module empfangen das, die nach Paketen an diese Adresse "lauschen". (11/0/0) ist das decodierte 9bit PCF: 11=Länge der payload, 0=message counter, 0=noack-flag Die payload ist also 0x38 bis 0xfc. Danach in der eckigen Klammer ist der crc16 vom nrf24 Protokoll. Die Payload habe ich mit (|) versucht zu untergliedern: erstes Byte ist das MID (sofern das stimmt). Danach 4 Byte mit S/N des WR, dann 4 Byte mit S/N der DTU, dann der CMD 0x00, dann ein CRC8 über die vorangegangen Bytes der Payload. Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn der WR antwortet steht an genau dieser Stelle die S/N des WR. Nun gilt es herauszufinden, wie man dem WR "programmiert", an welche Adresse er seine Antwortpakete senden soll. Ich habe das zuletzt geschafft indem ich ein Paket mit MID=15 und CMD=80 an den WR geschickt habe (Inhalt nach der Logik wie oben). Danach hat der WR einige Minuten lang alle seine Antworten an die gesetzte Adresse geschickt 8-) Leider aber konnte ich weiterhin keine Stromdaten aus dem WR herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die PV-Kanäle 36:1, 37:2, 38:3 und 39:4...?
:
Bearbeitet durch User
Hallo zusammen, Daniel R. schrieb: > Ich scheitere beim letzten Step "sudo python3 -um hoymiles...". Zu meinem obigen problem bin ich nicht weiter gekommen. Alles neu gemacht aber irgendwie hänge ich nun an dem Wrapper. Nunja, wollte euch nur zum Thema "NRF24 kann nicht senden" noch Informieren das man die Platine einpacken soll. Siehe: https://github.com/nRF24/RF24/blob/master/COMMON_ISSUES.md Falls es jemand interessiert. :)
Christian P. schrieb: >>> Ach so, danke für die Erklaerung! > Leider aber konnte ich weiterhin keine Stromdaten aus dem WR > herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von > deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die > PV-Kanäle 36:1, 37:2, 38:3 und 39:4...? Ich hatte mal früher schon mit MID=00bisFF und CMD=00bisFF alle Kombinationen erfolgslos versucht, aber hab vielleicht was falsch gemacht.. Jetzt bin gespannt, was bei dir rauskommt. > Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden > Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn > der WR antwortet steht an genau dieser Stelle die S/N des WR. Das ist genau so, imho bei allen DTU's
Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden. Handbuch: http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text
1 | If the DTU cannot detect all the microinverters in the system over 30 minutes, please use manual mode instead. |
Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping" aussendet und die WR darauf eine Rückantwort ausgeben. Hier müsste es auch in der DTU-Pro diese Funktion geben. Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon" auffangen und mit Implementieren (Feature). ------------------------ In diesem Beitrag von einem anderen Forum: https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840 Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann, ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :) Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf... Gruß
Daniel R. schrieb: > Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden. > > Handbuch: > http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf > > Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text >
1 | If the DTU cannot detect all the microinverters in the system over |
2 | > 30 minutes, please use manual mode instead. |
> Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping" > aussendet und die WR darauf eine Rückantwort ausgeben. > > Hier müsste es auch in der DTU-Pro diese Funktion geben. > Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon" > auffangen und mit Implementieren (Feature). > Das ist ein altes Manual. Bei meiner DTU-Pro geht das nicht mit dem MI-WR, man muss ihn zuerst in der APP/Cloud angeben > > In diesem Beitrag von einem anderen Forum: > https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840 > > Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann, > ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :) > > Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf... > > Gruß Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache seit einem Jahr per Modbus den zero export. Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine früheren Beitraege hier...
@Christian P. Anfrage DTU-Pro: PV1: ...36(63 70 71 60|72 22 84 12)00 PV2: ...37(63 70 71 60|72 22 84 12)00 PV3: ...38(63 70 71 60|72 22 84 12)00 PV4: ...39(63 70 71 60|72 22 84 12)00 Anworten vom MI-WR: PV1: ...b6(63 70 71 60|63 70 71 60)data PV2: ...b7(63 70 71 60|63 70 71 60)data PV3: ...b8(63 70 71 60|63 70 71 60)data PV4: ...b9(63 70 71 60|63 70 71 60)data 36 00110110 b6 10110110 bit8 gesetzt 37 00110111 b7 10110111 bit8 gesetzt ;-)
:
Bearbeitet durch User
Ziyat T. schrieb: > @Christian P. > Anfrage DTU-Pro: > PV1: ...36(63 70 71 60|72 22 84 12)00 > PV2: ...37(63 70 71 60|72 22 84 12)00 > PV3: ...38(63 70 71 60|72 22 84 12)00 > PV4: ...39(63 70 71 60|72 22 84 12)00 > > Anworten vom MI-WR: > > PV1: ...b6(63 70 71 60|63 70 71 60)data > PV2: ...b7(63 70 71 60|63 70 71 60)data > PV3: ...b8(63 70 71 60|63 70 71 60)data > PV4: ...b9(63 70 71 60|63 70 71 60)data Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten vom WR.
1 | 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2] <-anfrage vom Raspi |
2 | 44 55 66 77 01 (11/2/0) 36(77 66 55 44|61 40 19 13)00 1d[88 16] <-antwort vom WR |
Gleiches Ergebnis mit MID=37 bis 40. Bei mir antwortet der WR nur, wenn die erste S/N die vom Raspi ist. Setze ich da die S/N vom WR ein, dann antwortet der nicht mehr. Irgendwas macht deine DTU also zusätzlich, vielleicht auch nur alle $$ Minuten? Oder gar nur einmalig beim Hinzufügen des WR ins Setup? Vielleicht passiert es auch auf einem der anderen Kanäle? Ich lausche ja nur auf 0x03. Den Kanal kann man in den Skripten ja auch mal ändern...
@ Christian P. (pocki) Hier noch was: DTU: 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e WR: d1(63 70 71 60|63 70 71 60)5a 5a d1 51>d1 8 bit gesetzt
Christian P. schrieb: > Ziyat T. schrieb: >> @Christian P. >> Anfrage DTU-Pro: >> PV1: ...36(63 70 71 60|72 22 84 12)00 >> PV2: ...37(63 70 71 60|72 22 84 12)00 >> PV3: ...38(63 70 71 60|72 22 84 12)00 >> PV4: ...39(63 70 71 60|72 22 84 12)00 >> >> Anworten vom MI-WR: >> >> PV1: ...b6(63 70 71 60|63 70 71 60)data >> PV2: ...b7(63 70 71 60|63 70 71 60)data >> PV3: ...b8(63 70 71 60|63 70 71 60)data >> PV4: ...b9(63 70 71 60|63 70 71 60)data > > Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten > vom WR. > > [code] > 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2] > <-anfrage vom Raspi ich glaube es muss so sein: DTU>WR 36(63 70 71 60|72 22 84 12)00 f2 37(63 70 71 60|72 22 84 12)00 f3 38(63 70 71 60|72 22 84 12)00 fc 39(63 70 71 60|72 22 84 12)00 fd
Bei mir so - ich habe nun einfach mal deine Adressen kopiert.
1 | 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- raspi an WR |
2 | 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- antwort vom WR |
sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt. Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet der gar nicht.
Ziyat T. schrieb: > Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache > seit einem Jahr per Modbus den zero export. > Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine > früheren Beitraege hier... Ok, da ich ein HM besitze ist es bis auf 2% echt cool. 8-) Ziyat T. schrieb: > @Christian P. > Anfrage DTU-Pro: > PV1: ...36(63 70 71 60|72 22 84 12)00 > PV2: ...37(63 70 71 60|72 22 84 12)00 > PV3: ...38(63 70 71 60|72 22 84 12)00 > PV4: ...39(63 70 71 60|72 22 84 12)00 Sobald ich meine Probleme mit dem Raspi+NRF in den Griff bekommen habe, probiere ich das mal aus. Danke! :) @pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt. Hattest du die selben Probleme? -> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Daniel R. schrieb: > @pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt. > Hattest du die selben Probleme? -> > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Ja, habe ich auch nicht hinbekommen und dann hingeschmissen.
Guten Tag, ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500. Mein interesse ist die "export limitierung" realisiert durch einen bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24) Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode der DTU-PRO nicht weiter um die Informationen besser zu decodieren? Grüße Andreas
Andreas S. schrieb: > Guten Tag, > > ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500. > > Mein interesse ist die "export limitierung" realisiert durch einen > bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens > der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24) > > Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode > der DTU-PRO nicht weiter um die Informationen besser zu decodieren? > > Grüße > Andreas Hallo Andreas Hast du die Quellcode der DTU-PRO? Oder wo kann man sie finden?
@Christian P. (pocki) Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann? Ich möchte gerne die obige Diskussionen/Erkentmisse bei mir mal ausprobieren ohne lange deinen Sketch zu studieren und kaputt zu machen :-) Es waere einfach wenn ich als data z.B. 36(63 70 71 60|72 22 84 12)00 f2 37(63 70 71 60|72 22 84 12)00 f3 38(63 70 71 60|72 22 84 12)00 fc 39(63 70 71 60|72 22 84 12)00 fd schicken könnte
Hallo Andreas, wenn ich dich richtig verstanden habe ist an sich dein Gedanke nicht schlecht. Um an den Quellcode dran zu kommen ist es nötig das jemand die Mikrocontroller vom DTU-Pro dumped, diesen müsste man dann decompilieren und und und... wäre an sich möglich. Die Frage jedoch, wer hat eine DTU-Pro UND das Equipment um ein Dump zu machen? Bluepill, Blackpill,... https://medium.com/techmaker/reverse-engineering-stm32-firmware-578d53e79b3 Achtung: bei solch einem Dump werden natührlich auch die Daten (S.Nr, Email?, User-Infos) mit gesichert. Wenn jemand sich das zutrauen könnte, wäre das an sich eine feine Sache. =) Edit: Wie Ziyat schon geschrieben hat: Quellcode ist ja ein vom Hersteller geschrieben und ich kenne kaum eine Firma die denn Quellcode freigeben. ;)
:
Bearbeitet durch User
Ziyat T. schrieb: > @Christian P. (pocki) > Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann? Leider nein, so gut bin ich mit Arduino-Sketches nicht. Deshalb mache ich das auch mit einem Raspi und einem zweiten nrf24 Modul an den GPIO-Pins. Software dazu siehe ein paar Posts weiter oben mit den zip Attachments.
Hallo an die HolyMolyDTU SW-Entwicker Ich habe die letzte SW im April eingesetzt, sowohl ESP als auch Arduino Versionen, da die MI-WRs nicht mehr aktuell sind und ich war der einzige mit einem MI-WR, habe ich damals aufgehört weiter zu machen. Seit dem habe keine Ahnung mehr über die SW-Staende etc.. Jetzt hat mich wieder ein bisschen durch Christan P. gepackt, den MI zu lauschen, ich denke wir sind bisschen weiter gekommen. Ich möchte gerne eine der SW-Versionen (ESP oder Arduino) verwenden um einfach paar Msgs zu schicken und was zu empfangen. Ich gestehe, bin etwas faul um irgend eine SW zu aendern. Kann mir jemand von SW-Enwicklern eine Version anbieten mit der ich die folg. payload schicken kann: MID..WR...........DTU..........CMD.. 36...63 70 71 60..72 22 84 12..00 f2 37...63 70 71 60..72 22 84 12..00 f3 38...63 70 71 60..72 22 84 12..00 fc 39...63 70 71 60..72 22 84 12..00 fd erwartete Antwort b6...63 70 71 60..63 70 71 60..data..... Danke
Hallo, es gibt ein git-respository. Das parent-repository ist einige commits ahead aber privat. Die Aussage leite ich aus den merge requests 2020 ab. Aber vermutlich werden ein paar brauchbare Informationen vorhanden sein. https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO (Anmelden über den github oauth provider) Allerdings enthält das repository keine Lizenz Informationen. Daher ist eine bedenkenlose Verwendung wohl fraglich. Grüße Andreas
Christian P. schrieb: > Deshalb mache ich das auch mit einem Raspi Also funktioniert es bei dir doch. Hmm... Gut dann gehe ich denn weg alleine. Andreas S. schrieb: > Das parent-repository ist einige commits > ahead aber privat. Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff darauf, kann man da etwas scrapen? :) Dann könnte man das ganze hier sogar beschleunigen.
Christian P. schrieb: > Bei mir so - ich habe nun einfach mal deine Adressen kopiert. > >
1 | > 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- |
2 | > raspi an WR |
3 | |
4 | das hier sollte 5a 5a 9e 0b sein |
5 | |
6 | > 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- |
7 | > antwort vom WR |
8 | > |
> > sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt. > Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet > der gar nicht. hab alle MID=51 von DTU im Anhang, dann antwortet MI regelmaessig mit MID=D1
Daniel R. schrieb: > Christian P. schrieb: >> Deshalb mache ich das auch mit einem Raspi > > Also funktioniert es bei dir doch. Hmm... > Gut dann gehe ich denn weg alleine. > > Andreas S. schrieb: >> Das parent-repository ist einige commits >> ahead aber privat. > > Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff > darauf, kann man da etwas scrapen? :) > > Dann könnte man das ganze hier sogar beschleunigen. Christian P. hat zum Lauschen Arduino+nrf24 zum Senden Raspi+nrf24. Versuch mal mit seiner Raspi SW ?: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Daniel R. schrieb: > Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff > darauf, kann man da etwas scrapen? :) Also: - Gefunden mit dem Tool "google". ( https://www.google.de/search?q=gitee+hoymiles+dtu ) - Jeder hat Zugriff (siehe Link vorher oder erster Treffer in der google Suche) wenn man einen Account auf gitee erstellt. (github ist für die Welt, gitee ist für China) - Ja sollte helfen, da kompletter Quellcode inklusive Bootloader, Doku, Tabellen, Logs,... Grüße Andreas
:
Bearbeitet durch User
Super - da findet sich im gitee repo ein excel file mit dem Titel RFxxxx-V6.5. Schon ohne Translator erkennt man darin Message-Schemen. Das haben wir gesucht! Nun geht es ans übersetzen und auf die Suche des "PASSWORD/unlock codes" für die Commands MID=0x15 und 0x09... :-) Die finden sich vielleicht auch irgendwo dort im Repo.
Hallo, ich habe scheinbar ein Händchen für Suchfunktionen. :-) Im file usart_nrf.c ist definiert: UsartNrf_Send_PackSetLockOnOffCommand(...) Andreas
Hallo Ziyat T, danke für den Link. Jedoch ging es eher von Ahoy Github (https://github.com/grindylow/ahoy/tree/main/tools/rpi). Das bekomme ich nicht zum laufen. :( Christian nutzt die andere abgewandelte. ^^ Das würde ich dann nehmen, wenns nicht anders geht. @Andreas S: Okay cool, Gitee kannte ich gar nicht und wo ich auf die Seite gekommen bin (mit translator), wurde ich indirekt abgewimmelt. Ich versuche mich dort mal zu Registrieren. Mal schauen wie gut ich in Chinesisch bin. joke :)
Hallo, gibt es einen Trick das ganze Repo als ZIP herunterzuladen ? Ich bekomme überall nur 404 wenn ich den Button "Clone or Download" und dann "Download as ZIP" versuche (bei gitee.com). Anmeldung hab ich hinbekommen.
:
Bearbeitet durch User
Angehängte Dateien:
Also bei mir hat es funktioniert. Die ZIP ist 148MB groß.
Sieht nach den "Kronjuwelen" aus! Der Source Code lässt vermutlich keine Fragen mehr offen.
:
Bearbeitet durch User
Andreas super arbeit! Übrigens bin ich bisschen vorsichtig hier. Habe mal zwecks Dokumente lesen diese bei Virustotal geschoben. Aktuell nichts auffäliges. https://www.virustotal.com/gui/file/a31fea2076e821eae5d783c75fa3814e7a3378002f21d80d4737d238a31e4b47?nocache=1 Würde das bei allen Files empfehlen, besonders die bat / exe. Die erste bat-File im root Ordner sieht bisschen suspekt aus. Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich einige Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder besser Github pushe?
:
Bearbeitet durch User
Danke ! ! ! für den Link ! ! ! Danke Andreas ! ! !
Daniel R. schrieb: > Andreas super arbeit! > p> Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich einige > Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder > besser Github pushe? Rechtlich sind wir sowieso alle Banditen hier, darum gefaellt es mir;-)) Die Chinesen haben seit mehr als 20 Jahren auch alles kopiert... Für mich lieber Github, auch ohne Uebersetzung
@Christian P. #define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF 0x51 //ŒÓËø&ÏÞÖƹŠÂÊ #define CONTROL_LOCK_MI_SUB 0xa5a5 #define CONTROL_LIMIT_POWER_SUB 0x5a5a #define CONTROL_ON_SUB 0x55aa #define CONTROL_OFF_SUB 0xaa55 genau was ich heute bei mir gesehen habe ;-) 51(63 70 71 60|72 22 84 12)5a 5a
Angehängte Dateien:
Also in der Excel "RF通讯协议-V6.5.xlsx" (RF-Kommunikationsprotokoll-V6.5.xlsx) stehen viele Dinge über die alten MI-WR Serie. ;) Da sollte in Zukunft Licht ins dunkle kommen. Die Excel habe ich zu ca. 1/3 auf Deutsch übersetzt. Ich breche hier ab und schaue mich noch in den anderen Dokumenten um.
:
Bearbeitet durch User
Bingooo!!!!
1 | /*********************************************** |
2 | ** Function name: //Stellen Sie die Anti-Rückfluss-Parameter ein |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | |
7 | ** Returned value: ? |
8 | *************************************************/ |
9 | uint8_t UsartNrf_Send_PackSetRefluxPowerCommand(uint16_t reflux_power, uint8_t MainCmd, uint16_t SubCmd) |
10 | {
|
11 | uint8_t i = 0; |
12 | uint16_t j; |
13 | uint8_t temp_dat[UART_LEN]; |
14 | memset(temp_dat, 0, sizeof(temp_dat)); |
15 | Uart_SendBuffer[0] = STX;//Kopf |
16 | temp_dat[0] = MainCmd; //Anweisung |
17 | memset(&temp_dat[1], 0, 4); |
18 | memset(&temp_dat[5], 0, 4); |
19 | // |
20 | // MIReal[PortNO].Data.NetCmd = NET_TURN_ON; |
21 | // if(MIReal[PortNO].Data.NetCmd == NET_TURN_ON) //开机状态 |
22 | // {
|
23 | temp_dat[9] = SubCmd & 0XFF00 >> 8; |
24 | temp_dat[10] = SubCmd & 0XFF; |
25 | temp_dat[11] = reflux_power * 100 / (EVERY_PORT_POWER * 10 * Dtu3Detail.Property.PortNum); //Prozentsatz der Leistungsbegrenzung |
26 | temp_dat[12] = reflux_power >> 8; //Hohe 8-Bit-Leistungsbegrenzung |
27 | temp_dat[13] = reflux_power & 0x00ff; //Niedrige Leistungsgrenze 8 Bit |
28 | // } |
29 | // else //开低功耗 |
30 | // {
|
31 | // temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a |
32 | // temp_dat[10] = SubCmd & 0XFF; |
33 | // temp_dat[11] = 0; |
34 | // temp_dat[12] = 20&0x00ff; |
35 | // temp_dat[13] = 20&0xff00>>16; |
36 | // } |
37 | temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC |
38 | i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //Vorwärtssubstitution |
39 | Uart_SendBuffer[i + 1] = ETX; //Ende |
40 | memset(temp_dat, 0, sizeof(temp_dat)); |
41 | return (i + 2); |
42 | } |
Guten Abend, ich kann zwar programmieren -- denke ich -- aber ich bin eher der Anwender / Orchestrator. Daher meine vorsichtige Frage. Bekommen wir, ihr oder die Community es hin eine Arduino Bibliothek und/oder ein Python modul "ahoymilesdtu" zu erstellen? Man könnte ja in die Kommentare der Files im Sinne "copyleft" das quellgebende repository nennen. Danke und Grüße Andreas
:
Bearbeitet durch User
Ich kann mit der Frage nichts Anfangen. Was möchtest du nochmal genau wissen? :)
Daniel R. schrieb: > Ich kann mit der Frage nichts Anfangen. > Was möchtest du nochmal genau wissen? :) Das Resultat der zahlreichen Stunden die hier investiert werden könnte doch so aussehen: arduino include <ahoydtu.h> include <mysmartmeter.h> AHOYDTU ahoydtu_nrf24(SS_PIN, RST_PIN,...); MYSMMETER mysm('192.168.1.1',502); // Haus-Hauptanschluss void setup() { ... ahoydtu_nrf24522.Init(); ... } void loop(){ ... if (mysm.read_active_pw_kw() < -0.6){ ahoydtu_nrf24.reduce_pw_by(0.6 - math.abs(mysm.read_active_pw_kw()) ); } else { // no power limit } //wait some time ... } und/oder das gleiche in python import ahoydtu as ahoy ....# usw. So kann man 2kW installieren und speißt max. 600W ein. Und dank Blindleistungsregelung max. -60VA laut Richtlinien. Das geht glaube ich so in der DTU Pro software (noch) nicht. (siehe file: AntiBackflow.c )
:
Bearbeitet durch User
Sieht ja vielversprechend aus. Die Frage der Lizensierung ist sehr berechtigt. Ich würde meine Werke gerne unter der GPLv2 lizensiert sehen. Das wäre auch ein Grund für die Teilung der Repos. Meinetwegen bleiben sie bei Petersilie. Früher oder später muss das eh passieren, wenn wir python mal als richtiges installierbares Package bauen wollen. Für den MI-Teil bin ich sogut wie raus, weil ich hier kein DuT habe. Ich kann die Grundsubstanz des Python-Codes vielleicht mal modularer gestalten, dass das MI-Protokoll parallel hinzugefügt werden kann. Grundsätzlich bietet python ja schon die Idee, rohe Payloads via mqtt zu injecten. Jedoch bisher nur als Payload in zu einem HM, ohne ESB-Frame. Könnte man aber anpassen. Schwieriger wird dann das empfangen.
Andreas S. schrieb: > So kann man 2kW installieren und speißt max. 600W ein. Und dank Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein Zertifikat sehen, dass das auch funktioniert. Im Wesentlichen wird das EVU fordern bei Dir eine Fern-Abschalteinrichtung einzubauen. Physikalisches Limit != Software Limit. Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal wegen Unterproduktion die Computer aus.
Jan-Jonas S. schrieb: > Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine > DIY Frickelei ohne Siegel und Plombe eh nicht sein. Doch, ist sie, das ist gar kein Problem Zeig mir einen WR an dem die 70% Grenze verplombbar ist - entweder den Installateur interessiert es nicht oder man nimmt sie raus nachdem er weg ist Mit Kontrollen ist hier auch nicht zu rechnen auf welcher rechtlichen Grundlage sollte das passieren? Und selbst wenn es so passieren sollte - Pressemitteilung "900.000 PV-Anlagen in Deutschland still gelegt weil sie 3% zu viel eingespeist haben"- lächerlich
Hallo Andreas S., das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges. Hier die usart_nrf.c übersetzt ins Englische. Ich traue den Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht. Man sollte halt keinen Source Code 1:1 aus dem Original übernehmen, dann ist das ja auch nur eine Referenz und keine Kopie -> Urheberrecht. Bei dem Python Code von Jan-Jonas und den anderen Pythonistas sehe ich da sowieso eher kein Problem. Wenn es um die Portierung des Protokolls von der C in eine C++ Variante geht scheint mir der C++ Code von Lukas auch viel eleganter als das doch recht prozedurale C der Hoymiles Bibliothek. Vor allem der Parser für die Pakete ist m.E. bereits viel hübscher und modularer geraten.
isnoAhoy schrieb: > Hallo Andreas S., > das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges. > > Hier die usart_nrf.c übersetzt ins Englische. Ich traue den > Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht. Danke, super. Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden. Kann mir wer damit helfen? Verdächtig sind da ein paar Commands in der Übersicht: 0x02 broadcast commands to collect terminal device IDs in the network 0x13 Set query RF ID 0x18 All wRFID retrieval, respond as long as there is retrieval 0x1a Set MI-NRF ID
Hier ist eine englische Übersetzung des RF communication protocol-V6.5xlsx
Anbei noch einige übersetzte Dokumente. Laut dem Filesystem Design Dokument speichert die DTU 96 Werte pro Tag, das sind bei 1440 / 96 = 15 Minuten Intervalle.
Angehängte Dateien:
Hallo Christian P., > Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch > den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden. > Kann mir wer damit helfen? Ich habe das Excel-Dokument noch ein bißchen formatiert damit es leichter lesbar ist. Ich vermute das ist das Legacy poll data command 0x09 auf Seite 3 Data Collection instructions. Für den/die anderen Kanäle der zwei bzw. vier Kanal-Wechselrichter Varianten gibt es noch das Command 0x11 Kanal B, bzw. 0x36, 0x37, 0x38, 0x39 (=Kanäle A1, B1, A2, B2). Für die Suche nach einem WR kann man Command 0x02 verwenden siehe Seite 5 Data acquisition RF dedicated. Eventuell hast Du unbeabsichtigt auch das Kommando 0x01 Switch DTU-NRF air baud rate 2M / 250K an Deinen WR abgesetzt ? Versuche es doch mal mit 0x01 im User data wieder auf 250K zurück zu setzen. Ich meine so etwas auch in martin (Gast)'s DTULite Logfiles an den RX/TX Punkten gesehen zu haben. Ich vermute die Kommunikation mit 250K ist um einiges stabiler als die 2M Baudrate, vor allem in unseren Breitengraden mit einem vollen 2.4GHz Band.
Bingo - habe meinem MI-300 eine Antwort entlockt:
1 | Anfrage: |
2 | 13 19 40 61 01 (11/1/0) 09(61 40 19 13|51 22 22 22)00 51[cc 1a] |
3 | Antworten: |
4 | 22 22 22 51 01 (24/1/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1c.13 89.00 71.00 18.00 a4.8b[cb ??] |
5 | 22 22 22 51 01 (24/3/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1d.13 89.00 6b.00 19.00 a4.91[fb ??] |
6 | 22 22 22 51 01 (24/0/0) 89(61 40 19 13|61 40 19 13)01 3f.00 03.09 20.13 89.00 69.00 19.00 a4.d3[ad ??] |
7 | |
8 | 0x0142 = 32,2 V_PVA_AVG |
9 | 0x0003 = 0,3 I_PVA_AVG |
10 | 0x091c = 233,2 GridVol_AVG |
11 | 0x1389 = 50,01 GridFre_AVG |
12 | 0x0071 = 11,3 APower_AVG |
13 | 0x0018 = 2,4 AEnergy |
14 | 0x00a4 = 16,4 Temp_AVG |
Hoffe die Kommaverschiebungen habe ich richtig inerpretiert. Zu dem Zeitpunkt liefert der WR etwa 92mA und 6W Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so dokumentiert.
:
Bearbeitet durch User
Sehr cool Pocki! :) Damit alle Dokumente hier Hand und Fuß hat, würde ich mir wünschen statt alles in dem Forum zu Posten. Stattdessen auf Github zu laden, die Frage ist jedoch: Macht das Sinn? Beste grüße.
Christian P. schrieb: Super Christian! > 0x0018 = 2,4 AEnergy Das sollte 24Wh sein. D.h. MI-300 und MI-1500 wegen der Anzahl Ports anders anzusprechen, echt mühsam
Hallo, da ich die bisher immer nur stiller mitleser war habe ich mich jetzt endlich angemeldet. Ich habe einen Mi-600 und ich weis nicht ob ich hier was dazu beitragen kann. Zuerst hatte ich etwas schwierigkeiten den ESP8266 zum laufen zu bringen. Ich hatte die FW compiliert und geflasht und sah aber keinen acesspoint, auch der connect ins heimische wlan ging nicht (hatte es direkt beim compilieren schon mit rein) Ffertige .bin von hier probiert, die 0.4.11 und 0.4.13 mit selben Ergebniss. Die version 220519_ahoy_0.4.4_esp8266.bin hatte endlich funktioniert, und konnte auch auf die 0.4.13 upgraden... dabei war mir aufgefallen das die settings mit vielen yyyyyy gefüllt waren. Meine SN fängt mit 104161 an
Hallo Richard, also der letzte Update auf Github war vor ca 40min. An sich gibt es verschiedene wege wie man das ganze auf den ESP bekommt. Meines wissens nach ist der ganze Code noch nicht für den MI-Wechselrichter angepasst. Wäre es ein HM, dann wäre würde es schon besser klappen. Du musst dich noch ein bisschen gedulden für die MI-Serie, da neue Erkentnisse erlangt worden sind und das demnächst nach und nach weiter aufgebaut wird. ;) PS: yyyy sind übrigens nur "Platzhalter", die müsste man ersetzen.
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein > Zertifikat sehen, dass das auch funktioniert. > Im Wesentlichen wird das EVU fordern bei Dir eine > Fern-Abschalteinrichtung einzubauen. > Physikalisches Limit != Software Limit. > Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine > DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in > Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal > wegen Unterproduktion die Computer aus. Hallo Jan-Jonas, das sehe absolut genauso. Die Herausforderung ist nicht die Software. Ich könnte meinem EVU sogar eine REST-API zur Fernabschaltung anbieten aber ich vermute wenn ich aktuell den vereinfachten Antrag ("600W") stelle mit: "Balkonanlage mit 2kwWp und Null-Export-Begrenzung" wird man damit nichts anfangen können und ggf. sagen, "...ja aber was ist mit der Blindleistung...". Selbst wenn ich das mit gekaufter Hardware mache. (Es gibt ja hier auch Nutzer von MI-1500, wie ist es hier gelaufen?) Ich frage mich daher, es gibt ja diese Funktion. Das wird dann wohl von großen Anlagen genutzt (+ Blindleistungsanpassung)? Hat da jemand Dokumente / Zertitikate von hoymiles die diese Regelungsfunktion laut Standard XY durch TüV, VDE o.ä. zertifizieren? Danke für Hinweise.
Konformitätszertifikat Erzeugungseinheit VDE AR-N-4105:2018-11 https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_EZE.pdf Konformitätszertifikat NA-Schutz VDE AR-N-4105:2018-11 https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_NA.pdf Nur das konnte ich finden. EDIT: Hier gibts von jedem Hoymiles-WR ein Zertifikat. https://www.shinetech-power.de/wechselrichter/hoymiles/
:
Bearbeitet durch User
Beitrag #7093597 wurde von einem Moderator gelöscht.
Daniel R. schrieb: > Konformitätszertifikat Erzeugungseinheit Das gilt aber nicht für das Gerät mit selbst geschriebener Software oder selbst gebastelten Teilen des Komplettsystems :)
Hallo Christian P., > Bingo - habe meinem MI-300 eine Antwort entlockt: Na das ist doch mal eine freudige Nachricht! > Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so dokumentiert. Das ist m.E. die Fehler Antwort, wenn der WR einige Events im Log hat, die man sich genauer ansehen soll. M.W. hat Jan-Jonas die Event Log Abfrage für die aktuellen HM-XXX Wechselrichter in der Raspberry Pi/Python Software bereits umgesetzt. @Christian P., Ziyat T. & Richard K., vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen ? Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das Programm an der Stelle zu testen / verifzieren.. Hallo Daniel R., > Damit alle Dokumente Hand und Fuß haben, würde ich mir wünschen - statt alles hier ins Forum zu Posten - es stattdessen auf Github zu laden. Die Frage ist jedoch: Macht das Sinn? Es gab diverse Meinungen dass es nicht unbedingt sinnvoll ist den OpenSource Code mit den Closed Source Dokumenten auf GitHub zu mischen. Aber es spricht sicher Niemand dagegen, wenn Du die Dokumente auf Deinem Github in einem separaten Repository ablegst.
isnoAhoy schrieb: > @Christian P., Ziyat T. & Richard K., > vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos > in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen > ? > Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das > Programm an der Stelle zu testen / verifzieren.. > Ich würde gerne die ESP8266+nrf24 / Arduino+nrf24 Variante für den MI-1500 einsetzen. Die SW-Staende kenne ich nicht (mehr). Ich weiss dass die SW komplett auf HM zugeschnitten sind, darum ich braeuchte eine "Anleitung", wo und wie ich die Kommandos eingeben kann, natürlich auch die Antworten zu parsen. Edit: hier sind die Kommandos/Antworten welche ich in der Luft gesehen habe. DTU-Pro<>MI1500 Daten ======================================================================== = Anfrage v. DTU-Pro: MID,WR,DTU,CMD PV1: ...36(63 70 71 60|72 22 84 12)00 PV2: ...37(63 70 71 60|72 22 84 12)00 PV3: ...38(63 70 71 60|72 22 84 12)00 PV4: ...39(63 70 71 60|72 22 84 12)00 Anworten v. MI-WR: MID,WR,WR,Data PV1: ...b6(63 70 71 60|63 70 71 60)data PV2: ...b7(63 70 71 60|63 70 71 60)data PV3: ...b8(63 70 71 60|63 70 71 60)data PV4: ...b9(63 70 71 60|63 70 71 60)data 36 00110110 > b6 10110110 bit8 gesetzt 37 00110111 > b7 10110111 bit8 gesetzt Limitierung ======================================================================== = Anfragen v. DTU-Pro: 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e 0b = 11% power limitierung Anworten v. MI-WR: d1(63 70 71 60|63 70 71 60)5a 5a d1 51>d1 8 bit gesetzt #define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF 0x51 //ŒÓËø&ÏÞÖƹŠÂÊ #define CONTROL_LOCK_MI_SUB 0xa5a5 #define CONTROL_LIMIT_POWER_SUB 0x5a5a #define CONTROL_ON_SUB 0x55aa #define CONTROL_OFF_SUB 0xaa55
:
Bearbeitet durch User
Hallo Ziyat T., ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80, MI-250/300/400 MID = 0x09, MI-600/700/800 MID = 0x09 & 0x11 sowie MI-1000/1200/1500 MID = 0x36..0x39 In der hmInverter.h müssen die Inverter Model ebenfalls mit getModel und setModel implementiert werden In der hmSystem.h kann man dann in addInverter das Protokoll in einem switch je nach Modellnummer setzen. Und dann kann man in der hmRadio.h die Methoden sendTimePacket den sendCmdPacket Aufruf anpassen mit case je nach Inverter getModel. Das Mapping der Inverter Daten erfolgt dann wieder über die in hmDefines zu definierenden byteAssign_t miXchAssignment[] und deren Länge Irgendwie müssen wir dem Code dann noch beibringen dass für die MI-Serien teilweise zwei/vier Cmd Pakete geschickt und ausgewertet werden müssen. Aber mit den og Anpassungen sollte es erstmal den ersten Kanal der MI-Modelle abfragen können. @Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei so was umzusetzen?
IsnoAhoy schrieb: > @Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei > so was umzusetzen? Nein bin ich nicht und habe es auch nicht vor. Ich fände es am besten, wenn man die Inverter Serie per template Parameter übergibt und sich damit vor dem kompilieren entscheiden muss. Weiter würde ich es bevorzugen die hm*.h Dateien zu duplizieren und als mi*.h umbenennen. Dann bekommen wir jetzt nicht ein riesen Chaos und ständige if-else-switch Konstrukte. In naher Zukunft kann man dann Gemeinsamkeiten suchen und diese wieder generisch anlegen.
:
Bearbeitet durch User
IsnoAhoy schrieb: > Hallo Ziyat T., > ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für > HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80, Danke, Habe die https://github.com/lumapu/ahoy/tree/main/tools/esp8266 runter geladen, ohooo, ist ja was implementiert worden. Muss sagen da blicke ich nicht einfach schnell durch. Ich habe die Version von April hier, mache mal damit weiter, ich muss ja zuerst sicher sein, was ich in der Luft sehe sollte auch implementiert werden und soll so laufen..
Hallo, ich habe mit großem Interesse diesen thread gelesen und mir die 4.4. Bin auf einem Wemos geflasht. Mir ist nur nicht klar was ich bei inverter Adress eintragen soll. Ich habe mehrere HM-300 die ich anfragen möchte. Irgendwie scheint die serial number ne Rolle zu spielen,aber wo finde ich die. Kann mir mal jemand auf die Sprünge helfen. Habe ich was überlesen?
Holger Skusa schrieb: > ...Irgendwie scheint die serial number ne Rolle zu spielen,aber wo > finde ich die. Die S/N der WR findest Du auf der Rückseite vom WR. Also auf der planen Seite.
Und diese Nummer ist dann bei Adress inverter einzutragen? Oder muss die noch irgendwie gewandelt werden?
normaler Weise so eintragen wie sie drauf steht. Ich würde dir empfehlen die aktuelle 0.4.17 zu installieren, die muss allerdings selbst kompiliert werden.
Hallo euch allen! Ich wollte euch allen, die an der großartigen Entwicklung beteiligt sind, danken. Ich bin ein stummer „Mitleser“ mit einem HM-300, der zufällig auf dieses Forum und die Topic stieß. Was „Elektrotechnik" angeht bin ich maximal Anfänger; Was Mikrocontroller angeht kompletter Laie und was Funk angeht mit noch weniger Fachwissen ausgestattet. Leider kann ich nicht so viel zur Programmierung beitragen, da ich auch hier komplett fachfremd bin und mir die Zeit momentan fehlt, mir das alles anzueignen. Dank euch und eurer tollen Dokumentation konnte ich das Projekt mittels eines „D1 mini“-clones und einem NRF24L01+PA+LNA (jetzt mit zusätzlicher „Schirmung“) realisieren. Funktionierte, wie dokumentiert, problemlos „out of the box“. Danke für euer Engagement! Ihr habt da „etwas Lust am Basteln" bei mir etwas geweckt ;-)
Angehängte Dateien:
-
ESP_DTU_Platine1.jpg
68 KB -
ESP_DTU_Platine2.jpg
130 KB -
ESP_DTU_Platine3.jpg
140 KB
Hallo zusammen, ich habe einige Platinen machen lassen. Wemos D1 mini und NRF24 zusammen auf einer Platine mit der Verdrahtung wie im GitHub beschrieben. Ich habe noch einige Platinen übrig und würde die für 2€ pro Stück abgeben. Einfach in ebay-Kleinanzeigen nach esp-dtu suchen...
Hallo zusammen, wollte auch ein Danke loswerden! also: DANKE! Geile Arbeit! Dickes Lob an die Community! Ich habe es jezt alles auf einem Nodemcu laufen. Meine PV Module sind noch nicht da, also hab ich dem HM-300 ans Labornetztteil gepackt. Wenn keine DC-Spannung anliegt geht das Funkmodul vom Umrichter nicht. AC muss aber nicht anliegen um das System zu testen. Gruß Ert
Hallo, ich wünschte ich könnte mich auch bedanken. Aber leider will es noch nocht so richtig. Ich habe die Serial Nummer meines HM-300 nun gefunden und in der 4.4 eingetragen. Leider kommen keine Daten. Nun versuche ich dem Tipp von Lukas zu folgen und die 4.17 zu kompilieren. Meine Arduino ide bricht aber immer mit: In file included from app.cpp:1:0: app.h:4:18: fatal error: RF24.h: No such file or directory #include <RF24.h> ab. HELP !!!
Die Library von Git maniacbug/RF24 hab ich installiert...
Mit der Arduino IDE 1.8.19 und - aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4) sowie den LIBRARIES - Time 1.6.1 - RF24 1.4.2 - PubSubClient 2.8 klappt es bei mir problemlos. Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt.
Beitrag #7095391 wurde von einem Moderator gelöscht.
Eine Frage, gab es auch schon Versuche Werte zu setzen so wie es die DTU Pro macht? Die kann ja den Output begrenzen bzw. ein "Country Protection File" hochladen (theoretisch braucht man das für den regelkonformen Betrieb)
Günter H. schrieb: > Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt. Du bist mein Retter des Abends !!! Soeben habe ich meine ersten Werte empfangen. Das hat jetzt aber auch Stunden gekostet. Aber Danke für die Datei. Mit der Arduino IDE hab ich schon immer auf Kriegsfuss gestanden. Die mag mich irgendwie nicht. Ich hab die IDE nun ganz neu installiert und alle von Dir angegebenen Librarys installiert. Das Board nach installiert usw. Was soll ich sagen, nun geht auch das kompilieren. Na dann kann ich wenigstens zukünftige Versionen selber bauen. Vielen Dank an alle die das hier möglich gemacht haben. Klasse Sache !!! Eine Frage hab ich noch: Wie viele Inverter kann ein Wemos mit einem RF24 empfangen. Das ist ja im Sketch einstellbar. Ist da bei 3 Stück Schluss, oder würden auch 6 gehen ? Gruß Skusi, und allen einen schönen Wochenanfang...
Hallo Holger Skusa, also prinzipiell werden die WR nacheinander abgefragt, es wären also auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen: #define MAX_NUM_INVERTERS 3 https://github.com/grindylow/ahoy/blob/main/tools/esp8266/config.h#L33 Irgendwann wird halt der Speicher knapp und ich weiß noch nicht sicher, ob sich der Code problemlos auch auf einem ESP32 kompilieren läßt.
Hallo Alexander P., bitte schau mal in das letzte Excel File hier im Thread: * RF_communication_protocol-V6.5.xlsx (78,3 KB) dort sind die offiziellen Hoymiles Kommandos und Antworten dokumentiert. Damit ist es dieser Tage auch gelungen, die MI-Wechselrichter zum reden zu bringen. Auch die offizielle "Bibliothek" von Hoymiles ist hier im Thread: * usart_nrf.c (147 KB) dort habe ich beim Übersetzen auch die Power Profile und Firmware Upload Routinen gesehen. Wenn Du die Raspberry Pi/Python Software von Jan-Jonas verwendest, dann kannst Du u.a. über MQTT eigene Kommandos an den Wechselrichter senden. In der ESP8266 Variante ist eine derartige Option aktuell noch nicht vorgesehen. @Lukas P., hast Du evtl. vor eine derartige MQTT-Schnittstelle, o.a. zur Fernsteuerung der Wechselrichter einzubauen oder bist Du mit der reinen Auswertung der Daten soweit zufrieden ?
Hallo Oliver R., kannst Du das Platinen Layout evtl. noch im GitHub committen bzw. einen PR erstellen ? Ich glaube ich habe nur die Fritzing Layouts gemacht aber kein Layout hochgeladen. Danke!
Ziyat T. schrieb: > Hallo > Die Antwort > channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d > fa 01 3a 33 > Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert. > D.h. dieser TSUN ist ein MI? > Konntest du schon einen request schicken und TSUN hat geantwortet? Hi, habe noch keine Requests rausbekommen. Dieser Part scheint mir auch defekt zu sein, da Abweichungen in den Bytes sind, z.B. die WR-Adresse im ersten Teil. Es könnte sein, dass der MI1500 mit dem TSUN ähnlich ist, auch die Chinesen erfinden nicht 3x das Rad neu. Bin jetzt erst von Montage wiedergekommen und schaue die Tage, was ich noch rauskriege.
isnoAhoy schrieb: > also prinzipiell werden die WR nacheinander abgefragt, es wären also > auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen: Hallo, ich hab jetzt mit der Einstellung #define MAX_NUM_INVERTERS 6 kompiliert. Funktioniert aber nur bis 5 Stk ! Ab 6 Inverter startet der Wemos nicht mehr durch. In der Console meckert er: Settings not valid, erasing ... Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?
IsnoAhoy schrieb: > @Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg > wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer > versendet ? > > 10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ? > > @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. > Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf > 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten > auf dem Kanal 2403GHz. Ich kriege aktuell nichtmal ein Kommando raus, da ich mit Arduino noch nicht so fit bin und Python auch nicht gerade ein Küchenlicht ist. Meine Freundin ist immer erst ca. 19 uhr zuhause, da ist auch nicht mehr viel mit Code und Sonne, es zieht sich also etwas. Bin aber auch gespannt auf dem Code am Ende :) Eine Kurzanleitung, wie für den ESP die Kommandos zusammengesetzt werden, wäre hilfreich, Strom in allen Formen, Farben und Geschmacksrichtungen sind für mich kein Problem, aber Bytes schubbsen in C++ ist ne andere Geschichte. Seriennummern drehen hab ich mit dem anderen NRF-Chip ohne externe Antenne noch nicht getestet, mache ich die Woche noch. Ich hab noch nicht so ganz verstanden, was meine DTU zwischen dem was am NRF reinkommt und am Ende in der Luft landet, noch macht, da sind Unterschiede.
Holger S. schrieb: > #define MAX_NUM_INVERTERS 6 > > kompiliert. Funktioniert aber nur bis 5 Stk ! > Ab 6 Inverter startet der Wemos nicht mehr durch. > In der Console meckert er: > > Settings not valid, erasing ... > > Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ? Nein es gibt keine Limitierung auf 6 Stück. Ich glaube in main.cpp oä wird new EEP(1000) oä aufgerufen. Die 1000 ist die Länge des zugreifbaren Eeproms oder besser gesagt emuliertes Eeprom also Flash. Diese Zahl darf maximal 4096 sein. Zusätzlich muss in defines.h noch die Speicherposition vom SettingsCRC nach oben verschoben werden z.B. 1500
Hallo @Daniel M.,@IsnoAhoy, @Hubi Da ich schon früher Hubi's code verwendet habe, hab die letzte Git-Version von ihm angepasst/vergewaltigt;-) Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD) 36 63 70 71 60 72 22 84 12 00 37 63 70 71 60 72 22 84 12 00 38 63 70 71 60 72 22 84 12 00 39 63 70 71 60 72 22 84 12 00 oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts! nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an meine DTU-Pro, wenn sie eingeschaltet ist. Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde ein neues nrf24 besorgen und damit ausprobieren.
Ziyat T. schrieb: > Da ich schon früher Hubi's code verwendet habe, hab die letzte > Git-Version von ihm angepasst/vergewaltigt;-) > Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD) Hi, das selbe an meiner Front gerade. D1 mini: 11 63 50 03 16 63 50 03 16 00 11 2E BA > oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts! > nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an > meine DTU-Pro, wenn sie eingeschaltet ist. > Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde > ein neues nrf24 besorgen und damit ausprobieren. Futsch isser sicher nicht. Solange wir nicht klar sagen können, was unsere Außenseiter genau hören wollen, bleiben die für uns stumm. Die Scanner-Programme, die ich probiert habe, kriegen entweder nix (falsche Rx-Adressen) oder ich sehe z.B. in der originalen scanner-Anwendung der NRF-Libary aus den Beispielen nur die Kanäle wo was aufploppt, jedoch nicht was. Ich kann bisher nicht sagen, wie die CRC aufgebaut ist oder was genau durch die Luft gesendet wird. Morgen neuer Versuch, WR geht gleich schlafen :) Angepasst habe ich erstmal in der hmRadio.h:
1 | void sendTimePacket(uint64_t invId, uint32_t ts) { |
2 | //DPRINTLN(F("hmRadio.h:sendTimePacket"));
|
3 | sendCmdPacket(invId, 0x11, 0x91, false); |
4 | mTxBuf[9] = 0x00; // cid |
5 | mTxBuf[10] = 0x11; |
6 | //CP_U32_LittleEndian(&mTxBuf[12], ts);
|
7 | //mTxBuf[19] = 0x05;
|
8 | |
9 | uint16_t crc = crc16(&mTxBuf[10], 14); |
10 | mTxBuf[11] = (crc >> 2) & 0xff; |
11 | mTxBuf[12] = (crc ) & 0xff; |
12 | mTxBuf[13] = crc8(mTxBuf, 13); |
13 | |
14 | sendPacket(invId, mTxBuf, 14, true); |
15 | }
|
Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine geänderten Dateien?
Hallo Daniel M., also Du musst zwei Pakete senden, aber zwischendrin erstmal die Antwort abwarten: Probiere mal: 1. sendCmdPacket(invId, 0x09, 0x00, true); 2. laß den Rest der Routine unter sendTimePacket einfach mal weg. Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen timestamp oder gar eine CRC_16. Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true berechnet und angehängt wird sollte eigentlich genug sein. Er sollte dann z.B. folgendes Senden: D1 mini: >09< <52 40 36 68> <63 50 03 16> >00< 11 Hier ist die 11 ganz vorne die MID (s.o.) dann die sollte die Serien Nummer der DTU als Routing Addresse (hier die antike DTU 10F052403668) folgen und dann erst die Serien Nummer des WR als Target Adresse (Routing und Target Adresse ist offenbar bei den MI-Wechselrichtern vertauscht). Die 00 sind die User data und dann kommt nur noch die CRC_8 hier einfach mal 11 gelassen, sollte eigentlich richtig berechnet werden. Die Start und Stop-Bytes 0x7e und 0x7f hängt i.d.R. der nRF25L01+ automatisch dran. Als Antwort bekommst Du dann 0x88 (status) / 0x89 (data) ... Das selbe sollte auch mit 0x11 als MID funktionieren für den zweiten Kanal. Also Antwort kommt dann eben 0x91 (data?) / 0x92 (status?) ... Warum bei 0x11 die Reihenfolge von status und data umgekehrt sein soll, wissen vermutlich nichtmal die Hoymiles-Götter. Aber das Excel Sheet "RF_communication_protocol-V6.5.xlsx" widerspricht sich hier auch selbst. Vermutlich wurde es erst nachträglich korrigiert (rot auf "Data collection instructions" in Zellen B94 und B99) @Ziyat T., Für Dich gilt m.E. genau das selbe, lediglich sollte als MID 0x36..0x39 für die vier Kanäle verwendet werden. Als Antwort kommt dann 0xB6... .. 0xB9... (data & status) Viel Erfolg
Hallo Holger,
wie Lukas schon erwähnt hat in eep.h:
EEPROM.begin(4096);
und in den defines.h das Ganze gleich dynamisch gestalten:
#define ADDR_SETTINGS_CRC ADDR_NEXT + CRC_LEN
#if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
#error address overlap!
#endif
#if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
#error EEPROM size exceeded! Configure less inverters?
#endif
@Daniel M. > Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine > geänderten Dateien? Wie gesagt, ich verwende Hubi's Code auf Arduino+nrf24, kein hmRadio.h,app.cpp @isnoAhoy > Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen > timestamp oder gar eine CRC_16. > Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true > berechnet und angehängt wird sollte eigentlich genug sein. Welches ist das alte MI-Protokoll? bis zum MI-600? Meine DTU-Pro sendet zum MI-1500 ganz klar CMD 0x36 bis 0x39 mit SubCMD 0x00, CRC 0xFx, sonst nichts: 60 71 70 63 01 (11/3/0) 39(63 70 71 60|72 22 84 12)00 fd[67 ed] 60 71 70 63 01 (11/1/0) 38(63 70 71 60|72 22 84 12)00 fc[a2 51] Ich muss mal andere Kanaele nochmals lauschen, ob der WR was anderes braucht Ps: Könnten wir uns auf die Bezeichnungen CMD und SubCMD einigen?
:
Bearbeitet durch User
Vielen Dank isnoAhoy, ich werde das mal bei Gelegenheit so versuchen. Fließt das dann auch in die nächste Version mit ein ? Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten und den Namen ändern. Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.
Habe den Code von Hubi etwas angepasst: NRF24_SendRcv.ino:
1 | if (tel == 0) { |
2 | #ifdef ESP8266
|
3 | hmPackets.SetUnixTimeStamp (getNow()); |
4 | #endif
|
5 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
6 | }
|
7 | else if (tel == 1) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x89); |
9 | else if (tel == 2) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x91); |
11 | else if (tel == 3) { |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
13 | //tel = 0;
|
14 | }
|
15 | else if (tel == 4) |
16 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x88); |
17 | else if (tel == 5) |
18 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x92); |
19 | |
20 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
21 | |
22 | tel++; |
Settings.h
1 | // WR und DTU
|
2 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
3 | #define SerialWR 0x104163500316ULL // <<<<<<<<<<<<<<<<<<<<<<< anpassen
|
4 | uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); // ((uint64_t)0x5279607201ULL); |
5 | #define DTU_RADIO_ID ((uint64_t)0x7311880801ULL)
|
Das Ergebnis:
1 | 20:19:58.728 -> Send... CH75 |
2 | 20:19:58.774 -> 00 7311880801 0092 12 1 92 63500316 63500316 000300000000000091D09E 1 |
3 | 20:19:58.774 -> ---- neues cmd=0 |
4 | 20:19:58.774 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 145.00 37328.00 53406.00 40502.00 13878.00 13981.00 |
5 | 20:19:58.774 -> analyse words:50331648.00 0.00 0.00 0.00 145.00 37328.00 9556126.00 2446368256.00 3500029440.00 2654353152.00 909548928.00 916290496.00 |
6 | |
7 | 20:20:03.760 -> 00 7311880801 0094 12 2 88 63500316 63500316 00030000000000008B7436 1 |
8 | 20:20:03.760 -> ---- neues cmd=0 |
9 | 20:20:03.760 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 139.00 35700.00 29750.00 13867.00 11083.00 19437.00 |
10 | 20:20:03.760 -> analyse words:50331648.00 0.00 0.00 0.00 139.00 35700.00 9139254.00 2339649024.00 1949707136.00 908807168.00 726396352.00 1273878016.00 |
11 | |
12 | 20:20:49.802 -> 00 7311880801 00C0 18 0 91 63500316 63500316 012D0001095D1389003D085D00FFE550EF 1 |
13 | 20:20:49.802 -> P1.Udc :26.50 |
14 | 20:20:49.802 -> P1.Idc :238.27 |
15 | 20:20:49.802 -> P1.Pdc :3507.20 |
16 | 20:20:49.802 -> P2.Udc :1562.40 |
17 | 20:20:49.802 -> P2.Idc :238.08 |
18 | 20:20:49.802 -> P2.Pdc :6550.90 |
Log anbei. Die etwas anders aussehenden Zeilen sind aus dem Python-Mitschnitt und zeitlich relativ passend. Die Werte stimmen natürlich noch nicht, aber hey, der WR redet mit mir :) Der tel==3 Part passt noch nicht, wird aber offenbar nicht benötigt. Ein kleiner weiterer Schritt in die richtige Richtung. Danke Euch allen!
Holger S. schrieb: > Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen > Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem > Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate > ein neues Gerät zu bekommen. Das wurde einfach aus dem Beispiel der MQTT lib übernommen, schau mal in der mqtt.h relativ weit unten, der neue Name wird 'extra' erzeugt, warum kann ich nicht sagen, evtl. findet man bei PubSubClient (so heißt die lib) etwas darüber. Bei der nächsten Speicheränderung können wir den CRC wie isnoAhoy geschrieben hat noch weiter nach hinten schieben. Mit 6 WR bist du aktuell Spitzenreiter und musst sowieso selbst kompilieren. Bin gespannt ob das funktioniert. Ich glaube bis zu 4 wurden schon getestet.
Hallo, habe seit langem mal wieder den Code geupdated und vorher hat alles sehr gut funktioniert aber mit dem neusten update bekomme ich gar keine Daten mehr. Ich sehe nur noch
1 | Error while retrieving data: last frame missing: Request Retransmit |
2 | Error while retrieving data: last frame missing: Request Retransmit |
3 | Free heap: 0x430f8 |
4 | Inverter #0 no Payload received! (retransmits: 0) |
5 | Requesting Inverter SN val = 0x112173109025 |
Gerät wurde nicht bewegt (Antenne ist gleich) und vor dem update ging es tadellos. Habe einen HM-400. Hat noch jemand das Problem ? Vielen dank P.s.: Ich habe was gelesen, das man jetzt schon weit ist die Einspeisung zu kontrollieren ? Ist das korrekt ?
Hast du auch den Gegencheck mit der alten Version gemacht? Ich habe zugegeben auch immer wieder Probleme, aber ich denke es liegt sehr stark an der Umgebung und die ändert sich doch mehr als man es erwarten würde. Gestern habe ich den ESP unters Dach getragen und ständig mit Abstürzen zu helfen gehabt (Wifi?) und heute konnte ich wieder aus dem Keller funken (aber auch nur in einer exakten Ausrichtung). Liegt die Antenne bisschen anders bekomme ich keine Frames rein. Ich hoffe die Ausrichtung passt morgen noch ... Die Einspeisung zu reduzieren gilt bisher nur für die MI Serie - und dort wird grad heftig an der Kommunikation der ersten Daten geschraubt. Also bisher kann man noch keinen WR begrenzen.
:
Bearbeitet durch User
Daniel M. schrieb: > Habe den Code von Hubi etwas angepasst: > NRF24_SendRcv.ino: Gratuliere :-) Ich mache so, aber ohne erfolg: uint8_t MID = 0x36; //0xB9=0x39 0xB8 38 uint8_t CMD = 0; . . if (tel > 5) tel = 0; if (MID > 0x0039) MID= 0x0036; if (tel == 0) { #ifdef ESP8266 hmPackets.SetUnixTimeStamp (getNow()); #endif //do not need size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); } else size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, MID, CMD); SendPacket (dest, (uint8_t *)&sendBuf, size); MID++; tel++;
:
Bearbeitet durch User
Hallo Marcel A., bzgl Power Limitation würde ich Doch auf das o.a. Excel Sheet "RF_communication_protocol-V6.5.xlsx" verweisen. Da steht mE alles drin was in der DTU Pro an Request und Response von MI-&HM-Wechselrichtern verstanden und gesendet wird. U.a. sind da auch die Kommandos zur Power Limitierung auf X % enthalten. Speziell auf der Seite „control commands“ findet sich das Limit Power command word 0x51 subcommand 0x5A5A und die Antwort 0xD1. Die Implementierung der Kommandos von Hoymiles dazu findest Du in der o.a. usart_nrf.c (147 KB). @Ziyat T. und Daniel M., ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer noch ein Timestamp mitgesendet zu werden. Laut der Command Word Summary sind die Commands words (früher hier MID) für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11 (optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse MI-1000..1500) Das Command word für die HM-Serie ist durchweg 15 und die Antwort 95. Bitte schaut Euch doch mal die Screenshots aus dem Excel bzw. die entsprechenden Command words auf der Seite „data collection instructions“ unterhalb der Zeile „Legacy poll data command“ an. Dort ist nach der Target Address nur noch das Subcommand / Userdata 00 und die CRC-8, aber kein Timestamp wie beim Command word 15 für die HM-Serie.
Hallo zusammen, auch wenn es nicht ganz zum aktuellen Stand der Unterhaltungen hier im Forum passt: Nachdem ich mehrere Stunden an mehreren Tagen verzweifelt probiert habe die NRF24 Python Library, also die Dependency für die Raspberry Version von Ahoy, korrekt zu installieren, habe ich mich gestern direkt an den Entwickler von NRF24 über github gewendet (https://github.com/nRF24/RF24/issues/845) - da ich, egal wie ichs gedreht und gewendet bekommen habe, den Python Wrapper für NRF24 nicht installiert bekommen habe. Ich würde gerne meine Schritte weitergeben, sollte jemand an dem selben Punkt verzweifelt sein wie ich. - Install Raspberry Pi OS lite x86 with raspberry pi imager - Connect nrf24 module to raspberry pi (as described in github) - Login with user pi - Execute "sudo apt update && sudo apt -y upgrade" - Execute "sudo raspi-config" and -- "Expand filesystem" in "Advanced Options" -- Activate "SPI" in "Interface Options" -- "Finish" to exit raspi-config Tool, reboot YES! - Login as pi user again
1 | sudo apt install cmake git python3-dev libboost-python-dev python3-pip python3-rpi.gpio |
2 | sudo ln -s $(ls /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3*.so | tail -1) /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3.so |
3 | git clone https://github.com/nRF24/RF24.git |
4 | export RF24_DRIVER=SPIDEV |
5 | cd RF24 |
6 | rm Makefile.inc #just to make sure there is no old stuff |
7 | mkdir build && cd build |
8 | cmake .. |
9 | make |
10 | sudo make install |
11 | cd ../pyRF24 |
12 | rm -r ./build/ ./dist/ ./RF24.egg-info/ ./__pycache__/ #just to make sure there is no old stuff |
13 | python3 -m pip install --upgrade pip |
14 | python3 -m pip install . |
15 | python3 -m pip list #watch for RF24 module - if its there its installed |
16 | cd .. |
17 | cd examples_linux/ |
18 | python3 getting_started.py # to test and see whether RF24 class can be loaded as module in python correctly |
Wenn im letzten Schritt keine Fehlermeldungen kommen, dann sollte der NF24 Wrapper erfolgreich installiert sein. Danke euch allen für eure Arbeit :)
:
Bearbeitet durch User
IsnoAhoy schrieb: > @Ziyat T. und Daniel M., > ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer > noch ein Timestamp mitgesendet zu werden. > Laut der Command Word Summary sind die Commands words (früher hier MID) > für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11 > (optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse > MI-1000..1500) Die 0x09 und 0x11 mit den Antworten 0x88,0x89 sowie 0x91 unx 0x92 sind beim TSUN identisch mit dem was ich aus der MI-Serie gesehen habe. Offenbar haben die Chinesen einfach das MI-Modell kopiert. Der Timestamp wird gesendet, die Funktion bewirkt aber garnichts, der WR ignoriert das einfach. Hubi verwendet einfach ein i++ um den CMD hochzuzählen und entsprechende Abfragen zu schicken, zu sehen in dem Post weiter oben. Die passende pid für die Antwort wird gleich mitgegeben. Mittlerweile hab ich auch die Felder zu den Antworten passend gemappt. Der Part nach der WR-Temperatur fehlt mir noch, ich bin nicht sicher ob das CRC16 oder noch Werte sind, da mit die Gesamtproduktion der MPPT noch fehlt. Weiter fehlen auch noch die Statusbytes. Vielleicht kriege ich das heute abend noch hin. > Probiere mal: > 1. sendCmdPacket(invId, 0x09, 0x00, true); > 2. laß den Rest der Routine unter sendTimePacket einfach mal weg. Der Teil ist mir ehrlich gesagt, zu hoch. Ich weiß nicht an welcher Stelle ich das einfügen soll. Wenn du mir da kurz auf die Sprünge hilfst, teste ich das gerne. Eventuell kannst du auch kurz was zaubern, womit ich 0x09 und 0x11 im Wechsel senden kann, dann probier ich mich mit dem Einbau daran aus.
Hallo, die Platinen sind wahrscheinlich schon weg oder? Konnte leider nichts finden und könnte 3 Stück gebrauchen. Danke und Gruß
Hallo Daniel M., ja, der TSUN scheint nur ein rebrandeter Hoymiles MI-Wechselrichter zu sein. Das hatten wir aufgrund der Seriennummer auch schon vermutet. Meine Angaben bezogen sich auf den code von Lukas unter tools/esp8266 da ich den Rest für Nano und die nrfScan tools von Hubi und anddren nie genutzt habe. Speziell bezog sich 1. & 2. auf die hmRadio.h Zeile 162ff https://github.com/grindylow/ahoy/blob/e05d2220cb1f99bbbf4083d62b0281d096ceeccb/tools/esp8266/hmRadio.h#L162
Hallo Daniel M., habe mir den code nochmal genauer angesehen und vermutlich kannst Du die beiden Aufrufe von sendTimePacket und die anderen Aufrufe von sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe ersetzen und anpassen. app::loop Ab Zeile 295ff kommt die Senderoutine: https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L339 app::processPayload hier erfolgt das Lesen und Sammeln der Payload Fragmente und der bisher HM spezifische Retransmit: https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L413 Im zweiten Teil dem processPayload könntest Du also nach Empfang der ersten Antwort 0x89 die zweite Anfrage 0x11 stellen und auf die Antwort 0x91/0x92 warten. Dann solltest Du die Antworten jeweils in den Variablen/Strukturen ablegen und mit den Definitionen in miDefines.h (Kopie von hmDdfines.h) auslesen.
Angehängte Dateien:
-
2022-06-16-A.jpg
69 KB -
2022-06-16-A1.jpg
48 KB
nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden
Angehängte Dateien:
Guten Morgen! Leider bin ich noch Anfänger auf dem Gebiet, habe mich aber an einem PCB-Design versucht, welches ich hier angehängt habe (habe keinen Github-Account; kann bei Gefallen gerne dort übernommen werden). Designt mit EasyEDA; Ich habe versucht, Platinenplatz einzusparen und gleichzeitig auch noch die Pins nochmals anzulegen (für weitere Spielereien wie 5/3,3v externe Stromversorgung ohne Löten etc). Ebenfalls habe ich den 100µF (oder andere Größe nach Belieben; das µ wollte mir das Programm nicht auf das Board beschriften ;-)) Kondensator zwischen GND und 3,3v auf das Board gepackt. Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€. Verbesserungsvorschläge gerne willkommen
oxylog schrieb: > Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€. kleiner Edit: 3 Boards habe ich bei Aisler für unter 10€ geordert
Hallo, ich habe ein Problem mit meiner ide. Ich bin weit weg von zu Hause und kann es nicht lösen. Könnte jemand bitte hier eine bin-Datei mit der neuesten Version für ESP anhängen. Danke im Voraus
Für das Wemos D1 mini-Board ist das hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Daniel R. schrieb: >
1 | sudo python3 -um hoymiles --log-transactions --verbose --config |
2 | > from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, |
3 | > RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16 |
4 | > ImportError: |
5 | > /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: |
6 | > undefined symbol: _ZN4RF2410setPALevelEh |
7 | > |
Sieht nach einer kaputten Installation des RF24-Moduls aus. Warte noch ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01, was man einfach komplett mit pip installieren kann. Kein fuckery mehr mit irgendwelchen selbst kompillierten blobs im System verteilen, die nur kompillieren, wenn man sie im richtigen Unterverzeichnis kompilliert. ``` ModuleNotFoundError: No module named 'cross.crossunixccompiler' ```
Ameise schrieb: > nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden Da hat sich ja die Arbeit der Community gelohnt…
IsnoAhoy schrieb: > Hallo Daniel M., > > habe mir den code nochmal genauer angesehen und vermutlich kannst Du die > beiden Aufrufe von sendTimePacket und die anderen Aufrufe von > sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe > ersetzen und anpassen. Hi, Danke, ich versuche es mal die kommenden Tage. Mit etwas experimentieren habe ich zumindest schonmal eine Payload gesehen, auch wenn das noch nicht zuverlässig geklappt hatte. Deine Hinweise auf die Stellen schaue ich mir genauer an, an einigen Stellen war ich schon dran.
Meine ESP-Version 4.17 hat ein Problem, ich kann es nicht anpingen, das www funktioniert nicht, manchmal ist es 2 Minuten nach dem Start. Mir ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1 Sekunde aktualisiert wird, ist das richtig?
Ameise schrieb: > nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden Sauerei, das sich da wieder jemand dran bereichern muß. Kann man da nix gegen machen ? Pfui ! von mir...
Ein paar Fragen: Wenn ich in der config.h folgendes eintrage: // fallback WiFi info #define FB_WIFI_SSID "Flackerlighter" #define FB_WIFI_PWD "meinPasswort" 1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem WLan auf ? Console: Main::setupStation connect to network '⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮ ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮' ... ............................... ........................................................................ ............................ Main::setupAp --------- AP MODE SSDI: AHOY-DTU PWD: esp_8266 Active for: 60 seconds --------- 2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert verwendet ? 3. Wie genau sind die Statistic Werte zu verstehen: Receive success: 18 Receive fail: 17 Send Cnt: 128 sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ? Gruß Skusi
isnoAhoy schrieb: > Hallo Holger, > wie Lukas schon erwähnt hat in eep.h: > EEPROM.begin(4096); > > und in den defines.h das Ganze gleich dynamisch gestalten: > > #define ADDR_SETTINGS_CRC ADDR_NEXT + CRC_LEN > > #if(ADDR_SETTINGS_CRC <= ADDR_NEXT) > #error address overlap! > #endif > > #if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN) > #error EEPROM size exceeded! Configure less inverters? > #endif Hallo isnoAhoy, ich habe die Änderungen so in die Dateien eingepflegt, aber sobald ich mehr als 4 inverter in die config.h eintrage bootet der Wemos nicht und sendet. Settings not valid, erasing ... ???
Holger S. schrieb: > Sauerei, das sich da wieder jemand dran bereichern muß. > Kann man da nix gegen machen ? > > Pfui ! von mir... Kannst du ausschließen dass jemand die Software selbst entwickelt hat?
Jan-Jonas S. schrieb: > Warte noch > ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01 Moin Jonas, danke für die Antwort. :) Ok, du bist schon dabei das ganze miteinander zu kombinieren? Kann ich irgendwie helfen? Mein Ziel ist es zukünftig alles direkt am Pi zu betreiben. Dann brauch ich nicht extra noch ein WiFi-Client ins Netz zu halten. :P
Damian B. schrieb: > Mir ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1 > Sekunde aktualisiert wird, ist das richtig? ja, das hat isnoAhoy geändert und führt bei uns zu stabileren Systemen. Es hängt jetzt fix am Abfrageintervall, die Zeit wird sogar auf der Index Seite ausgegeben (also wie lange das Intervall ist)
Holger S. schrieb: > 1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem > WLan auf ? Habe es selbst nie getestet, nur implementiert. Evtl findest du den Fehler? > 2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert > verwendet ? Die kWp der angeschlossenen Module. Hiermit wird die Einstrahlung in Prozent berechnet, ganz interessant um zu wissen wie optimal deine einzelnen Module stehen. > 3. Wie genau sind die Statistic Werte zu verstehen: > Receive success: 18 > Receive fail: 17 > Send Cnt: 128 > > sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ? Success heißt die komplette Payload wurde empfangen. Fail sind dementsprechend die fehlgeschlagenen Payloads. SendCnt sind alle gesendeten Frames, auch Retransmits. In besten Fall wäre success und SendCnt identisch und fail auf 0.
Einhart P. schrieb: > Holger S. schrieb: >> Sauerei, das sich da wieder jemand dran bereichern muß. >> Kann man da nix gegen machen ? >> >> Pfui ! von mir... > > Kannst du ausschließen dass jemand die Software selbst entwickelt hat? Kann man nicht, aber sie wird sehr sicher auf unseren Erkenntnissen aufbauen. Wie sieht es denn lizenztechnisch hier aus? Ich denke ua., dass Christian Bauer hier auch mitliest. @Jan-Jonas: Ich glaube du bist auf diesem Gebiet fit, was sollen wir für die (nahe) Zukunft machen? Für mich sieht es so aus als würde sich jemand mit unserem Wissen zu bereichern, irgendwie arm, hoffentlich ein Einzelfall. Bei einem Preis von 10€ könnte man nichts sagen, aber hier ist eine Marge von 40€ veranschlagt. Der kostenlose Support wird von Mikrokontroller.net geleistet oder wie?
:
Bearbeitet durch User
Hallo Holger S., ja das ist erstmal richtig, Du hast ja eine größere Config und die CRC Summe ist weiter nach hinten gerutscht, somit stimmt das nicht mehr und er löscht alle Settings (außer den WiFi Settings). Du mußt dann im Setup die Wechselrichter Daten wieder eintragen. Ich glaube da gab es ein Problem, daß er aktuell keine sinnigen Default Werte einträgt sondern alles mit 0xFF auffüllt. D.h. Du mußt Alles in den Settings entfernen und nur die relevanten Teile eintragen. Da auch die Pin Settings fehlen kann er auch keinen nRF24 finden und startet immer wieder neu bzw. den Access Point. Du kannst auch mal die folgenden u.a. Einträge mit #pragma error versuchen, vielleicht bekommst Du dann auch etwas mehr Debug Output. Ich weiß nämlich ehrlich gesagt nicht, wieviele Bytes eine Inverter Config groß ist ? #define INV_CH_CH_NAME_LEN MAX_NUM_INVERTERS MAX_NAME_LENGTH 4 // (4 channels) Laut der defines.h reserviert er immer vier Kanalnamen plus den Inverternamen à 16 Byte, also 5*16 Byte. Das sollten bei ca. 200 Byte für die WIFI und MQTT Settings ca. 100 Byte mal sechs Inverter weit unter 4096 sein. #define ADDR_SETTINGS_CRC ADDR_NEXT + CRC_LEN #if(ADDR_SETTINGS_CRC <= ADDR_NEXT) #pragma error "address overlap! (ADDR_SETTINGS_CRC="+ ADDR_SETTINGS_CRC +", ADDR_NEXT="+ ADDR_NEXT +")" #endif #if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN) #pragma error "EEPROM size exceeded! (ADDR_SETTINGS_CRC="+ ADDR_SETTINGS_CRC +", CRC_LEN="+ CRC_LEN +")" #pragma error "Configure less inverters? (MAX_NUM_INVERTERS=" + MAX_NUM_INVERTERS +")" #endif PS: Support-Anfragen der Käufer solange unsere Software noch so schöne Macken wie "Settings not valid, erasing ..." hat sind da bestimmt schon inklusiv =^p
So das Angebot in Kleinanzeigen ist deaktiviert, Dank meiner Frau. Evtl. sollten wir zusätzlich diese Lizenz aufnehmen um unsere Belange besser auszudrücken: https://commonsclause.com/ Wir machen das hier für die Community, also Maker und nicht für jedermann. Alle anderen sollen bei hoymiles eine DTU kaufen.
Einhart P. schrieb: > Holger S. schrieb: >> Sauerei, das sich da wieder jemand dran bereichern muß. >> Kann man da nix gegen machen ? >> >> Pfui ! von mir... > > Kannst du ausschließen dass jemand die Software selbst entwickelt hat? Das Gehäusedesign stammt jedenfalls von mir. https://github.com/grindylow/ahoy/tree/main/tools/esp8266/WemosD1_NRF24_Case