@isnoahoy: Danke für deine Rückmeldung.
Ja da bin ich gerade dran und schaue mir das nochmal inruhe durch.
Ich versuche aktuell aus den "usart_nrf3" denn genauen Aufbau des
Protokolls nachzuverfolgen.
Stefan T. schrieb:> Hallo Josef J.,>> Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen.> Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2> und 3. Dann sollte es m.E. nach einem Reboot funktionieren.>> Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen> Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst> angepaßt / gefixt.
Vielen Dank, das hatte ich gerade zufällig selber probiert. Leider ohne
Erfolg.
Hallo zusammen,
und vielen Dank für euere tolle Arbeit.
Hab mir vor 2 Tagen bei komputer.de die Chips bestellt:
1 Stk. nRF24L01+ PA SMA mit Antenne 3.20EUR
1 Stk. ESP32 Development board NodeMCU kompatibel 6.50EUR
Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens
mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die
beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen.
Nach nur 6 Jahren! Gruselig…
Grüße, Matze
Kann jemand was dazu sagen wie man das zu verstehen hat?
Habe folgendes nachgestellt:
case NET_LIMIT_ACTIVE_POEWR: // NET_LIMIT_ACTIVE_POEWR = 24,
case NET_LIMIT_POEWR: // NET_LIMIT_POEWR = 3,
SubCmd = Type_ActivePowerContr; //Limit active power = 11,
MainCmd = DEVCONTROL_ALL; // #define DEVCONTROL_ALL 0x51
break;
Error while retrieving data: unpack requires a buffer of 2 bytes
Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten
nachzusenden?
https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt
(Zeile: 520)
Ist ja ähnlich aufgebaut.
Ich habe zwar in der Vergangenheit gelesen das jmd. herausgefunden hat
(oder mutmaßt) das wenn die ID vom WR zweimal hintereinander steht, soll
es sich um ein Verworfenes Packet handeln.
Hallo Josef J.,
Hfhausen schrieb:> Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die> mit abgespeichert wurden. Copy-paste Fehler.
Das könnte auch eine Ursache sein, probier das doch mal aus bzw.
überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten
Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und
Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default
Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte:
https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584
Desweiteren wäre es hilfreich den ESP8266 per USB Kabel am
Computer/Laptop angeschloßen zu lassen. Wenn Du unter Tools > Port den
Anschluß prüfst und dann die Serial Console aufmachst, solltest Du nach
einem Reset ein etwas ausführlicheres Debug Log bekommen. Die Statistik
auf der WebSeite in Deinem Screenshot sagt an der Stelle leider nicht
mehr aus. Das Debug Log enthält auch Informationen zum Anschluß des
nRF24L01+ und dessen Einstellungen.
Daniel R. schrieb:> Ich glaube das der WR in der Lage ist sogar einzelne Strings> kontrolliert abzuschalten, oder Einzuschalten.> Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd'> mit Bit-Operatoren verarbeitet.> ... Könnt ihr aber auch selbst unten lesen.>> temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a> temp_dat[10] = SubCmd & 0XFF;> temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 /> (EVERY_PORT_POWER *> (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power> limit percentage> temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8;> //High 8-bit power limit> temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff;> //Low power limit 8 bits> temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC> i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15);> //forward substitution> }
Das habe ich schon beschrieben und implementiert, siehe meinen Beitrag
v. früher:
- nach % limitieren
SubCMD=5a5a:limit percentage:,CRC
- nach abs.Leistung limitieren:
SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC
> Error while retrieving data: unpack requires a buffer of 2 bytes
6
>
>> Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten> nachzusenden?
Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du
nachzusenden?
nach CMD 0x51 sollte d1:WR|WR:5a:5a:d1 kommen und fertig, danach kommt
nichts mehr.
Und warum bei dir eine 0x81 kommt verstehe ich nicht.
@Daniel R.
- nach abs.Leistung limitieren:
SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC
Limitleistung wird mit 1 DEC als int gesendet, zB. 123.4 Watt schickst
du als 1234, darum hi/low bytes
Bekomme halt kein Recieve.
Ziyat T. schrieb:> Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du> nachzusenden?
Ich hab es aus den Infos so verstanden das man erstmal ein Datenpaket
zum WR schickt. Wenn dieser mit 0x81 Antworter können die nächsten Daten
raus verschickt werden.
Hatte ich hier im unteren Absatz geschrieben:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Daniel R. schrieb:> Nur zu Info ich habe immer noch ein HM.
Ja ich weiss, vielleicht gehts ja auch mit HM
> Testweise auch mit 20%> [code]2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34> 12 5a 5a 14 01 50 32
Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach
% willst, musst du nach 0x14 die crc schicken, keine bytes mehr.
>2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01
50 24
Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte
0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24
richtig?
Hallo Ziyat,
erstmal danke das du dir Zeit für mich nimmst! :)
Ziyat T. schrieb:>> Testweise auch mit 20%>> 2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34>> 12 5a 5a 14 01 50 32>> Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach> % willst, musst du nach 0x14 die crc schicken, keine bytes mehr.
Das würde dann bei mir so aussehen:
Auch hier bekomme ich kein Antwort vom WR.
>>2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01> 50 24>> Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte> 0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24> richtig?
Das weiß ich nicht, ich habe bei der CRC Algorithmus nichts geändert.
Nutze von Ahoy die rpi Version. - Wenn ich nur die Daten (DC/AC) vom WR
Anfordern möchte, geht das ohne Probleme. Daher vermute ich das die CRC
Berechnung passen wird.
Hallo dax,
ja wir beobachten das Problem der ESP8266 Variante schon seit längerem
mit Argwohn. Wir haben auch schon einige Male einen Stack Trace in
Github hochgeladen aber außer des/r nun stark optimierten Interrupt
Handler haben wir bisher noch keinen Plan warum es so häufig zu WDT
(Watch Dog Timer) Resets kommt.
* Loosing WiFi connection after X minutes #15
https://github.com/grindylow/ahoy/issues/15
hier findet sich auch eine Anleitung verlinkt, nach der Du mit dem
Binary Deinen Stack Trace decodieren kannst.
* Zeitkritikalität in der Haupt-Loop? #24
https://github.com/grindylow/ahoy/issues/24
hier haben wir uns dem Thema Interrupt und State Machine gewidmet.
* ESP8266: Discussion Verkabelung / Pinout #36
https://github.com/grindylow/ahoy/issues/36
hier hat Lukas P. zuletzt berichtet daß es bei ihm nach Vertauschen (!)
der Pins für CE und IRQ stabiler lief.
* Stabilität ESP8266 #83
https://github.com/grindylow/ahoy/issues/83
und hier diskutieren wir aktuell ob wir auch an der nRF24 Bibliothek
Anpassungen vornehmen müssen/sollen.
Alternativ zu den oben genannten Issues kannst Du gerne mal eines der
anderen "Tools" ausprobieren (z.B. die offenbar problemlos laufende
Raspberry Pi Variante von Jan-Jonas S., oder Hubi's Code für den
ESP8266) oder die m.E. sehr saubere ESP32 Implementierung von Thomas B.
unter https://github.com/tbnobody/OpenDTU
Bei mir steckt der Code m.E. immer wieder in der WebServer Routine fest,
da er einige Requests beantworten muß und dann stürzt er ab. Das ließe
sich evtl. durch die AsyncWebServer Variante ersetzen, wie bei OpenDTU ?
Oder es liegt daran, daß er mit zu häufigen Anfragen an RF24, MQTT und
WebServer einfach überlastet wird. Er steckt meist in irgendwelchen
ummalloc Routinen beim WDT Reset und daher vermute ich daß es etwas mit
dem etwas zu offenherzigen Einsatz der String Klasse zu tun haben
könnte, hier wird nämlich fleißig vom Flash/Progmem ins RAM kopiert um
dann wieder an die Adresse des Zielstrings (z.B. beim + / Concatenieren)
die Einzelstrings zu kopieren. Das kann evtl. auch einige CPU Zyklen
brauchen.
Hallo Ziyat T. & Daniel R.,
ja und ja beim MI-XXXX Wechselrichter heißt das Command 0x51 in
usart_nrf.c/.h CONTROL_LOCK_MI__LIMIT_POWER_ONOFF und beim
HM-Wechselrichter wird laut usart_nrf3.c/.h 0x51 als DEVCONTROL_ALL
definiert.
D.h. das Kommando sieht beim HM-XXXX etwas anders aus nach dem SubCmd.
Bei der Antwort kommt wie Daniel R. bereits geschrieben hat
ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80) also 0xD1.
Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX
Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und
erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL
(REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden
SubCmd's definiert als:
Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum
Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S.
hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw
AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem
Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter
hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert
hatten.
@Daniel R. 0x81, 0x82, 0x84 etc. sind die Paketkennungen des jeweils
letzten Antwortpaketes auf eine RealTimeRunData_Debug 0x0B SubCmd
Anfrage gewesen. Dabei wird das SubCmd-Feld in der Antwort durch einen
Paketzähler ersetzt und beim letzten Paket das Komplement (Paketzähler |
0x80) mitgeliefert, damit die DTU weiß dass dies das letzte Fragment /
Paket war.
> 2022-06-29 18:13:17.628811 Transmit 11 | >51< <74 40 33 29> <78 56 34 12> >0b<
<7c>
> 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: >d1< <74 40 33 29> <74
40 33 29> >81< <50>
Warum in Deiner Antwort als vorletztes Byte vor der CRC8 der Wert 0x81
auftaucht: Vielleicht ist es ja die Antwort 1 und als Komplement
(Antwort | 0x80) = 0x81 ?
Ob das einfach Okay oder gesetzt oder etwas ganz Anderes bedeutet
müsstest DU anhand der Methoden im usart_nrf(3).c Code mal herausfinden.
Stefan T. schrieb:
> Hallo dax,> ja wir beobachten das Problem der ESP8266 Variante schon seit längerem> mit Argwohn.
Mein "Rekord" sind 1 Tag - 18 Std. Betriebszeit ohne Reset (Wemos D1
mini, separate 3,3V-Versorgung mit entsprechenden Kondensatoren für
nRF24L01+-Modul). Aber auch immer wieder Resets nach deutlich kürzeren
Zeitspannen.
Es gibt bei meinem Aufbau Resets, bei denen das System einfach neu
startet, aber auch "Abstürze", bei denen die Versorgungsspannung
unterbrochen werden muss, um einen Neustart zu ermöglichen.
Die Probleme mit der Stabilität von Aufbauten mit ESP8266-basierten
Boards gibt es auch in anderen Projekten, z. B. dieser "Esp8266 Nodemcu
Gaszähler Thingspeak"; spätestens nach einem Tag war ein Reset notwendig
(https://fipsok.de/Projekt/gaszaehler-esp8266-nodemcu).
In einem anderen Projekt zur Erfassung des Gasverbrauchs wird
ausgeführt:
"Mehrere erste Versuche mit nur einem Mikrocontroller vom Typ ESP8266
waren nicht erfolgreich, weil bei gleichzeitiger Benutzung der Webseite
leider die Zählimpuls-Erkennung über Interrupt nicht ausreichend
zuverlässig war. Die aktuelle Lösung verwendet deshalb zusätzlich zum
verwendeten ESP8266 noch einen ATTINY84 Mikrocontroller für die
zuverlässige Zählfunktion für insgesamt 4 Kanäle."
(https://www.stall.biz/project/pulsecounter-2-komfortabel-verbraeuche-von-strom-wasser-gas-und-solar-messen).
Den Teil mit dem Wemos D1 mini-Board habe ich getestet, er lief stabil.
Das Projekt habe ich aber nicht weiterverfolgt, weil es Probleme mit der
Impulserfassung am Gaszähler gab.
Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim
Kompilieren mit Visual Studio Code und der PlatformIO Extension...
Günter H. schrieb:> Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim> Kompilieren mit Visual Studio Code und der PlatformIO Extension...
Hallo Günter,
Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was
passiert nicht?
Hallo,
inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich
mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN
konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen.
Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die
HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung
für den TSUN dabei?
Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an
meiner ESP-Verkabelung.
Muss man für die WR-Hardware in der SW vor dem compilieren noch was
ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt.
Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier
der Auszug der serial-Konsole:
10:43:56.941 -> ...............................
10:44:01.668 -> I: add inverter: MI-800, SN: 11417xxxxxxxx
10:44:04.451 -> I: RF24 Amp Pwr: RF24_PA_MIN
10:44:04.451 -> I: Radio Config:
10:44:04.451 -> SPI Frequency = 1 Mhz
10:44:04.451 -> Channel = 3 (~ 2403 MHz)
10:44:04.451 -> RF Data Rate = 250 KBPS
10:44:04.451 -> RF Power Amplifier = PA_MIN
10:44:04.451 -> RF Low Noise Amplifier = Enabled
10:44:04.451 -> CRC Length = 16 bits
10:44:04.451 -> Address Length = 5 bytes
10:44:04.451 -> Static Payload Length = 32 bytes
10:44:04.451 -> Auto Retry Delay = 250 microseconds
10:44:04.483 -> Auto Retry Attempts = 0 maximum
10:44:04.483 -> Packets lost on
10:44:04.483 -> current channel = 0
10:44:04.483 -> Retry attempts made for
10:44:04.483 -> last transmission = 0
10:44:04.483 -> Multicast = Disabled
10:44:04.483 -> Custom ACK Payload = Disabled
10:44:04.483 -> Dynamic Payloads = Enabled
10:44:04.483 -> Auto Acknowledgment = Disabled
10:44:04.483 -> Primary Mode = RX
10:44:04.483 -> TX address = 0xdeadbeef01
10:44:04.483 -> pipe 0 (closed) bound = 0xdeadbeef01
10:44:04.483 -> pipe 1 ( open ) bound = 0x1234567801
10:44:04.520 -> pipe 2 (closed) bound = 0xc3
10:44:04.520 -> pipe 3 (closed) bound = 0xc4
10:44:04.520 -> pipe 4 (closed) bound = 0xc5
10:44:04.520 -> pipe 5 (closed) bound = 0xc6
10:44:04.520 -> I:
10:44:04.520 ->
10:44:04.520 -> ----------------------------------------
10:44:04.520 -> I: Welcome to AHOY!
10:44:04.520 -> I:
10:44:04.520 -> point your browser to http://192.168.10.229
10:44:04.520 -> I: to configure your device
10:44:04.520 -> I: ----------------------------------------
10:44:04.520 ->
10:44:10.573 -> I: [NTP]: 2022-06-30 10:44:04
Auf der Website kommt die Fehlermeldung
…Receive failed…
Inverter 1 not (correctly) configured
Inverter 2 not (correctly) configured
Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert
und ob der TSUN schon unterstützt wird.
Danke.
Grüße
Claus T.
Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung
ist mir was aufgefallen und denke es ist für die neue Generation
verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine
Abfrage ob es sich um eine DTU3PRO handelt.
Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein
"DRM_Limit_Switch; //DRM power limit".
Für mich ist das ein Indikator das es ein Flag im System zu setzen ist,
das aussagt ob eine Limitierung nun erlaubt sei oder nicht.
Dies bezüglich habe in der *.c Datei geschaut und siehe da, in der
Funktion (Zeile 1717) eine "UsartNrf_Send_PackSetPowerLimitCommand":
Hier zeigt sich im Speicher der DTU abgefragt wird, ob der WR sich in
einem gewissen Zustand ist.
i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution
Ich werde mal das ganze weiter anschauen und probieren.
EDIT:
5A 5A FF <[Property.Power_Limit * 10 / (300 *
(UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))]> [H
8-bit P limit] [LP limit 8 bits] CRC
Stefan T. schrieb:> Das könnte auch eine Ursache sein, probier das doch mal aus bzw.> überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten> Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und> Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default> Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte:> https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584
Vielen herzlichen Dank!
Darin befindet sich die Lösung. Jetzt funktioniert. Musste CE und IRQ
vertauschen. (also nicht nach dem Schaltbild, das auf GitHub ist!)
Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem
darstellen.
Jetzt kämpfe ich nur noch mit Wlan Problemen. Bei mehr als 3-4 Meter
Entfernung von Wlan Router, bricht die Verbindung in unregelmäßigen
Abständen ab (meist aber schon nach 4-5 Sekunden). Habe schon
verschiedene Netzteile und Kabel getestet und mit Kondensatoren
experimentiert. Werde jedenfalls noch weiter testen.
Thomas B. schrieb:
> Hallo Günter,> Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was> passiert nicht?
Danke für die Rückmeldung. Vorweg: Ich bin "kein Programmierer". Bekomme
die Arduino IDE (gerade so) zum Laufen.
PC mit Windows 10 Pro 21H2
Installation von Visual Studio Code und der PlatformIO Extension
innerhalb Visual Studio Code problemlos, Source Code als zip-Datei
heruntergeladen, entpackt und platformio.ini geöffnet, upload_port und
monitor_port angepasst.
Dann "PlatformIO: Upload" angeklickt - danach kamen die Fehlermeldungen,
s. Anhänge. Die Zahlen sollen die zeitliche Reihenfolge widerspiegeln.
Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0
für Windows" heruntergeladen und installiert. Weiter als zur
Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen.
Gruß Günter
Günter H. schrieb:> Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0> für Windows" heruntergeladen und installiert. Weiter als zur> Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen.
Hallo Günter,
du bist dann in das gleiche Problem gelaufen wie hier:
https://github.com/tbnobody/OpenDTU/issues/3
Ich werde heute Abend noch eine Ausnahme implementieren, damit man den
Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP
heruntergeladen hat.
Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord
umzuleiten?
Da hier auch über andere Themen gesprochen werden die für das Projekt
relevant sind, würde ich vorschlagen statt ein seperaten Thread
aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier
bleiben?
Nur eine Idee. :)
Claus T. schrieb:> Hallo,> inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich> mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN> konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen.> Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die> HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung> für den TSUN dabei?> Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an> meiner ESP-Verkabelung.> Muss man für die WR-Hardware in der SW vor dem compilieren noch was> ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt.> Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier> der Auszug der serial-Konsole:> Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert> und ob der TSUN schon unterstützt wird.> Danke.> Grüße> Claus T.
Hallo Claus,
ich bin der mit dem TSOL-M800 (MI-700 Klon).
Es gibt noch MI-1500 und 1200, die etwas andere Abfragen starten.
Meine Version ist nicht annähernd lauffähig, teilweise instabil und eher
unkomminikativ, allerdings ist deine Verkabelung ect. soweit ok.
Die älteren MI werden noch nicht unterstützt, ist allerdings in der
Mache.
Bitte hab etwas Geduld. Ich schaue mal, dass ich meine Version zu github
hochlade, wenn sie etwas besser läuft. Aktuell modifiziere ich noch
dran.
Ggf. kann Daniel R. oder Ziyat eine Testversion für den MI auf dem D1
Mini bereitstellen, die besser anzupassen ist.
Wie gesagt, etwas Geduld :)
Daniel R. schrieb:> Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord> umzuleiten?>> Da hier auch über andere Themen gesprochen werden die für das Projekt> relevant sind, würde ich vorschlagen statt ein seperaten Thread> aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier> bleiben?>> Nur eine Idee. :)
Moin,
wenn du einen Einladungslink zu einem Server hast, komme ich gerne dazu
:)
lg
Hallo Daniel,
danke für die Info, schön zu hören, dass meine HW funktioniert, dann
bleibe ich weiter geduldig :-)
Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner
nicht mit 1041… begonnen?
Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi
hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben
anschmeißen.
Grüße
Claus T.
Claus T. schrieb:> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner> nicht mit 1041… begonnen?
Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe
sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders
belegt?
Josef J. schrieb:> Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem> darstellen.>
Doch, weil deine DTU-Pro dauernd den WR abfragt, sendet der WR antworten
zu DTU-Pro.
Wenn du in deinem esp-ahoy die gleiche Adresse hast wie die DTU-Pro,
wirst du nie wissen ob das esp-ahoy den WR abfragt, bzw. das Senden
erfolgreich ist. Du bekommst die WR Antworten zu DTU-Pro gratis mit.
Daniel R. schrieb:> Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung> ist mir was aufgefallen und denke es ist für die neue Generation> verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine> Abfrage ob es sich um eine DTU3PRO handelt.> Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein> "DRM_Limit_Switch; //DRM power limit".>
Eigenlich alles steht im RF_communication_protocol-V6.5.xlsx.
Es gibt folg Limitierungen in der Praxis:
- zero export: prozentual oder absolut Wert der Nenneistung, gesteuert
in Verbindung mit einem Modbus Smart-Meter
- Fest limiterte WR: prozentual oder absolut Wert der Nenneistung,
eingegeben im smiles-cloud
-DRM(Demand Response Mode): der WR wird vom Gridanbieter kontrolliert
off/0%/50%/no limit.z.B in Australien, in der EU weiss nicht. Es wird
über die DTU-Pro, mit RS485(Modbus oder Sunspec) oder mit einem DRM-Port
direkt kommuniziert.
Thomas B. schrieb:> Claus T. schrieb:>> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner>> nicht mit 1041… begonnen?>> Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe> sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders> belegt?
Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141
los und monitore das schon eine ganze Weile.
Claus T. schrieb:> Hallo Daniel,> danke für die Info, schön zu hören, dass meine HW funktioniert, dann> bleibe ich weiter geduldig :-)> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner> nicht mit 1041… begonnen?> Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi> hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben> anschmeißen.> Grüße> Claus T.
Sehr interessant. Meiner hat mit 1041 begonnen, ja.
Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen
einzutragen.
Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es
bringt was raus.
Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das
geht.
Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren.
https://github.com/tbnobody/OpenDTU
Allerdings ist es auch bisher nur für die HM-Serie.
lg
Richard K. schrieb:> Thomas B. schrieb:>> Claus T. schrieb:>>> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner>>> nicht mit 1041… begonnen?>>>> Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe>> sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders>> belegt?>> Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141> los und monitore das schon eine ganze Weile.
Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein
umgelabelter HM-Serie?
Ich trau den Chinesen alles zu ;)
Thomas B. schrieb:
> Hallo Günter,>> du bist dann in das gleiche Problem gelaufen wie hier:> https://github.com/tbnobody/OpenDTU/issues/3>> Ich werde heute Abend noch eine Ausnahme implementieren, damit man den> Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP> heruntergeladen hat.
Hallo Thomas,
nach deinem Hinweis konnte ich den git clone herunterladen - frage bitte
nicht, wie das letztlich gelungen ist.
Wie auch immer: Das System arbeitet perfekt (HM600), über die Stabilität
kann ich naturgemäß noch keine Angaben machen.
Hallo Daniel,
Daniel M. schrieb:> Sehr interessant. Meiner hat mit 1041 begonnen, ja.> Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen> einzutragen.
Ich habe am meinem TSOL-M800 an jedem der beiden MPPT-Eingängen ein
370Wp Modul angeschlossen, also beide Inverter laufen. So habe ich sie
auch in der ahoy-SW eingetragen, bei
Inverter
Inverter 0
AddressNameMax Module Power (Wp) 440 440
Module Name CS3L-370 CS3L-370
Inverter 1
Alles weitere leer.
Und jetzt noch getestet, die beiden rechten Felder gelöscht.
AddressNameMax Module Power (Wp) 440 0
Module Name CS3L-370
Bringt aber auch nix, wobei die Rechte Module Power wird automatisch 0.
>> Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es> bringt was raus.>> Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das> geht.
Gut, dann kann ich die testen.
>> Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren.> https://github.com/tbnobody/OpenDTU> Allerdings ist es auch bisher nur für die HM-Serie.
Und dafür muss ich VisualStudio mit PlatformIO installieren, was ich
schon mal für ein anderes Projekt probiert hatte und gescheitert bin.
Ist aber ein Grund für einen neuen Versuch :-)
Die Art des WR wird bei ahoy über die Seriennummer erkannt?
Claus T. schrieb:> Ist aber ein Grund für einen neuen Versuch :-)
Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur
ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS
Code installieren und die PlatformIO Extension zu laden)
Claus T. schrieb:> Die Art des WR wird bei ahoy über die Seriennummer erkannt?
Genau. Wie in allen anderen Implementierungen aktuell auch. Die
Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht
eindeutig (siehe
https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx)
Holger S. schrieb:> Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x> Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch> rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den> China Wemos Clones liegt.>> Leider bekomme ich damit auch keine mehrstündigen Uptimes hin.> Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber> irgendwie muß man das doch sauber zum laufen bekommen.>> Läuft das bei euch über Tage ohne Reboot ???
Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger
als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert
auch keine Daten mehr. Hilft nur noch ein reboot...
Hans W. schrieb:> Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger> als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert> auch keine Daten mehr. Hilft nur noch ein reboot...
Betreibe einen NodeMCU mit rf-Modul ohne Cap mit ahoy an meinem HM-800
seit mittlerweile > 3 Wochen ohne Reboot. Großartige Arbeit übrigens @
Dev's!
Daniel M. schrieb:>> Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141>> los und monitore das schon eine ganze Weile.>> Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein> umgelabelter HM-Serie?> Ich trau den Chinesen alles zu ;)
Ja da steht wirklich TSUN TSOL-M800 drauf, und die 1141 passt auch zu
dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau
612W scheinbar begrenzt.
Hab die Version 0.4.19 am laufen.
Für alle die reboots haben, stellt mal das Intervall von 5 sekunden
einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5
Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es
damit zusammen.
> Ja da steht wirklich TSUN TSOL-M800 drauf, und die 1141 passt auch zu> dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau> 612W scheinbar begrenzt.> Hab die Version 0.4.19 am laufen.
Laut Datenblatt hat es eine Spitzenwirkungsgrad des Wechselrichters von
etwa 96,7%. Ich glaub meine Rechnung ist falsch aber wenn ich das ganze
Überschlage, sollte etwa folgendes raus kommen:
370W*2= 740W
(740W/100) * 96,7 = 715,58WAC ?
Für mich heißt es das lt. Rechnung 84,42W fehlen und nach deinen Angaben
sogar 188W fehlen. Wenn wir noch bei beiden ca. 20-50W mal für Toleranz
abziehen (pi*Daume) dann fehlen bei dir trotzdem gute 130W.
Hmm, eventuell wurde hier falsche Firmware oder wie du gesagt hast schon
vorab begrenzt. - Keine Ahnung... :/
> Für alle die reboots haben, stellt mal das Intervall von 5 sekunden> einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5> Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es> damit zusammen.
Das sollte man eventuell mal sich merken/Anpinnen. Glaube das hatte
bisher keiner im Verdacht? :)
Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft
worden.
Und das tut der auch brav. Ich habe das beim Aufzeichnen auch so
festgestellt.
Ob dieser das jetzt auf Einspeiseleistung macht oder auf Panelleistung
kann man so nicht sagen, denn ich sehe eine harte Begrenzung bei beidem.
Im Anhang sieht man das an dem aufgezeichneten Tag immer wieder mal die
Sonne weg war wegen einzelnen Wolken, dann ist ja das Panel kühler und
wenn die volle Bestrahlung kommt dann liefern die Panels auch mehr
Leistung.
Und da sieht man ganz deutlich das die Leistung gedeckelt ist.
Und ich würde behaupten das diese Serie evtl. auch in der Begrenzung
regelbar ist, oder es ist in der Firmware schon so begrenzt.
Hallo zusammen
Über die Suche im WWW bin ich auf diesen Thread gestossen. Ich bin
überrascht wieviele Leute es doch gibt, die sich gegen ein
"Fremdüberwachungscloud" gibt und wieviel Aufwand und Arbeit da
reingesteckt wird. Vielen Dank dafür.
Seit kurzem läuft bei mir auch ein HM-600 mit einem Stick DTU, den ich
aber nur leihweise habe.
Wenn ich das ganze hier richtig verstanden habe, gibt es hier 3
Varianten? Welche Variante ist die mir der ich am sichersten die Daten
in den Iobroker bringe?
Ich bin kein Softwaremensch, ein ESP oder Arduino flashen geht, aber
sobald es um komplexe Software geht weiss ich nicht mehr weiter. Darum
die Frage.
Gruss Andi
Richard K. schrieb:> Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft> worden.
An sich kann man die alle regeln, da schon festgestellt wurde das TSUN
eine kopie von Hoymiles ist. :)
Da an sich Zero-Export funktion auch noch möglich ist müssen die sich
regeln lassen können.
Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter
hoch treiben. ;)
@Andi: An sich kommt alles drauf an. Wenn du bereits ein Raspi hast und
der 24/7 läuft würde ich denn nutzen. Wenn du aber ein ESP8266/32 in der
Schublade hast, kann man denn auch gut nutzen. Bei allen jedoch ist ein
NRF24L01+ nötig.
Sollte aber alles auf Github stehen: https://github.com/grindylow/ahoy/
PS: Du kannst bei allen via MQTT auf iobroker dann legen. ;)
Hallo Daniel
Danke für die Hinweise. Mein Problem besteht darin, dass mein Englisch
sehr schlecht ist und sich leider nicht immer alles sinnvoll übersetzen
lässt.
Als Controller liegt alles bei mir rum, Rpi, ESP8266 und ESP32 als Wemos
D1 mini. Dann organisiere ich mir mal den NRF... und beginne mal zu
testen.
Die ESP Varianten sind mir sympatisch, den die brauchen dann keine
Software Support mehr wenn es mal läuft. Rpi ist da halt etwas
aufwändiger. Mein Iobroker läuft als Multihost auch auf Rpi CPU. Aber
eben im Keller und dort geht die DTU eben nicht.
Gruss Andi
Zuerst einmal: Vielen Dank für eure Arbeit!
Ich habe mir auch vom Makershop einen NRF24L01+ PA und einen Wemos D1
Mini geholt, geflashed und angeschlossen.
Aber er empfängt leider keine Daten vom WR. Ich habe das PinOut zweimal
geprüft - auch IRQ/CE.
Muss ich den WR selber noch überreden, dass er sendet? Habe ich etwas
vergessen in der Firmware zu aktivieren (Muss dort Channel Hopping an
oder aus sein?)
Gibt es irgendwo eine Anleitung zum systematischen Debugging, z.B. ob
das NF24-Modul überhaupt antwortet bzw. betriebsbereit ist?
EDIT: HAT sich erledigt. Ich habe keine Ahnung, was sich geändert hat,
aber nach dem aktivieren des Loggings, dem richtigen Raten der Baudrate
(115200) und dem connecten mit screen läuft es nun.
Hallo zusammen,
ich habe meinen WemosD1Mini nun schon eine ganze Weile mit meinem HM700
am laufen. Soweit funktioniert das auch, jedoch hatte ich jetzt versucht
ihn per mqtt mit iobroker zu verbinden aber irgendwie kann er sich nicht
mit dem mqtt Server verbinden.
Die Anmeldedaten sind jedoch definitiv korrekt aber eine Verbindung
schlägt fehlt.
Jetzt wollte ich ein OTA Update (aktuelle Version 0.3.3) durchführen und
frage mich aber wo ich die dafür benötigten Files finde.
Unter https://github.com/grindylow/ahoy konnte ich irgendwie nichts
finden.
Wäre super wenn ihr mir weiterhelfen könntet, vielleicht sehe ich ja den
Wald vor lauter Bäumen nicht.
EDIT: Hat sich erledigt. Hab eben gesehen, dass die BIN Files hier im
Thread zur Verfügung gestellt werden.
Daniel R. schrieb:> Richard K. schrieb:>> Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft>> worden.>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter> hoch treiben. ;)
Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit
einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert.
Bin gespannt ob es geht.
Hallo Thomas,
Thomas B. schrieb:> Claus T. schrieb:>> Ist aber ein Grund für einen neuen Versuch :-)
Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal
mit Erfolg.
> Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur> ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS> Code installieren und die PlatformIO Extension zu laden)
Ich hab’s auf meinem MacBookAir installiert, deine Anleitung hat aber
trotzdem sehr gut geholfen. Musste noch Python 3.10 und git
installieren.
Als serielle Schnittstelle muss man am Mac statt COM4
/dev/cu.usbserial-1410 eingeben. Wobei das vom ESP32-USB-Chip abhängig
ist.
>> Claus T. schrieb:>> Die Art des WR wird bei ahoy über die Seriennummer erkannt?> Genau. Wie in allen anderen Implementierungen aktuell auch. Die> Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht> eindeutig (siehe> https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx)
Nachdem ich unter Settings das Netzwerk und die Seriennummer meines
Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann
auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei
VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32
etwas bewegt hatte, kam auch ein „success“. Super! :-)
Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der
Empfang nicht ganz durch die Hauswand.
Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut.
Der Wechselrichter wird als HM-600, HM-700, HM-800 erkannt, was anhand
der Seriennummer 11417… zu erwarten war, und empfängt sauber alle Daten.
Mein TSUN TSOL-M800 ist also kein MI-xxx, sondern ein HM-6/7/800.
Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des
Hauses keine Daten.
Dank an alle, die das Projekt schon so weit gebracht haben.
lg
Claus T.
Also ich habe jetzt die Version 4.19 geflashed aber leider kann er
weiterhin keine Verbindung zu mqtt herstellen.
Gibt es Broker seitig etwas zu beachten?
Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im
Format 192.168.42.101 angegeben.
Muss beim Topic etwas beachtet werden?
Hallo Silvio,
an sich nichts großes.
Probiere mal via MQTTExplorer
(https://github.com/thomasnordquist/MQTT-Explorer) zu lauschen ob die
Daten auch empfangen werden.
In den Einstellung bei deinem DTU muss unter MQTT auch passend die Werte
eingepflegt werden. Denke mal das hast du auch gemacht.
Ziyat T. schrieb:>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter>> hoch treiben. ;)>> Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit> einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert.> Bin gespannt ob es geht.
Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden
können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die
Settings im WR anpassen kann.
Soweit ich die Installationsanleitungen verstehe, gibt es da Optionen.
In dem Gitee waren auch Hinweise auf dieses "Gridfile", vorwiegend aber
für die MI-Serie.
Habe heute meinen HM-1500 bekommen und bin gespannt, ob die EU-Version
(nicht explizit DE) das Limit auf 600W drin hat.
Ahoy-Software hat nach Pintausch auf einem Wemos kurzzeitig
funktioniert, ich vermute, hier hats einfach durch die Bastelumgebung
zuviel Störzeug, was überlagert.
Die Version auf dem ESP32 hatte da (wahrscheinlich wegen der Störfelder)
noch nicht geklappt, ich werde aber damit auch testen.
Claus T. schrieb:> Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal> mit Erfolg.
Glückwunsch! :)
> Nachdem ich unter Settings das Netzwerk und die Seriennummer meines> Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann> auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei> VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32> etwas bewegt hatte, kam auch ein „success“. Super! :-)>> Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der> Empfang nicht ganz durch die Hauswand.> Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut.
Also die Nachfolgerversion meines "alten" MI-Klon.
Wenn du Daten bekommst, ist das super.
> Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des> Hauses keine Daten.
Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ
auf D4. Alternativ kannst du auch D8, D2, D1 probieren.
Silvio R. schrieb:> Also ich habe jetzt die Version 4.19 geflashed aber leider kann er> weiterhin keine Verbindung zu mqtt herstellen.> Gibt es Broker seitig etwas zu beachten?> Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im> Format 192.168.42.101 angegeben.> Muss beim Topic etwas beachtet werden?
Für die neuere MQTT Version >2.x brauchst du zwingend Username/Passwort,
außer du konfigurierst den Server entsprechend um.
Sonst ist der Tip mit MQTT.fx oder MQTT Explorer ganz gut zum Schauen.
Normal sollte nichts weiter beachtet werden.
bei der HM Serie wird AC Power und die einzelnen DC Power der Eingänge
übertragen.
Die ESP Version errechnet die Gesamt DC Power und daraus wieder den
Wirkungsgrad.
Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC
Powermessung sehr genau stimmt.
Mal eine Frage in die Runde: Wie heiß werden eigentlich eure
Wechselrichter? Gibt es eine Overtemperature Abschaltung?
Ich habe bei mir schon 73°C gesehen. Das passt auch zu meiner
Vorstellung, dass bei ca. 1.1kW und 95.5% Wirkungsgrad ca. 50W in Wärme
umgewandelt werden. Man muss dazu sagen, das ich auf zwei Eingängen
Parallelschaltungen und damit verbunden hohe Ströme habe.
Lukas P. schrieb:> Mal eine Frage in die Runde: Wie heiß werden eigentlich eure> Wechselrichter?
Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500)
Lukas P. schrieb:> bei der HM Serie wird AC Power und die einzelnen DC Power der> Eingänge übertragen.> Die ESP Version errechnet die Gesamt DC Power und daraus wieder den> Wirkungsgrad.> Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC> Powermessung sehr genau stimmt.
Vielen Dank. Momentan lese ich noch die Daten via Modbus TCP von der DTU
Pro aus. Ich denke, dass dies aber die DC Power sein wird (Laut Doku PV
Power). Das muss ich mal vergleichen.
Zu den Temperaturen kann ich noch nichts sagen, da ich den WR erst seit
einer Woche habe.
Thomas B. schrieb:> Lukas P. schrieb:>> Mal eine Frage in die Runde: Wie heiß werden eigentlich eure>> Wechselrichter?>> Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500)
Aussen 38.5C, WR 64.9C
Daniel M. schrieb:> Ziyat T. schrieb:>>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter>>> hoch treiben. ;)>>>> Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit>> einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert.>> Bin gespannt ob es geht.>> Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden> können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die> Settings im WR anpassen kann.
Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Daniel,
Daniel M. schrieb:>> Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des>> Hauses keine Daten.>> Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ> auf D4. Alternativ kannst du auch D8, D2, D1 probieren.
hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3)
vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png +
AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den
ich auch verwende.
Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal
kontrolliert bzw. angepasst... und es läuft :-)
Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet,
hat nix geholfen.
Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert.
Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2)
eingestellt.
Grüße
Claus
Interrupt und ReceiveChannel
Hallo,
Ich habe von meinem MI-1500 immer wieder keine Daten mehr bekommen, habe
den Grund untersucht.
- Unbedingt nicht nur auf CH03 hören, mein MI-1500 sendet z.B. heute
nichts über CH03. Er sendet heute nur über CH61 und CH75 !!
- Wenn ich ohne Interrupt den NRF24 polle, sehe ich mehr Daten
So bekomme schön und regelmaessig Daten vom MI-1500
Ich habe eine HM-1500. Max Temperatur war knapp über 60°C.
Hab jetzt ein kleinen 12V Lüfter davor gestellt mit kleinem Solar Panel.
Seit dem bin ich bei Max 45°C.
Gruß Tom
Hallo Claus,
Claus T. schrieb:> hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3)> vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png +> AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den> ich auch verwende.
Ich muss nochmal drüber schauen, ich habe auch den Typ im Einsatz.
> Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal> kontrolliert bzw. angepasst... und es läuft :-)
Wenns läuft, ist top :)
Glückwunsch!
> Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet,> hat nix geholfen.> Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert.> Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2)> eingestellt.
Ich hab das auch noch nicht ganz verstanden, warum das nicht klappt. Ich
nutze 2 identische D1 mini, identisch verkabelt und eingerichtet, selbe
Position und das NRF Modul genauso ausgerichtet, der eine läuft, der
andere nicht.
Ziyat T. schrieb:> Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe:> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Ziyat,
ich bin nicht sicher, ob für die HM-Serie ggf. weitere Parameter
vorgesehen sind. Als die MI-Serie aktuell war, gab es keine Limits in
der Form (soweit mir bekannt).
Mein HM-1500 (EU-Version) kennt kein 600W Limit. Ahoy auf D1 Mini und
Thomas seine Version auf ESP32 laufen perfekt.
Mit dem MI-Klon bin ich noch nicht weiter, heute erstmal die 4 Panele
mit dem HM aufgestellt.
lg
Daniel
Wegen getauschten Verbindungen des ESP8266 Code von Lukas P., das hat er
ab Versiom 0.4.20 geändert:
https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584
Jetzt gilt als Default:
CS = D8(GPIO15)
CE = D3(GPIO0)
IRQ = D4(GPIO2)
Ich muss noch die Fritzing Schematics & die Beschreibung dementsprechend
anpassen. Verstehen tue ich’s auch (noch) nicht. Bei mir hat die 30 s
Intervallzeit mE viel mehr Erfolg als irgendeine geänderte Belegung.
Aber wenn‘s Euch hilft =^D
Wir sollten evtl überlegen ob wir den von Ziyat T. vorgeschlagenen Weg:
kein IRQ und auf allen Kanälen empfangen und/oder senden auch umsetzen ?
Zumindest die Raspberry Pi Variante von Jan-Jonas S. kommt schließlich
auch ohne IRQ aus. Vielleicht ist ein gutes Timing wie im uart_nrf.c/.h
code des Herstellers besser als ein Interrupthandler der ständig
dazwischenkommt/-„funkt“.
Hallo Oswald S.,
bitte hier keine Stacktraces / Exceptions reinpasten! Wir kennen das
Problem und versuchen es seit einiger Zeit u.a. im folgrnden Github
Issue zu analysieren:
https://github.com/grindylow/ahoy/issues/15
Dort steht auch, wie Du Deinen Exception Code decodieren kannst. Das
geht nur mit dem Original Hex/Binary file das auf Deinem ESP8266
geflasht wurde. Wir können also mit den Daten gar nichts anfangen sic
!
Wenn Du weiteren Code hier pasten willst dann verwende bitte die [ code
] und [ / code ] Syntax (siehe unten beim Eingabefeld) um es für uns
alle leserlich zu gestalten. Danke!
Hallo Oswald S.,
ansonsten scheint er ja einen WLAN Router zu erreichen, das nRF24L01+
Modul zu initialisieren und auf die Anfrage eine Antwort vom
Wechselrichter zu bekommen und es ist soweit alles schick außer/nach dem
Reboot.
Ach ja und das Problem mit dem Neuaufbau der MQTT Verbindung hatten wir
vermeintlich schon gelöst:
https://github.com/grindylow/ahoy/issues/68
Vielleicht ist die WLAN Verbindung doch nicht so stabil wie man es aus
den o.a. Logfile annehmen könnte ?
Das ist zumindest bei mir m.E. das Problem (mein Router ist im Keller
und der ESP unterm Dach) da geht es nur in bestimmten Ecken des Zimmers
und auch nur wenn die Nachbarn (bzw. deren WLAN Geräte) schlafen.
Hallo,
gibt es denn schon erfolge bzgl. Hoymiles und Limitierung ?
Ich habe das, was ich hier gelesen habe mal testweise eingebaut, leider
bekomme auch ich keine Antwort oder eine Limitierung.
Wäre cool, wenn wir das hinbekommen, mein 2ter PWM is bereits nach
Monaten Dauerbetrieb schon abgeraucht. Den nutze ich um die Stromstärke
für den HM anzupassen.
Marcel
Rene M. schrieb:> Wie kann man die Befehle zur Limitierung senden?
Ich hab seit ein paar Tagen die EspHome Version fertig und teste die
gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich
zufrieden damit bin). Da habe ich mir einen Schalter eingebaut der dann
die o.g. Funktion aufruft.
Es ist derzeit noch nicht im code eingebaut und man müsste es sich immer
selber bauen.
Damals war es möglich ein Commando in der Seriellen Konsole aufzurufen,
weiß aber nicht wie das gemacht wurde.
Marcel
Hallo zusammen,
erst einmal vielen vielen Dank an alle die das Projekt hier ins Leben
gerufen haben!!! Bei mir mit meinem Hoymiles HM-600 läuft das ganze
jetzt schon ca. zwei Wochen ohne nennenswerte Probleme.
Jetzt habe ich allerdings doch mal eine Frage: Im Setup bei MQTT kann
man da nur eine IP adresse eingeben? Eine dyndns adresse wird nicht
angenommen und es erscheint beim nachschauen die IP 0.0.0.0
Hat da wer ein Tipp für mich?
Liebe Grüße
Andreas
Es spielt doch gar keine Rolle wor ein MQTT Server steht !
Das kann intern oder extern sein.
Mein Vorschlag für die Programmierer wäre:
MQTT ein/aus wählbar
Wenn MQTT ein, dann
A) IP Addr und Timeout in ms angebbar
B) DNS Adr. und Timeout in ms angebbar
Reihenfolge zur Erreichbarkeit Auswahl:
(folgende Optionen nur wählbar, wenn A) bzw. B) auch ausgefüllt)
Nur A)
Nur B)
Erst A) und wenn nicht erreichbar bis Timeout dann B)
Erst B) und wenn nicht erreichbar bis Timeout dann A)
So was in der Art würde vielleicht Sinn machen. Wer einen github Account
hat, kann das ja gerne kopieren und dort hinterlegen. Ich habe da
aktuell keinen Account.
Tobi D. schrieb:> Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso> dann eine Dyndns Adresse?
Sie können einen Server außerhalb in der Cloud haben
Mir ist etwas interessantes aufgefallen, für was ich keine Lösung finden
kann:
- Mit ahoy v0.4.14 - alles funtkioniert bestens.
- Mit ahoy v0.4.20 - "Inverter is available but is not producing"
Einstellungen sind alle gleich - getestet per OTA-Update als auch direkt
aus Arduino auf den 8266 geladen.
Ich bin leider kein Programmierer und kann nicht so weit in die Materie
hereinschauen wie ihr, eventuell hilft aber der Hinweis
dax schrieb:> Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter> nicht
Der Wechselrichter produziert korrekt. Ich habe zwei ESP8266 mit
NRF24l01+ hier aufgebaut um die Versionen zu testen.
Mit Version 0.4.14 bekomme ich die nachweislich korrekten Werte
angezeigt, mit Version 0.4.20 den oben beschriebenen Fehler.
Es liegt nicht an der technischen Installation; es scheint zwischen
beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser
Meldung führt.
oxylog schrieb:> Es liegt nicht an der technischen Installation; es scheint zwischen> beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser> Meldung führt.
Hast Du die Pinout Einstellungen mal angepasst?
dax schrieb:> Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter> nicht
Ist ja auch irgendwie erwartungsgemäß. Interessant wäre dann auch mal
das Event-Log. Da müsste dann ein code 141 'Grid overvoltage' drin
stehen.
Yes, die Einstellungen sind gleich wie bei meinem Testaufbau.
Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht
solche Fehler zu vermeiden.
0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings
führen unter 0.4.20 zur Fehlermeldung.
Kann das an einer NRF-Library-Version hängen?
oxylog schrieb:> Yes, die Einstellungen sind gleich wie bei meinem Testaufbau.> Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht> solche Fehler zu vermeiden.> 0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings> führen unter 0.4.20 zur Fehlermeldung.> Kann das an einer NRF-Library-Version hängen?
Ok, jetzt habe ich doch einen Ansatz gefunden. Nochmals alle
Bibliotheken aktualisiert, nochmals kompiliert - alle Einstellungen in
Arduino überprüft - jetzt geht es.
Sorry für den Trouble!
Norman Z. schrieb:> Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon> erfolgreich mit dem Projekt zum laufen gebracht?
Hier steht im Datenblatt als Kommunikationsmedium "Sub-1G wireless". Das
ist kein Nordic Semiductor NRF24 2.4GHz Modul. Wird also nicht
funktionieren (würde ich annehmen)
Hallo,
hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt
sind?
Hier HM-800 an ESP8266.
Siehe Screenshot.
Ich habe auch festgestellt das wenn der MQTT Server mal weg ist (oder
man die falsche IP vergibt) der ESP nach einiger Zeit nicht mehr
reagiert.
> hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt> sind?
Hatte ich im Zusammenspiel PubSubClient und IOBroker MQTT schon öfters,
nicht nur beim Ahoy.
> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die> gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich> zufrieden damit bin).
Wenn du noch Tester brauchst :)
>> Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste> ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ?>> Marcel
Hallo Marcel
Dein Transmit waere korrekt. 100% wird, wenn danach noch ein Byte kommt
(abs. Watt) immer ignoriert, aber ich lasse immer 100% drin, zum
debuggen ist einfacher.
Ich denke das command:0x51 mit subcommand:0x5a5a funktioniert bei den
HM's nicht, du bist der 2. Tester. Schade :-(
Da ich kein HM habe, kann leider auch nicht sniffen, aber bald gibts bei
mir einen HM-1500, dann kann ich es sicher heraus finden.
Gruss
@Ziyat T. das wäre super. Ich bin nämlich mit meinem Latein am Ende.
Habe mir die Doku nochmal angeschaut, aber irgendwann iser der Kopf nur
noch voll. :(
1N 4. schrieb:>> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die>> gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich>> zufrieden damit bin).>> Wenn du noch Tester brauchst :)
Sehr gerne. Du kannst meinen Fork checken:
https://github.com/a-marcel/ahoy/tree/main/tools/esphome
Ich würde gern wissen ob es auf einem esp8266 funktioniert.
Ebenfalls habe ich Probleme die Payload in ein array zu packen und diese
dann an den ESP Logger zu übergeben. Derzeit loggt er noch direkt zu
Serial und das sieht man später nicht im EspHome log.
Und wenn du mit der Readme nicht klar kommst, nehme ich sehr gerne
Kommentare an.
Bisher läuft sie seit 1 Woche gut durch. Mit kleineren Aussetzern aber
keinen Reboot.
Vielen Dank
Marcel
>> Wenn du noch Tester brauchst :)> Sehr gerne. Du kannst meinen Fork checken:> https://github.com/a-marcel/ahoy/tree/main/tools/esphome> Ich würde gern wissen ob es auf einem esp8266 funktioniert.
Ich versuche das mal über das IOBroker - ESPHome Plugin zu kompilieren
:)
Hallo Daniel R.,
hat eigentlich schon mal jemand versucht den Code von gitee.com
(iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im
Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an
die HM-Wechselrichter versenden / verpacken würde ?
Das müsste doch in einer PlatformIO Umgebung oder einem STM IDE ohne
weitere Bibliotheken gehen ... es scheint zumindest alles vorhanden.
Ich strauchle immer noch über die Vorbelegung der beiden
Laufzeit-Variablen TotalIndex_Para und Index_Para in den
UsartNrf3_Send_PackDevControl() Aufrufen in der
UsartNrf_Send_DevControlUpdate() Methode:
und es sollte evtl. irgendwas wie das Folgende herauskommen:
0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f
Über den Wert aus PowerPFDev 0x03EB0001 bzw. Pass.Data[4] wird noch mit
CalcCRC16t und Get_crc_xor eine/mehrere Prüfsummen gebildet.
PS: die InverterMajor Struktur sieht wie folgt aus:
1
InverterMajor
2
Property
3
Pre_Id[2] (vu8)
4
Id[4] (vu8)
5
Port (PortType)
6
Id_In_Phase (vu8)
7
Acq_Switch (vu8)
8
Power_Limit (vu16)
9
Pass (PassValueType)
10
PowerPFDev (PowerPFDevType)
11
SetValut[2] (vu8)
12
Desc[2] (vu8)
13
ClearAlarmDev (ClearAlarmDevType)
14
WCode[2] (vu8)
15
EletricSet (EletricSetType)
16
Info[2] (vu8)
17
Data[16] (vu8)
18
PassWordSet (PassWordSetType)
19
PWO[4] (vu8)
20
PWN[4] (vu8)
21
ATTime[2] (vu8)
22
Data[18] (vu8)
23
PropertyMsg[30] (vu8)
Und hier sind die für MI und HM definierten Lower Bytes der Pre_Id's die
Id sind jeweils die lower 4 Bytes der Inverter Serial No.
Serial Number: Pre_Id[2] + Id[4]
Hierbei ist 0x05 bzw. 0x03 der Wert des (PowerLimit * 10) dividiert
durch die maximale Leistung (9*300W=2700W) des Inverters (bei 300 W pro
"Kanal") wobei die HM-Modelle offenbar eine maximale Spitzenleistung
zwischen 2100 W und 3000 W zur Validierung der führenden Stelle
verwenden bzw. verkraften ?
Im obigen Beispiel also:
1
(1000*10)/(300*9)=10000/2700=3.70->(u8) 3
2
(1500*10)/(300*9)=15000/2700=5.55->(u8) 5
3
(400*10)/(300*9)= 4000/2700=1.58->(u8) 1
Danach folgt in zwei weiteren Bytes das PowerLimit nochmal als Hex-Wert,
hier 0x05DC (1500 W) bzw. 0x03E8 (1000 W) oder 0x0100 (400 W).
Hier noch die Anzahl der "Kanäle" bzw. der maximale
Spitzenlast-Leistungsindex der Inverter:
1
typedef enum
2
{
3
InitInverterType = 0,
4
Inverter_250 = 1,
5
Inverter_500 = 2,
6
Inverter_1000 = 4,
7
Inverter_Pro = 7,
8
Inverter_HM_OneToOne = 8,
9
Inverter_HM_OneToTwo = 9,
10
Inverter_HM_OneToFour = 10,
11
} InverterType;
und die entsprechende Routine um den Invertertyp zu bestimmen.
Hi Stefan,
Stefan T. schrieb:> hat eigentlich schon mal jemand versucht den Code von gitee.com> (iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im> Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an> die HM-Wechselrichter versenden / verpacken würde ?
Ja da war ich dran, jedoch denke ich das ich dann an meine grenzen
gekommen bin. Ich mag es eigentlich nicht alleine zu Coden.^^
Da ich irgendwann Abends nur noch frustriert bin wenn es nicht so voran
geht wie ich es mir eigentlich wünsche. ^^
> und es sollte evtl. irgendwas wie das Folgende herauskommen:> 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f
Genau das habe ich letztens auch verschickt... nur ich glaube
mittlerweile das ich einen kleinen Fehler hatte (der großes bewirkt).
Asche auf mein Haupt - Natührlich möchte ich auch ehrlich sein und den
Fehler kongretisieren: In der Excel stehen ja die Protkolle wie Sie
auszusehen haben, daran habe ich mich gehalten. Nur habe ich Bsp. 0x0B
geschickt, statt 0x0B00 wie es teilweiße im *.c zu sehen ist. ;(
Sobald ich heute Zuhause bin, schaue ich mir das ganze nochmal an. Habe
mir jetzt paar Tage abstand gehalten und habe wieder einen freien Kopf
dafür. :)
Danke für eure Hilfe!
> PS: die InverterMajor Struktur sieht wie folgt aus:
Das habe ich auch gesehen.
Edit: Ganz kurz für dumme (wie mich), ich bin kein Profi meine aber auch
etwas drauf zu haben. ^^
Mir ist auch aufgefallen im Code das sogar Unterschieden wird welcher WR
genau angesprochen wird. Ob es 1/2/4 Kanal hat und und und...
Ich war kurz davor das ganze zu portieren, jedoch bevor ich mir die
Arbeit gemacht hätte habe ich zuerstmal versucht direkt aus der
Paketstruktur die Daten zum WR zu senden und erst wenn das funktioniert
ein ordentliches funktionen geschrieben damit es später automatisch im
Hintergrund auch richtig verarbeitet wird (so wie es im code zu sehen
ist).
Der einzige Knackpunkt womit ich zu kämpfen habe, ich lese ganz gerne
die einzelnen Hex werte als Byte durch. Bsp: 05 06 07 08 09 0A ...
Wenn mir jemand 0x0500 schreibt, bin ich immer dabei nur die 0x05 zu
sehen. Was an sich falsch ist! // Daher ein Fehler von mir. ;(
PS: Wenn jemand Lust hat, kann man sich mal auf Discord treffen.
Einfach melden, ich schicke den Einladungslink dann.
Stefan T. schrieb:> und es sollte evtl. irgendwas wie das Folgende herauskommen:> 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f
- CMD 0x51 hat kein SubCMD 0x81 ????
- Warum schickst du diese 0x7e/0x7f ???
Diese sind nur für DTU-NRF intern Serial Kommunikation, die werden nicht
in die Luft geschickt!!
Gruss
Daniel R. schrieb:> Hallo zusammen,>> also ich habe das mal probiert. Kein erfolg.> Bekomme höchstens immer folgende Antwort:>> Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00> 00 00 00 00 00 00 00 00 00 01 81 eb 9b> Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
Wenn du das auch schreiben würdest was du geschickt hast?
edit:
das auch beachten
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
> Daniel R. schrieb:> Hallo zusammen,>> also ich habe das mal probiert. Kein erfolg.> Bekomme höchstens immer folgende Antwort:>> Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00> 00 00 00 00 00 00 00 00 00 01 81 eb 9b> Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
Was du gesendet hast, würde mich auch interessieren, denn ich habe
bisher noch nicht mal eine Antwort bekommen und das was du da geschickt
hast ... darauf kann man ja aufbauen und rumspielen.
Danke
Marcel
Herbert K. schrieb:> Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit> HMT-xxxx, HMS-xxxx, DTU-Pro-S.>> Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt.> Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless">> Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt.> Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless"
Jetzt habt ihr hier einen Thread mit weit über 1000 Beiträgen - Respekt
Ich lese oft nicht nicht mehr mit - alleine weil mi das laden zu lange
dauert
Aber Herbert - so geht das leider auch nicht
Dann mach doch Dein eigenes Forum für die Hoymiles-WR auf?
Oder überzeuge die Mc-Admins hier eine eigene Unterrubrik zu machen?
Einfach Leute mit für Dich uninteressante Themen abwimmeln - dann erst
mal raus mit allen Mi-WR-Besitzern, hier geht es um die HM-Serie
VG
Hallo Jan-Jonas,
ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das
DTU-NRF Protokoll an sich ist schon interessant und bei der aktuellen
Situation wäre es schon praktisch, wenn man die HM-Wechselrichter evtl.
mit einem eigenen Grid Profile (laut Source Code kann man ein 1200
Punkte langes Window-Frame aufnehmen (Sinux, Sägezahn, Rechteck, etc.
=^} welches dann m.E. zur Analyse und Nachbildung der aktuellen
Wechselstromkurve dient) bestücken könnte oder gar die Firmware updaten
kann ...
Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren,
einfach die Hauptsicherung rausdrehen und ab geht die Luzie! Jaja ich
weiß darf man natürlich alles nicht wenn (solange) es an das
Niedervolt-Netz des lokalen Elektrizitätversorgers angeschlossen ist.
@Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen
Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es
den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir
mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^!
@Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End
Transmission Bytes, die die DTU Software für die SPI Kommunikation mit
dem NRF24 Modul als STX/SOF und ETX/EOF einfügt. Die kannst DU auch
gerne weglassen, weil sie evtl. von der NRF24 Bibliothek eh eingefügt
werden. Ich habe Sie nur im Zusammenhang mit der analysierten Code
Stelle erwähnt.
Wegen den PortType's gehe ich davon aus, dies sind die einzelnen DC
Eingangsports der unterschiedlichen HM- und MI-Wechselrichter Typen. Die
eigentlichen Invertertypen werden in UsartNrf_GetInvterType() aus der
Pre_Id also den ersten beiden Bytes der Seriennummer (z.B. 1141 bei
meinem HM-600 führt zu einem Inverter_HM_OneToTwo) abgeleitet.
Die DC PortType's werden hingegen bei der Berechnung der einzelnen
Leistungen berücksichtigt / unterschieden, da ja jeder Eingang (DC Ports
A/B/C/D) auch unterschiedlich viel Ertrag bringen kann. Das wird dann
m.E. in AntiReflux.c/.h gebraucht um die Leistung aller Wechselrichter,
die von einer DTU kontrolliert werden, möglichst gleichmäßig auf alle
drei AC Phasen A/B/C zu verteilen.
@Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll
zumindest die elektronische und funkseitige Komponente der HMT- / HMS-
und DTU-Pro-S in einem übersichtlichen Thread zu behandeln. Keine Ahnung
ob dafür aber zwei/drei separate Threads notwendig & hilfreich sind (da
vermutlich keiner von uns dort regelmäßig liest) und wie viele Anfragen
dazu überhaupt reinkommen. Andererseits scheint die DTU-PRO-S eventuell
sogar den selben Basis Code wie im gitee.com zu verwenden. Es gibt
zumindest eine Vielzahl von #ifdef DTU3PRO und die aktivieren einen
stm32f4xx anstelle eines stm32f10x Prozessors. Vielleicht finden sich ja
irgendwo auf einer FCC ID Seite irgendwelche Informationen zur CPU ?
Stefan T. schrieb:> @Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen> Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es> den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir> mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^!
Kann ich heute anhängen, log sei dank. =)
Thomas B. schrieb:> Es gibt noch etliche Stellen die nicht perfekt sind, einer> Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte> erstmal was lauffähiges haben.> Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU> Im docs Ordner gibt es auch ein paar Screenshots der WebGUI.>> In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking> Changes" geben was die Namen der MqTT Topics anbelangt.> Die Payload Erzeugung habe ich auch schon in die Inverter Klassen> verlegt. Dies ist jedoch mangels Test noch nicht commited.>> Über Anregungen und/oder PRs würde ich mich freuen.>> Grüße> Thomas
Hallo Thomas,
ich habe es gestern endlich geschaft deine ESP32 Version mit meinem
HM-400 zu testen.
Es lief auf anhieb ohne Probleme.
2 Dinge sind mir mit der aktuellen Version aufgefallen:
- Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone
zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten
Tabelle
- MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und
im Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es
kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob
MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK
ist.
Eventuell liegts auch am MQTT Server?
John P. schrieb:> Thomas B. schrieb:>>> Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU>> Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone> zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten> Tabelle
Da war ich schon dran und hab auch einen PR gemacht. Den könntest du
probieren. Als nächstes wollte ich noch die NavBar und das Scrolling
angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu
About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei
Tablet / mobile aufgefallen war.
Stefan T. schrieb:> Hallo Jan-Jonas,> ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das
Es sind Leute da, die nicht in Deutschland leben, es gibt Laender da
darfst du nichts einspeisen, wenn dann bezahlst du die Einspeisung auch!
> Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren,
Die Gedanken habe ich auch gemacht, es waere nett ;-)
> @Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End> Transmission Bytes, die die DTU Software für die SPI Kommunikation mit> dem NRF24 Modul als STX/SOF und ETX/EOF einfügt.
Das meinte ich ja auch, waere besser hier ohne STX/SOF und ETX/EOF zu
kommunizieren, weil es mich irritiert, ob ihr das Packet mit oder ohne
sendet
> @Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll> zumindest die elektronische und funkseitige Komponente der HMT- / HMS-> und DTU-Pro-S in einem übersichtlichen Thread zu behandeln.
Vorlaeufig finde es auch
Axel H. schrieb:> Da war ich schon dran und hab auch einen PR gemacht. Den könntest du> probieren. Als nächstes wollte ich noch die NavBar und das Scrolling> angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu> About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei> Tablet / mobile aufgefallen war.
Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute
Abend mal drüber schauen.
John P. schrieb:> - MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und> im Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es> kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob> MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK> ist.> Eventuell liegts auch am MQTT Server?
Könntest du für solche Themen ggf. bitte einen Issue auf Github
aufmachen? Dann bleibt hier der Thread für die wichtigen Themen frei.
Hast du ACL's konfiguriert? Ein MQTT Client kann nämlich nicht
feststellen ob er an die entsprechende Topic publishen darf. Wenn das
z.B. durch ACL's (oder Benutzer rechte) verboten ist gehen die
Nachrichten einfach unter. Ich habe das selbst mit einem Mosquitto
(letzte Debian Pakete von mosquitto.org also Version 2.x) Broker im
Einsatz und kann erst mal keine Probleme feststellen.
Thomas B. schrieb:> Axel H. schrieb:>> Da war ich schon dran und hab auch einen PR gemacht. Den könntest du>> probieren. Als nächstes wollte ich noch die NavBar und das Scrolling>> angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu>> About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei>> Tablet / mobile aufgefallen war.>> Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute> Abend mal drüber schauen.
Lass Dich nicht stressen. Die PRs werden auch nicht dauerhaft in der
Frequenz kommen. Hab hier gerade in Betrieb genommen und arbeite meine
Liste ab. Wenn ich schon nichts zum RE des Protokolls beitragen konnte.
Dafür übrigens herzlichen Dank an alle Beteiligten! Mit zu lesen und zu
fiebern hat extrem viel Freude gemacht und war erkenntnisreich!
Als ich im März bestellt hatte, war das die eine Kröte, die ich
geschluckt habe. Dass Auslesen nur über die Cloud geht und ich da halt
drauf verzichten werde. Dass das jetzt doch geht ist ganz hervorragend!
Hallo zusammen,
ich lese sporadisch mit und bin auf der Suche nach einer Lösung für
meinen HM-1500.
Leider reichen meine Kenntnisse nicht aus, dass hier alles geschriebene
nachzuvollziehen und zu verstehen.
Daher meine Frage, gibt es von euch bereits ein fertiges Produkt was ich
kaufen könnte? Im Moment habe ich das DTU Teil im Einsatz, allerdings
gefällt es mir überhaupt nicht, dass ich so viele Daten preisgeben muss.
Vielen Dank für eure Antwort.
Gruß
Hallo Ronny,
es gibt verschiedene Lösungen. Es kommt drauf an was für dich am
einfachsten ist.
Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann...
dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und
Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine
kleine Bezahlung?).
Natührlich wird hier daran weiter gearbeitet.
Ich habe auch noch viele Ideen was man hinzufügen kann.
Jedoch wird aktuell verstärkt an der Limitierung gearbeitet.
Im Grunde geht das Auslesen der Werte.
Mehr aus dem Github zu entnehmen:
https://github.com/grindylow/ahoy/ (hier wird m.E verstärkt gearbeitet)
oder
https://github.com/tbnobody/OpenDTU
Marcel A. schrieb:> Was du gesendet hast, würde mich auch interessieren, denn ich habe> bisher noch nicht mal eine Antwort bekommen und das was du da geschickt> hast ... darauf kann man ja aufbauen und rumspielen.
@Eike (Gast): Dies ist kein Restaurant mit Kellner !
Dies ist ein Buffet. Da muss man sich selbst bedienen !
Alles was Du wissen möchtest wurde in vorherigen Beiträgen mehrfach
beschrieben. Teilweise mit Fotos, Links, Bezugsquellen,
Verdrahtungsplänen. Du brauchst Dir nur die Informationen vom
Buffet=Beiträge nehmen.
vielleicht kann mir einer helfen
ich hab seit gestern einen d1 mini mit dem funkmodul laufen
soweit funktioniert alles gut, webseite läuft und die daten kommen auch
beim iobroker an.
nur leider ist der d1 mini immer wieder im netzwerk nicht mehr
erreichbar
ping bricht ab.
ich hab noch einige andere d1 mini laufen wodurch ich ein wlan problem
ausschließe
was könnte da sein?
version hab ich die 0.4.20
tom schrieb:
> nur leider ist der d1 mini immer wieder im netzwerk nicht mehr> erreichbar> ping bricht ab.
Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83
Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich.
Versucht werden kann:
- Anderes Netzteil/Kabel,
- Elko über +/GND des nRF24L01+,
- das Abfrageintervall auf 30 s einstellen.
Daniel R. schrieb:Marcel A. schrieb:>> Was du gesendet hast, würde mich auch interessieren, denn ich habe>> bisher noch nicht mal eine Antwort bekommen und das was du da geschickt>> hast ... darauf kann man ja aufbauen und rumspielen.>> [code]> Poll inverter 116174403329> 2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81> 5a 78 35 61 00 78 30 31 01 00 f8
Hab schon mal drauf hingewiesen: CMD 0x51 hat kein SubCMD 0x81, dann
0x5a etc. oder hab ich etwas übersehen?
Dann sehe ich Unixtimestamp drin, Tue Jul 27 2021 21:18:40 GMT+0000
Dieses Polling für HM kann nicht gehen.
Set Time/Data geht z.Bsp. so CMD 0x15 mit SubCMD 0x80 und Timestamp:
15 72220200 72220200 80 0B 00 62 09 04 9b 00 00 00 00 00 00 00 00 F2 68
F0
CMD 0x51 hat SubCMD 0x5A5A für Limitierung
CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock
Und diese funktionieren scheinbar nur mit MI-1500, bisher..
Ziyat T. schrieb:> CMD 0x51 hat SubCMD 0x5A5A für Limitierung> CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock> Und diese funktionieren scheinbar nur mit MI-1500, bisher..
Das ist korrekt! Steht ja auch in der Excel/c-File.
Günter H. schrieb:> tom schrieb:>> nur leider ist der d1 mini immer wieder im netzwerk nicht mehr>> erreichbar>> ping bricht ab.>> Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83> Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich.> Versucht werden kann:>> Anderes Netzteil/Kabel,> Elko über +/GND des nRF24L01+,> das Abfrageintervall auf 30 s einstellen.
Danke für die Infos, werde ich testen.
Welcher Elko wäre ideal?
Ich n
tom schrieb:>> Anderes Netzteil/Kabel,>> Elko über +/GND des nRF24L01+,>> das Abfrageintervall auf 30 s einstellen.
Ich nutze ein Iphone Netzteil.
Ohne Elko etc.
Elko >= 1000 uF / 10 Volt passt auf jeden Fall.
Ein 100 nF zus. parallel kann auch nicht schaden.
Hier
https://github.com/grindylow/ahoy
gibt es für das D1 mini-Board die Firmware Version 0.4.22.
Das Kompilieren geschieht jetzt über Visual Studio Code/Platformio.
Da ich diese Software vor einigen Tagen zum Testen der Firmware für das
ESP32-Board installiert hatte, wurde nach Download des
"ahoy-main.zip"-Ordners und dem Öffnen der "platformio.ini" mit dem
"Platformio: Build"-Befehl (überraschenderweise) erfolgreich eine
"firmware.bin" erzeugt. Im Platformio-Explorer findet man den
Speicherort der neuen Firmware - ggf. im Windows-Explorer suchen.
Mit dieser neuen Firmware habe ich dann von Version 0.4.20 problemlos
ein Update auf 0.4.22 gemacht.
Was das Update in Richtung Stabilität bringt, kann ich naturgemäß noch
nicht sagen.
Der Text oben ist von jemandem verfasst, der von Programmieren praktisch
null Ahnung hat.
Die Default-Verschaltung ab 0.4.20 habe ich mit angehängt.
hab vorhin gerade die 0.4.22 drauf gespielt.
die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der
seriele debug print weiter läuft auch wenn der d1 mini per netzwerk
nicht mehr erreichbar ist?
Daniel R. schrieb:> Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann...> dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und> Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine> kleine Bezahlung?).
Das war eigentlich mein Plan. Also eine Platine layouten, fertigen
lassen und für die die nicht löten wollen/können würde ich die auch
bestücken und alles in eine feines Gehäuse packen um das Ganze dann für
Selbstkostenpreis + kleiner Aufwandsentschädigung anzubieten.
Nun habe ich die Platine ja schon fertig, und zur Probe mal eine selbst
geätzt und bestückt. Leider hat sich herausgestellt das der Empfang sehr
viel schlechter ist als mit der Breadboard Version :(
Dann habe ich die Schirmung des RF24 entfern, keine Besserung.
Dann habe ich das Netzteil entfernt und per USB versorgt, keine
Besserung.
Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt
positioniert, keine Besserung.
Die Platine unter Lupe natürlich optisch auf Fehler untrsucht,
durchgemessen, nix zu finden.
Den RF ausgetauscht, keine Besserung.
Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang
bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m
Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern
muss damit es so gut funktioniert wie auf dem Steckbrett.
Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört
die Massefläche der Platine ?
Ich komm nicht weiter ...
Holger S. schrieb:> Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört> die Massefläche der Platine ?
Ich habe mir als purer Anfänger meine Platinen bei Aisler "schnitzen
lassen" - funktionieren problemlos ohne Empfangsprobleme.
Ich habe den D1 direkt neben dem NRF24l01+ (nicht über) und dachte mir
erst "das geht schief" - tut was es soll ohne große Schirmung.
Entweder die wirklich "räumliche Nähe" oder die Massefläche
tom schrieb:> hab vorhin gerade die 0.4.22 drauf gespielt.> die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der> seriele debug print weiter läuft auch wenn der d1 mini per netzwerk> nicht mehr erreichbar ist?
kann es sein das die probleme vom webserver kommen?
wenn ich ganz oft die webseite aktualisiere fällt die netzwerkverbindung
bei mir aus.
ist das bei euch auch?
Rene M. schrieb:> Kannst du die neue -.bin auch raufladen?> Bei mir funzt das mit platformIO nicht
Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine
erste CI (GitHub Actions), die nach dem Commit von Code die Firmware
automatisch baut und sogar als Artifakt zum Download zur Verfügung
stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90
Tage, dann werden die automatisch gelöscht.
Hier z.B. das von gestern:
https://github.com/grindylow/ahoy/actions
dann auf den obersten Eintrag klicken, ganz unten erscheint dann das
Artifakt
Günter H. schrieb:> Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update> (vor> knapp 4 Std.) stabil.
das hatte ich auch schon probiert, leider ohne verbesserung, auch mit
60s hab ich probiert
Holger S. schrieb:>> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang> bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m> Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern> muss damit es so gut funktioniert wie auf dem Steckbrett.> Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört> die Massefläche der Platine ?>> Ich komm nicht weiter ...
Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit
2,4Ghz !!
Nebeneinander mit Abstand und der Variante ein Blech das man dazwischen
einlöten kann. Und den Wemos gleich mit Pigtail für externe Antenne
nehmen.
Die kurzen Leiterbahnen vom Chip zur Antenne strahlen ja auch schon was
aus.
Hallo Holger S.,
wenn ich mir die Erfahrungen / Kommentare zu Deiner Platine und den
Aufbau der Anderen durchlese fällt mir auf, daß nur Du auch den AC/DC
Transformator und den Spannungsregler mit auf der Platine hast.
Hast Du Dir mal die Spannung am ESP mit einem Oszi angeschaut ?
Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und
dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du
ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat.
Sind ja immerhin 50Hz ?
Holger S. schrieb:> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang> bei meinem Aufbau.
Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken
sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden.
Trotzdem könnte ich mir das vorstellen.
Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und
platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch?
Ok, Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D
Hallo Holger,
hast du schlechten Empfang oder gar keinen Empfang?
Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich
das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen
ob die Verbindung auf deiner Platine stimmt.
Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung
von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da
sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht
sehr knapp aus.
Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand
zwischen der 230V AC Seite zur Niederspannungsseite. Der 230V AC Bereich
sollte eindeutig von der Niederspannungsseite getrennt sein.
Wenn ich mich recht erinnere, muss man hier 8mm Abstand einhalten.
Am besten den Stabi mit Elko zwischen ESP und Netzteil-Modul
positionieren. Evtl. auch das Netzteil um 90 Grad drehen.
Und die Sicherung auf der AC Seite nicht vergessen, außer du hast sie in
der Netz-Leitung integriert.
Lukas P. schrieb:
> Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine> erste CI (GitHub Actions), die nach dem Commit von Code die Firmware> automatisch baut und sogar als Artifakt zum Download zur Verfügung> stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90> Tage, dann werden die automatisch gelöscht.>> Hier z.B. das von gestern:> https://github.com/grindylow/ahoy/actions>> dann auf den obersten Eintrag klicken, ganz unten erscheint dann das> Artifakt
Danke für diesen Hinweis, das ist ein sehr einfacher und schneller
Zugang zur aktuellen bin-Datei.
Ergänzung: Man muss bei guthub angemeldet sein, um das Artifakt
herunterladen zu können.
Holger S. schrieb:> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang> bei meinem Aufbau.
Wenn man sich das Layout anguckt fällt mir etwas auf:
Der Elko ist völlig nutzlos. Dieser gehört nicht irgendwo auf die
Leiterplatte, sondern nach an den NRF24L01+.
Die 6mm Abstand (oder Fräsung) zwischen 230V und Niederspannung wurden
schon erwähnt. Sind aber nicht die Ursache deines Problems.
Wenn du deine Layout datein mit uns teilst können wir noch mehr tipps
geben.
Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen
Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT
mit zu übertragen?
Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man
beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen
anderen Weg...?
Holger S. schrieb:> Ich weiß nicht was ich verändern> muss damit es so gut funktioniert wie auf dem Steckbrett.
Disclaimer: Ich habe weder beruflich noch in der Ausbildung mit Platinen
oder Schaltungen zu tun!
Hallo Holger,
wenn ich das richtig erkannt habe, dann finde ich die GND-Verbindung vom
RF24 nicht optimal. Die geht auf den Fotos nur durch das GND-Pad vom
Wemos. Ob die Empfangsprobleme damit zu tun haben, könnte man mit einer
schnellen Kabelbrücke testen.
Und dann wollen doch die meisten LDO auch noch einen Kondensator am
Ausgang. Gerade die RF24 scheinen doch relativ empfindlich auf die
Restwelligkeit zu reagieren. Hatte ich so zumindest beim Mitlesen für
mich rausgeschlossen.
Aber beides nur spontane Ideen eines Hobbyisten.
Gruß
Axel
Daniel R. schrieb:> Holger S. schrieb:>> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang>> bei meinem Aufbau.>> Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken> sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden.> Trotzdem könnte ich mir das vorstellen.>> Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und> platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch?>> Ok, Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D
Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit
Reboots) mit dem WR. Distanz zum WR ca. 15m.
https://www.mikrocontroller.net/attachment/560492/DE6F5772-A240-4F90-AB27-12E40A65CEF2.jpeg
Peter L. schrieb:> Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen> Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT> mit zu übertragen?>> Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man> beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen> anderen Weg...?
ioBroker hat für jedes Objekt mehrere Timestamps, zB wann es erzeugt
wurde und wann es zuletzt aktualisiert wurde. Ich kann mir vorstellen,
dass sich andere Systeme hier genauso verhalten und sehe daher keine
Notwendigkeit den timestamp extra zu schicken.
@Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen
Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt:
https://github.com/grindylow/ahoy/issues/83
Stefan T. schrieb:> Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und> dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du> ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat.> Sind ja immerhin 50Hz ?
Zitat aus meinem Post:
"Dann habe ich das Netzteil entfernt und per USB versorgt, keine
Besserung."
Daniel R. schrieb:> Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und> platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch?Richard K. schrieb:> Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit> 2,4Ghz !!
Zitat aus meinem Post:
"Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt
positioniert, keine Besserung."
Claus T. schrieb:> hast du schlechten Empfang oder gar keinen Empfang?> Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich> das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen> ob die Verbindung auf deiner Platine stimmt.> Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung> von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da> sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht> sehr knapp aus.> Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand> zwischen der 230V AC Seite zur Niederspannungsseite.
Der Empfang ist da, aber es werde sehr viele Fails erzeugt und von den 6
Invertern sind meist nur 2 available.
Die Leiterbahnen sind OK. Das ist schlecht zu fotografieren. Aber unter
der Lupenlampe nochmal gecheckt und durchgemessen hatte ich das ja auch.
Das hätte auch gleich smoke gegen wenn da ne Verbindung ist. Der Aufbau
funktioniert ja auch, nur der Empfang taugt nix.
Den Abstand 230V werde ich noch vergrößern. Wahrscheinlich lasse ich das
on Board Netzteil wohl auch weg. Ich dachte es wäre ne gute Idee, aber
wenn ich den Wemos und den RF24 nebeneinander setzten muß, und die
Abstände vergrößern soll, wird mir das ganze schon wieder zu groß und
muß in ein anderes Gehäuse. Dann eben nicht kompakt und mit extra USB
Nezteil.
Peter L. schrieb:> Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit> Reboots) mit dem WR. Distanz zum WR ca. 15m.
Tja, deshalb bin ich ja so Ratlos.
Dear All,
At first let me express my respect to all who contributes to this topic.
I am follwing this thread since a while and I am using the pre-compiled
version 0.4.19 on a Wemos D1 mini clone anf HM-800 inverter and Home
Assistant.
The pre-compiled image works for me only when I use pins D2/D1 instead
of D4/D3 for signal CE/IRQ.
Hello Marcel,
I am trying to compile your ESPhome version on a 8266 (Wemos D1 mini
clone)
ESPHome version: 2022.5.1
I am facing with an issue defining the serial number of the inverter.
If I set the serial number as a hex number ( 12 digit decimal number
converted to hex) like in your example file:
1
serialnumber:"0x1234567890"
then the ESPhome enters to a boot loop with the following output on the
console:
Zsolt Z. schrieb:
Hello Zsolt, you can try this. I don´t know if it is working so.
Example (see hmRadio.h)
// Serial WR : 1141 74 11 22 33 Label on Inverter
try
// #define WR1_RADIO_ID ((uint64_t)0x 33 22 11 74 01ULL)
only for better readable for your eyes
// #define WR1_RADIO_ID ((uint64_t)0x 74 11 22 33 01ULL)
only for better readable for your eyes
(see hmRadio.h)
// in Source Code
#define WR_RADIO_ID ((uint64_t)0x3322117401ULL)
// OR try
#define WR_RADIO_ID ((uint64_t)0x7411223301ULL)
You have to change the example to YOUR serial number.
Holger S. schrieb:> Stefan T. schrieb:> Daniel R. schrieb:> Richard K. schrieb:> Claus T. schrieb:> Peter L. schrieb:> Tja, deshalb bin ich ja so Ratlos.
Hallo
Ich hatte lange auch ab und zu den ganzen Tag Empfang Probleme mit
Wemos, ich verwende meine spez. SW-Version auf Hubi's Basis.
Ich habe es lange gemessen und gesnifft, das Problem war nicht die HW !
(Edit: ich dachte auch mal die NRF sind futsch..)
- Ich würde mal die SW ohne Interrupt mit polling und ohne CRC
ausprobieren. Ich bin ziemlich sicher, dass mit Interrupt etwas verloren
geht, warum weiss ich nicht. Mit CRC geht vieles auch verloren. Ohne CRC
sind die Werte fast 97% richtig, die Falschen kann man ausfiltern.
- Ich bin auch ziemlich sicher, dass die WR's nicht immer auf CH3
senden, die SW muss beim RX auch hoppen. Mein MI-1500 sendet manchmal
einen Tag lang nur über CH61/CH75. Wenn die SW nur auf CH3 hört, siehst
du den ganzen Tag nichts!
Edit: versucht mal mit einer NRF24 Sniffer SW ob ihr mit der Dose etwas
empfaengt?
Hallo Zusammen,
erstmal vielen Dank für die tolle Arbeit hier.
Mein Setup:
- DTU-Lite
- HM1500 - 4 Module
- HM800 - 2 Module
- weitere 4 HM1500 kommen noch dazu
An meinem DTU-Lite habe ich über die Cloud alles verbunden mit dem
HM1500.
Leider kann der DTU ja nur 4 Module, deshalb bin ich jetzt auf die
8266/RF24 Lösung gestoßen und habe dieses gleich umgesetzt.
Bisher läuft dieses, aber wenn ich den DTU-Lite und den 8266 am laufen
haben, dann erhalte ich vom HM1500 oft keine Daten. Der HmM800 hat diese
Probleme nicht.
Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite
hängt und dadurch irgend welche Daten verloren gehen.
Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem?
Vielen Dank
Gruß
Denny S. schrieb:> - DTU-Lite> - HM1500 - 4 Module> - HM800 - 2 Module
...
> Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem?
Du kannst ja auch nicht 2 PKWs gleichzeitig fahren :-)
Vermutlich hat der HM1500 Probleme mit 2 DTUs zu kommunizieren ?
1. Möglichkeit: DTU-Lite Stromversorgung kappen - also aus das Teil
2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see
hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und
dann schauen, ob das dann funktioniert.
Wenn ich nix überlesen habe, hat das wohl noch niemand probiert.
Also zack und los :-) Du darfst als Erster :-)
Bin selbst gespannt. Viel Erfolg !
Variante 1 geht, aber ich würde gerne beides nutzen. Eine DTU-Pro habe
ich schon geordert, damit ich in Zukunft alle HM's auslesen kann.
Wieviele HM's kann der 8266 mit AHOY gleichzeitig lesen? Hat das jemand
mal getestet?
Variante 2 hatte ich schon probiert, aber dann bekomme ich überhaupt
keine Daten mehr.
Kann aber auch sein das ich mit der Seriennummer was falsch gemacht
habe.
Diese beginnt mit: 10D98015XXXX
Muss ich diese 1zu1 in die Zeile kopieren?
#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
Danke
schau heute um 10:25. Da hab ich geschrieben wie die SN einzutragen ist.
Die letzten 4 Zahlenpaare der SN. Musst einfach Beides mal probieren.
Die Anzahl der WR kannst Du auch irgendwo konfigurieren vor dem
Übersetzen.
Herbert K. schrieb:> 2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see> hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und> dann schauen, ob das dann funktioniert.
So hab ich die DTU-Pro<>MI-1500 gesnifft, schon am Anfang des Projekts.
Wenn du die gleiche Adresse eingibst wie die DTU, kannst alles mithören
was der WR sendet.
tom schrieb:> hat schon jemand versucht den webserver mal abzuschalten und schauen ob> der d1 mini dann immer noch neustartet?
Lukas P. (lumapu) schrieb:
> @Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen> Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt:> https://github.com/grindylow/ahoy/issues/83
Ich persönlich glaube, daß die von Tomas B genutzte AsyncWebServer
Bibliothek evtl. auch das Problem behebn könnte. Momentan verwenden wir
die ESP8266WebServer Library und die blockiert bis die Seite
ausgeliefert wurde.
Ich habe keine Ahnung wie die AsyncWebServer Bibliothek es genau macht,
aber anscheinend kann diese mehrere Requests parallel beantworten und
hat dazu so eine Art "Multithreading". Zumindest wird der Listener immer
gleich wieder freigegeben und steht dann für weitere Verbindungen zur
Verfügung. Vielleicht eine Funktion der AsyncTCP Bibliothek die als
Abhängigkeit dazu kommt.
@Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266
Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den
ESP8266 übersetzen ?
Stefan T. schrieb:> @Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266> Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den> ESP8266 übersetzen ?
ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist
so out of the Box wohl nicht möglich, da ich diverse Compiler und Linker
Features verwende die im Toolkit vom 8266 nicht vorhanden sind.
Denny S. schrieb:> Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite> hängt und dadurch irgend welche Daten verloren gehen.
Moin,
ich habe einen HM-1500 und frage ihn alle 10s mit ESP8266 und ESP32 ab,
unterschiedliche DTU-ID's, keine Probleme.
Dem WR ist es eigentlich egal, er antwortet stumpf. Das was ich mir
vorstellen kann, das er Probleme hat mit unterschiedlichen Zeitframes,
die er bekommt oder die Abfragen zu schnell nacheinander kommen.
Bei meine TSUN-DTU sehe ich im Sekundentakt abfragen, vielleicht
kollidiert es da, HM und TSUN sind ja quasi identisch.
Kannst du einfach mal deine DTU für ein paar Minuten trennen und
schauen, ob es dann geht?
Hallo,
ja wenn der DTU aus ist, gehen keine Daten verloren.
Ist der DTU an, sieht man gut das nur der HM1500 hin und wieder keine
Daten erhält (hängt am DTU), aber der HM800 (nur über AHOY) immer alles
korrekt ist.
Das mit der DTU Seriennummer ändern im AHOY habe ich auch probiert, aber
dann geht nix mehr.
Vielleicht geht das mit der DTU-Pro dann besser.
Thomas B. schrieb:
>> könnte man auch Deinen OpenDTU Code für den ESP8266 übersetzen ?> ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist so out
of the Box wohl nicht möglich, da ich diverse Compiler und Linker Features
verwende die im Toolkit vom 8266 nicht vorhanden sind.
Hallo Thomas, das habe ich gesehen vor allem das std::bind() für die
Interrupt Handler will er bei mir partout nicht übersetzen. Ich habe es
aber auch nicht hinbekommen die Interrupthandler außerhalb der
Klassenbzu definieren. Das scheint dem ESP8266 Cross Compiler nicht zu
gefallen. Das andere sind glaube ich div. Datentypen die beim ESP8266
etwas anders sind. Soll ich Dir die bereits gemachten Anpassungen
irgendwie per PR zukommen lassen ?
Hallo Denny S.,
ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR
sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn
Du das Abfrageintervall auf einen größeren Zeitraum stellst könnte es
evtl klappen aber mE bringst Du damit die Payload Decodierung aus dem
Tritt, weil er ja per Interrupt Pakete bekommt die er evtl grade gar
nicht erwartet.
Im DTU Code von Hoymiles sind zwar einige Bedingungen für falsche Pakete
(out-of-order) definiert die dann ggf. einen Abbruch der Verbindung und
ein sog. NET_INIT (ich glaube unser Zeit senden Paket) auslösen. Aber
auch im Ahoy-ESP8266 code schon alle Eventualitäten berücksichtigt sind
wage ich zu bezweifeln.
Der Hoymiles Code wartet auch max 300-500ms auf eine Antwort, da gibt es
eine ausführliche Methode die für jede Anfrage die sog LOCAL_TIME
berechnet bevor die Anfrage bzw Antwort verworfen wird und eine neue
Anfrage gestellt wird.
Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum
Ahoy-ESP zu betreiben ?
Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst
?
@Lukas evtl könnten wir ein sog Promiscuous Feature in die AHOY-ESP
Software einbauen, bei dem er selbst keine Anfragen sendet aber
ankommende Payloads versucht zu dekodieren ? Wäre ein Flag in den
Settings je WR und er müsste halt sehen ob er irgendwann das erste
Antwort-Paket und alle folgenden mitbekommt. Wenn es nicht klappt kann
er die Payload ja auch wieder verwerfen, da er ja kein Retransmit senden
kann/soll.
IsnoAhoy schrieb:> ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR> sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn
Auf der smiles-cloud kann man einen WR nur 1x registireren, DTU-lite
oder DTU-Pro
> Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum> Ahoy-ESP zu betreiben ?> Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst> ?
DTU-Lite kann nur 4 Module haendeln, ich denke er möchte mehr sehen...
Hallo @All,
Lukas und ich diskutieren gerade in
https://github.com/grindylow/ahoy/issues/36 und #83 ob wir einen ESP8266
mit 4MB Flash vorraussetzen können und sollen. Die HTML-Seiten und
Konfiguration scheint langsam den Flash zu füllen und die Wemos D1 mini
***LITE v1*** mit nur 1MB und einem ESP-07 würde damit als
***unsupported*** rausfallen. Wieviele von Euch nutzen den ESP-07 bzw.
einen Wemos D1 mini in der ***LITE v1*** mit nur einem 1MB Flash ?
Bitte im o.g. Github issue #36 und/oder #83 melden, damit wir die
Auswirkung dieser Änderung abschätzen können. Danke!
@Ziyat T.,
danke für den Hinweis es scheint sich in #91 heraus zu kristallisieren,
daß wir alle Antwort-Pakete ( egal für welche DTU ) die wir empfangen
auch versuchen in die Payloadstruktur zu integrieren. Wir sollten hier
also einen Plausibilitätscheck der DTU Addresse einbauen, außer wir sind
im o.g. Promiscuous Mode. Sonst kommen wir mit den Antworten für die
echte DTU und denen auf unsere Anfragen durcheinander.
Siehe https://github.com/grindylow/ahoy/issues/91
@Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und
eine original DTU (Lite/Pro) verwenden willst ?
Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ?
> @Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und> eine original DTU (Lite/Pro) verwenden willst ?> Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ?
Limitieren eines HoyMiles geht noch immer nicht :(
Moin Zusammen,
IsnoAhoy schrieb:> Hallo Denny S.,> ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR> Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum> Ahoy-ESP zu betreiben ?
Eigentlich erstmal nur Testweise. Ich möchte alle Werte aus der Anlage
gerne in ioBroker haben. Das geht mit dem DTU-Lite leider überhaupt
nicht, deshalb hatte ich mir einen DTU-Pro + Energiemesser bestellt
(kommt aber erst Ende Juli).
Dann bin ich auf dieses Projekt gestoßen. Ohne DTU-Lite am Netz könnte
ich eigentlich auf AHOY umstellen, aber dann geht mir aktuell die
Aufbereitung der Daten in der Hoymiles Cloud flöten.
> Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst> ?
Also wenn ich schon so gefragt werde :-)
Was haltet ihr von einer Berechnung der Gesamtwerte der Anlage, also
wenn mehrere WR eingebunden sind und die Daten ebenfalls gleich über
MQTT raus schicken?
Weitere Punkte fallen mir bestimmt noch ein. :-)
Gruß
Dieser Thread ist ja damit gestartet das man versucht die Daten von
Hoymiles auszulesen. Das ist ja eigentlich geschafft und dieser Thread
wird ja mehr und mehr zum Support Thread mit sehr vielen gleichen Fragen
und langer ladezeit.
Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten
gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll
diskussion entstehen?
Ich habe leider keine DTU und kann somit auch keine Daten sniffen. Ich
kann aber programmieren und kann helfen Sachen zu testen.
Wie man ja oben schon sieht, ich bin wirklich an der Limitierung
interessiert.
Danke
Marcel
Hi Marcel,
geht uns doch allen so. :) - Discord Link weiter oben.
Ich probiere viel alleine aus. Aber neue Erkentniss habe ich nicht.
Eine DTU-pro wäre hier Hilfreich.
Gruß Daniel
Marcel A. schrieb:> Dieser Thread ist ja damit gestartet das man versucht die Daten von> Hoymiles auszulesen. Das ist ja eigentlich geschafft
Ist meines Erachtens noch nicht geschafft bzw. nur zum Teil.
Wir bekommen zwar die "Guten Daten" aber nicht die Bösen, sofern ich nix
übersehen habe. Es ist noch gar nix in Richtung Fehler Abfrage
erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source
eine Fehlerliste entdeckt.
> Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten> gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll> diskussion entstehen?
Ich bin sehr dafür. Darum hatte ich ja auch schon für HMT, HMS,
DTU-Pro-S extra Threads angelegt in der Hoffnung, das sich da auch mal
irgendwann jemand einfindet und nicht diesen hier wiederholt kapert. Mit
Discord kann ich nix anfangen. Sagt mir nix. Wenn, dann Bitte hier. Nur
mir fällt kein Name ein.
Vielleicht so?
Protokoll Analyse Hoymiles HM-xxxx, MI-xxxx Bits und Bytes
Und als 1. Beitrag so was in der Art wie ich bei HMT geschrieben habe
evt.
Sinngemäß:
Kein Support für Entwicklungsumgebungen (kann Source nicht übersetzen
usw.)
Kein Support zum Flashen der Mikrokontroller
Kein Support für MQTT Probleme usw.
Dazu bitte den alten Beitrag benutzen:
Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hier soll nur über die Analyse der Bits und Bytes diskutiert werden
Hallo Marcel A. & Herbert K.,
>> Dieser Thread ist ja damit gestartet das man versucht die Daten von>> Hoymiles auszulesen. Das ist ja eigentlich geschafft> Es ist noch gar nix in Richtung Fehler Abfrage
erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source
eine Fehlerliste entdeckt.
Ich finde den Punkt gut hier im ESP evtl. auch die Fehlerliste
abzufragen. Das wäre dann eine neue sendEventLog Routine und dann der
entsprechende Payload Decoder.
Daniel R., hatte ja schon versucht aufgrund der Hoymiles Code Analyse
einige Power Limit Kommandos o.a. an seinen Wechselrichter zu schicken.
Ich habe bei mir irgendwo die vier NRF24 Module verlegt und somit nur
eines am ESP welches ich aber nicht so flexibel einsetzen kann wie das
mit dem Raspberry Pi code von Jan-Jonas geht.
Ich hatte m.W. auch schon weiter oben die verschiedenen SubCmds und
Events aus dem Hoymiles DTU-Pro code (iotloves) extrahiert:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
The current implementation we use for HM-inverters seems to be in the
Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or
`usart_nrf3.h`.
There also the user data starts with `0x80` in `byte[10]` and
after that the Sub Command mentioned in the Excel sheet.
According to the implementation in `usart_nrf3.h` the Sub Command is
defined as `DataType` in `usart_nrf3.h`:
1
typedef enum
2
{
3
InverterDevInform_Simple = 0, // 0x00
4
InverterDevInform_All = 1, // 0x01
5
GridOnProFilePara = 2, // 0x02
6
HardWareConfig = 3, // 0x03
7
SimpleCalibrationPara = 4, // 0x04
8
SystemConfigPara = 5, // 0x05
9
RealTimeRunData_Debug = 11, // 0x0B
10
RealTimeRunData_Reality = 12, // 0x0C
11
RealTimeRunData_A_Phase = 13, // 0x0D
12
RealTimeRunData_B_Phase = 14, // 0x0E
13
RealTimeRunData_C_Phase = 15, // 0x0F
14
//RealTimeRunData_Password = 16, // 0x10
15
AlarmData = 17, // 0x11
16
RecordData = 18, // 0x12
17
InternalData = 19, // 0x13
18
ExternalData = 20, // 0x14
19
} DataType;
Especially the 0x0B rings a bell with me and the traces so far!
According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:
The AlarmDataType can store up to 20 Alerts as far as I could tell from
the `UsartNrf3_Process_DevInform_Alarm` method.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX
Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und
erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL
(REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden
SubCmd's definiert als:
Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum
Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S.
hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw
AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem
Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter
hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert
hatten.
Interessant ist hier vor allem auch der InitDataState 0xff den der
Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
@Daniel R.,
Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
Funktion zu nutzen ?
Ach ja, wir haben auch schon seit längerem zwei Feature Requests im
Github, wenn ihr das lieber nehmen wollt um spezifische
Protokoll-Kommandos im Detail zu besprechen:
Das hier ist m.E. für die Alarm Data / Update Daten:
Use the 0x15 or 0x09 command to query the inverters internal history
#77
https://github.com/grindylow/ahoy/issues/77
und das hier sollte das Power Limit behandeln:
Feature Erweiterung: Leistungslimitierung (für z.B. geregelter
Batteriewechselrichter oder um gesetzliche Grenzen einzuhalten)
#31
https://github.com/grindylow/ahoy/issues/31
Herbert K. schrieb:
> Hier soll nur über die Analyse der Bits und Bytes diskutiert werden
Aus meiner Sicht sollten wir es lassen wie es ist:
1. Auch Fragen außerhalb von Bits und Bytes bringen das Projekt
insgesamt weiter,
2. gelingt eine solche "Sortierung" überhaupt (in den neu angelegten
Threads ist bisher kein weiterer Eintrag),
3. die angesprochenen langen Ladezeiten sind bei Auswahl der
Seitentrennung kein Thema.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang