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

Heinz R. schrieb:

versuch es mal mit OpenDTU?

Ich hatte nun auf Github einen Issue eröffnet und nun kam raus es liegt am Speicher. Bei mehr als 4 Wechselrichtern reicht der Speicher des ESP 8266 nicht mehr aus. Ich hab mir jetzt einen ESP 32 bestellt ;-)

OpenDTU API JSON Hallo, wofür steht Bitte das "d:" und was haben die Zahlen dahinter für eine Bewandnis? Danke schon einmal im voraus.

Hallo,

ich hab seit längerem ein AhoyDTU am laufen, und ich hab eine Frage. Ist es möglich ein Relais direkt zuschalten ab einer gewissen Einspeisung?

Also ohne Mqtt, ich möchte dazu kein extra Server aufbauen.

Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt Einspeisung.

Ich würde es gerne so einfach wie möglich halten.

Danke

Sebastian M. schrieb:

Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt Einspeisung.

Ich würde es gerne so einfach wie möglich halten.

Die willst dann einfach hart ein- und ausschalten? Da freut sie sich

Und unter 400W gibt es nur noch eine kalte Dusche?

Du solltest Dein Vorhaben noch mal überlegen Du musst bei PV-Überschuss die Soll-Temperatur hoch ziehen, nicht alles komplett an/aus

Nein ich hab noch ein Wärmetauscher, die Wärmepumpe soll unter 400 Watt nicht laufen. Man bräuchte noch ein 2. Relais um die Heizung aktivieren.

Alles andere ist mir zu aufwendig, da der Sicherungskasten zu weit weg ist Smarthome gibt es leider nicht.

Wenn du dir einen freien Ausgang entsprechend reinprogrammierst, der das macht, ist es sicher kein Problem dort ein Relais (ggf. über Transistor) anzuhängen.

Sebastian M. schrieb:

Alles andere ist mir zu aufwendig, da der Sicherungskasten zu weit weg ist Smarthome gibt es leider nicht.

Es ist ja nicht so das ein "Home2 "smart" ist oder nicht

Auch im sogenannten Smart Home, das sind halt Steuerungen - ,mal mehr, mal weniger

In Deinem Fall würde ich aber auf alle Fälle was sinnvolles bauen - nicht die WP hart an- / ausschalten

Was ist es denn für eine WP? wie kann die gesteuert werden?

Ich würde hier trotzdem MQTT nutzen, wegen mir auch einen öffentlichen Server, kann Dir auch meinen zur Verfügung stellen

Sebastian M. schrieb:

Hallo,

ich hab seit längerem ein AhoyDTU am laufen, und ich hab eine Frage. Ist es möglich ein Relais direkt zuschalten ab einer gewissen Einspeisung?

Also ohne Mqtt, ich möchte dazu kein extra Server aufbauen.

Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt Einspeisung.

Ich würde es gerne so einfach wie möglich halten.

Danke

Moin,

ich versuche sowas mit dem IOBroker und Alexa zu realiseren. Man kann eine Alexa Adapter installieren und dann z.b. Steckdosen schalten!

Grüsse

AD

Andreas schrieb:

ich versuche sowas mit dem IOBroker und Alexa zu realiseren. Man kann eine Alexa Adapter installieren und dann z.b. Steckdosen schalten!

von hinten durch die Brust ins Auge...

Hi,

ich bin ganz neu hier und schaffe mir gerade ein kleines Balkonkraftwerk an.

Nun stellt sich mir die Frage: Wie hoch ist denn die Wahrscheinlichkeit, dass OpenDTU auch den E-Star Energy HERF-800 unterstützen wird. Scheinbar soll es sich da weitestgehend um Hoymiles-Technik handeln, braucht aber statt einer DTU eine DCU, die wohl technisch nicht kompatibel sind.

Denke die Chance zumindest in absehbarer Zeit geht dann gegen Null (ohne es zu wissen). Warum nimmst dir dann nicht eine Hoymiles?

Moin, ich habe einen ESP32 (Box) mit Opendtu seit ca. März zu laufen. (da hängen 2x WR am Balkonkraftwerk dran) Alles hübsch und Verbindung zum Iobroker. Ich habe die Box momentan im Wohnzimmer zu stehen. Wenn die Box startet ist nur mein AP im Hausflur online. Später dann ab 10:00 schaltet sich ein Repeater im Wohnzimmer dazu. (heute testweise ca. 8:30 manuell betätigt) Die Box wird sich wohl dann irgendwann mit dem Repeater verbinden, weil der Empfang doch stärker ist als vom AP im Hausflur. In dieser Zeit habe ich immer einen kompletten Abbruch von ca. 5min. Ist das normal - startet dann die DTU komplett neu?

Danke für die Antwort.

Den kompatiblen HM-300 gibt es momentan bei Reichelt für 69€, falls jemand Interesse hat.

https://www.reichelt.de/microinverter-hoymiles-hm-300-betterie-bc01-buchse-ho-hm-300-bet-p354755.html?&trstct=pos_1&nbc=1

Hallo und vielen Dank für diese wertvolle Arbeit! Habe gerade brandneu das System aus ESP32 und NRF24L01+ Modulen zusammengesteckt und die aktuelle Firmware geflasht. Die Funkstrecke zum HM-600 ist eine Zimmerdecke, alles funktionierte auf Anhieb! Großartig! Die Einbindung der Daten in meine Heimsteueranlage ist dann nur noch eine Frage der Zeit.

Hallo in die Runde! Ich habe mir wieder ein paar Platinen fertigen lassen. Dieses Mal mit Integration für ESP32 (38 Pin) mit NRF24l01+ und E49-900M20S sowie I2C-Display; Ebenfalls geht die "klassische" Bestückung mittels Wemos + NRF (dann ohne Display). https://www.kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoydtu-und-opendtu-projekt-auf-esp32-und-esp8266/2490730186-168-9361

CE schrieb:

Ich habe mir wieder ein paar Platinen fertigen lassen.

Genau nach so einer suche ich :) Gibt es irgendwo den Schaltplan deiner Platine? Auf den Bildern ist die Beschriftung der Lötbrücken doch etwas schwierig zu erahnen.

Hallo Ahoy-Leute, ich habe mich ein wenig eingelesen und komme aber eher vom Arduino. Der Arduino-Teil scheint weniger entwickelt, bitte hier um Hilfe. Muss ich das NRF24_SendRcv als mehrere Bibliothek definieren ? Sonst kann ich die Befehle wohl nicht nutzen. Und ich sehe den Power-Limit Befehl in Arduino-Projekt umgesetzt. Bitte hier um etwas Hilfe, denn mit GUIs, IO Broker und fertig flashern kann ich nichts anfangen. Ich hätte gern lieber eine einfache Lib für die Arduino IDE, mit einem Befehl die Leistung auszulesen und ein volatile Power-Limit zu setzen. So konnte ich es mit meinen Griedtie Invertern bisher über RS465 tun, aber ich hätte nun gern etwas mit mehr VDE-Normen dran. Gruß, Max

Nun habe ich schon mal raus gefunden das im man nicht im "nano" Verzeichnis nachsehen darf, sondern in der tool/main im NRF24_SendRcv ein .ino findet.

Ich denke in diesem Abschnitt bekommt man die Daten des WR:

1

    for (uint8_t i = 0; i < ANZAHL_VALUES; i++) {

2

      //outChannel(i);

3

      Serial.print(getChannelName(i)); Serial.print(':'); Serial.print(VALUES[i]); Serial.println(BLANK);  // Schnittstelle bei Arduino

4

    }

Nur eine Umsetzung des Powerlimit sehe ich im Arduino leider nicht. Ich habe nur im github von Stefan123 das hier gesehen: Und hier das Power Limit setzen

1

51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B

2

^^------------------------------------------------ MainCmd 0x51 DEVCONTROL_ALL

3

   ^^^^^^^^--------------------------------------- WR Serial ID

4

            ^^^^^^^^------------------------------ DTU Serial ID

5

                     ^^--------------------------- SingleFrameID

6

                        ^^------------------------ SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr

7

                        ^^^^---------------------- Control Mode

8

                             ^^^^----------------- PowerPFDev.SetValut 0x012C = 30.0 W

9

                                  ^^^^------------ PowerPFDev.Desc 0x0000 oder 0x0001 ?

10

                                       ^^^^------- CRC16 / CRC-Modbus über die Daten, excl. Frame ID!

11

                                            ^^---- CRC8

Gibt es da schon eine Umsetzung am Arduino oder habe ich die im Code überlesen ?

Dieser Riesen-Thread hat zu der genialen OpenDTU geführt. Ich habe zwei davon in Einsatz - super. Danke an alle.

Ich habe mir für einem M5Stack eine WLAN Anzeige mit Logging und eingebautem MQTT Broker geschrieben. Damit ist ein MQTT Broker im Hausnetz nicht mehr Voraussetzung um im ganzen Haus die Solardaten anzeigen zu können.

Wer Interesse hat -

https://www.gadgetpool.eu/product_info.php?products_id=104

Ja, ist ein Shop. Aber unten findet sich auch der Download für die Software. Wenn jemand also eine M5Stack und einen OpenDTU hat und eine WLAN Anzeige im Haus haben möchte - einfach ausprobieren.

Gruss Frank

Frank W. schrieb:

Wenn jemand also eine M5Stack und einen OpenDTU hat und eine WLAN Anzeige im Haus haben möchte - einfach ausprobieren.

sehr gut gemacht :-)

Aber braucht es wirklich einen M5-Stack? Die Teile kosten 100€

Einfach einen ESP32 mit irgendeinem Display?

Heinz R. schrieb:

Aber braucht es wirklich einen M5-Stack? Die Teile kosten 100€

Einfach einen ESP32 mit irgendeinem Display?

Geht sicher. Habe dem M5 Stack genommen wegen WAF, Fertiges Gehäuse mit Taster, Batterie.

Bis ich das selbst gebastelt habe wird es wahrscheinlich auch nicht fürchterlich viel billiger.

Aber gehen wird das sicher

Die Teile sind halt - meine Meinung - unglaublich hässlich und preislich total überzogen

Heinz R. schrieb:

Frank W. schrieb im Beitrag #7474079: Einfach einen ESP32 mit irgendeinem Display?

Der ESP an der Wechselrichter-zu-WLAN-Brücke spuckt doch alles per UART aus. Da kann man sich dranstricken, was man braucht. Bei mir werkelt da noch ein 433MHz Umsetzer dran, der die Daten in den Keller schickt, wo ich sie in eine eigene Steueranlage einspeise. Bisschen Programmierarbeit für Funkprotokoll und Absicherung und 10 Minuten löten, dann war´s fertig.

HMS und HMT Wechselrichter von Hoymiles dürften nun durch Tausch des Funkmoduls ebenfalls unterstützt werden. Gute Nachricht für mich, da ich vorhabe alles umzurüsten.

Hallo, gibt es einen Befehl für den Hoymiles-400/800 mit dem man den MPPT Tracker abschalten kann. Verwende openDTU zu Steuerung. Der HM-400 hängt an einer Batterie, und da ist der MPPT Tracker eher schlecht.

Super wenn es das schon gibt.

Rolf

Mir ist nichts bekannt

Wieviel Volt hat Dein Akku? Bei 48V funktioniert das auch so problemlos

OpenDTU sagt, dass nach der Limitierung auf einen Absolutwert bis zu 4 Minuten vergehen können bis die Anzeige aktualisiert wird. Bei Limitierung auf relativen Wert scheint das nicht so zu sein. Kennt jemand den Grund dafür?

Danke

Grisu schrieb:

HMS und HMT Wechselrichter von Hoymiles dürften nun durch Tausch des Funkmoduls ebenfalls unterstützt werden. Gute Nachricht für mich, da ich vorhabe alles umzurüsten.

Möchtest du uns mitteilen warum die umrüstest.

Natürlich sind HMS und HMT gegenüber HM überlegen, gerade wenn es um direkte Erzeugung von 3-Phasen geht.

Im Vergleich zur HM Serie aber gerade bei den kleineren (Einphasigen) doch noch relativ teuer und was ich richtig schlecht finde ist diese Busbar die man braucht. Für einen nicht intelligente "Klemme"/"Stecker" find ich den Preis etwas überzogen.

Für Installateure die eh 10 oder mehr davon bei einer Fläche einstecken verkabeln müssen sehr ich den Vorteil aber bei Privatpersonen?

Oder gibt es noch weitere Vorteile, die ich noch nicht kenne?

Hallo Zusammen, ich habe eine kleine Frage zu unser aller Hobby :-) Mein AHOY läuft seit 5 Monaten super, Version 0.6.9. Seit dem 24.08. kommen bei Bedarf aber keine 600 W mehr aus dem Hoymiles HM-600 raus, nur noch so 280W. Gleichzeitig zeigt die Efficiency nur noch 50% an. Ich betreiben den Wechselrichter direkt an einer 8S Batterie. Wenn ich die Solarzellen direkt anstecke, kommt aus dem CH1 nix raus. Mit Batterie zeigt CH1 aber halbwegs plausible Werte an. Hat jemand schonmal beim Hoymiles ein Chanel abgeschossen? Gibts da eine Sicherung o.ä.? Ein Update auf die neuste SW bringt vermutlich nichts, ich denke es liegt ein HW-Fehler vor.

Ich wünsche euch einen sonnigen Tag :-) viele Grüße, stefan

Alexander H. schrieb:

Möchtest du uns mitteilen warum die umrüstest.

Natürlich sind HMS und HMT gegenüber HM überlegen, gerade wenn es um direkte Erzeugung von 3-Phasen geht.

Im Vergleich zur HM Serie aber gerade bei den kleineren (Einphasigen) doch noch relativ teuer und was ich richtig schlecht finde ist diese Busbar die man braucht. Für einen nicht intelligente "Klemme"/"Stecker" find ich den Preis etwas überzogen.

Für Installateure die eh 10 oder mehr davon bei einer Fläche einstecken verkabeln müssen sehr ich den Vorteil aber bei Privatpersonen?

Oder gibt es noch weitere Vorteile, die ich noch nicht kenne?

Also Umrüstung von (etwas großspurigem) Balkonkraftwerk auf "richtige" PV.

Da ich aber den Vorzug alles selbst zu machen sehr schätze und die Hochspannung am Dach vermeiden möchte installiere ich nun das Maximum 6x HMT-2250. Soviel geht sich grad aus mir 460W-Panelen. Die T-Connetor Stecker waren bei meinem holländischen Anbieter debei (ohne Aufpreis). Also die für mich etscheidenden riesigen Vorteile: 1.) KEINE Hochspannung, keine Sicherheitsabschaltung nötig und null Probleme mit der Feuerwehr. 2.) Wenn was hin ist dann höchstens ein WR der sich wegschaltet oder man leicht abstecken kann. Tausch/Reparatur kann dann irgendwann erfolgen wenns wieder schön ist. Die restlichen 5 produzieren munter weiter. 3.) Verschattung ist kein Thema, da alle Module einzeln angeschlossen werden. Es wird somit immer voll produziert. 4.) Mit openDTU volle Kontrolle über das System, selbst wenn Hoymiles in ein paar Jahren ihre Plattform vielleicht dicht macht (ist ja seit Jahren nur Beta) 5.) Ganz leicht erweiterbar, oder auch reduzierbar 6.) Preis ist denk ich sehr gut und sofort lieferbar. 2,2kWp um unter 500€ (inkl. MWSt bei uns), also 13,5kWp um 3.000€, glaub da gibts teurere Angebote.

Nachteil: Man kann nicht einfach die Module miteinander verbinden sondern muß jedes einzeln zum WR verkabeln. Aber in Eigenbau ist das eben eine Zeitfrage, bei einer Firma würde das teuer werden.

Grisu schrieb:

Also Umrüstung von (etwas großspurigem) Balkonkraftwerk auf "richtige" PV. [...]

Danke für deine Ausführungen. Genauso ging es mir auch. Ich kam auch von einem Balkonkraftwerk und habe dann alles selber mit den Modul WRs gebaut. Genau wie aus deinen genannten Gründen.

Vieleicht noch ein Nachteil den man bedenken sollte: Einen Akku nachrüsten ist nicht ganz einfach und auch nicht günstig, da man für den Akku dann wieder einen WR braucht. Aber das ist ja ein anderes Thema.

Meine Frage war eher halt dahin gehend, warum HMS und nicht HM? Da ist zumindest ein Preisunterschied in Summe dann.?

Alexander H. schrieb:

Meine Frage war eher halt dahin gehend, warum HMS und nicht HM? Da ist zumindest ein Preisunterschied in Summe dann.?

Habe HMT genommen, da 3-phasig (und neuer obendrein) im Gegensatz zu den einphasigen (älteren) HMS und auch HM. Ist halt doch wesentlich einfacher nur ein Starkstromkabel zu brauchen dafür und das Verbindugngssystem zum Anhängen und Serisieren/Erweitern ist ja auch recht einfach. Größere PV genehmigen sie auf einzelnen Phasen ja gar nicht. Da wirds dann mit HMS mühsam, wenn die nicht alle ident produzieren.

Grisu schrieb:

Größere PV genehmigen sie auf einzelnen Phasen ja gar nicht. Da wirds dann mit HMS mühsam, wenn die nicht alle ident produzieren.

Gebe ich dir zu 100% recht.

Ich babe bei mir 8x HM unterschiedlicher Größe, 5x den HM-1500. Habe 3 Dachseiten (Ost, Süd, West) teilweise bestückt und jede Dachseite auf eine Phase aufgeteilt. War aber in der Tat etwas mehr Arbeit an Verdrahtung und Kabel.

Ich habe mal was mit Virtuino IOT gebaut, macht aus den HoymilesDTU Json Daten eine Anzeige. Wenn Virtuino noch Curl oä für die Leistungsbegrenzung per Http könnte, ein Traum ;-) https://youtu.be/CwgmrcxG7hQ und https://www.youtube.com/watch?v=n8syQqeMyiw

Hallo, ich habe gerade updatet (von 0.6.9 zu 0.7.36). Soweit alles gut, nur ein Problemchen ist gleich aufgetaucht: Nach jedem Neustart aktualisiert sich die ESP-System-Zeit nicht mehr automatisch, wie das vorher war. Ich muss manuell auf "sync from browser" klicken. Wenn die Systemzeit nicht eingestellt ist, verbindet sich auch MQTT nicht. Und das ist nicht gut. Die Einstellungen sind gleich (NTP-Server) wie in meiner vorheriger ver. 0.6.9 Gibt es da etwas, was ich noch einstellen muss? Sonst muss ich zurück zu v0.6.9

Vielen Dank im Voraus

Funktioniert hier seit Anbeginn (begonnen mit v0.5.16) einwandfrei. Hast du DHCP aktiviert? NTP Einstellung bei mir wie folgt: Server: pool.ntp.org Port: 123 Intervall: 720s (5 Min.)

die NTP Einstellungen habe ich gleich wie bei dir (sind default). Das war auch in der ver 0.6.9 gleich. DHCP habe ich nicht aktiviert, habe feste IP für Ahoy folgend konfiguriert: IP Address:192.168.178.46 Submask:255.255.255.0 DNS 1: (leer gelassen) DNS 2: (leer gelassen) Gateway:192.168.178.1

So hat das bis jetzt auch problemlos funktioniert (in ver 0.6.9). Ob die feste IP so richtig konfiguriert ist, bin ich nicht ganz sicher :-)

Ich habe jetzt aber eine neue Inverter-Einstellung gefunden (in ver 0.7.36), welche in der ver 0.6.9 nicht vorhanden war: "Start without time sync" Wenn ich das erlaube, dann funktioniert der Neustart (reboot) wie vorher. ESP-SystemZeit wird auch gleich automatisch eingestellt und MQTT startet auch. Woher die richtige Zeit genommen wird, keine Ahnung :-)

Hallo, setze mal den Dns 192.168.178.1 wie dein Gateway - dann sollte es funktionieren Gruß Sven

Sven K. schrieb:

Hallo, setze mal den Dns 192.168.178.1 wie dein Gateway - dann sollte es funktionieren Gruß Sven

Interessante Aussage! Wie kommst Du zu der Erkenntnis, dass beim Fragesteller auf dem GW 192.168.178.1 ein DNS-Server oder Forwarder läuft? Bitte bei Unkenntnis keine Tipps geben.

Ggf. wäre es zielführender, statt z.B. pool.ntp.org die passende IP-Adresse einzutragen und dann nochmal zu testen.

Daniel schrieb:

Bitte bei Unkenntnis keine Tipps geben

mit dem linken Bein aufgestanden heute?

Ist schon einigermaßen naheliegend, daß sein Modem 192.168.178.1 hat und DNS anbietet fürs Heimnetz.

Daher hätte ich auch DHCP vorgeschlagen gehabt, damit auch der DNS mitübergeben wird. Fixe IP-Vergabe vorzugsweise im Modem einstellen für die gewünschten Geräte, dadurch erspart man sich genau diese Probleme den Aufwand, die überall manuell eingeben zu müssen - und erhalten dennoch immer die selbe gewünschte IP.

Danke, jetzt funktioniert es. Wie von Grisu vorgeschlagen, habe ich in Ahoy-DTU alle Network-Parameter leer gelassen um DHCP zu aktivieren. Die Inverter-Einstellung "Start without time sync" habe ich auch wieder deaktiviert. In meiner FritzBox habe ich für dieses Gerät Fixe IP eingestellt. Jetzt funktioniert nach dem reboot alles normal.

Auch wenn meine andere ESP8266 Geräte gut funktionieren, werde ich das wahrscheinlich überall so einstellen ... es ist so wahrscheinlich vernünftiger ... obwohl ich nicht verstehe, warum :-) Ist aber egal, ich muss nicht alles verstehen :-)

PS: ja, mein Modem/FritzBox hat 192.168.178.1

Weil du keinen DNS angegeben hattest, der den Namen des ntp-Servers hätte auflösen können auf eine IP-Adresse. Mit DHCP wird auch der DNS an den Client kundgetan. Vereinfacht halt die ganze Verwaltung wenn man es zentral am Modem einträgt für alle gewünschten Clients und die einfach auf DHCP läßt.

Heinz R. schrieb:

Daniel schrieb:

Bitte bei Unkenntnis keine Tipps geben

mit dem linken Bein aufgestanden heute?

Das kommt immer auf den Tag und das Bein an. Hast Du auch fachlich etwas beizutragen?

Hallo, was bedeutet dieser Wert in den Inverter Einstellungen?: "Yield Effiency (should be between 0.95 and 0.96)"

Ich habe dort 1 (defaul). Werden mit diesem Faktor die Yield-Zähler korrigiert (Yield Day, Yield Total)?

Danke.

Ich nehme an das sind einfach nur die Leistungsverluste des WR zw. DC-Einspeisung und AC-Abgabe. Yield ist der Ertrag (erzeugte Energie also).

Ich habe hier 2 x OpenDTU

• der eine liest 3 x HMS-2000 aus
• der andere 4 x HM-1200

was mich jetzt wundert:

Schaue ich abends nach Sonnuntergang ins Webinterface:

Bei den HM-1200 steht der Tagesertrag Bei den HMS-2000 ist nach Sonnenuntergang der Tagesertrag auf Null gesetzt

die OpenDTU für die HMS-2000 läuft auf Firmware 23.6.28 Die HM-1200- noch Version 23.5.9

Ich hatte mal Ahoy installiert - dort konnte man einstellen wann was resetet wird - bei OpenDTU finde ich hier keine Einstellung?

Würde gerne abends beim Geierabendbier sehen was die Anlagen jeweils gebracht haben - was mache ich falsch?

Grüße

Ich habe sowohl eine Ahoy als auch eine OpenDTU in Betrieb. Beide zeigen auch nach dem Sonnenuntergang noch den Vortageswert an bis zum Morgen. Ahoy grau unterlegt, OpenDTU ganz normal wie auch untertags.

Solltest vielleicht doch einmal überlegen die aktuelle Version zu verwenden. ;-) Und ich habe bei Wechselrichter Senden/Empfangen nur "Daten abrufen" aktiviert und bei NTP die "bürgerliche Dämmerung" eingestellt, sollte aber ohne Bedeutung sein.

Grisu schrieb:

Beide zeigen auch nach dem Sonnenuntergang noch den Vortageswert an bis zum Morgen. Ahoy grau unterlegt, OpenDTU ganz normal wie auch untertags.

Hast Du HM oder HMS-Wechselrichter?

Bei mir sind bei beiden die Einstellungen gleich

Auf Ahoy sind HM (da nur ESP8266) und auf der OpenDTU hängen HMT.

Nur, warum machst nicht erstmal ein Update auf gleiche Stände, um nur irgendwas sinnvoll vergleichen zu können?

Grisu schrieb:

Nur, warum machst nicht erstmal ein Update auf gleiche Stände, um nur irgendwas sinnvoll vergleichen zu können?

der für die Abends nichts anzeigenden HMS-WR zuständige hatte ich bereits upgedatet

Aber bin jetzt deinem Ratschlag gefolgt, beide ESPs sind auf Version v23.9.18

Das leider ernüchternde Resultat:

• OpenDTU mit 4 x HM-1200 zeigt auch jetzt bei Dunkelheit den Tagesertrag an
• OpenDTU mit 3 x HMS-2000 zeigt jetzt bei Tagesertrag null an

Unterschiede in den Einstellungen finde ich keine

Gibt es sonst jemand mit HMS-WR? Was wird hier abends angezeigt?

Heinz R. schrieb:

Gibt es sonst jemand mit HMS-WR? Was wird hier abends angezeigt?

es wird immer merkwürdiger

aktuell zeigen nach Sonnenuntergang 2 der 3 HMS-WR den Tagesertrag an, bei einem steht der auf Null?

Vielleicht schlechter Empfang zu dem und aufgrund aussetzender Werte dann das Bild ... Oder was mir noch einfiele dazu. Vielleicht schaltet der wegen Überspannung auf der Phase im Netz ab bzw. weil er der hinterste in der Reihe ist mit der folglich höchsten Spannung die grad schon das Abschalten bewirkt, dann ist für ihn ja ein neuer Tag wo er noch nichts produziert hat. Beobachte ihn halt mal einen ganzen Tag lang bzw. sie dir die MQTT-Einträge an.

nein, es muss ein anderes Problem sein

Jetzt ist die Snne seit 4 Stunen weg 2 von 3 HMS zeigen beim Tagesertrag je ca. 9 kWh an - das passt und wird so in der Gesamt-Tagessumme auch angezeigt Der 3. HMS zeigt beim Tagesertrag 0 an

Die 4 HM zeigen jetzt alle beim Tagesertrag realistische Werte an

Hängt sich ein ESP32 und openDTU mit der Zeit auf? Lief eigentlich klaglos, jedoch nach dem letzten Update vor einigen Tagen auf v23.9.18 hat er heute keine Werte mehr übertragen bekommen vom WR. Neustart änderte nichts daran, dachte schon der WR wäre über Nacht ausgefallen. Kurz die DTU vom Strom genommen und nun geht es wieder.

Passiert das anderen hier auch oder Einzelfallproblem?

Hier läuft das seit Monaten problemlos mit Version 23.4.25.

Moin Leute, hatte mir den AhoyDTU für meinem Hoymiles HM-600 gebaut und das lieft auch schon ein paar Wochen ganz gut. Gestern habe ich den Standort vom AhoyDTU geändert und da er dadurch näher an meinem zweiten Router gekommen ist auch den WLAN Zugang angepasst. Jetzt sehe ich nur noch eine abgespeckte Version des Menue mit den Punkten -AhoyDTU -Rest API -Documentation -About

alles andere wird nicht mehr angezeigt. Auch der Punkt settings nicht, um das wieder rückgägngig machen zu können. Seltsamerweise werden die Daten offensichtlich weiterhin in HomeAssistant eingespeist, da kommt es im Energiedashboard jedenfalls an. Für einen schnellen Blick ist mir die weboberfläche von AhoyDTU aber lieber. Was könnte ich tun?

Danke Hardy

Na dann hast wohl auch ein FW-Update gemacht und mußt vorher am Ahoy anmelden (Login).

Grisu schrieb:

Hängt sich ein ESP32 und openDTU mit der Zeit auf? Lief eigentlich klaglos, jedoch nach dem letzten Update vor einigen Tagen auf v23.9.18 hat er heute keine Werte mehr übertragen bekommen vom WR. Neustart änderte nichts daran, dachte schon der WR wäre über Nacht ausgefallen. Kurz die DTU vom Strom genommen und nun geht es wieder.

Passiert das anderen hier auch oder Einzelfallproblem?

Das passiert bei mir auch seit ein paar Firmware-Versionen. (Also die Aktuelle v23.10.9, v23.9.18 und v23_9_13) Ich habs so gelöst dass ich den ESP ein oder zwei mal in der Woche in der Nacht kurz vom Strom nehme.

Ich habe schon einen 3,3V / 1,5A Festspannungsregler extern angeschlossen weil ich vermutet habe dass der kleine Onboard-Regler kurzzeitig überlastet ist und der ESP in Brown-out geht. Der hat das Problem aber nicht behoben. (Das Netzteil war erst ein 25W Handyladegerät, jetzt ist es ein 9V, 30VA Trafo)

Ich hab schon überlegt einen externen Watchdog anzuschließen der das Aus-/ Einstecken für mich übernimmt.

Danke für deine Rückmeldung, dann besteht ja zumindest die Hoffnung, daß jemand den Fehler entdeckt und dieser behoben werden kann.

Mir ist es mit Annex ESP32Basic gelungen so ein AZ-Wanddisplay zur Anzeige von Hoymiles Wechselrichter mit OpenDTU zu programmieren. Inzwischen kann ich auch die Leistung über ESP32 Annex Basic einstellen. Also nicht über MQTT sondern per in Annex ESP32Basic übersetztem Curl Befehl. Wenn man also z.B. einen Shelly EM per Json abfragt, könnte man ohne andere Server (z.B. MQTT-Broker, Openhab, Symcon o.ä. die Nulleinspeisung in diesem ESP32 per ESP32 Annex Basic regeln. Guggst Du https://cicciocb.com/forum/viewtopic.php?p=5404#p5404

so was bekommst auch mit ESPEasy sehr einfach hin, eagl ob jetzt per MQTT oder direkt Selbst Touch ist dort rel. einfach umzusetzen

wlog WPOST$("http://admin:password@192.168.x.x/api/limit/config", |data={"serial":"1234567890", "limit_type":1, "limit_value":50}|, 0, "application/x-www-form-urlencoded") Das ist der Befehl in ESP32 Annex Basic um die Leistung zu stellen. Vorher status Abfrage machen. Ganz ohne MQTT Brokker oder andere Geschichten. @Heinz zeige mir den Befehl in ESPeasy, der das Gleiche macht. Und wenn das nicht klappt wenigstens die Parameter und Listings für die Displaydarstellung.

Helmut H. schrieb:

@Heinz zeige mir den Befehl in ESPeasy, der das Gleiche macht. Und wenn das nicht klappt wenigstens die Parameter und Listings für die Displaydarstellung.

mit Leistungslimits habe ich mich zugegeben nie beschäftigt, ich habe hier eine offiziell Angemeldete Anlage die auch einspeisen darf

Aber laut https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md

curl -u "admin:password" http://192.168.10.10/api/limit/config -d 'data={"serial":"11418180xxxx", "limit_type":1, "limit_value":50}'

Ein ganz normales HTTP Post.. Klar, curl gibt es in ESPEasy nicht :-)

Parameter und Listings? Ich habe für meinen Herrn Papa eine kleine 7Segment-Anzeige gebastelt die sich den Wert von OpenDTU holt

Wenn es unbedingt kein MQTT sein darf legst halt in ESPEasy ein Dummy-Device an, holst Dir alle paar Sekunden den Wert aus OpenDTU, das ist ja gut dokumentiert

das Display kannst z.B. so beschreiben:

on wasacuhimmer#abc do tft,rf,10,10,300,60,red,red tft,txtfull,110,55,3,white,black,rot endon

Aber irgendwann wirst merken das so ein MQTT-Server durchaus seinen SInn hat - macht vieles einfacher, und es gibt auch öffentliche..

Ein mächtiges Hallo in die Runde! Ersteinmal vielen Dank für Eure Arbeit zum OpenDTU! Nun zu meiner Frage, ist es möglich auch ein anderes SPI-Display mit der Auflösung 128x64 pixel zu nutzen? Das Display besitzt einen Sitronix ST7565R-G Controller und den habe ich erfolgreich mit der u8glib mit den ESPs in Betrieb. Und wenn ich das richtig heraus gelesen habe, wird ja in dem Code für die OPEN DTU auch die Lib benutzt. Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display einbinden kann? Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und C++ Programme gearbeitet, wie kann ich dann den Code compelieren? Ein Tip und Hilfe würde ich mich sehr freuen. Grüße MAT

Matthias S. schrieb:

Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display einbinden kann? Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und C++ Programme gearbeitet, wie kann ich dann den Code compelieren?

Zur ersten Frage kann ich nichts antworten, aber diese wäre sicher besser in den "Discussions" auf https://github.com/tbnobody/OpenDTU/ aufgehoben. Eine Anleitung zum Kompilieren findest Du unter "Flashing and starting up" ebenfalls auf GitHub.

Daniel schrieb:

Matthias S. schrieb:

Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display einbinden kann? Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und C++ Programme gearbeitet, wie kann ich dann den Code compelieren?

Zur ersten Frage kann ich nichts antworten, aber diese wäre sicher besser in den "Discussions" auf https://github.com/tbnobody/OpenDTU/ aufgehoben. Eine Anleitung zum Kompilieren findest Du unter "Flashing and starting up" ebenfalls auf GitHub.

Hallo Daniel, danke für adeinen Hinweis, habe dort auch schon die Frage platziert. Dachte bei der Regen Teilnahme hier, dass es ein Hinweis geben könnte. MAT

Grisu schrieb:

Vieleicht noch ein Nachteil den man bedenken sollte: Einen Akku nachrüsten ist nicht ganz einfach und auch nicht günstig, da man für den Akku dann wieder einen WR braucht. Aber das ist ja ein anderes Thema.

Das ist gar nicht so teuer. Und vor allem ganz einfach. Ein Multiplus II reicht. Gibt es ab 500€. Der kann alles was man zu einem AC gekoppelten Speicher braucht, dazu braucht es noch eine Steuerung. Wenn man nicht zu viel Basteln will nimmt man ein Cerbo GX (das -S hat kein CAN BUS für Batterien) für etwa 200€ und Bastelafine nehmen dafür einen Raspi. Im youtube gibt es einige Kanäle, wie etwa Schatten PV, Kleines Zuhause und andere die genau zu diesem Punkt Thema Videos gemacht haben. Der Multiplus wird mit AC Out einfach an den Verteiler angeschlossen und Batterie dran. Fertig ist. Das ist natürlich nicht Schwarzstart fähig, aber das wird denke ich überbewertet. Wer will kann am AC In noch eine Notsromsteckdose anschliessen die Strom abgibt so lange der Akku Saft hat.

Was sagt ihr dazu? Hat jemand mehr Details? https://www.cleanthinking.de/bnetza-hoymiles-hm-800-wechselrichter/

Alexander H. schrieb:

Was sagt ihr dazu? Hat jemand mehr Details? https://www.cleanthinking.de/bnetza-hoymiles-hm-800-wechselrichter/

Da hier wohl keine Antwort erfolgt und das auch nicht wirklich der richtige Platz ist, zumindest ein Link mit weiteren Infos und Stellungnahmen:

https://www.photovoltaikforum.com/thread/226815-hm-800-von-der-bundesnetzagentur-vom-markt-genommen/

Ergo: Betrieb der WR weiter kein Problem, Vertrieb aber (vorläufig) eingestellt.

Tim T. schrieb:

Hintergrund ist, das ich noch einen ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP nicht brauche und auch nicht will. Es reicht mir wenn das mein Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino empfängt und entsprechend aufarbeitet.

um damit 2€ zu sparen?

Merkwürdige Vorstellung....

Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler mit einem Vollwertigen System machen kann, was die Daten sehr einfach exakt so aufbereitet wie ich es will?

Ja, das verstehe ich. Die Community um AhoyDTU und OpenDTU mit ihren instabilen ESPs können nur irren. Ein vollwertiges System mit einem Arduino ist da ohne Alternativen.

Tim T. schrieb:

Und schon wieder absolut unnötiges Geblubber

sorry, in meinen Augen nicht so - es wurde halt was vernünftig mit aktuellen Prozessoren umgesetzt

Tim T. schrieb:

Fakt ist nunmal das die ESP sehr wählerisch bei der Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist, hängen sie sich auf.

Wie kommst Du auf solche Ausssagen?

Tim T. schrieb:

Dazu kommt dann irgendwelche überfrachtete Software die alles andere als ausentwickelt ist und weitere Probleme macht, wobei ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und der ganze Rest nur unnötiger Raffel ist.

Ziemlich freche Aussage - warum bettelst hier und programmierst nicht selber kurz was?

Tim T. schrieb:

Wer das nicht verstehen will, dem kann ich auch nicht helfen.

Du hast sicher auch nur 3beinige Tische daheim - das 4. Bein ist unnützer Ballast? :-)

Tim T. schrieb:

Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm ab:

1. Brauche ich eine komplexere HMI-Schnittstelle (Display, Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC
2. Einfache Sachen aber mit WLAN: ESP32
3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32
4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum: ATtiny
5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino.

Und das hat genau garnix mit dem Thema zu tun.

dann mach das doch gerne so - aber nicht beleidigt sein wenn hier 99% anders denken

Du hast wahrscheinlich auch 2 Autos, eins mit, eins ohne Servo - vor der Fahrt wird Einsatzenstsprechend gewählt?

@Tim Taylor (DER Heimwerkerking? ;-) ): Ich sehe da kein Problem mit dem Arduino-Interface und ich weiss nicht, warum hier so emotionale Diskussionen entstehen. ;-) => Im entsprechenden github Repository https://github.com/lumapu/ahoy findest Du Doku über das Protokoll, die Sourcen und auch Hardware, etc. Damit sollte es easy sein, die Parameter Deines WR auszulesen.

@Heinz R: Die Anfrage von Tim ist doch kein Grund, missionarisch zu werden. ;-) Die ESPs sind nicht schlecht, haben aber auch durchaus ihre Schwächen. Ich verstehe seinen Ansatz, einfach einen Arduino als kleinen Protokollwandler/Interface für einen Rechner o.ä. einsetzen zu wollen.

Und jetzt vertragen wir uns alle mal wieder. ;-) :-)

Cheers!

Zum Thema ESPxx - Abstürze

Man hat hier mit den tollen Ahoy / OpenDTU Projekten viele zig tausend Testuser - die Foren sind bemerkenswerter Weise nicht voll mit "stürzt ständig ab" usw

Ich bin gespannt auf Deine Arduino-Implementierung - ich hoffe Du veröffentlichst die dann auch im Sinne der Projekte entsprechend - es ist ja dann ein gewaltiger Schritt nach vorne - wesentlich mehr Zuverlässigkeit - wobei Du von den Erkenntnissen und Forschungen anderer profitierst

Nicht böse gemeint - aber Dein Beizrag kommt irgendwie rüber wie "schön das Ihr da was gebastelt habt - gebt mal den Code rüber, dann mache ich es richtig"

@Tim Taylor

Du nimmst wohl an, dass alle anderen wenig Ahnung von der Materie haben, was Deine Aussagen unterstreichen wie "Ja, nicht jeder versteht das KISS Prinzip." Du diffamierst eine Entwicklergruppe mit ihrem Projekt pauschal mit Zitat: "irgendwelche überfrachtete Software, die alles andere als ausentwickelt ist und weitere Probleme macht". Aber dann sagst Du wieder, Projekte bei "Einfache Sachen aber mit WLAN: ESP32" umzusetzen, was nicht wirklich zusammenpasst. Nebenbei: Ich bin Informatiker und kenne das "KISS-Prinzip" seit vielen Jahren und habe Projekte mit unterschiedlichen Mikrocontrollern umgesetzt. Also bitte keine derartigen unbelegten Thesen in einem Fachforum.

Ich habe selbst mehrere Projekte mit dem ESP32 auf Basis AhoyDTP (mehrere Mikrowechselrichter der HM-Serie) und OpenDTU (HMS-Serie) umgesetzt. Diese ESP laufen störungsfrei ununterbrochen seit vielen Monaten. Deine genannten "Instabilitäten" sind daher lediglich eine Behauptung, die ohne Nennung einer bestimmten (evtl. problematischen) Hardwarekonstellation keine Grundlage hat. Bei den ESP8266 stimme ich Dir unter bestimmten Bedingungen zu, aber das war ja nicht Dein Thema.

Auch nebenbei: Projekte wie "Tasmota" sind praktisch die Open Source-Referenz im ESP-Bereich. ESPs auf dieser Basis laufen (auch bei mir) problemlos seit Jahren ohne Ausfall. Vorschlag: Wende Dich doch mit Deinem Problem und genau mit Deinen bisherigen Aussagen direkt an die Hauptentwickler der beiden Projekte auf GitHub. Mich würde dann aber interessieren, wie das dann dort ankommt und wie Dir geholfen wird.

Tim T. schrieb:

Nach welchem Schema läuft das Channelhopping ab?

Hallo Tim, ich war ganz am Anfang des Threads an der Protokollanalyse beteiligt, unter anderem auch als es um das Channelhopping ging. Dabei wurde mal das Gazelle Protokoll von nRF in den Raum geworfen. Das Thema wurde dann aber nicht weiter verfolgt, weil man mit dem nRF24L01 das Hopping ja irgendwie nachbilden konnte - aber um es nochmal aufzugreifen:

Das Channelhopping dürfte nach dem "Gazelle Link Layer" von nRF aufgebaut sein (der nRF24L01 als pures RF Interface unterstützt dies nicht!): https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/gazell/gzll.html

Dabei ist der Wechselrichter der Host, der in definierten Timeslots auf gewissen Kanälen horcht und dann auf den nächsten wechselt (bei Hoymiles waren das 3, 23, 40, 61, 75). Mit einigen SoCs von nRF kann das GZLL implementiert werden, z.B. mit dem nRF51822, der abwärtskompatibel mit dem Funkprotokoll des nRF24L01 bzw. dem in der Original DTU verwendeten nRF24LE1 ist.

Wenn du also sowieso nochmal vorne anfängst, wäre es vielleicht eine Überlegung das mit einem nRF51822 zu versuchen. Da dieser ein SoC (Cortex M0) ist, könntest du sogar direkt serielle Daten rausgeben ohne Arduino. Den nRF51822 gibt es ähnlich günstig wie den nRF24L01 - nur leider nicht mit PA/LNA, was der Reichweite zugute kommen würde...

Lieber Tim,

wäre es nicht besser für Dich , für die Menschheit generell wenn Du Dich einfach aus solchen Dingen komplett raus hälst?

Entwickle gerne Deine eigene Steuerung - aber Deine Überheblichkeit und Besserwisserei - unglaublich

Ja, es gibt sicher sehr viele gute Ingenieure die wesentlich bessere Lösungen gefunden haben - ganz ohne Bedürfniss diese in Github usw teilen zu müssen, sie einfach für sich einsetzen

Aber Deine Reaktion ist mir zugegeben sehr unverständlich

Tim T. schrieb:

Jop, aber das ist nicht der Punkt. Es hätte hier im Thread nicht um eine Steuerung gehen sollen, sondern um das Protokoll dafür und das wurde hier gründlich vergeigt.

Tim T. schrieb:

Meine Steuerung läuft und die von dir genannte Überheblichkeit und Besserwisserei sind nur Fakten.

Tim T. schrieb:

Das glaube ich dir sogar. Du verstehst eben nicht den den Vorteil eines sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer gearteten, Implementierung einer Steuerung dafür.

Dann bitte, mach es besser. Sollten wir von dir keine saubere Dokumentation bekommen ist alles von dir nur erbärmlich.

Tim T. schrieb:

Du verstehst eben nicht den den Vorteil eines sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer gearteten, Implementierung einer Steuerung dafür.

Dir ist aber schon klar das hier nicht ein"Protokoll neu entwickelt wurde sondern ein von Hoymiles strikt geheim gehaltenes Protokoll geknackt wurde?

Klar ist das für DIch jetzt einfach - mit dem Wissen und der Forschung anderer das auf Deinen bevorzugten Microcontroller zu adaptieren

Wenn alles so einfach ist - warum fragst dann überhaupt hier? Hättest doch alles für Dich entwickeln können

Mit selbst entwickeln meine ich DU hast den WR , evtl. eine DTU, sonst nichts - leg los....

Tim T. schrieb:

Ich zitiere nicht Deine bisherigen Beiträge, diese stehen für sich und waren teilweise sogar noch schärfer formuliert, bevor Du sie selbst nochmals bearbeitet hast. Inhaltliche Kritik ist ja in Ordnung, aber das geht eindeutig zu weit. Gut gemeinter Rat: Arbeite bitte intensiv an Deiner Sprache und an Deiner sozialen Kompetenz. Es könnte Dir im Alltag nützlich sein. Daneben stimme ich den Vorpostern zu. Bringe Dein Fachwissen doch hier positiv zum Thema ein, Du nimmst dieses ja für Dich in Anspruch.

Lieber Tim,

was ist das was Du hier abziehst?

Ein Versuch wie KI funktioniert?

Ein Versuch - wie weit kann ich Forumsteilnehmer treiben?

Hinter Deinem Geschwätz kann auf keinen Fall ein normaler Mensch mit gesundem Menschenverstand stehen Dir geht es nicht um Hoymiles-WR sondern um irgend was ganz Anderes?

Hallo!

Jemand, der (wie ich) möglichst einfach die Livedaten von einem Hoymiles HM... Wechselrichter abrufen will, wird vielleicht hier fündig: https://github.com/sulmfish/pico_nrf_hm. Ist Micropython-Code und läuft (z. B.) auf einem Raspberry Pi Pico mit NRF24L01+-Modul.

Entschuldigung, dass ich diesen schon recht alten Thread wieder ausgrabe, aber ich beschäftige mich gerade mit der Kommunikation eines HM- Wechselrichters über das enhanced Shockburst Protokoll. Ziel ist eine intelligente Steuerung der Einspeiseleistung, die über die klassische Nulleinspeisung hinausgeht. Das Ahoy-Wiki https://github.com/lumapu/ahoy/wiki/Protocol habe ich gelesen, werde aber nicht richtig schlau daraus. Es würde mir sehr viel weiterhelfen, wenn mir jemand hier folgende 3 Fragen beantworten könnte:

1. Nutzt das Protokoll die Auto-Ack-Funktion mit automatischer Sendewiederholung?
2. Manche Pakete sind mit 0x7E und 0x7F eingerahmt, andere nicht. Welches Format ist richtig?
3. Offenbar wird ein Channel-Hopping über 5 Kanäle genutzt. Laut Wiki ist der Sendekanal des nrf24l01+ auf 40 = 2040 MHz festgelegt und es wird nur der Empfangskanal gewechselt. Ist das so OK? Wann wird der Kanal gewechselt? Nur, wenn keine Antwort kommt oder regelmäßig nach jeder Abfrage?

Vielen Dank!

Hallo Fritz!

Es ist schon fast ein Jahr her, dass ich mich mit den Einzelheiten befasst habe, deshalb alles ohne Gewähr:

zu 1. Ich glaube ja (ob das auch bei meinem Micropython-Code funktioniert, weiß ich nicht).

zu 2. Ich glaube 0x7e (start of frame, sof) und 0x7f (end of frame, eof) ist in den Daten, die man schickt bzw. erhält nicht enthalten; die sieht man nur, wenn man den Funkverkehr abhört (mit Sniffer?).

zu 3. Ein Zitat aus dem wiki: "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."

Heißt also: Man kann auf allen 5 Kanälen senden, die Antwort kommt dann auf einem von drei anderen Kanälen. Auf welchem ist meines Wissens zufällig. Also z.B. Senden auf Kanal 3 ergibt eine Antwort auf Kanal 23 oder 40 oder 61.

Viel Erfolg!

Fritz G. schrieb:

3. Offenbar wird ein Channel-Hopping über 5 Kanäle genutzt. Laut Wiki ist der Sendekanal des nrf24l01+ auf 40 = 2040 MHz festgelegt und es wird nur der Empfangskanal gewechselt. Ist das so OK? Wann wird der Kanal gewechselt? Nur, wenn keine Antwort kommt oder regelmäßig nach jeder Abfrage?

Hallo Fritz, ich hatte weiter oben schon mal spekuliert, dass das Channel Hopping dem Gazelle Link Layer von nRF entspricht und mit dem nRF24L01 nur pseudomäßig nachgebildet werden kann. Siehe hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Vielleicht hilft dir das weiter?

Ich habe für ein privates Projekt die Daten von meinem Wechselrichter mit einem Raspberry PI ausgelesen. Falls jemand das gleiche Anliegen hat, hier ist der Sourcecode:

https://github.com/bri1234/Hoymiles-HM-RaspberryPI

Es ist in Python (mit typehints) programmiert mit Schwerpunkt auf einfacher Verwendung, guter Lesbarkeit und guter Dokumentation des Sourcecodes.

So, schon 2,5 Jahre später habe ich ein Licht am Ende des Tunnels. Ich kann nun mit einem Arduino und dem NRF zusammen Hoymiles Powerlimits setzen. Ack klappt nicht, ich hoffe in weniger als 2,5 Jahren kann ich das auch noch posten :)

1

#include <RF24.h>

2

#include <SPI.h>

3

4

#define CE_PIN    9

5

#define CSN_PIN   10

6

7

RF24 radio(CE_PIN, CSN_PIN);

8

9

uint8_t invAddr[] = {0x71, 0x60, 0x33, 0x25}; 

10

uint8_t dtuAddr[] = {0x87, 0x29, 0x87, 0x48};

11

uint8_t channels[] = {3, 23, 40, 61, 75};

12

13

void setup() {

14

    Serial.begin(9600);

15

    if (!radio.begin()) { Serial.println(F("NRF24 Fail")); while (1); }

16

17

    radio.setDataRate(RF24_250KBPS);

18

    radio.setPALevel(RF24_PA_MAX);

19

    radio.setAddressWidth(5);

20

    radio.enableDynamicPayloads();

21

    radio.setCRCLength(RF24_CRC_16);

22

    radio.setAutoAck(false);

23

24

    // Adresse LSB zuerst + 0x01 Prefix

25

    uint8_t rxAddr[5] = {0x01, invAddr[3], invAddr[2], invAddr[1], invAddr[0]};

26

    radio.openReadingPipe(1, rxAddr);

27

28

    Serial.println(F("Bereit. Watt eingeben:"));

29

}

30

31

// CRC16 für den Payload-Teil (Modbus RTU Style)

32

uint16_t hoymiles_crc16(uint8_t *data, uint8_t len) {

33

    uint16_t crc = 0xFFFF;

34

    for (uint8_t i = 0; i < len; i++) {

35

        crc ^= (uint16_t)data[i];

36

        for (uint8_t j = 0; j < 8; j++) {

37

            if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; }

38

            else crc >>= 1;

39

        }

40

    }

41

    return crc;

42

}

43

44

// CRC8 für das gesamte Paket

45

uint8_t hoymiles_crc8(uint8_t *data, uint8_t len) {

46

    uint8_t crc = 0;

47

    for (uint8_t i = 0; i < len; i++) {

48

        crc ^= data[i];

49

        for (uint8_t j = 8; j; j--) {

50

            crc = (crc & 0x80) ? (crc << 1) ^ 0x01 : (crc << 1);

51

        }

52

    }

53

    return crc;

54

}

55

56

void sendLimit(uint16_t watts) {

57

    uint8_t buf[19];

58

    buf[0] = 0x51; // Control Frame

59

    memcpy(&buf[1], invAddr, 4);

60

    memcpy(&buf[5], dtuAddr, 4);

61

    buf[9] = 0x81; // Sequence (fest für diesen Test)

62

    buf[10] = 0x0B; // CMD: Set Limit

63

    buf[11] = 0x00;

64

65

    uint16_t val = watts * 10; // Inverter erwartet Zehntel-Watt oder Promille

66

    buf[12] = (val >> 8) & 0xFF;

67

    buf[13] = (val & 0xFF);

68

69

    buf[14] = 0x00; // Relative / Permanent

70

    buf[15] = 0x00;

71

72

    // 1. Payload CRC16 (über Byte 10 bis 15)

73

    uint16_t c16 = hoymiles_crc16(&buf[10], 6);

74

    buf[16] = (c16 >> 8) & 0xFF;

75

    buf[17] = (c16 & 0xFF);

76

77

    // 2. Global CRC8 (über Byte 0 bis 17)

78

    buf[18] = hoymiles_crc8(buf, 18);

79

80

    // Sende-Loop

81

    for (uint8_t i = 0; i < 5; i++) {

82

        radio.stopListening();

83

        radio.setChannel(channels[i]);

84

        radio.write(buf, 19);

85

        radio.startListening();

86

87

        Serial.print(F("Sende ")); Serial.print(watts);

88

        Serial.print(F("W auf CH ")); Serial.println(channels[i]);

89

90

        unsigned long start = millis();

91

        while (millis() - start < 200) {

92

            if (radio.available()) {

93

                uint8_t len = radio.getDynamicPayloadSize();

94

                uint8_t packet[32];

95

                radio.read(packet, len);

96

                if (packet[0] == 0xD1) {

97

                    Serial.println(F("--> ACK EMPFANGEN!"));

98

                    return;

99

                }

100

            }

101

        }

102

    }

103

    Serial.println(F("Kein ACK."));

104

}

105

106

void loop() {

107

    if (Serial.available()) {

108

        int w = Serial.parseInt();

109

        if (w > 0) sendLimit(w);

110

    }

111

}

Bugfix mit Ack:

1

#include <RF24.h>

2

#include <SPI.h>

3

4

#define CE_PIN    9

5

#define CSN_PIN   10

6

7

RF24 radio(CE_PIN, CSN_PIN);

8

9

// Die letzten 4 Byte der Wechselrichter- bzw. DTU-Seriennummer, LSB zuerst

10

// (invAddr[0] = die letzten beiden Hex-Ziffern der Seriennummer, invAddr[3] = die

11

// Ziffern 5-6 von hinten). Beispielwerte -> durch deine echten Seriennummern ersetzen.

12

uint8_t invAddr[] = {0x71, 0x60, 0x33, 0x25};

13

uint8_t dtuAddr[] = {0x87, 0x29, 0x87, 0x48};

14

15

uint8_t channels[] = {3, 23, 40, 61, 75};

16

17

void setup() {

18

    Serial.begin(9600);

19

    if (!radio.begin()) { Serial.println(F("NRF24 Fail")); while (1); }

20

21

    radio.setDataRate(RF24_250KBPS);

22

    radio.setPALevel(RF24_PA_MAX);

23

    radio.setAddressWidth(5);

24

    radio.enableDynamicPayloads();

25

    radio.setCRCLength(RF24_CRC_16);

26

27

    // WICHTIG: Auto-ACK MUSS an bleiben, sonst quittiert die Hardware nichts

28

    // und radio.write() gibt praktisch immer "true" zurück, egal ob der WR

29

    // das Paket überhaupt empfangen hat.

30

    radio.setRetries(3, 15); // 3*250us Delay, bis zu 15 Wiederholungen auf Hardware-Ebene

31

32

    // Sendeadresse (Pipe 0 wird implizit von openWritingPipe genutzt):

33

    // 0x01-Präfix + Seriennummer-Bytes in umgekehrter Reihenfolge - exakt wie

34

    // im Original (hmInverter.h::init()). Das ist die Adresse, an die WIR senden.

35

    uint8_t txAddr[5] = {0x01, invAddr[3], invAddr[2], invAddr[1], invAddr[0]};

36

    radio.openWritingPipe(txAddr);

37

38

    // Empfangsadresse: dieselbe Konstruktion, aber aus der DTU-Seriennummer -

39

    // das ist die Adresse, unter der WIR erreichbar sind und der WR seine

40

    // Antwort hinschickt. (Im Originalentwurf stand hier fälschlich invAddr.)

41

    uint8_t rxAddr[5] = {0x01, dtuAddr[3], dtuAddr[2], dtuAddr[1], dtuAddr[0]};

42

    radio.openReadingPipe(1, rxAddr);

43

44

    Serial.println(F("Bereit. Watt eingeben:"));

45

}

46

47

// CRC16 für den Payload-Teil (Modbus RTU Style) - unverändert korrekt

48

uint16_t hoymiles_crc16(uint8_t *data, uint8_t len) {

49

    uint16_t crc = 0xFFFF;

50

    for (uint8_t i = 0; i < len; i++) {

51

        crc ^= (uint16_t)data[i];

52

        for (uint8_t j = 0; j < 8; j++) {

53

            if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; }

54

            else crc >>= 1;

55

        }

56

    }

57

    return crc;

58

}

59

60

// CRC8 für das gesamte Paket - unverändert korrekt

61

uint8_t hoymiles_crc8(uint8_t *data, uint8_t len) {

62

    uint8_t crc = 0;

63

    for (uint8_t i = 0; i < len; i++) {

64

        crc ^= data[i];

65

        for (uint8_t j = 8; j; j--) {

66

            crc = (crc & 0x80) ? (crc << 1) ^ 0x01 : (crc << 1);

67

        }

68

    }

69

    return crc;

70

}

71

72

void sendLimit(uint16_t watts) {

73

    uint8_t buf[19];

74

    buf[0] = 0x51; // TX_REQ_DEVCONTROL

75

    memcpy(&buf[1], invAddr, 4);

76

    memcpy(&buf[5], dtuAddr, 4);

77

    buf[9] = 0x81; // SINGLE_FRAME

78

79

    buf[10] = 0x0B; // CMD: ActivePowerContr

80

    buf[11] = 0x00;

81

82

    uint16_t val = watts * 10; // WR erwartet das Limit mit einer Nachkommastelle

83

    buf[12] = (val >> 8) & 0xFF;

84

    buf[13] = (val & 0xFF);

85

86

    buf[14] = 0x00; // PowerLimitControlType, High-Byte

87

    buf[15] = 0x00; // = 0x0000 = AbsolutNonPersistent -> Limit in Watt, nur temporär

88

89

    // 1. Payload CRC16 (über Byte 10 bis 15)

90

    uint16_t c16 = hoymiles_crc16(&buf[10], 6);

91

    buf[16] = (c16 >> 8) & 0xFF;

92

    buf[17] = (c16 & 0xFF);

93

94

    // 2. Global CRC8 (über Byte 0 bis 17)

95

    buf[18] = hoymiles_crc8(buf, 18);

96

97

    // Sende-Loop über alle 5 Kanäle

98

    for (uint8_t i = 0; i < 5; i++) {

99

        radio.stopListening();

100

        radio.setChannel(channels[i]);

101

102

        bool ack = radio.write(buf, 19);

103

        if (!ack) {

104

            Serial.print(F("Kein Hardware-ACK auf CH ")); Serial.println(channels[i]);

105

            continue; // Chip hat gar nicht erst geantwortet -> nächster Kanal

106

        }

107

108

        // Der WR antwortet nicht auf dem Sendekanal, sondern versetzt (+3 für HM/HMS)

109

        uint8_t rxCh = channels[(i + 3) % 5];

110

        radio.setChannel(rxCh);

111

        radio.startListening();

112

113

        Serial.print(F("Sende ")); Serial.print(watts);

114

        Serial.print(F("W auf CH ")); Serial.print(channels[i]);

115

        Serial.print(F(", höre auf CH ")); Serial.println(rxCh);

116

117

        unsigned long start = millis();

118

        while (millis() - start < 200) {

119

            if (radio.available()) {

120

                uint8_t len = radio.getDynamicPayloadSize();

121

                uint8_t packet[32];

122

                radio.read(packet, len);

123

124

                // 0xD1 = Antwort auf DevControl-Befehl; Byte 10/11 == 0 heißt

125

                // "vom WR akzeptiert" (siehe Communication.h::parseDevCtrl)

126

                if (packet[0] == 0xD1 && packet[10] == 0x00 && packet[11] == 0x00) {

127

                    Serial.println(F("--> ACK EMPFANGEN, Limit akzeptiert!"));

128

                    radio.stopListening();

129

                    return;

130

                }

131

            }

132

        }

133

        radio.stopListening();

134

    }

135

    Serial.println(F("Kein ACK nach allen 5 Kanälen."));

136

}

137

138

void loop() {

139

    if (Serial.available()) {

140

        int w = Serial.parseInt();

141

        if (w > 0) sendLimit(w);

142

    }

143

}