Ja, heute ist kein guter Tag für die Prognose:
Prognose: 4,43 kWh
Yield: 2,4 kWh
Mehr kommt da heute auch nicht mehr, ist ja jetzt dunkel.
heute war in ganz deutschland die Prognose schlecht.
Guten Abend…
Heute war ein sehr “unglücklicher” Tag. Alle mir bekannten Prognosen lagen (je nach Region) ziemlich daneben, auch die “Bezahldienste”.
Das finde ich ziemlich unbefriedigend. Es ist pure Spekulation, was nun das auslösende Momente gewesen ist (Wolken, Wetter,…).
Vor diesem Hintergrund habe ich ein Clamping zurück in den Code “geholt” um derartige Ausreißer besser zu kompensieren und das Lernen zurück auf Stundenbasis eingeführt. Also weg von dem Täglichen Lernen auf das kleinteilige stündliche Lernen. Allerdings begrenzt auf die Jahreszeiten (!!)
Wird im kommenden Release automatisch geändert. Befindet sich in der Erprobung
Hintergrund:
Es macht einen gewaltigen Unterschied ob bei 7 Stunden Produktion 3 Stunden daneben liegen oder bei 12 Stunden (Sommer) Effektiv sind das im Winter fast 50% Fehler und im Sommer nur 25%.
Es wurde ebenso eine “einfache” Grafik hinzugefügt (in SFML Stats) um schneller zu sehen "nähert " sich ML dem IST an (also lernt es) oder wird es schlimmer. Dieses soll die Fehlerbehebung verbessern! Auch bietet es einen besseren Überblick über die Geschwindigkeit und zeigt Fehler auf.
Zweite Änderung:
Solange ML und KI noch nicht aktiv sind wird das System einen Fallback nutzen. Es können im config_flow beliebig (OPTIONAL) viel Solarpannels mit Ausrichtung und Winkel eingebeten werden.
Beispiel:
Du hast 3 Panels a 400 Watt in Richtung Süden mit 30 Grad Winkel und 2 Panel 450 Watt 10 Grad Richtung Westen
- 1200 /180/30
- 900/270/10
3 usw,
5 „Gefällt mir“
@ Chriss
Wir müssen bei dir mal wirklich genauer schauen! Frage:
- Powersensor: gibt er den Wert der aktuellen Leistung der Solarzellen (nicht Ausgang WR)
- Yield-Sensor: Berechnet er den Täglichen Wert (und setzt sich um Mitternacht auf null) ausgehend vom Powersensor, also tatsächliche Leistung deiner Solarzellen nicht WR Ausgang)
- Hast du “echte” physikalische Sensoren hinzugefügt - die bei dir vor Ort im Garten stehen
- Sind deine “echten /physikalischen” Sensoren den kompletten Tag frei von Schatten?
- Hast Du ggf noch alte Daten im System?
Bei euch schaut das ja noch gut aus. Weit daneben heute bei mir und jeden Tag mind. doppelt so viel prognostiziert: (Die aktuelle Version wurde gleich nach Veröffentlichung eingespielt und seit dem Tag ist auch die EcoWitt in Betrieb)
Vielleicht auch bei mir ein Sensor nicht richtig zugeordnet oder Ähnliches. Nachdem ich im Hintergrund alle Posts mitlese, weiß ich natürlich, dass es zu jedem Sensor schon eine Erklärung seitens des Entwicklers gab. Jedoch habe ich mittlerweile den Überblick verloren, was nach den diversen Updates noch gilt und was nicht mehr. Gibt es irgendwo eine Zusammenfassung, was jetzt welcher Sensor (mit welcher Mitternachtsrückstellung / als Energie oder Leistung) und welcher Wetterwert wann wie wo was eingetragen werden muss. Ich bin hier evtl. nicht alleine mit diesen Sorgen….
Ich schiebe mal meine ML Diagnose auch noch hinterher:
1 „Gefällt mir“
habe dir eine Nachricht geschickt
Hallo Michael
Die Sensoren waren eigentlich schon immer klar definiert und haben sich auch nicht geändert.
Powersensor:
Ein Sensor in Watt der die aktuelle Leistung aller Solarzellen angibt.
Yield-Sensor:
Ein Sensor die er Leistung aller Solarzellen für 24 Std mit einem linken Riemann berechnet und sich um 24 Uhr zurücksetzt. Idealerweise folgt man dem HA Standart und erstellt zunächst einen klassischen Riemann (wie er auch in dem Energie-Dashboard verwendet wird) und erstellt dann einen klassischen Verbrauchszähler der sich täglich zurücksetzt.
WARNUNG:
Ein Verbrauchszähler basierend auf W ergibt am Ende des Tages keine kWh!! Es wird immer die Einheit des Baiszählers benutzt!
KilowattPeak:
Die Kw-Summe aller installierten Solarzellen - nicht Leistung des Wechselrichters!
Optionale Sensoren:
Optional kannst du dann noch lokale / physisch vorhandene Sensoren einbinden (Temperatur, Watt/m2 usw…
WARNUNG:
Keine Template-Spielerein um lokale Sensoren zu Faken! Oder irgendwelche Wetterstation-Integration Werte als “optionalen Sensor” einbinden. Das führt ins Chaos!
Häufige Fehlerquellen aus Debugging:
- User “basteln” optionale Sensoren auf Grund von Daten der Wetter-App > NoGo
- User berechnen aus LUX entsprechende W/m2 > NoGO
- User geben kwP falsch an z.B Wechselrichterleistung > NoGo
- User nehmen einen Shelly der die Einspeisung anzeigt als Leistung Solarzellen > NoGo
- User nehmen Ausgangsleistung WR als Leistung Solarzellen > NoGo
- User Manipulieren Json um Werte zu verbessern / korrigieren > NoGo
- User öffnen json mit TXT Programmen und beim Schließen klicken sie auch Speichern > NoGo
- User lokales Wetter war die ersten Tage nach der Installation immer gleich > Nichts zum Lernen
- …
Normales Verhalten:
- Ich der Installation war das Wetter sehr gleichmäßig (grau in grau) und plötzlich gibt es einen Sonnentag und die Prognose stimmt nicht > Korrekt da der erste Sonnentag eine Vielzahl von Korrekturen auslöst und erste wirkliche Einschätzungen über die Leistung der Anlage und Sonnenstrahlung ergibt
Habe alles noch mal gecheckt. Alle eingetragenen Sensoren stimmen. Ich habe sonst nichts am System umeinander gedreht/gefummelt. Seit dem Update lasse ich es einfach laufen und beobachte nur…
Ich war mit den Sensoren nur etwas irritiert, weil in einem der letzten Posts war der Luftdruck ein Thema (relativ/absolut). Und den hatte ich noch geändert gehabt, weil das am Anfang nicht klar war, was hier eingetragen werden sollte. Ich hatte nämlich prompt den relativen Luftdruck eingetragen gehabt.
Vielen Dank für deine Zusammenfassung.
1 „Gefällt mir“
Bei mir sieht es eigentlich auch ganz gut aus.
Sogar mit Einbindung weather underground 2 Straßen weiter aus der Nachbarschaft.
1 „Gefällt mir“
Ups, vertan, vertan. Das sollte eigentlich per PN raus. Können alle anderen einfach ignorieren.
Hi,
ich habe die Huawei-Integration schon sehr lange, es kann sein, daß einige Namen nicht stimmen. Oder bei Dir ins Deutsche übersetzt sind. Meine Codes stammen noch aus der Zeit, als es noch unique-ID gab. Ich müßte bei Namensänderung alle Codes ändern. Mach ich irgendwann.
Dieser Sensor zeigt den Solarertrag in Watt (Leistung). Das wäre der Leistungssensor.
##Gesamt Solar Power (Huawei und Terasse)
- name: "watt solar sum tag"
unique_id: "watt_solar_sum_tag"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >
{{ states ('sensor.inverter_input_power')|float(0)|round(0) }}
So sieht z.B. mein Sensor für den echten Hausverbrauch aus, wäre Bei Tom-HA der Tagesverbrauch. Ist der “echte Verbrauch” ohne Solar, Einspeisung, Batterie rein oder raus. Halt das, was die Geräte wirklich verbrauchen.
##Realer Verbrauch in Watt laut Zähler minus Akku laden und entladen und Einspeisung
- name: "watt haus"
unique_id: "watt_haus"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >
{% set solar_in = ((states ('sensor.watt_solar_sum_tag')|float(0)|round(0))) -%}
{% set power_meter = ((((states('sensor.power_meter_active_power')|float(0))*-1)|round(0))) -%}
{% set laden_akku = (((([0, states('sensor.battery_charge_discharge_power')|float(0)]|max)|round(0)))) -%}
{% set entladen_akku = ((((([0, (states('sensor.battery_charge_discharge_power'))|float(0)]|min)|round(0))*-1))) -%}
{{((power_meter) + (solar_in) + (entladen_akku) - (laden_akku))|float(0)}}
Aus der “Wirkleistung” Zähler Huawei müsstes Du den echten Verbrauch ableiten. Ist aber hier wohl nicht nötig.
Batterie-Kapazität noch eintragen. Alles andere brauchst Du erstmal nicht.
Zwei weitere Helper machst Du Dir aus Powermeter-Verbrauch und Powermeter-Einspeisung
mit täglichem Zyklus. Damit hast Du dann Netzbezug und Netzeinspeisung.
Diese Integrationseintragungen in der configuration.yaml stehen bei mir ganz unten. Hiermit rechne ich die “Watt-Sensoren” um in kWh. Mit diesen Sensoren bauen ich mir einen Helper mit täglichem Zyklus. Kann man einfach in der Geräte u. Dienste Abteilung. Diese Helfer sind auch Klasse für das Energy-Dashboard. Da kann man bei einem neuen Sensornamen einfach den Sensor wechseln, ohne die History zu verlieren. Und Batterie-Entladung erscheint nicht mehr als Solarertrag.
##Umrechnungen Watt in kWh
sensor:
- platform: integration
source: sensor.watt_solar_sum_tag
name: solar_ertrag_watt_zu_kwh_alle_wr
unit_prefix: k
round: 1
method: trapezoidal
max_sub_interval:
minutes: 5
- platform: integration
source: sensor.watt_haus
name: watt_haus_kwh
unit_prefix: k
round: 1
method: left
- platform: integration
source: sensor.grid_to_battery
name: kWh_batt_ladung_netz
unique_id: "kWh_batt_ladung_netz"
unit_prefix: k
round: 1
method: left
Ich hoffe, das ganze haut Dich jetzt nicht um. Frag, sobald eine Frage aufkommt.
mfg
Rainer Pache
Hast Du einen dynamischen Tarif? Oder Fragen zu Energiemanagement in Verbindung mit Huawei oder Huawei/Wärmepumpe. Seit fast 3 Jahren beschäftige ich mich intensiv damit.
Frag immer, wann Du willst.
Auch wenn das eine PN ist, die nicht an mich ging 
einige Anmerkungen
Das ist ein sehr guter Work-Arround! Zum Thema Dynamische Stromtarife… ich habe selber einen der 15 Stündlich berechnet wird - ziemlich cool! Problem es verfälscht meine tatsächlichen Kosten / Ersparnisse. Besonders wenn ich Akku`s lade zu “guten” Zeiten und entlade zu schlechten Zeiten.
Genau das Problem adressiere ich gerade mit Grid-Price-Monitor (GPM) und SFML Stats, in dem die Preise der jeweiligen Zeitperiode betrachtet werden. So kann ich sehr exakt sagen:
- Wieviel hat das Laden des Akku gekostet und wieviel habe ich dadurch in der Spitzenzeit gespart
- Wieviel hat das Heizen mit Wärmepumpe tatsächlich gekostet und wie hoch ist der Anteil an der Stromrechnung (oder Ev you name it)
- Wieviel Solar in den Akku und wieviel wurde direkt verbraucht - Wie hoch ist die Tatsächliche Einsparung durch direkten Verbrauch
- Ist Mein Akku groß genug um effektiv zu sein / ist er zu groß,
- uvm..
- Wie hoch wird meine Stromrechnung ausfallen und / oder wie hoch ist sie (gerade bei dynamischen Tarifen wichtig!
- Wie hoch ist der Anteil an Solarstrom / Akku / Netzbezug
Du sprichst da also ein Thema an das mich schon eine Zeit umtreibt und kommen wird. Es ist quasi alles das was das HA Dashboard nicht kann! Code-Name ist daher " Energie-Dashbord 2.0"
DIe Prognose ist schon da - Wichtig- nicht irgendwelche Börsenpreise sondern die Endpreise incl. der vertraglichen Kosten und Steuern.
Die kommen aus GPM wo auch festgelegt wird aber welchen ENDPREIS was passieren soll..
Die variablen Abgaben (Steuern, echt,..) werden dabei automatisch berechnet. Genauigkeit ENDPREIS vs Börsenpreis bei meinem Anbieter aktuell 0,02 Cent - damit kann ich leben!
Sobald der Preis sich unterhalb der Preisschwelle befindet, wird ein “Schalter” gesetzt der sich in jeder Automation verwenden lässt.
HINWEIS
Gleiches wird Solar Forecast ML auch erhalten, bei einem Schwellenwert X abzüglich des Verbrauches XY setze Schalter XYZ auf ein.. so lassen sich auch hier sehr einfach Last erzeugen oder Last abwerfen. Quasi eine virtuelle Nulleinspeisung - für alle die keinen Shelly oder anderes in den Zähler einbauen dürfen.
WICHTIGER HINWEIS! Riemann-Summen-Fehler bei Cloud-basierten Integrationen möglich!! Betroffen: Anker, EcoFlow, Shelly EM,…
Bei meiner Recherche zu den teilweise doch erheblichen Abweichungen bin ich auf ein Phänomen gestoßen, das ich mir zunächst nicht erklären konnte!
Ich kann nicht sagen, wen es alles betrifft, aber definitiv EcoFlow, Shelly EM und Anker, die über die jeweilige Custom Integration / Cloud angebunden sind. Vermutlich auch bei älteren 3-Phasen-WR (das ist aber Spekulation).
Problem
Die Integration /cloud sendet kein regelmäßiges Update - das gilt bei Anker für Smartmeter, WR, Solix,… Bei EcoFlow für den WR. Dadurch entsteht ein mathematischer Fehler, der nicht auf Anhieb zu erkennen ist - ein mieser Fehler!
Technische Erklärung
Der HA Riemann-Summen-Helfer berechnet: kWh = Watt mal Zeit seit letztem State-Change.
Das Problem: Wenn der Sensor nur bei Wertänderungen aktualisiert (nicht periodisch), und der Wert z.B. 30 Minuten bei exakt 1200W bleibt, gibt es keinen State-Change. HA zählt dann 0 kWh für diese 30 Minuten!
Auswirkungen
Es entstehen Lücken, wenn der Sensor längere Zeit denselben Wert meldet (z.B. konstant 1200W während der Akkuladung). Der Riemann-Helfer zählt nur bei State-Changes - bleibt der Wert 15 Minuten konstant, wird nichts gezählt. Das ist für einen Riemann-Sensor “tödlich” - Werte werden regelrecht “verschluckt”.
Beispiel (Real-Life)
Wir betrachten exemplarisch den 01.12. bis 04.12.2025 anhand des von der Integration zur Verfügung gestellten Solarleistungssensors (ist aber identisch zu ALLEN Anker-Sensoren) - einmal als Power (W) und einmal einen daraus erstellten Riemann (kWh). Als Vergleich nehmen wir noch die Anker-App.
Anker Solarleistung:
- Anker-App: 4,51 kWh
- HA Power-Sensor (manuell berechnet): 4,48 kWh
- HA Riemann-Helfer: 3,55 kWh - Verlust ca. 21%
Anker Smartmeter:
- Anker-App: 35,92 kWh
- HA Power-Sensor (manuell berechnet): 35,78 kWh
- HA Riemann-Helfer: 11 kWh - Verlust ca. 69%
Übrigens betrifft das Problem auch Shelly EM - nur nicht so heftig!
Lösung
Beim Anlegen des Riemann-Sensors “Max. Teilintervall” auf 00:05:00 (5 Minuten) setzen.
Das sagt HA: “Auch wenn sich der Wert nicht ändert, rechne alle 5 Minuten weiter.”
Wichtig: Das korrigiert nur zukünftige Werte! Bereits verlorene Energie ist unwiederbringlich.
Auswirkungen auf die Prognose
Was hat das nun mit der Solar-Prognose zu tun? Ich denke, das ist selbsterklärend!
Die Integration setzt den IST-Wert vom Riemann (Tageswert) gegen den Prognosewert für einen Zeitraum von 7 Tagen. Wenn dieser sich fehlerhaft aufsummiert, ist klar was passiert - die Prognose-Genauigkeit leidet massiv!
Zara
1 „Gefällt mir“
Na dann bin ich ja beruhigt:
HA hat für den Tagesverbrauch 3,32 kWh errechnet und Fronius zeigt mir 3,31 kWh an. 
ich hab bisher auch keine Probleme gehabt.
Die zählungen von Hoymiles und meiner Steckdose haben gepasst.
Aber hier habe ich die Daten Lokal von den Geräten geholt und nicht über die Cloud!
Das ist genau der Punkt… die API Abrufe bei einigen Cloud-Diensten haben ein Delay. Hoymiles und Fronius laufen dann ohne Probleme - notiert!
Ich glaub bei Hoymiles muss man aufpassen, gibt glaub ich auch die Möglichkeit diese mit der original DTU von Hoymiles einzubinden, aber glaub dann ist es auch so ein Cloud zeug, aber denke die meisten werden OpenDTU oder so nutzen, dann ist es kein Problem
Hallo,
beim täglichen Briefing steht bei mir jeden Tag:
Tageslicht: 12h 0min
Aufgang: 06:00 Uhr
Untergang: 18:00 Uhr
Ich vermute, dass dies der Standardwert ist. Wie kann ich hier die aktuellen Werte einpflegen?