76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Mikel2906]

Hallo Heiko,

ich verwende den Wemos D1 Mini. Ich habe im Internet nach Lösungen gesucht, aber nichts passendes gefunden, das mir weitergeholfen hat. Daher werde ich eine andere Hardware verwenden. Ich habe noch einen Raspberry Pi – vielleicht funktioniert das. Ich werde berichten.

Vielen Dank für die Hilfe und für das super Projekt – das ist wirklich toll.


Michael

[Wolle02]

Ich verwende auch jeweils einen Lesekopf an zwei Stromzählern; diese sind per USB an einen RaspPi angeschlossen auf dem Fhem läuft. Die Daten lese ich mit dem OBIS Modul aus. Das Ganze funktioniert seit Jahren sehr zuverlässig und stabil.

[Mikel2906]

Danke Wolle02 für das Feedback

[300P]

Ich lese die Werte von meinem Stromzähler mit Tasmota und einem Schreib-Lesekopf ab. Das Komische an der ganzen Sache ist, dass das nur nachts passiert.
Ich habe auch die Zeitabstände für die Leseintervalle erhöht, um Lesefehler zu vermeiden. Hast du eine Idee, was ich ändern kann?

2026.05.12 02:31:51 1: PV_Prognose DEBUG> collect Energy Meter data - device: Smartmeter =>
2026.05.12 02:31:51 1: PV_Prognose DEBUG> gcon: 0 W, gfeedin: 8 W, contotal: 0 Wh, feedtotal: 11353700 Wh


2026.05.12 02:33:00 1: PV_Prognose DEBUG> collect Energy Meter data - device: Smartmeter =>
2026.05.12 02:33:00 1: PV_Prognose DEBUG> gcon: 0 W, gfeedin: 3 W, contotal: 17516900 Wh, feedtotal: 11353700 Wh
2026.05.12 02:33:00 1: PV_Prognose DEBUG> write to pvHistory - day: 12, hod: 3, GridConsumption (gcons): 17516900 Wh

a:
Könnte evtl. die Fritzbox sein
- wenn sie die Leitung nachts automatisch trennt, neu verbindet und sich neue IP holt.....
 

b:
Wenn es immer in den gleichen Zeiträumen 02:00 bis 03:00 Uhr auftritt (Trick17)
- nutze so etwas wie attr DEVICE disabledForIntervals HH:MM-HH:MM HH:MM-HH:MM ...
(kommt auf das FHEM-Modul an mit dem du arbeitest - in MQTT2 ginge bei mir - brauch ich aber bei meinem TASMOTA nicht 

[Mikel2906]

Danke 300P,
die Idee ist gut.

attr DEVICE disabledForIntervals HH:MM-HH:MM HH:MM-HH:MM ist gesetzt.

Mal sehen was morgen mein LOG anzeigt.

VG
Michael

[300P]

Danke 300P,
die Idee ist gut.

attr DEVICE disabledForIntervals HH:MM-HH:MM HH:MM-HH:MM ist gesetzt.

Mal sehen was morgen mein LOG anzeigt.

VG
Michael

Wenn es nicht klappt:
Diverse Usereading (je Problemfall anders) welche Werte >= max Wert XYXYXxxxx Wh überschreiten dann "nicht übernimmt".....
Diese "neuen" Userreading dann entsprechend in SF nutzen.



EDIT /NACHSATZ:
Was mir im Nachgang eingefallen ist:

Auf was steht denn die Tasmota Telemetrieperiode ?
Bitte diesen Wert max auf den  "Minimalwert"   von 10 - 15 Sekunden stellen (30 Sekunden ist besser  geeignet).
(Damit regelst du wie oft die Daten z.B. via MQTT übertragen werden)
SF sollte ja auch eigentlich bei dir (minimal) in diesen Zeitrahmen "seine Runde drehen" 

[300P]

Victron hat was neues für den Markt einen Solarsensor ->>>  SolarSense 750 ->> Standalone PV-installation monitor

Hier das Datasheet für Interessierte    (->Heiko)

[lorisurfen]

Mit der V 2.6.6 bis 2.6.7 kommen folgende Fixes und Änderungen ins System.

Consumersteuerung:

- pro SF-Zyklus wird ein PV-Überschußbudget geführt, aus welchem sich die Verbraucher beim Einschaltvorgang bedienen.
  Ist er aufgebraucht, wird kein Verbraucher im laufenden Zyklus mehr eingeschaltet und wird erst im nächsten wieder geprüft.
  Das Verfahren verhindert "Toggling" von Verbrauchern weil im nächsten Zyklus PV-Überschuß überzogen wurde und Verbraucher
  deshalb wieder abgeschaltet werden
 
- neuer Schlüssel swprio zur Prioritätssteuerung von Consumern

LG,
Heiko

Hallo Heiko,
zum Thema Consumersteuerung mein Anwendungsfall vereinfacht:
consumer01 Heizstab 3kW (swprio=100).
consumer02-05 heater je 1000W (swprio=50).
Im Winter wenn morgens die Sonne aufgeht erwartetes Verhalten:
surplus 1000W -> consumer02 schaltet ein.
Anschließend zusätzlich surplus 1000W -> consumer 03 schaltet ein (Gesamtüberschuss (surplus + eingeschaltetete consumer) 2000W).
Weitere 1000W surplus-> consumer 04 schaltet ein (Gesamtüberschuss 3000W). usw.
Dann würde den ganzen Tag consumer02-05 mit niedriger prio an sein, und consumer01 mit höchster prio gar nicht zum Zug kommen ?
Erwartung wäre dass bei einem Gesamtüberschuss von 3000W, dann auf consumer01 mit höchster Prio umgeschaltet wird und die consumer mit niedriger prio dafür ausgeschaltet werden.
Also z.B. Prüfung für consumer mit höchster Prio ob aktueller surplus zusammen mit eingeschalteten consumer mit niedrieger Prio  (consumer0x_currentPower) in Summe den Bedarf für diesen consumer mit höchster prio erbringen können.
Ist das bereits möglich bzw. angedacht?

Danke und Grüße
Markus

[300P]

Läuft das ganze in einer Consumer-,,exclgroup" oder einfach nur als einzelne ConsumerXX ?

[lorisurfen]

Läuft das ganze in einer Consumer-,,exclgroup" oder einfach nur als einzelne ConsumerXX ?

Einfach nur einzelne consumerXX, hat nichts mit "exclgroup" zu tun.
In dem Bsp. sollen bei 7kw Gesamtüberschuss alle consumer ein sein.

[Gisbert]

Hallo Heiko,

bei Sonne/Wolken-Wechsel und den damit sich stark ändernden Einspeisungen kommt es immer zu scheinbar hohen Haus-Verbäuchen im Flussdiagramm, die aber i.d.R. nur einige 100 W betragen.
Was kann man dagegen tun? Vom meinem Deye-Wechselrichter bekomme ich sowohl den Gesamt- als auch den Tagesverbrauch sowie die Leistung zur Verfügung gestellt. Gibt es dafür Eingabemöglichkeiten bei deinem Modul?

Viele Grüße Gisbert

[300P]

In dem Bsp. sollen bei 7kw Gesamtüberschuss alle consumer ein sein.

Meine Auslegung der bestehenden Regelung bei Nutzung Prioritätszahlen:

Bei mehr als 7 kW Gesamtüberschuß (+ alle anderen Rahmenbedingungen die dabei gelten) wird sich auch der große (3.000 W Leistung) am Ende einschalten "müssen".



Aber die Logik mit den Prioritäten sieht halt zuerst mehr als 1.000 W PV-Überschuss
Ab jetzt würde Consumer02 mit Prio 50 und seinen 1.000 W eingeschaltet am frühen Morgen

Etwas später sind wieder mehr als 1.000 W PV-Überschuß "frei" (insgesamt jetzt mehr als 2.000 W)
Ab jetzt würde Consumer03 mit Prio 50 und seinen 1.000 W eingeschaltet (Consumer02 bleibt ja an)

Wieder etwas später sind wieder mehr als 1.000 W PV-Überschuß "frei" (insgesamt mehr als 3.000 W)
Nun würde Consumer04 mit Prio 50 und seinen 1.000 W eingeschaltet (Consumer02 und Consumer03 bleiben weiter an)

Zu guter letzt - wieder etwas später - sind wieder mehr als 1.000 W PV-Überschuß "frei" (insgesamt mehr als 4.000 W)
Nun würde Consumer05 mit Prio 50 und seinen 1.000 W eingeschaltet (Consumer02,Consumer03 und Consumer04 bleiben auch weiter an)


Jetzt muss Consumer01 (trotz Prio 100) leider weiterhin weiter warten bis das wieder mehr als weitere 3.000 W an PV-Überschuss anfallen, denn vorher kommt er nicht infrage auf ON geschaltet zu werden.

Grund:
Es gibt keinen Parameter der die anderen 4 ConsumerXX ausschalten würde, damit der eine andere Consumer01 angeht !!
Wenn überhaupt, dann müsste das evtl. durch ein geschickte Logik per Code in "ctrlUserExitFn {<Code>}" deinerseits geregelt werden.
Ansonsten sehe ich m.W.n. im Augenblick keine Standartlösung dafür in SF.

[DS_Starter]

Victron hat was neues für den Markt einen Solarsensor ->>>  SolarSense 750 ->> Standalone PV-installation monitor

Na das schaue ich mir an, danke für den Hinweis 300P.

[DS_Starter]

@Gisbert,

bei Sonne/Wolken-Wechsel und den damit sich stark ändernden Einspeisungen kommt es immer zu scheinbar hohen Haus-Verbäuchen im Flussdiagramm, die aber i.d.R. nur einige 100 W betragen.
Was kann man dagegen tun? Vom meinem Deye-Wechselrichter bekomme ich sowohl den Gesamt- als auch den Tagesverbrauch sowie die Leistung zur Verfügung gestellt. Gibt es dafür Eingabemöglichkeiten bei deinem Modul?

Das ist ein typisches Race-Condition Problem. Es wird bei fast allen mehr oder weniger auftreten.
HIer geht es um die Intime-Messungen, d.h. was gerade _jetzt_ erzeugt/verbraucht/gespeichert/eingespeist/bezogen/usw. wird.
Diese Werte werden durch unterschiedlichste Geräte in FHEM geliefertund durch SF ausgelesen.
Das Problem - diese Geräte sind nicht synchronisiert, sie liefern nicht zur gleichen Zeit die gerade aktuellen Daten. SF liest also von allen Geräte Daten deren Erfassungszeit u.U. z.B. 15 Minuten auseinanderliegen, je nachdem wie oft die beteiligten Geräte Daten aktualisieren.
Die Lösung wäre, dass man versucht die Geräte z.B. über ein zentrales notify/at zu synchronisieren falls das überhaupt im jeweiligen Gerätemodul möglich ist und unterstützt wird.
Andere Möglichkeit wäre SF würde alle Geräte nativ abfragen. Das ist schlicht nicht möglich, dann müßte ich ja alle möglichen FHEM Module in SF nachbauen. 

LG,
Heiko 

[DS_Starter]

@Markus, @300P,

consumer01 Heizstab 3kW (swprio=100).
consumer02-05 heater je 1000W (swprio=50).
Im Winter wenn morgens die Sonne aufgeht erwartetes Verhalten:
surplus 1000W -> consumer02 schaltet ein.
Anschließend zusätzlich surplus 1000W -> consumer 03 schaltet ein (Gesamtüberschuss (surplus + eingeschaltetete consumer) 2000W).
Weitere 1000W surplus-> consumer 04 schaltet ein (Gesamtüberschuss 3000W). usw.
Dann würde den ganzen Tag consumer02-05 mit niedriger prio an sein, und consumer01 mit höchster prio gar nicht zum Zug kommen ?
Erwartung wäre dass bei einem Gesamtüberschuss von 3000W, dann auf consumer01 mit höchster Prio umgeschaltet wird und die consumer mit niedriger prio dafür ausgeschaltet werden.

Wie 300P schon gefolgert hat, müßte man diese Logik über ctrlUserExitFn unterstützen. Für eine Logik wäre das Setup etwa so.

Definiert sind die Consumer ohne exclgroup, aber mit swprio (02-05 könnte gleich sein, aber ich würde die Reihenfolge mal vorsehen):

consumer01 Heizstab 3000W -> swprio=100, locktime=300
consumer02 heater 1000W -> swprio=50, locktime=300
consumer03 heater 1000W -> swprio=40, locktime=300
consumer04 heater 1000W -> swprio=30, locktime=300
consumer05 heater 1000W -> swprio=20, locktime=300

Wenn zum Start des Tages der Überschuß ansteigt, schalten die consumer 02 bis 05 nacheinander an, da der Überschuß langsam steigt. Sollte er schnell auf über 3000W steigen und noch nicht alle 02-05 an sein, schaltet consumer01 an wegen der höheren prio! Muß man sehen ob das realistisch ist.

Wenn also insgesamt 4000W Überschuß vorhanden ist, sind die consumer 02-05 on und verbrauchen den Überschuß obwohl der Überschuß jetzt reichen würde um consumer01 und ggf. noch einen anderen consumer zu betreiben.

Eine Lösung wäre in ctrlUserExitFn eine kleine Logik zu bauen:

1. prüfe ob alle consumer 02-05 (evtl. 02-04) "on" sind
2. wenn ja, ist eigentlich genügend Überschuß vorhanden um consumer01 zu bereiben -> dann
3. schalte über die entsprechenden Befehle die consumer 02-05 (02-04) aus!

Dh. in diesem Fall werden durch die Logik ctrlUserExitFn alle consumer 02-05 (02-04) am Ende des SF-Zyklus ausgeschaltet sein, der PV-Überschuß wird frei.
Im nächsten Zyklus wird consumer01 aktiviert da genügend PV Überschuß vorhanden ist und er die höchste Prio hat. Damit nicht gleicht einer der consumer 02-05 dazu kommt, haben alle locktime von 5 Minuten nach dem Ausschalten gesetzt.

Sollte die PV nach unten gehen, wird consumer01 unterbrochen und die anderen 02-05 werden beim Hochlauf der PV wieder aktiviert bis die Logik in ctrlUserExitFn wieder greift, die C 02-05 abschaltet und dann consumer01 wieder fortsetzt da ja genug PV vorhanden.

Wenn das Verfahren gefällt, muß man es nur noch in Perl kodieren und testen.

LG,
Heiko