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.
Asche über mein Haupt, das oben beschriebene Problem bestand aus zwei Schwachstellen.
Das eine Problem, die Meldung “Bitte stellen Sie sicher, dass das Gerät und der CT mit demselben Netzwerk verbunden sind” wird weiterhin angezeigt.
Das andere Problem, dass ich im ersten Beitrag übersehen hatte war ein Empfang von -63dBm am Jupiter. Mit dem Durchprobieren von vielen WLAN-Accesspoint-Varianten konnte ich eine Lösung finden, bei der die Jupiter c plus nunmehr mit -59dBm bis -55dBm empfängt. Seither funktioniert die Nulleinspeisung im Rahmen der Marstek-üblichen Übersparsamkeit von 0-6W.
Heute streiken die Marstek-Server seit etwa 13Uhr. Die lokale Nulleinspeisung funktioniert. Die Protokollierung wie viel die Anlage seit 13:10Uhr produziert hat fehlt.
Gleichzeitig kann ich auf der App Seite aus den lokalen Daten herauslesen, dass heute bereits 7,2kWh erzeugt wurden. Android-App-Version 1.6.70 vom 10.07.2026 // Geräte-Version V140.
Schön, dass jemand antwortet! Vielen Dank Onkel Hotte. Schade, dass auch Du Einiges Deiner Zeit auf das Problem geschmissen hast. - Aber jetzt ist ziemlich klar, dass es ein zentrales Problem des Marstek Servers ist. Bei mir sind die ersten 24h Ausfallzeit jetzt auch schon voll:
Heute gähnende Leere in der “Leistungsanzeigen". - Und das alte vorgebliche Konfigurationsproblem besteht weiterhin fort. Die verschlechtbessern ihre Software fortlaufend, starten neue Software-Projekte, während die alten Baustellen noch gar nicht behoben wurden.
Und wenn man schon kein “Samstags-Notfallteam” hat, das den Server wieder zum Laufen bringen kann, sollte man seine Serverfarm donnerstags und freitags nicht anfassen!
Nach 72h Server-Ausfallzeit läuft es wieder. Ganz genau waren es 71h 40Min Ausfallzeit, ich will ja nicht übertreiben . Also wenn am Freitag-Mittag die Marstek-Server in Europa ausfallen, kann es schon Mal bis Montag-Mittag dauern, bis das querliegende Bit gefixt wird. Im Verlauf der Monatsbetrachtung ist der Freitag nunmehr unvollständig erfasst (nur bis 13:10Uhr), Samstag und Sonntag fehlen komplett.
. Also wenn am Freitag-Mittag die Marstek-Server in Europa ausfallen, kann es schon Mal bis Montag-Mittag dauern, bis das querliegende Bit gefixt wird. Im Verlauf der Monatsbetrachtung ist der Freitag nunmehr unvollständig erfasst (nur bis 13:10Uhr), Samstag und Sonntag fehlen komplett.
