Herzlichen Dank für den Hinweis! tcpdump gibt es im HA container leider nicht, aber der Hinweis hat mich veranlasst, mein Hirn mal richtig einzuschalten. Fazit - kaum macht man’s richtig, schon funktioniert’s 
. Ber der Reihe nach.
Zunächst habe ich per wireshark nochmal geschaut, ob die EM Pakete auf port 9522 ankommen. Gestern habe ich wohl etwas oberflächlich geschaut. Mit filter (udp.port == 9522) sah ich Pakete, die mir aber nicht wirklich angeschaut habe. Es war die Kommunikation zwischen dem STP und HA. Mea culpa.
Aber weder mit wireshark noch mit tcpdump konnte ich Pakete vom Energymanager nachweisen. Da sich alle Geräte in der selben firewalld Zone befinden (home), muss ich nach meinem Verständnis keine Port-Freigaben machen. Ich habe dann aber doch den port 9522 hinzugefügt, aber es wurden immer noch keine EM Pakete angezeigt.
Dann habe ich mal tcpdump auf dem host meiner virtuellen HA Produktionsmaschine ausgeführt. Dort waren die Pakete im Sekundenabstand zu sehen. Also habe ich dann die Firewall auf meinem Arbeitsplatz-System mal ganz abgeschaltet, aber es gab immer noch keine Pakete vom EM. Und sowohl Produktionssystem als auch mein Arbeitsplatzsystem bekommen die Daten über die selben switches - einen unmanaged Netgear und meine Fritzbox.
Und da dämmerte es dann endlich mal so langsam 
. Ohne einen Listener auf 239.12.255.254 betreibt einer der beiden igmp spoofing, vermutlich die Fritzbox, an der beide Systeme parallel hängen. Deshalb erhielt mein System die Pakete nicht. Also habe ich Geräte suchen in pysmaplus ausgeführt und hatte nach Sekunden mein EM in den pysma-Geräten.
Jetzt habe ich die firewall wieder aktiviert, aiuch den port wieder aus der Liste der Erlaubten entfernt, und es läuft immer noch. Mal schauen, ob es einen Reboot übersteht.
Was ich aber immer noch nicht verstehe ist, warum es jetzt weiter läuft, aber vorher ix gefunden wurde. mdns hatte ich für die home Zone zugelassen. AFAIK müsste das doch reichen, um Multicast-Sender zu finden. Mal schauen, was noch kommt …
Leider hat pysmaplus den reboot des hosts nicht überlebt. Ich bekam das hier:
Da ich an dieser Stelle nicht wieder “starten” kann, habe ich ein “docker stop/start” auseführt. Mit diesem Ergebnis:
Nun tat’s der STP auch nicht mehr 
.
Die udp Pakete des EM kommen aber noch an.
12:02:35.147905 IP `**`energy`**`meter1900201837.fritz.box.60247 > 239.12.255.254.sma-spw: UDP, length 600
12:02:36.148092 IP `**`energy`**`meter1900201837.fritz.box.60247 > 239.12.255.254.sma-spw: UDP, length 600
Das Log fürs EM zeigt das hier:
Logger: homeassistant.config_entries
Quelle: config_entries.py:762
Erstmals aufgetreten: 11:57:13 (1 Vorkommnis)
Zuletzt protokolliert: 11:57:13
Error setting up entry SHM2/EM (em1900201837) for pysmaplus
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, 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.13/site-packages/pysmaplus/device_em.py", line 78, in new_session
data = await self._get_next_values()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pysmaplus/device_em.py", line 91, in _get_next_values
await asyncio.wait_for(self._data_received, timeout=timeout)
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 506, in wait_for
async with timeouts.timeout(timeout):
~~~~~~~~~~~~~~~~^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/timeouts.py", line 116, 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 762, 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.13/site-packages/pysmaplus/device_em.py", line 80, in new_session
raise SmaConnectionException("No speedwire packet received!") from e
pysmaplus.exceptions.SmaConnectionException: No speedwire packet received!
Und die für den STP den schon oft gemeldeten stacktrace:
Logger: homeassistant.config_entries
Quelle: config_entries.py:762
Erstmals aufgetreten: 11:57:13 (1 Vorkommnis)
Zuletzt protokolliert: 11:57:13
Error setting up entry STP10.0SE (SUNNY TRIPOWER 10.0 SE) (sw3015605725) for pysmaplus
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 762, 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.13/site-packages/pysmaplus/device_speedwire.py", line 484, in new_session
await self.device_info()
File "/usr/local/lib/python3.13/site-packages/pysmaplus/device_speedwire.py", line 493, in device_info
ll = await self.device_list()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pysmaplus/device_speedwire.py", line 504, in device_list
await asyncio.wait_for(fut, timeout=self._protocol._overallTimeout)
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, in wait_for
return await fut
^^^^^^^^^
pysmaplus.exceptions.SmaConnectionException: Login failed! No Response from Device!
Könnte da etwas mit dem timing nicht stimmen? Vielleicht etwas länger warten? Ist schon seltsam …
Inzwischen kamen keine EM Pakete mehr an, weil die EM Integration nicht lief.
Ich habe dann den ha container nochmal gestoppt, etwas länger gewartet (15s?) und dann wieder gestartet. Das Ergebnis war jetzt, dass die STP Integration wieder lief, die EM aber immer noch nicht. Kurz nachdem dem Starten kamen dann auch wieder die EM Pakete auf dem System an. Anscheinend hat die EM Integration nur nicht lange genug auf Pakete gewartet nach dem socket call.
Edit:
Deaktivieren, dann Aktivieren und HA neu starten haben beim EM nichts verbessert. ABer es kann sein, dass die STP Integration den Neustart von HA nicht überlebt .
by HarryP:
. Zusammenführung Mehrfachpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
. Code-/Logzeilen formatiert (bitte immer in </> einbinden)
. s.a.: (Neues Update & Features - Hier in der Community 🫶)
. Bin im debugger mal durch das Programm “geschritten, war sehr interessant …