Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

Girgl · 14 März 2025, 15:33:17

Funktioniert, danke, das wars erst mal.

VG Girgl

ch.eick · 14 März 2025, 15:36:09

Zitat von: Girgl am 14 März 2025, 15:33:17Funktioniert, danke, das wars erst mal.

Das Svn_GetFile macht wohl nur einzelne files und keine ganze Struktur.

Ich habe es mal getestet:

fhem@raspberrypi:~/test$ svn checkout  https://svn.fhem.de/fhem/trunk/fhem/contrib/ch.eick/ .
A    Docker
A    Grafana
A    Grafana/Dashboard
A    Grafana/Diagramme
A    Photovoltaik
< snip >
A    Strombörse/EVU_Tibber/RAW_EVU_Tibber.txt
A    Strombörse/EVU_aWATTar/RAW_EVU_aWATTar.txt
Ausgecheckt, Revision 29749.
fhem@raspberrypi:~/test$ ls -l
insgesamt 16
drwxr-xr-x 2 fhem fhem 4096 Mär 14 15:45 Docker
drwxr-xr-x 4 fhem fhem 4096 Mär 14 15:45 Grafana
drwxr-xr-x 9 fhem fhem 4096 Mär 14 15:45 Photovoltaik
drwxr-xr-x 4 fhem fhem 4096 Mär 14 15:45 Strombörse
fhem@raspberrypi:~/test$

Girgl · 15 März 2025, 21:22:23

Hallo,

mit folgenden Problemen kämpfe ich noch.
Minütliche Fehlermeldungen im WR_1:

Code Auswählen

2025.03.15 20:38:00 3: WR_1: CreateDataObjects unpack of 0047 with N for MODBUS_Unit-ID resulted in undefined value
2025.03.15 20:38:00 3: WR_1: CreateDataObjects unpack of 0000 with N for MODBUS_Byte_Order_Note resulted in undefined value

und

Code Auswählen

2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - -------- New selection --------- 
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - Command: sqlCmd call dwd_load('full',curdate(),'none');
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - Timestamp begin human readable: not set
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - Timestamp end human readable: not set
2025.03.15 20:38:11 5: DbRep LogDBRep_PV_KI_Prognose - BlockingCall with PID "78701" started
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - Database Model: MYSQL
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - Database connect - user: fhemMysql, UTF-8 option set: no
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - Database Character set is >utf8mb4_bin<
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - SQL execute: call dwd_load('full',curdate(),'none');
2025.03.15 20:38:12 2: DbRep LogDBRep_PV_KI_Prognose - ERROR - DBD::mysql::st execute failed: Data truncated for column 'Neff' at row 125 at ./FHEM/93_DbRep.pm line 11860.

Ein 'call dwd_load('update',curdate(),'none');' läuft problemlos durch. Die Neff-Werte in den Tabellen current und history sind alle normal(0-100). Ein lösche der Tabelle dwdfull hilft auch nichts.

Wo kann ich da ansetzen?

Falls es hilft, das DBLog-Device:

Code Auswählen

define fhemMysql DbLog ./dbMysql.conf .*:.*
attr fhemMysql DbLogSelectionMode Include
attr fhemMysql DbLogType Current/History
attr fhemMysql asyncMode 1
attr fhemMysql room DB
attr fhemMysql showproctime 1
attr fhemMysql syncInterval 60
#   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32 
#   CONFIGURATION ./dbMysql.conf
#   DEF        ./dbMysql.conf .*:.*
#   FD         7
#   FUUID      67cc50da-f33f-6b20-de25-f81665c254e03213
#   FVERSION   93_DbLog.pm:v5.11.0-s29401/2024-12-05
#   MODE       asynchronous
#   MODEL      MYSQL
#   NAME       fhemMysql
#   NR         3
#   NTFY_ORDER 50-fhemMysql
#   PID        67338
#   REGEXP     .*:.*
#   SBP_PID    67340
#   SBP_STATE  running
#   STATE      connected
#   TYPE       DbLog
#   dbconn     mysql:database=fhem;host=localhost;port=3306
#   dbuser     fhemMysql
#   eventCount 528
#   HELPER:
#     COLSET     1
#     DEVICECOL  64
#     EVENTCOL   512
#     OLDSTATE   connected
#     PACKAGE    main
#     READINGCOL 64
#     TC         current
#     TH         history
#     TYPECOL    64
#     UNITCOL    32
#     VALUECOL   128
#     VERSION    5.11.0
#   OLDREADINGS:
#   READINGS:
#     2025-03-15 21:17:18   CacheOverflowLastNum 0
#     2025-03-15 10:01:05   CacheOverflowLastState normal
#     2025-03-15 21:17:18   CacheUsage      28
#     2025-03-15 21:17:18   NextSync        2025-03-15 21:18:18 or when CacheUsage 500 is reached
#     2025-03-15 21:17:18   background_processing_time 0.0825
#     2025-03-15 21:17:18   sql_processing_time 0.0748
#     2025-03-15 21:17:18   state           connected
#
setstate fhemMysql connected
setstate fhemMysql 2025-03-15 21:17:18 CacheOverflowLastNum 0
setstate fhemMysql 2025-03-15 10:01:05 CacheOverflowLastState normal
setstate fhemMysql 2025-03-15 21:17:18 CacheUsage 28
setstate fhemMysql 2025-03-15 21:17:18 NextSync 2025-03-15 21:18:18 or when CacheUsage 500 is reached
setstate fhemMysql 2025-03-15 21:17:18 background_processing_time 0.0825
setstate fhemMysql 2025-03-15 21:17:18 sql_processing_time 0.0748
setstate fhemMysql 2025-03-15 21:17:18 state connected

VG Girgl

ch.eick · 16 März 2025, 11:27:14

Hallo Girgl

Zitat von: Girgl am 15 März 2025, 21:22:23mit folgenden Problemen kämpfe ich noch.
Minütliche Fehlermeldungen im WR_1:
Code Auswählen Erweitern
2025.03.15 20:38:00 3: WR_1: CreateDataObjects unpack of 0047 with N for MODBUS_Unit-ID resulted in undefined value 2025.03.15 20:38:00 3: WR_1: CreateDataObjects unpack of 0000 with N for MODBUS_Byte_Order_Note resulted in undefined value

Kann es sein, dass Du versucht hast zusätzliche Register zu definieren, die noch als Leichen im Device zufinden sind?
Ein Register h47 oder etwas mit 0000 kann ich bei mir nicht finden.
Schau Dir da mal genau die Allribute im Device WR_1 an und entferne eventuelle Fragment.

ch.eick · 16 März 2025, 11:52:21

Zitat von: Girgl am 15 März 2025, 21:22:23< snip >
2025.03.15 20:38:11 4: DbRep LogDBRep_PV_KI_Prognose - SQL execute: call dwd_load('full',curdate(),'none');
2025.03.15 20:38:12 2: DbRep LogDBRep_PV_KI_Prognose - ERROR - DBD::mysql::st execute failed: Data truncated for column 'Neff' at row 125 at ./FHEM/93_DbRep.pm line 11860.[/code]
Ein 'call dwd_load('update',curdate(),'none');' läuft problemlos durch.
Die Neff-Werte in den Tabellen current und history sind alle normal(0-100).
Ein lösche der Tabelle dwdfull hilft auch nichts.

Für mich scheint das ein Problem in der PV_KI_Prognose.py zu sein, die wird nach der MySQL Procedure dwd_load() aufgerufen.
Findest Du da im Fhem Log noch Meldungen?
Zum Testen kannst Du den Aufruf auch direkt in der Fhem Kommandozeile aufrufen.
Mit verbose >= 3 sollten da auch Meldungen aus der PV_KI_Prognose.py im Log erscheinen.

Code Auswählen

"/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.40 192.168.178.40 LogDBRep_PV_KI_Prognose WR_ctl Yield_fc"

Die Tabelle dwdfull scheint irgend ein Problem in Zeile 125 zu haben. Eventuell hilft ein copy/past und das Einblenden von Sonderzeichen im Editor.
Schau auch bitte mal nach den original Daten in der history Tabelle, die bei dem Zeitstempel, so ungefähr vor 1 Woche, zu finden sind.

Die Tabelle dwdfull wird übrigens bei jedem Lauf von dwd_load() mit Option "full" automatisch gelöscht. Ich liebe saubere Daten

Girgl · 16 März 2025, 13:02:31

ZitatKann es sein, dass Du versucht hast zusätzliche Register zu definieren, die noch als Leichen im Device zufinden sind?
Ein Register h47 oder etwas mit 0000 kann ich bei mir nicht finden.
Schau Dir da mal genau die Allribute im Device WR_1 an und entferne eventuelle Fragment.

Diese Meldungen hatte ich von Beginn an. In den Attributten ist nichts zu finden. In der gesamten fhem.cfg kommt die Zahl 47 nicht vor. Mit Verbose 0 lässt sich die Fehlermeldung unterdrücken. Dann werde ich damit leben.

Zu

ZitatRROR - DBD::mysql::st execute failed: Data truncated for column 'Neff' at row 125 at ./FHEM/93_DbRep.pm line 11860.

ich habe vorhin festgestellt, dass ich beim anlegen des WR_1_ctl das device nur WR_ctl benannt habe. Jetzt habe ich es analog zum Wiki benannt und beide Routinen (full, update) stoppen jetzt mit der Meldung

Code Auswählen

/opt/fhem/python/bin/PV_KI_Prognose.py:189: RemovedIn20Warning: Deprecated API features detected! These feature(s) are not compatible with SQLAlchemy 2.0. To prevent incompatible upgrades prior to updating applications, ensure requirements files are pinned to "sqlalchemy<2.0". Set environment variable SQLALCHEMY_WARN_20=1 to show all deprecation warnings.  Set environment variable SQLALCHEMY_SILENCE_UBER_WARNING=1 to silence this message. (Background on SQLAlchemy 2.0 at: https://sqlalche.me/e/b8d9)
  connection.execute(text(sql))
PV_KI_Prognose  running - start
PV_KI_Prognose  running - start
PV_KI_Prognose  DbLog  192.168.163.4 /fhem
PV_KI_Prognose  Fhem   192.168.163.4 : 8083
Inverter_Max_Power 9000
PV_KI_Prognose  running - connected to 192.168.163.4
PV_KI_Prognose  running - dwdfull read from DbLog 192.168.163.4
PV_KI_Prognose  running - RandomForestRegressor loading
PV_KI_Prognose  running - RandomForestRegressor loaded
PV_KI_Prognose  running - RandomForestRegressor trained
PV_KI_Prognose  running - RandomForestRegressor fitted with yield
PV_KI_Prognose  running - RandomForestRegressor read statistics
Variable: SunAlt               Importance: 0.71
Variable: Rad1h                Importance: 0.12
Variable: DD                   Importance: 0.09
Variable: R101                 Importance: 0.03
Variable: SunAz                Importance: 0.02
Variable: VV                   Importance: 0.02
Variable: TTT                  Importance: 0.01
Variable: Neff                 Importance: 0.0
Variable: SunD1                Importance: 0.0
Variable: N                    Importance: 0.0
Variable: RRS1c                Importance: 0.0
PV_KI_Prognose  running - old forecast deleted
--------------------------------------------
Forecast fc0     2025-03-16
PV_KI_Prognose  running - start forecast
Traceback (most recent call last):
  File "/opt/fhem/python/bin/PV_KI_Prognose.py", line 249, in <module>
    Limit = int(round(dfask.loc[dfask['TIMESTAMP'] == timestamp].yield_max.values[0],0))
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: index 0 is out of bounds for axis 0 with size 0

Ich denke ebenfalls ein SQL-Problem bzw. python-Problem.

Ich muss jetzt ein paar Stunden arbeiten und werde dann am Spätnachmittag weitersuchen und testen. Evtl. ist es nur ein Tippfehler oder copy/paste Problem.

ch.eick · 16 März 2025, 13:25:26

Zitat von: Girgl am 16 März 2025, 13:02:31Diese Meldungen hatte ich von Beginn an. In den Attributten ist nichts zu finden. In der gesamten fhem.cfg kommt die Zahl 47 nicht vor. Mit Verbose 0 lässt sich die Fehlermeldung unterdrücken. Dann werde ich damit leben.

Für die ersten Test ginge das, jedoch ist es merkwürdig. Ein Grund, warum ich kein Module geschrieben habe ist, dass man so eventuell z.B. beim ModBus Thread im Forum weitere Hilfe anfragen könnte. Mit verbose 5 kommen da ja auch detailiertere Hinweise, die man weiter analysieren könnte.

Zitatich habe vorhin festgestellt, dass ich beim anlegen des WR_1_ctl das device nur WR_ctl benannt habe.

Ich habe es bei mir ebenfalls nur WR_ctl benannt, es muss halt zum Aufruf im LogDBRep_PV_KI_Prognose passen, den da legt man das Ziel Device für die Ablage der Prognosedaten im Fhem fest.

ZitatIch denke ebenfalls ein SQL-Problem bzw. python-Problem.

Schau Dir da mal die dwdfull Tabelle an, ob für yield_max Werte eingetragen sind.
Warum auch immer hatte ich da heute auch Probleme und festgestellt, dass in der MySQL Datenbank noch einige SELECT Prozesse noch nicht abgeschlossen waren.
Du kannst auch in der PV_KI_Prognose.py an dieser Stelle mal das Limit auf einen Wert oberhalb Deiner Maximalen PV Leistung fix setzen und somit die Problemsuche etwas reduzieren. Das Limit soll nur vor zu euphorischen Prognosen der KI schützen.

Code Auswählen

        # Zu große Werte werden limitiert
        # Achtung, die yield Prognose Werte sind Angaben zum Ende der Stunde
        if (Prognose > 0 and loop_hour > 0):
          timestamp = date+" %02d:00:00" % (dfhour_start['VALUE'].values[0]+loop_hour-1)

          if (verbose >= 4):
              print("TIMESTAMP " + str(timestamp))

        #  Limit = int(round(dfask.loc[dfask['TIMESTAMP'] == timestamp].yield_max.values[0],0))
          Limit = 50000

          if (verbose >= 4):
            # Hier wird beim Anzeigen der Wert um eine Stunde vorher angezeigt
            print(dfhour_start['VALUE'].values[0]+loop_hour-1,Prognose,Limit)

          if (Prognose > Limit):
            if (verbose >= 4):
                print("Forecast value to high : " + str(Prognose)+" > " + str(Limit))
            Prognose = Limit

EDIT: Ich habe gerade nochmal im contrib das PV_KI_Prognosy.py Skript hochgeladen, nur falls ich bei mir likal bereits Änderungen drin hatte, die im contrib noch gefehlt haben. Ich meine, da war mal was mit einem IndexError, den ich jedoch bereits korrigiert hatte.

Am Anfang hat man leider oft sehr viele Baustellen, bis es mal richtig läuft.

VG Christian

Girgl · 16 März 2025, 17:21:58

Hallo Christian,

habe eben die neue Version getestet und die läuft durch ohne Fehler.
Allerdings wird, und das war bei der alten Version auch schon so, die Vorschau für morgen nicht generiert. In den readings habe ich die Fehlermeldung

Code Auswählen

block_3_WR_ctl_Diagramm
	

condition c03: Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1485.

Müsste nicht bei den readings ein "Yield_fc1_current" als Trigger auftauchen? Das fehlt bei mir.

ch.eick · 16 März 2025, 18:23:49

Zitat von: Girgl link=msg=1336976Allerdings wird, und das war bei der alten Version auch schon so, die Vorschau für morgen nicht generiert.

< snip >

Müsste nicht bei den readings ein "Yield_fc1_current" als Trigger auftauchen? Das fehlt bei mir.

Das wird aus dem PV_KI_PROGNOSE geschrieben.
Setz im DbRep mal verbose 5 und ruf das Skript nochmal auf. Schau mal im FHEM Log nach den Meldungen. Eventuell stimmt da irgendwas mit dem yield_max nicht. Mach mal den Test mit dem Limit bitte.

Edit: Wichtig ist, dass das Skript nicht parallel zur dwd_load() läuft, da dann noch Daten in der dwdfull Tabelle fehlen. Das war heute bei mir das Problem, weshalb der fc1 fehlte.
Ich habe den RPI mal neu gestartet, da 4GB RAM wohl nach einem Monat uptime etwas durcheinander sind.

Girgl · 16 März 2025, 20:57:30

Das ist der Log mit der aktuellen KI....py
"Setz im DbRep mal verbose 5 und ruf das Skript nochmal auf ohne dwd_load" wurde beachtet.

Code Auswählen

/opt/fhem/python/bin/PV_KI_Prognose.py:190: RemovedIn20Warning: Deprecated API features detected! These feature(s) are not compatible with SQLAlchemy 2.0. To prevent incompatible upgrades prior to updating applications, ensure requirements files are pinned to "sqlalchemy<2.0". Set environment variable SQLALCHEMY_WARN_20=1 to show all deprecation warnings.  Set environment variable SQLALCHEMY_SILENCE_UBER_WARNING=1 to silence this message. (Background on SQLAlchemy 2.0 at: https://sqlalche.me/e/b8d9)
  connection.execute(text(sql))
2025.03.16 20:41:02 3: WR_ctl 3_WR_ctl_Diagramm : Werte für das Diagramm
2025-03-16_05:00:00 0.00
2025-03-16_06:00:00 0.17
2025-03-16_07:00:00 0.25
2025-03-16_08:00:00 0.36
2025-03-16_09:00:00 0.69
2025-03-16_10:00:00 1.50
2025-03-16_11:00:00 2.02
2025-03-16_12:00:00 1.95
2025-03-16_13:00:00 1.57
2025-03-16_14:00:00 0.99
2025-03-16_15:00:00 0.49
2025-03-16_16:00:00 0.14
2025-03-16_17:00:00 0.08
2025-03-16_18:00:00 0.05
2025-03-16_19:00:00 0.04
2025-03-16_20:00:00 0.04
2025-03-16_21:00:00 0.00


2025-03-17_05:00:00 0.00
2025-03-17_06:00:00 0.26
2025-03-17_07:00:00 0.57
2025-03-17_08:00:00 0.72
2025-03-17_09:00:00 1.10
2025-03-17_10:00:00 1.82
2025-03-17_11:00:00 2.13
2025-03-17_12:00:00 2.08
2025-03-17_13:00:00 1.61
2025-03-17_14:00:00 1.01
2025-03-17_15:00:00 0.49
2025-03-17_16:00:00 0.14
2025-03-17_17:00:00 0.08
2025-03-17_18:00:00 0.05
2025-03-17_19:00:00 0.04
2025-03-17_20:00:00 0.04
2025-03-17_21:00:00 0.00

2025.03.16 20:41:02 4: WR_ctl: condition c03: Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1485.
 in perl block: 3_WR_ctl_Diagramm
PV_KI_Prognose  running - start
PV_KI_Prognose  running - start
PV_KI_Prognose  DbLog  192.168.163.4 /fhem
PV_KI_Prognose  Fhem   192.168.163.4 : 8083
Inverter_Max_Power 9000
PV_KI_Prognose  running - connected to 192.168.163.4
PV_KI_Prognose  running - dwdfull read from DbLog 192.168.163.4
PV_KI_Prognose  running - RandomForestRegressor loading
PV_KI_Prognose  running - RandomForestRegressor loaded
PV_KI_Prognose  running - RandomForestRegressor trained
PV_KI_Prognose  running - RandomForestRegressor fitted with yield
PV_KI_Prognose  running - RandomForestRegressor read statistics
Variable: SunAlt               Importance: 0.71
Variable: Rad1h                Importance: 0.12
Variable: DD                   Importance: 0.09
Variable: R101                 Importance: 0.03
Variable: SunAz                Importance: 0.02
Variable: VV                   Importance: 0.02
Variable: TTT                  Importance: 0.01
Variable: Neff                 Importance: 0.0
Variable: SunD1                Importance: 0.0
Variable: N                    Importance: 0.0
Variable: RRS1c                Importance: 0.0
PV_KI_Prognose  running - old forecast deleted
--------------------------------------------
Forecast fc0     2025-03-16
PV_KI_Prognose  running - start forecast
loop_hour 0 60
loop_hour 0
loop_hour 1 166
TIMESTAMP 2025-03-16 06:00:00
6 166 260
Yield_fc0_06  06 166
loop_hour 1
loop_hour 2 252
TIMESTAMP 2025-03-16 07:00:00
7 252 987
Yield_fc0_07  07 252
loop_hour 2
loop_hour 3 365
TIMESTAMP 2025-03-16 08:00:00
8 365 835
Yield_fc0_08  08 365
loop_hour 3
loop_hour 4 686
TIMESTAMP 2025-03-16 09:00:00
9 686 1187
Yield_fc0_09  09 686
loop_hour 4
loop_hour 5 1497
TIMESTAMP 2025-03-16 10:00:00
10 1497 2745
Yield_fc0_10  10 1497
loop_hour 5
loop_hour 6 2022
TIMESTAMP 2025-03-16 11:00:00
11 2022 2135
Yield_fc0_11  11 2022
loop_hour 6
loop_hour 7 1952
TIMESTAMP 2025-03-16 12:00:00
12 1952 2354
Yield_fc0_12  12 1952
loop_hour 7
loop_hour 8 1575
TIMESTAMP 2025-03-16 13:00:00
13 1575 2759
Yield_fc0_13  13 1575
loop_hour 8
loop_hour 9 994
TIMESTAMP 2025-03-16 14:00:00
14 994 1724
Yield_fc0_14  14 994
loop_hour 9
loop_hour 10 545
TIMESTAMP 2025-03-16 15:00:00
15 545 487
Forecast value to high : 545 > 487
Yield_fc0_15  15 487
loop_hour 10
loop_hour 11 429
TIMESTAMP 2025-03-16 16:00:00
16 429 142
Forecast value to high : 429 > 142
Yield_fc0_16  16 142
loop_hour 11
loop_hour 12 466
TIMESTAMP 2025-03-16 17:00:00
17 466 84
Forecast value to high : 466 > 84
Yield_fc0_17  17 84
loop_hour 12
loop_hour 13 388
TIMESTAMP 2025-03-16 18:00:00
18 388 46
Forecast value to high : 388 > 46
Yield_fc0_18  18 46
loop_hour 13
loop_hour 14 366
TIMESTAMP 2025-03-16 19:00:00
19 366 45
Forecast value to high : 366 > 45
Yield_fc0_19  19 45
loop_hour 14
loop_hour 15 364
TIMESTAMP 2025-03-16 20:00:00
20 364 42
Forecast value to high : 364 > 42
Yield_fc0_20  20 42
loop_hour 15
--------------------------------------------
max       off/at 2022 11:00
Middayhigh_start 00:00
Middayhigh_stop  00:00
4h               42
rest             42
morning          5048
afternoon        5367
day              10415
--------------------------------------------
PV_KI_Prognose  running - forecast written to FHEM
PV_KI_Prognose  running - old forecast deleted
--------------------------------------------
Forecast fc1     2025-03-17
PV_KI_Prognose  running - start forecast
loop_hour 0 215
loop_hour 0
loop_hour 1 471
TIMESTAMP 2025-03-17 06:00:00
6 471 260
Forecast value to high : 471 > 260
Yield_fc1_06  06 260
loop_hour 1
loop_hour 2 567
TIMESTAMP 2025-03-17 07:00:00
7 567 987
Yield_fc1_07  07 567
loop_hour 2
loop_hour 3 722
TIMESTAMP 2025-03-17 08:00:00
8 722 835
Yield_fc1_08  08 722
loop_hour 3
loop_hour 4 1097
TIMESTAMP 2025-03-17 09:00:00
9 1097 1187
Yield_fc1_09  09 1097
loop_hour 4
loop_hour 5 1821
TIMESTAMP 2025-03-17 10:00:00
10 1821 2745
Yield_fc1_10  10 1821
loop_hour 5
loop_hour 6 2227
TIMESTAMP 2025-03-17 11:00:00
11 2227 2135
Forecast value to high : 2227 > 2135
Yield_fc1_11  11 2135
loop_hour 6
loop_hour 7 2079
TIMESTAMP 2025-03-17 12:00:00
12 2079 2354
Yield_fc1_12  12 2079
loop_hour 7
loop_hour 8 1612
TIMESTAMP 2025-03-17 13:00:00
13 1612 2759
Yield_fc1_13  13 1612
loop_hour 8
loop_hour 9 1007
TIMESTAMP 2025-03-17 14:00:00
14 1007 1724
Yield_fc1_14  14 1007
loop_hour 9
loop_hour 10 648
TIMESTAMP 2025-03-17 15:00:00
15 648 487
Forecast value to high : 648 > 487
Yield_fc1_15  15 487
loop_hour 10
loop_hour 11 485
TIMESTAMP 2025-03-17 16:00:00
16 485 142
Forecast value to high : 485 > 142
Yield_fc1_16  16 142
loop_hour 11
loop_hour 12 285
TIMESTAMP 2025-03-17 17:00:00
17 285 84
Forecast value to high : 285 > 84
Yield_fc1_17  17 84
loop_hour 12
loop_hour 13 106
TIMESTAMP 2025-03-17 18:00:00
18 106 46
Forecast value to high : 106 > 46
Yield_fc1_18  18 46
loop_hour 13
loop_hour 14 75
TIMESTAMP 2025-03-17 19:00:00
19 75 45
Forecast value to high : 75 > 45
Yield_fc1_19  19 45
loop_hour 14
loop_hour 15 75
TIMESTAMP 2025-03-17 20:00:00
20 75 42
Forecast value to high : 75 > 42
Yield_fc1_20  20 42
loop_hour 15
--------------------------------------------
max       off/at 2135 11:00
Middayhigh_start 00:00
Middayhigh_stop  00:00
4h               42
rest             42
morning          6817
afternoon        5544
day              12361
--------------------------------------------
PV_KI_Prognose  running - forecast written to FHEM
PV_KI_Prognose  done

Davor: Das händische Setzen des Limit-Parameters beim alten script hat ebenfalls funktioniert, die Routine lief ebenfalls durch, aber ebenfalls mit dem Fehler

Code Auswählen

block_3_WR_ctl_Diagramm
	

condition c03: Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1485.

Ich werde weiter testen, meine Rückmeldung wird aber ein zwei Tage dauern, habe aber gerade viel Arbeit.

VG Girgl

Girgl · 16 März 2025, 21:15:03

...und eben den fhem-rechner neu gestartet, auch keine Besserung.

Eine schöne Woche und besten Dank für den bisherigen support!

VG Girgl

ch.eick · 17 März 2025, 09:34:24

Hallo Girgl,
ich habe mir die Python Warnung noch angeschaut.
Bei mir ist für python3-sqlalchemy noch eine ältere Version installiert. Eventuell machst Du da einen Downgrade.

Code Auswählen

root@raspberrypi:/opt/fhem# apt list --installed|grep python3-sqlalchemy
python3-sqlalchemy-ext/oldoldstable,now 1.2.18+ds1-2 arm64 [installed,automatic]

ch.eick · 17 März 2025, 10:24:16

Zitat von: Girgl am 16 März 2025, 20:57:30Davor: Das händische Setzen des Limit-Parameters beim alten script hat ebenfalls funktioniert, die Routine lief ebenfalls durch, aber ebenfalls mit dem Fehler
Code Auswählen Erweitern
block_3_WR_ctl_Diagramm condition c03: Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1485.

Wurde denn jetzt das Yield_fc1_current aus dem userreadings gesetzt?
Die Yield_fc[0|1]_* sollten auch alle da sein.

Girgl · 17 März 2025, 20:01:16

Hallo Christian,

es hat sich etwas geklärt! Die Ausgangssituation war:
Die Ki...Prognose brach ab in der Zeile mit Limit --> Limit händisch gesetzt --> script läuft durch, generiert (offenbar) alles bis auf fc_01_current mit Fehlermeldung "...condition c03: Can't..."
Aktuelles Ki...Prognose-script --> script läuft durch, generiert (offenbar) alles bis auf fc_01_current mit Fehlermeldung "...condition c03: Can't use string ("") a"
Ich habe nochmal alles was ich aus Deinen Codezeilen importiert hatte überprüft und einen Fehler gefunden. (siehe Bild). Das userreadings für fc_01 konnte nicht gesetzt werden, da syntax-Fehler. Somit "condition c03: Can't use string ("")" logisch, wo nichts ist, kann man nichts übernehmen.
Das ist mir etwas peinlich, ich habe keine Ahnung wo die Zahl 511(s. Bild) herkommt. Sorry für die Umstände.
Eine Frage noch zu Deinem Post und dem regex "Yield_fc[0|2]_*". Bedeutet Yield_fc0_* und Yield_fc1_* sollten da sein. Oder sollte auch ein Yield_fc2_* da sein?

VG Girgl

ch.eick · 17 März 2025, 20:33:51

ZitatEine Frage noch zu Deinem Post und dem regex "Yield_fc[0|2]_*". Bedeutet Yield_fc0_* und Yield_fc1_* sollten da sein. Oder sollte auch ein Yield_fc2_* da sein?

Sorry, ein Tip Fehler, ich habs im Post korrigiert. Es sind nur 0 und 1, wie im userreadings zu sehen.
Diese beiden readings setzen in den Diagrammen die aktuelle Stunde und sind eine Art Trigger.