ZitatAber mir ist ein Fall eingefallen, wo ich das auch als Reading brauchen würde.Ok, implementiere ich gern.
2025.10.15 11:17:46.584 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.15 11:17:46.585 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 5 %
2025.10.15 11:17:46.585 1: SolCast DEBUG> ChargeOTP Bat 01 - weighted self-consumption: 0 %
2025.10.15 11:17:46.586 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 28416 Wh, remaining: 13924 Wh -> target likely achievable? no
2025.10.15 11:17:46.586 1: SolCast DEBUG> ChargeOTP Bat 01 15/11 - hod: 12 / 00, lr/lc: 1/1, SoC S/E: 14492 / 14584 Wh, Surplus: 135 Wh, OTP: 662 W
2025.10.15 11:17:46.586 1: SolCast DEBUG> ChargeOTP Bat 01 15/12 - hod: 13 / 01, lr/lc: 1/1, SoC S/E: 14584 / 15321 Wh, Surplus: 776 Wh, OTP: 815 W
2025.10.15 11:17:46.587 1: SolCast DEBUG> ChargeOTP Bat 01 15/13 - hod: 14 / 02, lr/lc: 1/1, SoC S/E: 15321 / 16252 Wh, Surplus: 980 Wh, OTP: 1029 W
2025.10.15 11:17:46.587 1: SolCast DEBUG> ChargeOTP Bat 01 15/14 - hod: 15 / 03, lr/lc: 1/1, SoC S/E: 16252 / 18063 Wh, Surplus: 1906 Wh, OTP: 2001 W
2025.10.15 11:17:46.587 1: SolCast DEBUG> ChargeOTP Bat 01 15/15 - hod: 16 / 04, lr/lc: 1/1, SoC S/E: 18063 / 20869 Wh, Surplus: 2954 Wh, OTP: 3102 W
2025.10.15 11:17:46.588 1: SolCast DEBUG> ChargeOTP Bat 01 15/16 - hod: 17 / 05, lr/lc: 1/1, SoC S/E: 20869 / 21408 Wh, Surplus: 567 Wh, OTP: 630 W
2025.10.15 11:17:46.588 1: SolCast DEBUG> ChargeOTP Bat 01 15/17 - hod: 18 / 06, lr/lc: 1/1, SoC S/E: 21408 / 21254 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.15 11:17:46.589 1: SolCast DEBUG> ChargeOTP Bat 01 15/18 - hod: 19 / 07, lr/lc: 1/1, SoC S/E: 21254 / 20654 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.15 11:17:46.589 1: SolCast DEBUG> ChargeOTP Bat 01 15/19 - hod: 20 / 08, lr/lc: 1/1, SoC S/E: 20654 / 20012 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.15 11:17:46.589 1: SolCast DEBUG> ChargeOTP Bat 01 15/20 - hod: 21 / 09, lr/lc: 1/1, SoC S/E: 20012 / 19305 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.15 11:19:22.668 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.15 11:19:22.669 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 5 %
2025.10.15 11:19:22.669 1: SolCast DEBUG> ChargeOTP Bat 01 - weighted self-consumption: 0 %
2025.10.15 11:19:22.670 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 28416 Wh, remaining: 13924 Wh -> target likely achievable? no
2025.10.15 11:19:22.670 1: SolCast DEBUG> ChargeOTP Bat 01 15/11 - hod: 12 / 00, lr/lc: 1/1, SoC S/E: 14492 / 14578 Wh, Surplus: 132 Wh, OTP: 5040 W
2025.10.15 11:19:22.670 1: SolCast DEBUG> ChargeOTP Bat 01 15/12 - hod: 13 / 01, lr/lc: 1/1, SoC S/E: 14578 / 15331 Wh, Surplus: 793 Wh, OTP: 5040 W
2025.10.15 11:19:22.671 1: SolCast DEBUG> ChargeOTP Bat 01 15/13 - hod: 14 / 02, lr/lc: 1/1, SoC S/E: 15331 / 16234 Wh, Surplus: 950 Wh, OTP: 5040 W
2025.10.15 11:19:22.671 1: SolCast DEBUG> ChargeOTP Bat 01 15/14 - hod: 15 / 03, lr/lc: 1/1, SoC S/E: 16234 / 18237 Wh, Surplus: 2108 Wh, OTP: 5040 W
2025.10.15 11:19:22.671 1: SolCast DEBUG> ChargeOTP Bat 01 15/15 - hod: 16 / 04, lr/lc: 1/1, SoC S/E: 18237 / 20742 Wh, Surplus: 2637 Wh, OTP: 2769 W
2025.10.15 11:19:22.672 1: SolCast DEBUG> ChargeOTP Bat 01 15/16 - hod: 17 / 05, lr/lc: 1/1, SoC S/E: 20742 / 20843 Wh, Surplus: 106 Wh, OTP: 630 W
2025.10.15 11:19:22.672 1: SolCast DEBUG> ChargeOTP Bat 01 15/17 - hod: 18 / 06, lr/lc: 1/1, SoC S/E: 20843 / 20456 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.15 11:19:22.672 1: SolCast DEBUG> ChargeOTP Bat 01 15/18 - hod: 19 / 07, lr/lc: 1/1, SoC S/E: 20456 / 19856 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.15 11:19:22.673 1: SolCast DEBUG> ChargeOTP Bat 01 15/19 - hod: 20 / 08, lr/lc: 1/1, SoC S/E: 19856 / 19214 Wh, Surplus: 0 Wh, OTP: 5040 W
Start
│
├─› ist achievable?
│ ├─› ja
│ │ ├─› target *= 1 + otpMargin/100
│ │ └─› strategy == smartPower?
│ │ ├─› ja → target = "Sicherheitsaufschlag linear absenkend"
│ │ └─› nein → weiter
│ └─› nein
│ ├─› target *= (1 + otpMargin/100)^2
│ └─› strategy == smartPower?
│ ├─› ja → $target = pinmax
│ └─› nein → weiter
└─› Ende
2025.10.15 11:57:59 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 11:57:59 4: VitoCal250AH - enter getResourceOnce
2025.10.15 11:57:59 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 11:57:59 4: VitoCal250AH - installation: 2772216
2025.10.15 11:57:59 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 11:58:00 4: VitoCal250AH - getResourceCallback went ok
2025.10.15 12:00:20 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 12:00:20 4: VitoCal250AH - enter getResourceOnce
2025.10.15 12:00:20 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 12:00:20 4: VitoCal250AH - installation: 2772216
2025.10.15 12:00:20 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 12:00:21 4: VitoCal250AH - getResourceCallback went ok
2025.10.15 12:02:41 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 12:02:41 4: VitoCal250AH - enter getResourceOnce
2025.10.15 12:02:41 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 12:02:41 4: VitoCal250AH - installation: 2772216
2025.10.15 12:02:41 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 12:02:42 4: VitoCal250AH - getResourceCallback went ok
2025.10.15 12:05:03 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 12:05:03 4: VitoCal250AH - enter getResourceOnce
2025.10.15 12:05:03 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 12:05:03 4: VitoCal250AH - installation: 2772216
2025.10.15 12:05:03 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 12:05:03 4: VitoCal250AH - getResourceCallback went ok
Zitat von: grossmaggul am 15 Oktober 2025, 11:20:36Achso, by-path sieht für mich unverdächtig aus:Sorry, das hatte ich vermutlich nicht ausreichend erklärt: "by-id" sieht man immer alles, bei uneindeutigen Geräten ist die Liste der Ausgabe von "by-id" kürzer als die der tatsächlich vorhandenen Geräte, siehe den Abschnitt im Wiki vorher.
Zitat von: DS_Starter am 13 Oktober 2025, 18:59:44Ich kann das vollkommen nachvollziehen und habe diese Idee bei mir heute im Laufe des Tages bereits eingebaut und getestet. Den Trigger "target likely achievable"=0 zu nutzen und die Ladeleistung entsprechend hochzuheben ist m.M. nach in Verbindung mit optPower eine sehr gut funktionierende Variante die Volatilität in dieser Jahreszeit abzufangen und für die Batterie zu nutzen.
ls -l /dev/serial/by-path
insgesamt 0
lrwxrwxrwx 1 root root 13 14. Okt 19:38 pci-0000:00:1d.0-usb-0:1:1.0-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 14. Okt 17:51 pci-0000:00:1d.0-usb-0:2:1.0-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 14. Okt 17:49 pci-0000:00:1d.1-usb-0:1:1.0-port0 -> ../../ttyUSB0
Zitat von: grossmaggul am 15 Oktober 2025, 10:16:10Zu a) Was meinst Du mit by-path Infos?https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden#Problemf%C3%A4lle:_by-id
Zitat von: grossmaggul am 15 Oktober 2025, 10:16:10Zu den zigbee UP Schaltern, wie funktioniert das genau, wird der Schalter durch diese Teile ersetzt oder kommen die zusätzlich zu dem vorhandenen Schalter in die Dose? Bei ersterem würde das ja bedeuten, daß man das Licht nicht mehr per mechanischem Schalter betätigen kann. Bei zweiterem hätte ich wahrscheinlich das Problem das Ding noch in der Dose unterzubringen.Die verlinkten Teile sind Unterputz-Varianten, kommen also hinter den vorhandenen Schalter (brauchen aber - wie der HM-Aktor - einen N-Leiter). Die sind beide eher etwas kleiner als die HM-UP-Dinger, von daher sollten sie (mit der "momentary switch"-Option) als 1:1-Ersatz funktionieren.