- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Mikel2906 - 10 Mai 2026, 12:21:09Hallo Heiko,
danke für deine Hilfe und das super Projekt. Ich benutze die aktuelle Version 2.6.5.
Zur meiner Person: Ich benutze FHEM schon seit mehreren Jahren, programmieren kann ich ein wenig und komme klar
Die Ausreißer der Variablen treten immer von 1 Uhr nachts und 4 Uhr morgens auf. Das sind die Werte die am Stromzähler angezeigt werden.
Beispiele:
Today_Hour02_GridConsumption: 17516200 Wh
Today_Hour04_GridFeedIn: 11315700 Wh
Das Skript für die Ladesteuerung funktioniert nur, wie bereits beschrieben, bleibt der Wert bei 3000 stehen.
Das Skript für die Ladesteuerung ist im Anhang.
Viele Grüße
Michael
danke für deine Hilfe und das super Projekt. Ich benutze die aktuelle Version 2.6.5.
Zur meiner Person: Ich benutze FHEM schon seit mehreren Jahren, programmieren kann ich ein wenig und komme klar
Die Ausreißer der Variablen treten immer von 1 Uhr nachts und 4 Uhr morgens auf. Das sind die Werte die am Stromzähler angezeigt werden.
Beispiele:
Today_Hour02_GridConsumption: 17516200 Wh
Today_Hour04_GridFeedIn: 11315700 Wh
Das Skript für die Ladesteuerung funktioniert nur, wie bereits beschrieben, bleibt der Wert bei 3000 stehen.
Das Skript für die Ladesteuerung ist im Anhang.
Viele Grüße
Michael
#2
Solaranlagen / Aw: Einbindung eines Sungrow S...
Letzter Beitrag von toron_go - 10 Mai 2026, 12:18:26Leider hier keine Reaktionen mehr
Wird wohl doch Zeit das System zu wechseln.
VG Toron
Wird wohl doch Zeit das System zu wechseln.
VG Toron
#3
FHEM Code changes / Revision 31201: 76_SolarForeca...
Letzter Beitrag von System - 10 Mai 2026, 12:11:16Revision 31201: 76_SolarForecast: contrib Version 2.6.8
76_SolarForecast: contrib Version 2.6.8
Source: Revision 31201: 76_SolarForecast: contrib Version 2.6.8
76_SolarForecast: contrib Version 2.6.8
Source: Revision 31201: 76_SolarForecast: contrib Version 2.6.8
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:58:06@all,
nach den vielen Diskussionen um die letzten Systemanpassungen verliert man leicht den Überblick.
Hier nun eine kurze Zusammenfassung was alles seit dem letzten Check-In der V 2.6.5 passiert ist.
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
Flußgrafik:
- Bugfix der Entladeflüsse bei mehreren vorhandenen Batterien und unterschiedlicher WR-Architektur (Forum: https://forum.fhem.de/index.php?msg=1363211)
Der Einsatz der Consumer-Priorität kann nun dazu führen, dass can-Consumer im ungünstigsten Fall den ganzen Tag nicht
gestartet werden können wenn höher priorisierte Consumer das Budget aufbrauchen.
NEU: Mit der V 2.6.8 kommt nun eine erweiterte Form des Planungsprozesses von "can"-Consumern zum Einsatz.
- Vorprozess summiert für jede Stunde (hod) die bereits verplante pvpow aller anderen Consumer anhand ihrer ehodpieces.
Consumer ohne ehodpieces oder ohne pvpow werden übersprungen.
- die Auswahl des Planungsfensters prüft jetzt das Ergebnis des Vorprozesses statt direkt.
Ein Fenster das durch andere Consumer bereits ausgelastet ist wird übersprungen, und der Consumer wandert automatisch in
das nächste freie Fenster.
- swprio-Sortierung in greift weiterhin – höher priorisierte Consumer werden zuerst geplant und belegen die besten Fenster.
Niedriger priorisierte Consumer weichen automatisch aus.
- must-Consumer bleiben unberührt – sie ignorieren die Belegung und planen um den Peak.
Die V 2.6.8 habe ich ins contrib geladen.
LG,
Heiko
nach den vielen Diskussionen um die letzten Systemanpassungen verliert man leicht den Überblick.
Hier nun eine kurze Zusammenfassung was alles seit dem letzten Check-In der V 2.6.5 passiert ist.
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
Flußgrafik:
- Bugfix der Entladeflüsse bei mehreren vorhandenen Batterien und unterschiedlicher WR-Architektur (Forum: https://forum.fhem.de/index.php?msg=1363211)
Der Einsatz der Consumer-Priorität kann nun dazu führen, dass can-Consumer im ungünstigsten Fall den ganzen Tag nicht
gestartet werden können wenn höher priorisierte Consumer das Budget aufbrauchen.
NEU: Mit der V 2.6.8 kommt nun eine erweiterte Form des Planungsprozesses von "can"-Consumern zum Einsatz.
- Vorprozess summiert für jede Stunde (hod) die bereits verplante pvpow aller anderen Consumer anhand ihrer ehodpieces.
Consumer ohne ehodpieces oder ohne pvpow werden übersprungen.
- die Auswahl des Planungsfensters prüft jetzt das Ergebnis des Vorprozesses statt direkt.
Ein Fenster das durch andere Consumer bereits ausgelastet ist wird übersprungen, und der Consumer wandert automatisch in
das nächste freie Fenster.
- swprio-Sortierung in greift weiterhin – höher priorisierte Consumer werden zuerst geplant und belegen die besten Fenster.
Niedriger priorisierte Consumer weichen automatisch aus.
- must-Consumer bleiben unberührt – sie ignorieren die Belegung und planen um den Peak.
Die V 2.6.8 habe ich ins contrib geladen.
LG,
Heiko
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:52:39Hallo Mikel2906,
willkommen bei SolarForecast. Ich habe gesehen dass du dich heute erst registriert hast.
Nun weiß ich nicht wieviel Vorkenntnisse bzgl. FHEM vorhanden sind weil nun einige Dinge besprochen werden müssen.
Zunächst sind die von dir beschriebenen Sachverhalte:
a) GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer
b) Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht
zwei völlig getrennte Dinge. Die Ladesteuerung ist komplexer, da du (der User) hier eigenen Code verwenden muß um die vorgeschlagene Ladeleistung im Reading! Battery_ChargeOptTargetPower_01 (nicht Variable) in seinem spezifischen Batteriesystem umzusetzen.
Deswegen schlage ich vor zunächst Punkt a) zu betrachten. Nun sind die Fragen
- welche SF-Version setzt du ein? (steht in der GUI oben im Kopf)
- was heißt "GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer" konkret?
- meinst du die Readings Current_GridConsumption bzw. Current_GridFeedIn?
- meinst du die Readings Today_HourXX_GridConsumption bzw. Today_HourXX_GridFeedIn?
Bitte beschreibe genauer was wir uns unter den Ausreißern vorstellen dürfen.
LG,
Heiko
willkommen bei SolarForecast. Ich habe gesehen dass du dich heute erst registriert hast.
Nun weiß ich nicht wieviel Vorkenntnisse bzgl. FHEM vorhanden sind weil nun einige Dinge besprochen werden müssen.
Zunächst sind die von dir beschriebenen Sachverhalte:
a) GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer
b) Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht
zwei völlig getrennte Dinge. Die Ladesteuerung ist komplexer, da du (der User) hier eigenen Code verwenden muß um die vorgeschlagene Ladeleistung im Reading! Battery_ChargeOptTargetPower_01 (nicht Variable) in seinem spezifischen Batteriesystem umzusetzen.
Deswegen schlage ich vor zunächst Punkt a) zu betrachten. Nun sind die Fragen
- welche SF-Version setzt du ein? (steht in der GUI oben im Kopf)
- was heißt "GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer" konkret?
- meinst du die Readings Current_GridConsumption bzw. Current_GridFeedIn?
- meinst du die Readings Today_HourXX_GridConsumption bzw. Today_HourXX_GridFeedIn?
Bitte beschreibe genauer was wir uns unter den Ausreißern vorstellen dürfen.
LG,
Heiko
#6
Bastelecke / Aw: unbekanntes Funkprotokoll ...
Letzter Beitrag von Ralf9 - 10 Mai 2026, 11:32:19Zitat von: DerD am 09 Mai 2026, 10:22:400x1D AGCCTRL0 - 0x90 ist erklärbar, hatte ich manuell auf 4db gesetzt um es empfindlich zu machen. Jetzt steht es wieder auf 8dB mit dem Ergebnis 0x1D AGCCTRL0 - 0x91 (90). Hat aber keinen offensichtlichen Einfluß auf die Erkennung bei mir, auch nicht bei Maximalwert 16db.0x1D AGCCTRL0 hat bei FSK eine andere Bedeutung als bei ASK/OOK
Zitat von: DerD am 09 Mai 2026, 10:22:40Das bei 0x1B AGCCTRL2 - 0x07 kann ich nicht erklären. cc1101_rAmpl steht auf 42dB (gewollt) und damit 0x07, das entspräche laut Datenblatt ja der Grundeinstellung (00000011) plus eben 42dB also 00000111 (0x07)Hast Du auch mal die 0x43 getestet ob es beim Empfang einen Unterschied macht?
0x43 stände für "The highest gain setting can not be used" und 33db. Das kann ich manuell über die settings so gar nicht vergeben, nur per raw definition vermutlich.
Zitat von: DerD am 09 Mai 2026, 10:22:40Dann vielleicht mal ein Schritt zurück: ich hatte als Basis rfmode den hier ausgewählt "HoneywActivL__SlowRf_FSK" und basierend darauf Frequenz, Deviation angepasst. Möglicherweise sollte ich von einer anderen Basis ausgehen? So wie ich das im SDR sehe, sind die Pulszeiten für SL/SH und LL/LH nämlich jeweils ziemlich gleich. Sprich es könnten die Einstellungen des CC1101 sein die nicht passen. Hast du einen Tipp was da zu empfehlen ist? Ich habe ja auch keinen anderen FSK-Sender mit dem ich testen könnte ob es da anders ist.Ich hab mir mal die Unterschiede zu den FSK rfmodes angeschaut.
Die rfmodes stehen am Anfang der signalduino_protocols.pm und können einfach miteinander verglichen werden.
0x12 MDMCFG2, wenn das sync-word bekannt ist, kannst Du auch mal 02 und 06 testen
0x14 MDMCFG0, bei den anderen rfmode wird 0xF8 verwendet
0x19 FOCCFG, bei FSK 0x16
0x1C AGCCTRL1, bei FSK 0x68 oder 0x40
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Mikel2906 - 10 Mai 2026, 11:31:19ch habe das Problem, dass die Variablen GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer zeigen. Ich lese die Daten direkt über Tasmota MQTT am Zähler ab. Meine Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht.
Ich habe meine Konfiguration angehängt. Ich benötige diesbezüglich Hilfe, ich bin mit meinem Latein am Ende.
Viele Grüße
Ich habe meine Konfiguration angehängt. Ich benötige diesbezüglich Hilfe, ich bin mit meinem Latein am Ende.
Viele Grüße
#8
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:20:49Wow, das wäre natürlich der Hit. So richtig glauben kann ich es noch nicht ... aber lassen wir uns mal überraschen.
Wenn das Ergebnis sich bewahrheitet mußt du aber eine Runde ausgeben.
... aber lassen wir uns mal überraschen. Wenn das Ergebnis sich bewahrheitet mußt du aber eine Runde ausgeben.
#9
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 10 Mai 2026, 11:08:24Gestern hab ich NN neu trainiert
Grund:
Mein WW-Programm in der WP läuft seit mehr als 1 Woche total anders um während der WW-Aufbereitung die WW-Arbeitszahl der WP höher zu bekommen....
- verschiedene Zeiten mit verschiedenen Temperaturen
- Legionellenprogramm aktiv mit 63 °C und 1x / Woche am SA um 14:00 Uhr
- wenig Komforverlust
Ergebnis ist im Schnitt ca. 2-2.7 kWh/Tag weniger Energieverbrauch bei der WW-Aufbereitung
(vorher 1 x täglich Mittagszeit auf 57 Grad und da war schon Potential (3 kWh/Tag) gegenüber vorher rausgekommen)
NN-Ergebnis leider grad erst angeschaut:
=>>> WOW - wenns wirklich stimmt und dauerhaft bleibt
Meine neueste aktuelle Einstellung in attr aiControl:
Mal sehen was nach 24 Stunden an Ergebnis kommt
Grund:
Mein WW-Programm in der WP läuft seit mehr als 1 Woche total anders um während der WW-Aufbereitung die WW-Arbeitszahl der WP höher zu bekommen....
- verschiedene Zeiten mit verschiedenen Temperaturen
- Legionellenprogramm aktiv mit 63 °C und 1x / Woche am SA um 14:00 Uhr
- wenig Komforverlust
Ergebnis ist im Schnitt ca. 2-2.7 kWh/Tag weniger Energieverbrauch bei der WW-Aufbereitung
(vorher 1 x täglich Mittagszeit auf 57 Grad und da war schon Potential (3 kWh/Tag) gegenüber vorher rausgekommen)
NN-Ergebnis leider grad erst angeschaut:
=>>> WOW - wenns wirklich stimmt und dauerhaft bleibt
Code Auswählen
Informationen zum neuronalen Netz der Verbrauchsvorhersage
letztes KI-Training: 09.05.2026 21:38:52 / Laufzeit in Sekunden: 5168
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 78.03 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08
=== Modellparameter ===
Normierungsgrenzen: PV=10450 Wh, Hausverbrauch: Min=0 Wh / Max=6770 Wh
Trainingsdaten: 12069 Datensätze (Training=9655, Validation=2414)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.002, Momentum=0.8, BitFail-Limit=0.28
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Period=20
Modellalter: 11 h
=== Trainingsmetriken ===
bestes Modell bei Epoche: 5706 (max. 15000)
Training MSE: 0.000634
Validation MSE: 0.000073
Validation MSE Average: 0.000094
Validation MSE Standard Deviation: 0.000011
Validation Bit_Fail: 0
Model Bias: -7 Wh
Model Slope: 1.0
Trainingsbewertung: ok
=== Fehlermaße der Prognosen ===
MAE: 44.38 Wh
MedAE: 33.76 Wh
RMSE: 48.59 Wh
RMSE relative: 4 %
RMSE Rating: excellent
MAPE: 3.88 %
MdAPE: 2.41 %
R²: 1.00
=== Rauschen ===
Rauschen Bewertung: low
Empfehlung für Bit_Fail: 0.28 (Einstellung von aiControl->aiConBitFailLimit)
=== Drift-Kennzahlen ===
Drift Score: -
Drift RMSE ratio: -
Drift Slope: 1
Drift Bias: 0
Drift Bias Live: -
Drift Index: -
Drift Bewertung: fresh_model
Slope recalibrated: 1.0
Bias recalibrated: -7
letzte Rekalibrierung: -
Meine neueste aktuelle Einstellung in attr aiControl:
Code Auswählen
aiConAbsOversample=0.25
aiConActFunc=ELLIOT_SYMMETRIC
aiConActivate=1
aiConAlpha=0.8
aiConBitFailLimit=0.28
aiConHiddenLayers=80-40
aiConLearnRate=0.002
aiConMomentum=0.8
aiConProfile=v1_heatpump_active_pv
aiConShuffleMode=2
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConTrainStart=7:9
aiStorageDuration=3600
aiTrainStart=3
aiTreesPV=30
Mal sehen was nach 24 Stunden an Ergebnis kommt
#10
Automatisierung / Aw: DBLOG: sqlite Another oper...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 10:56:09Hallo Hadl,
Es könnte ein Datenbank Deadlock sein. Es müßte aber im normalen Log wahrscheinlich Meldungen zu finden sein die darauf hindeuten. Wenn nicht, würde ich dennoch raten zu prüfen ob du evtl. DbRep-Devices hast die einen parallelen Schreibzugriff auf die DB verursachen könnten, z.B. Aktivitäten die löschen möchten. Dort füge vorsichtshalber im pre- und after Command ein Schließen und wieder Öffnen der DbLog-DB ein.
Ich habe diesbezüglich mal recherchiert:
Hier sind die wichtigsten Fakten zu SQLite und parallelen Schreibvorgängen:
* Single-Writer-Prinzip: SQLite erlaubt standardmäßig nur einen Schreibvorgang zur selben Zeit. Wenn ein Prozess in die Datenbank schreibt, wird die Datenbankdatei für andere Schreibprozesse gesperrt.
* «Database is locked»-Fehler: Bei vielen parallelen Schreibzugriffen kommt es häufig zur Fehlermeldung SQLITE_BUSY (Datenbank gesperrt), da wartende Schreibprozesse nicht blockieren, sondern fehlschlagen.
* WAL-Modus (Write-Ahead Logging): Durch die Aktivierung des WAL-Modus (PRAGMA journal_mode=WAL;) wird die Situation verbessert. WAL ermöglicht es, dass während eines aktiven Schreibvorgangs parallel gelesen werden kann. Parallele Schreibzugriffe bleiben jedoch meist serialisiert, d.h. sie werden nacheinander abgearbeitet.
* Lösung für Sperrkonflikte: Um Schreibkonflikte zu minimieren, sollten Schreibtransaktionen explizit mit BEGIN IMMEDIATE gestartet werden.
Den letzten Punkt kannte ich noch nicht. Das muß ich mir mal anschauen inwieweit es in DbLog / DbRep einzubauen wäre. Der WAL-Modus ist in DbLog per default aktiviert.
LG,
Heiko
ZitatIch habe nun auch einen Filelog vom dblog mitlaufen lassen, dort sieht man das es ab 14:33 zu dem Problem "Another operation is in progress - resync at NextSync" kam. Seitdem wurde auch "sql_processing_time" nichtmehr geschrieben. Vorher war es stabil unter 2 Sekunden und wurde alle 1-2 Minuten geschrieben.Das bestärkt mich in der Vermutung, dass der Schreibprozess der SQLite "hängt" bzw. blockiert. Dadurch kommen auch keine sql_processing_time Events mehr. Der Schreibprozess wird gestartet, aber meldet nichts mehr zurück -> der nächste Schreibprozsse läuft auf "Another operation is in progress - resync at NextSync".
Es könnte ein Datenbank Deadlock sein. Es müßte aber im normalen Log wahrscheinlich Meldungen zu finden sein die darauf hindeuten. Wenn nicht, würde ich dennoch raten zu prüfen ob du evtl. DbRep-Devices hast die einen parallelen Schreibzugriff auf die DB verursachen könnten, z.B. Aktivitäten die löschen möchten. Dort füge vorsichtshalber im pre- und after Command ein Schließen und wieder Öffnen der DbLog-DB ein.
Ich habe diesbezüglich mal recherchiert:
Hier sind die wichtigsten Fakten zu SQLite und parallelen Schreibvorgängen:
* Single-Writer-Prinzip: SQLite erlaubt standardmäßig nur einen Schreibvorgang zur selben Zeit. Wenn ein Prozess in die Datenbank schreibt, wird die Datenbankdatei für andere Schreibprozesse gesperrt.
* «Database is locked»-Fehler: Bei vielen parallelen Schreibzugriffen kommt es häufig zur Fehlermeldung SQLITE_BUSY (Datenbank gesperrt), da wartende Schreibprozesse nicht blockieren, sondern fehlschlagen.
* WAL-Modus (Write-Ahead Logging): Durch die Aktivierung des WAL-Modus (PRAGMA journal_mode=WAL;) wird die Situation verbessert. WAL ermöglicht es, dass während eines aktiven Schreibvorgangs parallel gelesen werden kann. Parallele Schreibzugriffe bleiben jedoch meist serialisiert, d.h. sie werden nacheinander abgearbeitet.
* Lösung für Sperrkonflikte: Um Schreibkonflikte zu minimieren, sollten Schreibtransaktionen explizit mit BEGIN IMMEDIATE gestartet werden.
Den letzten Punkt kannte ich noch nicht. Das muß ich mir mal anschauen inwieweit es in DbLog / DbRep einzubauen wäre. Der WAL-Modus ist in DbLog per default aktiviert.
LG,
Heiko