76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ineffizient ist sicher auch, dass bei jedem Event zweimal "ReadingsNum" aufgerufen wird

Kannst ja mal schauen ob du userReadings so verwendet bekommst, dass zwei neue Readings mit nur einem ReadingsNum Lesen erzeugt werden können.
Natürlich könnte man ein notify benutzen und mit etwas Logik zwei neue Readings erzeugen. Viele Wege ...

[grappa24]

Leistungsorientierte Beladungssteuerung mittels Battery_ChargeOptTargetPower_XX

Ich hab das jetzt mal umgesetzt, ihr seid richtig gut 

Eine einfache Frage: Das o.a. Reading ändert sich ja teilweise relativ häufig (Anlage), ist das denn für die Batterie o.k. wenn man den Wert ständig anpasst? Ich vermute, es ist sogar so gewollt 

Code Auswählen Erweitern

2025-09-15_08:00:06 solErtrag Battery_ChargeOptTargetPower_01: 5701 W
2025-09-15_08:00:24 solErtrag Battery_ChargeOptTargetPower_01: 6809 W
2025-09-15_08:10:46 solErtrag Battery_ChargeOptTargetPower_01: 6810 W
2025-09-15_08:12:46 solErtrag Battery_ChargeOptTargetPower_01: 6809 W
2025-09-15_08:17:46 solErtrag Battery_ChargeOptTargetPower_01: 6810 W
2025-09-15_08:23:46 solErtrag Battery_ChargeOptTargetPower_01: 6809 W
2025-09-15_08:26:49 solErtrag Battery_ChargeOptTargetPower_01: 6808 W
2025-09-15_08:30:49 solErtrag Battery_ChargeOptTargetPower_01: 6807 W
2025-09-15_08:35:51 solErtrag Battery_ChargeOptTargetPower_01: 6806 W
2025-09-15_08:41:28 solErtrag Battery_ChargeOptTargetPower_01: 1758 W
2025-09-15_08:41:34 solErtrag Battery_ChargeOptTargetPower_01: 6864 W

[Parallix]

Ineffizient ist sicher auch, dass bei jedem Event zweimal "ReadingsNum" aufgerufen wird

Kannst ja mal schauen ob du userReadings so verwendet bekommst, dass zwei neue Readings mit nur einem ReadingsNum Lesen erzeugt werden können.
Natürlich könnte man ein notify benutzen und mit etwas Logik zwei neue Readings erzeugen. Viele Wege ...

Im einem User-Reading-Codeblock müsste man doch via "setreading" ein anderes User-Reading setzen können, oder? Ahh, ich sehe gerade, dass das wohl nicht geht. Richtig?

Edit: Die Nutzung von DOIFs und NOTIFYs finde ich an o.g. Stelle unschön, da die Werte dann nicht mehr direkt vom bzw. am Device gesetzt werden.

@Heiko: Wäre es nicht komfortabel und vielleicht auch effizient, wenn Du die Trennung eines vorzeichenbehaftete In/Out-Readings in zwei einzelne vorzeichenlose Readings direkt in SF vornimmst?

[Parallix]

Eine einfache Frage: Das o.a. Reading ändert sich ja teilweise relativ häufig (Anlage), ist das denn für die Batterie o.k. wenn man den Wert ständig anpasst?

Hier sehe ich kein Problem. Das macht die Regelung eines Wechselrichters sogar noch viel häufiger!

[DS_Starter]

@Heiko: Wäre es nicht komfortabel und vielleicht auch effizient, wenn Du die Trennung eines vorzeichenbehaftete In/Out-Readings in zwei einzelne vorzeichenlose Readings direkt in SF vornimmst?

Tatsächlich habe ich dies bereits bei setupBatteryDevXX implementiert:

Sonderfälle: Sollte das Reading für pin und pout identisch, aber vorzeichenbehaftet sein, können die Schlüssel pin und pout wie folgt definiert werden:

    pin=-pout    (ein negativer Wert von pout wird als pin verwendet)
    pout=-pin    (ein negativer Wert von pin wird als pout verwendet)


Für die Batterieinverter-Schlüssel (ac2dc/dc2ac) ist das aktuell noch nicht der Fall.

[Parallix]

@Heiko: Wäre es nicht komfortabel und vielleicht auch effizient, wenn Du die Trennung eines vorzeichenbehaftete In/Out-Readings in zwei einzelne vorzeichenlose Readings direkt in SF vornimmst?

...
Für die Batterieinverter-Schlüssel (ac2dc/dc2ac) ist das aktuell noch nicht der Fall.

Genau deshalb hatte ich ja gefragt. Überdies wäre dann ja wahrscheinlich auch der unschöne Effekt, den Martin beschreibt, nämlich die Asynchronität von der Readings, nicht mehr relevant.

Was ich übrigens noch gerne wüsste ist, ob es eine Möglichkeit gibt, SF so zu konfigurieren, dass Readings (wie Battery_ChargeAbort_XX, Battery_ChargeRecommended_XX und Battery_ChargeRequest_XX) und deren Zeitstempel nicht mit jedem Update der Webseite aktualisiert werden, sodass dann erkennbar ist, wann der Wert eines Readings sich zuletzt geändert hat.

[DS_Starter]

Ich habe einen Abschnitt ins Wiki eingefügt:

  7.2.6 Welche Ladestrategie soll ich wählen? - eine Möglichkeit zur Best-Practice Findung mit Codebeispiel


Ihr könnt es euch ja mal anschauen. Das Beispielscript habe ich bei mir im Einsatz und ist sicherlich mit entsprechenden individuellen Anpassungen auch für andere Anlagen einsetzbar.

LG,
Heiko

[DS_Starter]

Was ich übrigens noch gerne wüsste ist, ob es eine Möglichkeit gibt, SF so zu konfigurieren, dass Readings (wie Battery_ChargeAbort_XX, Battery_ChargeRecommended_XX und Battery_ChargeRequest_XX) und deren Zeitstempel nicht mit jedem Update der Webseite aktualisiert werden, sodass dann erkennbar ist, wann der Wert eines Readings sich zuletzt geändert hat.

Es gibt in FHEM ganz allgemein für die Entwicklung eine Funktion readingsBulkUpdateIfChanged die genau das bei der Readinggenerierung tut. Unschön (von meinem Standpunkt aus gesehen) ist bei dieser Funktion, dass man eben nicht sieht ob das Reading beim letzten Zyklus gesetzt wurde oder nicht. Weil evetuell ein Fehler vorliegt der das Setzen des Readings verhinderte o.ä.
Aber die Abwägung des Vorteils/Nachteils liegt, wie bei vielen Dingen im Leben, im Auge des Betrachters/Nutzers.

[Parallix]

Was ich übrigens noch gerne wüsste ist, ob es eine Möglichkeit gibt, SF so zu konfigurieren, dass Readings (wie Battery_ChargeAbort_XX, Battery_ChargeRecommended_XX und Battery_ChargeRequest_XX) und deren Zeitstempel nicht mit jedem Update der Webseite aktualisiert werden, sodass dann erkennbar ist, wann der Wert eines Readings sich zuletzt geändert hat.

Es gibt in FHEM ganz allgemein für die Entwicklung eine Funktion readingsBulkUpdateIfChanged die genau das bei der Readinggenerierung tut. Unschön (von meinem Standpunkt aus gesehen) ist bei dieser Funktion, dass man eben nicht sieht ob das Reading beim letzten Zyklus gesetzt wurde oder nicht.
...

Das sehe ich auch so!

Wenn ich nicht falsch liege, dann gibt es doch eine Funktion, mit der geprüft werden kann, ob ein Update auch auch zu einer Wertveränderung geführt hat. Nun frage ich mich: Lässt sich auf Basis der hierfür erforderlichen Metadaten zu einem Reading die (Detail)Ansicht zu SF so erweitern, sodass neben dem Update-Zeitstempel auch ein Wertänderungs-Zeitstempel angefügt wird, der bei ein Webseiten-Update gleich bleibt, wenn sich der Wert zwischenzeitlich nicht verändert hat?

[MartinD]

@Heiko
Vielen Dank für die Analyse und Hinweise zu BatIn/BatOut.
Wenn ich Deinem Rat folge:

Wenn es zu schwierig sein sollte pvOut nur mit dem PV-Anteil zu ermitteln, kannst du auch den Wert für pvIn ebenfalls für pvOut benutzen. Dadurch wird zwar die Inverter Verlustleistung unterschlagen, aber als Notlösung würde es gehen um erstmal weiterzukommen.

heben sich die Werte auf, oder? Wird da noch was berechnet?

Es kristallisiert sich immer deutlicher, dass mir nicht die richtige Readings zur Verfügung stehen,
bzw. dass ich die Readings nicht korrekt erzeugen kann.

Ich benutze sowohl SolarEdgeAPI wie auch AttrModbus.

In SolarEdgeAPI habe ich (nach commandref ):

Code Auswählen Erweitern

    status-grid_power [W]     --> entspricht den Werten für Energiebezug auf Monitoring-Plattform
    status-load_power [W]     --> entspricht den Werten für Hausverbrauch auf Monitoring-Plattform
    status-pv_power [W]       --> entspricht den Werten für Leistung der Panelle auf Monitoring-Plattform
    status-storage_power [W]  --> entspricht den Werten für Speicher auf Monitoring-Plattform (Vorzeichenbehaftet)
    storage-XXXXXXXX-lifeTimeEnergyCharged --> keine Entsprechung auf Monitoring-Plattform
    storage-XXXXXXXX-lifeTimeEnergyDischarged --> keine Entsprechung auf Monitoring-Plattform
Dieses Modul könnte evtl. weitere Werte liefern, wird aber offensichtlich nicht weiter gepflegt.
Anfrage an Modul-Maintainer blieb erfolglos. (dies ist _keine_ Klage!)

In AttrModbus habe ich (nach Wiki )

Code Auswählen Erweitern

    I_AC_Power     [kW]          --> liefert Werte > 0 auch in der Nacht
    I_AC_Energy_WH [kWh]         -->  keine Entsprechung auf Monitoring-Plattform
    I_DC_Power     [kW]          --> Tagsüber entspricht den Werten für Leistung der Panelle auf Monitoring-Plattform
    M_AC_POWER     [kW]          --> Anzeige unzuverlässig
    M_Exported     [kW]          --> Zeigt konstant einen Fantasiewert, keine Entsprechung auf Monitoring-Plattform
    M_Imported     [kW]          --> Zeigt konstant einen Fantasiewert, keine Entsprechung auf Monitoring-Plattform
    B_Instantaneous_Power [kWh]            --> entspricht den Werten für Energiebezug auf Monitoring-Plattform
    B_Lifetime_Export_Energy_Counter [kWh] --> ist nicht "Lifetime" - wird um 22:45 zurückgesetzt, sont zuverlässig
    B_Lifetime_Import_Energy_Counter [kWh] --> ist nicht "Lifetime" - wird um 22:45 zurückgesetzt, sont zuverlässig
   
M_AC_POWER wird bei mir so definiert:

Code Auswählen Erweitern

obj-h40206-expr  $val * (10 ** ReadingsNum ('SolarEdge' ,'M_AC_Power_SF',0))/100
obj-h40206-reading  M_AC_POWER
obj-h40206-unpack  s>

M_AC_Power_SF:

Code Auswählen Erweitern

obj-h40210-reading  M_AC_POWER_SF
obj-h40210-unpack s>

M_Exported:

Code Auswählen Erweitern

obj-h40226-expr $val * (10 ** ReadingsNum ('SolarEdge' ,'M_Energy_W_SF',0))
obj-h40226-format %.2f
obj-h40226-len 2
obj-h40226-reading M_Exported
obj-h40226-unpack s>
M_Imported

Code Auswählen Erweitern

obj-h40234-expr $val * (10 ** ReadingsNum ('SolarEdge' ,'M_Energy_W_SF',0))
obj-h40234-format %.3f
obj-h40234-len 2
obj-h40234-reading M_Imported
obj-h40234-unpack s>
M_Energy_W_SF

Code Auswählen Erweitern

obj-h40242-reading M_Energy_W_SF
obj-h40242-unpack s>

im Modul sind auch:

Code Auswählen Erweitern

dev-h-combine  20
dev-h-defPoll  1
definiert.

Alles nach Sunspec (Juni 2025) von SolarEdge (im Anhang).
Anfragen bei SolaEdge blieben bis jetzt ohne Antwort

Der einzige Reading für für Leistung der Panelle (setupInverterDev01 pvIn) wäre demnach status-pv_power (von SolarEdgeAPI).
Hat aber, wie geschrieben, den Nachteil, dass die Reuest begrenzt sind.

Hat jemand einen Rat für die Readings?

Mit besten Grüßen

Martin.

[klaus.schauer]

So recht glauben kann ich nicht, dass die Integration von Hybridwechselrichtern im Forum und Wiki bisher kein Thema war. Gefunden habe ich jedenfalls nichts.

Ich versuche konkret einen
- SMA STP10.0SE (SUNNY TRIPOWER 10.0 SE) mit angeschlossenem Solarspeicher
- SMA STP3.0-3AV-40 (Sunny Tripower 3.0)
in SolarForecast zu konfigurieren. Zusätzlich ist ein SMA Homemanager 2.0 im Einsatz. Der HM 2.0 soll auch als EEBus-Energiemanagementsystem (EMS) nach § 14a EnWG für die Leistungsbegrenzung der Wärmepumpe und der Wallbox genutzt werden, sobald der Netzbetreiber bereit ist. Von SolarForecast erhoffe ich mir eine Lösung für eine zusätzliche prognosebasierte Steuerung der Wärmepumpe in Zeiten mit Niedrig- und Hochlasttarifstufen für das Netzentgelt (§ 14a EnWG Modul 3).

Die Wechselrichter und Batterie habe ich wie folgt definiert:

Code Auswählen Erweitern

setupInverterDev01: wr4136601s strings=south capacity=10000 pvIn=SPOT_PDC_SUM:W pvOut=SPOT_PACTOT:W etotal=SPOT_EPVTOTAL:Wh asynchron=1
setupInverterDev02: wr4136602s strings=east capacity=3000 pvIn=SPOT_PDC_SUM:W pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:Wh asynchron=1
setupBatteryDev01: wr4136601s pin=BAT_P_CHARGE:W pout=BAT_P_DISCHARGE:W pinmax=10000 poutmax:10000 intotal=BAT_LOADTOTAL:Wh outtotal=BAT_UNLOADTOTAL:W cap=19300 charge=ChargeStatus asynchron=1 show=1:bottom
setupMeterDev: wr4136601s gcon=Meter_Power_Grid_Consumation:W contotal=Meter_TOTAL_Grid_Consumation:Wh gfeedin=Meter_Power_Grid_FeedIn:W feedtotal=Meter_TOTAL_Grid_FeedIn:Wh asynchron=1
Die Betriebsdaten werden durch die SMAInverter-Module wr4136601s, wr4136602s bereitgestellt.

Solange es keine Energieflüsse im Solarspreicher setupBatteryDev01 gibt, werden die Energieflüsse im Gesamtsystem richtig berechnet.

Sobald aber der Solarspeicher ge- oder entladen wird, werden die Energieflüsse sowohl beim Hybridwechselrichter als auch beim Solarspeicher doppelt gezählt. Also habe ich versucht, einen Wechselrichter vom Typ "Solar charger" oder "Battery Inverter" zusätzlich zu definieren. Das hilft wohl aber nicht.

Gibt es für diese Konstellation eine Lösung?
- Im Wiki bin ich auf ein Beispiel mit Dummy Wechselrichtern und Batterien gestoßen. M. E. wäre das - wenn das die Lösung sein sollte - aber aufwändig und unübersichtlich.
- Wäre es nicht sinnvoller, für den Wechselrichtertyp "PV-Inverter" zusätzliche Energiepfade für Solarspeicher (batIn, batOut) einzuführen? Hierbei wäre aber zu beachten, dass der Pfad "pvOut" auch negative Werte erlauben müsste. In meiner Konstellation nimmt der Hybridwechselrichter zur Ladung des Solarspeichers - gesteuert durch den HM 2.0 - auch Energie vom zweiten Wechselrichter oder Netz auf.

[Wolle02]

Was ich übrigens noch gerne wüsste ist, ob es eine Möglichkeit gibt, SF so zu konfigurieren, dass Readings (wie Battery_ChargeAbort_XX, Battery_ChargeRecommended_XX und Battery_ChargeRequest_XX) und deren Zeitstempel nicht mit jedem Update der Webseite aktualisiert werden, sodass dann erkennbar ist, wann der Wert eines Readings sich zuletzt geändert hat.

Es gibt in FHEM ganz allgemein für die Entwicklung eine Funktion readingsBulkUpdateIfChanged die genau das bei der Readinggenerierung tut. Unschön (von meinem Standpunkt aus gesehen) ist bei dieser Funktion, dass man eben nicht sieht ob das Reading beim letzten Zyklus gesetzt wurde oder nicht. Weil evetuell ein Fehler vorliegt der das Setzen des Readings verhinderte o.ä.
Aber die Abwägung des Vorteils/Nachteils liegt, wie bei vielen Dingen im Leben, im Auge des Betrachters/Nutzers.

Ich weiß nicht, ob ich euch richtig verstehe, aber vielleicht ist das Attribut timestamp-on-change-reading .* das was ihr sucht?
Bei mir jedenfalls werden die Zeitstempel der Readings nur dann geändert wenn sich auch das Reading geändert hat und nicht bei jedem Zyklus.

[DS_Starter]

@Martin,

Wenn ich Deinem Rat folge:

    Zitat
    Wenn es zu schwierig sein sollte pvOut nur mit dem PV-Anteil zu ermitteln, kannst du auch den Wert für pvIn ebenfalls für pvOut benutzen. Dadurch wird zwar die Inverter Verlustleistung unterschlagen, aber als Notlösung würde es gehen um erstmal weiterzukommen.

heben sich die Werte auf, oder? Wird da noch was berechnet?

pvIn ist (aktuell) nur für die Darstellung im Flußdiagramm relevant, deswegen auch optional. Für die Berechnung wird der Wert aus pvOut herangezogen. Deswegen passt es dann auch sofern man der WR Wandlungsverluste vernachlässigt.


@klaus.schauer,

So recht glauben kann ich nicht, dass die Integration von Hybridwechselrichtern im Forum und Wiki bisher kein Thema war. Gefunden habe ich jedenfalls nichts.

Genau, deswegen will ich es im Wiki hinterlegen. Etliche Nutzer haben seit meiner Anfrage weiter vorn ihre Konfiguration mit Hybridwechselrichtern dankenswerter Weise zur Verfügung gestellt.

Also habe ich versucht, einen Wechselrichter vom Typ "Solar charger" oder "Battery Inverter" zusätzlich zu definieren. Das hilft wohl aber nicht.

Der zusätzliche "Battery Inverter" ist der richtige Weg. Man muß nur genau die Bedeutung der Schlüssel (Readings) beim Typ "PV-Wechselrichter" und Typ "Batterie-Wechselrichter" einhalten.

LG,
Heiko

[Parallix]

So recht glauben kann ich nicht, dass die Integration von Hybridwechselrichtern im Forum und Wiki bisher kein Thema war.
...

Die Breite der Möglichkeiten geht hier schlicht sehr auseinander. Bei meinem System kann ich z.B. die Leistungen zur und von der Batterie zum einen am Wechselrichter abfragen, zum anderen aber auch bei den Speichern. Für beide Varianten gibt es unterschiedliche Zugänge (einmal via ModbusAttr, einmal BYDBox). Insofern ist mein Tipp, in den Threads hier im Forum nachzusehen, mit denen Deine Devices angesprochen werden können.

[Parallix]

Nachdem mir SF gestern trotz schlechtem Wetter und safetyMargin=0:0 eine zeitliche Punktlandung (möglichst spät) auf den Ziel-SOC beschert hat, sieht es heute bei gutem Wetter und nicht veränderter safetyMargin nicht mehr so gut aus, denn ich bin bereits jetzt um 14:45 schon sehr nahe am Ziel-SOC (vgl. Bild).