BETA-TESTER GESUCHT: Selbstlernende / Intelligente Solarprognose (Integration via HACS)

Mein Verständnis ist es, dass er dann auch nicht sammelt. Erst ab morgen bei Dir. Deswegen habe ich es gestern Abend noch schnell installiert. :zany_face:

1 „Gefällt mir“

Ich verstehe das so, das zwar die Samples gesammelt werden, die tauchen in den Sensoren aber erst nach dem Lauf heute Abend auf.

Ich werde es verschmerzen können. :joy:

Abend,

habe heut mal son bisschen das Wetter beobachtet und mit dem DWD verglichen.
Laut DWD sollte es heut den ganzen Tag regnen und zu 100% bewolkt sein.
Also jetzt ist der Tag ja nun schon fast rum und bis jetzt nicht ein Tropfen von oben bzw der Himmel ist vorhin auch mal aufgerissen.
Habe DWD auch auf dem Handy da sah die Vorschau nicht anders aus. (Also Problem von DWD)

@Tom-HA
Wie weit werden jetzt die Daten die Prognose beeinflussen?

Wo wohnst Du? Hier regnet es den lieben langen Tag und es ist nie richtig hell geworden! NordWest Deutschland hier!

Bernau bei Berlin jetzt gerade fängt es ganz leicht an zu nieseln.

Werde das die Tage mal beobachten.

@Tom-HA welche Sensoren Daten muss der Wetterdienst bereit stellen für die Integration?

Sonst werde ich mal gucken was noch in frage kommen könnte.


Unterschiedlicher kann es nicht sein :face_with_peeking_eye:.

bin auch gerade bzgl. der DWD Wettervorhersage am grübeln - Problem bei mir die Wetterstation ist ein paar km weg und das kann schon Auswirkungen haben.

teste gerade OpenWetterMap, ob hier eine bessere Vorhersage getroffen wird

1 „Gefällt mir“

Ich habe heute einmal versuch die ganzen Sensoren zu erstellen bzw. richtig zu benenen und zu sortieren, scheitere aber daran.

Scheinbar bin ich einfach zu blöd.

Ich fasse jetzt einfach Mal zusammen wie ich das verstehe:

-Leistungs-Sensor (W): Aktuelle Ausgangsleistung der Wechselrichter in AC, ohne Batterie

-Tagesertrag (kWh): Tagesertrag aller Wechselrichter ohne Batterie, setzt sich um 0 Uhr zurück

-Tagesverbrauch (kWh): Summe aus Netzbezug und verbrauchter Batterieentladung. Muss am Tagesende nicht zurückgesetzt werden.

-Netzbezug Heute (kWh) und Netzeinspeisung Heute (kWh): Sind die ausgelesenen Istwerte vom Stromzähler. Müssen am Tagesende nicht zurückgesetzt werden.

Dann die Sensoren der Wetterstation, sowie die installierte Wechselrichterleistung und Batterieleistung.

-Batterie-Leistung (W, +/-): Aktuelle Batteausgangsleistung

-Batterie Ladezustand (%): Erklärt sich von selbst

-Solarzellenleistung (W): Die aktuelle DC Leistung aller Solarzellen zusammen gerechnet

-Wechselrichter-Leistung (W): Aktuelle Ausgangsleistung der Wechselrichter in AC, mit Batterie

-Hausverbrauch (W): Aktuelle Ausgangsleistung der Wechselrichter in AC + Aktuelle Ausgangsleistung der Batterie in AC + Netzbezug (W) - Netzexport (W)

-Netzbezug (W): Saldierter Messwerte vom Shelly ausgelesen

-Netzexport (W): Saldierter Messwerte vom Shelly ausgelesen und als positiver Wert umgewandelt

Die beiden optionalen Sensoren habe ich nicht

Ist das richtig so?

Da geht das Raten los.
Fragen blieben mir bis jetzt unbeantwortet.

Der Tagesverbrauch kWh sehe ich so = Netzbezug kWh + Tagesertrag kWh – Netzeinspeisung kWh

Die anderen auch als “24h Zähler” weil von der Bezeichnung her:

TAGESertrag
TAGESverbrauch
Netzbezug HEUTE
Netzeinspeisung HEUTE

Hausverbrauch W = Netzbezug W + (Leistungs-Sensor W + Akku/Batterie Entladung W) oder (Wechselrichter-Leistung W inkl Akku/Batterie)

aber da kann nur @Tom-HA für Aufklärung sorgen.

Scheinbar bin ich zu blöd

Weshalb?

Weil ich das Gefühl habe, dass alle anderen beim Erstellen von Helfern und Templates keine Probleme haben

BUG-TRACKER

BUG 1: ML verwendete Default-Werte statt echte Met.no Wetterdaten
Auswirkung: Vorhersagen lagen 400-500% zu hoch weil ML 50% Bewölkung statt 100% verwendete Status: Gefixt

BUG 2: Field Name Mismatch zwischen Weather Cache und ML Feature Engineering Auswirkung: ML konnte Wetterdaten nicht lesen wegen falschen Feldnamen
Status: Gefixt

BUG 3: Weather Cache hatte 48 doppelte Einträge mit Default-Werten
Auswirkung: 120 Einträge statt 72, Duplikate mit falschen Werten vermischten echte Daten
Status: Gefixt

BUG 4: Dummy-Forecast Timestamps mit Mikrosekunden
Auswirkung: Deduplizierung funktionierte nicht, Duplikate blieben im Cache
Status: Gefixt

BUG 5: Training Samples nach Neustart auf 0 zurückgesetzt
Auswirkung: ML wurde nicht verwendet trotz 56 vorhandener Trainingssamples
Status: Gefixt

BUG 6: last_training_samples wurde nicht wiederhergestellt
Auswirkung: Adaptive Blending gewichtete ML mit 0%
Status: Gefixt

BUG 7: Condition-Aware Defaults fehlten
Auswirkung: Bei fehlendem cloud_cover wurden neutrale Defaults statt wetterabhängige Werte verwendet
Status: Gefixt

BUG 8: Regen-Condition verwendete 60% Bewölkung statt 90-100%
Auswirkung: Über-Vorhersage bei Regenwetter
Status: Gefixt

BUG 9: Unnötige WARNING “Using default weather data as fallback”
Auswirkung: Logs voller harmloser Warnungen
Status: Gefixt

BUG 10: Unnötige WARNING “Only X training samples” Auswirkung: Logs voller harmloser Warnungen Status: Gefixt

BUG 11: Keine Met.no Empfehlung für User
Auswirkung: User wurden nicht darüber informiert das DWD durch zahlreiche Updates in den letzten Tagen seine Datenstruktur geändert hat. User verwendeten weiterhin DWD ohne numerische Werte ( War eine klare Empfehlung die NICHT mehr aufrecht erhalten werden kann)
Status: Gefixt

BUG 12: DWD liefert nur noch condition Strings keine Zahlen
Auswirkung: Keine cloud_cover oder temperature Werte verfügbar
Status: Gefixt mit condition-aware defaults

BUG 13: Keine Warnung wenn User nicht Met.no verwendet
Auswirkung: User wussten nicht dass Met.no besser ist DWD nicht mehr zu gebrauchen ist seit Update
Status: Gefixt

BUG 14: Config Flow prüfte nicht welche Weather Integration verwendet wird
Auswirkung: Keine Hilfestellung für optimale Integration
Status: Gefixt

BUG 15: strings.json fehlte weather_warning Step
Auswirkung: Warnung konnte nicht angezeigt werden
Status: Gefixt

BUG 16: Keine Dokumentation für Cloud Blending
Auswirkung: Feature nicht dokumentiert Status: Gefixt

BUG 17: Sensor-basiertes Cloud Blending nicht vorbereitet
Auswirkung: Keine Multi-Source Bewölkungs-Schätzung möglich
Status: Gefixt (Code vorbereitet, noch nicht aktiv)

BUG 18: Tages-Rotation schlägt fehl
Auswirkungen: Abschluss und verschieben in History schlägt fehl
Status: Gefixt

BUG 19: Astronomische Daten fehlerhaft
Auswirkungen: Anlagen-Performance und Ausrichtung mangelhaft
Status: Gefixt

BUG 20: Vorzeichen-Fehler bei Azimut
Auswirkungen: Sonnenstand und Sonnenlauf über die Panels fehlerhaft
Status: Gefixt

BUG 21: Missmatch Modulaufrufe fehlten
Auswirkungen: Zahlreiche Daten wurden nicht korrekt in die Files geschrieben
Status: Gefixt

BUG 22: Code-Reste V1
Auswirkungen: Willkürliche Auswahl von Features beim Start da V2 langsamer lädt
Status: Gefixt

BUG 23: PEP8 Probleme
Auswirkungen: Code nicht vorgaben getreu durch zuviele Anmerkungen
Status: Gefixt

Und noch einiges weiteres.

HINWEIS:
DWD Wetter-Intergration wird nicht mehr Unterstützt! Ihr habt bestimmt mitbekommen, dass es mehrere Updates in den letzten Tage gab. Leider ist sie nicht mehr kompatibel. Ich habe den Entwickler angeschrieben, leider ohne Antwort. Um derartige Abhängigkeiten in Zukunft zu vermeiden, werdn nun auch alle anderen Wetter-Intergration unterstützt - einzige Bedingung: Sie müssen Numerische Werte liefern keine Stings. Open WaetherMap und Co sind also nun 100% Kompatibel

1 „Gefällt mir“

Die Aussage war doch schon hier gewesen das es nur 5 Sekunden dauert.

Das genau das was ich meinte sobald man HA muss man alles wissen.
(Möchte nicht wissen wie viele evtl nen falschen Sensor hier irgendwo drin haben und somit kannst die Prognose vergessen bzw passt diese nicht)
Hilfestellungen sind immer gut.
Nur die Entwickler der Integration wissen in dem Moment nur was der Sensor liefern soll…

Das ist genau die Hilfestellung die hier halt noch fehlt bzw ausgebaut werden kann.

Sorry das musste ich jetzt mal so schreiben.

1 „Gefällt mir“

DWD dann garnicht mehr nutzen nur noch die Met.no ?

Also DWD ist raus? Interessant. Sollen wir jetzt Met.no verwenden oder funktionieren andere wie OpenWeartherMap weiterhin?

Die bug fixes, die du auflistest sind inwelchem Release gefixt?

s.o.:

“Um derartige Abhängigkeiten in Zukunft zu vermeiden, werdn nun auch alle anderen Wetter-Intergration unterstützt - einzige Bedingung: Sie müssen Numerische Werte liefern keine Stings. Open WaetherMap und Co sind also nun 100% Kompatibel”

Das kann ich verstehen. Die Problematik ist das die meisten die in diesem Thema unterwegs sind jenes tatsächlich aus dem Effeff können. Erschwerend kommt dazu, das viele Installationen aus Fernost stammen wo die Dokumentation eher dürftig und schlecht ist. Bei Fronius ist es eigentlich vorbildlich da die meisten abgefragten Sensoren sowieso existieren. Desweiteren wird hier ein sehr breiter Altersunterschied existieren. Die jüngeren könnten es und können es sich nicht leisten, die älteren können es sich leisten und müssen sich die Materie erst aneignen

3 „Gefällt mir“

Morgen Vormittag RC2 wieder als PREE-RELEASE kein Update muss manuell heruntergeladen werden. Status jetzt (bin noch am Debuggen) keine Breaking Changes

1 „Gefällt mir“

Dann ist DWD mal gleich Geschichte.
War eh von der Vorhersage bei mir nicht wirklich zu gebrauchen.

1 „Gefällt mir“

Hi,

für den Hausverbrauch habe ich ein Template und eine platform: integration (riemann) in die configuration.yaml eingefügt. Damit sehe ich dann die verbrauchten Watt und rechne das dann in kWh um. Da meine Batterie + beim Laden und - beim Enladen anzeigt muss das auch mit rein in die Berechnung. Sieht dann so aus:

##Watt plus Solarleistung minus Akku laden und entladen
      - 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)}}

Sieht erstmal komisch aus, da Shelly oder Powermeter aber bei hoher Solarleistung ins Minus gehen, passt das schon.

Und dann wird Watt in kWh umgerechnet. Ein Helfer macht dann einen Tages-kWh

  - platform: integration
    source: sensor.watt_haus
    name: watt_haus_kwh
    unit_prefix: k
    round: 1    
    method: left