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