76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

Das ist recht einfach. Zeig mal bitte die Definition von deinem userReading.

Code Auswählen Erweitern

forecast_json {

    use strict;
    use warnings;
    use JSON;
    use DateTime;
    use DateTime::Format::Strptime;

    my $hour = 0;
    my @output;

    # Parser für Datum mit CET/CEST
    my $parser = DateTime::Format::Strptime->new(
        pattern   => '%Y-%m-%d %H:%M:%S',
        time_zone => 'Europe/Berlin',
    );

    # Alle NextHour-Daten durchsuchen
    while ($hour < 100) {
        my $hour_str = sprintf('NextHour%02d', $hour);
        my $start_str = FHEM::SolarForecast::NexthoursVal ('solErtrag', $hour_str, 'starttime', 'na');
        my $pvfc = FHEM::SolarForecast::NexthoursVal ('solErtrag', $hour_str, 'pvfc', 'na');

        # Schleife beenden, wenn keine Werte mehr vorhanden sind
        last if $start_str eq 'na' or $pvfc eq 'na';

        # parse und konvertiere Zeit
        my $start_dt = $parser->parse_datetime($start_str);
        my $end_dt   = $start_dt->clone->add(hours => 1);

        # nach UTC konvertieren
        $start_dt->set_time_zone('UTC');
        $end_dt->set_time_zone('UTC');

        push @output, {
            start => $start_dt->iso8601() . 'Z',
            end   => $end_dt->iso8601() . 'Z',
            value => 0 + $pvfc,
        };
       
        $hour++;
    } 

    # Ausgabe als JSON
    my $json = JSON->new->utf8->pretty->encode(\@output);
    return $json;
}

[DS_Starter]

Naja ich meinte das attr ... userReadings , nicht die Sub.

[grappa24]

Naja ich meinte das attr ... userReadings , nicht die Sub.

na ja, ich hab die Sub komplett in das attr reingeschrieben 

[DS_Starter]

Und wie sieht das Attribut als Ganzes aus? Nur die Sub kann da ja nicht allein drin stehen.

[grappa24]

Code Auswählen Erweitern

attr solErtrag userReadings

special_todayEVG { ReadingsNum("solErtrag", "special_todayGridFeedIn",0) * 0.08 / 1000 },

forecast_json {

    use strict;
    use warnings;
    use JSON;
    use DateTime;
    use DateTime::Format::Strptime;

    my $hour = 0;
    my @output;

    # Parser für Datum mit CET/CEST
    my $parser = DateTime::Format::Strptime->new(
        pattern   => '%Y-%m-%d %H:%M:%S',
        time_zone => 'Europe/Berlin',
    );

    # Alle NextHour-Daten durchsuchen
    while ($hour < 100) {
        my $hour_str = sprintf('NextHour%02d', $hour);
        my $start_str = FHEM::SolarForecast::NexthoursVal ('solErtrag', $hour_str, 'starttime', 'na');
        my $pvfc = FHEM::SolarForecast::NexthoursVal ('solErtrag', $hour_str, 'pvfc', 'na');

        # Schleife beenden, wenn keine Werte mehr vorhanden sind
        last if $start_str eq 'na' or $pvfc eq 'na';

        # parse und konvertiere Zeit
        my $start_dt = $parser->parse_datetime($start_str);
        my $end_dt   = $start_dt->clone->add(hours => 1);

        # nach UTC konvertieren
        $start_dt->set_time_zone('UTC');
        $end_dt->set_time_zone('UTC');

        push @output, {
            start => $start_dt->iso8601() . 'Z',
            end   => $end_dt->iso8601() . 'Z',
            value => 0 + $pvfc,
        };
       
        $hour++;
    } 

    # Ausgabe als JSON
    my $json = JSON->new->utf8->pretty->encode(\@output);
    return $json;
}

[DS_Starter]

Ok, das klappt so nicht. Das erste userReading ist special_todayEVG (auch ohne Trigger).

Ein Trigger ist ein Reading welches immer ein Event generieren muß. z.B hier 'data_qmpstatus' :

Code Auswählen Erweitern

message:data_qmpstatus.* {
    my $dval = ReadingsVal ($name, 'data',    '');
    my $mval = ReadingsVal ($name, 'message', '');
    !$dval ? $mval : 'none';
}

Dein erstes UR würde z.B. so aussehen können:

Code Auswählen Erweitern

special_todayEVG:special_todayGridFeedIn.* { ReadingsNum("solErtrag", "special_todayGridFeedIn",0) * 0.08 / 1000 }

Sobald special_todayGridFeedIn ein Event wirft (Events zulassen!), wird dein special_todayEVG erstellt. Und nur dann! einmalig was enorm Performance bringt.

Den forecast_json code würde man jetzt in userReadings hinzufügen mit einem weiteren zu erstellenden Reading 'jsonReading':

Code Auswählen Erweitern

special_todayEVG:nextCycletime.* { ReadingsNum("solErtrag", "special_todayGridFeedIn",0) * 0.08 / 1000 },
jsonReading:nextCycletime.* { forecast_json {...} }

Wenn nextCycletime einen Event wirft (Events zulassen!) wird das Reading special_todayEVG und auch jsonReading generiert. Und wieder nur dann!
Besser ist es forecast_json in 99_myUtils zu schreiben und nur die Sub mit main::forecast_json() in userReadings zu hinterlegen.

So sollte es klappen. Hoffe keinen Fehler auf die Schnelle eingebaut zu haben.

LG,
Heiko

[grappa24]

Danke Heiko,
das hat funktioniert 
Werde morgen mal drüber nachdenken und auch forecast_json in 99_myUtils auslagern.
Gruß, Dieter

[All-Ex]

Ich habe das Wiki angepasst. Du kannst auch die erste Zeile im User-Reading so anpassen: forecast_json:nextCycletime.* {
Der Code wird dann nur ausgeführt, wenn das Reading nextCycletime ein Event erzeugt.

[grappa24]

Ein Trigger ist ein Reading welches immer ein Event generieren muß. z.B hier 'data_qmpstatus' :

d.h. letzen Endes sollte jedes UR einen Trigger haben? Da muss ich aber mal meine URs überdenken

[DS_Starter]

Moin,

Ja genau. Ohne Trigger wird das UR bei jedem! Event des Devices neu generiert. Kannst dir ja vorstellen wie das auf die Performance deines Systems wirkt. Zumal alle Events dann noch duch FileLog, DbLog etc. behandelt werden.

Lg,
Heiko

[grappa24]

Ja genau. Ohne Trigger wird das UR bei jedem! Event des Devices neu generiert.

Wie heißt es so schön: "Man wird alt wie ne Kuh und lernt immer noch dazu"

[Burny4600]

@Heiko

Ich weiß, ich bin lästig, aber mir hat das mit dem Dummy-Verbraucher keine Ruhe gelassen.
Die korrekte Dummy-Verbraucher Ermittlung funktioniert nur mit der Standartkonfiguration wie unter forum.fhem.de/index.php?action=dlattach;attach=185037;image
Dummy Verbraucher (438) = Hausknoten Verbrauch (2510) - ∑ Verbraucher (2071,8)

Binde ich die beiden Batterien mittels setupInverterDevXX

Code Auswählen Erweitern

Deye_12k_SFD
ac2dc=Akku_Leistung_In__W:W dc2ac=Akku_Leistung_Out__W:W
capacity=24000
strings=none
asynchron=0passt die Berechnung des Dummy-Verbrauchers nicht und stellt sich wie folgt zusammen.

Bat 1 Ladung:  590 W
Bat 2 Ladung: 1600 W
Hausknoten Verbraucher: 1814 W
Dummy Verbraucher (3018) = Hausknoten Verbraucher (1814) - ∑ Verbraucher (986) + Batterieladung 1 (590) + Batterieladung 2 (1600)

Der korrekte Wert des Dummy-Verbrauchers wäre aber 828 W
Weil aber mit dieser Konfiguration die beiden Batterieladungen als Verbrauch für den Dummy-Verbraucher herangezogen werden, passt das Ganze nicht mehr zusammen.
Der Hausknoten Verbraucher stimmt mit den 1814 W.

Nur wie ich diese Korrektur in SF einbinden könnte, damit der gesamte Verbrauch inklusive Dummy-Verbraucher stimmt, dazu fehlt mir die Lösung.
Zumindest kenne ich jetzt die Ursache bei meiner Konfiguration warum der Dummy-Verbraucher nicht stimmt.

[DS_Starter]

Hallo Chris,

so richtig kann ich mir noch keinen Reim darauf machen.
Lade dir bitte die V aus meinem contrib und schalte ctrlDebug=collectData ein.

Du wirst dann solche Zeilen finden:

Code Auswählen Erweitern

2025.08.05 22:09:36.105 1: SolCast DEBUG> current Power values -> PV2Node: 0 W, PV2Bat: 0, PV2Grid: 0 W, Other: 0 W, GridIn: 0 W, GridCon: 22 W, BatIn: 0 W, BatOut: 587 W
2025.08.05 22:09:36.105 1: SolCast DEBUG> current Consumption result -> 609 W
2025.08.05 22:09:36.106 1: SolCast DEBUG> current Power Battery Inverter -> DC2Inv2Node: 607 W, Node2Inv2DC: 0 W

Poste die dann bitte. Am Besten 3 oder 4 dieser Messungen.

HINWEIS: In dieser V gibt es Weiterentwicklungen. Sind DWD-Devices eingebunden, wird jetzt das Attr forecastDays=2 (oder höher) im DWD-Device erwartet. Anderenfalls gibt es Warnungen im Logfile.

LG,
Heiko

[300P]

WOW - Morgen gibts wohl gewaltig was auf die PV-Panel       

Heute ca. 48 kWh mit mehrfach Regen am Morgen bis 11:00 Uhr
Morgen sollen es laut SF-Vorhersage mehr als 114 kWh bei mir werden (bei insgesamt 9.5 kW WR-Leistung)
==>> "Highscore" dieses Jahr am Abend vorher

[DS_Starter]

WOW - Morgen gibts wohl gewaltig was auf die PV-Panel

Ich habe es doch geahnt dass die Erweiterung der Nexthours Stunden Nebenwirkungen haben wird die nicht sofort ins Auge fallen.