Die Flussrichtung hat sich da noch nie geändert bei IM-/Ex-/port, sollte aber eigentlich sein wenn man es korrekt darstellen möchte.
Ich meinte, dass die Fließrichtung der Striche immer diesselbe ist. Also plump ausgedrückt: Die Striche bewegen sich (egal ob Bezug oder Export) immer vom Haus in Richtung Netz.
Sensoren sind korrekt. Es wechselt ja auch von Import zu Export etc. Nur ein kleiner “Schönheitsfehler”. Bei allen anderen ist das korrekt - da wechselt es.
Guten Morgen,
Timmys Buckel ist wieder da bei mir.
Und seit dem Update, fahren die Kallibierungsfaktoren wieder nach oben.
Prognose ist nach MDC weiterhin gut.
Die Wetterfaktoren für das neue Wetter regime müssen natürlich noch weiter Samples gesammelt werden.
2026-06-02 23:40:21 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather regime learning [low_sun_uncertain/morning]: best=physics, physics_mae=0.0007, ai_mae=N/A, tfs_mae=N/A, blend_bias=-0.0010 (1 samples)
2026-06-02 23:40:21 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather regime learning [dry_cloud_edge/morning]: best=blend, physics_mae=0.0315, ai_mae=0.0330, tfs_mae=0.0334, blend_bias=-0.0040 (1 samples)
2026-06-02 23:40:21 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather regime learning [low_ghi_overcast/morning]: best=blend, physics_mae=0.1933, ai_mae=0.1891, tfs_mae=0.1952, blend_bias=-0.1670 (3 samples)
2026-06-02 23:40:21 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather regime learning [low_ghi_overcast/midday]: best=ai, physics_mae=0.4592, ai_mae=0.3603, tfs_mae=0.3498, blend_bias=-0.3730 (2 samples)
2026-06-02 23:40:21 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather regime learning [rain_overcast/midday]: best=tfs, physics_mae=0.3964, ai_mae=0.2244, tfs_mae=0.1563, blend_bias=-0.2163 (3 samples)
2026-06-02 23:40:21 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather regime learning [rain_overcast/afternoon]: best=blend, physics_mae=0.0436, ai_mae=0.0424, tfs_mae=0.0584, blend_bias=0.0194 (5 samples)
Als Neueinsteiger kämpfe ich mich so langsam durch. Das Lernen des Systems dürfte noch am Anfang sein.Ich sehe aber bei mir eine Unstimmigkeit zwischen Solarertrag und Ist (= korrekter Wert)
ich werde im kommenden update (nach dem urlaub) den wert oben wieder entfernen, da es zu vielen verwirrungen (trotz erklärungen) führt. live vs abschlossenene std. scheint zu komplex / nicht klar genug differenziert zu sein.
Vielen Dank und noch einen schönen Resturlaub
Huhu,
Ich habe noch ein Thema für die Liste nach dem Urlaub.
Es gibt Situationen, das die Prognose niedriger als P10 ist.
Nach meiner Logik, sollte das nicht passieren, da ja P10 die pessimistische Variante ist.
Grüße
kannst du mal prf ob in der situation mdc ausgelöst hat oder hybrid?
Ich habe bei mir nur MDC aktiv.
Es gibt auch Tage ohne MDC wo Prognose unter P10 ist.
alles klar, dann gibt es ein problem danke für die info ich nehme das auf
Ich bekomme seit einigen Tagen die Anzeige 0 kWh als Prognose für übermorgen in stats.
Auch in der Integration ist der Wert 0.
Woran kann das liegen?
von heute
gestern
Hier noch Logauszüge vom EOD gestern abend:
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - INFO - Forecast complete: Today=20.34 kWh, Tomorrow=27.76 kWh, Day After=19.69 kWh, Method=AI + Physics
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.forecast.forecast_orchestrator - DEBUG - Forecast storage skipped for locked morning forecasts: today, tomorrow, day_after_tomorrow
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.core.core_coordinator_update_helpers - DEBUG - Forecast generated: today=20.34 kWh, tomorrow=27.76 kWh, method=AI + Physics, hourly_entries=72
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.production.production_history - DEBUG - Peak time calculation: Using stored hourly production data
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.core.core_coordinator_update_helpers - DEBUG - Forecast update skipped for locked morning forecasts: today, tomorrow, day_after_tomorrow
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.core.core_coordinator_update_helpers - DEBUG - Forecasts saved to database (respecting locks)
2026-06-05 23:52:08 - custom_components.solar_forecast_ml.coordinator - DEBUG - Hourly predictions cache refreshed: 24 today, 24 tomorrow, 0 day_after
Roten Neutstart habe ich natürlich gemacht.
Ha 2026.6 ? Scheinen gerade viele Integrationen Probleme zu haben schaue ich mir nach dem Urlaub mal an
Nein, bin noch bei 2026.5.4
Ist abrupt aufgetreten.
Weiterhin einen schönen Urlaub noch!
Gruß Stefan
1 „Gefällt mir“
Ich bin mir da nicht ganz so sicher, ich vermute momentan eher, das es an den Sensoren liegt. Ich hatte ja auch immer wieder den Buckel, aber der letzte Buckel den ich hatte ist vom 18.05.
Ich hatte ja damals diesen Thread losgetrehten: Sensoren ändern weil Total != String1 + String2
Und darauf hin meine Sensoren geändert.
- Ich habe die Sensoren so umkonfiguriert, wie dort beschrieben, jedoch gab es mit einer Automation in HA die Probleme, das die Automation bei der Änderung jeder der beteiligten Sensoren neu getriggert hat und ich Geisterpeaks erhalten hatte. Jetzt war es bei mir einfach das mit NodeRed umzusetzen, weil ich die Daten mir aus einer Influx-Datenbank besorge und in dem Flow habe ich das einfach mit eingebaut: Total - String1 - String2 = Differenz; dann diese Differenz anteilig auf die beiden Strings addiert.
- Ich berechne die Energie aus einem SQL-Riemann, hier gibt es ja um Mitternacht immer eine Verzögerung, weil der SQL-Sensor ja nicht laufend, sondern alle 30 Sekunden aktualisiert. Vielleicht hat auch das einen Einfluß. Ich habe hierfür eine Automation erstellt, der die drei Sensoren genau um 00:00 updatet, seitdem geht der SQL-Sensor wirklich um 0:00 auf Null zurück. Jedoch schreibt ja Zara, das SFML um 00:05:00 seinen neuen Nullpunkt setzt.
- Man kann ja in den SQL-Sensoren entweder Total oder Total_increasing auswählen. Ich hatte hier Total stehen. Ein anderer Thread hatte mich dazu verleitet das mal zu hinterfragen, das Beste für sich täglich Zurücksetzende SQL-Sensoren ist tatsächlich Total_increasing. Nur hierbei wird das Feld Last_Reset gesetzt, das benötigt zumindest das Energiedashboard in dieser Form.
Ob es nur Zufall ist, das ich seit 17 Tagen keinen Buckel mehr hatte, kann ich nicht sagen, ich bin noch weiter am beobachten. Vielleicht fällt Zara ja mit meinen Ausführungen etwas ein.
Zu Punkt 2 hier mal meine mini-Automation:
alias: SQL Sensoren um Mitternacht aktualisieren
triggers:
- at: "00:00:00"
trigger: time
actions:
- target:
entity_id:
- sensor.calc_dc_energy_nr_sql
- sensor.calc_dc_energy_string1_nr_sql
- sensor.calc_dc_energy_string2_nr_sql
action: homeassistant.update_entity
data: {}
Aber vielleicht habe ich - nachdem ich das hier geschrieben habe - morgen auch wieder den Buckel 
3x auf Holz klopfender Ralf
PS: hier noch der Link zum Thema Total vs Total_increasing:
Hallo Kai2,
guter Hinweis, das Diagram sieht bei mir so aus, also auch ein kleiner Buckel zu sehen. Das deutet wieder auf die Vermutung von Kaysen899 hin.
Diesen Buckel habe ich schon vor dem letzen Update beobachtet, aber nix gesagt… Ich habe ihn jetzt mit Werten eingefügt. Vielleicht kann man daraus etwas ableiten.
Der Buckel ist seit kurzem wieder da, also seit letztem Update.
Ich habe an meinen Sensoren nix geändert.