76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

DS_Starter

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

grappa24

Zitat von: Parallix am 09 September 2025, 19:44:43
Zitat von: grappa24 am 09 September 2025, 16:00:35...
Ich steuere meine BYD_Battery mit Modbus, konkret u.a. mit "set BYD_Battery BatConfigReserve <limit>"
...
Du steuerst Deinen BYD-Speicher via Modbus? Das das geht, war mir bislang nicht bekannt. Wenn doch: Woher sind die Modbus-Register zu finden? Oder meinst Du, dass Du Deinen Wechselrichter via Modbus anweist z.B. Deinen BYD-Speicher zu laden oder nur bis zu einem bestimmten SOC zu entladen?
Ja, ich steuere meinen BYD-Speicher direkt via Modbus, nicht über meinen Wechselrichter. Viel geht da nicht, aber immerhin so Dinge wie "set BYD BatConfigReserve", "BatConfigMaxChargeWatt", ... (siehe Screenshot).
Die meisten Infos dazu hab ich von stefanru hier aus dem Forum: https://forum.fhem.de/index.php?msg=1283808

Hier mal meine Definition mit den Registern:
define BYD_Battery ModbusAttr 1 60 192.168.178.129:502 TCP
attr BYD_Battery dev-h-combine 125
attr BYD_Battery dev-h-defFormat %.1f
attr BYD_Battery dev-h-defLen 2
attr BYD_Battery dev-h-defPoll 1
attr BYD_Battery dev-h-defUnpack f>
attr BYD_Battery devStateStyle style="text-align:right"
attr BYD_Battery event-min-interval ACActEnergy:7200,ACPower:7200,Battery.*:7200
attr BYD_Battery event-on-change-reading .*Energy:0.1,ACPower:1,DCPowerMPPT.*:1,status,Battery.*harge.*:1,BatteryState
attr BYD_Battery icon measure_battery_100
attr BYD_Battery obj-h40073-reading ACCurrentPhaseA
attr BYD_Battery obj-h40075-reading ACCurrentPhaseB
attr BYD_Battery obj-h40077-reading ACCurrentPhaseC
attr BYD_Battery obj-h40085-reading ACVoltagePhaseA
attr BYD_Battery obj-h40087-reading ACVoltagePhaseB
attr BYD_Battery obj-h40089-reading ACVoltagePhaseC
attr BYD_Battery obj-h40091-format %.0f
attr BYD_Battery obj-h40091-reading ACPower
attr BYD_Battery obj-h40093-reading ACFrequency
attr BYD_Battery obj-h40109-reading CabinetTemperature
attr BYD_Battery obj-h40117-format %s
attr BYD_Battery obj-h40117-len 1
attr BYD_Battery obj-h40117-map 1:off,2:sleeping,3:starting,4:active,5:throttled,6:shutdown,7:fault,8:standby
attr BYD_Battery obj-h40117-reading status
attr BYD_Battery obj-h40117-unpack n
attr BYD_Battery obj-h40196-expr $val / 1000
attr BYD_Battery obj-h40196-format %.2f
attr BYD_Battery obj-h40196-len 4
attr BYD_Battery obj-h40196-reading ACActEnergy
attr BYD_Battery obj-h40196-unpack Q>
attr BYD_Battery obj-h40267-format %d
attr BYD_Battery obj-h40267-group 1-1
attr BYD_Battery obj-h40267-len 1
attr BYD_Battery obj-h40267-reading DCPowerScale
attr BYD_Battery obj-h40267-unpack s>
attr BYD_Battery obj-h40284-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Battery obj-h40284-group 1-2
attr BYD_Battery obj-h40284-len 1
attr BYD_Battery obj-h40284-reading DCPowerMPPT1
attr BYD_Battery obj-h40284-unpack n
attr BYD_Battery obj-h40304-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Battery obj-h40304-group 1-3
attr BYD_Battery obj-h40304-len 1
attr BYD_Battery obj-h40304-reading DCPowerMPPT2
attr BYD_Battery obj-h40304-unpack n
attr BYD_Battery obj-h40324-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Battery obj-h40324-group 1-4
attr BYD_Battery obj-h40324-len 1
attr BYD_Battery obj-h40324-reading BatteryChargeWatt
attr BYD_Battery obj-h40324-unpack n
attr BYD_Battery obj-h40325-expr $val/1000000
attr BYD_Battery obj-h40325-ignoreExpr $val < 100
attr BYD_Battery obj-h40325-len 2
attr BYD_Battery obj-h40325-poll 300
attr BYD_Battery obj-h40325-reading Summe_Ladung
attr BYD_Battery obj-h40325-unpack N
attr BYD_Battery obj-h40344-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr BYD_Battery obj-h40344-group 1-5
attr BYD_Battery obj-h40344-len 1
attr BYD_Battery obj-h40344-reading BatteryDischargeWatt
attr BYD_Battery obj-h40344-unpack n
attr BYD_Battery obj-h40345-expr $val/1000000
attr BYD_Battery obj-h40345-ignoreExpr $val < 100
attr BYD_Battery obj-h40345-len 2
attr BYD_Battery obj-h40345-poll 300
attr BYD_Battery obj-h40345-reading Summe_Entladung
attr BYD_Battery obj-h40345-unpack N
attr BYD_Battery obj-h40355-len 1
attr BYD_Battery obj-h40355-reading BatConfigMaxReferenceWatt
attr BYD_Battery obj-h40355-unpack n
attr BYD_Battery obj-h40358-format %s
attr BYD_Battery obj-h40358-len 1
attr BYD_Battery obj-h40358-map 0:none,1:chargeMax,2:dischrMax,3:bothMax
attr BYD_Battery obj-h40358-reading BatConfigMaxEnabled
attr BYD_Battery obj-h40358-set 1
attr BYD_Battery obj-h40358-unpack n
attr BYD_Battery obj-h40360-expr $val / 100
attr BYD_Battery obj-h40360-format %.0f
attr BYD_Battery obj-h40360-len 1
attr BYD_Battery obj-h40360-poll 60
attr BYD_Battery obj-h40360-reading BatConfigReserve
attr BYD_Battery obj-h40360-set 1
attr BYD_Battery obj-h40360-setexpr $val * 100
attr BYD_Battery obj-h40360-unpack n
attr BYD_Battery obj-h40361-expr $val / 100
attr BYD_Battery obj-h40361-len 1
attr BYD_Battery obj-h40361-reading BatteryChargePercent
attr BYD_Battery obj-h40361-unpack n
attr BYD_Battery obj-h40364-format %s
attr BYD_Battery obj-h40364-len 1
attr BYD_Battery obj-h40364-map 1:off,2:empty,3:discharging,4:charging,5:full,6:holding,7:testing
attr BYD_Battery obj-h40364-reading BatteryState
attr BYD_Battery obj-h40364-unpack n
attr BYD_Battery obj-h40365-expr $val / 10000 * ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Battery obj-h40365-len 1
attr BYD_Battery obj-h40365-max ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Battery obj-h40365-min -ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Battery obj-h40365-reading BatConfigMaxDischargeWatt
attr BYD_Battery obj-h40365-set 1
attr BYD_Battery obj-h40365-setexpr $val / ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1) * 10000
attr BYD_Battery obj-h40365-unpack s>
attr BYD_Battery obj-h40366-expr $val / 10000 * ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Battery obj-h40366-len 1
attr BYD_Battery obj-h40366-max ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Battery obj-h40366-min -ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
attr BYD_Battery obj-h40366-reading BatConfigMaxChargeWatt
attr BYD_Battery obj-h40366-set 1
attr BYD_Battery obj-h40366-setexpr $val / ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1) * 10000
attr BYD_Battery obj-h40366-unpack s>
attr BYD_Battery room Energy,Fronius
attr BYD_Battery stateFormat Status: BatteryState <br/>\
Ladung: BatteryChargePercent % <br/>\
Minimales Ladelimit: BatConfigReserve % <br>\
Akt. Ladeleistung: BatteryChargeWatt W <br/>\
Akt. Entladeleistung: BatteryDischargeWatt W <br/>\
Config Max: BatConfigMaxEnabled<br/>\
Temperatur: CabinetTemperature °C<br/>\

#   DEF        1 60 192.168.178.129:502 TCP
#   DeviceName 192.168.178.129:502
#   EXPECT     idle
#   FD         43
#   FUUID      6569fc0a-f33f-b5ae-e82f-32ddd006ee818e3f
#   IODev      BYD_Battery
#   Interval   60
#   LASTOPEN   1757431402.94954
#   MODBUSID   1
#   MODE       master
#   MODULEVERSION Modbus 4.5.6 - 7.11.2023
#   NAME       BYD_Battery
#   NOTIFYDEV  global
#   NR         706
#   NTFY_ORDER 50-BYD_Battery
#   PARTIAL   
#   PROTOCOL   TCP
#   STATE      Status: discharging <br/>
#Ladung: 43.5 % <br/>
#Minimales Ladelimit: 5 % <br>
#Akt. Ladeleistung: 0.0 W <br/>
#Akt. Entladeleistung: 538.0 W <br/>
#Config Max: none<br/>
#Temperatur: 0.0 °C<br/>
#
#   TCPConn    1
#   TYPE       ModbusAttr
#   devioLoglevel 3
#   devioNoSTATE 1
#   eventCount 2805
#   nextOpenDelay 60
#   DICACHE:
#     3:
#       UNPACK     
#       EXPRS:
#       EXTRAS:
#       FNAMES:
#     6:
#       UNPACK     
#       EXPRS:
#       EXTRAS:
#       FNAMES:
#   PICACHE:
#     h40073:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40075:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40077:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40085:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40087:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40089:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40091:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.0f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40093:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40109:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40117:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %s
#       ignoreExpr
#       map        1:off,2:sleeping,3:starting,4:active,5:throttled,6:shutdown,7:fault,8:standby
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40196:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val / 1000
#       format     %.2f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40267:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %d
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40284:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40304:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40324:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40325:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val/1000000
#       format     %.1f
#       ignoreExpr $val < 100
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40344:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40345:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val/1000000
#       format     %.1f
#       ignoreExpr $val < 100
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40355:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40358:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %s
#       ignoreExpr
#       map        0:none,1:chargeMax,2:dischrMax,3:bothMax
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40360:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val / 100
#       format     %.0f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40361:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val / 100
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40364:
#       bswapRegs 
#       decode     
#       encode     
#       expr       
#       format     %s
#       ignoreExpr
#       map        1:off,2:empty,3:discharging,4:charging,5:full,6:holding,7:testing
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40365:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val / 10000 * ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#     h40366:
#       bswapRegs 
#       decode     
#       encode     
#       expr       $val / 10000 * ReadingsVal($name, 'BatConfigMaxReferenceWatt', 1)
#       format     %.1f
#       ignoreExpr
#       map       
#       mapDefault
#       revRegs   
#       rmapDefault
#   QUEUE:
#   READ:
#     BUFFER     
#   READINGS:
#     2025-09-09 22:52:53   ACActEnergy     17239.97
#     2025-09-09 22:52:51   ACCurrentPhaseA 0.7
#     2025-09-09 22:52:51   ACCurrentPhaseB 0.7
#     2025-09-09 22:52:51   ACCurrentPhaseC 0.7
#     2025-09-09 22:52:51   ACFrequency     50.0
#     2025-09-09 22:52:51   ACPower         503
#     2025-09-09 22:52:51   ACVoltagePhaseA 237.0
#     2025-09-09 22:52:51   ACVoltagePhaseB 236.2
#     2025-09-09 22:52:51   ACVoltagePhaseC 235.2
#     2025-09-09 22:52:53   BatConfigMaxChargeWatt 7680.0
#     2025-09-09 22:52:53   BatConfigMaxDischargeWatt 7680.0
#     2025-09-09 22:52:53   BatConfigMaxEnabled none
#     2025-09-09 22:52:53   BatConfigMaxReferenceWatt 7680.0
#     2025-09-09 22:52:53   BatConfigReserve 5
#     2025-09-09 22:52:53   BatConfigReserveFormatted 5 %
#     2025-01-15 09:39:52   BatteryCharge   4 %
#     2025-09-09 22:52:53   BatteryChargeFormatted 44 %
#     2025-09-09 22:52:53   BatteryChargePercent 43.5
#     2025-09-09 22:52:53   BatteryChargeWatt 0.0
#     2025-01-16 08:14:32   BatteryConfigReserveFormatted 0 %
#     2025-09-09 22:52:53   BatteryDischargeWatt 538.0
#     2025-09-09 22:52:53   BatteryState    discharging
#     2025-09-09 22:52:51   CabinetTemperature 0.0
#     2025-09-09 22:52:53   DCPowerMPPT1    0.8
#     2025-09-09 22:52:53   DCPowerMPPT2    0.6
#     2025-09-09 22:52:53   DCPowerScale    -2
#     2025-09-09 22:52:53   Summe_Entladung 272.4
#     2025-09-09 22:52:53   Summe_Ladung    296.4
#     2025-09-09 17:23:22   state           opened
#     2025-09-09 22:52:51   status          active
#   REMEMBER:
#     lid        1
#     lname      BYD_Battery
#     lrecv      1757451173.67931
#     lsend      1757451173.67567
#   UPDATECACHE:
#     g1:
#       adr        40267
#       combine    g1 len 78 (h40267 len 1 DCPowerScale and h40284 len 1 DCPowerMPPT1 and h40304 len 1 DCPowerMPPT2 and h40324 len 1 BatteryChargeWatt and h40344 len 1 BatteryDischargeWatt) with h40325 len 2 Summe_Ladung and h40345 len 2 Summe_Entladung and h40355 len 1 BatConfigMaxReferenceWatt and h40358 len 1 BatConfigMaxEnabled and h40360 len 1 BatConfigReserve and h40361 len 1 BatteryChargePercent and h40364 len 1 BatteryState and h40365 len 1 BatConfigMaxDischargeWatt and h40366 len 1 BatConfigMaxChargeWatt
#       group      1-1
#       groupInfo  h40267 len 1 DCPowerScale and h40284 len 1 DCPowerMPPT1 and h40304 len 1 DCPowerMPPT2 and h40324 len 1 BatteryChargeWatt and h40344 len 1 BatteryDischargeWatt
#       len        78
#       objCombi   g1
#       reading    DCPowerScale
#       span       100
#       type       h
#     h40073:
#       adr        40073
#       combine    h40073 len 2 ACCurrentPhaseA with h40075 len 2 ACCurrentPhaseB and h40077 len 2 ACCurrentPhaseC and h40085 len 2 ACVoltagePhaseA and h40087 len 2 ACVoltagePhaseB and h40089 len 2 ACVoltagePhaseC and h40091 len 2 ACPower and h40093 len 2 ACFrequency and h40109 len 2 CabinetTemperature and h40117 len 1 status
#       len        2
#       objCombi   h40073
#       reading    ACCurrentPhaseA
#       span       45
#       type       h
#     h40196:
#       adr        40196
#       len        4
#       objCombi   h40196
#       reading    ACActEnergy
#       span       4
#       type       h
#   defptr:
#     BYD_Battery 1
#   gotReadings:
#     BatConfigMaxChargeWatt 7680.0
#     BatConfigMaxDischargeWatt 7680.0
#     BatConfigMaxEnabled none
#     BatConfigMaxReferenceWatt 7680.0
#     BatConfigReserve 5
#     BatteryChargePercent 43.5
#     BatteryChargeWatt 0.0
#     BatteryDischargeWatt 538.0
#     BatteryState discharging
#     DCPowerMPPT1 0.8
#     DCPowerMPPT2 0.6
#     DCPowerScale -2
#     Summe_Entladung 272.4
#     Summe_Ladung 296.4
#   lastRead:
#     h40073     1757451171.88452
#     h40075     1757451171.88558
#     h40077     1757451171.88654
#     h40085     1757451171.88749
#     h40087     1757451171.88844
#     h40089     1757451171.8894
#     h40091     1757451171.8904
#     h40093     1757451171.89137
#     h40109     1757451171.89229
#     h40117     1757451171.89334
#     h40196     1757451173.57303
#     h40267     1757451173.70255
#     h40284     1757451173.70398
#     h40304     1757451173.7055
#     h40324     1757451173.70712
#     h40325     1757451173.68969
#     h40344     1757451173.70869
#     h40345     1757451173.69138
#     h40355     1757451173.69247
#     h40358     1757451173.69351
#     h40360     1757451173.69487
#     h40361     1757451173.69662
#     h40364     1757451173.69807
#     h40365     1757451173.70001
#     h40366     1757451173.70157
#
setstate BYD_Battery Status: discharging <br/>\
Ladung: 43.5 % <br/>\
Minimales Ladelimit: 5 % <br>\
Akt. Ladeleistung: 0.0 W <br/>\
Akt. Entladeleistung: 538.0 W <br/>\
Config Max: none<br/>\
Temperatur: 0.0 °C<br/>\

setstate BYD_Battery 2025-09-09 22:52:53 ACActEnergy 17239.97
setstate BYD_Battery 2025-09-09 22:52:51 ACCurrentPhaseA 0.7
setstate BYD_Battery 2025-09-09 22:52:51 ACCurrentPhaseB 0.7
setstate BYD_Battery 2025-09-09 22:52:51 ACCurrentPhaseC 0.7
setstate BYD_Battery 2025-09-09 22:52:51 ACFrequency 50.0
setstate BYD_Battery 2025-09-09 22:52:51 ACPower 503
setstate BYD_Battery 2025-09-09 22:52:51 ACVoltagePhaseA 237.0
setstate BYD_Battery 2025-09-09 22:52:51 ACVoltagePhaseB 236.2
setstate BYD_Battery 2025-09-09 22:52:51 ACVoltagePhaseC 235.2
setstate BYD_Battery 2025-09-09 22:52:53 BatConfigMaxChargeWatt 7680.0
setstate BYD_Battery 2025-09-09 22:52:53 BatConfigMaxDischargeWatt 7680.0
setstate BYD_Battery 2025-09-09 22:52:53 BatConfigMaxEnabled none
setstate BYD_Battery 2025-09-09 22:52:53 BatConfigMaxReferenceWatt 7680.0
setstate BYD_Battery 2025-09-09 22:52:53 BatConfigReserve 5
setstate BYD_Battery 2025-09-09 22:52:53 BatConfigReserveFormatted 5 %
setstate BYD_Battery 2025-01-15 09:39:52 BatteryCharge 4 %
setstate BYD_Battery 2025-09-09 22:52:53 BatteryChargeFormatted 44 %
setstate BYD_Battery 2025-09-09 22:52:53 BatteryChargePercent 43.5
setstate BYD_Battery 2025-09-09 22:52:53 BatteryChargeWatt 0.0
setstate BYD_Battery 2025-01-16 08:14:32 BatteryConfigReserveFormatted 0 %
setstate BYD_Battery 2025-09-09 22:52:53 BatteryDischargeWatt 538.0
setstate BYD_Battery 2025-09-09 22:52:53 BatteryState discharging
setstate BYD_Battery 2025-09-09 22:52:51 CabinetTemperature 0.0
setstate BYD_Battery 2025-09-09 22:52:53 DCPowerMPPT1 0.8
setstate BYD_Battery 2025-09-09 22:52:53 DCPowerMPPT2 0.6
setstate BYD_Battery 2025-09-09 22:52:53 DCPowerScale -2
setstate BYD_Battery 2025-09-09 22:52:53 Summe_Entladung 272.4
setstate BYD_Battery 2025-09-09 22:52:53 Summe_Ladung 296.4
setstate BYD_Battery 2025-09-09 17:23:22 state opened
setstate BYD_Battery 2025-09-09 22:52:51 status active

Ich meine, ich hätte auch schon mal eine Doku von BYD mit den Registern gesehen, find ich grad nicht mehr.

Aber schau es dir mal an, wenn du Fragen hast, gerne.
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

Hadl

Zitat von: DS_Starter am 08 September 2025, 07:46:59Sollte jedoch der Wunsch bestehen, für jede Steuerung einen separaten Zuschlag verwenden zu wollen (oder das günstig erscheint), kann ich safetyMargin problemlos noch erweitern, z.B. so safetyMargin=50:30.
Ja, hier! Vielen Dank!

Zitat von: grappa24 am 09 September 2025, 23:01:05, ich steuere meinen BYD-Speicher direkt via Modbus, nicht über meinen Wechselrichter. Viel geht da nicht, aber immerhin so Dinge wie "set BYD BatConfigReserve", "BatConfigMaxChargeWatt", ... (siehe Screenshot).
Die meisten Infos dazu hab ich von stefanru hier aus dem Forum: https://forum.fhem.de/index.php?msg=1283808

Hallo Grappa,
ja, so mache ich das auch, aber streng genommen kommunizierst du hier nur mit dem Fronius Gen24 und weist diesen an was er mit der Batterie tun soll.
Werte wie ACCurrentPhaseA sind reine Wechselrichterwerte, die garnichts mit der BYD Batterie zu tun haben.
Die Register von Fronius kann man von deren Homepage runterladen.

Ich bin aber ehrlichgesagt auch etwas unschlüsssig mit den vielen Werten von SF, denn im Endeffekt geb ich ja dem Wechselrichter nur eine maximale Ladeleistung vor.
Alles weitere macht der Wechselrichter ja weiterhin selbstständig.

Bei mir macht das aktuell ein DOIF, in dem ich
- Battery_ChargeUnrestricted_01
- Battery_ChargeRequest_01
- Fronius_Symo1:Storage_0_Controller_StateOfCharge_Relative < Battery_OptimumTargetSoC_01
dazu verwende ne hohe Ladeleistung zu erlauben.
Wenn keins davon wahr ist dann schau ich auf Battery_ChargeOptTargetPower_01 und setze diesen Wert als maximale Ladeleistung.

Was komisch ist dass ich z.B. Battery_ChargeUnrestricted_01 gesehen habe während Battery_ChargeOptTargetPower_01 relativ niedrig war. Das macht für mich keinen Sinn. Was sollte man in diesem Fall tun?

Parallix

#3933
Heute früh (7:10 MESZ) sehe ich bei ausreichend prognostiziertem PV-Überschuss ab 8:00 MESZ bei mir:

Battery_ChargeOptTargetPower_0[12] = 15 W
Current_BatCharge_0[12] = 50 %
Battery_OptimumTargetSoC_0[12] = 40 %

und zwar bei einem System mit ctrlBatSocManagement0[12] (hier kein Unterstrich, weil Attr.-Name sonst zu lang? Könnte ja auch ctrlBatSocMgmt_[01] heißen) wie folgt:

lowSoc=3
upSoC=95
maxSoC=100
careCycle=14
loadAbort=99:686:95
safetyMargin=20

Den o.g. Wert für Battery_ChargeOptTargetPower_0[12]  verstehe ich nicht, da mit 15 W keine sinnvolle Ladung bis Sonnenuntergang (19:58 MESZ) erfolgen kann.

PS: Auch ist mir noch nicht klar, warum mein Battery_OptimumTargetSoC_0[12] = 40 % (also unterhalb des aktuellen SOC) es sei denn, es ist ein unterer SoC. Dann aber wäre der Name für das Reading nicht wirklich gut gewählt.

Edit: Jetzt (um 8:05 MESZ) ist Battery_ChargeOptTargetPower_0[12] = 250 W und für mich nachvollziehbar gesetzt. Gibt es eigentlich auch ein specialReading in dem die Anzahl der prognostizierten Stunden steht, in denen  wenigstens Battery_ChargeOptTargetPower_XX an PV-Überschuss zur Verfügung steht?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Moin,

@Hadl

ZitatWas komisch ist dass ich z.B. Battery_ChargeUnrestricted_01 gesehen habe während Battery_ChargeOptTargetPower_01 relativ niedrig war. Das macht für mich keinen Sinn. Was sollte man in diesem Fall tun?

Das ist zunächst kein Widerspruch. Battery_ChargeUnrestricted_01=1 bedeutet die Bat sollte "frei" geladen werden und nicht nur wenn plantControl->feedinPowerLimit überschritten ist. Mit welcher Leistung ist dir überlassen oder du folgst den optimierten Vorschlag in Reading Battery_ChargeOptTargetPower_XX. Ich habe es im
Wiki auch gleich nochmal angepasst.

Weiterhin verfolgen diese beiden Readings jeweils eine andere Ladestrategie bzw. haben einen anderen Fokus bei der Ladungssteuerung. Man kann sich auch nur auf die Werte des einen oder des anderen Readings bei der Steuerung des Akkus stützen. Die Steuerung über Battery_ChargeUnrestricted_XX habe ich wie weiter vorn schon geschrieben mit Sicherheit über ein Jahr in Verwendung und würde sie als ausgereift ansehen. Die andere Logik ist frisch implementiert und wir werden sehen wie gut sich damit das Ziel erreichen lässt.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#3935
@Parallix,

Zitathier kein Unterstrich, weil Attr.-Name sonst zu lang? Könnte ja auch ctrlBatSocMgmt_[01] heißen
Das ist einfach der Historie geschuldet. Vllt. stelle ich diese Attrnamen später (automatisch) um. Möchte die User nicht mit Änderungen überfordern was ja immer mal wieder zu lesen ist weil User die Updates verständlicherweise nicht so zügig einspielen wie ich es mir wünschen würde.

ZitatDen o.g. Wert für Battery_ChargeOptTargetPower_0[12]  verstehe ich nicht, da mit 15 W keine sinnvolle Ladung bis Sonnenuntergang (19:58 MESZ) erfolgen kann.
Ja das stimmt. Dieser Wert ist allerdings nicht fix, sondern ändert sich dynamisch. Dennoch ist es wahrscheinlich durch die Begrenzung des kalkulierten PV-Überschusses bedingt. Vllt. muß ich da etwas anpassen. Setze mal ctrlDebug=batteryManagement und wir schauen auf das Log.

ZitatPS: Auch ist mir noch nicht klar, warum mein Battery_OptimumTargetSoC_0[12] = 40 % (also unterhalb des aktuellen SOC) es sei denn, es ist ein unterer SoC. Dann aber wäre der Name für das Reading nicht wirklich gut gewählt.
Ja, deine Vermutung ist richtig. Es müsste eigentlich "unterer optimierter Ziel-SoC" heißen, also Battery_OptimumLowTargetSoC_0. Gegen einen höheren aktuell vorhandenen SoC hat normalerweise niemand etwas einzuwenden. Naja, auch hier wieder das Thema solcher Änderungen. Es gibt ja bereits ein Reading welches ich bereits lang angekündigt habe zu ändern. Bei dem könnte ich es auch machen. Mal sehen.

LG,
Heiko

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

ZitatEdit: Jetzt (um 8:05 MESZ) ist Battery_ChargeOptTargetPower_0[12] = 250 W und für mich nachvollziehbar gesetzt. Gibt es eigentlich auch ein specialReading in dem die Anzahl der prognostizierten Stunden steht, in denen  wenigstens Battery_ChargeOptTargetPower_XX an PV-Überschuss zur Verfügung steht?
Nein, es gibt nur SunHours_Remain, also die Reststunden bis Sonnenuntergang.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

Zitat von: DS_Starter am 10 September 2025, 08:22:30...
ZitatDen o.g. Wert für Battery_ChargeOptTargetPower_0[12]  verstehe ich nicht, da mit 15 W keine sinnvolle Ladung bis Sonnenuntergang (19:58 MESZ) erfolgen kann.
Ja das stimmt. Dieser Wert ist allerdings nicht fix, sondern ändert sich dynamisch. Dennoch ist es wahrscheinlich durch die Begrenzung des kalkulierten PV-Überschusses bedingt. Vllt. muß ich da etwas anpassen. Setze mal ctrlDebug=batteryManagement und wir schauen auf das Log.
...

Danke für das Angebot! ctrlDebug=batteryManagement ist jetzt gesetzt. Das Log kommt dann später.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

Parallix

Zitat von: DS_Starter am 10 September 2025, 08:45:19
Zitat...
Gibt es eigentlich auch ein specialReading in dem die Anzahl der prognostizierten Stunden steht, in denen  wenigstens Battery_ChargeOptTargetPower_XX an PV-Überschuss zur Verfügung steht?
Nein, es gibt nur SunHours_Remain, also die Reststunden bis Sonnenuntergang.

Schade, denn es würde einiges leichter verständlich machen.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Im Debuglog ist dann nur der Block mit

 DEBUG> Bat XX ChargeOTP -....

relevant.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

#3940
Zitat von: DS_Starter am 10 September 2025, 08:58:42Im Debuglog ist dann nur der Block mit

 DEBUG> Bat XX ChargeOTP -....

relevant.

Soeben extrahiert. Datei anbei!
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

grappa24

Zitat von: Hadl am 10 September 2025, 02:13:17Hallo Grappa,
ja, so mache ich das auch, aber streng genommen kommunizierst du hier nur mit dem Fronius Gen24 und weist diesen an was er mit der Batterie tun soll.
ihr habt natürlich recht, meine IP-Adresse für den Modbus ist ja auch die des Symo GEN24  :(
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

@Parallix,

das Debuglog passt soweit wie ich sehe.
Allerdings macht mir eine Sache Kopfzerbrechen. Mal nur für eine Batterie betrachtet sieht man exakt den gleichen Überschuß zu verschiedenen Tagesstunden:

2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 09, Start SoC: - Wh, Surplus: 0 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 10, Start SoC: 3225 Wh, Surplus: 1063 Wh, OptTargetPower: 384 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 11, Start SoC: 3609 Wh, Surplus: 3500 Wh, OptTargetPower: 3500 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 12, Start SoC: 7109 Wh, Surplus: 3500 Wh, OptTargetPower: 685 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 13, Start SoC: 7680 Wh, Surplus: 3054 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 14, Start SoC: 7680 Wh, Surplus: 2752 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 7930 Wh, Surplus: 3067 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 7680 Wh, Surplus: 2527 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 7930 Wh, Surplus: 3500 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 7680 Wh, Surplus: 3068 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: 7680 Wh, Surplus: 705 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh, OptTargetPower: 250 W, safety: 20 %
2025.09.10 08:43:42 1: SF DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh, OptTargetPower: 250 W, safety: 20 %

Das ist für die Logik etwas problematisch, da die Kalkulation auf einer aufsteigender Sortierung von Surplus ausgeht und dieser Wert äußerst selten exakt gleich sein kann.
Vermutlich liegt die Ursache im Code und ich habe auch eine Idee. Zur Kontrolle ... kann es sein, dass "pinmax" für diese Bat auf 3500 W gesetzt ist?

Nur zum Vergleich ein Debug Ausschnitt von mir:

2025.09.10 08:11:17.022 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 09, Start SoC: 20932 Wh, Surplus: 209 Wh, OptTargetPower: 170 W, safety: 20 %
2025.09.10 08:11:17.023 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 10, Start SoC: 21102 Wh, Surplus: 834 Wh, OptTargetPower: 717 W, safety: 20 %
2025.09.10 08:11:17.023 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 11, Start SoC: 21819 Wh, Surplus: 3193 Wh, OptTargetPower: 3193 W, safety: 20 %
2025.09.10 08:11:17.023 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 12, Start SoC: 26104 Wh, Surplus: 1719 Wh, OptTargetPower: 900 W, safety: 20 %
2025.09.10 08:11:17.024 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 13, Start SoC: 27004 Wh, Surplus: 2651 Wh, OptTargetPower: 1696 W, safety: 20 %
2025.09.10 08:11:17.024 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 14, Start SoC: 28416 Wh, Surplus: 2114 Wh, OptTargetPower: 1000 W, safety: 20 %
2025.09.10 08:11:17.024 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 28416 Wh, Surplus: 410 Wh, OptTargetPower: 1000 W, safety: 20 %
2025.09.10 08:11:17.025 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 29416 Wh, Surplus: 1012 Wh, OptTargetPower: 1000 W, safety: 20 %
2025.09.10 08:11:17.025 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 28416 Wh, Surplus: 114 Wh, OptTargetPower: 1000 W, safety: 20 %
2025.09.10 08:11:17.025 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: - Wh, Surplus: 0 Wh, OptTargetPower: 1000 W, safety: 20 %


Man sieht hier stets unterschiedliche Surplus, aber die Ursache ist, wie gesagt vermutlich in meinem Code zu suchen.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

#3943
Zitat von: DS_Starter am 10 September 2025, 10:24:33@Parallix,

das Debuglog passt soweit wie ich sehe.

Also liegt der unplausible niedrige Empfehlungswert von 15 W für die Ladung an etwas anderem. Aber woran?

Zitat von: DS_Starter am 10 September 2025, 10:24:33Allerdings macht mir eine Sache Kopfzerbrechen. Mal nur für eine Batterie betrachtet sieht man exakt den gleichen Überschuß zu verschiedenen Tagesstunden:
...
Das ist für die Logik etwas problematisch, da die Kalkulation auf einer aufsteigender Sortierung von Surplus ausgeht und dieser Wert äußerst selten exakt gleich sein kann.
Vermutlich liegt die Ursache im Code und ich habe auch eine Idee. Zur Kontrolle ... kann es sein, dass "pinmax" für diese Bat auf 3500 W gesetzt ist?

Da es mir ja darum geht, meinen Speicher keinem unnötigen Stress auszusetzen, habe ich die "maximal mögliche Ladeleistung", die SF pro Speicher berücksichtigen soll, auf 3500 W gesetzt, also ca. 0,5 C. Die Limitierung auf einen Wert unterhalb der PV-Leistung und tatsächlichen Speicherleistung halte ich nicht für besonders untypisch, insb. wenn man in Richtung steuerbare Verbrauchseinrichtungen denkt, oder?

Wenn nur nach aufsteigendem Überschuss sortiert wird, dann kann es in der Tat bei zwei gleichen Überschüssen zu einem Problem kommen, wenn Du Dir zur Berechnung der Ladeempfehlung immer den ersten Eintrag schnappst. Wenn Du Dir aber den Eintrag mit größter (Rest-)Stundenzahl wählst, dann sollte vorgenanntes Problem nicht mehr existieren, richtig?

Übrigens: Den letzten Eintrag in Deinem Log
2025.09.10 08:11:17.025 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: - Wh, Surplus: 0 Wh, OptTargetPower: 1000 W, safety: 20 %
finde ich seltsam: Ein Ladeempfehlung von 1000 W (wahrscheinlich der Wert für Dein pinreduced) bei einem Überschuss von 0 Wh. Wenn Du mit surplus = 0 W das Tabellenende markierst, dann löst sich das Rätsel.

Edit: Nach einem etwas intensiveren Betrachten der Logdaten/Tabellen kommt mir die Idee, dass die berücksichtigte safetyMargin während eines Tages vom Ursprungswert ausgehend dynamisch reduziert werden könnte, wenn genügend Tabelleneinträge mit höheren Ladeleistungen existieren. Oder anders ausgedrückt: Ein in SF ermittelter safetyFactor (in Hinblick auf die SOC-Zielerreichung) könnte aus der Anzahl alternativer (höherer) Ladeleistungen und der für diese ermittelten Ladezeit abgeleitet werden.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

ZitatDa es mir ja darum geht, meinen Speicher keinem unnötigen Stress auszusetzen, habe ich die "maximal mögliche Ladeleistung", die SF pro Speicher berücksichtigen soll, auf 3500 W gesetzt, also ca. 0,5 C. Die Limitierung auf einen Wert unterhalb der PV-Leistung und tatsächlichen Speicherleistung halte ich nicht für besonders untypisch, insb. wenn man in Richtung steuerbare Verbrauchseinrichtungen denkt, oder?
Passt schon. ich wollte nur verifizieren woher die wiederholte exakte Surplus von 3500 W kommt. Jetzt weiß ich was ich im Code berichtigen muß.

ZitatWenn nur nach aufsteigendem Überschuss sortiert wird, dann kann es in der Tat bei zwei gleichen Überschüssen zu einem Problem kommen, wenn Du Dir zur Berechnung der Ladeempfehlung immer den ersten Eintrag schnappst. Wenn Du Dir aber den Eintrag mit größter (Rest-)Stundenzahl wählst, dann sollte vorgenanntes Problem nicht mehr existieren, richtig?
Ja, allerdings ist das ein unnötiger Performancefresser, weil ich immer! den Nachfolger mit dem Vorgänger vergleichen müßte. Aber wenn ich obiges Problem beseitigt habe, kann eine Surplus Übereinstimmung nur in äußerst seltenen Fällen auftreten. Damit kann man leben.

ZitatÜbrigens: Den letzten Eintrag in Deinem Log
Code Auswählen
2025.09.10 08:11:17.025 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: - Wh, Surplus: 0 Wh, OptTargetPower: 1000 W, safety: 20 %
finde ich seltsam: Ein Ladeempfehlung von 1000 W (wahrscheinlich der Wert für Dein pinreduced) bei einem Überschuss von 0 Wh. Wenn Du mit surplus = 0 W das Tabellenende markierst, dann löst sich das Rätsel.
Wenn Surplus 0 ist, wird die Bat nicht aus PV geladen, ebensowenig wenn SOC=100%. Deswegen Rückfall auf pinreduced. Das bewirkt ja auch, dass die Bat im Falle der Netz-Zwangsladung (kann eigentlich nur bei Surplus=0 auftreten) lediglich mit pinreduced geladen wird -> works as designed.

ZitatNach einem etwas intensiveren Betrachten der Logdaten/Tabellen kommt mir die Idee, dass die berücksichtigte safetyMargin während eines Tages vom Ursprungswert ausgehend dynamisch reduziert werden könnte, wenn genügend Tabelleneinträge mit höheren Ladeleistungen existieren.
Etwas ähnliches ist bereits jetzt implementiert. Der Ladebedarf (Wh) für die Bat ändert sich ständig. Die safetyMargin wird nicht fix auf den ursprünglichen Ladebedarf angewendet, sondern dynamisch auf den jeweilig vorhandenen Ladebedarf.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter