Neueste Beiträge

#11
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 09 Mai 2026, 20:10:12
Nachsatz:
Zitat von: 300P am 09 Mai 2026, 20:05:40Welche max. Verbräuche hast du eigentlich normalerweise pro Stunde ?

Nimm diesen Wert und dann nutze im SF-Modul den integrierten set-Befehl mit folgenden Einstellungen:
=>> Nur so siehst man dann die Möglichkeiten dieses komplexen set-Befehls :)
Code Auswählen Erweitern
set mySolarForecast reset aiData searchValue=con>=hier_den_Höchstwert_eintragen

Die gefundenen Werte gemäß Filter werden im normalen FHEM-Log protokolliert !  8)
#12
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 09 Mai 2026, 20:06:40
Zitat von: Gisbert am 09 Mai 2026, 20:01:12oder benötigst du diesen File?
Nein wird dazu nicht benötigt
#13
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 09 Mai 2026, 20:05:40
Hier meine Infos / Hinweise :

Teil 1:

A:
Logeintrag :   input datasets=2863   ist "noch" etwas wenig nach meiner Ansicht - sollte aber trotzdem "gehen".

B:
2026.05.09 16:58:35.479 1: mySolarForecast DEBUG> AI FANN - There are 4 Records skipped due to incomplete or invalid data.
2026.05.09 16:58:35.491 1: mySolarForecast DEBUG> AI FANN - Target-Norm: raw_max=109600, p99=3500, p99.5=11100, targmaxval=14430
2026.05.09 16:58:35.492 1: mySolarForecast DEBUG> AI FANN - True Outliers above p99.5 (11100): 109600
20

4 Datensätze sind nicht verwertbar - lass einfach so stehen

Da sind aber evtl. zu hohe Werte in deinen Datensätzen vorhanden
=>>> True Outliers above p99.5

und der gleichartige Hinweis auch bei:
=>>> raw_max=109600

Das wären Verbräuche von 109,6 kWh in einer Stunde. :o

Welche max. Verbräuche hast du eigentlich normalerweise pro Stunde ?

Nimm diesen Wert und dann nutze im SF-Modul den integrierten set-Befehl mit folgenden Einstellungen:
=>> Nur so siehst man dann die Möglichkeiten dieses komplexen set-Befehls :)
set mySolarForecast reset aiData searchValue=con>=hier_den_Höchstwert_eintragen

Dann lösche die für dich wirklich zu hohen Verbrauchs- bzw- CON-Werte in den Datensätzen mit
set mySolarForecast reset aiData delValue=con>=hier_den_max_Wert_der_okay_ist_eintragen


Noch eine Empfehlung für diesen Eintrag, um es dem System am Anfang etwas einfacher zu machen und nicht zu tief zu gehen.(Geschwindigkeit)

aiConHiddenLayers=64-32 statt deines "leeren Eintrages" der dann 80-40-20 nutzt.
Dann starte das Training erneut und schicke das komplette Log und das Endergebnis wieder  O:-)



#14
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Gisbert - 09 Mai 2026, 20:01:12
Hallo 300P,

oder benötigst du diesen File? (File gelöscht, da nicht bemötigt.)

Viele Grüße Gisbert
#15
Automatisierung / Aw: DBLOG: sqlite Another oper...
Letzter Beitrag von Hadl - 09 Mai 2026, 19:40:38
Hallo,
heute ist der Fehler mal wieder aufgetreten.

define logdb DbLog ./db.conf .*:.*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb cacheLimit 1000
attr logdb cacheOverflowThreshold 20000
attr logdb event-min-interval .*:3600
attr logdb event-on-change-reading .*
attr logdb exportCacheAppend 1
attr logdb insertMode 0
attr logdb room Log
attr logdb showproctime 1
attr logdb syncInterval 120
#   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
#   CONFIGURATION ./db.conf
#   DEF        ./db.conf .*:.*
#   FD         5
#   FUUID      5d6c1e06-f33f-a72e-296f-6c78ab79b33a837c
#   FVERSION   93_DbLog.pm:v5.11.0-s29401/2024-12-05
#   MODE       asynchronous
#   MODEL      SQLITE
#   NAME       logdb
#   NR         2
#   NTFY_ORDER 50-logdb
#   PID        833
#   REGEXP     .*:.*
#   SBP_PID    972
#   SBP_STATE  running
#   STATE      Another operation is in progress - resync at NextSync
#   TYPE       DbLog
#   dbconn     SQLite:dbname=/opt/fhem/fhem.db
#   dbuser     
#   eventCount 34366
#   HELPER:
#     COLSET     1
#     DEVICECOL  64
#     EVENTCOL   512
#     LASTLIMITRUNTIME 1778345398.72136
#     LONGRUN_PID 1778329921.99097
#     OLDSTATE   Another operation is in progress - resync at NextSync
#     PACKAGE    main
#     READINGCOL 64
#     TC         current
#     TH         history
#     TYPECOL    64
#     UNITCOL    32
#     VALUECOL   128
#     VERSION    5.11.0
#   Helper:
#     DBLOG:
#       CacheOverflowLastNum:
#         logdb:
#           TIME       1778344311.10306
#           VALUE      0
#       CacheOverflowLastState:
#         logdb:
#           TIME       1778344311.10306
#           VALUE      normal
#       CacheUsage:
#         logdb:
#           TIME       1778344250.435
#           VALUE      0
#       background_processing_time:
#         logdb:
#           TIME       1778329857.84606
#           VALUE      1.9819
#       lastCachefile:
#         logdb:
#           TIME       1778344250.43319
#           VALUE      ./log/cache_logdb_2025-05-18_07-14-14 (0 cache rows exported)
#       sql_processing_time:
#         logdb:
#           TIME       1778329857.84606
#           VALUE      1.9718
#       state:
#         logdb:
#           TIME       1778344250.43776
#           VALUE      Another operation is in progress - resync at NextSync
#   OLDREADINGS:
#   READINGS:
#     2026-05-09 18:49:58   CacheOverflowLastNum 0
#     2026-05-09 18:31:51   CacheOverflowLastState normal
#     2026-05-09 18:50:56   CacheUsage      17374
#     2026-05-09 18:49:58   NextSync        2026-05-09 18:51:58 or when CacheUsage 1000 is reached
#     2026-05-09 14:30:57   background_processing_time 1.9819
#     2026-05-09 18:30:50   lastCachefile   ./log/cache_logdb_2025-05-18_07-14-14 (0 cache rows exported)
#     2026-05-09 14:30:57   sql_processing_time 1.9718
#     2026-05-09 18:49:58   state           Another operation is in progress - resync at NextSync
#
setstate logdb Another operation is in progress - resync at NextSync
setstate logdb 2026-05-09 18:49:58 CacheOverflowLastNum 0
setstate logdb 2026-05-09 18:31:51 CacheOverflowLastState normal
setstate logdb 2026-05-09 18:50:56 CacheUsage 17374
setstate logdb 2026-05-09 18:49:58 NextSync 2026-05-09 18:51:58 or when CacheUsage 1000 is reached
setstate logdb 2026-05-09 14:30:57 background_processing_time 1.9819
setstate logdb 2026-05-09 18:30:50 lastCachefile ./log/cache_logdb_2025-05-18_07-14-14 (0 cache rows exported)
setstate logdb 2026-05-09 14:30:57 sql_processing_time 1.9718
setstate logdb 2026-05-09 18:49:58 state Another operation is in progress - resync at NextSync

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.
Über mehrere Stunden hat sich das nicht automatisch geheilt. Nach einen fhem restart gehts aber wieder normal!
Die meisten Cache files sind auch leer, weil sie nachdem sie geschrieben wurden gleich wieder mit "0 cache rows exported" überschrieben wurden.

2026-05-09_14:30:57 logdb background_processing_time: 1.9819
2026-05-09_14:30:57 logdb sql_processing_time: 1.9718
2026-05-09_14:30:57 logdb CacheUsage: 123
2026-05-09_14:33:02 logdb Another operation is in progress - resync at NextSync
2026-05-09_14:33:02 logdb CacheUsage: 1060
2026-05-09_14:55:06 logdb CacheOverflowLastNum: 723
2026-05-09_14:55:06 logdb CacheOverflowLastState: exceeded
2026-05-09_14:55:06 logdb CacheUsage: 20725
2026-05-09_14:55:06 logdb CacheOverflowLastNum: 725
2026-05-09_14:55:06 logdb lastCachefile: ./log/cache_logdb_2025-05-18_07-14-14 (20725 cache rows exported)
2026-05-09_14:55:06 logdb CacheUsage: 0
2026-05-09_14:55:06 logdb Cache exported to "lastCachefile" due to Cache overflow
2026-05-09_14:55:06 logdb Another operation is in progress - resync at NextSync
2026-05-09_14:55:06 logdb lastCachefile: ./log/cache_logdb_2025-05-18_07-14-14 (0 cache rows exported)
2026-05-09_14:55:06 logdb CacheUsage: 1
2026-05-09_14:55:06 logdb CacheUsage: 0
2026-05-09_14:55:06 logdb CacheUsage: 1
2026-05-09_14:55:06 logdb Cache exported to "lastCachefile" due to Cache overflow
2026-05-09_14:55:06 logdb CacheUsage: 2
2026-05-09_14:55:06 logdb Another operation is in progress - resync at NextSync
2026-05-09_14:55:06 logdb CacheUsage: 3
2026-05-09_14:56:06 logdb CacheOverflowLastNum: 0
2026-05-09_14:56:06 logdb CacheOverflowLastState: normal
2026-05-09_14:56:06 logdb CacheUsage: 1069
2026-05-09_15:17:08 logdb CacheOverflowLastNum: 645
2026-05-09_15:17:08 logdb CacheOverflowLastState: exceeded
2026-05-09_15:17:08 logdb CacheUsage: 20647
2026-05-09_15:17:08 logdb CacheOverflowLastNum: 647
2026-05-09_15:17:08 logdb lastCachefile: ./log/cache_logdb_2025-05-18_07-14-14 (20647 cache rows exported)
2026-05-09_15:17:08 logdb CacheUsage: 0
2026-05-09_15:17:08 logdb Cache exported to "lastCachefile" due to Cache overflow
2026-05-09_15:17:08 logdb Another operation is in progress - resync at NextSync
2026-05-09_15:17:08 logdb lastCachefile: ./log/cache_logdb_2025-05-18_07-14-14 (0 cache rows exported)
2026-05-09_15:17:08 logdb CacheUsage: 1
2026-05-09_15:17:08 logdb CacheUsage: 0
2026-05-09_15:17:08 logdb CacheUsage: 1
2026-05-09_15:17:08 logdb Cache exported to "lastCachefile" due to Cache overflow
2026-05-09_15:17:08 logdb CacheUsage: 2
2026-05-09_15:17:08 logdb Another operation is in progress - resync at NextSync
2026-05-09_15:17:08 logdb CacheUsage: 3

Die Datenbank kann ich mit sqlite3 Kommandos von der Konsole aus nutzen, da scheint nichts zu blockieren.

Hat jemand eine Idee woran das liegen könnte?

Viele Grüße

Hadl
#16
Automatisierung / Aw: [gelöst] allowed: Kommando...
Letzter Beitrag von betateilchen - 09 Mai 2026, 18:00:29
Für mich ist das nicht überraschend. Rudi hatte das Attribut seinerzeit bei der Einführung (Ende 2018) sogar in einem eigenen Thread erklärt.

https://forum.fhem.de/index.php?topic=92423.0

Zitat von: Dr. Boris Neubert am 09 Mai 2026, 13:53:15Ich habe die Modulhilfe gelesen, aber natürlich nicht ganz.

Dann darfst Du aber bitte nicht das Modul dafür verantwortlich machen, dass etwas nicht so funktioniert, wie Du Dir das vorstellst  8)

Zitat von: Dr. Boris Neubert am 09 Mai 2026, 13:53:15Damit das Modul leistet, was es verspricht, sollte man meiner Meinung nach kein extra Attribut setzen müssen.

Nun, da müsste man erstmal eindeutig definieren, was genau "das Modul zu leisten verspricht". Da werden die Meinungen ziemlich sicher auseinandergehen.

Zitat von: Dr. Boris Neubert am 09 Mai 2026, 13:53:15Ich reiche demnächst einen Patch für die Modulhilfe ein. Damit nach mir und Otto nicht noch jemand hereinfällt.

Wenn Du mal nach dem Attributnamen im Forum suchst, wirst Du feststellen, dass das schon unzählige Male diskutiert, erklärt und in der Doku angepasst wurde. Ihr beiden seid nicht die Ersten oder Einzigen, die darüber stolpern.
#17
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Gisbert - 09 Mai 2026, 17:59:47
Hallo 300P,

ich hatte gegen 17:00 gestartet und nach ca. 50 Minuten den log kopiert. Der log-Auszug enthält insgesamt 1296 Zeilen - reicht das schon für eine Analyse?

Ich hatte diese Einstellungen verwendet:
ZitatLass den Parameter aiConTrainStart auf default oder löschen und setze ctrlDebug=aiProcess.

Viele Grüße Gisbert
#18
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 09 Mai 2026, 17:47:03
Statt:

Zitat von: Gisbert am 09 Mai 2026, 15:38:19aiConTrainStart=1:5
=>>> jeden Tag  automatisch nach der 5 Stunde NEU trainieren - zu eng gesetzt  ;)

=>>> besser normal nur alle 7 Tage nach der xy Stunde automatisch NEU Trainieren
aiConTrainStart=7:5


AktuellEinstellung bei mir:

aiConAbsOversample=0.50
aiConActFunc=ELLIOT_SYMMETRIC
aiConActivate=1
aiConAlpha=0.8
aiConBitFailLimit=0.20
aiConHiddenLayers=64-32
aiConLearnRate=0.002
aiConMomentum=0.8
aiConProfile=v1_heatpump_active_pv - lass aber deinen Eintrag v1_heatpump_pv bestehen
aiConShuffleMode=2
aiConShufflePeriod=20
aiConSteepness=1.0
aiConTrainAlgo=INCREMENTAL
aiConTrainStart=7:9     (Dann - mit 9 - kannst du am 7 Tag morgens bis knapp 09:00 Uhr noch sehen wie die letzten Ergebnisse waren)
aiStorageDuration=3600    (viele Daten von PV und CON bereit halten)
aiTrainStart=3
aiTreesPV=30

und setze:
attr Forecast ctrlDebug none,aiProcess,aiProcess_longDamit du im log was sehen kannst wenn und was da mit der CON-Vorhersageberechnung im Training so passiert.  O:-)


#19
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 09 Mai 2026, 17:17:33
Zitat von: DS_Starter am 09 Mai 2026, 16:36:55Aber 300P träumt schon von Trainingslogs  ;)  ...

😴⬍😉
#20
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 09 Mai 2026, 16:36:55
Hallo Gisbert,

Bist du sicher dass diese Zuweisung stimmt?

attr mySolarForecast setupInverterDev01 Deye_Inverter pvIn=pv_total_power:W pvOut=inverter_power:W capacity=13200 etotal=total_pv_production:kWh strings=Sueddach1,Sueddach2

Ich frage weil pvIn die DC PV-Eingangsleistung ist, also die Leistung der Solarzellen. Wenn pv_total_power dieser physikalische Wert ist, passt es. 
pvOut ist die vom Inverter erzeugte Leistung, also unsere Nutzleistung die wir ins Hausnetz geliefert bekommen. Wenn inverter_power dieser Wert ist, passt das auch.

Zitat2026.05.09 15:51:47.958 3: Timeout for FHEM::SolarForecast::aiFannCreateConTrainData reached, terminated process 68513
2026.05.09 15:51:47.959 1: mySolarForecast -> BlockingCall FHEM::SolarForecast::aiFannCreateConTrainData pid:68513 aborted: Timeout: process terminated
Das ist nicht gut. Das Training wird nicht beendet, sondern bricht mit Timeout ab. Das ist mit Sicherheit problematisch weil das Timeout 1 Tag! beträgt. Schon 2-3 Stunden würde ich als lang bezeichnen.
Lass den Parameter aiConTrainStart auf default oder löschen und setze ctrlDebug=aiProcess.
Dann starte der Trainingsprozess wie du es bereits getan hast. Kann man immer wieder aufsetzen.

Dann poste uns das Trainingslog. Müssen wir uns anschauen. Heute habe ich keine Zeit mehr ... kommt gleich Besuch.
Aber 300P träumt schon von Trainingslogs  ;)  ... er kennt sich auch gut damit aus, was sicher mittlerweile auf einige SF-User zutrifft.

LG,
Heiko