76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

Persuasiv

Zitat von: stefanru am 06 Juni 2025, 18:27:49Hi Heiko,

ich habe ein Anzeige Problem seit dem letzten Update.
Für mein Tablet UI scheint der Header etwas breit geworden zu sein.


Wie kann man den Akkufüllstand dort einblenden? Besten Dank!

grappa24

Zitat von: Persuasiv am 06 Juni 2025, 21:20:04Wie kann man den Akkufüllstand dort einblenden? Besten Dank!
Das kannst du beim setupBatteryDevXX mit show festlegen
show    Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
    0 - keine Anzeige des Gerätes (default)
    1..3[:top|bottom] - Anzeige des Gerätes in der Ebene 1,2 oder 3 (über|unter) den Balken
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Bozan

Zitat von: grappa24 am 24 Mai 2025, 17:48:23Hab jetzt endlich eine Möglichkeit gefunden, pvIn/pvOut beim Fronius SymoGEN24 korrekt abzugreifen und komme auf Wandlungsverluste von 2-5 %

Hallo Grappa,

welche Werte vom SymoGen24 nimmst Du hier nun für pvIn/pvOut?
Danke für Deine Hilfe,

Bozan

grappa24

Zitat von: Bozan am 07 Juni 2025, 20:31:16welche Werte vom SymoGen24 nimmst Du hier nun für pvIn/pvOut?
pvOut=Inverter_Common_PAC_Value - PowerFlow_Site_P_Akku
pvIn=Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC_2_Value * Inverter_Common_UDC_2_Value
Ausgangsleistung als Summe aus der Wechselstromleistung PAC des Inverters plus das was aus der Batterie kommt (ist negativ, deshalb minus)
Eingangsleistung als I*U meiner beiden Strings

100% sicher bin ich mir zwar nicht, liefert aber sehr plausible Werte und flow-Grafik; konnte es noch nicht für alle Situationen testen.
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Parallix

#3124
Die letzten Tage habe ich mich mit Strategien zur optimalen Batteriebeladung beschäftigt und mir dabei u.a. auch das Beispiel ,,Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie" angesehen. Hierbei ist mir aufgefallen, dass diese und meine (sehr ähnliche) Lösung nicht optimal ist,  da ein fixer ,,Verkürzungsfaktor Zeit bis Vollladung vor Sunset" verwendet wird.

Was man bräuchte wäre einige wenige gemäß Forecast berechnete Readings:

Eins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.

Zusätzlich bräuchte man noch ein Reading mit der Anzahl der verbleibenden Stunden ohne Ladeempfehlung (Battery_RemainingHoursWithoutChargeRecommendation_XX).

Insofern möchte ich vorschlagen, die o.g. (special)Readings noch in SF aufzunehmen.

Nachtrag 1: Aufgefallen ist mir auch, dass die bisherige SoC-Prognose in SF von einer Ladung mit maximal zur Verfügung stehenden Überschussleistung ausgeht. Im dem in Wiki beschriebenen Beispiel (,,Dynamische Ladestromsteuerung eines Victron ...") ist dies aber nicht der Fall. Abhilfe könnte eine vom User anpassbare Methode schaffen, die maximalen Ladeleistungen für die restlichen Stunden des Tages liefert.

Nachtrag 2: Dass upSoC und lowSoC Attribute sind, halte ich persönlich für ungünstig. Grund: upSoC ist - nach meinem Verständnis - optimal gesetzt, wenn die BAT nach einen (abendlichen) Dunkelzyklus mindestens noch lowSoc erreicht. Beide Werte  müssten hierzu im Jahresverlauf programmgesteuert angepasst werden können, was vorliegend aber nicht geht. Daher schlage ich vor, beide in ein Reading zu überführen.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

Bison

Hallo DS_Starter,

ich habe wohl aus versehen was an meinem Forecast Modul verstellt. Leider weiß ich nicht wo ich den Fehler suchen soll. Kannst du mir helfen wo ich in den Einstellungen nachschauen muß?

Mein Forecast sieht wie folgt aus:
Raspberry, Homematic, CUL, 50 Device, 260 Entities

DS_Starter

Moin,

Ich bin zur Zeit unterwegs und kann erst kommende Woche wieder aktiv sein. Vllt. Kann die Community helfen. Das Bild alleine hilft nicht viel. Da sind mehr Infos nötig wie das verwendete Model, die verwendete Autokorrektur etc. Ich tippe ins Blaue, du hast KI eingeschaltet, aber evtl. Ungenügende Trainingsdaten. Aber kann auch etwas anderes sein. Zumindest vermute ich, du meinst mit der Frage die starken Sprünge in den Stundenvorhersagen.

Lg,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Prof. Dr. Peter Henning

Zitat von: Bison am 08 Juni 2025, 22:15:38ich habe wohl aus versehen was an meinem Forecast Modul verstellt. Leider weiß ich nicht wo ich den Fehler suchen soll. Kannst du mir helfen wo ich in den Einstellungen nachschauen muß?

Vlt. einfach auf die configdb umstellen, dann kann man problemlos ältere Versionen - sofern diese auch wirklich liefen - eines Devices wiederherstellen.

LG

pah

Bison

Hallo DS_Starter,

ja das mit der KI könnte sein. Ich habe glaube in den Reiter Autokorrektur auf on_complex_ai gesetzt. Heute sind die Lücken kleiner geworden. Also ich beobachte es jetzt mal.

Wücnche dir noch einen schönen #urlaub und danke für das tolle Tool.

Gruß Bison
Raspberry, Homematic, CUL, 50 Device, 260 Entities