Monatsrückblick Januar/Februar 2026 ist online!

[Berny-K]

Mein SF 800 Pro geht irgendwie in der Nacht offline. Am Morgen geht er dann nicht mehr online, erst wenn ich die Starttaste am Gerät kurz drücke, dann verbindet er sich wieder. Kennt jemand das Problem?

[Murphy 0]

Verliert er die Verbindung zum Router oder die Verbindung zur Cloud?
Macht dein Provider Nachts einen Neustart der Internetanbindung, immer um die gleiche Zeit?
Ist im Router ein Energiesparmodus für die nacht eingestellt?

[Berny-K]

@Murphy-0 sagte in Test Adapter Zendure Solarflow:

Verliert er die Verbindung zum Router oder die Verbindung zur Cloud?
Macht dein Provider Nachts einen Neustart der Internetanbindung, immer um die gleiche Zeit?
Ist im Router ein Energiesparmodus für die nacht eingestellt?

In der Solarflow App sehe ich am Morgen die Info "Offline", im Zendure-Adapter kommen keine Daten an, aber der SF 800Pro speist ein.

Die Fritzbox meldet folgendes:
01:10:02 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen
Dann passend dazu im iobroker Log:
01:10:09.677 - error: zendure-solarflow.0 (7466) Connection to MQTT failed! Error: Error: read ECONNRESET
Danach aber wieder reconnect:
01:10:10.767 - info: zendure-solarflow.0 (7466) [onConnected] Connected with MQTT!

[Murphy 0]

Da würde ich sagen die Ursache liegt bei der Zendure Cloud.
Ich hatte früher als ich noch in der Cloud war ca. 2x die Woche, dass die CT Steuerung lief aber in der App nichts oder nur Blödsinn angezeigt wurde.
Um das zu klären hatte ich mir einen shelly em an die Leitung zur Zendure Anlage geklemmt um die Leistung in beide Richtungen zu überwachen. Meistens lief die Anlage ganz normal, obwohl die App neben der Spur lief.

Deshalb war ich sehr froh dass es diesen Adapter gibt. Habe die Steuerung zuerst online übernommen und als dann Wochenlang alles lief bin ich mit dem Hyper aus der Cloud gegangen.
Läuft seit über 10 Monaten ohne jegliche Probleme. Lediglich der Umstieg auf Trixie hat mir neulich arge Probleme bereitet.

[Berny-K]

@Murphy-0 Eigentlich benötige ich die Cloud auch nicht, ich steuere aktuell ja schon über Blockly (Basis von Lesiflo). Was müsste ich denn tun um komplett aus der Cloud zu kommen um komplett lokal zu steuern?
Ich habe das aktuell so weil ich damit erst mal schnell zum Ziel gekommen bin und los legen konnte.

[Murphy 0]

@nograx sei dank gibt es dafür eine einfache Lösung:

https://github.com/nograx/zendure-cloud-disconnector

Auch zurück in die Cloud ist problemlos möglich.

Ich mache es so, dass ich mit dem Disconnector den Hyper aus der Cloud hole.
Dann schalte ich den Hyper aus und trenne ihn von den Batterien und vom Netz.

Nach 2 bis 3 Minuten stecke ich wieder alles zusammen und drücke einfach wieder den Startknopf. Ich habe hier schon gelesen, dass manche eine kompletten Reset danach gemacht haben, das funktioniert bei mir nicht.

[Murphy 0]

Kann man denn den SF 800 pro nicht auch über die App aus der Cloud nehmen?

[Berny-K]

@Murphy-0 Da muss ich jetzt mal tiefer recherchieren, ob bzw. wie das möglicht ist

[nograx]

Ich bin mir nicht sicher ob der Cloud Disconnector mit den neuen Geräten von Zendure funktioniert. Aber so weit ich weiß kann man bei diesen in der App einen lokalen MQTT Server hinterlegen. Es gibt aber auch Hinweise darauf das man die Geräte dann nicht im HEMS hinterlegen darf.

[Schimi]

gibt eine neue Firmware fur den 2400 AC

[HeWaBa]

Zum SolarFlow 800 Pro neueste Firmware, V1.0.23.
Da kann man jetzt einen lokalen MQTT Server eintragen, HEMS muss dann deaktiviert sein, ist auch logisch, zumindest wenn man ihn lokal steuern möchte. Es kann nicht funktionieren, wenn ein Gerät von zwei Seiten her unterschiedliche Steuerbefehle bekommt.
Der Cloud Disconnector funktioniert, zumindest bei mir hier, nicht mehr.
Steuerung über MQTT scheint nicht zu funktionieren, oder ich bin zu blöd dafür. Die MQTT Topics sehen auch komplett anders aus als vorher.
Mit dem Firmwareupdate wäre ich vorsichtig, wenn es bisher der Disconnector funktioniert hat. Könnte sein, dass Zendure jetzt nach und nach überall die neue Funktion mit dem lokalen MQTT Server einbaut. Dann wird vermutlich auch der iobroker Adapter (zumindest über den lokalen MQTT Server) nicht mehr funktionieren, so ist das nämlich hier auf dem 800 pro.

[nograx]

@HeWaBa Die neueren Geräte funktionieren "lokal" komplett anders als die alten (bis einschließlich Hyper 2000). Das positive ist das man bei Zendure jetzt immerhin die lokalen Funktionen einbaut. Sobald ich mal ein zenSDK Gerät in die Finger bekomme und länger im Einsatz habe kann ich aktiv an der Umsetzung arbeiten das hier die lokale Unterstützung im Adapter gewährleistet ist.

[Freaknet]

Klingt ja nicht sehr positiv, jetzt wo morgen mein SF800 Plus kommen wird.
Hoffe ich kann über MQTT und das Blockly von @murphy-0 bzw. Java-Script von @lesiflo meinen Plus dennoch nutzen/testen inkl. dem Adapter.
Mal sehn welche Firmeware aktuell drauf ist und ob ich das Update, falls vorhanden unterbinden kann.

[Murphy 0]

Bisher kam beim Hyper kein Update automatisch. Musste immer angestoßen werden.
Mein letztes war im April 2025 😉

[Freaknet]

Vielleicht noch ne blöde Frage, aber was muss ich im Adapter einstellen?
Welche Haken müssen gesetzt werden?

[Murphy 0]

Neustart des Adapters alle 3 Std kann man aktivieren falls die Verbindung von Zeit zu Zeit verloren geht.

Berechnung vom Adapter sind optional um zusätzliche Kalkulationen zu machen. Kann man in ioBroker unter zendure-solarflow.0.gDa3tb.XXXXXXX.calculations die zusätzlichen Objekte ansehen.

Nutze ich hier für:

Spannungsüberwachung nutzen ist auf jeden Fall sinnvoll falls mal etwas aus dem Ruder läuft.

Solarflow Geräte zum herunterfahren zwingen funktioniert nicht mit allen Geräten.

[Freaknet]

@murphy-0 Danke für die Erklärung.

Noch eine Frage zu Adapter:
Ich habe jetzt in die Auswahl "Auth Key" meinen Key aus der App eingetragen und unter "MQTT-Server" meine IP:Port (192.168.x.x:3883)
Da mein Sonoff-Adapter den Port 1883 belegt habe ich als MQTT-Instanz den Port 3883 verwendet.
In der App habe ich den gleichen Port 3883 verwendet und es kommen auch Daten rein.

Nur hab ich jetzt das Problem, dass der Sonoff-Adapter wir sekündlich warn Meldungen im Log ausgibt. Was kann ich dagegen tun? Muss ich zwingend Port 1883 für den MQTT-Server verwenden?

[Felli]

Der Adapter verwendet hardcoded Port 1883, daher versucht er sich mit dem Sonoff zu verbinden was natürlich wegen falschen Zugangsdaten knallt. Gibt zwei Möglichkeiten, entweder baut Peter eine Möglichkeit ins Admin-Ui um den Port zu definieren oder Du benutzt einen dedizierten MQTT Broker auf einem separaten Host. Falls Du alles auf einem Raspi machst, geht das natürlich nicht. Habe in meinem Setup das gleiche Problem, weil Sonoff vor allem anderen da war. Daher nutze ich eine separate Instanz in Proxmox mit einem EMQX MQTT-Broker.

[Freaknet]

Hey @Felli,
Danke, hatte mir schon so etwas gedacht.
Alternativ müsste ich den Sonoff-Adapter einem anderen Port zuweisen und alle Geräte darin ebenfalls switchen. Würde das gehen? Bei knapp 20 Geräten auch eine gewisse Herausforderung.
@nograx
Wenn natürlich in der Admin-Ui vom Adapter das geändert werden könnte wäre das genial! Ist das schwierig umzustellen?

[Felli]

Klar kannst du das in allen Tasmota Geräten so machen, einfach auf 1884 für Sonoff und gut ist. Wäre bzw war mir aber zu viel gebastel ehrlich gesagt. Daher nutze ich den dedizierten MQTT-Broker, was ohnehin performanter und besser in der Wartung ist. Sonoff ist halt schön, weil er direkt eine saubere Objektstruktur anlegt.

Wenn du das nicht kannst mit dediziertem Broker, ist der Wechsel in Sonoff stand jetzt die einzige Möglichkeit oder Peter meldet sich mit einer schnellen Lösung 😁