So sieht es bei mir aus:
Was ich nicht weiß, woher die weißen Felder im Juli 9:00 und 11.00 bis 13.00 kommen. Oder soll das0 % Schatten sein, dann aber schlechte Farbwahl.
Du hast ja auch so Löcher im Juli
Nein, 7 Tage sollten ausreichen
Dann kennt Hubble sie auch und bezieht sie mit ein.
Allgemein für Alle… das ist eine Breaking Change ( wie im Update angegeben) und ich habe es im Auge. Es macht aktuell keinen Sinn hier einen BUG zu suchen.. ich kontrolliere täglich ob die neue DB und Logik korrekt gefüllt wird.
Ich suche keinen Bug - ich habe nur gefragt, wie lange es möglicherweise dauert um dann möglicherweise tätig zu werden.
Okay..
Solar Direktverbrauch habe ich nicht, da ich nen DC-Speicher hab. Also Module → Speicher → Wechselrichter.
DC Akku Entladungen und AC aus dem Wechselrichter hab ich.
Bei mir sind Schatten im Februar drin, sonst nix mehr, was mich wundert, hätte erwartet das ist komplett leer…
Ich habe STATS jetzt einige Tage mit einem kombinierten AC-Sensor laufen lassen, die Werte machen aus meiner Sicht Sinn. Die Akku zu AC Werte passen gut zu den Messungen die ein User im Akludoktor-Forum mit einem Deye Niedervolt WR wie meinem gemacht hat. Um die 80% bei niedrigen Lasten, um die 90% ab etwa 1 kW.
Kannst du mal schreiben wie du dein System konfiguriert hast?
Weil bei mir gibt es nicht solche Werte. ![]()
Kannst du bitte deinen Weg / Deine Lösung posten… vielleicht hilft es auch anderen bei WR → Stecker Akku Systemen!
Mein System besteht aus folgenden Komponenten:
-
Huawei Sun2000 30KTL-M3 Wechselrichter: Ausgelesen über die Modbus-Integration von wlcrs, über den Hotspot am Wechselrichter, Intervall 1 Sekunde für Anzeige. Ein zweites Mal ausgelesen über die gleiche Integration, aber über den Dongle am Wechselrichter, Intervall 30 Sekunden, für Logging.
-
Deye Sun 12K-SG04LP3-EU als reiner Batteriewechselrichter: ausgelesen über einen ESP32 am Modbus-Port, Intervall 5 Sekunden.
-
Akkus Seplos Mason 280 (14,3 kWh), mit Seplos 3.0 BMS: ausgelesen über einen ESP32 am Modbus-Port, Kommunikation mit dem Deye über CAN-Bus mit einem zwischengeschalteten ESP32 und zwei CANBUS-Transceivern, um den Ladestrom dynamisch steuern zu können ohne in den Registern des Deye oder des BMS herumschreiben zu müssen.
Direkt verwendbare Sensoren für SFML beim Huawei: AC-Ausgangsleistung, Leistung am Netzübergabepunkt, DC-Gesamtleistung.
Benötigte Template-Sensoren für SFML beim Huawei: MPPT-Leistung 1 bis 4, errechnet aus den per Modbus gelieferten Strom- und Spannungswerten.
Direkt verwertbare Sensoren für SFML beim Deye: AC-Leistung, Batterieleistung, SoC Akku
Man kann natürlich die Batterieleistung auch aus Spannung und Strom vom BMS berechnen, hat aber den Nachteil, dass das BMS keine Ströme unter 0.4 Ampere misst, der Wechselrichter am Batterieanschluss aber schon.
Die nötigen Sensoren habe ich mir mit der Powerhelper-Integration angelegt und in STATS eingefügt.
Der Leistungssensor für die kombinierte AC-Leistung der beiden Wechselrichter ist ein einfacher Template-Sensor zur Addition der Huawei- und Deye AC-Leistung:
- sensor:
- name: "AC_OUT_combined"
unique_id: AC_OUT_combined
unit_of_measurement: "W"
device_class: power
state: >
{% set AC1 = states('sensor.remote_inverter_active_power') | float(0) %}
{% set AC2 = states('sensor.sun12k_inverter_output_total_power') | float(0) %}
{{ (AC1+AC2) }}
Den habe ich in STATS als AC-Sensor konfiguriert. Wenn der Deye nicht lädt, dann geht seine AC-Leistung ganz leicht ins Minus, und durch den kombinierten Sensor müsste dieser Eigenverbrauch des Deye in die Wirkungsgradberechnung einfließen, was er nach meinen Beobachtungen auch tut, weil sich ein PV zu AC Wirkungsgrad von ca. 95 Prozent ergibt, der nur mit dem Huawei bei 97-98 Prozenz liegen würde.
Beim Laden geht die AC-Leistung des Deye entsprechend der Ladeleistung plus Eigenverbrauch ins Minus. STATS rechnet das aber offenbar mit der Akku-Ladeleistung gegen. Beim Entladen ist die AC-Leistung des Deye positiv. Es gibt Überschneidungen in der Früh und am Abend, wenn beide Wechselrichter ihren Anteil liefern, das scheint aber die Berechnung nicht zu beeinflussen.
Vielen Dank @michi84
Das ist eine klare und einfache Erklärung, die sich auf andere Anlagen übertragen lässt!
Zara
(Beitrag vom Verfasser gelöscht)
![]()
2026-08-01 01:07:20 - custom_components.solar_forecast_ml.services.service_extra_features - INFO - Extra feature 'grid_price_monitor' is up-to-date (v40.0.0)
2026-08-01 01:07:20 - custom_components.solar_forecast_ml.services.service_extra_features - INFO - Extra feature 'sfml_stats' is up-to-date (v40.0.4)
2026-08-01 01:07:20 - custom_components.solar_forecast_ml.services.service_extra_features - INFO - Extra feature 'solar_forecast_eai' is up-to-date (v40.0.4)
2026-08-01 01:07:20 - custom_components.solar_forecast_ml.services.service_extra_features - INFO - Extra feature 'weather_fusion_ai' is up-to-date (v40.0.0)
@suedschwede
Perfekt! Kannst Du bitte mal Testen ob das Handbuch sich korrekt öffnet und ob unter Wärme Pumpe die exzellente Arbeit von @Joachim-xo und @dietmar1968 " Bosch" zu sehen ist?
und ob der Graph in Weather Intelligence nicht mehr abgeschnitten / gestaucht ist.. war eine Meldung von @seebaer1976
Das wäre toll
Danke! Das ist wie immer ein riesen Hilfe! - dann hat HACS ja nichts verschluckt ![]()
Viel Spaß beim erforschen und testen.. kannst ja mal eine Apex-Karte anliegen mit folgenden Code ![]()
type: conditional
conditions:
- condition: state
entity: sensor.solar_forecast_energy_ai_wichtigste_wetterwarnung
state_not: "none"
card:
type: vertical-stack
cards:
- type: markdown
content: >-
{% set w =
states.sensor.solar_forecast_energy_ai_wichtigste_wetterwarnung %}
## ⚠️ {{ w.attributes.title | default('Wetterwarnung') }}
**Schweregrad:**
{{ 'Dringend' if w.attributes.severity == 'critical'
else 'Warnung' }}
**Gültig:**
{{ as_timestamp(w.attributes.start)
| timestamp_custom('%d.%m.%Y · %H:%M', true) }}
bis
{{ as_timestamp(w.attributes.end)
| timestamp_custom('%d.%m.%Y · %H:%M', true) }} Uhr
{{ w.attributes.recommended_action }}
- type: custom:apexcharts-card
graph_span: 48h
update_interval: 1min
span:
start: hour
header:
show: true
title: Zeitfenster der Wetterwarnung
show_states: false
now:
show: true
label: Jetzt
apex_config:
chart:
height: 190px
toolbar:
show: false
legend:
show: false
tooltip:
x:
format: "dd.MM. HH:mm 'Uhr'"
grid:
borderColor: rgba(128, 128, 128, 0.2)
yaxis:
- min: 0
max: 2
decimals: 0
show: false
series:
- entity: sensor.solar_forecast_energy_ai_wichtigste_wetterwarnung
attribute: warning_count
name: Warnung
type: area
color: "#ff9800"
opacity: 0.55
curve: stepline
stroke_width: 1
extend_to: false
data_generator: |
const a = entity.attributes;
if (
a.severity !== "warning" ||
!a.start ||
!a.end
) {
return [];
}
const warningStart =
new Date(a.start).getTime();
const warningEnd =
new Date(a.end).getTime();
if (
!Number.isFinite(warningStart) ||
!Number.isFinite(warningEnd) ||
warningEnd <= warningStart
) {
return [];
}
return [
[warningStart - 1, 0],
[warningStart, 1],
[warningEnd, 1],
[warningEnd + 1, 0]
];
- entity: sensor.solar_forecast_energy_ai_wichtigste_wetterwarnung
attribute: warning_count
name: Dringend
type: area
color: "#e53935"
opacity: 0.6
curve: stepline
stroke_width: 1
extend_to: false
data_generator: |
const a = entity.attributes;
if (
a.severity !== "critical" ||
!a.start ||
!a.end
) {
return [];
}
const warningStart =
new Date(a.start).getTime();
const warningEnd =
new Date(a.end).getTime();
if (
!Number.isFinite(warningStart) ||
!Number.isFinite(warningEnd) ||
warningEnd <= warningStart
) {
return [];
}
return [
[warningStart - 1, 0],
[warningStart, 2],
[warningEnd, 2],
[warningEnd + 1, 0]
];
Dir / euch ein schönes Wochenende!
Wo findet sich denn das Handbuch?
Seit zwei Tagen wird im EOD die u.a. Fehlermeldung ausgegeben. (nstallierte Version SFML 40.0.2)
Hab ihr einen Tip wie der Fehler behoben werden kann.
Logger: custom_components.solar_forecast_ml.production.production_scheduled_tasks
Quelle: runner.py:289
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 31. Juli 2026 um 23:30:02 (1 Vorkommnis)
Zuletzt protokolliert: 31. Juli 2026 um 23:30:02
End-of-day workflow partial (13/16): Weather MLP: insufficient training data (0/50 samples); AI model: candidate shadow evaluation pending for b77a58f5-43ba-4d27-b2fd-3db55c84490a; Shadow Pattern Learning: Gruppe 1: No shadow detection data available
2026-07-31 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Weather MLP training skipped: insufficient training data (0/50 samples)










