HA-pysmaplus - HA-Neustart führt jedes mal zu Einrichtungsfehler für Speedwire Inverter

[thomasz]

Moin @little.yoda ,

ich melde mich wegen einer etwas lästigen Eigenschaft des Geräts Speedwire Inverter. Jedes mal nach einem Neustart sieht das bei mir so aus:

Einmal deaktivieren und sofortiges Reaktivieren behebt das Problem umgehend. Ich hatte gerade das Update auf die neueste Version gemacht, lief auch problemlos, aber dieses jeweils auftretende Einrichtungsproblem bleibt. Im Log finde ich dann das hier:

Logger: homeassistant.config_entries
Quelle: config_entries.py:769
Erstmals aufgetreten: 09:31:37 (1 Vorkommnis)
Zuletzt protokolliert: 09:31:37

Error setting up entry SMA Speedwire Inverter (???3015605725) for pysmaplus
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/asyncio/tasks.py", line 488, in wait_for
    return await fut
           ^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 271, in _send_receive
    data = await self._protocol.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        msg, timeout=self.timeout, expect_response=receive
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 114, in request
    return await asyncio.wait_for(self._response_future, timeout=timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/asyncio/tasks.py", line 487, in wait_for
    async with timeouts.timeout(timeout):
               ~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/usr/local/lib/python3.14/asyncio/timeouts.py", line 114, in __aexit__
    raise TimeoutError from exc_val
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 769, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/pysmaplus/__init__.py", line 103, in async_setup_entry
    sma = await getPysmaInstance(hass, entry.data)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/pysmaplus/__init__.py", line 96, in getPysmaInstance
    await sma.new_session()
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 523, in new_session
    await session.ensure_initialized()
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 173, in ensure_initialized
    await self.init()
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 178, in init
    await self._login()
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 306, in _login
    data = await self._send_receive("login2")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/pysmaplus/device_speedwire2.py", line 302, in _send_receive
    raise SmaConnectionException("No response from inverter") from last_exc
pysmaplus.exceptions.SmaConnectionException: No response from inverter

Könnte es sein, dass die Wartezeit auf die Antwort vom Inverter für die HA-Startphase etwas kurz bemessen ist? Wenn alles läuft, funktioniert die Sequenz deaktivieren/aktivieren zuverlässig sofort beim ersten Mal.

[little.yoda]

Mit der Speedwire Implementierung gibt bei einigen Geräten diverse Probleme.

Bislang hat keine meiner Änderungen das Problem durchgängig gelöst.
Da ich auch keinen Zugriff auf ein Gerät mit Speedwire Problemen habe, kann ich gerade nicht viel an den Problem tun.

Du könntest probeweise mal statt dem Speedwire das “Speedwire V2” Interface testen.

[thomasz]

Danke für deine Hinweise! Ich habe gerade nochmal in das HA-Log von gestern geschaut. Vor der o. g. Fehlermeldung gab es noch eine:

Die erste Zeile deutet für mich darauf hin, dass ich schon die V2 Variante verwende, oder? Ich würde ungern die jetzigen Geräte/Entites durch erneutes erzeugen zerstören, da ich sie für Statistik verwende.

Zudem habe ich über den Link “Probleme” die Issues Option im Github gefunden. Gestern war ich auf die Schnelle zu blöd dazu. Dort habe ich dies Thema gefunden. Ich werde mal versuchen, den HA-Neustart mit zu loggen. Habe die reine HA-Docker-Version zu laufen. MAl schauen. Ich werde berichten.

p.s. Soll ich aus dem Thema besser noch ein issue erzeugen, oder erst mal warten, wie weit ich komme?

Nachtrag:
@little.yoda: Habe einen tcpdump für den HA-Neustart und nachfolgendes deaktivieren/aktivieren des inverter Gerätes. Die Kommunikation beginnt mit allerlei Hellos, scheint aber nicht zu ende zu kommen.

Zu erkennen ist auch, dass andere Komponenten damit beginne, per Modbus auf den STP10.0SE zu zu greifen. Einmal überwache ich die Innentemperatur (gibt’s anscheinend nicht über Speedwire), zum anderen greift evcc anscheinend über Modbus zu. Vielleicht bremst das den WR zu sehr aus.

Die angehängte Datei heißt zwar txt, ist aber das binäre typdump file.

inverter.txt (106,3 KB)

by HarryP: Zusammenführung Mehrfachpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

[little.yoda]

Kannst du probeweise mal modbus + evcc kurzfristig deaktivieren und dann schauen, ob der Fehler nach einem Neustart wieder auftritt?
(Nur um das Offensichtliche auszuschließen)

[thomasz]

Auf die Idee hätte ich auch selber kommen müssen . Habe ich gerade gemacht, aber das Verhalten hat sich nicht geändert. tcpdump ist wieder mit gelaufen (Anhang). Dies ist die einzige Hello-Sequenz, bei der am Ende anscheinend Daten übertragen werden.

Ich vermute, dass diese durch das aktivieren nach dem deaktivieren ausgelöst wurde. Davor gibt es keine, als würde das “Client Hello” beim Neustart nicht einmal gesendet (ich habe den dump gestartet, bevor ich auf Neustart geklickt habe). Das erscheint mir recht mysteriös. So, als würde der HA-Code den https Request deiner Integration schon abfangen/ignorieren. Vielleicht hast Du dazu eine Idee. Einen schönen Abend noch!

inverter2.txt (98,5 KB)

[little.yoda]

Das macht für mich gerade keinen Sinn.

Speedwire nutzt ein UDP-Protokoll.
Die TCP-Verbindungen stammen nicht von einer integration.

Könnten es deine Modbus-Anfragen sein?

[thomasz]

Hm, das kann gut sein. Ich habe die Standard-SMA-Integration, die das Webconnect-Interface nutzt, auch noch laufen. Die hatte ich ein wenig verdrängt. Die werde ich morgen auch mal abschalten und dann testen.

Nachtrag:

Ich habe das nun auch mal ohne die Webconnect Integration probiert, aber das Bild bleibt gleich. Ich habe keine Anzeichen, dass die anderen TCP-Protokolle stören.

Angehängt habe ich noch einen Dump von heute Vormittag. Der Neustart sollte ab 09:24:12 Uhr erfolgt sein. Dann folgen ab 24:23 mdns-Fragen und -Antworten und danach geht’s mit udp-Paketen fleißig weiter (inverter3.txt):

Dann folgt eine kleine 4s-Pause von 24:56 bis 25:00 und dann noch mal eine von 25:01 bis 25:06. Ich denke, dass in diese Zeiten meine deaktivieren und aktivieren fiel. Kannst du die anscheinend binären Paketinhalte analysieren?
Ich habe dann noch einen längeren Mitschnitt gemacht, hier der Neustart-Zeitpunkt:

Ich habe dann eine Zeit gewartet. Ab 53:00 enden die udp-Pakete, da dürfte die Einrichtung des Inverters wohl final fehlgeschlagen sein. Dann habe ich deaktiviert und aktiviert. Ab 54:47 kommen dann die udp-Pakete wieder regelmäßig:

Ich hoffe, dass es dir möglich ist, die Pakete vom Fehlversuch mit denen vom aktivieren zu vergleichen. Der dump dazu ist inverter4.txt.

inverter4.txt (173,8 KB)

inverter3.txt (93,7 KB)