Mike schrieb: > Ziyat T. schrieb: >> >> Bisherige Erkentnisse vom MI1500, siehe Anhang > > Ich bin der Meinung, das die Werte in der letzten Spalte das > Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der > aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt > (Nur in der Webansicht). Leider nicht, z.Bsp. Zeile 3,Spalte 2, B7(port2) ist nicht belegt, PW=0, Spalte AX 1.18, geht nicht auf Zeile 2,Spalte 2, B8(port2) ist belegt, PW=75.4, Spalte AX 0.01 geht nicht auf
Lukas P. schrieb: > Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle > mich von OTA Update zu Update =) > Das erinnert mit daran in der Konfiguraiton einen Erase Button > einzuführen =) Es gibt z.B. bei ESPEasy Blank-Files - habe Dir mal eines angehängt
Jetzt fällt mir noch was ein in hmRadio.h:83 ist noch immer 'RF24_PA_MAX' definiert, bei mir funktioniert es, evtl. bricht beim ersten Sendeversuch die Spannung ein. Ich habe an den 3.3V einen dicken Elco, man sieht aber trotzdem, dass die LEDs kurz dunkler werden. @Heinz Dein blank.bin sieht aus wie ein frisch gelöschter Speicher, alles 0xFF =). Vielen Dank.
Mit ESP-12e: Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis zum Löschen des EEPROMs, dann schlägt der WDT zu. Gruß... Bert
Bert 0. schrieb: > Mit ESP-12e: > Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis > zum Löschen des EEPROMs, dann schlägt der WDT zu. > > Gruß... Bert Super, danke für den Hinweis, die Fehler sind dann eindeutig in der eep.h und zwar in Zeile 40 und 81 Die For loops werden mit einem 8-bit zähler niemals die 16bit length zählen können -> Endlosschleifen Commit ist gleich unterwegs ;-) Kann bitte einer nochmal kurz die Sonne einschalten zum Testen? :-P
Jop, mit dem letzten Commit startet die Applikation wieder korrekt, Fix reviewed OK! ;-) Gruß... Bert
Ich kann btw. auch bestätigen, dass die Zuordnung auch für den HM-1500 sinn macht: https://github.com/grindylow/ahoy/blob/bf8c1628973eb1dc53b2604b6a7bc1561174f004/tools/esp8266/hmInverters.h#L100 Hab die Zuordnung mit einem meiner Dumps getestet... sieht alles plausibel aus
Gast
#7046268
Die neue Version läuft auf dem Wemos D1! Besten Dank.
Mich@ schrieb: > Die neue Version läuft auf dem Wemos D1! > Besten Dank. Gibt es die evtl. auch als fertig kompiliertes bin?
Ja im Anhang ist die neuste Verison - hat jetzt eine Erase Application data Option - Cmds 0x82 und 0x83 tauchen in Statistik auf
Gast
#7046312
Ich springe auch mal auf den Zug auf ;-) Erstmal ***VIELEN DANK*** an alle Beteiligten!!!! Ich bin noch an den Vorbereitungen, mein HM1200 ist noch nicht geliefert, und ich habe auch noch kein NRF, daher derzeit nur beschränkte Möglichkeiten. Die aktuelle 0.2.6 läuft aber schon mal auf einem Wemos D1 mini (clone) :-) - WIFI-Connection ist ok - Webseite funktioniert - MQTT ist inkl. user/pass eingetragen wird aber als "not connected" angezeigt. Im MQTT-Sniffer sehe ich aber das Topic und den FirmwareRelease. Sonst nichts, es gibt aber ja auch noch keine Daten. Meine Fragen: - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber in (s) Stimmt das? - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein Satzzeichen, ist das ok (erlaubt)? viele Grüße Robert
Hallo, ich bin leider kein C++ Programmierer und habe jetzt einen Status erreicht, wo ich nicht weiter kann. Ich wollte den Code auf ESP32 anpassen und hab auch viele Sachen angepasst, aber jetzt verlangt es langsam bessere C Knowledge. Ich würd mich freuen, wenn jemand da helfen kann ! Ich pack mal das error rein, welches ich bekomme wenn ich kompiliere. Ich nutze auch PlatformIo und habe da die Ordner Struktur angepasst. Zu finden sind die Änderungen in dem Fork in meinem Account: https://github.com/a-marcel/ahoy Ich würde mich freuen, wenn es auch für ESP32 geht, weil der ja mehr Speicher hat es einfacher sein sollte.
Hallo Marcel, finde ich super! Mal ein paar Dinge, die offensichtlich sind. Er findet die Datei "eep.cpp" nicht und er kommt nicht mit den 'Tickern' zurecht. Evtl. benötigt er eine Library / Include dafür. Evtl. tut man sich leichter, wenn man den Code erst mal für den ESP8266 in PlatformIO kompiliert. Robert S. schrieb: > Meine Fragen: > - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber > in (s) > Stimmt das? > - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein > Satzzeichen, > ist das ok (erlaubt)? - Inverval wird korrigiert, ist auch in ms - Das Passwort wird einfach als String (char-array) gespeichert, daher ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen begrenzt und der User auf 16 Zeichen. - der Status des MQTT Brokers war invertiert -> korrigiert
Gast
#7046327
Lukas P. schrieb: > - Inverval wird korrigiert, ist auch in ms > - Das Passwort wird einfach als String (char-array) gespeichert, daher > ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen > begrenzt und der User auf 16 Zeichen. > - der Status des MQTT Brokers war invertiert -> korrigiert Genial, funktioniert! Vielen Dank für den superschnellen Fix! Robert
Gast
#7046340
Heinz R. schrieb: > funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 > flashst? Auch hier kommt der Watchdog (Wemos D1 mini). Auch ein
1 | |
hilft nicht.
Gast
#7046348
Hallo Lukas P., danke für die vielen Commits und Fixes heute abend, nur das mit der Sonne hat nicht mehr gereicht =^D Ich schaue mir morgen bei Tag nochmal die HM-600 Werte an, da hast Du ja zuletzt noch etwas gefixt. Habe gerade nochmal die 0.2.7 geflashed, nach einem mutigen ERASE SETTINGS (not WiFi) kam auch folgender Fehler nicht mehr: 00:25:38.848 -> add inverter: oymiles A, SN: 114173123456, type: 0 00:25:38.848 -> no assignment for type found!add inverter: , SN: 480000000000, type: 3 Irgendwie hat er im EEProm wohl daneben gegriffen und das "H" des ersten WR Namens als SN für einen weiteren Wechselrichter interpretiert. Danke für die Funktion zum beibehalten der SSID und des WiFi Passworts das ist sehr praktisch und hilfreich! Auch die PA_MIN, PA_LOW, PA_HIGH, PA_MAX Einstellung funktioniert jetzt laut Debug Ausgabe: 00:29:55.769 -> add inverter: Hoymiles HM-600, SN: 114173123456, type: 0 00:29:55.802 -> RF24 Amp Pwr: RF24_PA_MAX Wie gesagt Device Name könnte noch mit ESP-<WIFIMAC> vorbelegt sein.
Gast
#7046350
Hallo Heinz R., kannst Du mal zum Flashen den Serial Monitor der Arduino IDE schließen. Ich meine das ist eine häufige Fehlerquelle wenn er die Firmware übertragen will und dabei vorzeitig abbricht. Vielleicht hilft das ja auch in Deinem Fall.
Gast
#7046411
Hallo Heinz R., jetzt habe ich mal den weiter oben genannten Stack Trace von Dir versucht zu analysieren. Schau Dir doch mal bitte folgende Seite an: https://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html Dort wird die Vorgehensweise bei solchen Exceptions Problemen beschrieben. Den ESP Exception Decoder habe ich nach der Anleitung ausgepackt und installiert https://github.com/me-no-dev/EspExceptionDecoder#installation Leider habe ich nicht den zugehörigen Source Code bzw. das ELF Binary um daraus Sinn zu machen bzw. Deinen alten Stack Trace zu analysieren. Mir fehlt auch der Exception Code um das Problem prinzipiell eingrenzen. Ich hatte übrigens gestern abend auch einen Stacktrace gesehen. Nach einigen Restarts geht es jetzt aber sauber, kann es also nicht einfach reproduzieren. Hast Du evtl. einige Clients die auf den ESP per WiFi zugreifen wollen oder wird viel per Serial geloggt ? I.d.R. treten solche WDT Exceptions auf, wenn der ESP seine WiFi Schnittstelle nicht parallel zum Programm bedienen/abarbeiten kann. Vielleicht kann man es ja an der richtigen Stelle mit einem yield() beheben ? Was für Einstellungen hast Du denn für Deinen ESP8266 im Tools Menü gewählt ? Eventuell liegt es ja an etwas einfachem wie der Frequenz, Debug Optionen, o.a.
Guten Morgen, ich weiß nicht, ob ich es schon genannt hatte: die Seriennumer muss jetzt genauso wie sie auf dem WR steht eingetragen werden, ohne ":". Im Anhang noch die Version 0.2.7 und im zip das .elf zum debuggen von Stack-Traces. Mit meinem HM1200 geht die Firmware bei Tageslicht =)
Gast
#7046464
Guten Morgen Lukas P., also ich habe (nach wie vor) seltsame Werte für meinen zweiten Kanal am HM-600 (bisher unbelegt daher vermutlich free-floating): CHANNEL 1 230.40 V U_DC 2.27 A I_DC 804.10 W P_DC 50467.00 Wh YieldDay CHANNEL 2 1557.50 V U_DC 393.21 A I_DC 3932.10 W P_DC 10711.00 Wh YieldDay Die Yield Total und Week sowie AC Werte / Temperatur werden aktuell noch nicht angezeigt bzw. deren u.g. Werte erscheinen mir fraglich. Kann man die rohen Datenpakete wieder ausgeben lassen, das war m.W. dumpBuf o.a. ? Hier mal die Werte aus dem Serial Monitor: 08:42:04.674 -> hm600/ch1/U_DC: 230.400 V 08:42:04.674 -> hm600/ch1/I_DC: 2.300 A 08:42:04.674 -> hm600/ch1/P_DC: 190.600 W 08:42:04.674 -> hm600/ch2/U_DC: 1368.500 08:42:04.674 -> hm600/ch2/I_DC: 393.210 A 08:42:04.707 -> hm600/ch2/P_DC: 3932.100 08:42:04.707 -> hm600/ch0/YieldWeek: 1024.000 08:42:04.707 -> hm600/ch0/YieldTotal: 94.000 Wh 08:42:04.707 -> hm600/ch1/YieldDay: 32133.000 08:42:04.707 -> hm600/ch2/YieldDay: 10985.000 08:42:04.707 -> hm600/ch0/U_AC: 3932.100 08:42:04.707 -> hm600/ch0/Freq: 393.210 H 08:42:04.707 -> hm600/ch0/I_AC: 3932.100 08:42:04.707 -> hm600/ch0/Temp: 2218.900 Wenn dies eine CSV Ausgabe in einer Zeile wäre, dann könnte das der Serial Plotter in der Arduino IDE darstellen: 1U_DC1,1I_DC1,1P_DC1,1U_DC2,1I_DC2,1P_DC2,1YW,1YT,1YD1,1YD2,1U_AC,1Freq, 1I_AC,1Temp: 230.400,2.300,190.600,1368.500,393.210,3932.100,1024.000,94.000,32133.00 0,10985.000,3932.100,393.210,3932.100,2218.900 Am Besten könnte man noch die Spalten auswählen, die per Serial Monitor als "CSV" oder im bisherige "MQTT" Format ausgegeben werden =^D Die Channel Statistik in app.h/.cpp habe ich wieder aktiviert und er schickt bei mir alles auf Kanal 61. Hast Du das Channel Hopping adaptiv angepaßt, d.h. daß es erst bei Fehlern (ACK) den Kanal wechselt ?
Habe hin und wieder Exceptions gesehen, daher die 0.2.8 @isnoAhoy: das channel hopping ist aus (hmRadio.h), bringt bei mir keinen Vorteil Ich würde eher die RAW oder Payload Daten plotten lassen und das dann per Excel auswerten
Gast
#7046473
Hallo Lukas P. habe die dumpBuf Aufrufe in hmRadio.h und app.cpp gefunden und wieder aktiviert. Das wäre als Debug Option im Setup sicher auch noch praktisch! Dazu musste ich die Methode in hmRadio.h vor den private: Bereich verschieben, da sie sonst nicht aus app.ccp aufgerufen werden konnte: declared private! Folgender einfacher Zusatz in dumpBuf() gibt übrigens auch HEX mit führender Null aus, dann klappt es m.E. leichter mit dem Excel Sheet zum dekodieren.
1 | |
An de NRF Spezialisten, Ich sehe diese RAWDaten vom MI1500 neben den "Regulaeren", was könnten sie sein? Kann immer noch den MI1500 nicht ansprechen, Daten bekomme ich nur, wenn die DTU-Pro eingeschaltet ist.
Gast
#7046931
Hallo Ziyat
soviel ich noch von weiter oben weiß benutzt du meine SW.
Dass nur Daten kommen wenn DTU an ist bedeutet für mich, dass die DTU
wohl dem WR einen Anstoß gibt. Weiter oben habe ich auch beschrieben,
dass beim Senden des Zeit-setzen-Pakets mit einem Wert <> 0B hinter dem
0x80 ganz neue Antworten kommen. Also vllt braucht dein MI1500 kein 0B
sondern was anderes.
Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert
buf[10] von 00 bis FF durchlaufen lassen. etwa so:
static uint8_t cid = 0;
int32_t HM_Packets::GetTimePacket(uint8_t *buf, uint32_t wrAdr, uint32_t
dtuAdr) {
prepareBuffer(buf);
buf[0] = 0x15;
copyToBufferBE(&buf[1], wrAdr);
copyToBufferBE(&buf[5], dtuAdr);
buf[9] = 0x80;
buf[10] = cid++; // statt 0x0B
buf[11] = 0x00;
copyToBuffer(&buf[12], unixTimeStamp);
.....
Hast du auch schon die einzelnen Sendestärken durchprobiert?
Gast
#7047063
Hi Lukas, heute ein erster Test mit dem HM-400 und der nun lauffähigen Version. Die Werte sind hier auch merkwürdig: [c]8:05:08.357 -> HM-400/ch1/I_DC: 105.600 A 18:05:08.357 -> HM-400/ch1/P_DC: 4785.400 18:05:08.390 -> HM-400/ch1/YieldTotal: 1056938.3 18:05:08.390 -> HM-400/ch1/YieldDay: 39.321 Wh 18:05:08.390 -> HM-400/ch0/U_AC: 3932.100 18:05:08.390 -> HM-400/ch0/Freq: 473.600 H 18:05:08.390 -> HM-400/ch0/P_AC: 158.300 W 18:05:08.390 -> HM-400/ch0/I_AC: 319.610 A 18:05:08.390 -> HM-400/ch0/Temp: 3932.100[c/] Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich schau mir das mal an... Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe ich da etwas? Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen HM-400 und HM-300 testen.
Gast
#7047084
Hallo Lukas, Die neue Version läuft gut auf dem Wemos. Vielen Dank! Ist es möglich das in den MQTT Einstellungen der Port über das webinterface eingestellt werden kann?
Gast
#7047137
Marcus schrieb: > Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich bin in C nicht so fit, aber wird hier wirklich der richtige Wert extrahiert? Als Beispiel ein CMD82 Paket: &p->packet[0] = 00DE957310xxyy7310xxyy82138600350000000203E8009E000AF1 In app.c übergibst Du das Paket ab Position 11:
1 | |
Damit beginnt es ab dem CMD 82: &p->packet[11] = 82138600350000000203E8009E000AF1 Nun zum addValue Aufruf, welcher hier auf die HM-400 Werte zurück greift:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
=> Value hat damit die Werte aus den Positionen packet[23] und packet[24] (2 Byte), es muss aber die Werte packet[14] und packet[15] haben (das dritte Byte nach dem CMD ist der Start). D.h. start beginnt bei 3 (packet[11] + 3), Länge ist mit 2 korrekt. Oder ich liege völlig falsch?!
Hallo Lukas, habe die neue Version zumindest mal geflasht bekommen und komme auf die Weboberfläche (Ich habe direkt das bin geflasht) Leider erhalte ich aber keine Daten vom WR (Das Setup lief so schon mal mit einer SW von weiter oben) Unten die Ausgabe des seriellen Schnittstelle Ich habe versucht die RF Power von Max niedriger zu stellen - es springt nach dem Speichern leider immer wieder auf Max? Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 erkannt werden? Kleiner Tip noch für zukünftige Versionen: Gib über die serielle Schnittstelle auch die IP-Adresse mit aus, spart langes suchen? Viele Grüße load 0x4010f000, len 3460, room 16 tail 4 chksum 0xcc load 0x3fff20b8, len 40, room 4 tail 4 chksum 0xc9 csum 0xc9 v00057520 ~ld wait for network . add inverter: , SN: 116474903203, type: 1 RF24 Amp Pwr: RF24_PA_MAX Radio Config: SPI Frequency = 10 Mhz Channel = 3 (~ 2403 MHz) RF Data Rate = 250 KBPS RF Power Amplifier = PA_MAX RF Low Noise Amplifier = Enabled CRC Length = Disabled Address Length = 5 bytes Static Payload Length = 32 bytes Auto Retry Delay = 250 microseconds Auto Retry Attempts = 0 maximum Packets lost on current channel = 0 Retry attempts made for last transmission = 15 Multicast = Disabled Custom ACK Payload = Disabled Dynamic Payloads = Disabled Auto Acknowledgment = Disabled Primary Mode = RX TX address = 0xdeadbeef01 pipe 0 (closed) bound = 0xdeadbeef01 pipe 1 ( open ) bound = 0x1234567801 pipe 2 (closed) bound = 0xc3 pipe 3 (closed) bound = 0xc4 pipe 4 (closed) bound = 0xc5 pipe 5 (closed) bound = 0xc6
Marcus schrieb: > Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe > ich da etwas? > > Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus > der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung > ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob > die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen > HM-400 und HM-300 testen. Ja Channel 0 wird noch nicht visualisiert, man kann aber durch ein define auch hier einfach die Liste der Werte ausgeben lassen. Das mit der SN habe ich mit anfangs auch gedacht, aber ich finde das noch nicht endgültig geklärt - jetzt ist es implementiert und würde ich vorerst so lassen. Sind nur 8Bit + alles drin rum ;-) Mich@ schrieb: > Ist es möglich das in den MQTT Einstellungen der Port über das > webinterface eingestellt werden kann? ja das ist möglich, werde ich demnächst einbauen. Heinz R. schrieb: > Ich habe versucht die RF Power von Max niedriger zu stellen - es springt > nach dem Speichern leider immer wieder auf Max? ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert. > Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 > erkannt werden? Habe zufällig so eine Funktion in der Beschreibung der RF24 lib gesehen. Kann ich mal testweise einbauen. > Kleiner Tip noch für zukünftige Versionen: Gib über die serielle > Schnittstelle auch die IP-Adresse mit aus, spart langes suchen? Ja die Rufe werden lauter - wird eingebaut
Lukas P. schrieb: >> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt >> nach dem Speichern leider immer wieder auf Max? > > ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger > alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden > kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert. Hallo Lukas, auch nach einem Reboot oder gar Reset steht RF Power wieder auf High? Ich versuche gerade den Fehler einzugrenzen - evtl. doch Kommunikationsprobleme mit dem NRF24L?
Das kann dann nur an der Speicherroutine liegen. Ich prüfe es bei mir nochmal. Das hat mir dem externen Bauteil nichts zu tun.
Hallo, ich probiere noch immer den Code auf ESP32 zum laufen zu bekommen. Ich würde da Hilfe von einem, der besser CPP coden kann, gebrauchen. Mehrere Ticker in der Form von:
1 | |
compilieren mit folgendem Fehler:
1 | |
2 | |
Auf Stackoverflow habe ich genau diesen Fehler gefunden, wo auch eine Lösung präsentiert wurde. Leider kann ich diese nicht auf den o.g. Code anwenden. https://stackoverflow.com/questions/60985496/arduino-esp8266-esp32-ticker-callback-class-member-function Vielleicht hat ja ein CPP Pro hier eine Antwort für mich. Vielen Dank Marcel
Gast
#7047350
Mal wieder ein paar (Wenigstens für mich) neue Erkenntnisse von meinem HM600, die aber das vermutlich auch das Protokoll im allgemeinen betreffen müssten, und ich glaube, das habe ich hier so noch nicht gelesen. Ich habe versucht, die Zuverlässigkeit des Empfangs der Nachrichtenpakete zu verbessern. Einen letztlich guten Hinweis dazu habe ich in dem DTU log aus Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" gefunden. Ganz allgemein, je nach Anfrage sendet der Inverter verschiedene Nachrichten als Antwort. Meine 'Standard' Anfrage basiert auf der GetTimePacket Nachricht, die auch in dem DTU log enthalten ist. Darauf hin kommen die Antworten 0x01, 0x02, und 0x83 zurück. Für die Antworten spielt es offensichtlich keine Rolle, ob das Byte 19 0 oder 5 ist (die Anfragen der DTU logs haben 0, daher habe ich das mal versucht - wie gesagt ohne wirklichen Unterschied). Beim Anschauen der DTU logs habe ich auch eine Anfrage gesehen, die im Byte 10 statt 0x0B eine 0x11 hat. Wenn ich das an den HM600 sende, bekomme ich (nach anpassen des Rx channel scans) zuverlässig die Antworten 0x01, 0x02, ... 0x0B, 0x8C. Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* Nachrichten das letzte Antwortpaket markieren. Das diese oft nicht so oft empfangen werden könnte Dara liegen, dass alle Nachrichten auf einem Kanal erwartet werden. Das ist aber nicht der Fall - dazu später mehr. Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das Anfordern eines nicht erhaltenen Pakets. Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. Das habe ich heute so erfolgreich getestet:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Wie man sehen kann, fehlt die erste Antwort. Diese frage ich dann noch einmal dediziert an, und habe dann alle Pakete (Anfrage ist immer auf Kanal 40, hier alle Antworten auf Kanal 75). Das erklärt dann eventuell auch, warum AutoAck nicht verwendet wird; has hat mich bei der Suche nach einem Schema für den Kanalwechsel immer wieder etwas verwirrt. Ich dachte eigentlich, dass das Fehlen von Nachrichten an meinem 'simplen' Kanal-Scannen liegt, aber in DTU log kann man diese erneute Anfrage ebenfalls schön sehen. Könnte also ein Hinweis darauf sein, dass es keine feste Synchronisation der Kanalwechsel gibt, und daher Paketverluste 'eingeplant' sind. Durch die 'vielen' Antworten auf die '11er' Anfrage habe ich dann auch gesehen, dass ich meine channel List anpassen musste. Mit
1 | |
und dem Re-transmit request bekomme ich bei mir jetzt ganz gut alle 15 Sekunden ein komplettes Datenpaket zusammen. Meine Logik ist noch nicht ganz ausgereift, so dass ich im Moment nur ein fehlendes Paket neu anfordere, aber es gibt auch mal keine Antwort, oder nur eine. Heute ist die Sonne wieder zu früh untergegangen, aber es sieht so aus, dass die Kanäle in einem festen Schema von oben nach unten gewechselt werden (da ich nicht weiß, was in den Nachrichten ist, habe ich die mal abgekürzt):
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Wie man an den unterschiedlichen Abständen sehen kann, fehlt noch eine 'korrekte' Synchronisation (im Moment mache ich das Timing basierend auf meinem Senden), aber es ist erstaunlich, wie gut das im Vergleich zu vorher zu funktionieren scheint.
Version 0.2.9 ist da! Changelog: - added: IP Adresse wird auf Serieller Console ausgegeben, wenn erfolgreich mit WLAN verbunden - fix: RF24 Konfiguration des Power Amplifiers - added: RF24 Verbindung wird geprüft; prüft nur, ob SPI erreichbar, wenn kein Power an RF24 Modul ist, bleibt der ganze ESP hängen (ohne Serielle Ausgabe) - added: MQTT port Konfiguration - fix: offsets für HM400 und HM600 Wechselrichter, diese sollten jetzt korrekte Werte anzeigen. Bitte um Feedback - added: Warnung, wenn die Konfiguration geändert wurde, ohne neu zu booten auf der index.html Viel Spaß damit =)
lpb schrieb: > Ich habe versucht, die Zuverlässigkeit des Empfangs der > Nachrichtenpakete zu verbessern. Hallo lpb, genial, dass du weiter auf diesem Gebiet forschst! Ich finde das super, dass sich so die Kompetenzen der einzelnen ergänzen. Wenn man statisch auf Kanal 40 das 'Zeit-setzen' schickt und nur auf Kanal 3 horcht, bekommt man sehr unzuverlässig Pakete rein. Verstehe ich das richtig, man sendet in Byte 10 eine 0x11 statt 0x0b und bekommmt dadurch viele neue Cmds in den Antworten. das erinnert bisschen an das was @Hubi schon mal kurz angesprochen hatte: Hubi (Gast) schrieb: > Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal gelesen zu haben. Auf eine Anfrage hin kommen dann viele Antworten und zuletzt ein 0x83? Wie bekommt man die Zuordnung von Kanal und CMD in der Antwort? Ich muss ja dann vorher wissen wo die nächste Antwort kommt. Bin gespannt wie es hier weitergeht.
Gast
#7047639
Die Werte für den HM-400 stimmen nun:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Ein paar Kleinigkeiten waren zu korrigieren (siehe app.cpp und hmInverters.h in https://github.com/dad401/ahoy/tree/main/tools/esp8266) - das h von kWh und das C von °C wird abgeschnitten => meine Änderungen scheinen da aber doch nicht zu helfen, bitte mal prüfen - YieldDay korrigiert - es wird nun wie bei HM-600 Wattstunden angezeigt (möchte nicht ständig im Thread das übermitteln - ich kann aber leider auch keinen zweiten Fork auf Lukas-Fork erstellen, daher PR auf das Haupt-Repo) P.S. ggü. Hubis NRF24 Receiver empfängt die aktuelle Version aber irgendwie schlechter. Es dauert mehrere Minuten bis etwas ankommt - früher kamen Pakete sofort nach dem Start?!
Hallo Marcus, den PR hast du garnicht durchgeführt oder? Lt. dieser Anleitung solltest du den auch meinem Repo zuweisen können: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork Yield total sollte doch in kWh sein oder, daher war der Teiler 1000. In Wh ist es sehr bald eine unnötig große Zahl. Bzgl. der Empfang: versuche mal in hmRadio.h den Channel-Hop (define) wieder zu aktivieren, evlt. geht es dann wieder besser.
Gast
#7047778
Habe noch keinen PR gemacht, weil die Änderungen in der app.cpp nicht funktionieren. Ich teste das mal, ob ich Dein Repo hier verbinden kann - bin da zu unerfahren mit GIT da ich nur gelegentlich damit zu habe. Yield total stimmt. Aber das h wird hinten bei der Ausgabe abgeschnitten. Yield daily wird derzeit beim 400er in kWh ausgegeben, aber als Einheit ist Wh angezeigt - das habe ich korrigiert. Wenn Du aber eh 3 Nachkommastellen ausgibst, könnte man YD auch generell auf kWh setzen. Ist aber alles Geschmackssache - Hauptsache einheitlich :-) Ich probiere das mal mit dem Channelhopping. War das früher aktiv? Mit der ersten Version nach Behebung des Watchdog-Crashes ging es m.E. sehr gut. Jetzt dauert es 10min bis erste Pakete empfangen werden.
Bei mir liegt es stark an der Ausrichtung der Antenne, sie muss bei mir mit der abstrahlenden Seite Richtung WR zeigen. Das ist bei mir noch sehr empfindlich, daher finde ich es super, dass sich hier auch welche um besseren Empfang kümmern.
Gast
#7047819
lpb schrieb: > Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* > Nachrichten das letzte Antwortpaket markieren Hallo lpb, diese Vermutung hatte ich auch schon, nachdem ich meine Messungen an der seriellen Schnittstelle hier gepostet hatte (siehe auch Bild): Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Aber die Erkenntnis mit dem Retransmit eines speziellen Pakets ist natürlich sehr nützlich. Ich hatte hier im Thread schon mal darauf hingewiesen, dass es einen Unterschied in der Antwort des Wechselrichters macht, welche Anfrage vorausging. Das dürfte vielleicht die ein oder anderen "seltsamen" Werte bei manchen hier erklären. Die 0x80 0x11 Anfrage liefert andere Antwortpakete als die 0x80 0x0B Anfrage, obwohl sie den gleichen Index haben (siehe Bild). Leider habe ich auch keine Ahnung, wie man das empfangene Paket plausibilisieren könnte. Evtl. lohnt es sich, das Channel Hopping systematischer zu untersuchen, um die komplette Antwortsequenz in einer gewissen Zeit zu erhalten. Bald sind meine Module auf dem Dach montiert, dann kann ich auch wieder hier mitmischen...
Angehängte Dateien:
-
hm_600_comm.png
(110 KB)
Gast
#7047834
martin schrieb: > Evtl. lohnt es sich, das Channel Hopping > systematischer zu untersuchen, um die komplette Antwortsequenz in einer > gewissen Zeit zu erhalten. Vielleicht ist die Messung von B.G. ja schon ein entscheidender Hinweis: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Es scheint eine Systematik in den Kanalwechseln zu geben, nämlich "von oben nach unten": Kommt Paket 1 auf Kanal 40, dann wird auf 23 weitergehorcht. Kommt dort 02,83 ist es Antwort auf 0x80 0x0B, kommt 02,03,04 wird auf Kanal 3 weitergehorcht, bis 85 kommt. Dann ist es die Antwort auf 0x80 0x11 (?)
Hubi schrieb: > Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert > buf[10] von 00 bis FF durchlaufen lassen. etwa so: Hallo Hubi Danke für den Vorschlag, hatte auch mal so durchlaufen lassen wie du vorgeschlagen hast, ohne Erfolg. Bisher habe ich alle Kombinationen MID/CMD/CID durchprobiert. Ich denke die MI-Series braucht was ganz anderes, denn die Antworten sind auch ganz anders, bei den MI-Antworten gibts keine regelmaessige SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. Ich muss die DTU-Pro sniffen aber, vorerst bin ich mit meinen Möglichkeiten am Ende. Ehrlich gesagt ich kann es auch fast nicht glauben, dass die Chinesen für die HM'S vollig etwas anderes erfunden haben.. Andere Signalstaerken hab nicht probiert, es steht auf PA_MAX, hab einen NRF mit Antenne und WR ist etwa 7m weit, ich denke, was ich sende kommt an.
Gast
#7047913
Ziyat T. schrieb: > SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. Achtung, das waren die seriellen Daten INNERHALB der DTU! 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den Adressen.
martin schrieb: > Ziyat T. schrieb: >> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. > > Achtung, das waren die seriellen Daten INNERHALB der DTU! > 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht > zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den > Adressen. Sorry, richtig!
Gast
#7048083
Ich habe Hubis Code ebenfalls mal eingecheckt. Hoffe es verwirrt nicht, denn es gibt noch einen weiteren Code unter "Nano" - der ist m.E. aber etwas anderes?!
Gast
#7048113
Hallo Leute, Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein stärkeres Netzteil habe ich bereits getestet… Ansonsten läuft die neue Version gut. Die Daten meines HM350 sehen plausibel aus. Auch die Abfrage per MQTT läuft.
Ich habe gleiches beobachtet, habe einfach den USB Stecker vom Laptop in ein USB-Netzteil gesteckt und auch Abstürze gesehen, auch ca. 15-20 Minuten geschätzt. Noch habe ich keine Idee woran es liegen könnte. MQTT war bei mir auch an. Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.
Hallo, sagt mal, gibt es irgendeine Möglichkeit die Core Funktionen in eine Library auszugliedern? Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder andere NTP/WiFi implementierungen. Das wäre wirklich von Vorteil ggf. für mehrere Personen. Vielen Dank für all eure Arbeit Marcel
Hallo Marcel, das ist doch im Prinzip jetzt schon so. Ich habe alles so angelegt, damit es möglichst unabhängig vom ESP8266 ist. Im wesentlichen sind hierfür die Dateien 'hmSystem.h', 'hmRadio.h', 'hmInverters.h' und 'CircularBuffer.h' notwendig. Evtl. ist noch das eine oder andere #define aus 'defines.h' nötig. Die 'Library' wird dann ungefähr so aufgerufen (kopiert aus app.h):
1 | |
2 | |
3 | |
4 | |
5 | |
aus deiner .ino setup() musst du noch diese Routine aufrufen
1 | |
jetzt kannst du mit dem Objekt sys alles anstellen, z.B. einen Inverter hinzufügen:
1 | |
danach muss man sich noch überlegen, was man alles in der loop() machen will, hierfür einfach in der app.cpp schauen.
Okay super. Schaue ich mir mal an. Danke. Marcel
Gast
#7048320
Mich@ schrieb: > Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der > Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles > perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er > nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht > mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein > stärkeres Netzteil habe ich bereits getestet… Ich habe hier einen Wemos D1 clone mit der 2.9er im Testbetrieb an einer Powerbank. Er läuft jetzt seit mehr als 3h 30min, das Webinterface ist erreichbar, die Zeit und Uptime zählen hoch. Unterschied, er läuft ohne NRF-Board (wird erst geliefert) und bekommt daher auch keine Daten. Vielleicht hilft das ja bei der Fehlersuche. SG Robert
Gast
#7048322
Hallo Marcel, schau Dir doch mal die folgenden beiden ebenfalls passenden SE&SO Artikel an: [1] https://arduino.stackexchange.com/questions/76138/error-in-defining-ticker-in-esp32-library [2] https://stackoverflow.com/questions/53091205/how-to-use-non-static-member-functions-as-callback-in-c Ich habe versucht an der Stelle etwas Neues zu lernen, offenbar muß ich dazu auch noch Einiges mehr [TM] verstehen... Das Beispiel im ersten u.a. Link fand ich dazu für mich etwas klarer, da es eine ESP8266 Vorlage und ein ESP32 Ergebnis gibt. Die beiden Funktionen sendTicker und mqttTicker muss man m.E. in der app.h als public deklarieren.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
Analog dazu sollte es auch in der main.cpp/.h möglich sein Interessant fand ich, daß der Umbau für den ESP32 dann auch unter ESP8266 funktionieren soll. Es sind also offenbar keine extra #if defined (ARDUINO_ARCH_ESP8266) #elif defined(ESP32) Blöcke für die Ticker notwendig. Für die Bibliotheken die unter ESP8266 i.d.R. auch dies als Präfix haben und die ESP32 Varianten ohne dieses Präfix hast Du m.W. ja schon die entsprechenden konditionalen include's eingepflegt.
Guten Morgen ! Ist schon jemand dahinter gekommen, was für eine Bedeutung die "81" er Telegramme vom HM350 / HM400 haben ? 005E ... 14 79 CF 005C ... 14 7F 25 0058 ... 14 72 F1 00 1234567801 005E 0B 3 95 [WR] [WR] 811479CF 1 00 1234567801 005C 0B 2 95 [WR] [WR] 81147F25 1 00 1234567801 0058 0B 0 95 [WR] [WR] 811472F1 1 00 1234567801 005E 0B 3 95 [WR] [WR] 811479CF 1 00 1234567801 005C 0B 2 95 [WR] [WR] 81147F25 1 00 1234567801 0058 0B 0 95 [WR] [WR] 811472F1 1
Hi Lukas und alle dies es interessiert,
erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr
gut lesbar.
Nach ersten Tests auf einem klassischen Arduino bin ich nun auf ein
ESP8266 Modul umgestiegen.
Man braucht für den Code wirklich aktuelle Tools zum compileren, da wohl
erst vor gar nicht langer Zeit die String-Conversion von uint64_t
eingebaut wurde. Bei schickte das die Umsetzung der Seriennummern in
eine Byte-Wurscht auf die Bretter... ;-)
Danach übersetzte das Ganze aber klaglos und lief auch auf Anhieb.
Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich
musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom
"Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC
Leistung. Also habe ich Zeile
{ FLD_IAC, UNIT_A, CH0, CMD02, 15, 2, 10 },
gegen
{ FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 },
getauscht. - Jetzt passt es.
Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
{ FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 },
=> Kann das bitte mal jemand mit einem HM600 checken, ob das beim HM600
auch so ist? - Sonst müsste man die HM600/700 Werte defines
separieren...
Die Visualisierung habe ich für mich noch auf die Schnelle um die
AC-Werte erweitert. - Siehe Screenshot. :-)
Ein Issue habe ich noch:
=> Ich habe ab und zu (gemittelt alle 10-20 Minuten) Stacktraces, also
Abstürze mit Exception 0. Meist im Zusammenhang mit der ISR für den
externen Interrupt und gleichzeitigem Bedienen des WLAN-TX.
=> Das Modul startet dann korrekt neu, bekommt aber keine IP-Adresse
zugewiesen (IP unset). Ein Reset behebt das aber (temporär).
Ich beobachte das weiter und prüfe heute noch, ob es ein HW-Thema
(Spannungseinbrüche o.ä.) ist oder eher nicht.
Cheers,
Lars
Angehängte Dateien:
-
ahoyb.jpg
(33 KB)
Gast
#7048605
Hallo zusammen Im Anhang meine neueste Version, da ich gesehen habe, dass doch einige diese ausprobieren. Kommentare dazu: - Projekt jetzt umgenannt in HoyDtuSim (Hoymiles DTU Simulation) -Läuft auf Arduino (bei mir auf Pro Mini) und ESP (Wemos D1 mini), je nachdem wie man kompiliert - Channel hopping für senden und Empfangen (poor man's ...) ist eingebaut und bringt konstante Antworten; obige Erkenntnisse über Kanäle abwärts sind noch nicht eingebaut - da manchmal ein Abbruch der RF-Verbindung vorkam (auch schon oben erwähnt) wird jetzt nach ca 50 Sekunden ohne Empfang das RF-Modul neu initialisiert und es geht problemlos weiter - Definitionen für HM-600 und HM-1200 sind implementiert, andere können anhand der beiden Beispiele sicher leicht impl. werden - Anpassungen sind in der Settings.h zu machen Marcus hat in das lumapu-Repo meine Version vom 13.04. eingecheckt. Wäre nett wenn er dies durch diese hier ersetzen würde. Wenn ich Zugang zu diesem Branch hätte und wenn ich wüßte wie das geht würde ich das auch selbst machen. Aber ich kann neue Versionen auch an Lukas P. (lumapu) per Mail schicken. @Herbert: Die 81er habe ich auch dauernd, besonders 8114. Fehlermeldung?
Gast
#7048657
Beim compilieren mit der aktuelle IDE und aktuellen Bibliotheken kommt folgende Fehlermeldung: app.cpp:58:95: error: call of overloaded 'String(uint64_t&, int)' is ambiguous Liegt das an der fehlenden Seriennummer die ich noch nicht eingetragen habe, weil ich nicht weiß wo? Sorry für die Anfängerfragen. Danke
Gast
#7048792
Hallo Sorbit für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das aber keinen Fehler werfen. Wenn du die Serial ausgeben willst, kannst du das so machen
1 | |
Gast
#7048830
Marcel A. schrieb: > Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch > auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder > andere NTP/WiFi implementierungen. Ich bastel gerade an einer Testversion für Tasmota - muss mir aber immer recht viel zusammensuchen, da ich nicht so tief drin stecke im Programmieren wie z.B. Lukas. Die Integration kompiliert inzwischen - einiges musste ich anpassen, konnte aber viele der Dateien von Lukas weiterverwenden. Ob es auch läuft konnte ich noch nicht testen. Kann das gerne in mein GIT einstellen ([[https://github.com/dad401/Tasmota]] Tasmota-Fork) - ist aber sicher noch nicht so toll der Code. Learning by Doing auch was GIT betrifft. @all: Wie plausibel haltet ihr die Werte für P_AC und Power total/daily => sind das die Werte, welcher ein Wechselstromzähler messen sollte oder könnte das ggf. doch (tlw.) Werte für DC sein? Wenn das passt, dann kann man damit auch z.B. einen SonOff besser kalibrieren. Dieser weicht derzeit nur wenige kWh von der Tagesproduktion ab.
Gast
#7048839
Lukas P. schrieb: > Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann > können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen. Ich glaube Du musst da "Discussions" in den "Settings" anwählen - in Deinem GIT habe ich irgendwie (ohne PR) keine Möglichkeit gefunden zum Austausch.
Gast
#7048867
Hubi schrieb: > Wäre > nett wenn er dies durch diese hier ersetzen würde. Ist bei mir drin und PR für das Hauptrepo angefordert. Mit einen GIT Account könntest Du das auch selbst. Ich kann Dir die Schritte, wenn Du den Account hast gerne sagen (so wie ich es mache/gelesen habe). Am besten aber dann hier [[Du bräuchtest einen git Account]] sonst sprengen wir die Server von mikrokontroller.net ;-)
Gast
#7048869
Marcus schrieb: > Am besten aber dann hier [[Du bräuchtest einen git > Account]] [[https://github.com/dad401/ahoy/discussions]]
Gast
#7048949
So, ich habe mir einen Git account zugelegt und meine SW dort mal reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation. Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, bitte gerne.
Gast
#7048989
Hubi schrieb: > So, ich habe mir einen Git account zugelegt und meine SW dort mal > reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation. > Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt > geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, > bitte gerne. Das ist nun die Frage - belassen wir alles im Haupt-Repo [[https://github.com/grindylow/ahoy]] oder führt jeder Entwickler sein eigenes? Ich kann diese Frage nicht beantworten. Man könnte es ja so machen: Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). Aber das müsst ihr wissen. Mir wird nur etwas schwindlig wenn man immer alles zwischen den Forks synct ;) Für mich wäre es einfacher wenn ich als Nutzer Hubis-Repo und Lukas-Repo bei mir forken kann und dort Änderungen per PR einbringen kann. Derzeit ist das irgendwie über zwei Ecken. <just my 2 cents> Marcus
Hallo Marcus, wir sollten bei dem Hauptrepository bleiben, aber evtl. kannst du mich als 'Colloborator' hinzufügen, dann kann ich direkt die Pull-Request managen - denke ich (ich hab leider auch keine Github Erfahrung) Repository -> Settings -> Colloborators
Gast
#7049184
Hallo Lukas Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann meine weitere Entwicklung per Mail zukommen lassen. Bin auch der Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und wird dann unübersichtlich. Bin da offen. Deine wirklich sehr gute OOP Entwicklung wäre schon wert unterstützt zu werden.
Gast
#7049193
Hubi schrieb: > Hallo Sorbit > für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das > aber keinen Fehler werfen. > Wenn du die Serial ausgeben willst, kannst du das so machen1 > sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned > long)(serial&0xFFFFFFFFULL)); Hallo Ahoi, Hubi, oder wer auch immer dahinter steckt😄 Im Git Repository steht doch geschrieben, das der Code für Arduino mit ESP8266 als Taget gedacht ist. Dann sollte der Compiler doch sauber durchlaufen. Ich verstehe den Zusammenhang nicht. Kann mir jemand auf die Sprünge helfen? Danke
Ich lade gerne "Collaborators" in das AHOY Repository ein. Schreibt doch hier im Thread kurz Eure Github-Namen und Euren Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als Collaborators hinzu. Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich hier im Forum in der Minderheit!), aber ich stimme Marcus und den anderen zu, dass es insbesondere für Nutzer hilfreich ist, wenn die Entwicklung nicht an zu vielen unterschiedlichen Forks läuft. Gruß Martin (petersilie) / https://github.com/grindylow/ahoy ps. Habe gerade mal das Haupt-README mit direkten Verweisen auf die Unterprojekte aktualisiert. Für die Übersicht wäre es super, wenn jeder Autor für "sein" Tool ein kleines README hinzufügen könnte. Dann finden sich auch Fremde schnell zurecht. Als Beispiel/Vorlage kann z.B. https://github.com/grindylow/ahoy/tree/main/tools/rpi dienen.
Hallo Martin,
> Mein Interesse ist immer noch eher auf der Raspi-Version
Schön! Ich halte zumindest davon auch noch am meisten, was das effektive
Entwickeln angeht, wenn auch der Ressourceneinsatz etwa bei einem ESP32
deutlichst kleiner ausfällt, wenn er dann einmal als Webserver läuft.
Übrigens habe ich heute meinen NRF24_Sniffer zugeschickt bekommen und
werde wohl in den nächsten Tagen das Dingens mal aktivieren. Wenn's dann
klappt, hoffe ich, was zum HM-1500 beitragen zu können. Wobei ich hoffe,
weitestgehend die Auslesung des HM-1200 übernehmen zu können. ;-)
Tschüssi,
Petra
Gast
#7049244
Hallo Sorbit mit der Arduino IDE und Einstellung Lolin(Wemos) D1 R2 & mini lässt sich zB ein
1 | |
ohne Fehler kompilieren. Ich benutze die IDE 1.8.13, nicht die neueste.
Martin G. schrieb: > Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich > hier im Forum in der Minderheit!), welche Vorteile versprichst Du Dir davon? Denke man sollte es möglichst einfach halten - und möglichst einfach ist halt der ESP8266
Gast
#7049293
Nachdem ich bisher nur stiller Mitleser war, hier mein erster Beitrag. Sehr cool, was ihr hier schon gemeinsam geschafft habt! :-) Heinz R. schrieb: > welche Vorteile versprichst Du Dir davon? > Denke man sollte es möglichst einfach halten - und möglichst einfach ist > halt der ESP8266 Der ESP ist sicherlich ein guter Start, universell und aus meiner Sicht eine schöne Plattform. Ich persönlich würde es auf Dauer aber auch bevorzugen, wenn das System auf einem bestehenden Raspberry untergebracht werden könnte und ich keine zusätzliche Hardware dafür laufen lassen muss. Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell ablesbar zu machen.
Heinz R. schrieb: > welche Vorteile versprichst Du Dir davon? > Denke man sollte es möglichst einfach halten - und möglichst einfach ist > halt der ESP8266 Der ESP8266/ESP32 ist sicher eine tolle Sache. Ich habe persönlich nicht primär das Nachbauen einer "DTU" im Kopf, sondern die Integration der Hoymiles-Wechselrichter in ein größeres Ökosystem. Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den Wechselrichtern einfach noch mitmachen lassen. Webinterface/Archivierung etc ist dann nicht Aufgabe der Hoymiles-Anbindung, sondern des übergeordneten Systems. Vielleicht ein bisschen wie die "DTU-Pro"-Anbindung via Modbus (wobei die DTU-Pro ja wohl auch ein Webinterface etc etc bietet). Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit NRF24 als auch mit Wifi auf 2.4 GHz. Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf. Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. Das sind alles absolut gute Wege, und jede Alternative trägt ein bisschen zum Erkenntnisgewinn bei. Ich finde es prima, wie wir alle unsere Erfahrungen mit dem Protokoll zusammensammeln!
> Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display > zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell > ablesbar zu machen. Jenau, man schaue z.B. unter https://tutorials-raspberrypi.de/esp8266-grafikdisplay-ssd1306-oled-bilder-text-anzeigen/ Wobei ich eher zum esp32 tendiere, weil der wohl bei minimalem Aufpreis etwas besser ausgestattet ist? Tschüssi, Petra
> Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier > eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit > NRF24 als auch mit Wifi auf 2.4 GHz. Scho'recht, allerdings ist die Frage, wie stark die Hoymiles-Abfragerei das WLAN belastet. Ich möchte auch mal hinterfragen, ob es einen Sinn macht, sekündlich Werte abzufragen? Ich denke, wenn man alle 30 s einen Wertesatz holt, wird sich die Statistik nur sehr unwesentlich verschlechtern. > Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" > experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf. Das auf jeden Fall - das ist auch bei mir der Antrieb, damit anzufangen, um ... > Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. ... später, wenn alles so weit ausexperimentiert ist und nur noch gelegentlich mal nach dem Zustand geschaut wird, so was als Standardanzeige zu etablieren. Zumindest fände ich es nett, hier eine Low-Power-Alternative zur Verfügung zu haben. ;-) Tschüssi, Petra
Gast
#7049434
Lukas P. schrieb: > aber evtl. kannst du mich > als 'Colloborator' hinzufügen Das wäre dann aber petersilie - das Hauptrepo ist seins, hat er aber darunter bereits geschrieben: Martin G schrieb: > Ich lade gerne "Collaborators" in das AHOY Repository ein. > Schreibt doch hier im Thread kurz Eure Github-Namen und Euren > Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als > Collaborators hinzu. Mein GIT: [[https://github.com/dad401]] Fokus: Nutzertests mit HM-400 (und HM-300), ggf. Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren Programmierkenntnissen beteiligt. Martin G schrieb: > Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man > durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den > Wechselrichtern einfach noch mitmachen lassen. Ich finde es gut, dass es auch diese Alternative gibt, denn auch ich würde mir ggf. ein zusätzliches Gerät sparen. Ich habe inzw. alles kompiliert/konfiguriert, aber bekomme es noch nicht zum Laufen. Benötige ich da zwingend den MQTT-Server? Ich muss das nochmal genauer prüfen. Einzig nachteilig (IMHO) ist leider das "Gefummel" (kompilieren statt einfach per apt installieren) mit den Bibliotheken. Solang das alles fehlerfrei klappt ist gut, aber wer weiß was mit dem nächsten RPi-Update passiert. Petra R. schrieb: > Ich möchte auch mal hinterfragen, ob es einen Sinn > macht, sekündlich Werte abzufragen? Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools berücksichtigt werden. Ich denke dies ist immer noch des ersten funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer stabil kommen. Ggf. macht man das Abfrageinterval einstellbar. Meine RRD-Datenbank befülle ich (von einem SonOff Pow R2) jede Minute. Wenn also stabil bei einer Abfrage eine Antwort kommt, dann reichen sicher 30s Intervall aus.
Marcus schrieb: > Hubi schrieb: > Man könnte es ja so machen: > Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software > lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). > Diesen Weg sollten wir gehen, denn es gibt noch viele ungelöste Dinge! IMHO, es sollten unbedingt alle Infos Zentral sein. Ich habe das Gefühl, dass bisher "nur" ein Paar WR Daten (und diese nur von HM's!) sichtbar sind, und schon wird hier über HW-Plattform diskutiert;-)
Gast
#7049869
Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente. Hier eine weitere HM-300 Seriennummer: 11216281xxyy Also ich leg mich fest, die HM-3xx und HM-400er beginnen mit immer 1121 ;)
Gast
#7050002
Vorweg: Super Arbeit - vielen Dank! Die ESP8266 Version funktioniert mit einem HM-800 (114174...) Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc erwähnten Installation der Library "PubSubClient"):
1 | |
2 | |
In der kurzen Testphase kam es zu Hängern - ich vermute einen Zusammenhang mit geöffnetem Webinterface. lg
st_b schrieb: > Die ESP8266 Version funktioniert mit einem HM-800 (114174...) > Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc > erwähnten Installation der Library "PubSubClient"): Hallo st_b , auf welcher Definition basiert deine Änderung, auf der vom HM600? Doku werde ich nachziehen, danke für den Hinweis.
Hubi schrieb: > Hallo Lukas > Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie > bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann > meine weitere Entwicklung per Mail zukommen lassen. Bin auch der > Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und > wird dann unübersichtlich. Bin da offen. Hallo Hubi, das liegt bei dir, ich finde es nicht falsch wenn du einen Git Account hast und direkt Änderungen per pull request einfließen lässt. Per Mail geht auch, dann checke ich es ein. Deine wirklich sehr gute OOP > Entwicklung wäre schon wert unterstützt zu werden. Vielen Dank für die Blumen ;-)
Lars B. schrieb: > erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr > gut lesbar. Das ist mein Ziel: so wenig wie möglich kommentieren, lieber sprechen Code schreiben. Ist nicht immer ganz einfach, aber so bleibt das gesamte auch über Monate wartbar. > Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich > musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom > "Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC > Leistung. Also habe ich Zeile > { FLD_IAC, UNIT_A, CH0, CMD02, 15, 2, 10 }, > gegen > { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, > getauscht. - Jetzt passt es. > > Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden: > { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 }, Ich kann leider nicht nachvollziehen, ob diese Änderungen bereits per PR in das repo gekommen sind, falls nicht bitte noch anlegen. > Die Visualisierung habe ich für mich noch auf die Schnelle um die > AC-Werte erweitert. - Siehe Screenshot. :-) Auch hier freue ich mich über einen PR in Git.
Gast
#7050074
Lukas P. schrieb: > st_b schrieb: >> Die ESP8266 Version funktioniert mit einem HM-800 (114174...) >> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc >> erwähnten Installation der Library "PubSubClient"): > > Hallo st_b , > auf welcher Definition basiert deine Änderung, auf der vom HM600? > Doku werde ich nachziehen, danke für den Hinweis. Ich habe die Definition des HM-600 angepasst. Vollständigkeitshalber sei erwähnt, dass die Werte ursprünglich von Lars B. stammen)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
Gast
#7050361
Hallo Marcus,
> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.
ich habe die Statistik der Seriennummern noch einmal sauber aufgeräumt
und nach Seriennummer sortiert.
Wenn Ihr wollt, könnt Ihr die gerne einchecken, ich habe die auch nur
weitergeführt.
Ich habe jetzt auch die Usernamen aus dem Forum ergänzt um zu sehen, von
wem evtl. noch eine führende Ziffer zu bekommen wäre:
Arnaldo G. (arnaldo_g), martin (Gast), Oliver F. (of22), heijz, Carsten
B. (carstenb) könntet Ihr eventuell hier im Forum oder direkt in der
Tabelle Eure führenden Ziffern bzw. die Serien-/Modellnummer Eures
Wechselrichters / DTU Modells ergänzen ?
Auch die ForistInnen mit einem MI- Wechselrichter der älteren Bauart
müssten ggf. Ihre Seriennummern beisteuern, da hiervon außer dem TSUN
TSOL-M800 von Daniel M. (Gast) noch keine hier bekanntgegeben wurde.
Gast
#7050369
Hier eine auf die ersten vier Stellen gekürzte Liste aus dem Excel, das ich letzte Woche aktualisiert habe:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
Wie man sehen kann sind die Seriennummern nicht ganz eindeutig. Aber es sollte von der Zahl der Anschlüsse bzw. MPPT die im Wechselrichter verbaut sind eigentlich hinkommen, daß alle mit der selben Seriennummer zumindest einen ähnlichen inneren Aufbau haben sollten. Lediglich die maximale Leistung der Kanäle scheint sie noch zu unterscheiden. Ich habe auch mal die Seriennummern der DTUs und unseres Exoten TSUN "TSOL-M800" aufgenommen.
Marcus schrieb: >> Ich lade gerne "Collaborators" in das AHOY Repository ein. >> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren >> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als >> Collaborators hinzu. > > Mein GIT: [[https://github.com/dad401]] > > Fokus: Nutzertests mit HM-400 (und HM-300), ggf. > Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste > Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht > commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren > Programmierkenntnissen beteiligt. Einladung ist erfolgt! > Man könnte es ja so machen: > Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software > lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). Das könnten wir auch gerne so halten. Ich habe leider ein bisschen den Überblick verloren, wer an welchem Teilprojekt in welcher Repo am aktivsten ist. Gerne kann ich in der Haupt-Repo im README auf die jeweiligen anderen Repos verweisen, und dann im Laufe der Zeit auch die (dann veralteten) Unterverzeichnisse entfernen. Am besten würde ich dann auch die jeweiligen Autoren mit auflisten, oder? Persönlich fände ich es gut, wenn wir die Doku (https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) im Hauptrepo (https://github.com/grindylow/ahoy) pflegen würden. Die können wir dann gerne auch versuchen, auszubauen und evtl. auf readthedocs.io o.ä. zu hosten. Mir fehlt nur gerade ein bisschen die Zeit - aber über die nächsten Wochen wird sich schon wieder Zeit finden...
isnoAhoy schrieb: >> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente. Habe die aktuelle von @isnoAhoy zusammengestellte Liste jetzt zumindest mal dem Repo hinzugefügt: https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx Ja, die Erkenntnisse daraus sollte ich (?) dann mal in die Haupt-Doku (https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) einfließen lassen...
Marcus schrieb: > Petra R. schrieb: >> Ich möchte auch mal hinterfragen, ob es einen Sinn >> macht, sekündlich Werte abzufragen? > > Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools > berücksichtigt werden. Ich denke dies ist immer noch des ersten > funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer > stabil kommen. In manchen Programmen war/ist auch immernoch das "AutoACK" eingeschaltet. Das geht in die selbe Richtung: da wir schlüssig nachgewiesen haben, dass die WR kein AutoACK machen, bedeutet das faktisch, dass unsere Programme das jeweilige Paket mehrfach (ich meine 15-fach) hintereinander aussenden. Das führt vermutlich zu "verlässlicherer" Kommunikation, flutet aber natürlich "unnötigerweise" das 2.4 GHz Band. Die bisherigen Erfahrungen zeigen, dass das eine DTU auf jeden Fall nicht ganz so "extrem" macht, und trotzdem "verlässlich" kommuniziert. Langer Rede kurzer Sinn: später muss * das AutoACK ausgeschaltet und * das Poll-Intervall auf einen "sinnvollen" Wert (15s, 30s, evtl. noch langsamer) ...eingestellt werden.
Gast
#7050849
HM1500 funktioniert hier auch mit ESP8266 und NFR24L01+ und die letzte Seriennummer meine 1500 fangt auch mit 1161 an. Steht upload nach PvOutput.org noch auf's Programm?
Hallo zusammen, Jan (HM-600) und ich (HM-1500) haben gerade den ESP8266 und Python Code, die Byte Assignments usw. für beide Wechselrichter angeschaut. Dadurch sind wir auf folgende Erkenntnisse / Theorien gekommen: * Beim HM-600 macht der Weekly Counter keinen Sinn (bei Jan ist dieser höher als der vermeintliche Total) * Der HM-1500 hat Total Spalten für jeden seiner 4 Eingänge * Wenn der HM-600 der gleichen Struktur folgt, müsste dieser 2 Total Werte haben. * Diese beiden Werte müssten jedoch 4 Byte haben * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1) Folgende Überlegungen: Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet. Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert übergelaufen? Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4 Unabhängig davon haben wir einen Pull Request für AC I und P mit einem HM-600 erstellt: https://github.com/grindylow/ahoy/pull/21
Angehängte Dateien:
-
HM-600_Telegramm.png
(17 KB)
Guten morgen, der Code von ahoy läuft jetzt auf meinem ESP32. Vielen Dank dafür. Ich habe einen HM400 und mir mal die Daten angeschaut und dazu mal eine Frage. Es scheint ja ch0 und ch1 zu geben ? Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das ? Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem Anschluss hat. Was war denn der Plan hinter diesen Channel ? Ich kann es für den HM400 ändern, sobald ich weiß wie das Konzept ist.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Danke Marcel
Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra Steckdose brauchen würde. Marcel
Hallo Marcel, > Was war denn der Plan hinter diesen Channel ? Channel 0 stellt Parameter dar die keinem direkten Input auf der DC Seite zugeordnet werden können (also z.B. AC Strom der AC Spannung). Da es beim HM-400 nur einen Eingang gibt, gibt es neben dem CH0 auch nur einen weiteren Kanal (CH1) welcher die DC Seite darstellt. > Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das Einspeisen? Nachdem es diesen Wert sowohl für den HM-600 (und kompatible) sowie für den HM-1500 (und kompatible wie HM-1200) gibt, würde ich vermuten das dieser auch für die Einkanal Geräte existiert. Es wurde wohl nur noch nicht herausgefunden welcher Wert dem entspricht.
Gast
#7051343
Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert. Meine Skills reichen nicht aus um die Fehler selbst zu beheben. Wo stelle ich HM1200 und die Seriennummer ein?
Gast
#7051360
> Es scheint ja ch0 und ch1 zu geben ? Richtig, CH0 dürfte allegemeiner Natur sein, sowas wie AC Seite des Wechselrichters und evtl. Temperatur. > Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das? Nicht ganz CH1..4 sind die MPPT Channel. > Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem Anschluss hat. In der Hoymiles Dokumentation bzw. der App zur Hoymiles DTU-Lite-S heißt CH0 auch "Output grid port" und die anderen Kanäle CH1 .. CH4 "Input port1..4". Ich habe gestern noch ein wenig in den offiziellen Dokus gelesen und dabei habe ich noch eine Menge DTU und WR Seriennummern gefunden. Ich werde diese die Tage evtl. mal noch im Seriennummern XLSX nachtragen.
Gast
#7051373
Hallo Thomas B. und Jan, > * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 > keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht > * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1) Ich glaube die Vermutung hatten wir auch schon weiter oben auf Seite 4. Aber ich habe gerade keine Referenz. Vielleicht war das auch nur ein Gedanke als es sich herausgestellt hat, daß die Yield Total Werte in kWh ja vier Byte belegen. > Folgende Überlegungen: > Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen > Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet. Das wäre in der Tat sinnvoll, da die einzelnen Telegramme ja über den Rahmen jeweils mit einem CRC8 und ggf. CRC_M/16 (Modbus) gecheckt werden können. Vielleicht gibt es am Ende (0x8x Telegramm) ja auch noch eine weitere Prüfsumme ? > Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert übergelaufen? Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn diese Telegramme wie bisher immer einzeln verarbeitet werden. @Lukas P. bei den HM-1000/1200/1500 habt ihr ja alle vier Byte in einem Telegramm. Für die HM-600/700/800 bräuchten wir in der Tat so einen Übertrag oder eine Kombination aller Teilinformationen der Telegramme um die ganze Nachricht zu parsen. > Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null > sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4 Wie gesagt das hatte ich auch angenommen, weiß jetzt aber nicht ob wirklich jemand seinen HM-600/700/800 schon zum "Überlauf" in das erste Telegramm gebracht hat. Dauert ja logischerweise auch doppelt so lange wie bei den größeren HM-1000/1200/1500 =^D Meiner wartet noch auf die Montage der Solarpanele bevor er richtig einspeißen darf.
Gast
#7051380
> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen > ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? > > Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert. > Meine Skills reichen nicht aus um die Fehler selbst zu beheben. > > Wo stelle ich HM1200 und die Seriennummer ein? Hallo Sorbit, schau mal auf der Anleitung nach: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den ESP8266 zu kompilieren. Prüfe mal folgendes: * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support herunterladen) * die beiden RF24 und TimeLib Bibliotheken im Library Manager installieren. @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der ESP8266 Boards Umgebung ? Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem o.g. Github aufmachen, damit wir die Dokumentation erweitern und die Schritte die Dir fehlen nachreichen ? https://github.com/grindylow/ahoy/issues
isnoAhoy schrieb: > brauchen wir auch die Ticker Bibliothek oder ist die Teil der > ESP8266 Boards Umgebung ? Ich denke nicht, da diese direkt von der ESP8266 Bibliothek mitgeliefert wird. (Hier wird sich in naher Zukunft auch noch was ändern, ich diskutiere hier gerade mit stefan123t auf Github.) Sorbit schrieb: > Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen > ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP auf die /setup Seite gehen und dort alles konfigurieren. Marcel A. schrieb: > Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das > Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz > abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra > Steckdose brauchen würde. Das Yield Total ist doch genau das Feld. In der neuen Version sind auch Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 habe ich mal 4 beispielhafte Berechnungen definiert)
isnoAhoy schrieb: > Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die > dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn > diese Telegramme wie bisher immer einzeln verarbeitet werden. Die Schwierigkeit wäre dann auch noch, wenn es wenn es zu Paketverlusten beim Überlauf kommt. Also wenn man z.B. beim HM-600 bleibt und der Total Wert wirklich über zwei Telegramme verteilt ist könnte es ja zu folgendem Szenario kommen: * Anfrage senden * Antwort Paket ID 1 geht verloren * Antwort Paket ID 2 kommt durch und der Total Wert steht bei 0xFF 0xFF... * Paket ID 1 wird erneut angefordert * Jetzt gab es den überlauf, die letzten beiden Bytes in Paket 1 sind 0x00 und 0x01. * Sollte man jetzt beide Pakete einfach zusammensetzen hätte man ja 0x00 0x01 0xFF 0xFF * In Wirklichkeit sollte es aber 0x00 0x01 0x00 0x00 sein * Man müsste also auch Paket 2 neu anfordern
Hallo, Lukas P. schrieb: > Das Yield Total ist doch genau das Feld. In der neuen Version sind auch > Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, > dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 > habe ich mal 4 beispielhafte Berechnungen definiert) Da würde ich nicht mitgehen. Das was ich gemessen habe, entspricht nicht dem Yield Total. Es weicht 1% ab. Ich würde sagen, das YieldTotal eben die Gesamtenergie der SolarPanele ist. Laut Datenblatt haben die Hoymiles auch einen Wirkungsgrad in dem Bereich - 99%. Rechnen bringt mir leider nicht viel, da ich einen totalen Wert (immer steigend) brauch (auch nach einem Neustart). Was man simulieren könnte, wäre das ich 1% vom Yield Total abziehe und diesen Wert dann als AC Energy Total nutze. Anbei ein Screenshot wo man den Unterschied zwischen AC und DC sieht. Marcel
Angehängte Dateien:
Gast
#7051621
Hallo Thomas B., ja das ist noch ein zusätzliches Grund. Ich dachte nur daran was es für Werte mit den niederwertigen Daten aus Paket 2 ohne die höherwertigen Daten aus Paket 1 ergibt, bzw. wie man diese zwischenspeichert bis das zweite Paket auch da ist. In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. @Lukas P. da könnte der Link zur State-Machine vielleicht nochmal hilfreich sein: https://hackaday.com/2015/09/04/embed-with-elliot-practical-state-machines/
IsnoAhoy schrieb: > In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, > [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn > alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) oder einen Gesamt-CRC. Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu anderen Messeinrichtungen? Ich messe mit einem selbst programmierten Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung. Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh gemessen hat. Das enspricht einer Abweichung von ca. 4%. Wenn ich die aktuelle Leistung vergleiche, dann sind beide Messungen bis 100W nahezu identisch, bei 1000W habe ich schon eine Abweichung von knapp 100W. Danke für den State-Machine Link - sehr schön beschrieben. Ungefähr bei der hälfte habe ich schon an Funktionpointer gedacht ;-) @ESP8266: neue Version 0.3.3 liegt im Git. Umstellung von Ticker zu millis(), Visualisierung zeigt jetzt alle bekannten Werte.
Lukas P. schrieb: > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Ich messe mit einem selbst programmierten > Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung. > Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh > gemessen hat. Das enspricht einer Abweichung von ca. 4%. Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% Abweichung.
Hallo Lukas, > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Also ich messe mit einem ESP und einem PZEM-004T mit Stromklemme. Ich hatte die Werte damals mit einer Fritz! Steckdose verglichen und die stimmten immer sehr genau. Jetzt, wo wir die Werte vom Hoymiles haben, sehe ich, dass die ziemlich die gleichen sind, wie gemessen. Ich werde die aber mal demnächst genau übereinander legen. Hab seit heute alle Daten in HomeAssistant. Das einzige was ich sagen kann ist, das die Totalsumme 1% abweicht. Da vermute ich aber, dass dieses nicht die AC Leistung ist sondern DC. Marcel
Gast
#7051867
Hallo Leute, Vielen dank für die neue Version. Die 0.3.2 läuft stabil mit dem Wemos. MQTT läuft auch reibungslos. Einen Wunsch hätte ich noch, wenn die Verbindung zum Wechselrichter nach Sonnenuntergang abreißt bleiben die letzten Werte noch im Webinterface und in MQTT stehen. Ist es möglich die Werte nach Sonnenuntergang wenn zb. 10 Minuten lang keine Werte kommen auf 0 zu setzen? Außer natürlich die Ertragswerte… Vielen Dank
Lukas P. schrieb: > IsnoAhoy schrieb: >> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, >> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn >> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. > > Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben > hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. > geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) > oder einen Gesamt-CRC. Das ist richtig. Hilft nicht gegen nicht empfangene Pakete. Andere Baustelle. Soweit verschlechtert das sogar die Empfangsrate, ist aber für den HM-600 zwingend notwendig, weil z.B. der DC kWh total von String 1 sehr sicher genau fragmentiert ist. Vorab, die fragmentierten Werte aus verschiedenen Requests zusammen zu stückeln ist nicht möglich, weil bei einer Werteänderung über das Fragment hinaus zu unterschiedlichen Zeiten sehr falsche Werte heraus kommen. Also kein Cache einzelner Fragmente (cmd'd) möglich! Man kann allerdings versuchen trotzdem irgendwie Werte zu retten, die nicht über mehrere Fragmente verteilt sind. Währe aber sehr viel Aufwand. Die Fragmente werden darüber henaus auch nicht in der richtigen Reihenfolge empfangen. Ich werde die Tage noch ein PR für ein Rewrite der Python-Implementierung einreichen. Ich bin gerade dabei das in Klassen und ein Hoymiles Modul zu zerlegen, so kann man dann damit besser Tinkern oder z.B. auch mal ein Logfile mit Rohdaten durch pipen. Und soweit ich das sehe ich das letzte byte in den 0x8n-Responses die crc8 über die zusammengesetzte Payload. Jedenfalls stimmt das verdächtig zuverlässig. Also der Ansatz mit den cmd's und channeln ist damit mal begraben, würde ich sagen. Das wars jetzt mit dem Wochenende. Ist eh vorbei :) Gruß, Jan
Gast
#7052203
Martin G. schrieb: > In manchen Programmen war/ist auch immernoch das "AutoACK" > eingeschaltet. Auf der Suche nach Gründen, warum der ESP8266 oft hängt bzw. einen Watchdog-Reset auslöst habe ich auch folgendes interessante Detail gefunden: [[https://github.com/nRF24/RF24/issues/244#issuecomment-357210585]] AutoACK sollte demnach am besten aus sein. Es gibt wohl (gefälschte) NRF-Chips, welche damit Probleme machen. Allerdings ist AutoACK bereits bei den hier verwendeten Tools (esp8266, NRF24_SendRecv) aus. > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Bei meinem HM-400 sind YieldTotal/YieldDay recht nah an meinem SonOff Pow R2 (ebenfalls mit 60W, oder waren es 100W Glühlampe?, kalibriert.) Der HM-Wert ist leicht höher. Hier sollte man aber am besten einen kalibrierten Wechselstromzähler als Vergleich nehmen. Die Kalibrierung der SonOff könnte da nicht so gut sein. Es scheint also weiter unklar, ob YT und YD beim 400er nun AC oder DC Werte sind. Mit Blick auf die 600er/1200er müssten es ja auch DC-Werte (Modulwerte) sein. Entweder die Typen sind da komplett unterschiedlich zu bewerten oder es fehlt generell der AC Wert für YT/Yx. Idee: Anhand der DC Werte für P kann man ja YT/YD für einen bestimmten Zeitraum selbst berechnen und dies mit dem ausgelesenen Werten YT/YD vergleichen. Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher sein, da der WR in die Begrenzung geht und damit bei AC weniger "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert anliegt, da Begrenzung). Ich rechne das mal für den 400er YD/YT Wert nach.
Gast
#7052254
Lukas P. schrieb: > Sorbit schrieb: >> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen >> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? > > Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier > angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP > auf die /setup Seite gehen und dort alles konfigurieren. Das ist supernett, danke! Ich probier es ASAP aus. BG
Gast
#7052258
Nomen est Omen schrieb: > Lukas P. schrieb: >> Sorbit schrieb: >>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen >>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? >> >> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier >> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP >> auf die /setup Seite gehen und dort alles konfigurieren. > > Das ist supernett, danke! > > Ich probier es ASAP aus. > > BG Sorry für den faschen Namen, ich bin an einem anderen Rechner in einer anderen "Welt"... Richtig wäre Sorbit, gewesen. Der Ersteller des Threads, der sich wundert was er hier "angestellt" hat. Toll welcher Enthusiasmus sich hier verbreitet hat! Hut ab
Peter L. schrieb: > Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut > AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% > Abweichung. Ich habe hier einen Sonoff Dual R3, um den Ertrag meines HM-600 zu messen. Kalibriert habe ich damals mit einer 60W Glühbirne. Bei mir sind es heute bisher 1,318 kWh (Sonoff) und 1,426 kWh (AHOY 0.3.3). Bei den gemessenen Watt liegt der Sonoff aktuell (keine Voll-Last) jeweils ca. 10-20 Watt unter dem per AHOY gemessenen Wert. Marcus schrieb: > Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher > sein, da der WR in die Begrenzung geht und damit bei AC weniger > "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in > dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für > das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert > anliegt, da Begrenzung). Falls uns das hilft: Ich habe auch Zugriff auf eine zweite Anlage mit HM-600 und zwei "großen" Modulen, die bei guter Sonne regelmäßig in die Begrenzung des Wechselrichters laufen. Evtl. können wir durch die Beobachtungen ja das AC/DC Rätsel lösen.
Gast
#7052501
Meine Anlage besteht aus HM-600 und 2 Module mit je 370 Wp, also 740 Wp. Der höchste gemessene Wert für die aktuelle Leistung war 612 W. Wenn das DC sein sollte müsste es schon mehr sein, m.E. Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal kurzzeitig (wie hier) drüber sein?
Hubi schrieb: > Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal > kurzzeitig (wie hier) drüber sein? Hallo, ich habe 700Wp an meinem HM600 und auf meinem shelly habe ich AC-seitig schon etwas über 600W gesehen. Meist so um die 620W. Lieder habe ich grade keine DC-Daten, da ich nicht mitlogge. Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich da. Carsten
Gast
#7052614
> Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der > sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich > da. Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten zu empfangen. Den kannst Du entweder mit * Deinem D1mini (ESP8266/ESP32) und der ahoy Software unter tools/esp8266 (v0.3.2/3) von Lukas P.oder * einem Raspberry Pi und der ahoy Software unter tools/pi von Martin G. betreiben. Anleitung zur Verdrahtung des ESP findet sich unter https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben könnte. Dann müsste man sich nicht immer erst mit dem Access Point verbinden und könnte diese Settings hart verdrahten. Zumindest in der Entwicklungsphase würde mir das eine Menge Tipparbeit im WebInterface ersparen. Ich habe nämlich jetzt mehrfach den kompletten Flash erased, da ich hier Probleme bei der Umstellung des Speicher-Layouts der Konfigurationsdaten vermutet habe. Auch scheint er den Access Point aufzumachen, wenn er das lokale WiFi Netzwerk (wegen Empfang) nicht erreichen kann. Gibt es auch einen Fallback, daß er immer mal wieder versucht das Netzwerk zu erreichen ?
isnoAhoy schrieb: > @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine > config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte > Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben ... Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update (Fehlerbehebung) sich nicht ändern. Ganz am Anfang dann die Länge von so einem Block. Darüber dann eine CRC bilden. Beim Neustart, dann die Länge aus dem EEPROM lesen. CRC abchecken und wenn so weit ok, dann mit den Werten starten ? Am Ende von so einem Block würde ich das so gestalten, das sich die Anzahl der WR ändern kann, evt. auch einzelne CRC s über WR Blöcke. Wenn sich dann jemand einen zusätzlichen WR kauft und einhängen will, kann alles so bleiben und er muss nur die SN / Typ des neuen WR eingeben. Dann wird der entsprechende Block am Ende drangehängt, mit einer CRC versehen und man kann weiter Software Updates machen ohne irgendwas einzugeben. Ist nur mal so eine Ideeeeeee :-)
Hallo zusammen, nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der ahoy.conf für einen HM-1500 (... [inverter] serial = 116173415022 ) ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 ahoy.py" leider den Anschiss ... ModuleNotFoundError: No module named 'RF24' Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit ... ModuleNotFoundError: No module named 'cross.crossunixccompiler' ... hängen. Ich habe darauf hin mit "sudo pip3 install cross" das umfassende Modul nachinstalliert, das ja dieses 'crossunixccompiler' enthalten sollte. Das ist auch ohne Fehlermeldung durchgelaufen. Es bleibt aber das Problem mit dem RF24, weil nach wie vor die Compilation von RF24 nicht durchläuft: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output. ERROR: Could not find a version that satisfies the requirement RF24 ERROR: No matching distribution found for RF24 Eine Suche nach "crossunixccompiler" war leider erfolglos, so dass ich da aktuell nicht weiter komme. Der Vollständigkeit halber: uname -a liefert: Linux raspberrypi 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 armv7l GNU/Linux Bliebe die Frage: Wo ist der Haken? Ergänzungs-Verständnisfrage zum Ahoy-Paket: Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann? Tschüssi, Petra
Vielen Dank für die zahlreichen Infos zu euren Vergeleichsmessungen. Jetzt habe ich einfach mal den Multiplikator meiner Kalibrierung (Sonoff) wieder auf 1.00 gestellt und habe jetzt identische Werte mit dem WR. Bei Gelegenheit werde ich nochmal mit einer Fritz! Steckdose gegenchecken. isnoAhoy schrieb: > Gibt es auch einen Fallback, daß er immer mal wieder > versucht das Netzwerk zu erreichen ? Das prüfe ich nochmal, sowas hatte ich mal im Sinn weiß aber nicht ob's hier implementiert ist. Finde ich auf jeden Fall sinnvoll. Herbert K. schrieb: > Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im > EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update > (Fehlerbehebung) sich nicht ändern. > Ganz am Anfang dann die Länge von so einem Block. > Darüber dann eine CRC bilden. Danke fürs Feedback. Ja hier ist noch Handlungsbedarf, ich weiß nicht mehr wie oft ich die Daten schon neu eingegeben habe. Ich werde es nochmal durchdenken und evtl. auch gleich umsetzen. Meiner Meinung sind nach der Aufteilung von WiFi und Sonstigen Settings (haben jeweils einen unabhängigen CRC) in getrennte Bereiche keine WiFi-Daten mehr verloren gegangen. (Klar da war noch der Issue mit der Passwortlänge, diese wurde auf 63 Zeichen angehoben)
Petra R. schrieb: > Hallo zusammen, > > nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern > mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der > ahoy.conf für einen HM-1500 > (... > [inverter] > serial = 116173415022 > ) > > ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo > pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 > ahoy.py" leider den Anschiss ... > > ModuleNotFoundError: No module named 'RF24' > > Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit > ... Hallo Petra, die Installation des RF24-Moduls ist leider etwas komplizierter. Ich habe versucht, das in https://github.com/grindylow/ahoy/tree/main/tools/rpi einigermaßen zu beschreiben. Im Prinzip sollte es reichen, der Anleitung für Python 3 auf * https://nrf24.github.io/RF24/md_docs_python_wrapper.html ...zu folgen. Wobei ich auf meinen beiden Raspis zuvor jeweils auch * https://nrf24.github.io/RF24/md_docs_linux_install.html ...gemacht habe. Bin mir aber nicht mehr ganz sicher, ob das wirklich notwendig ist. Einfach nur mit "pip" geht bei dieser Bibliothek wohl (noch) nicht. > Ergänzungs-Verständnisfrage zum Ahoy-Paket: > Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles > wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann? Ja leider richtig. Das entstand, als wir noch der Annahme waren, dass die WR AutoACK aktiviert hätten. Schön wär's gewesen :-(. So findet es nur andere NRF24-Empfänger, die AutoACK aktiviert haben. Leider quasi nutzlos. -- petersilie
Ich habe jetzt wider Erwartens doch noch meine DTU-lite bekommen, und würde mal versuchen, sie in Betrieb zu nehmen. Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem Einrichtungsvorgang "zuhören"? Kanal 40? -- petersilie
Martin G. schrieb: ... > Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem > Einrichtungsvorgang "zuhören"? Kanal 40? ... > -- petersilie Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-) MOSI, MISO, usw. https://www.az-delivery.de/products/saleae-logic-analyzer Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom LA klar kommst, dann die PINs im DTU-Lite :-) so ist das gemeint von mir. Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als Hex anzeigen. Bin mir aber nicht mehr 100% sicher. Muss ja beim 1. Schuss am DTU-Lite zu 100% funktionieren - wir wissen ja nicht, was sich der alles merkt. :-) Den LA gibts natürlich auch bei anderen Anbietern.
Gast
#7052782
Herbert K. schrieb: > Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-) > MOSI, MISO, usw. Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner DTU festgestellt hatte: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E handelt, der einen eigenen Controller drin hat.
Gast
#7052797
Erstmal für Seriennummernsammlung vorweg. HM-800 11417420xxyy HM-1500 11616320xxyy MI-1200 10616090xxyy Ich bin diesem Thread schon lange gefolgt, wollte mich aber erst melden, wenn ich Daten von meinen beiden Wechselrichtern empfangen konnte. Hatte mir das NRF24LE01+ mit externer Antenne gekauft und einige D1 mini V3, hatte jedoch nie Empfang. Kaufte verschiedene NRF24LE01+ und testete alle möglichen Kombinationen durch. Erst als ich D3 und D4 auf D1 und D2 umverdrahtete, mit der entsprechenden Setup-Änderung, konnte ich problemlos alles empfangen. Vielleicht kann sich einer von euch einen Reim darauf machen, warum D3, D4 bei mir nicht funktionieren. -- olaf
isnoAhoy schrieb: >> Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der >> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich >> da. > > Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten > zu empfangen. Hallo, danke für den Input. Mit einem Arduino nano hatte ich hier ja Anfangs schon Daten mitgeloggt... Dann schau ich mal, ob ich es heute Abend vielleicht auf dem ESP zum laufen bekomme. Carsten
martin schrieb: > Herbert K. schrieb: ... > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E > handelt, der einen eigenen Controller drin hat. ... Entschuldigung ! Daran hatte ich nicht mehr gedacht.
Gast
#7053001
Hallo martin & Herbert, > > Herbert K. schrieb: > ... > > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E > > handelt, der einen eigenen Controller drin hat. > ... > Entschuldigung ! Daran hatte ich nicht mehr gedacht. Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal anbei. Eventuell könnte man auch mit dem openocd Debugger am SWD Port den GD32F303 anhalten und Flash Programm, etc. genauer analysieren. Es gibt m.W. eine eigene target/gd32f30x.cfg mit der es m.E. nach bei mir funktioniert hat den GD in einem MH-Z19C Sensor anzusprechen. https://github.com/gd32-rs/gd32-openocd/blob/master/target/gd32f30x.cfg Bei einer schnellen Suche nach "openocd gd32" kamen gerade noch die folgenden beiden evtl. interessanten Links heraus: https://registry.platformio.org/tools/communitygd32cores/tool-openocd-gd32 https://github.com/stlink-org/stlink/issues/769 Wobei ich in meinem Fall keinen Erfolg mit dem bestehenden target/st-linkv2.cfg hatte.
Angehängte Dateien:
-
rx_tx.jpg
(180 KB)
Martin G. schrieb: > Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem > Einrichtungsvorgang "zuhören"? Kanal 40? Ideal wäre halt eine breitbandige Aufzeichnugsmöglichkeit mit einem HackRF oder ähnlichem besseren SDR, da ja mehrere Frequenzen in Frage kommen. Ich hab meine Aufzeichnungen mit einem BladeRF gemacht, der macht dann ca 60 Mhz Bandbreite. Vorhanden ist bei mir u.a. der LimeSDR , BladeRF, HackRF. Oder evtl reicht auch ein NRF24L01-Sniffer, der zuverlässig die in Frage kommenden Frequenzen abscannen kann. Durch die Sende-Wiederholungen gibts da normal keine Zeitprobleme.
Gast
#7053077
isnoAhoy schrieb: > https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md > > Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den > ESP8266 zu kompilieren. Prüfe mal folgendes: > * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support > herunterladen) > * die beiden RF24 und TimeLib Bibliotheken im Library Manager > installieren. > @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der > ESP8266 Boards Umgebung ? > > Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem > o.g. Github aufmachen, damit wir die Dokumentation erweitern und die > Schritte die Dir fehlen nachreichen ? @ Lukas, @isnoahoy, der Geier weiß warum; Erfolg;-) Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen und nun läuft der Compiler fehlerfrei durch!!! DANKE!!!
Gast
#7053089
Sorbit schrieb: > isnoAhoy schrieb: >> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md >> >> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den >> ESP8266 zu kompilieren. Prüfe mal folgendes: >> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support >> herunterladen) >> * die beiden RF24 und TimeLib Bibliotheken im Library Manager >> installieren. >> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der >> ESP8266 Boards Umgebung ? >> >> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem >> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die >> Schritte die Dir fehlen nachreichen ? > > @ Lukas, @isnoahoy, > > der Geier weiß warum; Erfolg;-) > Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen > und nun läuft der Compiler fehlerfrei durch!!! > > DANKE!!! Ich habe den NRF noch nicht angeschlossen (verdammt wo liegt der rum?) Mit dem AP kann ich mich verbinden, anpingen, Webseite bleibt aber leer. Ich denke das ist "normal" so wenn der NRF noch nicht dranhängt? Danke, ich suche weiter...
Sodele,
ich habe jetzt das ahoy.py auf einem Raspi 3B mit einem HM-1500 zur
Kommunikation bekommen und sehe erste Returns:
2022-05-03T07:20:30.553251Z MSG src=73415022, dst=73415022, cmd=1:
{"ts_unixtime": 1651555230.553251, "isodate":
"2022-05-03T07:20:30.553251", "rawdata": "95 73 41 50 22 73 41 50 22 01
00 01 01 4e 00 1a 00 14 00 56 00 42 00 00 08 0b c3", "crc8_valid": true,
"mid": 149, "response_time_ns": 18257366, "ch_rx": 3, "ch_tx": 40,
"src": "73415022", "name": "dcdata", "dst": "73415022", "cmd": 1,
"u1_V": 33.4, "i1_A": 0.26, "p1_W": 2.0, "u2_V": 8.6, "i2_A": 0.66,
"p2_W": 0.0, "p_W": 2.0, "unknown1": 1, "unknown2": 2059}
2022-05-03 09:20:30.601844 Received 27 bytes on channel 3 pipe 1: 95 73
41 50 22 73 41 50 22 02 00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c
e3
2022-05-03T07:20:30.602257Z MSG src=73415022, dst=73415022, cmd=2:
{"ts_unixtime": 1651555230.602257, "isodate":
"2022-05-03T07:20:30.602257", "rawdata": "95 73 41 50 22 73 41 50 22 02
00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c e3", "crc8_valid": true,
"mid": 149, "response_time_ns": 67262961, "ch_rx": 3, "ch_tx": 40,
"src": "73415022", "name": "acdata", "dst": "73415022", "cmd": 2, "u_V":
2.3, "f_Hz": 0.21, "p_W": 7.6, "wtot1_Wh": 0, "wtot2_Wh": 12,
"wday1_Wh": 9, "wday2_Wh": 334, "uk2": 2939}
So ganz glauben tu' ich den Werten allerdings noch nicht. :-)
Nicht mal u1_V und i1_A: Auch wenn die Sonne gerade nicht prall auf das
180 W_p Modul scheint, sollten da doch etwas mehr als 0,26 A bzw. 2 W
kommen, oder?
Fragt sich jetzt, wie ich den Interpretations-Gurus unter euch
bestmöglich in die Seite treten kann?
Noch eine Beobachtung, den Raspi betreffend: Wenn ich den (aus
Stöpsel-Faulheit) nur per WLAN anspreche, scheint der des Öfteren hängen
zu bleiben. Nach Anschluss per LAN-Kabel scheint dies nicht mehr
aufzutreten. Kann es sein, dass dessen WLAN und der nRF24 sich
gegenseitig beim Funken ins Gehege kommen?
Tschüssi,
Petra
Robert Bleumer schrieb: > Steht upload nach PvOutput.org noch auf's Programm? Ich denke aktuell liegt das Hauptaugenmerk noch auf dem korrekten auslesen der Daten. Aber später gibt es bestimmt die Möglichkeit, eine Anbindung zu PvOutput.org einzubauen. Die Doku dazu sieht relativ ausführlich aus, sodass es denke ich gut machbar wäre. https://pvoutput.org/help/index.html
Hallo Martin, danke schön für deine Erklärungen! Mittlerweile läuft's ja, wie man an meinem letzten Post sehen kann. thumbs_up > Im Prinzip sollte es reichen, der Anleitung für Python 3 auf > > * https://nrf24.github.io/RF24/md_docs_python_wrapper.html > > ...zu folgen. Das habe ich gemacht, bin aber auf einige Ungereimtheiten in der Abfolge gestoßen. Dies nur als Warnung für Nachfolgende, die es nach dieser Anleitung wortwörtlich probieren. Letztlich muss ich übrigens das ahoy.py auch mit sudo aufrufen, sonst will es nicht. Irgendwie scheine ich mich aber insgesamt wohl durchgewurschtelt zu haben. ;-) Viele Grüße, Petra
Guten Morgen ! Wie und wann und unter welchen Umständen die Kanäle gewechselt werden weiss ja scheinbar noch niemand (oder doch?). Nur mal so als Idee: Die NRF24L01+ Module kosten ja nicht die Welt. Was spricht denn gegen den Einsatz von 5 Stk. - jedes auf einem festen Kanal ? Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?
Moin, ich baue ja in der Python-Implementierung am empfang der vollständigen Payload vom Wechselrichter. Weil noch sehr "work in progress" gibts da noch kein PR zu. Nur so zur Info. Oben schrieb ich, die Zusammengesetzte Payload ist mit der crc8 im letzten byte der Payload der 0x8n-Fragmente signiert. Es ist jedoch ModbusCRC. Definitiv. Ich hab das bei mir so nebenbei laufen und bekomme sehr gute Ergebnisse. Zur Zeit ist nur der HM-600 implementiert, weil der mit dem Ansatz des Auswertens von Payload-Fragmenten eben nicht vollständig lesbar ist. Was anderes habe ich nicht. Was ich vor dem PR noch tun will: * Dekoder neu implementieren (bloß schnell hin gepfuscht als Beiwerk zum PoC) * PayloadBuilder bauen * Inverter-Klasse als Interface * Multi-Inverter Wie in der test.py zu sehen ist, lassen sich damit auch Logfiles mit Rohdaten neu auswerten. Sehr gut zum nachts entwickeln. ;) https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi (Preview, wird sicher noch ein paar mal amended) Der Output läuft bei mir aus Faulheitsgründen in eine vergleichbare Topic-Struktur, wie auch Shelly sie verwendet. Damit frisst der telegraf das gleich in die richtigen Influx measurements weg. Gruß, Jan
Gast
#7053199
Ich hätte da mal eine grundsätzliche Frage: beim Nordic Protokoll, dass die Daten seriell fliessen ist schon klar aber wird da eigentlich MSB oder LSB zuerst geschickt? Ich dachte bisher immer MSB first, aber das passt überhaut nicht mir der Anzeige meines LA (SALEAE/Sigrok) zusammen. Die Anzeige meines DSO (Batronix Rigol DS1054Z, alle Optionen freigeschaltet) decken sich damit auch nicht. Ich habe schon probiert wie wild, komme damit aber nicht so recht weiter. Wer kann helfen?
Herbert K. schrieb: > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ? Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme vermissen.
Gast
#7053226
> > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ? > Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme > vermissen. Das hatte Oliver F. bereits am 16.04.2022 auf Seite 3 mit einem hübschen Modell mit insgesamt sechs NRF24L01+ vorgeschlagen. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" @Oliver F., was ist denn daraus geworden ?
Gast
#7053814
Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana visualisiert. Anbei einige Diagramme. Die AC-Leistung stimmt mit meiner Kalibrierten Sonoff Steckdose bis auf wenige Watt Unterschied überein. Danke und großes Lob an alle.
Angehängte Dateien:
Mich@ schrieb: > Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana > visualisiert. Anbei einige Diagramme. Netter Versuch :) Anbei mal Ausschnitte aus meinem Dashboard. Die zugehörige Telegraf-Config hab ich oben mal gepostet. Das Dash braucht Influx2 (Flux) Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus dem HM600 raus geholt. Request 80 02 + time
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche Transaktionen mit valider crc über die 140 byte. Viel Spaß beim dechiffrieren *duckundweg Eine Antwort auf 80 0b "Zeit setzen" sieht zum Vergleich so aus:
1 | |
2 | |
3 | |
4 | |
5 | |
Gruß, Jan
Angehängte Dateien:
-
grafana_2h.png
(140 KB)
-
grafana_today.png
(120 KB)
Gast
#7053967
@ahoy, Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf der Konfig Seite kleben..
Gast
#7054014
Hallo Freunde, solange ihr noch aktiv am Loggen und Entschlüsseln der CMD´s seit, möchte ich euch nochmal an ein in den Hintergrund gerücktes aber wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft werden oder hier wichtige Leute abspringen: Es wäre toll, wenn ihr herausfindet, wie sich die Wechselrichter in der Leistung limitieren lassen, pro Kanal muss nicht unbedingt sein, die Gesamtleistung wäre schonmal ein sehr guter Anfang. (am besten diesen Thread nach "limit" durchsuchen, um die bisherigen Informationen dazu zu finden) Dann hätten wir endlich mal einen qualitativ hochwertigen Wechselrichter zum guten Preis/Leistungsverhältnis, der an einen kleinen Speicher angeschlossen werden kann, um z.B. die Grundlast oder zumindest ein Teil davon nachts mit dem Speicher zu decken. Es gibt bereits ein älteres Projekt aus dem photovoltaikforum mit dem MI-300 und neuerdings auch ein Update mit dem HM-800 (und natürlich baugleiche Modelle in den jeweils 3 Leistungsstufen), bei dem vorsichtig ein Loch an der richtigen Stelle in das Gehäuse gebohrt werden muss und mit einer kleinen Schaltung per PWM über einem Operationsverstärker ein falscher Strommesswert vorgegaukelt wird, so kann man den WR also auch regeln. Das hat natürlich den Nachteil, dass man etwas basteln muss und die Garantie weg ist. Gut, als Batteriewechselrichter sind die auch nicht gedacht, also wie es da mit der Garantie aussieht ist fraglich, aber sie sind zumindest geeignet und man lässt den ja auch nicht permanent mit 100% laufen, sondern regelt ihn ja dann intelligent je nach Bedarf oder Speicherfüllung. Diese guten Mikrowechselrichter sind jedenfalls besser als der Chinaschrott, der ähnlich viel kostet und noch dazu größer, lauter und ineffizienter ist. Es wäre daher toll, wenn quasi die gleiche Regelung per Funk einfach möglich ist. Deshalb würde ich euch darum bitten, dieses Signal mal zu sniffen und zu implementieren. Aber schonmal ein großes DANKE an alle, für eure bisherige tolle Arbeit, gemeinsam bekommen wir den Rest auch noch implementiert! Sonnige Grüße, Andi
Andi schrieb: > möchte ich euch nochmal an ein in den Hintergrund gerücktes aber > wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft > werden oder hier wichtige Leute abspringen: wozu willst den WR regeln? Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, bringt paar Euro Eine Abregelung macht nur wegen der 70% Grenze- die eh keinen Interessiert - Sinn - oder wenn man den WR als Batterie-WR nutzen möchte
Gast
#7054079
> wozu willst den WR regeln? > Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, > bringt paar Euro > Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein hat.
Gast
#7054129
> Es wäre toll, wenn ihr herausfindet, > wie sich die Wechselrichter in der > Leistung limitieren lassen, pro > Kanal muss nicht unbedingt sein, die > Gesamtleistung wäre schonmal ein > sehr guter Anfang. (am besten diesen > Thread nach "limit" durchsuchen, um > die bisherigen Informationen dazu zu > finden) > Es wäre daher toll, wenn quasi die > gleiche Regelung per Funk einfach > möglich ist. Deshalb würde ich euch > darum bitten, dieses Signal mal zu > sniffen und zu implementieren. Hallo Andi, das ist in der Tat ein interessantes und mE wichtiges Thema. 1. Zero Export Restrictions Mode Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU setzen. > 4.1 Work Mode (page 9) > Normal: In this mode, the microinverter operates normally and converts DC power into AC power to support the household loads and feeds into the public grid. > Zero Export Control: In this mode, the microinverter’s generation is limited based on the current household loads, and there is no extra power fed into the public grid. > Standby: There are several circumstances in which the microinverter will be in Standby mode: > • The current condition contradicts with the microinverter operating requirements. > • No household loads or the export control value has been set as “0” on the DTU in the Zero Export Control mode. 2. Grid Power Profile Zusätzlich gibt es noch ein sog. Grid Profile in der DTU/Hoymiles Cloud. Ich weiß aber nicht ob man das zB von AT auf DE oder PT ändern kann… Es wird u.a. auf den Screenshots von Enercab bzw in deren Hoymiles Cloud ausgegeben. > Grid Profile Version: 2.0.0 (AT_TOR_Erzeuger_default) 3. Als drittes ist mir in den Fehlercodes des HM-600/700/800 (6.1 Troubleshooting List, page 14ff) aufgefallen, dass es u.a. auch einen Code „149 Island detected“ gibt. Einige dieser Fehler sollte man ja ggf. Provozieren und auslesen können. 4. Communication with DTU changes Status LED Indicator > 6.2 Status LED Indicator > The LED flashes five times at startup. All green flashes (1s gap) indicate normal startup. > Status LED > (1) Startup Process > • Five green flashes (0.3s gap): Startup success > • Five red flashes (0.3s gap): Startup failure > (2) Running Process > • Fast green flashing (1s gap): Producing power. > • Slow green flashing (2s gap): Producing power, but one input is abnormal. > • Slow green flashing (4s gap): Producing power, but there is no communication with DTU. > • Red flashing (1s gap): Not producing power, AC grid fault (voltage or frequency out of range). > • Red flashing (0.5s gap): Non-grid abnormality fault. > (3) Other Status > • Alternating red and green flashing: Firmware is corrupted. > *Note: All faults are reported to the DTU, refer to the local DTU app or S-Miles Cloud (Hoymiles Monitoring Platform) for more information. https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_HM-600700800_Global_EN_V202203.pdf
Sorbit schrieb: > Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein > hat. IsnoAhoy schrieb: > 1. Zero Export Restrictions Mode > Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. > Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU > setzen. kann es sein das hier die 70%-Regelung (harte/ weiche Abregelung) durcheinander gebracht wird? Für den Zero Export Control mode reicht es sicher nicht diesen zu setzen - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU regelt die WR dynamisch IsnoAhoy schrieb: > 2. Grid Power Profile Damit ist wohl die Einstellung des CosPhi gemeint
Heinz R. schrieb: > - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU > regelt die WR dynamisch Interessant wäre das schon. Leider können da nur die weiterhelfen, die auch die DTU-Pro haben vermute ich. Bei möglichen Fehlern (wie bei MODBUS erklärt), da sind wohl auch die DTU-Pro Besitzer gefragt ? Ich habe beim HM-350 und HM-400 mal auf DC-Plus und DC-Minus einen Kurzschluß zu "Erde" gemacht. Begonnen mit 100K Ohm bis herunter zu 0 Ohm mit verschiedenen Werten. Das hat beide nicht gejuckt. Weder Mitten im Betrieb, noch bevor sie mit dem PV Modul verbunden waren. Die gehen ganz Normal in Betrieb wie immer. Erwartet hätte ich einen "Isolationsfehler", ohne das sie in Betrieb gehen, wie z.B. bei den SMA WR. Bisher habe ich keine DTU-.... Grundsätzlich wäre auch erst mal Interessant, wer welche Fehlermeldungen über die DTU-... dann in der Cloud gesehen hat. So was wie falsche Netzfrequenz zu simulieren, wird schwierig.
Gast
#7054375
Sorbit schrieb: > @ahoy, > > Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat > und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? > Ich bleibe immer auf der Konfig Seite kleben.. Ahoy, wo bist DU ?;-)
Gast
#7054413
Hallo, ich habe mir vor ein paar Wochen 2 Balkonmodule vom Stromanbieter mit 2 (vermutlich HM-350) Wechselrichtern gekauft, und ahoy.py dafür angepasst, damit ich die Ergebnisse in den io-broker bekomme. Vielen Dank was da alles schon an Vorarbeit geleistet wurde! Softwareinstallation wie im repository beschrieben, hardware raspi4, Kabel aus https://www.amazon.de/gp/product/B078JGQKWP weil ich so die gleichen Farben wie in der Anleitung verwenden konnte 😊 und Radiomodul aus https://www.amazon.de/gp/product/B07PBBC4H9 (sind also NRF24L01+ und das + bezieht sich nicht auf die anderen Teile). Damit lässt sich das ohne Aufwand zusammenstecken. Habe mir das Forum von Anfang an durchgelesen und noch hoffentlich noch für HM300, HM450, HM600, HM700, HM-800, HM-1200, HM1500 support eingebaut, indem ich die ersten 4 Stelen der Seriennummer auswerte und entsprechend verzweige. Außerdem Support für mehrere Wechselrichter und etwas weniger Radio Noise nachdem das Programm nach einer Meldung 10 Sekunden wartet um einen Inverter der geantwortet hat nochmals zu fragen. Programm liegt in franzongit branch. Ich hoffe das erleichtert den Einstieg für technisch nicht so versierte. lg Franz
Angehängte Dateien:
-
simple_raspi_hoymiles.jpg
(180 KB)
franz schrieb: > für HM300, HM450, HM600, HM700, HM-800, HM-1200, HM1500 support > eingebaut... Die alte ahoy.py, sowie das C-Projekt brauchen einen full-rewrite. Am Python bin ich gerade dran und bau da ein flexibles Modul draus, was im Idealfall so einfach instanzierbar ist wie der mqtt-client, und Framing, Fragmentierung beim senden einer arbiträr langen Payload, sowie Transport-Layer und Dekodierung übernimmt. Im Wesentlichen senden die Wechselrichter halt größere Payloads über mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die längste Payload, die ich von einem HM600 empfangen habe ist 140 byte lang. Da die crc stimmt, confirmed. Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten. Ich gehe bisher davon aus, dass der Fragment-Zähler (ehem. cmd) von 0x01-0x80 zählen kann und 0x80-0xNN (0xNN = Fragment-Zähler größer 0x80) die Anzahl der Fragmente des Pakets angibt. Schon passt da eine ganze Firmware rein. Die einzelnen Fragmente isoliert zu verarbeiten ist ein Dead-End. Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet. Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was angefragt wurde, um die Payload dekodieren zu können. Wir sollten zukünftig also von: Fragmenten, Paketen, und Payloads sprechen. Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das Paket enthält die Payload. Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment + 1 byte crc Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc Jede Payload kann demnach max 2046 byte haben. Vermutung, abgeleitet aus den bisher bekannten Umständen. Man müsste jetzt mal schauen, ob man aus dem 1. byte Payload vielleicht Rückschlüsse auf den Inhalt der Payload gewinnen kann. Gruß, Jan
Gast
#7054639
Hallo Sorbit, ich habe keine Ahnung wen Du mit Ahoy meinst. Ich glaube Martin G. / Petersilie hat das Logo gemalt und das Projekt so genannt ? Ich nenne mich isnoAhoy also eben nicht Ahoy :) > Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf der Konfig Seite kleben.. Das Problem habe ich auch. Das Programm macht beim Neustart mehrere Versuche das konfigurierte WLAN zu kontaktieren. Wenn es nicht klappt oder die Verbindung später abreißt dann kommt man ausser über den Serial Port oder ggf den AccessPoint nicht mehr an die Oberfläche. Lukas P. versucht das Problem einzugrenzen bzw zu beheben. Siehe auch: https://github.com/grindylow/ahoy/issues/15 Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Evtl. kann man in Zukunft die beiden Oberflächen vereinheitlichen und den Reconnect mit dem WLAN alle X Minuten einstellen oder per Serial Command forcieren?
Gast
#7054652
@Heinz Ja, natürlich macht im ersten Moment eine Limitierung keinen Sinn, man verschenkt ja dadurch gratis Energie, wenn man Module dran hängen hat. Aber ich habe ja auch geschrieben, um ihn als günstigen und guten Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) Der beliebte Chinawechselrichter GTIL SUN-1000 bewegt sich auch in der Preisspanne des HM-800, allerdings ist der Wirkungsgrad davon schlecht und die Leistungssteuerung muss man sich auch mehr oder weniger selbst zusammen basteln mit z.B. elektronischen Poti. Noch dazu hat das Ding einen Lüfter der recht laut wird bei 1000W, hängt aber wohl damit zusammen, das die recht hohe Verlustleistung ja irgendwie gekühlt werden muss. Ein Victron Wechselrichter übersteigt die Kosten enorm und ist auch viel zu viel Leistung um die Grundlast über die ca. 10 Stunden Nacht zu decken. Lastspitzen lohnen sich nie die ausgleichen zu können, mit denen muss man leben, das darf ruhig der Stromanbiete rübernehmen, ist einfach am billigsten und macht Insgesamt nur einen kleinen Anteil der Autarkie aus. Das ich den HM-800 nicht permanent mit 800W betreiben sollte ist mir klar, aber darum möchte ich ihn ja auch begrenzen und um halt dynamisch die Grundlast nachts zu decken, die keine 800W beträgt. Böse Zungen würden jetzt sagen, das Netz ist der beste Speicher, das ist aber illegal und nur mit einem rückwärtsdrehendem Ferraiszähler möglich. Ich und viele andere haben bereits einen digitalen Zweirichtungszähler verbaut und der wird nach und nach bei allen kommen... Und ja, eine EIGENBAU PV-Anlage mit Batteriespeicher lohnt sich, aber es dauert natürlich ca. doppelt so lange bis die Investition wieder rein ist gegenüber nur Module + nötiges Zubehör. Einen Fertigspeicher oder am besten noch PV-Anlage montieren lassen würde ich auch nicht, da dauert es mal ebend locker 15+ Jahre bis das wieder rein ist, da die Kosten deutlich höher sind. Mit meinem Eigenbauprojekt komme ich auf knapp 6 Jahre(bei steigenden Strompreise, wovon auszugehen ist, noch eher und bevor die Kritiker kommen: gute LiFePo4-Akkus halten noch ein paar Jahre länger, wenn man die richtig betreibt). Ja ist eine ganze Weile, aber was will man machen, mehr Wp und Einspeisen rechnet sich noch weniger, davon holt man die Nacht auch nicht rein und auf die Bürokratie habe ich auch keine Lust... Außerdem selbst wenn man nach 6 Jahren rechnerisch bei +-0 ist, hat man immernoch die Hardware(Panel, Wechselrichter, Laderegler, Akku mit Restkapazität ...), die einen Restwert hat, beim Stromanbieter sieht man von seinem Geld nichts mehr wieder, das hat mich überzeugt, dieses Projekt zu starten. Warnung: PV macht süchtig! :D ...alles beginnt mit einem einfachen Balkonkraftwerk und nach dem ersten Jahr will man mehr. Aber zurück zum Thema: In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure Daten rankommt, aber leider auch nicht identisch ist), sind Register zu sehen, die dafür zuständig sind: https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf 0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit dem Protokoll zum WR aussieht, aber es muss ja alles über NRF funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70% Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer wieder zyklisch das aktuelle Limit geschrieben. Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur da das möglich bzw. freigegeben ist. Grüße
Ich konnte der (esp8266) Anleitung sehr gut folgen und kann seit heute meinen HM-800 auslesen. Super wie schnell dies hier entwickelt wurde! Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry über MQTT. Mir sind zwei Dinge aufgefallen: 1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel vom Wert des 2. Channels sofort überschrieben. 2) In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der Channels. Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler wenn dieser Wert direkt angezeigt wird. Gruß Manuel
Angehängte Dateien:
-
Screenshot_2022-05-04_180548.jpg
(98 KB)
IsnoAhoy schrieb: > Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je > nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN > Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Im Prinzip ist alles gleich, nur dass im AP Modus standardmäßig auf die Setup Seite verwiesen wird. Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem WLAN zu verbinden. Achtung, einige Einstellungen gehen beim Upgrade verloren, das wurde noch nicht bearbeitet. Changelog = Git-Log (https://github.com/grindylow/ahoy/commits/main) Wie gewünscht sind jetzt alle Einstellungen, die zur Kompilierzeit gemacht werden können in einer config.h Manuel M. schrieb: > In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay > angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der > Channels. Sehr schön, dass es auf Anhieb geklappt hat. Ich verwende ioBroker als MQTT Server, dieser erstellt dann "Unterordner" da jedes Topic mit Slashes getrennt geschickt wird, z.B.: /inverter/hm1200/ch1/u_dc /inverter/hm1200/ch2/u_dc ... Bei mir wird hierdurch nichts überschrieben, da alles eindeutig und unique ist. > Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler > wenn dieser Wert direkt angezeigt wird. Die Summe lässt sich recht einfach bilden, indem du in der hmDefines.h für den HM800 folgende beiden Zeilen hinzufügst (kopiert vom HM1200):
1 | |
2 | |
Andi schrieb: > Aber ich habe ja auch geschrieben, um ihn als günstigen und guten > Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) Tolles Thema, gibt es hierzu auch ein Forum? Bin auch interessiert an einer Selbstbau-Speicherlösung. Wäre super wenn man hier eine ähnliche Community hätte wie diese hier, wobei bei Geschwindigkeit kann uns hier keiner was vormachen! ;-)
Gast
#7054758
Lukas P. schrieb: > Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem > WLAN zu verbinden. Super, wie schnell die Entwicklung voranschreitet! Habe die neue Version gleich installiert :-P Ist leider in mehreren Versuchen nur jeweils wenige Minuten erreichbar, WIFI wurde nur einmal aut. restarted. Nach welchem Zeitraum sollte das WIFI neustarten, muss ich länger warten? Ausserdem ist mir aufgefallen, dass nach dem aut. restart die MQTT Verbindung nicht mehr connected war. Wird die auch restarted? SG Robert
Herbert K. schrieb: > martin schrieb: >> Herbert K. schrieb: > ... >> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E >> handelt, der einen eigenen Controller drin hat. > ... > Entschuldigung ! Daran hatte ich nicht mehr gedacht. Hatte schonmal jemand den Mut, seinen WR aufzuschrauben? Mit etwas Glück ist ja darin direkt ein NRF24L01+ verbaut anstelle des NRF24LE1E?
Lukas P. schrieb: > { FLD_YD, UNIT_WH, CH0, CMDFF, CALC_YD_CH0, 0, 0 }, > { FLD_YT, UNIT_KWH, CH0, CMDFF, CALC_YT_CH0, 0, 0 }, Danke - das klappt so - kann man das in der hmDefines.h für den HM800 so einchecken?
Jan-Jonas S. schrieb: > > Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus > dem HM600 raus geholt. > > Request 80 02 + time > [code] .... 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c .... > Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche > Transaktionen mit valider crc über die 140 byte. Viel Spaß beim > dechiffrieren *duckundweg > Gruß, > Jan Hallo Jan, kann ich so bestätigen für HM-350/HM-400. Telegramm "04" sieht bei einem von meinen identisch aus. Telegramm "89" sieht bei einem von meinen anders aus bei einigen Bytes, einige sind identisch. Mehr habe ich noch nicht verglichen. Was auch immer das bedeutet. Ich lass das mal ne Zeit mitlaufen, ob sich da Werte ändern.
Hallo, Ich entschuldige mich für meinen deutschen Übersetzer Ich möchte einen externen MQTT-Server verwenden, jetzt kann ich die IP-Adresse angeben (1.2.3.4), kann ich Unterstützung für Hostnamen hinzufügen?
Gast
#7055322
Jan-Jonas S. schrieb: > Im Wesentlichen senden die Wechselrichter halt größere Payloads über > mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die > längste Payload, die ich von einem HM600 empfangen habe ist 140 byte > lang. Da die crc stimmt, confirmed. > Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt > in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich > einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten. ja, das ist sicher so, nur bei meinen kleinen 3xx geht/ginge sich alles in je einem Paket aus. Allerdings ist die python version schon so schlau, alle Antworten einer Sendung einzusammeln und dann hintereinander zu verarbeiten, somit konnte ich einbauen, mit globalen Variablen Daten zwischen 2 Fragmenten auszutauschen, ob es funktioniert, kann ich mangels entsprechender WR nicht testen. Ich nehme an, beim HM-600 ist das highword von total power 1 in 0x02 das letzte Word in 0x01, das das schon aufgetreten? Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich alles im 2. ausgehen, ist aber geteilt. Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder konstant oder springen. Ich erwische aber jedenfalls auch nicht alle Pakete, auch wenn ich 10 Sekunden Pause mache. Zumindest in 87% der Fälle wo ich die Antwort erwische, habe ich beide, so ich mit 40 sende. Bei 23 als Sendechannel ist es bei mir um 25% besser, allerdings erwische ich da ingesamt auch nur auf 40% der Sendungen eine Antwort, wobei auch wieder fast alle auf je 2 channels kommen (40 ->3,75, 23-> 61,75). Den in einem C source aufgeführten Channel 83 habe ich noch nie gesehen, in der DTU-W100 Doku für MI-... steht aber auch nur von 5 und nicht 6 Channels. Habe die von lbp beschriebene Logik zum Holen der Pakete nachimplementiert, war aber bei mir auch nicht besser. Ich denke auch, dass auf dem Channel für weitere Pakete bleiben wie zZ implementiert gar nicht zielführend ist, da nicht nach x-Paketen die Suche beendet wird, greift der Algorithmus aber sowieso zwischen Versendungen nicht. Auch aus Sicht des WR wäre es unklug alles auf je einen Channel zu setzen. Seine Beschreibung zum Nachfordern habe ich noch nicht versucht, diese Sonnenabhängigkeit ist eine echte Programmierbehinderung :-) lg, Franz
Hallo zusammen, ich habe in den letzten Tagen Martin G.'s Raspi-Programm ahoy.py für den HM-1500 adaptiert und die (ich meine, auch von ihm) als Farbgrafik gepostete Feldbedeutung der CMDs durchgesehen und in Teilen ein wenig nachkorrigiert. Jetzt sind die Ausgaben jedenfalls stimmig und für mich mit meiner PV-Paneel-Anordnung nachvollziehbar. (Ich habe 4 180 W bp-Solar Paneele auf dem Balkon liegen.) Um einen besseren Überblick über noch nicht zuweisbare Feldeinträge aus den Commands (1, 2, 3, 132 - was Anderes scheint's beim HM-1500 nicht zu geben) zu bekommen, habe ich das Logging zwecks visueller Inspektion ein wenig umgestellt und die Variablen anders benannt. Alle Änderungen beziehen sich auf die Subroutine on_receive(), die ich in der neuen Form als Anhang dranhänge. Die sich durchaus stark ändernden Blöcke des 132er Commands scheinen wesentlich mit der Verfügbarkeit des AC-Anschlusses zu tun zu haben. Um das zu untersuchen, habe ich den HM-1500 mal stromlos geschaltet und dann wieder eingestöpselt (entspricht ja einem Stromausfall). Die kondensierte Logdatei hängt dazu ebenfalls an. Meine Schlüsse daraus: - Die Variable uk_132_1 korreliert mit einer bemerkten AC-Frequenz - Die Variable uk_132_2 korreliert mit der Stromabgabe Weiter bin ich allerdings leider noch nicht vorgedrungen. Aber vielleicht finden ja einige Gurus hier noch was dazu raus ... ;-) Viele Grüße, Petra
Nachtrag: - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des Wechselrichters.
Gast
#7055431
Einen Wunderschönen guten Tag, da ich so gut es geht vermeiden will, mit China-Servern verbunden zu sein, bin ich auf das Forum gestoßen und bin Erstaunt darüber, was bereits zustande gekommen ist. Applaus dafür! War beim lesen der Postings schon nervös, ob dieses Projekt überhaupt was wird. (Beim Thema sniffen der internen Kommunikation der DTU-W100). In den nächsten Tagen bekomme ich einen HM-1500 und 4x 450Wp Panele, die ich unbedingt begrenzen möchte. Im Idealfall mit Zero-Export-Funktion. (Mir ist bewusst dass hierzu zusätzliche Messinstrumente usw. installiert werden müssten) Die Drosselung des Inverters auf fixe Maximalwerte, wird wohl etwas einfacher zu realisieren sein. Beispiel: Geringer Eigenverbrauch = Inverter auf 50% Höherer Verbrauch = Inverter auf 90% Es gibt auch Möglichkeiten in Form von Zuschaltung zusätzlicher Verbraucher. Habe einige ESP32, ESP8266 und Gosund(Tasmota) Steckdosen zuhause. NRF24L01+ sind auch bestellt. Nach inbetriebnahme kann icht gerne auch Daten beisteuern. Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion zu "entschlüsseln". Fragen: Habe zu diesem Thema nichts gelesen (möglicherweise überlesen): Wenn die Inverter/DTUs ausgeliefert werden, sind sie ja auf einer bestimmten FW, die vermutlich übers Internet upgedatet werden kann. Kann es sein, dass das Verhalten der Kommunikation je nach FW anders ist? Dann müssten wir am besten alle auf der selben FW sein um weiterzukommen.. Besteht bzw. wie hoch ist die Gefahr, dass Hoymiles die Inverter und DTUs updatet und verschlüsselt, wenn man sich zu ihren Servern verbinden? Sollte ich mir vorbeugend jetzt schon einen weiteren HM1500 für eine Zukünftige Erweiterung besorgen? Gehe davon aus, dass Hoymiles die Geräte durch weitere Hardware/Softwareeingriffe noch "sicherer" machen werden und die Inverter in Zukunft keine Seemanssprache verstehen. (Siehe Playstation 4 Jailbreaks) Freue mich darauf, eure Meinungen zu hören.
Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie Hat die HMT-Serie ein geändertes Protokoll? Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern: HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500 1200-4T HMS-1000 900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.
Gast
#7055747
Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. Hoymiles 1200.
Angehängte Dateien:
Gast
#7055753
Hallo Franz, > Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das > letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich > alles im 2. ausgehen, ist aber geteilt. > > Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder > konstant oder springen. Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD genannt wird/wurde. Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y gesetzt, also das höchstwertige Bit 8 wird gesetzt. Bei zwei Paketen also 0x01, 0x82 Bei drei Paketen 0x01, 0x02, 0x83 Und bei vier 0x01, 0x02, 0x03, 0x84 etc pp Die CRC8 der Pakete sind jeweils die letzten Bytes vor 0x7F Und die CRC_M/CRC16 sind die letzten beiden Bytes vor dem CRC8 des 0x8y Pakets. Wie Jan Jonas schon schrieb wäre es sinnvoll statt von CMD von einem Paket Counter zu sprechen, dessen höchstwertiges Bit 8 gleichzeitig als Nachrichtende Flag dient
Python voraus! ich habe heute mal einen weiteren riesigen Dev-Snapshot gepushed. ahoy.py implementiert jetzt - Multi-Inverter - Transport-Layer und Retransmits von verlorenen Frames - Full Payload Decode mit Device- und Request- abhändigen Decodern - Dynamisches mqtt-publishen, jenachdem wieviel Phasen/Strings TBD: - mehr als nur den HM-600 supporten - code cleanup - irgendwie noch eine Strategie für Struktur der Decoder einfallen lassen Ist halt noch ein PoC und enthält mit Sicherheit Fehler. Hier: https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi Das mit den Retransmits sieht dann so aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Gruß, Jan
Sorbit schrieb: > Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. > Hoymiles 1200. Das kann ich bestätigen. HM-1200 mit AHOY 0.3.6
Servus, habe das ganze jetzt auch laufen. MQTT Broker läuft in Home Assistant. Emfange damit auch alle anderen Geräte, die über das MQTT Protokoll senden. Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected ist.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Kann ich das irgendwie anders prüfen ?
Gast
#7055793
Hans W. schrieb: > Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected > ist. Hast schon mit einem MQTT Sniffer die Topics geprüft? Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem // SGR
Robert S. schrieb: > Hast schon mit einem MQTT Sniffer die Topics geprüft? > Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem // hab das ganze mal mit iobroker versucht und da wird ein ganzer Ordnerstamm erstellt. Scheint also an Home Assistant zu liegen... Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA. Aber das kommt dann im Sekundentakt rein. Muss ich wohl noch ein wenig suchen, woran es das liegt im HA. ESP-DTU funktioniert also !!! Top !!!
Gast
#7055815
Hans W. schrieb: > Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( > /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA. > Aber das kommt dann im Sekundentakt rein. > > Muss ich wohl noch ein wenig suchen, woran es das liegt im HA. Ich habe bei mir folgendes in der configuration.yaml: - platform: mqtt state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal" name: "Gesamtproduktion PV-Gartenhaus" device_class: energy unit_of_measurement: "kWh" Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | float) | round(2)) }}" will einfach nicht funktionieren.
Sorbit schrieb: > Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. > Hoymiles 1200. Kann mir vorstellen, dass das an den MPPT Reglern liegt. Der HM1200 hat nur zwei, also sind je zwei Anschlüsse parallel geschaltet. Hier entsteht wahrscheinlich ein geringer Fehler beim messen. Die Spannung wird übertragen, da es für den WR nur 2 DC Spannungen gibt. Petra R. schrieb: > - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des > Wechselrichters. Das ist kein Last-%-Grad, sondern der Power-Factor. https://de.wikipedia.org/wiki/Leistungsfaktor Jan-Jonas S. schrieb: > Transport-Layer und Retransmits von verlorenen Frames Lohnt es sich das Re-Transmit der Pakete zu implementieren? Aktuell ist meine Statistik fast jeden Tag gleich von der Verteilung her. Ich frage, da es ja noch nicht so genau bekannt ist, welche Sendekanäle der WR wirklich benutzt. Hat jemand schon mal eine DTU beim Re-Transmit erwischt?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Gast
#7055849
Hallo IsnoAhoy IsnoAhoy schrieb: > Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD > genannt wird/wurde. > Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y > gesetzt, also das höchstwertige Bit 8 wird gesetzt. > Bei zwei Paketen also 0x01, 0x82 ja, dass die "cmd" paketzaehler sind ist mir klar, dass das leftmost bit die endmarkierung ist, leuchtet mir jetzt auch ein. Ich hatte fälschlicherweise geglaubt, dass es bei anderen Modellen sowas wie anfragenübergreifende Nachrichtenzähler gibt den meine einfachen 3xx inverter mit 112174.. nicht haben - obwohl ich sie beim Zusammensuchen der dortigen Felder nicht gesehen hatte. Als ich mit anderen Sendekombinationen experimentiert hatte, war ich bis (durchgängig) 7 gekommen, allerdings habe ich das 0x88er dann wohl immer verpasst. Fast schade, dass ich Dienstag soviel Zeit hatte andere Modelle dazuzusuchen und die Struktur anzupassen (z.B. 3 mal umüberlegt ob mit 0 oder 1 bei DC zu starten, in der micro version ist es ja 1), immerhin habe ich nur heute abend ein wenig erfolglos refetching probiert. Ich habe mir aber als ich es merkte gleich Jans neue Version geholt. Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-( lg, Franz
Gast
#7055861
Kann ich mit Daten aus meinem HM1200 helfen? Wenn ja, welche werden benötigt?
Robert S. schrieb: > Ich habe bei mir folgendes in der configuration.yaml: > > - platform: mqtt > state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal" > name: "Gesamtproduktion PV-Gartenhaus" > device_class: energy > unit_of_measurement: "kWh" > > Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein > > value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | > float) | round(2)) }}" > > will einfach nicht funktionieren. ich hab es jetzt mal so eingetragen. Morgen sehen wir weiter.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Lukas P. schrieb: >> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des >> Wechselrichters. > > Das ist kein Last-%-Grad, sondern der Power-Factor. > https://de.wikipedia.org/wiki/Leistungsfaktor Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" getaufte Variable (Werte typisch bei 980 => 0,98) meintest? Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und "uk_132_4" (wild im einige Zehntausenderbereich schwankend). Any ideas? Tschüssi, Petra
Petra R. schrieb: > Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" > getaufte Variable (Werte typisch bei 980 => 0,98) meintest? > > Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" > (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und > "uk_132_4" (wild im einige Zehntausenderbereich schwankend). > > Any ideas? Hallo Petra, ich kann bestätigen, uk_132_2 verläuft nahezu genauso wie der Leistungsfaktor den meine Gosund Zwischensteckdose ausgibt. Dies ist auch so bei [1] und [2] implementiert. Was Jan herausgefunden hat steht im letzten empfangenen Paket (also das mit 0x8*) in den letzten beiden Bytes (bei dir uk_132_4) der CRC über die gesamte Payload. Dies ist auch in seiner Implementierung so umgesetzt. Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl 0x00 0x07 Dein uk_132_1 konnte ich hier ebenfalls noch nicht zuordnen. [1] https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h [2] https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py Güße Thomas
franz schrieb: > Ich habe mir aber als ich es merkte gleich Jans neue Version geholt. > Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein > Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-( Sehr schön :) Übrigens kann man mit dem python-Modul auch "offline" debuggen [code] root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3 Python 3.9.2 (default, Mar 12 2021, 04:06:34) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import hoymiles >>> response = bytes.fromhex("00 01 01 3b 00 03 00 0b 01 3c 00 04 00 0d 00 00 a2 16 00 00 99 24 06 47 06 4d 08 dc 13 8a 00 00 00 00 00 00 00 00 00 d8 00 5a b1 89") >>> hoymiles.decoders.HM600_Decode0B(response).__dict__() {'phases': [{'voltage': 226.8, 'current': 0.0, 'power': 0.0}], 'strings': [{'voltage': 31.5, 'current': 0.03, 'power': 1.1, 'energy_total': 41494, 'energy_daily': 1607}, {'voltage': 31.6, 'current': 0.04, 'power': 1.3, 'energy_total': 39204, 'energy_daily': 1613}], 'temperature': 21.6, 'frequency': 50.02} >>> [code] Die response ist dabei eine komplette Payload, wie sie in meinem obigen Logauszug zum retransmit-Beispiel zu finden ist. Die Decoder sind Klassen in hoymiles/decoders/__init__.py class {model}_Decoder{req_cmd}(AntwortTypElternklasse) also HM600_Decoder0B(StatusResponse) Bisher gibts 2 Hautklassen UnknownResponse und StatusResponse StatusResponse ist hauptsächlich für die 0b-Werte zu verwenden und stellt den __dict__() accessor bereit. Dann muss man noch in der ResponseDecoderFactory-Klasse in hoymiles/__init__.py die ser_db um die Seriennummern-Maske erweitern, wenn die Liste das gewünschte Modell bisher nicht abdeckt. Wie gesagt, die Struktur ändert sich wohl noch. Das hab ich jetzt alles schnell um den eigentlichen Transport-Layer drumrum gehackt. Teaser: Es gibt dann schon eine Vorbereitung für einen command_queue, um später auch WR per mqtt steuern zu können. Bei mir geht übrigens ein Interval von 4 Sekunden. Bei mehreren WR würde ich sagen interval + 5s für jeden WR. Nachtabregelung muss noch implementiert werden. Ich würde das aber lieber an Anzahl TX ohne Antwort binden statt an Uhrzeiten. Also wenn nach 30 Anfragen keine Antwort, interval auf 5 Minuten oder so. Jede Payload wird im Übrigen bis zu 4x je interval wiederholt, wenn keine Antwort kommt. Das ist Absicht, brauchen wir spätestens wenn wir steuern wollen und außerdem will ich meine Antworten garantiert innerhalb des interval bekommen.
Hi Thomas, > Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl > 0x00 0x07 Da kommen bei mir aktuell häufig Werte 11 und 12. Vielleicht kann ja mal ein DTU-behafteter Kollege nachschauen, welche Werte man über die bereits zuweisbaren hinaus als Information abfragen kann? Tschüssi, Petra
Hallo bin neu hier. Habe heute meine Hardware bekommen: NodeMCU + NRF24L01. Compilieren, Upload und Config hat funktioniert. Daten vom HM600 bekomme ich noch keine, evtl. bin ich zu weit weg. NRF24L01 wird erkannt, MQTT ist connected (IoBroker). Folgendes ist mir aber bis jetzt aufgefallen: Nach einem Reboot klappt scheinbar die NTP-Abfrage nicht immer. In der seriellen Console steht oft [NTP]: 1970-00-00+00:00:00, selten das korrekte Datum/Uhrzeit. Im WebIf steht immer 1970-00-00+00:00:00. Habe den Timerserver auch schon auf fritz.box geändert, bringt nichts. Evtl ist die Abfrage ja zu schnell nach dem Wifi-Connect. Update: Die ersten Daten sind angekommen. Wenn ich mit irgendwelchen Rohdaten helfen kann, bitte melden.
Angehängte Dateien:
-
esp_dtu.JPG
(61 KB)
Gast
#7056778
Hallo Harry F. Daten bekommst Du erst wenn Du die Seriennummer im Setup eingetragen hast. Das sollte selbst ohne WLAN Verbindung zum NTP server funktionieren. Ich weiss aber nicht ob der WR auf Epoch 1970-01-01 reagiert, die Anfrage für die Statusdaten ist ja im Prinzip das Zeit setzen Kommando. Was sagt er denn bzgl RF24 und Anschlüssen. Irgendjemand hat auch hier oder im github unter Issues gemeldet dass die IRQ Leitung nicht an allen / beliebigen ESP8266 Anschlüssen funktioniert. Der Anschluss muss Interrupt fähig sein. Mit besten Grüßen Stefan
Hallo zusammen, erst mal tausend Dank für die super Arbeit die ihr bisher gemacht habt. Der ganze Thread liest sich echt wie ein Krimi. Ich habe einen HM600 mit zwei Modulen und heute mal den Lötkolben angeschmissen und das ganze auf einem Wemos D1 Mini zum laufen gebracht. Wenn ich die Statistik-Werte mit den anderen hier geposteten vergleiche, kommt es mir so vor, als würden bei mir deutlich weniger Pakete ankommen. Mein ESP6288 ist nur ca. 2m vom WR entfernt. Ist bei meinem Setup irgendwas schief gelaufen oder ist das im Rahmen? Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen erzeugt worden.
Angehängte Dateien:
-
Unbenannt1.png
(6,9 KB)
-
Screenshot_2022-05-06_at_17-26-30_Index_-_ESP-DTU.png
(14 KB)
Gast
#7056896
Hallo Lukas, habe gerade mal nachgesehen mein ESP8266 (v0.3.6) hatte vor 2:15h wohl einen Reset. Das Datum steht immer noch auf 1970 aber er zeigt Werte (Temperatur, Yield Total, Spannung, Strom, etc.) an und ist auch per WLAN Router erreichbar. D.h. nach erfolgreicher Verbindung mit dem WLAN Router erfolgt kein erneuter NTP Abgleich.
H. E. schrieb: ... > Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast > doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen > erzeugt worden. Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? 292,70 + 290,80 = 583,50 P_DC 583,50 P_DC /// 420,00 P_AC ---> 72% ? Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%
Gast
#7057000
Hallo und danke an alle die hier so tolle Arbeit leisten! Auch ich habe heute meine Anlage bekommen (HM-1500) und habe die ersten Daten empfangen. Allerdings war das erste NRF24 Modul defekt. Erst nach dem Austausch lief alles. Aber dann wirklich wunderbar. Die Daten sind plausibel und die Pakete kommen in hoher Anzahl. Auch mit einer Entfernung von aktuell ca. 6-7m. Hab den MQTT Client in FHEM eingebunden. Daten kommen sauber rüber. Allerdings wird der Client nach jedem Neustart als neues Device erkannt. Könnte da noch etwas angepasst werden? Ich hab die AHOY:0.3.2 auf einem NodeMCU. Könnte der Device Host Name genutzt werden?
Angehängte Dateien:
-
Screenshot_20220506-194137_Chrome.jpg
(230 KB)
-
Screenshot_20220506-194137_Chrome.jpg
(230 KB)
Herbert K. schrieb: > H. E. schrieb: > ... >> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast >> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen >> erzeugt worden. > Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? > > 292,70 + 290,80 = 583,50 P_DC > 583,50 P_DC /// 420,00 P_AC ---> 72% ? > > Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3% Ne, abgeriegelt habe ich nichts. Ich habe auch keine DTU mit der ich das tun könnte. Ich glaube das liegt daran, dass die Daten der beiden Channel nicht synchron mit den oberen Daten sind. Die Daten dort sind auch lange auf 0 stehen geblieben (außer YieldDay), bis dann nach ca. einer Stunde das erste 0x1 Signal kam. Läuft also noch nicht so rund bei mir.
Hallo,
habe gerade meine Python-Implementierung [1] nochmal gepusht.
Hinzugekommen sind:
* Support für den HM-1500
* Mqtt {topic}/command payload-relay
* Default decoder zur einfacheren Protokollanalyse
1 | |
Injiziert z.B. ein Zeit-Setzen-Kommando. tttttttt ist eine Variable für die Zeit. So kann man sehr einfach und zur Laufzeit neue Payloads ausprobieren. Gruß, Jan [1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi
H. E. schrieb: > Herbert K. schrieb: >> Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? > > Channel nicht synchron mit den oberen Daten sind. Genau, weil es keine "channel" gibt. Das passiert, wenn man Datenfragmente die zu unterschiedlichen Zeitpunkten "aus dem Kontext gerissen" wurden korelliert. Bei einer Abregelung sinken zwingend DC und AC-Werte um die gleiche Summe. Blieben die DC-Werte hoch würde der WR massiv Energie vernichten müssen. Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung einfach der falschen Datenerhebung geschuldet und wenn mans richtig machen würde, wie es aktuell das Python-Ding tut, ist das der Wirkungsgrad des WR. Unabhängig von der Abregelung.
Hallo Jan-Jonas ich finde es toll mit welchem Elan du an die Sache dann gehst. Echt schön zu sehen, dass auch andere viel Zeit investieren. > Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung > einfach der falschen Datenerhebung geschuldet und wenn mans richtig > machen würde, wie es aktuell das Python-Ding tut, ist das der > Wirkungsgrad des WR. Unabhängig von der Abregelung. Allerdings finde ich hast du dich hier im Ton vergriffen. Ich fühle mich in keinem Wettbewerb und ich will schon gar keine zwei Lager bilden. Bitte lass uns weiterhin an einem Strang ziehen. Jeder kann per PR beitragen. Die aktuelle Implementierung ist bei allen noch ein PoC oder? Es gibt noch kein richtig oder falsch sondern eher Fortschritte. Die Version des ESP8266 ist halt Stand heute nicht mehr 'up to date'.
Guten Morgen, soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum MQTT Broker. z.B. bei mir gestern um 16 Uhr. Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den Logs. Also ESP reboot und dann ist er sofort wieder connected. Sonst noch jemand Probleme mit MQTT ?
Wir diskutieren schon länger auf github über Stabilität. https://github.com/grindylow/ahoy/issues MQTT läuft bei mir stabil, hatte vor 20h den letzten Komplettabsturz, danach hat alles von selbst wieder funktioniert. (Version 0.3.6)
Hans W. schrieb: > Guten Morgen, > soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr > zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum > MQTT Broker. z.B. bei mir gestern um 16 Uhr. > Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine > Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den > Logs. > Also ESP reboot und dann ist er sofort wieder connected. > Sonst noch jemand Probleme mit MQTT ? Bei mir selbiges. Das Wlan läuft stabil, aber der MQTT-Client schließt die Verbindung und macht sie nicht wieder neu auf.
Gast
#7057819
Mein Wemos D1 mini mit 0.3.6 läuft leider gar nicht stabil. Die Uptime ist selten höher als 1 Stunde, die automatischen reboots dauern oft sehr lange oder vielleicht findet er auch keine SSID oder DHCP. Jedenfalls habe ich in der Statistik manchmal stundenlange Lücken. Vermutlich auch deshalb weil er nur ca. jedes zweite Mal den MQTT connected. Die onboard LED blinkt übrigens unregelmäßig, weist das auf Ausfälle hin? WIFI Probleme glaube ich eher nicht, RSSI ist bei ca. -70dbM, andere ESP8266 in der Nähe funktionieren ohne Probleme. Kann es sein dass das NRF Modul stört, es sendet und empfängt ja auf derselben Frequenz. Das NRF-Modul scheint recht stabil zu sein, der WR ist durch ein Fenster mit Jalousie und dann noch ca. 20m Luftlinie entfernt. Wäre es möglich den WIFI-RSSI auf der Webpage anzuzeigen oder via MQTT zu publishen? Damit könnten wir schlechte Verbindungen leichter erkennen.
Also heute ist es wie gestern ... um 16 Uhr MQTT Abbruch aber der Wemos ist noch up
Gast
#7057936
Hallo Zusammen, ich habe heute mal versucht den HM-600 aufzuschrauben. Leider habe ich ihn nicht komplett aufbekommen. Ich vermute daß man irgendwie die Kabelzugentlastungen lösen muß und evtl. auch noch mit etwas Wärme aus einem Heißluft-/-fön die Dichtungen lösen muß. Das habe ich meinem neuen Geräte dann doch nicht alles zumuten wollen, es soll ja nachher wieder wasserdicht und möglichst lange seinen Dienst verrichten. Vielleicht hat ja jemand einen gebrauchten, defekten HM den er mal zu Anschauungszwecken defilieren kann ? @Jan-Jonas, ich habe Deine Paketanalyse mal nachvollzogen. M.E. hast Du Recht mit dem Paketzähler und dem höchstwertigen Bit 0x8y das das letzte Paket oder eben die Anforderung für einen Request (vielleicht sogar einen Retransmit) bedeutet. Ich habe die Ergebnisse dieser Paketanalyse vorläufig hier im Github Issue dokumentiert, das kann man ggf. auch in die hoymiles Doku aufnehmen. https://github.com/grindylow/ahoy/issues/24 Hat das (so einen Retransmit oder die Spezialanfrage mit X Paketen von Jan Jonas) bei den auf Seite 1 & 2 gemachten HackRF und anderen Funkprotokollmitschnitten der Original DTU auch sonst noch jemand feststellen können ? Vielleicht können ja noch ein paar alte Hasen (die schon vor Ostern hier geforscht haben) hierzu etwas beitragen ?
lpb schrieb: > Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das > Anfordern eines nicht erhaltenen Pakets. > Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket > anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. @isnoAhoy Hier wurden die Retransmits bereits im DTU Log gefunden. Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die Statistiken, also die Counter wie oft welches Paket kam. "CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x 0x84 Anfrageinterval war 1s auf Kanal 40, empfangen statisch auf Kanal 3.
Gast
#7058024
Bei mir werden die Werte per MQTT alle Sekunde geschickt obwohl es auf 10 Sekunde eingestellt ist. Änderungen der Zeit haben keinen Einfluss.Ist das auch bei anderen so? ESP-DTU 0.3.6
Gast
#7058043
Hallo Lukas P., Du hast Recht in Spalte AA bis AE stehen drei Pakete der Standardantwort. Man kann gut sehen, daß der GD32 das Paket 0x01 nicht empfangen hat und damit in Spalte AD nochmal mit 0x81 und CRC8 0x94 anfordert. Die Antwort mit dem fehlenden Paket kommt dann in Spalte AE. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Nur die Paketcounter sind eben nicht in Zeile 16 wie von martin (Gast) im Excel vermutet. Sondern wie richtig von lbp und Jan-Jonas bemerkt das in Zeile 10 bisher als CMD bezeichnete Byte. Zeile 13-16 ist hingegen die Zeit in Unix-Epoch wie anderweitig bereits herausgefunden wurde. In Spalte AU-AZ taucht dann auch die Anfrage mit 0x80 0x11 auf, die Jan-Jonas als bisher größtes Antwortnachricht mit den Paketen 0x01..0x85 des WR identifiziert hat. @martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt zwischen GD32 und nRF24 aufzuzeichnen ?
Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen Sinn ständig die Zeit neu zu setzen. Gedacht habe ich an sowas wie ein Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die Retransmits. @Jan-Jonas S. (janjonas_s) Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den Payload gebildet werden. Beispiel, so wie es aktuell verstehe, aber die CRC8s und CRC16_P stimmen nie: 01 [...] CRC8 CRC16_H CRC16_L 02 [...] CRC8 CRC16_H CRC16_L .... 8X [...] CRC16P_H CRC16P_L CRC8 CRC16_H CRC16_L CRC8: über Paketpayload ohne CRC8 und CRC16 CRC16: ist implementiert und funktioniert CRC16P: über die gesamte Payload aller Pakete - mit oder ohne dem Paketcounter?
Gast
#7058357
Hallo Jan, Jan-Jonas S. schrieb: > Hinzugekommen sind: > * Support für den HM-1500 ich dachte bisher dass ich HM-350 haette (steht leider nicht lesbar drauf ohne den WR vom Modul zu lösen, das ja auch noch montiert ist), Aber HM-4xx macht keinen Sinn, da ich pro Modul nur 325Wp habe. Allerdings war ja die Vermutung dass die 3xx und 400 gleiches Protokoll haben, darum hatte ich die bei mir alles als 300 zusammengefasst. Ich habe daher im angefügten diff meine (mit 112174..) als 3XX bezeichnet, aber vermutlich könnte man die letzte Stelle weglassen und 3xx und 4xx damit covern. Ich habe ein diff attached. Ad Retransmit, das hatte bei mir nicht funktioniert, bis ich die +6e7 ns bei empfangenen Paketen entfernt hatte, dann erwischte ich ueberhaupt fast alles, das hast Du jetzt auf +5e8, meine Antworten kommen zwischen 1ms und 10ms, geht sich also locker aus. Sollte auch in der Mikrocontrollerversion also mindestens so hoch sein. Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages auch flat in ein kompaktes File schreiben zu können, hab mir sowas für einen geplanten remote site implementiert wo ich keine db hinter iobroker haben werde. lg, Franz
Lukas P. schrieb: > Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) > werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, > ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen > Sinn ständig die Zeit neu zu setzen. Ich glaube der WR hat keine RTC und braucht daher die Updates der Zeit über die Luft, damit er z.B. weiß wann die daily counter resetet wetden müssen. > Gedacht habe ich an sowas wie ein > Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die > Retransmits. Da stehen wir noch vor dem Anfang. Ich glaube, dass das byte nach 0x80 (normal 0x0b) das Kommando ist. Die Zeit, die wir dahinter setzen die Parameter zum Kommando. Ich hab das mal durchgesweept und bekomme da alle möglichen langen und kurzen Antworten, die sich meist auch unterscheiden jenachdem welche Parameter man anhängt. Da sind wir auf mehr DTU Captures angewiesen um das verstehen zu können. Aber da war in python spätestens auch Schluss mit den cmd'd, weil jede Antwort mindestens ein Fragment 1 enthält, wo keine bekannten Werte drin stehen. Das macht dann graphen sehr kaputt, wenn man random binärdaten zu Zahlen macht. Übrigens zum sweepen s.O. das /command-Topic. Sehr handy. > @Jan-Jonas S. (janjonas_s) > Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der > C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu > prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh > oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den > Payload gebildet werden. in hoymiles/__init__.py InverterTransaction.get_payload()
1 | |
2 | |
3 | |
4 | |
Jedes Frame besteht aus
0x95, 4byte dst_addr, 4byte src_addr, 1byte sequence, bis 16byte(?)
data, 1byte crc8
sequence:
0x01 - 0x80 ist ein forlaufendes Fragment
0x81 - 0xFF(?) markiert das letzte Paket, und die Gesamtzahl der
Fragmente
Wenn sequence größer 0x80:
int(sequence - 0x80) = Anzahl Fragmente
Das Endpaket zählt mit in den Paketzähler, 0x80 kann daher kein Wert des
Endpakets sein. 0 Pakete = keine Übertragung ;)
Wenn mann alle data bytes in der richtigen Reihenfolge zusammen setzt
(Payload), sind am Ende die 2 byte die modbus crc über die ganze Payload
Fehlt das Endpaket ist die Transaktion verloren. Die Pakete werden
meistens nicht in der richtigen Reihenfolge empfangen. Kann sein, dass
man die in der Reihenfolge 84, 01, 03, 02 liest.
Neu ist für mich auch, dass bei längeren Payloads, der WR auch auf Ch 40
antwortet.
Den ersten Re-Transmit habe ich hier gefunden
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo franz, vielen Dank für das HM3XX-Mapping! Pulled-in. franz schrieb: > Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages > auch flat in ein kompaktes File schreiben zu können, hab mir sowas für > einen geplanten remote site implementiert wo ich keine db hinter > iobroker haben werde. Sowas ist geplant und möglich. Ich stelle mir das python-modul später mal so vor, dass man es ähnlich wie auch den paho mqtt-client irgendwo rein laden kann und ein on_message-Callback bekommt, indem man Daten aus der Response nach belieben verarbeiten kann. Ich plane z.B. einen direkten Influx2-Exporter, so umzusetzen. Das soll dann jeder selber modular bauen können, weil jeder sein eigenes Backend hat und die Zahl der Output-Plugins den Rahmen des Projekts sprengen würde. Da bin ich aber noch nicht soweit, weil wir mit Sicherheit im Kern noch Dinge entdecken die möglicheriweise grundlegend überarbeitet werden müssen. Da liegt im Moment mein Fokus drauf. Bis dahin würde ich gerne die Komplexität außen rum so gering wie möglich halten. Gruß, Jan
Gast
#7058675
Hallo Jan, Jan-Jonas S. schrieb: > Pulled-in. hab die germergte version ausprobiert, funktioniert. Überinges war meine timing Aussage vorher falsch es sind 1-10 hundertstel-, nicht 1-10ms. Ich hatte mir mehrere (7) NRF module bestellt, weil ich mir nicht sicher war, ob die wayintop + sind, die + von AZ so billig waren und laut Kommentaren und eigenen Beobachtungen gibt es öfters Aufälle, bzw schlimmer, funktioniert dann nicht zuverläßig. Ich habe nur in ca einen von 1000 Fällen eine Antwort am Sendekanal (40) und 90% auf 3 und 75. ALso kann ich mit einem chip staendig auf 3 und mit dem Sender gleich auf 75 umschalten, um zu sehen ob was kommt. Mit einem 2. Rapsi kann ich dann auch noch auf 2 weiteren Kanälen lauschen, sollte von der library her gehen und werde das mal ausprobieren :) lg, Franz
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.