Neueste Beiträge

#11

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:52:39

Hallo 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

#12

Bastelecke / Aw: unbekanntes Funkprotokoll ...

Letzter Beitrag von Ralf9 - 10 Mai 2026, 11:32:19

0x1D 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

Das 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)
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.

Hast Du auch mal die 0x43 getestet ob es beim Empfang einen Unterschied macht?

Dann 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

#13

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Mikel2906 - 10 Mai 2026, 11:31:19

ch 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

#14

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:20:49

Wow, 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. 

#15

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 10 Mai 2026, 11:08:24

Gestern 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

Code Auswählen Erweitern

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 Erweitern

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

[* Single-Writer-Prinzip:]

#16

Automatisierung / Aw: DBLOG: sqlite Another oper...

Letzter Beitrag von DS_Starter - 10 Mai 2026, 10:56:09

Hallo Hadl,

Ich 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

#17

Solaranlagen / Aw: Marstek Venus E Modulentwi...

Letzter Beitrag von Moli - 10 Mai 2026, 10:51:52

Moin, gibt es Marstek noch? Mein Ticket ist seit dem 6.4. ohne jede Reaktion.
Ich weiß, die Webseite ist noch da.

#18

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 10 Mai 2026, 10:37:47

Moin @all,

danke für die Rückmeldung Peter.
Da können wir nun einen Haken dran machen denke ich. Auch bei mir passt alles nach wie vor.

LG,
Heiko

#19

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von dieter114 - 10 Mai 2026, 10:29:51

EDIT:
SF-Wiki ? - dann kann ich es korrigieren

Nö im WiKi Fronius Komplettbeispiel.
Das mache ich wenn alles endlich mal richtig läuft.

LG WDS

#20

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von peterboeckmann - 10 Mai 2026, 10:13:26

Moin Heiko,

der Entladevorgang der Batterien sieht in v2.6.7 gut aus.

auch der Ladevorgang sieht in der v2.6.7 gut aus.
Screenshot anbei.

Viele Grüße,
Peter