Announcement: there is an English version of this forum on 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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.