Monatsrückblick Juli / August 2026 ist online!

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

[JackDaniel]

[mdnsHelper] Finished mDNS discovery of Zendure devices, found 0 device(s) via mDNS!
obwohl ich einen 3CT am start habe :(

[The_Stig]

@nograx sagte:

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

Ich hatte es oben so verstanden, dass nur noch verschlüsselt funktioniert. So hatte ich es mir dann mit Hilfe von ChatGPT auch eingerichtet. Sonst wäre ich ja gar nicht vom normalen MQTT Broker von ioBroker weg gegangen.

[nograx]

@The_Stig naja wenn auf emqx beide Ports erlaubt sind kann der Hyper ja per SSL verbinden und der Adapter trotzdem ohne.

[nograx]

@JackDaniel hast du getrennte IP Bereiche / VLANs im Einsatz?

[The_Stig]

@nograx sagte:

@The_Stig naja wenn auf emqx beide Ports erlaubt sind kann der Hyper ja per SSL verbinden und der Adapter trotzdem ohne.

Siehst - und da hört mein Verständnis schon wieder auf...ich weiß es schlicht nicht, was ich mit Hilfe der AI genau gemacht habe

[The_Stig]

Habs nochmal gecheckt. Verbindung über Port 8883...

[JackDaniel]

@nograx

nein, aber jetzt geht es auf einmal
[mdnsHelper] Finished mDNS discovery of Zendure devices, found 2 device(s) via mDNS!