Monatsrückblick Juli / August 2026 ist online!

[nograx]

Sehr gut. Meinen auch hatte kurz Panik ich hätte hier Scheisse gebaut. Wobei ein "Breaking Change Hinweis" beim Update vll. ganz gut gewesen wäre. Problem dabei ist das der Hyper bei hemsState irgendwie eigene Einstellungen nutzt. Wenn der auf hemsState = 1 schaltet greifen seine internen. Und bei einigen hat der dann komische Werte. Bei mir waren es z.B. 600W. Alles darüber wurde dann ignoriert.

[The_Stig]

Ok, ich blicke da ja eh nicht durch und hangele mich hier nur so durch. Die Diskussion oben habe ich auch nciht verstanden. Dir jedenfalls ein großer Dank für den Adapter und deinen Noteinsatz am Sonntag Morgen!

[nograx]

@The_Stig wird dir jetzt nichts mehr bringen, aber ich habe noch mal eine Version mit Hinweis im Changelog und einer Warnung in Log hinzugefügt wenn inverseMaxPower kleiner als das neue Limit ist (zB 0)

[Rene55]

@nograx Ist es für meinen 'alten' SF1200 noch sinnvoll, den Adapter immer auf die nächste Stufe hochzuziehen - oder bin ich irgendwann abgehangen von wegen HEMS und sonstigen Neuerungen?

[nograx]

@Rene55 Schaden kann es eigentlich nicht. Bin immer bemüht aufzupassen das ich nichts kaputt mache was die "Legacy" (klingt besser als alt) Geräte betrifft. Die letzte Majorversion (5.*) hat auch die Methodik geändert was die Anlage der Datenpunkte angeht, kann sein das du hier viel mehr Infos vom Hub siehst als vorher (vorher gab es eine feste Liste). Jetzt wird einfach alles was der Hub meldet auch als Datenpunkt angelegt.

[XBiT]

@nograx

Steuere gerade die Mix über das Multi-Device-Skript welches auf dem Shelly läuft weil es ja noch nicht von dem Adapter unterstützt wurde.
Batterie ist auf 100% und eine Überwachung sollte da nicht greifen.

[nograx]

@XBiT kannst du den Adapter wohl mal auf Debug stellen und mir einen kurzen Auszug von Log schicken? Dann schau ich mal was da passiert..

[Rene55]

@nograx Ok, dann vertraue ich darauf, dass die Legacy-Devices noch lange unterstützt werden. Wenn es nicht mehr geht, sagst du sicherlich Bescheid. Ich bin noch auf der V4.1.2. Ich werde die V5.2.0 mal testen. Übrigens: Danke dafür.

[nograx]

@Rene55 Ich denke du bist da noch sehr lange auf der sicheren Seite. Da dürfte es sowohl auf der Zendure Seite als auch im Adapter keine großen Änderungen mehr geben. Anpassungen gibt es eher in Richtung neuer Geräte, hier geht dann aber alles ausschließlich über das zenSDK, von daher betrifft es da auch nur den neuen Code und keinen alten ;-)

[The_Stig]

hi @nograx - kann ich eigentlich wieder auf das "normale" MQTT umstellen? Ich habe doch immer mal Aussetzer mit EMQX. Da war doch was mit Authentifizierungsnotwendigkeit irgendwie?

[nograx]

Wenn keine ganz große Not hast würde ich warten bis Zendure die neue Firmware für den Hyper verteilt, dann ist TLS wieder deaktiviert

[The_Stig]

@nograx sagte:

Wenn keine ganz große Not hast würde ich warten bis Zendure die neue Firmware für den Hyper verteilt, dann ist TLS wieder deaktiviert

Danke dir. So wirds gemacht. Und dann gerne auch nach dem Firmware Update erstmal ein paar Tagen warten und beobachten, was sonst so Spannendes mit dem Update passiert :-)

[lesiflo]

Hab ihr so was wie ein Monitoring eurer Geräte eingebaut, wenn sie z.B. "tot" sind und keine Daten mehr senden der WLAN weg ist? Ich prüfe aktuell auf
zendure-solarflow.0.x.y.lastUpdate. Damit kann ich aber nur sehen ob noch Daten vom Gerät kommen und nicht ob diese auch valide sind.
Macht ihr so was auch und wenn ja wie?

[The_Stig]

Habe das grad frisch in mein Script eingebaut: wenn Daten 3 Minuten veraltet, dann restarte ich den Adapter. Aber nur wenn

• Soll ≥ 100 W
• positives Soll seit mindestens 120 s
• kein LowVoltageBlock
• keine MinSOC/SOC-Entladesperre

[nograx]

Dh der Adapter verliert die Verbindung zum MQTT?

[The_Stig]

Keine Ahnung, was da genau passiert.

Bei mir hängt sporadisch der Zendure-Solarflow-Adapter bzw. die Gerätekommunikation. Auffällig ist:

• zendure-solarflow.0 bleibt alive=true und connected=true
• Steuerbefehle an control.setDeviceAutomationInOutLimit werden mit ack=false gesendet und anschließend vom Adapter mit ack=true bestätigt
• der Sollwert ändert sich also korrekt
• der reale Rückmeldewert outputHomePower bleibt aber auf einem alten Wert stehen
• auch ein manueller neuer Sollwert (gesetzt direkt im ioBroker), z. B. 500 W, wird bestätigt, physisch passiert aber nichts
• gleichzeitig wird outputHomePower zeitlich nicht mehr aktualisiert
  Ein Neustart nur von zendure-solarflow.0 behebt das Problem sofort. Danach wird outputHomePower wieder aktuell und folgt dem Sollwert.
  Der Fehler ist also nicht die Regelung selbst, sondern offenbar eine hängende Kommunikation zwischen Adapter und Hyper, obwohl der Adapter formal weiterhin „connected“ meldet.
  Als Workaround überwache ich deshalb das Alter von outputHomePower und starte den Adapter neu, wenn bei positivem Sollwert über mehrere Minuten keine frische IST-Rückmeldung mehr kommt.

Ist seit der Umstellung auf EMQX - passiert aber sehr unregelmäßig. Manchmal tagelang nicht, manchmal 2-3x pro Tag. Mit Restart deines Adapters gehts dann wieder. Daher habe ich das jetzt in mein Script eingebaut.

[nograx]

@The_Stig wie verbindest du dich denn mit dem EMQX? Du kannst ja sowohl per SSL als auch unverschlüsselt, sofern du das auf dem EMQX erlaubst. Hast du damit mal rumgespielt?