Marstek: Lokale Shelly-Nulleinspeisung gestört durch "CT002-angepasstes Update"

​Hallo zusammen,
​wer von Euch die lokale Nulleinspeisung (RPC/UDP) beim Jupiter/Venus in Kombination mit einem Shelly ( Pro 3EM etc.) nutzt, läuft seit den jüngsten App-/Plugin-Updates (um den 22.06.2026) in massive Timeout-Probleme.

Das Fehlerbild: Die Marstek-App zeigt plötzlich veränderte, teils doppelte dBm-Grafiken (WLAN-Signalstärke). Die Hauptgrafik wird fälschlicherweise als „Venus“ betitelt (mein Gerät ist der Jupiter c plus), eine zweite Grafik ist leer und als „CT“ beschriftet. Einige Zeit später (wenige Stunden) stürzt die lokale Kommunikation ab und es erscheint im Menüpunkt Jupiter/Einstellungen/WLAN-Konfiguration in roter Schrift die Fehlermeldung: „Bitte stellen Sie sicher, dass das Gerät und der CT mit demselben Netzwerk verbunden sind.“

​Die technische Ursache (Kein Netzwerkfehler!):
Mutmaßlich hat Marstek die JSON-Datenstruktur auf den Servern und in der App umgebaut, um den hauseigenen Smart Meter (CT002) zu integrieren. Die App erwartet nun im Jupiter-Untermenü zwingend ein Datenfeld für die Signalstärke (rssi_dbm) des Zählers.
​Ein Shelly liefert über die lokale API aber systembedingt nur die reinen Leistungswerte (Watt) und verständlicherweise keine Marstek-konformen WLAN-Werte. Die App läuft in einen logischen Underflow (Datenfeld bleibt null). Statt diesen Drittanbieter-Zustand sauber abzufangen, wirft die Software die paranoide Standard-Fehlermeldung aus und bringt den lokalen Kommunikations-Stack zum Timeout. (Das Alles geschieht während der Shelly als Nulleinspeisungs-Messgerät eingestellt ist. Zuvor hat das alles 9 Monate einwandfrei funktioniert)

​Temporärer Workaround: Wenn die Kommunikation stirbt, hilft aktuell nur das harte Kappen der Netzwerkverbindung des WLAN-Repeaters/Akkus (z. B. Repeater kurz ziehen), um den Socket-Timeout zurückzusetzen. Die Fehlermeldung in der WLAN-Konfiguration erscheint übrigens sofort wieder bzw. persistiert auch dann, wenn die Nulleinspeisung Shelly/Marstek gerade funktioniert.
​Schaut mal in eure Apps (Jupiter/Einstellungen/Historisches WiFi-Signal), ob es dort auch schon Geister-Grafiken gibt von Geräten, die ihr gar nicht am Start habt!

Seid gnädig, das ist mein erster Beitrag. Verschiebt ihn ggf., wenn er woanders besser hin passt.

Grüße an alle Leser

Markus (Maarqs)

Anhang: Bild mit Fehlermeldung der WLAN-Konfig (Während die Nulleinspeisung gerade gut läuft und es im gesamten Netz nur eine SSID gibt. Und Shelly Pro3 und Jupiter sich gerade definitiv im selben WLAN-Heimatnetz befinden.)

Ich habe einen Venus -E und da ist seit kurzem auch diese Doppel Grafik.
Aber bei dem Laden wundert mich nichts mehr was die Software angeht, die ist einfach nur Mist.
Weil ich ein HEMS habe, soll die Steuerung des Venus auch darüber erfolgen, aber Modbus ist nicht offiziell dokumentiert. Dafür gibt es Local API, aber die Nutzung dessen bringt den Speicher öfters zum Abstürzen, bis hin zum Freeze. Dann hilft nur noch ein Werksreset. Ach ja - Wlan und Lan gleichzeitig bringt das Gerät auch aus dem tritt.
Der Support ist unterirdisch, wenn sich den überhaupt mal jemand meldet heißt es oft die Wlan Verbindung wäre schlecht. Dabei steht der Venus einen knappen Meter neben meiner Fritzbox und zeigt 30dBm an, ok manchmal ist es auch weniger, aber nie weniger als 50dBm.
Wahrscheinlich nimmt der Speicher dann einen Repeater - fragt sich nur wieso (Software?)
Als CT hab ich den Ecotracker und der wird in der Regel auch schnell und sauber erkannt, kann aber auch einen emulierten Shelly 3M (vom HEMS erzeugt) nehmen, ändert aber nichts daran, das das Gerät bzw. die Software Mist baut.