Wechselrichter Hoymiles HM-600 mit FHEM verbinden anstelle mit WLAN Stick DTU-W1

[kabanett]

Die zuletzt von Beta-User bereitgestellte Version 0.5.13 ist nach der Installation pauschal schon auf 5 Sekunden eingestellt.
Ich habe diese ersteinmal auf 15 Sekunden hochgesetzt, da ich so viel Daten und Traffic nicht haben möchte und überlege den Intervall noch weit aus höher zu setzen.

Wo liegt denn der Vorteil, Daten so häufig zu bekommen?

[TheTrumpeter]

Wo liegt denn der Vorteil, Daten so häufig zu bekommen?

Smartmeter und Wechselrichter werden asynchron abgefragt, um den tatsächlichen Strombedarf zu ermitteln. Je höher die Abfrageintervalle sind, desto größer kann der Fehler sein.

Wenn sich die Daten nur minimal ändern, fange ich das über "event-on-change"-Attribut ab, sodass die Datenflut "unsichtbar" bleibt.

[Beta-User]

a) Es gibt "schon wieder" ein update des "interver"-attrTemplate (für die diversen neuen limit-Varianten).
b) Habe ich arge Zweifel, ob ein update-Interval <5 aus technischen Gründen auf der ESP-Seite sinnvoll ist: Je Kanal braucht es (mind.) eine Message von Seiten des WR. Die muss angefragt werden. Kommt eine der beiden Messages (Anfrage+Antwort) nicht an, ändert sich so oder so nichts, und wieder ist eine Sekunde um. Weiß aber (noch) nicht, ob das Intervall nicht auch Einfluss darauf hat, wann der ESP versucht, wieder eine neue "Kollekte" zu starten... Ist letzteres der Fall, wäre die kürzere Anfrage kontraproduktiv.

MAn. müßte man ggf. mal prüfen, ob man nicht bestimmte Hysterese-Prüfungen nicht direkt auf dem ESP erledigen könnte und dafür ggf. kurzfristige Messages versendet, falls sich was gravierendes ändert. Wenn man z.B. 2 Minuten einstellt, und es schiebt sich eine Wolke dazwischen, ist das auch nach 10 Sekunden nach dem letzten Senden interessant...

[TheTrumpeter]

b) Habe ich arge Zweifel, ob ein update-Interval <5 aus technischen Gründen auf der ESP-Seite sinnvoll ist: Je Kanal braucht es (mind.) eine Message von Seiten des WR. Die muss angefragt werden. Kommt eine der beiden Messages (Anfrage+Antwort) nicht an, ändert sich so oder so nichts, und wieder ist eine Sekunde um. Weiß aber (noch) nicht, ob das Intervall nicht auch Einfluss darauf hat, wann der ESP versucht, wieder eine neue "Kollekte" zu starten... Ist letzteres der Fall, wäre die kürzere Anfrage kontraproduktiv.

Erstmal will ich nur die 5s wieder haben, was ich jetzt auch eingestellt habe, um zu prüfen, ob die neue Version tatsächlich "stabiler" in Hinblick auf die unmotivierten Reboots ist oder es einfach eine Begleiterscheinung der längeren Intervalle war/ist.

MAn. müßte man ggf. mal prüfen, ob man nicht bestimmte Hysterese-Prüfungen nicht direkt auf dem ESP erledigen könnte und dafür ggf. kurzfristige Messages versendet, falls sich was gravierendes ändert. Wenn man z.B. 2 Minuten einstellt, und es schiebt sich eine Wolke dazwischen, ist das auch nach 10 Sekunden nach dem letzten Senden interessant...

Die Frage ist, wie der ESP das machen soll. Um die "Wolke" zu erkennen, muss er ja erst Recht in kurzen Intervallen abfragen. Ob der WR dann die "Filterung" übernimmt und bei geringer Änderung gar nicht erst an FHEM sendet oder das FHEM im Nachgang übernimmt, ist bzgl. Deiner obigen Bedenken doch erstmal egal.

Wenn man das Abfragen "von außen anstoßen" könnte, würde die Welt schon ganz anders ausschauen. Ich habe beispielsweise an der Beschattungssteuerung einen Lichtsensor, den ich auch abfrage. Ich könnte dann bei sprunghafter Änderung des Helligkeitswerts eine "Sonderabfrage" anstoßen. (Zwar müsste ich dann dort das Einleseintervall deutlich erhöhen, aber da die Beschattungssteuerung jede Änderung ohnehin auf den Bus legt, müsste ich das Abtastintervall einfach nur verringern.)
Wenn man keinen Lichtsensor hat, könnte man diverse andere Datenquellen verwenden, entweder den aktuellen Einspeisewert vom Smartmeter oder die Stromstärker des Außenleiters auf dem die PV-Anlage hängt. Man könnte auch eine Zwischensteckdose mit Strommessfunktion verwenden, aber dann hat man die Leistung ohenhin schon, wozu braucht man dann noch die weiteren Werte?

[Beta-User]

Erstmal will ich nur die 5s wieder haben, was ich jetzt auch eingestellt habe, um zu prüfen, ob die neue Version tatsächlich "stabiler" in Hinblick auf die unmotivierten Reboots ist oder es einfach eine Begleiterscheinung der längeren Intervalle war/ist.

Das wäre eher eine Frage im Zusammenhang mit "Last Will" und/oder der Überwachung eines uptime-Readings oä..

Die Frage ist, wie der ESP das machen soll. Um die "Wolke" zu erkennen, muss er ja erst Recht in kurzen Intervallen abfragen. Ob der WR dann die "Filterung" übernimmt und bei geringer Änderung gar nicht erst an FHEM sendet oder das FHEM im Nachgang übernimmt, ist bzgl. Deiner obigen Bedenken doch erstmal egal.

Es "muss" m.E. nicht unbedingt in kurzen Intervallen abfragen, sondern es sollte berücksichtigt werden, ob der WR eigentlich schon bereit sein kann. Wenn alles sehr gut synchronisiert ist, sollte es möglich sein, tatsächlich alle 5 Sekunden Daten zu erhalten, die unterhalb dieser Schwelle vom WR gesendet worden waren.

Aber im Prinzip tut man gut daran, sowohl den ESP "werkeln" zu lassen wie auch den WR dann Daten senden zu lassen, wenn grade die passende Zeit dafür ist...

[TheTrumpeter]

Erster Reboot nach ca. 3,5h. Kann natürlich Zufall gewesen sein, aber daran glaube ich eher nicht.
Muss dann noch dem Code durchschauen, weil ich sehen will wie die "Max retries per payload" genau verwendet werden. "0" nimmt er dort nicht, drum vermute ich, dass es keine Wiederholanzahl sondern Gesamtsendeanzahl darstellt. Falls es doch die Wiederholungen sind, könnte ich die natürlich auf "0" setzen.
Umgekehrt scheint grundsätzlich nicht viel verloren zu gehen, weil "receive fail" tagsüber sehr klein ist.

[rih]

Hallo,
zunächst mal vielen Dank @Beta-User für die Bereitstellung der Firmware. Als quasi Neueinsteiger benötige ich leider eure Hilfe dazu.
Ausgangslage: ich habe einen HM-350. Diesen konnte ich bisher mit der AHOY-DTU-Firmware 0.4.25 erfolgreich auslesen und die Werte in FHEM per MQTT2_Device darstellen.

Nun bin ich auf diesen Thread gestoßen. Da ich die Begrenzung der Ausgangsleistung gut gebrauchen könnte, habe ich 2 der Firmware-Versionen herunter geladen: 0.5.10 und 0.5.14. Die letzte Version läuft leider nicht, keine Verbindung möglich.
Die 0.5.10 läuft. Im Setup die gleichen Daten eingegeben wie beim bisherigen Device. Neustart. Werte vom HM-350 treffen im MQTT2-Device ein. Sah also gut aus.
Dann habe ich das Template hoymiles_microinverter_hub_bridge angewendet. Danach hatte ich 2 MQTT2-Devices: MQTT2_AHOY_DTU (Hub) und MQTT2_PV_Batterie_HM_350 (Device). Die Inverter-Daten kommen im Device an. Sieht meiner Meinung nach gut aus.

Jetzt die Fragen:
1. Wie stelle ich nun das Power-Limit ein? Im Setup (Web-Interface) gibt es zwar ein Feld dafür, aber mein dort gemachter Eintrag wird ignoriert. Im FHEM-Device kan ich weder per set ... noch per Attribut ein Limit eingeben.
2. Muss ich das 2. Template (hoymiles_microinverter_inverter) anwenden? Wenn ja, worauf? Allerdings sehe ich dort auch nichts von einem Power-Limit in den setlists.
3. Kann es sein, dass die Version 0.5.10 das Limit noch nicht kann?
4. Warum wurden nun alle Versionen zwischenzeitlich gelöscht? Hätte gerne die 0.5.11, 12, 13 probiert.
5. Kann es sein, dass mein HM-350 das Power-Limit nicht beherrscht?
6. Mein FHEM ist nicht auf dem letzten Stand. Habe lediglich das mqtt2_template auf den neuesten Stand gebracht. Spielen eventuell noch andere Module / Libs eine Rolle in diesem Zusammenhang (Power-Limit)?

Wäre nett, wenn ihr mir helfen könntet.

[Beta-User]

Mobile kurz-antwort:
Das 2. attrTemplate hat setList für ab 0.5.14 und muss auf das 2. automatisch angelegte Device.
Gelöscht ist das alte Zeug, da veraltet. Da ich im Moment nicht die actions aktuell halten kann, müsst ihr das anderweitig lösen.
Sonstiges FHEM muss nicht ganz so aktuell sein.

[Tobias]

Dumm gefragt trotz suchen im Thread: wo finde ich denn Beta-Users Firmware?

[TheTrumpeter]

Dumm gefragt trotz suchen im Thread: wo finde ich denn Beta-Users Firmware?

Im Github, Link ist im Mikrocontroller-Forum.

[Beta-User]

Ist nur nicht meine. Oder suchst du was für MI-Modelle?

[Tobias]

Ich habe 2x HM-1500 und einen HM-700

Bis jetzt messe ich nur den Ertrag über jeweils einen Shelly 1PM.

Könnte jemand den Link zum repo posten? Der Microcontroller Thread ist Kilometerlang

[TheTrumpeter]

Könnte jemand den Link zum repo posten? Der Microcontroller Thread ist Kilometerlang

https://github.com/grindylow/ahoy

[sprudelverduenner]

Hallo FHEMler,


ich bekomme zeitnah 2 x Hoymiles HM-800 und wollte diese in FHEM integrieren und verfolge dementsprechend diesen Thread.

Ich habe eine NodeMCU und das Funkmodul - allerdings noch nicht verlötet.
Ich wollte als 1. Schritt die Firmware auf den ESP32 flashen und die NodeMCU ins WLAN bringen.

Und hier scheitere ich bereits.
Ich habe versucht mit Visual Studio Code das Projekt von Github selber zu kompilieren.
Egal was ich mache - ich flashe die kompilierte .bin auf die Node MCU und es zeigt sich kein AP.

Ich sehe weder hier noch auf Github auch keine fertige BIN.
Wahrscheinlich ich habe riesengroße Tomaten auf den Augen.

Könnt Ihr mir einen Anstoss geben ??
Oder Geht die Firmware auf der NodeMCU gar nicht weil beim Start der Firmware das Funkmodul abgefragt wird ??

Besten Dank vorab,
Sprudelverduenner

[TheTrumpeter]

Egal was ich mache - ich flashe die kompilierte .bin auf die Node MCU und es zeigt sich kein AP.

Mach' doch mal die serielle Konsole auf und schau' was sich dort tut. Ich hatte bei manchen Versionen auch das Problem, dass der AP nicht aufging. In der seriellen Konsole habe ich dann gesehen, dass sich das Ding permanent mit einem kryptischen WLAN verbinden wollte, aber keinen AP geöffnet hat.

Oder Geht die Firmware auf der NodeMCU gar nicht weil beim Start der Firmware das Funkmodul abgefragt wird ??

Zumindest der 0.4.x war das egal.

Anbei die 0.4.25 für NodeMCU von mir übersetzt. NodeMCU habe ich selbst nicht ausprobiert, aber die Version für D1-mini läuft.