Hoymiles Firmware 2.0.4 und die hängende Regelung

[synack666]

Mich interessiert wie es bei anderen ist die einen HMS1600 4T mit Firmware 2.0.4 haben.

Auch mit der aktuellen Version hängt die Regelung immer wieder mal, nach einem reboot der DTU funktioniert es eine Zeit prima.

Was ich beobachtet habe ist das wenn Limit 624 angezeigt wird auch oft das "hängen" ist.

Im Screenshot wird nicht hoch geregelt, Sonne ist für >1000 Watt vorhanden.
Nach einem reboot wieder für (unterschiedlich lang) alles wie es soll.

Ist es die FW 2.0.4 im WR?
Da könnte ich ja versuchen einen downgrade zu bekommen.

Funktioniert es bei euch? Also mit diesem WR/FW?

[AndreasBoehm]

Mit FW 2.0.4 haben viel User von Problemen berichtet. Ich selbst konnte es noch nicht probieren.

Wenn du dir die Leistung der Eingänge im Verhältnis zum gesetzten Limit anschaust, wirst du sehen das keiner der Eingänge dem Limit enspricht, alle Eingänge lieferen zu wenig, daher gehen wir davon aus das ein erhöhen des Limits nicht mehr Leistung bringen wird.

[synack666]

Das Limit bleibt auf irgendeinem Wert stehen den es hatte, die Anzeige geht auf die 624 und es ändert sich nichts mehr.
Nach einem reboot passt das angezeigte Limit und es wird brav geregelt, eigentlich sogar sehr gut.
Das funktioniert dann mal 20 Minuten aber auch mal den halben Tag.

Wenn die FW im WR das Thema ist dann ist es mir unverständlich warum es teilweise gut funktioniert oder warum ein reboot es wieder ans laufen bekommt, also nur DTU reboot. Aber ist steck da auch nicht wirklich tief drin.

Ich werde mich dann mal Dienstag um ein FW downgrade bemühen. 1.01.12 ist OK?

[thopfei]

Ich habe an meinem HMS-1600 (FW 2.0.4) beobachtet, dass er nachts im ca. 4 Minuten-Takt auf 1600 Watt springt, obwohl ich in den Einstellungen 1497 W als Limit gesetzt habe. Da bleibt er dann bei 1600 W und der B2500 entlädt sich unkontrolliert. Wenn die 1600 W über MQTT gemeldet werden, schicke ich über eine Home-Assistant-Automation 320 W als temporäres Limit. Das ist nachts die benötigte Maximalleistung und dann läuft die Nullregelung wieder zum nächsten 1600-Watt-Event. Das ist schon merkwürdig, aber ich kann derzeit damit leben.

[synack666]

Interessanter Ansatz, regelt DPL zu selten schläft es ein.
Hab meine Hysterese jetzt von 60 auf 10 geändert und beobachte das mal.
@thopfei
HA läuft hier auch, wie machst du das mit dem Limit setzen?

[thopfei]

@thopfei HA läuft hier auch, wie machst du das mit dem Limit setzen?

Ich habe einen Kominationssensor Hausverbrauch definiert, der den Netzbezug des Tasmota-IR-Kopf und die HMS-1600-4T-Erzeugung addiert.

Automation:
Sobald: HMS-1600-4T Limit NonPersistent Absolute über 1499 ist
Und wenn: Wenn Hausverbrauch unter 1500 ist
Dann

• Gerät: HMS-1600-4T
• Aktion: Stelle den Wert für HMS-1600-4T Limit NonPersistent Absolte ein
• Wert 320

Wenn der Hausverbrauch über 1500 ist, korrigiere ich nicht auf 320 W.

Eigentlich sollte ich als Korrekturwert einfach den Hausverbrauch setzen, das geht aber nicht über die GUI. Das in automation.yaml direkt einzutragen, werde ich später mal machen, Derzeit reicht mir der Quickhack.

[knotzebom]

Das mit den 4 Minuten hat vermutlich etwas mit einem Telegram vom Umrichter zur DTU zu tun. Auch wenn man im Webserver das Limit setzen will, steht was von 4 Minuten bis es angezeigt wird. In HA ab ich ganz Simpel wenn das Limit größer 800W dann setze neues Limit 250W. Im DPL hab ich als Max 800 Watt eingestellt.

[vanson77]

Habe das genauso, Ich nenne es liebevoll den 4min/100% Bug ;)
Wie von konotzebom eingangs beschrieben, wenn sich DPL 4min nicht ändert dann geht sie auf 100%, weitere DPL Änderungen werden ignoriert. Ich helfe mit mit einer HA Regel ab, die solche Fälle nach 15s auf meinen Grundumsatz vom 80W (5%) runterregelt, dann läuft die DPL wieder. Sieht man schön am Screenshot.
Ändert man die Hysterese auf einen entsprechend kleinen Wert, sodass sich die DPL ständig ändert, dann tritt dieses Verhalten nicht bzw. nicht so häufig auf.

[Gururom]

Also ich nutze einen hms-1600 mit zwei marstek V1 den WR mit der 1.0.27. Wenn ich mich nicht irre, jedenfalls mit der alten Version und all die Probleme habe ich nicht.
Kleinere andere Probleme ja, zbsp das zu 100 % volle Akkus oftmals schwer den WR starten.
Aber schlechtes rgfelverhalten und unkontrolliertes hochfahren jedenfalls nicht.
Nutze kein MQTT obwohl ich manchmal auf die Idee kommen könnte

[synack666]

Die Automation in HA bau ich mir auch, danke für die Infos dazu.

Bleibt die Frage ob es dem WR anzulasten ist oder der DTU?

[AndreasBoehm]

Ich würde sagen das die DTU die neue WR Firmware schlichtweg nicht unterstützt. :)

[AndreasBoehm]

Hier wurde das Problem schon mal erörtert: tbnobody#2501 (reply in thread)

[knotzebom]

Hi, mit dem veränderten Kommando an den Wechselrichter in v2.04 hat das nichts zu tun?
tbnobody#2153 (comment)

[AndreasBoehm]

#1571 (comment)

Du kannst mal das build probieren, da hab ich das command angepasst.

[knotzebom]

Scheint zu funktionieren. Seit 10 Minuten bleibt das letzte gesetzte Limit aktiv. Er regelt auch einen String sofort hoch, wenn ein Akku dazu kommt und bleibt nicht bei kleiner Leistung bis ein neues Limit gesetzt wird.
Welche Kommandos wurden geändert? Alle oder nur nonpersistant?
Edit selbst gefunden.
Mit dem Build hab ich aber Probleme mit der Verbindung. Es kommt zu Fragment Wiederanforderungen. Dies hatte ich vorher nicht.
Im Log steht was von Middle missing request retransmit 6
Im Log des Wechselrichters steht nun sehr oft Zeitabgleich.
Basiert der Build auf der aktuellsten Version?

[AndreasBoehm]

Jap, basiert auf der aktuellsten Version.
Verbinundgsprobleme haben damit nichts zu tun. Die kommen einfach aus dem nichts.
Paar mal rebooten bis es wieder passt sollte klappen, zumindest aus meiner erfahrung.

[synack666]

Hab es jetzt auch drin, eigentlich wollte ich was anderes machen...
Bisher ist die Funkstatistik wie immer, Regelung muss ich warten bis mal Sonne da ist.

[knotzebom]

Hab den Backofen und oder das Kochfeld in Verdacht. Die schalten gerade an und aus. Warte mal bis das Essen fertig ist.

[vanson77]

Läuft auch bei mir einwandfrei, das 100% Problem ist auch bei mir damit behoben. Vielen Dank!

[AndreasBoehm]

Ich hab alle Commands angepasst, also non-persistent und persistent, konnte es aber noch nicht testen.
Hier findet ihr die neue Test-Version: #1571 (comment)

[knotzebom]

Super vielen Dank. Ich kann es leider erst am Wochenende testen.

[synack666]

Ich nutze nur non-persistent, dann ist testen Sinnfrei oder?

Ansonsten weiterhin einwandfrei!

[schlimmchen]

Doch, trotzdem sinnvoll.

[vanson77]

Also bei mir funktioniert auch die neue Testversion seit 3d einwandfrei, nutze aber auch nur non-persistent.
Habe trotzdem mal getestet wie sich (bei deaktiviertem DPL) peristent und non-persistent bei mir verhalten: ändere ich ein Limit ändert sich das andere mit, sind also beide synchron. Aber wie gesagt ich nutze es eigentlich nicht, von daher...
Eigentlich kann ich keinen Unterschied zwischen beiden Versionen feststellen.

[knotzebom]

Wie soll ich denn das Limit persistent setzen? Per Webui oder MQTT?

[stegbth]

Hi @synack666 ,
bei mir laeuft ein HMS1800-4T mit Firmware 10012 (vermutlich 1.00.12?) und habe mit dem DPL auch diese Probleme noch nicht gesehen.
Lt. MQTT und Grafana haengt das auch nicht.

Aber noch eine andere Frage:

1. wie hast Du die Firmware aktualisiert?
2. wie kannst Du die Firmware wieder downgraden?

vg
Thomas

[synack666]

Up/downgrade geht vie Hoymiles Support mit org. DTU, in der Gui gibt es einen Knopf für Support, ein chat, da habe ich meinen Wunsch formuliert und mein Gesprächspartner ist dem nachgekommen.

[AndreasBoehm]

@stegbth wenn alles ohne Probleme läuft einfach die aktuelle Firmware so lassen wie sie ist.

[AndreasBoehm]

Bitte nutzt vorerst wieder die Release Version, aktuell sind alle Limits persistent mit der Test Version.

[synack666]

Bin grad zurück auf die 1.1.12 und beobachte.

[knotzebom]

Hab seit heute morgen Fehler 62 im Status. 62 System configuration parameter error
Ist dies bei dir auch?

[synack666]

Ne, bisher alles bestens.
Ich hatte nach dem downgrade alles durchgebootet, keine Ahnung ob das einen Unterschied macht.

[knotzebom]

Hmm der Fehler steht auch nur in der OpenDTU. In der Cloud ist kein Fehler.

[synack666]

So, inzwischen kann ich sagen, alle Probleme wie weggeblasen, der umstieg auf 1.1.12 hat es bei mir gebracht.

[guenni26]

Moin, bei mir hat das Downgrade auf 01.00.27 nichts gebracht. Mit der DTU- Vers. 2025.04.17 blieben die Hänger. Habe dann die DTU-Vers. 2024.09.11 wieder eingesetzt. Seit dem läuft es wieder problemlos.

[Higgy112]

Hallo, ich habe mit meinem Hoymiles HMS 1600 4T V. 2.0.4 auch das Problem mit der hängenden Regelung, gibt es irgendwo eine compilierte, gefixte Version von OpenDTU on Battery zum Download?
LG
Hinnerk

[synack666]

Nein, die Version die es fixt schreibt immer persistent, also besser nicht nehmen.
Ein downgrade der Firmware im WR beseitigt das Problem aber sofort und dauert grob 15 Minuten.
Die 1.1.12 hat auch PDL, verzichtest also auf nichts und es ist unklar wann die 2.0.4 von openDTUoB unterstützt wird.

[Higgy112]

Alles klar, vielen Dank für die Info. Habe gerade die Hoymiles DTU raus gekramt und das Downgrade angefordert.

[Higgy112]

Moin, mit der 1.1.12 läuft es jetzt soweit, hatte nur noch ein Problem mit der DTU, die war sporadisch immer mal nicht erreichbar, lag aber anscheinend an dem ESP32, der lief auch ziemlich heiß. Mit einem anderen ESP tritt das Problem bisher nicht auf.