- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#41
FHEM Code changes / Revision 30933: 76_SolarForeca...
Letzter Beitrag von System - 12 März 2026, 08:51:05Revision 30933: 76_SolarForecast: contrib version 2.3.1
76_SolarForecast: contrib version 2.3.1
Source: Revision 30933: 76_SolarForecast: contrib version 2.3.1
76_SolarForecast: contrib version 2.3.1
Source: Revision 30933: 76_SolarForecast: contrib version 2.3.1
#42
Automatisierung / Aw: notify Status während disa...
Letzter Beitrag von yersinia - 12 März 2026, 08:45:08Zitat von: betateilchen am 11 März 2026, 16:12:32Das notify wird IMMER getriggered und ausgeführt. Es prüft erst bei der Ausführung für sich selbst, ob es aufgrund irgendwelcher Attribute (oder set active/inactive) disabled ist oder nicht.Das hab ich befürchtet; sonst würde man es ja wahrscheinlich heute schon direkt sehen.
Sollte es zu der Erkenntnis kommen, dass es gerade nicht aktiv sein soll, dann bricht es die Verarbeitung einfach ab.
Zitat von: Guybrush am 11 März 2026, 16:21:55Du könntest aber zb im notify ein reading 'temporaryDisabled' (oder anders benannt) im notify_test device auf true oder 1 setzen. Dann noch ein at device mit +30 sek anlegenViel zu Aufwändig für meinen "Bedarf"....
Dann ist gut, danke für die Rückmeldungen.
#43
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 12 März 2026, 08:38:25Heute früh noch einen Vorzeichenfehler in der Bias/Drift-Korrektur korrigiert.
Das Debug mit aiData sieht im Log nun so aus:
2026.03.12 08:27:06.042 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 08:00:00, hod: 09 -> AI=653, legacy=838, final: 711 Wh (alpha=1, BC=58 Wh, bias/drift zone=2/3)
2026.03.12 08:27:06.042 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 09:00:00, hod: 10 -> AI=713, legacy=837, final: 651 Wh (alpha=1, BC=-63 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.043 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 10:00:00, hod: 11 -> AI=705, legacy=710, final: 643 Wh (alpha=1, BC=-62 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.044 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 11:00:00, hod: 12 -> AI=878, legacy=813, final: 800 Wh (alpha=1, BC=-77 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.044 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 12:00:00, hod: 13 -> AI=936, legacy=776, final: 854 Wh (alpha=1, BC=-82 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.045 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 13:00:00, hod: 14 -> AI=872, legacy=706, final: 795 Wh (alpha=1, BC=-77 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.045 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 14:00:00, hod: 15 -> AI=664, legacy=691, final: 721 Wh (alpha=1, BC=58 Wh, bias/drift zone=2/3)
2026.03.12 08:27:06.046 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 15:00:00, hod: 16 -> AI=615, legacy=662, final: 676 Wh (alpha=1, BC=62 Wh, bias/drift zone=2/3)
...
Man sieht eine vorzeichenbehaftete Biaskorrektur (BC), die auch das Verhältnis von AI zu Legacy gut wiederspiegelt (die Werte haben aber keinen Bezug zueinander und dienen nur einem Vergleich im Log). Bei mir ist der Vergleich mit Legacy sehr hilfreich weil mein Haushalt nicht durch WP oder EV "gestört" wird. Lediglich Verbraucher wie Wasch- Spülmaschine etc. (die aber momentan nich an sind) würden den Vergleich stören.
Jetzt lasse ich es laufen und beobachte weiter. Eingebaut werden muß noch eine Driftkorrektur-Pause von X Stunden nachdem ein Training durchgeführt wurde. Sonst werden die "alten" Forecasts mit dem neuen Modell vermischt und führt zu einem negativen Einfluß auf die Driftkorrektur was momentan Einfluß haben dürfte.
Das Debug mit aiData sieht im Log nun so aus:
2026.03.12 08:27:06.042 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 08:00:00, hod: 09 -> AI=653, legacy=838, final: 711 Wh (alpha=1, BC=58 Wh, bias/drift zone=2/3)
2026.03.12 08:27:06.042 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 09:00:00, hod: 10 -> AI=713, legacy=837, final: 651 Wh (alpha=1, BC=-63 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.043 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 10:00:00, hod: 11 -> AI=705, legacy=710, final: 643 Wh (alpha=1, BC=-62 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.044 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 11:00:00, hod: 12 -> AI=878, legacy=813, final: 800 Wh (alpha=1, BC=-77 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.044 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 12:00:00, hod: 13 -> AI=936, legacy=776, final: 854 Wh (alpha=1, BC=-82 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.045 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 13:00:00, hod: 14 -> AI=872, legacy=706, final: 795 Wh (alpha=1, BC=-77 Wh, bias/drift zone=3/3)
2026.03.12 08:27:06.045 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 14:00:00, hod: 15 -> AI=664, legacy=691, final: 721 Wh (alpha=1, BC=58 Wh, bias/drift zone=2/3)
2026.03.12 08:27:06.046 1: SolCast DEBUG> AI FANN con fc - Time: 2026-03-12 15:00:00, hod: 16 -> AI=615, legacy=662, final: 676 Wh (alpha=1, BC=62 Wh, bias/drift zone=2/3)
...
Man sieht eine vorzeichenbehaftete Biaskorrektur (BC), die auch das Verhältnis von AI zu Legacy gut wiederspiegelt (die Werte haben aber keinen Bezug zueinander und dienen nur einem Vergleich im Log). Bei mir ist der Vergleich mit Legacy sehr hilfreich weil mein Haushalt nicht durch WP oder EV "gestört" wird. Lediglich Verbraucher wie Wasch- Spülmaschine etc. (die aber momentan nich an sind) würden den Vergleich stören.
Jetzt lasse ich es laufen und beobachte weiter. Eingebaut werden muß noch eine Driftkorrektur-Pause von X Stunden nachdem ein Training durchgeführt wurde. Sonst werden die "alten" Forecasts mit dem neuen Modell vermischt und führt zu einem negativen Einfluß auf die Driftkorrektur was momentan Einfluß haben dürfte.
#44
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von peterboeckmann - 12 März 2026, 07:53:20Moin Heiko,
das war nicht mal nötig. Heute Nacht hat er die Stunde wieder sauber vorhergesagt, wie gesagt, ohne das NN.
Viele Grüße,
Peter
Zitat von: DS_Starter am 11 März 2026, 23:33:52Eventuell kann/muß man mit
plantControl->consForecastLastDays temporär eingreifen.
das war nicht mal nötig. Heute Nacht hat er die Stunde wieder sauber vorhergesagt, wie gesagt, ohne das NN.
Viele Grüße,
Peter
#45
FHEM Code changes / Revision 30932: controls_fhem....
Letzter Beitrag von System - 12 März 2026, 07:50:20Revision 30932: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 30932: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 30932: controls_fhem.txt: fhemupdate checkin
#46
Codeschnipsel / Aw: Wallbox Zappi von Myenergi
Letzter Beitrag von Prof. Dr. Peter Henning - 12 März 2026, 04:29:301. Bitte den Beitrag NICHT unter "Codeschnipsel" posten. Entweder unter Anfängerfragen, oder unter "Wallboxen und E-Fahrzeuge".
2. Bitte zuerst die Forumssuche benutzen, und nicht einfach "hat jemand schon..." fragen.
LG
pah
2. Bitte zuerst die Forumssuche benutzen, und nicht einfach "hat jemand schon..." fragen.
LG
pah
#47
Wallboxen und E-Fahrzeuge / Aw: go-e Charger WallBox über...
Letzter Beitrag von fred_feuerstein - 12 März 2026, 00:03:58Blöde Fragen gibt's eigentlich nicht. Aber wieso Selbstbetrug?
Es ist doch legitim wissen zu wollen, wieviel Strom fürs Fahren selbst zuhause erzeugt wurde und wieviel aus dem Netz gezogen wurde.
Fürs tägliche Leben oder in der Praxis nutzen Dir viele Informationen und gar auch statistische Werte nicht viel. In diesem Zusammenhang kannst Du aber viele Dinge, die Du mit dem Smarthome etc. machst hinterfragen.
Fürs tägliche Leben "braucht" man das alles nicht.
Das meiste ist da wenn überhaupt nur "nice to have"...
Es geht hier aber generell um das Thema Go-e charger und dabei auch zu einen grossen Teil um das solare Überschussladen.
Warum also nicht den statistischen Wert ermitteln? Dabei nicht schön gerechnet, sondern möglichst real.
Es kommt bei dem ganzen Thema ja auf das Nutzungsprofil vom Auto an.
Wenn man das Auto täglich braucht und von morgens bis abends nicht zu Hause ist und man somit immer nur abends/nachts laden kann, dann ist das mit pv Überschussladung usw. alles unwichtig.
Wenn man wie ich das Auto aber nicht täglich braucht kann man den Zeitpunkt der Ladung sehr oft planen und eben tagsüber bei Sonne laden.
Es ist doch legitim wissen zu wollen, wieviel Strom fürs Fahren selbst zuhause erzeugt wurde und wieviel aus dem Netz gezogen wurde.
Fürs tägliche Leben oder in der Praxis nutzen Dir viele Informationen und gar auch statistische Werte nicht viel. In diesem Zusammenhang kannst Du aber viele Dinge, die Du mit dem Smarthome etc. machst hinterfragen.
Fürs tägliche Leben "braucht" man das alles nicht.
Das meiste ist da wenn überhaupt nur "nice to have"...
Es geht hier aber generell um das Thema Go-e charger und dabei auch zu einen grossen Teil um das solare Überschussladen.
Warum also nicht den statistischen Wert ermitteln? Dabei nicht schön gerechnet, sondern möglichst real.
Es kommt bei dem ganzen Thema ja auf das Nutzungsprofil vom Auto an.
Wenn man das Auto täglich braucht und von morgens bis abends nicht zu Hause ist und man somit immer nur abends/nachts laden kann, dann ist das mit pv Überschussladung usw. alles unwichtig.
Wenn man wie ich das Auto aber nicht täglich braucht kann man den Zeitpunkt der Ladung sehr oft planen und eben tagsüber bei Sonne laden.
#48
FHEM Code changes / Revision 30931: 76_SolarForeca...
Letzter Beitrag von System - 12 März 2026, 00:01:11Revision 30931: 76_SolarForecast: contrib Version 2.3.1
76_SolarForecast: contrib Version 2.3.1
Source: Revision 30931: 76_SolarForecast: contrib Version 2.3.1
76_SolarForecast: contrib Version 2.3.1
Source: Revision 30931: 76_SolarForecast: contrib Version 2.3.1
#49
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 11 März 2026, 23:59:17ZitatMöglicherweise ein Missverständnis: Wenn ich consForecastLastDays != 0 setze, dann wird das gesamte Verbrauchsprofil des Vortags auf den Folgetag abgebildet, was in meinen Fall nicht gewünscht ist, da ich einige Überschussverbraucher nicht als solche ausweisen kann. Erzeuge ich einen Dummy-Consumer zur Abbildung (m)eines Grundverbrauchsprofils, dann kann ich diesen Dummy-Consumer in der aktuellen Version von SF nur dann korrekt (mit consForecastLastDays == 0) bei der Verbrauchsprognose berücksichtigen lassen, wenn seine Leistung über den Tag konstant ist.Ich glaube da hast du recht. (Allerdings ist es heute schon spät.
Was ich brauche ist aber ein Consumer, der mit einem wohldefinierten 24h-Lastprofil berücksichtigt wird ohne dass ich consForecastLastDays > 0 setzen muss. Das geht doch aktuell nicht, oder?
) #50
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 11 März 2026, 23:55:30Das Modul im contrib ist upgedated.
Ich habe nach langem Suchen einen sich selbst verstärkenden Fehler in der Drift-Korrektur gefunden. Außerdem ist eine automatische Drift Rekalibrierung eingebaut die den Bias des Trainings mit dem Bias der Livedaten der letzten 96h vergleicht und bei Bedarf rekalibriert.
Ich habe noch eine weitere wichtige Maßnahme bzgl. Drift im Hinterkopf die ich aber noch nicht umsetzen konnte.
Die KI Einschätzung zum aktuellen Entwicklungsstand:
SolarForecast hat jetzt eine Drift‑Pipeline, die:
* peak‑aware
* semantik‑adaptiv
* modellskaliert
* ausreißersicher
* PV‑nacht‑sicher
* API‑fehler‑sicher
* rekalibrierungssicher
* selbststabilisierend
Das ist auf dem Niveau professioneller Forecasting‑Systeme.
Na mal sehen. Morgen wird sich zeigen ob das System die Korrektur und Rekalibrierung wie gewünscht ausführen kann.
LG,
Heiko
Ich habe nach langem Suchen einen sich selbst verstärkenden Fehler in der Drift-Korrektur gefunden. Außerdem ist eine automatische Drift Rekalibrierung eingebaut die den Bias des Trainings mit dem Bias der Livedaten der letzten 96h vergleicht und bei Bedarf rekalibriert.
Ich habe noch eine weitere wichtige Maßnahme bzgl. Drift im Hinterkopf die ich aber noch nicht umsetzen konnte.
Die KI Einschätzung zum aktuellen Entwicklungsstand:
SolarForecast hat jetzt eine Drift‑Pipeline, die:
* peak‑aware
* semantik‑adaptiv
* modellskaliert
* ausreißersicher
* PV‑nacht‑sicher
* API‑fehler‑sicher
* rekalibrierungssicher
* selbststabilisierend
Das ist auf dem Niveau professioneller Forecasting‑Systeme.
Na mal sehen. Morgen wird sich zeigen ob das System die Korrektur und Rekalibrierung wie gewünscht ausführen kann.
LG,
Heiko