Hallo, diese Wechselrichter verfügen über einen RF 2,4 GhZ Nordic. Hat jemand eine Idee wie dieses Protokoll aufgebaut ist? Hat jemand das schon einmal "angezapft" um ein eigenes Monitoring ohne deren Cloudzwang zu realsieren? Es gibt offensichtlich einen "Adapter", der das "2,4 GhZ Signal umsetzt und dann via WLAN an deren Cloudsysteme versendet. Google, Hersteller, etc. schweigen sich leider aus. Danke für sachdienliche Hinweise
sorbit schrieb: > Hat jemand eine Idee wie dieses Protokoll aufgebaut ist? Könnte auf der Basis von ShockBurst™ sein. Eine Beschreibung findest du z.B. im NRF24L01+ Datenblatt
Wenn die sich das einfach gemacht haben ist das ein properietäres Uart Signal.
Häng mich mal ran .... interessiert mich auch
Scheint leider niemand zu wissen… Schade, die WR sind eigentlich sehr verbreitet. Das Ding sendet ungenutzt dauernd wertvolle Daten in den Äther..
Bekomme demnächst auch den HM-600, von daher interessiere ich mich auch für das Thema. Zumal das Originalzubehör ziemlich teuer und hässlich ist...
Martin M. schrieb: > Bekomme demnächst auch den HM-600, von daher interessiere ich mich > auch > für das Thema. > Zumal das Originalzubehör ziemlich teuer und hässlich ist... Die schweigen sich da so ziemlich aus. Auf jeden Fall Cloudzwang mit Kosten und dieser wohl nicht verfügbare, teure wlan Stick
Ist da inzwischen jemand weitergekommen? Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine ID länger ist werden ignoriert. Erstes Problem: Das LC12S lässt sich nicht konfigurieren - zumindest spuckt dies die serielle Konsole aus. Beschaltet ist das LC12S so: VCC - 3V3 GND - GND CS - GND SET - IO4 Rx - IO16 Tx - IO 17 --> D.h. wenn, dann läuft es mit irgendwelchen Defaultwerten In der Konsole bekomme ich folgenden Nonsense bei aktuell schwankend 20-40W AC über Steckdose gemessen (klar, der WR ist ein anderer und hat ja bspw. 2 Strings usw...)
1 | 14:19:13.023 -> Received Inverter Status |
2 | 14:19:13.023 -> Device: 7201xxxx |
3 | 14:19:13.023 -> Status: 0 |
4 | 14:19:13.023 -> DC_Voltage: 46.00V |
5 | 14:19:13.023 -> DC_Current: 629.00A |
6 | 14:19:13.023 -> DC_Power: 28934.00W |
7 | 14:19:13.023 -> AC_Voltage: 0.00V |
8 | 14:19:13.023 -> AC_Current: 0.00A |
9 | 14:19:13.023 -> AC_Power: 0.00W |
10 | 14:19:13.023 -> Power gen total: 0.00 |
11 | 14:19:13.023 -> Temperature: 0 |
Sieht sich jemand in der Lage das Programm anzupassen? Hier ein Ausschnitt, welche Bytes überhaupt ausgewertet und wie sie verrechnet werden. Ich wüsste jtzt nicht welche Bytes wie rum zu shiften und verrechnen sind...
1 | void NETSGPClient::fillInverterStatusFromBuffer(const uint8_t* buffer, InverterStatus& status) |
2 | {
|
3 | status.deviceID = buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF); |
4 | //status.deviceID = buffer[5] << 32 | buffer[6] << 24 | buffer[7] << 16 | buffer[8] << 8 | (buffer[9] & 0xFF);
|
5 | const uint32_t tempTotal = buffer[10] << 24 | buffer[11] << 16 | buffer[12] << 8 | (buffer[13] & 0xFF); |
6 | status.totalGeneratedPower = *((float*)&tempTotal); |
7 | |
8 | // CRC = buffer[14]
|
9 | status.dcVoltage = (buffer[15] << 8 | buffer[16]) / 100; |
10 | |
11 | status.dcCurrent = (buffer[17] << 8 | buffer[18]) / 100; |
12 | status.dcPower = status.dcVoltage * status.dcCurrent; |
13 | |
14 | status.acVoltage = (buffer[19] << 8 | buffer[20]) / 100; |
15 | status.acCurrent = (buffer[21] << 8 | buffer[22]) / 100; |
16 | status.acPower = status.acVoltage * status.acCurrent; |
17 | |
18 | status.state = buffer[25]; // not fully reversed |
19 | status.temperature = buffer[26]; // not fully reversed |
20 | }
|
Ich würde mal "bluetooth-clients" in der Umgebung suchen. Vielleicht hat man Glück. ;-) Was steht auf den Nordic-Chip?
Eule schrieb: > Habe mich anhand des YT Links vorgearbeitet und habe ein LC12S an einm > ESP32 (Lolin32 V1.0.0) und vesuche meinen HM-600 mittels der Polldemo > von hier https://github.com/atc1441/NETSGPClient auszulesen. InverterID > habe ich angepasst, aber ich glaube, die ersten 4 Stellen, um die meine > ID länger ist werden ignoriert. Hi Eule, ich habe das gleiche bei meinem HM-1200 versucht. Allerdings bekomme ich einfach keine Antwort nach: "Sending request now" wie hast du denn die InverterID im code eingegeben ? einfach die komplette Seriennummer vom WR (12 stellen) wie hier ? constexpr const uint64_t inverterID = 0x11617052xxxx ;
Hallo Eule habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann verworfen. Also, ich schau's mir mal an. Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und im Klartext als auch als Hex-Dump hättest. Hast du am Original-Code was geändert, oder so wie in Github zu finden?
> > Hi Eule, > > ich habe das gleiche bei meinem HM-1200 versucht. > Allerdings bekomme ich einfach keine Antwort nach: "Sending request now" > > wie hast du denn die InverterID im code eingegeben ? > einfach die komplette Seriennummer vom WR (12 stellen) wie hier ? > > constexpr const uint64_t inverterID = 0x11617052xxxx ; Hallo Chris, ja genau. Geht aber genauso gut oder schlecht, wie wenn ich die ersten 4 Stellen einfach weglasse und nur die letzten 8 verwende. Es scheint, dass sich irgendwas verändert, wenn ich das Modul in der Hand habe. Auf dem Tisch liegtnd bekomme ich meist auch keine Antwort, halte ich es in der Hand oder an den Kabeln tut sich meist etwas. Entweder diene ich als Antenne oder ich habe einen Wackler, den ich trotz mehrmaligem Auftrennen und Neuverbinden nicht wegbekomme. Bin einfach zu lange raus aus dem C++, mich verwirrt die Polldemo. :( Gruß Eule
Hubi schrieb: > Hallo Eule > habe auch seit ein paar Tagen eine kleine Solaranlage mit dem Hoymiles > HM-600, dein Projekt würde mich interessieren. Habe zwar kein Zigbee, > aber bei Software kenne ich mich ein bisschen aus. Den SGP-Client habe > ich auch schon ins Auge gefasst, aber bei fehlendem Zigbee dann > verworfen. > Also, ich schau's mir mal an. > Wäre gut wenn du irgendwie die Kommunikation mitschneiden könntest, und > im Klartext als auch als Hex-Dump hättest. > Hast du am Original-Code was geändert, oder so wie in Github zu finden? Hallo Hubi, ich habe mir so ein LC12S Modul besorgt und an die 2. UART eines Lolin Boards gehängt. Die Polldemo habe ich lediglich um meine Inverter ID angepasst. Ansonsten habe ich inzwischen auch an zig Stellen im Code rumgedoktert - aber ich bin was das angeht mittlerweile einfach ein richtiger Anfänger. Mal alles was der WR ausgibt mitschneiden war auch meine Idee, bekomme ich aber auf die Schnelle nicht hin. Ich frage mich eh, wie der Aaron das "entschlüsselt" hat. Wenn die Werte halbwegs mit irgendwas zusammenpassen, kann man es sich ja noch zusammenreimen. Aber das passt bei mi gar nicht. Auch frage ich mich, woher kennt er den "command" mit 0xc0, 0xc1 usw.? Woher kennt er das Magic Byte? Ist das alles beim HM gleich oder anders? Gruß Eule
Hi Eule
hier auf die Schnelle der Code zur Ausgabe des Dumps:
void printBuffer (char * richtung) { // rein oder raus, send oder rcv
int i;
uint8_t ch;
Serial.println(richtung);
// drucke zuerst als Zeichen
for (int i = 0; i < sizeof(mBuffer); i++) {
ch = mBuffer[i];
if (ch >= 32 && ch < 127) Serial.print(ch); else Serial.print ('.');
}
Serial.println();
// jetzt das ganze in Hex
for (i = 0; i < sizeof(mBuffer); i++) {
ch = mBuffer[i];
if (ch < 10) Serial.print('0');
Serial.print (ch, HEX);
}
Serial.println();
}
Moin es wäre auch von Vorteil, wenn man nach dem sendCommand in der Methode getStatus den Buffer mBuffer wieder komplett löschen würde, etwa durch memset (mBuffer, 0, sizeof(mBuffer)) Da ab der Stelle 6 im mBuffer die DeviceId gefüllt wird (beim Senden) und dort nach Empfang des Status auch wieder steht, könnte man durch das vorherige Löschen ersehen, ob der Sender, also der WR, die DeviceId eingetragen hat. Dann wüßte man wenigstens, dass der WR richtig antwortet.
Kleines Update: Rx und Tx gehören anders herum, als im Code-Kommentar. D.h. alles was ich ab und zu "gelesen" habe, waren Geister. Nach dem Drehen von Rx/Tx erste Erkenntnis: die beiden Tx haben sich nicht weh getan, denn nun wird zumindest mal die Konfiguration des LC12S geschluckt! :) Aber vom Wechselrichter höre ich mit den gegeben Einstellungen für Channel und Network ID nichts. Ich bin dann auf dieses tolle Repository gestoßen: https://github.com/Yogui79/IntexPureSpa Da gibt's unter Tools was zum Suchen des Channels und der Network ID. Der klappert einfach einen nach dem anderen durch. Dauert halt... bisher noch kein Treffer beim Channel. Naja vielleicht hat der Hoymiles ja doch garkein LC12S verbaut...? Mal abwarten. Gruß Eule
OK, mal wieder was gelernt... Aber ans Ziel kam ich damit nicht. Die Kanalsuche schlägt nicht an. Also nochmal nach dem DTU gesucht und siehe da, ein Bild mit der aufgedruckten FCC ID gefunden. Die dokumentieren ja üblicherweise ihre Tests. Aha! https://fcc.report/FCC-ID/2ARNB-DTUW100 Wie man bei den internal photos sieht - kein LC12S verbaut. Sieht nach Eigenentwicklung - oder zumindest -layout aus. Wieso nicht noch weiter bei der FCC nach Hoymiles suchen? Achja, da gibt's ja auch ein RF Modul namens HM2401 einzeln - zum Verbau im WR vermutlich: https://fccid.io/2ARNB-HM2401 Auch hier gibt's nette Bilder. Das schaut tatsächlich nach was anderem aus, als das LC12S (https://fccid.io/2ARNB-HM2401/Internal-Photos/Internal-Photos-4572280) Aha! Ein NRF 24LE1E! Ich muss mal in den Keller, glaube sowas habe ich auch noch wo rumfliegen. Gruß Eule
Usr-c210 ist ein uart total WiFi modul von pusr
Tach in der Zwischenzeit habe ich einen RF24-Scanner in meinem Gartenhaus laufen lassen. Scanner sind bei diversen RF24 Libs als Beispiel dabei. Es wird nach Carriern auf den Kanälen gesucht. Mein bisheriges Resultat: - auf den Kanälen 1-14 ist recht viel los, sind ja auch die vom WLan - auf Kanal 64, der bei dem Polldemo benutzt wird, war rein garnichts los - meiste Aktivität war auf Kanal 16 bei 2 Mbps Mein nächster Ansatz, falls sonst keine neueren Erkenntnisse, wird sein, auf dem Kanal mal etwas zu senden, evtl sowas wie die Statusabfrage, und die Antwort abzuwarten. Übrigens: im Arduino-Repository gibt es die Lib nrf-hal, die stammt aus dem Hause Nordic und könnte die schon erwähnte proprietäre Lib für die Hoymiles sein.
Moin zusammen, kann ich hier mitmischen? Ich habe grade meine "Versuchsanlage" mit einem HM-600 in Betrieb genommen. Auf Grund dieses Beitrags habe ich jetzt ein NRF24-Mudul und einen Arduino zusammengesteckt und einen Scanner am laufen. Leider noch ohne Erfolg. Welche Scansoftware habt ihr eingesetzt und wie groß ist der Abstand HM und NRF-Modul (bei mir etwa 10m)? Wahrscheinlich ist es sinnvoll, den Empfänger mal direkt neben den HM zu setzen, oder? Kann ich erst machen, wenn es wieder hell ist. Finkt der HM überhaupt, wenn die Panels keine Spannung liefern? Viele Grüße Carsten
Hallo, ich hatte gesehen, dass in den FCC-Dokumenten, die weiter oben verlinkt sind, ein user manual enthalten ist. Dort ist angegeben: Channel List 2403, 2423, 2440, 2461, 2475MHz Vielleicht hilf das, die Suche einzugrenzen?
Carsten B. schrieb: > einen > Scanner am laufen. Leider noch ohne Erfolg. Hast du denn das Hoymiles Kommunikationsmodul (DTU-W100 ) laufen? Vielleicht antwortet der Wechselrichter nur auf Anfragen von diesem Gerät.
Hallo, DTU habe ich keine, war mir zu teuer und ich hätte es gern "cloudfree". Den Fehler beim Scanner habe ich gefunden, ich hatte noch zwei Pins vertauscht läuft jetzt. Noch kann ich aber keinen Kanal dem HM zuordnen.
Hallo meine Versuche mit dem Scanner hatte bisher keinen Erfolg. Oben gab es die Nachfrage welche Scanner eingesetzt wurden, ich nutzte die von den Libs rf24 und nrf_hal. Soviel ich weiß haben die nrf24l01 nur bis zu 126 Kanäle. Der Abstand zum HM-600 war nur knapp 2 m, und durch die Holzdecke + Schindeln. Bin jetzt leider am Ende meines Lateins, wenn noch jmd eine Idee hat mache ich gerne weiter.
Modul überprüfen. https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285 Direkt an TxD (oder auch RxD, das ist Definitionssache) des Moduls lauschen, ob Daten kommen. Und ganz böse: Sein eigenes Adapter-Modul einbauen. ;-)
ich bin auch interessiert - aber leider momentan viel zu wenig Zeit Aber schaut Euch doch das mal an: https://github.com/Koenkk/zigbee2mqtt/issues/4221 Hoymiles kommt aus dem gleichen Haus wie APSystems - denke das Protokoll ist sehr ähnlich Dort sind ein paar sehr fixe Jungs unterwegs die gerne behilflich sind
Angehängte Dateien:
Hallo zusammen, ich hänge mich hier mal rein, weil ich auch Cloud-Free
den "MI" auslesen will. In meinem Fall 2 HM-600.
Hoymiles kommuniziert über "Nordic proprietary"... siehe Anhang
Nordic proprietary != Zigbee
anderes Adress-/CRC-Protokol... mehr hab ich leider noch nicht erfahren
können... versuche auch schon mit 'nem NRF24l01 irgendwas zu
empfangen... fürchte aber, dass der Inverter wie beim NETSGPClient
getriggert werden muss... also aktiv Daten geholt werden.
Ansonten werden laut FCC-Test nur Kanal 13, 40 und 76 getestet
("Fundamental frequency")
Grüße^^
Das Gerät wird nicht ständig Senden. Wenn dann nur Keep Alive Packets mit größeren Abständen. Es könnte sogar sein, dass der Empfänger auch nicht ununterbrochen aktiv ist und zum Einschalten der Träger erst ein paar Sekunden anstehen muss. Die Hoymiles sind mit < 50mW Verbrauch bei Dunkelheit angegeben. Für permanentes Wlan reicht das nicht. Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die Kommunikation mitschneiden.
Einhart P. schrieb: > Eigenlich müsste jemand mit einem Hoymiles Kommunikationsmodul die > Kommunikation mitschneiden. Ich bin am überlegen, ob ich mir DTU-Wlite bestelle, gibt es momentan für 79€. Ist immer noch viel Geld...und beschränkt auf 4 Module... Bisher hat keiner der Beteiligten hier eine DTU? Mein Testaufbau mit den NRF24 und dem Arduino funktioniert, zwischen meinen beiden NRF-Modulen kann ich erfolgreich Daten austauschen. So bald das Wetter es zulässt, packe ich einen Empfänger neben den Hoymiles.
Sorry, sehe grade. dass ich als Gast geschrieben habe. Ich wars...
Tja, vllt findet sich ja einer mit DTU, der hier mitmachen will, wäre super. Meine Tests von heute morgen brachten folgende Resultate: - es scheint kein alive-Paket zu geben, das von den Hoymiles verschickt wird - Test auf Carrier-Signal auf den Kanälen, 13, 40 und 75 , dass nur auf Kanal 40 ein Carrier-Signal gefunden wurde, innerhalb einer Minute mehrere hundert.Auf den beiden anderen Kanälen war ab und zu ein Carrier, kann auch Rauschen sein. Ich denke, ohne dass man da die Kommunikation mitschneidet wird es sehr aufwendig. Ich versuch mal, ähnlich wie bei dem o.g. Projekt mit APsystems zu pollen.
Hallo zusammen, mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite bestellt, sowie einen HackRF SDR zur Protokoll-Analyse. Mein Ziel ist, die Kommunikation mitzuschneiden und die Daten mit einem nRF24 und ESP ins Heimnetz zu bringen. Die Info über die verwendeten Kanäle ist schon mal nützlich zur Eingrenzung der Suche. Ich melde mich, wenn dann mal alles da ist und ich Messungen machen konnte.
Klasse! Ich bin auf Ergebnisse gespannt.
Toll dass es hier weitergeht. Meine Tests haben zu keinem Ergebnis geführt. Das große Problem dabei ist, dass zuviele Parameter zueinander passen müssen, nämlich Kanal, (5-byte) Adressen der NRFs, Protokoll (Shockburst oder enhanced SB), Aufbau Datenpaket, "Magic" Byte, Füllbytes, CRC etc. Wenn meine Programmierkenntnisse gebraucht werden, gerne.
Angehängte Dateien:
-
spektrum.png
210 KB -
dtu_paket_zeitverlauf.png
67 KB -
dtu_top.jpg
170 KB -
dtu_bot.jpg
170 KB -
dtu_gd32.jpg
240 KB -
dtu_nrf24.jpg
240 KB
martin schrieb: > Hallo zusammen, > mich interessiert das Ding auch, daher habe ich mir jetzt den DTU Lite > bestellt, sowie einen HackRF SDR zur Protokoll-Analyse. Hallo zusammen. Die Teile sind da und ich habe bereits erste Versuche durchgeführt, wovon ich euch einen Zwischenstand mitteilen möchte. Zum Funkprotokoll: Die Kanäle 3,23,40,75 scheinen zu passen, hier sieht man im Spektrum die Datenpakete, die per NRF gesendet werden. Die DTU scheint auch regelmäßig alle Kanäle zu bedienen - ob der Inverter immer auf dem selben Antwortet oder ob die Pakete redundant sind kann ich noch nicht sagen. Im Zeitverlauf kann man die Datenpakete auch schön sehen, allerdings bin ich mir nicht sicher ob der Universal Radio Hacker sie richtig dekodieren kann - mir fehlt der Vergleich, welche Daten es denn sein sollen. Dann hab ich mir die DTU mal genauer angeschaut. Alles in allem keine Raketentechnik. -Ein GD32F303 (Gigadevice, ein STM-Klon) mit SPI Flash 25Q128 . -Ein ESP8266 für die WLAN Kommunikation -Ein NRF24LE1E mit 2401C (RF Front End) Nachdem ich die beschriftete SPI-Schnittstelle gesehen habe, dachte ich "Da kann ich ja direkt die NRF-Kommunikation abfangen und mit den Funkpaketen vergleichen" - war aber leider nix, die Schnittstelle wird nicht benutzt. Ich muss jetzt also herausfinden, wo der NRF mit dem anderen uC kommuniziert. Ich vermute mal, dass irgendwo noch eine UART lauert. Den "USB"-Anschluss werde ich mir auch noch genauer ansehen, der scheint nämlich der Beschriftung nach ebenfalls eine UART zu sein. Mal schauen, was die ausgibt. Gibt also noch bisschen was zu tun... Soweit für heute, ich melde mich, wenn ich mehr herausgefunden habe. Schönen Sonntag euch allen.
Hallo Martin, sehr cool. Ich bin leider wehen ständigem Streß auf der Arbeit und Mistwetter nicht weiter gekommen. Ich wollte eines meiner NRF24-Module dicht an den Hoymiles auf dem Dach positionieren. Mal sehen, grad kommt die Sonne raus ... Carsten
Super Martin, wenn etwas brauchbares herauskommt, beteilige ich mich an den Aufwand gern mit einer Spende! Danke an ALLE
Fritzdect schrieb: > Ich hab hier ein Projekt gefunden: > https://github.com/Eule01x/NETSGPClient-for-Hoymiles Sorry, ist oben bereits erwähnt
Ich hab den HM-600 erst bekommen. Sobald er in Betrieb ist, werde ich das Example hier mal auf einem Nordic Board testen. Mal sehen ob dieses Protokoll verwendet wurde: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fesb_users_guide.html&cp=5_0_0_5_2
Ich steige mal wieder mit ein. Folgende Überlegung: wenn dieses Teil über USB eine Programmierschnittstelle hat, könnte man doch die Firmware mittels esptool auslesen. Und es gibt einige Reverse engeneering tools (wie zB Ghidra) , mit denen man wieder C-code generieren kann. Vllt lässt sich darüber etwas über die benötigten Infos wie Kanal, Adressen etc rausfinden.
Angehängte Dateien:
-
rf_signal.png
63 KB -
rf_demod.png
40 KB -
rx_tx.jpg
200 KB -
serial.png
9 KB
Hallo zusammen, ein kleines bisschen bin ich auch weiter gekommen mit meinem Reverse Engineering der DTU. Zuerst musste ich aber lernen, dass das erste Funksignal im meinem oberen Beitrag k*cke aussieht. War nicht richtig abgetastet. Hier ein Bild wie es aussehen muss. Das kann man dann auch schön demodulieren, um daraus die Bitfolge auslesen zu können. Damit muss ich allerdings noch ein bisschen hin und her experimentieren, weil ich nicht genau weiß wie viele Bits der NRF tatsächlich sendet. Deshalb habe ich mir gleichzeitig die Platine noch ein bisschen näher angeschaut. Die im Bild markierten Testpunkte sind Rx/Tx einer seriellen Schnittstelle zwischen dem NRF und dem GigaDevice, welche ich mir dann mit dem Logic angeschaut habe - die Baudrate ist übrigens 125.000 Baud/sec. Dadurch erhoffe ich mir Rückschlüsse, ob das Funksignal auch richtig demoduliert wurde - ich habe jedenfalls schon übereinstimmende Sequenzen gefunden. Aber für belastbare Daten und eine saubere Analyse brauche ich mehr Zeit... Wenn ich dann mal weiß, wie viele Byte der NRF sendet werden und was die Adressen sind, versuche ich einen eigenen NRF mithorchen zu lassen. Schönen Rest-Sonntag noch. Gruß, Martin
Danke Martin, mit dem Ansatz hast du eine gute Grundlage geschaffen.
Hallo Martin hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte.
Angehängte Dateien:
-
Enhanced_Shockburst.png
52 KB -
Protokoll_analyse.png
300 KB -
DTU_Protokoll_vorlaeufig.png
7 KB
Hubi schrieb: > Hallo Martin > hast du dir schon das Shockburst bzw enhanced Shockburst Protokoll von > Nordic angeschaut? Dein Abtast sieht danach aus, denn da findet man die > Startsequenz 0x55. Danach sollte eine 3 bzw 5 byte lange Adresse folgen, > und im Fall von enhanced SB ein 9-bittiges (richtig neun!) Kontrollbyte. Hallo Hubi, ja, das Enhanced Shockburst hab ich mir angeschaut - dürfte passen. Ich habe hier mehrere Re-Transmits eines Pakets untereinandergelegt, die sich (halbwegs) sauber demodulieren ließen (bisschen Jitter ist in den einzelnen Bitfolgen). Es tauchen vertraute Zahlenfolgen darin auf, nämlich jeweils die letzten 8 Ziffern (=Hex) der Seriennummern von Inverter und DTU. Siehe Beispiel - möchte meine Seriennummern nicht preisgeben ;-) Die eigentliche RF-Payload ist 27 Byte. Das passt auch zu dem, was der NRF seriell an den Controller schickt - das sind 29 Byte, wobei das erste und letzte Byte immer gleich sind (0x7E..0x7F). Ich vermute mal, die werden als Start- und Endmarker benutzt oder als Commands für den uC. Die Datenrate müsste 250 kbps sein, das habe ich mal mit einem eigenen NRF und einem Sendetest quergeprüft. Ich konnte bisher noch nicht herausfinden, welche CRC verwendet wird und ob die Payload selbst auch nochmal mit einer CRC versehen ist. Als nächstes will ich deshalb untersuchen, welche Daten in der Payload versteckt sind. Da müssten sich ja theoretisch die Leistungs- und Stromwerte finden lassen, die die App anzeigt. Das wird aber nochmal ein größerer Brocken Arbeit... Vielleicht gelingt mit diesen Informationen ja dem ein oder anderen auch schon eine Kommunikation?
Ich lobe mal einen Preis von 50€ aus für einen funktionierenden Clone. Das Biest auf meinem Dach soll mir sagen was los ist;-)
Hubi schrieb: > Dein Abtast sieht danach aus, denn da findet man die > Startsequenz 0x55. Ein 0x55 sagt über das Protokoll eher wenig aus. Das ist eine Standardsequenz, die eigentliche jede Funkübertragung benötigt, damit sich der Empfänger einpegeln kann.
Hallo Martin, hast du in der Spec vom Nordic den Abschnitt von der CRC gesehen: CRC (Cyclic Redundancy Check) The CRC is the error detection mechanism in the packet. It may either be 1 or 2 bytes and is calculated over the address, Packet Control Field and Payload. The polynomial for 1 byte CRC is X8 + X2 + X + 1. Initial value 0xFF. The polynomial for 2 byte CRC is X16+ X12 + X5 + 1. Initial value 0xFFFF. No packet is accepted by Enhanced ShockBurstTM if the CRC fails. Das könnte helfen, die verwendete crc herauszufinden https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
Angehängte Dateien:
-
nrf_sniff.png
7,4 KB -
wireshark_nrf24.png
180 KB
Hallo zusammen, hier mal wieder ein Update zur Protokoll-Analyse. Ich habe nun etwas mehr Durchblick bei der Kommunikation erreicht. Also es ist definitiv das Enhanced Shockburst Protokoll. Das direkt per RadioHacker zu analysieren ist schwierig, da es nicht immer exakt demoduliert wird - hinzu kommen die 9 Bit Status-"Byte", die die erkannte Bitfolge um 1 verschieben ggü. der eigentlichen Payload. Ziemlich unschön. Aber wenn man damit die Randbedingungen geklärt hat, gibt es eine bessere Methode: Sniffen mit dem nrf24sniffer von yveaux. Er hat ein kleines Arduino-Programm für einen Nano mit nrf24, sowie ein Windows-Tool, das mit Wireshark gekoppelt wird - Anleitung auf seiner Homepage, siehe GitHub-Link. https://github.com/Yveaux/NRF24_Sniffer Dazu muss man noch folgende Startparameter wissen: -Die Empfängeradresse des Inverters entspricht den letzten 8 Stellen der Seriennummer, aber umgedreht (Little Endian) - 00 anhängen nicht vergessen, da die gesamte Adresse des NRF 5 Byte lang ist. -Die Datenrate ist 250 kbps, max. Payload 32. Man kann das Tool dann hiermit starten (siehe Screenshot) und bekommt die Datenpakete in Wireshark serviert. Der oben bereits beschriebene Protokoll-Aufbau (innerhalb der Payload) scheint zu passen, eine CRC konnte ich darin nicht ausfindig machen - die des NRF wird mit diesem Tool automatisch geprüft. So konnte ich das was die DTU sendet direkt auf dem Rechner empfangen. Im nächsten Schritt hänge ich einen 2. NRF mit der Adresse der DTU dran, um das was der Inverter zurück schickt abzufangen. Und dann geht es darum, den Inhalt zu identifizieren - einen offensichtlichen Zusammenhang zu den physikalischen Größen habe ich leider noch nicht entdeckt. Scheint aber eine Menge Overhead drin zu sein...
Hallo Martin
ich verfolge sehr intensiv deine "Forschung". Bin gerade dabei, das
ganze mit einem Aruino pro mini und eine nrf24 nachzubauen, aber es
kommt keine Kommunikation zustande, WR antwortet nicht.
Vllt könntest du mir folgendes kommentieren:
(nur zur Info: ich benutze Lib RadioHead, die macht von Hause aus schon
das enhanced SB)
1) wenn mein WR die Ser.Nr. 112233445566 (dezimal), so nehme ich letzte
8 Stellen, also 33445566, daraus in Hex 0x01FE56BE und setzte damit im
nRF die Adresse mit dem byte-Array {BE,56,FE,01,00}, oder muss das 0x00
vorne hin?
2) in der payload setzte ich nach der 0x15 wiederum die Adresse des WR
(BE,56,FE,01) und danach den Rest wie in deinem Bild vom WireShark (72
81 88 ...).
Aber es passiert nichts, keine Antwort vom WR.
Eine Idee? Wenn nicht wartete ich weitere Ergebnisse ab.
mein Punkt 2 ist falsch: ich schreibe die Adresse des WR natürlich in umgekehrter Reihenfolge, also (01,FE,56,BE)
Hallo Hubi, nein, die Adresse des WR nicht in Hex umwandeln sondern direkt (die ist quasi schon Hex). Also aus deiner SN wird Ox66554433 als erste 4 Byte der Adresse für den NRF im Inverter. Plus vermutlich 01 als 5. Byte. Dann die Ox15 als (irgendein) Kommando. Der WR antwortet an dieser Stelle mit 0x95. Danach die Empfangsadresse nochmal richtig rum innerhalb der Payload, sowie die Sendeadresse. Die 72818832 ist die Seriennr. meiner DTU, da kannst du also theoretisch irgendwas nehmen, was du deinem NRF als "DTU"-Adresse gibst. Die 0x80 OB nach den Adressen scheint auch immer da zu sein. Ich weiß noch nicht, wofür das steht. Genauso wenig wie ich bisher über die restlichen 16 Byte weiß...
Martin, Danke für die ausführliche Erklärung. Aber auch damit habe ich bisher keinen Erfolg, leider. Da muss noch irgendwas anderes nicht stimmen, payload dynamisch oder fix, auto ack, ???
Hallo Hubi, ich vermute Mal, dass die "DTU" zuerst eine Initialisierung schicken muss. Habe aber keine Ahnung wie die aussehen muss. Dieses Wochenende komme ich auch nicht mehr dazu weiterzumachen, bin unterwegs... Melde mich, wenn ich mehr weiß.
1 | WLAN Nordic |
2 | 2.4 GHz |
3 | \|/ \|/ |
4 | | | |
5 | +-------+ (A)(?) +-----------+ |
6 | | ESP32 | <------------> | NRF24LE1E | |
7 | +-------+ +-----------+ |
8 | ^ ^ |
9 | | | |
10 | | +----------+ | |
11 | +-----> | GD32F303 | <-----+ |
12 | (B) +----------+ (C) |
13 | |
14 | ABBILDUNG 1: Systemübersicht "DTU" |
Hallo zusammen, ich stelle mir gerade die Frage, welche Wechselrichter ich mir für mein geplantes "Balkonkraftwerk" zulegen soll. Auch für mich wäre eine direkte Kommunikation zum Wechselrichter (ohne Hersteller-"Cloud"-Zwang) sehr attraktiv. Die Ermittlungen von @martin sind sehr interessant. Da ich auch beruflich mit ähnlich aufgebauten Systemen zu tun habe, wollte ich mal darstellen, welche Möglichkeiten ich kenne, solch ein System aufzubauen. Vielleicht hilft das ja, mit der Analyse weiterzukommen. Also: Das "DTU" scheint nach @martins Analyse aus folgenden drei Hauptkomponenten zu bestehen (siehe Abbildung 1): - ESP-12F: Das ist ein komplettes "System on Module" mit ESP8266 Mikrocontroller und integriertem WLAN. Theoretisch könnte die gesammte "Intelligenz" darauf programmiert sein. - NRF24LE1E: Das ist auch ein komplettes "System on Chip": (https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [1]). Es besteht aus einem direkt an einen allgemeinen Mikrocontroller gekoppelten RF-Frontend. Wenn wir auf der Schnittstelle zwischen Controller und RF-Frontend lauschen könnten, hätten wir gewonnen. Aber das wird nix, denn die ist "im Chip". - GD32F303: Der dritte Controller im System. Allein die Tatsache, dass dieser überhaupt vorhanden ist, deutet IMHO darauf hin, dass die "Hauptintelligenz" des "DTU" hierauf implementiert ist. Denn technisch hätten die anderen beiden Subsysteme beide genug Rechenpower/Speicher/etc, um ohne weitere Hilfe die Aufgabe des "DTU" zu erledigen. Belauschen können wir die Kommunikation zwischen den Chips, also die Wege (A), (B) und (C). (A) gibt es vermutlich nicht, wenn der GD32F303 die zentrale Steuerung macht - dann muss WLAN und Nordic nie miteinander reden. Die Kommunikation (B) zum WLAN ist im ersten Schritt vermutlich eher uninteressant. Bleibt also die Verbindung (C) zwischen GD32F303 und NRF24LE1E. Hier können wir nun "Glück" oder "Pech" haben, oder irgendetwas dazwischen: "Glück"-Szenario: Auf dem Mikrocontroller des NRF24LE1E läuft nur eine ganz einfache Software, die eingehende Bytes/Pakete 1:1 an das eingebaute RF-Frontend durchreicht. "Pech"-Szenario: Auf dem Mikrocontroller des NRF24LE1E ist eine Software implementiert, die "Kommandos" vom GD32F303 empfängt, und diese dann selbst in passende RF-Pakete übersetzt. Und eventuell auch mit einem fest im Controller hinterlegten Schlüssel verschlüsselt (die eingebaute Verschlüsselungs-Hardware ist ein Grund, warum man solch ein System so entwerfen würde). Im "Glück"-Szenario hätten wir so gut wie gewonnen. Wir könnten quasi die RF-Kommunkation mitlesen, und sie somit auch mit einem eigenen NRF24LE1E nachbauen. Ganz unwahrscheinlich ist das nicht, denn dieses Szenario ist natürlich (von Herstellerseite) einfacher zu implementieren, als auch noch für den NRF24LE1 "kompliziertere" Software zu schreiben. Und mir scheint, es steht zumindest nirgendwo in der Werbung, dass die Wechselrichter "verschlüsselt" kommunizieren. Meine Frage an @martin wäre also: Kannst Du die Verbindung (C) irgendwo entdecken und darauf mithören? Am wahrscheinlichsten sind das einfach eine RX und eine TX Leitung zwischen den beiden Chips (UART). Der Mikrocontroller hat laut Datenblatt ([1], s.o.) genau eine serielle Schnittstelle, bei dem verbauten 32-pin-Gehäuse sollten die hier sein: - P0.4 (Pin 7): RXD - P0.3 (Pin 10): TXD Auf Deinen Fotos passt das auch insofern, als diese Pins jeweils in ein Via gehen. Da könntest Du mal versuchen, die Leiterbahnen zu verfolgen. Oder direkt da mit einem Tastkopf abgreifen. An einem Oszi sollte sich da schnell ein Signal zeigen und die Datenrate lässt sich dann rausmessen. (Die GND, CVV, ROG, SCK, SI, SO, SCN, RST Kontakte sind vermutlich "nur" die Programmierschnittstelle für den NRF24LE1 und werden im Betrieb keine Daten übertragen.) Jetzt bin ich mal gespannt, ob Ihr mit meiner Analyse übereinstimmt, und natürlich, ob @martin auf den Pins sinnvolle Signale mitlesen kann! Viele Grüße -- Petersilie (sorry, Vorname ist auch "Martin" - davon haben wir schon mehrere in diesem Thread...)
:
Bearbeitet durch User
Hallo Martin/Petersilie ;-) ja, die beiden Testpunkte gehen an die Rx/Tx Pins des NRF24LE1E. Ich habe auch schon die Kommunikation zwischen NRF24LE1E und GD32F303 mit dem Logic Analyzer mitgeschnitten. Es sieht tatsächlich so aus, als würde der NRF nur "stupide" als Transceiver benutzt. Ich vermute, wie du oben beschrieben hast, dass die Logik im Gigadevice sitzt und der ESP ebenfalls nur als Gateway zur Cloud dient. Die DTU stellt übrigens auch permanent ein WLAN zum direkten Zugriff bereit per App (das ist eher unschön, wenn man das Ding dauerhaft im Einsatz hat). Die bisherige Untersuchung zeigt, dass die Pakete "on air" 1:1 den seriellen Datenpaketen entsprechen. Jetzt geht es also darum, aus den seriellen Daten schlau zu werden. Ein paar Randbedingungen konnte ich schon klären, z.B. kommt immer die Seriennummer des Inverters bzw. der DTU im Paket vor (Absender und Empfänger-Adresse). Leider habe ich im Moment wenig Zeit, weiter an dem Protokoll zu forschen. Ich versuche euch demnächst mal eine Excel-Tabelle mit den aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit den Daten bereits was anfangen. (Einschalten der DTU, Verbindung zum Inverter, Regelmäßige Abfrage).
martin schrieb: > Ich versuche euch demnächst mal eine Excel-Tabelle mit den > aufeinanderfolgenden Paketen bereitzustellen, Das wäre spitze. Einfach mitschneiden. Muss nicht aufwendig aufbereitet sein. Eventuell kannst Du auch einfach ein Terminalprogram (HTerm o.ä.) aufzeichnen lassen. Was auch super funktioniert sind diese Saleae Logik-Analyser, falls Du zufällig so einen hast. Wäre doch gelacht, wenn wir bei diesen Erkenntnissen und der Vorarbeit dem Protokoll nicht vollends auf die Schliche kommen würden!
Bin auch dabei, wenn genügend Daten über die Kommunikation da sind, an einem Klon mit zu programmieren. Man müßte halt vom 1. Anschalten der DTU, über Registrierung des WR bis hin zur dauernden Übertragung der Daten von WR zu DTU mal alles aufgezeichnet haben. Verschlüsselt ist da wohl nichts, sonst könnte man die Seriennrn nicht rauslesen. Bin schon ganz gespannt auf die Daten!
Hab mir die Bedienungsanleitungen für die DTUs mal durchgelesen. Sieht mir so aus, als müsse es eventuell gar keine "Verbindungsaufnahme" o.ä. geben. Der DTU sagt man einfach, welche Seriennummern die Wechselrichter haben, und die DTU fragt dann regelmäßig alle eingetragenen Wechselrichter ab. Insofern also "einfach" mal die RX und TX Bytes für einige Zeit mitschneiden (ein ganzer Tag wäre ultimativ), dann sehen wir hoffentlich irgendwelche Muster in der Payload, über die wir dann auf den Inhalt schließen können.
Super Projekt das ihr da Versucht umzusetzen. Ich habe seit ein paar Tagen einen HM700 und eine DTU WLite. Ich habe allerdings sogar das Probelm das die DTU bei mir gar nicht richtig hochfährt und ich nur ein WLAN das AiThinker heisst angezeigt bekomme. Fahre ich ein paar Kilometer weit weg, fährt der Stick hoch und zeigt mir das DTU WLAN an. Habt ihr dazu eine Idee? Eine Alternative zu dem Stick wäre mir auch am liebsten! Die Cloud braucht ja keiner ;) LG Martin
Hab ich mir am Anfang auch gedacht, nur sind fast keine anderen WLAN Signale in der nähe. Hab dann auch schon mein eignes Mesh Wlan abgedreht, bringt keine Besserung. Auch in der restlichen Ortschaft funktioniert es nicht. Nur beim Bahnhof... sehr strange das ganze... Aber egal, ich beobachte eure Vortschritte weiter, der Stick geht aber auf jeden Fall wieder zurück. LG Martin
Hallo, ich würde sehr gerne helfen, da ich auch einen HM-400 habe und dessen Daten auslesen möchte. Ich hab den Thread hier schon verfolgt, aber bisher noch keinen Code gesehen. Wie schafft Ihr es, dass der Wechselrichter antwortet? Ich würde sehr gerne helfen und die Antworten des Wechselrichters auswerten / analysieren. Derzeit bekomme ich aber noch nicht mal eine Antwort.
1 | #include <Arduino.h> |
2 | #include <SPI.h> |
3 | #include <nRF24L01.h> |
4 | #include <RF24.h> |
5 | |
6 | /**
|
7 | * CSN 5
|
8 | * CE 4
|
9 | * MOSI 23
|
10 | * SCK 18
|
11 | * IRQ
|
12 | * MISO 19
|
13 | *
|
14 | * FCC URL: https://fcc.report/FCC-ID/2ARNB-DTUW100
|
15 | * Allowed Frequency: 2403, 2423, 2440, 2461 or 2475MHz
|
16 | * Channel: 1 1 8 10 13
|
17 | * Tested Channels: 1, 3, 6, 9, 11 (FCC)
|
18 | */
|
19 | |
20 | // ---- Radio Setup ----
|
21 | RF24 radio(4, 5); // CE, CSN |
22 | |
23 | // serial no hoymiles: 112234567890
|
24 | |
25 | const uint64_t deviceID[1] = { 0x0987654301 }; |
26 | |
27 | |
28 | // ---- Program Values ----
|
29 | const int unitNumber = 0; // Sets the pair out of the 6 programmed channels |
30 | |
31 | int dataSend = 0; |
32 | int dataReceive = 0; |
33 | |
34 | int channels[5] = {3, 23, 40, 61, 75}; |
35 | |
36 | //============ Send/Recieve Function ============
|
37 | void rxtx() { |
38 | |
39 | for( int i = 0; i < sizeof(channels)/sizeof(channels[0]); i++ ) { |
40 | int iChannel = channels[i]; |
41 | |
42 | Serial.print("rxtx Start"); |
43 | Serial.print(" "); |
44 | Serial.println(iChannel); |
45 | |
46 | uint8_t deadPool = 0x15; |
47 | uint8_t frankCastle = 0; |
48 | int iTx = 0; |
49 | int iRx = 0; |
50 | |
51 | radio.setChannel(iChannel); |
52 | |
53 | radio.printPrettyDetails(); |
54 | |
55 | //Begin Transmission and send for 10ms
|
56 | for (int iTx=0; iTx <= 10; iTx++){ |
57 | radio.stopListening(); |
58 | radio.write(&deadPool, 1); |
59 | delay(1); |
60 | }
|
61 | |
62 | //Begin Receive and listen for 10ms
|
63 | for (int iRx=0; iRx <= 10; iRx++){ |
64 | radio.startListening(); |
65 | radio.read(&frankCastle, 1); |
66 | delay(100); |
67 | }
|
68 | dataSend = deadPool; |
69 | dataReceive = frankCastle; |
70 | Serial.println("RxTx Cycle Finished"); |
71 | Serial.println(dataSend); |
72 | Serial.println(dataReceive); |
73 | Serial.println(""); |
74 | }
|
75 | }
|
76 | |
77 | |
78 | void setup() { |
79 | // ---- Activate Radio ----
|
80 | Serial.begin(115200); |
81 | |
82 | radio.begin(); |
83 | radio.openWritingPipe(deviceID[unitNumber]); |
84 | radio.openReadingPipe(unitNumber, deviceID[unitNumber]); |
85 | radio.setPALevel(RF24_PA_MIN); |
86 | radio.setPayloadSize(1); // Sets payload to 1 byte |
87 | radio.setDataRate(RF24_250KBPS); |
88 | radio.setAutoAck(unitNumber, false); |
89 | |
90 | // radio.printDetails();
|
91 | }
|
92 | |
93 | void loop() { |
94 | // Serial.println("Loop Start");
|
95 | rxtx(); |
96 | // Serial.println("Loop End");
|
97 | |
98 | delay(1000); |
99 | |
100 | }
|
Vielen Dank Marcel
martin schrieb: > Ich versuche euch demnächst mal eine Excel-Tabelle mit den > aufeinanderfolgenden Paketen bereitzustellen, vielleicht könnt ihr mit > den Daten bereits was anfangen. Hallo zusammen, im Anhang findet ihr eine Excel-Tabelle mit Daten die ich vor kurzem aufgezeichnet hatte. Es handelt sich dabei um die INTERNE Kommunikation in der DTU zwischen dem GD32 und dem NRF - die ersten 15 Sekunden nach Einschalten. Diese Daten entsprechen nach meinem Kenntnisstand fast 1:1 der Funkkommunikation mit dem Inverter (siehe Tab 3 in der Excel). Einiges, was ich identifizieren konnte, habe ich bereits markiert - vielleicht könnt ihr weitere Teile entschlüsseln. Leider ist es nicht ganz so offensichtlich, wo sich die Daten zu Strom, Spannung und Leistung wiederfinden lassen. Aber vielleicht könnt ihr mit diesen Infos ja bereits einen NRF mit eurem Inverter kommunizieren lassen. Ich vermute, dass die Kommunikation von der DTU initiiert werden muss, da man dort die Seriennr. des Inverters einträgt. Der antwortet dann nur, wenn er seine Nummer "hört" (ab dem 2. großen Kommunikationsblock im Tab 2).
Hallo Martin, vielleicht eine blöde Frage, aber hast du mal mit einem Hexeditor auf die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Die Aufbereitung in Excel ist Klasse für die Doku, aber für das Handling der Daten finde ich es eher unpraktisch. Vielleicht kannst du auch noch die Rohdaten als Binärfiles zur Verfügung stellen? Da ich mittelfristig eh einen zweiten HM brauche, habe ich gestern einen bestellt. Dann kann ich den "unter den Schreibtisch" legen und komme vielleicht auch weiter. Vom Dach empfange ich keine Daten, bzw. kann sie in all den "Stördaten" nicht identifizieren. Ich würde es dann mal mit HM und dem NRF24 in einer "Blechkiste" zur Abschirmung versuchen. Sendet der HM eigentlich auch Daten, wenn die Panels nichts liefern? VG Carsten
Angehängte Dateien:
-
raw_data_display.png
22 KB
Carsten B. schrieb: > hast du mal mit einem Hexeditor auf > die Rohdaten geschaut? Vielleicht erschließt sich da ein Muster? Hallo Carsten, habe deinen Vorschlag mal mit den vorhandenen Daten umgesetzt, siehe Binary anbei. Mit HxD war auch kein Muster direkt erkennbar, neben dem von mir bereits markierten Aufbau der Datenpakete. Wegen der verschieden Länge der Pakete habe ich diese jeweils mit 00 aufgefüllt - so sieht es wenigstens angenehmer aus ;-)
Marcel schrieb: > Wie schafft Ihr es, dass der > Wechselrichter antwortet? Hallo Marcel, mit einem eigenen NRF hat es bisher noch keiner hier geschafft. Ich hatte mir die DTU ("Data Transfer Unit"?) vom Hersteller gekauft, um damit das Protokoll abzufangen und analysieren zu können. Darin werkelt ebenfalls ein NRF auf den ich mich in meinen bisherigen Texten bezogen habe.
Angehängte Dateien:
Hi, ich bin auch am Überlegen mir eine PV zu kaufen. Die meinsten Angebote sind mit dem HM Wechselrichtern. Für die Integration in meine Hauselektronik will ich aber keine Cloud. Daher kommt mir der Bertrag sehr gelegen. Mal sehen, wo ich helfen kann. Ich hab mir mal die Binärdaten angesehen und noch Werten gesucht, welche normalerweise stabil sind. (Netzfrequenz und Netzspannung) Wenn mich nicht alles teucht, könnten es die Bytes (Big-Endian) im Screenshot sein. Gruß Pascal PS: Hier gibt es noch die Modbus Register der DTU Pro. Vielleicht läst sich daraus etwas ableiten. https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
Angehängte Dateien:
Hi, hab noch was rausgefunden: Das letzte Byte vor dem EOF (0x7F) ist ein CRC8 mit poly=1 init=0 xor=0 Hoffe, dass konnte weiterhelfen. Gruß Pascal
Angehängte Dateien:
Noch mehr Bytes.
Hallo Pascal, sehr gut, das sind schon mal hilfreiche Infos - das erste Byte nach den Seriennummern scheint zu kennzeichnen, welche Werte folgen. Bei den von dir vermuteten Netz-Ausgangsdaten (scheint zu passen) war es jeweils die ID 0x02 an Byte[10].
Hi Martin, mit der 0x02 passt nicht immer. In deiner Excel Datei Spalte AW ist eine Antwort, wo es nicht passt.
Angehängte Dateien:
-
excel.png
28 KB
Hallo Pascal, stimmt. Auf den ersten Blick würde ich vermuten, dass es an der Abfrage durch die DTU liegt. Die 0x80 an Byte[10] heißt wohl lesen - danach folgt i.d.R. die 0x0B für Ist-Werte. In dem von dir genannten Fall (Spalte AW) ist es aber die 0x11. Es dürften also irgendwelche anderen Werte folgen.
Hi Martin, hast du noch mehr Daten zu deinem Wechselrichter? Vielleicht sind es Daten zu Einstellungen, Firmware, ...
Pascal A. schrieb: > hast du noch mehr Daten zu deinem Wechselrichter? > Vielleicht sind es Daten zu Einstellungen, Firmware, ... Hallo Pascal, morgen kann ich dir mehr sagen - heute komme ich nicht dazu, weil mein Wechselrichter leider noch nicht fest installiert ist. Ich würde ihn ja gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn dadurch abschieße...
martin schrieb: > Ich würde ihn ja > gerne mit einem DC-Netzteil testen, habe aber Bammel, dass ich ihn > dadurch abschieße... Spannung im zulässigen Bereich und passende Strombegrenzung - dann kann nichts passieren. Am besten die Spannung niedrig halten damit der MPPT noch nicht arbeitet. Dann kannst du wunderbar verschiedene nahezu konstante Bedingungen schaffen und die zugehörigen Daten untersuchen.
Hallo, ich bin auch interessiert, da eine Anschaffung geplant ist. Ich habe mir die Daten auch mal angeschaut. Der 'PackageCounter' und die drei davorliegenden Bytes sind die Uhrzeit in BigEndian time_t 32-bit => 13.02.2022 13:16:04. Sieht man in der Oberfläche die Today Production / Total Production in Wh? Laut Modbus Beschreibung sollten dies 2 bzw 4byte sein. Interessant sind die beiden vorletzten Bytes vor dem 0x7F; ggf auch eine Art zusätzliche Prüfsumme? Das Byte direkt vor dem 7F ist ja eine CRC8. Hilfreich wäre m.E. auch mal eine andere Seriennummer zusätzlich zu probieren um zu sehen was sich bei der Anfrage hier ändert. VG Frank
Super! Ich habe mal versucht, die bisherigen Erkenntnisse in der angehängten Textdatei zusammenzufassen. Vielleicht gewährt das ja noch neue Einblicke. Gerne erweitern!
Das 1. Init (mit den 8 Nullen) scheint mir eine Broadcast zu sein, aber über welche Adresse wird das verschickt? In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn Adresse WR ist ja noch nicht bekannt, aber der sch... WR antwortet einfach nicht.
Hubi schrieb: > In meinem Testprogramm habe ich's mit der Adresse der DTU versucht, denn > Adresse WR ist ja noch nicht bekannt So wie ich das Verstanden habe gibt man die Seriennummer(n) der WR in der DTU (oder in der Cloud) ein bevor eine Kommunikation möglich ist. Dadurch wäre die Adresse des WR schon bekannt. Aber andererseits antwortet der WR mit der Adresse der DTU. Die ja nicht bekannt wäre wenn die nicht im ersten Frame enthalten wäre. Könntest du ggf. dein Testprogramm sharen? Habe hier einen HM-1500 sowie NRF24 Module. (nur aktuell noch keine Zeit gehabt einen Testaufbau zu machen bzw. Abends ist der WR meist schon aus)
:
Bearbeitet durch User
Anbei mein Testprogramm. Wer will kann es gerne weiterbenutzen und anpassen. Vllt hat ja jmd mehr Erfolg als ich.
Danke für den Sourcecode! Ich mag mich täuschen, aber sollte das hier:
1 | void tele7 () { |
2 | //=============
|
3 | memset (data, 0, 32); |
4 | data[0] = 0x07; |
5 | data[10] = 0x07; |
6 | datalen = 11; |
7 | }
|
nicht eher so aussehen:
1 | void tele7 () |
2 | {
|
3 | memset(data, 0, 32); |
4 | data[0] = 0x7e; |
5 | data[1] = 0x07; |
6 | data[11] = 0x07; |
7 | data[12] = 0x7f; |
8 | datalen = 13; |
9 | }
|
Nachdem im Excel vorher die komplette Payload dargestellt ist müsste doch das 0x7e und 0x7f mit dazu oder verstehe ich was falsch?
Hallo Thomas so wie ich die Excel-Tabelle verstanden habe ist das ein Mitschnitt innerhalb der DTU, also zwischen der "CPU" und dem NRF. Und diese Kommunikation startet mit 7E und endet mit 7F. Aber Martin kann das bestimmt klären.
Wir müssen unterscheiden zwischen (a) den Nachrichten zwischen dem GD32F303 und dem NRF24LE1E [1], und (b) den Nachrichten, die der µC im NRF24LE1E an den darin eingebauten "nRF24L01+"-kompatiblen Transceiver sendet. Martins Radio-Mitschnitt hat bewiesen, dass der "nRF24L01+"-Teil nach dem Nordic "enhanced Shockburst" Protokoll funkt. Dieses beinhaltet insbesondere immer eine Zieladresse. Siehe [1], Kapitel 3.4.3: - Preamble 1 byte - Address 3-5 byte - Packet Control Field 9 bit - Payload 0-32 byte - CRC 1-2 byte Für Shockburst gibt es leider keinen einfachen (d.h. NRF24LE1E-basierten) "Sniffer", um alle Nachrichten mitzulesen. Daher das weiter oben erwähnte Projekt in [2]. Unser Ziel ist ja wohl, mit einem einfachen "nRF24L01+" direkt mit einem/mehreren Wechselrichtern zu sprechen. Dazu müssen wir zu jeder der von Martin zwischen GD32F303 und NRF23LE1E mitgeschnittenen Nachrichten auch wissen, wie diese Nachricht schließlich (als "enhanced Shockburst"-Nachricht) versendet wird. Glücklicherweise scheint es sich herauszukristallisieren, dass die beiden sich sehr ähnlich sind. Alternativ könnte man eventuell an diese Pakete "direkt" drankommen, wenn man im Wechselrichter mitliest - was ist denn dort verbaut? Auch ein NRF24LE1E, oder eventuell ein "nRF24L01+" Transceiver? Ich könnte mir auch gut vorstellen, dass gewisse Nachrichten übernaupt nicht an den Transceiver (und somit in den Äther) gehen, so zum Beispiel die "Init" Nachricht. Vielleicht ist das lediglich eine Nachricht an den NRF24LE1E à la "mach' Dich bereit" oder so? -- petersilie [1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf [2] https://github.com/Yveaux/NRF24_Sniffer
Übersicht erweitert: Nachrichten "02 28 23" und "82 00 03" ergänzt. Sauberer ausgerichtet. Python Beispiel für CRC.
petersilie, du hast recht. Ich hatte verdrängt das auf den NRF24 selbst auch noch Logik vorhanden sein kann. Ich würde jetzt mal unterstellen, dass der WR immer auf seine Seriennummer (= Adresse) lauscht und der DTU ebenfalls auf seiner Seriennummer. In Init 1 (siehe deine Text File) würde die DTU zwar an die Adresse des WR ein Paket senden aber der WR würde nicht wissen an welche Adresse er antworten soll. Dies ginge erst ab Init 2 weil dort die DTU seine eigene Adresse an den WR schickt. Bei der Durchsicht des Datenblattes [1] ist mir noch etwas im Kapitel 3.4.3.3 aufgefallen. Dort wird u.a. das No Acknowledgment flag beschrieben. Im Post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" wird beschrieben das das PCF 0D8 (== b011011000) ist. Was ja bedeutet das NO_ACK 0 ist. "Setting the flag high, tells the receiver that the packet is not to be auto acknowledged." Es ist low, also muss AutoAck true sein. Das wäre zumindest etwas was mir im Code von Hubi aufgefallen ist. Ebenso wird im oben genannten Post beschrieben das Channel 3 verwendet wird.
1 | radio.setAutoAck(true); |
2 | radio.setChannel(3); |
[1] https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf
Ich hab mir jetzt mal solche NRF24-Platinchen geordert. Wir kennen die verwendeten Adressen. Somit können wir doch einen NRF24 auf die gleiche Adresse konfigurieren wie den Wechselrichter. Dann sollte der doch genau die Pakete von der DTU empfangen, oder was meint ihr? Damit hätten wir dann einen 1:1 Mitschnitt der tatsächlichen Pakete in die Richtung DTU --> WR. Später drehen wir das Spiel um, und konfigurieren den NRF24 auf die Adresse des DTU. Und hören wiederum zu. Eventuell macht das "auto-ACK" Probleme - das man eventuell empfängerseitig nicht abschalten kann. Aber vielleicht reicht es, den "Zuhörer" schön weit weg zu platzieren, damit das ACK vom echten Empfänger gewinnt. Leider habe ich (noch) keinen WR/DTU. Lieferprobleme überall. Wenn das mit den NRF24 klappt, könnte ich eventuell einen vorkonfigurierten Raspi zur Verfügung stellen, den dann ein stolzer Besitzer einer DTU (Martin?) mal lauschen lassen könnte... Hubi hat ja wohl auch nur einen WR, aber keine DTU. Da ist nach den bisherigen Erkenntnissen mit Zuhören allein wohl leider nichts zu holen, da der WR ohne passende Frage auch nie antwortet.
Angehängte Dateien:
-
Comm_Schema.png
130 KB
Hallo zusammen, gestern hatte ich versucht, den Wechselrichter mit einem Netzteil zu speisen - leider hat mir der MPP-Regler dazwischengefunkt und es hat sich kein stabiler Arbeitspunkt eingestellt. Ich glaube, es wird doch endlich mal Zeit für ein ordentliches Labornetzteil... Freut mich, dass hier so viele helfen, das Protokoll zu knacken. Aber ich glaube, es herrscht hier noch ein bisschen Unklarheit über die von mir bereitgestellten Daten. Deshalb nochmal ein Schema zur Klarstellung. Die obige Excel/Binärdaten zeigen die serielle Kommunikation innerhalb der DTU! Der NRF24LE1E ändert diese Pakete nochmal ab, bevor er sie an den Inverter rausschickt, inklusive Neuberechnung der CRC8. Die Initialisierungssequenz dürfte also nur dazu da sein, den NRF24LE1E mit den benötigten Adressen zu versorgen. Die erste Kommunikation "on air" beginnt dann erst nach den 3 Init-Sequenzen - das wäre der Ansatzpunkt, den jeder mit einem Inverter und ein paar NRF24 Modulen mal in Angriff nehmen könnte: -Enhanced Shockburst (ist voreingestellt) -CRC 2 Byte -250 kbit -Kanal 3, 23, 40, 61 oder 75 -Paketlänge 27 Byte -Empfänger-Adresse: Letzte 8 Stellen Inverter Seriennr. BCD in "Little Endian" Und wenn dann das im Bild dargestellte Datenpaket gesendet wird, müsste euer Inverter theoretisch antworten.
Macht er aber nicht!
Ich habe folgendes
15 72 60 79 52 72 81 88 32 80 B 0 62 9 4 9B 0 0 0 0 0 0 0 0 2 29 31
an addrWR[5] = {0x52, 0x79, 0x60, 0x72, 0x01} gesendet, aber das
Drecksding muckst sich nicht.
Meine Seriennummer WR ist xxxx72607952.
Die 31 ist die CRC8 der vorangehenden Bytes.
Das sollte doch alles passen!?
Hallo Hubi, ja, die Sequenz sieht m.M.n. richtig aus. Hast du es mal auf den anderen Kanälen probiert? Ist das in deinem Beispielcode enthalten? Dann könnte ich es mal bei mir probieren. Oder es könnte doch noch weitere Inbetriebnahmeschritte geben. Vielleicht wird die DTU-Adresse bei der Einrichtung per S-Miles App im Inverter gespeichert? Dazu müsste ich das ganze Setup nochmal neu machen, während ich die Pakete mitschneide.
Habe alle Kanäle ausprobiert, aber nix. Vllt ist auch die Entfernung zum WR zu groß. Sende hier vom Wohnzimmer durch Glastür in Richtung Gartenhaus mit dem WR aufm Dach. Im Anhang nochmals das Testprogramm. Als RF24 Lib benutze ich die von TMRh20 und die CRC-Lib findet man hier https://github.com/RobTillaart/CRC (bin zu blöd um Link einzufügen)
Hello all, First of all, I don´t speak german, so I am following this thread using google translator, it´s not a problem for me. I have a DTU-W100 and five MI-1500 microinverters. I have flashed a Logitech Unifying Dongle with the firmware from this repo https://github.com/BastilleResearch/nrf-research-firmware I left it running on channels 1,3,6,9,11,23,40,61 and 75 for all night, I don´t know if logged packages came from PV system. The dongle is a bit far from the MI and DTU, but today morning I put it about 2-3 meters from two MI-1500 and now I waiting for new data, but the code use DWELL for channel scanning, so probaly I am losting some packages. If anyone need a specific channel scanner or sniffer or any other test, I can help in my spare time. I hope this project will go forward!
Hi Arnaldo, Welcome to the party! Thanks for offering to help out with scanning/sniffing, and thanks for providing some results already! Looking at the received packets, it seems to me that these are unlikely to be coming from your MI-1500s for the following reason: I think we have already established that the devices (DTU/MIs) use the last 8 decimal digits of their respective serial numbers converted to BCD code as their "Shockburst" address. This implies that the address will never contain any of the hex digits A...F. From your list, this only leaves a handful (if your hand happens to be six-fingered, that is) of packets, but these don't look familiar:
1 | [2022-03-10 19:17:25.477] 11 21 55:15:57:55:BD 9A:AA:A8:2A:AA:AA:AA:AA:A2:97:AA:6A:AB:A9:AE:EA:AE:DA:79:2B:AA |
2 | [2022-03-11 04:14:56.172] 3 4 22:34:55:93:10 4C:01:2E:77 |
3 | [2022-03-11 05:46:00.747] 6 0 24:01:05:45:0B |
4 | [2022-03-11 06:17:57.783] 75 1 14:01:51:14:25 25 |
5 | [2022-03-11 07:00:49.999] 75 0 03:24:85:46:EA |
6 | [2022-03-11 07:06:58.018] 3 18 23:85:84:40:1F 23:5D:89:FA:D8:D5:B5:54:FA:FA:BA:A7:AC:90:C5:55:A8:C7 |
However, knowing the address that the inverters use means that we should be able to "sniff" specifically for packets to/from those addresses. I am not familiar with the "nrf-research-firmware" tools, but it appears to me that you might be able to use the "nrf24-sniffer.py" tool to specifically follow packets sent to/from a particular address. If your DTU serial number is, say, xxxx12345678, then this address should be 0x78,0x56,0x34,0x12 (possibly followed by 0x01 - not sure about that). But first, let's see what today's data contains! Very excited about this project gaining more participants. -- petersilie
Hello Arnaldo, thanks for the dump. I can see that your dump was mainly during the night. If i’m correct, the Hoymiles is not active in the night because the required start voltage is not generated by the solar panels. It would be beneficial if you try to “sniff” during a more or less sunny day. Even the last 5 byte pairs of your devices and DTU could be helpful for analyzing the dump. Thanks a lot Marcel
@hubi,@tbnobody Zumindest was den Kommentar in Zeile 35 (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") angeht ("// !!!! muss false sein sonst klappt senden nicht") kann ich Euch glaube ich beruhigen. Das Senden geht nicht schief, wenn Auto-ACK aktiviert wird. Vielmehr gibt die write()-Funktion zurück, ob ein ACK empfangen wurde (true), oder eben nicht (false), siehe [1]. Somit geht zwar das Senden nicht schief (das Senden gelingt wohl laut Spezifikation "immer"), aber der WR antwortet nicht (mit einem ACK). [1] https://nrf24.github.io/RF24/classRF24.html#a4cd4c198a47704db20b6b5cf0731cd58
@martin Bist Du sicher, dass die Pakete 5-Byte-Adressen verwenden, und nicht etwa nur vier? Mir fiel nämlich auf, dass "Shockburst" das Einstellen der Adresslänge (zwischen 3 und 5 Bytes) zulässt. Die RF24-Lib hat dazu die Funktion setAddressWidth() ([1]). Es scheinen ja nur die letzten 8 Dezimalziffern der Seriennummer in die (ersten vier Bytes der) Adresse umgesetzt zu werden. Bisher haben die Versuche oben dann als fünftes Byte ein "0x01" genommen, aber wo kommt das her? Hast Du das so auf dem Funk gesehen, oder ist das geraten? [1] https://nrf24.github.io/RF24/classRF24.html#ad5aea7f9a3bd9c7d357fb296ce751f21)
Hallo Petersilie habe mir den Source-Code angesehen und bin zu gleicher Erkenntnis gekommen. Mich hat halt nur gestört, dass das Senden immer das Ergebnis false lieferte. Aber was ist nun besser fürs testen, mit AutoACK=TRUE und Ergebnis=false oder doch besser Ack abschalten? Frage weil du halt geschrieben hast dass wohl AutoAck eingeschaltet ist laut deiner Mitschnitte (im PCF)? Bist du da sicher?
Was "besser" ist, ist eine gute Frage. Tatsache ist, es ist sehr unwahrscheinlich, dass der WR antworten wird, wenn er nicht einmal ein ACK sendet. Insofern würde ich sagen, es ist "besser", mit eingeschaltetem AutoACK zu arbeiten. Die Mitschnitte sind von einem anderen Martin - insofern muss ich die Frage weitergeben, ob das ACK-Bit in der beobachteten Kommunikation wirklich gesetzt ist, oder nicht... -- petersilie
I attached the log from today, I think tomorrow I will listen just on channel 1, or if someonte have another idea please tell me. @parsley it´s my first time using the nrf-research-firmware tools, so I am trying to do something that can help, I need to identify a address and after it sniff just this address with nr24-sniffer.py. To add a MI in hoymiles plataform you need to use the serial number of the MI so, I think, it is used to reach the device using the serial number. @Marcel yes, the dump was done in the night, because I flashed the dongle after the work and leave it running to try to catch something... today I got a few packages, I really don´t know if it´s working as expected, but the main reason, I think, is because the DWELL for each frequency, tomorrow I will leave it on channel 1 and after I post the result here again.... last 5 bytes of the serial DTU and the nearests MI1500 DTU: 35453 MI1500: 36590 MI1500: 14456
@arnaldo_g Your nrf-research sniffing efforts are much appreciated. This certainly has the potential to be very helpful indeed. Unfortunately, there might yet be some obstacles to overcome: I noticed that the "nrf24-scanner.py" uses "promiscuous mode" (which by itself seems to be a major hack, see posts above). This should not necessarily be a problem, since we think we know the addresses of the devices involved, and can therefore listen for packets specifically addressed to these. But to make matters worse, it seems to me that the on-air bitrate is hardcoded to 2 MBit/s (https://github.com/BastilleResearch/nrf-research-firmware/blob/02b84d1c4e59c0fb98263c83b2e7c7f9863a3b93/src/radio.c#L41). The Hoymiles inverters communicate at 250 kbit/s, so until you can switch the sniffer to that lower bitrate, you won't be seeing any meaningful data.
@martin, hattest du auch schon den traffic zwischen WR und DTU "in the air" mitgeschnitten? Ich frage mich nur, ob da das 5. byte auch immer 0x01 ist wie bei der Kommunikation zwischen DTU und WR. Nicht das hier noch ein Problem liegt
@arnaldo_g Another quick note regarding addresses. You helpfully list the serial numbers of your devices: > last 5 bytes of the serial DTU and the nearests MI1500 > DTU: 35453 > MI1500: 36590 > MI1500: 14456 However, you will need the last 8 (not 5) digits to determine the address: > DTU: 35453 --> Address will be 0x53,0x54,0x?5,0x?? (,0x01) > MI1500: 36590 --> Address will be 0x90,0x65,0x?3,0x?? (,0x01) > MI1500: 14456 --> Address will be 0x56,0x44,0x?1,0x?? (,0x01)
Hi! @petersilie, you are right the datarate is wrong! Thanks for the support, I recompiled the firmware for 250K and flashed the dongle again, and now I am seeing some packets with the serial numbers of MI, see the attached file, now I think we can go forward, I know the data is update at Hoymiles every 15 minutes the last number in address is always xx:xx:xx:xx:01. The dongle with this results is far from the MI, I will take it close again. If anyone have a idea to what channel/address to scan I can provide it.
Brilliant!!! These all appear to be messages from your DTU (serial number ...70:53:54:53) to various inverters. They're all 11 Bytes long, and we're not seeing any replies. Maybe some sort of "ping"? Are your inverters running? Not sure why we think that the DTU only communicates on the given channels (1 3 6 9 11 23 40 61 75). My guess is that maybe the channels are selected based on serial number. Or maybe they are switched dynamically somehow... Maybe you could try monitoring "all" available channels? Not sure how well that will work though - since at any given moment in time you will likely be looking at the "wrong" channel!
@petersilie @arnaldo_g, if all the messages are from the DTU towards the inverter we have a new message id. In this document: https://www.mikrocontroller.net/attachment/549922/hoymiles-datenformat-r2.txt and also in martins excel the MID 0x83 was only shown as a response form the inverter towards the DTU. But now we see 0x83 also from the DTU towards the inverter. 0x82 seems to be completly new
My inverters are running, attached a new log from a closest place with more log. This is the DTU: [2022-03-12 09:17:15.329] 40 0 90:65:23:74:01 I am running a scanner on all channels, but it´s seens losting a lot of package, I will leave it running for some hours and post here after!
Thanks Arnaldo, just to clarify. In an older post you wrote, that your serial number of your DTU ends with 35453 ? > DTU: 35453 > MI1500: 36590 > MI1500: 14456 But in your last post, you wrote "90:65:23:74:01". For me there are no similarities. Would you be so kind and give us the last 8 digits of the serial number from your DTU and your Hoymiles please ? Thanks a lot for your work Marcel
Marcel, Sorry I made a mistake, is not that line, see below, you can see it in last log nrf24_4.txt file, the serial is 70535453. [2022-03-12 09:16:58.926] 23 0 53:54:53:70:01 this is another MI. [2022-03-12 09:17:15.329] 40 0 90:65:23:74:01
Angehängte Dateien:
I just wrote a small parser to analyze the data from @arnaldo_g. It's maybe easier to find some logic in the channel selection. Unfortunatly it seems that all messages from the inverters to the DTU are empty.
:
Bearbeitet durch User
Correct, the reason for this result is that arnaldo is using the scanner. This one only shows the connections between the devices. Based on the code it analyses only the first bytes of the protocol. Arnaldo (@arnaldo_g) can you use the ./nrf24-sniffer.py. I'm not quite sure about the params. Maybe ./nrf24-sniffer.py -a 90:65:23:74:01 or ./nrf24-sniffer.py -a 53:54:53:70:01 I think this should result in a more detailed output. Marcel
Yes, sure I will run! Attached is a scanner in all channells with a DWELL of 10s.
Hi all!
seens the firmware for the dongle have some hardcoded parameters, I
leaved it running for about a hour and nothing was catch by sniffer,
after I analysed the code and change another point to 250K, maybe it
need some ajusts to sniff the packages.
I also changed (in radio.c / line 388) to RATE_250K recompile and
reflashed the device, but running "./nrf24-sniffer.py -a 36:49:51:70:01"
nothing is recorded...
// 2Mbps data rate, enable RX, 16-bit CRC
configure_phy(EN_CRC | CRC0 | PRIM_RX | PWR_UP, RATE_2M, 0);
If anyone is familiar with the radio and it´s parameters can look the
code, maybe can help more!
If someone have a idea please let me know to try again....
Grasping at straws here, but you could try reversing the order of the bytes to the -a parameter:
1 | ./nrf24-sniffer.py -a 01:70:51:49:36 |
(The source code reverses them before passing them on to the underlying layer "enter_sniffer_mode()", but it appears to do no such thing when printing the results coming from there.)
Martin G. schrieb: > Grasping at straws here, but you could try reversing the order of the > bytes to the -a parameter: > >
1 | ./nrf24-sniffer.py -a 01:70:51:49:36 |
> > (The source code reverses them before passing them on to the underlying > layer "enter_sniffer_mode()", but it appears to do no such thing when > printing the results coming from there.) Martin, about a hour running and nothing was logged..... root@retropie:/home/pi/nrf-research-firmware/tools# date Sat 12 Mar 17:09:04 -03 2022 root@retropie:/home/pi/nrf-research-firmware/tools# ./nrf24-sniffer.py -a 01:70:51:49:36
Hallo um sichern zu sein, dass meine Pseudo-DTU (Arduino ProMini + nRF24L01) funzt, habe ich mir ein Testprogramm geschrieben, das den WR simuliert. FDaten kommen an, ich setzte das Bit 8 und sende an die "DTU" zurück. Und die kriegt das auch, zwar nicht bei jedem Senden, aber wenigstens kommt was an. Und ich bin sicher, dass meine Hardware funktioniert. Aber weiterhin kommt von richtigen WR aufm Gartenhaus nix. Ich vermute entweder eine spezielle Einstellung der RF24-Parameter oder eine spezielle Sequenz von Telegrammen von DTU->WR. Meine RF24-Parameter sind: Kanal 3 Speed 250000 kbps payload=27 autoAck=true adressbreite=5 Sollte doch passen, oder?
Angehängte Dateien:
-
ali-002.jpg
24 KB -
ali-001.jpg
21 KB -
ali-003.jpg
24 KB -
ali-004.jpg
25 KB -
ali-005.jpg
18 KB
Hallo, eine Frage an diejenigen, bei denen es scheinbar schon ein bischen klappt mit dem Senden / Empfangen: Welches nrF24 Modul nutzt Ihr ? Es gibt ja verschiedene ? Ich wollte mir eines bestellen. Danke. Einen schönen Sonntag wünsche ich Dir / Euch.
ich habe hier ein ali-005 @Hubi: das mit der Kanalauswahl ist sehr seltsam. Weil bzgl. der Dumps von @arnaldo_g scheinen ja alle möglichen Kanäle involviert zu sein. Wann welcher ausgewählt wird ist mir noch nicht klar.
Hallo, Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen der Beiträge durch den Kopf ging: nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are used. In nrf24_4.txt we have a lot of packages with the address of the DTU and zero payload. Could this be ACK packages from the DTU to the WR? When the WR answers, could it be, that it uses the address of the DTU? However we see only data from the DTU. Maybe the usb sniffer has a 'weak' antenna. @arnaldo_g Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, 75, 83 but put the sniffer as near as possible (minimum wall in between) to one of the MIs? @hoymiles-datenformat-r3.txt Regarding the first xlsx from martin I think []=Spekulation: 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)] 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02] VG Frank
Frank H. schrieb: > Hallo, > Ich warte auch noch auf meine Hardware; hier einiges was mir beim Lesen > der Beiträge durch den Kopf ging: > > nrf24_5.txt from Arnaldo shows me channel 3, 23, 40, 61, 75 & 83 are > used. > In nrf24_4.txt we have a lot of packages with the address of the DTU and > zero payload. Could this be ACK packages from the DTU to the WR? > When the WR answers, could it be, that it uses the address of the DTU? > However we see only data from the DTU. Maybe the usb sniffer has a > 'weak' antenna. > @arnaldo_g > Could you repeat what you did for nrf24_4.txt for channel 3, 23, 40, 61, > 75, 83 but put the sniffer as near as possible (minimum wall in > between) to one of the MIs? > > @hoymiles-datenformat-r3.txt > Regarding the first xlsx from martin I think []=Spekulation: > 0x80 "Zeit setzen", Antworten (Anfragetyp 0x0B): [0x01, 0x02, (0x83)] > 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 > 0x82 "Anfrage AC-Daten", erwartete Antwort: [0x02] > > VG > Frank Hi Frank, I tried the sniffer in the same place but I can´t get anything, I think the code for the sniffer have something different... The distance for the DTU is about 3 meters and for 1 MI is about 1 meter, for another MI 1,5meters and the others is about 4-5 meters.... the wall is just a thin wooden about 4-5mm..... Yes the antenna of the sniffer is tiny, it´s a logitech unify dongle, but for 250k and the frequency it´s should work nice... When using the dongle with the logitech keyboard I can go far and it´s still working.... Also I have tried some changes on scripts and code of the nrf-research-firmware but no luck, I think the sniffer is not working, maybe because the CRC, payload or another radio configuration....
Hi! More one log, I think it will not help anything, but just to see the difference, I changed the script parameters and run it, then I runned the original code.....
I agree with arnaldo_g, fh_, etc. There might well be some setting that we're missing - therefore we're not seeing the packets we expect to see. CRC and Baud Rate settings seem fine to me. Not sure what to do about the different channels. Until we figure out how the devices "hop" between channels, we will miss packets. But we should be able to see at least some. It would be interesting to see if the inverters always stay on the same channel, or if they switch channels... "martin (Gast)" seems to have the most insight into how the RF side of things work. Maybe he has some more ideas? Also, maybe the Logitech dongle isn't quite the same as an "NRF24L01+", and the nrf-research-firmware definitely has some quirks. I bought some NRF24L01+ modules and will try to interface them to a RaspberryPi. This might give better results. @arnaldo_g - do you have any NRF24L01+ modules that you could try instead of the Logitech dongle?
Hi Martin, I have a Nrf24l01 module that I buyed, and put on my drawer to wait the results, when I found this forum.... :) After that I found the nrf-research-firmware, and I found a Logitech dongle that can run it... And started with some test and put the results here... This Logitech dongle model C-U0007 seens to have a NRF24L01+ IC, but I don´t have much time to code a new firmware and try....
Another thought: Could we try to "ping" the known addresses, cycling through "all" channels? I believe the NRF24s should answer to a "ping" (empty payload) all by themselves. I should be able to try this with my NRF24s in a couple of days' time.
Hi Guys, sorry for my late reply - I have a roof reconstruction going on at home, so little time for playing with my inverter and no panels installed at the moment ;-) As I mentioned in my post Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" I got good results with the NRF sniffer from yveaux. Since you have dedicated addresses and CRC checked packages, you can filter out a lot of garbage. Downside is, that you can only sniff one side of the communication (per computer - so I have to setup a second one to sniff both sides). As you can see in the wireshark screenshot, the packets are acknowledged. So ACK is on. @Arnaldo: I would limit sniffing to the channels 3/23/40/61/75 since these are approved in the FCC report and I have verified them with a spectrum analysis. see: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" My guess(!) about the channels is, that the information is redundant. That would mean, the DTU hops to every channel and transmits the same information - to have a chance of getting data even in wifi contaminated areas. So for the beginning, it should be sufficient to focus on one channel. A first glance at the RF data on channel 23 instead of 3 seems to support my guess.
Angehängte Dateien:
-
last2bytes.png
3,7 KB
Hi everyone, I started another quick test without the inverter (DTU trying to connect), to compare the serial data on the DTU with the RF packets sniffed with Wireshark. An important part in the request by the DTU seems to be coded in the last 2 Bytes before the CRC8. They alter with the time stamp, but I have no idea what they encode. Maybe some flags?
Hi, I also join the party as I'll receive soon a HM-600 inverter. I don't favour cloud services and try to keep my data in-house. Concerning the last two bytes before the CRC: Is that lower nibble of the first byte always "B"? To me it seems unlikely to put changing flags in an initial connect request which contains the same data besides the changing time stamp. IMHO it could be 1. some kind of pseudo random number (drawn from an internal µC counter) and used as a packet number. In this case the answer of the inverter should include somewhere the same number. or 2. some kind of authentication, e.g. a ciphered time value using a shared secret between the DTU and the inverter. just an idea... ;-)
or 3. Yet another CRC/"checksum"? (It changes whenever the content changes.) In that case: how is it calculated? Since it doesn't change when the source address gets swapped out by the µC, if it is some kind of checksum, it is likely only influenced by the bytes following the address information. Have we ever seen a reply from the inverter in response to a 0x80 message? That might give us some more clues.
Angehängte Dateien:
Success! Thanks, @docbmuc and @martin (Gast)! I cycled through some predefined CRC functions. Turns out our mystery bytes are the same type of CRC as used by the "Modbus" protocol, see picture. Works for all the examples in "martin" (Gast)'s SerialData_RFSniff.xlsx, and for the one I originally documented in hoymiles-datenformat-r3.txt. New revision of said document attached.
Hallo Martin, das heisst Du hast es jetzt geknackt? :-) Bin gespannt, hier wartet auch nich ein HM-1200 DTu werde ich mir keine kaufen - eher kommt der ganze Hoymiles-Schrott weg...
Amazing! Based on @petersilie info I adjusted the test program. I cannot test it at the moment (lack of sun) but the crc calculation should work as expected. Maybe it helps someone. (used libraries are also documented in the platformio.ini file) I tested the source with an ESP32
:
Bearbeitet durch User
@petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter oben [1]. Dort ist ein ESP-12F abgebildet. [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Thomas das setzen des CRC16-Polynom in Zeile 66 kann aber nicht ganz stimmen, das sind mehr als 16 bit. Und wenn ich nur 0x8005 und bei online-CRC16M Rechnern eingebe kriege ich nicht das gewünschte Ergebnis. Vllt bin ich auch etwas irritiert. Ich bin ganz g... auf deine Klarstellung und dann werde ich morgen wieder meinen ProMini bruzzeln bis er durchbrennt oder endlich eine Antwort kommt.
Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut Spitze wie sich das hier entwickelt. Auf meinem Vordach sonnt sich ein HM-600 und wartet darauf seine Daten preiszugeben. Ein NRF24-Modul ist im Zulauf, also bin ich hier auch bald bereit zum Mitspielen 😉 Mit freundlichen Grüßen Matthias
Hallo Hubi, jetzt hast du mich etwas blank erwischt :) Also in Python klappt es so:
1 | import crcmod |
2 | f = crcmod.mkCrcFun(0x18005, initCrc=0xFFFF, xorOut=0x0000) |
3 | payload = bytes((0x0B,0x00,0x62,0x09,0x04,0x94,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00)) |
4 | print(hex(f(payload))) |
Das Ergebnis ist wie erwartet: 0x229 (Wichtig ist hier, dass die kompletten 14 byte angegeben werden) Und auch hier wenn man es im Online Calculator eingibt erscheint das korrekte Ergebnis: https://crccalc.com/?crc=0B00620904940000000000000000&method=CRC-16/MODBUS&datatype=hex&outtype=0 Die 0x18005 habe ich aus der Doku von crcmod: http://crcmod.sourceforge.net/crcmod.predefined.html
:
Bearbeitet durch User
Sorry Thomas, mit 0x8005 passt es doch
Angehängte Dateien:
-
crc_modbus.png
110 KB
Hallo Martin, perfekt - damit wissen wir jetzt das komplette Anfrage-Paket. Ich habe auch nochmal ein paar Datenpakete überprüft, es passt auch für das Paket ausgehend von der DTU mit 0x11 anstatt 0x0B im ersten Byte (nach den Adressen). In den Antworten vom WR habe ich die Modbus-CRC bisher aber nicht entdecken können. Für diejenigen, die ihre CRC-Berechnungsfunktion oder weitere Pakete prüfen wollen, siehe Einstellungen für HxD im Screenshot. Thomas B. schrieb: > Maybe it helps someone. (used libraries are also documented in the > platformio.ini file) > I tested the source with an ESP32 @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. War gestern Abend aber auch nicht sicher, ob die Speisung mit Netzteil funktioniert hat - zumindest hatte der WR mal grün geblinkt... Matthias B. schrieb: > Ich lese hier schon ein paar Tage mit und ich muss sagen das ist absolut > Spitze wie sich das hier entwickelt. @Matthias, ja ich bin auch begeistert, wie das hier Fahrt aufgenommen hat ;-)
Habe mit meinem Testprogramm (mit CRC16) bisher auch keinen Erfolg, es kommt einfach keine Antwort. Ich vermute, da fehlt die richtige Initialsequenz. Ein Mitschnitt der Kommunikation vom Einschalten der DTU an wäre bestimmt sehr hilfreich.
Ich habe mir jetzt auch mal diese Logitech Dongles von Arnold geholt. Ich bin mir irgendwie nicht sicher, was die NRF library raus sendet. Ich hab das Gefühl, die fügt noch was hinzu. Ich teste dann mal mit meinem ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht vorstellen, das es eine genaue Schrittfolge geben soll. Marcel
Thomas B. schrieb: > @petersilie noch ein Hinweis zu deinem Text Dokument. Es handelt sich um > einen ESP8266 und nicht um einen ESP32. Sieht man auf den Bildern weiter > oben [1]. Dort ist ein ESP-12F abgebildet. > > [1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Du hast natürlich Recht, danke. Ich werde das anpassen.
Marcel schrieb: > [...] > Ich teste dann mal mit meinem > ESP - weil ich denk, der WR müsste so langsam mal antworten, weil die > einzelnen Calls sind ja "entschlüsselt". Kann mir fast gar nicht > vorstellen, das es eine genaue Schrittfolge geben soll. Dass es eine genau einzuhaltende Reihenfolge geben soll, scheint mir auch unwahrscheinlich. Ich denke aber, der WR wird (für längere Zeit/nur) auf einem der verfügbaren Kanäle zuhören. Und vielleicht nur jede Stunde oder so den Kanal wechseln, wenn er in der Zeit nichts sinnvolles empfangen hat. Die DTU, bzw. unsere Version davon, muss also zuerst mal auf allen Kanälen ein "PING" schicken, um zu sehen, ob der WR vielleicht zufällig gerade auf diesem Kanal zuhört. Erst dann sind weitere Anfragen überhaupt sinnvoll. Die DTU scheint das nach den Logs hier im Thread ja auch so in der Art zu machen. Ich meine, im Datenblatt zum NRF24 gelesen zu haben, dass ein "0-Payload"-Paket wie ein "PING" funktioniert, d.h. die Gegenstelle wird brav mit "ACK" antworten. Vielleicht könnten wir als ersten Schritt probieren, solch einen "PING" auf die jeweils bekannte(n) Seriennummer(n) auf allen Kanälen zu programmieren? Danach stellt sich die Frage, welche Anfrage wir dann schicken sollten. Die mit der Uhrzeit ist eventuell nicht die hilfreichste - welche Antwort erwarten wir denn darauf? Wie wäre es mit der "Nachricht 0x81: DTU an WR: "Anfrage DC-Daten""? Da würde ich dann die DC-Daten als Antwort erwarten.
:
Bearbeitet durch User
Einfach anfangen klingt sinnvoll :) Ich habe auch gesehen es gibt einen Dynamic Payload Length Modus. Im Excel von martin haben wir ja verschieden lange Pakete. Das Payload control field in [1] war 0x0d8 = 11011000 Laut Kapitel 7.3.3.1 in [2] ist wird die Payload Length (6 bit lang, siehe Kapitel 7.3.3) nur verwendet wenn die Dynamic Payload Length function aktiv ist. Vielleicht ist das auch noch ein Punkt der zum Erfolg fehlt... Hätte an meinem Code das hier geändert:
1 | //radio.setPayloadSize(27);
|
2 | radio.enableDynamicPayloads(); |
[1] Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" [2] https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf
:
Bearbeitet durch User
Hallo, was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 Frequenzen abgeklappert werden. "Channel List 2403, 2423, 2440, 2461, 2475MHz" Nur einen Channel zu testen bringt doch nix bzw. wäre Zufall, das der WR genau da horcht. Ich kenne mich mit "C" leider nicht so aus. Ich vermisse da jedenfalls eine Schleife die alle 5 Frequenzen abcheckt. @Petersilie: Vielleicht mal die Frequenzen in r6 mit aufnehmen :-) Viele Grüße an Alle, die hier mitarbeiten.
:
Bearbeitet durch User
Herbert K. schrieb: > was ich bisher in dem einen Sourcecode vermisse ist, das alle 5 > Frequenzen abgeklappert werden. Siehe Anhang... hatte das bei mir schonmal implementiert aber aktuell hats keine Sonne :-(
Nur zur Info: bei irgendwelchen neuen Erkenntnissen über die Kommunikation klappere ich mit meinem Testprogramm alle bekannten Kanäle ab. Bin mal gespannt wie oft ich noch bruzzeln kann, bis der uC die Krätsche macht.
Hallo, Marcel schrieb: > int channels[5] = {3, 23, 40, 61, 75}; > 35 mit diesen Kanälen hatte ich damals immer getestet und habe diese dann irgendwann mal auf int channels[9] = {1, 3, 6, 9, 11, 23, 40, 61, 75}; angepasst. Alle Informationen, die hier im Forum herausgefunden wurden, habe ich in meinem Script angepasst und immer auf diesen Kanälen getestet. Leider bisher noch kein Erfolg in Form von einem ACK oder sogar Statistiken vom WR. Marcel
Marcel schrieb: > Alle Informationen, die hier im Forum herausgefunden wurden, > habe ich in meinem Script angepasst und immer auf diesen Kanälen > getestet. Hast du die dynamicPayload auch schon getestet oder erst alle Dinge die vor heute Abend hier standen? Ich halte das aktuell für vielversprechend.
Bin zwar nicht angesprochen, aber DynamicPayload und Payload 27 (siehe Erkenntnisse irgendwo oben) probiere ich ständig abwechsenld aus.
@martin (Gast), hattest du schonmal versucht mit einem NRF24 den WR zu pollen? Falls die DTU im initialen Setup $Dinge im WR einstellt damit dieser antwortet, müsste das ja bei dir passiert sein und er sollte dann auch einem "eigenen" NRF24 antworten?
martin schrieb: > @Thomas, ich habe den Code getestet, erhielt aber keine Antwort vom > Wechselrichter. Allerdings ist in deinem Code ACK auf Off und Kanal 11 > eingestellt - ein Wechsel auf Kanal 3 brachte aber auch keinen Erfolg. Hallo Thomas. Ja, ich hatte es getestet - leider ohne Erfolg. Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und NRF24 - sobald es etwas neues gibt, melde ich mich.
Angehängte Dateien:
-
1647617263224.jpg
120 KB -
1647617263215.jpg
270 KB
martin schrieb: > Ich arbeite parallel auch gerade an einem Testsetup mit Arduino Nano und > NRF24 Also meine bisherigen Versuche mit eurer als auch eigener Software sind fehlgeschlagen - obwohl 2 NRFs miteinander Pingpong spielen (Funkmodul tut also). Aber was ich sagen kann, der Inverter lässt sich mit einem 24V Netzteil (nominal 2,5 A/60W) speisen und funktioniert dann auch. Das ermöglicht mir zumindest auch mal Abends zu testen. Pascal A. schrieb: > hast du noch mehr Daten zu deinem Wechselrichter? > Vielleicht sind es Daten zu Einstellungen, Firmware, .. @Pascal, hier noch die Daten, die ich dir schuldig geblieben bin -> Siehe Screenshot.
kann es vielleicht sein, daß die eigenen NRF24L01 1 Mbps statt 256kbps nutzen. Meiner jedenfalls will trotz Programmierung nach den SDR-Aufnahmen keine 256kB senden. Liegt aber evtl auch an mir ?
NRF24L01 = 1 MHz u 2 MHz NRF24L01+ = 256 K u. 1 u 2 MHz (ohne Gewähr)
Herbert K. schrieb: > NRF24L01 = 1 MHz u 2 MHz > NRF24L01+ = 256 K u. 1 u 2 MHz daran liegts dann bei mir bzw. meinen Modulen. Ich werd mir 24LE01 bestellen, wie sie verwendet werden.
Mit Interesse lese ich hier schon seit ein paar Tagen mit. Mein WR (ein HM600) kommt hoffentlich im April, die nrf24 Module sind schon da. Laut Datenblättern sieht es tatsächlich so aus, dass der nrf24L01+ die 250kbit/s kann: https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf#page24 Der nrf24L01 (ohne +) kann nur bis 1Mbit/s runter: https://www.mouser.com/datasheet/2/297/nRF24L01_Product_Specification_v2_0-9199.pdf Ich bin gespannt, wie es weiter geht und hoffe dass ich demnächst auch ordentlich mitmischen und programmieren kann sobald der WR da ist
Hallo, ich habe mir mal zwei NRFs aufgebaut und der eine sendet die Daten so, wie der WR sie eigentlich empfangen soll und wie es hier im Forum gepostet wurde. Den zweiten NRF habe ich mit einer Scanner logig beschrieben (https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183). Dieser Scanner findet auch ein paar valide Nachrichten in meinem Umfeld - aber leider nicht die, die ich mit dem anderen NRF sende. Dazu habe ich im Scanner mal nur den channel = 3 (und im while loop das channel++ auskommentiert) eingestellt und der 2. NRF sendet auch aller 140ms auf diesem Kanal. Sind wir denn sicher, das die CRC Berechnung korrekt ist (ich bin leider kein Experte in Bit Operatoren und Bit Verschiebung). Zeile, die prüft ob die CRC die empfangen wurde auch einer Berechnung stand hält befindet sich hier: https://github.com/insecurityofthings/uC_mousejack/blob/master/src/main.cpp#L183 Marcel
Ein anderer Ansatz: man könnte versuchen, die Firmware aus dem nRF24LE1 auszulesen. Die SPI-Schnittstelle dafür ist auf der DTU-Platine beschriftet. Sollte das Flash nicht lesegeschützt sein, könnte man sich die Initialisierung/Kommunikation mit dem RF-Kram via Disassembler ansehen. Zum Auslesen gibt es verschiedene Möglichkeiten: FTDI FT232R: https://github.com/jdelfes/nrf24le1_flasher
1 | nrf24le1_flasher --read-flash readout.bin |
RaspberryPi: https://github.com/derekstavis/nrf24le1-libbcm2835
1 | nrf24le1 show |
2 | nrf24le1 read firmware readout.bin |
Arduino: https://github.com/DeanCording/nRF24LE1_Programmer/blob/master/Read_Mainpage/Read_Mainpage.ino
Mein Wechselrichter ist angekommen!
Leider bisher ohne DTU ("Lieferschwierigkeiten" - große Hoffnungen habe
ich nicht).
Mein Testsetup besteht aus 2 RaspberryPis mit jeweils einem NRF24L01+
Modul.
Auf einem Pi läuft der "pretender", der sich wie ein WR verhalten soll.
Auf dem anderen Pi läuft der "discoverer", der nacheinander eine
Testnachricht an alle einprogrammierten Seriennummern auf allen Kanälen
sendet, und jeweils anzeigt, falls er ein ACK zurückbekommt.
Der "discoverer" findet auch brav den "pretender", auch wenn ich diesen
zwischendurch auf einen anderen Kanal wechsle.
ABER mein Wechselrichter antwortet nicht.
Das führt mich zu folgender Schlussfolgerung:
Der Auto-ACK-Modus ist Wechselrichter-seitig vermutlich doch nicht
aktiv.
Hat jemand auf der Funkschnittstelle schon mal wirkliche ACK Pakete
gesehen? Das "nACK" Bit im "PCF" sagt ja nur, ob der RF-Transceiver das
Paket bestätigen soll, sofern Auto-Ack eingeschaltet ist. Wenn das
nicht der Fall ist, wird er auch keine Bestätigung senden, egal welchen
Zustand das nACK Bit hat.
Ich habe mal ein Github-Repo für die Hoymiles-Kommunikation angefangen.
Vielleicht können wir das gemeinsam erweitern?
Mein Quellcode liegt hier: https://github.com/grindylow/ahoy
Ein zielführender nächster Schritt wäre, zu versuchen, einen 'pretender'
als weiteren Wechselrichter an eine DTU anzulernen.
Dann sollten wir sehen, welche Pakete die DTU an die entsprechende
Seriennummer schickt, und können von dort Stück für Stück die weitere
Kommunikation beobachten. Hat jemand die Möglichkeit, das
auszuprobieren?
@arnaldo_g, do you think you might be able to program your receiver to respond to the same address as one of your inverters? That way it should receive the queries from the DTU directly, without us having to guess what the sniffer tool may or may not be doing to the received packets. Also, at night, the inverters will stop replying, but traffic to the 'pretend' receiver should continue.
Hallo zusammen, ich habe hier nochmal ein paar Captures zusammengestellt, vielleicht hilft es dem Projekt ja weiter, wenn da noch jemand anderes draufschaut. Es sind .sal (Saleae Logic) Captures der seriellen Schnittstelle in der DTU. Und .pcapng (Wireshark captures) mit dem yveaux NRF24 sniffer, jeweils auf den bekannten Adressen. Interessanterweise antwortete der Inverter nur auf einem Kanal von den 3 betrachteten. Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung stellen, diese können im Universal Radio Hacker geöffnet werden. Sind aber mehrere Hundert MB groß, deshalb nur auf Anfrage. Ich vermute, dass die DTU alle Kanäle durchtestet und wenn der Inverter antwortet, diesen Kanal dann weiterhin verwendet. Kann das aber im Moment leider nicht verifizieren, da der Java Spectrum Analyzer seit dem Firmwareupdate des HackRF nicht mehr tut... Schönen Sonntag noch.
Hallo in die Runde, ich möchte eure interessante „Forschung“ nicht stören, habe aber vielleicht einen hilfreichen Hinweis: Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese zuallererst bei der Basis registrieren musste, bevor eine Kommunikation möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn man eine andere DTU verwenden wollte, musste man den WR zuerst de-registrieren und dann neu registrieren. Die Registrierung erfolgte mit der Master-ID, der Seriennummer der DTU. Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ erfolgen.
Angehängte Dateien:
martin schrieb: > Ich kann auch noch die dazugehörigen RF-Scans vom HackRF zur Verfügung > stellen, diese können im Universal Radio Hacker geöffnet werden. Sind > aber mehrere Hundert MB groß, deshalb nur auf Anfrage. Hallo Martin, solche RF-Aufnahmen, z.b. als IQ-File, wären sicher am besten. Da würden ganz kurze Ausschnitte davon mit den Sendungen ja voll ausreichen. Die könnte man dann selbst demodulieren, falls nötig. Als Anhang eine demodulierte Sendung von meinen Versuchen. Ich hab da momentan kein 16-bit CRC dran. Ist dieser immer vorhanden beim Senden ? ( da die demodulierte Sendung nicht mittig liegt, hab ich eine relativ große Frequenzabweichung. Da muß ich den Quarz am NRF noch besser abgleichen) Gruß golf
:
Bearbeitet durch User
Angehängte Dateien:
-
stream.png
7,3 KB
Hallo zusammen. Ich habe auch zwei Hoymiles Modulwechselrichter und eine DTU Lite. Ich habe mir nun, inspiriert durch die bisherigen Inhalte, zwei NRF24L01+ Module besorgt und diese mit einem Arduino nano gekoppelt. Ein Modul bekommt als Adresse die Adresse der DTU, das andere die Adresse eines der Wechselrichter. Damit schneide ich den Datenverkehr zwischen DTU und Wechselrichter mit. Ich nutze dazu den yveaux NRF24 sniffer in abgewandelter Form. Zunächst ist dabei nur ein Daten Durcheinander herausgekommen. Wenn man allerdings den gelesenen Nutzdaten Stream jeweils um ein Bit nach links verschiebt, sieht das Ganze ein wenig besser aus. Meine DTU hat die Adresse 0x50908172. Die Wechselrichter haben diese Adressen: WR1 0x19461073. WR2 0x39441073. Am Beispiel eines empfangenen Rohdatenstreams wird aus:
1 | 01-6C-4A-B9-88-23-0C-B9-88-23-0C-80-80-00-80-AC-00-AE-02-55-00-AB-00-AA-82-46-00-00-5A-17 |
Beim Schieben des ganzen Streams um ein Bit nach links diese Bytefolge:
1 | 02-D8-95-*73-10-46-19-73-10-46-19*-01-00-01-01-58-01-5C-04-AA-01-56-01-55-04-8C-00-00-B4-2E |
Ab Byte 3 wird darin zweimal hintereinander die Adresse eines der Wechselrichter gesendet. Allerdings wird die Wertigkeit gedreht, aus 0x19461073 wird 73-10-46-19. Wende ich dies auf die empfangenen Streams an und formatiere es ein wenig, so tauchen an den Stellen im Stream nur die bekannten Bytefolgen der Adressen auf, allerdings in umgekehrter Reihenfolge. Siehe Anhang. Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen Seriennummern bestätigen?
Super! Tolle Mitschnitte und Erkenntnisse! Das mit dem Verschieben um 1 Bit macht Sinn, da das "Enhanced Shockburst"-Protokoll seinen Vorgänger, das "Shockburst"-Protokoll, um ein 9-bit "Packet Control Field" erweitert. Alles nach diesem "PCF" erscheint dann um ein Bit verschoben. So wie ich das verstehe, arbeitet der "Sniffer" im "normalen" Shockburst Modus, wo man dem Chip wohl beibringen kann, auch Pakete durchzuleiten, die nicht CRC-geprüft sind. Eventuell gehen allerdings dafür die letzten Bytes verloren, das würde erklären, wenn Dir am Ende die protokoll-eigene CRC fehlt. Shockburst ist wohl auf 30 Bytes beschränkt, und da gehen die 5 Adressbytes noch weg, also können 27 Byte lange Nachrichten inkl. CRC evtl. nicht mehr ganz gelesen werden. Das ist aber kein Problem, denn wenn wir so weit sind, können wir die Nachrichten ja auch im echten "Enhanced Shockburst" Modus mitlesen. Zu Deiner Nachricht: Das passt super. Mit den verschobenen Bits ergibt sich nämlich direkt die Nachricht [0x01: WR an DTU: "Aktuelle DC Daten"], siehe hoymiles-datenformat-r5.txt.
1 | 02-D8-95-*73-10-46-19-73-10-46-19*- [01-00-01-] |
2 | 01-58- 01-5C- 04-AA- |
3 | 01-56- 01-55- 04-8C- 00-00- B4- 2E xx |
Dein WR Seriennummer xxxx73104619 sieht * Auf Kanal 1: 34.4 V; 3.48 A; 119.4 W * Auf Kanal 2: 34.2 V; 3.41 A; 116.4 W Die Bedeutung der anfänglichen [01-00-01] kennen wir noch nicht genau. Die erste 01 ist vermutlich ein Befehlscode.
:
Bearbeitet durch User
Angehängte Dateien:
Oliver F. schrieb: > Kann jemand dies anhand seiner aufgezeichneten Streams mit seinen > Seriennummern bestätigen? Hallo Oliver, ja, das sieht vertraut aus. Ich erkenne darin die bereits analysierte Paketstruktur wieder. Man sieht die Anfrage von der DTU mit der Kennung 0x15, danach das übliche 0x80 0x0B, die Unix-Zeit 0x62... Die Antwort vom Inverter beginnt mit 0x95 und enthält die Daten wie Martin G. oben schon aufgeschlüsselt hat. Was mir hier und auch in meinen Daten aufgefallen ist: In den Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun haben, der für die Antwort verwendet werden soll? Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden, wenn die DTU nach dem Inverter "sucht". Demnächst werde ich noch aufzeichnen was passiert, wenn der Inverter dann antwortet. Anbei noch wie von golf angemerkt eine kurze Sequenz auf Kanal 40 als IQ File zur Analyse mit dem Radio Hacker.
Angehängte Dateien:
-
NRF_Block3.JPG
180 KB -
NRF-Block_MomentanFM.JPG
88 KB
vielen Dank Martin für deine Aufnahmen. Es reicht eigentlich eine Realwandlung des IQ-Files, um die Bits abzulesen. Auch der Momentanfrequenzverlauf ist sehr sauber.
B. G. schrieb: > Auch der Momentanfrequenzverlauf ist sehr sauber. Hallo golf, mit welchem Programm hast du die Auswertung auf dem zweiten Bild gemacht? Die Bits sieht man hier viel deutlicher, als bei der Auswertung mit dem Universal Radio Hacker (URH). Durch die Verschiebung der Daten um 1 Bit wegen des 9-Bit Packet Control Fields ist auch die Hex-Ausgabe im URH nicht wirklich hilfreich. Ich hatte mir deshalb mit folgendem Excel-Template beholfen - ist natürlich Quick & Dirty, da die Bits nicht immer 100% passen, aber mir hat es definitv weitergeholfen, den Signalaufbau besser zu verstehen.
martin schrieb: > mit welchem Programm hast du die Auswertung auf dem zweiten Bild > gemacht? Hallo Martin, das ist alles von mir mal in Delphi selbst geschrieben im Programm für meinen Eigenbau-SDR. Ich hab auch einen Modulator gebaut, damit hab ich deine Aufnahme einfach wieder mit dem SDR empfangen können. Leider bringen Dir die Programme nichts ohne die Hardware dazu. Ich hab die Aufnahme erst auf 16 bit gebracht und als Wave gespeichert, da mein SDR nur 16 bits verarbeitet. Das Programm für die Complex to Realwandlung könnte ich evtl versuchen anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise demodulieren.
emhopa schrieb: > Hallo in die Runde, > > ich möchte eure interessante „Forschung“ nicht stören, habe aber > vielleicht einen hilfreichen Hinweis: > Bei den Letrika-WR mit wireless M-Bus war das so, dass man diese > zuallererst bei der Basis registrieren musste, bevor eine Kommunikation > möglich war. Anschließend sprach der WR nur noch mit dieser DTU. Wenn > man eine andere DTU verwenden wollte, musste man den WR zuerst > de-registrieren und dann neu registrieren. Die Registrierung erfolgte > mit der Master-ID, der Seriennummer der DTU. > > Bei der Hoymiles-DTU könnte das eventuell im Installationsschritt „H“ > erfolgen. So etwas dachte ich Anfangs auch. Ich mag mich täuschen, aber es sollte doch zumindest bei @martin (Gast) funktionieren, da bei ihm ja die Seriennummer der DTU schon im WR registriert sein müsste.
Liest sich wie ein Krimi. Ich drücke Euch die Daumen. Tolle Teamarbeit.
Finde ich auch! Ich drücke die Daumen. Mein DTU-loser Hoy HM-400 würde sich sehr gerne mit einem billigen Nachbau einlassen!
Angehängte Dateien:
B. G. schrieb: > Das Programm für die Complex to Realwandlung könnte ich evtl versuchen > anzupassen an die 8-bits vom HackRF. Das kann auch wahlweise > demodulieren. Ich hab mal eine 1.Version meines Complex2Real Wandlers mit opt. Demodulation versucht, die auch die HackRF Files bearbeiten kann (.complex16s). Ich selbst habe keinen HackRF, nur meine Eigenbauten. Leider machen die aktuellen Delphi-Compiler auch aus einem kleinen Programm gleich Megabytes. Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von martin. Die Ausgabe des Programms ist immer ein Wavefile.
:
Bearbeitet durch User
Angehängte Dateien:
-
protocol.png
73 KB
B. G. schrieb: > Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten > Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von > martin. Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner Analyse-Excel.
gut daß es soweit funktioniert. bei den bei mir vorliegenden Hf-Aufnahmen sind nur Blöcke vom Inverter. sendet der DTU denn auf einer anderen Frequenz ? gibts HF-Aufnahmen oder demodulierte Sendungen vom NRF24 des DTU, die wären interessant ?
:
Bearbeitet durch User
Hallo golf, anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. Die zugehörigen seriellen Pakete und Wireshark Captures hatte ich bereits oben angehängt jeweils unter "Session 1". Wer wann auf welcher Frequenz sendet scheint momentan noch eines der größten Rätsel zu sein. Bei meinem Test am Sonntag spielte sich das meiste offenbar auf Kanal 40 ab. emhopa schrieb: > Wenn > man eine andere DTU verwenden wollte, musste man den WR zuerst > de-registrieren und dann neu registrieren. Die Registrierung erfolgte > mit der Master-ID, der Seriennummer der DTU. Ja, das kann schon sein - aber bei mir sind die beiden Teilnehmer bereits registriert. Also sollte doch theoretisch irgendwas durchkommen?
martin schrieb: > B. G. schrieb: >> Vielleicht ist das ja für jemand nützlich. Das Jpg mit der demodulierten >> Bitfolge entstand aus der Datei 'HackRF_session2_2440MHz.zip' von >> martin. > > Vielen Dank, habe es gleich mal getestet. Die Signale lassen sich damit > deutlicher ablesen als mit dem URH - hier mal ein Vergleich in meiner > Analyse-Excel. Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen Auswertungen war das doch immer 0x01?
Thomas B. schrieb: > Was mir hier auffällt ist, dass Addr[0] Null ist. Bei den vorherigen > Auswertungen war das doch immer 0x01? Hallo Thomas, ja ist mir auch aufgefallen. Ebenso bei Olivers Daten: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" In den Wireshark Captures allerdings nicht, da ist Addr[0] = 0x01.
Angehängte Dateien:
martin schrieb: > anbei ein Mitschnitt auf Kanal 23, wo beide Teilnehmer beteiligt waren. was mir aufgefallen ist. Da ist im Frequenzbereich noch ein 2 Inverter aktiv. Wenn ich die Samplerate mit 20 Mhz richtig interpretiert habe, dann sendet der 3 Mhz tiefer. Jpg ist Teil der auf Real gewandelten Aufnahme. sowas wie Start, $32,88,81,72,01, 011011000, $95,72,22,02,00,72,22,02,00, $01,00,01,00,E4,01,64,03,2D,00,02,00,02,00,00,00,00,3A,33,41.. wenn ich mich nicht verschaut hab. Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ?
B. G. schrieb: > Ist es so, daß die NRFs immer diese Wiederholungen machen, wie es sich > darstellt, oder sieht das nur so aus wegen dem Schnitt der Aufnahmen ? Also die Pakete werden tatsächlich ein paar mal im Block so gesendet. Das ist vermutlich das automatische Retry, die Pause zwischen den Paketen beträgt ca. 1 ms. 3 MHz tiefer wäre dann Kanal 20? Ist das tatsächlich ein Signal oder kann das ein Fehler von meiner SDR-Messung sein? Das wäre natürlich ein wichtiger Hinweis, wenn der Inverter gar nicht auf den gleichen Kanälen antwortet wie die DTU...
martin schrieb: > kann das ein Fehler von meiner SDR-Messung sein? da der 2. NRF-Sender gleichzeitig (etwas verzögerter Start) mit auf der Aufnahme ist muß das so stimmen, auch die Frequenzen. Vorausgesetzt daß meine Annahme der Samplerate mit 20 Mhz stimmt. (gewandelte Realfiles haben bei meinem Programm dann immer doppelte Samplerate, da aus dem IQ-Stereo File ein Monofile wird). Aber ich hab das wohl falsch beschrieben. Es dürfte wohl so sein, daß auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz tiefer (2420 Mhz) der Inverter antwortet. Das Verhalten läßt sich bestimmt mit neuen Aufnahmen prüfen. Ob die Abweichnung der beiden Sendefrequenzen immer gleich bleibt, muß man sehen. (Ich weiss allerdings nicht, ob der HackRF irgendwas gemischt hat in diesen Bereich, da ich den nicht kenne, glaub das aber eher nicht).
:
Bearbeitet durch User
Angehängte Dateien:
-
HackRF_session1_2423MHz.png
120 KB
B. G. schrieb: > Es dürfte wohl so sein, daß > auf der Spektrummitte (2423 MHZ) der DTU sendet und hier dann 3 Mhz > tiefer (2420 Mhz) der Inverter antwortet. Im Universal Radio Hacker (UHR) sieht es für mich so aus, als ob auf der Spektrummitte zwei Sender unterwegs wären. Einer mit stärkerem Signal (DTU, weil näher am HackRF?) und ein schwächerer (Inverter?).
Angehängte Dateien:
Hallo Daniel, das stimmt schon. Ich weiss halt nur nicht, ob das alles Aufnahmeschnipsel sind von mehreren Aufnahmen oder ob das alles am Stück auf der 2423 Mhz so statt gefunden hat. Das sind ja immmer nur kleine Teilstücke. Das kann nur Martin beantworten. Da wäre evtl so ein Bild eines Sonogramms einer Aufnahme aussgefähiger ohne ausgeschnittene Stellen.
:
Bearbeitet durch User
Angehängte Dateien:
Da wäre z.b. ein Sonagrammbild des ganzen Ablaufs ( der Aufnahme ) evtl aussagefähiger ohne die Aussetzer. Oder nimmt der HackRF squelchgesteuert auf oder sowas ? Ich lass bei mir immer die Aufnahmen durchlaufen (geht theoretisch bis die platte voll ist) ohne Sampleverluste. Hab hier nur keine DTU-Signale. Nachtrag: doppelt gesendet, das ist was schief gelaufen bei mir
:
Bearbeitet durch User
@martin (Gast) - könntest Du vielleicht die großen Originalcaptures bei einem Filesharing-Dienst hochladen? Wetransfer kann zum Beispiel kostenlos bis 2 GB. https://filetransfer.io/ wohl bis zu 6 GB.
Hallo Martin, golf und Daniel, leider war mein Studienschwerpunkt Automatisierungstechnik, deshalb bin ich bei den HF-Themen nicht ganz so fit - was heißt Squelch? ;-) Anbei die 3 Mitschnitte bei 3, 23 und 40 MHz als komplette Files (zeitgleich aufgenommen wie die Logic und Wireshark Captures). https://filetransfer.io/data-package/1Z2bKt05#link Samplerate und Bandbreite je 20M (samples/s bzw. Hz). In der RF-Aufnahme ist viel Mist dazwischen, weil Inverter und DTU ja offensichtlich immer zwischen den Kanälen hin und her wechseln und halt unvermeidlich WLAN oder sonst was in der Gegend rumfunkt. Kann das "Doppelbild" daher kommen, dass ich gleichzeitig zwei Arduino/NRF24 Sniffer mitlaufen habe lassen? Theoretisch müssten diese doch rein passiv zuhören, oder?
Angehängte Dateien:
-
test_setup.png
31 KB
Hier zum besseren Verständnis noch ein Bild, wie bzw. was ich gemessen hatte mit allen Teilnehmern. 3 Versuche auf den jeweiligen Frequenzen (2403, 2423 und 2440 MHz).
Angehängte Dateien:
-
HackRF_0_2403_Mhz__NRFs_auf_ca_2403_Mhz___mehr_als_2_Umtastfrequenzen_erkennbar.JPG
65 KB -
HackRF_0_2403_Mhz_2_NRFs_auf_ca_2403_Mhz_und_ca_2402_Mhz.JPG
52 KB -
HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG
79 KB -
HackRF_1_2423Mhz_2_NRFs_auf_ca_2423_Mhz_und_ca_2420_Mhz.JPG
74 KB -
HackRF_2_2440Mhz_2_NRFs_auf_ca_2441_Mhz_und_ca_2443_2_Mhz.JPG
75 KB -
HackRF_2_2440Mhz__NRFs_auf_ca_2441_Mhz__2441_5_und_ca_2443_Mhz.JPG
66 KB -
HackRF_2_2440Mhz__1_NRFs_auf_ca_2441_Mhz.JPG
68 KB -
HackRF_2_2440Mhz__1_NRFs_auf_ca_2443_Mhz.JPG
72 KB -
HackRF_2_2440Mhz_2_NRFs_auf_ca_2441_Mhz_und_ca_2443_Mhz.JPG
77 KB
hallo martin, squelchgesteuerte Aufnahmen nehmen nur auf, wenn ein bestimmter Empfangspegel überschritten wird. Aber bei dem HackRF kann das Verhalten auch durch die 8-bit bedingt sein, das sind jedenfalls für mich teils recht ungewöhliche Aufnahmen. Es gibt NRFs mit teils sehr unterschiedlichen Pegeln, dann bricht die Aufnahme teils abrupt ab. Das sind Aussetzer, weil der PC mit der Datenrate überfordert ist. Die 40 MB/sec sind halt ziemlich das Maximum für USB2, was geht. Evtl zur Sicherheit mal bei weiteren Aufnahmne die Sniffer-NRFs aus lassen. Bei kurzer Durchsicht gab es mehrere Stellen mit verschiedenen Frequenzlagen. bei der 2403 wurde teilweise fast auf der gleichen Frequenz gesendet. Dann sieht man scheinbar mehr als 2 Umtastfrequenzen. Siehe Bilder bei dem HackRF_1_2423Mhz_1_NRF_auf_ca_2420_Mhz.JPG sind wohl auch 2 NRFs fast auf der gleichen Frequenz. Scheinbar auch mehr als 2 Umtastfrequenzen. Muß näher untersucht werden
:
Bearbeitet durch User
Angehängte Dateien:
die unterchiedlichen Pegel der einzelnen NRFs verwundern etwas.
Angehängte Dateien:
Beim Überfliegen der Aufnahmen mit "inspectrum" (zum Öffnen: *.complex16s in *.cs8 umbenennen) ist mir angehängter Abschnitt aufgefallen. Zwei verschiedene Sender? Ein Paket mit Länge 27 und cmd=0x95 (-> Inverterdaten) und das andere ein 0-Byte-Paket - ist das ein ACK? Vielleicht vom Sniffer-NRF?
Angehängte Dateien:
Ich meine auch, daß da diese Sniffer vielleicht mitmischen. Anbei eine grobe Darstellung der Blöcke auf den Frequenzen mit diversen Pegeln. Ob die Blöcke von DTU/INV oder teilweise von den Sniffern sind ? Bei den beschriebenen Blöcken mit mehr als 2 Frequenzen scheint der Sender irgendwie instabil, sieht eher nicht nach 2 NRFs aus. Vielleicht sollten wir auf eine neue Aufnahme warten ohne die Sniffer-NRFs.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, leider habe ich keine DTU um mitzumischen. Warum versteift Ihr Euch so auf den HF Teil ? Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation zwischen dem GD... und dem nRF ? Einen Logic Analyzer da dran, der gleich die Kommunikation dort decodiert ? Mann müsste vielleicht mal alles in den Werkszustand versetzen. Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA loslaufen lassen. Wer weiss, ob die ganzen Register vom nRF überhaupt schon zu dem passen, was hier durch obige Programme und LIBs gemacht wird ? Vielleicht ist es nur 1 Bit in irgendeinem Register, was noch nicht passt ? Ist nur so eine Überlegung von mir. Ich will niemanden einen Vorwurf machen (falls sich jemand auf den Schlips getreten fühlt) ! ! ! ! Danke an alle, die schon eine DTU haben und Ihr Bestes geben ! ! ! Foto ist von (C)Martin. Nur die Aufmerksamkeit.
Herbert K. schrieb: > Warum geht Ihr nicht direkt an die "digital" PINs für die Kommunikation > zwischen dem GD... und dem nRF ? Das wird schon so gemacht, siehe weiter oben. Aber der verwendete NRF ist nicht nur ein Transmitter, sondern auch ein Mikrocontroller. Die Kommunikation zwischen GD und NRF lässt deswegen nicht direkt auf das HF-Geschehen schließen. Was aber noch nicht versucht wurde: versuchen, ob der Flash vom NRF auslesbar ist. Siehe meinen Vorschlag: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Herbert K. schrieb: > Bevor der DTU überhaupt per USB mit Spannung versorgt wird, schon den LA > loslaufen lassen. Ich schlage vor, kurz vor der Stromversorgung des DTUs jeweils HF-Aufnahmen zu starten. Evtl auch mit etwas weniger Samplerate, damit es weniger Aussetzer gibt. Nach ein paar Aufnahmeversuchen müßte man zumindest die Start-Sequenz(en) des DTU finden können. Vielleicht kommt man dann etwas weiter. Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ?
:
Bearbeitet durch User
Gute Idee! Und am besten auch mal ohne die Sniffer-NRFs, nicht dass wir uns mit deren ACKs oder dergleichen verrennen.
B. G. schrieb: > Aber evtl sind ja so diese vorhandenen Aufnahmen entstanden ? Hallo golf, ja, tatsächlich sind die so entstanden, zumindest was die DTU betrifft und die Kanäle 3 und 23. Man sieht das auch gut an den seriellen Aufnahmen. Die UART-Pegel sind zunächst auf Low, gehen dann auf High und dann kommt die Initialisierung des NRF24LE1E (3x Request/Response). Danach beginnt das Suchen nach Invertern. Kanal 40 habe ich dann im laufenden Betrieb aufgenommen, nachdem ich gemerkt hatte, dass da mehr los war. Bei allen Versuchen war der Inverter vorher schon an, da er immer eine Weile braucht bis er initialisiert ist.
Angehängte Dateien:
Hallo zusammen. Eine Frage an alle die hier fleißig die HF Daten analysieren. Ich habe, wie bereits gesagt, auch einen NRF24 Sniffer am Laufen. Leider kann dieser nur auf die eingestellten Adressen lauschen. Der Chip unterstützt mehrere Datapipes. (Siehe Anhang) Ich denke, die WR werden eine Datapipe betreiben, mit deren Seriennummer als Adresse. Es muss aber noch eine andere Pipe geben mit einer Art Broadcast Adresse, die für alle WR gleich ist?!? Ich komme darauf, weil ich mehrmals den Hochlauf der DTU gesnifft habe. Sinnvolle Kommunikation sehe ich nur auf den Kanälen 3, 23 und 40, wobei die DTU auf Kanal 40 sehr selten vertreten ist. In diesem Beispiel ist es so, dass die Wechselrichter (C1) auf einmal anfangen zu senden, ohne dass zuvor ein Telegramm von der DTU an die Wechselrichter (C3) zu sehen ist. Ich habe das ganze relativ häufig auf den einschlägigen Kanälen probiert. In der Regel sind die ersten Telegramme immer WR=>DTU, ohne dass ich eine initiale Aktion der DTU sehe. Die Bedeutung der einzelnen Spalten habe ich versucht im Anhang zu dokumentieren.
1 | C1 026566496 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
2 | C1 026570128 00 0590817201 0006 00 3 EA5A EA5A |
3 | C1 026573400 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0966138916E2542173 2173 1 |
4 | C1 026595440 00 0590817201 0000 00 0 8A9C 8A9C |
5 | C1 026597740 00 0590817201 0002 00 1 AADE AADE |
6 | C1 026613740 00 0590817201 00B8 17 0 95 73104439 73104439 83000000F303E80185000581B4BA142F 142F 1 |
7 | C1 027707212 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
8 | C1 027713144 00 0590817201 0006 00 3 EA5A EA5A |
9 | C1 027716424 00 0590817201 00DC 1B 2 95 73104439 73104439 010001014803A60BF2014803AC0C0500006FADBA ADBA 1 |
10 | C1 027740752 00 0590817201 0000 00 0 8A9C 8A9C |
11 | C1 027756120 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
12 | C1 027764348 00 0590817201 0002 00 1 AADE AADE |
13 | C1 027767624 00 0590817201 00DE 1B 3 95 73104439 73104439 02F4A20000F66302BD02BC0965138916E356FCE0 FCE0 1 |
14 | C1 029551548 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
15 | C1 029557480 00 0590817201 0006 00 3 EA5A EA5A |
16 | C1 029560760 00 0590817201 00D8 1B 0 95 73104619 73104619 02000457645908000507A3409300055764B521B6 21B6 1 |
17 | C1 029585088 00 0590817201 0000 00 0 8A9C 8A9C |
18 | C1 029601636 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
19 | C1 029609864 00 0590817201 0002 00 1 AADE AADE |
20 | C1 029613140 00 0590817201 00DA 1B 1 95 73104619 73104619 03590800000000900200138D6D8D6DFFFF46214B 214B 1 |
21 | C1 029635176 00 0590817201 0004 00 2 CA18 CA18 |
22 | C1 029637480 00 0590817201 0006 00 3 EA5A EA5A |
23 | C1 034225220 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
24 | C1 034235752 00 0590817201 0006 00 3 EA5A EA5A |
25 | C1 034239032 00 0590817201 00D8 1B 0 95 73104619 73104619 010001014803B40C20014703AC0BFE00005BB77A B77A 1 |
26 | C1 034261072 00 0590817201 0000 00 0 8A9C 8A9C |
27 | C1 035451152 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
28 | C1 035457080 00 0590817201 0006 00 3 EA5A EA5A |
29 | C1 035460360 00 0590817201 00DA 1B 1 95 73104619 73104619 02F08C0000EBA202D602C809611389170A53527C 527C 1 |
30 | C1 035482388 00 0590817201 0000 00 0 8A9C 8A9C |
31 | C1 035484696 00 0590817201 0002 00 1 AADE AADE |
32 | C1 035500772 00 0590817201 00BC 17 2 95 73104619 73104619 83000500F603E8018300213960F485BA 85BA 1 |
33 | C1 035995516 00 0590817201 00D8 1B 0 95 73104439 73104439 010001014803A70BF5014803AC0C0600006AEB1C EB1C 1 |
34 | C1 036029056 00 0590817201 0004 00 2 CA18 CA18 |
35 | C1 036044500 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
36 | C1 036055028 00 0590817201 0006 00 3 EA5A EA5A |
37 | C1 036058312 00 0590817201 00DA 1B 1 95 73104439 73104439 02F4A30000F66402BE02BD0965138916E657D717 D717 1 |
38 | C1 036080352 00 0590817201 0000 00 0 8A9C 8A9C |
39 | C3 037978808 00 1946107301 00DE 1B 3 15 73104619 72819005 801200623DA4AB000000000000000098C8DD09E3 09E3 1 |
Ist Euch bei der Analyse der HF Daten schon mal eine andere Adresse aufgefallen?
:
Bearbeitet durch User
Hallo Oliver, Danke für Deine Logs. Ich habe dazu wiederum ein paar Fragen/Anmerkungen: (1) Nach meinem Verständnis kann der NRF24 zwar von bis zu 6 "Pipes" = "Adressen" empfangen, aber nur Pipe 0 ist unabhängig, Pipe 1-5 teilen sich die ersten 4 Bytes, d.h. dürfen sich nur im letzten Byte unterscheiden (siehe Kapitel 7.7 "Multiceiver"). Das würde erklären, warum Du nur Nachrichten von C1 und C3 siehst. (2) In Deinen Mitschnitten tauchen auch wieder diese 0-Byte Payload Pakete auf. Laut Datenblatt sind das ACK-Pakete, die der Chip automatisch sendet, wenn er auf der jeweiligen Adresse etwas empfangen hat. Ich meine, bisher sieht es so aus, als sei diese ACK Funktion bei den Hoymiles Geräten deaktiviert. Wir sollten diese auf jeden Fall bei jeglichen Sniffern auch deaktivieren (setAutoAck(false)), sonst greifen die ja aktiv in den Funkverkehr ein. Vielleicht kommt da auch manche der Verwirrung weiter oben her - denn die Adresse dieser ACK-Pakete ist ja jeweils gleich der Adresse des ursprünglich empfangenen Pakets. (3) Bzgl. Deiner Frage wegen anderer Adressen - ich meine, martin (Gast) hatte auch schon einmal Adressen beobachtet, die in 0x00 (anstatt 0x01) enden. Als "Broadcast" zwischen allen WR würde das aber nicht wirklich taugen, hierzu würde sich vielleicht am ehesten die DTU Adresse eignen. Vielleicht gibt es bei Inbetriebnahme auch Broadcasts an 0x0000000000 oder so - auf uC-Seite scheinen manche Pakete solch eine Adresse zu enthalten. -- Petersilie
Angehängte Dateien:
Hallo Martin. Also ich habe jetzt mal etwas mit dem RF25L01+ Chip experimentiert. So ganz bin ich noch nicht dahinter gestiegen wie er funktioniert. Es ist sicherlich irgend so ein ASIC der als Schrittschaltwerk funktioniert ohne abhängige Logic, bzw. ohne die eingestellten Parameter zu prüfen. Er macht etwas in Abhängigkeit der eingestellten Register. Es kann schon mal sein, dass er völlig durcheinander ist und nur ein Spannungsreset hilft. So meine Beobachtung. Zu Deinen Fragen/Anmerkungen: (1) So wie ich es verstehe besteht die Möglicheit, dass die Adressen von Pipe 0 und Pipe 1 5 Byte lang sind. Pipe 2-5 betrachte ich nicht, diese hängen natürlich von den restlichen Bytes der Pipe 1 ab. Ich habe die Pipes auf die beiden Wechselrichter programmiert:
1 | pipe 0 ( open ) bound = 0x3944107301 |
2 | pipe 1 ( open ) bound = 0x1946107301 |
3 | pipe 2 (closed) bound = 0xc3 |
4 | pipe 3 (closed) bound = 0xc4 |
5 | pipe 4 (closed) bound = 0xc5 |
6 | pipe 5 (closed) bound = 0xc6 |
Im Log werden die Einträge von C2 nicht angezeigt, weil die Abfrage der Pipe im Interrupt aus irgendeinem Grund nicht funktioniert. Darum stimmt die im Adurino generierte Prüfsumme nicht. Die Telegramme werden aber erfasst, jedoch der Pipe 1 zugeordnet, obwohl sie zu Pipe 0 gehören. Hier ein Beispiel, gehört eigentlich zu Pipe 0, die Abfrage
1 | radio2.available(&pipe) |
liefert aber Pipe 1, darum wird das Telegramm C3 zugeordnet und anschließend wegen falscher Prüfsumme (Die Berechnung legt die Adresse WR2 zugrunde) verworfen. In den Nutzdaten sieht man aber, dass das Telegramm eigentlich für 73104439 bestimmt ist.
1 | C3 019634660 00 1946107301 00DE 1B 3 15 73104439 72819005 800B00623DD84B00000005000000009117A9035D 1565 0 |
(2) Was Du sagst ist absolut richtig, aber wenn dann ist es in der RF24 Dokumentation missverständlich beschrieben. Die AutoAck Funktion ist bei allen "Sniffern" deaktiviert. Darum sollten die nicht für die Ack Frames verantwortlich sein. Die ACK Frames die ich sehe sind auch immer an die Adresse der DTU gerichtet. Meine RF24 sind so eingestellt, dass die TX_ADR auf Default steht:
1 | TX_ADDR = 0xe7e7e7e7e7 |
Das Datenblatt sagt ja, dass für die AutoAck Funktion TX und RX Addr. gleich sein müssen.
1 | TX5 device: TX_ADDR = 0xB3B4B5B605 |
2 | TX5 device: RX_ADDR_P0 = 0xB3B4B5B605 |
3 | RX device: RX_ADDR_P5 = 0xB3B4B5B605 |
Muss man sicherlich noch weiter hinterfragen. (3) Als Ursache für die Adressen die mit 0x00 enden habe ich für mich den yveaux Sniffer ausgemacht. (Gut wenn man einen Schuldigen hat). Dieser stellt im RF 24 immer fest eine Adressbreite von 4 Byte ein (Bzw. Parametrierte Adressbreite - 1).
1 | #define DEFAULT_RF_ADDR_PROMISC_WIDTH (DEFAULT_RF_ADDR_WIDTH-1)
|
Das fehlende 0x01 in der Adresse wird dann schon der Payload zugeordnet. Dies ist der Grund, warum ich in älteren Aufzeichnungen immer ein Bit vor dem 9-bit PCF hatte. (Siehe Anhang) Die 0x02 ist die 0x01 in Byte 5 der Adresse. Martin (Gast) hatte noch eine Anmerkung: > Was mir hier und auch in meinen Daten aufgefallen ist: In den > Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer > mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun > haben, der für die Antwort verwendet werden soll? Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) Turn unit off: C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 Turn unit on: C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 Turn unit off: C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 Turn unit on: C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1
:
Bearbeitet durch User
Angehängte Dateien:
Ich möchte gerne einen kleinen Teilerfolg vermelden. Ich kann meine WR ohne die DTU abfragen und erhalte sporadisch Antworten. Ein Muster erkenne ich noch nicht. Bisher kann ich meinen Aufbau nur mit RF24_PA_LOW betreiben. Aber die Sendeleistung reicht um die 30m entfernten WR zu erreichen. Beim Senden meldet sich bei einer höheren Sendeleistung immer der CH340 Chip USB zum Rechner ab. Zunächst ging sogar nur RF24_PA_MIN, bis ich die 3.3V zum RF Modul mit einem 100uF Elko gestützt habe. Die DTU Radio ID in dem Code kann ich beliebig ändern, die WR antworten dann auf die neue DTU ID. Als Anpassung sollte es reichen, die DTU Radio Ids zu ändern. Bei nur einem WR zunächst irgendeine Dummy Adresse verwenden oder diese belassen.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Die Wechselrichter scheinen irgendeinen proprietären Mechanismus bei dem Channel hopping zu verwenden. Den habe ich noch nicht verstanden. Der Trick ist, auf einer anderen Adresse zu empfangen als zu senden und beim Senden bis die maximale Retransmit rate mit 2ms Pause zu verwenden. Zur Zeit verwende ich die Kanäle 3 und 40. Auf einigen anderen Kanälen geht bei mir gar nichts, vermutlich wegen meinem WLAN. Muss man evtl. in jeder spezifischen Umgebung ausprobieren. Versucht habe ich es mit einer Kombination aus den bereits weiter oben erwähnten Kanälen:
1 | int channels[] = {3, 23, 40, 61, 75}; |
1 | #define DEFAULT_RECV_CHANNEL (3) // 3 = Default channel for Hoymiles
|
2 | #define DEFAULT_SEND_CHANNEL (40) // 40 = Default channel for Hoymiles
|
Kann dies jemand bei sich nachvollziehen? Oder liegt es bei mir daran, dass die WR schon mal mit der DTU kommuniziert haben und dadurch noch irgendeine Konfiguration haben? Bei Fragen oder Problemen einfach melden.
:
Bearbeitet durch User
Hallo Oliver, was genau wird bei dir zur Anforderung an den WR gesendet ? Vielleicht sende ich da was falsches. Bisher bei mir ohne Erfolg. Ich hab 14 retransmits eingschalten, hab auf jeder Megahertz - Frequenz 2400 - 2525 Mhz gesendet. Der WR hat nirgends geantwortet. Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, daß er irgendwo antwortet. Dann könnte ich immer noch mit Aufnahmen feststellen, wo. (Die Messung mit dem AD8318 funktioniert einwandfrei, wenn ich den an meinen NRF dran stelle.) Evtl fehlt dann doch irgendeine Grundinitialisierung an den WR, daß er was tut oder ich sende Schrott.
B. G. schrieb: > > was genau wird bei dir zur Anforderung an den WR gesendet ? > Hallo B.G. Der Quelltext ist dem Beitrag angehängt. Ich sende alle 200ms ein Telegramm an meine beiden Wechselrichter. Sie antworten nicht jedes mal, sondern gefühlt jedes 4-5 Mal. Ich denke das hat mit dem noch nicht durchschauten Channel Hopping zu tun. Es wird nacheinander auf CH40 das 0x80 Telegramm mit einer simulierten Unix Zeit gesendet, da ich auf dem nano keine Echtzeituhr habe. Das scheint dem WR aber egal zu sein. Dann das 0x81, 0x80, 0x83, 0xFF Telegramm, wie von Martin in der Protokollbeschreibung angegeben. Danke an Martin das ist sehr hilfreich. Nach dem Senden wird direkt wieder auf CH3 umgeschaltet und gehorcht.
1 | if (tel > 4) |
2 | tel = 0; |
3 | if (tel == 0) |
4 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
5 | else if (tel == 1) |
6 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x81); |
7 | else if (tel == 2) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x80); |
9 | else if (tel == 3) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
11 | else if (tel == 4) |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0xFF); |
13 | |
14 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
15 | |
16 | toggle = !toggle; |
17 | if (!toggle) |
18 | tel++; |
Ein Dump mit Ausgabe von Send und Receive ist angehängt. Die Zeilen mit diesem Inhalt sind dabei die vom WR empfangenen Daten.
1 | 048491820 00 1234567801 00DC 1B 2 95 73104619 73104619 010001014F027908470150026D08220000FB9CDF 9CDF 1 |
2 | 048540572 00 1234567801 00DE 1B 3 95 73104619 73104619 02FE300000F91307790762096413840FADF0AB62 AB62 1 |
"Send..." ist jeweils ein Send auf CH40. PL die Payload, WR1/2 gibt an an welche Adresse. Die 0 danach ist der Rückgabewert vom Write, da ja kein ACK von den WR kommt. Dann die millis() Zeit des Nano und die Dauer des Sendens in millis().
1 | Send... CH40 PL: 1573104439785634128182 WR2 0 48677140 29204 |
2 | Send... CH40 PL: 15731046197856341281A0 WR1 0 48877844 29204 |
:
Bearbeitet durch User
vielen Dank, wenn es jemand gibt, der Erfolg mit dem zurücklesen hat, ohne eigene DTU zu besitzen, dann bitte melden. bei martin müßte es ja evtl jetzt so funktionieren ?
Hallo @golf2010 und @of22, das ist tolle Arbeit. Muss man erst mal drauf kommen! Hoffentlich komme ich morgen dazu, das mit meinem Raspi-Setup auszuprobieren. Können wir eventuell noch weiter einschränken, welche Nachrichten wirklich notwendig sind? (1) @of22, Du wechselst zwischen den 5 Pakettypen im Kreis herum - hast Du mal probiert, ob weniger eventuell immernoch zum Erfolg führen? (2) Und habe ich das richtig verstanden, du hörst immer auf Kanal 3? D.h. angenommen, Du würdest nach dem Senden auf Kanal 40 bleiben, dann würdest Du nichts empfangen? (3) Und noch ne ganz ketzerische Frage: wenn Du garnichts sendest und nur auf Kanal 3 zuhörst, empfängst Du aber nie irgendwelche Nachrichten, oder doch?
Hallo Martin G. (1) Habe ich versucht nur das 0x80 mit dem Unix Timestamp zu senden, das reicht aus. Aber dann kommt nur der 01 00 01 Response. Mit den anderen zwischendurch kommt auch mal ganz selten eine andere Antwort. Ich hatte schon versucht mir die Saleae Captures von martin (Gast) 20.03.2022 13:37 anzusehen, um hier vielleicht anhand der Serial Captures ableiten zu können welche Requests erforderlich sind. Könnte man die vielleicht als ASCII Dump oder so zur Verfügung stellen? Ich habe kein Saleae und so wie ich es veerstehe gibt es keine Stand Alone Version der Software. (2) Das ist richtig, so ist meine Beobachtung. Gesendet und Empfangen wird immer auf einem unterschliedlichen Kanal. Bleibe ich auf dem Sendekanal, egal ob 40 oder 3, empfange ich keinen Response. (3) Nein, wenn ich aufhöre zu senden kommen keine Responses vom WR mehr. Er muss immer durch irgendein Telegramm getriggert werden.
:
Bearbeitet durch User
Hallo @of22, habe mir die Hardware mit dem Nano aufgebaut. Kommunikation mit dem NRF24 scheint zu tun. Also Register usw. werden ausgelesen. Nur kurz 2 Fragen bevor ich hier tiefer in den Code einsteige. 1. Muss die Seriennummer des WR auch Rückwärts angegeben werden? 2. Wie funktioniert das Menü? Wird gleich nach dem Startup schon gesendet oder muss man das Senden zuerst über die Serielle Konsole starten? Danke & Grüße Thomas
Angehängte Dateien:
-
ali-001.jpg
21 KB -
ali-005.jpg
18 KB
Hallo Thomas. Die Seriennummer muss in dem define umgekehrt angegeben werden. An meinem Beispiel: WR1 = xxxx73104619 WR2 = xxxx73104439 Und im Byte 5 der Adresse die 01 nicht vergessen. Die Adresse der DTU ist egal, da Du sie ja simulierts.
1 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
2 | #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
|
3 | #define WR2_RADIO_ID ((uint64_t)0x3944107301ULL) // 0x3944107301ULL = WR2
|
4 | #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
|
Das Menü ist erst einmal uninteressant. Der Code fängt direkt an zu senden. Es waren nur Tests um die Kommunikation auf einzelne Telegramme einzuschränken. Eine Anmerkung noch: Eventuell muss der Sendelevel angepasst werden. Ich habe die Module ali-005 mit externer Antenne im Einsatz. Damit komme ich nicht über PA_LOW sonst hängt sich etwas auf (CH340), oder ich bekomme keine Antworten. Vorhin habe ich es noch die ali-001 ausporbiert. Damit muss ich höher gehen auf PA_HIGH sonst bekomme ich keine Antwort von den ca. 30 m entfernten Wechselrichtern durch zwei Wände. Aber auch mit denen kann ich nicht auf PA_MAX gehen sonst kommt wiederum keine Antwort.
1 | radio1.setPALevel(RF24_PA_HIGH); |
Und dran denken, jetzt ist dunkel. Da kommt nichts mehr, weil der WR aus dem DC Kreis versorgt wird.
:
Bearbeitet durch User
Hallo Oliver, alles klar danke! Habe hier auch den ali-005. Habe aber schon einen 10uF angelötet. Werde es erstmal mit LOW versuchen und mich notfalls mit dem Laptop raus stellen. Ich bin ja sooo gespannt. Jetzt wenn schon Sonne vorhanden wäre :) Grüße Thomas
Angehängte Dateien:
B. G. schrieb: > Ich hab an die Antenne des WR einen AD8318 als Pegelmesser angeschlossen > und den Ausgang davon an den Oszi. So würde ich auf jeden Fall sehen, > daß er irgendwo antwortet. Ich hab tagelang völlig unnötig rumprobiert. Da war bei mir nur ein Zahlendreher in meiner eingegebenen WR-Seriennummer. Nachdem ich den heute Nacht gesehen hab, hat der WR heute morgen sofort geantwortet auf ein 80 Paket. Also brauchst doch keine extra Initialisierung. Anbei der Ausgang von meinem Pegelmesser AD8318, am Oszi angeschlossen. Ich muß jetzt schauen, wo er antwortet.
Angehängte Dateien:
B. G. schrieb: > Ich muß jetzt schauen, wo er antwortet. auf 2403 kam der gerade. auf der 2405 gibts hier noch einen weiteren NRF, wohl ein Nachbar. Der auf 2405 kommt etwas stärker rein.
:
Bearbeitet durch User
Hallo B.G. dein Testprogramm funzt einwandfrei. Es werden zwar nicht alle Anfragen beantwortet, aber so alle 1 - 2 Sekunden kriegt man Daten. Und das ist doch schon was.
Hallo Hubi, das Programm ist von Oliver. Ich kann kein C, nur Pascal(Avrco) und Delphi.
Hallo, kann es auch bestätigen. Daten werden empfangen. Ich kann auch bestätigen das es mit > RF24_PA_HIGH nicht funktioniert. Zumindest wenn ich den NRF24 via USB betreibe. Am Labornetzteil tut es.
Angehängte Dateien:
Hallo, das freut mich zu hören, dass es auch bei anderen klappt. Das man nicht jedes Mal eine Antwort erhält, liegt an dem noch nicht durchschauten Channel Hopping. Ich habe mal noch ein paar Sachen zum Nachdenken, wer möchte, kann sich gerne beteiligen. Ich habe meiner DTU und einem WR nochmal bei der Kommunikation mit diesem Aufbau zugehört: Zwei RF24 Chips. Einer lauscht auf Kanal x und der andere auf x + 40, jeweils für 60 s. Dann wird x inkrementiert von 0 bis 39. Dabei heraus gekommen ist diese Statistik. Das ist sicherlich eine Momentaufnahme, die sich aus meinem WLAN Umfeld und aus anderen Störern ergibt. Auch sind bei den Frames WR=>DTU die Antworten von dem zweiten Wechselrichter, dessen DTU Anfragen nicht geloggt werden, das könnte das Bild verfälschen. Kommunikation läuft auf mehr als den bisher angenommenen Kanälen, wobei es bei den Kanälen 7, 8, 9 auch ein Übersprechen sein könnte. WR an DTU sind am häufigsten auf Kanal 3 und 23 vertreten. DTU an WR springt lustig durch die anderen Kanäle, wobei 0, 7, 9, 23, 27, 35, und 40 die Spitzenreiter sind. Als Kommandos DTU=>WR sieht man die Ids 0x80, 0x81, 0x82, 0xFF.
1 | Kanal | Frames | DTU=>WR | WR=>DTU | 0x80 | 0x81 | 0x82 | 0xFF |
2 | ------+--------+---------+---------+------+------+------+------ |
3 | 0 | 11 | 11 | 0 | 5 | 0 | 0 | 6 |
4 | 3 | 81 | 8 | 73 | 5 | 4 | 1 | 2 |
5 | 7 | 10 | 10 | 0 | 8 | 0 | 0 | 2 |
6 | 8 | 3 | 3 | 0 | 2 | 0 | 1 | 0 |
7 | 9 | 12 | 12 | 0 | 9 | 0 | 3 | 0 |
8 | 11 | 9 | 9 | 0 | 8 | 0 | 1 | 0 |
9 | 14 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
10 | 20 | 3 | 3 | 0 | 2 | 0 | 0 | 1 |
11 | 23 | 59 | 12 | 47 | 7 | 1 | 4 | 1 |
12 | 27 | 13 | 13 | 0 | 9 | 1 | 1 | 2 |
13 | 29 | 8 | 8 | 0 | 4 | 0 | 3 | 1 |
14 | 35 | 11 | 11 | 0 | 5 | 2 | 1 | 3 |
15 | 37 | 8 | 8 | 0 | 6 | 0 | 2 | 0 |
16 | 39 | 8 | 8 | 0 | 5 | 0 | 2 | 1 |
17 | 40 | 10 | 10 | 0 | 6 | 0 | 1 | 3 |
18 | 61 | 13 | 9 | 4 | 6 | 0 | 2 | 1 |
19 | 75 | 8 | 3 | 5 | 2 | 1 | 0 | 0 |
Woher weiß die DTU, auf welchem Kanal der WR lauscht? Und woher weiß sie, auf welchem Kanal die Antwort vom WR kommt? So aus einem Bauchgefühl heraus: Könnte das 0xFF Telegramm die Aufforderung zum Kanalwechsel sein, aber wohin? Bei dem 0x80 Telegramm sehe ich im Byte hinter der 0x80 die Bytes 0x0B oder 0x11 (Siehe Screenshot). Die Bedeutung erschließt sich mir noch nicht. Beigefügt der Dump aus dem Minuten Scan als Rohdump und aufbereitete Excel.
:
Bearbeitet durch User
Hallo, es geht voran, aber nicht so direkt Beteilige verlieren den Überblick. So auch ich. Kann bitte jemand einmal kurz und knackig die benötigte Hardware skizzieren und die Software mit Sourcecode bereitstellen? Dann kann jeder Homiles Nutzer sich schnell zurechtfinden. Danke
@of22: Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen Uhrzeit stehen?
Bezugnehmend auf Sorbit (Gast) würde ich gerne https://github.com/grindylow/ahoy als Sammelstelle vorschlagen. Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf das Repository geben. @Sorbit, ich glaube, so hundertprozentig "einstecken und tut"-Lösungen haben wir noch nicht - jeder hat leicht andere Hard- und Software, aber gerade deshalb geht es erstaunlich voran! Aber Du hast natürlich Recht, ich denke wir haben alle ein Interesse daran, dass das ganze früher oder später einfach(er) nachzuvollziehen und zu nutzen wird.
Angehängte Dateien:
Martin G. schrieb: > @of22: > Könnte der gewählte Kanal eventuell in Zusammenhang mit der aktuellen > Uhrzeit stehen? Hallo Martin, gute Idee, das ist ja fast das Einzige was sich in den Telegrammen ändert. Beziehe ich in meine Grübeleien ein. > Gerne kann ich Code für Euch hochladen, bzw. Euch direkten Zugriff auf > das Repository geben. Bisher ist das Ganze ja nur ein zusammengeklopptes Testprogramm. z.B. könnte man die CRC Generierung auf eine Bibliothek umstellen. https://github.com/RobTillaart/CRC oder so. Auch wird im Testprogramm Kanal 40 zum Senden und 3 zum Empfangen verwendet. Die Statistik oben zeigt ja, dass man auch auf 23 lauschen müsste und auf anderen senden. Aber Du kannst gerne den jetzigen Stand hochladen. @ Sorbit (Gast): Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in China bestellt hatte. Ich mag die Atmel Dinger aber ansonsten nicht. Dazu ein RF24 Modul ali-005 (Siehe weiter oben). Die Schaltung habe ich skizziert. Ich betreibe den nano mit den 5V vom Laptop USB. Problem ist hierbei noch die 3V3 Versorgung des RF24. Wie Thomas B. (tbnobody) herausgefunden hat verwendet man besser noch ein externes Netzteil. Die Leistung des Linearreglers im CH340 des nanos reicht nicht aus um die Versorgung bei höheren Sendeleistungen sicher zu stellen.
Hallo zusammen, im Source von Oliver sollten ja die verschiedenen Packages nacheinander durchprobiert werden. Daher hätte ich erwartet, dass die Antworten mit gleicher Häufigkeit vorkommen. Aber siehe capture.txt im Anhang sehe ich hauptsächlich 1er und 2er... die 3er Messages kommen kaum vor. Könnt ihr das Nachvollziehen, ist das bei euch ähnlich? Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, ggf. auch der Strom, aber spätestens bei der Leistung stimmt es zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe hier einen HM-1500) Ggf. sind die Telegramme je nach Typ unterschiedlich aufgebaut. Dann müsste man aber seinen Typ entweder in der Hoymiles Cloud einstellen können oder dieser wird irgendwo noch mitgeschickt.
Oliver F. schrieb: > Aber Du kannst gerne den jetzigen Stand hochladen. Gesagt - getan: https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv
Oliver F. schrieb: > @ Sorbit (Gast): > Ich verwende einen Ardino nano, weil ich den in ausreichender Menge in > China bestellt hatte. Davon hab ich genug rumfliegen. Welcher Code läuft da drauf? RF Modul hab ich auch mal im 20 er Pack gekauft. Alles da, auch ein produktiver HM-1200... Danke
Hallo @of22, ich bin noch über Deine Zeile https://github.com/grindylow/ahoy/blob/82ce2c9d8864dcc465af804ab0130dd7a7322a6b/tools/nano/NRF24_SendRcv/src/hm_packets.cpp#L49 gestolpert:
1 | buf[19] = 0x05; |
Warum? Und was passiert, wenn das nicht gemacht wird (also an dieser Stelle ein 0-Byte verbleibt)? Ist das der von Dir beobachtete Zähler, der sich mit jedem Schaltbefehl erhöht?
Hallo, ich möchte mir schonmal die Hardware bestellen. Wir reden über sowas, richtig? https://www.ebay.de/itm/255283312809 (Einen Nano habe ich) Danke sehr!
Hallo @petersilie. Ja, dass ist richtig. Es ist wie weiter oben beschrieben. Ich habe gesehen, dass der Zähler mit jeder Schaltaktion inkrementiert wird. Es ist wahrscheinlich ein 16-bit Wert. Durch die ganze Probiererei scheint der Zähler aus der Cloud mittlerweile bei 0x0537 zu stehen?!? Es passiert erst einmal nichts offensichtliches, wenn man das weg lässt. Keine Ahnung was das ist.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
@Mag C. (magcode): Ja das Modul verwende ich auch. Wichtig ist, dass es ein NRF24L01*+* (Plus) ist.
:
Bearbeitet durch User
Thomas B. schrieb: > Des weiteren habe ich auch mal versucht die Empfangenen Telegramme zu > dekodieren. Siehe Excel Datei im Anhang. Aber so ganz schlau werde ich > daraus noch nicht. die Spannung für PV1 scheint noch irgendwo zu passen, > ggf. auch der Strom, aber spätestens bei der Leistung stimmt es > zumindest nicht mehr mit der bisherigen Protokollanalyse zusammen. (Habe > hier einen HM-1500) Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe geschaltet? Wenn wir die Verläufe über ein paar Stunden betrachten, idealerweise mit gleichzeitiger Beobachtung der Ausleuchtung der 4 Solarpanels, dann kommen wir bestimmt hinter die genaue Bedeutung der einzelnen Felder. Der WR-Typ wird ja vielleicht in einem der bisher als "unbekannt" gekennzeichneten Bytes/Bits übertragen. Oder vielleicht ist er in der Seriennummer kodiert? Oder die DTU fragt das bei der Einrichtung einmalig ab?
Angehängte Dateien:
martin schrieb: > Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden Hallo zusammen, leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, wie es hier voran geht. Danke an alle Beteiligte. Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher schon mal aufgenommen hatte: Könnte es vielleicht sein, dass der Inverter generell auf einem anderen aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die Interferenzen sind. Nur so eine Idee - auch wenn das von den im FCC Report genannten Frequenzen abweichen würde. Falls das den Hersteller überhaupt interessiert... (grübel)
Angehängte Dateien:
martin schrieb: > martin schrieb: >> Der Spectrum Analzer zeigt, wie die Kanäle abwechselnd genutzt werden > > Hallo zusammen, > leider hab ich gerade wenig Zeit auch was zu testen. Finde es aber mega, > wie es hier voran geht. Danke an alle Beteiligte. > > Eine Idee meinerseits, bezugnehmend auf das Spektrogramm, was ich früher > schon mal aufgenommen hatte: > Könnte es vielleicht sein, dass der Inverter generell auf einem anderen > aber nicht zu weit entfernten Kanal antwortet? B.G. hatte ja in seiner > Frequenzanalyse auch Signale gesehen, die ca. 3 MHz tiefer lagen. > Wenn ich auf ein Funksignal eine Antwort erhalten wollte, würde ich das > wenn nicht auf der gleichen Frequenz dann doch in der Nähe derselben > erwarten - sonst hätte ich ja gar keine Chance, herauszufinden wo die > Interferenzen sind. > > Nur so eine Idee - auch wenn das von den im FCC Report genannten > Frequenzen abweichen würde. Falls das den Hersteller überhaupt > interessiert... (grübel) Das ist momentan bei mir nicht der Fall. Die WR senden auf den festen Channel-Frequenzen, wie es aussieht. Keine Ahnung, was damals alles aktiv war bei Deinen Aufnahmen. Das war auch komisch mit den instabilen Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Der WR scannt die Kanäle durch bis er was empfangen hat und, wie es aussieht, sendet er dann immer 3 Antwort Telegramme, oft auf unterschiedlichen Frequenzen. (Telegramme nicht näher untersucht) Die Kanalwahl hat erst mal nichts zu tun mit der übermittelten Zeit. Das Sonagramm der Aufnahme ist etwas schwach, hatte nur ein Stück Draht als Antenne.
:
Bearbeitet durch User
B. G. schrieb: > Das war auch komisch mit den instabilen > Sendern, als wenn entweder der HackRF oder eine NRF instabil war. Ok, danke für die Rückmeldung. Ich werde das bei Gelegenheit nochmal nachmessen.
> Der WR scannt die Kanäle durch bis er was empfangen hat.
Deshalb wird vmtl immer mit 15 Retransmits gesendet.
Auch der DTU scannt vmtl einfach die Kanäle durch, die Telegramme werden
ja genügend oft wiederholt.
Hallo, ich versuche gerade mal durch den Code zu gehen und diesen zu verstehen. Dabei ist mir aufgefallen, das der Wert 0x05 an Stelle 19 gesetzt wird:
1 | buf[19] = 0x05; |
dennoch ist er bei deiner Ausgabe aber immer an Stelle 18:
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben werden ? Vielen Dank
Marcel schrieb: > Habe ich da eine Stelle im Code übersehen, wo Bitfolgen verschoben > werden ? Hallo Marcel. Nein Du hast nichts übersehen. Das rudimentäre Testprogramm zur Simulation der DTU schreibt an dieser Stelle immer eine 0x05. So ist es momentan noch, weil wir die Bedeutung dieses Wertes noch nicht kennen. Siehe Nachricht vom 27.03.2022 19:34 an Petersillie. Das Beispiel was Du anführst ist aus einem aktuellen Scan der Kommunikation zwischen DTU und WR. Hier steht dieser "Zähler" jetzt schon auf 0x0537.
1 | 15 73104619 72819005 801100624091650000053700000000EDA3740F6B 0F6B 1 |
Siehe auch Nachricht vom 25.03.2022 15:35: Dieser Zähler inkrementiert sich, wenn man aus der Hoymiles Cloud heraus eine Schaltaktion durchführt.
1 | Turn unit off: |
2 | C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 |
3 | 800B00623B5CD8000000080000000013DAD8A73B 3BA7 1 |
4 | Turn unit on: |
5 | C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 |
6 | 800B00623B5D5A0000000900000000B0CEEDD61D 1DD6 1 |
7 | Turn unit off: |
8 | C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 |
9 | 800B00623B5DC20000000A0000000076413F7EAF AF7E 1 |
10 | Turn unit on: |
11 | C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 |
12 | 800B00623B5E4B0000000B000000002F872B6ABD BD6A 1 |
Vielen Dank, ist aber auch ein witziger Zufall, das genau 05 um eine Stelle nach vorne gerückt ist. Somit hat der Counter da 16 bit, ergo 4 Stellen. Danke
Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine erste Testimplementierung in Python für RaspberryPi. Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf Kanal 40, ansonsten immer auf Kanal 3 zuhören. Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit einer DTU in Kontakt war. Ergebnis: siehe Anhang. (Programm siehe https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py)
:
Bearbeitet durch User
Hallo zusammen mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren. Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB Leistung der letzten Tage, Wochen, Insgesamt?
Martin G. schrieb: > Erfolg! Auf Basis des Testprogramms von @of22 habe ich jetzt eine > erste > Testimplementierung in Python für RaspberryPi. > > Gleiche Vorgehensweise: 0x80-Nachricht senden circa jede Sekunde auf > Kanal 40, ansonsten immer auf Kanal 3 zuhören. > > Das ist ein frisch gekaufter Hoymiles Wechselrichter, der noch nie mit > einer DTU in Kontakt war. > > Ergebnis: siehe Anhang. > > (Programm siehe > https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py) Hardware Setup, Software? Viele unterstützen und sollten es auch nachbauen Können. Danke
Hubi schrieb: > Hallo zusammen > mit dem Code von Oliver konnte ich die AC und DC Daten extrahieren. > Weiß jmd, ob der WR auch sowas wie statistische Daten preisgibt, also zB > Leistung der letzten Tage, Wochen, Insgesamt? Hallo Hubi, das weiß ich zwar nicht zu 100% aber ich halte es für sehr unwahrscheinlich. Das ist klassisch die Aufgabe der Cloud. Das wirst Du in ioBroker mit influxdb und/oder Grafana oer ähnlichem machen müssen.
Sorbit schrieb: > Hardware Setup, Software? Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben. Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon. https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md Gruß -- petersilie
Martin G. schrieb: > Sorbit schrieb: >> Hardware Setup, Software? > > Du hast natürlich Recht, wer nicht den ganzen Thread mitliest, für den > ist der Einstieg gerade noch schwer. Aber Stück für Stück, wir sind ja > noch mittendrin. Ich habe das Raspi-Setup jetzt mal hier beschrieben. > Ein kurzes Beispiel-Log von vor ein paar Stunden gibt es auch schon. > > https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md > > Gruß > > -- petersilie Klasse, super Beschreibung, toll gemacht! Woher bekommst Du die Seriennummer vom WR? Meiner ist leider schon unter den Panels auf dem Dach verbaut😪😪
Sorbit schrieb: > Woher bekommst Du die Seriennummer vom WR? Die Seriennummer habe ich leider bisher nur auf der Rückseite des WR gesehen. Dort sind 2 Labels mit der Seriennummer aufgebracht.
Thomas B. schrieb: > Die Seriennummer habe ich leider bisher nur auf der Rückseite Schei....... Ohne die Nummer keine Kommunikation?
Thomas B. schrieb: > Dort sind 2 Labels mit der Seriennummer aufgebracht. Genau. Damit man eines abziehen und auf den beigefügten Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu klettern ;-)
mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max. Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden? Gibt es dafür Beispiele auf Protokollebene?
martin schrieb: > Genau. Damit man eines abziehen und auf den beigefügten > Installationsplan kleben kann und somit nachschauen, ohne aufs Dach zu > klettern ;-) Tja, nacher ist man immer schlauer ;-(
Angehängte Dateien:
temp schrieb: > mal ne Frag ein die Runde, kann man bei dem Wechselrichter die max. > Leistung einstellen um ihn z.B. als Akkuwechselrichter zu verwenden? > Gibt es dafür Beispiele auf Protokollebene? Hallo. Das ist genau der Grund warum ich mich mit der Materie beschäftige. Ich habe eine DTU-WLite. Eigentlich hätte ich mit der Cloud Integration von Hoymiles prima leben können. Leider ist es aber so, dass Hoymiles die Funktion zum Begrenzen der Leistung bei der Lite DTU gesperrt hat. Man braucht dazu die sündhaft teure DTU-Pro. Noch ist es ein weiter Weg, weil nur ein geringer Teil der Payload zwischen DTU und WR entschlüsselt wurde. Wir stehen da erst am Anfang, zu verstehen wie es funktioniert. Dazu kommt, dass zwar schon viele Telgramme gesnifft wurden, aber eben nur zwischen DTU-Lite und WR. Die Möglichkeit mit einer DTU-Pro zu sniffen habe ich z.B. nicht. Darum ist es für mich fraglich ob ich jemals diese Funktion der Leistungsbegrenzung nutzen kann. Ich bekomme sporadisch viele verschiedene Antworten vom WR. Die Bedeutung muss erst einmal verstanden werden. Aber da ist bestimmt auch etwas dabei für WR mit mehr als zwei MPP Trackern. P.S. Autark wirst Du die WR der HM- Serie nie betreiben können, da sie ja einen NA Schutz haben und immer ein vorhandenes Netz in bestimmten Grenzwerten sehen wollen.
:
Bearbeitet durch User
Hallo, ich habe die RF Hardware erhalten und werde es mal mit den Arduino Sourcen probieren. Ich habs auf Anhieb nicht gefunden ... wo würde ich die Seriennummer eintragen? https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv Danke sehr! Update: habs gefunden! -> WR1_RADIO_ID
:
Bearbeitet durch User
Hallo, bei mir antwortet der WR ziemlich präzise jede Minute (ich warte immer 3 Sekunden auf Antwort). Aber alle Anfragen unter einer Minute werden nicht beantwortet (zumindest nicht auf Kanal 3) Ich denke mal, die haben da einen Schutz drin, dass man eben nicht jede Sekunde abfragt. Vielleicht kann das jemand mit DTU und cloud bestätigen, indem man sich die Auflösung der Daten anschaut.
1 | Time Tue Mar 29 15:59:32 2022 |
2 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 24 00 88 00 00 40 A7 03 A5 08 EF E8 |
3 | |
4 | Time Tue Mar 29 16:00:32 2022 |
5 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 F9 FD |
6 | |
7 | Time Tue Mar 29 16:00:40 2022 |
8 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7D 00 23 00 87 00 00 40 A7 03 A5 08 FA FE |
9 | |
10 | Time Tue Mar 29 16:01:40 2022 |
11 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7A 00 23 00 84 00 00 40 A7 03 A5 08 FA FA |
12 | |
13 | Time Tue Mar 29 16:01:48 2022 |
14 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 79 00 23 00 83 00 00 40 A7 03 A5 08 F6 F2 |
15 | |
16 | Time Tue Mar 29 16:02:48 2022 |
17 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 78 00 22 00 7F 00 00 40 A8 03 A6 08 FC 08 |
18 | |
19 | Time Tue Mar 29 16:03:48 2022 |
20 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 73 00 20 00 77 00 00 40 A8 03 A6 08 F5 00 |
21 | |
22 | Time Tue Mar 29 16:04:49 2022 |
23 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 76 00 1D 00 6D 00 00 40 A8 03 A6 08 F7 20 |
Ich habe einen HM-400 (mit nur einem Anschluß für Solar Paneele). Dennoch sind haben bei mir die Position 18-23 Werte. Ich denke nicht, das diese den Wert Volt, Ampere und Power beinhalten. Die Positionen 12-17 Stimmen mit meinen Messungen überein.
1 | if (data[0] == 0x95 && data[9] == 0x01) {
|
2 | // Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 7C 01 33 04 90 00 00 40 75 03 73 09 09 0B |
3 | DATA.voltage_pv1 = float(data[12] << 8 | data[13]) / 10; |
4 | |
5 | DATA.ampere_pv1 = float(data[14] << 8 | data[15]) / 100; |
6 | |
7 | DATA.power_pv1 = float(data[16] << 8 | data[17]) / 10; |
8 | |
9 | DATA.voltage_pv2 = float(data[18] << 8 | data[19]) / 10; |
10 | |
11 | DATA.ampere_pv2 = float(data[20] << 8 | data[21]) / 100; |
12 | |
13 | DATA.power_pv2 = float(data[22] << 8 | data[23]) / 10; |
14 | } else if (data[0] == 0x95 && data[9] == 0x82) {
|
15 | // Received: 95 73 10 90 25 73 10 90 25 82 13 88 04 57 00 01 00 30 03 E8 01 5B 00 1F 2E 2A 44 |
16 | DATA.frequency = float(data[10] << 8 | data[11]) / 100; |
17 | |
18 | } |
Danke für die Arbeit bisher. Ich bin schon mal sehr happy, das ich einige Daten lesen kann. Marcel
Wobei, ich revidiere. Da hatte er nur ein mal ein guten Lauf :) Nach erneutem Flashen des ESPs gehts jetzt nicht mehr so präzise. Marcel
(1) Das mit dem Abfragerhythmus ist noch mysteriös, aber je mehr Erfahrung wir sammeln, desto näher kommen wir der Sache. Ich fände es logisch, wenn der WR ziemlich zeitnah auf eine Anfrage antwortet. Aber er muss eben die Anfrage auch hören (in unserem Fall: gerade auf Kanal 40 lauschen), und sie dann (in unserem Fall) genau auf Kanal 3 beantworten. Ich meine, in einigen der frühen Posts hatten wir schon beobachtet, dass eine DTU auf jeden Fall immer gleich auf mehreren Kanälen anfragt. Ich spekuliere mal, dass der WR dann vielleicht auch immer gleich auf mehreren Kanälen antwortet. Vielleicht ist garnicht viel mehr Magie dabei. Auf vielen Kanälen fragen. Auf vielen Kanälen antworten. Wenn auf einem Kanal "lange" nie eine Nachricht kommt, mal auf einen anderen der bekannten Kanäle wechseln. Presto, semi-verlässliche Kommunikation. (2) Nachrichten-Inhalte. Hier habe ich mir seit längerem keine Zeit mehr genommen, die Protokollbeschreibung upzudaten. Es gibt ja ein paar neue Erkenntnisse. Aber ich sammle jetzt eifrig Beispieldaten mit meinem WR, und Du und viele andere machen dasselbe. Da finden wir bestimmt nach einiger Zeit Muster/Werte, über die wir dann auf den Inhalt der jeweiligen Datenfelder schließen können. Deine Daten von dem 1-kanaligen WR sind vielleicht ähnlich wie die von @tbnobody mit seinem HM-1500 (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")? Er sagt ja auch, dass es sich hier nicht um V/A/W handeln kann. Ruhig mal nen ganzen Tag mitloggen!
Ich hab die Daten jetzt mal mit meinem Esphome und Homeassistant Messungen verglichen. Ich gehe davon aus, das die Position 20 und 21 die Gesamtproduktion in Watt des WR und die Position 22 und 23 die Tagesproduktion in Watt sind. Die passen ziemlich genau mit den Daten von meinem HomeAssistant (wo ich den Strom messe, den ich ins Netz gebe).
1 | DATA.total_production = float(data[20] << 8 | data[21]) / 1000; |
2 | DATA.daily_production = float(data[22] << 8 | data[23]); |
Aber ich denke das werden die anderen bestimmt bald bestätigen oder widerlegen können :) Marcel
Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt. WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen. Beim starten gibt die serielle Konsole aus:
1 | -- Hoymiles test -- |
2 | 19:11:42.309 -> |
3 | 19:11:42.309 -> Radio 1: |
4 | 19:11:42.309 -> SPI Speedz = 10 Mhz |
5 | 19:11:42.309 -> STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 |
6 | |
7 | 19:11:42.309 -> RX_ADDR_P0-1 = 0xdeadbeef01 0x1234567801 |
8 | |
9 | 19:11:42.309 -> RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 |
10 | |
11 | 19:11:42.309 -> TX_ADDR = 0xdeadbeef01 |
12 | |
13 | 19:11:42.309 -> RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20 |
14 | |
15 | 19:11:42.309 -> EN_AA = 0x00 |
16 | |
17 | 19:11:42.309 -> EN_RXADDR = 0x02 |
18 | |
19 | 19:11:42.309 -> RF_CH = 0x03 |
20 | |
21 | 19:11:42.309 -> RF_SETUP = 0x23 |
22 | |
23 | 19:11:42.309 -> CONFIG = 0x37 |
24 | |
25 | 19:11:42.309 -> DYNPD/FEATURE = 0x00 0x00 |
26 | |
27 | 19:11:42.309 -> Data Rate = 250 KBPS |
28 | |
29 | 19:11:42.309 -> Model = nRF24L01+ |
30 | |
31 | 19:11:42.309 -> CRC Length = Disabled |
32 | |
33 | 19:11:42.309 -> PA Power = PA_LOW |
34 | |
35 | 19:11:42.309 -> ARC = 15 |
36 | |
37 | 19:11:42.309 -> |
Das wars dann leider. Mehr kommt nicht. Auch nach einigen Minuten warten. Ich war bis auf 4m am HM-400 ran. Der HM-400 hat während des Tests Strom produziert, war also aktiv. Verkabelung habe ich kontrolliert. Allerdings habe ich den Kondensator nicht und das RF Modul direkt an den 3.3v Pin des Nano angeschlossen...
Mag C. schrieb: > Ich habe mal den Nano mit dem RF verdrahtet und mit dem code bestückt. > WR Seriennummer in HEX umgewandelt und unter "WR1_RADIO_ID" eingetragen. Du darfst nichts in HEX wandeln, also umrechnen. Die dezimale Seriennummer wird einfach als Hex Wert eingetragen. Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge angegeben werden: An meinem Beispiel: WR1 = xxxx73104619 Und im Byte 5 der Adresse die 01 nicht vergessen. #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = WR1
Zusätzlich braucht der HM ein wenig Sonne, sonst ist er aus. Hier in Nord Deustchland antwortet mein HM nicht mehr. Da musst Du wohl bis morgen warten. Marcel
Hallo zusammen, ich habe gerade bei meinem HM-1500 einen etwas längeren Auszug von Sonntag Ausgewertet. (Rohdaten, leider ohne Timestamp siehe Anhang) Hierbei habe ich mir zuerst die 1er Messages angeschaut. Ich habe mich hierbei am -r5 Dokument orientiert: https://www.mikrocontroller.net/attachment/550551/hoymiles-datenformat-r5.txt PV1.u und PV1.i konnte ich soweit nachvollziehen. Die nächsten beiden Bytes machen dann keinen Sinn. Allerdings entsprechen die weiteren beiden Bytes (was im Beispiel oben PV2.u wäre) genau den Produkt von PV1.u und PV1.i, also der Leistung in .1W Im Excel im Anhang habe ich dies auf dem Sheet "output_2022-03-27_18-20-16__1er" dargestellt. Spalte D - N entsprechen den HEX Werten, In Spalte P - W habe ich diese in Dez Werte umgerechnet. Bei den 2er Messages konnte ich keine parallelen zum -r5 Dokument finden. Also es sieht hier nicht nach AC Werten aus. Spalte S multipliziert mit Spalte T entspricht aber Spalte V (+/- ein bisschen). Könnte also wieder U, I und P sein. Bei den 3er Messages könnte Spalte V die AC Spannung sein. Aber das ist nur geraten.
Angehängte Dateien:
-
Cloud-01.png
9,8 KB -
Cloud-02.png
180 KB -
Cloud-03.png
31 KB -
Cloud-04.png
29 KB -
Cloud-05.png
38 KB
Hier btw ein Link zu einer DTU Pro: https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html Interessanter als die Hardware finde ich aber den Link mit den Zugangsdaten. Ich habe mal ein paar Bilder angefügt. Irgendwo scheint also auch noch die Temperatur und die Firmware Version versteckt zu sein.
Hallo, danke für die Screenshots. Das mit der Temperatur ist sehr hilfreich - ich hatte auch ein paar mal ähnliche Werte gesehen. Danke Marcel P.s.: ich würde ein paar Sachen/Informationen in deinen Screenshots unlesbar machen. Wer weiß wie die drauf sind.
Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power) pro Solar Panel oder ist das immer pro WR zusammengefasst? Ich bin bisher der Meinung, das ma neben nur die Gesamtleistung sieht und nicht jedes PV einzeln. Marcel
Sorry, für den SPAM. Basierend auf deinen Daten, könnte ich mir vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar Panel Nummer ist. Das würde auch Sinn machen, da ich in meinen Logs noch nie eine 02 gesehen habe und immer nur 01 gefunden habe (HM-400 hat nur einen Anschluß für einen Solar String). WR1 - Solar Panel #1
1 | 95 71603546 71603546 01... |
2 | [code] |
3 | |
4 | WR1 - Solar Panel #2 |
5 | [code] |
6 | 95 71603546 71603546 02... |
Anbei auch mal meine Daten analyse, wobei ich mir mit den letzten Feldern nicht ganz sicher bin. Bei mir stimmen die Daten mit meinen Messungen überein, aber die von Thomas ergeben nicht so viel Sinn (ggf. bedeuten die Werte doch was anderes).
Oliver F. schrieb: > Die Seriennummer muss in dem define in umgekehrter Bytereihenfolge > angegeben werden: > > An meinem Beispiel: > WR1 = xxxx73104619 > > Und im Byte 5 der Adresse die 01 nicht vergessen. > #define WR1_RADIO_ID ((uint64_t)0x1946107301ULL) // 0x1946107300ULL = > WR1 Danke für den Tipp! Jetzt läuft's
1 | 000486220 00 1234567801 00DE 1B 3 95 74950839 74950839 010001014C000B00240000062C0000093AEEE320 E320 1 |
2 | 005286328 00 1234567801 00DA 1B 1 95 74950839 74950839 010001014B000B00240000062C0000093BE85281 5281 1 |
3 | 008486552 00 1234567801 00DA 1B 1 95 74950839 74950839 010001014C000B00240000062C0000093BEF5260 5260 1 |
4 | 013286980 00 1234567801 00DC 1B 2 95 74950839 74950839 010001014A000B00240000062C0000093AE8C1A9 C1A9 1 |
5 | 016487192 00 1234567801 00DE 1B 3 95 74950839 74950839 010001014B000B00240000062C00000939EA86F1 86F1 1 |
6 | 021287296 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014B000B00250000062C00000938EA01FD 01FD 1 |
7 | 024487512 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014B000B00250000062C00000937E5E02C E02C 1 |
8 | 026085360 00 1234567801 00DA 1B 1 95 74950839 74950839 010001014B000B00250000062C00000937E5A904 A904 1 |
9 | 026132564 00 1234567801 00DC 1B 2 95 74950839 74950839 82138700230000000103E9003B000858D3F33E3C 3E3C 1 |
10 | 027687708 00 1234567801 00DC 1B 2 95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1 |
11 | 029285564 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1 |
12 | 029321264 00 1234567801 00DA 1B 1 95 74950839 74950839 82138700230000000103EA003B00081468072891 2891 1 |
13 | 032486288 00 1234567801 00D8 1B 0 95 74950839 74950839 010001014C000B00250000062C00000937E2E0CD E0CD 1 |
14 | 035685728 00 1234567801 00DC 1B 2 95 74950839 74950839 010001014C000B00250000062C00000938ED934C 934C 1 |
15 | 037285832 00 1234567801 00DE 1B 3 95 74950839 74950839 010001014C000B00250000062C00000938EDDA64 DA64 1 |
16 | 037333012 00 1234567801 00D8 1B 0 95 74950839 74950839 82138700230000000103EB003B0008D01AB0655A 655A 1 |
Marcel schrieb: > Noch eine Frage. Siehst du irgendwie die Leistung (Volt, Ampere, Power) > pro Solar Panel oder ist das immer pro WR zusammengefasst? Hallo Marcel, bei dem oben genannten Account handelt es sich ja um einen öffentlichen Test-Account den jeder verwenden kann (Es handelt sich nicht um meine Anlage). Aktuell zeigt die Detailansicht (siehe Cloud-05.png) für jedes Panel unterschiedliche Watt angaben (33 vs. 32W). Spannung und Strom sind beim Klick auf die Panels identisch (32,5V und 1,0A). Es kann sich hier natürlich auch um Rundungsungenauigkeiten handeln und Strom/Spannung/Leistung ist trotzdem individuell. Bzgl. dem Hex Wert nach den WR Seriennummern... Dann müsste ich aber bis zu 4 Nachrichten erhalten, zumindest hat der HM-1500 vier individuelle Ports. Grüße Thomas
Marcel schrieb: > asierend auf deinen Daten, könnte ich mir > vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar > Panel Nummer ist. Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele angeschlossen und an der Stelle nie eine 02 gesehen. Eine andere Frage: Habt ihr schon mal andere Anfagecodes ausprobiert, um andere Daten zu erhalten? Ich habe bei der seriellen Aufzeichnung mindestens 3 verschiedene Anfragepakete gesehen: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Martin schrieb: >Marcel schrieb: >> basierend auf deinen Daten, könnte ich mir >> vorstellen, das der HEX Wert nach den beiden WR Seriennummern die Solar >> Panel Nummer ist. > Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele >angeschlossen und an der Stelle nie eine 02 gesehen. Hallo, okay, das ist schon mal ein guter Hinweiß. Die Daten für das 02 Command machten auch nicht so viel Sinn. Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten passen bisher mit meinem Messungen. Werde heute auch mal probieren andere Requests zu senden und schauen ob und was zurück kommt. Marcel
Marcel schrieb: > Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten > passen bisher mit meinem Messungen. Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor. Du hattest einen HM-400 oder?
Marcel schrieb: > Ich hänge mal meine Interpretation des Protokolls mit an. Die Daten > passen bisher mit meinem Messungen. Danke für die Doku! Kann ich so bestätigen mit meinem HM-400.
Sorry bin gerade krankheitsbedingt ziemlich außer Gefecht. Hier sind mal die Logs von meinem HM-700 (2 Kanäle) für die letzten 2 Tage: - https://filetransfer.io/data-package/QBOaWm7M#link Geloggt wie unter https://github.com/grindylow/ahoy/blob/main/tools/rpi/README.md#example-run beschrieben. Wie viele Posts weiter oben ja entdeckt haben, sind die Antworten wohl je nach Wechselrichtertyp leicht unterschiedlich. Bei meinem sieht man plausibel die U, I, P-Werte für die beiden angeschlossenen Panels. Vielleicht fällt jemand zu den "unknown"-Werten was ein - vielleicht sind das die gleichen, die bei anderen Wechselrichtern in den Feldern für das "2te Panel" stehen? Kandidaten sind u.a. Tages- und Gesamtenergie (in Wh) sowie die Temperatur (in Zehntel-°C). Als "Auslöser" für die Antworten sende ich bisher wohlgemerkt nur im Sekundentakt eine 0x80-Nachricht. Das scheint ausreichend häufig zu einer Rückmeldung zu führen.
:
Bearbeitet durch User
So aus dem Bauch raus würde ich für CMD=0x02 mal tippen: - uk4, uk5: Tages-Energie Panel 1, 2 [Wh] (läuft am nächsten Tag wieder mit 0 los) - uk1, uk3: Gesamt-Energie seit Geburt (?), Panel 1, 2 [Wh]
...und dann gibt es noch die mysteriöse 0x83-Antwort. Über die beiden Tage verteilt kam die nur 49 mal:
1 | $ cat two-days-hm-700.log | grep '95 74 60 81 45 74 60 81 45 83' | cut -b 28- |
2 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e8 00 67 00 06 86 06 1e |
3 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 75 00 06 4f ee 3f |
4 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 17 03 e8 00 7c 00 06 94 08 0c |
5 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 23 03 e8 00 91 00 06 3d a0 d5 |
6 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 29 03 e8 00 9e 00 06 d5 43 db |
7 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 2d 03 e8 00 a3 00 06 51 61 44 |
8 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 32 03 e8 00 a5 00 06 5f 15 27 |
9 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 40 03 e8 00 b2 00 06 90 be 26 |
10 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 65 03 e8 00 d3 00 06 4d f8 f8 |
11 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 5e 03 e8 00 eb 00 06 a9 9c 7b |
12 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 5d 03 e8 00 f3 00 06 08 dc 81 |
13 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 41 03 e8 00 f8 00 06 58 71 6a |
14 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 5a 03 e8 01 00 00 06 03 6e cd |
15 | : 95 74 60 81 45 74 60 81 45 83 00 03 00 a3 03 e8 01 1b 00 06 a1 88 68 |
16 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 82 03 e8 01 57 00 06 9a ef 5a |
17 | : 95 74 60 81 45 74 60 81 45 83 00 02 00 61 03 e8 01 75 00 06 9e 7f 0d |
18 | : 95 74 60 81 45 74 60 81 45 83 00 02 00 6d 03 e8 01 5b 00 06 0f b5 74 |
19 | : 95 74 60 81 45 74 60 81 45 83 00 02 00 52 03 e8 01 4d 00 06 2e 30 f9 |
20 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 4a 03 e8 01 4e 00 06 4d ef 5c |
21 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 47 03 e8 01 4d 00 06 5e 07 a9 |
22 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 44 03 e8 01 4c 00 06 ac 22 7d |
23 | : 95 74 60 81 45 74 60 81 45 83 00 01 00 27 03 e8 01 2b 00 06 45 4e fc |
24 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 15 03 e8 01 13 00 06 c3 c5 fa |
25 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 01 07 00 06 55 2f 96 |
26 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 fd 00 06 83 78 f6 |
27 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 78 00 06 8f ef 08 |
28 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 00 00 00 00 7b 00 06 25 2a 64 |
29 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7f 00 06 b3 43 77 |
30 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 e9 00 7e 00 06 35 4f fc |
31 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 02 03 ea 00 82 00 06 ed 4b df |
32 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 8b 00 06 1c 6e 0d |
33 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 8f 00 06 ae 48 83 |
34 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 11 03 e8 00 90 00 06 a6 5e 82 |
35 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 13 03 e8 00 92 00 06 70 46 4c |
36 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0f 03 e8 00 9c 00 06 38 74 24 |
37 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 16 03 e8 00 9d 00 06 c8 67 df |
38 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a0 00 06 5d 79 71 |
39 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 a3 00 06 c5 e0 64 |
40 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 12 03 e8 00 ae 00 06 85 5a 98 |
41 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 07 03 e8 00 aa 00 06 ca b1 2d |
42 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 08 03 e8 00 a5 00 06 88 74 aa |
43 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0b 03 e8 00 a3 00 06 55 16 10 |
44 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0a 03 e8 00 9c 00 06 c0 56 fb |
45 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 9b 00 06 82 e1 13 |
46 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 09 03 e8 00 9d 00 06 10 5d 22 |
47 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 19 03 e8 00 9c 00 06 ef a9 38 |
48 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 0e 03 e8 00 a4 00 06 cd e2 7e |
49 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 10 03 e8 00 a1 00 06 b5 ce 31 |
50 | : 95 74 60 81 45 74 60 81 45 83 00 00 00 04 03 e8 00 9d 00 06 0f ac c1 |
Vielleicht ist da was bzgl. Kanal-Hopping drin? Hat jemand Ideen?
Hallo Thomas, > Welchen Request hast du denn gesendet um als Antwort eine 0x82 zu > bekommen? Diese ID kommt in meinen Daten bisher noch gar nicht vor. Diese Antwort kommt bei mir so mehrmals auf 0x15er Request zurück
1 | Send to channel: 40 |
2 | Time Wed Mar 30 14:56:30 2022 |
3 | |
4 | Sending packet of size: 27 |
5 | Now sending: 15 73 10 90 25 72 81 90 05 80 0B 00 62 44 6F 9E 00 00 00 05 00 00 00 00 94 87 EF ok... |
6 | Listen channel: 3 |
7 | Received: 95 73 10 90 25 73 10 90 25 01 00 01 01 82 00 1C 00 6C 00 00 41 C6 01 18 08 F7 07 |
8 | Got reply: |
9 | Voltage: 38.60V, Ampere: 0.28A, Power: 10.80W |
10 | Daily production: 280.000 W, AC Voltage: 229.5 V, Total production: 16.838 kW |
11 | Frequency: 0.000, Temperature: 0.0 °C |
12 | Received: 95 73 10 90 25 73 10 90 25 82 13 87 00 67 00 00 00 04 03 E8 00 FE 00 06 BB 44 0C |
13 | Got reply: |
14 | Voltage: 0.00V, Ampere: 0.00A, Power: 0.00W |
15 | Daily production: 0.000 W, AC Voltage: 0.0 V, Total production: 0.000 kW |
16 | Frequency: 49.990, Temperature: 25.4 °C |
17 | This round is over. |
Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief
wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die
wichtigen Teile des Codes in mein Programm kopiert. Das gibt mir die
Möglichkeit mit dem Code zu spielen, da ich auch alle Teile davon genau
verstehe. Ebenfalls setze ich auch immer die korrekte Zeit (vielleicht
ist es das).
Mein Script sendet den Request und hört dann 3 Sekunden auf dem Kanal 3.
Dann wartet es erneut 3 Sekunden und beginnt von vorne.
> Du hattest einen HM-400 oder?
Genau.
Ich habe jetzt auch einen zweiten ESP32 mit einem NRF Chip und die habe
ich jetzt so synchronisiert, das der eine eine Message sendet und der
andere dann zur gleichen Zeit verschiedene Kanäle durch hört. Ich hoffe,
das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber
vorstellen, das es eine Weile dauert.
Marcel
martin schrieb: > Das glaube ich nicht. Ich hatte bei meinen Tests auch schon beide Panele > angeschlossen und an der Stelle nie eine 02 gesehen. Schaut mal in die Wechselrichter nach, ob die tatsächlich 2 seperate MPPT-Tracker habe könnten. Bei meinen SG700 werden die 2 Eingänge für die Module intern gebrückt.
Angehängte Dateien:
Marcel schrieb: > Ich hoffe, > das ich dann dem Kanal-Hopping auf die Schliche komme. Kann mir aber > vorstellen, das es eine Weile dauert. Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen. Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83 auf bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz von den dreien kommen. Wenn eine andere Sendefrequenz genutzt wird, dann sind das bei mir 3 andere mögliche Antwortfrequenzen. z.b noch die 2475 Mhz. Nochmal das jpg mit Kommentaren.
Hallo, ich habe jetzt mal die Messages auf Kanal 40 gesendet und dann alle Kanäle einzeln von 1 - 128 für 3 Sekunden gehört. Da kam nie was, ausser eben auf Kanal 3. Ebenfalls habe ich mal mit der Anfrage bits rumgespielt. Es kommen zwar bei einigen Kombinationen Antworten, aber die machen bisher noch keinen Sinn. Hab die Daten mal angehängt. Marcel
Marcel schrieb: > Ich nutze aber nicht das Programm, welches hier geteilt wurde. Das lief > wegen dem Circular Buffer nicht auf meinem ESP32 und ich hab die > wichtigen Teile des Codes in mein Programm kopiert. Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack Overflows kämpfe. - Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die ganzen Libraries quält. Ist das normal? - Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme gab es? B. G. schrieb: > Wie schon mal beschrieben, reicht bei mir ein RX-Scan über 3 Frequenzen. > Wenn ich auf 2403 Mhz sende, dann kommen die 3 Antworten 01,02,83 auf > bis zu 3 Frequenzen ( auf 2423,2440 oder 2461 Mhz), nicht aber auf der > Sendefrequenz 2403. Die 3 Antworten können auch auf nur einer Frequenz > von den dreien kommen. Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61? Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80 gelauscht. Meine WR antworten nur auf Kanal 3 und 23. Die DTU sendet abwechselnd auf: 0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61. Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung abhängen? z.B. auf welchem Kanal WLAN aktiv ist?
Hallo Oliver > Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 > schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack > Overflows kämpfe. Do it :) > - Welche Entwicklungsumgebung nutzt Du? Bei Visual Studio Code mit > PlatformIO dauert jeder Build bei mir ewig lange, weil er sich durch die > ganzen Libraries quält. Ist das normal? Also ich nutze auch Visual Studio Code mit der PlatformIO extension. Wenn bei mir alles ein mal gebaut ist, dann dauert das neu kompilieren unter 1sec. Das Hochladen und den Boot Button zu drücken ist das was am längsten dauert :). Ich hänge mal mein Programm hier mit an. Ist alles in einer Datei und ich nutze keine eigene CRC Berechnung, sondern eine externe offizielle Libs. Sobald alles einigermaßen geht, würde ich den Code dann sauber machen. Aber derzeit bin ich so schneller. > - Warum konntest Du den Circular Buffer nicht nutzen? Welche Probleme > gab es? Um ehrlich zu sein, habe ich es noch nie hinbekommen Circular Buffer auf meinen ESPs zum laufen zu bekommen (ist aber auch schon Jahre her das ich es probiert habe). Soweit ich mich erinnern kann, muss man auf dem ESP Circular Buffer anders initialisieren und es gibt Probleme, die man beachten muss, mit irgendwelchen Integer Größen, die anders auf einem Nano und einem ESP32 sind. Bin mir da aber nicht mehr sicher. Ist wirklich schon sehr lange her und ich baue es immer um, wenn ich Circular Buffer sehe. Marcel
Hallo, ich habe auf Basis des Arduino Sketch ein kleines MQTT Gateway geschrieben (in JAVA) und teste die nächsten Tage. Nun frage ich mich wo die Reise hingeht. Ich persönlich finde folgendes Setup clever: Microcontroller (Arduino oder ESP ohne aktivem WIFI) und RF als relativ "dumme Empfängerhardware" mit USB Anschluss. Die "Software" (nodeJS, python, java oder auch Plugins für Homeautomation Systeme) dann auf einem beliebigen Computer (Raspi, Windows, Linux, Mac) laufen lassen. Die meiste "Intelligenz" ist in der "Software". Dies betrifft das Parsen der Daten sowie das Aufbereiten und versenden via MQTT. Falls die verschiedenen Hoymiles tatsächlich unterschiedliches Parsing erfordern, ist es m.E. einfacher das in der "Software" anzupassen (anstatt C code schreiben und Firmware Flash). Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte. Wie ist Eure Meinung?
Hallo Mag, ich finde schon, das es einen "Treiber" geben sollte der ein einheitliches Interface hat (unabhängig vom verwendetem Hoymiles). So wie du das beschreibst, klingt es ja wie ein Open MQTT Gateway Integration, die deine Anfrage in das jeweilige Protokoll (LORA oder dann eben Hoymiles umwandelt). Dann muss die Logic, in der Tat irgendwo anders sein. Ich persönlich würde eine ESPHome Version bauen, die dann die Werte ebenfalls - in einem einheitlichem Format - via MQTT oder HomeAssistant API wegschreibt. Höre aber auch sehr gerne andere Meinungen :) Marcel
Oliver F. schrieb: > Das heißt also, die WR senden bei Dir auf Kanal 23, 40 und 61? > Ich habe den Datenverkehr mit meiner DTU und den WR noch einmal länger > mitgeschnitten und dabei jeweils 5 Minuten auf jedem Kanal von 0 bis 80 > gelauscht. > Meine WR antworten nur auf Kanal 3 und 23. > Die DTU sendet abwechselnd auf: > 0, 3, 7, 11, 19, 23, 27, 29, 37, 39, 40 und 61. > Könnte die Auswahl der Kanäle durch die WR von der jeweiligen Umgebung > abhängen? z.B. auf welchem Kanal WLAN aktiv ist? Ich hab das vielleicht falsch beschrieben. Nicht mein DTU sendet auf 2403, sondern mein Atmel, der mir als DTU-Ersatz dient. Dein Original-DTU wechselt wohl schon die Sendefrequenzen. Ich bleibe mit meinem AVR beim Senden immer auf einer gleichen Frequenz ( 2403) und dann antwortet der WR mir immer mit den Telegrammen 01,02,80 auf den maximal 3 Frequenzen 2423,2440,2461, siehe jpg. Wenn ich eine andere Sendefrequenz nehme, dann antwortet der WR z.b. auf 2475 2423 und 2403. Aber mir scheint es, daß es vielleicht auch Unterschiede bei den jeweiligen WRs gibt. Ich selbst habe einen HM-600
Hallo, ich glaube die Bytes von den Seriennummern der Wechselrichter werden berücksichtigt. Wenn ich hier mal die letzten Daten anschaue und die Texte mit den Angaben zu dem Versionen der Wechselrichter lese, ergibt sich ein Muster. Ich denke, dieses Byte kann dazu genutzt um die Antworten auszuwerten. Weil meine HM-400 Antwort hat Fundamental andere Werte als die von einem HM-600 (Ampere, Volt etcpp). Vielleicht kann ja jeder, der demnächst hier schreibt, seine Version des Wechselrichters (HM-XXX) reinschreiben und seine Seriennummer? Dann kann man meine These mal validieren.
1 | HM-1500: |
2 | - 71 60 35 46 |
3 | HM-700: |
4 | - 74 60 81 45 |
5 | HM-600: |
6 | - 72 22 02 00 |
7 | HM-400: |
8 | - 73 10 90 25 |
Es sieht fast so aus, als wenn jede Version eines erste Byte hat. Marcel
> 74 95 08 39
Verdammt :D Die passt nicht ins Schema.
Wobei die DTU ja die ganze Seriennummer kennt. Ggf. ist den ersten 4
Zahlen die Version kodiert.
Meine wäre dann für den HM-400 Serial No: 1121 73109025
Marcel
:
Bearbeitet durch User
Schaut mal hier (Kapitel 6): https://www.manualslib.de/manual/793350/Hoymiles-Mi-300.html?page=16#manual Mit den ersten 4 Zeichen scheint man wohl Inverter als auch Version identifizieren können...
1 | Fehlersuche |
2 | Hoymiles hat die interaktive Leistung des Mikroumwandlersystems Mitte 2020 aktualisiert. |
3 | Wenn Sie den Mikroumwandler mit Seriennummer "1022xxxxxxxx" verwenden, so beziehen Sie |
4 | sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikroumwandler mit |
5 | Seriennummer "1020xxxxxxxx" und "1021xxxxxxxx" verwenden, so beziehen Sie sich bitte auf |
6 | Abschnitt 6.2 und Abschnitt 6.4. |
7 | *Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von |
8 | Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und |
9 | DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren. |
Gleiches gibt es wohl auch für die größere Reihe: https://www.manualslib.de/manual/811724/Hoymiles-Mi-1000.html?page=17#manual
1 | Fehlersuche |
2 | Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems Mitte 2020 aktualisiert. |
3 | Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" verwenden, so beziehen |
4 | Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikrowechselrichter mit |
5 | Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen Sie sich bitte auf |
6 | Abschnitt 6.2 und Abschnitt 6.4. |
7 | *Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von |
8 | Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und |
9 | DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren. |
:
Bearbeitet durch User
HM-1200 1161xxxxxxxx HM-1500 1161xxxxxxxx
Sehr gut, das hilft schon mal wenn wir weitere Daten analysieren und später um den Parser zu schreiben. Ich denke mal, das die ersten 4 Ziffern immer eine Gruppe beschreiben und die Antworten im gleichen Format sind. Danke Marcel
Hallo Zusammen, *Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren. Das mit den og. unterschiedlichen Versionen der Wechselrichter und DTUs könnte mit dem verbauten NRF24L01+ Chip gegenüber den bei Seriennummer 1062x, bzw. DTU-Pro, DTU-G100 und DTU-W100 vermutlich verbauten NRF5x Chip zusammenhängen. Folgendes Zitat aus dem Enhanced ShockBurst (ESB) Dokument scheint die beiden Modi und Kombinationen zu erklären: Enhanced ShockBurst (ESB) - Features https://developer.nordicsemi.com/nRF_Connect_SDK_dev/doc/PR-3842/nrf/ug_esb.html * 1 to 32 bytes dynamic payload length in legacy mode * 1 to 252 bytes static payload length between nRF5 Series devices
HM-350: 1121 72xxxxxx HM-700: 1141 74xxxxxx
HM 1200 1161 70523283 ich habs mal einen Tag lang laufen lassen und sehe 4 arten von Antworten hab sie mal beigefügt.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht und nach Bildern von Hoymiles Wechselrichtern mit Seriennummern gesucht. Ebenfalls habe ich die Seriennummern aus diesem Thread verwendet. Das Ergebnis, insgesamt 29 WR, befindet sich im Anhang. Als Bild habe ich noch das Ergebnis angehängt. Also das Mapping zwischen Typ und Prefix. Das sieht erstmal recht eindeutig aus.
Angehängte Dateien:
Mag C. schrieb: > Hier ist noch ein HM-800 :-) -> 1141 Danke für den Hinweis :) Habe ich noch in das Ergebnis aufgenommen (siehe Anhang). Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten auch die Telegramme der farbig markierten Inverter kompatibel sein.
Hallo Thomas, > ich habe mal etwas dieses Internetz bzw. die Google Bildersuche bemüht Das ist natürlich clever und erheblich effizienter als hier zu fragen. Chapeau > Wenn der Verdacht mit den linken 4 Nummern korrekt ist, dann sollten > auch die Telegramme der farbig markierten Inverter kompatibel sein. Davon gehe ich auch aus. In hab mir vorhin noch mal den Thread durchgelesen und dabei die Bilder von der geöffnetem DTU angeschaut. Darin ist ja scheinbar eine RTC verbaut. Da ich in den vergangenen Tagen ein einziges mal wirklich aller 60 Sekunden für einen längeren Zeitraum konstant Antworten vom WR bekommen habe, kann es sein, das der WR ggf. den Timestamp und die differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren ggf. die Uhren meiner ESP32 und des WR grob syncron. Was denkt Ihr ? Ebenfalls habe ich mich mal in das Konzept von channel hopping (grob) eingelesen und eine synchronisierte Zeit oder Tackt ist dabei wohl essentiell. Ich hab vor ein paar Minuten mal ein RTC DS3231 an meinen ESP geklemmt und den code so verändert, das die Zeit immer von der RTC kommt. Vielleicht klappt es ja morgen bei Sonne. Marcel
Hallo, hab nen HM-1200 116172216067 Tolles Projekt bin mal auf das Ergebnis gespannt.
Mag C. schrieb: > Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den > Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte. Da ich weder MQTT noch ESPHome oder sonstige Home-Automation nutze, wäre gerade das zitierte meine Lösung. Bei mir laufen mehrere ESPs und als Master fungiert ein RasPi, der mittels cron-Jobs die Daten von den ESPs sammelt, speichert, auswertet, grafisch darstellt, ... Zu der "Software" : die brauch man nur einmal zu entwickeln, die Auswertung der empfangenen Daten könnte man über eine Tabelle (im EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so aussehen: 1141 HM-600 AC-Spannung 02 12 2 10 bedeutet: Die Wechselspannung ist im Telegramm 02, beginnt ab Byte 12, ist 2 bytes lang und muss noch durch 10 geteilt werden. Wenn das Projekt so richtig in Software umgesetzt wird (Github), hätte ich folgenden Vorschlag: 1) Die Kommunikation in einen Kern packen, der für Arduino, ESP, RasPi passt, am besten in C. 2) Funktionalität darüber hinaus in Plugins packen, die man über #define mit dazu linkt. Weitere Funktionalität wären zB: MQTT, ESPHome, Display, Webserver, Upload, ...
Marcel A. schrieb: > kann es sein, das der WR ggf. den Timestamp und die > differenz zur letzten Anfrage ermittelt. Und an diesem einem Tag waren > ggf. die Uhren meiner ESP32 und des WR grob syncron. Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer konstanten 0x80-Anfrage (jede Sekunde) laufen:
1 | 15 74 60 81 45 78 56 34 12 80 0b 00 62 46 d3 0f 00 00 00 05 00 00 00 00 92 ea c3 |
Er scheint damit genauso häufig zu antworten wie zuvor, als ich jede Sekunde die aktuelle Uhrzeit mitgeschickt hatte (siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?").
Mag C. schrieb: > Im Vergleich zu einer all-in-one ESP/Wifi Lösung hätte das auch den > Vorteil, dass man nicht das "37. IOT" Gerät im WLAN hängen hätte. Meine Interessen liegen da ähnlich, ich komme eher aus der RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen. Das nette daran ist, dass man insbesondere während der Experimentierphase sehr einfach Anpassungen machen kann, ohne dass man immer gleich einen Controller neu flashen muss. Aber na klar gibt es auch gute Gründe für Arduino/ESP32 Implementierungen. Unsere Forschungen hier sind für beide Ansätze gleichermaßen hilfreich. Habe soeben nochmals die in Entstehung befindliche `ahoy` Python-Software aktualisiert, diese sendet jetzt die empfangenen Daten gleich via MQTT raus. * https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py
Hallo petersilie,
> Also ich hatte jetzt meinen Logger für knapp zwei Tage mit immer einer
konstanten 0x80-Anfrage (jede Sekunde) laufen:
Ja, ich habe meinen Logger mit RTC seit heute morgen laufen und sehe
ebenfalls keine Besserung in der Antworthäufigkeit :/
Marcel
Angehängte Dateien:
Logs von meinem HM-600, auf die Schnelle ein altes Projekt umgeändert.
Angehängte Dateien:
-
response_packet.png
14 KB
Hubi schrieb: > Zu der "Software" : die brauch man nur einmal zu entwickeln, die > Auswertung der empfangenen Daten könnte man über eine Tabelle (im > EEPROM, LitteFS, Spiffs,..) dekodieren, etwa könnte eine Zeile so > aussehen: > 1141 HM-600 AC-Spannung 02 12 2 10 Hallo Hubi, ich bin mir nicht sicher, ob dass so einfach möglich ist. In meinen Daten von früher habe ich gesehen, dass die gleiche Paket-ID wohl verschiedene Inhalte haben kann, je nach dem welcher Request zuvor kam (siehe Bild oder früherer Post): Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Anscheinend kommt es auf die vorige Abfrage an. Allerdings habe ich das bisher nicht in den Funk-Daten beobachtet, die Mitschnitte in der Excel sind von der DTU-internen seriellen Kommunikation. Kann das jemand verifizieren?
Guten Tag! Ich habe H M 600 114170810815 und DTU W100 10D 373114359. Kann mir jemand helfen, die “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer gibt es nicht an, sagt, dass er selbst der Installateur ist.
Hello All. I just bought 3 x Hoymiles HW1500 for my PV installation. I will install them within one month. How could I contribute to your project to proceed with creating a reverse-engineered and open source solution to communicate with those micro inverters. I have some SDR usb dongle available to put it to work as well. Kind regards WK
Martin G. schrieb: > Meine Interessen liegen da ähnlich, ich komme eher aus der > RaspberryPi+Python Ecke. Einen RasPi habe ich sowieso schon für > verschiedene Hausautomations-Zwecke laufen, und der kann problemlos an > seinem SPI-Bus noch ein "dummes" NRF24L01+-Modul mitbedienen. Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder ESP32 zur Verfügung stellen könnte Raspi, schön und gut - aber meiner ist zu weit weg vom WR - gerade die Hoymiles-WR sind ja eigentlich dafür gedacht auf dem Dach montiert zu werden?
Sergey S. schrieb: > Guten Tag! Ich habe H M 600 114170810815 > und DTU W100 10D 373114359. Kann mir jemand helfen, die > “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer > gibt es nicht an, sagt, dass er selbst der Installateur ist. Hallo, eventuell können die helfen: https://www.enercab.at/hoymiles/1067-hoymiles-pv-monitoring-dtu-wlite.html Dort ist eine +49er Telefonnummer vorhanden. Mein HM600 SNR: 114172609296 wartet noch auf die PV-Module.
Heinz R. schrieb: > Ich würde mich sehr freuen wenn hier jemand was für den EPS8266 oder > ESP32 zur Verfügung stellen könnte Mein Plan wäre eine Library aka. https://github.com/atc1441/NETSGPClient Durch die NRF24 Library wäre dies dann vmtl. auch sowohl für ESP32 als auch ESP8266 nutzbar (und mit etwas Glück auch nativ unter Linux). Was man außen rum baut ist wieder ein ganz anderes Thema. Aber wie @petersilie schon sagt, die Grundlegenden Dinge die aktuell laufen eignen sich sowohl für Python als auch für eine C Implementierung. Erstmal muss man allgemein verstehen was passiert :) Habe heute einen ganzen Tag mitgelogged und werde das jetzt Auswerten. Spontan sehe ich aber nur 01er, 02er und 03er Nachrichten. (Gepulled habe ich die Daten mit dem ahoy.py Script)
Waldemar K. schrieb: > How could I contribute to your project to proceed with creating a > reverse-engineered and open source solution to communicate with those > micro inverters. > > I have some SDR usb dongle available to put it to work as well. Hello Waldemar, and welcome! One of the unsolved mysteries is how the inverters and DTU "hop" between different frequencies. Maybe scans with your SDR dongle can help.
Ich habe mal wieder das Format-Beschreibungs-Dokument aktualisiert. Leider immer noch ein bisschen durcheinander und unvollständig. Falls jemand Lust hat, hier mitzuhelfen - gerne melden! https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt
:
Bearbeitet durch User
Martin G. schrieb: > Falls > jemand Lust hat, hier mitzuhelfen - gerne melden! Gerne. Ich bin dir gerade auch schon auf github gefolgt. Also 0x83 Nachrichten sehe ich bei mir garnicht. Das ahoy.py Script liefert bei mir wie gesagt 1-3er Nachrichten. Ich habe in der Excel Datei im Anhang mal 3 Sheets gemacht. Für jede Nachricht eines. Ich habe aktuell am HM-1500 nur 3 Panels. Daher sollte irgendein Wert null sein. (Muss morgen mal prüfen welcher Kanal genau nicht angesteckt ist) Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x übertragen, der Strom und die Leistung jedoch 4x. Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw. geben aktuell Sinn. (bzw. ich sehe es gerade nicht)
Thomas B. schrieb: > Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x > übertragen, der Strom und die Leistung jedoch 4x. Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel Deshalb evtl. nur 2 Messwerte?
Heinz R. schrieb: > Thomas B. schrieb: >> Mir scheint es auch so, als würde die Spannung für die 4 Kanäle nur 2x >> übertragen, der Strom und die Leistung jedoch 4x. > > Der HM-1500 hat nur 2 MMP-Tracker - je 2 Eingänge sind quasi parallel > > Deshalb evtl. nur 2 Messwerte? Und HM-600 auch zwei?
Sergey S. schrieb: > Und HM-600 auch zwei? Ja der HM-600 hat 2 Eingänge mit separaten MPT. Ich hoffe, dass ich dies Wochenende meines Setup endlich soweit bekomme, dass ich auch an meinem HM-600 lauschen kann...
Thomas B. schrieb: > Die 3er Nachrichten könnten die AC Werte sein. Aber was genau? Spannung > ist vielleicht noch ersichtlich, aber weder Frequenz noch Strom usw. > geben aktuell Sinn. (bzw. ich sehe es gerade nicht) Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten: - Spalte T: Energie [Wh] seit letztem Start - Spalte S: aktuelle AC-Leistung [W] - Spalte R: Energie [Wh] seit Geburt - Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum? - Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung um die 0,6°C/0,7°C kalt?
Angehängte Dateien:
Hallo, Ich habe mal ein paar Daten des HM-400 aufgezeichnet zum Vergleich mit meinem AC-seitigen Shelly Plus 1PM. Sieht alles sehr gut aus! Das Setup mit Nano (FDTI Version) und nRF24L01+ zieht sich übrigens etwa 0,35W aus dem USB. Die Scanhäufigkeit habe ich verringert auf ca. 1 mal pro Minute. Ich nutze "RF24_PA_MIN"
Es gibt ein Dokument mit der Modbus-Beschreibung. Evtl. helfen die dort vorhandenen Beschreibungen der Telegramme und Befehle. Quelle: https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
Martin G. schrieb: > Die 03er-Nachricht sieht mir sehr ähnlich zu dem aus, was bei meinem > HM-700 als 83er-Nachricht herauskommt. Damit würde ich mal raten: > > - Spalte T: Energie [Wh] seit letztem Start > - Spalte S: aktuelle AC-Leistung [W] > - Spalte R: Energie [Wh] seit Geburt > - Spalte P: mysteriös, leicht ansteigende Werte um 2000 herum? > - Spalte E: mysteriös. War es vielleicht zum Zeitpunkt der Aufzeichnung > um die 0,6°C/0,7°C kalt? Hallo Martin, An dem Tag von dem die Aufzeichnung stammt hat ein Gosund Zwischenstecker ca. 1kWh gemessen. Die Gesamtproduktion die die Gosund gemessen hat seit Inbetriebnahme des Inverters liegt bei ca. 240kWh. - Spalte T: Wäre damit zu hoch, und ich würde eher einen Kommawert erwarten - Spalte S: Nachdem es ein ganzer Tag ist hätte ich einen ähnlichen Verlauf wie bei den DC Kurven erwartet. Also erst steigend, dann fallend. - Spalte R: Kommt mir für den Gesamtertrag zu hoch vor - Spalte P: Ggf. sind das auch Werte um 200 herum wenn man den Wert statt durch 10 durch 100 teilt. Muss ich beobachten wie sich das heute entwickelt. (Ggf. Gesamtleistung seit Geburt, dann würde aber der Gosund Mist messen) - Spalte E: Hätte die Temperatur v.a. unterm Tag eher im Bereich 5-10 Grad geschätzt.
Marcel schrieb: > Hallo Oliver > >> Ich habe auch überlegt auf ESP32 umzusteigen, weil der Atmel 328 >> schwachbrüstig ist und ich immer wieder mit zu wenig RAM oder Stack >> Overflows kämpfe. > Do it :) Hallo Marcel, ich habe deinen Code mit einem ESP8266 Nodemcu am laufen: -musste das getLocalTime(..) nachimplementieren, weil das das nur am ESP32 gibt -musste natürlich die Pins ändern -musste in der Receive-Loop ein yield(); einbauen, da sonst der wdt getriggert hat. habe meine WR und DTU Serial eingetragen .... .... sehe auf den Request zwar ein "ok" .... dann kommt aber keine Antwort vom WR
Hurra, es hat geklappt :) Ich empfange jetzt stabil Daten vom HM-600 aus etwa 15m Distanz. Setup: * HM-600 S/N 114172014650 * Arduin0 Nano V3 * NRF24L01 + separater Spannungsregler (damit geht bei mir RF24_PA_HIGH ohne Probleme) * Software von https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv Hilft es weiter, wenn ich einfach mal laufen lasse und den Output protokolliere und hochlade?
Carsten B. schrieb: > Hilft es weiter, wenn ich einfach mal laufen lasse und den Output > protokolliere und hochlade? Auf jeden Fall. Damit kann man das über einen längeren Zeitraum betrachten. Das macht es einfacher die Werte und Felder in den Telegrammen zu bestimmen!
Hallo, ich habe, HM-1200 3*350 W Panels angeschlossen Arduin0 Nano V3 NRF24L01 + Ich koennte auch Daten sammeln, helfen. Was muss ich tun um dieses Setup zum Fliegen zu bringen. Kurzanleitung moeglich? Danke
Ich hätte jetzt je eine Version von -NR24_SendRcv -Marcel's ESP32 code der auch auf ESP8266/Nodemcu kompiliert und läuft. Wenn das für noch jemanden von Interesse ist bitte melden.
Hallo Martin, ich hätte großes Interesse an der ESP-Version. Versuche mich hier gerade an einem Arduino Mini Pro - bekomme den in Platformio nicht geflasht... ESP8266 würde es evtl einfacher machen Viele Grüße
Auf die Schnelle: Hardware Nano V3 pin --- pin NRF24L01 D2 ----------- IRQ D6 ----------- CSN D9 ----------- CE D11 ----------- MISO D12 ----------- MOSI D13 ----------- SCK Software: https://github.com/grindylow/ahoy/tree/main/tools/nano/NRF24_SendRcv Ich habe es im Arduino IDE übersetzt und hochgeladen Seriennummer des HM musst du im Sourcecode eintragen wie folgt (NRF24_sniff.cpp): #define WR1_RADIO_ID ((uint64_t)0x5046017201ULL) // WR1 HM-600 Das ist sind die letzten 4 Byte der S/N Rückwärts plus eine 01 am Ende. Meine S/N ist 114172014650
Carsten B. schrieb: > Ich habe es im Arduino IDE übersetzt und hochgeladen welche Datei lädst Du hier in der Arduino IDE? Müsste es hierzu nicht eine .ino geben
Heinz R. schrieb: > ich hätte großes Interesse an der ESP-Version. Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von Links nach rechts ein ... das 5. byte muss 01 sein. Ich habe den Code auf das originale CircularBuffer vom Arduino portiert, deshalb sind hier auch weniger Files dabei als im GitHub Link von weiter oben. Es sollte auch für Arduino Nano / Uno weiter kompilieren.
...hier ein scan von meinen 2 (HM-350 und HM-700) WR
Carsten B. schrieb: > Ich habe sie einfach umbenannt... Ach das geht? lass uns das gerne mal in einem separaten Thread erörtern? :-)
Angehängte Dateien:
-
220422-excel-01.png
310 KB
Thomas B. schrieb: > Auf jeden Fall. Damit kann man das über einen längeren Zeitraum > betrachten. Das macht es einfacher die Werte und Felder in den > Telegrammen zu bestimmen! Hallo in die Runde, Angehängt die Daten, die ich heute mitgeschrieben habe mit dem HM-600. Zwischendrin hat der Nano 2x kurz neu gestartet (Wackelkontakt), die Bereiche ggf.raus löschen. Ich bin grade dran, das mit der Excel, die hier gepostet wurde ein wenig auszuwerten. Mit den "01" Messages bin ich fertig und komme zu dem Ergebnis auf dem angehängten Sreenshot. Spalte T enthält die addierten Leistungswerte bei der DC-Anschlüsse. Passt grafisch ganz gut überein mit dem, was mein Shelly heute auf der AC-Seite mitgeloggt hat. Ich poste nachher noch meine Auswertung für die weiteren Messages. Viele Grüße Carsten
:
Bearbeitet durch User
Angehängte Dateien:
-
Diagramm.PNG
29 KB -
Diagramm2.PNG
8,5 KB
Hier mal ein Tageslog von meinem HM-1200 es sind 2x 19V Panels in reihe je 130W an einem der 4 Anschlüsse dran. Das ergebniss passt noch nich ganz zu der format description. Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert? bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, was kann das sein ? :)
Angehängte Dateien:
-
220422-excel-02.png
26 KB
Chris A. schrieb: > Hier mal ein Tageslog von meinem HM-1200 > bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, > was kann das sein ? :) Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02 plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die Netzspannung und die Netzfrequenz drin ist. Siehe Bild.
> Ich sitze auch grade dran und beim HM-600 hat sich für mich für 02 > plausibel ergeben, dass dort die kumulierte DC und AC Leistung, die > Netzspannung und die Netzfrequenz drin ist. Siehe Bild. ok, aber Netzspannung und Frequenz ist bei meiner 02.. Anwort nicht zu finden. Oder überseh ich was ? auch bei der 01.. Antwort scheint es einen Unterschied zu geben. Die Amps machen da keinen sinn oder ? 020000BC8B0000000F0009000100010000A6E639 010001015200020032000600A800000283D9A089
Carsten B. schrieb: > Ich poste nachher noch meine Auswertung für die weiteren Messages. Hier nun meine Auswertung, soweit wie ich gekommen bin: Ergebnis Excelauswertung 02.04.2022: 01 Telegramme: Spalte N: U1 0,1V Spalte O: I1 0,01A Spalte O: P1 0,1W Spalte Q: U2 0,1V Spalte R: I2 0,01A Spalte S: P2 0,1W 02 Telegramme: Spalte N: E seit „Geburt“ ? Wh Spalte O: E DC akt. Tag ? Wh Spalte Q: E AC akt. Tag ? Wh Spalte R: U AC 0,1V (Netzspannung) Spalte S: F 0,01 Hz (Netzfrequenz) Ob die kumulierten Tagesangaben zutreffen zeigt sich Morgen... 03 Telegramme: empfange ich keine 81 Telegramme: kann ich mir keinen Reim drauf machen 83 Telegramme: kann ich mir keinen Reim drauf machen Ergänzung zum Setup des HM-600: An beiden Eingängen sind je 350Wp angeschlossen Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht messen.
:
Bearbeitet durch User
Manchmal bin ich einfach naiv-pragmatisch und hin und wieder klappt das sogar... Ich bin jetzt nicht der Programmierprofi und habe bisher nur die Arduino-Umgebung benutzt. Bevor ich mir die Mühe mache, eine neue Umgebung aufzusetzen, dachte ich, ich probiere es einfach mal :-)
Carsten B. schrieb: > > Erkenntnis: bei Dunkelheit sendet der WR nichts, passt ja auch gut zum > erfreulich kleinen Nachtverbrauch der HM. Mein Shelly kann den nicht > messen. Guten Abend, die Wechselrichtern werden aus dem DC Anteil versorgt und deshalb sind sie bei wenig Licht bzw Nacht nicht ansprechbar. ich lese hier schon eine ganze Weile mit. Momentan habe ich einfach keine freien Zeitslots mich hier einzubringen, leider. Auch ich hätte gerne den momentan benutzten DTU Pro ausser Betrieb und würde gerne irgendwo auf meinem Synology NAS ein Datengrab schaffen um meine Ertragszahlen zu speichern. Was mir persönlich aufgefallen ist, dass aus meinen 60 Wechselrichtern in allen Paketen die Seriennummern nicht fortlaufend einsortiert sind sondern immer in einer gewissen Struktur und hierbei meine ich nur die letzten 4 Ziffern. Kann es sein dass sich darin die Kanalnummern für den jeweiligen Wlan Kanal verschlüsseln, man stellt sich vor dass bei einer grösseren Anlage sonst schnell zu einer Menge Datenkollisionen kommen würde. Viel Erfolg in die Runde, programmiere aus Leidenschaft in C und würde gerne helfen, habe aber momentan zu viel andere Dinge die in der Priorität weiter oben sind Solong B
Chris A. schrieb: > Volt passt, aber Watt hab ich irgendwie 2 mal, nur anders skaliert? > bei der 02... antwort hab ich eine schöne ansteigende Kurve gefunden, > was kann das sein ? :) Hallo Chris, die Telegramme von HM-1200 und HM-600 werden nicht kompatibel sein. Siehe: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Schau dir mal das Excel in Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" an In den 1er Messages habe ich einmal die Spannung, 2x den Strom und 2x die Leistung. In den 2er Messages habe ich bisher 1x die Spannung und 1x die Leistung gefunden. Ich habe nur 3 Panels dran, darum vmtl. nur insgesamt 3x Strom und Leistung. In den 3er Messages habe ich nur die AC Spannung gefunden. Werde mir aber deinen Dump noch ansehen.
Carsten B. schrieb: > 81 Telegramme: kann ich mir keinen Reim drauf machen > > 83 Telegramme: kann ich mir keinen Reim drauf machen > > E Wenn Du in das von mir weiter oben bereitgestellte Dokument (Hoymiles Modbus implementation..., Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") ab Seite 8 unter 4.2.1 schaust, dann wirst Du dort bei den Function Codes diese Werte als Antwort auf fehlerhaften "Read Single Device Status" und "Read Device Data" finden. Könnte vielleicht passen...?
:
Bearbeitet durch User
Moin Peter, danke für den Hinweis, kann wirklich sein, dass 81 nur Fehlerhafte Übertragungen sind. Bei den 02-Messages bin ich mir bei Spalte Q inzwischen recht sicher, dass Spalte T die WR-Temparatur ist. O und Q sind vermutlich eher der Tagesertrag je Kanal. 02 Telegramme: Spalte N: E seit „Geburt“ Wh (sieht gut aus, zählte heute morgen weiter hoch) Spalte O: E DC akt. Tag ? Wh (vielleicht doch E für Kanal 1 ?) Spalte Q: E AC akt. Tag ? Wh (vielleicht doch E für Kanal 2 ?) Spalte R: U AC 0,1V (Netzspannung) (passt) Spalte S: F 0,01 Hz (Netzfrequenz) (passt) Spalte T: Temperatur 0,01 °C (neu) Mal sehen, was der Tag bringt... Carsten
Angehängte Dateien:
-
plot_response_times.png
39 KB
Mal zwischendurch ein Themenwechsel zu "Channel Hopping": Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen "Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im Anhang. Da zeichnet sich klar ab, dass * die "0x01"-Nachrichten immer nach ca. 18 ms eingehen, * die "0x02"-Antworten immer nach ca. 67 ms und * die "0x83"-Antworten immer nach ca. 116 ms. Das ist für "Anfrage auf Kanel 40, Antwort auf Kanal 3".
Martin P. schrieb: > Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die > Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann > trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von > Links nach rechts ein ... das 5. byte muss 01 sein. Hallo Martin, danke, scheint zu funktionieren Ich bekomme jetzt beiliegende Daten - sieht richtig aus? Es ist ein HM-1200 - nur 2 Eingänge belegt Aktuell liefert er ca. 35W Viele Grüße
Angehängte Dateien:
-
HM1200_Heinz.PNG
2 KB
Heinz R. schrieb: > Ich bekomme jetzt beiliegende Daten - sieht richtig aus? > > Es ist ein HM-1200 - nur 2 Eingänge belegt > Aktuell liefert er ca. 35W Hi Heinz, ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber keine Leistung. An welchen Anschlüssen hast du die Panels dran ? links oder rechts? Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann nichts sinnvolles mehr bei der 01 Antwort.
Chris A. schrieb: > Heinz R. schrieb: >> Ich bekomme jetzt beiliegende Daten - sieht richtig aus? >> >> Es ist ein HM-1200 - nur 2 Eingänge belegt >> Aktuell liefert er ca. 35W > > Hi Heinz, > > ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber > keine Leistung. > > An welchen Anschlüssen hast du die Panels dran ? links oder rechts? > Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann > nichts sinnvolles mehr bei der 01 Antwort. Das sieht so aus wie bei meinem HM-1500. Allerdings würde ich nur Spalte N als Spannung interpretieren. - Spalte N: 26,2V - Spalte O: 0,02A - Spalte P: 0,03A - Spalte Q: 0,6W (26,2 x 0,02 mit Rundungsfehlern?) - Spalte R: 0,9W (26,2 x 0,03 mit Rundungsfehlern?)
Chris A. schrieb: > ich hab auch den HM-1200. Bei deinen 01 Daten sehe ich z.B. 26,2V aber > keine Leistung. > > An welchen Anschlüssen hast du die Panels dran ? links oder rechts? > Ich hatte meine mal auf der linken Seite angeschlossen, es kam dann > nichts sinnvolles mehr bei der 01 Antwort. Hallo Chris, je ein Panel aktuell pro Seite Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt Ich messe an ihm ca. 23V, ca. 10mA Das andere Panel hat aktuell ca. 29V, ca. 1 A Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte ungefähr passen? Hast Du DIr eine Excel-Vorlage gebaut? Viele Grüße
> Hallo Chris, > > je ein Panel aktuell pro Seite > > Allerdings ist eines der beiden Panel aktuell vom Schnee bedeckt > Ich messe an ihm ca. 23V, ca. 10mA > > Das andere Panel hat aktuell ca. 29V, ca. 1 A > > Anbei noch mal ein Log von gerade eben - dort müssten dann diese Werte > ungefähr passen? > > Hast Du DIr eine Excel-Vorlage gebaut? > > Viele Grüße Hi Heinz, ich hab das hier verwendet: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo zusammen, endlich habe ich meinen WR HM-700 bekommen, läuft auch, aber antwortet nicht. grmpf Ich habe sowohl eigene Entwicklungen als auch adaptierte Sniffer am Arduino Mega2560 erfolglos versucht. Zudem widersprechen sich aktuell die Aussagen bzgl. der nötigen Seriennummern-Bytes etwas: Martin P. schrieb: > Heinz R. schrieb: > Also du brauchst auch hier Platformio, und der wichtigste Punkt sind die > Wechselrichter-Seriennummern. Wenn du die Nummer vor dir hast, dann > trägst du die ersten 4 bytes von rechts nach links gelesen, im Code von > Links nach rechts ein ... das 5. byte muss 01 sein. In der (ursprünglichen) github-Doku von Petersilie heisst es: > Hier werden 4-Byte-Adressen verwendet, die direkt aus den letzten 8 Stellen der Seriennummer des Wechselrichters bzw. der DTU gewonnen werden... Verwirrung... ;-) Sind es nun die ersten 4 oder die letzten 4? - Ich nehme mal an, es sind die letzten 4 BCD Bytes der Seriennummer. Jetzt ist noch die Frage, wie rum die Dinger in das Define rein müssen. MSB oder LSB neben der abschließenden 0x01? Laut Doku würde ich mal annehmen, dass das MSB daneben kommt. Also z.B. bei WR Serno. 11 41 74 60 84 85: #define WR1_RADIO_ID ((uint64_t)0x8584607401ULL) Ich habe beide Varianten schon getestet, die PA settings sowie SPI speed rauf und runter genudelt. - Nix geht... :-( Config und erweiterte Ausgabe bei mir wie folgt - ich sende nur das 80er Telegramm: Radio 1: SPI Speedz = 1 Mhz STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xdeadbeef01 0x2888817201 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0xdeadbeef01 RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20 EN_AA = 0x00 EN_RXADDR = 0x02 RF_CH = 0x03 RF_SETUP = 0x23 CONFIG = 0x37 DYNPD/FEATURE = 0x00 0x00 Data Rate = 250 KBPS Model = nRF24L01+ CRC Length = Disabled PA Power = PA_LOW ARC = 15 Send... CH40 157460848572818828800B00623C8EA30000000500000000375EC7 Dest: 0174608485 WR1 TX error! 288828 37640 Send... CH40 157460848572818828800B00623C8EA5000000050000000097754A Dest: 0174608485 WR1 TX error! 2488380 37700 usw. Achja: Ich habe das lustige PA-Modul mit externer Antenne, das hängt über den mitgelieferten LDO Adapter am Arduino 2560 folgendermaßen: VCC->5V, GND->GND, SCK->52, MI->50, MO->51, IRQ->2, CE->7, CSN->8 IMHO sollte das passen. Was übersehe ich? Hat irgendjemand einen heissen Tipp? Danke für die Geduld, Lars
Lars B. schrieb: > Also z.B. bei WR Serno. 11 41 74 60 84 85: > #define WR1_RADIO_ID ((uint64_t)0x8584607401ULL) ja genau so - sorry für die Verwirrung!
Hi Martin, danke für die Bestätigung. - Ich suche dann mal weiter, wo der Hund begraben liegt... ;-) ***UPDATE *** Habe den begrabenen Hund gefunden! :-) :-) :-) Der Receive-Interrupt im Arduino-Code wurde nicht aktiviert/deaktiviert. Die Routine wird zwar über das attach eingehängt, aber die existierenden Defines #define DISABLE_EINT EIMSK = 0x00 #define ENABLE_EINT EIMSK = 0x01 lassen den klassischen Arduino eher kalt. ;-) Ich habs mal durch folgendes ersetzt und dann klappert das auch: #define DISABLE_EINT noInterrupts(); #define ENABLE_EINT interrupts(); Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe anbei... :) Cheers, Lars
:
Bearbeitet durch User
Lars B. schrieb: > Jetzt bekomme ich responses vom HM-700, sind aber noch ungeparsed. Siehe > anbei... :) ja das mit den Interrupts musste ich für den ESP auch so machen ... Ich lese ja auch einen HM-700 (und einen HM-350) aus und habe mittlerweile den von mir auf ESP angepassten NF24Send_Rcv Code auch um das parsing/printing und MQTT publishing erweitert ... bei der Unterscheidung der Geräte hapert es noch ein wenig ... und die Temperatur finde ich beim HM-700 nicht an der Stelle wie hier im Thread beschrieben. Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch gerne ...
Hallo, ich wurde gerade hierauf verwiesen: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fgzll_02_user_guide.html&cp=4_1_0_5_0 Kann es sein das dieses Gazell unser Channel hopping ist? Auch wenn sich oben genannte Doku auf einen nRF52833 bezieht steht bei den Features: Backward compatible with legacy nRF24L Series Gazell.
Hallo, hier scheint wohl so eine Implementierung des gzll Protokolls zu sein https://github.com/wangdong/cpod/blob/master/lib/nrf24/gazell/common/gzll.c Leider kann das wohl die nRF24 lib nicht.
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... ch bekunde Interesse :-) Habe allerdings einen HM-1200
Hi Thomas, guter Hinweis mit dem Gazell-Protokoll... das hatte ich schon erfolgreich verdrängt. ;-) Das Kommunikationsschema von Gazell sieht aber IMHO anders aus. Das ist Device-getriggert und der Host lauscht erstmal nur und antwortet auf Anfragen der Devices. Insofern müssten die HMs von sich aus auf einem Anker-Kanal "ungefragt" vor sich hin senden. Das tun sie aber nach aktuellem Kenntnisstand nicht, sondern antworten auf Anfragen des Hosts. Das Kommunikationsschema stellt sich für mich eher "klassisch" dar, also Anfrage Host->Device, dann Antwort Device->Host. Die max. Anzahl der für die DTUs spezifizierten "Solarmodule" ist mit 99 auch deutlich höher, als die für Gazell maximal spezifizierten 8 Teilnehmer. ...aber ich kann mich ja auch irren... ;-)
Beitrag #7024347 wurde vom Autor gelöscht.
Hallo zusammen, ich habe auch ein wenig an meinem HM600 gelauscht. Ich kann die Informationen für den HM600 wie im Anhang bestätigen. Ich hoffe, das hilft dem einen oder anderen weiter. Vielen Dank für die tollen Beiträge hier!
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... Ja, da hätten mein HM-600 und ich auch Interesse :)
lpb schrieb: > Hallo zusammen, > > ich habe auch ein wenig an meinem HM600 gelauscht. > Ich kann die Informationen für den HM600 wie im Anhang bestätigen. Ich habe auch weiter gelauscht und die 01-Message kann ich so bestätigen an Hand meiner Daten. Bei der 02-Message bin ich unsicher, was Gesamt-Ertrag und Wochenertrag angeht. Der letzte Wert ist die AC-Leistung und nicht wie Samstag noch von mir vermutet die Temperatur. Wenn ich mir die HM-Software ansehe, würde ich aber denken, das irgendwo noch die Temperatur versteckt ist...
Martin P. schrieb: > Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch > gerne ... Da hätte ich großes Interesse :-)
Carsten B. schrieb: > Martin P. schrieb: >> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch >> gerne ... > Da hätte ich großes Interesse :-) Ok - ein Zipfile gibt es hier: https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0 Hab leider gerade keine andere Möglichkeit den Code zu sharen (Handy) Disclaimer: das Original ist nicht von mir - ich habe nur Code und Wissen aus dem Forum kombiniert, so wie es für mich nützlich ist. Es ist auch noch nicht besonders ausführlich getestet. Es unterstützt mehrere Wechselrichter, denen man in der Definition einen Namen geben kann um sie an der Konsole/Mqtt unterscheidbar zu machen. Das Mqtt topic und Format hab ich mal so gewählt, wie es zu meinem Homesetup passt. Was m.E. noch fehlt: zB das Timing entspannen Nur requests schicken, in der Nacht deepsleep Und vieles mehr Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe leider nur die Basic DTU und kann daher die Nachrichten nicht loggen ….
Martin P. schrieb: > Carsten B. schrieb: >> Martin P. schrieb: >>> Auf Wunsch teile ich meinen aktuellen Stand (am Abend) natürlich auch >>> gerne ... >> Da hätte ich großes Interesse :-) > > Ok - ein Zipfile gibt es hier: > Leistungsbegrenzung wäre mir persönlich auch wichtig .. aber ich habe > leider nur die Basic DTU und kann daher die Nachrichten nicht loggen …. Danke, sehr cool. Ich hoffe, ich finde morgen die Zeit es zu installieren. Das Thema Leistungsbegrenzung interessiert mich auch sehr. Gemeinsam mit mehreren kommen wir da sicher weiter.
Hallo, ich vermute die Inverter-Temperatur beim HM600 im cmd 131 (83), byte 4.
1 | 2022-04-04T11:23:54.973594Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=84, uk3=1000, uk4=393, uk5=1757, uk6=47334 |
2 | 2022-04-04T11:26:28.900800Z MSG src=72220143, dst=72220143, cmd=131, uk1=1, uk2=36, uk3=1000, uk4=397, uk5=1765, uk6=13181 |
3 | 2022-04-04T12:16:51.839332Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=98, uk3=1000, uk4=460, uk5=1998, uk6=53222 |
4 | 2022-04-04T14:03:09.826004Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=59, uk3=1000, uk4=516, uk5=2492, uk6=12253 |
5 | 2022-04-04T14:36:51.087562Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=46, uk3=1000, uk4=496, uk5=2642, uk6=42061 |
6 | 2022-04-04T17:20:05.465478Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=0, uk3=0, uk4=327, uk5=3372, uk6=17290 |
7 | 2022-04-04T17:20:33.714355Z MSG src=72220143, dst=72220143, cmd=131, uk1=0, uk2=0, uk3=0, uk4=327, uk5=3375, uk6=25778 |
Quelle: Relevanter Log-Output mit https://github.com/Sprinterfreak/ahoy/tree/dev
Hallo, habe gerade mal ein poormans Channel hopping über die bekannten Kanäle beim empfangen gefrickelt. Siehe da: Mehr erfolgreiche Übertragungen als Fehlschläge. Also wir reden jetzt von mindestens 3-4 vollständigen Datensätzen pro Minute. Ich habe ein HM600 und bekomme cmd=1,2,131 nun etwa 4x/Minute. https://github.com/Sprinterfreak/ahoy/commit/86715ac116188f27247d2beb65fe0f3a39a2eeab
Hallo lpb so ganz passen die Werte für Week und Total bei mir nicht. Ich notiere mir jetzt schon ein paar Tage day1 und day2 power (Summe ist Gesamtleistung am Tag). Die Summe der letzten 5 Tage + aktuell ergeben bei mir 10.000, aber im Telegramm gibt das week power nur 5102 (Stand jetzt) aus. Da meine Anlage seit 1.1.2022 läuft, schätze ich mal eine Gesamtleistung von ca 100.000 Wh, im HM-Telegramm stehen aber 68.990 Wh. Scheint mir etwas wenig zu sein. Bist du dir mit den Daten sicher?
Jan-Jonas S. schrieb: > habe gerade mal ein poormans Channel hopping über die bekannten Kanäle > beim empfangen gefrickelt. Also ich kann bestätigen, dass mit der Modifikation von Jan teilweise mehr Pakete empfangen werden. Also z.B. auf eine einzige 0x80 Anfrage kam folgendes:
1 | 2022-04-05 18:14:04.512796 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 01 00 01 01 36 00 08 00 08 00 1a 00 18 00 01 54 76 83 |
2 | 2022-04-05 18:14:04.559483 Received 27 bytes on channel 3 pipe 1: 95 71 60 35 46 71 60 35 46 02 00 01 57 4e 00 b5 00 ac 01 33 00 07 00 02 00 17 b6 |
3 | 2022-04-05 18:14:04.595240 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 03 00 05 00 01 5e 4f 00 00 02 4e 00 a9 00 06 08 dd b5 |
4 | 2022-04-05 18:14:04.641578 Received 27 bytes on channel 75 pipe 1: 95 71 60 35 46 71 60 35 46 84 13 89 00 49 00 c9 00 03 01 57 00 55 00 07 39 23 16 |
Ein 0x84 hatte ich vorher noch nie gesehen. Man achte auch auf die verschiedenen Kanäle.
Angehängte Dateien:
-
ChannelMID.png
3,9 KB
Ich hatte gerade auch die Möglichkeit von einem HM-600 eine Matrix über die Empfangenen Message ID's vs. Channel Number zu bilden (siehe Anhang). 1er und 2er scheinen nur auf Kanal 3 zu kommen. Ob das nun Zufall ist, oder Jans Implementierung so geschuldet ist (das zufällig durchs Timing immer die 1er und 2er auf Channel 3 erscheinen und andere ggf. verworfen werden) kann ich erstmal nicht sagen. Also ich muss sagen, ich hab keine Ahnung von Channel Hopping Algorithmen usw... ich stochere hier nur etwas in den Daten.
:
Bearbeitet durch User
Martin G. schrieb: > Mal zwischendurch ein Themenwechsel zu "Channel Hopping": > > Ich habe hier die Antwortzeiten ausgewertet, d.h. die Zeit zwischen > "Senden der 0x80 Nachricht" und "Eingang der Antwort(en)". Siehe Plot im > Anhang. > > Da zeichnet sich klar ab, dass > > * die "0x01"-Nachrichten immer nach ca. 18 ms eingehen, > * die "0x02"-Antworten immer nach ca. 67 ms und > * die "0x83"-Antworten immer nach ca. 116 ms. > > Das ist für "Anfrage auf Kanal 40, Antwort auf Kanal 3". Das würde doch dafür sprechen das Channel Hopping mal zufällig zu gestalten. Aktuell fängt die Implementierung von Jan-Jonas ja immer mit Kanal 3 an und macht dann mit den Kanälen 23, 61, 75 immer die selbe Reihe durch. Bei einer zufälligen Abfolge könnte man auch statistische Auswertungen der Daten vornhemen. So wie der Code aktuell ist bleibt die Präferenz für die schnellen Antworten auf Kanal 3 wie von Martin / Petersilie ausgewertet.
Hallo, bekomme jetzt bei meinem HM-600 nahezu sekündlich alle Daten. https://github.com/Sprinterfreak/ahoy/tree/dev Habe das Channel Hopping nochmal überarbeitet, sodass der RX Start Channel mit jeder Transaktion rotiert. Das empfängt jetzt auch cmd=1,2 auf verschiedenen Channeln. Nachdem ich AutoAck mal auf True gesetzt habe findet die Kommunikation jetzt nahezu zuverlässig statt. An jemanden mit ner DTU und Sniffer: Kann mal wer versuchen herauszufinden wie man das "Zero Export Control"-Feature setzt? Laut Bedienungsanleitung kann der HM-600 ja auch noch Fehlercodes ausgeben. Eine Tabelle ist in der Bedienungsanleitung, jedoch finde ich keine halbwegs passenden Werte in den bisher bekannten Datensätzen.
In der nRF24L01+ Product Specs findet sich noch der folgende Absatz auf Seite 34 von 78: https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf?cp=12_4_0_0 > Two packet loss counters are incremented each time a packet is lost, ARC_CNT and PLOS_CNT in the > OBSERVE_TX register. The ARC_CNT counts the number of retransmissions for the current transaction. > You reset ARC_CNT by initiating a new transaction. The PLOS_CNT counts the total number of retrans- > missions since the last channel change. You reset PLOS_CNT by writing to the RF_CH register. It is possi- > ble to use the information in the OBSERVE_TX register to make an overall assessment of the channel > quality. Das würde dafür sprechen, daß es bei Übertragungsfehlern auf einem der bekannten Kanäle eine Retransmission auf einem der anderen Kanäle gibt um ggf. Störungen durch WLAN, PCM oder andere Funkteilnehmer auszugleichen. Offenbar scheint das "Channel-Hopping" ja auch speziell im Zusammenhang mit den vermuteten "Fehlermeldungen" 0x83 (und evtl. 0x81 / 0x82 ?) in Verbindung zu stehen. Oder täuscht mich da mein Eindruck ?
Hi, habe ein HM600; 0x83 (cmd=131) ist bei mir ein Werteblock, keine Fehlermeldung Hier stecken vmtl. load%, Temperatur, Status, Statuswechselzähler drin. 0x81 (cmd=129) ordne ich den Fehlern zu. Das kommt zurück, wenn man Müll mit korrekter CRC hin schickt. https://www.alpha-solar.info/media/Dokumente/Wechselrichter/Hoymiles%20HM/Deutsch/Bedienungsanleitungen/HM-600%20%20HM-800%20Bedienungsanleitung.pdf Alarmcode 129 deckt sich u.A. auch mit der Fehlertabelle in der Bedienungsanleitung vom HM-600. "Softwarefehlercode 129". Zufall? Dann könnte der WR ja prinziepiell auch die anderen Alarmcodes senden. Dafür bräuchte es aber eine Art Session zwischen der DTU und dem WR. Weil ich habe noch keine unbekannten Pakete rein purzeln sehen, wenn ich z.B. das Netz abtrenne. Das müsste dann laut Anleitung 0x93/147 oder 0x94/148 sein
zu den genutzten Frequenzen.
Bei meinem HM-600 ist es immer so:
Wenn ich ein 80 Telegramm sende auf 2403, dann antwortet der WR mit den
Antworten 01,02,83 auf den möglichen Frequenzen 2423,2440,2461 MHz.
also bei TX 2403, Antworten auf 2423,2440,2461
bei TX 2423, Antworten auf 2403,2440,2475
bei TX 2440, Antworten auf 2403,2423,2475
bei TX 2461, Antworten auf 2403,2423,2475
bei TX 2475, Antworten auf 2403,2423,2440
Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt
man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie
empfangen.
:
Bearbeitet durch User
B. G. schrieb: > Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt > man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie > empfangen. Hallo BG, hast du es mal mit einer 0x80 0x11 Anfrage versucht? Da dürften andere Daten zurückkommen, siehe hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Angehängte Dateien:
martin schrieb: > Hallo BG, > hast du es mal mit einer 0x80 0x11 Anfrage versucht? Das muß ich mal testen. Anbei noch ein jpg , NRF sendete auf 2475. HM-600 antwortete auf 2440,2423,2423 (3. Antwort 83 nicht mehr auf jpg) Man sieht, wann ich beim Scan auf die Frequenz kam und den Block quittiert habe.
Nach einiger Zeit hatte ich auch noch einmal Gelegenheit mich mit der Materie zu beschäftigen. Momentan bin ich noch der Meinung, dass das Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen. Auf den unterschiedlichen Kanälen kommen auf die 0x80 Anfrage immer 3 verschiedene Antworten mit verschiedenen Ids, wenn Sie nicht durch irgendwelche Übertragungsprobleme gestört werden. Ich empfange die Ids 0x01 bis 0x0B. Siehe beigefügter Beispiel Dump. Da ist mit Sicherheit auch etwas dabei für Inverter mit mehr als 2 MPP Trackern. Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt. https://github.com/OFreddy/hm_poll Eventuell kann man das nutzen und für verschiedene Platformen anpassen um solche Probleme zu vermeiden, dass bei einem nano z.B. andere Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der hm_config_x.h geschehen. Wer dort erweitern möchte ist herzlich willkommen. Momentan unterstützt die Library 4 Inverter Instanzen, ist aber erweiterbar. Das Channel Hopping kann noch optimiert werden. Geplant habe ich eine Art Callback Funktion, bei der die Library empfangene gültige Pakete an die Applikation signalisiert. Diese könnten dann von der Applikation nach Datenpunkten zerlegt werden.
:
Bearbeitet durch User
Angehängte Dateien:
martin schrieb: > hast du es mal mit einer 0x80 0x11 Anfrage versucht? Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85 zurück, bei 800B 01,02,83
Hallo Martin, 80 0b ist das "Zeit setzen" was mit normalen Werten antwortet 80 11 liefert bei mir cmd=129, Error 80 03 liefert ein ganzen Haufen, siehe Log. u.A. cmd=1-7, wobei die Werte in 1 und 2 nicht identisch sind wie bei 0b Hab das mal durchprobiert. 80 0b, 0c, 0d sind sehr ähnlich aber Werte scheinbar mit einem falschen Faktor. Das ganze Tageslog muss ich mal aufarbeiten. Da ist auf jeden Fall einiges drin, was neu ist und bisher keinen Sinn ergibt, wenn man mit den Anfragen spielt und keinen Fehler schmeißt.
Oliver F. schrieb: > Momentan bin ich noch der Meinung, dass das > Channel Hopping nach dem Gießkannen Prinzip funktioniert. Ich kann kein > Schema erkennen, lasse mich aber gerne vom Gegenteil überzeugen. Das mit dem "Gießkannenprinzip" ist bisher auch mein Eindruck: Vielleicht so etwas in diese Richtung: - Die "DTU" sendet eine Anfrage auf mehreren Kanälen "zeitlich dicht hintereinander". - Die WR hören permanent auf einem der Kanäle, und schalten nur mal einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hören. - Die WR antworten auf mehreren Kanälen "zeitlich dicht hintereinander" - Die DTU hört permanent auf einem der Kanäle, und schaltet nur mal einen Kanal weiter, wenn sie "lange" auf einem Kanal nichts hört. Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen Empfänger scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt. Hier wäre es toll, wenn jemand mit einem SDR-Sniffer und DTU derartige Muster beobachten könnte. Ich meine, @tbnobody hat sowas zumindest ansatzweise mal gesehen? Leider ist meine DTU noch immer nicht geliefert worden - und viel Hoffnung mache ich mir nicht mehr...
Martin G. schrieb: > Ein andauerndes, zufälliges Kanal-Wechseln der jeweiligen *Empfänger* > scheint mir eher weniger sinnvoll - dann ist es ja schon ein doppeltes > Glücksspiel, ob man zufällig mal ne Nachricht mitkriegt. Das ist das, was ahoy.py aus meinem Fork sieht. > Ich meine, @tbnobody hat sowas zumindest ansatzweise mal gesehen? Ja, in meinen Logs. Heute Nacht nach Einspeiseende werden meine Logs wieder untersucht. Mit Sicherheit. Mit entsprechenden Änderungen in ahoy.py, die genau das dämliche Verhalten mit verbessertem hopping-code zeigen, was ich so den Tag über bereits beobachtet habe.
:
Bearbeitet durch User
Das glaube ich eher nicht. Ich meine, die WR scannen die wenigen genutzten Kanäle durch. Durch das Retransmit erkennen sie immer die Nachricht. Ebenso können die DTUs oder eigene NRFs durch das Scannen sicher alle Telegramme empfangen. So hab ich das jedenfalls bei mir. Wenn ich auf einer anderen Frequenz sende, kommen immer gleich die Antworten. Ebenso ist es beim Empfang der Antworten.
Das ist bei mir (HM600) eben anders. Bei TX auf einem anderen Kanal als 40 kommt nichts. Nie. Wenn ich nur auf einem fixen Kanal, auch über die Zeit empfange, bekomme ich nur hin und wieder mal ein einzelnes Paket. Wenn ich nach dem Tx über die Kanäle scanne, bekomme ich recht zuverlässig alle Pakete. Jedes mal auf anderen Kanälen. Auch nach einem Tx die Antwortpakete nacheinander auf unterschiedlichen Kanälen.
Der Code, der das generiert ist hier: https://github.com/Sprinterfreak/ahoy/blob/dev/tools/rpi/ahoy.py Am Ende habe ich ein wenig mit den Tx-Daten gespielt, da sind sicher interessante Rohdaten dabei.
Angehängte Dateien:
-
2022-04-06_19_05_49.png
28 KB
Mein Testprogramm funktioniert jetzt so, dass die simulierte DTU die Kanäle durchwechselt und dann auf einem der Kanäle lauscht. Empfängt es eine Antwort, so bleibt es auf dem Sendekanal und wechselt nur noch die Empfangskanäle durch. Dabei empfängt es immer auf einem der anderen Kanäle bis zu 3 verschiedene Frames. Siehe Screenshot. Wechselt auch bei jedem mal auch der Sendekanal kommen deutlich weniger Antworten. Voraussetzung ist allerdings, dass der Request mit 0x80 0x11 beginnt. Verwende ich die 0x80 0x0B kommen nur 0x01, 0x02 und 0x83 Antworten.
@janjonas_s - Wow! Phänomenal! Mit Deinen Channel-Hopping-Versuchen kommen auf jeden Fall wesentlich häufigere Antworten. Und ein paar neue Feldbedeutungen hast Du auch eingepflegt. Ich hab Deine Commits mal gemerged, danke! Hatte noch ein paar lokale Änderungen, die sind jetzt auch drin. Die JSON-Daten enthalten jetzt alle Infos, die wir bisher erarbeitet haben. * https://github.com/grindylow/ahoy/blob/main/tools/rpi/ahoy.py
Hallo Martin, danke. So ganz "richtig" kann das alles noch nicht sein. Speziell weil wohl z.B. cmd=1,2,3 nicht immer den selben Inhalt haben. Dies ist wohl noch zwischen Modellen und je nachdem was man anfragt unterschiedlich. Siehe z.B. mein ahoy.log.gz um 17:46 rum. Da habe ich mit den Anfragedaten gespielt. Bisher habe ich damit allerdings mit meinem HM600 die höchste Wahrscheinlichkeit erziehlt auf eine Anfrage möglichst alle Antworten zu bekommen. Ich habe die ahoy.conf erweitert, sodass man da seine DTU-, Inverter serial und broker eintragen kann. Wenn man die außerhalb des Repos lagert und die ahoy.py vom Ort der ahoy.conf startet, geht das Updaten leichter.
:
Bearbeitet durch User
So langsam wird mir klar, warum ich auf dem WLAN-Band so einen hohen Hintergrundstörnebel gemessen habe. Echt bizarr.
also ich habe die ESP8266 Version jetzt auch soweit, dass man sie wo headless parken könnte (musste auch einen 100uF und Dipol-Antenne an die nrf24l01 Platine löten, um beide WR empfangen zu können) .. geschickt werden Messwerte per Mqtt und gelogged wird per rsyslog. Sonnenaufgang und Untergang wird berechnet um so über Nacht in DeepSleep gehen zu können. Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste, bekomme ich: Vom HM700: viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 mit Temp (hier scheint der Wert auch nicht zu stimmen) Vom HM350: Bekomme ich nur 01 DC Daten und etwa halb so oft wie vom HM700 Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der Python Version breiter nach dem HM350 zu loggen.
Martin P. schrieb: > Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der > Python Version breiter nach dem HM350 zu loggen. Hi. Könntest Du mal die Bibliothek aus https://github.com/OFreddy/hm_poll ausprobieren? Es würde mich interessieren welche Antworen von anderen WR kommen. Ich kann nur mit HM-600 loggen. Bei Fragen einfach melden.
:
Bearbeitet durch User
Martin P. schrieb: > Irgendwas scheint aber am eigentlichen Empfangsalgorithmus noch nicht > ganz zu stimmen. Auch mit random Rx Kanal aus der bekannten Liste, > bekomme ich: Das vermute ich, weil meine Versuche da eher blindes Huhn spielen. Wenn da tatsächlich Gazell, oder in Teilen Gazell, dahinter steckt wären die Channel vorhersagbar. > Vom HM700: > viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 > mit Temp (hier scheint der Wert auch nicht zu stimmen) Das kann gut sein. Habe ich ja gestern bei meinem HM600 auch provoziert, als ich das byte nach 0x80 im "Zeit setzen" verändert habe. Das hat die Werte im cmd=2,131 um irgendwas faktorisiert. Gut möglich, dass da jeder WR einen eigenen Requests braucht. Sicher jedenfalls sein eigenes Schema hat wie die Payload(s) aufgebaut ist. Glaube Thomas frickelt schon an Modellbezogenen Dekodern? Thomas hat gestern aus meinen Daten auch komische Timing-Effekte extrapoliert Sah aus als ob über die Zeit (range unbekannt) mit meinem Hopping Werte nach einem Muster mal mehr und weniger werden. > Ich werde wohl mal einen alten Raspi ausgraben und mal versuchen mit der > Python Version breiter nach dem HM350 zu loggen. Mein Gedanke war auch schon 5 nRF's als reinen Receiver, je einen Pro Kanal, laufen zu lassen. Ich hab leider nicht die Möglichkeit ein Spektrum im Gigahertz-Bereich aufzuzeichnen.
Oliver F. schrieb: > Hi. > Könntest Du mal die Bibliothek aus > https://github.com/OFreddy/hm_poll > ausprobieren? Es würde mich interessieren welche Antworen von anderen WR > kommen. Ich kann nur mit HM-600 loggen. Hallo Oliver, anbei ein Scan von HM350 und HM700. das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC erscheinen schlüssig und passen auch zu den Shelly Werten.
> Hallo Oliver, > > anbei ein Scan von HM350 und HM700. > > das HM700 dürfte die Kommandos vom ursprünglichen NR24F Code aus dem > Repo ganz gut vertragen .. Strom/Spannung/Leistung von AC und DC > erscheinen schlüssig und passen auch zu den Shelly Werten. Hallo Martin, vielen Dank, super das Du das gemacht hast. Aber das verstehe ich nicht. Bei mir sieht das ganz anders aus. Ich erhalte eigentlich auf jede Anfrage eine Antwort von den Wechselrichtern. Kann es sein, dass sie bei Dir nicht in Reichweite sind? Oder sind sie zu nahe? Du verwendest PA_HIGH. Ich hatte auch schon das Problem, dass das Verhalten schlechter wird, wenn die Sendeleistung zu hoch ist, oder die 3.3V Versorgung für die RF24 Module zu schlecht ist.
ja leider sind meine beiden WR ein Stück voneinander entfernt. Bei meinem 2. Board mit ESP8266 + Dipol Antenne (selbstgebaut) kommen auch wesentlich mehr Messages ... vielleicht kann der Spannungsregler am NodeMCU einfach mehr leisten, als der des Nano. Wenn der Laptop wieder aufgeladen ist (anders geht es leider nicht, wo ich beide WR empfange) kann ich es ja nochmals mit dem Dipol Board und PA_LOW probieren. Morgen sollte ich außerdem so ein Board mit PA + LNA bekommen.
Martin P. schrieb: > Vom HM700: > viele 01 DC Daten, etwa jedes 4-8 Mal 02 AC Daten und viel seltener 131 > mit Temp (hier scheint der Wert auch nicht zu stimmen) Witzig, das deckt sich genau mit meiner Erfahrung (siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"). "Oft" 01, "seltener" 02, sehr selten 131. Mysteriös. Aber wir sammeln eifrig weiter...
Angehängte Dateien:
-
HM-1500_20220407_01.png
37 KB
Hallo, dank Jans Modifikation habe ich einen ganzen Tag aufgezeichnet und bei fast allen 0x80 vier Antworten bekommen. Dadurch konnte ich schon schon viele Felder identifizieren. Siehe Anhang. (Die #NV bitte ignorieren, die benötige ich zum Diagramme rendern) Spalte F - G zeigen die Rohdaten. Spalte AH bis BA die bisher bekannten Felder. Vielleicht hilft es jemanden. (Und DC1-4 sind bisher beliebig zugewiesen. Da müsste ich mal alle Panels bis auf eines abstecken und das genau machen)
:
Bearbeitet durch User
Angehängte Dateien:
-
HM-1500_20220407_02.png
29 KB -
HM-1500_20220407_02_graph.png
140 KB
Und ich glaube ich habe auch die Temperatur gefunden...
Angehängte Dateien:
-
HM-1500_20220407_03.png
25 KB -
Leistungsfaktor_Grafana.png
93 KB -
Leistungsfaktor_RF24.png
43 KB
Und ich glaub ich hab den Power Faktor gefunden. Zumindest korreliert der Graph recht gut zu dem was der Gosund Zwischenstecker aufzeichnet (und im Grafana landet).
B. G. schrieb: > martin schrieb: >> hast du es mal mit einer 0x80 0x11 Anfrage versucht? > > Ich habs getestet mit 8011 und 800B, bei 8011 kommt immer 01,02,03,04,85 > zurück, bei 800B 01,02,83 Hallo B. G., könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere Pakete und Frequenzen interessieren.
Angehängte Dateien:
Thomas B. schrieb: > könntest du bitte das Bild aus diesem Beitrag mit der Zeit-X-Achse > nochmals bereitstellen? Mich würde der zeitl. Verlauf über mehrere > Pakete und Frequenzen interessieren. Das Bild vom 6.4. ist ja noch verfügbar. Ich hab gerade nochmal so eine Aufnahme gemacht. Komischerweise sendet der HM-600 gerade andere Pakete. Anbei der Frequenzverlauf über die Zeit und die empfangenen Pakete.
Angehängte Dateien:
nochmal eine kleine Aufnahme. Jetzt sendet der HM-600 wieder anders. Aufnahme ist etwas schwach, aber man erkennt die Frequenzen noch.
Angehängte Dateien:
-
HM-1500_20220408_01.png
10 KB -
HM-1500_20220408_01_graph.png
14 KB
Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig machen können. Die Port Zuordnung ist ggf. noch zu verifizieren. In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man summiert die letzten 3 Wochen). Kann jemand ein ähnliches Phänomen beobachten?
Thomas B. schrieb: > Habe noch die Gesamtproduktion sowie die täglichen Counter > ausfindig > machen können. Die Port Zuordnung ist ggf. noch zu verifizieren. > > In der Gesamtproduktion scheinen aktuell ziemlich genau 3 Wochen > enthalten zu sein. Ich würde jetzt schätzen das ist seit dem 1. Kontakt > zwischen WR und "DTU". Die Gesamtproduktion passt genau mit der > täglichen Produktion. Daher würde ich vermuten das die korrekten Bytes > gewählt wurden. Jedoch passt die Gesamtproduktion absolut nicht zu dem > was der Zwischenstecker bisher aufgezeichnet hat (außer wie gesagt, man > summiert die letzten 3 Wochen). > Kann jemand ein ähnliches Phänomen beobachten? Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst.
Angehängte Dateien:
-
HM-600_20220408_01.png
8,3 KB
Mike schrieb: > Das ist so korrekt, denn als ich bei meinen Eltern einen WR HM-1200 in > Betrieb nahm, hatter dieser bereits Strom produziert. Als zwei Wochen > später dann die DTU-W100 eintraf, umd ich den WR mit der DTU gekoppelt > habe, wurden erst ab diesen Zeitpunkt die Gesamtproduktion erfasst. Das ist wunderbar dass das so passt! Ich habe eine ähnliche Tabelle auch für einen HM-600 erstellt. Vielleicht findet der ein oder andere darin noch Werte die er bisher noch nicht hat. (AC_I z.B.) Die letzten 4 Bytes in der HM-600 0x83 Message sind im gleichen unbekannten Format wie die letzten 4 Bytes in der 0x84 Message des HM-1500 (letzte 4 Bytes ohne die letzte CRC)
:
Bearbeitet durch User
Angehängte Dateien:
Thomas B. schrieb: > Vielleicht findet der ein oder andere darin noch Werte die er bisher > noch nicht hat. (AC_I z.B.) Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw. die S-Miles Enduser App zeigt keine an.
Mike schrieb: > Soweit mir bekannt, gibt es gar keine Werte für AC_I vom WR HM-1200 bzw. > die S-Miles Enduser App zeigt keine an. Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese entsprechen exakt der Leistung (P) durch der Spannung (V). [1] https://www.mikrocontroller.net/attachment/553106/HM-1500_20220408_01.png [2] https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png
Angehängte Dateien:
Desweiteren kann die Energie (Wh) und die Leistung (W) jeweis für Tag/Monat/Jahr/Gesamt angezeigt werden. Jedes PV Modul hat auch eine Ortangabe (0,0 / 0,1 / 0,2 / 0,3)
Thomas B. schrieb: > Hm ich konnte sowohl für HM-1500 als auch für den HM-600 die > entsprechenden Werte finden (siehe die Tabellen in [1] und [2]). Diese > entsprechen exakt der Leistung (P) durch der Spannung (V). Also ich kann die HM-600 Decodierung auch für den HM-700 bestätigen. Beim HM-350 bin ich auch etwas weiter gekommen: Da sind die DC Daten im 0x1: DC_V, DC_A, DC_P (and der selben Stelle wie bei HM600 .. der erste byte ist 10 und das letzte ist 0. und AC Daten kommen in 0x82: 2byte Frequenz /100 2 byte Power /10 2 byte u1 (entweder 1 oder 0) 2 byte Strom /100 2 byte u2 (1000 dezimal) ... die restlichen Bytes geben für mich noch keinen Sinn. Spannung fehlt Mit dem NRF24Sniff code, der TimePacket, gefolgt von 0x81,0x80,0x82 Pakete schickt, bekomme ich vom HM-350 sehr oft mit einem 0x81? Das ist doch Command-Error? Schicke ich nur das TimePacket, kommen nur die 01/02/82 zurück
:
Bearbeitet durch User
Thomas B. schrieb: > Habe noch die Gesamtproduktion sowie die täglichen Counter ausfindig > machen können. Die Port Zuordnung ist ggf. noch zu verifizieren. Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die Tagesleistung pro Eingang sind? Das ist nämliche meine Theorie bei der Auswertung des HM-700 .... die Werte sind mir zu ähnlich (und wir hatten sehr wechselhaftes Wetter)
Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut) 01: 2bytes unbekannt "1" 2bytes dc_volt / 10 2bytes dc_amps / 100 2bytes dc_power / 10 2bytes unbekannt "0" 2bytes Total_w 2bytes Daily_w 2bytes ac_volt / 10 82: 2bytes ac_freq / 100 2bytes ac_power / 10 2byte unbekannt "0" 2bytes ac_current / 100 2byte unbekannt "1000" vielleicht /10 Power Factor in %? 2bytes temp / 10 2bytes unbekannt ansteigend 2bytes random
Oliver F. schrieb: > Das NRF24_SendRcv habe ich überarbeitet und auf GitHub eingestellt. > https://github.com/OFreddy/hm_poll > Eventuell kann man das nutzen und für verschiedene Platformen anpassen > um solche Probleme zu vermeiden, dass bei einem nano z.B. andere > Interrupt Behandlungen erforderlich sind. Auch Anpassung kompatibel zu > einem ESP32 als Target sollte möglich sein. Die Adaption könnte in der > hm_config_x.h geschehen. > Wer dort erweitern möchte ist herzlich willkommen. Hallo, super Arbeit! Das ist sehr sauber aufgesetzt. Wäre es möglich die "Konfiguration via Seriell" zu unterstützen? Mit Konfiguration meine ich: Die Seriennummer der/des Hoys. (Idealerweise nutzerfreundlich mit der "richtigen" Seriennummer.) Weiterhin fände ich es gut, wenn man das Senden/Empfangen pausieren könnte sowie den Scanintervall einstellen könnte. Ich werde selber mal bisschen probieren, aber an Deine C++ Skills komme ich sicher nicht ran :-)
Martin P. schrieb: > Bist du dir sicher, dass diese Day1, Day2, Day3 usw. Werte nicht die > Tagesleistung pro Eingang sind? Aehm ja, die Day1 - 4 ist jeweils pro Port. Was ich noch nicht verfiziert habe ist die genaue Portzuordnung.
Mag C. schrieb: > Hallo, super Arbeit! Das ist sehr sauber aufgesetzt. > Wäre es möglich die "Konfiguration via Seriell" zu unterstützen? Hallo Mag. Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas dauern, da ich in Osterurlaub fahre. Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du willst ja sicher nicht bei jedem Start erst die Seriennummern wieder schreiben, oder?
Oliver F. schrieb: > Mag C. schrieb: >> Hallo, super Arbeit! Das ist sehr sauber aufgesetzt. >> Wäre es möglich die "Konfiguration via Seriell" zu unterstützen? > > Hallo Mag. > Vielen Dank für das Lob. Ich werde es mal versuchen, wird aber etwas > dauern, da ich in Osterurlaub fahre. > Auf welchem Target nutzt Du es? Die Seriennummern müssten ja dann im > EEPROM oder im simulierten Flash EEPROM weg gespeichert werden. Du > willst ja sicher nicht bei jedem Start erst die Seriennummern wieder > schreiben, oder? Ich nutze einen Arduino Nano. Der Gedanke bei den Seriennummern war dass man anderen/nicht so versierten Hoymiles Nutzern vielleicht den Einstieg etwas leichter machen könnte. Man braucht im Falle des Nano ja immer noch ein weiteres Stück Software um die Daten auszulesen, weiterzusenden oder zu speichern. (Etwas in der Art baue ich gerade.) Das könnte dann auch die Konfiguration übernehmen, also beim Starten die Seriennummer(n) übergeben und z.b. das Scannen Nachts abschalten. Wenn man das Ganze standalone auf einem ESP aufbaut (Siehe oben "ESPHome" Beitrag von Marcel), dann würde es vielleicht ein UI geben, wo man die Seriennummern eintippt... Kein Stress! Schönen Urlaub!
Angehängte Dateien:
-
hoy_webserver.png
33 KB
Moin Das mit der Temperatur würde mich auch interessiern, das fehlt mir noch. Aufbauend auf der Nano-Variante von der ahoy-Seite habe ich mir eine ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt, die recht gut funzt (siehe Bild). Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die Temp?
Hubi schrieb: > Außer den 01 und 02 Telegrammen bekomme ich nur 83er, aber wo ist da die > Temp? Hallo Hubi, siehe [1]. Die Temperatur sollte in Telegramm 0x83 in den Bytes 17 und 18 (wenn man bei 1 zu zählen anfängt) stehen. Der dort enthaltene Wert muss durch 10 geteilt werden. [1] https://www.mikrocontroller.net/attachment/553127/HM-600_20220408_01.png
Hubi schrieb: > 83er, aber wo ist da die > Temp? ich hab die aktuellen Werte beim HM-600 mal angehängt von heute. Temperatur steigt an von 5,1 bis aktuell 26,6°
Angehängte Dateien:
-
HM-PowerLevel.jpg
220 KB
Hallo, für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert: Message 0x83 Start Bytes Unit Factor -------------------------------------------------- Output Level 0-5? 10 2 - x1 Grid Cuurent 12 2 A x100 0 or 1000 14 2 - -1 Status info? Temperature 16 2 °C x10 Das, was ich 'Output Level' nenne passt in den Stufen prinzipiell recht gut mit meiner Ausgangsleistung zusammen (siehe Anhang). Allerdings wird der Wert immer wieder Null, obwohl ich eine Ausgangsleistung habe - von daher passt das noch nicht ganz - aber eine bessere Beschreibung/Erklärung habe ich noch nicht gefunden :) Die 0x02 Daten habe ich auch überarbeitet. Die total 1 und 2 steigen täglich mit den Werten daily 1 und 2, von daher sollte das jetzt so passen: Message 0x2 Start Bytes Unit Factor -------------------------------------------------- Total Production 1 10 2 Wh x1 Total Production 2 14 2 Wh x1 Daily Production 1 16 2 Wh x1 Daily Production 2 18 2 Wh x1 Grid Voltage 20 2 V x10 Grid Frequency 22 2 Hz x100 Grid Power 24 2 W x10 Ich vermute, dass die Hoymiles Cloud die anderen Werte für die Wochen- und Monatsdaten ermittelt. Ebenso könnte der Power Level in % aus der Maximal-Leistung des Inverters und der aktuellen Leistung von der Cloud berechnet werden. Ich habe übrigens auch mit dem 'poor man rx channel switching' die Empfangsquote der Nachrichten deutlich erhöhen können (ich sende alle 6 Sekunden eine Anfrage), aber ich erwische damit immer noch nicht alle, evtl ist dabei neben dem Timing auch noch die Reihenfolge wichtig... Auf alle Fälle reicht das schon mal, um die wesentlichen Daten erfassen zu können, was ich sehr cool finde. Dafür ein großes Danke an alle, die hier so fleißig beigetragen haben!
Hubi schrieb: > Moin > ... habe ich mir eine > ESP-Version mit Webserver und Datenschnittstelle (über Web) gebastelt,... Hallo Hubi, würdest Du mir Bitte Deinen Source zur Verfügung stellen ? Ich habe 8266 und auch 32 hier. "C++" kann ich allerdings noch nicht. Mir würde das auch erst mal so reichen, wie Du es bisher hinbekommen hast. Viele Grüße und einen schönen Sonntag wünscht Dir Herbert
Hallo meine Lieben Tüftler, den ganzen Thread am Stück lesen war jetzt doch ne Menge Input, Respekt für eure Arbeit. Ich habe zwar keinen Hoymiles, allerdings eine abgewandelte Variante: TSUN TSOL-M800. Dieser hat die Seriennummer 104163500316 Passend dazu könnte der Hoymiles 1141... passen. Datenstick und die große Basisstation sind identisch, auch in den Anleitungen zur Cloud ist Hoymiles drin. Ich hätte einen Wemos D1 Mini hier, suche aber noch ein passendes NRF Modul. Gefunden habe ich dieses hier: https://smile.amazon.de/DollaTek-NRF24L01-Funk-Transceiver-Modul-antistatischem-kompatibel/dp/B07PQPFTWZ/ Alternativ hat AZDelivery noch was im Sortiment. Wäre davon was richtig? Auch den Sourcecode für einen ESP8266, den ich mit der Arduino-Software laden kann, wäre hilfreich. Parallel habe ich noch 2 SG700MD hier, deren Protokoll ich aber schon habe und demnächst in NodeRed die Steuerung weiterbaue. Die Databox habe ich schon versucht, jedoch ist keine Kommunikation mit dem TSUN möglich. Hier ist der Chip Beken bk2461 verbaut. Was in den WR drin ist, werde ich nochmal schauen, wenn ich die Folien der Silikonpads entferne. Zur Software an sich: ich bevorzuge NodeRed und habe dazu einen Raspi am start. Hier könnte man auch wegen Python schauen, jedoch bin ich damit nie wirklich warm geworden. NodeRed finde ich da irgendwie angenehmer :) Programmierskills habe ich keine, finde mich aber in Beispielcode zurecht. C/C++ ist mir weitgehend fremd, Python ist nicht so meins, Arduino geht, JS in NodeRed basics vorhanden. Wäre cool, wenn ihr mir den Start erleichtert und wir den TSUN-Kunden einen ähnlichen Kompfort ermöglichen können :) lg Daniel
Hallo Herbert u. Daniel anbei mein Fork von der ahoy-Seite. Läuft bei mir auf einem Wemos D1 mini. Was ist anzupassen: in wifi.h : - SSID_PREFIX zur Suche des besten WLan; wenn auskommentiert, werden alle WLans in der Nähe beachtet - password für Wlan in ModWebserver.h: die defines für Serverport und OTA-Zugriff Einfach im Browser die IP eingeben, dann kommt die Tabelle wie oben. Wenn man IP/data eingibt, kommen nur die Werte als Text, das ist meine einfache Datenschnittstelle, die ich dann mittels RasPi und cron abspeichere. Ich benutze die Arduino IDE, also wer platform.io benutzt muss sich das anpassen. Viel Spaß
@Hubi, Herzlichen Dank, die Beschäftigung die nächsten Stunden (Tage) ist nun gesichert :-) Einen schönen Abend wünsche ich Dir. Danke nochmals.
Hallo,
mithilfe von
> https://www.dropbox.com/s/cbpuw6aupjuhmda/NRF24_SendRcvMqtt.zip?dl=0
hab ich jetzt auch das Programm (mit Circular Buffer) auf meinem ESP32
zum laufen bekommen. Danke Martin.
Heute lief das ganze mal ein paar Stunden und ich habe dazu mal ein paar
Fragen.
Was genau ist denn dieses "// Packet control field - PID Packet
identification" ?
1 | // Packet control field - PID Packet identification |
2 | uint8_t val = (p.packet[1] >> 1) & 0x03; |
3 | Serial.print(val); |
4 | Serial.print(F(" "));
|
Ebenfalls habe ich mal ein paar Debugausgaben mit hier rangehangen. Ich hab ja einen HM-400 und bekomme jetzt sehr viele dieser 0x81 Antworten. Wobei diese immer gleich per PID sind. Und ich hatte sogar eine 0x82 dabei. Weiß da schon jemand etwas mehr über dessen Bedeutung? Marcel
Der HM-400 ist ja auch ein Single Modul Inverter … wahrscheinlich wirst du da die Dekodierung für den HM-350 verwenden können, wie ich sie gestern gepostet habe. Bei mir hat es auch gereicht nur das TimePacket zu schicken … damit liefern beide Wechselrichter (350 und 700) die relevanten Nachrichten. Ich habe mal alles aus dem ursprünglichen Code geschmissen was ich nicht brauche und schicke die Dekodierung für beide WR per RSyslog und Mqtt raus (der ESP ist am Dachboden installiert, damit er beide WR sieht)
Hallo Martin, die Werte des HM hatte ich selber schon rausgefunden und gepostet. Ich nutze die schon seit ein paar Wochen. Mit deinem Code konnte ich es jetzt aber auf diese Interrupt Methode und CircularBuffer umstellen und sehe jetzt die o.g. Daten. Würde schon gerne wissen was das ist und wozu das gut ist ;) Ebenfalls wäre ich super dankbar, wenn jemand den Request von der DTU Pro rausfindet um die Einspeisung zu limitieren. Dann könnte ich demnächst auf Akkubetrieb mit Konstanteinspeisung umstellen. Marcel
lpb schrieb: > Hallo, > > für den HM600 habe ich folgende Felder der 0x83 Nachricht identifiziert: > Message 0x83 Start Bytes Unit Factor > -------------------------------------------------- > Output Level 0-5? 10 2 - x1 hallo dieser "output level" wert ist interessant! in hoymiles modbus register 0xC001 oder 0x9D9D "Limit Active Power" wird der wert als % eingegeben, und zwar für MI series zwischen 10-100% für MH series 2-100% der wr-nennleistung. die frage ist, wie passt das zusammen? oder gibt es ein anderer befehl zur limitierung? Ziyat T.
Angehängte Dateien:
Manchmal sind es die kleinen Dinge dieser Welt, über die man sich freut
:-)
Nach dem ich noch einige LIBs zu meiner Arduino: 1.8.13 hinzufügen
mußte,
habe ich mich durch div. warnings gekämpft bis ich gefunden habe, was
der Grund für "exit status 1" war:
wifi.h:76:54: error: ...
....
....
exit status 1
cannot pass objects of non-trivially-copyable type 'class String'
through '...'
(Source von "Hubi" vom 10.04.2022 17:49)
in wifi.h habe ich dann diese Zeile auskommentiert:
// DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID);
Keine Ahnung, warum da gemeckert wird. Dafür reichen meine Kenntnisse
leider nicht aus.
Nun sehe ich die Webseite und muss jetzt noch die Verbindung zum
nRF24L01+ Modul herstellen.
Ich freue mich jedenfalls, das ich schon mal bis hier hin gekommen bin.
Danke "hubi"
:
Bearbeitet durch User
Sorry, dass ich nicht erwähnt habe welche libs ich noch benutze
(TimeLib, Pinger). Warum du den error mit exit status=1 in wifi.h hast
ist mir unverständlich. Ich habe dort nur eine warning und mit
DEBUG_OUT.printf ("Bestes Wifi unter: %s\n", SSID.c_str());
ist die warning weg.
Ein herzliches DANKE an alle beteiligten für die großartige Arbeit
bisher! Vielen Dank Hubi für deinen Arduino-Code für den D1 mini. Die
Beobachtungen von Herbert K. kann ich bestätigen. Mit DEBUG_OUT.printf
("Bestes Wifi unter: %s\n", SSID.c_str()); habe ich jedoch keinen Fehler
mehr, sodass ich nun den Webserver erreiche. Tests mit dem HM-600 stehen
noch aus...
Marcel A. schrieb: > Was genau ist denn dieses "// Packet control field - PID Packet > identification" ? Hallo Marcel, https://www.sparkfun.com/datasheets/Wireless/Nordic/nRF24L01P_Product_Specification_1_0.pdf Section 7.3.3.2 The 2 bit PID field is used to detect if the received packet is new or retransmitted. PID prevents the PRX device from presenting the same payload more than once to the receiving host MCU. The PID field is incremented at the TX side for each new packet received through the SPI. The PID and CRC fields are used by the PRX device to determine if a packet is retransmitted or new. When several data packets are lost on the link, the PID fields may become equal to the last received PID. If a packet has the same PID as the previous packet, nRF24L01+ compares the CRC sums from both packets. If the CRC sums are also equal, the last received packet is considered a copy of the previously received packet and discarded. Was es allerdings in dem Code macht, hab ich nicht weiter nachgeforscht. Ich hab ja auch nur den Code von Github genommen und das stdinout / CircularBuffer Thema für den ESP aus dem Weg geschafft.
Früher oder später wird auch eine etwas robustere Hardware interessant werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 Combo gefunden: http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein. Sollte als Ersatz-DTU aber auch seinen Dienst machen. Hier noch etwas minimalistischer: https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/ was mich bei letzterem allerdings verwundert, sind die fehlenden Widerstände, die der ESP12 normalerweise braucht.
Martin P. schrieb: > Früher oder später wird auch eine etwas robustere Hardware interessant > werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 > Combo gefunden: Mit einem ESP32 sähe das hier auch ganz nett aus: https://www.openhardware.io/view/698/MY-ESP32-GW
Angehängte Dateien:
-
ali-003.jpg
24 KB -
ali-005.jpg
18 KB -
HM400-HUBI-SRC-2022-04-11-18-01.jpg
25 KB
Wieder einen kleinen Schritt weiter :-) worüber ich mich freuen kann :-) Dies habe ich aktualisiert. "....SSID.c_str());" Nun klappt das Compilieren auch damit :-) Durch Ändern der S/N meiner HM400 bekomme ich die ersten 3 Werte vermutlich sogar richtig :-) wieder ein kleiner Schritt :-) Die restlichen Werte sind leider noch "0" . Aber so weiss ich jetzt das die HW schon mal tut :-) ali-003.jpg hat nicht funktioniert. Mit ali-005.jpg klappt es so weit schon mal.
Moin moin, ich habe gerade mal probiert das Ganze für mein Wemos D1 zu compilieren. Bekomme das Programm auch hochgeladen und eine IP. Nur leider kann ich nicht auf die Website zugreifen. Pingen kann ich den D1, somit sollte die Netzwerkverbidung stehen. Habe hier noch einen PiHole usw. laufen und somit nicht wirklich "Standard" Netzwerksettings. Kann es sein das sich der D1 in einer Whileschleife verläuft? Kann ich das Debuggin irgendwie aktivieren? Habe schon DEBUG_SEND auf 1 gesetzt, im Serial-Monitor ändert das jedoch die Ausgabe nicht. Grüße aus HH Jan
Angehängte Dateien:
-
ali-003.jpg
24 KB
Herbert K. schrieb:
ali-003.jpg funktioniert ebenfalls (konnte meinen Beitrag leider nicht
mehr editieren)
Dietrich schrieb:
...
Hallo Jan,
Keine Ahnung, welchen Source Du verwendest. Ich habe den von Hubi und
der Start in der Seriellen Console sieht zu Beginn so aus wie in der
Anlage.
Vielleicht hilft Dir das als Vergleich. Webserver ist vom Firefox und
Chrome erreichbar. Egal ob der NRF24L01+ vorhanden ist oder nicht.
:
Bearbeitet durch User
Moin Herbert, ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl. SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und mich wieder melden. Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss sich mein D1 weghängen.
Hallo da inzwischen einige Leute meine Source benutzen und noch Probleme haben, meine Frage: Soll ich eine Version bereitstellen mit einer Settings.h, in der genau beschrieben ist was einzustellen ist?
Hubi schrieb: > Hallo > da inzwischen einige Leute meine Source benutzen und noch Probleme > haben, meine Frage: Soll ich eine Version bereitstellen mit einer > Settings.h, in der genau beschrieben ist was einzustellen ist? Würde sich anbieten denke ich, da sonst viele Fragen bzgl. des Programms aufkommen, wir aber noch herausfinden müssen wie Channel Hopping und Werte setzen funktioniert sowie weitere Antworten/Werte herausfinden müssen. Bisher ist ja alles noch in Entwicklung. Marcel
Martin P. schrieb: > Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut) > > 01: > 2bytes unbekannt "1" > 2bytes dc_volt / 10 > 2bytes dc_amps / 100 > 2bytes dc_power / 10 > 2bytes unbekannt "0" > 2bytes Total_w Hallo Martin P., vielen Dank für Deine Analyse. Im Telegram "01" für die HM-Single (300/350/400) ist dies -- 2bytes unbekannt "0" -- evt. der Überlauf von -- 2bytes Total_w -- Bei einem WR habe ich schon einen Überlauf, bei einem 2. WR erwarte ich den Überlauf in ca. 5 Tagen je nach Sonne. Dann werde ich das sehen. Habe die Telegramme "01" und "82" erst mal so von Dir übernommen und bei meinen 2 HM 400 scheint das auch zu passen. Danke an ALLE für die bisherige Arbeit.
Herbert K. schrieb: > Im Telegram "01" für die HM-Single (300/350/400) ist dies > -- 2bytes unbekannt "0" -- > evt. der Überlauf von > -- 2bytes Total_w -- das ist ein guter Tipp - und macht auch Sinn, weil die 64 kWh (mit nur 16 bit) sind ja doch bald mal erreicht" .... bei mir dauert das noch .. bin erst bei 20 kWh... Was mir generell noch aufgefallen ist: Gestern war meine Hoymiles DTU als Offline im System und die Cloud zeigte auch keine aktuellen Daten. Mein ESP hingegen loggte ganz normal in den IOBroker mit. Heute Früh zeigt die Cloud plötzlich die fehlenden Daten von gestern bist Mitternacht an. Nach einem Aus/Einstecken der DTU loggt sie heute wieder normal. Entweder hatte die Cloud gestern ein Problem, oder die WR dürften eine Art Historie speichern und die DTU hat sie heute nach Sonnenaufgang noch irgendwie rausgeschickt?
Hubi schrieb: > Hallo > da inzwischen einige Leute meine Source benutzen und noch Probleme > haben, meine Frage: Soll ich eine Version bereitstellen mit einer > Settings.h, in der genau beschrieben ist was einzustellen ist? Hallo Hubi, ich denke das ist eine gute Idee um die Source von dir besser Nutzbar zu machen. Grüße Jan
Dietrich schrieb: > Moin Herbert, > > ja, ich benutze auch den von Hubi. Bei mir ist nach der „xxx2“ (vmtl. > SSID) Schluss. Mh, ich werde morgen mal ein anderes Board testen und > mich wieder melden. > > Vielen Dank schonmal für deinen Log, das Hilft. Irgendwo im Boot muss > sich mein D1 weghängen. Hallo zusammen, soo Fehler gefunden. Ich habe keine Fritzbox, daher funktiniert der TimeServer define #define TIMESERVER_NAME "fritz.box" natürlich nicht. Einfach auskommentieren und Hubis Angabe "pool.ntp.org" benutzen. Nun läuft der Webserver - jetzt muss nur noch der WR ankommen... :) Grüße Jan
Hallo, ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp. Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten im Log ?
1 | 1649772015 00 00DC 1B 2 95 73109025 73109025 010001017F00C702F900005E44039E08FBA3F89D AF08 A2DC DAA8 AF08 E3D3 E787 AF08 A2DC AF08 1F4A AF08 7860 0978 A436 A2DC A9E2 AEB6 08FE AF08 A2DC AF08 A9E2 25BB A2DC A9E2 F891 |
2 | hm400: Voltage: 38.30V, Ampere: 1.990A, Power: 76.10W |
3 | Total Production: 24.132kW, Daily Production: 926.00W, AC Voltage: 229.90V |
(erste spalte ist epochtime, welches ich hinzugefügt habe) Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ? Marcel
Marcel A. schrieb: > Hallo, > > ja, das Total mehr bit hat, kann wirklich sein. Guter Tipp. > > Von den HM-350|HM-400 Leuten, habt ihr auch ab und zu mal folgende Daten > im Log ? Hallo Marcel, ja bei mir kommt auch des öfteren etwas merkwürdiges. Bisher mache ich mir da nicht viel drauss. Bin froh, das ich das mit 2 Stk. HM400 so weit hinbekommen habe, trotz fehlender "C++" Kenntnisse. Ich versuche die nä. Tage mal Fehler zu produzieren, ob man die in den unbekannten Feldern wiederfindet. An die "C++" Programmierer: Bitte was muss ich wo ändern, um die 4 Byte zu Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr als 65535 werden können ? Danke schon mal.
:
Bearbeitet durch User
Martin P. schrieb: > Früher oder später wird auch eine etwas robustere Hardware interessant > werden. Ich habe mal google bemüht und Boards für die ESP8266 + NRF24L01 > Combo gefunden: > > http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/138-mysensors-wlan-gateway-milight-bridge > Scheint 2018 erdacht und für einen anderen Zweck gebaut worden zu sein. > Sollte als Ersatz-DTU aber auch seinen Dienst machen. > > Hier noch etwas minimalistischer: > > https://leetronics.de/en/blog/2017/09/23/esp8266-nrf2401-milight-gateway-pcb/ > > was mich bei letzterem allerdings verwundert, sind die fehlenden > Widerstände, die der ESP12 normalerweise braucht. Hallo, ich habe mal den Creator angeschrieben ob es okay ist, wenn wir uns ein paar Platinen machen lassen. Wenn das okay bist, bestelle ich mal 5 Stück. 4 davon würde ich dann kostenlos an die Hauptverantwortlichen hier verschicken, wenn ihr was damit anfangen könnt. Quasi als Support :) Grüße Jan
> Ich frage mich, ob das nur in meinem Programm beim Zugriff oder füllen > des Circular Buffer ist, oder ob das eine echte Nachricht vom WR ist ? > Marcel Ich habe solche bei mir auch gesehen … habe aber auch die gleiche CodeBase..
Hallo zusammen, ich bin heute auf der Suche nach einer DTU alternative auf euren Thread gestoßen. Dies ist mein erster Eintrag hier im Forum. Ich bin absolut beeindruckt was hier alles geleistet wurde. Ich bekomme auch bald einen HM-1500 und möchte die Daten selbst per MQTT auslesen. So wie ich es gelesen habe, besteht die Hardware aus ESP8266 + NRF24L01. Die hab ich zufällig schon rumliegen. Wo finde ich denn den Code? Viele Grüße an die großartigen Unterstützer, Analysten, Programmierer hier!!!! Gruß Chris
Herbert K. schrieb: > An die "C++" Programmierer: Bitte was muss ich wo ändern, um die 4 Byte > zu > Power Total zusammenzufassen (Telegram 01 / HM 350/400) so das es mehr > als 65535 werden können ? Danke schon mal. Ich mache das so:
1 | float extractValue4 (uint8_t *p, int divisor) { |
2 | //-------------------------------------------
|
3 | uint32_t ret = *p++; |
4 | for (uint8_t i = 1; i <= 3; i++) |
5 | ret = (ret << 8) + *p++; |
6 | return (ret / divisor); |
7 | }
|
Du übergibts einen Zeiger auf die Stelle in der Payload wo dein 4-byte Wert beginnt und als Divisor 1 (kannst du also auch weglassen), etwa so: [b] float wert = extractValue (&payload[??], 1) [/b] Das findest du aber alles in meinem am 10.4. geposteten Code.
Im Anhang überarbeitete Version meiner Software, die auf ESP als auch Arduinos läuft. Neu ist: - extra Settings.h mit den möglichen Einstellungen - automatische Konvertierung der WR-Seriennummer in diese umgedrehte Radio-ID - Source Sonne.h enthält Berechnung von Sonnenauf- und -untergang => nachts nicht mehr den WR abfragen
@Hubi, kannst Du das bitte via git bereitstellen? Sourcen in zip-Files ohne Versionierung in Foren teilen ist wenig hilfreich. Danke.
Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss der Funkmoduls an den ESP8266 D1 mit Hubis Software (Danke dafür!) nicht korrekt gemacht habe. Die Software an sich läuft und verbindet sich problemlos mit meinem WLAN, die Web-Oberfläche kann ich auch aufrufen, aber alles 0. Möglicherweise bin ich nicht der Einzige, der nicht sicher ist, welche Pins ausser den in Settings.h erwähnten mit dem ESP verbunden werden müssen. Meine Bitte: wäre jemand so nett, die komplette Verschaltung dieser Konfiguration zu dokumentieren...? Dankeschön! aus Settings.h: // Hardware configuration #ifdef ESP8266 #define RF1_CE_PIN (D4) #define RF1_CS_PIN (D8) #define RF1_IRQ_PIN (D3) GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für den NRF24) sind klar. Aber was ist mit MO (D7?) und MI (D6?)...
Peter L. schrieb: > Mein HM-1200 spricht nicht mit mir. Ich vermute, dass ich den Anschluss .... > Aber was ist mit MO (D7?) und MI (D6?)... Hallo, natürlich musst Du MISO, MOSI, CLK anschliessen, damit die RF24 LIB funktioniert. Einfach mal in die Datenblätter schauen vom ESP8266 und NRF24... Hab die HW gerade nicht zur Hand.
Peter L. schrieb: > aus Settings.h: > // Hardware configuration > #ifdef ESP8266 > #define RF1_CE_PIN (D4) > #define RF1_CS_PIN (D8) > #define RF1_IRQ_PIN (D3) > > GND und Vcc (3,3V bzw. 5V bei Verwendung der Spannungsregler-Platine für > den NRF24) sind klar. > > Aber was ist mit MO (D7?) und MI (D6?)... Ich habe: D4 -> CE D8 -> CSN D3 -> IRQ D5 -> SCK D6 -> MIso D7 -> MOsi VCC und GND ergeben sich. Leider auch noch kein Signal. @Hubi: war da nicht noch was mit der "ersten Taufe" damit der Gerät spricht? Sonnenoffest hab ich mal auf 120min gestellt, du verwendest da UTC, oder? Sonst sehr gute Arbeit :) Vielen dank!
Es gibt viele Bespiele in Google - aber halte dich nicht an die … sondern Google nach nrf24l01 Pinout und welchen Controller du hast. Verbinde die SPI Pins wie sie der Controller hat und wähle für CE und CSN und IRQ Die Pins aus dem Code. Beachte, dass es unterschiedliche Nomenklatur gibt (deshalb haben diese Pinout Bilder immer mehrere Namen)
Angehängte Dateien:
OK, wie auch von Daniel geschrieben, habe ich es so gemacht: NRF24 ESP8266 ---------------------- RF1_CE_PIN D4 RF1_CS_PIN D8 RF1_IRQ_PIN D3 RF1_MO_PIN D7 RF1_MI_PIN D6 RF1_SCK_PIN D5 GND G VCC(5V) 5V (NRF24 mit Spannungsregler-Platine) VCC(3,3V) 3V3 Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>. Morgen kommt die Sonne wieder ;-)
Peter L. schrieb: > OK, wie auch von Daniel geschrieben, habe ich es so gemacht: > > NRF24 ESP8266 > ---------------------- > RF1_CE_PIN D4 > RF1_CS_PIN D8 > RF1_IRQ_PIN D3 > > RF1_MO_PIN D7 > RF1_MI_PIN D6 > RF1_SCK_PIN D5 > > GND G > VCC(5V) 5V (NRF24 mit Spannungsregler-Platine) > VCC(3,3V) 3V3 > > Leider auch bisher noch nichts empfangen, und jetzt ist <Nacht>. > Morgen kommt die Sonne wieder ;-) Wir werden sehen ob ein Reboot über Nacht hilft. Ic hvermute trotzdem eher den initialen "Hello" Schritt, der noch fehlt, quasi ein Setup, damit erstmal WR und "Databox" zueinander finden. Sonst muss ich sagen, ist der Arduino-Code echt genial, sehr sauber und übersichtlich. Danke Hubi :)
Hallo zusammen da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS) und dazu eine CS( Chip select). Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe. Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software in Verbindung mit einem RasPi als "Datensammler" und Webserver mit grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder meine neue Weiterentwicklung kann sich bitte hier gern melden.
Hubi schrieb: > Hallo zusammen > da scheint es wohl Probleme zu geben bzgl der Schaltung von SPI. In > meiner Settings.h gehe ich davon aus, dass man je nach Hardware (ob > Arduino oder ESP) die Standard-SPI-Belegung nimmt (SCK, MISO,MOSIO,SS) > und dazu eine CS( Chip select). > Ein initiales "Hallo" habe ich nicht gebraucht, irgendwann gings, als > ich auf verschiedenen Kanälen gesendet und immer auf 3 gehorcht habe. > Und die Sache mit Git: ich habe keinen Account bei Git. Meine Software > in Verbindung mit einem RasPi als "Datensammler" und Webserver mit > grafischer Darstellung reicht mir im Moment. Aber wer Hilfe braucht oder > meine neue Weiterentwicklung kann sich bitte hier gern melden. Ein Git-Account sollte nicht kompliziert sein, wäre halt praktisch. Welche Belegung nutzt du an deinem Wemos? Vielleicht kann man das zusammen dort in die readme packen. Ich warte mal auf den Reboot über Nacht, vielleicht hilft der. Ich hab noch das große Fragezeichen, weil ich einen potentiell kompatiblen Typ nutze, kein originalteil. Laut Anleitung soll ein initiales binding durchgeführt werden, ob das wirklich nötig ist, weiß ich nicht. Ist es sehr aufwändig, so ein "Hello" zu implementieren, das man über Konsole oder Webserver anstoßen kann? Du hast gerade den vielversprechendsten Ansatz für den ESP8266. Ein Paypal-Spendenlink für den einen oder anderen Kaffee würde ich auch sehr begrüßen, genauso von den anderen, die hier so einiges beigetragen haben :) Ich hoffe noch auf die Leistungsregulierung, wenn das mit der Kommunikation komplett klappt. Dann kann man auf Nulleinspeisung oder Akku-laden via NodeRed schauen, der SDM z.B. ist ja auch keine Raketentechnik. Da würde ich mich dann mehr einbringen, wenn ich das ganze richtig zum laufen gebracht hab. lg
Hallo Daniel, mich würde mal Interessieren, woher die Annahme kommt, das der TSUN gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen technischen Angaben weichen beide eben ab. Zusätzlich die Information, das es ein hello signal geben soll weisen ggf. sogar schon drauf hin, das es eine andere Software hat. Und Hubi hat doch schon die Software bereitgestellt und erhebliche Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde den Github Link zu einer anderen Code Version und mache einen Pull Request und füge diesen Code hinzu. Marcel
:
Bearbeitet durch User
Marcel A. schrieb: > Hallo Daniel, > > mich würde mal Interessieren, woher die Annahme kommt, das der TSUN > gleich dem HoyMiles ist? Die technischen Daten unterscheiden sich ja > schon in einigen Punkten. Und ja, das Protokoll scheint das gleiche zu > sein, aber dennoch ist ja nicht mal gesagt das auf dem TSUN die gleiche > Software läuft. MPPT z.b. ist ja ein Software-Algorithmus und bei diesen > technischen Angaben weichen beide eben ab. In der Anleitung zu den Kommunikationsadaptern beider Hersteller steht Hoymiles drin. Die cloud bei Tsun läuft auf einer anderen URL, allerdings identisch aufgebaut. Es würde mich nicht wundern, wenn es eine Kopie ist. Die Initialisierung beider Geräte auf Kommunikationsebene ist identisch beschrieben. Was am Ende im Protokoll passiert, kann anders sein, ganz klar. > Zusätzlich die Information, das es ein hello signal geben soll weisen > ggf. sogar schon drauf hin, das es eine andere Software hat. Das Hello wurde schon in anderen Postings beschrieben, ebenfalls steht es in der Anleitung. > Und Hubi hat doch schon die Software bereitgestellt und erhebliche > Arbeit rein gesteckt damit man diese nutzen kann! Wenn Du diese auf > GitHub benötigst, dann schaue doch bitte weiter oben im Thread, finde > den Github Link zu einer anderen Code Version und mache einen Pull > Request und füge diesen Code hinzu. Und ich bin ihm sehr dankbar dafür. Einen ESP8266 als Interface nutzen zu können, ist ein großer Vorteil. Da ich noch einen Raspi und ein 2. RF24 Interface habe, schau ich die Tage mal, was ich tun kann. Werde auch noch einen Stick von Tsun besorgen und schauen, was der tut. Es wäre ungewöhnlich, wenn bei dieser Schnittmenge zwischen den Geräten, das nicht einfach nur eine Kopie mit kleinen Änderungen in der Ziel-URL ist, zumal selbst die Bedienoberfläche des Stick laut Anleitung beim Tsun identisch zu der von Hoymiles ist. Das mit Git werd ich gerne mit machen, sofern Hubi nichts dagegen hat.
Hallo,
Hubi´s Code funktioniert bei mir ohne Probleme. Ich habe auch keine
DTU...
Der Code hat sofort funktioniert, nachdem ich die WR SN eingetragen
habe.
1. Es muss (!) der nRF24L01+ sein. Das PLUS ist wichtig ! Ein "alter"
nRF24L01 (ohne Plus) funktioniert NICHT !
2. Sucht im Code nach
"// radio1.printPrettyDetails();"
und übersetzt den Code mal, in dem Ihr das wieder einkommentiert
"radio1.printPrettyDetails();"
Dann findet Ihr in der Seriellen Konsole was das - sofern der RF24
richtig verdrahtet ist - so aussieht.
Steht da NICHT "RF Data Rate = 250 KBPS " ist was Faul in
der Kommunikation zum nRF24L01+ .
SPI Frequency = 10 Mhz
Channel = 3 (~ 2403 MHz)
RF Data Rate = 250 KBPS
RF Power Amplifier = PA_MAX
RF Low Noise Amplifier = Enabled
CRC Length = Disabled
Address Length = 5 bytes
Static Payload Length = 32 bytes
Auto Retry Delay = 250 microseconds
Auto Retry Attempts = 0 maximum
Packets lost on
current channel = 0
Retry attempts made for
last transmission = 0
Multicast = Disabled
Custom ACK Payload = Disabled
Dynamic Payloads = Disabled
Auto Acknowledgment = Disabled
Primary Mode = RX
TX address = 0xe7e7e7e7e7
pipe 0 (closed) bound = 0xe7e7e7e7e7
pipe 1 ( open ) bound = 0x1234567801
pipe 2 (closed) bound = 0xc3
pipe 3 (closed) bound = 0xc4
pipe 4 (closed) bound = 0xc5
pipe 5 (closed) bound = 0xc6
Ja, wenn die Kommunikation mit dem nrf24l01+ erst mal funktioniert, kann es immer noch an der Funkschnittstelle scheitern. Einen Kondensator an +- des Moduls anlöten. Eine Zwischenplatine mit eigenem LDO (hier scheint es auch 2 Varianten am Markt zu geben: mit kleinen und großen SMD caps drauf) Eine nrf24l01+ Variante mit PA/LNA und SMA Antenne verwenden. Eine Dipolantenne an das kleine Modul löten. Wenn Kondensator dran ist, auch mal PA_MODE_HIGH oder PA_MODE_MAX probieren.
Angehängte Dateien:
-
P1100204.JPG
280 KB -
P1100205.JPG
300 KB -
P1100206.JPG
360 KB -
P1100207.JPG
220 KB
Hallo anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja nur ein paar Strippen zu löten. Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht nur für den HM-600, und auch für mehrere (unterschiedliche) WR gleichzeitig. Eine Version für RasPi könnte da auch noch drin sein. Ich überleg's mir mal. Vllt könten sich auch ein paar von uns zs-schließen und das mit Git machen, Aufgaben verteilen etc.
Hubi schrieb: > Hallo > anbei ein paar Bilder aus denen die Verkabelung ersichtlich ist. Meine > Hardware löte ich später noch auf eine Streifenrasterplatine, sind ja > nur ein paar Strippen zu löten. > Zum Thema Git: Wenn man diese Software schon öffentlich macht dann nicht > nur für den HM-600, und auch für mehrere (unterschiedliche) WR > gleichzeitig. > Eine Version für RasPi könnte da auch noch drin sein. > Ich überleg's mir mal. Vllt könten sich auch ein paar von uns > zs-schließen und das mit Git machen, Aufgaben verteilen etc. Hallo Hubi Herzlichen Dank für die SW und die Bilder. Und natürlich an dieser Stelle Danke auch an allen Beteiligten am Projekt. Ich habe eine DTU-Pro und MI1500 am Laufen, da die Zero Export Funktion nicht so lief, wie sie sollte (und wie die Hotmiles behauptet), steuere ich mit einem Python/Modbus script über die DTU den MI1500, so wie ich es richtig halte. Ich möchte gerne die DTU-Pro ersetzen, die SW hat Fehler (bei kleineren Loads) und die Hoymiles will es nicht korrigieren. Ich werde deine SW verwenden, mit WEMOS D1 mini und nrf24l01+ PA/LNA/SMA Antenne. Mich interessiert die WR Steuerung bzw. Limitierung, ich würde gerne hier mit machen, da ich den MI1500 über myPython/DTU prozentual limitieren und dort halten kann, könnte ich ev. die Limitierung heraus finden. Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die raw-Packete beobachten? Danke und grüsse aus dem Süden. Ziyat T.
Toe C. schrieb: > Bevor ich den ganzen Thread nochmals lese, kann ich mit deiner SW die > raw-Packete beobachten? Meine SW arbeitet auf Telegramm-Ebene. Ich weiß nicht so genau was du mit raw-Paketen meinst, wahrscheinlich eher sowas wie oben mittels Sniffer mitgeschnittenen Datenverkehr. Musst wohl doch den Thread nochmals lesen. Steuerung des WR wäre natürlich auch ganz nett, also dass man limitieren kann bzw diese auch aufheben kann. Wenn da was zu programmieren ist bin ich dabei, auch wenn ich keine DTU habe.
Eine Frage an die DTU-Wlite und DTU-Pro Besitzer: Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR über die offiziellen hoymiles Wege bekommen und auf welche Kommunikatiosart ? (also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem Smartphone, RS485 ?, ...) Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU... übertragen werden.
Herbert K. schrieb: > Eine Frage an die DTU-Wlite und DTU-Pro Besitzer: > > Was habt Ihr denn bisher so als Fehlermeldungen von den einzelnen WR > über die offiziellen hoymiles Wege bekommen und auf welche > Kommunikatiosart ? > (also Web-Server bei hoymiles, DTU-Pro bei Euch zu Hause, APP auf dem > Smartphone, RS485 ?, ...) > Wäre ja mal Interessant, denn das muß ja auch erst mal vom WR zu DTU... > übertragen werden. Hallo Herbert Ich steuere meinen MI1500 über DTU-Pro/ModbusRTU selber. Ich habe bisher an der DTU-Pro die folg. WR-Port-Status herausgefunden: PORT_STATUS = ["can't read", "?", "?", "Normal", "?", "(ev.)PV not connected", "?", "?", "Reduced"] Die 8=Reduced wird im S-miles als "remote shutdown" ersichtlich, manchmal;-). Grüsse Ziyat
Hallo, auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann es noch nicht montieren. Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1 laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht verpackt und hatte beim Transport ganz schön gelitten. Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht weiß, ob er den Transport überlebt hat. Gruß Hans ...und Hut ab vor eurer Arbeit hier !!!
Hallo in die Runde, wie versprochen kommt meine DTU für den TSUN am Dienstag. Bin gespannt wie das Innenleben aussieht. Mit welchen Tools macht es am meissten Sinn, die DTU auf rx/tx zu überwachen? Ich hätte USB-Serial Adapter hier und kann vom ersten Einschalten beobachten, theoretisch. Bislang komme ich mit dem Wemos nicht weiter, keine Kommunikation mit dem WR, was ich aber fast erwartet habe. Ich hab mal dein Stück des Bootvorgang und der Kommunikation mit angehängt. Debug ist aktiviert und die Sendedaten lasse ich mir mit anzeigen. lg Daniel
Hans W. schrieb: > Hallo, > > auf der Suche nach einer Möglichkeit den HM-1500 auszulesen, bin ich > hier gelandet. Leider ist mein BKW noch nicht vollständig und ich kann > es noch nicht montieren. > > Habe mir jetzt schon mal einen nrf24l01+ besorgt und mit dem Wemos D1 > laut Pinbelegung im Sketch verkabelt. Leider war das Ding so schlecht > verpackt und hatte beim Transport ganz schön gelitten. > > Die Webseite mit den Werten kann ich schon mal sehen. Gibt es eine > Möglichkeit, den nrf24l01+ ohne Wechselrichter zu testen, da ich nicht > weiß, ob er den Transport überlebt hat. > > Gruß Hans ...und Hut ab vor eurer Arbeit hier !!! Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem "+" bekommt? Vielen Dank!
Ich habe diese: WayinTop 2pcs NRF24L01+PA+LNA... https://www.amazon.de/dp/B07PBBC4H9 (Mit PA und LNA - die breakout boards dabei sind nicht gut) Und die: AZDelivery 5 x NRF24L01 mit 2,4... https://www.amazon.de/dp/B075DBDS3J
Hallo, kann man eigentlich auch einen RF-NANO (z.B. https://de.aliexpress.com/item/1005003513445043.html) verwenden? NRF24_SendRcv kompiliert, aber hier scheint es keinen IRQ zu geben?!
Der RF-Nano verhält sich merkwürdig: - isPVariant liefert true also PLUS - setDataRate liefert mit 250KBPS false - unterstützt also keine 250KBPS Insofern also wohl nicht brauchbar :-(
Hakko Marcus das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben, also sollte D2 der INT0 sein. Bei den Kundenbewertungen ist auch erwähnt, dass wohl nicht die Plus-Variante des RF-Moduls verbaut wurde, also keine 250 kbps.
Reinhard B. schrieb: > Hat vielleicht jemand einen link wo man das beschriebene Modul mit dem > "+" bekommt? bei mir gerade von AZ-Delivery angekommen: funktioniert! :-) Der Tip mit dem "PLUS" war entscheidend, Danke für Eure Unterstützung, mein HM-1200 spricht nun mit mir!
Hubi schrieb: > Vllt könten sich auch ein paar von uns > zs-schließen und das mit Git machen, Aufgaben verteilen etc. Also mein Vorschlag steht ja und wird auch schon fleißig geforkt: * https://github.com/grindylow/ahoy Persönlich bin ich eher an der Raspi-Seite interessiert, aber die beiden ergänzen sich ja gegenseitig.
Wir bräuchten dringend mal noch längere Logs von Datenverkehr mit echten DTUs. Ich meine, in den ursprünglichen Mitschnitten war das 0x80 ja garnicht notwendigerweise als das fortwährend zu sendende Paket zu erkennen - macht ja eigentlich auch keinen Sinn, sekündlich die Uhrzeit neu zu setzen. Vielleicht bringt das ja auch jedesmal das Channel Hopping wieder durcheinander? Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24 zu tun. Das wäre spitze, aber natürlich Hardware-intensiv... Meine DTU kam immernoch nicht - und die Hoffnung schwindet.
Angehängte Dateien:
-
IMG-20220416-WA0009.jpg
240 KB
Martin G. schrieb: > Hat jemand die Möglichkeit, seine DTU "lange" auf mehreren Kanälen zu > belauschen? Es gab mal weiter oben den Vorschlag, das mit mehreren NRF24 > zu tun. Das wäre spitze, aber natürlich Hardware-intensiv... Hallo Martin. Das war mein Plan. Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren bin. Konnte es leider noch nicht richtig ausprobieren. Aber ich denke, das wird neue Erkenntnisse bringen. Erste Tests haben aber schon gezeigt, dass die DTU leider auf mehr als 6 Kanälen sendet.
Hubi schrieb: > das mit dem Interrupt sollte gehen, ist doch ein Atmel328p auf dem > Board. Ist auch in deinem Link externe Interrupts(2 und 3) beschrieben, Mhh - ich dachte der IRQ wird (beim Aufbau Wemos D1/NRF-Modul) verwendet, um einen IRQ bei Empfang auszulösen (für die ISR). Der IRQ-Pin des NRF auf dem RF-Nano ist nicht verbunden. Meinst Du der Nano löst dennoch einen Interrupt auf D2 / D3 aus? Kann ich mir jetzt nicht vorstellen - außer man würde den IRQ-Pin des NRF mit dem Nano PIN D2 oder D3 verbinden. Normal ist da ja bei einem Nano nichts verbunden (außer eben wenn man ein externes NRF-Modul anschliesst). Fazit für das Topic: Der RF-Nano ist für das Auslesen der Hoymiles weniger (bzw. nicht) geeignet. Wenn man diesen dennoch testen möchte, dann ist zu prüfen, ob er wirklich ein NRF+ Modul hat (am besten die Datenrate von 250KPBS setzen und überprüfen). Es scheint wohl welche mit und ohne zu geben. Wenn er ein NRF+ Modul hätte, müsste man aber vermutlich auch die Software bzgl. der ISR / IRQ Thematik anpassen. Ich habe mir nun die hier im Thread genannten Module bestellt: [[https://www.amazon.de/dp/B075DBDS3J]] Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca. 10-15m LOS + 1 Holzdach überbrückt?
Hallo, habe einen HM1200. Aufschrift 1200HR. EU .HM. Die Seriennummer ist rein numerisch 116170522231, kann das sein? Habe die leider nicht vorher aufgeschrieben und nun mit einer Iphone/Holzlattenkombination auf dem Dach abgefilmt...... Danke
Marcus schrieb: > Kann hier jemand was über die Reichweite sagen? Bekomme ich da ca. > 10-15m LOS + 1 Holzdach überbrückt? Hallo Marcus genau diese benutze ich auch. Die reihen hier vom Wohnzimmer, wo programmiere und teste bis zum WR auf dem Gartenhaus, ca. 20 m entfernt, dazwischen eine Tür mit Isolierglas und Büsche/Bäume.
> Die Seriennummer ist rein numerisch 116170522231, kann das sein?
Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch
mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde
ein 0x vorangestellt sein.
@Thomas B. Noch etwas für die Statistik Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" - da ich gerade den WR fotografiert habe: Die Seriennummer meines HM-400 beginnt mit: 1121
Lukas P. schrieb: >> Die Seriennummer ist rein numerisch 116170522231, kann das sein? > > Ja ist korrekt. Habe auch einen HM1200, meine Seriennummer fängt auch > mit 11617 an. Diese Seriennummer wird als hex interpretiert, als würde > ein 0x vorangestellt sein. Danke, wo fange ich an? Der Thread ist etwas unüberschaubar. Ich habe NRF, Atmega, Espxxxx und Raspi…
Angehängte Dateien:
-
AhoyMiles_bb.png
62 KB -
AhoyMiles_schem.png
36 KB
Danke an Hubi für das Update des ESP8266/ESP32 Codes und die anderen die hier schon fleißig getraced haben! Seit ich meine HM-600 Seriennummer (beginnt mit 1141 7310 xxxx) eingetragen habe und das in der alten Version (vom 10.4.) fehlende Debug.h auskommentiert habe funktioniert es bei Tageslicht problemlos. Ich habe diese Bibliotheken extra installiert: * RF24 * TimeLib * Pinger (braucht man in der neuen Version vom 13.4. evtl. nicht mehr ?) Hier sind die Verbindungen meiner beiden Komponenten: * Pinout des PA nRF24L01+ Moduls: Ich habe dieses hier von derpaule auf eBay bestellt, scheint nur jetzt vergriffen zu sein. Aber man kann wie bei den AZ-Delivery aus der Zone sehr gut das nRFL01 "+" sehen. https://www.ebay.de/itm/165071116650 Die Debug Ausgaben sollte m.E. immer das og. radio1.printPrettyDetails(); aktiviert haben, damit man etwas über die korrekte Belegung des nRF24L01 Moduls erfährt.
1 | |Colour|Description|Pin|Pin|Description|Colour| |
2 | |------|-----------|---|---|-----------|------| |
3 | |black | GND |[1]|[2]| VCC +3.3V |white | |
4 | |grey | CE |[3]|[4]| CSN |purple| |
5 | |blue | SCK |[5]|[6]| MOSI |green | |
6 | |brown | MISO |[7]|[8]| IRQ |yellow| |
* ESP8266 / NodeMCU Anschlüsse: Wire Connections
1 | +-----------+ +-----------+ |
2 | | nRF24L01+ |--colour--| ESP8266 | |
3 | | | | | |
4 | | GND |---black--| GND | |
5 | | VCC |----red---| +3.3V | |
6 | | CE |---grey---| D4 | |
7 | | CSN |--purple--| D8 | |
8 | | SCK |---blue---| D5 | |
9 | | MOSI |---green--| D7 | |
10 | | MISO |---brown--| D6 | |
11 | | IRQ |--yellow--| D3 | |
12 | +-----------+ +-----------+ |
Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in das Readme.md auf dem Ahoy Github einchecken. @Hubi unter welcher Lizenz steht denn Dein Source Code und darf der ebenfalls eingecheckt werden ? Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter verbessern. Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter (Liste/Array mit WR IDs) in einer Schleife abfragen kann ? Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher praktisch. Eine Ausgabe der Daten im Serial Plotter Format wäre für einfache Tests ohne MQTT, etc. ebenfalls geschickt. Hier ist die PDF Dokumentation [1] und hier die offizielle Markdown Doku [2] der Arduino Software zum Serial Plotter Protokoll. [1] https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.pdf [2] https://github.com/arduino/Arduino/blob/master/build/shared/ArduinoSerialPlotterProtocol.md
Hallo, seit Mitte Februar lese ich begeistert in diesem Thread. Leider hatte ich bis jetzt nur Zeit die unglaubliche Anzahl der Beiträge zu lesen. Vielen Dank für eure Arbeit, es ist einfach toll zu sehen wie schnell es hier weitergeht! Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier möchte ich was beitragen. Ein pull-request habe ich erstellt. Mein Setup: - HM1200 - NRF24L01+ https://www.ebay.de/itm/255283312809 - ESP8266 (ESP-07) - Verdrahtung wie in dem Post darüber Aktueller Stand: Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station). Ich konnte damit auch schon loggen, allerdings habe ich festgestellt, dass ich nur Antworten mit Command 0x81 bekomme. Wenn ich den Code von Hubi direkt verwende, dann kommen auch andere Commands. Zur Verifizierung der Werte habe ich einen Sonoff-POW-R2 vor dem Wechselrichter und kann damit die Leistung vergleichen. Die Werte aus Hubi's Webinterface stimmen nicht für meinen HM1200.
isnoAhoy schrieb: > @Hubi unter welcher Lizenz steht denn Dein Source Code und darf der > ebenfalls eingecheckt werden ? > Ich hatte gelesen, Du möchtest ihn erst noch aufräumen bzw. noch weiter > verbessern. > > Ist eigentlich eine Option geplant, die mehrere Hoymiles Microinverter > (Liste/Array mit WR IDs) in einer Schleife abfragen kann ? > Als Ausgabe wäre dafür eine CSV Liste bzw. ein JSON Dokument sicher > praktisch. Moin zusammen Meine Source hat keine Lizenz, stammt ja ursprünglich auch nicht von mir sondern von der ahoy-Seite bei Github. Ja, im Moment bin ich noch am aufräumen und verbessern. Eine Version für mehrere WR ist in Arbeit. Die abzufragenden Messwerte hinterlege ich in einer Liste, pro Messwert eine Zeile mit WR, Messwertname, Einheit, Telgramm-ID, Offset, Länge, Funktion. Als Funktion kann man einen Divisorwert oder eine selbst definierte Funktion nehmen, zb wenn man die Stromstärke haben will mittels P/U. Da das ganze auch für Arduinos (zB Pro mini) laufen soll, musste ich etwas aufräumen. Besonders in der crc.cpp konnte ich über 500 byte einsparen, indem ich eine crc-Lib benutzt habe. Aber es läuft ohne Speicherwarnung auch auf dem Pro Mini, natürlich nicht mit webinterface, aber mit Ausgabe über Serial. Wenn der Autor von der ursprünglichen NRF24-SendRcv (ahoy) nichts dagegen hat dann stelle ich meine Entwicklung ins Git. Meine Source ist im Moment nur für den HM-600. Für andere WR-Typen wird das nicht funktionieren, denn da sind die Requests und Antworten anders mit anderen Telegram-IDs und offsets. Wenn mir jmd seine Erkenntnisse über seinen WR zuschickt, bringe ich das in meine Source mit ein. Schöne Ostern
Wenn mir jmd seine Erkenntnisse > über seinen WR zuschickt, bringe ich das in meine Source mit ein. > Schöne Ostern Ich habe weiter oben gepostet, dass HM-700 gleich wie der HM-600 tut und wie die Interpretation für HM-350 ist (und HM-400 scheint gleich zu sein) Brauchst du trotzdem meinen Code dazu auch?
Source brauche ich im Moment noch, die nötigen Daten suche ich mir oben zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst Mehr-WR-Fähigkeit entwickeln will.
Source brauche ich im Moment noch nicht, die nötigen Daten suche ich mir oben zusammen, kann aber noch etwas dauern, da ich im Prinzip zuerst Mehr-WR-Fähigkeit entwickeln will.
Oliver F. schrieb: > yveaux NRF24 sniffer Hallo, Oliver F., könntest du eventuell den Code posten? Wollte auch mal ein serielles MySensors-GW umflashen und zum sniffen nutzen, aber leider bekomme ich schon den Ausgangs-Sketch von Yveaux nicht via Arduino-IDE compiliert. Konkret wird die "wrong number of template arguments" bzgl. des CircularBuffer (Zeile 97?) bemängelt... Wäre toll, wenn du da helfen könntest.
@Hubi, @Martin G(petersilie) Hallo zusammen Mein Setup: DTU-Pro MI1500 (nur Port3/4 mit PV's) WemosD1mini NRF24L01+ wie https://www.ebay.de/itm/255283312809 Ich verwende Hubi's letzte Version(mit settings.h): - NRF24L01+ mit 256KBPS funktioniert, siehe init in log Dateien - MI1500 gibt keine Antwort, siehe NRF24_DTU_OFF.log Aber wenn ich DTU-Pro einschalte: - erhalte ich etwas, die PV/AC/etc. Werte stimmen nicht (wahrscheinlich auch, da MI1500 4 Ports hat), siehe NRF24_DTU_ON.log - ich sehe neue CMD's, siehe NRF24_CMDXX, CMD 00,5A,55 Grüsse Ziyat T.
Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das Telegramm mit command 00 müsstest du mal untersuchen, zu was die aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die Werte der unbestückten Ports sein!?
Hubi schrieb: > Ich vermute mal, dass dein MI1500 andere Requests braucht, die ja deine > eingeschaltete DTU-Pro macht und dann auch was zurückkommt. Das > Telegramm mit command 00 müsstest du mal untersuchen, zu was die > aufgeführten Werte in deiner Anlage passen. Die Nullen könnten doch die > Werte der unbestückten Ports sein!? Habe schon versucht die Daten zu analysieren, wie ich sie anschaue ist gleich, bekomme ich keine gescheitere Werte, siehe Anhang
Hallo wenn sich jemand interessiert im Anhang MI1500 > DTU-pro log
Angehängte Dateien:
Falls noch nicht bekannt, mein HM-1200 sendet auch 84er-Telegramme. Nicht so oft, aber immer wieder. Panels: 2 + 1, aktuelle Leistung: 800.69W, 4.895kWh letzte 24h, heute 2.322kWh, total 73.528kWh
:
Bearbeitet durch User
Leider, mein 1500 wird auch noch nicht unterstutzt, aber wenn ich mal helfen kann, schick mir mail auf robert (at) bleumer.nl Kein DTU Pro dabei übrigens.
Angehängte Dateien:
-
220418_HM1200_Bytes.png
57 KB
Hallo zusammen, ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück weitergekommen. Dank des Excel-Screenshots von tbnobody (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") habe ich so ziemlich alle Felder der Commands 01, 02, 03 und 84 für den HM1200 zuordnen können. Ich habe als Input die Firmware von Hubi verwendet und das serielle Log ausgewertet. Heute habe ich den ganzen Tag mitgeloggt und konnte dadurch sehr gut die Zuordnung bestimmen. (220418_log_out.xlsx ist das Log von heute) Die Werte stimmen mit meinen durch einen vorgeschalteten Sonoff POW R2 gemessenen Werte sehr gut überein (vor allem bezogen auf die Tagesproduktion und die Gesamtproduktion). Falls jemand meine Schritte nachvollziehen will, hier so ein grober Fahrplan: - ESP Firmware von Hubi, seriellen Output mitloggen - Log bei https://regexr.com/ reinladen und mit folgender Regex filtern, die ausgegebene Liste dann wieder in ein File kopieren (Input für main.cpp) - main.cpp kompilieren (VS2019 Projekt kann ich auch noch teilen) - ausgegebenes CSV in LibreOffice / Excel öffnen und verschönern Regex:
1 | ([0-9]+\s[0-9]+\s[0-9A-F]+\s[0-9A-F]+\s.\s+[0-9]+\s[0-9]+\s[0-9]+\s[0-9A-F]+\s[0-1]) |
Lukas P. schrieb: > Hallo zusammen, > > ich bin mit der Zuordnung der einzelen Bytes ein gutes Stück > weitergekommen. .... Commands 01, 02, 03 und 84 für den HM1200 Auch wenn ich aktuell keinen HM1200 habe, sage ich einfach mal Danke für die Arbeit !
Angehängte Dateien:
-
220419_HM1200_Bytes.png
110 KB
Jetzt ist mir aufgefallen, dass die 16bit vor den jeweiligen Gesamterträgen 0 sind, daher nehme ich an, dass die Gesamterträge als 32bit Wert geführt werden. Weitere 8 Byte geklärt. Byte 1 und 2 vom Command 01 könnte ein AC-Enable sein oder eine Art Netz-Sync boolean. Was mir noch aufgefallen ist: es gibt nur 2 DC Spannungen, kann es sein, dass diese für jeweils 2 Eingänge gelten (HM1200 hat 4 Eingänge, aber nur 2 MPPT, also hat jeder MPPT eine Spannung).
wo fange ich an? Der Thread ist etwas unüberschaubar. Ich habe NRF, Atmega, Espxxxx und Raspi…
analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.81 PV-DC.P:163.10 PTotal-Ueberlauf-Unbekannt.W:0.00 PTotal.W:65535.00 PToDay.W:106.00 AC.V:238.10 analyse 01 HM xxx Single: unbekannt-01-1:1.00 PV-DC.U:42.80 PV-DC.I:3.69 PV-DC.P:157.80 PTotal-Ueberlauf-Unbekannt.W:1.00 PTotal.W:0.00 PToDay.W:107.00 AC.V:237.90 HM400 der "Überlauf" :-) ist gerade eben passiert :-) Also (P-Total) ist 4 Byte :-) wie vermutet :-) Euch Allen einen schönen Tag
Angehängte Dateien:
Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank holt, müssten in den Telegrammen ja auch noch Hardware und Software Version versteckt sein ? (wird in der Cloud ja angezeigt)
Herbert K. schrieb: > HM400 der "Überlauf" :-) ist gerade eben passiert :-) > Also (P-Total) ist 4 Byte :-) wie vermutet :-) Super, dann stimmt die 4 Byte Größe wie im Manual angegeben - dann war ich am Anfang doch nicht ganz auf der falschen Spur. Ich habe einen HM600, da müssen dann die 'Überlauf' Bytes in 2 Nachrichten verteilt sein, sonst geht das nicht auf. Ich vermute dann mal die letzten beiden 'null' Bytes (24/25) in Msg 01 für P1 total, und die beiden Bytes vor P2 Total in Msg 02 (12/13). Mal sehen, ob/wann das jemand mit einem HM600 bestätigen kann - bei mir dauert das wohl noch ... In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen Nachricht um 1 erhöht wird (ich sende aktuell alle 15 Sekunden eine Anfrage ab). Da ich mir die Nachrichten der anderen Inverter nicht so genau angeschaut habe, gibt es sowas da auch (ich glaube, ich hatte da was gelesen - ansteigender Wert)? Das könnte dann ein Hinweis sein, dass sich dahinter mehr verbirgt. Evtl. lässt sich ja damit irgendwie der Inhalt der letzten 4 Bytes dieser Nachricht entschlüsseln, aber ein Muster (oder Wiederholungen, die z.B. auf die noch fehlenden SW/HW Version hindeuten könnten) habe ich bislang noch nicht gefunden. In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder abends das Licht schwach ist und keine Einspeisung passiert, ist dieser Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und '1002' gesehen. Leider habe ich keine passenden Codes in den Manuals gefunden, aber es schaut plausibel aus.
lpb schrieb: ... > In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder > abends das Licht schwach ist und keine Einspeisung passiert, ist dieser > Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) > ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und > '1002' gesehen. ... Ich biete zusätzlich noch 1003,1004,1008,1038
lpb schrieb: > In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein > inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen > Nachricht um 1 erhöht wird An welcher Position?
Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden, einzig die Energieproduktionen sind monoton steigend. Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir eine Gesamtübersicht / Doku der Bytes machen können? Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander die Module ab und wieder angeklemmt habe -> sie stimmt.
Herbert K. schrieb: > Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank > holt, müssten in den Telegrammen ja auch noch Hardware und Software > Version versteckt sein ? > (wird in der Cloud ja angezeigt) Ich denke, es gibt weitere Kommandos, die nur am Anfang ausgetauscht werden, wenn z.B. die DTU mit dem Wechelrichter Kontakt aufnimmt. Hat jemand mit einer DTU schon mal während der Einstellung der Begrenzng der Nennleistung die Kommandos 'gesnifft'?
Lukas P. schrieb: > Ich habe für den HM1200 noch keine inkrementellen Zähler gefunden, > einzig die Energieproduktionen sind monoton steigend. > > Hat jemand eines anderen WR als HM1200 ein Log zum auswerten, damit wir > eine Gesamtübersicht / Doku der Bytes machen können? > > Habe heute die Zuordung der Eingänge überprüft, indem ich nacheinander > die Module ab und wieder angeklemmt habe -> sie stimmt. Ich hätte da Daten, darf aber nicht mitspielen: wo fange ich an? Der Thread ist etwas unüberschaubar. Ich habe NRF, Atmega, Espxxxx und Raspi…
Angehängte Dateien:
-
hm600_msg0x83.png
120 KB
Martin G. schrieb: > lpb schrieb: >> In der HM600 Nachricht 131 (0x83) steckt offensichtlich ein >> inkrementeller Zähler, der sehr zuverlässig in jeder empfangenen >> Nachricht um 1 erhöht wird > > An welcher Position? Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in dem angehängtem Auszug der dekodierten Daten).
> wo fange ich an? > Der Thread ist etwas unüberschaubar. > Ich habe NRF, Atmega, Espxxxx und Raspi… NRF24L01+ und ESP8266/ESP32 funktionieren anhand des o.g. Schaltplans (Fritzing) und mit der Software NRF24_SendRcv.zip (18,2 KB) von Hubi vom 13.4.2022 für einen Hoymiles HM-600 recht zuverlässig. Solltest Du einen anderen HM-1200, etc. Wechselrichter haben, ist wohl noch etwas Detailarbeit nötig. Auch die Kommandos der DTU (pro) um ggf. den Zero-Export-Restriction Modus (z.B. Limitierung der Asugangsleistung auf 600W bzw. 600VA) umzustellen sind bisher noch nicht bekannt. Einzelne Bytes der Nachrichten sind aktuell auch noch nicht zweifellos geklärt, u.a. Hardware-, Software- und Netzprofilversion wie in der Hoymiles Cloud ausgegeben sind noch unbekannt. Dazu ggf. die letzten Beiträge von lumapu und avr-herbi nochmal lesen. Wenn ich es richtig aufgefaßt habe stehen aktuell noch einige große Themen an: * DFU (pro) Kommunikation bei der Einrichtung der Hoymiles App (am besten auf mehreren / allen Kanälen) mitschneiden. * genaueres Verständnis für das sog. Channel Hopping, damit hängt evtl. auch die laufende Nummer der Nachrichten und der CRC Algorithmus zusammen. * die ModBus Schnittstelle scheint die meisten Datagramme zu beschreiben. Hierzu sollte man die Dokumentation mit dem bisher erforschten nochmals vergleichen und ggf. bestehende Lücken auf unserer Seite dokumentieren bzw. untersuchen. * HM-600, HM-1200, etc. Protokoll genauer untersuchen bzw. länger Protokoll Aufzeichnungen analysieren (wg. Überlauf). * Inverter Status Codes 1000, 1001, 1002, 1003, 1004, 1008, 1038 in der 0x83 Nachricht interpretieren. * NRF24_SendRcv aktuell nur für HM-600, daher für andere Wechselrichter HM-1200, etc. erweitern. * NRF24_SendRcv erweitern um mehrere Inverter / Wechselrichter nacheinander abzufragen.
Herbert K. schrieb: > Sofern die hoymiles Cloud das nicht aus einer Firmen internen Datenbank > holt, müssten in den Telegrammen ja auch noch Hardware und Software > Version versteckt sein ? > (wird in der Cloud ja angezeigt) Bis auf die Softwareversion sollte alles in der Seriennummer enthalten sein. Diese, soweit ich das verstanden habe, gibt man ja beim Einrichten der DTU an. Marcel
> Wer erbarmt sich?😪 Du kannst auch das Ahoy [1] GitHub Repo von Martin G. (Petersilie) auschecken, dort befindet sich nun auch die von lumapu um ein ESP WiFi-Setup und OTA erweiterte ESP8266 Version, wie auch die bereits im Vorfeld von den Ersten hier im Thread benutzte Python Variante des ahoy Tools. Dafür brauchst Du dann halt einen Raspberry Pi 2+ das NRF24L01+ Modul und die Verkabelung. Was Du verwenden und erreichen möchtest entscheidet jede/r selbst. [1] https://github.com/grindylow/ahoy/
Herbert K. schrieb: >> In den Bytes 16/17 vermute ich den Inverter Status. Wenn morgens oder >> abends das Licht schwach ist und keine Einspeisung passiert, ist dieser >> Wert '0', sobald der HM einspeist (AC Power und Strom nicht mehr Null) >> ist der Wert (meistens) '1000'; ich habe aber auch Werte von '1001' und >> '1002' gesehen. ... > Ich biete zusätzlich noch 1003,1004,1008,1038 In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von Registern angegeben, hängt das eventuell miteinander zusammen ? 4.3.2 Microinverter Data Register List The following registers provide a microinverter data register list, which can be read-only with the function code 0x03 | Registers | Name | Decimal | Units | Remark | | --------- | ---------------- | ------- | ----- | ------------------------------------------------------------ | | 0x1000 | Data Type | / | / | Default, 0x3C | | 0x1001 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1002 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1003 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1004 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1005 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1006 | Microinverter SN | / | / | 12-digit decimal number Big-Endian For example, 116151200012 | | 0x1007 | Port Number | / | / | | | 0x1008 | PV Voltage | 1 | V | | | 0x1009 | PV Voltage | 1 | V | | | 0x100A | PV Current | 1/2 | A | 1 for MI Series, 2 for HM Series | | 0x100B | PV Current | 1/2 | A | 1 for MI Series, 2 for HM Series | | 0x100C | Grid Voltage | 1 | V | | | 0x100D | Grid Voltage | 1 | V | | | 0x100E | Grid frequency | 2 | Hz | | | 0x100F | Grid frequency | 2 | Hz | | | 0x1010 | PV Power | 1 | W | | | 0x1011 | PV Power | 1 | W | | | 0x1012 | Today Production | / | Wh | | | 0x1013 | Today Production | / | Wh | | | 0x1014 | Total Production | / | Wh | | | 0x1015 | Total Production | / | Wh | | | 0x1016 | Total Production | / | Wh | | | 0x1017 | Total Production | / | Wh | | | 0x1018 | Temperature | 1 | °C | Microinverter internal temperature | | 0x1019 | Temperature | 1 | °C | Microinverter internal temperature | | 0x101A | Operating Status | / | / | | | 0x101B | Operating Status | / | / | | | 0x101C | Alarm Code | / | / | | | 0x101D | Alarm Code | / | / | | | 0x101E | Alarm Count | / | / | | | 0x101F | Alarm Count | / | / | | | 0x1020 | Link Status | / | / | Communication status with DTU | | 0x1021 | / | / | / | Fixed, 0x07 | | 0x1022 | Reserved | / | / | | | 0x1023 | Reserved | / | / | | | 0x1024 | Reserved | / | / | | | 0x1025 | Reserved | / | / | | | 0x1026 | Reserved | / | / | | | 0x1027 | Reserved | / | / | | | 0x1028 | Data Type | / | / | Default, 0x3C | | 0x1029 | | / | / | | Die Daten können offenbar mit dem entsprechenden 0x03 Kommando angefordert werden und aus der entsprechenden 0x03 Antwort entnommen werden: 4.2.3 Read Device Data * Command sending format | Name | Length | Value | Remark | | ---------------- | ------ | ----- | ------------- | | Address | 1 | | RS485 Address | | Function Code | 1 | 0x03 | | | Register Address | 2 | | Big-Endian | | Register Count | 2 | | Big-Endian | | CRC | 2 | | CRC16 | * Command response format (if success) | Name | Length | Value | Remark | | --------------- | ------ | ----- | ------------- | | Address | 1 | | RS485 Address | | Function Code | 1 | 0x03 | | | Data Length | 2 | | | | Data 1 | 2 | | Big-Endian | | Data 2 | 2 | | Big-Endian | | ...... | | | | | CRC | 2 | | CRC16 | * Command response format (if failed) | Name | Length | Value | Remark | | --------------- | ------ | ----- | ------------- | | Address | 1 | | RS485 Address | | Function Code | 1 | 0x83 | | | Wrong Data Code | 1 | 0x01 | | | CRC | 2 | | CRC16 | [1] https://www.mikrocontroller.net/attachment/552319/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
> Ich arbeite schon seit langer Zeit mit den ESP8266 Modulen und hier > möchte ich was beitragen. Ein pull-request habe ich erstellt. > > Aktueller Stand: > Mein ESP Code basiert auf @Hubi's Code vom 13. April. Eingebaut habe ich > es in mein eigenen ESP-Baukasten (Webinterface, OTA, AP und Station). Hallo Lukas P., habe mir mal Deinen Code aus dem ahoy github geclont und versucht zu deployen. Folgende Punkte sind mir aufgefallen: * Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F. bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die Spannung am +3.3V Anschluß des ESP8266 ein. * das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt wie die ino Datei. * ich habe versucht die WiFi und Wechselrichter Daten auf der Setup Seite einzutragen. Leider ist das Programm die ganze Zeit schon beschäftigt im Hintergrund per nRF24L01+ und vermutlich Dummy Adress-Daten an den Hoymiles zu senden und zu empfangen. Dadurch verliere ich immer die Verbindung, bevor ich die WiFi und Device Daten eingeben kann. Gibt es eine Möglichkeit das Hauptprogramm (im unkonfigurierten Zustand) anzuhalten bzw. eine längere Wartezeit (z.B. 5 Minuten) zwischen den Anfragen zu konfigurieren ? * Alternativ könnte man diese evtl. auch in der defines.h hinterlegen, nur habe ich die korrekten define / settings nicht herausgefunden: #define SSID "meineSSID" #define PWD "meinPasswort" #define DEVNAME "ahoy-esp" #define HOY_ADDR 0x1141 7312 3456 * ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73 01 ?
Danke @isnoAhoy! Am Woende werfe ich mal den Lötkolben an. Mal schauen was ich dem HM1200 entlocken kann. Ich bin auch an einer Nulleinspeisung interessiert. Habe noch keinen Plan wie man so etwas erreichen kann. Ggf. auch ein Projekt hier im Forum unter anderem Thread, oder gibt es das gar schon? Danke für die Zusammenfassung.
isnoAhoy schrieb: > Folgende Punkte sind mir aufgefallen: > > * Du setzt mRadio->setPALevel(RF24_PA_MAX); in app.cpp obwohl Oliver F. > bemerkt hat, daß bei ihm nur RF23_PA_MIN bzw. RF24_PA_LOW mit 100uF am > nRF24L01+ Modul funktioniert. Vermutlich bricht bei RF24_PA_MAX die > Spannung am +3.3V Anschluß des ESP8266 ein. ich sehe aktuell kein Problem. Danke für den Hinweis, ich werde die anderen Settings mal ausprobieren. Aktuell kommen die 3.3V aus meinem FTDI USB Adpater. Habe auch schon mal extern versorgt, das hat aber nichts verbessert. Was mir aufgefallen ist: Ich bin relativ weit weg vom WR (eine Betondecke und 10m durch den Garten). Wenn ich allerdings direkt zum WR gehe, bekomme ich keine Pakete mehr. Hier im Keller muss die Antenne auch sehr genau liegen. > * das Verzeichnis heißt ahoy/tools/esp8266 aber das ahoy-esp.ino, meine > Arduino IDE 1.8.13 beschwert sich, daß das Verzeichnis nicht so heißt > wie die ino Datei. > [...] Danke für dein Feedback, ich habe eine neue Version eingecheckt, die hoffentlich alle deine Probleme beseitigt, hier das commit-log: - renamed .ino (must be identical to parent folder name) - build CRC over settings, only if the CRC matches settings are applied - send command 0x80 (set time was wrong) - improved crc16 routine - added statistics for received commands and send statistics (channels are not correct for now!) - receive of commands 0x01, 0x02, 0x03, 0x81 and 0x84 working
Angehängte Dateien:
-
220420_esp.png
44 KB
Im Anhang mal ein Screenshot der aktullen Verison. Wie im Commit-log schon geschrieben, stimmt die Statistik der Kanäle nicht, da diese Info nicht synchron erfasst wird, die Statistik der Cmds ist korrekt.
isnoAhoy schrieb: > ist die HOY_ADDR eigentlich als komplette Serialnumber anzugeben oder > bereits im um die "Modelnumber" gekürzten BCD Format, d.h. 0x56 34 12 73 > 01 ? Die Seriennummer muss man so angeben, wie sie auf dem WR steht. Nach jedem Byte muss ein ":" eingefügt werden, also z.B.
1 | 11:61:11:22:33:44 |
Hallo Lukas P. ich habe mir mal deinen Code im Git angeschaut, das ist ja super, alles sauber in C++. Mit meiner Programmierung bin ich schon weiter gekommen, auch schon für mehrere WR. So ganz gefällt mir das noch nicht, denn ist noch sehr RAM-intensiv, da die Konstanten halt alle dort abgelegt sind. Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen, melde dich.
Hallo Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?
:
Bearbeitet durch User
isnoAhoy schrieb: > In der Dokumentation zum ModBus Protokoll [1] wird folgende Liste von > Registern angegeben, > hängt das eventuell miteinander zusammen ? Modbus ist ein eigenes Kommunikationsprotokoll, siehe [https://de.wikipedia.org/wiki/Modbus]. Der "Funktionscode 0x03" dort bedeutet "Register lesen". Das hat nichts direkt mit unserem CMD=0x03 zu tun. Aber die Infos sind natürlich trotzdem nützlich. Zum Beispiel sehen wir anhand der Registerliste, welche Werte die Wechselrichter vermutlich liefern können, und was man vermutlich einstellen können sollte. Und mindestens der 0x80 Befehl ("Uhrzeit setzen") verwendet die gleiche CRC16 wie das Modbus Protokoll.
lpb schrieb: >> An welcher Position? > > Ab Byte 18, direkt nach der Temperatur, bzw im Payload ab Byte 9 (wie in > dem angehängtem Auszug der dekodierten Daten). Hallo lpb, ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses Ergebnis bzw. wie genau fragst Du den WR ab?
Angehängte Dateien:
-
220420_ESP_2.png
36 KB
Hubi schrieb: > Wenn du Interesse an meinem Konzept hast, um es bei dir einzubauen, > melde dich. Danke für dein Lob. Ohne deine Vorarbeit hätte ich das nicht so schnell auf die Beine gestellt, danke für die Vorlage =) Ja ich habe interesse, wie du mich erreichst? - in jedem Git commit findet man in den ersten Zeilen die E-Mail des Autors - sofern diese richitg angegeben ist: Einfach ein '.patch' an die URL hängen und schon hast du sie ;-) https://github.com/grindylow/ahoy/commit/7d2437828830d7825953844d632aed72940d942c Anbei noch ein Screenshot meiner Darstellung der Werte - ich werde den Stand heute noch committen.
isnoAhoy schrieb: > Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in > das Readme.md auf dem Ahoy Github einchecken. @petersilie würdest du die Diagramme in Git übernehmen, ich fände das super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann könnte man bei Fragen immer öfter auf das Repository verweisen.
Lukas P. schrieb: > isnoAhoy schrieb: >> Die beiden ASCII Diagramme bzw. das Fritzing Layout kann man gerne in >> das Readme.md auf dem Ahoy Github einchecken. > > @petersilie würdest du die Diagramme in Git übernehmen, ich fände das > super und würde auch helfen einen Quickstart-Guide zu erstellen. Dann > könnte man bei Fragen immer öfter auf das Repository verweisen. Gute Idee. Hab mal die Diagramme und einen Anfang eines Quickstart-Guides hochgeladen: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
:
Bearbeitet durch User
Martin G. schrieb: > Hallo lpb, > > ich bin fasziniert von dem sauber fortlaufenden Zähler. Ich sehe in > meinen Logs auch aufsteigende Zahlen, aber bei mir sind da im > Allgemeinen große Lücken. Mit welcher Software erzielst Du dieses > Ergebnis bzw. wie genau fragst Du den WR ab? Vielen Dank für die Blumen, aber ohne die vielen Hinweise und Diskussionen hier hätte ich das sicher nicht hinbekommen. Im wesentlichen nutze ich das hier geteilte nrf24_sendrcv. Ich habe das ganze in der Arduino IDE auf den D1 mini mit einem EPS32 portiert. Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des 'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine Nachricht(en) empfangen habe. Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal 3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte. Je nach der eingestellten 'Wartezeit' habe ich mehr oder weniger oft alle 3 Nachrichten von meinem HM600 empfangen. Empirisch ermittelt war 4ms in meinem Code ein ganz guter Wert. Ebenfalls habe ich verschiedene Rx Kanäle und Reihenfolgen probiert. Dabei habe ich einige nie gesehen und daher wieder verworfen. Falls das jemand ausprobieren möchte, ich habe das so realisiert:
1 | uint8_t rx_channels[] = {3, 23, 61, 75, 83}; |
2 | uint8_t rx_chn_num = 5; |
3 | uint8_t intvl = 4; |
4 | ...
|
5 | // NRF rx/tx handling
|
6 | if (millis() >= tickMillis) |
7 | {
|
8 | tickMillis += intvl; |
9 | // rx channel switching
|
10 | chn_id++; |
11 | if (chn_id >= rx_chn_num) |
12 | chn_id = 0; |
13 | rx_channel = rx_channels[chn_id]; |
14 | DISABLE_EINT; |
15 | radio.stopListening(); |
16 | radio.setChannel(rx_channel); |
17 | radio.startListening(); |
18 | ENABLE_EINT; |
Ziyat T. schrieb: > Hallo > wenn sich jemand interessiert im Anhang > MI1500 > DTU-pro log Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC Freq. und U_AC) konnte ich schon identifizieren, natürlich alles angenommen. Beim 01er Command (Spalte A, ich weiß nicht ob das ein Command ist) sieht es für mich so aus, als gäbe es in Spalte D noch ein Sub-Command. Wenn Spalte A auf 5A steht bedeutet das wahrscheinlich Fehler oä.
lpb schrieb: > Den größten Fortschritt für den Empfang habe ich auf Basis der Idee des > 'poor man channel hoppings' erzielt. Dabei wechsele ich nach einer > festen Zeit den Rx Kanal, wenn ich auf dem aktuellen Kanal keine > Nachricht(en) empfangen habe. > Nach jedem senden (alle 15s immer auf Kanal 40) starte ich Rx auf Kanal > 3. Aktuell warte ich 4ms, bevor ich auf den nächsten Kanal schalte. Das ist sehr interessant. Ich habe den Empfang fix auf Kanal 3 stehen und gemerkt, dass ich quasi nur Antworten bekommen habe wenn ich auf Kanal 61 sende. Ich sende jede Sekunde ein Paket, nach 6 Paketen wechsele ich zum nächsten Kanal, aktuell sind das 4 Stück (23, 40, 61 und 75). Mal beobachten wie es sich die nächsten Tage verhält. Was ich noch nicht verstehe: Sendest du deine Nachricht mit 0x80-0x84 commands und bekommst eine 0x83 Nachricht zurück? Vom HM1200 kann ich folgendes beobachten: Senden von 0x80-0x84 führt zur Antwort von 0x01-0x03, 0x81 und 0x84.
> Was ich noch nicht verstehe: denSest du deine Nachricht mit 0x80-0x84 > commands und bekommst eine 0x83 Nachricht zurück? Ich sende jedesmal die 0x80 Zeit setzen Nachricht. Ich nehme einfach an, dass darauf hin der WR seinen aktuellen Status sendet, beim HM600 dann die 0x01, 0x02, und 0x83 Nachrichten. Mit den anderen Anfragen könnte ich allerdings auch noch mal spielen, das habe ich bislang nicht gemacht. Als nächstes wollte ich noch mal die Antwort-Zeiten und die Kanäle auswerten, ob sich da eventuell ein Muster erkennen lässt, denn hin und wieder verpasse ich einzelne Antwort-Nachrichten, oder bekomme gar keine Antwort auf eine Anfrage. Leider ist es nicht so einfach zu sagen, ob das an der SW oder evtl der HF Umgebung liegt. Die Anzeige in einem Webserver ist übrigens auch sehr schick, ich sende meine Daten allerdings an emoncms auf einem Raspberry, das ist dann fast so schick wie in der Hoymiles Cloud :)
Lukas P. schrieb: > Habe mal angefangen dein Log zu analysieren, 4 Felder (U_DC, P_DC, AC > Freq. und U_AC) konnte ich schon identifizieren, natürlich alles > angenommen. Hallo Lukas Vielen Dank für deine Bemühungen! Habe auch die Daten von der V/Freq gefunden. Allerdings deine Deutung der U_DC, P_DC, AC stimmen leider nicht. Ich habe im Anhang die neue (meine) Ordnung der Daten, ganz rechts siehst du die reale Daten, bei meinen PV's ist die UDC 37-45V. Ich bin mir sicher dass die Spalte C die MPPT sind: 0xB6/0xB7 > MPPT1 ,2 ports nicht angeschlossen 0xB8/0xB9 > MPPT2 ,2 ports mit PV belegt ansonsten bin ich leider nicht weiter gekommen, muss mal pausieren ;-)
Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal gelesen zu haben. Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88. Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten: 08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch. Diese Zahl hinter der 80 scheint mir eine Einstellung für den WR zu sein, in welchem Format er senden soll. Hat jmd schon ähnliche Beobachtungen gemacht? Vllt ist es auch ein Kennzeichen der DTU, welche sie ist DTU-Prlo oder lite.
Hubi schrieb: > Ich habe mal mit dem Timepacket etwas gespielt und statt der 0B hinter > der 80 andere Zahlen eingesetzt. z.B. bei einer 03 anstatt 0B, kommen > zwar die cmds 01 und 02, nur wird dann was ganz anderes dekodiert. Die > Antwort 83 kommt garnicht mehr, aber ganz neue cmds: 04, 05, 06, 07, 88. > Und bei einen 0x11 hinter 80 kommen wieder ganz neue Antworten: > 08, 09, 8C, 0B, 0A. Die 02 - 07 kommen auch. Hallo Hubi, wo hast Du das Senden Bitte im Source geändert ? (Wo die Pakete aufgedröselt werden, weiss ich) Dann könnte ich das mal mit einem HM-400 und die nä. Tage auch mit HM-350 mal testen.
in HM_Packets::GetTimePacket die Zeile buf[10] = 0x03;
Hubi schrieb:
Spannend :-)
Mit buf[10] = 0x0B;
habe ich beim HM400 Antwort Telegramme 01 und ab und zu 82 bekommen.
Mit buf[10] = 0x03;
bekomme ich beim HM400 die Telegramme 01,02,03,04 als Antwort.
04: aber sehr sehr selten
044060000040C066663FA6CCCD412CEB85AA7F42
044060000040C066663FA6CCCD412CEB85AA366A
044060000040C066663FA6CCCD412CEB85AA366A
01: die Werte sind jetzt statisch und ändern sich nicht mehr
Alles im Allen bisher nur nix wo man DC V,A,W / AC V,A,W / Hz
wiederfinden kann über analyseWords / analyseLongs
Aber eine Interessante Entdeckung. Vielleicht löst jemand das Rätsel
noch?
@Lukas P. Der neue Commit ließ sich übersetzen und nun auch Konfigurieren. Sowohl die Auswahl einer existierenden WiFi Connection (Liste der gescannten WiFi SSIDs) als auch das Speichern des Passworts und des Device Names waren am Tablet etwas knifflig. Es gab keine Ausgabe der Konfiguration (DNS Name / IP) per Serial Monitor bzw. Redirect auf die Status Seite (/) und auch nach einem Neustart war nicht klar, ob und wie man den ESP per DNS erreichen kann, bzw. welche DHCP Adresse er vom Router bekommen hat. Meine HM-600 Adresse (sowie die anderen Parameter) wurden aber offensichtlich gesetzt, nach einem Hard Reset waren alle noch da. Aber der Device Name beim Router ESP-429DF0 blieb wie beim ersten Start vergeben, eventuell wäre es hier besser den Device Name (ESP-<MAC>) einfach anzuzeigen. Uptime lag am Ende bei 10 Minuten und die Time wurde offensichtlich vom NTP Server (o.a.) synchronisiert. Die /livedata URL ist noch nicht verlinkt und Daten vom HM-600 wurden keine empfangen, daher blieb vermutlich auch die /hoymiles Seite leer "Every 10 seconds the values are updated". Ich vermute mal daß die HM-1200 Konfiguration aus Deinem letzten Commit die HM-600 Konfiguration von Hubi überschrieben hat ? @Martin G. Ja das mit dem ModBus Protokoll hatte ich auch gesehen, aber die Codes erschienen mir zu ähnlich zu den Register Adressen. An anderer Stelle CRC16 und 0x80 scheint es ja auch diverse Gemeinsamkeiten zu geben. Laut dem Abschnitt 4.3.3 Device SN Register List scheint es auch ein Register für die Seriennummern der DTU und der WR zu geben. Ich habe daher mal die DTU Modell und Seriennummern dazu notiert. Das scheint ja in der Zukunft evtl. interessant zu werden. Eventuell könnte man auch den DTU Pro per ModBus ansprechen um die o.g. Informationen zu lesen / setzen und dabei das nRF Protokoll mit einem/mehreren nRF24L01+ im Promisuous Modus tracen. So könnten wir das Kommunikationsprotokoll der DTU Pro relativ einfach und reproduzierbar analysieren. Danke auch für die Übernahme der Verbindungsskizze in das GitHub Repo. Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für Diagramme [1] wie ditaa Diagrams through ASCII Art [2], mermaid-js [3] und WaveDrom [4] herum. Z.B. könnten wir die hoymiles-format-description.txt einfach umbenennen zu hoymiles-format-description.md. Wenn Du die Diagramme im Markdown rendern möchtest einfach mit folgendem einem ditaa Code Tag umgeben. Ein Export von Markdown zu PDF funktioniert soweit ich weiß aber nur mit dem mermaid-js Plugin. [1] Markdown Diagrams https://gist.github.com/blackcater/1701e845a963216541591106c1bb9d3b [2] ditaa Diagrams through ASCII Art https://github.com/stathissideris/ditaa [3] mermaid-js https://mermaid-js.github.io/mermaid/#/gantt [4] WaveDrom https://github.com/drom/wavedrom @Ziyat T. das weiß ich nicht sicher, laut der gestern von mir aktualisierten Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread, oder sind das mehrmals die selben (mal Prefix und mal Postfix)? [1] 1161xxxxxxxx Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" [2] xxxxxxx14456 & xxxxxxx36590 Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Eventuell sollten wir die Kürzel der Nutzer aus dem Forum dahinterschreiben, damit wir ggf. die Seriennummern besser korrigieren können ? Du kannst auch alles auf einer Seite anzeigen lassen und einfach nach 1500 suchen, da findest Du dann Thomas B. und Arnaldo G. und Waldemar K. Zumindest Arnaldo hat auch fünf MI1500. M.E. ist die Bezeichnung MI / HM austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter) für den Typ Wechselrichter. Ich glaube auf meinem Typenschild / Aufkleber am Karton stehen auch beide Bezeichnungen.
isnoAhoy schrieb: > > @Ziyat T. > das weiß ich nicht sicher, laut der gestern von mir aktualisierten > Hoymiles Seriennummer Liste im Anhang sind drei HM-1500 hier im Thread, Hallo isnoAhoy Danke für die WR-Liste Ich bin mir ziemlich sicher dass die MI series HW/SW-maessig nicht gleich sind, HM 3.gen./MI 2.gen. MI series: - untere Limitierung 10%, WR nur als ganzer limitierbar. - mehrere DTU-ModbusRegister funktionieren nicht, da wahrscheinlich nicht im WR vorhanden HM series: - untere Limitierung bis 2%, auch port based limitierbar. - alle Modbus DTU-ModbusRegister funktionieren Ich bekomme von meinem MI1500 ganz andere antworten (bisher nur, wenn ich die DTU-Pro einschalte), bisher konnte ich den MI auch nicht direkt ansprechen. Da ich meiene DTU-Pro über Modbus-RTU selber ansteuere, könnte ich den WR gezielt ansteueren, ich waere bereit sie zu sniffen aber brauche HW-maessig hilfe wie ich es machen soll.
Hallo Ich habe versucht 2 Tage lang meinen MI1500 zu wecken. Ich verwende Hubi's SW auf ESP, habe alle MSGid & CMD Kombination durchgespilet, keine Antwort. Send... CH40 [15]6370716072228412[81]50 hier 0x15 und 0x81 [0x0-0xFF]6370716072228412[0x0-0xFF]50 Kombinationen (NRF24 funktioniert, ich sehe WR-Antworten wenn die DTU einschalte) Hat jemand nen Vorschlag? Danke
Ist das die letzte Version mit der Routine Serial2RadioID? Seriennummer auch richtig eingetragen, also Seriennummer zb 114172607952 dann
1 | #define SerialWR 0x114172607952ULL
|
2 | uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); |
in der Settings.h
Hubi schrieb: > Ist das die letzte Version mit der Routine Serial2RadioID? > Seriennummer auch richtig eingetragen, also > Seriennummer zb 114172607952 dann >
1 | > #define SerialWR 0x114172607952ULL |
2 | > uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); |
3 | >
|
> in der Settings.h
Ja, genau
#define SerialWR 0x106163707160ULL //
uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); //
//#define DTU_RADIO_ID ((uint64_t)0x1234567801ULL)
//10F8---72228412 12842272
#define DTU_RADIO_ID ((uint64_t)0x1284227201ULL)
Hi isnoAhoy, Du schriebst im Beitrag #7042229: > M.E. ist die Bezeichnung MI / HM > austauschbar HM steht für Hoymiles (Hersteller) und MI (Microinverter) > für den Typ Wechselrichter. Auf der Seite https://www.hoymiles.com/de-eu/microinverter-single-phase ziemlich in der Mitte wird zwischen beiden Modellreihen unterschieden: "MI-Mikro-Wechselrichter Unsere MI-Mikro-Wechselrichter sind die kompaktesten Modelle in unserem Sortiment und ideal für jede Anlage." vs. "HM-Mikro-Wechselrichter Mit einem Gerät der HM-Serie erhalten Sie Blindleistungsregelung und eine bessere Datenverbindung dank einer externen Antenne." - Ich lese hier schon eine Weile sehr erfreut mit und werde meinen heute gelieferten HM-1500 gerne auch sniffen und die Mitschnitte hier verfügbar machen, sobald ich die Panels bekommen und aufs Dach gebracht habe. Und sofern ich mich durchringe, den Gateway-Stick für 90€ zu kaufen - bin da noch unentschieden :-) Maik
Hallo, ist jemand da dran, die Anzahl der WR zu erweitern ? Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die Serielle (war ja im Prinzip schon fast drin, aber auskommentiert). Hab nun heute Nachschub bekommen HM-350. Dafür fliegen andere Hersteller raus, die nicht so tun, wie ich es erwartet habe. Wenn ich anfange im Code herumzuwurschteln, wird jeder "C" Programmierer die Hände über den Kopf zusammenschlagen vermute ich. Eine Idee dazu: Solange wir nicht wissen, wie man aus den S/N oder den Telegrammen auf das Modell inkl. HW Vers. / SW Vers. kommt, wären Tabellen sicher nicht schlecht: 1. Tab: Alle bisher bekannten Typen von WR., Anzahl MPPT Tracker, Anzahl DC-Inputs 2. Tab: Länder Kennungen (gibt scheinbar auch je nach Vorschriften in den Ländern verschiedene Funktionen / Verhaltensweisen. EU und Österreich für den Anfang :-) 3. Tab: Tabelle mit S/N, Modell (aus Tab 1), HW Vers., SW Vers., Land Ist nur mal so eine Idee .... Ergänzung: Eben mal einen alten WR rausgeworfen (der auch schon abgeschaltet hatte), S/N von einem 400 auf eine neue S/N vom 350 geändert. :-) Funktioniert sofort :-) P-Total = 0.0 :-) und der 350er speisst sogar noch ein. Nun kann ich ohne schlaflose Nacht träumen :-)
:
Bearbeitet durch User
Herbert K. schrieb: > ist jemand da dran, die Anzahl der WR zu erweitern ? > Ich habe Hubi s Code für mich schon auf 2 HM-400 erweitert für die > Serielle (war ja im Prinzip schon fast drin, aber auskommentiert). Ich habe da schon ein Konzept entwickelt (funzt auch für minsdestens 2 WR, auch mit Arduino, obwohl wenig Speicher) und Lukas P. will das (oder ähnlich) in seine ESP-Version auf der ahoy-Seite einbauen. Also, etwas Geduld, und das wird schon was tolles.
Hallo zusammen, als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5 anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden) und würde ihm gerne ein wenig auf die Finger gucken. Ich habe die bisherigen 3 Seiten weitestgehend durchgelesen und dabei zu verstehen versucht, über was ihr schreibt, habe dabei aber ziemliche Verständnisprobleme. Ich habe einen Raspi 3, einen alten Arduino Mega und einen ESP32 und auf allen schon ein paar Sachen in Richtung Midi + BTLE und ein wenig Anwendungsprogrammierung (Zusammenführen von Sensorsignalen und daraus rechnerisch Meta-Informationen erzeugen) gemacht. Das Jonglieren mit / Bitfieseln von irgendwelchen sonstigen Protokollen / ModBus ist mir allerdings noch unbekannt/fremd. Mit den Voraussetzungen: Wo kann ich mich einigermaßen linear in die aktuelle Problematik einlesen? Wie kann ich euch ggf. z.B. durch Datensammeln unterstützen? Viele Grüße aus Aachen, Petra
Petra-Kathi schrieb: > Wo kann ich mich einigermaßen linear in die aktuelle Problematik einlesen? > Wie kann ich euch ggf. z.B. durch Datensammeln unterstützen? https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md und https://github.com/Yveaux/NRF24_Sniffer Sind für mich die Einstiege. Ein nRF24 Modul (5€) ist auf eBay bestellt, ein mini-DUT für 88€ auch. HTH, Maik
@Lukas P.(lumapu) @Hubi Hallo Ich habe heute die https://github.com/grindylow/ahoy/tree/main/tools/esp8266 geladen und laufen lassen. Ich finde die SW sauber! Mit Hubi's SW konnte ich, wenn ich die DTUpro einschaltete, die DTUpro msg's 00/01 empfangen.(siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") Mit der ahoy SW kann ich nichts empfangen, fand ich merkwürdig. Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte ich: mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE); Serial.println("sent packet: #" + String(mSendCnt)); dumpBuf(mSendBuf, size); DTU und WR Adressen sind richtig: CH: 23 sent packet: #15 1563707160722284128352 CH: 23 sent packet: #16 1563707160722284128253 CH: 23 sent packet: #17 1563707160722284128455 CH: 23 sent packet: #18 15637071607222841280b06263d9e6000500002ad398 CH: 40 sent packet: #19 1563707160722284128150
Hallo Maik, danke für deine Einstiegshilfe! > https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Hierüber bin ich noch auf die Langstory https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt gestoßen und habe mir diese erst mal durchgelesen. Was ich daraus und aus deinem zitierten > https://github.com/Yveaux/NRF24_Sniffer noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den Beiden dieses Sniffer-Modul ebenfalls noch erforderlich? Tschüssi, Petra
Petra-Kathi schrieb: > noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features > des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den > Beiden dieses Sniffer-Modul ebenfalls noch erforderlich? ja; DU BENÖTIGST EINEN NRF
SUNPOWER schrieb: > Petra-Kathi schrieb: >> noch nicht verstanden habe: Würde eine ESP32 bzw. ein Raspi die Features >> des NRF24-Sniffers schon von Hause aus mitbringen? Oder wäre bei den >> Beiden dieses Sniffer-Modul ebenfalls noch erforderlich? > > ja; DU BENÖTIGST EINEN NRF Wichtig: einen mit “Plus” (nRF24L01+)
@Lukas P. (lumapu) Danke für die neuen Versionen auf Deinem github repo ich habe sowohl die von Dir mit HM-1200 als auch die von in grindylow gemergte Version versucht. Ich bekomme leider keine Antworten mehr vom HM-600. Was/wo sollte ich untersuchen. Wie gesagt mit Hubis Version vom 13.4. hat es funktioniert ? @Mail & @Ziyat, ja da habt ihr wohl Recht. Ob sich noch mehr geändert hat von 2.Generation MI zu 3.Gen HM müsste man evtl durch Fotos anhand der FCCID oder eigenes Begutachten des Mainboards in Erfahrung bringen. Eventuell gibt es ja auch eine Verbesserung von nRF24L01 zu nRF24L01+ o.a. was eine andere Datenrate erfordern würde ? Ich hatte auch schon vermutet dass die DTU pro evtl. einen nRF51/2 MCU verbaut hat da sich damit scheinbar mehr Wechselrichter abfragen lassen. @Ziyat willst Du Deine mal aufschrauben und uns Bilder schicken ?
@IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat mir hier sehr guten Input gegeben, wir versuchen das ganze so Leichtgewichtig wie möglich aufzusetzen. Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie ist eine gute Basis für sowas. Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und dynamisch ist, dass sie auch auf z.B. einem proMini läuft und gleichzeitig mehrere Wechselrichter unterstützt.
Angehängte Dateien:
-
220422_hm1200_5x.jpg
81 KB
Ziyat T. schrieb: > Auskommentiert sind die folg. Zeilen, damit sollte ich was sehen, dachte > ich: > mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE); > Serial.println("sent packet: #" + String(mSendCnt)); > dumpBuf(mSendBuf, size); Damit solltest du nur die gesendeten Pakete sehen, die empfangenen kannst du in dieser Zeile anzeigen lassen: https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97 Petra-Kathi schrieb: > als Neu-Besitzerin eines HM-1500 (mit potenziell bis zu 5 > anzuschließenden Modulen; ja: zwei sollen parallel angeschlossen werden) Ich habe vor mehr als 4 Module an meinem HM1200 zu betreiben, testweise habe ich immer mal wieder 5 dran. Zwei sind parallel mit Dioden an einem Anschluss, der Screenshot spricht für sich. (Channel 3)
@Lukas P. > schrieb: > Damit solltest du nur die gesendeten Pakete sehen, die empfangenen > kannst du in dieser Zeile anzeigen lassen: > https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/app.cpp#L97 > Ich habe die Version ohne MQTT vor 4 Tagen, ich denke, ich habe die richtige Zeile auskommentiert: void app::loop(void) { Main::loop(); if(!mBufCtrl->empty()) { uint8_t len, rptCnt; NRF24_packet_t *p = mBufCtrl->getBack(); //toe mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE); //toe Ich werde mal die Innereien der DTU-Pro mal anschauen.
Peter L. schrieb: > Wichtig: einen mit “Plus” (nRF24L01+) Danke für den Hinweis. Dingens ist bereits bestellt. Tschüssi, Petra
Hallo Lukas P.
danke für die Bestätigung, daß es aktuell noch nicht mit dem HM-600
geht.
Ich hatte das schon vermutet, da es bisher nur eine hm1200Decode.h gibt.
Die Punkte bzgl. der Software hatte ich auch eher als ein Review
verstanden,
falls Du / andere das irgendwie noch aufhübschen wollt.
Bzgl. Speicherverbrauch und "leichtgewichtig" ist mir aufgefallen,
daß die html/h/*.h Dateien zwar in einer Zeile untergebracht sind,
aber immer noch sehr viele Leerzeichen für die Einrückungen enthalten.
Evtl. könnte man das mit FileConv.exe oder sed unter Linux noch etwas
anders gestalten ?
Ich nehme an da die {VARIABLE} Ausdrücke ersetzt werden sollen,
kann man die HTML Seiten auch nicht im Flash Memory des ESP speichern ?
Hallo isnoAhoy, ja ich fände es super das ganze noch aufzuhübschen. Das ist das erste Mal, dass ich was in dieser Richtung veröffentlich habe - ich habe diesen ESP (app und main Klasse) schon in diversen Projekten verwendet und es hat sich immer gezeigt, dass man es schnell für ein neues Projekt verwenden kann. Bisher habe ich mich geweigert Tasmota irgendwo zu installieren - ich mach das selbst ;-), z.B für den Sonoff-POW-R2 und RGB-LED Streifen Das Fileconv.exe habe ich mir aus der Not gebaut und es kürzt der einfachheit halber alle Whitespaces auf ein Space ein. Ich habe mich nicht näher mit der Thematik auseinandergesetzt und bin hier offen für Input. Schön ist halt aktuell nur ein Binary zu haben und es ist alles drin. Die geschweiften Klammern sind die Bereiche, die ich im Code dann ersetze, richtig z.B.
1 | html.replace("{VERSION}", mVersion);
|
Lukas P. schrieb: > @IsnoAhoy: Ich bin noch am bauen einer neuen Version, die in meinem Git > geht nur mit HM1200, ändert sich aber mit der nächsten Version. Hubi hat > mir hier sehr guten Input gegeben, wir versuchen das ganze so > Leichtgewichtig wie möglich aufzusetzen. > > Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die > alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie > ist eine gute Basis für sowas. > > Ziel sollte es für die nahe Zukunft aus meiner Sicht sein, dass wir eine > C++ Library für alle Wechselrichter erzeugen, die so Leichtgewichtig und > dynamisch ist, dass sie auch auf z.B. einem proMini läuft und > gleichzeitig mehrere Wechselrichter unterstützt. Deinen Code teste ich gleich morgen, wenn es wieder hell ist... Da ist ein Fehlerchen: https://github.com/lumapu/ahoy/blob/58d79beb8c00c5f4c460bd7356d29751208ee861/tools/esp8266/mqtt.h#L54
Peter L. schrieb: > Da ist ein Fehlerchen: ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke
Hallo Lukas P., Prinzipiell ist es bei ESP8266 und ESP32 vorteilhaft größere Strings im PROGMEM [2] (bis zu 4 MB Flash Memory) abzulegen. Das ist zwar nicht ganz so schnell und flexibel wie das normale RAM / ROM aber dafür gibt es eben viel Platz. Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:
1 | static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"
|
Ich habe mal nachgesehen, hier ist ein Beispiel von Sebastian Glahn wie man string.replace() und FPSTR() für das WebServer Modul verwenden kann [2].
1 | String body = FPSTR(HTTP_BODY); |
2 | body.replace("{{variable}}", configuration.variable);
|
3 | page += body; |
[1] https://arduino-esp8266.readthedocs.io/en/latest/PROGMEM.html [2] https://blog.tldnr.org/2017/10/25/how-to-deliver-larger-web-pages-with-an-esp8266/
isnoAhoy schrieb: > Ich spiele aktuell ein wenig mit Markdown und Erweiterungen für > Diagramme [1] wie ditaa Diagrams through ASCII Art [2], mermaid-js [3] > und WaveDrom [4] herum. > Z.B. könnten wir die hoymiles-format-description.txt einfach umbenennen > zu hoymiles-format-description.md. Danke für Deine Arbeit. Die Nachfragen nach einem "zusammenhängenden" Dokument häufen sich ja (macht auch Sinn). Ich frage mich, ob wir so etwas vielleicht mit Hilfe von readthedocs.io aufbauen können?
Lukas P. schrieb: > Peter L. schrieb: >> Da ist ein Fehlerchen: > > ertappt, MQTT nie mit Benutzer und Passwort getestet =), danke Sowas kommt vor, kenne ich aus eigener Erfahrung ;-) Nach Korrektur funktioniert es mit meinem MQTT-Broker perfekt! Auch die Daten des HM-1200 mit nur drei Panels sehen gut aus; vielen Dank für die gute Arbeit!
Ich habe meine NRF-Module nun erhalten. Ich habe mich die ganze Zeit gewundert, warum [[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen Empfang brachte, mit Hubis Code jedoch alles funktioniert. Verkabelung ist nach diesem Schema: [[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]] Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen:
1 | //-------------------------------------
|
2 | // PINOUT
|
3 | //-------------------------------------
|
4 | #define RF24_IRQ_PIN (D3)
|
5 | #define RF24_CE_PIN (D4)
|
6 | #define RF24_CS_PIN (D8)
|
Ist das so gewollt (GIT Verkabelung vs. Code)? Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten (also keine AC Spannung/Energie/Frequenz) Das ist die Statistik nach einigen Minuten:
1 | CMDs:
|
2 | 0x01: 18 |
3 | 0x02: 0 |
4 | 0x03: 0 |
5 | 0x81: 55 |
6 | 0x84: 0 |
7 | other: 13 |
8 | |
9 | CHANNELs: |
10 | 23: 0 |
11 | 40: 9 |
12 | 61: 44 |
13 | 75: 33 |
@Herbert K. Welche Erweiterungen hast Du für den 400er denn vorgenommen?
Lukas P. schrieb: > Zu deinem fürheren Beitrag: Die Firmware ist noch kein "Tasmota", die > alles abdeckt (Autoredirect, Suche nach WLANs, etc.) aber ich denke sie > ist eine gute Basis für sowas. Eine Integration in Tasmota wäre super - würde mich auch daran mit einem POC versuchen, sobald ich einen halbwegs lauffähigen Code mit meinem HM-400 hinbekomme.
Marcus schrieb: > Des Weiteren empfange ich mit meinem HM-400 keinerlei 02-er Nachrichten > (also keine AC Spannung/Energie/Frequenz) > Das ist die Statistik nach einigen Minuten: >
1 | CMDs:
|
2 | > 0x01: 18 |
3 | > 0x02: 0 |
4 | > 0x03: 0 |
5 | > 0x81: 55 |
6 | > 0x84: 0 |
7 | > other: 13 |
8 | >
|
9 | > CHANNELs: |
10 | > 23: 0 |
11 | > 40: 9 |
12 | > 61: 44 |
13 | > 75: 33 |
> @Herbert K. > Welche Erweiterungen hast Du für den 400er denn vorgenommen? Ich bekomme nur "01", "81" (keine Ahnung wozu die gut sind) und ab und zu - sehr selten - "82" Antworten für 350/400 die sinnig sind nach den bisherigen Analysen. 02,03,04,84 hab ich nicht mit Hubis Vorarbeit (alter Code). In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur und Unbekanntes
Marcus schrieb: > Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen: > [c]//------------------------------------- > // PINOUT > //------------------------------------- > #define RF24_IRQ_PIN (D3) > #define RF24_CE_PIN (D4) Habe auch erst heute gemerkt ;-)
Hallo Leute, Ich verfolge die Entwicklung der selbstbau DTU schon eine Weile. Großes Lob an die Macher der Software. Nun wollte ich auch mal meine beiden Wechselrichter belauschen. Die Software ist auf dem ESP das Webinterface läuft aber leider bekomme ich keine Verbindung zum Funkmodul. Ich denke es liegt wie oben beschreiben an den falschen Pins in der Firmware. Wenn ich die Pins in der defines.h ändere kann ich die Firmware nicht mehr auf den ESP laden da es Fehlermeldungen gibt. Ist es möglich das jemand eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP gebügelt werden muss? Vielen Dank
Herbert K. schrieb: > In "82" steckt bei mir die Frequenz, AC-Leistung, AC-Strom, Temperatur Aha, dann werde ich mir das mal ansehen - kannst Du Deine "Entschlüsselung" hier mitteilen? Unter [[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]] ist es noch nicht zu finden. Ergänzend folgende Erfahrungen mit dem HM-400 und diesen Modulen [[https://www.amazon.de/dp/B06XJN417D]]: Noch mal etwas Statistik (ESP8266-Code)
1 | CMDs:
|
2 | 0x01: 490 |
3 | 0x02: 0 |
4 | 0x03: 0 |
5 | 0x81: 0 |
6 | 0x84: 0 |
7 | other: 227 |
8 | |
9 | CHANNELs: |
10 | 23: 2 |
11 | 40: 494 |
12 | 61: 186 |
13 | 75: 3 |
Zur Reichweite - das Modul ist hier ca. 30-40m über 2 Wände zum WR entfernt. Also ich finde das sehr gut. Was mich noch interessieren würde - es gibt ja immer diese P1 und P2 Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen dann nicht 2 bei einem HM-1200? Und warum habe ich bei meinem HM-400 (1 Panel) einen Wert bei P2 von 0 bei der DC-Spannung, aber unplausible Werte bei Strom und Leistung? Die Werte bei P1 sind plausibel.
Hallo Marcus, > Ich habe mich die ganze Zeit gewundert, warum > [[https://github.com/grindylow/ahoy/tree/main/tools/esp8266]] keinen > Empfang brachte, mit Hubis Code jedoch alles funktioniert. > Verkabelung ist nach diesem Schema: > [[https://github.com/grindylow/ahoy/blob/main/doc/AhoyMiles_bb.png]] > Für den ESP8266-Code im GIT muss man das PINOUT in defines.h anpassen: > //------------------------------------- > // PINOUT > //------------------------------------- > #define RF24_IRQ_PIN (D3) > #define RF24_CE_PIN (D4) > #define RF24_CS_PIN (D8) > Ist das so gewollt (GIT Verkabelung vs. Code)? Danke für das Auffinden des Fehlers, ich habe mich ja auch schon gewundert. Die Diagramme hatte ich für Hubis Source Code gemacht und Lukas hatte derweil den Source Code mit den WebSeiten angepaßt und hochgeladen. Auf die Idee die RF Pins zu überprüfen bin ich leider nicht gekommen. Ach ja die aktuelle github Version scheint nur HM1200 zu unterstützen. Der Decoder für HM600 und HM400 etc. scheint noch zu fehlen. @Lukas P., wollen wir die Anpassung im Code machen oder soll ich neue Diagramme generieren ?
Hallo, ich werde die Pins konfigurierbar machen und den default im Source auf die Diagramme anpassen. Dann muss man im besten Fall keine Änderungen am Code machen. Mein Code passt aktuell zu meiner Hardware. Den HM600 unterstützt meine Firmware schon fast, ich habe es in einen dev Branch auf meinem github Account und werde es sobald ich es für gut befinde ins Hauptrepository mergen. Gefühlt bin ich fast schon soweit. Marcus schrieb: > Was mich noch interessieren würde - es gibt ja immer diese P1 und P2 > Angaben - sind das die möglichen angeschlossenen Solarpanels? Fehlen > dann nicht 2 bei einem HM-1200? Wir haben das alles selbst ermittelt, du kannst gerne Änderungen vorschlagen bzw. diese ermitteln. Im jeweiligen Code gibt es eigentlich immer eine Möglichkteit sich die Rohen Daten ausgeben zu lassen. Mich@ schrieb: > Ist es möglich das jemand > eine funktionierenden Firmwaredump hochlädt der einfach nur auf den ESP > gebügelt werden muss? könnte man doch in Github über Releases machen, allerdings denke ich, dass wir noch viel zu früh im Projekt stehen um es Release zu nennen. Marcus schrieb: > würde mich auch daran mit einem > POC versuchen was ist ein POC?
Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern das es für esp8266 und esp32 geht. > Marcus schrieb: >> würde mich auch daran mit einem >> POC versuchen > > was ist ein POC? Proof of concept Marcel
Marcel A. schrieb: > Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern > das es für esp8266 und esp32 geht. finde ich super! Verwende am besten als Basis meinen aktuellen Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen veröffentlichten neuen Stand in main-Branch.
Hallo zusammen, ich finde das ein super interessantes Projekt. Eine Frage wird der HM-700 auch unterstützt werden?
Zur Auswertung/Datenanalyse: Ich habe mich nochmal durch den Thread gewühlt und folgende Theorie für meinen HM-400 und damit wohl "Single"-Wechselrichter - das kann ich an einen HM-300, wenn ich vor Ort bin, mal prüfen. Single-WR senden keine 02er (cmd / Byte 9) Nachrichten, diese senden vermutlich nur WR mit >= 2 Panels. Bei WR mit nur einem Panel stecken die (bisher erkannten) Daten in folgenden Nachrichten-Bytes (vieles IMHO schon bekannt, aber es hier jedenfalls "verlorengegangen": [[https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt]]).
1 | cmd 01 => |
2 | 12/13: DC-Spannung, Divisor 10 |
3 | 14/15: DC-Strom, Divisor 100 |
4 | 16/17: DC-Leistung, Divisor 10 |
5 | 18/19: unbekannt, bei mir immer 0 |
6 | hier ist IMHO bei WR mit >= 2 Panels die DC-Spannung des 2. Panels enthalten |
7 | 20/21: Gesamtleistung kWh, Divisor 1000 - (mir) unklar ob DC/AR Wert |
8 | hier ist IMHO bei WR mit >= 2 Panels der DC-Strom des 2. Panels enthalten |
9 | 22/23: tägliche Leistung Wh, Divisor 1? - (mir) unklar ob DC/AC Wert |
10 | hier ist IMHO bei WR mit >= 2 Panels die DC-Leistung des 2. Panels enthalten |
11 | 24/25: Spannung, Divisor 100 |
12 | |
13 | cmd 82 => |
14 | 10/11: Frequenz, Divisor 10 |
15 | 20/21: Temperatur, Divisor 10 |
Einen GIT-Account habe ich. Könnte o.g. Format-Beschreibung ergänzen. Diese müsste nach meiner Vermutung dann aber nach WR-Bauart (Anzahl Panels) unterscheiden. Für einen HM-400 sind somit erstmal die wesentlichsten Daten bekannt. Das mit den Leistungswerten (Gesamt/Tag) will ich selbst noch mal bei mir verifizieren.
Hallo Markus, ich fände es auch gut, das Wissen wo Zentral zu sammeln. Zum Thema HM-400/350 habe ich am 9.4 gepostet: (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") Hier meine Erkenntnis zum HM350 (hatte auf zu wenige Bytes geschaut) 01: 2bytes unbekannt "1" 2bytes dc_volt / 10 2bytes dc_amps / 100 2bytes dc_power / 10 4bytes Total_w 2bytes Daily_w 2bytes ac_volt / 10 82: 2bytes ac_freq / 100 2bytes ac_power / 10 2byte unbekannt "0" 2bytes ac_current / 100 2byte unbekannt "1000" vielleicht /10 Power Factor in %? 2bytes temp / 10 2bytes unbekannt ansteigend 2bytes random Die Total Werte scheinen immer 4byte Werte zu sein. Das muss wohl bei HM-600/700 auch so sein .... allerdings geht sich das dort nicht so einfach aus
Lukas P. schrieb: > Marcel A. schrieb: >> Ich werde die Tage mal probieren den esp8266 sourcecode so zu verändern >> das es für esp8266 und esp32 geht. > > finde ich super! Verwende am besten als Basis meinen aktuellen > Dev-Branch (Version >= 0.2.3) oder meinen hoffentlich in wenigen Tagen > veröffentlichten neuen Stand in main-Branch. Ich hatte mir bisher nur das Repo https://github.com/grindylow/ahoy angeschaut und da gibt es keinen Dev Branch. Welchen Code meinst du ?
Da ich nicht der Eigentümer des Hauptrepositories bin habe ich einen Fork in meinem Account. Ich verlinke es nicht, da das Hauptrepository die Referenz für alles bleiben soll. Suche einfach nach dem Fork (auf der rechten Seite unter "About") von "lumapu" und dort im "dev" Branch.
Martin P. schrieb: > ich fände es auch gut, das Wissen wo Zentral zu sammeln. Habe das ergänzt und einen Pullrequest (PR) im git ausgelöst. Zu:
1 | 4bytes Total_w |
2 | 2bytes Daily_w |
1. ist das eigentlich die Leistung DC oder AC? 2. Total_w sind doch auch nur 2 Bytes, oder? Siehe hier (PR) unter cmd 01: [[https://github.com/grindylow/ahoy/pull/7/commits/dfa7975fedaa3993bd3655aa52bdaa83614dbac4]]
Marcus schrieb: > 1. ist das eigentlich die Leistung DC oder AC? Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher, dass es DC ist: der HM400 hat daily/total nur einmal .... der 2-port HM600 hat diese Werte je 2x (wie die DC Daten) > 2. Total_w sind doch auch nur 2 Bytes, oder? Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter oben hat es Herbert K. schon gezeigt, dass es so ist.
Martin P. schrieb: >Ich denke das ist noch nicht 100% geklärt. Persönlich glaube ich eher, >dass es DC ist: Wenn es aber die Leistungswerte für DC sind - gibt es die Gesamtwerte für AC gar nicht? Pro Panel mag das ja interessant sein, aber die Summe ist eben m.E. nur näherungsweise gleich der Summe AC seitig (beim Wandeln entstehen ja auch noch "Verluste") - oder wird das ggf. mit einem Faktor abgebildet, der weniger Bytes benötigt, als nochmal 2+4 Bytes für AC zu benötigen (Spekulation). Die momentane Leistung für AC ist ja inzw. bekannt - fehlt irgendwie Ptotal und Pdaily für AC. > Ich verstehe nicht ganz, was du meinst? Total_W muss 4 bytes sein, weil > die 64 kWh sind ja doch nach ein paar Wochen erreicht ... und weiter > oben hat es Herbert K. schon gezeigt, dass es so ist. Ahhh - das hatte ich übersehen - hab mich schon immer über die ständigen Nuller gewundert in den vorderen 2 Bytes - ich bin noch nicht über 65535 Wh ;-). Muss das in meiner Beschreibung noch korrigieren. Für den HM-400 habe ich jetzt alles sauber aufgeschrieben und versuche es in das GIT einzuchecken.
Hallo zusammen, es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist die 0.2.4 Sie bassiert auf dem Konzept von Hubi, Vielen Dank nochmal. Wir haben weitere Ideen, die dann in die nächste Version einfließen werden. Das sollte möglich sein: - mehrere Wechselrichter, aktuell sind per define 3 voreingestellt - verschiedene Wechselrichter, aktuell ist zwischen HM600 und HM1200 die Wahl - Pinout kann konfiguriert werden, voreingestellt ist das des Wemos D1mini - die Konvertierung der HMTL Seiten passiert jetzt mit python und sie werden im PROGMEM abgelegt - der code wurde soweit verändert, dass prinzipiell auch eine 'einfache' Portierung auf den proMini (328p) denkbar ist - ein MQTT client wurde eingebaut um die Werte woanders zu visualisieren (z.B. ioBroker) Über Feedback und Tests würde ich mich freuen, viel Spaß mit der neuen Firmware! Im Anhang habe ich mal meinen Build gehängt, damit man auch ohne Kompilieren auf die neue Version updaten kann - mal sehen ob das klappt.
Hallo Lukas,
Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur
den unten gezeigten Output
Der D1- Mini lief schon mal mit einem viel weiter oben im Thread
gezeigten Programm
Ich habe ihn zum Test auch mal mit einem blank-File geflasht - leider
auch erfolglos
Viele Grüße
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00057330
~ld
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Soft WDT reset
>>>stack>>>
ctx: cont
sp: 3ffffb40 end: 3fffffc0 offset: 01a0
3ffffce0: 00000000 3ffe901c 3ffeeff0 40204b01
3ffffcf0: 00000000 00000000 00000000 00000000
3ffffd00: 00000000 00000000 00000000 00000000
3ffffd10: 00000000 00000000 00000000 00000000
3ffffd20: 00000000 00000000 00000000 00000000
3ffffd30: 00000000 00000000 00000000 00000000
3ffffd40: 00000000 00000000 00000000 00000000
3ffffd50: 00000000 00000000 00000000 00000000
3ffffd60: 00000000 00000000 00000000 00000000
3ffffd70: 00000000 00000000 00000000 00000000
3ffffd80: 00000000 00000000 00000000 00000000
3ffffd90: 00000000 00000000 00000000 00000000
3ffffda0: 00000000 00000000 00000000 00000000
3ffffdb0: 00000000 00000000 00000000 00000000
3ffffdc0: 00000000 00000000 00000000 00000000
3ffffdd0: 00000000 00000000 00000000 00000000
3ffffde0: 00000000 00000000 00000000 00000000
3ffffdf0: 00000000 00000000 00000000 00000000
3ffffe00: 00000000 00000000 00000000 00000000
3ffffe10: 00000000 00000000 00000000 00000000
3ffffe20: 00000000 00000000 00000000 00000000
3ffffe30: 00000000 00000000 3ffe0000 40212768
3ffffe40: 00000000 3ffe901c 3ffeeff0 402080cb
3ffffe50: 3fff0f84 feefeffe 402045cc 40212848
3ffffe60: 40207694 00000000 3ffeeff0 00000000
3ffffe70: 40206f9c 00000000 3ffeeff0 feefeffe
3ffffe80: feefeffe feefeffe feefeffe feefeffe
3ffffe90: 3fff0054 3fff0054 0000000f feefeffe
3ffffea0: feefeffe feefeffe feefeffe 3ffef324
3ffffeb0: 3ffeeff0 00000000 3ffeeff0 402033ba
3ffffec0: feefeffe feefeffe feefeffe feefeffe
3ffffed0: feefeffe feefeffe feefeffe feefeffe
3ffffee0: feefeffe feefeffe feefeffe feefeffe
3ffffef0: feefeffe feefeffe feefeffe feefeffe
3fffff00: feefeffe feefeffe feefeffe feefeffe
3fffff10: feefeffe feefeffe feefeffe feefeffe
3fffff20: feefeffe feefeffe feefeffe feefeffe
3fffff30: feefeffe feefeffe feefeffe feefeffe
3fffff40: feefeffe feefeffe feefeffe feefeffe
3fffff50: feefeffe feefeffe feefeffe feefeffe
3fffff60: feefeffe feefeffe feefeffe feefeffe
3fffff70: feefeffe feefeffe feefeffe feefeffe
3fffff80: feefeffe feefeffe feefeffe 3ffef324
3fffff90: 3fffdad0 00000000 3ffeeff0 4020458b
3fffffa0: feefeffe feefeffe 3ffef310 4021038c
3fffffb0: feefeffe feefeffe 3ffe85d8 40100e65
<<<stack<<<
Lukas P. schrieb: > es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist > die 0.2.4 Würde ich gerne auch testen, habe aber nur einen HM-400. Da ich heute eh im Thema stecke, hier die Tabelle aller bisher bekannten Werte um den 400er ggf. leicht zu ergänzen:
1 | //-------------------------------------
|
2 | // HM400 (vermutlich auch HM-350 und HM-300)
|
3 | //-------------------------------------
|
4 | const byteAssign_t hm400assignment[] = { |
5 | { FLD_UDC, UNIT_V, CH1, CMD01, 14, 2, 10 }, |
6 | { FLD_IDC, UNIT_A, CH1, CMD01, 16, 2, 100 }, |
7 | { FLD_PDC, UNIT_W, CH1, CMD01, 18, 2, 10 }, |
8 | { FLD_YT, UNIT_KWH,CH2, CMD01, 20, 4, 1000 }, |
9 | { FLD_YD, UNIT_KWH,CH2, CMD01, 24, 2, 1000 }, |
10 | { FLD_UAC, UNIT_V, CH0, CMD01, 26, 2, 10 }, |
11 | { FLD_F, UNIT_HZ, CH0, CMD82, 12, 2, 100 }, |
12 | { FLD_PAC, UNIT_W, CH0, CMD82, 14, 2, 10 }, |
13 | { FLD_IAC, UNIT_A, CH0, CMD82, 18, 2, 100 }, |
14 | { FLD_T, UNIT_C, CH0, CMD82, 22, 2, 10 } |
15 | };
|
Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf Deine komme. Beispielnachricht:
1 | 95 7310xxyy 7310xxyy 010001 0198 004001060000FA7B00190922F8C75E 1 |
Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0 anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC Spannung des 1. Moduls. Ggf. muss das noch angepasst werden.
Angehängte Dateien:
-
MI1500data.png
140 KB
Lukas P. schrieb: > Hallo zusammen, > > es ist soweit, ich habe eine neue Firmware veröffentlicht. Version ist > die 0.2.4 Danke für die Arbeit! Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird? (WR Library?) Wollte drauf hinweisen, dass das MI-Series Datenformat völlig verschieden ist (CMD,MID,Ports etc.) Bisherige Erkentnisse vom MI1500, siehe Anhang
Marcus schrieb: > Unklar ist mir, was Du mit CHx meinst (noch anzupassen) und von wo Du > aus zählst. Ich habe meine Zählweise um 2 Byte erhöht, damit ich auf > Deine komme. > Beispielnachricht:95 7310xxyy 7310xxyy 010001 0198 > 004001060000FA7B00190922F8C75E 1 > Hier startet der erste (bekannte) Wert am Byte 12 (0198) wenn man mit 0 > anfängt mit zählen. Der ist beim HM-600/700 und auch beim HM-400 die DC > Spannung des 1. Moduls. Ggf. muss das noch angepasst werden. Deine Definition habe ich mal eingebaut und commited. Dabei habe ich noch geringfügige Änderungen gemacht. Aufgefallen ist mir, dass für den HM1200 alle Idizes ungerade sind, deine sind alle gerade. Meine Zählweise ist so: Byte 0 = cmd Byte 1 .. x Daten Ich wollte das durch diesen Kommentar (über den Definitionen) ausdrücken, evtl. muss man es umformulieren.
1 | /** |
2 | * indices are built for the buffer starting with cmd-id in first byte |
3 | * (complete payload in buffer) |
4 | * */ |
Die Kanäle habe ich wie folgt aufgebaut: CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten CH1-CH4: je nach Wechselrichter die Anschlüsse für Module
Heinz R. schrieb: > Ich habe gerade Dein bin auf einen ESP8266 geflasht - erhalte leider nur > den unten gezeigten Output Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären.
Ziyat T. schrieb: > Ich weiss nicht wie weit die SW vorbereitet ist für andere HoymilesWR > als HM Series, oder überhaupt sowas vorgesehen ist oder gewünscht wird? > (WR Library?) Klar wir sind für alles offen, wir versuchen jetzt mal das schon bekannte in einer Firmware zusammenzufassen. Wenn du Input / Ideen hast kannst du sie gerne jederzeit beitragen. Ich würde sagen: Je mehr und je vollständiger die WR unterstützt werden umso besser!
Lukas P. schrieb: > Dem Stack Trace nach (den von dir konvertiert) ist der Fehler in der > Main::getConfig() passiert - das kann ich mir bis jetzt nicht erklären. funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 flashst?
Lukas P. schrieb: Zur Zählweise - hier erkennst Du es denk ich ganz deutlich (ich warte noch auf einen PR in das offizielle Repo-Doku): [[https://github.com/dad401/ahoy/blob/main/doc/HM-400%20data.xlsx]] > Die Kanäle habe ich wie folgt aufgebaut: > CH0: alles was AC ist, und zusätzliche allgemeine Wechelrichterdaten > CH1-CH4: je nach Wechselrichter die Anschlüsse für Module Ja, ich habe es mir inzwischen so gedacht - hatte mir vorher Channels = cmd01 etc. bzw. Radio-Channels vorgestellt. Demnach hat der HM-400 CH0 (AC, Freq, Spannung, Temp) und CH1 den Rest vom Panel. Habe den 400er auch in Deinen Code eingebaut/-bastelt, kann nur wegen Dunkelheit nicht mehr testen. Kommt morgen... Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch das CMD82 (hminverters.h)?
1 | enum {CMD01 = 0x01, CMD02, CMD03, CMD83 = 0x83, CMD84}; |
Der Code ist eine gute Grundlage für Tasmota - bin da zwar eher Amateur, aber man lernt daran und einen adaptierten SDM230-Treiber (Wechselstromzähler) wurde auch als PR schon angenommen :-) - Bin gespannt ob das klappt. Einzig die Ressourcen sind da arg knapp und die Anzahl der WR sollte man da auch beschränken. Aber Web und MQTT kommt von Haus aus mit.
Hallo Lukas, Ich kann auch bestätigen das die neue Firmware nicht auf dem Wemos D1 Mini läuft. Weder das bin file (mit Tadtomizer und mit ESP-Easy flasher getestet) sowie auch die Version von Github mit Arduino IDE neu Kompiliert und geflasht. Bei beiden Varianten das gleiche Ergebnis wie Heiz bereits geschrieben hat.
Angehängte Dateien:
Ziyat T. schrieb: > > Bisherige Erkentnisse vom MI1500, siehe Anhang Ich bin der Meinung, das die Werte in der letzten Spalte das Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt (Nur in der Webansicht).
Sehr schade, worin liegt der Unterschied zwischen meinem ESP-07 und dem Wemos D1mini? Ich glaube der ESP-07 hat 1MB Flash. Ich habe bisher keinen Wemos. Marcus schrieb: > Deine Änderungen decken sich mit meinen :-) - aber fehlt hier nicht noch > das CMD82 (hminverters.h)? wird nachgereicht, du hast Recht
Hallo Lukas, ich habe mal Deinen dev branch ausgecheckt und übersetzt. Dabei habe ich folgende Änderungen für Linux hinzugefügt: tools/fileConv.sh:
1 | #!/bin/bash
|
2 | echo String $3 = \"$(cat $1 | tr '\n' ' ' | sed 's/"/\\"/g;s/\s\{4\}/\t/g')\"\; > $2 |
html/conv.sh:
1 | #!/bin/bash
|
2 | ../tools/fileConv.sh index.html h/index_html.h index_html |
3 | ../tools/fileConv.sh setup.html h/setup_html.h setup_html |
4 | ../tools/fileConv.sh hoymiles.html h/hoymiles_html.h hoymiles_html |
5 | ../tools/fileConv.sh style.css h/style_css.h style_css |
platform.txt:
1 | # add a prebuild hook to generate minified h files from html templates |
2 | recipe.hooks.prebuild.1.pattern={build.path}/html/conv.sh
|
3 | recipe.hooks.prebuild.2.pattern={build.path}\html\conv.bat
|
Wobei die prebuild hooks in der platform.txt offenbar noch nicht
greifen. Vielleicht kennt sich ja jemand damit aus, wie man das HTML/CSS
minify der templates im html Verzeichnis richtig anstoßen kann.
Auch die folgende Speicheroptimierung habe ich noch nicht in den o.g.
Generator eingebaut.
> Um einen String im PROGMEM abzulegen einfach folgende Syntax verwenden:1 | static const char xyz[] PROGMEM = "langer String mit {{variable}} Parameter"
|
2 | String body = FPSTR(HTTP_BODY); |
3 | body.replace("{{variable}}", configuration.variable);
|
4 | page += body; |
Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das halt im Dev Branch =^D Dafür sind die ganzen versprochenen Anpassungen schon da ! * WiFi mit SSID und Password * Device Name: ESP-AHOY * bis zu vier Inverter 0-3 (wahlweise HM600 / HM1200) mit Adresse im 114173123456 Format plus ein sprechender Name für jeden * Abfrage Intervall der Wechselrichter: 1000 ms * Pin Out Definition CS: D8 (GPIO15), CE: D4 (GPIO2) und IRQ: D3 (GPIO0) im Default und wählbar. * MQTT Settings mit Broker / Server IP, Username & Password, Topic (/inverter) sowie Interval (10000 seconds) Besonders gefällt mir das flexible Mapping der Bytes in den Nachrichten auf die enstprechenden Felder (DC U/I/P und AC U/I/P/Freq, etc.) der Wechselrichter in der hmInverters.h. Ich muß mir das mal genauer ansehen, ich meine es gab auch Felder die u.a. auf zwei Nachrichten 0x01 Buffer Byte 15/16 und 0x02 Buffer Byte 1/2 aufgeteilt waren ? Das habe ich gestern bei meinen Versuchen eine hm600Decode.h zusammenzubasteln nicht gebacken bekommen. Die bei meinem Hoymiles immer wieder auftretenden 0x83 Nachrichten werden aktuell unter other summiert. Evtl. wäre es da hilfreich diese Nachrichten sowie die 0x82 bei anderen WR gesondert zu zählen ?
Hallo Lukas, Der D1 Mini hat 4mb fashspeicher… Die Vorgänger Version in dem nur der HM1200 unterstützt wurde lief ohne Probleme.
isnoAhoy schrieb: > Nach dem Deployment waren zwar die WLAN Settings futsch, aber so ist das > halt im Dev Branch =^D Bin ich froh, dass es bei dir klappt. Jetzt wäre es noch toll wenn du den heutigen main Branch verwenden würdest. Damit die Wifi Settings nicht ständig weg sind, wenn man die Liste der zu speichernden Parameter erweitert, habe ich jetzt einen weiteren CRC eingeführt, der nur über die Wifi Settings geht. Dein conv.sh ist leider fast überflüssig, aber wir können es parallel ablegen. Ich habe heute auf python umgestellt, dadurch sind wir plattformunabhängig. Heinz R. schrieb: > leeren ESP8266 > flashst? Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle mich von OTA Update zu Update =) Das erinnert mit daran in der Konfiguraiton einen Erase Button einzuführen =)
:
Bearbeitet durch User
Mike schrieb: > Ziyat T. schrieb: >> >> Bisherige Erkentnisse vom MI1500, siehe Anhang > > Ich bin der Meinung, das die Werte in der letzten Spalte das > Leistungsverhältnis der Gesamtleistung (angegebenen PV-Module) und der > aktuellen Leistung ist. Denn dies wird in der S-Cloud auch angezeigt > (Nur in der Webansicht). Leider nicht, z.Bsp. Zeile 3,Spalte 2, B7(port2) ist nicht belegt, PW=0, Spalte AX 1.18, geht nicht auf Zeile 2,Spalte 2, B8(port2) ist belegt, PW=75.4, Spalte AX 0.01 geht nicht auf
Lukas P. schrieb: > Wenn du mir sagst wie ich den einfach wieder leer bekomme, ich hangle > mich von OTA Update zu Update =) > Das erinnert mit daran in der Konfiguraiton einen Erase Button > einzuführen =) Es gibt z.B. bei ESPEasy Blank-Files - habe Dir mal eines angehängt
Jetzt fällt mir noch was ein in hmRadio.h:83 ist noch immer 'RF24_PA_MAX' definiert, bei mir funktioniert es, evtl. bricht beim ersten Sendeversuch die Spannung ein. Ich habe an den 3.3V einen dicken Elco, man sieht aber trotzdem, dass die LEDs kurz dunkler werden. @Heinz Dein blank.bin sieht aus wie ein frisch gelöschter Speicher, alles 0xFF =). Vielen Dank.
Mit ESP-12e: Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis zum Löschen des EEPROMs, dann schlägt der WDT zu. Gruß... Bert
Bert 0. schrieb: > Mit ESP-12e: > Ich habe mal Debug-Ausgaben eingebaut, die main::GetConfig() kommt bis > zum Löschen des EEPROMs, dann schlägt der WDT zu. > > Gruß... Bert Super, danke für den Hinweis, die Fehler sind dann eindeutig in der eep.h und zwar in Zeile 40 und 81 Die For loops werden mit einem 8-bit zähler niemals die 16bit length zählen können -> Endlosschleifen Commit ist gleich unterwegs ;-) Kann bitte einer nochmal kurz die Sonne einschalten zum Testen? :-P
:
Bearbeitet durch User
Jop, mit dem letzten Commit startet die Applikation wieder korrekt, Fix reviewed OK! ;-) Gruß... Bert
Ich kann btw. auch bestätigen, dass die Zuordnung auch für den HM-1500 sinn macht: https://github.com/grindylow/ahoy/blob/bf8c1628973eb1dc53b2604b6a7bc1561174f004/tools/esp8266/hmInverters.h#L100 Hab die Zuordnung mit einem meiner Dumps getestet... sieht alles plausibel aus
Die neue Version läuft auf dem Wemos D1! Besten Dank.
Mich@ schrieb: > Die neue Version läuft auf dem Wemos D1! > Besten Dank. Gibt es die evtl. auch als fertig kompiliertes bin?
Ja im Anhang ist die neuste Verison - hat jetzt eine Erase Application data Option - Cmds 0x82 und 0x83 tauchen in Statistik auf
Ich springe auch mal auf den Zug auf ;-) Erstmal ***VIELEN DANK*** an alle Beteiligten!!!! Ich bin noch an den Vorbereitungen, mein HM1200 ist noch nicht geliefert, und ich habe auch noch kein NRF, daher derzeit nur beschränkte Möglichkeiten. Die aktuelle 0.2.6 läuft aber schon mal auf einem Wemos D1 mini (clone) :-) - WIFI-Connection ist ok - Webseite funktioniert - MQTT ist inkl. user/pass eingetragen wird aber als "not connected" angezeigt. Im MQTT-Sniffer sehe ich aber das Topic und den FirmwareRelease. Sonst nichts, es gibt aber ja auch noch keine Daten. Meine Fragen: - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber in (s) Stimmt das? - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein Satzzeichen, ist das ok (erlaubt)? viele Grüße Robert
Hallo, ich bin leider kein C++ Programmierer und habe jetzt einen Status erreicht, wo ich nicht weiter kann. Ich wollte den Code auf ESP32 anpassen und hab auch viele Sachen angepasst, aber jetzt verlangt es langsam bessere C Knowledge. Ich würd mich freuen, wenn jemand da helfen kann ! Ich pack mal das error rein, welches ich bekomme wenn ich kompiliere. Ich nutze auch PlatformIo und habe da die Ordner Struktur angepasst. Zu finden sind die Änderungen in dem Fork in meinem Account: https://github.com/a-marcel/ahoy Ich würde mich freuen, wenn es auch für ESP32 geht, weil der ja mehr Speicher hat es einfacher sein sollte.
Hallo Marcel, finde ich super! Mal ein paar Dinge, die offensichtlich sind. Er findet die Datei "eep.cpp" nicht und er kommt nicht mit den 'Tickern' zurecht. Evtl. benötigt er eine Library / Include dafür. Evtl. tut man sich leichter, wenn man den Code erst mal für den ESP8266 in PlatformIO kompiliert. Robert S. schrieb: > Meine Fragen: > - Für den Inverter ist das "Interval" in (ms) angegeben, für MQTT aber > in (s) > Stimmt das? > - Das MQTT Passwort hat Gross/Kleinschreibung, Zahlen und ein > Satzzeichen, > ist das ok (erlaubt)? - Inverval wird korrigiert, ist auch in ms - Das Passwort wird einfach als String (char-array) gespeichert, daher ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen begrenzt und der User auf 16 Zeichen. - der Status des MQTT Brokers war invertiert -> korrigiert
:
Bearbeitet durch User
Lukas P. schrieb: > - Inverval wird korrigiert, ist auch in ms > - Das Passwort wird einfach als String (char-array) gespeichert, daher > ist alles möglich. Aktuell sind Passwort und Topic auf 32 Zeichen > begrenzt und der User auf 16 Zeichen. > - der Status des MQTT Brokers war invertiert -> korrigiert Genial, funktioniert! Vielen Dank für den superschnellen Fix! Robert
Heinz R. schrieb: > funktioniert es bei Dir wenn Du Dein Bin-File auf einen leeren ESP8266 > flashst? Auch hier kommt der Watchdog (Wemos D1 mini). Auch ein
1 | esptool.py erase_flash |
hilft nicht.
Hallo Lukas P., danke für die vielen Commits und Fixes heute abend, nur das mit der Sonne hat nicht mehr gereicht =^D Ich schaue mir morgen bei Tag nochmal die HM-600 Werte an, da hast Du ja zuletzt noch etwas gefixt. Habe gerade nochmal die 0.2.7 geflashed, nach einem mutigen ERASE SETTINGS (not WiFi) kam auch folgender Fehler nicht mehr: 00:25:38.848 -> add inverter: oymiles A, SN: 114173123456, type: 0 00:25:38.848 -> no assignment for type found!add inverter: , SN: 480000000000, type: 3 Irgendwie hat er im EEProm wohl daneben gegriffen und das "H" des ersten WR Namens als SN für einen weiteren Wechselrichter interpretiert. Danke für die Funktion zum beibehalten der SSID und des WiFi Passworts das ist sehr praktisch und hilfreich! Auch die PA_MIN, PA_LOW, PA_HIGH, PA_MAX Einstellung funktioniert jetzt laut Debug Ausgabe: 00:29:55.769 -> add inverter: Hoymiles HM-600, SN: 114173123456, type: 0 00:29:55.802 -> RF24 Amp Pwr: RF24_PA_MAX Wie gesagt Device Name könnte noch mit ESP-<WIFIMAC> vorbelegt sein.
Hallo Heinz R., kannst Du mal zum Flashen den Serial Monitor der Arduino IDE schließen. Ich meine das ist eine häufige Fehlerquelle wenn er die Firmware übertragen will und dabei vorzeitig abbricht. Vielleicht hilft das ja auch in Deinem Fall.
Hallo Heinz R., jetzt habe ich mal den weiter oben genannten Stack Trace von Dir versucht zu analysieren. Schau Dir doch mal bitte folgende Seite an: https://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html Dort wird die Vorgehensweise bei solchen Exceptions Problemen beschrieben. Den ESP Exception Decoder habe ich nach der Anleitung ausgepackt und installiert https://github.com/me-no-dev/EspExceptionDecoder#installation Leider habe ich nicht den zugehörigen Source Code bzw. das ELF Binary um daraus Sinn zu machen bzw. Deinen alten Stack Trace zu analysieren. Mir fehlt auch der Exception Code um das Problem prinzipiell eingrenzen. Ich hatte übrigens gestern abend auch einen Stacktrace gesehen. Nach einigen Restarts geht es jetzt aber sauber, kann es also nicht einfach reproduzieren. Hast Du evtl. einige Clients die auf den ESP per WiFi zugreifen wollen oder wird viel per Serial geloggt ? I.d.R. treten solche WDT Exceptions auf, wenn der ESP seine WiFi Schnittstelle nicht parallel zum Programm bedienen/abarbeiten kann. Vielleicht kann man es ja an der richtigen Stelle mit einem yield() beheben ? Was für Einstellungen hast Du denn für Deinen ESP8266 im Tools Menü gewählt ? Eventuell liegt es ja an etwas einfachem wie der Frequenz, Debug Optionen, o.a.
Guten Morgen, ich weiß nicht, ob ich es schon genannt hatte: die Seriennumer muss jetzt genauso wie sie auf dem WR steht eingetragen werden, ohne ":". Im Anhang noch die Version 0.2.7 und im zip das .elf zum debuggen von Stack-Traces. Mit meinem HM1200 geht die Firmware bei Tageslicht =)
Guten Morgen Lukas P., also ich habe (nach wie vor) seltsame Werte für meinen zweiten Kanal am HM-600 (bisher unbelegt daher vermutlich free-floating): CHANNEL 1 230.40 V U_DC 2.27 A I_DC 804.10 W P_DC 50467.00 Wh YieldDay CHANNEL 2 1557.50 V U_DC 393.21 A I_DC 3932.10 W P_DC 10711.00 Wh YieldDay Die Yield Total und Week sowie AC Werte / Temperatur werden aktuell noch nicht angezeigt bzw. deren u.g. Werte erscheinen mir fraglich. Kann man die rohen Datenpakete wieder ausgeben lassen, das war m.W. dumpBuf o.a. ? Hier mal die Werte aus dem Serial Monitor: 08:42:04.674 -> hm600/ch1/U_DC: 230.400 V 08:42:04.674 -> hm600/ch1/I_DC: 2.300 A 08:42:04.674 -> hm600/ch1/P_DC: 190.600 W 08:42:04.674 -> hm600/ch2/U_DC: 1368.500 08:42:04.674 -> hm600/ch2/I_DC: 393.210 A 08:42:04.707 -> hm600/ch2/P_DC: 3932.100 08:42:04.707 -> hm600/ch0/YieldWeek: 1024.000 08:42:04.707 -> hm600/ch0/YieldTotal: 94.000 Wh 08:42:04.707 -> hm600/ch1/YieldDay: 32133.000 08:42:04.707 -> hm600/ch2/YieldDay: 10985.000 08:42:04.707 -> hm600/ch0/U_AC: 3932.100 08:42:04.707 -> hm600/ch0/Freq: 393.210 H 08:42:04.707 -> hm600/ch0/I_AC: 3932.100 08:42:04.707 -> hm600/ch0/Temp: 2218.900 Wenn dies eine CSV Ausgabe in einer Zeile wäre, dann könnte das der Serial Plotter in der Arduino IDE darstellen: 1U_DC1,1I_DC1,1P_DC1,1U_DC2,1I_DC2,1P_DC2,1YW,1YT,1YD1,1YD2,1U_AC,1Freq, 1I_AC,1Temp: 230.400,2.300,190.600,1368.500,393.210,3932.100,1024.000,94.000,32133.00 0,10985.000,3932.100,393.210,3932.100,2218.900 Am Besten könnte man noch die Spalten auswählen, die per Serial Monitor als "CSV" oder im bisherige "MQTT" Format ausgegeben werden =^D Die Channel Statistik in app.h/.cpp habe ich wieder aktiviert und er schickt bei mir alles auf Kanal 61. Hast Du das Channel Hopping adaptiv angepaßt, d.h. daß es erst bei Fehlern (ACK) den Kanal wechselt ?
Habe hin und wieder Exceptions gesehen, daher die 0.2.8 @isnoAhoy: das channel hopping ist aus (hmRadio.h), bringt bei mir keinen Vorteil Ich würde eher die RAW oder Payload Daten plotten lassen und das dann per Excel auswerten
Hallo Lukas P. habe die dumpBuf Aufrufe in hmRadio.h und app.cpp gefunden und wieder aktiviert. Das wäre als Debug Option im Setup sicher auch noch praktisch! Dazu musste ich die Methode in hmRadio.h vor den private: Bereich verschieben, da sie sonst nicht aus app.ccp aufgerufen werden konnte: declared private! Folgender einfacher Zusatz in dumpBuf() gibt übrigens auch HEX mit führender Null aus, dann klappt es m.E. leichter mit dem Excel Sheet zum dekodieren.
1 | if (buf[i] < 10) Serial.print("0");
|
An de NRF Spezialisten, Ich sehe diese RAWDaten vom MI1500 neben den "Regulaeren", was könnten sie sein? Kann immer noch den MI1500 nicht ansprechen, Daten bekomme ich nur, wenn die DTU-Pro eingeschaltet ist.
Hallo Ziyat
soviel ich noch von weiter oben weiß benutzt du meine SW.
Dass nur Daten kommen wenn DTU an ist bedeutet für mich, dass die DTU
wohl dem WR einen Anstoß gibt. Weiter oben habe ich auch beschrieben,
dass beim Senden des Zeit-setzen-Pakets mit einem Wert <> 0B hinter dem
0x80 ganz neue Antworten kommen. Also vllt braucht dein MI1500 kein 0B
sondern was anderes.
Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert
buf[10] von 00 bis FF durchlaufen lassen. etwa so:
static uint8_t cid = 0;
int32_t HM_Packets::GetTimePacket(uint8_t *buf, uint32_t wrAdr, uint32_t
dtuAdr) {
prepareBuffer(buf);
buf[0] = 0x15;
copyToBufferBE(&buf[1], wrAdr);
copyToBufferBE(&buf[5], dtuAdr);
buf[9] = 0x80;
buf[10] = cid++; // statt 0x0B
buf[11] = 0x00;
copyToBuffer(&buf[12], unixTimeStamp);
.....
Hast du auch schon die einzelnen Sendestärken durchprobiert?
Hi Lukas, heute ein erster Test mit dem HM-400 und der nun lauffähigen Version. Die Werte sind hier auch merkwürdig: [c]8:05:08.357 -> HM-400/ch1/I_DC: 105.600 A 18:05:08.357 -> HM-400/ch1/P_DC: 4785.400 18:05:08.390 -> HM-400/ch1/YieldTotal: 1056938.3 18:05:08.390 -> HM-400/ch1/YieldDay: 39.321 Wh 18:05:08.390 -> HM-400/ch0/U_AC: 3932.100 18:05:08.390 -> HM-400/ch0/Freq: 473.600 H 18:05:08.390 -> HM-400/ch0/P_AC: 158.300 W 18:05:08.390 -> HM-400/ch0/I_AC: 319.610 A 18:05:08.390 -> HM-400/ch0/Temp: 3932.100[c/] Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich schau mir das mal an... Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe ich da etwas? Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen HM-400 und HM-300 testen.
Hallo Lukas, Die neue Version läuft gut auf dem Wemos. Vielen Dank! Ist es möglich das in den MQTT Einstellungen der Port über das webinterface eingestellt werden kann?
Marcus schrieb: > Ich vermute hier werden die falschen Datenblöcke extrahiert. Ich bin in C nicht so fit, aber wird hier wirklich der richtige Wert extrahiert? Als Beispiel ein CMD82 Paket: &p->packet[0] = 00DE957310xxyy7310xxyy82138600350000000203E8009E000AF1 In app.c übergibst Du das Paket ab Position 11:
1 | mSys->addValue(iv, i, &p->packet[11]); |
Damit beginnt es ab dem CMD 82: &p->packet[11] = 82138600350000000203E8009E000AF1 Nun zum addValue Aufruf, welcher hier auf die HM-400 Werte zurück greift:
1 | { FLD_F, UNIT_HZ, CH0, CMD82, 12, 2, 100 } |
2 | |
3 | void addValue(inverter_t *p, uint8_t pos, uint8_t buf[]) { |
4 | uint8_t ptr = p->assign[pos].start; // das müsste ja die 12 sein |
5 | uint8_t end = ptr + p->assign[pos].num; // 12 plus die Länge von 2 |
6 | uint16_t div = p->assign[pos].div; => der Divisorwert 100 |
7 | |
8 | uint32_t val = 0; |
9 | do { |
10 | val <<= 8; // val = val << 8 |
11 | val |= buf[ptr]; // val = val OR buf[12]; aber da buf[] ja die Adresse von packet[11] übergeben bekommt, entspricht dann buf[12] nicht &p->packet[11]+12 Bytes (uint8) weiter? |
12 | } while(++ptr != end); |
=> Value hat damit die Werte aus den Positionen packet[23] und packet[24] (2 Byte), es muss aber die Werte packet[14] und packet[15] haben (das dritte Byte nach dem CMD ist der Start). D.h. start beginnt bei 3 (packet[11] + 3), Länge ist mit 2 korrekt. Oder ich liege völlig falsch?!
Hallo Lukas, habe die neue Version zumindest mal geflasht bekommen und komme auf die Weboberfläche (Ich habe direkt das bin geflasht) Leider erhalte ich aber keine Daten vom WR (Das Setup lief so schon mal mit einer SW von weiter oben) Unten die Ausgabe des seriellen Schnittstelle Ich habe versucht die RF Power von Max niedriger zu stellen - es springt nach dem Speichern leider immer wieder auf Max? Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 erkannt werden? Kleiner Tip noch für zukünftige Versionen: Gib über die serielle Schnittstelle auch die IP-Adresse mit aus, spart langes suchen? Viele Grüße load 0x4010f000, len 3460, room 16 tail 4 chksum 0xcc load 0x3fff20b8, len 40, room 4 tail 4 chksum 0xc9 csum 0xc9 v00057520 ~ld wait for network . add inverter: , SN: 116474903203, type: 1 RF24 Amp Pwr: RF24_PA_MAX Radio Config: SPI Frequency = 10 Mhz Channel = 3 (~ 2403 MHz) RF Data Rate = 250 KBPS RF Power Amplifier = PA_MAX RF Low Noise Amplifier = Enabled CRC Length = Disabled Address Length = 5 bytes Static Payload Length = 32 bytes Auto Retry Delay = 250 microseconds Auto Retry Attempts = 0 maximum Packets lost on current channel = 0 Retry attempts made for last transmission = 15 Multicast = Disabled Custom ACK Payload = Disabled Dynamic Payloads = Disabled Auto Acknowledgment = Disabled Primary Mode = RX TX address = 0xdeadbeef01 pipe 0 (closed) bound = 0xdeadbeef01 pipe 1 ( open ) bound = 0x1234567801 pipe 2 (closed) bound = 0xc3 pipe 3 (closed) bound = 0xc4 pipe 4 (closed) bound = 0xc5 pipe 5 (closed) bound = 0xc6
Marcus schrieb: > Channel 0 soll nicht im Webinterface angezeigt werden - oder übersehe > ich da etwas? > > Zum Setup: Im Grunde kann man die Angabe des WR-Typs weglassen und aus > der Seriennummer ermitteln. Die ersten 4 Stellen müssten die Zuordnung > ergeben - hier gab es im Thread eine Übersicht der "Gruppen". Aber ob > die alle gleich sind, habe ich noch nicht gelesen. Ich kann es für einen > HM-400 und HM-300 testen. Ja Channel 0 wird noch nicht visualisiert, man kann aber durch ein define auch hier einfach die Liste der Werte ausgeben lassen. Das mit der SN habe ich mit anfangs auch gedacht, aber ich finde das noch nicht endgültig geklärt - jetzt ist es implementiert und würde ich vorerst so lassen. Sind nur 8Bit + alles drin rum ;-) Mich@ schrieb: > Ist es möglich das in den MQTT Einstellungen der Port über das > webinterface eingestellt werden kann? ja das ist möglich, werde ich demnächst einbauen. Heinz R. schrieb: > Ich habe versucht die RF Power von Max niedriger zu stellen - es springt > nach dem Speichern leider immer wieder auf Max? ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert. > Würde in Deiner Software ein Kommunikationsproblem mit dem NRF24L01 > erkannt werden? Habe zufällig so eine Funktion in der Beschreibung der RF24 lib gesehen. Kann ich mal testweise einbauen. > Kleiner Tip noch für zukünftige Versionen: Gib über die serielle > Schnittstelle auch die IP-Adresse mit aus, spart langes suchen? Ja die Rufe werden lauter - wird eingebaut
:
Bearbeitet durch User
Lukas P. schrieb: >> Ich habe versucht die RF Power von Max niedriger zu stellen - es springt >> nach dem Speichern leider immer wieder auf Max? > > ja das ist wenn du nicht bei bootest. Es ist um einiges schwieriger > alles so zu programmieren, dass es zur Laufzeit umkonfiguriert werden > kann. Man könnte ja eine Meldung einblenden, die zum Reboot auffordert. Hallo Lukas, auch nach einem Reboot oder gar Reset steht RF Power wieder auf High? Ich versuche gerade den Fehler einzugrenzen - evtl. doch Kommunikationsprobleme mit dem NRF24L?
Das kann dann nur an der Speicherroutine liegen. Ich prüfe es bei mir nochmal. Das hat mir dem externen Bauteil nichts zu tun.
Hallo, ich probiere noch immer den Code auf ESP32 zum laufen zu bekommen. Ich würde da Hilfe von einem, der besser CPP coden kann, gebrauchen. Mehrere Ticker in der Form von:
1 | mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this)); |
compilieren mit folgendem Fehler:
1 | src/app.cpp:97:75: error: no matching function for call to 'Ticker::attach_ms(uint16_t&, std::_Bind_helper<false, void (app::*)(), app*>::type)' |
2 | mMqttTicker->attach_ms(interval, std::bind(&app::mqttTicker, this)); |
Auf Stackoverflow habe ich genau diesen Fehler gefunden, wo auch eine Lösung präsentiert wurde. Leider kann ich diese nicht auf den o.g. Code anwenden. https://stackoverflow.com/questions/60985496/arduino-esp8266-esp32-ticker-callback-class-member-function Vielleicht hat ja ein CPP Pro hier eine Antwort für mich. Vielen Dank Marcel
Mal wieder ein paar (Wenigstens für mich) neue Erkenntnisse von meinem HM600, die aber das vermutlich auch das Protokoll im allgemeinen betreffen müssten, und ich glaube, das habe ich hier so noch nicht gelesen. Ich habe versucht, die Zuverlässigkeit des Empfangs der Nachrichtenpakete zu verbessern. Einen letztlich guten Hinweis dazu habe ich in dem DTU log aus Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" gefunden. Ganz allgemein, je nach Anfrage sendet der Inverter verschiedene Nachrichten als Antwort. Meine 'Standard' Anfrage basiert auf der GetTimePacket Nachricht, die auch in dem DTU log enthalten ist. Darauf hin kommen die Antworten 0x01, 0x02, und 0x83 zurück. Für die Antworten spielt es offensichtlich keine Rolle, ob das Byte 19 0 oder 5 ist (die Anfragen der DTU logs haben 0, daher habe ich das mal versucht - wie gesagt ohne wirklichen Unterschied). Beim Anschauen der DTU logs habe ich auch eine Anfrage gesehen, die im Byte 10 statt 0x0B eine 0x11 hat. Wenn ich das an den HM600 sende, bekomme ich (nach anpassen des Rx channel scans) zuverlässig die Antworten 0x01, 0x02, ... 0x0B, 0x8C. Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* Nachrichten das letzte Antwortpaket markieren. Das diese oft nicht so oft empfangen werden könnte Dara liegen, dass alle Nachrichten auf einem Kanal erwartet werden. Das ist aber nicht der Fall - dazu später mehr. Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das Anfordern eines nicht erhaltenen Pakets. Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. Das habe ich heute so erfolgreich getestet:
1 | 19:12:16.870 -> sending data request... |
2 | 19:12:16.973 -> [75] 024A2F0000505F00B400BE08C8138500C76618A1 |
3 | 19:12:16.973 -> AC_Power: 19.9W, AC_Voltage: 224.8V, Frequency: 49.97Hz |
4 | 19:12:16.973 -> Day_Production: 370Wh (180 + 190) |
5 | 19:12:16.973 -> Total_Production: 39.6kWh (18991 + 20575) |
6 | 19:12:17.007 -> [75] 830000000903E800840B5E8BB6188E89 |
7 | 19:12:17.007 -> Level(?): 0 |
8 | 19:12:17.007 -> Status: 1000 |
9 | 19:12:17.007 -> AC_Current: 0.09A |
10 | 19:12:17.007 -> Temperature: 13.2°C |
11 | 19:12:17.308 -> |
12 | 19:12:17.308 -> sending re-transmit request 01... |
13 | 19:12:17.375 -> [75] 010001014B001F006701480020006A0000A46F02 |
14 | 19:12:17.375 -> PV1-V: 33.1V, PV1-C: 0.31A, PV1-P: 10.3W |
15 | 19:12:17.375 -> PV2-V: 32.8V, PV2-C: 0.32A, PV2-P: 10.6W |
Wie man sehen kann, fehlt die erste Antwort. Diese frage ich dann noch einmal dediziert an, und habe dann alle Pakete (Anfrage ist immer auf Kanal 40, hier alle Antworten auf Kanal 75). Das erklärt dann eventuell auch, warum AutoAck nicht verwendet wird; has hat mich bei der Suche nach einem Schema für den Kanalwechsel immer wieder etwas verwirrt. Ich dachte eigentlich, dass das Fehlen von Nachrichten an meinem 'simplen' Kanal-Scannen liegt, aber in DTU log kann man diese erneute Anfrage ebenfalls schön sehen. Könnte also ein Hinweis darauf sein, dass es keine feste Synchronisation der Kanalwechsel gibt, und daher Paketverluste 'eingeplant' sind. Durch die 'vielen' Antworten auf die '11er' Anfrage habe ich dann auch gesehen, dass ich meine channel List anpassen musste. Mit
1 | rx_channels[] = {3, 23, 40, 61, 75, 83}; |
und dem Re-transmit request bekomme ich bei mir jetzt ganz gut alle 15 Sekunden ein komplettes Datenpaket zusammen. Meine Logik ist noch nicht ganz ausgereift, so dass ich im Moment nur ein fehlendes Paket neu anfordere, aber es gibt auch mal keine Antwort, oder nur eine. Heute ist die Sonne wieder zu früh untergegangen, aber es sieht so aus, dass die Kanäle in einem festen Schema von oben nach unten gewechselt werden (da ich nicht weiß, was in den Nachrichten ist, habe ich die mal abgekürzt):
1 | 19:13:32.105 -> sending data request... |
2 | 19:13:32.139 -> [03] 010... |
3 | 19:13:32.174 -> [75] 020... |
4 | 19:13:32.242 -> [75] 030... |
5 | 19:13:32.312 -> [61] 040... |
6 | 19:13:32.346 -> [61] 050... |
7 | 19:13:32.379 -> [61] 060... |
8 | 19:13:32.446 -> [40] 070... |
9 | 19:13:32.482 -> [40] 080... |
10 | 19:13:32.550 -> [40] 090... |
11 | 19:13:32.586 -> [23] 0A0... |
12 | 19:13:32.656 -> [23] 0B0... |
13 | 19:13:32.694 -> [03] 8C0... |
Wie man an den unterschiedlichen Abständen sehen kann, fehlt noch eine 'korrekte' Synchronisation (im Moment mache ich das Timing basierend auf meinem Senden), aber es ist erstaunlich, wie gut das im Vergleich zu vorher zu funktionieren scheint.
Version 0.2.9 ist da! Changelog: - added: IP Adresse wird auf Serieller Console ausgegeben, wenn erfolgreich mit WLAN verbunden - fix: RF24 Konfiguration des Power Amplifiers - added: RF24 Verbindung wird geprüft; prüft nur, ob SPI erreichbar, wenn kein Power an RF24 Modul ist, bleibt der ganze ESP hängen (ohne Serielle Ausgabe) - added: MQTT port Konfiguration - fix: offsets für HM400 und HM600 Wechselrichter, diese sollten jetzt korrekte Werte anzeigen. Bitte um Feedback - added: Warnung, wenn die Konfiguration geändert wurde, ohne neu zu booten auf der index.html Viel Spaß damit =)
lpb schrieb: > Ich habe versucht, die Zuverlässigkeit des Empfangs der > Nachrichtenpakete zu verbessern. Hallo lpb, genial, dass du weiter auf diesem Gebiet forschst! Ich finde das super, dass sich so die Kompetenzen der einzelnen ergänzen. Wenn man statisch auf Kanal 40 das 'Zeit-setzen' schickt und nur auf Kanal 3 horcht, bekommt man sehr unzuverlässig Pakete rein. Verstehe ich das richtig, man sendet in Byte 10 eine 0x11 statt 0x0b und bekommmt dadurch viele neue Cmds in den Antworten. das erinnert bisschen an das was @Hubi schon mal kurz angesprochen hatte: Hubi (Gast) schrieb: > Habe was neues entdeckt oder ich kann mich nicht erinnern, das im Thread mal gelesen zu haben. Auf eine Anfrage hin kommen dann viele Antworten und zuletzt ein 0x83? Wie bekommt man die Zuordnung von Kanal und CMD in der Antwort? Ich muss ja dann vorher wissen wo die nächste Antwort kommt. Bin gespannt wie es hier weitergeht.
:
Bearbeitet durch User
Die Werte für den HM-400 stimmen nun:
1 | 10:17:40.209 -> HM-400/ch1/U_DC: 41.200 V |
2 | 10:17:40.209 -> HM-400/ch1/I_DC: 5.570 A |
3 | 10:17:40.209 -> HM-400/ch1/P_DC: 229.400 W |
4 | 10:17:40.209 -> HM-400/ch1/YieldTotal: 67.629 kW |
5 | 10:17:40.209 -> HM-400/ch1/YieldDay: 0.315 Wh |
6 | 10:17:40.209 -> HM-400/ch0/U_AC: 235.400 V |
7 | 10:17:40.209 -> HM-400/ch0/Freq: 50.040 Hz |
8 | 10:17:40.242 -> HM-400/ch0/P_AC: 218.200 W |
9 | 10:17:40.242 -> HM-400/ch0/I_AC: 0.930 A |
10 | 10:17:40.242 -> HM-400/ch0/Temp: 28.800 ° |
Ein paar Kleinigkeiten waren zu korrigieren (siehe app.cpp und hmInverters.h in https://github.com/dad401/ahoy/tree/main/tools/esp8266) - das h von kWh und das C von °C wird abgeschnitten => meine Änderungen scheinen da aber doch nicht zu helfen, bitte mal prüfen - YieldDay korrigiert - es wird nun wie bei HM-600 Wattstunden angezeigt (möchte nicht ständig im Thread das übermitteln - ich kann aber leider auch keinen zweiten Fork auf Lukas-Fork erstellen, daher PR auf das Haupt-Repo) P.S. ggü. Hubis NRF24 Receiver empfängt die aktuelle Version aber irgendwie schlechter. Es dauert mehrere Minuten bis etwas ankommt - früher kamen Pakete sofort nach dem Start?!
Hallo Marcus, den PR hast du garnicht durchgeführt oder? Lt. dieser Anleitung solltest du den auch meinem Repo zuweisen können: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork Yield total sollte doch in kWh sein oder, daher war der Teiler 1000. In Wh ist es sehr bald eine unnötig große Zahl. Bzgl. der Empfang: versuche mal in hmRadio.h den Channel-Hop (define) wieder zu aktivieren, evlt. geht es dann wieder besser.
Habe noch keinen PR gemacht, weil die Änderungen in der app.cpp nicht funktionieren. Ich teste das mal, ob ich Dein Repo hier verbinden kann - bin da zu unerfahren mit GIT da ich nur gelegentlich damit zu habe. Yield total stimmt. Aber das h wird hinten bei der Ausgabe abgeschnitten. Yield daily wird derzeit beim 400er in kWh ausgegeben, aber als Einheit ist Wh angezeigt - das habe ich korrigiert. Wenn Du aber eh 3 Nachkommastellen ausgibst, könnte man YD auch generell auf kWh setzen. Ist aber alles Geschmackssache - Hauptsache einheitlich :-) Ich probiere das mal mit dem Channelhopping. War das früher aktiv? Mit der ersten Version nach Behebung des Watchdog-Crashes ging es m.E. sehr gut. Jetzt dauert es 10min bis erste Pakete empfangen werden.
Bei mir liegt es stark an der Ausrichtung der Antenne, sie muss bei mir mit der abstrahlenden Seite Richtung WR zeigen. Das ist bei mir noch sehr empfindlich, daher finde ich es super, dass sich hier auch welche um besseren Empfang kümmern.
Angehängte Dateien:
-
hm_600_comm.png
110 KB
lpb schrieb: > Zusammen mit der Analyse der DTU logs denke ich, dass die 0x8* > Nachrichten das letzte Antwortpaket markieren Hallo lpb, diese Vermutung hatte ich auch schon, nachdem ich meine Messungen an der seriellen Schnittstelle hier gepostet hatte (siehe auch Bild): Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Aber die Erkenntnis mit dem Retransmit eines speziellen Pakets ist natürlich sehr nützlich. Ich hatte hier im Thread schon mal darauf hingewiesen, dass es einen Unterschied in der Antwort des Wechselrichters macht, welche Anfrage vorausging. Das dürfte vielleicht die ein oder anderen "seltsamen" Werte bei manchen hier erklären. Die 0x80 0x11 Anfrage liefert andere Antwortpakete als die 0x80 0x0B Anfrage, obwohl sie den gleichen Index haben (siehe Bild). Leider habe ich auch keine Ahnung, wie man das empfangene Paket plausibilisieren könnte. Evtl. lohnt es sich, das Channel Hopping systematischer zu untersuchen, um die komplette Antwortsequenz in einer gewissen Zeit zu erhalten. Bald sind meine Module auf dem Dach montiert, dann kann ich auch wieder hier mitmischen...
martin schrieb: > Evtl. lohnt es sich, das Channel Hopping > systematischer zu untersuchen, um die komplette Antwortsequenz in einer > gewissen Zeit zu erhalten. Vielleicht ist die Messung von B.G. ja schon ein entscheidender Hinweis: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Es scheint eine Systematik in den Kanalwechseln zu geben, nämlich "von oben nach unten": Kommt Paket 1 auf Kanal 40, dann wird auf 23 weitergehorcht. Kommt dort 02,83 ist es Antwort auf 0x80 0x0B, kommt 02,03,04 wird auf Kanal 3 weitergehorcht, bis 85 kommt. Dann ist es die Antwort auf 0x80 0x11 (?)
Hubi schrieb: > Ich würde mal in hm_packets.cpp in der Funktion getTimePacket den Wert > buf[10] von 00 bis FF durchlaufen lassen. etwa so: Hallo Hubi Danke für den Vorschlag, hatte auch mal so durchlaufen lassen wie du vorgeschlagen hast, ohne Erfolg. Bisher habe ich alle Kombinationen MID/CMD/CID durchprobiert. Ich denke die MI-Series braucht was ganz anderes, denn die Antworten sind auch ganz anders, bei den MI-Antworten gibts keine regelmaessige SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. Ich muss die DTU-Pro sniffen aber, vorerst bin ich mit meinen Möglichkeiten am Ende. Ehrlich gesagt ich kann es auch fast nicht glauben, dass die Chinesen für die HM'S vollig etwas anderes erfunden haben.. Andere Signalstaerken hab nicht probiert, es steht auf PA_MAX, hab einen NRF mit Antenne und WR ist etwa 7m weit, ich denke, was ich sende kommt an.
:
Bearbeitet durch User
Ziyat T. schrieb: > SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. Achtung, das waren die seriellen Daten INNERHALB der DTU! 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den Adressen.
martin schrieb: > Ziyat T. schrieb: >> SOF(7E),MID(95),CMD(0x0-0x83), EOF(7F) etc.. > > Achtung, das waren die seriellen Daten INNERHALB der DTU! > 7E/7F kommt in der NRF-Kommunikation nicht vor, brauchst du also nicht > zu berücksichtigen. Es ging in meinem Post nur um die Nutzdaten nach den > Adressen. Sorry, richtig!
Ich habe Hubis Code ebenfalls mal eingecheckt. Hoffe es verwirrt nicht, denn es gibt noch einen weiteren Code unter "Nano" - der ist m.E. aber etwas anderes?!
Hallo Leute, Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein stärkeres Netzteil habe ich bereits getestet… Ansonsten läuft die neue Version gut. Die Daten meines HM350 sehen plausibel aus. Auch die Abfrage per MQTT läuft.
Ich habe gleiches beobachtet, habe einfach den USB Stecker vom Laptop in ein USB-Netzteil gesteckt und auch Abstürze gesehen, auch ca. 15-20 Minuten geschätzt. Noch habe ich keine Idee woran es liegen könnte. MQTT war bei mir auch an. Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen.
Hallo, sagt mal, gibt es irgendeine Möglichkeit die Core Funktionen in eine Library auszugliedern? Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder andere NTP/WiFi implementierungen. Das wäre wirklich von Vorteil ggf. für mehrere Personen. Vielen Dank für all eure Arbeit Marcel
Hallo Marcel, das ist doch im Prinzip jetzt schon so. Ich habe alles so angelegt, damit es möglichst unabhängig vom ESP8266 ist. Im wesentlichen sind hierfür die Dateien 'hmSystem.h', 'hmRadio.h', 'hmInverters.h' und 'CircularBuffer.h' notwendig. Evtl. ist noch das eine oder andere #define aus 'defines.h' nötig. Die 'Library' wird dann ungefähr so aufgerufen (kopiert aus app.h):
1 | typedef CircularBuffer<packet_t, PACKET_BUFFER_SIZE> BufferType; |
2 | typedef HmRadio<RF24_CE_PIN, RF24_CS_PIN, RF24_IRQ_PIN, BufferType> RadioType; |
3 | typedef HmSystem<RadioType, BufferType, MAX_NUM_INVERTERS, float> HmSystemType; |
4 | |
5 | HmSystemType sys; |
aus deiner .ino setup() musst du noch diese Routine aufrufen
1 | sys.setup(); |
jetzt kannst du mit dem Objekt sys alles anstellen, z.B. einen Inverter hinzufügen:
1 | sys.addInverter("HM_XY", 116100000000, 0); |
danach muss man sich noch überlegen, was man alles in der loop() machen will, hierfür einfach in der app.cpp schauen.
:
Bearbeitet durch User
Okay super. Schaue ich mir mal an. Danke. Marcel
Mich@ schrieb: > Ich habe die neue 2.9 er Version nun auf dem Wemos getestet. Wenn der > Wemos am PC angeschlossen ist und die serielle Ausgabe läuft ist alles > perfekt. Wenn ich den Wemos nur an einem USB Netzteil betreibe läuft er > nur eine kurze Zeit zb. 15 Minuten danach ist er per Webinterface nicht > mehr erreichbar und es kommen auch keine Daten mehr per MQTT rein. Ein > stärkeres Netzteil habe ich bereits getestet… Ich habe hier einen Wemos D1 clone mit der 2.9er im Testbetrieb an einer Powerbank. Er läuft jetzt seit mehr als 3h 30min, das Webinterface ist erreichbar, die Zeit und Uptime zählen hoch. Unterschied, er läuft ohne NRF-Board (wird erst geliefert) und bekommt daher auch keine Daten. Vielleicht hilft das ja bei der Fehlersuche. SG Robert
Hallo Marcel, schau Dir doch mal die folgenden beiden ebenfalls passenden SE&SO Artikel an: [1] https://arduino.stackexchange.com/questions/76138/error-in-defining-ticker-in-esp32-library [2] https://stackoverflow.com/questions/53091205/how-to-use-non-static-member-functions-as-callback-in-c Ich habe versucht an der Stelle etwas Neues zu lernen, offenbar muß ich dazu auch noch Einiges mehr [TM] verstehen... Das Beispiel im ersten u.a. Link fand ich dazu für mich etwas klarer, da es eine ESP8266 Vorlage und ein ESP32 Ergebnis gibt. Die beiden Funktionen sendTicker und mqttTicker muss man m.E. in der app.h als public deklarieren.
1 | static void appSendTicker_helper(app* appl) {
|
2 | //needs to be public! |
3 | appl->sendTicker(); |
4 | } |
5 | |
6 | static void appMqttTicker_helper(app* appl) {
|
7 | //needs to be public! |
8 | appl->mqttTicker(); |
9 | } |
10 | |
11 | ... |
12 | mSendTicker->attach_ms(interval, &appSendTicker_helper, this); |
13 | ... |
14 | mMqttTicker->attach_ms(interval, &appMqttTicker_helper, this); |
Analog dazu sollte es auch in der main.cpp/.h möglich sein Interessant fand ich, daß der Umbau für den ESP32 dann auch unter ESP8266 funktionieren soll. Es sind also offenbar keine extra #if defined (ARDUINO_ARCH_ESP8266) #elif defined(ESP32) Blöcke für die Ticker notwendig. Für die Bibliotheken die unter ESP8266 i.d.R. auch dies als Präfix haben und die ESP32 Varianten ohne dieses Präfix hast Du m.W. ja schon die entsprechenden konditionalen include's eingepflegt.
Guten Morgen ! Ist schon jemand dahinter gekommen, was für eine Bedeutung die "81" er Telegramme vom HM350 / HM400 haben ? 005E ... 14 79 CF 005C ... 14 7F 25 0058 ... 14 72 F1 00 1234567801 005E 0B 3 95 [WR] [WR] 811479CF 1 00 1234567801 005C 0B 2 95 [WR] [WR] 81147F25 1 00 1234567801 0058 0B 0 95 [WR] [WR] 811472F1 1 00 1234567801 005E 0B 3 95 [WR] [WR] 811479CF 1 00 1234567801 005C 0B 2 95 [WR] [WR] 81147F25 1 00 1234567801 0058 0B 0 95 [WR] [WR] 811472F1 1
Angehängte Dateien:
-
ahoyb.jpg
33 KB
Hi Lukas und alle dies es interessiert,
erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr
gut lesbar.
Nach ersten Tests auf einem klassischen Arduino bin ich nun auf ein
ESP8266 Modul umgestiegen.
Man braucht für den Code wirklich aktuelle Tools zum compileren, da wohl
erst vor gar nicht langer Zeit die String-Conversion von uint64_t
eingebaut wurde. Bei schickte das die Umsetzung der Seriennummern in
eine Byte-Wurscht auf die Bretter... ;-)
Danach übersetzte das Ganze aber klaglos und lief auch auf Anhieb.
Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich
musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom
"Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC
Leistung. Also habe ich Zeile
{ FLD_IAC, UNIT_A, CH0, CMD02, 15, 2, 10 },
gegen
{ FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 },
getauscht. - Jetzt passt es.
Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden:
{ FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 },
=> Kann das bitte mal jemand mit einem HM600 checken, ob das beim HM600
auch so ist? - Sonst müsste man die HM600/700 Werte defines
separieren...
Die Visualisierung habe ich für mich noch auf die Schnelle um die
AC-Werte erweitert. - Siehe Screenshot. :-)
Ein Issue habe ich noch:
=> Ich habe ab und zu (gemittelt alle 10-20 Minuten) Stacktraces, also
Abstürze mit Exception 0. Meist im Zusammenhang mit der ISR für den
externen Interrupt und gleichzeitigem Bedienen des WLAN-TX.
=> Das Modul startet dann korrekt neu, bekommt aber keine IP-Adresse
zugewiesen (IP unset). Ein Reset behebt das aber (temporär).
Ich beobachte das weiter und prüfe heute noch, ob es ein HW-Thema
(Spannungseinbrüche o.ä.) ist oder eher nicht.
Cheers,
Lars
:
Bearbeitet durch User
Hallo zusammen Im Anhang meine neueste Version, da ich gesehen habe, dass doch einige diese ausprobieren. Kommentare dazu: - Projekt jetzt umgenannt in HoyDtuSim (Hoymiles DTU Simulation) -Läuft auf Arduino (bei mir auf Pro Mini) und ESP (Wemos D1 mini), je nachdem wie man kompiliert - Channel hopping für senden und Empfangen (poor man's ...) ist eingebaut und bringt konstante Antworten; obige Erkenntnisse über Kanäle abwärts sind noch nicht eingebaut - da manchmal ein Abbruch der RF-Verbindung vorkam (auch schon oben erwähnt) wird jetzt nach ca 50 Sekunden ohne Empfang das RF-Modul neu initialisiert und es geht problemlos weiter - Definitionen für HM-600 und HM-1200 sind implementiert, andere können anhand der beiden Beispiele sicher leicht impl. werden - Anpassungen sind in der Settings.h zu machen Marcus hat in das lumapu-Repo meine Version vom 13.04. eingecheckt. Wäre nett wenn er dies durch diese hier ersetzen würde. Wenn ich Zugang zu diesem Branch hätte und wenn ich wüßte wie das geht würde ich das auch selbst machen. Aber ich kann neue Versionen auch an Lukas P. (lumapu) per Mail schicken. @Herbert: Die 81er habe ich auch dauernd, besonders 8114. Fehlermeldung?
Beim compilieren mit der aktuelle IDE und aktuellen Bibliotheken kommt folgende Fehlermeldung: app.cpp:58:95: error: call of overloaded 'String(uint64_t&, int)' is ambiguous Liegt das an der fehlenden Seriennummer die ich noch nicht eingetragen habe, weil ich nicht weiß wo? Sorry für die Anfängerfragen. Danke
Hallo Sorbit für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das aber keinen Fehler werfen. Wenn du die Serial ausgeben willst, kannst du das so machen
1 | sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned long)(serial&0xFFFFFFFFULL)); |
Marcel A. schrieb: > Ich würde sehr gerne das ganze auf einen ESP32 portieren und dann auch > auf EspHome. Ich brauche dazu weder ein Webinterface noch ein MQTT oder > andere NTP/WiFi implementierungen. Ich bastel gerade an einer Testversion für Tasmota - muss mir aber immer recht viel zusammensuchen, da ich nicht so tief drin stecke im Programmieren wie z.B. Lukas. Die Integration kompiliert inzwischen - einiges musste ich anpassen, konnte aber viele der Dateien von Lukas weiterverwenden. Ob es auch läuft konnte ich noch nicht testen. Kann das gerne in mein GIT einstellen ([[https://github.com/dad401/Tasmota]] Tasmota-Fork) - ist aber sicher noch nicht so toll der Code. Learning by Doing auch was GIT betrifft. @all: Wie plausibel haltet ihr die Werte für P_AC und Power total/daily => sind das die Werte, welcher ein Wechselstromzähler messen sollte oder könnte das ggf. doch (tlw.) Werte für DC sein? Wenn das passt, dann kann man damit auch z.B. einen SonOff besser kalibrieren. Dieser weicht derzeit nur wenige kWh von der Tagesproduktion ab.
Lukas P. schrieb: > Ich fände für die Zukunft gut Fehler via Github Issues zu regeln, dann > können wir uns hier mehr wieder dem Protokoll, Funk, Kanäle usw. widmen. Ich glaube Du musst da "Discussions" in den "Settings" anwählen - in Deinem GIT habe ich irgendwie (ohne PR) keine Möglichkeit gefunden zum Austausch.
Hubi schrieb: > Wäre > nett wenn er dies durch diese hier ersetzen würde. Ist bei mir drin und PR für das Hauptrepo angefordert. Mit einen GIT Account könntest Du das auch selbst. Ich kann Dir die Schritte, wenn Du den Account hast gerne sagen (so wie ich es mache/gelesen habe). Am besten aber dann hier [[Du bräuchtest einen git Account]] sonst sprengen wir die Server von mikrokontroller.net ;-)
Marcus schrieb: > Am besten aber dann hier [[Du bräuchtest einen git > Account]] [[https://github.com/dad401/ahoy/discussions]]
So, ich habe mir einen Git account zugelegt und meine SW dort mal reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation. Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, bitte gerne.
Hubi schrieb: > So, ich habe mir einen Git account zugelegt und meine SW dort mal > reingestellt, siehe https://github.com/hm-soft/Hoymiles-DTU-Simulation. > Ich weiß nicht, ob das so rechtlich ok ist. Wenn jmd (wenn das überhaupt > geht) einen Link in seinem Repo (Marcus? , Lukas?) darauf setzen will, > bitte gerne. Das ist nun die Frage - belassen wir alles im Haupt-Repo [[https://github.com/grindylow/ahoy]] oder führt jeder Entwickler sein eigenes? Ich kann diese Frage nicht beantworten. Man könnte es ja so machen: Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). Aber das müsst ihr wissen. Mir wird nur etwas schwindlig wenn man immer alles zwischen den Forks synct ;) Für mich wäre es einfacher wenn ich als Nutzer Hubis-Repo und Lukas-Repo bei mir forken kann und dort Änderungen per PR einbringen kann. Derzeit ist das irgendwie über zwei Ecken. <just my 2 cents> Marcus
Hallo Marcus, wir sollten bei dem Hauptrepository bleiben, aber evtl. kannst du mich als 'Colloborator' hinzufügen, dann kann ich direkt die Pull-Request managen - denke ich (ich hab leider auch keine Github Erfahrung) Repository -> Settings -> Colloborators
Hallo Lukas Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann meine weitere Entwicklung per Mail zukommen lassen. Bin auch der Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und wird dann unübersichtlich. Bin da offen. Deine wirklich sehr gute OOP Entwicklung wäre schon wert unterstützt zu werden.
Hubi schrieb: > Hallo Sorbit > für Arduino gibt es den String-Constructor nicht. Bei ESP sollte das > aber keinen Fehler werfen. > Wenn du die Serial ausgeben willst, kannst du das so machen1 > sprintf(_buffer, "%lX%08lX", (unsigned long)(serial>>32), (unsigned > long)(serial&0xFFFFFFFFULL)); Hallo Ahoi, Hubi, oder wer auch immer dahinter steckt😄 Im Git Repository steht doch geschrieben, das der Code für Arduino mit ESP8266 als Taget gedacht ist. Dann sollte der Compiler doch sauber durchlaufen. Ich verstehe den Zusammenhang nicht. Kann mir jemand auf die Sprünge helfen? Danke
Ich lade gerne "Collaborators" in das AHOY Repository ein. Schreibt doch hier im Thread kurz Eure Github-Namen und Euren Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als Collaborators hinzu. Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich hier im Forum in der Minderheit!), aber ich stimme Marcus und den anderen zu, dass es insbesondere für Nutzer hilfreich ist, wenn die Entwicklung nicht an zu vielen unterschiedlichen Forks läuft. Gruß Martin (petersilie) / https://github.com/grindylow/ahoy ps. Habe gerade mal das Haupt-README mit direkten Verweisen auf die Unterprojekte aktualisiert. Für die Übersicht wäre es super, wenn jeder Autor für "sein" Tool ein kleines README hinzufügen könnte. Dann finden sich auch Fremde schnell zurecht. Als Beispiel/Vorlage kann z.B. https://github.com/grindylow/ahoy/tree/main/tools/rpi dienen.
:
Bearbeitet durch User
Hallo Martin,
> Mein Interesse ist immer noch eher auf der Raspi-Version
Schön! Ich halte zumindest davon auch noch am meisten, was das effektive
Entwickeln angeht, wenn auch der Ressourceneinsatz etwa bei einem ESP32
deutlichst kleiner ausfällt, wenn er dann einmal als Webserver läuft.
Übrigens habe ich heute meinen NRF24_Sniffer zugeschickt bekommen und
werde wohl in den nächsten Tagen das Dingens mal aktivieren. Wenn's dann
klappt, hoffe ich, was zum HM-1500 beitragen zu können. Wobei ich hoffe,
weitestgehend die Auslesung des HM-1200 übernehmen zu können. ;-)
Tschüssi,
Petra
Hallo Sorbit mit der Arduino IDE und Einstellung Lolin(Wemos) D1 R2 & mini lässt sich zB ein
1 | Serial.println(String(serialNr,HEX)) |
ohne Fehler kompilieren. Ich benutze die IDE 1.8.13, nicht die neueste.
Martin G. schrieb: > Mein Interesse ist immernoch eher auf der Raspi-Version (damit bin ich > hier im Forum in der Minderheit!), welche Vorteile versprichst Du Dir davon? Denke man sollte es möglichst einfach halten - und möglichst einfach ist halt der ESP8266
Nachdem ich bisher nur stiller Mitleser war, hier mein erster Beitrag. Sehr cool, was ihr hier schon gemeinsam geschafft habt! :-) Heinz R. schrieb: > welche Vorteile versprichst Du Dir davon? > Denke man sollte es möglichst einfach halten - und möglichst einfach ist > halt der ESP8266 Der ESP ist sicherlich ein guter Start, universell und aus meiner Sicht eine schöne Plattform. Ich persönlich würde es auf Dauer aber auch bevorzugen, wenn das System auf einem bestehenden Raspberry untergebracht werden könnte und ich keine zusätzliche Hardware dafür laufen lassen muss. Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell ablesbar zu machen.
Heinz R. schrieb: > welche Vorteile versprichst Du Dir davon? > Denke man sollte es möglichst einfach halten - und möglichst einfach ist > halt der ESP8266 Der ESP8266/ESP32 ist sicher eine tolle Sache. Ich habe persönlich nicht primär das Nachbauen einer "DTU" im Kopf, sondern die Integration der Hoymiles-Wechselrichter in ein größeres Ökosystem. Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den Wechselrichtern einfach noch mitmachen lassen. Webinterface/Archivierung etc ist dann nicht Aufgabe der Hoymiles-Anbindung, sondern des übergeordneten Systems. Vielleicht ein bisschen wie die "DTU-Pro"-Anbindung via Modbus (wobei die DTU-Pro ja wohl auch ein Webinterface etc etc bietet). Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit NRF24 als auch mit Wifi auf 2.4 GHz. Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf. Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. Das sind alles absolut gute Wege, und jede Alternative trägt ein bisschen zum Erkenntnisgewinn bei. Ich finde es prima, wie wir alle unsere Erfahrungen mit dem Protokoll zusammensammeln!
> Alternativ spiele ich mit dem Gedanken, dem ESP zusätzlich ein Display > zu verpassen, um die Werte auch ohne Smartphone z.B. für Gäste schnell > ablesbar zu machen. Jenau, man schaue z.B. unter https://tutorials-raspberrypi.de/esp8266-grafikdisplay-ssd1306-oled-bilder-text-anzeigen/ Wobei ich eher zum esp32 tendiere, weil der wohl bei minimalem Aufpreis etwas besser ausgestattet ist? Tschüssi, Petra
> Ein weiterer Punkt könnte sein, dass die Wireless-Fähigkeit hier > eventuell eher kontraproduktiv ist. Schließlich funken wir ja sowohl mit > NRF24 als auch mit Wifi auf 2.4 GHz. Scho'recht, allerdings ist die Frage, wie stark die Hoymiles-Abfragerei das WLAN belastet. Ich möchte auch mal hinterfragen, ob es einen Sinn macht, sekündlich Werte abzufragen? Ich denke, wenn man alle 30 s einen Wertesatz holt, wird sich die Statistik nur sehr unwesentlich verschlechtern. > Schließlich kann man auf dem Raspi mit Python wunderbar "interaktiv" > experimentieren, ohne den für einen µC notwendigen Compiler-Durchlauf. Das auf jeden Fall - das ist auch bei mir der Antrieb, damit anzufangen, um ... > Aber all das soll auf keinen Fall die ESPxxx-Ansätze in Frage stellen. ... später, wenn alles so weit ausexperimentiert ist und nur noch gelegentlich mal nach dem Zustand geschaut wird, so was als Standardanzeige zu etablieren. Zumindest fände ich es nett, hier eine Low-Power-Alternative zur Verfügung zu haben. ;-) Tschüssi, Petra
Lukas P. schrieb: > aber evtl. kannst du mich > als 'Colloborator' hinzufügen Das wäre dann aber petersilie - das Hauptrepo ist seins, hat er aber darunter bereits geschrieben: Martin G schrieb: > Ich lade gerne "Collaborators" in das AHOY Repository ein. > Schreibt doch hier im Thread kurz Eure Github-Namen und Euren > Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als > Collaborators hinzu. Mein GIT: [[https://github.com/dad401]] Fokus: Nutzertests mit HM-400 (und HM-300), ggf. Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren Programmierkenntnissen beteiligt. Martin G schrieb: > Z.B. läuft bei mir sowieso schon ein Raspberry Pi, und den kann man > durch Hinzufügen eines NRF24-Funkmoduls das Kommunizieren mit den > Wechselrichtern einfach noch mitmachen lassen. Ich finde es gut, dass es auch diese Alternative gibt, denn auch ich würde mir ggf. ein zusätzliches Gerät sparen. Ich habe inzw. alles kompiliert/konfiguriert, aber bekomme es noch nicht zum Laufen. Benötige ich da zwingend den MQTT-Server? Ich muss das nochmal genauer prüfen. Einzig nachteilig (IMHO) ist leider das "Gefummel" (kompilieren statt einfach per apt installieren) mit den Bibliotheken. Solang das alles fehlerfrei klappt ist gut, aber wer weiß was mit dem nächsten RPi-Update passiert. Petra R. schrieb: > Ich möchte auch mal hinterfragen, ob es einen Sinn > macht, sekündlich Werte abzufragen? Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools berücksichtigt werden. Ich denke dies ist immer noch des ersten funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer stabil kommen. Ggf. macht man das Abfrageinterval einstellbar. Meine RRD-Datenbank befülle ich (von einem SonOff Pow R2) jede Minute. Wenn also stabil bei einer Abfrage eine Antwort kommt, dann reichen sicher 30s Intervall aus.
Marcus schrieb: > Hubi schrieb: > Man könnte es ja so machen: > Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software > lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). > Diesen Weg sollten wir gehen, denn es gibt noch viele ungelöste Dinge! IMHO, es sollten unbedingt alle Infos Zentral sein. Ich habe das Gefühl, dass bisher "nur" ein Paar WR Daten (und diese nur von HM's!) sichtbar sind, und schon wird hier über HW-Plattform diskutiert;-)
:
Bearbeitet durch User
Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente. Hier eine weitere HM-300 Seriennummer: 11216281xxyy Also ich leg mich fest, die HM-3xx und HM-400er beginnen mit immer 1121 ;)
Vorweg: Super Arbeit - vielen Dank! Die ESP8266 Version funktioniert mit einem HM-800 (114174...) Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc erwähnten Installation der Library "PubSubClient"):
1 | { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, |
2 | { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 } |
In der kurzen Testphase kam es zu Hängern - ich vermute einen Zusammenhang mit geöffnetem Webinterface. lg
st_b schrieb: > Die ESP8266 Version funktioniert mit einem HM-800 (114174...) > Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc > erwähnten Installation der Library "PubSubClient"): Hallo st_b , auf welcher Definition basiert deine Änderung, auf der vom HM600? Doku werde ich nachziehen, danke für den Hinweis.
Hubi schrieb: > Hallo Lukas > Habe kein Problem damit mein Repo wieder zu löschen und alles irgendwie > bei dir oder sonst jemanden zentral zu halten. Ich kann dir ja dann > meine weitere Entwicklung per Mail zukommen lassen. Bin auch der > Meinung, wenn alles irgendwie auseinander läuft wäre nicht so gut und > wird dann unübersichtlich. Bin da offen. Hallo Hubi, das liegt bei dir, ich finde es nicht falsch wenn du einen Git Account hast und direkt Änderungen per pull request einfließen lässt. Per Mail geht auch, dann checke ich es ein. Deine wirklich sehr gute OOP > Entwicklung wäre schon wert unterstützt zu werden. Vielen Dank für die Blumen ;-)
Lars B. schrieb: > erstmal danke für den guten Code. :-) - Zwar wenig Kommentare, aber sehr > gut lesbar. Das ist mein Ziel: so wenig wie möglich kommentieren, lieber sprechen Code schreiben. Ist nicht immer ganz einfach, aber so bleibt das gesamte auch über Monate wartbar. > Die Werte-Zuweisungen in hmdefines.h sind für HM600 und 700 gleich. Ich > musste diese aber für meinen HM700 anpassen. Es wurden für den AC-Strom > "Schweissgerät-verdächtige" Werte angezeigt. Tatsächlich war dies die AC > Leistung. Also habe ich Zeile > { FLD_IAC, UNIT_A, CH0, CMD02, 15, 2, 10 }, > gegen > { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, > getauscht. - Jetzt passt es. > > Den AC Strom des HM700 habe ich - aller Vermutung nach - hier gefunden: > { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 }, Ich kann leider nicht nachvollziehen, ob diese Änderungen bereits per PR in das repo gekommen sind, falls nicht bitte noch anlegen. > Die Visualisierung habe ich für mich noch auf die Schnelle um die > AC-Werte erweitert. - Siehe Screenshot. :-) Auch hier freue ich mich über einen PR in Git.
Lukas P. schrieb: > st_b schrieb: >> Die ESP8266 Version funktioniert mit einem HM-800 (114174...) >> Wechselrichter nach kleinen Anpassungen (und der noch nicht in der Doc >> erwähnten Installation der Library "PubSubClient"): > > Hallo st_b , > auf welcher Definition basiert deine Änderung, auf der vom HM600? > Doku werde ich nachziehen, danke für den Hinweis. Ich habe die Definition des HM-600 angepasst. Vollständigkeitshalber sei erwähnt, dass die Werte ursprünglich von Lars B. stammen)
1 | const byteAssign_t hm800assignment[] = { |
2 | { FLD_UDC, UNIT_V, CH1, CMD01, 3, 2, 10 }, |
3 | { FLD_IDC, UNIT_A, CH1, CMD01, 5, 2, 100 }, |
4 | { FLD_PDC, UNIT_W, CH1, CMD01, 7, 2, 10 }, |
5 | { FLD_UDC, UNIT_V, CH2, CMD01, 9, 2, 10 }, |
6 | { FLD_IDC, UNIT_A, CH2, CMD01, 11, 2, 100 }, |
7 | { FLD_PDC, UNIT_W, CH2, CMD01, 13, 2, 10 }, |
8 | { FLD_YW, UNIT_WH, CH0, CMD02, 1, 2, 1 }, |
9 | { FLD_YT, UNIT_KWH, CH0, CMD02, 3, 4, 1000 }, |
10 | { FLD_YD, UNIT_WH, CH1, CMD02, 7, 2, 1 }, |
11 | { FLD_YD, UNIT_WH, CH2, CMD02, 9, 2, 1 }, |
12 | { FLD_UAC, UNIT_V, CH0, CMD02, 11, 2, 10 }, |
13 | { FLD_F, UNIT_HZ, CH0, CMD02, 13, 2, 100 }, |
14 | { FLD_PAC, UNIT_W, CH0, CMD02, 15, 2, 10 }, |
15 | { FLD_IAC, UNIT_A, CH0, CMD83, 3, 2, 100 }, |
16 | { FLD_T, UNIT_C, CH0, CMD83, 7, 2, 10 } |
17 | };
|
18 | #define HM800_LIST_LEN (sizeof(hm800assignment) / sizeof(byteAssign_t))
|
Hallo Marcus,
> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente.
ich habe die Statistik der Seriennummern noch einmal sauber aufgeräumt
und nach Seriennummer sortiert.
Wenn Ihr wollt, könnt Ihr die gerne einchecken, ich habe die auch nur
weitergeführt.
Ich habe jetzt auch die Usernamen aus dem Forum ergänzt um zu sehen, von
wem evtl. noch eine führende Ziffer zu bekommen wäre:
Arnaldo G. (arnaldo_g), martin (Gast), Oliver F. (of22), heijz, Carsten
B. (carstenb) könntet Ihr eventuell hier im Forum oder direkt in der
Tabelle Eure führenden Ziffern bzw. die Serien-/Modellnummer Eures
Wechselrichters / DTU Modells ergänzen ?
Auch die ForistInnen mit einem MI- Wechselrichter der älteren Bauart
müssten ggf. Ihre Seriennummern beisteuern, da hiervon außer dem TSUN
TSOL-M800 von Daniel M. (Gast) noch keine hier bekanntgegeben wurde.
Hier eine auf die ersten vier Stellen gekürzte Liste aus dem Excel, das ich letzte Woche aktualisiert habe:
1 | Name | Serien |
2 | --------- | ------ |
3 | MI-250 | 1020 |
4 | MI-300 | 1021 |
5 | MI-? | 1022 |
6 | MI-500 | 1040 |
7 | TSOL-M800 | 1041 |
8 | MI-1000 | 1060 |
9 | MI-1200 | 1061 |
10 | MI-1500 | 1061 |
11 | MI-? | 1062 |
12 | HM-300 | 1121 |
13 | HM-350 | 1121 |
14 | HM-400 | 1121 |
15 | HM-600 | 1141 |
16 | HM-700 | 1141 |
17 | HM-800 | 1141 |
18 | HM-1200 | 1161 |
19 | HM-1500 | 1161 |
20 | DTU-G100 | 10D2 |
21 | DTU-W100 | 10D3 |
22 | DTU-Pro | 10F7 |
23 | DTU-Pro | 10F8 |
Wie man sehen kann sind die Seriennummern nicht ganz eindeutig. Aber es sollte von der Zahl der Anschlüsse bzw. MPPT die im Wechselrichter verbaut sind eigentlich hinkommen, daß alle mit der selben Seriennummer zumindest einen ähnlichen inneren Aufbau haben sollten. Lediglich die maximale Leistung der Kanäle scheint sie noch zu unterscheiden. Ich habe auch mal die Seriennummern der DTUs und unseres Exoten TSUN "TSOL-M800" aufgenommen.
Marcus schrieb: >> Ich lade gerne "Collaborators" in das AHOY Repository ein. >> Schreibt doch hier im Thread kurz Eure Github-Namen und Euren >> Haupt-Fokus (oder auch mir im Direkt-Chat), und ich nehme Euch als >> Collaborators hinzu. > > Mein GIT: [[https://github.com/dad401]] > > Fokus: Nutzertests mit HM-400 (und HM-300), ggf. > Fehlerbehebungen/-Verbesserungen/Ideen einbringen, geplant: eine erste > Proof-of-Concept Version für Tasmota im gleichnamigen Fork (noch nicht > commited!). Hier wäre ich dann begeistert, wenn sich jemand mit besseren > Programmierkenntnissen beteiligt. Einladung ist erfolgt! > Man könnte es ja so machen: > Haupt-Repo: alles gesammelten Infos etc. und bzgl. der Software > lediglich Verweise auf die Entwickler-GITs (Hubi, Lukas). Das könnten wir auch gerne so halten. Ich habe leider ein bisschen den Überblick verloren, wer an welchem Teilprojekt in welcher Repo am aktivsten ist. Gerne kann ich in der Haupt-Repo im README auf die jeweiligen anderen Repos verweisen, und dann im Laufe der Zeit auch die (dann veralteten) Unterverzeichnisse entfernen. Am besten würde ich dann auch die jeweiligen Autoren mit auflisten, oder? Persönlich fände ich es gut, wenn wir die Doku (https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) im Hauptrepo (https://github.com/grindylow/ahoy) pflegen würden. Die können wir dann gerne auch versuchen, auszubauen und evtl. auf readthedocs.io o.ä. zu hosten. Mir fehlt nur gerade ein bisschen die Zeit - aber über die nächsten Wochen wird sich schon wieder Zeit finden...
isnoAhoy schrieb: >> Wer hatte die aktuelle Statistiktabelle? Die muss auch mal in die Dokumente. Habe die aktuelle von @isnoAhoy zusammengestellte Liste jetzt zumindest mal dem Repo hinzugefügt: https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx Ja, die Erkenntnisse daraus sollte ich (?) dann mal in die Haupt-Doku (https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.txt) einfließen lassen...
:
Bearbeitet durch User
Marcus schrieb: > Petra R. schrieb: >> Ich möchte auch mal hinterfragen, ob es einen Sinn >> macht, sekündlich Werte abzufragen? > > Sehe ich ebenso. Dies sollte bei "Reifung"/Optimierung der Tools > berücksichtigt werden. Ich denke dies ist immer noch des ersten > funktionalen Lösungen geschuldet und das die Antworten wohl nicht immer > stabil kommen. In manchen Programmen war/ist auch immernoch das "AutoACK" eingeschaltet. Das geht in die selbe Richtung: da wir schlüssig nachgewiesen haben, dass die WR kein AutoACK machen, bedeutet das faktisch, dass unsere Programme das jeweilige Paket mehrfach (ich meine 15-fach) hintereinander aussenden. Das führt vermutlich zu "verlässlicherer" Kommunikation, flutet aber natürlich "unnötigerweise" das 2.4 GHz Band. Die bisherigen Erfahrungen zeigen, dass das eine DTU auf jeden Fall nicht ganz so "extrem" macht, und trotzdem "verlässlich" kommuniziert. Langer Rede kurzer Sinn: später muss * das AutoACK ausgeschaltet und * das Poll-Intervall auf einen "sinnvollen" Wert (15s, 30s, evtl. noch langsamer) ...eingestellt werden.
HM1500 funktioniert hier auch mit ESP8266 und NFR24L01+ und die letzte Seriennummer meine 1500 fangt auch mit 1161 an. Steht upload nach PvOutput.org noch auf's Programm?
Angehängte Dateien:
-
HM-600_Telegramm.png
17 KB
Hallo zusammen, Jan (HM-600) und ich (HM-1500) haben gerade den ESP8266 und Python Code, die Byte Assignments usw. für beide Wechselrichter angeschaut. Dadurch sind wir auf folgende Erkenntnisse / Theorien gekommen: * Beim HM-600 macht der Weekly Counter keinen Sinn (bei Jan ist dieser höher als der vermeintliche Total) * Der HM-1500 hat Total Spalten für jeden seiner 4 Eingänge * Wenn der HM-600 der gleichen Struktur folgt, müsste dieser 2 Total Werte haben. * Diese beiden Werte müssten jedoch 4 Byte haben * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1) Folgende Überlegungen: Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet. Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert übergelaufen? Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4 Unabhängig davon haben wir einen Pull Request für AC I und P mit einem HM-600 erstellt: https://github.com/grindylow/ahoy/pull/21
:
Bearbeitet durch User
Guten morgen, der Code von ahoy läuft jetzt auf meinem ESP32. Vielen Dank dafür. Ich habe einen HM400 und mir mal die Daten angeschaut und dazu mal eine Frage. Es scheint ja ch0 und ch1 zu geben ? Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das ? Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem Anschluss hat. Was war denn der Plan hinter diesen Channel ? Ich kann es für den HM400 ändern, sobald ich weiß wie das Konzept ist.
1 | HM_400/ch1/U_DC: 38.000 |
2 | HM_400/ch1/I_DC: 3.260 |
3 | HM_400/ch1/P_DC: 123.700 |
4 | HM_400/ch1/YieldTotal: 39.363 |
5 | HM_400/ch1/YieldDay: 183.000 |
6 | HM_400/ch0/U_AC: 229.400 |
7 | HM_400/ch0/Freq: 50.030 |
8 | HM_400/ch0/P_AC: 120.600 |
9 | HM_400/ch0/I_AC: 0.530 |
10 | HM_400/ch0/Temp: 30.100 |
Danke Marcel
Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra Steckdose brauchen würde. Marcel
Hallo Marcel, > Was war denn der Plan hinter diesen Channel ? Channel 0 stellt Parameter dar die keinem direkten Input auf der DC Seite zugeordnet werden können (also z.B. AC Strom der AC Spannung). Da es beim HM-400 nur einen Eingang gibt, gibt es neben dem CH0 auch nur einen weiteren Kanal (CH1) welcher die DC Seite darstellt. > Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das Einspeisen? Nachdem es diesen Wert sowohl für den HM-600 (und kompatible) sowie für den HM-1500 (und kompatible wie HM-1200) gibt, würde ich vermuten das dieser auch für die Einkanal Geräte existiert. Es wurde wohl nur noch nicht herausgefunden welcher Wert dem entspricht.
:
Bearbeitet durch User
Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert. Meine Skills reichen nicht aus um die Fehler selbst zu beheben. Wo stelle ich HM1200 und die Seriennummer ein?
> Es scheint ja ch0 und ch1 zu geben ? Richtig, CH0 dürfte allegemeiner Natur sein, sowas wie AC Seite des Wechselrichters und evtl. Temperatur. > Ich gehe mal davon aus, das diese channel die MPPT Channels sind - stimmt das? Nicht ganz CH1..4 sind die MPPT Channel. > Wenn ja, dann wäre das für den HM400 ja nicht korrekt, da dieser ja nur ein MPPT mit nur einem Anschluss hat. In der Hoymiles Dokumentation bzw. der App zur Hoymiles DTU-Lite-S heißt CH0 auch "Output grid port" und die anderen Kanäle CH1 .. CH4 "Input port1..4". Ich habe gestern noch ein wenig in den offiziellen Dokus gelesen und dabei habe ich noch eine Menge DTU und WR Seriennummern gefunden. Ich werde diese die Tage evtl. mal noch im Seriennummern XLSX nachtragen.
Hallo Thomas B. und Jan, > * Wenn man das Telegram im Anhang ansieht, kann der erste Wert in CMD 2 > keine 4 Byte haben da dieser direkt am Beginn des Telegramms steht > * Es gibt jedoch 2 leere Bytes am Ende der 1. Message (CMD 1) Ich glaube die Vermutung hatten wir auch schon weiter oben auf Seite 4. Aber ich habe gerade keine Referenz. Vielleicht war das auch nur ein Gedanke als es sich herausgestellt hat, daß die Yield Total Werte in kWh ja vier Byte belegen. > Folgende Überlegungen: > Was ist, wenn man die CMDs alle zusammenfügen muss zu einem großen > Datenpaket? Das CMD wäre dann ein Fragment Counter der bei 0x8* endet. Das wäre in der Tat sinnvoll, da die einzelnen Telegramme ja über den Rahmen jeweils mit einem CRC8 und ggf. CRC_M/16 (Modbus) gecheckt werden können. Vielleicht gibt es am Ende (0x8x Telegramm) ja auch noch eine weitere Prüfsumme ? > Ist bei jemanden mit HM-600 schon einmal der 2 Byte total Wert übergelaufen? Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn diese Telegramme wie bisher immer einzeln verarbeitet werden. @Lukas P. bei den HM-1000/1200/1500 habt ihr ja alle vier Byte in einem Telegramm. Für die HM-600/700/800 bräuchten wir in der Tat so einen Übertrag oder eine Kombination aller Teilinformationen der Telegramme um die ganze Nachricht zu parsen. > Falls ja, müssten ja die letzten beiden Bytes bei "CMD" 1 größer Null > sein. Genauso wie bei "CMD" 2 die Bytes 3 und 4 Wie gesagt das hatte ich auch angenommen, weiß jetzt aber nicht ob wirklich jemand seinen HM-600/700/800 schon zum "Überlauf" in das erste Telegramm gebracht hat. Dauert ja logischerweise auch doppelt so lange wie bei den größeren HM-1000/1200/1500 =^D Meiner wartet noch auf die Montage der Solarpanele bevor er richtig einspeißen darf.
> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen > ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? > > Ich bekomme das leider nicht mit aktueller Arduino IDE kompiliert. > Meine Skills reichen nicht aus um die Fehler selbst zu beheben. > > Wo stelle ich HM1200 und die Seriennummer ein? Hallo Sorbit, schau mal auf der Anleitung nach: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den ESP8266 zu kompilieren. Prüfe mal folgendes: * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support herunterladen) * die beiden RF24 und TimeLib Bibliotheken im Library Manager installieren. @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der ESP8266 Boards Umgebung ? Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem o.g. Github aufmachen, damit wir die Dokumentation erweitern und die Schritte die Dir fehlen nachreichen ? https://github.com/grindylow/ahoy/issues
isnoAhoy schrieb: > brauchen wir auch die Ticker Bibliothek oder ist die Teil der > ESP8266 Boards Umgebung ? Ich denke nicht, da diese direkt von der ESP8266 Bibliothek mitgeliefert wird. (Hier wird sich in naher Zukunft auch noch was ändern, ich diskutiere hier gerade mit stefan123t auf Github.) Sorbit schrieb: > Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen > ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP auf die /setup Seite gehen und dort alles konfigurieren. Marcel A. schrieb: > Ebenfalls frage ich mich, ob es denn auch eine Summe in kWh gibt für das > Einspeisen? Also wieviel kWh wurde AC seitig generiert und in das Netz > abgegeben. Wäre ja eigentlich schade, wenn man dafür jetzt eine extra > Steckdose brauchen würde. Das Yield Total ist doch genau das Feld. In der neuen Version sind auch Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 habe ich mal 4 beispielhafte Berechnungen definiert)
isnoAhoy schrieb: > Ich habe mir schon Überlegungen gemacht, wie man denn die Werte, die > dann ja über zwei Telegramme verteilt sind sinnvoll parsen könnte, wenn > diese Telegramme wie bisher immer einzeln verarbeitet werden. Die Schwierigkeit wäre dann auch noch, wenn es wenn es zu Paketverlusten beim Überlauf kommt. Also wenn man z.B. beim HM-600 bleibt und der Total Wert wirklich über zwei Telegramme verteilt ist könnte es ja zu folgendem Szenario kommen: * Anfrage senden * Antwort Paket ID 1 geht verloren * Antwort Paket ID 2 kommt durch und der Total Wert steht bei 0xFF 0xFF... * Paket ID 1 wird erneut angefordert * Jetzt gab es den überlauf, die letzten beiden Bytes in Paket 1 sind 0x00 und 0x01. * Sollte man jetzt beide Pakete einfach zusammensetzen hätte man ja 0x00 0x01 0xFF 0xFF * In Wirklichkeit sollte es aber 0x00 0x01 0x00 0x00 sein * Man müsste also auch Paket 2 neu anfordern
Angehängte Dateien:
Hallo, Lukas P. schrieb: > Das Yield Total ist doch genau das Feld. In der neuen Version sind auch > Berechnungen möglich, die werden auch in der hmDefines.h eingetragen, > dann könntest du z.B. diesen Wert auch auf CH0 kopieren. (Für den HM1200 > habe ich mal 4 beispielhafte Berechnungen definiert) Da würde ich nicht mitgehen. Das was ich gemessen habe, entspricht nicht dem Yield Total. Es weicht 1% ab. Ich würde sagen, das YieldTotal eben die Gesamtenergie der SolarPanele ist. Laut Datenblatt haben die Hoymiles auch einen Wirkungsgrad in dem Bereich - 99%. Rechnen bringt mir leider nicht viel, da ich einen totalen Wert (immer steigend) brauch (auch nach einem Neustart). Was man simulieren könnte, wäre das ich 1% vom Yield Total abziehe und diesen Wert dann als AC Energy Total nutze. Anbei ein Screenshot wo man den Unterschied zwischen AC und DC sieht. Marcel
:
Bearbeitet durch User
Hallo Thomas B., ja das ist noch ein zusätzliches Grund. Ich dachte nur daran was es für Werte mit den niederwertigen Daten aus Paket 2 ohne die höherwertigen Daten aus Paket 1 ergibt, bzw. wie man diese zwischenspeichert bis das zweite Paket auch da ist. In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. @Lukas P. da könnte der Link zur State-Machine vielleicht nochmal hilfreich sein: https://hackaday.com/2015/09/04/embed-with-elliot-practical-state-machines/
IsnoAhoy schrieb: > In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, > [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn > alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) oder einen Gesamt-CRC. Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu anderen Messeinrichtungen? Ich messe mit einem selbst programmierten Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung. Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh gemessen hat. Das enspricht einer Abweichung von ca. 4%. Wenn ich die aktuelle Leistung vergleiche, dann sind beide Messungen bis 100W nahezu identisch, bei 1000W habe ich schon eine Abweichung von knapp 100W. Danke für den State-Machine Link - sehr schön beschrieben. Ungefähr bei der hälfte habe ich schon an Funktionpointer gedacht ;-) @ESP8266: neue Version 0.3.3 liegt im Git. Umstellung von Ticker zu millis(), Visualisierung zeigt jetzt alle bekannten Werte.
:
Bearbeitet durch User
Lukas P. schrieb: > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Ich messe mit einem selbst programmierten > Sonoff POW R2, kalibriert auf eine 60W Glühbirne, die Solarleistung. > Heute hat der Hoymiles 1929Wh gemessen, während mein Sonoff 2014Wh > gemessen hat. Das enspricht einer Abweichung von ca. 4%. Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% Abweichung.
Hallo Lukas, > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Also ich messe mit einem ESP und einem PZEM-004T mit Stromklemme. Ich hatte die Werte damals mit einer Fritz! Steckdose verglichen und die stimmten immer sehr genau. Jetzt, wo wir die Werte vom Hoymiles haben, sehe ich, dass die ziemlich die gleichen sind, wie gemessen. Ich werde die aber mal demnächst genau übereinander legen. Hab seit heute alle Daten in HomeAssistant. Das einzige was ich sagen kann ist, das die Totalsumme 1% abweicht. Da vermute ich aber, dass dieses nicht die AC Leistung ist sondern DC. Marcel
Hallo Leute, Vielen dank für die neue Version. Die 0.3.2 läuft stabil mit dem Wemos. MQTT läuft auch reibungslos. Einen Wunsch hätte ich noch, wenn die Verbindung zum Wechselrichter nach Sonnenuntergang abreißt bleiben die letzten Werte noch im Webinterface und in MQTT stehen. Ist es möglich die Werte nach Sonnenuntergang wenn zb. 10 Minuten lang keine Werte kommen auf 0 zu setzen? Außer natürlich die Ertragswerte… Vielen Dank
Lukas P. schrieb: > IsnoAhoy schrieb: >> In der Tat sollten wir die komplette Sequenz von 0x01, [0x02], …, >> [0x0x], 0x8y zwischenspeichern und nur dann weiter verarbeiten, wenn >> alle Pakete mit passender CRC-8 und CRC_M/CRC-16 vollständig sind. > > Das hilft aber nicht das Problem zu umgehen, das @tbnobody beschrieben > hat, da auch hier wieder nicht alle Pakete gleichzeitig kommen. Evtl. > geht das eher über einen Plausibilitätscheck (keine zu großen Sprünge) > oder einen Gesamt-CRC. Das ist richtig. Hilft nicht gegen nicht empfangene Pakete. Andere Baustelle. Soweit verschlechtert das sogar die Empfangsrate, ist aber für den HM-600 zwingend notwendig, weil z.B. der DC kWh total von String 1 sehr sicher genau fragmentiert ist. Vorab, die fragmentierten Werte aus verschiedenen Requests zusammen zu stückeln ist nicht möglich, weil bei einer Werteänderung über das Fragment hinaus zu unterschiedlichen Zeiten sehr falsche Werte heraus kommen. Also kein Cache einzelner Fragmente (cmd'd) möglich! Man kann allerdings versuchen trotzdem irgendwie Werte zu retten, die nicht über mehrere Fragmente verteilt sind. Währe aber sehr viel Aufwand. Die Fragmente werden darüber henaus auch nicht in der richtigen Reihenfolge empfangen. Ich werde die Tage noch ein PR für ein Rewrite der Python-Implementierung einreichen. Ich bin gerade dabei das in Klassen und ein Hoymiles Modul zu zerlegen, so kann man dann damit besser Tinkern oder z.B. auch mal ein Logfile mit Rohdaten durch pipen. Und soweit ich das sehe ich das letzte byte in den 0x8n-Responses die crc8 über die zusammengesetzte Payload. Jedenfalls stimmt das verdächtig zuverlässig. Also der Ansatz mit den cmd's und channeln ist damit mal begraben, würde ich sagen. Das wars jetzt mit dem Wochenende. Ist eh vorbei :) Gruß, Jan
Martin G. schrieb: > In manchen Programmen war/ist auch immernoch das "AutoACK" > eingeschaltet. Auf der Suche nach Gründen, warum der ESP8266 oft hängt bzw. einen Watchdog-Reset auslöst habe ich auch folgendes interessante Detail gefunden: [[https://github.com/nRF24/RF24/issues/244#issuecomment-357210585]] AutoACK sollte demnach am besten aus sein. Es gibt wohl (gefälschte) NRF-Chips, welche damit Probleme machen. Allerdings ist AutoACK bereits bei den hier verwendeten Tools (esp8266, NRF24_SendRecv) aus. > Btw. Wie empfindet ihr die gemessenen Daten des Hoymiles im Gegensatz zu > anderen Messeinrichtungen? Bei meinem HM-400 sind YieldTotal/YieldDay recht nah an meinem SonOff Pow R2 (ebenfalls mit 60W, oder waren es 100W Glühlampe?, kalibriert.) Der HM-Wert ist leicht höher. Hier sollte man aber am besten einen kalibrierten Wechselstromzähler als Vergleich nehmen. Die Kalibrierung der SonOff könnte da nicht so gut sein. Es scheint also weiter unklar, ob YT und YD beim 400er nun AC oder DC Werte sind. Mit Blick auf die 600er/1200er müssten es ja auch DC-Werte (Modulwerte) sein. Entweder die Typen sind da komplett unterschiedlich zu bewerten oder es fehlt generell der AC Wert für YT/Yx. Idee: Anhand der DC Werte für P kann man ja YT/YD für einen bestimmten Zeitraum selbst berechnen und dies mit dem ausgelesenen Werten YT/YD vergleichen. Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher sein, da der WR in die Begrenzung geht und damit bei AC weniger "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert anliegt, da Begrenzung). Ich rechne das mal für den 400er YD/YT Wert nach.
Lukas P. schrieb: > Sorbit schrieb: >> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen >> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? > > Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier > angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP > auf die /setup Seite gehen und dort alles konfigurieren. Das ist supernett, danke! Ich probier es ASAP aus. BG
Nomen est Omen schrieb: > Lukas P. schrieb: >> Sorbit schrieb: >>> Mag bitte jemand einen ohne Fehler compilierbaren Sourcecode für einen >>> ESP 8226 mit NRF zur Verfügung stellen, oder ESP 32…? >> >> Habe den aktuellen Git-Stand mal als Version 0.3.2 kompiliert und hier >> angehängt. Sobald die FW auf deinem ESP8266 ist, kannst du über die IP >> auf die /setup Seite gehen und dort alles konfigurieren. > > Das ist supernett, danke! > > Ich probier es ASAP aus. > > BG Sorry für den faschen Namen, ich bin an einem anderen Rechner in einer anderen "Welt"... Richtig wäre Sorbit, gewesen. Der Ersteller des Threads, der sich wundert was er hier "angestellt" hat. Toll welcher Enthusiasmus sich hier verbreitet hat! Hut ab
Peter L. schrieb: > Bei mir heute (HM-1200, 3 Panels angeschlossen) insgesamt 3,82 kWh laut > AHOY (0.3.2), und 3,743 kWh mit Fritz 210 gemessen, also etwa 2% > Abweichung. Ich habe hier einen Sonoff Dual R3, um den Ertrag meines HM-600 zu messen. Kalibriert habe ich damals mit einer 60W Glühbirne. Bei mir sind es heute bisher 1,318 kWh (Sonoff) und 1,426 kWh (AHOY 0.3.3). Bei den gemessenen Watt liegt der Sonoff aktuell (keine Voll-Last) jeweils ca. 10-20 Watt unter dem per AHOY gemessenen Wert. Marcus schrieb: > Auch müsste YT/YD (wenn DC) bei guter Sonneneinstrahlung viel höher > sein, da der WR in die Begrenzung geht und damit bei AC weniger > "herauskommen" würde. Die Abweichung vom eigenen "Stromzähler" müsste in > dieser Zeit also höher sein als außerhalb (der momentane Power-Wert für > das Modul liefert bei guter Sonne so ca. 429W - was aber nie als AC-Wert > anliegt, da Begrenzung). Falls uns das hilft: Ich habe auch Zugriff auf eine zweite Anlage mit HM-600 und zwei "großen" Modulen, die bei guter Sonne regelmäßig in die Begrenzung des Wechselrichters laufen. Evtl. können wir durch die Beobachtungen ja das AC/DC Rätsel lösen.
Meine Anlage besteht aus HM-600 und 2 Module mit je 370 Wp, also 740 Wp. Der höchste gemessene Wert für die aktuelle Leistung war 612 W. Wenn das DC sein sollte müsste es schon mehr sein, m.E. Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal kurzzeitig (wie hier) drüber sein?
Hubi schrieb: > Macht ein WR wirklich bei genau 600 W dicht oder kann er auch mal > kurzzeitig (wie hier) drüber sein? Hallo, ich habe 700Wp an meinem HM600 und auf meinem shelly habe ich AC-seitig schon etwas über 600W gesehen. Meist so um die 620W. Lieder habe ich grade keine DC-Daten, da ich nicht mitlogge. Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich da. Carsten
> Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der > sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich > da. Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten zu empfangen. Den kannst Du entweder mit * Deinem D1mini (ESP8266/ESP32) und der ahoy Software unter tools/esp8266 (v0.3.2/3) von Lukas P.oder * einem Raspberry Pi und der ahoy Software unter tools/pi von Martin G. betreiben. Anleitung zur Verdrahtung des ESP findet sich unter https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben könnte. Dann müsste man sich nicht immer erst mit dem Access Point verbinden und könnte diese Settings hart verdrahten. Zumindest in der Entwicklungsphase würde mir das eine Menge Tipparbeit im WebInterface ersparen. Ich habe nämlich jetzt mehrfach den kompletten Flash erased, da ich hier Probleme bei der Umstellung des Speicher-Layouts der Konfigurationsdaten vermutet habe. Auch scheint er den Access Point aufzumachen, wenn er das lokale WiFi Netzwerk (wegen Empfang) nicht erreichen kann. Gibt es auch einen Fallback, daß er immer mal wieder versucht das Netzwerk zu erreichen ?
isnoAhoy schrieb: > @Lukas P., aus meiner Sicht wäre es nach wie vor schön, wenn man eine > config.h / einen Abschnitt in der defines.h hätte, in dem man bestimmte > Defaults für WiFi SSID, Password, EPS Name, Wechselrichter fest vorgeben ... Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update (Fehlerbehebung) sich nicht ändern. Ganz am Anfang dann die Länge von so einem Block. Darüber dann eine CRC bilden. Beim Neustart, dann die Länge aus dem EEPROM lesen. CRC abchecken und wenn so weit ok, dann mit den Werten starten ? Am Ende von so einem Block würde ich das so gestalten, das sich die Anzahl der WR ändern kann, evt. auch einzelne CRC s über WR Blöcke. Wenn sich dann jemand einen zusätzlichen WR kauft und einhängen will, kann alles so bleiben und er muss nur die SN / Typ des neuen WR eingeben. Dann wird der entsprechende Block am Ende drangehängt, mit einer CRC versehen und man kann weiter Software Updates machen ohne irgendwas einzugeben. Ist nur mal so eine Ideeeeeee :-)
Hallo zusammen, nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der ahoy.conf für einen HM-1500 (... [inverter] serial = 116173415022 ) ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 ahoy.py" leider den Anschiss ... ModuleNotFoundError: No module named 'RF24' Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit ... ModuleNotFoundError: No module named 'cross.crossunixccompiler' ... hängen. Ich habe darauf hin mit "sudo pip3 install cross" das umfassende Modul nachinstalliert, das ja dieses 'crossunixccompiler' enthalten sollte. Das ist auch ohne Fehlermeldung durchgelaufen. Es bleibt aber das Problem mit dem RF24, weil nach wie vor die Compilation von RF24 nicht durchläuft: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output. ERROR: Could not find a version that satisfies the requirement RF24 ERROR: No matching distribution found for RF24 Eine Suche nach "crossunixccompiler" war leider erfolglos, so dass ich da aktuell nicht weiter komme. Der Vollständigkeit halber: uname -a liefert: Linux raspberrypi 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 armv7l GNU/Linux Bliebe die Frage: Wo ist der Haken? Ergänzungs-Verständnisfrage zum Ahoy-Paket: Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann? Tschüssi, Petra
Vielen Dank für die zahlreichen Infos zu euren Vergeleichsmessungen. Jetzt habe ich einfach mal den Multiplikator meiner Kalibrierung (Sonoff) wieder auf 1.00 gestellt und habe jetzt identische Werte mit dem WR. Bei Gelegenheit werde ich nochmal mit einer Fritz! Steckdose gegenchecken. isnoAhoy schrieb: > Gibt es auch einen Fallback, daß er immer mal wieder > versucht das Netzwerk zu erreichen ? Das prüfe ich nochmal, sowas hatte ich mal im Sinn weiß aber nicht ob's hier implementiert ist. Finde ich auf jeden Fall sinnvoll. Herbert K. schrieb: > Ich hatte mir das gestern Abend angeschaut. Ich würde die Reihenfolge im > EEPROM etwas abändern. Vorne alle Daten, die bei einem Software Update > (Fehlerbehebung) sich nicht ändern. > Ganz am Anfang dann die Länge von so einem Block. > Darüber dann eine CRC bilden. Danke fürs Feedback. Ja hier ist noch Handlungsbedarf, ich weiß nicht mehr wie oft ich die Daten schon neu eingegeben habe. Ich werde es nochmal durchdenken und evtl. auch gleich umsetzen. Meiner Meinung sind nach der Aufteilung von WiFi und Sonstigen Settings (haben jeweils einen unabhängigen CRC) in getrennte Bereiche keine WiFi-Daten mehr verloren gegangen. (Klar da war noch der Issue mit der Passwortlänge, diese wurde auf 63 Zeichen angehoben)
Petra R. schrieb: > Hallo zusammen, > > nachdem am Samstag mein NRF24L01+ angekommen ist, habe ich den gestern > mal verdrahtet und an einen Raspi 3B angeschlossen. Nach Erstellen der > ahoy.conf für einen HM-1500 > (... > [inverter] > serial = 116173415022 > ) > > ... und dem Versuch, die notwendigen Python-Pakete jeweils mit "sudo > pip3 install ..." zu installieren, bekomme ich beim Aufruf von "python3 > ahoy.py" leider den Anschiss ... > > ModuleNotFoundError: No module named 'RF24' > > Ein "sudo pip3 install RF24" versucht zwar sein Bestes, bleibt aber mit > ... Hallo Petra, die Installation des RF24-Moduls ist leider etwas komplizierter. Ich habe versucht, das in https://github.com/grindylow/ahoy/tree/main/tools/rpi einigermaßen zu beschreiben. Im Prinzip sollte es reichen, der Anleitung für Python 3 auf * https://nrf24.github.io/RF24/md_docs_python_wrapper.html ...zu folgen. Wobei ich auf meinen beiden Raspis zuvor jeweils auch * https://nrf24.github.io/RF24/md_docs_linux_install.html ...gemacht habe. Bin mir aber nicht mehr ganz sicher, ob das wirklich notwendig ist. Einfach nur mit "pip" geht bei dieser Bibliothek wohl (noch) nicht. > Ergänzungs-Verständnisfrage zum Ahoy-Paket: > Habe ich das richtig verstanden, dass das discover-Programm die Hoymiles > wegen dieser Auto-ACK-Geschichte gerade nicht entdecken kann? Ja leider richtig. Das entstand, als wir noch der Annahme waren, dass die WR AutoACK aktiviert hätten. Schön wär's gewesen :-(. So findet es nur andere NRF24-Empfänger, die AutoACK aktiviert haben. Leider quasi nutzlos. -- petersilie
Ich habe jetzt wider Erwartens doch noch meine DTU-lite bekommen, und würde mal versuchen, sie in Betrieb zu nehmen. Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem Einrichtungsvorgang "zuhören"? Kanal 40? -- petersilie
Martin G. schrieb: ... > Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem > Einrichtungsvorgang "zuhören"? Kanal 40? ... > -- petersilie Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-) MOSI, MISO, usw. https://www.az-delivery.de/products/saleae-logic-analyzer Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom LA klar kommst, dann die PINs im DTU-Lite :-) so ist das gemeint von mir. Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als Hex anzeigen. Bin mir aber nicht mehr 100% sicher. Muss ja beim 1. Schuss am DTU-Lite zu 100% funktionieren - wir wissen ja nicht, was sich der alles merkt. :-) Den LA gibts natürlich auch bei anderen Anbietern.
:
Bearbeitet durch User
Herbert K. schrieb: > Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-) > MOSI, MISO, usw. Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner DTU festgestellt hatte: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E handelt, der einen eigenen Controller drin hat.
Erstmal für Seriennummernsammlung vorweg. HM-800 11417420xxyy HM-1500 11616320xxyy MI-1200 10616090xxyy Ich bin diesem Thread schon lange gefolgt, wollte mich aber erst melden, wenn ich Daten von meinen beiden Wechselrichtern empfangen konnte. Hatte mir das NRF24LE01+ mit externer Antenne gekauft und einige D1 mini V3, hatte jedoch nie Empfang. Kaufte verschiedene NRF24LE01+ und testete alle möglichen Kombinationen durch. Erst als ich D3 und D4 auf D1 und D2 umverdrahtete, mit der entsprechenden Setup-Änderung, konnte ich problemlos alles empfangen. Vielleicht kann sich einer von euch einen Reim darauf machen, warum D3, D4 bei mir nicht funktionieren. -- olaf
isnoAhoy schrieb: >> Ich habe leider etwas den Anschluss zum Projekt verloren. Was ist denn der >> sinnvollste Setup, mit dem ich wieder einsteigen könnte? D1mini habe ich >> da. > > Auf jeden Fall benötigst Du einen nRF24l01+ (plus ist wichtig!) um Daten > zu empfangen. Hallo, danke für den Input. Mit einem Arduino nano hatte ich hier ja Anfangs schon Daten mitgeloggt... Dann schau ich mal, ob ich es heute Abend vielleicht auf dem ESP zum laufen bekomme. Carsten
martin schrieb: > Herbert K. schrieb: ... > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E > handelt, der einen eigenen Controller drin hat. ... Entschuldigung ! Daran hatte ich nicht mehr gedacht.
Angehängte Dateien:
-
rx_tx.jpg
180 KB
Hallo martin & Herbert, > > Herbert K. schrieb: > ... > > Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E > > handelt, der einen eigenen Controller drin hat. > ... > Entschuldigung ! Daran hatte ich nicht mehr gedacht. Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal anbei. Eventuell könnte man auch mit dem openocd Debugger am SWD Port den GD32F303 anhalten und Flash Programm, etc. genauer analysieren. Es gibt m.W. eine eigene target/gd32f30x.cfg mit der es m.E. nach bei mir funktioniert hat den GD in einem MH-Z19C Sensor anzusprechen. https://github.com/gd32-rs/gd32-openocd/blob/master/target/gd32f30x.cfg Bei einer schnellen Suche nach "openocd gd32" kamen gerade noch die folgenden beiden evtl. interessanten Links heraus: https://registry.platformio.org/tools/communitygd32cores/tool-openocd-gd32 https://github.com/stlink-org/stlink/issues/769 Wobei ich in meinem Fall keinen Erfolg mit dem bestehenden target/st-linkv2.cfg hatte.
Martin G. schrieb: > Was denkt ihr, auf welchem Kanal sollte ich denn am Besten dem > Einrichtungsvorgang "zuhören"? Kanal 40? Ideal wäre halt eine breitbandige Aufzeichnugsmöglichkeit mit einem HackRF oder ähnlichem besseren SDR, da ja mehrere Frequenzen in Frage kommen. Ich hab meine Aufzeichnungen mit einem BladeRF gemacht, der macht dann ca 60 Mhz Bandbreite. Vorhanden ist bei mir u.a. der LimeSDR , BladeRF, HackRF. Oder evtl reicht auch ein NRF24L01-Sniffer, der zuverlässig die in Frage kommenden Frequenzen abscannen kann. Durch die Sende-Wiederholungen gibts da normal keine Zeitprobleme.
:
Bearbeitet durch User
isnoAhoy schrieb: > https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md > > Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den > ESP8266 zu kompilieren. Prüfe mal folgendes: > * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support > herunterladen) > * die beiden RF24 und TimeLib Bibliotheken im Library Manager > installieren. > @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der > ESP8266 Boards Umgebung ? > > Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem > o.g. Github aufmachen, damit wir die Dokumentation erweitern und die > Schritte die Dir fehlen nachreichen ? @ Lukas, @isnoahoy, der Geier weiß warum; Erfolg;-) Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen und nun läuft der Compiler fehlerfrei durch!!! DANKE!!!
Sorbit schrieb: > isnoAhoy schrieb: >> https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md >> >> Dort sollte eigentlich alles vermerkt sein, was notwendig ist um den >> ESP8266 zu kompilieren. Prüfe mal folgendes: >> * Boards Manager erweitert auf ESP8266 (URL Eintragen und Board Support >> herunterladen) >> * die beiden RF24 und TimeLib Bibliotheken im Library Manager >> installieren. >> @Lukas P. brauchen wir auch die Ticker Bibliothek oder ist die Teil der >> ESP8266 Boards Umgebung ? >> >> Damit sollte alles gehen, ggf. kannst Du ja auch noch ein Issue auf dem >> o.g. Github aufmachen, damit wir die Dokumentation erweitern und die >> Schritte die Dir fehlen nachreichen ? > > @ Lukas, @isnoahoy, > > der Geier weiß warum; Erfolg;-) > Ich habe meinen Sketchordner gelöscht, alles neu aus dem Repo geladen > und nun läuft der Compiler fehlerfrei durch!!! > > DANKE!!! Ich habe den NRF noch nicht angeschlossen (verdammt wo liegt der rum?) Mit dem AP kann ich mich verbinden, anpingen, Webseite bleibt aber leer. Ich denke das ist "normal" so wenn der NRF noch nicht dranhängt? Danke, ich suche weiter...
Sodele,
ich habe jetzt das ahoy.py auf einem Raspi 3B mit einem HM-1500 zur
Kommunikation bekommen und sehe erste Returns:
2022-05-03T07:20:30.553251Z MSG src=73415022, dst=73415022, cmd=1:
{"ts_unixtime": 1651555230.553251, "isodate":
"2022-05-03T07:20:30.553251", "rawdata": "95 73 41 50 22 73 41 50 22 01
00 01 01 4e 00 1a 00 14 00 56 00 42 00 00 08 0b c3", "crc8_valid": true,
"mid": 149, "response_time_ns": 18257366, "ch_rx": 3, "ch_tx": 40,
"src": "73415022", "name": "dcdata", "dst": "73415022", "cmd": 1,
"u1_V": 33.4, "i1_A": 0.26, "p1_W": 2.0, "u2_V": 8.6, "i2_A": 0.66,
"p2_W": 0.0, "p_W": 2.0, "unknown1": 1, "unknown2": 2059}
2022-05-03 09:20:30.601844 Received 27 bytes on channel 3 pipe 1: 95 73
41 50 22 73 41 50 22 02 00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c
e3
2022-05-03T07:20:30.602257Z MSG src=73415022, dst=73415022, cmd=2:
{"ts_unixtime": 1651555230.602257, "isodate":
"2022-05-03T07:20:30.602257", "rawdata": "95 73 41 50 22 73 41 50 22 02
00 00 0b 7b 00 0c 00 09 01 4e 00 17 00 15 00 4c e3", "crc8_valid": true,
"mid": 149, "response_time_ns": 67262961, "ch_rx": 3, "ch_tx": 40,
"src": "73415022", "name": "acdata", "dst": "73415022", "cmd": 2, "u_V":
2.3, "f_Hz": 0.21, "p_W": 7.6, "wtot1_Wh": 0, "wtot2_Wh": 12,
"wday1_Wh": 9, "wday2_Wh": 334, "uk2": 2939}
So ganz glauben tu' ich den Werten allerdings noch nicht. :-)
Nicht mal u1_V und i1_A: Auch wenn die Sonne gerade nicht prall auf das
180 W_p Modul scheint, sollten da doch etwas mehr als 0,26 A bzw. 2 W
kommen, oder?
Fragt sich jetzt, wie ich den Interpretations-Gurus unter euch
bestmöglich in die Seite treten kann?
Noch eine Beobachtung, den Raspi betreffend: Wenn ich den (aus
Stöpsel-Faulheit) nur per WLAN anspreche, scheint der des Öfteren hängen
zu bleiben. Nach Anschluss per LAN-Kabel scheint dies nicht mehr
aufzutreten. Kann es sein, dass dessen WLAN und der nRF24 sich
gegenseitig beim Funken ins Gehege kommen?
Tschüssi,
Petra
Robert Bleumer schrieb: > Steht upload nach PvOutput.org noch auf's Programm? Ich denke aktuell liegt das Hauptaugenmerk noch auf dem korrekten auslesen der Daten. Aber später gibt es bestimmt die Möglichkeit, eine Anbindung zu PvOutput.org einzubauen. Die Doku dazu sieht relativ ausführlich aus, sodass es denke ich gut machbar wäre. https://pvoutput.org/help/index.html
Hallo Martin, danke schön für deine Erklärungen! Mittlerweile läuft's ja, wie man an meinem letzten Post sehen kann. thumbs_up > Im Prinzip sollte es reichen, der Anleitung für Python 3 auf > > * https://nrf24.github.io/RF24/md_docs_python_wrapper.html > > ...zu folgen. Das habe ich gemacht, bin aber auf einige Ungereimtheiten in der Abfolge gestoßen. Dies nur als Warnung für Nachfolgende, die es nach dieser Anleitung wortwörtlich probieren. Letztlich muss ich übrigens das ahoy.py auch mit sudo aufrufen, sonst will es nicht. Irgendwie scheine ich mich aber insgesamt wohl durchgewurschtelt zu haben. ;-) Viele Grüße, Petra
Guten Morgen ! Wie und wann und unter welchen Umständen die Kanäle gewechselt werden weiss ja scheinbar noch niemand (oder doch?). Nur mal so als Idee: Die NRF24L01+ Module kosten ja nicht die Welt. Was spricht denn gegen den Einsatz von 5 Stk. - jedes auf einem festen Kanal ? Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ?
Moin, ich baue ja in der Python-Implementierung am empfang der vollständigen Payload vom Wechselrichter. Weil noch sehr "work in progress" gibts da noch kein PR zu. Nur so zur Info. Oben schrieb ich, die Zusammengesetzte Payload ist mit der crc8 im letzten byte der Payload der 0x8n-Fragmente signiert. Es ist jedoch ModbusCRC. Definitiv. Ich hab das bei mir so nebenbei laufen und bekomme sehr gute Ergebnisse. Zur Zeit ist nur der HM-600 implementiert, weil der mit dem Ansatz des Auswertens von Payload-Fragmenten eben nicht vollständig lesbar ist. Was anderes habe ich nicht. Was ich vor dem PR noch tun will: * Dekoder neu implementieren (bloß schnell hin gepfuscht als Beiwerk zum PoC) * PayloadBuilder bauen * Inverter-Klasse als Interface * Multi-Inverter Wie in der test.py zu sehen ist, lassen sich damit auch Logfiles mit Rohdaten neu auswerten. Sehr gut zum nachts entwickeln. ;) https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi (Preview, wird sicher noch ein paar mal amended) Der Output läuft bei mir aus Faulheitsgründen in eine vergleichbare Topic-Struktur, wie auch Shelly sie verwendet. Damit frisst der telegraf das gleich in die richtigen Influx measurements weg. Gruß, Jan
Ich hätte da mal eine grundsätzliche Frage: beim Nordic Protokoll, dass die Daten seriell fliessen ist schon klar aber wird da eigentlich MSB oder LSB zuerst geschickt? Ich dachte bisher immer MSB first, aber das passt überhaut nicht mir der Anzeige meines LA (SALEAE/Sigrok) zusammen. Die Anzeige meines DSO (Batronix Rigol DS1054Z, alle Optionen freigeschaltet) decken sich damit auch nicht. Ich habe schon probiert wie wild, komme damit aber nicht so recht weiter. Wer kann helfen?
Herbert K. schrieb: > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ? Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme vermissen.
> > Senden hauptsächlich auf 1 Modul, "mithören" auf den 4 anderen Modulen ? > Sowas geht natürlich auch jederzeit. dann sollte keiner Telegramme > vermissen. Das hatte Oliver F. bereits am 16.04.2022 auf Seite 3 mit einem hübschen Modell mit insgesamt sechs NRF24L01+ vorgeschlagen. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" @Oliver F., was ist denn daraus geworden ?
Angehängte Dateien:
Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana visualisiert. Anbei einige Diagramme. Die AC-Leistung stimmt mit meiner Kalibrierten Sonoff Steckdose bis auf wenige Watt Unterschied überein. Danke und großes Lob an alle.
Angehängte Dateien:
-
grafana_2h.png
140 KB -
grafana_today.png
120 KB
Mich@ schrieb: > Hallo Leute, heute hab ich mal die Daten aus AHOY in Grafana > visualisiert. Anbei einige Diagramme. Netter Versuch :) Anbei mal Ausschnitte aus meinem Dashboard. Die zugehörige Telegraf-Config hab ich oben mal gepostet. Das Dash braucht Influx2 (Flux) Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus dem HM600 raus geholt. Request 80 02 + time
1 | 2022-05-03 20:27:56.781439 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 2c 00 00 00 05 00 00 00 00 86 3c 79 |
2 | 2022-05-03 20:27:56.844744 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
3 | 2022-05-03 20:27:56.887237 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
4 | 2022-05-03 20:27:56.935143 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
5 | 2022-05-03 20:27:56.977203 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
6 | 2022-05-03 20:27:57.025358 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
7 | 2022-05-03 20:27:57.073432 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
8 | 2022-05-03 20:27:57.115671 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
9 | 2022-05-03 20:27:57.163807 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
10 | 2022-05-03 20:27:57.211908 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
11 | 2022-05-03 20:28:05.613912 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 35 00 00 00 05 00 00 00 00 16 9b 57 |
12 | 2022-05-03 20:28:05.689287 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
13 | 2022-05-03 20:28:05.737622 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
14 | 2022-05-03 20:28:05.785561 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
15 | 2022-05-03 20:28:05.827717 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
16 | 2022-05-03 20:28:05.875809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
17 | 2022-05-03 20:28:05.923963 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
18 | 2022-05-03 20:28:05.966142 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
19 | 2022-05-03 20:28:06.014271 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
20 | 2022-05-03 20:28:06.056376 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
21 | 2022-05-03 20:28:13.833624 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 3d 00 00 00 05 00 00 00 00 d6 fc f8 |
22 | 2022-05-03 20:28:13.890903 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
23 | 2022-05-03 20:28:13.939259 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
24 | 2022-05-03 20:28:13.981286 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
25 | 2022-05-03 20:28:14.029283 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
26 | 2022-05-03 20:28:14.071458 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
27 | 2022-05-03 20:28:14.119636 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
28 | 2022-05-03 20:28:14.167809 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
29 | 2022-05-03 20:28:14.209973 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
30 | 2022-05-03 20:28:14.258033 Received 23 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
31 | 2022-05-03 20:28:40.145516 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 58 00 00 00 05 00 00 00 00 84 6b 58 |
32 | 2022-05-03 20:28:40.214575 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
33 | 2022-05-03 20:28:40.262608 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
34 | 2022-05-03 20:28:40.304763 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
35 | 2022-05-03 20:28:40.352869 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
36 | 2022-05-03 20:28:40.401014 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
37 | 2022-05-03 20:28:40.443199 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
38 | 2022-05-03 20:28:40.491307 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
39 | 2022-05-03 20:28:40.533532 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
40 | 2022-05-03 20:28:40.581560 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
41 | 2022-05-03 20:28:42.355754 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5a 00 00 00 05 00 00 00 00 e4 72 23 |
42 | 2022-05-03 20:28:42.454595 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
43 | 2022-05-03 20:28:42.490861 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
44 | 2022-05-03 20:28:42.526965 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
45 | 2022-05-03 20:28:42.592729 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
46 | 2022-05-03 20:28:42.629048 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
47 | 2022-05-03 20:28:42.671269 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
48 | 2022-05-03 20:28:42.719446 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
49 | 2022-05-03 20:28:42.791353 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
50 | 2022-05-03 20:28:42.839432 Received 23 bytes channel 3: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
51 | 2022-05-03 20:28:44.815962 Transmit | 15 72 22 01 43 78 56 34 12 80 02 00 62 71 74 5c 00 00 00 05 00 00 00 00 44 59 ae |
52 | 2022-05-03 20:28:44.885060 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 0a 00 20 01 00 0c 08 fc 07 a3 00 0f 09 e2 00 1e 19 |
53 | 2022-05-03 20:28:44.933349 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 06 4a 00 14 0a 55 00 14 0a c8 00 0a 09 e2 10 03 b4 |
54 | 2022-05-03 20:28:44.975352 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 13 88 12 c0 00 14 13 ec 00 14 12 8e 00 05 14 50 fd |
55 | 2022-05-03 20:28:45.029316 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c 1c |
56 | 2022-05-03 20:28:45.071513 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 13 56 40 00 07 d0 00 10 50 01 00 01 13 9c 01 90 1c |
57 | 2022-05-03 20:28:45.113829 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 00 10 00 00 60 00 00 01 09 e2 0a 5a 02 15 80 01 cf |
58 | 2022-05-03 20:28:45.161987 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 07 00 00 08 5b 01 2c 08 b7 09 41 09 9d 01 2c 00 64 c6 |
59 | 2022-05-03 20:28:45.210197 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 3a |
60 | 2022-05-03 20:28:45.252331 Received 23 bytes channel 23: 95 72 22 01 43 72 22 01 43 89 00 01 27 10 a0 02 00 00 00 00 cb fe bd |
Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche Transaktionen mit valider crc über die 140 byte. Viel Spaß beim dechiffrieren *duckundweg Eine Antwort auf 80 0b "Zeit setzen" sieht zum Vergleich so aus:
1 | 2022-05-03 20:27:07.155080 Transmit | 15 72 22 01 43 78 56 34 12 80 0b 00 62 71 73 fb 00 00 00 05 00 00 00 00 a0 3f 85 |
2 | 2022-05-03 20:27:07.219066 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 24 00 04 00 0b 01 25 00 04 00 0c 00 00 93 |
3 | 2022-05-03 20:27:07.267618 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 97 5f 00 00 8e 5f 07 b2 07 b9 08 e2 13 8a 00 00 f6 |
4 | 2022-05-03 20:27:07.316231 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 00 00 00 00 ca 00 06 0a 1b cb |
5 | 2022-05-03 20:27:07.316231 Decoded: 44 string1= 29.2VDC 0.04A 1.1W 38751Wh 1970Wh/day string2= 29.3VDC 0.04A 1.2W 36447Wh 1977Wh/day phase1= 227.4VAC 0.0A 0.0W inverter=114172220143 50.02Hz 20.2°C |
Gruß, Jan
@ahoy, Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf der Konfig Seite kleben..
Hallo Freunde, solange ihr noch aktiv am Loggen und Entschlüsseln der CMD´s seit, möchte ich euch nochmal an ein in den Hintergrund gerücktes aber wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft werden oder hier wichtige Leute abspringen: Es wäre toll, wenn ihr herausfindet, wie sich die Wechselrichter in der Leistung limitieren lassen, pro Kanal muss nicht unbedingt sein, die Gesamtleistung wäre schonmal ein sehr guter Anfang. (am besten diesen Thread nach "limit" durchsuchen, um die bisherigen Informationen dazu zu finden) Dann hätten wir endlich mal einen qualitativ hochwertigen Wechselrichter zum guten Preis/Leistungsverhältnis, der an einen kleinen Speicher angeschlossen werden kann, um z.B. die Grundlast oder zumindest ein Teil davon nachts mit dem Speicher zu decken. Es gibt bereits ein älteres Projekt aus dem photovoltaikforum mit dem MI-300 und neuerdings auch ein Update mit dem HM-800 (und natürlich baugleiche Modelle in den jeweils 3 Leistungsstufen), bei dem vorsichtig ein Loch an der richtigen Stelle in das Gehäuse gebohrt werden muss und mit einer kleinen Schaltung per PWM über einem Operationsverstärker ein falscher Strommesswert vorgegaukelt wird, so kann man den WR also auch regeln. Das hat natürlich den Nachteil, dass man etwas basteln muss und die Garantie weg ist. Gut, als Batteriewechselrichter sind die auch nicht gedacht, also wie es da mit der Garantie aussieht ist fraglich, aber sie sind zumindest geeignet und man lässt den ja auch nicht permanent mit 100% laufen, sondern regelt ihn ja dann intelligent je nach Bedarf oder Speicherfüllung. Diese guten Mikrowechselrichter sind jedenfalls besser als der Chinaschrott, der ähnlich viel kostet und noch dazu größer, lauter und ineffizienter ist. Es wäre daher toll, wenn quasi die gleiche Regelung per Funk einfach möglich ist. Deshalb würde ich euch darum bitten, dieses Signal mal zu sniffen und zu implementieren. Aber schonmal ein großes DANKE an alle, für eure bisherige tolle Arbeit, gemeinsam bekommen wir den Rest auch noch implementiert! Sonnige Grüße, Andi
Andi schrieb: > möchte ich euch nochmal an ein in den Hintergrund gerücktes aber > wichtiges Thema aufmerksam machen, bevor die DTU´s wieder verkauft > werden oder hier wichtige Leute abspringen: wozu willst den WR regeln? Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, bringt paar Euro Eine Abregelung macht nur wegen der 70% Grenze- die eh keinen Interessiert - Sinn - oder wenn man den WR als Batterie-WR nutzen möchte
> wozu willst den WR regeln? > Der soll so viel wie möglich bringen- der Überschuss geht ins Netz, > bringt paar Euro > Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein hat.
> Es wäre toll, wenn ihr herausfindet, > wie sich die Wechselrichter in der > Leistung limitieren lassen, pro > Kanal muss nicht unbedingt sein, die > Gesamtleistung wäre schonmal ein > sehr guter Anfang. (am besten diesen > Thread nach "limit" durchsuchen, um > die bisherigen Informationen dazu zu > finden) > Es wäre daher toll, wenn quasi die > gleiche Regelung per Funk einfach > möglich ist. Deshalb würde ich euch > darum bitten, dieses Signal mal zu > sniffen und zu implementieren. Hallo Andi, das ist in der Tat ein interessantes und mE wichtiges Thema. 1. Zero Export Restrictions Mode Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU setzen. > 4.1 Work Mode (page 9) > Normal: In this mode, the microinverter operates normally and converts DC power into AC power to support the household loads and feeds into the public grid. > Zero Export Control: In this mode, the microinverter’s generation is limited based on the current household loads, and there is no extra power fed into the public grid. > Standby: There are several circumstances in which the microinverter will be in Standby mode: > • The current condition contradicts with the microinverter operating requirements. > • No household loads or the export control value has been set as “0” on the DTU in the Zero Export Control mode. 2. Grid Power Profile Zusätzlich gibt es noch ein sog. Grid Profile in der DTU/Hoymiles Cloud. Ich weiß aber nicht ob man das zB von AT auf DE oder PT ändern kann… Es wird u.a. auf den Screenshots von Enercab bzw in deren Hoymiles Cloud ausgegeben. > Grid Profile Version: 2.0.0 (AT_TOR_Erzeuger_default) 3. Als drittes ist mir in den Fehlercodes des HM-600/700/800 (6.1 Troubleshooting List, page 14ff) aufgefallen, dass es u.a. auch einen Code „149 Island detected“ gibt. Einige dieser Fehler sollte man ja ggf. Provozieren und auslesen können. 4. Communication with DTU changes Status LED Indicator > 6.2 Status LED Indicator > The LED flashes five times at startup. All green flashes (1s gap) indicate normal startup. > Status LED > (1) Startup Process > • Five green flashes (0.3s gap): Startup success > • Five red flashes (0.3s gap): Startup failure > (2) Running Process > • Fast green flashing (1s gap): Producing power. > • Slow green flashing (2s gap): Producing power, but one input is abnormal. > • Slow green flashing (4s gap): Producing power, but there is no communication with DTU. > • Red flashing (1s gap): Not producing power, AC grid fault (voltage or frequency out of range). > • Red flashing (0.5s gap): Non-grid abnormality fault. > (3) Other Status > • Alternating red and green flashing: Firmware is corrupted. > *Note: All faults are reported to the DTU, refer to the local DTU app or S-Miles Cloud (Hoymiles Monitoring Platform) for more information. https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_HM-600700800_Global_EN_V202203.pdf
Sorbit schrieb: > Na weil man dann die gesamte Bürokratiekeule nebst Finanzamt am Bein > hat. IsnoAhoy schrieb: > 1. Zero Export Restrictions Mode > Laut Dokumentation der HM-600/700/800 Wechselrichter kann man den sog. > Zero Export Control Mode (Default an: 1?) per Hoymiles Cloud bzw DTU > setzen. kann es sein das hier die 70%-Regelung (harte/ weiche Abregelung) durcheinander gebracht wird? Für den Zero Export Control mode reicht es sicher nicht diesen zu setzen - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU regelt die WR dynamisch IsnoAhoy schrieb: > 2. Grid Power Profile Damit ist wohl die Einstellung des CosPhi gemeint
Heinz R. schrieb: > - an die DTU kommt ein Zähler für den Haushaltsverbrauch - die DTU > regelt die WR dynamisch Interessant wäre das schon. Leider können da nur die weiterhelfen, die auch die DTU-Pro haben vermute ich. Bei möglichen Fehlern (wie bei MODBUS erklärt), da sind wohl auch die DTU-Pro Besitzer gefragt ? Ich habe beim HM-350 und HM-400 mal auf DC-Plus und DC-Minus einen Kurzschluß zu "Erde" gemacht. Begonnen mit 100K Ohm bis herunter zu 0 Ohm mit verschiedenen Werten. Das hat beide nicht gejuckt. Weder Mitten im Betrieb, noch bevor sie mit dem PV Modul verbunden waren. Die gehen ganz Normal in Betrieb wie immer. Erwartet hätte ich einen "Isolationsfehler", ohne das sie in Betrieb gehen, wie z.B. bei den SMA WR. Bisher habe ich keine DTU-.... Grundsätzlich wäre auch erst mal Interessant, wer welche Fehlermeldungen über die DTU-... dann in der Cloud gesehen hat. So was wie falsche Netzfrequenz zu simulieren, wird schwierig.
:
Bearbeitet durch User
Sorbit schrieb: > @ahoy, > > Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat > und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? > Ich bleibe immer auf der Konfig Seite kleben.. Ahoy, wo bist DU ?;-)
Angehängte Dateien:
-
simple_raspi_hoymiles.jpg
180 KB
Hallo, ich habe mir vor ein paar Wochen 2 Balkonmodule vom Stromanbieter mit 2 (vermutlich HM-350) Wechselrichtern gekauft, und ahoy.py dafür angepasst, damit ich die Ergebnisse in den io-broker bekomme. Vielen Dank was da alles schon an Vorarbeit geleistet wurde! Softwareinstallation wie im repository beschrieben, hardware raspi4, Kabel aus https://www.amazon.de/gp/product/B078JGQKWP weil ich so die gleichen Farben wie in der Anleitung verwenden konnte 😊 und Radiomodul aus https://www.amazon.de/gp/product/B07PBBC4H9 (sind also NRF24L01+ und das + bezieht sich nicht auf die anderen Teile). Damit lässt sich das ohne Aufwand zusammenstecken. Habe mir das Forum von Anfang an durchgelesen und noch hoffentlich noch für HM300, HM450, HM600, HM700, HM-800, HM-1200, HM1500 support eingebaut, indem ich die ersten 4 Stelen der Seriennummer auswerte und entsprechend verzweige. Außerdem Support für mehrere Wechselrichter und etwas weniger Radio Noise nachdem das Programm nach einer Meldung 10 Sekunden wartet um einen Inverter der geantwortet hat nochmals zu fragen. Programm liegt in franzongit branch. Ich hoffe das erleichtert den Einstieg für technisch nicht so versierte. lg Franz
franz schrieb: > für HM300, HM450, HM600, HM700, HM-800, HM-1200, HM1500 support > eingebaut... Die alte ahoy.py, sowie das C-Projekt brauchen einen full-rewrite. Am Python bin ich gerade dran und bau da ein flexibles Modul draus, was im Idealfall so einfach instanzierbar ist wie der mqtt-client, und Framing, Fragmentierung beim senden einer arbiträr langen Payload, sowie Transport-Layer und Dekodierung übernimmt. Im Wesentlichen senden die Wechselrichter halt größere Payloads über mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die längste Payload, die ich von einem HM600 empfangen habe ist 140 byte lang. Da die crc stimmt, confirmed. Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten. Ich gehe bisher davon aus, dass der Fragment-Zähler (ehem. cmd) von 0x01-0x80 zählen kann und 0x80-0xNN (0xNN = Fragment-Zähler größer 0x80) die Anzahl der Fragmente des Pakets angibt. Schon passt da eine ganze Firmware rein. Die einzelnen Fragmente isoliert zu verarbeiten ist ein Dead-End. Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet. Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was angefragt wurde, um die Payload dekodieren zu können. Wir sollten zukünftig also von: Fragmenten, Paketen, und Payloads sprechen. Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das Paket enthält die Payload. Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment + 1 byte crc Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc Jede Payload kann demnach max 2046 byte haben. Vermutung, abgeleitet aus den bisher bekannten Umständen. Man müsste jetzt mal schauen, ob man aus dem 1. byte Payload vielleicht Rückschlüsse auf den Inhalt der Payload gewinnen kann. Gruß, Jan
Hallo Sorbit, ich habe keine Ahnung wen Du mit Ahoy meinst. Ich glaube Martin G. / Petersilie hat das Logo gemalt und das Projekt so genannt ? Ich nenne mich isnoAhoy also eben nicht Ahoy :) > Funktioniert es auch, wenn der esp keine Verbindung zu einem WLAN hat und es nur eine WLAN Punkt zu Punkt ( Tablet <-> ESP ) Verbindung gibt? Ich bleibe immer auf der Konfig Seite kleben.. Das Problem habe ich auch. Das Programm macht beim Neustart mehrere Versuche das konfigurierte WLAN zu kontaktieren. Wenn es nicht klappt oder die Verbindung später abreißt dann kommt man ausser über den Serial Port oder ggf den AccessPoint nicht mehr an die Oberfläche. Lukas P. versucht das Problem einzugrenzen bzw zu beheben. Siehe auch: https://github.com/grindylow/ahoy/issues/15 Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Evtl. kann man in Zukunft die beiden Oberflächen vereinheitlichen und den Reconnect mit dem WLAN alle X Minuten einstellen oder per Serial Command forcieren?
@Heinz Ja, natürlich macht im ersten Moment eine Limitierung keinen Sinn, man verschenkt ja dadurch gratis Energie, wenn man Module dran hängen hat. Aber ich habe ja auch geschrieben, um ihn als günstigen und guten Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) Der beliebte Chinawechselrichter GTIL SUN-1000 bewegt sich auch in der Preisspanne des HM-800, allerdings ist der Wirkungsgrad davon schlecht und die Leistungssteuerung muss man sich auch mehr oder weniger selbst zusammen basteln mit z.B. elektronischen Poti. Noch dazu hat das Ding einen Lüfter der recht laut wird bei 1000W, hängt aber wohl damit zusammen, das die recht hohe Verlustleistung ja irgendwie gekühlt werden muss. Ein Victron Wechselrichter übersteigt die Kosten enorm und ist auch viel zu viel Leistung um die Grundlast über die ca. 10 Stunden Nacht zu decken. Lastspitzen lohnen sich nie die ausgleichen zu können, mit denen muss man leben, das darf ruhig der Stromanbiete rübernehmen, ist einfach am billigsten und macht Insgesamt nur einen kleinen Anteil der Autarkie aus. Das ich den HM-800 nicht permanent mit 800W betreiben sollte ist mir klar, aber darum möchte ich ihn ja auch begrenzen und um halt dynamisch die Grundlast nachts zu decken, die keine 800W beträgt. Böse Zungen würden jetzt sagen, das Netz ist der beste Speicher, das ist aber illegal und nur mit einem rückwärtsdrehendem Ferraiszähler möglich. Ich und viele andere haben bereits einen digitalen Zweirichtungszähler verbaut und der wird nach und nach bei allen kommen... Und ja, eine EIGENBAU PV-Anlage mit Batteriespeicher lohnt sich, aber es dauert natürlich ca. doppelt so lange bis die Investition wieder rein ist gegenüber nur Module + nötiges Zubehör. Einen Fertigspeicher oder am besten noch PV-Anlage montieren lassen würde ich auch nicht, da dauert es mal ebend locker 15+ Jahre bis das wieder rein ist, da die Kosten deutlich höher sind. Mit meinem Eigenbauprojekt komme ich auf knapp 6 Jahre(bei steigenden Strompreise, wovon auszugehen ist, noch eher und bevor die Kritiker kommen: gute LiFePo4-Akkus halten noch ein paar Jahre länger, wenn man die richtig betreibt). Ja ist eine ganze Weile, aber was will man machen, mehr Wp und Einspeisen rechnet sich noch weniger, davon holt man die Nacht auch nicht rein und auf die Bürokratie habe ich auch keine Lust... Außerdem selbst wenn man nach 6 Jahren rechnerisch bei +-0 ist, hat man immernoch die Hardware(Panel, Wechselrichter, Laderegler, Akku mit Restkapazität ...), die einen Restwert hat, beim Stromanbieter sieht man von seinem Geld nichts mehr wieder, das hat mich überzeugt, dieses Projekt zu starten. Warnung: PV macht süchtig! :D ...alles beginnt mit einem einfachen Balkonkraftwerk und nach dem ersten Jahr will man mehr. Aber zurück zum Thema: In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure Daten rankommt, aber leider auch nicht identisch ist), sind Register zu sehen, die dafür zuständig sind: https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf 0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit dem Protokoll zum WR aussieht, aber es muss ja alles über NRF funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70% Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer wieder zyklisch das aktuelle Limit geschrieben. Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur da das möglich bzw. freigegeben ist. Grüße
Angehängte Dateien:
Ich konnte der (esp8266) Anleitung sehr gut folgen und kann seit heute meinen HM-800 auslesen. Super wie schnell dies hier entwickelt wurde! Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry über MQTT. Mir sind zwei Dinge aufgefallen: 1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel vom Wert des 2. Channels sofort überschrieben. 2) In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der Channels. Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler wenn dieser Wert direkt angezeigt wird. Gruß Manuel
IsnoAhoy schrieb: > Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je > nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN > Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Im Prinzip ist alles gleich, nur dass im AP Modus standardmäßig auf die Setup Seite verwiesen wird. Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem WLAN zu verbinden. Achtung, einige Einstellungen gehen beim Upgrade verloren, das wurde noch nicht bearbeitet. Changelog = Git-Log (https://github.com/grindylow/ahoy/commits/main) Wie gewünscht sind jetzt alle Einstellungen, die zur Kompilierzeit gemacht werden können in einer config.h Manuel M. schrieb: > In der Web-Ansicht werden für beide Channels (blau) der Wert YieldDay > angezeigt. Im Übergeordneten Ansicht (grün) fehlt aber die Summe der > Channels. Sehr schön, dass es auf Anhieb geklappt hat. Ich verwende ioBroker als MQTT Server, dieser erstellt dann "Unterordner" da jedes Topic mit Slashes getrennt geschickt wird, z.B.: /inverter/hm1200/ch1/u_dc /inverter/hm1200/ch2/u_dc ... Bei mir wird hierdurch nichts überschrieben, da alles eindeutig und unique ist. > Das kann ich mir natürlich berechnen aber es ist denke ich komfortabler > wenn dieser Wert direkt angezeigt wird. Die Summe lässt sich recht einfach bilden, indem du in der hmDefines.h für den HM800 folgende beiden Zeilen hinzufügst (kopiert vom HM1200):
1 | { FLD_YD, UNIT_WH, CH0, CMDFF, CALC_YD_CH0, 0, 0 }, |
2 | { FLD_YT, UNIT_KWH, CH0, CMDFF, CALC_YT_CH0, 0, 0 }, |
Andi schrieb: > Aber ich habe ja auch geschrieben, um ihn als günstigen und guten > Batteriewechselrichter einzusetzen (da gibts nämlich nichts am Markt) Tolles Thema, gibt es hierzu auch ein Forum? Bin auch interessiert an einer Selbstbau-Speicherlösung. Wäre super wenn man hier eine ähnliche Community hätte wie diese hier, wobei bei Geschwindigkeit kann uns hier keiner was vormachen! ;-)
:
Bearbeitet durch User
Lukas P. schrieb: > Es gibt jetzt eine Version 0.3.6, die auch immer wieder versucht mit dem > WLAN zu verbinden. Super, wie schnell die Entwicklung voranschreitet! Habe die neue Version gleich installiert :-P Ist leider in mehreren Versuchen nur jeweils wenige Minuten erreichbar, WIFI wurde nur einmal aut. restarted. Nach welchem Zeitraum sollte das WIFI neustarten, muss ich länger warten? Ausserdem ist mir aufgefallen, dass nach dem aut. restart die MQTT Verbindung nicht mehr connected war. Wird die auch restarted? SG Robert
Herbert K. schrieb: > martin schrieb: >> Herbert K. schrieb: > ... >> Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E >> handelt, der einen eigenen Controller drin hat. > ... > Entschuldigung ! Daran hatte ich nicht mehr gedacht. Hatte schonmal jemand den Mut, seinen WR aufzuschrauben? Mit etwas Glück ist ja darin direkt ein NRF24L01+ verbaut anstelle des NRF24LE1E?
Lukas P. schrieb: > { FLD_YD, UNIT_WH, CH0, CMDFF, CALC_YD_CH0, 0, 0 }, > { FLD_YT, UNIT_KWH, CH0, CMDFF, CALC_YT_CH0, 0, 0 }, Danke - das klappt so - kann man das in der hmDefines.h für den HM800 so einchecken?
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > > Dann noch 2 Boni: Habe kurz vor Sonnenuntergang nochmal neue Daten aus > dem HM600 raus geholt. > > Request 80 02 + time > [code] .... 04 00 05 20 00 00 01 30 03 02 58 09 e2 07 a3 13 9c .... > Die Payload ist jeweils 140 byte lang. Hier sind nur erfolgreiche > Transaktionen mit valider crc über die 140 byte. Viel Spaß beim > dechiffrieren *duckundweg > Gruß, > Jan Hallo Jan, kann ich so bestätigen für HM-350/HM-400. Telegramm "04" sieht bei einem von meinen identisch aus. Telegramm "89" sieht bei einem von meinen anders aus bei einigen Bytes, einige sind identisch. Mehr habe ich noch nicht verglichen. Was auch immer das bedeutet. Ich lass das mal ne Zeit mitlaufen, ob sich da Werte ändern.
Hallo, Ich entschuldige mich für meinen deutschen Übersetzer Ich möchte einen externen MQTT-Server verwenden, jetzt kann ich die IP-Adresse angeben (1.2.3.4), kann ich Unterstützung für Hostnamen hinzufügen?
Jan-Jonas S. schrieb: > Im Wesentlichen senden die Wechselrichter halt größere Payloads über > mehrere Pakete (Fragmente). Ähnlich wie TCP, bloß mit mtu 16. Die > längste Payload, die ich von einem HM600 empfangen habe ist 140 byte > lang. Da die crc stimmt, confirmed. > Fragmentiert in 16 byte + 7 byte Protokoll-Overhead. Siehe oben. Es gibt > in den Daten keine cmd's. In den einzelnen Fragmenten gibts lediglich > einen Fragment-Zähler. Ohne Kontext kann man die nicht auswerten. ja, das ist sicher so, nur bei meinen kleinen 3xx geht/ginge sich alles in je einem Paket aus. Allerdings ist die python version schon so schlau, alle Antworten einer Sendung einzusammeln und dann hintereinander zu verarbeiten, somit konnte ich einbauen, mit globalen Variablen Daten zwischen 2 Fragmenten auszutauschen, ob es funktioniert, kann ich mangels entsprechender WR nicht testen. Ich nehme an, beim HM-600 ist das highword von total power 1 in 0x02 das letzte Word in 0x01, das das schon aufgetreten? Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich alles im 2. ausgehen, ist aber geteilt. Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder konstant oder springen. Ich erwische aber jedenfalls auch nicht alle Pakete, auch wenn ich 10 Sekunden Pause mache. Zumindest in 87% der Fälle wo ich die Antwort erwische, habe ich beide, so ich mit 40 sende. Bei 23 als Sendechannel ist es bei mir um 25% besser, allerdings erwische ich da ingesamt auch nur auf 40% der Sendungen eine Antwort, wobei auch wieder fast alle auf je 2 channels kommen (40 ->3,75, 23-> 61,75). Den in einem C source aufgeführten Channel 83 habe ich noch nie gesehen, in der DTU-W100 Doku für MI-... steht aber auch nur von 5 und nicht 6 Channels. Habe die von lbp beschriebene Logik zum Holen der Pakete nachimplementiert, war aber bei mir auch nicht besser. Ich denke auch, dass auf dem Channel für weitere Pakete bleiben wie zZ implementiert gar nicht zielführend ist, da nicht nach x-Paketen die Suche beendet wird, greift der Algorithmus aber sowieso zwischen Versendungen nicht. Auch aus Sicht des WR wäre es unklug alles auf je einen Channel zu setzen. Seine Beschreibung zum Nachfordern habe ich noch nicht versucht, diese Sonnenabhängigkeit ist eine echte Programmierbehinderung :-) lg, Franz
Hallo zusammen, ich habe in den letzten Tagen Martin G.'s Raspi-Programm ahoy.py für den HM-1500 adaptiert und die (ich meine, auch von ihm) als Farbgrafik gepostete Feldbedeutung der CMDs durchgesehen und in Teilen ein wenig nachkorrigiert. Jetzt sind die Ausgaben jedenfalls stimmig und für mich mit meiner PV-Paneel-Anordnung nachvollziehbar. (Ich habe 4 180 W bp-Solar Paneele auf dem Balkon liegen.) Um einen besseren Überblick über noch nicht zuweisbare Feldeinträge aus den Commands (1, 2, 3, 132 - was Anderes scheint's beim HM-1500 nicht zu geben) zu bekommen, habe ich das Logging zwecks visueller Inspektion ein wenig umgestellt und die Variablen anders benannt. Alle Änderungen beziehen sich auf die Subroutine on_receive(), die ich in der neuen Form als Anhang dranhänge. Die sich durchaus stark ändernden Blöcke des 132er Commands scheinen wesentlich mit der Verfügbarkeit des AC-Anschlusses zu tun zu haben. Um das zu untersuchen, habe ich den HM-1500 mal stromlos geschaltet und dann wieder eingestöpselt (entspricht ja einem Stromausfall). Die kondensierte Logdatei hängt dazu ebenfalls an. Meine Schlüsse daraus: - Die Variable uk_132_1 korreliert mit einer bemerkten AC-Frequenz - Die Variable uk_132_2 korreliert mit der Stromabgabe Weiter bin ich allerdings leider noch nicht vorgedrungen. Aber vielleicht finden ja einige Gurus hier noch was dazu raus ... ;-) Viele Grüße, Petra
Nachtrag: - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des Wechselrichters.
Einen Wunderschönen guten Tag, da ich so gut es geht vermeiden will, mit China-Servern verbunden zu sein, bin ich auf das Forum gestoßen und bin Erstaunt darüber, was bereits zustande gekommen ist. Applaus dafür! War beim lesen der Postings schon nervös, ob dieses Projekt überhaupt was wird. (Beim Thema sniffen der internen Kommunikation der DTU-W100). In den nächsten Tagen bekomme ich einen HM-1500 und 4x 450Wp Panele, die ich unbedingt begrenzen möchte. Im Idealfall mit Zero-Export-Funktion. (Mir ist bewusst dass hierzu zusätzliche Messinstrumente usw. installiert werden müssten) Die Drosselung des Inverters auf fixe Maximalwerte, wird wohl etwas einfacher zu realisieren sein. Beispiel: Geringer Eigenverbrauch = Inverter auf 50% Höherer Verbrauch = Inverter auf 90% Es gibt auch Möglichkeiten in Form von Zuschaltung zusätzlicher Verbraucher. Habe einige ESP32, ESP8266 und Gosund(Tasmota) Steckdosen zuhause. NRF24L01+ sind auch bestellt. Nach inbetriebnahme kann icht gerne auch Daten beisteuern. Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion zu "entschlüsseln". Fragen: Habe zu diesem Thema nichts gelesen (möglicherweise überlesen): Wenn die Inverter/DTUs ausgeliefert werden, sind sie ja auf einer bestimmten FW, die vermutlich übers Internet upgedatet werden kann. Kann es sein, dass das Verhalten der Kommunikation je nach FW anders ist? Dann müssten wir am besten alle auf der selben FW sein um weiterzukommen.. Besteht bzw. wie hoch ist die Gefahr, dass Hoymiles die Inverter und DTUs updatet und verschlüsselt, wenn man sich zu ihren Servern verbinden? Sollte ich mir vorbeugend jetzt schon einen weiteren HM1500 für eine Zukünftige Erweiterung besorgen? Gehe davon aus, dass Hoymiles die Geräte durch weitere Hardware/Softwareeingriffe noch "sicherer" machen werden und die Inverter in Zukunft keine Seemanssprache verstehen. (Siehe Playstation 4 Jailbreaks) Freue mich darauf, eure Meinungen zu hören.
Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie Hat die HMT-Serie ein geändertes Protokoll? Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern: HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500 1200-4T HMS-1000 900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.
Angehängte Dateien:
Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. Hoymiles 1200.
Hallo Franz, > Auch wenn ich bei meinen 3xx nur 2 Pakete habe, so gehoert doch das > letzte Word in 0x01 klar zu den overall Werten in 0x82, würde sich > alles im 2. ausgehen, ist aber geteilt. > > Bei mir gibt es keinen Zähler, bisher unbekannte Felder sind entweder > konstant oder springen. Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD genannt wird/wurde. Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y gesetzt, also das höchstwertige Bit 8 wird gesetzt. Bei zwei Paketen also 0x01, 0x82 Bei drei Paketen 0x01, 0x02, 0x83 Und bei vier 0x01, 0x02, 0x03, 0x84 etc pp Die CRC8 der Pakete sind jeweils die letzten Bytes vor 0x7F Und die CRC_M/CRC16 sind die letzten beiden Bytes vor dem CRC8 des 0x8y Pakets. Wie Jan Jonas schon schrieb wäre es sinnvoll statt von CMD von einem Paket Counter zu sprechen, dessen höchstwertiges Bit 8 gleichzeitig als Nachrichtende Flag dient
Python voraus! ich habe heute mal einen weiteren riesigen Dev-Snapshot gepushed. ahoy.py implementiert jetzt - Multi-Inverter - Transport-Layer und Retransmits von verlorenen Frames - Full Payload Decode mit Device- und Request- abhändigen Decodern - Dynamisches mqtt-publishen, jenachdem wieviel Phasen/Strings TBD: - mehr als nur den HM-600 supporten - code cleanup - irgendwie noch eine Strategie für Struktur der Decoder einfallen lassen Ist halt noch ein PoC und enthält mit Sicherheit Fehler. Hier: https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi Das mit den Retransmits sieht dann so aus:
1 | 2022-05-05 18:46:56.432521 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 73 ff 7e 00 00 00 05 00 00 00 00 59 ad e5 |
2 | 2022-05-05 18:46:56.525429 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 e4 |
3 | 2022-05-05 18:46:56.579134 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 0f 03 e8 00 f5 00 2a 6b f2 b4 |
4 | Error while retrieving data: Frame 1 missing: Request Retransmit |
5 | 2022-05-05 18:46:57.083093 Transmit 11 | 15 72 22 01 43 78 56 34 12 81 8e |
6 | 2022-05-05 18:46:57.137897 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 86 |
7 | 2022-05-05 18:46:57.641794 Payload: 00 01 01 3b 00 37 00 af 01 3b 00 39 00 b2 00 00 a2 0a 00 00 99 17 06 3b 06 40 08 e3 13 86 01 51 00 00 00 0f 03 e8 00 f5 00 2a 6b f2 |
8 | 2022-05-05 18:46:57.641794 Decoded: 24.5 phase0=voltage:227.5, current:1.5, power:33.7, frequency:49.98 string0=voltage:31.5, current:0.55, power:17.5, total:41.482, daily:1595 string1=voltage:31.5, current:0.57, power:17.8, total:39.191, daily:1600 |
Gruß, Jan
Sorbit schrieb: > Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. > Hoymiles 1200. Das kann ich bestätigen. HM-1200 mit AHOY 0.3.6
Servus, habe das ganze jetzt auch laufen. MQTT Broker läuft in Home Assistant. Emfange damit auch alle anderen Geräte, die über das MQTT Protokoll senden. Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected ist.
1 | CMDs:
|
2 | 0x1: 97 |
3 | 0x2: 193 |
4 | 0x3: 145 |
5 | 0x81: 0 |
6 | 0x82: 0 |
7 | 0x83: 0 |
8 | 0x84: 65 |
9 | other: 0 |
10 | |
11 | Send Cnt: 245 |
12 | |
13 | MQTT: connected |
Kann ich das irgendwie anders prüfen ?
Hans W. schrieb: > Leider bekomme ich nichts von der ESP-DTU rein. Obwohl MQTT connected > ist. Hast schon mit einem MQTT Sniffer die Topics geprüft? Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem // SGR
Robert S. schrieb: > Hast schon mit einem MQTT Sniffer die Topics geprüft? > Ich hatte am Ende ein / konfiguriert, das resultiert dann in einem // hab das ganze mal mit iobroker versucht und da wird ein ganzer Ordnerstamm erstellt. Scheint also an Home Assistant zu liegen... Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA. Aber das kommt dann im Sekundentakt rein. Muss ich wohl noch ein wenig suchen, woran es das liegt im HA. ESP-DTU funktioniert also !!! Top !!!
Hans W. schrieb: > Wenn ich jetzt ein Topic abonniere welcher im iobroker erstellt wurde ( > /inverter/hm1500/ch0/YieldTotal ) dann funktioniert es auch im HA. > Aber das kommt dann im Sekundentakt rein. > > Muss ich wohl noch ein wenig suchen, woran es das liegt im HA. Ich habe bei mir folgendes in der configuration.yaml: - platform: mqtt state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal" name: "Gesamtproduktion PV-Gartenhaus" device_class: energy unit_of_measurement: "kWh" Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | float) | round(2)) }}" will einfach nicht funktionieren.
Sorbit schrieb: > Kanal 4 zeigt Werte, obgleich dort kein Panel angeschlossen ist. > Hoymiles 1200. Kann mir vorstellen, dass das an den MPPT Reglern liegt. Der HM1200 hat nur zwei, also sind je zwei Anschlüsse parallel geschaltet. Hier entsteht wahrscheinlich ein geringer Fehler beim messen. Die Spannung wird übertragen, da es für den WR nur 2 DC Spannungen gibt. Petra R. schrieb: > - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des > Wechselrichters. Das ist kein Last-%-Grad, sondern der Power-Factor. https://de.wikipedia.org/wiki/Leistungsfaktor Jan-Jonas S. schrieb: > Transport-Layer und Retransmits von verlorenen Frames Lohnt es sich das Re-Transmit der Pakete zu implementieren? Aktuell ist meine Statistik fast jeden Tag gleich von der Verteilung her. Ich frage, da es ja noch nicht so genau bekannt ist, welche Sendekanäle der WR wirklich benutzt. Hat jemand schon mal eine DTU beim Re-Transmit erwischt?
1 | CMDs:
|
2 | 0x1: 3617 |
3 | 0x2: 11571 |
4 | 0x3: 9310 |
5 | 0x81: 0 |
6 | 0x82: 0 |
7 | 0x83: 0 |
8 | 0x84: 4332 |
9 | other: 0 |
10 | |
11 | Send Cnt: 20883 |
:
Bearbeitet durch User
Hallo IsnoAhoy IsnoAhoy schrieb: > Der Zähler sind die niederwertigen 4Bit in dem was hier gemeinhin CMD > genannt wird/wurde. > Wenn man das Letzte Paket der Nachricht bekommt wird zusätzlich 0x8y > gesetzt, also das höchstwertige Bit 8 wird gesetzt. > Bei zwei Paketen also 0x01, 0x82 ja, dass die "cmd" paketzaehler sind ist mir klar, dass das leftmost bit die endmarkierung ist, leuchtet mir jetzt auch ein. Ich hatte fälschlicherweise geglaubt, dass es bei anderen Modellen sowas wie anfragenübergreifende Nachrichtenzähler gibt den meine einfachen 3xx inverter mit 112174.. nicht haben - obwohl ich sie beim Zusammensuchen der dortigen Felder nicht gesehen hatte. Als ich mit anderen Sendekombinationen experimentiert hatte, war ich bis (durchgängig) 7 gekommen, allerdings habe ich das 0x88er dann wohl immer verpasst. Fast schade, dass ich Dienstag soviel Zeit hatte andere Modelle dazuzusuchen und die Struktur anzupassen (z.B. 3 mal umüberlegt ob mit 0 oder 1 bei DC zu starten, in der micro version ist es ja 1), immerhin habe ich nur heute abend ein wenig erfolglos refetching probiert. Ich habe mir aber als ich es merkte gleich Jans neue Version geholt. Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-( lg, Franz
Kann ich mit Daten aus meinem HM1200 helfen? Wenn ja, welche werden benötigt?
Robert S. schrieb: > Ich habe bei mir folgendes in der configuration.yaml: > > - platform: mqtt > state_topic: "Hoymiles/Gartenhaus/ch0/YieldTotal" > name: "Gesamtproduktion PV-Gartenhaus" > device_class: energy > unit_of_measurement: "kWh" > > Ich habs nur noch nicht geschafft die Werte sinnvoll zu runden, ein > > value_template: "{{ (states('sensor.gesamtproduktion_pv_gartenhaus' | > float) | round(2)) }}" > > will einfach nicht funktionieren. ich hab es jetzt mal so eingetragen. Morgen sehen wir weiter.
1 | - platform: mqtt |
2 | state_topic: "/inverter/hm1500/ch0/YieldTotal" |
3 | name: "Gesamtproduktion PV-Gartenhaus" |
4 | device_class: energy |
5 | unit_of_measurement: "kWh" |
6 | value_template: > |
7 | {{value|round(2)}} |
8 | state_class: total_increasing |
9 | unique_id: "pv_gartenhaus_total" |
10 | last_reset_topic: "/inverter/hm1500/ch0/YieldTotal" |
11 | last_reset_value_template: "1970-01-01T00:00:00+00:00" |
Lukas P. schrieb: >> - Die Variable uk_132_3 korreliert nicht mit dem Last-%-Grad des >> Wechselrichters. > > Das ist kein Last-%-Grad, sondern der Power-Factor. > https://de.wikipedia.org/wiki/Leistungsfaktor Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" getaufte Variable (Werte typisch bei 980 => 0,98) meintest? Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und "uk_132_4" (wild im einige Zehntausenderbereich schwankend). Any ideas? Tschüssi, Petra
Petra R. schrieb: > Danke für den Hinweis. Wobei ich vermute, dass du da meine "uk_132_2" > getaufte Variable (Werte typisch bei 980 => 0,98) meintest? > > Blieben vor allem noch die Interpretationen der Werte von "uk_132_1" > (oft bei 205), "uk_132_3" (1-stellige bis niedrige 2-stellige Werte) und > "uk_132_4" (wild im einige Zehntausenderbereich schwankend). > > Any ideas? Hallo Petra, ich kann bestätigen, uk_132_2 verläuft nahezu genauso wie der Leistungsfaktor den meine Gosund Zwischensteckdose ausgibt. Dies ist auch so bei [1] und [2] implementiert. Was Jan herausgefunden hat steht im letzten empfangenen Paket (also das mit 0x8*) in den letzten beiden Bytes (bei dir uk_132_4) der CRC über die gesamte Payload. Dies ist auch in seiner Implementierung so umgesetzt. Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl 0x00 0x07 Dein uk_132_1 konnte ich hier ebenfalls noch nicht zuordnen. [1] https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h [2] https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py Güße Thomas
franz schrieb: > Ich habe mir aber als ich es merkte gleich Jans neue Version geholt. > Mich beim Temperaturfeld hinzufügen verschrieben - musste dann ein > Butterbrot machen und dann war es schon um 3 Minuten zu dunkel :-( Sehr schön :) Übrigens kann man mit dem python-Modul auch "offline" debuggen [code] root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3 Python 3.9.2 (default, Mar 12 2021, 04:06:34) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import hoymiles >>> response = bytes.fromhex("00 01 01 3b 00 03 00 0b 01 3c 00 04 00 0d 00 00 a2 16 00 00 99 24 06 47 06 4d 08 dc 13 8a 00 00 00 00 00 00 00 00 00 d8 00 5a b1 89") >>> hoymiles.decoders.HM600_Decode0B(response).__dict__() {'phases': [{'voltage': 226.8, 'current': 0.0, 'power': 0.0}], 'strings': [{'voltage': 31.5, 'current': 0.03, 'power': 1.1, 'energy_total': 41494, 'energy_daily': 1607}, {'voltage': 31.6, 'current': 0.04, 'power': 1.3, 'energy_total': 39204, 'energy_daily': 1613}], 'temperature': 21.6, 'frequency': 50.02} >>> [code] Die response ist dabei eine komplette Payload, wie sie in meinem obigen Logauszug zum retransmit-Beispiel zu finden ist. Die Decoder sind Klassen in hoymiles/decoders/__init__.py class {model}_Decoder{req_cmd}(AntwortTypElternklasse) also HM600_Decoder0B(StatusResponse) Bisher gibts 2 Hautklassen UnknownResponse und StatusResponse StatusResponse ist hauptsächlich für die 0b-Werte zu verwenden und stellt den __dict__() accessor bereit. Dann muss man noch in der ResponseDecoderFactory-Klasse in hoymiles/__init__.py die ser_db um die Seriennummern-Maske erweitern, wenn die Liste das gewünschte Modell bisher nicht abdeckt. Wie gesagt, die Struktur ändert sich wohl noch. Das hab ich jetzt alles schnell um den eigentlichen Transport-Layer drumrum gehackt. Teaser: Es gibt dann schon eine Vorbereitung für einen command_queue, um später auch WR per mqtt steuern zu können. Bei mir geht übrigens ein Interval von 4 Sekunden. Bei mehreren WR würde ich sagen interval + 5s für jeden WR. Nachtabregelung muss noch implementiert werden. Ich würde das aber lieber an Anzahl TX ohne Antwort binden statt an Uhrzeiten. Also wenn nach 30 Anfragen keine Antwort, interval auf 5 Minuten oder so. Jede Payload wird im Übrigen bis zu 4x je interval wiederholt, wenn keine Antwort kommt. Das ist Absicht, brauchen wir spätestens wenn wir steuern wollen und außerdem will ich meine Antworten garantiert innerhalb des interval bekommen.
Hi Thomas, > Bei mir (habe ebenfalls einen HM-1500) ist uk_132_3 die meiste Zeit wohl > 0x00 0x07 Da kommen bei mir aktuell häufig Werte 11 und 12. Vielleicht kann ja mal ein DTU-behafteter Kollege nachschauen, welche Werte man über die bereits zuweisbaren hinaus als Information abfragen kann? Tschüssi, Petra
Angehängte Dateien:
-
esp_dtu.JPG
61 KB
Hallo bin neu hier. Habe heute meine Hardware bekommen: NodeMCU + NRF24L01. Compilieren, Upload und Config hat funktioniert. Daten vom HM600 bekomme ich noch keine, evtl. bin ich zu weit weg. NRF24L01 wird erkannt, MQTT ist connected (IoBroker). Folgendes ist mir aber bis jetzt aufgefallen: Nach einem Reboot klappt scheinbar die NTP-Abfrage nicht immer. In der seriellen Console steht oft [NTP]: 1970-00-00+00:00:00, selten das korrekte Datum/Uhrzeit. Im WebIf steht immer 1970-00-00+00:00:00. Habe den Timerserver auch schon auf fritz.box geändert, bringt nichts. Evtl ist die Abfrage ja zu schnell nach dem Wifi-Connect. Update: Die ersten Daten sind angekommen. Wenn ich mit irgendwelchen Rohdaten helfen kann, bitte melden.
:
Bearbeitet durch User
Hallo Harry F. Daten bekommst Du erst wenn Du die Seriennummer im Setup eingetragen hast. Das sollte selbst ohne WLAN Verbindung zum NTP server funktionieren. Ich weiss aber nicht ob der WR auf Epoch 1970-01-01 reagiert, die Anfrage für die Statusdaten ist ja im Prinzip das Zeit setzen Kommando. Was sagt er denn bzgl RF24 und Anschlüssen. Irgendjemand hat auch hier oder im github unter Issues gemeldet dass die IRQ Leitung nicht an allen / beliebigen ESP8266 Anschlüssen funktioniert. Der Anschluss muss Interrupt fähig sein. Mit besten Grüßen Stefan
Angehängte Dateien:
Hallo zusammen, erst mal tausend Dank für die super Arbeit die ihr bisher gemacht habt. Der ganze Thread liest sich echt wie ein Krimi. Ich habe einen HM600 mit zwei Modulen und heute mal den Lötkolben angeschmissen und das ganze auf einem Wemos D1 Mini zum laufen gebracht. Wenn ich die Statistik-Werte mit den anderen hier geposteten vergleiche, kommt es mir so vor, als würden bei mir deutlich weniger Pakete ankommen. Mein ESP6288 ist nur ca. 2m vom WR entfernt. Ist bei meinem Setup irgendwas schief gelaufen oder ist das im Rahmen? Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen erzeugt worden.
Hallo Lukas, habe gerade mal nachgesehen mein ESP8266 (v0.3.6) hatte vor 2:15h wohl einen Reset. Das Datum steht immer noch auf 1970 aber er zeigt Werte (Temperatur, Yield Total, Spannung, Strom, etc.) an und ist auch per WLAN Router erreichbar. D.h. nach erfolgreicher Verbindung mit dem WLAN Router erfolgt kein erneuter NTP Abgleich.
H. E. schrieb: ... > Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast > doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen > erzeugt worden. Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? 292,70 + 290,80 = 583,50 P_DC 583,50 P_DC /// 420,00 P_AC ---> 72% ? Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3%
:
Bearbeitet durch User
Angehängte Dateien:
Hallo und danke an alle die hier so tolle Arbeit leisten! Auch ich habe heute meine Anlage bekommen (HM-1500) und habe die ersten Daten empfangen. Allerdings war das erste NRF24 Modul defekt. Erst nach dem Austausch lief alles. Aber dann wirklich wunderbar. Die Daten sind plausibel und die Pakete kommen in hoher Anzahl. Auch mit einer Entfernung von aktuell ca. 6-7m. Hab den MQTT Client in FHEM eingebunden. Daten kommen sauber rüber. Allerdings wird der Client nach jedem Neustart als neues Device erkannt. Könnte da noch etwas angepasst werden? Ich hab die AHOY:0.3.2 auf einem NodeMCU. Könnte der Device Host Name genutzt werden?
Herbert K. schrieb: > H. E. schrieb: > ... >> Der YieldTotal Wert kommt bei mir auch nicht hin. Der müsste fast >> doppelt so hoch sein. Die 86 kWh sind eher in den letzten 30 Tagen >> erzeugt worden. > Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? > > 292,70 + 290,80 = 583,50 P_DC > 583,50 P_DC /// 420,00 P_AC ---> 72% ? > > Ich habe z.B. bei P_DC von 376 W /// P_AC von 358,30 W ---> 95,3% Ne, abgeriegelt habe ich nichts. Ich habe auch keine DTU mit der ich das tun könnte. Ich glaube das liegt daran, dass die Daten der beiden Channel nicht synchron mit den oberen Daten sind. Die Daten dort sind auch lange auf 0 stehen geblieben (außer YieldDay), bis dann nach ca. einer Stunde das erste 0x1 Signal kam. Läuft also noch nicht so rund bei mir.
Hallo,
habe gerade meine Python-Implementierung [1] nochmal gepusht.
Hinzugekommen sind:
* Support für den HM-1500
* Mqtt {topic}/command payload-relay
* Default decoder zur einfacheren Protokollanalyse
1 | $ mosquitto_pub -t hoymiles/11417/command -m 800b00tttttttt0000000500000000 |
Injiziert z.B. ein Zeit-Setzen-Kommando. tttttttt ist eine Variable für die Zeit. So kann man sehr einfach und zur Laufzeit neue Payloads ausprobieren. Gruß, Jan [1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi
H. E. schrieb: > Herbert K. schrieb: >> Wieso ist Dein HM600 auf 72% abgeregelt ? Absicht ? Nicht bemerkt ? > > Channel nicht synchron mit den oberen Daten sind. Genau, weil es keine "channel" gibt. Das passiert, wenn man Datenfragmente die zu unterschiedlichen Zeitpunkten "aus dem Kontext gerissen" wurden korelliert. Bei einer Abregelung sinken zwingend DC und AC-Werte um die gleiche Summe. Blieben die DC-Werte hoch würde der WR massiv Energie vernichten müssen. Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung einfach der falschen Datenerhebung geschuldet und wenn mans richtig machen würde, wie es aktuell das Python-Ding tut, ist das der Wirkungsgrad des WR. Unabhängig von der Abregelung.
Hallo Jan-Jonas ich finde es toll mit welchem Elan du an die Sache dann gehst. Echt schön zu sehen, dass auch andere viel Zeit investieren. > Eine größere Differenz zwischen DC und AC ist bei der C-Implementierung > einfach der falschen Datenerhebung geschuldet und wenn mans richtig > machen würde, wie es aktuell das Python-Ding tut, ist das der > Wirkungsgrad des WR. Unabhängig von der Abregelung. Allerdings finde ich hast du dich hier im Ton vergriffen. Ich fühle mich in keinem Wettbewerb und ich will schon gar keine zwei Lager bilden. Bitte lass uns weiterhin an einem Strang ziehen. Jeder kann per PR beitragen. Die aktuelle Implementierung ist bei allen noch ein PoC oder? Es gibt noch kein richtig oder falsch sondern eher Fortschritte. Die Version des ESP8266 ist halt Stand heute nicht mehr 'up to date'.
Guten Morgen, soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum MQTT Broker. z.B. bei mir gestern um 16 Uhr. Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den Logs. Also ESP reboot und dann ist er sofort wieder connected. Sonst noch jemand Probleme mit MQTT ?
Wir diskutieren schon länger auf github über Stabilität. https://github.com/grindylow/ahoy/issues MQTT läuft bei mir stabil, hatte vor 20h den letzten Komplettabsturz, danach hat alles von selbst wieder funktioniert. (Version 0.3.6)
Hans W. schrieb: > Guten Morgen, > soweit läuft meine ESP-DTU 0.3.6 stabil. Keine Verbindungsabbrüche mehr > zum Webinterface. Leider verliert der ESP irgendwann die Verbindung zum > MQTT Broker. z.B. bei mir gestern um 16 Uhr. > Hatte mich schon gewundert, das Home Assistant ab 16 Uhr keine > Produktion mehr aufgezeichnet hat. Leider sehe ich am Broker nix in den > Logs. > Also ESP reboot und dann ist er sofort wieder connected. > Sonst noch jemand Probleme mit MQTT ? Bei mir selbiges. Das Wlan läuft stabil, aber der MQTT-Client schließt die Verbindung und macht sie nicht wieder neu auf.
Mein Wemos D1 mini mit 0.3.6 läuft leider gar nicht stabil. Die Uptime ist selten höher als 1 Stunde, die automatischen reboots dauern oft sehr lange oder vielleicht findet er auch keine SSID oder DHCP. Jedenfalls habe ich in der Statistik manchmal stundenlange Lücken. Vermutlich auch deshalb weil er nur ca. jedes zweite Mal den MQTT connected. Die onboard LED blinkt übrigens unregelmäßig, weist das auf Ausfälle hin? WIFI Probleme glaube ich eher nicht, RSSI ist bei ca. -70dbM, andere ESP8266 in der Nähe funktionieren ohne Probleme. Kann es sein dass das NRF Modul stört, es sendet und empfängt ja auf derselben Frequenz. Das NRF-Modul scheint recht stabil zu sein, der WR ist durch ein Fenster mit Jalousie und dann noch ca. 20m Luftlinie entfernt. Wäre es möglich den WIFI-RSSI auf der Webpage anzuzeigen oder via MQTT zu publishen? Damit könnten wir schlechte Verbindungen leichter erkennen.
Also heute ist es wie gestern ... um 16 Uhr MQTT Abbruch aber der Wemos ist noch up
Hallo Zusammen, ich habe heute mal versucht den HM-600 aufzuschrauben. Leider habe ich ihn nicht komplett aufbekommen. Ich vermute daß man irgendwie die Kabelzugentlastungen lösen muß und evtl. auch noch mit etwas Wärme aus einem Heißluft-/-fön die Dichtungen lösen muß. Das habe ich meinem neuen Geräte dann doch nicht alles zumuten wollen, es soll ja nachher wieder wasserdicht und möglichst lange seinen Dienst verrichten. Vielleicht hat ja jemand einen gebrauchten, defekten HM den er mal zu Anschauungszwecken defilieren kann ? @Jan-Jonas, ich habe Deine Paketanalyse mal nachvollzogen. M.E. hast Du Recht mit dem Paketzähler und dem höchstwertigen Bit 0x8y das das letzte Paket oder eben die Anforderung für einen Request (vielleicht sogar einen Retransmit) bedeutet. Ich habe die Ergebnisse dieser Paketanalyse vorläufig hier im Github Issue dokumentiert, das kann man ggf. auch in die hoymiles Doku aufnehmen. https://github.com/grindylow/ahoy/issues/24 Hat das (so einen Retransmit oder die Spezialanfrage mit X Paketen von Jan Jonas) bei den auf Seite 1 & 2 gemachten HackRF und anderen Funkprotokollmitschnitten der Original DTU auch sonst noch jemand feststellen können ? Vielleicht können ja noch ein paar alte Hasen (die schon vor Ostern hier geforscht haben) hierzu etwas beitragen ?
lpb schrieb: > Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das > Anfordern eines nicht erhaltenen Pakets. > Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket > anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. @isnoAhoy Hier wurden die Retransmits bereits im DTU Log gefunden. Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die Statistiken, also die Counter wie oft welches Paket kam. "CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x 0x84 Anfrageinterval war 1s auf Kanal 40, empfangen statisch auf Kanal 3.
Bei mir werden die Werte per MQTT alle Sekunde geschickt obwohl es auf 10 Sekunde eingestellt ist. Änderungen der Zeit haben keinen Einfluss.Ist das auch bei anderen so? ESP-DTU 0.3.6
Hallo Lukas P., Du hast Recht in Spalte AA bis AE stehen drei Pakete der Standardantwort. Man kann gut sehen, daß der GD32 das Paket 0x01 nicht empfangen hat und damit in Spalte AD nochmal mit 0x81 und CRC8 0x94 anfordert. Die Antwort mit dem fehlenden Paket kommt dann in Spalte AE. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Nur die Paketcounter sind eben nicht in Zeile 16 wie von martin (Gast) im Excel vermutet. Sondern wie richtig von lbp und Jan-Jonas bemerkt das in Zeile 10 bisher als CMD bezeichnete Byte. Zeile 13-16 ist hingegen die Zeit in Unix-Epoch wie anderweitig bereits herausgefunden wurde. In Spalte AU-AZ taucht dann auch die Anfrage mit 0x80 0x11 auf, die Jan-Jonas als bisher größtes Antwortnachricht mit den Paketen 0x01..0x85 des WR identifiziert hat. @martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt zwischen GD32 und nRF24 aufzuzeichnen ?
Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen Sinn ständig die Zeit neu zu setzen. Gedacht habe ich an sowas wie ein Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die Retransmits. @Jan-Jonas S. (janjonas_s) Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den Payload gebildet werden. Beispiel, so wie es aktuell verstehe, aber die CRC8s und CRC16_P stimmen nie: 01 [...] CRC8 CRC16_H CRC16_L 02 [...] CRC8 CRC16_H CRC16_L .... 8X [...] CRC16P_H CRC16P_L CRC8 CRC16_H CRC16_L CRC8: über Paketpayload ohne CRC8 und CRC16 CRC16: ist implementiert und funktioniert CRC16P: über die gesamte Payload aller Pakete - mit oder ohne dem Paketcounter?
Hallo Jan, Jan-Jonas S. schrieb: > Hinzugekommen sind: > * Support für den HM-1500 ich dachte bisher dass ich HM-350 haette (steht leider nicht lesbar drauf ohne den WR vom Modul zu lösen, das ja auch noch montiert ist), Aber HM-4xx macht keinen Sinn, da ich pro Modul nur 325Wp habe. Allerdings war ja die Vermutung dass die 3xx und 400 gleiches Protokoll haben, darum hatte ich die bei mir alles als 300 zusammengefasst. Ich habe daher im angefügten diff meine (mit 112174..) als 3XX bezeichnet, aber vermutlich könnte man die letzte Stelle weglassen und 3xx und 4xx damit covern. Ich habe ein diff attached. Ad Retransmit, das hatte bei mir nicht funktioniert, bis ich die +6e7 ns bei empfangenen Paketen entfernt hatte, dann erwischte ich ueberhaupt fast alles, das hast Du jetzt auf +5e8, meine Antworten kommen zwischen 1ms und 10ms, geht sich also locker aus. Sollte auch in der Mikrocontrollerversion also mindestens so hoch sein. Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages auch flat in ein kompaktes File schreiben zu können, hab mir sowas für einen geplanten remote site implementiert wo ich keine db hinter iobroker haben werde. lg, Franz
Lukas P. schrieb: > Jetzt mal eine blöde Frage: nur mit dem Request 0x80 (Zeit setzen) > werden alle Pakete / Frames von 0x01 bis 0x8X geschickt? Ich frage mich, > ob es nicht noch eine kürze Anfrage gibt - es mach ja keinen wirklichen > Sinn ständig die Zeit neu zu setzen. Ich glaube der WR hat keine RTC und braucht daher die Updates der Zeit über die Luft, damit er z.B. weiß wann die daily counter resetet wetden müssen. > Gedacht habe ich an sowas wie ein > Request 0x00 oder halt ein Request 0x80 mit CRC und sonst nichts wie die > Retransmits. Da stehen wir noch vor dem Anfang. Ich glaube, dass das byte nach 0x80 (normal 0x0b) das Kommando ist. Die Zeit, die wir dahinter setzen die Parameter zum Kommando. Ich hab das mal durchgesweept und bekomme da alle möglichen langen und kurzen Antworten, die sich meist auch unterscheiden jenachdem welche Parameter man anhängt. Da sind wir auf mehr DTU Captures angewiesen um das verstehen zu können. Aber da war in python spätestens auch Schluss mit den cmd'd, weil jede Antwort mindestens ein Fragment 1 enthält, wo keine bekannten Werte drin stehen. Das macht dann graphen sehr kaputt, wenn man random binärdaten zu Zahlen macht. Übrigens zum sweepen s.O. das /command-Topic. Sehr handy. > @Jan-Jonas S. (janjonas_s) > Ich würde gerne die C-Implementierung nachziehen. Was ja auch in der > C-Impl. schon gemacht wird, ist den CRC16 jedes Paketes/Frames zu > prüfen. Was ich noch nicht verstanden habe ist auf welchen Daten (Roh > oder schon verschoben um 7bit nach rechts) die CRC8 und CRC16 über den > Payload gebildet werden. in hoymiles/__init__.py InverterTransaction.get_payload()
1 | # check crc |
2 | pcrc = struct.unpack('>H', payload[-2:])[0]
|
3 | if f_crc_m(payload[:-2]) != pcrc: |
4 | raise ValueError('Payload failed CRC check.')
|
Jedes Frame besteht aus
0x95, 4byte dst_addr, 4byte src_addr, 1byte sequence, bis 16byte(?)
data, 1byte crc8
sequence:
0x01 - 0x80 ist ein forlaufendes Fragment
0x81 - 0xFF(?) markiert das letzte Paket, und die Gesamtzahl der
Fragmente
Wenn sequence größer 0x80:
int(sequence - 0x80) = Anzahl Fragmente
Das Endpaket zählt mit in den Paketzähler, 0x80 kann daher kein Wert des
Endpakets sein. 0 Pakete = keine Übertragung ;)
Wenn mann alle data bytes in der richtigen Reihenfolge zusammen setzt
(Payload), sind am Ende die 2 byte die modbus crc über die ganze Payload
Fehlt das Endpaket ist die Transaktion verloren. Die Pakete werden
meistens nicht in der richtigen Reihenfolge empfangen. Kann sein, dass
man die in der Reihenfolge 84, 01, 03, 02 liest.
Neu ist für mich auch, dass bei längeren Payloads, der WR auch auf Ch 40
antwortet.
Den ersten Re-Transmit habe ich hier gefunden
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo franz, vielen Dank für das HM3XX-Mapping! Pulled-in. franz schrieb: > Was auch noch prakisch wäre, ist die Endknoteninfo der mqtt messages > auch flat in ein kompaktes File schreiben zu können, hab mir sowas für > einen geplanten remote site implementiert wo ich keine db hinter > iobroker haben werde. Sowas ist geplant und möglich. Ich stelle mir das python-modul später mal so vor, dass man es ähnlich wie auch den paho mqtt-client irgendwo rein laden kann und ein on_message-Callback bekommt, indem man Daten aus der Response nach belieben verarbeiten kann. Ich plane z.B. einen direkten Influx2-Exporter, so umzusetzen. Das soll dann jeder selber modular bauen können, weil jeder sein eigenes Backend hat und die Zahl der Output-Plugins den Rahmen des Projekts sprengen würde. Da bin ich aber noch nicht soweit, weil wir mit Sicherheit im Kern noch Dinge entdecken die möglicheriweise grundlegend überarbeitet werden müssen. Da liegt im Moment mein Fokus drauf. Bis dahin würde ich gerne die Komplexität außen rum so gering wie möglich halten. Gruß, Jan
Hallo Jan, Jan-Jonas S. schrieb: > Pulled-in. hab die germergte version ausprobiert, funktioniert. Überinges war meine timing Aussage vorher falsch es sind 1-10 hundertstel-, nicht 1-10ms. Ich hatte mir mehrere (7) NRF module bestellt, weil ich mir nicht sicher war, ob die wayintop + sind, die + von AZ so billig waren und laut Kommentaren und eigenen Beobachtungen gibt es öfters Aufälle, bzw schlimmer, funktioniert dann nicht zuverläßig. Ich habe nur in ca einen von 1000 Fällen eine Antwort am Sendekanal (40) und 90% auf 3 und 75. ALso kann ich mit einem chip staendig auf 3 und mit dem Sender gleich auf 75 umschalten, um zu sehen ob was kommt. Mit einem 2. Rapsi kann ich dann auch noch auf 2 weiteren Kanälen lauschen, sollte von der library her gehen und werde das mal ausprobieren :) lg, Franz
Lukas P. schrieb: > lpb schrieb: >> Mit dieser Info kann man auch andere Pakete in dem DTU log erklären, das >> Anfordern eines nicht erhaltenen Pakets. >> Wenn ich die 02 nicht erhalten habe, kann ich die mit einem '82' Paket >> anfordern, also sinngemäß '15 4bytsADR 4bytesAdr 82 CRC'. So, wie es halt das python-modul seit einiger Zeit macht. Was ich ja alles schon geschrieben habe. Offensichtlich lest Ihr nicht. > Im Anhang habe ich einfach mal zur Entwicklung der gesamt-Payload mal > die Payload gesammelt. Die Datei ist so zu verstehen: Pro Zeile ein > Paket, ganz vorne sieht man 01, 02, 03 und 84. Darunter sind die > Statistiken, also die Counter wie oft welches Paket kam. > "CMDS: 6 13 11 0 0 0 5" bedeutet also 6x 0x01, 13x 0x02, 11x 0x03 und 5x > 0x84 Was für einen Nährwert hat diese Satistik? Das ist wie wenn man hin und wieder mal aus dem Fenster schaut und über den Tag die Autos nach Farbe zählt, die gerade zufällig vorbei fuhren. Die Daten aus dem 220507_PayloadHm1200.log machen für mich überhaupt keinen Sinn. Je Frame gibts max 16 byte Payload-Fragment. In der Payload gibts garkeinen Bezug mehr, in welchem Frame ein Schnipsel mal rein kam. Im Anhang nochmal valide Daten von einem HM600 als Referenz. Daran könnt Ihr eure Implementierung mal testen, bis diese zu den gleichen Werten kommt. Die Transaktion: * Transmit Request (gesendete Daten merken) * Alle innerhalb $Timeout empfangenen Daten per Frame-CRC (letztes byte) virifizieren und wenn valide den Datenteil und die sequenz in ein stack aus (seq, data) appenden. Die Adressen und Frame-CRC können da schon verworfen werden. * buffer nach sequenz größer 0x80 durchsuchen, damit man weiß wieviele Frames der WR gesendet hat * über den stack iterieren range(1, int(sequenz - 0x80)) und alle daten der reihe nach zusammensetzen + daten letztes Frame oder wenn man kein frame mit der sequenz findet, re-transmit anfordern und response auf den stack werfen. Schritt Wiederholen. * modbus_crc(data ohne letzten beiden byte) == data letzten beiden byte checken * final payload = data[:-2] (2 byte checksum weg) Dann wird der Request der Transaktion wieder wichtig, weil man daran den Decoder wählt, dem man die finale Payload überreicht. Nach aktuellem Kenntnisstand ist der Dekoder anhand des byte 11 (0b bei Zeit setzen) aus dem Request zu wählen. In der Payload gibts wohl keinen Identifier der enthaltenen Daten. Der Wesentliche Teil findet sich da in hoymiles/__init__.py:InverterTransaction.get_payload() Dort wird die Payload zusammengebaut. Gruß, Jan
:
Bearbeitet durch User
isnoAhoy schrieb: > @martin(Gast), hast Du evtl. die Möglichkeit noch weitere Aktionen in > der Hoymiles DTU (wie das vielfach angefragte Einstellen von Zero Export > Restrictions oder Abregeln auf 70% Leistung, etc.) an Deinem Meßpunkt > zwischen GD32 und nRF24 aufzuzeichnen ? Leider habe ich nur die DTU Lite, damit kann ich nichts regeln. Die Anzeige der Live-Werte im Installationsmodus kann ich mal testen. Bisher schneide ich die Kommunikation nur mit dem Logic Analyzer mit, was einen gewissen Aufwand darstellt - stattdessen möchte ich mir demnächst mal einen Logger basteln, damit ich längerfristig die Daten mitschreiben kann. Die werde ich dann gerne bereitstellen. Für die Statistik hier noch meine Seriennummern: DTU Lite: 10D9-72... HM-600: 1141-72...
Danke martin, dass du es zumindest schonmal kurz versuchst hast dir anzusehen. Das Power Limit lässt sich aber defintiv nur mit der DTU-Pro einstellen. Ich habe dazu auch noch eine kleine Anleitung gefunden vom letzten Jahr, für die DTU-Pro Nutzer, die es Testen wollen/können: https://www.shinetech-power.de/wp-content/uploads/2021/11/Shinetech_DTU_Set70Percent_Hoymiles.pdf Die Oberfläche sieht vielleicht inzwischen etwas anders aus, aber irgendwo sollte der Punkt versteckt sein. Der Zero Export Modus wird logischerweise ohne externe Modbus Messeinrichtung nicht funktionieren und falls es dort 70% Festwert zur Auswahl gibt, könnte es sein, dass er einfach nur als beliebiges Limit die 70% an den WR sendet. Egal welcher Weg, es wird am Ende wohl immer nur ein Prozentwert in ein Register des WR gesendet werden und das lässt sich wohl am besten mit der frei wählbaren Option testen/loggen. Ich würde mich sehr freuen, wenn das noch klappt, ansonsten muss ich in knapp einem Monat ein Loch in meinen WR bohren und etwas löten. Mehr zu meinem Grund/Vorhaben dafür habe ich bereits eher geschrieben. Das mit den Seriennummern sollte ja inzwischen fest stehen, wie es auch Sprinterfreak im Git und isnoahoy hier geschrieben hat: Hoymiles HM Serie: SN 1121 = 1 MPPT/Eingang -> HM-300/350/400 SN 1141 = 2 MPPT/Eingänge -> HM-600/700/800 SN 1161 = 4 MPPT/Eingänge -> (HM-1000)/1200/1500 Mein frisch gelieferter HM-800 hat die SN 114180... Grüße
Danke für die Info. Sollte dieses "Funfact" bezug auf mein Posting nehmen, so möchte ich darauf hinweisen dass ich von der DTU in der Mehrzahl (Plural) geschrieben habe und nicht explitit die DTU-Pro-S erwähnt habe. Ist es Empfehlenswert, die Inverter vorerst nicht mit einer DTU zu verbinden, um mögliche komplikationen durch Updates zu vermeiden?
Jan-Jonas S. schrieb: > Im Anhang nochmal valide Daten von einem HM600 als Referenz. > Daran könnt Ihr eure Implementierung mal testen, bis diese zu den > gleichen Werten kommt. Das war sehr hilfreich. Habe jetzt den CRC8 und den CRC16 korrekt nachvollziehen können. Kanal-Switching auf RX Seite habe ich eingebaut, die Ergebnisse sind gemischt: Was mir aufgefallen ist: Wenn ich TX auf 40 stelle, dann bekomme ich nie Antworten auf Kanal 40. Habe den vorerst mal rausgenommen, evtl. kann man hierdurch die Retransmits zu reduzieren, da man in dieser Zeit auf anderen Kanälen lauschen kann. Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten liegen. Gibt es schon Erkenntnisse wie oft der WR seine Daten erneuert? Ich glaube im Python Code ein 5s Interval erkannt zu haben. Hat schon jemand bei diesem Kommando mit den Parametern experimentiert?
1 | setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms |
Angehängte Dateien:
-
20220509_Grafana.png
300 KB
Ich habe aktuell das Python in der letzten Version von Jan am laufen [1] Die Ergebnisse sind toll. Habe ein 5 Sek. Intervall eingestellt und bekomme dort zuverlässig Daten. [1] https://github.com/Sprinterfreak/ahoy/tree/pypackage/tools/rpi
Lukas P. schrieb: > Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus > bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten > liegen. Ja, das ist mir auch schonmal aufgefallen. Eine Änderung der Antennenausrichtung hat hier wunder gewirkt. (Zusätzlich zu dem Kondensator den ich sowieso am NRF Modul habe)
in der app.cpp hab ich folgendes beim Serial-Output (mit mSerialInterval=600) reingefrickelt - sorry, ich hatte keine Zeit mich in den Code ernsthaft einzulesen - vielleicht bringt es trotzdem jemanden etwas:
1 | #include <ESP8266HTTPClient.h> |
2 | |
3 | #define SERVERNAME "http://pvoutput.org/service/r2/addstatus.jsp"
|
4 | #define APIKEY "40digit-hex-API-Key" // pvoutput.org API-Key
|
5 | #define SYSTEMID 12345 // pvoutput.org systemID
|
... ... ...
1 | void app::loop(void) { |
... ... ...
1 | if (mSerialValues) { |
2 | if (++mSerialTicker >= mSerialInterval) { |
3 | mSerialTicker = 0; |
4 | uint16_t energy = 0; |
5 | for (uint8_t id = 0; id < mSys->getNumInverters(); id++) { |
6 | Inverter<> *iv = mSys->getInverterByPos(id); |
7 | if (NULL != iv) { |
8 | uint8_t modNum, pos; |
9 | switch (iv->type) { |
10 | default: modNum = 1; break; |
11 | case INV_TYPE_HM600: |
12 | case INV_TYPE_HM800: modNum = 2; break; |
13 | case INV_TYPE_HM1200: modNum = 4; break; |
14 | }
|
15 | |
16 | for (uint8_t ch = 1; ch <= modNum; ch ++) { |
17 | energy += iv->getValue(iv->getPosByChFld(ch, FLD_YD)); |
18 | }
|
19 | }
|
20 | }
|
21 | |
22 | char serverPath[255] = {0}; |
23 | sprintf(serverPath, "%s?key=%s&sid=%d&d=%04d%02d%02d&t=%02d:%02d&v1=%d", SERVERNAME, APIKEY, SYSTEMID, year(mTimestamp), month(mTimestamp), day(mTimestamp), hour(mTimestamp), minute(mTimestamp), energy); |
24 | |
25 | Serial.println(serverPath); |
26 | |
27 | HTTPClient http; |
28 | WiFiClient client; |
29 | |
30 | http.begin(client, serverPath); |
31 | |
32 | // Send HTTP GET request
|
33 | int httpResponseCode = http.GET(); |
34 | |
35 | if (httpResponseCode > 0) { |
36 | Serial.print("HTTP Response code: "); |
37 | Serial.println(httpResponseCode); |
38 | String payload = http.getString(); |
39 | Serial.println(payload); |
40 | }
|
41 | else { |
42 | Serial.print("Error code: "); |
43 | Serial.println(httpResponseCode); |
44 | }
|
45 | // Free resources
|
46 | http.end(); |
47 | |
48 | |
49 | |
50 | char topic[30], val[10]; |
51 | for (uint8_t id = 0; id < mSys->getNumInverters(); id++) { |
52 | Inverter<> *iv = mSys->getInverterByPos(id); |
53 | if (NULL != iv) { |
54 | for (uint8_t i = 0; i < iv->listLen; i++) { |
55 | if (0.0f != iv->getValue(i)) { |
56 | snprintf(topic, 30, "%s/ch%d/%s", iv->name, iv->assign[i].ch, iv->getFieldName(i)); |
57 | snprintf(val, 10, "%.3f %s", iv->getValue(i), iv->getUnit(i)); |
58 | DPRINTLN(String(topic) + ": " + String(val)); |
59 | }
|
60 | yield(); |
61 | }
|
62 | }
|
63 | }
|
64 | }
|
oben sollte eine Antwort auf folgenden Beitrag sein - sorry Robert Bleumer schrieb: > HM1500 funktioniert hier auch mit ESP8266 und NFR24L01+ und die > letzte > > Seriennummer meine 1500 fangt auch mit 1161 an. > > Steht upload nach PvOutput.org noch auf's Programm?
Lukas P. schrieb: > Was mir aufgefallen ist: Wenn ich TX auf 40 stelle, dann bekomme ich nie > Antworten auf Kanal 40. Habe den vorerst mal rausgenommen, evtl. kann > man hierdurch die Retransmits zu reduzieren, da man in dieser Zeit auf > anderen Kanälen lauschen kann. Auf 40 antwortet der WR einiges, wenn man ihn was fragt wo es längere Payloads als 4 Frames gibt. Also bei mir bleibt der definitiv drin. ;) 8002tttttttt00000500000000 z.B. liefert mir fast immer ein Teil der Response auf Ch40 aus. Dafür habe ich vom WR noch nie was bekommen, wenn ich auf was anderem als 40 anfrage. Oli hat aber glaub ich auch schon Antworten auf Anfragen auf anderen Kanälen bekommen? Solange 40 bei allen funktionert bin ich glücklich. Eine Hoplist ist zumindest auch für TX schon so halb vorbereitet. Ich sehe gerade keinen Grund dafür. Meine Idee währe ohnehin eine Transceiver-List im YAML-File hinzuzufügen wo man sagen kann.
1 | - channel: [23,40] |
2 | mode: tx |
3 | ce_pin: n |
4 | - channel: [3,23,40,61] |
5 | mode: rx |
6 | ce_pin: n |
z.B. Da ich aber auch mit nem 2s Interval eigentlich kein cycel verliere, sehe ich dafür absolut kein Bedarf mehr. (Also multi-transceiver Setup) > Leider kommt es bei mir recht häufig vor, dass alle 4 Pakete des WR aus > bleiben - das kann natürlich auch an meinen räumlichen Gegebenheiten > liegen. Da wir keinem Funkplan folgen und kenie Rücksicht drauf nehmen ob wir irgendwas dazwischen funken was gerade schon auf Welle ist, ist eine Kollision sehr wahrscheinlich. Dann versteht natürlich niemand mehr was, da können wir nichts machen außer re-transmitten bis wir eine Antwort bekommen. Also quasi das Band solange jammen bis andere aufgeben. :D Dann kommt noch dazu, dass die Antenne tatsächlich kein wirklicher Rundstrahler ist und schon recht optimal stehen muss. > Gibt es schon Erkenntnisse wie oft der WR seine Daten erneuert? Ich > glaube im Python Code ein 5s Interval erkannt zu haben. On Request. Ich hab auch wenn ich den mit 1s polle immer neue Daten. Schneller lässt das Protokoll das nicht zu. > Hat schon jemand bei diesem Kommando mit den Parametern experimentiert? >
1 | > setRetries(3, 15); // 3*250us and 15 loops -> 11.25ms |
2 | >
|
SEHR viel. Hätte ich einen Sketch so oft kompillieren und auf einen ESP schreiben müssen, hätte ich einen hohen Chip-Verbrauch gehabt. :D Die Settings haben bei mir damals son sweet spot getroffen. Scheint aber wohl sehr von der Funk-Umgebung abzuhängen wie sich rausstellt. Gruß, Jan
:
Bearbeitet durch User
Angehängte Dateien:
Hallo Jan-Jonas, ich habe mir mal Deine Transmit Pakete angesehen und folgendes Byte >05< ist mir dabei aufgefallen: 2022-05-08 15:24:27.553664 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 77 c4 8b 00 00 00>05<00 00 00 00 27 f2 0e Bei den von martin (Gast) am RX/TX zwischen GD32 und nRF24 aufgezeichneten Daten seiner DTU Lite wurde hier immer >00< übertragen. Hast Du einen Grund an der Stelle einen anderen Wert zu übertragen, bzw. bekommst Du hier andere Antworten je nach Anfrage ? Ich habe auf der Suche nach diesem Byte auch noch folgende Anmerkung und Beobachtung von Oliver F. gefunden: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" > Martin (Gast) hatte noch eine Anmerkung: >> Was mir hier und auch in meinen Daten aufgefallen ist: In den >> Anfrage-Daten der DTU taucht in der ganzen Reihe mit den Nullen immer >> mal wieder eine Zahl auf - Könnte diese etwas mit dem Funkkanal zu tun >> haben, der für die Antwort verwendet werden soll? > > Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über > die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) > > Turn unit off: > C2 850194040 00 1946107301 00DA 1B 1 15 73104619 72819005 > 800B00623B5CD8000000>08<0000000013DAD8A73B 3BA7 1 > Turn unit on: > C2 067083344 00 1946107301 00DE 1B 3 15 73104619 72819005 > 800B00623B5D5A000000>09<00000000B0CEEDD61D 1DD6 1 > Turn unit off: > C2 055407012 00 1946107301 00DA 1B 1 15 73104619 72819005 > 800B00623B5DC2000000>0A<0000000076413F7EAF AF7E 1 > Turn unit on: > C2 086582484 00 1946107301 00DA 1B 1 15 73104619 72819005 > 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1 Das 0x8y bedeutet m.E. daß die letzten beiden Byte (vor dem letzten CRC8) einen CRC_M bzw CRC16 enthalten. 0x8y kann ja sowohl bei Anfragen als auch bei Antworten auftauchen. Das mit dem Kanal/allen Kanälen jammen konnte ich auch in martins Logic Analyzer Aufzeichnungen im Excel sehen (Spalte O-Z), dort wird die Anfrage insgesamt 12x wiederholt, lediglich der time_t Zeitstempel und somit auch die CRC16 & CRC8 werden ggf. angepaßt. Jetzt müssten wir also die Antworten auf 0x800b, 0x8011 und 0x8003 je Wechselrichter Modellreihe, z.B. 1121, 1141 und 1161 dekodieren. Das ist für die 0x800b Statusanfrage m.W. auch soweit schon alles funktional. Es fehlen aber noch das Verständnis für die Antworten auf 0x8011 und 0x8003 die Einige (martin, Oliver, Hubi & Herbert, etc.) hier vorher beobachtet haben. 0x8003 geht dabei sogar von 0x01, 0x02, .., 0x09, 0x0A, 0x0B bis 0x8C. Diese Anfragen & deren Antworten sind vermutlich auch wieder in Abhängigkeit von der Modellreihe zu untersuchen. Anbei das Beispiel aus martin's RX/TX Logic Analyser Excel als Screenshot.
Hallo Jan-Jonas, > SEHR viel. Hätte ich einen Sketch so oft kompillieren und auf einen ESP > schreiben müssen, hätte ich einen hohen Chip-Verbrauch gehabt. :D Ich weiß, ziemlich Off-Topic, aber wie macht ihr das eigentlich auf Eurem Raspberry Pi die vielen MQTT Daten in eine InfluxDB o.a. zu speichern. Da müsste ja jede SD Karte den Geist aufgeben. Habt Ihr dafür irgendeine (m)SATA / m.2 SSD eingebaut ? Wenn ja, welchen Adapter (USB->SATA) verwendet ihr und wie groß bzw. welcher Bauart ist die SSD ?
Hallo, isnoAhoy schrieb: > Ich habe auf der Suche nach diesem Byte auch noch folgende Anmerkung und > Beobachtung von Oliver F. gefunden: > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Das. Was genau es bedeutet, keine Ahnung. Zu dem Zeitpunkt habe ich das Projekt gejoined und hab das so aus der alten ahoy.py übernommen. Nein, ich sehe keine Änderung, wenn ich da was anderes übertrage. >> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über >> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) 05 >> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1 Guter Fund! > Das 0x8y bedeutet m.E. daß die letzten beiden Byte (vor dem letzten > CRC8) einen CRC_M bzw CRC16 enthalten. Nicht ganz. Die Adressen, der Frame-Counter und das letzte Byte gehören zum ESB-Frame. Die CRC16_M, zufällig in dem ESB-Frame mit Counter größer 0x80, ist zu diesem Zeitpunkt nur Payload und hat nichts mit dem Transport-Layer zu tun. Die CRC16_M existiert für uns also am besten nur in der Payload, wenn sie wieder defragmentiert ist. Ich könnte jetzt natürlich auch mal schauen, ob die letzten beiden Byte anderer Payloads auf random Requests auch eine CRC16_M ist ... Das würde die Anzahl zu erratener Bytes reduzieren :D > InfluxDB > Da müsste ja jede SD Karte den Geist aufgeben. Richtig. SD ist by design kaputt. > Habt Ihr dafür irgendeine (m)SATA / m.2 SSD eingebaut ? So habe ich meine 0-Einspeise-Regelung realisiert. Rechenzentrum zu Hause. Da steht ein i3 mit Proxmox und NVME. Sicher radiert das da auch ganz schön trotz wear leveling (Was die SD nicht hat). Aber ich mag bunte Grafiken, wo ich rein zoomen kann und trotzdem keine Auflösung verliere. Ich halte die Daten 1 Woche mit voller Auflösung und danach reduziert ein CQ das runter auf 10 Minuten. So bleibt das dann ewig. Die paar Wechselrichter-Werte sind da aber nur ein ganz kleiner Teil vom Rauschen. :) Gruß, Jan mqtt->telegraf->InfluxDB. Beispiel habe ich oben auch schon mal gepostet. Append: Der incrementierende Counter verrät dem WR im Grunde wieviele Commands er hinterher hängt. Wie verhält sich denn das erste Byte der Payload zum Command-Counter. Könnte das vielleicht die Differenz angeben, damit die verpassten Nachrichten nochmal hinterher geschoben werden können?
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > So habe ich meine 0-Einspeise-Regelung realisiert. Wie hast Du diese denn realisiert? Du benötigst ja einen steuerbaren WR....
Hallo Jan-Jonas, danke für die Antwort. Ich habe nochmal den Github Kommentar nachgelesen, in dem ich exemplarisch Mal eine 0x8002 Anfrage und Antwort von Dir untersucht hatte. https://github.com/grindylow/ahoy/issues/24#issuecomment-1120237280 Hier mal die Antwort auf die 0x8011 wie von martin im Excel zwischen GD32 und nRF24 getraced. $ xxd 0x8011.bin 00000000: 0001 b001 0001 0d34 0d34 0000 0000 708f .......4.4....p. 00000010: 0004 0d3c 0d97 0002 07a3 7093 0005 0d3c ...<......p....< 00000020: 0d97 0000 0000 a00e 0006 0d9c 0d9c 0705 ................ 00000030: 0542 708f 0009 0d9c 0dd8 01e2 07a3 7091 .Bp...........p. 00000040: 000a 0d9c 0dd8 0000 12c0 d16a 377f ...........j7. Wir haben also nicht nur dei Anfragen 0x800b und 0x8011 gesehen, sondern auch wie von Hubi/Herbert berichtet eine 0x8003 und die von Dir geloggte 0x8002. Die Anfragen sollte man vielleicht auch nach ein paar Tagen nochmal wiederholen, da es wohl nicht besonders schnell veränderliche Daten sind. Zumindest taucht die Anfrage 0x8011 in martin's DTU Logic Analyzer Daten nur einmal auf. Bzgl. dem RF24 am Raspberry habe ich noch eine weitere Frage: Warum funktioniert es da auch ohne Interrupt, beim ESP8266 schliessen wir extra den Interrupt an. Ich hatte irgendwo ein Issue im RF24 github gelesen, das aber schon geschlossen war bzgl. optionaler pigpio Unterstützung für Interrupts.
Hallo isnoAhoy, ich habe mal die Payload aus dem Screenshot abgetippt. Nicht nur, dass die ganz anders aussieht als bei mir, die crc stimmt auch nicht. Dafür habe ich mal 0x11 bei mein HM600 angefragt und ein wenig rum probiert. Ich hab fast die Vermutung, dass das eine Daily history von energy total von einem String ist. In meiner Payload sieht das sehr nach Tabelle von irgendwas aus. Ich hab hier mal kurz die Payload mit Linebreaks versehen. Ich sehe da ein Muster.
1 | 00 01 |
2 | 80 01 00 06 31 53 31 53 00 00 00 00 |
3 | 80 02 00 35 a7 fa a7 fa 00 00 00 07 |
4 | b0 02 00 36 00 32 00 32 ff ff ff fb |
5 | b0 02 00 37 00 39 00 39 00 00 00 05 |
6 | b0 02 00 38 05 c2 05 c2 ff ff ff fa |
7 | b0 02 00 39 05 c6 05 c6 00 00 00 06 |
8 | b0 02 00 3a 18 6c 18 6c ff ff ff fb |
9 | b0 02 00 3b 18 6f 18 6f 00 00 00 05 |
10 | b0 02 00 3c 23 5a 23 5a ff ff ff fb |
11 | b0 02 00 3d 23 5e 23 5e 00 00 00 05 |
12 | b0 02 00 3e 25 de 25 de ff ff ff fb |
13 | b0 02 00 3f 25 e3 25 e3 00 00 00 05 |
14 | b0 02 00 40 26 c9 26 c9 ff ff ff fa |
15 | b0 02 00 41 26 ce 26 ce 00 00 00 06 |
16 | b0 02 00 42 27 ea 27 ea ff ff ff fb |
17 | 39 f2 <- modbus crc |
Bei 0x12 habe ich einmal eine ähnliche Antwort bekommen und jetzt kommt bei 0x12 nur noch
1 | 2022-05-10 18:37:20.973622 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 12 00 62 7a 94 bd 00 00 00 00 00 00 00 00 b2 61 7f |
2 | 2022-05-10 18:37:21.019035 Received 15 bytes channel 3: 95 72 22 01 43 72 22 01 43 81 00 01 70 c0 a5 |
3 | 2022-05-10 18:37:21.522190 Payload: 00 01 70 c0 |
4 | payload has valid modbus crc |
Gruß, Jan
Beim Beschiessen der HM350 + HM400 mit 0x11 bekomme ich 2 verschieden lange Antworten: a) 5+1 Telegramme (letztes = 86....) b) 8+1 Telegramme (letztes = 89....) c) oder 8114 als Kurztelegramm (Payload=0x14) Wobei die letzten Telegramme (also 86..., 89...) weniger Lang sind nach dem was mir angezeigt wird. Auf jeden Fall wiederholt sich öfters ...8002... in der Payload. Entschlüsselt habe ich noch nix.
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > Auf 40 antwortet der WR einiges, wenn man ihn was fragt wo es längere > Payloads als 4 Frames gibt. Also bei mir bleibt der definitiv drin. ;) > 8002tttttttt00000500000000 z.B. liefert mir fast immer ein Teil der > Response auf Ch40 aus. Ok, du bist da schon weiter - dann nehme ich es wieder auf. Jan-Jonas S. schrieb: > Dafür habe ich vom WR noch nie was bekommen, wenn ich auf was anderem > als 40 anfrage. Das sehe ich genauso, anfangs habe ich mit 4 Kanälen gearbeitet. Wenn man nicht auf 40 sendet, bekommt man nur 0x81 Pakete ohne Payload -> Fehlermeldung? Jan-Jonas S. schrieb: > On Request. Ich hab auch wenn ich den mit 1s polle immer neue Daten. > Schneller lässt das Protokoll das nicht zu. Wegen Zeit setzen und mit Unix-Timestamp? Dürfte auch mehr als genug sein. Sorbit schrieb: > Jan-Jonas S. schrieb: >> So habe ich meine 0-Einspeise-Regelung realisiert. > > Wie hast Du diese denn realisiert? > Du benötigst ja einen steuerbaren WR.... Oder man verheizt die Energie einfach kommt auch bei 0 raus, ist halt weniger nachhaltig (je nach dem was man mit dem Überschuss anstellt).
Angehängte Dateien:
-
IMG_6141.JPG
230 KB
Hallo, bin noch neu hier aber erstmal meinen Respekt an all die hie reverse engeneered haben. Find ich super, da brauch ich mir jetzt die DTU für 100Euro kaufen. So ein Mini 8266 von AZDelivery tuts auch mit ein paar Modifikationen. Kleines Feedback an die Developer von Ahoy: -Tsun M800 läuft ohne Probleme, im Setup HM600 ausgewählt und Seriennummer eingetragen (114173307xxx) -MQTT funktioniert noch nicht (vielleicht schon bekannt) -Ich wünsche mir ein JSON file als Alternative zu MQTT Lukas P. schrieb: > Sorbit schrieb: >> Jan-Jonas S. schrieb: >>> So habe ich meine 0-Einspeise-Regelung realisiert. >> >> Wie hast Du diese denn realisiert? >> Du benötigst ja einen steuerbaren WR.... > > Oder man verheizt die Energie einfach kommt auch bei 0 raus, ist halt > weniger nachhaltig (je nach dem was man mit dem Überschuss anstellt). Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um Warmwasserspeicher. Danke Jungs!
:
Bearbeitet durch User
Neue Erkenntnisse: Die vermeintliche Liste in 80 11 wird länger, wenn man den Stecker zieht. Ereignisspeicher seit Einspeisebegin?
1 | Poll inverter 114172220143 |
2 | 2022-05-11 09:47:14.398816 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 11 00 62 7b 69 fe 00 00 00 00 00 00 00 00 47 d7 80 |
3 | 2022-05-11 09:47:14.462357 Received 27 bytes channel 23: 95 72 22 01 43 72 22 01 43 01 00 01 80 01 00 06 32 88 32 88 00 00 00 00 80 0d 9f |
4 | 2022-05-11 09:47:14.497777 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 02 00 07 68 3a 68 3a 01 ce 13 54 40 94 00 09 68 3a 97 |
5 | 2022-05-11 09:47:14.533164 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 03 68 90 09 3d 07 53 80 0d 00 0a 68 c8 68 c8 02 60 eb |
6 | 2022-05-11 09:47:14.574203 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 04 12 45 40 94 00 0c 68 c8 69 0f 09 47 08 58 80 02 44 |
7 | 2022-05-11 09:47:14.639077 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 00 0d 6a 25 6a 25 ff ff ff fb 80 02 00 0e 6a 25 5a |
8 | 2022-05-11 09:47:14.680307 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 06 6a 25 00 00 00 05 80 02 00 0f 6b 29 6b 29 ff ff 54 |
9 | 2022-05-11 09:47:14.751142 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 07 ff fb 80 02 00 10 6b 2c 6b 2c 00 00 00 05 80 02 83 |
10 | 2022-05-11 09:47:14.786377 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 08 00 11 6b 66 6b 66 ff ff ff fa 80 02 00 12 6b 6b 19 |
11 | 2022-05-11 09:47:14.827522 Received 19 bytes channel 40: 95 72 22 01 43 72 22 01 43 89 6b 6b 00 00 00 05 01 69 71 |
12 | 2022-05-11 09:47:15.331532 Payload: 00 01 80 01 00 06 32 88 32 88 00 00 00 00 80 0d 00 07 68 3a 68 3a 01 ce 13 54 40 94 00 09 68 3a 68 90 09 3d 07 53 80 0d 00 0a 68 c8 68 c8 02 60 12 45 40 94 00 0c 68 c8 69 0f 09 47 08 58 80 02 00 0d 6a 25 6a 25 ff ff ff fb 80 02 00 0e 6a 25 6a 25 |
13 | 00 00 00 05 80 02 00 0f 6b 29 6b 29 ff ff ff fb 80 02 00 10 6b 2c 6b 2c 00 00 00 05 80 02 00 11 6b 66 6b 66 ff ff ff fa 80 02 00 12 6b 6b 6b 6b 00 00 00 05 01 69 |
14 | payload has valid modbus crc |
15 | 80 01 00 06 32 88 32 88 00 00 00 00: |
16 | BBLHl : (128, 1, 406152, 12936, 0) |
17 | BBBBBHHHB: (128, 1, 0, 6, 50, 34866, 34816, 0, 0) |
18 | 12B : (128, 1, 0, 6, 50, 136, 50, 136, 0, 0, 0, 0) |
19 | |
20 | 80 0d 00 07 68 3a 68 3a 01 ce 13 54: |
21 | BBLHl : (128, 13, 485434, 26682, 30282580) |
22 | BBBBBHHHB: (128, 13, 0, 7, 104, 14952, 14849, 52755, 84) |
23 | 12B : (128, 13, 0, 7, 104, 58, 104, 58, 1, 206, 19, 84) |
24 | |
25 | 40 94 00 09 68 3a 68 90 09 3d 07 53: <-- Netztrennung |
26 | BBLHl : (64, 148, 616506, 26768, 154994515) |
27 | BBBBBHHHB: (64, 148, 0, 9, 104, 14952, 36873, 15623, 83) |
28 | 12B : (64, 148, 0, 9, 104, 58, 104, 144, 9, 61, 7, 83) |
29 | |
30 | 80 0d 00 0a 68 c8 68 c8 02 60 12 45: |
31 | BBLHl : (128, 13, 682184, 26824, 39850565) |
32 | BBBBBHHHB: (128, 13, 0, 10, 104, 51304, 51202, 24594, 69) |
33 | 12B : (128, 13, 0, 10, 104, 200, 104, 200, 2, 96, 18, 69) |
34 | |
35 | 40 94 00 0c 68 c8 69 0f 09 47 08 58: <-- Netztrennung |
36 | BBLHl : (64, 148, 813256, 26895, 155650136) |
37 | BBBBBHHHB: (64, 148, 0, 12, 104, 51305, 3849, 18184, 88) |
38 | 12B : (64, 148, 0, 12, 104, 200, 105, 15, 9, 71, 8, 88) |
39 | |
40 | 80 02 00 0d 6a 25 6a 25 ff ff ff fb: |
41 | BBLHl : (128, 2, 879141, 27173, -5) |
42 | BBBBBHHHB: (128, 2, 0, 13, 106, 9578, 9727, 65535, 251) |
43 | 12B : (128, 2, 0, 13, 106, 37, 106, 37, 255, 255, 255, 251) |
44 | |
45 | 80 02 00 0e 6a 25 6a 25 00 00 00 05: |
46 | BBLHl : (128, 2, 944677, 27173, 5) |
47 | BBBBBHHHB: (128, 2, 0, 14, 106, 9578, 9472, 0, 5) |
48 | 12B : (128, 2, 0, 14, 106, 37, 106, 37, 0, 0, 0, 5) |
49 | |
50 | 80 02 00 0f 6b 29 6b 29 ff ff ff fb: |
51 | BBLHl : (128, 2, 1010473, 27433, -5) |
52 | BBBBBHHHB: (128, 2, 0, 15, 107, 10603, 10751, 65535, 251) |
53 | 12B : (128, 2, 0, 15, 107, 41, 107, 41, 255, 255, 255, 251) |
54 | |
55 | 80 02 00 10 6b 2c 6b 2c 00 00 00 05: |
56 | BBLHl : (128, 2, 1076012, 27436, 5) |
57 | BBBBBHHHB: (128, 2, 0, 16, 107, 11371, 11264, 0, 5) |
58 | 12B : (128, 2, 0, 16, 107, 44, 107, 44, 0, 0, 0, 5) |
59 | |
60 | 80 02 00 11 6b 66 6b 66 ff ff ff fa: |
61 | BBLHl : (128, 2, 1141606, 27494, -6) |
62 | BBBBBHHHB: (128, 2, 0, 17, 107, 26219, 26367, 65535, 250) |
63 | 12B : (128, 2, 0, 17, 107, 102, 107, 102, 255, 255, 255, 250) |
64 | |
65 | 80 02 00 12 6b 6b 6b 6b 00 00 00 05: |
66 | BBLHl : (128, 2, 1207147, 27499, 5) |
67 | BBBBBHHHB: (128, 2, 0, 18, 107, 27499, 27392, 0, 5) |
68 | 12B : (128, 2, 0, 18, 107, 107, 107, 107, 0, 0, 0, 5) |
69 | |
70 | 2022-05-11 09:47:15.345973 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 7b 6a 02 00 00 00 05 00 00 00 00 96 a1 c7 |
71 | 2022-05-11 09:47:15.409633 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 3f 02 e4 09 35 01 40 02 e9 09 48 00 00 9a |
72 | 2022-05-11 09:47:15.450519 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 ba 0a 00 00 b1 2d 01 53 01 52 08 ed 13 88 11 a8 7d |
73 | 2022-05-11 09:47:15.485233 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 04 00 c6 03 e8 01 7b 00 12 59 e7 e9 |
74 | 2022-05-11 09:47:15.989314 Payload: 00 01 01 3f 02 e4 09 35 01 40 02 e9 09 48 00 00 ba 0a 00 00 b1 2d 01 53 01 52 08 ed 13 88 11 a8 00 04 00 c6 03 e8 01 7b 00 12 59 e7 |
75 | 2022-05-11 09:47:15.989314 Decoded: 37.9 phase0=voltage:228.5, current:19.8, power:452.0, frequency:50.0 string0=voltage:31.9, current:7.4, power:235.7, total:47.626, daily:339 string1=voltage:32.0, current:7.45, power:237.6, total:45.357, daily:338 |
Gruß, Jan
:
Bearbeitet durch User
so eine Art Gedächtnis muss es geben. Ich hatte schon beobachtet, dass die DTU den HM350 plötzlich nicht mehr sah ... und am nächsten Tag waren plötzlich Daten zum Tag da. Was ich mit meiner SW (Fork vom alten C-Code auf ESP8266) plötzlich beobachte (bis vor kurzem funktionierte es ganz passabel) ist, dass der etwas weiter entfernte HM350 von der Früh weg Werte schickt und dann plötzlich damit aufhört, bzw sehe ich am ESP keine Nachrichten mehr .... er verschwindet dann um ca 9:00 auch immer von der DTU .... speist aber weiterhin ein und auch die Led blinkt grün. Am nächsten Tag kommen wieder Nachrichten und nach 1-2h hören sie auf. Kann es sein, dass es so eine Art "denial of service" Schutz ist, wo der WR nach einer größeren Anzahl mit CRC fails oder einfach zu vielen Anfragen zu schweigen beginnt? Hat jemand ähnliches beobachten können? Ich habe viel mit RX Channel hopping und unterschiedlichen Zeiten zwischen den ticks experimentiert .... nichts scheint das zu verbessern. Der HM700, der näher zu ESP und DTU ist liefert viel mehr Werte pro Zeiteinheit. Was sich geändert hat seit Anfang April ist die gesteigerte Vegetation zwischen HM350 und ESP ... ich habe aber auch mehrere Antennen getestet um das zu kompensieren (bus zu 9dBi omni)
Martin P. schrieb: > er verschwindet dann um ca 9:00 auch immer von der DTU .... speist aber > weiterhin ein und auch die Led blinkt grün. > Am nächsten Tag kommen wieder Nachrichten und nach 1-2h hören sie auf. Ich vermute eher, da beginnt jemand sein HomeOffice und DDoSed das wlan in Teams. Oder verwendet sonst welche Funk-Gadgets. NRF ist da sehr empfindlich. Schon mal die Antenne schief angeschaut? Bei Thomas hat das wohl geholfen. Mein WR hat noch nicht aufgehört mir Daten zu schicken und ich hol da echt raus, was geht. Aber über die Eventualität habe ich auch schon nachgesacht, dass die loggen und irgendwann ihren Flash kaputt schreiben? Wer weiß. Egal. So lange hab ich ein buntes Leben :D
Raik E. schrieb: > Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um > Warmwasserspeicher. Bitte etwas konkreter. Wie regelt Ihr das? Welche Hardware benötigt man dazu?
Sorbit schrieb: > Wie regelt Ihr das? Am Verbraucher: - Shelly - Sonoff HomeAssistant übernimmt dabei die Logik, Verbraucher bedarfsgereicht ein-/abzuschalten. Am Wechselrichter garnicht. Wir wissen ja noch nicht wie... Aber bei 600 Wp habe ich auch nur sehr kurz, sehr wenig, wenn überhaupt Überchuss. Wenn ich Energie über hätte, würde ich ein Miner anschmeißen. Das Problem hab ich leider nicht. > Welche Hardware benötigt man dazu? Energiemessgerät am Hausanschluss, was schon halbwegs Echtzeitdaten liefern kann. Ich hab ein Shelly 3EM und polle dessen http api sekündlich. EVU-Meter scheinen dazu nicht geeignet zu sein, liefern zu selten Daten. Ferrais-Zähler gehen garnicht. Dann halt irgendein Logik-Element dazwischen was die Daten vergleicht und dann, sobald wir endlich wissen wie man den WR steuert, könnte mein HASS jetzt schon per mqtt {topic}/command die Steuer-Payload einwerfen.
Angehängte Dateien:
-
Hoymiles_001.png
26 KB
Hallo! Auch ich habe mir vor einigen Wochen ein Mini-Solarkraftwerk mit 2 Stück 375W Modulen und einem HM600 Inverter in den Garten gestellt. Da ich unser Haus mit einer Homematic teilautomatisiert habe, benutze ich zur Messung des Ertrags ein Schaltmodul mit Energiezähler, welches ich "rückwärts" betreibe. Zum weiteren Erkenntnisgewinn und aus reinem Spieltrieb habe ich das Netz auf der Suche nach einer Möglichkeit durchsucht, an die internen Daten des Controllers, ohne Cloudzwang, heranzukommen. Auf dieser Seite hier bin ich nun fündig geworden. Einen ESP8266 hatte ich noch in meiner Basteliste, die NRF-Platine habe ich von AZ Delivery. Dort habe ich nur noch einen Elko über die Versorgungsspannungs-Pins gelötet, beide Platinchen verdrahtet, das Git-Repository geclont, das Projekt in den ESP gebrannt, meine gemachten Fehler gesucht und behoben....und nun kann ich meinen Wechselrichter auslesen. Herzlichen Dank an alle Beteiligten, welche dieses tolle Projekt realisiert haben und viel Zeit und Mühe dort hineingesteckt haben! Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic gemessenen Werte. Jetzt habe ich mir mal die RF24 Payload über die serielle Schnittstelle ausgeben lassen und nach den fehlenden Daten gesucht. In dem Bild im Anhang habe ich den vermeindlichen Fundort markiert. Könnte jemand von euch das verifizieren? Was ich auch nicht hinbekomme, ist die MQTT-Verbindung. Ich habe mir auf der Homematic mit Mosquitto und Node-Red einen Broker gebaut, mit dem sich der ESP laut Statusmeldung auch connectet, aber ich bekomme keine Daten heraus. Allerdings bin ich auch totaler MQTT-Anfänger, der Fehler liegt sicherlich irgendwo in meiner Konfiguration versteckt. Vielen Dank noch einmal für die hervorragende Arbeit! Peter
Pintopf schrieb: > Was ich auch nicht hinbekomme, ist die MQTT-Verbindung. Ich habe mir auf > der Homematic mit Mosquitto und Node-Red einen Broker gebaut, mit dem > sich der ESP laut Statusmeldung auch connectet, aber ich bekomme keine > Daten heraus. > Allerdings bin ich auch totaler MQTT-Anfänger, der Fehler liegt > sicherlich irgendwo in meiner Konfiguration versteckt. > > Vielen Dank noch einmal für die hervorragende Arbeit! > Peter Versuch doch mal, einen MQTT-Client wie z.B. MQTT Inspector (iPad) zu verwenden, um die Daten des MQTT-Brokers auszulesen. Nach meiner Erfahrung hilft das sehr dabei, zu erkennen, welche Namen Deine Werte im Broker haben. Von der Kommandozeile gehts auch mit: mosquitto_sub -u <user> -P <passw> -v -t +/# Dann siehst Du, was rauskommt von dem, was Du reinschickst…
Pintopf schrieb: > Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge > (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic > gemessenen Werte. Die beiden Channels (PV-Module) zusammengezählt ergeben doch 45kWh wie gemessen, das passt doch eh. @MQTT kontrolliere genau die / in den jeweiligen Topics, oft hakt es daran ;-)
Angehängte Dateien:
-
_MQTT_Test.png
41 KB
Ich habe schon einen MQTT-Sniffer laufen, der findet auch mein selbsdefiniertes Topic nebst Inhalt, was mir sagt, dass der Broker auf der CCU3 wohl läuft.(Screenshot) Muss ich den Inhalt des vom ESP gesendeten Topics vielleicht irgendwo selbst definieren? Steht da zur Zeit nur nichts drin? Wenn nein, welche Meldungen werden übermittelt? Als String? Viele Grüße, Peter
rosch99 schrieb: > Die beiden Channels (PV-Module) zusammengezählt ergeben doch 45kWh wie > gemessen, das passt doch eh. Das ist wohl war, jedoch wird auf der vom ESP generierten Webseite nur der Wert des zweiten Channels als Gesamt-Energiemenge angezeigt. Da stand beim meiner obigen Messung eben 23,3 kWh Gesamtertrag. Gruß, Peter
Hi, neues von 0x11 und 0x12 Requests. Siehe Logfile. Sieht wohl so aus, als währe ich da auf der richtigen Fährte. Die a_text's sind die a_codes aus der DTU-Modbus und User manual [1]. a_code 1 und 2 sind geraten. Sonst ist noch ne Menge unbekannt. Bei der Uptime bin ich mir auch unschlüssig. Ginge um ne Stunde falsch und scheint irgendwann übergelaufen zu sein? Aber mit long statt short dekodieren gibt an der Stelle keinen sinnvollen Output. Wo ist der Unterschied zwischen 0x11 und 0x12? Glaube die Art des Fehlers. 0x11 scheint ein allgemeines Log zu sein, 0x12 Grid related? [1] https://www.hoymiles.com/wp-content/uploads/2021/11/User-manual_HMS-160018002000-4T-NA_EN_V202201.pdf -- Gruß, Jan
:
Bearbeitet durch User
Konnte Jans Erkenntnis bzgl. 0x80 0x11 nachvollziehen. mit seinem letzten Source bekommt man folgendes dekodiert:
1 | 2022-05-11 19:17:29.045241 Payload: 00 01 80 01 00 06 30 62 30 62 00 00 00 00 00 d4 00 07 30 6a 00 00 00 00 00 00 b0 02 00 48 4c f7 4c f7 00 00 00 05 b0 02 00 49 55 da 55 da ff ff ff fb b0 02 00 4a 55 ed 55 ed 00 00 00 05 b0 02 00 4b 56 72 56 72 ff ff ff fb b0 02 00 4c 56 72 56 72 00 00 00 06 b0 02 00 4d 56 79 56 79 ff ff ff fb b0 02 00 4e 56 82 56 82 00 00 00 05 b0 02 00 4f 56 e7 56 e7 ff ff ff fb b0 02 00 50 56 f3 56 f3 00 00 00 05 b0 02 00 51 57 1d 57 1d ff ff ff fb b0 02 00 52 57 23 57 23 00 00 00 05 b0 02 00 53 57 4f 57 4f ff ff ff fb b0 02 00 54 57 51 57 51 00 00 00 05 05 ab |
2 | payload has valid modbus crc |
3 | 80 01 00 06 30 62 30 62 00 00 00 00: |
4 | uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start |
5 | BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0) |
6 | 00 d4 00 07 30 6a 00 00 00 00 00 00: |
7 | uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input |
8 | BBHHHHH: (0, 212, 7, 12394, 0, 0, 0) |
9 | b0 02 00 48 4c f7 4c f7 00 00 00 05: |
10 | uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power |
11 | BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5) |
12 | b0 02 00 49 55 da 55 da ff ff ff fb: |
13 | uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power |
14 | BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531) |
15 | b0 02 00 4a 55 ed 55 ed 00 00 00 05: |
16 | uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power |
17 | BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5) |
18 | b0 02 00 4b 56 72 56 72 ff ff ff fb: |
19 | uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power |
20 | BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531) |
21 | b0 02 00 4c 56 72 56 72 00 00 00 06: |
22 | uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power |
23 | BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6) |
24 | b0 02 00 4d 56 79 56 79 ff ff ff fb: |
25 | uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power |
26 | BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531) |
27 | b0 02 00 4e 56 82 56 82 00 00 00 05: |
28 | uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power |
29 | BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5) |
30 | b0 02 00 4f 56 e7 56 e7 ff ff ff fb: |
31 | uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power |
32 | BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531) |
33 | b0 02 00 50 56 f3 56 f3 00 00 00 05: |
34 | uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power |
35 | BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5) |
36 | b0 02 00 51 57 1d 57 1d ff ff ff fb: |
37 | uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power |
38 | BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531) |
39 | b0 02 00 52 57 23 57 23 00 00 00 05: |
40 | uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power |
41 | BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5) |
42 | b0 02 00 53 57 4f 57 4f ff ff ff fb: |
43 | uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power |
44 | BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531) |
45 | b0 02 00 54 57 51 57 51 00 00 00 05: |
46 | uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power |
47 | BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5) |
Bei 0x80 0x12 schaut kommt
1 | 2022-05-11 19:09:10.888401 Transmit 27 | 15 71 60 35 46 78 56 34 12 80 12 00 62 7b fb c4 00 00 00 00 00 00 00 00 52 59 c0 |
2 | 2022-05-11 19:09:10.951495 Received 27 bytes channel 3: 95 71 60 35 46 71 60 35 46 81 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb 36 |
3 | 2022-05-11 19:09:11.454623 Payload: 00 01 00 d4 00 07 30 6a 00 00 00 00 00 00 51 fb |
4 | payload has valid modbus crc |
5 | 00 d4 00 07 30 6a 00 00 00 00 00 00: |
6 | uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input |
7 | BBHHHHH: (0, 212, 7, 12394, 0, 0, 0) |
Ich hätte das so interpretiert, dass 0x11 ein allgemeines Log ist und 0x12 nur kritische Dinge anzeigt. Aber ist nur eine vermutung.
Jan-Jonas S. schrieb: > Hi, > > neues von 0x11 und 0x12 Requests. Siehe Logfile. Sieht wohl so aus, als Hallo Jan, 0x11 habe ich seit Mittag am Laufen für 350 + 400. Hab aber noch keine Zeit gehabt, mir das anzuschauen. Hab nur gesehen, das einer schon bei den Antworten bei ..8C... angekommen ist, so auf die Schnelle. "C" wären ja 12 Payloads zum zusammensetzen ?
pintopf schrieb: > Muss ich den Inhalt des vom ESP gesendeten Topics vielleicht irgendwo > selbst definieren? Steht da zur Zeit nur nichts drin? > Wenn nein, welche Meldungen werden übermittelt? Als String? Ok, du verwendest NodeRed, damit ist es einfach. Versuch mal /inverter/# zu subscriben und einen debug node dranzuhängen, das # entspricht im MQTT einem *. Du bekommst dann alle Topics und Werte als String im debug fenster und kannst dir die passenden raussuchen. Ich schicke es dann in einen change node und mache aus dem string eine number und anschliessend noch einen smooth node zum runden der Werte. Kann man natürlich auch mit einem function node lösen.
Sorbit schrieb: > Raik E. schrieb: >> Genau so mach ich das auch. Ich verbrenne einfach den Überschuss um >> Warmwasserspeicher. > > Bitte etwas konkreter. > Wie regelt Ihr das? > > Welche Hardware benötigt man dazu? Ein wenig Off-topic: Ich habe in meiner Unterverteilung direkt hinter dem Hauptzähler ein Eastron SDM72M installieren lassen, dieser wird mittels einem ESP32 ausgelesen und übermittelt den Verbrauch/Einspeisung wattgenau an einen Thyristor Leistungssteller (Schwingungspaketsteuerung) an dem dann ein Heizstab im Warmwasserspeicher hängt. Auf diese weise kann ich den Heizstab genau steuern (dimmen) und so fast jedes erzeugte Watt nutzen.
Raik E. schrieb: > Ich habe in meiner Unterverteilung direkt hinter dem Hauptzähler ein > Eastron SDM72M installieren lassen, dieser wird mittels einem ESP32 > ausgelesen und übermittelt den Verbrauch/Einspeisung wattgenau an einen > Thyristor Leistungssteller (Schwingungspaketsteuerung) an dem dann ein > Heizstab im Warmwasserspeicher hängt. sorry, falsches Topic, bitte kapere nicht den Thread Mach gerne einen Neuen auf - genau das was Du hier beschreibst - Schwingungspaketsteuerung - funktioniert nämlich so überhaupt nicht
Hallo Jan-Jonas, das sieht ja schon sehr vielversprechend aus mit den Logfiles vom Hoymiles WR! Ich habe zwar noch nicht nachvollziehen können wie man auf die uptime Werte kommt, aber dazu muß ich wohl mal in den Python code schauen. Und für a_count und opcode existiert bisher noch keine Erklärung. Aber Deine Erklärung und Übersetzung von a_code erscheint mir plausibel. Das könnte man ggf. auch mal mit einem Schaltnetzteil am Eingang nachprüfen, indem man z.B. die Über- und Unterspannungsfehler 215..222 provoziert. >> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über >> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) >> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1 > Guter Fund! Das ist ja in einem 0x80 Request (hier 0x0B) Zeitsetzen und Status abfragen. Kann man bei den beiden Statuslog 0x11 und Errolog 0x12 Requests evtl. darüber einen Offset mitgeben, damit man nur die letzten X-Meldungen geschickt bekommt ?
isnoAhoy schrieb: > noch nicht nachvollziehen können wie man auf die uptime > Werte kommt ich bin mir auch unsicher. Hab lange probiert das mit unterschiedlichen typen-mappings zu dekodieren und Muster zu erkennen. Hab ja selber auch 0 Dokumentation dazu, was ich da überhaupt erwarten könnte. Hab ja auch keine S-Cloud oder DTU zum probieren. Glaube dann währe das Protokoll schon fertig analysiert. :D > für a_count und opcode existiert bisher noch keine Erklärung. a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass das letzte byte payload[40:42] in der 800b response den aktuellen Zählerstand angibt. So kann die DTU ein 8011 initiieren, wenn er incrementiert um den neuen Log-Eintrag abzurufen. Würde Sinn machen, muss ich aber noch genauer beobachten. Das es den Zählerstand irgendwie gibt steht in der DTU-Pro Modbus Tech-Note [1] und der Manual von den jeweiligen Invertern drin. > Erklärung und Übersetzung von a_code erscheint mir plausibel. Zufallsfund. > man ggf. auch mal mit einem Schaltnetzteil am Eingang nachprüfen, indem > man z.B. die Über- und Unterspannungsfehler 215..222 provoziert. Freiwillige vor :D >>> Hier ist meine Beobachtung, diese Zahl inkrementiert sich, wenn ich über >>> die Cloud eine Schaltaktion für den WR mache (Turn On, turn off) >>> 800B00623B5E4B000000>0B<000000002F872B6ABD BD6A 1 >> Guter Fund! Stehen die Schaltaktionen im 8011 Log? Ist die Zahl vielleicht ein message ack von der DTU? > Das ist ja in einem 0x80 Request (hier 0x0B) Zeitsetzen und Status > abfragen. Ich würde generell sagen Poll. "Zeit setzen" scheint bei vielen (allen?) Commands außer re-transmit mit dabei zu sein. Weil ich vermute, dass der WR keine RTC besitzt, sondern die Zeit mit jedem Kommando mit bekommt. > Kann man bei den beiden Statuslog 0x11 und Errolog 0x12 Requests evtl. > darüber einen Offset mitgeben, damit man nur die letzten X-Meldungen > geschickt bekommt ? Gibt nix gutes, außer man tut es. :) Müsste man mal mehr Mitschnitte von einer DTU haben um die Bedeutung der bytes hinter der Zeit zu erraten. Weil die 18 byte zu brute-forcen, wenn man nichtmal weiß wonach man sucht, ist aussichtslos. VOr allem über die Zeit mal so beobachten, was die da noch so kommuniziert. Vor allem währe interessant, ob die modbus-Abfragen direkt an den WR durchgereicht werden oder aus dem DTU cache kommen. Wenn die direkt durch gehen dürfte es sehr leicht sein das nach zu bauen. Zudem hätte man Referenzwerte, dass man wenigstens weiß wonach man in den riesen random dekodierten Zahlenhaufen ausschau halten muss. Gurß, Jan [1] https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
rosch99 schrieb: > Ok, du verwendest NodeRed, damit ist es einfach. > Versuch mal /inverter/# zu subscriben und einen debug node dranzuhängen, > das # entspricht im MQTT einem *. Du bekommst dann alle Topics und > Werte als String im debug fenster und kannst dir die passenden > raussuchen. Hallo Rosch, genauso habe ich es jetzt gemacht, mein MQTT Sniffer zeigt jetzt auch alle Daten an. Ich fand hier: https://www.hivemq.com/mqtt-essentials/ die entscheidenden Hinweise. Allerdings steht dort auch, dass der Slash (/) nicht an erster Stelle im Topic stehen sollte. Allerdings werden die Daten sekündlich aktualisiert, der Parameter auf dem Web-UI hat bei mir auf die Aktualisierungsrate keinen Einfluss. Viele Grüße, Peter
Jan-Jonas S. schrieb: > a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass > das letzte byte payload[40:42] in der 800b response den aktuellen > Zählerstand angibt Confirmed
1 | 2022-05-12 08:56:31.787164 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 11 00 62 7c af 9c 00 00 00 00 00 00 00 00 72 99 58 |
2 | 2022-05-12 08:56:31.847991 Received 27 bytes channel 3: 95 72 22 01 43 72 22 01 43 01 00 01 80 01 00 06 31 e3 31 e3 00 00 00 00 80 02 90 |
3 | 2022-05-12 08:56:31.883198 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 00 07 3b 9c 3b 9c ff ff ff fa 80 02 00 08 3b 9c b8 |
4 | 2022-05-12 08:56:31.917849 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 03 3b 9c 00 00 00 06 80 02 00 09 60 b1 60 b1 ff ff bc |
5 | 2022-05-12 08:56:31.987761 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 04 ff fb 80 02 00 0a 60 c2 60 c2 00 00 00 05 80 02 9a |
6 | 2022-05-12 08:56:32.028280 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 05 00 0b 60 d9 60 d9 ff ff ff fb 80 02 00 0c 60 dd ac |
7 | 2022-05-12 08:56:32.092314 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 06 60 dd 00 00 00 05 80 02 00 0d 61 79 61 79 ff ff a4 |
8 | 2022-05-12 08:56:32.132800 Received 27 bytes channel 40: 95 72 22 01 43 72 22 01 43 87 ff fb 80 02 00 0e 61 81 61 81 00 00 00 05 cd 30 62 |
9 | 2022-05-12 08:56:32.637981 Payload: 00 01 80 01 00 06 31 e3 31 e3 00 00 00 00 80 02 00 07 3b 9c 3b 9c ff ff ff fa 80 02 00 08 3b 9c 3b 9c 00 00 00 06 80 02 00 09 60 b1 60 b1 ff ff ff fb 80 02 00 0a 60 c2 60 c2 00 00 00 05 80 02 00 0b 60 d9 60 d9 ff ff ff fb 80 02 00 0c 60 dd 60 dd 00 00 00 05 80 02 00 0d 61 79 61 79 ff ff ff fb 80 02 00 0e 61 81 61 81 00 00 00 05 cd 30 |
10 | payload has valid modbus crc |
11 | 80 01 00 06 31 e3 31 e3 00 00 00 00: |
12 | uptime=3:32:51 a_count=6 opcode=128 a_code=1 a_text=Inverter start |
13 | BBHHHHH: (128, 1, 6, 12771, 12771, 0, 0) |
14 | 80 02 00 07 3b 9c 3b 9c ff ff ff fa: |
15 | uptime=4:14:20 a_count=7 opcode=128 a_code=2 a_text=Producing power |
16 | BBHHHHH: (128, 2, 7, 15260, 15260, 65535, 65530) |
17 | 80 02 00 08 3b 9c 3b 9c 00 00 00 06: |
18 | uptime=4:14:20 a_count=8 opcode=128 a_code=2 a_text=Producing power |
19 | BBHHHHH: (128, 2, 8, 15260, 15260, 0, 6) |
20 | 80 02 00 09 60 b1 60 b1 ff ff ff fb: |
21 | uptime=6:52:33 a_count=9 opcode=128 a_code=2 a_text=Producing power |
22 | BBHHHHH: (128, 2, 9, 24753, 24753, 65535, 65531) |
23 | 80 02 00 0a 60 c2 60 c2 00 00 00 05: |
24 | uptime=6:52:50 a_count=10 opcode=128 a_code=2 a_text=Producing power |
25 | BBHHHHH: (128, 2, 10, 24770, 24770, 0, 5) |
26 | 80 02 00 0b 60 d9 60 d9 ff ff ff fb: |
27 | uptime=6:53:13 a_count=11 opcode=128 a_code=2 a_text=Producing power |
28 | BBHHHHH: (128, 2, 11, 24793, 24793, 65535, 65531) |
29 | 80 02 00 0c 60 dd 60 dd 00 00 00 05: |
30 | uptime=6:53:17 a_count=12 opcode=128 a_code=2 a_text=Producing power |
31 | BBHHHHH: (128, 2, 12, 24797, 24797, 0, 5) |
32 | 80 02 00 0d 61 79 61 79 ff ff ff fb: |
33 | uptime=6:55:53 a_count=13 opcode=128 a_code=2 a_text=Producing power |
34 | BBHHHHH: (128, 2, 13, 24953, 24953, 65535, 65531) |
35 | 80 02 00 0e 61 81 61 81 00 00 00 05: |
36 | uptime=6:56:01 a_count=14 opcode=128 a_code=2 a_text=Producing power |
37 | BBHHHHH: (128, 2, 14, 24961, 24961, 0, 5) |
38 | 2022-05-12 08:56:32.645194 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 12 00 62 7c af 9c 00 00 00 00 00 00 00 00 71 9a 5b |
39 | 2022-05-12 08:56:32.702398 Received 15 bytes channel 75: 95 72 22 01 43 72 22 01 43 81 00 01 70 c0 a5 |
40 | 2022-05-12 08:56:33.204835 Payload: 00 01 70 c0 |
41 | payload has valid modbus crc |
42 | Poll inverter 114172220143 |
43 | 2022-05-12 08:56:33.206615 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 7c af a1 00 00 00 05 00 00 00 00 39 42 ea |
44 | 2022-05-12 08:56:33.258071 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 8c |
45 | 2022-05-12 08:56:33.293355 Received 27 bytes channel 61: 95 72 22 01 43 72 22 01 43 02 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 ec |
46 | 2022-05-12 08:56:33.363660 Received 23 bytes channel 61: 95 72 22 01 43 72 22 01 43 83 00 03 00 a1 03 e8 01 6c 00 0f 42 e7 98 |
47 | 2022-05-12 08:56:33.866489 Payload: 00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 00 03 00 a1 03 e8 01 6c 00 0f 42 e7 |
48 | 2022-05-12 08:56:33.866489 Decoded: 36.4 phase0=voltage:229.1, current:16.1, power:369.6, frequency:49.99 string0=voltage:32.2, current:5.98, power:192.7, total:49.378, daily:211 string1=voltage:32.4, current:6.01, power:194.3, total:47.099, daily:215 |
wobei
1 | ~ # python3 |
2 | Python 3.9.2 (default, Mar 12 2021, 04:06:34) |
3 | [GCC 10.2.1 20210110] on linux |
4 | Type "help", "copyright", "credits" or "license" for more information. |
5 | >>> import struct |
6 | >>> struct.unpack('>HHHHHHLLHHHHHHHHHHH', bytes.fromhex('00 01 01 42 02 56 07 87 01 44 02 59 07 97 00 00 c0 e2 00 00 b7 fb 00 d3 00 d7 08 f3 13 87 0e 70 00 03 00 a1 03 e8 01 6c 00 0f 42 e7')[:42])
|
7 | (1, 322, 598, 1927, 324, 601, 127336448, 3236036608, 47099, 211, 215, 2291, 4999, 3696, 3, 161, 1000, 364, 15) |
Oben sind doch erst 14 Fehler im Speicher? Richtig. Dazwischen ist aber noch der 8012-Request (leer). Der setzt einen zusätzlichen Fehler (code 2). 15. Gruß, Jan
Pintopf schrieb: > Ich fand hier: > https://www.hivemq.com/mqtt-essentials/ > die entscheidenden Hinweise. > Allerdings steht dort auch, dass der Slash (/) nicht an erster Stelle im > Topic stehen sollte. Ja, im Gegensatz zu filesystemen ist das bei MQTT nicht üblich. Dazu muss aber der Default-Eintrag in der setup page geändert werden, ich habe das bei mir angepasst. Ebenso sollte am Ende kein / stehen, das wird aut. angehängt. Ich habe das auch erst mit dem Sniffer bemerkt weil nix "angekommen" ist ;-)
Hallo zusammen ich logge nun seit mehreren Wochen die Werte meines HM-600 alle 5 Minuten pro Tag mit. Wenn ich mir die Tagesendezahlen ansehe fällt mir folgendes auf: 1) Ertrag Woche steigt permanent an; das sollte doch eigentlich immer in etwa gleich sein. 2) Die Differenz von 2 Tagen Ertrag Woche und 2 Tagen Ertrag gesamt passt nie. 3) die Differenz Tagesanfang zu Tagesende von Ertrag Woche und Ertrag Gesamt sollte doch gleich sein, aber passt auch nie; da gibt da Differenzen bis über 100 Wh. 4) Ertrag Total kann nicht stimmen, denn wenn ich meine Dachanlage von 3,87 KWp runterrechne auf 0,6 KWp müsste der Gesamtertrag mindestens doppelt so hoch sein. Hat schon jmd ähnliches beobachtet oder sind die beiden Werte was ganz anderes?
Hubi schrieb: > Hat schon jmd ähnliches beobachtet oder sind die beiden Werte was ganz > anderes? Hallo Hubi, ich gehe davon aus du nutzt die ESP8266 Version aus [1]? In dieser Version stimmt die Byte Zuordnung vmtl. nicht. Dies hängt auch damit zusammen, dass hier wohl noch keine Fragmentübergreifenden Datenwerte unterstützt werden (diese kommen laut aktuellem Stand wohl nur beim HM-600 vor). Die Python Version implementiert dies bereits. Hintergrund ist, dass der Wert der beim HM-600 als Weekly Wert angegeben wird in Wahrheit der Total Wert für den 2. Kanal ist. Dieser läuft aber ggf. wöchentlich über. Der Überlauf wird in einem anderen Datenfragment übertragen (man müsste wie im Python Code alle übertragenen Fragmente zusammenfügen und Auswerten) [1] https://github.com/grindylow/ahoy
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > Jan-Jonas S. schrieb: >> a_count ist mit Sicherheit der event-Zähler. Ich bin auf der Spur, dass Hallo Jan, leider kann ich kein py. So wie ich es verstehe, ergibt sich z.B. bei mir folgender zerlegter Block (Hand bearbeitet): W1 W2 W3 W4 W5 W6 B1 2 3 4 5 6 7 8 9 10 11 12 0001 Hex Dez 8001 0006 1698 1698 0000 0000 ; 1698 > 5784 /60 = 96 /60=1:36:xx ; 8002 0007 4F16 4F16 FFFF FFDF ; 4F16 > 20246/60 = 337/60=5:37:xx ; 8002 0008 5CC9 5CC9 FFFF F261 ; 5CC9 > 23753/60 = 395/60=6:35:xx ;F2=242 8002 0009 5D0E 5D0E FFFF FFA7 ; 5D0E > 23822/60 = 397/60=6:37:xx ; 8002 000A 641D 641D FFFF F8F1 ; 641D > 25629/60 = 427/60=7:07:xx ;F8=248 8002 000B 64DE 64DE FFFF FF3F ; 64DE > 25822/60 = 430/60=7:10:xx ; 8002 000C 657D 657D FFFF FF61 ; 657D > 25981/60 = 433/60=7:13:xx ; 8002 000D 6679 6679 FFFF FF18 ; 6679 > 26233/60 = 437/60=7:17:xx ; 8002 000E 754A 754A FFFF F12F ; 754A > 30026/60 = 500/60=8:00:xx ;F1=241 34E7 a) Nur was sollen mir die Worte W1 bis W6 sagen ? Ich habe gegen 12:41 Uhr mit der Aufzeichnung begonnen. Der WR arbeitet aber schon sehr viel früher. Also "Uptime" in der Zeile 8001 mit 1:36:xx kann nicht sein. b) Welches Wort/Byte (W1 bis W6/B1 bis B12) soll Bitte der Alarmcode sein?
:
Bearbeitet durch User
Zu deiner Feststellung: Hubi schrieb: > 4) Ertrag Total kann nicht stimmen, denn wenn ich meine Dachanlage von > 3,87 KWp runterrechne auf 0,6 KWp müsste der Gesamtertrag mindestens > doppelt so hoch sein. zitiere ich mich mal selber: Pintopf schrieb: > Mir ist allerdings aufgefallen, dass die angezeigte Gesamt-Energiemenge > (YieldTotal) nur ungefähr halb so groß ist, wie die von meiner Homematic > gemessenen Werte. > Jetzt habe ich mir mal die RF24 Payload über die serielle Schnittstelle > ausgeben lassen und nach den fehlenden Daten gesucht. In dem Bild im > Anhang habe ich den vermeindlichen Fundort markiert. > Könnte jemand von euch das verifizieren? Danke für die Mitteilung, dass es bei dir genauso ist. In meinem Originalbeitrag habe ich auch die Stelle im Datenfeld markiert, wo ich den Gesamtertrag des ersten Moduls vermute. Gruß Peter
Herbert K. schrieb: > b) Welches Wort/Byte (W1 bis W6/B1 bis B12) soll Bitte der Alarmcode > sein? Hier https://github.com/Sprinterfreak/ahoy/blob/pypackage/tools/rpi/hoymiles/decoders/__init__.py#L310 ist die zeile, wo ich zuordne. Lass mich versuchen das ein wenig zu veranschaulichen
1 | opcode, a_code, a_count, uptime, u, u, u = struct.unpack('>BBHHHHH', chunk)
|
2 | |
3 | B B H H H H H |
4 | 00 d4 00 07 30 6a 00 00 00 00 00 00 |
5 | | | | | |
6 | | | | \_ uptime seconds(?) |
7 | | | \_ a_count |
8 | | \__ a_code |
9 | \_ opcode |
Das schöne an python ist, geht auch interaktiv. Auf der Konsole am Beispiel von Thomas die Payload von "Port 4 no input"
1 | ~ # python3 |
2 | Python 3.9.2 (default, Mar 12 2021, 04:06:34) |
3 | [GCC 10.2.1 20210110] on linux |
4 | Type "help", "copyright", "credits" or "license" for more information. |
5 | >>> import struct |
6 | >>> struct.unpack('>BBHHHHH', bytes.fromhex('00 d4 00 07 30 6a 00 00 00 00 00 00'))
|
7 | (0, 212, 7, 12394, 0, 0, 0) |
8 | >>> |
Alle Zeilen mit ">>>" sind manuelle Eingaben. So kann man recht fix und
effektiv an den Payloads rum doktorn. `import struct` macht das Modul
struct verfügbar.
struct.unpack string '>' endian-big, 'B' sind 2 byte (unsigned char),
'H' sind 4 byte (unsigned short)
chunk = bytes.fromhex('00 11 22 33 44 55')
wandelt einen schön lesbaren byte string in ein byte array um, mit dem
struct arbeiten kann.
Gruß,
Jan
Jan-Jonas S. schrieb: > Herbert K. schrieb: ... > B B H H H H H > 00 d4 00 07 30 6a 00 00 00 00 00 00 > | | | | > | | | \_ uptime seconds(?) > | | \_ a_count > | \__ a_code > \_ opcode DANKE Jan !
Noch schöner ist, man kann die Decoder auch so auf der Konsole ausprobieren Im Verzeichnis tools/rpi/ python3 ausführen:
1 | root@dtu ~/ahoy/tools/rpi (git)-[pypackage] # python3 |
2 | Python 3.9.2 (default, Mar 12 2021, 04:06:34) |
3 | [GCC 10.2.1 20210110] on linux |
4 | Type "help", "copyright", "credits" or "license" for more information. |
5 | >>> import hoymiles |
6 | >>> hoymiles.decoders.HM1200_Decode11(bytes.fromhex('00 01 80 01 00 06 30 62 30 62 00 00 00 00 00 d4 00 07 30 6a 00 00 00 00 00 00 b0 02 00 48 4c f7 4c f7 00 00 00 05 b0 02 00 49 55 da 55 da ff ff ff fb b0 02 00 4a 55 ed 55 ed 00 00 00 05 b0 02 00 4b 56 72 56 72 ff ff ff fb b0 02 00 4c 56 72 56 72 00 00 00 06 b0 02 00 4d 56 79 56 79 ff ff ff fb b0 02 00 4e 56 82 56 82 00 00 00 05 b0 02 00 4f 56 e7 56 e7 ff ff ff fb b0 02 00 50 56 f3 56 f3 00 00 00 05 b0 02 00 51 57 1d 57 1d ff ff ff fb b0 02 00 52 57 23 57 23 00 00 00 05 b0 02 00 53 57 4f 57 4f ff ff ff fb b0 02 00 54 57 51 57 51 00 00 00 05 05 ab'))
|
7 | payload has valid modbus crc |
8 | 80 01 00 06 30 62 30 62 00 00 00 00: |
9 | uptime=3:26:26 a_count=6 opcode=128 a_code=1 a_text=Inverter start |
10 | BBHHHHH: (128, 1, 6, 12386, 12386, 0, 0) |
11 | 00 d4 00 07 30 6a 00 00 00 00 00 00: |
12 | uptime=3:26:34 a_count=7 opcode=0 a_code=212 a_text=Port 4 no input |
13 | BBHHHHH: (0, 212, 7, 12394, 0, 0, 0) |
14 | b0 02 00 48 4c f7 4c f7 00 00 00 05: |
15 | uptime=5:28:23 a_count=72 opcode=176 a_code=2 a_text=Producing power |
16 | BBHHHHH: (176, 2, 72, 19703, 19703, 0, 5) |
17 | b0 02 00 49 55 da 55 da ff ff ff fb: |
18 | uptime=6:06:18 a_count=73 opcode=176 a_code=2 a_text=Producing power |
19 | BBHHHHH: (176, 2, 73, 21978, 21978, 65535, 65531) |
20 | b0 02 00 4a 55 ed 55 ed 00 00 00 05: |
21 | uptime=6:06:37 a_count=74 opcode=176 a_code=2 a_text=Producing power |
22 | BBHHHHH: (176, 2, 74, 21997, 21997, 0, 5) |
23 | b0 02 00 4b 56 72 56 72 ff ff ff fb: |
24 | uptime=6:08:50 a_count=75 opcode=176 a_code=2 a_text=Producing power |
25 | BBHHHHH: (176, 2, 75, 22130, 22130, 65535, 65531) |
26 | b0 02 00 4c 56 72 56 72 00 00 00 06: |
27 | uptime=6:08:50 a_count=76 opcode=176 a_code=2 a_text=Producing power |
28 | BBHHHHH: (176, 2, 76, 22130, 22130, 0, 6) |
29 | b0 02 00 4d 56 79 56 79 ff ff ff fb: |
30 | uptime=6:08:57 a_count=77 opcode=176 a_code=2 a_text=Producing power |
31 | BBHHHHH: (176, 2, 77, 22137, 22137, 65535, 65531) |
32 | b0 02 00 4e 56 82 56 82 00 00 00 05: |
33 | uptime=6:09:06 a_count=78 opcode=176 a_code=2 a_text=Producing power |
34 | BBHHHHH: (176, 2, 78, 22146, 22146, 0, 5) |
35 | b0 02 00 4f 56 e7 56 e7 ff ff ff fb: |
36 | uptime=6:10:47 a_count=79 opcode=176 a_code=2 a_text=Producing power |
37 | BBHHHHH: (176, 2, 79, 22247, 22247, 65535, 65531) |
38 | b0 02 00 50 56 f3 56 f3 00 00 00 05: |
39 | uptime=6:10:59 a_count=80 opcode=176 a_code=2 a_text=Producing power |
40 | BBHHHHH: (176, 2, 80, 22259, 22259, 0, 5) |
41 | b0 02 00 51 57 1d 57 1d ff ff ff fb: |
42 | uptime=6:11:41 a_count=81 opcode=176 a_code=2 a_text=Producing power |
43 | BBHHHHH: (176, 2, 81, 22301, 22301, 65535, 65531) |
44 | b0 02 00 52 57 23 57 23 00 00 00 05: |
45 | uptime=6:11:47 a_count=82 opcode=176 a_code=2 a_text=Producing power |
46 | BBHHHHH: (176, 2, 82, 22307, 22307, 0, 5) |
47 | b0 02 00 53 57 4f 57 4f ff ff ff fb: |
48 | uptime=6:12:31 a_count=83 opcode=176 a_code=2 a_text=Producing power |
49 | BBHHHHH: (176, 2, 83, 22351, 22351, 65535, 65531) |
50 | b0 02 00 54 57 51 57 51 00 00 00 05: |
51 | uptime=6:12:33 a_count=84 opcode=176 a_code=2 a_text=Producing power |
52 | BBHHHHH: (176, 2, 84, 22353, 22353, 0, 5) |
1 | import hoymiles # läd das Modul hoymiles |
2 | # hoymiles.decoders korrespondiert zu hoymiles/decoders/__init__.py |
3 | hoymiles.decoders.HM1200_Decode11(bytes payload) |
HM1200_Decode11 erwartet als Argument die payload bytes. Die kann man sich wieder mit bytes.fromhex() aus dem lesbaren String aus den Logs hin konvertieren und mit einer Payload so oft wie man will verschiedene Änderungen am Code ausprobieren.
:
Bearbeitet durch User
Moin, ich habe seit gestern auch einen HM-1500 im Einsatz, es sollen noch ein paar weitere folgen. Ich nutze einen ESP8266 mit dem Funkmodul und der Ahoi-Software. Das Auslesen und Anzeigen der Werte per Weboberfläche hat auf Anhieb geklappt, ich bin begeistert. Danke an die Community für dieses starke Projekt. Ich versuche auch meinen Teil beizutragen, falls es irgendwie möglich ist. Im MQTT war mir aufgefallen, dass die Werte trotz Einstellung von 10s Intervall im Sekundentakt gesetzt wurden. Ich habe den Wert dann mal höher gesetzt, aber nach einiger Zeit war der 1s Intervall wieder da. In der Datei \tools\esp8266\app.cpp sollte es in der Zeile 181 wahrscheinlich
1 | mMqttTicker = 0; |
statt
1 | mMqttInterval = 0; |
sein, damit klappt es bei mir jedenfalls. Leider wird mir im Git-Commit die ganze Datei als Änderung angezeigt statt nur der einen Zeile, ich versuche zu klären warum und mache dann einen PullRequest wenn gewünscht. Aber die kleine Änderung könnte ja auch jemand anderes schnell übernehmen. Gruß, sude
:
Bearbeitet durch User
Hallo, erst einmal vielen Dank für die tolle Software, sie funktioniert ausgezeichnet mit meinem HM-400. Nun eine Frage an die Experten: Ich habe an meinem Smart-Meter bereits einen Energieverbrauchsmanager von Iungo (www.iungo.nl) angeschlossen, der kann auch Solaranlagen über einen Modbus Energiezähler monitoren, dazu kann mann z.B. einen Standard RS485 Modbus/USB Adapter verwenden und ihn in den USB Port vom Iungo verbinden. Ich frage mich nun ob ich nicht den Wemos D1 mini in den USB Port stöpseln könnte um einen Modbus Energiezähler und USB Adapter zu emulieren. Würde das funktionieren und was müsste ich grob dafür implementieren? Vielen Dank für die Hilfe. Grüße, Stefan
Hallo zusammen, ich habe seit heute auch einen HM-1500. =) Würde hier beim reenginering mit Unterstützen. Gibt es hier zufällig jemand der auf Github etwas voran getragen hat was man alles braucht? Ich habe bei mir noch mehrere ESP8266 und irgendwo in der schublade 3x NRF24LE1E. Um hier zwecks logging zu helfen, wie wird es miteinander verdrahten und auf welcher Basis wird das ganze in das ESP geflasht? Ich würde mir heute wenn ich dazu komme die App decompilen und mir schauen ob man weitere Interessante Infos rausziehen kann. PS: Wie wäre es mit einem IRC-Chat und/oder Discord, dann könnte man doch mal ein Abend damit verbringen sich zusammen das anzuschauen. Was sagt ihr dazu? Beste Grüße.
Hallo, kleiner Fortschritt (weiß nicht inwieweit das vom Nutzen her hilft): this.memoizedIsInitialized = (byte) -1; this.pvSn_ = 0L; this.pvPort_ = 0; this.pvVol_ = 0; this.pvCur_ = 0; this.pvPower_ = 0; this.pvEnergyTotal_ = 0; this.gridVol_ = 0; this.gridVolMax_ = 0; this.gridFreq_ = 0; this.gridP_ = 0; this.gridQ_ = 0; this.gridI_ = 0; this.gridPf_ = 0; this.pvTemp_ = 0; this.pvRunStatus_ = 0; this.pvFaultNum_ = 0; this.pvFaultCnt_ = 0; this.pvWarnningCnt_ = 0; this.pvLinkStatus_ = 0; this.pvSendP_ = 0; this.pvRevP_ = 0; this.pvTime_ = 0; this.pvEnergy_ = 0; this.miSignal_ = 0; So bin später wieder aktiv da.
Hallo Stefan, das mit dem Modbus Energiezähler der dann an den ESP angeschloßen wird klingt interessant. Ob das an dem Modell von Dir so einfach geht kann ich nicht sagen, da ich keine Ahnung habe was der für Kommandos über Modbus absetzt, oder ob der nur abgefragt werden kann ? Auf der anderen Seite der ESP8266 mit Ahoy Software ist aktuell auch noch nicht so weit, daß er bereits Kommandos an die Hoymiles Wechselrichter senden könnte. Wir können m.W. bisher nur lesen, die aktuellen Leistungsdaten 0x0B und den Ereignis- 0x11 bzw. Fehlerspeicher 0x12. Die Modbus Kommandos, die z.B. die Hoymiles DTU Pro versteht und unterstützt kann unsere Software (Python oder ESP) bisher auch noch nicht. Hallo Daniel, die ESP Verdrahtung ist im Verzeichnis doc/getting-started-ESP8266: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Viel Erfolg beim basteln und kompilieren. Was die Liste der Definitionen von Dir angeht, hab ich keine Ahnung wie uns das so weiterhelfen soll, vielleicht kannst Du noch ein bisschen mehr dazu schreiben. Andererseits sind in tools/esp8266/hmDefines.h die entsprechenden Felder der Payloads bereits hinterlegt. Lukas arbeitet aktuell daran die Frames/Pakete einzeln zu verifizieren und dann die gesamte Payload auf einmal zu lesen. Da steht ja auch nochmal eine CRC16/CRC_M Prüfsumme am Ende (0x8y Paket). https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmDefines.h#L59
Hallo Stefan, hier ist die Anleitung zum Modbus Adapter Deiner iungo Anlage: https://www.iungo.nl/images/pdf/handleiding_modbus_16012019.pdf Die Anleitung habe ich nur auf niederländisch gefunden. Maar meijn Nederlands is nit prittig. Auf dem Titelbild ist ein Eastron SDM630/Modbus V2 abgebildet. Hast Du den auch ?
Angehängte Dateien:
Moin zusammen, @isnoAhoy: vielen dank für die Info mit der Verdrahtung. Das werde ich mir anschauen und das ganze mal in Ruhe Aufbauen. :) Zu meiner Infos von weiter oben, da gebe ich dir recht und hole noch etwas weiter aus. Ich habe in der Vergangenheit auch bei anderen Programmen reingeneering durchgeführt (Haupts. nur C# decompiliert). Nun da ich kein Programm habe um es mir am PC anzuschauen, habe ich einfach die App im Google Appstore angeschaut. Da ich mit Java kaum was am Hut habe, ist es für mich hier etwas schwierig passende Infos raus zu ziehen. Die Infos oben ist ein Schnipsel von der App "S-Miles Endbenutzer". - Das ist doch die App? Es bringt denke ich soweit uns an Infos was alles damit ausgelesen werden kann. Natürlich fehlen bestimmt weitere Dinge (Volt, Ampere, Watt, Blindleistung, Leistungsfaktor (Pf.), ...). Im Anhang mal ein Screenshot. Ich muss noch schauen wie die App genauer Aufgebaut ist. Oder gibt es ein PC Programm wo man es Runterladen kann? :)
:
Bearbeitet durch User
Hallo Daniel, jetzt hast Du mich neugierig gemacht, ich habe zwei Apps von Hoymiles gefunden: S-Miles Enduser und S-Miles Installer. Welche hast Du denn runtergeladen und vor allem wie ? Ich finde keinen Link zum Download auf dem PC. https://play.google.com/store/apps/developer?id=Hoymiles+Converter+Technology+Co.,+Ltd.&gl=US Welchen Decompiler hast Du verwendet ? Ich habe meist gute Ergebnisse mit jd-gui von Emmanuel Dupuy gehabt. Auch der Support ist Klasse, falls mal was nicht geht, so wie Lambda Functions, dann hatte er das innerhalb von wenigen Tagen eingebaut! https://github.com/java-decompiler/jd-gui/ Das Ganze ist dann zwar nur die Mobile App, die mit der DTU kommuniziert und vermutlich nicht alles abdeckt, was z.B. die DTU Pro über den Modbus einstellen kann, aber es wäre immerhin eine gute Option herauszufinden, was die App mit den ersten vier Stellen der Seriennummer macht, bzw. wie die Datenpakete von der DTU zur App übertragen werden...
Hallo zusammen. Wenn es nur um das Monitoring des Ertrags geht, waere das Shelly Plug hier nuetzlich (https://www.gartenkraftwerke.de/c/unsere-pakete/zubehoer). Das Teil baut sein eigenes WLAN auf und bietet eine Webseite, von der man dann mit z.B. wget die Daten von Interesse auslesen kann. Das habe ich mit einem Kostal 10.1 so gemacht und habe z.B. fuer jede volle Stunde den Tagesertrag und den Gesamtertrag ueber die Lebensdauer des WR. Hoffe, das hilft dem einen oder andern.
Angehängte Dateien:
Moin, richtig es existieren zwei Apps. Die Version "Installer" ist für den Techniker für großen Anlagen gedacht (leite ich jetzt mal so heraus). Für den Endbenutzer gibt es die andere App. Diese konnte ich (wie weiter oben beschrieben) mit den Zugangsdaten einloggen und Daten auslesen. Jetzt muss ich hier jedoch sagen, ich weiß natührlich nicht ob die App mit einer DTU direkt kommuniziert (hab keine DTU) und/oder ob es mit der Cloud sich verbindet. Die Endbenutzer-App funtioniert bei mir anscheinend mit der Cloud. Ich habe die App bei mir Installiert (direkt aus der Google PlayStore) und danach mittels einer weiteren App als apk exportiert (App Extractor). Diese apk, habe ich auf meinem PC übertragen und nutze aktuell JADX-GUI (https://github.com/skylot/jadx). Java ist nicht mein Favorit, da muss ich ehrlich sein. Jedoch gibt es leider meines wissens nach nur die Weboberfläche und die Mobile Variante um die Daten auszuwerten. ----------------------------------------------- Die Apps sind teils obfuskiert (namen von variabeln sind umbenannt). Das Tool JADX leistet hier aber soweit ich das einschätzen kann gute Arbeit beim deobfuskieren (Tools -> Deobfuskierung). Die Hauptstruktur ist von der Baumstruktur so: /com/hoymiles/... da liegen ganze classen, methoden und co ab. p000 besitzt auch hier Teils Interessante Daten. Was mich stutzig macht: Wenn man eine globale Textsuche startet (Info: Am Anfang wird die ganze APK dann Dekompiliert. Dauert bevor man eine Suche starten kann), dann kam mir auch Methoden/Classen entgegen mit dem Namen "Miner". Ich dachte erstmal, wird die App als Miner im Hintergrund verwendet? O.o - Naja habe das aber nicht weiter beachtet. Info: Es gibt ein Indiz das auch die Cloud bei Alibaba gehostet wird. Einerseits da es als Klasse benammt wird und zweitens die hinterlegten Domain: >ping m.hoymiles.com Ping wird ausgeführt für m.hoymiles.com [119.3.31.20] mit 32 Bytes Daten: Antwort von 119.3.31.20: Bytes=32 Zeit=312ms TTL=37 Die IP-Adresse zeigt nach China (https://ipinfo.io/AS55990/119.3.0.0/19-119.3.31.0/25) Gruß
Also ich würde mir da nicht zuviel versprechen von den Apps .... ich denk' mir, die kommunizieren sicher nur der Hoymiles Cloud ..... a) die App funktioniert ja überall, also muss sie mit der Hoymiles Cloud in Verbindung stehen b) was sollte die App mit der DTU direkt zu bereden haben, wenn die Cloud bereits alle Funktionen abbildet.
Moin Martin, ein Stückweit gebe ich dir hier recht. Jedoch können wir uns doch über die App Informationen gewinnen, was für Daten übertragen werden können und somit später bei der Indentifizierung uns dabei helfen? - Können die App auch gern vorerst beiseite legen und erstmal weiter mit der Auswertung kümmern. :) Idee: Hat schon jemand die den WR ausseinander genommen und mittels einem LogicAnalyzer kurz vor dem TX die Daten mitgelauscht und gleichzeitig beim Empfänger nach dem RX die Daten verglichen?
Hallo Daniel, bitte lies erstmal die vorangegangenen 4 Seiten dieses Threads, da steht nämlich u.a. wie Martin seine DTU zerlegt und genau am RX/TX zwischen GD32 MCU und nRF24 Radio die ersten Mitschnitte gemacht hat. Andere haben mit einem HackRF Mitschnitte des Funkverkehrs gemacht. Darauf basiert auch der aktuelle Code für ESP (Lukas) als auch die noch aktuellere Version für Python (Jan-Jonas) Aktuell fehlen weitere Mitschnitte für Kommandos die die DTU an den Wechselrichter sendet, z.B. aktiv/disabled, Limit setzen, Zero Export Control, etc. Die alten Hoymiles String-Wechselrichter hießen MI (= MicroInverter), daher stammt vielleicht auch das Präfix Mi in den Klassen, Methoden und Variablennamen der App ? Aber Ausschließen will ich nichts an der Stelle. @Sorbit, ja ich habe Aaron (atc1441) schon gefragt was er von den aktuellen Versuchen der Hoymiles Inverter hier im Forum hält. Er hat leider keinen HM Wechselrichter und kann daher wenig zur Entwicklung beitragen, obwohl ihn das Thema BLE speziell mit nRF52 etc. nach wie vor interessiert. Wenn jemand will, kann er ihn ja in Hamburg kontaktieren, vielleicht hat er ja ein bißchen Zeit neben seinem neuen Job und schaut mal in einen Hoymiles Wechselrichter rein. Ich habe versucht meinen aufzuschrauben bin aber an den Kabelzugentlastungen und der Verklebung der Metallplatte gescheitert. Da ich meinen auf dem Balkon installieren möchte sollte er auch weiter wasserdicht bleiben. Beim "Freundlichen Händler" meines Vertrauens hat man mir auch gesagt, dieser hätte bisher keine Rückläufer mit Defekt, die man mal aufschrauben könnte.
Ich habe zwar alle Seiten mir angeschaut, aber bin bei den großen Mitschnitten via HackRF nicht komplett durchgegangen. ^^ Cool ist es aufjedenfall was ihr schon alles herausgefunden habt. Da kann ich definitiv euch nur loben! Die fehlenden Kommandos die die DTU an den Wechselrichter senden, könnte man doch nur mit der DTU-Pro version herausbekommen oder? Dein Ansatz mit dem Präfix kann gut möglich sein. Ich bin mir am überlegen so ein Pro zu Organisieren, aber aktuell nicht ganz einfach. https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html PS: Die Login Daten im Shop kann man auch mit der App nutzen, aber das wisst ihr bestimmt schon.
Angehängte Dateien:
Meine Prototype mit ESP8266 im Gehäuse. Trotz der dichten Packung funktioniert die Kommunikation mit dem WR.
Hallo zusammen, habe nun alles zusammengebaut... Leider bekomme ich folgende Meldung: Warn: your settings are not valid! check [IP]/setup Was ist denn falsch? Edit: Hat sich erledigt, ich komme drauf und bin alles am Eintragen. Die Frage, woher bekomme ich die SNr. habe ein 1500.
:
Bearbeitet durch User
Daniel R. schrieb: > Die Frage, woher bekomme ich die SNr. habe ein 1500. Steht auf der glatten Seite / Rückseite auf 2 Aufklebern.
Danke, boa darauf muss man erstmal kommen. Aber stimmt, wenn ich die ersten Zeichen hier Suche gibt es überschneidungen. :) Mercii! PS: Spannung kommt von meinem Labornetzteil. Solarmodule brauchen noch bis sie da sind. :) Erste Log: Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 01 00 05 00 02 4D Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9A Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 FB 00 13 6D AD 39 Solarkraftwerk/ch3/U_DC: 22.000 V Solarkraftwerk/ch3/I_DC: 0.010 A Solarkraftwerk/ch3/P_DC: 0.200 W Solarkraftwerk/ch4/I_DC: 0.050 A Solarkraftwerk/ch4/P_DC: 1.200 W Solarkraftwerk/ch0/Temp: 25.100 ° Solarkraftwerk/ch4/U_DC: 22.000 V 0 (0000) 1 (0001) 2 (0002) 2 (0020) -> missing: 1 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 AP will be closed in 152 seconds Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 01 00 05 00 02 4D Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9A Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 FA 00 13 AD FC A9 0 (0000) 1 (0001) 1 (0001) 3 (0030) -> missing: 1 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 01 00 05 00 02 4D Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9A Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 FB 00 13 6D AD 39 Solarkraftwerk/ch3/U_DC: 22.000 V Solarkraftwerk/ch3/I_DC: 0.010 A Solarkraftwerk/ch3/P_DC: 0.200 W Solarkraftwerk/ch4/I_DC: 0.050 A Solarkraftwerk/ch4/P_DC: 1.200 W Solarkraftwerk/ch0/Temp: 25.100 ° Solarkraftwerk/ch4/U_DC: 22.000 V 0 (0000) 1 (0001) 2 (0002) 2 (0020) -> missing: 1 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 AP will be closed in 142 seconds Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 01 00 05 00 02 4D Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9A Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 FB 00 13 6D AD 39 0 (0000) 6 (3003) 2 (0020) 2 (0200) -> missing: 1 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DD 00 01 00 05 00 02 4C Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9A Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 FB 00 13 FD B1 B5 Solarkraftwerk/ch3/U_DC: 22.100 V Solarkraftwerk/ch3/I_DC: 0.010 A Solarkraftwerk/ch3/P_DC: 0.200 W Solarkraftwerk/ch4/I_DC: 0.050 A Solarkraftwerk/ch4/P_DC: 1.200 W Solarkraftwerk/ch0/Temp: 25.100 ° Solarkraftwerk/ch4/U_DC: 22.100 V 0 (0000) 5 (2003) 3 (0030) 2 (0200) -> missing: 1 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 0 (0000) 0 (0000) 0 (0000) 0 (0000) -> missing: 4 AP will be closed in 132 seconds Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 01 00 05 00 02 4D Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9A Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 F9 00 13 AD 0C 5A
:
Bearbeitet durch User
“Danke, boa darauf muss man erstmal kommen.” Handbuch lesen sollte wohl möglich sein;-( Auch mit Schreib- und Leseschwäche…
Hallo Daniel, wo Du doch schon den Source Code der App decompiliert hast. Wir haben eine Liste mit Status / alarm_codes von den Wechselrichtern. Kannst Du mal schauen ob Du die auch irgendwo im App Code findest ? https://github.com/Sprinterfreak/ahoy/commit/e473583a5536b4f8ffb7099d3510912db84928a1
Hallo Ahoy,
ich schau mal fix drauf. Rest mach ich morgen. :)
Wenn ich gleich noch was finde, gebe ich eine Rückmeldung.
Gibt es die möglichkeit die Logs irgendwo gesammelt zusammen zu tragen?
Vielleicht können auch andere Infos herauslesen die Interessant sind,
was denkt ihr?
Edit: --------------------------------
Folgendes konnte ich auf anhieb finden (code gekürzt):
private APPDtuInfoMO(CodedInputStream input, ExtensionRegistryLite
extensionRegistry) throws InvalidProtocolBufferException {
this();
boolean z = false;
while (!z) {
try {
try {
int readTag = input.readTag();
switch (readTag) {
case 0:
break;
case 8:
this.deviceKind_ = input.readInt32();
continue;
case 16:
this.dtuSw_ = input.readInt32();
continue;
case 24:
this.dtuHw_ = input.readInt32();
continue;
case 32:
this.dtuStepTime_ = input.readInt32();
continue;
case 40:
this.dtuRfHw_ = input.readInt32();
continue;
case 48:
this.dtuRfSw_ = input.readInt32();
continue;
case 56:
this.accessModel_ = input.readInt32();
continue;
case 64:
this.communicationTime_ =
input.readInt32();
continue;
case 72:
this.signalStrength_ =
input.readInt32();
continue;
case 82:
this.gprsVsn_ = input.readBytes();
continue;
case 90:
this.wifiVsn_ = input.readBytes();
continue;
case 98:
this.kaNub_ = input.readBytes();
continue;
case 104:
this.dtuRuleId_ = input.readInt32();
continue;
case 112:
this.dtuErrorCode_ = input.readInt32();
continue;
case 120:
this.dtu485Mode_ = input.readInt32();
continue;
case 128:
this.dtu485Addr_ = input.readInt32();
continue;
case 136:
this.sub1GFqband_ = input.readInt32();
continue;
case 144:
this.sub1GChtnum_ = input.readInt32();
continue;
case 152:
this.sub1GChnum_ = input.readInt32();
continue;
case Opcodes.IF_ICMPNE /* 160 */:
this.sub1GRp_ = input.readInt32();
continue;
case 168:
this.sub1GChtotal_ = input.readInt32();
continue;
case Opcodes.GETSTATIC /* 178 */:
this.gprsImei_ = input.readBytes();
continue;
default:
if (!input.skipField(readTag)) {
break;
} else {
continue;
}
}
z = true;
} catch (InvalidProtocolBufferException e) {
throw e.setUnfinishedMessage(this);
} catch (IOException e2) {
throw new
InvalidProtocolBufferException(e2).setUnfinishedMessage(this);
}
} finally {
makeExtensionsImmutable();
}
}
}
:
Bearbeitet durch User
Daniel R. schrieb: > Erste Log: > > Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 DC 00 > 01 00 05 00 02 4D > Payload 95 74 40 33 29 74 40 33 29 03 00 0C 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 9A > Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 > FB 00 13 6D AD 39 Die Payload währe: ( 16 byte fehlen ) 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FB 00 13 6D AD Wobei 6D AD die Modbus CRC ist. Natürlich falsch, weil die Payload nicht vollständig ist. Irgendwie fehlt da immer das erste Fragment. Aus den Logs lassen sich so keine korrekten Daten lesen.
Daniel R. schrieb: > Gibt es die möglichkeit die Logs irgendwo gesammelt zusammen zu tragen? Gute Idee. Man müsste sich dann noch auf das Format einigen. Den Output, wie es das python-script macht kann ich jederzeit wieder parsen. Zeilen mit - "Transmit" beginnen eine Transaktion oder sind ein Re-Transmit - "Received" werden als Fragment gelesen und der zuvor gestarteten Transaktion appended - "Payload" (mit crc) werden statt den Received-Fragmenten anhand der Transmit-Payload direkt dekodiert gefolgt von den byte hexlified rohdaten dahinter. > private APPDtuInfoMO(CodedInputStream input, ExtensionRegistryLite > ... sieht sehr nach den technischen Daten der DTU aus und ist damit eher uninteressant. Wir wollen ja den WR und nicht die DTU abfragen. Trotzdem währe es aber interessant ob die App Rohdaten über die DTU zum WR senden kann. Wenn es also irgendwelche tx payloads gäbe könnte man das mal an die WR senden und gucken was passiert. Gruß, Jan
Hallo Lukas P., kannst Du den Feature Request noch aufnehmen, d.h. die Daten mit Transmit und Received per Serial (ggf. auch WebSerial oder MQTT o.a.) im "Unified Format" mitzuloggen, damit man die Daten auch mit dem Python Code nachverarbeiten könnte ? Es gibt zwar ein paar Zeilen, die bereits die "sent packet: #" und "RAW / CMD" im entsprechenden Format ausgeben. Diese sind jedoch meist inaktiv und ich muss die immer von Hand einschalten vor dem Kompilieren, damit ich die Rohdaten sehe. Transmit https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L239-L240 Received https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L142-L151 Bzgl. der blauen LED auf dem NodeMCU / Wemos D1 mini ist es evtl. keine so gute Idee gewesen den Anschluss D4 (GPIO2) für CE des nRF24 Moduls zu verwenden. Sobald CE low wird leuchtet die blaue LED. Das passiert wohl auch im Falle eines TX per Serial IO. Soll ich die Fritzing Layouts nochmal anpassen und gibt es eine empfohlene Verdrahtung, bzw. sollten noch andere GPIOs evtl. nicht / anders verwendet werden ? https://www.computerhilfen.de/info/esp8266-blaue-led-ausschalten-oder-blinken-lassen.html Aktuell ist die Belegung in der getting started ESP8266 Dokumentation: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Wire Connections
1 | +-----------+ +-----------+ |
2 | | ESP8266 |--colour--| nRF24L01+ | |
3 | | | | | |
4 | | GND |---black--|[GND] | |
5 | | +3.3V |----red---| VCC | |
6 | | D4 |---grey---| CE | |
7 | | D8 |--purple--| CSN | |
8 | | D5 |---blue---| SCK | |
9 | | D7 |---green--| MOSI | |
10 | | D6 |---brown--| MISO | |
11 | | D3 |--yellow--| IRQ | |
12 | +-----------+ +-----------+ |
Also cool wäre es, wenn man in das Webinterface von ESP drauf zugreift... das man dort aktzeptiert die Logs irgendwo gesammelt hochzuladen. Dann könnte man mittels Datenbank, das ganze super analysieren. Problem nur: Datenschutz... aber die meisten, die das Projekt Unterstützen wollen würden das Freiwilig ja machen. :) Mich eingeschlossen. Habe ich richtig gelesen, du betreibst das NRF24L01+ direkt am Raspi? Würde ich dann nähmlich bei mir auch umbauen und direkt alles auf dem Pi ablegen und verwalten. Aktuell habe ich alles auf einem Breadboard am Tisch. Wenn ich heute Zuhause bin, kann ich mal weiter decompilen und schauen ob ich was finde. Nachtrag: Gern kann ich zusätzlich später mit meinem gebastelten DVB-T mal die Frequenzen anschauen, ob sich da was auffäliges verhält. Bzgl. Channel Hopping oder ob vlt sogar auf mehrere Kanälen gleichzeitig gefunkt wird? (nur eine Mutmassung)
:
Bearbeitet durch User
Hallo Zusammen, ist das RF module von Kuman nRF24L01+PA+LNA ist dafür auch zu nutzen? Gruss david
Hallo David, sollte soweit ich weiß auch gehen. Die Endungen sagen soweit ich weiß nur aus das es mit einer extra Antenne versehen ist, statt einer auf dem PCB. Korrigiert mich wenn ich falsch liege. :)
Hallo Daniel, gut danke Dir. Im Moment bekomme ich keine Verbindung zum Inverter, nicht dass ich weiter den Fehler suche und dabei ist das RF Modul das Falsche ;) Grad war ich irgendwie nicht angemeldet. david
Wie verwendest du es denn? Arduino, ESP, Raspberry Pi,... ? Im falle vom ESP (wie ich) und du alles schon geflasht hast, musst du mit einem Endgerät mit WLAN dich darauf verbinden und kannst die WLAN Daten und co anpassen... Das schafst du schon. :) An die Experten, was könnte das bedeuten (gestern stand missing, statt all): das hier > 2 (0002) 3 (0003) 2 (0002) 3 (0030) -> all Payload 95 74 40 33 29 74 40 33 29 01 00 01 00 00 00 01 00 01 00 00 00 00 00 00 00 00 95 Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Payload 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 9F Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 DC 00 09 BB 71 0E das hier > 2 (0002) 3 (0003) 1 (0010) 3 (0030) -> all Payload 95 74 40 33 29 74 40 33 29 01 00 01 00 00 00 01 00 01 00 00 00 00 00 00 00 00 95 Payload 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Payload 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 9F Payload 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 DC 00 09 BB 71 0E
:
Bearbeitet durch User
Habe ein ESP-8266, darauf läuft die Ahoy Version 0.4.0. Noch kommt kein Bit vom Inverter ... Das denke ich auch, dass ich es hinbekomme ;) werde
Das sieht doch super aus, du bekommst Daten vom WR. Ich würde empfehlen, die ganz aktuelle Version 0.4.1 zu verwenden, die jetzt wie die Python Version die gesamte Payload sammelt + prüft und erst dann weiterverarbeitet.
Hab mal was angehängt, könnte das eine heiße Spur sein? Ich habe noch die 0.3.9, OTA Update wird wie gemacht? Möchte keine EInstellung verlieren.^^ Hat sich erledigt, selbst gefunden. :P
:
Bearbeitet durch User
Problem: inverter type can't be detected! In der Beschreibung ist angegeben, dass man den Inverter Typ angeben muss. Ist damit das Feld Name unter dem Adress gemeint? dort hab ich MI-600 eingetragen, adresse startet mit 1041...
So ich habe es nun auch geupdated auf 0.4.1. Danke :) Man muss den Typ nicht mehr Eintragen. @lumapu: Gebe dir hierfür recht, der 1500 hat nur zwei Spannungen und 4 Ströme. - https://github.com/grindylow/ahoy/issues/38 Inverter #0 no Payload received! Requesting Inverter SN xxxxxxxxxxx (ersetzt) Transmit 27 | 15 74 40 33 29 78 56 34 12 80 0B 00 62 83 DE 4B 00 00 00 05 00 00 00 00 A4 95 F8 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 9F Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 9F Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 9F Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A 75 E0 69 Error while retrieving data: Frame 1 missing: Request Retransmit Transmit 11 | 15 74 40 33 29 78 56 34 12 81 B2 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 97 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 97 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 97 Payload (62): 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A Balkonkraftwerk/ch1/U_DC: 0.200 V Balkonkraftwerk/ch1/I_DC: 0.010 A Balkonkraftwerk/ch2/U_DC: 0.200 V Balkonkraftwerk/ch2/I_DC: 0.010 A Balkonkraftwerk/ch3/U_DC: 30.000 V Balkonkraftwerk/ch3/I_DC: 0.010 A Balkonkraftwerk/ch3/P_DC: 0.200 W Balkonkraftwerk/ch4/U_DC: 30.000 V Balkonkraftwerk/ch4/I_DC: 0.030 A Balkonkraftwerk/ch4/P_DC: 0.800 W Balkonkraftwerk/ch4/YieldTota: 0.001 kWh Balkonkraftwerk/ch0/Temp: 23.100 ° Balkonkraftwerk/ch0/YieldTota: 0.001 kWh Transmit 27 | 15 74 40 33 29 78 56 34 12 80 0B 00 62 83 DE 50 00 00 00 05 00 00 00 00 54 2B AD Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 97 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 01 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 97 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 BA Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 03 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 9F Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A 75 E0 69 Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A 75 E0 69 Received 27 bytes channel 61: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A 75 E0 69 Payload (62): 00 01 00 02 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 2C 00 01 00 03 00 02 00 08 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 00 0A Balkonkraftwerk/ch1/U_DC: 0.200 V Balkonkraftwerk/ch1/I_DC: 0.010 A Balkonkraftwerk/ch2/U_DC: 0.200 V Balkonkraftwerk/ch2/I_DC: 0.010 A Balkonkraftwerk/ch3/U_DC: 30.000 V Balkonkraftwerk/ch3/I_DC: 0.010 A Balkonkraftwerk/ch3/P_DC: 0.200 W Balkonkraftwerk/ch4/U_DC: 30.000 V Balkonkraftwerk/ch4/I_DC: 0.030 A Balkonkraftwerk/ch4/P_DC: 0.800 W Balkonkraftwerk/ch4/YieldTota: 0.001 kWh Balkonkraftwerk/ch0/Temp: 23.100 ° Balkonkraftwerk/ch0/YieldTota: 0.001 kWh
:
Bearbeitet durch User
David B. schrieb: > Problem: > inverter type can't be detected! Sorry mein Fehler, ich werde das später noch fixen, habe wohl die Liste der Inverter zu schnell gelesen. Passe doch bei dir temporär mal in hmSystem.h:40 die 0x11 auf 0x10 an.
Ok, das mit dem Fehler inverter type can't be detected! ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht. ändere ich die S/N auf 1141..., ist der Fehler weg, aber Daten werden noch immer nicht empfangen. @lumapu: Codestelle korrigiert, der error trace ist auch mit regulärer S/N weg. Aber der Inverter bleibt stumm.
:
Bearbeitet durch User
David B. schrieb: > ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht. Soweit ich weiß haben wir es noch nicht geschafft einen Inverter der MI-Serie auszulesen. Daher werden egal welche Veränderungen gemacht werden auch weiterhin keine Daten rauskommen. Auf der 3ten Seite dieses Threads hat Ziyat T. (toe_c) schon einiges zu MI-1500 geschrieben: Ziyat T. schrieb: > Hallo > Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)?
Ich habe schwierigkeite bei der App was zu finden, was für uns wichtig seien könnte. Ich durchsuche quasi alles, was Interessant für uns seien könnte. Das näheste was ich gefunden habe ist im Anhang zu finden. Zeile 5506, 6760 Kennt sich jemand noch mit dem ... aus? ^^ Mein wissen stößt langsam bei Java an meine grenzen.
:
Bearbeitet durch User
Lukas P. schrieb: > David B. schrieb: >> ich nutze das model MI-600 welches mit der Seriennummer 1041.. losgeht. > > Soweit ich weiß haben wir es noch nicht geschafft einen Inverter der > MI-Serie auszulesen. Daher werden egal welche Veränderungen gemacht > werden auch weiterhin keine Daten rauskommen. > Auf der 3ten Seite dieses Threads hat Ziyat T. (toe_c) schon einiges zu > MI-1500 geschrieben: > > Ziyat T. schrieb: >> Hallo >> Bin ich hier der einzige mit einem WR der MI serie? (MI-1500)? achso, ja dann, das hab ich dann wohl überlesen. Hier wäre dann noch einer im Besitz eines WR der MI Serie ;)
Was haltet ihr davon wenn wir zur Dokumentation ähnlich wie Tasmota eine Github.io Seite einrichten. Das geht so wie es gelesen habe direkt im Repository zu aktivieren, wäre also eine Aufgabe für Martin G. (petersilie) Hat jemand Erfahrungen mit Github-Actions? Habe mal kurz bei Tasmota gespickt und gesehen, dass hier platformio installiert wird und damit gebaut wird.
Gute Idee, dann könnte man ein FAQ einrichten und und und... =)
> Ich habe Schwierigkeiten bei der App was zu finden, was für uns wichtig > seien könnte. > Ich durchsuche quasi alles, was Interessant für uns seien könnte. Das > näheste was ich gefunden habe ist im Anhang zu finden. > Zeile 5506, 6760 Ja das habe ich auch gesehen in Deinem DevConfigSMLPE.txt Anhang. Ich fand die folgende MO (Message Objekte?) sehr interessant, da hat man alles nochmal in einer Zeile. Die sind jeweils kurz vor den dazugehörigen Checksum Berechnungen mit `int hashcode` und den von Dir z.B. ab Zeile 5506 gefundenen und jeweils zugehörigen writeTo/getSerializedSize Methoden. U.a. scheint es darin auch eine acPSf (?) und die invSwAddr zu geben. Ob das Ganze aber für die Kommunikation mit der Hoymiles Cloud oder direkt mit der DTU gedacht ist kann ich nicht sagen. Vielleicht können wir ja später mehr Sinn darin sehen, wenn wir noch ein paar Ergebnisse aus der DTU Pro Analyse haben ?
1 | PDbusConfigMO pDbusConfigMO = (PDbusConfigMO) obj; |
2 | return (((((((((((((((((((((((((((((((((((((((((getSysType() == pDbusConfigMO.getSysType()) && getSysCfg() == pDbusConfigMO.getSysCfg()) && getDevNum() == pDbusConfigMO.getDevNum()) && getStrNum() == pDbusConfigMO.getStrNum()) && getReserve1() == pDbusConfigMO.getReserve1()) && getSmlpeAdVer() == pDbusConfigMO.getSmlpeAdVer()) && getCmdInterval() == pDbusConfigMO.getCmdInterval()) && getHbsInterval() == pDbusConfigMO.getHbsInterval()) && getTBd() == pDbusConfigMO.getTBd()) && getDataSampMode() == pDbusConfigMO.getDataSampMode()) && getPdbusComErrCnt() == pDbusConfigMO.getPdbusComErrCnt()) && getSmlpeComErrCnt() == pDbusConfigMO.getSmlpeComErrCnt()) && getDayModeCheckTm() == pDbusConfigMO.getDayModeCheckTm()) && getDayModeSmlpePercent() == pDbusConfigMO.getDayModeSmlpePercent()) && getReserve2() == pDbusConfigMO.getReserve2()) && getEnexSearchCnt() == pDbusConfigMO.getEnexSearchCnt()) && getEnSearchHbsCnt() == pDbusConfigMO.getEnSearchHbsCnt()) && getClearSearchDataCnt() == pDbusConfigMO.getClearSearchDataCnt()) && getSearchHostErrCnt() == pDbusConfigMO.getSearchHostErrCnt()) && getSearchSlaveCnt() == pDbusConfigMO.getSearchSlaveCnt()) && getSearchHostTout() == pDbusConfigMO.getSearchHostTout()) && getCompeteHostReceiptnone() == pDbusConfigMO.getCompeteHostReceiptnone()) && getSearchHost1ReciptnoneCnt() == pDbusConfigMO.getSearchHost1ReciptnoneCnt()) && getSearchHost2RecipterrCnt() == pDbusConfigMO.getSearchHost2RecipterrCnt()) && getRegMasterRssiTh() == pDbusConfigMO.getRegMasterRssiTh()) && getRegMasterReplyErrCnt() == pDbusConfigMO.getRegMasterReplyErrCnt()) && getSlaveRegMasterRssiTh() == pDbusConfigMO.getSlaveRegMasterRssiTh()) && getRegMasterCnt() == pDbusConfigMO.getRegMasterCnt()) && getCloseStrCnt() == pDbusConfigMO.getCloseStrCnt()) && getCancelMasterRegCnt() == pDbusConfigMO.getCancelMasterRegCnt()) && getTurnOnStrCnt() == pDbusConfigMO.getTurnOnStrCnt()) && getTurnOnStrHbsCnt() == pDbusConfigMO.getTurnOnStrHbsCnt()) && getSearchSlave1Reciptnone() == pDbusConfigMO.getSearchSlave1Reciptnone()) && getSearchSlave2SeciptsrrCnt() == pDbusConfigMO.getSearchSlave2SeciptsrrCnt()) && getRegSlaveCnt() == pDbusConfigMO.getRegSlaveCnt()) && getSeedNum() == pDbusConfigMO.getSeedNum()) && getReserve3() == pDbusConfigMO.getReserve3()) && getReserve4() == pDbusConfigMO.getReserve4()) && getReserve5() == pDbusConfigMO.getReserve5()) && getReserve6() == pDbusConfigMO.getReserve6()) && getReserve7() == pDbusConfigMO.getReserve7()) && getReserve8() == pDbusConfigMO.getReserve8(); |
3 | |
4 | InvInfoAddrMO invInfoAddrMO = (InvInfoAddrMO) obj; |
5 | return (((getEn() == invInfoAddrMO.getEn()) && getFc() == invInfoAddrMO.getFc()) && getStartAddr() == invInfoAddrMO.getStartAddr()) && getLength() == invInfoAddrMO.getLength(); |
6 | |
7 | InvRealAddrMO invRealAddrMO = (InvRealAddrMO) obj; |
8 | return (((getEn() == invRealAddrMO.getEn()) && getFc() == invRealAddrMO.getFc()) && getStartAddr() == invRealAddrMO.getStartAddr()) && getLength() == invRealAddrMO.getLength(); |
9 | |
10 | PvStrAddrMO pvStrAddrMO = (PvStrAddrMO) obj; |
11 | return (getVAddr() == pvStrAddrMO.getVAddr()) && getIAddr() == pvStrAddrMO.getIAddr(); |
12 | |
13 | InvConfigMO invConfigMO = (InvConfigMO) obj; |
14 | return ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((getInvVer() == invConfigMO.getInvVer()) && getDs().equals(invConfigMO.getDs())) && getModel().equals(invConfigMO.getModel())) && getFBoost() == invConfigMO.getFBoost()) && getFInv() == invConfigMO.getFInv()) && getMpptNum() == invConfigMO.getMpptNum()) && getStrNumMax() == invConfigMO.getStrNumMax()) && getPvSampCfg() == invConfigMO.getPvSampCfg()) && getAcMode() == invConfigMO.getAcMode()) && getEsReady() == invConfigMO.getEsReady()) && getLoadMonitorMode() == invConfigMO.getLoadMonitorMode()) && getComMode() == invConfigMO.getComMode()) && getEndian() == invConfigMO.getEndian()) && getInvInterval() == invConfigMO.getInvInterval()) && getStartDelay() == invConfigMO.getStartDelay()) && getRefreshDelayTm() == invConfigMO.getRefreshDelayTm()) && getInvDataSafetyMode() == invConfigMO.getInvDataSafetyMode()) && getComErrDelay() == invConfigMO.getComErrDelay()) && getNightModeDetectTm() == invConfigMO.getNightModeDetectTm()) && getDayModeCheckTm() == invConfigMO.getDayModeCheckTm()) && getBatteryEn() == invConfigMO.getBatteryEn()) && getLoadMonitorEn() == invConfigMO.getLoadMonitorEn()) && getLinkMode() == invConfigMO.getLinkMode()) && getInvSlaveAddr() == invConfigMO.getInvSlaveAddr()) && getInvIp().equals(invConfigMO.getInvIp())) && getInvPort() == invConfigMO.getInvPort()) && getInvBd() == invConfigMO.getInvBd()) && getInvParity() == invConfigMO.getInvParity()) && getInvStart() == invConfigMO.getInvStart()) && getInvStop() == invConfigMO.getInvStop()) && getInvInfoAddrList().equals(invConfigMO.getInvInfoAddrList())) && getInvRealAddrList().equals(invConfigMO.getInvRealAddrList())) && getAcPSf() == invConfigMO.getAcPSf()) && getAcEhSf() == invConfigMO.getAcEhSf()) && getLoadPSf() == invConfigMO.getLoadPSf()) && getGridPSf() == invConfigMO.getGridPSf()) && getLoadEhSf() == invConfigMO.getLoadEhSf()) && getBatSocSf() == invConfigMO.getBatSocSf()) && getBatPSf() == invConfigMO.getBatPSf()) && getPvStrVSf() == invConfigMO.getPvStrVSf()) && getPvStrISf() == invConfigMO.getPvStrISf()) && getPvStrPSf() == invConfigMO.getPvStrPSf()) && getPvStrEhSf() == invConfigMO.getPvStrEhSf()) && getAcPAddr() == invConfigMO.getAcPAddr()) && getAcPFc() == invConfigMO.getAcPFc()) && getAcPNum() == invConfigMO.getAcPNum()) && getAcEhAddr() == invConfigMO.getAcEhAddr()) && getAcEhFc() == invConfigMO.getAcEhFc()) && getAcEhNum() == invConfigMO.getAcEhNum()) && getLoadPAddr() == invConfigMO.getLoadPAddr()) && getLoadPFc() == invConfigMO.getLoadPFc()) && getLoadPNum() == invConfigMO.getLoadPNum()) && getLoadEhAddr() == invConfigMO.getLoadEhAddr()) && getLoadEhFc() == invConfigMO.getLoadEhFc()) && getLoadEhNum() == invConfigMO.getLoadEhNum()) && getPvPAddr() == invConfigMO.getPvPAddr()) && getPvPFc() == invConfigMO.getPvPFc()) && getPvPNum() == invConfigMO.getPvPNum()) && getGridPAddr() == invConfigMO.getGridPAddr()) && getGridPFc() == invConfigMO.getGridPFc()) && getGridPNum() == invConfigMO.getGridPNum()) && getBuyPAddr() == invConfigMO.getBuyPAddr()) && getBuyPFc() == invConfigMO.getBuyPFc()) && getBuyPNum() == invConfigMO.getBuyPNum()) && getSailPAddr() == invConfigMO.getSailPAddr()) && getSailPFc() == invConfigMO.getSailPFc()) && getSailPNum() == invConfigMO.getSailPNum()) && getBatSocAddr() == invConfigMO.getBatSocAddr()) && getBatSocFc() == invConfigMO.getBatSocFc()) && getBatSocNum() == invConfigMO.getBatSocNum()) && getBatPAddr() == invConfigMO.getBatPAddr()) && getBatPFc() == invConfigMO.getBatPFc()) && getBatPNum() == invConfigMO.getBatPNum()) && getPvStrTotalPAddr() == invConfigMO.getPvStrTotalPAddr()) && getPvStrTotalPFc() == invConfigMO.getPvStrTotalPFc()) && getPvStrTotalPNum() == invConfigMO.getPvStrTotalPNum()) && getPvStrTotalEhAddr() == invConfigMO.getPvStrTotalEhAddr()) && getPvStrTotalEhFc() == invConfigMO.getPvStrTotalEhFc()) && getPvStrTotalEhNum() == invConfigMO.getPvStrTotalEhNum()) && getPvStrRealAddrList().equals(invConfigMO.getPvStrRealAddrList())) && getInvSwAddr() == invConfigMO.getInvSwAddr()) && getInvSwFc() == invConfigMO.getInvSwFc()) && getInvSwNum() == invConfigMO.getInvSwNum()) && getPdSwAddr() == invConfigMO.getPdSwAddr()) && getPdSwFc() == invConfigMO.getPdSwFc()) && getPdSwNum() == invConfigMO.getPdSwNum()) && getOpenVal() == invConfigMO.getOpenVal()) && getCloseVal() == invConfigMO.getCloseVal()) && getPdValType() == invConfigMO.getPdValType()) && getPdValSf() == invConfigMO.getPdValSf()) && getReserve9() == invConfigMO.getReserve9()) && getReserve10() == invConfigMO.getReserve10()) && getReserve11() == invConfigMO.getReserve11()) && getReserve12() == invConfigMO.getReserve12()) && getReserve13() == invConfigMO.getReserve13()) && getReserve14() == invConfigMO.getReserve14()) && getSInterval() == invConfigMO.getSInterval()) && getReserve15() == invConfigMO.getReserve15()) && getDevMode() == invConfigMO.getDevMode()) && getDevAddr() == invConfigMO.getDevAddr()) && getBaudBd() == invConfigMO.getBaudBd()) && getParity() == invConfigMO.getParity()) && getStart() == invConfigMO.getStart()) && getStop() == invConfigMO.getStop()) && getReserve16() == invConfigMO.getReserve16(); |
15 | |
16 | int acPSf = (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((hashCode * 37) + 33) * 53) + getAcPSf()) * 37) + 34) * 53) + getAcEhSf()) * 37) + 35) * 53) + getLoadPSf()) * 37) + 36) * 53) + getGridPSf()) * 37) + 37) * 53) + getLoadEhSf()) * 37) + 38) * 53) + getBatSocSf()) * 37) + 39) * 53) + getBatPSf()) * 37) + 40) * 53) + getPvStrVSf()) * 37) + 41) * 53) + getPvStrISf()) * 37) + 42) * 53) + getPvStrPSf()) * 37) + 43) * 53) + getPvStrEhSf()) * 37) + 44) * 53) + getAcPAddr()) * 37) + 45) * 53) + getAcPFc()) * 37) + 46) * 53) + getAcPNum()) * 37) + 47) * 53) + getAcEhAddr()) * 37) + 48) * 53) + getAcEhFc()) * 37) + 49) * 53) + getAcEhNum()) * 37) + 50) * 53) + getLoadPAddr()) * 37) + 51) * 53) + getLoadPFc()) * 37) + 52) * 53) + getLoadPNum()) * 37) + 53) * 53) + getLoadEhAddr()) * 37) + 54) * 53) + getLoadEhFc()) * 37) + 55) * 53) + getLoadEhNum()) * 37) + 56) * 53) + getPvPAddr()) * 37) + 57) * 53) + getPvPFc()) * 37) + 58) * 53) + getPvPNum()) * 37) + 59) * 53) + getGridPAddr()) * 37) + 60) * 53) + getGridPFc()) * 37) + 61) * 53) + getGridPNum()) * 37) + 62) * 53) + getBuyPAddr()) * 37) + 63) * 53) + getBuyPFc()) * 37) + 64) * 53) + getBuyPNum()) * 37) + 65) * 53) + getSailPAddr()) * 37) + 66) * 53) + getSailPFc()) * 37) + 67) * 53) + getSailPNum()) * 37) + 68) * 53) + getBatSocAddr()) * 37) + 69) * 53) + getBatSocFc()) * 37) + 70) * 53) + getBatSocNum()) * 37) + 71) * 53) + getBatPAddr()) * 37) + 72) * 53) + getBatPFc()) * 37) + 73) * 53) + getBatPNum()) * 37) + 74) * 53) + getPvStrTotalPAddr()) * 37) + 75) * 53) + getPvStrTotalPFc()) * 37) + 76) * 53) + getPvStrTotalPNum()) * 37) + 77) * 53) + getPvStrTotalEhAddr()) * 37) + 78) * 53) + getPvStrTotalEhFc()) * 37) + 79) * 53) + getPvStrTotalEhNum(); |
17 | |
18 | int invSwAddr = (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((acPSf * 37) + 81) * 53) + getInvSwAddr()) * 37) + 82) * 53) + getInvSwFc()) * 37) + 83) * 53) + getInvSwNum()) * 37) + 84) * 53) + getPdSwAddr()) * 37) + 85) * 53) + getPdSwFc()) * 37) + 86) * 53) + getPdSwNum()) * 37) + 87) * 53) + getOpenVal()) * 37) + 88) * 53) + getCloseVal()) * 37) + 89) * 53) + getPdValType()) * 37) + 90) * 53) + getPdValSf()) * 37) + 91) * 53) + getReserve9()) * 37) + 92) * 53) + getReserve10()) * 37) + 93) * 53) + getReserve11()) * 37) + 94) * 53) + getReserve12()) * 37) + 95) * 53) + getReserve13()) * 37) + 96) * 53) + getReserve14()) * 37) + 97) * 53) + getSInterval()) * 37) + 98) * 53) + getReserve15()) * 37) + 99) * 53) + getDevMode()) * 37) + 100) * 53) + getDevAddr()) * 37) + 101) * 53) + getBaudBd()) * 37) + 102) * 53) + getParity()) * 37) + 103) * 53) + getStart()) * 37) + 104) * 53) + getStop()) * 37) + 105) * 53) + getReserve16()) * 29) + this.unknownFields.hashCode(); |
19 | |
20 | LoggerConfigMO loggerConfigMO = (LoggerConfigMO) obj; |
21 | return ((((((((((((((((getWorkMode() == loggerConfigMO.getWorkMode()) && getCommMode() == loggerConfigMO.getCommMode()) && getDhcpSw() == loggerConfigMO.getDhcpSw()) && getIp().equals(loggerConfigMO.getIp())) && getNetmask().equals(loggerConfigMO.getNetmask())) && getGw().equals(loggerConfigMO.getGw())) && getDns().equals(loggerConfigMO.getDns())) && getApSsid().equals(loggerConfigMO.getApSsid())) && getApPwd().equals(loggerConfigMO.getApPwd())) && getSpApn().equals(loggerConfigMO.getSpApn())) && getSpName().equals(loggerConfigMO.getSpName())) && getSpPwd().equals(loggerConfigMO.getSpPwd())) && getGprsNo().equals(loggerConfigMO.getGprsNo())) && getReserve19() == loggerConfigMO.getReserve19()) && getSvrPort() == loggerConfigMO.getSvrPort()) && getSvrHost().equals(loggerConfigMO.getSvrHost())) && getReserve20() == loggerConfigMO.getReserve20(); |
22 | |
23 | ConfigParaMO configParaMO = (ConfigParaMO) obj; |
24 | return ((getPdbusCfgList().equals(configParaMO.getPdbusCfgList())) && getInvCfgList().equals(configParaMO.getInvCfgList())) && getLogCfgList().equals(configParaMO.getLogCfgList()); |
25 | |
26 | WriteHRegResDTO writeHRegResDTO = (WriteHRegResDTO) obj; |
27 | return (((((((getOffset() == writeHRegResDTO.getOffset()) && getTime() == writeHRegResDTO.getTime()) && getAction() == writeHRegResDTO.getAction()) && (getGwSn() > writeHRegResDTO.getGwSn() ? 1 : (getGwSn() == writeHRegResDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > writeHRegResDTO.getLogSn() ? 1 : (getLogSn() == writeHRegResDTO.getLogSn() ? 0 : -1)) == 0) && getAp() == writeHRegResDTO.getAp()) && getCp() == writeHRegResDTO.getCp()) && getCfgParaList().equals(writeHRegResDTO.getCfgParaList()); |
28 | |
29 | WriteHRegReqDTO writeHRegReqDTO = (WriteHRegReqDTO) obj; |
30 | return ((((((getOffset() == writeHRegReqDTO.getOffset()) && getTime() == writeHRegReqDTO.getTime()) && getAction() == writeHRegReqDTO.getAction()) && (getGwSn() > writeHRegReqDTO.getGwSn() ? 1 : (getGwSn() == writeHRegReqDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > writeHRegReqDTO.getLogSn() ? 1 : (getLogSn() == writeHRegReqDTO.getLogSn() ? 0 : -1)) == 0) && getCp() == writeHRegReqDTO.getCp()) && getErrCode() == writeHRegReqDTO.getErrCode(); |
31 | |
32 | ReadHRegReqDTO readHRegReqDTO = (ReadHRegReqDTO) obj; |
33 | return (((((((getOffset() == readHRegReqDTO.getOffset()) && getTime() == readHRegReqDTO.getTime()) && getAction() == readHRegReqDTO.getAction()) && (getGwSn() > readHRegReqDTO.getGwSn() ? 1 : (getGwSn() == readHRegReqDTO.getGwSn() ? 0 : -1)) == 0) && (getLogSn() > readHRegReqDTO.getLogSn() ? 1 : (getLogSn() == readHRegReqDTO.getLogSn() ? 0 : -1)) == 0) && getAp() == readHRegReqDTO.getAp()) && getCp() == readHRegReqDTO.getCp()) && getCfgParaList().equals(readHRegReqDTO.getCfgParaList()); |
34 | |
35 | ReadHRegResDTO readHRegResDTO = (ReadHRegResDTO) obj; |
36 | return ((((getOffset() == readHRegResDTO.getOffset()) && getTime() == readHRegResDTO.getTime()) && getAction() == readHRegResDTO.getAction()) && (getGwSn() > readHRegResDTO.getGwSn() ? 1 : (getGwSn() == readHRegResDTO.getGwSn() ? 0 : -1)) == 0) && getLogSn() == readHRegResDTO.getLogSn(); |
Ich habe folgendes im Netz gefunden. Bedienungsanleitung MI-1000/MI-1200/MI-1500 Version 2.0 (Juni 2020) 6. Fehlersuche Hoymiles hat die interaktive Leistung des Mikrowechselrichtersystems Mitte 2020 aktualisiert. Wenn Sie den Mikrowechselrichter mit Seriennummer "1062xxxxxxxx" verwenden, so beziehen Sie sich bitte auf Abschnitt 6.1 und Abschnitt 6.3. Wenn Sie den Mikrowechselrichter mit Seriennummer "1060xxxxxxxx" und "1061xxxxxxxx" verwenden, so beziehen Sie sich bitte auf Abschnitt 6.2 und Abschnitt 6.4. *Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren
Hier im Forum gibt es unter nRF24L01+ und PA Kombi gibt kein Acknowledge Hinweise zu Inkompatibilitäten zwischen Orginal-Chip's und Nachbauten. Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge"
Hallo zusammen, @isnoAhoy: das ist mir auch aufgefallen, jedoch war das ganze schon sehr lang. Das müsste man sich nochmal anschauen. In erster linie war mir wichtig etwas "pregnantes" zu finden. Was uns direkt weiterhelfen könnte. @Olaf A: Danke für die Info, ich habe nämlich beim decompilen herausgefunden das es tatsächlich Geräte hinterlegt sind mit einer bestimmten Kennung. Wobei ich diese eher als Test entnommen habe und nicht dachte das diese eventuell was für uns aussagt. Siehe Zeile ab 38 im Anhang. Gruß Daniel Nachtrag: Ich meine diese Einträge sagen aus, wie die App mit der DTU zu arbeiten hat. Da jedes Produkt eine eigene Kennung besitzt und diese im ganzen System Automatisch hinterlegt wird. Beispiel: Mikrowechselrichter mit Batterie und einem Energiemessgerät zusammen in einer App... und welcher DTU im System ist, handelt es sich um eine Pro oder um eine Lite Version. Im Handbuch steht im Punkt 4.1 was Interessantes: https://www.hoymiles.com/wp-content/uploads/2021/05/BENUTZERHANDBUCH_HM-100012001500_Global_DE_V202203.pdf - Ich glaube man muss hier nur denn Wert definitiv irgendwie ändern. Das Suchen wir ja aktuell. Aber mehr steht dort auch nicht. Kopfschmerzen habe ich beim Thema 0 Einspeisung, da hier der WR irgendwie mit einem Messgerät zusammen Kommunizieren muss. Damit der WR regeln kann. Generell die Leistung vom WR auf einem festen Wert zu regeln, erlese ich aber dort leider nicht. :( Das wäre für uns ja fundamental, damit wir diese automatisiert regeln können.
:
Bearbeitet durch User
Grüezi mitenand, hier sind ein paar Videos und Bilder zum Hoymiles Wechselrichter (MI-1200 und HM-800): - zum Thema Nulleinspeisung: https://www.youtube.com/watch?v=BVWrG8nCMPQ - zum Innenleben des Wechselrichters: https://www.youtube.com/watch?v=Ho02aQxyX20 https://www.youtube.com/watch?v=AtOjcIZpGKI https://www.youtube.com/watch?v=cgw11fTxhH8 https://www.youtube.com/watch?v=Tu75J9IIhUg https://www.photovoltaikforum.com/thread/171257-hoymiles-hm800-leistungssteuerung-per-pwm/
Sehr cool, vielen dank! Dann kann man sich heute nach der Arbeit mal alles durch arbeiten und weiter schauen. :) Besten Dank Yoshi
Hi, das letzte Paket kann wohl nicht zum re-transmit angefragt werden. Wenn das fehlt ist wohl zwingend eine neue Transaktion nötig. Lukas P. schrieb: > Was haltet ihr davon wenn wir zur Dokumentation ähnlich wie Tasmota eine > Github.io Seite einrichten. Das geht so wie es gelesen habe direkt im > Repository zu aktivieren, wäre also eine Aufgabe für Martin G. > (petersilie) Wird spaßig, weil wir 2 Softwaren in dem repo haben. Ich glaube wir sind mit Markdown besser bedient. > Hat jemand Erfahrungen mit Github-Actions? Habe mal kurz bei Tasmota > gespickt und gesehen, dass hier platformio installiert wird und damit > gebaut wird. Pipelines. Spätestens da macht es dann Sinn das Projekt in die einzelnen Implementierungen zu splitten. Ich arbeite normal mit Drone oder Gitlab Runner. Sehr praktisch, aber Entwicklungsaufwand mal 2. Daniel R. schrieb: > Kopfschmerzen habe ich beim Thema 0 Einspeisung, da hier der WR > irgendwie mit einem Messgerät zusammen Kommunizieren muss. Damit der WR > regeln kann. Eher wenig Kopfschmerzen. Aber da brauchen wir noch sehr viel Protokoll-Analyse. Ich meine damit, Tage an Rohdatenmittschnitten vom Original im Idealfall unter verschiedenen Betriebsbedingungen. Natürlich muss dem Wechselrichter irgendwo ein Bit gesetzt werden, dass die DTU die Leistungsvorgabe setzen muss (der WR damit ohne Kommunikation abschaltet) und dann muss die DTU die Leistungsanforderung eben regelmäßig in der WR schreiben. Die DTU fragt das dann wohl via Modbus vom Energiezähler ab und provisierniert mit dem Einspeisebudget alle paar Sekunden die Wechselrichter. Ich denke dabei gerade daran das Einspeisebudget aus den Zählerinformationen via Mqtt zu lesen bzw. die nötigen Payloads via HASS generieren zu lassen und dann via Command-Topic an den WR zu relayen. Gruß, Jan
Moin Jan, zu deiner letzten Passage, da gebe ich dir recht. Habe mir im Nachhinein die YT-Videos die Yoshi hinterlegt hat angeschaut und wird sehr sauber beschrieben: - zum Thema Nulleinspeisung: https://www.youtube.com/watch?v=BVWrG8nCMPQ Das ist genau so wie du beschrieben hast, nur das hier zwischen DTU und Messzähler eine RS485 zum Einsatz kommt (3:35min). - Whatever, es geht aufjedenfall weiter. =)
Daniel R. schrieb: > nur das hier zwischen DTU und Messzähler eine RS485 zum Einsatz kommt Jan-Jonas S. schrieb: > Die DTU fragt das dann wohl via Modbus vom Energiezähler ab
Ich nutze einen shelly3em zur aktuellen energiemessung meines Haushaltes. Wäre prima wenn die Nulleinspeisung auf zb Werte die per Mqtt kommen weiterverarbeitet werden, so ist es für viele Systeme offen und nicht auf den energiemesser den hoymiles vorgibt beschränkt.
Das wäre doch alles viel zu langsam, wenn die DTU jetzt was von einem Messgerät ließt und das dann dem Wechselrichter zukommen lässt und das auch noch over the air. Da wird ja man ja an Strahlung gegrillt ;). In der Preisklasse der Wechselrichter gehe ich davon aus, das man a) einen festen Leistungswert oder b) einen prozentualen leistungswert an den Wechselrichter übermittelt. Alles andere sehe ich nicht in diesem Preisbereich und muss selber gebaut werden. Deswegen wäre es eben cool wenn wir mal Mitschnitte haben wo die DTU mit dem WR kommuniziert und man mehrfach die Leistungswerte ändert. Marcel
Ziyat T. schrieb: > Ich habe eine DTU-Pro Hallo Ziyat, bist du hier noch aktiv? Wäre es möglich uns hierbei einige Infos über das teil zukommen zu lassen? Oder wäre es möglich es auszuleihen um weitere Recherchen daran zu betreiben? Wer hat noch so ein DTU-Pro? @Jan: Sorry ^^ Gruß Daniel Edit: Ich bin nun aktiv dabei weiter die Logs mal auszuwerten. Nur das ich auf dem richtigen weg bin, habe ich dazu eine Frage: Ich vergleiche aktuell die Logs untereinander und versuche durch die Logs eine Symmetrie zu finden. Dazu habe ich auch Logs mir erstellt, wo ich versuche die Werte manuell zu ändern. Zb: "kein PV Spannung", PV Spannung, kein AC Spannung und wieder AC Spannung habe, um zum Beispiel eine Inkrimierte Variabel zu finden. Oder den aktuellen Status des WR zu erlesen ist. - Was haltet ihr von der vorgehensweiße?
:
Bearbeitet durch User
Moin zusammen, könnte man in der Log das ganze bisschen ausbauen? Aktuell muss ich mühsehlig alles ausseinander ziehen und schauen welches Bit noch undefiniert ist. Oder hat jemand eine Excel geschrieben, wo ich das reinhauen kann um zu sehen was übrig bleibt? Danke
Daniel R. schrieb: > könnte man in der Log das ganze bisschen ausbauen? Baue dir am besten eine Firmware oder noch besser verwende Jan's Python Code als Basis und lass dir die Roh-Daten ausgeben. Ich denke in Python geht das fixer, Code umbauen und sofort testen, nicht erst kompilieren und updaten. Nach und nach kannst du dann einen Parser für die Daten entwickeln. Die entgültige Erkenntnis kannst du dann wieder in den ESP portieren sofern er dir dann noch zusagt ;-)
Hi Lukas, danke, ja aktuell mach ich das über ESP. Muss das echt mal auf den Raspberry portieren... hmm alles klar, so kann man das auch machen. Danke. :)
Morgen, hab was neues entdeckt in einer Anleitung. Auf dieser Seite https://www.shinetech-power.de/en/inverter/hoymiles/ werden Produkte anscheinend verkauft. Unter dem Punkt "Hoymiles DTU-Pro" sind auch Anleitung in PDF hinterlegt. Darunter auch Modbus Protokoll mit einer riesen Tabelle. Ich bin heute nach der Arbeit beim Grillfest, vielleicht kann es sich jemand von euch mal anschauen? https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf Gruß Daniel
ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze) behoben
Hi tbnobody, wäre es möglich, dass du hier einen Export(json) deines Grafana Boards zur Verfügung stellst? Danke dir. Viele Grüße
Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c):
Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und
speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz
vollständige Liste der DTUs im Besitz von Foren Teilnehmern. Auch ein
Salea Logic Analyzer habe ich mal ausprobiert und anhand den von martin
(Gast) in seiner DTU-Lite aufgenommenen Daten (RX/TX) Testpunkt
dokumentiert, wie man dabei zu den entsprechenden Logfiles kommt. Es
gibt da sog. Analyzer (speziell Async Serial funktioniert) und dann kann
man einen Export ins CSV Format machen.
Jetzt bräuchten wir nur noch einen Freiwilligen DTU-Pro Besitzer, der
das große Kästchen mal aufschraubt und an den RX/TX Punkten mißt was
passiert, wenn man per ModBus ein paar Kommandos gibt. Wenn die DTU
Besitzer ihre Geräte nicht aufschrauben wollen gäbe es immer noch andere
Methoden (NRF24_Sniffer, Ahoy zum Sniffen anpassen) die eventuell etwas
minimal-invasiver sind, jedoch wäre das vermutlich mit mehr Aufwand und
weniger Erkenntnisgewinn verknüpft, da die Pakete nicht so sicher
belauscht werden können wie am RX/TX Testpunkt auf der Platine.
Die Salea Logic Analyzer bzw. Clones gibt es übrigens für ca. 13,- Euro
aus der Bucht:
https://www.ebay.de/itm/255283244102
* Trace / Sniffer Software:
- Salea Logic / Clone
+ Sigrok Software (Pulseviwew)
https://sigrok.org/
https://sigrok.org/wiki/Downloads
http://marcusjenkins.com/saleae-logic-analyser-clone-with-ubuntu/
+ Salea Logic
https://www.saleae.com/downloads/
chmod +x Logic-2.3.53-master.AppImage
./Logic-2.3.53-master.AppImage
<1F> Analyzer (right side toolbar)
Analyzers (+)
Async Serial
Input Channel: 00. Channel 0
Bit Rate (Bits/s): 125000
Bits per Frame: 8 Bits per Transfer (Standard)
Stop Bits: 1 Stop Bit (Standard)
Parity Bit: No Parity Bit (Standard)
Significant Bit: Least Significant Bit Sent First (Standard)
Signal Inversion: Non Inverted (Standard)
Mode: Normal
[x] Show in Protocol Results Table
[x] Stream to terminal
Save
Analyzers (+)
Async Serial
Input Channel: 01. Channel 1
Bit Rate (Bits/s): 125000
Bits per Frame: 8 Bits per Transfer (Standard)
Stop Bits: 1 Stop Bit (Standard)
Parity Bit: No Parity Bit (Standard)
Significant Bit: Least Significant Bit Sent First (Standard)
Signal Inversion: Non Inverted (Standard)
Mode: Normal
[x] Show in Protocol Results Table
[x] Stream to terminal
Save
Rename the two Async Serial Analyzers to RX / TX
Data ... Export Table
Export Table Data
Columns: (*) All
Data: (*) All
Export Format: (*) CSV
[x] Use ISO8601 Timestamps
Export
- NRF24_Sniffer
git clone https://github.com/Yveaux/NRF24_Sniffer
./nrf24-sniffer.py -a 90:65:23:74:01
- Wireshark
* Python ESP Variante zum Mitschneiden anpassen konfigurieren
* Pakete einer DTU und eines Wechselrichters (hier MI-1500) mit der
ESP/Raspberry Pi Variante mitschneiden.
* Kommandos per Modbus an die DTU-Pro senden und diese mit einem
LogicAnalyzer an den RX/TX Testpunkten in der DTU mitschneiden
* Payload und Kommandos aus den Datenpaketen extrahieren und analysieren
DTU Besitzer / Nutzer
---------------------
DTU-Pro: Sascha D. (bandit7311), Ziyat T. (toe_c)
DTU-Lite: martin (Gast), Oliver F. (of22), Martin G. (petersilie)
DTU-W100: Arnaldo G. (arnaldo_g), Sergey S. (sergey_s632), Mike (Gast)
DTU ?: Daniel M. (daniel_m821), Martin P. (mpolak77)
DTU-Pro Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Sascha D. (bandit7311)
DTU-Pro Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Ziyat
T. (toe_c)
DTU-Lite xxxx72818832
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx martin
(Gast)
DTU-Lite xxxx72819005
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Oliver F.
(of22)
DTU-Lite Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Martin G. (petersilie)
DTU-Lite 10D972xxxxxx
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 10D9 martin
(Gast)
DTU-W100 10D373114359
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 10D3 Sergey S.
(sergey_s632)
DTU-W100 xxxx70535453
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Arnaldo G.
(arnaldo_g)
DTU-W100 10D373114359
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 10D3 Sergey S.
(sergey_s632)
DTU-W100 Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Mike
(Gast)
DTU Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Daniel M.
(daniel_m821)
DTU basic ? Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Martin P. (mpolak77)
Exoten MI & TSUN Wechselrichter:
MI-1500 xxxxxxx14456
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Arnaldo G.
(arnaldo_g)
MI-1500 xxxxxxx36590
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" xxxx Arnaldo G.
(arnaldo_g)
MI-1500 Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Ziyat
T. (toe_c)
MI-600 1041xxxxxxxx
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 1041 David B.
(mystisch)
TSUN TSOL-M800 104163500316
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 1041 Daniel M.
(Gast)
---
Diskussionsausschnitte zum Thema DTU-Pro und Modbus Ansteuerung
---------------------------------------------------------------
Da ich meiene DTU-Pro über Modbus-RTU selber ansteuere, könnte ich den
WR gezielt ansteueren, ich waere bereit sie zu sniffen aber brauche
HW-maessig hilfe wie ich es machen soll.
Logik Analysator direkt an die Pins vom NRF24+ und aufzeichnen :-)
MOSI, MISO, usw.
https://www.az-delivery.de/products/saleae-logic-analyzer
Also Testen an unser aller DIY Hardware und wenn Du mit der Software vom
LA klar kommst, dann die PINs im DTU-Lite :-) so ist das gemeint von
mir.
Ich meine, der LA kann auch in der Software 8 Serielle Bits direkt als
Hex anzeigen.
Den LA gibts natürlich auch bei anderen Anbietern.
Da herrscht leider Totenstille, wie ich schon vor einiger Zeit an meiner
DTU festgestellt hatte:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Liegt daran, dass es sich beim NRF in der DTU um einen NRF24LE1E
handelt, der einen eigenen Controller drin hat.
Ich hatte mitgenommen, daß man die Kommunikation an den Testpunkten für
RX/TX zwischen GD32F303 und nRF12LE1E abnehmen kann ? Das Bild nochmal
anbei.
Wir brauchen dringend packet captures von DTU-Usern. Im Idealfall mit
Korellierbaren Werten und Aktionen. Speziell was die DTU so sendet.
Wichtig: von beiden Seiten. Es ist absolut relevant DTU tx und WR tx in
zeitlicher Abfolge richtig zu haben, weil wie gesagt aus den Fragmenten
und Paketen der Inhalt nicht ableitbar ist. Man MUSS wissen was
angefragt wurde, um die Payload dekodieren zu können.
Wir sollten zukünftig also von:
Fragmenten, Paketen, und Payloads sprechen.
Dabei setzt sich ein Paket aus Fragmenten (ehem. cmd) zusammen, das
Paket enthält die Payload.
Jedes Fragment enthält src-, dst-addr, seq, bis 16 byte Payload-Fragment
+ 1 byte crc
Jedes Paket enthält 128*16-2 byte(?) Payload + 2 byte crc
Jede Payload kann demnach max 2046 byte haben.
Vermutung, abgeleitet aus den bisher bekannten Umständen.
In der bereits verlinkten PDF zum Modbus(was ja schon recht nahe an eure
Daten rankommt, aber leider auch nicht identisch ist), sind Register zu
sehen, die dafür zuständig sind:
https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf
0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über
ein Relais lösen könnte). Ich weiß jetzt leider nicht genau, wie das mit
dem Protokoll zum WR aussieht, aber es muss ja alles über NRF
funktionieren und sollte somit auch umsetzbar sein. Ich denke im 70%
Modus setzt die DTU einfach nur einen Festwert(70% der Nennleistung in
jeden WR) und bei Nulleinspeisung(was ich quasi vor habe) wird immer
wieder zyklisch das aktuelle Limit geschrieben.
Diese Funktion kann leider nur mit der DTU Pro gesnifft werden, da nur
da das möglich bzw. freigegeben ist.
Nach Inbetriebnahme kann ich gerne auch Daten beisteuern.
Wäre auch bereit dazu, einem Sniffing-Experten finanziell zu
unterstützen. Z.B. beim Kauf einer DTU-Pro um die Zero-Export-Funktion
zu "entschlüsseln".
Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie
Hat die HMT-Serie ein geändertes Protokoll?
Das Modell DTU-Pro-S ist kompatibel mit Hoymiles Mikrowechselrichtern:
HMT-2250 / 1800-6T, HMS-2000 / 1800-4T, HMS-1500 1200-4T HMS-1000
900-2T, HMS-800/700/ 600-2T HMS-500/450/400/350/300-1T.
isnoAhoy schrieb: > Fun Fact DTU-PRO-S kommuniziert nicht mit der HM-Serie > Hat die HMT-Serie ein geändertes Protokoll? Good point. Das ist mir auch schon aufgefallen, dass die HM's bei der serial von der DTU recht picky sind. Die 10F... aus dem Excel sheet gehen z.B. garnicht.
Hallo isnoAhoy , vielen Dank für die tolle zusammenfassung. Ich habe gestern Abend einige Lieferanten angeschrieben bezügl. DTU-Pro, um sein Teil zu erhalten. Bis jetzt noch keine Antwort erhalten. Wenn ich eins habe, könnte ich es ohne Probleme ausseinander nehmen. Zum Analysieren habe ich ein "Salea Logic 16 clone", der wunderbar mit der Software von Salea funktioniert. Der einzige Punkt wo ich stutzig bin: Denn WR ausseinander zu nehmen, würde ich ungern tun (zwecks Dichtung und co.). Wieso sollte es hier nicht ausreichen, direkt am DTU (hinter dem NRF) TX & RX zu belauschen? Da sollten ja keine Packete vom NRF modifiziert sein? Wäre nicht auch die SPI NRF <-> MCU Übertragung mitzusniffen sinnvoll? Gruß
Daniel R. schrieb:
Hallo Daniel,
ich schätze Deine Mitarbeit sehr.
ABER
Du hast Dich irgendwann hier eingeklingt, ohne alle Beiträge zu lesen.
Das Du sie nicht gelesen hast - oder vergessen hast - oder wie auch
immer ist eindeutig an Deinen Äußerungen zu sehen.
Nach dem nRF24L01+ brauchst zu Equipment für 2,4 GHz ! Das ist HF ! Da
nutzt Dir der SALEA LA. gar nix.
In den DTU´s sitzt nach unseren bisherigen Erkenntnissen ein
Kombi-Baustein nämlich ein nRF24 inkl. 80x51 CPU = NRF24LE1E. LE1E ist
was anderes als LE1+ ! Dazwischen wirst Du kaum Sniffen können.
Alles kalter Kaffee wenn Du alles gelesen hättest.
ModBus sniffen nutzt auch niemand was.
Einzig ein oder mehrere nRF24L01+ die auf allen Kanälen mithören und in
zeitlich korrekter Reihenfolge Telegramme mithören nutzen etwas.
Ausgelöste Aktionen über ein DTU-Pro oder/und die Cloud, die wir ja
umgehen wollen.
Es wäre sehr schön, wenn Du uns mit Deiner Erfahrung in dieser Richtung
weiter unterstützen würdest. Danke schon mal.
Viele Grüße Herbert
Hallo Herbert, ich verstehe dich sehr gut. Ich gebe dir auch recht das ich mich hier relativ spät eingeklingt habe. Dennoch bin ich nicht auf die Nase gefallen. - Vorschlag: Alle Fortschritte und Todos in Github zu hinterlegen (Wiki)? Ich habe weder ein Spectrum Analyzer, noch ein Oszi um HF messen zu können. Das habe ich alles auf der Arbeit, kann es aber dort schlecht privat nutzen. ;) - Via DVB-T und einem SDR, das ist bei mir aber aktuell irgendwie nicht möglich (Treiber problem? -> zuletzt vor über 1 Jahr benutzt). Um kurz mein Gedanke nochmal neu zu Formulieren, damit ihr wisst wie ich gerne euch Unterstützen kann und möchte: Ich habe Zuhause aktuell ein HM-1500 und einen "NRF24L01+" der an einem ESP32 angebunden ist. Wenn ich später einen DTU-Pro haben sollte, wird sich auch später zeigen was im inneren steckt. Aufjedenfall meine ich mit dem oberen Post, das man auf dem PCB (wird ja nach der Antenne, mit Filter, etc... auch irgendwo ein IC sein der die Signale in Pakete umwandelt) mitlauschen kann. Sei es Seriel oder anderweitig. Da ich den WR ungern ausseinander nehmen möchte und auch nicht so auf die schnelle die fliegende Pakete in der Luft aufnehmen kann (ohne Equipment nicht möglich, höhö), bleibt mir aktuell nur die Möglichkeit hinter dem NFR-IC am DTU mit zu lauschen. Ich weis, am besten were Zeitgleiche protokolierung auf beiden Seiten WR + DTU um beide Pakete vergleichen zu können, um die genaue reihenfolge zu erkennen und und und... Aber danke Herbert. PS: Die Funktion "Bearbeiten" nutze ich um nicht Unnötig denn Thread zu spamen. Wenn ich Neuinformation habe die für jemand Hilfreich seien können, schreibe ich es eben nachträglich rein. =)
:
Bearbeitet durch User
Angehängte Dateien:
-
Ahoy-44.JPG
72 KB
Lukas P. schrieb: > ESP Version 0.4.4, alle bekannten Fehler (außer sporadische Abstürze) > behoben Moin, hm... funtzt bei mir leider nicht. Hatte vorher die 0.3.6 am laufen.
Ralf B. schrieb: > funtzt bei mir leider nicht. Schöne Fehlerbeschreibung =) bitte auf Github und mit mehr Details: - Serielle Konsole, kommt was? - Visualisierung von ESP, ist alles Null? - Wechselrichter 1,2 oder 4 Kanäle? - Pinout in der Setup nochmal gegengecheckt? - woran machst du fest, dass es nicht geht?
isnoAhoy schrieb: > Hallo Sascha D. (bandit7311) & Ziyat T. (toe_c): > > Ich habe mir mal die Mühe gemacht und den Thread bis hierher auf DTU und > speziell DTU-Pro Geräte analysiert. Hier also mal eine evtl. nicht ganz > vollständige Liste der DTUs im Besitz von Foren Teilnehmern. Hallo isnoAhoy Da ich der einzige mit einem MI1500 bin, und hier alles um den HM dreht, hab mal "aufgehört" weiter zu bohren, aber ich werde bald einen HM1500 bekommen.. Ich habe mit der NRF24_Sniff/wireshark von Ivo Pullens gespielt, kam aber nicht weiter. Das Protokoll für MI ist chaotisch;-) > 0xC000 und 0xC001 wären interessant, wobei ich 0xC000(An/Aus auch über > ein Relais lösen könnte). Was ich bisher über Modbus gefunden habe, für MI series: - 0xC000 on/off geht bei MI nicht - 0xC001 nur bis 10% der angeschlossene PV-Nennleistung limitierbar, darum zero export (ich meine eine NULL) mit dem MI nicht machbar - 0xC006x/0xC007x Steuerungen der Ports gehen nicht Grüsse, Ziyat
:
Bearbeitet durch User
Angehängte Dateien:
-
rx_tx.jpg
180 KB
Hallo Ziyat T. und Daniel R., die Aufnahmen mit dem Salea Logic Analyzer sind auf der Platine der DTU / DTU-Pro an den RX/TX Testpunkten. Hier nochmal das Bild von martin (Gast) der das bei seiner DTU-Lite sehr schön dokumentiert hat. Die Aufnahme ist bei 115200 Baud mit dem Salea sehr gut möglich und hat sowohl senden als auch empfangen, inklusive evtl. vorhandener Retransmit Requests.
Angehängte Dateien:
Daniel R. schrieb: > Ziyat T. schrieb: >> Ich habe eine DTU-Pro > > Hallo Ziyat, bist du hier noch aktiv? Hallo Daniel Ich pausiere mal, da ich einen MI1500 habe und nicht weiter gekommen bin, bald bekomme ich einen HM1500, hoffe ich mal, dann gehts weiter. Ich konnte den MI nicht ansprechen, aber wenn die DTU eingeschaltet ist konnte ich mithören und aufschlüsseln, siehe Anhang. Die Werte stimmen exact. Meine DTU-Pro kann ich nicht ausleihen, da sie im Betrieb ist und ich bin ca. 2000km weit weg.. Grüsse
Hatte das gleiche Problem, dann erstmal alle libraries geupdated. Nochmals kompiliert und upload. Danach funktioniert es wieder problemlos.
Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die Möglichkeit, die Daten per JSON String zu übermitteln ?
Robert Bleumer schrieb: > Hatte das gleiche Problem, dann erstmal alle libraries geupdated. > > Nochmals kompiliert und upload. Danach funktioniert es wieder > problemlos. Das wusste ich nicht, habe eigentlich nichts verändert was neue Versionen braucht -zumal ich die genauen Abhängigkeiten gar nicht kenne.
Hans W. schrieb: > Da die MQTT Anbindung ja recht instabil ist, gibt es nicht die > Möglichkeit, die Daten per JSON String zu übermitteln ? Auch bei JSON String würden wir auf eine externe Library setzen. Was haben wir dann gewonnen? Wer sagt und das es stabiler ist? Wir können es als Option vorsehen, genauso wie MQTT auch eine Option und kein Muss ist. Wenn du sowas implementierst kannst du es gerne per Pull Request beitragen. Schau mal auf GitHub, da hat @isnoAhoy aka stefan123t unter issue #24 einiges zu abstürzen geschrieben. Ich bin der Meinung, das sehr viel auch von der Powerversorgung abhängt. Evtl. sollen wir alle den Code um den MQTT Bereich nochmal genau reviewen.
:
Bearbeitet durch User
Lukas P. schrieb: > Wenn du sowas implementierst kannst du es gerne per Pull Request > beitragen. Ich bin leider kein Coder, sondern eher Copy & Paste'er...
Komme gerade echt mit dem Hoymiles nicht hinterher. Habe das Projekt aber nicht vergessen. Meine DTU liegt noch unbenutzt im Schrank. Toll, was wir schon alles rausgefunden haben. Sobald ich ein bisschen mehr Zeit habe, mache ich nochmal einen Anlauf. Liebe Grüße - Martin (petersilie)
@ Ziyat T. (toe_c) Danke für die Bilder, ich habe mir die mal auf die schnelle angeschaut und dabei ist mir aufgefallen, dass in der DTU-Pro das gleiche NRF Modul aufgelötet wurde wie in den HM Wechselrichtern selbst verbaut ist(siehe HM800 Zerlegtbilder). Ich konnte allerdings auch nach einer halben Stunde im Netz suchen dieses Modul nicht finden, da das Pinout natürlich interessant wäre. Auf dem Abschirmdeckel scheint leider auch kein Typ aufgedruckt zu sein (die HM800 Bilder waren dafür eh zu unscharf). Da das Modul aber anscheinend HMRF-SMD-V1.1.0 heißt, gehe ich mal stark davon aus, dass Hoymiles die Module für sich selbst fertigen lässt(darum HMRF) und es keine vergleichbaren NRF Module auf dem freien Markt gibt. Die Rückseite der Platine(vorallem zwischen STM und NRF Modul) wäre sicherlich auch interessant ;-) Jetzt kommen die Vermutungen von mir (bin kein Platinenexperte, werden andere hier sicher noch besser herausfinden, aber um einen Anfang zu haben): erstmal das wohl wichtigste: auf dem NRF Modul sind zum Glück 3 Pins beschriftet, diese scheinen für mich recht eindeutig zu sein: G - Ground R - Rx T - Tx ob die direkt zum NRF Sender gehen ist derzeit noch unbekannt, auch ob sich auf der Rückseite Lötpads dazu befinden oder vielleicht mit dem nachfolgenden Connector(gegenüber) verbunden sind P201_NC geht ja offensichtlich zu einer kompletten Seite des NRF Moduls, eventuell steckt da mehr darunter, als nur ein NRF-Chip, da so viele Pins entweder auf Debug oder programmierbar hindeuten. Wenn wir Pech haben ist da noch ein extra Mikrokontroller auf der Platine und die Kommunikation zum STM findet über ein eigenes Protokoll statt, nicht direkt die NRF Datenkommunikation. CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn unteranderem zu Programmieren oder Debuggen. Wer es sich zutraut und überhaupt machen möchte/kann, von den DTU-Pro Besitzern, kann gern die Abschirmhaube ablöten, dann wäre ein Geheimnis mehr gelüftet, muss aber nicht unbedingt sein, da wir auch andere Wege haben an die Daten zu kommen.
Angehängte Dateien:
vielleicht so ähnlich :-)
:
Bearbeitet durch User
Guten Abend zusammen, ich melde mich erst jetzt. Huii die Bilder sind Interessant, aber nochmal von Anfang an. @ Ziyat T.: Alles klar, ist doch kein Problem. Wenn wir es geschaft haben, könne wir bestimmt an diesem 2000km weiten Ort Urlaub machen? :P - Spaß hehe Die Bilder sind schonmal sehr gut, könntest du in Zukunft eine komplette Aufnahme vom Board (Vorder und Rückseite) machen? Dann kann man sich auch besser vorstellen wo was ist. Muss aber nicht sein, die Bilder sollten auch so schon reichen. :) @Martin G(petersilie): Kein Ding, ich bin dabei alles auch aufzuholen und das ist wahnsinnig was hier schon geleistet wurde. @ Andi: Da gebe ich dir recht, die Schnittstelle P201_NC könnte uns vielleicht helfen... wer weiß vielleicht auch ein Terminal zum lesen und schreiben? Anyway, die PINS auf dem Modul mit G R T sind Goldwert (wenn es nicht intern deaktiviert wurde). Ich gehe mal davon aus das sie auch nicht rausgeführt wurde. Oder es geht unter dem Modul weiter. Hätte ich eine DTU-Pro würde ich das machen, hab alles hier bei mir zum Ablöten. ^^ Edit: Gerade was geschrieben, schon eine neue Nachricht. @ Herbert K: Super! Es geht weiter, sieht sehr ähnlich aus. Laut Tabelle ist CN201_NC eine SPI Schnittstelle.
:
Bearbeitet durch User
Angehängte Dateien:
und noch eines aus dem MI-1200
Angehängte Dateien:
-
dtu_lite.jpg
12 KB
Andi schrieb: > und dabei ist mir aufgefallen, dass in der DTU-Pro das gleiche NRF Modul > aufgelötet wurde wie in den HM Wechselrichtern selbst verbaut ist Das ist ein von Hoymiles entwickeltes und FCC freigegebenes Modul, wie auf Seite 1 des Threads schon verlinkt wurde: https://fcc.report/FCC-ID/2ARNB-HM2401/ Macht es sicher einfacher mit der Zulassung, das als Modul auszulagern, sonst müssten sie vermutlich jeden Inverter einzeln zertifizieren lassen... Im Endeffekt ist es aber immer die gleiche Funkschnittstelle. Die DTU (Lite) hat es nicht als Modul sondern direkt onboard. Bei der DTU Lite kommt über SPI vom NRF24LE1E keine Kommunikation - ich gehe davon aus, dass es bei den Modulen nicht anders ist. Jemand hatte mal vorgeschlagen, den NRF24LE1E Flash auszulesen und den Code zu reassemblieren, um so evtl. einen Hinweis auf die darin laufende Software und das Channel-Hopping zu bekommen. Was bräuchte ich denn dazu?
Herbert K. schrieb: > und noch eines aus dem MI-1200 Hallo Herbert, konntest du den MI1200 schon ansprechen?
Ziyat T. schrieb: > Hallo Herbert, konntest du den MI1200 schon ansprechen? Hallo Ziyat, ich habe selbst den MI1200 nicht. Ich habe HM350/400.
Hallo martin (Gast), das mit dem einen Standard nRF24 Modul von Hoymiles HM2401 klingt logisch. Da spart man sich sicher einen Haufen Papierkram auf diese Art und Weise. Deswegen ist das Modul wahrscheinlich auch mit einer Platte abgeschirmt, damit es eben ein Standardtestobjekt für die EMV Messungen ist. Hier die anderen FCC Reports von Hoymiles: https://fcc.report/company/Hoymiles-Converter-Technology-Co-L-T-D Der Microprozessor auf der Platine ist ein STM32F402/STM32F407 und ich nehme auch an der Port CN201_NC ist ein SWD / JTAG Port. @Ziyat T., ich konnte die letzte Ziffer der MCU auf der DTU-Pro nicht lesen, kannst Du diese bitte nochmal mit Adleraugen erspähen und ggf. bestätigen ? Auch eine FCC-ID der DTU-Pro wäre hilfreich um diese ggf. in den einschlägigen Datenbanke zu finden. Danke! Auf der Suche nach der FCC ID der DTU-Pro habe ich auch noch ein Projekt von Arek Kubaki gefunden mit dem man die DTU-Pro per Modbus steuert: https://github.com/ArekKubacki/Hoymiles-Plant-DTU-Pro Für das Auslesen des Flash Speichers brauchst Du im Prinzip OpenOCD und einen Debugger, z.B. ein bluepill STM32 oder eines der üblichen USB-Dongles STLinkV2 / JLink ab 6 Euro oder direkt mit dem Raspberry Pi als Interface. Dann bringt man den nRF24 oder auch den STM32F4x in den JTAG / SWD Modus und kann ihn dann anhalten bzw. den Flash langsam auslesen. OpenOCD startet man mit mehreren Config Files, hier eines für das Interface, mein STLinkV2 USB Dongle und als zweites die Zielarchitektur / CPU, die man steuern / debuggen möchte: openocd -f interface/stlink.cfg -f target/stm32f4x_stlink.cfg https://www.openocd.org/doc/html/Flash-Commands.html Den Flash Speicher selbst kann man dann mit Ghidra (OpenSource aus dem Sonder-Programm der CIA) zurück zu C dekompilieren, wenn man kein IDA Pro sein Eigen nennt. CAVE CANEM: Zu beachten ist dass evtl. auch die Read Out Protection aktiviert sein kann. I.d.R. machen das die Produzenten aber m.W. aus den selben Gründen nicht wie wir, es ist einfacher den Code überzubügeln ohne die ganze Security =^/ https://stackoverflow.com/questions/32509747/stm32-read-out-protection-via-openocd
Prima, hier (https://fccid.io/2ARNB) gibt es neben den bekannten drei Prüfberichten auch noch das Sub-1G Modul HMS10. * 2ARNB-HMS10 Sub-1G Module * 2ARNB-HM2401 2.4G RF Module * 2ARNB-MI1200 Microinverter * 2ARNB-DTUW100 Data Logger Mit einem kompletten UserGuide und den Pin Belegungen: https://fccid.io/2ARNB-HMS10/User-Manual/User-manual-5204741 2.2 Pin Definition This Table 1 describes the interface pins. Table 1 HM2401 interface pins NO. Symbol I/O Type Function 1 Gnd P Power supply reference ground pin 2 NC I Null pin, no internal connection 3 P1.5 I/O RESERVED, P1.5, which is connected to P1.5 on the IC 4 P1.6 I/O RESERVED, P1.6, which is connected to P1.6 on the IC 5 P0.1 I/O RESERVED, P0.1, which is connected to P0.1 on the IC 6 P0.6 I/O RESERVED, P0.6, which is connected to P0.6 on the IC 7 NC I/O Serial peripheral interface clock pin 8 GND P Power supply reference ground pin 9 RXD I/O UART_RX, which is connected to P0.4 on the IC 10 TXD Output UART_TX, which is connected to P0.3 on the IC 11 GND P Power supply reference ground pin 12 VCC P Power supply pin 13 PRG I/O Set high to enter flash programming mode 14 SCK I/O Serial peripheral interface clock pin 15 RST I/O Hardware reset pin (active at a low level) 16 GPIO I/O Reserved 17 MI I/O Reserved 18 SCN I/O Reserved 19 GND P Power supply reference ground pin 20 GND P Power supply reference ground pin 4.1 NRF Channel List Depending on the program, the module can work on 915MHz for North America and 868MHz for Europe. Unless necessary, it’s forbidden to change the module program. sic
Sorry for spamming, das HMS2401 enthält ebenfalls die gesuchte Pin Belegung, nur leicht geändert. Selbst die Tabellenüber/-unterschrift scheint prinzipiell beides mal "HM2401 interface pins" zu sein: UserGuide und den Pin Belegungen: https://fccid.io/2ARNB-HM2401/Users-Manual/User-Manual-4572285 2.2 Pin Definition This Table 1 describes the interface pins. Table 1 HM2401 interface pins NO. Symbol I/O Type Function 1 Gnd P Power supply reference ground pin 2 NC I Null pin, no internal connection 3 P1.5 I/O RESERVED, P1.5, which is connected to P1.5 on the IC 4 P1.6 I/O RESERVED, P1.6, which is connected to P1.6 on the IC 5 P0.1 I/O RESERVED, P0.1, which is connected to P0.1 on the IC 6 P0.6 I/O RESERVED, P0.6, which is connected to P0.6 on the IC 7 SCK I/O Serial peripheral interface clock pin 8 GND P Power supply reference ground pin 9 RXD I/O UART_RX, which is connected to P0.4 on the IC 10 TXD Output UART_TX, which is connected to P0.3 on the IC 11 GND P Power supply reference ground pin 12 VCC P Power supply pin 13 PRG I/O Set high to enter flash programming mode 14 SCK I/O Serial peripheral interface clock pin 15 MO O Serial peripheral interface data output pin 16 MI I Serial peripheral interface data input pin 17 SCN I/O Serial peripheral interface Chip selection pin 18 RST I/O Hardware reset pin (active at a low level) 19 GND P Power supply reference ground pin 20 GND P Power supply reference ground pin 3.2 Summarize the specific operational use conditions **This module can be used in DTU, micro-converter and other equipment**. The input voltage to the module should be nominally 1.9~3.6 VDC and the ambient temperature of the module should not exceed 80°C. HM2401 uses a PCB antenna with max antenna gain 2 dBi. If the antenna needs to be changed, the certification should be re-applied. 4. Basic Operation 4.1 NRF Channel List Depending on the program, the module can work on 2403, 2423, 2440, 2461 or 2475MHz. Unless necessary, it’s forbidden to change the module program. 6. Technical Data Model HM2401 Type 2.4G RF Channel List 2403, 2423, 2440, 2461, 2475MHz Modulation Type GFSK Antenna Gain 2dBi Working Voltage 1.9~3.6V Power Consumption 40mW typical
Ich bekomme merkwürdigerweise die Ahoy-Software nicht zum laufen Auf der Konsole kommt nur Requesting Inverter SN 116474903203 Transmit 27 | 15 74 90 32 03 78 56 34 12 80 0B 00 62 87 96 11 00 00 00 05 00 00 00 00 09 81 AC Error while retrieving data: last frame missing: Request Retransmit Transmit 27 | 15 74 90 32 03 78 56 34 12 80 0B 00 62 87 96 11 00 00 00 05 00 00 00 00 09 81 AC Error while retrieving data: last frame missing: Request Retransmit Merkwürdigerweise funktioniert das Ganze mit Hubis NRFSendRcv - einen Hardwarefehler kann ich somit eigentlich ausschließen? Das Thema IRQ an D1 oder D3 ist mir bekannt, auch ein flashen einer blank.bin brachte nichts Hat jemand zufällig ähnliche Erfahrungen und eine Lösung gefunden?
Hallo Heinz R, dieses Problem hatte ich auch. Prüf mal ob im Webinterface auch die S.Nr. hinterlegt ist vom WR. Danach sollte es gehen. :)
Daniel R. schrieb: > Hallo Heinz R, > > dieses Problem hatte ich auch. Prüf mal ob im Webinterface auch die > S.Nr. hinterlegt ist vom WR. > > Danach sollte es gehen. :) Was glaubst Du was das wohl bedeutet Du Quasselstrippe: Requesting Inverter SN 116474903203
Joa bei so einer patzigen Antwort kann ich auch nicht viel sagen. Kann ja sein das ein Zahlendreher drinnen ist. Hatte auch mal zum Testen 123456 geschrieben und wurde im Log angezeigt.
Heh, Harald. Trollen ist meine Aufgabe !!1! Ist denn 1164... richtig? Sollte das nicht 1161 sein? Was noch merkwürdig ist, wenn kein Frame empfangen wurde kann man auch kein retransmit anfordern. Weil ein einzelnes Frame bzw. damit auch automatisch, und das letzte Frame nicht retransmittet werden kann.
> Weil ein einzelnes Frame bzw. damit auch > automatisch, und das letzte Frame nicht retransmittet werden kann. Niemand kann diesen Satz verstehen.
Beitrag #7070975 wurde vom Autor gelöscht.
Jan-Jonas S. schrieb: > Ist denn 1164... richtig? Sollte das nicht 1161 sein? Danke Jan-Jonas, das war der entscheidende Tipp, es läuft jetzt Ich hatte mal mit dem Handy ein Foto vom WR gemacht , die Nummer eingegeben Aber ich hatte vergessen das ich danach auch mal ein Foto von einem HMS.2000 gemacht habe :-) Wollte es gerade hier hochladen - sehe es mir genau an - ich Depp... Viele Grüße
Guten Abend, ich habe einen HM-600 und würde gern die Daten auslesen. Hierfür wollte ich einen ESP-01 sowie das Funkmodul NRF24L01+. Nun stehe ich vor der Frage, wie verbinde ich beide Module miteinander. Das ESP-01 scheint ja den SPI-Bus nicht nach außen zu legen, und das wird für die Kommunikation mit dem NRF24L01+ benötigt. Sehe ich das richtig? Also bleibt mir nur, einen anderes ESP8266-Modul zu besorgen, welches SPI über Pins verfügbar macht? Viele Grüße
Harald schrieb: >> Weil ein einzelnes Frame bzw. damit auch >> automatisch, und das letzte Frame nicht retransmittet werden kann. > > Niemand kann diesen Satz verstehen. Doch ich ;-) Ich habe es so implementiert, dass beim Fehlen des letzten Pakets nochmal alles mit dem gleichen Zeitstempel angefordert wird.
S. W. schrieb: > Sehe ich das richtig? Also bleibt mir nur, einen anderes ESP8266-Modul > zu besorgen, welches SPI über Pins verfügbar macht? Moin S.W., so sehe ich das auch. Das sollte ja kein Problem sein, ein neues ESP Kosten ja fast nichts. :) Ich empfehle dir ein ESP32, dann kannst du für spätere Projekte diesen auch weiter verwenden.
Kurze Info: Seit dem Update von Ahoy 0.3.9 auf Ahoy Version 0.4.5 ist die MQTT Verbindung viel stabiler. Vorher ist die Verbindung nach max. 5h abgebrochen. Aktuell steht die Verbindung seit 31h.
Ich nehm (fast) alles zurück. Von wegen man kann das letzte Paket nicht retransmitten...
1 | Poll inverter 114172220143 |
2 | 2022-05-21 18:08:58.192865 Transmit 27 | 15 72 22 01 43 78 56 34 12 80 0b 00 62 89 0e 9a 00 00 00 05 00 00 00 00 80 20 5e |
3 | 2022-05-21 18:08:58.244718 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 01 00 01 01 41 00 68 01 4e 01 42 00 6a 01 56 00 01 8d |
4 | 2022-05-21 18:08:58.285863 Received 27 bytes channel 75: 95 72 22 01 43 72 22 01 43 02 01 60 00 00 f8 70 06 a3 06 82 08 e0 13 8b 02 85 a8 |
5 | Error while retrieving data: Missing packet: Last packet 2 |
6 | 2022-05-21 18:08:58.788941 Transmit 11 | 15 72 22 01 43 78 56 34 12 83 8c |
7 | 2022-05-21 18:08:58.832128 Received 23 bytes channel 75: 95 72 22 01 43 72 22 01 43 83 00 00 00 1c 03 e8 01 19 00 07 18 15 f3 |
8 | 2022-05-21 18:08:59.334726 Payload: 00 01 01 41 00 68 01 4e 01 42 00 6a 01 56 00 01 01 60 00 00 f8 70 06 a3 06 82 08 e0 13 8b 02 85 00 00 00 1c 03 e8 01 19 00 07 18 15 |
9 | 2022-05-21 18:08:59.334726 Decoded: 28.1 phase0=voltage:227.2, current:2.8, power:64.5, frequency:50.03 string0=voltage:32.1, current:1.04, power:33.4, total:65.888, daily:1699 string1=voltage:32.2, current:1.06, power:34.2, total:63.6, daily:1666 |
Edit. Mistiges Mistforum kann kein Markdown
:
Bearbeitet durch User
Aber sicher Herr Düsentrieb, die sind ja auch binärkompatibel. > Ich empfehle dir ein ESP32, dann kannst du für spätere Projekte diesen > auch weiter verwenden.
Der Akkusativ wäre auch noch passend. Aber das lernt wohl niemand mehr in der Schule, traurig. 😪😪😪😪
Hallo, ich lese hier sonst nur mit und hab mich jetzt angemeldet und komme leider mit einer OT Frage Hat jemand auf dem DTU Pro Board schon eine serielle Schnittstelle oder eine Terminalschnittstelle gefunden? Meine DTU ist tot. Weder per IP erreichbar, noch spannt sie ein WLAN auf. Danke
Moin Thomas, laut einer Excel-Tabelle "Hoymiles-SerialNumbers.xlsx" gibt es nur einer der ein DTU-Pro hat (indirekt noch einer). Die Frage, ist es frisch gekauft oder gebraucht gekauft? Es gibt Bilder die vom inneren einer DTU zeigen "DxTxUxPxRxOinnereien.zip", hier wird auch eine Schnittstelle gezeigt. Andi schrieb: > CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn > unteranderem zu Programmieren oder Debuggen. - SPI Schnittstelle - Ob jemand sich da schon reingehängt hat, kann ich aktuell nicht sagen. Soweit ich weiß haben wir keine weiteren Infos darüber. Kannst ja gern mal schauen. Ansonsten zum Problem: Erstmal die einfachen Fragen, Liefert das Netzteil die Spannung? Nicht das hier der Fehler liegt. :P 2.) Wenn du es am LAN-Port hängst bekommst du ein Link? - LED leuchtet, oder die gegenstelle (Switch) blinkt fröhlich? 3.) Netzwerkkabel defekt? - Kann ja sein^^ 4.) Sieht man sonst irgendeine Status LED? Gruß Daniel
hi zusammen, hab jetzt meine esp version von 4.4 auf 4.8 geupdatet. jetzt gibt es im setup die möglichkeit dort die maximale wp vom angeschlossenen modul anzugeben. wofür ist das gut? davon abgesehen das ich bei meinem hm-400 nur 1 modul anschließen kann, habe ich die auswahl von 4 modulen zum eintragen. offtopic.: hat jemand schon nen gehäuse für nen wemos d1mini und dem nrf24 modul mit der externen antenne für nen 3d drucker konstruiert? bei thingi hab ich nix passendes gefunden mit der kombi
Daniel R. schrieb: > Moin Thomas, > > laut einer Excel-Tabelle "Hoymiles-SerialNumbers.xlsx" gibt es nur einer > der ein DTU-Pro hat (indirekt noch einer). > > Die Frage, ist es frisch gekauft oder gebraucht gekauft? > Es gibt Bilder die vom inneren einer DTU zeigen > "DxTxUxPxRxOinnereien.zip", hier wird auch eine Schnittstelle gezeigt. > > Andi schrieb: >> CN201_NC ist vermutlich eine serielle Schnittstelle zum STM um ihn >> unteranderem zu Programmieren oder Debuggen. > > - SPI Schnittstelle - > > Ob jemand sich da schon reingehängt hat, kann ich aktuell nicht sagen. > Soweit ich weiß haben wir keine weiteren Infos darüber. > > Kannst ja gern mal schauen. > > Ansonsten zum Problem: > Erstmal die einfachen Fragen, Liefert das Netzteil die Spannung? Nicht: Netzteil hab ich schon gewechselt > das hier der Fehler liegt. :P > > 2.) Wenn du es am LAN-Port hängst bekommst du ein Link? - LED leuchtet, > oder die gegenstelle (Switch) blinkt fröhlich? LEDs blinken alle > > 3.) Netzwerkkabel defekt? - Kann ja sein^^ Switch zeigt an, das Rx und Tx Pakete drüber gehen und link ist auf 100Mbit er holt sich aber keine DHCP Adresse mehr. Anderer Switch und anderes NIC Kabel erfolglos getestet. muss mir dann einen Notebook mit Wireshark fertig machen und die Kommunikation mit der betreffenden MAC ansehen > 4.) Sieht man sonst irgendeine Status LED? Die Status-LEDs zeigen, dass kein Internet und keine Cloud da ist. Anderer Switch und anderes NIC Kabel getestet PS: Das Gerät war ein Neukauf und lief 18 Monate störungsfrei. > > > Gruß Daniel Dankeschön .. Gruß Thomas
Hi,
habe meins nun auch geupdated 0.4.4 auf 4.8.
Aktuell habe ich damit nun immense WiFi probleme.
Ping wird ausgeführt für 192.168.10.149 mit 32 Bytes Daten:
Antwort von 192.168.10.149: Bytes=32 Zeit=46ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=85ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=99ms TTL=255
Antwort von 192.168.10.149: Bytes=32 Zeit=2ms TTL=255
Ping-Statistik für 192.168.10.149:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 2ms, Maximum = 99ms, Mittelwert = 58ms
Firefox (v100.0.2) lädt sich ins Nimmerleinstag. =(
ESP Serial Verbindung bleibt leer, irgendwann schmeist er mir paar logs
entgegen.
@Thomas: Uiii, das ist ja Interessant... hmm sag mal bescheid wie weit
du gekommen bist. Wobei, ich habe die Vermutung (da es länger ohne
Probleme lief), das hier eventuell am Board probleme gibt.
Ich kenn es nur von einem 48-Port Switch (uralt), das hier ein DC/DC +
Elkos flöten gegangen sind. Aber da es an sich "Neu" ist, hmm ... :/
Zur Not Werksreset durchführen?
:
Bearbeitet durch User
Die WLAN Probleme mit der neuesten Version kann ich ebenfalls bestätigen. Ca. 3 Sekunden nach dem ersten Success + Inverter available scheint der ESP abzuschmieren(Builtin-LED bleibt aus, Webif/ESP nicht mehr erreichbar), dann fliegt er sehr oft aus dem WLAN(scheint hin und wieder sehr langsam erreichbar zu sein). Ist am einfachsten zu testen, wenn man ihn hochfährt und direkt danach auf der Statusseite bleibt, da sieht man das Pairing und danach bleibt die Uptime und alle anderen Zähler stehen. Ich habe mich jetzt nicht weiter damit rumgeschlagen und bin erstmal wieder auf die 0.4.4 zurück.
Andi schrieb: > Die WLAN Probleme mit der neuesten Version kann ich ebenfalls > bestätigen. > Ca. 3 Sekunden nach dem ersten Success + Inverter available scheint der > ESP abzuschmieren(Builtin-LED bleibt aus, Webif/ESP nicht mehr > erreichbar), dann fliegt er sehr oft aus dem WLAN(scheint hin und wieder > sehr langsam erreichbar zu sein). Sehr schade, könnt ihr mir sagen welchen WR ihr habt. Es genügt 1, 2 oder 4 Kanäle. Gerne auch über Github issues. Ich kann keine Abstürze sehen (mehr als 6h Uptime) und habe das 4-Kanal Setup.
@lumapu Da ich die Version nur kurz getestet habe, kann ich nur Aussagen aus dem Kopf machen und nicht 100% genau Infos liefern, darum habe ich kein Issue im Git aufgemacht. Ich habe einen HM800, also 2 Eingänge. Ich habe mir den Code noch nicht so genau angesehen, aber rein vom Gefühl her ist die LED normalerweise an und beim Rx und/oder Tx flackert sie kurz, beim Fehlerfall war sie allerdings dauerhaft aus und im Router war der ESP nicht mehr verbunden, also scheint er sich wohl komplett aufzuhängen an irgendeiner Stelle nach den ersten Daten. Jetzt weiß ich aber nicht mehr genau, ob der nach paar Sekunden wieder langsam erreichbar war oder weil ich Resettet habe. Ich hatte auch beim rumspielen bei dem Fehler auf einmal alle Daten verloren(macht der ESP trotz einfach Stecker ziehen ja normalerweise nicht). Deswegen bin ich mir mit der WLAN aussage nicht ganz sicher, eventuell war die LED und WLAN auch nach dem Verlorengehen der Daten aus. Was ich aber sehr sicher sagen kann ist, dass der Zugriff auf das Webif grottig bis hin zu nicht erreichbar war, als er noch die gespeicherte Konfig hatte und das kurz nachdem der Inverter als available in den paar Zeilen auf dem Homescreen war. Vielleicht kann ich es ja morgen nochmal genauer testen, wenn es bis dahin nicht schon behoben ist :-)
Tobi D. schrieb: > jetzt gibt es im > setup die möglichkeit dort die maximale wp vom angeschlossenen modul > anzugeben. wofür ist das gut? davon abgesehen das ich bei meinem hm-400 > nur 1 modul anschließen kann, habe ich die auswahl von 4 modulen zum > eintragen. Der ESP berechnet die Einstrahlung in Prozent, sodass man sehen kann wie gut die Module ausgerichtet sind / wie klar die Luft ist. Während man die Wechselrichter einträgt hat man noch keine Möglichkeit zu wissen wie viele Kanäle es geben wird, daher immer die Maximale Anzahl von 4.
Moin Lukas, Github Issue ist raus. Hoffe passt, wenn du mehr Infos brauchst einfach melden. :)
Lukas P. schrieb: .... wofür ist das gut? davon abgesehen das ich bei meinem hm-400 >> nur 1 modul anschließen kann.... Das ist ja wohl Quatsch ! Natürlich kann man da auch mehr Module anschließen ! Es ist halt nur 1 MPPT Eingang da mit 1 Paar Steckkontakten. Ich habe z.B. am HM350 2 Stk. Module. Das kommt ja auf die Daten der Module und der WR drauf an, das es zusammenpaßt zu Strömen, Spannungen und Leistungen.
Ja natürlich kann ich auch mehrere module in Reihe oder parallel im hm-400 anschließen aber dann müssen die Werte von allen Modulen meiner Meinung nach dann trotzdem in das erste Feld eingetragen werden, da ja nur 1 Eingang da ist
Angehängte Dateien:
-
IMG_20220524_193539.jpg
230 KB -
IMG_20220524_194100.jpg
230 KB -
IMG_20220524_194121.jpg
230 KB -
IMG_20220524_194131.jpg
240 KB -
IMG_20220524_193651.jpg
210 KB -
IMG_20220524_193621.jpg
220 KB -
IMG_20220524_193539.jpg
230 KB
Ich meld mich auch mal wieder, nachdem GreenAkku das TSUN-Gateway statt mit 1-2 Tagen Lieferzeit dann nach knapp 6 Wochen doch endlich mal verschickt hat. Gut sichtbar ist der Controller STM32F103, danach kommt der UART-WIFI Converter und selbstverständlich der NRF 24LE1E. Das Platinenlayout ist relativ ähnlich zu Hoymiles. Ich schaue mir die Kommunikation an, wenn ich weiß, wo ich was sinnvolles aus der Platine bekomme. Die Rx/Tx Pins sind bei mir 3 Tastpunkte in etwas anderer Anordnung. Die ID'S laufen nach dem Muster: 10D573118xxx Die x sind laufende Nummerierung. Habe mehrere hier. Ist eher Hyperterminal oder Putty für die serielle Verbindung ratsam? Gibt es irgendwas, wo ich besonderen Fokus drauflegen sollte? lg Daniel M. edit: Bilder nachgereicht, nachdem es erstmal nicht ging
:
Bearbeitet durch User
Hallo, gibt es eigentlich einen praktischen Grund für die Beschränkung auf drei Geräte im ESP8266? Ich habe 4 HM-1500 und würde die gerne mit einem ESP auslesen.
Hi Siggi, glaube an so viele Inverter in einem Setup hat hier bisher keiner gedacht. Ich währe schon froh ein Setup zum testen für 2 gleichzeitig zu haben. Python hat da jedenfalls kein Limit gesetzt, ist aber glaube ich noch nie mit mehr als einem gleichzeitig in Betrieb gewesen. Theoretisch sollte es gehen. Hat jemand die rpi-Variante mit mehr als einem am Laufen?
Siggi U. schrieb: > Hallo, > gibt es eigentlich einen praktischen Grund für die Beschränkung auf drei > Geräte im ESP8266? Ich habe 4 HM-1500 und würde die gerne mit einem ESP > auslesen. Klar gibt es die Option, schon sehr lange: https://github.com/grindylow/ahoy/blob/2199d46890ea826a19068253c36e7b4973b65775/tools/esp8266/config.h#L33 Der Code ESP ist theoretisch auch nicht limitiert - nur wird irgendwan der Speicher im Chip selbst knapp.
:
Bearbeitet durch User
Hallo, ich habe per ESP8266 und Hubis Ur-Version 4 WR die ich Seriell abfrage wenn mir danach ist. Funktioniert auch schon mal den ganzen Tag und schreibt schön ein LOG voll auf´m PC. Reicht mir so erst mal um zu sehen, das die WR tun, was sie sollen :-)
Alles klar, dann baue ich mir mal eine Version mit 4 WR. Kann dann ja berichten ob es klappt.
Thomas H. schrieb: > Hallo, > > ich lese hier sonst nur mit und hab mich jetzt angemeldet und komme > leider mit einer OT Frage > > Hat jemand auf dem DTU Pro Board schon eine serielle Schnittstelle oder > eine Terminalschnittstelle gefunden? Meine DTU ist tot. Weder per IP > erreichbar, noch spannt sie ein WLAN auf. > > Danke Hallo Thomas DTU-Pro hat noch Ethernet(RJ45) und RS485-Modbus SS
Tobi D. schrieb: > offtopic.: hat jemand schon nen gehäuse für nen wemos d1mini und dem > nrf24 modul mit der externen antenne für nen 3d drucker konstruiert? bei > thingi hab ich nix passendes gefunden mit der kombi Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls jemand Interesse hat, stelle ich die .stl gern zur Verfügung.
Hi Daniel, Daniel M. schrieb: > > Das Platinenlayout ist relativ ähnlich zu Hoymiles. ich würde mal meinen, dass TSUN und Hoymiles Geräte eher sowas wie "bei-der-Geburt-getrennte-Zwillinge" sind. Die Dinger - auch die DTUs - fallen sicherlich vom selben Band. ;-) > Ich schaue mir die Kommunikation an, wenn ich weiß, wo ich was > sinnvolles aus der Platine bekomme. Die Rx/Tx Pins sind bei mir 3 > Tastpunkte in etwas anderer Anordnung. Ich weiss nicht, ob Dir die UART Testpoints des STM etwas nützen. Um die Kommunikation zwischen STM und Nordic belauschen zu können, musst Du Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO (Output Nordic) und SCK (Clock der SPI) mit einem entsprechenden Logic Analyzer oder SPI Sniffer verbinden und mitloggen... :) Mich würde es allerdings sehr wundern, wenn das Protokoll was ganz anderes wäre als bei den HMs. LG, Lars
Lars B. schrieb: > Um die > Kommunikation zwischen STM und Nordic belauschen zu können, musst Du > Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO > (Output Nordic) und SCK (Clock der SPI) Nein, bei der UART bist du schon richtig. Wie schon mehrfach im Thread beschrieben, findet über die SPI-Schnittstelle des NRF keine Kommunikation statt, die ist nur zur Programmierung des NRF-internen Controllers - zumindest bei der HM-DTU. Wird dann hier vermutlich genauso sein.
Heute gabs 2 neue Videos von hoymiles: 1) https://www.youtube.com/watch?v=ed7rJvYVuJg Ich sag da mal lieber nix zu. Kann sich jeder seine Meinung selbst bilden. Einzig interessant ist der Unterschied zu den DTU..."S" Modellen bei der Reichweite. 2) Anschauen kann man sich auch sparen: https://www.youtube.com/watch?v=9GbAhf3pU7I
:
Bearbeitet durch User
Peter L. schrieb: > Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich > ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls > jemand Interesse hat, stelle ich die .stl gern zur Verfügung. Hallo Peter, ich hätte Interesse an dem .stl :-) Bitte hier oder auf github hochladen. Grüße rosch
rosch99 schrieb: > Peter L. schrieb: >> Für ein Sandwich aus d1mini und nrf24 (ohne externe Antenne) habe ich >> ein kleines Gehäuse mit Aufhängeöse konstruiert und gedruckt. Falls >> jemand Interesse hat, stelle ich die .stl gern zur Verfügung. > > Hallo Peter, > ich hätte Interesse an dem .stl :-) > Bitte hier oder auf github hochladen. > > Grüße > rosch https://github.com/grindylow/ahoy/pull/59 :-)
Hab mal auf die schnelle ein Gehäuse gebastelt für die mit externer Antenne. Bisschen filigran aber lässt sich drucken. (Sorry, bin leider kein Zeichen-Profi ;-) ) https://www.thingiverse.com/thing:5395556 Grüße Thomas
sorbit schrieb: > Hat jemand das schon einmal "angezapft" um ein eigenes Monitoring ohne > deren Cloudzwang zu realsieren? > > Es gibt offensichtlich einen "Adapter", der das "2,4 GhZ Signal umsetzt > und dann via WLAN an deren Cloudsysteme versendet. Eine Anmerkung von mir zur Ausgangsfrage: Mit einer DTU-PRO von Hoymiles für knapp 200 € kann man zwar Daten auch in die Cloud senden. Muss man aber nicht. Man kann die DTU-PRO aber über MODBUS-TCP lokal auslesen und alle Daten aller angeschlossenen Wechselrichter auslesen. Ein konkretes Beispiel mit iobroker findet ihr unter https://forum.iobroker.net/topic/55115/gel%C3%B6st-ben%C3%B6tige-hilfe-modbus-tcp-hoymiles-hm-1500-dtu-pro/6
Hi Bernd, das ist wohl richtig. Allerdings haben wir Spaß am reverse Engineering und wollen die Daten nach Mqtt bzw. Influx exportieren. Kann die DTU-Pro das auch? Spaß bei Seite. Natürlich nicht. Für 200€ kauft man sich lieber ein Panel mehr, anstatt die Wirtschaftlichkeit endgültig zu begraben. Wir machen das mit 20€ :) Nichts desto Trotz brauchen wir die DTU-Pro um sie zu belauschen. Nicht um sie per Modbus-TCP zu befragen. Das kann jeder ^^ Denn wir wollen mehr Daten! ...und besser verstehen, was Hoymiles mit ihrem trojanischen Pferd so in unseren Netzen treibt. Gruß, Jan
martin schrieb: > Lars B. schrieb: >> Um die >> Kommunikation zwischen STM und Nordic belauschen zu können, musst Du >> Dich auf die SPI am Nordic klemmen. Also die Pins SI (Input Nordic), SO >> (Output Nordic) und SCK (Clock der SPI) > > Nein, bei der UART bist du schon richtig. Wie schon mehrfach im Thread > beschrieben, findet über die SPI-Schnittstelle des NRF keine > Kommunikation statt, die ist nur zur Programmierung des NRF-internen > Controllers - zumindest bei der HM-DTU. Wird dann hier vermutlich > genauso sein. richtig - mein Fehler! Der UART zwischen dem GD Controller und dem nRF liegt ja IMHO auf den beiden Testpoints beim Knopf der DTU... Sorry für die Verwirrung, Lars
Hallo zusammen, bei der Bucht wird ein DTU-Pro verkauft. Was denkt ihr, macht es Sinn darauf zu Bieten? Oder könnte es sein, das die DTU beim Hersteller mit einem Account verknüpft ist und diese eventuell probleme aufkommen könnte? Thomas H. schrieb: > Meine DTU ist tot. Könnte ich eventuell dein DTU-Pro mir anschauen, vielleicht kann man da noch was retten? :) Gruß Daniel
Servus, Martin G. schrieb vor einer ganzen Weile im Beitrag #7016238: > Könnte ich mir gut vorstellen, dass sich das Format je nach WR-Typ in > Details unterscheidet. Der HM-1500 hat ja 4 DC-Eingänge. Sind das vier > unabhängige MPP-Tracker? Oder werden die intern z.B. in Reihe > geschaltet? Zumindest schaltet der HM-1500 Gen3 H00.04.00 / V01.00.16 seine 4 Eingänge nicht vor der separaten Messung zusammen, denn in der Cloud und S-Miles-App sehe ich separate, leicht unterschiedliche Leistungsdaten meiner 4 identischen Panels. Aber nur als DC-Leistung. DC current und DC voltage bekomme ich nicht. Habe seit gestern endlich meine DTU-Wlite Gen3 H06.01.01 / V00.03.05. Gibt's in Mödling (AT) erheblich günstiger als bei den Preußen. Habe aber (noch) kein Sniffer-Equipment und die Panels nur provisorisch auf Holzgestell. Stockschrauben, Bituplan und ein regenfreier Tag fehlen noch. Wenn die Mechanik erledigt ist, steige ich mit Eurer Starthilfe gerne mit ins Sniffen ein. Erste ESP8266 Erfahrungen mit ArduinoIDE und VSCode habe ich schon mit ein paar Mods an Airrohr/DNMS gesammelt. Aber Warnung: bei HF-Technik bin ich keine Hilfe. Hatte ich zugunsten Stromrichterantriebstechnik abgewählt (WPU-ET-m88-sg3) und auch davon inzwischen vieles vergessen :-(.
Daniel R. schrieb: > bei der Bucht wird ein DTU-Pro verkauft. Was denkt ihr, macht es Sinn > darauf zu Bieten? Oder könnte es sein, das die DTU beim Hersteller mit > einem Account verknüpft ist und diese eventuell probleme aufkommen > könnte? Wenn Du (wie ich) ein Installateur-Account bei HOYMILES hast und der Verkäufer den DTU bei sich austrägt (oder der Verkäufer Dir seine Accountdaten überlässt), kannst Du das Ding nehmen. Ob man den DTU auch "kapern" kann, nur weil man die Seriennummer weiß? Ich hoffe nicht! Vermutlich kann man ihn nur übernehmen, wenn man Seriennummer und Zugang zum internen WLAN-AP hat. Den spannt er wie viele ESP-Devices auf, wenn er seinen bisherigen externen AP nicht findet. In JEDEM FALL muss die Seriennummer auf dem Gehäuse noch lesbar sein, sonst kannst Du ihn nicht übernehmen! Liegt gerade bei ca. 160€ und läuft noch 11 Stunden. Hatte ich auch in Erwägung gezogen, dann kam der W-Lite aber doch noch an. Zwei erlaubt die Finanzministerin nicht. Wenn Du keinen Installateur-Account bei HOYMILES hast: ich könnte den DTU zur Not bei mir mit eintragen und Dir ein Kunden-Account darauf erstellen. Ich wäre dann quasi Dein Solateur und Du der Besitzer. Servus, BastelBarney
:
Bearbeitet durch User
Maik R. schrieb: > Wenn Du keinen Installateur-Account bei HOYMILES hast: ich könnte den > DTU zur Not bei mir mit eintragen und Dir ein Kunden-Account darauf > erstellen. Ich wäre dann quasi Dein Solateur und Du der Besitzer. Argh! Das ginge natürlich nur, wenn ich einmal physischen Zugriff auf Deinen DTU habe! Kann man im Grunde auch per TeamViewer oder so machen, aber das wird dann arg kompliziert, weil das Gerät, das Du mit der DTU per WLAN verbindest zusätzlich auch per 2. Netzwerkinterface per TeamViewer aus dem Internet erreichbar sein muß. Du willst nicht Deinen PC per TV an mich freigeben. Müßtest also erstmal einen separaten PC dafür einrichten (oder ein Live-Linux booten), nur zu diesem Zweck. Wenn das für Dich ein "kein Problem, mache ich oft" ist, wäre das ein Weg... Ergo: Du brauchst ein Installateur-Account bei HOYMILES oder jemanden in Deiner Nähe, der einen hat. Servus, BastelBarney
Sergey S. schrieb: > Guten Tag! Ich habe H M 600 114170810815 > und DTU W100 10D 373114359. Kann mir jemand helfen, die > “S-Miles-Installer”.Dort wird ein Konto benötigt, aber der Verkäufer > gibt es nicht an, sagt, dass er selbst der Installateur ist. Du benötigst das Installer-Konto nicht unbedingt. Der Verkäufer sollte Dir aber ein User-Account anlegen und geben. Damit greifst Du per global.hoymiles.com auf Deine Daten zu. Oder per "S-Miles-User App". HTH, BastelBarney
Guten Morgen bastelbarney, vielen dank für die Info. Ich verstehe nicht warum der Hersteller das so kompliziert macht... Oh mann. Naja an sich wäre es kein Problem, würde es sogar einfach zu dir schicken wenn es einfacher wäre, dann könntest du es später wieder zurück schicken (Wenn ich dich zwekcs Einrichtung richtig verstanden habe). Ich kenne jemand der die WR verkauft, aber er hat bisher kein DTU-Pro im Sortiment. Edit: Aktuell liegt der Preis in der Bucht bei EUR 157,00 (S.Nr lautet 10f874435634, wie auf dem Bild zu sehen). Da kann ich mir es gleich aus AT bestellen. - https://www.enercab.at/startseite/1057-hoymiles-pv-monitoring-dtu-pro-wifi-monitoring.html Gruß Daniel
:
Bearbeitet durch User
Guten Morgen zusammen, wie erwartet, kochen TSUN und Hoylmiles ein ähnliches Süppchen. Die Tastpunkte auf der Platine sind Rx/Tx zwischen dem NRF und meinem STM. Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein. Die Verbindung läuft ebenfalls mit 125000 BAUD, war nicht so einfach, ein Programm zu finden, dass mir das unter Windows 10 auch in Hex ausgibt. Nutze dafür Realterm. Die Requests sehen so aus und sind als capture.txt-Datei noch im Anhang:
1 | 7E09635003166350031600097F |
2 | 7E11635003166350031600117F |
3 | 7E09635003166350031600097F |
4 | 7E11635003166350031600117F |
5 | 7E09635003166350031600097F |
6 | 7E11635003166350031600117F |
7 | 7E11635003166350031600117F |
8 | 7E09635003166350031600097F |
9 | 7E11635003166350031600117F |
Darauf die Antworten in der capture-rx.txt, allerdings unsortiert zu den Requests. Ich konnte noch nicht beides parallel anschauen, da mir die USB-Schnittstellen ausgegangen sind:
1 | 7E8963500316635003160157000E0961138601CB005900AE117F |
2 | 7E9163500316635003160157000E0962138601C1005300AE0A7F |
3 | 7E88635003166350031600030000000000008B7F |
4 | 7E8963500316635003160158000E0962138601CB005900AE1D7F |
5 | 7E9263500316635003160003000000000000917F |
6 | 7E9163500316635003160157000E0962138601C1005300AF0B7F |
7 | 7E8963500316635003160158000F0962138601CB005900AF1D7F |
8 | 7E9163500316635003160157000E0962138601C1005300AF0B7F |
9 | 7E88635003166350031600030000000000008B7F |
10 | 7E8963500316635003160158000F0962138601CB005900AE1C7F |
11 | 7E9263500316635003160003000000000000917F |
12 | 7E9163500316635003160158000F0962138601C1005300AE047F |
13 | 7E88635003166350031600030000000000008B7F |
14 | 7E8963500316635003160159000F0963138601EF005900AD3B7F |
15 | 7E9263500316635003160003000000000000917F |
16 | 7E9163500316635003160159000F0963138601E4005300AD227F |
17 | 7E88635003166350031600030000000000008B7F |
18 | 7E8963500316635003160159000F0963138601EF005900AD3B7F |
19 | 7E9263500316635003160003000000000000917F |
20 | 7E9163500316635003160159000F0963138701E4005300AE207F |
21 | 7E88635003166350031600030000000000008B7F |
22 | 7E896350031663500316015900100963138701EF005900AE267F |
23 | |
24 | 7E896350031663500316014F00360960138806EB00A300DC917F |
63500316 ist meine WR-ID. Auch hier wird diese 2x hintereinander aufgeführt, jedoch nicht in umgekehrter Reihenfolge. Greife ich mir die letzten beiden Zeilen: 7E896350031663500316 0159 0010 0963 1387 01EF 00 5900 AE 26 7F früh Dezimal 345 16 2403 4999 495 174 7E896350031663500316 014F 0036 0960 1388 06EB 00 A300 DC 91 7F später Dezimal 335 54 2400 5000 1771 220 7E916350031663500316 0159 000F 0963 1387 01E4 00 5300 AE 20 7F früh Dezimal 345 15 2403 4999 484 174 7E916350031663500316 0155 0036 0960 1388 06EE 00 9B00 DC AE 7F später Dezimal 341 54 2400 5000 1774 220 DC V/10 | DC I/10 | AC V/10 | AC Frequenz/100 | AC Power/10 | ??? | Temperatur/10 | Daily Production/1000? Modul 1 und 2 jeweils identifiziert über die 89 und 91 am Anfang. 7E ist der Beginn der Übertragung, 7F das Ende. Eine CRC habe ich so nicht entdeckt, außer die vorletzten beiden Byte. Von Abends habe ich zu den 88 und 92 noch diese Infos: 7E88635003166350031600020000000000008A7F 7E9263500316635003160002000000000000907F Tagsüber: 7E88635003166350031600030000000000008B7F 7E9263500316635003160003000000000000917F die 02 bzw. 03 Tagsüber ist der Modulstatus. Diese Nummer taucht auch in der Cloud auf: Spekulation! - wird beobachtet 02 - MPPT inaktiv, Modul verbunden und arbeitet 03 - MPPT aktiv, Modul verbunden und arbeitet 05 - ? Modul liefert zu wenig Leistung 00 - Modul aus Ich habe den Netzwerkverkehr zwischen DTU und Server aufgefangen. Mobiler Hotspot und Wireshark, Datei raw.txt:
1 | a55600104291f008881173d510020001010116051c0910067800020a160350634110014f01350060098713bc069c009e0e0000d7000300000000000100000000000a160350634110025601340061098713bf0694008e0e0000d7000300000000000100000000001415
|
Hier haben wir meine DTU: 08881173d510 in umgekehrter Reihenfolge Datum und Uhrzeit YYMMDDhhmmss: 16051c091006 Die WR-ID: 16035063 in umgekehrter Reihenfolge DC- und AC-Daten, Produktion tägl. und gesamt sowie Modulstatus, Modulfehler-Zähler, Verbindungsstatus (Module?), Temperaturen. Die Zeile oben ist etwa im gleichen Zeitraum übertragen worden als ich die einzelnen Daten (Zeile "später") abgegriffen habe. Meine Freundin hat mir geholfen, ein kleines Python-Script zu schreiben, mit dem ich die Daten dekodieren kann. Das Script analyse.py ist sehr einfach gehalten, es erfüllt seinen Zweck, ist allerdings noch nicht auf dem Stand, dass man es groß braucht. Es analysiert nur die Daten, die an den Tsun-Server gehen. Hier passiert automatisch alle 15min eine Übertragung mit allen Daten seitens der DTU ohne vorher einen Request des Server, weiterhin jede Minute ein Request der DTU nach der Uhrzeit mit passender Antwort vom Server. Request: a500001047c62508881173d510020001013f15 Response: a50d001017c72508881173d510000201013f0016051c0a090878000100002715 Das dürfte zugleich eine Art Ping für den Server sein, dass die DTU noch online ist. In der DTU kann ich Server- und Port des Ziel ändern, außerdem die Kommunikationseinstellungen zum USR-C210. Da ich noch keinerlei Datentransfer durch die Luft gesehen habe, discover und pretender aus dem ahoy-Repo nichts finden, benötige ich hier etwas Starthilfe. Ich habe noch einen Wemos-D1 mini hier, den ich gerne mit entweder ahoy oder dem anderen Prog flashen würde. Könnte mir jemand eine Vorlage dafür machen oder erklären, wo ich was ändern muss? Bin mit Arduino noch nicht ganz warm. Vielen Dank für eure Hilfe :) lg Daniel M.
Daniel M. schrieb: > Guten Morgen zusammen,... Guten Morgen Daniel M. ! Super Arbeit von Dir und Deiner Freundin ! Endlich geht es mal mit den Protokollen weiter ! (Bits, Bytes und Status, ...)
Jan-Jonas, ich finde die von Bernd vorgeschlagene „Abfrage“ über Modbus TCP nicht so falsch. Speziell wenn wir jemand wie Arnaldo G oder Ziyat T. mit einer DTU Pro und Modbus Schnittstelle haben dann ist das doch die ideale Möglichkeit per Modbus „Kommandos“ an die WR zu stellen und parallel an den RX/TX Punkten das MCU/nRF Protokoll abzugreifen. Wenn wir also ein klares Testszenario per Modbus vorgeben könnten, wäre uns allen doch geholfen da wir dann auch die gwünschten Testdaten bekämen. Was wäre denn per Modbus möglich und nötig ? * Werte aller Art abfragen * WR auf X% Leistung limitieren * WR wieder unlimitiert betreiben etc. Wenn wir die Anforderungen an das Testszenario schon mal definieren und ein klares Testprogramm für Modbus haben dann klappt es vielleicht auch schneller die gesuchten Daten zu bekommen.
Moin zusammen, @ Daniel M: Super Arbeit! Hast du zufällig vom Mitschnitt ein *.pcap File? Ich gehe hier jetzt noch davon aus, wie du oben beshrieben hast, das es sich um ein "TSUN" handelt? Daniel M. schrieb: > Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein. Konntest du hier mit einem Multimeter das nachprüfen auf einen Durchgang? Wenn es kein GND Verbindung hat, wäre es Interessant füher oder später auch zu wissen wo dieser hinführt. :) Die Frage die sich mir noch stellt (spez. an Arnaldo G & Ziyat T.), besitzt Ihr zufällig auch ein DTSU666? - Dann hätte man nähmlich ein kompletten Aufbau von einer 0-Einspeisung System. Dann wäre es ja noch einfacher alles weiter zu Analysieren. Jedoch gehe ich hier mal davon aus das ein DTSU666 noch fehlt? Gruß Daniel
Kleiner Nachtrag:
weiteres Decoding der einzelnen Werte wie folgt:
7E 89 63500316 63500316 014A 002D 0962 1383 04A2 0269 0123 FB 7F
330 40 2402 4995 1186 617 291 251
DCV DCI ACV ACF ACP DProd. Temp.
7E 91 63500316 63500316 014E 0026 0961 1383 049D 0261 0122 D9 7F
334 38 2401 4995 1181 609 290 217
DCV=DC Voltage /10
DCI=DC Strom /10
ACV=AC Voltage /10
ACF=AC Frequenz /100
ACP=AC Leistung /10
DProd.= tägliche Produktion /1000
Temp.=Temperatur /10
Die letzten Werte sind Fragezeichen, könnte CRC sein, weiß ich aber
nicht.
Die Daten an den Server zusammen mit fast passender Abfrage der
DTU-Daten:
7E 89 63500316 63500316 014D 002E 095A 1386 05A6 02C7 0126 6C 7F
333 46 2394 4998 1446 711 294 108
7E 91 63500316 63500316 0151 002B 095A 1386 059D 02BE 0126 2F 7F
337 43 2394 4998 1437 702 294 47
-
a55600104254b308881173d510020001010116051c0c1f097800020a160350634110014d
012b0059098613a605c702c910000025010300000000000100000000000a160350634110
0251012b00590986139d05be02b810000025010300000000000100000000009a15
DTU id: 08881173d510
WR id: 160350634110
Datum: 28 . 5 . 22 | Zeit: 12 : 31 : 9
Panel: 1
DC Volt: 33.3 V | DC Amp: 4.3 A | AC Volt: 239.3 | Temperatur: 3.7
C | A02 01 1
AC Freq: 49.98 Hz | AC Power: 144.6 W | P today: 0.711 kWh | P total:
4.297 MWh
Modulstatus: 3 | Anz. Modulfehler: 0 | Connectionstatus: 1
-
Panel: 2
DC Volt: 33.7 V | DC Amp: 4.3 A | AC Volt: 239.3 | Temperatur: 3.7
C | A02 01 1
AC Freq: 49.98 Hz | AC Power: 143.7 W | P today: 0.702 kWh | P total:
4.28 MWh
Modulstatus: 3 | Anz. Modulfehler: 0 | Connectionstatus: 1
Die Temperatur funktioniert offenbar nicht mehr, warum auch immer. Der
Rest der Daten kommt jedoch hin. Das schwächere Modul 2 liegt leider
unterhalb des Dachfirst, der zu gerne von Vögeln als Toilette benutzt
wird, daher ist auch, denke ich, recht gut erkennbar, wie die Zuordnung
ist:
89 ist Panel 1, 91 ist Panel 2
lg
Daniel M.
Edit: Am Anfang ist eine Zeile zu den Werten verrutscht.
:
Bearbeitet durch User
Daniel R. schrieb: > @ Daniel M: Super Arbeit! Hast du zufällig vom Mitschnitt ein *.pcap > File? > Ich gehe hier jetzt noch davon aus, wie du oben beshrieben hast, das es > sich um ein "TSUN" handelt? Hi, hängt hier dran :) Ja, ist ein TSUN TSOL-M800 mit 2 MPPT-Trackern. > Daniel M. schrieb: >> Was der 3. Tastpunkt macht, weiß ich nicht, könnte ein GND sein. > > Konntest du hier mit einem Multimeter das nachprüfen auf einen > Durchgang? > Wenn es kein GND Verbindung hat, wäre es Interessant füher oder später > auch zu wissen wo dieser hinführt. :) Der Tastpunkt ist 3,3V. Mit dem Durchgangsprüfer hatte ich Verbindung nach VDD, VSS und GND. Maximale Verwirrung. lg Daniel M.
Servus, die Verdrahtung für https://github.com/grindylow/ahoy geht immer(?) von einem ESP8266 "Wemos D1mini" aus. Daran mangelt es mir gerade. Doch habe ich noch paar AZDelivery ESP8266 "NodeMCU v3" herumliegen ... weiss jmd von Euch aus dem Stehgreif, ob die PIN-Bezeichnungen bei beiden identisch ist? Muss ich sonst im Source die Pins anpassen? Merci, BastelBarney
Maik R. schrieb: > Muss ich sonst im Source die Pins anpassen? Wemos hat die Dx-Bezeichnungen Nichts im Code ändern, einfach passend anlöten - die GPIO-Bezeichnungen sind die gleichen https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/
Heinz R. schrieb: > Wemos hat die Dx-Bezeichnungen > Nichts im Code ändern, einfach passend anlöten [...] > https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/ Dankeschön! Und guter Link, sehr schnell überblickbar dort.
Hallo Bastel Barney, habe auch eine NodeMCU und die selben PINs wie am Wemos verwendet. Wenn ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und Raspberry Pi hochladen.
Moin Ahoy, ich glaube das es Sinnvoll ist. Damit andere User am Projekt mitwirken wollen, aber nicht das technische "know-how" haben dennoch mitwirken können. :) Fritzing ist ja denke ich schnell gemacht.
:
Bearbeitet durch User
Hallo Ich habe, wie schon früher gemeldet: -DTU-Pro -DTSU666 -MI1500 -Raspi+python(pymodbus+mqtt+nodered) ausser WR alle mit Modbus verbunden um den zero export zu realisieren, DTU-Pro+MI-Series kann den zero export nicht wirklich. Da ich einen MI1500 habe kann ich euch nicht helfen, da die MI-Serie völlig anders funktioniert: - RF Protokoll komplett anders - Modbus auf Port/WR Ebene schwach implementiert Ich werde aber bald einen HM1500 bekommen, dann kann ich weiter
:
Bearbeitet durch User
Hallo, suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem Link dazu helfen .... den neuesten Code bekomme ich mit der Arduino IDE nicht kompiliert warum auch immer .' im Moment benutze ich die Version 0.4.4 mit einem HM1500, funktioniert gut Danke !!! Vielen Dank im voraus misch
Guten Abend, anbei die neusete Version. Danke an @Jan-Jonas, diese Version hat jetzt auch den Retransmit des letzten Pakets, sobald bekannt ist welches das letzte Paket ist. Ich hoffe die Stabilität konnte weiter verbessert werden und stellt einigermaßen zufrieden. Durch den last-Paket-Retransmit kommen bei mir deutlich mehr komplette Payloads zustande (mit einem 5s Interval). Aktuell funke ich durch 3 Betondecken vom Keller aufs Dach. Edit 22:20: 0.4.12 mit Boot-Loop fix Wir haben 1000 Beiträge =) Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =)
:
Bearbeitet durch User
Misch O. schrieb: > suche die neueste ESP8266.bin zum runterladen, kann mir jemand mit einem > Link dazu helfen Hier die brandaktuelle 0.4.11 kompiliert für den Wemos D1 mini
leider nicht mehr brandaktuell, es gibt schon die 0.4.13.
Lukas P. schrieb: > Edit 22:47: 0.4.13 mit funktionierendem Boot-Loop fix =) oh, mein Artikel kam zu spät, lumapu ist so schnell am committen, ich komme mit dem kompilieren nicht nach ;-)
Moin zusammen, nach der Arbeit schaue ich mir mal den Code und alles an. :) Ich nutzte aktuell VS Studio und aktuell für den Arduino, die eigene IDE. VSCode läuft bei mir irgendwie nicht rund. Oder kennt jemand ne gute Anlauf stelle um mit VS Studio direkt zu compilieren? - Bitte keine "nutz Google" Antworten. Aktuell habe ich das gefunden: https://marketplace.visualstudio.com/items?itemName=VisualMicro.ArduinoIDEforVisualStudio Was nutzt ihr denn? Vielen Dank und den neuen Code teste ich sobald ich heute wieder Zuhause bin. :) 1003 Einträge, Mensch haben wir ein neuen Rekord aufgestellt? :D
:
Bearbeitet durch User
Einen Link dazu kenne ich auch nicht. Bei mir klappt es mit der Arduino IDE 1.8.19 und - aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4) sowie den LIBRARIES - Time 1.6.1 - RF24 1.4.2 - PubSubClient 2.8 ohne Probleme. Gruß Günter
Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht. Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut werden kann? Hardware hätte ich alles schon da: Raspberry Pi, nRF24, ESP8266, Arduino-Nano. LG, Pocki
Hallo Christian P., leider gibt es noch keine klare Information zu den älteren MI-Modellen von Hoymiles. Es gab bereits einige Foristen mit einem MI- Wechselrichter, u.a. Ziyat T. mit einem MI-1500, Arnaldo G. mit zwei MI-1500 und Daniel B. mit einem MI-600, Daniel M. mit einem TSUN TSOL-M800 vermutlich ein re-brandeter MI-800 und jetzt Du mit einem MI-300. Leider haben wir bisher relativ wenig Informationen über das ältere MI-Protokoll. Ziyat. T. hat mal eine Auswertung in Excel als Screenshot MI1500data.png und DTUPro.log angehängt und Arnaldo G. hatte sehr zu Beginn dieses Threads seine nrf24.txt und nrf24_2.txt Ergebnisse vom mitsniffen ihrer DTU Pro bekannt gegeben. Vielleicht wollt Ihr auch mal ein Issue auf github aufmachen um den aktuellen Wissensstand zur MI-Serie zusammenzutragen. Da könnte dann z.B. Ziyat noch mal erklären wie er zu den Ergebnissen bei seiner Auswertung gekommen ist. M.E. sah das was die Spannung und sonstigen Werte angeht schon sehr vielversprechend aus ... Das fehlende Glied sind die Aufforderungen zum Tanz die die DTU-Pro den MI-Wechselrichter schickt. Hier müsste man am besten und einfachsten an den RX/TX Testpunkten in der DTUPro den Verkehr mit einem Logic Analyzer mitschneiden. Anleitung für eine DTU-Lite hatte martin (Gast) hier bereits geliefert: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Du kannst auch einfach nochmal auf der Single Page Ansicht nach "MI-", "MI1500", "Salea" etc. suchen. Ziyat & Arnaldo, do you have an Logic Analyzer at hand or would you get one for a dozen bucks to make those traces ? I have given you a short summary for the Software Decoding / Analysis under Linux in a recent post, where I documented my approach to successfully decode the files DTU_Captures.zip from martin: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
@Ziyat & Arnaldo, I believe Sigrok / Pulseview may be even able to read raw data from Raspberry Pis GPIO pins, just in case you do not have a Logic Analyzer at hand. Read here for two projects with the same goal and helpful input on how to best secure the GPIO Pins against overvoltage / current. https://github.com/superzerg/logic-analyzer https://github.com/richardghirst/Panalyzer
Christian P. schrieb: > Ich habe einen MI-300 und der antwortet auch die Skripte leider nicht. > Wie kann ich beitragen, damit die Kommunikation damit auch aufgebaut > werden kann? Hallo Christian P. und @isnoAhoy Bisher funktionieren alle SW-Versionen nur mit der HM-Serie, MI-Serie werden (imho) nicht unterstützt. Meine Motivation um den MI zu analysieren (zur Zeit) ziemlich klein geworden: - Hoylimoly hat die Produktion der MI's abgestellt - Die MI's als 2.gen haben wenige Funktionen, vor allem man kann sie nicht unter 10% limitieren, das passt mir überhaupt nicht (zero import? wenn kein load) - MI-Ports können nicht einzeln limitiert oder ein/ausgeschaltet werden Ich habe bisher durch meine DTU-Pro Hilfe (wenn sie eingeschaltet ist konnte ich die WR-RF-Messages mitlesen) alle Werte in MI-Messages entschlüsseln, den MI konnte nicht ansprechen, bisher das ist alles. Ich werde weiter machen wenn ich den HM bekomme, sorry.
Ja, ist nachvollziehbar. Die MI Serie ist schwierig zu knacken. Ich habe mich soweit durch die 1000+ Postings gearbeitet, speziell die Logfiles nrf24.txt bis hin zu nrf24_5.txt und weitere. Scheint als fehle noch das initiale Aktivierungskommando der DTU. Schon versucht, die DTU abzustecken, abzuwarten bis die Inverter verstummen und dann beim Wiedereinschalten der DTU dessen Init-Kommando zu erwischen? Eventuell ist genau der setTime-Command der Key? Ich kämpfe noch, um Raspi, nrf24-modul, esp8266, nano und die Software zum Laufen zu bringen. Hoffe ich habe das bald bei'nander.
Hallo Lukas P. warum ist in hmRadio.h eigentlich Kanal 40 nicht als Receive Channel mit angegeben ?
1 | #define RX_CHANNELS 5 |
2 | ... |
3 | // Depending on the program, the module can work on 2403, 2423, 2440, 2461 or 2475MHz. |
4 | // Channel List 2403, 2423, 2440, 2461, 2475MHz |
5 | mRxChLst[0] = 03; |
6 | mRxChLst[1] = 23; |
7 | mRxChLst[2] = 40; |
8 | mRxChLst[3] = 61; |
9 | mRxChLst[4] = 75; |
10 | ... |
11 | uint8_t getRxNxtChannel(void) {
|
12 | if(++mRxChIdx >= RX_CHANNELS) |
13 | ... |
14 | uint8_t mRxChLst[RX_CHANNELS]; |
würde das um den Kanal 40 erweitern. laut FCC Dokumentation soll das nRF Modul ja auf allen fünf Kanälen funktionieren. @Christian P., Ziyat T., etc. mit der o.g. Erweiterung könnte man ggf. auch seine DTU als "Dummy"-Wechselrichter eintragen, also DTU Serien Nummer stattdessen mit führender 1121, 1141 oder 1161 eingeben. Er würde dann zwar auch versuchen der DTU die bekannten Status/setTime-Kommandos zu schicken, aber gleichzeitig müsste er auch alles was von der DTU kommt als Received bytes channel XX im Serial Monitor ausgeben.
Ich selbst habe leider keine DTU, und plane auch nicht eine zu kaufen. Ich fürchte es wird nötig sein, dass ein DTU-User einen MI-WR aus seinem Setup entfernt (de-registriert) und neu einrichtet/registriert. Und am besten BEIDES mitschneiden :-)
:
Bearbeitet durch User
Die Benutzeranleitung der DTU-Pro App erwähnt eine Funktion zur automatischen Erkennung naher Microinverter: https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf Seite 16: >3. You can add microinverter via “Automatic Search” or typing in... >4. The search result of microinverters and microinverter added will be displayed Die Screenshots wurden mit Inverter-Seriennummern 1121xxxxxxxx gemacht, also vermutlich MI-Serie. Könnte jemand mit einer DTU und dieser App das mal ausprobieren und ggf. den nrf24-Traffic versuchen einzufangen?
Hi Pocki, ui das klingt ja mal Interessant. Wenn es tatsächlich klappen sollte, könnte man das als Feature mit einbauen um einfacher die WR zu hinterlegen. Sehr cool, glaub ich sollte auch mal das ganze Handbuch studieren. 😅
Wenn Ihr schon mit solchen guten Vorschlaegen kommt, bitte liest Ihr das HB (https://www.hoymiles.com/wp-content/uploads/2021/11/User-Manual_DTU-Pro-S_Global_EN_V202111.pdf ) nochmals schön durch:-) Es handelt sich um DTU-Pro-S Microinverter Compatibility Microinverter model HMS series, HMT series
Hm, stimmt allerdings. Ich erinnere mich Ende 2020 an ein Handbuch mit Screenshots zur DTUlite von schlecht designten HTML-Seiten zur Einrichtung der WR. Und da gab es auch einen "search"-Button. Und das war zu Zeiten bevor es die HM-Serie gab.
:
Bearbeitet durch User
Hallo martin (Gast) & Christian P., das sieht in der Tat interessant aus. Die Funktion scheint es auch in der DTU-Lite-S zu geben. Ich weiß natürlich nicht ob es das nur in der -S Version und/oder auch in der WLite Version gibt ? User Manual_DTU-Lite-S_Global_EN_V202202 https://www.hoymiles.com/wp-content/uploads/2022/03/User-Manual_DTU-Lite-S_Global_EN_V202202.pdf > 3. You can click "Automatic Search" to add microinverter, > or you can type in / scan the microinverter ID. @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic Analyzer ausprobieren und mitschneiden ?
Mal eine blöde Frage zwischendurch: Wenn ich versuche aus der Arduino-IDE meinen Wemos D1 Mini zu flashen, rennt er in eine Boot-Loop und kommt nicht. Ich möchte nicht ausschließen, dass ich falsche Einstellungen habe, kann mir jemand die richtigen geben? Auch könnte der Flash mittlerweile hinüber sein, was ich auch nicht ausschließen kann. Ich nutze aktuell Arduino 1.8.19 und habe es mit der ahoy-Version 0.4.13 von Github probiert. Mit etwas Überzeugungshilfe habe ich esptool 3.3 dann dazu bekommen, das bin-file direkt zu flashen und es klappte nach einigen Schwierigkeiten. Danach wäre ein kurzer Exkurs in das Programm interessant, an welchen Stellen die Adressen und Befehle zusammengebaut werden. Würde mich da mal mit den Anpassungen auf den TSUN beschäftigen und schauen, was ich mit meiner Unkenntniss hinbekomme. Dankeschön :) Edit: ein neuer Git Pull hat geholfen, habe noch eine Vorversion mit dem Bug drin gehabt. Die Einstellungen mal vergleichen wäre trotzdem Hilfreich.
:
Bearbeitet durch User
isnoAhoy schrieb: > @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic > Analyzer ausprobieren und mitschneiden ? Ja, das kann ich heute Abend oder morgen Nachmittag mal testen.
martin schrieb: > isnoAhoy schrieb: >> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic >> Analyzer ausprobieren und mitschneiden ? > > Ja, das kann ich heute Abend oder morgen Nachmittag mal testen. Das wäre ganz super :-) Ich habe inzwischen mein Klump zusammen und kann gleichzeitig nrf24 sniffen (noise wird über crc-check verworfen) und auch custom-payloads senden :-) Sobald ich also einen Anhaltspunkt bekomme, an welche Destination-Adresse mit welchem Payload man Pakete senden könnte, kann ich starten.
Ich habe von meinem MI-300 nun geschafft Antworten zu empfangen, wenngleich auch noch keine nutzbaren Daten: Anfrage via nrf24 (on-air):
1 | Address 1319406101 Data 15 77665544 88776655 81 58 |
2 | WR-rev mid DTU dummy cmd crc |
Antwort vom WR (on-air):
1 | Address 4455667701 Data 15 77665544 61401913 81 bf |
2 | DTU-rev mid DTU WR cmd crc |
Nach ein bisserl Herumspielen stelle ich fest: 1) Der WR antwortet an die Adresse, welche in der Anfrage-Payload bytes 2,3,4,5 steht, reversed und mit 0x01 ergänzt. hier also 77665544 liefert die WR-Antwort an die Adresse 4455667701 2) Die Felder WR und DTU sind somit vertauscht (hinter dem MID): zuerst kommt die DTU (an welche der WR seine Antwort senden soll), und dann der WR. 3) Die Länge der Antwort ist immer gleich lange wie die Länge der Anfrage. Keine der bekannten Anfragen (MID 0x07, 0x15 und CMDs 0x00, 0x80 bis 0x83) liefern brauchbare Payload retour: es kommt immer nur genau das zurück, was in der Anfrage gesendet wurde. Einziger Unterschied ist die S/N des WR (bei mir 61401913) und dann natürlich die 8bit payload-crc. So, und was nun? :-) Ideen willkommen
:
Bearbeitet durch User
Hmm, interessant... Ich hätte die Idee das man die MID inkrementiert und darauf lauscht. 0x00 bis 0xFF sind 255 steps. Wie lang dauert das Senden + Empfangen + Delay? 1sek.? Dann hätte man nach 255sek. wenigsten die Info ob bei allen MIDs die gleiche Antwort zurück kommt. Oder was meint ihr?
Ok, rennt schon. Leider nicht so simpel, weil der WR nicht bei jeder Sendung antwortet. Ich vermute, das liegt am Channelhopping des WR: der scannt umher auf den Kanälen. Ich sende und sniffe aber nur Channel 0x03, daher kann es sein, dass ich ein Paket 5-10x senden muss, um eine Antwort zu bekommen. Ein erster Durchlauf bestätigt das. Was ich schon mal sagen kann: Pakete mit MID größer als 0x80 werden nicht beantwortet. Auch MID=0x00 bleibt stumm. Ich lasse mal laufen für MID=0x00-0xFF und CMD=0x00-0xFF folgende Payloads jeweils 4x mit 15 retransmissions :-)
1 | MID+ dtu + wr +CMD+crc |
2 | zb 07 77665544 61401913 81 aa |
Werde berichten... Hoffentlich zerschiesse ich mir den WR damit nicht
Hmm, soviele retransmissions macht doch kein Sinn? Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu schalten, damit man mehrere Kanäle sich anhört. Apropo Channel hopping, irgendwo muss doch eine Komunikation stattfinden das beide, WR + DTU, im selben Channel zuhören/reden. Oder? Gerade gefunden: https://hackaday.com/2017/03/21/ask-hackaday-frequency-hopping-on-the-nrf24l01/ https://paulplusx.wordpress.com/2017/03/19/frequency-hopping-with-nrf24l01/
:
Bearbeitet durch User
Daniel R. schrieb: > Hmm, soviele retransmissions macht doch kein Sinn? > > Stoppe das ganze mal. Hast du noch paar NRF? Die könnte man dann dazu > schalten, damit man mehrere Kanäle sich anhört. Ich habe 2 NRF-Module: eines am GPIO eines Raspberry zum Versenden und eines an einem Arduino-Nano zum Sniffen. Der liefert via serial an den gleichen Raspi ab, wo ich dann auf die Empfängeradresse filtere. Die 15 Retramsmissions alle 250µs sind im Python-Initscript fix drinnen, habe es nicht geschafft das zu reduzieren. Die macht er, weil der WR ja kein ACK sendet. Das 4x-Senden in 500ms Abständen loope ich bewusst, damit ich sicher gehen kann, dass es der WR auch gehört hat und nicht antworten will. Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch. Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen, also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende. Hoffe nur wir können dann etwas beobachten.
Alles klar, danke für die Arbeit. Wichtig natührlich alles fleißig zu loggen... :D
Ich bin noch skeptisch, ob uns das weiterbringt. Bis jetzt habe ich ausnahmslos nur "gespiegelte" Antworten gesehen, also egal welcher MID oder CMD: es kam immer genau die selbe Nachricht retour, nur mit der anderen Seriennummer. Sonst: gleicher Inhalt, gleiche Länge. Kann also sein, dass wir ohne Kenntniss des *echten Einrichtungs-Dialogs* zwischen einer DTU und einem MI-WR nicht weiterkommen.
Christian P. schrieb: >> isnoAhoy schrieb: >>> @martin (Gast) könntest Du den ersten Halbsatz nochmals mit Deinem Logic >>> Analyzer ausprobieren und mitschneiden ? >> >> Ja, das kann ich heute Abend oder morgen Nachmittag mal testen. Hallo, ich konnte zwischenzeitlich mal ein paar Captures aufnehmen. In Capture0 und 1 habe ich mich per App mit der DTU verbunden (die baut ja ihr eigenes WLAN auf) und dann auf "Inverter Hinzufügen und Automatische Suche" geklickt. In Capture2 habe ich mal die Echtzeitdatenabfrage laufen lassen (Zeigt die Istwerte auf dem Inverter). Habe heute leider keine Zeit mehr, die Daten aufzubereiten, daher die Rohausgabe als .txt und die Logic-Captures direkt mit im Anhang, für eure eigenen Analysen (Saleae Logic-Software kann man kostenlos runterladen und die Captures öffnen). Zur Info nochmal: Inverter 1141 72220200 DTU Lite 10D9 72818832
Danke, mir fällt insbesonders alles ausser mid=15 und =95 auf auf: capture_1.txt 7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 0a,8d,7f 7e,81,72,81,88,32,72,81,88,32,00,81,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,81,72,81,88,32,72,81,88,32,01,80,7f 7e,06,72,22,02,00,72,22,02,00,00,06,7f 7e,06,72,22,02,00,72,22,02,00,00,06,7f 7e,01,72,81,88,32,72,81,88,32,00,01,7f 7e,01,72,81,88,32,72,81,88,32,01,00,7f 7e,02,72,22,02,00,72,22,02,00,00,02,7f Verstehe ich das korrekt: das sind die Daten von "on-wire" zwischen dem Onboard-Chip und dem NRF24-Modul der DTU? Weil: leider kann man da nicht klar herauslesen, an selche destination-address das nrf24-paket dann geschickt wird. Oder?
Christian P. schrieb: > das sind die Daten von "on-wire" zwischen dem > Onboard-Chip und dem NRF24-Modul der DTU? Ja genau, auf der UART zwischen GD32 und NRF24. Um die Richtung zu erkennen habe ich die Saleae-Files mit hochgeladen. Dort kann man anhand des Kanals erkennen, ob es der DTU-Controller an den NRF schickt (sprich: die DTU an den Inverter) oder ob es vom Inverter zurückkommt.
Christian P. schrieb: > Daniel R. schrieb: ..... > Halb so schlimm: alle 255 MIDs und 255 CMDs sind in 45h durch. > Eigentlich ja nur 128 MIDs, weil ja ab 0x80 nichts mehr kam beim Testen, > also doch nur die halbe Zeit. Ich lass ich halt laufen übers Wochenende. > Hoffe nur wir können dann etwas beobachten. Habe schon vor 2 Monaten ausprobiert, bei mir kam nichts... Ich habe mehrere logs vom MI1500 hier veröffentlicht
Christian P., ja die Salea Captures haben noch en 0x7e Prefix und Postfix 0x7f vor/nach den uns sonst geläufigen Nachrichten / Paketen. 7e,86,72,22,02,00,72,22,02,00,02,11,41,72,22,02,00,00,b0,00,00,00,b0,01, 0a,8d,7f ist also eigentlich MID=0x86 Destination=72220200 Source/DTU=72220200 Paket/CMD=0x02 Payload=11,41,72,22,02,00,00,b0,00,00,00,b0,01,0a CRC8=0x8d Ich sehe da also zwei Addressen: * 72220200 * 72818832 Vielleicht sind die im capture1.txt genannten Adressen ja so eine Art Broadcast Adresse für die jeweiligen Modellreihen ? Interessant dürften für die MI Wechselrichter in der Tat die MIDs außer 0x15 und 0x95 der HM Baureihen sein: Speziell 0xc2 und 0x06 stechen mir ins Auge, ich meine so etwas auch in Ziyat T. bzw. Arnaldos Logfiles bereits gesehen zu haben.
Hallo martin (Gast), Danke für die Aufnahmen! Hast Du die Aufnahmen während des Tages gemacht, d.h. dabei war ein WR anwesend und hat geantwortet. Interessant wäre ja auch das Verhalten der DTU in einer abgeschirmten Umgebung. Hier sollte die DTU ja prinzipiell einmal alle Discovery Optionen ausspielen, die ggf. auch eine MI-Wechselrichter interessieren könnten. In der Payload steht ja eine HM-600/700/800 Serien Nummer: 114172220200 Damit hat die DTU wohl einen jungen Fisch gefangen ?
Noch eine (Broadcast) Adresse 10,d9,42,7f ? grep '^7e' capture0.txt | less /(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83) bzw. grep '^7e' capture0.txt | grep -v '72,22,02,00' | less /(72,81,88,32|72,22,02,00|11,41|15|95|10,d9,42,7f|01|02|83) um den ganzen Smalltalk mit 114172220200 auszufiltern ergibt: 7e,81,72,81,88,32,72,81,88,32,00,81,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,c2,72,81,88,32,10,d9,42,7f 7e,81,72,81,88,32,72,81,88,32,01,80,7f 7e,01,72,81,88,32,72,81,88,32,00,01,7f 7e,01,72,81,88,32,72,81,88,32,01,00,7f
Hallo im Anhang sind die wireshark logs zwischen DTU-Pro und MI1500 mit versch. channels. Hatte sie mit NRF24_Sniff von Ivo Pullens generiert. Adr:1284..DTU, 6071..MI, Adr sind verkehrt! z.Bsp: im NRF24_Sniff die DTU Adresse eingegeben, auf CH3, das ist die Antwort vom WR, ist von mir entschlüsselt, siehe früheren Beitrag: ch3-2-12842272.pcapng b6:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 05:05:b1 b8:63:70:71:60:63:70:71:60:01:bb:00:0c:09:86:13:87:02:23:01:da:01:16:03: 00:01:fa b7:63:70:71:60:63:70:71:60:00:0d:00:00:09:85:13:87:00:00:00:00:01:16:05: 05:05:b0 b9:63:70:71:60:63:70:71:60:01:bb:00:06:09:85:13:87:01:2b:01:3f:01:16:03: 00:01:1c im NRF24_Sniff die WR Adresse eingegeben, auf CH23: ch23-60717063.pcapng 51:63:70:71:60:72:22:84:12:5a:5a:1a:8f 51:63:70:71:60:72:22:84:12:5a:5a:1a:8f 51:63:70:71:60:72:22:84:12:5a:5a:0b:9e 36:63:70:71:60:72:22:84:12:00:f2 37:63:70:71:60:72:22:84:12:00:f3 38:63:70:71:60:72:22:84:12:00:fc 39:63:70:71:60:72:22:84:12:00:fd Villeicht hilfts euch weiter.
:
Bearbeitet durch User
Ich habe heute mal die c2 und 81 er Payloads bei mir in die Luft geworfen und von meinem HM600 keine Reaktion bekommen. Die Frage ist natürlich, ob die Dinge wirklich on-air gehen oder nur setup-commands an das NRF-Modul sind? Christian P. schrieb: > MID+ dtu + wr +CMD+crc > zb 07 77665544 61401913 81 aa Damit hast Du ja nur ein Re-Transmit angefordert(?). So einfach ist das nicht mit durch iterieren, weil viele Anfragen einfach eine definierte payload mit Parametern erwarten. Interessant ist eigentlich nach jedem Kommando mal ein 80 11 abzufragen (event log). Das wird bestimmt überlaufen mit a_code=2, was ich denke wird soviel sagen wie Software-Fehler, Parameter-Fehler oder Kommunikationsfehler (Spekulation) Leider scheint im Dump auch die Anfrage auf die Antwort mit der Seriennummer zu fehlen.
:
Bearbeitet durch User
Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das Shockburst-Frame des nrf24-Protololls gesendet wird? Wenn die Daten ein Dump aus der internen DTU-Schnittstelle zum nrf24-Modul sind, zeigen die ja nur (?) den Payload oder? Oder steuert das erste Feld (MID) das Verhalten des nrf24 hinsichtlich Destination-Adresse/Adresslänge/ShockburstOnOff? Hat sonst noch jemand captures von on-air Daten?
Hallo Hubi(Gast)
Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme
aber beim kompilieren folgende Fehlermeldung:
In file included from
/home/papalapap/Arduino/HoyDtuSim/HoyDtuSim.ino:86:
/home/papalapap/Arduino/HoyDtuSim/ModWebserver.h: In function 'void
handleRoot()':
ModWebserver.h:55:33: error: 'getSerialNoTxt' was not declared in this
scope
55 | out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";
| ^~~~~~~~~~~~~~
exit status 1
'getSerialNoTxt' was not declared in this scope
Vielleicht sagt dir die Fehlermeldung in der ModWebserver.h etwas.
Wünsche frohe Pfingsten
Arduino: 1.8.19 (Linux), Board: "LOLIN(WEMOS) D1 R2 & mini, 160 MHz,
Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most
compatible), 32KB cache + 32KB IRAM (balanced), Use pgm_read macros for
IRAM/PROGMEM, 4MB (FS:1MB OTA:~1019KB), v2 Lower Memory, Serial, None,
All Flash Contents, 921600"
DTU-Pro <-> MI1500 logs WR -> DTU ---------- len } 2a: hdr } 2c:67:b7:0f:00:63:70:71:60: 63:70:71:60: data} 01:b2:00:0f:09:22:13:89:02:77:01:02:01:b7:03:00:03:74:48:9e:3e:aa:77:de: ab:ec:b6:a6:40: U DC I DC U AC Hz AC P DC C 1 b2 0 0f 9 22 13 89 2 77 1 2 1 b7 DTU -> WR --------- 16: d4:cf:21:0f:00:63:70:71:60: 72:22:84:12:5a:5a:1b:8e:ee:12:3d:b6:08
Christian P. schrieb: > Wie kann man an diesen Daten erkennen, an welche Destination-Adresse das > Shockburst-Frame des nrf24-Protololls gesendet wird? Die Richtung kann man nicht erkennen. Aus beobachtungen weiß ich bisher, dass 0x15 dtu->wr und 0x95 die Antwort vom wr ist. Oder man kennt die Adressen seiner Geräte. 7e,7f markiert start und ende der spi-kommunikation in der dtu. Das geht nicht on-air. 0xc2 und 0x81 sind neu für mich und enthalten z.T. keinen gewöhnlichen ESB-Aufbau. Vermutlich könnte es also sein, dass die dtu da den nrf-chip konfiguriert oder status register abfragt. (Spekulation) Könnte aber auch genauso gut sein, dass 0xc2 Übertragungsart ist, broadcast vs. 0x15 unicast?
ich habe meinen HM-400 heute endlich in Betrieb nehmen können. Der WR läuft und produziert auch,aber ich bekomme mit meinem WemosD1 und dem NRF Modul leider keinerlei Rückemeldungen vom WR. Uptime: 0 Tage, 00:54:20 Time: 2022-06-05 14:09:30 Statistics: Receive success: 0 Receive fail: 652 Send Cnt: 1304 Free Heap: 0x98c8 Inverter 'HM-400' is not available and is not producing MQTT: connected Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu haben. im seriellen log steht folgendes: Free heap: 0x9fb0 Inverter #0 no Payload received! Requesting Inverter SN 1121xxxxxxxx Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 05 00 00 00 00 B0 39 B9 Error while retrieving data: last frame missing: Request Retransmit Transmit 27 | 15 80 13 52 94 78 56 34 12 80 0B 00 62 9C B9 B1 00 00 00 05 00 00 00 00 B0 39 B9 Free heap: 0x9fb0 Inverter #0 no Payload received! Requesting Inverter SN 1121xxxxxxxx Version nutze ich die aktuelle 0.4.15
Hast Du einen Kondensator an VCC vom NRF-Modul? Wichtig. Manchmal hilft, die Sendeleistung von der "DTU" zu ändern. Habe das schon gehabt, dass WR nicht antworten, wenn man die zu laut fragt. Auch die Ausrichtung der Antenne kann Wunder wirken.
ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe ich auch alle low, min, high und max probiert. genauso wie die entfernung zwischen paar cm und einigen metern geändert wurde
Mehr DTU-Pro <-> MI1500 logs Diesmal WR ist stumm, weil Nacht, DTU-Pro neu gestartet
Tobi D. schrieb: > Seriennummer habe ich im Setup ganz normal eingetragen,oder muss man die > Rückwärts eintragen, glaube sowas irgendwo mal im Beitrag gelesen zu > haben. Seriennummer muss so eingetragen werden, wie sie auf dem Aufkleber zu lesen ist. Hast du mal mit der Ausrichtung der Antenne gespielt? Stimmt dein Pinout, vor allem der IRQ Pin darf nicht auf GPIO16 liegen?
Friedhelm E. schrieb: > Ich habe deine Software HoyDtuSim wie angegeben installiert, bekomme > aber beim kompilieren folgende Fehlermeldung: > In file included from Hallo Friedhelm hol dir die neueste Version von [[https://github.com/hm-soft/Hoymiles-DTU-Simulation]], das sollte klappen
Tobi D. schrieb: > ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe > ich auch alle low, min, high und max probiert. Viele der NRF-Module haben geclonte Chips, manche funktionieren besser, manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne auf der Platine bestellt, die funktionieren problemlos. rosch99
Der Tip mit den Modulen mit Antenne, die irgendwie nicht so ganz laufen, war gut. Ardunio-Konsole:
1 | 14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB |
2 | 14:37:10.670 -> Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 4A 00 10 09 59 13 87 02 0C 03 59 00 F1 AB |
3 | 14:40:00.684 -> Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 4A 00 11 09 5F 13 85 02 2D 03 61 00 F2 AC |
4 | 14:42:57.596 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4 |
5 | 14:42:57.644 -> Received 24 bytes channel 23: 89 63 50 03 16 63 50 03 16 01 4A 00 13 09 5C 13 88 02 5C 03 64 00 F2 D4 |
Hauptsächlich jedoch kommt diese Meldung:
1 | 14:43:00.590 -> Error while retrieving data: last frame missing: Request Retransmit |
Das passiert fast immer, wenn vom WR eine Antwort eingeht. Raspi mit ahoy python-tool:
1 | 2022-06-06 14:43:06.908846 Received 24 bytes channel 23: 89 63 50 0b 16 e3 50 0b 16 81 4a 40 17 09 5b 53 88 82 dc 0b 64 80 f2 d3 |
2 | Error while retrieving data: max() arg is an empty sequence |
3 | |
4 | 2022-06-06 14:43:13.198405 Received 24 bytes channel 75: 8b 63 50 03 16 63 51 0b 56 95 5a 09 53 19 5b 33 8a 92 de 0b 6c 91 f6 d1 |
5 | Error while retrieving data: Frame 1 missing: Request Retransmit |
6 | |
7 | 2022-06-06 14:49:57.395157 Received 18 bytes channel 61: 88 63 50 03 16 63 50 13 16 00 03 00 80 08 01 00 03 89 |
8 | 2022-06-06 14:49:57.401382 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
9 | Error while retrieving data: Missing packet: Last packet 2 |
10 | |
11 | 2022-06-06 14:50:01.087613 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56 |
12 | 2022-06-06 14:50:01.098937 Received 24 bytes channel 40: 91 63 50 03 16 63 50 03 16 01 48 00 0e 09 59 13 8a 01 d8 03 65 00 f6 56 |
13 | Error while retrieving data: Missing packet: Last packet 2 |
14 | |
15 | 2022-06-06 14:50:02.584152 Received 18 bytes channel 61: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
16 | Error while retrieving data: Missing packet: Last packet 3 |
17 | |
18 | 2022-06-06 14:52:42.631804 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 13 86 01 c4 03 6d 00 f6 55 |
19 | 2022-06-06 14:52:42.643443 Received 24 bytes channel 75: 89 63 50 03 16 63 50 03 16 01 47 00 0e 09 55 53 86 05 c5 03 6d 01 f6 55 |
20 | Error while retrieving data: Missing packet: Last packet 2 |
21 | |
22 | 2022-06-06 14:52:44.136428 Received 18 bytes channel 40: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
23 | Error while retrieving data: Missing packet: Last packet 3 |
24 | |
25 | 2022-06-06 14:52:46.298238 Received 24 bytes channel 75: 91 63 50 03 16 63 50 03 16 01 47 00 0e 09 58 13 86 01 c1 03 67 00 f6 4f |
26 | Error while retrieving data: Missing packet: Last packet 1 |
27 | |
28 | 2022-06-06 14:52:47.289513 Received 18 bytes channel 3: 94 63 50 02 16 63 50 02 16 00 03 00 00 00 00 00 00 91 |
29 | Error while retrieving data: Missing packet: Last packet 2 |
30 | |
31 | 2022-06-06 14:52:47.851089 Received 18 bytes channel 40: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 01 00 03 89 |
32 | Error while retrieving data: Missing packet: Last packet 3 |
33 | |
34 | 2022-06-06 14:56:22.534647 Received 18 bytes channel 3: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
Der Raspi empfängt etwas alle ca. 30s, wenn die DTU die Requests sendet. Den Tx hab ich rausgelassen, da wir wissen, dass mein WR nicht darauf reagiert. Ich hab aus dem Log von Raspi mal diese größeren Abschnitte mit nur Tx gelöscht. Ich bin mit Arduino und C++ nicht wirklich gut unterwegs und brauche Starthilfe, an welchen Stellen die Sendebefehle wie zusammengebaut werden. Mein Tsun hat 2 Kanäle, füge ich ihn über 1141 statt 1041 hinzu, funktioniert das schonmal :)
Das Python-Script wird damit auch nichts automatisch dekodieren können, weil für die Wahl des Dekoders die Anfrage ausschlaggebend ist, die python selbst abgesetzt hat. Du kannst höchstens manuell den Datenstrom aufzeichnen, zusammensetzen und einen Dekoder dafür in Python bauen und das dann copy&pasta mit bytes.fromhex() da durch schieben. Das geht tatsächlich sehr gut und man kann dann auch schön am Dekoder rum tweaken bis die Ergebnisse sinnvoll sind. Beispiele habe ich ja schonmal gepostet. Bis die gesamte Transaktion implementiert ist, wird das mit dem python-Script, automatisch, keine Daten dekodieren können ohne den Tx 1. zu haben und 2. sinnvoll verstanden zu haben. Also aus dem Tx muss man erkennen können welche Daten angefragt wurden. Theoretisch könnte die DTU ja auch gerade ein Firmware-Update hochladen. Die Fragmente der Transaktion kann man schon durch einen Status-Dekoder schieben, bekommt dann aber keine sinnvollen Werte. Der Dekoder wird schon dekodieren. Der kann nicht erkennen ob das sinnvoll ist oder nicht, oder ob er für die Daten die man ihm gibt überhaupt geeignet ist. Zumindest solange der buffer groß genug ist und man nicht in einen IndexError läuft. Du bekommst da zwar Daten aber ohne Kontext. Binärdaten ohne Kontext sind nicht mehr als Rauschen.
Hi Jan, aktuell zeichne ich einfach auf, was durch die Luft fliegt. Die Requests habe ich da, kann sie nur nicht senden, allerdings macht das, was ich so empfange Sinn zu dem, was ich in der DTU sehe. Die bytes kann ich soweit dekodieren und nachvollziehen, nutze das eher als sniffer, den ich bedienen kann. Dass ich mit dem Python-Script nicht viel weiter komme, ist mir klar :) Leider bin ich nicht so tief in der Programmierung drin, wie einige andere hier, so dass ich sehr froh bin, die Scripte soweit überhaupt hab starten können und ihnen was sinnvolles entlocken konnte. Primäres Ziel war erstmal: - funktionieren die NRF-Platinen? -> mit externer Antenne nicht, integriert ja - auf welchen Kanälen wird empfangen? -> 3, 23, 40, 61, 75 - ist das, was ich empfange, sinnvoll? -> weitestgehend ja - kriege ich es hin, mit dem D1 mini was zu sehen? -> nur zufällig, eher nein Beim rumschnüffeln in der Luft hab ich noch 2-4 byte lange Antworten gesehen sowie solche Konstrukte:
1 | channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d fa 01 3a 33 |
2 | channel 40: b2 6b 50 03 16 63 50 07 16 00 03 00 00 02 00 20 02 91 |
3 | channel 23: a8 6b 50 03 36 63 50 03 16 00 13 00 00 0a d7 26 af bb |
4 | channel 3: a9 63 50 03 16 63 50 07 16 01 35 00 04 09 4a 13 8a 00 8e 85 03 01 3a d0 |
5 | channel 3: b2 63 50 03 36 63 50 03 16 00 13 01 00 00 00 80 08 93 c3 93 3a aa |
6 | channel 3: 94 63 50 03 16 63 50 03 14 00 43 00 00 00 10 00 01 91 |
7 | channel 3: 8b 63 50 03 16 63 51 03 16 01 2e 00 02 09 51 13 8e 80 51 05 04 01 2b 1b |
Was es damit aufsich hat, schau ich mir später noch an, da es wiederkehrende Muster aller paar Minuten sind. Ohne Hilfe beim Code werd ich aber nicht viel machen können, da mir einfach die Grundlagen fehlen. Ich komme aus dem Dickstrombereich, das hier ist Hobby ;) Deine Beispiele sehen gut aus, hab die versucht und bin (erstmal) gescheitert. Ich werd meine Freundin mal fragen, ob die damit weiter kommt. Wird aber etwas dauern. Trotzdem danke für den Ansatz, mit Geduld wirds werden :)
Ich hab gerade nochmal ein PR für python auf gemacht. Habe den DebugDecodeAny Dekoder nochmal überarbeitet. Beispiel: (auf der Kommandozeile)
1 | tools/rpi$ python3 -c 'import hoymiles; hoymiles.decoders.DebugDecodeAny(bytes.fromhex("5c 00 00 b4 91 00 00 ab bf 03 71 03 78"))'
|
2 | payload has 13 bytes |
3 | |
4 | Field view: int |
5 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
6 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
7 | >B 92 0 0 180 145 0 0 171 191 3 113 3 120 |
8 | |
9 | Field view: shorts |
10 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
11 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
12 | >H 23552 180 37120 171 48899 28931 |
13 | >H 0 46225 0 43967 881 888 |
14 | |
15 | Field view: longs |
16 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 |
17 | Hex 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 |
18 | >L 1543504052 2432696491 3204673795 |
19 | >L 46225 43967 57738104 |
20 | >L 11833600 11255555 |
21 | >L 3029401600 2881422193 |
22 | type utf-8 : utf-8 decode error |
23 | type ascii : ascii decode error |
*payload gekürzt, weil dieses dämliche Forum Zeilenumbrüche in Code, und damit Leserlichkeit kaputt macht. Würde die komplette Payload in die DebugDecodeAny-Klasse gepastet werden würde es uns noch sagen, dass sich um die Payload eine valide Modbus CRC (oder CRC8) befindet. Referenz:
1 | 2022-05-10 11:39:49.447628 Payload: 00 01 01 35 03 a8 0b 4a 01 37 03 aa 0b 5c 00 00 b4 91 00 00 ab bf 03 71 03 78 09 08 13 87 15 a1 00 00 00 ef 03 e8 01 ef 00 06 99 3a |
2 | 2022-05-10 11:39:49.447628 Decoded: 49.5 phase0=voltage:231.2, current:23.9, power:553.7, frequency:49.99 string0=voltage:30.9, current:9.36, power:289.0, total:46.225, daily:881 string1=voltage:31.1, current:9.38, power:290.8, total:43.967, daily:888 |
Wir finden aber Zahlen wieder und sehen schön an welcher Position in den Hex-Daten die stehen. Meiner Meinung nach sind in den tsun-Daten viele korrupte Pakete mit Bitfehlern drin. Die Payload CRC8 stimmt oft nicht. Manchmal auch offensichtlich durch korrumpierte Adresse. Nicht, dass wir da jetzt Unsinn lernen. Grundsätzlich würde ich das auf der Luft-Schnittstelle aber erwarten, da wir das Protokoll nicht implementiert haben.
@Daniel M. schrieb: @Jan-Jonas S > Hi Jan, > > aktuell zeichne ich einfach auf, was durch die Luft fliegt. Hallo Die Antwort channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d fa 01 3a 33 Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert. D.h. dieser TSUN ist ein MI? Konntest du schon einen request schicken und TSUN hat geantwortet?
Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu bekommen. Wie habt ihr das gemacht (ohne eine DTU)?
Christian P. schrieb: > Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu > bekommen. Wie habt ihr das gemacht (ohne eine DTU)? Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine Logs v. früher. Ich sehe die WR-Antworten nur wenn meine DTU-Pro die request schickt. Ich glaube, ich habe alle logs zusammen, WR-Antworten decodiert aber wie die request funktioniert hab nicht rausgefunden.
Ziyat T. schrieb: > Christian P. schrieb: >> Ich schaffe es nicht, meinen MI-300 zum Senden dieser Antworten zu >> bekommen. Wie habt ihr das gemacht (ohne eine DTU)? > > Eine request fehlt, das DTU > MI Protokoll ist echt sch..., siehe meine > Logs v. früher. Ja das las ich, ist also immer noch stand der Dinge wie es scheint :( Ich bin nur auf Funk-Ebene unterwegs, also versuche die Messages einer DTU mit einem nrf24-Modul nachzumachen, um die Funk-Antworten meines WR zu erhalten. Dabei fiel mir auf: Der WR antwortet NUR, wenn das nrf-paket im Funkheader die Zieladresse des WR hat (also SN=102161401913 -> Zieladresse 13:19:40:61:01 mit Länge 5). Das wäre die Unicast-Variante. Ich konnte keine Broadcast-Empfangsadresse für den WR hier im Forum bislang ausmachen, auch nicht anhand der jüngsten Logs zu "automatische Suche". Sowas könnte eine 2-5 bytige Addresse sein, auf die jeder WR in der zweiten Pipe lauscht. Außerdem: Die bekannten Payloads dokumentieren immer nach dem MID die S/N der DTU und danach die S/N des WR. Bei mir ist das umgekehrt! Der WR antwortet auf die Anfragen immer an jene Adresse, welche der ERSTEN S/N in der Payload entspricht. Das würde für mich bedeuten: die erste S/N der Payload sollte die DTU sein, an die deer WR seine Antwort adressiert. Die bislang dokumentierte Payload stellt aber als erstes die S/N des WR dar, und erst danach die S/N der DTU. Kann das jemand bestätigen?
Also so:
1 | python3 py-nrf24/send.py --crc 1 1319406101 15776655446140191381 |
2 | ..sendet die payload 15776655446140191381+crc8 an 13:.19:40:61:01 |
3 | 77665544 ist die erfundene SN meines Raspi |
4 | 61401913 ist die echte SN meines WR. |
5 | |
6 | Sent: to Address 1319406101 Data 15 77665544 88776655 81 58 |
7 | Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf |
8 | |
9 | Das geht auch ohne der S/N des WR in der Anfrage |
10 | python3 py-nrf24/send.py --crc 1 1319406101 15776655440000000081 |
11 | |
12 | Sent: to Address 1319406101 Data 15 77665544 00000000 81 94 |
13 | Recv: to Address 4455667701 Data 15 77665544 61401913 81 bf |
Ergo: 1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed, 0x01 als 5. byte). 2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5, reveresed mit 0x01 ergänzt 3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload 4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 und 0x7f beginnen.
:
Bearbeitet durch User
Habe was neues gefunden:
1 | nrf24-dest pcf payload |
2 | anfrage: 13 19 40 61 01 (16/0/0) df 02 00 776655441111111100fcaf85 0b |
3 | antwort: 13 19 40 61 01 (16/3/0) df 02 00 776661401913111100fcaf85 31 |
der Payload-Anfang df0200 bewirkt, dass der WR die Antwort-Adresse irgendwie ändert. Hier am Beispiel sendet er nicht an die DTU laut SN in den bytes 2.. retour, sondern an sich selbst?! Nachgefolgde MDI=15 anfragen werden ebenfalls an diese Andresse dann beantwortet. Ich hoffe ich habe mir nun nichts zerschossen. Scheinbar aber bewirkt der PRefix df0200 aber mal was anderes als nur MID=15.
rosch99 schrieb: > Tobi D. schrieb: >> ja mit und ohne kondensator das gleiche ergebniss, sendeleistung habe >> ich auch alle low, min, high und max probiert. > > Viele der NRF-Module haben geclonte Chips, manche funktionieren besser, > manche schlechter und manche gar nicht. Ich habe zB. mehrere Module mit > ext. Antenne bei Amazon bestellt, die ALLE überhaupt nicht > funktionieren. Mit gleicher Bestellung habe ich auch Module mit Antenne > auf der Platine bestellt, die funktionieren problemlos. > > rosch99 hab mir jetzt auch noch ein nrf modul bei az del. ohne externe antenne bestellt, leider auch keine besserung
Christian P. schrieb: > 1) der WR hört auf die nrf24-destinationadresse wie bekannt (reversed, > 0x01 als 5. byte). > 2) Der WR antwortet an die nrf24-dest-address laut Payload byte 2..5, > reveresed mit 0x01 ergänzt > 3) Die Antwort des WR enthält seine S/N als zweite S/N in der Payload > 4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 > und 0x7f beginnen. interresant, bei mir sieht es ganz anders aus..
Ziyat T. schrieb: > interresant, bei mir sieht es ganz anders aus.. naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit Schluss sind. Ich habe inzwischen folgendes nachstellen können.
1 | sende 15:77665544:22222222:80 an WR |
2 | empfange 15:77665544:61401913:80 als Antwort an Adresse 44:55:66:77:01 |
3 | 10sek pause |
4 | sende df0200:7766 55443333 3333:00 an WR |
5 | empange df0200:7766:61401913:333300 als Antwort an Adresse 22:22:22:22 |
Bei der ersten Nachricht setze ich im WR eine DTU-Adresse, die sich der WR merkt. Bei der zweiten Nachricht verwendet der WR die DTU-Adresse von zuvor und überschriebt nur die Bytes 4..7 mit der eigenen SN. > Christian P. schrieb: >>4) der WR Antwortet nur auf Payloads, die mit einer MID zwischen 0x00 >> und 0x7f beginnen. ich revidiere, punkt 4 stimmt nicht
Christian P. schrieb: > Ziyat T. schrieb: >> interresant, bei mir sieht es ganz anders aus.. > > naja, gut möglich dass meine Beobachtungen nicht der letzte Weißheit > Schluss sind. Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du? Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die gleiche SW verwenden würden, kommen wir ev. besser vorwaerts.
Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ und CE zu tauschen.
@Tobi B.
Beschreibe mal Deine Schaltung bzw. Überprüfe ob es evtl wie von Olaf
geschrieben am IRQ Eingang liegt. Nicht alle Pins am ESP sind
Interruptfähig.
Laut Deinem Log hat Dein HM-400 folgende Seriennummer:
> Inverter SN 1121xxxxxxxx Transmit 27 | 15 80 13 52 94
112180135294 stimmt das ?
Ich sehe in Deinem „kurzen“ Log nämlich nur TX aber kein einziges RX
Paket. D.h. dein ESP und nRF24 scheinen zu senden, aber der HM-400 fühlt
sich offenbar nicht angesprochen.
Alternativ kannst Du gerne auch mal ein längeres Log anhängen,
vielleicht sieht man da mehr. Nach dem Booten sollte der ESP auch einen
Block mit den nRF24 Settings ausgeben, etc pp.
@Daniel M. und Freundin, Ziyat T., Das sieht doch schon ganz vielversprechend aus. Ich meine auch das mit den „reversed“ 5 Byte (das letzte 01) bei der MI- Baureihe am Anfang des Threads gelesen zu haben. Habe mich immer gewundert, dass die HM- Baureihe die Seriennummer in der richtigen Reihenfolge und mit nur 4 Byte annimmt. Da scheint es wohl einen Unterschied zu geben. Viel Erfolg weiterhin!
Olaf A. schrieb: > Versuch mal die Pin-Belegung zu wechseln. Bei mir hat es geholfen IRQ > und CE zu tauschen. das hats gebracht, vielen dank für den tipp :)
Ziyat T. schrieb: > Habe deine Beitraege nochmals durchsucht, zum richtig Verstehen, die > Daten bekommst du mit dem Arduino+nrf24? Und welche SW benutzt du? > Ich benütze auch Arduino+nrf24 (hab auch esp+nrf24), wenn wir die > gleiche SW verwenden würden, kommen wir ev. besser vorwaerts. Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+ modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit sehe ich alle pakete (inkl. der destination adresse). Quelle des sketch kann ich nimmer sagen: habe ich Sept. 2020 organisiert, Author ist J. Coliz inspired by cpixip. Diesen Sketch habe ich etwas modifiziert, damit das 9bit PCF als 3 dezimale angezeigt wird und alles danach um das 1 Bit verschoben ist: so kann man viel leichter die Payload erkennen. Ergänzend habe ich ein Skript gebaut, dass die CRC des nrf24-Pakets prüft, so kann ich leichter die Noise aus dem gesnifften Kauderwelsch rausfiltern und es bleiben nur "echte" Pakete übrig. Zum Senden nutze ich einen Raspberry Pi 2B mit einem nrf24+ Modul an den GPIO Pins. Software ist von https://github.com/bjarne-hansen/py-nrf24 mit kleinen Modifikationen, um z.B. einen crc8 automatisch anzufügen. Ich sende und sniffe nur auf CH 0x03.
Hallo zusammen, ich bin aktuell ein stiller leser geworden. Habe aber folgende Infos mitbekommen (speziell für die MI-WR) und denke das es hier noch nicht im Forum diskutiert wurde? In dieser PDF Seite 8, sieht man die ältere Generation der DTU. https://cdn.webshopapp.com/shops/296982/files/328732372/mi-500-mi-600-mi-700-microinverter-user-manual-rev.pdf Das müsste genauer gesagt diese DTU sein: https://loja.opussolar.com.br/produto/transmissor-dados-hoymiles-dtu-mi/ Und hier sieht man eine DTU mit S.Nr.(10F052403668) aufgeklebt: https://ae01.alicdn.com/kf/H91aaca10736b4450a21891509dfeb934v.png Mit der Info will ich nur aussagen, dass die MI-WR die S.Nr. von der alten DTU wahrscheinlich hören wollen. Wie Olaf schon die Erkenntnis hatte, kann man nicht jede DTU mit jeden WR kommunizieren. :) Olaf A. schrieb: > *Anmerkung: Der Mikrowechselrichter der Seriennummer "1062xxxxxxxx" kann > nur mit dem neuen Gateway von > Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 > ( Seriennummer: 10D2xxxxxxxx) und > DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren Somit könnte man bei der Abfrage die DTU(alt), die S.Nr. 10F0xxxxxxxx hinterlegen. @IsnoAhoy: Hier könnte man die Excel aktualisieren, oder? https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx Und wenn mein Gedanke richtig ist und das so auch funktioniert,... könnte man später im Code hinterlegen mit welcher DTU-S.Nr. die Kommunikation stattfinden soll. Bsp: HM-800 11417420xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx) HM-1500 11616320xxyy => DTU-Pro (10F7xxxxxxxx, 10F8xxxxxxxx) MI-1200 10616090xxyy => DTU-Alt? (10F0xxxxxxxx) Gruß Daniel
:
Bearbeitet durch User
Hallo Olaf A. / Tobi D., danke für die positive Rückmeldung. Könnt Ihr bitte unter github oder hier Eure Verkabelung zwischen ESP (welches Modul) und dem nRF24 Funkmodul dokumentieren bzw. mit der Verkabelung dort vergleichen ? Danke! ESP8266: Discussion Verkabelung / Pinout #36 https://github.com/grindylow/ahoy/issues/36
Daniel R. schrieb: > Hallo zusammen, Nachtrag: Hier eine bessere Quelle: https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt
Daniel R. schrieb: > Daniel R. schrieb: > >> Hallo zusammen, > > Nachtrag: Hier eine bessere Quelle: > https://de.aliexpress.com/item/2255801014691936.html?gatewayAdapt=4itemAdapt Quatsch mit Soße.
Hallo Frank, danke für die Ausführliche Rückmeldung. ;) Die Quelle soll sich eher auf die DTU-MI (Bilder) beziehen. Ich weiß ja nicht inwieweit es "Quatsch mit Soße" seien soll. Lieber verweise ich auf die Quelle woher die S.Nr. stammt. Schließlich ist doch jede Hilfe (auch wenn es nur eine S.Nr. ist) brauchbar. Vielleicht könnte man die Daten aus dem MI-WR mithilfe dieser DTU S.Nr beziehen. Bisher wird meines wissens nach in der "hmRadio.h" mit einer festen S.Nr. vorgegaukelt welche DTU spricht. Vielleicht macht es Sinn hier die ersten 4 stellen diese mit einzubeziehen. So, erkläre mir jetzt mal wieso das Quatsch mit Soße ist!?
Christian P. schrieb: >>> > Ich nutze zum Scannen/Sniffen einen arduino-nano mit angehängtem nrf24+ > modul. darauf läuft ein sketch, der die adfresslänge auf 2 stellt und > bei beiden pipes mit adressen 0x0055 und 0x00aa hört, ohne crc: somit > sehe ich alle pakete (inkl. der destination adresse). >>>> Das ist interresant, habe wie gesagt bisher die aurduinoUno+nrf24 kombi und SW von Ivo Pullens verwendet. Ich würde gerne mal deine aurduino Sketches ausprobieren um zu sehen ob ich die gleichen Daten sehe wie du, geht das?
Hallo Daniel R., ja das ist evtl ein interessanter Fakt, ich habe noch keine Rückmeldung von den anderen DTU Besitzern erhalten welches Prefix die denn haben, sonst könnte ich die Tabelle gerne mal ergänzen/aktualisieren. Ich habe schon ein paar zusätzliche Informationen gesammelt aber noch keine. commit gemacht. @Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer versendet ? 10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ? @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten auf dem Kanal 2403GHz. @Oliver F. das wäre doch was für Deinen nRF24 hexa-Decker mit sechs nRF Modulen kannst Du dann senden und alle fünf Kanäle (2403-2475) mitschneiden. Ebenfalls interessant ist mE die Beschreibung unter Seite 8 des von Daniel R. verlinkten „historischen“ Dokuments: Fig.2. MI-500 /MI-600 /MI-700 Microinverter wiring diagram Note 1: DTU connects the power production of each microinverter. If the asymmetry current is going to exceed 16 A, DTU will send stop signal to one or more microinverters to let the asymmetry current lower than 16A. Das sind ja die Signale die uns noch fehlen, also wie kann die DTU die WR dazu bringen ihre Kanäle abzuschalten. Evtl. kann man mit diesem Wissen und einem regelbaren Netzteil am Eingang der WR eine DTU in den Panikmodus versetzen und die Nachricht abfangen ?
Hallo IsnoAhoy; IsnoAhoy schrieb: > am Eingang der WR eine DTU in den > Panikmodus versetzen Das klingt an sich nicht schlecht, nur ist die Frage ob der Flag im Speicher vom WR sich automatisch zurücksetzen lässt (durch ein Neustart?). Sonst bestünde die Gefahr das der WR für immer in dem Modus bleibt, außer man schickt den richtigen Befehl... wobei ich behaupte mal das die Entwickler hierfür bestimmt was vorgesehen haben. Hier würde ich mal das ganze mit vorsicht "genießen".
:
Bearbeitet durch User
Hallo Daniel R. ich gehe mal davon aus, wenn die Differenz der Leistung wieder unter 16A fällt sollte eine ordentliche DTU das auch wiedee freischalten, das könnte man dann auch aufnehmen. Hattest Du nicht Deinen WR mangels Modulen noch am Labornetzteil ? Ich nehme an das bezieht sich auf mehrere WR in der auf Seite 8 beschriebenen Modul-Konfiguration.
Genau, ich betreibe es aktuell am Labornetzteil. Nur habe ich ein HM-1500. Mein Netzteil kommt an sein Limit. :( Besitze nur einen mit 30V und knapp 10A.
:
Bearbeitet durch User
IsnoAhoy schrieb: > @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. > Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf > 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten > auf dem Kanal 2403GHz. Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und 0x00AA. Achtung: man kann hiermit keine längeren Payloads mitlesen, weil ja wegen der Empfangskonfig 6 Bytes und 1 Bit zu früh empfangen wird und deshalb die hinteren bis zu 7 Byte fehlen. Ziel dieses Sniff-Methode ist es, die Destination-Adresse im nrf24-Header zu identifizieren. Wenn man die mal genauer weiß, kann man den nrf24 auf diese Adresse und Adresslänge konfigurieren und dann die ganze Payload über die herkömmliche (=designte) Methode empfangen. Anbei der Sketch und die verwendete RF24 library. Mit readserial.py hole ich mir den Output am Raspberry Pi herein. Mit verifyserial.py filtere ich nach Paketen mit gültigem CRC. Aus Performancegründen nur Pakete mit 5stelliger Zieladresse. Das kann man in Zeile 59 auf range(0,3) setzen, um 2 bis 5 byte lange Adressen durchzuanalysieren. Achtung: Payloads länger als 23 Byte oder 24 Byte könnten hier übersehen werden. LG
:
Bearbeitet durch User
Hallo zusammen, ich versuche gerade das NRF auf dem Raspi zum laufen zu bringen. Ich scheitere beim letzten Step "sudo python3 -um hoymiles...".
1 | sudo python3 -um hoymiles --log-transactions --verbose --config /home/dtu/ahoy.yml | tee -a log2.log |
2 | Traceback (most recent call last): |
3 | File "/usr/lib/python3.7/runpy.py", line 183, in _run_module_as_main |
4 | mod_name, mod_spec, code = _get_module_details(mod_name, _Error) |
5 | File "/usr/lib/python3.7/runpy.py", line 142, in _get_module_details |
6 | return _get_module_details(pkg_main_name, error) |
7 | File "/usr/lib/python3.7/runpy.py", line 109, in _get_module_details |
8 | __import__(pkg_name) |
9 | File "/home/Hoymiles_NRF24/hoymiles/__init__.py", line 14, in <module> |
10 | from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16 |
11 | ImportError: /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: undefined symbol: _ZN4RF2410setPALevelEh |
Ich habe wie in der Beschreibung auf Github alles Installiert und auch den Wrapper drauf gepackt. Ich musste vorher noch die Module crcmod & RF24 nach installieren. Aber irgendwie hängt das ganze. :( Raspberry Pi 4 Python 2.7.16 Python 3.7.3 PS: Bei Step 4 "nano gettingstarted.cpp", habe ich diesen Punkt einfach ohne Änderung weiter gemacht. Ist das falsch?
:
Bearbeitet durch User
Hallo in die Runde, nachdem ich eine Weile nur selten mitlesen konnte, habe ich nun mein Setup wieder aktiviert. Diese Software https://github.com/hm-soft/Hoymiles-DTU-Simulation läuft auf einem Arduino Nano V3 zuverlässig und liefert an meinem HM600 Werte, die gut zu dem passen, was ich am Shelly mitlogge.
1 | ----------------------- |
2 | rcv CH:75 00 1234567801 00BE 17 3 95 72014650 72014650 830000000403E8012900163010E7B896 B896 1 |
3 | Udc.CH1=29.4 V |
4 | Idc.CH1=0.14 A |
5 | Pdc.CH1=4.2 W |
6 | Udc.CH2=30.0 V |
7 | Idc.CH2=0.15 A |
8 | Pdc.CH2=4.6 W |
9 | E-Total.CH1=145.471 KWh |
10 | E-Total.CH2=146.316 KWh |
11 | E-Tag.CH1=1568 Wh |
12 | E-Tag.CH2=1610 Wh |
13 | Uac=233.6 V |
14 | Freq.ac=49.99 Hz |
15 | Pac=8.4 W |
16 | Ipv=0.04 A |
17 | WR-Temp=29.7 °C |
18 | Status=1000 |
19 | E-heute=3178 Wh |
20 | E-Total=291.787 KWh |
Tagesproduktion heute lt. Shelly 3100Wh und Total 290 KWh Klasse, wie gut das schon funktioniert :-) Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g. Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht kompatibel sind. Hat jemand eine lauffähige Version für ESP32? Viele Grüße Carsten
Christian P. schrieb: > IsnoAhoy schrieb: >> @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. >> Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf >> 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten >> auf dem Kanal 2403GHz. > > Fast. Man kann die Adresslänge auf 2 bis 5 Byte stellen. Wenn auf 2 Byte > konfiguriert, dann lauten die konfigurierten Empfangsadressen 0x0055 und > 0x00AA. >>>> Hallo Christian P. Danke für die SW! Habe gerade ausprobiert ohne was zu aendern, also als sniffer: WR ist im Schlaf , die DTU-Pro sendet/sucht. Zuerst mal bin ich beruhigt, die Daten sind gleiche was ich auch schon mit "meiner" SW gesehen habe. Siehe Anhang, du kannst es sicher besser interpretieren.. Was die DTU sendet ist dauernd: 00 f2 bis 00 fd
:
Bearbeitet durch User
> Was die DTU sendet ist dauernd: 00 f2 bis 00 fd
Das liest sich so:
1 | 60 71 70 63 01 (11/0/0) 38(63 70 71 60|72 22 84 12)00 fc[a4 bb] |
Erste 5 Bytes: Adresse, an welche das nrf24 Paket geschickt wird. Nur nrf24 Module empfangen das, die nach Paketen an diese Adresse "lauschen". (11/0/0) ist das decodierte 9bit PCF: 11=Länge der payload, 0=message counter, 0=noack-flag Die payload ist also 0x38 bis 0xfc. Danach in der eckigen Klammer ist der crc16 vom nrf24 Protokoll. Die Payload habe ich mit (|) versucht zu untergliedern: erstes Byte ist das MID (sofern das stimmt). Danach 4 Byte mit S/N des WR, dann 4 Byte mit S/N der DTU, dann der CMD 0x00, dann ein CRC8 über die vorangegangen Bytes der Payload. Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn der WR antwortet steht an genau dieser Stelle die S/N des WR. Nun gilt es herauszufinden, wie man dem WR "programmiert", an welche Adresse er seine Antwortpakete senden soll. Ich habe das zuletzt geschafft indem ich ein Paket mit MID=15 und CMD=80 an den WR geschickt habe (Inhalt nach der Logik wie oben). Danach hat der WR einige Minuten lang alle seine Antworten an die gesetzte Adresse geschickt 8-) Leider aber konnte ich weiterhin keine Stromdaten aus dem WR herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die PV-Kanäle 36:1, 37:2, 38:3 und 39:4...?
:
Bearbeitet durch User
Hallo zusammen, Daniel R. schrieb: > Ich scheitere beim letzten Step "sudo python3 -um hoymiles...". Zu meinem obigen problem bin ich nicht weiter gekommen. Alles neu gemacht aber irgendwie hänge ich nun an dem Wrapper. Nunja, wollte euch nur zum Thema "NRF24 kann nicht senden" noch Informieren das man die Platine einpacken soll. Siehe: https://github.com/nRF24/RF24/blob/master/COMMON_ISSUES.md Falls es jemand interessiert. :)
Christian P. schrieb: >>> Ach so, danke für die Erklaerung! > Leider aber konnte ich weiterhin keine Stromdaten aus dem WR > herauskitzeln. Ich werde das aber morgen mal probieren mit den Daten von > deinem Log. Also MID=36 bis 39 und CMD=00. Vielleicht sind das ja die > PV-Kanäle 36:1, 37:2, 38:3 und 39:4...? Ich hatte mal früher schon mit MID=00bisFF und CMD=00bisFF alle Kombinationen erfolgslos versucht, aber hab vielleicht was falsch gemacht.. Jetzt bin gespannt, was bei dir rauskommt. > Interessant ist hier: die S/N der DTU ist an zweiter Stelle der beiden > Seriennummern. Das ist offenbar der Platz fur die S/N des Senders. Wenn > der WR antwortet steht an genau dieser Stelle die S/N des WR. Das ist genau so, imho bei allen DTU's
Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden. Handbuch: http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text
1 | If the DTU cannot detect all the microinverters in the system over 30 minutes, please use manual mode instead. |
Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping" aussendet und die WR darauf eine Rückantwort ausgeben. Hier müsste es auch in der DTU-Pro diese Funktion geben. Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon" auffangen und mit Implementieren (Feature). ------------------------ In diesem Beitrag von einem anderen Forum: https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840 Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann, ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :) Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf... Gruß
Daniel R. schrieb: > Zum Thema DTU-MI (für MI WR) habe ich was Interessantes gefunden. > > Handbuch: > http://www.worldtechnologysupply.com/wp-content/uploads/2018/06/Manual-Usuario-DTU.pdf > > Auf der Seite Seite 13 wird der Auto-Scan Modus erklärt. Laut dem Text >
1 | If the DTU cannot detect all the microinverters in the system over |
2 | > 30 minutes, please use manual mode instead. |
> Scheint das die DTU für diese Zeit zyklisch einen "Beacon/Ping" > aussendet und die WR darauf eine Rückantwort ausgeben. > > Hier müsste es auch in der DTU-Pro diese Funktion geben. > Kann das jemand VErifizieren, wenn ja könnte man diesen "Beacon" > auffangen und mit Implementieren (Feature). > Das ist ein altes Manual. Bei meiner DTU-Pro geht das nicht mit dem MI-WR, man muss ihn zuerst in der APP/Cloud angeben > > In diesem Beitrag von einem anderen Forum: > https://www.photovoltaikforum.com/thread/127532-hoymiles-dtu-mi-login/?postID=2634840#post2634840 > > Das man ja via Modbus an der DTU auch die Leistung am WR ändern kann, > ohne Energiemessgerät. Kann das ein DTU-Pro besitzer doch probieren? :) > > Oder wo gab es schwierigkeiten, hab da gerade ein Knoten im Kopf... > > Gruß Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache seit einem Jahr per Modbus den zero export. Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine früheren Beitraege hier...
@Christian P. Anfrage DTU-Pro: PV1: ...36(63 70 71 60|72 22 84 12)00 PV2: ...37(63 70 71 60|72 22 84 12)00 PV3: ...38(63 70 71 60|72 22 84 12)00 PV4: ...39(63 70 71 60|72 22 84 12)00 Anworten vom MI-WR: PV1: ...b6(63 70 71 60|63 70 71 60)data PV2: ...b7(63 70 71 60|63 70 71 60)data PV3: ...b8(63 70 71 60|63 70 71 60)data PV4: ...b9(63 70 71 60|63 70 71 60)data 36 00110110 b6 10110110 bit8 gesetzt 37 00110111 b7 10110111 bit8 gesetzt ;-)
:
Bearbeitet durch User
Ziyat T. schrieb: > @Christian P. > Anfrage DTU-Pro: > PV1: ...36(63 70 71 60|72 22 84 12)00 > PV2: ...37(63 70 71 60|72 22 84 12)00 > PV3: ...38(63 70 71 60|72 22 84 12)00 > PV4: ...39(63 70 71 60|72 22 84 12)00 > > Anworten vom MI-WR: > > PV1: ...b6(63 70 71 60|63 70 71 60)data > PV2: ...b7(63 70 71 60|63 70 71 60)data > PV3: ...b8(63 70 71 60|63 70 71 60)data > PV4: ...b9(63 70 71 60|63 70 71 60)data Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten vom WR.
1 | 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2] <-anfrage vom Raspi |
2 | 44 55 66 77 01 (11/2/0) 36(77 66 55 44|61 40 19 13)00 1d[88 16] <-antwort vom WR |
Gleiches Ergebnis mit MID=37 bis 40. Bei mir antwortet der WR nur, wenn die erste S/N die vom Raspi ist. Setze ich da die S/N vom WR ein, dann antwortet der nicht mehr. Irgendwas macht deine DTU also zusätzlich, vielleicht auch nur alle $$ Minuten? Oder gar nur einmalig beim Hinzufügen des WR ins Setup? Vielleicht passiert es auch auf einem der anderen Kanäle? Ich lausche ja nur auf 0x03. Den Kanal kann man in den Skripten ja auch mal ändern...
@ Christian P. (pocki) Hier noch was: DTU: 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e WR: d1(63 70 71 60|63 70 71 60)5a 5a d1 51>d1 8 bit gesetzt
Christian P. schrieb: > Ziyat T. schrieb: >> @Christian P. >> Anfrage DTU-Pro: >> PV1: ...36(63 70 71 60|72 22 84 12)00 >> PV2: ...37(63 70 71 60|72 22 84 12)00 >> PV3: ...38(63 70 71 60|72 22 84 12)00 >> PV4: ...39(63 70 71 60|72 22 84 12)00 >> >> Anworten vom MI-WR: >> >> PV1: ...b6(63 70 71 60|63 70 71 60)data >> PV2: ...b7(63 70 71 60|63 70 71 60)data >> PV3: ...b8(63 70 71 60|63 70 71 60)data >> PV4: ...b9(63 70 71 60|63 70 71 60)data > > Hi. Gerade selbst auch probiert. Leider bei mir nur "leere" Antworten > vom WR. > > [code] > 13 19 40 61 01 (11/1/0) 36(77 66 55 44|77 66 55 44)00 36[b0 d2] > <-anfrage vom Raspi ich glaube es muss so sein: DTU>WR 36(63 70 71 60|72 22 84 12)00 f2 37(63 70 71 60|72 22 84 12)00 f3 38(63 70 71 60|72 22 84 12)00 fc 39(63 70 71 60|72 22 84 12)00 fd
Bei mir so - ich habe nun einfach mal deine Adressen kopiert.
1 | 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- raspi an WR |
2 | 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- antwort vom WR |
sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt. Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet der gar nicht.
Ziyat T. schrieb: > Ja, man kann die angeschlossene Nennleistund prozentual regeln, so mache > seit einem Jahr per Modbus den zero export. > Bei MI kann man nur auf 10% regeln, beim HM bis auf 2%. Siehe dazu meine > früheren Beitraege hier... Ok, da ich ein HM besitze ist es bis auf 2% echt cool. 8-) Ziyat T. schrieb: > @Christian P. > Anfrage DTU-Pro: > PV1: ...36(63 70 71 60|72 22 84 12)00 > PV2: ...37(63 70 71 60|72 22 84 12)00 > PV3: ...38(63 70 71 60|72 22 84 12)00 > PV4: ...39(63 70 71 60|72 22 84 12)00 Sobald ich meine Probleme mit dem Raspi+NRF in den Griff bekommen habe, probiere ich das mal aus. Danke! :) @pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt. Hattest du die selben Probleme? -> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Daniel R. schrieb: > @pocki: Du hattest vor kurzem ja auch den Raspi mit dem NRF eingesetzt. > Hattest du die selben Probleme? -> > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Ja, habe ich auch nicht hinbekommen und dann hingeschmissen.
Guten Tag, ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500. Mein interesse ist die "export limitierung" realisiert durch einen bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24) Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode der DTU-PRO nicht weiter um die Informationen besser zu decodieren? Grüße Andreas
Andreas S. schrieb: > Guten Tag, > > ich habe selbst eine Anlage im Aufbau. Umrichter ist ein MI1500. > > Mein interesse ist die "export limitierung" realisiert durch einen > bereits vorhanden modbus fähigen smart-meter. Ich werde jetzt seitens > der Hardware auch mal ein Setup aufbauen. (Arduino + nrf24) > > Vielleicht ist es eine unsinnige Frage aber warum hilft der Quellcode > der DTU-PRO nicht weiter um die Informationen besser zu decodieren? > > Grüße > Andreas Hallo Andreas Hast du die Quellcode der DTU-PRO? Oder wo kann man sie finden?
@Christian P. (pocki) Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann? Ich möchte gerne die obige Diskussionen/Erkentmisse bei mir mal ausprobieren ohne lange deinen Sketch zu studieren und kaputt zu machen :-) Es waere einfach wenn ich als data z.B. 36(63 70 71 60|72 22 84 12)00 f2 37(63 70 71 60|72 22 84 12)00 f3 38(63 70 71 60|72 22 84 12)00 fc 39(63 70 71 60|72 22 84 12)00 fd schicken könnte
Hallo Andreas, wenn ich dich richtig verstanden habe ist an sich dein Gedanke nicht schlecht. Um an den Quellcode dran zu kommen ist es nötig das jemand die Mikrocontroller vom DTU-Pro dumped, diesen müsste man dann decompilieren und und und... wäre an sich möglich. Die Frage jedoch, wer hat eine DTU-Pro UND das Equipment um ein Dump zu machen? Bluepill, Blackpill,... https://medium.com/techmaker/reverse-engineering-stm32-firmware-578d53e79b3 Achtung: bei solch einem Dump werden natührlich auch die Daten (S.Nr, Email?, User-Infos) mit gesichert. Wenn jemand sich das zutrauen könnte, wäre das an sich eine feine Sache. =) Edit: Wie Ziyat schon geschrieben hat: Quellcode ist ja ein vom Hersteller geschrieben und ich kenne kaum eine Firma die denn Quellcode freigeben. ;)
:
Bearbeitet durch User
Ziyat T. schrieb: > @Christian P. (pocki) > Kannst du deinen Arduino Sketch so umbauen, dass ich was schicken kann? Leider nein, so gut bin ich mit Arduino-Sketches nicht. Deshalb mache ich das auch mit einem Raspi und einem zweiten nrf24 Modul an den GPIO-Pins. Software dazu siehe ein paar Posts weiter oben mit den zip Attachments.
Hallo an die HolyMolyDTU SW-Entwicker Ich habe die letzte SW im April eingesetzt, sowohl ESP als auch Arduino Versionen, da die MI-WRs nicht mehr aktuell sind und ich war der einzige mit einem MI-WR, habe ich damals aufgehört weiter zu machen. Seit dem habe keine Ahnung mehr über die SW-Staende etc.. Jetzt hat mich wieder ein bisschen durch Christan P. gepackt, den MI zu lauschen, ich denke wir sind bisschen weiter gekommen. Ich möchte gerne eine der SW-Versionen (ESP oder Arduino) verwenden um einfach paar Msgs zu schicken und was zu empfangen. Ich gestehe, bin etwas faul um irgend eine SW zu aendern. Kann mir jemand von SW-Enwicklern eine Version anbieten mit der ich die folg. payload schicken kann: MID..WR...........DTU..........CMD.. 36...63 70 71 60..72 22 84 12..00 f2 37...63 70 71 60..72 22 84 12..00 f3 38...63 70 71 60..72 22 84 12..00 fc 39...63 70 71 60..72 22 84 12..00 fd erwartete Antwort b6...63 70 71 60..63 70 71 60..data..... Danke
Hallo, es gibt ein git-respository. Das parent-repository ist einige commits ahead aber privat. Die Aussage leite ich aus den merge requests 2020 ab. Aber vermutlich werden ein paar brauchbare Informationen vorhanden sein. https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO (Anmelden über den github oauth provider) Allerdings enthält das repository keine Lizenz Informationen. Daher ist eine bedenkenlose Verwendung wohl fraglich. Grüße Andreas
Christian P. schrieb: > Deshalb mache ich das auch mit einem Raspi Also funktioniert es bei dir doch. Hmm... Gut dann gehe ich denn weg alleine. Andreas S. schrieb: > Das parent-repository ist einige commits > ahead aber privat. Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff darauf, kann man da etwas scrapen? :) Dann könnte man das ganze hier sogar beschleunigen.
Christian P. schrieb: > Bei mir so - ich habe nun einfach mal deine Adressen kopiert. > >
1 | > 13 19 40 61 01 (13/0/0) 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e[f4 3e] <- |
2 | > raspi an WR |
3 | |
4 | das hier sollte 5a 5a 9e 0b sein |
5 | |
6 | > 60 71 70 63 01 (13/1/0) 51(63 70 71 60|61 40 19 13)5a 5a 0b 73[df 5d] <- |
7 | > antwort vom WR |
8 | > |
> > sieht aus wie ein dummes echo. nur die S/N wurde vom WR eingesetzt. > Und again: wenn ich an byte 2-5 die S/N meines WRs eingebe, antwortet > der gar nicht. hab alle MID=51 von DTU im Anhang, dann antwortet MI regelmaessig mit MID=D1
Daniel R. schrieb: > Christian P. schrieb: >> Deshalb mache ich das auch mit einem Raspi > > Also funktioniert es bei dir doch. Hmm... > Gut dann gehe ich denn weg alleine. > > Andreas S. schrieb: >> Das parent-repository ist einige commits >> ahead aber privat. > > Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff > darauf, kann man da etwas scrapen? :) > > Dann könnte man das ganze hier sogar beschleunigen. Christian P. hat zum Lauschen Arduino+nrf24 zum Senden Raspi+nrf24. Versuch mal mit seiner Raspi SW ?: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Daniel R. schrieb: > Ich weiß ja nicht woher die Infos kommen, aber kurz: Hast du Zugriff > darauf, kann man da etwas scrapen? :) Also: - Gefunden mit dem Tool "google". ( https://www.google.de/search?q=gitee+hoymiles+dtu ) - Jeder hat Zugriff (siehe Link vorher oder erster Treffer in der google Suche) wenn man einen Account auf gitee erstellt. (github ist für die Welt, gitee ist für China) - Ja sollte helfen, da kompletter Quellcode inklusive Bootloader, Doku, Tabellen, Logs,... Grüße Andreas
:
Bearbeitet durch User
Super - da findet sich im gitee repo ein excel file mit dem Titel RFxxxx-V6.5. Schon ohne Translator erkennt man darin Message-Schemen. Das haben wir gesucht! Nun geht es ans übersetzen und auf die Suche des "PASSWORD/unlock codes" für die Commands MID=0x15 und 0x09... :-) Die finden sich vielleicht auch irgendwo dort im Repo.
Hallo, ich habe scheinbar ein Händchen für Suchfunktionen. :-) Im file usart_nrf.c ist definiert: UsartNrf_Send_PackSetLockOnOffCommand(...) Andreas
Hallo Ziyat T, danke für den Link. Jedoch ging es eher von Ahoy Github (https://github.com/grindylow/ahoy/tree/main/tools/rpi). Das bekomme ich nicht zum laufen. :( Christian nutzt die andere abgewandelte. ^^ Das würde ich dann nehmen, wenns nicht anders geht. @Andreas S: Okay cool, Gitee kannte ich gar nicht und wo ich auf die Seite gekommen bin (mit translator), wurde ich indirekt abgewimmelt. Ich versuche mich dort mal zu Registrieren. Mal schauen wie gut ich in Chinesisch bin. joke :)
Hallo, gibt es einen Trick das ganze Repo als ZIP herunterzuladen ? Ich bekomme überall nur 404 wenn ich den Button "Clone or Download" und dann "Download as ZIP" versuche (bei gitee.com). Anmeldung hab ich hinbekommen.
:
Bearbeitet durch User
Angehängte Dateien:
Also bei mir hat es funktioniert. Die ZIP ist 148MB groß.
Sieht nach den "Kronjuwelen" aus! Der Source Code lässt vermutlich keine Fragen mehr offen.
:
Bearbeitet durch User
Andreas super arbeit! Übrigens bin ich bisschen vorsichtig hier. Habe mal zwecks Dokumente lesen diese bei Virustotal geschoben. Aktuell nichts auffäliges. https://www.virustotal.com/gui/file/a31fea2076e821eae5d783c75fa3814e7a3378002f21d80d4737d238a31e4b47?nocache=1 Würde das bei allen Files empfehlen, besonders die bat / exe. Die erste bat-File im root Ordner sieht bisschen suspekt aus. Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich einige Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder besser Github pushe?
:
Bearbeitet durch User
Danke ! ! ! für den Link ! ! ! Danke Andreas ! ! !
Daniel R. schrieb: > Andreas super arbeit! > p> Edit: Eine rechtliche Frage in die Runde.... Ist es okay wenn ich einige > Dokumente auf deutsch übersetze und diese Seperat hier hochlade? Oder > besser Github pushe? Rechtlich sind wir sowieso alle Banditen hier, darum gefaellt es mir;-)) Die Chinesen haben seit mehr als 20 Jahren auch alles kopiert... Für mich lieber Github, auch ohne Uebersetzung
@Christian P. #define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF 0x51 //ŒÓËø&ÏÞÖƹŠÂÊ #define CONTROL_LOCK_MI_SUB 0xa5a5 #define CONTROL_LIMIT_POWER_SUB 0x5a5a #define CONTROL_ON_SUB 0x55aa #define CONTROL_OFF_SUB 0xaa55 genau was ich heute bei mir gesehen habe ;-) 51(63 70 71 60|72 22 84 12)5a 5a
Angehängte Dateien:
Also in der Excel "RF通讯协议-V6.5.xlsx" (RF-Kommunikationsprotokoll-V6.5.xlsx) stehen viele Dinge über die alten MI-WR Serie. ;) Da sollte in Zukunft Licht ins dunkle kommen. Die Excel habe ich zu ca. 1/3 auf Deutsch übersetzt. Ich breche hier ab und schaue mich noch in den anderen Dokumenten um.
:
Bearbeitet durch User
Bingooo!!!!
1 | /*********************************************** |
2 | ** Function name: //Stellen Sie die Anti-Rückfluss-Parameter ein |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | |
7 | ** Returned value: ? |
8 | *************************************************/ |
9 | uint8_t UsartNrf_Send_PackSetRefluxPowerCommand(uint16_t reflux_power, uint8_t MainCmd, uint16_t SubCmd) |
10 | {
|
11 | uint8_t i = 0; |
12 | uint16_t j; |
13 | uint8_t temp_dat[UART_LEN]; |
14 | memset(temp_dat, 0, sizeof(temp_dat)); |
15 | Uart_SendBuffer[0] = STX;//Kopf |
16 | temp_dat[0] = MainCmd; //Anweisung |
17 | memset(&temp_dat[1], 0, 4); |
18 | memset(&temp_dat[5], 0, 4); |
19 | // |
20 | // MIReal[PortNO].Data.NetCmd = NET_TURN_ON; |
21 | // if(MIReal[PortNO].Data.NetCmd == NET_TURN_ON) //开机状态 |
22 | // {
|
23 | temp_dat[9] = SubCmd & 0XFF00 >> 8; |
24 | temp_dat[10] = SubCmd & 0XFF; |
25 | temp_dat[11] = reflux_power * 100 / (EVERY_PORT_POWER * 10 * Dtu3Detail.Property.PortNum); //Prozentsatz der Leistungsbegrenzung |
26 | temp_dat[12] = reflux_power >> 8; //Hohe 8-Bit-Leistungsbegrenzung |
27 | temp_dat[13] = reflux_power & 0x00ff; //Niedrige Leistungsgrenze 8 Bit |
28 | // } |
29 | // else //开低功耗 |
30 | // {
|
31 | // temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a |
32 | // temp_dat[10] = SubCmd & 0XFF; |
33 | // temp_dat[11] = 0; |
34 | // temp_dat[12] = 20&0x00ff; |
35 | // temp_dat[13] = 20&0xff00>>16; |
36 | // } |
37 | temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC |
38 | i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //Vorwärtssubstitution |
39 | Uart_SendBuffer[i + 1] = ETX; //Ende |
40 | memset(temp_dat, 0, sizeof(temp_dat)); |
41 | return (i + 2); |
42 | } |
Guten Abend, ich kann zwar programmieren -- denke ich -- aber ich bin eher der Anwender / Orchestrator. Daher meine vorsichtige Frage. Bekommen wir, ihr oder die Community es hin eine Arduino Bibliothek und/oder ein Python modul "ahoymilesdtu" zu erstellen? Man könnte ja in die Kommentare der Files im Sinne "copyleft" das quellgebende repository nennen. Danke und Grüße Andreas
:
Bearbeitet durch User
Ich kann mit der Frage nichts Anfangen. Was möchtest du nochmal genau wissen? :)
Daniel R. schrieb: > Ich kann mit der Frage nichts Anfangen. > Was möchtest du nochmal genau wissen? :) Das Resultat der zahlreichen Stunden die hier investiert werden könnte doch so aussehen: arduino include <ahoydtu.h> include <mysmartmeter.h> AHOYDTU ahoydtu_nrf24(SS_PIN, RST_PIN,...); MYSMMETER mysm('192.168.1.1',502); // Haus-Hauptanschluss void setup() { ... ahoydtu_nrf24522.Init(); ... } void loop(){ ... if (mysm.read_active_pw_kw() < -0.6){ ahoydtu_nrf24.reduce_pw_by(0.6 - math.abs(mysm.read_active_pw_kw()) ); } else { // no power limit } //wait some time ... } und/oder das gleiche in python import ahoydtu as ahoy ....# usw. So kann man 2kW installieren und speißt max. 600W ein. Und dank Blindleistungsregelung max. -60VA laut Richtlinien. Das geht glaube ich so in der DTU Pro software (noch) nicht. (siehe file: AntiBackflow.c )
:
Bearbeitet durch User
Sieht ja vielversprechend aus. Die Frage der Lizensierung ist sehr berechtigt. Ich würde meine Werke gerne unter der GPLv2 lizensiert sehen. Das wäre auch ein Grund für die Teilung der Repos. Meinetwegen bleiben sie bei Petersilie. Früher oder später muss das eh passieren, wenn wir python mal als richtiges installierbares Package bauen wollen. Für den MI-Teil bin ich sogut wie raus, weil ich hier kein DuT habe. Ich kann die Grundsubstanz des Python-Codes vielleicht mal modularer gestalten, dass das MI-Protokoll parallel hinzugefügt werden kann. Grundsätzlich bietet python ja schon die Idee, rohe Payloads via mqtt zu injecten. Jedoch bisher nur als Payload in zu einem HM, ohne ESB-Frame. Könnte man aber anpassen. Schwieriger wird dann das empfangen.
Andreas S. schrieb: > So kann man 2kW installieren und speißt max. 600W ein. Und dank Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein Zertifikat sehen, dass das auch funktioniert. Im Wesentlichen wird das EVU fordern bei Dir eine Fern-Abschalteinrichtung einzubauen. Physikalisches Limit != Software Limit. Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal wegen Unterproduktion die Computer aus.
Jan-Jonas S. schrieb: > Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine > DIY Frickelei ohne Siegel und Plombe eh nicht sein. Doch, ist sie, das ist gar kein Problem Zeig mir einen WR an dem die 70% Grenze verplombbar ist - entweder den Installateur interessiert es nicht oder man nimmt sie raus nachdem er weg ist Mit Kontrollen ist hier auch nicht zu rechnen auf welcher rechtlichen Grundlage sollte das passieren? Und selbst wenn es so passieren sollte - Pressemitteilung "900.000 PV-Anlagen in Deutschland still gelegt weil sie 3% zu viel eingespeist haben"- lächerlich
Hallo Andreas S., das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges. Hier die usart_nrf.c übersetzt ins Englische. Ich traue den Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht. Man sollte halt keinen Source Code 1:1 aus dem Original übernehmen, dann ist das ja auch nur eine Referenz und keine Kopie -> Urheberrecht. Bei dem Python Code von Jan-Jonas und den anderen Pythonistas sehe ich da sowieso eher kein Problem. Wenn es um die Portierung des Protokolls von der C in eine C++ Variante geht scheint mir der C++ Code von Lukas auch viel eleganter als das doch recht prozedurale C der Hoymiles Bibliothek. Vor allem der Parser für die Pakete ist m.E. bereits viel hübscher und modularer geraten.
isnoAhoy schrieb: > Hallo Andreas S., > das ist tatsächlich eine echte Fundgrube und erleichtert sicher Einiges. > > Hier die usart_nrf.c übersetzt ins Englische. Ich traue den > Übersetzungsprogrammen von Chinesisch direkt ins Deutsche nicht. Danke, super. Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden. Kann mir wer damit helfen? Verdächtig sind da ein paar Commands in der Übersicht: 0x02 broadcast commands to collect terminal device IDs in the network 0x13 Set query RF ID 0x18 All wRFID retrieval, respond as long as there is retrieval 0x1a Set MI-NRF ID
Hier ist eine englische Übersetzung des RF communication protocol-V6.5xlsx
Anbei noch einige übersetzte Dokumente. Laut dem Filesystem Design Dokument speichert die DTU 96 Werte pro Tag, das sind bei 1440 / 96 = 15 Minuten Intervalle.
Angehängte Dateien:
Hallo Christian P., > Ich habe jetzt den ganzen Abend schon studiert und auch übersetzt. Doch > den Hinweis, wie ich meinem MI-300 zum Plaudern bekomme nicht gefunden. > Kann mir wer damit helfen? Ich habe das Excel-Dokument noch ein bißchen formatiert damit es leichter lesbar ist. Ich vermute das ist das Legacy poll data command 0x09 auf Seite 3 Data Collection instructions. Für den/die anderen Kanäle der zwei bzw. vier Kanal-Wechselrichter Varianten gibt es noch das Command 0x11 Kanal B, bzw. 0x36, 0x37, 0x38, 0x39 (=Kanäle A1, B1, A2, B2). Für die Suche nach einem WR kann man Command 0x02 verwenden siehe Seite 5 Data acquisition RF dedicated. Eventuell hast Du unbeabsichtigt auch das Kommando 0x01 Switch DTU-NRF air baud rate 2M / 250K an Deinen WR abgesetzt ? Versuche es doch mal mit 0x01 im User data wieder auf 250K zurück zu setzen. Ich meine so etwas auch in martin (Gast)'s DTULite Logfiles an den RX/TX Punkten gesehen zu haben. Ich vermute die Kommunikation mit 250K ist um einiges stabiler als die 2M Baudrate, vor allem in unseren Breitengraden mit einem vollen 2.4GHz Band.
Bingo - habe meinem MI-300 eine Antwort entlockt:
1 | Anfrage: |
2 | 13 19 40 61 01 (11/1/0) 09(61 40 19 13|51 22 22 22)00 51[cc 1a] |
3 | Antworten: |
4 | 22 22 22 51 01 (24/1/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1c.13 89.00 71.00 18.00 a4.8b[cb ??] |
5 | 22 22 22 51 01 (24/3/0) 89(61 40 19 13|61 40 19 13)01 42.00 03.09 1d.13 89.00 6b.00 19.00 a4.91[fb ??] |
6 | 22 22 22 51 01 (24/0/0) 89(61 40 19 13|61 40 19 13)01 3f.00 03.09 20.13 89.00 69.00 19.00 a4.d3[ad ??] |
7 | |
8 | 0x0142 = 32,2 V_PVA_AVG |
9 | 0x0003 = 0,3 I_PVA_AVG |
10 | 0x091c = 233,2 GridVol_AVG |
11 | 0x1389 = 50,01 GridFre_AVG |
12 | 0x0071 = 11,3 APower_AVG |
13 | 0x0018 = 2,4 AEnergy |
14 | 0x00a4 = 16,4 Temp_AVG |
Hoffe die Kommaverschiebungen habe ich richtig inerpretiert. Zu dem Zeitpunkt liefert der WR etwa 92mA und 6W Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so dokumentiert.
:
Bearbeitet durch User
Sehr cool Pocki! :) Damit alle Dokumente hier Hand und Fuß hat, würde ich mir wünschen statt alles in dem Forum zu Posten. Stattdessen auf Github zu laden, die Frage ist jedoch: Macht das Sinn? Beste grüße.
Christian P. schrieb: Super Christian! > 0x0018 = 2,4 AEnergy Das sollte 24Wh sein. D.h. MI-300 und MI-1500 wegen der Anzahl Ports anders anzusprechen, echt mühsam
Hallo, da ich die bisher immer nur stiller mitleser war habe ich mich jetzt endlich angemeldet. Ich habe einen Mi-600 und ich weis nicht ob ich hier was dazu beitragen kann. Zuerst hatte ich etwas schwierigkeiten den ESP8266 zum laufen zu bringen. Ich hatte die FW compiliert und geflasht und sah aber keinen acesspoint, auch der connect ins heimische wlan ging nicht (hatte es direkt beim compilieren schon mit rein) Ffertige .bin von hier probiert, die 0.4.11 und 0.4.13 mit selben Ergebniss. Die version 220519_ahoy_0.4.4_esp8266.bin hatte endlich funktioniert, und konnte auch auf die 0.4.13 upgraden... dabei war mir aufgefallen das die settings mit vielen yyyyyy gefüllt waren. Meine SN fängt mit 104161 an
Hallo Richard, also der letzte Update auf Github war vor ca 40min. An sich gibt es verschiedene wege wie man das ganze auf den ESP bekommt. Meines wissens nach ist der ganze Code noch nicht für den MI-Wechselrichter angepasst. Wäre es ein HM, dann wäre würde es schon besser klappen. Du musst dich noch ein bisschen gedulden für die MI-Serie, da neue Erkentnisse erlangt worden sind und das demnächst nach und nach weiter aufgebaut wird. ;) PS: yyyy sind übrigens nur "Platzhalter", die müsste man ersetzen.
:
Bearbeitet durch User
Jan-Jonas S. schrieb: > Theoretisch. Glaube der Gesetzgeber bzw. EVU will aber noch ein > Zertifikat sehen, dass das auch funktioniert. > Im Wesentlichen wird das EVU fordern bei Dir eine > Fern-Abschalteinrichtung einzubauen. > Physikalisches Limit != Software Limit. > Es ist halt ein trotziges Spielzeug aber gesetzeskonform kann so eine > DIY Frickelei ohne Siegel und Plombe eh nicht sein. Zumindest niemals in > Deutschland. Ausser vielleicht Montag morgens um 10 gehen in Berlin mal > wegen Unterproduktion die Computer aus. Hallo Jan-Jonas, das sehe absolut genauso. Die Herausforderung ist nicht die Software. Ich könnte meinem EVU sogar eine REST-API zur Fernabschaltung anbieten aber ich vermute wenn ich aktuell den vereinfachten Antrag ("600W") stelle mit: "Balkonanlage mit 2kwWp und Null-Export-Begrenzung" wird man damit nichts anfangen können und ggf. sagen, "...ja aber was ist mit der Blindleistung...". Selbst wenn ich das mit gekaufter Hardware mache. (Es gibt ja hier auch Nutzer von MI-1500, wie ist es hier gelaufen?) Ich frage mich daher, es gibt ja diese Funktion. Das wird dann wohl von großen Anlagen genutzt (+ Blindleistungsanpassung)? Hat da jemand Dokumente / Zertitikate von hoymiles die diese Regelungsfunktion laut Standard XY durch TüV, VDE o.ä. zertifizieren? Danke für Hinweise.
Konformitätszertifikat Erzeugungseinheit VDE AR-N-4105:2018-11 https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_EZE.pdf Konformitätszertifikat NA-Schutz VDE AR-N-4105:2018-11 https://machdeinenstrom.de/wp-content/uploads/2021/03/zertifikat-2018-Hoymiles_HM-250-800_VDE4105_2018_NA.pdf Nur das konnte ich finden. EDIT: Hier gibts von jedem Hoymiles-WR ein Zertifikat. https://www.shinetech-power.de/wechselrichter/hoymiles/
:
Bearbeitet durch User
Beitrag #7093597 wurde von einem Moderator gelöscht.
Daniel R. schrieb: > Konformitätszertifikat Erzeugungseinheit Das gilt aber nicht für das Gerät mit selbst geschriebener Software oder selbst gebastelten Teilen des Komplettsystems :)
Hallo Christian P., > Bingo - habe meinem MI-300 eine Antwort entlockt: Na das ist doch mal eine freudige Nachricht! > Ein Antwort-Paket mit 0x88 konnt ich nicht beobachten, obwohl im xlsx so dokumentiert. Das ist m.E. die Fehler Antwort, wenn der WR einige Events im Log hat, die man sich genauer ansehen soll. M.W. hat Jan-Jonas die Event Log Abfrage für die aktuellen HM-XXX Wechselrichter in der Raspberry Pi/Python Software bereits umgesetzt. @Christian P., Ziyat T. & Richard K., vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen ? Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das Programm an der Stelle zu testen / verifzieren.. Hallo Daniel R., > Damit alle Dokumente Hand und Fuß haben, würde ich mir wünschen - statt alles hier ins Forum zu Posten - es stattdessen auf Github zu laden. Die Frage ist jedoch: Macht das Sinn? Es gab diverse Meinungen dass es nicht unbedingt sinnvoll ist den OpenSource Code mit den Closed Source Dokumenten auf GitHub zu mischen. Aber es spricht sicher Niemand dagegen, wenn Du die Dokumente auf Deinem Github in einem separaten Repository ablegst.
isnoAhoy schrieb: > @Christian P., Ziyat T. & Richard K., > vielleicht könnt Ihr die entsprechenden 0x09, 0x11, 0x37..0x39 Kommandos > in der Raspberry/Python oder der ESP8266/C++ Variante selbst einpflegen > ? > Weder Jan-Jonas noch Lukas P. haben m.W. einen MI-Wechselrichter um das > Programm an der Stelle zu testen / verifzieren.. > Ich würde gerne die ESP8266+nrf24 / Arduino+nrf24 Variante für den MI-1500 einsetzen. Die SW-Staende kenne ich nicht (mehr). Ich weiss dass die SW komplett auf HM zugeschnitten sind, darum ich braeuchte eine "Anleitung", wo und wie ich die Kommandos eingeben kann, natürlich auch die Antworten zu parsen. Edit: hier sind die Kommandos/Antworten welche ich in der Luft gesehen habe. DTU-Pro<>MI1500 Daten ======================================================================== = Anfrage v. DTU-Pro: MID,WR,DTU,CMD PV1: ...36(63 70 71 60|72 22 84 12)00 PV2: ...37(63 70 71 60|72 22 84 12)00 PV3: ...38(63 70 71 60|72 22 84 12)00 PV4: ...39(63 70 71 60|72 22 84 12)00 Anworten v. MI-WR: MID,WR,WR,Data PV1: ...b6(63 70 71 60|63 70 71 60)data PV2: ...b7(63 70 71 60|63 70 71 60)data PV3: ...b8(63 70 71 60|63 70 71 60)data PV4: ...b9(63 70 71 60|63 70 71 60)data 36 00110110 > b6 10110110 bit8 gesetzt 37 00110111 > b7 10110111 bit8 gesetzt Limitierung ======================================================================== = Anfragen v. DTU-Pro: 51(63 70 71 60|72 22 84 12)5a 5a 0b 9e 0b = 11% power limitierung Anworten v. MI-WR: d1(63 70 71 60|63 70 71 60)5a 5a d1 51>d1 8 bit gesetzt #define CONTROL_LOCK_MI__LIMIT_POWER_ONOFF 0x51 //ŒÓËø&ÏÞÖƹŠÂÊ #define CONTROL_LOCK_MI_SUB 0xa5a5 #define CONTROL_LIMIT_POWER_SUB 0x5a5a #define CONTROL_ON_SUB 0x55aa #define CONTROL_OFF_SUB 0xaa55
:
Bearbeitet durch User
Hallo Ziyat T., ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80, MI-250/300/400 MID = 0x09, MI-600/700/800 MID = 0x09 & 0x11 sowie MI-1000/1200/1500 MID = 0x36..0x39 In der hmInverter.h müssen die Inverter Model ebenfalls mit getModel und setModel implementiert werden In der hmSystem.h kann man dann in addInverter das Protokoll in einem switch je nach Modellnummer setzen. Und dann kann man in der hmRadio.h die Methoden sendTimePacket den sendCmdPacket Aufruf anpassen mit case je nach Inverter getModel. Das Mapping der Inverter Daten erfolgt dann wieder über die in hmDefines zu definierenden byteAssign_t miXchAssignment[] und deren Länge Irgendwie müssen wir dem Code dann noch beibringen dass für die MI-Serien teilweise zwei/vier Cmd Pakete geschickt und ausgewertet werden müssen. Aber mit den og Anpassungen sollte es erstmal den ersten Kanal der MI-Modelle abfragen können. @Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei so was umzusetzen?
IsnoAhoy schrieb: > @Lukas P. habe ich irgendwas übersehen oder bist Du evtl. bereits dabei > so was umzusetzen? Nein bin ich nicht und habe es auch nicht vor. Ich fände es am besten, wenn man die Inverter Serie per template Parameter übergibt und sich damit vor dem kompilieren entscheiden muss. Weiter würde ich es bevorzugen die hm*.h Dateien zu duplizieren und als mi*.h umbenennen. Dann bekommen wir jetzt nicht ein riesen Chaos und ständige if-else-switch Konstrukte. In naher Zukunft kann man dann Gemeinsamkeiten suchen und diese wieder generisch anlegen.
:
Bearbeitet durch User
IsnoAhoy schrieb: > Hallo Ziyat T., > ich würde ein enum INV_PROTOCOL in der hmDefines.h anlegen für > HM-350/400/500/600/700/800/1000/1200/1500 MID = 0x15 + SUBCMD = 0x80, Danke, Habe die https://github.com/lumapu/ahoy/tree/main/tools/esp8266 runter geladen, ohooo, ist ja was implementiert worden. Muss sagen da blicke ich nicht einfach schnell durch. Ich habe die Version von April hier, mache mal damit weiter, ich muss ja zuerst sicher sein, was ich in der Luft sehe sollte auch implementiert werden und soll so laufen..
Hallo, ich habe mit großem Interesse diesen thread gelesen und mir die 4.4. Bin auf einem Wemos geflasht. Mir ist nur nicht klar was ich bei inverter Adress eintragen soll. Ich habe mehrere HM-300 die ich anfragen möchte. Irgendwie scheint die serial number ne Rolle zu spielen,aber wo finde ich die. Kann mir mal jemand auf die Sprünge helfen. Habe ich was überlesen?
Holger Skusa schrieb: > ...Irgendwie scheint die serial number ne Rolle zu spielen,aber wo > finde ich die. Die S/N der WR findest Du auf der Rückseite vom WR. Also auf der planen Seite.
Und diese Nummer ist dann bei Adress inverter einzutragen? Oder muss die noch irgendwie gewandelt werden?
normaler Weise so eintragen wie sie drauf steht. Ich würde dir empfehlen die aktuelle 0.4.17 zu installieren, die muss allerdings selbst kompiliert werden.
Hallo euch allen! Ich wollte euch allen, die an der großartigen Entwicklung beteiligt sind, danken. Ich bin ein stummer „Mitleser“ mit einem HM-300, der zufällig auf dieses Forum und die Topic stieß. Was „Elektrotechnik" angeht bin ich maximal Anfänger; Was Mikrocontroller angeht kompletter Laie und was Funk angeht mit noch weniger Fachwissen ausgestattet. Leider kann ich nicht so viel zur Programmierung beitragen, da ich auch hier komplett fachfremd bin und mir die Zeit momentan fehlt, mir das alles anzueignen. Dank euch und eurer tollen Dokumentation konnte ich das Projekt mittels eines „D1 mini“-clones und einem NRF24L01+PA+LNA (jetzt mit zusätzlicher „Schirmung“) realisieren. Funktionierte, wie dokumentiert, problemlos „out of the box“. Danke für euer Engagement! Ihr habt da „etwas Lust am Basteln" bei mir etwas geweckt ;-)
Angehängte Dateien:
-
ESP_DTU_Platine1.jpg
68 KB -
ESP_DTU_Platine2.jpg
130 KB -
ESP_DTU_Platine3.jpg
140 KB
Hallo zusammen, ich habe einige Platinen machen lassen. Wemos D1 mini und NRF24 zusammen auf einer Platine mit der Verdrahtung wie im GitHub beschrieben. Ich habe noch einige Platinen übrig und würde die für 2€ pro Stück abgeben. Einfach in ebay-Kleinanzeigen nach esp-dtu suchen...
Hallo zusammen, wollte auch ein Danke loswerden! also: DANKE! Geile Arbeit! Dickes Lob an die Community! Ich habe es jezt alles auf einem Nodemcu laufen. Meine PV Module sind noch nicht da, also hab ich dem HM-300 ans Labornetztteil gepackt. Wenn keine DC-Spannung anliegt geht das Funkmodul vom Umrichter nicht. AC muss aber nicht anliegen um das System zu testen. Gruß Ert
Hallo, ich wünschte ich könnte mich auch bedanken. Aber leider will es noch nocht so richtig. Ich habe die Serial Nummer meines HM-300 nun gefunden und in der 4.4 eingetragen. Leider kommen keine Daten. Nun versuche ich dem Tipp von Lukas zu folgen und die 4.17 zu kompilieren. Meine Arduino ide bricht aber immer mit: In file included from app.cpp:1:0: app.h:4:18: fatal error: RF24.h: No such file or directory #include <RF24.h> ab. HELP !!!
Die Library von Git maniacbug/RF24 hab ich installiert...
Mit der Arduino IDE 1.8.19 und - aus dem Boardverwalter ESP-Boards 3.0.2 (nicht 2.7.4) sowie den LIBRARIES - Time 1.6.1 - RF24 1.4.2 - PubSubClient 2.8 klappt es bei mir problemlos. Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt.
Beitrag #7095391 wurde von einem Moderator gelöscht.
Eine Frage, gab es auch schon Versuche Werte zu setzen so wie es die DTU Pro macht? Die kann ja den Output begrenzen bzw. ein "Country Protection File" hochladen (theoretisch braucht man das für den regelkonformen Betrieb)
Günter H. schrieb: > Die kompilierte 0.4.17 für einen Wemos D1 mini habe ich angehängt. Du bist mein Retter des Abends !!! Soeben habe ich meine ersten Werte empfangen. Das hat jetzt aber auch Stunden gekostet. Aber Danke für die Datei. Mit der Arduino IDE hab ich schon immer auf Kriegsfuss gestanden. Die mag mich irgendwie nicht. Ich hab die IDE nun ganz neu installiert und alle von Dir angegebenen Librarys installiert. Das Board nach installiert usw. Was soll ich sagen, nun geht auch das kompilieren. Na dann kann ich wenigstens zukünftige Versionen selber bauen. Vielen Dank an alle die das hier möglich gemacht haben. Klasse Sache !!! Eine Frage hab ich noch: Wie viele Inverter kann ein Wemos mit einem RF24 empfangen. Das ist ja im Sketch einstellbar. Ist da bei 3 Stück Schluss, oder würden auch 6 gehen ? Gruß Skusi, und allen einen schönen Wochenanfang...
Hallo Holger Skusa, also prinzipiell werden die WR nacheinander abgefragt, es wären also auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen: #define MAX_NUM_INVERTERS 3 https://github.com/grindylow/ahoy/blob/main/tools/esp8266/config.h#L33 Irgendwann wird halt der Speicher knapp und ich weiß noch nicht sicher, ob sich der Code problemlos auch auf einem ESP32 kompilieren läßt.
Hallo Alexander P., bitte schau mal in das letzte Excel File hier im Thread: * RF_communication_protocol-V6.5.xlsx (78,3 KB) dort sind die offiziellen Hoymiles Kommandos und Antworten dokumentiert. Damit ist es dieser Tage auch gelungen, die MI-Wechselrichter zum reden zu bringen. Auch die offizielle "Bibliothek" von Hoymiles ist hier im Thread: * usart_nrf.c (147 KB) dort habe ich beim Übersetzen auch die Power Profile und Firmware Upload Routinen gesehen. Wenn Du die Raspberry Pi/Python Software von Jan-Jonas verwendest, dann kannst Du u.a. über MQTT eigene Kommandos an den Wechselrichter senden. In der ESP8266 Variante ist eine derartige Option aktuell noch nicht vorgesehen. @Lukas P., hast Du evtl. vor eine derartige MQTT-Schnittstelle, o.a. zur Fernsteuerung der Wechselrichter einzubauen oder bist Du mit der reinen Auswertung der Daten soweit zufrieden ?
Hallo Oliver R., kannst Du das Platinen Layout evtl. noch im GitHub committen bzw. einen PR erstellen ? Ich glaube ich habe nur die Fritzing Layouts gemacht aber kein Layout hochgeladen. Danke!
Ziyat T. schrieb: > Hallo > Die Antwort > channel 3: b1 62 50 23 16 63 50 03 16 01 35 00 04 19 5b 13 8a 00 8d 0d > fa 01 3a 33 > Format ist exact was mein MI1500 auch schickt, hab sie schon decodiert. > D.h. dieser TSUN ist ein MI? > Konntest du schon einen request schicken und TSUN hat geantwortet? Hi, habe noch keine Requests rausbekommen. Dieser Part scheint mir auch defekt zu sein, da Abweichungen in den Bytes sind, z.B. die WR-Adresse im ersten Teil. Es könnte sein, dass der MI1500 mit dem TSUN ähnlich ist, auch die Chinesen erfinden nicht 3x das Rad neu. Bin jetzt erst von Montage wiedergekommen und schaue die Tage, was ich noch rauskriege.
isnoAhoy schrieb: > also prinzipiell werden die WR nacheinander abgefragt, es wären also > auch mehr als 4 möglich, einfach die Zeile in der config.h anpassen: Hallo, ich hab jetzt mit der Einstellung #define MAX_NUM_INVERTERS 6 kompiliert. Funktioniert aber nur bis 5 Stk ! Ab 6 Inverter startet der Wemos nicht mehr durch. In der Console meckert er: Settings not valid, erasing ... Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?
IsnoAhoy schrieb: > @Daniel M. und Ziyat T. vielleicht habt Ihr ja tatsächlich mehr Erfolg > wenn Ihr Eure Kommandos an den WR mit der „antiken“ MI DTU Seriennummer > versendet ? > > 10F052403668 -> 52403668 in Ahoy ESP bzw 68364052 in Euren Versuchen ? > > @Daniel M. ich glaube wir sind alle sehr gespannt auf Deinen nRF24 Code. > Wenn ich es richtig verstehe setzt Du nur das/die letzten Bytes also auf > 0x00000055 bzw 0x000000AA und empfängst dann praktische alle Nachrichten > auf dem Kanal 2403GHz. Ich kriege aktuell nichtmal ein Kommando raus, da ich mit Arduino noch nicht so fit bin und Python auch nicht gerade ein Küchenlicht ist. Meine Freundin ist immer erst ca. 19 uhr zuhause, da ist auch nicht mehr viel mit Code und Sonne, es zieht sich also etwas. Bin aber auch gespannt auf dem Code am Ende :) Eine Kurzanleitung, wie für den ESP die Kommandos zusammengesetzt werden, wäre hilfreich, Strom in allen Formen, Farben und Geschmacksrichtungen sind für mich kein Problem, aber Bytes schubbsen in C++ ist ne andere Geschichte. Seriennummern drehen hab ich mit dem anderen NRF-Chip ohne externe Antenne noch nicht getestet, mache ich die Woche noch. Ich hab noch nicht so ganz verstanden, was meine DTU zwischen dem was am NRF reinkommt und am Ende in der Luft landet, noch macht, da sind Unterschiede.
Holger S. schrieb: > #define MAX_NUM_INVERTERS 6 > > kompiliert. Funktioniert aber nur bis 5 Stk ! > Ab 6 Inverter startet der Wemos nicht mehr durch. > In der Console meckert er: > > Settings not valid, erasing ... > > Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ? Nein es gibt keine Limitierung auf 6 Stück. Ich glaube in main.cpp oä wird new EEP(1000) oä aufgerufen. Die 1000 ist die Länge des zugreifbaren Eeproms oder besser gesagt emuliertes Eeprom also Flash. Diese Zahl darf maximal 4096 sein. Zusätzlich muss in defines.h noch die Speicherposition vom SettingsCRC nach oben verschoben werden z.B. 1500
Hallo @Daniel M.,@IsnoAhoy, @Hubi Da ich schon früher Hubi's code verwendet habe, hab die letzte Git-Version von ihm angepasst/vergewaltigt;-) Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD) 36 63 70 71 60 72 22 84 12 00 37 63 70 71 60 72 22 84 12 00 38 63 70 71 60 72 22 84 12 00 39 63 70 71 60 72 22 84 12 00 oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts! nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an meine DTU-Pro, wenn sie eingeschaltet ist. Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde ein neues nrf24 besorgen und damit ausprobieren.
Ziyat T. schrieb: > Da ich schon früher Hubi's code verwendet habe, hab die letzte > Git-Version von ihm angepasst/vergewaltigt;-) > Ich sende (so wie meine DTU-pro):(MID,WR,DTU,CMD) Hi, das selbe an meiner Front gerade. D1 mini: 11 63 50 03 16 63 50 03 16 00 11 2E BA > oder auch andere MID&CMD's aus holymoly-gite-doku, empfange nichts! > nrf24 funktioniert, zumindest beim Empfang, ich sehe die WR-Antworten an > meine DTU-Pro, wenn sie eingeschaltet ist. > Also für mich bleibt nur noch der nrf24-Sender, ev. ist futsch, werde > ein neues nrf24 besorgen und damit ausprobieren. Futsch isser sicher nicht. Solange wir nicht klar sagen können, was unsere Außenseiter genau hören wollen, bleiben die für uns stumm. Die Scanner-Programme, die ich probiert habe, kriegen entweder nix (falsche Rx-Adressen) oder ich sehe z.B. in der originalen scanner-Anwendung der NRF-Libary aus den Beispielen nur die Kanäle wo was aufploppt, jedoch nicht was. Ich kann bisher nicht sagen, wie die CRC aufgebaut ist oder was genau durch die Luft gesendet wird. Morgen neuer Versuch, WR geht gleich schlafen :) Angepasst habe ich erstmal in der hmRadio.h:
1 | void sendTimePacket(uint64_t invId, uint32_t ts) { |
2 | //DPRINTLN(F("hmRadio.h:sendTimePacket"));
|
3 | sendCmdPacket(invId, 0x11, 0x91, false); |
4 | mTxBuf[9] = 0x00; // cid |
5 | mTxBuf[10] = 0x11; |
6 | //CP_U32_LittleEndian(&mTxBuf[12], ts);
|
7 | //mTxBuf[19] = 0x05;
|
8 | |
9 | uint16_t crc = crc16(&mTxBuf[10], 14); |
10 | mTxBuf[11] = (crc >> 2) & 0xff; |
11 | mTxBuf[12] = (crc ) & 0xff; |
12 | mTxBuf[13] = crc8(mTxBuf, 13); |
13 | |
14 | sendPacket(invId, mTxBuf, 14, true); |
15 | }
|
Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine geänderten Dateien?
Hallo Daniel M., also Du musst zwei Pakete senden, aber zwischendrin erstmal die Antwort abwarten: Probiere mal: 1. sendCmdPacket(invId, 0x09, 0x00, true); 2. laß den Rest der Routine unter sendTimePacket einfach mal weg. Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen timestamp oder gar eine CRC_16. Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true berechnet und angehängt wird sollte eigentlich genug sein. Er sollte dann z.B. folgendes Senden: D1 mini: >09< <52 40 36 68> <63 50 03 16> >00< 11 Hier ist die 11 ganz vorne die MID (s.o.) dann die sollte die Serien Nummer der DTU als Routing Addresse (hier die antike DTU 10F052403668) folgen und dann erst die Serien Nummer des WR als Target Adresse (Routing und Target Adresse ist offenbar bei den MI-Wechselrichtern vertauscht). Die 00 sind die User data und dann kommt nur noch die CRC_8 hier einfach mal 11 gelassen, sollte eigentlich richtig berechnet werden. Die Start und Stop-Bytes 0x7e und 0x7f hängt i.d.R. der nRF25L01+ automatisch dran. Als Antwort bekommst Du dann 0x88 (status) / 0x89 (data) ... Das selbe sollte auch mit 0x11 als MID funktionieren für den zweiten Kanal. Also Antwort kommt dann eben 0x91 (data?) / 0x92 (status?) ... Warum bei 0x11 die Reihenfolge von status und data umgekehrt sein soll, wissen vermutlich nichtmal die Hoymiles-Götter. Aber das Excel Sheet "RF_communication_protocol-V6.5.xlsx" widerspricht sich hier auch selbst. Vermutlich wurde es erst nachträglich korrigiert (rot auf "Data collection instructions" in Zellen B94 und B99) @Ziyat T., Für Dich gilt m.E. genau das selbe, lediglich sollte als MID 0x36..0x39 für die vier Kanäle verwendet werden. Als Antwort kommt dann 0xB6... .. 0xB9... (data & status) Viel Erfolg
Hallo Holger,
wie Lukas schon erwähnt hat in eep.h:
EEPROM.begin(4096);
und in den defines.h das Ganze gleich dynamisch gestalten:
#define ADDR_SETTINGS_CRC ADDR_NEXT + CRC_LEN
#if(ADDR_SETTINGS_CRC <= ADDR_NEXT)
#error address overlap!
#endif
#if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN)
#error EEPROM size exceeded! Configure less inverters?
#endif
@Daniel M. > Kannst du deine hmRadio.h und die app.cpp mal anhängen bzw. deine > geänderten Dateien? Wie gesagt, ich verwende Hubi's Code auf Arduino+nrf24, kein hmRadio.h,app.cpp @isnoAhoy > Das alte MI-Protokoll braucht m.E. weder ein 0x0b00 Subcmd, noch einen > timestamp oder gar eine CRC_16. > Die CRC_8 die am Ende von sendCmdPacket mit dem Parameter calcCrc = true > berechnet und angehängt wird sollte eigentlich genug sein. Welches ist das alte MI-Protokoll? bis zum MI-600? Meine DTU-Pro sendet zum MI-1500 ganz klar CMD 0x36 bis 0x39 mit SubCMD 0x00, CRC 0xFx, sonst nichts: 60 71 70 63 01 (11/3/0) 39(63 70 71 60|72 22 84 12)00 fd[67 ed] 60 71 70 63 01 (11/1/0) 38(63 70 71 60|72 22 84 12)00 fc[a2 51] Ich muss mal andere Kanaele nochmals lauschen, ob der WR was anderes braucht Ps: Könnten wir uns auf die Bezeichnungen CMD und SubCMD einigen?
:
Bearbeitet durch User
Vielen Dank isnoAhoy, ich werde das mal bei Gelegenheit so versuchen. Fließt das dann auch in die nächste Version mit ein ? Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten und den Namen ändern. Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.
Habe den Code von Hubi etwas angepasst: NRF24_SendRcv.ino:
1 | if (tel == 0) { |
2 | #ifdef ESP8266
|
3 | hmPackets.SetUnixTimeStamp (getNow()); |
4 | #endif
|
5 | size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); |
6 | }
|
7 | else if (tel == 1) |
8 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x89); |
9 | else if (tel == 2) |
10 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x91); |
11 | else if (tel == 3) { |
12 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x15, 0x83); |
13 | //tel = 0;
|
14 | }
|
15 | else if (tel == 4) |
16 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x09, 0x88); |
17 | else if (tel == 5) |
18 | size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x11, 0x92); |
19 | |
20 | SendPacket(dest, (uint8_t *)&sendBuf, size); |
21 | |
22 | tel++; |
Settings.h
1 | // WR und DTU
|
2 | #define DUMMY_RADIO_ID ((uint64_t)0xDEADBEEF01ULL)
|
3 | #define SerialWR 0x104163500316ULL // <<<<<<<<<<<<<<<<<<<<<<< anpassen
|
4 | uint64_t WR1_RADIO_ID = Serial2RadioID (SerialWR); // ((uint64_t)0x5279607201ULL); |
5 | #define DTU_RADIO_ID ((uint64_t)0x7311880801ULL)
|
Das Ergebnis:
1 | 20:19:58.728 -> Send... CH75 |
2 | 20:19:58.774 -> 00 7311880801 0092 12 1 92 63500316 63500316 000300000000000091D09E 1 |
3 | 20:19:58.774 -> ---- neues cmd=0 |
4 | 20:19:58.774 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 145.00 37328.00 53406.00 40502.00 13878.00 13981.00 |
5 | 20:19:58.774 -> analyse words:50331648.00 0.00 0.00 0.00 145.00 37328.00 9556126.00 2446368256.00 3500029440.00 2654353152.00 909548928.00 916290496.00 |
6 | |
7 | 20:20:03.760 -> 00 7311880801 0094 12 2 88 63500316 63500316 00030000000000008B7436 1 |
8 | 20:20:03.760 -> ---- neues cmd=0 |
9 | 20:20:03.760 -> analyse words:768.00 0.00 0.00 0.00 0.00 0.00 139.00 35700.00 29750.00 13867.00 11083.00 19437.00 |
10 | 20:20:03.760 -> analyse words:50331648.00 0.00 0.00 0.00 139.00 35700.00 9139254.00 2339649024.00 1949707136.00 908807168.00 726396352.00 1273878016.00 |
11 | |
12 | 20:20:49.802 -> 00 7311880801 00C0 18 0 91 63500316 63500316 012D0001095D1389003D085D00FFE550EF 1 |
13 | 20:20:49.802 -> P1.Udc :26.50 |
14 | 20:20:49.802 -> P1.Idc :238.27 |
15 | 20:20:49.802 -> P1.Pdc :3507.20 |
16 | 20:20:49.802 -> P2.Udc :1562.40 |
17 | 20:20:49.802 -> P2.Idc :238.08 |
18 | 20:20:49.802 -> P2.Pdc :6550.90 |
Log anbei. Die etwas anders aussehenden Zeilen sind aus dem Python-Mitschnitt und zeitlich relativ passend. Die Werte stimmen natürlich noch nicht, aber hey, der WR redet mit mir :) Der tel==3 Part passt noch nicht, wird aber offenbar nicht benötigt. Ein kleiner weiterer Schritt in die richtige Richtung. Danke Euch allen!
Holger S. schrieb: > Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen > Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem > Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate > ein neues Gerät zu bekommen. Das wurde einfach aus dem Beispiel der MQTT lib übernommen, schau mal in der mqtt.h relativ weit unten, der neue Name wird 'extra' erzeugt, warum kann ich nicht sagen, evtl. findet man bei PubSubClient (so heißt die lib) etwas darüber. Bei der nächsten Speicheränderung können wir den CRC wie isnoAhoy geschrieben hat noch weiter nach hinten schieben. Mit 6 WR bist du aktuell Spitzenreiter und musst sowieso selbst kompilieren. Bin gespannt ob das funktioniert. Ich glaube bis zu 4 wurden schon getestet.
Hallo, habe seit langem mal wieder den Code geupdated und vorher hat alles sehr gut funktioniert aber mit dem neusten update bekomme ich gar keine Daten mehr. Ich sehe nur noch
1 | Error while retrieving data: last frame missing: Request Retransmit |
2 | Error while retrieving data: last frame missing: Request Retransmit |
3 | Free heap: 0x430f8 |
4 | Inverter #0 no Payload received! (retransmits: 0) |
5 | Requesting Inverter SN val = 0x112173109025 |
Gerät wurde nicht bewegt (Antenne ist gleich) und vor dem update ging es tadellos. Habe einen HM-400. Hat noch jemand das Problem ? Vielen dank P.s.: Ich habe was gelesen, das man jetzt schon weit ist die Einspeisung zu kontrollieren ? Ist das korrekt ?
Hast du auch den Gegencheck mit der alten Version gemacht? Ich habe zugegeben auch immer wieder Probleme, aber ich denke es liegt sehr stark an der Umgebung und die ändert sich doch mehr als man es erwarten würde. Gestern habe ich den ESP unters Dach getragen und ständig mit Abstürzen zu helfen gehabt (Wifi?) und heute konnte ich wieder aus dem Keller funken (aber auch nur in einer exakten Ausrichtung). Liegt die Antenne bisschen anders bekomme ich keine Frames rein. Ich hoffe die Ausrichtung passt morgen noch ... Die Einspeisung zu reduzieren gilt bisher nur für die MI Serie - und dort wird grad heftig an der Kommunikation der ersten Daten geschraubt. Also bisher kann man noch keinen WR begrenzen.
:
Bearbeitet durch User
Daniel M. schrieb: > Habe den Code von Hubi etwas angepasst: > NRF24_SendRcv.ino: Gratuliere :-) Ich mache so, aber ohne erfolg: uint8_t MID = 0x36; //0xB9=0x39 0xB8 38 uint8_t CMD = 0; . . if (tel > 5) tel = 0; if (MID > 0x0039) MID= 0x0036; if (tel == 0) { #ifdef ESP8266 hmPackets.SetUnixTimeStamp (getNow()); #endif //do not need size = hmPackets.GetTimePacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8); } else size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, MID, CMD); SendPacket (dest, (uint8_t *)&sendBuf, size); MID++; tel++;
:
Bearbeitet durch User
Hallo Marcel A., bzgl Power Limitation würde ich Doch auf das o.a. Excel Sheet "RF_communication_protocol-V6.5.xlsx" verweisen. Da steht mE alles drin was in der DTU Pro an Request und Response von MI-&HM-Wechselrichtern verstanden und gesendet wird. U.a. sind da auch die Kommandos zur Power Limitierung auf X % enthalten. Speziell auf der Seite „control commands“ findet sich das Limit Power command word 0x51 subcommand 0x5A5A und die Antwort 0xD1. Die Implementierung der Kommandos von Hoymiles dazu findest Du in der o.a. usart_nrf.c (147 KB). @Ziyat T. und Daniel M., ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer noch ein Timestamp mitgesendet zu werden. Laut der Command Word Summary sind die Commands words (früher hier MID) für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11 (optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse MI-1000..1500) Das Command word für die HM-Serie ist durchweg 15 und die Antwort 95. Bitte schaut Euch doch mal die Screenshots aus dem Excel bzw. die entsprechenden Command words auf der Seite „data collection instructions“ unterhalb der Zeile „Legacy poll data command“ an. Dort ist nach der Target Address nur noch das Subcommand / Userdata 00 und die CRC-8, aber kein Timestamp wie beim Command word 15 für die HM-Serie.
Hallo zusammen, auch wenn es nicht ganz zum aktuellen Stand der Unterhaltungen hier im Forum passt: Nachdem ich mehrere Stunden an mehreren Tagen verzweifelt probiert habe die NRF24 Python Library, also die Dependency für die Raspberry Version von Ahoy, korrekt zu installieren, habe ich mich gestern direkt an den Entwickler von NRF24 über github gewendet (https://github.com/nRF24/RF24/issues/845) - da ich, egal wie ichs gedreht und gewendet bekommen habe, den Python Wrapper für NRF24 nicht installiert bekommen habe. Ich würde gerne meine Schritte weitergeben, sollte jemand an dem selben Punkt verzweifelt sein wie ich. - Install Raspberry Pi OS lite x86 with raspberry pi imager - Connect nrf24 module to raspberry pi (as described in github) - Login with user pi - Execute "sudo apt update && sudo apt -y upgrade" - Execute "sudo raspi-config" and -- "Expand filesystem" in "Advanced Options" -- Activate "SPI" in "Interface Options" -- "Finish" to exit raspi-config Tool, reboot YES! - Login as pi user again
1 | sudo apt install cmake git python3-dev libboost-python-dev python3-pip python3-rpi.gpio |
2 | sudo ln -s $(ls /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3*.so | tail -1) /usr/lib/$(ls /usr/lib/gcc | tail -1)/libboost_python3.so |
3 | git clone https://github.com/nRF24/RF24.git |
4 | export RF24_DRIVER=SPIDEV |
5 | cd RF24 |
6 | rm Makefile.inc #just to make sure there is no old stuff |
7 | mkdir build && cd build |
8 | cmake .. |
9 | make |
10 | sudo make install |
11 | cd ../pyRF24 |
12 | rm -r ./build/ ./dist/ ./RF24.egg-info/ ./__pycache__/ #just to make sure there is no old stuff |
13 | python3 -m pip install --upgrade pip |
14 | python3 -m pip install . |
15 | python3 -m pip list #watch for RF24 module - if its there its installed |
16 | cd .. |
17 | cd examples_linux/ |
18 | python3 getting_started.py # to test and see whether RF24 class can be loaded as module in python correctly |
Wenn im letzten Schritt keine Fehlermeldungen kommen, dann sollte der NF24 Wrapper erfolgreich installiert sein. Danke euch allen für eure Arbeit :)
:
Bearbeitet durch User
IsnoAhoy schrieb: > @Ziyat T. und Daniel M., > ich kenne den Code von Hubi nicht wirklich gut aber dort scheint immer > noch ein Timestamp mitgesendet zu werden. > Laut der Command Word Summary sind die Commands words (früher hier MID) > für die MI Wechselrichter 09 (erster MPPT Anschluss MI-250..500) und 11 > (optionaler zweiter Anschluss MI-600..800) bzw. 36-39 (vier Anschlüsse > MI-1000..1500) Die 0x09 und 0x11 mit den Antworten 0x88,0x89 sowie 0x91 unx 0x92 sind beim TSUN identisch mit dem was ich aus der MI-Serie gesehen habe. Offenbar haben die Chinesen einfach das MI-Modell kopiert. Der Timestamp wird gesendet, die Funktion bewirkt aber garnichts, der WR ignoriert das einfach. Hubi verwendet einfach ein i++ um den CMD hochzuzählen und entsprechende Abfragen zu schicken, zu sehen in dem Post weiter oben. Die passende pid für die Antwort wird gleich mitgegeben. Mittlerweile hab ich auch die Felder zu den Antworten passend gemappt. Der Part nach der WR-Temperatur fehlt mir noch, ich bin nicht sicher ob das CRC16 oder noch Werte sind, da mit die Gesamtproduktion der MPPT noch fehlt. Weiter fehlen auch noch die Statusbytes. Vielleicht kriege ich das heute abend noch hin. > Probiere mal: > 1. sendCmdPacket(invId, 0x09, 0x00, true); > 2. laß den Rest der Routine unter sendTimePacket einfach mal weg. Der Teil ist mir ehrlich gesagt, zu hoch. Ich weiß nicht an welcher Stelle ich das einfügen soll. Wenn du mir da kurz auf die Sprünge hilfst, teste ich das gerne. Eventuell kannst du auch kurz was zaubern, womit ich 0x09 und 0x11 im Wechsel senden kann, dann probier ich mich mit dem Einbau daran aus.
Hallo, die Platinen sind wahrscheinlich schon weg oder? Konnte leider nichts finden und könnte 3 Stück gebrauchen. Danke und Gruß
Hallo Daniel M., ja, der TSUN scheint nur ein rebrandeter Hoymiles MI-Wechselrichter zu sein. Das hatten wir aufgrund der Seriennummer auch schon vermutet. Meine Angaben bezogen sich auf den code von Lukas unter tools/esp8266 da ich den Rest für Nano und die nrfScan tools von Hubi und anddren nie genutzt habe. Speziell bezog sich 1. & 2. auf die hmRadio.h Zeile 162ff https://github.com/grindylow/ahoy/blob/e05d2220cb1f99bbbf4083d62b0281d096ceeccb/tools/esp8266/hmRadio.h#L162
Hallo Daniel M., habe mir den code nochmal genauer angesehen und vermutlich kannst Du die beiden Aufrufe von sendTimePacket und die anderen Aufrufe von sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe ersetzen und anpassen. app::loop Ab Zeile 295ff kommt die Senderoutine: https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L339 app::processPayload hier erfolgt das Lesen und Sammeln der Payload Fragmente und der bisher HM spezifische Retransmit: https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/app.cpp#L413 Im zweiten Teil dem processPayload könntest Du also nach Empfang der ersten Antwort 0x89 die zweite Anfrage 0x11 stellen und auf die Antwort 0x91/0x92 warten. Dann solltest Du die Antworten jeweils in den Variablen/Strukturen ablegen und mit den Definitionen in miDefines.h (Kopie von hmDdfines.h) auslesen.
Angehängte Dateien:
-
2022-06-16-A.jpg
69 KB -
2022-06-16-A1.jpg
48 KB
nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden
Angehängte Dateien:
Guten Morgen! Leider bin ich noch Anfänger auf dem Gebiet, habe mich aber an einem PCB-Design versucht, welches ich hier angehängt habe (habe keinen Github-Account; kann bei Gefallen gerne dort übernommen werden). Designt mit EasyEDA; Ich habe versucht, Platinenplatz einzusparen und gleichzeitig auch noch die Pins nochmals anzulegen (für weitere Spielereien wie 5/3,3v externe Stromversorgung ohne Löten etc). Ebenfalls habe ich den 100µF (oder andere Größe nach Belieben; das µ wollte mir das Programm nicht auf das Board beschriften ;-)) Kondensator zwischen GND und 3,3v auf das Board gepackt. Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€. Verbesserungsvorschläge gerne willkommen
oxylog schrieb: > Geordert habe ich die Boards gestern bei Aisler für knapp unter 10€. kleiner Edit: 3 Boards habe ich bei Aisler für unter 10€ geordert
Hallo, ich habe ein Problem mit meiner ide. Ich bin weit weg von zu Hause und kann es nicht lösen. Könnte jemand bitte hier eine bin-Datei mit der neuesten Version für ESP anhängen. Danke im Voraus
Für das Wemos D1 mini-Board ist das hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Daniel R. schrieb: >
1 | sudo python3 -um hoymiles --log-transactions --verbose --config |
2 | > from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, |
3 | > RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16 |
4 | > ImportError: |
5 | > /usr/local/lib/python3.7/dist-packages/RF24.cpython-37m-arm-linux-gnueabihf.so: |
6 | > undefined symbol: _ZN4RF2410setPALevelEh |
7 | > |
Sieht nach einer kaputten Installation des RF24-Moduls aus. Warte noch ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01, was man einfach komplett mit pip installieren kann. Kein fuckery mehr mit irgendwelchen selbst kompillierten blobs im System verteilen, die nur kompillieren, wenn man sie im richtigen Unterverzeichnis kompilliert. ``` ModuleNotFoundError: No module named 'cross.crossunixccompiler' ```
Ameise schrieb: > nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden Da hat sich ja die Arbeit der Community gelohnt…
IsnoAhoy schrieb: > Hallo Daniel M., > > habe mir den code nochmal genauer angesehen und vermutlich kannst Du die > beiden Aufrufe von sendTimePacket und die anderen Aufrufe von > sendCmdPacket in app.cpp durch die MI-spezifischen sendCmdPacket Aufrufe > ersetzen und anpassen. Hi, Danke, ich versuche es mal die kommenden Tage. Mit etwas experimentieren habe ich zumindest schonmal eine Payload gesehen, auch wenn das noch nicht zuverlässig geklappt hatte. Deine Hinweise auf die Stellen schaue ich mir genauer an, an einigen Stellen war ich schon dran.
Meine ESP-Version 4.17 hat ein Problem, ich kann es nicht anpingen, das www funktioniert nicht, manchmal ist es 2 Minuten nach dem Start. Mir ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1 Sekunde aktualisiert wird, ist das richtig?
Ameise schrieb: > nur zur Info: Habe ich bei ebay-kleinanzeigen gefunden Sauerei, das sich da wieder jemand dran bereichern muß. Kann man da nix gegen machen ? Pfui ! von mir...
Ein paar Fragen: Wenn ich in der config.h folgendes eintrage: // fallback WiFi info #define FB_WIFI_SSID "Flackerlighter" #define FB_WIFI_PWD "meinPasswort" 1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem WLan auf ? Console: Main::setupStation connect to network '⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮ ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮' ... ............................... ........................................................................ ............................ Main::setupAp --------- AP MODE SSDI: AHOY-DTU PWD: esp_8266 Active for: 60 seconds --------- 2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert verwendet ? 3. Wie genau sind die Statistic Werte zu verstehen: Receive success: 18 Receive fail: 17 Send Cnt: 128 sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ? Gruß Skusi
isnoAhoy schrieb: > Hallo Holger, > wie Lukas schon erwähnt hat in eep.h: > EEPROM.begin(4096); > > und in den defines.h das Ganze gleich dynamisch gestalten: > > #define ADDR_SETTINGS_CRC ADDR_NEXT + CRC_LEN > > #if(ADDR_SETTINGS_CRC <= ADDR_NEXT) > #error address overlap! > #endif > > #if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN) > #error EEPROM size exceeded! Configure less inverters? > #endif Hallo isnoAhoy, ich habe die Änderungen so in die Dateien eingepflegt, aber sobald ich mehr als 4 inverter in die config.h eintrage bootet der Wemos nicht und sendet. Settings not valid, erasing ... ???
Holger S. schrieb: > Sauerei, das sich da wieder jemand dran bereichern muß. > Kann man da nix gegen machen ? > > Pfui ! von mir... Kannst du ausschließen dass jemand die Software selbst entwickelt hat?
Jan-Jonas S. schrieb: > Warte noch > ne Woche, dann unterstützen wir auch das circuitpython-nrf24l01 Moin Jonas, danke für die Antwort. :) Ok, du bist schon dabei das ganze miteinander zu kombinieren? Kann ich irgendwie helfen? Mein Ziel ist es zukünftig alles direkt am Pi zu betreiben. Dann brauch ich nicht extra noch ein WiFi-Client ins Netz zu halten. :P
Damian B. schrieb: > Mir ist aufgefallen, dass die Betriebszeit und NTP alle 5 Sekunden statt 1 > Sekunde aktualisiert wird, ist das richtig? ja, das hat isnoAhoy geändert und führt bei uns zu stabileren Systemen. Es hängt jetzt fix am Abfrageintervall, die Zeit wird sogar auf der Index Seite ausgegeben (also wie lange das Intervall ist)
Holger S. schrieb: > 1. Wieso baut der Wemos dann nach dem Flash keine verbindung zu meinem > WLan auf ? Habe es selbst nie getestet, nur implementiert. Evtl findest du den Fehler? > 2. Was tragt man bei Max Module Power (Wp) ein und wozu wird der Wert > verwendet ? Die kWp der angeschlossenen Module. Hiermit wird die Einstrahlung in Prozent berechnet, ganz interessant um zu wissen wie optimal deine einzelnen Module stehen. > 3. Wie genau sind die Statistic Werte zu verstehen: > Receive success: 18 > Receive fail: 17 > Send Cnt: 128 > > sind die fails normal, oder kann man die im Besten Fall auf 0 bekommen ? Success heißt die komplette Payload wurde empfangen. Fail sind dementsprechend die fehlgeschlagenen Payloads. SendCnt sind alle gesendeten Frames, auch Retransmits. In besten Fall wäre success und SendCnt identisch und fail auf 0.
Einhart P. schrieb: > Holger S. schrieb: >> Sauerei, das sich da wieder jemand dran bereichern muß. >> Kann man da nix gegen machen ? >> >> Pfui ! von mir... > > Kannst du ausschließen dass jemand die Software selbst entwickelt hat? Kann man nicht, aber sie wird sehr sicher auf unseren Erkenntnissen aufbauen. Wie sieht es denn lizenztechnisch hier aus? Ich denke ua., dass Christian Bauer hier auch mitliest. @Jan-Jonas: Ich glaube du bist auf diesem Gebiet fit, was sollen wir für die (nahe) Zukunft machen? Für mich sieht es so aus als würde sich jemand mit unserem Wissen zu bereichern, irgendwie arm, hoffentlich ein Einzelfall. Bei einem Preis von 10€ könnte man nichts sagen, aber hier ist eine Marge von 40€ veranschlagt. Der kostenlose Support wird von Mikrokontroller.net geleistet oder wie?
:
Bearbeitet durch User
Hallo Holger S., ja das ist erstmal richtig, Du hast ja eine größere Config und die CRC Summe ist weiter nach hinten gerutscht, somit stimmt das nicht mehr und er löscht alle Settings (außer den WiFi Settings). Du mußt dann im Setup die Wechselrichter Daten wieder eintragen. Ich glaube da gab es ein Problem, daß er aktuell keine sinnigen Default Werte einträgt sondern alles mit 0xFF auffüllt. D.h. Du mußt Alles in den Settings entfernen und nur die relevanten Teile eintragen. Da auch die Pin Settings fehlen kann er auch keinen nRF24 finden und startet immer wieder neu bzw. den Access Point. Du kannst auch mal die folgenden u.a. Einträge mit #pragma error versuchen, vielleicht bekommst Du dann auch etwas mehr Debug Output. Ich weiß nämlich ehrlich gesagt nicht, wieviele Bytes eine Inverter Config groß ist ? #define INV_CH_CH_NAME_LEN MAX_NUM_INVERTERS MAX_NAME_LENGTH 4 // (4 channels) Laut der defines.h reserviert er immer vier Kanalnamen plus den Inverternamen à 16 Byte, also 5*16 Byte. Das sollten bei ca. 200 Byte für die WIFI und MQTT Settings ca. 100 Byte mal sechs Inverter weit unter 4096 sein. #define ADDR_SETTINGS_CRC ADDR_NEXT + CRC_LEN #if(ADDR_SETTINGS_CRC <= ADDR_NEXT) #pragma error "address overlap! (ADDR_SETTINGS_CRC="+ ADDR_SETTINGS_CRC +", ADDR_NEXT="+ ADDR_NEXT +")" #endif #if(ADDR_SETTINGS_CRC >= 4096 - CRC_LEN) #pragma error "EEPROM size exceeded! (ADDR_SETTINGS_CRC="+ ADDR_SETTINGS_CRC +", CRC_LEN="+ CRC_LEN +")" #pragma error "Configure less inverters? (MAX_NUM_INVERTERS=" + MAX_NUM_INVERTERS +")" #endif PS: Support-Anfragen der Käufer solange unsere Software noch so schöne Macken wie "Settings not valid, erasing ..." hat sind da bestimmt schon inklusiv =^p
So das Angebot in Kleinanzeigen ist deaktiviert, Dank meiner Frau. Evtl. sollten wir zusätzlich diese Lizenz aufnehmen um unsere Belange besser auszudrücken: https://commonsclause.com/ Wir machen das hier für die Community, also Maker und nicht für jedermann. Alle anderen sollen bei hoymiles eine DTU kaufen.
Einhart P. schrieb: > Holger S. schrieb: >> Sauerei, das sich da wieder jemand dran bereichern muß. >> Kann man da nix gegen machen ? >> >> Pfui ! von mir... > > Kannst du ausschließen dass jemand die Software selbst entwickelt hat? Das Gehäusedesign stammt jedenfalls von mir. https://github.com/grindylow/ahoy/tree/main/tools/esp8266/WemosD1_NRF24_Case
@Jan-Jonas & Lukas
the current implementation we use for HM-inverters seems to be in the
Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or
`usart_nrf3.h`.
There are also the user data starting with `0x80` in `byte[10]` and
after that the Sub Command mentioned in the Excel sheet.
```
/***********************************************
** Function name: �豸����
** Descriptions:
** input parameters: ?
** output parameters: ?
** Returned value: ?
*************************************************/
uint8_t UsartNrf3_Send_PackDevControl(uint8_t *target_adr, uint8_t
*rout_adr, uint16_t ControlMode, uint8_t *ControlData, uint8_t Num)
{
uint8_t i = 0;
uint16_t TempCrc = 0;
uint8_t temp_dat[UART_LEN];
uint16_t DatCrc = 0xffff;
memset(temp_dat, 0, sizeof(temp_dat));
Uart_SendBuffer[0] = STX;//ͷ
temp_dat[0] = DEVCONTROL_ALL; //command
memcpy(&temp_dat[1], target_adr, 4);//Դ��ַ
memcpy(&temp_dat[5], rout_adr, 4);//Ŀ���ַ
temp_dat[9] = 0x80;//
temp_dat[10] = ControlMode >> 8; //��������
temp_dat[11] = ControlMode;//��������
//CurSendPackageDataType = ControlMode;
memcpy(&(temp_dat[11]), ControlData, Num); //���Ʋ���
for(i = 10; i < 11 + Num + 1; i++)
{
if((i - 10) % 2 == 1)
{
TempCrc = (temp_dat[i - 1] << 8) | (temp_dat[i]);
DatCrc = CalcCRC16t(TempCrc, DatCrc);
}
}
temp_dat[12 + Num] = DatCrc >> 8;
temp_dat[13 + Num] = DatCrc;
temp_dat[14 + Num] = Get_crc_xor(&temp_dat[0], 15 + Num);
i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], (15 +
Num)); //�����滻
Uart_SendBuffer[(i + 1)] = ETX; //β
memset(temp_dat, 0, sizeof(temp_dat));
return (i + 2);
}
```
According to the implementation in `usart_nrf3.h` the Sub Command is
defined as `DataType` in `usart_nrf3.h`:
```
typedef enum
{
InverterDevInform_Simple = 0, // 0x00
InverterDevInform_All = 1, // 0x01
GridOnProFilePara = 2, // 0x02
HardWareConfig = 3, // 0x03
SimpleCalibrationPara = 4, // 0x04
SystemConfigPara = 5, // 0x05
RealTimeRunData_Debug = 11, // 0x0B
RealTimeRunData_Reality = 12, // 0x0C
RealTimeRunData_A_Phase = 13, // 0x0D
RealTimeRunData_B_Phase = 14, // 0x0E
RealTimeRunData_C_Phase = 15, // 0x0F
//RealTimeRunData_Password = 16, // 0x10
AlarmData = 17, // 0x11
RecordData = 18, // 0x12
InternalData = 19, // 0x13
ExternalData = 20, // 0x14
} DataType;
```
Especially the 0x0B rings a bell with me and the traces so far!
Sorry that was the wrong function / method and the references in the
Excel sheet e.g. `byte[10]` are including the SOF `0x7E`, whilst the
implementation first sets up `temp_dat[]` which is without the SOF and
EOF `0x7F`, hence the shift.
```
/***********************************************
** Function name: �豸������Ϣ���
** Descriptions:
** input parameters: ?
** output parameters: ?
** Returned value: ?
*************************************************/
uint8_t UsartNrf3_Send_PackDataCommand(uint8_t *target_adr, uint8_t
*rout_adr, uint8_t DataType, uint8_t DataMode, uint8_t Gap, uint8_t
*Password)
{
uint8_t i = 0;
uint16_t TempCrc = 0;
uint8_t temp_dat[UART_LEN];
uint16_t DatCrc = 0xffff;
memset(temp_dat, 0, sizeof(temp_dat));
Uart_SendBuffer[0] = STX;//ͷ
temp_dat[0] = 0x15; //command
memcpy(&temp_dat[1], target_adr, 4);//Դ��ַ
memcpy(&temp_dat[5], rout_adr, 4);//Ŀ���ַ
temp_dat[9] = 0x80;//��֡��ʶ
temp_dat[10] = DataType;//�û�����:��������
CurSendPackageDataType = DataType;//��ǰ�������������
temp_dat[11] = DataMode;//�û�����:����ģʽ
//
memcpy(&(temp_dat[12]),&(RTC_GetWorldSecond(Dtu3Detail.Property.timezone
)),4);//�û�����:��ͬ��ʱ��
temp_dat[12] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >>
24;
temp_dat[13] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >>
16;
temp_dat[14] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone) >>
8;
temp_dat[15] = RTC_GetWorldSecond(Dtu3Detail.Property.timezone);
//RTC_GetWorldSecond(Dtu3Detail.Property.timezone);
temp_dat[16] = Gap;//�û�����:�����ϴ����������
temp_dat[17] = Gap >> 8;
memset(&(temp_dat[18]), 0, 2); //�û�����:���������յ��ĸ澯���
memcpy((&temp_dat[20]), Password, 4); //�û�����:��������
for(i = 10; i < 24; i++)
{
if((i - 10) % 2 == 1)
{
TempCrc = (temp_dat[i - 1] << 8) | (temp_dat[i]);
DatCrc = CalcCRC16t(TempCrc, DatCrc);
}
}
temp_dat[24] = DatCrc >> 8;
temp_dat[25] = DatCrc;
temp_dat[26] = Get_crc_xor(temp_dat, 26);
i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 27);
//�����滻
Uart_SendBuffer[(i + 1)] = ETX; //β
memset(temp_dat, 0, sizeof(temp_dat));
return (i + 2);
}
```
Holger S. schrieb: > Ab 6 Inverter startet der Wemos nicht mehr durch. > In der Console meckert er: > > Settings not valid, erasing ... > > Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ? Habe den Fehler soeben gefunden und gefixt. Für die es interessiert: Wenn man in Macros addiert und subtrahiert muss man sich klar machen, dass alles expandiert wird. Gewollt war z.B. (2+2+4+5)-(2+4) es wurde aber 2+2+4+5-2+4 berechnet. Es waren einfach zwei Klammern um `ADDR_NEXT` und `ADDR_START_SETTINGS` nötig, da sonst die Länge des Blocks falsch berechnet wird. Mal wieder ein Wunder, dass es überhaupt bisher funktioniert hat. Hier die betroffene Zeile (existiert ähnlich auch nochmal in main.cpp:130) https://github.com/grindylow/ahoy/blob/0347a3df44d77952524666794c888e6ef4693e45/tools/esp8266/app.cpp#L855
:
Bearbeitet durch User
According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:
```
#define DEVCONTROL_ALL 0x51
#define ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80)
```
Hence the `UsartNrf3_Send_PackDevControl` method above is actually very
much the same as the `CONTROL_LOCK_MI__LIMIT_POWER_ONOFF` for the legacy
Gen 1 or 2 MI-inverters. The answer will be starting with Command `0xC1`
or `ANSWER_DEVCONTROL_ALL`. This can be used to set various settings in
HM-inverters e.g. the "sinus" wave `pWaveData = mymalloc(1200 *
sizeof(uint8_t));` being recorded.
The main routine is in `UsartNrf3_Send_NetCmdToNrfCmd` where all the
commands and subcommands are defined:
```
/***********************************************
** Function name: ��������ת��Ϊ����Э��nrfָ��
** Descriptions:
** input parameters: ?
** output parameters: ?
** Returned value: ?
*************************************************/
// Type_ReactivePowerContr = 12,
// Type_PFSet = 13,
// Type_CleanState_LockAndAlarm = 20,
void UsartNrf3_Send_NetCmdToNrfCmd(void)
{
if((CurNetCmd >= NET_TURN_ON) && (CurNetCmd <= NET_RESTART))
{
switch(CurNetCmd)
{
case NET_INVERTER_HW_INFOR:
case NET_TERMINAL_INFOR:
SubCmd = InverterDevInform_All;
MainCmd = REQ_ARW_DAT_ALL;
break;
case NET_TURN_ON:
SubCmd = Type_TurnOn;//����
MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
break;
case NET_TURN_OFF:
SubCmd = Type_TurnOff;//�ػ�
MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
break;
case NET_LIMIT_POEWR:
SubCmd = Type_ActivePowerContr;//���ƹ���
MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
break;
case NET_DOWNLOAD_PRO:
MainCmd = DOWN_PRO;
SubCmd = Type_Init;
break;
case NET_DOWNLOAD_DAT://���������ļ�
MainCmd = DOWN_DAT;
SubCmd = Type_Init;
break;
case NET_RESTART: //���س���/��λ
MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
SubCmd = Type_Restart;
break;
case NET_UNLOCK:
SubCmd = Type_Unlock;
MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
break;
case NET_LOCK:
SubCmd = Type_Lock;
MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
break;
default:
break;
}
}
else if(CurNetCmd == NET_INIT)
{
SubCmd = RealTimeRunData_Reality;
MainCmd = REQ_ARW_DAT_ALL;
}
else if(CurNetCmd == NET_ALARM_DATA)
{
MainCmd = REQ_ARW_DAT_ALL;
SubCmd = AlarmData;
}
else if(CurNetCmd == NET_RECORD_DATA)
{
MainCmd = REQ_ARW_DAT_ALL;
SubCmd = RecordData;
}
}
```
where the Sub Commands are of `DevControlType`
```
typedef enum
{
Type_TurnOn = 0, // 0x00
Type_TurnOff = 1, // 0x01
Type_Restart = 2, // 0x02
Type_Lock = 3, // 0x03
Type_Unlock = 4, // 0x04
Type_ActivePowerContr = 11, // 0x0B
Type_ReactivePowerContr = 12, // 0x0C
Type_PFSet = 13, // 0x0D
Type_CleanState_LockAndAlarm = 20, // 0x14
Type_Init = 0xff, // 0xFF
} DevControlType;
```
The AlarmDataType can store up to 50 Alerts as far as I could tell from
the `UsartNrf3_Process_DevInform_Alarm` method.
BTW: The most recent version of the Gen3 protocol can be found in
hoymiles-DTU-PRO-GPRS/User/NRF/usart_nrf3.c accompanied by the
NetProtocol.c and AntiBackflow.c/.h
This implementation is more detailed than the ones under the 0.0.2 and
0.0.1-20191115 Release directories.
Find attached the latest Test Report that came with the gitee repo. It
has the following hint on this code line in NetProtocol.c:
> Enter the super password 10165082, you can change the password
```
else if(Password_old == 10165082)
```
Hallo Lukas,
> Settings not valid, erasing ...
gratuliere ein weiteres Problem behoben!
Da muß man auch erstmal drauf kommen in Zeile 130 und 855 noch
zusätzliche Klammern zu setzen. Man könnte auch die Summen-Ausdrücke in
den #Defines bereits in Klammern setzen, dann kann man sich auch in
Zukunft nicht mehr verrechnen =^}
Guten Morgen ! Wollte einfach nur mal ein Danke an die Nachtaktiven da lassen !
Grüezi mitenand, es gibt anscheinend noch eine etwas neuere Version von usart_nrf3.c (hoymiles-DTU-PRO-APP/User/NRF/usart_nrf3.c) in folgendem repository: https://gitee.com/iotloves/hoymiles-DTU-PRO.git
Moin zusammen, bin aktuell noch Unterwegs seit einer Woche. Melde mich wenn ich wieder Zuhause bin. PS: Cool wie Ihr es bisher geschaft habt. Beste Grüße Daniel :)
Mel Yoshi schrieb: > Grüezi mitenand, > > es gibt anscheinend noch eine etwas neuere Version von usart_nrf3.c > (hoymiles-DTU-PRO-APP/User/NRF/usart_nrf3.c) in folgendem repository: > > https://gitee.com/iotloves/hoymiles-DTU-PRO.git Moin, wenn ich dort schauen will, bekomme ich die Meldung, dass das Repo für unregistrierte Benutzer gesperrt ist. War das schon länger so oder ist das frisch? lg :)
Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy Version aufgegeben, weil dort das multiple messages handling schon funktioniert ... und habe dort das von mir benötigte json format für matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR damit erstellen). Was mir aber auffällt ist, dass die Werte alle immer wieder Ausreißer (0 oder mehrere zehntausend) haben ... ich habe versucht das im Code abzufangen und nur "gültige" Werte zu publishen, aber das funktioniert nur mäßig gut, weil es immer wieder unterschiedliche Werte betrifft. Ich hatte eigentlich gemeint, dass der CRC das verhindern sollte? Kann es sein, dass es ein Problem unterschiedlicher threads bzw Kontexte ist (also dass ein RX IRQ schon Daten überschreibt, während der MQTT Teil noch am versenden ist?
Mel Yoshi schrieb: > Grüezi Daniel M., > > versuch mal: > git clone https://gitee.com/iotloves/hoymiles-DTU-PRO.git Grüezi wohl Mel Yoshi Bei mir gehts auch nicht, kannst du das neue usart_nrf3.c hier anhaengen bitte? Danke
Nein, der ESP8266 hat nur einen Core und der IRQ setzt nur ein boolean. Daher ist hier eine Nebenläufigkeit ausgeschlossen. Zudem wird die Payload in einen extra Datenbereich kopiert und erst dann gepublished. Bei mir läuft die Kommunikation schon immer ohne Ausreißer, die einzigen kommen von Wetter, zB. bei gemischter Bewölkung. Welchen WR hast du? Der einzige, der hier Probleme machen könnte wäre der HM600
Lukas P. schrieb: > Welchen WR hast du? Der einzige, der hier Probleme machen könnte wäre > der HM600 ich verwende einen HM-700 und einen HM-350 .... ich versuche mal genauer mitzuloggen, was da so vorsich geht. Aufgefallen ist es mir ja nur meinen Plots im IOBroker
Dann schau doch Mal in deiner History in ioBroker ob da tatsächlich falsche Werte drin stehen, oder ob evtl zu selten ein Wert abgelegt wird. Der HM-700 wäre auch betroffen, allerdings kann ich mir das nicht vorstellen.
Hallo, ich wollte gerade die 0.4.19 ausprobieren. Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen, Bootloop, Console: [13:57:41]I: connect to network 'Flackerlighter' ... [13:57:43]........... [13:57:53] [13:57:53] ets Jan 8 2013,rst cause:4, boot mode:(3,6) [13:57:53] [13:57:53]wdt reset [13:57:53]load 0x4010f000, len 3460, room 16 [13:57:53]tail 4 [13:57:53]chksum 0xcc [13:57:53]load 0x3fff20b8, len 40, room 4 [13:57:53]tail 4 [13:57:53]chksum 0xc9 [13:57:53]csum 0xc9 [13:57:53]v0005af00 [13:57:53]~ld Jemand einen Tipp ???
:
Bearbeitet durch User
Liebe Leute, ich habe seit einer Weile den HM700 und bin auf diese Diskussion gestoßen. Großartige Arbeit kann ich nur sagen! Ich habe nicht die nötige Expertise um hier mitreden zu können, möchte aber zumindest mein Feedback geben. Mit diesem Setup hatte ich sofort Erfolg: .) "DollaTek NRF24L01 + PA + LNA mit Antenne" .) Raspberry Pi 3B v1.2 (kein Plus) .) Pi OS 32bit (vom 4.4.2022) mit Raspberry Imager aufgesetzt .) Build/install RF24 und Anschlußbelegung Raspberry von hier: https://tutorials-raspberrypi.de/funkkommunikation-zwischen-raspberry-pis-und-arduinos-2-4-ghz/ Allerdings mit diesen Paketen für Python3: sudo apt-get install python3-dev libboost-python-dev sudo apt-get install python3-setuptools (für Python3 muss man noch die richtige boostlib verlinken, bei mir war es: sudo ln -s /usr/lib/arm-linux-gnueabihf/libboost_python39.so.1.74.0 /usr/lib/arm-linux-gnueabihf/libboost_python3.so ) .) Python-Software von hier: https://github.com/grindylow/ahoy .) Im Verzeichnis ahoy-main/tools/rpi das ahoy.yml.example als ahoy.yml kopiert, mqtt disabled auf true gestellt, Seriennummer dort auf mein Gerät angepasst .) Start mit: sudo python3 -um hoymiles --log-transactions --verbose --config ahoy.yml Der Mikroinverter hat sofort geantwortet, die Leistungsangabe hat mit dem angeschlossenen Powermeter auch zusammengepasst - welches ich nun nicht mehr wirklich brauche.... Einfach super! Danke schön für all die Mühen und die tolle Software!
Holger S. schrieb: > ich wollte gerade die 0.4.19 ausprobieren. > Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen, > Bootloop, Console: Ich habe bei meinem Wemos D1 mini mit 0.4.19 einen "Factory Reset" gemacht, meldet sich als AP unter 192.168.1.1, beim ersten Mal bewusst falsches Passwort für mein WLAN eingegeben, AP bleibt aktiv, mit richtigem Passwort Verbindung zum WLAN (s. angehängte Log-Datei). Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass neue Netzwerkgeräte zugelassen werden?
:
Bearbeitet durch User
Grüezi Ziyat T., ich bin mir nicht sicher ob es eine gute Idee wäre, die Datei hier einfach anzuhängen (Thema Copyright). Außerdem sind die einzelnen Revisionen möglicherweise auch nicht ganz uninteressant.
Vielleicht geht bei euch dieses Repository (mit gleicher Revision)?:
1 | git clone https://gitee.com/andycao1860/hoymiles-DTU-PRO.git |
keine Probleme beim Download :-) allerdings hatte ich mich angemeldet beim 1. gitee Link Datum der Dateien in obigem (also 3. Link) ist 13.07.2020 09:38 Ist der gleiche Zeitstempel wie beim 2. Link so wie ich das sehe.
:
Bearbeitet durch User
Günter H. schrieb: > Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass > neue Netzwerkgeräte zugelassen werden? Ja, ist er. Mit den anderen Revisionen hat es ja funktioniert.
Hilfe Meine DTU-Konfiguration auf ESP funktioniert nach der Programmierung maximal 10 Minuten und reagiert nicht auf Ping, sie kehrt nach einiger Zeit zurück und dies ist kein Problem für mein Netzwerk. Ist MQTT für den ordnungsgemäßen Betrieb erforderlich? ist eine spezielle Konfiguration erforderlich? Momentan habe ich die Version 4.19 und nach dem Einrichten des Setups und der Eingabe von Visualisiert stirbt es ...
Hallo Holger S., er kann Deinen Router nicht erreichen, deshalb (oder trotzdem) macht er den Access Point auf. Das hat er auch früher schon so gemacht. Nach 60 Sekudnen sollte er eigentlich nochmal den Router versuchen. Dabei scheint er sich aber irgendwie zu verrechnen, er kommt nämlich von 42 Sekunden wieder auf 60 Sekunden ohne die WiFi Verbindung zu probieren! I: connect to network 'HWW-WLAN-2-5G1581' ... ............................... ........................................................................ ............................ I: --------- AP MODE SSID: AHOY-DTU PWD: esp_8266 Active for: 60 seconds --------- I: AP will be closed in 42 seconds I: 1 clients connected, resetting AP timeout I: AP will be closed in 60 seconds I: 1 clients connected, resetting AP timeout I: AP will be closed in 60 seconds I: Serial debug is I: off
Hallo Daniel M & Ziyat T., > Moin, > wenn ich dort schauen will, bekomme ich die Meldung, dass das Repo für > unregistrierte Benutzer gesperrt ist. > War das schon länger so oder ist das frisch? Ihr müsst Euch zwingend einen Account bei gitee.com erstellen, das war auch schon beim ersten Repolink dorthin so. Sonst kann man auf gitee.com m.E. nichts runterladen. @Mel Yoshi, wie findest Du denn die anderen Repos von Hoymiles. Bei mir ergibt die Suche z.B. nach "usart_nrf3.c" auf gitee.com keinen einzigen Treffer ?
Herbert K. schrieb: > keine Probleme beim Download :-) > allerdings hatte ich mich angemeldet beim 1. gitee Link > Datum der Dateien in obigem (also 3. Link) ist 13.07.2020 09:38 > Ist der gleiche Zeitstempel wie beim 2. Link so wie ich das sehe. Habe es mal ausgepackt und verglichen mit diff/meld und kann auch keine Unterschiede feststellen. Es gibt in hoymiles-DTU-PRO-master-iotloves/hoymiles-DTU-PRO-APP/User/NRF/ neben den bekannten usart_nrf3.c/.h auch eine usart_nrfConfig.h und in der usart_nrf3.c stehen einige Kommentare: //dong 2020-0515 //dong 2020-06-17 Ich habe noch nicht ganz verstanden was der Unterschied zwischen hoymiles-DTU-PRO-APP und hoymiles-DTU-PRO-GPRS ist. Mal sehen ob das die ModBus RS485 Anbindung oder etwas anderes ist ?
@Ziyat T. & Daniel M., es gibt in dem neuen gitee Repo(s) (iotloves === andycao1860) zwei neue Dateien namens SunSpec.c/.h die einiges an Implementierung zu MI-XXX Wechselrichtern enthalten.
Grüezi mitenand, "hoymiles-DTU-PRO-GPRS" wurde in Commit bfb4da7 einfach in "hoymiles-DTU-PRO-APP" umbenannt. Das Ganze ist aber etwas neuer und könnte deshalb vielleicht mehr Infos zur HM-Serie enthalten. Deshalb meinte ich, dass es vielleicht interessant wäre auch die Commit-History mal anzuschauen (also am besten nicht nur das Archiv von gitee.com herunterladen sondern mit das gesamte Repository mit "git clone" klonen). Die Repositories iotloves und andycao1860 haben den selben Stand. @isnoAhoy: Ich habe einfach mit Google gesucht: https://www.google.de/search?q=site:gitee.com+hoymiles
Günter H. schrieb: > Holger S. schrieb: >> ich wollte gerade die 0.4.19 ausprobieren. >> Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen, >> Bootloop, Console: > > Ich habe bei meinem Wemos D1 mini mit 0.4.19 einen "Factory Reset" > gemacht, meldet sich als AP unter 192.168.1.1, beim ersten Mal bewusst > falsches Passwort für mein WLAN eingegeben, AP bleibt aktiv, mit > richtigem Passwort Verbindung zum WLAN (s. angehängte Log-Datei). > > Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass > neue Netzwerkgeräte zugelassen werden? Also ich hab es heute nochmal in Ruhe von vorne angefangen: Ich glaube ich habe bei meinen gestrigen Versuchen falsche Pins in Pinout angegeben. Statt CS -> D8 hab ich wohl GPIO8 ausgewählt. Kann das sein das es dann in einen Bootloop geht ? Dann hängt er auch in dieser Schleife, versucht immer mein WLan zu erreichen, schafft aber kein connect, öffnet aber auch keinen AP. Dann bleibt nur noch neu flashen !? Nun funktioniert die 0.4.19 aber endlich super ! Ich habe zur Zeit 3 Inverter HM-300 dran und trotz Testaufbau und Blechdach und Amplifier Power Level auf Min recht gute Statistic Werte: Uptime: 0 Tage, 00:10:01 Time: 2022-06-18 11:10:36 Statistics: Receive success: 120 Receive fail: 3 Frames received: 387 Send Cnt: 169 Inverter 'West' is available and is producing Inverter 'Sued_1' is available and is producing Inverter 'Sued_2' is available and is producing MQTT: connected Mit der anderen version hatte ich bedeutend mehr fails. Klasse Arbeit. Ich bin begeistert. Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das Endprodukt soll dann eine kleine Box werden die man per Netzstecker direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser ganzen USB Netzteile. Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...
Heinz R. schrieb: > IsnoAhoy schrieb: >> 2. Grid Power Profile > > Damit ist wohl die Einstellung des CosPhi gemeint Bisschen spät, aber da mir gestern das entspr. PDF in die Finger fiel ... ich denke, der CosPhi wird in meiner Branche auf Englisch üblicherweise als "Power Factor" bezeichnet. "Grid Power Profile" könnte sich daher mMn eher auf "Grid Type" aus dem Handbuch https://www.hoymiles.com/wp-content/uploads/2021/11/Technical-Note_Hoymiles-Export-Management_Global_EN_V1.1.pdf Seiten 3 und 4 beziehen. Lässt sich aber leider nicht durch https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf untermauern. Aber auch nicht widerlegen ;-)
Stefan T. schrieb: > Ich habe noch nicht ganz verstanden was der Unterschied zwischen > hoymiles-DTU-PRO-APP und hoymiles-DTU-PRO-GPRS ist. Mal sehen ob das die > ModBus RS485 Anbindung oder etwas anderes ist ? Den DTU-Pro von Hoymiles gibt es in einer WLAN- und einer GPRS-Version: https://www.alpha-solar.info/images/datenbl%C3%A4tter/Hoymiles/User-Manual_DTU-Pro-DE_V202103.pdf (Seite 5) Grüazi, MaXx
Holger S. schrieb: > Nun funktioniert die 0.4.19 aber endlich super ! Das freut mich zu hören. > Das > Endprodukt soll dann eine kleine Box werden die man per Netzstecker > direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser > ganzen USB Netzteile. Das halte ich für eine gute Idee. Ich bin auf das Ergebnis gespannt.
Ich habe jetzt etwas rumgebaut und komme einfach nicht weiter. Die Requests werden korrekt abgesetzt, allerdings renne ich entweder in den Fehler "Frame 1 missing" oder "last frame missing"
1 | 12:01:10.197 -> I: Inverter #0 I: no Payload received! (retransmits: 5) |
2 | 12:01:10.197 -> I: Requesting Inverter SN 114163500316 |
3 | 12:01:10.197 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 |
4 | 12:01:10.251 -> E: while retrieving data: last frame missing: Request Retransmit |
5 | 12:01:10.251 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 |
6 | 12:01:10.298 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE |
7 | 12:01:10.551 -> E: while retrieving data: last frame missing: Request Retransmit |
8 | 12:01:10.551 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 |
9 | 12:01:10.651 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE |
10 | 12:01:10.651 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE |
11 | 12:01:10.698 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE |
12 | 12:01:10.898 -> E: while retrieving data: last frame missing: Request Retransmit |
Die app.cpp ab Zeile 224 original:
1 | if(0 != len) { |
2 | Inverter<> *iv = mSys->findInverter(&p->packet[1]); |
3 | if(NULL != iv) { |
4 | uint8_t *pid = &p->packet[9]; |
5 | if((*pid & 0x7F) < 5) { |
6 | memcpy(mPayload[iv->id].data[(*pid & 0x7F) - 1], &p->packet[10], len-11); |
7 | mPayload[iv->id].len[(*pid & 0x7F) - 1] = len-11; |
8 | }
|
9 | |
10 | if((*pid & 0x80) == 0x80) { |
11 | if((*pid & 0x7f) > mPayload[iv->id].maxPackId) { |
12 | mPayload[iv->id].maxPackId = (*pid & 0x7f); |
13 | if(*pid > 0x81) |
14 | mLastPacketId = *pid; |
15 | }
|
16 | }
|
mit meiner Version:
1 | if(0 != len) { |
2 | Inverter<> *iv = mSys->findInverter(&p->packet[0]); |
3 | if(NULL != iv) { |
4 | uint8_t *pid = &p->packet[0]; //9 |
5 | if((*pid & 0x88) < 5) { // (*pid & 0x7F) |
6 | memcpy(mPayload[iv->id].data[(*pid & 0x88) - 1], &p->packet[9], len-12); // (*pid & 0x7F) |
7 | mPayload[iv->id].len[(*pid & 0x88) - 1] = len-12; // (*pid & 0x7F) |
8 | }
|
9 | if((*pid & 0x89) < 5) { // (*pid & 0x7F) |
10 | memcpy(mPayload[iv->id].data[(*pid & 0x89) - 1], &p->packet[9], len-12); // (*pid & 0x7F) |
11 | mPayload[iv->id].len[(*pid & 0x89) - 1] = len-12; // (*pid & 0x7F) |
12 | }
|
13 | if((*pid & 0x91) < 5) { // (*pid & 0x7F) |
14 | memcpy(mPayload[iv->id].data[(*pid & 0x91) - 1], &p->packet[9], len-12); // (*pid & 0x7F) |
15 | mPayload[iv->id].len[(*pid & 0x91) - 1] = len-12; // (*pid & 0x7F) |
16 | }
|
17 | if((*pid & 0x92) < 5) { // (*pid & 0x7F) |
18 | memcpy(mPayload[iv->id].data[(*pid & 0x92) - 1], &p->packet[9], len-12); // (*pid & 0x7F) |
19 | mPayload[iv->id].len[(*pid & 0x92) - 1] = len-12; // (*pid & 0x7F) |
20 | }
|
21 | |
22 | //if((*pid & 0x80) == 0x80) {
|
23 | if( ((*pid & 0x88) == 0x88) || ((*pid & 0x89) == 0x89) || ((*pid & 0x91) == 0x91) || ((*pid & 0x92) == 0x92) ) { |
24 | if((*pid & 0x88) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F) |
25 | mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F) |
26 | }
|
27 | if((*pid & 0x89) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F) |
28 | mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F) |
29 | }
|
30 | if((*pid & 0x91) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F) |
31 | mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F) |
32 | }
|
33 | if((*pid & 0x92) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F) |
34 | mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F) |
35 | |
36 | if(*pid > 0x92) // (*pid & 0x81) |
37 | mLastPacketId = *pid; |
38 | }
|
39 | }
|
Bei len-11 ist Frame 1 missing, len-12 bringt last frame missing. Den Reqest habe ich so gestaltet:
1 | if(mSerialDebug) |
2 | DPRINTLN(DBG_INFO, F("Requesting Inverter SN ") + String(iv->serial.u64, HEX)); |
3 | //mSys->Radio.sendTimePacket(iv->radioId.u64, mPayload[iv->id].ts);
|
4 | // for MI-Series or TSUN
|
5 | static uint8_t tel = 0; |
6 | if (tel = 2) |
7 | tel = 0; |
8 | |
9 | if (tel == 0) { |
10 | //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x09, mLastPacketId, true);
|
11 | mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x09, 0x00, true); |
12 | }
|
13 | else if (tel == 1) { |
14 | //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, mLastPacketId, true);
|
15 | mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, 0x00, true); |
16 | }
|
17 | else if (tel == 2) { |
18 | //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, mLastPacketId, true);
|
19 | mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x10, 0x00, true); |
20 | }
|
21 | tel++; |
22 | mRxTicker = 0; |
Direkt danach folgt der Fehler:
1 | else if(mSerialDebug) |
2 | DPRINTLN(DBG_WARN, F("time not set, can't request inverter!")); |
3 | yield(); |
für die Position, wo ich das geändert habe. Das repo aus China konnte ich clonen und wühle mich da gerade durch. von dort habe ich auch den CMD 0x10, für Debug- und Verständniszwecke mal mit eingebaut. Gesehen habe ich die Antwort darauf auch schon, nur noch keine Idee, was ich mit den Werten am Ende mache (aktuell auch irrelevant). Was die Payload-länge, maxPackID usw. angeht, habe ich keine Ahnung, was ich da tue und wie es richtig geht. Habe einiges durchprobiert, mangels Verständnis und Wissen scheitere ich an diesem Punkt. &p->packet[0] findet auf jeden Fall die Antwort-ID, &p->packet[9] zeigt auf den Punkt, ab wann Nutzdaten kommen, die Länge der Nutzdaten ist 12 (6 Werte). Habe ich einen Denkfehler bei "len-12" das hier nicht die Gesamtlänge gefragt ist sondern eine Position in der Payload verschoben wird? Ich würde den Knoten im Kopf gerne lösen. edit: typo
:
Bearbeitet durch User
Martin P. schrieb: > Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy > Version aufgegeben, weil dort das multiple messages handling schon > funktioniert ... und habe dort das von mir benötigte json format für > matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR > damit erstellen). Hallo Martin, nur so aus eigenem Interesse, was ist denn matt?
Angehängte Dateien:
-
gridprofile.png
48 KB
@isnoAhoy
Also ich bin schon alt aber...;-)
Sicher habe einen gitee Account! Ich hab ja schon mal das 1. Repo
runtergeladen, seit dem geht es nicht mehr und ich wollte mich nicht
wieder neu registrieren.
@Mel Yoshi
Nach dem hier die Uebersetzungen v. div. files schon veröffentlicht
wurden, ist eine Diskussion über das Thema Copyright für mich nicht mehr
aktuell, aber jeder soll so handhaben, wie es ihm richtig scheint...
@Stefan T.
Das ist sicher die Implementierung das Sunspec Protokolls des MI-WR, das
kann man auch im Modbus-HB lesen.
@Maik R., @isnoAhoy
Das Grid Profile enthaltet mehr Daten als nur den Power Factor, im
Anhang ist mein Grid Profile für meinen Standort.
Und weitere Nachrichten aus MI-1500 Front:
Nach dem ich mit dem MI-1500 erfolglos war, habe noch einen Sniffer auf
arduino/nrf24 basis neben dem esp8266/nrf24 (aeltere Vers.) gestellt,
und sah in den Sniffer-Daten die Antworten vom WR ab und zu kommen,
immer auf die Anfragen auf CH 75!!
Die esp8266/nrf24-SW erkennt die Antworten nicht, weil das CRC nicht
stimmt, guckst du:
ab hier geht es nicht mehr weiter:
if(mHoymiles->checkCrc(p->packet, &len, &rptCnt))
Ich habe vor dem if diese Zeile eingefügt:
mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
So sehe ich ab und zu die Antworten auch im esp8266.
hmmmmm...???
:
Bearbeitet durch User
Thomas B. schrieb: > Martin P. schrieb: > >> Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy >> Version aufgegeben, weil dort das multiple messages handling schon >> funktioniert ... und habe dort das von mir benötigte json format für >> matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR >> damit erstellen). > > Hallo Martin, > nur so aus eigenem Interesse, was ist denn matt? Das ist Mqtt mit Autokorrektur ;-)
Angehängte Dateien:
Holger S. schrieb: …. > > Klasse Arbeit. Ich bin begeistert. > Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine > Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die > auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das > Endprodukt soll dann eine kleine Box werden die man per Netzstecker > direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser > ganzen USB Netzteile. > > Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen > lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten... Gute Idee, ich hab da mal was probiert, siehe Fotos.
Carsten B. schrieb: > Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem > ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g. > Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht > kompatibel sind. > > Hat jemand eine lauffähige Version für ESP32? Das Thema ESP32 habe ich erst mal aufgegeben und benutze einen ESP8266. Die Ahoy-Software läuft darauf einwandfrei, allerdings musste ich in "defines.h" folgendes anpassen: #define PWD_LEN 64 da mein WLAN-Schlüssel die volle Länge nutzt. Mit der Änderung funktioniert es bei mir. LG Carsten
sorry wenn OT - gibt es in Euren chinesischen Quellen auch was für die HMS-Serie von Hoymiles? Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem HM-Protokoll ist? Viele Grüße
Heinz R. schrieb: > sorry wenn OT - gibt es in Euren chinesischen Quellen auch was für die > HMS-Serie von Hoymiles? > Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke > mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem > HM-Protokoll ist? > > Viele Grüße Hallo Heinz, bei der Durchsicht der NRF-Dinge ist mir der HMS nicht begegnet. Die Daten sind von 2020, also nicht super aktuell. Kannst du was genaueres sagen, welche DTU/DTU-Pro dafür passt? Edit: Was mir noch eingefallen ist: welche Seriennummer hat dein HMS und wieviele PV-Anschlüsse/MPPT Tracker?
:
Bearbeitet durch User
Angehängte Dateien:
-
hoymiles_hms_hmt.png
450 KB
Daniel M. schrieb: > welche DTU/DTU-Pro dafür passt? Gestern hatte ich das aus interesse nachgeschaut: https://www.shinetech-power.de/wechselrichter/hoymiles/ "Die Überwachung für HMS Serie ist der DTU Lite S / Pro S, die für HM-Serie gebaute DTU Lite/Wlite/Pro funktioniert nicht mit HMS." Hier gibt es die Anleitung dazu https://manuals.plus/m/1ecf6e51138bca7f81443c62f0c1d440fcbbbf26c16146d949870e807c943955_optim.pdf Hier ist das passende Datenblatt zu finden https://www.mini-nrg.de/download Heinz R. schrieb: > Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke > mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem > HM-Protokoll ist? In den Spezifikationen ist "Sub-1G" unter Kommunikation angegeben. Inn der Bedienungsanleitung ist folgendes zu finden: https://www.hoymiles.com/wp-content/uploads/2021/11/User-manual_HMS-160018002000-4T-NA_EN_V202201.pdf "Range of Sub-1GHz wireless: Unlike Wi-Fi or Zigbee which both operate on the 2.4 GHz band, Sub-1GHz op- erates on the 868 MHz or the 915 MHz band. Generally speaking, Sub-1GHz wireless transmission covers 1.5 to 2 times longer distance than the 2.4GHz spectrum" Hierzu ist eventuell diese Dokumentation über das Sendemodul (?) interessant: https://manuals.plus/m/a345e161e8ceba2155593aaeefcb3e2f3de7dfe1e13fe1e4dc9d421e50725131_optim.pdf Aus einer Hoymiles-Präsentation habe ich noch ein Slide angehängt über HMS/HMT (Über das Protokoll heißt es hier nur "Proprietary"). Vielleicht hilft es euch etwas.
Holger S. schrieb: > > Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen > Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem > Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate > ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten > und den Namen ändern. > Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt. Hallo Holger, ich betreibe es auch auf dem ESP8266 und übermittle via MQTT an mein FHEM seit gestern. Hast du bezüglich der wechselnden ID schon eine Lösung gefunden? Carsten
Carsten B. schrieb: > Holger S. schrieb: >> >> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen >> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem >> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate >> ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten >> und den Namen ändern. >> Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt. > > Hallo Holger, > > ich betreibe es auch auf dem ESP8266 und übermittle via MQTT an mein > FHEM seit gestern. Hast du bezüglich der wechselnden ID schon eine > Lösung gefunden? > > Carsten Hallo Carsten, wenn Du die aktuelle Version 0.4.19 verwendest ist die ID immer "AHOY_DTU"! Ich hatte das zwischenzeitlich auch schon geändert, aber nun wurde es wohl so eingepflegt. Gruß Skusi
Peter L. schrieb: > Holger S. schrieb: > …. >> >> Klasse Arbeit. Ich bin begeistert. >> Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine >> Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die >> auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das >> Endprodukt soll dann eine kleine Box werden die man per Netzstecker >> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser >> ganzen USB Netzteile. >> >> Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen >> lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten... > > Gute Idee, ich hab da mal was probiert, siehe Fotos. WOW !!! So kompakt hatte ich eigentlich nicht vor. Das Gehäuse ist sicherlich gedruckt !? Ich habe keinen 3D Drucker, deshalb wird meine Box nicht direkt der Netzstecker sein, sondern eher ein Kleingehäuse von Pollin. Die Platine Darin enthält dann ein Mini Netzteil vom Typ HLK-PM01 von HI-LINK. Die Spannungsversorgung wird dann über ein EURO Netzkabel erfolgen. Deine Arbeit ist noch eine Stufe Kompakter, aber für mich zu aufwendig. Aber großen Respekt!!! Ich finde die Lösung sehr gut, kann ich nicht gegen anstinken...
Angehängte Dateien:
-
22-06-19_10-30-42_5527.jpg
240 KB -
22-06-19_10-31-08_5528.jpg
240 KB
Hallo, sehr cool und schön kompakt. Ich habe meine Aufbau grade in eine IP65-Verteilerdose eingebaut. Das habe ich bei ähnlichen Anwendungen schon öfter so gemacht. Ist kostengünstig und lässt sich ggf. auch draussen benutzen. Carsten
Hallo, ich hatte grade auch schon gefunden, wo ich es ändern kann und läuft jetzt. Natürlich sollte ich mal die aktuelle Version einsetzen, aber für heute ist erst mal Schluss mit basteln :-) Carsten
Carsten B. schrieb: > Ich habe meinen Aufbau grade in eine > IP65-Verteilerdose eingebaut. Ist da ein separater 3,3V-Spannungsregler zur Versorgung des nRF24L01-Moduls eingebaut? Ich mache gerade Versuche damit - inzwischen schafft mein Aufbau häufig 24 h und länger ohne reboot. Was jetzt auffällt: Nach dieser Zeitspanne geht in meinem Fall die Uhrzeit der "DTU" ca. 8 min nach. Es sieht für mich so aus, als würde beim Booten NTP abgerufen, danach aber nicht mehr? (Leider habe ich vom Programmieren praktisch null Ahnung)
oxylog schrieb: > "Range of Sub-1GHz wireless: Unlike Wi-Fi or Zigbee which both operate > on the 2.4 GHz band, Sub-1GHz op- > erates on the 868 MHz or the 915 MHz band. Generally speaking, Sub-1GHz > wireless transmission covers 1.5 > to 2 times longer distance than the 2.4GHz spectrum" 868 MHz dieses mal. Ich kann mir nicht vorstellen, dass es ein neues oder groß anderes Protokoll gibt. Vielleicht aber erstmal die aktuellen Baustellen abarbeiten und MI- und HM-Serie auf 2,4GHz vollständig implementieren. Interessant ist das aber auf jeden Fall mit der 1G Verbindung, wurde ja bereits vor einigen Tagen hier schonmal mit YT-Links gezeigt. @Heinz R. > Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke > mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem > HM-Protokoll ist? Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen. Hab bitte etwas Geduld :)
Ja, ich habe das Spannungsreglermodul von AZ-delivery benutzt und zusätzlich zwei Elkos angeschlossen (5V und 3,3V). Damit läuft es auch bei PA_HIGH stabil. https://www.az-delivery.de/products/adapter-fur-nrf24l01 Ich habe allerdings immer noch fehlerhafte Pakete, seit der Aufbau nah am WR ist (ca. 2-3m durch eine Holzbalkendecke) ist es aber besser. Statistics: Receive success: 807 Receive fail: 103 Send Cnt: 2861
Angehängte Dateien:
-
Bild_19.06.22_um_11.03.png
460 KB
Holger S. schrieb: > WOW !!! So kompakt hatte ich eigentlich nicht vor. Das Gehäuse ist > sicherlich gedruckt !? Ich habe keinen 3D Drucker, deshalb wird meine > Box nicht direkt der Netzstecker sein, sondern eher ein Kleingehäuse von > Pollin. Die Platine Darin enthält dann ein Mini Netzteil vom Typ > HLK-PM01 von HI-LINK. Die Spannungsversorgung wird dann über ein EURO > Netzkabel erfolgen. > > Deine Arbeit ist noch eine Stufe Kompakter, aber für mich zu aufwendig. > Aber großen Respekt!!! Ich finde die Lösung sehr gut, kann ich nicht > gegen anstinken... Danke, freut mich, wenn es Dir gefällt. Das Schöne an so einer Community ist, dass die Diskussion mit Anderen die eigene Kreativität beflügelt. Über eine solche Kompaktlösung hatte ich vor Deinem Beitrag noch nicht nachgedacht :-) Für diese Variante habe ich folgende Komponenten verwendet: 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die freundlicherweise verschraubt und nicht genietet sind, leicht zu zerlegen und perfekt für den vorgesehenen Zweck geeignet. 2. ein dazu passend konstruiertes Gehäuse-Unterteil mit Verschraub-Möglichkeit für den obigen Schukostecker. 3. das Mini-Netzteil 5V, das Du auch verwendest. 4. eine passend konstruierte Trennplatte mit Bohrung zum Abtrennen des Netzspannungs-Bereichs vom Rest. 5. ein ESP8266 D1 von AZ-Delivery mit zwei Buchsenleisten. 6. eine passende (ESP8266-Format) Leerplatine von AZ-D. 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne. Modul mit Fädeltechnik und Steckerleisten auf Leerplatine gelötet. 8. 10uF Elko an 3.3V Versorgung dazu, bisschen isolierte Alufolie um den Prozessorteil des NRF24L01+, unter Vermeidung von Kurzschlüssen das Ganze zum Sandwich zusammengesteckt. 9. passend zum Gehäuse konstruierter Deckel. Teile 2,4 und 9 sind 3D-gedruckt (die waren ursprünglich für eine ESPEasy-basierte Lösung zur Temperaturmessung mit DS1820 entstanden). Im Moment liegen die Platinen nur locker im dafür vorgesehenen Gehäusebereich, das könnte man noch durch Anpassung der inneren Formgebung verbessern. :-)
Daniel M. schrieb: > Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen. > Hab bitte etwas Geduld :) sorry, hatte es verwechselt - HM und MI-Serie sind ja 2,4 GHz Wollte hier jetzt auch nicht noch groß ein Thema wegen HMS aufmachen - aber hätte ja sein können jemand hat in den diversen chinesischen Seiten was dazu gefunden Viele Grüße
Heinz R. schrieb: > Daniel M. schrieb: >> Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen. >> Hab bitte etwas Geduld :) > > sorry, hatte es verwechselt - HM und MI-Serie sind ja 2,4 GHz > > Wollte hier jetzt auch nicht noch groß ein Thema wegen HMS aufmachen - > aber hätte ja sein können jemand hat in den diversen chinesischen Seiten > was dazu gefunden > > Viele Grüße Den Fortschritt beobachten ist auf jeden Fall wichtig. Meinen TSUN als MI-Verschnitt habe ich damals geholt weil ich dachte, dass er gut und auch kommunikativ ist. Hätte ich da gewusst, dass es sich um einen MI-Klon handelt, wäre ich gleich auf die HM-Serie gegangen. Schlecht ist er nicht, er fängt sehr früh schon an mit produzieren und hält lange durch, aber für mehr als mal schnell irgendwo 2 Module hinlegen würd ich ihn auch nicht weiter einsetzen. Da ich jetzt schlauer bin, werd ich die nächsten 16 Module wohl mit der HM-Serie bestücken. Wenn HMS jetzt kommt, fallen die HM hoffentlich im Preis. Aktuell ist ja fast nichts lieferbar, das ändert sich hoffentlich auch noch.
Liebe Leute, eine Kleinigkeit ist mir aufgefallen - kann jetzt doch noch einen unbedeutenden Beitrag leisten... :-) In Zeile 471 der Datei: https://github.com/grindylow/ahoy/blob/main/tools/rpi/hoymiles/decoders/__init__.py (in "class Hm600Decode0B") sollte wohl das stehen: "return self.unpack('>H', 34)[0]/100" (statt "/10"), sonst passt der ausgegebene AC Strom nicht. Für die 1-String Inverter (in "class Hm300Decode0B") ist der Code korrekt. Danke nochmal, Wolfgang
Hallo, ich verfolge diesen Thread schon ein paar Tage, dauert ja bei so vielen Einträgen schon ne Weile, bis man alles gelesen hat :-) und muss sagen, super Arbeit in so kurzer Zeit. Da ihr ja auch an der Einspeise-Leistungsregelung arbeitet, hab ich noch eine Idee zu einer einfachen Leistungsmessung. Mit den neuen elektronischen Stromzählern kann man über Optokopler den Zählerstand und die aktuelle Leistung auslesen (Obis/SML-Schnittstelle). Die wird bei mir auch negativ angezeigt, wenn der WR Überschuss produziert. Meine Idee war, eine Software zum auslesen für den ESP schreiben und die Daten per MQTT weiter geben, oder eure Schaltung noch mit einer Photodiode ergänzen und die Obis-SW gleich mit integrieren. Und wie es im Internet so ist, war da schon jemand anderer auf die Idee gekommen, ESP mit Obis-SW gibts schon: https://github.com/mruettgers/SMLReader Nur mal so als günstige Anregung der Leistungsmessung, ist auch leicht im Schaltschrank zu installieren, ohne Elektriker, nur auf den Zähler mit Magnet oder Klebeband aufsetzen. Bilder und Schaltplan sind bei GitHub dabei. Grüße Claus T. P.S. ich habe seit kurzem ein Balkonkraftwerk mit Wechselrichter TSOL-M800 von TSUN, würde mich also über die Unterstützung dieses WR freuen.
Peter L. schrieb: > Für diese Variante habe ich folgende Komponenten verwendet: > 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von > Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die > freundlicherweise verschraubt und nicht genietet sind, leicht zu > zerlegen und perfekt für den vorgesehenen Zweck geeignet. Solche alten Gehäuse ausgeschlachteter Steckernetzteile hab ich auch noch zu Hauf rumligen. Aber je mehr ich damit hantiere fällt mir auf das ich es immer gehasst habe das man diese Dinger nie da reingesteckt bekommt wo man sie gerade heben möchte. In Mehrfachsteckdosen belegen sie meist 2 Plätze oder passen eben gar nicht mit den anderen Winkelsteckern zusammen, usw... Außerdem denke ich ist man mit der WLan Antennen Ausrichtung des Wemos flexibler wenn man das Gehäuse mit einem 230V Netzkabel ausstattet. Ich werde die Variante mit Standard Gehäuse weiter verfolgen. > 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne. Ich werde in das Gehäuse ein Nrf24l01+pa+lna Modul verbauen. Dann kann ich ein SMA Verlängerungskabel verwenden um die Antenne flexibel, wahrscheinlich sogar Outdoor (weil Blechdach) zu positionieren. Dann muß ich die Technik selber auch nicht wasserdicht ausführen und kann sie Indoor lassen, ist mir lieber. > 8. 10uF Elko an 3.3V Versorgung dazu Ist das zu empfehlen ? Arbeitet das dann stabiler ? Auch ein Elko an 5V ? Gruß Skusi
Carsten B. schrieb: > Ja, ich habe das Spannungsreglermodul von AZ-delivery benutzt und > zusätzlich zwei Elkos angeschlossen (5V und 3,3V). Damit läuft es auch > bei PA_HIGH stabil. Meinst Du das der Spannungsregler auf dem Wemos minderwertiger ist und deshalb oft rebootet wird ? Oder sind es eher die Elkos die da abhilfe schaffen. Mein Testaufbau rebootet auch öfters. 24 Std hab ich noch nicht geschafft. Ich beobachte das auch schon mit Sorge und frage mich was man da Hardwareseitig machen kann. Ich dachte immer das es noch Kinderkrankheiten der Software sind. Gruß Skusi
oxylog schrieb: > Hierzu ist eventuell diese Dokumentation über das Sendemodul (?) > interessant: > https://manuals.plus/m/a345e161e8ceba2155593aaeefcb3e2f3de7dfe1e13fe1e4dc9d421e50725131_optim.pdf Interessant ist neben den Pin-Outs folgender Absatz aus der Anleitung: 3.6 Label and compliance information An exterior label on OEM’s end product can use wording such as the following: “Contains Transmitter Module FCC ID: 2ARNB-HMS101” or “Contains FCC ID: 2ARNB-HMS101” Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das ist m.W. Giga Devices, China) und einen 300A E965 945 chip. Die chin. Chip(s)-Hersteller produzieren viele ST32, nRF24 o.a. Clones. https://fccid.io/2ARNB-HMS101/Internal-Photos/Internal-Photos-5204735 Du kannst ja mal weiter oben nachschauen ob das die selbe FCC ID ist wie im bisherigen nRF24-basierten Modul ? Das mit dem Sub-1G Funkmodul steht auch bei den aktuellen Hoymiles HM-600 Invertern im Data Sheet, da nimmt es der Hersteller wohl nicht ganz so genau mit dem Marketing der Sende-Frequenzen. Es könnte aber auch ein LoRaWAN ähnliches Modul sein, zumindest die genutzten Frequenzen von 868 & 915 MHz sprächen dafür, wobei in US glaube ich 433 MHz genutzt werden.
Hallo Daniel M., probier mal die Anfrage umgekehrt zu stellen, d.h. erst DTU dann WR Adresse:
1 | 12:01:10.197 -> I: Requesting Inverter SN 114163500316 |
2 | 12:01:10.251 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 |
3 | 12:01:10.298 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE |
Also > Transmit 11 | 09 78 56 34 12 63 50 03 16 00 27 das sollte dann eigentlich die Antwort geben > 89 63 50 03 16 78 56 34 12 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE Hier noch ein paar Kommentare um den Code zu verdeutlichen > Die app.cpp ab Zeile 224 original: >
1 | > if(0 != len) { |
2 | > Inverter<> *iv = mSys->findInverter(&p->packet[1]); |
3 | > if(NULL != iv) { |
4 | // paket ID in byte 10, d.h. packet[9]
|
5 | > uint8_t *pid = &p->packet[9]; |
6 | // die paket ID muß < 5 sein, wenn man 0x80 abzieht bzw. sich alle unteren Bits ansieht.
|
7 | > if((*pid & 0x7F) < 5) { |
8 | // kopiere das Ergebnis in die Payload .data[1..5] ab der 11. Stelle bis zum Ende, das Ende ist die Länge des Paketes len-11 Bytes (= 10 Bytes davor plus 1 Byte CRC-8 ganz am Ende)
|
9 | > memcpy(mPayload[iv->id].data[(*pid & 0x7F) - |
10 | > 1], &p->packet[10], len-11); |
11 | // Berechne die Länge der Payload des Paketes, analog zur Länge davor
|
12 | > mPayload[iv->id].len[(*pid & 0x7F) - 1] = |
13 | > len-11; |
14 | > } |
15 | >
|
16 | // Wenn die Paket ID das höchstwertige Bit 0x80 gesetzt hat bzw. > 0x80 ist == Letztes Paket oder Antwort auf ein Retransmit
|
17 | > if((*pid & 0x80) == 0x80) { |
18 | // wenn die Paket ID > die maxPackId ist.
|
19 | > if((*pid & 0x7f) > |
20 | > mPayload[iv->id].maxPackId) { |
21 | // setze die maxPackId gleich der aktuellen Paket ID
|
22 | > mPayload[iv->id].maxPackId = (*pid & |
23 | > 0x7f); |
24 | // falls die Paket ID > 0x81 ist, also 0x82 ... 0x85
|
25 | > if(*pid > 0x81) |
26 | // setze die mLastPackId = der aktuellen paket ID
|
27 | > mLastPacketId = *pid; |
28 | > } |
29 | > } |
30 | >
|
> mit meiner Version: >
1 | > if(0 != len) { |
2 | > Inverter<> *iv = mSys->findInverter(&p->packet[0]); |
3 | > if(NULL != iv) { |
4 | > uint8_t *pid = &p->packet[0]; //9 |
5 | > if(*pid == 0x88) { // A Event |
6 | > memcpy(mPayload[iv->id].data[2], &p->packet[9], len-12); |
7 | > mPayload[iv->id].len[2] = len-12; |
8 | > } |
9 | > if(*pid == 0x89) { // A Data |
10 | > memcpy(mPayload[iv->id].data[0], &p->packet[9], len-12); |
11 | > mPayload[iv->id].len[0] = len-12; |
12 | > } |
13 | > if(*pid == 0x91) { // B Event (or Data ?) |
14 | > memcpy(mPayload[iv->id].data[1], &p->packet[9], len-12); |
15 | > mPayload[iv->id].len[1] = len-12; |
16 | > } |
17 | > if(*pid == 0x92) { // B Data (or Event ?) |
18 | > memcpy(mPayload[iv->id].data[3], &p->packet[9], len-12); |
19 | > mPayload[iv->id].len[3] = len-12; |
20 | > } |
21 | >
|
22 | Den Rest würde ich erstmal weglassen und sehen, daß er die o.a. 0x89 Antwort sauber dekodiert. Das sollte er in processPayload machen. |
23 | Dabei kannst Du m.E. den Punkt mit buildPayload überspringen, dabei werden alle Teil-Payloads der Pakete zusammen nochmal mit einer CRC-16 validiert. |
24 | Das gibt/gab es bei den MI-Wechselrichtern nicht, dort reicht die bereits in Zeile 216 überprüfte CRC-8 die immer am Ende jedes Pakets vorhanden ist. |
25 | |
26 | > if( (*pid == 0x88) || (*pid == 0x89) || (*pid == 0x91) || (*pid == 0x92) ) { |
27 | > if((*pid == 0x89) && (mPayload[iv->id].maxPackId < 1)) { |
28 | > mPayload[iv->id].maxPackId = 1; |
29 | > } |
30 | > if((*pid == 0x88) && (mPayload[iv->id].maxPackId < 3) { |
31 | > mPayload[iv->id].maxPackId = 3; |
32 | > } |
33 | > if((*pid == 0x91) && (mPayload[iv->id].maxPackId < 2) { |
34 | > mPayload[iv->id].maxPackId = 2; |
35 | > } |
36 | > if((*pid == 0x92) && (mPayload[iv->id].maxPackId < 4)) { |
37 | > mPayload[iv->id].maxPackId = 4; |
38 | >
|
39 | > if(*pid == 0x92) |
40 | > mLastPacketId = *pid; |
41 | > } |
42 | > } |
43 | >
|
Ich bin mir nicht sicher in welcher Reihenfolge die einzelnen Anfragen 0x09, 0x11, 0x08 / 0x12 denn gestellt werden bzw. reinkommen. Ich habe jetzt einfach mal eine hypothetische Reihenfolge angenommen und nehme an, daß auch tatsächlich alle view Pakete gesendet / empfangen werden. Sollte das nicht der Fall sein, muß man das eben entsprechend kürzen. Persönlich wäre für mich nach 0x89 (als Antwort auf 0x09) und 0x91/0x92 (als Antwort auf 0x11) erst mal Schluss. D.h. eigentlich nur zwei Antwort-Pakete und dann die mLastPacketId setzen. > dort habe ich auch den CMD 0x10, für Debug- und Verständniszwecke mal > mit eingebaut. Gesehen habe ich die Antwort darauf auch schon, nur noch > keine Idee, was ich mit den Werten am Ende mache (aktuell auch > irrelevant). Laut Command Summary ist 0x10 Collect grid-connected configuration file name and version information die Antwort beginnt dann mit 0x90. > Was die Payload-länge, maxPackID usw. angeht, habe ich keine Ahnung, was > ich da tue und wie es richtig geht. Habe einiges durchprobiert, mangels > Verständnis und Wissen scheitere ich an diesem Punkt. In der app.h wird die folgende Struktur definiert, die pro Wechselrichter existiert:
1 | typedef struct {
|
2 | uint8_t invId; |
3 | uint32_t ts; |
4 | uint8_t data[MAX_PAYLOAD_ENTRIES][MAX_RF_PAYLOAD_SIZE]; |
5 | uint8_t len[MAX_PAYLOAD_ENTRIES]; |
6 | bool complete; |
7 | uint8_t maxPackId; |
8 | uint8_t retransmits; |
9 | bool requested; |
10 | } invPayload_t; |
> &p->packet[0] findet auf jeden Fall die Antwort-ID, &p->packet[9] zeigt > auf den Punkt, ab wann Nutzdaten kommen, die Länge der Nutzdaten ist 12 > (6 Werte). Ich denke das ist richtig. @Lukas, kannst Du das und die weiteren Annahmen / Fragen zu buildPayload / processPayload eventuell noch bestätigen bzw. etwas erklären ? > Habe ich einen Denkfehler bei "len-12" das hier nicht die Gesamtlänge > gefragt ist sondern eine Position in der Payload verschoben wird? len ist die Länge des gesamten Antwort Paketes vom nRF24, also len-10 sollte m.E. bei Dir richtig sein (10 Bytes = 1 Byte Command + 4 Bytes Source Adr + 4 Bytes Destination Adr + 1 Byte CRC-8 am Ende)
1 | 89 >63 50 03 16< >78 56 34 12< >01 2B< >00 56< >09 5C< >13 85< >09 A5< >02 B8< >01 FF< DE |
2 | 1 + 4 + 4 + 2 + 2 + 2 + 2 + 2 + 2 + 2 + 1 |
3 | CMD >WR ADR < >DTU ADR < >299 W< > 86 ?< >2396?< >4997?< >2469?< >696?< >511?< CRC8 |
> Ich würde den Knoten im Kopf gerne lösen.
Ich hoffe das o.a. ist jetzt nicht komplett verwirrend sondern hilft Dir
etwas weiter. Vielleicht kann ja auch nochmal Lukas etwas zu einer
möglichen Implementierung in der Methode processPayload (bzw.
buildPayload) sagen.
Ich hoffe das klappt mit dem MI-Wechselrichtern bei Euch noch demnächst.
Stefan T. schrieb: ... > Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das > ist m.W. Giga Devices, China) ... Könnte dieser sein (Datenblatt siehe Anhang)
Stefan T. schrieb: > Hallo Daniel M., > > probier mal die Anfrage umgekehrt zu stellen, d.h. erst DTU dann WR > Adresse: > Also > >> Transmit 11 | 09 78 56 34 12 63 50 03 16 00 27 > > das sollte dann eigentlich die Antwort geben > >> 89 63 50 03 16 78 56 34 12 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE DTU und WR-ID umdrehen klappt nicht, es folgen keine Antworten mehr. Ich sende 0x09 und erhalte im normalfall eine 0x88 und eine 0x89 zurück.
1 | 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B |
2 | 89 63 50 03 16 63 50 03 16 01 2F 00 05 09 5D 13 86 00 97 07 CC 01 60 5E |
Die 0x88 ist der Status, hier die 03 ist der Modulstatus (verbunden und aktiv) Die 0x89 sind die Werte:
1 | 89 63 50 03 16 63 50 03 16 01 2F 00 05 09 5D 13 86 00 97 07 CC 01 60 5E |
2 | 1 + 4 + 4 + 2 + 2 + 2 + 2 + 2 + 2 + 2 + 1 |
3 | CMD >WR ADR < >WR ADR < >29,9V<>0,86A<>239,6V<>4997Hz<>24,69W< |
4 | >0,696kWh< >51,1°C< CRC8 |
CMD, WR-ID, WR-ID, DC_U, DC_I, AC_U, AC_Freq, AC_Pow, Day_kWh, WR_Temperatur Das gleiche gilt für die Anfrage 0x11 mit den Antworten 0x91 Status und 0x92 Werte. Mit Hubi seiner NRF24_SendRcv bekomme ich folgedes als Payload zurück:
1 | 00 7388888801 0096 12 3 88 63500316 63500316 00030000000000008B187E 1 |
2 | 00 7388888801 00C4 18 2 89 63500316 63500316 012B000409641384007D07D8014BB5780D 1 |
3 | |
4 | 00 7388888801 00C4 18 2 91 63500316 63500316 013400030965138500720768014A0BACD6 1 |
5 | |
6 | 00 7388888801 0096 12 3 92 63500316 63500316 00030000000000009158D6 1 |
Ich habs bisher noch nicht geschafft, das komplett anzeigen zu lassen. Wird in der ahoy-Version der kram vor 0x88 usw. verworfen und ich starte quasi mit der Antwort bei packet[0] oder starte ich bei [10] und mit der Adresse bei [11]? In allen Versuchen mit verschiedenen Adressen in dem Teil:
1 | if(0 != len) { |
2 | Inverter<> *iv = mSys->findInverter(&p->packet[1]); |
3 | if(NULL != iv) { |
habe ich nichts verwertbares bekommen. Den Debug konnte ich soweit verändern, dass er mir immer eine len=0 und maxPackId=4 ausgegeben hat, falls da überhaupt was war. Bei packet[1] hat die Funktion retransmit gegriffen, "Frame 1 missing", bei allen anderen Versuchen war "Last Frame missing". Die anderen Tips schau ich mir gleich an. > Ich hoffe das o.a. ist jetzt nicht komplett verwirrend sondern hilft Dir > etwas weiter. Vielleicht kann ja auch nochmal Lukas etwas zu einer > möglichen Implementierung in der Methode processPayload (bzw. > buildPayload) sagen. War nicht komplett verwirrend, aber ich brauche etwas Zeit um alles anzuschauen und nachzuvollziehen. Ich denke, ich bin immernoch nur am Symptom dran, nicht an der Ursache. Irgendwo hab ich etwas übersehen, was verkehrt läuft. Gerne mehr Informationen und Ideen :) > Ich hoffe das klappt mit dem MI-Wechselrichtern bei Euch noch demnächst. Das hoffe ich auch, hab ich ehrlich gesagt unterschätzt, wie aufwändig es ist. Danke auf jeden Fall für deine ausführliche Antwort, ich probier weiter.
Holger S. schrieb: > Peter L. schrieb: >> Für diese Variante habe ich folgende Komponenten verwendet: >> 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von >> Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die >> freundlicherweise verschraubt und nicht genietet sind, leicht zu >> zerlegen und perfekt für den vorgesehenen Zweck geeignet. > > Solche alten Gehäuse ausgeschlachteter Steckernetzteile hab ich auch > noch zu Hauf rumligen. Aber je mehr ich damit hantiere fällt mir auf das > ich es immer gehasst habe das man diese Dinger nie da reingesteckt > bekommt wo man sie gerade heben möchte. In Mehrfachsteckdosen belegen > sie meist 2 Plätze oder passen eben gar nicht mit den anderen > Winkelsteckern zusammen, usw... > Außerdem denke ich ist man mit der WLan Antennen Ausrichtung des Wemos > flexibler wenn man das Gehäuse mit einem 230V Netzkabel ausstattet. > > Ich werde die Variante mit Standard Gehäuse weiter verfolgen. > ich denke, die Umsetzung sollte sich immer an den individuellen Anforderungen orientieren. Für mich ist klein und kompakt wichtig... >> 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne. > > Ich werde in das Gehäuse ein Nrf24l01+pa+lna Modul verbauen. Dann kann > ich ein SMA Verlängerungskabel verwenden um die Antenne flexibel, > wahrscheinlich sogar Outdoor (weil Blechdach) zu positionieren. > Dann muß ich die Technik selber auch nicht wasserdicht ausführen und > kann sie Indoor lassen, ist mir lieber. bisher habe ich leider noch kein mit dem HM-1200 funktionierendes Funkmodul mit Antennenpin auftreiben können, daher die Platinenversion, die aber erstaunlich gut funktioniert. Auch eingebaut und fest in der Steckdose verstöpselt. > >> 8. 10uF Elko an 3.3V Versorgung dazu > > Ist das zu empfehlen ? Arbeitet das dann stabiler ? Auch ein Elko an 5V > ? es gibt irgendwo in diesem Thread eine Empfehlung dazu, die für mich plausibel klingt, daher habe ich das gemacht. Zu einem Elko an 5V kann ich nichts sagen, es schadet nicht, aber ob es eine Verbesserung bringt...?
Holger S. schrieb: > Ist das zu empfehlen ? Quelle für den Tipp: http://stefanfrings.de/esp8266/ oder https://esp8266-server.de/Tipps.html
oxylog schrieb: > Holger S. schrieb: >> Ist das zu empfehlen ? > > Quelle für den Tipp: http://stefanfrings.de/esp8266/ Wemos D1 Mini Board ... Der Spannungsregler reicht gerade für den WLAN Chip aus, er darf extern nur minimal belastet werden (50 mA bei 5 V). Um die Zuverlässigkeit zu verbessern, empfehle ich einen 100 µF Kondensator zwischen 3,3V und GND. > oder https://esp8266-server.de/Tipps.html Adapter Plate With IO Lead Out For ESP-07 ESP-08 ESP-12 ... Außerdem fehlt auf der Platine ein Puffer Kondensator an 3,3V –Seite. Es muss mindestens 100uF sein, denn ESP8266 Modul erzeugt kurzzeitig die Strompeaks von 400mA.
Herbert K. schrieb: > Stefan T. schrieb: > ... >> Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das >> ist m.W. Giga Devices, China) > ... > Könnte dieser sein (Datenblatt siehe Anhang) Treffer GD32 E329G8 ist ein STM blue pill clone. Wegen dem 300A E965 945 habe ich dem o.a. FCC Beitrag noch folgendes entnommen: 4.1 NRF Channel List Depending on the program, the module can work on 915MHz for North America and 868MHz for Europe. Unless necessary, it’s forbidden to change the module program. Das spricht zumindest für NRF m.W. ein Nordic Semiconductors Standard. Vielleicht findet man ja mit NRF und der Frequenz etwas mehr, ich tippe auf einen nRF905 Clone ? Data Sheet z.B. hier https://www.sparkfun.com/datasheets/IC/nRF905_rev1_1.pdf
:
Bearbeitet durch User
Moin zusammen, ich habe nun das NRF Module auf dem Raspberry zum laufen bekommen. :)
1 | Poll inverter 116174403329 |
2 | 2022-06-20 14:43:35.254088 Transmit 27 | 15 74 40 33 29 78 56 30 01 80 0b 00 62 b0 79 87 00 00 00 05 00 00 00 00 bd d7 ec |
3 | 2022-06-20 14:43:35.311724 Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 01 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00 00 95 |
4 | 2022-06-20 14:43:35.346887 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 d7 00 00 00 03 00 01 42 |
5 | 2022-06-20 14:43:35.417421 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 07 00 00 00 00 00 00 00 01 00 00 00 00 00 03 93 |
6 | 2022-06-20 14:43:35.458275 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 01 0d 00 0b c4 fc 2e |
7 | 2022-06-20 14:43:35.960403 Payload: 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d7 00 00 00 03 00 01 00 07 00 00 00 00 00 00 00 01 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 01 0d 00 0b c4 fc |
8 | 2022-06-20 14:43:35.960403 Decoded: temp=26.9, pf=0.0 phase0=voltage:0.3, current:0.0, power:0.0, frequency:0.0 string0=voltage:0.1, current:0.0, power:0.0, total:0.0, daily:0 string1=voltage:0.1, current:0.01, power:0.0, total:0.0, daily:0 string2=voltage:21.5, current:0.0, power:0.1, total:0.0, daily:0 string3=voltage:21.5, current:0.03, power:0.7, total:0.001, daily:0 |
Bekomme aber hin und wieder ein missing frame zurück. =( Error while retrieving data: Frame 3 missing: Request Retransmit Error while retrieving data: Frame 1 missing: Request Retransmit Error while retrieving data: Missing packet: Last packet 2
Tach auch, ich habe nun gestern mein Platinenlayout fertig gestellt. Nun stellt sich mir noch die Frage nach der stabilen Spannungsversorgung des RF24. Ich habe mal eben eine über 30 min die Stromaufnahme des Transceiver bei Amplifier Power Level Max und drei Invertern gemessen. Die Spitzen lagen bei 34 mA. Auf http://stefanfrings.de/esp8266/ steht geschrieben: 3V3 VCC Spannungsversorgung 3,3 V (Eingang 500 mA oder Ausgang max. 50 mA) Wäre also im Limit. Trotzdem ist ein 100 µF Kondensator sicher nicht falsch. Ich könnte zur Sicherheit natürlich noch einen eigenen Spannungsregler für den RF24 dazu stricken. Eine andere Überlegung ist ein 3,3V Netzteil einzusetzen und den RF24 sowie den Wemos damit zu versorgen. Im Netzt ließt man aber unterschiedliche Meinungen dazu ob es gut ist den Wemos eigenen Spannungsregler "rückwärts" mit 3,3 V zu betreiben. Es würde die Sache aber um einen Spannungsregler leichter machen. Den 100 µF Kondensator würde ich zur Sicherheit dann trotzdem an das Netzteil hängen. Ich kann mich nicht entscheiden, wie ist Eure Meinung dazu ?
@ Holger Der nRF24L01+ kann aber auch deutlich mehr Strom aufnehmen: "The modules operate in the 2.4GHz band at data rates of 250Kbps, 1Mbps or 2Mbps. Max operating current is < 115mA." (Quelle: https://protosupplies.com/product/nrf24l01palna-2-4ghz-rf-wireless-module/) Mit diesem Wert wäre man außerhalb einer stabilen Spannungsversorgung. Mein Vorschlag: Zweiten 3,3V-Spannungsregler (und Peripherie) auf Platine vorsehen mit der Option, diesen Spannungsregler ggf. nicht zu bestücken und über eine dann einzulötende Drahtbrücke zu überbrücken.
MI-1500: - Beim Sniffen keine Sender Daten vom ESP gesehen, lange gesucht und - meine beiden ESP's waren futsch!!!!!, MOSI gehen an beiden nicht??! - auf Arduino gewechselt - es muss die PA Einstellung RF24_PA_LOW sein, schon mit RF24_PA_HIGH geht nichts mehr! Mein MurxBoard ist 10m vom WR weg. - Warum bei beiden ESP's die MOSI's kaputt sind: kann die Standard Einstellung RF24_PA_MAX der Grund sein??? Hier mit 3 PV's Send... CH75 36637071607222841200F2 Send... CH3 37637071607222841200F3 Send... CH23 38637071607222841200FC Send... CH40 39637071607222841200FD Send... CH61 36637071607222841200F2 00 1284227201 00DE 1B 3 B6 63707160 63707160 01750004091E1387009703E0013E0300030EEAC5 1 PV:1 37.30V 0.40A 15.10W 992.00Wh 233.40V 49.99Hz 31.80C Sts:3 Cnt:0 Send... CH75 37637071607222841200F3 Send... CH3 38637071607222841200FC Send... CH23 39637071607222841200FD Send... CH40 36637071607222841200F2 Send... CH61 37637071607222841200F3 00 1284227201 00DA 1B 1 B7 63707160 63707160 017500040920138600AE040C013E030003E28DBB 1 PV:2 37.30V 0.40A 17.40W 1036.00Wh 233.60V 49.98Hz 31.80C Sts:3 Cnt:0 Send... CH75 38637071607222841200FC Send... CH3 39637071607222841200FD Send... CH23 36637071607222841200F2 Send... CH40 37637071607222841200F3 Send... CH61 38637071607222841200FC 00 1284227201 00D8 1B 0 B8 63707160 63707160 0163000409231387009106E1013F03000328AD7E 1 PV:3 35.50V 0.40A 14.50W 1761.00Wh 233.90V 49.99Hz 31.90C Sts:3 Cnt:0 Send... CH75 39637071607222841200FD Send... CH3 36637071607222841200F2 Send... CH23 37637071607222841200F3 Send... CH40 38637071607222841200FC Send... CH61 39637071607222841200FD 00 1284227201 00D8 1B 0 B9 63707160 63707160 016300000921138600030006013E0300035C4E20 1 PV:4 35.50V 0.00A 0.30W 6.00Wh 233.70V 49.98Hz 31.80C Sts:3 Cnt:0
Holger S. schrieb: > Eine andere Überlegung ist ein 3,3V Netzteil einzusetzen und den RF24 > sowie den Wemos damit zu versorgen. Im Netzt ließt man aber > unterschiedliche Meinungen dazu ob es gut ist den Wemos eigenen > Spannungsregler "rückwärts" mit 3,3 V zu betreiben. Es würde die Sache > aber um einen Spannungsregler leichter machen. Den 100 µF Kondensator > würde ich zur Sicherheit dann trotzdem an das Netzteil hängen. > > Ich kann mich nicht entscheiden, wie ist Eure Meinung dazu ? auf dem Wemos ist ja ein RT9013 verbaut, vom Blockschaltbild sehe ich erstmal kein Problem wenn auf der 3,3V Seite Spannung anliegt. Ich würde das ganze sowieso entkoppeln, alleine wegen dem ganzen Funk und HF zeugs was sich gegenseitig ja stört. Einfach einen zweiten RT9013 nur für den RF24 nehmen und dann kannst du alles mit 5V Versorgen.
Ich habe nach Stefan seiner Anleitung noch etwas rumprobiert und bin hier rausgekommen:
1 | D: Received 18 bytes channel 75: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B |
2 | D: ],[0,6103,"normal"],[0,3104,63.62],[0,6101,0],[0,9101,"roller"],[0,4108,239.21]]} |
3 | |
4 | D: Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 00 E4 00 00 09 4E 13 88 00 0D 01 E2 00 BC E3 |
5 | D: ],[0,6103,"normal"],[0,3104,63.62],[0,6101,0],[0,9101,"roller"],[0,4108,239.21]]} |
Wo kommen "normal" und "roller" her, was ist das? Wie genau wird die mPayload zusammengebaut? Wofür stehen die ".data"-Adressen?
1 | memcpy(mPayload[iv->id].data[3], &p->packet[16], len-9); |
2 | mPayload[iv->id].len[3] = len-8; |
Ich denke, so langsam verstehe ich, was passiert. @Ziyat: Glückwunsch! :) Das PA_Max war es wahrscheinlich nicht, mein Wemos hält bisher stand. lg
Hallo Holger, ich kann noch das folgende vom Author der RF24 Bibliothek beisteuern: my PA/LNA module fails to transmit https://nrf24.github.io/RF24/md_COMMON_ISSUES.html You may find variants of the nRF24L01 transceiver that are marketed as “nRF24L01+PA+LNA”. These modules are distinct in the fact that they come with a detachable (SMA-type) antenna. They employ seperate RFX24C01 IC with the antenna for enhanced Power Amplification (PA) and Low Noise Amplification (LNA) features. While they boast greater range with the same functionality, they are subject to a couple lesser known (and lesser advertised) drawbacks: Stronger power source. Below is a chart of advertised current requirements that many MCU boards’ 3V regulators may not be able to provide (after supplying power to internal components). Specification Value Emission mode current(peak) 115 mA Receive Mode current(peak) 45 mA Power-down mode current 4.2 µA Needs shielding from electromagnetic interference. Shielding usually works best when it has a path to ground (GND pin), but this connection to the GND pin is not required. It is important that the sheilding does not touch any current carrying parts. Professionals tend to use a faraday cage/mesh to implement electromagnetic shielding, but it can be pricey for this scenario. A quick do-it-yourself solution (as proof-of-concept) would be to wrap the PA/LNA module with electrical tape and then wrap foil around the electrical tape (for shielding) while being very careful to not let the foil touch any current carrying parts (like the GPIO pins, the antenna mount, and the soldier joints for the antenna mount). Observe ghetto_shielding_1.png ghetto_shielding_2.png Sowie hier die Empfehlung einen Kondensator zwischen 3,3V und GND zu klemmen: Troubleshooting https://howtomechatronics.com/tutorials/arduino/arduino-wireless-communication-nrf24l01-tutorial/ It’s worth noting that power supply noise is one of the most common issues people experience when trying to make successful communication with the NRF24L01 modules. Generally, RF circuits or radio frequency signals are sensitive to power supply noise. Therefore, it’s always a good idea to include a decoupling capacitor across the power supply line. The capacitor can be anything from 10uF to 100uF. NRF24L01 Troubleshooting- decoupling capacitor and external power supply Another common issue is that the 3.3V pin of the Arduino boards, cannot always supply enough power to the NRF24L01 module. So, powering the module with an external power source is also a good idea. Fixing NRF24L01+ Modules Without Going (Too) Insane https://hackaday.com/2021/01/22/fixing-nrf24l01-modules-without-going-too-insane/ Ich habe auch irgendwo bei Hack-A-Day gelesen, daß es evtl. besser ist einen Elko mit ca. 100uF und 25V und ein Tantalum Cap mit 1-10pF parallel anzuklemmen um sowohl hoch- als auch niederfrequente Teile der Versorgungsspannung zu glätten. Bei mir läuft es (das o.g. PA Modul mit Antenne und ohne Schirmung vom maker"laden") ganz ohne Elko, etc. Ich würde daher empfehlen drei Plätze vorzusehen, für den Elko, für den Tantalum und einen für die Lötbrücke, am besten die Lötbrücke fest verdrahten zum raus-cuttern, wenn man die Elkos und/oder Tantalum einbaut.
:
Bearbeitet durch User
Hallo Daniel, mach doch mal ein Issue auf Github auf, damit wir dort die Punkte für den MI-Wechselrichter abstimmen, hier gehen die Punkte m.E. etwas verloren, da ja auch noch andere Diskussionen ablaufen ? Daniel M. schrieb: > Wo kommen "normal" und "roller" her, was ist das? > > Wie genau wird die mPayload zusammengebaut? Wofür stehen die > ".data"-Adressen? >
1 | > memcpy(mPayload[iv->id].data[3], &p->packet[16], len-9); |
2 | > mPayload[iv->id].len[3] = len-8; |
3 | >
|
> > Ich denke, so langsam verstehe ich, was passiert. normal und roller habe ich bei mir noch gar nicht gesehen... "roller" z.B. kann ich auch im repo von grindylow/ahoy nirgends finden ? mPayload ist eine Struktur, mit einem data[] Array. In data[0..3] werden Deine vier Antworten bzw. die Daten davon, also alles ab packet[10..len] abgelegt, das sind dann len-10 bytes. in len[0..3] wird die Länge der jeweiligen Daten im Packet abgelegt, also die len-10 bytes. Bei diesem Vorgang werden die Daten mit der memcpy(ziel, anfang_quelle, länge) Funktion kopiert. Die Länge ist nur ein Wert, der wird direkt zugeordnet. Das heißt am Ende hast Du in mPayload.data[0..3] Deine Daten, ohne die Adressen und die Antwort ID 0x88/0x89,0x91/0x92. Weil die Daten beim HM-Wechselrichter unterschiedlich lang sein können, vor allem das letzte Paket ist i.d.R. nicht 12 Byte lang, deshalb gibt es das len[0..3] Feld in dem die jeweilige Länge steht. Der HM-Wechselrichter hat dann in den letzten beiden Bytes des letzten Pakets noch eine Prüfsumme (CRC-M/CRC-16) stehen, die in buildPayload geprüft wird. Da die MI-Baureihe keine zweite Quersumme hat, kann der Teil m.E. entfallen. Du mußt also nur die Daten in processPayload den entsprechenden Werten zuordnen und ggf. durch 100 oder 1000 teilen. Das wird in hmDefines.h für jeden HM-Wechselrichter definiert und dann nach diesen Vorgaben umgerechnet.
:
Bearbeitet durch User
MI-1500 ======== Limitierung laeuft! Hier als Bsp. die Limitierung auf 5% (5a:5a:05:) Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90: 00 1284227201 0066 0C 3 D1 63707160 63707160 5A5AD1272F 1 Rcv... auf 0x51 cmd=0xD1 (korrekt) WR zeigt Status 8 > PVs sind ausgeschaltet, weil bei MI unter 10% nicht limitiert werden kann Send... CH3 38:63:70:71:60:72:22:84:12:00:fc: Send... CH23 39:63:70:71:60:72:22:84:12:00:fd: Send... CH40 36:63:70:71:60:72:22:84:12:00:f2: Send... CH61 37:63:70:71:60:72:22:84:12:00:f3: 00 1284227201 00DA 1B 1 B7 63707160 63707160 01C900000941138700050062017E081F01ADC76E 1 PV:2 0.50W 45.70V 0.00A 98.00Wh 236.90V 49.99Hz 38.20C Sts:8 Cnt:31 Send... CH3 39:63:70:71:60:72:22:84:12:00:fd: Send... CH23 36:63:70:71:60:72:22:84:12:00:f2: Send... CH40 37:63:70:71:60:72:22:84:12:00:f3: Send... CH61 38:63:70:71:60:72:22:84:12:00:fc: 00 1284227201 00DA 1B 1 B8 63707160 63707160 01C1000009441387000700B5017D081F01793AD4 1 PV:3 0.70W 44.90V 0.00A 181.00Wh 237.20V 49.99Hz 38.10C Sts:8 Cnt:31 Send... CH75 39:63:70:71:60:72:22:84:12:00:fd: Send... CH23 37:63:70:71:60:72:22:84:12:00:f3: Send... CH40 38:63:70:71:60:72:22:84:12:00:fc: 00 1284227201 00D8 1B 0 B9 63707160 63707160 01C10000093C138700050001017D081F01B6D1BA 1 PV:4 0.50W 44.90V 0.00A 1.00Wh 236.40V 49.99Hz 38.10C Sts:8 Cnt:31
Hallo Forum! Eine Frage treibt mich um: Bei uns wurde ein STP 5.0-3SE-40 / SMA SUNNY TRIPOWER 5.0 - SMART ENERGY verbaut. Vielleicht findet die Schwarmintelligenz (?) auch darauf eine Antwort: Gilt das in den letzten 1270 Beiträgen Gesagte dafür auch? LG Steffi
Ziyat T. schrieb: > MI-1500 > ======== > Limitierung laeuft! > Hi, wie ich sehe ist auch bei Dir die Spannung an den Modulen 3/4 und 1/2 identisch. Das liegt am Code im Decoder da hier die gleichen Bytes aufgelöst werden. Allerdings ist in der Antwort vom Umrichter auch keine weitere Information zu den Spannungen drin. (Es fehlen schlicht Bytes rein rechnerisch) Es gibt meinerseits zwei Vermutungen: 1. Das ist im Umrichter intern so verschaltet, dass die Module 3/4 und 1/2 jeweils am gleichen Potential hängen. 2. Den Wert gibt es schlicht nicht. (Die Leistung ist ja individuell für jede der vier Module / Eingänge und wird auch ausgegeben) Sonst noch Erklärungen? Grüße Andreas
Steff schrieb: > Hallo Forum! > > Eine Frage treibt mich um: Bei uns wurde ein STP 5.0-3SE-40 / SMA SUNNY > TRIPOWER 5.0 - SMART ENERGY verbaut. Vielleicht findet die > Schwarmintelligenz (?) auch darauf eine Antwort: Hallo Steff Hier geht es nur um die Hoymiles Inverter, leider keine Lösung für den SMA SUNNY TRIPOWER hier
Ziyat T. schrieb: > MI-1500 > ======== > Limitierung laeuft! Sehr sehr cool schonmal. Unabhängik davon, konnte jemand schon was beim HM-1500 oder kleiner, etwas erreichen? Die Dokus von Gitee sind ja fast ausschlieslich für MI bezogen, oder hab ich was übersehen?
Angehängte Dateien:
Andreas S. schrieb: > Ziyat T. schrieb: >> MI-1500 >> ======== >> Limitierung laeuft! >> > Hi, > > wie ich sehe ist auch bei Dir die Spannung an den Modulen 3/4 und 1/2 > identisch. Das liegt am Code im Decoder da hier die gleichen Bytes > aufgelöst werden. > Allerdings ist in der Antwort vom Umrichter auch keine weitere > Information zu den Spannungen drin. (Es fehlen schlicht Bytes rein > rechnerisch) > Es gibt meinerseits zwei Vermutungen: > 1. Das ist im Umrichter intern so verschaltet, dass die Module 3/4 und > 1/2 jeweils am gleichen Potential hängen. > 2. Den Wert gibt es schlicht nicht. (Die Leistung ist ja individuell für > jede der vier Module / Eingänge und wird auch ausgegeben) > > Sonst noch Erklärungen? > > Grüße > Andreas Hallo Andreas MI hat 2 MPPTs für 4PVs Module 1/2 am MPPT1 Module 3/4 am MPPT2 Die Grafik zeigt es auch, ich denke die hängen am gleichen Potential
:
Bearbeitet durch User
Beitrag #7103821 wurde vom Autor gelöscht.
Daniel R. schrieb: > Ziyat T. schrieb: >> MI-1500 >> ======== >> Limitierung laeuft! > > Sehr sehr cool schonmal. Unabhängik davon, konnte jemand schon was beim > HM-1500 oder kleiner, etwas erreichen? > > Die Dokus von Gitee sind ja fast ausschlieslich für MI bezogen, oder hab > ich was übersehen? Danke, es hat ja ziemlich lange gedauert... Richtig, in den Dokus hab ich auch nichts extra für HM gesehen, aber das Modbus-Doku beschreibt die gleiche Limitierung-Register für alle WR-Modelle, vielleicht geht es auch mit dem HM
Das probiere ich Zuhause dann aus! =) Ziyat T. schrieb: > Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90: > 00 1284227201 0066 0C 3 D1 63707160 63707160 5A5AD1272F 1 Könntest du bitte ein Auszug von deinem Code durch geben? Ich würde es ca. so abschicken. (Habe aktuell noch nicht viel abgeschickt) Kümmere mich gerade um die Einbindung in 'Home Assistant' über MQTT. Dort will ich es als Entität einbinden und später mit Grafana noch anzeigen.
1 | payload={0x5a, 0x5a, 0x05}
|
2 | request=next(hoymiles.compose_esb_packet(payload,seq=b'\x80',src=dtu_ser,dst=inverter_ser))) |
:
Bearbeitet durch User
Daniel R. schrieb: > Das probiere ich Zuhause dann aus! =) > > Ziyat T. schrieb: >> Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90: >> 00 1284227201 0066 0C 3 D1 63707160 63707160 5A5AD1272F 1 > > Könntest du bitte ein Auszug von deinem Code durch geben? > >>> payload={0x5a, 0x5a, 0x05} 0x05 ist % die Limitierung also hier 5% der angeschlossene Nennleistung. Ich verwende immer noch die Hubi's SW auf Arduino, es wird hier gesendet: void isTime2Send () { //----------------- int32_t size = 0; uint64_t dest = WR1_RADIO_ID; uint8_t UsrData[5]; // Second timer if (millis() >= tickMillis) { static uint8_t tel = 0; tickMillis += 500; //200; //tickSec++; hmPackets.UnixTimeStampTick(); /* if (++tickSec >= 5) { // 5 hmPackets.UnixTimeStampTick(); tickSec = 0; } */ if (tel > 5) { tel = 0; } if (COMMAND > 0x0039) COMMAND= 0x0036; if (tel == 0) {// Limitierung Command 0x51 //set SubCmd and UsrData UsrData[0]=0x5A;UsrData[1]=0x5A;UsrData[2]=0x0a;// 10% limit size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, 0x51, UsrData,3); } else { UsrData[0]=0x0;//set SubCmd and UsrData size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, DTU_RADIO_ID >> 8, COMMAND, UsrData,1); } // DEBUG_OUT.print(F("size: ")); DEBUG_OUT.print(size); SendPacket(dest, (uint8_t *)&sendBuf, size); tel++; COMMAND++; /* for (uint8_t warte = 0; warte < 2; warte++) { delay(1000); hmPackets.UnixTimeStampTick(); }*/ } //if millis }
Stefan T. schrieb: > Ich würde daher empfehlen drei Plätze > vorzusehen, für den Elko, für den Tantalum und einen für die Lötbrücke, > am besten die Lötbrücke fest verdrahten zum raus-cuttern, wenn man die > Elkos und/oder Tantalum einbaut. Wenn die beschriebene Lötbrücke/Stelle zum Raus-Cuttern nur die Kondensatoren betrifft, braucht man das nicht vorzusehen: Bei Kondensatoren reicht bestücken oder nicht bestücken.
Daniel R. schrieb: > Das probiere ich Zuhause dann aus! =) Habe ein HM-1500! Folgende Antwort habe ich erhalten: Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 05 70 ab 7a Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 05 70 ab 7a Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b Edit: Habe das ganze mal mit '\x5a\x5a\x01' (1% P-Limit?) gemacht. Bekomme dann das hier, was könnte das alles sein?:
1 | Poll inverter 116174403329 |
2 | 2022-06-21 15:49:21.612117 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc |
3 | 2022-06-21 15:49:22.848184 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc |
4 | 2022-06-21 15:49:22.888219 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
5 | 2022-06-21 15:49:23.391443 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
6 | payload has valid modbus crc |
7 | payload has 14 bytes |
8 | |
9 | Field view: int |
10 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
11 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
12 | >B 128 0 0 0 0 0 0 0 0 0 0 0 0 1 |
13 | |
14 | Field view: shorts |
15 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
16 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
17 | >H 32768 0 0 0 0 0 1 |
18 | >H 0 0 0 0 0 0 |
19 | |
20 | Field view: longs |
21 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
22 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
23 | >L 2147483648 0 0 |
24 | >L 0 0 0 |
25 | >L 0 0 1 |
26 | >L 0 0 |
27 | type utf-8 : utf-8 decode error |
28 | type ascii : ascii decode error |
29 | Poll inverter 116174403329 |
30 | 2022-06-21 15:49:23.395573 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc |
31 | 2022-06-21 15:49:23.441496 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
:
Bearbeitet durch User
Hallo Ziyat T., Gratuliere zur MI-1500 Limitierung! @Daniel R., Ziyat schickt ein Cmd 0x51, Du schickst nach wie vor ein 0x15 Cmd das kann also auch mit dem HM-1500 nur schiefgehen. Und die Implementierung für HM-1500 etc. steckt wie für alle Hoymiles Generation 3 Geräte in der usart_nrf3.c, die die weiterhin genutzten Grundfunktionen der MI- und HM-Geräte der Generation 2 in usart_nrf.c erweitern / vervollständigen. Lad den ganzen Code doch mal in VSCode oder einer anderen IDE Deines Vertrauens? @Günther H., danke für die Korrektur! Irgendjemand schrieb was von Drahtbrücke einlöten. Aber so ein Kurzschluss zwisch +3V3 und GND ist natürlich elektronischer Blödsinn =^!
IsnoAhoy schrieb: > Ziyat schickt ein Cmd 0x51, Du schickst nach wie vor ein 0x15 Cmd das > kann also auch mit dem HM-1500 nur schiefgehen. Das ist mir auch aufgefallen, habe es dann korriegiert und erneut getestet. Um denn WR in seiner Leistung zu drossel, sendet man ja folgenden Befehl ab:
1 | CMD (data )<value> |
2 | Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e |
3 | Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e |
4 | Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
5 | Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
Nun wollte ich die Drosselung auslesen, jedoch kommt immer beim senden 2b automatisch dazu (ohne mein willen)... Wieso?
1 | CMD (data ) <value?> |
2 | Transmit 15 | [d1] 74 40 33 29 78 56 30 01 80 (5a 5a) <2b> bb f0 |
3 | Received 15 bytes channel 61: [d1] 74 40 33 29 74 40 33 29 80 (5a 5a) <2b> bb c1 |
4 | Error while retrieving data: int too big to convert |
:
Bearbeitet durch User
Daniel R. schrieb: > Daniel R. schrieb: >> Das probiere ich Zuhause dann aus! =) > > Habe ein HM-1500! > > Poll inverter 116174403329 > 2022-06-21 15:49:23.395573 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 > 5a 5a 01 b3 aa bc > 2022-06-21 15:49:23.441496 Received 27 bytes channel 75: f1 74 40 33 29 > 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b > > [/code] Wenn dein Inverter die SN 116174403329 hat, dann müsste dein Packet zum Senden etwa so sein: WR= 29 33 40 74 DTU= 78 56 30 01 (nehme ich mal an) Command= 51 für Limitierung (früher MID) SubCommand= 5a 5a (früher CMD aber nur 1 byte!) UserData= 05 (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%) ergibt CRC=90 51 74 40 33 29 78 56 30 01 5a 5a 0b 90 aber du schickst: 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 ??? 15 ist, glaube, ein MID für Timepacket, 80 CMD für WR-Data wenn ok, dann bekommst du als Bestaetigung CMD = 0xD1 Hier nochmals wie bei mir: Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90: Receive... 00 1284227201 0066 0C 3 D1 63707160 63707160 5A5AD1272F 1 Ich glaube, du musst das Senden für Command=0x51 sep. neu programmieren. Die bisher verwendeten Bezeichnungen MID und CMD sind nun etwas unglücklich, denn es gibt viele Kontroll Befehle/Commands mit SubCommands und Userdata, wie die Limitierung eben.
Hallo Zusammen, ich verfolge seit einiger Zeit diesen Thread und bin beeindruckt von der Professionalität und was man mit einer guten Zusammenarbeit gemeinsam erreichen kann ... Jetzt versuche ich das System (esp8266 und nRF24L01) zum Laufen zu bringen. Aktuelle nutze ich Version 0.4.19 ich komme leider nicht weiter, denn ich bekomme die folgende Fehlermeldung: W: WARNING! your NRF24 module can't be reached, check the wiring I: [NTP]: 2022-06-20 23:14:32 I: Inverter #1 I: no Payload received! (retransmits: 0) I: Requesting Inverter SN 116174401924 I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 00 05 00 00 00 00 7F EC 7C E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 00 05 00 00 00 00 7F EC 7C pm open,type:2 0 E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 00 05 00 00 00 00 7F EC 7C folgendes habe ich schon versucht: 1) Tausch des NRF24 moduls 2) verschiedene Varianten der Verdrahtung (CE,CS,IRQ) 3) 10µF Kondensator zwischen GRND und 3,3V Aber alles hat keinen Einfluss auf die Fehlermeldung. Vielleicht kann mir jemand helfen, wäre doch schade, wenn ich kurz vor dem Ziel scheitere. LG Herbert
@Daniel R. Ziyat T. schrieb: > WR= 29 33 40 74 > DTU= 78 56 30 01 (nehme ich mal an) > Command= 51 für Limitierung (früher MID) > SubCommand= 5a 5a (früher CMD aber nur 1 byte!) > UserData= 05 (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%) > ergibt CRC=90 sorry, in dem Fall ist der CRC natürlich nicht 0x90, ich meinte nur als Bsp.
Also ich bekomme es gerade nicht ganz hin... Transmit 15 | 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5 Statt letzten drei bytes, soll nur ein byte für CRC geschickt werden. Aber irgendwie wird im Python code angehängt.
:
Bearbeitet durch User
Daniel R. schrieb: > Also ich bekomme es gerade nicht ganz hin... > > Transmit 15 | 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5 > > Statt letzten drei bytes, soll nur ein byte für CRC geschickt werden. > Aber irgendwie wird im Python code angehängt. - ist die CRC=0xb4 für 0x51 bis 0xb richtig? - wurde die buffer len des Pakets zum Senden richtig übergeben?
Genau da bin ich aktuell dran, aber ich finde nirgendwo eine Angabe wie lang das Paket seien soll. - Ich mach mal ein cut. Hab schon ewig nicht mehr mit Python mich ausseinander gesetzt. Ziyat T. schrieb: > - ist die CRC=0xb4 für 0x51 bis 0xb richtig? Glaube ich nicht, da die CRC erst am ende angehängt wird. Ziyat T. schrieb: > - wurde die buffer len des Pakets zum Senden richtig übergeben? von meiner Seite 'noch?' nicht. Beim debuggen sehe ich das meine payload genau 3 bytes lang ist '5a 5a 0b'. Das passt. Nur der hintere Teil ist für mich gerade sehr gespenstig! :( Der ganze Python script steckt ja noch in den Kinderschuhen. Gruß
:
Bearbeitet durch User
Hallo zusammen, ich möchte mich ganz herzlich für die tolle Arbeit bedanken! Ich nutze seit ein paar Tagen Ahoy-esp8266 mit einem HM1500 und es war super easy einzurichten und alles scheint zu funktionieren. Eine Frage: darf/soll ich in der Readme bei esp8266 den HM1500 ergänzen? In anderen Worten, ist die Datei veraltet oder gibt es einen Grund, warum ihr den HM1500 nicht aufführt? Und ich kann sogar etwas beitragen: ich habe ein kleines Gehäuse entworfen für den 3D Drucker... die Dateien findet Ihr auf https://www.printables.com/model/229686-box-case-housing-for-wemos-d1-mini-and-nrf24l01-fo zum selber drucken, anpassen, drucken lassen... Und als Dankeschön von mir an alle Programmierer: wer hier beigetragen hat und so ein Gehäuse gerne hätte braucht sich nur zu melden. :) Vielen Dank und Grüße Seekerbot
Angehängte Dateien:
Hallo Daniel R., anbei nochmal ein Screenshot aus den RF_communication_protocol_v6.5.xlsx als Wink mit der Dokumentation des Herstellers. Daniel R. schrieb: > Genau da bin ich aktuell dran, aber ich finde nirgendwo eine Angabe wie > lang das Paket seien soll. - Ich mach mal ein cut. Hab schon ewig nicht > mehr mit Python mich ausseinander gesetzt. > > Ziyat T. schrieb: >> - ist die CRC=0xb4 für 0x51 bis 0xb richtig? Gute Frage Ziyat, die Antwort muß Daniel sich noch geben: Das ist auf jeden Fall um zwei Bytes zu lang! 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5 So lang sollte es maximal sein und anstelle von 0xb4 muß da definitiv die richtige CRC-8 hin, sonst verwirft es der WR gleich wieder und antwortet mit nem Fehler: <51> <74 40 33 29> <78 56 30 01> <5a 5a> <0b> <b4> <CMD> <WR Addresse> <DTU Adresse> <SubCmd> <10%> CRC8 1,2,3,4, ... 12 Bytes plus ein Byte CRC8. Warum steht da bei Dir Daniel eigentlich 78 56 30 01 und nicht die sonst übliche DTU Addresse 78 56 34 12 ?
Angehängte Dateien:
-
AHOY_Breadboard_1.jpg
280 KB -
AHOY_Verdrahtungshilfe_nRF24.jpg
400 KB -
AHOY_Breadboard_3.jpg
470 KB
IsnoAhoy schrieb: > Wenn > ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und > Raspberry Pi hochladen. Das wäre sehr cool! Ich habe meine NodeMCU auf einem freien Rest Breadboard zusammengesteckt, wobei die NodeMCU ja dann leider "unter" der Platine zu verdrahten ist (Fotos) weil sie zu breit für Breadboards ist. Die Kabelfarben zum nRF24 habe ich 1:1 übernommen, die waren im Wemos-Fritzing schon top gewählt! Aber die Drahtbrücken für das Breadboard hatte ich nicht in den nötigen Farben. Hier ging nur, was noch in der Kiste übrig war. Vielleicht ist meine Fotosammlung eine Anregung für Zögerliche, endlich auch loszulegen? Ja, ja, Breadboard und Brücken sind unzuverlässig, ich weiss. Aber es läuft und nichts hält länger als ein Provisorium... Der Breadboard-Aufbau läuft auch in kleinster Sendeleistung um eine Hausecke herum (Poroton und Klinker) und entweder durch die Panels oder um die Panels herum. Es sind ca. 10 m Entfernung zum HM-1500. und in 4 m Entfernung funkt noch ein DTU-WLite. Allerdings benutze ich für die AHOY-nRF24 eine über 50 Jahre alte, hölzerne Statue zweier lokaler Superhelden ;-) vielleicht macht's das XD
Hallo Herbert S., schau doch mal bitte im Github Issue #36 vorbei. Da diskutieren wir das bzw. ähnliche Probleme bei der Schaltung mit der ESP8266 Software. ESP8266: Discussion Verkabelung / Pinout #36 https://github.com/grindylow/ahoy/issues/36 Das hier sagt eindeutig, daß er das NRF24 Modul nicht erreichen kann: W: WARNING! your NRF24 module can't be reached, check the wiring Die darauf folgenden anderen Versuche mit der fehlenden / falschen Konfiguration zu senden schlagen natürlich fehl. Schau doch mal bitte im Setup Menü nach den dort hinterlegten Pin Einstellungen und speichere alles noch Mal. Eventuell muß man auch alle 0xFF oder sonstigen Werte aus den anderen Feldern nochmal entfernen und die Settings speichern und den ESP rebooten (Flag ganz unten links). Wichtig wäre auf jeden Fall welches ESP8266 Modul Du verwendest und welches nRF24L01+ Modul Du hast. Vielleicht kannst Du dort auch mal Deine Schaltung und die Konfiguration (Screenshot aus der Setup Seite) hochladen ?
:
Bearbeitet durch User
Ziyat T. schrieb: > Richtig, in den Dokus hab ich auch nichts extra für HM gesehen, aber > das Modbus-Doku beschreibt die gleiche Limitierung-Register für alle > WR-Modelle, vielleicht geht es auch mit dem HM Wie oben erwähnt, läuft mein HW-15000 mit AHOY / ESP8266 ver 0.4.19, selbst compiliert (nutze ohnehin gelegentlich ArduinoIDE oder VSCode) und ich kann gerne Patches oder andere Programme von Euch übernehmen und ausprobieren. Habe ein Messgerät auf der Hutschiene, kann also recht schnell in echt sehen, was Änderungen bewirkt haben. Nur leider den RS485 am Stromzähler verplombt bekommen :,-( Was ich mangels DTU-Pro nicht kann, ist sniffen, welche Kommandos der senden würde. Abends zwischen 18:00 und Sonnenuntergang kann ich oft noch was testen. Einfach bescheid sagen...
Angehängte Dateien:
Herbert S. schrieb: > Vielleicht kann mir jemand helfen, wäre doch schade, wenn ich kurz vor > dem Ziel scheitere. Ich nutze diese NodeMCU von AZ-Delivery (weil sie hier rumliegen): "AZDelivery 3 x NodeMCU Lolin V3 Module ESP8266 ESP-12F WiFi WiFi Development Board mit CH340" und "NRF24L01+ PA LNA SMA" von Makershop.de. Ganz primitiv auf einem Breadboard gesteckt, also eher "schlecht" verdrahtet, wenn man Bedenken bzgl. der Spannungsstabilität am NRF24 hat. (Fotos: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") Kein Elko, keine Tantalperle, keine separate 3V3 Versorgung! CSN => D8 CE => D4 IRQ => D3 Sendeleistung auf Min oder Low (bei mir egal). Lief sofort (nachdem ich ein Micro-USB-Kabel ausgewechselt habe, aber mit dem vorigen Kabel war schon der COM-Port in der Systemsteuerung und ArduinoIDE nicht sichtbar - also eher nicht das Problem, das Du hast). Habe damit ab und zu Falsch-Anzeigen und in der Statistik etwa 20% Fehler, aber läuft erstmal. Vielleicht MOSI und MISO vertauscht?
Angehängte Dateien:
-
IMG_7572.jpg
230 KB -
IMG_7573.jpg
240 KB
Hallo Maik R., >> Wenn ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und >> Raspberry Pi hochladen. > Das wäre sehr cool! habe mal schematics und fritzing für Arduino, Raspberry Pi und ESP8266 (NodeMCU) in mein github eingecheckt. https://github.com/grindylow/ahoy/pull/80/commits/6015cbe0729ec13661a7229fdb15b90b587395d9 Mal sehen wann Lukas den PR mergen kann. > Allerdings benutze ich für die AHOY-nRF24 eine über 50 Jahre alte, > hölzerne Statue zweier lokaler Superhelden ;-) vielleicht macht's das XD Ja die sind schick, nur leider sieht man auf dem Photo die Gesichter der Beiden nicht =^D Hier im Anhang die Bildchen von meinem Aufbau mit NodeMCU. Auf meinem großen Breadboard passt der ESP gerade so zwischen zwei Reihen, daß noch bißchen mehr Platz für die Kabel übrig ist. Das ist ein echter Nachteil von dem Modul: der Platz auf dem Breadboard =^D
Stefan T. schrieb: > Gute Frage Ziyat, die Antwort muß Daniel sich noch geben: Das ist auf > jeden Fall um zwei Bytes zu lang! > 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5 Richtig, das habe ich gestern auch so geschrieben. Vielleicht mit anderen worten (irgendwann sieht man den Wald vor lauter Bäumen nicht mehr => hab eine Pause gebraucht). > So lang sollte es maximal sein und anstelle von 0xb4 muß da definitiv > die richtige CRC-8 hin, sonst verwirft es der WR gleich wieder und > antwortet mit nem Fehler: > <51> <74 40 33 29> <78 56 30 01> <5a 5a> <0b> <b4> > <CMD> <WR Addresse> <DTU Adresse> <SubCmd> <10%> CRC8 > 1,2,3,4, ... 12 Bytes plus ein Byte CRC8. Richtig, daran werde ich mich heute nochmal hinsetzen. > Warum steht da bei Dir Daniel eigentlich 78 56 30 01 und nicht die sonst > übliche DTU Addresse 78 56 34 12 ? Ui, das ist ja Interessant! Ähm, hmm... auf der Seite 5 in diesem Thread war es noch richtig bei mir in der Log. Danke für denn Hinweis, ich werde mal drauf schauen. =) Edit: Stimmt jetzt weiß ich es wieder! Hatte vorher das ganze in die 'Home Assistant' eingebunden und zu Testzwecken habe ich den Wert geändert. Wahrscheinlich vor euphorie dann vergessen es wieder zu ändern. Hupps. ^^
:
Bearbeitet durch User
Hallo Stefan T., vielen Dank für die Hilfe. Habe das System mittlerweile am Laufen. Ich hatte die Kabel für MISO und MOSI vertauscht. LG Herbert
Hallo zusammen, manchmal hilft es eine Nacht darüber zu schlafen. :) Hab meinen Fehler gefunden... trotzdem keine Rückantwort. WR= 74 40 33 29 DTU= 78 56 34 12 Command= 51 SubCommand= 5a 5a UserData= 05 (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%) CRC= 72
1 | Poll inverter 116174403329 |
2 | 2022-06-22 14:58:37.633634 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72 |
3 | 2022-06-22 14:58:38.870592 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72 |
4 | 2022-06-22 14:58:40.107719 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72 |
Laut Excel Protokoll gab es denn Befehl zum auslesen der eingestellen Leistung. - Das kam dabei bei mir heraus:
1 | 2022-06-22 15:07:10.486528 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a 5a f7 |
2 | 2022-06-22 15:07:11.721448 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a 5a f7 |
3 | 2022-06-22 15:07:11.760218 Received 12 bytes channel 61: d1 74 40 33 29 74 40 33 29 5a 5a d1 |
Ich lese das hierbei so: CMD | WR | WR | 5a 5a | CRC?
:
Bearbeitet durch User
Daniel R. schrieb: > Laut Excel Protokoll gab es denn Befehl zum auslesen der eingestellen > Leistung. - Das kam dabei bei mir heraus: > > [code] > 2022-06-22 15:07:10.486528 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a > 5a f7 Hallo Daniel Nach meiner Lesung, es gibt keinen Befehl zum Auslesen der Limitierung. Das command=0xD1 ist die Bestaetigung/Antwort auf 0x51. Anfrage mit 0x51, Antwort drauf 0xD1, es wird immer bei der Antwort 8.Bit gesetzt. Also somit kannst du diesen Befehl nicht schicken: > 2022-06-22 15:07:11.721448 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a > 5a f7 Wenn du ihn schickst, bekommst einfach ein Echo.
Limitierung: Es ist mir noch was aufgefallen: Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90: 00 1284227201 0064 0C 2 D1 63707160 63707160 5A5AD1ADE9 1 51 cmd=D1 Die 0xD1 Antwort bekomme ich nur wenn ich das 0x51 über CH61 sende. Ich muss es noch laengere Zeit beobachten....
Ähm, ich schau mal ob es bei mir auch damit zusammen hängt mit CH61. Ziyat T. schrieb: > Nach meiner Lesung, es gibt keinen Befehl zum Auslesen der Limitierung. Ahh glaube jetzt verstehe ich was das Protokoll in der Excel Tabelle meint, wenn ich denn Befehl abgeschickt wurde, bekommt man eine Quittung zurück. Die ist gleich wie der Befehl abgeschickt wurde, nur ohne SubCMD. Edit: So, ich schicke es auf CH61 raus. Leider ohne erfolg. =( Edit: Habe nun folgende CH durch probiert. tx_channel_list = [3,23,40,61,75]
:
Bearbeitet durch User
Hallo zusammen, ich habe das Platinen Layout nun um die Kondensator Möglichkeit und den Spannungsregler für den RF24 erweitert. Vielen Dank für die Hinweise und die Links zu den Erklärungen. Bevor ich nun die Dingen fertigen lasse, macht mir noch Sorge das mein Prototype den ich auf einem Breadboard aufgebaut habe sehr häufig neu bootet. Auch nachdem ich nun den Spannungsregler und den Elko 100uF nachgerüstet habe schafft der Wemos keine langen UpTimes. Das längste waren so ca 6 Stunden. Spannungsversorgung ist derzeit noch ein USB Netzteil Liegt das an der Breadboard Verkabelung ? Wie sind Eure Erfahrungen mit der UpTime ? Glücklicherweise gehen ja bei einem reboot die Werte nicht verloren, aber das ja auch nicht so bleiben. Sonst läuft alles recht reibungslos. Ich habe nur 3 fails bei meinen 3 HM-300 Invertern. Diese kommen immer beim Booten zu Stande wenn die ersten Abfragen in lehre gehen.
Hallo Leute, beeindruckend was ihr hier macht und schon erreicht habt. Ich verfolge diesen Thread schon seit Beginn. Nun habe ich mir das ahoy 0.4.19 bi binary auf einen ESP8266 geflashed. Zusammen mit einem NRF24L01+ Long Range mit Antenne hat das sofort funktioniert und läuft stabil. Vielen Dank an Euch. Ich habe zwei HM-600 mit jeweils 2 PV Module und einen HM-300, den ich für einen Pufferspeicher einsetzen möchte. Derzeit verwende ich die Batterie meines Elektrorollers. Eine Leistungsbegrenzung des HM-300 wäre dafür perfekt. Ich arbeite viel mit ESP8266 und Raspberry aber nur low-code. (ESPEasy, Tasmota, Node Red, FHEM, ..) Wäre es möglich eine Version zu bauen, die über MQTT Raw Daten an die Wechselrichter sendet und empfängt? Ich könnte mich dann beim Testen beteiligen. Grüße, Stefan
Habe jetzt für den MI/TSUN das ganze soweit, dass ich: - alle Pakete sehe - immer wieder, noch unzyklisch, requests sende - die Fehlermeldungen reduziert habe (wie auch immer das passiert ist) - einen Teil der Payload des Inverter in die Payload übertragen bekomme - den Teil der Payload angezeigt bekomme Payload Inverter:
1 | Received 18 bytes channel 75: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 |
2 | Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 44 00 15 09 52 13 8A 02 A0 07 DD 01 A5 DF |
3 | |
4 | Received 18 bytes channel 61: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B |
5 | Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 3E 00 15 09 52 13 8A 02 9C 08 51 01 A5 02 |
Payload zusammengebaut:
1 | Payload (32): 00 03 00 00 00 00 00 00 8B 01 3E 00 15 09 52 13 8A 00 03 00 00 00 00 00 00 91 01 44 00 15 09 52 |
Decode (auf Konsole):
1 | 17:34:13.185 -> I: Vordach/ch1/U_DC: 31.000 V |
2 | 17:34:13.185 -> I: Vordach/ch1/I_DC: 4.600 A |
3 | 17:34:13.185 -> I: Vordach/ch1/U_AC: 238.500 V |
4 | 17:34:13.185 -> I: Vordach/ch1/Freq: 50.010 Hz |
5 | 17:34:13.185 -> I: Vordach/ch0/U_AC: 238.500 V |
6 | 17:34:13.219 -> I: Vordach/ch0/Freq: 50.010 Hz |
7 | 17:34:14.222 -> I: Vordach/ch1/U_DC: 31.000 V |
8 | 17:34:14.222 -> I: Vordach/ch1/I_DC: 4.600 A |
9 | 17:34:14.222 -> I: Vordach/ch1/U_AC: 238.500 V |
10 | 17:34:14.222 -> I: Vordach/ch1/Freq: 50.010 Hz |
11 | 17:34:14.222 -> I: Vordach/ch0/U_AC: 238.500 V |
12 | 17:34:14.222 -> I: Vordach/ch0/Freq: 50.010 Hz |
13 | 17:34:15.193 -> I: Vordach/ch1/U_DC: 31.000 V |
14 | 17:34:15.193 -> I: Vordach/ch1/I_DC: 4.600 A |
15 | 17:34:15.193 -> I: Vordach/ch1/U_AC: 238.500 V |
16 | 17:34:15.193 -> I: Vordach/ch1/Freq: 50.010 Hz |
17 | 17:34:15.193 -> I: Vordach/ch0/U_AC: 238.500 V |
18 | 17:34:15.193 -> I: Vordach/ch0/Freq: 50.010 Hz |
19 | 17:34:16.227 -> I: Vordach/ch1/U_DC: 31.000 V |
20 | 17:34:16.227 -> I: Vordach/ch1/I_DC: 4.600 A |
21 | 17:34:16.227 -> I: Vordach/ch1/U_AC: 238.500 V |
22 | 17:34:16.227 -> I: Vordach/ch1/Freq: 50.010 Hz |
23 | 17:34:16.227 -> I: Vordach/ch0/U_AC: 238.500 V |
24 | 17:34:16.227 -> I: Vordach/ch0/Freq: 50.010 Hz |
hmDefines enum:
1 | enum {INV_TYPE_1CH = 0, INV_TYPE_2CH, INV_TYPE_4CH, MI_INV_TYPE_1CH, MI_INV_TYPE_2CH, MI_INV_TYPE_4CH}; |
hmDefines Werte:
1 | //MI-Version
|
2 | { FLD_UDC, UNIT_V, CH1, 9, 2, 10 }, |
3 | { FLD_IDC, UNIT_A, CH1, 11, 2, 10 }, |
4 | { FLD_UAC, UNIT_V, CH1, 13, 2, 10 }, |
5 | { FLD_F, UNIT_HZ, CH1, 15, 2, 100 }, |
6 | { FLD_PAC, UNIT_W, CH1, 17, 2, 10 }, |
7 | { FLD_YD, UNIT_WH, CH1, 19, 2, 1 }, |
8 | { FLD_T, UNIT_C, CH1, 21, 2, 10 }, |
9 | //{ FLD_YT, UNIT_KWH, CH1, 24, 0, 1 },
|
10 | { FLD_IRR, UNIT_PCT, CH1, CALC_IRR_CH, CH1, CMD_CALC }, |
11 | |
12 | { FLD_UDC, UNIT_V, CH2, 34, 2, 10 }, |
13 | { FLD_IDC, UNIT_A, CH2, 36, 2, 10 }, |
14 | { FLD_UAC, UNIT_V, CH2, 38, 2, 10 }, |
15 | { FLD_F, UNIT_HZ, CH2, 40, 2, 100 }, |
16 | { FLD_PAC, UNIT_W, CH2, 42, 2, 10 }, |
17 | { FLD_YD, UNIT_WH, CH2, 44, 2, 1 }, |
18 | { FLD_T, UNIT_C, CH2, 46, 2, 10 }, |
19 | // { FLD_YT, UNIT_KWH, CH1, 24, 0, 1 },
|
20 | { FLD_IRR, UNIT_PCT, CH2, CALC_IRR_CH, CH2, CMD_CALC }, |
21 | |
22 | // { FLD_UAC, UNIT_V, CH0, 26, 2, 10 },
|
23 | // { FLD_IAC, UNIT_A, CH0, 34, 2, 100 },
|
24 | { FLD_PAC, UNIT_W, CH0, 17, 2, 10 }, |
25 | { FLD_T, UNIT_C, CH0, 21, 2, 10 }, |
26 | { FLD_PAC, UNIT_W, CH0, 42, 2, 10 }, |
27 | { FLD_T, UNIT_C, CH0, 36, 2, 10 }, |
28 | { FLD_UAC, UNIT_V, CH0, 13, 2, 10 }, |
29 | { FLD_F, UNIT_HZ, CH0, 15, 2, 100 } |
Ich habe die Werte sowohl in einem eigenen Abschnitt als auch im 2-Kanal HM drin und wechsle die SN zwischen 1041 und 1141. Die Erkennung im Webinterface für 10xx funktioniert mit meiner Modifikation leider nicht, mittlerweile bekomme ich auf allen 3 möglichen Einträgen 4 Kanäle angezeigt, hier schaue ich noch. Die Payload wird nicht so zusammengebaut, wie ich ich es erwartet habe, in den meissten Fällen kriege ich entweder die Event-Daten oder die Leistungsdaten und bei denen wird jedoch noch nach 3-4 Werten abgeschnitten. Der erste Teil kommt meißt mit einer Länge 7 (statt 9) rein, der 2. wird mit 3 Werten angehängt, es fehlt ein Stück:
1 | Received 18 bytes channel 75: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B |
2 | |
3 | Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 38 00 2C 09 3C 13 88 05 37 08 18 01 C0 D1 |
4 | |
5 | Payload (7): 00 03 00 00 00 00 00 |
6 | Payload (15): 00 03 00 00 00 00 00 00 8B 01 38 00 2C 09 3C |
7 | Payload (24): 00 03 00 00 00 00 00 00 8B 01 38 00 2B 09 3E 13 88 00 03 00 00 00 00 00 |
Zwischendurch klappt das auch mit dem 2. Kanal, das ist allerdings eher Glückssache. Angezeigt/Dekodiert wird nur auf Kanal 1, egal welche Werte kommen. Auswertung:
1 | if(0 != len) { |
2 | Inverter<> *iv = mSys->findInverter(&p->packet[1]); |
3 | if(NULL != iv) { |
4 | uint8_t *pid = &p->packet[0]; //9 |
5 | if(*pid == 0x88) { // A Event |
6 | DPRINTLN(DBG_INFO, F("A Event")); |
7 | memcpy(mPayload[iv->id].data[0], &p->packet[9], len-9); |
8 | //DBGPRINT(String('mPayload[iv->id].data[1]', HEX) + String("\n"));
|
9 | mPayload[iv->id].len[0] = len-9; |
10 | }
|
11 | if(*pid == 0x89) { // A Data |
12 | DPRINTLN(DBG_INFO, F("A DATA")); |
13 | memcpy(mPayload[iv->id].data[1], &p->packet[9], len-16); |
14 | //DBGPRINT(String('mPayload[iv->id].data[0]', HEX) + String("\n"));
|
15 | mPayload[iv->id].len[1] = len-16; |
16 | }
|
17 | if(*pid == 0x91) { // B Event (or Data ?) |
18 | DPRINTLN(DBG_INFO, F("B DATA")); |
19 | memcpy(mPayload[iv->id].data[3], &p->packet[9], len-16); |
20 | mPayload[iv->id].len[3] = len-16; |
21 | }
|
22 | if(*pid == 0x92) { // B Data (or Event ?) |
23 | DPRINTLN(DBG_INFO, F("B EVENT")); |
24 | memcpy(mPayload[iv->id].data[2], &p->packet[9], len-9); |
25 | mPayload[iv->id].len[2] = len-9; |
26 | }
|
27 | |
28 | if( (*pid == 0x88) || (*pid == 0x89) || (*pid == 0x91) || (*pid == 0x92) ) { |
29 | if((*pid == 0x88) && (mPayload[iv->id].maxPackId < 1)) { //1 |
30 | mPayload[iv->id].maxPackId = 1; |
31 | mLastPacketId = *pid; |
32 | }
|
33 | if((*pid == 0x89) && (mPayload[iv->id].maxPackId < 2)) { //3 |
34 | mPayload[iv->id].maxPackId = 2; |
35 | // if(*pid == 0x89)
|
36 | mLastPacketId = *pid; |
37 | }
|
38 | if((*pid == 0x91) && (mPayload[iv->id].maxPackId < 3)) { //2 |
39 | mPayload[iv->id].maxPackId = 3; |
40 | // if(*pid == 0x91)
|
41 | mLastPacketId = *pid; |
42 | }
|
43 | if((*pid == 0x92) && (mPayload[iv->id].maxPackId < 4)) { //4 |
44 | mPayload[iv->id].maxPackId = 4; |
45 | mLastPacketId = *pid; |
46 | }
|
47 | }
|
48 | } //iv |
49 | } //0 = len |
50 | [c/] |
51 | |
52 | Die Antworten sind: |
53 | 0x88 - A Event |
54 | 0x89 - A Data |
55 | 0x91 - B DATA |
56 | 0x92 - B Event |
57 | |
58 | Die Längen 9 bzw. 16 sind die gesamte Payload, die ich bekomme. Irgendwo sind für die Gesamtleistung noch ein High- und Low-bit versteckt, ich nehme an, das sind die letzten beiden, die mitgesendet werden. Mit der Bitverschiebung werde ich mich aber erstmal nicht beschäftigen. |
59 | |
60 | Den Invertertype in hmSystem.h habe ich etwas erweitert: |
61 | [c] |
62 | if(p->serial.b[5] == 0x11) { |
63 | switch(p->serial.b[4]) { |
64 | case 0x21: p->type = INV_TYPE_1CH; break; |
65 | case 0x41: p->type = INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("HM 2 Channel")); break; |
66 | case 0x61: p->type = INV_TYPE_4CH; break; |
67 | default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 11") + String(p->serial.b[4], HEX)); break; |
68 | }
|
69 | }
|
70 | else if(p->serial.b[5] == 0x10) { |
71 | switch(p->serial.b[4]) { |
72 | case 0x21: p->type = MI_INV_TYPE_1CH; break; |
73 | case 0x41: p->type = MI_INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("MI 2 Channel")); break; |
74 | case 0x61: p->type = MI_INV_TYPE_4CH; break; |
75 | default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 10") + String(p->serial.b[4], HEX)); break; |
76 | }
|
77 | }
|
78 | else
|
79 | DPRINTLN(DBG_ERROR, F("inverter type can't be detected!")); |
Die Debug-Info taucht nur nirgends auf der Konsole auf, in debug.h ist debug als Level eingestellt. Ich weiß also nicht, ob der Part wirklich greift. Am meissten Kopfschmerzen macht mir aktuell die unvollständige Payload und das nicht richtige dekodieren der Werte. Ich habe zwischenzeitlich mit den maxPackId und mit den *pid verschiedene Varianten ausprobiert, keine führte zum Erfolg. Was habe ich übersehen? edit: Payload zusammenhängende Werte im Log gefunden
:
Bearbeitet durch User
Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul. Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit Trigger auf Spg.Abfall. —-> die 3.3V sind stabil
Hallo Daniel M., erstmal Respekt! Schön das wir alle zusammen irgendwie voran kommen. :) Bevor ich es vergesse, wäre es sinnvoll je nach Hersteller eine eigene Klasse zu erstellen. Oder? - TSUN - Hoymiles (MI,HM,...) Für Arduino/ESP könnte es später etwas knapp werden mit dem Speicher, oder was meint Ihr dazu? Ich schau mir mal dein Code an, da ich selbst kein TSUN habe kann ich nichts nachprüfen. Aber vielleicht kommt jemand später dazu. =) @grindylow: Ich bin mir nicht 100% sicher, aber wäre es möglich im Github unter Project ein Backlog anzulegen damit man weiß was noch alles zu machen ist? - So kann man das ganze bisschen sauber führen. 8-) z.B.: https://github.com/users/DanielR92/projects/2/views/1 Gruß Daniel
:
Bearbeitet durch User
Daniel R. schrieb: > erstmal Respekt! Schön das wir alle zusammen irgendwie voran kommen. :) > Bevor ich es vergesse, wäre es sinnvoll je nach Hersteller eine eigene > Classe zu erstellen. Oder? > > - TSUN > - Hoymiles (MI,HM,...) Ja, zieht sich mit den Außenseitern und Altmodellen halt wie Kaugummi, aber solang es Spaß macht :) Das mit den eigenen Klassen erstellem ist auf jeden Fall nötig. Wenn ich was lauffähiges habe, kann man das theoretisch vereinzeln, bis dahin ist es für mich einfacher. Ich bin kein Softwareentwickler und weiß nicht, was ich tue, also versuchen zu verstehen, modifizieren und schauen, was passiert (der Compiler hasst mich mittlerweile). > > Für Arduino/ESP könnte es später etwas knapp werden mit dem Speicher, > oder was meint Ihr dazu? Jep, das wird definitiv eng. > > Ich schau mir mal dein Code an, da ich selbst kein TSUN habe kann ich > nichts nachprüfen. Aber vielleicht kommt jemand später dazu. =) TSUN/MI sind Baugleich in der Kommunikation. Falls du (oder wer anderes) willst, kannst du auch per Anydesk direkt bei mir schauen. Macht das Debuging wahrscheinlich einfacher. Ein Kollege hat sich jetzt einen HM1500 bestellt, an dem werd ich Ahoy ausprobieren :)
Hi Daniel M., habe selbst ein HM-1500. Es läuft schon ziemlich stabil bei mir. Arbeite hier direkt mit einem Raspberry statt ESP. Ich kann schnell denn Code ändern ohne immer alles neu zu kompilieren und zu warten bis es auf dem ESP läuft. :) Ich hatte schon früher die Idee mit discord, habe es aber nicht angesprochen. Da jeder auch seine "Freizeit" hat und man eher selten wahrscheinlich zusammen kommt um gemeinsam dran zu arbeiten.
Angehängte Dateien:
-
20220623_193317.jpg
220 KB -
20220623_193431.jpg
230 KB -
20220623_194030.jpg
200 KB -
20220623_201332.jpg
180 KB -
20220623_203039.jpg
230 KB -
20220623_203049.jpg
220 KB -
20220623_203118.jpg
210 KB
So, hab mal den Abend damit verbracht mein Layout als Einzelstück zu fertigen. Dabei hab ich dann auch den Tipp mit dem Abschirmen des RF Moduls umgesetzt. Mit einem Schrumpfschlauch und etwas Alu Klebeband ging das ganz gut. Morgen werde das Ganze in das Gehäuse einbauen und die Version gegen meinen Breadboard Aufbau tauschen. Mal sehen wie sich das dann mit den Reboots verändert. Hier mal ein paar Impressionen:
Esp_loeter schrieb: > Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul. > Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit > Trigger auf Spg.Abfall. —-> die 3.3V sind stabil das klingt ja gut, auch mit max. Sendeleistung ? wieviel mV hattest du den Trigger ?
Richard K. schrieb: > Esp_loeter schrieb: > >> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul. >> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit >> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil > > das klingt ja gut, auch mit max. Sendeleistung ? > wieviel mV hattest du den Trigger ? Trigger stand auf 3.2V, Sendeleistung auf Max.
MI-1500 Limitierung: Limitierung mit absolut Wattzahl funktioniert auch, hier z.B. 500W Limit: Send... CH61 51|63707160|72228412|5A5A|64|1388|6A Command|WR|DTU|SubCommand|100%|500W|CRC 510.9W PV:2 123.2W 42.9V 2.9A 304.0Wh 227.3V 50.0Hz 52.5C Sts:3 FCnt:0 510.9W PV:3 253.4W 39.2V 6.7A 474.0Wh 226.7V 50.0Hz 52.4C Sts:3 FCnt:0 510.9W PV:4 0.5W 39.2V 0.0A 2.0Wh 226.7V 50.0Hz 52.4C Sts:3 FCnt:0 511.0W PV:1 133.9W 42.9V 3.2A 304.0Wh 226.2V 50.0Hz 52.5C Sts:3 FCnt:0
:
Bearbeitet durch User
Hi Ziyat T., das ist sehr cool. :D Natührlich super für die MI-Nutzer da hier die Dokumente vorhanden sind. Ich nutze ein HM, da hat es leider nicht funktioniert. Wobei, ich glaube ich kenne nun mein Fehler! Die Watt anzahl muss noch mit 10 multipliziert werden. Korrekt? Zusätzlich frage ich mich, die Prozent Angabe die sagt eigentlich was aus? Ich dachte hier trägt man von zb. 1500W nur 10% ein um dann 150W zu erhalten. Bei dir steht es weitherhin auf 100%, jedoch im nächste Byte 500W. Ich bin da etwas verwirrt.^^ Das heißt ich müsste folgendes senden: value = 10(%) * 10 => 100 = 0x00 0x64 value = 50(%) * 10 => 500 = 0x01 0xF4 value = 75(%) * 10 => 750 = 0x02 0xEE ... Transmit 14 | [51] [74 40 33 29] [78 56 34 12] [5a 5a] [xy%] [val|val] CRC Kann das jemand von HM-Nutzer bestätigen (bin aktuell nicht Zuhause)? Danke für die Infos vorab! :)
:
Bearbeitet durch User
Esp_loeter schrieb: > Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul. > Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit > Trigger auf Spg.Abfall. —-> die 3.3V sind stabil Gut, dass das einmal gemessen wurde. Leider gibt es nicht den Wemos D1 mini. Siehe z. B. : https://github.com/bbqkees/Wemos-the-Clone-Wars/blob/master/README.md Zum Thema "reboot": Es gibt Hinweise, dass bei manchen Clones der verbaute Spannungsregler der Grund für häufiges Rebooten ist. (Quelle: https://www.letscontrolit.com/forum/viewtopic.php?t=6603) Das könnte das unterschiedliche Verhalten in Bezug auf Rebooten bei den verschiedenen Usern sein. @Holger S. Sehr kompaktes Layout. Einige Anmerkungen: - Den 3.3V-Spannungsregler weiter vom AC-Eingang weg platzieren, der Abstand zwischen AC-Eingang und der übrigen Schaltung erscheint mir sehr klein zu sein. Besonders dann, wenn eine externe Antenne geplant ist. - Datenblatt HiLink_3W_Power_Supply Seiten 7-8, Kap. 8 "Typical Application Circuit". Dort ist ausgeführt: "Fuses and varistors are the basic protection circuits (required)" sowie "For certification, safety capacitors and common mode inductors cannot be omitted". (Danke an den Google-Übersetzter)
Hallo Daniel R. Variante mit %: [51] [74 40 33 29] [78 56 34 12] [5a 5a] [xy%] CRC Variante mit abs(Watt*10, 1 dec): [51] [74 40 33 29] [78 56 34 12] [5a 5a] [100%] [val=P-lo|val=P-hi] CRC Ich glaube hier wird 100% ignoriert. hier 1388=500,0W Send... CH61 51|63707160|72228412|5A5A|64|1388|6A Das mit der Prozentzahl ist sehr mühsam. Ich steuere meine DTU-Pro über Modbus(zero export), dort geht es nur mit Prozent. Mann muss die angeschlossene PVs Total P als 100% betrachten. Ich habe den MI-1500 aber nur 3PVs mit je 450W brutto, total bekomme ich (gemessen mit Verlust) etwa 1100W unter "meine" Sonne am Sommer/Mittag. Produktion ist nicht linear, darum habe ich eine Tabelle: 100% 1100 90% 1050 80% 996 70% 900 60% 820 50% 750 45% 700 40% 610 30% 460 25% 380 20% 310 17% 261 15% 230 13% 200 12% 182 11% 170
@Günter H. @Holger S. @Esp_loeter Ich habe auch mal mit Wemos1 und NRF24L01 + PA + LNA/Antenne probiert. Bei 3 versch. nrf24 Modulen, konnte ich nur mit einem senden und empfangen, die anderen 2 nur empfangen? Ich dachte zuerst an Spannungsproblem. Allerdings, die 2 Module hatte ich lange mit RF24_PA_MAX betrieben, danach ging auch das ESP kaputt..
Ziyat T. schrieb: > Mann muss die angeschlossene PVs Total P als 100% betrachten. Vielen Dank für die Infos. Ok das ist auch sehr Interessant. Ich würde sagen, jetzt kann es langsam dran gehen den ganzen Code sauber zu machen und die ersten Klassen zu generieren? :) Um für die User mit ESP/Arduino speicher zu sparen, wäre die Frage ob man alle Kombination (HM/MI/TSUN/...) unter einem Hut bringen kann. Oder ob es sogar Notwendig ist diese zu splitten? Ich hoffe man bekommt alles unter. Wobei ich denke hier muss man das ganze anders heran gehen. Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es sich handelt (Marke, Typ?)
Daniel R. schrieb: > Ich würde sagen, jetzt kann es langsam dran gehen den ganzen Code sauber > zu machen und die ersten Klassen zu generieren? :) Da bin ich gespannt;-) HM und MI haben völlig andere Tx/Rx-Message Struktur und Polling, so wie ich beurteilen kann, bisherige SW sind alle auf HM zugeschnitten. Habe mal versuch den MI in die HM-SW zu integrieren, geht nicht so einfach, ich konnte nicht, habe aufgegeben, und das ist echt schade.
Ich meine das sollten wir hinbekommen. Wäre es möglich das du deine Änderung als MI-Version irgendwie hier bereitstellen könntest? Ich bin nähmlich dabei erstmal ein UML aufzustellen. Finde ich erstmal einfacher, damit jeder weiß wie es später aussehen könnte. :) Was meint ihr dazu?
Daniel R. schrieb: > Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es > sich handelt (Marke, Typ?) Hier https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx wurden vor zwei Monaten Typen und Seriennummern zusammengestellt.
Angehängte Dateien:
-
UML_first_draft.png
9,5 KB
Danke. Ich hab zwecks UML angefangen, aber konnte kein gutes Tool/Designer findet indem man das ganze schön Darstellen kann. Hab mal ganz grob denn Anfang gemacht. Ich schau mir gerade von Gitee noch deren Klassen durch wie Sie das gelöst haben.
Daniel R. schrieb: > Ich meine das sollten wir hinbekommen. > Wäre es möglich das du deine Änderung als MI-Version irgendwie hier > bereitstellen könntest? Deise SW ist orig. vom Hubi, ich habe für den MI-1500 abgaendert und als Arbeits-/Debug-SW zu verstehen. Nur für ArduinoUno.
Hallo zusammen, ich habe auch begonnen Firmware für den ESP32 zu schreiben. Es ist in der aktuellen Form schon komplett funktionsfähig und läuft stabil (NodeMCU32 + NRF24 mit zusätzlichem 10uF Kondensator). Vielleicht kann man da auch Anregungen für eine Klassenstruktur finden. Ich habe versucht die Hoymiles Implementierung eigenständig als Library zu gestalten. Die Web GUI ist in Vue.js geschrieben und wird zur Firmware Binary hinzugelinkt. Bei dieser aufwändigeren Projektstruktur und auch zwecks Dependency Verwaltung eignet sich die Arduino IDE hiefür natürlich nicht mehr. Das Projekt basiert auf PlatformIO. Es gibt noch etliche Stellen die nicht perfekt sind, einer Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte erstmal was lauffähiges haben. Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU Im docs Ordner gibt es auch ein paar Screenshots der WebGUI. In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking Changes" geben was die Namen der MqTT Topics anbelangt. Die Payload Erzeugung habe ich auch schon in die Inverter Klassen verlegt. Dies ist jedoch mangels Test noch nicht commited. Über Anregungen und/oder PRs würde ich mich freuen. Grüße Thomas
Günter H. schrieb: > Daniel R. schrieb: >> Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es >> sich handelt (Marke, Typ?) > > Hier > > https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx > > wurden vor zwei Monaten Typen und Seriennummern zusammengestellt. Wenn man mal quer ließt: HM beginnt mit 11 MI beginnt mit 10 250 Watt -> xx20 300 bis 400 Watt -> xx21 500 Watt -> xx40 600 bis 800 Watt -> xx41 1000 Watt -> xx60 1200 bis 1500 Watt -> xx61
Hallo Thomas, stark, dass du das angehst. Sobald du jemanden zum Testen benötigst kann ich helfen. Ich habe einen HM300 und zwei HM600 im Einsatz. Die Ahoy 0.4.19 funktioniert bei mir 100% stabil ohne Kondensator. Grüße, Stefan
Hallo Thomas, habe dein ESP32 Projekt ausprobiert. Soweit hat alles funktioniert, vielen Dank. Dann brauche ich keinen ESP8266 bestellen sondern kann einen der vielen ESP32 nehmen. Leider habe ich grad keinen WR hier, daher kann ich nicht vollständig testen.
Hallo Thomas, ja das sieht schonmal stark aus. =) Ich bin aktuell nicht Zuhause. Habe zum testen ein HM-1500. Würde es mir anschauen, aufjedenfall wäre es Klasse wenn man alle Hoymiles + TSUN in einem Paket bekommt und somit eine breite Maße abdecken kann. Ich weiß nicht wie groß der Flash ist, aber meine das der ESP32 größer ist. Daher sollte das passen oder? Jetzt kommt aber die Master frage: zwei Githubs zu pflegen macht kein Sinn, beide sind soweit ich es sehe (Ahoy habe ich selbst schon getestet) soweit ganz gut. Nur welche sollte man für die Zukunft pflegen? Ahoy ist soweit ich weiß sehr aktiv und hat aktuell ein großen Andrang. Was meint ihr? Gruß
Nur ein Projekt würde schon besser sein, aus meiner Sicht. Ich würde mich über die Implementierung der Leistungsbegrenzung mittels MQTT freuen. Wenn der ESP32 besser geeigne ist, dann werde ich mir einen kaufen. Die GUIs von Thomas sehen schon gut und konsistent aus. Allerdings benötigt der ESP32 3 mal so viel Strom als der ESP8266. Vielleicht könnten sich die Hauptentwickler dazu abstimmen. Stefan
Hallo Stefan, jetzt kann man das noch nicht sagen welches der bessere ist. Ich glaube es wird sich mit der Zeit zeigen. Je nach dem wie wir alle zusammen das Projekt programmieren (auf effizient getrimmt) desto weniger Speicher wird dafür benötigt. Auch hier wäre es eventuell Sinnvoll vielleicht auf einige Libarys die alles aufblähen raus zu schmeisen. Oder? Ich behaupte jetzt erstmal das man am ESP8266 bleiben kann. ;)
Hallo alle zusammen, ich verfolge die aktivitäten hier schon seit einer Woche. Hut ab vor den hier erbrachten Leistungen. ich habe beide Programme (hubi und Ahoi) mit einem ESP8266 am laufen. habe lediglich aus früheren Versuchen einen 10uF Kondensator an dem NRF Modul. Diese hier beschriebenen Abstürze bzw. Reboots des ESP konnte ich bis jetzt noch nicht beobachten. allerdings habe ich in der Vergangenheit schon öfter feststellen müssen, das ein "Handyladegerät" ungeeignet ist um Funkgeschichten mit Strom zu versorgen. Bei mir hängt das meistens zum testen am Laptop oder einer ähnlichen Stromquelle bei der der PE angeschlossen ist, wie weiter oben schon erläutert. ich bin auch brennend an einer Lösung zur Leistungsbegrenzung des HM-600 interresiert. ich habe die ganze Zeit vergeblich versucht, auf der DC Seite den Strom mit einem PWM DC-Wandler zu begrenzen. das funktioniert aber nicht so toll, da der MPPT- Tracker mit dem Steilen abfallen der Spannung nicht zurecht kommt.
Thomas K. schrieb: > Diese hier beschriebenen Abstürze bzw. Reboots des ESP konnte ich bis > jetzt noch nicht beobachten. allerdings habe ich in der Vergangenheit > schon öfter feststellen müssen, das ein "Handyladegerät" ungeeignet ist > um Funkgeschichten mit Strom zu versorgen. > Bei mir hängt das meistens zum testen am Laptop oder einer ähnlichen > Stromquelle bei der der PE angeschlossen ist, wie weiter oben schon So toll Schaltnetzteile auch sind vom Wirkungsgrad, haben sie eben auch durch die Taktung von einigen 10khz bis einigen 100khz leider auch viel Schmutz auf den Leitungen. Oberwellen, Interferenzen usw... alles wird getaktet und das sorgt für Probleme. Ich hatte einen wemos d1 mini versucht mit einem Blitzsensor as3935 zu betreiben und bin kläglich gescheitert, der ESP hatte einfach zu sehr gestört und mit noch so gut gefilterten Spannungsversorgungen und Abschirmungen ging es einfach nicht. Denn die Blitzerkennung läuft mit 500khz Band und Ferritkern Spule als Antenne. Die Abschirmung die skusi hier auf seinen Bildern gezeigt hat finde ich sehr gut, ich werde das auch mal umsetzen um zu sehen ob ich dann auch mit max. Power senden kann, denn das geht bei mir ungeschirmt nicht ohne massenhafte Funkfehler.
Nachtrag: die Abschirmungsmethode die Holger S. (skusi) hier auf seinen Fotos zeigt ist perfekt !!! Ich habe es soeben umgesetzt und kann von min low high bis max mit allen Einstellungen sauber Senden und Empfangen, auch ohne extra Kondensator und Versorgungsspannung.
Daniel R. schrieb: > Danke. > > Ich hab zwecks UML angefangen, aber konnte kein gutes Tool/Designer > findet indem man das ganze schön Darstellen kann. > > Hab mal ganz grob denn Anfang gemacht. Ich schau mir gerade von Gitee > noch deren Klassen durch wie Sie das gelöst haben. Hi, das ganze ist soweit gut, allerdings brauchst du für TSUN nichts extra machen, TSUN ist ein umgelabelter MI. China standart Copy+Paste. Du kannst also MI/TSUN als Klasse machen :)
Moin,
hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird
verschenkt)
Da sollte man seine Energie inwestieren warum das so ist.
Ist ein alter Feraris verbaut dreht der rückwärts (doppelt
gespart).
Hallo Ralf das problem ist, dass bald keiner mehr einen "alten" Zähler hat. Der überschüssige Strom, der tagsüber (für lau) ins Netz gespeist würde, lässt sich aber auch bequem in einem Akku Speichern und dann findet dieser z.B. nachts noch seine Verwendung, um die Grundlast zu decken. Bei mir zum Beispiel ist die Grundlast den ganzen Tag irgendwo zwischen 150 und 230 Watt. Ich habe Aktuell 4 Solarpanels mit mit je 370Watt --> also quasi 1480Wp diese Energie speise ich in einen LiFePo4 Akku mit 4,4kWh Kapazität ein. Parallel dazu, soll ein Wechselrichter davon die ca.200W für die Grundlast einspeisen. Der Rest wird in den Akkus für die Nacht gespeichert. Wenn ich mich nicht verkalkuliert habe, müsste der Akku dann die 16 Stunden überbrücken können in denen die Sonne nicht scheint. Um die Energie nicht zu Verschwenden (bzw. dem Netzbetreiber zu schenken) wollte ich meinen Shelly 3EM auslesen und den Wechselrichter auf NULL EINSPEISUNG einregeln.
Hallo Zusammen, Ich bin neu im Club und habe heute meinen HM-600 erhalten. Er hängt aktuell noch an eine Fritz Steckdose, deshalb weiß ich, dass auch fleißig produziert wird. Ich habe mir auch bereits einen Wemos D1 Mini mit NRF… geholt, verkabelt und die Software aufgespielt. WLAN ist verbunden, MQTT connected und der Inverter ist ebenfalls verbunden. Aber jetzt gehen die Probleme los: 1. Inverter ‚Hm600‘ is availabe and is not producing. -> Tut er aber nachweisbar. 2. MQTT Probleme New connection from das.ist.meine.ip on port 1883 New client connected from das.ist.meine.ip as AHOY-DTU (c1, k15, u‘mqtt‘). Client AHOY-DTU has exceeded timeout, disconnecting 3. Die GUI auf dem Wemos D1 ist extrem langsam. Hat jemand ein paar Tipps für mich? AHOY Version 0.4.19 NRF24L01+ Platine mit externer Antenne MQTT Version 1.5.7 (läuft seit Jahren problemlos auf einem RPI) Viele Grüße Ben
Hallo Thomas, > Der überschüssige Strom, der tagsüber (für lau) ins Netz gespeist würde, > lässt sich aber auch bequem in einem Akku Speichern und dann findet > dieser z.B. nachts noch seine Verwendung, um die Grundlast zu decken. Hier möchte ich mich mal kurz einklinken, weil ich das mittelfristig auch gerne so machen würde. Allerdings fehlt mir ein wenig die Vorstellung, wie das regelungstechnisch ablaufen soll und wie das (um wieder zum hiesigen Thema zurückzukommen) über die Ansteuerung eines Wechselrichters (hier: HM-1500 mit 3 Panels) zu organisieren wäre? Konkret: Wie müsste die Ansteuerung erfolgen, wenn bei überschüssiger Produktion der Akku geladen werden soll? Ich begreife noch nicht, wie der Wechselrichter definiert, wohin der produzierte Strom denn nun gehen soll. Bzw., wie der Akku merken soll, dass er bitteschön gerade laden soll? Wenn das hier am Thema vorbei sein sollte: Gerne auch Erhellung per Linknennung! ;-) Hier läuft seit ca. 2 Monaten eine leicht modifizierte Version eines älteren Ahoy.py auf 'nem Raspi, die auch noch nie Probleme mit dem Strombezug des NRF24+ hatte. Allerdings reicht bei mir die schwächste Sendeleistung aus. Tschüssi, Petra
Ralf B. schrieb: > Moin, > > hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ? > Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird > verschenkt) > Da sollte man seine Energie inwestieren warum das so ist. > Ist ein alter Feraris verbaut dreht der rückwärts (doppelt > gespart). Hallo Weil es nicht überall auf dieser Welt die Rückspeisung so handgehabt wird wie in Deutschland, darum darf/muss ich NULL einspeisen.
Angehängte Dateien:
-
UML.png
9,6 KB
Daniel M. schrieb: > China standart Copy+Paste Stimmt da hast du recht. :)
Petra R. schrieb: > Wenn das hier am Thema vorbei sein sollte: Gerne auch Erhellung per > Linknennung! ;-) > Bitte nicht hier ;-) Aber hier gibts tonnenweise https://www.facebook.com/groups/170429543515117/
@Stefan R. (rossiman) @Daniel R. (daniel92) Bei dem Thema Wemos1/esp8266 ist mir das noch aufgefallen: Wenn jemand den WR steuern möchte, muss man die Leistung (+/-) beim Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.
Ziyat T. schrieb: > Wenn jemand den WR steuern möchte, muss man die Leistung (+/-) beim > Zaehler über Modbus abfragen Naja kommt drauf an wie man das realisieren möchte. Mir würde es reichen wenn man via MQTT das ganze realisieren. Da ich es via Raspberry nutze. Klar der Zähler ist auch via Modbus/S1 Angebunden. Denn würde ich jedoch auch direkt am Pi verbinden. Wir wissen ja nicht wie die gegebenheiten sind. Ich behaupte mal das jeder ein Zähler direkt am UV(Unterverteiler) haben und von dort dann weiter verarbeiten. :) > Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein > RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1. NRF24 läuft doch über SPI und wenn man einen 'MAX3140' Wandler nutzt, kann man auch via SPI kommunizieren. Somit fehlt uns kein Pin mehr. =)
Daniel R. schrieb: > Mir würde es reichen wenn man via MQTT das ganze realisieren. Da ich es > via Raspberry nutze. Klar der Zähler ist auch via Modbus/S1 Angebunden. > Denn würde ich jedoch auch direkt am Pi verbinden. > > Wir wissen ja nicht wie die gegebenheiten sind. Ich behaupte mal das > jeder ein Zähler direkt am UV(Unterverteiler) haben und von dort dann > weiter verarbeiten. :) MQTT ist eine gute Idee. Modbus via einem weiteren Pfennig-Wemos mit RS458-Schnittstelle ist keine Raketenwissenschaft. Ich hab z.B. SDM630 als zentralen Zähler direkt nach dem vom Versorger sowie für alle 3 Etagen einen extra, für Garage, Nebenanlagen und die Wallbox. Insgesamt also 7 Stück, wo ich mit Modbus rankomme. Hier ist es langfristig das Ziel, die Energieflüsse zu messen und Verbräuche zu erfassen. Wäre später interessant, die abzufragenden Register (im Quellcode) konfigurieren zu können oder vllt verschiedene Profile für die gängigen Zähler/Messgeräte zu haben. S1 kann man machen, finde ich aber zu ungenau. Wenn du es sowieso per Raspi hast, ist es kein Problem.
S1 habe ich nur mit reingenommen, da es vielleicht jemand da draußen gibt der ein Zähler schon verbaut hat und nicht noch extra was Invenstieren möchte. :) Die Register vom deinem Zähler sind im Datenblatt zu finden. :) https://bg-etech.de/download/manual/SDM630Register1-5.pdf daher kein Problem die Daten weiter zu vearbeiten.
Daniel R. schrieb: > S1 habe ich nur mit reingenommen, da es vielleicht jemand da draußen > gibt der ein Zähler schon verbaut hat und nicht noch extra was > Invenstieren möchte. :) Verständlich, zumal die Zähler gerade schwierig zu bekommen sind. S1 wäre aber, meiner Meinung nach, nur eine Zwischenlösung. Wer das macht wird früher oder später neugieriger werden. PV macht einfach süchtig. > Die Register vom deinem Zähler sind im Datenblatt zu finden. :) > https://bg-etech.de/download/manual/SDM630Register1-5.pdf > > daher kein Problem die Daten weiter zu vearbeiten. Weiß ich :) Es gibt noch andere Varianten von Janitza, Finder, Eltako, Victron und Co, die alle irgendwie anders belegt sind. Falls noch Platz im Code ist, könnte man hier für die üblichen Verdächtigen schon fertige Belegungen hinterlegen. Meine 7 Stück wollen irgendwie nicht zusammen auf einer Leitung laufen, nach einer gewissen Zeit rebooten die und springen im Zählerstand ein Stück zurück, Eastron zuckt mit den Schultern und weiß nicht warum. Das war der Stand Ende 2019. Genug OT :)
WOW ... total fix eine EMV Prüfung erfolgreich bestanden ... und eine CE und RoHS Erklärung gibts bestimmt auch dazu https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=17732479 https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-wechselrichter/2141424109-168-8859
Ziyat T. schrieb: > Ralf B. schrieb: >> Moin, >> >> hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ? >> Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird >> verschenkt) >> Da sollte man seine Energie inwestieren warum das so ist. >> Ist ein alter Feraris verbaut dreht der rückwärts (doppelt >> gespart). > > Hallo > Weil es nicht überall auf dieser Welt die Rückspeisung so handgehabt > wird wie in Deutschland, darum darf/muss ich NULL einspeisen. Moin, deshalb schrieb ich: >> Da sollte man seine Energie inwestieren warum das so ist. Ich bin absolut der Meinung das dieser Strom zu vergüten ist. Die Nulleinspeisung für nen Akku zu nehmen ist eine schöne aber sehr teure Lösung. 2. WR und nen Lifopo4 mit 2,4 kW sind immo ca 2k€. ob sich das rechnet ? Btw Ich selber habe 10 kWp und 14,5 kw Speicher im Keller. Ist ein schönes Gefühl wenn der Strom von da kommt. Die HM1200 die ich jetzt noch verbauen will sind für die SchattenPV.
RoHS-CE schrieb: > WOW ... total fix eine EMV Prüfung erfolgreich bestanden ... und eine CE > und RoHS Erklärung gibts bestimmt auch dazu > https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=17732479 > https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-wechselrichter/2141424109-168-8859 Leute vergesst den Gedanken mit Ahoy Geld zu verdienen! Die Lizenz erlaubt es nicht, dass Ahoy verkauft wird! Lesen hilft und heulen wenn sich der Anwalt meldet geht gar nicht. Ich finde es schei**e, dass sich hier irgendwelche ganz schlauen meinen es verkaufen zu müssen. Wir stecken echt viel Zeit rein und machen das als Community. Ich sehe das eher so: jeder steuert was bei und gemeinsam schaffen wir großes - für uns -
Hallo Thomas B., habe mir mal Deinen Code angesehen und versucht die Bibliotheken für den Build mit dem ESP8266 auszutauschen. Ich strauchele an dem selben Punkt den wir auch schon umgekehrt festgestellt hatten: * Beim ESP32 kann man ISR Routinen auch mit std::bind Klassen aufrufen/als Callback einbinden. * Beim ESP8266 geht dies nur wenn die ISR Routine global als static void deklariert ist, also noch nicht als Methode einer Klasse. Ansonsten ist der Code sehr übersichtlich und aufgeräumt. Hut ab / Chapeau! Es dürfte dadurch vielleicht sogar etwas einfacher werden dies um die Inverter MI-/TSUN- zu erweitern. Schwierigkeit bei beiden (Ahoy ESP8266 / OpenDTU ESP32) ist m.E. daß das Senden aktuell nur ein Kommando vorsieht. Bei MI-/TSUN- Wechselrichtern muß man aber alle vier Status/Data Pakete einzeln anfragen um die Informationen zu bekommen. Bei HM- Wechselrichtern geht das alles mit der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen. Auch gibt es bei MI-/TSUN- Wechselrichtern keine CRC-Modbus / CRC-16 Prüfsumme innerhalb der Payload, es existiert nur die Paket-eigene CRC-8 Prüfsumme. Der Code dürfte m.E. auch nicht zu viel Speicher verbrauchen, ist ja alles im PROGMEM bzw. Flash memory abgelegt und davon hat selbst der ESP8266(-12E/F) mit 4M m.E. reichlich, zumindest für die 2x3 Wechselrichter Modelle, die wir bisher kennen. Speicher-intensiv wird höchstens, wenn geplant sein sollte Daten zum Tages-/Wochenverlauf mehrerer Wechselrichter direkt im lokalen Flash-Filesystem des ESP abzulegen. Das könnte mit den entsprechenden Schreiboperationen einer RoundRobinDB auch schnell zu Fehlern führen.
Thomas K. schrieb: > Um die Energie nicht zu Verschwenden (bzw. dem Netzbetreiber zu > schenken) wollte ich meinen Shelly 3EM auslesen und den Wechselrichter > auf > NULL EINSPEISUNG einregeln. was ein Unsinn, dann ist sie doch genau so verschwendet? Du erzeugst sie halt nicht mehr, wirfst sie weg statt sie dem Netzbetreiber zu schenken Selber hast Du keinerlei Vorteil davon, gönnst halt dem Netzbetreiber den Vorteil auch nicht Die einzig interessante Anwendung die ich mir für eine Leistungsbegrenzung bei HM-Wechserichtern vorstellen kann: Wenn man damit Akkukapazität ins Netz einspeisst...
Hallo, ich hoffe, es ist langsam mal Schluss hier mit Diskussionen, die nix mit der Protokoll Entschlüsselung zu tun haben. Hier geht es um die Protokoll Entschlüsselung, Tests und da ist noch viel zu tun !
Ziyat T. schrieb: > @Stefan R. (rossiman) > @Daniel R. (daniel92) > Bei dem Thema Wemos1/esp8266 ist mir das noch aufgefallen: > Wenn jemand den WR steuern möchte, muss man die Leistung (+/-) beim > Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein > RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1. Ich würde den WR über einen ESP8266 nur über MQTT steuern und lesen. Für die Leistungserfassung am Hauszähler habe ich schon einen ESP8266 mit Tasmota. Der bekommt die Daten über Infrarot Diode und sendet sie wieder über MQTT. Die Regelung mache ich mit Node Red auf dem Raspi meiner Heimautomatisierung. Für die Hoymiles Schnittstelle wäre für mich deshalb auch eine ESPEasy Plugin total ok. Für mich passt aber natürlich auch das was hier gebaut wird. Ich nutze aber die ESPs nur als Schnittstelle zu Sensoren und Aktoren.
Angehängte Dateien:
Hi Leute, mir ist da ein kleiner Bug im AHOY aufgefallen. Und weil ich Eure Arbeit schon nutze, dachte ich mir: "los, hilf auch mal!" Aber irgendwie bin ich dermaßen QtCreator und VS verwöhnt, dass ich gerne den Code im Single-Step-Debugger durchlaufen wollte. Geht das mit dem 8266? In der Ardu-IDE is ja nix. Geht sowas mit VSCode? Oder läuft der Code auf dem 8266 direkt aus dem Flash? dann ja wohl eher nix mit single-Stepping ...
Hallo Maik R., für single-step debugging direkt auf der Hardware brauchst Du einen JTAG oder Serial Wire Debug (SWD) Port. Mir ist nicht bekannt, daß die Espressif Chips ESP8266 und ESP32 sowas anbieten. Aber eine Suche nach OpenOCD (On Chip Debugger) und ESP8266 fördert sogar ein paar Seiten zu Tage: esp8266-openocd/TODO https://github.com/sysprogs/esp8266-openocd/blob/master/TODO ESP32 JTAG Debugging https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/index.html Man müsste mal einen ST-Linkv2 an die ESP Module / Chips klemmen und das versuchen. Wie man dann den GDB im VSCode mit Platform IO zum laufen bekommt, wäre ein weites Thema. Hier ist ein Beispiel: Debugging ESP8266 code with OpenOCD and Visual Studio https://visualgdb.com/tutorials/esp8266/openocd/ ESP8266 Development Log 00: Environment Setup https://blog.thexyzlab.studio/esp8266-development-log-00-environment-setup/ Hier gibt es auch ein Pinout für den o.a. JTAG Port, aber alles in allem scheint es mit dem ESP32 einfacher und besser unterstützt zu sein. WIFI-JTAG https://github.com/emard/wifi_jtag
isnoAhoy schrieb: > für single-step debugging direkt auf der Hardware brauchst Du einen JTAG > oder Serial Wire Debug (SWD) Port. Mir ist nicht bekannt, daß die > Espressif Chips ESP8266 und ESP32 sowas anbieten. Ich hab hier noch 2 unbenutzte M5Stack Core2 rumfliegen, da tickert ein ESP32 drin rum. Wäre das eine Option zum Testen?
isnoAhoy schrieb: > Bei HM- Wechselrichtern geht das alles mit > der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete > sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen. Moment, nochmal ganz kurz das war mir gerade etwas viel Infos. Ich habe letztens versucht da weiter zu kommen... Wie darf ich das mit der Zeit verstehen? Wird hier ein Timestamp mitgeschickt von der aktuellen Uhrzeit oder wie das zu verstehen? Wenn jemand da mehr Infos für mich hat, gern her damit. :) Vielleicht findet man dadurch eine Kombination aus dem alten MI und den neuen HM, wo man statt '100%' nur die Zeit dafür einsetzt. Command|WR|DTU|SubCommand|Time|500W|CRC so vielleicht? Gruß
Ich habe mal eine Frage an die HM-1500 Experten hier im Forum. Ich hatte mir einen HM-800 bestellt allerdings irrtümlich einen HM-1500 geliefert bekommen. Bevor ich den wieder zurückschicke und noch länger auf einen HM-800 warten muß, weil der zur Zeit beim Händler nicht lieferbar ist, dachte ich mir, dass ich den HM-1500 auch verwenden könnte. Allerdings liefern die von mir ins Auge gefassten Solarmodule bei Pmax 12,5 A und das ist mehr als die 11,5 A pro Kanal die der HM-1500 maximal verträgt (der HM-800 kann 12,5 A pro Kanal). Der HM-1500 hat doch so wie der HM-800 auch nur 2 MPPT Tracker, also die Spannung an den zwei rechten bzw. den zwei linken Kanälen ist immer gleich geregelt, d.h. mann könnte doch die zwei rechten bzw. die zwei linken Kanäle parallel mittel MC4 Splitter an ein Solarmodul schalten, um ihn dann wie einen HM-800 zu betreiben. Ist zwar overkill, aber das sollte doch funktionieren und der Microinverter wird nicht so warm und ich könnte sogar Module mit Imax >12,5 A verwenden? Vielen Dank für die Hilfe. Grüße, Stefan
ST2 schrieb: ... > könnte. Allerdings liefern die von mir ins Auge gefassten Solarmodule > bei Pmax 12,5 A und das ist mehr als die 11,5 A pro Kanal die der > HM-1500 maximal verträgt (der HM-800 kann 12,5 A pro Kanal). Der HM-1500 ... Hallo Stefan, warum wird hier ein Thread geentert mit Fragen, die mit der Überschrift nix zu tun hat ? Mach dafür ein extra Thread auf. Gleiche Fragestellung war vor einigen Tagen schon in einer anderen Gruppe.
@Positron Sorry, ich dachte, dass meine Frage viel mit der Threadüberschrift zu tun hat, es geht schließlich um "Hoymiles HM-XXXX Wechselrichter", die sowohl den HM-800 als auch den HM-1500 umfassen, beide lassen sich über Nordic Protokoll auslesen und die hierbei gesammelten Erkenntnisse lassen Rückschlüsse über die Anzahl der MPPT Tracker und die interne Verschalung der 4 DC Channles beim HM-1500 zu. Ich konnte leider keinen anderen Thread mit der gleichen Fragestellung finden.
ST2 schrieb: > @Positron Sorry, ich dachte, dass meine Frage viel mit der > Threadüberschrift zu tun hat, es geht schließlich um "Hoymiles HM-XXXX > Wechselrichter", die sowohl den HM-800 als auch den HM-1500 umfassen, > beide lassen sich über Nordic Protokoll auslesen und die hierbei > gesammelten Erkenntnisse lassen Rückschlüsse über die Anzahl der MPPT > Tracker und die interne Verschalung der 4 DC Channles beim HM-1500 zu. > Ich konnte leider keinen anderen Thread mit der gleichen Fragestellung > finden. Hallo ST2, elektrisch ist das sicher kein Problem. Du kannst mit dem Auslesen des WR auch überwachen, was er tut. Hier wäre es in deinem Fall wichtig, dass du beobachtest, was der WR tut. Sobald du die Splitter im Einsatz hast, sollte sich der Strom auf beide Eingänge aufteilen. Bereite dir bitte ein Monitoring auf der Basis der Software vor und beobachte damit deinen WR. Klar ist es nicht schön, andere Threads zu entern, allerdings ist es in dem Fall durchaus möglich, abseits der eigentlichen Fragestellung eine Lösung für ein Problem zu finden. Sobald du dein System aufgesetzt hast, wäre es schön, Informationen über die Performance zu bekommen. Berichte bitte über die AC-Leistung und die beiden integrierten Tracker, wie die laufen. Gerne auch mit MQTT logging. Deine Frage ist mir in anderen Kreisen schon oft begegnet. Nachtrag: Ich finde es wichtig, sich nicht nur auf das Protokoll zu versteifen sondern auch zu verstehen, was am Ende rauskommt. Daten sind das eine, aber wenn man diese nicht richtig interpretieren kann, ist es halt unschön. Solche Spezialfälle gibt es immer wieder und genau hier ist das Protokoll und die Software eine Hilfe, die zum Erfolg führen kann. In Bezug auf z.B. einen Akku am WR anstelle von Modulen, eine Leistungsbegrenzung und die damit verbundenen weiteren Möglichkeiten, die sowohl der WR als auch Software bringen können, finde ich genau diese Art Messdaten durchaus interessant für die zukünftige Entwicklung. Da steckt Potential drin :)
:
Bearbeitet durch User
Daniel R. schrieb: > isnoAhoy schrieb: >> Bei HM- Wechselrichtern geht das alles mit >> der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete >> sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen. > > Moment, nochmal ganz kurz das war mir gerade etwas viel Infos. > Ich habe letztens versucht da weiter zu kommen... > > Wie darf ich das mit der Zeit verstehen? Wird hier ein Timestamp > mitgeschickt von der aktuellen Uhrzeit oder wie das zu verstehen? Wenn > jemand da mehr Infos für mich hat, gern her damit. :) Hier https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt findest du alles für den HM. Speziell Zeile 399. 15:72220200:72220200:80:0B:00:6209049b:00 00 00 00 00 00 00 00 F2 68 F0
Lukas P. schrieb: > Leute vergesst den Gedanken mit Ahoy Geld zu verdienen! Die Lizenz > erlaubt es nicht, dass Ahoy verkauft wird! > Lesen hilft und heulen wenn sich der Anwalt meldet geht gar nicht. Also ich sehe hier: https://github.com/grindylow/ahoy/blob/main/LICENSE GNU General Public License v3.0 Damit ist es sehr wohl erlaubt Geld zu machen. Bei Github gibt es sogar kleine rote und grüne Häkchen die auf dem ersten Blick erklären wie die zitierte Lizenz zu nutzen ist. Das nächste mal muss man halt ein proprietäres Lizenz wählen, dann darf auch die Anwalt Keule kommen.
Das stimmt, das Repository ist per GNU 3.0 lizenziert. Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3 Finde es gut wenn wir dieses Thema klar verständlich für alle umsetzen können. Verbesserungen sind willkommen, Ziel soll sein: - jeder darf die FW bauen / verändern - jeder darf beitragen - es darf kein Geld mit dem Wissen Software PCB Layout / Gehäuse verdient werden Ich kenne auch ein anderes Projekt, das ein ähnliches Problem hat und es mit dieser Zeile in jedem File kenntlich gemacht hat (auch nach dem pull des Codes): https://github.com/pa-pa/AskSinPP Der ESP präsentiert die Lizenz übrigens auch direkt auf der Index.html
Lukas P. schrieb: > Das stimmt, das Repository ist per GNU 3.0 lizenziert. > > Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt: > https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3 > Es waere ev. besser direkt in hier: https://github.com/grindylow/ahoy/blob/main/LICENSE auf diese: Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/ zu verweisen
Lukas P. schrieb: > Das stimmt, das Repository ist per GNU 3.0 lizenziert. > > Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt: > https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3 > > Finde es gut wenn wir dieses Thema klar verständlich für alle umsetzen > können. Verbesserungen sind willkommen, Ziel soll sein: > > - jeder darf die FW bauen / verändern > - jeder darf beitragen > - es darf kein Geld mit dem Wissen Software PCB Layout / Gehäuse > verdient werden > > Ich kenne auch ein anderes Projekt, das ein ähnliches Problem hat und es > mit dieser Zeile in jedem File kenntlich gemacht hat (auch nach dem pull > des Codes): https://github.com/pa-pa/AskSinPP > > Der ESP präsentiert die Lizenz übrigens auch direkt auf der Index.html Tatsächlich. Ja dann habe ich mich geirrt. Ich fände es auch gut wenn die Lizenz prominenter zu sehen wäre. Dieses Projekt ist jetzt "heiß" genug dafür. Beste Grüße
Also ich persönlich bin für die GNU GPL v2/3 wie bereits ursprünglich im Projekt von Grindylow Martin Petersilie vorgesehen. Eine LICENSE Datei wäre natürlich schön. Da ich aber bisher kaum Code beigetragen habe unterwerfe ich meine Zusätze der Doku auch gerne einer anderen Lizenz. Wenn also einige der Haupt-Contributoren (Lukas P., Thomas B. -> ESP8266/32, bzw. Jan-Jonas S. Python) hier eine ggf restriktivere Lizenz CC-SA-NC also non-commercial wünschen um zB Copy-Cat und unnötige Support-Anfragen zu verhindern dann ist das 1. verständlich und 2. auch gerechtfertigt da sie den größten Anteil am Code haben. Andererseits werden die Support-Anfragen dadurch nicht weniger oder qualitativ besser und den Fragestellern sieht man es am Issue / Kommentar nicht direkt an ob sie das Ding gekauft oder selbst zusammengebastelt haben. Vielleicht hilft es auch wenn wir hier einen „Selbstkostenpreis“ als Richtschnur oder Bill Of Materials im Readme.md definieren um unerwünscht hohe Preise von 50 Euro auf Kleinanzeigen als ebensolche herauszustellen ? * Wemos D1 plus 4,65 EUR * nRF24L01+ Modul 3,65 EUR bzw. Optional statt der Komponenten oben * NodeMCU v3.4 6,85 EUR * nRF24L01+ PA Modul 5,75 EUR plus * Wemos Proto Board 3,74 EUR oder * Platine ca. 2,00 EUR laut Oliver R. * 100uF Elko Kondensator 25V 0,35-1,79 EUR * Gehäuse 3D Druck einige Euros zugl Versand ZB hier mit geringen Versandkosten und klarem Preis. Wieviel Gramm wiegt denn ein Gehäuse und wie lange dauert der Druck ? Ich habe immer noch kein Cura auf dem Handy =^P https://www.ebay.de/itm/3D-Druck-Service-Drucken-von-Prototypen-Figuren-uvm-Schnell-und-Preiswert-/265496132225 * Arbeitszeit, Fädeldraht und Lötzinn (unbezahlbar heutzutage =^) Macht in Summe also schon mal ca. 15-20 Euro je nachdem welche Komponenten und wie viel Versandkosten dazu kommen. Auch der Paketboote will ja was verdienen. @Lukas P. wieviel wäre demnach für einen komplett zusammengebauten Satz für Dich erträglich / verständlich ? Abseits der Frage nach der korrekten Lizensierung wäre das ja die Frage die wir für uns erstmal beantworten müssten, bevor wir ein Angebot als moralisch „unanständig“ oder korrekt („Selbstkostenpreis“) klassifizieren. Für mich wäre zwar bei ca. 30 Euro eine Grenze erreicht (-> Gschmäckle). Aber wenn jemand Fremdes mehr dafür bezahlen will oder ein Bekannter mir mehr dafür gibt weil ich ja „auch soo viel Arbeitszeit reingesteckt“ habe, müsste ich auch nach guten Argumenten suchen dieses nicht anzunehmen. Ich weiss aber nicht ob wir die von Einigen hier produzierten Überschüsse (bei 5-10 Modulen sind halt die anteiligen Versandkosten geringer und man hat auch immer ein paar Ersatzteile im Materialkontinuum für andere Projekte) Einzelner hier auf der Liste wirklich mit dem Anwalt sanktionieren müssen. Ich will jedenfalls nicht die Hardware für andere zusammenlöten und verkaufen aber wenn ich die anderen vier PA Module wiederfinde hänge ich bestimmt noch eines an den Raspberry Pi oder versuche mal den Hoymiles HM-600 mit der P8/Pinetime Smartwatch abzufragen.
Hallo Stefan, ja genau wir sind noch zu stark in den Kinderschuhen als dass man hier zu stark unbedarfte damit versorgen sollte (Support). Daher würde ich auch einen nachvollziehbaren Preis von 10-15€ akzeptieren / verstehen. Was ich halt unterstreichen will: ich bin nicht einer der 'Dummen' um anderen ein verkaufsfähiges Produkt auf den Tisch zu zaubern und selbst leer auszugehen. Warum kann es nicht einfach offen sein und wer ein bisschen Lust auf basteln hat kann sich für lau eine DTU ohne Cloud selbst stricken - und sogar noch eigene Anpassungen vornehmen. Besonders gefährdet als Produkt verkauft zu werden sind glaube ich nur die ESPs. Wir wollen ja auch nicht hoymiles eine Konkurrenz machen, sondern eine Cloud freie Version, ursprünglich ging es ja nur um die Entschlüsselung des Protokolls ^^
Günter H. schrieb: > @Holger S. > Sehr kompaktes Layout. > Einige Anmerkungen: > - Den 3.3V-Spannungsregler weiter vom AC-Eingang weg platzieren, der > Abstand zwischen AC-Eingang und der übrigen Schaltung erscheint mir sehr > klein zu sein. Besonders dann, wenn eine externe Antenne geplant ist. > - Datenblatt HiLink_3W_Power_Supply Seiten 7-8, Kap. 8 "Typical > Application Circuit". Dort ist ausgeführt: "Fuses and varistors are the > basic protection circuits (required)" sowie "For certification, safety > capacitors and common mode inductors cannot be omitted". (Danke an den > Google-Übersetzter) Wenn ich hier so lese, das die 3,3V vom Wemos ausreichend stabil sind, und man den Elko auch nicht unbedingt benötigt. Bin ich geneigt den Spannungsregler und die Kondensatoren rauszuschmeißen um dann Platz für eine Sicherung zu schaffen. Ich möchte ungerne auf ein größeres Gehäuse aufrüsten müssen. Ich experimentiere derzeit mit verschienden0en Lösungen. Dabei hat sich übrigens schon ergeben das meine Idee mit der Schrumpfschlauch / Alu Klebeband Abschirmumg des RF24 den Empfang sehr verschlechtert. Ich habe die Schirmung wieder entfernt, und nun werden meine 6 WR auch ziemlich sauber empfangen. Einzig den Grund für die Abstürze habe ich noch nicht ergründen können. Ich habe nun alle meine 3 Verschiedenen Wemos d1 mini clone ausprobiert, und keiner schafft mehrere Stunden Uptime.
Ziyat T. schrieb: > Deise SW ist orig. vom Hubi, ich habe für den MI-1500 abgaendert und als > Arbeits-/Debug-SW zu verstehen. > Nur für ArduinoUno. Hallo Ziyat, du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands geführt. Hattest du auch mal versucht die Non-Legacy commands zu verwenden? (Also die, die oben auf dem Sheet "Data collection instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein) Ich glaub mit meiner aktuellen ESP32 Lib sollte man das evtl. mit überschaubarem Aufwand umsetzen können (evtl...). Wenn ich da ein paar Background Infos hab muss ich mich aber nicht so durch den Arduino Code mühen.
:
Bearbeitet durch User
Thomas B. schrieb: > du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der > Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands > geführt. Hattest du auch mal versucht die Non-Legacy commands zu > verwenden? (Also die, die oben auf dem Sheet "Data collection > instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein) Hallo Thomas, ich habe heute meine ESP32 bekommen und direkt mit deiner Version losgelegt. Die sendTime-Routine etwas umgefummelt damit Daten gesendet werden:
1 | HM_Abstract.cpp: |
2 | |
3 | payload->mainCmd = 0x09; |
4 | payload->subCmd = 0x00; |
5 | payload->timeout = 2000; |
6 | payload->len = 0; |
mainCmd = 0x09 ergibt Antwort 0x88 (Event/Status Modul 1) und 0x89 (PV Daten) auf der Payload Position 0. Doe 0x11 ergibt die Antworten 0x91 (PV Daten) und 0x92 (Event/Status Modul 2). Ziyat hat einen MI-1500, ich habe einen MI-700 Klon. Die Befehle sind etwas unterschiedlich, die Grundlegenden Antworten sind aber identisch. Ziyat bekommt 8 Antworten, ich 4. Der mainCmd 0x15 hat keine Auswirkungen auf die alten Modelle. > Ich glaub mit meiner aktuellen ESP32 Lib sollte man das evtl. mit > überschaubarem Aufwand umsetzen können (evtl...). Wenn ich da ein paar > Background Infos hab muss ich mich aber nicht so durch den Arduino Code > mühen. Für die Backgroudinfos sind wir sicher zu haben, ich fange mal an. Ich habe für den 2-Kanal MI folgendes in der MI_2CH.cpp, einer Kopie deiner HM_2CH.cpp:
1 | #include "MI_2CH.h" |
2 | |
3 | MI_2CH::MI_2CH(uint64_t serial) |
4 | : HM_Abstract(serial) {}; |
5 | |
6 | bool MI_2CH::isValidSerial(uint64_t serial) |
7 | {
|
8 | return serial >= 0x104100000000 && serial <= 0x104199999999; |
9 | }
|
10 | |
11 | String MI_2CH::typeName() |
12 | {
|
13 | return String(F("MI-600, MI-700, MI-800")); |
14 | }
|
15 | |
16 | const byteAssign_t* MI_2CH::getByteAssignment() |
17 | {
|
18 | return byteAssignment; |
19 | }
|
20 | |
21 | const uint8_t MI_2CH::getAssignmentCount() |
22 | {
|
23 | return sizeof(byteAssignment) / sizeof(byteAssign_t); |
24 | }
|
Die .h habe ich angehängt, diese ist aber noch lange nicht lauffähig, jedoch stimmt die Reihenfolge der Bytes bereits. Zeile 14 hat garantiert die falsche Länge. Die Hoymiles.cpp habe ich ab Zeile 43 folgend erweitert:
1 | std::shared_ptr<InverterAbstract> HoymilesClass::addInverter(const char* name, uint64_t serial) |
2 | {
|
3 | std::shared_ptr<InverterAbstract> i; |
4 | if (HM_4CH::isValidSerial(serial)) { |
5 | i = std::make_shared<HM_4CH>(serial); |
6 | }
|
7 | else if (HM_2CH::isValidSerial(serial)) { |
8 | i = std::make_shared<HM_2CH>(serial); |
9 | }
|
10 | else if (HM_1CH::isValidSerial(serial)) { |
11 | i = std::make_shared<HM_1CH>(serial); |
12 | }
|
13 | /*if (HM_4CH::isValidSerial(serial)) {
|
14 | i = std::make_shared<MI_4CH>(serial);
|
15 | }*/
|
16 | else if (MI_2CH::isValidSerial(serial)) { |
17 | i = std::make_shared<MI_2CH>(serial); |
18 | }
|
19 | /*else if (HM_1CH::isValidSerial(serial)) {
|
20 | i = std::make_shared<MI_1CH>(serial);
|
21 | }*/
|
Leider komme ich mit dem Empfang der Payload nicht weiter. Log:
1 | Fetch inverter: 17872974971670 |
2 | TX 9 60 53 3 16 78 56 34 12 0 27 |
3 | RX Period End |
4 | All missing |
5 | Nothing received, resend whole request |
6 | TX 9 60 53 3 16 78 56 34 12 0 27 |
7 | RX Period End |
8 | All missing |
9 | Nothing received, resend whole request |
Warum unter Fetch inverter das ganze in Dezimal (?) kodiert steht, kann ich noch nicht nachvollziehen. Ansonsten muss ich isnoahoy zustimmen, dein Code ist sehr übersichtlich und aufgeräumt. Sehr gut! :) Wenn du nochmal Beispiele für komplette Empfangspayload brauchst, kann ich gerne noch welche schicken.
1 | 88 63500316 63500316 00 03 00 00 00 00 00 00 8B D8 29 |
2 | 89 63500316 63500316 012D 0001 095D 1389 003D 085D 00FF E550 EF |
3 | 91 63500316 63500316 012D 0001 095D 1389 003D 085D 00FF E550 EF |
4 | 92 63500316 63500316 00 03 00 00 00 00 00 00 91 98 81 |
5 | pid WR-ID WR-ID Payload |
Das Grundgerüst ist, soweit ich gesehen habe, identisch zu meinem, nur die payload-ID's zum Abfragen und Empfangen sind unterschiedlich. Wäre es einfach Möglich, in den inverters/xxx.h und xxx.cpp die commands und payload-ID's hinzuzufügen? Etwa in dieser Form:
1 | const uint8_t MI_2CH::getPayload() |
2 | {
|
3 | mainCmd = 0x09; //Ch0 request |
4 | mainCmd = 0x11; //Ch1 request |
5 | PayloadID = 0x88; //Event Ch0 |
6 | PayloadID = 0x89; //PV-DATA Ch0 |
7 | PayloadID = 0x91; //PV-DATA Ch1 |
8 | PayloadID = 0x92; //Event Ch1 |
9 | }
|
Zum genauen Ablauf von Sende/Empfangsdaten müsste Ziyat was sagen, mainCmd hier sind: Ch0=0x36 Ch1=0x37 Ch2=0x38 Ch3=0x39 Leider gibt es zur Antwort keine Kommentare in der Version von Gitee. Ein Zeit-Kommando gibt es nicht, eine CRC16 auf dem mainCmd gibt es nicht, nur das CRC8. Eine CRC16 auf der Payload gibt es ebenfalls nicht, das letzte Byte auf 0x89 und 0x91 ist Bestandteil der Gesamtproduktion des WR. Wie das aufgebaut ist, hab ich noch keine Ahnung. ES gibt Hinweise in der Gitee-Version, lass da später mal schauen. Das einfachste dürfte sein, eine Bedingung: wenn HM-Inverter, dann CRC16, wenn MI, dann einfach die Payload mit (ID) nutzen. Btw. ich habe 2 Kollegen mit Balkonkraftwerken angesteckt, ich habe heute 4 Module, der nächste 3 und der 3. 1 Modul abgeholt. Jeder wird einen HM-1500 verwenden. Der MI-Klon wird natürlich weiterarbeiten und für Tests herhalten. Danke für deine gute Vorlage, Thomas, ist das erste mal für mich, dass ich freudig durch VScode gewuselt bin :) lg Daniel M.
Daniel M. schrieb: >
1 | > HM_Abstract.cpp: |
2 | >
|
3 | > payload->mainCmd = 0x09; |
4 | > payload->subCmd = 0x00; |
5 | > payload->timeout = 2000; |
6 | > payload->len = 0; |
7 | >
|
Mein Plan war hier eine MI_Abstract.cpp Datei zu haben. Diese wird dann alle MI-Spezifischen Methoden enthalten. > Der mainCmd 0x15 hat keine Auswirkungen auf die alten Modelle. Ok, damit muss man wirklich das Legacy Protokoll Implementieren. >
1 | > #include "MI_2CH.h" |
2 | >
|
3 | > MI_2CH::MI_2CH(uint64_t serial) |
4 | > : HM_Abstract(serial) {}; |
5 | >
|
6 | > bool MI_2CH::isValidSerial(uint64_t serial) |
7 | > { |
8 | > return serial >= 0x104100000000 && serial <= 0x104199999999; |
9 | > } |
10 | >
|
11 | >
|
Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)? > Leider komme ich mit dem Empfang der Payload nicht weiter. > Log: >
1 | > Fetch inverter: 17872974971670 |
2 | > TX 9 60 53 3 16 78 56 34 12 0 27 |
3 | > RX Period End |
4 | > All missing |
5 | > Nothing received, resend whole request |
6 | > TX 9 60 53 3 16 78 56 34 12 0 27 |
7 | > RX Period End |
8 | > All missing |
9 | > Nothing received, resend whole request |
10 | >
|
Du wirst hier aktuell auch noch nichts empfangen können. Die Empfangsroutine erwartet aktuell Fragmente die jeweils eine CRC usw. enthalten. Das muss ich an der Stelle noch umtippen (ggf. 2. Empfangsmodus für Pakete die nicht als Fragmente übertragen werden). Aber selbst wenn das nicht implementiert ist sollte zumindest ein "Frame kaputt" kommen da die Fragment CRC nicht geprüft werden kann: https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/HoymilesRadio.cpp#L74 Ich habe aber noch im Hinterkopf das die DTU's für die MI's einen anderen Nummernkreis haben. Ggf. erfolgt deshalb keine Antwort. Da muss ich aber nochmal nachlesen bzw. den Code von Ziyat anschauen. > Warum unter Fetch inverter das ganze in Dezimal (?) kodiert steht, kann > ich noch nicht nachvollziehen. Das scheint noch ein Problem bei mir zu sein. Muss in dieser Zeile die Ausgabe als Hex machen: https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/Hoymiles.cpp#L27 > Zum genauen Ablauf von Sende/Empfangsdaten müsste Ziyat was sagen, > mainCmd hier sind: > Ch0=0x36 > Ch1=0x37 > Ch2=0x38 > Ch3=0x39 > > Leider gibt es zur Antwort keine Kommentare in der Version von Gitee. Die Antworten auf die entsprechenden Anfragen sind im Excel (siehe auch hier Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") auf dem 3. Blatt von links in Zeile 106 beschrieben (Anfrage in Zeile 104) > Danke für deine gute Vorlage, Thomas, ist das erste mal für mich, dass > ich freudig durch VScode gewuselt bin :) Freut mich das es mit VSCode klappt. Wenn man erstmal weiß was es tut ist es imho viel schöner als die Arduino IDE.
Thomas B. schrieb: > Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern > gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich > wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)? Ich hab mal einfach im Internet zusammen gesucht, kein Gewähr auf richtigkeit. :) MI-500 104021600117:https://www.youtube.com/watch?v=uqnoU9fCvOg MI-1500 106160914811:https://www.alpha-solar.info/images/product_images/original_images/MI-1500%20Vorderseite%20freigestellt%20klein.png 105154003229:https://images.tcdn.com.br/img/img_prod/606124/kit_hoymiles_mi1500_4_paineis_440w_monocristalino_12351_6_5e3655b2364e9548a6376ae715afcf69.jpg
Thomas B. schrieb: Hallo Thomas, > Mein Plan war hier eine MI_Abstract.cpp Datei zu haben. Diese wird dann > alle MI-Spezifischen Methoden enthalten. das war auch mein Gedanke, irgendwo muss man aber anfangen, daher bot sich diese Funktion an. > Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern > gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich > wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)? Jup, der Nummernkreis ist gleich, startet aber mit 10 statt 11. > Du wirst hier aktuell auch noch nichts empfangen können. Die > Empfangsroutine erwartet aktuell Fragmente die jeweils eine CRC usw. > enthalten. Das muss ich an der Stelle noch umtippen (ggf. 2. > Empfangsmodus für Pakete die nicht als Fragmente übertragen werden). > Aber selbst wenn das nicht implementiert ist sollte zumindest ein "Frame > kaputt" kommen da die Fragment CRC nicht geprüft werden kann: > https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/HoymilesRadio.cpp#L74 Das ist eine gute Frage. Nachdem ich die CRC16 in der ahoy-version ausgeblendet habe und nicht verwende, bekomme ich zumindest valide Pakete. > Ich habe aber noch im Hinterkopf das die DTU's für die MI's einen > anderen Nummernkreis haben. Ggf. erfolgt deshalb keine Antwort. Da muss > ich aber nochmal nachlesen bzw. den Code von Ziyat anschauen. Die Nummer der DTU scheint dem WR relativ egal, ich bekomme mit der modifizierten Version von Hubi mit den den DTU-ID's antworten. > Das scheint noch ein Problem bei mir zu sein. Muss in dieser Zeile die > Ausgabe als Hex machen: > https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/Hoymiles.cpp#L27 Das eilt nicht :) Wenn man es weiß, ist es ok, normal schaut aber keiner weiter darauf. > Die Antworten auf die entsprechenden Anfragen sind im Excel (siehe auch > hier > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") > auf dem 3. Blatt von links in Zeile > 106 beschrieben (Anfrage in Zeile 104) Jup, die Antworten sind so aufgebaut. > Freut mich das es mit VSCode klappt. Wenn man erstmal weiß was es tut > ist es imho viel schöner als die Arduino IDE. VSCode ist schon angenehm im Handling, jemanden allerdings, der nicht so tief in der Entwicklung steckt, erschlägt es einen erstmal. Viel schöner als die Arduino IDE ist es auf jeden Fall. Danke und Respekt für deine Arbeit mit dem ESP32. Natürlich auch Hubi und den anderen mit Raspi und ESP8266. Das ganze ist nicht so einfach und trotzdem irgendwie faszinierend :)
Daniel M. schrieb: Thomas B. schrieb: >> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern >> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich >> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)? Hallo zusammen Die Frage wurde schon im Doku beantwortet: https://github.com/lumapu/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx HM beginnt mit 11 MI beginnt mit 10 250 Watt -> xx20 300 bis 400 Watt -> xx21 500 Watt -> xx40 600 bis 800 Watt -> xx41 1000 Watt -> xx60 1200 bis 1500 Watt -> xx61 Die MI-1500 commands und antworten könnt ihr ja in meinen Beitraegen finden. Hoffe bald auf eine Version mit MI1500;-) Noch eine freche Frage: Könnt ihr bitte die Limitierung (CMD 0x51) auch einbauen, mit der mqtt-Abfrage des Smartzaehler-Wertes?
Thomas B. schrieb: > du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der > Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands > geführt. Hattest du auch mal versucht die Non-Legacy commands zu > verwenden? (Also die, die oben auf dem Sheet "Data collection > instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein) Bei MI-1500 gehen nur CMD=0x36-0x39 Alle Kombinationen für den MI-1500 wurde von mir bereits getestet. Bitte siehe meine Beitraege.
Daniel M. schrieb: Thomas B. schrieb: >>Eine CRC16 auf der Payload gibt es ebenfalls nicht, das letzte Byte auf >>0x89 und 0x91 ist Bestandteil der Gesamtproduktion des WR. Wie das Doch, ohne CRC16 bekommt man auch die falschen Werte, z.B. ein PV 5300Watt, das mach die Rechnung schwieriger;-).
@Thomas B. @Daniel M. Ich habe alle commands für den MI-1500 mit meiner DTU-Pro verifiziert. Ich habe die Kommunikation DTUPro-WR gesnifft und die cmd's und Antworten so herausgefungen, bevor die gite Dokus gefunden wurde. Die habe ich dann so implementiert.
Angehängte Dateien:
-
Zwischenablage01.jpg
82 KB -
Zwischenablage01.jpg
82 KB -
Zwischenablage02.jpg
77 KB
Hallo, hoffentlich kann mir hier jemand helfen. Ich habe die Software auf einem Wemos D1 mini. Dazu dieses Modul: https://www.amazon.de/gp/product/B09MKCZ7WT/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1 Anbei Screenshots meiner Einstellungen. Leider bekomme ich keine Verbindung zum HM-800. Angeschlossen ist es nach: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md Das ganze befindet sich momentan ca. 4m entfernt vom Wechselrichter.
Hallo Matze M.P., Du verwendest noch die v0.4.17 versuche es mal mit 0.4.19 es gab da evtl. einige Verbesserungen (ich hab das Changelog nicht im Kopf). Probiere mal eine andere Belegung für die IRQ und CSN / CE Pins. Siehe dem entsprechenden GitHub issue: https://github.com/grindylow/ahoy/issues/36 Es gabe Hinweise, daß die IRQ Leitung an D3 / GPIO0 teilweise Probleme macht. Andere haben D2 & D1 statt D3 & D4 verwendet und Erfolg gehabt. Bitte also eine Rückmeldung im o.g. Issue falls das bei Dir ebenfalls erfolgreich ist. Als Drittes kannst Du noch das Kleingedruckte auf Deinen Modulen überprüfen ob es auch tatsächlich ein nRF24L01+ Modul ist. Es gibt wohl auch Module ohne das + bei denen es nicht klappen kann. Ich weiß nicht ob die NRF24 Bibliothek beim Booten des ESP über die Serial Console eine Versionsnummer des NRF Chips mit ausgibt ? Eventuell gibt es auch noch ein eigenes Kommando in der NRF24 Bibliothek um die Version zu prüfen ?
Die 0.4.19 (fertiges bin) hier aus dem Thread hab ich gerade als OTA aufgespielt. Leider macht der Wemos jetzt kein WLAN auf um ihn zu konfigurieren. Mist...Jetzt komm ich nicht mehr drauf.
Lukas P. schrieb: > ja genau wir sind noch zu stark in den Kinderschuhen als dass man hier > zu stark unbedarfte damit versorgen sollte (Support). Daher würde ich > auch einen nachvollziehbaren Preis von 10-15€ akzeptieren / verstehen. Ich verstehe zugegeben nicht was manche hier machen - aber vielleicht lese ich auch zu wenig mit? Ich habe hier einen HM-1500 - für den habe ich vor ca. 3 Monaten hier was runter geladen, glaube von AHOY, auf einen ESP8266 geflasht, es läuft und macht genau was ich will Viele sagen wir sind im Forschungsstatus - ihr habt es doch schon geknackt? Das ganze rumgeeire was wie verkauft werden kan / soll - wozu? Ich habe hier einige solcher ESP-Lösungen im Einsatz, YC-600, SML-Reader, Wärmepumpe, alle schicken brav über MQTT Meiner Ansicht nach wird es Zeit das einer ausschert, einfach was fertiges präsentiert Schaut euch gerne mal das hier an: https://github.com/Egyras/HeishaMon Es ist wie es ist, tut was es soll, reicht so Sorry für mein Unverständnis an dieser Stelle und Viele Grüße
Heinz R. schrieb: > Ich habe hier einen HM-1500 - für den habe ich vor ca. 3 Monaten hier > was runter geladen, glaube von AHOY, auf einen ESP8266 geflasht, es > läuft und macht genau was ich will > Viele sagen wir sind im Forschungsstatus - ihr habt es doch schon > geknackt? > Es gibt nicht nur die HM-Serie von hoylmoly! Und von HM's werden bisher "nur" die WR-Daten geholt, der WR wird noch nicht gesteuert. Also wenn du nur Daten von deinem HM möchtest ist es ok. für dich, ich und einige möchten mehr: Unterstützung der alle MI's,TSUN, Zuverlaessigkeit, MQTT, zero export etc. > Das ganze rumgeeire was wie verkauft werden kan / soll - wozu? Alleine ich habe ziemlich viel Zeit investiert für den MI-1500, die anderen hier sicher noch mehr. So dürfen wir doch bisschen "rumgeeiren";-) Gruss
Hallo zusammen, so ich bin aktuell wieder dran HM die Limitierung zu testen. Folgendes habe ich nun gesendet:
1 | 2022-06-29 14:09:39.966934 Transmit 14 | 15 74 40 33 29 78 56 34 12 80 5a 5a 02 b1 |
2 | 2022-06-29 14:09:40.012065 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
3 | 2022-06-29 14:09:40.516145 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
Jedoch steht in der Descr.: https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt (Zeile: 520)
1 | **CMD**: |
2 | Befehl an den WR hat Bit 7 gesetzt |
3 | 0x80 "Zeit setzen" |
4 | 0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01 |
5 | 0x82 "Anfrage AC-Daten", erwartete Antwort: 0x02 |
6 | 0x83 "?" |
7 | 0x85 "?" |
8 | 0xFF "?" |
9 | Antworten vom WR haben Bit 7 gelöscht: |
10 | 0x01 "Aktuelle DC-Daten" |
11 | 0x02 "Aktuelle AC-Daten" |
Habe ich es richtig verstanden, das damals Herausgefunden wurde das man die Zeit zuerst setzen muss und später auf Anfrage die eigentliche Nachricht zu schicken soll?
Angehängte Dateien:
Hallo! Ich besitze einen HM-1500 und habe mich auch mal daran versucht. Leider scheitere ich ebenfalls. Ich habe auch schon D1&D2 anstatt D3&D4 und 2 verschiedene nRF24L01+ Module probiert (zumindest auf einem steht das + dabei). Es handelt sich dabei um die Version 0.4.20. Hat vielleicht jemand eine Idee, was ich falsch mache?
Angehängte Dateien:
-
screen1.jpg
88 KB -
screen2.jpg
54 KB -
screen3.jpg
91 KB
Hallo, ich habe dieses Forum durch Zufall gefunden und bin begeistert was Ihr alles erreicht habt. Da ich noch auf meine Aufständerung für meine 2 Module warte, habe ich eines im Garten aufgestellt. Zum Test reicht es.(heute regnet es) Bin noch aus der analog Zeit. Habe es jedoch geschafft das fertige bin File auf einen Wemos D1 mini zum laufen zu bringen. Leider hab ich es nicht geschafft die Daten (MQTT) ins Openhab 3 einzubinden. Grosse Lob an alle die hier so hart Arbeiten. Leider kann ich ausser testen nichts beitragen. Gruß
:
Bearbeitet durch User
Habe mir nochmal das ganze aus Gitee angeschaut. Mir ist was aufgefallen, kann aber nicht bestätigen ob das sinnig ist. Mein Gedanke dazu: Der unten stehende Code beschreibt wie ein PowerLimit abläuft. Ich glaube das der WR in der Lage ist sogar einzelne Strings kontrolliert abzuschalten, oder Einzuschalten. Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd' mit Bit-Operatoren verarbeitet. ... Könnt ihr aber auch selbst unten lesen. Was mich noch stutzig macht, was könnte 'Acq_Switch' genau bedeuten?
1 | /*********************************************** |
2 | ** Function name: |
3 | ** Descriptions: set micro-inverter power instruction |
4 | ** input parameters: |
5 | ** output parameters: |
6 | ** Returned value: |
7 | *************************************************/ |
8 | uint8_t UsartNrf_Send_PackSetPowerLimitCommand(uint8_t *target_adr, uint8_t *rout_adr, int8_t MainCmd, uint16_t SubCmd) |
9 | {
|
10 | uint8_t i = 0; |
11 | uint8_t temp_dat[UART_LEN]; //(#define UART_LEN 35) |
12 | memset(temp_dat, 0, sizeof(temp_dat)); |
13 | Uart_SendBuffer[0] = STX;//head (#define STX 0x7e) |
14 | temp_dat[0] = MainCmd; //instruction |
15 | memcpy(&temp_dat[1], target_adr, 4); |
16 | memcpy(&temp_dat[5], rout_adr, 4); |
17 | |
18 | if(MIMajor[PortNO].Property.Acq_Switch == 0) |
19 | {
|
20 | //1000w shutdown Micro-inverse control of 1-to-4 with the last 8 digits of the special control ID less than 0x50000000 |
21 | if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61))) |
22 | {
|
23 | temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a |
24 | temp_dat[10] = SubCmd & 0XFF; |
25 | temp_dat[11] = 11; |
26 | // temp = 35*4*10=1400=0x0578; |
27 | temp_dat[12] = 0X05; |
28 | temp_dat[13] = 0X78; |
29 | temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC |
30 | i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); // forward replacement |
31 | } |
32 | else |
33 | {
|
34 | temp_dat[9] = SubCmd >> 8; //5a5a |
35 | temp_dat[10] = SubCmd ; |
36 | temp_dat[11] = Get_crc_xor(&temp_dat[0], 11); //CRC |
37 | i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 12); //forward substitution |
38 | } |
39 | } |
40 | else |
41 | {
|
42 | temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a |
43 | temp_dat[10] = SubCmd & 0XFF; |
44 | temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power limit percentage |
45 | temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8; //High 8-bit power limit |
46 | temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff; //Low power limit 8 bits |
47 | temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC |
48 | i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //forward substitution |
49 | } |
50 | |
51 | Uart_SendBuffer[(i + 1)] = ETX; //tail |
52 | memset(temp_dat, 0, sizeof(temp_dat)); |
53 | return (i + 2); |
54 | } |
:
Bearbeitet durch User
Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den China Wemos Clones liegt. Leider bekomme ich damit auch keine mehrstündigen Uptimes hin. Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber irgendwie muß man das doch sauber zum laufen bekommen. Läuft das bei euch über Tage ohne Reboot ???
Ich kann nichts dazu beitragen. Ich nutze es über Raspberry Pi. Zusätzlich läuft es aktuell noch nicht (warte immer noch auf die PVs).
Holger S. schrieb: > Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x > Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch > rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den > China Wemos Clones liegt. > > Leider bekomme ich damit auch keine mehrstündigen Uptimes hin. > Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber > irgendwie muß man das doch sauber zum laufen bekommen. > > Läuft das bei euch über Tage ohne Reboot ??? Ja, über mehrere Wochen stabil
Daniel R. schrieb: > Ich kann nichts dazu beitragen. Was soll dann der Beitrag? Wenn das jeder macht.....
Ok der Beitrag 'Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"; ist doch erstmal hinfällig. Die Funktion macht nichts anderes als wie in der Excel im Blatt "Control instruction" Zeile 91. Somit könnt ihr denn Teil erstmal überfliegen. ^^ Ist ja für MI, nicht für mich HM.
:
Bearbeitet durch User
@Holger S. (skusi) Hallo, ich habe die uralt "hubi" Version für den ESP8266 ohne MQTT (Stromversorgung vom PC über USB ca. 2,5m Kabel, kleiner Elko am RF Modul, alles total einfach auf einem Steckbrett) und ich habe damit noch keinen eigenständigen Reboot erlebt. Stört evt. was aus der Umgebung ? Motoren ? Hohe plötzliche Stromaufnahme von Waschmaschine, Geschirrspüler, Staubsauger ? Anlauf von Kompressoren ? Bohrmaschinen (oder ähnliche Motoren) wo die Kohlen feuern ? Oder evt. einfach der WDT, der zuschlägt, weil die Stromversorgung nicht sauber ist ? Kann ja evt. auch aus der Nachbarschaft kommen ? - nur so Ideen -
:
Bearbeitet durch User
Hallo Daniel R.,
danke daß Du Dir den Source vom Hersteller ansiehst und nicht die leider
etwas überholten Informationen im hoymiles-format-description.txt/.md.
Es hat sich leider noch niemand gefunden, der das Format/Protokoll auf
den aktuellen Wissensstand bringt, ich auch noch nicht =^/
Wenn Du dazu jetzt noch die hoymiles-DTU-PRO-GPRS mit der aktuelleren
hoymiles-DTU-PRO-APP vergleichst wurde an der von Dir angesprochenen
Stelle noch folgende Vorbedingung in User/NRF/usart_nrf.c eingebaut:
#ifdef DTU3PRO
if((Dtu3Detail.Property.Zero_Export_Switch == 1) ||
(Dtu3Detail.Property.DRM_Limit_Switch == 1) ||
(Dtu3Detail.Property.Phase_Balance_Switch == 1) ||
(Dtu3Detail.Property.SunSpec_Switch == 1))
{
if(MIMajor[PortNO].Property.Acq_Switch == 0)
{
//1000w¹Ø»ú ÌØÊâ¿ØÖÆ IDºó8λСÓÚ0x50000000µÄ1ÍÏËÄ µÄ΢Äæ¿ØÖÆ
if((MIMajor[PortNO].Property.Id[0] < 0X50) &&
((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) ||
(MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
...
Den chinesesischen Unicode Kauderwelsch aus den beiden aktuelleren Repos
habe ich noch nicht übersetzt.
:
Bearbeitet durch User
Hallo Josef J., Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen. Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2 und 3. Dann sollte es m.E. nach einem Reboot funktionieren. Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst angepaßt / gefixt.
Hallo Daniel R., im usart_nrf3.c findet sich übrigens noch der folgende Code:
1 | void UsartNrf3_Send_NetCmdToNrfCmd(void) |
2 | {
|
3 | if((CurNetCmd >= NET_TURN_ON) && (CurNetCmd <= NET_ELE_ENERGY)) |
4 | {
|
5 | switch(CurNetCmd) |
6 | {
|
7 | case NET_INVERTER_HW_INFOR: |
8 | //case NET_TERMINAL_INFOR: |
9 | SubCmd = InverterDevInform_Simple; |
10 | MainCmd = REQ_ARW_DAT_ALL; |
11 | break; |
12 | |
13 | case NET_POLL_GRID_ON_FILE: |
14 | SubCmd = GridOnProFilePara; |
15 | MainCmd = REQ_ARW_DAT_ALL; |
16 | break; |
17 | |
18 | //////////////////////////////////////////////////////////////////////ÔËÐпØÖÆ |
19 | |
20 | case NET_TURN_ON: |
21 | SubCmd = Type_TurnOn;//¿ª»ú |
22 | MainCmd = DEVCONTROL_ALL; |
23 | break; |
24 | |
25 | case NET_TURN_OFF: |
26 | SubCmd = Type_TurnOff;//¹Ø»ú |
27 | MainCmd = DEVCONTROL_ALL; |
28 | break; |
29 | |
30 | case NET_LIMIT_ACTIVE_POEWR: |
31 | case NET_LIMIT_POEWR: |
32 | SubCmd = Type_ActivePowerContr ;//ÏÞÖÆÓйŠ¹ŠÂÊ |
33 | MainCmd = DEVCONTROL_ALL; |
34 | break; |
35 | |
36 | case NET_LIMIT_REACTIVE_POWER: |
37 | SubCmd = Type_ReactivePowerContr ;//ÏÞÖÆÎÞ¹Š¹ŠÂÊ |
38 | MainCmd = DEVCONTROL_ALL; |
39 | break; |
40 | |
41 | case NET_PF_SET: |
42 | SubCmd = Type_PFSet ;//ÏÞÖƹŠÂÊÒòÊý |
43 | MainCmd = DEVCONTROL_ALL; |
44 | break; |
45 | |
46 | case NET_CLEAN_GFDI: |
47 | case NET_CLEAR_ALARM: |
48 | SubCmd = Type_CleanState_LockAndAlarm ;//ËøËÀžæŸ¯Çå³ý |
49 | MainCmd = DEVCONTROL_ALL; |
50 | break; |
51 | |
52 | case NET_RESTART: //ÏÂÔسÌÐò/žŽÎ» |
53 | MainCmd = DEVCONTROL_ALL; |
54 | SubCmd = Type_Restart; |
55 | break; |
56 | |
57 | case NET_UNLOCK: |
58 | SubCmd = Type_Unlock; |
59 | MainCmd = DEVCONTROL_ALL; |
60 | break; |
61 | |
62 | case NET_LOCK: |
63 | SubCmd = Type_Lock; |
64 | MainCmd = DEVCONTROL_ALL; |
65 | break; |
66 | |
67 | //dong 2020-06-15 |
68 | case NET_SELF_INSPECTION: |
69 | SubCmd = Type_SelfInspection;//×ÔŒì |
70 | MainCmd = DEVCONTROL_ALL; |
71 | break; |
72 | |
73 | ////////////////////////////////////////////////////////////////²ÎÊýÅäÖà |
74 | case NET_ELE_ENERGY: |
75 | case NET_SET_ENERGY: |
76 | SubCmd = EleEnergySet; |
77 | MainCmd = PARASET_ALL; |
78 | break; |
79 | |
80 | case NET_SET_PASSWORD: |
81 | case NET_CANCEL_GUARD: |
82 | SubCmd = AntitheftParaSet;//ÉèÖÃÃÜÂë |
83 | MainCmd = PARASET_ALL; |
84 | break; |
85 | |
86 | ////////////////////////////////////////////////////////////////ÎÄŒþ¶à°üžüÐÂÎÄŒþ |
87 | case NET_DOWNLOAD_PRO: |
88 | MainCmd = DOWN_PRO; |
89 | SubCmd = Type_Init; |
90 | break; |
91 | |
92 | case NET_DOWNLOAD_DAT://²¢Íø±£»€ÎÄŒþ |
93 | MainCmd = DOWN_DAT; |
94 | SubCmd = Type_Init; |
95 | break; |
96 | |
97 | default: |
98 | break; |
99 | } |
100 | } |
101 | else if(CurNetCmd == NET_INIT) |
102 | {
|
103 | MainCmd = REQ_ARW_DAT_ALL; |
104 | |
105 | if(CurPollIsDebugDataTime == false) |
106 | {
|
107 | SubCmd = RealTimeRunData_Reality; |
108 | } |
109 | else |
110 | {
|
111 | SubCmd = RealTimeRunData_Debug; |
112 | } |
113 | } |
114 | //dong 2020-06-15 |
115 | // else if(CurNetCmd == NET_SELF_STAUS) |
116 | // {
|
117 | // MainCmd = REQ_ARW_DAT_ALL; |
118 | // SubCmd = GetSelfCheckState; |
119 | // } |
120 | //dong 2020-06-23 |
121 | // else if(CurNetCmd == NET_GET_LOSS_RATE) |
122 | // {
|
123 | // MainCmd = REQ_ARW_DAT_ALL; |
124 | // SubCmd = GetLossRate; |
125 | // } |
126 | else if(CurNetCmd == NET_ALARM_DATA) |
127 | {
|
128 | MainCmd = REQ_ARW_DAT_ALL; |
129 | SubCmd = AlarmData; |
130 | } |
131 | else if(CurNetCmd == NET_RECORD_DATA) |
132 | {
|
133 | MainCmd = REQ_ARW_DAT_ALL; |
134 | SubCmd = RecordData; |
135 | } |
136 | else if(CurNetCmd == NET_ALARM_UPDATE) |
137 | {
|
138 | MainCmd = REQ_ARW_DAT_ALL; |
139 | SubCmd = AlarmUpdate; |
140 | } |
141 | else if(CurNetCmd == NET_MI_VERSION) |
142 | {
|
143 | SubCmd = InverterDevInform_Simple; |
144 | MainCmd = REQ_ARW_DAT_ALL; |
145 | } |
146 | } |
in der usart_nrf3.h stehen die Defines:
1 | #define DEVCONTROL_ALL 0x51 |
2 | ... |
3 | typedef enum |
4 | {
|
5 | Type_TurnOn = 0, |
6 | Type_TurnOff = 1, |
7 | Type_Restart = 2, |
8 | Type_Lock = 3, |
9 | Type_Unlock = 4, |
10 | Type_ActivePowerContr = 11, // 0x0b |
11 | Type_ReactivePowerContr = 12, // 0x0c |
12 | Type_PFSet = 13, // 0x0d |
13 | Type_CleanState_LockAndAlarm = 20, |
14 | //dong 06-15 |
15 | Type_SelfInspection = 40,//���������ļ��Լ� |
16 | Type_Init = 0xff, |
17 | } DevControlType; |
Aber ich dachte das hätten wir schon letzte / vorletzte Woche festgestellt. Bitte schau Dir das doch auch mal an ...
@isnoahoy: Danke für deine Rückmeldung. Ja da bin ich gerade dran und schaue mir das nochmal inruhe durch. Ich versuche aktuell aus den "usart_nrf3" denn genauen Aufbau des Protokolls nachzuverfolgen.
Angehängte Dateien:
Stefan T. schrieb: > Hallo Josef J., > > Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen. > Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2 > und 3. Dann sollte es m.E. nach einem Reboot funktionieren. > > Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen > Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst > angepaßt / gefixt. Vielen Dank, das hatte ich gerade zufällig selber probiert. Leider ohne Erfolg.
Hallo zusammen, und vielen Dank für euere tolle Arbeit. Hab mir vor 2 Tagen bei komputer.de die Chips bestellt: 1 Stk. nRF24L01+ PA SMA mit Antenne 3.20EUR 1 Stk. ESP32 Development board NodeMCU kompatibel 6.50EUR Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen. Nach nur 6 Jahren! Gruselig… Grüße, Matze
Beitrag #7112309 wurde vom Autor gelöscht.
Kann jemand was dazu sagen wie man das zu verstehen hat? Habe folgendes nachgestellt: case NET_LIMIT_ACTIVE_POEWR: // NET_LIMIT_ACTIVE_POEWR = 24, case NET_LIMIT_POEWR: // NET_LIMIT_POEWR = 3, SubCmd = Type_ActivePowerContr; //Limit active power = 11, MainCmd = DEVCONTROL_ALL; // #define DEVCONTROL_ALL 0x51 break;
1 | 2022-06-29 18:13:17.628811 Transmit 11 | 51 74 40 33 29 78 56 34 12 0b 7c |
2 | 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: d1 74 40 33 29 74 40 33 29 81 50 |
3 | Error while retrieving data: unpack requires a buffer of 2 bytes |
Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten nachzusenden? https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt (Zeile: 520) Ist ja ähnlich aufgebaut. Ich habe zwar in der Vergangenheit gelesen das jmd. herausgefunden hat (oder mutmaßt) das wenn die ID vom WR zweimal hintereinander steht, soll es sich um ein Verworfenes Packet handeln.
:
Bearbeitet durch User
Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die mit abgespeichert wurden. Copy-paste Fehler.
Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die mit abgespeichert wurden. Copy-paste Fehler.
Hallo Josef J., Hfhausen schrieb: > Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die > mit abgespeichert wurden. Copy-paste Fehler. Das könnte auch eine Ursache sein, probier das doch mal aus bzw. überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte: https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584 Desweiteren wäre es hilfreich den ESP8266 per USB Kabel am Computer/Laptop angeschloßen zu lassen. Wenn Du unter Tools > Port den Anschluß prüfst und dann die Serial Console aufmachst, solltest Du nach einem Reset ein etwas ausführlicheres Debug Log bekommen. Die Statistik auf der WebSeite in Deinem Screenshot sagt an der Stelle leider nicht mehr aus. Das Debug Log enthält auch Informationen zum Anschluß des nRF24L01+ und dessen Einstellungen.
Daniel R. schrieb: > Ich glaube das der WR in der Lage ist sogar einzelne Strings > kontrolliert abzuschalten, oder Einzuschalten. > Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd' > mit Bit-Operatoren verarbeitet. > ... Könnt ihr aber auch selbst unten lesen. > > temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a > temp_dat[10] = SubCmd & 0XFF; > temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 / > (EVERY_PORT_POWER * > (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power > limit percentage > temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8; > //High 8-bit power limit > temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff; > //Low power limit 8 bits > temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC > i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); > //forward substitution > } Das habe ich schon beschrieben und implementiert, siehe meinen Beitrag v. früher: - nach % limitieren SubCMD=5a5a:limit percentage:,CRC - nach abs.Leistung limitieren: SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC
mein esp8266 lief nie länger als 1h.
Fehler beim Debuggen:
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Exception (29):
epc1=0x4000df64 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000
depc=0x00000
000
>>>stack>>>
ctx: sys
sp: 3fffec10 end: 3fffffb0 offset: 0190
3fffeda0: 00000005 3ffee120 00000002 40100524
3fffedb0: 402329d7 3ffefb6c 3ffea5ef 4023296c
3fffedc0: 00000002 40232913 00000002 40231a68
3fffedd0: 40231a91 3fffee80 3ffee120 00000016
3fffede0: 4022f4f4 3fffee80 3ffedfc8 3ffed9c0
3fffedf0: 3ffeb1d8 3fffee80 3fffee80 00000000
3fffee00: 2d525744 5f363131 46393345 00004334
3fffee10: 00000000 3ffecc90 00000020 40100bdc
3fffee20: 4022b859 4022cd31 3ffed8d0 00000000
3fffee30: ffffffc0 3ffedadc 3ffeb1e8 3ffee120
3fffee40: 3ffed020 00000020 00000000 402301ef
3fffee50: 00000000 3ffefb6c ffffffc0 00000000
3fffee60: 00000000 3ffee120 3ffee800 304baf06
3fffee70: 4023bfc2 3ffefb6c 0000000e 3ffee014
3fffee80: 00000000 00310a0a 00640100 00000053
3fffee90: 3ffeb1fc 000000d6 3ffeb21f 3ffeb1f0
3fffeea0: 00000000 3ffeb1fc 3ffeb20c 3ffeb219
3fffeeb0: 00000000 00000000 3ffeb292 3ffeb2a8
3fffeec0: 3ffeb25b 3ffeb277 00000000 3ffeb225
3fffeed0: 00000000 00000000 00000020 00000000
3fffeee0: 3ffefe14 4022fc5e 3ffed020 3ffefb6c
3fffeef0: 00000000 3ffee120 3ffed020 3ffeb1d8
3fffef00: 3ffeb1d8 000000fe 00000000 00000020
3fffef10: 00000000 3ffeb1e2 40243313 3ffed020
3fffef20: 3ffeb1cc 3fffdcc0 3ffe9730 3ffe9730
3fffef30: 00000080 3ffed020 00000000 3ffe85d8
3fffef40: 40242bd3 3fffdab0 00000000 40211f56
3fffef50: 3ffe9730 40000f49 3fffdab0 40000f49
3fffef60: 40000e19 0005aef1 00000000 00000005
3fffef70: 60000600 aa55aa55 000000ed 40105539
3fffef80: 4010553f 00000000 00000005 40100b8c
3fffef90: 4010000d 8742b1f0 0005aef1 401000ac
3fffefa0: 00000000 3fffef3c 00000000 3ffffec8
3fffefb0: 3fffffc0 00000000 00000000 feefeffe
3fffefc0: feefeffe feefeffe feefeffe feefeffe
3fffefd0: feefeffe feefeffe feefeffe feefeffe
3fffefe0: feefeffe feefeffe feefeffe feefeffe
3fffeff0: feefeffe feefeffe feefeffe feefeffe
3ffff000: feefeffe feefeffe feefeffe feefeffe
3ffff010: feefeffe feefeffe feefeffe feefeffe
3ffff020: feefeffe feefeffe feefeffe feefeffe
3ffff030: feefeffe feefeffe feefeffe feefeffe
3ffff040: feefeffe feefeffe feefeffe feefeffe
3ffff050: feefeffe feefeffe feefeffe feefeffe
3ffff060: feefeffe feefeffe feefeffe feefeffe
3ffff070: feefeffe feefeffe feefeffe feefeffe
3ffff080: feefeffe feefeffe feefeffe feefeffe
3ffff090: feefeffe feefeffe feefeffe feefeffe
3ffff0a0: feefeffe feefeffe feefeffe feefeffe
3ffff0b0: feefeffe feefeffe feefeffe feefeffe
3ffff0c0: feefeffe feefeffe feefeffe feefeffe
3ffff0d0: feefeffe feefeffe feefeffe feefeffe
3ffff0e0: feefeffe feefeffe feefeffe feefeffe
3ffff0f0: feefeffe feefeffe feefeffe feefeffe
3ffff100: feefeffe feefeffe feefeffe feefeffe
3ffff110: feefeffe feefeffe feefeffe feefeffe
3ffff120: feefeffe feefeffe feefeffe feefeffe
3ffff130: feefeffe feefeffe feefeffe feefeffe
3ffff140: feefeffe feefeffe feefeffe feefeffe
3ffff150: feefeffe feefeffe feefeffe feefeffe
3ffff160: feefeffe feefeffe feefeffe feefeffe
3ffff170: feefeffe feefeffe feefeffe feefeffe
3ffff180: feefeffe feefeffe feefeffe feefeffe
3ffff190: feefeffe feefeffe feefeffe feefeffe
3ffff1a0: feefeffe feefeffe feefeffe feefeffe
3ffff1b0: feefeffe feefeffe feefeffe feefeffe
3ffff1c0: feefeffe feefeffe feefeffe feefeffe
3ffff1d0: feefeffe feefeffe feefeffe feefeffe
3ffff1e0: feefeffe feefeffe feefeffe feefeffe
3ffff1f0: feefeffe feefeffe feefeffe feefeffe
3ffff200: feefeffe feefeffe feefeffe feefeffe
3ffff210: feefeffe feefeffe feefeffe feefeffe
3ffff220: feefeffe feefeffe feefeffe feefeffe
3ffff230: feefeffe feefeffe feefeffe feefeffe
3ffff240: feefeffe feefeffe feefeffe feefeffe
3ffff250: feefeffe feefeffe feefeffe feefeffe
3ffff260: feefeffe feefeffe feefeffe feefeffe
3ffff270: feefeffe feefeffe feefeffe feefeffe
3ffff280: feefeffe feefeffe feefeffe feefeffe
3ffff290: feefeffe feefeffe feefeffe feefeffe
3ffff2a0: feefeffe feefeffe feefeffe feefeffe
3ffff2b0: feefeffe feefeffe feefeffe feefeffe
3ffff2c0: feefeffe feefeffe feefeffe feefeffe
3ffff2d0: feefeffe feefeffe feefeffe feefeffe
3ffff2e0: feefeffe feefeffe feefeffe feefeffe
3ffff2f0: feefeffe feefeffe feefeffe feefeffe
3ffff300: feefeffe feefeffe feefeffe feefeffe
3ffff310: feefeffe feefeffe feefeffe feefeffe
3ffff320: feefeffe feefeffe feefeffe feefeffe
3ffff330: feefeffe feefeffe feefeffe feefeffe
3ffff340: feefeffe feefeffe feefeffe feefeffe
3ffff350: feefeffe feefeffe feefeffe feefeffe
3ffff360: feefeffe feefeffe feefeffe feefeffe
3ffff370: feefeffe feefeffe feefeffe feefeffe
3ffff380: feefeffe feefeffe feefeffe feefeffe
3ffff390: feefeffe feefeffe feefeffe feefeffe
3ffff3a0: feefeffe feefeffe feefeffe feefeffe
3ffff3b0: feefeffe feefeffe feefeffe feefeffe
3ffff3c0: feefeffe feefeffe feefeffe feefeffe
3ffff3d0: feefeffe feefeffe feefeffe feefeffe
3ffff3e0: feefeffe feefeffe feefeffe feefeffe
3ffff3f0: feefeffe feefeffe feefeffe feefeffe
3ffff400: feefeffe feefeffe feefeffe feefeffe
3ffff410: feefeffe feefeffe feefeffe feefeffe
3ffff420: feefeffe feefeffe feefeffe feefeffe
3ffff430: feefeffe feefeffe feefeffe feefeffe
3ffff440: feefeffe feefeffe feefeffe feefeffe
3ffff450: feefeffe feefeffe feefeffe feefeffe
3ffff460: feefeffe feefeffe feefeffe feefeffe
3ffff470: feefeffe feefeffe feefeffe feefeffe
3ffff480: feefeffe feefeffe feefeffe feefeffe
3ffff490: feefeffe feefeffe feefeffe feefeffe
3ffff4a0: feefeffe feefeffe feefeffe feefeffe
3ffff4b0: feefeffe feefeffe feefeffe feefeffe
3ffff4c0: feefeffe feefeffe feefeffe feefeffe
3ffff4d0: feefeffe feefeffe feefeffe feefeffe
3ffff4e0: feefeffe feefeffe feefeffe feefeffe
3ffff4f0: feefeffe feefeffe feefeffe feefeffe
3ffff500: feefeffe feefeffe feefeffe feefeffe
3ffff510: feefeffe feefeffe feefeffe feefeffe
3ffff520: feefeffe feefeffe feefeffe feefeffe
3ffff530: feefeffe feefeffe feefeffe feefeffe
3ffff540: feefeffe feefeffe feefeffe feefeffe
3ffff550: feefeffe feefeffe feefeffe feefeffe
3ffff560: feefeffe feefeffe feefeffe feefeffe
3ffff570: feefeffe feefeffe feefeffe feefeffe
3ffff580: feefeffe feefeffe feefeffe feefeffe
3ffff590: feefeffe feefeffe feefeffe feefeffe
3ffff5a0: feefeffe feefeffe feefeffe feefeffe
3ffff5b0: feefeffe feefeffe feefeffe feefeffe
3ffff5c0: feefeffe feefeffe feefeffe feefeffe
3ffff5d0: feefeffe feefeffe feefeffe feefeffe
3ffff5e0: feefeffe feefeffe feefeffe feefeffe
3ffff5f0: feefeffe feefeffe feefeffe feefeffe
3ffff600: feefeffe feefeffe feefeffe feefeffe
3ffff610: feefeffe feefeffe feefeffe feefeffe
3ffff620: feefeffe feefeffe feefeffe feefeffe
3ffff630: feefeffe feefeffe feefeffe feefeffe
3ffff640: feefeffe feefeffe feefeffe feefeffe
3ffff650: feefeffe feefeffe feefeffe feefeffe
3ffff660: feefeffe feefeffe feefeffe feefeffe
3ffff670: feefeffe feefeffe feefeffe feefeffe
3ffff680: feefeffe feefeffe feefeffe feefeffe
3ffff690: feefeffe feefeffe feefeffe feefeffe
3ffff6a0: feefeffe feefeffe feefeffe feefeffe
3ffff6b0: feefeffe feefeffe feefeffe feefeffe
3ffff6c0: feefeffe feefeffe feefeffe feefeffe
3ffff6d0: feefeffe feefeffe feefeffe feefeffe
3ffff6e0: feefeffe feefeffe feefeffe feefeffe
3ffff6f0: feefeffe feefeffe feefeffe feefeffe
3ffff700: feefeffe feefeffe feefeffe feefeffe
3ffff710: feefeffe feefeffe feefeffe feefeffe
3ffff720: feefeffe feefeffe feefeffe feefeffe
3ffff730: feefeffe feefeffe feefeffe feefeffe
3ffff740: feefeffe feefeffe feefeffe feefeffe
3ffff750: feefeffe feefeffe feefeffe feefeffe
3ffff760: feefeffe feefeffe feefeffe feefeffe
3ffff770: feefeffe feefeffe feefeffe feefeffe
3ffff780: feefeffe feefeffe feefeffe feefeffe
3ffff790: feefeffe feefeffe feefeffe feefeffe
3ffff7a0: feefeffe feefeffe feefeffe feefeffe
3ffff7b0: feefeffe feefeffe feefeffe feefeffe
3ffff7c0: feefeffe feefeffe feefeffe feefeffe
3ffff7d0: feefeffe feefeffe feefeffe feefeffe
3ffff7e0: feefeffe feefeffe feefeffe feefeffe
3ffff7f0: feefeffe 00000000 feefeffe 00000100
3ffff800: 000000d0 00000000 40105385 00000100
3ffff810: 000000d0 00000000 40105385 000000ee
3ffff820: 00000129 00000001 40105385 3ffed7f8
3ffff830: 3ffed780 00000001 40105385 3ffed7f8
3ffff840: 3ffe9635 40105437 3ffed0c0 00000100
3ffff850: 00000005 00000000 00000020 401001c8
3ffff860: 00007fff 00000000 00000005 000000fe
3ffff870: 0000005c 00000001 40105385 3ffed7f8
3ffff880: 3ffed780 3ffed020 401033c2 00000100
3ffff890: 00007fff 01698d04 3ffed9c0 40102f08
3ffff8a0: 40104f6a 3ffed7f8 00000000 401001c8
3ffff8b0: 00007fff 401048b9 3ffed7f8 00000100
3ffff8c0: 3ffe9ec8 7fffffff 00002200 00000001
3ffff8d0: 40104e6d 3ffed7f8 3ffeccd8 00040000
3ffff8e0: 53002200 00000030 00000005 401021a0
3ffff8f0: 40105145 00080000 00000002 3fffc278
3ffff900: 40103412 3ffed0c0 00000022 00000014
3ffff910: 00007fff 00000000 3ffed9c0 40102f08
3ffff920: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffff930: 401030e4 3fffc200 00000022 00000100
3ffff940: 40219018 00000030 00000010 ffffffff
3ffff950: 40219013 00000030 00303032 3ffffc52
3ffff960: 00000003 00000003 4021b6bc 3ffffba0
3ffff970: 00000000 00000000 3ffffb33 3ffffc50
3ffff980: 3ffffc50 00000002 00000003 00000030
3ffff990: 40245675 00000030 00000010 ffffffff
3ffff9a0: 00002000 00000000 3ffed480 00000020
3ffff9b0: 3ffed4a0 00000042 3fff353e 0000008a
3ffff9c0: 00000002 00000000 0000000a 00000000
3ffff9d0: 00000002 00000000 40243d2f 00000000
3ffff9e0: ffffffff 00000000 3ffe9781 00000000
3ffff9f0: 40243d7e 3ffeccd8 3ffefb6c 00000001
3ffffa00: 40243e8a 3ffeccd8 3ffefb6c 3ffeccd8
3ffffa10: 00000005 00000005 00000008 3fff3620
3ffffa20: 3ffe9632 40242e3b 3ffeccd8 3fff3604
3ffffa30: 00000000 4022c477 3ffee120 3ffefb6c
3ffffa40: 00000000 00000002 00000000 3ffeccd8
3ffffa50: 3fff363a 40105a7b 3fff1f0c 3ffef57c
3ffffa60: 3ffefe14 00000000 3ffffba0 4021b780
3ffffa70: 4021b6bc 4021d7e5 3fff1f0c 3ffef57c
3ffffa80: 00000005 00000000 00000020 401001c8
3ffffa90: 3ffffb2f 00000000 00000005 401021a0
3ffffaa0: 3ffe9635 40105437 3ffed020 4021da13
3ffffab0: 40102d2b 3ffed020 00000000 4021de6e
3ffffac0: fffffff5 3000f717 3ffed96c 40102f08
3ffffad0: 3ffe9ed4 00000000 00000000 3ffef8b0
3ffffae0: fffffff5 3000f717 401033c2 00000100
3ffffaf0: 3ffe9ed4 7fffffff 00002200 00000001
3ffffb00: 00000001 00000080 00302064 3ffe8368
3ffffb10: 3ffe9ed4 00000000 0000001f 3000f717
3ffffb20: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffb30: 401030e4 3fffc200 00000022 401001c8
3ffffb40: 402120b4 00000030 00000008 ffffffff
3ffffb50: 40213564 000c3500 00000647 13a71553
3ffffb60: 00000003 4020eb18 0000007f 00000080
3ffffb70: 000000b0 3fffc6fc 00000001 3ffffc91
3ffffb80: 00000003 00000000 fffffffc 00000030
3ffffb90: fffffff5 2f5066c1 401033c2 00000100
3ffffba0: 3ffe9ed4 7fffffff 00002200 00000001
3ffffbb0: 00000001 00000080 3ffed020 401001c8
3ffffbc0: 3ffe9ed4 3ffed020 3fffc228 2f5066c1
3ffffbd0: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffbe0: 401030e4 3fffc200 00000022 ffffffff
3ffffbf0: 4021353d 00000030 00000010 ffffffff
3ffffc00: 00000000 00000002 3ffffc51 40213564
3ffffc10: 3ffffc52 4020eb18 3fffc228 40105cd1
3ffffc20: 00000000 00000000 0000001f 401001c8
3ffffc30: 00000002 40252c3c 3fffc228 40105cd1
3ffffc40: 4000050c 40252c3c 00000000 4020fce0
3ffffc50: 402023ad 00000030 0000001c ffffffff
3ffffc60: 402023aa 0000002f 00000013 00000190
3ffffc70: 60000120 00000000 0000007f 00000080
3ffffc80: 00000000 3ffe87fc 0000a7f0 3fff12b8
3ffffc90: 0000000b 3fff12e0 3fff12a4 00000030
3ffffca0: 40100348 00000000 00000004 401010e8
3ffffcb0: 40100348 00000000 00000004 401010e8
3ffffcc0: 40100348 00000000 00000004 401010e8
3ffffcd0: 40100348 00000001 00000004 401010e8
3ffffce0: 00000005 00000000 00000020 401001c8
3ffffcf0: 40100348 00000022 00000005 401021a0
3ffffd00: 3ffe9635 40105437 3ffed020 4020c230
3ffffd10: 40102d2b 3ffed020 0000001f 401001c8
3ffffd20: 00000000 304c3b2f 3ffed9c0 40102f08
3ffffd30: 3ffe9ed4 00000000 00000000 401001c8
3ffffd40: 00000000 304c3b2f 401033c2 00000100
3ffffd50: 3ffe9ed4 7fffffff 00002200 00000001
3ffffd60: 00000001 00000080 3fffc228 40105cd1
3ffffd70: 3ffe9ed4 00000030 00000010 304c3b2f
3ffffd80: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffd90: 401030e4 3fffc200 00000022 fffffffe
3ffffda0: 40000671 00000030 00000010 ffffffff
3ffffdb0: 00000000 7d0ada90 0e4bd28b 00000000
3ffffdc0: 00004bc6 7d0ada90 00000000 fffffffe
3ffffdd0: 000033c3 3fffc6fc 2c80da90 304c43d7
3ffffde0: 4bc6a7f0 3ffeec70 3ffef178 00000030
3ffffdf0: 40204d64 00000030 00000010 ffffffff
3ffffe00: 40204d64 3ffef30c 2ade07a0 40237b0d
3ffffe10: 00000000 00000000 00000000 fffffffe
3ffffe20: ffffffff 3fffc6fc 00000001 3ffef164
3ffffe30: 00000000 00000000 0000001f 401001c8
3ffffe40: 00000000 304aab27 3fffc228 4020b5a2
3ffffe50: 00000001 4bc6a7f0 75c28f5c 0e4bd288
3ffffe60: 00000001 00000000 4bc6a7f0 00000000
3ffffe70: 3ffeec70 00000000 401002dd 00000001
3ffffe80: 000c5d40 00000000 00001388 4020c1c5
3ffffe90: 00000001 4bc6a7f0 7d70a3d7 0e4bd291
3ffffea0: 00000001 00000000 4bc6a7f0 00000000
3ffffeb0: 00000000 00000000 401002dd 00000001
3ffffec0: 000c5d40 3fff12b8 3ffef164 3ffef178
3ffffed0: 3ffeec70 00000000 3ffef164 3ffef178
3ffffee0: 3ffeec70 3ffeef70 3ffef164 40204f7c
3ffffef0: 00000000 3fffdad0 3ffef178 00000030
3fffff00: 00000000 3fffdad0 3ffef178 00000030
3fffff10: 6f697461 feef006e feefeffe 0000effe
3fffff20: 00000000 0023002f 00000000 00000000
3fffff30: 0024002f 00000000 00000000 0017001f
3fffff40: 00000000 00000000 0010001f 00000000
3fffff50: 30372e30 00572030 000000b0 3ffef178
3fffff60: 007a1200 2b2c49c4 00000000 3fff1704
3fffff70: 00000000 3fff16ec 3fff16ec 00000010
3fffff80: 00000000 00000000 00000001 401001c8
3fffff90: 3fffdad0 00000000 3ffef164 401001e9
3fffffa0: feefeffe feefeffe 3ffef164 4021211a
<<<stack<<<
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Daniel R. schrieb: >
1 | 2022-06-29 18:13:17.628811 Transmit 11 | 51 74 40 33 29 78 56 34 |
2 | > 12 0b 7c |
3 | > 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: d1 74 40 33 29 |
4 | > 74 40 33 29 81 50 |
5 | > Error while retrieving data: unpack requires a buffer of 2 bytes |
6 | > |
> > Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten > nachzusenden? Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du nachzusenden? nach CMD 0x51 sollte d1:WR|WR:5a:5a:d1 kommen und fertig, danach kommt nichts mehr. Und warum bei dir eine 0x81 kommt verstehe ich nicht.
@Daniel R. - nach abs.Leistung limitieren: SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC Limitleistung wird mit 1 DEC als int gesendet, zB. 123.4 Watt schickst du als 1234, darum hi/low bytes
Nur zu Info ich habe immer noch ein HM. Aktuell schaut es so aus:
1 | 2022-06-29 22:32:05.965908 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24 |
2 | 2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24 |
3 | 2022-06-29 22:32:08.439419 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24 |
Testweise auch mit 20%
1 | 2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
2 | 2022-06-29 22:34:48.077215 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
3 | 2022-06-29 22:34:49.311756 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
4 | 2022-06-29 22:34:50.547037 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
Bekomme halt kein Recieve. Ziyat T. schrieb: > Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du > nachzusenden? Ich hab es aus den Infos so verstanden das man erstmal ein Datenpaket zum WR schickt. Wenn dieser mit 0x81 Antworter können die nächsten Daten raus verschickt werden. Hatte ich hier im unteren Absatz geschrieben: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Daniel R. schrieb: > Nur zu Info ich habe immer noch ein HM. Ja ich weiss, vielleicht gehts ja auch mit HM > Testweise auch mit 20% > [code]2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 > 12 5a 5a 14 01 50 32 Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach % willst, musst du nach 0x14 die crc schicken, keine bytes mehr. >2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01 50 24 Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte 0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24 richtig?
Hallo Ziyat, erstmal danke das du dir Zeit für mich nimmst! :) Ziyat T. schrieb: >> Testweise auch mit 20% >> 2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 >> 12 5a 5a 14 01 50 32 > > Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach > % willst, musst du nach 0x14 die crc schicken, keine bytes mehr. Das würde dann bei mir so aussehen:
1 | 2022-06-30 05:43:01.828959 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 14 63 |
Auch hier bekomme ich kein Antwort vom WR. >>2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01 > 50 24 > > Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte > 0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24 > richtig? Das weiß ich nicht, ich habe bei der CRC Algorithmus nichts geändert. Nutze von Ahoy die rpi Version. - Wenn ich nur die Daten (DC/AC) vom WR Anfordern möchte, geht das ohne Probleme. Daher vermute ich das die CRC Berechnung passen wird.
:
Bearbeitet durch User
Hallo dax, ja wir beobachten das Problem der ESP8266 Variante schon seit längerem mit Argwohn. Wir haben auch schon einige Male einen Stack Trace in Github hochgeladen aber außer des/r nun stark optimierten Interrupt Handler haben wir bisher noch keinen Plan warum es so häufig zu WDT (Watch Dog Timer) Resets kommt. * Loosing WiFi connection after X minutes #15 https://github.com/grindylow/ahoy/issues/15 hier findet sich auch eine Anleitung verlinkt, nach der Du mit dem Binary Deinen Stack Trace decodieren kannst. * Zeitkritikalität in der Haupt-Loop? #24 https://github.com/grindylow/ahoy/issues/24 hier haben wir uns dem Thema Interrupt und State Machine gewidmet. * ESP8266: Discussion Verkabelung / Pinout #36 https://github.com/grindylow/ahoy/issues/36 hier hat Lukas P. zuletzt berichtet daß es bei ihm nach Vertauschen (!) der Pins für CE und IRQ stabiler lief. * Stabilität ESP8266 #83 https://github.com/grindylow/ahoy/issues/83 und hier diskutieren wir aktuell ob wir auch an der nRF24 Bibliothek Anpassungen vornehmen müssen/sollen. Alternativ zu den oben genannten Issues kannst Du gerne mal eines der anderen "Tools" ausprobieren (z.B. die offenbar problemlos laufende Raspberry Pi Variante von Jan-Jonas S., oder Hubi's Code für den ESP8266) oder die m.E. sehr saubere ESP32 Implementierung von Thomas B. unter https://github.com/tbnobody/OpenDTU Bei mir steckt der Code m.E. immer wieder in der WebServer Routine fest, da er einige Requests beantworten muß und dann stürzt er ab. Das ließe sich evtl. durch die AsyncWebServer Variante ersetzen, wie bei OpenDTU ? Oder es liegt daran, daß er mit zu häufigen Anfragen an RF24, MQTT und WebServer einfach überlastet wird. Er steckt meist in irgendwelchen ummalloc Routinen beim WDT Reset und daher vermute ich daß es etwas mit dem etwas zu offenherzigen Einsatz der String Klasse zu tun haben könnte, hier wird nämlich fleißig vom Flash/Progmem ins RAM kopiert um dann wieder an die Adresse des Zielstrings (z.B. beim + / Concatenieren) die Einzelstrings zu kopieren. Das kann evtl. auch einige CPU Zyklen brauchen.
Hallo Ziyat T. & Daniel R., ja und ja beim MI-XXXX Wechselrichter heißt das Command 0x51 in usart_nrf.c/.h CONTROL_LOCK_MI__LIMIT_POWER_ONOFF und beim HM-Wechselrichter wird laut usart_nrf3.c/.h 0x51 als DEVCONTROL_ALL definiert. D.h. das Kommando sieht beim HM-XXXX etwas anders aus nach dem SubCmd. Bei der Antwort kommt wie Daniel R. bereits geschrieben hat ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80) also 0xD1. Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL (REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden SubCmd's definiert als:
1 | typedef enum |
2 | {
|
3 | InverterDevInform_Simple = 0, |
4 | InverterDevInform_All = 1, |
5 | GridOnProFilePara = 2, |
6 | HardWareConfig = 3, |
7 | SimpleCalibrationPara = 4, |
8 | SystemConfigPara = 5, |
9 | RealTimeRunData_Debug = 11, // 0x0B |
10 | RealTimeRunData_Reality = 12, // 0x0C |
11 | RealTimeRunData_A_Phase = 13, // 0x0D |
12 | RealTimeRunData_B_Phase = 14, // 0x0E |
13 | RealTimeRunData_C_Phase = 15, // 0x0F //�澯����-����δ���澯 |
14 | AlarmData = 17, // 0x11 //�澯����-ȫ������澯 |
15 | AlarmUpdate = 18, // 0x12 |
16 | RecordData = 19, // 0x13 |
17 | InternalData = 20, // 0x14 |
18 | GetLossRate = 21, // 0x15 |
19 | //dong 2020-06-15 |
20 | GetSelfCheckState = 30, // 0x1E |
21 | InitDataState = 0xff, |
22 | |
23 | } DataType; |
Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S. hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert hatten. @Daniel R. 0x81, 0x82, 0x84 etc. sind die Paketkennungen des jeweils letzten Antwortpaketes auf eine RealTimeRunData_Debug 0x0B SubCmd Anfrage gewesen. Dabei wird das SubCmd-Feld in der Antwort durch einen Paketzähler ersetzt und beim letzten Paket das Komplement (Paketzähler | 0x80) mitgeliefert, damit die DTU weiß dass dies das letzte Fragment / Paket war. > 2022-06-29 18:13:17.628811 Transmit 11 | >51< <74 40 33 29> <78 56 34 12> >0b< <7c> > 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: >d1< <74 40 33 29> <74 40 33 29> >81< <50> Warum in Deiner Antwort als vorletztes Byte vor der CRC8 der Wert 0x81 auftaucht: Vielleicht ist es ja die Antwort 1 und als Komplement (Antwort | 0x80) = 0x81 ? Ob das einfach Okay oder gesetzt oder etwas ganz Anderes bedeutet müsstest DU anhand der Methoden im usart_nrf(3).c Code mal herausfinden.
Stefan T. schrieb: Danke Stefan T. (isnoahoy) ! Das hatte ich bisher übersehen. > typedef enum > { > InverterDevInform_Simple = 0, > InverterDevInform_All = 1, > GridOnProFilePara = 2, > HardWareConfig = 3, > SimpleCalibrationPara = 4, > SystemConfigPara = 5, > RealTimeRunData_Debug = 11, // 0x0B > RealTimeRunData_Reality = 12, // 0x0C > RealTimeRunData_A_Phase = 13, // 0x0D > RealTimeRunData_B_Phase = 14, // 0x0E > RealTimeRunData_C_Phase = 15, // 0x0F > AlarmData = 17, // 0x11 > AlarmUpdate = 18, // 0x12 > RecordData = 19, // 0x13 > InternalData = 20, // 0x14 > GetLossRate = 21, // 0x15 > //dong 2020-06-15 > GetSelfCheckState = 30, // 0x1E > InitDataState = 0xff, Hallo, hat jemand auch Payload Beschreibungen für die anderen Antworten ausser "RealTimeRunData_Debug = 11, // 0x0B" ? Hab gerade mal "17=AlarmData" am Laufen über alle WR mit Hubis Uralt Code und bekomme zur Zeit je WR bis zu 3 Payloads als Antwort (01,02,83).
Stefan T. schrieb: > Hallo dax, > ja wir beobachten das Problem der ESP8266 Variante schon seit längerem > mit Argwohn. Mein "Rekord" sind 1 Tag - 18 Std. Betriebszeit ohne Reset (Wemos D1 mini, separate 3,3V-Versorgung mit entsprechenden Kondensatoren für nRF24L01+-Modul). Aber auch immer wieder Resets nach deutlich kürzeren Zeitspannen. Es gibt bei meinem Aufbau Resets, bei denen das System einfach neu startet, aber auch "Abstürze", bei denen die Versorgungsspannung unterbrochen werden muss, um einen Neustart zu ermöglichen. Die Probleme mit der Stabilität von Aufbauten mit ESP8266-basierten Boards gibt es auch in anderen Projekten, z. B. dieser "Esp8266 Nodemcu Gaszähler Thingspeak"; spätestens nach einem Tag war ein Reset notwendig (https://fipsok.de/Projekt/gaszaehler-esp8266-nodemcu). In einem anderen Projekt zur Erfassung des Gasverbrauchs wird ausgeführt: "Mehrere erste Versuche mit nur einem Mikrocontroller vom Typ ESP8266 waren nicht erfolgreich, weil bei gleichzeitiger Benutzung der Webseite leider die Zählimpuls-Erkennung über Interrupt nicht ausreichend zuverlässig war. Die aktuelle Lösung verwendet deshalb zusätzlich zum verwendeten ESP8266 noch einen ATTINY84 Mikrocontroller für die zuverlässige Zählfunktion für insgesamt 4 Kanäle." (https://www.stall.biz/project/pulsecounter-2-komfortabel-verbraeuche-von-strom-wasser-gas-und-solar-messen). Den Teil mit dem Wemos D1 mini-Board habe ich getestet, er lief stabil. Das Projekt habe ich aber nicht weiterverfolgt, weil es Probleme mit der Impulserfassung am Gaszähler gab. Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim Kompilieren mit Visual Studio Code und der PlatformIO Extension...
Günter H. schrieb: > Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim > Kompilieren mit Visual Studio Code und der PlatformIO Extension... Hallo Günter, Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was passiert nicht?
Hallo, inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen. Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung für den TSUN dabei? Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an meiner ESP-Verkabelung. Muss man für die WR-Hardware in der SW vor dem compilieren noch was ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt. Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier der Auszug der serial-Konsole: 10:43:56.941 -> ............................... 10:44:01.668 -> I: add inverter: MI-800, SN: 11417xxxxxxxx 10:44:04.451 -> I: RF24 Amp Pwr: RF24_PA_MIN 10:44:04.451 -> I: Radio Config: 10:44:04.451 -> SPI Frequency = 1 Mhz 10:44:04.451 -> Channel = 3 (~ 2403 MHz) 10:44:04.451 -> RF Data Rate = 250 KBPS 10:44:04.451 -> RF Power Amplifier = PA_MIN 10:44:04.451 -> RF Low Noise Amplifier = Enabled 10:44:04.451 -> CRC Length = 16 bits 10:44:04.451 -> Address Length = 5 bytes 10:44:04.451 -> Static Payload Length = 32 bytes 10:44:04.451 -> Auto Retry Delay = 250 microseconds 10:44:04.483 -> Auto Retry Attempts = 0 maximum 10:44:04.483 -> Packets lost on 10:44:04.483 -> current channel = 0 10:44:04.483 -> Retry attempts made for 10:44:04.483 -> last transmission = 0 10:44:04.483 -> Multicast = Disabled 10:44:04.483 -> Custom ACK Payload = Disabled 10:44:04.483 -> Dynamic Payloads = Enabled 10:44:04.483 -> Auto Acknowledgment = Disabled 10:44:04.483 -> Primary Mode = RX 10:44:04.483 -> TX address = 0xdeadbeef01 10:44:04.483 -> pipe 0 (closed) bound = 0xdeadbeef01 10:44:04.483 -> pipe 1 ( open ) bound = 0x1234567801 10:44:04.520 -> pipe 2 (closed) bound = 0xc3 10:44:04.520 -> pipe 3 (closed) bound = 0xc4 10:44:04.520 -> pipe 4 (closed) bound = 0xc5 10:44:04.520 -> pipe 5 (closed) bound = 0xc6 10:44:04.520 -> I: 10:44:04.520 -> 10:44:04.520 -> ---------------------------------------- 10:44:04.520 -> I: Welcome to AHOY! 10:44:04.520 -> I: 10:44:04.520 -> point your browser to http://192.168.10.229 10:44:04.520 -> I: to configure your device 10:44:04.520 -> I: ---------------------------------------- 10:44:04.520 -> 10:44:10.573 -> I: [NTP]: 2022-06-30 10:44:04 Auf der Website kommt die Fehlermeldung …Receive failed… Inverter 1 not (correctly) configured Inverter 2 not (correctly) configured Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert und ob der TSUN schon unterstützt wird. Danke. Grüße Claus T.
Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung ist mir was aufgefallen und denke es ist für die neue Generation verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine Abfrage ob es sich um eine DTU3PRO handelt. Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein "DRM_Limit_Switch; //DRM power limit". Für mich ist das ein Indikator das es ein Flag im System zu setzen ist, das aussagt ob eine Limitierung nun erlaubt sei oder nicht. Dies bezüglich habe in der *.c Datei geschaut und siehe da, in der Funktion (Zeile 1717) eine "UsartNrf_Send_PackSetPowerLimitCommand": Hier zeigt sich im Speicher der DTU abgefragt wird, ob der WR sich in einem gewissen Zustand ist.
1 | if((Dtu3Detail.Property.Zero_Export_Switch == 1) || (Dtu3Detail.Property.DRM_Limit_Switch == 1) || (Dtu3Detail.Property.Phase_Balance_Switch == 1) || (Dtu3Detail.Property.SunSpec_Switch == 1)) |
2 | {
|
3 | if(MIMajor[PortNO].Property.Acq_Switch == 0) |
4 | { ...
|
Ist dieser 0, dann wird folgender Befehl abgeschickt:
1 | //1000w shutdown Micro-inverse control of 1-to-4 with the last 8 digits of the special control ID less than 0x50000000 |
2 | if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61))) |
3 | {
|
4 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
5 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
6 | temp_dat[11] = 11; |
7 | // temp = 35*4*10=1400=0x0578; |
8 | temp_dat[12] = 0X05; |
9 | temp_dat[13] = 0X78; |
10 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
11 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
12 | } |
13 | else |
14 | {
|
15 | temp_dat[9] = (u8)(CONTROL_OFF_SUB >> 8); //5a5a |
16 | temp_dat[10] = (u8)(CONTROL_OFF_SUB & 0XFF); |
17 | temp_dat[11] = Get_crc_xor((u8 *)&temp_dat[0], 11); //CRC |
18 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 12); //forward substitution |
19 | } |
Wenn nicht dann:
1 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
2 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
3 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
4 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
5 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
6 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
7 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
Interessant ist, wenn alles nicht zutrifft wird folgendes verschickt:
1 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
2 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
3 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
4 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
5 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
6 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
7 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
Ich werde mal das ganze weiter anschauen und probieren. EDIT: 5A 5A FF <[Property.Power_Limit * 10 / (300 * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))]> [H 8-bit P limit] [LP limit 8 bits] CRC
:
Bearbeitet durch User
Stefan T. schrieb: > Das könnte auch eine Ursache sein, probier das doch mal aus bzw. > überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten > Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und > Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default > Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte: > https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584 Vielen herzlichen Dank! Darin befindet sich die Lösung. Jetzt funktioniert. Musste CE und IRQ vertauschen. (also nicht nach dem Schaltbild, das auf GitHub ist!) Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem darstellen. Jetzt kämpfe ich nur noch mit Wlan Problemen. Bei mehr als 3-4 Meter Entfernung von Wlan Router, bricht die Verbindung in unregelmäßigen Abständen ab (meist aber schon nach 4-5 Sekunden). Habe schon verschiedene Netzteile und Kabel getestet und mit Kondensatoren experimentiert. Werde jedenfalls noch weiter testen.
Thomas B. schrieb: > Hallo Günter, > Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was > passiert nicht? Danke für die Rückmeldung. Vorweg: Ich bin "kein Programmierer". Bekomme die Arduino IDE (gerade so) zum Laufen. PC mit Windows 10 Pro 21H2 Installation von Visual Studio Code und der PlatformIO Extension innerhalb Visual Studio Code problemlos, Source Code als zip-Datei heruntergeladen, entpackt und platformio.ini geöffnet, upload_port und monitor_port angepasst. Dann "PlatformIO: Upload" angeklickt - danach kamen die Fehlermeldungen, s. Anhänge. Die Zahlen sollen die zeitliche Reihenfolge widerspiegeln. Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0 für Windows" heruntergeladen und installiert. Weiter als zur Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen. Gruß Günter
Günter H. schrieb: > Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0 > für Windows" heruntergeladen und installiert. Weiter als zur > Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen. Hallo Günter, du bist dann in das gleiche Problem gelaufen wie hier: https://github.com/tbnobody/OpenDTU/issues/3 Ich werde heute Abend noch eine Ausnahme implementieren, damit man den Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP heruntergeladen hat.
Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord umzuleiten? Da hier auch über andere Themen gesprochen werden die für das Projekt relevant sind, würde ich vorschlagen statt ein seperaten Thread aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier bleiben? Nur eine Idee. :)
Claus T. schrieb: > Hallo, > inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich > mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN > konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen. > Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die > HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung > für den TSUN dabei? > Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an > meiner ESP-Verkabelung. > Muss man für die WR-Hardware in der SW vor dem compilieren noch was > ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt. > Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier > der Auszug der serial-Konsole: > Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert > und ob der TSUN schon unterstützt wird. > Danke. > Grüße > Claus T. Hallo Claus, ich bin der mit dem TSOL-M800 (MI-700 Klon). Es gibt noch MI-1500 und 1200, die etwas andere Abfragen starten. Meine Version ist nicht annähernd lauffähig, teilweise instabil und eher unkomminikativ, allerdings ist deine Verkabelung ect. soweit ok. Die älteren MI werden noch nicht unterstützt, ist allerdings in der Mache. Bitte hab etwas Geduld. Ich schaue mal, dass ich meine Version zu github hochlade, wenn sie etwas besser läuft. Aktuell modifiziere ich noch dran. Ggf. kann Daniel R. oder Ziyat eine Testversion für den MI auf dem D1 Mini bereitstellen, die besser anzupassen ist. Wie gesagt, etwas Geduld :)
Daniel R. schrieb: > Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord > umzuleiten? > > Da hier auch über andere Themen gesprochen werden die für das Projekt > relevant sind, würde ich vorschlagen statt ein seperaten Thread > aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier > bleiben? > > Nur eine Idee. :) Moin, wenn du einen Einladungslink zu einem Server hast, komme ich gerne dazu :) lg
Discord Link habe ich via PM raus geschickt. :)
Hallo Daniel, danke für die Info, schön zu hören, dass meine HW funktioniert, dann bleibe ich weiter geduldig :-) Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner nicht mit 1041… begonnen? Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben anschmeißen. Grüße Claus T.
Claus T. schrieb: > Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner > nicht mit 1041… begonnen? Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders belegt?
Josef J. schrieb: > Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem > darstellen. > Doch, weil deine DTU-Pro dauernd den WR abfragt, sendet der WR antworten zu DTU-Pro. Wenn du in deinem esp-ahoy die gleiche Adresse hast wie die DTU-Pro, wirst du nie wissen ob das esp-ahoy den WR abfragt, bzw. das Senden erfolgreich ist. Du bekommst die WR Antworten zu DTU-Pro gratis mit.
Habe im usart-code was interessantes gefunden.
Kann jemand entschlüsseln was das seien könnte?
//u8 Uart_SendBuffer1[] = {0x7e, 0x15, 0x50, 0x80, 0x55, 0x56, 0x50,
0x80, 0x55, 0x56, 0x80, 0x02, 0x00, 0x5E, 0x04, 0x7D, 0x5E, 0x2A, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5B, 0x10, 0xD2, 0x7f};
//u8 Uart_SendBuffer1[] =
{0x7e,0x15,0x50,0x80,0x55,0x55,0x50,0x80,0x55,0x55,0x80,0x12,0x00,0x00,0
x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x13,0xb9,0x2d,0x7
f};
Daniel R. schrieb: > Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung > ist mir was aufgefallen und denke es ist für die neue Generation > verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine > Abfrage ob es sich um eine DTU3PRO handelt. > Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein > "DRM_Limit_Switch; //DRM power limit". > Eigenlich alles steht im RF_communication_protocol-V6.5.xlsx. Es gibt folg Limitierungen in der Praxis: - zero export: prozentual oder absolut Wert der Nenneistung, gesteuert in Verbindung mit einem Modbus Smart-Meter - Fest limiterte WR: prozentual oder absolut Wert der Nenneistung, eingegeben im smiles-cloud -DRM(Demand Response Mode): der WR wird vom Gridanbieter kontrolliert off/0%/50%/no limit.z.B in Australien, in der EU weiss nicht. Es wird über die DTU-Pro, mit RS485(Modbus oder Sunspec) oder mit einem DRM-Port direkt kommuniziert.
Thomas B. schrieb: > Claus T. schrieb: >> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner >> nicht mit 1041… begonnen? > > Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe > sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders > belegt? Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 los und monitore das schon eine ganze Weile.
Claus T. schrieb: > Hallo Daniel, > danke für die Info, schön zu hören, dass meine HW funktioniert, dann > bleibe ich weiter geduldig :-) > Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner > nicht mit 1041… begonnen? > Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi > hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben > anschmeißen. > Grüße > Claus T. Sehr interessant. Meiner hat mit 1041 begonnen, ja. Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen einzutragen. Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es bringt was raus. Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das geht. Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren. https://github.com/tbnobody/OpenDTU Allerdings ist es auch bisher nur für die HM-Serie. lg
Richard K. schrieb: > Thomas B. schrieb: >> Claus T. schrieb: >>> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner >>> nicht mit 1041… begonnen? >> >> Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe >> sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders >> belegt? > > Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 > los und monitore das schon eine ganze Weile. Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein umgelabelter HM-Serie? Ich trau den Chinesen alles zu ;)
Thomas B. schrieb: > Hallo Günter, > > du bist dann in das gleiche Problem gelaufen wie hier: > https://github.com/tbnobody/OpenDTU/issues/3 > > Ich werde heute Abend noch eine Ausnahme implementieren, damit man den > Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP > heruntergeladen hat. Hallo Thomas, nach deinem Hinweis konnte ich den git clone herunterladen - frage bitte nicht, wie das letztlich gelungen ist. Wie auch immer: Das System arbeitet perfekt (HM600), über die Stabilität kann ich naturgemäß noch keine Angaben machen.
Hallo Daniel, Daniel M. schrieb: > Sehr interessant. Meiner hat mit 1041 begonnen, ja. > Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen > einzutragen. Ich habe am meinem TSOL-M800 an jedem der beiden MPPT-Eingängen ein 370Wp Modul angeschlossen, also beide Inverter laufen. So habe ich sie auch in der ahoy-SW eingetragen, bei Inverter Inverter 0 AddressNameMax Module Power (Wp) 440 440 Module Name CS3L-370 CS3L-370 Inverter 1 Alles weitere leer. Und jetzt noch getestet, die beiden rechten Felder gelöscht. AddressNameMax Module Power (Wp) 440 0 Module Name CS3L-370 Bringt aber auch nix, wobei die Rechte Module Power wird automatisch 0. > > Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es > bringt was raus. > > Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das > geht. Gut, dann kann ich die testen. > > Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren. > https://github.com/tbnobody/OpenDTU > Allerdings ist es auch bisher nur für die HM-Serie. Und dafür muss ich VisualStudio mit PlatformIO installieren, was ich schon mal für ein anderes Projekt probiert hatte und gescheitert bin. Ist aber ein Grund für einen neuen Versuch :-) Die Art des WR wird bei ahoy über die Seriennummer erkannt?
Claus T. schrieb: > Ist aber ein Grund für einen neuen Versuch :-) Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS Code installieren und die PlatformIO Extension zu laden) Claus T. schrieb: > Die Art des WR wird bei ahoy über die Seriennummer erkannt? Genau. Wie in allen anderen Implementierungen aktuell auch. Die Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht eindeutig (siehe https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx)
Holger S. schrieb: > Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x > Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch > rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den > China Wemos Clones liegt. > > Leider bekomme ich damit auch keine mehrstündigen Uptimes hin. > Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber > irgendwie muß man das doch sauber zum laufen bekommen. > > Läuft das bei euch über Tage ohne Reboot ??? Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert auch keine Daten mehr. Hilft nur noch ein reboot...
Hans W. schrieb: > Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger > als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert > auch keine Daten mehr. Hilft nur noch ein reboot... Betreibe einen NodeMCU mit rf-Modul ohne Cap mit ahoy an meinem HM-800 seit mittlerweile > 3 Wochen ohne Reboot. Großartige Arbeit übrigens @ Dev's!
Daniel M. schrieb: >> Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 >> los und monitore das schon eine ganze Weile. > > Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein > umgelabelter HM-Serie? > Ich trau den Chinesen alles zu ;) Ja da steht wirklich TSUN TSOL-M800 drauf, und die 1141 passt auch zu dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau 612W scheinbar begrenzt. Hab die Version 0.4.19 am laufen. Für alle die reboots haben, stellt mal das Intervall von 5 sekunden einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5 Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es damit zusammen.
:
Bearbeitet durch User
> Ja da steht wirklich TSUN TSOL-M800 drauf, und die 1141 passt auch zu > dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau > 612W scheinbar begrenzt. > Hab die Version 0.4.19 am laufen. Laut Datenblatt hat es eine Spitzenwirkungsgrad des Wechselrichters von etwa 96,7%. Ich glaub meine Rechnung ist falsch aber wenn ich das ganze Überschlage, sollte etwa folgendes raus kommen: 370W*2= 740W (740W/100) * 96,7 = 715,58WAC ? Für mich heißt es das lt. Rechnung 84,42W fehlen und nach deinen Angaben sogar 188W fehlen. Wenn wir noch bei beiden ca. 20-50W mal für Toleranz abziehen (pi*Daume) dann fehlen bei dir trotzdem gute 130W. Hmm, eventuell wurde hier falsche Firmware oder wie du gesagt hast schon vorab begrenzt. - Keine Ahnung... :/ > Für alle die reboots haben, stellt mal das Intervall von 5 sekunden > einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5 > Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es > damit zusammen. Das sollte man eventuell mal sich merken/Anpinnen. Glaube das hatte bisher keiner im Verdacht? :)
Angehängte Dateien:
-
tsol-m800.png
61 KB -
tsol-m800_1.png
72 KB
Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft worden. Und das tut der auch brav. Ich habe das beim Aufzeichnen auch so festgestellt. Ob dieser das jetzt auf Einspeiseleistung macht oder auf Panelleistung kann man so nicht sagen, denn ich sehe eine harte Begrenzung bei beidem. Im Anhang sieht man das an dem aufgezeichneten Tag immer wieder mal die Sonne weg war wegen einzelnen Wolken, dann ist ja das Panel kühler und wenn die volle Bestrahlung kommt dann liefern die Panels auch mehr Leistung. Und da sieht man ganz deutlich das die Leistung gedeckelt ist. Und ich würde behaupten das diese Serie evtl. auch in der Begrenzung regelbar ist, oder es ist in der Firmware schon so begrenzt.
Hallo zusammen Über die Suche im WWW bin ich auf diesen Thread gestossen. Ich bin überrascht wieviele Leute es doch gibt, die sich gegen ein "Fremdüberwachungscloud" gibt und wieviel Aufwand und Arbeit da reingesteckt wird. Vielen Dank dafür. Seit kurzem läuft bei mir auch ein HM-600 mit einem Stick DTU, den ich aber nur leihweise habe. Wenn ich das ganze hier richtig verstanden habe, gibt es hier 3 Varianten? Welche Variante ist die mir der ich am sichersten die Daten in den Iobroker bringe? Ich bin kein Softwaremensch, ein ESP oder Arduino flashen geht, aber sobald es um komplexe Software geht weiss ich nicht mehr weiter. Darum die Frage. Gruss Andi
Richard K. schrieb: > Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft > worden. An sich kann man die alle regeln, da schon festgestellt wurde das TSUN eine kopie von Hoymiles ist. :) Da an sich Zero-Export funktion auch noch möglich ist müssen die sich regeln lassen können. Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter hoch treiben. ;) @Andi: An sich kommt alles drauf an. Wenn du bereits ein Raspi hast und der 24/7 läuft würde ich denn nutzen. Wenn du aber ein ESP8266/32 in der Schublade hast, kann man denn auch gut nutzen. Bei allen jedoch ist ein NRF24L01+ nötig. Sollte aber alles auf Github stehen: https://github.com/grindylow/ahoy/ PS: Du kannst bei allen via MQTT auf iobroker dann legen. ;)
:
Bearbeitet durch User
Hallo Daniel Danke für die Hinweise. Mein Problem besteht darin, dass mein Englisch sehr schlecht ist und sich leider nicht immer alles sinnvoll übersetzen lässt. Als Controller liegt alles bei mir rum, Rpi, ESP8266 und ESP32 als Wemos D1 mini. Dann organisiere ich mir mal den NRF... und beginne mal zu testen. Die ESP Varianten sind mir sympatisch, den die brauchen dann keine Software Support mehr wenn es mal läuft. Rpi ist da halt etwas aufwändiger. Mein Iobroker läuft als Multihost auch auf Rpi CPU. Aber eben im Keller und dort geht die DTU eben nicht. Gruss Andi
Ist zwar Off-Topic, aber du könntest ja dann einfach ein ESP nehmen und das irgendwo in der Mitte zwischen WR und deinem Router einspannen. ;)
Wie meinst du "einspannen"? Als ich denke mir das ich einen ESP nehme und denn einfach an Stelle der DTU verwenden kann?
Einspannen, dazwischen schalten, in dein Netzwerk joinen lassen... :D Richtig, der ESP emuliert einfach die DTU.
Zuerst einmal: Vielen Dank für eure Arbeit! Ich habe mir auch vom Makershop einen NRF24L01+ PA und einen Wemos D1 Mini geholt, geflashed und angeschlossen. Aber er empfängt leider keine Daten vom WR. Ich habe das PinOut zweimal geprüft - auch IRQ/CE. Muss ich den WR selber noch überreden, dass er sendet? Habe ich etwas vergessen in der Firmware zu aktivieren (Muss dort Channel Hopping an oder aus sein?) Gibt es irgendwo eine Anleitung zum systematischen Debugging, z.B. ob das NF24-Modul überhaupt antwortet bzw. betriebsbereit ist? EDIT: HAT sich erledigt. Ich habe keine Ahnung, was sich geändert hat, aber nach dem aktivieren des Loggings, dem richtigen Raten der Baudrate (115200) und dem connecten mit screen läuft es nun.
:
Bearbeitet durch User
Hallo zusammen, ich habe meinen WemosD1Mini nun schon eine ganze Weile mit meinem HM700 am laufen. Soweit funktioniert das auch, jedoch hatte ich jetzt versucht ihn per mqtt mit iobroker zu verbinden aber irgendwie kann er sich nicht mit dem mqtt Server verbinden. Die Anmeldedaten sind jedoch definitiv korrekt aber eine Verbindung schlägt fehlt. Jetzt wollte ich ein OTA Update (aktuelle Version 0.3.3) durchführen und frage mich aber wo ich die dafür benötigten Files finde. Unter https://github.com/grindylow/ahoy konnte ich irgendwie nichts finden. Wäre super wenn ihr mir weiterhelfen könntet, vielleicht sehe ich ja den Wald vor lauter Bäumen nicht. EDIT: Hat sich erledigt. Hab eben gesehen, dass die BIN Files hier im Thread zur Verfügung gestellt werden.
:
Bearbeitet durch User
Daniel R. schrieb: > Richard K. schrieb: >> Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft >> worden. > > Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter > hoch treiben. ;) Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. Bin gespannt ob es geht.
Hallo Thomas, Thomas B. schrieb: > Claus T. schrieb: >> Ist aber ein Grund für einen neuen Versuch :-) Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal mit Erfolg. > Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur > ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS > Code installieren und die PlatformIO Extension zu laden) Ich hab’s auf meinem MacBookAir installiert, deine Anleitung hat aber trotzdem sehr gut geholfen. Musste noch Python 3.10 und git installieren. Als serielle Schnittstelle muss man am Mac statt COM4 /dev/cu.usbserial-1410 eingeben. Wobei das vom ESP32-USB-Chip abhängig ist. > > Claus T. schrieb: >> Die Art des WR wird bei ahoy über die Seriennummer erkannt? > Genau. Wie in allen anderen Implementierungen aktuell auch. Die > Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht > eindeutig (siehe > https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx) Nachdem ich unter Settings das Netzwerk und die Seriennummer meines Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32 etwas bewegt hatte, kam auch ein „success“. Super! :-) Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der Empfang nicht ganz durch die Hauswand. Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut. Der Wechselrichter wird als HM-600, HM-700, HM-800 erkannt, was anhand der Seriennummer 11417… zu erwarten war, und empfängt sauber alle Daten. Mein TSUN TSOL-M800 ist also kein MI-xxx, sondern ein HM-6/7/800. Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des Hauses keine Daten. Dank an alle, die das Projekt schon so weit gebracht haben. lg Claus T.
Oliver F. schrieb: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" ... > Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die > erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren > bin. Hallo Oliver, was ist aus dem ESP32 mit 6 x nRF Modulen denn geworden ? Gibt es da Neuigkeiten ? Viele Grüße Herbert
:
Bearbeitet durch User
Bei mir funktioniert alles wie es soll, auch MQTT. Nur habe ich zwischendurch immer 0 Werte bei allen Werten. Kann man das irgendwie unterbinden?
Also ich habe jetzt die Version 4.19 geflashed aber leider kann er weiterhin keine Verbindung zu mqtt herstellen. Gibt es Broker seitig etwas zu beachten? Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im Format 192.168.42.101 angegeben. Muss beim Topic etwas beachtet werden?
Hallo Silvio, an sich nichts großes. Probiere mal via MQTTExplorer (https://github.com/thomasnordquist/MQTT-Explorer) zu lauschen ob die Daten auch empfangen werden. In den Einstellung bei deinem DTU muss unter MQTT auch passend die Werte eingepflegt werden. Denke mal das hast du auch gemacht.
Ziyat T. schrieb: >> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter >> hoch treiben. ;) > > Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit > einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. > Bin gespannt ob es geht. Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die Settings im WR anpassen kann. Soweit ich die Installationsanleitungen verstehe, gibt es da Optionen. In dem Gitee waren auch Hinweise auf dieses "Gridfile", vorwiegend aber für die MI-Serie. Habe heute meinen HM-1500 bekommen und bin gespannt, ob die EU-Version (nicht explizit DE) das Limit auf 600W drin hat. Ahoy-Software hat nach Pintausch auf einem Wemos kurzzeitig funktioniert, ich vermute, hier hats einfach durch die Bastelumgebung zuviel Störzeug, was überlagert. Die Version auf dem ESP32 hatte da (wahrscheinlich wegen der Störfelder) noch nicht geklappt, ich werde aber damit auch testen.
Claus T. schrieb: > Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal > mit Erfolg. Glückwunsch! :) > Nachdem ich unter Settings das Netzwerk und die Seriennummer meines > Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann > auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei > VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32 > etwas bewegt hatte, kam auch ein „success“. Super! :-) > > Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der > Empfang nicht ganz durch die Hauswand. > Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut. Also die Nachfolgerversion meines "alten" MI-Klon. Wenn du Daten bekommst, ist das super. > Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des > Hauses keine Daten. Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ auf D4. Alternativ kannst du auch D8, D2, D1 probieren.
Silvio R. schrieb: > Also ich habe jetzt die Version 4.19 geflashed aber leider kann er > weiterhin keine Verbindung zu mqtt herstellen. > Gibt es Broker seitig etwas zu beachten? > Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im > Format 192.168.42.101 angegeben. > Muss beim Topic etwas beachtet werden? Für die neuere MQTT Version >2.x brauchst du zwingend Username/Passwort, außer du konfigurierst den Server entsprechend um. Sonst ist der Tip mit MQTT.fx oder MQTT Explorer ganz gut zum Schauen. Normal sollte nichts weiter beachtet werden.
Werden die Werte für AC Power eigentlich aufgrund der Werte von DC Power errechnet, oder werden diese vom Wechselrichter direkt übertragen?
bei der HM Serie wird AC Power und die einzelnen DC Power der Eingänge übertragen. Die ESP Version errechnet die Gesamt DC Power und daraus wieder den Wirkungsgrad. Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC Powermessung sehr genau stimmt. Mal eine Frage in die Runde: Wie heiß werden eigentlich eure Wechselrichter? Gibt es eine Overtemperature Abschaltung? Ich habe bei mir schon 73°C gesehen. Das passt auch zu meiner Vorstellung, dass bei ca. 1.1kW und 95.5% Wirkungsgrad ca. 50W in Wärme umgewandelt werden. Man muss dazu sagen, das ich auf zwei Eingängen Parallelschaltungen und damit verbunden hohe Ströme habe.
Lukas P. schrieb: > Mal eine Frage in die Runde: Wie heiß werden eigentlich eure > Wechselrichter? Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500)
Lukas P. schrieb: > bei der HM Serie wird AC Power und die einzelnen DC Power der > Eingänge übertragen. > Die ESP Version errechnet die Gesamt DC Power und daraus wieder den > Wirkungsgrad. > Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC > Powermessung sehr genau stimmt. Vielen Dank. Momentan lese ich noch die Daten via Modbus TCP von der DTU Pro aus. Ich denke, dass dies aber die DC Power sein wird (Laut Doku PV Power). Das muss ich mal vergleichen. Zu den Temperaturen kann ich noch nichts sagen, da ich den WR erst seit einer Woche habe.
Thomas B. schrieb: > Lukas P. schrieb: >> Mal eine Frage in die Runde: Wie heiß werden eigentlich eure >> Wechselrichter? > > Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500) Aussen 38.5C, WR 64.9C
Daniel M. schrieb: > Ziyat T. schrieb: >>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter >>> hoch treiben. ;) >> >> Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit >> einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. >> Bin gespannt ob es geht. > > Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden > können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die > Settings im WR anpassen kann. Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Daniel, Daniel M. schrieb: >> Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des >> Hauses keine Daten. > > Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ > auf D4. Alternativ kannst du auch D8, D2, D1 probieren. hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3) vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png + AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den ich auch verwende. Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal kontrolliert bzw. angepasst... und es läuft :-) Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet, hat nix geholfen. Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert. Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2) eingestellt. Grüße Claus
Interrupt und ReceiveChannel Hallo, Ich habe von meinem MI-1500 immer wieder keine Daten mehr bekommen, habe den Grund untersucht. - Unbedingt nicht nur auf CH03 hören, mein MI-1500 sendet z.B. heute nichts über CH03. Er sendet heute nur über CH61 und CH75 !! - Wenn ich ohne Interrupt den NRF24 polle, sehe ich mehr Daten So bekomme schön und regelmaessig Daten vom MI-1500
:
Bearbeitet durch User
Ich habe bei meinem HM-1500 schon 79°C gesehen. Das kommt mir auch etwas viel vor. Ist aber unter den Panels auf einem Flachdach.
Ich habe eine HM-1500. Max Temperatur war knapp über 60°C. Hab jetzt ein kleinen 12V Lüfter davor gestellt mit kleinem Solar Panel. Seit dem bin ich bei Max 45°C. Gruß Tom
Hallo Claus, Claus T. schrieb: > hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3) > vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png + > AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den > ich auch verwende. Ich muss nochmal drüber schauen, ich habe auch den Typ im Einsatz. > Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal > kontrolliert bzw. angepasst... und es läuft :-) Wenns läuft, ist top :) Glückwunsch! > Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet, > hat nix geholfen. > Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert. > Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2) > eingestellt. Ich hab das auch noch nicht ganz verstanden, warum das nicht klappt. Ich nutze 2 identische D1 mini, identisch verkabelt und eingerichtet, selbe Position und das NRF Modul genauso ausgerichtet, der eine läuft, der andere nicht.
Ziyat T. schrieb: > Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe: > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hallo Ziyat, ich bin nicht sicher, ob für die HM-Serie ggf. weitere Parameter vorgesehen sind. Als die MI-Serie aktuell war, gab es keine Limits in der Form (soweit mir bekannt). Mein HM-1500 (EU-Version) kennt kein 600W Limit. Ahoy auf D1 Mini und Thomas seine Version auf ESP32 laufen perfekt. Mit dem MI-Klon bin ich noch nicht weiter, heute erstmal die 4 Panele mit dem HM aufgestellt. lg Daniel
Wegen getauschten Verbindungen des ESP8266 Code von Lukas P., das hat er ab Versiom 0.4.20 geändert: https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584 Jetzt gilt als Default: CS = D8(GPIO15) CE = D3(GPIO0) IRQ = D4(GPIO2) Ich muss noch die Fritzing Schematics & die Beschreibung dementsprechend anpassen. Verstehen tue ich’s auch (noch) nicht. Bei mir hat die 30 s Intervallzeit mE viel mehr Erfolg als irgendeine geänderte Belegung. Aber wenn‘s Euch hilft =^D Wir sollten evtl überlegen ob wir den von Ziyat T. vorgeschlagenen Weg: kein IRQ und auf allen Kanälen empfangen und/oder senden auch umsetzen ? Zumindest die Raspberry Pi Variante von Jan-Jonas S. kommt schließlich auch ohne IRQ aus. Vielleicht ist ein gutes Timing wie im uart_nrf.c/.h code des Herstellers besser als ein Interrupthandler der ständig dazwischenkommt/-„funkt“.
HAllo habe teiweise resets ohne ersichtlichem Grund. Kann jemand aus dem Log etwas lesen warum? equesting Inverter SN 114180113742 Transmit 27 | 15 80 11 37 42 78 56 34 12 80 0B 00 62 C1 61 21 00 00 00 05 00 00 00 00 58 2A E6 Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 2E Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 2E Received 27 bytes channel 23: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 2E Received 23 bytes channel 3: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 03 E8 00 FA 00 D2 3E 2D CE Received 23 bytes channel 3: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 03 E8 00 FA 00 D2 3E 2D CE Received 23 bytes channel 23: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 03 E8 00 FA 00 D2 3E 2D CE Error while retrieving data: Frame 2 missing: Request Retransmit Transmit 11 | 15 80 11 37 42 78 56 34 12 82 7B Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 44 Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 44 Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 44 Payload (42): 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 00 00 00 08 03 E8 00 FA 00 D2 --------------- CUT HERE FOR EXCEPTION DECODER --------------- Exception (3): epc1=0x401007a5 epc2=0x00000000 epc3=0x00000000 excvaddr=0x40031dd9 depc=0x00000000 >>>stack>>> ctx: sys sp: 3fffec20 end: 3fffffb0 offset: 0190 3fffedb0: 00000319 00000319 3ffe85dc 401009d3 3fffedc0: 00000319 00000319 3ffe85dc 401009d3 3fffedd0: 3fff1d1c 00000020 3fff1d1c 3fff1d1c 3fffede0: 00000000 00000020 3fff1d1c 40100bb2 3fffedf0: 40104533 00000000 00000000 40100534 3fffee00: 0000011c 00000020 3fff3b3c 402253f8 3fffee10: 401033fc 3fff1d1c 3fff1d1c 4021d339 3fffee20: 000007d3 000007d3 3ffe85dc 4021de40 3fffee30: 00000000 2c9f0300 4000050c 4021e4c7 3fffee40: 3fff1d1c 00000020 3fff42ec 40100bb2 3fffee50: 0055f4e5 cc21a274 00000000 40100534 3fffee60: 3fff1d1c 3fff0400 00000006 3fff03fc 3fffee70: 3fff1d1c 3fff0400 00000005 4021e530 3fffee80: 3fff1d1c 3fff0400 00000005 40226f47 3fffee90: 00000000 00000000 4bc6a7f0 402253d1 3fffeea0: 00000019 00000000 401002dd 00000000 3fffeeb0: 3fff0000 00000152 00000020 3ffeffb0 3fffeec0: 3fff0230 3fff430a 3fff42ec 402246e9 3fffeed0: 00000014 3ffeffb0 3ffe85dc 401009d3 3fffeee0: 00000000 3fff058c 3ffeda50 3fff1c8c 3fffeef0: 3fffdc80 00000020 3fff35e4 3fff1c8c 3fffef00: 3ffeffb0 00000008 3fff42ec 4021d209 3fffef10: 3fffdc80 3fff0834 3fff35e4 4021d008 3fffef20: 4024558d 3fff0834 3fff35e4 4024559f 3fffef30: 3fff42fc 3fff42ec 00000000 3ffe85d8 3fffef40: 40241ffb 00000000 3fff35e4 40246873 3fffef50: 40000f49 3fffdab0 3fffdab0 40000f49 3fffef60: 40000e19 000593d1 00000000 00000005 3fffef70: 60000600 aa55aa55 000000f7 40105539 3fffef80: 4010553f 00000000 00000005 40100b8c 3fffef90: 4010000d 56bde7c1 000593d1 401000ac 3fffefa0: 00000000 3fffef3c 00000000 3ffffe58 3fffefb0: 3fffffc0 00000000 00000000 feefeffe 3fffefc0: feefeffe feefeffe feefeffe feefeffe 3fffefd0: feefeffe feefeffe feefeffe feefeffe 3fffefe0: feefeffe feefeffe feefeffe feefeffe 3fffeff0: feefeffe feefeffe feefeffe feefeffe 3ffff000: feefeffe feefeffe feefeffe feefeffe 3ffff010: feefeffe feefeffe feefeffe feefeffe 3ffff020: feefeffe feefeffe feefeffe feefeffe 3ffff030: feefeffe feefeffe feefeffe feefeffe 3ffff040: feefeffe feefeffe feefeffe feefeffe 3ffff050: feefeffe feefeffe feefeffe feefeffe 3ffff060: feefeffe feefeffe feefeffe feefeffe 3ffff070: feefeffe feefeffe feefeffe feefeffe 3ffff080: feefeffe feefeffe feefeffe feefeffe 3ffff090: feefeffe feefeffe feefeffe feefeffe 3ffff0a0: feefeffe feefeffe feefeffe feefeffe 3ffff0b0: feefeffe feefeffe feefeffe feefeffe 3ffff0c0: feefeffe feefeffe feefeffe feefeffe 3ffff0d0: feefeffe feefeffe feefeffe feefeffe 3ffff0e0: feefeffe feefeffe feefeffe feefeffe 3ffff0f0: feefeffe feefeffe feefeffe feefeffe 3ffff100: feefeffe feefeffe feefeffe feefeffe 3ffff110: feefeffe feefeffe feefeffe feefeffe 3ffff120: feefeffe feefeffe feefeffe feefeffe 3ffff130: feefeffe feefeffe feefeffe feefeffe 3ffff140: feefeffe feefeffe feefeffe feefeffe 3ffff150: feefeffe feefeffe feefeffe feefeffe 3ffff160: feefeffe feefeffe feefeffe feefeffe 3ffff170: feefeffe feefeffe feefeffe feefeffe 3ffff180: feefeffe feefeffe feefeffe feefeffe 3ffff190: feefeffe feefeffe feefeffe feefeffe 3ffff1a0: feefeffe feefeffe feefeffe feefeffe 3ffff1b0: feefeffe feefeffe feefeffe feefeffe 3ffff1c0: feefeffe feefeffe feefeffe feefeffe 3ffff1d0: feefeffe feefeffe feefeffe feefeffe 3ffff1e0: feefeffe feefeffe feefeffe feefeffe 3ffff1f0: feefeffe feefeffe feefeffe feefeffe 3ffff200: feefeffe feefeffe feefeffe feefeffe 3ffff210: feefeffe feefeffe feefeffe feefeffe 3ffff220: feefeffe feefeffe feefeffe feefeffe 3ffff230: feefeffe feefeffe feefeffe feefeffe 3ffff240: feefeffe feefeffe feefeffe feefeffe 3ffff250: feefeffe feefeffe feefeffe feefeffe 3ffff260: feefeffe feefeffe feefeffe feefeffe 3ffff270: feefeffe feefeffe feefeffe feefeffe 3ffff280: feefeffe feefeffe feefeffe feefeffe 3ffff290: feefeffe feefeffe feefeffe feefeffe 3ffff2a0: feefeffe feefeffe feefeffe feefeffe 3ffff2b0: feefeffe feefeffe feefeffe feefeffe 3ffff2c0: feefeffe feefeffe feefeffe feefeffe 3ffff2d0: feefeffe feefeffe feefeffe feefeffe 3ffff2e0: feefeffe feefeffe feefeffe feefeffe 3ffff2f0: feefeffe feefeffe feefeffe feefeffe 3ffff300: feefeffe feefeffe feefeffe feefeffe 3ffff310: feefeffe feefeffe feefeffe feefeffe 3ffff320: feefeffe feefeffe feefeffe feefeffe 3ffff330: feefeffe feefeffe feefeffe feefeffe 3ffff340: feefeffe feefeffe feefeffe feefeffe 3ffff350: feefeffe feefeffe feefeffe feefeffe 3ffff360: feefeffe feefeffe feefeffe feefeffe 3ffff370: feefeffe feefeffe feefeffe feefeffe 3ffff380: feefeffe feefeffe feefeffe feefeffe 3ffff390: feefeffe feefeffe feefeffe feefeffe 3ffff3a0: feefeffe feefeffe feefeffe feefeffe 3ffff3b0: feefeffe feefeffe feefeffe feefeffe 3ffff3c0: feefeffe feefeffe feefeffe feefeffe 3ffff3d0: feefeffe feefeffe feefeffe feefeffe 3ffff3e0: feefeffe feefeffe feefeffe feefeffe 3ffff3f0: feefeffe feefeffe feefeffe feefeffe 3ffff400: feefeffe feefeffe feefeffe feefeffe 3ffff410: feefeffe feefeffe feefeffe feefeffe 3ffff420: feefeffe feefeffe feefeffe feefeffe 3ffff430: feefeffe feefeffe feefeffe feefeffe 3ffff440: feefeffe feefeffe feefeffe feefeffe 3ffff450: feefeffe feefeffe feefeffe feefeffe 3ffff460: feefeffe feefeffe feefeffe feefeffe 3ffff470: feefeffe feefeffe feefeffe feefeffe 3ffff480: feefeffe feefeffe feefeffe feefeffe 3ffff490: feefeffe feefeffe feefeffe feefeffe 3ffff4a0: feefeffe feefeffe feefeffe feefeffe 3ffff4b0: feefeffe feefeffe feefeffe feefeffe 3ffff4c0: feefeffe feefeffe feefeffe feefeffe 3ffff4d0: feefeffe feefeffe feefeffe feefeffe 3ffff4e0: feefeffe feefeffe feefeffe feefeffe 3ffff4f0: feefeffe feefeffe feefeffe feefeffe 3ffff500: feefeffe feefeffe feefeffe feefeffe 3ffff510: feefeffe feefeffe feefeffe feefeffe 3ffff520: feefeffe feefeffe feefeffe feefeffe 3ffff530: feefeffe feefeffe feefeffe feefeffe 3ffff540: feefeffe feefeffe feefeffe feefeffe 3ffff550: feefeffe feefeffe feefeffe feefeffe 3ffff560: feefeffe feefeffe feefeffe feefeffe 3ffff570: feefeffe feefeffe feefeffe feefeffe 3ffff580: feefeffe feefeffe feefeffe feefeffe 3ffff590: feefeffe feefeffe feefeffe feefeffe 3ffff5a0: feefeffe feefeffe feefeffe feefeffe 3ffff5b0: feefeffe feefeffe feefeffe feefeffe 3ffff5c0: feefeffe feefeffe feefeffe feefeffe 3ffff5d0: feefeffe feefeffe feefeffe feefeffe 3ffff5e0: feefeffe feefeffe feefeffe feefeffe 3ffff5f0: feefeffe feefeffe feefeffe feefeffe 3ffff600: feefeffe feefeffe feefeffe feefeffe 3ffff610: feefeffe feefeffe feefeffe feefeffe 3ffff620: feefeffe feefeffe feefeffe feefeffe 3ffff630: feefeffe feefeffe feefeffe feefeffe 3ffff640: feefeffe feefeffe feefeffe feefeffe 3ffff650: feefeffe feefeffe feefeffe feefeffe 3ffff660: feefeffe feefeffe feefeffe feefeffe 3ffff670: feefeffe feefeffe feefeffe feefeffe 3ffff680: feefeffe feefeffe feefeffe feefeffe 3ffff690: feefeffe feefeffe feefeffe feefeffe 3ffff6a0: feefeffe feefeffe feefeffe feefeffe 3ffff6b0: feefeffe feefeffe feefeffe feefeffe 3ffff6c0: feefeffe feefeffe feefeffe feefeffe 3ffff6d0: feefeffe feefeffe feefeffe feefeffe 3ffff6e0: feefeffe feefeffe feefeffe feefeffe 3ffff6f0: feefeffe feefeffe feefeffe feefeffe 3ffff700: feefeffe feefeffe feefeffe feefeffe 3ffff710: feefeffe feefeffe feefeffe feefeffe 3ffff720: feefeffe feefeffe feefeffe feefeffe 3ffff730: feefeffe feefeffe feefeffe feefeffe 3ffff740: feefeffe feefeffe feefeffe feefeffe 3ffff750: feefeffe feefeffe feefeffe feefeffe 3ffff760: feefeffe feefeffe feefeffe feefeffe 3ffff770: feefeffe feefeffe feefeffe feefeffe 3ffff780: feefeffe feefeffe feefeffe feefeffe 3ffff790: feefeffe feefeffe feefeffe feefeffe 3ffff7a0: feefeffe feefeffe feefeffe feefeffe 3ffff7b0: feefeffe feefeffe feefeffe feefeffe 3ffff7c0: feefeffe feefeffe feefeffe feefeffe 3ffff7d0: feefeffe feefeffe feefeffe feefeffe 3ffff7e0: feefeffe feefeffe feefeffe feefeffe 3ffff7f0: feefeffe feefeffe feefeffe feefeffe 3ffff800: feefeffe 00000000 feefeffe 000000f9 3ffff810: 00000064 00000001 40105385 3ffee228 3ffff820: 00000002 00000000 00000020 401001c8 3ffff830: 401025d1 00000001 00000002 401021a0 3ffff840: 3ffea062 4010541f 3ffed780 000000fe 3ffff850: 00000002 00000000 00000020 401001c8 3ffff860: 00000002 00000000 00000020 401001c8 3ffff870: 401025d1 4010541f 00000002 401021a0 3ffff880: 3ffea062 4010541f 3ffed780 00040000 3ffff890: 00000001 401045fa 3ffee228 401001c8 3ffff8a0: 40104a6b 40105437 3ffeda50 401001c8 3ffff8b0: 40104533 00000000 00000002 000000fe 3ffff8c0: 40104533 00000029 00000002 00040000 3ffff8d0: 00002200 00000000 00000000 000000ff 3ffff8e0: 00000005 00000000 00000020 401001c8 3ffff8f0: 3ffee1b0 00000000 00000005 401021a0 3ffff900: 3ffea065 40105437 3ffedaf0 401001c8 3ffff910: 40102d2b 3ffedaf0 00000002 401021a0 3ffff920: 00000000 00000000 0000001f 401001c8 3ffff930: 3ffea910 00000000 3fffc228 40105cd1 3ffff940: 4000050c 2c9f0300 4000050c 3fffc278 3ffff950: 401030e4 3fffc200 00000022 ffffffff 3ffff960: 4022fdd4 00000030 00000000 ffffffff 3ffff970: 4022b896 3fff1a48 00000001 40000000 3ffff980: 00000000 bfffffff 00080240 c00c3004 3ffff990: 3ffecf00 000c3000 ff000fff 3ffeeb50 3ffff9a0: 3fff058c 00000001 3fff4f8c 00000030 3ffff9b0: 40216535 00000000 00000003 00000000 3ffff9c0: 00000000 3ffffc50 00000002 3ffffba0 3ffff9d0: 00000002 00000000 00000020 401001c8 3ffff9e0: 00000002 00000000 0000000a 00000000 3ffff9f0: 00000002 00000000 40243157 00000000 3ffffa00: ffffffff 00000000 3ffea1b1 00000000 3ffffa10: 402431a6 00000000 3fff058c 000000fa 3ffffa20: 0000006c 00000001 40105385 3ffee228 3ffffa30: 3ffee1b0 00000005 00000002 401021a0 3ffffa40: 3ffea062 40242263 3ffed758 3fff4f8c 3ffffa50: 40104f6a 3ffee228 3ffeeb50 3fff058c 3ffffa60: 00000000 401048b9 3ffee228 3ffed758 3ffffa70: 3fff4fc2 40105a7b 3fff1a48 3ffeff98 3ffffa80: 40105081 3ffee228 00000008 00040000 3ffffa90: 53002200 4021cc0d 3fff1a48 3ffeff98 3ffffaa0: 4010513d 00080000 00000002 3ffffbc0 3ffffab0: 40103412 00000000 3ffffb10 3ffeffb0 3ffffac0: 3ffeffb0 00000000 3fff4f8c 4021ce3b 3ffffad0: 3ffeffe8 2c9f0300 4000050c 3fffc278 3ffffae0: 401030e4 3fffc200 00000022 00040000 3ffffaf0: 40000656 00000030 00000010 ffffffff 3ffffb00: 401002dd 00000000 00000000 4bc6a7f0 3ffffb10: 00000000 282a097f 3fff08e8 00000000 3ffffb20: 00004c35 3fffc6fc 47cf097f 00000000 3ffffb30: 002455a3 522d0e56 2a0304d7 00000030 3ffffb40: 4020a156 00000030 00000010 ffffffff 3ffffb50: 4020a152 00000000 00418937 00000000 3ffffb60: 00000000 3fff1e04 00000020 40100bdc 3ffffb70: 00000000 3ffe9f94 00000000 40100510 3ffffb80: 00000000 00000218 00000020 402253d1 3ffffb90: 00000006 3fff03c0 00000274 4021d2e4 3ffffba0: 00000452 00000010 3ffffc6c 4021d314 3ffffbb0: 3ffeffb0 3fff1e04 00000000 4021ff43 3ffffbc0: 00000000 0057180f 00000000 4020feb4 3ffffbd0: 00000046 7fffffff 3ffffc9c 00000000 3ffffbe0: 00000000 4bc6a7f0 6624dd2f 2a0304ee 3ffffbf0: 00000000 00000000 4bc6a7f0 00000000 3ffffc00: 00000001 3fff4064 401002dd 00000000 3ffffc10: 002455a3 3fff1e08 00000010 00000073 3ffffc20: 007a1200 77de7f91 3ffffd00 00000002 3ffffc30: 00000001 00000000 3fff2004 4020a152 3ffffc40: 00000010 00000010 00000073 3ffffcf0 3ffffc50: 3fff08e8 00000000 00000073 000000ff 3ffffc60: 000000cf 00000001 40105385 3ffee228 3ffffc70: 3ffee1b0 3ffffd14 3ffffc90 4020f5c4 3ffffc80: 04c4b400 77dea726 3fff0900 40202db8 3ffffc90: 40104f6a 00000000 00000010 000000fd 3ffffca0: 000000cf 00000001 40105385 3ffee228 3ffffcb0: 3ffee1b0 00000000 312e312f 3ffffd50 3ffffcc0: 00000005 00000000 00000020 401001c8 3ffffcd0: 401025d1 3ffee228 00000005 401021a0 3ffffce0: 4010432f 00040000 00000000 00040000 3ffffcf0: 00002200 4010432c 00040000 40105cd1 3ffffd00: 3ffee228 40103293 3ffee3fc 40102f08 3ffffd10: 00000005 00000000 00000020 401001c8 3ffffd20: 4000066d 2c9f0300 00000005 401021a0 3ffffd30: 3ffea065 40105437 3ffeda50 401001c8 3ffffd40: 40102d2b 3ffeda50 0000001f 401001c8 3ffffd50: 000000a7 8df3c376 3ffee3fc 40102f08 3ffffd60: 3ffea91c 00000000 00000000 3ffefb94 3ffffd70: 000000a7 8df3c376 401033c2 00000100 3ffffd80: 3ffea91c 7fffffff 00002200 00000001 3ffffd90: 00000001 00004a88 00000000 fffffffe 3ffffda0: 3ffea91c 3fffc6fc 00000001 8df3c376 3ffffdb0: 3ffea8ec 2c9f0300 4000050c 3fffc278 3ffffdc0: 401030e4 3fffc200 00000022 8df35128 3ffffdd0: 401060c2 00000030 00000010 ffffffff 3ffffde0: 4010028a 3ff20a00 3ffea8d8 00000000 3ffffdf0: 00004bc6 00000000 00000000 fffffffe 3ffffe00: 00000000 3fffc6fc 00000000 3ffefb80 3ffffe10: 00000000 3ffef6a0 3ffefb94 00000030 3ffffe20: 00000000 4bc6a7f0 ebc6a7ef 2a049598 3ffffe30: 007a1200 7985a96f 4bc6a700 00000000 3ffffe40: 00000000 00000000 00000001 401001c8 3ffffe50: 00000000 4bc6a7f0 eed91687 2a04959c 3ffffe60: 00000000 00000000 4bc6a7f0 00000000 3ffffe70: 3ffef6a0 3fff08e8 401002dd 00000000 3ffffe80: 002456fd 00000000 00000000 fffffffe 3ffffe90: 00000000 4bc6a7f0 f4bc6a7f 2a0495a3 3ffffea0: 00000000 00000000 4bc6a7f0 00000000 3ffffeb0: 402113ec 40100e60 401002dd 00000000 3ffffec0: 002456fd 00000000 00000000 fffffffe 3ffffed0: ffffffff 3fffc6fc 00000001 3ffefb94 3ffffee0: 3ffef6a0 00000000 3ffefb80 4020464e 3ffffef0: 00000000 3fffdad0 3ffefb94 00000030 3fffff00: 00000000 3fffdad0 3ffefb94 00000030 3fffff10: 54646c65 6c61746f 3ffe8500 401009d3 3fffff20: 00000000 001d001f 00000000 00000000 3fffff30: 000b000f 00000000 00000000 001b001f 3fffff40: 00000000 00000000 001a001f 00000000 3fffff50: 00000000 000b000f 00000000 3ffefb94 3fffff60: 007a1200 7985b2a9 00000000 3fff1314 3fffff70: 00000000 3fff12fc 3fff1310 feefeffe 3fffff80: 00000000 00000000 00000001 401001c8 3fffff90: 3fffdad0 00000000 3ffefb80 401001e9 3fffffa0: feefeffe feefeffe 3ffefb80 40211412 <<<stack<<< --------------- CUT HERE FOR EXCEPTION DECODER --------------- ets Jan 8 2013,rst cause:2, boot mode:(3,6) load 0x4010f000, len 3460, room 16 tail 4 chksum 0xcc load 0x3fff20b8, len 40, room 4 tail 4 chksum 0xc9 csum 0xc9 v000593e0 ~ld connect to network 'obmar' ... ............................... ..................................................................... [NTP]: 2022-07-03+09:28:43 SERIAL: 11 41 add inverter: PV HM 800, SN: 114180113742 RF24 Amp Pwr: RF24_PA_HIGH Radio Config: SPI Frequency = 1 Mhz Channel = 3 (~ 2403 MHz) RF Data Rate = 250 KBPS RF Power Amplifier = PA_HIGH 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 = 9 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 ---------------------------------------- Welcome to AHOY! point your browser to http://192.168.178.61 to configure your device ---------------------------------------- Free heap: 0x8ab8 Inverter #0 no Payload received! Requesting Inverter SN 114180113742 Transmit 27 | 15 80 11 37 42 78 56 34 12 80 0B 00 62 C1 61 46 00 00 00 05 00 00 00 00 6A A4 3D Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 49 00 48 00 EC 00 00 70 Manchmal geht auch die Verbindung zu Mqtt verloren. Hab ich aber noch keinen Log .
Hallo Oswald S., bitte hier keine Stacktraces / Exceptions reinpasten! Wir kennen das Problem und versuchen es seit einiger Zeit u.a. im folgrnden Github Issue zu analysieren: https://github.com/grindylow/ahoy/issues/15 Dort steht auch, wie Du Deinen Exception Code decodieren kannst. Das geht nur mit dem Original Hex/Binary file das auf Deinem ESP8266 geflasht wurde. Wir können also mit den Daten gar nichts anfangen sic ! Wenn Du weiteren Code hier pasten willst dann verwende bitte die [ code ] und [ / code ] Syntax (siehe unten beim Eingabefeld) um es für uns alle leserlich zu gestalten. Danke!
Hallo Oswald S., ansonsten scheint er ja einen WLAN Router zu erreichen, das nRF24L01+ Modul zu initialisieren und auf die Anfrage eine Antwort vom Wechselrichter zu bekommen und es ist soweit alles schick außer/nach dem Reboot.
Ach ja und das Problem mit dem Neuaufbau der MQTT Verbindung hatten wir vermeintlich schon gelöst: https://github.com/grindylow/ahoy/issues/68 Vielleicht ist die WLAN Verbindung doch nicht so stabil wie man es aus den o.a. Logfile annehmen könnte ? Das ist zumindest bei mir m.E. das Problem (mein Router ist im Keller und der ESP unterm Dach) da geht es nur in bestimmten Ecken des Zimmers und auch nur wenn die Nachbarn (bzw. deren WLAN Geräte) schlafen.
Hallo, gibt es denn schon erfolge bzgl. Hoymiles und Limitierung ? Ich habe das, was ich hier gelesen habe mal testweise eingebaut, leider bekomme auch ich keine Antwort oder eine Limitierung.
1 | void sendPowerLimitPacket(uint64_t invId, uint8_t limit, bool calcCrc = true) {
|
2 | //DPRINTLN(DBG_VERBOSE, F("hmRadio.h:sendCmdPacket"));
|
3 | memset(mTxBuf, 0, MAX_RF_PAYLOAD_SIZE); |
4 | mTxBuf[0] = 0x51; // message id |
5 | CP_U32_BigEndian(&mTxBuf[1], (invId >> 8)); |
6 | CP_U32_BigEndian(&mTxBuf[5], (DTU_ID >> 8)); |
7 | mTxBuf[9] = 0x5a; |
8 | mTxBuf[10] = 0x5a; |
9 | mTxBuf[11] = 0x32; |
10 | |
11 | if(calcCrc) {
|
12 | mTxBuf[12] = Hoymiles::crc8(mTxBuf, 12); |
13 | sendPacket(invId, mTxBuf, 13, false); |
14 | DPRINT(DBG_INFO, "Transmit (Limit) " + String(13) + " | "); |
15 | dumpBuf(NULL, mTxBuf, 13); |
16 | } |
17 | } |
Der Request sollte 50% limitieren. Die Payload dazu ist:
1 | [14:52:39]I: Transmit (Limit) 13 | 51 73 10 90 25 78 56 34 12 5A 5A 32 BD |
Wäre cool, wenn wir das hinbekommen, mein 2ter PWM is bereits nach Monaten Dauerbetrieb schon abgeraucht. Den nutze ich um die Stromstärke für den HM anzupassen. Marcel
Marcel A. schrieb: > Der Request sollte 50% limitieren. > > Die Payload dazu ist: > [code] > [14:52:39]I: Transmit (Limit) 13 | 51 73 10 90 25 78 56 34 12 5A 5A 32 > BD Das geht anscheinend bisher nur mit "meinem" MI-1500. Kannst du mal bitte diese Variante auch noch probieren? Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Ziyat, ich hab den test code mal angepasst auf:
1 | void sendPowerLimitPacket(uint64_t invId, uint8_t limit, bool calcCrc = true) {
|
2 | //DPRINTLN(DBG_VERBOSE, F("hmRadio.h:sendCmdPacket"));
|
3 | memset(mTxBuf, 0, MAX_RF_PAYLOAD_SIZE); |
4 | mTxBuf[0] = 0x51; // message id |
5 | CP_U32_BigEndian(&mTxBuf[1], (invId >> 8)); |
6 | CP_U32_BigEndian(&mTxBuf[5], (DTU_ID >> 8)); |
7 | mTxBuf[9] = 0x5a; |
8 | mTxBuf[10] = 0x5a; |
9 | mTxBuf[11] = 0x64; // 100% |
10 | mTxBuf[12] = 0x32; // 50W |
11 | |
12 | if(calcCrc) {
|
13 | mTxBuf[13] = Hoymiles::crc8(mTxBuf, 13); |
14 | sendPacket(invId, mTxBuf, 14, false); |
15 | DPRINT(DBG_INFO, "Transmit (Limit) " + String(14) + " | "); |
16 | dumpBuf(NULL, mTxBuf, 14); |
17 | } |
18 | } |
welches dann in folgende Payload übergeht:
1 | [16:21:06]I: Transmit (Limit) 14 | 51 73 10 90 25 78 56 34 12 5A 5A 64 32 D9 |
Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ? Marcel
Wie kann man die Befehle zur Limitierung senden?
Rene M. schrieb: > Wie kann man die Befehle zur Limitierung senden? Ich hab seit ein paar Tagen die EspHome Version fertig und teste die gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich zufrieden damit bin). Da habe ich mir einen Schalter eingebaut der dann die o.g. Funktion aufruft. Es ist derzeit noch nicht im code eingebaut und man müsste es sich immer selber bauen. Damals war es möglich ein Commando in der Seriellen Konsole aufzurufen, weiß aber nicht wie das gemacht wurde. Marcel
:
Bearbeitet durch User
Ok danke. Da bin ich schon gespannt darauf. Danke für die tolle Arbeit an alle!
Hallo zusammen, erst einmal vielen vielen Dank an alle die das Projekt hier ins Leben gerufen haben!!! Bei mir mit meinem Hoymiles HM-600 läuft das ganze jetzt schon ca. zwei Wochen ohne nennenswerte Probleme. Jetzt habe ich allerdings doch mal eine Frage: Im Setup bei MQTT kann man da nur eine IP adresse eingeben? Eine dyndns adresse wird nicht angenommen und es erscheint beim nachschauen die IP 0.0.0.0 Hat da wer ein Tipp für mich? Liebe Grüße Andreas
Die IP-Adresse von MQTT ist die Adresse zum MQTT-Server gemeint. ;)
Ja, soweit klar. Aber man kann nur eine IP adresse eingeben. Nicht z.B. „xyz.ddns.net“
Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso dann eine Dyndns Adresse?
Es spielt doch gar keine Rolle wor ein MQTT Server steht ! Das kann intern oder extern sein. Mein Vorschlag für die Programmierer wäre: MQTT ein/aus wählbar Wenn MQTT ein, dann A) IP Addr und Timeout in ms angebbar B) DNS Adr. und Timeout in ms angebbar Reihenfolge zur Erreichbarkeit Auswahl: (folgende Optionen nur wählbar, wenn A) bzw. B) auch ausgefüllt) Nur A) Nur B) Erst A) und wenn nicht erreichbar bis Timeout dann B) Erst B) und wenn nicht erreichbar bis Timeout dann A) So was in der Art würde vielleicht Sinn machen. Wer einen github Account hat, kann das ja gerne kopieren und dort hinterlegen. Ich habe da aktuell keinen Account.
Tobi D. schrieb: > Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso > dann eine Dyndns Adresse? Sie können einen Server außerhalb in der Cloud haben
Herbert K. schrieb: > Mein Vorschlag für die Programmierer wäre: > > MQTT ein/aus wählbar Schreib es auf Github als feature. :) https://github.com/grindylow/ahoy/issues
Mir ist etwas interessantes aufgefallen, für was ich keine Lösung finden kann: - Mit ahoy v0.4.14 - alles funtkioniert bestens. - Mit ahoy v0.4.20 - "Inverter is available but is not producing" Einstellungen sind alle gleich - getestet per OTA-Update als auch direkt aus Arduino auf den 8266 geladen. Ich bin leider kein Programmierer und kann nicht so weit in die Materie hereinschauen wie ihr, eventuell hilft aber der Hinweis
Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter nicht
dax schrieb: > Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter > nicht Der Wechselrichter produziert korrekt. Ich habe zwei ESP8266 mit NRF24l01+ hier aufgebaut um die Versionen zu testen. Mit Version 0.4.14 bekomme ich die nachweislich korrekten Werte angezeigt, mit Version 0.4.20 den oben beschriebenen Fehler. Es liegt nicht an der technischen Installation; es scheint zwischen beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser Meldung führt.
Angehängte Dateien:
oxylog schrieb: > Es liegt nicht an der technischen Installation; es scheint zwischen > beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser > Meldung führt. Hast Du die Pinout Einstellungen mal angepasst?
dax schrieb: > Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter > nicht Ist ja auch irgendwie erwartungsgemäß. Interessant wäre dann auch mal das Event-Log. Da müsste dann ein code 141 'Grid overvoltage' drin stehen.
Yes, die Einstellungen sind gleich wie bei meinem Testaufbau. Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht solche Fehler zu vermeiden. 0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings führen unter 0.4.20 zur Fehlermeldung. Kann das an einer NRF-Library-Version hängen?
Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon erfolgreich mit dem Projekt zum laufen gebracht?
oxylog schrieb: > Yes, die Einstellungen sind gleich wie bei meinem Testaufbau. > Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht > solche Fehler zu vermeiden. > 0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings > führen unter 0.4.20 zur Fehlermeldung. > Kann das an einer NRF-Library-Version hängen? Ok, jetzt habe ich doch einen Ansatz gefunden. Nochmals alle Bibliotheken aktualisiert, nochmals kompiliert - alle Einstellungen in Arduino überprüft - jetzt geht es. Sorry für den Trouble!
Norman Z. schrieb: > Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon > erfolgreich mit dem Projekt zum laufen gebracht? Hier steht im Datenblatt als Kommunikationsmedium "Sub-1G wireless". Das ist kein Nordic Semiductor NRF24 2.4GHz Modul. Wird also nicht funktionieren (würde ich annehmen)
Wechselrichter hoymiles HMT-xxxx HMS-xxxx DTU-Pro-S (Sub-1G wireless) ist vermutlich eine andere Übertragungstechnik / ein anderes Protokoll wie hoymiles HM-xxxx (nRF24). Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit HMT-xxxx, HMS-xxxx, DTU-Pro-S. Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt. Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless" Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt. Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless" Und für Hoymiles Gateway DTU-Pro-S bitte hier diskutieren: Beitrag "Hoymiles Gateway DTU-Pro-S mit "-S" Sub-1G wireless" Danke fürs Verständnis.
:
Bearbeitet durch User
Ich würde gerne mal OpenDTU mit einem HM-800 ausprobieren. Leider gibt es von den ESP32 so viele Versionen dass ich nicht durchblicke. Ist das hier der richtige? https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1 Ich finde auf git bei tbnonody leider nirgends eine vollständige Bezeichnung.
Angehängte Dateien:
-
Zwischenablage01.jpg
88 KB
Hallo, hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt sind? Hier HM-800 an ESP8266. Siehe Screenshot. Ich habe auch festgestellt das wenn der MQTT Server mal weg ist (oder man die falsche IP vergibt) der ESP nach einiger Zeit nicht mehr reagiert.
Hmm bei mir passt alles. Welche Version hast du?
Das ist die 0.4.20. Erst läuft auch alles normal... Dann nach einiger Zeit fängt das an.
:
Bearbeitet durch User
> hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt > sind? Hatte ich im Zusammenspiel PubSubClient und IOBroker MQTT schon öfters, nicht nur beim Ahoy.
> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die > gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich > zufrieden damit bin). Wenn du noch Tester brauchst :)
Marcel A. schrieb: > Hallo Ziyat, >
1 | > [16:21:06]I: Transmit (Limit) 14 | 51 73 10 90 25 78 56 34 12 5A 5A 64 |
2 | > 32 D9 |
3 | > |
> > Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste > ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ? > > Marcel Hallo Marcel Dein Transmit waere korrekt. 100% wird, wenn danach noch ein Byte kommt (abs. Watt) immer ignoriert, aber ich lasse immer 100% drin, zum debuggen ist einfacher. Ich denke das command:0x51 mit subcommand:0x5a5a funktioniert bei den HM's nicht, du bist der 2. Tester. Schade :-( Da ich kein HM habe, kann leider auch nicht sniffen, aber bald gibts bei mir einen HM-1500, dann kann ich es sicher heraus finden. Gruss
@Ziyat T. das wäre super. Ich bin nämlich mit meinem Latein am Ende. Habe mir die Doku nochmal angeschaut, aber irgendwann iser der Kopf nur noch voll. :(
1N 4. schrieb: >> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die >> gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich >> zufrieden damit bin). > > Wenn du noch Tester brauchst :) Sehr gerne. Du kannst meinen Fork checken: https://github.com/a-marcel/ahoy/tree/main/tools/esphome Ich würde gern wissen ob es auf einem esp8266 funktioniert. Ebenfalls habe ich Probleme die Payload in ein array zu packen und diese dann an den ESP Logger zu übergeben. Derzeit loggt er noch direkt zu Serial und das sieht man später nicht im EspHome log. Und wenn du mit der Readme nicht klar kommst, nehme ich sehr gerne Kommentare an. Bisher läuft sie seit 1 Woche gut durch. Mit kleineren Aussetzern aber keinen Reboot. Vielen Dank Marcel
:
Bearbeitet durch User
>> Wenn du noch Tester brauchst :) > Sehr gerne. Du kannst meinen Fork checken: > https://github.com/a-marcel/ahoy/tree/main/tools/esphome > Ich würde gern wissen ob es auf einem esp8266 funktioniert. Ich versuche das mal über das IOBroker - ESPHome Plugin zu kompilieren :)
Hallo Daniel R., hat eigentlich schon mal jemand versucht den Code von gitee.com (iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an die HM-Wechselrichter versenden / verpacken würde ? Das müsste doch in einer PlatformIO Umgebung oder einem STM IDE ohne weitere Bibliotheken gehen ... es scheint zumindest alles vorhanden. Ich strauchle immer noch über die Vorbelegung der beiden Laufzeit-Variablen TotalIndex_Para und Index_Para in den UsartNrf3_Send_PackDevControl() Aufrufen in der UsartNrf_Send_DevControlUpdate() Methode:
1 | 2542: Uart_SendBufferLen = UsartNrf3_Send_PackDevControl((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, (u16)(SubCmd << 8), (u8 *)MIMajor[PortNO].Property.Pass.Data + Index_Para, 0x81 + ((Index_Para + 4) / 16), TotalIndex_Para - Index_Para); |
bzw. CurSendRecLostPackageNO und CurSendRecLastPackageNO in den Aufrufen in UsartNrf3_Send_DevControlUpdate:
1 | 2603: Uart_SendBufferLen = UsartNrf3_Send_PackDevControl(target_adr, rout_adr, (u16)(SubCmd << 8), (u8 *)MIMajor[PortNO].Property.Pass.Data, (CurSendRecLastPackageNO + 1) | 0x80, TotalIndex_Para); |
In UsartNrf3_Send_PackDevControl() wird dann schließlich das Paket zusammengebaut:
1 | /*********************************************** |
2 | ** Function name: Three-generation protocol device control package |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | ** Returned value: ? |
7 | *************************************************/ |
8 | u8 UsartNrf3_Send_PackDevControl(u8 *target_adr, u8 *rout_adr, u16 ControlMode, u8 *ControlData, u8 nub, u8 Num) |
9 | {
|
10 | vu8 i = 0; |
11 | vu16 TempCrc = 0; |
12 | vu8 temp_dat[UART_LEN]; |
13 | vu16 DatCrc = 0xffff; |
14 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
15 | memset((u8 *)Uart_SendBuffer, 0, UART_LEN); |
16 | Uart_SendBuffer[0] = STX; //header |
17 | temp_dat[0] = DEVCONTROL_ALL; //command |
18 | memcpy((u8 *)&temp_dat[1], target_adr, 4);//Source address |
19 | memcpy((u8 *)&temp_dat[5], rout_adr, 4);//Destination address |
20 | temp_dat[9] = 0x81;// |
21 | |
22 | if((nub & 0x0f) == 1) |
23 | {
|
24 | temp_dat[10] = (u8)(ControlMode >> 8); //Control type |
25 | temp_dat[11] = (u8)(ControlMode); //Control type |
26 | } |
27 | |
28 | memcpy((u8 *) & (temp_dat[12]), ControlData, Num); //Control parameters |
29 | |
30 | for(i = 10; i < 12 + Num + 1; i++) |
31 | {
|
32 | if((i - 10) % 2 == 1) |
33 | {
|
34 | TempCrc = (u16)((temp_dat[i - 1] << 8) | (temp_dat[i])); |
35 | DatCrc = CalcCRC16t(TempCrc, DatCrc); |
36 | } |
37 | } |
38 | |
39 | temp_dat[12 + Num] = (u8)(DatCrc >> 8); |
40 | temp_dat[13 + Num] = (u8)(DatCrc); |
41 | temp_dat[14 + Num] = Get_crc_xor((u8 *)&temp_dat[0], 15 + Num); |
42 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], (15 + Num)); //Forward replacement |
43 | Uart_SendBuffer[(i + 1)] = ETX; // footer |
44 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
45 | return (i + 2); |
46 | } |
Mit den folgenden Annahmen:
1 | // STX: 0x7e |
2 | // MainCmd: 0x51 DEVCONTROL_ALL/REQ_ARW_DAT_ALL |
3 | // target_adr: 0x73109025 |
4 | // rout_adr: 0x78563412 |
5 | // SubCmd: 0x0B Type_ActivePowerContr |
6 | // ControlMode: (u16)(SubCmd << 8): 0x0B00 |
7 | // *ControlData: (u8 *)MIMajor[PortNO].Property.Pass.Data: 0x00000000 00000000 00000000 00000000 0000 |
8 | // PowerPFDev: 0x03EB0001 // SetValut[2], Desc[2] |
9 | // nub: (CurSendRecLastPackageNO + 1) | 0x80: 0x81 |
10 | // Num: TotalIndex_Para: 4 ? |
11 | // ETX: 0x7f |
ergibt sich diese Paketstruktur
1 | temp_dat[i]: -1, 0, 1..4, 5..8, 9, 10-11, 12-15, 16 |
2 | STX, MainCmd, target_adr[4], rout_adr[4], 0x81, 0x0B00, 0x00000000, ETX |
und es sollte evtl. irgendwas wie das Folgende herauskommen: 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f Über den Wert aus PowerPFDev 0x03EB0001 bzw. Pass.Data[4] wird noch mit CalcCRC16t und Get_crc_xor eine/mehrere Prüfsummen gebildet. PS: die InverterMajor Struktur sieht wie folgt aus:
1 | InverterMajor |
2 | Property |
3 | Pre_Id[2] (vu8) |
4 | Id[4] (vu8) |
5 | Port (PortType) |
6 | Id_In_Phase (vu8) |
7 | Acq_Switch (vu8) |
8 | Power_Limit (vu16) |
9 | Pass (PassValueType) |
10 | PowerPFDev (PowerPFDevType) |
11 | SetValut[2] (vu8) |
12 | Desc[2] (vu8) |
13 | ClearAlarmDev (ClearAlarmDevType) |
14 | WCode[2] (vu8) |
15 | EletricSet (EletricSetType) |
16 | Info[2] (vu8) |
17 | Data[16] (vu8) |
18 | PassWordSet (PassWordSetType) |
19 | PWO[4] (vu8) |
20 | PWN[4] (vu8) |
21 | ATTime[2] (vu8) |
22 | Data[18] (vu8) |
23 | PropertyMsg[30] (vu8) |
Und hier sind die für MI und HM definierten Lower Bytes der Pre_Id's die Id sind jeweils die lower 4 Bytes der Inverter Serial No. Serial Number: Pre_Id[2] + Id[4]
1 | typedef enum |
2 | {
|
3 | MI_NO = 0, |
4 | MI_250W = 0x01, |
5 | MI_500W_A = 0x02, |
6 | MI_500W_B = 0x03, |
7 | MI_1000W_A = 0x04, |
8 | MI_1000W_B = 0x05, |
9 | MI_1000W_C = 0x06, |
10 | MI_1000W_D = 0x07, |
11 | Pro_A = 0x08, |
12 | Pro_B = 0x09, |
13 | Pro_C = 0x0a, |
14 | Pro_D = 0x0b, |
15 | HM_250W = 0x0C, |
16 | HM_500W_A = 0x0D, |
17 | HM_500W_B = 0x0E, |
18 | HM_1000W_A = 0x0F, |
19 | HM_1000W_B = 0x10, |
20 | HM_1000W_C = 0x11, |
21 | HM_1000W_D = 0x12, |
22 | } PortType; |
Hallo Daniel R., alternativ geht es nach der Implementierung in UsartNrf_Send_PackSetPowerLimitCommand()
1 | /*********************************************** |
2 | ** Function name: The second-generation protocol sets the micro-inverse power package |
3 | ** Descriptions: |
4 | ** input parameters: |
5 | ** output parameters: |
6 | ** Returned value: |
7 | *************************************************/ |
8 | u8 UsartNrf_Send_PackSetPowerLimitCommand(u8 *target_adr, u8 *rout_adr, int8_t MainCmd, u16 SubCmd) |
9 | {
|
10 | vu8 i = 0; |
11 | vu8 temp_dat[UART_LEN]; |
12 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
13 | Uart_SendBuffer[0] = STX;//start |
14 | temp_dat[0] = (u8)MainCmd; //command |
15 | memcpy((u8 *)&temp_dat[1], target_adr, 4); |
16 | memcpy((u8 *)&temp_dat[5], rout_adr, 4); |
17 | #ifdef DTU3PRO |
18 | |
19 | if((Dtu3Detail.Property.Zero_Export_Switch == 1) || |
20 | (Dtu3Detail.Property.DRM_Limit_Switch == 1) || |
21 | (Dtu3Detail.Property.Phase_Balance_Switch == 1) || |
22 | (Dtu3Detail.Property.SunSpec_Switch == 1)) |
23 | {
|
24 | if(MIMajor[PortNO].Property.Acq_Switch == 0) |
25 | {
|
26 | //1000w shutdown special control micro-inverse control of 1-to-4 with the last 8 digits of the ID less than 0x50000000 |
27 | if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61))) |
28 | {
|
29 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
30 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
31 | temp_dat[11] = 11; |
32 | // temp = 35*4*10=1400=0x0578; |
33 | temp_dat[12] = 0X05; |
34 | temp_dat[13] = 0X78; |
35 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
36 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
37 | } |
38 | else |
39 | {
|
40 | temp_dat[9] = (u8)(CONTROL_OFF_SUB >> 8); //aa55 |
41 | temp_dat[10] = (u8)(CONTROL_OFF_SUB & 0XFF); |
42 | temp_dat[11] = Get_crc_xor((u8 *)&temp_dat[0], 11); //CRC |
43 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 12); //forward substitution |
44 | } |
45 | } |
46 | else |
47 | {
|
48 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
49 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
50 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
51 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
52 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
53 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
54 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
55 | } |
56 | } |
57 | else |
58 | {
|
59 | #endif |
60 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
61 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
62 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
63 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
64 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
65 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
66 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
67 | #ifdef DTU3PRO |
68 | } |
69 | |
70 | #endif |
71 | Uart_SendBuffer[(i + 1)] = ETX; //end |
72 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
73 | return (i + 2); |
74 | } |
Hier im Beispiel ein HM-1161 mit bis zu 2700 W maximaler Spitzenleistung. Das müsste m.E. dann folgendes Paket ergeben:
1 | 1000W: 0x51 0x73109025 0x78563412 0xa5a5 0x03 0x03E8 CRC8 |
2 | 1500W: 0x51 0x73109025 0x78563412 0xa5a5 0x05 0x05DC CRC8 |
3 | 400W: 0x51 0x73109025 0x78563412 0xa5a5 0x01 0x0100 CRC8 |
Hierbei ist 0x05 bzw. 0x03 der Wert des (PowerLimit * 10) dividiert durch die maximale Leistung (9*300W=2700W) des Inverters (bei 300 W pro "Kanal") wobei die HM-Modelle offenbar eine maximale Spitzenleistung zwischen 2100 W und 3000 W zur Validierung der führenden Stelle verwenden bzw. verkraften ? Im obigen Beispiel also:
1 | (1000*10)/(300*9)=10000/2700=3.70->(u8) 3 |
2 | (1500*10)/(300*9)=15000/2700=5.55->(u8) 5 |
3 | (400*10)/(300*9)= 4000/2700=1.58->(u8) 1 |
Danach folgt in zwei weiteren Bytes das PowerLimit nochmal als Hex-Wert, hier 0x05DC (1500 W) bzw. 0x03E8 (1000 W) oder 0x0100 (400 W). Hier noch die Anzahl der "Kanäle" bzw. der maximale Spitzenlast-Leistungsindex der Inverter:
1 | typedef enum |
2 | {
|
3 | InitInverterType = 0, |
4 | Inverter_250 = 1, |
5 | Inverter_500 = 2, |
6 | Inverter_1000 = 4, |
7 | Inverter_Pro = 7, |
8 | Inverter_HM_OneToOne = 8, |
9 | Inverter_HM_OneToTwo = 9, |
10 | Inverter_HM_OneToFour = 10, |
11 | } InverterType; |
und die entsprechende Routine um den Invertertyp zu bestimmen.
1 | /*********************************************** |
2 | ** Function name: Get the micro-inverse type |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | ** Returned value: ? |
7 | *************************************************/ |
8 | |
9 | InverterType UsartNrf_GetInvterType(u8 *pId) |
10 | {
|
11 | if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x26) // 0x0260 |
12 | {
|
13 | return Inverter_Pro; // 7*300W=2100W |
14 | } |
15 | else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x12) // 0x0120 |
16 | {
|
17 | return Inverter_HM_OneToOne; // 8*300W=2400W |
18 | } |
19 | else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x14) // 0x0140 |
20 | {
|
21 | return Inverter_HM_OneToTwo; // 9*300W=2700W |
22 | } |
23 | else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x16) // 0x0160 |
24 | {
|
25 | return Inverter_HM_OneToFour; // 10*300W=3000W |
26 | } |
27 | else |
28 | {
|
29 | if(((pId[1] & 0xf0) == 0x10) || ((pId[1] & 0xf0) == 0x20)) //0x0010 || 0x0020 |
30 | {
|
31 | if(((pId[0] == 0x10) && (pId[1] == 0x22)) || ((pId[0] == 0x11) && (pId[1] == 0x21))) // 0x1022 || 0x1121 |
32 | {
|
33 | return Inverter_HM_OneToOne; // 8*300W=2400W |
34 | } |
35 | else if(((pId[0] == 0x10) && (pId[1] == 0x19)) || ((pId[0] == 0x10) && (pId[1] == 0x29))) // 0x1019 || 0x1029 |
36 | {
|
37 | return InitInverterType; // 0*300W=0W |
38 | } |
39 | else // others |
40 | {
|
41 | return Inverter_250; // 1*300W=300W |
42 | } |
43 | } |
44 | else if(((pId[1] & 0xf0) == 0x30) || ((pId[1] & 0xf0) == 0x40)) //500w // 0x0030 || 0x0040 |
45 | {
|
46 | if(((pId[0] == 0x10) && (pId[1] == 0x42)) || ((pId[0] == 0x11) && (pId[1] == 0x41))) // 0x1042 || 0x1141 |
47 | {
|
48 | return Inverter_HM_OneToTwo; // 9*300W=2700W |
49 | } |
50 | else if(((pId[0] == 0x10) && (pId[1] == 0x39)) || ((pId[0] == 0x10) && (pId[1] == 0x49))) // 0x1039 || 0x1049 |
51 | {
|
52 | return InitInverterType; // 0*300W=0W |
53 | } |
54 | else // others |
55 | {
|
56 | return Inverter_500; // 2*300W=600W |
57 | } |
58 | } |
59 | else if(((pId[1] & 0xf0) == 0x50) || ((pId[1] & 0xf0) == 0x60)) // 0x0050 || 0x0060 |
60 | {
|
61 | if(((pId[0] == 0x10) && (pId[1] == 0x62)) || ((pId[0] == 0x11) && (pId[1] == 0x61))) // 0x1062 || 0x1161 |
62 | {
|
63 | return Inverter_HM_OneToFour; // 10*300W=3000W |
64 | } |
65 | else if((pId[0] == 0x10) && (pId[1] == 0x69)) // 0x1069 |
66 | {
|
67 | return InitInverterType; // 0*300W=0W |
68 | } |
69 | else // others |
70 | {
|
71 | return Inverter_1000; // 4*300W=1200W |
72 | } |
73 | } |
74 | else if((pId[0] == 0x12) && (pId[1] == 0x61)) // 0x1261 |
75 | {
|
76 | return Inverter_Pro; // 7*300W=2100W |
77 | } |
78 | |
79 | return InitInverterType; // 0*300W=0W |
80 | } |
81 | } |
Hi Stefan, Stefan T. schrieb: > hat eigentlich schon mal jemand versucht den Code von gitee.com > (iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im > Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an > die HM-Wechselrichter versenden / verpacken würde ? Ja da war ich dran, jedoch denke ich das ich dann an meine grenzen gekommen bin. Ich mag es eigentlich nicht alleine zu Coden.^^ Da ich irgendwann Abends nur noch frustriert bin wenn es nicht so voran geht wie ich es mir eigentlich wünsche. ^^ > und es sollte evtl. irgendwas wie das Folgende herauskommen: > 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f Genau das habe ich letztens auch verschickt... nur ich glaube mittlerweile das ich einen kleinen Fehler hatte (der großes bewirkt). Asche auf mein Haupt - Natührlich möchte ich auch ehrlich sein und den Fehler kongretisieren: In der Excel stehen ja die Protkolle wie Sie auszusehen haben, daran habe ich mich gehalten. Nur habe ich Bsp. 0x0B geschickt, statt 0x0B00 wie es teilweiße im *.c zu sehen ist. ;( Sobald ich heute Zuhause bin, schaue ich mir das ganze nochmal an. Habe mir jetzt paar Tage abstand gehalten und habe wieder einen freien Kopf dafür. :) Danke für eure Hilfe! > PS: die InverterMajor Struktur sieht wie folgt aus: Das habe ich auch gesehen. Edit: Ganz kurz für dumme (wie mich), ich bin kein Profi meine aber auch etwas drauf zu haben. ^^ Mir ist auch aufgefallen im Code das sogar Unterschieden wird welcher WR genau angesprochen wird. Ob es 1/2/4 Kanal hat und und und... Ich war kurz davor das ganze zu portieren, jedoch bevor ich mir die Arbeit gemacht hätte habe ich zuerstmal versucht direkt aus der Paketstruktur die Daten zum WR zu senden und erst wenn das funktioniert ein ordentliches funktionen geschrieben damit es später automatisch im Hintergrund auch richtig verarbeitet wird (so wie es im code zu sehen ist). Der einzige Knackpunkt womit ich zu kämpfen habe, ich lese ganz gerne die einzelnen Hex werte als Byte durch. Bsp: 05 06 07 08 09 0A ... Wenn mir jemand 0x0500 schreibt, bin ich immer dabei nur die 0x05 zu sehen. Was an sich falsch ist! // Daher ein Fehler von mir. ;( PS: Wenn jemand Lust hat, kann man sich mal auf Discord treffen. Einfach melden, ich schicke den Einladungslink dann.
:
Bearbeitet durch User
Gerald R. schrieb: > Ist das hier der richtige? > https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1 Ja, der sollte funktionieren. Wie alle anderen ESP32devkit Klone auch.
@Stefan T. @Daniel R. > typedef enum > { > MI_NO = 0, > MI_250W = 0x01, > MI_500W_A = 0x02, > MI_500W_B = 0x03, > MI_1000W_A = 0x04, > MI_1000W_B = 0x05, > MI_1000W_C = 0x06, > MI_1000W_D = 0x07, > Pro_A = 0x08, > Pro_B = 0x09, > Pro_C = 0x0a, > Pro_D = 0x0b, > HM_250W = 0x0C, > HM_500W_A = 0x0D, > HM_500W_B = 0x0E, > HM_1000W_A = 0x0F, > HM_1000W_B = 0x10, > HM_1000W_C = 0x11, > HM_1000W_D = 0x12, > } PortType; Wie hier ersichtlich, die gite Dokumente beinhalten nicht die HM-1200,HM-1500,MI-1200, MI-1500. Diese sind nicht unbedingt RF_communication_protocol-V6.5.xlsx kompatibel. Die könnten ev. gleich sein wie MI_1000W_D/HM_1000W_D, also 4 Kanal Modelle, eben nur eventuell..Um das Sniffen kommt man nicht herum, MI-1500 hab ich schon.
Stefan T. schrieb: > und es sollte evtl. irgendwas wie das Folgende herauskommen: > 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f - CMD 0x51 hat kein SubCMD 0x81 ???? - Warum schickst du diese 0x7e/0x7f ??? Diese sind nur für DTU-NRF intern Serial Kommunikation, die werden nicht in die Luft geschickt!! Gruss
Beitrag #7117766 wurde vom Autor gelöscht.
Axel H. schrieb: > https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1 > > Ja, der sollte funktionieren. Wie alle anderen ESP32devkit Klone auch. Danke!
Hallo zusammen, also ich habe das mal probiert. Kein erfolg. Bekomme höchstens immer folgende Antwort: Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
Hallo Sigi, ich habe probiert Datenpakete zum HM-WR zu senden, so wie isnoahoy beschrieben hat. ;)
Stellt euch doch lieber ein PC mit boinc zum verbrennen überschüssigem Stroms hin. Dann hat die Wissenschaft auch noch sinnvoll was davon.
Daniel R. schrieb: > Hallo zusammen, > > also ich habe das mal probiert. Kein erfolg. > Bekomme höchstens immer folgende Antwort: > > Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 > 00 00 00 00 00 00 00 00 00 01 81 eb 9b > Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb Wenn du das auch schreiben würdest was du geschickt hast? edit: das auch beachten Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
> Daniel R. schrieb: > Hallo zusammen, > > also ich habe das mal probiert. Kein erfolg. > Bekomme höchstens immer folgende Antwort: > > Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 > 00 00 00 00 00 00 00 00 00 01 81 eb 9b > Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb Was du gesendet hast, würde mich auch interessieren, denn ich habe bisher noch nicht mal eine Antwort bekommen und das was du da geschickt hast ... darauf kann man ja aufbauen und rumspielen. Danke Marcel
:
Bearbeitet durch User
Herbert K. schrieb: > Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit > HMT-xxxx, HMS-xxxx, DTU-Pro-S. > > Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt. > Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless" > > Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt. > Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless" Jetzt habt ihr hier einen Thread mit weit über 1000 Beiträgen - Respekt Ich lese oft nicht nicht mehr mit - alleine weil mi das laden zu lange dauert Aber Herbert - so geht das leider auch nicht Dann mach doch Dein eigenes Forum für die Hoymiles-WR auf? Oder überzeuge die Mc-Admins hier eine eigene Unterrubrik zu machen? Einfach Leute mit für Dich uninteressante Themen abwimmeln - dann erst mal raus mit allen Mi-WR-Besitzern, hier geht es um die HM-Serie VG
Hallo Jan-Jonas, ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das DTU-NRF Protokoll an sich ist schon interessant und bei der aktuellen Situation wäre es schon praktisch, wenn man die HM-Wechselrichter evtl. mit einem eigenen Grid Profile (laut Source Code kann man ein 1200 Punkte langes Window-Frame aufnehmen (Sinux, Sägezahn, Rechteck, etc. =^} welches dann m.E. zur Analyse und Nachbildung der aktuellen Wechselstromkurve dient) bestücken könnte oder gar die Firmware updaten kann ... Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren, einfach die Hauptsicherung rausdrehen und ab geht die Luzie! Jaja ich weiß darf man natürlich alles nicht wenn (solange) es an das Niedervolt-Netz des lokalen Elektrizitätversorgers angeschlossen ist. @Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^! @Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End Transmission Bytes, die die DTU Software für die SPI Kommunikation mit dem NRF24 Modul als STX/SOF und ETX/EOF einfügt. Die kannst DU auch gerne weglassen, weil sie evtl. von der NRF24 Bibliothek eh eingefügt werden. Ich habe Sie nur im Zusammenhang mit der analysierten Code Stelle erwähnt. Wegen den PortType's gehe ich davon aus, dies sind die einzelnen DC Eingangsports der unterschiedlichen HM- und MI-Wechselrichter Typen. Die eigentlichen Invertertypen werden in UsartNrf_GetInvterType() aus der Pre_Id also den ersten beiden Bytes der Seriennummer (z.B. 1141 bei meinem HM-600 führt zu einem Inverter_HM_OneToTwo) abgeleitet. Die DC PortType's werden hingegen bei der Berechnung der einzelnen Leistungen berücksichtigt / unterschieden, da ja jeder Eingang (DC Ports A/B/C/D) auch unterschiedlich viel Ertrag bringen kann. Das wird dann m.E. in AntiReflux.c/.h gebraucht um die Leistung aller Wechselrichter, die von einer DTU kontrolliert werden, möglichst gleichmäßig auf alle drei AC Phasen A/B/C zu verteilen. @Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll zumindest die elektronische und funkseitige Komponente der HMT- / HMS- und DTU-Pro-S in einem übersichtlichen Thread zu behandeln. Keine Ahnung ob dafür aber zwei/drei separate Threads notwendig & hilfreich sind (da vermutlich keiner von uns dort regelmäßig liest) und wie viele Anfragen dazu überhaupt reinkommen. Andererseits scheint die DTU-PRO-S eventuell sogar den selben Basis Code wie im gitee.com zu verwenden. Es gibt zumindest eine Vielzahl von #ifdef DTU3PRO und die aktivieren einen stm32f4xx anstelle eines stm32f10x Prozessors. Vielleicht finden sich ja irgendwo auf einer FCC ID Seite irgendwelche Informationen zur CPU ?
Stefan T. schrieb: > @Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen > Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es > den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir > mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^! Kann ich heute anhängen, log sei dank. =)
Thomas B. schrieb: > Es gibt noch etliche Stellen die nicht perfekt sind, einer > Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte > erstmal was lauffähiges haben. > Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU > Im docs Ordner gibt es auch ein paar Screenshots der WebGUI. > > In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking > Changes" geben was die Namen der MqTT Topics anbelangt. > Die Payload Erzeugung habe ich auch schon in die Inverter Klassen > verlegt. Dies ist jedoch mangels Test noch nicht commited. > > Über Anregungen und/oder PRs würde ich mich freuen. > > Grüße > Thomas Hallo Thomas, ich habe es gestern endlich geschaft deine ESP32 Version mit meinem HM-400 zu testen. Es lief auf anhieb ohne Probleme. 2 Dinge sind mir mit der aktuellen Version aufgefallen: - Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten Tabelle - MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und im Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK ist. Eventuell liegts auch am MQTT Server?
John P. schrieb: > Thomas B. schrieb: > >> Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU > > Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone > zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten > Tabelle Da war ich schon dran und hab auch einen PR gemacht. Den könntest du probieren. Als nächstes wollte ich noch die NavBar und das Scrolling angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei Tablet / mobile aufgefallen war.
Stefan T. schrieb: > Hallo Jan-Jonas, > ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das Es sind Leute da, die nicht in Deutschland leben, es gibt Laender da darfst du nichts einspeisen, wenn dann bezahlst du die Einspeisung auch! > Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren, Die Gedanken habe ich auch gemacht, es waere nett ;-) > @Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End > Transmission Bytes, die die DTU Software für die SPI Kommunikation mit > dem NRF24 Modul als STX/SOF und ETX/EOF einfügt. Das meinte ich ja auch, waere besser hier ohne STX/SOF und ETX/EOF zu kommunizieren, weil es mich irritiert, ob ihr das Packet mit oder ohne sendet > @Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll > zumindest die elektronische und funkseitige Komponente der HMT- / HMS- > und DTU-Pro-S in einem übersichtlichen Thread zu behandeln. Vorlaeufig finde es auch
Axel H. schrieb: > Da war ich schon dran und hab auch einen PR gemacht. Den könntest du > probieren. Als nächstes wollte ich noch die NavBar und das Scrolling > angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu > About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei > Tablet / mobile aufgefallen war. Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute Abend mal drüber schauen.
John P. schrieb: > - MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und > im Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es > kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob > MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK > ist. > Eventuell liegts auch am MQTT Server? Könntest du für solche Themen ggf. bitte einen Issue auf Github aufmachen? Dann bleibt hier der Thread für die wichtigen Themen frei. Hast du ACL's konfiguriert? Ein MQTT Client kann nämlich nicht feststellen ob er an die entsprechende Topic publishen darf. Wenn das z.B. durch ACL's (oder Benutzer rechte) verboten ist gehen die Nachrichten einfach unter. Ich habe das selbst mit einem Mosquitto (letzte Debian Pakete von mosquitto.org also Version 2.x) Broker im Einsatz und kann erst mal keine Probleme feststellen.
Thomas B. schrieb: > Axel H. schrieb: >> Da war ich schon dran und hab auch einen PR gemacht. Den könntest du >> probieren. Als nächstes wollte ich noch die NavBar und das Scrolling >> angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu >> About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei >> Tablet / mobile aufgefallen war. > > Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute > Abend mal drüber schauen. Lass Dich nicht stressen. Die PRs werden auch nicht dauerhaft in der Frequenz kommen. Hab hier gerade in Betrieb genommen und arbeite meine Liste ab. Wenn ich schon nichts zum RE des Protokolls beitragen konnte. Dafür übrigens herzlichen Dank an alle Beteiligten! Mit zu lesen und zu fiebern hat extrem viel Freude gemacht und war erkenntnisreich! Als ich im März bestellt hatte, war das die eine Kröte, die ich geschluckt habe. Dass Auslesen nur über die Cloud geht und ich da halt drauf verzichten werde. Dass das jetzt doch geht ist ganz hervorragend!
Hallo zusammen, ich lese sporadisch mit und bin auf der Suche nach einer Lösung für meinen HM-1500. Leider reichen meine Kenntnisse nicht aus, dass hier alles geschriebene nachzuvollziehen und zu verstehen. Daher meine Frage, gibt es von euch bereits ein fertiges Produkt was ich kaufen könnte? Im Moment habe ich das DTU Teil im Einsatz, allerdings gefällt es mir überhaupt nicht, dass ich so viele Daten preisgeben muss. Vielen Dank für eure Antwort. Gruß
Hallo Ronny, es gibt verschiedene Lösungen. Es kommt drauf an was für dich am einfachsten ist. Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann... dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine kleine Bezahlung?). Natührlich wird hier daran weiter gearbeitet. Ich habe auch noch viele Ideen was man hinzufügen kann. Jedoch wird aktuell verstärkt an der Limitierung gearbeitet. Im Grunde geht das Auslesen der Werte. Mehr aus dem Github zu entnehmen: https://github.com/grindylow/ahoy/ (hier wird m.E verstärkt gearbeitet) oder https://github.com/tbnobody/OpenDTU
:
Bearbeitet durch User
Marcel A. schrieb: > Was du gesendet hast, würde mich auch interessieren, denn ich habe > bisher noch nicht mal eine Antwort bekommen und das was du da geschickt > hast ... darauf kann man ja aufbauen und rumspielen.
1 | Poll inverter 116174403329 |
2 | 2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
3 | 2022-07-05 14:35:31.453370 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
4 | 2022-07-05 14:35:32.693952 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
5 | 2022-07-05 14:35:33.931475 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
6 | 2022-07-05 14:35:33.980149 Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
7 | 2022-07-05 14:35:34.483548 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
8 | payload has valid modbus crc |
9 | payload has 14 bytes |
10 | |
11 | Field view: int |
12 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
13 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
14 | >B 128 0 0 0 0 0 0 0 0 0 0 0 0 1 |
15 | |
16 | Field view: shorts |
17 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
18 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
19 | >H 32768 0 0 0 0 0 1 |
20 | >H 0 0 0 0 0 0 |
21 | |
22 | Field view: longs |
23 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
24 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
25 | >L 2147483648 0 0 |
26 | >L 0 0 0 |
27 | >L 0 0 1 |
28 | >L 0 0 |
29 | type utf-8 : utf-8 decode error |
30 | type ascii : ascii decode error |
und
1 | 2022-07-05 16:11:51.881684 Transmit 17 | 51 74 40 33 29 78 56 34 12 81 0b 00 03 eb 00 01 14 |
2 | 2022-07-05 16:11:53.117722 Transmit 17 | 51 74 40 33 29 78 56 34 12 81 0b 00 03 eb 00 01 14 |
3 | 2022-07-05 16:11:53.164533 Received 27 bytes channel 61: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
4 | 2022-07-05 16:11:53.668439 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
Die Log hängt im Anhang. Diesen Payload bekomme ich so oft, sind in der Log 189 mal zu finden. Discord Link für alle: https://discord.gg/2jUFfKkD
:
Bearbeitet durch User
Moin, kann mal einer die Teileliste posten bitte was ich brauche, damit ich es alles zusammen löten kann :) Danke Eike
@Eike (Gast): Dies ist kein Restaurant mit Kellner ! Dies ist ein Buffet. Da muss man sich selbst bedienen ! Alles was Du wissen möchtest wurde in vorherigen Beiträgen mehrfach beschrieben. Teilweise mit Fotos, Links, Bezugsquellen, Verdrahtungsplänen. Du brauchst Dir nur die Informationen vom Buffet=Beiträge nehmen.
vielleicht kann mir einer helfen ich hab seit gestern einen d1 mini mit dem funkmodul laufen soweit funktioniert alles gut, webseite läuft und die daten kommen auch beim iobroker an. nur leider ist der d1 mini immer wieder im netzwerk nicht mehr erreichbar ping bricht ab. ich hab noch einige andere d1 mini laufen wodurch ich ein wlan problem ausschließe was könnte da sein? version hab ich die 0.4.20
tom schrieb: > nur leider ist der d1 mini immer wieder im netzwerk nicht mehr > erreichbar > ping bricht ab. Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83 Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich. Versucht werden kann: - Anderes Netzteil/Kabel, - Elko über +/GND des nRF24L01+, - das Abfrageintervall auf 30 s einstellen.
Daniel R. schrieb: Marcel A. schrieb: >> Was du gesendet hast, würde mich auch interessieren, denn ich habe >> bisher noch nicht mal eine Antwort bekommen und das was du da geschickt >> hast ... darauf kann man ja aufbauen und rumspielen. > > [code] > Poll inverter 116174403329 > 2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 > 5a 78 35 61 00 78 30 31 01 00 f8 Hab schon mal drauf hingewiesen: CMD 0x51 hat kein SubCMD 0x81, dann 0x5a etc. oder hab ich etwas übersehen? Dann sehe ich Unixtimestamp drin, Tue Jul 27 2021 21:18:40 GMT+0000 Dieses Polling für HM kann nicht gehen. Set Time/Data geht z.Bsp. so CMD 0x15 mit SubCMD 0x80 und Timestamp: 15 72220200 72220200 80 0B 00 62 09 04 9b 00 00 00 00 00 00 00 00 F2 68 F0 CMD 0x51 hat SubCMD 0x5A5A für Limitierung CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock Und diese funktionieren scheinbar nur mit MI-1500, bisher..
Ziyat T. schrieb: > CMD 0x51 hat SubCMD 0x5A5A für Limitierung > CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock > Und diese funktionieren scheinbar nur mit MI-1500, bisher.. Das ist korrekt! Steht ja auch in der Excel/c-File.
Günter H. schrieb: > tom schrieb: >> nur leider ist der d1 mini immer wieder im netzwerk nicht mehr >> erreichbar >> ping bricht ab. > > Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83 > Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich. > Versucht werden kann: > > Anderes Netzteil/Kabel, > Elko über +/GND des nRF24L01+, > das Abfrageintervall auf 30 s einstellen. Danke für die Infos, werde ich testen. Welcher Elko wäre ideal?
Ich n tom schrieb: >> Anderes Netzteil/Kabel, >> Elko über +/GND des nRF24L01+, >> das Abfrageintervall auf 30 s einstellen. Ich nutze ein Iphone Netzteil. Ohne Elko etc. Elko >= 1000 uF / 10 Volt passt auf jeden Fall. Ein 100 nF zus. parallel kann auch nicht schaden.
:
Bearbeitet durch User
Angehängte Dateien:
-
Firmware_0422.png
97 KB -
AhoyMiles_0420.png
67 KB -
AhoyMiles_schem_0420.png
37 KB -
AhoyMiles_schem_0420.png
37 KB
Hier https://github.com/grindylow/ahoy gibt es für das D1 mini-Board die Firmware Version 0.4.22. Das Kompilieren geschieht jetzt über Visual Studio Code/Platformio. Da ich diese Software vor einigen Tagen zum Testen der Firmware für das ESP32-Board installiert hatte, wurde nach Download des "ahoy-main.zip"-Ordners und dem Öffnen der "platformio.ini" mit dem "Platformio: Build"-Befehl (überraschenderweise) erfolgreich eine "firmware.bin" erzeugt. Im Platformio-Explorer findet man den Speicherort der neuen Firmware - ggf. im Windows-Explorer suchen. Mit dieser neuen Firmware habe ich dann von Version 0.4.20 problemlos ein Update auf 0.4.22 gemacht. Was das Update in Richtung Stabilität bringt, kann ich naturgemäß noch nicht sagen. Der Text oben ist von jemandem verfasst, der von Programmieren praktisch null Ahnung hat. Die Default-Verschaltung ab 0.4.20 habe ich mit angehängt.
:
Bearbeitet durch User
Kannst du die neue -.bin auch raufladen? Bei mir funzt das mit platformIO nicht
hab vorhin gerade die 0.4.22 drauf gespielt. die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der seriele debug print weiter läuft auch wenn der d1 mini per netzwerk nicht mehr erreichbar ist?
Angehängte Dateien:
-
20220623_203049.jpg
220 KB -
20220623_203039.jpg
230 KB
Daniel R. schrieb: > Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann... > dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und > Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine > kleine Bezahlung?). Das war eigentlich mein Plan. Also eine Platine layouten, fertigen lassen und für die die nicht löten wollen/können würde ich die auch bestücken und alles in eine feines Gehäuse packen um das Ganze dann für Selbstkostenpreis + kleiner Aufwandsentschädigung anzubieten. Nun habe ich die Platine ja schon fertig, und zur Probe mal eine selbst geätzt und bestückt. Leider hat sich herausgestellt das der Empfang sehr viel schlechter ist als mit der Breadboard Version :( Dann habe ich die Schirmung des RF24 entfern, keine Besserung. Dann habe ich das Netzteil entfernt und per USB versorgt, keine Besserung. Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt positioniert, keine Besserung. Die Platine unter Lupe natürlich optisch auf Fehler untrsucht, durchgemessen, nix zu finden. Den RF ausgetauscht, keine Besserung. Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern muss damit es so gut funktioniert wie auf dem Steckbrett. Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört die Massefläche der Platine ? Ich komm nicht weiter ...
Holger S. schrieb: > Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört > die Massefläche der Platine ? Ich habe mir als purer Anfänger meine Platinen bei Aisler "schnitzen lassen" - funktionieren problemlos ohne Empfangsprobleme. Ich habe den D1 direkt neben dem NRF24l01+ (nicht über) und dachte mir erst "das geht schief" - tut was es soll ohne große Schirmung. Entweder die wirklich "räumliche Nähe" oder die Massefläche
tom schrieb: > hab vorhin gerade die 0.4.22 drauf gespielt. > die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der > seriele debug print weiter läuft auch wenn der d1 mini per netzwerk > nicht mehr erreichbar ist? kann es sein das die probleme vom webserver kommen? wenn ich ganz oft die webseite aktualisiere fällt die netzwerkverbindung bei mir aus. ist das bei euch auch?
Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update (vor knapp 4 Std.) stabil.
Rene M. schrieb: > Kannst du die neue -.bin auch raufladen? > Bei mir funzt das mit platformIO nicht Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine erste CI (GitHub Actions), die nach dem Commit von Code die Firmware automatisch baut und sogar als Artifakt zum Download zur Verfügung stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90 Tage, dann werden die automatisch gelöscht. Hier z.B. das von gestern: https://github.com/grindylow/ahoy/actions dann auf den obersten Eintrag klicken, ganz unten erscheint dann das Artifakt
:
Bearbeitet durch User
Günter H. schrieb: > Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update > (vor > knapp 4 Std.) stabil. das hatte ich auch schon probiert, leider ohne verbesserung, auch mit 60s hab ich probiert
Angehängte Dateien:
Günter H. schrieb: > Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update (vor > knapp 4 Std.) stabil.
Holger S. schrieb: > > Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang > bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m > Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern > muss damit es so gut funktioniert wie auf dem Steckbrett. > Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört > die Massefläche der Platine ? > > Ich komm nicht weiter ... Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit 2,4Ghz !! Nebeneinander mit Abstand und der Variante ein Blech das man dazwischen einlöten kann. Und den Wemos gleich mit Pigtail für externe Antenne nehmen. Die kurzen Leiterbahnen vom Chip zur Antenne strahlen ja auch schon was aus.
Hallo Holger S., wenn ich mir die Erfahrungen / Kommentare zu Deiner Platine und den Aufbau der Anderen durchlese fällt mir auf, daß nur Du auch den AC/DC Transformator und den Spannungsregler mit auf der Platine hast. Hast Du Dir mal die Spannung am ESP mit einem Oszi angeschaut ? Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat. Sind ja immerhin 50Hz ?
Holger S. schrieb: > Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang > bei meinem Aufbau. Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden. Trotzdem könnte ich mir das vorstellen. Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch? Ok, Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D
:
Bearbeitet durch User
Hallo Holger, hast du schlechten Empfang oder gar keinen Empfang? Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen ob die Verbindung auf deiner Platine stimmt. Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht sehr knapp aus. Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand zwischen der 230V AC Seite zur Niederspannungsseite. Der 230V AC Bereich sollte eindeutig von der Niederspannungsseite getrennt sein. Wenn ich mich recht erinnere, muss man hier 8mm Abstand einhalten. Am besten den Stabi mit Elko zwischen ESP und Netzteil-Modul positionieren. Evtl. auch das Netzteil um 90 Grad drehen. Und die Sicherung auf der AC Seite nicht vergessen, außer du hast sie in der Netz-Leitung integriert.
Lukas P. schrieb: > Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine > erste CI (GitHub Actions), die nach dem Commit von Code die Firmware > automatisch baut und sogar als Artifakt zum Download zur Verfügung > stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90 > Tage, dann werden die automatisch gelöscht. > > Hier z.B. das von gestern: > https://github.com/grindylow/ahoy/actions > > dann auf den obersten Eintrag klicken, ganz unten erscheint dann das > Artifakt Danke für diesen Hinweis, das ist ein sehr einfacher und schneller Zugang zur aktuellen bin-Datei. Ergänzung: Man muss bei guthub angemeldet sein, um das Artifakt herunterladen zu können.
Holger S. schrieb: > Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang > bei meinem Aufbau. Wenn man sich das Layout anguckt fällt mir etwas auf: Der Elko ist völlig nutzlos. Dieser gehört nicht irgendwo auf die Leiterplatte, sondern nach an den NRF24L01+. Die 6mm Abstand (oder Fräsung) zwischen 230V und Niederspannung wurden schon erwähnt. Sind aber nicht die Ursache deines Problems. Wenn du deine Layout datein mit uns teilst können wir noch mehr tipps geben.
Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT mit zu übertragen? Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen anderen Weg...?
Holger S. schrieb: > Ich weiß nicht was ich verändern > muss damit es so gut funktioniert wie auf dem Steckbrett. Disclaimer: Ich habe weder beruflich noch in der Ausbildung mit Platinen oder Schaltungen zu tun! Hallo Holger, wenn ich das richtig erkannt habe, dann finde ich die GND-Verbindung vom RF24 nicht optimal. Die geht auf den Fotos nur durch das GND-Pad vom Wemos. Ob die Empfangsprobleme damit zu tun haben, könnte man mit einer schnellen Kabelbrücke testen. Und dann wollen doch die meisten LDO auch noch einen Kondensator am Ausgang. Gerade die RF24 scheinen doch relativ empfindlich auf die Restwelligkeit zu reagieren. Hatte ich so zumindest beim Mitlesen für mich rausgeschlossen. Aber beides nur spontane Ideen eines Hobbyisten. Gruß Axel
Angehängte Dateien:
Ist da GND und 3,3V wirklich getrennt?
Daniel R. schrieb: > Holger S. schrieb: >> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang >> bei meinem Aufbau. > > Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken > sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden. > Trotzdem könnte ich mir das vorstellen. > > Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und > platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch? > > Ok, Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit Reboots) mit dem WR. Distanz zum WR ca. 15m. https://www.mikrocontroller.net/attachment/560492/DE6F5772-A240-4F90-AB27-12E40A65CEF2.jpeg
hat schon jemand versucht den webserver mal abzuschalten und schauen ob der d1 mini dann immer noch neustartet?
Peter L. schrieb: > Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen > Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT > mit zu übertragen? > > Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man > beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen > anderen Weg...? ioBroker hat für jedes Objekt mehrere Timestamps, zB wann es erzeugt wurde und wann es zuletzt aktualisiert wurde. Ich kann mir vorstellen, dass sich andere Systeme hier genauso verhalten und sehe daher keine Notwendigkeit den timestamp extra zu schicken. @Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt: https://github.com/grindylow/ahoy/issues/83
:
Bearbeitet durch User
Stefan T. schrieb: > Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und > dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du > ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat. > Sind ja immerhin 50Hz ? Zitat aus meinem Post: "Dann habe ich das Netzteil entfernt und per USB versorgt, keine Besserung." Daniel R. schrieb: > Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und > platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch? Richard K. schrieb: > Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit > 2,4Ghz !! Zitat aus meinem Post: "Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt positioniert, keine Besserung." Claus T. schrieb: > hast du schlechten Empfang oder gar keinen Empfang? > Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich > das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen > ob die Verbindung auf deiner Platine stimmt. > Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung > von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da > sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht > sehr knapp aus. > Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand > zwischen der 230V AC Seite zur Niederspannungsseite. Der Empfang ist da, aber es werde sehr viele Fails erzeugt und von den 6 Invertern sind meist nur 2 available. Die Leiterbahnen sind OK. Das ist schlecht zu fotografieren. Aber unter der Lupenlampe nochmal gecheckt und durchgemessen hatte ich das ja auch. Das hätte auch gleich smoke gegen wenn da ne Verbindung ist. Der Aufbau funktioniert ja auch, nur der Empfang taugt nix. Den Abstand 230V werde ich noch vergrößern. Wahrscheinlich lasse ich das on Board Netzteil wohl auch weg. Ich dachte es wäre ne gute Idee, aber wenn ich den Wemos und den RF24 nebeneinander setzten muß, und die Abstände vergrößern soll, wird mir das ganze schon wieder zu groß und muß in ein anderes Gehäuse. Dann eben nicht kompakt und mit extra USB Nezteil. Peter L. schrieb: > Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit > Reboots) mit dem WR. Distanz zum WR ca. 15m. Tja, deshalb bin ich ja so Ratlos.
Dear All, At first let me express my respect to all who contributes to this topic. I am follwing this thread since a while and I am using the pre-compiled version 0.4.19 on a Wemos D1 mini clone anf HM-800 inverter and Home Assistant. The pre-compiled image works for me only when I use pins D2/D1 instead of D4/D3 for signal CE/IRQ. Hello Marcel, I am trying to compile your ESPhome version on a 8266 (Wemos D1 mini clone) ESPHome version: 2022.5.1 I am facing with an issue defining the serial number of the inverter. If I set the serial number as a hex number ( 12 digit decimal number converted to hex) like in your example file:
1 | serialnumber: "0x1234567890" |
then the ESPhome enters to a boot loop with the following output on the console:
1 | [C][api:025]: Setting up Home Assistant API server... |
2 | [D][hoymiles.esp32:046]: Setting up Hoymiles Component |
3 | E: inverter type can't be detected! |
4 | [I][hoymiles.esp32:065]: Adding Inverter: hm800 ( 0x0 ) |
5 | I: RF24 Amp Pwr: RF24_PA_I: LOW |
6 | I: Radio Config: |
7 | SPI Frequency = 1 Mhz |
8 | Channel = 3 (~ 2403 MHz) |
9 | RF Data Rate = 250 KBPS |
10 | RF Power Amplifier = PA_LOW |
11 | RF Low Noise Amplifier = Enabled |
12 | CRC Length = 16 bits |
13 | Address Length = 5 bytes |
14 | Static Payload Length = 32 bytes |
15 | Auto Retry Delay = 250 microseconds |
16 | Auto Retry Attempts = 0 maximum |
17 | Packets lost on |
18 | current channel = 0 |
19 | Retry attempts made for |
20 | last transmission = 15 |
21 | Multicast = Disabled |
22 | Custom ACK Payload = Disabled |
23 | Dynamic Payloads = Enabled |
24 | Auto Acknowledgment = Disabled |
25 | Primary Mode = RX |
26 | TX address = 0xdeadbeef01 |
27 | pipe 0 (closed) bound = 0xdeadbeef01 |
28 | pipe 1 ( open ) bound = 0x1234567801 |
29 | pipe 2 (closed) bound = 0xc3 |
30 | pipe 3 (closed) bound = 0xc4 |
31 | pipe 4 (closed) bound = 0xc5 |
32 | pipe 5 (closed) bound = 0xc6 |
33 | [I][hoymiles.sensor:010]: Sensor hm800, ▒H#@ |
34 | [I][app:062]: setup() finished successfully! |
If I set it as a decimal number (as it is printed on the HW, either with or without quotes):
1 | serialnumber: "114180445566" |
then it does not enter the boot loop, but prints the following:
1 | [D][hoymiles.esp32:046]: Setting up Hoymiles Component |
2 | E: inverter type can't be detected! |
3 | [I][hoymiles.esp32:065]: Adding Inverter: hm800 ( 0x7fffffff ) |
4 | I: RF24 Amp Pwr: RF24_PA_I: LOW |
5 | I: Radio Config: |
6 | SPI Frequency = 1 Mhz |
7 | Channel = 3 (~ 2403 MHz) |
8 | RF Data Rate = 250 KBPS |
9 | RF Power Amplifier = PA_LOW |
10 | RF Low Noise Amplifier = Enabled |
11 | CRC Length = 16 bits |
12 | Address Length = 5 bytes |
13 | Static Payload Length = 32 bytes |
14 | Auto Retry Delay = 250 microseconds |
15 | Auto Retry Attempts = 0 maximum |
16 | Packets lost on |
17 | current channel = 0 |
18 | Retry attempts made for |
19 | last transmission = 15 |
20 | Multicast = Disabled |
21 | Custom ACK Payload = Disabled |
22 | Dynamic Payloads = Enabled |
23 | Auto Acknowledgment = Disabled |
24 | Primary Mode = RX |
25 | TX address = 0xdeadbeef01 |
26 | pipe 0 (closed) bound = 0xdeadbeef01 |
27 | pipe 1 ( open ) bound = 0x1234567801 |
28 | pipe 2 (closed) bound = 0xc3 |
29 | pipe 3 (closed) bound = 0xc4 |
30 | pipe 4 (closed) bound = 0xc5 |
31 | pipe 5 (closed) bound = 0xc6 |
32 | [I][hoymiles.sensor:010]: Sensor hm800, ▒H#@ |
33 | [I][app:062]: setup() finished successfully! |
What am I doing wrong?
Beitrag #7121184 wurde vom Autor gelöscht.
Zsolt Z. schrieb:
Hello Zsolt, you can try this. I don´t know if it is working so.
Example (see hmRadio.h)
// Serial WR : 1141 74 11 22 33 Label on Inverter
try
// #define WR1_RADIO_ID ((uint64_t)0x 33 22 11 74 01ULL)
only for better readable for your eyes
// #define WR1_RADIO_ID ((uint64_t)0x 74 11 22 33 01ULL)
only for better readable for your eyes
(see hmRadio.h)
// in Source Code
#define WR_RADIO_ID ((uint64_t)0x3322117401ULL)
// OR try
#define WR_RADIO_ID ((uint64_t)0x7411223301ULL)
You have to change the example to YOUR serial number.
:
Bearbeitet durch User
Holger S. schrieb: > Stefan T. schrieb: > Daniel R. schrieb: > Richard K. schrieb: > Claus T. schrieb: > Peter L. schrieb: > Tja, deshalb bin ich ja so Ratlos. Hallo Ich hatte lange auch ab und zu den ganzen Tag Empfang Probleme mit Wemos, ich verwende meine spez. SW-Version auf Hubi's Basis. Ich habe es lange gemessen und gesnifft, das Problem war nicht die HW ! (Edit: ich dachte auch mal die NRF sind futsch..) - Ich würde mal die SW ohne Interrupt mit polling und ohne CRC ausprobieren. Ich bin ziemlich sicher, dass mit Interrupt etwas verloren geht, warum weiss ich nicht. Mit CRC geht vieles auch verloren. Ohne CRC sind die Werte fast 97% richtig, die Falschen kann man ausfiltern. - Ich bin auch ziemlich sicher, dass die WR's nicht immer auf CH3 senden, die SW muss beim RX auch hoppen. Mein MI-1500 sendet manchmal einen Tag lang nur über CH61/CH75. Wenn die SW nur auf CH3 hört, siehst du den ganzen Tag nichts! Edit: versucht mal mit einer NRF24 Sniffer SW ob ihr mit der Dose etwas empfaengt?
:
Bearbeitet durch User
Hallo Zusammen, erstmal vielen Dank für die tolle Arbeit hier. Mein Setup: - DTU-Lite - HM1500 - 4 Module - HM800 - 2 Module - weitere 4 HM1500 kommen noch dazu An meinem DTU-Lite habe ich über die Cloud alles verbunden mit dem HM1500. Leider kann der DTU ja nur 4 Module, deshalb bin ich jetzt auf die 8266/RF24 Lösung gestoßen und habe dieses gleich umgesetzt. Bisher läuft dieses, aber wenn ich den DTU-Lite und den 8266 am laufen haben, dann erhalte ich vom HM1500 oft keine Daten. Der HmM800 hat diese Probleme nicht. Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite hängt und dadurch irgend welche Daten verloren gehen. Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem? Vielen Dank Gruß
Denny S. schrieb: > - DTU-Lite > - HM1500 - 4 Module > - HM800 - 2 Module ... > Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem? Du kannst ja auch nicht 2 PKWs gleichzeitig fahren :-) Vermutlich hat der HM1500 Probleme mit 2 DTUs zu kommunizieren ? 1. Möglichkeit: DTU-Lite Stromversorgung kappen - also aus das Teil 2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und dann schauen, ob das dann funktioniert. Wenn ich nix überlesen habe, hat das wohl noch niemand probiert. Also zack und los :-) Du darfst als Erster :-) Bin selbst gespannt. Viel Erfolg !
Variante 1 geht, aber ich würde gerne beides nutzen. Eine DTU-Pro habe ich schon geordert, damit ich in Zukunft alle HM's auslesen kann. Wieviele HM's kann der 8266 mit AHOY gleichzeitig lesen? Hat das jemand mal getestet? Variante 2 hatte ich schon probiert, aber dann bekomme ich überhaupt keine Daten mehr. Kann aber auch sein das ich mit der Seriennummer was falsch gemacht habe. Diese beginnt mit: 10D98015XXXX Muss ich diese 1zu1 in die Zeile kopieren? #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL) Danke
schau heute um 10:25. Da hab ich geschrieben wie die SN einzutragen ist. Die letzten 4 Zahlenpaare der SN. Musst einfach Beides mal probieren. Die Anzahl der WR kannst Du auch irgendwo konfigurieren vor dem Übersetzen.
:
Bearbeitet durch User
Herbert K. schrieb: > 2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see > hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und > dann schauen, ob das dann funktioniert. So hab ich die DTU-Pro<>MI-1500 gesnifft, schon am Anfang des Projekts. Wenn du die gleiche Adresse eingibst wie die DTU, kannst alles mithören was der WR sendet.
Denny S. schrieb: > Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite > hängt und dadurch irgend welche Daten verloren gehen. Der WR hat keine Ahnung von der Cloud, nur die DTU haengt an der. Zum parallel Betrieb, siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
tom schrieb: > hat schon jemand versucht den webserver mal abzuschalten und schauen ob > der d1 mini dann immer noch neustartet? Lukas P. (lumapu) schrieb: > @Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen > Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt: > https://github.com/grindylow/ahoy/issues/83 Ich persönlich glaube, daß die von Tomas B genutzte AsyncWebServer Bibliothek evtl. auch das Problem behebn könnte. Momentan verwenden wir die ESP8266WebServer Library und die blockiert bis die Seite ausgeliefert wurde. Ich habe keine Ahnung wie die AsyncWebServer Bibliothek es genau macht, aber anscheinend kann diese mehrere Requests parallel beantworten und hat dazu so eine Art "Multithreading". Zumindest wird der Listener immer gleich wieder freigegeben und steht dann für weitere Verbindungen zur Verfügung. Vielleicht eine Funktion der AsyncTCP Bibliothek die als Abhängigkeit dazu kommt. @Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266 Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den ESP8266 übersetzen ?
Stefan T. schrieb: > @Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266 > Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den > ESP8266 übersetzen ? ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist so out of the Box wohl nicht möglich, da ich diverse Compiler und Linker Features verwende die im Toolkit vom 8266 nicht vorhanden sind.
Denny S. schrieb: > Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite > hängt und dadurch irgend welche Daten verloren gehen. Moin, ich habe einen HM-1500 und frage ihn alle 10s mit ESP8266 und ESP32 ab, unterschiedliche DTU-ID's, keine Probleme. Dem WR ist es eigentlich egal, er antwortet stumpf. Das was ich mir vorstellen kann, das er Probleme hat mit unterschiedlichen Zeitframes, die er bekommt oder die Abfragen zu schnell nacheinander kommen. Bei meine TSUN-DTU sehe ich im Sekundentakt abfragen, vielleicht kollidiert es da, HM und TSUN sind ja quasi identisch. Kannst du einfach mal deine DTU für ein paar Minuten trennen und schauen, ob es dann geht?
Hallo, ja wenn der DTU aus ist, gehen keine Daten verloren. Ist der DTU an, sieht man gut das nur der HM1500 hin und wieder keine Daten erhält (hängt am DTU), aber der HM800 (nur über AHOY) immer alles korrekt ist. Das mit der DTU Seriennummer ändern im AHOY habe ich auch probiert, aber dann geht nix mehr. Vielleicht geht das mit der DTU-Pro dann besser.
Thomas B. schrieb: >> könnte man auch Deinen OpenDTU Code für den ESP8266 übersetzen ? > ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist so out of the Box wohl nicht möglich, da ich diverse Compiler und Linker Features verwende die im Toolkit vom 8266 nicht vorhanden sind. Hallo Thomas, das habe ich gesehen vor allem das std::bind() für die Interrupt Handler will er bei mir partout nicht übersetzen. Ich habe es aber auch nicht hinbekommen die Interrupthandler außerhalb der Klassenbzu definieren. Das scheint dem ESP8266 Cross Compiler nicht zu gefallen. Das andere sind glaube ich div. Datentypen die beim ESP8266 etwas anders sind. Soll ich Dir die bereits gemachten Anpassungen irgendwie per PR zukommen lassen ?
Hallo Denny S., ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn Du das Abfrageintervall auf einen größeren Zeitraum stellst könnte es evtl klappen aber mE bringst Du damit die Payload Decodierung aus dem Tritt, weil er ja per Interrupt Pakete bekommt die er evtl grade gar nicht erwartet. Im DTU Code von Hoymiles sind zwar einige Bedingungen für falsche Pakete (out-of-order) definiert die dann ggf. einen Abbruch der Verbindung und ein sog. NET_INIT (ich glaube unser Zeit senden Paket) auslösen. Aber auch im Ahoy-ESP8266 code schon alle Eventualitäten berücksichtigt sind wage ich zu bezweifeln. Der Hoymiles Code wartet auch max 300-500ms auf eine Antwort, da gibt es eine ausführliche Methode die für jede Anfrage die sog LOCAL_TIME berechnet bevor die Anfrage bzw Antwort verworfen wird und eine neue Anfrage gestellt wird. Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum Ahoy-ESP zu betreiben ? Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst ?
@Lukas evtl könnten wir ein sog Promiscuous Feature in die AHOY-ESP Software einbauen, bei dem er selbst keine Anfragen sendet aber ankommende Payloads versucht zu dekodieren ? Wäre ein Flag in den Settings je WR und er müsste halt sehen ob er irgendwann das erste Antwort-Paket und alle folgenden mitbekommt. Wenn es nicht klappt kann er die Payload ja auch wieder verwerfen, da er ja kein Retransmit senden kann/soll.
IsnoAhoy schrieb: > ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR > sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn Auf der smiles-cloud kann man einen WR nur 1x registireren, DTU-lite oder DTU-Pro > Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum > Ahoy-ESP zu betreiben ? > Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst > ? DTU-Lite kann nur 4 Module haendeln, ich denke er möchte mehr sehen...
Hallo @All, Lukas und ich diskutieren gerade in https://github.com/grindylow/ahoy/issues/36 und #83 ob wir einen ESP8266 mit 4MB Flash vorraussetzen können und sollen. Die HTML-Seiten und Konfiguration scheint langsam den Flash zu füllen und die Wemos D1 mini ***LITE v1*** mit nur 1MB und einem ESP-07 würde damit als ***unsupported*** rausfallen. Wieviele von Euch nutzen den ESP-07 bzw. einen Wemos D1 mini in der ***LITE v1*** mit nur einem 1MB Flash ? Bitte im o.g. Github issue #36 und/oder #83 melden, damit wir die Auswirkung dieser Änderung abschätzen können. Danke!
@Ziyat T., danke für den Hinweis es scheint sich in #91 heraus zu kristallisieren, daß wir alle Antwort-Pakete ( egal für welche DTU ) die wir empfangen auch versuchen in die Payloadstruktur zu integrieren. Wir sollten hier also einen Plausibilitätscheck der DTU Addresse einbauen, außer wir sind im o.g. Promiscuous Mode. Sonst kommen wir mit den Antworten für die echte DTU und denen auf unsere Anfragen durcheinander. Siehe https://github.com/grindylow/ahoy/issues/91 @Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und eine original DTU (Lite/Pro) verwenden willst ? Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ?
> @Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und > eine original DTU (Lite/Pro) verwenden willst ? > Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ? Limitieren eines HoyMiles geht noch immer nicht :(
Moin Zusammen, IsnoAhoy schrieb: > Hallo Denny S., > ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR > Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum > Ahoy-ESP zu betreiben ? Eigentlich erstmal nur Testweise. Ich möchte alle Werte aus der Anlage gerne in ioBroker haben. Das geht mit dem DTU-Lite leider überhaupt nicht, deshalb hatte ich mir einen DTU-Pro + Energiemesser bestellt (kommt aber erst Ende Juli). Dann bin ich auf dieses Projekt gestoßen. Ohne DTU-Lite am Netz könnte ich eigentlich auf AHOY umstellen, aber dann geht mir aktuell die Aufbereitung der Daten in der Hoymiles Cloud flöten. > Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst > ? Also wenn ich schon so gefragt werde :-) Was haltet ihr von einer Berechnung der Gesamtwerte der Anlage, also wenn mehrere WR eingebunden sind und die Daten ebenfalls gleich über MQTT raus schicken? Weitere Punkte fallen mir bestimmt noch ein. :-) Gruß
Dieser Thread ist ja damit gestartet das man versucht die Daten von Hoymiles auszulesen. Das ist ja eigentlich geschafft und dieser Thread wird ja mehr und mehr zum Support Thread mit sehr vielen gleichen Fragen und langer ladezeit. Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll diskussion entstehen? Ich habe leider keine DTU und kann somit auch keine Daten sniffen. Ich kann aber programmieren und kann helfen Sachen zu testen. Wie man ja oben schon sieht, ich bin wirklich an der Limitierung interessiert. Danke Marcel
:
Bearbeitet durch User
Hi Marcel, geht uns doch allen so. :) - Discord Link weiter oben. Ich probiere viel alleine aus. Aber neue Erkentniss habe ich nicht. Eine DTU-pro wäre hier Hilfreich. Gruß Daniel
Marcel A. schrieb: > Dieser Thread ist ja damit gestartet das man versucht die Daten von > Hoymiles auszulesen. Das ist ja eigentlich geschafft Ist meines Erachtens noch nicht geschafft bzw. nur zum Teil. Wir bekommen zwar die "Guten Daten" aber nicht die Bösen, sofern ich nix übersehen habe. Es ist noch gar nix in Richtung Fehler Abfrage erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source eine Fehlerliste entdeckt. > Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten > gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll > diskussion entstehen? Ich bin sehr dafür. Darum hatte ich ja auch schon für HMT, HMS, DTU-Pro-S extra Threads angelegt in der Hoffnung, das sich da auch mal irgendwann jemand einfindet und nicht diesen hier wiederholt kapert. Mit Discord kann ich nix anfangen. Sagt mir nix. Wenn, dann Bitte hier. Nur mir fällt kein Name ein. Vielleicht so? Protokoll Analyse Hoymiles HM-xxxx, MI-xxxx Bits und Bytes Und als 1. Beitrag so was in der Art wie ich bei HMT geschrieben habe evt. Sinngemäß: Kein Support für Entwicklungsumgebungen (kann Source nicht übersetzen usw.) Kein Support zum Flashen der Mikrokontroller Kein Support für MQTT Probleme usw. Dazu bitte den alten Beitrag benutzen: Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hier soll nur über die Analyse der Bits und Bytes diskutiert werden
:
Bearbeitet durch User
Hallo Marcel A. & Herbert K., >> Dieser Thread ist ja damit gestartet das man versucht die Daten von >> Hoymiles auszulesen. Das ist ja eigentlich geschafft > Es ist noch gar nix in Richtung Fehler Abfrage erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source eine Fehlerliste entdeckt. Ich finde den Punkt gut hier im ESP evtl. auch die Fehlerliste abzufragen. Das wäre dann eine neue sendEventLog Routine und dann der entsprechende Payload Decoder. Daniel R., hatte ja schon versucht aufgrund der Hoymiles Code Analyse einige Power Limit Kommandos o.a. an seinen Wechselrichter zu schicken. Ich habe bei mir irgendwo die vier NRF24 Module verlegt und somit nur eines am ESP welches ich aber nicht so flexibel einsetzen kann wie das mit dem Raspberry Pi code von Jan-Jonas geht. Ich hatte m.W. auch schon weiter oben die verschiedenen SubCmds und Events aus dem Hoymiles DTU-Pro code (iotloves) extrahiert: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" The current implementation we use for HM-inverters seems to be in the Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or `usart_nrf3.h`. There also the user data starts with `0x80` in `byte[10]` and after that the Sub Command mentioned in the Excel sheet. According to the implementation in `usart_nrf3.h` the Sub Command is defined as `DataType` in `usart_nrf3.h`:
1 | typedef enum |
2 | {
|
3 | InverterDevInform_Simple = 0, // 0x00 |
4 | InverterDevInform_All = 1, // 0x01 |
5 | GridOnProFilePara = 2, // 0x02 |
6 | HardWareConfig = 3, // 0x03 |
7 | SimpleCalibrationPara = 4, // 0x04 |
8 | SystemConfigPara = 5, // 0x05 |
9 | RealTimeRunData_Debug = 11, // 0x0B |
10 | RealTimeRunData_Reality = 12, // 0x0C |
11 | RealTimeRunData_A_Phase = 13, // 0x0D |
12 | RealTimeRunData_B_Phase = 14, // 0x0E |
13 | RealTimeRunData_C_Phase = 15, // 0x0F |
14 | //RealTimeRunData_Password = 16, // 0x10 |
15 | AlarmData = 17, // 0x11 |
16 | RecordData = 18, // 0x12 |
17 | InternalData = 19, // 0x13 |
18 | ExternalData = 20, // 0x14 |
19 | } DataType; |
Especially the 0x0B rings a bell with me and the traces so far! According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:
1 | #define DEVCONTROL_ALL 0x51 |
2 | #define ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80) |
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" The main routine is in `UsartNrf3_Send_NetCmdToNrfCmd` where all the commands and subcommands are defined, where the Sub Commands are of `DevControlType`:
1 | typedef enum |
2 | {
|
3 | Type_TurnOn = 0, // 0x00 |
4 | Type_TurnOff = 1, // 0x01 |
5 | Type_Restart = 2, // 0x02 |
6 | Type_Lock = 3, // 0x03 |
7 | Type_Unlock = 4, // 0x04 |
8 | Type_ActivePowerContr = 11, // 0x0B |
9 | Type_ReactivePowerContr = 12, // 0x0C |
10 | Type_PFSet = 13, // 0x0D |
11 | Type_CleanState_LockAndAlarm = 20, // 0x14 |
12 | Type_Init = 0xff, // 0xFF |
13 | } DevControlType; |
The AlarmDataType can store up to 20 Alerts as far as I could tell from the `UsartNrf3_Process_DevInform_Alarm` method. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL (REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden SubCmd's definiert als:
1 | typedef enum |
2 | {
|
3 | InverterDevInform_Simple = 0, |
4 | InverterDevInform_All = 1, |
5 | GridOnProFilePara = 2, |
6 | HardWareConfig = 3, |
7 | SimpleCalibrationPara = 4, |
8 | SystemConfigPara = 5, |
9 | RealTimeRunData_Debug = 11, // 0x0B |
10 | RealTimeRunData_Reality = 12, // 0x0C |
11 | RealTimeRunData_A_Phase = 13, // 0x0D |
12 | RealTimeRunData_B_Phase = 14, // 0x0E |
13 | RealTimeRunData_C_Phase = 15, // 0x0F //�澯����-����δ���澯 |
14 | AlarmData = 17, // 0x11 //�澯����-ȫ������澯 |
15 | AlarmUpdate = 18, // 0x12 |
16 | RecordData = 19, // 0x13 |
17 | InternalData = 20, // 0x14 |
18 | GetLossRate = 21, // 0x15 |
19 | //dong 2020-06-15 |
20 | GetSelfCheckState = 30, // 0x1E |
21 | InitDataState = 0xff, |
22 | } DataType; |
Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S. hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert hatten. Interessant ist hier vor allem auch der InitDataState 0xff den der Hoymiles immer wieder sendet um den Wechselrichter in einen definierten Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt. @Daniel R., Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit Funktion zu nutzen ?
Ach ja, wir haben auch schon seit längerem zwei Feature Requests im Github, wenn ihr das lieber nehmen wollt um spezifische Protokoll-Kommandos im Detail zu besprechen: Das hier ist m.E. für die Alarm Data / Update Daten: Use the 0x15 or 0x09 command to query the inverters internal history #77 https://github.com/grindylow/ahoy/issues/77 und das hier sollte das Power Limit behandeln: Feature Erweiterung: Leistungslimitierung (für z.B. geregelter Batteriewechselrichter oder um gesetzliche Grenzen einzuhalten) #31 https://github.com/grindylow/ahoy/issues/31
Herbert K. schrieb:
> Hier soll nur über die Analyse der Bits und Bytes diskutiert werden
Aus meiner Sicht sollten wir es lassen wie es ist:
1. Auch Fragen außerhalb von Bits und Bytes bringen das Projekt
insgesamt weiter,
2. gelingt eine solche "Sortierung" überhaupt (in den neu angelegten
Threads ist bisher kein weiterer Eintrag),
3. die angesprochenen langen Ladezeiten sind bei Auswahl der
Seitentrennung kein Thema.
isnoAhoy schrieb: > Interessant ist hier vor allem auch der InitDataState 0xff den der > Hoymiles immer wieder sendet um den Wechselrichter in einen definierten > Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort > ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt. > > @Daniel R., > Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit > Funktion zu nutzen ? Ui, darauf habe ich gar nicht geachtet! Guter Punkt. Lass mich das später nochmal anschauen, gibt es die Möglichkeit dich außerhalb von µC zu Kontaktieren?
Hallo Daniel R., Dein Discord Invite ist expired. Kannst Du nochmal einen schicken ?
Hallo Wollte mal fragen, ob jemand auch den MI integriert oder überhaupt integrieren wird?
Ich befürworte es, das man versucht alle Versionen zu integrieren. :)
isnoAhoy schrieb: > Dein Discord Invite ist expired. Kannst Du nochmal einen schicken ? https://discord.gg/WzhxEY62mB bitte schön. :)
Daniel R. schrieb: > Ich befürworte es, das man versucht alle Versionen zu integrieren. :) Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben, oder hab ich schon?
isnoAhoy schrieb: > Interessant ist hier vor allem auch der InitDataState 0xff den der > Hoymiles immer wieder sendet um den Wechselrichter in einen definierten > Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort > ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt. > > @Daniel R., > Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit > Funktion zu nutzen ? Habe heute nochmals lange nach gesnifft, meine DTU-Pro sendet definitiv keine InitDataState 0xff zum MI. wenn #define DEVCONTROL_ALL 0x51 für alle gilt müsste ja auch für HM gehen, hmmm??
Ziyat T. schrieb: > Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben, > oder hab ich schon? Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" ist es das hier? Hast du auch Github, dann könntest du es vorerst dort pflegen. Vielleicht kann man später das ganze mergen. Bin aktuell heiß auf die HM Limitierung. :)
Moin, gibt es eine Quelle wo man die Binarys der aktuellen Version downloaden kann?
schaue ein paar Beiträge zurück, da hab ich geschrieben wo in Github diese zu finden sind.
Ziyat T. schrieb: > Daniel R. schrieb: >> Ich befürworte es, das man versucht alle Versionen zu integrieren. :) > > Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben, > oder hab ich schon? Wo liegt deine Version? Wenn es nicht allzu viel Aufwand ist und jemand sich zum Testen bereit erklärt würde ich es mir anschauen, habe selbst keinen MI.
Lukas P. schrieb: > schaue ein paar Beiträge zurück, da hab ich geschrieben wo in Github > diese zu finden sind. Ok, das habe ich gelesen. Der Trick war nur, dass man auf Github eingeloggt sein muss um den Downloadlink zu sehen. Danke!
Lukas P. schrieb: Daniel R. schrieb: > Wo liegt deine Version? Wenn es nicht allzu viel Aufwand ist und jemand > sich zum Testen bereit erklärt würde ich es mir anschauen, habe selbst > keinen MI. Die Quick&Dirty für MI-1500, erwartet bitte keine Qualitaet, auf der Basis v. Hubi! Laeuft auf ESP8266 und ArduiniUNO(ohne WiFi) Im settings.h ist alles einzustellen - Laeuft als Sniffer, wenns definiert (adr 0x00aa, 0x0055, hört alles mit). - Channel hopping auch beim RX - Mit/Ohne Interrupt,CRC zum Testen - hat MQTT (auf meine Art) wenn Wifi, bekommt SmartMeterPower über MQTT - kann über Serielle-SS gesteuert werden: * Befehl 1-1000: Leistungs Limitierung in Watt/ 0:stop limiting * Befehl 2000: serial help * Befehl 2001: WR-Info * BEfehl 2002-2004 : set PA_LEVEL Kann eure SW testen wenn sie auf esp8266 laeuft.
Ziyat T. schrieb: > isnoAhoy schrieb: > >> Interessant ist hier vor allem auch der InitDataState 0xff den der >> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten >> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort >> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt. >> >> @Daniel R., >> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit >> Funktion zu nutzen ? > > Habe heute nochmals lange nach gesnifft, meine DTU-Pro sendet definitiv > keine InitDataState 0xff zum MI. > > wenn > #define DEVCONTROL_ALL 0x51 > für alle gilt müsste ja auch für HM gehen, hmmm?? Hallo Ziyat T., ja Du hast Recht. Das CurRecSendPackageDataType = InitDataState setzt er nur in zwei anderen Fällen und einmal initial. Das mit dem SubCmd = Type_Init (0xff) scheint nur bei * MainCmd = DOWN_PRO (0x0e) oder * MainCmd = DOWN_DAT (0x0a) verwendet zu werden. Bei allen anderen Anfragen erfolgt vorher ein CurNetCmd = NET_INIT, also * MainCmd = REQ_ARW_DAT_ALL (0x15) und * SubCmd = RealTimeRunData_Reality (0x0c) bzw. * SubCmd = RealTimeRunData_Debug (0x0b). Wir verwenden ja schon länger den zweiten Fall 0x0b für die Status Meldungen.
Hallo und vielen Dank für die super Arbeit! Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600 nichts empfangen kann? Irgend ein Depp hat nämlich alles montiert und vorher kein Foto vom Wechselrichter gemacht bzw. das Etikett abgezogen......
Tobias schrieb: > Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600 > nichts empfangen kann? So sieht es aus ! Vielleicht hast Du Glück und es hat die S/N jemand eingescannt und sie steht auf Rechnung / Lieferschein.
Hallo Hubi, habe mit Zufriedenheit die SW-Varianten vom 13.04.22 und 5.06.22 an einem HM800 erprobt. Finde die SW-Lösung vom 13.04.22 wegen der expliziten Darstellung der Werte übersichtlicher als die vom 5.06.22. Habe heute beim Übernehmen der Daten für die E-Woche festgestellt, das auf Grund der 4 Bytes nur maximal 65535 W angegeben werden können. Bei der Aufsummierung der Werte > 65535 springt der Zähler wieder auf 0 und beginnt von neuem. Frage : Ist irgend eine der 4Byte in der Abfrage ein Zähler für die Summierung der Überläufe? weiterhin gutes Gelingen. Fritsche
Auf der Rechnung/Lieferschein finde ich leider keine Seriennummer :-( Na dann, Dummheit muss bestraft werden, also wieder rauf auf's Garagendach ;-) Herbert K. schrieb: > Tobias schrieb: >> Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600 >> nichts empfangen kann? > > So sieht es aus ! Vielleicht hast Du Glück und es hat die S/N jemand > eingescannt und sie steht auf Rechnung / Lieferschein.
@Tobias, laut Hersteller soll es eine Scan Funktion geben. Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann kein Problem mehr sein. :)
Daniel R. schrieb: > @Tobias, laut Hersteller soll es eine Scan Funktion geben. > Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann > kein Problem mehr sein. :) DAS wäre natürlich was. Ich kapiere das mit den shockburst vom nrf zwar nicht, aber ich könnte mir als Laie schon vorstellen, dass der Wechselrichter seine Seriennummer irgendwie "broadcasted". Bei den nrf-Sniffern die ich hier verlinkt fand, war allerdings die Eingabe der Seriennummer Voraussetzung.
Das ist richtig, da wir Thema Scan noch nicht implemtiert haben/können. Ich bin gerade die Alarme auszulesen und konnte schonmal Erfolg verbuchen! :) Habe mit isnoahoy folgende Beiträge durchgesichtet und diese auch probiert: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Und tatsächlich konnte ich Payloads erhalten. Es gibt nur ein Problem: Wenn ich auf Kanal 3 oder 75 sende, bekomme ich bessere Ergebnise. Bei zuvielen Retransmits, bricht der skript ab und fängt von neu an... Hier jetzt mal mein Ergebnis (noch nicht analysiert!):
1 | Poll inverter 116174403329 |
2 | Transmit 27 | 15 74 40 33 29 78 56 34 12 80 11 00 62 7b 69 fe 00 00 00 00 00 00 00 00 47 d7 bc |
3 | Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 01 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 c4 |
4 | Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 02 00 04 62 2e 00 00 00 00 00 00 00 d2 00 05 62 2e 44 |
5 | Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 03 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 66 |
6 | Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 04 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 22 |
7 | Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 05 00 0d 62 2e 69 fd 00 00 00 00 80 02 00 22 6c a4 2d |
8 | Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 06 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff ff |
9 | Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 07 ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 f0 |
10 | Error while retrieving data: Missing packet: Last packet 7 |
11 | |
12 | Transmit 11 | 15 74 40 33 29 78 56 34 12 88 bb |
13 | Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 08 00 25 6c f1 6c f1 ff ff ff fb 80 02 00 26 6c fb 8f |
14 | Error while retrieving data: Missing packet: Last packet 8 |
15 | |
16 | Transmit 11 | 15 74 40 33 29 78 56 34 12 89 ba |
17 | Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 09 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff a7 |
18 | |
19 | Error while retrieving data: Missing packet: Last packet 9 |
20 | Transmit 11 | 15 74 40 33 29 78 56 34 12 8a b9 |
21 | Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 0a ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 a2 |
22 | Error while retrieving data: Missing packet: Last packet 10 |
23 | |
24 | Transmit 11 | 15 74 40 33 29 78 56 34 12 8b b8 |
25 | Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 0b 00 29 6d 27 6d 27 ff ff ff fb 80 02 00 2a 6d 32 44 |
26 | Error while retrieving data: Missing packet: Last packet 11 |
27 | |
28 | Transmit 11 | 15 74 40 33 29 78 56 34 12 8c bf |
29 | Received 19 bytes channel 23: 95 74 40 33 29 74 40 33 29 8c 6d 32 ff ff ff f5 53 03 1c |
30 | |
31 | Payload: 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 00 04 62 2e 00 00 00 00 00 00 00 d2 00 05 62 2e 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 00 0d 62 2e 69 fd 00 00 00 00 80 02 00 22 6c a4 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 00 25 6c f1 6c f1 ff ff ff fb 80 02 00 26 6c fb 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 00 29 6d 27 6d 27 ff ff ff fb 80 02 00 2a 6d 32 6d 32 ff ff ff f5 53 03 |
32 | payload has valid modbus crc |
@friedhelm E. hol dir die neuste Version von git-hub hm-soft/hoydtusim. Das sollte klappen.
Das einzige was bei mir nicht passt: Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
1 | payload has valid modbus crc |
2 | 80 01 00 01 62 26 62 26 00 00 00 00: |
3 | uptime=6:58:46 a_count=1 opcode=128 a_code=1 a_text=Inverter start |
4 | BBHHHHH: (128, 1, 1, 25126, 25126, 0, 0) |
5 | 00 d1 00 04 62 2e 00 00 00 00 00 00: |
6 | uptime=6:58:54 a_count=4 opcode=0 a_code=209 a_text=Port 1 no input |
7 | BBHHHHH: (0, 209, 4, 25134, 0, 0, 0) |
8 | 00 d2 00 05 62 2e 00 00 00 00 00 00: |
9 | uptime=6:58:54 a_count=5 opcode=0 a_code=210 a_text=Port 2 no input |
10 | BBHHHHH: (0, 210, 5, 25134, 0, 0, 0) |
11 | 00 cf 00 06 63 5a 00 00 00 00 00 dc: |
12 | uptime=7:03:54 a_count=6 opcode=0 a_code=207 a_text=Input port 1 & 2 undervoltage |
13 | BBHHHHH: (0, 207, 6, 25434, 0, 0, 220) |
14 | 40 8f 00 0c 62 2e 69 fd 00 03 07 a3: |
15 | uptime=6:58:54 a_count=12 opcode=64 a_code=143 a_text=Grid undervoltage |
16 | BBHHHHH: (64, 143, 12, 25134, 27133, 3, 1955) |
17 | 40 93 00 0d 62 2e 69 fd 00 00 00 00: |
18 | uptime=6:58:54 a_count=13 opcode=64 a_code=147 a_text=Power grid outage |
19 | BBHHHHH: (64, 147, 13, 25134, 27133, 0, 0) |
20 | 80 02 00 22 6c a4 6c a4 ff ff ff fa: |
21 | uptime=7:43:32 a_count=34 opcode=128 a_code=2 a_text=DTU command failed |
22 | BBHHHHH: (128, 2, 34, 27812, 27812, 65535, 65530) |
23 | 80 02 00 23 6c ab 6c ab ff ff ff f9: |
24 | uptime=7:43:39 a_count=35 opcode=128 a_code=2 a_text=DTU command failed |
25 | BBHHHHH: (128, 2, 35, 27819, 27819, 65535, 65529) |
26 | 80 02 00 24 6c ec 6c ec ff ff ff bf: |
27 | uptime=7:44:44 a_count=36 opcode=128 a_code=2 a_text=DTU command failed |
28 | BBHHHHH: (128, 2, 36, 27884, 27884, 65535, 65471) |
29 | 80 02 00 25 6c f1 6c f1 ff ff ff fb: |
30 | uptime=7:44:49 a_count=37 opcode=128 a_code=2 a_text=DTU command failed |
31 | BBHHHHH: (128, 2, 37, 27889, 27889, 65535, 65531) |
32 | 80 02 00 26 6c fb 6c fb ff ff ff f6: |
33 | uptime=7:44:59 a_count=38 opcode=128 a_code=2 a_text=DTU command failed |
34 | BBHHHHH: (128, 2, 38, 27899, 27899, 65535, 65526) |
35 | 80 02 00 27 6d 18 6d 18 ff ff ff e3: |
36 | uptime=7:45:28 a_count=39 opcode=128 a_code=2 a_text=DTU command failed |
37 | BBHHHHH: (128, 2, 39, 27928, 27928, 65535, 65507) |
38 | 80 02 00 28 6d 22 6d 22 ff ff ff f6: |
39 | uptime=7:45:38 a_count=40 opcode=128 a_code=2 a_text=DTU command failed |
40 | BBHHHHH: (128, 2, 40, 27938, 27938, 65535, 65526) |
41 | 80 02 00 29 6d 27 6d 27 ff ff ff fb: |
42 | uptime=7:45:43 a_count=41 opcode=128 a_code=2 a_text=DTU command failed |
43 | BBHHHHH: (128, 2, 41, 27943, 27943, 65535, 65531) |
44 | 80 02 00 2a 6d 32 6d 32 ff ff ff f5: |
45 | uptime=7:45:54 a_count=42 opcode=128 a_code=2 a_text=DTU command failed |
46 | BBHHHHH: (128, 2, 42, 27954, 27954, 65535, 65525) |
Tobias schrieb: > Daniel R. schrieb: > Wechselrichter seine Seriennummer irgendwie "broadcasted". Also mein bisheriges Sniffen zwischen DTU-Pro und MI-1500: hab noch nie ein braodcast vom MI gesehen, auch wenn die DTU ausgeschaltet war. An welche Adresse soll broadcastet werden? Der WR ist ohne eine Abfrage quasi tot, zumindestens der MI-1500 (mein Sniffer hört auf "alles" wechselweise auf mehreren kanaelen)
@Ziyat T. Ich habe bisher nur im Manual gelesen das man via Webinterface in der DTU das Umfeld Scannen kann. Damit man weitere Wechselrichter finden kann. Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Daniel R. schrieb: > Das einzige was bei mir nicht passt: > Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" > Die v. Jonas erwaenhte Quelle ist für die HMS Serie !
Daniel R. schrieb: > @Ziyat T. Ich habe bisher nur im Manual gelesen das man via Webinterface > in der DTU das Umfeld Scannen kann. Damit man weitere Wechselrichter > finden kann. > > Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Das ist soweit korrekt, nur auf dem Android-Phone per Installer-APP. Die APP fragt einfach mal alle WR Modelle ab, also es ist nicht richtiges broadcasting, der WR macht also nichts
Angehängte Dateien:
In der Excel steht folgendes, kannst du das mal probieren für MI? Siehe Anhang. Target würde ich mal als DTU sehen, oder? Gongfa steht für: to attack to raid
:
Bearbeitet durch User
Tobias schrieb: > Bei den > nrf-Sniffern die ich hier verlinkt fand, war allerdings die Eingabe der > Seriennummer Voraussetzung. Wenn du auf esp8266 bist kannst du die nehmen als Sniffer, braucht keine WR/DTU Adresse: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" im settings.h "sniffer" einstellen
Beitrag #7127175 wurde vom Autor gelöscht.
Beitrag #7127181 wurde vom Autor gelöscht.
Daniel R. schrieb: > In der Excel steht folgendes, kannst du das mal probieren für MI? > Siehe Anhang. > > Target würde ich mal als DTU sehen, oder? > > Gongfa steht für: > to attack > to raid Ich werde mir das Ding nochmals anschauen Edit: habe vorher eine falsche Antwort geschrieben, ich habe die 0xf implementiert
:
Bearbeitet durch User
Daniel R. schrieb: > @Tobias, laut Hersteller soll es eine Scan Funktion geben. > Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann > kein Problem mehr sein. :) Anbei die ins Englische übersetzten Versionen der usart_nrf.c/.h und usart_nrf3.c/.h aus dem iotloves Gitee repo. Endlich hab ich mal die Zeit gefunden das mal für mich abzuschließen. Ähnlich interessant sind m.E. noch die AntiReflux.c/.h und DRM.c/.h Dateien. Für das G{o,ua}ngfa / Such-Kommando wird folgendes gesetzt:
1 | void UsartNrf_Send_NetCmdToNrfCmd(void) |
2 | ... |
3 | case NET_SEARCH_ID: //Search ID |
4 | MainCmd = BROADCAST; // 0x02 |
5 | SubCmd = 0; // 0x00 |
6 | break; |
1 | void UsartNrf_Send_PackNrfCmd(void) |
2 | ... |
3 | case NET_SEARCH_ID://Search Id (Guangfa command) |
4 | {
|
5 | if(UsartNrf_HasSetCurrentInverterOk()) |
6 | {
|
7 | for(j = Dtu3Detail.Property.PortNum; j < PORT_LEN; j++) |
8 | {
|
9 | memset((u8 *)MIMajor[j].Property.Pre_Id, 0, 2); |
10 | memset((u8 *)MIMajor[j].Property.Id, 0, 4); |
11 | MIMajor[j].Property.Port = MI_NO; |
12 | } |
13 | |
14 | Uart_SendBufferLen = UsartNrf_Send_PackBaseCommand((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, MainCmd, 0); |
15 | } |
16 | |
17 | break; |
18 | } |
1 | u8 UsartNrf_Send_PackBaseCommand(u8 *target_adr, u8 *rout_adr, u8 cmd, u8 dat) |
2 | {
|
3 | vu8 i = 0; |
4 | vu8 temp_dat[UART_LEN]; |
5 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
6 | Uart_SendBuffer[0] = STX;//start // 0x7e |
7 | temp_dat[0] = cmd; //command // MainCmd |
8 | memcpy((u8 *)&temp_dat[1], target_adr, 4); |
9 | memcpy((u8 *)&temp_dat[5], rout_adr, 4); |
10 | temp_dat[9] = dat; |
11 | temp_dat[10] = Get_crc_xor((u8 *)&temp_dat[0], 10); //CRC |
12 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 11); //Forward Substitution |
13 | Uart_SendBuffer[(i + 1)] = ETX; //end |
14 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
15 | return (i + 2); |
16 | } |
Es sollte also mit z.B. als Search Paket gehen: 02 74 40 33 29 78 56 34 12 00 CRC8
Daniel R. schrieb:1 | > 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 00 04 62 2e 00 00 00 00 |
2 | > 00 00 00 d2 00 05 62 2e 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 |
3 | > 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 00 0d 62 2e 69 fd 00 00 |
4 | > 00 00 80 02 00 22 6c a4 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff |
5 | > ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 00 25 6c f1 6c f1 ff ff |
6 | > ff fb 80 02 00 26 6c fb 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff |
7 | > ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 00 29 6d 27 6d 27 ff ff |
8 | > ff fb 80 02 00 2a 6d 32 6d 32 ff ff ff f5 53 03 |
Die Routine um die o.a. Alarm Payload zu dekodieren findet sich in UsartNrf3_Process_DevInform_Alarm(). Es wird immer in 12 byte zusammengefaßt, wobei die ersten beiden die Alarm Version number darstellen:
1 | 00 01 <-- Alarm Version number |
2 | 80 01 00 01 62 26 62 26 00 00 00 00 |
3 | 00 d1 00 04 62 2e 00 00 00 00 00 00 |
4 | 00 d2 00 05 62 2e 00 00 00 00 00 00 |
5 | 00 cf 00 06 63 5a 00 00 00 00 00 dc |
6 | 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 |
7 | 40 93 00 0d 62 2e 69 fd 00 00 00 00 |
8 | 80 02 00 22 6c a4 6c a4 ff ff ff fa |
9 | 80 02 00 23 6c ab 6c ab ff ff ff f9 |
10 | 80 02 00 24 6c ec 6c ec ff ff ff bf |
11 | 80 02 00 25 6c f1 6c f1 ff ff ff fb |
12 | 80 02 00 26 6c fb 6c fb ff ff ff f6 |
13 | 80 02 00 27 6d 18 6d 18 ff ff ff e3 |
14 | 80 02 00 28 6d 22 6d 22 ff ff ff f6 |
15 | 80 02 00 29 6d 27 6d 27 ff ff ff fb |
16 | 80 02 00 2a 6d 32 6d 32 ff ff ff f5 |
17 | |...| |...| |...| |...| |...| |...| |
18 | +2 +3 +4 +5 +6 +7 +8 +9 +10.. +12.. |
19 | <WCode> | | | | |
20 | <WNum>| | | | |
21 | <WarnSerNub>| | | |
22 | <AlarmStartTime> | |
23 | <AlarmEndTime> |
24 | <AlarmData1> |
25 | <AlarmData2> |
Hier die Dekodierung der o.a. Felder:
1 | AlarmId: Alarm_Id[0]), (u8 *)MIMajor[PortNO].Property.Pre_Id, 2); |
2 | Alarm_Id[2]), (u8 *)MIMajor[PortNO].Property.Id, 4); |
3 | |
4 | WCode: WCode = (u16)pProBuffer[i * 12 + 2] << 8 | pProBuffer[i * 12 + 3]; |
5 | WNum: WNum), &(pProBuffer[i * 12 + 4]), 2); |
6 | WarnSerNub: WarnSerNub[PortNO] = (u16)pProBuffer[i * 12 + 4] << 8 | (u16)pProBuffer[i * 12 + 5]; |
7 | WTime1=AlarmStartTime: //Alarm start time |
8 | AlarmTime = (u32)((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7]) + DateToSec(calendar); // AM |
9 | AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7])) + DateToSec(calendar); // PM WCode >> 13) & 0x01) == 1) |
10 | WTime2=AlarmEndTime : //Alarm end time |
11 | AlarmTime = (u32)((u16)pProBuffer[i * 12 + 8] << 8) | ((u16)pProBuffer[i * 12 + 9]) + DateToSec(calendar); // AM |
12 | AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 8] << 8) | ((u16)pProBuffer[i * 12 + 9])) + DateToSec(calendar); // PM WCode >> 12) & 0x01) == 1) |
13 | AlarmData1: Data1[0]), &(pProBuffer[i * 12 + 10]), 2); |
14 | AlarmData2: Data2[0]), &(pProBuffer[i * 12 + 12]), 2); |
Es wird offenbar immer das aktuelle Datum des Tages in Sekunden dazu gezählt und anhand des Bit 13 / 12 im WCode entschieden ob der AlarmStartTime / AlarmEndTime vormittags oder nachmittags liegt/lag. Aus Bit 14 & 15 des WCode wird noch ein sog. Run_Status[0] und [1] extrahiert. Was auch immer das aussagt?
1 | WCode >> 14) & 0x03)) == 0) |
2 | Run_Status[0] = 0x00; |
3 | Run_Status[1] = 0x08; |
4 | |
5 | WCode >> 14) & 0x03) == 1) |
6 | Run_Status[0] = 0x00; |
7 | Run_Status[1] = 0x03; |
@Jan-Jonas S., kannst Du die Punkte mal mit Deinen bisherigen Annahmen (a_code, etc.) überprüfen.
Morgen zusammen, @Jan-Jonas S.: Also den Python Code müssten man irgendwann mal optimieren. :D ABER: Es läuft schonmal zwecks Logs auswertung ziemlich gut!
1 | 2022-07-14 20:08:34.249099 Payload: 00 01 80 01 00 01 4d 02 4d 02 00 00 00 00 00 d1 00 04 4d 0a 00 00 00 00 00 00 00 d2 00 05 4d 0a 00 00 00 00 00 00 00 cf 00 06 4e 36 00 00 00 00 00 dc 40 8f 00 0c 4d 0a 54 d9 00 03 07 a3 40 93 00 0d 4d 0a 54 d9 00 00 00 00 80 02 00 40 6c 85 6c 85 ff ff ff fb 80 02 00 41 6c 8b 6c 8b ff ff ff fa 80 24 00 42 6d 09 6d 09 09 06 eb ec 00 94 00 43 6d 0a 00 00 0f 06 00 00 80 02 00 44 6d 14 6d 14 ff ff ff 77 80 02 00 45 6d 3a 6d 3a ff ff ff da 80 02 00 46 6d 3f 6d 3f ff ff ff fb 80 02 00 47 6d 46 6d 46 ff ff ff f9 80 02 00 48 6d 50 6d 50 ff ff ff f6 06 28 |
2 | payload has valid modbus crc |
3 | 80 01 00 01 4d 02 4d 02 00 00 00 00: |
4 | uptime=5:28:34 a_count=1 opcode=128 a_code=1 a_text=Inverter start |
5 | BBHHHHH: (128, 1, 1, 19714, 19714, 0, 0) |
6 | 00 d1 00 04 4d 0a 00 00 00 00 00 00: |
7 | uptime=5:28:42 a_count=4 opcode=0 a_code=209 a_text=Port 1 no input |
8 | BBHHHHH: (0, 209, 4, 19722, 0, 0, 0) |
9 | 00 d2 00 05 4d 0a 00 00 00 00 00 00: |
10 | uptime=5:28:42 a_count=5 opcode=0 a_code=210 a_text=Port 2 no input |
11 | BBHHHHH: (0, 210, 5, 19722, 0, 0, 0) |
12 | 00 cf 00 06 4e 36 00 00 00 00 00 dc: |
13 | uptime=5:33:42 a_count=6 opcode=0 a_code=207 a_text=Input port 1 & 2 undervoltage |
14 | BBHHHHH: (0, 207, 6, 20022, 0, 0, 220) |
15 | 40 8f 00 0c 4d 0a 54 d9 00 03 07 a3: |
16 | uptime=5:28:42 a_count=12 opcode=64 a_code=143 a_text=Grid undervoltage |
17 | BBHHHHH: (64, 143, 12, 19722, 21721, 3, 1955) |
18 | 40 93 00 0d 4d 0a 54 d9 00 00 00 00: |
19 | uptime=5:28:42 a_count=13 opcode=64 a_code=147 a_text=Power grid outage |
20 | BBHHHHH: (64, 147, 13, 19722, 21721, 0, 0) |
21 | 80 02 00 40 6c 85 6c 85 ff ff ff fb: |
22 | uptime=7:43:01 a_count=64 opcode=128 a_code=2 a_text=DTU command failed |
23 | BBHHHHH: (128, 2, 64, 27781, 27781, 65535, 65531) |
24 | 80 02 00 41 6c 8b 6c 8b ff ff ff fa: |
25 | uptime=7:43:07 a_count=65 opcode=128 a_code=2 a_text=DTU command failed |
26 | BBHHHHH: (128, 2, 65, 27787, 27787, 65535, 65530) |
27 | 80 24 00 42 6d 09 6d 09 09 06 eb ec: |
28 | uptime=7:45:13 a_count=66 opcode=128 a_code=36 a_text=N/A |
29 | BBHHHHH: (128, 36, 66, 27913, 27913, 2310, 60396) |
30 | 00 94 00 43 6d 0a 00 00 0f 06 00 00: |
31 | uptime=7:45:14 a_count=67 opcode=0 a_code=148 a_text=Grid disconnection |
32 | BBHHHHH: (0, 148, 67, 27914, 0, 3846, 0) |
33 | 80 02 00 44 6d 14 6d 14 ff ff ff 77: |
34 | uptime=7:45:24 a_count=68 opcode=128 a_code=2 a_text=DTU command failed |
35 | BBHHHHH: (128, 2, 68, 27924, 27924, 65535, 65399) |
36 | 80 02 00 45 6d 3a 6d 3a ff ff ff da: |
37 | uptime=7:46:02 a_count=69 opcode=128 a_code=2 a_text=DTU command failed |
38 | BBHHHHH: (128, 2, 69, 27962, 27962, 65535, 65498) |
39 | 80 02 00 46 6d 3f 6d 3f ff ff ff fb: |
40 | uptime=7:46:07 a_count=70 opcode=128 a_code=2 a_text=DTU command failed |
41 | BBHHHHH: (128, 2, 70, 27967, 27967, 65535, 65531) |
42 | 80 02 00 47 6d 46 6d 46 ff ff ff f9: |
43 | uptime=7:46:14 a_count=71 opcode=128 a_code=2 a_text=DTU command failed |
44 | BBHHHHH: (128, 2, 71, 27974, 27974, 65535, 65529) |
45 | 80 02 00 48 6d 50 6d 50 ff ff ff f6: |
46 | uptime=7:46:24 a_count=72 opcode=128 a_code=2 a_text=DTU command failed |
47 | BBHHHHH: (128, 2, 72, 27984, 27984, 65535, 65526) |
Meiner Meinung nach müsste man die Log auswertung etwas leserlicher gestalten. Es soll sich so lesen als würde man einfach ein Log AUszug aus dem Webinterface geben. :) Kann jemand mal ein Screenshoot aus einer echten DTU-Webinterface von der Log bereitstellen? @Jan-Jonas S.: Was fehlt hier eigentlich noch, wo müsste man noch etwas analyzieren?
Daniel R. schrieb: > Kann jemand mal ein Screenshoot aus einer echten DTU-Webinterface von > der Log bereitstellen? Ich habe eine DTU Pro. Lokales Webinterface gibt es da keines und in der Cloud sehe ich bei meinem Installer Account keine Möglichkeit ein Log zu sehen.
DTU-Pro hat kein Webinterface? Das ist ja schwach. ^^ Ok aber an sich müsste das Log auslesen irgendwie gehen. Hmm..
Hallo Jan-Jonas, uptime ist tatsächlich ein Zeitstempel also WTime1 / AlarmStartTime, wobei das Bits 13 (Start) des long WCode (d.h. opcode<<8 | a_code) also Bit 5 des opcode bestimmt ob es AM = 0 / PM = 1 ist. Der long Wert hinter uptime ist die WTime2 / AlarmEndTime, hier bestimmt Bit 12 (End) also Bit 4 des opcode ob es AM = 0 / PM = 1 ist. Bit 15 und 14 bestimmen (also Bit 7 und 6 des opcode) wie der RunStatus des Wechselrichters ist (siehe oben). Wir sollten also uptime in starttime umbenennen, die endtime hinzunehmen und die AM/PM Berechnung einbauen. Den RunStatus habe ich noch nicht ganz durchschaut, der wird offenbar auch per ModBus486 und NetProtocol an den Server weitergegeben. Was die WData1 und WData2 in den beiden longs ganz rechts sind, weiß ich auch nicht. Das hängt bestimmt von dem von Dir so genannten a_code ab. BTW: die a_code's können übrigens noch bis zu 12 Bit groß sein. Aber ich denke die Übersetzungstabelle die Du eingebaut hast scheint ganz gut zu funktionieren und die höchsten vier Bit sind offenbar noch nicht vergeben worden.
isnoAhoy schrieb: > und anhand des Bit 13 / 12 im WCode entschieden ob der > AlarmStartTime / AlarmEndTime vormittags oder nachmittags liegt/lag. Wo im Sourcecode siehst du das? Das war mir so anhand der UsartNrf3_Process_DevInform_Alarm Funktion nicht klar.
Hallo Thomas B., Hier mal der erste Teil für die Alarm Start Time mit Bit 13 des WCode (erster long/double Wert einer 12 byte Zeile), der Block wiederholt sich für die Alarm End Time und Bit 12.
1 | //Pending alarm afternoon |
2 | if(((pRealAlarm[RealAlarmDataNO].Data.WCode >> 13) & 0x01) == 1) |
3 | {
|
4 | AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7])) + DateToSec(calendar); |
5 | } |
6 | //Pending alarm morning |
7 | else |
8 | {
|
9 | AlarmTime = (u32)((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7]) + DateToSec(calendar); |
10 | } |
11 | |
12 | //Alarm start time |
13 | pRealAlarm[RealAlarmDataNO].Data.WTime1[0] = AlarmTime >> 24; |
14 | pRealAlarm[RealAlarmDataNO].Data.WTime1[1] = AlarmTime >> 16; |
15 | pRealAlarm[RealAlarmDataNO].Data.WTime1[2] = AlarmTime >> 8; |
16 | pRealAlarm[RealAlarmDataNO].Data.WTime1[3] = AlarmTime; |
D.h. die ersten beiden Bits 15 & 14 des WCode bestimmen den RunStatus und die Bit 13 & 12 bestimmen AM/PM der AlarmStartTime / AlarmEndTime Angaben.
:
Bearbeitet durch User
Hallo Stefan, aus welchem Repo kommt das? Bei mir ist die Bedingung:
1 | if((calendar.hour * 60 * 60 + calendar.min * 60 + calendar.sec) / (12 * 60 * 60) > 0) |
statt
1 | if(((pRealAlarm[RealAlarmDataNO].Data.WCode >> 13) & 0x01) == 1) |
@Thomas B., das ist aus dem iotloves bzw. dem m.W. identischen andycao1860 repos. Im älteren michel_individual_organization war m.W. keine usart_nrf3.c Implementierung aber ich kann mich auch täuschen und die war einfach nur älter. Ich habe mir deswegen den aktuelleren Code angesehen, da dort auch AntiReflux.c und andere schöne Funktionen implementiert sind. Die usart_nrf[3].c/.h Dateien aus dem iotloves hatte ich gestern übersetzt und hier angehängt. Die aus dem michel_individual_organization schon vor einer ganzen Weile ebenfalls hier im Forum.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo allerseits, ich bitte um Nachsicht wenn ich so reinplatze, ich habe diesen Thread zwar schon öfters durchkämmt, konnte aber mein Problem bzw. mein Anliegen nicht so richtig finden, deshalb meine Frage: ich hab die wlan Datenpakete von einem Stick (DTU100W) mitgeschnitten und erhoffe mir darüber die mir wichtigen Informationen, wie Temperatur des Wechselrichters (HM-800) und die PV-Module-Power der einzelnen Panels, auszulesen. Ich bin mir ziemlich sicher, dass die Struktur der Datenpakete schon analysiert worden ist, doch wo könnte ich die finden? Vielen Dank, Hans Ps: der screenshot zeigt eines der typischen Pakete, das sich pro Minute wiederholt. Es geht nicht um den Datenverkehr zwischen WR und irgend einen HW-Client, sondern um den Datenverkehr zwischen DTU und Cloud, den ich abtrennen möchte.
:
Bearbeitet durch User
Java L. schrieb: > Hallo allerseits, ich bitte um Nachsicht wenn ich so reinplatze, ich > habe diesen Thread zwar schon öfters durchkämmt, konnte aber mein ... Hier analysieren wir die Kommunikation zwischen DTU... und HM-xxxx, MI-xxxx. Hier wird NICHT analysiert der Netzwerktraffic zwischen DTU und der S-Miles-Cloud. Bitte mach dafür einen neuen Thread auf falls Dich das Interessiert. Das ist eine ganz andere Baustelle. Danke.
Daniel R. schrieb: > DTU-Pro hat kein Webinterface? > Das ist ja schwach. ^^ > > Ok aber an sich müsste das Log auslesen irgendwie gehen. Hmm.. Wenn wer weiß wie, könnte ich dann, falls es hilft, dahingehend gerne was dazu beitragen
Hallo zusammen, gibt es Wechselrichter bei denen es nicht funktioniert? Hab hier ein HM-600 der irgendwie nicht will. Bei meinem anderen (auch HM-600) funktioniert es ohne Probleme. "Inverter 'TEST' is not available and is not producing" kann evtl eine falsche Seriennummer auf dem WR sein? Kann man die irgendwie anders auslesen? Danke schon mal.
Hallo Java L. wie Herbert schon geschrieben hat geht es hier vorragig um die HM-Wechselrichter <-> DTU lite/Pro Kommunikation. Die Modbus485 und die NetProtocol Kommunination zwischen DTU und Hoymiles Cloud ist hier Off-Topic. Du kannst gerne einen Hinweis/Link auf den Thread hier posten. Das Protokoll sollte mE im NetProtocol.c/.h der einschlägigen gitee Repos definiert sein. Ich habe nur bisher keinen Endpoint entdecken können. Aber vielleicht willst Du ja Deine Ergebnisse mit Wireshark / mitmproxy o.ä. in dem neuen Thread publizieren ?
@isnoAhoy @Daniel R. schrieb: > In der Excel steht folgendes, kannst du das mal probieren für MI? > Siehe Anhang. > > Target würde ich mal als DTU sehen, oder? > > Gongfa steht für: > to attack > to raid Ich hab es probiert, bekomme nichts vom MI. Meine DTU-Pro hat sowas auch nie geschickt, besser gesagt hab nie gesichtet. Was ich nicht ganz verstehe ist, wie soll diese 0x2 als broadcast/search_packet gelten? Normalerweise ist die routing_adress ist ja die WR-Adresse, dann ist ja WR bekannt! Oder welche routing_adress sollte es sein? target_adress ist DTU, das ist klar. Für mich ist die 0x2 einfache WR Abfrage, oder?
A.D. schrieb: > gibt es Wechselrichter bei denen es nicht funktioniert? > Hab hier ein HM-600 der irgendwie nicht will. An diesem Problem hab ich jetzt auch 2 Tage gehangen. Keine Ahnung warum aber mein HM-600 wollte partout nicht antworten wenn er nur auf Kanal 40 angefunkt wird. Mit Kanal 3 und 23 funktioniert es. Ich nehme an du verwendest Ahoy für den ESP8266? Probiere mal ob es funktioniert wenn Du in der hmRadio.h mTxChLst[0] = 40; änderst in Kanal 3 oder 23.
A.D. schrieb: > gibt es Wechselrichter bei denen es nicht funktioniert? > Hab hier ein HM-600 der irgendwie nicht will. Hat sich erledigt. Irgendwann konnte ich ihn dann doch zum "reden" überzeugen :)
Thomas G. schrieb: > Ich nehme an du verwendest Ahoy für den ESP8266? > Probiere mal ob es funktioniert wenn Du in der hmRadio.h > mTxChLst[0] = 40; änderst in Kanal 3 oder 23. Ja, verwende ich. Warum auch immer fing er dann nach nem halben Tag an doch zu kommunizieren. Aber danke trotzdem für den Tipp!!
Hallo Zusammen, finde ich toll was ihr da so angestellt habt. ich versuche mich daran das auf einen ESP32 zu laden habe mich an die Anleitung gehalten in https://github.com/tbnobody/OpenDTU aber Probleme beim aufspielen auf den ESP32. habe 9immer die Fehlermeldung "Der Terminalprozess "C:\Users\Markus\.platformio\penv\Scripts\platformio.exe 'run', '--target', 'upload'" wurde mit folgendem Exitcode beendet: 1. " gruß Markus
Hallo, bin schon seit einer Weile mit Begeisterung den Thread am verfolgen. Da ich momentan ziemlich eingespannt bin kann ich leider nicht aktiv mitwirken. Hätte folgende Fragen: a) Ist die Einspeiselimitierung schon implementiert (z.B. 70%)? b) Wurde schon die Modbusverbindung zu einem Smartmeter (z.B. CHINT 666) eingebunden zwecks z.B. Null-Einspeisung, alternativ z.B. auch Shelly oder andere? Solong B.
SM D. schrieb:
> Hätte folgende Fragen
Einfach Strg F bemühen, ggf. Seitenaufteilung abschalten.
hat jemand eine fertige bin Datei von der aktuellen Version für mich?
tom schrieb:
> hat jemand eine fertige bin Datei von der aktuellen Version für mich?
Hier ist sie.
Ich habe in der AHOY 0.4.20 etwas experimentiert und schreibe die "inverter data" Ausgabe die normalerweise nur über die serielle Schnittstelle kommt zusätzlich auf eine SD Karte. So können Laptop und Router beim loggen ausgeschaltet bleiben. Ich würde gerne für jeden Tag eine neue Datei erstellen, verstehe aber nicht wie ich das aktuelle Datum aus der main.cpp in der app.cpp erhalte. String logFilename = "log"; logFilename += date(); ergibt: 'date' was not declared in this scope String logFilename = "log"; logFilename += year(); ergibt: 1970 Entweder ich bekomme "date" welches in der main.cpp schon berichtigt wird in die app.cpp, oder oder ich schaffe es die NTP Zeit auf die "Arduino time" zu übertragen damit year(), month() etc stimmen. Ja, da scheitert es an Grundlagen, ist mir klar ;-) Wäre trotzdem nett wenn mich jemand in die richtige Richtung schubsen würde.
Könnten Sie bitte eine Quelle für die Bibliothek "dbg.h" für Arduino bereitstellen
Günter H. schrieb: > tom schrieb: >> hat jemand eine fertige bin Datei von der aktuellen Version für mich? > > Hier ist sie. Vielen Dank
Habe es jetzt mit meinem WEMOS D1 mini hinbekommen und werde es morgen testen. Ein diff zum Head 0b9ab0100a9cf2b428911dfbe3f79d82886109e3 (0.4.20) hänge ich an. CS Pin ist wie im Quellcode ersichtlich auf D0, der Rest MISO MOSI CLK VDD und GND ist wohl selbsterklärend.
macht es einen unterschied ob ich einen normalen d1 mini oder einen d1 mini pro verwende? aktuell hab ich einen d1 mini und der fällt immer wieder aus
Ich habe den D1 mini V2 von Reichelt, der ist bei mir noch nie ausgefallen. https://secure.reichelt.at/at/de/d1-mini-esp8266-v2-0-d1-mini-p253978.html?&nbc=1
Hallo an Alle und als erstes ein herzliches Dankeschön für eure Arbeit. Ich lese hier schon eine Weile mit und habe auch schon so einige Versionen auf meinem ESP8266 geflasht. Habe einen HM-600. Bekomme mit der Version 4.24 bzw. 4.25 folgende Ausgabe im Terminal:
1 | I: Requesting Inverter SN 1141xxxxxxxx |
2 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
3 | E: while retrieving data: last frame missing: Request Retransmit |
4 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
5 | E: while retrieving data: last frame missing: Request Retransmit |
6 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
7 | E: while retrieving data: last frame missing: Request Retransmit |
8 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
9 | I: Inverter #0 I: no Payload received! (retransmits: 3) |
Nach einem zurück auf Version 4.22 (hatte ich als .bin noch), wurden sofort wieder Daten empfangen. Auch ein Wechsel auf Kanal 3 oder 23 brachte keine Verbesserung. Habe die beiden Versionen (4.25 zu 4.22) verglichen soweit ich den Code verstanden habe, aber nichts gefunden, welches das unterschiedliche Verhalten der beiden Versionen erklärt. Vielleicht kann jemand mal darüber schauen, der mehr Ahnung hat als ich? Danke und einen schönen Sonntag.
Falcon81 schrieb: > Bekomme mit der Version 4.24 bzw. 4.25 folgende Ausgabe im Terminal: Von 4.22 auf 4.25 wurden die Pins für CE und IRQ wieder getauscht - eventuell liegt da der Hase im Pfeffer? "Reverted the default settings to CE=D4 and IRQ=D3 so it matches the pinout diagrams for the time being." 4.25 // PINOUT (Default, can be changed in setup) //------------------------------------- #define RF24_CS_PIN 15 #define RF24_CE_PIN 2 #define RF24_IRQ_PIN 0 4.22 / PINOUT (Default, can be changed in setup) //------------------------------------- #define RF24_CS_PIN 15 #define RF24_CE_PIN 0 #define RF24_IRQ_PIN 2
Vielen, vielen Dank. Das war es. Nach dem Tausch von CE und IRQ läuft es wieder
Beitrag #7130649 wurde von einem Moderator gelöscht.
Markus schrieb: > Hallo Zusammen, > > finde ich toll was ihr da so angestellt habt. > ich versuche mich daran das auf einen ESP32 zu laden habe mich an die > Anleitung gehalten in https://github.com/tbnobody/OpenDTU aber Probleme > beim aufspielen auf den ESP32. > habe 9immer die Fehlermeldung "Der Terminalprozess > "C:\Users\Markus\.platformio\penv\Scripts\platformio.exe 'run', > '--target', 'upload'" wurde mit folgendem Exitcode beendet: 1. " > > gruß Markus Hallo Markus, da sollten davor noch mehr Meldungen erscheinen. Diese dürften aussagekräftiger sein.
Angehängte Dateien:
-
hm1500.jpg
240 KB -
hm1500.jpg
240 KB
Ihr seit echt der Hammer! Habe mir nen Wemos d1 mini und das Funkmodul gekauft, verkabelt, die 220713_ahoy_0.4.25_esp8266.bin von Günther H. geflasht, dann per Wifi AP die Werte eingetragen und zack... alles läuft! Vielen Dank!
Ich hoffe, dass die Leistungsbegrenzung noch kommt.
Hallo zusammen, ich bin froh verkünden zu können, dass die Leistungsreduzierung / Leistungseinstellung für den HM300 funktioniert. In den nächsten Tagen werde ich das Ganze dokumentieren und hier bereitstellen. DanielR92 testet gerade seinen HM1500. Auch ich werde noch Weiteres testen, wenn die Sonne wieder scheint ;-) Viele Grüße Klaus
Kla H. schrieb: > DanielR92 testet gerade seinen HM1500. Genau. Habe für Python (RPi) denn Modbus CRC16 schon hinterlegt. Das ganze möchte ich sauber noch ziehen, da es probleme beim Paket bauen gibt. @Jan-Jonas: Da müsste man nochmal was anpassen. :) Aktuell ist 0x80 immer fest als Sub-CMD sowie CMD. Dies muss man abändern. PS: Aktuell läuft die HM-1500 auf ~25W! =)
:
Bearbeitet durch User
Hallo zusammen, hier die erste Version des Protokolls: https://github.com/tbnobody/OpenDTU/issues/35 https://github.com/grindylow/ahoy/issues/31 Vielen Dank an die tolle "Vorarbeit" hier im Forum. Besonders Stefan T. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" und Daniel R. für die hilfreichen Hinweise. Erste Version quick and dirty mit dem openDTU implementiert und getestet: limit = zwei Byte, eine Dezimalstelle. Z.B: 30W = 300dez = 0x01 0x2c
1 | <0x51> <WR> <DTU> <0x81> <0x0b 0x00> <0x01 0x2c> <0x01 0x00> <crc16/modbus> <crc8> |
2 | <Cmd> <target> <source> <subcmd> <ctrlmode> <limit> <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8> |
Log:
1 | 22:28:13.964 > Fetch inverter: 112172615582 |
2 | 22:28:13.964 > sendPackSetPowerLimitCommand |
3 | 22:28:13.966 > sendEsbPacket |
4 | 22:28:13.969 > TX 51 72 61 55 82 78 56 34 12 81 0B 00 01 2C 01 00 C5 C0 3E |
5 | ...
|
6 | 22:28:14.897 > Interrupt received |
7 | 22:28:14.897 > |
8 | 22:28:14.897 > >> RX OK: D1 72 61 55 82 72 61 55 82 81 00 00 0B 00 14 07 48 |
9 | 22:28:14.903 > |
10 | 22:28:15.271 > RX Period End |
11 | 22:28:15.271 > getLastRequest() == RequestType::Cmd |
12 | 22:28:15.275 > Success |
Siehe auch :
1 | usart_nrf3.cpp |
2 | UsartNrf_Send_DevControlUpdate() |
3 | ...
|
4 | MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[0] = (u8)(relative_value >> 8); |
5 | MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[1] = (u8)(relative_value); |
6 | MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[0] = 0; |
7 | MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[1] = 1; |
...Happy coding... VG Klaus
:
Bearbeitet durch User
Kla H. schrieb: > Vielen Dank an die tolle "Vorarbeit" hier im Forum. > limit = zwei Byte, eine Dezimalstelle. Z.B: 30.0W = 300dez = 0x01 0x2c
1 | <0x51> <WR> <DTU> <0x81> <0x0b 0x00> <0x01 0x2c> <0x01 0x00> <crc16/modbus> <crc8> |
2 | <Cmd> <target> <source> <subcmd> <ctrlmode> <limit> <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8> |
Danke fürs Ausprobieren und die Lösung, daß das Limit mit einer Dezimalstelle angegeben wird war mir bisher nicht klar. Das ist die Wucht, Gratuliere! Mit besten Grüßen, Stefan T.
Einfach genial. Danke an die Hirnis hier!
Hallo, besteht da nicht die Gefahr, das man seinen WR völlig und unwiderruflich verstrubbelt? Oder hat der ne Resettaste? Mein HM1200 nicht.
Angsthase schrieb: > Hallo, > > besteht da nicht die Gefahr, das man seinen WR völlig und unwiderruflich > verstrubbelt? > > Oder hat der ne Resettaste? > Mein HM1200 nicht. Die Gefahr besteht immer :-) Zur Resettaste: Vielleicht hilft kpl. stromlos machen, also DC (Solarpanel/Netzteil/Batterie) und AC-Stecker ziehen für eine gewisse Zeit. Ist das schon jemandem der Tester aufgefallen? Bleiben die Total-Werte immer erhalten?
Wie erkennt man eigentlich wenn eine neue Version der OpenDTU verfügbar ist? Aktuell habe ich: SDK Version v4.4.1-1-gb8050b365e Firmware Version 0.1.18 Git Hash g63ccf38 Die habe ich heute gebuilded und die *.bin per Firmware Upgrade Funktion eingespielt. Erkennt man im Git irgenwo welche Version gerade aktuell ist? Vielen Dank!
Mal eine Frage bezüglich der Leistungsreduzierung: Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher interessiert bei meinem HM-600 die 600W Begrenzung aufzuheben und alles rauszuholen, was die Module hergeben ;) Klärt ihr mich auf? Danke
locke987 schrieb: > Wie erkennt man eigentlich wenn eine neue Version der OpenDTU verfügbar > ist? > Aktuell habe ich: > SDK Version v4.4.1-1-gb8050b365e > Firmware Version 0.1.18 > Git Hash g63ccf38 > > Die habe ich heute gebuilded und die *.bin per Firmware Upgrade Funktion > eingespielt. Erkennt man im Git irgenwo welche Version gerade aktuell > ist? > Vielen Dank! Es gibt keine Versionsnummern. Alles was im Git ist ist stabil (nach bestem Wissen und Gewissen). Die einzelnen Git Commits sieht man ja hier: https://github.com/tbnobody/OpenDTU/commits/master Bei jedem Commit steht rechts der Git Hash. Im aktuellen Fall 63ccf38. Das ist auch der Git Hash den du in der System Overview siehst. Damit lässt sich exakt bestimmen welche Version man aktuell am laufen hat.
Hoyle schrieb: > Mal eine Frage bezüglich der Leistungsreduzierung: > Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher ... > Klärt ihr mich auf? Danke Hier geht es um das Reverse Engineering des Protokolls und nicht ob etwas sinnvoll ist oder nicht. Wer es braucht und warum findest Du in den 1679 Beiträgen hier. Wenn Du eine Diskussion über Deine Wünsche möchtest, mach bitte ein eigenen Thread auf und kapere nicht diesen. Da könnt Ihr dann auch über zu tauschende MOSFETs im WR diskutieren. Danke.
:
Bearbeitet durch User
Herbert K. schrieb: > Hoyle schrieb: >> Mal eine Frage bezüglich der Leistungsreduzierung: >> Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher > ... >> Klärt ihr mich auf? Danke > > Hier geht es um das Reverse Engineering des Protokolls und nicht ob > etwas sinnvoll ist oder nicht. Wer es braucht und warum findest Du in > den 1678 Beiträgen hier. > Wenn Du eine Diskussion über Deine Wünsche möchtest, mach bitte ein > eigenen Thread auf und kapere nicht diesen. Da könnt Ihr dann auch über > zu tauschende MOSFETs im WR diskutieren. Danke. Hohoho was ist denn für ein Umgangston? Ich würde behaupten, ich lese den Thread schon länger mit als du... Aber darum geht es nicht. Und den Mund verbieten lasse ich mir von dir schon garnicht. Mich interessiert der Anwedungsfall für die gewünschte Leistungsreduzierung - nicht mehr nicht weniger. Dass ich mir eher die Möglichkeit wünschen würde, die Leistung aufzubohren (bzw. die willkürliche 600W Begrenzung für DE) soll nur mein Unverständnis /-wissen diesbezüglich verdeutlichen. Wenn du dazu nichts beizutragen hast, dann überlies doch bitte einfach meinen Post. Danke Hoyle
Hoyle schrieb: > Mich interessiert der Anwedungsfall für die gewünschte > Leistungsreduzierung - nicht mehr nicht weniger. Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt.
Thomas B. schrieb: > Das ist auch der Git Hash den du in der System Overview siehst. Damit > lässt sich exakt bestimmen welche Version man aktuell am laufen hat. Vielen Dank!!!
Thomas B. schrieb: > Hoyle schrieb: >> Mich interessiert der Anwedungsfall für die gewünschte >> Leistungsreduzierung - nicht mehr nicht weniger. > > Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem > Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen > als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts > läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR > limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss > könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die > Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das > ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt. Aha! Danke für die Ideen dazu. Mir hat sich diese Frage bisher noch garnicht gestellt, da hier noch ein alter Ferraris-Zähler (ggf. auch mal ein paar Umdrehungen rückwärts) läuft. So lange den keiner wechseln will, komme ich noch nicht in die Versuchung, über Batterien und verschenkte kWh nachzudenken :) Danke Thomas!
Stefan T. schrieb: > Kla H. schrieb: >> Vielen Dank an die tolle "Vorarbeit" hier im Forum. >> limit = zwei Byte, eine Dezimalstelle. Z.B: 30.0W = 300dez = 0x01 0x2c > 1<0x51> <WR> <DTU> <0x81> <0x0b 0x00> <0x01 0x2c> <0x01 0x00> > <crc16/modbus> <crc8> > 2<Cmd> <target> <source> <subcmd> <ctrlmode> <limit> <?desc?-fix > 0x01 0x00> <crc16/modbus> <crc8> > > Danke fürs Ausprobieren und die Lösung, daß das Limit mit einer > Dezimalstelle angegeben wird war mir bisher nicht klar. Das ist die > Wucht, Gratuliere! > > Mit besten Grüßen, > Stefan T. Wirst Du das auch in Deine Software mit einbauen?
Thomas B. schrieb: > Dann könnte man den WR > limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss > könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die > Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das > ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt. Zum Anschluss des WR an eine Batterie, statt den Solarpanels, würde mich interessieren, ob es einen Befehl zum deaktivieren der MPPT-Regler für die Panels gibt, bzw. Batterie-Betrieb umschalten? Ist da bei der DTU-Pro was vorgesehen?
Hallo, ich lese schon einige Zeit hier mit und sage erstmal Danke für die ganze Arbeit. Ich habe mir kürzlich ein ESP8266 und Funkmodul zusammengebaut und die bin von Günter H. geflasht. Geht super, nochmals Danke. Eine Sache ist mir in der V0.4.25 aufgefallen: wenn das WLan wiederkehrt (nach Nachtabschaltung) verbindet sich MQTT nicht wieder, erst nach Neustart. In der V0.4.22 schien das zu gehen. Schöne Grüße Heiko
Claus T. schrieb: > Zum Anschluss des WR an eine Batterie, statt den Solarpanels, würde mich > interessieren, ob es einen Befehl zum deaktivieren der MPPT-Regler für > die Panels gibt, bzw. Batterie-Betrieb umschalten? > Ist da bei der DTU-Pro was vorgesehen? Moin, ein Befehl dafür ist mir nicht aufgefallen. Der MPPT läuft automatisch ab eine bestimmten Spannung mit und versucht einfach, den Leistungspunkt zu optimieren. Meine Erkenntnisse aus der DTU zeigen nur den "normalen" Leistungsumfang wie die 0-Einspeisung in Verbindung mit dem CHiNT Meter, die restliche Leistungsreduktion wurde durch Daniel R. dahingehend auf Basis dieser Befehle erfolgreich getestet. Wenn du mehr darüber wissen willst, wir haben mittlerweile auf dem Discord einen Speichersysteme-Channel, wo wir sowas genauer besprechen können. Dort gibt es bereits mehrere Ansätze, bei denen du dich gerne mit Einbringen kannst, keine Idee ist verrückt genug :) Turn On/Turn Off/Restart sind ebenfalls seit eben bekannt. Das ganze werde ich für die MI-Version nachher noch anschauen, Leistungsreduktion auf der MI-Serie (bei mir MI-600) habe ich auch mitgeschnitten, ist nur noch nicht ausgewertet. Controls muss ich extra machen, war leider schon zu dunkel dafür. lg
Hallo, erstmals ein großes Dankeschön an alle, die geholfen haben, dieses Projekt weiter zu bringen. Es ist immer schön zu sehen was eine Hand voll kluger Köpfe erreichen kann. :) Ich bin auf den Thread gestoßen, nachdem wir bei einem Freund eine HM-1200-Anlage mit einem HM-1500 erweitert haben, und auf das Vier-Platten-Limit des DTU-Lite gestoßen sind. Zudem war uns die Cloud-Geschichte schon immer ein Dorn im Auge. Beim Zusammenlöten und Testen bei mir vor Ort habe ich spaßeshalber die SN meines TSUN TSOL-M350 eingegeben, da diese wie bei den Modellen HM-300, HM-350 und HM-400 mit "1121" beginnt. Und siehe da: es funktioniert ohne Probleme. Nachdem die Integration in mein Grafana gebaut wurde, bleibt wohl ein ESP bei mir. :) Viele Grüße, Kev
Thomas B. schrieb: > Hoyle schrieb: >> Mich interessiert der Anwedungsfall für die gewünschte >> Leistungsreduzierung - nicht mehr nicht weniger. > > Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem > Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen > als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts > läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR > limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss > könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die > Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das > ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt. Der WR hat genau einen Ausgang, und zwar die Netzeinspeisung (50Hz 230V). Wenn ich jetzt das limitiere, wie genau bekomme ich den Überfluss an Leistung aus dem PV panelen in meine Batterie? VG
Hier die drei o.g. Commands für das Ein-/Ausschalten bzw. den Reset des Wechselrichters.
1 | 51 76543210 78563412 81 0000 B001 A5 ------ Type_TurnOn 0x00 |
2 | 51 76543210 78563412 81 0100 2000 55 ------ Type_TurnOff 0x01 |
3 | 51 76543210 78563412 81 0200 D000 7B ------ Type_Restart 0x02 |
4 | ^^-------------------------------------- MainCmd 0x51 DEVCONTROL_ALL |
5 | ^^^^^^^^----------------------------- WR Serial ID |
6 | ^^^^^^^^-------------------- DTU Serial ID |
7 | ^^----------------- SingleFrameID |
8 | ^^-------------- SubCmd siehe oben |
9 | ^^^^------------ Control Mode ? immer zwei Byte im Gen3 Protokoll |
10 | ^^^^------ CRC16 / CRC-Modbus über die Daten, excl. Frame ID! |
11 | ^^--- CRC8 |
Die CRC16 und CRC8 läßt sich ggf. online berechnen, falls es jemand mal schnell kontrollieren will: CRC-16/CRC-Modbus Input Data: 0x0200 Result CRC-16/CRC-Modbus value: 0xD000 https://crccalc.com/?crc=0x0200&method=CRC-16/MODBUS&datatype=hex&outtype=0 CRC-8 Input value: 0x51 76543210 78563412 81 0200 D000 Result CRC-8 value: 0x7B https://crccalc.com/?crc=0x517654321078563412810200D000&method=CRC-8/ITU&datatype=hex&outtype=0 --- Und hier das Power Limit setzen
1 | 51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B |
2 | ^^--------------------------------------------- MainCmd 0x51 DEVCONTROL_ALL |
3 | ^^^^^^^^------------------------------------ WR Serial ID |
4 | ^^^^^^^^--------------------------- DTU Serial ID |
5 | ^^------------------------ SingleFrameID |
6 | ^^--------------------- SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr |
7 | ^^^^------------------- Control Mode |
8 | ^^^^-------------- PowerPFDev.SetValut 0x012C = 30.0 W |
9 | ^^^^--------- PowerPFDev.Desc 0x0000 oder 0x0001 ? |
10 | ^^^^---- CRC16 / CRC-Modbus über die Daten, excl. Frame ID! |
11 | ^^- CRC8 |
CRC-16/CRC-Modbus Input Data: 0x0B00 012C 0000 Result CRC-16/CRC-Modbus value: 0x55C1 https://crccalc.com/?crc=0x0B00012C0000&method=CRC-16/MODBUS&datatype=hex&outtype=0 CRC-8 Input value: 0x51 76543210 78563412 81 0B00 012C 0000 55C1 Result CRC-8 value: 0x0F https://crccalc.com/?crc=0x517654321078563412810B00012C000055C1&method=CRC-8/ITU&datatype=hex&outtype=0 Die Antwort Pakete haben wir noch nicht entschlüsselt, aber es kommt immer (MainCmd | 0x80) also ANSWER_DEVCONTROL_ALL 0xD1 zurück. Bei Fehlern in der Nachricht oder der CRC-16/CRC-Modbus Checksumme kommt 0xF1 oder 0xFF als Fehlercode je nachdem ob es sich um eine SingleFrame oder MultiFrame Anfrage gehandelt hat.
:
Bearbeitet durch User
Stefan T. schrieb: > Hier die drei o.g. Commands für das Ein-/Ausschalten bzw. den Reset des > Wechselrichters.... Hallo Stefan T., sind die für für MI-xxxx oder HM-xxxx ? SUPER Arbeit von Dir !
Kurze Frage: muss es ein NRF24L01+ sein oder funktioniert auch ein NRF24L01?
Tobi schrieb: > Kurze Frage: muss es ein NRF24L01+ sein oder funktioniert auch ein > NRF24L01? Es MUSS ein "+" sein
> Der WR hat genau einen Ausgang, und zwar die Netzeinspeisung (50Hz > 230V). Wenn ich jetzt das limitiere, wie genau bekomme ich den Überfluss > an Leistung aus dem PV panelen in meine Batterie? > Hallo, ich denke die Idee dahinter ist, den WR (nicht nich bestimmungsmässem Gebrauch) an eine Batterie zu hängen (z.B. LiFePo mit 24, 36 oder 48V) und über die Begrenzung dann die Ausgangsleistung passend zum Hauverbrauch zu regeln. Das wäre eine sehr preisgünstige Sache mit einem Netzsetig konformen WR. Gruß Carsten PS: vieleich hierzu ein Seperates Thema aufmachen, wenn es mehr Leute interessiert?
Herbert K. schrieb: > sind die für für MI-xxxx oder HM-xxxx ? Das betrifft die HM-Serie. Mein TSUN ist eigentlich ein MI-600, daher habe ich für MI folgendes direkt an der DTU Pro mitgeloggt: OFF-CMD: 51 63500316 63500316 AA55 AE ON-CMD: 51 63500316 63500316 55AA AE Reboot: 0E 63500316 63500316 1000 0000 12EE E2 Leistung: 51 63500316 63500316 5A5A 2C0A 86F1 51 63500316 63500316 5A5A 1C06 C08B Was aus der Leistung rauslesbar ist, weiß ich noch nicht, aber ihr habt erstmal wieder Futter für die 2-Kanal MI :) Anbei außerdem diverse Logs direkt am NRF-Modul der Pro, drin zu finden Powerlimits in Verbindung mit dem CHiNT-Zähler, Limitierung des HM-1500 und des MI-600, Reboot-, ON- und OFF- Commands.
Carsten B. schrieb: > PS: vieleich hierzu ein Seperates Thema aufmachen, wenn es mehr Leute > interessiert? Die Thematik haben wir u.a. auf dem Discord. Ich denke, hier ist es sinnvoll, später ein extra Thema zu starten, wenn die Erkenntnisse soweit sind, dass man es verwenden kann, zumal div. Zähler/Messgeräte zusätzlich benötigt werden. Aktuell ist es noch so, dass zwar grundlegende Funktionen bekannt sind, jedoch noch nicht überall integriert. Derzeit hat Daniel R. ein Labornetzteil und einen Raspi zum Testen, mir fehlen Programmierkenntnisse um das ganze in AHOY und OpenDTU einzubauen, damit kann ich nur Daten abfischen und bereitstellen. Die weitere Problematik ist die Berechnung der Limits anhand der benutzten Eingänge über mehrere Geräteklassen hinweg (1- und Mehrkanal HM/MI), was nicht ganz trivial ist. Klar ist: Eine netzkonforme Ausspeisung aus einem Akku ist der Weg, den einige hier wünschen :) lg
Hallo, ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite die dann aber kurz später nicht mehr erreichbar ist. Hat jemand eine Idee was das sein könnte? Solong B
Ich hatte gestern und heute 2 "Unknown" events im Log, einmal Event ID 12 und einmal ID 47. Weiß Jemand welche Fehlermeldung das sein könnte? Bzw. ist es geplant in der OpenDTU die Loginformationen zu erweitern? Ich speichere alle verfügbaren Werte momentan über mqtt in einer influxdb und Werte diese über Grafana aus, konnte aber keinerlei Zusammenhang zu den Zeitpunkten der Fehlermeldungen erkennen.
Update Leistungsregulierung MI-Serie (hier MI-600 & Kompatibel) An der Schnittstelle zum NRF abgegriffene Daten sehen so aus: <51> <63 50 03 16> <63 50 03 16> <5A 5A> <2D> <0A 9E> <E8> Main-CMD 0x51, WR-ID, WR-ID, Sub-CMD 0x5A 0x5A, Limit %, Limit Absolut, CRC8 Die CRC8 über den ganzen Block. Meine DTU sendet das Powerlimit basierend auf 1%=6W (100%=600W), 0x2D = 45%, 0x0A 0x9E = 271,8W (DEC 2.718) 51 63500316 63500316 5A5A 2D 0AA0 D6 -> 45% 272,0W 51 63500316 63500316 5A5A 65 17CC EF -> 101% 609,2W 51 63500316 63500316 5A5A 3F 0EF0 90 -> 63% 382,4W Ich weiß nicht, ob ein Limit von 100% mit einem absoluten Wert funktioniert, für die 2-Kanal MI könnte das aber ein Ansatz sein. Viel Spaß beim Testen :) lg
Kann man irgendwie prüfen ob der NRF24L01+ richtig arbeitet? Also gibt es einen Log-Output auf dem ESP32? Ich hab alles verlötet, den ESP32 geflasht, die Weboberfläche startet - aber ich bekomme keine Daten vom Hoymiles. Darum würde ich gerne wissen ob mein NRF24L01+ Board "am Leben" ist.
Beitrag #7135179 wurde vom Autor gelöscht.
Chris schrieb: > Kann man irgendwie prüfen ob der NRF24L01+ richtig arbeitet? Also > gibt es einen Log-Output auf dem ESP32? Schau auf welchem COM Port dein ESP32 hängt und geh einfach mit einem Serial Monitor drauf (mit 115200 Baud). Dort findest du dann Zeilen wie:
1 | Starting OpenDTU |
2 | ...
|
3 | Setting Hostname... Configuring WiFi STA using new credentials... done |
4 | ...
|
5 | Initialize Hoymiles interface... Connection successfull |
6 | ...
|
Im Fehlerfall, also falls die Initialization vom NRF gar nicht klappt, sollte da das hier stehen:
1 | Initialize Hoymiles interface... Connection error!! |
locke987 schrieb: > Ich hatte gestern und heute 2 "Unknown" events im Log, einmal Event ID > 12 und einmal ID 47. Weiß Jemand welche Fehlermeldung das sein könnte? > Bzw. ist es geplant in der OpenDTU die Loginformationen zu erweitern? > Ich speichere alle verfügbaren Werte momentan über mqtt in einer > influxdb und Werte diese über Grafana aus, konnte aber keinerlei > Zusammenhang zu den Zeitpunkten der Fehlermeldungen erkennen. Das Eventlog kommt 1zu1 aus dem Inverter. Hier Dinge zu erweitern wird also eher nichts werden. Was dagegen noch machbar ist, ist die Interpretation der enthaltenen Daten. ID 12 bzw. 47 hatte ich bisher noch nicht. Manchmal sehe ich Abends eine 36. Aber auch nicht jeden Tag.
Ich habe gerade das erste mal versucht eine Verbindung aufzubauen. Wenn ich außerhalb der Reichweite bin, dann kommt:
1 | TX 15 81 10 4 20 78 56 34 13 80 B 0 62 DA 4C 23 0 0 0 5 0 0 0 0 4C D2 6E |
2 | RX Period End |
3 | All missing |
4 | Nothing received, resend count exeeded |
Wenn ich innerhalb der Reichweite bin kommt laufend:
1 | Fetch inverter: 116181100420 |
2 | Fetch inverter: 116181100420 |
3 | Fetch inverter: 116181100420 |
4 | Fetch inverter: 116181100420 |
5 | ...
|
Ich vermute mal, dieses "Fetch" bedeutet, dass die Verbindung klappt. Problem: Ich bekomme trotzdem keine Werte, im Web Interface sind sämtliche Werte auf 0. Das "Event Log" hat auch 0 Einträge. Was könnte das Problem sein?
:
Bearbeitet durch User
Daniel M. schrieb: > Update Leistungsregulierung MI-Serie (hier MI-600 & Kompatibel) > > An der Schnittstelle zum NRF abgegriffene Daten sehen so aus: > <51> <63 50 03 16> <63 50 03 16> <5A 5A> <2D> <0A 9E> <E8> > Main-CMD 0x51, WR-ID, WR-ID, Sub-CMD 0x5A 0x5A, Limit %, Limit Absolut, > CRC8 > > Die CRC8 über den ganzen Block. > Meine DTU sendet das Powerlimit basierend auf 1%=6W (100%=600W), > 0x2D = 45%, 0x0A 0x9E = 271,8W (DEC 2.718) > > 51 63500316 63500316 5A5A 2D 0AA0 D6 -> 45% 272,0W > 51 63500316 63500316 5A5A 65 17CC EF -> 101% 609,2W > 51 63500316 63500316 5A5A 3F 0EF0 90 -> 63% 382,4W > > Ich weiß nicht, ob ein Limit von 100% mit einem absoluten Wert > funktioniert, für die 2-Kanal MI könnte das aber ein Ansatz sein. > > Viel Spaß beim Testen :) > > lg Ok, der MI600 ist ja scheinbar gleich was ich vom MI-1500 berichtet hatte. Das mit % oder abs. Wert funktioniert entweder oder, wenn du % eingibst wird nach der %-Wattzahl der Nennleistung limitiert, wenn du abs. Wert eingibts, also 2. byte nach 0x5a5a, wird die % Zahl ignoriert.
Joni N. schrieb: > Ich vermute mal, dieses "Fetch" bedeutet, dass die Verbindung klappt. > > Problem: Ich bekomme trotzdem keine Werte, im Web Interface sind > sämtliche Werte auf 0. Das "Event Log" hat auch 0 Einträge. Das Fetch bedeutet, dass versucht wird was vom Inverter zu lesen. Aber wenn darauf keine TX Nachrichten kommen (was bei dir ja nicht der Fall ist) scheint keine valide Uhrzeit vorzuliegen. Hier scheint der ESP keine Internet Verbindung zu bekommen um die Zeit vom NTP Server zu holen.
Thomas B. schrieb: > Das Fetch bedeutet, dass versucht wird was vom Inverter zu lesen. Ah, OK. Pollst du die Werte für ein bestimmtes Zeitfenster? Muss deswegen die Zeit genau stimmen? Haben die Hoymiles eine RTC eingebaut?
Kurze Erfahrung mit einem NRF24L01+ - Clone: Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600 empfangen. Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt!
Joni N. schrieb: > Ah, OK. Pollst du die Werte für ein bestimmtes Zeitfenster? Muss > deswegen die Zeit genau stimmen? > > Haben die Hoymiles eine RTC eingebaut? Die Zeit wird mit jedem Anfragepaket an den WR geschickt. Was der WR intern damit alles macht ist nicht bekannt. Fest steht, dass die Zeit anschließend im Eventlog auftaucht. Ob über diese Zeit auch die tägliche Produktion (also der Tageswechsel) ermittelt wird ist nicht bekannt aber möglich.
Frank K. schrieb: > Heute kamen die originalen > NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600 > empfangen. Welche/wo NRF24L01+ hast Du denn bestellt? Ich bin mir nicht sicher ob meine richtig funktionieren. Ich würde gerne genau die selben wie Du bestellen.
Joni N. schrieb: > Welche/wo NRF24L01+ hast Du denn bestellt? Ich bin zwar nicht Frank aber diese beiden funktionieren bei mir beide in Verbindung mit einem ESP8266 und aktueller OpenDTU Version: https://www.amazon.de/gp/product/B07PQPFTWZ/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1 https://www.amazon.de/gp/product/B06XJN417D/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Gruß Stefan
Frank K. schrieb: > Kurze Erfahrung mit einem NRF24L01+ - Clone: > Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt > mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen > NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600 > empfangen. > Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt! Wo hast du die originalen gekauft? Meine China Dinger zicken auch nur rum. Ich würde auch gerne andere ausprobieren.
skusi schrieb: > Frank K. schrieb: >> Kurze Erfahrung mit einem NRF24L01+ - Clone: >> Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt >> mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen >> NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600 >> empfangen. >> Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt! > > Wo hast du die originalen gekauft? Meine China Dinger zicken auch nur > rum. Ich würde auch gerne andere ausprobieren. Sorry, hat sich erledigt, hab eben erst zu Ende gelesen... Danke Stefan.
SM D. schrieb: > Hallo, > > ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der > wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später > ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass > das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite > die dann aber kurz später nicht mehr erreichbar ist. > > Hat jemand eine Idee was das sein könnte? > Es könnte Reboots wegen zu schwacher Stromversorgung sein. Was sagt das serielle Log?
Hallo, ein tolles Projekt! Was genau benötige ich nun für Teile? ESP8266 + nrf24l01 ? Muss es ein original Wemos ESP8266 sein? wemos ds1 mini? Mal lese ich, es muss unbedingt ein nrf24l01+ sein, mal lese ich ein nrf24l01 reicht auch. Kann jemand ggf. Links zu Amazon posten, von Teilen, die erfolgreich mit Hoymiles-Wechselrichtern funktionieren? Ich bin ein wenig verwirrt, weil es nicht mein Tagesgeschäft ist ;-) Danke. Gruß, Tobias
@Tobias G. Einfach 5 Beiträge zurück. Da sind Links. UND nirgends steht, das ein "nrf24l01" ausreicht ! Es muß !!! ein "+" sein !
@Return 5 Danke, aber deshalb frage ich ja, weil es m.E. in dem Link bei dem Artikel DollaTek 2Pcs NRF24L01 + PA + LNA nicht um den NRF24L01+ handelt, sondern hier nur das "+" geschickt als Ersatz für & im Rahmen einer Aufzählung verwendet wurde ... aber den Eindruck erwecken soll, dass es sich um den NRF24L01+ handelt. Oder liege ich falsch?
Hallo, hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut?
Tobias G. schrieb: > @Return 5 Danke, aber deshalb frage ich ja, weil es m.E. in dem > Link bei > dem Artikel DollaTek 2Pcs NRF24L01 + PA + LNA nicht um den NRF24L01+ > handelt, sondern hier nur das "+" geschickt als Ersatz für & im Rahmen > einer Aufzählung verwendet wurde ... aber den Eindruck erwecken soll, > dass es sich um den NRF24L01+ handelt. Oder liege ich falsch? Wie auch immer, ich hab die Dinger beide im Einsatz und Sie funktionieren stabil seit ca. 2 Wochen, und wenn nicht schickst Du sie einfach wieder kostenlos zurück.
locke987 schrieb: > Wie auch immer, ich hab die Dinger beide im Einsatz und Sie > funktionieren stabil seit ca. 2 Wochen, und wenn nicht schickst Du sie > einfach wieder kostenlos zurück. auf dem Chip ist ein + drauf
RM schrieb: > Hallo, > hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut? Hi, ja, auch das haben wir bereits angeschaut und versuchen das nachzuvollziehen. Bitte etwas Geduld und gerne direkt auf Github AHOY und OpenDTU verfolgen. Wofür brauchst du es genau? (Und wer votet solche Fragen runter? Meine güte...) lg
Daniel M. schrieb: > RM schrieb: >> Hallo, >> hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut? > > Hi, > ja, auch das haben wir bereits angeschaut und versuchen das > nachzuvollziehen. > Bitte etwas Geduld und gerne direkt auf Github AHOY und OpenDTU > verfolgen. > > Wofür brauchst du es genau? > > (Und wer votet solche Fragen runter? Meine güte...) > > lg Ich wollte mir mit 3x HM 1500 eine PV Anlage bauen und vor allem Anmelden. Der Elektriker bzw der Enegergieversorger haben auf Ihrer Checkliste stehen, dass der Wechselrichter die Möglichkeit haben muss, die Blindleistung einzustellen. Also einstellen will ich da nichts, aber bei der Abnahme muss ich Ihn demonstrieren, dass ich könnte.... In der DTU glaub ich gehts nicht, aber im Datenblatt ist was erwähnt, dass es gehen sollte. Ich will die anmelden, es gibts zwar blos 6 cent aber besser als den Strom zu verschenken. Und ich brach weil alles so verwinkelt und verschattet ist 6 MPPT Tracker. Seit über 1,5 Jahren hab ich auch schon 2x HM 300 im einsatz und auch beim Amateurfunk keine merklichen Probleme damit, das hab ich mit meinen Nachbarn und SMA Wechselrichter schon.
Kann mir jemand helfen und sagen, ob ich diesen ESP hier nehmen kann oder lieber einen anderen? https://www.amazon.de/AZDelivery-D1-Mini-Entwicklungsboard-kompatibel/dp/B0754N794H/ref=cm_cr_arp_d_product_top?ie=UTF8
Tobias G. schrieb: > Kann mir jemand helfen und sagen, ob ich diesen ESP hier nehmen kann > oder lieber einen anderen? > https://www.amazon.de/AZDelivery-D1-Mini-Entwicklungsboard-kompatibel/dp/B0754N794H/ref=cm_cr_arp_d_product_top?ie=UTF8 Ja die sind Top und benutze sie auch. 4MB Flash sind wichtig
:
Bearbeitet durch User
RM schrieb: > > Ich wollte mir mit 3x HM 1500 eine PV Anlage bauen und vor allem > Anmelden. Das ist eine ordentliche Größe, da lohnt sich auch der Aufwand. > Der Elektriker bzw der Enegergieversorger haben auf Ihrer Checkliste > stehen, dass der Wechselrichter die Möglichkeit haben muss, die > Blindleistung einzustellen. Bitte was? Mir wäre neu, dass das bei kleinen Anlagen gefordert ist. Im Normalfall machen die das selber, wenn die Messung sagt, dass es nötig ist. Bist du sicher, dass es sich dabei um die Blindleistung und nicht um die normale AC-Leistung handelt? Ich bin kein Netzbetreiber, aber ich denke, im Netz haben die größere Sorgen als 1,5kW Mikrowechselrichter justieren zu müssen. Frag da nochmal nach ob die dich verarschen wollen. > Also einstellen will ich da nichts, aber bei der Abnahme muss ich Ihn > demonstrieren, dass ich könnte.... In der DTU glaub ich gehts nicht, > aber im Datenblatt ist was erwähnt, dass es gehen sollte. Einstellen solltest du da als Anwender auch nichts, vor allem nicht, wenn du nicht weißt, was du tust. In der DTU geht das nicht manuell, wie gesagt, es ist ein Automatismus, der da greift. > Ich will die anmelden, es gibts zwar blos 6 cent aber besser als den > Strom zu verschenken. Und ich brach weil alles so verwinkelt und > verschattet ist 6 MPPT Tracker. Seit über 1,5 Jahren hab ich auch schon > 2x HM 300 im einsatz und auch beim Amateurfunk keine merklichen Probleme > damit, das hab ich mit meinen Nachbarn und SMA Wechselrichter schon. Zuviel Input :) Mach ruhig, gerade mit der neuen Einspeisevergütung gibts da ja mehr. Amateurfunk, anderes Thema, nicht in diesem Thread. Oberwellen und Netzrückwirkungen gehen hier auch ein Stück zu weit in die falsche Richtung, da kommt maximal die Info: siehe Zertifikate und Laborberichte. lg
Nachdem ich jetzt tagelang herumgelötet habe, alles doppelt und dreifach überprüft hab - und trotzdem nichts ging sind heute die bestellten Transceiver Module angekommen. Und damit klappte es auf Anhieb! Ich hab diese hier bestellt: https://www.amazon.de/gp/product/B07VQ838KT Tausend Dank an die Entwickler für dieses tolle Projekt.
:
Bearbeitet durch User
Tobias: Das funktionsfähige Teil habe ich bei MAKERSHOP.DE bestellt, Artikelbezeichnung "2x NRF24L01+ 2.4GHz Funkmodul Raspberry Pi Arduino Modul nrf2401 Antenne".
Hallo zusammen, erst mal vielen Dank für die super Leistung !!! Hab meinen ESP mit Empfänger verlötet und alles funktioniert ... Mir ist nur aufgefallen das der MQQT in der aktuellen Version 0.4.25 nur beim Neustart verbunden wird. Wenn Wlan kurz weg ist oder der MQQT Server nicht erreichbar ist ( weil er eine Datensicherung nachts macht ) wird keine Verbindung mehr hergestellt. Erst nach einem Neustart geht es wieder.
Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24 besser?
Holger S. schrieb: > Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24 > besser? Nein, ist bei mir auch bei der .24 so gewesen. Eine gute Version mit stabilerem MQTT war bei mir die 0.4.5
Hallo in die Runde. Ich habe ein Problem und zwar ich bekomme auf meinem D1 mini von berrybase, nichts hochgeladen, weder mit der Arduino IDE noch mit Visual Studio Code und der Platform.io. Mein Setup ist wie folgt: 1x D1 Mini von berrybase.de https://www.berrybase.de/d1-mini-esp8266-entwicklungsboard per USB Kabel am Laptop. Auf dem Board ist ja so ein USB to Serial Converter CH340 drauf verbaut. Der Treiber wird erkannt und setzt das Board auf COM6. Soweit so gut. Aber wenn ich mit dem VSC oder der Arduino IDE versuche zu D1 Mini zu connecten bricht der Uploade immer mit Fehlermeldung ab. Hat jemand von euch das Setup so am laufen mit dem CH340 USB to Serial Converter oder flasht ihr die Software über FTDI direkt verdrahtet auf die RX und TX Pins des ESP D1 Mini ? Danke für Eure Tips Gruss Esafreak
@esafreak: Verwende doch einfach eines der Flash- Programme! NodeMCU-PyFlasher ESP8266Flasher tasmotizer-1.2 Funktioniert tadellos! Grüße Gerri
esafreak schrieb: > Hat jemand von euch das Setup so am laufen mit dem CH340 USB to Serial Ich habe das Setup exakt so am laufen an meinem Mac. Keine Probleme; Weder unter Arduino noch unter VS-Code. Unter VS-Code finde ich es sogar komfortabler zu flashen (als Anfänger). Hast du schon mal ein anderes USB-Kabel verwendet?
Tausche das Kabel. Da gibt es mehr Schrott als vorstellbar! Viele sind gar nicht komplett belegt und taugen maximal zum Laden.
Hallo Hubi. Aus den vielen Beiträgen habe ich die SW hoydtusim aus Deiner Schmiede gewählt und finde die gut. Frage: Wird deine SW auch um die Einstellung der Leistungsbegrenzung bzw. Nulleinspeisung mit Smartmeter erweitert oder hast Du dies vor? einen schönen Sonntag. Fritsche
Hallo zusammen, Nach 3 Tagen intensiver Forschung hab ich den Datenlogger soweit gebaut. Firmware ist drauf, im WLAN sind wir auch, nur kann ich meine HMT-1800 nicht verbinden mit der Seriennummer. Kann es sein, dass HMT-1800 nicht unterstützt wird bei der aktuellen Diskussion? Danke und VG James
Mr.James schrieb: > Hallo zusammen, > Nach 3 Tagen intensiver Forschung hab ich den Datenlogger soweit gebaut. > Firmware ist drauf, im WLAN sind wir auch, nur kann ich meine HMT-1800 > nicht verbinden mit der Seriennummer. > > Kann es sein, dass HMT-1800 nicht unterstützt wird bei der aktuellen > Diskussion? > > Danke und VG > James Hallo James, der HMT wird nicht unterstützt, da dieser ein anderes Funkprotokoll und einen andere Frequenzbereich verwendet. lg
Hallo zusammen, ich verfolge dieses Thema schon seit langen. Ich finde es echt cool wie das ganze hier sich entwickelt hat. Super Arbeit. Eine Frage hätte ich noch: wird es eventuell irgend wann eine Unterstützung für den HM-1800 (3 Phasig) geben ? Mit dem HM-800 läuft das ganze einwandfrei. Vielen Dank nochmal
Hallo Marius, so ein bisschen kann ich AVR Herbi schon verstehen wenn man nicht mal die letzten zwei Posts liest. Und nein HMT/HMS Wechselrichter sind nicht das Thema dieses Threads da es sich um komplett andere Gunktechnik handelt. Wenn Du die Funktechnik nachgebaut hast kannst Du Dich gerne im Source Code der DTU-Pro umsehen da steht auch einiges zum Regeln von drei Phasen drin aber die Ansteuerung von Deinem Wechselrichter wird über den von Hoymiles und uns verwendeten nRF24L01+ nicht funktionieren da die Frequenz und das Funkverfahren zwei ganz andere sind.
Hallo zusammen, könnte mir bitte jemand den Discord Link zukommen lassen Danke Sven
Hallo zusammen, Danke schon mal für eure Antworten. Habe es auf 2 Windows Rechnern probiert mit 3 verschiedenen USB Kabeln :-( Eine Frage noch. Muss man am wemos D1 Mini vor dem flashen immer den GPIO 0 auf Low legen oder etwas anderes beachten damit das wemos Board geflasht wird? Davon hab ich bisher nirgends etwas gelesen dass man am wemos d1 mini Board aktiv einen Pin jedesmal vor dem flashen high oder Low schalten muss. Kann das mein Problem sein dass der wemos d1 mini nie in den Flash Modus geht oder ist das eigentlich nicht notwendig Pins auf der Platine händisch auf high oder Low zu legen? Danke für euer Feedback. Gruss esa
Sven H. schrieb: > Hallo zusammen, > > könnte mir bitte jemand den Discord Link zukommen lassen > > Danke > > Sven Findest du hier: https://discord.gg/mddnTPwu lg
@ Esafreak Beim Wemos D1 Mini müssen keine Pins auf bestimmte Potentiale gelegt werden, das geschieht durch die Beschaltung auf dem Board.
Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hallo Friedhelm, da ich keine DTU und sniffen kann bin ich auf die Erkenntnisse von anderen in diesem Thread angewiesen. Aber, ja, ich habe das gefragte vor, aber eher n Richtung volle Ausnutzung meiner Panele.
Hi zusammen, jetzt hat es endlich geklappt mit dem flashen. das esp board hatte einen Schuss weg. habe noch ein anderes originalverpackt liegen gehabt, und das liess sich dann mit platform.io flashen. jetzt hab ich aber das nächste folgende problem. der esp macht ein wlan auf mit dem namen ahoy-dtu und nach eingabe des wlan passworts für ahoy-dtu connected mein laptop auch kurz aufs wlan des Esp. allerdings werde ich nicht automatisch zu den configuration seiten weitergeleitet sondern das wlan des esp ist mal da, mal weg, mal da mal weg. die IP des esp lässt sich pingen, aber es werden nicht die configurationsseiten geladen. Hat jemand eine Idee von euch, woran das liegen könnte, dass die configuration seiten des ESP nicht geladen werden, nachdem ich auf das ahoy-dtu WLAN connected habe. ? Wie gesagt, es ist auch nicht ständig da sondern das ahoy-dtu kommt und geht. danke schon mal für eure kommentare. gruss esafreak
Hast Du mal nen Browser aufgemacht und die IP des Wemos eingegeben ? Also 192.168.1.1
Hallo Zusammen, mein Passwort fpr das AHOY-DTU WLAN wird nicht akzeptiert. Könnt Ihr das Start PW bitte noch mal posten? Vielen Dank
Hallo zusammen, hab ständig die Meldung MQQT : not connected. Nach Neustart funktioniert es kurz dann wieder der Fehler. Ich verwende die Version 0.4.25 auf einem ESP. GUI funktioniert alles. Jemand ne Idee zur Lösung ? Besten Dank schon mal ... :-)
Axel H. schrieb: > SM D. schrieb: > >> Hallo, >> ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der >> wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später >> ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass >> das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite >> die dann aber kurz später nicht mehr erreichbar ist. >> Hat jemand eine Idee was das sein könnte? > > Es könnte Reboots wegen zu schwacher Stromversorgung sein. Was sagt das > serielle Log? Genau das gleiche Problem bei mir. Stromversorgung ist stabiles raspberry Netzteil Hat sich das Problem bei euch schon gelöst und wenn ja wie? Gruss esafreak
Hallo zusammen,
wir sind bald fertig. Natührlich muss viel noch überarbeitet werden.
Aktuell haben wir ein kleines Problem das später das ganze
Python-Scrippt imemr wieder zum crashen bringt.
File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack
return struct.unpack(fmt, self.response[base:base+size])
struct.error: unpack requires a buffer of 2 bytes
Wenn jemand eine Idee hat, sagt bescheid.
PS: Ja Google ist mein aller aller ... bester Freund. ;)
Angehängte Dateien:
-
loeschen.png
75 KB
83775 schrieb: >Jemand ne Idee zur Lösung ? Besten Dank schon mal ... :-) Ich hatte mit Ahoy ähnliche Probleme als ich noch mit Arduino geflasht habe. Es werden ja Partitionen definiert, wenn das nicht stimmt können seltsame Dinge passieren. Ich würde vorschlagen vor dem flashen alles zu löschen. Kann man in Arduino einstellen, ich denke das geht in Plattform IO bestimmt auch. Habs gefunden, siehe Anhang.
:
Bearbeitet durch User
Esafreak schrieb: > > Genau das gleiche Problem bei mir. Stromversorgung ist stabiles > raspberry Netzteil > Hat sich das Problem bei euch schon gelöst und wenn ja wie? > Gruss esafreak Also, das Problem kam bei mir von einer schlechten USB Buchse auf dem ESP32 Board, die ging mal und mal ging sie nicht, zumindest nicht ausreichend(Übergangswiderstand). Das gleiche könnte natürlich auch ein Problem des USB Kabels sein. Solong B
Hallo Daniel, > Aktuell haben wir ein kleines Problem das später das ganze > Python-Scrippt imemr wieder zum crashen bringt. > > File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack > return struct.unpack(fmt, self.response[base:base+size]) > struct.error: unpack requires a buffer of 2 bytes > > > Wenn jemand eine Idee hat, sagt bescheid. Wenn das nur sporadisch auftritt (gelegentliches, vorüber gehendes Empfangsproblem?), wäre meine Methode per Python, das mittels eines try:/except:-Konstrukts abzufangen und erst mal nicht weiter drüber nachzudenken, bis andere wichtigere Sachen organisiert sind. Bei grundsätzlich unsicheren Datensituationen ist so was wahrscheinlich sogar die einzige solide Lösung, da raus zu kommen. Tschüssi, Petra
Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. Tolles Projekt!! Gruss esafreak
Hallo. Ich habe eine Frage zum HM-400 WR Ich nutzte die Arduino IDE mit der HoyDtuSim.ino. Hardware: WEMOS D1 Mini + 1x NRF24L01+ verkabelt nach der Anleitung von github. Im Seriellen Monitor sehe ich, dass sich der Wemos mit dem Wifi verbindet. Ich komme auch per Browser rauf. Es gibt in diesem Sketch keine Möglichkeit den 400er WR auszuwählen. Ich sehe hier nur den 600er und 1200er? Ist das korrekt? Kann ich die "Vorlage" für den 600er lassen? Meine Seriennummer lautet: 112173109786 (Kann gern in die Tabelle mit übernommen werden) Wird diese in genau dieser Form unter #define DUMMY_RADIO_ID eingetragen? Oder muss das 0x am Anfang und das ULL am Ende bleiben?
Esafreak schrieb: > Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. ... und woran hatte es dann gelegen? Grüße Gerri
Daniel R. schrieb: > File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack > return struct.unpack(fmt, self.response[base:base+size]) > struct.error: unpack requires a buffer of 2 bytes try:-except: drumrum bauen und im Fehlerfall fmt und self.response bzw. deren len anzeigen lassen! Gruß... Bert
K. J. schrieb: > Hallo. Ich habe eine Frage zum HM-400 WR > Ich nutzte die Arduino IDE mit der HoyDtuSim.ino. > Hardware: WEMOS D1 Mini + 1x NRF24L01+ verkabelt nach der Anleitung von > github. > Im Seriellen Monitor sehe ich, dass sich der Wemos mit dem Wifi > verbindet. > Ich komme auch per Browser rauf. > Es gibt in diesem Sketch keine Möglichkeit den 400er WR auszuwählen. Ich > sehe hier nur den 600er und 1200er? > Ist das korrekt? Kann ich die "Vorlage" für den 600er lassen? > Meine Seriennummer lautet: 112173109786 > (Kann gern in die Tabelle mit übernommen werden) > Wird diese in genau dieser Form unter > #define DUMMY_RADIO_ID eingetragen? Oder muss das 0x am Anfang und das > ULL am Ende bleiben? 0x und ULL verbleiben so.
Noch eine Frage.
Ich erhalte folgende Fehlermeldung:
'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not
declared in this scope
out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";
Man kann das auskommentieren dann wird der Sketch hochgeladen.
Aber wieso taucht der Fehler auf. Bzw wie kann ich das beheben?
Gerri schrieb: > Esafreak schrieb: > >> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. > > ... und woran hatte es dann gelegen? > Grüße > Gerri Hi Gerri, ich hatte verschiedene Probleme gleichzeitig. Am Anfang war der esp defekt und liess sich nicht flashen.Als ich dann einen andern genommen hatte ging es.dann hatte ich Probleme die config Seiten aufzurufen weil der access point immer nach paar Sekunden weg war und nicht auf die settings Seite weitergeleitet wurde. Nach ewigem rumprobieren war der esp dann im WLAN angemeldet und der Webserver hat die seiten zuverlässig angezeigt und ich konnte den hoymiles WR konfigurieren. Allerdings hat das funkmodul nicht mit dem WR kommuniziert. Ich musste dann noch zwei GPIOS am Esp umlöten und in den settings umkonfigurieren und dann lief das ganze. Schönes Projekt. Viele Grüße esafreak
Esafreak schrieb: > Gerri schrieb: >> Esafreak schrieb: >> >>> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. >> >> ... und woran hatte es dann gelegen? >> Grüße >> Gerri > > Hi Gerri, ich hatte verschiedene Probleme gleichzeitig. Am Anfang war > der esp defekt und liess sich nicht flashen.Als ich dann einen andern > genommen hatte ging es.dann hatte ich Probleme die config Seiten > aufzurufen weil der access point immer nach paar Sekunden weg war und > nicht auf die settings Seite weitergeleitet wurde. Nach ewigem > rumprobieren war der esp dann im WLAN angemeldet und der Webserver hat > die seiten zuverlässig angezeigt und ich konnte den hoymiles WR > konfigurieren. Allerdings hat das funkmodul nicht mit dem WR > kommuniziert. Ich musste dann noch zwei GPIOS am Esp umlöten und in den > settings umkonfigurieren und dann lief das ganze. Schönes Projekt. Viele > Grüße esafreak Was für ein wirres Geschwurbel, völlig sinnbefreit und nutzlos. Bitte versuche es nochmal und etwas strukturiert.
So, alles zusammengelötet, lief auf Anhieb! Danke an alle Verantwortlichen, die dieses Projekt vorantreiben! Ich habe 4 Fragen: 1. Der ESP8266 hat eine Antenne (geschlängelte Kupferbahn auf der Platine) und der NRF24 hat ebenfalls eine Antenne (geschraubt). Welche wird nun benutzt und ist genau wofür? Wenn beide benutzt werden, ist dann ein mögl großer Abstand zwischen beiden sinnvoll? geht ja nur um cm, aber man könnte es ja einrichten. 2. Wenn ich den "Amplifier Power Level" von MIN auf irgendwas anderes (HIGH, MAX..) stelle, verliere ich die Verbindung zu den beiden HM-1500. Hat jemand eine Vermutung, woran es liegen könnte? 3. MQTT - was genau muss ich tun, damit ich alles im Home Assistant sehen kann? Muss ich die komplette MQTT-Broker Integration hinzufügen oder reicht auch irgend ein kleines Adaptertool? 4. AHOY vs Open DTU Konkurrenz? Was ist besser? Haben beide die gleichen Funktionen? Viele Grüße Tobias
Tobias G. schrieb: > Ich habe 4 Fragen: > 1. Der ESP8266 hat eine Antenne (geschlängelte Kupferbahn auf der > Platine) und der NRF24 hat ebenfalls eine Antenne (geschraubt). > Welche wird nun benutzt und ist genau wofür? > Wenn beide benutzt werden, ist dann ein mögl großer Abstand zwischen > beiden sinnvoll? geht ja nur um cm, aber man könnte es ja einrichten. Die eine auf dem ESP ist für die WLAN Verbindung zum Router. Darauf finden die normalen Datensignal austausch statt (Webinterface,...). Auf dem NRF24 funkt zwar auch auf 2.4GHz, aber hat ein komplett anderen Protokoll aufbau (die Datenpakette sind nicht gleich wie die vom TCP). Da hier beide auf den gleicheren "Grundfrequenz" senden/empfangen, jedoch eine leichte Verschiebung aufweisen (kommt vom Kanal). Kann es ab und zu dazu kommen, das gewisse Daten nicht korrekt übertragen wurden. - Man kann es nicht ausschließen. Wenn man diese so Positioniert das beide Antennen in die jeweilige Richtung zeigen, sollte es ausreichen. ;) > 2. Wenn ich den "Amplifier Power Level" von MIN auf irgendwas anderes > (HIGH, MAX..) stelle, verliere ich die Verbindung zu den beiden HM-1500. > Hat jemand eine Vermutung, woran es liegen könnte? Kann mehrere Gründe haben, je lauter so ein Ding schreit, umso mehr stört man andere Kommunikation. Oder das Modul stört sich selbst (Mutmassung)? > 3. MQTT - was genau muss ich tun, damit ich alles im Home Assistant > sehen kann? > Muss ich die komplette MQTT-Broker Integration hinzufügen oder reicht > auch irgend ein kleines Adaptertool? Das kann jeder selbst entscheiden. Ich nutze es direkt am Raspberry Pi und MQTT. Darauf läuft gleichzeit auch mein HomeAssistant (aber noch nicht eingebunden). > 4. AHOY vs Open DTU > Konkurrenz? Was ist besser? Haben beide die gleichen Funktionen? Das ist Geschmackssache. Beides hat Vor/Nachteile. OpenDTU nutzt hier nur ein ESP. Ahoy, nutzt ESP und Raspberry Pi (in Python -> nutze ich, somit habe ich kein weiteren Client im Netzwerk).
K. J. schrieb: > 'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not > declared in this scope Ich habe mir die Source neu runtergeladen und habe keinen Fehler. Da musst du eine ältere Version haben. K. J. schrieb: > Kann ich die "Vorlage" für den 600er lassen? > Meine Seriennummer lautet: 112173109786 Nein, denn HM400 haben 1 Kanal, HM600 2 Kanäle. Somit ist die Kommunikation bzw Auswertung der Telegramme unterschiedlich. Ich werde versuchen noch heute die Tabelle für den HM400 (gilt auch für 300 und 350) zur Verfügung zu stellen.
@K.J. Die Tabelle für HM400 (HM300, HM350) ist jetzt in HoyDtuSim. Da ich es nicht testen kann, bitte Probleme in meinem Github melden.
Hubi schrieb: > K. J. schrieb: >> 'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not >> declared in this scope > > Ich habe mir die Source neu runtergeladen und habe keinen Fehler. Da > musst du eine ältere Version haben. > > K. J. schrieb: >> Kann ich die "Vorlage" für den 600er lassen? >> Meine Seriennummer lautet: 112173109786 > > Nein, denn HM400 haben 1 Kanal, HM600 2 Kanäle. Somit ist die > Kommunikation bzw Auswertung der Telegramme unterschiedlich. > Ich werde versuchen noch heute die Tabelle für den HM400 (gilt auch für > 300 und 350) zur Verfügung zu stellen. Das Problem wurde zwischenzeitlich gelöst auf Discord. Verwendet wurde die Ur-Version, jetzt läuft die AHOY in der aktuellen Version und das zuverlässig auf dem D1 mini. Danke trotzdem für die Meldung Hubi :) lg
Angehängte Dateien:
Hallo Hubi, vielen Dank für die neue Version. Mit einem HM-300 passen noch nicht alle Werte - siehe angehängter Screenshot. Leider stirbt recht schnell das Webinterface weg, die Debugausgabe via USB/Seriel-Monitor läuft dann weiter bis irgendwann ein Stracktrace kommt und neu gestartet wird. Mein Setup: Wemos D1 mini vom Makershop mit nRF24L01+.
Hallo Zusammen, keine Frage und kein Problem ;-) Ich wollte Eu nur ein kurzes Feedback geben. Habe einen Hoymiles HM800 mit 2 Pannels. Ich hatte zuerst Schwierigkeiten selbst zu kompilieren. Nachdem ich das .bin File entdeckt hatte war alles innerhalb von Minuten erledigt. Ein riesen großes Lob an alles hier beteiligten. Eure Arbeit ist sensationell. Alles läuft jetzt bei mir seid 2 Tagen perfekt. Nicht nur die Kommunikation mit dem Wechselrichter ist problemlos, auch die Übertragung an meinen ioBroker per MQTT. Hier wurden alle Datenpunkte perfekt angelegt. Ich bin so was von begeistert. Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das .bin File veröffentlichen. Vielen Dank uns weiter so.....
Hallo Zusammen, keine Frage und kein Problem ;-) Ich wollte Eu nur ein kurzes Feedback geben. Habe einen Hoymiles HM800 mit 2 Pannels. Ich hatte zuerst Schwierigkeiten selbst zu kompilieren. Nachdem ich das .bin File entdeckt hatte war alles innerhalb von Minuten erledigt. Ein riesen großes Lob an alles hier beteiligten. Eure Arbeit ist sensationell. Alles läuft jetzt bei mir seid 2 Tagen perfekt. Nicht nur die Kommunikation mit dem Wechselrichter ist problemlos, auch die Übertragung an meinen ioBroker per MQTT. Hier wurden alle Datenpunkte perfekt angelegt. Ich bin so was von begeistert. Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das .bin File veröffentlichen. Vielen Dank und weiter so.....
Angehängte Dateien:
-
IMG_20220727_200723.jpg
220 KB
Hi Leute, ich habe jetzt alles hin bekommen was das Flashen usw. angeht. Jetzt suche ich die Seriennummer von meinem Hoymiles 1500 Wenn ich die 11617.... eingebe sagt er mir immer das der Wert nicht stimmt. Ich habe aber keinen anderen Aufkleber auf meinem Wechselrichter. Könnt ihr helfen ? (Bild hängt dran) Hostname OpenDTU-%06X SDK Version v4.4.1-1-gb8050b365e Firmware Version 0.1.18 Git Hash 725d482 Reset Reason CPU 0 Vbat power on reset Reset Reason CPU 1 for APP CPU, reseted by PRO CPU Config save count 4 Uptime 0 days 00:54:12
habs eben immer unter DTU Settings eingetragen.....ich Dussel....Was muss ich bei DTU settings eintragen ? Einmal Hilfe hierzu bitte
PeterL schrieb: > Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das > .bin File veröffentlichen. Die .bin-Files sind jetzt schon unter https://github.com/grindylow/ahoy bzw. https://github.com/tbnobody/OpenDTU jeweils unter dem Menüpunkt "Actions" chronologisch aufgelistet. Zum Herunterladen muss man bei GitHub angemeldet sein.
kleine Frage hätte ich noch. Kann das den Wechselrichter auch ohne Module testen ? oder kommt dann nix? Ich war mal so frei und habe ihn eben so angeschlossen ohne alles und es hat keine Lampe oder der gleichen geleuchtet. Auch kam im OpenDTU nix an :( Danke Eike
Die Wechselrichter arbeiten nur, wenn sie mit Gleichspannung versorgt werden. Auch mit angeschlossenen Modulen sind sie nach Einbruch der Dunkelheit nicht mehr erreichbar. Im Blog gibt es Hinweise, dass man die Module zu Testzwecken durch ein geeignetes Labornetzteil ersetzen kann.
ahhhhh danke das erklärt einiges....na dann baue ich den Mist mal zusammen und die Tage aufs Carport. eike
@github Programmierer Hubi, Daniel(s), .... betrifft im Prinzip alle Sourcen ESP8266, ESP32, Raspi, phyton Heute und auch die letzten Tage sind extrem viele Fragen zu div. Dingen gekommen. S/N eintragen, muss das "ULL" stehen bleiben (im Source) ? Format Beispiel direkt im Souce als Kommentar z.B. Wo und wie kommt man direkt ohne Entwicklungsumgebung an die .bin ? Wo liegen die verschiedenen Versionen der .bin´s ? Muß es ein nrf24L01+ sein oder funktioniert auch ein nrf24L01 (ohne Plus) ? Werden hoymiles HMT und HMS auch unterstützt ? Wird DTU-Pro-S auch unterstützt ? Wird Modbus für Zähler auch unterstützt ? Stabile Stromversorgung ... Ich habe mehr als 3 hoymiles HM-..., wird das auch Unterstützt ? (muss im Source geändert werden - ich weiss - aber neue Nutzer eher nicht) Antwortet der HM-.... auch ohne angeschlossene PV Module bzw. Nachts ? Reicht ein ESP8266 mit 1MB oder muss es unbedingt ein ESP8266 mit 4MB sein ? ... Vielleicht könnt Ihr Bitte mal so die letzten Beiträge durchgehen und einiges als FAQs mit aufnehmen in der Hoffnung, das es nicht täglich neu gefragt wird ? Das könnte vielleicht auch jemand machen, der aktuell nicht mit entwickelt, aber sich gut mit github auskennt ? Vielleicht auch 1 Dokument für alle Sourcen zusammen - denn einiges wäre ja Allgemeingültig ? Nur so als Anregung.
:
Bearbeitet durch User
Hallo Leute, Klasse Projekt und Zusammenarbeit, Hut ab. Aber auch ich hänge leider etwas und habe noch keinen 100% Erfolg. Hab es mit einem MINI D1 ESP32 und einem NRF24L01+ aufgebaut. Weboberfläche läuft alles. Allerdings bekomme ich keine Verbindung zum HM-600 und somit auch keine Daten. Es werden nur Nullwerte angezeigt. Nun habe ich bisher testweise nur ein Panel und keine zwei angeschlossen. Kann das vielleicht daran liegen? WR Adresse habe ich komplett (alle Stellen) unter Inverter eingegben. Das ganze lief jetzt 2 Tage und das eine angeschlossene Panel hat tagsüber auch Strom geliefert, aber wie gesagt keine Verbindung. Ich frage mich was ich da noch falsch mache. PS: Ein Problem das ich vorher noch hatte ist dass ich nicht die Typbezeichnung des WR unter dem Menüpunkt Inverter eingegeben hatte sondern einen "freien" anderen Text. Danach verabschiedet sich der ESP32 in einer Dauerbootloop und ist nur mit einem erease_flash wieder zu retten. (Ich hatte das mit esptool erledigt aber da geht nur eine Version > 3.0, ansonsten erscheint die Fehlermeldung "kann ROM nicht löschen", leider ist unter Ubuntu noch eine ältere Version esptool gebündelt.) Habe heute erst hier im Text gelesen dass das erase_flash auch direkt aus PlatformIO heraus gehen soll. Bin mit PlatformIO noch nicht so richtig vertraut. Ein Hinweis hierzu (falschen Textstring bei Inverter) könnte anderen vielleicht diesen falschen Weg ersparen. Sylvester
Sylvester D. schrieb: > Allerdings bekomme ich keine Verbindung zum HM-600 und > somit auch keine Daten. Es werden nur Nullwerte angezeigt. Nun habe ich > bisher testweise nur ein Panel und keine zwei angeschlossen. Kann das > vielleicht daran liegen? Ich betreibe einen HM-600 z. Z. mit einem Modul und erhalte plausible Werte. Die Anschlüsse für das zweite Modul am Wechselrichter sind offen. Es ist für die Funktion unerheblich, welches Paar von Modulanschlüssen am Wechselrichter benutzt wird. Ich würde einen Defekt des nRF24L01+ nicht ausschließen.
DerJens schrieb: > Mit einem HM-300 passen noch nicht alle Werte - siehe angehängter > Screenshot. Geänderte Tabelle ist in meinem Repo. Bei mir läuft das Webinterface schon seit Wochen durch. Versuch mal mit dem Stacktrace und dem Tool "ESP Exception Decoder" die Stelle zu finden wo's crashed. Wie man das macht ist hier im Thread irgendwo zu finden bzw auch im Netz beschrieben.
Hallo Hubi, ich bekomme im Log 82er Meldungen, die sehen so aus:
1 | 12 14 16 18 20 22 |
2 | Hz P_AC ? I_AC ? TEMP |
3 | 82 138A 0121 0000 000C 03E8 011E 0006 11A2 E35F 95 // Beispiel 1 |
4 | 82 1387 0108 0000 000B 03E8 0119 0006 B62A E8ED E6 // Beispiel 2 |
Demnach müsste die Tabelle für P_AC, I_AC, Hz und Temp so aussehen:
1 | { IDX_PAC, CH0, UNIT_W, CMD82, 14, BYTES2, DIV10 },
|
2 | { IDX_IPV, CH0, UNIT_A, CMD82, 18, BYTES2, DIV100 },
|
3 | { IDX_FREQ, CH0, UNIT_HZ, CMD82, 12, BYTES2, DIV100 },
|
4 | { IDX_WR_TEMP,CH0, UNIT_C, CMD82, 22, BYTES2, DIV10 }
|
Muss U_AC dann berechnet werden? U_AC = P_AC / I_AC? Src: https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.md, Abschnitt CMD0x82
DerJens schrieb: > Hallo Hubi, ... > Muss U_AC dann berechnet werden? U_AC = P_AC / I_AC? U_AC muss nicht berechnet werden bei HM-3.. Es ist der letzte 16 Bit payload Wert /10 im Telegram 01 vor CRC. (ist im übrigen seit vor dem 10.05.2022 schon bekannt)
:
Bearbeitet durch User
Noja, dann sollte das whl so für Hubis HoyDtuSim passen:
1 | const measureDef_t hm400_measureDef[] = {
|
2 | { IDX_UDC, CH1, UNIT_V, CMD01, 14, BYTES2, DIV10 },
|
3 | { IDX_IDC, CH1, UNIT_A, CMD01, 16, BYTES2, DIV100 },
|
4 | { IDX_PDC, CH1, UNIT_W, CMD01, 18, BYTES2, DIV10 },
|
5 | { IDX_E_TAG, CH1, UNIT_WH, CMD01, 24, BYTES2, DIV1 },
|
6 | { IDX_E_TOTAL,CH1, UNIT_KWH, CMD01, 20, BYTES4, DIV1000 },
|
7 | { IDX_UAC, CH0, UNIT_V, CMD01, 26, BYTES2, DIV10 },
|
8 | |
9 | { IDX_IPV, CH0, UNIT_A, CMD82, 18, BYTES2, DIV100 },
|
10 | { IDX_PAC, CH0, UNIT_W, CMD82, 14, BYTES2, DIV10 },
|
11 | { IDX_FREQ, CH0, UNIT_HZ, CMD82, 12, BYTES2, DIV100 },
|
12 | { IDX_WR_TEMP,CH0, UNIT_C, CMD82, 22, BYTES2, DIV10 }
|
13 | }; |
DerJens schrieb: > Noja, dann sollte das whl so für Hubis HoyDtuSim passen: Wenn das dann so passt, vielen Dank. Ich habe das so dann in mein Repo übernommen.
Angehängte Dateien:
So passt es, siehe Screenshot :) Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?!
Sylvester D. schrieb: > Hallo Leute, > Klasse Projekt und Zusammenarbeit, Hut ab. > Aber auch ich hänge leider etwas und habe noch keinen 100% Erfolg. Hab > es mit einem MINI D1 ESP32 und einem NRF24L01+ aufgebaut. Weboberfläche > läuft alles. Allerdings bekomme ich keine Verbindung zum HM-600 und > somit auch keine Daten. Es werden nur Nullwerte angezeigt. Hallo welches NRF24L01+ Modul hast du denn, mit externer Antenne, LNA (Low Noise Amplifier) ? Worauf man generell achten sollte dass der ESP mit seinem eigenen Wlan und der NRF24 körperlich etwas voneinander weg montiert werden, die Sendestufen von beiden Teilen können sich gegenseitig so taub machen, dass schlichtweg nichts mehr empfangen wird. Zustopfen nennt sich dass. Ebenso sollte man auf eine gute stabile Spannungsversorgung für den NRF24 achten. Die Pinbelegung muss man entweder so nutzen wie sie im Sourcecode verankert ist oder man muss sich eine eigene Version bauen und komplilieren. Hierbei muss man aufpassen dass man Pins verwendet die auch universell so zu nutzen sind. Was sagt die serielle Schnittstelle, gibts da einen Protokollmitschnitt? Viel Erfolg Solong B
Hallo herbert, das finde ich mega gut. gerade wenn man nicht mit dem vertraut ist was hier alles so passiert. ich zum beispiel habe es hinbekommen aber kann mit diesen zeilen null anfangen. es wahr wohl mehr glück als alles andere das es läuft. wie auhc immer ein howto wie man diese dinger einfach flashen kann.oder ein tool dazu was dies macht ohne eben 23 andere tools zu installieren wäre toll. und wenn jemand das geflshed anbietet wäre ja auch so ne idee. zumindest die amazon links zu den richtigen modulen wäre schon hilfreich ohne das man es wie ich dann 3 mal hin und her schicken muss weil das falsche kam. die idee ist geboren und sie ist gut nun sollten es aber auch mehr leute nutzen können und nicht nur ne hand voll eike
Vielen Dank für die Tips. NRF24L01 +PA LNA SMA und externer Antenne. Heute Abend hat das Teil doch plötzlich mal sporadisch mit dem HM-600 geredet. Zwar nicht viel und benötigte auch einmal einen Retransmit. Es war auch das erstemal dass ich an der seriellen Schnittstelle "Interrupt received" gesehen hab und nicht nur nach einem TX RX Period End > All missing > Nothing received, resend whole request Also prinzipiell funtioniert es wohl. Ich hatte, zumindest mir bewusst, nichts geändert, nur nochmal kontrolliert ob alle Verbindungen richtig sind. Nun, der NRF und der ESP32 könnten wirklich weiter auseinander sein. Sieht wirklich so aus als wäre die Funkverbindung bzw. insbesondere der Empfang nicht sonderlich stabil, oder anderweitig gestört. Jetzt habe ich zumindest mal die Sicherheit dass die Schaltung funktioniert und die Konfiguration richtig ist. Ist auch schon mal viel Wert. Morgen probiere ich mal einen größeren Abstand zwischen den beiden Modulen (ESP und NRF). Kann gut sein dass das das Problem ist. Wenn ich rausfinde was es war lasse ich es Euch natürlich wissen. Danke schon mal für Eure Hilfe. Es ist immer etwas schwierig wenn man nicht genau weiß unter welchen Bedingungen das System wie genau reagieren soll ob man auf dem richtigen oder einem abwegigen Pfad ist. Sylvester
DerJens schrieb: > Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define > MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte > mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?! Sorry, aber das gibt meine SW leider noch nicht her. Ich habe leider nur eine Anlage auf dem Gartenhaus mit einem HM-600, das Testen mit mehreren WR also unmöglich. Ich sende zwar an alle "registrierten" Anlagen, aber die empfangenen Daten werden noch nicht korrekt zugeordnet. Da sind die Projekte OpenDTU und ahoy wohl etwas weiter. Wenn entsprechender Bedarf und auch Tester sich finden mache ich da gerne weiter.
Habe mal angefangen eine FAQ zu erstellen wie von AVR Herbi gewünscht und von Juergen vorgeschlagen im Wiki: Wie zu erwarten ist das ganze etwas Protokoll lastig geworden =^D # FAQ Häufig gestellte Fragen https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions
Stefan, danke für das Anlegen des FAQs, das ist ja schon sehr umfangreich. Mir ist aufgefallen, das oft aus der ich Perspektive geschrieben ist. Evtl. finden sich ja Freiwillige, die hier bisschen formulieren helfen :-) Finde es toll wie sich die Zusammenarbeit hier entwickelt hat.
isnoAhoy schrieb: > Habe mal angefangen eine FAQ zu erstellen wie von AVR Herbi gewünscht > und von Juergen vorgeschlagen im Wiki: > # FAQ Häufig gestellte Fragen > https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions War ja nur ein Vorschlag :-) Ich hoffe und würde es Allen, die hier schon länger und regelmäßig mitlesen wünschen, das alle Neuhinzugekommenen sich die Zeit nehmen, das zu lesen. TOP Arbeit für den Anfang ! Ich sage einfach mal Danke, auch wenn es weniger für mich ist, sondern für Andere.
Angehängte Dateien:
Rene M. schrieb: > Weiß jemand was das für Meldungen sind? > ID 12 und 46? ID 12 hatte ich auch in Zusammenhang mit Grid Overvoltage, schaut für mich wie eine wieder gut Meldung nach dem Fehler aus.
Kannst du mal ein Bild hochladen wie du das verdrahtet hast? Habe die gleiche Zusammensetzung aber die pin Belegung ist irgendwie anders an dem kleinen Board
Kannst du mal ein Bild hochladen wie du das verdrahtet hast? Habe die gleiche Zusammensetzung aber die pin Belegung ist irgendwie anders an dem kleinen Board Heinrich P. schrieb: > Hallo zusammen, > und vielen Dank für euere tolle Arbeit. > Hab mir vor 2 Tagen bei komputer.de die Chips bestellt: > 1 Stk. nRF24L01+ PA SMA mit Antenne 3.20EUR > 1 Stk. ESP32 Development board NodeMCU kompatibel 6.50EUR > Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens > mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die > beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen. > Nach nur 6 Jahren! Gruselig… > Grüße, Matze
DerJens schrieb: > Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define > MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte > mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?! Die SW HoyDtuSim aus meiner Repo [[https://github.com/hm-soft/Hoymiles-DTU-Simulation/ ]] sollte es jetzt auch mit mehreren WR können. Kann das aber leider nicht testen.
isnoAhoy schrieb: > Habe mal angefangen eine FAQ Vielen Dank, sehr gut! :) Edit: Sorry das ich hier nicht mehr so aktiv bin (mehr Discord GitHub), das hat hier teils überhand genommen und wenn ich am ReverseEngeneering dran bin kann ich nicht gleichzeitig Support spielen. :) https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-modelle-werden-unterst%C3%BCtzt - Sollen hier noch die Modelle Aufgelistet werden, damit jeder weiß welche Modelle Unterstützt werden? Ich glaube nähmlich das neue User nicht ganz sonst durchsteigen?
:
Bearbeitet durch User
Angehängte Dateien:
Sylvester D. schrieb: > Nun, der NRF und der ESP32 könnten wirklich weiter auseinander sein. > Sieht wirklich so aus als wäre die Funkverbindung bzw. insbesondere der > Empfang nicht sonderlich stabil, oder anderweitig gestört. > Morgen probiere ich mal einen größeren Abstand zwischen den beiden > Modulen (ESP und NRF). Kann gut sein dass das das Problem ist. > Wenn ich rausfinde was es war lasse ich es Euch natürlich wissen. Das Thema Abstand ESP-Board <---> nRF24L01+-Modul sollte aus meiner Sicht nicht überbewertet werden: - In der Original-DTU ist der Abstand auch nicht riesig groß, - ein realisiertes Muster von mir läuft stabil (grindylow / ahoy, Firmware 0.4.25) und, solange der Wechselrichter aktiv ist, praktisch ohne "Receive fail". Auch ein nFR24L01+-Modul mit Print-Antenne ist problemlos einsetzbar. Die Bausteine sind gesteckt, um bei Bedarf verschiedene Ausführungen testen zu können, somit ist auch der USB-Anschluss prinzipiell zugänglich. Leider ist die "Streubreite" der Qualität der nRF24L01+-Klone wohl sehr groß - siehe z. B. hier: Beitrag "Re: nRF24L01+ und PA Kombi gibt kein Acknowledge" Bei einem früheren Aufbau war ein Stecker des Dupont-Kabels "ausgeleiert" und verursachte so eine Instabilität.
isnoAhoy schrieb: > # FAQ Häufig gestellte Fragen > https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions Sehr schön, Danke an alle! Sollte jemand einen Tester für die Leistungsbegrenzung brauchen, ich und mein HM800 sind bereit. :-D
Wäre es möglich im FAQ mal mit aufzunehmen wie man ein Kommando an den WR sendet. Habe hier die Kombi Arduino / Esp 8266 mit NRF Plus, WR HM600. Wie wird die Anfrage gesendet ? Beispiel Hterm sendet per Serial TX an Arduino der nach NRF ? Ist das richtig so. Kleines Beispiel wäre nett wie man sendet. Würde gerne mittesten da ich eine Leistungsreduzierung von Vorteil sehe und von der Leistungsreduzierung AE Conversion nach Hoymiles wechseln möchte. Wünschenswert wäre halt wie beim AE ein Request aus IoBroker an den HM senden zu können damit die Energie aus der Batterie gezielt abgegeben werden kann.
Hallo, erst einmal ein großes Dankeschön für dieses tolle Projekt. Ihr habt da etwas großartiges auf die Beine gestellt :) Gerald R. schrieb: > Sollte jemand einen Tester für die Leistungsbegrenzung brauchen, ich und > mein HM800 sind bereit. :-D Ich wäre mit meinem HM600 auch am Start um die Leistungsbegrenzung zu testen :)
Hubi schrieb: > Die SW HoyDtuSim aus meiner Repo > [[https://github.com/hm-soft/Hoymiles-DTU-Simulation/ ]] sollte es jetzt > auch mit mehreren WR können. Kann das aber leider nicht testen. Soeben ausprobiert: Mit einem WR klappts, da bekomme ich nach jedem Send... eine Antwort.
1 | 18:32:03.082 -> Send... CH3 |
2 | 18:32:03.129 -> Request cmd=1 |
3 | 18:32:03.129 -> Send... CH23 |
4 | 18:32:04.160 -> rcv CH:40 00 1234567801 ... |
5 | 18:32:04.160 -> rcv CH:61 00 1234567801 ... |
6 | 18:32:06.930 -> Send... CH40 |
7 | 18:32:07.024 -> rcv CH:75 00 1234567801 ... |
8 | 18:32:07.024 -> rcv CH:61 00 1234567801 ... |
9 | 18:32:16.923 -> Send... CH61 |
10 | 18:32:17.016 -> rcv CH:23 00 1234567801 ... |
11 | 18:32:17.016 -> rcv CH:3 00 1234567801 ... |
12 | 18:32:26.958 -> Send... CH75 |
Mit 3 WR kommt sehr lange erstmal nicht.
1 | 18:36:50.507 -> Send... CH3 |
2 | 18:36:50.553 -> Send... CH23 |
3 | 18:36:50.599 -> Send... CH40 |
4 | 18:36:53.407 -> Send... CH61 |
5 | 18:36:56.406 -> Send... CH75 |
6 | 18:36:59.396 -> Send... CH3 |
7 | 18:37:02.392 -> Send... CH23 |
8 | 18:37:05.395 -> Send... CH40 |
9 | 18:37:08.413 -> Send... CH61 |
10 | 18:37:11.415 -> Send... CH75 |
11 | 18:37:14.400 -> Send... CH3 |
12 | 18:37:17.377 -> Send... CH23 |
13 | 18:37:20.386 -> Send... CH40 |
14 | 18:37:23.397 -> Send... CH61 |
15 | 18:37:26.398 -> Send... CH75 |
16 | 18:37:29.413 -> Send... CH3 |
17 | 18:37:32.399 -> Send... CH23 |
18 | 18:37:35.385 -> Send... CH40 |
19 | 18:37:38.412 -> Send... CH61 |
20 | 18:37:41.412 -> Send... CH75 |
21 | 18:37:44.387 -> Send... CH3 |
22 | 18:37:47.416 -> Send... CH23 |
23 | 18:37:50.412 -> Send... CH40 |
24 | 18:37:53.381 -> Send... CH61 |
25 | 18:37:56.423 -> Send... CH75 |
26 | 18:37:59.415 -> Send... CH3 |
27 | 18:38:02.385 -> Send... CH23 |
28 | 18:38:05.393 -> Send... CH40 |
Irgendwann kommen dann selten Antworten von allen 3 WR, dazwischen liegen aber zum Teil mehrere Minuten.
Canon.Fritz schrieb: > Ich wäre mit meinem HM600 auch am Start um die Leistungsbegrenzung zu > testen :) Wäre mit einem HM-1500 und iobroker/mqtt auch beim Testen dabei...
Günter H. schrieb: > ein realisiertes Muster von mir läuft stabil Kann man das Carrier Board käuflich erwerben, und wenn ja wo? Schaut gut aus! Gruß Stefan
Welche EXPERIMENTELLEN Software Funktionen sind bisher noch nicht im Standard enthalten (Pull Request / Merge) https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-experimentellen-software-funktionen-sind-bisher-noch-nicht-im-standard-enthalten-pull-request--merge Power Limit via mqtt https://github.com/grindylow/ahoy/pull/109
Für das Logbuch: Leerzeichen in der WR Bezeichnung innerhalb AHOY wird dadurch bestraft, dass zB keine Entitäten (über MQTT) autom. in Home Assistant erkannt werden. Leerzeichen entfernt, schwupps, alles da.
:
Bearbeitet durch User
Noch ein Beitrag für das Logbuch: Die Verbindung zum NTP Zeitgeber muss möglich sein. In den fertigen Binaries ist "pool.ntp.org" eingetragen. Im Code lässt sich das natürlich anpassen (z.B. auf einen lokalen Zeitgeber im Heimnetz), womit aber selbst compiliert werden muss. Da ich in meiner FritzBox den Geräten der Hausautomatisierung keinen Zugriff auf das Internet erlaube, bin ich da leider ein paar Stunden hängegeblieben - nun läuft aber alles. Super Forum, vielen Dank an alle kreativen Köpfe!!!!!
Mein Cloud MQTT (HiveMQ) Broker verwendet TLS-Verschlüsselung auf Port 8883, kann AhoyDTU dies unterstützen?
Angehängte Dateien:
Hallo, die Ahoy Esp8266 Version 0.4.25 verbindet sich ja gut mit meinem HassIO MQTT Broker. HassIO zeigt mit auch alle Entitäten. OpenDTU mit einem ESp32 läuft Rauch top und verbindet sich auch mit dem MQTT Broker aber HassIO zeigt mir keine Entitäten oder das Gerät an. Wo liegt da der Hund begraben?
:
Bearbeitet durch User
Problem gefunden Wie bereits zuletzt berichtet lief die HW & SW bei mir zumindest einmal kurzzeitig am Abend. Jetzt ist mir auch klar wo das Problem lag, nachdem gestern Morgen das System, ohne irgendeiner weiteren Änderung und für mich völlig überraschend, problemlos und dann den ganzen Tag anstandslos lief. Die Ursache? Die Uhrzeit zu denen ich Zeit hatte zu testen......nämlich entweder sehr sehr spät Abends oder früh am Morgen. Tagsüber habe ich es nicht laufen lassen und auch nicht mitgeloggt. Es schien einfach zu wenig Licht auf das eine am HM-600 angeschlossenen Panel. Das Panel steht testweise noch am Boden an eine Südwand gelehnt. Sobald einige Watt Leistung auf dem Panel zusammen kommen läuft die Kommunikation einwandfrei. Bei 5W ganz sicher, teilweise sogar noch im Bereich von ~1W. Ich hatte zwar gelesen dass die Kommunikation nur geht wenn Strom vom Panel erzeugt wird, deshalb ja auch die Tests am Morgen, aber das war einfach noch zu wenig Licht obwohl man als Mensch schon den Eindruck von hell, Morgendämmerung hat und farbig sieht. Als es am Abend kurzzeitig lief, hatte ich ausnahmsweise einmal deutlich früher am Abend getestet.....und gestern Morgen später als sonst...... Gestern Abend war dann die letzte Meldung mit 0,7W und heute Morgen lief es dann wiederum problemlos. Obwohl der HM-600 am 230V Netz angeschlossen ist, scheint er, ohne ausreichende Energieversorgung durch zumindest ein Panel, nicht auf den DTU zu antworten, was ja schon mal hier im Thread angesprochen wurde. Allerdings braucht es unter Umständen einfach mehr als Dämmerlicht. Ich hoffe diese Erfahrung hilft anderen, nicht den gleichen Fehler zu wiederholen. Sylvester
Tobias G. schrieb: > Leerzeichen in der WR Bezeichnung innerhalb AHOY wird > dadurch bestraft, dass zB keine Entitäten (über MQTT) autom. in Home > Assistant erkannt werden. > Leerzeichen entfernt, schwupps, alles da. Ich versuche das ganze in FHEM zu integrieren. Mit meinem Mosquitto MQTT Server hat er sich auch laut AHOY Software verbunden. Wie muss ich das Topic denn jetzt zusammen bauen ? Leider werde ich auch aus dieser Anleitung nicht ganz schlau : Power Limit via mqtt https://github.com/grindylow/ahoy/pull/109 Es wäre toll wenn mir jemand anschaulich erklärt wie ich das Topic zusammenbauen muss :) z.b. so Device Name/Inverter_0_Name/Topic
Canon.Fritz schrieb: > Es wäre toll wenn mir jemand anschaulich erklärt wie ich das Topic > zusammenbauen muss :) z.b. so Device Name/Inverter_0_Name/Topic In den Einstellungen hast du ein Base Topic. In OpenDTU schaut es folgenermaßen aus: BaseTopic/INV_Serial/Channel/Abzufragender_Wert Beispiel: solar/116181101507/0/power Channel 0 ist AC, Channel 1 und folgende (max. 4) sind die DC-Eingänge. Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was alles kommt und wie es bei dir genau aussieht. Für die DTU sieht es so aus: solar/dtu/name solar/dtu/uptime solar/dtu/ip
Canon.Fritz schrieb: > > Ich versuche das ganze in FHEM zu integrieren. Mit meinem Mosquitto MQTT > Server hat er sich auch laut AHOY Software verbunden. > Ich habe das MTTQ2 Modul von FHEM definiert, also keinen extra mosquito installiert und der MTTQ2 hat bei mir dann automatisch ein MTTQ-Device mit allen readings angelegt.
Test über Nacht, Kombi WemosD1 mit Ahoi 0.4.25 Morgens Spannung der Module da Spannung sichtbar mit Sonoff Dual R3 Keine Daten empfangen, gesendet werden 6 gleiche Pakete Transmit 27 | 15 Last Frame missing usw mit anderem Zeitstempel Reboot keine Besserung Wemos Stromlos Keine Daten empfangen, gesendet werden 1 mal 6 gleiche Pakete Transmit 27 | 15 Last Frame missing Keine Daten empfangen, gesendet wird 1 Pakete Transmit 27 | 15 danach 95er Pakete unterschiedlicher Anzahl, Last Frame missing Pakete 27 | 15 mit 95er werden 5 mal angezeigt Danach Daten Receive mit Transmit 11 | 15 Transmit 11 | 15 81 86 77 21 78 56 34 12 82 CE 95 81 86 77 21 81 86 77 21 02 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 BE AF 95 81 86 77 21 81 86 77 21 02 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 BE AF I: Payload (42): 00 01 01 03 00 4D 00 C7 00 08 00 02 00 00 00 00 2B 16 00 00 00 00 00 3F 00 00 09 1A 13 84 00 BE 00 00 00 08 03 E8 01 0C 04 30 Soweit der Übernachttest
DerJens schrieb: > Soeben ausprobiert: > Mit einem WR klappts, da bekomme ich nach jedem Send... eine > Antwort.18:32:03.082 -> Send... CH3 > 18:32:03.129 -> Request cmd=1 > 18:32:03.129 -> Send... CH23 > 18:32:04.160 -> rcv CH:40 00 1234567801 ... > 18:32:04.160 -> rcv CH:61 00 1234567801 ... > 18:32:06.930 -> Send... CH40 > 18:32:07.024 -> rcv CH:75 00 1234567801 ... > 18:32:07.024 -> rcv CH:61 00 1234567801 ... > 18:32:16.923 -> Send... CH61 > 18:32:17.016 -> rcv CH:23 00 1234567801 ... > 18:32:17.016 -> rcv CH:3 00 1234567801 ... > 18:32:26.958 -> Send... CH75 > > Mit 3 WR kommt sehr lange erstmal nicht.18:36:50.507 -> Send... CH3 > 18:36:50.553 -> Send... CH23 > 18:36:50.599 -> Send... CH40 Probier mal in der Settings.h andere Einstellungen, zB #define PA_LEVEL RF24_PA_MAX oder RF24_PA_HIGH. Außerdem wird die Wartezeit (WAIT_TILL_NEXT_SEND) bis zum nächsten Senden auf dir WRs aufgeteilt, also bei 3 WR wird lediglich 3 Sekunden gewartet. setze mal fest WAIT_TILL_NEXT_SEND=10 am Ende von setupInverters()
Angehängte Dateien:
-
IMG_20220704_082950066.jpg
370 KB -
IMG_20220730_190647241.jpg
160 KB
Günter H. schrieb: > Das Thema Abstand ESP-Board <---> nRF24L01+-Modul sollte aus meiner > Sicht nicht überbewertet werden: Selbiges hier - Läuft auf beiden Platinen fehlerfrei, auch unter 04.22 - Ebenfalls steckbar. Auch hatte ich einen Wemos D1mini-Clone, der fehlerhaft war.
Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen. 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann einfach email mit Postanschrift an derbuchner@gmail.com Es ist dieses Fritzing File hier: https://github.com/tbnobody/OpenDTU/tree/master/docs P.S: Ich seh das ganze als "Pay It Forward" Aktion :-)
Joni N. schrieb: > Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen. > 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann > einfach email mit Postanschrift an derbuchner@gmail.com > > Es ist dieses Fritzing File hier: > https://github.com/tbnobody/OpenDTU/tree/master/docs > > P.S: > Ich seh das ganze als "Pay It Forward" Aktion :-) Ging schnell ... sind jetzt alle weg :-D
Joni N. schrieb: > Ich hab mir 5 PCBs (Mindestmenge) machen lassen, die sind eben gekommen. > 3 davon könnte ich kostenlos abgeben. Falls jemand eines will, dann > einfach email mit Postanschrift an derbuchner@gmail.com > > Es ist dieses Fritzing File hier: > https://github.com/tbnobody/OpenDTU/tree/master/docs > > P.S: > Ich seh das ganze als "Pay It Forward" Aktion :-) Wo hast Du die machen lassen? Würde die mit deiner Erlaubnis (Datei) fertigen lassen.
Hubi schrieb: > Probier mal in der Settings.h andere Einstellungen, zB > #define PA_LEVEL RF24_PA_MAX oder RF24_PA_HIGH. > Außerdem wird die Wartezeit (WAIT_TILL_NEXT_SEND) bis zum nächsten > Senden auf dir WRs aufgeteilt, also bei 3 WR wird lediglich 3 Sekunden > gewartet. > setze mal fest WAIT_TILL_NEXT_SEND=10 am Ende von setupInverters() Soeben ausprobiert: - bei PA_LEVEL auf HIGH ändert sich nichts - bei WAIT_TILL_NEXT_SEND=10 dauert es länger bis ein Send... kommt, es kommt aber trotzdem nicht schneller eine Antwort. Zum Teil nur von einem WR, von den anderen kommen gar keine Antworten. Ich habe mal jeden WR einzeln mit MAX_ANZ_INV 1 angesprochen, da kommt bei jedem innerhalb der ersten 1-2 Send... eine Antwort. Ich habe den Eindruck, dass mit mehreren WR die Antworten irgendwie nicht mehr erwischt werden...?
Steffen D. schrieb: > Wo hast Du die machen lassen? Würde die mit deiner Erlaubnis (Datei) > fertigen lassen. Die Datei ist ja nicht von mir, sondern von tbnobody ;-) https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz Fertigen habe ich sie bei JLCPCB lassen. Ging super einfach. Hier die Anleitung wie du aus dem .fzz ein Gerber File machst: https://support.jlcpcb.com/article/171-how-to-generate-gerber-and-drill-files-in-fritzing
Hallo, bin schwer beeindruckt, was ihr hier geschafft habt!
Kennt jemand folgendes Verhalten?
Es sieht aus, als würde mein HM-600 erst genau 1800 Sekunden (30
Minuten) nach seinem Start antworten, also nachdem DC Spannung vom
Labornetzteil am Wechselrichter-Eingang vorhanden ist.
Die ersten 30 Minuten schweigt er einfach ("All missing" im Log), danach
antwortet er ziemlich zuverlässig ("Interrupt received" im Log).
All meine vorangegangenen Fehlversuche mit Kondensatoren, anderen
Antennen, Abstand, anderen NRF-Modulen, ESP-Neustarts usw. hatten gar
keinen Einfluss. Es waren schlicht die 30 Minuten Wartezeit. Das könnte
auch die Probleme manch anderer Forenteilnehmer beim RX erklären.
Versuchsaufbau: OpenDTU auf ESP32 mit NRF24L01+, HM-600 mit
Labornetzteil am DC-Eingang
(War da nicht auch was mit Epoch-Zeitstempeln in den Nachrichten? Nur
mal gesponnen, vielleicht ja irgendein Schutz vor Replay-Attacken
basierend auf Zeitstempeln?)
Joni N. schrieb: > https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz > Fertigen habe ich sie bei JLCPCB lassen. Ging super einfach. > Hier die Anleitung wie du aus dem .fzz ein Gerber File machst: > https://support.jlcpcb.com/article/171-how-to-generate-gerber-and-drill-files-in-fritzing Okay wie ich sehe ist es nur die Platine mit Lötaugen für den ESP32 und den NRF+ ohne Leiterbahnen!? Du kannst mir gerne auch das Gerber File zukommen lassen. Ich muss mich erstmal mit Fritzing und autoroute beschäftigen.
:
Bearbeitet durch User
Habe hier inzwischen einen WimosD1 mit Ahoi 0.4.25 in Dauerbetrieb laufen. Großartige Leistung von allen die die Software bis hier vorangetrieben haben. Bei mir bringt der Ahoi sehr zuverlässig seine Daten und überträgt die auch zuverlässig zu einem Mosquito MQTT Server, auch über den Tageswechsel. Es sollte aber sichergestellt sein, das der Abstand zwischen HM ( hier ein HM400) und dem Aufbau nicht zu groß ist und ein mehr oder weniger freies Funkfeld besteht. Bei 2,4 GHz wirken sich gemauerte Wände doch schon erheblich aus. Was mir allerdings aufgefallen ist, wenn man zwei Ahoi's betreibt ( einen Produktiv und einen zur Fehlersuche des MQTT reconnect Problems ; auch mit unterschiedlichen Device-Namen im Setup ) stören sich diese beim versenden der MQTT Daten. Ursache ist, das beim MQTT anmelden nicht der Device-Name wie im Setup eingetragen genommen wird, sondern der im Source-Code voreingestellte. Nachdem ich hier eine Erweiterung in der App.cpp und MQTT.h eingebaut habe, so das auch hier der Devicename aus dem Setup genommen wird, stören sich die beiden Ahoi's nicht mehr. Ausserdem habe ich eine kleine Anpassung eingebaut, so das nach jeder erfolgreicher Datenaufbereitung, mit einer Verzögerung von 2 Sekunden, die neuen Daten per MQTT übertragen bekomme, indem ich den MQTT Intervall Zähler auf "MQTT-Intervallzeit - 2" setze.
DerJens schrieb: > Ich habe mal jeden WR einzeln mit MAX_ANZ_INV 1 angesprochen, da kommt > bei jedem innerhalb der ersten 1-2 Send... eine Antwort. Ich habe den > Eindruck, dass mit mehreren WR die Antworten irgendwie nicht mehr > erwischt werden...? Ich konnte testweise einen 2. WR simulieren, indem ich meinen einzigen WR 2x lade, mit je richtigen und falschen SerialNo beim Senden und Empfang warten. Und es funzt jetzt. Update ist im Repo. @DerJens: Wenn's bei dir immer noch Probleme gibt, schreib per Mail an hubi.mora(at)gmail.com
Hallo, ich bin auf der Auswahl eines Mikrowechselrichters auf dieses Forum gestoßen. Ich möchte bei dem zukünftigen Modell keinem Cloud-Zwang unterworfen sein und die Ausgangsleistung des Wechselrichters begrenzen können. Das aber nur zur Einordnung. Zu Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" : Aus Interesse habe ich mir das gitee-Repository zur DTU-PRO geladen. Ein Repository vergisst nichts :-) Vor dem Commit mit dem Text "Document" mit der Commit-Kennung 2d24e2b7a261282501b44da26a5693d5033e8ba6 finden sich viele gelöschte Dokumente, unter anderem auch RF通讯协议-V6.6.xlsx (übersetzt RFprotocol-V6.6.xslx). Vielleicht finden sich dort aktuellere Informationen als in V6.5. Ansonsten finden sich in den älteren Commits sehr viele gelöschte Verzeichnisse und Dateien. Ich forsche mal noch weiter ... Dieses Forum und die Teilnehmer machen Lust darauf sich zu beteiligen. Danke für die bisher geleistete Arbeit.
Ergänzend: Es gibt zwei Repositories bei gitee zum gleichen Thema: https://gitee.com/iotloves/hoymiles-DTU-PRO https://gitee.com/michel_individual_organization/hoymiles-DTU-PRO Das Erstere ist jünger. Ich habe mich daraus bedient.
Hi, ich reihe mich ein in die vielen Danksagungen. Ich habe mit die fertige 0.4.25 hier aus board runtergeladen. auf github (unter actions) finde ich Sie jedoch nicht. Gibt es eine Möglichkeit das Abfrageintervall MQTT von 90s zu reduzieren, damit die Daten ein bissl aktueller sind? VG
Daniel M. schrieb: > Du kannst mittels MQTTExplorer oder MQTTfx auf dem Broker schauen, was > alles kommt und wie es bei dir genau aussieht. Ich konnte die Topics mittels MQTT Explorer raussuchen. Besten dank für den Tipp :) Nun funktionierte auch bei mir die Integration in Fhem. Jetzt stellt sich mir nur noch die Frage wie ich den Topic für die Leistungslimitierung formen muss. Ich verwende die Ahoy 0.4.25.bin hier aus dem Forum, da mir VS Code immer 70 Fehler beim kompilieren rauswirft und ich mir daher keine eigene .bin exportieren kann ;( Ich hoffe es geht auch schon in dieser Version.
guilligan71 schrieb: > Hi, ich reihe mich ein in die vielen Danksagungen. > Ich habe mit die fertige 0.4.25 hier aus board runtergeladen. auf github > (unter actions) finde ich Sie jedoch nicht. > Gibt es eine Möglichkeit das Abfrageintervall MQTT von 90s zu > reduzieren, damit die Daten ein bissl aktueller sind? > > VG Das geht wohl schon über die config.h. aber so tief bin ich noch nicht in der Materie drin. Dann warte ich wohl noch ein bissl und versuche mich schlau zu machen wie man selbst compilen kann. Dazu habe ich leider noch keine (ausführliche) Anleitung für Anfänger gefunden. Weiter so *daumenHOCH
Angehängte Dateien:
-
setup.png
22 KB
Ich habe mich nochmal als Programmierer versucht und in die aktuelle Ahoy Version von grindy https://github.com/grindylow/ahoy.git die SD-Karte eingepflegt. Dieses mal an - und abwählbar mit einstellbarem Intervall im setup.html. Der CS pin für die SD kommt auf D0. Ich würde gerne die Firmware hier zur Verfügung stellen, bin mir aber nicht ganz sicher welche der beiden die Richtige ist. Selsamer Weise flasht PlatformIO meine D1 mini 2x. zuerst /build/d1_mini/firmware.bin sofort danach mit /build/node_mcu_v2/firmware.bin Ich nehme an beide sind ident sonst würde ja mein D1 mini mit der node_mcu_v2 firmware nicht funktionieren.
Tja, wer lesen kann ... Stehen ja beide in der platform.ini. Also hier die Firmware dazu für diejenigen die sie nicht selber bauen können oder wollen.
Habe testweise mal in Ahoy MIN_MQTT_INTERVAL auf 10 gesetzt. Könnt ihr ja testen. Ist die Version mit SD-Karte, die muss man ja nicht nutzen. Keine Ahnung ob das dann auch funktioniert.
Gerald R. schrieb: > Ich habe mich nochmal als Programmierer versucht und in die aktuelle > Ahoy Version von grindy https://github.com/grindylow/ahoy.git die > SD-Karte eingepflegt. > Dieses mal an - und abwählbar mit einstellbarem Intervall im setup.html. > > Der CS pin für die SD kommt auf D0. > > Ich würde gerne die Firmware hier zur Verfügung stellen, bin mir aber > nicht ganz sicher welche der beiden die Richtige ist. > Selsamer Weise flasht PlatformIO meine D1 mini 2x. > zuerst /build/d1_mini/firmware.bin > sofort danach mit /build/node_mcu_v2/firmware.bin > Ich nehme an beide sind ident sonst würde ja mein D1 mini mit der > node_mcu_v2 firmware nicht funktionieren. Hallo Gerald, ich habe noch mal schnell das diff File überflogen: Kann es sein das die SD Karte initialisiert wird ohne das Flag zu prüfen ob die SD Karte ein oder ausgeschaltet ist? Zeile mit Code „if (!SD.begin(chipSelect)) {„ Könnte ja sein das jemand gerne den Code übernimmt aber noch keine SD Karte angeschlossen hat ? Gruß Sven
Wie ich schon auf Discord bekannt gegeben hab, sind 30 Platinen von mir unterwegs. Kommen wohl nächste Woche. Ich gebe die gerne für 3 € das Stk ab. Oder auf Wunsch auch fertige Geräte.
Holger S. schrieb: > Wie ich schon auf Discord bekannt gegeben hab, sind 30 Platinen von mir > unterwegs. Kommen wohl nächste Woche. Ich gebe die gerne für 3 € das Stk > ab. Oder auf Wunsch auch fertige Geräte. Top, sind die für den Wemos oder den Esp32?
Sven K. schrieb: > Kann es sein das die SD Karte initialisiert wird ohne das Flag > zu prüfen ob die SD Karte ein oder ausgeschaltet ist? > Zeile mit Code > > „if (!SD.begin(chipSelect)) {„ > > Könnte ja sein das jemand gerne > den Code übernimmt aber noch keine > SD Karte angeschlossen hat ? > > Gruß Sven Hallo Sven! Ja, das hast du richtig gesehen. Beim jedem Start wird überprüft ob eine SD vorhanden ist. Da könnte man noch nachbessern, danke für den Hinweis! Hatte aber in meinen Tests ohne SD keinen negativen Einfluss und es wird nicht versucht zu schreiben nach dem die Meldung: I: SD card failed, or not present kommt. Das habe ich mit einer LED am CS pin überprüft. Werde das morgen nochmal probieren, denn ohne Sonne wird nichts geschrieben ;-)
Angehängte Dateien:
-
mqtt.PNG
20 KB
Hallo zusammen, hat jemand eine Idee, was man gegen "MQTT: not connected" tun kann? Mal läuft es bei mir einen Tag durch, dann alle 30 Minuten der Verbindungsabbruch. Es hilft dann nur ein Reboot. 0.4.25 ist installiert, AHOY befindet sich ca 1,5m direkt neben den Hoymiles.
Hallo allerseits, ich hatte mir auch ein paar Platinen fertigen lassen. Falls Bedarf besteht gebe ich von diesen gerne welche ab. https://www.ebay-kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoy-dtu-esp8266/2171544569-168-9361
Also bei mir läuft MQTT ansich sehr stabiel ( bei mir ein Mosquito MQTT Server auf Debian 11 ). Mir ist nur mal aufgefallen, wenn der Ahoi zu dicht am WLAN Access Point dran ist, wird der Empfänger für die Verbindung zum HM400 hin und wieder gestört ( Zustop effeckt ).Das kann natürlich auch anders herum vorkommen. Beide senden im gleichen Frequenzband. Ein Problem ergibt sich noch , sobald der MQTT Client von Ahoi ( 0.4.25 ) die Verbindung zum MQTT Server verliert. Die Reconnect Procedure in der mqtt.h wird sauber aufgerufen, nur bekomme der TCP_Client der unter der MQTT Verbindung liegt, die Verbindung nicht wieder aufgebaut ( Soweit konnte ich das bis jetzt nochvollziehen ). Nach einer Verbindungsunterbrechung bringt der MQTT Client sauber den Status -3 ( LOSS CONNECTION ) und der TCP-Client bringt den Status 0. Danach bekommt der TCP Client bzw. der MQTT Client die Verbindung nicht wieder aufgebaut. Ich habe es hier schon mit einem Disconnect probiert ( nachdem festgestellt wurde das die MQTT Verbindung abgebrochen ist ) bzw. mit einer Verzögerung vom bis zu 60 Sekunden bevor ein neuer connect Versuch unternommen wird. Auch ein "flush" und ein "stop" der TCP Verbindung haben keine Verbesserung der Situation gebracht.
Danke für Deinen Hinweis @Horst ich selbst kann damit aber nur wenig anfangen. Ich hoffe auf eine neuere Firmware, die das Problem behebt, da es ja mehrere User haben.
Angehängte Dateien:
Hallo, das soll jetzt keine Werbe Veranstaltung werden, aber wen es interessiert, hier mal ein paar Bilder von meinem Platinen Layout das ich entworfen und bestellt habe. Ich würde 3,- pro Platine + 1,60 Versand nehmen. Wer nicht löten kann oder will, kann auch ein fertiges Gerät für 45,- inc Versand bekommen. Nur ein Angebot... Keine Profitabsichten ;-) Ich hab das eigentlich für mich und meinem Kumpel gemacht, und weil ich mit KiCad umgehen lernen wollte. Nun kann und soll aber auch gerne die Community was davon haben.
Hi, ich bekomme keine Connect hin zum Wechselrichter. ich habe nicht in den DTU settings eingetragen muss da was rein ? Wlan klappt zu dem Modul....nur eben nicht zum Wechselrichter ideen ? eike
Betreffend SD init. So wird die SD Karte nur dann initialisiert wenn man das Loggen im Setup aktiviert.
1 | if(mSDValues == true) |
2 | {
|
3 | if (!SD.begin(chipSelect)) { |
4 | DPRINTLN(DBG_INFO, String("SD card failed, or not present")); |
5 | // don't do anything more:
|
6 | return; |
7 | }
|
8 | DPRINTLN(DBG_INFO, String("SD card initialized.")); |
9 | }
|
Ob das notwendig ist, keine Ahnung. Ich habe wie bereits erwähnt keine Nachteile durch eine nicht vorhandene SD bemerkt. Aber trotzdem nochmal ein bin und ein diff für diese Version.
Eike schrieb: > ich habe nicht in den DTU settings eingetragen muss da was rein ? > > Wlan klappt zu dem Modul....nur eben nicht zum Wechselrichter Du musst die Seriennummer deines Wechselrichters im Setup eintragen damit sich dein DTU damit verbinden kann. Die Seriennummer findest du auf einem Aufkleber am Wechselrichter.
ja in inverter settings aber doch nicht in dtu settings oder ?
Ich nehme an es geht um OpenDTU? Das habe ich gerade nicht in Betrieb, aber da sollte eine Seriennummer für den DTU bereits eingetragen sein. Funktionierte bei mir auf Anhieb. Verkabelung OK? Der verwendete NRF24 ist auch sicher ein NRF24L01+?
Jau da war auch eine drin die habe ich bei ersten Male gelöscht weil ich dachte ich muss da meine serial eintragen
Die ist standardmäßig drinnen 99978563412
Eingetragen...klappt nicht wie nah muss das Teil beim Umrichter sein?
@Eike Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist, d.h. DC-seitig Spannung hat und die LED blinkt. Ursache unbekannt. Kann es daran liegen?
ich habe noch einen tasmota powr r2 dran der misst schon die ganze zeit also power hat die kiste und alles klappt.......ich verstehe es nicht......ich kann sonst morgen mal ein foto von meinem Gehäuse machen
Gerald R. schrieb: > Verkabelung OK? > Der verwendete NRF24 ist auch sicher ein NRF24L01+? System Info Firmware Information Hostname OpenDTU-%06X SDK Version v4.4.1-1-gb8050b365e Firmware Version 0.1.18 Git Hash 12df602 Reset Reason CPU 0 Vbat power on reset Reset Reason CPU 1 for APP CPU, reseted by PRO CPU Config save count 14 Uptime 0 days 00:28:17 Hardware Information Chip Model ESP32-D0WDQ6 Chip Revision 1 Chip Cores 2 CPU Frequency 240 MHz Memory Information Type Usage Free Used Size Heap 31% 211 KByte 95 KByte 306 KByte LittleFs 4% 308 KByte 12 KByte 320 KByte Sketch 78% 335 KByte 1201 KByte 1536 KByte
https://www.amazon.de/gp/product/B07Z83MF5W/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1 das gekauft https://www.amazon.de/gp/product/B09MKCZ7WT/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1 und das
locke987 schrieb: > Wäre mit einem HM-1500 und iobroker/mqtt auch beim Testen dabei... Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein einfaches Tutorium empfehlen, wie ich in ioBroker ein Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin MQTT-Neuling, aber sehr interessiert.
Angehängte Dateien:
Zur Diskussion mit den Abständen zwischen ESP8266 und nRF24 kann ich nur sagen: ich kann Eure Probleme nicht nachvollziehen, mit einem HM-1500 in 10m Entfernung hinter einer Hausecke. Ich habe meine Breadboard-Lösung (Bild rechts) mit 10 cm Kabel zwischen ESP und nRF heute zerlegen müssen (Breadbord wurde gebraucht) und den ESP auf eine 50-polige SCSI-Buchsenleiste (für Flachband-Schneidklemm-Montage) gesteckt, den nRF kurz dahinter und alles per hand "gecrimpt". Abstand zwischen WLAN-Antenne und nRF-Modul nur noch ca. 10 MILLIMETER, und zwar die WiFi-Antenne direkt neben dem nRF (Bild links). Läuft hinreichend stabil! Ja, nur jedes 3 Frame ist ein Receive success. Aber da sabbelt ja auch noch ein original DTU-Pro dazwischen.
:
Bearbeitet durch User
Holger F. schrieb: > Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist Mein HM-1500 scheint erst zu antworten, sobald er in Summe 2 Watt von den Modulen bekommt, jedenfalls ist das der kleinste Wert, den ich Life sehe. Ich weiss nicht, ob er dabei die MPP Kurve durchprobiert oder einfach nur ein paar Minuten lang angeschlossene Module stabil sehen will. Wäre das ein Hinweis für Dich? 30 Minuten sind es mit dem 1500er eher nie. Na, vielleicht an Schlechtwettertagen. Aber beobachtet habe ich bislang eher wenige einstellige Minuten. Habe Ahoy gerade in ioBroker eingebunden, dann kann man es vllt. genauer nachvollziehen. B.T.W: An die Cloud senden der DTU-Pro und der DTU-W die Info zudem nur, wenn die Ports von vorne beginnend bestückt sind. Hatte zwei Tage mal A1 und A2 ab, da hat Ahoy kein Problem mit, aber die Cloud-DTUs sehen das als Störung und melden auch die Leistung nicht weiter, obwohl die Anlage auch laut 230V Zähler schön produziert. Das soll jetzt keine Aufforderung sein, die Macke in Ahoy nachzubilden =:-)
Angehängte Dateien:
-
Ahoy-Setup-Sample.png
64 KB
Eike schrieb: > ich bekomme keine Connect hin zum Wechselrichter. > ich habe nicht in den DTU settings eingetragen muss da was rein ? schau mal in den angehängten Screenshot
von Klaus H. (klahi) > Zu Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" : Aus Interesse > habe ich mir das gitee-Repository zur DTU-PRO geladen. Ein Repository > vergisst nichts :-) Vor dem Commit mit dem Text "Document" mit der > Commit-Kennung 2d24e2b7a261282501b44da26a5693d5033e8ba6 finden sich > viele gelöschte Dokumente, unter anderem auch RF通讯协议-V6.6.xlsx > (übersetzt RFprotocol-V6.6.xslx). Vielleicht finden sich dort aktuellere > Informationen als in V6.5. > Ansonsten finden sich in den älteren Commits sehr viele gelöschte > Verzeichnisse und Dateien. Ich forsche mal noch weiter ... Das ist interessant, muß das mal extrahieren und durch den Translator schicken von Maik R. (bastelbarney) > An die Cloud senden der DTU-Pro und der DTU-W die Info zudem nur, wenn > die Ports von vorne beginnend bestückt sind. Hatte zwei Tage mal A1 und > A2 ab, da hat Ahoy kein Problem mit, aber die Cloud-DTUs sehen das als > Störung und melden auch die Leistung nicht weiter, obwohl die Anlage > auch laut 230V Zähler schön produziert. Ja das kann ich aus dem Source Code in UsartNrf3_Process_DevRunReality aka UsartNrf3_Process_DevRunDebug bestätigen. Dort werden die Werte immer überprüft bevor sie übernommen werden. Wenn er 0 Werte findet springt er aus der Parser Routine. Auch das Bild mit den Angaben zur Konfiguration ist prima, werde es demnächst mal in die FAQ übernehmen. PS: Ich habe die FAQ aktualisiert. Jetzt sind Dank @klahus1 einige DevInform Kommandos und deren Antworten dazugekommen. Vielleicht kann / wollen das einige implementieren, da man damit auch die FW / HW Version der Wechselrichter auslesen könnte. https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions
Hallo Klaus H., kannst Du eventuell den Link zum Git Commit / Dokument angeben ? Ich habe nur 6.4 und 6.3 gefunden und die bereits bekannte aktuellste 6.5. Ich würde mir gerne mal die 6.6 ansehen wenn ich Sie zu lesen bekomme.
Found it: RF通讯协议-V6.6.xlsx last entry from 2020.03.10
Angehängte Dateien:
-
hm600.JPG
110 KB
Zu dem Problem, dass keine Daten kommen, kann ich folgendes hinzufügen. Mein Steckbrett liegt seit Wochen an einem "geeigneten" Ort, mittlerweile habe ich die Sendeleistung auf MIN eingestellt und es funktioniert. Abstand 20m, eine Ziegelwand. ABER ich hatte es auch schon, dass nach einem OTA erstmal keine Daten geliefert wurden. Erst nach einem längerem Zeitfenster konnte des ESP Daten liefern. Evlt. ein Problem mit fehlerhaften Zeitstempeln in den Abfragen? Sprich nach dem Neustart ist das Datum/Uhrzeit des ESP im Vergleich zum WR in der Vergangenheit und deshalb können keine Daten geliefert werden? Nur eine Vermutung. Im Anhang eine Grafik wie die Produktion am Morgen beginnt.
Maik R. schrieb: > schau mal in den angehängten Screenshot Ich kann da gar nichts eintragen, da ich opendtu habe :( Eike
Hat schon mal jemand versucht ein Scanner zu bauen für Wechselrichter, deren Seriennummer nicht bekannt ist? Gibt es eine Broadcast Seriennummer auf die alle antworten oder Bruteforce?
Angehängte Dateien:
Hallo Mein Ahoy läuft ganz gut soweit. Habe einen Shelly auch drauf hängen, siehe Screenshot. Mqtt in Richtung IoBroker funzt auch gut. Nur welcher Wert ist nun der richtig von dem was ich Einspeise in mein Haus? P_AC oder P_DC ? Der Shelly misst und zeigt immer gleich mit P_DC. Welchen soll ich in IoBroker loggen zum auswerten? Danke für die tolle Arbeit. LG Thomas
Tom K. schrieb: > Hallo > Mein Ahoy läuft ganz gut soweit. > Habe einen Shelly auch drauf hängen, siehe Screenshot. > Mqtt in Richtung IoBroker funzt auch gut. > Nur welcher Wert ist nun der richtig von dem was ich Einspeise in mein > Haus? > P_AC oder P_DC ? > Der Shelly misst und zeigt immer gleich mit P_DC. > Welchen soll ich in IoBroker loggen zum auswerten? > > Danke für die tolle Arbeit. > LG Thomas P_AC logge ich mit. Der Shelly ist zu ungenau. Meiner zeigt zuwenig an. P_DC ist Leistung des Moduls (Gleichspannung).
ACHTUNG: Laienerklärung: P_DC --> Power DC ist die erzeugte Leistung der Module in Gleichstrom P_AC --> Power AC ist die erzeugte Leistung in Wechselstrom des WR aus dem gelieferten Gleichstrom. Die Differenz ist der bei der Umwandlung entstehende Verlust bei der Umwandlung. Bzw. der Wirkungsgrad. PV1_P_DC + PV2_P_DC = HM-800_P_DC Efficiency 95.26% == P_DC / P_AC *100 -> Wirkungsgrad
Maik R. schrieb: > Holger F. schrieb: >> Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist > > Mein HM-1500 scheint erst zu antworten, sobald er in Summe 2 Watt von > den Modulen bekommt, jedenfalls ist das der kleinste Wert, den ich Life > sehe. ... Wäre das ein Hinweis für Dich? Danke, aber die 30 Minuten Wartezeit scheinen noch was anderes zu sein. Vom Labornetzteil habe ich sofort 30 V mit max. 2 A, also max. 60 Watt. Ohne Verbindung zum AC-Stromnetz nimmt sich mein HM-600 1.1 Watt zum Betrieb; ab da lebt (blinkt) er. Habe jetzt nochmal ganz genau gemessen: Es dauerte genau 29 Minuten 50 Sekunden zwischen Anschalten meines Labornetzteils auf der DC-Eingangsseite bis zum ersten erfolgreichen Datenempfang in OpenDTU. Ab dann stabiler Empfang. Das ist unabhängig von - DC an String 1 oder 2 - AC-Seite mit Stromnetz verbunden oder nicht - erfolgreicher Datenlieferung vor WR-Neustart (vor DC aus-ein) oder nicht - OpenDTU Neustarts => Jeder neue WR-Start bringt wieder die 30 Minuten Zwangspause. Ha F. schrieb: > ABER ich hatte es auch schon, dass nach einem OTA erstmal keine Daten > geliefert wurden. Erst nach einem längerem Zeitfenster konnte des ESP > Daten liefern. Evlt. ein Problem mit fehlerhaften Zeitstempeln in den > Abfragen? Ich habe auch irgendeine Logik auf Basis der Zeitstempel im Verdacht. OpenDTU sendet aber erst nach erfolgreichem NTP-Sync Abfragen zum WR, das habe ich im Code so gesehen und mit ein paar Debug-Ausgaben überprüft. Der erste für Abfragen verwendete Zeitstempel war bereits korrekt und Rücksprünge konnte ich nicht sehen. Hat der HM-600 eine gepufferte Uhr?
Bei meinem HM-600 mit ESP8266 mit Ahoi ist seriell zu sehen das nur Transmit 27 / 15 gesendet wird mit der Fehlermeldung das ein Frame fehlt. Erst nach Stromtrennung des ESP wird dann Transmit 11 / 15 gesendet worauf der Payload angezeigt wird.Zeitstempel sind aber ok.
Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot und ich erreiche das Teil gar nicht mehr. Wie bekomme ich eine bin von dem ayoli zeig her ? Eike
Angehängte Dateien:
-
OpenDTU.jpg
58 KB
Also das OpenDTU Mist ist kann ich nicht behaupten. (würde ich auch nicht blos wenns mal wo klemmt) ich würde wenns schon nicht funktioniert einfach noch mal von vorne beginnen. Habe beide Systeme laufen und derzeit läuft bei mir OpenDTU stabiler und länger trotz deutlich größerem Abstand zum WR.
Merkwürdig. OpenDTU läuft bei mir seit Wochen einwandfrei. Ich würde sagen, der Fehler sitzt selber vor dem Teil,....
Maik R. schrieb: > Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein > einfaches Tutorium empfehlen, wie ich in ioBroker ein > Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin > MQTT-Neuling, aber sehr interessiert. Ich mache das mit dem influxdb adapter der die Objekte bzw. geloggten Daten in eine influxdb schreibt und mittels Grafana mache ich dann die Auswertung. Tutorial habe ich leider keines. Beides habe ich als container in unraid laufen, hat keine halbe Stunde gedauert bis ich die ersten Graphen zusammen hatte.
Eike schrieb: > Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot > und ich > erreiche das Teil gar nicht mehr. > Wie bekomme ich eine bin von dem ayoli zeig her ? > > Eike Hallo, steht schon mehrfach immer wieder mal weiter oben: https://github.com/grindylow/ahoy/actions Man muss angemeldet sein! Hier die FAQ: https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu
Angehängte Dateien:
-
AC_Power.jpg
70 KB
Ich mache es mit Openhabian da ich mit IObroker generell nicht zurecht kam Mit Openhabian hat bei mit super funktioniert. (auch E2 Boxen, Smart Steckdosen, temp Messung) Anbei Vergleich Bild Gosund / WR Leistung
Hallo zusammen, zunächst einen großen Dank an alle, die das Projekt hier zustande gebracht haben! Ich bin eher 'erfahrener Anfänger' und habe hier mal eine kleine Anleitung einschl. der PIN-Belegung für den D1 mini angehängt. Das erspart dem einen oder anderen vielleicht eine längere Suche im Forum oder woanders - jedenfalls ging es mir so. Und: falls jemand mal wieder Platinen bestellen sollte - ich hätte noch Bedarf für eine Platine :-)
Könnte einer von euch nochmal das Mqtt Topic für die Leistungsbegrenzung posten? Ich habe die Ahoi Version mit der 0.4.25.bin hier aus dem Forum am laufen. WR ist der HM600 Danke ;)
Holger F. schrieb: > @Eike Mein HM-600 antwortet erst, nachdem er >= 30 Minuten aktiv ist, > d.h. DC-seitig Spannung hat und die LED blinkt. Ursache unbekannt. Kann > es daran liegen? Hallo Holger und Eike, das Problem ist bekannt, offenbar fehlt noch ein Resetbefehl für die Kommunikation. Wir analysieren das demnächst, muss aber das Dauerlogging vorbereiten. lg
Danke, ich Jan schon gedacht ich bin bescheuert. Sieht ja alles Klasse aus soweit nur ich würde gern sehen ob ich alles richtig installiert habe. Ich kann das ja nicht testen und sehen das alle Module dran sind. Danke Eike
Angehängte Dateien:
-
AlarmData_diff.png
38 KB
Hier eine Neuigkeit aus der Welt der AlarmData Events dank der Aufzeichnungen von @klahus1: Anscheinend wandern die Events aus dem AlarmData langsam nach oben raus. Ich habe nur 15 Einträge in den beiden o.g. Antworten des Wechselrichters finden können:
1 | $ sdiff -w $COLUMNS AlarmData1.txt AlarmData2.txt |
2 | 0001 | 0001 |
3 | B001 0006 8D99 8D99 0000 0000 | B001 0006 8D93 8D93 0000 0000 |
4 | B002 2783 5EC0 5EC0 FFFF E3E7 | B002 2784 5EF2 5EF2 0000 1C19 |
5 | B002 2784 5EF8 5EF8 0000 1C19 | B002 2785 5EF6 5EF6 FFFF E3E7 |
6 | B002 2785 5EFC 5EFC FFFF E3E7 | B002 2786 5F10 5F10 0000 1C19 |
7 | B002 2786 5F16 5F16 0000 1C19 | B002 2787 5F14 5F14 FFFF E3E7 |
8 | B002 2787 5F1A 5F1A FFFF E3E7 | B002 2788 5F4C 5F4C 0000 1C19 |
9 | B002 2788 5F52 5F52 0000 1C19 | B002 2789 5F50 5F50 FFFF E3E7 |
10 | B002 2789 5F56 5F56 FFFF E3E7 | B002 278A 5F6A 5F6A 0000 1C19 |
11 | B002 278A 5F70 5F70 0000 1C19 | B002 278B 5F6E 5F6E FFFF E3E7 |
12 | B002 278B 5F74 5F74 FFFF E3E7 | B002 278C 5F88 5F88 0000 1C19 |
13 | B002 278C 5F8E 5F8E 0000 1C19 | B002 278D 5F8C 5F8C FFFF E3E7 |
14 | B002 278D 5F92 5F92 FFFF E3E7 | B002 278E 6031 6031 FFFF FFFB |
15 | B002 278E 6037 6037 FFFF FFFB | B002 278F 6036 6036 0000 0005 |
16 | B002 278F 603C 603C 0000 0005 | B002 2790 71AE 71AE FFFF FFFB |
17 | B002 2790 71B4 71B4 FFFF FFFB | B002 2791 7380 7380 0000 0005 |
18 | D6EC | 6E24 |
Was mir dabei aufgefallen ist: * der ESP schickt fast immer den selben Zeitstempel mit (praktisch immer 62E98701) * die Zeitstempel in den beiden o.g. AlarmData Ausgaben differieren um ein paar Sekunden: - Event 2790 um 71B4 und beim zweiten Aufruf um 71AE. Das sind ca. 6 Sekunden. - 22:20:21.978 .. 22:20:27.649 sind 5,671 Sekunden. Ich vermute daher der WR aktualisiert seine interne RTC nachdem er immer die selbe Zeit vom ESP bekommt. Es ist also wichtig bei Retransmits und anderen Angaben immer die RTC der DTU in den Zeitstempel einfließen zu lassen, sonst gibt es die oben beobachteten Zeitverschiebungen.
Hallo, ich habe hier nach Anleitung auch mal alles in Betrieb genommen und erhalte grundsätzlich auch Daten vom Wechselrichter. Diese sind aber bisher alls andere als zuverlässig. Ich erhalte zumr Zeit 3 Arten von Datensätzen. Zum einen, die richten Werte die man auch erwarten würde. Hier passen die Werte, z.B. 500W P_AC, YieldDay passt z.B. auch. Einige Sekunden später werden dann mal wieder alle Werte als 0 angegeben. Und bei der nächsten Abfrage sind es utopische Werte. z.B. 4000V U_DC, oder 9500W P_AC. Das Verhalten ist mit unterschiedlichen WR so. Das Modul befindet sich testweise in der Nähe des WR. Amplifier Power Level Einstellungen machen hier keinen Unterschied. Hatte das schon mal jem. von euch? Danke schon mal.
@Olli Das hat man normal, wenn parallel eine original DTU mitläuft.
Hi zusammen, ich hab seit etwa 1 Woche 3x1500ter am Start mit der hier beschriebenen Konfiguration. Hat bis gestern alles super funktioniert. Aber seit gestern 18 Uhr erreiche ich einen gar nicht mehr. DTU wird jede Nacht ( wegen MQTT-Verbindungsverlust) neu gestartet. WR war die Nacht auch Stromlos (auch 230V). Was kann ich tun jemand ne Idee ?
Dirk schrieb: > Hi zusammen, ich hab seit etwa 1 Woche 3x1500ter am Start mit der hier > beschriebenen Konfiguration. Hat bis gestern alles super funktioniert. > Aber seit gestern 18 Uhr erreiche ich einen gar nicht mehr. DTU wird > jede Nacht ( wegen MQTT-Verbindungsverlust) neu gestartet. WR war die > Nacht auch Stromlos (auch 230V). > Was kann ich tun jemand ne Idee ? Ich habe heute früh auch schon bestimmt 10x reboot gemacht, weil immer wieder MQTT not connected erscheint - irgendwie ist heute der Wurm drinnen. Sonst passiert es nur 2-3x pro Tag.
Rene M. schrieb: > @Olli > Das hat man normal, wenn parallel eine original DTU mitläuft. Hey, vielen Dank für die Info. Das ist bei mir nicht der Fall. Weitere Ideen? Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht funktionieren würden?
Olli schrieb: > Bedeutet aber grundsätzlich, dass HM DTU und Nachbau zusammen nicht > funktionieren würden? Es kann nur einen geben;-)
Highlander schrieb: > Es kann nur einen geben;-) Warum ist das so? Ich ging davon aus, dass die WR Ihre Daten einfach in die Welt raus schreien und die DTUs diese empfangen.
Hallo Zusammen,
der RECV_CHANNEL 0x61 ist m.W. der mit dem er loslegt. Es wurde bei
ersten Tests herausgefunden, dass bei TX auf Kanal 0x61 die nächste
Antwort auf Kanal 0x03 relativ gut empfange wurde, d.h. zwei Kanäle
Unterschied. Ob das am Timing zwischen Senden und Empfangsbereitschaft
des Ahoy DTU Codes ist, oder etwas anderes weiß ich nicht.
Die Originalaufzeichnungen mit Hack RF und anderen Geräten von martin
(Gast), B. G. (golf2010) und Oliver F. (of22) auf Seite 1 & 2 des Forums
hatten gezeigt, daß auch der Wechselrichter alle 2-5 Antwortpakete die
Frequenz wechselt.
Dafür gibt (bzw. gab da in der Zwischenzeit immer aktiv) es das sog.
Channel Hopping das die mRxChList[4]={03, 23, 40, 61, 75} der Reihe nach
durchgeht. Für die mTxChLst[0]=40 gibt es das bisher noch nicht. Wer
also Probleme mit dem Funk hat könnte sich daran machen auch für das
Senden ein Channel Hop einzubauen und vor allem die beiden irgendwie
sinnvoll miteinander zu koordinieren, damit er auch den nächsten
Empfangskanal des Wechselrichters möglichst gut errät. Dazu muß man sich
wie gesagt die o.g. Hack RF Aufnahmen ansehen und einen geschickten
Algorithmus finden.
Hier noch die Links zum Source Code für die mTxChLst und mRxChLst:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L59-L69
Allgemeine Beobachtung von Oliver F. die aber den Spezifikationen in der
FCC Application Note für die HMS-100 widersprechen. Dort sind
tatsächlich nur die o.g. Kanäle (2403, 2423, 2440, 2461, 2475MHz)
beantragt und werden m.W. auch ausschließlich genutzt.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hier einige Beiträge von B.G. (golf2010) der das Channel Hopping auf
seinen Scans relativ gut darstellt.
Was mir dabei aufgefallen ist, sind die Retry-Kaskaden von 15
Retransmits jeder Nachricht.
Das liegt m.E. eventuell daran, daß die DTU mit diesen aktuellen
Retransmit Settings ebenso viele Anfragen sendet ?
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Kann man die o.g. Beobachtungen nicht auch mit einem RTL-SDR (RTL2832U)
mit einem der Tools unter
https://www.rtl-sdr.com/big-list-rtl-sdr-supported-software/ machen.
Solange es nur um das Aufzeichnen des Channel Hoppings einer einsamen
DTU-Pro und eines WR geht sollte das doch zumindest helfen die Kanäle
und das Muster zu erkennen ?
Holger S. schrieb: > Hallo, das soll jetzt keine Werbe Veranstaltung werden, aber wen es > interessiert, hier mal ein paar Bilder von meinem Platinen Layout das > ich entworfen und bestellt habe. > > Ich würde 3,- pro Platine + 1,60 Versand nehmen. > Wer nicht löten kann oder will, kann auch ein fertiges Gerät für 45,- > inc Versand bekommen. > > Nur ein Angebot... Keine Profitabsichten ;-) Ich hab das eigentlich für > mich und meinem Kumpel gemacht, und weil ich mit KiCad umgehen lernen > wollte. Nun kann und soll aber auch gerne die Community was davon haben. Hallo Holger, ich würde gerne dein Angebot in Anspruch nehmen.Und ein fertiges Gerät + Versand kaufen. H.G.
Ha F. schrieb: > Eike schrieb: > >> Das opendtu ist Mist. Einmal an der Sendeleistung gedreht reboot >> und ich >> erreiche das Teil gar nicht mehr. >> Wie bekomme ich eine bin von dem ayoli zeig her ? >> Eike > > Hallo, > steht schon mehrfach immer wieder mal weiter oben: > https://github.com/grindylow/ahoy/actions > Man muss angemeldet sein! > Hier die FAQ: > https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu Hi, ich bin angemeldet, kann aber leider keine fertige .bin finden. Auch die FAQ ist an der Stelle noch nicht fertig aufgebaut. Da kommt aber bestimmt noch Hilfe oder ? VG Frank
Angehängte Dateien:
-
modbus-C001.png
77 KB
Highlander schrieb: > Es kann nur einen geben;-) Ich kann das so nicht bestätigen. Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32. Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten. Aktuell wird bei mir ein HM-600 und ein HM-700 ausgelesen und es kommt demnächst noch ein weiterer HM-700 dazu. Entfernung von DTU-Pro und ESP32 zu HM-600 ist in etwa 3 Meter durch eine Sicherheitsverglasung und zum HM-700 ca. 8 Meter durch zwei Wände. Als ich diesen Thread und das OpenDTU mit ESP32 gefunden hatte war meine DTU-Pro schon unterwegs. Da ich evtl. das Limit Active Power nutzen möchte habe bzw. werde ich die DTU-Pro trotzdem behalten. Hat das hier schon jemand erfolgreich benutzt? Ich verstehe den Modbus Befehl nicht so richtig. Laut Anleitung in der DTU-Pro soll Function Code 0x05 an die Adresse 0xC001 gesendet werden (siehe auch Anhang). Dabei soll man Werte bei HM von 2 bis 100% senden können. Nach meinem Verständnis kann Function Code 0x05 aber nur 1 Bit Werte senden bzw. schreiben also nur 1 oder 0. Kann mir da jemand weiter helfen bzw. den entscheidenden Tipp geben? Wenn es eine Möglichkeit gibt über OpenDTU per MQTT diese limit Active Power zu setzen wäre das natürlich auch super.
Angehängte Dateien:
-
Download_bin.png
89 KB
guilligan schrieb:
> Hi, ich bin angemeldet, kann aber leider keine fertige .bin finden.
In dem angehängten Bild habe ich den Weg zur .bin am Beispiel "ahoy"
skizziert. Die neuste .bin ist jeweils oben in der Liste.
Für "OpenDTU" gelten die Angaben sinngemäß.
Viel Erfolg - Günter
:
Bearbeitet durch User
Ist OpenDTU eine Alternive zu Ahoi und kann auch auf einem Esp8266 installiert werden?
...einfach 'mal die FAQ https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#bin-files-f%C3%BCr-ahoy-dtu bemühen, genau dafür sind sie da.
Vermutlich ist es ein simpler Anfängerfehler, aber ich bekomme ahoy
nicht auf meinem RasPi zum laufen. Das getting_started von RF24 läuft
und ich sehe die SPI Kommunikation auf dem Oszi, aber wenn ich ahoy
starten will bekomme ich folgendes:
pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config
ahoy.yml
Traceback (most recent call last):
File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details
return _get_module_details(pkg_main_name, error)
File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details
__import__(pkg_name)
File "/home/pi/ahoy-tool/hoymiles/__init__.py", line 14, in <module>
from RF24 import RF24, RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH,
RF24_PA_MAX, RF24_250KBPS, RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
ModuleNotFoundError: No module named 'RF24'
Aber in der pip list ist es, so soll es doch eigentlich sein?
pi@ahoy:~/ahoy-tool $ python3 -m pip list
Package Version
------------- ---------
certifi 2020.6.20
chardet 4.0.0
colorzero 1.1
crcmod 1.7
distro 1.5.0
gpiozero 1.6.2
idna 2.10
paho-mqtt 1.6.1
pip 22.2.1
python-apt 2.2.1
PyYAML 6.0
requests 2.25.1
RF24 1.4.5
RPi.GPIO 0.7.0
setuptools 63.4.0
six 1.16.0
spidev 3.5
ssh-import-id 5.10
urllib3 1.26.5
wheel 0.34.2
Hat jemand eine Idee?
Giuseppe M. schrieb: > Ich kann das so nicht bestätigen. > Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32. > Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten. Hallo, ist was etwas technisches, dass sich die Systeme stören, oder liegt das an der Software? Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren?
Giuseppe M. schrieb: > > Ich verstehe den Modbus Befehl nicht so richtig. > Laut Anleitung in der DTU-Pro soll Function Code 0x05 an die Adresse > 0xC001 gesendet werden (siehe auch Anhang). Dabei soll man Werte bei HM > von 2 bis 100% senden können. > Nach meinem Verständnis kann Function Code 0x05 aber nur 1 Bit Werte > senden bzw. schreiben also nur 1 oder 0. > > Kann mir da jemand weiter helfen bzw. den entscheidenden Tipp geben? > das Handbuch hat viele Fehler! Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport. Raspi/PyModbus: clientDTU.read_holding_registers und clientDTU.write_register für alle DTU-Pro Register also nicht mit FC 0x05
JedernureinKreuz schrieb: > pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config mit sudo > pi@ahoy:~/ahoy-tool $ python3 -m pip list ohne sudo kann sein dass die beiden aufrufe andere "environments" haben
Olli schrieb: > Giuseppe M. schrieb: >> Ich kann das so nicht bestätigen. >> Bei mir läuft eine DTU-Pro und parallel dazu OpenDTU auf einem ESP32. >> Beide loggen Ihre Daten ohne große Aussetzer und Schwierigkeiten. > > Hallo, > > ist was etwas technisches, dass sich die Systeme stören, oder liegt das > an der Software? > Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren? JA es laufen beide parallel wenn die DTU-Adressen gleich sind
Stefan T. schrieb: > gab da in der Zwischenzeit immer aktiv) es das sog. > Channel Hopping das die mRxChList[4]={03, 23, 40, 61, 75} der Reihe nach > durchgeht. Für die mTxChLst[0]=40 gibt es das bisher noch nicht. Wer > also Probleme mit dem Funk hat könnte sich daran machen auch für das > Senden ein Channel Hop einzubauen und vor allem die beiden irgendwie > sinnvoll miteinander zu koordinieren, damit er auch den nächsten > Empfangskanal des Wechselrichters möglichst gut errät. Dazu muß man sich > wie gesagt die o.g. Hack RF Aufnahmen ansehen und einen geschickten > Algorithmus finden. Das habe ich ja schon lange hier geschrieben und so ist meine SW implementiert. Mein MI-1500 aendert die kanaele staendig, so muss ich auf RX UND TX hoppen. Ich glaube auch, dass nicht nur der MI so macht..
Angehängte Dateien:
Olli schrieb: > Hallo, > > ist was etwas technisches, dass sich die Systeme stören, oder liegt das > an der Software? > Laut dir scheint ja das Zusammenspiel mit dem OpenDTU zu funktionieren? Zum präzisieren. Ich verwende einen ESP32 keinen ESP8266 bzw. WemosD1 Ich habe zum flashen des ESP32 das hier verwendet https://github.com/tbnobody/OpenDTU Es gibt keine fertigen Bin Dateien bzw. habe ich keine gefunden musste also genau nach Anleitung per Vscode den ESP32 bespielen. Nach meinem Verständnis basieren aber Ahoy Wemos D1 und das OpenDTU für den ESP32 auf dem gleichen Basis Code sollten also sehr ähnlich sein. Der ESP32 hat lediglich etwas mehr Speicher und CPU-Speed. Ich habe die DTU-Pro und den ESP32 im Abstand von ca. 0,5 m gleichzeitig im Betrieb. Der ESP32 ist per MQTT an meinem Smarthome System (Symcon) angebunden. Die Daten werden zuverlässig übertragen und geloggt (siehe beigefügte Screenshots). Die DTU-Pro wird aktuell nur mit der Cloud genutzt also kein ständiges auslesen per Modbus oder ähnliches. Aber in der Cloud werden die zwei Wechselrichter ebenfalls zuverlässig geloggt (siehe Screenshot).
Ziyat T. schrieb: > das Handbuch hat viele Fehler! > Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport. > Raspi/PyModbus: > clientDTU.read_holding_registers und > clientDTU.write_register > für alle DTU-Pro Register > also nicht mit FC 0x05 Vielen Dank für die Rückmeldung. Sind die Register in der Anleitung korrekt? Oder sind diese ebenfalls fehlerhaft? Das lesen der Daten also Leistung etc. mit 0x03 funktioniert bei mir soweit ohne Probleme. Nach Deiner Erklärung müsste ich also z.B. zum limitieren aller Wechselrichter in das Register 0xC001 per Function 0x06 einen Wert von 2-100 schreiben. Das werde ich morgen mal ausprobieren. Wenn Du dies schon länger verwendest, wie lange dauert es bis die Wechselrichter auf den neuen Limit Wert reagieren?
Giuseppe M. schrieb: > Ziyat T. schrieb: >> das Handbuch hat viele Fehler! >> Ich verwende DTU-Pro/Modbus seit einem Jahr, für ZeroExport. >> Raspi/PyModbus: >> clientDTU.read_holding_registers und >> clientDTU.write_register >> für alle DTU-Pro Register >> also nicht mit FC 0x05 > > Vielen Dank für die Rückmeldung. > Sind die Register in der Anleitung korrekt? > Oder sind diese ebenfalls fehlerhaft? > Das lesen der Daten also Leistung etc. mit 0x03 funktioniert bei mir > soweit ohne Probleme. > Nach Deiner Erklärung müsste ich also z.B. zum limitieren aller > Wechselrichter in das Register 0xC001 per Function 0x06 einen Wert von > 2-100 schreiben. > Das werde ich morgen mal ausprobieren. > > Wenn Du dies schon länger verwendest, wie lange dauert es bis die > Wechselrichter auf den neuen Limit Wert reagieren? - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006 ist nicht für Port 1 sondern für WR 1 - beim MI unter 10% schaltet er fast auf 0 - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche v. mppt ist, dann klar etwas laenger)
Ziyat T. schrieb: > JedernureinKreuz schrieb: > >> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config > mit sudo > >> pi@ahoy:~/ahoy-tool $ python3 -m pip list > ohne sudo > > kann sein dass die beiden aufrufe andere "environments" haben Abgefahren, jetzt muss ich das nur noch bereinigt bekommen... pi@ahoy:~ $ sudo python3 -m pip list Package Version ------------- --------- certifi 2020.6.20 chardet 4.0.0 colorzero 1.1 crcmod 1.7 distro 1.5.0 gpiozero 1.6.2 idna 2.10 paho-mqtt 1.6.1 pip 20.3.4 python-apt 2.2.1 PyYAML 6.0 requests 2.25.1 RPi.GPIO 0.7.0 setuptools 52.0.0 six 1.16.0 spidev 3.5 ssh-import-id 5.10 urllib3 1.26.5 wheel 0.34.2
Angehängte Dateien:
Ziyat T. schrieb: > - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006 > ist nicht für Port 1 sondern für WR 1 > - beim MI unter 10% schaltet er fast auf 0 > - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche > v. mppt ist, dann klar etwas laenger) Das es WR1 sein muss dachte ich mir schon. Adresse ist C006? Weil in der Anleitung steht C007. Ich werde es morgen testen und noch mal Rückinfo geben. Vielen Dank
Für alle die Ahoy DTU (ESP8266) nutzen, @baloo und ich haben uns heute das Problem mit dem MQTT Reconnect angesehen und einen Wechsel des TX Kanals für diejenigen, die manchmal 30 Minuten keine Daten vom WR bekommen eingebaut. Der Pull Request dafür ist gestellt. fix MQTT problem and add TX channel switch to send loop #119 https://github.com/grindylow/ahoy/pull/119
Giuseppe M. schrieb: > Zum präzisieren. > Ich verwende einen ESP32 keinen ESP8266 bzw. WemosD1 > Ich habe zum flashen des ESP32 das hier verwendet > https://github.com/tbnobody/OpenDTU > Es gibt keine fertigen Bin Dateien bzw. habe ich keine gefunden musste Vielen Dank für die Infos. Die .bin Files kannst du doch über "Aktions" generieren.
Hallo Olli, Thomas B. schreibt OpenDTU gerade großteils um / neu um die in der Zwischenzeit neu hinzugekommenen Kommandos unterzubringen. Es gibt m.W. für OpenDTU noch keine GitHub Actions die automatisch die Binaries erzeugen. Wenn Du also Lust hast und weißt wie es geht, kannst Du gerne die Actions erstellen und in einem Fork testen.
Hallo, ist in OpenDTU oder Ahoy die Möglichkeit schon eingebaut die Leistung zu limitieren? Ich muss meinen Elektriker zeigen, dass ich die Geräte auf 70% eingestellt habe. LG
Stefan T. schrieb: > Es gibt m.W. für OpenDTU noch keine GitHub Actions die automatisch die Binaries erzeugen. Doch gibt es...
Giuseppe M. schrieb: > Ziyat T. schrieb: >> - ich bin mir nicht sicher, da ich einen MI habe, aber z.B die 0xC006 >> ist nicht für Port 1 sondern für WR 1 >> - beim MI unter 10% schaltet er fast auf 0 >> - er reagiert drauf in 5-10sek, relativ schnell (wenn er auf die suche >> v. mppt ist, dann klar etwas laenger) > Das es WR1 sein muss dachte ich mir schon. > Adresse ist C006? > Weil in der Anleitung steht C007. > Ich werde es morgen testen und noch mal Rückinfo geben. > Vielen Dank 0xc006 on/off wr1 0xc007 limit wr1
:
Bearbeitet durch User
habe mal einen Fork mit meiner Lösung für das MQTT-Reconncet Problem und dem Anmeldenamen am MQTT erstellt. Der Reconncet läuft bei mir jetzt sehr zuverlässig und für die Anmeldung am MQTT wird jetzt der Device-Name verwendet ( wie er im Setup steht ). Ausserdem sende ich die MQTT Daten jedesmal sofort aus, nachdem die WR Daten intern aufbereitet wurden. Ich lese den WR alle 30 Sekunden aus und erhalte die Daten mit 2 Sekunden Verzögerung ( so gewollt wegen Funkfeld Belegung ) sofort im MQTT-Broker. Den Pull Request dafür habe ich erstellt.
Hier kann man die neueste Version von Ahoy ESP8266 runterladen, mit MQTT Reconnect von isnoAhoy Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link auch jede neuere Version bekommen (ohne Login): https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip
:
Bearbeitet durch User
Stefan T. schrieb: > Wenn Du also Lust hast und weißt wie es geht, kannst Du gerne die > Actions erstellen und in einem Fork testen. Hallo Stefan, da bin ich leider der Falsche, da mir da einige Kenntnisse fehlen. Aber "Actions" gibt es doch bereits über die man sich eine .bin erzeugen kann.
Ziyat T. schrieb: > JedernureinKreuz schrieb: > >> pi@ahoy:~/ahoy-tool $ sudo python3 -um hoymiles --verbose --config > mit sudo > >> pi@ahoy:~/ahoy-tool $ python3 -m pip list > ohne sudo > > kann sein dass die beiden aufrufe andere "environments" haben Jetzt auch wieder mit Login, bitte nicht meckern :-) Ich habe diesen Teil python3 -m pip install --upgrade pip python3 -m pip install . von hier https://github.com/grindylow/ahoy/tree/main/tools/rpi nochmal als sudo ausgeführt und nun ist das Modul gelistet. Danach bekam ich syntax errors, nachdem ich in ahoy/tools/rpi/hoymiles/decoders/__init__.py Die Kommentareinleitungen von // auf # geändert habe funktioniert es jetzt (vermutlich). Mein HM-300 ist noch unterwegs, aber ahoy versucht jetzt zu pollen :-)
Vielen Dank an alle Beteiligten für die 0.4.26 - ich bin gespannt. Wo bringe ich den Wunsch ein, oben bei Visualisation eine summierte Gesamtübersicht (YieldTotal, Day, P_AC, P_DC) haben zu können? Jeder, der mehrere Wechselrichter betreibt, dürfte sich darüber freuen. Idealerweise per Checkbox im Setup auswählbar (Display SUM).
Lukas P. schrieb: > Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link > auch jede neuere Version bekommen (ohne Login): > https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip Über "Actions" bei GitHub ist nun wirklich kein Hexenwerk, der Link ist aber noch komfortabler. Danke dafür und für die ganze Entwicklungsarbeit - natürlich auch an das ganze "Team".
Danke auch an HorstG-57 und baloo die beim finden und beheben des MQTT Problems tatkräftig unterstützt haben. Jetzt bin ich gespannt ob das auch tatsächlich allen Betroffenen hilft und wir einige Issues schließen können. @Tobias G. wenn ich mich recht entsinne hat das bereits jemand umgesetzt. Der Code / Pull Request steht aber noch aus...
Ich habe auf Version 0.4.26 geupdatet. Bei mqtt ist immernoch nur read-only 75s möglich (also keine Eingabe einer kürzeren Zeit)? Oder sehe ich das nur nicht? Kann diese Version schon Befehle zur Limitierung über Mqttfx umsetzen und wenn ja wie wären die zu schreiben? Bei mir "dtu/hm600/Ch0/??????" Und was anstelle der "?" ? Danke für Hilfe und die Supi-Arbeit hier. VG Frank (Anfänger mit technischem Verständnis, aber ohne Programmierung)
:
Bearbeitet durch User
Stefan T. schrieb: > ... und einen Wechsel des TX > Kanals für diejenigen, die manchmal 30 Minuten keine Daten vom WR > bekommen eingebaut. > > Der Pull Request dafür ist gestellt. > > fix MQTT problem and add TX channel switch to send loop #119 > https://github.com/grindylow/ahoy/pull/119 Habe mir jetzt neben der ESP32 OpenDTU auch noch eine ESP8266 Ahoy DTU zum Vergleich gebastelt und ich kann bestätigen, dass die 30 Minuten Empfangslücke nach WR-Neustart mit der aktuellen Ahoy-Version nicht auftreten. Es kommen sofort alle Daten. Spitze!!!
Hallo ich würde gerne die 0.4.26er bin Version testen. Wie kann ich meine aktuelle Version 0.4.25 am besten upgraden ? Was ist der Unterschied zwischen Firmware und Filesystem Upgrade ?
1. Einige Beiträge nach oben scrollen, dort hat Lukas P. heute einen Link zur jeweils aktuellen .bin eingestellt. 2. zip-Datei entpacken. 3. Update Firmware durchführen (Wozu Update FileSystem gut sein kann, weiß ich auch nicht).
Moin! Eine kurze Frage bzgl. Verbindungsproblemen: welche Minimal(!)voraussetzungen genau gibt es, damit über Funk eine erste erfolgreiche Verbindung zum WR hergestellt werden kann? Meine Vermutungen: 1. Mindestens ein Panel muss angeschlossen sein und Strom produzieren. 2. Der WR muss auch an AC angeschlossen sein (sonst blinkt die LED wohl im Sekundentakt rot auf) 3. Laut Forenberichten muss der WR wohl zunächst 30 Minuten laufen - ist das wirklich so?
Joachim schrieb: > 1. Mindestens ein Panel muss angeschlossen sein und Strom produzieren. > 2. Der WR muss auch an AC angeschlossen sein (sonst blinkt die LED wohl > im Sekundentakt rot auf) > 3. Laut Forenberichten muss der WR wohl zunächst 30 Minuten laufen - ist > das wirklich so? Nur 1. muss gegeben sein.
Danke! Ich frage deshalb, weil er bei mir bisher keine Verbindung herstellen kann, es ist ein 300W-Modul dran und die LED blinkt im Sekundentakt rot (da noch kein AC angeschlossen ist). Die 30 Min. sind bald rum, ich fürchte nur, dass sich nicht viel ändern wird. Die SN ist korrekt eingetragen, zwischen Antenne und WR liegen nur 3m. Die Meldungen sind bisher nicht vielversprechend: I: Requesting Inverter SN 11417201xxxx -> I: Transmit 27 | ... Inverter #0 I: no Payload received! (retransmits: 5) .... Hab das Modul im Setup sowohl mal unter Port 1 als auch unter Port 2 ausprobiert, die Meldungen sind leider die gleichen.
Joachim schrieb: > Das hier sind die Meldungen (Anhang) Probier mal sowohl hardwaremässig als auch Softwaremässig d3 und d4 zu tauschen, bei mir gehts damit, siehe https://github.com/grindylow/ahoy/issues/36
Danke für den Tipp! Auf diese Idee wäre ich natürlich nicht gekommen. Ich schau mal, wie ich das umsetzen kann, dummerweise ist das alles bereits gut verlötet (angepasste Platine). Aber trotzdem. Wenn ich die PINs nur softwareseitig vertausche, bleibt zumindest die Startmeldung zur Antenne identisch: 17:04:25.532 -> I: RF24 Amp Pwr: RF24_PA_MIN 17:04:25.532 -> I: Radio Config: 17:04:25.532 -> SPI Frequency = 1 Mhz 17:04:25.579 -> Channel = 3 (~ 2403 MHz) 17:04:25.579 -> RF Data Rate = 250 KBPS 17:04:25.579 -> RF Power Amplifier = PA_MIN 17:04:25.579 -> RF Low Noise Amplifier = Enabled 17:04:25.579 -> CRC Length = 16 bits 17:04:25.579 -> Address Length = 5 bytes 17:04:25.579 -> Static Payload Length = 32 bytes 17:04:25.579 -> Auto Retry Delay = 250 microseconds 17:04:25.579 -> Auto Retry Attempts = 0 maximum 17:04:25.579 -> Packets lost on 17:04:25.579 -> current channel = 0 17:04:25.579 -> Retry attempts made for 17:04:25.579 -> last transmission = 15 17:04:25.579 -> Multicast = Disabled 17:04:25.579 -> Custom ACK Payload = Disabled 17:04:25.579 -> Dynamic Payloads = Enabled 17:04:25.579 -> Auto Acknowledgment = Disabled 17:04:25.579 -> Primary Mode = RX 17:04:25.579 -> TX address = 0xdeadbeef01 17:04:25.579 -> pipe 0 (closed) bound = 0xdeadbeef01 17:04:25.626 -> pipe 1 ( open ) bound = 0x1234567801 17:04:25.626 -> pipe 2 (closed) bound = 0xc3 17:04:25.626 -> pipe 3 (closed) bound = 0xc4 17:04:25.626 -> pipe 4 (closed) bound = 0xc5 17:04:25.626 -> pipe 5 (closed) bound = 0xc6 Falls es keine anderen Tipps gibt, werde ich nachher wohl nochmal den Kolben in die Hand nehmen müssen :-(
Mit welcher Software flasht Ihr die OpenDTU bin Files auf den ESP32?
Olli schrieb: > Mit welcher Software flasht Ihr die OpenDTU bin Files auf den > ESP32? Mit Visual Studio Code + PlatformIO
OK, ich werde wohl eine neue Antenne bestellen müssen, das Entfernen hat sie wohl irgendwie nicht überlebt, obwohl die Kontakte eigentlich funktionieren. Ich werde sowas zukünftig besser nicht mehr löten, bevor alles auf dem Breadboard läuft.
Ziyat T. schrieb: > 0xc006 on/off wr1 > 0xc007 limit wr1 Hallo, ich habe es heute mal probiert aber irgendwie hat es nicht richtig geklappt. Könntest Du mir mal bitte ein Beispiel geben welchen Wert man senden muss? Also ich meine muss man Dezimal 2-100 senden? Oder muss man einen Wert z.B. 400 für 400 Watt senden? Ich habe mehrere Werte an den Wechselrichter gesendet, irgendwann hat er nichts mehr produziert, aber eine Limitierung auf einen bestimmten Wert ist mir nicht gelungen.
Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen? Also opendtu und ahoi?
@Eike wäre vielleicht toll, wenn du einmal die Wikis von OpenDTU und Ahoy lesen würdest. Ein bisschen selber informieren und denken kann nicht schaden.
Ne geile FAQ wäre auch toll. Gibt es aber auch nicht.
Eike schrieb: > Ne geile FAQ wäre auch toll. Gibt es aber auch nicht. Vielleicht mal ein wenig mitlesen ..... https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions
Eigentlich ist alles gut beschrieben. Wenn jemand fragt, o man für OpenDTU und Ahoy die selbe Hardware verwenden kann, da liegt es wieder einmal beim Fragesteller. Hatten wir schon einmal. Da hast ja gleich OpenDTU schlecht geredet, nur weil es nicht funktioniert. Zitat von dir am 02.08 "Das opendtu ist Mist" Wie so oft, liegt der Fehler vor dir, wenn du in den Spiegel siehst. Da machen sich andere die Mühe und entwickeln so etwas geniales, und dann kommen solche wie du daher, und sagen das ist "Mist"
Eike schrieb: > Sag mal kann ich mit der gleichen Hardware bei Versionen. Nutzen? > Also > opendtu und ahoi? Hier nachzulesen: https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-hardware-brauche-ich-f%C3%BCr-die-verschiedenen-software-projekte
Rene M. schrieb: > Eigentlich ist alles gut beschrieben. Schenkelklopfer, Zitat aus der achso geilen FAQ: Q: "Reicht ein ESP8266 mit 1MB oder muss es unbedingt ein ESP8266 mit 4MB sein?" A: NIX Q: Muß es ein nrf24L01+ sein oder funktioniert auch ein nrf24L01 (ohne Plus)? A: NIX Q: Ich will mir eines bestellen, wo gibt es eine sichere Quelle? A: NIX Q: Wie ist das Gerät mit Spannung zu versorgen A: "Stabile Stromversorgung ..." -> Schenkelklopfer, warum schreibt man hier nicht "aus der Steckdose"? Q: Wo und wie kommt man direkt ohne Entwicklungsumgebung an die .bin? A: NIX, ein Link wäre wohl zu anstrengend ;) Q: o liegen die verschiedenen Versionen der .bin´s? A: NIX, ein Link wäre wohl zu anstrengend ;) usw. usf. Das sollte umgehend umbenannt werden in FAQ-Frequently-Asked-Questions-without-helpful-answers Hochachtung vor der Programmierleistung und dem Reverse-Engineering, aber Doku? Katastrophe! Und so zu tun als wäre die superduper und hilfreich (wie die zahlreichen Links zur "FAQ" hier im Endlospost zeigen) kann man nicht unwidersprochen stehen lassen ;)
Naja die FAQ gibt es erst seit wenigen Wochen /einigen Tagen. Ich denke der Ersteller ist dankbar für jeden hilfreichen Text den er bekommt um ihn einzufügen. Hermann schrieb: > A: "Stabile Stromversorgung ..." -> Schenkelklopfer, warum schreibt man > hier nicht "aus der Steckdose"? Mit der Antwort "aus der Steckdose" kann auch niemand etwas anfangen. Hier geht es genau darum, dass das Netzteil entsprechend geeignet sein muss um den ESP mit Strom zu versorgen und zwar auch dann wenn er mal kurzzeitige etwas mehr zieht (WLAN etc). Ein Netzteil mit 1A kann funktionieren, kann aber auch dafür sorgen, dass es Neustarts gibt.
Mein OpenDTU läuft absolut stabil und fehlerfrei seit dem ich es angesteckt habe, seit 9 Tagen. WR steht etwa 5 Meter vom ESP32 entfernt, es ist eine dicke Betondecke + Kies dazwischen. PA Level: Maximum (0 dBm) Komponenten: https://www.amazon.de/gp/product/B071P98VTG https://www.amazon.de/gp/product/B07VQ838KT https://github.com/tbnobody/OpenDTU/blob/master/docs/Wiring_ESP32.fzz Strom bekomme ich so (direkt von einem der USB-Anschlüsse): https://www.amazon.de/gp/product/B096BFKWSK Ein herzliches Dankeschön an alle Entwickler!
:
Bearbeitet durch User
Hermann schrieb: > Und so zu tun als wäre die superduper und hilfreich (wie die zahlreichen > Links zur "FAQ" hier im Endlospost zeigen) kann man nicht > unwidersprochen stehen lassen ;) Würde man einfach nur selbst ein bisschen Hirn einschalten und sich die Mühe machen etwas selber zu informieren, wäre das kein Problem. Aber es wird immer Leute geben, die alles vorgekaut brauchen, weil sie es selbst nicht schaffen, etwas zu googeln. Ist aber noch immer kein Grund, irgendetwas schlecht zu mache wie der User Eike, den ich zukünftig sicher ignorieren werde
Eigentlich ist es ganz einfach...entweder es sollen nur Hardcore User nutzen die wissen wie man Datenströme mitloesst und was was ich alles oder eben auch normalos. Normalos. Rauchen eben Amazon links und einfache antworten. Müsst ihr euch entscheiden was ihr wollt oder was das für ein prot werden soll so einfach ist das. Eike
@Eike und Hermann kauf doch einfach das fertige kommerzielle Gerät. Da musst Du nicht mitdenken und bekommst für Dein Geld ein (hoffentlich) fertig entwickeltes und marktreifes Produkt - gleich mit Cloud. Hier dreht es sich um ein Projekt von freiwilligen in der Entwicklungsphase. Wenn beim kommerziellen Produkt etwas nicht gleich geht, kannst Du gerne dem Hersteller schreiben sein Produkt wäre "Mist". So ist das einfach im Leben. Wer nur Ansprüche hat ohne mithelfen und ausprobieren zu wollen, der muss halt einfach ein fertiges Produkt kaufen und die Entwicklungsarbeit, Marketing, Vertrieb, Gewinn usw. des Herstellers bezahlen.
Hallo zusammen und vielen Dank für eure tolle Leitung bisher. Ich werde in den nächsten Tagen meinen HM400 aktivieren und hab vorab schon mal einen ESP8266 (Wemos D1 mini) + NRF24L01(plus) zusammengesteckt und mit der Version 0.4.26 geflasht. Als Funkmodul hab ich dieses verwendet: https://www.amazon.de/WayinTop-NRF24L01-Transceiver-Regulator-kompatibel/dp/B07PBBC4H9 Auf dem Chip steht nrf24l01+. Ich hab das Modul über den mitgelieferten Adapter an den Wemos angeschlossen. Die Stromversorgung des Adapters kommt vom 5V PIN des Wemos. Nach dem Flashen konnte ich wunderbar auf die Weboberfläche zugreifen und alle Einstellungen vornehmen und alles sieht normal aus. Ich bekomme natürlich noch keine Daten, da der Wechselrichter noch nicht in Betrieb ist. Was ich aber feststellen musste ist, dass der ESP Chip sehr heiss wird. Kennt jemand das Verhalten? Woran kann das liegen? Viele Gruße, Bibo
Es wäre mal nett wenn jemand erklärt wie man die Commandos für die Leistungsbegrenzung über einen ESP8266 zum NRF sendet. Geschieht dies per Mqtt oder funktioniert dies per Terminal Programm wie z.B. Hterm. Also Command per Hterm TX in hex an ESP senden der dies zum NRF sendet oder ist das in der HoyDTUsimu nicht mit enthalten ?
Solche Projekte leben vom konstruktiven Mitmachen. Da sind Kommentare wie "Mist" oder "NIX, ein Link wäre wohl zu anstrengend ;)" nicht hilfreich. Es gibt da auf Youtube ein Video mit dem Titel "Hoymiles-Mikrowechselrichter – DTU für Monitoring einrichten – Tipps und Tricks" . Ich war erstaunt wie viele Einschränkungen und Fehlfunktionen bei der originalen DTU von Hoymiles erwähnt wurden. Da scheint im Kommunikationsverfahren zwischen DTU und Wechselrichter mehr als ein bekannter Bug eingebaut zu sein. Open Source Reverse-Engineering Projekte diskutieren wenigstens darüber und lösen. Die Hersteller wechseln im besten Fall das Produkt aus. Hochachtung vor allen, die sich bisher eingebracht haben.
Hermann schrieb: > … > Das sollte umgehend umbenannt werden in > FAQ-Frequently-Asked-Questions-without-helpful-answers > > Hochachtung vor der Programmierleistung und dem Reverse-Engineering, > aber Doku? Katastrophe! > … Du weisst aber, dass es sich hier um ein gemeinschaftlich entwickeltes Projekt handelt, bei dem jeder herzlich eingeladen ist, einen Beitrag zu leisten, um das Gesamtergebnis zu verbessern? Also: finde die Lücken in der Doku, arbeite Dich durch den ganzen Diskussions-Thread und fülle die Lücken mit Deinem erarbeiteten Wissen auf. Hat den Effekt, dass Du danach schlauer bist und die, die nach Dir Informationen suchen, sie auch mühelos finden. Und wenn Du erwartest, ein fertiges Produkt zu erhalten, dann schau Dich auf dem kommerziellen Markt um. Vielen Dank. Und ein herzliches „Danke“ an alle hier, die ihre Zeit, ihr Gehinschmalz und ihre Arbeit investieren! -pl
Hallo zusammen, ich find euer Projekt und die Leistung hier echt super. Ich würde euch gerne beim ausfüllen der Faqs (soweit es mir möglich ist) unterstützen bzw. auch gerne mal ne Anleitung schreiben. Wie kann man das organisieren ?
Bibo schrieb:
> Was ich aber feststellen musste ist, dass der ESP Chip sehr heiss wird.
Was heißt denn "sehr heiß"? Bei den ESP8266 auf meinem Wemos D1 mini ist
im Dauerbetrieb eine "leichte Erwärmung" feststellbar.
Kannst du die Stromaufnahme messen? Bei mir mit Netzteil (also an 230 V)
gemessen 0,6 W.
Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade eingestellt ist, da ich das für die EVU brauche.
Günter H. schrieb: > Was heißt denn "sehr heiß"? Bei den ESP8266 auf meinem Wemos D1 mini ist > im Dauerbetrieb eine "leichte Erwärmung" feststellbar. Wenn ich mit meinem Finger ;) die Temperatur messe halte ich es nicht lange aus. Ich schätze > 50 °C. Günter H. schrieb: > Kannst du die Stromaufnahme messen? Bei mir mit Netzteil (also an 230 V) > gemessen 0,6 W. Den Strom werde ich heute Abend mal messen.
Dirk Z. schrieb: > Hallo zusammen, ich find euer Projekt und die Leistung hier echt super. > Ich würde euch gerne beim ausfüllen der Faqs (soweit es mir möglich ist) > unterstützen bzw. auch gerne mal ne Anleitung schreiben. Wie kann man > das organisieren ? Hallo Dirk, am einfachsten ist es aktuell, wenn du auf den Discord kommst: https://discord.gg/6Y4dAs2v Da können wir die FAQ übersichtlicher erweitern und es ist allen dabei geholfen. Danke für dein Angebot zum Mitmachen :) lg
Liebe Leute, die Diskussionskultur hier ist vereinzelt unter aller Sau. Dieses Projekt lebt von konstruktiver Kritik, Verbesserungsvorschlägen und dem Mitwirken von Entwicklern, die das ganze hier in ihrer Freizeit machen. Genauso lebt dieses Projekt von Leuten, die Hardware kaufen (zum Teil mehrere 100€), öffnen, auf Garantie verzichten und am Ende Daten mitloggen und Bereitstellen, aufbereiten, auswerten und das auch mal nachts, in der Freizeit. Das Projekt hier ist weit voran geschritten, weil viele sich helfen, gute Fragen stellen oder ordentlich beantworten. Es geht beim Basteln und Bauen nicht ohne Hirnschmalz. Wer also der Meinung ist, hier irgendwas Steckerfertig zu kriegen und rummotzen kann, weil irgendwas nicht geht, ist falsch hier. Geht auf ne Webseite, kauft euch vom Hersteller einen Datenlogger und schaltet euer Hirn aus. Danke. Wer jedoch ordentlich Fragen stellt, Diskussionsettikette hat und sich selbst erstmal informiert, ist herzlichst willkommen und dem wird auch geholfen. Beiträge wie "ist Kacke" oder "Nix" in den FAQ sind schlicht fehl am Platz. Es gibt wenig Leute hier, die ein Problem damit haben, wenn die eine oder andere Frage doppelt oder 3fach kommt, vor allem wenn dazwischen Tage oder teils Wochen liegen, aber eine Suchfunktion nutzen ist keine Raketenwissenschaft. Das Ding zwischen den Ohren ist nicht zum Haare schneiden da sondern zum Denken und Mitdenken. Stellt eure Fragen so, dass man die beantworten kann und habt etwas Geduld. Manche Antwort braucht eben 1-2 Tage. Nehmt jedoch euren Undank, geht was fertiges kaufen und verstopft hier nicht die Pipe mit eurem sinnfreien Gesabbel und Gemotze. Danke.
HM schrieb: > Würde mich aus Interessieren, und auch ob man auslesen kann, was gerade > eingestellt ist, da ich das für die EVU brauche. Hallo HM, das Powerlimit befindet sich derzeit auf einigen Forks in der Testphase. Für OpenDTU ist dieses noch nicht verfügbar. Eine Option um das auszulesen gibt es nicht. Ich würde beim EVU mal nachfragen, ob die sich sicher sind, was die da tun. Mir scheint, da ist eine gehörige Portion Willkür und Verhinderungstaktik dabei. So sinnbefreit es auch ist, hier wäre vllt für dich die Option der DTU-Pro mit CHiNT Zähler und 0-Einspeisung der richtige Weg. Kostet zwar ca. 300€ plus Elektriker, ist aber sicher leichter, als den Netzbetreiber zu wechseln, der mindestens fragwürdige Anforderungen an ein "Balkonkraftwerk" hat. Das, was dein EVU fordert, kann weder AHOY noch OpenDTU leisten (aktuell). Zumal einerseits die 70% jederzeit variabel änderbar und nicht verplompt sind und andererseits ab 2023 die 70% eh wegfallen sollen, auch für Bestandsanlagen. In wie weit das schon durch ist, kann ich gerade nicht sagen. lg
Eine Art Nulleinspeisung mit Werten von MQTT wäre das übertrüber. Ich habe ja schon meine Werte vom Smartmeter per MQTT. Bin schon gespannt auf die Leistungsanpassung. Übernimmt und setzt der Wechselrichter diese auch sofort um, oder dauert das etwas, bis die Leistung reduziert wird?
Rene M. schrieb: > Eine Art Nulleinspeisung mit Werten von MQTT wäre das übertrüber. > Ich habe ja schon meine Werte vom Smartmeter per MQTT. > Bin schon gespannt auf die Leistungsanpassung. > > Übernimmt und setzt der Wechselrichter diese auch sofort um, oder dauert > das etwas, bis die Leistung reduziert wird? Im Test laufen die praktisch sofort auf das neue Limit, wir wissen nur noch nicht, wie gesund das ganze ist. Die DTU Pro setzt auch das Limit und die WR reagieren sofort. Welchen Smartmeter hast du im Einsatz? lg
Netzbetreiber hat bei mir einen Kaifa installiert (bin aus Österreich). Lasse mir sämtliche Smartmeter Werte sekündlich ins Iobroker senden. Ich denke, wenn Hoymiles die Nulleinspeisung, sprich Leistungsbegrenzung von sich aus anbietet, sollte es ja nicht unbedingt ungesund für den Wechselrichter sein
Also ich hätte auch meinen Momentanverbrauch vom Haus per MQTT zur Verfügung. IoBroker + Adapter Smartmeter + IR-Lesekopf + "Moderner Zähler" Holley DTZ541-ZDBA im Bayernwerk Netz. Liefert unter anderem (ca. alle 5 Sekunden) unter den Datenpunkten: 16.7.0 Momentanwert Gesamtwirkleistung (Total) (saldierend) Bsp. 250W 2.8.0 Zählerstand 1 Summe Wirkarbeit (Abgabe) Bsp 60 kWh (an der Netzbetreiber verschenkt) 1.8.1 Bezug Tarif 1 (erregt) 1.8.2 Bezug Tarif 2 2.8.0 Lieferung
Rene M. schrieb: > Netzbetreiber hat bei mir einen Kaifa installiert (bin aus Österreich). Da bin ich jetzt nicht so drin, was das ist. > Lasse mir sämtliche Smartmeter Werte sekündlich ins Iobroker senden. Ok :) > Ich denke, wenn Hoymiles die Nulleinspeisung, sprich Leistungsbegrenzung > von sich aus anbietet, sollte es ja nicht unbedingt ungesund für den > Wechselrichter sein Das kommt drauf an, wenn der zu schnell zu viel nachregeln muss, wirds schon interessant, Elektronik kann viel leisten, aber es gibt eben Grenzen. Komm doch gerne im Discord vorbei und mach bei den Tests mit. lg
Hallo zusammen, vorab mal Hut ab, was ihr da gezaubert habt! Hätte da auch noch ein paar Fragen und Anmerkungen... Habe einen MI-600 und die Ahoy-0.4.26 auf einem D1-Mini-Klon am laufen. Der WR scheint ein "echter" MI zu sein. Dementspechend macht der zwar fleißig Anfragen, bekommt aber derzeit (= mit dieser firmware-Version) keine Rückmeldungen. Soweit ich das jetzt verstanden habe, liegt das schlicht daran, dass die MI-Varianten noch nicht funktionieren/eingepflegt sind. Kann ich da irgendwie helfen bzw. wie nähere ich mich dieser Sache? (ich bin Hobbyist und kann mich zwar in den C-Code orientieren, aber die ganzen Auswertungen sind oberhalb meiner Fähigkeiten...) Auf ESP32 umzuswitchen bringt im Hinblick auf die MI-Hardware derzeit auch nichts, korrekt? Aufgrund meiner MySensors- und MiLight-Hub-Erfahrungen gehe ich auch davon aus, dass die Hardware an sich funktional ist - die nRF-Boards stammen aus MySensors-Nodes, die zwischenzeitlich auf RS485 umgestellt wurden, es ist eine Hilfsplatine zwischengeschaltet, die einen Spannungswandler und ein paar Kondensatoren mitbringt, und an der seriellen Schnittstelle sieht zumindest das Senden auch ok aus. Oder ist das ggf. ein Trugschluss? Was Doku angeht: Abgesehen von D2/D3 und der Verwendung der IRQ-Line entspricht der Aufbau recht genau dem, was insbesondere bei MySensors schon lange erprobt ist - da finden sich dann auch viele Tipps betr. der Spannungsversorgung des nRF, Fakes/guten Shops und ggf. sogar Platinen und 3D-Druck-Daten. Ich selbst habe noch das Glück gehabt, einige nRF "vor der großen Fake-Flut" geordert zu haben, die funktionierten zum großen Teil (aber auch damals schon nicht alle). Wenn ich heute einkaufen müßte: nur noch die "geschieldeten" mit pa+nla (3.100m oder so), da scheint das Risiko für fakes nicht ganz so hoch zu sein... Wünsche bzw. Anregungen hätte ich dann auch noch: - sowas wie ein "LWT" wäre klasse (vielleicht komme ich dazu, da was beizutragen) - die jeweils zusammengehörenden Datensätze (z.B. pro Eingang?) in einen JSON zu verpacken wäre super - das würde weniger Last auf dem von mir eingesetzten FHEM erzeugen. Vielleicht hat ja jemand Lust, das (als Option?) umzusetzen... Grüße jedenfalls, J.
Jörg R. schrieb: > Hallo zusammen, > > vorab mal Hut ab, was ihr da gezaubert habt! > > Hätte da auch noch ein paar Fragen und Anmerkungen... > > Habe einen MI-600 und die Ahoy-0.4.26 auf einem D1-Mini-Klon am laufen. > Der WR scheint ein "echter" MI zu sein. Dementspechend macht der zwar > fleißig Anfragen, bekommt aber derzeit (= mit dieser firmware-Version) > keine Rückmeldungen. habe eine esp8266 version für MI veröffentlicht, weiter oben
Giuseppe M. schrieb: > Ziyat T. schrieb: >> 0xc006 on/off wr1 >> 0xc007 limit wr1 > Hallo, > ich habe es heute mal probiert aber irgendwie hat es nicht richtig > geklappt. > Könntest Du mir mal bitte ein Beispiel geben welchen Wert man senden > muss? > Also ich meine muss man Dezimal 2-100 senden? > Oder muss man einen Wert z.B. 400 für 400 Watt senden? > Ich habe mehrere Werte an den Wechselrichter gesendet, irgendwann hat er > nichts mehr produziert, aber eine Limitierung auf einen bestimmten Wert > ist mir nicht gelungen. in 0xc007 (uint8)2 bis 100 schreiben, prozent der angeschlossene nennleistung z.B. 1000W angeschlossen, wenn du 500W willst dann ist der wert 50 edit: > Ich habe mehrere Werte an den Wechselrichter gesendet an den wr? ne, du schickst an die dtu-pro über modbus, oder?
:
Bearbeitet durch User
Hallo Joerg, ich glaube Ziyat T. hatte sich mit dem MI-Protokoll beschäftigt und den Code für seinen MI-1500 angepaßt. Analog dazu geht es auch für MI-600-800 und die kleine MI-300-500. Beim MI-250 bin ich mir nicht sicher, was der tatsächlich verwendet, könnte laut DTU-Pro Source Code noch ein Spezialfall sein, da sozusagen der Urschleim der Hoymiles WR. Such doch mal ob er den Code auch hochgeladen hat oder vielleicht in seinem github Repo hinterlegt hat, seit das mit dem ActivePowerLimit Kommando bei ihm geklappt hat =^D.
:
Bearbeitet durch User
Angehängte Dateien:
Ziyat T. schrieb: > an den wr? ne, du schickst an die dtu-pro über modbus, oder? Danke für die Antwort. Ich habe an die DTU-Pro gesendet. Per Modbus TCP also an die IP-Adresse des DTU-Pro über Port 502. Vielleicht habe ich aber auch dort noch einen Fehler bei den RS485 Einstellungen. Wie sind diese bei Dir eingestellt? Einspeisesteuerung oder Fernbedienung?
:
Bearbeitet durch User
Ziyat T. schrieb: > habe eine esp8266 version für MI veröffentlicht, weiter oben Danke, auch an Stefan T.. Hoffe, nichts neueres übersehen zu haben, das scheint die zip vom 13.07. (Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") zu sein. Habe die Daten zum MQTT-Server, Wifi und der Seriennummer (meine beginnt mit 1041) angepaßt, aber leider will die Arduino-IDE nicht durchlaufen (1.8.19). Wenn ich die erweiterten debug-Ausgaben richtig deute, beißt sich da was. Vielleicht kann jemand mit dem Schnipsel was anfangen, ich vermute, dass die ESP-libs jetzt "zu neu" sind:
1 | In file included from /home/joerg/Arduino/libraries/ESP8266WiFi/src/ESP8266WiFi.h:39, |
2 | from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/wifi.h:10, |
3 | from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/mqtt.h:3, |
4 | from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:21: |
5 | /home/joerg/Arduino/libraries/ESP8266WiFi/src/WiFiClient.h:89:10: error: conflicting return type specified for 'virtual size_t WiFiClient::availableForWrite()' |
6 | 89 | size_t availableForWrite(); |
7 | | ^~~~~~~~~~~~~~~~~ |
8 | In file included from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Stream.h:27, |
9 | from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/HardwareSerial.h:32, |
10 | from /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Arduino.h:288, |
11 | from /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:11: |
12 | /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp8266/Print.h:80:21: note: overridden function is 'virtual int Print::availableForWrite()' |
13 | 80 | virtual int availableForWrite() { return 0; }
|
14 | | ^~~~~~~~~~~~~~~~~ |
Werde jetzt erst mal was anderes machen... Danke aber auf alle Fälle bis hierhin!
Giuseppe M. schrieb: > Ziyat T. schrieb: >> an den wr? ne, du schickst an die dtu-pro über modbus, oder? > > Danke für die Antwort. > Ich habe an die DTU-Pro gesendet. > Per Modbus TCP also an die IP-Adresse des DTU-Pro über Port 502. > Vielleicht habe ich aber auch dort noch einen Fehler bei den RS485 > Einstellungen. > Wie sind diese bei Dir eingestellt? > Einspeisesteuerung oder Fernbedienung? es wird als fernbedienung eingestellt, damit sagst du der dtu was sie machen soll da ich auch einen DTSU (smartmeter) abfrage mein modbus laeuft nur über rs485 hatte auch mal mit tcp über port 502 verbunden, no problem
Jörg R. schrieb: > Ziyat T. schrieb: >> habe eine esp8266 version für MI veröffentlicht, weiter oben > >>>>>>>>>> > /home/joerg/FHEM/ZiyatT/NRF24_SendRcvMIesp/NRF24_SendRcvMIesp.ino:11: > /home/joerg/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/cores/esp 8266/Print.h:80:21: > note: overridden function is 'virtual int Print::availableForWrite()' > 80 | virtual int availableForWrite() { return 0; } > | ^~~~~~~~~~~~~~~~~[/code] > Werde jetzt erst mal was anderes machen... > > Danke aber auf alle Fälle bis hierhin! - bei mir laeuft mit arduino-ide 2.0.0-rc6 und 1.8.19, also die esp libs sollten bei mir die neueste sein. - additional board manager url: https://arduino.esp8266.com/stable/package_esp8266com_index.json - selected board: LOLIN(WEMOS) D1 R2 & mini dann müsste es beim compiler durchkommen edit: # ESP8266 platform name=ESP8266 Boards (3.0.2) version=3.0.2
:
Bearbeitet durch User
Hallo, hat jemand schon mal vom ESP8266 oder ESP32 eine Verbindung per USB auf ein Samsung Smartphone realisiert (per USB Kabel natürlich) um dort die Ertragsdaten abzulegen. Also z.B. pro Tag eine Datei und z.B. alle 10 Min. einen Datensatz mit den PV Daten ans Ende der Datei anfügen (append) ? Hab hier nämlich eines herumliegen, das so noch eine sinnvolle Verwenung hätte.
@Jörg R, @Stefan T. Bin als "keineahnungvongithub" auch auf den github Zug gesprungen. QUICK&DIRTY DTUsim für MI --------------------------- https://github.com/Ziyatoe/DTUsimMI
Ziyat T. schrieb: > - selected board: LOLIN(WEMOS) D1 R2 & mini > dann müsste es beim compiler durchkommen > > edit: > # ESP8266 platform > name=ESP8266 Boards (3.0.2) > version=3.0.2 OK, DANKE! Problem saß (zum Teil) vor dem Bildschirm... Meine Arduino-IDE hat schon ein paar Versionen hinter sich, und es lagen schlicht noch ein paar betagte Versionen von diversen libs im "Arduino"-Folder. Nachdem die da gelöscht waren, lief es durch. Was jetzt aber nicht klappen will, ist der connect zum MQTT-Broker. Der ESP schreibt in der seriellen Konsole unglaublich viele Zeichen in den Versuch rein, die Subscriptions anzumelden (?), und Werte zeigt er auch per Web-Interface bisher keine an. Jetzt lasse ich den mal die "verdächtigen 30 Minuten" laufen, vielleicht wird es bis dahin dann was... Als MQTT-Server habe ich es sowohl mit dem in FHEM integrierten MQTT2_SERVER versucht (mit der Ahoy-Version kein Problem) wie auch mit einem Mosquitto (2.0, anonyme Anmeldung ist erlaubt). Ziyat T. schrieb: > @Jörg R, @Stefan T. > > Bin als "keineahnungvongithub" auch auf den github Zug gesprungen. > > QUICK&DIRTY DTUsim für MI > --------------------------- > https://github.com/Ziyatoe/DTUsimMI THX, hab's direkt geklont. Bin auch nicht wirklich firm mit github, obwohl schon "ewig" dabei...
Jörg R. schrieb: > Ziyat T. schrieb: >> - selected board: LOLIN(WEMOS) D1 R2 & mini >> dann müsste es beim compiler durchkommen >> >> edit: >> # ESP8266 platform >> name=ESP8266 Boards (3.0.2) >> version=3.0.2 > > OK, DANKE! > > Problem saß (zum Teil) vor dem Bildschirm... Meine Arduino-IDE hat schon > ein paar Versionen hinter sich, und es lagen schlicht noch ein paar > betagte Versionen von diversen libs im "Arduino"-Folder. Nachdem die da > gelöscht waren, lief es durch. > > Was jetzt aber nicht klappen will, ist der connect zum MQTT-Broker. Der > ESP schreibt in der seriellen Konsole unglaublich viele Zeichen in den > Versuch rein, die Subscriptions anzumelden (?), und Werte zeigt er auch > per Web-Interface bisher keine an. Jetzt lasse ich den mal die > "verdächtigen 30 Minuten" laufen, vielleicht wird es bis dahin dann > was... - wichtigste ist die wr-adresse im settings.h - im settings.h mal tx- und rx-debug einschalten, laeuft was? - wie weit ist der wr? ev. mit pa_level per serial command erhöhen/verringern - auch wenns nix kommt müssten die null werte auf der web-interface sichtbar sein - ich verwende eigenen mqtt-broker auf dem pi edit: als serial monitor nicht den arduino-ide-monitor verwenden, direkt im terminal mit dem z.B. minicom auf /dev/ttyXXX gehen, ich verwende ascii steuerung im terminal hast du im settings.h wifi on?
:
Bearbeitet durch User
Daniel M. schrieb: > > Komm doch gerne im Discord vorbei und mach bei den Tests mit. > Ich bin da keine Hilfe leider. Schaffe es nicht einmal, den Wechselrichter per Hand in eine Leistungsbegrenzung zu bringen. Wollte das mit MQTT machen, aber klappt nicht.
Ich habe gerade auf die 0.5.1 upgedatet. Bei "Aktive Power Level" hatte ich nichts eingetragen, also stand es bei 0. Nun produzierte mein HM600 nichts mehr, auch nicht nachdem ich 600 eigetragen habe. Erst nach einem Neustart des WR produziert er wieder. Ist das so beabsichtigt? Zusatzfrage, kann (darf) man das Limit auch nach oben setzen?
Volker.B. schrieb: > Zusatzfrage, kann (darf) man das Limit auch nach oben setzen? Hat sich erledigt, bringt nichts, habe es getestet.
Wie funktioniert das mit dieser Leistungsbegrenzung? ich habe einen HM1500 habe nun ohne Leistungsbegrenzung 250Watt. Setze ich die Begrenzung auf 200 Watt habe ich danach plötzlich nur mehr um die 100Watt. Setze ich das ganze wieder auf 1500Watt Begrenzung habe ich wieder die 250Watt.
Volker.B. schrieb: > Ich habe gerade auf die 0.5.1 upgedatet. @Volker.B. : Wo hast du die Version 0.5.1 her ? Ich konnte im Repo noch keine neue Version finden :/
Ziyat T. schrieb: > - wichtigste ist die wr-adresse im settings.h Die ist eingetragen, das ULL am Ende bleibt ja, oder? > - auch wenns nix kommt müssten die null werte auf der web-interface > sichtbar sein Die sind da, das Ding wird aber als MI-1500 gelabelt. Muss man da für MI-600 noch irgendwo anders was umstellen? > - ich verwende eigenen mqtt-broker auf dem pi Im Moment habe ich einen ziemlichen "Mesh-up" zwischen deinem aktuellsten zip aus github und meinen "Altdaten" und da dann auch noch eine Client-Id reingemogelt, die dürfte für den MQTT2_SERVER erforderlich sein (Mosquitto ging vorher ja aber auch nicht). In minicom sehe ich im Moment trotzdem keine anderen Infos wie den Versuch, sich am Server anzumelden, die tx- und rx-debug-Settings habe ich auf "1" gesetzt. Das einzige, das sich ändert ist von "LOOP" beim ersten Versuch auf "loop" bei allen weiteren. Man kann den/die Verbindungsversuch/e (?) bei der Variante MQTT2_SERVER in FHEM per verbose-Änderung sichtbar machen, das schaut dann so aus:
1 | 2022.08.06 14:02:47 5: in@192.168.2.59:52662 SUBSCRIBE: (130)(12)(0)(1)(0)(7)ImpExpW(0) |
2 | 2022.08.06 14:02:47 4: MQTT2_FHEM_Server_192.168.2.59_52662 HOY-DTU SUBSCRIBE |
3 | 2022.08.06 14:02:47 4: topic:ImpExpW qos:0 |
4 | 2022.08.06 14:02:47 5: out@192.168.2.59:52662 SUBACK: (144)(3)(0)(1)(0) |
5 | 2022.08.06 14:02:55 4: Connection closed for MQTT2_FHEM_Server_192.168.2.59_52662: EOF |
6 | 2022.08.06 14:02:55 4: Connection accepted from MQTT2_FHEM_Server_192.168.2.59_58027 |
7 | 2022.08.06 14:02:55 5: in@192.168.2.59:58027 CONNECT: (16)(19)(0)(4)MQTT(4)(2)(0)<(0)(7)HOY-DTU |
8 | 2022.08.06 14:02:55 4: MQTT2_FHEM_Server_192.168.2.59_58027 cid:HOY-DTU CONNECT V:4 keepAlive:60 |
9 | 2022.08.06 14:02:55 5: out@192.168.2.59:58027 CONNACK: (2)(0)(0) |
10 | 2022.08.06 14:02:55 5: in@192.168.2.59:58027 SUBSCRIBE: (130)(12)(0)(1)(0)(7)ImpExpW(0) |
11 | 2022.08.06 14:02:55 4: MQTT2_FHEM_Server_192.168.2.59_58027 HOY-DTU SUBSCRIBE |
12 | 2022.08.06 14:02:55 4: topic:ImpExpW qos:0 |
13 | 2022.08.06 14:02:55 5: out@192.168.2.59:58027 SUBACK: (144)(3)(0)(1)(0) |
Der ESP meldet sich also mit der vergebenen ClientId an, die Verbindung wird aber 8 Sek. später wieder zugemacht, k.A. warum. > - wie weit ist der wr? ev. mit pa_level per serial command > erhöhen/verringern PA-Level steht noch auf LOW, aber das sollte nicht das Problem sein, sind nur ca. 3m+ein paar Ziegel + Gips... Den nRF habe ich auch nochmal hin- und hergetauscht, kein Unterschied. Werde mir das nochmal in Ruhe ansehen müssen, und dann ausgehend von deinem letzten zip erst mal alles der Reihe nach anpassen und versuchen zu verstehen, wann da was warum stattfindet. EDIT: hier noch die sich ständig wiederholenden Zeilen aus minicom:
1 | MQTT connected = 0 |
2 | Subscribing to topics.. No MQTT.. |
3 | Attempting to connect to the MQTT broker: <ip-Adresse> |
:
Bearbeitet durch User
Jörg R. schrieb: > Ziyat T. schrieb: >> - wichtigste ist die wr-adresse im settings.h > Die ist eingetragen, das ULL am Ende bleibt ja, oder? ja, richtig > >> - auch wenns nix kommt müssten die null werte auf der web-interface >> sichtbar sein > Die sind da, das Ding wird aber als MI-1500 gelabelt. Muss man da für > MI-600 noch irgendwo anders was umstellen? eigentlich nicht, meine version erwartet 3 PV's aber es sollte trotzdem etwas zeigen > Der ESP meldet sich also mit der vergebenen ClientId an, die Verbindung > wird aber 8 Sek. später wieder zugemacht, k.A. warum. lieg das ev am broker? timeout oder so? > > EDIT: hier noch die sich ständig wiederholenden Zeilen aus minicom: >
1 | MQTT connected = 0 |
2 | > Subscribing to topics.. No MQTT.. |
3 | > Attempting to connect to the MQTT broker: <ip-Adresse> |
4 | > |
ja, mqtt nicht vorhanden ich nehme an dass du im mqtt.h diese zeilen angepasst hast const char MQTTbroker[] = "192.168.1.11"; int MQTTport = 1883; ich würde mal im settings.h wifi = 0 stellen dann schauen was vom wr kommt, falls die pv's/wr etwas liefern, dann weiter machen mit wifi, mqtt ach ja noch in der "uint8_t checkAllPV(void)" die Zeile if (pvCnt[0]+pvCnt[1]+pvCnt[2]==3) >> ich habe 3 PV's anpassen, nehme an du hast 2 PV's if (pvCnt[0]+pvCnt[1]==2) muss ich mal diese auch irgendwie inn settings.h zügeln EDIT: jetzt ist glaube klar, ich abboniere von meinem mqtt broker den "ImpExpW", das ding kommt vom meinem DTSU-Smart meter und du hast das ding natürlich nicht. füge in deinem broker irgendwie den "ImpExpW"
:
Bearbeitet durch User
Canon.Fritz schrieb: > @Volker.B. : Wo hast du die Version 0.5.1 her ? > Ich konnte im Repo noch keine neue Version finden :/ https://github.com/grindylow/ahoy/actions/runs/2808392417
Ziyat T. schrieb: > EDIT: > jetzt ist glaube klar, ich abboniere von meinem mqtt broker den > "ImpExpW", das ding kommt vom meinem DTSU-Smart meter und du hast das > ding natürlich nicht. füge in deinem broker irgendwie den "ImpExpW" OK, da habe ich jetzt mal ein "600" mit retain-Flag reingeschubst. Dann ändert sich das auf
1 | Subscribing to topics.. ImpExpW Watt 600.0Watt | All PVs received?:0 |
2 | No MQTT.. |
Die erscheinen dann auch als "600.00W" im Web-Interface. Soweit so gut, aber irgendwie scheint der ESP was anderes/noch mehr zu erwarten? (Wo finde ich das? Und wie kann man es ggf. abschalten?) (Eine originale DTU ist nicht vorhanden, ich könnte natürlich den Messwert aus dem zwischengeschalteten Aktor da reinschieben.) Die übrigen Anpassungen mache ich dann bei Gelegenheit.
Ziyat T. schrieb: > ch würde mal im settings.h wifi = 0 stellen dann schauen was vom wr > kommt, falls die pv's/wr etwas liefern, dann weiter machen mit wifi, > mqtt > > ach ja noch in der "uint8_t checkAllPV(void)" > die Zeile > if (pvCnt[0]+pvCnt[1]+pvCnt[2]==3) >> ich habe 3 PV's > anpassen, nehme an du hast 2 PV's > if (pvCnt[0]+pvCnt[1]==2) > muss ich mal diese auch irgendwie inn settings.h zügeln Wenn WITHWIFI auf 0 steht (und man dann auch noch die PINS richtig anpaßt) kommt dann sowas im "sniffer"-Mode:
1 | 40 00 1234567801 00A0 14 0 52 56AD1089 2D434553 EA4AE14B1092078000C8EA150C 0 |
2 | CH61 00 1234567801 00D5 1A 2 B4 F5BB6BAA A554A84D 0B2AAA84AD369A9955598AA495283690A95255 0 |
3 | CH23 00 1234567801 012A 25 1 55 726ABA6A C9AFAAB5 DAA59D95A5B5F54AB8724ED56D2B0CA551B7654E96000000000000000000 0 |
4 | CH23 00 1234567801 0075 0E 2 6D 7A896B5D B548BADE 953A2AA884D8D0 0 |
5 | CH40 00 1234567801 003C 07 2 EDAB15B55256AAAAD5 |
6 | CH75 00 1234567801 0095 12 2 69 AB5AA332 759DADDE D5959B612B59295515A515 0 |
7 | CH61 00 1234567801 00AA 15 1 64 59149A29 D4892271 069250AA6D488A3693512C208B56 0 |
8 | CH23 00 1234567801 002A 05 1 D46B65DA95323A |
9 | CH61 00 1234567801 0086 10 3 28 B9CE5215 2A2AA462 44D4A4D57294582A56 0 |
10 | CH23 00 1234567801 016A 2D 1 D6 AE255922 5A9A5D6B Ill remain 38 |
11 | CH75 00 1234567801 009C 13 2 FF FB32E6BF AFAC1B29 56677884005090092B048288 0 |
12 | CH75 00 1234567801 0055 0A 2 DA AD2E2B5B AED55492 4E91E5 0 |
13 | CH75 00 1234567801 012D 25 2 AA 9512A1F2 2555755A 6A5451655455EA954552A4D49AA65AA94AAB14C395000000000000000000 0 |
14 | CH61 00 1234567801 01D4 3A 2 99 C9DEBD6C A9F2DAEB Ill remain 51 |
15 | CH40 00 1234567801 002A 05 1 2AA5114954B548 |
16 | CH61 00 1234567801 00A9 15 0 95 D52A556A 8556DBB5 5BFCD2A5BAAD52A2545695AAD649 0 |
17 | CH3 00 1234567801 0122 24 1 F4 AA45A976 AEAD1494 F55B52C000010895220424415544424B6AA4CA696A0000000000000000 0 |
18 | CH61 00 1234567801 008C 11 2 76 E9AA8246 01949E55 4A48B569245551251349 0 |
19 | CH61 00 1234567801 00DB 1B 1 65 B540929A 8082D355 5A6AF5DEAAD55BB6BF7B576AAED29454644C84AA 0 |
20 | CH40 00 1234567801 015F 2B 3 55 64794E0F 5592AEA5 Ill remain 36 |
21 | CH75 00 1234567801 0098 13 0 C8 8928A92A F6FD5DBE EADFB7D9F35B55D667AA7D5E 0 |
22 | CH75 00 1234567801 0131 26 0 06 294AB34A A45B55B5 5552A76D6955D6A7C2D6A36956A2D56ABB4ABAA5AE00000000000000000000 0 |
23 | CH3 00 1234567801 0031 06 0 D4A825B41A801D52 |
24 | CH40 00 1234567801 006B 0D 1 24 63509551 5396B58E BD5FFFFFFFFF 0 |
25 | CH23 00 1234567801 01FF 3F 3 FF FDFFFFFF FFFFFFFF Ill remain 56 |
26 | CH40 00 1234567801 01FF 3F 3 FF FFFFFFFF FFD77FED Ill remain 56 |
27 | CH61 00 1234567801 00D9 1B 0 9C 4AB3EB5A 84A2CA9B 2AB15554058322CDEF6EEFFFFDED55BDDFEDA757 0 |
28 | CH40 00 1234567801 0086 10 3 F6 7FFFFFFF FFFFFFFF FFF7FA9551DFF57BFF 0 |
29 | CH40 00 1234567801 014D 29 2 4C A4956A70 A868B557 Ill remain 34 |
30 | CH75 00 1234567801 0155 2A 2 66 DCD957E4 28B2B2FE Ill remain 35 |
31 | CH61 00 1234567801 0129 25 0 8D 5DD5969A D6DB558D 7D8559A7AD54F66EAEAFB75B5ED56E6AD79EAD774D000000EFA9CA010000 0 |
32 | CH40 00 1234567801 0095 12 2 53 D2C00040 00200000 036352D556BAAAA5AA9495 0 |
33 | CH3 00 1234567801 0057 0A 3 DE BAAAAF5D 26CAFD1D 559ABA 6220 B5CA CA72 9E3B 90D8 2C0E B99C D126 84C4 7837 13C0 CA72 B03B B561 CA72 2303 676A 0A2D CA72 28BA C39D 02EA 7EC4 CA72 453A 8D60 |
34 | CH61 00 1234567801 0098 13 0 5A F994F958 B2B5652E B45BFDEFD555B5642B6F6FA9 0 |
35 | CH3 00 1234567801 01AD 35 2 92 8D75AB52 45DB6569 Ill remain 46 |
36 | CH40 00 1234567801 0055 0A 2 5A 54DBFFFE FFFFFFFF FC96AA 0 |
37 | CH75 00 1234567801 00A9 15 0 54 65A55A26 164611AA 289E5474F15AC24DCAAAAAADA52B 0 |
38 | CH61 00 1234567801 00A9 15 0 15 21352A58 A9135A95 6A75281A5F0295356C1A2A0A52D5 0 |
39 | CH75 00 1234567801 0096 12 3 A9 746B7D95 526C6B6E B5B5B12AB1AADAF3BAEADB 0 |
40 | CH40 00 1234567801 00BA 17 1 B5 B6A5A6AE 6B567B4A AA59B55BFDEBFFFEBEFFE92900000800 0 |
41 | CH61 00 1234567801 00B7 16 3 29 ACD6FA65 495420C5 215F52A2BF53F0128294840C1AA733 0 |
42 | CH23 00 1234567801 0022 04 1 E4B25C86AA95 |
43 | CH61 00 1234567801 0095 12 2 56 A6552D54 5BAAB6F4 DCD3ED1EDAAEF56D74EF77 0 |
44 | CH23 00 1234567801 0055 0A 2 A4 8D491611 94AD8ACB 5A4A34 0 |
45 | CH75 00 1234567801 00AE 15 3 56 AB34D096 E959E66B 48954AF776EACA65AAA96EB7D926 0 |
46 | CH3 00 1234567801 00D6 1A 3 E7 9ED2AE6F DA0AAEDB 0ACBFFFFF5BFFFFFFFDAFDDDB7FF76DFEFFBFF 0 |
47 | CH61 00 1234567801 01D5 3A 2 4A DD7AB6D5 AFEAD56E Ill remain 51 |
48 | CH75 00 1234567801 01FF 3F 3 FD FFFFFFF2 43BAB2AA Ill remain 56 |
Entweder kommen wir der Sache grade näher, oder das ist irgendwelches Zigbee oder WiFi-Gefunke, oder mein MiLight-Hub macht Zicken.... (lt. Messgerät kamen grade ca. 308W an).
:
Bearbeitet durch User
Jörg R. schrieb: > Entweder kommen wir der Sache grade näher Scheint so: Bisher war "ONLY_RX" eingeschaltet gewesen, was ohne DTU dann wohl keinen Sinn macht. Steht jetzt auf "0", mal schauen, ob dann heute noch irgendwelche Werte decodiert werden können. Wenn ich das richtig verstanden habe, muss man erst mal ca. 30 Minuten warten?
Jörg R. schrieb: > Ziyat T. schrieb: > Wenn WITHWIFI auf 0 steht (und man dann auch noch die PINS richtig > anpaßt) kommt dann sowas im "sniffer"-Mode: > [code] > 40 00 1234567801 00A0 14 0 52 56AD1089 2D434553 > EA4AE14B1092078000C8EA150C 0 > CH61 00 1234567801 00D5 1A 2 B4 F5BB6BAA A554A84D > 0B2AAA84AD369A9955598AA495283690A95255 0 > CH23 00 1234567801 012A 25 1 55 726ABA6A C9AFAAB5 > DAA59D95A5B5F54AB8724ED56D2B0CA551B7654E96000000000000000000 0 > CH23 00 1234567801 0075 0E 2 6D 7A896B5D B548BADE 953A2AA884D8D0 0 > CH40 00 1234567801 003C 07 2 EDAB15B55256AAAAD5 > CH75 00 1234567801 0095 12 2 69 AB5AA332 759DADDE >>>>>> > Entweder kommen wir der Sache grade näher, oder das ist irgendwelches > Zigbee oder WiFi-Gefunke, oder mein MiLight-Hub macht Zicken.... (lt. > Messgerät kamen grade ca. 308W an). das ist wie im sniffer mode, ist SNIFFER = 0? jedenfalls das ist airtrash! oder DEBUG_RCV_DATA ist 1; kannst du mal DEBUG_TX_DATA = 1 stellen? du kannst es auch im terminal per command 8/9 stellen: 1: help 2:Status 3:PA_LOW 4:PA_HIGH 5:PA_MAX 6:Sniffer 7:ZeroEx 8:OnlyRX 9:ShowTX 10:Wifi 11:CRC 20:WRinfo 21:Gongfa
Wie geschrieben: Das war im Sniffer-Modus. DEBUG_RCV_DATA und DEBUG_TX_DATA stehen jetzt noch auf 1, dann sieht das aktuell so aus (meine aktuelle Leistung wird jetzt dahin gepublisht):
1 | Send... CH40 376010001378563412005C.....send res 0 |
2 | ImpExpW Watt 223.0Watt | All PVs received?:0 |
3 | Send... CH61 3860100013785634120053.....send res 0 |
4 | Send... CH75 3960100013785634120052.....send res 0 |
5 | Send... CH03 366010001378563412005D.....send res 0 |
6 | Send... CH23 376010001378563412005C.....send res 0 |
7 | Send... CH40 3860100013785634120053.....send res 0 |
8 | Send... CH61 3960100013785634120052.....send res 0 |
9 | Send... CH75 366010001378563412005D.....send res 0 |
10 | Send... CH03 376010001378563412005C.....send res 0 |
11 | Send... CH23 3860100013785634120053.....send res 0 |
12 | Send... CH40 3960100013785634120052.....send res 0 |
13 | Send... CH61 366010001378563412005D.....send res 0 |
14 | Send... CH75 376010001378563412005C.....send res 0 |
15 | Send... CH03 3860100013785634120053.....send res 0 |
16 | Send... CH23 3960100013785634120052.....send res 0 |
Komisch kommt mir vor, dass sich die firmware immer wieder den Wert holt, man muss daher mit retain-flag publishen, aber darum kümmern wir uns ggf. später. PA-Level steht jetzt auf "HIGH". Sollte die "echt-DTU-Adresse" aktiviert werden (im Moment ist das die 1234...)?
Jörg R. schrieb: > Wie geschrieben: Das war im Sniffer-Modus. > > DEBUG_RCV_DATA und DEBUG_TX_DATA stehen jetzt noch auf 1, dann sieht das > aktuell so aus (meine aktuelle Leistung wird jetzt dahin gepublisht): >
1 | > Send... CH40 376010001378563412005C.....send res 0 |
2 | > ImpExpW Watt 223.0Watt | All PVs received?:0 |
3 | > Send... CH61 3860100013785634120053.....send res 0 |
4 | > Send... CH75 3960100013785634120052.....send res 0 |
5 | > Send... CH03 366010001378563412005D.....send res 0 |
6 | > Send... CH23 376010001378563412005C.....send res 0 |
7 | > Send... CH40 3860100013785634120053.....send res 0 |
8 | > Send... CH61 3960100013785634120052.....send res 0 |
9 | > Send... CH75 366010001378563412005D.....send res 0 |
10 | > Send... CH03 376010001378563412005C.....send res 0 |
11 | > Send... CH23 3860100013785634120053.....send res 0 |
12 | > Send... CH40 3960100013785634120052.....send res 0 |
13 | > Send... CH61 366010001378563412005D.....send res 0 |
14 | > Send... CH75 376010001378563412005C.....send res 0 |
15 | > Send... CH03 3860100013785634120053.....send res 0 |
16 | > Send... CH23 3960100013785634120052.....send res 0 |
17 | > |
> Komisch kommt mir vor, dass sich die firmware immer wieder den Wert > holt, man muss daher mit retain-flag publishen, aber darum kümmern wir > uns ggf. später. > PA-Level steht jetzt auf "HIGH". > > Sollte die "echt-DTU-Adresse" aktiviert werden (im Moment ist das die > 1234...)? wenn deine wr-sn 104160100013 ist dann sollte es gehen, dtu adr ist egal probiere mal ohne crc kannst auch mal ohne interrupt probieren ich fahre immer ohne crc und interrupt
Die Adresse paßt (jedenfalls steht die so auf dem abfotografierten Etikett), CRC war eh' aus (entsprechend den in der zip enthaltenen Vorgaben). Aktuelle Settings lt. minicom:
1 | DEBUG_RCV_DATA 0 |
2 | DEBUG_TX_DATA 0 |
3 | PA_LEVEL 2 |
4 | WITHWIFI 1 |
5 | ZEROEXP 0 |
6 | INTERRUPT 0 |
7 | SNIFFER 0 |
8 | ONLY_RX 0 |
9 | CHECK_CRC 0 |
Werde das ganze dann nochmal in Ruhe durchgehen müssen bzw. ggf. auch warten, ob sich das "beruhigt" (oder sind die 30 Min Wartezeit bei diesem Code egal?).
Jörg R. schrieb: > Werde das ganze dann nochmal in Ruhe durchgehen müssen bzw. ggf. auch > warten, ob sich das "beruhigt" (oder sind die 30 Min Wartezeit bei > diesem Code egal?). Ich habe mal in Ruhe das "RF_communication_protocol-V6.5.xlsx" angeschaut und gesehen dass 500/600W-Inverter nicht gleich ist wie der 1000/1500W-Inverter, schade EDIT: hier Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Hm, schade, ja. Trotzdem herzlichen Dank für deinen Support bis dahin, dann werde ich mir das mal zu Gemüte führen, vielleicht verstehe ich es ja... Habe in den zwei angehängten Dateien ein paar kleinere Änderungen vorgenommen, damit man die nicht unbedingt direkt editieren muss, sondern die Einstellungen auch über settings.h vornehmen. Klappt zumindest teilweise, betr. MQTT ist kommentiert, inwieweit ich es prüfen konnte. settings.h bekommt dann ein paar weitere Einträge:
1 | // Pinger IP |
2 | #define PINGER_IP {192,168,1,1}
|
3 | |
4 | // MQTT |
5 | bool MQTT_ON = 1; |
6 | #define MSERVER_IP "192.168.1.99" |
7 | #define MSERVER_PORT 1883 |
8 | #define MQTT_ID "HOYMILES-DTU" |
9 | #define VALUE_TOPIC "inverter1" |
10 | #define SET_TOPIC "inverter1/set" |
Hi sage mal wie kann ich meine hardwar so flashen das sie wie am anfang ist ? ich komme null mehr auf das boar d drauf ganz egal wie oft ich brüber flashe. gibt es einen clean befehl den ich vorher absetzen kann ? eike
Der Eike der immer nur will und alles schlecht redet,...
schwall schwall Gummiball.....hast heute schon dein Tabletten genommen ?
@ Eike Im diesem Thread steht folgendes: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Danke Günther, leider komme ich gar nicht mehr auf die Oberfläche sodas ich auch keine Bin laden kann :(
Es ist noch lange nicht Alles von Jedem gesagt...
Angehängte Dateien:
-
30W.png
39 KB
Hallo miteinander! Habe heute Morgen die aktuelle Ahoy 0.5.2 https://github.com/grindylow/ahoy.git geflasht und war dann schon fast am Verzweifeln. E ist ein Fehler in der defines.h wodurch der Wert für powerlimit mit dem Wert von NTP_ADDR überschrieben wird. in defines.h Zeile 99
1 | #define ADDR_NTP_ADDR ADDR_INV_MAX_RTRY + INV_MAX_RTRY_LEN |
ändern in
1 | #define ADDR_NTP_ADDR ADDR_INV_PWR_LIM + INV_PWR_LIM_LEN |
Dann funktioniert das PowerLimit. Vieln dank an alle! Jetzt kann ich auch in der Nacht einspeisen! Bitte rasch ändern sonst gibt es einen Schwung nasse Augen heute wegen Limit 0W.
Jörg R. schrieb: > Hm, schade, ja. Trotzdem herzlichen Dank für deinen Support bis dahin, > dann werde ich mir das mal zu Gemüte führen, vielleicht verstehe ich es > ja... hallo Jörg habe mal wieder eine quick&dirty version, dieses mal für MI300/600/1500, kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h" anpassen dann auf "Settings.h" aendern und testen? einfach ohne wifi,mqtt etc. bool DEBUG_TX_DATA = 1; damit wir was sehen nach dem wir die daten bekommen, können wir alle andere anpassen
Hallo Leute Wir versuchen hier ein Projekt durchzuführen, mit so vielen Beitraegen (über 2000) wird es immer schwieriger es zu verfolgen. Also bitte lass das Gequassel über Tabletten und so!
Angehängte Dateien:
Ziyat T. schrieb: > kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h" > anpassen dann auf "Settings.h" aendern und testen? WOW, was ein Service! Hatte gestern noch auf das xlsx gestarrt und das Projekt abgehakt, und jetzt sowas.... Also, vermutlich suchen wir nach sowas hier, oder:
1 | 17 MI600 |
2 | Send... CH61 11601000132143658700F2.....send res 0 |
3 | New CMD 8a CH23 00 8765432101 00C4 18 2 8A FFFFFFE6 F77FD57A BB6AAAD96656A95341A2A6BAA7AAA88634 0 |
4 | 9 MI600 |
5 | Send... CH75 09601000132143658700EA.....send res 0 |
6 | 17 MI600 |
7 | Send... CH03 11601000132143658700F2.....send res 0 |
8 | 9 MI600 |
9 | Send... CH23 09601000132143658700EA.....send res 0 |
10 | 17 MI600 |
11 | Send... CH40 11601000132143658700F2.....send res 0 |
12 | 9 MI600 |
13 | Send... CH61 09601000132143658700EA.....send res 0 |
14 | New CMD 8b CH61 00 8765432101 0080 10 0 8B E5B35477 59DAB6DB 2D55F1B75EB6B55555 0 |
PS: spricht was dagegen, wifi.h und mqtt.h auszutauschen? Dann kann man alles zentral über Settings.h anfassen, was zu individualisieren ist (zumindest mittelfristig...) EDIT: Es zuckt auch mit aktivem WiFi, ist aber nicht durchgängig plausibel, siehe angehängten screenshot
:
Bearbeitet durch User
Gerald R. schrieb: > Bitte rasch ändern sonst gibt es einen Schwung nasse Augen heute wegen > Limit 0W. Oh ja, den Schwung hatte ich :D Danke für die Info!!!
Jörg R. schrieb: > Ziyat T. schrieb: >> kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h" >> anpassen dann auf "Settings.h" aendern und testen? > WOW, was ein Service! Hatte gestern noch auf das xlsx gestarrt und das > Projekt abgehakt, und jetzt sowas.... > 9 MI600 > Send... CH75 09601000132143658700EA.....send res 0 > 17 MI600 > Send... CH03 11601000132143658700F2.....send res 0 also wir senden 0x9 und 0x11 das ist mal gut > PS: spricht was dagegen, wifi.h und mqtt.h auszutauschen? Dann kann man > alles zentral über Settings.h anfassen, was zu individualisieren ist > (zumindest mittelfristig...) im moment will ich nur über serial/minicom die daten kommen sehen, nehme an du hast 2 PV's, die im setting.h definiert sind, dann müsste z.B. so was kommen: CH:3 PV0 MI: xxxW Grd: 0W Lm: 0W xxxW 38.5V 0.0A 854Wh 245.5ACV 50.0Hz CH:75 PV1 MI: xxxW Grd: 0W Lm: 0W xxxW 38.5V 0.0A 854Wh 245.5ACV 50.0Hz oder, für data New CMD 89, New CMD 92 dann für die status meldung New CMD 88, New CMD 91 kommen EDIT: ev. schickst du mir ein laengeres minicom log?
:
Bearbeitet durch User
Angehängte Dateien:
Ja, 2 PV's sind definiert. Wenn man das ganze etwas länger laufen läßt, werden auch beide gefüllt, die Daten sind im Moment halt nur mehr oder weniger inkonsistent, was diese "Nebeninfos" anbelangt (siehe Screenshot). Per minicom -C habe ich jetzt auch einen Mitschnitt gemacht, blöd ist nur, dass man da die ganzen loop-Infos drin hat, die das zum einen sehr aufblähen, und zum anderen halt nicht wirklich hilfreich sind... Gibt es einen besseren Weg, nur den relevanten Teil mitzuschneiden? Per Maus markieren ist auch ziemlich - na ja...
Jörg R. schrieb: > Ja, 2 PV's sind definiert. Wenn man das ganze etwas länger laufen läßt, > werden auch beide gefüllt, die Daten sind im Moment halt nur mehr oder > weniger inkonsistent, was diese "Nebeninfos" anbelangt (siehe > Screenshot). > > Per minicom -C habe ich jetzt auch einen Mitschnitt gemacht, blöd ist > nur, dass man da die ganzen loop-Infos drin hat, die das zum einen sehr > aufblähen, und zum anderen halt nicht wirklich hilfreich sind... Gibt es > einen besseren Weg, nur den relevanten Teil mitzuschneiden? Per Maus > markieren ist auch ziemlich - na ja... ok, im .ino alles mit "\b\b\b\b" auskommentieren, dann sollten nur die daten geloggt werden so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?
Ziyat T. schrieb: > so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder? Kurzzeitig hatte ich mal in beiden PVx plausible Watt-Werte stehen. Zwischenzeitlich kamen bei den ganzen Versuchen gar keine Werte rein; keine Ahnung, ob ich jetzt den/die nRF geschrottet hatte, oder was grade los ist - bzw. jetzt habe ich den nRF wieder auf die pa+nla-Variante getauscht, jetzt kommen wenigstens Initial-Werte rein, aber im laufenden Betrieb sehe ich grade nur die ganzen Send-Anweisungen. Problem mit der Spannungsversorgung des Ganzen? (Wie ganz am Anfang erläutert, ist da eine Adapterplatine dazwischen mit eigenem Spannungswandler 5V->3.3V + diversen Kondensatoren, siehe auch die Abbildung bei https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo).
Jörg R. schrieb: > Ziyat T. schrieb: >> so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder? > > Kurzzeitig hatte ich mal in beiden PVx plausible Watt-Werte stehen. > Zwischenzeitlich kamen bei den ganzen Versuchen gar keine Werte rein; > keine Ahnung, ob ich jetzt den/die nRF geschrottet hatte, oder was grade > los ist - bzw. jetzt habe ich den nRF wieder auf die pa+nla-Variante > getauscht, jetzt kommen wenigstens Initial-Werte rein, aber im laufenden > Betrieb sehe ich grade nur die ganzen Send-Anweisungen. > > Problem mit der Spannungsversorgung des Ganzen? (Wie ganz am Anfang > erläutert, ist da eine Adapterplatine dazwischen mit eigenem > Spannungswandler 5V->3.3V + diversen Kondensatoren, siehe auch die > Abbildung bei > https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo). mit der spannungsversorgung habe ich mich überhaupt nicht beschaeftigt, bei mir leauft es direkt PC>USB>ESP, ich würde raten, dass du beim sw-testen auch so faehrst. aber immerhin waren die werte mal da und plausible.. ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder 0x092 ist, das müssen wir noch verifizieren
Jörg R. schrieb: > Ziyat T. schrieb: > Also, vermutlich suchen wir nach sowas hier, oder: >
1 | 17 MI600 |
2 | > Send... CH61 11601000132143658700F2.....send res 0 |
3 | > New CMD 8a CH23 00 8765432101 00C4 18 2 8A FFFFFFE6 F77FD57A |
4 | > BB6AAAD96656A95341A2A6BAA7AAA88634 0 |
5 | > 9 MI600 |
6 | > Send... CH75 09601000132143658700EA.....send res 0 |
7 | > 17 MI600 |
8 | > Send... CH03 11601000132143658700F2.....send res 0 |
9 | > 9 MI600 |
10 | > Send... CH23 09601000132143658700EA.....send res 0 |
11 | > 17 MI600 |
12 | > Send... CH40 11601000132143658700F2.....send res 0 |
13 | > 9 MI600 |
14 | > Send... CH61 09601000132143658700EA.....send res 0 |
15 | > New CMD 8b CH61 00 8765432101 0080 10 0 8B E5B35477 59DAB6DB |
16 | > 2D55F1B75EB6B55555 0 |
17 | > |
Hallo Joerg / Ziyat T. Danke dass ihr Euch um die alten Gen2 MI Wechselrichter kümmert, ihr seid da ja die Vorreiter was die antiken Schätzchen angeht. Ja wie ihr schon herausgefunden habt: * MI-300 verwendet nur einen MPPT, daher Cmd 09 * MI-600 verwendet zwei MPPT, daher Cmd 09 und Cmd 11 * MI-1200 verwendet zwei MPPT mit je zwei Eingänge, daher Cmd 36, 37, 38 und 39 wie von Ziyat bereits implementiert. @Joerg R., d.h. Du wirst die Ehre haben MI-300 und MI-600 zu implementieren und beide MPPT testen zu können. Ich glaube die Felder die vom WR zurückkommen sind bei MI-300,600 und 1200 ziemlich ähnlich. Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den DTU-Pro Source Code. Das Power Limit hatte Ziyat T. ja m.W. auch schon für die Gen2 MI-Wechselrichter implementiert, das müsste eigentlich auch für MI-300/600 gehen. Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h, etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?
Stefan T. schrieb: > Jörg R. schrieb: >> Ziyat T. schrieb: > Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den > DTU-Pro Source Code. hallo Stefan eigentlich für mich alles klar bis auf: ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder 0x092 ist, im RF_communication_protocol-V6.6.xlsx stehen beide, aber wir werden es rausfinden. > Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch > im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h, > etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ? ja, einverstanden. es ist sowieso sinnvoller alle holymoly versionen unter einem dach anzubieten. sobald es für MI600 laeuft kannst du es von meinem git holen und machen wir bei dir weiter.
Ziyat T. schrieb: > mit der spannungsversorgung habe ich mich überhaupt nicht beschaeftigt, > bei mir leauft es direkt PC>USB>ESP, ich würde raten, dass du beim > sw-testen auch so faehrst. > > aber immerhin waren die werte mal da und plausible.. > ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder > 0x092 ist, das müssen wir noch verifizieren Irgendwie ist da der Wurm drin. Im Moment bekomme ich gar keine Antworten rein, exemplarisch mal ein paar Zeilen (PA-Level ist egal, Ergebnis ist immer dasselbe:
1 | DEBUG_RCV_DATA 1 |
2 | DEBUG_TX_DATA 1 |
3 | PA_LEVEL 2 |
4 | WITHWIFI 0 |
5 | ZEROEXP 0 |
6 | INTERRUPT 0 |
7 | SNIFFER 0 |
8 | ONLY_RX 0 |
9 | CHECK_CRC 0 |
10 | |
11 | SerialIn: 2 Cmd:2 |
12 | 9 MI600 |
13 | Send... CH23 0960100013785634120062.....send res 0 |
14 | 17 MI600 |
15 | Send... CH40 116010001378563412007A.....send res 0 |
16 | 9 MI600 |
17 | Send... CH61 0960100013785634120062.....send res 1 |
18 | 17 MI600 |
19 | Send... CH75 116010001378563412007A.....send res 0 |
20 | 9 MI600 |
21 | Send... CH03 0960100013785634120062.....send res 0 |
22 | 17 MI600 |
23 | Send... CH23 116010001378563412007A.....send res 0 |
24 | 9 MI600 |
25 | Send... CH40 0960100013785634120062.....send res 0 |
26 | 17 MI600 |
27 | Send... CH61 116010001378563412007A.....send res 1 |
28 | 9 MI600 |
29 | Send... CH75 0960100013785634120062.....send res 0 |
30 | 17 MI600 |
31 | Send... CH03 116010001378563412007A.....send res 0 |
32 | 9 MI600 |
33 | Send... CH23 0960100013785634120062.....send res 0 |
34 | 17 MI600 |
35 | Send... CH40 116010001378563412007A.....send res 0 |
36 | 9 MI600 |
37 | Send... CH61 0960100013785634120062.....send res 1 |
38 | 17 MI600 |
39 | Send... CH75 116010001378563412007A.....send res 0 |
40 | 9 MI600 |
41 | Send... CH03 0960100013785634120062.....send res 0 |
42 | 17 MI600 |
43 | Send... CH23 116010001378563412007A.....send res 0 |
44 | 9 MI600 |
45 | Send... CH40 0960100013785634120062.....send res 0 |
46 | 17 MI600 |
47 | Send... CH61 116010001378563412007A.....send res 0 |
48 | 9 MI600 |
49 | Send... CH75 0960100013785634120062.....send res 0 |
50 | 17 MI600 |
51 | Send... CH03 116010001378563412007A.....send res 0 |
52 | 9 MI600 |
53 | Send... CH23 0960100013785634120062.....send res 0 |
54 | 17 MI600 |
55 | Send... CH40 116010001378563412007A.....send res 0 |
56 | 9 MI600 |
57 | Send... CH61 0960100013785634120062.....send res 1 |
58 | 17 MI600 |
59 | Send... CH75 116010001378563412007A.....send res 0 |
60 | 9 MI600 |
61 | Send... CH03 0960100013785634120062.....send res 0 |
62 | 17 MI600 |
63 | Send... CH23 116010001378563412007A.....send res 0 |
64 | 9 MI600 |
65 | Send... CH40 0960100013785634120062.....send res 0 |
66 | 17 MI600 |
67 | Send... CH61 116010001378563412007A.....send res 1 |
68 | 9 MI600 |
69 | Send... CH75 0960100013785634120062.....send res 0 |
70 | 17 MI600 |
71 | Send... CH03 116010001378563412007A.....send res 0 |
72 | 9 MI600 |
73 | Send... CH23 0960100013785634120062.....send res 0 |
74 | 17 MI600 |
75 | Send... CH40 116010001378563412007A.....send res 0 |
76 | 9 MI600 |
77 | Send... CH61 0960100013785634120062.....send res 1 |
78 | 17 MI600 |
79 | Send... CH75 116010001378563412007A.....send res 0 |
80 | 9 MI600 |
81 | Send... CH03 0960100013785634120062.....send res 0 |
82 | 17 MI600 |
83 | Send... CH23 116010001378563412007A.....send res 0 |
84 | 9 MI600 |
85 | Send... CH40 0960100013785634120062.....send res 0 |
86 | 17 MI600 |
87 | Send... CH61 116010001378563412007A.....send res 1 |
88 | 9 MI600 |
89 | Send... CH75 0960100013785634120062.....send res 0 |
90 | 17 MI600 |
91 | Send... CH03 116010001378563412007A.....send res 0 |
92 | 9 MI600 |
93 | Send... CH23 0960100013785634120062.....send res 0 |
94 | 17 MI600 |
95 | Send... CH40 116010001378563412007A.....send res 0 |
96 | 9 MI600 |
97 | Send... CH61 0960100013785634120062.....send res 1 |
Aus der "1" zwischendurch hätte ich jetzt geschlossen, dass der nRF prinzipiell ansprechbar ist, aber halt entweder effektiv nichts sendet oder "nur" nichts mehr hört. Prinzipiell ist das mit den Adapterplatinen eine feine Sache (wie gesagt, ich habe sowohl Erfahrung bei MySensors@nRF24 wie auch den MiLight-Hub von Chris Mullins im Einsatz...), aber dann werde ich das mit einem neuen ESP nochmal mit einem fliegenden "Direktaufbau" versuchen und notfalls meinen Reserve 3.000m-nRF opfern. Betr. der 92/91-Frage: die betreffenden Stellen im Code hatte ich gesehen und auch den Versuch unternommen, das zu tauschen. Vermutlich hatte ich aber nicht alle Stellen im Code erwischt, jedenfalls wurden die Payloads entweder gleich als ungültig verworfen, oder es kam irgendwas absurdes raus. Werde daher jetzt erst nochmal ESP's suchen gehen und ein paar Beinchen anlöten, gehe aber davon aus, dass der 92-er Ansatz der zielführende bleibt (siehe auch den screenshot von vorhin; da passen zumindest die Leistungsdaten vom 2. Kanal)... Stefan T. schrieb: > @Joerg R., d.h. Du wirst die Ehre haben MI-300 und MI-600 zu > implementieren und beide MPPT testen zu können. Ich glaube die Felder > die vom WR zurückkommen sind bei MI-300,600 und 1200 ziemlich ähnlich. > Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den > DTU-Pro Source Code. > Das Power Limit hatte Ziyat T. ja m.W. auch schon für die Gen2 > MI-Wechselrichter implementiert, das müsste eigentlich auch für > MI-300/600 gehen. > > Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch > im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h, > etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ? Na ja, freut mich ja, wenn ich was beitragen kann, und es wäre auch klasse, wenn das in das allgemeine Ahoy-Projekt mit reinkäme - ich hatte uU. die Idee, meine Solarkapazitäten noch auszubauen, und dazu wäre es schön, nicht für jeden WR ein eigenes Interface zu benötigen grins. Wie man das dann integriert, wäre eine weitere Frage, die zumindest derzeit noch außerhalb meiner gefühlten Kompetenz liegt. Mal schauen...
ich habe was gefunden: https://github.com/OFreddy/hm_poll sein copyright in allen sources: /* Copyright (C) 2022 OFreddy die sw (inhaltlich) ist mehr oder weniger von hier, sogar die kommentare stimmen! :-)
Ziyat T. schrieb: > aber immerhin waren die werte mal da und plausible.. > ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x91 oder > 0x92 ist, das müssen wir noch verifizieren Die Antworten haben i.d.R. das erste (höchstwertige) Bit gesetzt: * Anfrage 0x09 -> Antwort 0x09|0x80=0x89 * Anfrage 0x11 -> Antwort 0x11|0x80=0x91 * Anfrage 0x36 -> Antwort 0x36|0x80=0xB6 * Anfrage 0x37 -> Antwort 0x37|0x80=0xB7 * Anfrage 0x38 -> Antwort 0x38|0x80=0xB8 * Anfrage 0x39 -> Antwort 0x39|0x80=0xB9 Hoffe das hilft.
Jörg R. schrieb: > Ziyat T. schrieb: > Aus der "1" zwischendurch hätte ich jetzt geschlossen, dass der nRF > prinzipiell ansprechbar ist, aber halt entweder effektiv nichts sendet > oder "nur" nichts mehr hört. sniffer mode einstellen, schauen ob etwas rein kommt auf .....send res 0 ist kein verlass
Ziyat T. schrieb: > sniffer mode einstellen, schauen ob etwas rein kommt > auf .....send res 0 ist kein verlass OK, dann schaut es doch so aus, als würde der nRF was hören:
1 | CH75 00 1234567801 0095 12 2 5A 95D95AD2 A4A25214 5555548D85328AC0001000 0 |
2 | CH3 00 1234567801 00DA 1B 1 D5 AD6EEE56 572CAAAF A96D57D5377FFFCBB777DED77EA9F5BFFE3959DE 0 |
3 | CH75 00 1234567801 0124 24 2 24 955AA853 500AA4AC FA8A42A5A1499A481000A404A9452052AC455912220000000000000000 0 |
4 | CH3 00 1234567801 012B 25 1 3A ABAD9756 959D4656 5A8AD5A5BFBFFC550A4B255B9ACCEAAB62AA72E3B5000000000000000000 0 |
5 | CH75 00 1234567801 0029 05 0 526B42AA4A85D8 |
6 | CH3 00 1234567801 00AA 15 1 C5 5A149581 A750D50E 9D3496D2954AEAA8F346ADCDE1DF 0 |
7 | CH61 00 1234567801 0165 2C 2 B5 F55B2DBD FFFBFFBD Ill remain 37 |
8 | CH40 00 1234567801 0135 26 2 26 5290412D 52CB4AB0 2EA52AD56AA96DAE6AD9AAAD5BA5EA4B0EB1D6A7EE00000000000000000000 0 |
9 | CH75 00 1234567801 01EB 3D 1 F8 85080000 00004000 Ill remain 54 |
10 | CH40 00 1234567801 0195 32 2 66 D54AC94C B5BDAAD5 Ill remain 43 |
11 | CH3 00 1234567801 01C5 38 2 65 C5950416 D325610A Ill remain 49 |
12 | CH3 00 1234567801 0039 07 0 8AD725212AE264AAAA |
13 | CH23 00 1234567801 016A 2D 1 B6 D7CB9D6B 51A0B241 Ill remain 38 |
Oder ist das eine Fehlinterpretation? (Wäre schön zu wissen, ob sich das mit dem Lötkolben lohnt...)
Jörg R. schrieb: > CH3 00 1234567801 01C5 38 2 65 C5950416 D325610A Ill remain 49 > CH3 00 1234567801 0039 07 0 8AD725212AE264AAAA > CH23 00 1234567801 016A 2D 1 B6 D7CB9D6B 51A0B241 Ill remain 38 > [/code] > Oder ist das eine Fehlinterpretation? > > (Wäre schön zu wissen, ob sich das mit dem Lötkolben lohnt...) ich würde sagen er hört etwas, ev. NRF sendet nicht? morgen nach dem wr reset wieder probieren
Hmmm, kann es sein, dass den WR die hohe Anfragefrequenz stört? Hatte zwischendurch wieder den WiFi-Modus an und dann wieder Sniffer. Wenn ich es richtig interpretiert habe (?), wird im Sniffer-Mode nichts gesendet. Es kommen dann aber noch ein paar Messages rein, danach ist wieder ziemlich Ruhe. Vielleicht ist das eine Fehlinterpretation, aber ggf. ist es kontraproduktiv, zu viele Anfragen zu senden? Also: DTU meldet: "ich bin da, sende was!" WR sendet eine Zeitlang wie angefordert, bis wieder eine Art Ping kommt für "DTU ist noch da". Anders gesagt: Das Dauerfeuer, das wir hier veranstalten kommt mir nicht plausibel vor.... Auf die Schnelle wäre ein Hinweis hilfreich, wo man die Sendefrequenz für die Anfragen reduzieren könnte? EDIT: Wg. der libs - bin da alles andere als erfahren, und bevor ich mich da reinzufuchsen versuche wäre ein Wink auch ganz nett, wenn ich mich einfach gedulden darf... EDIT2: habe wieder den WiFi-Modus angemacht und jetzt sind wieder für Kanal 1 einigermaßen plausible Daten da (v.a. was die (halbe) Leistung angeht... EDIT3: Jetzt sind mir doch noch ein paar Nachrichten ins minicom-log geflogen - vielleicht kann jemand was damit anfangen. Die Frequenzen im Web-Interface sind jedenfalls nicht plausibel (anders als (meistens) vorhin).
:
Bearbeitet durch User
Angehängte Dateien:
Jörg R. schrieb: > Hmmm, kann es sein, dass den WR die hohe Anfragefrequenz stört? > > Hatte zwischendurch wieder den WiFi-Modus an und dann wieder Sniffer. > Wenn ich es richtig interpretiert habe (?), wird im Sniffer-Mode nichts > gesendet. Es kommen dann aber noch ein paar Messages rein, danach ist >>>>>>>>>>>>> es kann schon sein dass der wr zu macht, in void isTime2Send (void) die zeile if (millis() >= tickMillis) { tickMillis += 300; <<<<<<< mit der kannst du spielen vom log file: status v. kanal B, status 3: CH3 00 1234567801 0082 10 1 92 60100013 60100013 000300000000913454 1 data v. kanal A: CH75 00 1234567801 00C4 18 2 89 60100013 60100013 01310023093A138D040408960179D1B273 1 die sind richtig, siehe screenshot im anhang also diese zeilen aendern: case 0x89: //1-2 ports case 0x91: //2 ports <<<<<<<<<<<<<<<<<< MI600DataMsg(p); break; case 0x88: //1-2 ports case 0x92: //2 ports <<<<<<<<<<<<<<<<<< MI600StsMsg(p); break; und: if (p->packet[2] == 0x91) {PV= 1; TotalP[2]=P_DC; pvCnt[1]=1;}//port 2
:
Bearbeitet durch User
Eine Sekunde eingestellt und die Stellen angepaßt => Leistungsdaten für Kanal 2 sind plausibel freu Kanal 1 ist zwar im Moment noch tot, aber da bin ich optimistisch... Vielleicht hängt es doch auch an der Spannungsversorgung, das grade aktive pa+nla braucht halt mehr Saft als das kleine, und die Frequenz ist vielleicht dann das Tröpfchen...?
Jörg R. schrieb: > Eine Sekunde eingestellt und die Stellen angepaßt => Leistungsdaten für > Kanal 2 sind plausibel *freu* > Kanal 1 ist zwar im Moment noch tot, aber da bin ich optimistisch... > Vielleicht hängt es doch auch an der Spannungsversorgung, das grade > aktive pa+nla braucht halt mehr Saft als das kleine, und die Frequenz > ist vielleicht dann das Tröpfchen...? ja super, aber eine sekunde ist definitiv zu lang denke ich.. kannst du mal DEBUG_TX_DATA = 0 stellen und ein minicom log schicken?
Anbei mal ein log mit 350. Hab's jetzt wieder mit 300 laufen - hatte ja mal so funktioniert, mal schauen.... Kanal 2 kommt allerdings nichts an Leistung, dafür wieder Kanal 1...
:
Bearbeitet durch User
Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke und mir ist da etwas aufgefallen: Irgendwann verabschieden sich meine beiden dauer-laufenden Installationen gerne mal mit einem watchdog reset (Ursache noch unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den Hanger nicht, erst nach einem Power Reset läuft alles wieder. Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann sehe ich einen falschen Bootloader Mode: ets Jan 8 2013,rst cause:2, boot mode:(1,6) verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man sollte also den IRQ besser woanders hinlegen, meine ich.
Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2 erfolgreich getestet. Allerdings habe ich das Limit in den Settings gesetzt. - Ist es möglich das Limit über MQTT vorzugeben? - Wäre eine Anzeige des aktuellen Limit über MQTT möglich / sinnvoll? Übrigens läuft seit 0.4.26 MQTT perfekt. MQTT "not connected" gibt es seitdem nicht mehr!! Super Job, Danke!!
Peter S. schrieb: > Irgendwann verabschieden sich meine beiden dauer-laufenden > Installationen gerne mal mit einem watchdog reset (Ursache noch > unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den > Hanger nicht, erst nach einem Power Reset läuft alles wieder. Diesen Phänomen kann ich bestätigen. Meine Installation ist stabil augebaut, das nRF24L01+-Modul hat wird über einen separaten 3,3V-Spannungsregler versorgt, dennoch bleiben Abstürze nicht aus. Erwähnt werden soll aber auch, dass die Stabilität deutlich größer geworden ist - mein "Rekord" liegt bei fünf Tagen.
Chris schrieb: > Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2 > erfolgreich getestet. Allerdings habe ich das Limit in den Settings > gesetzt. > - Ist es möglich das Limit über MQTT vorzugeben? Von drschiffler/discord:
1 | subcribed topics are mTopic + "/devcontrol/#" where # is <inverter_id>/<subcmd in dec> |
2 | eg. mypvsolar/devcontrol/1/11 with payload "400" --> inverter 1 active power limit 400 Watt |
3 | mTopic ist das was im Setup eingetragen ist. |
4 | mit <mTopic>/devcontrol/0/0 + payload beliebig --> einschalten |
5 | mit <mTopic>/devcontrol/0/1 + payload beliebig --> ausschalten |
6 | mit <mTopic>/devcontrol/0/11 + payload xxx --> Limit auf xxx Watt |
7 | mit <mTopic>/devcontrol/0/2 + payload beliebig --> neustart |
8 | Beispiele alle mit Inverter Id 0 |
Achtung: Das Limit per MQTT ist nicht-permanent (find ich auch gut & richtig so, sonst wird das EEPROM auf Dauer zerstört).
Peter S. schrieb: > Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke > und mir ist da etwas aufgefallen: > Irgendwann verabschieden sich meine beiden dauer-laufenden > Installationen gerne mal mit einem watchdog reset (Ursache noch > unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den > Hanger nicht, erst nach einem Power Reset läuft alles wieder. > Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann > sehe ich einen falschen Bootloader Mode: > ets Jan 8 2013,rst cause:2, boot mode:(1,6) > verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man > sollte also den IRQ besser woanders hinlegen, meine ich. Hallo Peter S., danke für den Hinweis, wir diskutieren das Problem schon seit geraumer Zeit in https://github.com/grindylow/ahoy/issues/36 Ich werde Deine Antwort dort mal hinzufügen. Eigentlich war die ursprüngliche Intention die Pins D1/D2 für I2C oder andere zukünftige Anwendungen (ModBus485, etc.) freizuhalten. Bisher hatte ich als Grund für die WDT Resets meist ein Problem in umm_malloc ausgemacht. Ich vermute das hängt mit der Nutzung der String-Implentierung im ESP8266 zusammen. Weitere Debug Output dazu packe ich auch in das o.g. Issue Gibt es nicht eine einfache Möglichkeit den GPIO0 / D3 beim Booten auf High zu ziehen -> RC-Glied ?
Moin, anbei mal das, was so über einen Zeitraum von etwa einer Stunde so via minicom reingekommen ist. Im Web-Interface ergibt das keine plausiblen Daten, aber immerhin wird "irgendwas" empfangen. Sieht für mich nach einem Problem in der Auswertung aus. Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt erst mal nicht möglich.
Jörg R. schrieb: > Anbei mal ein log mit 350. > > Hab's jetzt wieder mit 300 laufen - hatte ja mal so funktioniert, mal > schauen.... > Kanal 2 kommt allerdings nichts an Leistung, dafür wieder Kanal 1... einige anpassungen, mqtt on/off über settings.h wenn ZEROEXP = 0, keine mqtt subscription "ImpExpW" viel glück ;-)
Jörg R. schrieb: > Sieht für mich nach einem Problem in der Auswertung aus. > > Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt > erst mal nicht möglich. Wollt ich auch schon immer mal sagen.
Jörg R. schrieb: > Moin, > > anbei mal das, was so über einen Zeitraum von etwa einer Stunde so via > minicom reingekommen ist. Im Web-Interface ergibt das keine plausiblen > Daten, aber immerhin wird "irgendwas" empfangen. > > Sieht für mich nach einem Problem in der Auswertung aus. > > Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt > erst mal nicht möglich. diese sind kanal A daten: CH23 00 1234567801 00C0 18 0 89 60100013 60100013 014F00140BF555F7FDDEB6AF5B9772FB37 0 CH40 00 1234567801 00C2 18 1 89 60100013 60100013 01F6DECABF5B5AF55F7D79EDACAB737557 0 CH3 00 1234567801 00C2 18 1 89 60100013 60100013 01490029091013860520004D7E57F3D6DF 0 diese sind kanal B daten: CH23 00 1234567801 00C2 18 1 91 60100013 60100013 07AAD1FDF9F7EF75FBFDF3DF7AFDB6BB2A 0 CH40 00 1234567801 00C4 18 2 91 60100013 60100013 01510555F576FD7DBBE7B7EBDD3D6BADBB 0 CH61 00 1234567801 00C6 18 3 91 60100013 60100013 01CB5AF9767B2BFFF5DAA0912210850421 0 wenn 0x89 oder 0x90 kommen, hier sind sie ja, dann müsste "MI600DataMsg(p)" aufgerufen werden, dann müsste im serial monitor so was stehen: PV:1 37.30V 0.40A 15.10W 992.00Wh 233.40V 49.99Hz 31.80C Sts:3 Cnt:0
diese sind status msg. kanal A CH75 00 1234567801 0080 10 0 88 60100013 60100013 0003000000008BD407 0 CH61 00 1234567801 0080 10 0 88 60100013 60100013 0003000000008BD40D 1 diese sind status msg. kanal B CH3 00 1234567801 0082 10 1 92 60100013 60100013 000300000000913F58 0 H61 00 1234567801 0080 10 0 92 60100013 60100013 000300000000911590 1 CH75 00 1234567801 0080 10 0 92 60100013 60100013 0003000039EEBD6B5B 0 beide kanaele sind ON und produzieren (0003) also, es kommen schon mal richtige daten, das ist doch mal sehr gut, den rest schaffen wir doch auch noch
hallo Jörg also ich habe die daten überprüft, die sind nicht plausibel, verwende bitte das neue .ino im anhang. ich würde mal in settings.h die CHECK_CRC = 1 stellen und mal keine wifi und so.
Ich habe mir den dtu White gekauft und drangesteckt. Hier kommt jetzt die Fehlermeldung das die sn des Wechselrichter falsch ist. Kann ich die irgendwo ermitteln ? Ja ich habe die richtige vom Aufkleber eingetragen. Ich kann zwar noch immer nicht auf mein opendtu zugreifen aber das mir mittlerweile egal
Joni N. schrieb: > Chris schrieb: >> Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2 >> erfolgreich getestet. Allerdings habe ich das Limit in den Settings >> gesetzt. >> - Ist es möglich das Limit über MQTT vorzugeben? > > Von drschiffler/discord: > >
1 | subcribed topics are mTopic + "/devcontrol/#" where # is |
2 | > <inverter_id>/<subcmd in dec> |
3 | > eg. mypvsolar/devcontrol/1/11 with payload "400" --> inverter 1 active |
4 | > power limit 400 Watt |
5 | > mTopic ist das was im Setup eingetragen ist. |
6 | > mit <mTopic>/devcontrol/0/0 + payload beliebig --> einschalten |
7 | > mit <mTopic>/devcontrol/0/1 + payload beliebig --> ausschalten |
8 | > mit <mTopic>/devcontrol/0/11 + payload xxx --> Limit auf xxx Watt |
9 | > mit <mTopic>/devcontrol/0/2 + payload beliebig --> neustart |
10 | > Beispiele alle mit Inverter Id 0 |
> > Achtung: Das Limit per MQTT ist nicht-permanent (find ich auch gut & > richtig so, sonst wird das EEPROM auf Dauer zerstört). Hallo, gute Aufbereitung und Hilfe. Leider komme ich damit nicht klar. Über Mqtt bekomme ich das nicht hin (Version 0.5.2). Ich versuche über mqttfx die Limitierung zu senden, aber ohne Erfolg. Topic: dtu name: hm600 dann sollte das für den 1. Inverter doch so aussehen: "dtu/devcontrol/0/11 + payload 400" oder nicht? Danke für weitere Hilfe.
:
Bearbeitet durch User
@Frank So ist es richtig devControl commands via MQTT Topic (/devcontrol/subcmd + payload); eg. mysolar/devcontrol/1/0 --> turn on inverter 1; eg. mysolar/devcontrol/1/1 --> turn off; mysolar/devcontrol/0/11 + payload "300" --> set power limit for inverter 1 to 300 W (set power is now remanent during inverter power cycle and remanent during power cycle of ahoy and power limit is set on each reboot/start up THX: @klahus1) Set power limit in setup page; Save --> writes to eeprom --> reboot --> after reboot set power limit acc. to eeprom Set power limit to zero --> inverter will not stop working (Reactive Power <> 0 VAr) but active power will be zero During change of power limit eg. 200 W --> 500 W, the Powerfactor is not controled Case "set to unlimited power": NOT working by setting it to large numbers or -1 or similar. You have to set it acc. to the specific device eg. Mi-1500 --> 1500. There is an error handling because the response from inverter differs in case the new power limit is NOT accepted. See logs.
Ziyat T. schrieb: > bitte das neue .ino im anhang. Anbei das log dazu. Da aber erst mal gar nichts passiert ist, habe ich doch Wifi zugeschaltet. Jetzt kann man auch besser erkennen, wie die (m.E. zu) wenigen Messages in etwa reinkamen. Wenn nicht verändert, macht FHEM ca. alle 5 Min. ein publish. Kurzfassung: Beide Kanäle werden ausgewertet, aber es sind zu wenige Datenpunkte und das "Beiwerk" ist komisch. Effektiv was empfangen wird mehr oder weniger nur, wenn auch WiFi läuft, warum auch immer. Habe die effektiv verwendeten Parts dann auch per pull request an dich geschickt.
:
Bearbeitet durch User
Jörg R. schrieb: > Ziyat T. schrieb: >> bitte das neue .ino im anhang. > > Anbei das log dazu. Da aber erst mal gar nichts passiert ist, habe ich > doch Wifi zugeschaltet. > > Jetzt kann man auch besser erkennen, wie die (m.E. zu) wenigen Messages > in etwa reinkamen. Wenn nicht verändert, macht FHEM ca. alle 5 Min. ein > publish. > > Kurzfassung: Beide Kanäle werden ausgewertet, aber es sind zu wenige > Datenpunkte und das "Beiwerk" ist komisch. Effektiv was empfangen wird > mehr oder weniger nur, wenn auch WiFi läuft, warum auch immer. > > Habe die effektiv verwendeten Parts dann auch per pull request an dich > geschickt. das ist interresant, dass mit wifi "mehr" empfangen kannst, bei mir ist das genau umgekehrt! die daten sind irgendwie in der luft zu fest gestört, darum mit CHECK_CRC=1 siehst du selten etwas. wenn du mein letztes .ino verwendest: - wir sehen welche und wie viele daten nicht plausibel sind - in settings.h WITHMQTT = 0 stellen, dann sollten diese meldg. nicht mehr kommen: Attempting to connect to the MQTT broker: 192.168.2.2 MQTT connected = 0 Subscribing to topics.. so haben wir "saubere" logs.
Ziyat T. schrieb: > die daten sind irgendwie in der luft zu fest gestört, darum mit > CHECK_CRC=1 siehst du selten etwas. Na ja, hier läuft halt "alles" zusammen: WLAN, BT, ZigBee, (selten MiLight) und nun eben (wieder) nRF24. Habe den CRC-Check jetzt mal ausgeschaltet und lass das Ding auch über Nacht laufen, eigentlich sollte kaum noch was vom WR kommen (vorhin waren 7 Watt oder so). Der MQTT-Import-Code hat übrigens eine Macke: Immer wenn es eine Stelle weniger wird, bleiben die hinteren stehen, aus 101 => 98 werden dann 981W (leider nicht in der Realität...)
Manuel M. schrieb: > 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. Hallo Manuel, hast du es in FHEM eigentlich noch hinbekommen? Ich kann die Daten meiner beiden Wechselrichter und der Channels nicht unterscheiden im Fhem. Ich bin allerdings auch totaler Noob, was MQTT angeht. Hast du vielleicht ein Beipiel für mich aus deiner Konfig? Oder eine gute Quelle, wo ich mich dazu einlesen kann? Gruß Carsten
Carsten B. schrieb: > hast du es in FHEM eigentlich noch hinbekommen? Es gibt einen ersten attrTemplate-Vorschlag dazu im FHEM-Forum. Bitte ggf. da anhängen.
Ziyat T. schrieb: > die daten sind irgendwie in der luft zu fest gestört, darum mit > CHECK_CRC=1 siehst du selten etwas. ....da scheint wirklich viel los zu sein, hier mal ein Auszug von dem, was ohne CRC-Check vorhin los war. Habe dazu mal PA_MIN eingestellt und bin dann etwas weiter weg, dann war das besser.
1 | CH23 00 1234567801 00C6 18 3 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF56001900CADB78ED 0 |
2 | New CMD ff CH23 00 1234567801 00C6 18 3 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF56001900CADB78ED 0 |
3 | CH23 00 1234567801 00C6 18 3 97 FFFFFFFF FFFDCD58 E6C6AA5D2A2151BFC20000000000000000 0 |
4 | New CMD 97 CH23 00 1234567801 00C6 18 3 97 FFFFFFFF FFFDCD58 E6C6AA5D2A2151BFC20000000000000000 0 |
5 | CH23 00 1234567801 0080 10 0 89 6FFFFFFF FF4AD0B5 68A85A6C99A45551FF 0 |
6 | CH23 00 1234567801 00DF 1B 3 FD FFFFFFFF FF7EFFFF FFFFFFFFFFFFFFFFF754001900C9DC20553FFFFF 0 |
7 | New CMD fd CH23 00 1234567801 00DF 1B 3 FD FFFFFFFF FF7EFFFF FFFFFFFFFFFFFFFFF754001900C9DC20553FFFFF 0 |
8 | CH23 00 1234567801 00C3 18 1 FF FFF02D76 AAAD1CA2 4AA2BED62EC38AFF820000000000000001 0 |
9 | New CMD ff CH23 00 1234567801 00C3 18 1 FF FFF02D76 AAAD1CA2 4AA2BED62EC38AFF820000000000000001 0 |
10 | CH23 00 1234567801 00FF 1F 3 FF FFFFF4BA 6A8A96F6 AC2A4985F55A3FA40000000000000000000B25ADC9000000 0 |
11 | New CMD ff CH23 00 1234567801 00FF 1F 3 FF FFFFF4BA 6A8A96F6 AC2A4985F55A3FA40000000000000000000B25ADC9000000 0 |
12 | CH23 00 1234567801 00C4 18 2 9F FFFFFFF7 FFFFFD4A 552EAB8B15496A27F90000000000000000 0 |
13 | New CMD 9f CH23 00 1234567801 00C4 18 2 9F FFFFFFF7 FFFFFD4A 552EAB8B15496A27F90000000000000000 0 |
14 | CH3 00 1234567801 0082 10 1 91 7FFFFBFF FFFFFFFF EFFE5A94B1AC505550 0 |
15 | CH3 00 1234567801 00C2 18 1 91 67FFFFFF FFFFFFEB FFFFFFFFFFFFC8ADA4FF00000000000000 0 |
16 | CH3 00 1234567801 00C4 18 2 89 7FF7FFFF FFFDFFFF FDFFFBFFFFFFFFDFFFFFFFAB00CCB19974 0 |
17 | CH23 00 1234567801 00C4 18 2 9F FFFFFFFF FBFFFFFF FFFFDFFFFFFFFFFFFFFF400900CCB1997C 0 |
18 | New CMD 9f CH23 00 1234567801 00C4 18 2 9F FFFFFFFF FBFFFFFF FFFFDFFFFFFFFFFFFFFF400900CCB1997C 0 |
19 | CH23 00 1234567801 00FF 1F 3 FF D852A545 52AEA8A4 694B45502AEA8DF500000000000000000032B2CAA5000000 0 |
20 | New CMD ff CH23 00 1234567801 00FF 1F 3 FF D852A545 52AEA8A4 694B45502AEA8DF500000000000000000032B2CAA5000000 0 |
21 | CH23 00 1234567801 01FF 3F 3 FF FFFFFFFF FFFFFFFF Ill remain 56 |
22 | New CMD ff CH23 00 1234567801 01FF 3F 3 FF FFFFFFFF FFFFFFFF Ill remain 56 |
23 | CH23 00 1234567801 01FB 3F 1 FF FFFFFFFF BFFFFFFF Ill remain 56 |
24 | New CMD ff CH23 00 1234567801 01FB 3F 1 FF FFFFFFFF BFFFFFFF Ill remain 56 |
25 | CH3 00 1234567801 00C6 18 3 91 6011FFFF FFFFFFFF FFFFFFFFFFF495584BA3FE100000000000 0 |
26 | CH23 00 1234567801 00FF 1F 3 FF FFFFFFFF FFFFFFFF FFDFFFFFFFF7FFFFFB7C000900CDA831F13FFFFFFF000000 0 |
27 | New CMD ff CH23 00 1234567801 00FF 1F 3 FF FFFFFFFF FFFFFFFF FFDFFFFFFFF7FFFFFB7C000900CDA831F13FFFFFFF000000 0 |
28 | CH23 00 1234567801 00DF 1B 3 FF FFFFFFFF FFFFFFFF FFFFFFFFFFE6B7FC0000000000000000002CA552 0 |
29 | New CMD ff CH23 00 1234567801 00DF 1B 3 FF FFFFFFFF FFFFFFFF FFFFFFFFFFE6B7FC0000000000000000002CA552 0 |
30 | CH23 00 1234567801 00FF 1F 3 EF F663A89A 9394B692 AAB52652AA693FD000000000000000000036D54A65000000 FE5F FE5F 42D1 42D1 80 |
31 | New CMD ef CH23 00 1234567801 00FF 1F 3 EF F663A89A 9394B692 AAB52652AA693FD000000000000000000036D54A65000000 0 |
32 | CH23 00 1234567801 00DF 1B 3 FF FF5368B6 F6AA70EB B5120A32DBA627F80000000000000000002916AD 0 |
33 | New CMD ff CH23 00 1234567801 00DF 1B 3 FF FF5368B6 F6AA70EB B5120A32DBA627F80000000000000000002916AD 0 |
34 | CH23 00 1234567801 00C0 18 0 8F FFFFFFFF FFFFFFFF FFE2EA98A5359EB7F90000000000000000 0 |
35 | WRInfo(0x8f) is ok CMD 8f WR ff:ff:ff:ff HWPN: 255.226 HWVers: 234.152 APPFVers: 165.53 GPFCode: 158.183 GPFVers:: 249.0 0 |
36 | New CMD ff CH23 00 1234567801 00CF 19 3 FF FFFD74E5 DCA9152A FB6ADBA54AA9ABFD00000000000000000037 0 |
37 | CH3 00 1234567801 0080 10 0 91 67FFFFFF DFFFFFFF FFF7FFFFFFFFFFFFFD 0 |
38 | CH23 00 1234567801 01FF 3F 3 FF FFFFFFFB FFFFF3AC Ill remain 56 |
39 | New CMD ff CH23 00 1234567801 01FF 3F 3 FF FFFFFFFB FFFFF3AC Ill remain 56 |
40 | CH23 00 1234567801 00C0 18 0 91 7FFFFFFF FEFFFFFF FFFFFFD2D6A3AD5AD7FA00000000000000 0 |
41 | CH23 00 1234567801 00C0 18 0 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFDA801B00CDC0F2F8 0 |
42 | New CMD ff CH23 00 1234567801 00C0 18 0 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFDA801B00CDC0F2F8 0 |
43 | CH23 00 1234567801 00C3 18 1 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFFF501C00CDC3EEDE 0 |
44 | New CMD ff CH23 00 1234567801 00C3 18 1 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFFF501C00CDC3EEDE 0 |
45 | CH23 00 1234567801 00C7 18 3 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF6A000900CE8C38A4 0 |
46 | New CMD ff CH23 00 1234567801 00C7 18 3 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF6A000900CE8C38A4 0 |
47 | CH23 00 1234567801 00C0 18 0 89 FFFFFFFF 7EFFFFFF FFFDFFFFFFFFFBFFFFFFD40900CE8C1032 0 |
48 | CH23 00 1234567801 00C1 18 0 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFEA800900CE8C1032 0 |
49 | New CMD ff CH23 00 1234567801 00C1 18 0 FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFEA800900CE8C1032 0 |
50 | CH23 00 1234567801 00FF 1F 3 FF FFFFFFFF FFFFFFFF FFAD94AB0AAACFF60000000000000000002A556B56000000 0 |
51 | New CMD ff CH23 00 1234567801 00FF 1F 3 FF FFFFFFFF FFFFFFFF FFAD94AB0AAACFF60000000000000000002A556B56000000 0 |
52 | CH23 00 1234567801 00C6 18 3 9F FFFFFFFF FFFEFFFF FFFFFFFFFFFFFFFFFFFF401D00CEFA703D 0 |
53 | New CMD 9f CH23 00 1234567801 00C6 18 3 9F FFFFFFFF FFFEFFFF FFFFFFFFFFFFFFFFFFFF401D00CEFA703D 0 |
54 | CH23 00 1234567801 01FF 3F 3 FF FFFFFFFF FFFFFFFF Ill remain 56 |
55 | New CMD ff CH23 00 1234567801 01FF 3F 3 FF FFFFFFFF FFFFFFFF Ill remain 56 |
56 | CH23 00 1234567801 00DF 1B 3 FF FFFFFFFF FD514615 A245A5890A11D3FE0000000000000000002A8A4A 0 |
57 | New CMD ff CH23 00 1234567801 00DF 1B 3 FF FFFFFFFF FD514615 A245A5890A11D3FE0000000000000000002A8A4A 0 |
58 | CH23 00 1234567801 01FF 3F 3 FF FFFFFFFF FFFFFFFF Ill remain 56 |
59 | New CMD ff CH23 00 1234567801 01FF 3F 3 FF FFFFFFFF FFFFFFFF Ill remain 56 |
60 | CH23 00 1234567801 00FE 1F 3 FF FEF7F7FF FFFFDFFF FFFFFFFFFFFFBFFFFBA3000A00CF63A3273FFFFDFF000000 0 |
61 | New CMD ff CH23 00 1234567801 00FE 1F 3 FF FEF7F7FF FFFFDFFF FFFFFFFFFFFFBFFFFBA3000A00CF63A3273FFFFDFF000000 0 |
62 | CH23 00 1234567801 00FF 1F 3 FF FFBFFFFF FFFFF7FF FFFDFFDFFFFFFFFFF770001E00CEEE549A3F4AAC94000000 2 CA72 6B2A 6B2A 39E80 |
63 | New CMD ff CH23 00 1234567801 00FF 1F 3 FF FFBFFFFF FFFFF7FF FFFDFFDFFFFFFFFFF770001E00CEEE549A3F4AAC94000000 0 |
64 | CH23 00 1234567801 00CF 19 3 FF FFFFFFFF F5FFFFFB FFFFFFFFFBFFABFF00000000000000000026 0 |
65 | New CMD ff CH23 00 1234567801 00CF 19 3 FF FFFFFFFF F5FFFFFB FFFFFFFFFBFFABFF00000000000000000026 0 |
66 | CH23 00 1234567801 00C3 18 1 FF FFFFFFFF 7FF7FFFF FFFFDFEFFFFFFDFFFFB5000A00CE7F92CE 0 |
67 | New CMD ff CH23 00 1234567801 00C3 18 1 FF FFFFFFFF 7FF7FFFF FFFFDFEFFFFFFDFFFFB5000A00CE7F92CE 0 |
68 | CH23 00 1234567801 00FF 1F 3 FA CD55D16D 6DBEB652 AF1FA155634594FF4100000000000000002B92DAA8000000 0 |
69 | New CMD fa CH23 00 1234567801 00FF 1F 3 FA CD55D16D 6DBEB652 AF1FA155634594FF4100000000000000002B92DAA8000000 0 |
70 | CH23 00 1234567801 00C2 18 1 8F FDFFDFDF FFFFBFFF FBFFBFEFFFFFFFFFFFFA800A00D066505D 0 |
71 | WRInfo(0x8f) is ok CMD 8f WR ff:ff:bf:ff HWPN: 251.255 HWVers: 191.239 APPFVers: 255.255 GPFCode: 255.255 GPFVers:: 255.20 |
72 | New CMD ff CH23 00 1234567801 00FF 1F 3 FF FFFFFFFF FDFFEFFF 556AA4B53B3A9FFA0110000000000000003BBFA9BE000000 0 |
73 | CH23 00 1234567801 00DF 1B 3 FF FFFFFFFF FFC6D510 8D5A9C84500F6FF80000000000000000003D4A75 0 |
74 | New CMD ff CH23 00 1234567801 00DF 1B 3 FF FFFFFFFF FFC6D510 8D5A9C84500F6FF80000000000000000003D4A75 0 |
75 | CH23 00 1234567801 01FF 3F 3 FF FF504144 8500A452 Ill remain 56 |
76 | New CMD ff CH23 00 1234567801 01FF 3F 3 FF FF504144 8500A452 Ill remain 56 |
Werde bei Gelegenheit wirklich nochmal neue Hardware aufbauen, irgendwie ist das zu wackelig, was ich grade da habe.
Angehängte Dateien:
-
mqtt.JPG
94 KB
Für alle die, die die MQTT-Struktur für SubCMD 11 PowerLimit suchen. Diese muss man selbst anlegen. Ich benutze den IoBroker. Manchmal funktioniert die Umwandlung der Payload in Integer nicht korrekt. Bsp: Eingabe 600 und im WebIF steht dann 60000W.
:
Bearbeitet durch User
Nachtrag zu obigen Post zum Power Limit: Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max Leistung des WR. Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W. Es sollte 50.0% von X MaxWatt lauten. Kann das jemand so bestätigen?
Angehängte Dateien:
-
HM600_Limit_150W.png
51 KB
Ich betreibe einen HM600 z. Z. mit einem Modul. Wenn ich unter 0.5.4 im Setup 150 W Limit einstelle, ist das Limit für das eine Modul 75W. Mit Limit 600 W waren zu diesem Zeitpunkt ca. 230 W für ein Modul möglich.
:
Bearbeitet durch User
Ha F. schrieb: > Nachtrag zu obigen Post zum Power Limit: > > Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max > Leistung des WR. > > Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W. > Es sollte 50.0% von X MaxWatt lauten. > > Kann das jemand so bestätigen? Ich kann das nicht bestätigen. .../devcontrol/0/11 500 >>>bringt bei mir das 500 Watt Limit.
Ha F. schrieb: > Nachtrag zu obigen Post zum Power Limit: > > Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max > Leistung des WR. > > Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W. > Es sollte 50.0% von X MaxWatt lauten. > > Kann das jemand so bestätigen? Ok jetzt ist bei mir das Ergebnis anders wie oben beschrieben. Jetzt regelt der WR mit dem Wert 300 (aus MQTT) auf 300W Ausgangsleistung (+-) Irgendwie war durch vorherige Experimente das Verhalten heute morgen anders. Oder kann man das irgendwie steuern ob Watt oder % Limitierung?
:
Bearbeitet durch User
Hallo, @hubi Habe die letzte Version Deiner SW aufgespielt, funktioniert sehr gut. Da ich aber inzwischen einen weiteren HM-800 habe, frage ich mich, wie man den 2.WR im Setting einbinden kann. Habe die Anzahl der WR auf 2 eingestellt und die Daten für den 2.WR als HM-600 eingegeben. Konnte alles programmieren , aber auf die Channelabfrage kommt keine Antwort. Die Einzelabfrage vom 1.WR und vom 2.WR funktioniert. Bitte um Hilfe. einen guten Tag fritsche
Günter H. schrieb: > Wenn ich unter 0.5.4 im Setup 150 W Limit einstelle, ist das Limit für > das eine Modul 75W. Das kann ich bestätigen, ist bei meinem HM 800 auch so. Leistung pro Eingang = gedrosselte Leistung / 2 Hier wird vermutlich die Gesamtleistung limitiert und intern vom Wechselrichter durch die Anzahl der Eingänge dividiert.
Gerald R. schrieb: > Das kann ich bestätigen, ist bei meinem HM 800 auch so. > Leistung pro Eingang = gedrosselte Leistung / 2 > Hier wird vermutlich die Gesamtleistung limitiert und intern vom > Wechselrichter durch die Anzahl der Eingänge dividiert. Das wäre schon wichtig, ob die Ausgangsleistung oder an den Eingängen begrenzt wird. Mein Plan mit Ost-West Ausrichtung bräuchte eine Begrenzung der Ausgangsleistung. Wenn die Westsonne kräftig scheint, möchte ich bis 600W vom Westen nutzen und nicht maximal 300W vom Westen und nicht vorhandene 300W vom Osten. Kann mich da jemand beruhigen?
Friedhelm E. schrieb: > Konnte alles > programmieren , aber auf die Channelabfrage kommt keine Antwort. Die > Einzelabfrage vom 1.WR und vom 2.WR funktioniert. Bitte um Hilfe. Sorry, das Problem hatte ich schon mal letzte Seite von diesem Thread und dachte es wäre gelöst. Ich hatte das mit einer Simulation versucht zu lösen, 1WR mit 2 setups und dann jeweils simulierte Serials, und das hat auch geklappt. im Moment weiß ich nicht wie ich dir weiterhelfen kann, habe eben nur 1 WR. Ich versuche nochmals das ganze zu simulieren.
Habe jetzt meine Panels bekommen. Ahoy läuft jetzt auf einem RasPi Zero. Auch mein HM-300 antwortet erst nachdem er 30 Minuten aktiv ist. Ab jetzt kann ich gerne mithelfen, für mehr als beta-Test reichen meine Programmierfähigkeiten aber nicht aus.
Klaus H. schrieb: > Gerald R. schrieb: >> Das kann ich bestätigen, ist bei meinem HM 800 auch so. >> Leistung pro Eingang = gedrosselte Leistung / 2 >> Hier wird vermutlich die Gesamtleistung limitiert und intern vom >> Wechselrichter durch die Anzahl der Eingänge dividiert. > Das wäre schon wichtig, ob die Ausgangsleistung oder an den Eingängen > begrenzt wird. Mein Plan mit Ost-West Ausrichtung bräuchte eine > Begrenzung der Ausgangsleistung. Wenn die Westsonne kräftig scheint, > möchte ich bis 600W vom Westen nutzen und nicht maximal 300W vom Westen > und nicht vorhandene 300W vom Osten. > Kann mich da jemand beruhigen? Evlt hilft es: Setup: Version 0.5.4 HM-600 2x 340Wp Ost/West Hab mal Bilder gemacht. Man beachte den Unterschied zwischen 300W und 100W Limit auf den einzelnen Seiten.
:
Bearbeitet durch User
Liest hier eigentlich noch jemand mit von den anderen "MI"-Besitzern? Es müßte ja neben Ziyat T und mir noch ca. eine Handvoll geben, die WR mit "10"-er Seriennummern haben. Die "ino3" von Ziyat T. ist jedenfalls bereits so ausgelegt, dass man neben diversen Zugangsdaten "nur" den WR-Grundtyp passend einstellen muss, also falls jemand das bisher frustriert in die Ecke gelegt hatte: Welcome on board again! Irgendwo hier war zu lesen, dass man unbedingt einen nRF24L01+ benötigen würde. Wenn meine Interpretation von https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners zutreffend ist, müßte eigentlich auch die "neue Generation" (insbesondere nRF52) noch das alte "shockburst"-Protokoll beherrschen, so dass z.B. ein E73-Board von Ebyte ebenfalls als Transceiver genutzt werden könnte. Ein paar der nRF52-Varianten beherrschen übrigens auch ZigBee, so dass man damit ggf. auch eine Art "Universalgateway" basteln könnte, das dann auch die APSystems-WR ansprechen könnte... (Siehe https://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Briefs/nRF52832-product-brief.pdf, Tabelle auf S. 1) Habe gestern übrigens noch etwas gelötet, einen anderen ESP geflasht und das "gute" 100mW-nRF24 mit shield ausgepackt - das halft alles nichts, die empfangenen Packete sind weiter zum großen Teil einfach kaputt. Zwischenzeitlich hätte ich auch eine Theorie anzubieten, warum das so ist: Mein "Testort" befand sich meistens (leicht schräg, aber) _direkt unter der Unterseite_ des MI. Der hat aber keine externe Antenne, also muss das Signal nicht nur durch das Gehäuse, sondern ggf. auch "durch" das ganze sonstige Elektro-Material => nicht optimal. Vermutlich sind die so aufgebaut, dass die auch eher "zur Seite hin" optimiert abstrahlen: Die nRF beherrschen ja auch Mesh, und wenn man (wie in den Prospekten gezeigt) größere Flächen damit abdecken möchte, muss man ggf. eben zwischendurch einen anderen nRF als "Zwischenstation" nutzen. Dazu paßt ja auch, dass man immer zwei Adressen übermittelt bekommt: Die Sender-Adresse und die des "letzten hop" (so kann man das übrigens auch bei MySensors-Repeatern beobachten). Da wir meistens eine direkte Kommunikation sehen entspricht der letzte hop einfach der des Senders. Werde das bei Gelegenheit mal testen, ob ich einen besseren Platz zum längerfristigen Testen finde, jedenfalls waren die Zwischenresultate auf der Terrasse eher besser als direkt unter dem MI. Für's weitere Testen ist eh' der Plan, den Verkehr über ein ausrangiertes MySenors-GW auf Arduino-Nano-Basis zu sniffen und den ESP vor sich hin tuckern zu lassen... (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach den 10-fachen Messwert). Wird aber dauern, bis wieder Zeit ist, das etwas intensiver zu beleuchten (daher auch meine Frage nach weiteren Usern, die ggf. jetzt wieder einsteigen möchten).
:
Bearbeitet durch User
Hallo,
Hubi(Gast) schrieb: 1WR mit 2 setups und dann jeweils simulierte Serials
Habe die setting.h so abgeändert:
#define MAX_ANZ_INV 2
#include "Inverters.h"
#if MAX_ANZ_INV >= 1
#include "HM600.h"
#define WR1_NAME "HM-600"
#define WR1_SERIAL 0x1141xxxxxxxxULL
#define WR1_MEASUREDEF hm600_measureDef
#define WR1_MEASURECALC hm600_measureCalc
#define WR1_FRAGMENTS hm600_fragmentLen
uint16_t WR1_MODULEPEAKS[] = {2, 370, 370};
#endif
// Beispiel für 2. WR
#if MAX_ANZ_INV >= 2
#include "HM600.h"
#define WR2_NAME "HM-600"
#define WR2_SERIAL 0x1141yyyyyyyyULL
#define WR2_MEASUREDEF hm600_measureDef
#define WR2_MEASURECALC hm600_measureCalc
#define WR2_FRAGMENTS hm600_fragmentLen
uint16_t WR2_MODULEPEAKS[] = {2, 370, 370};
#endif
Ich bin mir nicht sicher ob Du das so gemeint hast.
Ist noch eine Eingabe für den 2ten WR notwendig?
Grüße
Fritsche
Friedhelm E. schrieb: > Ich bin mir nicht sicher ob Du das so gemeint hast. > Ist noch eine Eingabe für den 2ten WR notwendig? Eigentlich ist sonst nichts zu machen, wenn du 2xHM600 hast, außer den Namen des 2.WR ändern, damit du unterscheiden kannst. Den Bug habe ich gefunden, warum es mit 2 nicht funzt. Ändere mal in der loop() die Zeile if ((packetBuffer.available() >= totalFragments && packetsComplete()) in if ((packetBuffer.available() >= inverters[aktWR].fragmentCount && packetsComplete()) ab, dann sollte es gehen. Wenigstens bei mir hat das in der Simulation mit 1 WR geklappt. Änderung ist auch in meinem github drin.
Von Ha F. >Setup: >Version 0.5.4 >HM-600 2x 340Wp Ost/West > >Hab mal Bilder gemacht. Man beachte den Unterschied zwischen 300W und >100W Limit auf den einzelnen Seiten. Vielen Dank. Ich bin beruhigt :-) Die Leistungsbegrenzung wirkt auf die Leistung am Ausgang "P_AC", nicht auf die Leistungen der Eingänge "P_DC". Zwar gibt es leichte Unterschiede zwischen der Summe aller P_DC und P_AC. Das kann durch interne Wandlungsverluste, Messfehler oder unterschiedliche Zeitpunkte der Datenabfrage verursacht sein. Das macht mir keine Gedanken.
Jörg R. schrieb: > Irgendwo hier war zu lesen, dass man unbedingt einen nRF24L01+ > benötigen würde. Wenn meine Interpretation von > https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners ich hab beim nordic/devzone auch gelesen: "The nRF52 is capable of 255-byte payloads in both SB and ESB modes" > > Habe gestern übrigens noch etwas gelötet, einen anderen ESP geflasht und > das "gute" 100mW-nRF24 mit shield ausgepackt - das halft alles nichts, > die empfangenen Packete sind weiter zum großen Teil einfach kaputt. > Zwischenzeitlich hätte ich auch eine Theorie anzubieten, warum das so > ist: Mein "Testort" befand sich meistens (leicht schräg, aber) _direkt > unter der Unterseite_ des MI. Der hat aber keine externe Antenne, also > muss das Signal nicht nur durch das Gehäuse, sondern ggf. auch "durch" > das ganze sonstige Elektro-Material => nicht optimal. Vermutlich sind > die so aufgebaut, dass die auch eher "zur Seite hin" optimiert > abstrahlen: ja, kann es bestaetigen, direkt unter MI ist weniger empfang (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach > den 10-fachen Messwert). das habe ich nicht verstanden?
Ziyat T. schrieb: > ich hab beim nordic/devzone auch gelesen: > "The nRF52 is capable of 255-byte payloads in both SB and ESB modes" grins - die Frage ist nur, ob einen das wirklich weiterbringt... Der E73, der hier rumliegt (weil ich erst dachte, "nordic proprietäry wäre vielleicht "Gazelle") ist zwar schön anzusehen, aber vermutlich schwieriger zu handhaben wie ein einfacher nRF24L01+ (wenn man denn keinen fake erwischt!), weil er die (M4?-) MCU gleich mitbringt, dafür aber kein WLAN oä... > ja, kann es bestaetigen, direkt unter MI ist weniger empfang Na dann bin ich mal positiv gespannt, wie das bei meinem nächsten Test-Ort sein wird und ob die "kleinen" (ohne pa etc.) dann doch tauglich/ausreichend sind! Was den Teil der eigentlichen Auswertungen angeht, scheinen wir ja an sich soweit zu sein, dass man (ggf. abgesehen von einem gewissen Restbestand von echten "new CMD"-Funden beim Sniffen) versuchen könnte, den jetzigen Code als "mi-"Bibliotheken in den "ahoy-ESP" einzubinden? Denn wenn was mit passendem CRC empfangen wurde, war auch die Anzeige im Web-Interface soweit ok. Für's sniffen wäre dann der Arduino das Mittel der Wahl. Oder wie siehst du das? Zugegebenermaßen hat das bisherige Starren auf die NRF24_SendRcv.ino (deine V3) einerseits und ahoy/tree/main/tools/esp8266 andererseits bisher nicht dazu geführt, dass das Licht besonders hell geworden wäre. Immerhin gibt es auch bei hmSystem.h drei (anhand der Seriennummer unterschiedene) Klassen von WR. Den Part könnte man also vermutlich recht einfach übernehmen, und auch die Nummernbereiche sollten (lt. der Excel-Seriennummern-Liste) soweit passen, aber dann....?!? Vielleicht möchte doch einer der C++-Cracks hier den Versuch unternehmen nachobenschau - ich teste herzlichst gerne und habe aktuell auch 3x Hardware zur Verfügung (2*D1 mini, 1 Nano)? > (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach >> den 10-fachen Messwert). > das habe ich nicht verstanden? War mir nicht ganz sicher, welche Gründe es gab, unbedingt den MQTT-Teil abzuschalten und hatte dann vermutet, dass du darüber vielleicht die Leistungsvorgabe machst, was dann eben meinen MI unnötig ausgebremst hätte (weil ich da den laufenden Messwert reingeschubst habe). Daher der Gedanke, den sicherheitshalber (ohne weitere Code-Analyse) ausreichend hoch zu setzen, ohne auf "Aktualität" in der Web-Anzeige verzichten zu müssen.
Jörg R. schrieb: > den jetzigen Code als "mi-"Bibliotheken in den "ahoy-ESP" einzubinden? das ist wiederum nicht so ganz einfach, zuerst müssen die parser (tx/rx) angepasst werden, weil bei den MI's, 2 verschiedene (MI300/600 und MI1000/1500) völlig andere tx/rx msgs sind. da müsste grundsaetzlich im ahoy-esp etwas geschehen und der adressat ist mmn "isnoahoy" Stefan. den rest könnten wir schon noch reinkriegen. (edit: muss sagen, dass ich die letzte version von ahoy-esp nicht angeschaut habe) > >> (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach >>> den 10-fachen Messwert). >> das habe ich nicht verstanden? > War mir nicht ganz sicher, welche Gründe es gab, unbedingt den MQTT-Teil > abzuschalten und hatte dann vermutet, dass du darüber vielleicht die du kannst mqtt laufen lassen, wenn ZEROEXP=0 ist, wird die topic "ImpExpW" nicht mehr abonniert, also keine limitierung über mqtt/gridmeter
:
Bearbeitet durch User
Hallo Ziyat T. und Joerg R, Ja es ist tatsächlich so dass da noch etwas auf Ahoy Seite passieren müsste um die ein/zwei/vier Commands für die MI-300/MI-600/MI-1200 Wechselrichter abzufragen. Aktuell haben wir nur das Gen3 Protokoll mit Single und MultiFrame Antworten implementiert. Die Gen2 Kommandos sind idR alles Single Frame Antworten und somit kann die CRC16 Prüfsumme über mehrere Pakete unterbleiben. Aber wir müssen immer je 1/2/4 Antworten die Pakete häppchenweise in den Strukturen ablegen, das ist etwas anders als bei HM-Wechselrichtern bei denen wir ja immer alle Werte aus der Gesamtpayload ablegen. Wie man das am besten macht bin ich auch ein wenig überfragt, aber macht doch mal einen Anfang in Form einer miInverter.h und miSystem.h etc. Wir müssen wie gesagt auch eine miRadio.h und/oder eine miApp.cpp anlegen da sich hier die Gen2 und Gen3 Protokolle ein wenig üebrlappen / beissen ?? @Lukas und @Andreas S. wir wollen doch auch den Ahoy Code refaktorieren damit er mit OpenDTU gemeinsam genutzt werden kann… wäre das nicht ein erster Schritt: die app.cpp aufräumen und alles was mit Kommunikation mit dem WR an Protokoll/Kommandos da aktuell drin ist wieder auslagern in eine hmGen3.cpp und dann eine miGen2.cpp die vielleicht beide ein ähnliches Interface haben ?
Ich würde mich über Hinweise freuen, was bei mir falsch laufen könnte. Habe den D1 mini laufen, inzwischen produziert der HM-600 auch Strom (blinkt im Sekundentakt grün). Abstand D1 zum WR etwa 5m, was ja eigentlich kein Problem sein dürfte. Im Setup sollte alles stimmen, die SN ist korrekt. Allerdings kann er sich immer noch nicht verbinden: I: Requesting Inverter SN 114172015695 I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 00 05 00 00 00 00 A3 5A AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 00 05 00 00 00 00 A3 5A AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 00 05 00 00 00 00 A3 5A AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 00 05 00 00 00 00 A3 5A AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 00 05 00 00 00 00 A3 5A AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 00 05 00 00 00 00 A3 5A AF I: Inverter #0 I: no Payload received! (retransmits: 5) Ich hatte vorher schon die länger gebaute Antenne dran, hab auch mal D3 und D4 getauscht, alles ohne Erfolg. Hatte die gleiche Situation bereits auf sehr kurzer Distanz, allerdings hing der WR damals noch nicht am Hausnetz. Momentan ist die eher quadratisch gebaute Antenne dran. Danke!!
Wie man (wiederholt) sieht, ist Stefan an Bord *grins*: Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?): https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50 Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als "Objekte" definiert, die dann auch - je nach Modell - intern einfach unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das ganze in diese Richtung angelegt? Wobei auf die Schnelle die einzige Stelle, in der das bei den HM's eine Auswirkung hat die Funktion "getAssignment" zu sein scheint, dort z.B. die Unterscheidung in https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmInverter.h#L203 Vermutlich schließt sich daran noch weiteres in der cpp-File an, aber wie gesagt: Orientieren im Code geht halbwegs, aber dann wird es schnell dünne... Bedeutet, man würde praktisch erst mal so anfangen, dass man statt der hm.*.h's (bzw. cpp-Files) einfach Klone anlegt und die dann an den entsprechenden Stellen anpaßt...? Ufff... Na ja, immerhin könnte man so ggf. dann wenigstens eine fertige firmware (MI-Version) mit "backen" lassen... > du kannst mqtt laufen lassen, wenn ZEROEXP=0 ist, wird die topic > "ImpExpW" nicht mehr abonniert, also keine limitierung über > mqtt/gridmeter ZEROEXP war die ganze Zeit auf 0, aber der ESP wollte den Wert trotzdem - was aber auch völlig egal ist, solange nicht weitere Tester hier an Bord sind. Ich weiß, wie mit dem Thema umzugehen ist, und habe zwischenzeitlich (neben dem "NOMQTT"-Schalter) auch noch eine weitere Code-Stelle ausgemacht, an der man die lästigen Connecting-to-Meldungen ausschalten kann. MQTT könnte übrigens hilfreich sein, um einfach auf diesem Weg "unbekannte CMD"-Messages zu loggen. Z.B. einfach dieses Reading dann in FHEM loggen und gut ist - dann hat das ganze auch gleich einen Zeitstempel...
Jörg R. schrieb: > Wie man (wiederholt) sieht, ist Stefan an Bord *grins*: > > Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?): > https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50 > > Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als > "Objekte" definiert, die dann auch - je nach Modell - intern einfach > unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen > gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden > Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das > ganze in diese Richtung angelegt? es geht in erster linie nicht um das definieren der 2.gen wr, sondern um den mechanismus der single frame 1/2/4 antworten und wie man die mit den 3.gen wr antworten zusammen abarbeitet. gleiches gilt für die request meldungen. wie stefan auch geschrieben hat, da müssen sie zuerst mal "platz schaffen" und ein sw-interface für die 2.gen zur verfügung stellen. > > MQTT könnte übrigens hilfreich sein, um einfach auf diesem Weg > "unbekannte CMD"-Messages zu loggen. Z.B. einfach dieses Reading dann in > FHEM loggen und gut ist - dann hat das ganze auch gleich einen > Zeitstempel... ja sicher könnte man, i.d.regel wenns richtig laeuft sollten keine "unbekannte CMD" kommen
IsnoAhoy schrieb: > Hallo Ziyat T. und Joerg R, > Ja es ist tatsächlich so dass da noch etwas auf Ahoy Seite passieren > müsste um die ein/zwei/vier Commands für die MI-300/MI-600/MI-1200 > Wechselrichter abzufragen. Aktuell haben wir nur das Gen3 Protokoll mit > Single und MultiFrame Antworten implementiert. > Die Gen2 Kommandos sind idR alles Single Frame Antworten und somit kann > die CRC16 Prüfsumme über mehrere Pakete unterbleiben. Aber wir müssen > immer je 1/2/4 Antworten die Pakete häppchenweise in den Strukturen > ablegen, das ist etwas anders als bei HM-Wechselrichtern bei denen wir > ja immer alle Werte aus der Gesamtpayload ablegen. > Wie man das am besten macht bin ich auch ein wenig überfragt, aber macht > doch mal einen Anfang in Form einer miInverter.h und miSystem.h etc. man könnte sich zuerst ein high-level kommunikation interface überlegen, das alle wr-typen verstehen: z.B. get_data,set_data,get_status usw. darunter quasi je einen spez. driver für jedes modell, 2.gen a b c, 3.gen a b c etc.
Hi. Also die Limitierung mit 0.5.4 funktioniert gut. Hat jemand Erfahrung wie oft/schnell der hm mit Befehlen aus mqqt zu recht kommt und ob das Auswirkungen auf die Lebensdauer hat? Ich meine kein Sekundengenaue Limitierung Aber so alle 15/30/45 Sekunden. Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein als der 600), aber verträgt der Inverter häufige Befehle zur Änderung? Echt super Sache bis jetzt und wer nur mitliest sollte es endlich ausprobieren. Ich bereue bis jetzt noch nichts. VG Frank
Frank L. schrieb: > Hi. Also die Limitierung mit 0.5.4 funktioniert gut. Hat jemand > Erfahrung wie oft/schnell der hm mit Befehlen aus mqqt zu recht kommt > und ob das Auswirkungen auf die Lebensdauer hat? > Ich meine kein Sekundengenaue Limitierung Aber so alle 15/30/45 > Sekunden. > Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein > als der 600), aber verträgt der Inverter häufige Befehle zur Änderung? > Echt super Sache bis jetzt und wer nur mitliest sollte es endlich > ausprobieren. Ich bereue bis jetzt noch nichts. > VG Frank - eine zeroexport funktion macht das ja immer - der wr , zumindest die 2.gen wr, reagiert sofort, wenn der wr den mmpt suchen muss dann natürlich es dauert bisschen laenger
Hallo Joachim, Du kannst gerne mal D1/D2 ausprobieren, es gab Hinweise dass es damit klappt. Wenn Du die Pins tauschst dann auch das Setup anpassen. Vielleicht auch zwischenrein mal MQTT abschalten, da es Vermutungen gibt dass PubSubClient uns immer noch in die Suppe spuckt. Optional kann man auch das nRF24L01+ Modul mit einem 10/100uF Elko zwischen VCC & GND Pins des Moduls, ein bißchen besser für die notwendige Sendeleistung des kleinen Funkzwerges kompensieren.
Hallo Jörg & Ziyat T., >> Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?): >> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50 >> >> Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als >> "Objekte" definiert, die dann auch - je nach Modell - intern einfach >> unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen >> gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden >> Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das >> ganze in diese Richtung angelegt? > es geht in erster linie nicht um das definieren der 2.gen wr, sondern um > den mechanismus der single frame 1/2/4 antworten und wie man die mit den > 3.gen wr antworten zusammen abarbeitet. gleiches gilt für die request > meldungen. wie stefan auch geschrieben hat, da müssen sie zuerst mal > "platz schaffen" und ein sw-interface für die 2.gen zur verfügung > stellen. Ja, das habt ihr beide richtig verstanden! Die Implementierung einfach mal in miDefines.h, miInverter.h und miSystem.h vornehmen. Dann für die Anpassungen am Protokoll miRadio.h anpassen. Hierzu müssen m.E. viele Code Teile die aktuell in app.cpp sind (warum eigentlich ?) und für die Abhandlung der einzelnen Kommandos bzw. Erstellung und Parsen der Pakete/Frames notwendig sind hierhin bzw. in hmRadio.h oder eine neue hmProtokoll.h und für Euch in eine miProtokoll.h ausgelagert werden. Ich weiß nicht ob sich Lukas oder Andreas sich hieran beteiligen, den bestehenden Code mal aufzuräumen, aber wenn ihr schon mal die ersten drei miDefines/Inverter/System erstellen könntet, dann geht das andere bestimmt auch noch irgendwann.
Frank L. schrieb: > Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein > als der 600), aber verträgt der Inverter häufige Befehle zur Änderung? Bei mir dauert es schon eine Zeitlang bis der HM1500 reagiert. Ist aber auch schwer nachzuvollziehen, da Ahoy so selten die Werte ausliest und MQTT noch seltener. Machst du die quasi Nulleinspeisung mit einem Blockly auf iobroker?
Hallo, @Hubi(Gast) Habe die neue Version mit den entsprechenden Daten eingegeben und festgestellt das nur der WR1 dargestellt wird. Erst mit Änderung der define Anzahl WR = 2 hat er beide Tabellen ausgegeben. Danke fürs Bearbeiten. Ist schon etwas über eine Leistungsbegrenzung angedacht? Hintergrund: Der 2te.WR soll auf dem 2ten. Eingang eine Akkueinspeisung bekommen, der entweder mit einer Leistungeinstellung im WR oder extern funktioniert. Die externe Strom-/Spannungsbegrenzung funktioniert bereits mit einem E-Bike Akku (36V). Eine WR interne Begrenzung wäre mir lieber. wünsche einen guten Tag fritsche
Stefan T. schrieb: > Hallo Jörg & Ziyat T., > hast du irgend ein klassen-diagram oder ablauf-diagram von ahoy-esp? oder verwendest du irgendein UML-tool? dann könnte ich mal das ganze anschauen..
Hallo. Was sagt eigentlich der Wert "ALARM_MES_ID" in der Ahoy Version 0.5.5 aus?
Ziyat T. schrieb: > auf .....send res 0 ist kein verlass Hmm, irgendwie läßt mich das nicht so ganz los.... Hatte jetzt testweise den Standort etwas verlagert, und ja, die Daten waren etwas besser, aber im Prinzip immer noch grottig. Anscheinend sind die ersten paar Bytes oft noch ok, aber je weiter nach hinten man kommt, desto zufälliger scheint das zu werden. Da es "irgendwie" manchmal klappt, dürfte das ganze kein reines Hardware-Problem sein, sondern irgendwas anderes. Hier mal die Schnippsel, die bei mir in meinem Laien-Verständnis vom Ganzen hängen geblieben sind: - Manche haben in den frühen Sketchen gar kein Channel-Hopping vorgesehen, aber trotzdem Daten bekommen. Am "zufriedensten" scheinen die zu sein, die ein "poor man's channel hopping" machen (hab's nicht nachgeschlagen, was das konkret bedeutet); - die auf den WR vercodeten Channels liegen in dem Bereich, in dem auch 2.4GHz-WLAN rumfunkt (ab 86? wäre in der EU nicht mehr zulässig); - eng nebeneinanderliegende Channels bedeuten Interferenzen; Was wir mit dem MI-Sketch aktuell machen, ist "Dauer-Channel-hopping", "res = 1" kommt keinerlei Bedeutung zu. Das ist m.E. Teil des Problems, jedenfalls, wenn meine graue laienhafte Theoriewelt nicht komplett danebenliegt: - Ein Hardware-ACK (das verbirgt sich hinter der "1") bedeutet doch, dass wir ein starkes Indiz dafür haben, genau den Channel erwischt zu haben, auf dem der WR grade lauscht? - Wenn das so ist, sollten wir erst mal auf diesem Channel bleiben, sowohl, was das Senden wie auch das Empfangen angeht. Das würde die Chance erhöhen, dass der WR mit seinen Infos "durch den Nebel" kommt. Erst, wenn länger nichts sinnvolles kommt, fangen wir an, wieder einen passenden Kanal zu suchen. (Für das ganze Netz, wohlgemerkt, s.U.). Die sehr kurze Gesamtdurchlaufdauer des Ganzen bis zum nächsten Gesamtdurchlauf scheint mir für den 4-Kanaligen ok zu sein, aber eigentlich läge mir eine Logik ala "jeden WR nur alle 5 Sekunden abfragen" näher. Würde bedeuten, dass man den "tickMillis" weniger statisch handhaben sollte: Wenn der WR "durch" ist, könnten es 5 Sekunden sein, wenn der nächste Kanal abzufragen ist, kann man das m.E. eigentlich direkt (im Auswertungscode für die Antwort-Messages?) auf "0" setzen, oder? Werde mal versuchen, den Sketch entsprechend anzupassen, das sollte noch im Bereich meiner Skills liegen. Ach so, vielleicht noch zum gedanklichen Hintergrund des ganzen: An sich sieht ein MI/HM-"Netzwerk" nicht anders aus als das, was man unter https://www.mysensors.org/about/network findet. Sowas funktioniert erwiesenermaßen ganz ordentlich - (@MySensors-nRF) vorausgesetzt, man kann einen statischen Kanal festlegen, auf dem nichts anderes heftig rumfunkt. Nach meinem Verständnis dienen die mehreren festen Kanäle nur dazu, Ausweichmöglichkeiten zu haben, aber das eigentliche "Ziel" des Codes müßte eigentlich sein, sich für alle WR in diesem Netz auf einen Kanal zu einigen (ähnlich zu dem, was für WLAN gilt, nur dass da eben (prinzipiell) mehr Kanäle wählbar sind). Auf diesem teilt dann die DTU die "Sendezeiten" zu, was uU. auch mal bedeuten kann, etwas geduldiger zu warten, bis Nachrichten "aus dem letzten Eck" ihr Ziel erreicht haben. Das findet sich aber m.E. in der MI-Fassung derzeit nicht so recht wieder, das ist mehr auf eine 1:1-Kommunikation angelegt, deren Gelingen wohl auch davon abhängt, dass die äußeren Rahmenbedingungen in etwa gleich sind. Kann aber natürlich sein, dass ich einmal mehr sehr auf dem Holzweg bin...
Rene M. schrieb: > Frank L. schrieb: > >> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein >> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung? > > Bei mir dauert es schon eine Zeitlang bis der HM1500 reagiert. Ist aber > auch schwer nachzuvollziehen, da Ahoy so selten die Werte ausliest und > MQTT noch seltener. > > Machst du die quasi Nulleinspeisung mit einem Blockly auf iobroker? nein über node red auf raspi. Quasi den Zähler im Schrank auslesen mit ir-lesekopf und dann verrechnen und über mqtt und wemos+nrf an die wechselrichter. iobroker hab ich nicht in Gebrauch.
Volker.B. schrieb: > Was sagt eigentlich der Wert "ALARM_MES_ID" in der Ahoy Version 0.5.5 > aus? Diese Frage hatte ich mir auch gestellt - auf Discord (https://discord.com/channels/984173303147155506/992031772328075375/1006955462580781217) bekam ich diese Antwort: drschiffler — gestern um 18:01 Uhr Diese Zahl erhöht sich um 1 wenn eine neue Warnung bzw ein neuer Alarm hinzukommt. Welcher Alarm oder welche Warnung kann man noch nicht sehen
Angehängte Dateien:
-
WR1_SN_neu.jpg
230 KB
Hallo, @Hubi(Gast) Habe einen eigenartigen Effekt festgestellt. Die Original SNr. werden abwechselnd mit der 1141 72600000 bei der Ausgabe auf dem Handy angezeigt, sowohl bei WR1 als auch WR2. Die Daten im Ausgabefeld veändern sich nicht. Soweit mein Testlauf. einen guten Tag, fritsche
Stefan T. schrieb: > Stefan Hallo Stefan, einen ganz großen Dank für Deinen Tipp, der war mir irgendwo auf den letzten Seiten wohl entgangen. Kurz: mit meinem D1 mini pro funktioniert die Antenne nur mit D1/D2 (CE/IRQ), nicht aber mit D3/D4. Muss ich weiter nicht verstehen, aber ich freue mich sehr, dass es endlich klappt! Großes Lob an alle (Mit-)Entwickler, ein klasse Projekt!
Hallo , erstmal vielen Dank das ihr eine so tolle Arbeit kostenlos zur Verfügung stellt . Ich bin begeistert . Ich hoffe meine Fragen passen hier rein . Ich habe einen HM 1200 auf 600w über das setup limitiert . Meine Frage ist , wie oft aktualisiert ahoy diesen Wert und überschreibt diesen im wr ? Gibt es einen Wert mit dem man den wr wieder auf max limitieren kann ? Also wie auf Werkseinstellung. Ihr seid da so hinterher mit den Verbesserungen und bug fix dass kaum nach kommt . Danke
@MI-Mitleser: Das mit dem "Beharren" auf einem Channel scheint jedenfalls besser zu funktionieren, bin ganz begeistert. Sogar mit dem "kleinen" nRF klappt es, die Daten zu empfangen, in minicom ist das Verhältnis Sende- zu Emfangszeilen sogar mit diesem Modul (HIGH-Sendelevel, CRC an (!)) gefühlt bei 4:1, mit dem geshieldeten (LOW) sogar 1:1 - und das am vermeintlich funktechnisch schlechtesten Ort... Aus irgendeinem Grund hopt das Ding immer noch sendseitig (kommt das aus der hm-lib?) und den Status sieht man auch nicht (die "3"), vermutlich habe ich versehentlich was abgeschaltet, das das anfragt? Aber als Zwischenergebnis dürfte es trotzdem interessant sein grins. Hier noch ein paar Zeilen aus minicom (mit dem "kleinen"):
1 | Send... CH61 0960100013785634120062.....send res 0 |
2 | Send... CH75 116010001378563412007A.....send res 0 |
3 | Send... CH03 0960100013785634120062.....send res 0 |
4 | Send... CH23 116010001378563412007A.....send res 0 |
5 | Send... CH40 0960100013785634120062.....send res 0 |
6 | CH3 00 1234567801 00C2 18 1 89 60100013 60100013 013200180936138503170891017FF88FCA 1 |
7 | CH: 3 PV0 MI: 157W Grd:1480W Lm: 0W 79.1W 30.6V 2.4A 2193Wh 235.8ACV 50.0Hz 38.3C S:0 |
8 | Send... CH61 116010001378563412007A.....send res 0 |
9 | Send... CH75 0960100013785634120062.....send res 0 |
10 | Send... CH03 116010001378563412007A.....send res 0 |
11 | Send... CH23 0960100013785634120062.....send res 0 |
12 | Send... CH40 116010001378563412007A.....send res 0 |
13 | CH3 00 1234567801 00C2 18 1 91 60100013 60100013 013200180938138502DE08B6017D034E92 1 |
14 | CH: 3 PV1 MI: 152W Grd:1480W Lm: 0W 73.4W 30.6V 2.4A 2230Wh 236.0ACV 50.0Hz 38.1C S:0 |
15 | Send... CH61 0960100013785634120062.....send res 0 |
16 | Send... CH75 116010001378563412007A.....send res 0 |
17 | Send... CH03 0960100013785634120062.....send res 0 |
18 | Send... CH23 116010001378563412007A.....send res 0 |
19 | Send... CH40 0960100013785634120062.....send res 0 |
20 | CH3 00 1234567801 00C2 18 1 89 60100013 60100013 013200170938138502E30891017E0D062A 1 |
21 | CH: 3 PV0 MI: 147W Grd:1480W Lm: 0W 73.9W 30.6V 2.3A 2193Wh 236.0ACV 50.0Hz 38.2C S:0 |
22 | Send... CH61 116010001378563412007A.....send res 0 |
23 | Send... CH75 0960100013785634120062.....send res 0 |
24 | Send... CH03 116010001378563412007A.....send res 0 |
25 | Send... CH23 0960100013785634120062.....send res 0 |
26 | Send... CH40 116010001378563412007A.....send res 0 |
27 | CH3 00 1234567801 00C2 18 1 91 60100013 60100013 013100170938138502BB08B6017D6A3144 1 |
28 | CH: 3 PV1 MI: 143W Grd:1480W Lm: 0W 69.9W 30.5V 2.3A 2230Wh 236.0ACV 50.0Hz 38.1C S:0 |
29 | Send... CH61 0960100013785634120062.....send res 0 |
30 | Send... CH75 116010001378563412007A.....send res 0 |
31 | Send... CH03 0960100013785634120062.....send res 0 |
32 | Send... CH23 116010001378563412007A.....send res 0 |
33 | Send... CH40 0960100013785634120062.....send res 0 |
34 | CH3 00 1234567801 00C2 18 1 89 60100013 60100013 013200170936138402C00892017E22CDB4 1 |
35 | CH: 3 PV0 MI: 140W Grd:1480W Lm: 0W 70.4W 30.6V 2.3A 2194Wh 235.8ACV 50.0Hz 38.2C S:0 |
36 | Send... CH61 116010001378563412007A.....send res 0 |
37 | Send... CH75 0960100013785634120062.....send res 0 |
38 | Send... CH03 116010001378563412007A.....send res 0 |
39 | Send... CH23 0960100013785634120062.....send res 0 |
40 | Send... CH40 116010001378563412007A.....send res 0 |
41 | CH3 00 1234567801 00C2 18 1 91 60100013 60100013 013200170936138302B908B6017E607A81 1 |
42 | CH: 3 PV1 MI: 140W Grd:1480W Lm: 0W 69.7W 30.6V 2.3A 2230Wh 235.8ACV 50.0Hz 38.2C S:0 |
43 | Send... CH61 0960100013785634120062.....send res 0 |
44 | Send... CH75 116010001378563412007A.....send res 0 |
45 | Send... CH03 0960100013785634120062.....send res 0 |
46 | Send... CH23 116010001378563412007A.....send res 0 |
47 | Send... CH40 0960100013785634120062.....send res 0 |
48 | CH3 00 1234567801 00C4 18 2 89 60100013 60100013 013200180935138302BF0892017E569B95 1 |
49 | CH: 3 PV0 MI: 140W Grd:1480W Lm: 0W 70.3W 30.6V 2.4A 2194Wh 235.7ACV 50.0Hz 38.2C S:0 |
50 | Send... CH61 116010001378563412007A.....send res 0 |
51 | Send... CH75 0960100013785634120062.....send res 0 |
52 | Send... CH03 116010001378563412007A.....send res 0 |
53 | Send... CH23 0960100013785634120062.....send res 0 |
54 | Send... CH40 116010001378563412007A.....send res 0 |
55 | Send... CH61 0960100013785634120062.....send res 0 |
56 | Send... CH75 116010001378563412007A.....send res 0 |
57 | Send... CH03 0960100013785634120062.....send res 0 |
58 | Send... CH23 116010001378563412007A.....send res 0 |
59 | Send... CH40 0960100013785634120062.....send res 0 |
60 | CH3 00 1234567801 00C2 18 1 89 60100013 60100013 0133001A0935138502DE0892017E32DDD6 1 |
61 | CH: 3 PV0 MI: 143W Grd:1480W Lm: 0W 73.4W 30.7V 2.6A 2194Wh 235.7ACV 50.0Hz 38.2C S:0 |
62 | Send... CH61 116010001378563412007A.....send res 0 |
63 | Send... CH75 0960100013785634120062.....send res 0 |
64 | Send... CH03 116010001378563412007A.....send res 0 |
65 | Send... CH23 0960100013785634120062.....send res 0 |
66 | Send... CH40 116010001378563412007A.....send res 0 |
67 | CH3 00 1234567801 00C2 18 1 91 60100013 60100013 013300190936138502F908B7017C2A02F5 1 |
68 | CH: 3 PV1 MI: 149W Grd:1480W Lm: 0W 76.1W 30.7V 2.5A 2231Wh 235.8ACV 50.0Hz 38.0C S:0 |
69 | Send... CH61 0960100013785634120062.....send res 0 |
:
Bearbeitet durch User
Limitierung über mqtt Ich habe heute noch ein wenig rum probiert wie eine "Nulleinspeisung" über mqtt funktionieren könnte. Ergebnis: scheint zu viel traffic zu sein. Meine 2 WR (600 und 1500) reagieren nur sporadisch. Das "kleben" des Limits (Limit 6000W statt 600) ist immer noch drin bei v0.5.6. Manuelles setzen über mqtt geht gut (mit warten von ca. 1 min). Nachdem jedoch die automatische Datenflut über mqtt erfolgt ist, hilft meist nur ein reboot über ahoy. Mal schauen wie es weiter geht... heute wird es erst mal "dunkel" bei mir.
Boah, jetzt scheinen die sich auf Kanal 61 geeinigt zu haben, und da geht es nur noch so ab in der Kommunikation zu dem MI... Aber nur noch 89/91-Messages. Kann es sein, dass man die 88/92 extra bestellen muss? (An einen anderen Channel dafür mag ich nicht so recht glauben, oder braucht man den doch?). Update der ino anbei. (EDIT *2) Mit etwas millis() in der Debug-Ausgabe (CRC-Check ausgeschaltet)...
1 | 360453 Send... CH61 360454116010001378563412007A.....send res 0 |
2 | CH61 00 1234567801 00C2 18 1 89 60100013 60100013 012600070930138700D508D801595915A0 1 |
3 | 360490 CH:61 PV0 MI: 42W Grd: 300W Lm: 0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 |
4 | CH:61 PV0 MI: 42W Grd: 300W Lm: 0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 |
5 | CH61 00 1234567801 00C2 18 1 89 60100013 60100013 012600070930138700D508D801595915A0 1 |
6 | 360510 CH:61 PV0 MI: 42W Grd: 300W Lm: 0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 |
7 | CH:61 PV0 MI: 42W Grd: 300W Lm: 0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 |
8 | CH61 00 1234567801 00C2 18 1 89 60100013 60100013 012600070930138700D508D801595915A0 1 |
9 | 360534 CH:61 PV0 MI: 42W Grd: 300W Lm: 0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 |
10 | CH:61 PV0 MI: 42W Grd: 300W Lm: 0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 |
11 | 360549 Send... CH61 3605510960100013785634120062.....send res 0 |
12 | 365549 Send... CH61 365549116010001378563412007A.....send res 0 |
13 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 01240007092F138700DA08FC015876172F 1 |
14 | 365631 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
15 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
16 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 01240007092F138700DA08FC015876172F 1 |
17 | 365651 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
18 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
19 | CH61 00 1234567801 00C2 18 1 91 60105557 6AB48057 036C400F1B6F378F00DA8AFD0B5AF6376F 0 |
20 | 365675 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 87.6V 1639.9A 35581Wh 702.3ACV 142.2Hz 290.6C S:0 |
21 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 87.6V 1639.9A 35581Wh 702.3ACV 142.2Hz 290.6C S:0 |
22 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 01240007092F138700DA08FC015876172F 1 |
23 | 365699 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
24 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
25 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 01240007092F138700DA08FC015876172F 1 |
26 | 365723 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
27 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
28 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 01240007092F138700DA08FC015876172F 1 |
29 | 365747 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
30 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
31 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 01240007092F138700DA08FC015876172F 1 |
32 | 365771 CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
33 | CH:61 PV1 MI: 43W Grd: 300W Lm: 0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 |
:
Bearbeitet durch User
Jörg R. schrieb: > Boah, jetzt scheinen die sich auf Kanal 61 geeinigt zu haben, und da > geht es nur noch so ab in der Kommunikation zu dem MI... > > Aber nur noch 89/91-Messages. Kann es sein, dass man die 88/92 extra > bestellen muss? (An einen anderen Channel dafür mag ich nicht so recht > glauben, oder braucht man den doch?). > moment mal wieso sehe ich das? 360549 Send... CH61 3605510960100013785634120062.....send res 0 das ist die abfrage "cmd36" für MI1500!! das sollete beim MI600 nicht sein! irgendwas stimmt nicht da. also die einigen sich überhaupt nicht für einen kanal, wir senden und empfangen (channel hopping) auf ch {3,23, 40, 61, 75}, wenn der wr z.b. auf 11 beantwortet werden wir nicht erfahren. ich beheaupte schon lange, dass die wr's mit der zeit auf andere kanaele wechseln. ich bin mir nicht sicher, z.b. bei ahoy-esp wird nur auf ch3 empfangen, dann kann es natürlich lange dauern bis etwas kommt. ich denke die 88/92 antworten sind ev. auf einem anderen kanal.
Es ist definitiv nicht auszuschließen, dass ich irgendwas grundlegend verbogen habe. ABER: Ziel der Änderungen in dem Code war es, das channel-Gehopse für die Fälle auszuschalten, in denen was als Antwort zurückkommt. rx-Channel und tx-Channel sollten dabei immer gleich sein. Gesendet wird dabei (in Summe) sehr viel langsamer! Kann man an den millis()-Ausgaben vor den debug-Meldungen ablesen, besser sogar noch, wenn CRC eingeschaltet ist. Was ich sehen kann, ist dass der MI seit ungefähr 2 h immer auf die 898/91-Anfragen unter Kanal 61 antwortet, und das relativ zuverlässig, einzelne Anfragen gehen verloren. Ergo kann es schon sein, dass die anderen Infos unter einem anderen Kanal verfügbar wären, eher glaube ich daran, dass das einfach "Zufallstreffer" auf "unser Gerausche" waren (Fehlinterpretationen der Anfrage-Ziffer, sowas habe ich hier "rückwarts" teilweise auch gesehen...). Die Änderungen im Code sind übrigens überschaubar - ein diff oder der Vergleich in notepad++ würde ggf. helfen zu verstehen, wie meine "Denke" dazu ist. Und bitte immer das Bildchen von MySensors gedanklich mit diesen Modifikationen vergleichen. Ich behaupte, das Gehopse der MI selbst dient wirklich nur dazu, sich auf einen Kanal zu verständigen, und zwar "einen für alle" (!). Wenn HM das mit 03 hinbekommt, ohne dass sich jemand beklagt, gilt dies m.E. umso mehr. Dass man damit eigentlich die ganze Abfragelogik umstellen müßte, ist ein anderes Thema (also irgendwie verwalten, zu was man schon eine Info hat und wo man ggf. nochmal nachhaken müßte etc.). EDIT: Das "es kommt nichts mehr, also wird gehoppt" funktioniert übrigens - es ist Nacht:
1 | 2901299 Send... CH61 29012990960100013785634120062.....send res 0 |
2 | 2906299 Send... CH75 2906299116010001378563412007A.....send res 0 |
3 | 2911299 Send... CH03 29112990960100013785634120062.....send res 0 |
4 | 2916299 Send... CH23 2916299116010001378563412007A.....send res 0 |
5 | 2921299 Send... CH40 29212990960100013785634120062.....send res 0 |
6 | 2926299 Send... CH61 2926299116010001378563412007A.....send res 0 |
7 | 2931299 Send... CH75 29312990960100013785634120062.....send res 0 |
8 | 2936299 Send... CH03 2936299116010001378563412007A.....send res 0 |
Bin mal gespannt, ob und wo die sich morgen finden.
:
Bearbeitet durch User
Jörg R. schrieb: > ABER: Ziel der Änderungen in dem Code war es, das channel-Gehopse für > die Fälle auszuschalten, in denen was als Antwort zurückkommt. > rx-Channel und tx-Channel sollten dabei immer gleich sein. Gesendet wird > dabei (in Summe) sehr viel langsamer! > Kann man an den millis()-Ausgaben vor den debug-Meldungen ablesen, > besser sogar noch, wenn CRC eingeschaltet ist. ok, ich kann deine gedanken folgen. aber wie am anfang dieses projektes "bewiesen" wurde, dass der dtu statistisch meistens auf kanaelen {3,23, 40, 61, 75} sendet, darum haben wir es so gemacht. ich habe für mich durchs sniffen heraus gefunden, dass z.B. mein MI1500 manchmal den ganzen tag nicht auf CH3 antwortet, darum hab ich hopping auch beim rx eingeführt. ich bin mir nicht sicher, ob ein ack immer auf dem gleichen kanal kommt oder kommen muss. aber wieso sendest du den timer mit?? das verstehe ich nicht, so bekommst du doch keine antworten, oder? 2936299 Send... CH03 [2936299]116010001378563412007A 2931299 Send... CH75 [2931299]0960100013785634120062
Hallo, Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne auslesen möchte per Ahoy DTU. Heute kamen alle Teile an, der Az Esp8266 und das Az Antennenmodul. Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich bekomme einfach keine Verbindung zum Wechselrichter? Die Seriennummer geht los mit 1161xxxxx Das Pinout hatte ich mehrfach kontrolliert.
Sebastian schrieb: > Hallo, > > Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne > auslesen möchte per Ahoy DTU. > > Heute kamen alle Teile an, der Az Esp8266 > und das Az Antennenmodul. > > Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich > bekomme einfach keine Verbindung zum Wechselrichter? > > Die Seriennummer geht los mit 1161xxxxx > > Das Pinout hatte ich mehrfach kontrolliert. Wie weit ist Ahoy vom WR entfernt?
Ziyat T. schrieb: > 2936299 Ziyat T. schrieb: > ok, ich kann deine gedanken folgen. aber wie am anfang dieses projektes > "bewiesen" wurde, dass der dtu statistisch meistens auf kanaelen {3,23, > 40, 61, 75} sendet, darum haben wir es so gemacht. Das ist ja vermutlich auch nicht kompletter Unsinn. Solange keine Antwort zurückkommt, oder wenn da Teilnehmer sind, die bestimmte Frequenzen nicht können, wäre das eine Option. Irgendwo meine ich gelesen zu haben, dass die originale DTU ein paar Bugs hat, und als solchen würde ich es bezeichnen, wenn die das grundlos macht. Bis jedenfalls dato habe ich noch keinen triftigen Grund gefunden für's hoppen, es sei denn, jeder WR hätte "seine" Frequenz... Aber dann müßte es gewisse Zeitbudgets geben, und die Reichweite wäre sehr viel begrenzter wie mit der Mesh-Option, die afaik nur funktioniert, wenn alle beteiligten nRF auf derselben Frequenz funken. > ich habe für mich durchs sniffen heraus gefunden, dass z.B. mein MI1500 > manchmal den ganzen tag nicht auf CH3 antwortet, darum hab ich hopping > auch beim rx eingeführt. > ich bin mir nicht sicher, ob ein ack immer auf dem gleichen kanal kommt > oder kommen muss. Das Hardware-Ack (ganz am Anfang der loop) "kann" gar nicht anders, "des khert so!". Und Es macht m.E. auch keinen Sinn, die Antwort auf eine Anfrage auf einem anderen Kanal zu machen (es sei denn, es gäbe eine explizite Verabredung über Frequenz und timing (!). MAn. viel zu kompliziert...) Bei meinem "guten" nRF hatte ich einige HW-Acks gesehen, beim "kleinen" nicht und auch nicht mehr beim ungeshieldeten. Aber wenn er da ist, ist es m.E. der "Jackpot" - eindeutiger geht es nicht... > aber wieso sendest du den timer mit?? das verstehe ich nicht, so > bekommst du doch keine antworten, oder? > 2936299 Send... CH03 [2936299]116010001378563412007A > 2931299 Send... CH75 [2931299]0960100013785634120062 Falsche (doppelte) Stelle für die Info erwischt, hinter if (DEBUG_TX_DATA){ muss man die eine Zeile auskommentieren, sorry; gesendet wird das nicht. Wenn es gut gemacht ist, müßte es auch einen Code geben, mit der die DTU den WR (allen "zuhörenden" per broadcast?) mitteilt, dass ab demnächst ein anderer Kanal zu verwenden ist, wobei ich bei 5en dann eher immer einen überspringen würde (also Start=23, dann 61, 3, 40, 75, 23). So könnte man auch einen schnellen stabilen nächsten Gesamtzustand erhalten. (Denkt sich jedenfalls der Laie). Bin mal gespannt auf morgen...
:
Bearbeitet durch User
Steffen D. schrieb: > Sebastian schrieb: > >> Hallo, >> Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne >> auslesen möchte per Ahoy DTU. >> Heute kamen alle Teile an, der Az Esp8266 >> und das Az Antennenmodul. >> Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich >> bekomme einfach keine Verbindung zum Wechselrichter? >> Die Seriennummer geht los mit 1161xxxxx >> Das Pinout hatte ich mehrfach kontrolliert. > > Wie weit ist Ahoy vom WR entfernt? Zum testen war ich ganz nahe am Wechselrichter ca 3m entfernt. Die Sonne war schon weg, es lagen vielleicht noch 26 Watt an, damit müsste das Funkmodul doch noch arbeiten im Wechselrichter.
Nachtrag noch: Wie sähe denn die Anfrage nach den Werten aus 88/92 aus? Und in welchem Intervall würde man solche Infos erfragen wollen? Sebastian schrieb: > Die Sonne war schon weg, es lagen vielleicht noch 26 Watt an, damit > müsste das Funkmodul doch noch arbeiten im Wechselrichter. Habe vorhin bei dem MI noch Nachrichten empfangen bei nahe 0 W....
:
Bearbeitet durch User
Jörg R. schrieb: > Nachtrag noch: Wie sähe denn die Anfrage nach den Werten aus 88/92 > aus? Und in welchem Intervall würde man solche Infos erfragen wollen? > Sebastian schrieb: > >> Die Sonne war schon weg, es lagen vielleicht noch 26 Watt an, damit >> müsste das Funkmodul doch noch arbeiten im Wechselrichter. > > Habe vorhin bei dem MI noch Nachrichten empfangen bei nahe 0 W.... Sehr komisch, den ESP hatte ich bestellt https://www.amazon.de/gp/aw/d/B074Q2WM1Y?psc=1&ref=ppx_pop_mob_b_asin_title Das Funkmodul dazu https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title
Sebastian schrieb: > Das Funkmodul dazu > https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise die falsche Ausführung, das muss eines mit "+" sein, also nicht "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise sollte die ganze Schrift klar sein (=früher war "verwaschen" ein Anzeichen für fake chips"). Wie gesagt: Es ist möglicherweise "overdone", aber ich würde immer für "richtige Projekte" (aus vielerlei Gründen) sicherheitshalber zu den "großen geshieldeten Modulen" raten (und ausreichend Power uVa. Kondensator-Kapazität vorschalten!). (Willkürlich gegriffen!) sehen die Dinger so aus: https://www.ebay.de/itm/162822272150. Hat sich auch jetzt wieder gezeigt: So ein Teil + diese hier teilweise abgewerteten Adapterplatinen (ebenfalls willkürlich: https://www.ebay.de/itm/144491901516) haben sich als einigermaßen robust erwiesen, das ist die Kombi (optisch), die Hardware-ACKS ausspuckt...
:
Bearbeitet durch User
...ohne weitere Worte - das log von heute morgen...
Jörg R. schrieb: > Sebastian schrieb: >> Das Funkmodul dazu >> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title > > Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise > die falsche Ausführung, das muss eines mit "+" sein, also nicht > "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es > zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise > sollte die ganze Schrift klar sein (=früher war "verwaschen" ein > Anzeichen für fake chips"). Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".
Jörg R. schrieb: > ...ohne weitere Worte - das log von heute morgen... das sieht ja recht ordentlich aus:-) > Falsche (doppelte) Stelle für die Info erwischt, hinter if > (DEBUG_TX_DATA){ muss man die eine Zeile auskommentieren, sorry; ja, habe auch schon gefunden also, deine überlegungen müsste man schon verfolgen, es sieht ja so aus, wenn sich die beiden auf einen kanal "einigen" laeuft es schon besser. edit:ich schaue mal nach, warum bei dir die status meldungen nicht gehen
:
Bearbeitet durch User
@Jörg R. also wir schicken 0x09/0x11, erwarten 0x91/0x89(data) UND 0x92/0x88(status), es gibt keine sep. status abfrage du hattest ja am anfang diese auch mal gesehen CH3 00 1234567801 0082 10 1 92 60100013 60100013 00[03]00000000913454 1 diese [03] ist status = producing villeicht sind die 0x92/0x88 auf anderem kanal?
Steffen D. schrieb: > Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der > Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ". Komisch, dass ein eher größerer Importeur wie AZDelivery bei der Beschreibung leicht schlampig vorgegangen ist, aber auch die Bilder sind teilweise eindeutig "mit +". Wenn es nicht klappt, ggf. mal den Ping-Pong-Sketch aus der RF24-lib suchen (oder war der von MySensors?). Damit sollte sich feststellen lassen, ob die HW an sich ok ist. Ziyat T. schrieb: > Jörg R. schrieb: >> ...ohne weitere Worte - das log von heute morgen... > > das sieht ja recht ordentlich aus:-) grins Ziyat T. schrieb: > villeicht sind die 0x92/0x88 auf anderem kanal? Habe eine andere Theorie: Man muss nur lange genug ohne Anfrage warten, dann kommen die automatisch! Wenn diese Theorie richtig ist, müßte es ausreichen, nur die 0x08-Anfrage an die MI-600 zu senden (und entsprechend die untere Status-Anfrage an die MI-300 bzw. MI-1xxx). Wir bräuchten also uU. gar keine 0x09/0x11! Mich beschäftigen in diesem Zusammenhang ein paar Fragen: - Warum kamen die "anderen" Messages überhaupt, wenn sie nicht angefragt waren? - warum waren in dem Log mit ausgeschaltetem CRC gestern relativ viele an sich "gute" (gleiche) Messages? - warum empfängt man im reinen sniffer-Modus noch recht lange Daten vom WR, obwohl es keine Anfrage mehr geben dürfte? Daraus ergibt sich für mich folgendes vorläufiges Bild: - Wir brauchen einen gemeinsamen "Nenner", was den Kanal angeht. Steht der mal, haben die WR ein größeres "Beharrungsvermögen" auf diesem Kanal - der MI-600 hat jedenfalls mit einiger Sicherheit da angefangen, wo er abends aufgehört hatte... - Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn es irgendwelchen signifikanten Änderungen gibt; - als "Ping" ist möglicherweise bereits ein (Hardware-!)-ACK für eine beliebige Message des WR ausreichend, in jedem Fall aber eine beliebige Anfrage eines einzelnen Werts aus dem Gesamtpaket. Das mit dem Hardware-ACK deswegen, weil vermutlich das Senden der "immer gleichen Message" dann aufhört, wenn der Sender sein angeforderte ACK gehört hat... Ergo würde ich die Zeit bis zur nächsten aktiven Anfrage mal deutlich verlängern (15-20 Min!), sobald wir eine Antwort vom WR haben (ACK genügt). Weiß nicht, ob das so ist, aber wir sollten mAn. alle Anfragen mit ACK-Anforderung versenden. Weiter könnte es eine gute Idee sein, sich das Routing jedes WR zu merken. Wenn wir "wissen", dass es einen Repeater braucht, müßte man mAn. den direkt anpingen und darum bitten, das weiterzugeben. Auch das müßte eigentlich mit ACK vom _End_-Empfänger gehen. Code dazu müßte (einmal mehr) bei MySensors zu finden sein. Nachtrag: Das mit dem ACK ist übrigens der Grund warum ich davon ausgehe, dass es eine sehr gute Idee ist, dieses Projekt mindestens mit einem Modul mit PA+LNA auszustatten...
:
Bearbeitet durch User
Jörg R. schrieb: > Wenn diese Theorie richtig ist, müßte es ausreichen, nur die > 0x08-Anfrage an die MI-600 zu senden (und entsprechend die untere > Status-Anfrage an die MI-300 bzw. MI-1xxx). Wir bräuchten also uU. gar > keine 0x09/0x11! > du hast mich falsch verstanden, nochmals: es gibt nur die 0x09(PV1)/0x11(PV2) zum abfragen nach der abfrage müssten 0x91/0x89(data) danach 0x92/0x88(status)kommen edit:oder umgekehrt, das wissen wir (noch) nicht es gibt keine sep. status abfrage
:
Bearbeitet durch User
Jörg R. schrieb: > - Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem > vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn > es irgendwelchen signifikanten Änderungen gibt; > - als "Ping" ist möglicherweise bereits ein (Hardware-!)-ACK für eine > beliebige Message des WR ausreichend, in jedem Fall aber eine beliebige > Anfrage eines einzelnen Werts aus dem Gesamtpaket. Das mit dem > Hardware-ACK deswegen, weil vermutlich das Senden der "immer gleichen > Message" dann aufhört, wenn der Sender sein angeforderte ACK gehört > hat... bisher kann ich das für den MI1500 nicht bestaetigen, beim sniffen der DT-Pro/MI1500, tut der WR einfach mal den kanal wechseln, warum auch immer man muss immer daran denken, dass der MI300/MI600 schon einiges aelter sind, und der MI1500 der letzte von 2.gen ist, kann durchaus sein, dass das verhalten auch anderes ist >- Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem > vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn > es irgendwelchen signifikanten Änderungen gibt; der MI1500 hört schnell auf, wenn nichts abgefragt wird edit: hab gerade nachgeschaut, wr sendete etwa 10min lang auf ch61, dann jetzt plötzlich auf ch3
:
Bearbeitet durch User
Ziyat T. schrieb: > du hast mich falsch verstanden, nochmals: > es gibt nur die 0x09(PV1)/0x11(PV2) zum abfragen > > nach der abfrage müssten 0x91/0x89(data) danach > 0x92/0x88(status)kommen > edit:oder umgekehrt, das wissen wir (noch) nicht > > es gibt keine sep. status abfrage Habe offenbar den Mechanismus dann fehlinterpretiert, hatte das hier von neulich im Hinterkopf und daraus geschlossen, dass es evtl. möglich ist, auch die 0x08 als Anfrage zu versenden: Stefan T. schrieb: > Die Antworten haben i.d.R. das erste (höchstwertige) Bit gesetzt: > * Anfrage 0x09 -> Antwort 0x09|0x80=0x89 > * Anfrage 0x11 -> Antwort 0x11|0x80=0x91 > * Anfrage 0x36 -> Antwort 0x36|0x80=0xB6 Ziyat T. schrieb: > bisher kann ich das für den MI1500 nicht bestaetigen, beim sniffen der > DT-Pro/MI1500, tut der WR einfach mal den kanal wechseln, warum auch > immer > > man muss immer daran denken, dass der MI300/MI600 schon einiges aelter > sind, und der MI1500 der letzte von 2.gen ist, kann durchaus sein, dass > das verhalten auch anderes ist > > edit: hab gerade nachgeschaut, wr sendete etwa 10min lang auf ch61, dann > jetzt plötzlich auf ch3 Hmm, sendest du die Anfragen weiter unter allen Channels raus? Bzw. die DT-Pro? Wenn ja, ist das uU. einfach ein bug der DTU. Es kann zwar sein, dass der MI1500 irgendwie speziell ist, aber warum sind die Gen-3-Geräte dann gut erreichbar, wenn man nur ch03 verwendet? (So macht das ahoy, oder?) Wäre nur zu erklären, wenn sich das (neue) Prinzip nicht bewärt hätte. Oder kannst du zwischendurch was sniffen, was nach Aufforderung zum "Kanalwechsel" aussieht? Und kannst du den aktuellen rx-Kanal sehen/sichtbar machen, über den die 0x88/0x92-Infos reinkommen? Wie ist der Zeitstempel im Verhältnis zur zugehörigen "Hauptmessage"? >der MI1500 hört schnell auf, wenn nichts abgefragt wird Unter welchen Rahmenbedingungen hast du das getestet? Mit oder ohne rx-hop? Und was ist "schnell"? (uU. können/müssen wir eben passende Timings konfigurieren). EDIT: ok, das waren in dem Fall 10 Minuten, wenn ich es richtig interpretiert habe.
:
Bearbeitet durch User
Jörg R. schrieb: > Ziyat T. schrieb: > Hmm, sendest du die Anfragen weiter unter allen Channels raus? Bzw. die > DT-Pro? Wenn ja, ist das uU. einfach ein bug der DTU. Es kann zwar sein, > dass der MI1500 irgendwie speziell ist, aber warum sind die Gen-3-Geräte > dann gut erreichbar, wenn man nur ch03 verwendet? weil die 2.gen und 3.gen WRs andere SW haben, in der ein völlig anderer mechanismus implementiert ist, sonst waere ja alles gleich und einfach > Unter welchen Rahmenbedingungen hast du das getestet? Mit oder ohne > rx-hop? sniffer-mode übrigens: wenn wir auf ack warten, dann funktioniert der sniffer nicht, aber das ist egal, andere baustelle edit: ich bau mal die sw um, rxCH=txCH und hopping wenn ein SW-ack kommt, mal schauen
:
Bearbeitet durch User
Ziyat T. schrieb: > weil die 2.gen und 3.gen WRs andere SW haben, in der ein völlig anderer > mechanismus implementiert ist, sonst waere ja alles gleich und einfach Na ja, aus bestimmten Limitierungen der nRF-Hardware kann auch die 3.Gen-firmware nur schlecht raus, das klingt (von sehr weit weg vermutet) irgendwie eher danach, als wäre da halt eine stricktere Abfolge von geringfügig weniger Messages erforderlich. Eigentlich glaube ich, dass das auch für die 2. Gen-Geräte richtig wäre: 1. Paket anfordern, auswerten, gleich das 2. anfordern, dann warten bis 3+4 kommen, alles zusammen auswerfen. Kommt Paket 1 oder 2 nicht: nochmal anfordern, erst beim 3. Mal aufgeben, diesen Teil der Daten nicht ausgeben. > sniffer-mode > > übrigens: wenn wir auf ack warten, dann funktioniert der sniffer nicht, > aber das ist egal, andere baustelle Ähm, fyi: gestern morgen war ich noch der festen Überzeugung, ich hätte die nRF geschrottet, weil ESP1 (im sniffer-Mode!) nichts (!) von dem gesehen hat, was ESP2 gesendet hat, und auch nichts von dem, was der WR vielleicht geantwortet hat. Aber auch ESP2 hat keine Antworten bekommen... > edit: ich bau mal die sw um, rxCH=txCH und hopping wenn ein SW-ack > kommt, mal schauen Bin gespannt. Nachtrag noch zu den Fragen von vorhin: während du für 10 Minuten nichts gesendet hattest - hat da der WR irgendwas zum Status der einzelnen Eingänge von sich gegeben?
:
Bearbeitet durch User
Jörg R. schrieb: > Nachtrag noch zu den Fragen von vorhin: während du für 10 Minuten nichts > gesendet hattest - hat da der WR irgendwas zum Status der einzelnen > Eingänge von sich gegeben? wenn ich max 1 min nichts sende, hört der auf
Steffen D. schrieb: > Jörg R. schrieb: > >> Sebastian schrieb: >> >>> Das Funkmodul dazu >>> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title >> >> Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise >> die falsche Ausführung, das muss eines mit "+" sein, also nicht >> "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es >> zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise >> sollte die ganze Schrift klar sein (=früher war "verwaschen" ein >> Anzeichen für fake chips"). > > Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der > Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ". So ein Update, soweit läuft jetzt alles mit der Hardware. Der Fehler lag daran ohne Kondensator läuft der NRF nicht an. Nun hab ich das Problem das das Webinterface nach einiger Zeit nicht mehr erreichbar ist bzw der ESP arbeitet weiter.
Oha, das ist (gefühlt) kurz... Wenn wir den also "sicher" auf dem aktuellen Kanal halten wollten, müßten wir spätestens nach unter 50 Sekunden anfangen, den anzupingen, soweit so schlecht. Dann sollte die "hopping-Frequenz" unseres Codes irgendwie so versetzt sein, dass wir entweder mind. 5 Minuten warten* (dann wäre er ggf. wieder da?) => 5:30 beginnen, ggf. hinterherzulaufen (oder entgegen?), was umso besser gelingen könnte, wenn wir dann die Reihenfolge wüßten, in die wir ggf. zu gehen haben oder wir müßten nach einem Verbindungsabbruch dann eben wieder relativ schnell durch die Kanäle zappen (1-3 Sekunden?). *Warten wäre ggf. die bessere Variante, wenn wir bereits eine "Herde" haben, die auf Kommandos auf dem betr. Kanal warten. Macht im Moment für's Testen noch keinen Unterschied, aber m.E. sollte man diesen Aspekt im Hinterkopf behalten. Es kann ja Gründe geben, warum einer "unseren Kanal" nicht mehr will (Interferenzen wg. anderem Sender in der Nähe des WR etc.). Dann könnte man den auf dem Fuße folgen und darauf warten, dass der Rest nachkommt. Oder es bekommt eben jeder WR "seine" Frequenz? Na ja, bißchen viel auf einmal, oder? Für's erste müßte es erst mal genügen rauszufinden, ob man dem MI1500 einfach auf einem Kanal halten kann, und wie viele Anfragen es braucht, damit er "alles" sendet. Dto für den MI-600. Kann grade nur sporadisch schauen, aber das sieht plausibel aus, und es gibt bei einem der Kanäle sogar eine "3"-Info... Werde daher vielleicht als erstes die 5 Sekunden aus meiner Fassung des Sketches zu 25 Sekunden ausweiten?
@Sebastian versuche ein anderes stärkeres Netzteil. Welche Version hast du genau installiert?
Jörg R. schrieb: > Wenn wir den also "sicher" auf dem aktuellen Kanal halten wollten, > müßten wir spätestens nach unter 50 Sekunden anfangen, den anzupingen, > soweit so schlecht. das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf allen kanaelen, bin ziemlich sicher.
Ziyat T. schrieb: > das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf > allen kanaelen, bin ziemlich sicher. Es irritiert mir zwar immer noch, aber du wirst das mit deinen Erfahrungen besser wissen. Es erscheint mir nicht logisch, effektiv >80% der Zeit "blind" zu fliegen und dabei zu behaupten, dass man auch größere Netze überwachen könnte (so hatte ich das im Hinterkopf als Inhalt eines Werbefilmchens von denen mal abgespeichert). Vielleicht ist es ähnlich wie bei manchen von diesen Temperatursensoren, die die Hälfte der Zeit mit der einen Methode senden und die andere mit einer anderen? Also: Hauptinfo auf Kanal 1, Statusinfo auf Kanal 2 (oder 3). Bricht einer weg, wechselt der Hauptkanal auf den anderen, und es wird ein neuer fallback ausgehandelt? Mir fehlt nur grade eine Idee, wie man sowas austesten könnte. Wenn die Theorie aufgeht, dass man auch den MI-1500 auf dem einen Hauptkanal halten kann, wenn man nur regelmäßig genug 0x36-0x39 abfragt (?), müßte es doch gehen, den Regelablauf so zu machen, dass man erst auf dem Hauptkanal die 4 Werte abfragt, und dann auf den übrigen scannt, wobei es Zufall sein mag, dass vorhin der Wechsel im Hauptkanal von 61 nach 03 ging (relativ großer Abstand wie oben bereits theoretisiert). Das ergäbe sowas wie: <20 Sekunden für die 4 Anfragen samt Warten auf Antwort, dann je 2 Durchläufe über die übrigen Kanäle à je knapp 5 Sekunden. Hat man einen Treffer, auf diesem Kanal die restlichen 40 Sekunden lauschen? (Modell für einen WR, klar...). Oder gibt es für sowas bessere, standardisierte Methoden?
Rene M. schrieb: > @Sebastian > versuche ein anderes stärkeres Netzteil. > Welche Version hast du genau installiert? Ahoy 0.5.8 und Netzteile habe ich schon etliche versucht. Sehr komisch, jetzt lief der ESP mal eine Stunde durch und verschwindet.
gibt schon eine neuere ahoy Version. Hast du MQTT aktiviert?
@AHOY Über welche serielle Schnittstelle läuft die Debug Ausgabe beim ESP8266? Über die am USB Anschluß (Darüber versorge ich ihn gerade mit einem Ipad Ladegerät mit 5V)? Ist die immer aktiviert oder im Sourcecode freizuschalten? Wenn wo? Eine ältere Version 3.6 oder so läuft bei mir seit Monaten ohne jedes Problem. Seit ein paar Tagen keine Daten mehr vom HM1500. Ich hoffe so auf aussagekräftige Informationen. Ich sehe das permanent angefragt wird, aber vom HM1500 kommt nichts zurück. Ich hoffe der WR ist nicht nach 6 Monaten schon im "Himmel". Er speist aber noch artig ein. 2-3 Tage vorher sah ich auf einem der 3 Panels plötzlich nur noch ein paar Watt Abgabe.
Jörg R. schrieb: > Ziyat T. schrieb: >> das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf >> allen kanaelen, bin ziemlich sicher. > > > Mir fehlt nur grade eine Idee, wie man sowas austesten könnte. ich habe leider nur 1 esp+nrf aber, wenn du 2 esp+nrf hast, könntest so testen: -ESP1 sendet nur auf einem CH -ESP2 empfaengt alle CH
Ziyat T. schrieb: > wenn du 2 esp+nrf hast, könntest so testen: > -ESP1 sendet nur auf einem CH > -ESP2 empfaengt alle CH Stimmt eigentlich... Frage noch zu dem Mi-1500-Teil des Codes. Es gibt keine separate Auswertung der "Status"-Messages? Diese Infos sind bei diesem Typ Teil der "normalen" Messages aus 0x36-0x39, oder ist mir was rausgegangen? Und wenn das so ist: wieso bist du dir sicher, dass die nicht (z.B.) per 0x08-Anfrage gesondert abzurufen wären? Die gesendeten Daten aus einem MI-600 hatte ja bis zu diesem Punkt noch keiner von uns hier gesehen, oder?
:
Bearbeitet durch User
@Jörg R. kannst du bitte diese variante mal testen?
Jörg R. schrieb: > Ziyat T. schrieb: >> wenn du 2 esp+nrf hast, könntest so testen: >> -ESP1 sendet nur auf einem CH >> -ESP2 empfaengt alle CH > Stimmt eigentlich... > > Frage noch zu dem Mi-1500-Teil des Codes. Es gibt keine separate > Auswertung der "Status"-Messages? Diese Infos sind bei diesem Typ Teil > der "normalen" Messages aus 0x36-0x39, oder ist mir was rausgegangen? ja > Und wenn das so ist: wieso bist du dir sicher, dass die nicht (z.B.) per > 0x08-Anfrage gesondert abzurufen wären? ich kenne keine 0x08-anfrage für MI > Die gesendeten Daten aus einem > MI-600 hatte ja bis zu diesem Punkt noch keiner von uns hier gesehen, > oder? du hattest ja auch mal gesehen CH3 00 1234567801 0082 10 1 92 60100013 60100013 00[03]00000000913454 1 diese [03] ist status = producing
Hallo, ich habe zwei Hm-400. Gestern habe ich mir mal die Ahoy version 0.5.4 geflasht und das erste mal getestet. Funkverbindung über ca 25m ging auf anhieb. nur hatte ich vergessen das ich bei Produktion der 2 WR die 0Watt in der Setup Seite auf 400 ändere. Seitdem produziert einer der 2 WR nicht mehr. Gibts irgendein reset befehlt? Das er wirklich nicht mehr produziert sehe ich an den SDM120, also stimmt die Anzeige in der Ahoy Software.
Sebastian schrieb: > Rene M. schrieb: > >> @Sebastian >> versuche ein anderes stärkeres Netzteil. >> Welche Version hast du genau installiert? > > Ahoy 0.5.8 und Netzteile habe ich schon etliche versucht. Sehr komisch, > jetzt lief der ESP mal eine Stunde durch und verschwindet. So gibt es wieder ein Update, ein 2. Kondensator hat geholfen am 5 V Anschluss vom ESP, bis jetzt läuft er stabil.
Hallo Leute,
das ist eine völlig neue Umgebung für mich.
Ich fühle mich verloren.
Gibt es eine etwas detailliertere Step By Step Anweisung um das Projket
zu importieren, erfolgreich zu compilieren, als auch auch zu flashen
(denke das geht direkt aus Visual Studio Code heraus?), als diese hier:?
Ich benötige Hilfe, Danke
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This code can be compiled using Visual Studio Code and PlatformIO Addon.
The settings were:
Board: Generic ESP8266 Module
Flash-Size: 1MB (FS: none, OTA: 502kB)
Install libraries (not included in the Arduino IDE 1.8.19):
Time Arduino Time library (TimeLib.h)
RF24 Optimized high speed nRF24L01+ driver class documentation
PubSubClient A client library for MQTT messaging. By Nick
O'Leary
ArduinoJson Arduino Json library
:
Bearbeitet durch User
Marki schrieb: > Funkverbindung über ca 25m ging auf > anhieb. Bei mir geht nicht mal 50 cm stabil. Kannst Du bitte mal schreiben welchen ESP und welchen NRF24 du genau verwendest (am besten mit Produktlink). Ob Du Kondensatoren verbaut hast. Besonderheiten. Etc. Danke!
Ziyat T. schrieb: > du hattest ja auch mal gesehen > CH3 00 1234567801 0082 10 1 92 60100013 60100013 00[03]00000000913454 1 > diese [03] ist status = producing Soweit ist es klar, der WR meldet das übrigens jetzt grade auch auf beiden Kanälen, die hinteren beiden Felder sind (vermutlich unverändert) jeweils auf 0. Die (für mich noch nicht ganz geklärte) Frage ist ja gerade, warum die mit dem "Gerausche" eher häufiger zu sehen gewesen waren - dafür aber mit "kaputtem Beiwerk", und jetzt so selten. Komme auf die Schnelle auf zwei Varianten: Entweder haben wir den WR verwirrt und er hat eben "kaputte Messages" als (undokumentierte...) Aufforderung akzeptiert, oder es gab zwischendurch einen Kanalwechsel, bei dem dann mehr oder weniger zufällig so eine "reguläre Statusmessage" abgefangen wurde. Beides möglich, vielleicht knödle ich testweise mal ergänzend einen 0x08-Anfrageversuch rein. Wenn ich den Code richtig verstanden habe, müßte man halt statt des "flip-flops" noch eine dritte (bzw. falls das wider Erwarten klappt: und 4.) Variante einbauen. Danke vorab für Code und die Erhellung, was den MI-1500 angeht.
Tobi schrieb: > Marki schrieb: >> Funkverbindung über ca 25m ging auf >> anhieb. > > Bei mir geht nicht mal 50 cm stabil. > > Kannst Du bitte mal schreiben welchen ESP und welchen NRF24 du genau > verwendest (am besten mit Produktlink). Ob Du Kondensatoren verbaut > hast. Besonderheiten. Etc. > > Danke! diese nrf24+ Module https://www.aliexpress.com/item/32719545755.html?spm=a2g0o.order_detail.0.0.598e6368s2llpG und dieses 5er pack https://de.aliexpress.com/item/1005003722134215.html?spm=a2g0o.order_list.0.0.21ef5c5fU9zuSa&gatewayAdapt=glo2deu kein Kondensator, und Netzteil war von einen alten FireTV Stick, glaub das macht so um die 2A. Aber auch an der USB 2 buchse von meinen Thinkpad T430 kommt genug Strom raus. die Funkmodule hatte ich schon im Oktober gekauft bin aber am schlechten bzw dunklen Wetter gescheitert da irgendwas zu machen und als ich jetzt im Sommerurlaub mal schauen wollte bin ich hier über den Beitrag gestolpert und hab mir viel zeit gespart. Ich werde mir auch mal das OpenDTU anschauen, da ich hier einige ESP32 mit Ethnernet und POE habe und dann kann ich auf das WLAN verzichten.
Kann man mit den Erkenntnissen hier einen HM-1500 auf 600 Watt drosseln für den Betrieb als BKW? Oder habt ihr die als Festinstallation laufen?
:
Bearbeitet durch User
hätte die gleiche Frage. Hoymiles 1500 bekommt man noch relativ gut, die Brot und Butter Modelle 300 und 600W sind alle ausverkauft
Drosseln kann man sie, aber vereinfacht anmelden kann man sie nicht.
Jörg R. schrieb: > Beides möglich, vielleicht knödle ich testweise mal ergänzend einen > 0x08-Anfrageversuch rein. Wenn ich den Code richtig verstanden habe, > müßte man halt statt des "flip-flops" noch eine dritte (bzw. falls das > wider Erwarten klappt: und 4.) Variante einbauen. mich nimmt es wunder woher du diese 0x08 hast, die ist im RF_communication_protocol-V6.6.xlsx "Data collection instructions" nicht beschrieben, oder sehe ichs falsch?
Sigi S. schrieb: > das ist eine völlig neue Umgebung für mich. > Ich fühle mich verloren. > > Gibt es eine etwas detailliertere Step By Step Anweisung um das Projket > zu importieren, erfolgreich zu compilieren, als auch auch zu flashen > (denke das geht direkt aus Visual Studio Code heraus?) Mein Vorschlag ist, hier https://github.com/lumapu/ahoy/actions die aktuelle (oberste) bin-Datei herunterzuladen (vorher bei GitHub anmelden) und mit einem (fast beliebigen) Flash-Programm zu flashen. Die weitere Inbetriebnahme ist dann hier https://github.com/lumapu/ahoy/tree/main/tools/esp8266#readme beschrieben. Zukünftige Updates können dann über die Weboberfläche angestoßen werden. Für eine allgemeine Einführung in PlatformIO bitte im Internet nach Tutorials suchen.
:
Bearbeitet durch User
Günter H. schrieb: > Mein Vorschlag ist, hier > > https://github.com/lumapu/ahoy/actions > > die aktuelle (oberste) bin-Datei herunterzuladen (vorher bei GitHub > anmelden) und mit einem (fast beliebigen) Flash-Programm zu flashen. > > Die weitere Inbetriebnahme ist dann hier > > https://github.com/lumapu/ahoy/tree/main/tools/esp8266#readme > > beschrieben. Zukünftige Updates können dann über die Weboberfläche > angestoßen werden. > > Für eine allgemeine Einführung in PlatformIO bitte im Internet nach > Tutorials suchen. Danke, Compilieren in Platformio bekomme ich nun hin, nur flashen geht nicht. Mit Nodemcu flasher geht es. Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500. Ist das nicht mehr nötig? Danke
@Jörg R. hier ist das sniffer log von DTU-Pro und MI1500, wegen der ch-hopping
Angehängte Dateien:
-
058_Setup_Inverter.png
29 KB
Sigi S. schrieb: > Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500. > Ist das nicht mehr nötig? Doch. Siehe Screenshot. Hilfe zum Ausfüllen gibt es auch hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Marki schrieb: > von > > Marki mit der 5.9.10 Marki schrieb: > Hallo, > ich habe zwei Hm-400. Gestern habe ich mir mal die Ahoy version 0.5.4 > geflasht und das erste mal getestet. Funkverbindung über ca 25m ging auf > anhieb. nur hatte ich vergessen das ich bei Produktion der 2 WR die > 0Watt in der Setup Seite auf 400 ändere. Seitdem produziert einer der 2 > WR nicht mehr. > Gibts irgendein reset befehlt? Das er wirklich nicht mehr produziert > sehe ich an den SDM120, also stimmt die Anzeige in der Ahoy Software. 0.5.10 mal getestet und als Limit 400 eingestellt, dann hat der eine WR wieder angefangen zu Produzieren, scheint also in der 0.5.4 ein Bug gewesen zu sein. Wäre es möglich einzubauen, ob die Limitierung überhaupt an den WR geschickt wird? Wenn die regelmäßig da hin geschickt wird, ist das EEPROM bald kaputt, zumindest bin ich mit fast sicher das es keine 5 Jahre halten wird. Ich glaub mal irgendwo in einen Solarforum gelesen zu haben dass die DTU Pro zwei verschiedene Möglichkeiten hat, eine Permanente (zb für die 70% hier in DEU) und eine für die Nulleinspeisung, die wird aber blos ins RAM geschrieben. Auch wenn die Ahoy-DTU nur einmal am Tag das schicken würde wären es schon 365mal in Jahr... Wäre also vielleicht nicht schlecht wenn man die Limitierung vielleicht mit einen Button einmal wegschicken kann oder so?
Achso, wenn ich mehr als 3 WR will, muss ich irgendwo in einer .h die Zahl erhöhen oder?
Marki schrieb: > Ich glaub mal irgendwo in einen Solarforum gelesen zu haben dass die DTU > Pro zwei verschiedene Möglichkeiten hat, eine Permanente (zb für die 70% > hier in DEU) und eine für die Nulleinspeisung, die wird aber blos ins > RAM geschrieben. es gibt keine permanente limit-konstante für den wr, wenn im smiles-cloud z.b. 70% eingestellt wird, schickt dtu diese jeden tag 1x. bei zero-export, es wird dauernd (sie sagen es so, aber leider alle 15min) der smartmeter abgefragt, danach wenn nötig der wr limitiert
Günter H. schrieb: > Sigi S. schrieb: >> Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500. >> Ist das nicht mehr nötig? > > Doch. Siehe Screenshot. > > Hilfe zum Ausfüllen gibt es auch hier: > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" In dem Screenshot steht nichts vom Typ des WR. Das war doch die Frage! Oder erkennt er das über die Seriennummer?
Stimmt, im Screenshot steht nichts vom Typ des WR - der Typ des WR wird über die Seriennummer zugeordnet. Das wird über den verlinkten Screenshot deutlich.
Hallo, ich habe gerade die 0.5.5 installiert. Nach dem Update war im Setup das Power Limit auf 0 --> Alles normal Zum Test auf 300 gesetzt --> WR regelt auf 300 herunter. Beim Versuch das wieder auf 0 zu stellen bleibt der Wert nach dem Reboot auf 300. Ein Wert von 800 wird angenommen. WR: HM-800 Gerade auf 0.5.10. Auch hier wird eine "0" bei "Active Power Limit (W)" nicht angenommen um das Limit zu deaktivieren. Und wie bekomme ich den Power Limit Wert in iobroker?
:
Bearbeitet durch User
Ziyat T. schrieb: > @Jörg R. > kannst du bitte diese variante mal testen? Komme ich vermutlich erst morgen dazu, aber hier noch was interessantes:
1 | 15869 Send... CH61 0960100013785634120062.....send res 0 |
2 | 20769 Send... CH61 116010001378563412007A.....send res 0 |
3 | 20985 CH40 00 1234567801 0082 10 1 92 60100013 60100013 000300000000913454 1 |
4 | ImpExpW Watt 1660.0Watt | All PVs received?:0 |
5 | ImpExpW Watt 1440.0Watt | All PVs received?:0 |
6 | 25669 Send... CH61 0960100013785634120062.....send res 0 |
7 | 25704 CH40 00 1234567801 0082 10 1 88 60100013 60100013 0003000000008BF5C9 1 |
8 | 30569 Send... CH61 116010001378563412007A.....send res 0 |
9 | 30601 CH40 00 1234567801 0080 10 0 92 60100013 60100013 000300000000911590 1 |
10 | ImpExpW Watt 1600.0Watt | All PVs received?:0 |
11 | 35469 Send... CH61 0960100013785634120062.....send res 0 |
12 | ImpExpW Watt 1760.0Watt | All PVs received?:0 |
13 | 40369 Send... CH61 116010001378563412007A.....send res 0 |
14 | ImpExpW Watt 2490.0Watt | All PVs received?:0 |
15 | 45269 Send... CH61 0960100013785634120062.....send res 0 |
16 | ImpExpW Watt 2890.0Watt | All PVs received?:0 |
17 | ImpExpW Watt 2690.0Watt | All PVs received?:0 |
18 | 50169 Send... CH61 116010001378563412007A.....send res 0 |
19 | 55069 Send... CH61 0960100013785634120062.....send res 0 |
20 | 55101 CH40 00 1234567801 0080 10 0 88 60100013 60100013 0003000000008BD40D 1 |
21 | ImpExpW Watt 2840.0Watt | All PVs received?:0 |
22 | 59969 Send... CH61 116010001378563412007A.....send res 0 |
23 | 60005 CH40 00 1234567801 0082 10 1 92 60100013 60100013 000300000000913454 1 |
24 | ImpExpW Watt 2520.0Watt | All PVs received?:0 |
25 | ImpExpW Watt 2200.0Watt | All PVs received?:0 |
26 | 64869 Send... CH61 0960100013785634120062.....send res 0 |
27 | ImpExpW Watt 2020.0Watt | All PVs received?:0 |
28 | 69769 Send... CH61 116010001378563412007A.....send res 0 |
29 | ImpExpW Watt 1620.0Watt | All PVs received?:0 |
30 | 69984 CH40 00 1234567801 0080 10 0 92 60100013 60100013 000300000000911590 1 |
31 | ImpExpW Watt 1390.0Watt | All PVs received?:0 |
32 | 74669 Send... CH61 0960100013785634120062.....send res 0 |
33 | 74703 CH40 00 1234567801 0082 10 1 88 60100013 60100013 0003000000008BF5C9 1 |
34 | 79569 Send... CH61 116010001378563412007A.....send res 0 |
35 | 79602 CH40 00 1234567801 0080 10 0 92 60100013 60100013 000300000000911590 1 |
36 | 84469 Send... CH61 0960100013785634120062.....send res 0 |
37 | 84502 CH40 00 1234567801 0086 10 3 88 60100013 60100013 0003000000008BB641 1 |
38 | ImpExpW Watt 1230.0Watt | All PVs received?:0 |
Sketch dazu (ziemlich wild (!) anbei. Rahmenbedingungen: der andere ESP tuckert munter vor sich hin (seit neulich schon). Die scheinen sich also auf CH61 geeinigt zu haben. Und in der Tat kann man 0x08-Anfragen nicht als solche erfolgreich durchführen. ABER: die 003-er-Antwort kommt soweit ersichtlich immer verlässlich auf CH40. Ergo müßte tatsächlich man einen kurzfristigen Switch zwischendurch einplanen, und zwar vermutlich immer auf den vorherigen (so ist es ja auch im "channel-hop" angelegt). Muss mal bei Gelegenheit die Zeitstempel ansehen, ob man erst nach Erhalt der eigentlich angefragten Info umschalten sollte, oder erst kurz für die 003-er. (falls man die überhaupt braucht. Mit dem Content habe ich mich bisher nicht beschäftigt...). Auf die 11-er-Anfrage sehe ich übrigens auch häufig die Antworten für beide (zeitlich sehr eng beeinander). Es könnte also reichen, nach der 11-er-Anfrage kurz rx umzuschalten (für ca. 300ms?). Kann aber auch Zufall sein, und es sind Antworten auf die Anfragen vom anderen ESP. Für ein "echtes" Durchrollieren sehe ich im Moment jedenfalls keine Veranlassung, und warum die 003-er hin und wieder auch so empfangen werden, wissen vermutlich nur die Wifi-Götter....
Jörg R. schrieb: >> hast du es in FHEM eigentlich noch hinbekommen? > > Es gibt einen ersten attrTemplate-Vorschlag dazu im FHEM-Forum. Bitte > ggf. da anhängen. Danke, das hat prima funktioniert :-) https://forum.fhem.de/index.php/topic,121282.0.html
Carsten B. schrieb: > Danke, das hat prima funktioniert :-) :-) Im svn ist übrigens ein update (kommt dann morgen, wenn man es nicht manuell holt). Das sollte dann ein paar zwischenzeitlich erkannte Problemchen lösen, etwas mehr erläutern und auch für 1- bzw 4-kanalige passen. Ziyat T. schrieb: > @Jörg R. > kannst du bitte diese variante mal testen? läuft grade im Solo-Betrieb seit ca. 20 Minuten. Aber außer Sendeanweisungen und Kanalwechseln war da nichts interessantes an output. Habe dann den "normal-Sketch" von vor ein paar Tagen auf dem anderen ESP wieder angeschaltet. Der findet den WR anscheinend direkt wieder. Dann bekomme ich auch mit diesem Sketch eingehende Nachrichten, aber nur je einmal unter CH23 und CH40, direkt nach dem Kanalwechsel, wobei CH23 dann die 3-Info 88 geliefert hat und CH40 die 3-Info 92 (!)... Bringt dich das irgendwie weiter? Nachtrag: Habe mir jetzt den anderen nochmal per mincom angesehen und die Zeitstempel betrachtet. Danach scheint es so zu sein, dass der WR erst die Statusmessage auf dem unteren Kanal sendet, und dann die weiteren Daten. Ergo müßte man (nur!) nach dem Senden der 09/11-Anfragen auf den vorherigen Kanal umschalten (längstens für 200 ms?), und könnte dann direkt nach dem Empfang der Status-Message wieder auf den "default", um den Rest einzufangen.
:
Bearbeitet durch User
Jörg R. schrieb: >> kannst du bitte diese variante mal testen? > läuft grade im Solo-Betrieb seit ca. 20 Minuten. Aber außer > Sendeanweisungen und Kanalwechseln war da nichts interessantes an > output. NRF24_SendRcvMIesp4.zip laeuft bei mir recht gut, wenn dein setting ok ist dann müsstest du etwas empfangen, oder ist esp+nrf sendet nicht edit: wegen dieser ch beibehalten geschichte: das gefaellt mir nicht, weil wir für solchen probleme, wie bei deinem MI600 data und status pakete, immer andere spez. lösungen haben müssen. es steht für mich fest (wie wir früher auch herausgefunden haben), dass der wr die antworten auf allen ch's schickt, wir müssen halt dann auch schnell ch wechseln
:
Bearbeitet durch User
Hmm, weiß nicht... In den sniff von der DTU habe ich kurz reingeschaut, weiß aber nicht so richtig, wie ich das interpretieren soll. Die sendet Anfragen an den konkreten WR raus und nimmt dabei scheinbar keine Rücksicht darauf, ob/wie sie was empfängt. Ergo geht sie jedenfalls nicht davon aus, dass ein bestimmter Kanal besser wäre wie andere (ch09 kommt allerdings vor, wenn auch selten, k.A., warum). Auf was sie dann hört wissen wir nicht, der Code mit dem "Rücksprung" scheint aber aus dem DTU-Quellcode zu kommen. Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage kommt. Du musst die firmware für die Nutzung iVm. der DTU in jedem Fall so auslegen, dass deren "Gefunke" dir nicht ins Gehege kommt. Nachvollziehbar. Für mich stellt sich die Situation anders dar: Ich habe keine DTU und will "einfach nur" den WR auslesen. Ich brauche auch nicht alle Nase lang aktualisierte Daten, mir würde es reichen, wenn z.B. alle Minute Daten kämen, aber dafür verläßlich. Bedeutet ggf.: wir bilden eine Queue für alle WR, und versuchen dabei. möglichst alle auf einem Kanal zu halten und die Zahl der Umschaltungen dabei gering zu halten. Für alle WR - mit Ausnahme des MI-600 (?) genügt dabei eine Frequenz -ergo bekommt der die niedrigste Prio. Ist die Queue soweit durch, dass der MI-600 dran ist, fangen wir erst die STS-Msg ab, dann möglichst direkt auch die zugehörige Haupt-Info (1x direkt umschalten, dann zurück). Dto. für den 2. Kanal. Sind wir durch, können wir für den Rest der Zeit gerne hopsen. Nach jedem WR senden wir die "geballte Info" für diesen WR raus (Wunsch wäre JSON-encoded (!)), ggf. auch jeweils pro Kanal. Ggf. versuchen wir es ein 2. oder 3. Mal, wenn einer nicht antwortet, aber dann brechen wir ab und versenden, was wir haben (falls wir was haben). Oder habe ich was grundlegend missverstanden? PS: Die Meinungen der anderen hier, die mehr Erfahrung mit der ganzen Sache haben würden mich auch sehr interessieren. Es ist so still...
:
Bearbeitet durch User
Jörg R. schrieb: > Hmm, weiß nicht... > Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem > bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage > kommt. das wissen wir nicht, weil wir nicht gleichzeitig mehrere ch's hören können. wir "beharren" beim hören auf einen kanal, dann sieht es so aus als der wr diesen auch "gut" findet. so wars am anfang, wir hörten nur auf CH3, funktionierte schon, aber langsam, damit hatte ich ein problem und zwar: > Ich habe keine DTU und will "einfach nur" den WR auslesen. Ich brauche > auch nicht alle Nase lang aktualisierte Daten, mir würde es reichen, > wenn z.B. alle Minute Daten kämen, aber dafür verläßlich. ich brauche die zeroexport funktion: da genügt es nicht (mit 4 PVs), irgendwann zu wissen wieviel der wr produziert, ich muss schnell (am besten alle 15 sek) wissen was die pv's bringen. darum bin ich aufs "ch hopsen beim rx" umgestiegen, so habe ich schneller 4 pv's erfassen können. hier darf man nichts ins netz einspeisen, bzw. es wird als bezug v. netz verrechnet, es gibt nur eine art v. zaehler!! ich habe eine DTU-pro; meine erwartung war, ich sage ihr mach die zeroexport mit 0W, und sie macht das. nein, sie kontrolliert eben alle 5-15min, in der zeit, alles was du nichts konsumierst, wird schön eingespeist. dann hat sie auch das problem mit MI1500, weil er nicht unter 150w (10%)limitert werden kann, sie schaltet ihn einfach aus, aber einschalten tut sie erst ab 300W konsum und zwar irgendwann!! (edit:über dieses problem schweigt der hersteller immer noch) darum habe ich pi/python/modbus485, damit limitiere den wr selber, die DTU-pro ist "inaktiv", wird nur als ss zum wr gebraucht.
:
Bearbeitet durch User
Lukas P. schrieb: > Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link > auch jede neuere Version bekommen (ohne Login): > https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip Eigentlich ein sehr schöner Service, leider erscheint inzwischen "Error 404 – Not Found".
nimmt man einfach diesen link, da sind dann immer die aktuellen bins verfügbar https://github.com/grindylow/ahoy/actions
Ist schon klar. Mit dem anderen Link braucht man halt keinen Login bei GitHub.
Ein Log sagt mehr wie viele Worte:
1 | 92388 Send... CH61 116010001378563412007A92389 |
2 | .....send res 0 |
3 | CH40 00 1234567801 0084 10 2 88 60100013 60100013 0003000000008B9785 1 |
4 | CH61 00 1234567801 00C6 18 3 89 60100013 60100013 013F003609551382069500DC01787AFCCF 1 |
5 | 92536 CH:61 PV0 MI: 328W Grd:3230W Lm: 0W 168.5W 31.9V 5.4A 220Wh 238.9ACV 49.9Hz 37.6C S:3 |
Also bei guten Bedingungen ca. 150ms/Abfrage. Auf CH23 sind die 003-er auch zu finden, anzunehmen, dass der WR halt auch kurz braucht, um die angefragten Werte aufzubereiten. Gehe davon aus, dass man für einen Mi-1500 bei halbwegs ordentlichen Bedingungen also keine Sekunde braucht, um ihn komplett auszulesen, und er wirklich DIREKT reagiert, wenn man eine Limitierung versendet. Code dazu ist anbei. Leider wird es mir nicht reichen, eine komplette statemachine für die Abfrage zu bauen, stelle mir sowas in der Art vor:
1 | static bool received[4] = {false};
|
2 | static bool requestOpen = true; |
3 | |
4 | [...] |
5 | if (MI600){ // 2 PVs
|
6 | MIDataCMD=!received[0] ? 0x09 : 0x11; |
7 | |
8 | [...] |
9 | if (MI1500){ // 4 PVs
|
10 | MIDataCMD = 0x0036 |
11 | for (int8_t i = 0; i < 4; i++) {
|
12 | if (!received[i]) {
|
13 | break; |
14 | } |
15 | ++MIDataCMD; |
16 | } |
17 | } |
18 | [...] |
19 | if (received[0] && received[1] && received[2] && received[3]) {
|
20 | tickMillis = millis() + maxTimeForNextPing; //we got a message and will just wait.... |
21 | requestOpen = false; |
22 | } |
23 | |
24 | [...] |
25 | if (p->packet[2] == 0x89) {PV= 0; TotalP[1]=P_DC; pvCnt[0]=1; received[0]=1; }//port 1
|
26 | if (p->packet[2] == 0x91) {PV= 1; TotalP[2]=P_DC; pvCnt[1]=1; received[1]=1; }//port 2
|
Hoffe, es ist erkennbar, wie es gemeint ist.
Hallo zusammen, ich habe seit kurzem einen TSUN TSOL M800(de) und konnte heute relativ problemlos mit einem Raspberry + NRF24L01+ + ahoy Daten vom Wechselrichter empfangen :) Mein Wechselrichter hat die Seriennummer 11418203xxxx > Payload: 00 01 01 49 00 93 01 e2 01 4f 00 3c 00 c9 00 00 25 1e 00 00 18 0b 01 a9 00 a8 09 02 13 86 02 8c 00 01 00 1c 03 e8 01 9f 00 0b 1e 64 > Decoded: temp=41.5, pf=1.0 phase0=voltage:230.6, current:2.8, power:65.2, frequency:49.98 string0=voltage:32.9, current:1.47, power:48.2, total:9.502, daily:425 sring1=voltage:33.5, current:0.6, power:20.1, total:6.155, daily:168 Wie man sieht ist der zweite Strang ungünstig positioniert aber das habe ich schon vermutet und wollte eigentlich nur eine Bestätigung. Jetzt muss ich nur noch schauen wie ich das Richtung Volkszähler oder ähnlichen schön darstellbar hinbekomme. Danke, Christian
Angehängte Dateien:
-
Unbenannt.PNG
48 KB
Hallo, ich will demnächst zwei HM-1500 für einen Netzparallelen Akku mit Nulleinspeisung nutzen. Das Projekt scheint ja mittlerweile weit genug zu sein um das umzusetzen. Das ganze soll auf venusOS laufen und so habe ich als ersten Schritt erstmal ein PCB für den Raspberry PI erstellt (siehe Bild). Bei Interesse kann ich gerne ein paar für euch mitbestellen :)
Hi und Gruß in die Runde. Ich verfolge den Thread seit ein paar Tagen, da ich mir ein Balkonkraftwerk installiert habe mit einem TSOL350 Wechselrichter. Ich bin mit Arduino und AVR Mikrokontrollern vertraut und will Mal schauen, ob ich hier was finde, bei dem ich unterstützen kann. Ich hab auch noch einen Webspace mit ein paar freien URLs übrig. Falls das von euch von Interesse wäre, könnte ich euch anbieten, dass man dort z.B. ein Forum einrichtet inkl. Admins von euch. Außerdem kann ich Android Apps erstellen. Vielleicht wäre es ja interessant, dass man sich die Daten der Wechselrichter über einen NRF+ESP aufs Handy anzeigen lassen kann. Einen 3D Drucker zum Drucken von Gehäusen hätte ich ebenfalls. Für den Fall, dass es Mal eine gute Idee für einen all-in-one System gibt. Auf jeden Fall schon Mal danke dafür, dass ihr so ein Projekt aufgezogen habt aus einer so einfachen Frage, die im ersten Beitrag steht.
Dirk M. schrieb: > Vielleicht wäre es ja > interessant, dass man sich die Daten der Wechselrichter über einen > NRF+ESP aufs Handy anzeigen lassen kann. Vielleicht solltest Du dich etwas genauer mit der bestehenden Lösung auseinandersetzen? ;-)
Nach dem ich auf 0.5.12 aktualisiert habe, waren wieder alle Einstellungen weg. Sogar im ESP musste zunächst das Netzwerk eingerichtet werden. Es ist als 3. Inverter einer fest eingetragen, der sich löschen lässt, aber nach reboot wieder da ist. Mqtt Intervall steht auf 0(read only. Sonst läuft es bis jetzt besser als die 0.5.10. Kann mir jemand sagen, was die minimalen Limitierungen für den hm-600 und hm-1500 sind? Oder kann ich beide auf 0 setzen über Mqtt? Ich schon öfters von min 10% gelesen ???
Frank L. schrieb: > Kann mir jemand sagen, was die minimalen Limitierungen für den hm-600 > und hm-1500 sind? Hallo, in der Hoymiles-Doku finde ich dazu: Percentage 2~100 for HM series 10~100 for MI series Wenn ich über das Webinterface das Limit bei meinem HM600 setze, komme ich bei einem Wert von 10 auf etwa 60W Ausgangsleistung. Kann es sein, dass die Werte jetzt nicht merh absolut in W sind sondern relativ in %? Siehe auch: https://github.com/grindylow/ahoy/issues/154
Ziyat T. schrieb: > Jörg R. schrieb: >> Hmm, weiß nicht... > >> Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem >> bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage >> kommt. > > das wissen wir nicht, weil wir nicht gleichzeitig mehrere ch's hören > können. wir "beharren" beim hören auf einen kanal, dann sieht es so aus > als der wr diesen auch "gut" findet. Hmmm, also: Für den MI-600 (und vermutlich alle älteren) bin ich jetzt ziemlich sicher, dass der die STS-MSGs über Anfrage-Channel (- 1) bzw. (- 2) raushaut, seit der eine ESP den WR auf Kanal 61 festgenagelt hat, hat beides funktioniert. Scheinbar ist (- 1) etwas schneller, unklar ist noch, - ob dann auch auf (- 2) (CH23) was zu sehen wäre; - ob das wechselt (muss das nochmal kritisch beäugen und ggf. auch den Empfangskanal nochmal zwischendurch manipulieren?), und woran es liegt, dass manchmal (?) eine lange Message kommt und manchmal kein "Paar" zu sehen ist, sondern eine einzelne Message - im Moment gehe ich noch von Nebenwirkungen des weiteren ESP's aus... Jedenfalls für den Empfang der "Hauptmessage" darf man den Kanal nicht auf was anderem haben als dem der Anfrage. Damit dürfte zumindest klar sein, warum in den ersten Versionen des Sketches für den MI-600 nur so wenige "Treffer" dabei waren, dabei die 003-er-Messages überwiegt haben und die Timing-Änderung vermeintlich eine Besserung gebracht hat - das ganze war schlicht nicht aufeinander abgestimmt... > so wars am anfang, wir hörten nur auf CH3, funktionierte schon, aber > langsam, damit hatte ich ein problem und zwar: Das Problem kann ich nachvollziehen, wobei ich gerne verstehen würde, wo die Ursache für das Symptom liegt. Wenn es ein starres Verhältnis zwischen Sende- und Empfangskanal gibt (was ich zumindest für die alten WR vor MI-1500 vermute), könnte das schlicht daran gelegen haben, dass - der Sendekanal gewechselt hatte, und/oder - die DTU (schneller) was empfangen hat und dann der WR aufgehört hat zu senden (HW-ACK-Auswertung) > da genügt es nicht (mit 4 PVs), irgendwann zu wissen wieviel der wr > produziert, ich muss schnell (am besten alle 15 sek) wissen was die pv's > bringen. darum bin ich aufs "ch hopsen beim rx" umgestiegen, so habe ich > schneller 4 pv's erfassen können. Wie gesagt: wenn der wirklich auf einem (vorhersagbaren) anderen Kanal zurücksendet als angefragt wird, müßten wir Zeiten deutlich noch unter 15 Sekunden erzielen können! Wir sollten uns m.E. auch beim Rollieren jedenfalls merken, wo der letzte Treffer war und das irgendwie einbauen (zumindest in das DEBUG). Das "Problem" der jetzigen ino ist m.E. noch, dass wir keinerlei Prüfung haben, ob die Daten noch aktuell sind. Einmal bei dem MI-600 alle Kanäle empfangen ergibt "alle PV's sind da", und zwar soweit erkennbar auch noch am nächsten Tag usw.... In diesem Zusammenhang bin ich dann noch über diesen Beitrag gestolpert: Stefan T. schrieb: > Hallo Zusammen, > > der RECV_CHANNEL 0x61 ist m.W. der mit dem er loslegt. Es wurde bei > ersten Tests herausgefunden, dass bei TX auf Kanal 0x61 die nächste > Antwort auf Kanal 0x03 relativ gut empfange wurde, d.h. zwei Kanäle > Unterschied. Ob das am Timing zwischen Senden und Empfangsbereitschaft > des Ahoy DTU Codes ist, oder etwas anderes weiß ich nicht. Alles in allen wird mir nun auch klar, warum wir mit der "Hopserei" und deren Notwendigkeit so aneinander vorbei geredet haben und/oder es User gibt, die teils über sehr lange Synchronisierungszeiten klagen: Alles vor MI-1500 tickt an der Stelle wohl wirklich komplett anders - und ich sehe auch keinen großen Sinn darin, den Code-Ablauf groß anders zu gestalten wie "Merke dir den aktuellen Sende-Channel, hau reichtzeitig Anfragen drüber. Schalte nach dem Senden direkt den Empfangskanal 'zurück' und direkt auch wieder hoch, sobald da was gekommen ist (oder zu lange nichts)". Damit bekommt man ziemlich sicher punktgenau einen aktuellen und konsistenten Satz Infos vom WR. Bleibt die Frage, wie man das ggf. auf den MI-1500 (und später?) übertragen kann, v.a. auch, um die Synchronisierungszeiten zu verbessern... Auch bei den neueren Modellen würde es mAn. Sinn machen, sich den aktuellen "besten Empfangskanal" zu merken (und dann "erst mal" den anzufahren?). Die Frage wäre, ob das auch (-1) bzw. (-2) wäre, und ggf. nach welcher Logik was anderes auszuwählen wäre... Wie arbeitest du denn grade sendeseitig? Ist das auch rollierend oder irgendwie festgezurrt?
Zufälliges Channel hopping eher weniger, wohl ein Algo aus bester Signalstärke pro Channel und gültiger CRC das die DTU auswertet.
Ralla66 schrieb: > Zufälliges Channel hopping eher weniger, wohl ein Algo aus bester > Signalstärke pro Channel und gültiger CRC das die DTU auswertet. Muss darüber nochmal nachdenken, aber zum Thema "Signalstärke" eine kurze Rückfrage: Üblicherweise wird ja sowas als RSSI angegeben. Jetzt ist mir aus der MySensors-nRF-Ecke noch im Ohr, dass das die nRF-Chips nicht unterstützen und man bei MySensors daher auf die entsprechende Debug-Anfrage auch "nur" sowas bekommt wie einen Pseudo-RSSI (wie auch immer der gebildet wurde). Als Indikator würde ich sehen: - Zahl der Retry's, bis ein Hardware-Ack kommt (da muss afaik der CRC passen) - ob überhaupt eines kommt - (zuletzt) -- Zeit, bis eine Antwort kommt (je kürzer, desto besser) -- Verhältnis der Messages mit gültigem CRC / Gesamtzahl von einer Gegenstelle (kann sein, dass das die MySensors-Lösung ist). -- das ganze ggf. unter Berücksichtigung der Frage, wie starkt ggf. der Anfragende (ESP) sowie die Gegenseite ausgelastet ist (Zusammenstellen von Daten). Oder kennt ihr noch weitere Indikatoren? Habe wg. des Frequenz-Wechsel-Themas nochmal das sniffer-log aus Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" angesehen. Danach sieht das so aus, als würden zumindest manche der Anfragen auch noch innerhalb dieses Zykluses auf derselben Frequenz beantwortet - warum auch immer das grade dann da so ist (mir fehlen irgendwie da Zeitstempel-Infos, und was z.b. (27/0/0) bedeuten soll, müßte ich auch erst mal nachlesen). Das sieht jedenfalls nicht unbedingt danach aus, als müßte man bei dem MI-1500 die Sende- und Empfangsfrequenz entkoppeln, und auch die "fehlenden" Antworten aus diesem Zyklus kommen dann in den folgenden Nachrichten auf dem nächsten Kanal? Folgt das der Logik: Wenn du eine erhaltene Anfrage nicht mehr zustellen kannst, speichere sie und sende das dann auf dem nächsten Kanal? (Weil die DTU weitergezogen ist?).
Signalstärke wäre ja wichtig, wo wenig Signal oder gar keins da liegt ja nahe das die Daten falsch sind oder nicht vorhanden.Gefiltert nach den 20 Signalstärksten wäre gut. Danach diese 20 gefilterten auf gültige CRC prüfen. Die besten 8 abspeichern. Danach wieder von vorne. Ich lese mal das Datasheet vom NRF, das muß doch gehen mit der Signalstärke, Krücke würde ja reichen.
Anbei eine weitere Iteration des Sketches für MI-xxx - "nicht zum Verzehr geeignet" (da ist noch ein größerer Bug drin, aber die ersten paar Ausgaben bis zum unbeabsichtigten "Dauerfeuer" sind trotzdem sehr aufschlussreich)...
1 | CH40 00 1234567801 0086 10 3 88 60100013 60100013 0003000000008BB641 1 |
2 | 24382 CH:40: MI300/MI600 status message |
3 | CH61 00 1234567801 00C0 18 0 89 60100013 60100013 0143000C091A1380018E057E00F645D490 1 |
4 | 24430 CH:61 PV0 MI: 39W Grd: 730W Lm: 0W 39.8W 32.3V 1.2A 1406Wh 233.0ACV 49.9Hz 24.6C S:3 |
5 | 24433 Send... CH61 116010001378563412007A24438 |
6 | .....send res 0 |
7 | backchannel timed out... |
8 | 24868 Send... CH61 116010001378563412007A24869 |
9 | .....send res 0 |
10 | 25098 Send... CH61 116010001378563412007A25099 |
11 | .....send res 0 |
12 | backchannel timed out... |
13 | 25528 Send... CH61 116010001378563412007A25529 |
14 | .....send res 0 |
15 | CH40 00 1234567801 0082 10 1 92 60100013 60100013 000300000000913454 1 |
16 | 25562 CH:40: MI300/MI600 status message |
17 | 25758 Send... CH61 116010001378563412007A25759 |
18 | .....send res 0 |
19 | 25988 Send... CH61 116010001378563412007A25989 |
20 | .....send res 0 |
21 | CH40 00 1234567801 0084 10 2 92 60100013 60100013 000300000000915618 1 |
22 | 26022 CH:40: MI300/MI600 status message |
23 | CH61 00 1234567801 00C6 18 3 91 60100013 60100013 0142000C09181380018D058100F6A21C02 1 |
24 | 26064 CH:61 PV1 MI: 79W Grd: 730W Lm: 0W 39.7W 32.2V 1.2A 1409Wh 232.8ACV 49.9Hz 24.6C S:3 |
25 | CH61 00 1234567801 00C4 18 2 91 60100013 60100013 0142000C091C1380018F058100F7A5F2C9 1 |
26 | 34519 CH:61 PV1 MI: 79W Grd: 730W Lm: 0W 39.9W 32.2V 1.2A 1409Wh 233.2ACV 49.9Hz 24.7C S:3 |
27 | CH61 00 1234567801 00C6 18 3 89 60100013 60100013 0143000C091E13810190057E00F75FA982 1 |
28 | 39526 CH:61 PV0 MI: 79W Grd: 730W Lm: 0W 40.0W 32.3V 1.2A 1406Wh 233.4ACV 49.9Hz 24.7C S:3 |
29 | CH61 00 1234567801 00C6 18 3 91 60100013 60100013 0142000C091C137B0192058100F7432BAC 1 |
30 | 49616 CH:61 PV1 MI: 80W Grd: 730W Lm: 0W 40.2W 32.2V 1.2A 1409Wh 233.2ACV 49.9Hz 24.7C S:3 |
31 | 50001 Send... CH61 116010001378563412007A50002 |
Zitat: There is an RSSI register in nRF24L01+, the address is 0x09, the 0th bit of this register represents the current channel signal strength. When the received signal strength is less than -60dBm, bit 0 is 0, when it is greater than -60dBm it is 1. Ch die nicht / wenig senden können so gefunden werden, die am meisten senden CRC prüfen.So der Gedanke.
Vielleicht gefunden, warum dann keine Pause mehr war, nachdem der erste "Satz" komplett war...
Jörg R. schrieb: > Vielleicht gefunden, warum dann keine Pause mehr war, nachdem der erste > "Satz" komplett war... Eher nicht, das war jedenfalls nicht alles gewesen. Hatte gestern dann noch lange vor Sonnenuntergang beide ESP abgeklemmt. Einer der Startvorgänge von heute morgen:
1 | SerialIn: 4 Cmd:4 |
2 | 33823 Send... CH23 096010001378563412006233825 |
3 | .....send res 0 |
4 | 34054 Send... CH40 096010001378563412006234055 |
5 | .....send res 0 |
6 | 34284 Send... CH61 096010001378563412006234285 |
7 | .....send res 0 |
8 | 34514 Send... CH75 096010001378563412006234515 |
9 | .....send res 0 |
10 | backchannel timed out... |
11 | 34944 Send... CH03 096010001378563412006234945 |
12 | .....send res 0 |
13 | 35174 Send... CH23 096010001378563412006235175 |
14 | .....send res 0 |
15 | backchannel timed out... |
16 | 35604 Send... CH40 096010001378563412006235605 |
17 | .....send res 0 |
18 | backchannel timed out... |
19 | 36034 Send... CH61 096010001378563412006236035 |
20 | .....send res 0 |
21 | backchannel timed out... |
22 | 36464 Send... CH75 096010001378563412006236465 |
23 | .....send res 0 |
24 | backchannel timed out... |
25 | 36894 Send... CH03 096010001378563412006236895 |
26 | .....send res 0 |
27 | backchannel timed out... |
28 | 37324 Send... CH23 096010001378563412006237325 |
29 | .....send res 0 |
30 | 37554 Send... CH40 096010001378563412006237555 |
31 | .....send res 0 |
32 | CH40 00 1234567801 0084 10 2 88 60100013 60100013 0003000000008B9785 1 |
33 | 37587 CH:40: MI300/MI600 status message |
34 | CH61 00 1234567801 00C6 18 3 89 60100013 60100013 00BA000208FD13860029000000BAC24075 1 |
35 | 37639 CH:61 PV0 MI: 4W Grd: 50W Lm: 0W 4.1W 18.6V 0.2A 0Wh 230.1ACV 50.0Hz 18.6C S:3 |
36 | 37642 Send... CH61 116010001378563412007A37647 |
37 | .....send res 0 |
38 | backchannel timed out... |
39 | 38076 Send... CH61 116010001378563412007A38077 |
40 | .....send res 0 |
41 | backchannel timed out... |
42 | 38506 Send... CH61 116010001378563412007A38507 |
43 | .....send res 0 |
44 | 38736 Send... CH61 116010001378563412007A38737 |
45 | .....send res 0 |
46 | 38966 Send... CH61 116010001378563412007A38967 |
47 | .....send res 0 |
48 | CH40 00 1234567801 0080 10 0 92 60100013 60100013 000300000000911590 1 |
49 | 39000 CH:40: MI300/MI600 status message |
50 | CH61 00 1234567801 00C2 18 1 91 60100013 60100013 00E7000208FE13860030000000BA9D66BA 1 |
51 | 39040 CH:61 PV1 MI: 8W Grd: 50W Lm: 0W 4.8W 23.1V 0.2A 0Wh 230.2ACV 50.0Hz 18.6C S:3 |
0.5.12. #40 super Entwicklung. Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die Produktion fast immer 10watt unter der Limitierung liegt. Hat jemand gleiches beobachtet?
Moin, super Projekt! Was mir hier fehlt, oder ich finde es nicht, ist eine Zusammenstellung aller benötigter Komponeten und Software mit welcher z.B. der ESP gefasht wird! ich hab in der Vergangenheit mit der Arduino Software gearbeitet das denke ich geht hier nicht! Bin kein kompleter Leihe aber ich will halt das meinen WR ans laufen bringen (überwachen)! Eine Schritt für Schritt Anleitung für "Halbdummies" fände ich super! Ansonsten super Arbeit! Grüsse Andreas
Woran kann es liegen dass sich der ESP nicht mit dem WLAN verbinden will und jedes Mal nach einem Neustart die Konfiguration verwirft? Habe immer das neuste Release (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini geflasht. Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen kappt es nicht wirklich und es kommt zu einem Bootloop.
Simon S schrieb: > Woran kann es liegen dass sich der ESP nicht mit dem WLAN > verbinden will > und jedes Mal nach einem Neustart die Konfiguration verwirft? > > Habe immer das neuste Release > (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini > geflasht. > > Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen > kappt es nicht wirklich und es kommt zu einem Bootloop. Wie sieht die Stromversorgung aus? Vom PC aus über USB-Port? Über ein Netzteil? Evlt zu schwach? Auch mal nur den nackten D1 Mini getestet ohne Anbauteile?
Andreas schrieb: > Moin, > super Projekt! > Was mir hier fehlt, oder ich finde es nicht, ist eine Zusammenstellung > aller benötigter Komponeten und Software mit welcher z.B. der ESP > gefasht wird! ich hab in der Vergangenheit mit der Arduino Software > gearbeitet das denke ich geht hier nicht! Bin kein kompleter Leihe aber > ich will halt das meinen WR ans laufen bringen (überwachen)! > Eine Schritt für Schritt Anleitung für "Halbdummies" fände ich super! > > Ansonsten super Arbeit! > > Grüsse > Andreas - für das erste mal flashen zB mit: https://github.com/tasmota/tasmotizer/releases später über OTA: IP/update - das bin-File von hier https://github.com/grindylow/ahoy/actions - danach neu starten, mit dem WLAN des ESP verbinden und im WebIf einrichten.
Das "Gehopse" und manche Zufälligkeiten (warum scheint meiner den Kanal 0x61 so zu mögen?!?) lassen mich nicht so richtig in Ruhe - und siehe da, in https://www.mikrocontroller.net/attachment/559626/Micro-inverse_system_related_product_ID_coding_rules-A3-20190712.docx steht ziemlich am Anfang was interessantes. Es gibt nicht nur Geräte, die explizit als Repeater eingesetzt werden können, sondern für DTU's, Repeater und WR gilt: >The "8~12" bits are the pipeline coding (currently in decimal), the micro-inverter, repeater, and DTU share the same pipeline sequence, which is coded in sequence and must not be repeated, a total of 99999 bits. Hmmm, ist etwas kryptisch, aber es klingt jedenfalls danach, als sei eine bestimmte Kombination der letzten 5 Ziffern der Seriennummern der beteiligten Geräten dafür ausschlaggebend, wann (im Sinne einer Zeitscheibe?) und auf welchem Kanal (?) ein Gerät Nachrichten versendet bzw. empfängt. Eventuell hat hoymiles da auch irgendwann das Konzept dazu geändert? Na ja, wie dem auch sei, in hmDefines.h gibt es z.B. hm1chAssignment[], und danach scheint die Zuordnung bestimmter Infos zu bestimmten Kanälen fest zu sein? Das würde auf den MI-600 nur eingeschränkt passen, wie gesehen wäre es optimal, wenn a) der (aktuell) richtige Sendekanal für den MI bekannt ist, und b) der RX-Kanal noch für kurze Zeit (50-100ms?) auf dem davor liegenden Kanal (?) verbleibt und danach auch auf den aktuellen TX-Kanal umgeschaltet wird. Wie das zeitlich in der app.cpp eingetacktet ist: noch k.A.. Zu den aktuellen Punkten auf der Roadmap: >app.cpp aufräumen und in hmRadio / hmProtokollGen3 auslagern In hmRadio gibt es derzeit die Funktion "sendPacket". Kommt mir aus der "kleinen ino" bekannt vor, stellt aber ihrerseits dann auch den Sende- und Empfangskanal um. Irgendwie müßten wir für den Fall der Koexistenz von verschiedenen Typen dafür sorgen, dass es zusammenpaßt, was da passiert.... Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten Ergebnisse dann in json zu verpacken (gerne optional). Ich werde jetzt erst mal versuchen, eine etwas generalisierte Fassung der "kleinen ino" für MI zu bauen, die man dann ggf. auch als separates Tool anbieten kann? Vielleicht meldet sich ja doch noch jemand, der ein etwas abweichendes setup hat als Ziyat T und ich... Oder bestehen da prinzipielle Einwände?
Ha F. schrieb: > Simon S schrieb: > >> Woran kann es liegen dass sich der ESP nicht mit dem WLAN >> verbinden will >> und jedes Mal nach einem Neustart die Konfiguration verwirft? >> Habe immer das neuste Release >> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini >> geflasht. >> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen >> kappt es nicht wirklich und es kommt zu einem Bootloop. > > Wie sieht die Stromversorgung aus? > Vom PC aus über USB-Port? > Über ein Netzteil? Evlt zu schwach? > Auch mal nur den nackten D1 Mini getestet ohne Anbauteile? Sowohl USB am PC, als auch mit eigenem Netzteil. Sowie mit und ohne Anbauteile. Werde mal das letzte Debug Build flashen und schauen ob ich so mehr Informationen auslesen kann.
> für das erste mal flashen zB mit: > https://github.com/tasmota/tasmotizer/releases > später über OTA: IP/update > das bin-File von hier https://github.com/grindylow/ahoy/actions > danach neu starten, mit dem WLAN des ESP verbinden und im WebIf > einrichten. Genau so hab ich es auch gemacht, doch leider verwirft er bei mir immer die WLAN Konfiguration
Jörg R. schrieb: > Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten > Ergebnisse dann in json zu verpacken (gerne optional). IP/json sollte schon vieles liefern.
Frank L. schrieb: > 0.5.12. #40 super Entwicklung. > Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die > Produktion fast immer 10watt unter der Limitierung liegt. > Hat jemand gleiches beobachtet? Hallo, ich habe mir grade die 5.13 installliert. Da hat sich beim Limit noch ganz vie lgetan (danke an alle für die tolle Weiterentwicklung!). Ich werde morgen (das Wetter scheint ja ok zu werden) ausgiebig mit den Limits testen und berichten. Carsten
Dann müsste ja WRSer in dec 6 77 21 ESP Dtu 4 56 78 ergibt Ch 3 23 40 61 75 wobei ja DTU fest ist und die CH immer ähnlich sind bei HM600.
Carsten B. schrieb: > Frank L. schrieb: >> 0.5.12. #40 super Entwicklung. >> Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die >> Produktion fast immer 10watt unter der Limitierung liegt. >> Hat jemand gleiches beobachtet? > > Hallo, > > ich habe mir grade die 5.13 installliert. Da hat sich beim Limit noch > ganz vie lgetan (danke an alle für die tolle Weiterentwicklung!). > > Ich werde morgen (das Wetter scheint ja ok zu werden) ausgiebig mit den > Limits testen und berichten. > > Carsten Hallo Carsten, danke für die Bereitschaft zu testen. Nimm bitte die Version von hier: https://github.com/aschiffler/ahoy/actions/runs/2869788679 Ist auch 0.5.13 nur hier habe ich noch eine kleine Verbesserung für MQTT einbauen müssen. Nach den Tests -- ca. 2-3 User wollen testen -- werden wir auf dem main dann ein neues Release bereitstellen inklusive pot. fixes. Siehe auch als Anleitung: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md
Simon S schrieb: > Woran kann es liegen dass sich der ESP nicht mit dem WLAN > verbinden will und jedes Mal nach einem Neustart die Konfiguration > verwirft? > Habe immer das neuste Release > (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini > geflasht. > Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen > kappt es nicht wirklich und es kommt zu einem Bootloop. Lag wohl ab einem defekten Wemos D1 mini, hatte noch einen anderen auf dem es jetzt problemlos funktioniert.
Moin, ich habe gerade von 5.10 auf 5.13 ein OTA Update gemacht. Danach hat sich der ESP wieder als AP gemeldet, aber keine Konfigurationsseite geöffnet. Nachdem ich über USB wieder auf 5.10 gewechselt habe lief es sofort wieder im normalen Modus (hat also die WLAN Info im EEPROM gefunden). 5.13 funktioniert auch nicht, wenn ich es über USB einspiele.
:
Bearbeitet durch User
Hfhausen schrieb: > Jörg R. schrieb: >> Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten >> Ergebnisse dann in json zu verpacken (gerne optional). > > IP/json sollte schon vieles liefern. Zum einen spiele ich grade noch mit "der kleinen ino" rum und sehe im Moment nur, was andere User an Topics (automatisch) abbonniert haben. Da war dieser Topic jedenfalls bislang gar nicht zu sehen. Zum anderen war ich etwas unpräzise: Wünschen würde ich mit je getrennte Topics für - den ESP an sich (obiger tree?) - jeden WR (uU. noch getrennt nach AC+jedem DC-Eingang, aber in jedem Fall unter einem Sub-Topic, der dem WR zugeordnet ist) Klasse wäre auch, wenn "signifikante Änderungen" (auf Bestellung?) vor Ablauf der normalen Periode gemeldet würden (Ausfall eines Eingangs oder von AC, Änderungen über z.B. 10% der Leistung oder 15/20W etc. tb. discussed). Ralla66 schrieb: > Dann müsste ja > WRSer in dec 6 77 21 > ESP Dtu 4 56 78 > ergibt Ch 3 23 40 61 75 > wobei ja DTU fest ist und die CH immer ähnlich sind bei HM600. Eine klare Logik kann ich hinter den Zahlen (auch mit meiner WR-Nummer) nicht erkennen. Beim Durchflözen der Rückmeldungen hier ist nur eben auffällig, dass viele sehr zufrieden sind, es bei manchen "ewig" braucht, bis eine Synchronisation da ist und wieder andere anscheinend gar keine Daten bekommen - warum auch immer. Jedenfall habe ich heute nacht mal den WR auch von AC genommen. Damit sollte der "resettet" sein? Dann lief er eine Weile, bevor dann einer meiner Versuchs-Codes "randurfte". Im Ergebnis wollten sich beide dann wieder auf Kanal 0x61 einigen. ABER: zwischendurch kam auch über CH40 eine 0x91-er Message rein. Interessant dabei ist, dass der Code zu diesem Zeitpunkt ausschließlich auf Kanal 0x61 sendete, der WR also vielleicht noch versucht hat, die Status-Messages 0x88 und 0x92 zuzustellen? Und die Daten bereits aufbereitet hatte für den Fall, dass der ESP empfangsbereit ist? (oder meine ausgegebenen Infos irgendwie unsauber sind...) Na ja, wie dem auch sei, werde jetzt auch versuchsweise wieder zu starren Tick-Zeiten zurückgehen und den Empfangskanal "hart" an den Sendekanal binden (-1). Kommt dann die 89 Antwort im Zeithorizont von "senden+200" bis "senden+400" (oder ein HW-Ack), ist das der "richtige Channel" und künftige Sendungen sollten dann (erst mal nur) über diesen Kanal rausgehen - also muss bei "isTime2Send()" zusätzlich noch geprüft werden, ob wir auf der passenden "Zeitscheibe" sind und die bei "bisher Fehlanzeige" dann auch gewechselt werden. Mal schauen.
Die Channels werden ja im Register Map Table Adresse 05 Bit 0 - 6 geschrieben oder gelesen. Könnte mir vorstellen das jede Pipe einen eigenen Channel bekommt für WR bezogene Daten.Eben errechnet aus den Serial IDs der DTU und WR.Dann wäre die Channel Number in den Daten der Pipe zu suchen und zum Senden vermutlich am Anfang gesetzt.
Kennt jemand den mqqt Befehl um das aktuell gesetzte limit auszulesen bzw. wird das gesendet und man kann es über ein subscribe verwenden?
Ralla66 schrieb: > Die Channels werden ja im Register Map Table Adresse 05 Bit 0 - 6 > geschrieben oder gelesen. > Könnte mir vorstellen das jede Pipe einen eigenen Channel bekommt für WR > bezogene Daten.Eben errechnet aus den Serial IDs der DTU und WR.Dann > wäre die Channel Number in den Daten der Pipe zu suchen und zum Senden > vermutlich am Anfang gesetzt. MAn. ist aus WR-Sicht eher die Frage des "optimalen Empfangs" relevant. Ein nRF kann nach meinem laienhaften Verständnis (zu einem bestimmten Zeitpunkt) immer nur - entweder Senden oder Empfangen, und das ganze - immer nur auf genau einem Kanal Da der Aufwand für eine eigene (exakte) Uhr auf jedem WR vermutlich viel zu groß ist, fangen die bei jedem DC-Zyklus (näherungsweise) bei "0" an. Was sie wissen, ist - die eigene Nr. - (vielleicht) den letzten Kanal, auf dem sie angefunkt wurden, und - bestenfalls (!) die ID ihrer Gegenstelle, also (Repeater oder) DTU. Ergo müßte es eigentlich das einfachste sein, die Dinger schlicht auf "ihrem Kanal" auf die Lauer zu legen und auf Signale zu warten. Vielleicht mal Wechseln, wenn zu lange nichts kommt. Das würde dann bedeuten: etwas mehr wie eine Sekunde (=1 DTU-Zyklus?) auf einen anderen Kanal wechseln, dort lauschen, dann wieder zurück, ebenfalls für mind. einen Zyklus, dann wieder den nächsten. Eine eventuelle Antwort dann "rückwärts" auf dem vorherigen Kanal versenden, in der Erwartung, dass die DTU genau dort lauscht, bei "Unzustellbarkeit" dann die Kanäle wechseln (seltsamerweise scheint mein MI noch einen Kanal weiter zurück zu gehen, wenn er die Status-Message nicht an den Mann bringt? Der WR war dann aber nach etwas weniger als 200ms wieder auf dem Hauptkanal, um die Hauptinfo zu versenden). Wenn die Zustellung klappt, wird ggf. die folgende Message (in etwa) "im Takt mit den Kanalwechseln" dann auch versendet? Der "eigene Kanal" bleibt bei Versandproblemen nach dem 1. Zyklus frei, damit der WR hier auf weitere Anweisungen lauschen kann? "Zuzuhören" scheint (!) mein MI jedenfalls mehr oder weniger ausschließlich auf Kanal 0x61... (wenn ich dran denke, wird dieser Kanal mal aus der Liste genommen, mal sehen, ob (und ggf. wie/wo/wann) dann eine Kommunikation zustande kommt; aber erst muss der Code ohne solche Spielereien erst mal so laufen wie gedacht...).
:
Bearbeitet durch User
Angehängte Dateien:
-
iobroker_mqtt.png
9,7 KB
Hallo, erstmal vielen Dank für das coole Projekt! An die iobroker-User unter uns, ich würde gerne das nicht-persistente Powerlimit per MQTT setzen, dazu habe ich den Datenpunkt angelegt (und siehe Bild), nach den Kriterien, wie sieh hier hinterlegt sind: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md "mqtt.0.Ahoy.devcontrol.114172608859.11.0" Leider passiert in Ahoy gar nichts :-( wie habt ihr den Datenpunkt angelegt? Danke schon mal! Marcel
@Marcel du musst auch mqtt.0.Ahoy.devcontrol.0.11 nehmen.
Rene M. schrieb: > @Marcel > du musst auch > mqtt.0.Ahoy.devcontrol.0.11 > nehmen. Hmm, dann ist die Anleitung falsch. Hab es gerade ausprobiert, funktioniert aber leider auch nicht, sondern führt genau wie die andere Variante direkt zu einem reboot. Welche Version hast du denn installiert? Hab die 0.5.14
An Jörg R. Sehe ich ähnlich, aus der Spec vom NRF geht ja hervor das zwischen RX und TX gezielt geschaltet werden kann. Eine gute Verbindung wird ja bei RX in RDP 09 gesetzt. Ein Register für Ch habe ich in der Spec nicht gefunden. Dann wäre die einfachste Variante den CH mit zu senden im ersten Paket bei der Kontaktaufnahme zwischen den Teilnehmern.
Hallo, ich habe 2 neue AZ-Delivery NodeMCU LolinV3 probiert. Prozessor ESP8266MOD, Modell 12-F. Compiliert ohne Fehler mit folgenden Settings: platform = espressif8266 framework = arduino board = esp12f board_build.f_cpu = 80000000L upload_port = COM5 Upload auch ohne Probleme. Leider spannt er kein eigenes WLAN auf. Version ist von letzter Woche. Hat jemand einen Hinweis für mich? Danke Achso auf der Seriellen Schnittstelle empfange ich nur Schmierzeichen mit 115200 Baud
:
Bearbeitet durch User
Sigi S. schrieb: > Hallo, > > ich habe 2 neue AZ-Delivery NodeMCU LolinV3 probiert. > Prozessor ESP8266MOD, Modell 12-F. > > Compiliert ohne Fehler mit folgenden Settings: > > platform = espressif8266 > framework = arduino > board = esp12f > board_build.f_cpu = 80000000L > upload_port = COM5 > > Upload auch ohne Probleme. > > Leider spannt er kein eigenes WLAN auf. > > Version ist von letzter Woche. > > Hat jemand einen Hinweis für mich? > Danke > Achso auf der Seriellen Schnittstelle empfange ich nur Schmierzeichen > mit 115200 Baud Hallo, mit einem NodeMCU Flasher von: This programmer can flash esp8266 by one click. Our website is http://www.nodemcu.com Our Tencent QQ Group:309957875 wird eine FW geflashed und es funktioniert so weit. (Warum tut Platformio als hätte alles geklappt?!) In der neuen GUI sehe ich kein Feld um meinen WR Typ HM1500 einzutragen. Die Hinweise hier im Forum klären das auch nicht eindeutig. Wo muß der Typ eingetragen werden???
Angehängte Dateien:
-
ahoy.jpg
33 KB
@Marcel sollte schon klappen. Sieh dir einmal meinen Screenshot an. Klappt schon seit 0.0.8 oder so.
Angehängte Dateien:
-
HM600-limit-shelly.png
270 KB -
HM600-limit.png
270 KB
Andreas S. schrieb: > Hallo Carsten, > > danke für die Bereitschaft zu testen. > Nimm bitte die Version von hier: > https://github.com/aschiffler/ahoy/actions/runs/2869788679 Hallo, leider hat moch die Arbeit heute etwas mehr in Anspruch genommen, als gedacht. Ich habe nicht mehr geschafft abzudaten, habe aber mit der 5.13 getest, die ich schon dauf hatte. Hat sich alles plausibel verhalten. Habe jeweils über das Webinterface "absolute watt in non-persitant" gesetzt:
1 | gesetzt 10W, WR:13W, shelly:9W |
2 | gesetzt 20W, WR:24W, shelly:19W |
3 | gesetzt 50W, WR:48W, shelly:43W |
4 | gesetzt 100W, WR:103-108W, shelly:98-103W |
5 | gesetzt 150W, WR:152-157W, shelly:152-157W |
6 | gesetzt 200W, WR:201-206W, shelly:201W |
7 | gesetzt 300W, WR:310W max, shelly:max 305W |
8 | gesetzt relativ in procent persistent: 100% WR: max 561W, shelly: max 553W |
Angehängt noch die Graphen aus fhem dazu. Für mich ist das ein sehr ordentliches Ergebnis :-) Gruß Carsten PS: ich hatte mehrere Reboots den Tag über. Mit 5.1 lief es mehrere Tag durch... PPS: ich habe leider keine serielle Console dran, da aus Empfangsgründen die DTU draussen am Gartenhaus hängt. Ich versuche spätestens am Wochende dafür eine Lösung zu finden (2. ESP mit seriell nach ssh o.ä.)
Falls jemand die Daten direkt mit einem RaspberryPi auslesen und an den Volkszähler schicken will: https://github.com/stefan123t/ahoy/pull/3 Ggf. an einigen Stellen noch nicht schön aber funktioniert erstmal so.
number of supported inverters (set to 3 by default) defines.h Ist in defines.h nicht zu finden. Wo dann?
config.h, Zeile 46: // number of configurable inverters #define MAX_NUM_INVERTERS 3
Sigi S. schrieb: > number of supported inverters (set to 3 by default) defines.h > > Ist in defines.h nicht zu finden. > > Wo dann? JA, Danke!!!
Ich muss noch mal nachfragen, wie genau du es machst, weil es bei mir einfach nicht klappen will. Ich nutze den mqtt Adapter (nicht den mqtt-Client, könnte das ein Fehler sein). Ich habe mir analog zu dir diesen Datenpunkt manuell erstellt: mqtt.0.Ahoy.devcontrol.0.11 Die Ordner habe ich als folder deklariert. Gesendet habe ich dann die Werte als string und number, beides ohne Erfolg. Wo kann ich ansetzen?
Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin keine höhere Version zum laufen. Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von 5.10 aus, auch mit komplett gelöschten ESP getestet. Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe funktioniert es wieder.
Dirk S. schrieb: > Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin > keine > höhere Version zum laufen. > > Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene > Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von > 5.10 aus, auch mit komplett gelöschten ESP getestet. > Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich > keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht > übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe > funktioniert es wieder. Ich kann bestätigen, das auch die aktuellen Versionen bei mir einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones…
Marcel S. schrieb: > Ich muss noch mal nachfragen, wie genau du es machst, weil es bei > mir > einfach nicht klappen will. > Ich nutze den mqtt Adapter (nicht den mqtt-Client, könnte das ein Fehler > sein). > Ich habe mir analog zu dir diesen Datenpunkt manuell erstellt: > mqtt.0.Ahoy.devcontrol.0.11 > Die Ordner habe ich als folder deklariert. > Gesendet habe ich dann die Werte als string und number, beides ohne > Erfolg. > Wo kann ich ansetzen? Im Einsatz: 0.5.14 Iobroker mit MQTT-Adapter als Server, allerdings auf Port 1881, da noch ein Sonoff-Adapter läuft. ich schreibe Werte nach (als String): mqtt.0.inverter.devcontrol.0.11 inverter ist das MQTT-Topic aus der Configseite
Sorbit schrieb: > Ich kann bestätigen, das auch die aktuellen Versionen bei mir > einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones… Moin, hast Du die bin von GitHub genommen, oder selbst kompiliert? Wie hast Du sie aufgespielt: - direkt auf leeren ESP geflasht? - OTA von vorheriger Version? - neue Version über vorherige geflasht? Irgendetwas mache ich wohl falsch, aber was kann es bloß sein?
Dirk S. schrieb: > Sorbit schrieb: >> Ich kann bestätigen, das auch die aktuellen Versionen bei mir >> einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones… > > Moin, > > hast Du die bin von GitHub genommen, oder selbst kompiliert? Beides > Wie hast Du sie aufgespielt: > - direkt auf leeren ESP geflasht? Ja > - OTA von vorheriger Version? Auch das > - neue Version über vorherige geflasht? Ja > > Irgendetwas mache ich wohl falsch, aber was kann es bloß sein? Ja, offenbar bei der Anmeldung. Funktioniert die Anmeldung am AP? Welche IP trägst du im Browser ein? Firewall ausschalten, Pop up Blocker ausschalten, verschiedene Browser nutzen, welche Infos siehst Du auf dem COMx Port ( Putty)?
Dirk S. schrieb: > Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin > keine > höhere Version zum laufen. > > Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene > Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von > 5.10 aus, auch mit komplett gelöschten ESP getestet. > Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich > keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht > übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe > funktioniert es wieder. Bei mir ist es mit ahoy so ähnlich. Hatte die 0.4.20 und dann bis Gesten die 0.4.22 ohne Probleme am laufen. Ich habe jetzt die 0.5.14 mit VisualStudio/PlatformIO auf meinen ESP8266EX D1 Mini V3.0.0 (4MB Flash) ohne Fehlermeldung geschrieben. In den Einstellungen bei den 3 Invertern stehen überall die gleichen sinnlosen Einträge. Diese konnte ich ändern und speichern, aber nicht löschen (hab ja nur einen Inverter). Nachdem ich den Knopf Erase Settings (ohne WLAN) gedrückt hatte, waren die Felder leer, aber man konnte keine neuen Daten mehr abspeichern. Ein Factory Reset bringt auch keine Verbesserung. Nachdem ich mit Arduino ein anderes Programm mit Erase all flash geschrieben hatte, konnte ich mit PlatformIO wieder die 0.5.14 drauf schreiben, wlan einstellen und den ersten Inverter mit meiner Seriennummer abspeichern, die beiden anderen Inverter sind dann noch mit sinnlosen Zeichen befüllt, aber die SW funktioniert ansonsten. Irgendwie gibt es wohl ab der Version 0.5.xx ein Problem mit der Formatierung/Partitionierung des Flashlayouts? Oder dem Zugriff auf den Speicherbereiche der Default Werte?
Claus T. schrieb: > Irgendwie gibt es wohl ab der Version 0.5.xx ein Problem mit der > Formatierung/Partitionierung des Flashlayouts? Oder dem Zugriff auf den > Speicherbereiche der Default Werte? Ähnliches bei mir. Habe gerade über OTA auf die 0.5.14 geflasht und die Inverter-Einstellungen werden nicht übernommen. Wenn ich auf Save klicke und die Seite neugeladen hat, sind die Einträge wieder weg. Erase all Settings schafft keine Abhilfe.
Ok, danke. Jetzt geht's. Wie oft setzt du die Begrenzung? Bin dabei einen Grundlastspeicher für die Nacht zu bauen.hast du da schon Erfahrungen, alle wie viele Sekunden man das machen kann?
Jetzt habe ich 0.5.14 zum laufen bekommen. Eigentlich lief er, nur das automatische Anmeldefenster kam nicht. Mit 192.168.x.1 konnte ich es aufrufen und WiFi einstellen. Aber in 0.5.14 werden bei mir auch die Invertereinstellungen nicht gespeichert! Ich konnte aber von 0.5.14 auf 0.5.13 per OTA gehen (dabei blieben die WiFi Einstellungen erhalten) und in der Version übernimmt er die Invertereinstellungen. Die 0.5.14 hat aber z.B. die Einstellung für den NRF24 übernommen, nur die Invertereinstellungen nicht.
Dirk S. schrieb: > Eigentlich lief er, nur das automatische Anmeldefenster kam nicht. Mit > 192.168.x.1 konnte ich es aufrufen und WiFi einstellen. Wie auch sonst? Natürlich mußt Du im Browser eine gültige IP eingeben. Die sieht man doch in den WLAN Settings des AP im Hostsystem (bei mir WIN 11).
Nicht natürlich, die Version 0.5.10 ruft die Anmeldeseite automatisch auf, sobald man sich mit dem AP verbindet. Die nachfolgenden Versionen nicht mehr, daher war nicht klar ob es überhaupt läuft. Ist natürlich ein Anfängerfehler, aber im Nachhinein ist es immer einfach.
Dirk S. schrieb: > Nicht natürlich, die Version 0.5.10 ruft die Anmeldeseite automatisch > auf, sobald man sich mit dem AP verbindet. Interessant, erkläre mal den Mechanismus wenn Dein Endgerät noch mit einem weiteren Netzwerk verbunden ist, wovon ich stark ausgehe. Kenne das nur als "Captive Portal"... Bei mir hat das auch nicht automatisch funktioniert. Daher habe ich in den WLAN Einstellungen das DG gesehen und die IP im Browser eingegeben... Aber das scheint ja nur eine Hürde bis zu den weiteren Problemen zu sein. Das alles funktioniert bei mir einwandfrei. Bei Dir nicht mit gleicher Codebasis. Suche den Fehler, wenn Dein Monitor entspiegelt ist wird es schwer;-)
Angehängte Dateien:
-
ahoy.png
210 KB
Ich verstehe nicht ganz warum Du hier unterschwellig pissig wirst. Warum sollte ich noch mit einem anderen Netzwerk verbunden sein, wenn ich mich mit dem ESP im AccessPoint Modus verbinde? Bei 0.5.10 wurde man automatisch auf die Anmeldeseite (siehe 4.) weitergeleitet, danach nicht mehr. Das ist alles was ich festgestellt habe. Genau wie die Tatsache, dass es mein Fehler war dies nicht zu erkennen. Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die Inverter Einstellungen nicht und das nicht nur bei mir. Ich versuche hier nur etwas als unbedarfter Anwender beizutragen, falls dies nicht erwünscht ist, kann ich mich auch raushalten.
:
Bearbeitet durch User
Dirk S. schrieb: > Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die > Inverter Einstellungen nicht und das nicht nur bei mir. Bei mir schon. Wir halten also fest: Es kann nicht am Code liegen.
Sigi S. schrieb: > Dirk S. schrieb: >> Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die >> Inverter Einstellungen nicht und das nicht nur bei mir. > > Bei mir schon. > Wir halten also fest: > Es kann nicht am Code liegen. Moin, hm... bei ist das gleiche. Die Inverter lassen sich nicht speichern. Und nein mein Monitor ist nicht entspiegelt. Ich habe 2x die gleiche Hardware (NodeMCU+NRF24)
Hallo zusammen Ich habe heute mein Wemos D1 mini mit dem ESP8266 und dem NRL24L01+ bekommen. Ich habe irgendwie den richtigen Link zur Firmeware oder dem Archiv für Platformio noch nicht gefunden. Ich habe einen HM600 bei mir im Einsatz und möchte die Daten am Schluss im Iobroker MQTT haben. Eine weitere Frage: gibt es irgendwo eine Schrittanleitung mit der auch ein nicht Softwarespezialist das ganze zum laufen kriegt? Vielen dank für eure super Arbeit Andi
Andi schrieb: > Hallo zusammen > > Ich habe heute mein Wemos D1 mini mit dem ESP8266 und dem NRL24L01+ > bekommen. Ich habe irgendwie den richtigen Link zur Firmeware oder dem > Archiv für Platformio noch nicht gefunden. > > Ich habe einen HM600 bei mir im Einsatz und möchte die Daten am Schluss > im Iobroker MQTT haben. > > Eine weitere Frage: gibt es irgendwo eine Schrittanleitung mit der auch > ein nicht Softwarespezialist das ganze zum laufen kriegt? > > Vielen dank für eure super Arbeit > Andi Ja schau mal bei GitHub nach. Vorlesen ist nicht
Einfach mal eine Seite zurück blättern und lesen. Irgendwo dazwischen gibt es die Hinweise.
Ist auch nicht notwendig mit Vorlesen, soweit bin ich noch durch die Primarschule gekommen. Aber es gibt da diverse verschiedene Link und Projekte. Als Laie hat ist es etwas sehr schwierig, die Entwickler Infos und die wichtigen Anwender Info zu auseinander zu halten. Aber ich habe schon mal was gefunden, so kann ich das ganze mal anschliessen und schauen.
Hallo allerseits, Ich habe mir eine neue Version meines PCB-Layouts erstellt und diese Platinen fertigen lassen. Dieses Mal für den D1-Mini (ESP8266) als auch für den ESP32-NodeMCU (38 Pin). Somit kann beides mit einer Platine genutzt werden (natürlich nicht gleichzeitig ;-)) Falls Bedarf besteht gebe ich von diesen gerne welche ab. https://www.ebay-kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoy-dtu-esp8266-und-opendtu-projekt/2187289249-168-9361
AHOY, ich habe nun auch die Probleme, das auch in der akktuellen Version, keine Werte gespeichert werden. Bei Inverter werden Address* und Name* nicht gespeichert. Diverse Browser probiert, diverse Reihenfolgen, SAVE mit reboot, ohne reboot... Device Name und WLAN Settings bleiben erhalten. Was ist nur los? Habe bei Github ein ISSUE dazu erstellt.
:
Bearbeitet durch User
So, nun läuft ein Teil. Ich habe mich genau an dieses hier gehalten: https://github.com/grindylow/ahoy/tree/main/tools/esp8266 MQTT Daten bekomme ich vom ESP aber keine Hoymiles Daten, oder anderst ausgedrückt, dass ganze komuniziert noch nicht mit dem Wechselrichter. Auf der http-Seite steht: "...is not available and is not producing" Wo kann ich schauen ob da wirklich nichts geht? Ja. ich habe meine DTUL vom USB getrennt und der Wemos D1 steht direkt unter dem Hoymiles sind ca. 3m Sicht.
Es ist genial, jetzt läuft es richtig. Weil der ESP im Monitor plötzlich die Meldung gezeigt hat: "RF-Modul nicht mehr erreichbar", habe ich alles auf einen anderen Wemos geflasht und das Modul umgesteckt. Auf dem viel älteren identischen Wemos D1 mini läuft jetzt alles korrekt und meine Daten erscheinen auch im Iobroker via MQTT. Absolut geniale Entwicklung. Ich möchte mich bei allen Beteiligten ganz herzlich für ihren Entwicklungsaufwand bedanken. Machen wir uns so doch ein weiteres Stück unabhängiger von der globalen Überwachung, verhindern auch das irgendjemand noch auf die Idee kommt, für die Sonnenstrahlung noch Steuern zu erheben. Gruss aus der Schweiz Andi
Angehängte Dateien:
-
Zwischenablage01.jpg
48 KB -
Zwischenablage02.jpg
110 KB -
Zwischenablage03.jpg
89 KB
Also ich bin auch zu blöd dazu den Datenpunkt für die Leistungsbegrenzung im iobroker anzulegen. Anbei mal ein paar Screenshots. Die MQQT Instanz ist als Server konfiguriert. Die Daten kommen auch von der Ahoy-DTU an. Das Topic ist "Solaranlage" Ich kann aber überhaupt keine Ordner erstellen! Ja Expertenmodus ist an. Kann mir da jemand helfen?
M. P. schrieb: > Also ich bin auch zu blöd dazu den Datenpunkt für die > Leistungsbegrenzung im iobroker anzulegen. > > Anbei mal ein paar Screenshots. > Die MQQT Instanz ist als Server konfiguriert. Die Daten kommen auch von > der Ahoy-DTU an. > > Das Topic ist "Solaranlage" > > Ich kann aber überhaupt keine Ordner erstellen! > Ja Expertenmodus ist an. > > Kann mir da jemand helfen? Hast du im ioBroker unter den Instanzeinstellungen: mqtt.1 im Reiter MQTT EINSTELLUNGEN alles richtig eingestellt?
Das Problem, dass die Adresse (das ist schon die volle Seriennummer mit 12 Stellen, oder?) und der Name nicht gespeichert wird, habe ich jetzt auch. Ich habe auch ein paar Optionen ausprobiert, dass ich #define MAX_NUM_INVERTERS 1 gesetzt habe, macht keinen Unterschied bei dem Problem
Zur Info Test der 0.5.14, #42 mit ESP / HM600 nach Reboot Limit wird gesetzt, Keine WR Daten wenn der Mqtt Broker nicht erreichbar ist. ESP überlast durch Mqtt anfragen ? Falsche Mqtt Broker IP, Absturz des ESP.
Hallo M.P. > Also ich bin auch zu blöd dazu den Datenpunkt für die >> Leistungsbegrenzung im iobroker anzulegen. >> >> Anbei mal ein paar Screenshots. >> Die MQQT Instanz ist als Server konfiguriert. Die Daten kommen auch von >> der Ahoy-DTU an. >> >> Das Topic ist "Solaranlage" >> >> Ich kann aber überhaupt keine Ordner erstellen! >> Ja Expertenmodus ist an. >> >> Kann mir da jemand helfen? Also ich habe da gar keine Datenpunkte angelegt, die hat mir der Iobroker direkt selber erstellt. Im Setup "AHOY-DTU" unter "MQTT" ein Topic eintragen, und wenn die Konfig richtig ist, sollte im Iob eigentlich alle Daten dort drin erscheinen (bei mir ist der Iob auch MQTT-Brocker). Kleiner Typ, im MQTT-Ordner keine eigene Datenpunkte anlegen sondern im nur im "0_userdata". Bedingt dann ein Skript oder Allias das die Daten dann dorthin kopiert.
Moin, sag mal hast Du noch 1 - 2 Platinen ESP-DTU ?
@ Andy Leistungsbegrenzung senden ist gemeint
Sigi S. schrieb: > Dirk S. schrieb: >> Wie bereits geschrieben funktioniert 0.5.13, aber 0.5.14 speichert die >> Inverter Einstellungen nicht und das nicht nur bei mir. > > Bei mir schon. > Wir halten also fest: > Es kann nicht am Code liegen. Nachdem ich die Version 0.5.14 bei mir nicht so fehlerfrei installieren konnte, habe ich heute auf die neue ahoy-DTU ESP8266 Version 0.5.15 mit PlatformIO aktualisiert, WiFi eingegeben, in den Settings "Erase Settings" gedrückt, die Inverter Adresse und MQTT eingegeben. Jetzt läufts wieder, super Arbeit an die Entwickler. Ich halte für mich fest, auch wenn es Sigi S. anders sah, :-) Es kann doch am Code liegen, :-) hier die Info dazu https://github.com/grindylow/ahoy/issues/162 Denn bei einer laufenden Entwicklung gibt es meistens Fortschritte, aber auch manchmal Rückschritte (neue Fehler). Weiter so.
Ralla66 schrieb: > Keine WR Daten wenn der Mqtt Broker nicht erreichbar ist. > ESP überlast durch Mqtt anfragen ? > Falsche Mqtt Broker IP, Absturz des ESP. Ja, richtige Vermutung. Wenn der MQTT Broker nicht erreichbar ist versucht der ESP extrem oft, sich neu zu verbinden. Bei DNS Fehlern so um die 1000 Mal pro Sekunde. Ich habe dazu bereits eine issue auf github angelegt. Ich denke dass ich morgen Zeit haben werde, den Code zu überarbeiten.
Hi und Sorry Leute. Die Kommentare sind ao lang. Kann bitte einer zusammenfassen was nötig ist (Hardware und Software um die DTU zu bauen? LG Jerry
Jerry schrieb: > Hi und Sorry Leute. Die Kommentare sind ao lang. Kann bitte einer > zusammenfassen was nötig ist (Hardware und Software um die DTU zu bauen? Hardware: -ein ESP8266 Board wie z.b. Wemos D1 Mini oder NodeMCU -ein NRF24L01+ Modul -eine Möglichkeit beide zu verbinden (weiblich-weiblich "DuPont" Kabel, Breadboard oder eine entsprechende Platine). -eventuell einen 0.1µF Kondesator oder sogar einen 3.3V Spannungsregler um die Spannungsversorgung des NRF Moduls zu verbessern, sollte das nötig sein (in den meisten Fällen ist es das nicht) Software: -die .bin Datei mit der aktuellen ahoy Software aus dem grindylow/ahoy repo bei github (links unter releases) -ein Tool um Dateien auf den ESP zu flashen. Das geht mit NodeMCU Flasher, ESPTool, mit PlatformIO und vermutlich auch mit der Arduino IDE. Wobei die erste Option für die meisten wahrscheinlich die einfachste ist. Dieses Tool ist nur zur Erstinstallation nötig. Weitere Updates können per Web Interface installiert werden. -Treiber für den USB-to-Serial Chip auf dem ESP8266 Board (CH340 o.ä.)
Jerry schrieb: > Hi und Sorry Leute. Die Kommentare sind ao lang. Kann bitte einer > zusammenfassen was nötig ist (Hardware und Software um die DTU zu bauen? > LG > Jerry Ist es in diesem Forum möglich, den allerersten Beitrag (auf Seite 1) jetzt noch zu Ändern, bzw. zu ergänzen? Falls ja, wäre dort ein Hinweis auf das ahoy-git mit einer kurzen Beschreibung zu SW und HW nicht schlecht.
Hat schon jemand Erfahrungen mit diesem Funk-Modul sammeln können? Laut Beschreibung soll es ein Original Nordic Chip sein. https://de.aliexpress.com/item/1005001803228202.html
Claus T. schrieb: > Ist es in diesem Forum möglich, den allerersten Beitrag (auf Seite 1) > jetzt noch zu Ändern, bzw. zu ergänzen? > Falls ja, wäre dort ein Hinweis auf das ahoy-git mit einer kurzen > Beschreibung zu SW und HW nicht schlecht. Nein ist es nicht möglich. Beiträge können erstens nur vom verfasser geändert werden und zweitens ist es auch nur dann möglich, wenn nach dem Verfasser kein neuer Beitrag geschrieben wurde. Wenn du Hilfe brauchst, schau doch einfach auf der Github Seite oder im Discord nach. :)
tastendruecker schrieb: > -die .bin Datei mit der aktuellen ahoy Software aus dem grindylow/ahoy > repo bei github (links unter releases) Finde ich nicht mehr. Unter Actions kann ich auch nichts runterladen?!
Bitte um Entschuldigung, irgendwann habe ich es nachträglich auch kapiert, dass es ums senden geht. Ist bei meinem HM600 auch gar nicht notwendig, weil er nicht mehr kann. Das Problem mit dem "Download" vom git hatte ich gestern auch, bis ich begriffen habe, dass da im "clone" alle Varianten drin sind. Ich habe dann im Ordner Tool die Wemos Variante gefunden und daraus im Platformio ein eigenes Projekt erzeugt. Jetzt geht es wunderbar. Auch das eintragen der Wlan und Mqtt Daten ging im File viel besser als über die Webseite vom ESP. Denn dort speicherte er bei mir zwar irgendwelche Einträge, aber die waren kryptisch und kaum richtig. Was bei mir aber dann ging: Ein Eintrag machen und speichern mit reboot, danach nächste Zeile usw. Ich denke, dass ist ein html Problem beim Daten übernehmen in die verschiedenen Variablen. Etwas was noch ganz schön wäre (oder ich habe es übersehen), wäre ein Datenpunkt der mir direkt angibt "HMxxx true/false". Das hat bei mir folgenden Grund: Ich habe einen Shelly PM (mit 2poligem Relais) in der Netzleitung und würde gerne den Hoymiles in der Nacht komplett abtrennen. Da würde ein solcher Datenpunkt eben etliches an Programierung ersparen im Iobroker. Gruss Andi
Hallo Leute! vielen Dank für Eure tolle Arbeit! Habe es endlich geschafft, die .bin Datei zu flashen, und habe jetzt die version 5.14 oben. Beim Zugriff auf den AP werde ich jedoch noch einem Passwort gefragt! Gibt es denn eines, oder hat das flashen hier denn irgendwie nicht richtig funktioniert?
Nachdem ich die ESP8266-Version 0.4.20 seit über einen Monat produktiv im Einsatz habe und damit auch zufrieden bin, habe ich mir auf ein zweites System testweise die neue 0.5.x Version installiert. Da stellen sich folgende Fragen: was bedeuten die neuen Felder P_ACr und die Einheit VAr bzw. ALARM_MES_IS ? Kann man irgendwo etwas darüber nachlesen? Gruß Herbert
Hubert schrieb: > Hallo Leute! > > vielen Dank für Eure tolle Arbeit! Habe es endlich geschafft, die .bin > Datei zu flashen, und habe jetzt die version 5.14 oben. > Beim Zugriff auf den AP werde ich jedoch noch einem Passwort gefragt! > Gibt es denn eines, oder hat das flashen hier denn irgendwie nicht > richtig funktioniert? Das AP Standardpasswort ist "esp_8266"
Eine tolle Arbeit der Entwickler. Hut ab und besten Dank dafür! Eine tolle Sache, wenn man die PV-Anlage damit detailliert im Blick hat. Gestern hat es mir die Füße weggezogen. Ich hatte die Version 0.4.xx noch drauf. Gestern habe ich dann die Version 0.5.14 geflasht. Und nichts ging. Fehler wie oben beschrieben. Den Fehler habe ich einen halben Tag bei mir gesucht. Bis ich gesehen habe, dass es am Nachmittag die neue Version 0.5.15 gab. Das hat auf Anhieb wieder funktioniert. Ich war verblüfft, wie schnell die Entwickelter reagiert haben. Sie sind wirklich sehr arrangiert. Vielen Dank!
Daniel schrieb: > Nein ist es nicht möglich. Beiträge können erstens nur vom verfasser > geändert werden und zweitens ist es auch nur dann möglich, wenn nach dem > Verfasser kein neuer Beitrag geschrieben wurde. > > Wenn du Hilfe brauchst, schau doch einfach auf der Github Seite oder im > Discord nach. :) Hallo Daniel, ich hatte die Hoffnung dass evtl. ein registrierter User seine Einträge noch ändern kann. Als Gast sollte das natürlich nicht gehen und fremde Einträge ändern natürlich erst recht nicht. War als Einstiegshilfe für die neuen Anwender gedacht, :-) ich bin schon länger dabei und hab inzwischen alle Beiträge gelesen :-) , um die vielen sich wiederholenden Frage nach wo, wie, was,… zu minimieren. Grüße Claus T.
Herbert S. schrieb: > was bedeuten die neuen Felder P_ACr und die Einheit VAr bzw. > ALARM_MES_IS ? P_ACr, ist AC reactive power, also Scheinleistung. Wird für die meisten eher nebensächlich sein, aber der WR gibt es halt mit aus. Alarm_MES_ID gibt an, wieviele Warnungen/Alarme der WR geschickt hat. Aber das ist in der Regel sowas wie 'PV Spannung zu niedrig' abends.
Hallo Andi K. > Hat schon jemand Erfahrungen mit diesem Funk-Modul sammeln können? > Laut Beschreibung soll es ein Original Nordic Chip sein. > https://de.aliexpress.com/item/1005001803228202.html Ich habe noch keines in der freien Wildbahn hier in DE gesehen. Schön ist dass es ein Abschirmblech hat! Wenn Du welche bestellen solltest hätte ich auch Interesse an einem / zwei Modulen. Grüsse Stefan T
Andi K. schrieb: > Hat schon jemand Erfahrungen mit diesem Funk-Modul sammeln können? > Laut Beschreibung soll es ein Original Nordic Chip sein. > > https://de.aliexpress.com/item/1005001803228202.html Ich hatte hier bestellt: https://de.aliexpress.com/item/4000516282921.html?spm=a2g0o.order_list.0.0.21ef5c5fwq0ieL&gatewayAdapt=glo2deu Lieferung innerhalb von zwei Wochen! Das Modul macht einen sehr guten Eindruck, funktioniert bei mir auch einwandfrei - allerdings habe ich nur ca. 1 m und eine Betondecke zwischen WR und "DTU", alle anderen Versionen der von mir getesteten nRF24L01+-Module machen da auch keine Probleme. Und die Chips sind hinter der Abschirmung "versteckt".
Hubert schrieb: > Hallo Leute! > > vielen Dank für Eure tolle Arbeit! Habe es endlich geschafft, die .bin > Datei zu flashen, und habe jetzt die version 5.14 oben. > Beim Zugriff auf den AP werde ich jedoch noch einem Passwort gefragt! > Gibt es denn eines, oder hat das flashen hier denn irgendwie nicht > richtig funktioniert? Moin, PW ist esp_8266 Ich komme auf die Startseite, auf die setup Seite komme ich nach dem flashe des D1 Mini immer nur 1mal und diese wird nicht richtig angezeigt. Rufe ich Setup ein zweites mal auf rebootet der D1. Grüsse AD
Ich habe ahoy auf einem ESP8266 mit NRF24L01+ installiert (Ahoy sieht super aus). NRF wird erkannt, allerdings reagiert der Wechselrichter nicht, obwohl die korrekte Seriennummer eingetagen ist. Es ist ein MI-1500 mit 1062xxxxxxxx aus 2021 (gekauft als HM-1500). Ich habe gelesen: "Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer: 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren" Was bedeutet dies genau? An welchen Stellen sind Änderungen im Code vorzunehmen, bzw. hat jemand diese Type schon zum Laufen gebracht mit irgendeiner Plattform? Ich könnte mit ESP8266, Arduino Nano, or Raspberry PI 3B das Debugging unterstützen. Wie würdet ihr vorgehen?
Angehängte Dateien:
-
ahoy.JPG
20 KB
Moin, ich hatte mit 0.5.12 Probleme das die Setup seite nicht geöffnet wurde und der D1 mini offensichtlich eine reset durgeführt hat! Habe jetzt die 5.15 drauf und die nun scheints zu gehen! Beim compilieren können 2 Datein nicht erstellt werden aber die brauche ich wohl nicht! AD
:
Bearbeitet durch User
Reinhard schrieb: > Ich habe ahoy auf einem ESP8266 mit NRF24L01+ installiert (Ahoy sieht > super aus). NRF wird erkannt, allerdings reagiert der Wechselrichter > nicht, obwohl die korrekte Seriennummer eingetagen ist. > > Es ist ein MI-1500 mit 1062xxxxxxxx aus 2021 (gekauft als HM-1500). Ich > habe gelesen: > "Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann > nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer: > 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und > DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren" Suche mal in diesem Thread (ggf. Seitenaufteilung abschalten) nach "MI-1500" bzw. Beiträgen von "Ziyat T. (toe_c)" und "Jörg R. (rejoe2)". Die beiden haben sich intensiv mit dem MI-1500 beschäftigt.
Ralla66 schrieb: > Dann müsste ja > WRSer in dec 6 77 21 > ESP Dtu 4 56 78 > ergibt Ch 3 23 40 61 75 > wobei ja DTU fest ist und die CH immer ähnlich sind bei HM600. Hallo zusammen! Gibt es zu den Kanalwechseln schon weitere Erkenntnisse? (Leider kann ich die Rechnung zu den genannten Werten nicht folgen)
Reinhard schrieb: > Ich habe ahoy auf einem ESP8266 mit NRF24L01+ installiert (Ahoy sieht > super aus). NRF wird erkannt, allerdings reagiert der Wechselrichter > nicht, obwohl die korrekte Seriennummer eingetagen ist. > > Es ist ein MI-1500 mit 1062xxxxxxxx aus 2021 (gekauft als HM-1500). Ich > habe gelesen: > "Bitte beachten: Der Mikroumwandler der Seriennummer "1062xxxxxxxx" kann > nur mit dem neuen Gateway von Hoymiles, DTU-Pro (Seriennummer: > 10F7xxxxxxxx, 10F8xxxxxxxx ), DTU-G100 ( Seriennummer: 10D2xxxxxxxx) und > DTU-W100 (Seriennummer: 10D3xxxxxxxx) funktionieren" > > Was bedeutet dies genau? An welchen Stellen sind Änderungen im Code > vorzunehmen, bzw. hat jemand diese Type schon zum Laufen gebracht mit > irgendeiner Plattform? > > Ich könnte mit ESP8266, Arduino Nano, or Raspberry PI 3B das Debugging > unterstützen. Wie würdet ihr vorgehen? Hi, ändere einfach mal deine Seriennummer im Setup/Eingabe von 1062xxxxxx auf 1161xxxxxxx (die "xxxxx" sind natürlich in beiden Fällen die gleichen die für dich gelten) Grüße
@Reinhard (sym) Ist der WR ein MI-1500 oder HM-1500? Was steht drauf? Für MI-1500 gibt es bisher diesen git Repo: https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles
Danke sehr. Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen HM-1500? Der Wechselrichter sieht genau wie ein MI-1500 aus, gelabelt ist er mit MSC Grid Tie Inverter 1500W. Ziyat T. (toe_c) oder Jörg R. (rejoe2), könnt ihr mir einen Link schicken von einem kompletten Sketch, den ich testen kann?
Boris J suche den Algo halt, WR ID verkaspert mit DTU ID ergibt CH, oder wird mitgesendet, dann welches cmd welche Umrechnung oder ... doch zufällig ?
Reinhard schrieb: > Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen > HM-1500? Nach der Übersicht hier https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx ist es eher **kein** HM-1500.
Vielen Dank für den tollen Support. Leider habe ich noch nicht mit dem Wechselrichter (MI-1500 höchstwahrscheinlich) kommunizieren können. Ich werde Ziyatoes code (https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles) die nächsten Tage testen - kompilieren konnte ich ihn schon (BTW: in Sonne.h fehlt ein l für long). Vermutlich macht es sogar Sinn mit einem zweiten ESP8266 zu sniffen um zu sehen, dass die Nordic Module richtig funktionieren - Ich habe welche mit power amplifier und welche ohne.
Andreas schrieb: > Beim compilieren können 2 Datein nicht erstellt werden aber die brauche > ich wohl nicht! > > AD Ab der 5.15 gibt es auch eine Version für den ESP32, aber der ESP32 Build scheint bei dir nicht geklappt zu haben. Wenn du allerdings einen ESP8266 verwendest, spielt das keine Rolle.
Receive success: 1 Receive fail: 72 Frames received: 7 Send Cnt: 434 Inverter 'HM1500 (FW-Version: 0)' is not available and is not producing -> last successful transmission: 2022-08-24 07:31:17 Welche Einträge muss ich wie setzen? Der WR produziert sehr wohl Energie, aber fälschlicher Weise steht im Webinterface obige Anzeige. BG
Die Seriennummer beim Setup > Adresse Der Empfänger darf nicht zu weit vom Inverter sein!
Die Seriennummer ist korrekt und die Visualisierung zeigt auch „Produktion“, trotzdem die Fehlermeldung
Beitrag #7169599 wurde vom Autor gelöscht.
Sermon schrieb: > Receive success: 1 > Receive fail: 72 > Frames received: 7 > Send Cnt: 434 > > Inverter 'HM1500 (FW-Version: 0)' is not available and is not producing > -> last successful transmission: 2022-08-24 07:31:17 > > > Welche Einträge muss ich wie setzen? > > Der WR produziert sehr wohl Energie, aber fälschlicher Weise steht im > Webinterface obige Anzeige. > > BG Einfach mal laufen lassen. Hatte ich auch schon. Dauerte teilweise schon sehr lange bis dann plötzlich Daten empfangen wurden. Und dass ohne etwas am Standort der Geräte, WLAN etc geändert wurde.
Guten Tag zusammen, ich stelle jetzt mal eine Frage aus der Sicht eines Webentwicklers der von Mikrokontrollern keine und von Elektrotechnik wenig Ahnung hat ... also nicht wundern ;-) Der Hoymiles USB Stick Lite schickt die Daten ja an die Hoymiles Cloud und wir wollen die Daten ja lokal haben. Zum Transfer der Daten muss dann ja eine Ziel Domain oder -IP angegeben sein, damit die Daten dann auch dorthin versendet werden können. Jetzt stellt sich mir die Frage: * Könnte man die IP/Domain nicht einfach so verändern, das die Daten lokal landen? Also eben nicht Cloud, sondern z.B. 192.168.1.123 etc ... ? * Oder wäre es möglich die IP im Datenstrom durch einen Proxy umschreiben zu lassen? So könnten die Daten dann auc lokal verarbeitet werden. Mit WireShark müssten die Daten ja sichtbar sein, oder sind die verschlüsselt? Was meint Ihr dazu? Die Verarbeitung der Daten ist dann natürlich noch was anderes, aber es ging ja primär darum, die Cloud zu umgehen und die Daten lokal zuhaben.
Martin Ecker schrieb: > Guten Tag zusammen, > > ich stelle jetzt mal eine Frage aus der Sicht eines Webentwicklers der > von Mikrokontrollern keine und von Elektrotechnik wenig Ahnung hat ... > also nicht wundern ;-) > > Der Hoymiles USB Stick Lite schickt die Daten ja an die Hoymiles Cloud > und wir wollen die Daten ja lokal haben. > > Zum Transfer der Daten muss dann ja eine Ziel Domain oder -IP angegeben > sein, damit die Daten dann auch dorthin versendet werden können. > > Jetzt stellt sich mir die Frage: > * Könnte man die IP/Domain nicht einfach so verändern, das die Daten > lokal landen? Also eben nicht Cloud, sondern z.B. 192.168.1.123 etc ... > ? > > * Oder wäre es möglich die IP im Datenstrom durch einen Proxy > umschreiben zu lassen? So könnten die Daten dann auc lokal verarbeitet > werden. > Mit WireShark müssten die Daten ja sichtbar sein, oder sind die > verschlüsselt? > > Was meint Ihr dazu? > > Die Verarbeitung der Daten ist dann natürlich noch was anderes, > aber es ging ja primär darum, die Cloud zu umgehen und die Daten lokal > zuhaben. Moin, genau darum geht hier in dem Thread, aber halt nicht mit dem Hoymiles DTu sondern mit einem Eigenbau. Du solltet Dir so was basteln und dann dmit "rumspielen" die Lösung mit dem ESP8266 ist recht einfach! Falls du dir das nicht zutraust kann ich helfen! Grüsse Andreas
Hallo, ich habe seit ein paar Tagen die Version 0.5.15 im Einsatz. Ich habe zwei Inverter definiert, jedoch nach einen Reboot erscheinen Angaben im 3. Inverter, [Address: 52656368, Name: n],die ich nicht gemacht habe. Durch einen Save(ohne Boot) kann man dies löschen und das wird auch richtig verarbeitet. Aber bei einen erneuten Reboot tauchen die Angaben wieder auf. Die Limit-Angabe in der Visualization-Seite wechselt ohne das ich eine entsprechende Eingabe gemacht habe, manchmal auf 32%. Das hat aber keinen Einfluss auf die Einsspeise-Leistung des WR. Gruß Herbert
Herbert S. schrieb: > Hallo, > > ich habe seit ein paar Tagen die Version 0.5.15 im Einsatz. Ich habe > zwei Inverter definiert, jedoch nach einen Reboot erscheinen Angaben im > 3. Inverter, [Address: 52656368, Name: n],die ich nicht gemacht habe. > Durch einen Save(ohne Boot) kann man dies löschen und das wird auch > richtig verarbeitet. > Aber bei einen erneuten Reboot tauchen die Angaben wieder auf. > Die Limit-Angabe in der Visualization-Seite wechselt ohne das ich eine > entsprechende Eingabe gemacht habe, manchmal auf 32%. Das hat aber > keinen Einfluss auf die Einsspeise-Leistung des WR. > > Gruß > Herbert Das kann ich so bestätigen, hatte nach Inbetriebnahme das gleiche Problem. Lösche doch mal den gesamten Flash des ESP8266 nach folgender Anleitung: http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers Danach die aktuellste *.bin - Datei flashen.
Reinhard schrieb: > Danke sehr. Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen > HM-1500? Der Wechselrichter sieht genau wie ein MI-1500 aus, gelabelt > ist er mit MSC Grid Tie Inverter 1500W. > > Ziyat T. (toe_c) oder Jörg R. (rejoe2), könnt ihr mir einen Link > schicken von einem kompletten Sketch, den ich testen kann? Hi, Es ist ein hm1500. Nutze einfach ein esp8266 board mit ahoy Firmware 0.5.15 und schreibe die Seriennummer immer als 1161xxxx
„Danach die aktuellste *.bin - Datei flashen.„ Könnte einer der Entwickler uns erhellen? Irgendwas stimmt nicht, aber was?
Sorbit schrieb: > „Danach die aktuellste *.bin - Datei flashen.„ > > Könnte einer der Entwickler uns erhellen? > > Irgendwas stimmt nicht, aber was? Worüber denn?
Worüber denn? Worüber wohl, nicht im Thema?!
Ich verstehe nach wie vor nicht, über was du erhellt werden möchtest. Und der Ton ist ebenfalls befremdlich.
Hallo, nach durchforsten dieses threads und einigem Ausprobieren mit
ahoy (esp8266) und openDTU (esp32) wollte ich mal fragen ob mittlerweile
jemand den
TSUN TSOL-M800 mit ner 104161xxxxxx Seriennummer ans laufen gebracht?
Ich bekomme da einfach keine Verbindung zum Inverter. Hardware sollte
passen.
Der Inverter läuft hier seit 2 Jahren prima, würde ihn nur gerne in die
restliche Infrastruktur (diverse Tasmotas und Eigenbauten mit ESPs/MQTT)
per mqtt einbinden.
Gruß
Johannes
tastendruecker schrieb: > Ich verstehe nach wie vor nicht, über was du erhellt werden möchtest. > Und der Ton ist ebenfalls befremdlich. Das steht 2 Posts früher, einen "TON" vernehme ich hier nicht. Aber die Nachricht entsteht ja eh beim Empfänger, so Watzlawick. Hier sind viele nicht gewillt, oder in der Lage, etwas Mühe und Zeit in den Verlauf zu investieren um selbst längst gegebene Antworten zu finden. Ist allgemein so, work life balance steht im Vordergrund, CORONA und Homeoffice forcieren die Häwelmänner. Also mal bitte nicht so schenll die (shiftlosen) Tasten drücken, Herr tastendrücker. Darum verstehe ich, das keiner der Entwickler mehr direkt in diese Chaos hinein antwortet. Dafür gibt es nun Github Issues. Alles gut, bleibt freundlich.
Johannes schrieb: > Hallo, nach durchforsten dieses threads und einigem Ausprobieren mit > ahoy (esp8266) und openDTU (esp32) wollte ich mal fragen ob mittlerweile > jemand den > > TSUN TSOL-M800 mit ner 104161xxxxxx Seriennummer ans laufen gebracht? Ich warte aktuell noch auf die Lieferung eines TSUN M800, bin aber guter Hoffnung, dass dieser mit ahoy kommunizieren kann. Bei Raik E. soll es zumindest funktionieren: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Ja, seiner hat auch ne 114173307xxx Seriennummer, meiner eine mit 1041 startende...
Angehängte Dateien:
-
2222.jpg
10 KB
Woran kann es liegen dass ich den Ahoy nicht in Home Assistant bekomme? Addon Mosquitto broker: installliert -Integration: installiert und aktiviert -mehrfach HA neugestartet -Ahoy DTU mehrfach neugestartet -IP, Port, Passwort und Benutzername ebenfalls richtig Ahoy sagt MQTT: connected Ich bekomme auch alles mit den gleichen Daten im mqtt-explorer angezeigt. Nur taucht es eben in HA nicht auf, bin auch mit jemanden durchgegangen der es gestern installiert hat und bei dem es läuft, bei ihm geht es, bei mir nicht. Ich bin auch auf ein Video gestoßen wo gesagt wurde man solle einen neuen benutzer anlegen "mqtt-user" auch mit dem geht es einfach nicht. Jemand eine Idee?
Angehängte Dateien:
-
2022-08-26.png
96 KB
Sören S. schrieb: > Woran kann es liegen dass ich den Ahoy nicht in Home Assistant > bekomme? > Addon Mosquitto broker: installliert > -Integration: installiert und aktiviert > -mehrfach HA neugestartet > -Ahoy DTU mehrfach neugestartet > -IP, Port, Passwort und Benutzername ebenfalls richtig > > Ahoy sagt MQTT: connected > Ich bekomme auch alles mit den gleichen Daten im mqtt-explorer > angezeigt. > > Nur taucht es eben in HA nicht auf, bin auch mit jemanden durchgegangen > der es gestern installiert hat und bei dem es läuft, bei ihm geht es, > bei mir nicht. > > Ich bin auch auf ein Video gestoßen wo gesagt wurde man solle einen > neuen benutzer anlegen "mqtt-user" auch mit dem geht es einfach nicht. > > Jemand eine Idee? Also bei mir war das auch so. Alles versucht, aber kein mqtt Autodiscovery. Auch mehrfach versucht. Es wollte einfach nicht klappen. Im mqtt-explorer siehst du ja die Topics. Habe die in der configuration.yaml dann händisch angelegt.
1 | |
2 | - platform: mqtt |
3 | state_topic: "solar/11617xxxxx/0/yieldtotal" |
4 | name: "Gesamtproduktion HM-1500" |
5 | device_class: energy |
6 | unit_of_measurement: "KW/H" |
7 | value_template: > |
8 | {{value|round(2)}} |
9 | state_class: total_increasing |
10 | unique_id: "total_hm1500" |
11 | last_reset_topic: "solar/11617xxxxx/0/yieldtotal" |
12 | last_reset_value_template: "1970-01-01T00:00:00+00:00" |
Das Problem hatte ich auch, allerdings mit OpenDTU auf ESP32. Letztendlich habe ich irgendwo (in der Homeassistant-Dokumentation?) gefunden, dass folgende Einträge in die configuration.yaml geschrieben werden müssten:
1 | mqtt: |
2 | broker: http://<IP des Brokers> |
3 | discovery: true |
4 | discovery_prefix: solar |
Ich glaube, ich musste HA dann noch einmal neu starten, danach funktionierte das Autodiscovery wie gewünscht.
Angehängte Dateien:
Hallo, vielen Dank für eure cool Arbeit... Es funktioniert nun ganz ausgezeichnet. Ich habe mir ein RF-Nano bestellt und musste feststellen, dass gar kein echter ATMega verbaut ist, sondern ein chinesischer Clone (nulllab). Das hatte mich etwas zurückgeworfen. Außerdem baut man das RF-Nano ohne den ISR Pin rauszuführen... also nicht mal ein Testpunkt oder so... Absolut eintäuschend... Also den Patch noch herstellen und die Idee, des 0-Lötaufwandes war obsolete. Aber es sieht trotzdem noch ganz okay und ungebastelt aus. Fürs Protokoll: ich habe ein TSUN TSOL-M800(DE) also auf 600 VA begrenzt. Seriennummer: 1141820XXXXX -> der Anfang mit 82 ist noch nicht in der Excelliste. Kann ich sonst noch was tun? Viele Grüße Basti
Hallo zusammen, ich kann unter Github-Action nur die Version 0.5.14 finden. Gibt es für die 0.5.15 ein neues Versteck ;-) ?
Ihr habt super Arbeit geleistet! Habe meine beiden HM-300 sehr schnell ans Netz bekommen. Zur Info: Für mein NRF24+ Modul https://www.amazon.de/NRF24L01-Wireless-Transceiver-Antenne-kompatibel/dp/B07Y4ZLPTJ musste ich den öffter erwähnten Kondensator für die 3,3V installieren.
OlaLu schrieb: > Das Problem hatte ich auch, allerdings mit OpenDTU auf ESP32. > Letztendlich habe ich irgendwo (in der Homeassistant-Dokumentation?) > gefunden, dass folgende Einträge in die configuration.yaml geschrieben > werden müssten: > mqtt: > broker: http://<IP des Brokers> > discovery: true > discovery_prefix: solar Dass war noch ein Fehler in der Default OpenDTU Konfiguration (Heute behoben). Du kannst das discovery_prefix in der configuration.yaml auch weglassen (default ist homeassistant) und unter Settings --> MQTT --> "Home Assistant MQTT Auto Discovery Parameters" --> "Prefix Topic" einfach "homeassistant/" eintragen.
Dirk Z. schrieb: > Hallo zusammen, ich kann unter Github-Action nur die Version 0.5.14 > finden. Gibt es für die 0.5.15 ein neues Versteck ;-) ? code ----releases
Hallo Reinhard und Johannes, mit der Version von Ziyat T. sollte es eventuell gehen, ich hoffe, Anfang Sept. auch eine etwas einfachere Variante für alle 10-er Nummern als Basis für das Weiter-Entwickeln in Richtung ahoy-Integration anbieten zu können.
Thomas B. schrieb: > Dass war noch ein Fehler in der Default OpenDTU Konfiguration (Heute > behoben). Du kannst das discovery_prefix in der configuration.yaml auch > weglassen (default ist homeassistant) und unter Settings --> MQTT --> > "Home Assistant MQTT Auto Discovery Parameters" --> "Prefix Topic" > einfach "homeassistant/" eintragen. Nun, das hatte ich zuerst auch so versucht, allerdings als Topic immer "solar/" eingetragen - und es funktionierte erst mit den o.g. Änderungen in der configuration.yaml. Vielen Dank Thomas für die Fehlerbehebung und auch mal einen ganz dicken Dank an alle Entwickler für eure tolle Arbeit hier im Forum!
Moin, ich nutze seit einer Woche einen ESP8266 mit einem HM-1500, funktioniert einwandfrei! Das einizige was mir aufgefallen ist das die Uhrzeit sehr viel nachgeht. Weiss jemannd wo die Zeit definiert bzw. wie die Zeit berechnet wird. Ich denke die Synchronisierung mit dem NTP Server wird nur beim Start des ESP einmal ausgeführt! AD
Hallo Andreas, korrekt, die Zeit wird nur einmal beim Start geholt. Laut Stefan sollte die garnicht so stark davonlaufen. Jetzt bin ich neugierig. Was hast du gemacht, dass dein ESP so lange läuft? Welcher Aufbau und welche Version? Mein ESP läuft maximal 8h, dadurch habe ich immer eine frische Zeit - ich hätte aber auch gerne eine Laufzeit > 1 Tag Die neue Synchronisation der Zeit brauchen wir auf jeden Fall, man könnte einen Trigger einbauen, der alle 12h aktiv wird.
Lukas P. schrieb: > Hallo Andreas, > > korrekt, die Zeit wird nur einmal beim Start geholt. Laut Stefan sollte > die garnicht so stark davonlaufen. > Jetzt bin ich neugierig. Was hast du gemacht, dass dein ESP so lange > läuft? Welcher Aufbau und welche Version? Mein ESP läuft maximal 8h, > dadurch habe ich immer eine frische Zeit - ich hätte aber auch gerne > eine Laufzeit > 1 Tag > > Die neue Synchronisation der Zeit brauchen wir auf jeden Fall, man > könnte einen Trigger einbauen, der alle 12h aktiv wird. Moin, ich habe mich evtl. etwas falsch ausgedrückt, das ganze Setup läuft seit einer Woche. Der ESP8266 bootet schonmal oder ich habe ihn gebootet. Die Zeit läuft ca. 5min pro 3 STunden zu langsam!
Angehängte Dateien:
Vier Tage Laufzeit habe ich schon dokumentiert - s. Screenshot. Aufbau dazu: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Unter dem nRF24L01+-Modul "versteckt" ist ein 3,3V-Spannungsregler für dieses Modul. Die von Andreas beschriebenen Abweichungen bei der Zeit habe ich auch beobachtet. Sie sind wohl vom jeweiligen ESP8266-Baustein abhängig.
> Die Zeit läuft ca. 5min pro 3 STunden zu langsam!
Das kann ich nicht bestätigen. Meine Uptime ist jetzt 02:38 und die Zeit
geht ca. 8s nach.
Lukas P. schrieb: > Das kann ich nicht bestätigen. Meine Uptime ist jetzt 02:38 und die Zeit > geht ca. 8s nach. Ich denke das hängt von Modul ab! Ich arbeite vermutlich mit einem China Cone!?
Andreas S. schrieb: > Reinhard schrieb: >> Danke sehr. Habe ich mit dem 1062xxxxxxxx einen MI-1500 oder einen >> HM-1500? Der Wechselrichter sieht genau wie ein MI-1500 aus, gelabelt >> ist er mit MSC Grid Tie Inverter 1500W. >> >> Ziyat T. (toe_c) oder Jörg R. (rejoe2), könnt ihr mir einen Link >> schicken von einem kompletten Sketch, den ich testen kann? > > Hi, > Es ist ein hm1500. > Nutze einfach ein esp8266 board mit ahoy Firmware 0.5.15 und schreibe > die Seriennummer immer als 1161xxxx Hallo Andreas, dein Tipp war goldrichtig. 1161xxxxxxxx eintragen statt 1062xxxxxxxx eintragen und der Wechselrichter funkt mit ahoy am ESP8266 brav. Ich habe D1/D2 für CE/IRQ genommen (da auf D3 oder D4 eine LED am ESP8266 Modul ist). Vielleicht war dies der Grund, warum ich vorher keine Verbindung geschafft habe. Jedenfalls, vielmals Danke nochmals!
Hallo, ich nochmal: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" ich verwende den Arduino Nano Code (nicht Plattform.io) und habe noch unterschiedliche Aussagen bei den zwei Parametern: E-Woche:28832.00 E-Total:26394.00 Ist da was bekannt? Ich nehme an, es ist vertauscht und die Wochenfunktion ist nicht wirklich korrekt. Also 28 kWh total klingt durchaus realistisch. Ist für mich jetzt nicht wirklich relevant, ich lese es jetzt einfach bei E-Woche ab und gut ist. Viele Grüße Basti
Hallo coole sache die ihr geschaffen habt. Habe eine frage die ich beim Durchlesen so nicht gefunden habe. Kann man über OpenDTU oder ahoy TOR Einstellungen ändern wie es über die DTu von hoymiles möglich wäre? Oder ist es rein zum Auslesen der Daten? In Österreich wäre folgende Einstellungen nötig: "Der Betrieb ist nur dann erlaubt, wenn die geltenden Richtlinien TOR-Erzeuger am Wechselrichter aktiviert wurden (AT_TOR_Erzeuger_default)."
Johannes schrieb: > Ja, seiner hat auch ne 114173307xxx Seriennummer, meiner eine mit > 1041 startende... Hier ebenso, TSUN M800 mit 1041 kommuniziert leider nicht (0.5.15)
Angehängte Dateien:
Hallo, nachdem ich mich hier durchgewurschtelt habe, openDTU auf ESP32pico so läuft, stellt sich mir die Frage was hat das mit dem Git Hash auf sich ? Weil bei mir steht da alles nullen, siehe Bild. Und im 2.bild muß ich da die Daten von meinem Heimnetz eintragen. Ich bekomme keine Verbindung zum WR, achso ist ein HM-800.
Jetzt mal doof gefragt, was ist denn die IP des Brokers bei Home Assistant?
@ D.J, ja richtig im 2. Bild die Daten von deinem Heimnetz eingeben. Was dann noch fehlt ist die SN vom Inverter unter Inverter Settings. Sollte keine Verbindung zustande kommen, die Sendeleleistung erhöhen und/oder näher an den WR ran.
D Sören S. schrieb: > Jetzt mal doof gefragt, was ist denn die IP des Brokers bei Home > Assistant? Die IP von dem PC oder vom RPi wo drauf der HA läuft.
Hallo miteinander! Alle Achtung für Euer ambitioniertes Projekt! Bin seit >30a HW-Entwickler & weiß zu schätzen, was Ihr da leistet! LGG
Jörg R. schrieb: > mit der Version von Ziyat T. sollte es eventuell gehen, ich hoffe, > Anfang Sept. auch eine etwas einfachere Variante für alle 10-er Nummern > als Basis für das Weiter-Entwickeln in Richtung ahoy-Integration > anbieten zu können. Hi Jörg, Welche Version genau meinst du? Ich habe jetzt nochmal Ahoy 0.5.15 probiert, Seriennummer mal als 1041 mal als 1141 eingegeben, es kommen aber keine Daten vom Inverter. Wenn ich dir was helfen kann beim integrieren, testen oder so, lass es mich wissen. Gruß Johannes. ...dann gehts erstmal auf der anderen Baustelle weiter: ESPHome mit Soyosource1000, Epever Laderegler und DALY BMS sprechen lassen.
Johannes schrieb: > Jörg R. schrieb: >> mit der Version von Ziyat T. sollte es eventuell gehen, ich hoffe, >> Anfang Sept. auch eine etwas einfachere Variante für alle 10-er Nummern >> als Basis für das Weiter-Entwickeln in Richtung ahoy-Integration >> anbieten zu können. > > Hi Jörg, > Welche Version genau meinst du? > > Ich habe jetzt nochmal Ahoy 0.5.15 probiert, Seriennummer mal als 1041 > mal als 1141 eingegeben, es kommen aber keine Daten vom Inverter. > > Wenn ich dir was helfen kann beim integrieren, testen oder so, lass es > mich wissen. > > Gruß > Johannes. > > ...dann gehts erstmal auf der anderen Baustelle weiter: ESPHome mit > Soyosource1000, Epever Laderegler und DALY BMS sprechen lassen. Bei den Beiträgen von Ziyat T. und mir geht es um die 2nd Generation-Geräte (SN 10xx), da sind auch zip-Dateien bzw. repo-Links dabei). Bis das in ahoy oä. drin ist, wird es etwas dauern, und man muss in etwa eine Vorstellung haben, was da wie anzupassen ist... Hoffe, in ein paar Tagen was vereinfachtes zum testen anbieten zu können. Mit jnz gibt es ja vermutlich noch einen user, den das betrifft...
Angehängte Dateien:
-
TSUN_tsol-m800.jpeg
210 KB
Danke Jörg, Ich hab das Repo von Ziyat gefunden: https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles Mit dem code in der zip und nach umstellen auf MI600 und bekome ich jetzt tatsächlich Daten vom TSUN TSOL-M800 mit 1041er Seriennummer in der Konsole. Vielen Dank schonmal. EDIT: nachdem ich NRofPV auf 1 gesetzt hab gehen jetzt auch Webserver und MQTT senden. Denke ich werde das senden noch was anpassen, lieber einen JSON String statt vieler einzelner Werte, werde wohl das format von Tasmota übernehmen, das passt dann gut zum rest und geht direkt in die Influx. Gruß Johannes
:
Bearbeitet durch User
Jörg R. schrieb: > Hoffe, in ein paar Tagen was vereinfachtes zum testen anbieten zu > können. > Mit jnz gibt es ja vermutlich noch einen user, den das betrifft... Danke Jörg, das klingt vielversprechend. Teste dann gern und werde rückmelden. Danke Johannes für den eindeutigen Beweis, das die 1041TSUN prinzipiell zur Kommunikation zu bewegen sind. Viele Grüße
Hat eigentlich jemand mal sowas wie die oberste Spannungsgrenzabschaltung bei 60V gesehen? Bei mir steigt die Spannung morgens manchmal zu heftig an und ich steht kurz auf 65V was zu einem Totalausfall für betreffenden Tag führt. Ich hätte Interesse diesen Wert auf 70V zu kriegen. Aushalten tun es die Geräte, bloß wollen tun sies nicht.
Also irgendwie bekomm ich das in Home Assistant nicht zum laufen. Könnte mir jemand mal ne richtige Starthilfe geben? Ausgangspunkt ist: HASSIO: neueste Version Ahoy: 0.5.15 MQTT: ist verbunden HASSIO: unter Mosquitto broker bei "zuhören" werden mir alle Daten vom HM-600 Angezeigt. Wie gehts für mich konkret weiter, ich wurstel da jetzt seit 3-4 Tagen abends herum und langsam nervt es nur noch.
:
Bearbeitet durch User
jnz schrieb: > Danke Johannes für den eindeutigen Beweis, das die 1041TSUN prinzipiell > zur Kommunikation zu bewegen sind. Wenn jemand mal testen will: https://github.com/derFrickler/DTUsimMI1x00-Hoymiles kompiliert und flasht mit platformio. Es muss nur die secrets.h angepasst werden. Und falls mqtt gewünscht noch die Adresse des brokers in der mqtt.h
Johannes schrieb: > jnz schrieb: >> Danke Johannes für den eindeutigen Beweis, das die 1041TSUN prinzipiell >> zur Kommunikation zu bewegen sind. > > Wenn jemand mal testen will: > https://github.com/derFrickler/DTUsimMI1x00-Hoymiles > > kompiliert und flasht mit platformio. > Es muss nur die secrets.h angepasst werden. > Und falls mqtt gewünscht noch die Adresse des brokers in der mqtt.h Wow, das sieht cool aus, und dein C-Kenntnis-Level ist eindeutig besser wie meiner! Zwischenzeitlich habe ich auch noch etwas am "Original" für die MI-Varianten rumgespielt. Die angehängte Version kann: - Das Model bzw. auch die Anzahl der PV-Eingänge anhand der Seriennummer erkennen (der TSOL-800 müßte eigentlich 2 Eingänge haben, oder?). - Die Analyse der "normalen" Messages erfolgt über eine einzige Routine - Es wird nicht strikt abwechselnd angefragt, sondern immer der nächste noch fehlende Datenpunkt (auch bei dem 1500-er) - Es wird TX- und RX-seitig "gehopt", wobei der RX-Channel immer 1/2 Periode hinter TX herhinkt. Effektiv gesendet wird bei isTime2Send() dann immer erst, wenn der RX-Channel "optimal" für den WR ist; solange nicht klar ist, ob das der Fall ist, wird nach ein paar Fehlversuchen dann zum nächsten gewechselt. Hatte eigentlich gehofft, dass es mit dieser Methodik dann easy wäre, die Status-Messages abzufangen - effektiv geklappt hat das aber leider nicht, ohne dass ich bisher draufgekommen wäre, an was es hängt. Andererseits "findet" der ESP nach dem Start recht schnell einen Kanal, auf dem der WR reagiert und bekommt dann "zumindest" die mAn. wichtigeren Leistungsdaten auch zeitnah zu jedem neuen "Zyklus" ermittelt. @derFrickler: Die ersten beiden Punkte wären vermutlich recht einfach in deinen Code zu übernehmen. Ob es sinnvoll ist, das ganze irgendwie "zyklisch" anzulegen (nach x Sekunden wird alles wieder gelöscht und von vorne begonnen), müßte man ggf. diskutieren. Ich wollte (vor dem Hintergrund der bei den ersten Versuchen eher "löchrigen" empfangenen Daten) mit dieser Methode absichern, dass einerseits (ohne Limitierung) keine "Altdaten" ewig mitgeschleift werden, und andererseits optimalerweise der WR nicht "ständig" nach updates gefragt wird, ohne dass sich jemand für "Zwischenergebnisse" interessiert (anstehender MQTT-Versand oä.).
Jörg R. schrieb: > Das Model bzw. auch die Anzahl der PV-Eingänge anhand der Seriennummer > erkennen (der TSOL-800 müßte eigentlich 2 Eingänge haben, oder?). Korrekt, habe 1041635xxxxx mit 2 Eingängen, TSOL M800, DE auf 600 W gedrosselt.
Jörg R. schrieb: > Wow, das sieht cool aus, und dein C-Kenntnis-Level ist eindeutig besser > wie meiner! Och,m ich habe da auch nur rumgestümpert, mein C is auch nicht doll. wollte es nur sauber im git haben und eben mit platformio. > Zwischenzeitlich habe ich auch noch etwas am "Original" für die > MI-Varianten rumgespielt. Sehr cool, schaue ich mir an, denke das ich meine paar Änderungen da auch einfach einbauen kann. Wenn du willst kannst du danach mal mein repository versuchen, ist mit platformio und VSCode doch deutlich komfortabler als mit Arduino IDE. Das mit dem Fehlende anfragen ist prima, idealerweise hätte man so einen kompletten Datensatz und könnte den komplett als ein objekt per mqtt verschicken. Die Limitierung habe ich beim TSUN noch garnicht getestet. meiner ist auch ein TSOL M800, DE auf 600W limitiert. Wäre mal interessant ob man die 600W auch mit den max 800W möglichen überschreiben kann ;_) Gruß Johannes
Johannes schrieb: > Ich hab das Repo von Ziyat gefunden: > https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles > Mit dem code in der zip und nach umstellen auf MI600 und bekome ich > jetzt tatsächlich Daten vom TSUN TSOL-M800 mit 1041er Seriennummer in > der Konsole. Vielen Dank schonmal. das ist erfreulich! damit ist die funktionsfaehigkeit für den MI600 auch getestet. ich sehe auf dem bild, dass die status meldungen (3 = betrieb normal) auch durch kommen, super! @Jörg R warum die status meldungen bei dir nicht auf anhieb funktioniert hat?? ich habe bei einer neuen version (0.1.6) die PV checks mit einem timer versehen, nach dem ablauf wird die PV daten neue gesammelt. und es gibt div. andere aenderungen, auch fixe limitierung. bei mir geht es bei der definition v. NRofPV um die anzahl der tatsaechlich angeschlossenen PV's und nicht um die anzahl der wr-ports, damit sammele ich nur die angeschlossenen PV daten.
Hallo zusammen, zwischenzeitlich habe ich auch gesehen, dass es ein update im Repo von Ziyat T. gab, und wohl aus diesem Grund der Code so aufgeräumt aussieht, sorry für das Mißverständnis. Es wäre m.E. hilfreich, wenn wir dazu übergehen könnten, den Code nicht als Zip im repo zu verwalten, dann wird es transparenter, was wo (ggf. warum) geändert wurde. Ziyat T. schrieb: > @Jörg R > warum die status meldungen bei dir nicht auf anhieb funktioniert hat?? Ich habe gestern dann noch eine firmware mit Hilfe von Johannes V0.1.5 gebastelt, die seit heute morgen auf meinem Haupt-ESP werkelt. Die hat das Problem nicht, da kommen auch die 03-er-Messages durch. Dieses Problem wird also durch meine Versuche verursacht, die Sende- und Empfangskanäle voneinander abhängig zu takten. Insgesamt ist es in der V0.1.5 aber seltsam, dass die Zahl der "Treffer" (gesendete Anfragen mit zeithaher Antwort) zur Zahl der "Fehlschüsse" starkt über der Zeit variiert, auch was das Verhältnis der 03-er zu den PV-Daten bzw. 89- zu 91-Messages betrifft. Festzuhalten bleibt aber, dass das gefühlt die beste Version ist, die ich bisher gesehen habe, auch was den MQTT-Teil betrifft. Ad MQTT noch: die Daten kommen auch da eher ungleichmäßig, der JSON-Teil an sich gefällt mir auch sehr gut, über die Nomenklatur sollte man m.E. nochmal reden (auch was die Single-Topics angeht), wobei mich selbst das relativ wenig kratzt, ich benenne einfach in FHEM um... Was aber bei Johannes Version noch nicht schön ist: da wird der json-Topic irgendwie anders ermittelt als der Rest, das wirkt wie ein Fremdkörper... > ich habe bei einer neuen version (0.1.6) die PV checks mit einem timer > versehen, nach dem ablauf wird die PV daten neue gesammelt. und es gibt > div. andere aenderungen, auch fixe limitierung. Ich werde dann auf alle Fälle dann diese Fassung als weitere Basis nehmen, habe aber meinerseit ein paar kleinere Vorschläge, die es neuen Usern einfacher machen würden, das ganze auf ihre Bedürfnisse anzupassen. Wäre klasse, wenn wir da irgendwie einen Weg finden könnten, dass das geht, ohne dass jeder bei jeder Änderung irgendwo wieder erst mal ein diff drüberlaufen lassen müßte... > bei mir geht es bei der definition v. NRofPV um die anzahl der > tatsaechlich angeschlossenen PV's und nicht um die anzahl der wr-ports, > damit sammele ich nur die angeschlossenen PV daten. Ah, ja, da war noch was... Wie wäre es, den Teil in die userConfig zu übernehmen, aber optional zu machen? Also: wer es braucht, weil er künstlich limitieren will, kann das setzen, wer es nicht setzt, bekommt "ifdef" einen (korrekten) Automatismus? Ziel sollte ja sein, dass man als "experienced user" alles mögliche einstellen kann, aber als "Gelegenheitscompiler" (bzw. mittelfristig ahoy-etc.-User) alles "mundgerecht" vorbereitet bekommt.
Ja, code direkt im GIT wäre klasse, dann kann man auch diffs machen und mergen. Die Sache mit dem JSON mqtt war auch nur ein schneller Versuch es bei mir in die bestehende Infrastruktur mit Tasmota/Node-Red/Influx einzubinden, hab mich bei der Struktur und Nomenklatur am Tasmota orientiert - weil ich das gewohnt bin. Ja, generell wäre es sinnvoll alle Settings wie Serial, Wifi, mqtt Server, Topic(s), WR Typ etc.. in einer Config zu haben. Hier hatte scheinbar auch schon jemand angefangen das umzusetzten: https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles/blob/21bce89b41a921d3743ff0c941421eed46b917b5/NRF24_SendRcvMIesp/SettingsCheckThisFirstOutAndChangeName.h#L107 Mein Traum wäre ja das ganze integriert in Tasmota zu haben, aber das zu machen ist mir zu aufwendig. Bin gespannt wie es weitergeht, auf jeden Fall schon mal vielen Dank, hab jetzt nach 2 Jahren Betrieb auch mal einzelne Daten was die beiden Panels wann bringen. Wenn der Rest soweit steht kann ich gerne den MQTT Teil nochmal anpassen so das er besser integriert und configurierbar ist. Es scheint da auch noch ein problem zu geben das er keinen Reconnect zum broker macht wenn der mal weg war.
:
Bearbeitet durch User
Johannes schrieb: > Hier hatte > scheinbar auch schon jemand angefangen das umzusetzten: > https://github.com/Ziyatoe/DTUsimMI1x00-Hoymiles/blob/21bce89b41a921d3743ff0c941421eed46b917b5/NRF24_SendRcvMIesp/SettingsCheckThisFirstOutAndChangeName.h#L107 Na ja, "jemand" war meinereiner, über dasselbe Thema stolpere ich bei jeder Anpassung an mqtt.h - meine IP-Adressen sind einfach anders, und es ist ausgesprochen lästig, das jedesmal wieder "zurückdrehen" zu müssen... > Wenn der Rest soweit steht kann ich gerne den MQTT Teil nochmal anpassen > so das er besser integriert und configurierbar ist. Es scheint da auch > noch ein problem zu geben das er keinen Reconnect zum broker macht wenn > der mal weg war. Die Benennungen im JSON finde ich eigentlich besser als die single-Varianten, und wenn sich da schon jemand anderes an anderer Stelle den Kopf zerbrochen hat, kann/darf das m.E. gerne so bleiben - ich kann für mich ja das so überleiten, dass die Benennung dem "klassischen" Muster entspricht, kein Problem, nur (einmaliger) Aufwand. (Bei mir geht es auch darum, das ggf. für andere FHEM-User vorzubereiten, damit die nicht ihrerseits irgendwelche historisch gewachsenen Datenstrukturen anpassen müssen). Nur die Topic-Benennung ist da "schräg", und doppelt (single+JSON-verpackt) braucht man es eigentlich auch nicht. Aber das ist eher sowas wie der Feinschliff...
:
Bearbeitet durch User
@Jörg R. @Johannes (derfrickler) die von mir verwendeten mqtt topics sind so entstanden, weil ich schon seit einem jahr meine DTU-Pro und DTSU666 mit pymodbus steuere und die daten auf nodered presentiere, darum musste ich die gleichen namen verwenden, so kann ich einfach umschalten. >Ja, generell wäre es sinnvoll alle Settings wie Serial, Wifi, mqtt >Server, Topic(s), WR Typ etc.. in einer Config zu haben. klar und einverstanden, meiste sind jetzt 0.1.6 im settings.h, den rest werde ich auch zügeln. > Es scheint da auch noch ein problem zu geben das er keinen Reconnect zum > broker macht wenn der mal weg war. das kann ich nicht bestaetigen > Wie wäre es, den Teil in die userConfig zu übernehmen, aber optional zu >machen? > Also: wer es braucht, weil er künstlich limitieren will, kann das >setzen, wer es nicht setzt, bekommt "ifdef" einen (korrekten) > Automatismus? im settings.h kann man definieren ob fix limitiert oder zeroexport oder gar nicht >Es wäre m.E. hilfreich, wenn wir dazu übergehen könnten, den Code nicht >als Zip im repo zu verwalten, dann wird es transparenter, was wo (ggf. >warum) geändert wurde. ich werde die V0.1.6 files einzeln uploaden
:
Bearbeitet durch User
Ziyat T. schrieb: > ich werde die V0.1.6 files einzeln uploaden Thx, der erste Patch ist eingereicht (automatische Erkennung von Type und NRofPV (letzteres abschaltbar)). Danke auch für's Zusammenführen der ganzen Einstellungen, das ist jetzt wirklich übersichtlich! Funktioniert soweit ganz gut, an der "falschen" Empfangsstelle hatte ich allerdings erst gar keine Sts-Messages, und die Web-Seite kann man nicht aufrufen. > die von mir verwendeten mqtt topics sind so entstanden, [...] Volles Verständnis, (zumindest erst mal) die Kompabilität beizubehalten ist für mich völlig ok. Ändern können wir dann immer noch, wenn alles soweit steht, wobei ein optionaler tieferer sub-Topic als ergänzung schon hilfreich wäre, und darauf, dass Johannes wieder die JSON-Option einbaut, freue ich mich schon jetzt... grins >> Es scheint da auch noch ein problem zu geben das er keinen Reconnect zum >> broker macht wenn der mal weg war. > > das kann ich nicht bestaetigen Ist vielleicht "Broker"-abhängig. hab's (mit FHEM-MQTT2_SERVER) noch nicht getestet, bei Gelegenheit versuche ich das mal (ggf. auch mit Mosquitto). > im settings.h kann man definieren ob fix limitiert oder zeroexport oder > gar nicht Vermutlich irritiert mich das "one for all"-Konzept an dieser Stelle etwas. Für's Plausibilisieren fand ich es hilfreich, den Grid-Wert aus dem vorgeschalteten Aktor zu sehen. Vielleicht kann man das dahingehend umstellen, dass es einen getrennten MQTT-Topic für's Aktivieren gibt? Andererseits: für mich tut es die aktuelle Lösung auch, nachdem mir klarer ist, wie die Zusammenhänge sind. THX jedenfalls für den klasse Support!
:
Bearbeitet durch User
Hallo Sören, ich bin recht im Thema Home Assistant und kann ggf. helfen. Was genau fehlt dir? P.S. Danke für dieses super Projekt und all eure Mühen!! Mein NodeMCU mit Empfänger ist seit gestern Abend verlötet und in einem Case, leider werden meine Panels erst im Oktober geliefert... :( ;)
Klaus schrieb: > Hat eigentlich jemand mal sowas wie die oberste > Spannungsgrenzabschaltung bei 60V gesehen? Bei mir steigt die Spannung > morgens manchmal zu heftig an und ich steht kurz auf 65V was zu einem > Totalausfall für betreffenden Tag führt. Ich hätte Interesse diesen Wert > auf 70V zu kriegen. Aushalten tun es die Geräte, bloß wollen tun sies > nicht. Also hier an meinem Labor Netzteil geht er bei ca 59V an wenn ich von 60V+ komme. Mich würde der betrieb bei 61V interessieren (18S lifepo4), aber glaube das wird eher nichts.
Jörg R. schrieb: > Thx, der erste Patch ist eingereicht (automatische Erkennung von Type > und NRofPV (letzteres abschaltbar)). ich aendere noch weitere dinge, deine idee mit der "automatische erkennung" werde ich, etwas geandert, in die neue version übernehmen, danke! > Funktioniert soweit ganz gut, an der "falschen" Empfangsstelle hatte ich > allerdings erst gar keine Sts-Messages, und die Web-Seite kann man nicht > aufrufen. setupWebServer() war faelschlicherweise kommentiert und ausser betrieb ;-) > schon hilfreich wäre, und darauf, dass Johannes wieder die JSON-Option > einbaut, freue ich mich schon jetzt... *grins* diese JSON scheint ja unentbehrlich sein;-) ich überlege wie ich beide möglichkeiten über settings anbieten könnte
Ziyat T. schrieb: > ich aendere noch weitere dinge, Gerne! Ist ja nur ein (getesteter) Vorschlag. Falls Du auch einen Vorschlag haben möchtest für die Logik "frage zuerst erst mal nach den Dingen, die noch nicht da sind": Einfach melden. Dieses "ungeregelte Dauerfeuer" bei den Anfragen ist mir einfach suspekt, aber anscheinend ist das halt (zumindest mit Einschränkungen) wohl so erforderlich...? Ansonsten enthält die neulich angehänge .ino auch noch einen "Einheitscode" für die Auswertung der Data-Messages (36-39 und 89/91; es wird einfach der hintere Bereich ausgelassen, wenn nicht MI1500). Ist vielleicht übersichtlicher, wenn man das irgendwann in eine "Klasse" umbauen will? (dto, was Vorschlag angeht). > setupWebServer() war faelschlicherweise kommentiert und ausser betrieb > ;-) lach, dann brauche ich nicht mehr suchen... > diese JSON scheint ja unentbehrlich sein;-) "unentbehrlich" ist vielleicht etwas dick aufgetragen, aber in FHEM ist die Verarbeitung von "Mehrfachinfos" schlicht effizienter, wenn alles auf einmal kommt statt tröpfchenweise, weil für jedes Tröpfchen jedesmal die komplette Eventverarbeitungsloop angestoßen wird (und wir hatten leider einige Fälle, in denen die aufgrund der konkreten Konfiguration der betreffenden User "etwas ineffizient" war, was dann in Summe zu (vermeidbaren) Problemen führt). Ein Teil der vermeidbaren "Zutaten" für derartige Probleme ist eben die "Umverpackung" in JSON, that's all, weil dann die Eventverarbeitung pro JSON durchgeführt wird - egal, ob da 1 Datenpunkt drin ist oder 10.000e.
Ziyat T. schrieb: > diese JSON scheint ja unentbehrlich sein;-) ich überlege wie ich beide > möglichkeiten über settings anbieten könnte Ich habs jetzt so gelöst: https://github.com/derFrickler/DTUsimMI1x00-Hoymiles/blob/main/Settings.h#L70 https://github.com/derFrickler/DTUsimMI1x00-Hoymiles/blob/main/NRF24_DTUMIesp.ino#L1104 Senden der JSON Nachricht is in ne Funktion gepackt. Beim Webserver wird nun auch noch die anzahl der Panels berücksichtigt: https://github.com/derFrickler/DTUsimMI1x00-Hoymiles/commit/fd499d738297c8a7b75d5c210463781380abf16d#diff-c6315fa14b190df4199812d6dec67688aa0cc3c86f214fcf4e60cf8698359ac4
Angehängte Dateien:
-
IMG_1670.JPG
170 KB -
img_001.jpg
64 KB
Hallo, folgendes Problem sobald ich meinen D1 ESP8266 Mini (ahoy_v0.5.15) mit dem nRF24L01+ PA+LNA verbinde bleibt alles aus. Erst wenn ich das nRF24L01+ entferne läuft der D1 ESP8266 Mini,so dass ich mich ins ESP AHOY WiFi-Netzwerk einloggen kann. Es scheint ein Problem mit dem Strom zu sein. Verbunden wurden die Module wie auf Github gezeigt. Wäre Prima, wenn mir jemand ein paar Tipps geben könnte Anbei mal ein Foto von meinem Setup:
Johannes schrieb: > Senden der JSON Nachricht is in ne Funktion gepackt. werde so übernehmen, auch die definition im settings.h > Beim Webserver wird nun auch noch die anzahl der Panels berücksichtigt: gute idee! danke
Finde ich auch gut so! Wenn ich noch Wünsche äußern darf: - der subsribe-Topic sollte auch von der JSON-Variante abhängig sein (damit man wenigstens die "Adresse" im Topic drin hat) - Falls jemand weiß, wie man einen funktionierenden "last will" bastelt, wäre das nochmal einen (ebenfalls von JSON/nicht-JSON abhängigen?) Topic wert... - was ggf. noch fehlt (?), wäre die dynamische Ermittlung der Maximalleistung des WR (für MI600 eigentlich (?) 3*300W, Settings.h, zeroexport PVPOWER) Ansonsten sind wir m.E. ziemlich nahe dran, dass wir "Teil 1" abgeschlossen haben (funktionsfähigen Code für einen "Standalone"-WR). Für "Teil 2" (Integration in die Komplettfirmware) fehlt mir allerdings im Moment weiter der Durchblick, wie man das analog zu den HM-Modellen umsetzen könnte...
Andi schrieb: > sobald ich meinen D1 ESP8266 Mini (ahoy_v0.5.15) mit > dem nRF24L01+ PA+LNA verbinde bleibt alles aus. Ich schlage folgendes Vorgehen vor: - Kontrollieren, ob es zwischen den + und - Pins (rot - schwarz) am nRF24L01 sichtbar eine direkte Lötverbindung gibt, ggf. vorsichtig nachlöten, - nur + und - vom nRF24L01 am Wemos mini D1 anschließen: Bleibt dann der Wemos betriebsfähig? - Falls nein: nRF24L01 wahrscheinlich "defekt".
Jörg R. schrieb: > Wenn ich noch Wünsche äußern darf: > - der subsribe-Topic sollte auch von der JSON-Variante abhängig sein > (damit man wenigstens die "Adresse" im Topic drin hat) > - Falls jemand weiß, wie man einen funktionierenden "last will" bastelt, > wäre das nochmal einen (ebenfalls von JSON/nicht-JSON abhängigen?) Topic > wert... bisher hab ich keine erfahrung mit JSON, kann ev. Johannes (derfrickler) uns helfen > > - was ggf. noch fehlt (?), wäre die dynamische Ermittlung der > Maximalleistung des WR (für MI600 eigentlich (?) 3*300W, Settings.h, > zeroexport PVPOWER) meinst du für MI600 2*300W, und bei MI300, 1*300?
Ziyat T. schrieb: > Jörg R. schrieb: > >> Wenn ich noch Wünsche äußern darf: >> - der subsribe-Topic sollte auch von der JSON-Variante abhängig sein >> (damit man wenigstens die "Adresse" im Topic drin hat) >> - Falls jemand weiß, wie man einen funktionierenden "last will" bastelt, >> wäre das nochmal einen (ebenfalls von JSON/nicht-JSON abhängigen?) Topic >> wert... > bisher hab ich keine erfahrung mit JSON, kann ev. Johannes (derfrickler) > uns helfen In mqtt.h habe ich bzgl. des ersten Punkts mal Folgendes eingefügt, das scheint zu funktionieren:
1 | #ifdef SENDJSON
|
2 | String GRID_PSTR = String(MQTTclientid)+"/ImpExpW"; //topic for reading the gridpower |
3 | const char *GRID_P = GRID_PSTR.c_str(); |
4 | #else
|
5 | static char GRID_P[] = "ImpExpW"; //topic for reading the gridpower |
6 | #endif
|
last will hat nichts mit JSON zu tun, ist was MQTT-spezifisches: https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/ (ist wohl grade offline?) und http://www.steves-internet-guide.com/mqtt-last-will-example/ >> - was ggf. noch fehlt (?), wäre die dynamische Ermittlung der >> Maximalleistung des WR (für MI600 eigentlich (?) 3*300W, Settings.h, >> zeroexport PVPOWER) > meinst du für MI600 2*300W, und bei MI300, 1*300? Die Berechnung ist da und steht wohl auch an der richtigen Stelle, aber im Moment wird bei allen Modellen 350 verwendet. Müßte mal ausprobieren, ob der MI600 auch 700W liefern würde? (Die Frage kam in ähnlicher Gestalt hier schon ein paar Mal, der WR müßte es abkönnen). Weiß nicht, ob es von den Gen-2-Geräten auch 4*300W gibt (MI1200?) Nachtrag: Mit FHEM-MQTT2_SERVER ebenfalls wohl kein reconnect, und der Code von Johannes scheint auch an einer anderen Stelle etwas anders zu "ticken": Mit dem wird in FHEM ein Reading angezeigt, mit den "subscriptions" des ESP. Das fehlt (es funktioniert aber, der Server muss die also kennen). Die Uhrzeit in der WEB-Abzeige war vorhin auch seltsam (2036), jetzt paßt es wieder? (habe zwischendurch nur die NRofPV in web....h eingetragen), die auch an einer 2. Stelle weiter unten auftaucht). Generell neige ich weiter dazu, zwei subscribe-Topics zu nehmen, und die auf einen "set"-Teiltopic umzubiegen (für "grid" und "limit"). Vorschlag dazu kommt bei Gelegenheit.
:
Bearbeitet durch User
Andi schrieb: > Wäre Prima, wenn mir jemand ein paar Tipps geben könnte Die PA+LNA-Variante zieht ziemlich viel Strom, ein (bei unshielded: besser 2) Kondensator ist (spätestens da) Pflicht! Evtl. reicht auch der auf dem ESP verbaute Spannungswandler für 3.3V nicht aus.
:
Bearbeitet durch User
meine Einstiegsprobleme waren: - kompilieren des ESP Tools warf viele Fehler: meine Espressif Plattform für ESP8266 war viel zu alt, mit aktueller 4.x dann kein Problem - die Verdrahtung auf dem Fritzing Bild passt nicht zur Defaultbelegung von CS,CE und IRQ. Kann im Setup im Webinterface angepasst werden - ich hatte erst ein nRF Modul mit 10 pins und das falsch angeschlossen. Bei den 10 pin Modulen gibt es min. zwei Varianten. Sollte mittlerweile kein Problem bei neuen Komponenten sein, mein Waveshare Modul wird nicht mehr produziert und war aus einem älteren Set. Mit einem anderen Modul mit PA ging es dann, ich habe aber auch einen zusätzlichen Elko angelötet. - In der Statistik wurden viele Fehler gezählt, es wurde versucht zwei nicht vorhandene WR abzufragen. Vor der Eingabe der WR Daten erstmal im Setup 'Erase Settings' auslösen, dann sind die Defaults ordentlich gesetzt. - MQTT Server wurde nicht über Namen gefunden (liegt eher an meinem Netzwerk), mit IP Adresse ging es. Ich benutze ioBroker, da den mqtt-client Adpater installieren und alle Werte sind da. Danke für das schöne Projekt, damit ist das Logging wirklich einfach. Und die Hilfe im Discord Channel ist Top.
:
Bearbeitet durch User
Jörg R. schrieb: >> Jörg R. schrieb: >> > #ifdef SENDJSON > String GRID_PSTR = String(MQTTclientid)+"/ImpExpW"; > //topic for reading the gridpower > const char *GRID_P = GRID_PSTR.c_str(); > #else > static char GRID_P[] = "ImpExpW"; //topic for reading > the gridpower > #endif habe so übernommen, danke > Die Berechnung ist da und steht wohl auch an der richtigen Stelle, aber > im Moment wird bei allen Modellen 350 verwendet. > Müßte mal ausprobieren, ob der MI600 auch 700W liefern würde? (Die Frage > kam in ähnlicher Gestalt hier schon ein paar Mal, der WR müßte es > abkönnen). > Weiß nicht, ob es von den Gen-2-Geräten auch 4*300W gibt (MI1200?) jetzt geht es sowohl, auch. wenn die PVportPOWER nicht angegeben wird, wird sie ermittelt
Danke für die Tipps ( Jörg & Günter). Hab alles mal nachgelötet. Es hat sich herausgestellt, dass GND - Pol nicht richtig angelötet war. jetzt geht alles. Eine Frage habe ich allerdings noch. Im Ahoi-SETUP stehen unter dem Reiter Inverter - 3 Einträge: Inverter 0 - Inverter 1 - Inverter 2. Unter Inverter 1 habe ich die SN meines Wechselrichters eingetragen. Im Menü Visualization werden mir allerdings auch die anderen beiden Inverter 0 & Inverter 2 als Leer angezeigt. Kann man die irgendwie entfernen ?
:
Bearbeitet durch User
Schön, dass das jetzt geklappt hat, den/die Kondensatoren solltest du trotzdem sicherheitshalber noch einfügen. Für den Rest kann ich wenig beitragen, da ahoy für die alten Modelle noch nicht läuft. Vielleicht reicht es, den WR als inverter 0 einzutragen und die anderen leer zu lassen, sonst musst du ggf. die maximale Inverterzahl anpassen und selbst den Compiler anwerfen. Dann kannst du mit dem "großen" nRF evtl. auch gleich den PA-Level nach unten nehmen.
Erase Settings und dann nochmal neu eintragen.
Oha, perfekt. Jetzt wird alles richtig angezeigt. Wofür steht im SETUP Reiter der Eintrag: Radio (NRF24L01+) - Amplifier Power Level ? Was wäre da der optimale Eintrag für einen D1 ESP8266 Mini (ahoy_v0.5.15) mit dem nRF24L01+ PA+LNA ?
Ich habe es hier als Testaufbau und nur ca. 4 m Abstand, da reicht min. Ich würde es auch nur so stark einstellen wie nötig um die Daten zu empfangen. Wifi und ZigBee kloppen sich hier auch schon auf 2,4 GHz.
Ich habe heute einen TSUN TSOL-M800(DE) mit 11418 beginnender Seriennummer in Betrieb genommen. Die Kommunikation mit Ahoy 0.5.15 hat auf Anhieb funktioniert!
Hallo und schönen Sonntag. Habe mich bis hier durchgeschlagen, Mein BKW mit 2x350W + HM800 und Ahoy-DTU läuft. Aber was ich nicht kapiere ist die Geschichte mit den Daten, die se Darstellung was der WR den Tag über so treibt. Diese MQTT-Sache, wer oder wo find ich mal ne Erklärung oder Beschreibung , die auch verständlich ist. Jeder scheint irgend ein anderen Broker zu verwenden. Was brauch ich um z.B. die Daten auf meinem Handy(Android) zu sehen ? Danke schon mal.
du brauchst einen Datensammler. Der Broker, z.B. mosquitto, verteilt nur die Daten. Beliebige Clients können dem Broker Daten liefern, andere Clients können anmelden diese Daten haben zu wollen. Lieferant hast du mit Ahoy, jetzt fehlt ein Rechner auf dem der MQTT Broker läuft, ein Stück SW das die Daten abonniert und in eine Datenbank schiebt, und dann eine GUI die aus der DB liest und darstellt. Das macht SW wie ioBroker, FHEM, HomeAssistant lokal oder man könnte eine Cloud Lösung suchen. Der Broker selber sammelt keine Daten, der verteilt nur 1:1 den Eingang (Publisher) and die Ausgänge (Subscriber).
:
Bearbeitet durch User
Unfassbar: https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-hardware-fuer-ahoy-projekt-hm300-hm400-hm600-hm1500/2201223140-168-5178 Da hat doch schon mal jemand eine FAQ begonnen, wäre es nicht sinnig,um so etwas zu vermeiden, diese in jedem Github repo zu verlinken? Gruß
Hallo alle miteinander, Ich bin jetzt auch seit knapp einer Woche Besitzer eines BKW mit einem HM1500. War natürlich zu geizig mir eine DTU zu kaufen und bin nach etwas Suchen hier auf das Projekt gestoßen. Habe mit auch die ca. 80 ersten Posts durchgelesen, aber irgendwann wurde es recht anstrengend dem ganzen zu folgen. Gibt es den eine Gesamtanleitung zum Projekt ( ja, könnte es auf Ebay Kleinanzeigen kaufen, weiß nur nicht ob das sinnig ist und gewollt). Oder kann mir jemand die Stelle/Stellen im Postverlauf nennen, die wichtig sind. Habe von programmieren selbst keine Ahnung, der Elektronikpart usw. ist kein Problem, nur bei Codezeilen und ähnlichem bin ich raus. Wäre super, wenn mir da jemand helfen könnte, damit ich weiß was meine Ablage überhaupt bringt und ich das ganze per MQTT in HomeAssistant einbinden kann. Gruß Jens
Jens schrieb: > Oder kann mir jemand die Stelle/Stellen im Postverlauf nennen, die > wichtig sind. > > > Gruß Jens Hi, 1. Hardware: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/README.md#esp8266-wiring-example 2. Software: https://github.com/grindylow/ahoy/releases --> dort das jeweils aktuelle zip und darin die *.bin Datei. Dann: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/README.md#flash-the-firmware-on-your-ahoy-dtu-hardware Grüße
Hi, teste gerade die 0.5.16 Wurde das automatische erstellen von Datenpunkten im Mqtt Broker hier devcontrol schon eingepflegt ?
Wow, dass ging flott. Vielen lieben Dank. Dann wurschtel ich mich da mal durch.
Hallo zusammen, mal eine "verrückte" Idee ... Wäre es irgendwie möglich die Signalqualität darzustellen ? Laienhaft ausgedrückt vielleicht über die Signallaufzeit ähnlich Ping ?
Devcontrol Datenpunkte wurden bei mir nicht angelegt. Habe mit einem Mqtt Explorer die Datenpunkt per Hand angelegt und Powerlimit vorgegeben, lief.
Dirk Z. schrieb: > Wäre es irgendwie möglich > die Signalqualität darzustellen ? Dazu müsste der nRF Chip die Möglichkeit die RSSI auszulesen, hat er aber nicht, zumindest nicht dokumentiert.
Hat hier vielleicht jemand zufällig die 0.5.15 Version von Ahoy? Die neu 0.5.16 war eine "Verschlimmbesserung" und die 0.5.15 gibt es nicht mehr zum download.
Also bei mir läuft die 5.16 auf 8266 und ESP32 stabil anbei die 5.15
:
Bearbeitet durch User
Danke dir. Die Leistungslimitierung wird nicht mehr richtig angezeigt.
tatsächlich betreibe ihn ohne Leistungslimitierung deshalb nicht afgefallen
Rene M. schrieb: > Danke dir. > Die Leistungslimitierung wird nicht mehr richtig angezeigt. Ja das stimmt. In der Weboberfläche passt das noch nicht. Vorher 0.5.15 wurde einfach immer der Sollwert angezeigt egal ob der Umrichter das einstellte oder nicht. Jetzt ab 0.5.16 wird das Limit auf welches der WR regelt per Abfrage ermittelt und ausgegeben (also der Istwert): a) auf der web Oberfläche (ja läuft im release 0.5.16 nicht, aber in der dev-Version, siehe github) b) auf dem MQTT topic <DEINTOPIC>/ch0/PowerLimit beides IMMER in % Grüße
@Andreas Ich limitiere mit absoluten Watt Angaben. Das funktioniert auch. Nur bleibt im Webview die Limitierung auf 100% stehen, obwohl ich den 1500er Wechselrichter auf 600W limitiere. Hebe ich die Limitierung auf kommt irgendwann einmal später plötzlich im Webview 33%. Es gibt ja jetzt auch ein File für den Esp32. Wie sieht es da mit der Verkabelung aus? Gleich wie bei OpenDTU?
Hi Leute! Mega danke für eure ganze Arbeit, find ich richtig geil :) Ne Möglichkeit oder die Idee den nrF Chip direkt auf dem WR mit anderer FW zu flashen gibt es nicht oder?
Bei mir läuft jetzt seit 36 Tagen OpenDtu ohne unterbrechung aus einem ESP32. Leider lief die Ahoy immern nur max. 1 Tag bei mir. Da ich mit den Daten der OpenDtu meinen Kühllüfter regele, möchte ich das ungern unterbrechen. Geht es auch, das ich mit OpenDtu und AhoyDtu gleichzeitig auf den WR zugreifen kann oder beißt sich das dann ? So könnte ich die neue Ahoy testen, ohne mein laufendes System zu unterbrechen.
Hallo, was bedeuten eigentlich die Werte: Pct P_ACr
Hans W. schrieb: > Geht es auch, das ich mit OpenDtu und AhoyDtu gleichzeitig auf den WR > zugreifen kann oder beißt sich das dann ? Ich würde vermuten, dass sich das beißt: https://github.com/tbnobody/OpenDTU/issues/26
:
Wiederhergestellt durch Admin
Beitrag #7183066 wurde von einem Moderator gelöscht.
Beitrag #7183069 wurde von einem Moderator gelöscht.
Hans W. schrieb: > Geht es auch, das ich mit OpenDtu und AhoyDtu gleichzeitig auf den WR > zugreifen kann oder beißt sich das dann ? Nein die zwei stören sich dann. Am Anfang klappte es bei mir mit ahoy auch nie. Aber seit 0.5. irgendwas läuft das Teil auch einwandfrei. Hatte am Anfang auch immer nur OpenDTU. Momentan nur ahoy. Aber ich denke oder hoffe, dass auch OpenDTU bald mit der Leistungsbegrenzung klar kommt. Zwei DTUs parallel stören sich aber, da hat man Ausfälle.
Beitrag #7183365 wurde von einem Moderator gelöscht.
M. P. schrieb: > Hallo, > > was bedeuten eigentlich die Werte: > Pct > P_ACr Für Pct habe ich keine Erklärung und konnte auch nirgendwo nur einen Hinweis darauf finden. Irgendwas mit %, die angezeigten Werte ergeben für mich aber keinen wie immer gearteten Zusammenhang zu irgendwas. Bezügl. P_ACr schien mir logisch Power-AC reactiv, also Scheinleistung, die bei diesen WR meist um die 0 herumkrebsen wird vermutlich. Dies konnte ich dann auch wo bestätigt finden. Wenn also noch jemand die Güte besäße uns Pct einzudeutschen - danke!
M. P. schrieb im Beitrag #7183365: > Sorbit schrieb: >> Vorher mal selbst nachdenken, oder hier nach bereits gegebenen Antworten >> suchen? > > Na das sagt der Richtige. > Was muss eigentlich im Leben passieren um so ein Arschloch zu werden?
Grisu schrieb: > Wenn also noch jemand die Güte besäße uns Pct einzudeutschen - danke! Ich hab folgendes gefunden: Pct: actual AC Power factor in % Quelle: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md
Danke für die Aufklärung. Das würde ja bedeuten Wirkleistung/Scheinleistung. Ja, kommt sogar hin mit aktuell Pct 99,60% bei bei P_AC 272,70W und P_ACr 21,30VAr. Die Scheinleistung (Wurzel der Quadratsumme) errechnet sich dabei zu 273,53VA, somit 272,70/273,53=99,69%. Danke auch für den Link, sowas hatte ich gesucht und nicht gefunden.
:
Bearbeitet durch User
Angehängte Dateien:
-
HM_1500A.JPG
86 KB -
HM_1500B.JPG
33 KB
Hallo, bin am verzweifeln da mein HM 1500 kein Strom mehr produziert Hatte mit der Version 04.22 funktioniert : wollte die Version 05.15 flashen, ist mir aber nicht gelungen kann es sein das bei zugriff auf den HM1500 irgend was passiert ist und dieser kein Strom mehr produziert ? Im Moment habe ich die Version 0.5.3 geflasht Kann mir vieleicht jemand Helfen ? und mir sagen wie ich das hinbekomme das der Wechselrichtet wieder Strom produzirt Vielen Dank !! Michael
Das Limit (dunkelgrüne Zeile ganz oben) scheint auf "0 Watt" eingestellt zu sein. Bitte den Eintrag im Setup überprüfen. Bei mir (HM-600) dauert es auch manchmal einige Minuten, bis der WR Strom produziert. Gut eine Minute wie im Bild ist eine kurze Zeitspanne.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, ich wollte einfach mal ordentlich Danke sagen für das großartige "Ahoy" Projekt. Top! Funktioniert nun wunderbar nach anfänglichen Startschwierigkeiten mit nicht funktionierenden NRF24L01+. So kann es aussehen, wenn man es per mqtt in den Home Assistant importiert hat. Vielen Dank! koerly
In der Tat das war der Fehler !! Habe das Limit nun auf den richtigen Wert gesetzt und nach mehreren Minuten war die Einspeisung wider da !! Vielen DANK !!!
misch schrieb: > wollte die Version 05.15 flashen Solltest vielleicht gleich die aktuelle 5.16 nehmen.
:
Bearbeitet durch User
Hi zusammen, auch von meiner Seite aus erst einmal vielen Dank für alles, was Ihr hier bisher auf die Beine gestellt habt. So ein geniales Projekt! Ich habe OpenDTU jetzt seit einigen Tagen mit einem HM-400 ausfallfrei laufen. Das einzige was mich verwirrt ist der YieldDay-Wert. Der ist immer locker 0,4 bis 0,5 kWh unter dem Tageswert des Shelly 1PM, den ich noch zur Messung nutze. Gestern z.B. 1,71 kWh OpenDTU und 2,19 kWh Shelly. Ich weiß, dass ein unkalibrierter Shelly 1PM nicht gerade präzise ist, aber SO unterschiedlich wundert mich dann doch. Oder funktioniert da was nicht richtig?
:
Bearbeitet durch User
Hängen vielleicht noch andere Geräte an dem Kreis zw. Einspeispunkt und Shelly? Wäre aber auch nur eine Erklärung, wenn die DTU mehr als der Shelly anzeigt. Mein uralter EKM265 vom Conrad (>30 Jahre alt) liefert fast exakt die selben Werte wie die Messungen aus dem HM (<1,5% Differenz). Habe ihn dazu extra umgepolt, da er nur Verbrauch und keine Einspeisung messen kann. PS: Finde es auch echt genial was hier geschaffen wurde, auch wenn ich Ahoy verwende, da die dazu nötigen Module grad greifbar waren.
:
Bearbeitet durch User
@Jörg R., Ziyat T., Johannes und JNZ, freue mich dass es nun auch für die "alte" 10er Serie der Hoymiles MI-Wechselrichter und TSUN geht. In der RF Communication protocol v6.5.xls steht folgendes zu den 0x08 und 0x11 Kommandos: 08 Collect the status and data of channel A of the terminal device (upload in two packages) 88 (status), 89 (data) 09 A-side data 89 11 Collect the status and data of channel B of the terminal device (upload in two packages) 92 (status), 91 (data) 12 B-side event Die Antwort erscheint dann wie gehabt mit 0x80|REQ_CMD Danke auch nochmal für die Erinnerung: In https://www.mikrocontroller.net/attachment/559626/Micro-inverse_system_related_product_ID_coding_rules-A3-20190712.docx steht ziemlich am Anfang was sehr Interessantes: **2. ID coding rules** **1. The first four rules** The 1st to 4th digits are the model code, among which, the "1" digit is the **product category**, and "1" represents the related products of the **micro-inverse system**. The "2~3" digit is the **product category**. At present, the related products of the micro-inversion system are: | 2-3 digit value | Product Category | Involved product model | | --- | --- | --- | | 01 | One drag series (four-core bus version) | MI-250T1, MI-300T1, MI-350T1 | | 02 | one drag series | MI-250, MI-300, MI-350, MI-250T, MI-300T, MI-350T | | 03 | One for two series (four-core bus version) | MI-500T1, MI-600T1 | | 04 | One for two HM, MI series | MI-500,MI-600, MI-700, MI-500T,MI-600T, MI-700T, HM-500,HM-600, HM-700, HM-500T,HM-600T, HM-700T | | 06 | One for four HM, MI series | MI-1000,MI-1200, MI-1500, MI-1000T,MI-1200T, MI-1500T, HM-1000,HM-1200, HM-1500, HM-1000T,HM-1200T, HM-1500T | | 16 | HM Pro one drag four series | HM-1200 Pro, HM-1500 Pro, HM-1200T Pro, HM-1500T Pro | | 0C | smart meter | Chint DDSU666, DTSU666, etc. | | 0D | Minimalist DTU | DTU-G100, DTU-W100, DTU-Lite-GPRS, DTU-Lite-WIFI | | 0E | repeater | RP-433-ICR | | 0F | DTU | DTU-MI, DTU-433, DTU-MI-GPRS, DTU-433-GPRS, DTU-MI-AR, DTU-MI-ARW, DTU-MI-GPRS-ARW, DTU-Pro-GPRS, DTU-Pro-WIFI | | 9X | Production test fixture | | ... 2. Last eight coding rules For products such as micro-inverters, DTUs, repeaters, etc., the rules are as follows: The 5th to 12th digits are the production serial number and are used as the RF communication address of the micro-inverter/DTU/repeater, among which: The "5" digit is the **year of production** (time provided by the welder), the "1" is for **2015**, and so on The "6~7" bits are the **production week** (the time provided by the welding factory), and the range is "1~52". The "8~12" bits are the pipeline coding (currently in decimal), the micro-inverter, repeater, and DTU share the same pipeline sequence, which is coded in sequence and must not be repeated, a total of 99999 bits. Ich würde Euch gerne einladen, kommt doch mal in den Discord Chat, wir haben extra einen Kanal #mi-serie eingerichtet in dem wir gerne die Integration von Eurem Code in die AhoyDTU / Bibliothek diskutieren können. Der Link dazu https://discord.gg/WzhxEY62mB ist in der Zwischenzeit auch auf https://github.com/grindylow/ahoy Für die HMS / HMT interessierten gibt es auch einen #hms-serie Kanal und ein github Issue https://github.com/grindylow/ahoy/issues/233 Sub1G Unterstützung für 3phasige HMT-1800-6T, HMT-2250-6T und HMS #233 Dieses versucht die notwendige Hardware (NRF905 ?) und den Partner Thread hier im Forum zusammen zu fügen. Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless" Wenn wir die Fragen nach einzelnen Software-Versionen hier etwas reduzieren und (wie ihr) stärker am Protokoll arbeiten, kehrt vielleicht auch beim einen oder anderen Thread Teilnehmer wieder etwas mehr Gelassenheit ein.
Danke für die Einladung, bin "da". Wäre schön, wenn Ziyat T. auch dazustoßen würde, weil ich mich bisher nicht damit beschäftigt habe, wo "im Untergrund" (also bei den h und cpp-files) eigentlich die Unterschiede zwischen HM und MI liegen. Die Zusammensetzung der Messages selbst scheint ja bis auf die Status-Messages bis Mi-600/MI-800 mehr oder weniger identisch zu sein? Und der Empfang (und/oder auch das Senden?) "muss" (ich halte das immer noch für eine komische Implementierung auf der Seite des Herstellers) wohl wirklich rollieren, damit man die Status-Messages auch bekommt. Dass zwischenzeitlich Topics da sind für die diversen Bestandteile zum Produktionsdatum, habe ich dem "list" eines FHEM-Users entnommen und mich gefragt, ob das zeitlich zufällig war... Aber ist es sinnvoll, gleich 3 Topics für diese Infos zu belegen? Und könnte man die HomeAssistant-autodiscovery per default bitte ausschalten? Jedem neuen FHEM-User zu erklären, dass er das gar nicht braucht und bitte ausschalten soll bzw. die Topics generell abschalten, ist nicht allzu erquicklich... Das soll's von meiner Seite aber zu User-Fragen zu einer speziellen Automatisierungslösung gewesen sein, diese Dinge sind anderswo m.E. in der Tat besser aufgehoben.
Hallo zusammen, wurde die HI version (habe selbst HI-600) jetzt schon testweise in das AHOI DTU eingebaut oder noch nicht?
David B. schrieb: > Hallo zusammen, > wurde die HI version (habe selbst HI-600) jetzt schon testweise in das > AHOI DTU eingebaut oder noch nicht? Die 2.Gen/Geräte sind noch nicht integriert, der "Startschuss" dürfte aber gefallen sein. Den aktuellen Stand kann man seit heute https://github.com/grindylow/ahoy/issues/258 verfolgen, und falls du selbst compilieren kannst (Arduino IDE reicht), kannst du das Repo von Ziyat T. (oder meinen fork) nehmen; da sind eigentlich nur kleine Anpassungen (in einer einzigen file) nötig (WR- und IP-Adressen etc.). (Ist dann aber nicht die Ahoy-firmware, sondern ein Klon von Hubi's Ausgangs-Code)
:
Bearbeitet durch User
okay, das werde ich machen. melde mich mit resultaten.
Ist es normal, daß nach einem FW-Update (Ahoy 0.5.16 auf 0.5.17) die Pinout-Settings verloren gehen? nRF24 war nicht mehr erreichbar (Fehlermeldung), dann in den Settings gesehen, daß alle 3 konfigurierbaren Pins D3 (GPIO0) eingetragen hatten.
:
Bearbeitet durch User
Hi David, ich hoffe, es ist ok für dich, wenn ich auf die pm hier offen antworte - das ist ein Entwicklungsthread, und es ist einfacher, wenn alle lesen können, ob bzw. welche Probleme dass es gibt. Gut ist erst mal, dass das mit dem Flashen (Files aus meinem Repo, ich nehme an, aus dem Master-Tree) geklappt hat und du Nachrichten siehst bzw. zurückbekommst. Prinzipiell ist es so, dass der WR afaik nicht von sich aus sendet, sondern von der DTU aus "eingetacktet" und abgefragt wird, was vermutlich bedeutet, dass bei dir irgendwas auf der RF-Seite optimiert werden muss. Die Klassiker: Kondensator + "optimale" Sendeleistung. Letztere ist vermutlich auf "MIN" eingestellt, was für mich als Test-Ausgangsbasis gut war, weil ich einen eher "lauten" nRF verwende. Würde also in jedem Fall den/die Kondensator/en einsetzen, und dann ggf. die Stufen nacheinander durchtesten (man kann es am Terminal im laufenden Betrieb machen, nur eben nicht zurück auf MIN). "Zu laut" ist aber auch nichts! Die jetzigen Fassungen (egal, ob von Ziyat T., oder die daraus abgeleiteten Klone von Johannes oder mir) sind die besten, die ich bisher gesehen habe, aber auch mit den Vorversionen hatte ich noch teilweise (auch im laufenden Betrieb) wechselhafte Ergebnisse mit Phasen relativ häufiger Rückmeldungen und solchen, in denen es nicht so optimal war. Daher auch die (jetzt erst mal abgebrochenen und aktuell nicht implementierten) Versuche, irgendeine Logik zu finden, nach der Sende- und Empfangskanal in Abhängigkeit zueinander ermittelt werden können... Ich will aber nicht ausschließen, dass ich bei den (wenigen) Modifikationen was kaputt gemacht habe, das den Empfang verschlechtert.
Rene M. schrieb: > Wie sieht es da mit der Verkabelung aus? Gleich wie bei OpenDTU? Ich habe meinen ESP wie folgt verkabelt und die Ahoy5.17 läuft darauf sehr stabil: NRF24 / ESP32 CSN --- G23 CE ---- G2 MO ---- G13 SCK --- G18 IRQ --- G0 MI ---- G19
Carsten B. schrieb: > Ich habe meinen ESP wie folgt verkabelt und die Ahoy5.17 läuft darauf > sehr stabil: > > NRF24 / ESP32 > CSN --- G23 > CE ---- G2 > MO ---- G13 > SCK --- G18 > IRQ --- G0 > MI ---- G19 War das die Standardbelegung? Ich habe bei mir NRF24 / ESP32 MINI CSN --- G5 CE ---- G2 MO ---- G23 SCK --- G18 IRQ --- G01 MI ---- G19 Jedoch erhalte ich bisher keine Antwort, daher bin ich hier noch am ausprobieren...
Beitrag #7185504 wurde von einem Moderator gelöscht.
Jumper schrieb: > Carsten B. schrieb: > Ich habe bei mir > NRF24 / ESP32 MINI > CSN --- G5 > CE ---- G2 > MO ---- G23 > SCK --- G18 > IRQ --- G01 > MI ---- G19 > Jedoch erhalte ich bisher keine Antwort, daher bin ich hier noch am > ausprobieren... Ich hatte das aus meiner Belegung beim ESP8266 abgeleitet. Allerdings habe ich beim Aufschrieben gestern noch einen Fehler eingebaut :-(, hier die Korrektur: NRF24 / ESP32 CSN --- G15 CE ---- G2 MO ---- G23 SCK --- G18 IRQ --- G0 MI ---- G19 Sorry für die Verwirrung...
Jörg R. schrieb: Die Klassiker: Kondensator + "optimale" > Sendeleistung. Letztere ist vermutlich auf "MIN" eingestellt, was für > mich als Test-Ausgangsbasis gut war, weil ich einen eher "lauten" nRF > verwende. Würde also in jedem Fall den/die Kondensator/en einsetzen, und > dann ggf. die Stufen nacheinander durchtesten (man kann es am Terminal > im laufenden Betrieb machen, nur eben nicht zurück auf MIN). "Zu laut" > ist aber auch nichts! > > Die jetzigen Fassungen (egal, ob von Ziyat T., oder die daraus > abgeleiteten Klone von Johannes oder mir) sind die besten, die ich > bisher gesehen habe, aber auch mit den Vorversionen hatte ich noch > teilweise (auch im laufenden Betrieb) wechselhafte Ergebnisse mit Phasen > relativ häufiger Rückmeldungen und solchen, in denen es nicht so optimal > war. Hey Jörg, ich habe den(die) Kondensatoren mal verbaut, aber bekomme noch immer keine validen Ergebnisse ausserhalb des Sniffers (sniffer output hab ich dir als PN geschickt) Benutzt habe ich den Main von Dir, habe dort PA_LEVEL = RF24_PA_HIGH auf MIN gesetzt und die Schritte durch probiert, ohne nennenswerte Ergebnisse. Habe auch die Distanz auf 30cm zwischen WR und nRF modul reduziert.
Erinnert mich etwas an die Probleme, die ich in den ersten Versionen von Ziyat auch hatte. Könnte damit zusammenhängen, dass er keinen Grid-Wert per MQTT bekommt. Habe den Teil dann nicht mehr vertieft, sondern schlicht einen Wert an die richtige Stelle gepublisht (mit retain-flag). Außerdem sehe ich grade, dass ich den "konsolidierten Code" mit den JSON-Vorschlägen von Johannes noch gar nicht im Repo habe, hole ich bei Gelegenheit nach. Im Moment ist der Topic, auf den "irgendwas" gepublisht werden sollte (ich habe dazu sicherheitshalber den 10-fachen Wert genommen, den der vorgeschaltete Aktor liefert, letztlich ist es aber nicht wichtig, solange man ZEROEXP nicht aktiviert): "ImpExpW" Und generell ist beim Funken "zu nah" auch nicht zu empfehlen. 2-3m dürfen es schon sein.
:
Bearbeitet durch User
Beitrag #7185775 wurde vom Autor gelöscht.
Hallo Zusammen, danke für die Mühen. Ich habe heute den ESP32 in Betrieb genommen mit openDTU. Wird es hier noch ein Update geben um das Limit per mqtt einzustellen? Die Werte sind auf Anhieb raus gefallen und das Auto discover im Home Assistant war sofort da. Einfach Top. Alternativ wie bekomme ich denn Ahoy auf dem ESP32 zum laufen? Einfach die Pins im source anpassen? Grüße Tiny
Carsten B. schrieb: > Ich habe meinen ESP wie folgt verkabelt und die Ahoy5.17 läuft darauf > sehr stabil: > > NRF24 / ESP32 > CSN --- G23 > CE ---- G2 > MO ---- G13 > SCK --- G18 > IRQ --- G0 > MI ---- G19 Danke. Mittlerweile wurde die Readme auf ahoy schon damit erweitert.
Hey Jörg, Ich werde das mal probieren. Ich verstehe das dann richtig, wenn MQTT deaktiviert wurde, das Script nicht richtig läuft? Daher bin ich etwas über den Gritwert irritiert, welchen ich vom MQTT Server senden soll. Die Aussage verstehe ich nicht so recht, da MQTT Seitig (noch) keine Logik für das Senden von Werten existiert. Hatte das mal aktiviert, aber als einziges item habe ich das ‚ImpExpW‘ im Root des MQTT bekommen. Ansonsten wurde nichts weiter angelegt, auch nicht, wenn mal ein Wert vom WR Decodiert werden konnte. Ich bin etwas verwirrt, ob das am Code oder an meinem Aufbau liegt. Ich werde am Sonntag mal ein zweiten Aufbau als Sniffer machen, um zu sehen, ob mein DTUsim überhaupt was sendet. David
Tut mir leid, ich habe es dann im Code auch nicht mehr weiter nachvollzogen, aber es war auch bei mir so, dass weder der Webserver erreichbar war, noch irgendein Wert gesendet wurde, solange es Probleme auf der MQTT-Seite gab. Ob was gesendet/empfangen wurde, kann ich grade nicht sagen. Welche Art Server hast du da? Mosquitto oder was anderes? Welche Automatisierung? Im Prinzip müßte es reichen, per mosquitto_pub (z.B.) auf diesen einen Topic einen Wert zu senden. Bei mir macht das MQTT_GENERIC_BRIDGE (in FHEM/MQTT2_SERVER) und haut da jeweils den Messwert rein.
Hey Jörg, ioBroker nutze ich. Jetzt ruft erst mal das Mittelalter :-). Ich teste Sonntag wieder. Dank Dir soweit und ein schönes Wochenende.
Hoylmoly DTU für MI 300/600/1500 / TSUN800 hallo ich habe eine neue version V0.1.9 veröffentlicht zum testen: https://github.com/Ziyatoe/DTUsimMI-Hoymiles - der sketch/code wurde zum teil massiv umgebaut - es laeuft recht stabil(bei mir mehrere tage) und die wr-daten werden viel schneller erfasst, zu mindestens bei mir;-) - mehrere wr-commands implementiert - siehe readme.md @Jörg R. (rejoe2) ich habe für diese version die dtu-pro und den mi1500 von morgens bis abends durchgesnifft. ich muss dich enttaeuschen, auch wenn es für dich (auch für mich teilweise) schwer zu verstehen ist: es gibt keine sichtbare zusammenhaenge zwischen Serienummern, timing, kanaele usw. DTU sendet zwischen CH1-99 fast auf alle kanaelen, statistisch bekommst du die meisten antworten auf: 3,23, 40, 61, 75. für mich ist die weitere "forschung" nicht mehr nötig, zu mal die neue versio, bei der datenerfassung recht schnell ist
Günter H. schrieb: > Das Limit (dunkelgrüne Zeile ganz oben) scheint auf "0 Watt" eingestellt das ist sehr aufmwerksam! super!
Moin, vielen Dank für dieses genieale Tool, habe es heute auf einem ESP32 installiert und funktioniert sehr gut. Eine Frage hätte ich, welches in den die Varinaten auf die mann zukünftig setzten sollte? Ahoy oder OpenDTU? habe heute OpenDTU genommen. danke vg
Hallo zusammen,
vielen Dank für das tolle Projekt.
Der Aufbau und Inbetriebnahme hat problemlos funktioniert.
Mein ESP8266 läuft jetzt seit mehreren Tagen problemlos.
Leider scheitere ich beim beim Aufruf des "Active Power Limit via REST
API".
Was ist am folgenden Aufruf verkehrt ?
curl -d '{"inverter":0, "tx_request":81, "cmd":11, "payload":10,
"payload2":1} ' -H "Content-Type: application/json" -X POST
http://192.168.1.93/api/
Vielleicht kann mir jemand beim Aufruf helfen.
Danke
Grüße Draszen
Ziyat T. schrieb: > Hoylmoly DTU für MI 300/600/1500 / TSUN800 > > hallo > ich habe eine neue version V0.1.9 veröffentlicht zum testen: > > https://github.com/Ziyatoe/DTUsimMI-Hoymiles Der Umbau sieht sehr gut aus (!), auch bei mir kommen die Daten sehr schnell (die Messdose zeigt noch gar nichts an....! Aber der MI-600 sendet schon länger fleißig Daten (<5W zwar, aber er produziert). Auch nach reboots (bisher aber nur 3x, und alle ohne großes zeitliches "Funkloch") sind die Daten schnell da (bereits bei der 2. Aktualisierung der Webseite). Welchen Einfluss da speziell das als wichtig gekennzeichnete "wait(10);" hat, wäre ggf. auch für die HM-Fraktion interessant. Auf die Schnelle keine Probleme auf der MQTT-JSON-Seite. Kleinigkeiten: - Die Webseite zeigt wohl Winterzeit an, und die "is day"-Info dürfte nachts auch falsch sein; ob die "year 2036"-Anzeige weg ist, kann ich ggf. morgen sagen - Die Debug-Ausgaben an der Konsole für RX/TX enthalten teils komische Zeichen, die das etwas schwerer lesbar machen als bisher. Das Dauerfeuer gefällt mir zwar immer noch nicht, und wie die TX-Kanäle gewechselt werden, sah' auf die Schnelle auch seltsam aus, wo/wann die 3-er Statusinfo herkam, war an der Konsole nicht zu sehen. **Vielen lieben Dank an dich für die Mühe auf alle Fälle!** Vielleicht allgemein interessant: Dafür kurze Zeit stand auf einem der Kanäle eine "2" - das scheint sowas zu bedeuten wie: "fange gleich an zu produzieren"?
Jörg R. schrieb: > Ziyat T. schrieb: >> Hoylmoly DTU für MI 300/600/1500 / TSUN800 >> >> hallo >> ich habe eine neue version V0.1.9 veröffentlicht zum testen: >> >> https://github.com/Ziyatoe/DTUsimMI-Hoymiles > Der Umbau sieht sehr gut aus (!), auch bei mir kommen die Daten sehr > - Die Webseite zeigt wohl Winterzeit an, und die "is day"-Info dürfte > nachts auch falsch sein; ob die "year 2036"-Anzeige weg ist, kann ich > ggf. morgen sagen die 2036 hab auch schon gesehen, konnte nicht mehr reproduzieren, da laeuft mit NTP etwas schief > - Die Debug-Ausgaben an der Konsole für RX/TX enthalten teils komische > Zeichen, die das etwas schwerer lesbar machen als bisher. > > Das Dauerfeuer gefällt mir zwar immer noch nicht, und wie die TX-Kanäle > gewechselt werden, sah' auf die Schnelle auch seltsam aus, wo/wann die > 3-er Statusinfo herkam, war an der Konsole nicht zu sehen. wie gesagt, die DTU macht genau so mit dem dauerfeuer, nach meiner meinung gibts keine zusammenhaenge zwischen rx/tx, wenn man schaut wie viele verschiedene wr/cmd's/frame's die haben, ist es fast nicht möglich.. > **Vielen lieben Dank an dich für die Mühe auf alle Fälle!** gerne! ich aendere die v0.1.9 immer wieder, einfach mal checken, das ziel ist eine 0.2 zu machen. > Vielleicht allgemein interessant: Dafür kurze Zeit stand auf einem der > Kanäle eine "2" - das scheint sowas zu bedeuten wie: "fange gleich an zu > produzieren"? die 2 hab ich auch schon gesehen, kann aber nicht ganz zu ordnen, bisher bin ich mit diesen sicher: PORT_STATUS = ["no data?", "?", "?gesehen", "Normal", (3) "?", "PV not connected", (5) "?gesehen", "?", "Reduced"] (8)
Jörg R. schrieb: > Kleinigkeiten: > - Die Webseite zeigt wohl Winterzeit an, und die "is day"-Info dürfte > nachts auch falsch sein; ob die "year 2036"-Anzeige weg ist, kann ich > ggf. morgen sagen ja genau, offset ist bei mir NULL, kannst du für dich anpassen zeile 1195,363 >> is_Day = isDayTime(0); ich werde den offset ins settings.h nehmen edit: >- Die Debug-Ausgaben an der Konsole für RX/TX enthalten teils komische > Zeichen, die das etwas schwerer lesbar machen als bisher. kann nicht bestaetigen, hier auf ubuntu22.04/minicom sorry, es ist so: PORT_STATUS = ["no data?", "?", "?gesehen", "Normal", (3) "?", "MPPT port not connected", (5) "?gesehen", "?", "Reduced"] (8)
:
Bearbeitet durch User
wer zu wissen möchte, reaktionszeit eines MI1550 auf cmd=0x51 (0x5A5A, limit) etwa 20sek
Ziyat T. schrieb: > kann nicht bestaetigen, hier auf ubuntu22.04/minicom Keine Ahnung, wo das herkommt, zu sehen ist es auch nur bei den erweiterten RX/TX-Ausgaben: Hier, was bei mir kommt, hoffe, die Forensoftware zerhaut es nicht:
1 | CH 61 �0 12345678�1 �0c6 18 3 89 6010�013 6010�013 �14c�034�94e138a�5ff�35c�11f95dac7 1 |
2 | 2022-9-9 18:8:51 it's daytime!, SunDown at 19.48 |
3 | CH 61 �0 12345678�1 �082 10 1 88 6010�013 6010�013 �0�3�0�0�0�08bf5c9 1 |
(tut sie doch; sind wenige verschiedene Unicode-Zeichen; hier auch ein recht aktuelles Kubuntu, Ausgabe mit minicom). Hab's vorher sicherheitshalber nochmal durch den Compiler gelassen, und auch die aktualisierte Webserver-Datei eingebaut. NTP habe ich jetzt auf die Fritte gesetzt, habe den Eindruck, dass hier in letzter Zeit das INet häufig mal wackelt...
Angehängte Dateien:
-
MQTT.png
8,1 KB
Thorsten schrieb: > So kann es aussehen, wenn man es per mqtt in den Home Assistant > importiert hat. Hallo, genau danach hatte ich gesucht, bin totaler Anfänger mit mqtt in Home Assistant, habe Home Assistant auf einem Raspberry laufen, hast du eine Anleitung für mich am besten mit Screenshot danke, Thomas
Jörg R. schrieb: > Ziyat T. schrieb: >> kann nicht bestaetigen, hier auf ubuntu22.04/minicom > > Keine Ahnung, wo das herkommt, zu sehen ist es auch nur bei den > erweiterten RX/TX-Ausgaben: > Hier, was bei mir kommt, hoffe, die Forensoftware zerhaut es nicht: >
1 | CH 61 �0 12345678�1 �0c6 18 3 89 6010�013 6010�013 |
2 | > �14c�034�94e138a�5ff�35c�11f95dac7 1 |
3 | > 2022-9-9 18:8:51 it's daytime!, SunDown at 19.48 |
4 | > CH 61 �0 12345678�1 �082 10 1 88 6010�013 6010�013 �0�3�0�0�0�08bf5c9 1 |
5 | > |
das ist bei mir nicht der fall. was ich oben sehe, das ist nur bei den datadump's, ich schaue mal nach. edit: ich habe bei der debug ausgabe DEBUG_OUT alle print/println's auf printf umgestellt. der grund, ich möchte spaeter das DEBUG_OUT.printf auf webserial umbiegen, damit die hoylmoly-dtu ohne angeschl.compi gesteuert werden kann.
:
Bearbeitet durch User
Jörg R. schrieb: > Ziyat T. schrieb: >> kann nicht bestaetigen, hier auf ubuntu22.04/minicom > > Hier, was bei mir kommt, hoffe, die Forensoftware zerhaut es nicht: >
1 | CH 61 �0 12345678�1 �0c6 18 3 89 6010�013 6010�013 |
2 | > �14c�034�94e138a�5ff�35c�11f95dac7 1 |
3 | > 2022-9-9 18:8:51 it's daytime!, SunDown at 19.48 |
4 | > CH 61 �0 12345678�1 �082 10 1 88 6010�013 6010�013 �0�3�0�0�0�08bf5c9 1 |
5 | > |
hier: bitte aendern
if (*p < 16)
DEBUG_OUT.printf("%c",'0');
Funktioniert es eigentlich auch mit den aktuelleren HMS Modellen?
Ziyat T. schrieb: > hier: bitte aendern done. Die firmware meinte nur, jetzt sei schon Nacht, obwohl noch 70W kamen (die Zeit für den Start morgen früh ist aber mAn. ok, der offset sollte also eigentlich nicht das Problem sein). (Sind aber alles Kleinigkeiten!)
Prettypat schrieb: > Funktioniert es eigentlich auch mit den aktuelleren HMS Modellen? Nein. Siehe https://github.com/grindylow/ahoy/tree/main/tools/esp8266
Hallo, habe heute mein BKW zum Testen mal in Betrieb genommen. Die DTU wollte ich zuerst mit einem ESP-WROOM-32 aufbauen. Leider klappte das nicht. Habe es einfach nicht hinbekommen. Ich konnte problemlos und fehlerfrei das Teil programmieren aber es erschien kein AP. Die rote LED blinkte nur in kurzen Abständen. Mit einem D1 mini klappte es dann sofort. Der AP erschien und es lies sich alles einrichten. Ich nutze einen HM-800 als WR. Was mich noch interessieren würde, die Einrichtung in Home Assistant. Vielleicht kann da jemand mal etwas näher darauf eingehen. Ganz großen Dank an die Entwickler der Software und an alle Beteiligten! Finde ich ganz toll was ihr da geschaffen habt. mfg
Jörg R. schrieb: > Ziyat T. schrieb: >> hier: bitte aendern > done. > > Die firmware meinte nur, jetzt sei schon Nacht, obwohl noch 70W kamen > (die Zeit für den Start morgen früh ist aber mAn. ok, der offset sollte > also eigentlich nicht das Problem sein). sind die geo daten im secrets.h richtig?
Ziyat T. schrieb: > sind die geo daten im secrets.h richtig? Denke schon. Wie gesagt, die Berechnung für morgen früh passt.
Jörg R. schrieb: > Ziyat T. schrieb: >> sind die geo daten im secrets.h richtig? > Denke schon. Wie gesagt, die Berechnung für morgen früh passt. Hmmm, evtl. habe ich die Angabe auch falsch interpretiert und es muss doch der offset eingestellt werden? Der ESP tickt ja insgesamt um eine Stunde versetzt...?!? Na ja, jedenfalls vielleicht noch interessant: grade gab es 2 mal einen "2"-er Status bei Leistungen von um 1W herum. Auf einem Ausgang wechselte das kurz auf "3", dann wieder zurück auf "2", und jetzt scheint die "3" auf beiden Ports stabil zu sein.
:
Bearbeitet durch User
Jörg R. schrieb: > Na ja, jedenfalls vielleicht noch interessant: grade gab es 2 mal einen > "2"-er Status bei Leistungen von um 1W herum. Auf einem Ausgang > wechselte das kurz auf "3", dann wieder zurück auf "2", und jetzt > scheint die "3" auf beiden Ports stabil zu sein. das muss so etwas sein wie du gesagt hast, soll ichm schon oder soll ich doch noch nicht produzieren :-) es ist schwierig diese meldungen fest zu nageln, zu mal ich z.b. die 2 nicht sehe, auch beim sniffen nicht
Hoylmoly DTU für MI / TSUN ich habe folgendes "problem" fest gestellt: mein MI1500 scheint nicht linear zu produzieren, so etwa ab 500W, d.h. wenn ich z.B. auf 650W limitiere, bekomme ich den wr nicht dorthin, bzw. weit weg davon. bis etwa 500W scheint es ok zu sein. ich bin mir nicht sicher ob es nur bei mir ist oder nicht. kann jemand von den MI/TSUN leute das mal testen bitte? in der version von https://github.com/Ziyatoe/DTUsimMI-Hoymiles, hab ich einen FACTOR, der versucht diese unlinaearitaet ab 500W auszugleichen. so testen: - ZEROEXP = false; setzen - console eingabe(serial command): 2, siehe FACTOR ist default 3 - console eingabe: 100-2000 (limitieren watt) - der wr sollte innert ca. 40sek dort sein - wenn nicht, ev. mit FACTOR spielen, console eingabe: 22-29 (FACTOR 2-9) - besten FACTOR notieren danke!
:
Bearbeitet durch User
ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR bekomme. wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich dann sehen, welche packete vom WR kommen und welche vom sim-DTU?
David B. schrieb: > ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR > bekomme. ich gehe davon aus , dass du die pin's (CE/CS ev. IRQ) richtig konfiguriert hast. verwendest du meine letzte version vom git? https://github.com/Ziyatoe/DTUsimMI-Hoymiles wenn ja: in der console 1 geben, du siehst alle befehle, zeigen was du sendest: eingabe 9 (show tx), wieder mit 9 stoppen. dann z.B. PA_LEVEL höher stellen: eingabe 3-5 dann ohne CRC ausprobieren: eingabe 11 > wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich > dann sehen, welche packete vom WR kommen und welche vom sim-DTU? ich würde zum sniffen unbedingt diesen verwenden: https://github.com/Ziyatoe/DTUsimMI-Hoymiles/tree/main/sniffer da solltest du deine dtu/wr adressen sehen können, bzw. mit grep filtern: CH 40 P 1 DTUADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|WRADRESSE) xx xx [03 82] oder CH 40 P 1 WRADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|DTUADRESSE) xx xx [03 82]
:
Bearbeitet durch User
David B. schrieb: > ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR > bekomme. Bei mir wird das mit dem diesbezüglichen Tests auch erst wieder am WE passen, zumal das kleine ggf. nicht direkt vergleichbar ist. > wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich > dann sehen, welche packete vom WR kommen und welche vom sim-DTU? Die Messages folgen einem bestimmten Muster, was die Adressen angeht: "An" (andere Kopfdaten) "von" "über" (wobei "über" hier in der Regel "von" entspricht).
:
Bearbeitet durch User
Ziyat T. schrieb: > David B. schrieb: >> ich kann leider nicht mittesten, da ich (noch immer) keine Daten vom WR >> bekomme. > > ich gehe davon aus , dass du die pin's (CE/CS ev. IRQ) richtig > konfiguriert hast. > #define RF1_CE_PIN 2//(D4) //(D2) #define RF1_CS_PIN 15//(D8) //(D8) #define RF1_IRQ_PIN 0//(D3) ja, sonst würde der sniffer auch keine daten bekommen. > verwendest du meine letzte version vom git? ich habe dir ein mit mitschnitt der Sniffer ausgabe per PN geschickt. ich habe die Version von stand gestern Abend genutzt. die letzte Version von heute Morgen noch nicht. > https://github.com/Ziyatoe/DTUsimMI-Hoymiles > wenn ja: > in der console 1 geben, du siehst alle befehle, > zeigen was du sendest: eingabe 9 (show tx), wieder mit 9 stoppen. > > dann z.B. PA_LEVEL höher stellen: eingabe 3-5 > > dann ohne CRC ausprobieren: eingabe 11 > > >> wenn ich ein zweiten ESP im sniffer mode laufen lasse, woran kann ich >> dann sehen, welche packete vom WR kommen und welche vom sim-DTU? > > ich würde zum sniffen unbedingt diesen verwenden: > https://github.com/Ziyatoe/DTUsimMI-Hoymiles/tree/main/sniffer > > da solltest du deine dtu/wr adressen sehen können, bzw. mit grep > filtern: > CH 40 P 1 DTUADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|WRADRESSE) xx xx > [03 82] > oder > CH 40 P 1 WRADRESSE(verkehrt) (12/1/0) xx (WRADRESSE|DTUADRESSE) xx xx > [03 82] okay cool, dann hole ich mir den Sniffer gleich von https://github.com/Ziyatoe/DTUsimMI-Hoymiles/tree/main/sniffer
ich hornochse..... sorry. naja wenn man die seriennummber WR in MY_MI_WR und MY_DTU_PRO kopiert, dann gehört man ... Danke, mit dem neuen sniffer isses mir gleich aufgefallen.... Und plötzlich macht man es richtig, kommen schon Daten vom WR....
:
Bearbeitet durch User
Beitrag #7189039 wurde vom Autor gelöscht.
David B. schrieb: > ich hornochse..... sorry. naja wenn man die seriennummber WR in MY_MI_WR > und MY_DTU_PRO kopiert, dann gehört man ... > Danke, mit dem neuen sniffer isses mir gleich aufgefallen.... > > Und plötzlich macht man es richtig, kommen schon Daten vom WR.... ja super, gratuliere!!!
mein WR limitiert nicht, gut oder schlecht ;) über den debug den Wert 100 übergeben RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100 RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100 RFisTime2Send: CMD:051 CH:61 Sts:1 Setting limit:100 MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:23 CH:23 0377W [PV1 188.7W 30.5V 6.4A 1037Wh][238.3V 50.0Hz 47.3C S:3] Grid:0000W Lmt:0100W PVok:0 00:00:03:27:738 WR quittiert, aber fördert dann unbeindruckt weiter(nicht dass es mich stört), aber fürs Testen der Linearität nix gut. CH:23 0332W [PV1 166.8W 30.7V 5.6A 1048Wh][238.4V 50.0Hz 46.8C S:3] Grid:0000W Lmt:0100W PVok:2 00:00:07:10:254 CH:23 0333W [PV0 167.1W 30.6V 5.6A 1030Wh][238.7V 50.0Hz 46.8C S:3] Grid:0000W Lmt:0100W PVok:2 00:00:07:14:507
:
Bearbeitet durch User
Beitrag #7189263 wurde vom Autor gelöscht.
David B. schrieb: > mein WR limitiert nicht, gut oder schlecht ;) > über den debug den Wert 100 übergeben > RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100 > RFisTime2Send: CMD:051 CH:75 Sts:1 Setting limit:100 > RFisTime2Send: CMD:051 CH:61 Sts:1 Setting limit:100 > MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:23 > CH:23 0377W [PV1 188.7W 30.5V 6.4A 1037Wh][238.3V 50.0Hz 47.3C S:3] > Grid:0000W Lmt:0100W PVok:0 00:00:03:27:738 > > WR quittiert, aber fördert dann unbeindruckt weiter(nicht dass es mich > stört), aber fürs Testen der Linearität nix gut. > > CH:23 0332W [PV1 166.8W 30.7V 5.6A 1048Wh][238.4V 50.0Hz 46.8C S:3] > Grid:0000W Lmt:0100W PVok:2 00:00:07:10:254 > CH:23 0333W [PV0 167.1W 30.6V 5.6A 1030Wh][238.7V 50.0Hz 46.8C S:3] > Grid:0000W Lmt:0100W PVok:2 00:00:07:14:507 ja, tatsaechlich eine ack da für 0x51/0x5a5a, hmmmm das ist sehr eigenartig, aber bei denen glaube ich bald alles... ah ja, ist dein MI600 ein normaler oder irgend was spez. für D?
Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar gekauft, leider auf der Rechnung nicht weiter deklariert.
könnte mir bitte jemand neuen discord link bekannt geben? danke
David B. schrieb: > Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar > gekauft, leider auf der Rechnung nicht weiter deklariert. es waere interresant, die etikette zu sehen
Ziyat T. schrieb: > wer zu wissen möchte, > reaktionszeit eines MI1550 auf cmd=0x51 (0x5A5A, limit) etwa 20sek https://discord.gg/WzhxEY62mB
Ziyat T. schrieb: > könnte mir bitte jemand neuen discord link bekannt geben? danke https://discord.gg/WzhxEY62mB
S. schrieb: > Ziyat T. schrieb: >> könnte mir bitte jemand neuen discord link bekannt geben? danke > > https://discord.gg/WzhxEY62mB danke, aber beide links sind ungültig
Ich könnte auch nur den gleichen Link noch einmal versenden. Ich habe beide Links oben getestet - bei mir funktionieren sie.
Angehängte Dateien:
Günter H. schrieb: > Ich könnte auch nur den gleichen Link noch einmal versenden. Ich habe > beide Links oben getestet - bei mir funktionieren sie. danke, kenn mich mit discord nicht aus, schauen die echt auf die location, woher man kommt? wenn es nur für D oder EU ist, dann würde es für mich nicht funzen...
:
Bearbeitet durch User
Angehängte Dateien:
Ziyat T. schrieb: > David B. schrieb: >> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar >> gekauft, leider auf der Rechnung nicht weiter deklariert. > > es waere interresant, die etikette zu sehen Hier :-) 600D EU HM By the way, kann der MI-600 Max 760W und nicht nur 600W
Ziyat T. schrieb: > danke, kenn mich mit discord nicht aus, schauen die echt auf die > location, woher man kommt? wenn es nur für D oder EU ist, dann würde es > für mich nicht funzen... Moin, du warst doch schonmal in der Gruppe wenn ich mich richtig entsinne? Oder hast du ein neuen Account?
Daniel schrieb: > Ziyat T. schrieb: >> danke, kenn mich mit discord nicht aus, schauen die echt auf die >> location, woher man kommt? wenn es nur für D oder EU ist, dann würde es >> für mich nicht funzen... > > Moin, du warst doch schonmal in der Gruppe wenn ich mich richtig > entsinne? > Oder hast du ein neuen Account? guten morgen, nein war noch nie in der gruppe, hab aber einen account
David B. schrieb: > Ziyat T. schrieb: >> David B. schrieb: >>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar >>> gekauft, leider auf der Rechnung nicht weiter deklariert. >> >> es waere interresant, die etikette zu sehen > > Hier :-) 600D EU HM > By the way, kann der MI-600 Max 760W und nicht nur 600W an der etikette ist nichts besonders vermerkt. der will einfach mehr produzieren und nicht limitiert werden:-))
David B. schrieb: > Hier :-) 600D EU HM > By the way, kann der MI-600 Max 760W und nicht nur 600W Interessant... Mein Etikett sieht etwas anders aus, da ist der 2*380W-Panel-Hinweis nicht drauf, dafür aber die genauere Modell-Bezeichnung rechts incl. Strichcode direkt auf dem Etikett aufgedruckt. 600D.NL.HM Fertigungsdatum war wohl Jan. 2000 (sn-Bestandteil 601).
David B. schrieb: > Ziyat T. schrieb: >> David B. schrieb: >>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar >>> gekauft, leider auf der Rechnung nicht weiter deklariert. >> >> es waere interresant, die etikette zu sehen > > Hier :-) 600D EU HM > By the way, kann der MI-600 Max 760W und nicht nur 600W Ich denke nicht das es so gemeint ist. Die empfohlene Modulleistung ist maximal 760W um auch bei suboptimalen Bedingungen 600W Strom zu erhalten. Der WR macht trotzdem nur maximal 600W Ausgangsleistung (dafür braucht er etwa 632 W DC).
Dirk S. schrieb: > David B. schrieb: >> Ziyat T. schrieb: >>> David B. schrieb: >>>> Das kann ich Dir leider nicht sagen. Wurde in München bei AlphaSolar >>>> gekauft, leider auf der Rechnung nicht weiter deklariert. >>> >>> es waere interresant, die etikette zu sehen >> >> Hier :-) 600D EU HM >> By the way, kann der MI-600 Max 760W und nicht nur 600W > > Ich denke nicht das es so gemeint ist. > Die empfohlene Modulleistung ist maximal 760W um auch bei suboptimalen > Bedingungen 600W Strom zu erhalten. Der WR macht trotzdem nur maximal > 600W Ausgangsleistung (dafür braucht er etwa 632 W DC). Kann ich so nicht bestätigen, kommen unter guten Bedingungen auch mal deutlich mehr als 600W raus.
Ja und, deshalb ist der WR -600 auch auf 600W am Ausgang limitiert. Die Panele können bzw. sollen auch ruhig mehr Peak haben, hier werden eben bis zu 380W/Panel empfohlen. Wenn es kalt ist bei perfekter Einstrahlung bzw. günstigen Wolken können die Panele schon mal 350W liefern kurzzeitig. Ist aber auch egal da diese Peaks nichts ausmachen im Betrieb.
Grisu schrieb: > Ja und, deshalb ist der WR -600 auch auf 600W am Ausgang limitiert. Die > Panele können bzw. sollen auch ruhig mehr Peak haben, hier werden eben > bis zu 380W/Panel empfohlen. Wenn es kalt ist bei perfekter Einstrahlung > bzw. günstigen Wolken können die Panele schon mal 350W liefern > kurzzeitig. Ist aber auch egal da diese Peaks nichts ausmachen im > Betrieb. Ich verstehe das schon, kann’s aber bei mir nicht nachvollziehen, am Ausgang WR kommen auch mal mehr als 600W bei perfekten Konditionen, Rekord waren 679W über einen Zeitraum von knapp 20 Minuten Anfang April. Aber darum gehts auch nicht, Problem war ja, das ich bei mir den Test von Ziyat bezüglich der Limitierung und linearität machen wollte, was bei mir nicht klappte.
:
Bearbeitet durch User
Echt wahr? Das finde ich dann wirklich spannend, ist wohl keine so harte Grenze in den WRn, sondern eher abhängig von Temp. usw. was er grad wirklich zusammenbringt und 600W ist der Max-Wert unter ihren "Standard"-Bedingungen, welche auch immer das sein mögen. Versteh dann nur nicht ganz wie sie dann eine EU-Zulassung bekommen können, die ja sicher keine Überschreitung der Werte (welche auch immer national dann gelten mögen) tolerieren. Wenn der -800 über 800W geht ist das ja als Balkonkraftwerk ein Ausschlußgrund (bzw. der -600 über 600W Limit nach der deutschen Bestimmung soviel ich weiß).
:
Bearbeitet durch User
Grisu schrieb: > Echt wahr? > Das finde ich dann wirklich spannend, ist wohl keine so harte Grenze in > den WRn, sondern eher abhängig von Temp. usw. was er grad wirklich > zusammenbringt und 600W ist der Max-Wert unter ihren > "Standard"-Bedingungen, welche auch immer das sein mögen. > Versteh dann nur nicht ganz wie sie dann eine EU-Zulassung bekommen > können, die ja sicher keine Überschreitung der Werte (welche auch immer > national dann gelten mögen) tolerieren. Wenn der Mann Verstehe ich nicht, was die Leistungsgrenzen mit EU-Zulassungen zu tun hat. Geht doch eher um die Genehmigungspflichten, welche je nach Bundesland bis 600W entfallen. Desweitern macht der WR auch 3A auf dauer, was bei 230V auch mehr als 600W ergibt. Wie gesagt, wir kommen vom Thema ab.
:
Bearbeitet durch User
@David: Hast Du schon versucht Deinen Wechselrichter als Hm einzugeben? Also statt 1041xxxxxxxx 1141xxxxxxxx in Ahoy Software als Wechselrichter Seriennummer einzugeben? Vg Sven
Sven K. schrieb: > @David: > Hast Du schon versucht Deinen Wechselrichter als Hm einzugeben? > Also statt 1041xxxxxxxx 1141xxxxxxxx > in Ahoy Software als Wechselrichter Seriennummer einzugeben? > > Vg > Sven Nein hab ich nicht. Du meinst wegen der Limitierung oder warum sollte ich das Probieren?
Die Engpaßleistung brauchst doch für jede Bewilligung, oder? Und die wird durchschnittlich nunmal vom WR ausgangsseitig vorgegeben. Wenn man sich nicht darauf verlassen kann wird man doch irgendwo Probleme bekommen können - denk ich. Obendrein ist gerade die Ausgangsleistung sehr wichtig für die Dimensionierung der Leitungen und Sicherungen, insbes. wenn man diese in Serie hängt wie es ja u.a. auch vorgesehen ist.
:
Bearbeitet durch User
Ziyat T. schrieb: > mein MI1500 scheint nicht linear zu produzieren, so etwa ab 500W, > d.h. wenn ich z.B. auf 650W limitiere, bekomme ich den wr nicht dorthin, > bzw. weit weg davon. bis etwa 500W scheint es ok zu sein. Du hast bedacht das die Limitierung nicht für die Gesamtleistung ist? Wenn Du auf 650 limitierst wird MPPT 1 auf 325W und MPPT 2 auch auf 325 limitiert. Wenn die Solarzellen bei MPPT 1 momentan 600W könnten und die an MPPT 2 nur 100W (wegen der Sonneneinstrahlung) kommen nur 325+100= 425W bei raus und nicht 650W. Zumindest kommt es mir am HM-800 und HM-1200 so vor.
:
Bearbeitet durch User
Läßt sich eigentlich bei den für DE ab Werk 600W limitierten die max Leistung auch höher als 600w setzten? Naturlich nur sofern die Hardware ohne die Limitierung mehr könnte. Ich habe 2 Panels ost-west die jeweils über 300w könnten, aber der TSUN is halt auf 600 Limitiert und macht so scheinbar auch max 300 pro Strang womit ich nie die 600 erreichen werde.
:
Bearbeitet durch User
M. P. schrieb: > Zumindest kommt es mir am HM-800 und HM-1200 so vor. Gerade nochmal getestet: Ist so.
M. P. schrieb: > Ziyat T. schrieb: >> mein MI1500 scheint nicht linear zu produzieren, so etwa ab 500W, >> d.h. wenn ich z.B. auf 650W limitiere, bekomme ich den wr nicht dorthin, >> bzw. weit weg davon. bis etwa 500W scheint es ok zu sein. > > Du hast bedacht das die Limitierung nicht für die Gesamtleistung ist? > der wr versteht es so, gem. hoymiles: - P_Limit is the power limit, the percentage of the rated power, the range is 0~100, - P_Limit1 is the absolute value of the power limit, the unit is W, with 1 decimal place ich gehe davon aus, dass P_Limit1 auch das "power limit of the rated power" ist, so hab ich es programmiert, ich glaube bei ahoy-dtu ists auch so. hebe nen MI1500 mit 3 pv's, wenn ich um 12-13uhr teste, habe voll die sonne, 2 mmpt's sollten ja voll aufmachen, bekomme ich dann auch 850W bei 57C! aber die linearitaet ist nicht vorhanden, siehe dateianhang edit:im log, MPPT1:PV1/PV2 MPPT2:PV2/PV3
:
Bearbeitet durch User
David B. schrieb: > mein WR limitiert nicht, gut oder schlecht ;) das hat mich beschaeftigt! ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen könntest? kannst du auch ev. in der console, eingabe 15, auf % wechseln und so mal testen
Dein Log zeigt doch genau das Verhalten was ich sage. Auszug aus Log.
1 | CH:23 0593W [PV0 185.4W 41.2V 4.7A 0287Wh][237.6V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3 00:03:03:42:51 |
2 | CH:23 0593W [PV1 223.1W 41.2V 5.6A 0525Wh][237.5V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3 00:03:03:42:302 |
3 | CH:23 0593W [PV2 184.6W 38.4V 5.0A 0576Wh][237.5V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3 00:03:03:42:552 |
4 | CH:23 0593W [PV3 0.5W 38.4V 0.0A 0003Wh][237.5V 50.0Hz 55.9C S:3] Grid:0239W Lmt:0800W PVok:3 00:03:03:42:803 |
Limit 800W (also 400W pro MPPT) PV0 plus PV1 = ca. 408W (also am Limit) Dazu kommt dann PV2 was die 593W Gesamt ergibt. Dein 1500er sind einfach zwei 750. Das Limit teilt sich 1zu1 auf beide auf. Ist meiner Meinung nach extrem blöd von Hoymiles das so zu machen.
:
Bearbeitet durch User
M. P. schrieb: > Dein Log zeigt doch genau das Verhalten was ich sage. > > Auszug aus Log. > >
1 | > CH:23 0593W [PV0 185.4W 41.2V 4.7A 0287Wh][237.6V 50.0Hz 55.9C S:3] |
2 | > Grid:0239W Lmt:0800W PVok:3 00:03:03:42:51 |
3 | > CH:23 0593W [PV1 223.1W 41.2V 5.6A 0525Wh][237.5V 50.0Hz 55.9C S:3] |
4 | > Grid:0239W Lmt:0800W PVok:3 00:03:03:42:302 |
5 | > CH:23 0593W [PV2 184.6W 38.4V 5.0A 0576Wh][237.5V 50.0Hz 55.9C S:3] |
6 | > Grid:0239W Lmt:0800W PVok:3 00:03:03:42:552 |
7 | > CH:23 0593W [PV3 0.5W 38.4V 0.0A 0003Wh][237.5V 50.0Hz 55.9C S:3] |
8 | > Grid:0239W Lmt:0800W PVok:3 00:03:03:42:803 |
9 | > |
> > Limit 800W (also 400W pro MPPT) > PV0 plus PV1 = ca. 408W (also am Limit) > Dazu kommt dann PV2 was die 593W Gesamt ergibt. > > Dein 1500er sind einfach zwei 750. Das Limit teilt sich 1zu1 auf beide > auf. > Ist meiner Meinung nach extrem blöd von Hoymiles das so zu machen. du hast recht mit deiner rechnung, was sie geschrieben haben ist nicht ganz verstaendlich,oder ich habs nicht kapiert. jedenfalls ist es natürlich blöd von hoymiles es so zu machen, darum gibts bei der DTU-Pro/modbus register ja nur die prozentuale limitierung. edit: das wirkt ja auch auf die feste limitierung aus, wenn jemand nicht alle ports des wr's angeschlossen hat, stimmt die limitierung nicht, hmm echt sch... jetzt muss ich mir überlegen wie ich das lösen könnte, unsere limit_P = WR_P, any thoughts?
:
Bearbeitet durch User
Hmmm, im Prinzip wissen wir doch anhand der sn, wieviele Ports da sind, und in dem "3-er Fall" (wie in deiner Konfiguration) müßte man dann halt hergehen und die Limitierung passend verteilen, also im "zulässigen Bereich" durch 3 mal 4 rechnen (15%=>20%, 75%=>100%), und erst dann diese neue Effektivbegrenzung wieder auf beide MPPT verteilen. Oder ist das zu einfach gedacht?
:
Bearbeitet durch User
Ist doch technisch logisch und auch nachvollziehbar, da auch die (intern doppelt ausgelegte) Ausgangselektronik eben pro MPPT auf eine gewisse Leistung dimensioniert ist, die nicht überschritten werden darf, um nichts abzuglühen.
Grisu schrieb: > Ist doch technisch logisch und auch nachvollziehbar, da auch die (intern > doppelt ausgelegte) Ausgangselektronik eben pro MPPT auf eine gewisse > Leistung dimensioniert ist, die nicht überschritten werden darf, um > nichts abzuglühen. für mich ist das nicht sauber gelöst, ich hab praktisch die leistung da, aber kann so nicht abrufen. z.B. mittag voll aufgedreht hab 850W, wenn ich auf 600W limitiere, macht der mppt1=300W, mppt2=300W, wenn ich nur 3pv's habe bekomme ich 300+ca150=450W, obwohl ich nur über mppt1 (850/2)425W ziehen könnte
Jörg R. schrieb: > Hmmm, im Prinzip wissen wir doch anhand der sn, wieviele Ports da sind, > und in dem "3-er Fall" (wie in deiner Konfiguration) müßte man dann halt > hergehen und die Limitierung passend verteilen, also im "zulässigen > Bereich" durch 3 mal 4 rechnen (15%=>20%, 75%=>100%), und erst dann > diese neue Effektivbegrenzung wieder auf beide MPPT verteilen. > Oder ist das zu einfach gedacht? ja, wenn ich die einzelne mppt's direkt ansteuern könnte waere es so ok, aber wir haben nur eine absolute limitpower zahl zu versenden, oder habe dich falsch verstanden? mach mir bitte eine rechnung, mit MI maxpower 1500w 2 mppt, 3 pv
Du willst z.B. 600W haben: 600/3*4 => 800W effektiv. Ist zulässig (da weniger wie 1500) => kann man direkt angeben. "Komisch" ist dann nur, dass der WR vermutlich dann zurückmeldet, dass er auf 800 limitiert sei. Vermutlich ist es einfacher, das auf der Seite der Automatisierungslösung zu machen, also dem WR gleich die 800 zu senden und eben zu wissen, dass das dann effektiv 600 sind...
Ziyat T. schrieb: > edit: das wirkt ja auch auf die feste limitierung aus, wenn jemand nicht > alle ports des wr's angeschlossen hat, stimmt die limitierung nicht, hmm > echt sch... > jetzt muss ich mir überlegen wie ich das lösen könnte, > unsere limit_P = WR_P, any thoughts? Moin Ziyat, ich habe es schon in Diskord geantwortet. Jedoch auch für die anderen hier nochmal zum lesen: > Hierzu würde ich Vorschlagen eine kleine Funktion zu bauen. > Jedesmal wenn man ein neuen Wert zum WR schickt, wird vorher abgefragt ob an beiden MPPT eine Leistung erzeugt wird. > Ist dies der Fall, dann soll der Wert ganz normal an den WR geschickt werden. > > Ist nur ein MPPT "vorhanden", oder durch Schatten abgedeckt (beide Leistungen von MPPT sind ungleich): > Soll die Leistung mal zwei Multipliziert werden. > > ---------- > > Man kann es auch so weit treiben das die DTU, denn Wert beider MPPT Tracker überwacht. > Denn sobald die Verschattung wieder weg ist. > Hat man ja doppelte Leistung, dann soll er wieder runter regeln.
:
Bearbeitet durch User
Jörg R. schrieb: > Du willst z.B. 600W haben: > 600/3*4 => 800W effektiv. Ist zulässig (da weniger wie 1500) => kann man > direkt angeben. > > "Komisch" ist dann nur, dass der WR vermutlich dann zurückmeldet, dass > er auf 800 limitiert sei. Vermutlich ist es einfacher, das auf der Seite > der Automatisierungslösung zu machen, also dem WR gleich die 800 zu > senden und eben zu wissen, dass das dann effektiv 600 sind... ja soweit war ich auch, und gefaellt mir nicht so.. aber was macht er wenn die mppt's mit verschiedene pv's-leistungen bestückt sind? zB mppt1=200W/350W, mppt2=400W
(esp8266/holymolydtu MI-1500) vergleich mit oder ohne interrupt,in etwa gleicher zeit: mit: TX statistic:15192 RX statistic:2846 ohne(looping): TX statistic:16335 RX statistic:8273 @Jörg R. (rejoe2) der erlös von 2zu1 beim looping trotz des "dauer feuers" ist doch nicht schlecht oder? ;-)
Ziyat T. schrieb: > ja soweit war ich auch, und gefaellt mir nicht so.. > aber was macht er wenn die mppt's mit verschiedene pv's-leistungen > bestückt sind? zB mppt1=200W/350W, mppt2=400W MAn. braucht man nicht jeden Sonderfall in der firmware abdecken. Man kann das ja noch weiter verkomplizieren, indem man die aktuelle Beschattung von 350W berücksichtigt... Sowas kann man wohl nur auf der Seite des Heimautomatisierungs-Controllers lösen. Ziyat T. schrieb: > @Jörg R. (rejoe2) > der erlös von 2zu1 beim looping trotz des "dauer feuers" ist doch nicht > schlecht oder? ;-) Hmmm, irgendwo hatte ich einen Log-Auszug mit gefühlt 5:4 Rückmeldungen gepostet... Aber ja, die Quote ist recht ordentlich, die Frage bleibt, ob man das Dauerfeuer wirklich braucht, um brauchbare Quoten zu erreichen? Aber lassen wir das, die DTU macht so ein Dauerfeuer, warum auch immer, und es funktioniert wohl, und ich habe auch keinen besseren (dauerhaft funktionierenden) Vorschlag anzubieten...
Naja so ein Sonderfall ist das gar nicht. Kommt z.B. bei unterschiedlicher Ausrichtung der Module sehr schnell zum tragen. Im ioBroker hatte ich es mal ein "Soll-Limit" als Datenpunkt und dann per Skript das Limit in der DTU hoch (bzw. runter) gesetzt bis die Ausgangsleistung real beim Soll-Limit war. Aber dadurch wird das ganze natürlich langsamer.
Mit "Sonderfall" war eher gemeint, dass die Bestückung gleich so ungleichgewichtig ist, und man das direkt in der firmware vercodet. Auf den aktuellen Sonnenstand, jahreszeitliche Verschattungen usw. kann man m.E. sowieso nur im laufenden Betrieb reagieren, und da sind die Reaktionszeiten halt wie sie sind. Wir können ggf. nur dafür sorgen, dass die Trefferquote gut ist, mit der Anweisungen auch tatsächlich (schnell) beim Inverter landen...
Ziyat T. schrieb: > David B. schrieb: >> mein WR limitiert nicht, gut oder schlecht ;) > > das hat mich beschaeftigt! > > ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen > könntest? > kannst du auch ev. in der console, eingabe 15, auf % wechseln und so mal > testen Hey ich wollte nur kurz sagen, dass ich dabei bin, aber im Moment dauerbewölkt … daher kann ich nicht testen. Wird noch dauern.
:
Bearbeitet durch User
Ziyat T. schrieb: > ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen > könntest? Hab's versucht, aber im Moment kommen mit der aktuellen 1.9 gar keine Daten rein; nicht mal mit ausgeschaltetem CRC...
Angehängte Dateien:
Jörg R. schrieb: > Ziyat T. schrieb: >> ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen >> könntest? > > Hab's versucht, aber im Moment kommen mit der aktuellen 1.9 gar keine > Daten rein; nicht mal mit ausgeschaltetem CRC... bei mir kein problem, siehe anhang(und datum), hab ja im verlauf nichts angepasst, nur bei der limitierung
Jörg R. schrieb: > Ziyat T. schrieb: >> ich habe im sketch etwas angepasst, ist im git, wenn du bitte testen >> könntest? > > Hab's versucht, aber im Moment kommen mit der aktuellen 1.9 gar keine > Daten rein; nicht mal mit ausgeschaltetem CRC... Kann ich nicht bestätigen, läuft ganz gut Kann nur nicht limitieren, da unter 100W
:
Bearbeitet durch User
...60cm-Problem. Hatte übersehen, dass mit dem update auch wieder meine PIN-Konfiguration geändert worden war... Limitierung sieht irgendwie komisch aus. Es wird ein Ack behauptet, aber effektiv passiert nicht viel. Vielleicht sollte ich die Info über das Grid wegschalten?
@David B. (mystisch) @Jörg R. (rejoe2) wenn ihr über die console limitiert (befehl 100-1999): zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war, dann spielt das grid keine rolle mehr. probiert ev. in der console, eingabe 15, auf % wechseln und so mal testen bei mir laeuft beides, mit abs-watt und %
Ziyat T. schrieb: > @David B. (mystisch) > @Jörg R. (rejoe2) > wenn ihr über die console limitiert (befehl 100-1999): > zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war, > dann spielt das grid keine rolle mehr. > > probiert ev. in der console, eingabe 15, auf % wechseln und so mal > testen > > bei mir laeuft beides, mit abs-watt und % Ab Mittwoch soll das Wetter in München wieder sonniger werden, dann kann ich testen
Hallo zusammen, alles funzt super solange ich das Teil am PC inkl. Konsole habe. Sobald ich dieses aber per USB Netzteil versorge bekomme ich keine Verbindung mehr. Könnt Ihr mir sagen warum nicht? Danke und Gruß Qmaxx
Qmaxx85 schrieb: > Sobald ich dieses aber per USB Netzteil versorge bekomme ich keine > Verbindung mehr. Mach mal einen 100uF Elko in die Versorgung vom nRF Funkmodul.
Hallo, mal eine Frage zur AHOY-DTU. Es geht um die Zeitdauer zwischen 2 Abfragen. Diese ist ja auf 30s vor eingestellt. Gibt es irgendwelche negativen Auswirkungen wenn ich diese z.B. auf 5s stelle? Es geht mir darum, dass z.B. bei der Berechnung der Leistungsdaten über Homeassistant im Vergleich mit dem Drehstromzähler es zu größeren Ungenauigkeiten kommt. Bei vorbei fliegenden Wolken z.B. werden Maxima z.B. über 30s beibehalten obwohl die hohe Leistung vielleicht nur 5s anlag. mfg Jürgen
Hallo M.P, habe jetzt 100uF mehrere ausprobiert leider ohne Erfolg das Modul wird nicht mehr erkannt. Welchen Elko empfelst du? Habe 16v als kleinsten da gehabt. Danke für die Hilfe.
Die Spannung ist völlig egal (weniger=kleiner), da du wohl kaum einen unter 6,3V findest (der bereits ausreicht). 100µF sollten mehr als ausreichend sein. Und fix verlötet anstatt gesteckt macht auch einen Unterschied. Hast schon ein anderes Netzteil versucht? Leicht möglich, daß deines HF-Störungen verursacht, welche bei anderen Anwendungen nicht so ins Gewicht fallen.
:
Bearbeitet durch User
Angehängte Dateien:
-
wire.png
83 KB
Moin, ich lese dort auf dem screenshot, das man hier eine geänderte GPIO's verwenden soll oder muss, ist jemand so nett und packt mir eine bin Datei von ahoy online damit ich es flashen kann ? Danke Peter
Ziyat T. schrieb: > @David B. (mystisch) > @Jörg R. (rejoe2) > wenn ihr über die console limitiert (befehl 100-1999): > zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war, > dann spielt das grid keine rolle mehr. > > probiert ev. in der console, eingabe 15, auf % wechseln und so mal > testen > > bei mir laeuft beides, mit abs-watt und % Das scheint jeweils beim WR nicht angekommen zu sein, jedenfalls hat es auch nach einer Wartezeit von mehr als einer Minute keine Auswirkungen. Absolut:
1 | CH:40 0140W [PV0 70.2W 33.9V 2.1A 0047Wh][232.9V 50.0Hz 17.1C S:3] Grid:0124W Lmt:0100W PVok:2 00:00:03:34:861 |
2 | CH:40 0141W [PV1 71.0W 34.1V 2.1A 0048Wh][232.9V 50.0Hz 17.1C S:3] Grid:0124W Lmt:0100W PVok:2 00:00:03:35:614 |
Relativ:
1 | CH:75 0208W [PV1 104.5W 34.5V 3.1A 0058Wh][234.0V 50.0Hz 17.9C S:3] Grid:0202W Lmt:0016% PVok:2 00:00:10:04:130 |
2 | CH:75 0208W [PV0 103.5W 34.3V 3.1A 0056Wh][234.2V 50.0Hz 17.9C S:3] Grid:0202W Lmt:0016% PVok:2 00:00:10:07:364 |
Hallo, ich habe alle Netzteile ausprobiert die ich im Haus habe. So ca.7 verschiedene aber alle verbinden sich nicht. Sobald ich das Kabel in den Notebook stecke findet er sofort Wechselrichter und läuft einwandfrei. Gruß Qmaxx85
Dann versuch es einmal mit einem anderen Kabel.
Hallo, ja die Kabel habe ich jetzt auch durchprobiert leider immer ohne erfolg. Geht das bei dir denn alles so?
Ja, sowohl direkt an der Fritzbox als auch mit eigenem Netzdadapter. Verwende ein kurzes Ladekabel (ohne Datenleitungen) geht aber mit dem anderen langen vollbelegten ebenso.
Hallo, habe es auch Grade an der Fritzbox getestet leider auch da ohne Erfolg.
Peter Hansen schrieb: > Moin, > ich lese dort auf dem screenshot, das man hier eine geänderte GPIO's > verwenden soll oder muss, ist jemand so nett und packt mir eine bin > Datei von ahoy online damit ich es flashen kann ? > > Danke Peter https://github.com/lumapu/ahoy/releases/tag/ahoy_v0.5.17
und genau diese Version geht nicht weil sie nicht angepasst ist
Hallo Peter, Geht denn bei Dir der ESP-WROOM-32 ohne den NRF24? Ich habe den ESP einige male geflasht, lt. nodemcu-pyflasher mit Erfolg, der ESP blinkt dann nur in schneller Folge aber ich kann keinen AP finden! Geflasht habe ich die fertige 220906_ahoy_0.5.17_esp32_5402e9b.bin Was mache ich falsch? Oder geht es nicht ohne dem NRF24? Ich bin dann auf den ESP8266 umgestiegen, der funktionierte sofort. Auch ohne den NRF24 Gruß Jürgen
Peter Hansen schrieb: > und genau diese Version geht nicht weil sie nicht angepasst ist Du sollst laut Screenshot ja nur die 3 im UI anpaßbaren ändern.
:
Bearbeitet durch User
moin zusammen, bei mir sagt er auch immer alles okay, aber ich finde auch keinen ap. ich kann ja nichts ändern, da ich eben nur den flasher habe und dann die bins flashe. da kann man nix ändern.
Jörg R. schrieb: > Absolut: >
1 | > CH:40 0140W [PV0 70.2W 33.9V 2.1A 0047Wh][232.9V 50.0Hz 17.1C S:3] |
2 | > Grid:0124W Lmt:0100W PVok:2 00:00:03:34:861 |
3 | > CH:40 0141W [PV1 71.0W 34.1V 2.1A 0048Wh][232.9V 50.0Hz 17.1C S:3] |
4 | > Grid:0124W Lmt:0100W PVok:2 00:00:03:35:614 |
5 | > |
> Relativ: >
1 | > CH:75 0208W [PV1 104.5W 34.5V 3.1A 0058Wh][234.0V 50.0Hz 17.9C S:3] |
2 | > Grid:0202W Lmt:0016% PVok:2 00:00:10:04:130 |
3 | > CH:75 0208W [PV0 103.5W 34.3V 3.1A 0056Wh][234.2V 50.0Hz 17.9C S:3] |
4 | > Grid:0202W Lmt:0016% PVok:2 00:00:10:07:364 |
5 | > |
du hattest gesagt, dass die ACK für die 0x51 kommen, oder nicht?
:
Bearbeitet durch User
Ja, zumindest gestern hatte ich das gesehen. Heute hatte ich nicht explizit aufgelöst, jetzt kann ich gerade nicht schauen.
Ziyat T. schrieb: > du hattest gesagt, dass die ACK für die 0x51 kommen, oder nicht? Hier auch noch die zugehörige Info aus der Konsole. zu 100W:
1 | SerialIn: 100 int:100 SerCmd:100 |
2 | SerialIn: 100 SerCmd:100 Limit:100 |
3 | RFisTime2Send: CMD 0x0 CH:40 set limiting over serial command |
4 | 2022-9-17 11:9:31 it's daytime!, SunDown at 19.30 |
5 | MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:40 |
zu den 16%:
1 | SerialIn: 100 SerCmd:100 Limit:16 |
2 | RFisTime2Send: CMD 0x0 CH:61 set limiting over serial command |
3 | MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:75 |
Peter Hansen schrieb: > moin zusammen, > bei mir sagt er auch immer alles okay, aber ich finde auch keinen ap. > ich kann ja nichts ändern, da ich eben nur den flasher habe und dann die > bins flashe. > da kann man nix ändern. schau mal mit der seriellen Konsole, ob du evtl. einen Bootloop nach dem flashen der .bin hast
Peter Hansen schrieb: > moin zusammen, > bei mir sagt er auch immer alles okay, aber ich finde auch keinen ap. > ich kann ja nichts ändern, da ich eben nur den flasher habe und dann die > bins flashe. > da kann man nix ändern Eventuell liegt es am Flashen. Sofern du unter Windows flashst, überprüfe die Baudrate des virtuellen Com-Ports,die steht meistens auf 9600. Dann die Rate mal im Flash Programm anpassen.
Angehängte Dateien:
nein liegt es nicht
ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) waiting for download das steht da mehr nicht
Angehängte Dateien:
Peter Hansen schrieb: > ets Jun 8 2016 00:22:57 > > rst:0x1 (POWERON_RESET),boot:0x3 > (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) > waiting for download Flash mal mit dem ESP Download Tool Speed auf 80. Nich wie im Bild auf 40 https://www.espressif.com/sites/default/files/tools/flash_download_tool_3.9.3.zip Sollte das nicht gehen, flashe einfach mal online https://install.wled.me/ hatte ich auch schon, das ich einen Bootloop hatte nach dem flashen. Dann hab ich WLED drauf gemacht und dann Ahoy und dann ging es. Warum auch immer ....
:
Bearbeitet durch User
Peter Hansen schrieb: > hat er gemacht....selbes Ergebnis :( Beim einstecken des USB Kabels boot Knopf gedrückt gehalten ? WLED ging auch nicht ?
Jörg R. schrieb: > RFisTime2Send: CMD 0x0 CH:61 set limiting over serial command > MIAnalysePacket: ACK PowerLimiting(0x5A5A), CMD:D1 RxCH:75 > [/code] ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für gründen auch immer tut er nicht limitieren. in der doku sehe ich auch nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade
Hallo, ich habe gerade mal auf den ESP-WROOM-32 open DTU geflasht. Das funktionierte sofort. Ohne NRF24! Konnte den AP connecten! Hat allerdings etwas gedauert bis ich Visual Studio usw. installiert hatte und das alles kapiert habe. Wo bleiben eigentlich die Daten gespeichert bei Ahoy? Auf dem 8266 Board oder im jeweiligen Wechselrichter? Gruß Jürgen
Angehängte Dateien:
-
Geraetemanager.png
51 KB -
Geraetemanager.png
51 KB -
Geraetemanager.png
51 KB
Peter Hansen schrieb: > nein liegt es nicht Im flash Programm steht 115000 als Baudrate im Gerätemanger auch?
Ziyat T. schrieb: > ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun > waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für > gründen auch immer tut er nicht limitieren. in der doku sehe ich auch > nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade So habe ich das auch interpretiert, aber wie gezeigt passiert halt effektiv nichts. Kann es sein, dass die älteren/kleineren MI-Modelle die Limitierung halt einfach noch nicht konnten? Bei der Suche nach Infos dazu bin ich über das hier gestolpert: https://www.fotowoltaika.belos.com.pl/pl/p/file/81017a576a9b3227b6558863e7332e50/manual-mi600-mi700-mi800.pdf Ist evtl. interessant wegen der Interpretation von Statusmeldungen?
Jörg R. schrieb: > Ziyat T. schrieb: >> ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun >> waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für >> gründen auch immer tut er nicht limitieren. in der doku sehe ich auch >> nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade > So habe ich das auch interpretiert, aber wie gezeigt passiert halt > effektiv nichts. Kann es sein, dass die älteren/kleineren MI-Modelle die > Limitierung halt einfach noch nicht konnten? oder alle die für balkonien in D zugelassen sind? > Bei der Suche nach Infos dazu bin ich über das hier gestolpert: > https://www.fotowoltaika.belos.com.pl/pl/p/file/81017a576a9b3227b6558863e7332e50/manual-mi600-mi700-mi800.pdf > Ist evtl. interessant wegen der Interpretation von Statusmeldungen? diese status meldungen sind nicht vom inverter direkt, die sind imho vom smiles cloud bzw. von DTU
Ziyat T. schrieb: > oder alle die für balkonien in D zugelassen sind? Kann ich nicht beurteilen, aber wenn ich das richtig interpretiere, gibt es die Möglichkeit bei den HM-600 etc.. > diese status meldungen sind nicht vom inverter direkt, die sind imho vom > smiles cloud bzw. von DTU Na ja, irgendwoher wird die DTU ihre Weisheit ja beziehen, und das kann eigentlich nur die Interpretation der Daten sein, die der WR ihr zukommen läßt. Oder?
Gerade bei #eBayKleinanzeigen gefunden. Wie findest du das? https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-hardware-fuer-ahoy-projekt-hm300-hm400-hm600-hm1500/2201223140-168-5178?utm_source=sharesheet&utm_medium=social&utm_campaign=socialbuttons&utm_content=app_android Da vertickt jemand eure Erkenntnisse. Nur zur Info
Ok, ich sehe das wurde im Verlauf des threads schon gemeldet. Sorry
....und was genau kann ich nun tun wenn alles okay ist ?
Ziyat T. schrieb: > ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun > waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für > gründen auch immer tut er nicht limitieren. in der doku sehe ich auch > nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade Vielleicht ist es bei den alten aber auch schlicht ein anderes Kommando? Bin wegen eines Posts im FHEM-Forum bei Zeile https://github.com/atc1441/NETSGPClient/blob/main/src/NETSGPClient.h#L282 gelandet, nach der es sehr vielleicht auch 0xC3 sein könnte (für prozentuale Vorgaben). Werde aber aus den Gesamtzusammenhängen nicht ganz schlau, diese Bitschubserei ist irgendwie nicht so meins... Full story: Das scheint der überarbeitete Code aus dem "Urvideo" zu sein. Von dem hat jemand eine bisher nicht veröffentlichte Kopie gemacht (https://forum.fhem.de/index.php/topic,129305.0.html), um damit Wechselrichter einer bisher hier nicht aufgeführten Marke (New Energy Technology Co., Ltd.) abzuhören bzw. anzusteuern. Deren Produkte (aus 2019, http://newenergytek.com/index.php/content-51) sehen ziemlich identisch aus zu den neueren HM-Modellen (mit externer Antenne). Vielleicht ist das eine Art "missing link"...
die MI600 lassen sich auch mit der DTU-Pro nicht limitieren, das geht nur mit den HM Invertern
Nach Lesen vieler Beiträge fiel mir auf, dass einige ja Probleme haben, die Hardware in Betrieb zu nehmen. Dazu kurz meine Erfahrungen: Flashen mit dem NodeMCU-PyFlasher funktionierte an meinem Notebook (TB-Usb-A-Adapter) nur mit einem älteren ESP8266, während das Flashen mit zwei ESP32 und zwei D1-Minis fehlerhaft war. Über PlatformIo traten die Fehler nicht auf. Ebenso ließen sich die Binärdateien problemlos mit dem ESPHome-Flasher 1.4.0-Windows flashen. Entweder es liegt an meinem Notebook (i7/Windows11) oder am PyFlasher, keine Ahnung. Viele D1-Mini-Clones sind mit zu einem schwachen 3,3V-Spannungregler bestückt, der gerne nach dem Anschluss des NRF24 durchknallt. Wer also nicht weiß, wie er an die besseren D1-Minis rankommt, dem empfehle ich, die größeren ESP-Boards zu kaufen, da dort die Regler meist leistungsfähiger sind. Nachdem ich das Ganze über eine Powerbank mit Strom versorge (läuft mit einer Ladung fast einen Monat) habe ich keine Receive Fails mehr. Das bringt mehr Stabilität als ein kleiner Elko am NRF24, zumindest war es bei mir so. Ansonsten läuft das Ganze bei mir absolut fehlerfrei. Ich bin begeistert.
:
Bearbeitet durch User
Joh schrieb: > die MI600 lassen sich auch mit der DTU-Pro nicht limitieren, das geht > nur mit den HM Invertern Danke für die Info!
Beitrag #7199014 wurde vom Autor gelöscht.
David B. schrieb: > Ziyat T. schrieb: >> @David B. (mystisch) >> @Jörg R. (rejoe2) >> wenn ihr über die console limitiert (befehl 100-1999): >> zuerst eingabe 7 = ZEROEXPORT aus, falls im settings aktiv ist/war, >> dann spielt das grid keine rolle mehr. >> >> probiert ev. in der console, eingabe 15, auf % wechseln und so mal >> testen >> >> bei mir laeuft beides, mit abs-watt und % > > Ab Mittwoch soll das Wetter in München wieder sonniger werden, dann kann > ich testen Hallo zusammen, So endlich Sonne in München, aber die viele Sonne hat sich auch wieder nicht limitieren lassen, weder direkt noch prozentual. Die Änderungen werden zwar acknowledged, aber mehr auch nicht. WR limitiert auch nicht nach 40s
Jörg R. schrieb: > Joh schrieb: >> die MI600 lassen sich auch mit der DTU-Pro nicht limitieren, das geht >> nur mit den HM Invertern > Danke für die Info! stimmt nicht ganz, mein MI1500 wird mit meiner DTU-Pro über modbus sehr wohl limitiert auch mit https://github.com/Ziyatoe/DTUsimMI-Hoymiles
:
Bearbeitet durch User
David B. schrieb: > Hallo zusammen, So endlich Sonne in München, aber die viele Sonne hat > sich auch wieder nicht limitieren lassen, weder direkt noch prozentual. > Die Änderungen werden zwar acknowledged, aber mehr auch nicht. WR > limitiert auch nicht nach 40s schade, ich werde das verfolgen
Jörg R. schrieb: > Ziyat T. schrieb: >> ok, wenn die ACK (0xD1) da ist, hat er schon verstanden was zu tun >> waere, er schickt naemlich als antwort auch eine 0x5A5A, aber was für >> gründen auch immer tut er nicht limitieren. in der doku sehe ich auch >> nichts anderes als cmd=0x51 mit 0x5a5a, verstehe nicht... schade > > Vielleicht ist es bei den alten aber auch schlicht ein anderes Kommando? > Bin wegen eines Posts im FHEM-Forum bei Zeile > https://github.com/atc1441/NETSGPClient/blob/main/src/NETSGPClient.h#L282 > gelandet, nach der es sehr vielleicht auch 0xC3 sein könnte (für > prozentuale Vorgaben). Werde aber aus den Gesamtzusammenhängen nicht > ganz schlau, diese Bitschubserei ist irgendwie nicht so meins... bei dem geht es ums NETSGP protocol, das haben wir leider nicht. viele chinesische alibaba-wr benützen diese https://de.aliexpress.com/i/4000444523624.html eine 0xC3 sehe ich auch nicht in der hoymiles-doku
:
Bearbeitet durch User
Alfons schrieb: > Flashen mit dem NodeMCU-PyFlasher funktionierte an meinem Notebook > (TB-Usb-A-Adapter) nur mit einem älteren ESP8266, während das Flashen > mit zwei ESP32 und zwei D1-Minis fehlerhaft war. Über PlatformIo traten > die Fehler nicht auf. Ebenso ließen sich die Binärdateien problemlos mit > dem ESPHome-Flasher 1.4.0-Windows flashen. Entweder es liegt an meinem > Notebook (i7/Windows11) oder am PyFlasher, keine Ahnung. Bei mir das gleiche. Dachte schon die Binaries sind corrupt, ich konnte die Firmware auch nur durch PlatformIO auf den ESP32 bekommen. Danke an alle Beteiligten für das Projekt, mein HM 1500 mit FW 10018 funktioniert damit absolut problemlos. Auch das Drosseln auf 600W funktioniert einwandfrei.
Ziyat T. schrieb: > eine 0xC3 sehe ich auch nicht in der hoymiles-doku ...ich auch nicht... Aber wie wir ja an der 0x91/0x92-Frage gesehen haben, ist die nicht zwingend 100% akkurat bzw. eindeutig. Da auch dieses Projekt hier mal mit dem LCirgendwas angefangen hatte, könnte es ja ggf. eine gewisse Verwandtschaft geben. Aber klar: sehr spekulativ...
Jörg R. schrieb: < stimmt nicht ganz, mein MI1500 wird mit meiner DTU-Pro über modbus sehr < wohl limitiert < auch mit https://github.com/Ziyatoe/DTUsimMI-Hoymiles Das kann gut sein, meine Angabe bezieht sich auf die Ausstattung DTU-Pro und Hoymiles WR MI-600 und HM-1500 und Leistungsanpassung in der S-Cloud jedoch ohne Chint Energiemeter oder direkte Modbus Steuerung. Danke für den Hinweis dann sind meine MI-600 weiter nützlich.
Meinen HM-1500 lese ich zur Zeit mit einem Raspberry Pi 4 und dem NRF Modul aus (MQTT). Vielen Dank an alle die das ermöglicht haben. Hab leider keine Erfahrung mit den ESP aber würde nun gerne einen kaufen um den Raspi woanders hinzubauen (Funk reicht dort nicht bis zum WR). Gibt es für dieses Projekt schon ein Gehäuse und Netzteil bzw. kann man eins empfehlen?
Kannst doch jedes 5V USB Netzteil nehmen von alten Handys etwa. Und Gehäuse wirds da nix fertiges geben können, da es jeder etwas anders aufbaut und zusammenlötet oder steckt. Da nimmt man doch ein 0815-Gehäuse von irgendwoher und paßt es irgendwie ein, reicht doch vollkommen, daß es reinpaßt, und mit Heißklebepistole anpicken.
Grisu schrieb: > Kannst doch jedes 5V USB Netzteil nehmen von alten Handys etwa. Gleich ein 3.3 V Netzteil wird schwierig? Ist wohl auch nicht nötig. Auf der Github Seite steht: "Any other ESP8266 Board with at least 4MBytes of ROM could work as well, depending on your skills." Wenn ich einen "D1 Mini Pro" habe was gibt es zu beachten? C und Python ist kein Problem für mich.
Günter H. schrieb: > Die .bin-Files sind jetzt schon unter > https://github.com/grindylow/ahoy bzw. > https://github.com/tbnobody/OpenDTU > jeweils unter dem Menüpunkt "Actions" chronologisch aufgelistet. Was ist zum OTA Update zu verwenden? Einfach das opendtu-generic.bin? Oder muss man ein firmware.bin mit anderem Inhalt erzeugen/laden? Wenn ja, wie, bzw. wo?
Einfach die passende aktuelle .bin laden und über das Webinterface upgraden. Danach startet der ESP Neu und die neueste Firmware sollt laufen.
Ich würde gerne einen ESP32-POE von Olimex mit Ahoy nutzen. https://github.com/OLIMEX/ESP32-POE Dazu müsste aber die LAN Unterstützung noch in den Code mit rein. Leider kenne ich mich damit nicht aus. Kann mir hier jemand weiter helfen?
Giuseppe M. schrieb: > Einfach die passende aktuelle .bin laden und über das Webinterface > upgraden. Soll das eine Antfort auf meine Frage sein? Falls ja: Ich frage ja gerade, welches die "passende" bin ist.
Dann habe ich wohl Deine Frage falsch verstanden. Wenn Du nicht selber mit z.B. VSCode deine .bin erstellst, dann nimmst die neueste aus dem Bereich Actions in Github (Achtung man kann nur die bin herunterladen, wenn man in github angemeldet ist). Wenn Du einen ESP32 verwendest kannst entweder die Ahoy für ESP32 bin verwenden oder die opendtu-generic.bin.
Er meint: „ ….man kann die bin nur herunterladen, wenn man in github angemeldet ist“.
Hallo, mal kurze Frage: Wie schnell werden die Daten über die OpenDTU aktualisiert? Im Hoymiles Webportal ist die Auflösung ja nur 15 Minuten und die Daten meistens über eine Stunde alt.
Also ich sehe die Daten meist innerhalb von 5-10 Minuten mit der DTU aktualisiert und die sind dann auch aktuell für die letzte 1/4 Stunde. Die Daten werden hier alle 30s abegefragt, nur bekommst oft keine Antwort.
Daniel schrieb: > Wie schnell werden die Daten über die OpenDTU aktualisiert? Ich erhalte die Daten alle 5 Sekunden. Man kann aber auch noch kürzere Zeiträume einstellen.
Giuseppe M. schrieb: > Dann habe ich wohl Deine Frage falsch verstanden. Ja. :-) Aber auch diese Antwort ist nicht Eindeutig. Nochmal: Ist die opendtu-generic.bin aus dem git .zip Identisch mit der selbst erzeugten firmware.bin? Kann ich also einfach die opendtu-generic.bin übers OTA Update hochladen?
Ja. Ich hoffe, dass dies eine eindeutige Antwort ist.
Hallo zusammen, Ich bin kein Progrogrammierer und wäre für Hilfe Dankbar. Ich habe meinen Hm-600 erfolgreich mit dem esp8266 mit opendtu verbunden. Beim Homeassistant Mqtt installiert.mqtt-user Benutzer angelegt. bei der Konfiguration Broker:core-mosquitto Port 1883 Benutzername mqtt-user das gleiche im Opendtu eingetragen. wie muss ich nun weiter machen würde mich freunen wenn ich die Daten schön im Homeassistant anzeigen kann grüße der nikolaus
nikolaus schrieb: > Ich habe meinen Hm-600 erfolgreich mit dem esp8266 mit opendtu > verbunden. Läuft opendtu nicht nur auf nem esp32?
Jürgen E. schrieb: > Hallo, > > habe heute mein BKW zum Testen mal in Betrieb genommen. > Die DTU wollte ich zuerst mit einem ESP-WROOM-32 aufbauen. > Leider klappte das nicht. Habe es einfach nicht hinbekommen. > Ich konnte problemlos und fehlerfrei das Teil programmieren aber es > erschien kein AP. Die rote LED blinkte nur in kurzen Abständen. > Mit einem D1 mini klappte es dann sofort. Guten Morgen, ich habe genau das gleiche Problem. Egal ob vorkompilierte Version oder selbst mit Plattform IO kompiliert. Flashe ich das Programm auf mein ESP32 Devkit C Board (eigentlich nichts besonderes) blinkt nur schnell die LED und nichts weiter passiert. das Board ist in Ordnung, andere Projekte lassen sich Problemlos darauf flashen etc. Hat hier jemand die Firmware erfolgreich auf ESP32 Hardware zum laufen gebracht?
Okay mit der integrierten Flashfunktion in Visual Studio Code scheint es doch zu funktionieren.
Angehängte Dateien:
-
hoy-ek-003.jpg
57 KB
Was soll so was ? Das ist ein Schlag ins Gesicht von Allen, die hier aktiv mitarbeiten. https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-inverter-/2224890964-168-6820 https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=58131475
Ob das das zuständige Finanzamt weiß? Wenn jemand mir die Bauteile schickt, ein Rücksendeschein dabei legt, flashe ich sowas umsonst, vorzugsweise ESP32, weil stabiler.
was-soll-so-was schrieb: > Was soll so was ? > Das ist ein Schlag ins Gesicht von Allen, die hier aktiv mitarbeiten. > > https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-inverter-/2224890964-168-6820 > > https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=58131475 Wow rechtlich aber recht schwammig, unter welcher Lizenz läuft denn die AHOY DTU? Auf der anderen Seite, weder Gehäuse und Netzteil. Dafür noch 86Euro abdrücken. Jemand der noch Gehäuse und Netzteil spendieren muss, der sollte auch so weit bewandert sein auf ein Wemos die DTU installieren zu können…
:
Bearbeitet durch User
David B. schrieb: > Auf der anderen Seite, weder Gehäuse und Netzteil. Dafür noch 86Euro > abdrücken. Jemand der noch Gehäuse und Netzteil spendieren muss, der > sollte auch so weit bewandert sein auf ein Wemos die DTU installieren zu > können… ...nicht mal einen Kondensator drauf... Na ja, mal abgesehen von den Steuer- und Lizensierungsfragen hat mal an anderer Stelle jemand gemeint: "Jedes Angebot ist ein gutes Angebot! Man muss es ja nicht annehmen..." Indirekt macht dieser Anbieter ja "Werbung" für das Projekt. Ärgerlich wird es nur, wenn jemand, der dafür derart viel Moos liegen läßt, dann hier aufschlagen würde und sich beschweren, weil irgendwas nicht so läuft, wie er das als "Verbraucher" erwarten darf, der schließlich sein sauer verdientes Geld dafür ausgegeben hat. Soweit ist es ja (zum Glück!) bisher nicht gekommen. Aber an sich sollte es in diesem Thread ja v.a. um Entwicklungsthemen gehen, und nicht um allgemeinen Stress beim Flashen von ESP's oder der Frage, wie man bestimmte Automatisierungslösungen dafür konfiguriert...
Jörg R. schrieb: > Aber an sich sollte es in diesem Thread ja v.a. um Entwicklungsthemen > gehen, und nicht um allgemeinen Stress beim Flashen von ESP's Richtig, nur treibt es nicht so fitte Leute in die EBAY Arme. Ev. sind es durchaus Wechselrichter Insider, die aber so'n Flash Kram nicht hinbekommen, bzw dessen Anbindung in die Smarthome-Welt gerne hätten. Zusätzlich könnten Diese dann dem Entwickler eine Spende generieren, was sonst sicher nicht passiert und DAS würde ich gut finden.
Hallo, ich würde zur allgemeinen Erheiterung gerne mal eine totale Anfängerfrage stellen: Habe heute Post bekommen und Wemos D1 Mini sowie NRF24L01+ Modul aus https://github.com/lumapu/ahoy/issues/230 erhalten. Das Wemos zu verkabeln bekomme ich hin. Das NRF24L01+ hat aber ein engeres Rastermaß (1.27?). Buchsenleisten finde ich dafür, aber wie bekomme ich dann die Leitungen vom Wemos da dran? Das besagte NRF24L01+ benötigt keine weitere Antenne, so wie hier auf diversen Fotos zu sehen?
Löten statt stecken, ist sowieso viel besser?
Zwischenzeitlich habe ich herausgefunden, dass OpenDTU den Olimex
ESP32-POE unterstützt.
Ich würde aber gerne Ahoy nutzen.
Reicht es aus in der platformio.ini den Olimex einzufügen?
z.B. so:
[env:esp32-poe]
platform = espressif32
board = esp32-poe
build_flags = -D RELEASE
monitor_filters =
;default ; Remove typical terminal control codes from input
time ; Add timestamp with milliseconds for each new line
;log2file ; Log data to a file “platformio-device-monitor-*.log”
located in the current working directory
Oder muss da noch mehr geändert werden?
Hallo zusammen, vielleicht schon bekannt: Für das Hoymiles DTU Pro steht der Sourcecode (stand 06.2020) auf gitee -> https://gitee.com/iotloves/hoymiles-DTU-PRO/ Viel Spass noch an alle Mistljo
Hi. Ich habe den HM-800 und wollte OpenDTU ohne angeschlossene Module testen. Aber mein Wechselrichter tut absolut nichts (LED leuchtet nicht). Ist das so korrekt oder ist mein WR tot?
Woher denkst Du bezieht der WR seine Energie?
Achso, also rein aus den Modulen? Dann funktioniert die Funkeinheit nur wenn Sonne da ist oder wie?
Na in der Nacht sendet er jedenfalls nix. Sonne brauchts dazu nicht. Außerdem solltest du wissen, daß die Netzseite abgeschaltet ist wenn er nicht in Betrieb oder abgesteckt ist. Was sollte er dir außerdem senden, daß keine Produktion stattfindet??? Sehr informativ .... daß merkt die DTU auch so wenn sie ihn nicht erreicht. Oder wär dir lieber er säuft sogar noch Strom nur um dir zu melden wieviel du grad sinnlos verbrauchst?
:
Bearbeitet durch User
Helmut H. schrieb: > Wenn jemand mir die Bauteile schickt, ein Rücksendeschein dabei legt, > flashe ich sowas umsonst, vorzugsweise ESP32, weil stabiler. Dann schick mir mal deine Adresse bitte Volker
Melde Dich hier an, dann auf "der_andere" klicken und mir dann eine PN schicken ob Du Ahoy oder OpenDTU geflasht haben willst.
Was ist denn der Unterschied zwischen OpenDTU und Ahoy? Ich lese zwar schon eine Zeit lang mit aber hab dazu den Faden verloren.
https://github.com/tbnobody/OpenDTU https://github.com/lumapu/ahoy Ist Geschmacksache, Web-Ansicht, MQTT Ausgabe usw.
Daniel schrieb: > Was ist denn der Unterschied zwischen OpenDTU und Ahoy? Der wesentliche Unterschied ist, dass OpenDTU nur auf dem ESP32 läuft. Ahoy gibt es Version für ESP8266 und ESP32. Zudem kann Ahoy Limit im Wechselrichter setzen. OpenDTU kann das noch nicht.
Hier die MQTT Topic zum Steuern des ESP32 mit OpenDTU, das liest sich so, dass steuern möglich ist: https://github.com/tbnobody/OpenDTU/blob/master/docs/MQTT_Topics.md
Helmut H. schrieb: > Hier die MQTT Topic zum Steuern des ESP32 mit OpenDTU, das liest sich > so, dass steuern möglich ist: Hallo Helmut, ja, sieht wirklich so aus, als ob nun Limit setzen mit OpenDTU funktioniert. Vor einigen Wochen, war das Limit setzen für mich der Grund von OpenDTU auf Ahoy zu wechseln. Ich werde OpenDTU nun mal wieder testen, weil es lief immer sehr Stabil. Wenn es wirklich funktioniert, dann kann ich nun endlich den Olimex ESP32-POE verwenden. Mit Ahoy hatte ich anfangs Probleme mit einem Wemos D1 mini. Als dann endlich ESP32 support für Ahoy kam, bin ich auf ESP32 gewechselt und seither läuft Ahoy stabil bei mir. Gruß Giuseppe
:
Bearbeitet durch User
Hallo zusammen, sehe ich das eigentlich richtig, dass es keinerlei Authentifizierung zwischen DTU und WR gibt? Das heißt jeder der die Kommunikation zwischen DTU und WR mithören kann, kann sich auch selbst als DTU ausgeben und zum Beispiel den WR ausschalten?! Gruß, solmate
Dazu muss dieser jemand die Seriennummer des Wechselrichters wissen. Und was hätte dieser jemand von dem Ganzen?
Die Funk Reichweite der Wechselrichter ist relativ begrenzt, also müsste ein potentieller Angreifer auch in der Nähe sein und wie schon geschrieben die Seriennummer des Wechselrichters kennen. Meine persönliche Meinung dazu ist, dass sich Angreifer nur mühe machen, wo es sich lohnt. Bei einem kleinen Balkonkraftwerk, sehe ich keinen finanziellen Anreiz sich damit in boshafter Absicht zu beschäftigen.
N'abend zusammen, bessteht Hoffnung auf einen Support der HMS Serie?
Warum nicht dort fragen wo's hingehört? Beitrag "Re: Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"
:
Bearbeitet durch User
Wir suchen noch Nutzer eines HM-350 oder HM-1000 die mal ihre PN / Part Number auslesen und zur Verfügung stellen. Die Informationen bitte ins OpenDTU Github oder im Discord Chat #opendtu-esp32: https://github.com/tbnobody/OpenDTU/issues/35 Laut der Serial Number Liste und Wortmeldungen hier im Forum sind dies HM-350: Martin P. (mpolak77) 1121 72xxxxxx Herbert K. (avr-herbi) franz (Gast) Kev (Gast) TSUN TSOL-M350 Für den HM-1000 habe ich hier keine Wortmeldungen / Besitzer gefunden. Also wer ein noch unbekanntes HM- oder TSUN-Modell hat und die Information aus OpenDTU auslesen kann wären wir dankbar.
Isnoahoy schrieb: > Wir suchen noch Nutzer eines HM-350 oder HM-1000 die mal ihre PN / Part > Number auslesen und zur Verfügung stellen. > > Die Informationen bitte ins OpenDTU Github oder im Discord Chat > #opendtu-esp32: > https://github.com/tbnobody/OpenDTU/issues/35 > > Laut der Serial Number Liste und Wortmeldungen hier im Forum sind dies > > HM-350: > Herbert K. (avr-herbi) Hallo, HM-350 hab ich. Ich hatte die Uralte SW am laufen auf ESP-8266 bis ich irgendwann kaum noch Antworten bekommen habe. Hab seit dem in der Richtung nix mehr unternommen, da der Code ja auch von der Arduino Umgebung auf platformio umgestellt wurde und ich auch kein "C" kann. Habe auch schon eine ganze Zeit nicht mehr mitgelesen und kenne die aktuellen Fortschritte nicht. ESP-32 hätte ich. HM-350 könnte ich im Prinzip testen. HM-400 könnte ich gegenchecken, falls nötig. Müsste mir nur mal jemand kurz schreiben, was ich tun soll. Dann könnte ich das evt. am Wochenende mal versuchen.
vielleicht etwas offtopic hat jemand einen Hoymiles als Batterie Wechselrichter in Benutzung mit Limit? Meine Idee ist es einen HM-WR zu nehmen, auf 50W limitieren und an der Batterie laufen zu lassen für Nachteinspeisung.
Dir fehlt das Grundverständnis der Funktion des WR
@NichtKohlebürstenpower Schätze er meint, dass das nicht geht, weil die Dinger Netz als Führung brauchen, bzw mit nur 'ner Batterie nicht starten werden.
Helmut H. schrieb: > Schätze er meint, dass das nicht geht, weil die Dinger Netz als Führung > brauchen, bzw mit nur 'ner Batterie nicht starten werden. Wenn er das meint, hat er nicht korrekt gelesen. Das Problem mit "normalen einspeise WR" ist der MPPT. Mit Batterie läuft dieser an das Maximum da die Batterie sehr niederohmig ist. Die Frage ist, ob der HM dies entsprechend sauber begrenzt auf das eingestellte Limit? Bzw. ob das schon jemand versucht hat oder so betreibt.
> Die Frage ist, ob der HM dies entsprechend sauber begrenzt auf das > eingestellte Limit? Bzw. ob das schon jemand versucht hat oder so > betreibt. Im Photovoltaik Forum mal lesen/suchen. Bei youtube gibt es auch einige Videos dazu. Die Batt./Akku muss halt im MPPT Bereich vom Inverter liegen. Mit 12V dürfte das so einfach nicht klappen. Eher ein vielfaches von 12V. Alternative: 12V Batt und preisgünstigen WR der 50 W kann und dann die Geräte da reinstecken, wenn möglich. Macht nicht immer Sinn, manchmal aber schon. Ich kenne die Randbedingungen ja nicht. Ich hoffe, das hilft ein wenig weiter.
Mit Batterie läuft dieser an das Maximum da die Batterie sehr niederohmig ist. Völliger Stuss!
John P. schrieb: > vielleicht etwas offtopic > > hat jemand einen Hoymiles als Batterie Wechselrichter in Benutzung mit > Limit? > > Meine Idee ist es einen HM-WR zu nehmen, auf 50W limitieren und an der > Batterie laufen zu lassen für Nachteinspeisung. Hallo zusammen, zuerst einmal möchte ich meinen Hut vor dem ziehen, was Ihr hier auf die Beine gestellt habt. Um mal auf das Thema Nachteinspeisung einzugehen, muss ich etwas weiter ausholen. Hoffentlich nicht zu weit, ansonsten bitte durch die Moderation verschieben. Momentan betreibe ich einen HM-400, um unter der 600W-Grenze zu bleiben, aber eine Erweiterung auf 3 HM-1500 ist schon im Gange. Daher hatte ich mit einem Kollegen auch schon darüber diskutiert, den HM-400 dann als Batteriewechselrichter zu 'missbrauchen'. Dies vor dem Hintergrund, dass die Batteriekompatibilität der Hybridwechselrichter doch seeeehhr eingeschränkt ist und wir über eine AC-gekoppelte Lösung sinniert haben, um beliebige 48V-Akkus nutzen zu können. Da eine Leistungsregelung mit den HMs mittlerweile möglich ist, könnte man das Ganze mit einer Leistungsmessung am Hausanschluss (eigenes Smartmeter mit MQTT oder MQTT-Rüssel am Stromzähler) kombinieren, um eine Nulleinspeisung bei Akkubetrieb zu erzielen, schließlich möchte man mit dem Akku nicht das Stromnetz füttern. Bevor jetzt geantwortet wird, dass das ja so nicht gehen würde, folgende Gedanken: - der HM-400 hat momentan ca. 770W installiert PV-Generatorleistung zur Verfügung (2x JAMS60S20-385 parallel). Leistungsmessung erfolgt mit AVM DECT 210, dort sieht man dann sehr gut, dass der HM400 auch sauber bei 400W abregelt. - dass der Betrieb mit einer anderen DC-Quelle als PV-Modulen an den PV-Anschlüssen möglich ist, haben einige Mitforisten erfolgreich demonstriert, in dem sie ihre HMs nachts mit einem Labornetzteil betrieben haben, daher sehe ich wenig Gründe, weshalb ein Akku nicht auch als DC-Quelle dienen könnte Viele Grüße
Was ihr diskutiert beschrieben schon ein paar Leute in ihren YouTube Kanälen. ZB https://youtu.be/yOcoux9IbzM Und das scheint auch brauchbar zu funktionieren.
:
Bearbeitet durch User
Angehängte Dateien:
-
Hoymiles_Ahoy_.jpg
110 KB
Ein wunderbares Projekt – klasse Leistung! Nach meinem Steckbrettaufbau habe ich mir das Layout von Ahoy! vorgenommen und etwas geändert. Die Gundschaltung ist natürlich unverändert! Ich würde in der nächsten Woche (wenn es keine Änderungen mehr gibt) bei Aisler Platinen bestellen (3.18€ Stück). Wenn noch jemand Ideen hat oder sich ranhängen will kurze PM an mich.
Ich habe vermutlich erst 50% des Threads 'geschafft', eventuell ist meine Frage/Anmerkung schon beantwortet – ich bitte dies zu entschuldigen… Ist das Channel-Hopping 'Problem' gelöst? Mein Eindruck ist, das die verwendeten nRF-Module eben keine 'P' Versionen sind. Und nur die nRF24L01P scheinen das automatische Frequency-Hopping zu unterstützen und bei der Verwendung dieser Module ist dann auch kein entsprechender programmatischer Aufwand notwendig. Oder liege ich völlig falsch?
VFR-Reiter schrieb: > - dass der Betrieb mit einer anderen DC-Quelle als PV-Modulen an den > PV-Anschlüssen möglich ist, haben einige Mitforisten erfolgreich > demonstriert, in dem sie ihre HMs nachts mit einem Labornetzteil > betrieben haben, daher sehe ich wenig Gründe, weshalb ein Akku nicht > auch als DC-Quelle dienen könnte Gibt es Links zu diesem Thema auf entsprechende Threads? Ich wollte an einem 16S LiFePO4 Akku ein DPM8624 als eine einstellbare Stromquelle (via RS-485 Interface) nutzen um 3 parallele HM-400 anzusteuern. Gibt es zu so einem Ansatz eine Diskussion hier im Forum oder Link-Tips außerhalb? Vielen Dank thomas
excel bitte noch Ergänzen MI-600 mit 104161609005
VFR-Reiter schrieb: > ... könnte man das Ganze mit einer Leistungsmessung am Hausanschluss > (eigenes Smartmeter mit MQTT oder MQTT-Rüssel am Stromzähler) > kombinieren, um eine Nulleinspeisung bei Akkubetrieb zu erzielen ... Genau das ist auch mein Ziel. Nulleinspeisung realisieren mit einem HM300 (oder auch 2 parallel) , der an einen 48V Akku angeschlossen wird und durch DTU die benötigte Leistung reguliert wird. Die Einspeisung funktioniert definitiv. Auch das manuelle Limitierung der Leistung durch AhoyDTU. Frage ist, ob die automatische Leistung-Regulierung auch möglich ist. Wenn jemand das schafft, stabile Nulleinspeisung mit DTU zu realisieren, dann wäre das wahrscheinlich die einfachste Lösung dafür (für mich auf jeden Fall). Schon mal vielen Dank im Voraus dafür, weil ich fest daran glaube, dass es möglich ist 😀 Meine Programmierkentnisse sind dafür leider zu schwach.
Angehängte Dateien:
Ich habe für meine Familie und einen Freund auch insgesamt vier Module aufgebaut und heute noch ein Gehäuse dafür gelasert. Danke für das Projekt, es funktioniert bei allen Invertern bestens (1x HM 600, 2x HM 800, 1x HM 1500).
Tobias schrieb:
...und heute noch ein Gehäuse dafür gelasert. Danke für das
Cool das Gehäuse ! Sehr schön gemacht !
Ich hab eine alte Streichholzschachtel genommen, der ESP8266 mit Nordic-Modul paßt fast exakt hinein. Natürlich ohne externe Antenne, nur auf einer Seite den Einlaß fürs Kabel ausgeschnitten und das ganze einfach mit Isolierband umwickelt. Vollkommen ausreichend für den (meinen) Zweck.
Moin aus dem momentan sonnigen Hamburg. klasse, hier werden richtig spannende Dinge veranstaltet und auch ich zähle mich zu den Leuten, die nicht gerne wild rumfunkende Geräte im Haus haben ohne zu wissen, was die denn tatsächlich tun. Seit ein paar Tagen steht mein Balkonkraftwerk am Wohnzimmerfenster und läuft im Testbetrieb; leider ohne dass ich -außer einer grün blinkenden Leuchtdiode- auch nur die geringste weitere Information über Zustand/Arbeit der Anlage erhalte. Als WR wurde ein TSOL-M800(DE) von TSUN ohne DTU mitgeliefert. Rein äußerlich sieht der den ungefähr gleich dimensionierten Hoymiles sehr ähnlich und die entsprechende Suche zeigte diesen Beitrag. Den Seriennummernbeginn 1141 kann ich bestätigen. RaspiPi habe ich, Linux kann ich, aus Programmieren bin ich als inzwischen "nur noch Administrator" -von Shellssripten abgesehen- absolut raus, denke aber wieder reinkommen zu können. Ist denn inzwischen raus, dass mit der hier erarbeiteten Lösung auch die TSOLs befragt werden können (und auch antworten? LG - Ingo
Angehängte Dateien:
-
Zwischenablage01.jpg
210 KB
Pavel schrieb: > Frage ist, ob die automatische Leistung-Regulierung auch möglich ist. > Wenn jemand das schafft, stabile Nulleinspeisung mit DTU zu realisieren, > dann wäre das wahrscheinlich die einfachste Lösung dafür (für mich auf > jeden Fall). Das funktioniert generell nicht, bzw machen auch die Profi-Systeme wie Victron nicht so Alle Systeme eiern immer um den Nullpunkt rum, da wird nichts im ms-Bereich geregelt In der Regel stelt man das dann so ein das immer ein bsichen Strom aus dem Netz gezogen wird, z.B. 30W Man gibt ihm alle 1-3 Sekunden einen neuen Wert Der Inverter eiert dann in dem Beispiel zwischen ca. 50W Bezug und 10W verschenkt rum, das spielt aber finanziell fast keine Rolle Große Lasten wie Herd müssen eh aus dem Netz kommen Anbei ein Screenshot eines Victron
--> an die Mods und OT: Würde es nicht mal Sinn machen hier eine 2. Seite zu eröffnen? Immer den ganzen Mega-Thread zu laden ist nervig
... mit eingeschalteter Seitenaufteilung läuft das auch bei diesem Thread ganz entspannt. Zum Suchen im gesamten Thread - dann natürlich die Seitenaufteilung abgeschaltet - ist ein Thread günstiger.
Günter H. schrieb: > ... mit eingeschalteter Seitenaufteilung läuft das auch bei diesem > Thread ganz entspannt. > > Zum Suchen im gesamten Thread - dann natürlich die Seitenaufteilung > abgeschaltet - ist ein Thread günstiger. Danke, das Feature kannte ich noch nicht
Heinz R. schrieb: > In der Regel stelt man das dann so ein das immer ein bsichen Strom aus > dem Netz gezogen wird, z.B. 30W > Man gibt ihm alle 1-3 Sekunden einen neuen Wert > Der Inverter eiert dann in dem Beispiel zwischen ca. 50W Bezug und 10W > verschenkt rum ... so habe ich mir das auch ungefähr vorgestellt. Dass es nicht genau Null hält, ist klar. Das reicht vollkommen. Nur bräuchte ich am besten ein Beispiel-Regelungprogramm im Raspberry, was ich dann "analysieren " könnte um das ganze auch verstehen. Und auf meine Situation anpassen.
Hast DU denn überhaupt die aktuellen Zählerwerte zur Verfügung? Wie liegen diese vor?
Ich bin momentan gaaanz am Anfang der Planung. PV Anlage läuft seit fast einem Jahr. Jetzt möchte ich Akku nachrüsten. Leistungsmeter habe ich noch nicht, werde aber Shelly EM einbauen. Von meinem 2R-Zähler weiss ich aber jetzt schon, dass ich nur ca. 50% der erzeugten Energie ausnutze. Deswegen suche ich eine, für mich machbare Lösung für "Nulleinspeisung ". Und Hoymiles DTU sieht als sehr gut geeignet aus. Meine Vorstellung: Raspberry liest die auktuellen Zählerwerte regelmäßig aus und sendet and DTU die gewünschte Maximalleistung, die man im Moment braucht .... sollte mMn. funktionieren.
Wenn du eine sehr gute und stabile Verbindung zum WR hinbekommst könnte es hinlänglich gut funktionieren. Die Begrenzung selbst in Watt funktioniert bei mir sehr gut. Problem sind halt schnelle und sehr hohe Lastwechsel, schaltest den E-Herd aus sind gleich mal 1-3kW plötzlich zuviel Einspeisung, bis du die wieder runtergeregelt bekommst vergehen Minuten.
:
Bearbeitet durch User
Pavel schrieb: > Leistungsmeter habe ich noch nicht, werde aber Shelly EM einbauen. warum nicht einfach den vorhandenen Zähler per SML auslesen? Grisu schrieb: > Problem sind halt schnelle und sehr hohe Lastwechsel, schaltest den > E-Herd aus sind gleich mal 1-3kW plötzlich zuviel Einspeisung Das ist sehr einfach zu lösen - die generelle maximale Einspeisung z.B. auf 500W begrenzen Es geht ja nicht darum jede Spitze abzufangen, viel interessanter ist das der AKku die ganze Nacht durch hält
Tobias schrieb: ...und heute noch ein Gehäuse dafür gelasert. Danke für das Welche Hardware nutzt Du dazu?
Sorbit schrieb: > Welche Hardware nutzt Du dazu? Einen Sculpfun S10 und eine 3mm HDF Platte. Gruß Tobias
Beitrag #7218601 wurde vom Autor gelöscht.
Beitrag #7219710 wurde vom Autor gelöscht.
Hallo zusammen! Ich hab mir gerade das Bundle fertiggestellt und über PlatformIO geflasht. Dort meine WLAN-Daten eingetragen, die maximale Anzahl an Invertern auf 10 geändert und ich komm auch auf die Startseite. Aber sobald ich den Punkt "Setup" aufrufen möchte, verliert der ESP8266 die Verbindung zu meinem WLAN und öffnet den eigenen Access Point. Wenn ich über den AccessPoint vom ESP8266 verbunden bin, verliert er auch hier wieder die verbindung, sobald ich auf Setup in der Weboberfläche klicke. Ist das Verhalten jemandem bekannt und hat eine Lösungß Danke, LG Christian
Da es mehrere Fragen zur Schaltung und zur Leiterplatte des Hardwareinterface zum Hoymiles gibt hier kurz eine Antwort: Im Angang der Schaltplan für das WeMos D1 mini Modul und das Wireless 2.4GHz Funk Modul (nRF24L01+). Alle ESP8266 I/Os werden mit 3,3V betrieben und sind nicht 5V-tolerant! D.h. die rausgeführten Schnittstellen I2C und UART dürfen auch nur mit 3.3V betrieben werden. An der Klemme K3 können extern 5V eingespeist werden. Wenn ein Satz erfolgreich bestückt ist (nächste Woche) stelle ich die CAD-Daten hier zur Verfügung. Da ich mit dem System EAGLE arbeite, nur als *.BRD und *.SCH. Die Board-Daten kann ich auch als Gerber-Daten exportieren. Weiterhin stelle ich die Fertigungsdaten (derzeit Version 1.0) frei bei AISLER [1] rein, damit jeder bei Bedarf Platinen selbst ordern kann. Die erste Charge an Leiterplatten hatte ich schon letzten Sonntag bestellt, so dass derzeit keine LP’s mehr vorhanden sind. Diejenigen die LP’s erhalten, habe ich über E-Mail informiert. [1] https://aisler.net/p/EAYHGSED
:
Bearbeitet durch User
wenn die 3v und die 5v reingehen, dann sollte der Pfeil im Schaltplan auch nach innen zeigen?
Angehängte Dateien:
-
hhh.JPG
88 KB
Auf Seite 12 hat der Nikolaus eine Frage zum MQTT gestellt. Ich stehe vor dem selben Problem mit Ahoy. Ich bekomme per MQTT einfach keine Verbindung zu Homeassistant soweit habe ich alles installiert (Mosquitto broker) für Ahoy habe ich es einmal mit der normalen Homeassistant IP versucht und einmal einen mqtt-user angelegt aber es taucht einfach nicht auf. Hat jemand eine Idee warum? Hab da wirklich mehr als 5 Stunden intensiv versucht.... Versucht habe ich es mit 0.5.15 und jetzt 0.5.17...
planlos schrieb: > wenn die 3v und die 5v reingehen, dann sollte der Pfeil im Schaltplan > auch nach innen zeigen? Dazu fällt mir wirklich nur dein Nickname ein ... - nomen es omen?!?
planlos schrieb: > wenn die 3v und die 5v reingehen, dann sollte der Pfeil im Schaltplan > auch nach innen zeigen? Dazu fällt mir wirklich nur dein Nickname ein ... - nomen es omen?!? Elektronik und deren Schaltpläne sind dir offensichtlich ein spanisches Dorf.
Grisu schrieb: > Dazu fällt mir wirklich nur dein Nickname ein ... - nomen es omen?!? das mit den Pfeilrichtungen sehe ich genau so... Erklär mal welche DIN/ISO oder was auch immer das beschreibt. Und wenn da Spannung raus kommt geht der Pfeil in die Quelle? Sehr logisch
So wie man bei der Masse einen dicken Querstrich macht ist es der Pfeil bei den Versorgungsspannungen. Hab ich nie anders gemacht und auch nie anders gelernt (ok ist schon einige Jahre her). Bei der Masse oder Erdung (3 Striche) ist dir die Richtung in die der Strom fließt oder wo diese schaltungs- und aufbautechnisch realisiert ist auch egal. Es heißt nicht mehr und nicht weniger als dort geht's zu einer Spannung und alle "Pfeile" mit dem selben Wert kann man sich als miteinander verbunden vorstellen, um sie nicht einzeln mit vielen Strichen einzeichnen zu müssen.
:
Bearbeitet durch User
Christian F. schrieb: > Hallo zusammen! > > Ich hab mir gerade das Bundle fertiggestellt und über PlatformIO > geflasht. Dort meine WLAN-Daten eingetragen, die maximale Anzahl an > Invertern auf 10 geändert und ich komm auch auf die Startseite. > > Aber sobald ich den Punkt "Setup" aufrufen möchte, verliert der ESP8266 > die Verbindung zu meinem WLAN und öffnet den eigenen Access Point. Wenn > ich über den AccessPoint vom ESP8266 verbunden bin, verliert er auch > hier wieder die verbindung, sobald ich auf Setup in der Weboberfläche > klicke. > > Ist das Verhalten jemandem bekannt und hat eine Lösungß > r > Danke, LG > Christian Guten Morgen. Ich bin jetzt mal draufgekommen, woran es liegt -> ich hab die max. Inverteranzahl auf 5 erhöht. Senk ich sie wieder auf 3, lädt das Setup. Andernfalls restartet der ESP8266. Ist das ein Bug, oder mach ich was falsch dabei? Danke, LG Christian
Angehängte Dateien:
-
signal-2022-10-15-154236_002.jpeg
310 KB -
signal-2022-10-15.jpeg
310 KB
Hallo zusammen, kurze Rückmeldung: D1-Mini aus Vorrat =>check 4pcs NRF24L01+ bestellt =>check (https://www.amazon.de/gp/product/B07XYYXVFF) Das ganze auf Experimentierplatine zusammengelötet, checcken =>check flashen mit Tasmonizer =>check Hoymile Modul ab/anbauen für Seriennummer :-( =>check Eingabe der Infos auf Webseite =>check 2 Minuten warten... =>endlos LÄUFT!!! Einbinden in FHEM =>check Der SONOFF SP111 ist schon in der Kramkiste verschwunden, den Hoymiles Werten vertraue ich eher! Grandiose Arbeit! Vielen Dank! Rolf
/setup anwählen .... Es wird der AP geöffnet. ...das ist ein Absturz (sieht man im aerial log). Er lädt sich Werte aus dem eeprom, die Müll sind. Wenn du den Flash mal komplett löschst sollte es auch gehen. Ich schätze mal mit der geplanten Umstellung auf Filesystem hat sich der bug erledigt. PS: Der bug kommt auch zu Tage, wenn der geflashte Code (viel) größer wird. Das hatte ich, durch eine Erweiterung um das Nokia5110 Display auch.
also: Nur zur Klarstellung, da ich nicht sicher bin, ob ich verständlich war! Wollte nicht MEINE Leistung in den Vordergrund stellen, sondern darstellen, dass die Installation problemlos und straight forward einfach nur einwandfrei funktioniert hat! Das bin ich von anderen (oder eigenen) Projekten wahrlich nicht gewohnt! Also noch einmal: Grandiose Arbeit von allen die hier einfach nur super gemeinsam einen Aspekt nach dem anderen identifiziert und enträtselt haben!!!
@rolf: da musst du keine Angst haben. Ich schliesse mich dem Dank an und finde es auch ne echt gute Leistung. Das mit dem bug bezog sich auf den Beitrag von Christian. Ich wollte nur n tip geben, wie man da rauskommt. (1malig an die URL ein /erase anhängen). Die Änderung auf 5 Inverter war ein Zufallstreffer von ihm. .... Obwohl - Hauptsache es geht jetzt. Nochmal @rolf: Ich finde die Idee mit dem Solardach über dem Aufgang cool.
Angehängte Dateien:
-
image.jpg
240 KB
fx2 schrieb: > /setup anwählen .... Es wird der AP geöffnet. > ...das ist ein Absturz (sieht man im aerial log). Er lädt sich Werte aus > dem eeprom, die Müll sind. Wenn du den Flash mal komplett löschst sollte > es auch gehen. Ich schätze mal mit der geplanten Umstellung auf > Filesystem hat sich der bug erledigt. > PS: Der bug kommt auch zu Tage, wenn der geflashte Code (viel) größer > wird. Das hatte ich, durch eine Erweiterung um das Nokia5110 Display > auch. Danke für den Tipp. Jetzt habe ich keinen Absturz mehr. Dafür hab ich aber keine Möglichkeit mehr, die Wechselrichter einzutragen. Mit 3 möglichen Invertern sind die Eingabefelder hier. Wenn ich auf höher als 3 stelle, sind die Eingabefelder weg :(. Danke, LG Christian
:
Bearbeitet durch User
Well, fuer diejenigen, die an einer Loesung mit 'Nulleinspeisung' interessiert sind, ich kann sagen, dass sich so ein System sehr gut mit Modul-WR realisieren laesst. Ich habe das letztes Jahr mit einem kleineren, aelteren WR umgesetzt und es laeuft seither stabil und zuverlaessig. Vorab aber ein grosses Dankeschoen an all die Entwickler dieses Projektes, alle Achtung was da entstanden ist. Von Anfang an habe ich gehofft, dass mit der Analyse der Hoymiles-WR ein 'Nulleinspeisesystem' moeglich werden wird, und als vor ca. 3 Monaten die Leistungsregelung erstmals funktionierte, da habe ich mir dann auch ein ESP und NRF+ Modul zugelegt. Ging erstaunlich schnell, bis ich meine Daten vom HM350 einlesen, in FHEM darstellen und die Leistung des WR variieren konnte. Zurueck zu dem 'Nulleinspeisesystem'. Ich habe mir zuerst so ein sogenanntes Solar-BKW mit zwei Solarpanels und einem Modul-WR zugelegt und angemeldet. Als zweiten Schritt habe ich dann einen elektronischen Energiezaehler hinter dem Hauptzaehler meines E-Anschlusses ergaenzt. Der Energiezaehler basiert und auf folgendem Projekt: weberblog.net/stromzahler-mit-s0-schnittstelle-vom-raspberry-pi-auswerte n. Allerdings habe ich den Zaehler mit S0-Schnittstelle durch einen Eastron SDM230 ersetzt. Damit bekomme ich ueber Modbus schnell alle moeglichen Daten zum aktuellen Stromverbrauch und die Software erstellt mir Diagramme mit dem Lastprofil der gesamten Hausanschluss. Gerade diese Lastprofile sind wesentlich, um ein sinnvolles System fuer die Optimierung des Eigenverbrauchs zu konzipieren. Zur gleichen Zeit hatte ich schon mit Li-Akku's, die ich gebraucht von alten E-Autos bekommen habe, experimentiert. Die Akku's habe ich umkonfiguriert (7S) und fuer die Sicherheit mit jeweils eigenen BMS ausgestattet. Damit haben die Akkus aehnliche Spannungs-Level wie ein traditioneller 24V-Akku und ich kann sie ueber einen Victron-BlueSolarCharger laden (natuerlich muss auch die Konfiguration des Victron angepasst werden). Zu der eigentlichen Steuerung fuer die Optimierung des Eigenverbrauchs: mit meinen zwei Solarpanelen kann ich sowieso nicht meinen gesamten Stromverbrauch abdecken. Also braucht auch meine Steuerung erst einmal nicht allzu exakt sein. Vielmehr geht es darum, die tagsueber ueberschuessig produzierte Solarenergie in die Akkus zu laden und dann abends/ueber Nacht von einem gesteuerten Modul-WR den Stromverbrauch abhaengig vom Wert des Energiezaehlers und dem Akku-Ladezustand so weit als moeglich zu kompensieren. Um dies zu erreichen, habe ich von meiner Solaranlage eines der Panele abgeklemmt und lade damit tagsueber die Akkus. Lediglich das andere Solarpanel speist tagsueber via den WR direkt ein. Auf einem Raspi laeuft eine kleine Steuerungssoftware, die erkennt, wenn abends nichts mehr von meiner Solaranlage geliefert wird. Dann schaltet sie abhaengig vom Ladezustand der Akkus den gesteuerten WR ein und erhoeht/reduziert die Leistung des WR im 5-Minutentakt je nach aktuellem Verbrauch des Energiezaehlers. Das Nachregeln erfolgt grob in 50W-Schritten, so dass ich moeglichst um einen 0-Verbrauch an meinem Hauszaehler herumpendele. Das ganze System ist zwar in kontinuierlicher Weiterentwicklung, funktioniert aber mittlerweile stabil. In der Zwischenzeit hat das System bewiesen, dass ich damit einen Grossteil der sonst fuer mich nutzlos eingespeisten Energie in Eigenverbrauch 'umlenken' kann. Und da alles modular gestaltet ist, laesst es sich in vielerlei Weise variieren bzw. skalieren. Die naechsten Schritte sind nun, das Konzept/Software auf den Hoymiles-WR umzustellen. Dazu muessen vor allem die Kommunikations-Routinen zum WR programmiert werden, ich nutze dazu die mqqt-Kommandos. Der Rest duerfte weitgehend gleich bleiben, hoffe in den naechsten Wochen eine erste experimentelle Version zum Laufen zu bringen.
Angehängte Dateien:
-
Mqtt_Explorer.png
46 KB
hast du es mit dem Mqtt Explorer mal überprüft, ich hatte es über Homeassistant stabil am laufen mit der 0.5.15 bevor mein Raspi 4 abgestürzt war SD Card defekt, es geht nur mit einem angelegten mqtt-user
Angehängte Dateien:
-
Mqtt_Explorer.png
46 KB
Weihnachtsmann schrieb: > Auf Seite 12 hat der Nikolaus eine Frage zum MQTT gestellt. > > Ich stehe vor dem selben Problem mit Ahoy. > > Ich bekomme per MQTT einfach keine Verbindung zu Homeassistant soweit > habe ich alles installiert (Mosquitto broker) für Ahoy habe ich es > einmal mit der normalen Homeassistant IP versucht und einmal einen > mqtt-user angelegt aber es taucht einfach nicht auf. > > Hat jemand eine Idee warum? Hab da wirklich mehr als 5 Stunden intensiv > versucht.... > Versucht habe ich es mit 0.5.15 und jetzt 0.5.17... hast du es mit dem Mqtt Explorer mal überprüft, ich hatte es über Homeassistant stabil am laufen mit der 0.5.15 bevor mein Raspi 4 abgestürzt war SD Card defekt, es geht nur mit einem angelegten mqtt-Benutzer
Vielleicht mal mit anderem User ohne Leerzeichen versuchen und auch sonst keine Besonderheiten veranstalten.
Angehängte Dateien:
-
venus_1.JPG
39 KB -
venus_2.JPG
36 KB -
venus_3.JPG
43 KB -
venus_4.JPG
37 KB
So hier mal mein bescheidener Beitrag zu diesem geilen Projekt DTU AHOY. Für alle die ein VENUS OS auf einem Raspi laufen haben, hier ein Python-Script dass die Daten vom DTU-AHOY per JSON ausliest und an den DBUS weitergibt. Alles nach \data\dbus-dtu-ahoy\ kopieren, die config.ini bearbeiten und ./install.sh ausführen. Das soll hier alles als Vorlage dienen! Im Moment nur für einen WR etc pp... Bei mir im Einsatz ein HM-600. PS: darf jemand dem GIT hinzufügen.
:
Bearbeitet durch User
Danke. Klingt toll. Genau sowas such ich gerade. Werde ich baldmöglichst mal ausprobieren. Hast du das auch in einem git-Repo? Wäre vielleicht hilfreich.
Angehängte Dateien:
-
verdrahtung.png
100 KB -
wired.jpg
95 KB -
nordic.jpg
110 KB -
wemos.jpg
130 KB
Hallo zusammen, vielen Dank für das tolle Projekt. Ich hab eine kurze Frage. Ich habe alles nach dieser Anleitung gemacht: https://github.com/lumapu/ahoy/blob/main/tools/esp8266/README.md#things-needed Using a ready-to-flash binary using nodemcu-pyflasher Diese Datei geflashed: 220906_ahoy_0.5.17_esp8266_5402e9b.bin Das Setup hat super funktioniert, nun wird aber diese Meldung angezeigt, dass die Verbindung zum Nordic nicht geht:
1 | WARNING! your NRF24 module can't be reached, check the wiring and pinout (setup) |
Ich habe ein Wemos D1 mini mit dem Nordic verdrahtet. Auf dem Nordic Chip sehe ich auch das "+": 24L01+ Habe ich die richtige Datei geflashed für diese Verdrahtung?
Das ist ein mega tolles Projekt und ich habe natürlich die DTU schon gebaut. Ich habe zu meiner Frage keine direkte Antwort gefunden, deswegen frag ich nochmal. Kann man mehr als 3 Wechselrichter anbinden? Ich plane nämlich 6x 1500 zu nutzen. Falls nicht ist nicht schlimm dann installier ich noch eine, ist nicht perfekt aber ein einfacher Workaround. Besten Dank hans schrieb: > Das Setup hat super funktioniert, nun wird aber diese Meldung angezeigt, > dass die Verbindung zum Nordic nicht geht: >
1 | WARNING! your NRF24 module can't be reached, check the wiring and |
2 | > pinout (setup) |
> > Ich habe ein Wemos D1 mini mit dem Nordic verdrahtet. Auf dem Nordic > Chip sehe ich auch das "+": 24L01+ > > Habe ich die richtige Datei geflashed für diese Verdrahtung? Ich habe davon gelesen das teilweise NF24L01+ Fälschungen verkauft werden. Da werden NF24L01 Chips genommen die dann umgelabelt werden als NF24L01+ und verkauft, kann das eine Ursache sein?
:
Bearbeitet durch User
Danke für die Antwort. Auf der Setup Page müssen folgende Pins noch
angegeben werden, jetzt ist die Fehlermeldung weg
CS (Chip Select),
CE (Chip Enable) and
IRQ (Interrupt)
Jetzt versuche ich die Verbindung zum Inverter zu bekommen. Bei Adresse
die 12 stellige Seriennummer eingetragen und als Name HM600. Noch
bekomme ich keine Antwort. Ich setz das Modul mal direkt neben den
Inverter...
Weiß jemand die Einstellungen der Serial Console? Das müßte ja auf der Seriellen Schnittstelle des VCP vom Wemos funktionieren, oder wurde das auf andere Pins gelegt? Was ist die Baudrete, etc? Danke euch
Hi zusammen, Ich versuche auch gerade mein Glück. Hoffe ich bin mit meinem Problem hier richtig. :) Hardware: ESP32 WROOM32, NRF24L01+ OS: Win10 Habe das Ahoy vom Repository in VS Code geladen. Habe Cmake und MinGw64 installiert und die Pfade in die Systemvariablen eingetragen. Im Projekt habe ich in der platformio.ini das src_dir eingetragen und in der config.ini die Anpassungen gemacht. Weiter komme ich nicht. Habe vorher noch nicht mit pio gearbeitet. Ich bekomme immer die Meldung "Unable to determine what CMake generator to use.", aber der GCC ist ausgewählt. Beim starten des Projekts steht in der Ausgabe "The command: ninja --version failed with error: Error: spawn ninja ENOENT". Ninja ist aber durch CMake mit installiert :( Kann mir bitte jemand einen Tipp geben.
:
Bearbeitet durch User
Bei platformIO bin ich auch "auf dünnen Eis" - deshalb keine direkte Antwort auf die Frage. Ein "Umweg" könnte aber sein: https://github.com/lumapu/ahoy/actions/runs/3265026568 aufrufen, ganz unter "Artifacts" "ahoy_v0.5.20_dev_build.zip" herunterlabden und entpacken. Die ESP32 bin.Datei mit einem Tool deiner Wahl flashen. Zum Herunterladen der zip-Datei musst Du bei GitHub angemeldet sein.
Danke für die Antwort. Habe das Repo gelöscht und nochmals herunter geladen und im PIO Home als Projekt geladen. Danach hat es sich übersetzen lassen. Dazu habe ich noch den "esp32-wroom32-release" als default_envs in der platformio.ini eingetragen.
Angehängte Dateien:
-
dtu.jpg
31 KB
Hallo ich wurschtle mich nun schon seit Tagen durch dieses Thema hier und komme nich wirklich weiter. Ahoy-DTu mit ESP8266 und NRF-Modul mit Antenne habe ich soweit in Betrieb bekommen. Aber leider lässt sich nur sporadisch der WR, HM-800 +2x 395W PV, auf eine Limitierung ein. Meist macht er immer 100%. Hatte mal Anfangs das OpenDTU probiert, da hat es gklappt. Leider war das ESP-Modul nur geliehen. Ich wollte jetzt nich schon wieder neues Material kaufen, da der 8266 noch vorrätig war. Wo kann ich jetzt noch suchen ? Anbei ein Bild der Homeseite, wo ich mal eine Erklärung bräucht, wie die Daten nach dem Punkt Statistics zu interpretieren sind.
Blöde Frage: wieso sehe ich bei meiner Oberfläche nicht die RSSI Signalstärke? Gibts das nur in der Debug Variante?
Angehängte Dateien:
hans schrieb: > Weiß jemand die Einstellungen der Serial Console? Das müßte ja auf > der Seriellen Schnittstelle des VCP vom Wemos funktionieren, oder wurde > das auf andere Pins gelegt? > Was ist die Baudrete, etc? > Danke euch Leider geht es immernoch nicht, auch nicht wenn ich direkt nebenan bin. Hin und wieder kommt ein Packet durch... Hat jemand eine Idee? Hat mir jemand die Debugeinstellungen?
welche Sendeleistung hast du eingestellt? Hast du damit mal gespielt?
Tobias K. schrieb: > Blöde Frage: wieso sehe ich bei meiner Oberfläche nicht die RSSI > Signalstärke? Gibts das nur in der Debug Variante? Schau mal nach der FW-Version, meine ist 0.5.18.
Zu nah dürfte auch nicht gut sein, dann Leistung runterregeln. @Detmar und @Hans: Habt ihr einen Elko 100µ beim NRF an die Spannungsversorgung gehängt?
Detmar schrieb: > Tobias K. schrieb: >> Blöde Frage: wieso sehe ich bei meiner Oberfläche nicht die RSSI >> Signalstärke? Gibts das nur in der Debug Variante? > > Schau mal nach der FW-Version, meine ist 0.5.18. Wo ist die denn her? Wenn ich das aktuelle Verzeichnis bei GitHub kompiliere, dann ergibt das nur 0.5.17? https://github.com/lumapu/ahoy
0.5.17 ist die aktuelle stable. Im Entwickler-Pfad ist man momentan bei 0.5.20 Das sind aber Beta Versionen! Schau bei Github unter Actions https://github.com/lumapu/ahoy/actions
Angehängte Dateien:
-
AHOY_.jpg
340 KB
Eine Platine ist erfolgreich bestückt. Die Daten [1] sind somit freigegeben. Alle die eine Zusage zu einer Platine von mir haben, erhalten nun in den nächsten Tagen Post. [1] https://aisler.net/p/EAYHGSED
Grisu schrieb: > Zu nah dürfte auch nicht gut sein, dann Leistung runterregeln. > @Detmar und @Hans: > Habt ihr einen Elko 100µ beim NRF an die Spannungsversorgung gehängt? Natürlich , direkt auf die Platine, auch bei dem NRF mit Antenne.
Grisu schrieb: > Zu nah dürfte auch nicht gut sein, dann Leistung runterregeln. > @Detmar und @Hans: > Habt ihr einen Elko 100µ beim NRF an die Spannungsversorgung gehängt? Oh ne, ich nicht. Das wird es bei mir sein. Vielen Dank
wo finde ich die aktuellen Binary’s zum flashen? Für esp 32 und 8226??
Wie wird zwischen Developement und Stabil unterschieden?
Hallo Zusammen, ich steige jetzt auch in das Energieerzeugungsgeschäft ein, geiles Projekt :-) Mit der Version 0.5.17 und ESP8266 habe ich immer Abstürze nach ~30min. Schon alles probiert, Spannungsversorgung, etc. Liegt vermutlich am billigen China Teil. Da die ESP32 Version laut Rückmeldung stabiler läuft, wollte ich wechseln. Aber nach dem flashen des BIN Files bekomme ich einen Dauerreset, probiert mit 2st. ESP32: rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 ets Jun 8 2016 00:22:57 Habe auch zwei verschiedene Flasher probiert und am USB eine externe Versorgung dran. Kennt einer einen Trick? Als Fallback habe ich einen ESP8266 und NRF24L01+ von einem deutschen Händler bestellt.
Ja, war bei mir auch so. Direkt aus MS Code compilieren und flashen klappt aber problemlos!
Ich hab bevor ich mit VS begonnen habe den ESP 32 mit ESPHome-Flasher-1.4.0-Windows-x64 geflasht
Hallo, Erstmal ein großes Kompliment an die Macher hier für dieses Projekt. Ich habe mir eine kleine Solaranlage mit dem Hoymiles HM-1200 aufgebaut. Ich hangel mich jetzt schon seid stunden hier durch komme irgendwie nicht weiter! Ich habe die AHOY-DTU nachgebaut und habe noch so einige Probleme :-( . Ich habe die Aktuelle AHOY Version und das ESP-8266 Modul mit dem NRF24L01+ Funkmodul mit der langen Antenne. Der Zusammenbau und das Flashen hat ( fast) problemlos funktioniert. Die Einstellungen habe ich soweit ich hier herausfinden konnte durchgeführt. Als Name habe ich HM1200 und die Seriennummer ( ich denke das ist die Nummer auf dem weißen Aufkleber) eingetragen. Wenn ich mein Hauseigenes W-LAN eingeschaltet habe dann meldet sich der AHOY DTU nicht als verfügbares W-LAN in der W-LAN Liste an. Ich nehme an das heißt das die Verbindung zu meinem Haus- W-LAN steht. Ich kann aber nicht auf den AHOY DTU zugreifen. Wenn ich jetzt mein Haus-W-LAN ausschalte dann erscheint der AHOY DTU nach einigen Sekunden als verfügbares W-LAN in meiner Liste und ich kann darauf zugreifen. Der WR erscheint und ich kann die Daten vom WR sehen, alles so wie es sein soll. Schalte ich den AHOY DTU kurz aus und wieder ein dann kann ich sofort darauf zugreifen aber vom WR werden auch nach längerer warte zeit keine Daten empfangen. Es erscheint die Meldung Inverter #0: HM1200 (v0) is available and is not producing obwohl Strom produziert wird. Schalte ich mein Haus-W-LAN wieder ein und den AHOY DTU kurz aus und wieder ein dann geht das Spiel wieder von vorne los. D.d. ich kann nicht auf den AHOY zugreifen und er erscheint auch nicht in der W-LAN Liste. Erst wenn ich mein Haus-W-LAN ausschalte kann ich wieder darauf zugreifen und auch die Daten vom WR sind wieder da! Ich habe das ganze mit einem W10 PC einem Linux UBUNTU PC und meinem SMART PHONE ausprobiert immer mit dem gleichen Ergebnis. Nach einigem rumspielen geht nichts mehr und jetzt kommt diese Meldung: WARNING! your NRF24 module can't be reached, check the wiring and pinout. Ich habe natürlich alle Verbindungen nochmal überprüft, alles O.K. kann es sein das ich mit meiner Spielerei irgendwas verstellt habe oder ist die Antenne schon für die Tonne ? Bewusst habe ich keine Einstellungen verändert!! VG Rudi.
Flashe ihn nochmals. Wenn die Verbindung nicht gut war (hatte ich auch wenn er sich am letzten Repeater verband) dreht er durch, verbiegt die Settings (Pin-Zuordnung) und nix geht mehr. Als erstes wenn du dich mit seiner SSID verbindest änderst die WLAN-Settings auf dein Heimnetz, damit du ihn übers Heimnetz erreichen kannst.
:
Bearbeitet durch User
Angehängte Dateien:
-
Screenshot_HM1500_DTUpro.png
130 KB -
Screenshot_HM1500_DTUpro.png
130 KB
locke987 schrieb: > Maik R. schrieb: >> Habe meinen 1500er nun auch im ioBroker sichtbar, kannst Du mir ein >> einfaches Tutorium empfehlen, wie ich in ioBroker ein >> Leistung-über-Zeit-Diagramm ähnlich dem in S-Miles-App bauen kann? Bin >> MQTT-Neuling, aber sehr interessiert. > > Ich mache das mit dem influxdb adapter der die Objekte bzw. geloggten > Daten in eine influxdb schreibt und mittels Grafana mache ich dann die > Auswertung. Tutorial habe ich leider keines. Beides habe ich als > container in unraid laufen, hat keine halbe Stunde gedauert bis ich die > ersten Graphen zusammen hatte. Klar, für die reine Visualisierung natürlich auch ein Weg! Aber für direkte Aktionen wie "Habe Überschuss, schalte mal den Heizstab dazu" wäre ioBroker/FHEM & Co wohl reaktionsschneller, oder? Also wenn mir noch mal jemand einen Tipp geben kann wie man den MQTT-Ausgang vom AHOY als Aktor in ioBroker einbinden kann, oder wo es gute Tutorien dazu gibt, das wäre schon super! (schade, keine Bettel-Smilies hier) Zur Visualisierung: Ich war 'ne Weile Offline, inzwischen lese ich eine DTU-Pro per Modbus/TCP aus. Über Telegraf-> InfluxDB-> Grafana. Wer Interesse hat, mit mir gemeinsam im Telegraf einen passenden AHOY-MQTT Block anzulegen ... Dann schiebe ich das auf GitHub. Ich schraube gerade daran, auch einen DTSU666 per Modbus/RTU auszulesen. Das geht nicht wirklich gut mit Telegraf, weil Telegraf einen vollen Client erzeugt und der DTU-pro schon Client ist, daher als Sniffer. Wenn der Code hübsch genug für die Welt ist, kommt er auf GitHub. Aber das wäre hier OT, worum es mir hier geht: hat schon jemand im Rahmen der Leistungsbegrenzung via AHOY einen DTSU666 -> ModbusRTU -> InfluxDB-/MQTT-Adapter in C oder C++ fertig? Letztlich ist meine DTU-pro nur Übergangsweise, auf Dauer soll eine ESP/nRF24 Lösung das Ganze übernehmen und die DTU-Pro eine eBay-Reise machen. ;-)
Hallo zusammen, zuerst einmal vielen Dank für eure tolle Arbeit. Ich habe versucht die letzten Wochen hier etwas quer zu lesen. Ich habe seit 2 Wochen meinen HM-300 am laufen. Aktuell lese ich die Daten des Stromzählers mit einem ESP32. Auf einem raspberry 4 habe ich dazu influxdb und Grafana laufen. Das funktoniert mega. Ich habe mir diese nrf24 Module bestellt: https://www.amazon.de/AZDelivery-NRF24L01-Wireless-Arduino-Raspberry/dp/B06XJN417D/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3KRVC99S97ZF8&keywords=nrf24&qid=1666518169&qu=eyJxc2MiOiIzLjYzIiwicXNhIjoiMy4xNiIsInFzcCI6IjIuNjIifQ%3D%3D&sprefix=nrf2%2Caps%2C327&sr=8-1-spons&psc=1&smid=A1X7QLRQH87QA3 und an meinen Pi angeschlossen. Mein Problem: Ich empfange nur extrem sporadisch Daten des Wechselrichters. Gefühlt kommt 1 response auf 100 requests. Ich habe schon die Sendeleitung variiert und die Ausrichtung der Antenne geändert. Der Pi liegt direkt neben meinem Router und der WR ist in max 5 Meter Entfernung auf dem Balkon. Hat jemand noch eine Tipp für mich? Gerne versuche ich auch noch andere nrf24 Module, wenn das zielführend ist. Vielen Dank euch!
Die Nrf von AZ Del.simd auf jeden Fall kompatibel und funktionieren bei mir sehr gut.
Sowohl mein Steckbrettaufbau als auch mein Lochrasteraufbau waren extrem zickig. Das Verhältnis zu korrekten und fehlerhaften Frames war ca. 1:1. Der nun realisierte Aufbau auf einer Leiterplatte mit 90 Grad versetzten Antennen läuft besser. Das Verhältnis korrekte und fehlerhafte Frames liegt etwa bei 3:1. Von vier gekauften NRF24L01+ Modulen laufen zwei nicht.
ich kann das so unterschreiben, die kleinen Module hatten bei mir auch sehr viele fehlerhaft empfangene Pakete. Seit ich das Modul mit "langer" Antenne verwende: Receive success: 416 Receive fail: 0 Frames received: 2491 Send Cnt: 1823 Das ist aktuell von heute.
So, ich habe jetzt die Nrf-module getauscht. Auch um 90^Versetzt angeordnet. Mite Ahoy geht einfach nicht die Limitiereung. RX Fehler und auch das mehrfache Reboot/Speichern hilft nicht. Was kann ich noch tun ?
Einen meiner ersten Steckbrettaufbauten hatte ich auch nicht zum Laufen bekommen. Nachdem ich im System Config Menü die serielle Console aktiviert hatte (beide Häkchen) trudelten plötzlich korrekte Frames ein.
Tobias K. schrieb: > ich kann das so unterschreiben, die kleinen Module hatten bei mir auch > sehr viele fehlerhaft empfangene Pakete. > Seit ich das Modul mit "langer" Antenne verwende: > Receive success: 416 > Receive fail: 0 > Frames received: 2491 > Send Cnt: 1823 > Das ist aktuell von heute. Vielen Dank! Auf so einen Tipp hatte ich gehofft und mir direkt Mal die anderen Module mit Antenne bestellt. Ich melde mich mit Ergebnissen.
Joe G. schrieb: > Einen meiner ersten Steckbrettaufbauten hatte ich auch nicht zum Laufen > bekommen. Nachdem ich im System Config Menü die serielle Console > aktiviert hatte (beide Häkchen) trudelten plötzlich korrekte Frames ein. Kannst du das nochmal genauer beschreiben? Die SPI habe ich auch aktiviert. Was denn noch?
Unter Setup/System Config/Serial Console die beiden Häkchen print inverter data und Serial Debug aktivieren. Jetzt werden die daten zusätzlich über die serielle Schnittstelle ausgegeben. Damit erzeugte der Empfang vom Inverter plötzlich auch keine Fehler mehr an.
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hallo, in der gleichen Situation half mir im Access Point Betrieb in der
1 | void app::loop(void) |
einen else Zweig für
1 | if (!apActive) |
einzubauen. Ist aber erstmal noch vorläufig und ein arger Hack. Nebenwirkungen untersuche ich noch.
1 | if(checkTicker(&mNtpRefreshTicker, mNtpRefreshInterval)) {
|
2 | if(!apActive) {
|
3 | mTimestamp = mWifi->getNtpTime(); |
4 | DPRINTLN(DBG_INFO, "[NTP]: " + getDateTimeStr(mTimestamp)); |
5 | } else |
6 | {
|
7 | mTimestamp = 1; // default, dass ap active ist, evtl hochzählen? todo |
8 | // damit wird fake ntp Aufruf möglich und AHOY-DTU sendet wieder. |
9 | // Empfang? |
10 | } |
11 | } |
Meine Controller HW:
1 | platform = espressif32 |
2 | board = nodemcu-32s |
und noch der Verweis zur Frage (der oben ist falsch, sorry): Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Angehängte Dateien:
-
Nachtverbrauch.jpg
370 KB -
Nachtverbrauch.jpg
370 KB
Hallo zusammen, ich bin neu hier im Forum und total begeistert von euren Erfolgen. WR die ich gerade im BKW Einsatz habe: - Hoymiles HMI-250 - TSUN M350 Leider habe ich zu diesen beiden Modellen wenig bis nichts lesen können. Konnten manchen Mitglieder hier schon Erfolge mit diesen WRs verbuchen? Ziel ist bei mir auch die Nulleinspeisung über Nacht mit der am Tag in Akkus gespeicherten Solarenergie. Die Daten vom Bild sind aus OpenHAB, gemessen von einem Shelly 3EM und über MQTT verfügbar. Meine Überschüsse vom Tag decken sich sehr gut mit den 70 W bis 90 W je nach Taktzyklus des Kühlschranks. Überschuss Tag an guten Tagen: 0,8 kWh Verbrauch in der Nacht: 10h * 80 W = 0,8 kWh Viele Grüße Simon
Hallo, Danke für den Tipp mit dem „nochmals Flashen“. Jetzt habe ich wieder die ursprüngliche Situation. d.h. ich habe über mein Heimnetzwerk keinen zugriff schalte ich das Heimnetzwerk ab meldet er sich nach einigen Sekunden als W-LAN an und ich habe zugriff. Ich habe noch ein zweites W-LAN von Delovo mit dem gleichen Ergebnis :-( .Habe mich bei github nochmal durchgehangelt. Da steht das eine IP Adresse zugewiesen wird und man diese herauszufinden muss ! Ich dachte das würde automatisch passieren. Mal eine Frage für einen Anfänger!!! Warum macht man den Umweg über das Heimnetzwerk wenn es auch ohne funktionieren würde und er ein eigenes W-LAN zur Verfügung stellen kann ? Auf github steht das er darüber die Aktuelle Uhrzeit bekommt! Was auch stimmt, wenn ich das Netzwerk abschalte und zugriff über W-LAN bekomme dann hat er die Aktuelle Zeit. Warum ist die Uhrzeit so wichtig ? Und wie mache ich das mit der IP Adresse? Vg Rudi
Wieviele WLAN-Netze möchtest denn noch aufspannen? Sei doch froh, daß er dann übers Heimnetz erreichbar ist. Oder möchtest den PC oder Handy immer umstellen damit du zugreifen kannst? Außderdem wohin sollte er seine MQTT Daten hinschreiben ohne Heimnetz, das macht doch alles nur Sinn im Heimnetz. Wie sollte der die Daten schreiben ohne Zeit? Was wären die dann wert? Brauchst doch nur dem PC eine fixe IP verpassen, mit cmd und "arp -a" siehst dann die IP.
Lässt dein Router neue WLAN Geräte zu? Was sagen die Ausgaben an der seriellen Konsole?
Hallo, Nein, er ist eben nicht übers Heimnetz erreichbar :-( Das devolo ist nur Aktiv wenn ich im Garten oder auf der Terrasse bin weil Das andere Netz nur im Haus funktioniert. Ich habe das devolo jetzt mal nur zu Test Zwecken eingeschaltet in der regel ist es aus da ich es nur selten brauche. Wie gesagt ich bin Anfänger auf dem Gebiet, ich habe nicht die leiseste Ahnung was es mit diesen MQTT Daten auf sich hat oder wozu man die braucht. Ich will doch „nur“ die Daten vom WR auslesen um zu sehen wie viel Leistung er gerade bringt oder ein Solarmodul einen Fehler hat etc. auf die Uhr schauen kann ich selber. Scheinbar bin ich zu blöd dazu, jedenfalls werden mir keine weiteren IP Adressen angezeigt, nur die vom PC und selbst wenn, was soll ich damit den anstellen ?? vg Rudi
Nicht falsch verstehen, aber ich glaube das Teil ist nix für dich. Es ist eben kein „Consumer“ Produkt - sondern ein Entwickerprojekt bei dem du selbst auch diverse Einstellungen und Problemchen lösen bzw. vornehmen musst. Wenn du nicht weißt was du am Ende mit der zugewiesenen IP Adresse anfangen sollst, dann ist es einfach nix für dich. Aber es gibt ja auch die DTU von Hoymiles die ja Plug and Play funktioniert. Wozu brauchst du das devolo Teil denn, hänge den Controller an den Rechner, aktiviere die serielle Schnittstelle und dann kannst du sehr wahrscheinlich schon sehen was das „Problem“ ist. Ferndiagnose ist einfach schwierig.
Hallo Community, nachfolgend meine Erfahrungen mit dem Projekt und einige Hinweise die vielleicht helfen. Ich nutze seit 'einigen Jahren' div. ESP8266 und ESP-32 Module. So kam mir AHOY-DTU auf einem ESP8266 sehr gelegen. Was nutze ich: ESP8266 D1mini V3 (4MB Flash) NRF24L01+ Modul mit extra Chip für Sender (mit und ohne ext. Antenne) Die teilweise vorgeschlagene Verdrahtung ESP zum NRF finde ich problematisch. Problem ist bei D3/GPIO0: Wenn der bei Boot des ESP auf low ist, geht der ESP in den Programmiermodus. Problem ist bei D4/GPIO2: Beim D1mini hängt die blaue LED daran. Die Pin sollte man meiden Meine Empfehlung (so verdrahten und im Webinterface konfigurieren): NRF = ESP CS = D8 (GPIO15) CE = D1 (GPIO5) IRQ = D2 (GPIO4) Problematisch ist auch die Stromversorgung des NRF24L01+. Der Sender wird mit 3,3V versorgt. Die 3,3V kommen aus einem Spannungsregler auf dem D1mini ESP8266 Modul. Der ist nur für geringe Ströme ausgelegt. Stromversorgung ist schon beim ESP8266 alleine problematisch. Beim Senden werden kurzfristig Stromspitzen gezogen. Um das etwas zu entspannen einen low ESR Elko auf 3,3V gegen Masse schalten. Ab 100microF sollte passen. Im Webinterface in der Kofiguration ‚Radio (NRF24L01+) den Amplifier Power Level' auf ‚MIN‘ setzen. Sonst hat es bei mir nicht funktioniert. Wobei ich ja Module mit 2 Chips habe. Ein Modul OHNE ext. Antenne hat durch 2 Wände stabilen Empfang. Das hat auf Anhieb funktioniert. Die Teile sind alle über Ali bestellt. Billigstes Abgebot. Empfohlene Software Version ist ab 0.5.17. Problematisch ist auch bei 0.5.18, wenn ein eingerichtetes MQTT Ziel nicht verfügbar ist. Dann hängt irgendwie alles. Danke für das tolle Projekt und viel Erfolg!
:
Bearbeitet durch User
Rudi schrieb: > jedenfalls werden mir keine weiteren IP Adressen angezeigt, nur die vom > PC und selbst wenn, was soll ich damit den anstellen ?? Die sollst dann im Browser eingeben und das Teil vollständig konfigurieren beginnend mit der Eingabe deines Heim-WLAN, damit die Verbindung darüber hergestellt werden kann. Da bekommt es dann eine andere IP vom Router zugewiesen, welche findest im Router angeführt, falls es über DHCP eine bekommt, bzw. kannst der MAC eine bestimmte IP vorgeben. Aber ich glaub auch, daß das alles deinen Horizont weit übersteigt. Such dir vielleicht einen Bekannten der sich nur etwas damit auskennt und laß es dir einmal zeigen. Aber so ganz ohne Dunst von der Materie, wie bist du dann überhaupt an das Teil gelangt und wie programmierst du es??? Irgendwann stehst sowieso an dem Punkt, daß du es neu programmieren mußt, ging mir auch schon so ohne "etwas getan" zu haben außer ab und zu die Werte ansehen. Kauf dir lieber um 20€ ein Energiemeßgerät und häng es zw. Stecker und Steckdose, da kannst immer ablesen wieviel grad produziert wird. Wird deinen Ansprüchen vermutlich viel besser gerecht und ist echt plug&play.
:
Bearbeitet durch User
Maik R. schrieb: > wäre ioBroker/FHEM & Co wohl reaktionsschneller, oder? > Also wenn mir noch mal jemand einen Tipp geben kann wie man den > MQTT-Ausgang vom AHOY als Aktor in ioBroker einbinden kann, oder wo es > gute Tutorien dazu gibt, das wäre schon super! Du musst in ioBroker zwei Adapter installieren: - MQTT Broker/Client (als Broker) - MQTT-Client AHOY schickt die Daten über MQTT an den Broker. Diese sind dann schon mal in "Aufzählungen" sichtbar. Im MQTT-Client pickst Du Dir die interessierenden Topics raus, die dann unter "Objekte" erscheinen. Mit denen kannst Du dann wir gewohnt weiterarbeiten. In JavaScript kannst Du vermutlich die Stati aus "Aufzählungen" direkt verwenden, ohne Umweg über den MQTT-Client. Tutorials hierzu kann mal wohl vergessen, fast immer werden ältere ioBroker-Versionen beschrieben. Zur aktuellen v6.2.22 gibt es kaum was. Das ist besonders doof, weil sich doch Entscheidendes geändert hat.
Hallo, „ welche findest im Router angeführt“ Das war die entscheidende Info die Ich brauchte oder nicht verstanden hatte. Habe die IP in den Netzwerkeinstellungen vom PC gesucht. Wie dem auch sei habe jetzt den Zugang übers Netzwerk. Wie ich an das Teil gelangt bin ? Habe es selber gebaut, steht ja alles auf Github. Was meinen Dunst von der Materie angeht ? Naja hatte während des Studiums auch E-Technik und Informatik auf dem Lehrplan ist aber schon viele Jahre her. Mit Elektronik beschäftige ich mich seid über 45 Jahren Hauptsächlich Analoge Transistor und Röhrentechnik habe aber auch das eine oder andere Mikrocontroller Projekt in „C“ und „Bascom“ auf die Beine gestellt . Ja so ein Energiemessteil habe ich tatsächlich angeschlossen. Funktioniert sehr gut aber dazu muss ich immer nach draußen gehen um es abzulesen und es zeigt mir nicht an was die einzelnen Module bringen! Sicher hätte ich mir die Original Hoymiles DTU besorgen können finde den Preis für diesen Stick aber viel zu hoch außerdem geht es doch ums Bauen, Lernen und Verstehen. Wie ich schon sagte Ich bin „Noch“ Anfänger auf dem Gebiet, das muss aber nicht so bleiben. Ihr ward sicher auch mal an diesem Punkt und sicher froh über jeden Tipp und Info die ihr bekommen konntet! Nochmal vielen lieben dank für die Info. vg Rudi
Ist halt schwierig zu helfen, wenn an keinen Schimmer hat wo ansetzen. ;-) Na Hauptsache du hast das jetzt auch hinbekommen. Hab ähnliche Voraussetzungen, nur die Röhren blieben mir schon erspart.
Danke für das Projekt openDTU das bei mir mit einem HM300 und HM400 läuft. Ich habe noch einen Volkszähler und hole mir von dort den aktuellen Verbrauch über ein python-script. Dieses Script setzt dann das Limit für den Wechselrichter. Das Script wird über crontab 1/minute aufgerufen. Wenn ihr mal kucken wollt: https://gitlab.com/p3605/hoymiles-tarnkappe Gruss Peter
Hallo zusammen, ich nutze ebenfalls die aktuelle Ahoy-Version, danke dafür. Jetzt habe ich mal eine Frage zur Limitierung. Diese wird ja von Hoymiles auf jeden Eingang umgerechnet. Sprich, wenn ich auf 50% setze, wird beim HM1500 jeder Eingang auf 187,5W begrenzt (4x 187,5W = 750W). Ich möchte aber nun eine HM1500 nur mit 2 Modulen betreiben und den WR auf 600W begrenzen. Geht das jetzt nur so, dass ich die Begrenzung NICHT statisch auf 600W setze, sondern prozentual auf 80%? Nur dadurch würde ja jeder Eingang auf 300W begrenzt werden? Und wenn ein Modul mal verschattet und weniger als 300W generiert, kann das zweite Modul wohl trotzdem nicht die fehlende Leistung zum 300W kompensiere, und mehr als 300W erzeugen können, korrekt? Wäre eigentlich ziemlich schade, weil genau das beim DTU Pro ziemlich nervig ist..
Beitrag #7231925 wurde vom Autor gelöscht.
Mc S. schrieb: > Tobias K. schrieb: >> ich kann das so unterschreiben, die kleinen Module hatten bei mir auch >> sehr viele fehlerhaft empfangene Pakete. >> Seit ich das Modul mit "langer" Antenne verwende: >> Receive success: 416 >> Receive fail: 0 >> Frames received: 2491 >> Send Cnt: 1823 >> Das ist aktuell von heute. > > Vielen Dank! > Auf so einen Tipp hatte ich gehofft und mir direkt Mal die anderen > Module mit Antenne bestellt. Ich melde mich mit Ergebnissen. Gestern sind die Module mit externer Antenne angekommen und funktionieren bei mir fast fehlerfrei. Vielen Dank für den Tipp @Tobias K. Jetzt muss ich nur noch die Bugs im python code finden ;)
Der Wert wird doch pro WR eingestellt und nicht pro Panel, wirkt also am Ausgang des WR. Und ob in Watt oder % ist nur eine Anzeigesache, funktionieren tut er im Hintergrund glaub ich immer mit % vom jeweiligen WR Peak-Wert. Wenn du mehrere WR eingebunden hast kannst den Wert für jeden separat einstellen, auch klar, daß da einer den anderen nicht ausgleichen kann, die wissen voneinander doch nichts.
:
Bearbeitet durch User
Eine kleine Frage noch. Ich habe auf die Schnelle nichts gefunden. Kann mir jemand die beiden Werte daily und total erklären? total: erzeuge Gesamtleistung in KWh? daily: ?? Vielen Dank
Genau was es heißt, Total seit Anbeginn und Daily was heute erzeugt wurde. Mustafa K. schrieb: > Ich möchte aber nun eine HM1500 nur mit 2 Modulen betreiben und den WR > auf 600W begrenzen. Dann häng aber auch einen rechts und den anderen links an, damit jeder seinen eigenen Tracker hat und somit jeweils im Optimum betrieben wird. Und trag halt 600 Watt persistent ein.
:
Bearbeitet durch User
Joe G. schrieb: > Eine Platine ist erfolgreich bestückt. Die Daten [1] sind somit > freigegeben. Alle die eine Zusage zu einer Platine von mir haben, > erhalten nun in den nächsten Tagen Post. > > [1] https://aisler.net/p/EAYHGSED Vielen Dank für deinen Beitrag. Das Design ist echt gut. Kannst du uns nochmal Informationen zu den zusätzlichen Teilen mitteilen: bis dato habe ich mitgeschnitten: - deine Platine - Wemos D1 Mini - NRF24L01+ Modul - Verbindungselemente zwischen Platine und Wmos sowie NRF24L01+ Modul Was braucht man noch an elKos, Widerständen, Pinouts etc. und an welcher Stelle (C1, C2 usw.)? Ist eine Antenne von nöten und wenn ja welche?
:
Bearbeitet durch User
Grisu schrieb: > Der Wert wird doch pro WR eingestellt und nicht pro Panel, wirkt also am > Ausgang des WR. > Und ob in Watt oder % ist nur eine Anzeigesache, funktionieren tut er im > Hintergrund glaub ich immer mit % vom jeweiligen WR Peak-Wert. > Wenn du mehrere WR eingebunden hast kannst den Wert für > jeden separat einstellen, auch klar, daß da einer den anderen > nicht ausgleichen kann, die wissen voneinander doch nichts. Es geht nicht um mehrere WR sondern weniger Solarmodule als Eingänge vorhanden sind (oder alternativ dass 1-2Module stark verschattet sind und nichts liefern).Den HM1500 auf 600W limitiert, heisst doch pro Eingang 150W. Und wenn dann zwei Module gar nicht angeschlossen sind (oder stark verschattet sind) liefert der WR mit den verbliebenen zwei Modulen eben nur maximal 300W, obwohl die beiden Module (z.b je 410W) eigentlich 600W liefern könnten. Wie bekommt ihr dieses Problem gelöst?
Ob die Begrenzung sich auf alle 4 Eingänge aufteilt oder auf die 2 MPPT hab ich noch nicht herausgefunden. Auf die zwei MPPT aber habe ich es aber feststellen können. Du müsstest also auf 1200W begrenzen. Aber um so "richtig" zu begrenzen und auch unterschiedliche Leistungen durch Verschattung an den einzelnen Modulen usw. zu beachten bräuchtest Du eine aktive Regelung. Ich hatte mir da mal mit ioBroker gebastelt. Leistung unter 600W --> Begrenzung erhöhen bis max 100% Leistung über 600W --> Begrenzung verringern
:
Bearbeitet durch User
Ich schrieb doch, daß es sich auf den AUSGANG des WR bezieht. Wie sich das auf die Panele aufteilt ist ihm völlig wurscht, er regelt die beiden Tracker eben so weit runter, daß die eingestellten 600W passen. Die Angabe der Modulleistung ist nutzlos für den Betrieb (kannst auch 0 oder 1MW eintragen) und rein für Statistikzwecke, damit du weißt was eines könnte in der Anzeige.
:
Bearbeitet durch User
Grisu schrieb: > Ich schrieb doch, daß es sich auf den AUSGANG des WR bezieht. Und genau das ist falsch. Beispiel von mir mit HM-1200 Modul 1 & 2: Süd Modul 3 & 4: West Angenommen Limit auf 100% (1200W) Sonne scheint auf Süd und West ist verschattet. Süd = 600 Watt West = 100 Watt Jetzt das Limit auf 50% (600W) passiert folgendes. Süd und West werden auf JEWEILS 300W gegrenzt. Ergebnis: Süd = 300 Watt West = 100 Watt Mehrfach getestet und das Thema hatten wir hier auch schon im Thread.
:
Bearbeitet durch User
CE E. schrieb: > Kannst du uns nochmal Informationen zu den zusätzlichen Teilen > mitteilen: Das Layout ist für einen Wemos D1 Mini sowie ein NRF24L01+ Modul ausgelegt. Bei den NRF24L01+ Modulen können die mit integrierter Antenne und die mit zusätzlicher PA und externer Antenne verwendet werden. Die Anschlüsse sind pinkompatibel. Nach meiner Erfahrung funktionieren die Module mit externer Antenne zuverlässiger. Zur Abblockung der Stromversorgung benötigt man auf der 5V und 3.3V Schiene jeweils einen Elko von 100 µF und einen 100n Vielschichtkondensator. Für den Anschluss der Spannungsversorgung (5V) gibt es zwei Schraubklemmblöcke im Rastermaß 5mm. Die beiden Module (Wemos und NRF24L01+) sind auf einreihige Buchsenleisten im Rastermaß 2.5mm gesteckt (beim NRF24L01+ zwei nebeneinander). Anhand es Bestückungsaufdruckes ist zu erkennen, an welcher Stelle die Kondensatoren sitzen. Die anderen Lötaugen können für den „normalen“ Betrieb frei bleiben. Für die Steckverbinder, Buchsenleisten, Kondensatoren habe ich keine exakte Bauteilbezeichnung. Ich habe alles aus meinen vorhandenen Lagerbeständen bestückt. Wenn noch etwas unkla bleiben sollte, einfach fragen.
Angehängte Dateien:
-
IMG_20221008_154621.jpg
460 KB
@Joe Nur als kleine Anregung. Integriere doch das Netzteil mit auf der Platine. Anbei ein Bild von meinem in einer Abzweigdose mit Netzteil.
M. P. schrieb: > Grisu schrieb: >> Ich schrieb doch, daß es sich auf den AUSGANG des WR bezieht. > > Und genau das ist falsch. > > Mehrfach getestet und das Thema hatten wir hier auch schon im Thread. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Joe G. schrieb: > CE E. schrieb: >> Kannst du uns nochmal Informationen zu den zusätzlichen Teilen >> mitteilen: > > Das Layout ist für einen Wemos D1 Mini sowie ein NRF24L01+ Modul > ausgelegt. Bei den NRF24L01+ Modulen können die mit integrierter Antenne > und die mit zusätzlicher PA und externer Antenne verwendet werden. Die > Anschlüsse sind pinkompatibel. Nach meiner Erfahrung funktionieren die > Module mit externer Antenne zuverlässiger. > > Zur Abblockung der Stromversorgung benötigt man auf der 5V und 3.3V > Schiene jeweils einen Elko von 100 µF und einen 100n > Vielschichtkondensator. Für den Anschluss der Spannungsversorgung (5V) > gibt es zwei Schraubklemmblöcke im Rastermaß 5mm. Die beiden Module > (Wemos und NRF24L01+) sind auf einreihige Buchsenleisten im Rastermaß > 2.5mm gesteckt (beim NRF24L01+ zwei nebeneinander). > Anhand es Bestückungsaufdruckes ist zu erkennen, an welcher Stelle die > Kondensatoren sitzen. Die anderen Lötaugen können für den „normalen“ > Betrieb frei bleiben. > Für die Steckverbinder, Buchsenleisten, Kondensatoren habe ich keine > exakte Bauteilbezeichnung. Ich habe alles aus meinen vorhandenen > Lagerbeständen bestückt. Wenn noch etwas unkla bleiben sollte, einfach > fragen. Dazu noch folgende Fragen: Kann ich das gesamte Konstrukt auch über den USB Port beim Wemos D1 betreiben oder ist zwingend eine 5V Verbindung über die Schraubklemmblöcke notwendig? Warum ist bei deinem Bild kein Kondensator C1 und C2 eingelötet? Wofür benötige ich die RST Pins und wie werden diese aktiviert? Ist die Position des 100nF und des 100uF Kondensators egal? Danke dir!
CE E. schrieb: > Kann ich das gesamte Konstrukt auch über den USB Port beim Wemos D1 > betreiben oder ist zwingend eine 5V Verbindung über die > Schraubklemmblöcke notwendig? Wenn das NRF24L01+ Modul gesteckt ist, kommt man an die USB-Buchse nicht mehr ran. In diesem Fall müssen die 5V extern zugeführt werden. > Warum ist bei deinem Bild kein Kondensator C1 und C2 eingelötet? Weil ich zunächst die Stabilität der Spannungsversorgung mit dem Oszi überprüft hatte. Die Elkos hatte ich im nächsten Schritt eingelötet. > Wofür benötige ich die RST Pins und wie werden diese aktiviert? Ist nur für Testzwecke vorgesehen, wird also im normalen Betrieb nicht benötigt. > > Ist die Position des 100nF und des 100uF Kondensators egal? ja, beide liegen im Layout parallel
Wo sind bei der Version AhoyDTU © 2022 0.5.25 die Einstellungen für die Leistungsbegrenzung geblieben?
Willi schrieb: > CS = D8 (GPIO15) > CE = D1 (GPIO5) > IRQ = D2 (GPIO4) Mit dieser Konfiguration habe ich den WeMos D1 mini Pro von Elektor zum laufen gebracht.
mimi schrieb: > Wo sind bei der Version AhoyDTU © 2022 0.5.25 > die Einstellungen für die Leistungsbegrenzung geblieben? Das geht nur noch über die serielle Konsole und auch da nicht zuverlässig. Aber diese Version ist irgendwie total geschrottet, wenn Abends der WR nicht mehr produziert, verschwinden auch viele Werte, wie z.B. YieldTotal, unter MQTT erscheint dann nur noch available and not producing.
Volker.B. schrieb: > Das geht nur noch über die serielle Konsole und auch da nicht > zuverlässig. > Aber diese Version ist irgendwie total geschrottet, wenn Abends der WR > nicht mehr produziert, verschwinden auch viele Werte, wie z.B. > YieldTotal, unter MQTT erscheint dann nur noch available and not > producing. Uhaa, das hört sich nicht gut an. Welche Version gilt denn als "stabil". Über Github ist das nicht wirklich ersichtlich, schade..
HM1500 Limit 202% | last Alarm: Inverter start Schräg....
Zeigt er hier auch an 202%. Dürfte aber "nur" ein Anzeigefehler sein.
Angehängte Dateien:
-
hm1500-400W.jpg
81 KB
Mustafa K. schrieb: > Es geht nicht um mehrere WR sondern weniger Solarmodule als Eingänge > vorhanden sind (oder alternativ dass 1-2Module stark verschattet sind > und nichts liefern).Den HM1500 auf 600W limitiert, heisst doch pro > Eingang 150W. Und wenn dann zwei Module gar nicht angeschlossen sind > (oder stark verschattet sind) liefert der WR mit den verbliebenen zwei > Modulen eben nur maximal 300W, obwohl die beiden Module (z.b je 410W) > eigentlich 600W liefern könnten. Wie bekommt ihr dieses Problem gelöst? M. P. schrieb: > Und genau das ist falsch. Tut mir Leid, zuvor einen ziemlichen Schmarrn geschrieben zu haben! Durch meine 4 Panele hat es sich (zufällig) so dargestellt. Würds ja gern wieder löschen wenn das hier ginge ... Die eingestellte Leistung teilt sich tatsächlich auf die beiden Tracker auf, die sich dann NICHT gegenseitig ausgleichen können. Aber dennoch ist das dann auch bei dir kein großes Problem. Die Leistungsbegrenzung wird auf % umgerechnet und dann auf beide Tracker angewandt. Beim HM1500 also 750W pro Tracker bei 100% oder falls du insgesamt max. 600W möchtest eben auf 40% einstellen. Somit wird jeder Tracker max. 300W liefern, zusammen also die gewünschten 600W. Du brauchst also immer nur ein "verschattetes" Modul zu einem besonnten hängen (rechte Seite) bzw. 2 weitere links. Also nicht 2 besonnte auf einer Seite sondern immer ein gutes mit einem schlechten pro Seite sprich pro Tracker. Hier ein Bild von meinen, wie man sieht sind für den Test 400W (26%) eingestellt. Beide Seiten (1+2 bzw. 3+4) liefern somit bis zu je 200W, wobei das 4. Modul verschattet ist und durch das 3. Modul auf diesem Tracker ausgeglichen wird. Am anderen Tracker ist ein Modul nur ganz leicht verschattet, daher ähnliche Werte.
:
Bearbeitet durch User
Grisu schrieb: > Zeigt er hier auch an 202%. Dürfte aber "nur" ein Anzeigefehler > sein. Du meinst Dein System zeigt das in Deiner Umgebung auch an?
Ja alle beide verbundenen WR, aber irgendwie nicht immer, sieht so aus erst nach einer gewissen Zeit. Da ich gestern herumgespielt habe mit der Leistung steht aktuell 'Limit 100% (not controlled)', bevor ich die Änderungen begann war es jedoch bei beiden 'Limit 202% (not controlled)'. Ich glaub mich zu erinnern, daß es erst nach einer gewissen Zeit dann umspringt. Nach einem Neustart steht ja noch 65535% dort, solange kein Kontakt zum WR erfolgt ist. Ich hab auch noch nie verstanden oder gefunden was auf der Homepage die Angaben (v0) bzw. (v1) oder (v10018) bedeuten. Vielleicht kann mir das jemand erklären? Anfangs ohne Kontakt zum WR dürfte es immer (v0) sein, später dann für mich unerklärlich (v1) oder (v10018).
:
Bearbeitet durch User
Grisu schrieb: > Anfangs ohne Kontakt zum WR dürfte es immer (v0) sein, später dann für > mich unerklärlich (v1) oder (v10018) Das ist glaub ich die Firmware-Version vom Wechselrichter.
Hallo zusammen, ich habe eine Frage zur Leistungsreduzierung (v0.5.17). Wenn ich im Ahoi-DTU Setup unter Inverter Active Power Limit die 100 und und unter Active Power Limit Control Type relativ in percent persistent eintrage, werden diese Werte, da ja permanent, ins Eprom geschrieben. Wann und wie oft wird damit das Eprom mit beschrieben? Schöne Grüße Gerri
Ich glaube (!!!) 1x, und sobald er es dann später beim Auslesen wieder so zurückbekommt nicht mehr - wie gesagt eine Vermutung wie es sein sollte. Alles andere wäre auf Dauer ja zerstörerisch. Wäre aber schön wenn das ein Wissender bestätigen (oder berichtigen) könnte.
:
Bearbeitet durch User
M. P. schrieb: > Grisu schrieb: > >> Anfangs ohne Kontakt zum WR dürfte es immer (v0) sein, später dann für >> mich unerklärlich (v1) oder (v10018) > > Das ist glaub ich die Firmware-Version vom Wechselrichter. In der Doku nicht zu finden😪
Grisu schrieb: > Ich glaube (!!!) 1x, und sobald er es dann später beim Auslesen wieder > so zurückbekommt nicht mehr - wie gesagt eine Vermutung wie es sein > sollte. > Alles andere wäre auf Dauer ja zerstörerisch. > > Wäre aber schön wenn das ein Wissender bestätigen (oder berichtigen) > könnte. Vielen Dank erstmal für die Info. Ich denke es wird auch so sein. Jedenfalls habe ich noch festgestellt, das das Setzen von einem Powerlimit über MQTT (ioBroker) bei der v0.5.17, nur sporadich bei bei mir funktioniert!
Ich denke für kontinuierliche Anpassung ist das so und so nicht wirklich geeignet. Eher für eine fixe Einstellung, etwa um ihn auf 600 oder 800W zu limitieren und dennoch weit mehr Module anhängen oder den HM-1200 bzw. 1500 verwenden zu können, um auch bei weniger Sonne weit höhere Ausbeute zu erhalten. Möglicherweise sind andere NRF-Module als meines besser geeignet und können tatsächlich alle 30s Daten austauschen ohne Fehler.
Hallo zusammen. Ist es eigentlich schon jemandem gelungen den Esp8266 für mehr als 3 Wechselrichter zu flashen? Ich versuche es seit Tagen, aber es funktioniert nur mit 3 WRs. Sobald ich mehr in die Config gebe, habe ich keine Möglichkeit mehr, sie einzugeben. Vielleicht kann mir ja wer eine Bin erstellen für 9 WRs? Danke, LG
Christian F. schrieb: > Ist es eigentlich schon jemandem gelungen den Esp8266 für mehr als 3 > Wechselrichter zu flashen? Also da würde ich lieber mehrere Esp8266 nehmen.
Grisu schrieb: > Möglicherweise sind andere NRF-Module als meines besser geeignet und > können tatsächlich alle 30s Daten austauschen ohne Fehler. Also ich hab hier 5 Sekunden eingestellt. Und das funktioniert erstaunlich gut seit den 100uF an der 3,3V Leitung und Sendeleistung auf "Low". Der ESP ist ca. 6m entfernt in einer Abzweigdose mit Sichtverbindung.
:
Bearbeitet durch User
rolf schrieb: > signal-2022-10-15-154236_002.jpeg > > 310 KB > > > > > signal-2022-10-15.jpeg > > 310 KB Interessante Befestigung. Kannst du davon mal Details posten?
Moin, gestern wurde meine DTU-Basis aus Raspi 1 mit NRF24+ fertig, das ReadMe im ahoy-git bis zur Anweisung, die Module crcmod, pyyaml + paho-mqtt zu aktualisieren und zu laden, abgearbeit. Das System meldet keine Fehler beim Aufruf der Beispielapplikation"python3 getting_started.py". Gehe ich nun einen Schritt im ahoy-Readme weiter und rufe diesen Befehl in der Shell auf: sudo python3 -um hoymiles --log-transactions --verbose --config /home/dtu/ahoy.yml , kommt nach kurzer Zeit: /usr/bin/python3: No module named hoymiles und jetzt komme ich nicht weiter. Laut Befehlsparameter wird das Modul namens "hoymiles" angefordert, nur leider bin ich wahrscheinlich zu blind um einen Hinweis zur Installation desselben zu entdecken. Würde mir bitte jemand eine Anleitung oder einen Hinweis zur entsprechenden Dokumentation geben? Danke + Gruß - Ingo
Vielleicht wurde das schon hier erklärt aber ich habe das noch nicht gefunden. Was ist der genaue unterschied zwischen den Power Einstellungen "non persitent" und "persistent". So ganz kann ich mir nicht herleiten was, welche Einstellung bedeutet.
Persistent sollte dauerhafte Drosselung sein, non persistent bis zum nächsten Reboot des WR (also nur bis Sonnenuntergang).. Ich hab auch mal eine Frage: Wenn der WR offiziell mit der DTU Pro gedrosselt wurde, würde der "No power Limit" über Ahoy diese Drosselung aufheben, oder sind dies unterschiedliche und unabhängige Drosselungs-Arten?
Non-Persistent verliert die Einstellungen nachdem der Inverter im Power-Off war (z.B. über Nacht). Persistent ist eben für immer.
Hallo Ingo, hast Du die Zip-Datei aus git heruntergeladen und entpackt? Wenn nicht mach das erst mal. - Dann in der Konsole per "cd-Befehl" in den Ordner ahoy-main/tools/rpi/ wechseln z.B.
1 | cd ahoy-main/tools/rpi/ |
- Darin die Datei "ahoy.yml.example" mit einem Texteditor (z.B. nano) öffnen.
1 | nano ahoy.yml.example |
- Unten in dieser Datei gibt es einen Abschnitt "inverters:" Dort hinter "serial:" die Seriennummer Deines Inverters eintragen. Wenn Du später mittels ioBroker o.ä. eine Auswertung machen möchtest, würde ich diese Nummer auch gleich in der letzten Zeile unter "mqtt:" hinter "topic: 'hoymiles/...'" eintragen. - Nun die bearbeitete Datei unter anderem Namen abspeichern, z.B. ahoy.yml - nano schließen. - Du befindest Dich in der Konsole immer noch im Ordner "rpi". Hier existiert auch der Unterordner "hoymiles", der die Pythonmodule - die in Deinem Aufruf nicht gefunden wurden - enthält. - Hier kannst Du nun den Befehl
1 | python3 -um hoymiles --log-transactions --verbose --config ahoy.yml |
aufrufen. Willst Du später per Script den Befehl ausführen, muss der komplette Pfad dorthin in diesem Script angegeben werden. Gruß Heinz
Danke schön... An dieser Stelle möchte ich allen aktiv hier mitarbeitenden Entwicklern, Testern usw. ein ganz großes "Danke schön" sagen. Ich verfolge die Arbeit hier schon seit geraumer Zeit - und was hier entstanden ist, ist aller Achtung wert. Macht weiter so und lasst Euch von Kritikern, die es auch hier gibt, nicht unterkriegen. Recht herzlichen Dank Heinz
Hallo Ingo, da Problem hatte ich auch. Schlussendlich musste ich noch das Projekt selber auf meinen RPI bringen git clone https://github.com/stefan123t/ahoy.git half. Dann im Ordner ahoy/toolf/rpi starten.
Hat schon jemand die neue ahoy v0.5.28 getestet und ist bereit seine Erfahrungen damit zu teilen? Kann man getrost das Update einspielen. Verliert man damit die Leistungsbegrenzungsmöglichkeiten im GUI?
Nein, du verlierst das nicht. Meiner Meinung nach eine super Version! Die Weboberfläche ist wesentlich schneller und es kommt mir stabiler vor. Die Leistungsbegrenzung funktioniert nahezu in Echtzeit und problemlos. Ich kann das Update absolut empfehlen bisher!
:
Bearbeitet durch User
Hallo könnte jemand die v0.5.28 hier reinsetzen zum download, oder den kniff sage wie es von githup geht?
Hallo Herbert und Marc, danke für eure Super-Unterstützung, aber ich stecke trotzdem weiterhin fest. @Marc Das git ahoy repository hatte ich mir via
1 | $ git clone https://github.com/grindylow/ahoy.git |
(es scheint egal zu sein, ob es von "grindylow" oder "stefan123t" geholt wird) schon gezogen, die Einstellungen in "ahoy.yml.example" editiert, als "ahoy.yml" gespeichert und damit kamen dann die im Beitrag gezeigten Fehler. Wäre ich man gleich in den rpi-Ordner gewechselt, wären meine Probleme andere gewesen. Wenn ich im rpi-Ordner bin komme ich schon weiter, aber der Aufruf
1 | sudo python3 -um hoymiles ... |
kommt jetzt zu dem Schluss:
1 | Traceback (most recent call last): |
2 | File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main |
3 | mod_name, mod_spec, code = _get_module_details(mod_name, _Error) |
4 | File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details |
5 | return _get_module_details(pkg_main_name, error) |
6 | File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details |
7 | __import__(pkg_name) |
8 | File "/home/ingo/dtu/ahoy/tools/rpi/hoymiles/__init__.py", line 13, in <module> |
9 | import crcmod |
10 | ModuleNotFoundError: No module named 'crcmod' |
Obwohl
1 | pip list modules |
die benötigten Module u.a. anzeigt:
1 | crcmod 1.7 |
2 | RF24 1.4.6 |
3 | paho-mqtt 1.6.1 |
4 | PyYAML 6.0 |
und damit die requirements erfüllt sind. @Herbert Hole ich per wget das Archiv "http://github.com/lumapu/ahoy/releases/download/ahoy_v0.5.28/ahoy_v0.5.28.zip"; steckt da nicht das richtige drin.
1 | $ unzip -l ahoy_v0.5.28.zip |
zeigt:
1 | Archive: ahoy_v0.5.28.zip |
2 | Length Date Time Name |
3 | --------- ---------- ----- ---- |
4 | 918320 2022-10-30 22:11 221030_ahoy_0.5.28_esp32_2e08ee0.bin |
5 | 434880 2022-10-30 22:10 221030_ahoy_0.5.28_esp8266_1m_2e08ee0.bin |
6 | 434864 2022-10-30 22:10 221030_ahoy_0.5.28_esp8266_2e08ee0.bin |
7 | 17403 2022-10-30 22:11 User_Manual.md |
8 | --------- ------- |
9 | 1805467 4 files |
also vermutlich nur esp-Support. Wo finde ich denn die für Raspi (rpi?) geeignete Zip-Datei? Das oft erwähnte "ahoy.py"-Skript habe ich auch noch nicht entdeckt, aber das scheint sich im Laufe der Entwicklung verflüchtigt zu haben. Gruß - Ingo
Thomas schrieb: > Hallo > könnte jemand die v0.5.28 hier reinsetzen zum download, oder den kniff > sage wie es von githup geht? Einfach auf Release und die zip runterladen und entpacken, dann im Web-GUI deiner DTU FW-Update starten und die passende .bin auswählen (bei mir die 221030_ahoy_0.5.28_esp8266_2e08ee0.bin). Sieht echt toll aus die neue Ansicht und da dürfte echt was weitergehen, hoffe es funktioniert wenigstens so gut wie bisher - nach oben ist natürlich immer Luft. :-) Leider wurden die Daten nur zum Teil übernommen, mußte die WR neu eingeben ebenso MQTT-Daten, Rest wurde übernommen.
Maik R. schrieb: > Leistungsbegrenzung via AHOY einen DTSU666 -> ModbusRTU -> > InfluxDB-/MQTT-Adapter in C oder C++ fertig? > ich steuere meine dtu-pro + dtsu666 über pymodbus, hab auch nen quick&dirty pymodbus (python) code für dtsu666
:
Bearbeitet durch User
Zu meinem letzten Post: keine Ahnung, was passiert ist, aber auf einmal funktioniert der Aufruf. Gemacht habe ich nichts, nur anstatt des Parameters "--config" den von der Hilfe angezeigten "-c" zu benutzen. Manchmal hilft die Hilfe. Inzwischen habe ich herausgefunden, dass
1 | -c Dateiname, |
2 | --config Dateiname |
3 | --config-file Dateiname |
gleichberechigt nutzbar sind und jetzt seltsamerweise alle 3 hier funktionieren. Hoffentlich bleibt das so. Nochmals Danke + Gruß - Ingo
Grisu schrieb: > Thomas schrieb: >> Hallo >> könnte jemand die v0.5.28 hier reinsetzen zum download, oder den kniff >> sage wie es von githup geht? > > Einfach auf Release und die zip runterladen und entpacken, dann im > Web-GUI deiner DTU FW-Update starten und die passende .bin auswählen > (bei mir die 221030_ahoy_0.5.28_esp8266_2e08ee0.bin). > > Sieht echt toll aus die neue Ansicht und da dürfte echt was weitergehen, > hoffe es funktioniert wenigstens so gut wie bisher - nach oben ist > natürlich immer Luft. :-) > Leider wurden die Daten nur zum Teil übernommen, mußte die WR neu > eingeben ebenso MQTT-Daten, Rest wurde übernommen. Die Version hat keine Möglichkeit zur Leistungslimitierung?!
Wo ist der Unterschied zwischen der BIN-Datei: "221030_ahoy_0.5.28_esp8266_1m_2e08ee0.bin" und der: "221030_ahoy_0.5.28_esp8266_2e08ee0.bin" Danke für eine kurze Rückmeldung. Gruß Jürgen
Moin, Jürgen D. schrieb: > Wo ist der Unterschied zwischen der BIN-Datei: > "221030_ahoy_0.5.28_esp8266_1m_2e08ee0.bin" > > und der: "221030_ahoy_0.5.28_esp8266_2e08ee0.bin" das "1m" im Namen weist bestimmt auf eine Speichergrenze hin - Ingo
Hallo Ingo, danke für den Hinweis. Gruß Jürgen
Moin, nachdem mein TSUN TSol-M800(DE) Wechselrichter nun auch seine Daten an die Hoymiles DTU preisgibt, habe ich nun noch eine Frage: welche Applikation empfiehlt die Gemeinde denn so als GUI-Server für den Raspberry, denn den hatte ich noch rumliegen und deswegen eingesetzt. Ich würde gern eine Anzeige im Browser des PCs sehen. Danke + Gruß - Ingo
El Capitan schrieb: > Die Version hat keine Möglichkeit zur Leistungslimitierung?! Doch, jedoch an anderer Stelle (habs nicht auf Funktion überprüft). Es gab nur im Vorfeld Diskussionen bei den Zwischenreleases, daß es weg wäre, deshalb fragte ich lieber bevor ich es aufspiele, war mir dann aber egal und nicht wichtig auf eine Antwort zu warten und war sehr positiv beeindruckt! Jetzt zeigt ein HM-1500 noch brav die 100% (unlimitiert) an, der andere jedoch nicht mehr die von früher bekannten 202% sondern gleich "Limit 202.1%", warum auch immer. :-) Allerdings fehlt nun die Funktion "kein Power-Limit". Man kann nur mehr nicht/persistent in Watt oder % einstellen nach Auswahl des WR, aber nicht mehr ohne Limitierung. Muß man wohl jetzt den jeweiligen max. Wert des WR eintragen oder 100%. Interessant finde ich auch die aktuelle Watt Anzeige (bisserl witzlos): Total 57.199999999999996 W Und die Zeit ist bei mir im Serial-Interface eine Stunde zurück. Gerri schrieb: > Wann und wie oft wird damit das Eprom mit beschrieben? Also in der neuen Version 0.5.28 jedenfalls nur mehr einmal auf Anforderung, wenn man den Wert setzt.
:
Bearbeitet durch User
Hallo Grisu et. al, eine Einstellung für Limitierung finde ich in der 0.5.28 nirgendwo. Oder mir fehlt die Phantasie… Mich beschleicht immer das Gefühl, dass die Einspeisung gedrosselt wird und ich die schöne Sonnenenergie nicht abschöpfe. Das Webinterface kann mir ja viel vorgaukeln. Malen wir mal nicht den Teufel an die Wand… Es wird immer besser. Toller Job
Die Funktion befindet sich unter „Serial Console“.
Hat jemand ein Schaltplan wo der 100µF Kondensator genau hin soll. Auf der wohl neuen Ahoy Website: https://ahoydtu.de/ Steht was von Kondensator und auch hier im Thread wurde das kurz erwähnt, jedoch finde ich kein Schaltplan/Schaltbild wo der hin soll. Ich habs zwar ganz gut verstanden wieso aber ein Schaltbild/plan ist da doch 100% eindeutig. Danke
Am Eingang des NRF-Moduls zw. 3,3V und Masse. Steht eh vielfach hier.
Die 5V bzw. 3.3V sollten möglichst in der Nähe der der beiden Module gepuffert werden. Zusätzlich zu den 100µF ist jeweils ein 100n Kondensator recht hilfreich. https://www.mikrocontroller.net/attachment/574169/Hoymiles.sch.pdf
Tobias K. schrieb: > Die Funktion befindet sich unter „Serial Console“. Da hätte ich sie niemals vermutet.... Befemdlich diese Stelle. Was trage ichein wenn ich KEIN Limit möchte? Was trage ich eine wenn ich 50% möchte, oder konkret nur 600 Watt einspeisen möchte? Das kann man doch auch im Webinterface kurz erläutern. Wäre m.E. viel funktionaler und unmißverständlich.
Warum nicht einfach 100% eintragen wenn du kein Limit möchtest? Was gäbe es da zu erklären? Gib halt 600W ein, wenn du das so willst oder den %-Satz der bei deinem den 600W entspricht.
IngoEF schrieb: > welche Applikation empfiehlt die Gemeinde denn so als GUI-Server für den > Raspberry Für meinen kleinen 3er Raspi nutze ich volkszaehler (kann das python-script ja mittlerweile direkt ansteuern, die Beispiel-Config hat alles korrekt drin). Grafana + InfluxDB geht auch, ist aber aufwendiger (und ich habs nicht auf dem Raspi hinbekommen da ich es nicht geschafft habe, influx2 zu installieren).
Christian E. schrieb: > Für meinen kleinen 3er Raspi nutze ich volkszaehler danke für den Hinweis. Mal sehen, was ich so hinbekomme. Welche Visualisierung läuft eigentlich in der esp-Umgebung? Ein probeweises
1 | apt install influxdb |
hat in meinem Raspi funktioniert; influxdb2 scheint nicht zu existieren.
Die Limitierung in % dürfte (zumindest bei meinem HM-1500) vermurkst sein. Angaben in Watt flüchtig und dauerhaft scheinen korrekt zu funktionieren. Nur in % wenn ich es eintrage tut sich nichts. Habt ihr ähnliche Beobachtungen?
Stimmt, bei mir das gleiche. Hatte es nur mit den Watt probiert und das funktionierte auf Anhieb.
Grisu schrieb: > Nur in % wenn ich es eintrage tut sich nichts. > Habt ihr ähnliche Beobachtungen? Kann ich bestätigen (HM-1500). Bei Einträgen in % kommt auch keine Antwort bei Ctrl result: Die Einstellungen in Watt funktionieren.
Hallo zusammen ... Ein Super Projekt!! Mein HM-600 ist im Versand und da kommt das natürlich gerade recht. Ich habe mal einen Wemos D1 mini geflasht und eingerichtet. Das NRF24L01+ sollte im laufe des Tages kommen. Will das ganze per MQTT mit Homeassistant verbinden und dabei ist mir aufgefallen das die Verbindung bzw. der login abgelehnt wird. Liegt das tatsächlich daran das die anderen Komponenten noch nicht angeschlossen sind? 2022-11-02 11:38:38: New connection from 192.168.xxx.xx:52211 on port 1883. 2022-11-02 11:38:38: Client <unknown> disconnected, not authorised. Gruß Wolfi
> 2022-11-02 11:38:38: New connection from 192.168.xxx.xx:52211 on port > 1883. > 2022-11-02 11:38:38: Client disconnected, not authorised. > Gruß Wolfi Ok, hat sich erledigt. Es durfte nicht der admin von mqtt (Mosquitto) sein. Einfach noch einen Benutzer anlegen in Homeassistant und dann ging es. INFO: MQTT is connected, 473 packets sent Gruß Wolfi
Tobias K. schrieb: > Stimmt, bei mir das gleiche. Hatte es nur mit den Watt probiert und das > funktionierte auf Anhieb. Was trägt man nun optimaler Weise ein, wenn man sicher keine Begrenzung haben möchte? Einen Phantasiewert wie 5000 Watt? Danke
planlos schrieb: > Was trägt man nun optimaler Weise ein, wenn man sicher keine Begrenzung > haben möchte? Die Leistung deines Wechselrichters mit "Persistent". Bzw. wenn er jetzt auf 100% läuft. Einfach nix. Das was Du dort einträgst wird einmal an den Wechselrichter übertragen. Es ist keine feste Einstellung in AHOY. Sondern wird nur einmal gesendet wenn Du auf "Send Power Limit" klickst.
:
Bearbeitet durch User
Und die Prozentangaben funktionieren beim HM1200 auch nicht.
Christian E. schrieb: > Für meinen kleinen 3er Raspi nutze ich volkszaehler (kann das > python-script ja mittlerweile direkt ansteuern, die Beispiel-Config hat > alles korrekt drin) Hallo Christian, Volkszähler läuft, UIDs habe ich für die einzelnen Messwerte erzeugt und entsprechend in
1 | ahoy.yml |
eingetragen, in der MySQL-DB sind alle Entities und Properties zu finden. Nur laufen trotz funktionierender DTU keine Daten aus ahoy in die Middleware. Sniffen auf port 80 zeigt keinerlei Aktivität oder bin ich bzgl. der Schnittstelle auf dem Holzweg? Welcher Trick fehlt mir noch? Gruß - Ingo
Guten Abend, Ich hab die Ahoy-DTU nach gebaut und installiert. Den Inverter eingerichtet, aber ich bekomm die Meldung das der „Inverter #0: is not available“. Ich hoffe ihr könnt mir weiterhelfen. Schön Dank schon mal im Vorraus.
Das ganze funktioniert nur wenn der Inverter Strom hat - sprich Tagsüber. Nachts hast du keine Verbindung.
planlos schrieb: > Tobias K. schrieb: > Was trägt man nun optimaler Weise ein, wenn man sicher keine Begrenzung > haben möchte? > Einen Phantasiewert wie 5000 Watt? Natürlich keinen Phantasiewert sondern den max.-Wert deines WR. Also beim HM-1500 eben 1500W.
Das hab ich schon gelesen, hat heut Mittag/Nachmittag auch nicht funktioniert.
Tobias K. schrieb: > funktioniert nur wenn der Inverter Strom Wenn die Solar Panel Spannung liefern, genauer. Hast Du denn in seriellen Ausgabe (z.B. mit HTerm) Mitteilungen gesehen, die die Kommunikation beschreiben, läuft Die?
:
Bearbeitet durch User
IngoEF schrieb: > Nur laufen trotz funktionierender DTU > keine Daten aus ahoy in die Middleware. > Kommen denn auch wirklich Daten vom Wechselrichter beim Raspi an? Am besten mal mit "--log-transactions --verbose" auf der Kommandozeile starten und schauen was da ankommt. Falls Du etwas python kannst, ggf. in der outputs.py ein paar Ausgaben einbauen oder mich per Mail kontaktieren (siehe git commit logs)
Angehängte Dateien:
-
IMG_20221104_100044.jpg
240 KB -
IMG_20221104_101549.jpg
260 KB
So, nun möchte auch ich (Teil der "stillen-Mitleser-Armee") Erfolg vermelden und mich bei den Entwicklern bedanken! Im provisorischen Betrieb ist ein Hoymiles HM600 (Serien-Nr. 11418....) mit einem von zwei TrinaSolar Panels, im Garten ausgebreitet (für das Garagen Flachdach fehlt es noch an Befestigungs- und Dichtungsmaterial). Ein WEMOS D1 mini (4MB) von Berrybase mit einem nRF24L01+ (Altbestand aus unbekannter Quelle mit o oben links!)und Stütz-Elko funktioniert mit ahoy 0.5.28 einwandfrei. (Einstellungen wie vom Kollegen "hoymiles-tarnkappe" hier etliche Threads zuvor empfohlen: CS = D8 (GPIO15), CE = D1 (GPIO5) und IRQ = D2 (GPIO4). Die ersten Versuche, einen NodeMCU-ESP32 von Joy-it zu flashen (liegen hier rum und hätten vermutlich auch etwas stabilere 3,3V), schlugen fehl, allenfalls rasch blinkende rote LED oder überhaupt keine Reaktion. Erst ein Webdienst, für den ich dann noch Chromium als Browser nehmen musste, klappte überraschend gut! Hier ist mein Problem, dass ich keine Referenz gefunden hatte, welcher PIN mit welchem GPIO korrespondiert, um die o.g. Zuordnungen. Das "Espressif ESP32 Flashtool" (nur Win) funktioniert bei mir nicht, der "ESP-Flasher-x86" (auch für Win) mit der NodeMCU-ESP32 ebenfalls nicht, aber mit der WEMOS D1 mini. Sehr hilfreich ist übrigens eine korrekte Seriennummer ;-) Es hat mich eine Stunde und Nerven gekostet, dass der Wechselrichter sich einfach nicht kontaktieren lassen wollte ... von der 1141 war noch eine "1" mehr auf meinen Handzettel reingerutscht und damit die letzte Ziffer beim Eintragen in die AHOY-DTU herausgefallen und der WR inzwischen, natürlich, hinter dem Panel verschraubt. Beim ersten Betrieb fällt mir auf, dass ein Shelly Plug-S Steckdosen-Adapter rund 50W MEHR Leistung vom Wechselrichter anzeigt, als die AHOY-DTU Software !? Wenn ich den WR softwaremäßig "restarte" wird die tägliche Stromernte gelöscht, die bisher aufgelaufene Gesamtmenge kWh bleiben erhalten? Eine Kleinigkeit: den Abfrageintervall von 30 Sek. habe ich mal auf 20 Sek. verkürzt, klappt problemlos, die Entfernung zum WR im Garten war zu diesem Zeitpunkt vielleicht 10-12m mit einer Kellermauer dazwischen (ich habe einen ebenerdigen Kellerausgang zum Garten) und jede Abfrage produzierte eine ordentliche Antwort. Die Anzeige "Every 30 seconds the values are updated" ändert die Einstellung auf 20 Sekunden aber nicht. Wirklich nicht wichtig, aber wenn ganz viel Zeit übrig ist, könnte der Intervall als Variable im String ausgegeben werden können.
Manfred H. schrieb: Zunächst eine Korrektur/Ergänzung: > Hier ist mein Problem, dass ich keine Referenz gefunden hatte, welcher > PIN mit welchem GPIO korrespondiert, um die o.g. Zuordnungen. "... welcher PIN mit welchem GPIO korrespondiert, um die o.g. Zuordnungen der CE/CS/IRQ vornehmen zu können". Zur AHOY-DTU Software: Wenn ich die Elektronik zum Kollegen im Dorf mitnehme, um ihm die Funktionen an SEINER PV-Anlage zu zeigen, komme ich außerhalb meines WLAN nicht auf die Weboberfläche zum Einstellen z.B. der Seriennummer. Wie reagiert die AHOY-DTU, wenn beim Einschalten das eingestellte Netz nicht erreichbar ist? Rückfall auf den eigenen Accesspoint? Manfred
Wieder einmal jemand, der mit dem Projekt Geld verdienen will. Na ja, die Abmahn Rechtsanwälte wird´s freuen und das Finanzamt, Gewerbeaufsichtsamt und einige andere auch. https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-ahoy-mit-gehaeuse-und-anleitung/2262602790-168-2700
Ameise schrieb: > Wieder einmal jemand, der mit dem Projekt Geld verdienen will. > Na ja, die Abmahn Rechtsanwälte wird´s freuen und das Finanzamt, > Gewerbeaufsichtsamt und einige andere auch. > > https://www.ebay-kleinanzeigen.de/s-anzeige/hoymiles-dtu-ahoy-mit-gehaeuse-und-anleitung/2262602790-168-2700 Was sollte denn dagegen rechtlich einzuwenden sein? Das sollte jeder Ameise klar sein, NIX! NIX!
Zudem er es sogar ohne FW anbietet, also als reine HW die man erst selbst in Betrieb nehmen muß. Verwerflich, ja in gewissem Rahmen, aber sonst auch schon rein gar nichts. Höchstens die Finanz könnte daran Gefallen finden! Und irgendwann wirst meine auch auf einer solchen Plattform angeboten finden, wenn ich mein System möglicherweise nächstes Jahr umstelle und keine Bedarf mehr daran haben werde. Vielleicht behalt ich es aber aus sentimentalen Gründen oder als Reserve, wer weiß - freu mich allenfalls schon auf deine "Anwälte". Manfred H. schrieb: > Zur AHOY-DTU Software: > Wenn ich die Elektronik zum Kollegen im Dorf mitnehme, um ihm die > Funktionen an SEINER PV-Anlage zu zeigen, komme ich außerhalb meines > WLAN nicht auf die Weboberfläche zum Einstellen z.B. der Seriennummer. > Wie reagiert die AHOY-DTU, wenn beim Einschalten das eingestellte Netz > nicht erreichbar ist? Rückfall auf den eigenen Accesspoint? Du kannst dich doch mit deren Hotspot verbinden und sein WLAN eintragen. Wieso fragst du so etwas anstatt es einfach mal auszuprobieren. Dreh dein WLAN in der Nacht mal kurz ab und versuch es ... Dann hast Sicherheit und zudem schon mal geübt, um nicht allzu blöd vor dem Freund dazustehen.
:
Bearbeitet durch User
Beitrag #7242064 wurde vom Autor gelöscht.
Hallo Gemeinde ... Blöde Frage! Ich hab irgendwo gelesen das auf Git auch die Dev als binarys irgendwo zum download sind. Bin ich blind, oder wo findet man die denn genau? Gruß Wolfi
Beitrag #7243218 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
dev.jpg
170 KB
Wolfi schrieb: > Hallo Gemeinde ... > > Blöde Frage! Ich hab irgendwo gelesen das auf Git auch die Dev als > binarys irgendwo zum download sind. Bin ich blind, oder wo findet man > die denn genau? > > Gruß Wolfi
Beitrag #7243321 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Hallo, Ich weiß nicht ob ich mit meinem Problem hier richtig bin. Wenn nicht, wäre ich für einen passenden link dankbar. Der link in der Ahoy weboberfläche scheint mir gehacked. Ich habe einen Hoymiles 1000. Und eine Box mit esp 8266. Die neueste Firmware ist geladen. Leider bekomme ich keine Daten Hoymiles 1000. Laut meinem shelly wir Energie erzeugt. Am WR war schon mal eine hoymiles dtu pro. Diese ist aktuell spannungslos, Den WR hatte ich von 230V getrennt. Kann mir jemand helfen? Grüße Werner
Dann hat er schlicht keine Verbindung zum WR. Hast du die richtige SN eingetragen und auch die Pin-Zuordnung korrekt deinem Aufbau entsprechend eingestellt?
Werner schrieb: > Hallo, > Ich weiß nicht ob ich mit meinem Problem hier richtig bin. > Wenn nicht, wäre ich für einen passenden link dankbar. > Der link in der Ahoy weboberfläche scheint mir gehacked. > Ich habe einen Hoymiles 1000. was ist das für ein WR? MI oder HM? oder welche serienummer hat er, die ersten 6 stellen würde auch weiter helfen
Werner schrieb: > Der link in der Ahoy weboberfläche scheint mir gehacked. wie? kannst du einbisschen genauer sein? sonst ist die hilfe unter https://discord.com/channels/984173303147155506/ zu finden
:
Bearbeitet durch User
Angehängte Dateien:
Das schaut für mich aus wie eine Abzocker seite
Angehängte Dateien:
Es ist ein HM 1000, HMS-1000-2T Seriennummer = 11448016... Diese hab ich im Web ui eingetrage
Werner schrieb: > Es ist ein HM 1000, HMS-1000-2T > Seriennummer = 11448016... > Diese hab ich im Web ui eingetrage ist er jetzt ein HM oder HMS? imho, es werden folg serienummern unterstützt: HM-300 | 1121 HM-350 | 1121 HM-400 | 1121 HM-600 | 1141 HM-700 | 1141 HM-800 | 1141 HM-1200 | 1161 HM-1500 | 1161
Werner schrieb: > Diese ist aktuell spannungslos, Den WR hatte ich von 230V getrennt. Vielleicht solltest den WR mal in Betrieb nehmen, woher sollte er wohl sonst den Strom für die Funkübertragung hernehmen wenn du ihn vom Netz trennst und somit außer Betrieb nimmst? Das war doch mit deiner DTU-pro auch nicht anders, oder?
:
Bearbeitet durch User
Grisu schrieb: > Werner schrieb: >> Diese ist aktuell spannungslos, Den WR hatte ich von 230V getrennt. > Vielleicht solltest den WR mal in Betrieb nehmen, woher sollte er wohl > sonst den Strom für die Funkübertragung hernehmen wenn du ihn vom Netz > trennst und somit außer Betrieb nimmst? > Das war doch mit deiner DTU-pro auch nicht anders, oder? wr braucht die dc-spannung der panels zum funktionieren bzw. zur übertragung, nicht das ac-netz, wenn man ihn vom ac-netz trennt, er produziert einfach nichts, aber funktioniert weiter
AhoyDTU development Builds findet man nach dem Github Login unter Actions. Dort einfach einen der letzten Build Läufe auswählen und dann hängen die Artefakte als ein ZIP ganz unten dran. Im ZIP findet man die ESP8266 und ESP32 builds. Ich glaube sogar eine 1MB Variante für ESP8265 oder so ist darunter.
Werner schrieb: > Das schaut für mich aus wie eine Abzocker seite Hallo Werner, bitte mal den Aluhut beiseite legen, das ist die Anmeldeseite von Discord. Die Entwickler und viele andere unterhalten sich dort weil es ein bißchen interaktiver ist, als das mittlerweile 14 Seiten lange und sehr lineare uC Forum hier. Der Meldung nach zu urteilen versuchst Du zu senden, bekommst aber keine Antwortpakete zurück. Den Serial Debug Level könntest Du ggf. noch etwas hochstellen und auch mal ein Log des USB Serial Logs mitschneiden. Da meldet sich der NRF24 mit Modellbezeichnung und ob er richtig angeschlossen ist. Vermutlich kommt er aber mit dem D3 Pin als IRQ nicht zu Recht. Was ist denn eigentlich die neueste Firmware (0.5.28 wie auf Deinen Screenshots oder die development Version 0.5.32) und vor allem wie sieht es in Deiner Blackbox mit ESP8266 drin aus ? Ist da ein Wemos D1 mini drin oder ein etwas größerer NodeMCU ? Der Wemos D1 mini braucht i.d.R. den IRQ auf D1 / D2 weil er bei D3 nichts empfängt. Die Ursache kennen wir nicht ist aber m.W. hinreichend in der FAQ und get-started dokumentiert. Hast Du einen NRF24L01+ mit einer externen Antenne oder nur so einen einfachen mit auf die Schaltung geäzter Leiterbahn ? Ist ein entsprechender Elko am NRF24 Pin1&2 GND&+3.3V verbaut ? Ein Bild von Deiner Schaltung wäre auch noch ganz gut. Viele Grüße, Stefan
Manfred H. schrieb: > "... welcher PIN mit welchem GPIO korrespondiert, um die o.g. > Zuordnungen der CE/CS/IRQ vornehmen zu können". Schau doch bitte mal in die getting started Beispiele auf der lumapu/ahoy Seite dort sind die vorgeschlagenen Pin Verbindungen dokumentiert. Je nach verwendetem ESP8266 / ESP32 Modul kann man sich die Pinouts im Internet suchen und dann sind dort die GPIO Nummern angegeben. Die Bezeichnungen / Zuordnungen von DX Pins und GPIO können sich je nach Modell unterscheiden, daher sind die GPIOs eigentlich die richtigen Bezeichnungen. MISO, MOSI und SCLK sollten klar sein (bei ESP32 gibt es die V-/H-, ich glaube die OpenDTU Dokumentation beschreibt da die richtigen). Und für die anderen drei CE/CS/IRQ hast Du die freie Wahl, wir haben ein Beispiel seit Urzeiten als Default festgelegt und einige haben so auch Ihre Platinen geätzt / gelötet daher bleibt es wohl auch dabei. Obwohl es immer wieder Berichte gibt, dass die Kombination von D3 = IRQ auf dem Wemos D1 mini (v1/v3) Probleme macht. Hier kann man einfach den D1 / D2 Pin verwenden und es sollte nach Konfigurationsänderung im Setup gehen.
Ziyat T. schrieb: > wr braucht die dc-spannung der panels zum funktionieren bzw. zur > übertragung, nicht das ac-netz Ja, da hab ich mich wohl unglücklich um nicht zu sagen falsch ausgedrückt, ein Panel ohne Sonne (etwas Licht halt) beschert ihm aber auch noch keine Funkverbindung.
:
Bearbeitet durch User
Volker.B. schrieb: >> Blöde Frage! Ich hab irgendwo gelesen das auf Git auch die Dev als >> binarys irgendwo zum download sind. Bin ich blind, oder wo findet man >> die denn genau? >> >> Gruß Wolfi Du klickst auf das entprechende "DEV", dann auf der neuen Site ganz nach unten scrollen.
Angehängte Dateien:
-
20221107_125951.jpg
240 KB -
Screenshot_20221107-125329_Opera_beta.jpg
270 KB
Hallo, Zunächst mal die Schaltung Beiliegend die Bilder. Der link oben https://discord.com/channels/984173303147155506/ Bringt mich nicht weiter. Welchen Channel muß ich öffnen, mit welchem Thema.
Vorzugsweise lötest gemäß voherigen Beiträgen D4 nach D1 und D3 nach D2 um und stellst es in der Config dann entsprechend ein. CS: D8 CE: D1 IRQ: D2 Und dann hängst wenigstens ein Panel an bei Sonnenschein, wenn du ihn schon nicht ans Netz hängen möchtest, wirst halt auch keine brauchbaren Daten dann bekommen. Sonst sieht dein Machwerk gut aus.
:
Bearbeitet durch User
Sorry (fast schon off-topic): @Werner - ich beziehe mich auf Dein "20221107_125951.jpg": Darf ich fragen, was das für Kabel sind und wie Du das so sauber gelötet bekommst? Ich habe schon wirklich viel gelötet, aber das gefällt mir besonders gut!
:
Bearbeitet durch User
Dirk schrieb: > Ich habe schon wirklich viel gelötet, aber das gefällt mir > besonders gut! Gutes Werkzeug, gutes "Blei" Lötzin, dann sollte das schon passen
Litzen abisolieren, verdrillen, durchstecken und von unten mit etwas Zinn mit Flußmittel kurz hinhalten, das sieht doch dann bei allen so aus.
Grisu schrieb: > Litzen abisolieren, verdrillen, durchstecken und von unten mit etwas > Zinn mit Flußmittel kurz hinhalten, das sieht doch dann bei allen so > aus. Wenn die Löcher groß genug sind, verdrille und verzinne ich das vorher. Dann ist auch alles schön "durchtränkt";-). Kable, ja.. auf jeden Fall nicht die Flachkabel/Flachbandleitung von der Rolle. Da ist meist zu wenig Kupfer dran. Und nicht Dupond Kabel abschneiden und verlöten. Das Zeugs läßt sich oft gar nicht löten, keine Ahnung was das für ein Stahldraht ist. Beim Absiolieren keine der feinen Litzen abschneiden!! und BLEILOT!
Werner schrieb: > Hallo, > Zunächst mal die Schaltung > Beiliegend die Bilder. > > Der link oben > https://discord.com/channels/984173303147155506/ > Bringt mich nicht weiter. > Welchen Channel muß ich öffnen, mit welchem Thema. >> Es ist ein HM 1000, HMS-1000-2T >> Seriennummer = 11448016.. du hast angegeben dass du ein wr mit 1144 hast, das ist ein wr der HMS serie, den unterstützt die ahoy-dtu nicht!
Ok, War wohl nix. Kennt jemand eine Lösung für einen HMS 1000?
Vielen Dank für eure Unterstützung. Der link oben https://discord.com/channels/984173303147155506/ Bringt mich nicht weiter. Welchen Channel muß ich öffnen, mit welchem Thema?
Grisu schrieb: > Litzen abisolieren, verdrillen, durchstecken und von unten mit etwas > Zinn mit Flußmittel kurz hinhalten, das sieht doch dann bei allen so > aus. Ahh. Die sind durchgesteckt. Ich bin davon augegangen, dass ihr (wie ich) einen ESP32 habt, wo die Pins schon angelötet sind. Dort dann noch zusätzlich eine Litze dranlöten, stelle ich mir schwierig vor. Aber klar: Man braucht die Pins ja nicht zwingend - und wenn man's durchstecken kann, dann gehts. Danke für die Antworten!
Joe G. schrieb: > Eine Platine ist erfolgreich bestückt. Die Daten [1] sind somit > freigegeben. Alle die eine Zusage zu einer Platine von mir haben, > erhalten nun in den nächsten Tagen Post. > > [1] https://aisler.net/p/EAYHGSED Danke fürs bereitstellen des Layouts. Hab eben welche geordert. Gruß Wolfi
Angehängte Dateien:
Ziyat T. schrieb: > sonst ist die hilfe unter > https://discord.com/channels/984173303147155506/ zu finden Das scheint nicht ganz zu funktionieren, siehe Bild
Angehängte Dateien:
Discodia schrieb: > Ziyat T. schrieb: >> sonst ist die hilfe unter >> https://discord.com/channels/984173303147155506/ zu finden > > Das scheint nicht ganz zu funktionieren, siehe Bild eigentlich den link brauche ich fast jeden tag, aber ev. diesen probieren https://discord.gg/RxC4kx4z
:
Bearbeitet durch User
Herzlichen Dank für das Board. Hab's mir besorgt und freue mich darauf meinen fliegenden Aufbau abzulösen. Kannst Du bitte kurz auflisten was für die komplette Bestückung noch nötig ist? Gerade die Kondensatoren. Vielen Dank Alexander
Den 100µ Elko (manche nehmen noch einen 100nF dazu), USB-Kabel (zur Versorgung) und Drähtchen, wenn du es fix verlöstest (was für die Funktion auch nur vorteilhaft ist).
Hallo, wie stehen die Chancen, dass die HMS-Serie von Hoymiles auch von OpenDTU unterstützt wird? Vielen Dank.
Sicher nie, da es ganz anders funktioniert bzw. aufgebaut ist. Höchstens, daß es vielleicht einmal ein eigenes Projekt dazu gibt, wenn es einmal funktionieren sollte. Hier kannst gern mitentwickeln: Beitrag "Re: Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless"
:
Bearbeitet durch User
Moin, ich bekomme 5.28 nicht ans laufen, bis 5.17 alles ohne Probleme! Das Teil geht noch dem flashen nicht in den AP Modus! Habe den eindruck das Reste im Flashspeicher bleiben!
ja hatte ich auch, lösche den Flash einfach vorher dann sollte es funktionieren.
Ist es per default so, dass die Zähler (Total Yield Total/Day) nach einem reboot des WR zurückgesetzt werden bzw. neu starten? Hardware ist ein ESP32.
Nein eigentlich nicht, der Total zählt seit Erstinbetriebnahme bei mir hoch und dürfte im WR selbst abgelegt sein. Über Nacht machen sie doch täglich einen Reboot wenn sie ohne Licht völlig abdrehen. Der tägliche setzt sich natürlich zurück, wenn du ihm den Saft nimmst oder rebootest.
:
Bearbeitet durch User
Grisu schrieb: > Nein eigentlich nicht, der Total zählt seit Erstinbetriebnahme bei mir > hoch und dürfte im WR selbst abgelegt sein. Über Nacht machen sie doch > täglich einen Reboot wenn sie ohne Licht völlig abdrehen. > Der tägliche setzt sich natürlich zurück, wenn du ihm den Saft nimmst > oder rebootest. Kann ich so bestätigen.
Ich warte im Moment auf Solarpanels und einen Hoymiles HM-600 Wechselrichter und möchte die Ahoy DTU verwenden. Mein Problem ist, daß ich am Aufstellort der Panels kein WLAN habe (Gartenhausdach mit einigen Hindernissen). Ich möchte auch keine zusätzlichen WLAN Aussenantennen installieren, um nicht die ganze Gegend übermäßig mit meinen Signalen zu belästigen. Da ich seit längerem eine kleine LoRa, bzw. LoRaWan Infrastruktur über TTN mit einem Indoor Gateway und einigen Sensoren am Laufen habe, wollte ich die Datenweitergabe der DTU über LoRa implementieren. Der erste Ansatz war die Portierung des Ahoy Codes auf meine LoRa Platformen. Ich verwende Heltec Lora 151 Nodes mit STM32L151 MCU und Nodes mit AtTiny3216. Sinnvoller wäre aber doch eher die Möglichkeit, die Daten der Ahoy DTU über eine der gängigen Schnittstellen wie z.B. I2C anzapfbar zu machen. Also den LoRa Node an die DTU zu hängen. Jetzt die eigentliche Frage: Hat ausser mir noch jemand ähnliche Anforderungen und würde es Sinn machen, eine entsprechende Schnittstelle in die Ahoy DTU zu integrieren? Evtl. als optionale Möglichkeit über Defines.
Ich habe gerade 3 Tsol M800 an der DTU hängen. Geht einwandfrei. Nochmals vielen Dank.
Hallo zusammen, auch von mir erst mal ein herzliches Dankeschön and die Akteure hier. Ich bin mit der exakt gleichen Fragestellung nach der Regelung der Hoymiles ohne den Kauf einer (sauteuren) DTU Pro vor 2 Wochen auf diese Seite gestoßen. Mittlerweile habe ich 3 Hoymiles (1xHM-600, 2xHM-1500) mit 9 405Wp-Modulen installiert. Eure systematische Herangehensweise finde ich klasse !!! Und natürlich das Ergebnis. Da ich alles, was ich brauchte, sowieso aus anderen Projekten hier herumliegen hatte, habe ich gestern mal den ESP8266m, den NRF24L01+ und die Kabel zusammengesteckt, das NodeMCU Flash und die 0.5.28 heruntergeladen und auf den ESP geflasht. Funktionierte wunderbar. Einrichten des WLANs mit Einbindung in mein existierendes ging auch und alle 3 Hoymiles wurden richtig erkannt. Heute am sonnigen Tag gingen dann auch alle Hoymiles ins Netz und lieferten ihre Daten. Das taten sie allerdings nicht immer direkt vollzählig. Ich denke, dort muss ich noch den optimalen Aufstellungsort finden. Aber für einen ersten Start bin ich super zufrieden. Auch das Limitieren der Leistung hat einwandfrei funktioniert. Wobei aber noch zu sagen bleibt, dass eine Limitierung auf eine Wattzahl auch eine prozentuale Limitierung mit sich bringt. Limitiere ich den HM-1500 auf 500 Watt, so wird er bei 600 Watt Sonnen-Leistung auch nur 200 Watt bringen. Jetzt bleibt nur noch die Erstellung eines io-Boker-Servers. Gruß André
Das hätte ich jetzt so bei meinen nicht festgestellt, da war das Limit immer auf den Max-Wert bezogen, obgleich ich mit der 0.5.28 nur mehr in Watt einstellen kann und sich bei % nichts tut. 50% bedeuten also eine Limitierung auf 750W beim HM-1500 und nicht eine Halbierung des aktuell gerade erzeugten bzw. möglichen Wertes. Das ginge m.E. ja auch gar nicht, da er den aktuell möglichen Wert nicht kennt oder mißt um ihn überhaupt halbieren zu können.
Mal eine ganz andere Frage: Die DTU zeichnet ja nichts selber auf, kann aber MQTT. Gerne würde ich das ganze Aufzeichnen und Visualisieren, wie mache ich das am besten? Ich habe schon viel gelesen und ausprobiert, hatte sogar einen IT Studenten (gegen Bezahlung) mal daran der irgendwas gemacht hat aber auch nicht hinbekommen hat. Ich besitze eine Synology DS 220+. Raspeberry Pi würde ich auch verwenden sind aber derzeit unverschämt teuer. Ich selber habe diverse Male ioborker per Docker probiert bekomme aber keine Verbindung hin. Der Student hat irgendwas von Mosquitto Sever installiert, Influx Datenbank und Grafana. Funktionierte aber an einigen Stellen nicht und jetzt meldet er sich nicht mehr. Gibt es irgendwo eine Seite oder irgendjemand der mir das einfach erklären kann was ich machen muss? Das ganze was ich bis jetzt gelesen habe und gemacht wurde ist für mich Raketenwissenschaft. Das kann doch insgesamt nicht so schwer sein einfache Datenpunkte aufzunehmen und zu visualisieren? Denn ich habe auch noch einen IR Lesekopf an meinem Stromzähler der auch MQTT kann und dann würde ich beides gerne übereinanderlegen. Nur per Browser den gerade ist Wert abrufen bringt mir nicht viel.
Hallo habe ein HM-1200 , der Serien Nummer fängt mit 1061 an .. der wird nicht erkannt von Ahoy . Wie bekomme ich den zum laufen ?
revilo schrieb: > Hallo habe ein HM-1200 , > der Serien Nummer fängt mit 1061 an .. der wird nicht erkannt von Ahoy . > Wie bekomme ich den zum laufen ? Laut Seriennummernliste hast du mit der 1061 einen MI-1200. HM-1xxx haben 1161. Ob das einen Unterschied macht ob HM oder MI weiß ich nicht.
Ok , danke für den Hinweis .. da gibts schon mögliche Ansatzpunkte zur Integration: https://github.com/lumapu/ahoy/issues/258
@Alexander H Erst mal die Frage: Worauf hat Dein Student Mosquitto, Influx, etc. installiert? Die Ahoy DTU und der IR Lesekopf produzieren Daten und können diese an einen MQTT Broker (z.B. Mosquitto, ==> publish) weitergeben. Dort können die Daten von Interessenten abonniert werden (==> subscribe) und weiterverarbeitet werden. Wenn Du aus diesen Daten Grafiken oder Statistiken erzeugen willst, mußt Du natürlich mindestens die Daten aus dem interessierenden Zeitraum parat haben. Dafür brauchst Du eine Datenbank (z.B. InfluxDB, Zeitreihen-Datenbank). Die eigentlichen Diagramme kannst Du dann z.B. mit Grafana erzeugen. Damit das funktioniert, müssen mindestens der MQTT Broker und die Datenbank permanent laufen, oder zumindest in der Zeit, in der Daten entstehen. Da käme dann der Raspberry Pi als kleiner sparsamer Server ins Spiel. Darum meine Frage oben nach dem Installationsort. Ich hatte zum Thema Stromzähler vor ein paar Tagen schon mal was geschrieben: Beitrag "Re: Tasmota / Volkszähler - Wie fängt man an?" Unter dem Blickwinkel ist die Ahoy DTU nur ein weiterer Datenproduzent. Zusammengefaßt könnte es so aussehen: 1. diverse Datenquellen (Stromzähler, Ahoy DTU, Wettersensoren, usw.) publizieren Daten per MQTT 2. MQTT Broker vermittelt die Daten an Interessenten 3. Aufbereiten der Daten des MQTT Brokers (grafisch z.B. mit NodeRed, oder per Config-Datei mit Telegraf) 4. Weitergabe der aufbereiteten Daten an die Zeitreihen-Datenbank 5. Erzeugen von Grafiken, Statistiken aus den Zeitreihen-Daten Die Verwendung eines MQTT Brokers ist maximal flexibel: Wer Daten produziert, stellt sie dort bereit und wer sich für die Daten interessiert, holt sie dort ab. Nichts ist fest verdrahtet und Produzenten und Konsumenten sind voneinander unabhängig. Was Tools wie ioBroker, HomeAssistant hier übernehmen können, weiß ich nicht. Ich baue mir bisher lieber alles aus Einzelkomponenten zusammen und habe auch keinen Bedarf für eine Hausautomatisierung. Ich wollte mich aber demnächst mal damit befassen. In Deinem Fall böte es sich an, die Zeitreihen-Datenbank auf dem NAS zu installieren, wenn das geht. Auch damit habe ich keine Erfahrung. Wenn das NAS Betriebssystem mit Docker klarkommt, kannst Du natürlich auch alle nötigen Dienste dort als Container laufen lassen. Mosquitto, NodeRed und InfluxDB sind nicht besonders resourcenintensiv und laufen bei mir problemlos neben einigen anderen Diensten auf einem RPi4 mit 4 GByte RAM.
revilo schrieb: > Hallo habe ein HM-1200 , > der Serien Nummer fängt mit 1061 an .. der wird nicht erkannt von Ahoy . > Wie bekomme ich den zum laufen ? 1061 ist ein MI1500/MI1200 und kann mit ahoy nicht ausgelesen werden! für MI gibts: https://github.com/Ziyatoe/DTUsimMI-Hoymiles
@ Alexander H. Genau so wie du es vor hast, habe ich es schon zum Teil umgesetzt. Habe auf meiner Synology im Docker Container den IOBroker installiert. Dort dann über MQTT und andere Adapter bekomme ich dann die Daten. Unter anderem vom Stromzähler und HM600. Zur einfachen Verarbeitung habe ich noch ein Java Skript aus dem Internet etwas modifiziert (für Speicherung der Werte gestern, letzte Woche, letztes Jahr). Darüber hinaus verwende ich Flot für Diagramme und Vis für die Visualisierung (am einfachsten und am schnellsten). Besser ist wohl Influx und Grafana, erschien mir aber für den Anfang zu kompliziert.
Alexander H. schrieb: > Ich selber habe diverse Male ioborker per Docker probiert bekomme aber > keine Verbindung hin. > Der Student hat irgendwas von Mosquitto Sever installiert, Influx > Datenbank und Grafana. > Funktionierte aber an einigen Stellen nicht und jetzt meldet er sich > nicht mehr. Hallo, ich habe es nach dieser Anleitung gemacht, läuft absolut stabil seit 2 Wochen https://schroederdennis.de/tutorial-howto/shelly-tasmota-mqtt-node-red-influxdb-ins-grafana-dashboard-anleitung/ https://grafana.com/grafana/dashboards/16850-pv-power-ahoy/
Vielen Dank, Jetzt muss ich mich mal Dumm stellen. Die Hardware ist vorhanden jedoch habe ich keine Ahnung wie ich das Programm von https://github.com/Ziyatoe/DTUsimMI-Hoymiles auf meinen ESP8266 bekomme. Bei meinem HM habe ich es über https://ahoydtu.de gemacht was für mich kein Problem war. Vll kann mir das hier jemand Step for Step erklären oder mir eine Anleitung schicken. An sonixx@arcor.de
Ich konnte die .bin es mit esptool-v4.2.1-win64.zip am Win-PC hochladen.
Vielen Dank für die geleistete Arbeit. Ich hab mir openDTU von tnobody zusammengebaut, alles funktioniert einwandfrei. Allerdings, seit ich eine DTU pro parallel betreibe, gibt es Störungen bei der Übertragung. Ist da irgendwas bekannt oder irgendwas zu beachten? openDTU und DTU pro haben jeder seine eigene SerialId. Ich habe eine DTU pro und einen HM-1500 falls ich irgendwas mit meinen begrenzten Mitteln beitragen kann.
Darfst ja auch nur mit einer DTU verbinden, also entweder oder. Zumindest nicht die selben S/N (Wechselrichter) auf beiden verwenden, steht schon lang früher wo (glaub sogar mehrfach) in diesem Endlosthread.
:
Bearbeitet durch User
Sonixx schrieb: > Vielen Dank, > Jetzt muss ich mich mal Dumm stellen. Die Hardware ist vorhanden jedoch > habe ich keine Ahnung wie ich das Programm von > https://github.com/Ziyatoe/DTUsimMI-Hoymiles auf meinen ESP8266 bekomme. > Bei meinem HM habe ich es über https://ahoydtu.de gemacht was für mich > kein Problem war. > Vll kann mir das hier jemand Step for Step erklären oder mir eine > Anleitung schicken. An sonixx@arcor.de geht es um HM oder MI? falls MI: unter https://github.com/Ziyatoe/DTUsimMI-Hoymiles gibt es kein binary file; dort gibts ja ein readme, und es steht dort, dass man die arduino-ide braucht, nicht?
:
Bearbeitet durch User
Ok Danke, ArduinoIDE habe ich aber wie gehts jetz weiter, wie bekomme ich die dateien auf den chip oder so ähnlich?
Sonixx schrieb: > Ok Danke, > ArduinoIDE habe ich aber wie gehts jetz weiter, wie bekomme ich die > dateien auf den chip oder so ähnlich? google hilft da vielleicht weiter: https://randomnerdtutorials.com/how-to-install-esp8266-board-arduino-ide/
Seit der 0.5.41 findet sie nach einem Neustart bei mir den Zeitserver nicht mehr (DHCP). Muß dann immer zuerst auf "vom Browser übernehmen" klicken. Hat das noch jemand?
Kann ich so bestätigen. Man kann im Setup auch auf NTP Sync nach einiger Zeit drücken. Vorher gibt es offenbar Probleme mit der Namensauflösung.
Ich habe eben ein Update aus der "ahoy-dtu" heraus von 0.5.28 auf v0.5.41 durchgeführt, endet mit der Meldung "... success, ... reboot in 20 sec". Dann kommt aber zunächst der eigene Accesspoint "AHOY-DTU", mit dem ich mich verbinden kann, aber der Webserver reagiert nicht auf die IP 192.168.1.1 !?? Habe ich irgendetwas falsch verstanden mit dem OTA-Update?
Dürfte sich wohl zu viel verändert haben und man muß alles neu konfigurieren, war bei mir auch so.
Ja, sieht so aus. Zum neu konfigurieren müsste ich aber schon den eingebauten webserver bemühen. Also nun einfach den/das *.bin File (mit esp-flasher-x86) geflasht, offenbar erfolgreich, denn in dessen Terminal sehe ich erste Lebensäußerungen, dass z.B. das nRF24-Modul nicht gefunden wird. Stimmt, ich habe es ja an D8/D1/D2 angeflanscht. Also Laptop mit dem Ahoy-eigenen Accesspoint verbunden, die Startseite auf 192.168.1.1 aufgerufen ... keine Chance, irgendwann kommt time-out. Grundsätzlich läuft der Wemos D1, beim Start blinkt die blaue LED einmal kurz (wie schon vorher) und nun noch einmal deutlich länger. Gleich schiebe ich noch einmal die v0.5.28 auf den Chip, sollte ja weiterhin funktionieren.
Manfred H. schrieb: > aber der Webserver reagiert nicht auf die IP > 192.168.1.1 !?? ... nimm mal wie in der Dokumentation beschrieben ist, die 192.168.4.1 !
Manfred H. schrieb: > Gleich schiebe ich noch einmal die v0.5.28 auf den Chip, sollte ja > weiterhin funktionieren. Jetzt wird es kurios: soeben die Version 0.5.28 geflasht (Win10, esp-flasher-x86), aber dieses Mal das Terminal offen gelassen. Etliche Meldungen, Systemparameter usw. laufen durch, zuletzt eine time-out Meldung, dass der AP (ahoy-dtu) in 60 Sek. geschlossen wird, in 45 Sek., in 30 Sek. usw. Nun das Laptop mit diesem AP verbunden, rödelt hier ziemlich lange herum, während im Terminal sich eine Meldung wiederholt: "1 client connected" und "AP closed in xx sec." oder ähnlich. Windows meldet "verbunden", ok. Im Firefox die IP 192.168.1.1 aufgerufen, die Eingangsseite vom "ahoy-dtu" erscheint in voller Schönheit und ich könnte jetzt alles so konfigurieren, wie ich es gerne hätte. Ich kann aber auch gleich das OTA Update machen ... ;-) Auf der entsprechenden Seite mit dem Update-Button und der Dialogzeile, um den passenden File auf dem Rechner aufzusuchen, bin ich mit dem Finger etwas schneller als mit dem Kopf und betätige den Update-Button bei leerer Adresszeile! Weniger als eine Sekunde später erscheint die Meldung "update successful" oder ähnlich und "reboot in 20 sec." ;-) Der Laptop verliert die Verbindung zum AHOY-DTU Accesspoint, kann wieder verbunden werden, aber nun klappt der Aufruf der Startseite unter 192.168.1.1 nicht mehr!! Erkenntnis? Ich kann die Version 0.5.28 flashen, einrichten und verwenden, ich kann die Version 0.5.41 auch flashen, aber nicht einrichten oder gar verwenden (gleicher Laptop, gleiches Win10, gleicher WEMOS D1 mini, gleiches Kabel, gleiche Powerbank zur Versorgung).
Gerri schrieb: > Manfred H. schrieb: >> aber der Webserver reagiert nicht auf die IP >> 192.168.1.1 !?? > > ... nimm mal wie in der Dokumentation beschrieben ist, die 192.168.4.1 ! oh, tatsächlich! Ich musste erst noch einmal umflashen auf die Version 0.5.41, aber jetzt klappt es! Besten Dank!! Edit: was ich jetzt nicht noch einmal probiert habe, ob das OTA-Update nun klappt.
:
Bearbeitet durch User
Hallo, Zunächst einmal vielen lieben Dank an alle, die das Projekt entwickelt haben. Das Forum liest sich vom Start weg wie die Ermittlungen in einem Krimi. Das Setup mit einem eps8266 lief bei mir vom Start weg rund mit einem Inverter der Serie 1141########. Als MQTT-Broker habe ich Mosquito auf einem Raspberry Pi laufen, dahinter eine Node-Red Instanz zum spielen mit einem Dasboard. Um etwas zum Projekt beizutragen, würde ich den Node-Red- Flow hier posten. Wäre das OK? Oder besser woanders? Gruß, Ralf Thielecke (Der so blöd ist, Ende November eine Solaranlage zu bauen)
Ralf Thielecke schrieb: > Um etwas zum Projekt beizutragen, würde ich den Node-Red- Flow hier > posten. Wäre das OK? Oder besser woanders? Hallo Ralf, vielleicht direkt im github? Dort zusammen mit allen anderen Dokus macht vielleicht am meisten Sinn? Das wäre so mein Vorschlag. Später hier suchen ist dann fast wie ne Stecknadel im Heuhaufen. Viele Grüße Herbert
Hallo, ich wollte gerade mein DTU-AHOY von 5.17 auf 5.41 upgraden. Im Release-Paket finden sich die Dateien: 221119_ahoy_0.5.41_esp8266_dec333f.bin 221119_ahoy_0.5.41_esp8266_1m_dec333f.bin welche Datei sollte ich zum flashen verwenden bzw. was ist der Unterschied? Danke für die Unterstützung Herbert
Die Antwort findest hier (1MB Variante für ESP8265), wenns stimmt: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Ist in den HM-600/700/800er wirklich eine andere Hardware verbaut oder kann die Leistungsbegrenzung theoretisch auch über das Maximum gebracht werden? Also der HM-600 auf zB. HM-700 umparametriert werden? Frage für einen Freund... ;)
Die HW wird schon wohl sehr ähnlich sein, aber auch fix hinterlegt der unverändliche Max-Wert. Dies ist auch nötig, da die Leistungskomponenten und Elkos dafür ausgelegt sein müssen inkl. Kühlung. Also selbst wenn du öffnest und umprogrammieren könntest würdest niemandem einen Gefallen erweisen, allenfalls der Wirtschaft durch baldigen Neukauf.
@Ulrich K. Erstmal vielen Dank für deine Erläuterungen: Alles läuft bis jetzt auf einer Synology DS220+ im Docker. Ich habe soweit alles verstanden was du schreibst und mir leuchtet das auch ein. Das Problem ist das Wie. Wo muss ich was drücken, wie installiere ich was und wo muss ich was einstellen. Das ist mein größtes Problem, ich bin kein ITler und Dokus von solchen Dingen sehen für mich teilweise so aus wie für manche das Periodensystem. Ich verstehe manche Dokus schon, weiß aber dann dennoch nicht was ich für meinen Anwendungsfall machen und einstellen muss. Oder anders gesagt nur weil man die Straßenverkehrsordnung versteht kann man ja auch noch kein Auto bedienen. ;-) Bis jetzt habe ich mit jemand anderem auf Synology im Docker den MQTT Broker zum laufen bekommen und auch Verbindung mit meinen Geräten bekommen. Jetut klemmt es an der Übertragung der Daten vom Broker in die Influx-Datenbank, dazu braucht man eine Art Übersetzter namens Telegraf, es klemmt weil uns die Config für Telegraf noch nicht ganz klar ist was wir einstellen müssen. ICh glaube hier sind auch mehrere Leute die das genau so machen oder zumindest hier mal erwähnt hatten. Naja wir probieren uns weiter durch.
Hallo zusammen, ich wollte gerade die Software über AhoyDTU aufspielen. Allerdings kommt jedes mal die folgende Fehlermeldung: Failed to initialize. Try resetting your device or holding the BOOT button while clicking INSTALL. Ein Resett bringt keine Veränderung. Habt ihr einen Tip für mich? Vielen Dank!
Angehängte Dateien:
-
IOBrocker.jpg
310 KB -
Grafana.jpg
250 KB
Alexander H. schrieb: > Jetut klemmt es an der Übertragung der Daten vom Broker in die > Influx-Datenbank, dazu braucht man eine Art Übersetzter namens Telegraf, > es klemmt weil uns die Config für Telegraf noch nicht ganz klar ist was > wir einstellen müssen. Du installierst den MQTT-Adapter im IOBroker. Du installierst den influxdb-Adapter im IOBrocker. Du ordnest dem Datenpunkt welchen du in der Datenbank speichern möchtest die Datenbank zu (Zahnrad). Jetzt kannst du mit einem Dashboard, z.B. Grafana, die Daten aus der Datenbank visualisieren.
Hoschbaer schrieb: > Habt ihr einen Tip für mich? ESP D1-Mini flashen: Beim "PowerUp" des ESP "GND" und "D3" verbinden. HTH
Beitrag #7283958 wurde vom Autor gelöscht.
Angehängte Dateien:
Mein HM 400 wird heute ungewohnt warm ;)
Hatte doch schon jemand hier gepostet, daß negative Temperaturen binär offensichtlich nicht berücksichtig wurden. Irgendwo hab ich das schon mal gelesen, finde aber nichts mehr, vielleicht wurde es wieder gelöscht. Mußt halt vom Wert 6553,5 abziehen oder so ähnlich. Oder du baust es zum Fusionsreaktor um.
:
Bearbeitet durch User
John P. schrieb: > Mein HM 400 wird heute ungewohnt warm ;) Meiner hat : Temperature 6.552,90 °C Habe gestern im Forum bei Github nachgefragt. Das Problem ist bekannt und bereits bearbeitet und erledigt. Siehe #432 und #246 Das Problem wurde am 20. Oktober behoben.... ( https://github.com/tbnobody/OpenDTU/discussions/445 ) Also doch mal neue Software aufspielen. Habe bisher kein Update gemacht, weil mein openDTU seit Monaten friedlich und zuverlässig funktioniert hat. Da gab es keine Grund. Gruss Frank
Frank W. schrieb: > Habe bisher kein Update gemacht, weil mein openDTU seit Monaten > friedlich und zuverlässig funktioniert hat. Da gab es keine Grund. Sehe ich ganz genauso. Da ist es mir auch wurscht welche Temperatur er anzeigt. Offtopic: Was ist besser? Das Solarpanel mit frost überzogen lassen? Oder halb von Frost befreien? Komme nicht komplett ran und das halbe freikratzen zeigte wenig Wirkung.
Naja, sobald die Sonne kommt wird es dort beginnend wo schon schwarz ist sodann schneller wegschmelzen, somit ist es sicher kein Nachteil was halt geht entfernen. Nur glaub ich nicht, daß die Oberflächen sehr entzückt sind wenn du mit dem Schaber anrückst. Gefrorenes würd ich persönlich daher eher lassen und warten. Schnee runterwischen hingegen reinigt sie ja sogar.
Joe G. schrieb: > Du installierst den MQTT-Adapter im IOBroker. > Du installierst den influxdb-Adapter im IOBrocker. > Du ordnest dem Datenpunkt welchen du in der Datenbank speichern möchtest > die Datenbank zu (Zahnrad). > Jetzt kannst du mit einem Dashboard, z.B. Grafana, die Daten aus der > Datenbank visualisieren. Dieser Weg war mir noch nicht bewusst, das das funktioniert. Mein Problem mit iobroker war das ich zwar den MQTT Adapter installieren kann aber der meine Adapter (DTU und Tasmota aufm Stromzähler) nicht findet. Auch auf der DTU steht dann immer MQTT not connected. Habe schon alles versucht, mir wurde im ioborker Forum gesagt das das an meiner Synology und Docker liegt, ich solle doch einen Pi oder irgendso einen Fujitsu Kram nehmen. Auf meine Frage ob mir jemand dabei helfen kann oder es Anleitungen gibt wurde nicht reagiert.
:
Bearbeitet durch User
Zur Überprüfung und Test einer MQTT-Verbindung finde ich den MQTT Explorer [1] sehr hilfreich. Damit kannst du zunächst prinzipiell überprüfen, ob du dich mit dem MQTT Adapter vom IOBrocker verbinden kannst. Wenn das nicht funktioniert, dann bekommt die AhoiDTU auch keine Verbindung. [1] http://mqtt-explorer.com/
@ Alexander H. Kann mir nicht vorstellen, dass es an der Synology und am Docker liegt. Was hast denn in der mqtt Instanz im iobroker eingestellt. Hast den gestartet? Gleiche/richtige Einstellungen im DTU / Tasmota?
Alexander H. schrieb: > meiner Synology > und Docker liegt Hast Du den Port an den Container weitergeleitet?
Hallo Habe hier 2 HM 1200 mit Seriennummer 1168 bekommen würden die auch mit OpenDTU funktionieren? Gruß
Vapo schrieb: > Hallo > Habe hier 2 HM 1200 mit Seriennummer 1168 bekommen würden die auch mit > OpenDTU funktionieren? > > Gruß 100% Versprechen kann ich es natürlich nicht, aber wenn ich eine Seriennummer eingebe die mit 1168 beginnt wird diese zumindest korrekt als HM-1200 identifiziert.
Danke das hört sich doch schonmal gut.
Danke erstmal an alle für das Super Tool. Ahoy funktioniert erstmal einwandfrei. ABER leider habe ich für meinen gebraucht gekauften HM-300 KEINE Seriennummer (nicht mehr lesbar). Gibt es eine Möglichkeit den Inverter trotzdem zu integrieren? Dummynummer, irgendwie auslesen, ..... Merci schon mal VG Christian
Seitdem ich dies Projekt vor ein par Monaten gefunden habe, bin ich begeistert. Inzwischen habe ich auch eine leise Ahnung, was Ihr hier auf die Beine stellt. Aber verstehen tue ich davon noch immer nicht viel. Und jetzt komme ich nicht weiter. Ich habe ein D1 Mini ESP8266-12F v3 Modul von AZ-Delivery mit 221119_ahoy_0.5.41_esp8266_dec333f.bin als Firmware, dass über den USB-Anschluss versorgt wird. Am 3,3V-Ausgang ist ein 100µF Kondensator. Inzwischen wird das Funkmodul durch ein Adapaterboard von AZ-Delivery versorgt, das am 5V-Pin des D1 Mini angeschlossen ist, versorgt. Als Funkmodul habe ich ein nRF24L01+ Modul von AZ-Delivery mit Antenne auf der Platine und ein NRF24L01+PA+LNA Wireless Transceiver RF Transceiver Module with SMA Antenna 2.4G von Hailege. Verbunden werden soll mit einem HM-1200. Der war auch schon mal mit einem geliehenen DTU-Stick von Hoymiles verbunden. Beide Funkmodule habe ich getestet mit unterschiedlichen Ausrichtungen, Entfernungen, Sendeleitungen und vertauschten CE und IRQ. Die Seriennummer ist mehrfach überprüft, unten ersetzt. In allen Varianten bekommen ich dieselben Ausgaben in der Console:
1 | n/a09:12:26 I: [NTP]: 2022-12-27 08:12:26 UTC |
2 | 09:12:36 I: enqueued cmd failed/timeout |
3 | 09:12:36 I: (#0) I: no Payload received! (retransmits: 0) |
4 | 09:12:36 I: resetPayload: id: 0 |
5 | 09:12:36 I: (#0) Requesting Inv SN 1161xxxxxx41 |
6 | 09:12:36 I: (#0) enqueuedCmd: 11 |
7 | 09:12:36 I: (#0) enqueuedCmd: 1 |
8 | 09:12:36 I: (#0) enqueuedCmd: 5 |
9 | 09:12:36 I: (#0) sendTimePacket |
10 | 09:12:36 I: TX 27B Ch40 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b |
11 | 09:12:37 W: while retrieving data: last frame missing: Request Retransmit |
12 | 09:12:37 I: (#0) sendTimePacket |
13 | 09:12:37 I: TX 27B Ch61 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b |
14 | 09:12:39 W: while retrieving data: last frame missing: Request Retransmit |
15 | 09:12:39 I: (#0) sendTimePacket |
16 | 09:12:39 I: TX 27B Ch75 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b |
17 | 09:12:41 W: while retrieving data: last frame missing: Request Retransmit |
18 | 09:12:41 I: (#0) sendTimePacket |
19 | 09:12:41 I: TX 27B Ch3 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b |
20 | 09:12:43 W: while retrieving data: last frame missing: Request Retransmit |
21 | 09:12:43 I: (#0) sendTimePacket |
22 | 09:12:43 I: TX 27B Ch23 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b |
23 | 09:12:46 W: while retrieving data: last frame missing: Request Retransmit |
24 | 09:12:46 I: (#0) sendTimePacket |
25 | 09:12:46 I: TX 27B Ch40 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 f4 00 00 00 00 00 00 00 00 38 b7 9b |
Hab Ihr einen Tip für mich? Besten Dank
Christian schrieb: > Danke erstmal an alle für das Super Tool. > Ahoy funktioniert erstmal einwandfrei. > ABER leider habe ich für meinen gebraucht gekauften HM-300 KEINE > Seriennummer (nicht mehr lesbar). > Gibt es eine Möglichkeit den Inverter trotzdem zu integrieren? > Dummynummer, irgendwie auslesen, ..... > Merci schon mal > VG Christian Moin evlt. mal aufschrauben vielleicht steht dort nochmal irgendwo die Sn!?
LittleHelper schrieb: > Hoschbaer schrieb: >> Habt ihr einen Tip für mich? > > ESP D1-Mini flashen: > Beim "PowerUp" des ESP "GND" und "D3" verbinden. > > HTH Was passiert dann?
Lange gabs von mir hier nichts neues. Heute habe ich ein neues Release veröffentlicht: https://ahoydtu.de/web_install/ https://github.com/lumapu/ahoy/releases/tag/ahoy_v0.5.66 Ich hoffe, dass mit dieser Version das neue Jahr einen guten Auftakt haben wird. Vielen Dank an alle, die hier mitgewirkt haben! Echt enorm was sich in den letzten 9 Monaten entwickelt hat. Nächstes Jahr können wir hoffentlich endlich mit den HMS und HMT Invertern durchstarten. Viele Grüße und einen guten Rutsch allerseits!
Zur Info falls andere auch suchen, weil keine Werte mehr kommen: Nach dem Update wurde kein WR mehr gefunden (überall gelbe Rufzeichen). Mußte in den Einstellungen erst bei jedem das Häkchen für "Communication Enable" setzen, das es früher gar nicht gab und nun offensichtlich per Default aus war. Das Feld übersieht man auch recht leicht mal, wenn man es nicht erwartet. Ansonst Hut ab vor dem gesamten Projekt und dessen Fortschritt!!! Auch daß es Bestrebungen bezügl. HMT gibt stimmt mich sehr froh. DANKE allen Mitwirkenden!
:
Bearbeitet durch User
Lukas P. schrieb: > Lange gabs von mir hier nichts neues. Heute habe ich ein neues Release > veröffentlicht: Darf ich dir hier einen "Verbesserungsvorschlag" einbringen? Die Reihenfolge der Felder ist m.E. verbesserungswürdig. Damit man die wesentlichen Infos in logischer Reihenfolge zuerst sieht und auch an den selben Positionen bei 'Total' und den einzelnen Wechselrichtern möchte ich folgende Anordnung vorschlagen bzw. diskutieren. (Die Panel-Ansicht finde ich ok wie sie ist ohne Änderungsbesdarf.) Total ---------------- ---------------- ---------------- ---------------- [W] P_AC [var] Q_AC [Wh] YieldDay [kWh] YieldTotal ---------------- ---------------- ---------------- ---------------- [W] P_DC 1. WR ---------------- ---------------- ---------------- ---------------- [W] P_AC [var] Q_AC [Wh] YieldDay [kWh] YieldTotal ---------------- ---------------- ---------------- ---------------- [V] U_AC [A] I_AC [Hz] F_AC [] PF_AC ---------------- ---------------- ---------------- ---------------- [W] P_DC [%] Efficiency [°C] Temp
:
Bearbeitet durch User
Hallo, es ist wohl möglich ein Display OLED 1306 anzuschließen ( Ahoy) Wo ist dokumentiert wie es angeschlossen wird? Frohes Neues!
Danke, ich probiere es in den nächsten Tagen mal aus…
Danke, ich probiere es in den nächsten Tagen mal aus…
Hallo, erstmal habe ich heute fast den ganzen Nachmittag verbracht, diesen Thread zu lesen - das liest sich wie ein Krimi. Ich mag solche Forschungen und die Teamarbeit - ein großes Danke und "Chapeau" an alle Beteiligten. Da ich gestern zum ersten Mal eher zufällig von Ahoy-DTU gehört habe, habe ich kurzentschlossen einen Beutel 24L01+-Module bestellt, ESPs habe ich noch haufenweise. Ein Hoymiles-WR hängt seit 1. November in der Nähe meiner 3 Module und trägt seinen Teil dazu bei, dass die Energiekosten hier etwas gedämpft werden. Eine geregelte Speicherung (Ziel der Nulleinspeisung) folgt noch im Frühjahr. Um dann HEUTE zu lesen, dass die HMS und HMT-Serie auf einer ganz anderen Frequenz funkt und dazu wohl wenig bekannt ist. Ich bin Elektroniker, kein Programmierer. Habe einen HMT-1800 im Einsatz, der aber bisher eher vergeblich auf irgendwelche Funksignale hört. Toll, zu hören, dass es hier ebenfalls in der Planung ist. Somit denke ich, dass ich beim Testen und Debuggen helfen kann, die Werte des WR hätte ich nämlich auch gern im ioBroker, der bei mir im Keller auf einem Raspi Daten sammelt, als gäbe es kein Morgen mehr. Daumen hoch und auf ein tolles 2023 mit neuen Erkenntnissen! Stefan
bloedkolben schrieb: > Toll, zu hören, dass es hier ebenfalls in der Planung ist. > Somit denke ich, dass ich beim Testen und Debuggen helfen kann ... und deshalb habe ich mich auch mal angemeldet. Grüße vom Stefan!
bloedkolben schrieb: > Toll, zu hören, dass es hier ebenfalls in der Planung ist. Habe ich was verpasst? Gibt es Neuigkeiten zu HMS / HMT? WO findet sich hierzu was?
Meine Steckersolaranlage steht inzwischen auf einem Gartenhaus weit ausserhalb der Reichweite des häuslichen WLANs. Deshalb würde ich gerne die von der Ahoy-DTU gewonnenen Daten abzapfen und über einen LoRaWan-Node weiterschicken. Damit würde sich in etwa folgendes Szenario ergeben: Ahoy-DTU dauerhaft im Access-Point only Modus, der auch den Reset überlebt. Das war bei ersten Versuchen (damals noch ohne Solaranlage) nicht der Fall. Nach dem Reset war die DTU nicht mehr als AP erreichbar. Eventuell die Möglichkeit, das WLAN z.B. über einen Schalter komplett auszuschalten, nachdem die DTU in WLAN-Reichweite mit dem Laptop o.ä. konfiguriert ist. Weitergabe der Daten über eine der gängigen Schnittstellen nach aussen. Bevor die DTU in den Nachtmodus geht, eine Mitteilung an den Client schicken, dass er ebenfalls schlafen kann. Aufwachen kann er von selbst über einen Interrupt, wenn bei entsprechender Helligkeit die nächsten Daten kommen. Alternativ könnte der Client auch einfach schlafen gehen, wenn eine Zeit lang keine Daten mehr kommen. Die Daten, die über die Schnittstelle kommen, würde ich auf dem Client sammeln, das wichtige selektieren und in Paketen weiterschicken (wegen der begrenzten Datenmenge im LoRaWan). Holen der aktuellen Zeit vom Client (ist dort über die LoRa-Daten verfügbar). Jetzt die Frage: Gibt es ausser mir noch mehr Leute mit ähnlichen Anforderungen (fehlendes WLAN)? Ich hatte vor einiger Zeit schon mal eine ähnliche Anfrage gestellt, aber keine Reaktionen erhalten. Ich würde mich freuen, dieses Mal eine Antwort zu bekommen, selbst wenn sie negativ ist. Viele Grüße, Uli
@Ulrich K. (ulrich65) Welches nRF Funkmodul hast du verbaut? Das mit der externen Antenne hat eine enorme Reichweite!
@Gerri Das Modul mit der externen Antenne. Die Entfernung von der Solaranlage zum Haus ist etwa 100 Meter mit einigen Hindernissen dazwischen. Die Möglichkeit hatte ich bis jetzt noch nicht auf dem Schirm. Muss ich ausprobieren. Gruß, Uli
Einfach mal die Ahoy-DTU ins Haus stellen (Fenster Richtig der Anlage)und evtl. mit der Sendeleistung etwas Testen!
Werde ich ausprobieren. Melde mich dann wieder. Gruß, Uli
@Gerri Klappt einwandfrei. Danke, Du hast mir den Tag (Woche, Monat) gerettet! Ich hatte ganz weit vorne im Thread über die geringe Reichweite der RF24 Module gelesen und hatte die einfache Möglichkeit mir der direkten Kommunikation abgehakt. Statt es einfach mal auszuprobieren. Na ja, wieder was gelernt. Die Module mit Antenne haben wirklich eine enorme Reichweite. Ich habe selbst mit der niedrigsten Leistung durch das Fenster (ich sitze in der warmen Wohnung) eine sichere Verbindung. Umso erstaunlicher, da das Haus südlich des Inventers steht, der hinter einem der Panels hängt und hinter dem Inverter nichts ist, was reflektieren könnte. Noch danke und viele Grüße, Uli
Uli schrieb: > ... In allen Varianten > bekommen ich dieselben Ausgaben in der Console: >
1 | n/a09:12:26 I: [NTP]: 2022-12-27 08:12:26 UTC |
2 | > 09:12:36 I: enqueued cmd failed/timeout |
3 | > 09:12:36 I: (#0) I: no Payload received! (retransmits: 0) |
4 | > 09:12:36 I: resetPayload: id: 0 |
5 | > 09:12:36 I: (#0) Requesting Inv SN 1161xxxxxx41 |
6 | > 09:12:36 I: (#0) enqueuedCmd: 11 |
7 | > 09:12:36 I: (#0) enqueuedCmd: 1 |
8 | > 09:12:36 I: (#0) enqueuedCmd: 5 |
9 | > 09:12:36 I: (#0) sendTimePacket |
10 | > 09:12:36 I: TX 27B Ch40 | 15 72 21 60 41 84 48 89 28 80 0b 00 63 aa a8 |
11 | > f4 00 00 00 00 00 00 00 00 38 b7 9b |
12 | > 09:12:37 W: while retrieving data: last frame missing: Request |
13 | > Retransmit |
14 | > ... |
Hallo, wer kann mir einen Hinweis geben, ob ich da was falsch zusammengebaut/konfiguriert habe oder ob ich weitere Funkmodule ausprobieren muss? Besten Dank Uli
@Uli Welches nRF-Modul, ESP, Firmwareversion, Pins für CE und IRQ verwendest du?
@Gerri, besten Dank D1 Mini ESP8266-12F v3 von AZ-Delivery 3,3V-Ausgang mit 100µF Kondensator Firmware 221230_ahoy_0.5.66_esp8266_f8fe044.bin u. 221119_ahoy_0.5.41_esp8266_dec333f.bin getestet nRF24L01+ Modul von AZ-Delivery mit Antenne auf der Platine und NRF24L01+PA+LNA Wireless Transceiver RF Transceiver Module with SMA Antenna 2.4G von Hailege beide mit/ohne Adapaterboard von AZ-Delivery getestet CS an D8 (GPIO15) CE an D4 (GPIO2) IRQ an D3 (GPIO0) CE und IRQ in den Settings auch getauscht. Viele Grüße Ul
:
Bearbeitet durch User
Vorzugsweise solltest CE und IRQ auf einen anderen Pin legen (Begründungen in früheren Beiträgen), wird dein Problem aber auch nicht lösen. CS an D8 (GPIO15) CE an D1 (GPIO5) IRQ an D2 (GPIO4)
@Grisu Besten Dank, das probiere ich nachher aus.
Habe CE an D1 (GPIO5) und IRQ an D2 (GPIO4) getestet. Die Fehler bestehen, wie von Grisu erwartet, weiterhin. Es macht auch keinen Unterschied, wenn ich in den Settings für CE/IRQ D1/D2 vertausche oder bei D4/D3 belasse. Viele Grüße Uli
@Uli H. Stimmt die Seriennummer vom Inverter?
@Uli H. evtl. die FW nochmal neu flashen über USB mit Erase, oder mal einen anderen ESP nehmen!
@Gerri besten Dank, mit neu flashen und CE an D1 (GPIO5) IRQ an D2 (GPIO4) läuft es jetzt mit meinem ganze Sortiment an Funkmodulen. Bin begeistert. Jetzt geht der Spaß weiter. Vielen Dank!
Hallo zusammen, wollte mal kurz auf ein "Phänomän" hinweisen: In benutze "noch" die Version 5.15 mit EPS6288 stabil seit 4 Monaten. Gestern konnte keine Verbindung mehr zum HM-1500 auf gebaut werden(not available and not producing). Alle versuche mit reboot von HM und ESP blieben erfolglos. Dann stellte ich fest das MTTQ auch nicht verbunden war und musste feststellen das der IOBroker auf PI "defekt" war, zuerst habe ich da gar keinen Zusammenhang gesehen, aber nach (langer) Reperatur mit diversen Scripten usw. lief der IOBroker wieder und es konnte wieder auf den HM connectet werden! nur mal so als Hinweis! Grüsse Andreas
Ja. Bekannter alter bug ( sollte in diner aktuellen version weg sein ).
Moin, weiß eigentlich schon jemand, auf welcher Frequenz die HMS- und HMT-Serie funkt...? Da er ja nicht ständig ohne Anforderung einer DTU funkt, wird ja auch nicht mit einem SA die Frequenz direkt an der Antenne zu detektieren sein, denke ich. "SUB 1G" ist ja weit gefaßt - aus meiner Sicht bleiben ja nur 433 und 868 MHz als "freie" Frequenzen ohne Anmeldung und Gebühren.
HMS wird hier behandelt, da andere Übertragungstechnik: Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless" Und dort Bitte weiterdiskutieren.
HMT wird hier behandelt, da andere Übertragungstechnik: Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless" Und dort Bitte weiterdiskutieren.
Oh, sorry. Dann beobachte ich den mal.
Ulrich K. schrieb: > Ich warte im Moment auf Solarpanels und einen Hoymiles HM-600 > Wechselrichter und möchte die Ahoy DTU verwenden. Mein Problem ist, daß > ich am Aufstellort der Panels kein WLAN habe (Gartenhausdach mit einigen > Hindernissen). Vielleicht sollte man das für zukünftige Versionen noch mit LoRaWan kombinieren :-)
Kurze Frage: Kann man der Wert der Gesamtleistung (YieldTotal) per Ahoy zurücksetzen? Hintergrund: Ich habe den Umrichter gebraucht gekauft und würde gerne die von MIR erzeugte Gesamtleistung anzeigen. Merci MfG Christian
Nicht möglich, ob durch FW des WR ausgeschlossen oder nur noch nichts gefunden wurde dies zu ändern weiß ich nicht, vermute aber eher ersteres. Wäre ja so als würdest den km-Zähler am Auto ändern.
Dachte ich mir schon. Muss ich mir halt im iobroker was basteln.
Gibt es eigentlich die Möglichkeit das Netzprofil (Wechselrichter Parametrisierung, zb. Cos, phi=1, etc.) einzustellen ?
Dzt. nicht (hab zumindest noch nichts dazu gefunden) - geht nur mit der HM-DTU-pro ein TOR-Profil hochzuladen.
:
Bearbeitet durch User
Hallo, ich habe den halben Tag damit verbracht diesen Thread zu lesen und es fällt mir nur eines dazu ein: RESPEKT(!) und DANKE(!) für die geniale Demonstration was möglich ist, wenn Menschen zusammenarbeiten. Eine Frage hätte ich aber: Lässt sich für die Hoymiles HMnnn Serie darüber die abgegebene Leistung limitieren?
ist es unter Ahoy/OpenDTU möglich Befehle an den WR zu senden ohne MQTT
und Smart home?
Ich möchte eigentlich nur ein paar Zeilen Code hinzufügen
if(dc_Spannung < 24V){
switch_off;
}
if(dc_Spannung > 26V){
switch_on;
}
nur leider fehlt mir das verständnis an welcher stelle ich welche Klasse
verwenden kann, um die DC Spannung des Wechselrichters zu bekommen und
entsprechend ein und aus zu Schalten.
Dafür gibt es doch die jeweilige API Bei OpenDTU siehe https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md Bei ahoy siehe http://[ip ahoy device]/api Nun lässt sich z.B. bei ahoy per cURL ein JSON abschicken. cURL ist auch in verschiedenen Skriptsprachen verfügbar, z.B. PHP Für die Konsole (Linux/Windows) würde das so aussehen: Abfrage Daten (auch im Browser) http://[ip ahoy device]/api/live Abschalten: curl -i -X POST -H "Content-Type: application/json" -d '{"id":"0","cmd":"power","val":"0"}' http://[ip ahoy device]/api/ctrl Einschalten: curl -i -X POST -H "Content-Type: application/json" -d '{"id":"0","cmd":"power","val":"1"}' http://[ip ahoy device]/api/ctrl
Daniel schrieb: > Dafür gibt es doch die jeweilige API > > Bei OpenDTU siehe > https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md > > Bei ahoy siehe > http://[ip ahoy device]/api > > Nun lässt sich z.B. bei ahoy per cURL ein JSON abschicken. cURL ist auch > in verschiedenen Skriptsprachen verfügbar, z.B. PHP > > Für die Konsole (Linux/Windows) würde das so aussehen: > > Abfrage Daten (auch im Browser) > http://[ip ahoy device]/api/live > > Abschalten: > > curl -i -X POST -H "Content-Type: application/json" -d > '{"id":"0","cmd":"power","val":"0"}' http://[ip ahoy device]/api/ctrl > > > Einschalten: > > curl -i -X POST -H "Content-Type: application/json" -d > '{"id":"0","cmd":"power","val":"1"}' http://[ip ahoy device]/api/ctrl Mir fehlt absolut das verständnis wie das gehen soll? für OpenDTU konnte ich das schon umsetzen. Muss es aber nocht testen: auto inv = Hoymiles.getInverterByPos(0); float dcvoltage = inv->Statistics()->getChannelFieldValue(CH0, FLD_UDC); if(dcvoltage < 24.0){ //switch off inv->sendPowerControlRequest(Hoymiles.getRadio(), false); } else if(dcvoltage > 25.0){ // switch on inv->sendPowerControlRequest(Hoymiles.getRadio(), true); }
Beitrag #7336831 wurde von einem Moderator gelöscht.
Vielen Dank für das Projekt. Ich habe mich genau wegen OpenDTU für einen Hoymiles 300 Wechselrichter entschieden. Esp32 und NRF24L01+ gekauft, eingespielt und alles geht auf Anhieb. :) Aus Interesse, gibt es irgendwo eine Protokollübersicht? Ich habe den Thread aufgrund der Länge jetzt nur Quergelesen. Demnach scheinen die letzten 5 Byte der Seriennummer einfach die Empfangsadresse zu sein, aber verschlüsselt ist da nichts? Sprich, jeder der nach eingerichtete Hoymiles Wechselrichter lauscht und auf dieses Weise die Seriennummer erfährt kann sie danach auch auslesen + konfigurieren?
Malte _. schrieb: > Aus Interesse, gibt es irgendwo eine Protokollübersicht? Ich habe den > Thread aufgrund der Länge jetzt nur Quergelesen. Demnach scheinen die > letzten 5 Byte der Seriennummer einfach die Empfangsadresse zu sein, > aber verschlüsselt ist da nichts? Sprich, jeder der nach eingerichtete > Hoymiles Wechselrichter lauscht und auf dieses Weise die Seriennummer > erfährt kann sie danach auch auslesen + konfigurieren? Es gibt irgendwo hier in diesem Thread eine Excel-Datei (RF_communication_protocol-V6.5.xlsx), in der das Protokoll dokumentiert ist. Prinzipiell kann jeder mitlesen bzw. auch Kommandos absetzen, der weiß, wie es geht (und ggf. die "korrekte" DTU-Adresse verwendet, auf die der jeweilige WR grade hört). Verschlüsselt wird da jedenfalls afaik nichts, es kann aber sein, dass man ein "Passwort" einrichten könnte (das aber dann nach meinem VErständnis wohl auch mitgelesen werden könnte...).
Jörg R. schrieb: > Es gibt irgendwo hier in diesem Thread eine Excel-Datei > (RF_communication_protocol-V6.5.xlsx), in der das Protokoll dokumentiert > ist. Prinzipiell kann jeder mitlesen bzw. auch Kommandos absetzen, der > weiß, wie es geht Danke :) Damit hab ich es gefunden: https://github.com/dad401/ahoy/blob/main/doc/hoymiles-format-description.txt und Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Auch wenn die fehlende Verschlüsselung sicher die Analyse stark vereinfacht hat, wenn ich in der Doku einen "Download Firmware" Befehl sehe, ist der Wechselrichter potentiell offen wie ein Scheunentor, wenn da nicht noch eine Signierung und Überprüfung erfolgt.
Malte _. schrieb: > ist der Wechselrichter potentiell offen wie ein Scheunentor Prinzipiell schon - aber eine Scheune, aus der nix geklaut werden kann, braucht man doch auch nicht abschließen? Mit welchem Ziel sollte dir jemand den Wechselrichter "hacken" und tot programmieren? So ein Aufwand nur um dich zu ärgern? Da kann er dir auch die Autoreifen plattstechen...
Willi schrieb: > Die teilweise vorgeschlagene Verdrahtung ESP zum NRF finde ich > problematisch. > Problem ist bei D3/GPIO0: > Wenn der bei Boot des ESP auf low ist, geht der ESP in den > Programmiermodus. > Problem ist bei D4/GPIO2: > Beim D1mini hängt die blaue LED daran. > Die Pin sollte man meiden > > Meine Empfehlung (so verdrahten und im Webinterface konfigurieren): > NRF = ESP > CS = D8 (GPIO15) > CE = D1 (GPIO5) > IRQ = D2 (GPIO4) Hi, ist das beschriebene Problem noch akut? Fände es schade, wenn man den I2C-Bus an D1/D2 dafür opfern müsste (wegen Display). Eine flackernde blaue LED am Chip-Select würde mich persönlich nicht stören. Evtl. könnte man den D3 mit einem Single-Gate Analog-Schalter FET / Dirty-Trick, was auch immer entkoppeln, dass erst wenn die Firmware läuft, die IRQ-Signale vom nRF durchgereicht werden? Hat jemand Erfahrungen dazu?
Angehängte Dateien:
-
ESP_DTU_Platine1.jpg
68 KB -
ESP_DTU_Platine2.jpg
130 KB -
ESP_DTU_Platine3.jpg
140 KB
Hallo zusammen, aufgrund vieler Nachfragen habe ich wieder einige Platinen machen lassen. Wemos D1 mini und NRF24 zusammen auf einer Platine mit der Verdrahtung wie im GitHub beschrieben. RF24_CS_PIN D8 GPIO 15 RF24_CE_PIN D4 GPIO 2 RF24_IRQ_PIN D3 GPIO 0 Läuft bei mir mit dieser Verdrahtung schon seit Monaten störungsfrei. Ich habe noch einige Platinen übrig und würde die für 2€ pro Stück abgeben. Einfach in ebay-Kleinanzeigen nach esp-dtu suchen...
Moin, mal eine kurze Frage, macht der Hoymiles HM-600 irgendwas, wenn nur Wechselspannung und keine Module angeschlossen sind? Kriege meine Module erst nächste Woche und wenn ich AC-Spannung anschließe, bleibe die Status-LED dunkel. Ist das richtig so? Danke. Gruß kami
Das gehört so, der WR wird aus den Solarzellen versorgt.
Moin, ist die PIN-Belegung "Standart" und passt die Platine auch für NRF24L01+ ohne externe Antenne ? Grüsse
Für die AhoyDTU gibt es jetzt eine Integration ins Projekt "Solaranzeige" . Siehe https://solaranzeige.de/phpBB3/viewtopic.php?t=3387
Hallo, kann mir vielleicht jemand bei meinem Problem weiterhelfen? Ich habe einen Wemos D1 Mini Pro (ESP8266EX) und einen NRF24L01+ PLUS. Ich habe das aktuelle bin geflashed, habe aber immer das Problem, dass sich der Access Point nicht aufbaut. Ich habe schon mehrere Wemos D1 getestet und verschiedene Versionen geflasht. Wenn ich mich per Putty(seriell) verbinde, sehe ich die Meldung, dass ich mich mit dem AP verbinden soll. Allerdings hatte ich schon 2 Mal das Phänomen, dass nach ein paar Stunden der AP doch auftauchte, allerdings konnte ich mich nur einmal kurz damit verbinden, jedoch ohne Eingaben zu speichern (danach war er wieder weg). Was mache ich falsch? Danke
Hi, seit heute Morgen ist mein HM_600 offline. Fehlermeldung: 144 Grid: Grid overfrequency Die Frequenz steht im openDTU bei 51.74 Hz Die Anlage lässt sich auch nicht mehr starten bzw ohne Erfolg. Kann ich an den Einstellungen im HM 600 etwas ändern? Wo liegen die Grenzen bei der Frequenz? Würde mich über eine Hilfestellung freuen. Grüße Robert
Robert B. schrieb: > Fehlermeldung: 144 Grid: Grid overfrequency > Die Frequenz steht im openDTU bei 51.74 Hz Woher kommen diese 51,74 Hz? Bist Du am Verbundnetz angeschlossen? Falls ja ist wohl der WR defekt, es gab die letzten Tage in Europa keine so hohen Frequenzen Ab 50,2 Hz müssen Umrichter beginnen abzuregeln, ab 51,5 Hz müssen sie komplett aus sein
außer dein Netzbetreiber macht gerade irgendwelche Wartungsarbeiten und hat deine Region vom eigentlichen Netz abgetrennt um sie per Notstromaggregat zu versorgen. In so einem Fall wird nämlich die Netzfrequenz in diesem Teil künstlich angehoben, damit genau alle PV Wechselrichter abschalten und nicht "gegen" das Notstromaggregat einzuspeisen versuchen. Quelle: https://www.goingelectric.de/forum/viewtopic.php?p=996735#p996735
Danke für die Aufschlussreichen Antworten. Seit 13:45 ist die Frequenz wieder bei 50.02Hz. Ich werde weiter beobachten und die Frequenz nun mitloggen. Grüße Robert
Martin P. schrieb: > außer dein Netzbetreiber macht gerade irgendwelche Wartungsarbeiten und > hat deine Region vom eigentlichen Netz abgetrennt um sie per > Notstromaggregat zu versorgen. Das kann natürlich auch sein - informieren die Netzbetreiber bei so was nicht? Kann ja wohl kaum sein das hier dann zig Leute auf Fehlersuche gehen?
Warum sollten sie, solange alles in der zugesagten Bandbreite liegt? Funktioniert ja alles wie geplant und vorgesehen inkl. Abschaltung deiner WR. Zig Leute hängen nicht täglich am WR um die Daten auszulesen. Das installiert man und erfreut sich, wenn keine Sonne scheint kommt ja auch nichts. Anfangs ist man vielleicht interessiert und schaut öfter, aber wozu später noch, da genügt eine quartalsweise oder monatliche Kontrolle. Ändern kann man an den Werten eh nix, also nur zum Zeitvertreib? Ja, auch solche gibts mehr als genug, da die Menschheit zuviel Freizeit hat und unterbeschäftigt ist.
:
Bearbeitet durch User
Grisu schrieb: > Ändern kann man an den Werten eh nix, also nur zum Zeitvertreib? > Ja, auch solche gibts mehr als genug, da die Menschheit zuviel Freizeit > hat und unterbeschäftigt ist. Solche Beiträge bringen keinen weiter, haben nichts mit dem Thema zutun!
Hallo und erstmal vielen Dank für die viele Arbeit, die in die Umsetzung dieses Projektes investiert wurde. Da es vielleicht mehrere Minderbemittelte wie mich gibt, möchte ich hier einmal meinen Lösungsansatz vorstellen, wie ich die Daten der DTU auswerte, in der Hoffnung, dass es jemanden interessiert. Meistens stolpert man über Broker und MQTT, wenn es um die Datenauswertung geht, ich bin aber sehr froh über die RESTAPI, die ich in openHAB auswerte. Unter DietPi läuft das fast auf jeder Plattform. Man braucht das HTTP Binding, um eine Verbindung mit der DTU aufzubauen und die JSONPath Transformation, um die Datei "lesen" zu können. Danach kann man ein Thing anlegen mit der HTTP-Adresse http://192.xxx.xxx.xxx/api/live Man legt jeweils einen Channel mit einer Status-Transformation an, z.B. JSONPATH:$.inverter[0].ch[0][5] für die Gesamterzeugung. https://jsonpathfinder.com/ hilft bei beim Lesen der API. Nochmal herzlichen Dank für die Entwicklungsarbeit. Ich bin absolut begeistert, wie viel Funktionalität sich auf dem bisschen Hardware unterbringen lässt. Grüße, Mathias
Hallo zusammen! Ich hab nach ein paar Monaten problemlosen Betrieb das Phänomen, dass ich keine Daten mehr von den Wechselrichtern erhalte. Ich hab nichts an der Konfiguration geändert. Es war von heute auf morgen weg. Fehleranalyse … Wechselrichter blinken alle grün, also alles in Betrieb. Einmal Stromkosten gemacht und ein paar Minuten gewartet brachte keine Änderung. AhoyDTU …. Ausgesteckt und neu gestartet nach ein paar Minuten. Brachte nichts. Update auf 0.5.66 brachte auch keine Änderung. Ich hatte damals noch eine Kombi gelötet, die funktioniert hat, auch keine Daten damit empfangen. Hat noch wer einen Tipp, was ich machen könnte? 0.5.66 sagt nur „ Inverter #0: Paar1 (v0) is not yet available“ und „ Inverter #1: Paar2 (v10010) is not yet available“ . Die Versionsnummer bekommt er vom zweiten Wechselrichter anscheinend… Danke, Lg Christian
Hallo Christian, versuche mal bitte auch eine Werkseinstellung durchzuführen. Trage dann alle relevanten Daten neu ein. Eventuell noch alle Verbindungen zwischen ESP und NRF prüfen. Nicht das sich was gelockert hat.
Gibt es eine Möglichkeit die WLAN-Leistung des Moduls zu begrenzen? Dieses ist bei mir direkt neben dem Router plaziert, von dem es auch die 5V über USB bekommt, und wie mir scheint diesen etwas überfordert durch die hohe Signalstärke.
Ich habe in meiner Ahoy meinen HM-1500 auf dem Dach und den vom Nachbarn auf dem seinen Carport. Nun bin ich mit meinem Logging endlich weitergekommen. Die beiden IT-Studenten die ich bezahlen wollte haben es ja nicht hinbekommen. Zwar hab ichs auch auf meiner Synology NAS in Docker geschafft aber bin jetzt doch auf einen Rasberry Pi gewechselt. Kurzum: MQTT Server als normalen Dienst auf dem Pi installiert. Stromzähler Ausleseeinheit und Ahoy haben Verbindung. Node-Red in Docker installiert und dort immer 3 Knoten pro Messwert zu nutzen- MQTT In --> Function Node für Tags --> Influx Out InfluxDB 2.6.1 genutzt um die Daten zu speichern auch in Docker Grafana für das Dashboard auch in Docker. Wobei ich sagen muss die Kombination InfluxDB 2.x und Grafana ist nicht unbedingt hilfreich da im Netz sehr viele Leute (noch) Influx 1.x nutzen und hier eine ganz andere Abfragesprache genutzt wird. Da ich das ganze nicht so verstehe war ich auf viel Hilfe in Foren und rumprobieren angewiesen, da solche Dokumentationen zu den Sachen für mich oft ein Buch mit 7 Siegeln ist. Ich lerne eher an Beispielen und den Ergebnisse und verusche das dann auf meine Bedürfnisse anzupassen, was natürlich nicht immer passt und klappt. Aber egal, mei Dashboard ist nun fast fertig und es funktonioniert. Nun ist mir aufgefallen, das die Anlage vom Nachbarn sporadisch aussteigt. Leistung geht auf 0 W, Spannung und Frequenz sind weiterhin vorhanden. Ich habe dann Hoymiles kontaktiert und die meinten ich soll mal auf die Spannung schauen bei 250V schaltet der WR ab. Und siehe da, bei meinem Nachbarn geht es kurzzeitig auch mal auf 253,5 V hoch. Was sogar außerhalb der Norm ist (230V +/- 10% sind die Norm --> 207 - 253 V). Nun die Frage, die Spannung die der WR misst ist das die die vom Netz kommt und er passt sich der dann an oder ist das die Spannung die er erzeugt? Hoymiles hat angeboten wenn ich eine DTU hätte können die aus der Ferne dort das Limit etwas höher setzten nach dem Sie sich das 7 Tage lang angesehen hätten. Nun mein Nachbar und ich hängen nicht an der selben Zuleitung. Ich bekomme es aus der Straße über ein Erdkabel und er von der Straße über uns per Überlandleitung. Er hat zudem vom Zählerschrank bis zur Anlage locker 30-40 m mit 4 oder 5 Klemmstellen und unterschiedlichen Querschnitten (manchmal auch nur 1,5 mm²). Dazu hat er auch noch einen Durchlauferhitzer 22kW für Warmwasser. Nunja ich habe nun eine orginal DTU (USB Version gekauft, war im Angebot und ohne MwSt). auch um meinen WR mal zu updaten falls nötig. Da ich eh noch weitere 6 Stück hier liegen habe für eine Anlagenerweiterung kann das ja nicht schaden. Ich wollte euch nur auch mal an solchen Sachen teilhaben lassen. Das 0.6.0 Update habe ich auch schon gemacht, sieht gut aus. :-)
Da speisen wohl schon einige ein in der Umgebung und die Spannung läuft ihnen im Netz davon. Daher dann die Abschaltung der WR, was ja auch so sein muß. Bessere bzw. auch stärkere Zuleitung könnte da schon abhilfe schaffen, damit der Spannungsabfall geringer wird wenn sie einspeist. Miß halt mal ganz vorn am Hauptschalter die Spannung, ob die dort spürbar niedriger ist als am Punkt wo der WR einspeist.
Alexander H. schrieb: > Nun die Frage, die Spannung die der WR misst ist das die die vom Netz > kommt und er passt sich der dann an oder ist das die Spannung die er > erzeugt? beides ist das Gleiche, an einem Messpunkt können ja keine 2 verschiedene Spannungen sein?
Strom (Einspeisung) mal Widerstand (Leitung) ergibt Spannung(sabfall). Mit anderen Worten, beim Einspeisen ist die Spannung direkt am WR gemessen sehr wohl etwas höher als vor dem Zähler gemessen. Und normalerweise ist die Spannung an der Steckdose dann eine Spur unter der am Eingang (Zähler), beim Einspeisen ist das naturgemäß aber umgekehrt. Von daher kann es dann schon um einzelne Volt gehen, daß er abregelt, obwohl vor dem Zähler noch etwas Spielraum zum tolerierten Maximum wäre.
:
Bearbeitet durch User
da müsste er aber Hausintern schon sehr dünne Leitungen haben Ich würde dann mal messen - Steckdose unbelastet - Steckdose mit einem Heizlüfter auf Stufe 1 - ca. 1000W
Alexander H. schrieb: > Er hat zudem vom Zählerschrank bis zur Anlage > locker 30-40 m mit 4 oder 5 Klemmstellen und unterschiedlichen > Querschnitten (manchmal auch nur 1,5 mm²). Schrieb er ja.
Die letzten Tage konnte ich sehen sobald die Sonne gut rauskommt geht es direkt Richtung 250 V bei ihm. Je näher es an 12 Uhr und volle Einstrahlung kommt je häufiger und länger gehts über die 250V. Wenn ich mir das mal so genau ansehe dann ist er das 4. Haus auf der Überlandleitung nachdem es per Mast (hoffentlich aus dem Boden) kam. Alle die mit dran hängen haben auch PV Anlagen auf dem Dach > 6 kwP (schätzungsweise). Dann noch die ganzen alten und dünnen Leitungen sowohl im Haus als auch bis zur Solaranlage mit den gnazen Klemmstellen. Für dauerhafte Abhilfe wäre wohl eine neue eigene Leitung nötig, auch wenn das heißt von der Übergabe im obersten Stock, runter in den Keller und dann noch die 30 m bis zum Carpot incl. Bach Überquerrung. Es kommt vermutlich alles zusammen in dem Fall. Ich weiß ja auch nicht was für Überlandkabel mal da so früher genommen hat (Material und Querschnitt) wurde alles in den 70ern gebaut. Gut das an der anderen Straße am Erdkabel hänge, wenn auch ich der letzte in der Reihe bin. Aber bei mir hat glaub ich kein Haus was mit dran hängt zumindest meine Straße, PV auf dem Dach. Danke für eure Hilfe.
:
Bearbeitet durch User
Das erklärt doch alles, wenn hinter ihm ein paar massiv einspeisen, daß die Spannung dann steigt, bis die eine oder andere PV dann eben abdrehen muß, wenns zu hoch geht.
Das ist ja auch der Sinn der Regelung, 260 Volt im Netz will niemand. Da kann er nur den Heizstab z.B im Warmwasser zuschalten, so dass seine PV-Anlage dann auch wieder liefert ;-)
:
Bearbeitet durch User
Ich hab jetzt die original DTU von Hoymiles (war im Angebot) noch warte ich auf den Account. Dann wollen die Techniker von Hoymiles sich das mal anschauen und ggf. das Limit etwas hochsetzen hatten sie mir geschrieben. 253V sind ja erlaubt. ;-)
Den kann dir auch jeder erstellen der bereits einen Installer-Account hat.
Hast auch mal die anderen Phasen gemessen? Evtl. hilft ja ein Wechsel?
Heinz R. schrieb: > Hast auch mal die anderen Phasen gemessen? Evtl. hilft ja ein Wechsel? Ne gemessen noch nicht. Das Umklemmen wäre aber nicht ganz so einfach, weil im Hauptkasten (der kleiner kaum sein kann 70er halt) nur 6 Sicherungen sind und das ganze Gedöns hängt an der für den Keller. Würde bedeuten man müsste da komplett was tauschen, aber um ehrlich zu sein geht ich an son altes Zeug nicht dran. Einfach nicht anfassen. Der Besitzer weiß selber das das alles nicht optimal ist und ärgert sich warum er nicht schon vor Jahren alles einmal neu gemacht hat. Grisu schrieb: > Den kann dir auch jeder erstellen der bereits einen > Installer-Account > hat. Gut zu wissen, hast du einen?
Reicht doch von der Hauptsicherung zum FI oder LS 2 Phasen zu tauschen. Alle Sicherungen rausschrauben damit das Haus stromlos ist und wie gesagt 2 Drähte tauschen. Wenn kein Drehstrommotor (Wärmepumpe oder Poolpumpe etwa) im Haus vorhanden ist stellt das doch kein Problem dar, falls doch darst das ohne den ebenfalls geräteseitig irgendwelche 2 Phasen zu tauschen nicht machen, sonst sind sie hinüber mit Linksdrehfeld. Sollte natürlich nur ein Elektriker machen oder jemand der dazu befähigt ist, aber keine große Sache wo allenfalls der Anfahrtsweg das teuerste ist. Ich hab auch zw. den Phasen 1-2V differenz, wenn ihr die PV zufällig grad an der stärksten angeschlossen habt könnte das sehr wohl bereits eine Lösung sein. PS: Ja hab einen (PN).
:
Bearbeitet durch User
Alexander H. schrieb: > Heinz R. schrieb: > Gut zu wissen, hast du einen? Liest du deine Mails nicht bzw. landen sie im Spam oder hast eine falsche bzw. nicht mehr gültige hier hinterlegt?
Grisu schrieb: > Alexander H. schrieb: >> Heinz R. schrieb: > >> Gut zu wissen, hast du einen? > > Liest du deine Mails nicht bzw. landen sie im Spam oder hast eine > falsche bzw. nicht mehr gültige hier hinterlegt? Ja doch ich hab jeden Tag auch geschaut ob was gekommen ist aber ist nichts angekommen. Ich habe meine Emailadresse eben geändert und die Änderung wurde auch bestätigt. Wäre nett wenn du mir nochmal die Nachricht schickst wenn möglich. Vielen Dank
Ginge einfacher wennst mir eine PN mit deiner (gültigen) Mailadr. geschickt hättest. ;-) PN werden hier nicht verwaltet oder gar gespeichert sondern nur direkt auf die hinterlegte Mailadr. versandt - Ende.
Erst mal vielen Dank an alle für die beeindruckende Zusammenarbeit. Der Thread ist ja nun sehr lang geworden, komme mit dem einlesen gar nicht nach. Deshalb die Frage, vielleicht kann das jemand aus dem Stegreif beurteilen: Ist der Wechselrichter auch für die Lösung geeignet? https://www.reichelt.de/microinverter-hoymiles-hm-600-ho-hm-600-p331488.html?search=HO+HM-600
Ist doch genau das worums hier seit Anbeginn geht, also ja was sonst.
Lutz S. schrieb: > Erst mal vielen Dank an alle für die beeindruckende > Zusammenarbeit. > > Der Thread ist ja nun sehr lang geworden, komme mit dem einlesen gar > nicht nach. > > Deshalb die Frage, vielleicht kann das jemand aus dem Stegreif > beurteilen: > > Ist der Wechselrichter auch für die Lösung geeignet? > > https://www.reichelt.de/microinverter-hoymiles-hm-600-ho-hm-600-p331488.html?search=HO+HM-600 passt soweit, kannst ja hier kaufen ist nochmal ein ticken günstiger: https://www.offgridtec.com/hoymiles-hm-600-microinverter-modulwechselrichter.html Oder manchmal bei Ebay noch einen 10er oder 20er günstiger, bei Neuware vom Händler.
Grisu schrieb: > Ist doch genau das worums hier seit Anbeginn geht, also ja was sonst. Danke für die schnelle Antwort. Ich meinte irgendwo gelesen zu haben, dass manche Geräte die Schnittstelle nicht haben, aber vielleicht verwechsle ich da auch was.
Lutz S. schrieb: > Grisu schrieb: >> Ist doch genau das worums hier seit Anbeginn geht, also ja was sonst. > > Danke für die schnelle Antwort. Ich meinte irgendwo gelesen zu haben, > dass manche Geräte die Schnittstelle nicht haben, aber vielleicht > verwechsle ich da auch was. Alle Wechselrichter von Hoymiles der Serie HM-XXXX können via Ahoy DTU oder Open DTU verbunden werden. Die MI-XXXX Serie geht nur bedingt bis gar nicht und die HMS-XXXX Serie (jetzt ganz neu) geht auch (noch) nicht da hier eine ganz andere Frequenz/Schnittstelle genutzt wird.
An dieser Stelle vielen Dank für dieses supertolle Projekt. Bei mir funktioniert alles bestens! hm800 iobroker liebe Grüße
Möchte mich auch bei allen bedanken die mitgewirkt haben. Habe das jetzt hier zunächst fliegend zusammengesteckt - funktionierte sofort, auch mit Display. Funkkontakt zum Inverter HM-600 auch mit kleiner Antenne auf der Platine des Moduls durch mehrere Wände über ca. 20 Meter Entfernung völlig problemlos. Auch die Einbindung mit MQTT ist reibungslos, Daten werden auch im Home Assistant sofort dargestellt. Runde Sache, vielen Dank noch mal. Falls jemand noch 2 leere Platinen abzugeben hat (für ESP32 Modul 38-polig, kleines Funkmodul und 1,3" OLED Display 1306), bitte PN oder im Markt einstellen.
:
Bearbeitet durch User
Gibt es eine Grafik, in welche Richtung die Leiterplattenantenne des NRF24L01 die beste Sendecharakteristik hat? Ich habe bei 5m Abstand mit zwei Betonwänden keinen Empfang mehr, mit einer Betonwand dazwischen ist ok. Kann man herausfinden, ob die Pakete vom NRF oder vom Wechselrichter nicht ankommen? Ansonsten ist das ein super Projekt. Klappt alles einwandfrei und ist verständlich, top!
Das wird nichts werden und ist auch unerheblich welche Seite nichts hört. Antenne oder Empfänger (bzw. vice versa) verbessern hilft gleichermaßen. Ich meine damit egal welches Teil, senden und empfangen ja beide. Versuch mal das hier, könnte helfen, muß es doch glatt selbst ausprobieren: https://www.instructables.com/Enhanced-NRF24L01/
:
Bearbeitet durch User
Gibt es bei der Version 0.6.9 (ESP32) Probleme mit dem WLAN? Ich habe mir gerade eine Schaltung aufgebaut, um ein E-Paper anzuschließen. Das aktuelle heimische WLAN-Netz wird nur sehr sporadisch erreicht. (Ein ESP8266 läuft parallel in 2 Metern aber stabil). Wenn das heimische Netz nicht erreicht wird, funktioniert der Default Access-Point unter der http://192.168.4.1 auch sofort. Ich habe den Eindruck, dass der ESP32 zu kurz einen Verbindungsaufbau versucht.
Hallo zusammen!!Geniales Projekt. Habe einen HM 1200-4 Module ca 375 W .Ahoy-DTU mit esp32/nrf24l01+ und Display läuft super und lässt kaum einen Wunsch offen. Gibt es die Möglichkeit die Yield Total auf 0 zu resetten.Ich wollte nicht irgendetwas, wie zB Factory Reset bei System ausprobieren, da sonst alles super läuft.Ich habe einiges gelesen (nicht alles) aber nichts darüber gefunden. Was mir aufgefallen ist, dass viele mit der Leistungsbegrenzung Schwierigkeiten haben.Wenn man auf senden drückt (bei Serial/Controle) kommt es bei mir öfter vor, dass es nicht gesendet wird und ich sah dann irgendwann, dass die Software direkt nach dem Button-Click eine Fehlermeldung bringt. Ich hab das oft übersehen und mich gewundert, dass sich im WR nichts verändert hat.
Hast schon die aktuelle 0.6.9 drauf? Falls ja empfehle ich dir mal genau nachzusehen bei den Paneleinstellungen (Korrektur), andernfalls mach ein Update.
Kann man eigentlich von einer 5er version direkt auf 6.9 updaten, oder muss man zuerst auf 6.0 gehen und vor allem, was kann schiefgehen, mein Teil läuft bestens.Ich würde nur gerne den Gesamtertrag des WR (Hm 1200) auf Null stellen.
Was sollte schief gehen? Kann natürlich immer was sein, aber allenfalls hattest du ihn schon einmal komplett jungfräulich programmiert, wirst es also noch ein 2. Mal hinbekommen.
Hallo Zusammen,
ich habe schon länger AHOY als Nulleinspeisung am laufen, funktioniert
soweit :-)
Die Reaktionszeit auf eine neue Leistung ist mit dem letzten Update
nochmals schneller geworden.
Jetzt versuche ich mich an einer weiteren Optimierung: Ich möchte das
Daly-BMS-Projekt von Softwarecrash mit einbauen.
Damit kann ich dann auch das BMS auslesen. Ich spare mir somit ein ESP
für das BMS und die ganze Schleife über Wlan usw. wird einfacher.
Dann habe ich ein ESP32 mit AHOY, DALY-BMS, und dem Programm für die
Nulleinspeisung.
Hat das schon jemand versucht?
Bei mir klappts soweit, das BMS wird an der zweiten seriellen
Schnittstelle am ESP32 eingelesen und ich bekomme die Werte.
Ich schaffs allerdings nicht, die Werte in meiner eigenen Funktion über
MQTT rauszuschicken.
Da sind meine C++ Kenntnisse zu lasch. Templates, Klassen usw. kenn ich
mich zu wenig aus.
Ich habe testweise versucht: (die 25.2 Volt ist dann natürlich die
ausgelesene Spannung vom BMS)
PubMqtt::publish ("BMS/Spannung","25.5V");
myApp.mMqtt.publish("BMS/Spannung","25.5V");
mClient.publish("BMS/Spannung", 0, 0,"25.5V");
Tut alles nicht...
Die MQTT Botschaften werden aus der pubMqtt.h verschickt.
Wie komme ich da an die Funktionen ran?
Habe in meiner Funktion eine Zeiger auf die "app" drin. Bräuchte aber
irgendwas mit
template<class HMSYSTEM>
class PubMqtt {
public:
PubMqtt() {
Kann mich jemand erleuchten?
viele Grüße,
Stefan
Hallo Stefan ..bei deiner Frage kann ich dir leider nicht weiterhelfen ..ich hab Ahoy auf esp8266 für 2x HM800 laufen und möchte die Ausgangsleistung eines HM800 dynamisch reduzieren z.Zt versuch ich durch trennen eines PV Moduls über SSR eine Einspeisung über 800W zu verhindern würd dies aber gerne quasi stufenlos (bei wechselnder Ertragsleistung der PV) machen ..ich heize mein Whirlpool mit reduzierter Heizleistung (über einen mit PWM steuerbaren SSR) z. Zt. noch mit manueller Regelung – sollte bald über IO Broker im Vergleich zur saldierten Netzleistung funktionieren (bin in Blockly noch nicht so fit) ..wie machst du die Nulleinspeisung und wie schnell/langsam ist die Reaktionszeit ..hast du Info’s für mich ? Gruß aus Wien – fossi1
Grisu schrieb: > Versuch mal das hier, könnte helfen, muß es doch glatt selbst > ausprobieren: > https://www.instructables.com/Enhanced-NRF24L01/ Hab's gemacht, hat keine fünf Minuten gedauert und funktioniert super. Wie viel besser die Antennenleistung ist, kann ich schlecht quantifizieren, aber Wechselrichter und NRF kommunizieren jetzt problemlos durch mehrere Betonwände. Danke für den Link!
Danke für die Rückmeldung! Dann werd ich mich auch mal ins Vergnügen stürzen und den kleinen Umbau wagen, vielleicht sehe ich dann den ungünstig gelegenen entfernten WR auch.
:
Bearbeitet durch User
Hallo zusammen. ich habe ein Problem mit dem Befehl zum reduzieren der WR (HM 800) Leistung. Ich habe die Beschreibung im Git gefunden jedoch habe ich keinen Erfolg bzw. ich weis nicht wie genau ich es machen muss. SW ist Ahoy 0.6.9 auf ESP32 Versucht habe ich es mit: http://192.168.178.133/ctrl/0/limit 50 http://192.168.178.133/api/ctrl/0/limit_nonpersistent_relative 50 http://192.168.178.133 /api/ctrl/0/limit 50 Kan mir da jemand helfen wie ich es genau machen muss. Noch habe ich eine rückwertslaufenden Zähler der vermutlich heuer getauscht wird. Dafür möchte ich vorbereitet sein. Danke im Voraus
Hat jemand vielleicht bei der Analyse des Protokolls solch einen Wechselrichter mal zerlegt? Und könnte bei der folgenden Frage weiterhelfen? Beitrag "Unteschied HM-600 <-> HM-800" Vielleicht gibt auch das Protokoll etwas her, ob man einen HM-600 später mal auf HM-800 aufrüsten könnte? Gibt es eigentlich Protokoll-Erfahrung/Aufzeichnungen wie ein Firmware-Update eines Hoymiles Mikrowechselrichters abläuft (wenn dies überhaupt außerhalb der Fertigung möglich ist)?
Mit der Hoymiles DTU kann man schon ein Update einspielen, soviel ich gesehen hab (sofern es je eines gäbe). Ich denk du wirst ihn schrotten wenn du aus einem 600 softwaretechnisch einen 800er machst, da dieser sicher thermisch und von der Bauteildimensionierung (Gleichrichter, Elkos, MOSFET/Triacs oder was eben verbaut ist) nicht ident bestückt sein wird. Du darfst dir auch einen HM-1500 mit 4 Panelen nehmen, wenn du ihn auf 800 oder 600W (was halt bei euch erlaubt ist) begrenzt. Oswald S. schrieb: > ich habe ein Problem mit dem Befehl zum reduzieren der WR (HM 800) > Leistung. > Ich habe die Beschreibung im Git gefunden jedoch habe ich keinen Erfolg > bzw. ich weis nicht wie genau ich es machen muss. > SW ist Ahoy 0.6.9 auf ESP32 > Versucht habe ich es mit: > http://192.168.178.133/ctrl/0/limit 50 > http://192.168.178.133/api/ctrl/0/limit_nonpersistent_relative 50 > http://192.168.178.133 /api/ctrl/0/limit 50 > > Kan mir da jemand helfen wie ich es genau machen muss. > Noch habe ich eine rückwertslaufenden Zähler der vermutlich heuer > getauscht wird. Dafür möchte ich vorbereitet sein. > > Danke im Voraus Warum willst du ihn überhaupt begrenzen? Wozu der Aufwand, dann schenkst halt dem Netz was du nicht selbst verbrauchst, kann dir doch völlig egal sein und der Umwelt hilfts jedenfalls auch wenn du nichts dafür bekommst. Ich hatte nur mit Einstellung einer fixen W-Zahl Erfolg, mit % gings ab einer Version nicht mehr (mit der aktuellen 6.9 nicht getestet), aber mit Watt wunderbar, also beim HM-800 sind das für 50% laut Adam Riese 400W. Kannst fix einstellen, dann überlebts auch einen Neustart des WR oder temporär. Eingetragen hab ich es im GUI.
:
Bearbeitet durch User
Grisu schrieb: > Warum willst du ihn überhaupt begrenzen? > Wozu der Aufwand, dann schenkst halt dem Netz was du nicht selbst > verbrauchst, kann dir doch völlig egal sein und der Umwelt hilfts > jedenfalls auch wenn du nichts dafür bekommst. Ich verstehe Deine Antwort nicht ganz. Ich möchte den WR begrenzen weil ich nach einem möglichen Zählertausch eine Nachteinspeisung realisieren möchte. Die zuviel produzierte Leistung möchte ich im Akku speichern und nachts einspeisen. Das man es über UI machen kann weis ich aber beantwortet halt nicht meine Frage wie ich den Befehl senden muss.
Oswald S. schrieb: > Das man es über UI machen kann weis ich aber beantwortet halt nicht > meine Frage wie ich den Befehl senden muss. Per MQTT oder RestAPI. Siehe: https://github.com/lumapu/ahoy/blob/main/User_Manual.md
Oswald S. schrieb: > Ich verstehe Deine Antwort nicht ganz. > Ich möchte den WR begrenzen weil ich nach einem möglichen Zählertausch > eine Nachteinspeisung realisieren möchte. Die zuviel produzierte > Leistung möchte ich im Akku speichern und nachts einspeisen. > Das man es über UI machen kann weis ich aber beantwortet halt nicht > meine Frage wie ich den Befehl senden muss. Das erklärt aber nicht die Frage, warum du ihn begrenzen wolltest. Was zuviel ist und der Akku nicht speichern kann für deine Nachteinspeisung geht halt zurück ins Netz. Wem hilft es was wenn er dann ruhend gelegt wird, nur weil du es nicht mehr speichern kannst? Die Regelung sollte doch dann an ganz anderer Stelle erfolgen und nicht am WR, der begrenzt wird.
:
Bearbeitet durch User
Grisu schrieb: > Das erklärt aber nicht die Frage, warum du ihn begrenzen wolltest. vielleicht will er den WR nachts einfach am Akku anschließen? Dann macht die Reduzierung evtl. Sinn Es gibt allerdings die HM-300 aktuell für 75€ incl. Versand - da würde ich mir das Gekasper mit Umschaltung WR zwischen Akku und PV nicht antun
Martin M. schrieb: > Gibt es eigentlich Protokoll-Erfahrung/Aufzeichnungen > wie ein Firmware-Update eines Hoymiles Mikrowechselrichters abläuft > (wenn dies überhaupt außerhalb der Fertigung möglich ist)? Ich hab schon ein paar mal das "Netzprofil" an einem WR mit der original DTU neuaufgespielt bzw. ein leicht geändertes (der Hinweis was ich wie zu ändern habe kam von Hoymiles Support selber) Netzprofil aufgespielt. Ansonsten habe ich dort keine andere Möglichkeit gesehen bis jetzt irgendwas zu aktualisieren. Ganz andere Frage: Wie viele WRs kann ich eigentlich an eine Ahoy DTU hängen?
Ich habe soeben zwei Paneele samt einem HM-800 auf meinem Dach montiert, angesteckt und auf Anhieb Verbindung mit meinem AhoyDTU herstellen können. : Deshalb möchte ich mich herzlich bei allen bedanken, die etwas zu diesem tollen Projekt beigetragen haben! LG Christian
:
Bearbeitet durch User
Brauche Hilfe beim Kompilieren des Projekts Guten Morgen Ich möchte mir eine eigene Version mit einer kleinen Ergänzung kompilieren, da ich gerne die eingelesenen Daten direkt in eine MySQL-DB schicken möchte. Da ich für einen MQTT-Broker keine weitere Verwendung hätte möchte ich den Umweg über MQTT gerne vermeiden. Ich bin zwar Programmierer, allerdings seit Jahrzehnten verwende ich nur Pascal und kenne C/C++ nur aus der Schule und von kleinen Arduinoprojekten. Nun habe ich mir Visual Studio Code heruntergeladen, PlatformIO installiert und alle Vorschläge, die mir dabei gemacht wurden befolgt (Gitclient installieren etc.) Dann hab ich mir die ZIP-Datei von Github heruntergeladen, den Ordner src als Projekt geöffnet und auf "Build" gedrückt. (Bevor ich irgendwelche Änderungen vorrnehme wollte ich natürlich erst sehen ob es überhaupt funktioniert). Naja. Was soll ich sagen? Abgesehen davon, dass ich von der langen Kompilierdauer doch überrascht wurde, verlief der Versuch durchwegs negativ. Erstens bin ich erschlagen vom Funktionsumfang der IDE und ich bekam nur eine recht lange Auflistung (siehe Anhang) der Fehler und Meldungen und steige da derzeit überhaupt nicht durch. Könnte mir jemand die Entscheidenden Hinweise geben, damit ich weiß wie ich weiterkomme? LG Christian
Christian B. schrieb: > Dann hab ich mir die ZIP-Datei von Github heruntergeladen, den Ordner > src als Projekt geöffnet und auf "Build" gedrückt. (Bevor ich > irgendwelche Änderungen vorrnehme wollte ich natürlich erst sehen ob es > überhaupt funktioniert). Du musst das aus Github in Visual Studio Code clonen, nicht das zip herunterladen und entpacken. https://github.com/tbnobody/OpenDTU#flashing-and-starting-up 'Clone this repository (you really have to clone it, don't just download the ZIP file.' Hatte das vorher auch noch nie gemacht, habe es aber zum compilieren bekommen und zum Test mal eine geänderte Datei für das Display (aus dem Forum) mit einkompiliert, die die Temperatur des Wechselrichters mit ausgibt. Die so erstellte Firmware funktionierte sofort.
:
Bearbeitet durch User
Danke sehr für den Hinweis. Habe es jetzt mit clonen versucht (zuvor die Dateien des Downloads gelöscht, damit nicht irgendwo Artefakte zu Problemen führen können), ging auch soweit alles gut. Nur beim Build kommt wieder nix rum ... :( Die Ausgabe hab ich wieder angehängt. Unter dem Reiter "Problems" steht z.B. dass in der Datei "DebugPrintMacros.h" millis() nicht deklariert sei. ??? Weiß wer Rat PS: Ich möchte auch keineswegs den Thread hier kapern und wechsle wenn gewünscht gern in einen Neuen. Ich dachte nur, dass ich hier am ehesten Gehör finden werde ...
@Christian B Lutz S. schrieb: > Du musst das aus Github in Visual Studio Code clonen, nicht das zip > herunterladen und entpacken. > > https://github.com/tbnobody/OpenDTU#flashing-and-starting-up Hallo Christian B, ich habe keine Ahnung von "C" und hab noch nie was mit platformio entwickelt. Ich habe das nur aus Interesse eben mal gemacht, wie beschrieben. Gültige "COM..."-Ports eingetragen wie beschrieben: "...in Adjust the COM port in the file "platformio_override.ini" for your USB-to-serial-converter. It occurs twice: upload_port monitor_port ..." Und nach ca. 3 Min warten hatte ich 3 Stk. _.bin Dateien im .pio Verzeichnis. Nur 1 Warning aus einer Fremd-LIB wegen einer data Variable. Also ... funktioniert auch für Leute, die wenig Ahnung haben - wie ich. Geflasht und auf Funktion geprüft habe ich die allerdings nicht. Danke an Alle die weitergemacht haben, nachdem ich mich nach dem Zerfleddern des Protokolls mangels Zeit ausgeklinken musste.
Angehängte Dateien:
-
Zwischenablage01.jpg
60 KB
Da hier die Experten sind, folgendes Problem: Ein HM-300 wird nachts zur Unterstützung eines Victron-WR genutzt, um vom Akku von Sonnenuntergang bis Akku leer oder SOnnenaufgang ständig 300W einzuspeisen Geschaltet wird er AC-seitig mittels Smart-Steckdose Jetzt zeigt mir Ahoy ständig Lasten zwischen 30 und 50W an obwohl er AC-seitig getrennt ist Mit Zangenamperemeter gemessen - es fließt kein Strom 30W müsste man auch als Wärme am WR spüren - er bleibt kalt Auch yield day ist falsch - mit 300W kann er kaum an einem Tag 21,4 kWh eingespeist haben Hat das sonst noch jemand festgestellt? Es ist die aktuelle Ahoy-Version - ob es bei der älteren auch so war - es ist mir zumindest nicht aufgefallen
:
Bearbeitet durch User
Herbert K. schrieb: > Also ... funktioniert auch für Leute, die wenig Ahnung haben - wie ich. Inzwischen zeigt die IDE nurmehr "Initializing PlatformIO Core" an wenn ich auf den Außerirdischen klicke und dann passiert gar nichts mehr ... (Daran hat auch eine De- und Neuinstallation von VSC nichts geändert) Anscheinend gibts halt doch Welche die noch weniger Ahnung haben ... :(
Christian B. schrieb: > Inzwischen zeigt die IDE nurmehr "Initializing PlatformIO Core" an wenn > ich auf den Außerirdischen klicke und dann passiert gar nichts mehr ... > (Daran hat auch eine De- und Neuinstallation von VSC nichts geändert) Hast du mal die Command Line Version probiert? Wenn du kein Linux hast, gegebenenfalls WSL installieren. Das sollte zumindest fürs erfolgreiche Compilieren reichen.
Malte _. schrieb: > Hast du mal die Command Line Version probiert? Von VSC oder PlatformIO? Ich muss zugeben, dass ich noch nicht wirklich durchschaue, was die tatsächliche Funktion der beiden Komponenten ist. VSC ist nur der Editor? Mit PlatformIO wurde automatisch C/C++ installiert. Ich dachte das wäre der Compiler. Es steht aber dabei "Intellisense, Code browsing ... " "Code browsing" würde ich eher dem Editor zuordnen. Entweder bin ich nur von meiner Pascal IDE so verwöhnt oder ich werde wirklich langsam zu alt. Mir kommt das alles (völlig unnötig) kompliziert vor. Linux verwende ich (aus ähnlichen Gründen) nicht, außer auf Raspberries, da bleibt mir nichts anderes übrig.
Christian B. schrieb: > Von VSC oder PlatformIO? PlatformIO. So habe ich das gebaut. Ich gebe zu dass das ganze eine ziemliche Toolchain Download Orgie ist. Aber wenigstens funktionierte es alles wie beschrieben.
Ich bin jetzt wieder einen Schritt weiter gekommen. Auf einem anderen Computer bleibt PIO zumindest nicht beim initialisieren hängen. Also wieder von Github geklont und diesmal statt das Häkchen für "Build" zu klicken, einen ESP32 angeschlossen und den Pfeil für "Upload". Mir ja schon zuvor bei Build aufgefallen, dass der ganze Vorgang mehrmals durchlaufen wurde. Nun ist mir auch klar warum: Es wird für alle möglichen Controller (ESP8266, ESP32 ...) eine Version kompiliert. Und auch zum Controller hochgeladen. Er scheint auch zu funktionieren (zumindest spannt er sofort das Default-Wlan auf). Heißt das ich müsste irgendwie erst auswählen welchen Controller ich angeschlossen habe, um nur die richtige (und auch funktionierende) Version zu kompilieren? Wie und wo? Denn nach (mehreren) erfolgreich hochgeladenen Versionen kommen dann noch die Fehlerhaften ...
:
Bearbeitet durch User
Angehängte Dateien:
-
Errors.png
6,5 KB
Das Bild zeigt auch welche funktionieren, und welche nicht ...
In VSC gibt es unten eine Statuszeile, dort steht bei mir im vorletzten
Eintrag rechts 'Switch Platform IO Project Environment' im Tooltip. Beim
anklicken lassen sich verschiedene Optionen fpr diverse boards
auswählen, steht bei mir allerdings auf 'Default (OpenDTU)'
Beim Build macht er exakt nur eine Variante:
'generic SUCCESS 00:00:14.305'
In der Datei platformio.ini steht folgendes:
[platformio]
default_envs = generic
extra_configs =
platformio_override.ini
und weiter unten
[env:generic]
board = esp32dev
build_flags = ${env.build_flags}
-DHOYMILES_PIN_MISO=19
-DHOYMILES_PIN_MOSI=23
-DHOYMILES_PIN_SCLK=18
-DHOYMILES_PIN_IRQ=16
-DHOYMILES_PIN_CE=4
-DHOYMILES_PIN_CS=5
Ich weiss aber nicht, ob das dafür die entscheidende Einstellung ist.
:
Bearbeitet durch User
Lutz S. schrieb: > In VSC gibt es unten eine Statuszeile, dort steht bei mir im vorletzten > Eintrag rechts 'Switch Platform IO Project Environment' Hallo Lutz Deiner ersten Antwort entnehme ich (inzwischen) dass Du OpenDTU verwendest und nicht AhoyDTU. Aber Dein Tipp war dennoch goldrichtig. Switch Platform IO Project Environment" fuktioniert auch bei AhoyDTU genau wie gewünscht. Nur ist dummerweise ESP32 bei den nicht funktionierenden Kompilaten. Aber ich werde mir jetzt einfach OpenDTU ansehen, da dieses (zumindest im Bezug auf "Out of the Box Kompilierbarkeit") anscheinend besser für mich geeignet ist. Danke Dir Christian
Der Thread ist inzwischen unerträglich lang geworden und das Laden dauert eine Ewigkeit :-( Es würde mich freuen wenn einer der hier anwesenden Experten auf einer Webseite eine für Halbschlaue wie mich nachvollziehbare Anleitung schreiben könnte, die angibt wie man den Hoymiles mit preisgünstigen Komponenten auslesen und konfigurieren kann. Vielen Dank! H. Trickler
H. T. schrieb: > Es würde mich freuen wenn einer der hier anwesenden Experten auf einer > Webseite eine für Halbschlaue wie mich nachvollziehbare Anleitung > schreiben könnte, die angibt wie man den Hoymiles mit preisgünstigen > Komponenten auslesen und konfigurieren kann. https://ahoydtu.de
Hi, kann mir bitte mal jemand in einfachen Worten erklären wie man Werte auf der Linux-Console zeitnah aus der DTU rauskriegt. Ein "mosquitto_sub -t DTU/HM600/ch0/active_PowerLimit -C 1" braucht 30 Sekunden! Das kann ja wohl nicht wahr sein. Selbst die die simple P_AC-Abfrage dauert bis zu 10 Sekunden. Da stimmt doch was nicht? Wozu braucht man dazu überhaupt einen Broker? Meine Tasmotas liefern mit einem einfachen http get die Werte in Millisekunden zurück. Geht sowas denn nicht mit AhoyDTU(0.6.9)? Mache ich was falsch?
Micha H. schrieb: > Ein "mosquitto_sub -t DTU/HM600/ch0/active_PowerLimit -C 1" braucht 30 > Sekunden! Das kann ja wohl nicht wahr sein. Selbst die die simple > P_AC-Abfrage dauert bis zu 10 Sekunden. Da stimmt doch was nicht? Wozu > braucht man dazu überhaupt einen Broker? Du hast die Funktion von MQTT noch nicht ganz verstanden Der Broker ist ein Nachrichtenverteiler Der von DIr gezeigte Befehl abonniert das Thema XY auf dem Broker - das heisst immer wenn ein Client, in dem Fall Ahoy oder OpenDTU - einen neuen Wert an den Broker schickt, weiss dieser wer alles das Thema abonniert hat und verteil den Wert an diese Werte werden meist nur bei Änderungen geschickt, oder falls gleich alle 30 oder 60 Sekunden Installiere doch mal an deinem Rechner das Programm MQTT-Client - Du wirst sehen, die DTU sendet gar nicht öfter Was Du suchst ist eher die REST API?
:
Bearbeitet durch User
Heinz R. schrieb: > Micha H. schrieb: > > Du hast die Funktion von MQTT noch nicht ganz verstanden Das habe ich dann gestern auch noch rausgefunden. Also für meinen Zweck völlig ungeeignet, weg damit. > Was Du suchst ist eher die REST API? Ist das so? Ein Beispiel wie man das benutzt? Nur ein Einziges?
Micha H. schrieb: > Das habe ich dann gestern auch noch rausgefunden. Also für meinen Zweck > völlig ungeeignet, weg damit. was hast Du denn genau vor, welche Werte brauchst Du so schnell? Ich nutze z.B. FHEM, dorthin loggt der WR, ich kann dann dort die Werte abholen Aber wenn es direkt per Bash / über die API sein soll: Nutzt Du OpenDTU oder AHOY? Für OpenDTU ist es hier sehr ausführlich beschrieben: https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md AHOY: in der Weboberfläche gibt es den Button REST API, dann siehst die möglichen Befehle Beispiel:http://192.168.178.30/api/record/live Du musst dann die Antwort "zerschneiden", so den gewünschten Wert parsen Sag mal welche Software Du nutzt , welchen Wert du haben willst, dann schaue ich mal
Heinz R. schrieb: > was hast Du denn genau vor, welche Werte brauchst Du so schnell? > > Ich nutze z.B. FHEM, dorthin loggt der WR, ich kann dann dort die Werte > abholen Meine "Home Automation" läuft ausschließlich über ein umfangreiches bash-Skript, angezeigt und gestellt wird über meine Website. Die Schleife im Skript läuft in unter einer Sekunde durch; wenn ich da dutzende Sekunden auf einen einzelnen Wert warten muß hebelt das mein ganzes Konzept aus. > Aber wenn es direkt per Bash / über die API sein soll: > Nutzt Du OpenDTU oder AHOY? Ahoy > Für OpenDTU ist es hier sehr ausführlich beschrieben: > https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md > > AHOY: in der Weboberfläche gibt es den Button REST API, dann siehst die > möglichen Befehle > Beispiel:http://192.168.178.30/api/record/live > > Du musst dann die Antwort "zerschneiden", so den gewünschten Wert parsen Genau darum geht's mir. jq ist ja schön und gut, aber auch dafür finde ich kein funktionierendes Beispiel auf dem ich aufbauen kann. jq nackt schreibt dagegen die ganze Lebensgeschichte des Wechselrichters, wenn ich da noch seitenweise mit cut, grep, awk und Konsorten drauf losgehen muß bringt's auch nichts. > Sag mal welche Software Du nutzt , welchen Wert du haben willst, dann > schaue ich mal Nur das was auf der console so hat. Momentan will ich nur Leistung und Powersetting auslesen. Es wäre sehr nett von Dir wenn Du dafür ein Beispiel bringen könntest.
Hallo Micha, habe etwas ähnliches gebaut. Frage bei mir aber über eine Shelly ab. Im Prinzip das selbe Prozedere. Batch als Anhang. Dürfte selbsterklärend sein. hth
Karl M. W. schrieb: > Batch als Anhang. Dürfte selbsterklärend sein. Danke, ist es. Ich hab mal die relevante Zeile händisch abgesetzt:
1 | $ curl http://192.168.178.52/status | jq -r '.meters[].power' |
2 | % Total % Received % Xferd Average Speed Time Time Time Current |
3 | Dload Upload Total Spent Left Speed |
4 | 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 |
Ich krieg das Haareraufen. Den Endpoint gibt's bei mir nicht. http://192.168.178.52/api zeigt mir das:
1 | {
|
2 | "avail_endpoints": {
|
3 | "system": "http://192.168.178.52/api/system", |
4 | "statistics": "http://192.168.178.52/api/statistics", |
5 | "inverter/list": "http://192.168.178.52/api/inverter/list", |
6 | "index": "http://192.168.178.52/api/index", |
7 | "setup": "http://192.168.178.52/api/setup", |
8 | "live": "http://192.168.178.52/api/live", |
9 | "record/info": "http://192.168.178.52/api/record/info", |
10 | "record/alarm": "http://192.168.178.52/api/record/alarm", |
11 | "record/config": "http://192.168.178.52/api/record/config", |
12 | "record/live": "http://192.168.178.52/api/record/live" |
13 | } |
14 | } |
Was läuft da schief bei mir?
Micha H. schrieb: > Ich krieg das Haareraufen. Den Endpoint gibt's bei mir nicht. > http://192.168.178.52/api zeigt mir das: das ist eine Übersicht über die möglichen Abfragen Ich bastel Dir nachher was in Bash ABer such doch gerne schon mal raus wo die richtigen Werte stehen? Schau DIr alle Links durch - vermutlich der Letzte: http://192.168.178.52/api/record/live
@ Micha H. Erst mal: curl http://192.168.178.52/api/record/live | jq -r '.inverter[]' Dann suchst Du Dir den Wert raus, den Du haben willst. Und dann: curl http://192.168.178.52/api/record/live | jq -r '.inverter[] | .[1] | .val' In [] die entsprechende Ziffer/Zahl eintragen. hth
> ABer such doch gerne schon mal raus wo die richtigen Werte stehen?
Leistung steht hier:
/api/record/live/P_AC
Das Limit steht hier:
/api/record/config/active_PowerLimit
Ich bin völlig am Ende. Ich finde im ganzen Netz auf und ab keine
Erklärung wie man das extrahiert.
P_AC ist der 14. Eintrag in der json_liste (Zählung beginnt bei 0). Also [14]. Das Übrige äquivalent. hth
Karl M. W. schrieb: > P_AC ist der 14. Eintrag in der json_liste (Zählung beginnt bei 0). > Also [14]. Jetzt habe ich es verstanden, es funktioniert. Sowas extrem unübersichtliches ist mir ja noch nie begegnet, das bleibt hoffentlich die einzige Begegnung mit Json. Warum man sowas macht oder haben will ist mir ein Rätsel. Jedenfalls vielen Dank an alle die Geduld mit mir hatten! Ich brauche jetzt erstmal ein Beruhigungsbier. Prosit!
Micha H. schrieb: > Sowas extrem unübersichtliches ist mir ja noch nie begegnet, das bleibt > hoffentlich die einzige Begegnung mit Json. Warum man sowas macht oder > haben will ist mir ein Rätsel. Das Problem ist hier weder Json noch Du, sondern AHOY :-) Ich habe es mir gerade auch noch mal angeschaut - es gibt - zumindest auf die Schnelle gesehen - nicht die Gesamtleistung, sondern nur pro WR einzeln - es macht in meinen Augen auch wenig Sinn in der JSON alle Kanäle gleich zu benennen - sinnvoller wären hier Angaben wie P_AC_Ch0 usw Ich habe hier sowohl Ahoy als auch OpenDTU am laufen - mein Favorit ist - gerade wegen solcher Themen - OpenDTU Auch wenn man siech mal die Issues in Github anschaut - da tauchen von Update zu Update immer wieder neue Probleme auf die eigentlich schon mal funktioniert haben
Heute wurde meine Solaranlage erweitert. Weitere 6kwp mit 4x HM-1500 insgesamt dann jetzt 6x HM 1500. Leider gibt mit der Ahoy Stress. Mit einem WR und MQTT aktiv auf 0.6.9 liefen zwei Stück problemlos. Nun habe ich in jeder Ahoy DTU 3 WRs drin und die Dinger stürzen andauernd ab oder brauchen ewig zum laden. Oft kommt: "Every n/a seconds the values are updated" unter "Live" und dann passiert nichts mehr. Habe auch schon neu geflashed komplett und alles neu eingegeben kein Unterschied. Wie gesagt mit einem WR und MQTT klappt das super. Kondensator ist auch verbaut. Manchmal startet sie auch einfach neu nach dem ich zugreifen wollte. Weiß einer wo das Problem sein könnte?
:
Bearbeitet durch User
Hallo, hatte gerade bei einem Freund eine Weile gesucht, weil die neue OpenDTU keine Verbindung zu seinem Wechselrichter aufnehmen wollte. Hier bei mir funktionierte es problemlos. Seriennummer stimmte, mehrfach überprüft. Nun bin ich wieder zu mir zurück und teste mit meinem WR: ist es richtig, dass das erst funktioniert wenn die Verbindung zum WLAN steht? Solange ich über den AP der DTU zugreife findet er den Wechselrichter nicht, ist er im WLAN klappt es sofort.
:
Bearbeitet durch User
Heinz R. schrieb: > versuch es mal mit OpenDTU? Ich hatte nun auf Github einen Issue eröffnet und nun kam raus es liegt am Speicher. Bei mehr als 4 Wechselrichtern reicht der Speicher des ESP 8266 nicht mehr aus. Ich hab mir jetzt einen ESP 32 bestellt ;-)
Angehängte Dateien:
OpenDTU API JSON Hallo, wofür steht Bitte das "d:" und was haben die Zahlen dahinter für eine Bewandnis? Danke schon einmal im voraus.
Hallo, ich hab seit längerem ein AhoyDTU am laufen, und ich hab eine Frage. Ist es möglich ein Relais direkt zuschalten ab einer gewissen Einspeisung? Also ohne Mqtt, ich möchte dazu kein extra Server aufbauen. Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt Einspeisung. Ich würde es gerne so einfach wie möglich halten. Danke
Sebastian M. schrieb: > Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt > mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt > Einspeisung. > > Ich würde es gerne so einfach wie möglich halten. Die willst dann einfach hart ein- und ausschalten? Da freut sie sich Und unter 400W gibt es nur noch eine kalte Dusche? Du solltest Dein Vorhaben noch mal überlegen Du musst bei PV-Überschuss die Soll-Temperatur hoch ziehen, nicht alles komplett an/aus
Nein ich hab noch ein Wärmetauscher, die Wärmepumpe soll unter 400 Watt nicht laufen. Man bräuchte noch ein 2. Relais um die Heizung aktivieren. Alles andere ist mir zu aufwendig, da der Sicherungskasten zu weit weg ist Smarthome gibt es leider nicht.
Wenn du dir einen freien Ausgang entsprechend reinprogrammierst, der das macht, ist es sicher kein Problem dort ein Relais (ggf. über Transistor) anzuhängen.
:
Bearbeitet durch User
Sebastian M. schrieb: > Alles andere ist mir zu aufwendig, da der Sicherungskasten zu weit weg > ist > Smarthome gibt es leider nicht. Es ist ja nicht so das ein "Home2 "smart" ist oder nicht Auch im sogenannten Smart Home, das sind halt Steuerungen - ,mal mehr, mal weniger In Deinem Fall würde ich aber auf alle Fälle was sinnvolles bauen - nicht die WP hart an- / ausschalten Was ist es denn für eine WP? wie kann die gesteuert werden? Ich würde hier trotzdem MQTT nutzen, wegen mir auch einen öffentlichen Server, kann Dir auch meinen zur Verfügung stellen
Sebastian M. schrieb: > Hallo, > > > ich hab seit längerem ein AhoyDTU am laufen, und ich hab eine Frage. Ist > es möglich ein Relais direkt zuschalten ab einer gewissen Einspeisung? > > Also ohne Mqtt, ich möchte dazu kein extra Server aufbauen. > > Meine Vorstellung, die Brauchwasserwärmepumpe mit dem PV Eingang direkt > mit der DTU verbinden per Relais, was dann geschalten wird ab 400 Watt > Einspeisung. > > Ich würde es gerne so einfach wie möglich halten. > > Danke Moin, ich versuche sowas mit dem IOBroker und Alexa zu realiseren. Man kann eine Alexa Adapter installieren und dann z.b. Steckdosen schalten! Grüsse AD
Andreas schrieb: > ich versuche sowas mit dem IOBroker und Alexa zu realiseren. Man kann > eine Alexa Adapter installieren und dann z.b. Steckdosen schalten! von hinten durch die Brust ins Auge...
Hi, ich bin ganz neu hier und schaffe mir gerade ein kleines Balkonkraftwerk an. Nun stellt sich mir die Frage: Wie hoch ist denn die Wahrscheinlichkeit, dass OpenDTU auch den E-Star Energy HERF-800 unterstützen wird. Scheinbar soll es sich da weitestgehend um Hoymiles-Technik handeln, braucht aber statt einer DTU eine DCU, die wohl technisch nicht kompatibel sind.
Denke die Chance zumindest in absehbarer Zeit geht dann gegen Null (ohne es zu wissen). Warum nimmst dir dann nicht eine Hoymiles?
Angehängte Dateien:
-
grafa5.PNG
27 KB
Moin, ich habe einen ESP32 (Box) mit Opendtu seit ca. März zu laufen. (da hängen 2x WR am Balkonkraftwerk dran) Alles hübsch und Verbindung zum Iobroker. Ich habe die Box momentan im Wohnzimmer zu stehen. Wenn die Box startet ist nur mein AP im Hausflur online. Später dann ab 10:00 schaltet sich ein Repeater im Wohnzimmer dazu. (heute testweise ca. 8:30 manuell betätigt) Die Box wird sich wohl dann irgendwann mit dem Repeater verbinden, weil der Empfang doch stärker ist als vom AP im Hausflur. In dieser Zeit habe ich immer einen kompletten Abbruch von ca. 5min. Ist das normal - startet dann die DTU komplett neu? Danke für die Antwort.
:
Bearbeitet durch User
Den kompatiblen HM-300 gibt es momentan bei Reichelt für 69€, falls jemand Interesse hat. https://www.reichelt.de/microinverter-hoymiles-hm-300-betterie-bc01-buchse-ho-hm-300-bet-p354755.html?&trstct=pos_1&nbc=1
Hallo und vielen Dank für diese wertvolle Arbeit! Habe gerade brandneu das System aus ESP32 und NRF24L01+ Modulen zusammengesteckt und die aktuelle Firmware geflasht. Die Funkstrecke zum HM-600 ist eine Zimmerdecke, alles funktionierte auf Anhieb! Großartig! Die Einbindung der Daten in meine Heimsteueranlage ist dann nur noch eine Frage der Zeit.
Hallo in die Runde! Ich habe mir wieder ein paar Platinen fertigen lassen. Dieses Mal mit Integration für ESP32 (38 Pin) mit NRF24l01+ und E49-900M20S sowie I2C-Display; Ebenfalls geht die "klassische" Bestückung mittels Wemos + NRF (dann ohne Display). https://www.kleinanzeigen.de/s-anzeige/pcb-platine-fuer-ahoydtu-und-opendtu-projekt-auf-esp32-und-esp8266/2490730186-168-9361
CE schrieb: > Ich habe mir wieder ein paar Platinen fertigen lassen. Genau nach so einer suche ich :) Gibt es irgendwo den Schaltplan deiner Platine? Auf den Bildern ist die Beschriftung der Lötbrücken doch etwas schwierig zu erahnen.
Hallo Ahoy-Leute, ich habe mich ein wenig eingelesen und komme aber eher vom Arduino. Der Arduino-Teil scheint weniger entwickelt, bitte hier um Hilfe. Muss ich das NRF24_SendRcv als mehrere Bibliothek definieren ? Sonst kann ich die Befehle wohl nicht nutzen. Und ich sehe den Power-Limit Befehl in Arduino-Projekt umgesetzt. Bitte hier um etwas Hilfe, denn mit GUIs, IO Broker und fertig flashern kann ich nichts anfangen. Ich hätte gern lieber eine einfache Lib für die Arduino IDE, mit einem Befehl die Leistung auszulesen und ein volatile Power-Limit zu setzen. So konnte ich es mit meinen Griedtie Invertern bisher über RS465 tun, aber ich hätte nun gern etwas mit mehr VDE-Normen dran. Gruß, Max
Nun habe ich schon mal raus gefunden das im man nicht im "nano" Verzeichnis nachsehen darf, sondern in der tool/main im NRF24_SendRcv ein .ino findet. Ich denke in diesem Abschnitt bekommt man die Daten des WR:
1 | for (uint8_t i = 0; i < ANZAHL_VALUES; i++) { |
2 | //outChannel(i);
|
3 | Serial.print(getChannelName(i)); Serial.print(':'); Serial.print(VALUES[i]); Serial.println(BLANK); // Schnittstelle bei Arduino |
4 | }
|
Nur eine Umsetzung des Powerlimit sehe ich im Arduino leider nicht. Ich habe nur im github von Stefan123 das hier gesehen: Und hier das Power Limit setzen
1 | 51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B |
2 | ^^------------------------------------------------ MainCmd 0x51 DEVCONTROL_ALL |
3 | ^^^^^^^^--------------------------------------- WR Serial ID |
4 | ^^^^^^^^------------------------------ DTU Serial ID |
5 | ^^--------------------------- SingleFrameID |
6 | ^^------------------------ SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr |
7 | ^^^^---------------------- Control Mode |
8 | ^^^^----------------- PowerPFDev.SetValut 0x012C = 30.0 W |
9 | ^^^^------------ PowerPFDev.Desc 0x0000 oder 0x0001 ? |
10 | ^^^^------- CRC16 / CRC-Modbus über die Daten, excl. Frame ID! |
11 | ^^---- CRC8 |
Gibt es da schon eine Umsetzung am Arduino oder habe ich die im Code überlesen ?
Angehängte Dateien:
-
OpenDTUDisplay_2.jpg
210 KB -
imgBalkon1.jpg
32 KB -
imgChart.jpg
68 KB
Dieser Riesen-Thread hat zu der genialen OpenDTU geführt. Ich habe zwei davon in Einsatz - super. Danke an alle. Ich habe mir für einem M5Stack eine WLAN Anzeige mit Logging und eingebautem MQTT Broker geschrieben. Damit ist ein MQTT Broker im Hausnetz nicht mehr Voraussetzung um im ganzen Haus die Solardaten anzeigen zu können. Wer Interesse hat - https://www.gadgetpool.eu/product_info.php?products_id=104 Ja, ist ein Shop. Aber unten findet sich auch der Download für die Software. Wenn jemand also eine M5Stack und einen OpenDTU hat und eine WLAN Anzeige im Haus haben möchte - einfach ausprobieren. Gruss Frank
Frank W. schrieb: > Wenn jemand also eine M5Stack und einen OpenDTU hat und eine WLAN > Anzeige im Haus haben möchte - einfach ausprobieren. sehr gut gemacht :-) Aber braucht es wirklich einen M5-Stack? Die Teile kosten 100€ Einfach einen ESP32 mit irgendeinem Display?
Heinz R. schrieb: > > Aber braucht es wirklich einen M5-Stack? > Die Teile kosten 100€ > > Einfach einen ESP32 mit irgendeinem Display? Geht sicher. Habe dem M5 Stack genommen wegen WAF, Fertiges Gehäuse mit Taster, Batterie. Bis ich das selbst gebastelt habe wird es wahrscheinlich auch nicht fürchterlich viel billiger. Aber gehen wird das sicher
Die Teile sind halt - meine Meinung - unglaublich hässlich und preislich total überzogen
Heinz R. schrieb: > Frank W. schrieb: > Einfach einen ESP32 mit irgendeinem Display? Der ESP an der Wechselrichter-zu-WLAN-Brücke spuckt doch alles per UART aus. Da kann man sich dranstricken, was man braucht. Bei mir werkelt da noch ein 433MHz Umsetzer dran, der die Daten in den Keller schickt, wo ich sie in eine eigene Steueranlage einspeise. Bisschen Programmierarbeit für Funkprotokoll und Absicherung und 10 Minuten löten, dann war´s fertig.
HMS und HMT Wechselrichter von Hoymiles dürften nun durch Tausch des Funkmoduls ebenfalls unterstützt werden. Gute Nachricht für mich, da ich vorhabe alles umzurüsten.
Hallo, gibt es einen Befehl für den Hoymiles-400/800 mit dem man den MPPT Tracker abschalten kann. Verwende openDTU zu Steuerung. Der HM-400 hängt an einer Batterie, und da ist der MPPT Tracker eher schlecht. Super wenn es das schon gibt. Rolf
Mir ist nichts bekannt Wieviel Volt hat Dein Akku? Bei 48V funktioniert das auch so problemlos
OpenDTU sagt, dass nach der Limitierung auf einen Absolutwert bis zu 4 Minuten vergehen können bis die Anzeige aktualisiert wird. Bei Limitierung auf relativen Wert scheint das nicht so zu sein. Kennt jemand den Grund dafür? Danke
Grisu schrieb: > HMS und HMT Wechselrichter von Hoymiles dürften nun durch Tausch des > Funkmoduls ebenfalls unterstützt werden. > Gute Nachricht für mich, da ich vorhabe alles umzurüsten. Möchtest du uns mitteilen warum die umrüstest. Natürlich sind HMS und HMT gegenüber HM überlegen, gerade wenn es um direkte Erzeugung von 3-Phasen geht. Im Vergleich zur HM Serie aber gerade bei den kleineren (Einphasigen) doch noch relativ teuer und was ich richtig schlecht finde ist diese Busbar die man braucht. Für einen nicht intelligente "Klemme"/"Stecker" find ich den Preis etwas überzogen. Für Installateure die eh 10 oder mehr davon bei einer Fläche einstecken verkabeln müssen sehr ich den Vorteil aber bei Privatpersonen? Oder gibt es noch weitere Vorteile, die ich noch nicht kenne?
Hallo Zusammen, ich habe eine kleine Frage zu unser aller Hobby :-) Mein AHOY läuft seit 5 Monaten super, Version 0.6.9. Seit dem 24.08. kommen bei Bedarf aber keine 600 W mehr aus dem Hoymiles HM-600 raus, nur noch so 280W. Gleichzeitig zeigt die Efficiency nur noch 50% an. Ich betreiben den Wechselrichter direkt an einer 8S Batterie. Wenn ich die Solarzellen direkt anstecke, kommt aus dem CH1 nix raus. Mit Batterie zeigt CH1 aber halbwegs plausible Werte an. Hat jemand schonmal beim Hoymiles ein Chanel abgeschossen? Gibts da eine Sicherung o.ä.? Ein Update auf die neuste SW bringt vermutlich nichts, ich denke es liegt ein HW-Fehler vor. Ich wünsche euch einen sonnigen Tag :-) viele Grüße, stefan
Alexander H. schrieb: > Möchtest du uns mitteilen warum die umrüstest. > > Natürlich sind HMS und HMT gegenüber HM überlegen, gerade wenn es um > direkte Erzeugung von 3-Phasen geht. > > Im Vergleich zur HM Serie aber gerade bei den kleineren (Einphasigen) > doch noch relativ teuer und was ich richtig schlecht finde ist diese > Busbar die man braucht. Für einen nicht intelligente "Klemme"/"Stecker" > find ich den Preis etwas überzogen. > > Für Installateure die eh 10 oder mehr davon bei einer Fläche einstecken > verkabeln müssen sehr ich den Vorteil aber bei Privatpersonen? > > Oder gibt es noch weitere Vorteile, die ich noch nicht kenne? Also Umrüstung von (etwas großspurigem) Balkonkraftwerk auf "richtige" PV. Da ich aber den Vorzug alles selbst zu machen sehr schätze und die Hochspannung am Dach vermeiden möchte installiere ich nun das Maximum 6x HMT-2250. Soviel geht sich grad aus mir 460W-Panelen. Die T-Connetor Stecker waren bei meinem holländischen Anbieter debei (ohne Aufpreis). Also die für mich etscheidenden riesigen Vorteile: 1.) KEINE Hochspannung, keine Sicherheitsabschaltung nötig und null Probleme mit der Feuerwehr. 2.) Wenn was hin ist dann höchstens ein WR der sich wegschaltet oder man leicht abstecken kann. Tausch/Reparatur kann dann irgendwann erfolgen wenns wieder schön ist. Die restlichen 5 produzieren munter weiter. 3.) Verschattung ist kein Thema, da alle Module einzeln angeschlossen werden. Es wird somit immer voll produziert. 4.) Mit openDTU volle Kontrolle über das System, selbst wenn Hoymiles in ein paar Jahren ihre Plattform vielleicht dicht macht (ist ja seit Jahren nur Beta) 5.) Ganz leicht erweiterbar, oder auch reduzierbar 6.) Preis ist denk ich sehr gut und sofort lieferbar. 2,2kWp um unter 500€ (inkl. MWSt bei uns), also 13,5kWp um 3.000€, glaub da gibts teurere Angebote. Nachteil: Man kann nicht einfach die Module miteinander verbinden sondern muß jedes einzeln zum WR verkabeln. Aber in Eigenbau ist das eben eine Zeitfrage, bei einer Firma würde das teuer werden.
Grisu schrieb: > Also Umrüstung von (etwas großspurigem) Balkonkraftwerk auf "richtige" > PV. [...] Danke für deine Ausführungen. Genauso ging es mir auch. Ich kam auch von einem Balkonkraftwerk und habe dann alles selber mit den Modul WRs gebaut. Genau wie aus deinen genannten Gründen. Vieleicht noch ein Nachteil den man bedenken sollte: Einen Akku nachrüsten ist nicht ganz einfach und auch nicht günstig, da man für den Akku dann wieder einen WR braucht. Aber das ist ja ein anderes Thema. Meine Frage war eher halt dahin gehend, warum HMS und nicht HM? Da ist zumindest ein Preisunterschied in Summe dann.?
Alexander H. schrieb: > Meine Frage war eher halt dahin gehend, warum HMS und nicht HM? Da ist > zumindest ein Preisunterschied in Summe dann.? Habe HMT genommen, da 3-phasig (und neuer obendrein) im Gegensatz zu den einphasigen (älteren) HMS und auch HM. Ist halt doch wesentlich einfacher nur ein Starkstromkabel zu brauchen dafür und das Verbindugngssystem zum Anhängen und Serisieren/Erweitern ist ja auch recht einfach. Größere PV genehmigen sie auf einzelnen Phasen ja gar nicht. Da wirds dann mit HMS mühsam, wenn die nicht alle ident produzieren.
Grisu schrieb: > Größere PV genehmigen sie auf einzelnen Phasen ja gar nicht. > Da wirds dann mit HMS mühsam, wenn die nicht alle ident produzieren. Gebe ich dir zu 100% recht. Ich babe bei mir 8x HM unterschiedlicher Größe, 5x den HM-1500. Habe 3 Dachseiten (Ost, Süd, West) teilweise bestückt und jede Dachseite auf eine Phase aufgeteilt. War aber in der Tat etwas mehr Arbeit an Verdrahtung und Kabel.
Ich habe mal was mit Virtuino IOT gebaut, macht aus den HoymilesDTU Json Daten eine Anzeige. Wenn Virtuino noch Curl oä für die Leistungsbegrenzung per Http könnte, ein Traum ;-) https://youtu.be/CwgmrcxG7hQ und https://www.youtube.com/watch?v=n8syQqeMyiw
Hallo, ich habe gerade updatet (von 0.6.9 zu 0.7.36). Soweit alles gut, nur ein Problemchen ist gleich aufgetaucht: Nach jedem Neustart aktualisiert sich die ESP-System-Zeit nicht mehr automatisch, wie das vorher war. Ich muss manuell auf "sync from browser" klicken. Wenn die Systemzeit nicht eingestellt ist, verbindet sich auch MQTT nicht. Und das ist nicht gut. Die Einstellungen sind gleich (NTP-Server) wie in meiner vorheriger ver. 0.6.9 Gibt es da etwas, was ich noch einstellen muss? Sonst muss ich zurück zu v0.6.9 Vielen Dank im Voraus
Funktioniert hier seit Anbeginn (begonnen mit v0.5.16) einwandfrei. Hast du DHCP aktiviert? NTP Einstellung bei mir wie folgt: Server: pool.ntp.org Port: 123 Intervall: 720s (5 Min.)
:
Bearbeitet durch User
die NTP Einstellungen habe ich gleich wie bei dir (sind default). Das war auch in der ver 0.6.9 gleich. DHCP habe ich nicht aktiviert, habe feste IP für Ahoy folgend konfiguriert: IP Address:192.168.178.46 Submask:255.255.255.0 DNS 1: (leer gelassen) DNS 2: (leer gelassen) Gateway:192.168.178.1 So hat das bis jetzt auch problemlos funktioniert (in ver 0.6.9). Ob die feste IP so richtig konfiguriert ist, bin ich nicht ganz sicher :-) Ich habe jetzt aber eine neue Inverter-Einstellung gefunden (in ver 0.7.36), welche in der ver 0.6.9 nicht vorhanden war: "Start without time sync" Wenn ich das erlaube, dann funktioniert der Neustart (reboot) wie vorher. ESP-SystemZeit wird auch gleich automatisch eingestellt und MQTT startet auch. Woher die richtige Zeit genommen wird, keine Ahnung :-)
:
Bearbeitet durch User
Hallo, setze mal den Dns 192.168.178.1 wie dein Gateway - dann sollte es funktionieren Gruß Sven
Sven K. schrieb: > Hallo, > setze mal den Dns 192.168.178.1 wie dein Gateway - dann sollte es > funktionieren > Gruß Sven Interessante Aussage! Wie kommst Du zu der Erkenntnis, dass beim Fragesteller auf dem GW 192.168.178.1 ein DNS-Server oder Forwarder läuft? Bitte bei Unkenntnis keine Tipps geben. Ggf. wäre es zielführender, statt z.B. pool.ntp.org die passende IP-Adresse einzutragen und dann nochmal zu testen.
Ist schon einigermaßen naheliegend, daß sein Modem 192.168.178.1 hat und DNS anbietet fürs Heimnetz. Daher hätte ich auch DHCP vorgeschlagen gehabt, damit auch der DNS mitübergeben wird. Fixe IP-Vergabe vorzugsweise im Modem einstellen für die gewünschten Geräte, dadurch erspart man sich genau diese Probleme den Aufwand, die überall manuell eingeben zu müssen - und erhalten dennoch immer die selbe gewünschte IP.
:
Bearbeitet durch User
Danke, jetzt funktioniert es. Wie von Grisu vorgeschlagen, habe ich in Ahoy-DTU alle Network-Parameter leer gelassen um DHCP zu aktivieren. Die Inverter-Einstellung "Start without time sync" habe ich auch wieder deaktiviert. In meiner FritzBox habe ich für dieses Gerät Fixe IP eingestellt. Jetzt funktioniert nach dem reboot alles normal. Auch wenn meine andere ESP8266 Geräte gut funktionieren, werde ich das wahrscheinlich überall so einstellen ... es ist so wahrscheinlich vernünftiger ... obwohl ich nicht verstehe, warum :-) Ist aber egal, ich muss nicht alles verstehen :-) PS: ja, mein Modem/FritzBox hat 192.168.178.1
:
Bearbeitet durch User
Weil du keinen DNS angegeben hattest, der den Namen des ntp-Servers hätte auflösen können auf eine IP-Adresse. Mit DHCP wird auch der DNS an den Client kundgetan. Vereinfacht halt die ganze Verwaltung wenn man es zentral am Modem einträgt für alle gewünschten Clients und die einfach auf DHCP läßt.
Heinz R. schrieb: > Daniel schrieb: >> Bitte bei Unkenntnis keine Tipps geben > > mit dem linken Bein aufgestanden heute? Das kommt immer auf den Tag und das Bein an. Hast Du auch fachlich etwas beizutragen?
Hallo, was bedeutet dieser Wert in den Inverter Einstellungen?: "Yield Effiency (should be between 0.95 and 0.96)" Ich habe dort 1 (defaul). Werden mit diesem Faktor die Yield-Zähler korrigiert (Yield Day, Yield Total)? Danke.
Ich nehme an das sind einfach nur die Leistungsverluste des WR zw. DC-Einspeisung und AC-Abgabe. Yield ist der Ertrag (erzeugte Energie also).
Ich habe hier 2 x OpenDTU - der eine liest 3 x HMS-2000 aus - der andere 4 x HM-1200 was mich jetzt wundert: Schaue ich abends nach Sonnuntergang ins Webinterface: Bei den HM-1200 steht der Tagesertrag Bei den HMS-2000 ist nach Sonnenuntergang der Tagesertrag auf Null gesetzt die OpenDTU für die HMS-2000 läuft auf Firmware 23.6.28 Die HM-1200- noch Version 23.5.9 Ich hatte mal Ahoy installiert - dort konnte man einstellen wann was resetet wird - bei OpenDTU finde ich hier keine Einstellung? Würde gerne abends beim Geierabendbier sehen was die Anlagen jeweils gebracht haben - was mache ich falsch? Grüße
Ich habe sowohl eine Ahoy als auch eine OpenDTU in Betrieb. Beide zeigen auch nach dem Sonnenuntergang noch den Vortageswert an bis zum Morgen. Ahoy grau unterlegt, OpenDTU ganz normal wie auch untertags. Solltest vielleicht doch einmal überlegen die aktuelle Version zu verwenden. ;-) Und ich habe bei Wechselrichter Senden/Empfangen nur "Daten abrufen" aktiviert und bei NTP die "bürgerliche Dämmerung" eingestellt, sollte aber ohne Bedeutung sein.
Grisu schrieb: > Beide zeigen auch nach dem Sonnenuntergang noch den Vortageswert an bis > zum Morgen. Ahoy grau unterlegt, OpenDTU ganz normal wie auch untertags. Hast Du HM oder HMS-Wechselrichter? Bei mir sind bei beiden die Einstellungen gleich
Auf Ahoy sind HM (da nur ESP8266) und auf der OpenDTU hängen HMT. Nur, warum machst nicht erstmal ein Update auf gleiche Stände, um nur irgendwas sinnvoll vergleichen zu können?
:
Bearbeitet durch User
Grisu schrieb: > Nur, warum machst nicht erstmal ein Update auf gleiche Stände, um nur > irgendwas sinnvoll vergleichen zu können? der für die Abends nichts anzeigenden HMS-WR zuständige hatte ich bereits upgedatet Aber bin jetzt deinem Ratschlag gefolgt, beide ESPs sind auf Version v23.9.18 Das leider ernüchternde Resultat: - OpenDTU mit 4 x HM-1200 zeigt auch jetzt bei Dunkelheit den Tagesertrag an - OpenDTU mit 3 x HMS-2000 zeigt jetzt bei Tagesertrag null an Unterschiede in den Einstellungen finde ich keine Gibt es sonst jemand mit HMS-WR? Was wird hier abends angezeigt?
Heinz R. schrieb: > Gibt es sonst jemand mit HMS-WR? Was wird hier abends angezeigt? es wird immer merkwürdiger aktuell zeigen nach Sonnenuntergang 2 der 3 HMS-WR den Tagesertrag an, bei einem steht der auf Null?
Vielleicht schlechter Empfang zu dem und aufgrund aussetzender Werte dann das Bild ... Oder was mir noch einfiele dazu. Vielleicht schaltet der wegen Überspannung auf der Phase im Netz ab bzw. weil er der hinterste in der Reihe ist mit der folglich höchsten Spannung die grad schon das Abschalten bewirkt, dann ist für ihn ja ein neuer Tag wo er noch nichts produziert hat. Beobachte ihn halt mal einen ganzen Tag lang bzw. sie dir die MQTT-Einträge an.
:
Bearbeitet durch User
nein, es muss ein anderes Problem sein Jetzt ist die Snne seit 4 Stunen weg 2 von 3 HMS zeigen beim Tagesertrag je ca. 9 kWh an - das passt und wird so in der Gesamt-Tagessumme auch angezeigt Der 3. HMS zeigt beim Tagesertrag 0 an Die 4 HM zeigen jetzt alle beim Tagesertrag realistische Werte an
Hängt sich ein ESP32 und openDTU mit der Zeit auf? Lief eigentlich klaglos, jedoch nach dem letzten Update vor einigen Tagen auf v23.9.18 hat er heute keine Werte mehr übertragen bekommen vom WR. Neustart änderte nichts daran, dachte schon der WR wäre über Nacht ausgefallen. Kurz die DTU vom Strom genommen und nun geht es wieder. Passiert das anderen hier auch oder Einzelfallproblem?
:
Bearbeitet durch User
Hier läuft das seit Monaten problemlos mit Version 23.4.25.
Moin Leute, hatte mir den AhoyDTU für meinem Hoymiles HM-600 gebaut und das lieft auch schon ein paar Wochen ganz gut. Gestern habe ich den Standort vom AhoyDTU geändert und da er dadurch näher an meinem zweiten Router gekommen ist auch den WLAN Zugang angepasst. Jetzt sehe ich nur noch eine abgespeckte Version des Menue mit den Punkten -AhoyDTU -Rest API -Documentation -About alles andere wird nicht mehr angezeigt. Auch der Punkt settings nicht, um das wieder rückgägngig machen zu können. Seltsamerweise werden die Daten offensichtlich weiterhin in HomeAssistant eingespeist, da kommt es im Energiedashboard jedenfalls an. Für einen schnellen Blick ist mir die weboberfläche von AhoyDTU aber lieber. Was könnte ich tun? Danke Hardy
Na dann hast wohl auch ein FW-Update gemacht und mußt vorher am Ahoy anmelden (Login).
Grisu schrieb: > Hängt sich ein ESP32 und openDTU mit der Zeit auf? > Lief eigentlich klaglos, jedoch nach dem letzten Update vor einigen > Tagen auf v23.9.18 hat er heute keine Werte mehr übertragen bekommen vom > WR. Neustart änderte nichts daran, dachte schon der WR wäre über Nacht > ausgefallen. > Kurz die DTU vom Strom genommen und nun geht es wieder. > > Passiert das anderen hier auch oder Einzelfallproblem? Das passiert bei mir auch seit ein paar Firmware-Versionen. (Also die Aktuelle v23.10.9, v23.9.18 und v23_9_13) Ich habs so gelöst dass ich den ESP ein oder zwei mal in der Woche in der Nacht kurz vom Strom nehme. Ich habe schon einen 3,3V / 1,5A Festspannungsregler extern angeschlossen weil ich vermutet habe dass der kleine Onboard-Regler kurzzeitig überlastet ist und der ESP in Brown-out geht. Der hat das Problem aber nicht behoben. (Das Netzteil war erst ein 25W Handyladegerät, jetzt ist es ein 9V, 30VA Trafo) Ich hab schon überlegt einen externen Watchdog anzuschließen der das Aus-/ Einstecken für mich übernimmt.
Danke für deine Rückmeldung, dann besteht ja zumindest die Hoffnung, daß jemand den Fehler entdeckt und dieser behoben werden kann.
Angehängte Dateien:
-
Display.png
1,6 MB
Mir ist es mit Annex ESP32Basic gelungen so ein AZ-Wanddisplay zur Anzeige von Hoymiles Wechselrichter mit OpenDTU zu programmieren. Inzwischen kann ich auch die Leistung über ESP32 Annex Basic einstellen. Also nicht über MQTT sondern per in Annex ESP32Basic übersetztem Curl Befehl. Wenn man also z.B. einen Shelly EM per Json abfragt, könnte man ohne andere Server (z.B. MQTT-Broker, Openhab, Symcon o.ä. die Nulleinspeisung in diesem ESP32 per ESP32 Annex Basic regeln. Guggst Du https://cicciocb.com/forum/viewtopic.php?p=5404#p5404
:
Bearbeitet durch User
so was bekommst auch mit ESPEasy sehr einfach hin, eagl ob jetzt per MQTT oder direkt Selbst Touch ist dort rel. einfach umzusetzen
wlog WPOST$("http://admin:password@192.168.x.x/api/limit/config";,
|data={"serial":"1234567890", "limit_type":1, "limit_value":50}|, 0,
"application/x-www-form-urlencoded")
Das ist der Befehl in ESP32 Annex Basic um die Leistung zu stellen.
Vorher status Abfrage machen.
Ganz ohne MQTT Brokker oder andere Geschichten.
@Heinz
zeige mir den Befehl in ESPeasy, der das Gleiche macht. Und wenn das
nicht klappt wenigstens die Parameter und Listings für die
Displaydarstellung.
Helmut H. schrieb: > @Heinz > zeige mir den Befehl in ESPeasy, der das Gleiche macht. Und wenn das > nicht klappt wenigstens die Parameter und Listings für die > Displaydarstellung. mit Leistungslimits habe ich mich zugegeben nie beschäftigt, ich habe hier eine offiziell Angemeldete Anlage die auch einspeisen darf Aber laut https://github.com/tbnobody/OpenDTU/blob/master/docs/Web-API.md curl -u "admin:password" http://192.168.10.10/api/limit/config -d 'data={"serial":"11418180xxxx", "limit_type":1, "limit_value":50}' Ein ganz normales HTTP Post.. Klar, curl gibt es in ESPEasy nicht :-) Parameter und Listings? Ich habe für meinen Herrn Papa eine kleine 7Segment-Anzeige gebastelt die sich den Wert von OpenDTU holt Wenn es unbedingt kein MQTT sein darf legst halt in ESPEasy ein Dummy-Device an, holst Dir alle paar Sekunden den Wert aus OpenDTU, das ist ja gut dokumentiert das Display kannst z.B. so beschreiben: on wasacuhimmer#abc do tft,rf,10,10,300,60,red,red tft,txtfull,110,55,3,white,black,rot endon Aber irgendwann wirst merken das so ein MQTT-Server durchaus seinen SInn hat - macht vieles einfacher, und es gibt auch öffentliche..
:
Bearbeitet durch User
Ein mächtiges Hallo in die Runde! Ersteinmal vielen Dank für Eure Arbeit zum OpenDTU! Nun zu meiner Frage, ist es möglich auch ein anderes SPI-Display mit der Auflösung 128x64 pixel zu nutzen? Das Display besitzt einen Sitronix ST7565R-G Controller und den habe ich erfolgreich mit der u8glib mit den ESPs in Betrieb. Und wenn ich das richtig heraus gelesen habe, wird ja in dem Code für die OPEN DTU auch die Lib benutzt. Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display einbinden kann? Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und C++ Programme gearbeitet, wie kann ich dann den Code compelieren? Ein Tip und Hilfe würde ich mich sehr freuen. Grüße MAT
Matthias S. schrieb: > Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display > einbinden kann? > Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und > C++ Programme gearbeitet, wie kann ich dann den Code compelieren? Zur ersten Frage kann ich nichts antworten, aber diese wäre sicher besser in den "Discussions" auf https://github.com/tbnobody/OpenDTU/ aufgehoben. Eine Anleitung zum Kompilieren findest Du unter "Flashing and starting up" ebenfalls auf GitHub.
Daniel schrieb: > Matthias S. schrieb: >> Kann mir bitte jemand den Punkt in der SW aufzeigen, wie ich das Display >> einbinden kann? >> Und weiterhin, habe noch nicht genug mit VS Code oder Platform IO und >> C++ Programme gearbeitet, wie kann ich dann den Code compelieren? > > Zur ersten Frage kann ich nichts antworten, aber diese wäre sicher > besser in den "Discussions" auf https://github.com/tbnobody/OpenDTU/ > aufgehoben. Eine Anleitung zum Kompilieren findest Du unter "Flashing > and starting up" ebenfalls auf GitHub. Hallo Daniel, danke für adeinen Hinweis, habe dort auch schon die Frage platziert. Dachte bei der Regen Teilnahme hier, dass es ein Hinweis geben könnte. MAT
> Grisu schrieb: > > Vieleicht noch ein Nachteil den man bedenken sollte: > Einen Akku nachrüsten ist nicht ganz einfach und auch nicht günstig, da > man für den Akku dann wieder einen WR braucht. > Aber das ist ja ein anderes Thema. > Das ist gar nicht so teuer. Und vor allem ganz einfach. Ein Multiplus II reicht. Gibt es ab 500€. Der kann alles was man zu einem AC gekoppelten Speicher braucht, dazu braucht es noch eine Steuerung. Wenn man nicht zu viel Basteln will nimmt man ein Cerbo GX (das -S hat kein CAN BUS für Batterien) für etwa 200€ und Bastelafine nehmen dafür einen Raspi. Im youtube gibt es einige Kanäle, wie etwa Schatten PV, Kleines Zuhause und andere die genau zu diesem Punkt Thema Videos gemacht haben. Der Multiplus wird mit AC Out einfach an den Verteiler angeschlossen und Batterie dran. Fertig ist. Das ist natürlich nicht Schwarzstart fähig, aber das wird denke ich überbewertet. Wer will kann am AC In noch eine Notsromsteckdose anschliessen die Strom abgibt so lange der Akku Saft hat.
Was sagt ihr dazu? Hat jemand mehr Details? https://www.cleanthinking.de/bnetza-hoymiles-hm-800-wechselrichter/
Alexander H. schrieb: > Was sagt ihr dazu? > Hat jemand mehr Details? > https://www.cleanthinking.de/bnetza-hoymiles-hm-800-wechselrichter/ Da hier wohl keine Antwort erfolgt und das auch nicht wirklich der richtige Platz ist, zumindest ein Link mit weiteren Infos und Stellungnahmen: https://www.photovoltaikforum.com/thread/226815-hm-800-von-der-bundesnetzagentur-vom-markt-genommen/ Ergo: Betrieb der WR weiter kein Problem, Vertrieb aber (vorläufig) eingestellt.
Nabend, da der Thread, zumindest für mich, mittlerweile ziemlich unübersichtlich geworden ist und ich keine Lust habe die nächste Woche damit zu verbringen alle Beiträge durchzulesen, kann mir eventuell jemand sagen wo ich die aktuelle Version für einen Arduino finde. Also ich suche nichts für einen ESP sondern einfach nur das Protokoll für die Kommunikation über SPI. Hintergrund ist, das ich noch einen ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP nicht brauche und auch nicht will. Es reicht mir wenn das mein Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino empfängt und entsprechend aufarbeitet.
Tim T. schrieb: > Hintergrund ist, das ich noch einen > ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP > nicht brauche und auch nicht will. Es reicht mir wenn das mein > Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino > empfängt und entsprechend aufarbeitet. um damit 2€ zu sparen? Merkwürdige Vorstellung....
Heinz R. schrieb: > Tim T. schrieb: >> Hintergrund ist, das ich noch einen >> ganzen Sack Arduino Uno und Nano habe und den ganzen Klimbim auf dem ESP >> nicht brauche und auch nicht will. Es reicht mir wenn das mein >> Homeserver erledigt indem er die Daten über Seriell/USB vom Arduino >> empfängt und entsprechend aufarbeitet. > > um damit 2€ zu sparen? > > Merkwürdige Vorstellung.... Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler mit einem Vollwertigen System machen kann, was die Daten sehr einfach exakt so aufbereitet wie ich es will?
> Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die > Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen > Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler > mit einem Vollwertigen System machen kann, was die Daten sehr einfach > exakt so aufbereitet wie ich es will? Ja, das verstehe ich. Die Community um AhoyDTU und OpenDTU mit ihren instabilen ESPs können nur irren. Ein vollwertiges System mit einem Arduino ist da ohne Alternativen.
Daniel schrieb: >> Nein, nur brauche ich echt nichts von dem was ein ESP bietet und die >> Benutzung instabiler und komplexer macht. Und wofür sollte ich mir einen >> Kastrierten Webserver ans Bein binden wenn ich das deutlich flexibler >> mit einem Vollwertigen System machen kann, was die Daten sehr einfach >> exakt so aufbereitet wie ich es will? > > Ja, das verstehe ich. Die Community um AhoyDTU und OpenDTU mit ihren > instabilen ESPs können nur irren. Ein vollwertiges System mit einem > Arduino ist da ohne Alternativen. Und schon wieder absolut unnötiges Geblubber. Was die AhoyDTU oder die OpenDTU kann oder nicht, ist mir absolut egal, weil ich es weder will noch brauche. Fakt ist nunmal das die ESP sehr wählerisch bei der Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist, hängen sie sich auf. Dazu kommt dann irgendwelche überfrachtete Software die alles andere als ausentwickelt ist und weitere Probleme macht, wobei ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und der ganze Rest nur unnötiger Raffel ist. Dazu kommt das es natürlich sehr sinnvoll ist, im gleichen Frequenzbereich die Daten weiter zu schicken in dem man sie empfängt. Letztlich soll mir der Arduino nur als Umsetzer von Nordic auf USB dienen und sonst möglichst garnix machen. Wer das nicht verstehen will, dem kann ich auch nicht helfen.
Tim T. schrieb: > Und schon wieder absolut unnötiges Geblubber sorry, in meinen Augen nicht so - es wurde halt was vernünftig mit aktuellen Prozessoren umgesetzt Tim T. schrieb: > Fakt ist nunmal das die ESP sehr wählerisch bei der > Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist, > hängen sie sich auf. Wie kommst Du auf solche Ausssagen? Tim T. schrieb: > Dazu kommt dann irgendwelche überfrachtete Software > die alles andere als ausentwickelt ist und weitere Probleme macht, wobei > ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und > der ganze Rest nur unnötiger Raffel ist. Ziemlich freche Aussage - warum bettelst hier und programmierst nicht selber kurz was? Tim T. schrieb: > Wer das nicht verstehen will, dem kann ich auch nicht helfen. Du hast sicher auch nur 3beinige Tische daheim - das 4. Bein ist unnützer Ballast? :-)
Heinz R. schrieb: > Tim T. schrieb: >> Und schon wieder absolut unnötiges Geblubber > sorry, in meinen Augen nicht so - es wurde halt was vernünftig mit > aktuellen Prozessoren umgesetzt Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm ab: 1. Brauche ich eine komplexere HMI-Schnittstelle (Display, Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC 2. Einfache Sachen aber mit WLAN: ESP32 3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32 4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum: ATtiny 5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino. Und das hat genau garnix mit dem Thema zu tun. > > Tim T. schrieb: >> Fakt ist nunmal das die ESP sehr wählerisch bei der >> Stromversorgung sind und sobald da irgendeine Kleinigkeit mit ist, >> hängen sie sich auf. > > Wie kommst Du auf solche Ausssagen? Betreibe seit längerer Zeit mehrere ESP32, unter anderem zum auslesen meines Stromzählers. IR-Diode Seriell auslesen und als UDP-Paket an meinen Server wo dann etwas Nachbearbeitung erfolgt und in eine MySql Tabelle geschrieben wird. Oder auch in meinem APRS Tracker für Wetterballons. > > Tim T. schrieb: >> Dazu kommt dann irgendwelche überfrachtete Software >> die alles andere als ausentwickelt ist und weitere Probleme macht, wobei >> ich ja eigentlich nur die Telegramme zum weiterverarbeiten brauche und >> der ganze Rest nur unnötiger Raffel ist. > > Ziemlich freche Aussage - warum bettelst hier und programmierst nicht > selber kurz was? Genau darum geht es ja, ich suche nur das Protokoll. Aber bin schon dran, wollte es mir nur einfacher machen bevor ich jetzt wieder Zeit damit verschwende entsprechende Informationen aus dem Quelltext der AhoyDTU zu extrahieren. > > Tim T. schrieb: >> Wer das nicht verstehen will, dem kann ich auch nicht helfen. > > Du hast sicher auch nur 3beinige Tische daheim - das 4. Bein ist > unnützer Ballast? :-) Ja, ich habe (auch) 3 Beinige Tische zuhause, unter Anderem wegen der (eventuell nicht dir) bekannten Vorteile.
:
Bearbeitet durch User
Tim T. schrieb: > Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm > ab: > 1. Brauche ich eine komplexere HMI-Schnittstelle (Display, > Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC > 2. Einfache Sachen aber mit WLAN: ESP32 > 3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32 > 4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum: > ATtiny > 5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino. > > Und das hat genau garnix mit dem Thema zu tun. dann mach das doch gerne so - aber nicht beleidigt sein wenn hier 99% anders denken Du hast wahrscheinlich auch 2 Autos, eins mit, eins ohne Servo - vor der Fahrt wird Einsatzenstsprechend gewählt?
:
Bearbeitet durch User
Heinz R. schrieb: > Tim T. schrieb: >> Bei mir läuft bei einer Aufgabe immer das gleiche Entscheidungsprogramm >> ab: >> 1. Brauche ich eine komplexere HMI-Schnittstelle (Display, >> Maus/Tastatur) und Netzwerkzugriff: Raspberry oder NUC >> 2. Einfache Sachen aber mit WLAN: ESP32 >> 3. Brauche ich Leistung ohne Interaktion mit Netzwerken: STM32 >> 4. Simpelste Aufgabe bei "geringer" Größe ohne viel extra drumherum: >> ATtiny >> 5. Rest: Atmel ATmega, aus Faulheitsgründen oft als Arduino. >> >> Und das hat genau garnix mit dem Thema zu tun. > > dann mach das doch gerne so - aber nicht beleidigt sein wenn hier 99% > anders denken Ob es wirklich 99% sind wage ich zu bezweifeln, aber selbst wenn, was hat das schon für eine Bedeutung? Eine Mehrheit, egal bei welchem Thema, sagt noch überhaupt nichts über die Qualität der Aussage aus. > Du hast wahrscheinlich auch 2 Autos, eins mit, eins ohne Servo - vor der > Fahrt wird Einsatzenstsprechend gewählt? Fast, es sind zwei Autos, Kleinwagen und Kombi und ja, es wird entsprechend vor dem Einsatz gewählt. Aber im Jahr 2024 haben beide schon Servolenkung...
Tim T. schrieb: > Betreibe seit längerer Zeit mehrere ESP32, unter anderem zum auslesen > meines Stromzählers. Habe ich auch (allerdings über MBus). Der ESP hat inzwischen einen Arduino Nano als externen Watchdog, weil er sich ~ 1x am Tag aus unerfindlichen Gründen aufgehängt hat ... PS.: Was Du hier (sicher nicht zum ersten Mal) erlebst ist leider inzwischen für die meisten Foren typisch. Es wird unheimlich viel Energie aufgewendet, Dir die Herangehensweise des Antwortenden näherzubringen, weil Derjenige annimmt, wenn Du das, was Du fragst nicht weißt, wirst Du wohl überhaupt ein Trottel sein, und er muss Dich bel(k)ehren. Dass es durchaus Vorteile haben kann etwas Älteres Einfacheres Bekanntes zu verwenden, erschließt sich allerdings den Meisten in ihrer Schlichtheit nicht!
@Tim Taylor (DER Heimwerkerking? ;-) ): Ich sehe da kein Problem mit dem Arduino-Interface und ich weiss nicht, warum hier so emotionale Diskussionen entstehen. ;-) => Im entsprechenden github Repository https://github.com/lumapu/ahoy findest Du Doku über das Protokoll, die Sourcen und auch Hardware, etc. Damit sollte es easy sein, die Parameter Deines WR auszulesen. @Heinz R: Die Anfrage von Tim ist doch kein Grund, missionarisch zu werden. ;-) Die ESPs sind nicht schlecht, haben aber auch durchaus ihre Schwächen. Ich verstehe seinen Ansatz, einfach einen Arduino als kleinen Protokollwandler/Interface für einen Rechner o.ä. einsetzen zu wollen. Und jetzt vertragen wir uns alle mal wieder. ;-) :-) Cheers!
Christian B. schrieb: > Tim T. schrieb: >> Betreibe seit längerer Zeit mehrere ESP32, unter anderem zum auslesen >> meines Stromzählers. > > Habe ich auch (allerdings über MBus). Der ESP hat inzwischen einen > Arduino Nano als externen Watchdog, weil er sich ~ 1x am Tag aus > unerfindlichen Gründen aufgehängt hat ... Das gleiche hatte ich auch und meine (vorübergehende) Lösung war eine elektronische Zeitschaltuhr die irgendwann mitten in der Nacht für 1 Minute die Spannungsversorgung unterbrochen hat. Die Finale Lösung war dann aber das Steckernetzteil von einem alten Amazon Fire TV-Stick, das hat zwar auch nur 5W aber irgendwie kommt der ESP damit besser klar als mit allen Netzteilen zuvor, egal ob von Apple oder sonst einem Hersteller mit 10W. > PS.: > Was Du hier (sicher nicht zum ersten Mal) erlebst ist leider inzwischen > für die meisten Foren typisch. Gefühlt ist es in den letzten Jahren hier deutlich schlimmer geworden. > Es wird unheimlich viel Energie aufgewendet, Dir die Herangehensweise > des Antwortenden näherzubringen, weil Derjenige annimmt, wenn Du das, > was Du fragst nicht weißt, wirst Du wohl überhaupt ein Trottel sein, und > er muss Dich bel(k)ehren. Ja, und das von Leuten die nicht die geringste Ahnung vom Background des jeweiligen Fragestellers haben. > Dass es durchaus Vorteile haben kann etwas Älteres / Einfacheres / > Bekanntes zu verwenden, erschließt sich allerdings den Meisten in ihrer > Schlichtheit nicht! Ja, nicht jeder versteht das KISS Prinzip. Lars B. schrieb: > @Tim Taylor (DER Heimwerkerking? ;-) ): Ja, so in etwa^^. > Ich sehe da kein Problem mit dem Arduino-Interface und ich weiss nicht, > warum hier so emotionale Diskussionen entstehen. ;-) > => Im entsprechenden github Repository https://github.com/lumapu/ahoy > findest Du Doku über das Protokoll, die Sourcen und auch Hardware, etc. > Damit sollte es easy sein, die Parameter Deines WR auszulesen. Ja, hatte das Repo mittlerweile auch gefunden, nur fälschlicherweise zuerst den nano Ordner unter tools genommen bevor ich dann beim NRF24_SendRcv gelandet bin. Aber auch das Zeug darin ist nicht wirklich brauchbar. Ich denke aber, das ich jetzt mit den Infos aus dem doc Ordner und den Quelltexten der AhoyDTU eigentlich alles zusammen habe. Das Einzige was mir immer noch unklar ist, ist die Kanalwahl und das Hopping Schema...
Zum Thema ESPxx - Abstürze Man hat hier mit den tollen Ahoy / OpenDTU Projekten viele zig tausend Testuser - die Foren sind bemerkenswerter Weise nicht voll mit "stürzt ständig ab" usw Ich bin gespannt auf Deine Arduino-Implementierung - ich hoffe Du veröffentlichst die dann auch im Sinne der Projekte entsprechend - es ist ja dann ein gewaltiger Schritt nach vorne - wesentlich mehr Zuverlässigkeit - wobei Du von den Erkenntnissen und Forschungen anderer profitierst Nicht böse gemeint - aber Dein Beizrag kommt irgendwie rüber wie "schön das Ihr da was gebastelt habt - gebt mal den Code rüber, dann mache ich es richtig"
:
Bearbeitet durch User
@Tim Taylor Du nimmst wohl an, dass alle anderen wenig Ahnung von der Materie haben, was Deine Aussagen unterstreichen wie "Ja, nicht jeder versteht das KISS Prinzip." Du diffamierst eine Entwicklergruppe mit ihrem Projekt pauschal mit Zitat: "irgendwelche überfrachtete Software, die alles andere als ausentwickelt ist und weitere Probleme macht". Aber dann sagst Du wieder, Projekte bei "Einfache Sachen aber mit WLAN: ESP32" umzusetzen, was nicht wirklich zusammenpasst. Nebenbei: Ich bin Informatiker und kenne das "KISS-Prinzip" seit vielen Jahren und habe Projekte mit unterschiedlichen Mikrocontrollern umgesetzt. Also bitte keine derartigen unbelegten Thesen in einem Fachforum. Ich habe selbst mehrere Projekte mit dem ESP32 auf Basis AhoyDTP (mehrere Mikrowechselrichter der HM-Serie) und OpenDTU (HMS-Serie) umgesetzt. Diese ESP laufen störungsfrei ununterbrochen seit vielen Monaten. Deine genannten "Instabilitäten" sind daher lediglich eine Behauptung, die ohne Nennung einer bestimmten (evtl. problematischen) Hardwarekonstellation keine Grundlage hat. Bei den ESP8266 stimme ich Dir unter bestimmten Bedingungen zu, aber das war ja nicht Dein Thema. Auch nebenbei: Projekte wie "Tasmota" sind praktisch die Open Source-Referenz im ESP-Bereich. ESPs auf dieser Basis laufen (auch bei mir) problemlos seit Jahren ohne Ausfall. Vorschlag: Wende Dich doch mit Deinem Problem und genau mit Deinen bisherigen Aussagen direkt an die Hauptentwickler der beiden Projekte auf GitHub. Mich würde dann aber interessieren, wie das dann dort ankommt und wie Dir geholfen wird.
Daniel schrieb: > @Tim Taylor > > Du nimmst wohl an, dass alle anderen wenig Ahnung von der Materie haben, > was Deine Aussagen unterstreichen wie > "Ja, nicht jeder versteht das KISS Prinzip." > Du diffamierst eine Entwicklergruppe mit ihrem Projekt pauschal mit Nein, nicht die Entwicklergruppe, nur diejenigen, die immer noch nicht verstehen (wollen), was ich eigentlich haben will und mich weiter bekehren wollen. Wer eine Ahoy DTU haben will, soll sie benutzen, auf meinen Usecase trifft sie jedoch nicht zu. > Zitat: "irgendwelche überfrachtete Software, die alles andere als > ausentwickelt ist und weitere Probleme macht". Schau dir die Issues an. Ich will ein System das ich einmal anwerfe und woran ich im besten Fall nie wieder denken muss. Kombiniert mit kleiner Energieaufnahme. > Aber dann sagst Du wieder, Projekte bei > "Einfache Sachen aber mit WLAN: ESP32" umzusetzen, was nicht wirklich > zusammenpasst. Sag mal begreifst du es echt nicht? ES SOLL KEIN WLAN BENUTZT WERDEN! 1. Der WR kommuniziert über Nordic mit dem NRF24L01+ 2. Der NRF24L01+ kommuniziert über SPI mit dem Arduino 3. Der Arduino kommuniziert über RS232 mit dem FTDI 4. Der FTDI kommuniziert über USB mit dem Server 5. Der Server kümmert sich um den Rest Der Arduino haut dabei nur stumpf die Requests an den WR raus und leitet die Antworten, bei denen die CRC stimmt, an den Server weiter. Mehr nicht, keine Auswertung, keine tollen Menüs, nichts. Ansonsten bedeutet "Einfache Sachen" für mich in dem Zusammenhang auch das keine besonderen Anforderungen an die Zuverlässigkeit bestehen. > Nebenbei: Ich bin Informatiker und kenne das "KISS-Prinzip" seit vielen > Jahren und habe Projekte mit unterschiedlichen > Mikrocontrollern umgesetzt. Ja, und ich bin (Software)entwickler für Eingebettete Systeme und verdiene mein Geld hauptberuflich mit Softwareentwicklung auf STM32 und PIC im Automobilbereich. So what? > Also bitte keine derartigen unbelegten Thesen in einem Fachforum. Kennen und verstehen sind zwei Paar Stiefel. > Ich habe selbst mehrere Projekte mit dem ESP32 auf Basis AhoyDTP > (mehrere Mikrowechselrichter der HM-Serie) und OpenDTU (HMS-Serie) > umgesetzt. > Diese ESP laufen störungsfrei ununterbrochen seit vielen Monaten. > Deine genannten "Instabilitäten" sind daher lediglich eine Behauptung, > die ohne Nennung einer bestimmten (evtl. problematischen) > Hardwarekonstellation keine Grundlage hat. > Bei den ESP8266 stimme ich Dir unter bestimmten Bedingungen zu, aber das > war ja nicht Dein Thema. Schön für dich und richtig, der ESP ist immer noch nicht mein Thema. > Auch nebenbei: Projekte wie "Tasmota" sind praktisch die Open > Source-Referenz im ESP-Bereich. > ESPs auf dieser Basis laufen (auch bei mir) problemlos seit Jahren ohne > Ausfall. Schön das es für deinen Usecase passt. > Vorschlag: > Wende Dich doch mit Deinem Problem und genau mit Deinen bisherigen > Aussagen direkt an die Hauptentwickler der beiden Projekte auf GitHub. > Mich würde dann aber interessieren, wie das dann dort ankommt und wie > Dir geholfen wird. Warum? Glaubst du ernsthaft ich investiere weiter Zeit mit ungewissem Ausgang anstatt das jetzt mit den zugegeben dürftigen Informationen selber zusammen zu knüppeln? Und bevor wieder die Keule mit den unbelegten Thesen kommt: Wo steht was die CMDs 0x03, 0x83 und 0x84 machen? Nach welchem Schema läuft das Channelhopping ab? Gibt es für den HM-1500 irgendwo bessere Informationen als das hm4chAssignment[] in https://github.com/lumapu/ahoy/blob/main/src/hm/hmDefines.h? Und da ich diese bislang im Repo nicht gefunden habe, bezweifel ich stark, das sich irgendwer die Mühe macht diese extra für mich zusammen zu schreiben.
:
Bearbeitet durch User
Angehängte Dateien:
-
gazell.png
42 KB
Tim T. schrieb: > Nach welchem Schema läuft das Channelhopping ab? Hallo Tim, ich war ganz am Anfang des Threads an der Protokollanalyse beteiligt, unter anderem auch als es um das Channelhopping ging. Dabei wurde mal das Gazelle Protokoll von nRF in den Raum geworfen. Das Thema wurde dann aber nicht weiter verfolgt, weil man mit dem nRF24L01 das Hopping ja irgendwie nachbilden konnte - aber um es nochmal aufzugreifen: Das Channelhopping dürfte nach dem "Gazelle Link Layer" von nRF aufgebaut sein (der nRF24L01 als pures RF Interface unterstützt dies nicht!): https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/gazell/gzll.html Dabei ist der Wechselrichter der Host, der in definierten Timeslots auf gewissen Kanälen horcht und dann auf den nächsten wechselt (bei Hoymiles waren das 3, 23, 40, 61, 75). Mit einigen SoCs von nRF kann das GZLL implementiert werden, z.B. mit dem nRF51822, der abwärtskompatibel mit dem Funkprotokoll des nRF24L01 bzw. dem in der Original DTU verwendeten nRF24LE1 ist. Wenn du also sowieso nochmal vorne anfängst, wäre es vielleicht eine Überlegung das mit einem nRF51822 zu versuchen. Da dieser ein SoC (Cortex M0) ist, könntest du sogar direkt serielle Daten rausgeben ohne Arduino. Den nRF51822 gibt es ähnlich günstig wie den nRF24L01 - nur leider nicht mit PA/LNA, was der Reichweite zugute kommen würde...
So, habe mich jetzt durch 2/3 der Posts dieses Threads gelesen und muss sagen, ich könnte im Strahl kotzen... Der Thread besteht nur etwa aus 5% Protokollanalyse, 15% Lobhuddelei wie toll doch alles ist, 20% Informationen über die verdammte Ahoy DTU, die nichts mit dem Protokoll zu tun haben, 20% blödem Geschwätz von Leuten die zwar überhaupt keinen Plan haben aber ach so gerne helfen wollen, 20% Fragen zu anderen WR als der HM Serie und 20% Fragen von Leuten die wahlweise das Bin nicht finden, die Leitungen nicht angeklemmt bekommen oder irgendwelche anderen Sachfremden Fragen (MQTT, etc.) haben. Dazu kommt eine erbärmliche und falsche Protokollbeschreibung im Github Repo die kaum im Ansatz weiterhilft und ein Code der so weit mit Zusatzfeatures vollgepflastert wurde, dass es auch ewig dauert daraus das Protokoll zu destillieren. Glücklicherweise gibt es jedoch 3-4 Lichtgestalten in diesem Thread die das ganze Thema überhaupt voran gebracht haben und damit meine ich explizit nicht diejenigen die das ganze auf den ESP mit dem ganzen Beiwerk geklempnert haben sondern diejenigen die am Protokoll geforscht haben. Aber dank der ganzen Störfeuer wäre wohl auch diese Arbeit irgendwann untergegangen wenn nicht einer zufällig den Quelltext der DTU-Pro auf gitee gefunden hätte, der traurigerweise zielführender war als das meiste was hier geschrieben wurde. Falls irgendwer von euch nochmal so etwas vorhat, bitte bitte, verkneift euch irgendwelche, von absoluten DAUs benutzbaren Lösungen, während es noch ein PoC ist, sonst dreht sich hinterher wieder die Mehrheit der Posts nicht um das Protokoll und dessen Entschlüsselung sondern um DAU-Support und anderen damit zusammenhängenden Problemen. PS: Ja, schön runtervoten, dann weiß ich auch das es die Richtigen gelesen haben.
:
Bearbeitet durch User
Lieber Tim, wäre es nicht besser für Dich , für die Menschheit generell wenn Du Dich einfach aus solchen Dingen komplett raus hälst? Entwickle gerne Deine eigene Steuerung - aber Deine Überheblichkeit und Besserwisserei - unglaublich Ja, es gibt sicher sehr viele gute Ingenieure die wesentlich bessere Lösungen gefunden haben - ganz ohne Bedürfniss diese in Github usw teilen zu müssen, sie einfach für sich einsetzen Aber Deine Reaktion ist mir zugegeben sehr unverständlich
Heinz R. schrieb: > Lieber Tim, > > wäre es nicht besser für Dich , für die Menschheit generell wenn Du Dich > einfach aus solchen Dingen komplett raus hälst? Nein, ganz im Gegenteil. > Entwickle gerne Deine eigene Steuerung - aber Deine Überheblichkeit und > Besserwisserei - unglaublich Meine Steuerung läuft und die von dir genannte Überheblichkeit und Besserwisserei sind nur Fakten. > Ja, es gibt sicher sehr viele gute Ingenieure die wesentlich bessere > Lösungen gefunden haben - ganz ohne Bedürfniss diese in Github usw > teilen zu müssen, sie einfach für sich einsetzen Jop, aber das ist nicht der Punkt. Es hätte hier im Thread nicht um eine Steuerung gehen sollen, sondern um das Protokoll dafür und das wurde hier gründlich vergeigt. > Aber Deine Reaktion ist mir zugegeben sehr unverständlich Das glaube ich dir sogar. Du verstehst eben nicht den den Vorteil eines sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer gearteten, Implementierung einer Steuerung dafür.
:
Bearbeitet durch User
Tim T. schrieb: > Jop, aber das ist nicht der Punkt. Es hätte hier im Thread nicht um eine > Steuerung gehen sollen, sondern um das Protokoll dafür und das wurde > hier gründlich vergeigt. Tim T. schrieb: > Meine Steuerung läuft und die von dir genannte Überheblichkeit und > Besserwisserei sind nur Fakten. Tim T. schrieb: > Das glaube ich dir sogar. Du verstehst eben nicht den den Vorteil eines > sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer > gearteten, Implementierung einer Steuerung dafür. Dann bitte, mach es besser. Sollten wir von dir keine saubere Dokumentation bekommen ist alles von dir nur erbärmlich.
Tim T. schrieb: > Du verstehst eben nicht den den Vorteil eines > sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer > gearteten, Implementierung einer Steuerung dafür. Dir ist aber schon klar das hier nicht ein"Protokoll neu entwickelt wurde sondern ein von Hoymiles strikt geheim gehaltenes Protokoll geknackt wurde? Klar ist das für DIch jetzt einfach - mit dem Wissen und der Forschung anderer das auf Deinen bevorzugten Microcontroller zu adaptieren Wenn alles so einfach ist - warum fragst dann überhaupt hier? Hättest doch alles für Dich entwickeln können Mit selbst entwickeln meine ich DU hast den WR , evtl. eine DTU, sonst nichts - leg los....
Heinz R. schrieb: > Tim T. schrieb: >> Du verstehst eben nicht den den Vorteil eines >> sauber dokumentierten Protokolls gegenüber irgendeiner, wie auch immer >> gearteten, Implementierung einer Steuerung dafür. > > Dir ist aber schon klar das hier nicht ein"Protokoll neu entwickelt > wurde sondern ein von Hoymiles strikt geheim gehaltenes Protokoll > geknackt wurde? Natürlich ist mir das klar und genau das wurde nicht vernünftig dokumentiert sondern ist nur irgendwie in die Ahoy DTU gewandert. > Klar ist das für DIch jetzt einfach - mit dem Wissen und der Forschung > anderer das auf Deinen bevorzugten Microcontroller zu adaptieren GENAU DAS IST ES JA, DIE "FORSCHUNG" WURDE ERBÄRMLICH DOKUMENTIERT UND IST NUR IRGENDWIE IN DER AHOYDTU VERWURSTET WORDEN. > Wenn alles so einfach ist - warum fragst dann überhaupt hier? Hättest > doch alles für Dich entwickeln können Ich hatte nach dem Protokoll gefragt und genau das habe ich auch nicht bekommen, jedenfalls nicht aus diesem Thread oder der "Doku" im Github Repo. Ich habe es für mich letztlich aus den China Quelltexten auf gitee heraus implementiert. > Mit selbst entwickeln meine ich DU hast den WR , evtl. eine DTU, sonst > nichts - leg los.... Ja, das wäre letztlich die Variante gewesen die ich gewählt hätte wenn es nirgends Informationen gegeben hätte, gibt es aber. Zum Teil in homöopathischen Dosen hier im Thread oder geballt im Quelltext auf gitee. Aber klar, es ist natürlich super toll, wenn man die Erkenntnisse nirgends in brauchbarer Form aufschreibt und direkt tief in irgendeinem anderen Quelltext verbuddelt damit der nächste sich am besten gar nicht die Mühe macht was eigenes zu entwickeln.
:
Bearbeitet durch User
Tim T. schrieb:
Ich zitiere nicht Deine bisherigen Beiträge, diese stehen für sich und
waren teilweise sogar noch schärfer formuliert, bevor Du sie selbst
nochmals bearbeitet hast. Inhaltliche Kritik ist ja in Ordnung, aber das
geht eindeutig zu weit.
Gut gemeinter Rat:
Arbeite bitte intensiv an Deiner Sprache und an Deiner sozialen
Kompetenz. Es könnte Dir im Alltag nützlich sein.
Daneben stimme ich den Vorpostern zu. Bringe Dein Fachwissen doch hier
positiv zum Thema ein, Du nimmst dieses ja für Dich in Anspruch.
Lieber Tim, was ist das was Du hier abziehst? Ein Versuch wie KI funktioniert? Ein Versuch - wie weit kann ich Forumsteilnehmer treiben? Hinter Deinem Geschwätz kann auf keinen Fall ein normaler Mensch mit gesundem Menschenverstand stehen Dir geht es nicht um Hoymiles-WR sondern um irgend was ganz Anderes?
Beitrag #7691511 wurde vom Autor gelöscht.
Hallo! Jemand, der (wie ich) möglichst einfach die Livedaten von einem Hoymiles HM... Wechselrichter abrufen will, wird vielleicht hier fündig: https://github.com/sulmfish/pico_nrf_hm. Ist Micropython-Code und läuft (z. B.) auf einem Raspberry Pi Pico mit NRF24L01+-Modul.
Entschuldigung, dass ich diesen schon recht alten Thread wieder ausgrabe, aber ich beschäftige mich gerade mit der Kommunikation eines HM- Wechselrichters über das enhanced Shockburst Protokoll. Ziel ist eine intelligente Steuerung der Einspeiseleistung, die über die klassische Nulleinspeisung hinausgeht. Das Ahoy-Wiki https://github.com/lumapu/ahoy/wiki/Protocol habe ich gelesen, werde aber nicht richtig schlau daraus. Es würde mir sehr viel weiterhelfen, wenn mir jemand hier folgende 3 Fragen beantworten könnte: 1. Nutzt das Protokoll die Auto-Ack-Funktion mit automatischer Sendewiederholung? 2. Manche Pakete sind mit 0x7E und 0x7F eingerahmt, andere nicht. Welches Format ist richtig? 3. Offenbar wird ein Channel-Hopping über 5 Kanäle genutzt. Laut Wiki ist der Sendekanal des nrf24l01+ auf 40 = 2040 MHz festgelegt und es wird nur der Empfangskanal gewechselt. Ist das so OK? Wann wird der Kanal gewechselt? Nur, wenn keine Antwort kommt oder regelmäßig nach jeder Abfrage? Vielen Dank!
Hallo Fritz! Es ist schon fast ein Jahr her, dass ich mich mit den Einzelheiten befasst habe, deshalb alles ohne Gewähr: zu 1. Ich glaube ja (ob das auch bei meinem Micropython-Code funktioniert, weiß ich nicht). zu 2. Ich glaube 0x7e (start of frame, sof) und 0x7f (end of frame, eof) ist in den Daten, die man schickt bzw. erhält nicht enthalten; die sieht man nur, wenn man den Funkverkehr abhört (mit Sniffer?). zu 3. Ein Zitat aus dem wiki: "zu den genutzten Frequenzen. Bei meinem HM-600 ist es immer so: Wenn ich ein 80 Telegramm sende auf 2403, dann antwortet der WR mit den Antworten 01,02,83 auf den möglichen Frequenzen 2423,2440,2461 MHz. also bei TX 2403, Antworten auf 2423,2440,2461 bei TX 2423, Antworten auf 2403,2440,2475 bei TX 2440, Antworten auf 2403,2423,2475 bei TX 2461, Antworten auf 2403,2423,2475 bei TX 2475, Antworten auf 2403,2423,2440 Wenn man die möglichen Frequenzen scannt nach dem Senden, dann empfängt man alle Antworten. Andere Antworten als 01,02,83 habe ich bisher nie empfangen." Heißt also: Man kann auf allen 5 Kanälen senden, die Antwort kommt dann auf einem von drei anderen Kanälen. Auf welchem ist meines Wissens zufällig. Also z.B. Senden auf Kanal 3 ergibt eine Antwort auf Kanal 23 oder 40 oder 61. Viel Erfolg!
Fritz G. schrieb: > 3. Offenbar wird ein Channel-Hopping über 5 Kanäle genutzt. Laut Wiki > ist der Sendekanal des nrf24l01+ auf 40 = 2040 MHz festgelegt und es > wird nur der Empfangskanal gewechselt. Ist das so OK? Wann wird der > Kanal gewechselt? Nur, wenn keine Antwort kommt oder regelmäßig nach > jeder Abfrage? Hallo Fritz, ich hatte weiter oben schon mal spekuliert, dass das Channel Hopping dem Gazelle Link Layer von nRF entspricht und mit dem nRF24L01 nur pseudomäßig nachgebildet werden kann. Siehe hier: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Vielleicht hilft dir das weiter?
Ich habe für ein privates Projekt die Daten von meinem Wechselrichter mit einem Raspberry PI ausgelesen. Falls jemand das gleiche Anliegen hat, hier ist der Sourcecode: https://github.com/bri1234/Hoymiles-HM-RaspberryPI Es ist in Python (mit typehints) programmiert mit Schwerpunkt auf einfacher Verwendung, guter Lesbarkeit und guter Dokumentation des Sourcecodes.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.