Eine Warnmeldung gibt es, ich denke aber das du die schon kennst:
<frozen serve_forecast>:2854: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
Ist an sich nur ein Hinweis, das mit der kommenden Version in Python 3.16 eine Änderung eintritt und dieser Befehl nicht mehr verwendet und daraus entfernt wird. Da HA mit den Versionen eh hinterher ist, kann man das momentan getrost ignorieren.
Auch bei mir gabs keine Probleme bei der Installation und beim ersten Durchlauf. Allerdings habe ich 5 Panel-Gruppen…kA, ob er nun die letzte Panelgruppe ausblendet und nur die ersten 4 macht….
@Twix1212
Das steht in der Beschreibung, er “macht” nur 4 Gruppen! Mehr ist einfach völliger Overkill und Unsinn auf Home Assistant.. das wird sich auch nicht ändern macht logisch auch super wenig sinn, erzeugt nur Noise ohne Mehrwert. Das ist bei SFML aber auch so, nur SFML ist da “gnädiger” . Logisch ist es so:
4 Himmelsrichtungen oder 3 Himmelrichtung + 1 Tilt oder 2 Himmelsrichtunge + 2 Tilt usw.
Tilt macht erst ab einer Differenz von 30 +/- Sinn und Azimut bei +/- 40 Grad (Kompasswert) .. alls andere ist völlg sinnbefreit und erzeugt Noise und Hintergrundrauschen in SFML. Der Transformer würde es komplett “kicken” da es logisch und mathematisch irrelvant ist.
Das ist bei mir historisch gewachsen - es waren immer 5 Gruppen und dementsprechend sind auch die Dashboards anegelegt. Daher wollte ich das schlicht nicht verwerfen, weil es einen Rattenschwanz an Änderungen nachsich ziehen würde (inkl historische Daten usw…)
So lange das SFML damit umgehen kann (ob TFS jetzt ne Gruppe irgendwo anders dazu rechnet oder wie auch immer) und sich nicht erhängt, passt das für mich.
Nein, TFS hängt sich nicht auf, es ergibt nur absolut keinen Sinn. Da quasi immer eine Gruppe fehlt, sind die übergebenen Layer grundsätzlich zu niedrig (um die einzelnen Stundenwerte der fehlenden Gruppe reduziert), und SFML würde wie verrückt dagegenarbeiten.
Also bitte De-Installieren sonst hast Du mittelfristig ein echtes Problem ..
Ottokar hat es eigentlich schon korrekt beantwortet. Code ist grundsätzlich UTC das hängt mit dem Umstand zusammen, dass nicht alle Länder Sommer- / Winterzeit kennen und es eine Baseline bedarf.
Wetterdaten zum Bespiel kommen grundsätzlich in UTC und vieles mehr. SFML hat an sehr vielen Stellen (ich glaube rund 400) konverter die UTC auf den jeweiligen Standort anpassen. Das ist besonder kritisch bei Wetterdaten und der Prognose an sich, die würde sich sonst verschieben. → Sehr tricky besonders bei Sommer / Winterzeit Umstellungen.
Home Assistant ist leider nicht durchgängig local / UTC → ein echtes Problem! SFML hat, um das abzufangen, dafür einen Code der quasi die Zeitstempel übersetzt zwischen Anzeige / Training / Prognose / Wetter / … da auch SFML ausschließlich in UTC programiert ist (also ohne Winter- / Sommerzeit)
TFS braucht den also nicht zusätzlich.. den BUG in HA selbst, kannst Du gut selber sehen:
Startzeit TFS = Local // Logs selber = UTC.. . man muss kein Mathegenie sein um zu verstehen was das für die Entwickler von Integrationen bedeutet und wieviel Umwege es auf Code-Ebene bedeutet es zu synchronisieren / synchron zu halten. → Irgendwie unlogisch das das erste Log 2 Std vor dem eigentlichen Start der App liegt .. der berühmte Glitch in der Matrix (verursacht von HA selbst)
Hier siehst Du den "Glitch in der Matrix" und den seit Jahren nicht gefixten BUG in Home Assistant der die HÖLLE für jeden Entwickler ist → HA hilft sich hier mit TZ-Code..
Das ist ein Fehler der nicht direkt etwas mit TFS zu tun hat. Er konnte keine Wetterdaten “abholen” das kommt öfter mal vor wenn die Wetterdienste nicht erreichbar sind. Ist aber kein Problem! Es ist ein Sicherheitsnetz eingebaut..
Guten Morgen, als Info, dies lief heute Früh um 6 als Fehler in SFML und TFS.
SFML
2026-04-19 06:00:01 - custom_components.solar_forecast_ml.data.data_weather_pipeline_manager - INFO - Pipeline: Weather update SUCCESS
2026-04-19 06:00:30 - custom_components.solar_forecast_ml.forecast.forecast_tfs_client - DEBUG - TFS fetch failed
Traceback (most recent call last):
File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 539, in start
message, payload = await protocol.read() # type: ignore[union-attr]
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/streams.py", line 707, in read
await self._waiter
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<frozen forecast_tfs_client>", line 44, in fetch_forecast
File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 1521, in __aenter__
self._resp: _RetType = await self._coro
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 788, in _request
resp = await handler(req)
^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/client_middlewares.py", line 36, in single_middleware_handler
return await middleware(req, handler)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 72, in _ssrf_redirect_middleware
resp = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 766, in _connect_and_send_request
await resp.start(conn)
File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 534, in start
with self._timer:
^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/helpers.py", line 713, in __exit__
raise asyncio.TimeoutError from exc_val
TimeoutError
2026-04-19 06:00:31 - custom_components.solar_forecast_ml.forecast.forecast_rule_based_strategy - DEBUG - Physics+LSTM blend active
Bei mir taucht TFS heute nicht im Blend auf, die App Leif aber die ganze Zeit, hab noch nicht gefunden was da möglicherweise schief gegangen ist…ggf. kann mir jemand sagen wonach ich im Log schauen sollte?
(verursacht von HA selbst)
