Forum: Mikrocontroller und Digitale Elektronik Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Sorbit (Gast)


Lesenswert?

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)?

von Claus T. (Gast)


Lesenswert?

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?

von H. E. (h_e)


Lesenswert?

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.

von Marcel S. (Gast)


Lesenswert?

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?

von Dirk S. (fusebit)


Lesenswert?

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.

von Sigi S. (sermon)


Lesenswert?

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).

von Dirk S. (fusebit)


Lesenswert?

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.

von Sigi S. (sermon)


Lesenswert?

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;-)

von Dirk S. (fusebit)


Angehängte Dateien:

Lesenswert?

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
von Sigi S. (sermon)


Lesenswert?

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.

von Ralf B. (ralf_b210)


Lesenswert?

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)

von Andi (Gast)


Lesenswert?

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

von Sorbit (Gast)


Lesenswert?

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

von Hfhausen (Gast)


Lesenswert?

Einfach mal eine Seite zurück blättern und lesen. Irgendwo dazwischen 
gibt es die Hinweise.

von Andi (Gast)


Lesenswert?

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.

von oxylog (Gast)


Lesenswert?

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

von Sigi S. (sermon)


Lesenswert?

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
von Andi (Gast)


Lesenswert?

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.

von Andi (Gast)


Lesenswert?

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

von M. P. (matze7779)


Angehängte Dateien:

Lesenswert?

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?

von Gerri (Gast)


Lesenswert?

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?

von Thomas Korner (Gast)


Lesenswert?

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

von Ralla66 (Gast)


Lesenswert?

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.

von Andi (Gast)


Lesenswert?

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.

von Guido (Gast)


Lesenswert?

Moin, sag mal hast Du noch 1 - 2 Platinen ESP-DTU ?

von Ralla66 (Gast)


Lesenswert?

@ Andy
Leistungsbegrenzung senden ist gemeint

von Claus T. (Gast)


Lesenswert?

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.

von tastendruecker (Gast)


Lesenswert?

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.

von Jerry (Gast)


Lesenswert?

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

von tastendruecker (Gast)


Lesenswert?

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.ä.)

von Claus T. (Gast)


Lesenswert?

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.

von Andi K. (fujin)


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

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. :)

von Sigi S. (sermon)


Lesenswert?

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?!

von Sigi S. (sermon)


Lesenswert?

Entwarnung, gefunden!

von Andi (Gast)


Lesenswert?

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

von Hubert (Gast)


Lesenswert?

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?

von Herbert S. (herbert_s445)


Lesenswert?

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

von Dirk S. (fusebit)


Lesenswert?

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"

von Friedrich (Gast)


Lesenswert?

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!

von Hubert (Gast)


Lesenswert?

Danke!

von Claus T. (Gast)


Lesenswert?

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.

von tastendruecker (Gast)


Lesenswert?

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.

von isnoahoy (Gast)


Lesenswert?

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

von Günter H. (gnter_h534)


Lesenswert?

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".

von Andreas (dicc)


Lesenswert?

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

von Reinhard (sym)


Lesenswert?

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?

von Andreas (dicc)


Angehängte Dateien:

Lesenswert?

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
von Günter H. (gnter_h534)


Lesenswert?

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.

von Boris J. (sivar2311)


Lesenswert?

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)

von Andreas S. (drschiffler)


Lesenswert?

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

von wr (Gast)


Lesenswert?

@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

von Reinhard (sym)


Lesenswert?

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?

von Ralla66 (Gast)


Lesenswert?

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 ?

von Günter H. (gnter_h534)


Lesenswert?

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.

von Reinhard (sym)


Lesenswert?

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.

von tastendruecker (Gast)


Lesenswert?

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.

von Sermon (Gast)


Lesenswert?

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

von Sermon (Gast)


Lesenswert?

FW ist 5.15

von Andreas (dicc)


Lesenswert?

Die Seriennummer beim Setup > Adresse
Der Empfänger darf nicht zu weit vom Inverter sein!

von Sermon (Gast)


Lesenswert?

Die Seriennummer ist korrekt und die Visualisierung zeigt auch 
„Produktion“, trotzdem die Fehlermeldung

Beitrag #7169599 wurde vom Autor gelöscht.
von Ha F. (harry_f)


Lesenswert?

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.

von Martin Ecker (Gast)


Lesenswert?

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.

von Andreas (dicc)


Lesenswert?

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

von Herbert S. (herbert_s445)


Lesenswert?

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

von Andi K. (fujin)


Lesenswert?

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.

von Andreas S. (drschiffler)


Lesenswert?

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

von Sorbit (Gast)


Lesenswert?

„Danach die aktuellste *.bin - Datei flashen.„

Könnte einer der Entwickler uns erhellen?

Irgendwas stimmt nicht, aber was?

von tastendruecker (Gast)


Lesenswert?

Sorbit schrieb:
> „Danach die aktuellste *.bin - Datei flashen.„
>
> Könnte einer der Entwickler uns erhellen?
>
> Irgendwas stimmt nicht, aber was?

Worüber denn?

von Sorbit (Gast)


Lesenswert?

Worüber denn?


Worüber wohl, nicht im Thema?!

von tastendruecker (Gast)


Lesenswert?

Ich verstehe nach wie vor nicht, über was du erhellt werden möchtest. 
Und der Ton ist ebenfalls befremdlich.

von Johannes (derfrickler)


Lesenswert?

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

von Highlander (Gast)


Lesenswert?

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.

von Normen (burn)


Lesenswert?

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?"

von Johannes (derfrickler)


Lesenswert?

Ja, seiner hat auch ne 114173307xxx Seriennummer, meiner eine mit 1041 
startende...

von Sören S. (sren_s)


Angehängte Dateien:

Lesenswert?

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?

von Hans W. (hans_w801)


Angehängte Dateien:

Lesenswert?

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"

von OlaLu (Gast)


Lesenswert?

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.

von Basti (Gast)


Angehängte Dateien:

Lesenswert?

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

von Dirk Z. (dirk007)


Lesenswert?

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 ;-) ?

von Frank R. (Gast)


Lesenswert?

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.

von Thomas B. (tbnobody)


Lesenswert?

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.

von Andreas (andic)


Lesenswert?

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

von Jörg R. (Gast)


Lesenswert?

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.

von OlaLu (Gast)


Lesenswert?

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!

von Andreas (dicc)


Lesenswert?

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

von Lukas P. (lumapu)


Lesenswert?

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.

von Andreas (dicc)


Lesenswert?

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!

von Günter H. (gnter_h534)


Angehängte Dateien:

Lesenswert?

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.

von Lukas P. (lumapu)


Lesenswert?

> 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.

von Andreas (dicc)


Lesenswert?

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!?

von Reinhard (sym)


Lesenswert?

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!

von Basti (Gast)


Lesenswert?

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

von Matthias (Gast)


Lesenswert?

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)."

von jnz (Gast)


Lesenswert?

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)

von D. J. (basteldag)



Lesenswert?

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.

von Sören S. (sren_s)


Lesenswert?

Jetzt mal doof gefragt, was ist denn die IP des Brokers bei Home 
Assistant?

von DaAlchemist (Gast)


Lesenswert?

@ 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.

von Steffen D. (steffen_d)


Lesenswert?

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.

von Günther T. (brachykykloma)


Lesenswert?

Hallo miteinander!
Alle Achtung für Euer ambitioniertes Projekt!
Bin seit >30a HW-Entwickler & weiß zu schätzen, was Ihr da leistet!
LGG

von Johannes (derfrickler)


Lesenswert?

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.

von Jörg R. (Gast)


Lesenswert?

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...

von Johannes (derfrickler)


Angehängte Dateien:

Lesenswert?

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
von jnz (Gast)


Lesenswert?

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

von Klaus (Gast)


Lesenswert?

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.

von Sören S. (sren_s)


Lesenswert?

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
von Johannes (derfrickler)


Lesenswert?

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

von Jörg R. (rejoe2)


Angehängte Dateien:

Lesenswert?

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ä.).

von jnz (Gast)


Lesenswert?

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.

von Johannes (derfrickler)


Lesenswert?

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

von Ziyat T. (toe_c)


Lesenswert?

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.

von Jörg R. (rejoe2)


Lesenswert?

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.

von Johannes (derfrickler)


Lesenswert?

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
von Jörg R. (rejoe2)


Lesenswert?

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
von Ziyat T. (toe_c)


Lesenswert?

@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
von Jörg R. (rejoe2)


Lesenswert?

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
von Andreas B. (Gast)


Lesenswert?

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... :( ;)

von peter (Gast)


Lesenswert?

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.

von Ziyat T. (toe_c)


Lesenswert?

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

von Jörg R. (rejoe2)


Lesenswert?

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.

von Johannes (derfrickler)


Lesenswert?

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

von Andi (chello)


Angehängte Dateien:

Lesenswert?

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:

von Ziyat T. (toe_c)


Lesenswert?

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

von Jörg R. (rejoe2)


Lesenswert?

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...

von Günter H. (gnter_h534)


Lesenswert?

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".

von Ziyat T. (toe_c)


Lesenswert?

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?

von Jörg R. (rejoe2)


Lesenswert?

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
von Jörg R. (rejoe2)


Lesenswert?

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
von J. S. (jojos)


Lesenswert?

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
von Ziyat T. (toe_c)


Lesenswert?

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

von Andi (chello)


Lesenswert?

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
von Jörg R. (rejoe2)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

Erase Settings und dann nochmal neu eintragen.

von Andi (chello)


Lesenswert?

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 ?

von J. S. (jojos)


Lesenswert?

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.

von Normen (burn)


Lesenswert?

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!

von solaris (Gast)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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
von DaAlchemist (Gast)


Lesenswert?

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ß

von Jens (Gast)


Lesenswert?

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

von Andreas S. (drschiffler)


Lesenswert?

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

von Ralla66 (Gast)


Lesenswert?

Hi, teste gerade die 0.5.16
Wurde das automatische erstellen von Datenpunkten im Mqtt Broker hier 
devcontrol schon eingepflegt ?

von Jens (Gast)


Lesenswert?

Wow, dass ging flott.

Vielen lieben Dank.

Dann wurschtel ich mich da mal durch.

von Dirk Z. (dirk007)


Lesenswert?

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 ?

von Ralla66 (Gast)


Lesenswert?

Devcontrol Datenpunkte wurden bei mir nicht angelegt.
Habe mit einem Mqtt Explorer die Datenpunkt per Hand angelegt und 
Powerlimit vorgegeben, lief.

von J. S. (jojos)


Lesenswert?

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.

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

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.

von Oswald S. (obmaroszi)


Angehängte Dateien:

Lesenswert?

Also bei mir läuft die 5.16 auf 8266 und ESP32 stabil
anbei die 5.15

: Bearbeitet durch User
von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

Danke dir.
Die Leistungslimitierung wird nicht mehr richtig angezeigt.

von Oswald S. (obmaroszi)


Lesenswert?

tatsächlich
betreibe ihn ohne Leistungslimitierung  deshalb nicht afgefallen

von Andreas S. (drschiffler)


Lesenswert?

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

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

@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?

von Christian O. (ottelo)


Lesenswert?

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?

von Hans W. (hans_w801)


Lesenswert?

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.

von M. P. (matze7779)


Lesenswert?

Hallo,

was bedeuten eigentlich die Werte:
Pct
P_ACr

von Thomas B. (Gast)


Lesenswert?

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.
von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

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.
von Grisu (krisu)


Lesenswert?

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!

von Gutmensch (Gast)


Lesenswert?

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?

von M. P. (matze7779)


Lesenswert?

Danke @ Grisu

von Normen (burn)


Lesenswert?

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

von Grisu (krisu)


Lesenswert?

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
von misch (Gast)


Angehängte Dateien:

Lesenswert?

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

von Günter H. (gnter_h534)


Lesenswert?

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
von Thorsten (koerly)


Angehängte Dateien:

Lesenswert?

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

von misch (Gast)


Lesenswert?

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 !!!

von Grisu (krisu)


Lesenswert?

misch schrieb:

> wollte die Version 05.15 flashen

Solltest vielleicht gleich die aktuelle 5.16 nehmen.

: Bearbeitet durch User
von Eike (eike_l)


Lesenswert?

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
von Grisu (krisu)


Lesenswert?

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
von isnoAhoy (Gast)


Lesenswert?

@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.

von Jörg R. (rejoe2)


Lesenswert?

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.

von David B. (mystisch)


Lesenswert?

Hallo zusammen,
wurde die HI version (habe selbst HI-600) jetzt schon testweise in das 
AHOI DTU eingebaut oder noch nicht?

von Jörg R. (rejoe2)


Lesenswert?

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
von David B. (mystisch)


Lesenswert?

okay, das werde ich machen. melde mich mit resultaten.

von Grisu (krisu)


Lesenswert?

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
von Jörg R. (rejoe2)


Lesenswert?

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.

von Carsten B. (carstenb)


Lesenswert?

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

von Jumper (Gast)


Lesenswert?

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.
von Carsten B. (carstenb)


Lesenswert?

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...

von David B. (mystisch)


Lesenswert?

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.

von Jörg R. (rejoe2)


Lesenswert?

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.
von tiny (Gast)


Lesenswert?

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

von Rene M. (Firma: Bitte wählen) (renmo)


Lesenswert?

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.

von David B. (mystisch)


Lesenswert?

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

von Jörg R. (rejoe2)


Lesenswert?

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.

von David B. (mystisch)


Lesenswert?

Hey Jörg,
ioBroker nutze ich.
Jetzt ruft erst mal das Mittelalter :-).
Ich teste Sonntag wieder. Dank Dir soweit und ein schönes Wochenende.

von Ziyat T. (toe_c)


Lesenswert?

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

von Ziyat T. (toe_c)


Lesenswert?

Günter H. schrieb:
> Das Limit (dunkelgrüne Zeile ganz oben) scheint auf "0 Watt" eingestellt

das ist sehr aufmwerksam! super!

von co3 (Gast)


Lesenswert?

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

von Drazen K. (rewop)


Lesenswert?

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

von Jörg R. (rejoe2)


Lesenswert?

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"?

von Ziyat T. (toe_c)


Lesenswert?

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)

von Ziyat T. (toe_c)


Lesenswert?

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
von Ziyat T. (toe_c)


Lesenswert?

wer zu wissen möchte,
reaktionszeit eines MI1550 auf cmd=0x51 (0x5A5A, limit)  etwa 20sek

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.