Plötzlicher extreme Ausschlag des Forecast

[Astrofreak85]

Hi,

ich habe heute, plötzlich auf System 1 einen extremen Ausschlag im Forecast (wie schon fälschlich drüben im Bugtracker gepostet).

Meine Vermutung ist, dass das eventuell mt einem HA Schluckauf Anfang Mai zusammen hängt, da war der Tages kwh-Zähler kurz bei 0 und wieder hoch, dadurch hab ich bis heute einen falschen “Rekord Tag”.

Auch dir Prognose für die nächsten Tage ist extrem überzogen.
Hier gehen maximal so um die 5,4kWh (DC)

Das muss irgendwie durch den Early Morning Forecast passiert sein.
Bisher hatte dieser “Hickup” keinerlei Auswirkungen, besonders mit den neuen Safeguards in SFMl hätte ich eher vermutet, dass das ignoriert wird.
Offenbar schlägt das aber plötzlich durch, oder hier ist was anderes faul…

@Tom-HA soll ich dir ggf. mal Logs und db sicken?

Im Log für gestern abend 23:30 hab ich nicht auffälliges gefunden, die Anomaly taucht erstmalig nach dem 0:20 wetter-lauf auf und die weiteren “Wetter-Läufe” hab ich das hier gefunden:

Ende vom EOD-Lauf:

2026-05-25 23:50:07 - custom_components.solar_forecast_ml.forecast.forecast_rule_based_strategy - DEBUG - Skipping hourly predictions for locked dates: 2026-05-25, 2026-05-26, 2026-05-27
2026-05-25 23:50:07 - custom_components.solar_forecast_ml.forecast.forecast_rule_based_strategy - DEBUG - Forecast strategy summary: hours=72, regime_learning_available=57, regime_learning_shrinkage=51, similar_weather_adjustment=11, similar_weather_tfs_cap_relaxation=3, similar_weather_underforecast_relaxation=11, tfs_adaptive_blend=30, tfs_policy_adjustment=3
2026-05-25 23:50:07 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - INFO - Forecast complete: Today=4.06 kWh, Tomorrow=3.87 kWh, Day After=3.15 kWh, Method=physics
2026-05-25 23:50:18 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - DEBUG - Forecast storage skipped for locked morning forecasts: today, tomorrow, day_after_tomorrow
2026-05-25 23:50:18 - custom_components.solar_forecast_ml.core.core_coordinator_update_helpers - DEBUG - Forecast generated: today=4.06 kWh, tomorrow=3.87 kWh, method=physics, hourly_entries=72
2026-05-25 23:50:37 - custom_components.solar_forecast_ml.production.production_history - DEBUG - Peak time calculation: Using stored hourly production data
2026-05-25 23:51:04 - custom_components.solar_forecast_ml.core.core_coordinator_update_helpers - DEBUG - Forecast update skipped for locked morning forecasts: today, tomorrow, day_after_tomorrow
2026-05-25 23:51:04 - custom_components.solar_forecast_ml.core.core_coordinator_update_helpers - DEBUG - Forecasts saved to database (respecting locks)
2026-05-25 23:51:07 - custom_components.solar_forecast_ml.ai.ai_tiny_lstm - INFO - Early stopping at epoch 42
2026-05-25 23:51:10 - custom_components.solar_forecast_ml.ai.ai_tiny_lstm - INFO - Training complete: R2=0.869, RMSE=0.036 kWh, outputs=3, layers=2, heads=4
2026-05-25 23:51:10 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - LSTM trained: R²=0.869, epochs=42, layers=2, heads=4
2026-05-25 23:51:10 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - Active model: LSTM (915 samples)
2026-05-25 23:51:10 - custom_components.solar_forecast_ml.coordinator - DEBUG - Hourly predictions cache refreshed: 24 today, 24 tomorrow, 24 day_after
2026-05-25 23:51:10 - custom_components.solar_forecast_ml.coordinator - DEBUG - Finished fetching solar_forecast_ml data in 539.464 seconds (success: True)
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Model weights saved to structured tables
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - Weights saved to database
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_seasonal - DEBUG - Seasonal factors saved to database
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_predictor - DEBUG - Updated seasonal factors for 3 months
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_dni_tracker - DEBUG - DNI tracker saved to database
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Seasonal archive saved: spring/lstm (25827 weights)
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.data.db_manager - DEBUG - Seasonal archive saved: spring/ridge (4323 weights)
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - Model archived for season spring/2026
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_predictor - INFO - Training complete: active=tiny_lstm, R²=0.869, RMSE=0.036kWh, samples=915, outputs=3
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - AI model trained: R²=0.869, RMSE=0.036kWh, samples=915, features=36, outputs=3, attention=ON
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.coordinator - INFO - Coordinator notified of AI Training completion at 2026-05-25 23:51:17.505025+02:00. Accuracy: 0.8688392628421373
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.sensors.sensor_system_status - DEBUG - Status updated: event=ai_training, status=success, state=ok
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_dni_tracker - DEBUG - DNI tracker saved to database
2026-05-25 23:51:17 - custom_components.solar_forecast_ml.ai.ai_dni_tracker - INFO - DNI tracker end-of-day update complete

Erstmaliges auftauchen der Abweichung im Wetter-Lauf 0:20

2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - ================================================================================
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   MORNING ROUTINE EXECUTION - Attempt 1/3 for 2026-05-26
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - ================================================================================
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 1/5: Validating prerequisites...
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - All prerequisites validated
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ✓ Prerequisites validated: 72 forecast hours, 72 weather hours
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 2/5: Creating hourly predictions in database...
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Checking and unlocking existing forecast locks...
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  🔓 Found 24 existing predictions - will update
2026-05-26 00:30:03 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Preparing to update predictions for 3 days...
2026-05-26 00:30:04 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  Cleared 72 existing prediction slots for update
2026-05-26 00:30:04 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Processing 72 input forecast entries (3 days)...
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Calculating daily totals from saved predictions for 3 days...
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  → 2026-05-26: 6.56 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  → 2026-05-27: 7.90 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  → 2026-05-28: 6.86 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Saving daily forecasts to database for 3 days...
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG -      → Daily forecasts LOCKED for 3 days: locked=TRUE, locked_at=2026-05-26 00:30:04.017486+02:00
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Operational morning snapshot mirrored successfully
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Updating coordinator expected daily production...
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.data.data_state_handler - DEBUG - Expected daily production saved: 6.56 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Setting morning routine lock for 2026-05-26...
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG -      → Lock flag set: last_set_date = 2026-05-26
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   └─ SUMMARY:
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Input entries: 72 (3 days)
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Created predictions: 72
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Predictions per day:
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -        - 2026-05-26: 24 hours, 6.56 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -        - 2026-05-27: 24 hours, 7.90 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -        - 2026-05-28: 24 hours, 6.86 kWh
2026-05-26 00:30:07 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Coordinator updated: Yes (today=6.56 kWh)

Mornig Routine (5:00)

2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - 
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - ================================================================================
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   MORNING ROUTINE EXECUTION - Attempt 1/3 for 2026-05-26
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - ================================================================================
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 1/5: Validating prerequisites...
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - All prerequisites validated
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ✓ Prerequisites validated: 72 forecast hours, 72 weather hours
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 2/5: Creating hourly predictions in database...
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Checking and unlocking existing forecast locks...
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  🔓 Found 24 existing predictions - will update
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  🔓 Unlocking daily_forecast (was locked at 2026-05-26 00:30:04.017486+02:00 by morning_routine)
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Preparing to update predictions for 3 days...
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  Cleared 72 existing prediction slots for update
2026-05-26 05:00:23 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Processing 72 input forecast entries (3 days)...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Calculating daily totals from saved predictions for 3 days...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  → 2026-05-26: 6.57 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  → 2026-05-27: 8.05 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   │  → 2026-05-28: 6.86 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Saving daily forecasts to database for 3 days...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG -      → Daily forecasts LOCKED for 3 days: locked=TRUE, locked_at=2026-05-26 05:00:23.234342+02:00
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Operational morning snapshot mirrored successfully
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Updating coordinator expected daily production...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.data.data_state_handler - DEBUG - Expected daily production saved: 6.57 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ├─ Setting morning routine lock for 2026-05-26...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG -      → Lock flag set: last_set_date = 2026-05-26
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   └─ SUMMARY:
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Input entries: 72 (3 days)
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Created predictions: 72
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Predictions per day:
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -        - 2026-05-26: 24 hours, 6.57 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -        - 2026-05-27: 24 hours, 8.05 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -        - 2026-05-28: 24 hours, 6.86 kWh
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -      • Coordinator updated: Yes (today=6.57 kWh)
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ✓ Hourly predictions created successfully
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 3/5: Verifying data integrity...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - Integrity verified for 3 days starting from 2026-05-26, no duplicates
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ✓ Data integrity verified - no duplicates found
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 4/5: Refreshing coordinator cache...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.coordinator - DEBUG - Hourly predictions cache refreshed: 24 today, 24 tomorrow, 24 day_after
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO -   ✓ Coordinator cache refreshed
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.production.production_morning_routine - INFO - → Step 5/5: Triggering sensor updates...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.forecast.forecast_weather - INFO - Forecast using database: 72 hours across 3 days
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.sensors.sensor_data_collector - DEBUG - Collected external sensor data: {'temperature': 14.2, 'humidity': 84.0, 'wind_speed': 0.0, 'rain': 0.0, 'pressure': 1016.8, 'solar_radiation': 2.49, 'lux': 315.2}
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - DEBUG - Creating forecast (AI + Physics)...
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - DEBUG - Lag-Feature 'production_yesterday' = 4.76 kWh (from DB: 2026-05-25)
2026-05-26 05:00:25 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - INFO - TFS forecast: 9.74 kWh (score 1.00)

Da wird die Vorhersage für morgen sogar noch ein wenig krasser…

[Tom-HA]

Hallo @Astrofreak85

Nicht der „Rekordtag“ als Anzeige ist das eigentliche Problem, sondern die Frage, ob der damalige HA-Schluckauf als falscher historischer Ist-Wert in der SFML-Datenbank gelandet ist. Wenn Anfang Mai durch den kurz auf 0 gefallenen Tageszähler ein unrealistisch hoher Tages- oder Stundenwert gespeichert wurde und dieser Wert als lernfähig gilt, kann er später tatsächlich die Prognose beeinflussen. → Das gilt aber nicht für einmalige Ausreißer!

Der Mechanismus dahinter ist:
SFML vergleicht historische Morning-Prognosen mit den später gemessenen Ist-Werten. Wenn dort ein falscher Ist-Wert steht, kann SFML daraus lernen: „Bei ähnlichem Wetter war die Prognose damals viel zu niedrig.“ Genau so ein Signal kann dann spätere Prognosen nach oben ziehen, sollte das häufiger Vorkommen!

[Kaysen899]

Bedeutet also, bei gleichen Wetter so lange lernen lassen, bis der Ausschlag wieder rausgewichtet ist. Kann also ein bisschen dauern.

[Astrofreak85]

Hi,

das ist es ja was mich verwundert, das ist nur ein singuläres Ereignis. Nichts was mehrmals aufgetaucht ist. Die Mechanik von SFML sollte gegen sowas ja ansich robust sein. Vielleicht war es auch was anderes, das Ereignis am 02.05. ist aber das einzige was ich mir jetzt auch zeitlich vorstellen kann.

Und bis heute morgen gab es auch keine solchen merkwürdigen Forecasts.

Kann dir gern mal die DB und die Logs schicken.

[Astrofreak85]

sieht heute wieder normal aus… 5,2kWh scheint mir zwar Nenntick zu optimistisch bei der Wärme…aber immerhin ist die Vorhersage Weider ohne Buckel…

[Kaysen899]

Ich habe Zwar keinen so Extremen Ausschlag wie bei dir, aber heute auch etwas kurriose Prognose.
Und wieder lernmaterial.

1kWh wurde noch nie erreicht und bei diesem Wetter die letzten tage, wird es eher weniger in der Produktion als mehr.
Wegen Anstellwinkel und Temperatur.

siehe die letzten Tage.

Mal gucken wie es sich entwickelt.

[Tom-HA]

Grundsätzlich ist es so, dass das KEIN BUG im Code ist. Warum?

SFML arbeitet mit Daten und Datenquellen, die von Home Assistant bereitgestellt werden.

Das hat vorteile aber auch einen einfachen Nachteil:
Wenn sich Home Assistant irgendwo „verhaspelt“, ein Sensor kurzzeitig falsche Werte liefert oder ein Datensatz nicht sauber ist, kann sich das in der Auswertung widerspiegeln.

Die Ursachen dafür können praktisch überall liegen:

• Eine nicht erreichbare Cloud
• Fehler in der Hardware, die die Werte bereitstellt,
• kurzzeitige Aussetzer
• Neustarts
• Poll-Intervalle,
• Software oder das BIOS z.B, des Wechselrichters
• Verkabelungen
• Kriechströme
• Widerstände
• Wärme / Kälte
• Software des Cloud-Anbieters in China auf den Servern
• Interne Korrekturen des Herstellers
• Fehler in der Bereitstellung durch den Hersteller
• Modbus
• Hardware des Nutzers
• Internetverbindung beim Hersteller / Nutzer
• Netzlast im Heimnetz
• TCP/IP-Konflikte
• Home-Assistant-Konfiguration
• Nutzerverhalten
• Andere Integrationen oder Automationen, die kurzfristig den Eventloop blockieren,
• Rundungsfehler
• Herstellerkorrekturen

und vieles mehr…

Und genau da stellt sich die Frage:
Wo soll man anfangen?

• Bei der Wechselrichter-Software?
• Beim Cloud-Anbieter (seinen Servern)?
• Bei Modbus?
• Bei der lokalen Hardware?
• Bei der Internetverbindung?
• Bei Home Assistant selbst?
• Beim Nutzerverhalten
• …

Diese Fehlerquellen sind so vielfältig, dass es schlicht keinen Sinn ergibt, sie im SFML-Code „korrigieren“ zu wollen.
Home Assistant läuft in der Regel 24 Stunden am Tag, 7 Tage die Woche.
Die meisten internen Fehler, Ausreißer oder kurzfristigen Ungenauigkeiten bekommt der Nutzer im Alltag gar nicht mit.
SFML hingegen schreibt diese Daten dauerhaft mit und macht solche Auffälligkeiten dadurch überhaupt erst sichtbar.

Wichtig dabei:
Der Code selbst kann weder technisch noch logisch Werte erfinden. Für ihn gilt immer: 1 + 1 = 2.
Wenn also irgendwo „seltsame Buckel“ oder auffällige Verläufe auftauchen, dann liegt die Ursache nicht in einem Bug des SFML-Codes, sondern in den Daten, die von Home Assistant beziehungsweise den angebundenen Sensoren geliefert werden.

Einmalige Ausreißer oder kurzfristige Fehler werden von SFML in der Regel ignoriert. Wenn solche Auffälligkeiten trotzdem sichtbar werden, spricht das eher dafür, dass ein Sensor, eine Entität oder eine von Home Assistant bereitgestellte Datenquelle wiederholt fehlerhafte oder ungewöhnliche Werte liefert.

Ist das kritisch? Nein.
Wir reden hier nicht von einer Laborumgebung. Ohne die grafische Darstellung würden solche Dinge vermutlich gar nicht auffallen. Die Visualisierung macht lediglich sichtbar, was in den zugrunde liegenden Daten ohnehin vorhanden ist.

Fazit:
Ich kann und werde an dieser Stelle nichts am Code ändern, weil der Code nicht die Ursache ist. Die Ursache liegt in den gelieferten Daten beziehungsweise in Home Assistant, den Sensoren oder den jeweiligen Datenquellen…

Man muss sich dabei auch die Relationen bewusst machen:
Wir sprechen hier von einer statischen Prognose, die bei etwa 8 von 10 Nutzern nur zwischen 2 und 15 % abweicht. Das ist für eine statische Prognose mehr als gut.

Es bringt daher wenig, hier Pfennigfuchserei zu betreiben, um die letzten Wh herauszuholen oder den Code dazu zu bringen, interne Fehler von Home Assistant zu korrigieren, zumal überhaupt nicht klar ist, ob es überhaupt Fehler von HA sind oder von der Software der Hardware selbst. Diese Fehlerquellen sind in der Praxis so vielfältig wie die jeweiligen Installationen, Sensoren, Konfigurationen und Meinungen dazu.

[Kaysen899]

@Tom-HA Ich wollte nur das Aufzeigen und bin gerade dabei zu schauen wo dies bei mir hätte passieren können. (Obwohl ich meine Sensoren sehr genau im Blick habe).

Deswegen beobachten und fertig.

Viel interessanter sehe ich das, nächstes Jahr, wenn SFML Daten da sind.

[Astrofreak85]

Ich hab ja auch nioe behauptet, das es ein Bug von SFML ist (ok ich habs erst im falschen Thread gepostet).

Ich bin mir relatif sicher, das es bei mir durch den einmaligen Ausreißer am 09.05. verursacht wurde, als HA beim Neustart den Tages-kWh Zähler kurz auf 0 gesetzt hat.

Das wa ich mich im wesentlichen aber frage ist:
Warum tauchte das erst jetzt im Forecast auf, und nicht erst eher? Interessanter weise ist es ja auch direkt wieder verschwunden.

Mich interessiert das technisch, warum das jetzt so war.
War das Wetter gestern zufällig sehr ähnlich dem am 2.5.? So dass die KI den “Fehler” eingerechnet hat?

“Das war mal so, bei dem Wetter, also ist es wahrscheinlich das es wieder so ist”

Und des weiteren wundert mich das nicht irgendein Safeguard gegriffen hat, weil es physikalisch sehr unwahrscheinlich wenn nicht gar unmöglich ist.

[Tom-HA]

@Kaysen899

Deswegen beobachten und fertig.

Das ist auch völlig korrekt. Bitte mich nicht Missverstehen!

Es war nie meine Intention, Bugs wegzudiskutieren. Im Gegenteil. Wenn es echte Bugs gibt, werden sie auch angesehen. Man muss sich nur immer wieder vor Augen halten, in welchem Rahmen SFML arbeitet.

Alles, was als Integration unter Home Assistant läuft, steht unter der „Knute“ des Supervisors und ist sehr eng reglementiert. Das ist auch verdammt gut und richtig so. Genau das schafft Sicherheit für den Nutzer und ist ein wesentlicher Unterschied zwischen einer Integration und irgendeiner App, mit der man sich im Zweifel eine Menge Mist ins System holen kann.

SFML ist eine Integration. 100 % nach den Vorgaben und Bedingungen von Home Assistant. Ohne eine einzige Ausnahme!

Das bedeutet aber auch: SFML baut 1:1 auf den Daten und Werten auf, die Home Assistant zur Verfügung stellt. SFML ist ein reiner Consumer beziehungsweise Leser. Es kann also nur mit dem arbeiten, was Home Assistant liefert.

Umgekehrt gilt das natürlich auch für Home Assistant selbst. Home Assistant kann ebenfalls nur das verarbeiten, was er von Sensoren, Integrationen, Clouds, Wechselrichtern, Gateways, Modbus, MQTT, APIs oder anderer Hardware geliefert bekommt.

Es gibt aber einen wichtigen Unterschied:
SFML arbeitet in vielen Bereichen deutlich feiner aufgelöst. Home Assistant ist an vielen Stellen grobschlächtiger, weil er für ein völlig anderes Ziel gebaut wurde.

Let’s talk KI:

Wir sprechen hier teilweise von Gewichtungen, die sich im Millionstel- oder Zehntausendstel-Bereich bewegen. Das ist ein Ritt auf der Rasierklinge.

Ich habe SFML an vielen Stellen abgesichert, um Ausreißer, unplausible Werte und kurzfristige Störungen abzufangen. Aber bei wiederkehrenden Problemen, fehlerhaften Sensorwerten oder Sensorfehlkonfigurationen hat das eine harte Grenze.

SFML kann aufgrund seiner Architektur und aufgrund des festen Willens, zu 100 % den Home-Assistant-Vorgaben zu folgen, keine Werte im Recorder korrigieren. SFML kann auch keine Werte direkt an Home Assistant vorbei abfragen, bewerten und dann so tun, als wären das die offiziellen HA-Daten.
Genau das wäre architektonisch falsch und würde dem Sinn einer sauberen Integration widersprechen.

Ein Beispiel aus der Wetter-KI-Gewichtung ICON:

Heute: 0,000023690
Gestern: 0,000023691

Das ist ein Unterschied von 0,000000001.

Das sind Größenordnungen, die Home Assistant in dieser Form gar nicht erfasst oder sinnvoll sichtbar macht. Für SFML können solche minimalen Unterschiede aber relevant sein, weil die Prognose intern mit sehr feinen Gewichtungen arbeitet.

Und genau deshalb gilt:
Wenn Home Assistant oder eine Datenquelle regelmäßig kleine Fehler, Sprünge oder Ungenauigkeiten liefert, dann kann sich das in der Darstellung zeigen. Nicht, weil SFML „phantasiert“, sondern weil SFML sehr genau auf das reagiert, was ihm geliefert wird.

[Astrofreak85]

sieht heute gut aus, die Wokeln vom Vormittag sind weg, wird also vermutlich sogar nen ticken besser…der markierte Buckel ist vemutlich tatsächlich wetterbedingt, hat zeitlich mit dem extremen Buckel von gestern nix gemein

[Tom-HA]

@Astrofreak85

Das wa ich mich im wesentlichen aber frage ist:
Warum tauchte das erst jetzt im Forecast auf, und nicht erst eher? Interessanter weise ist es ja auch direkt wieder verschwunden.

Das ist logisch durch den Code erklärbar — und genau genommen ist das sogar der aktive Schutzmechanismus.

Der Vorgang dahinter ist ziemlich komplex, aber ich versuche es mal ohne zu viel Nerd-Geschafel zu erklären:

Stell dir vor, du fährst morgens immer dieselbe Strecke zur Arbeit. Du kennst jede Kurve, jedes Schlagloch und weißt genau: Wenn du um 7 Uhr losfährst, brauchst du 20 Minuten. In 10 Jahren hast du auf dieser Strecke noch nie einen Blitzer gesehen. Also weißt du: Wenn es knapp wird, kannst du auch mal etwas schneller fahren, um pünktlich zu sein.

Jetzt gibt es plötzlich eine Baustelle und du musst eine andere Route fahren. Auch diese Route kennst du. Du weißt: Dort steht ein Blitzer, und du brauchst eher 25 Minuten. Wenn du zu spät losfährst, hast du keine Chance, die Zeit wieder reinzuholen. Also musst du dein Verhalten anpassen.

Dann wird die Baustelle aufgehoben und du kannst wieder deine alte Strecke fahren. Was du aber nicht weißt: Dort wurde inzwischen ein Blitzer aufgebaut. Du fährst wie früher — und rauscht voll rein.
Am nächsten Morgen weißt du es. Also fährst du langsamer oder bremst rechtzeitig vor dem Blitzer.

So ähnlich lernt SFML.

Der wichtige Punkt ist:
SFML darf nicht wegen eines einzelnen Ereignisses sofort sein komplettes Verhalten ändern. Denn ein einzelner Ausreißer kann alles Mögliche sein: ein Sensorfehler, ein Neustart, ein kurzzeitig falscher Wert, ein Cloud-Aussetzer oder irgendein einmaliger Effekt in Home Assistant.

Deshalb muss SFML denselben „Blitzer“ unter vergleichbaren Bedingungen mehrfach sehen.
Konkret: SFML muss ihn auf derselben Strecke drei Mal beziehungsweise über drei Tage erkennen, bevor es davon ausgeht, dass es kein einmaliges Ereignis war.

Umgekehrt gilt das genauso: Wenn der „Blitzer“ wieder weg ist, reicht auch ein einzelner Tag nicht aus, um sofort wieder alles zu verwerfen. SFML muss ebenfalls drei Tage unter vergleichbaren Bedingungen sehen, dass dieser Effekt nicht mehr auftritt.

Genau deshalb kann so etwas im Forecast auftauchen und danach wieder verschwinden. Das ist kein zufälliges Verhalten und kein Phantasieren des Codes, sondern Teil des Schutzmechanismus. SFML prüft, ob ein Muster stabil genug ist, bevor es daraus dauerhaft lernt oder eine Gewichtung wirklich verändert. → Darum ist es nur einmal bei Dir passiert… SFML ist Vollgas in den Blitzer gerast!

Nun doch etwas Nerd-Talk:

3 Tage = Sehr wahrscheinlich
7 Tage = valide
60 Tage = unumstößlich Bewiesen

[Astrofreak85]

Genau so erwarte ich die Funktionsweise von SFML.

Daher wundert mich ja der Ursprung des Buckels, es gab nur genau EIN Ereignis zu dem Zeitpunkt in der Historie, ich hab extra die DBs umgegraben um dahinter zu kommen.

Deshalb hab ich die “Anomaly” ja auch gepostet…nicht dass da mehr dahintersteckt.

[Tom-HA]

@Astrofreak85 @Kaysen899

Das kann mit den sogenannten Guardrails und Safeguards zusammenhängen.

Diese sind ein wichtiger Kernbestandteil der KI. Vereinfacht gesagt kann man sich das so vorstellen:

Guardrails sind Regeln wie: „Auf keinen Fall darfst du X tun.“
Safeguards sind Schutzmechanismen wie: „Wenn Y passiert, musst du sofort reagieren.“

Das ist im Grunde das Herz jeder verantwortungsvoll arbeitenden KI (und das aktuelle Problem von Claude). Diese Regeln bilden eine Art enges Handlungskonzept, damit die KI keinen Schaden anrichtet, nicht unkontrolliert reagiert und nicht aus jedem einzelnen Ereignis sofort falsche Schlüsse zieht.

SFML hat solche Guardrails und Safeguards ebenfalls. → sie sind der Kern und gehören in JEDE verantwortungsvoll entwickelte KI Niemand will einen Terminator der sich selbst erschafft und die Weltherrschaft an sich reißt.

Gehen wir noch einmal zurück zum Beispiel mit dem Weg zur Arbeit, um es etwas plastischer zu machen:

Du fährst morgens deine bekannte Strecke zur Arbeit. Normalerweise lernt SFML aus wiederkehrenden Mustern. Ein einzelnes Ereignis reicht also nicht aus, um sofort alles dauerhaft umzubauen. Deshalb braucht SFML bei normalen Auffälligkeiten mehrere vergleichbare Beobachtungen, bevor es daraus ein stabiles Muster ableitet.

Jetzt stell dir aber vor, du siehst auf deinem Arbeitsweg einen schweren Unfall.
In so einem Fall darf SFML nicht drei Tage lang abwarten, ob dort jeden Morgen wieder derselbe Mensch am Straßenrand liegt. Das wäre offensichtlich falsch. Dann muss sofort reagiert werden.

Übertragen auf das Beispiel bedeutet das:

Du hältst sofort an, sicherst die Unfallstelle ab, ziehst Handschuhe an (Safeguards), rufst den Krankenwagen und beginnst mit der Erstversorgung (Guardrails).

Genau dafür sind Guardrails und Safeguards da. Sie unterscheiden zwischen:

„Das könnte ein normales Muster sein, das wir erst beobachten müssen.“

und:

„Das ist ein kritischer Wert oder ein Schutzfall, auf den sofort reagiert werden muss.“

Wenn also ein Sensorwert eine Guardrail oder einen Safeguard triggert, wird diese Schutzlogik kurzfristig höher priorisiert als die normale Gewichtung. Alles andere wird in diesem Moment zweitrangig behandelt.
Am Folgetag wird dann wieder normal weitergerechnet, sofern sich dieser kritische Zustand nicht erneut zeigt.

Das kann erklären, warum ein Effekt kurzzeitig im Forecast sichtbar wird und danach wieder verschwindet.
Es bedeutet nicht automatisch, dass SFML falsch rechnet oder irgendetwas „phantasiert“.
Es kann schlicht bedeuten, dass ein einzelner Wert kurzfristig einen Schutzmechanismus ausgelöst hat, der genau dafür eingebaut wurde: nicht blind weiterzurechnen, wenn ein Wert plötzlich außerhalb des normalen Erwartungsrahmens liegt.

Lange Rede kurzer Sinn: Es ist komplex

Macht das für Dich Sinn… @Astrofreak85