Neueste Beiträge

[Revision 30397: 76_SolarForecast: contrib V1.59.5]

#1

FHEM Code changes / Revision 30397: 76_SolarForeca...

Letzter Beitrag von System - 15 Oktober 2025, 12:21:50

Revision 30397: 76_SolarForecast: contrib V1.59.5

76_SolarForecast: contrib V1.59.5

Source: Revision 30397: 76_SolarForecast: contrib V1.59.5

#2

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 15 Oktober 2025, 12:16:58

@Hadl,

Aber mir ist ein Fall eingefallen, wo ich das auch als Reading brauchen würde.

Ok, implementiere ich gern.
Perspektivisch werde ich dann wahrscheinlich, wie von Parallix vorgeschlagen, die True/False-Readings Battery_ChargeAbort_XX, Battery_ChargeRequest_XX, Battery_ChargeUnrestricted_XX und dem noch hinzukommenden Battery_TargetAchievable_XX ein zusammengefasstes Reading Battery_Status_XX erstellen.

Aber das muß ich erst in Ruhe entwickeln wenn ich mal viel Zeit und Lust zu einer solchen Änderung habe. Es muß ja auch gut erkennbar und auswertbar sein -> Zukunftsmusik.

@all,
ich habe die Idee von Hadl aus #4248 aufgenommen und in die Ladestrategie 'smartPower' integriert.
Dadurch ergibt sich ein linear absenkender Sicherheitsaufschlag sofern das Tagesziel erreichbar ist.
Das Funktionsverhalten ist im Anhang erkennbar.

Der folgende Logauszug verdeutlicht die Unterschiede der Strategien optPower und smartPower.

Strategie = optPower (optimierte Ladeleistung), pinreduced = 600 W, safety 5%:

Code Auswählen Erweitern

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


Strategie = smartPower (zieloptimierte Ladeleistung), pinreduced = 600 W, safety 5%:

Code Auswählen Erweitern


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


Der Pseudocode dafür sieht folgendermaßen aus:

Code Auswählen Erweitern

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


Das Modul im contrib ist upgedated zur Version 1.59.5

#3

Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...

Letzter Beitrag von stefanru - 15 Oktober 2025, 12:10:37

Hi Jochen,

aus deinem Log kann ich sehen dass du wohl 2 Timer aktiv hast.
Das verwundert mich sehr.
Ich habe das Coding des alten Moduls bei dem es vorkommen konnte genau analysiert und umgebaut so dass dies nicht mehr passieren sollte.
Seit dem Umbau kamen auch keine Meldungen mehr dazu hoch bis auf deine jetzt

Ich habe im Coding mal 2 Dinge angepasst um es besser eingrenzen zu können.
Bei dem Fehler Anzahl der möglichen API Calls in überschritten! kommt nun immer der Name des Hashes und die Memoryadresse.

Ich habe auch im GetUpdate das Logging bei Verbose 4 verbessert.
Auch hier kommt nun Name des Hashes und die Memoryadresse.

Ich hänge die angepasste Version hier an.
Bitte lade sie mit "reload 98_vitoconnect.pm" in der commandline.

Setze das Device auf Verbose 4.

Danach solltest du im Log so etwas sehen:

Code Auswählen Erweitern

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

Also bei mir tut alles ein caller mit immer der selben Memoryadresse.
Die calls sind bei mir: 11:57:59, 12:00:20, 12:02:41, 12:05:03
Also alle 140 sek. genau mein intervall.

Kannst du das mal testen und den output posten.

Gruß,
Stefan

#4

Solaranlagen / Aw: [23_BYDBox] - Modul für BY...

Letzter Beitrag von Hadl - 15 Oktober 2025, 12:04:14

Ja, ein balancing sehe ich auch immer mal wieder, auch bei mittleren SoC's. Grob gesagt meistens wenn die Spannungdifferenz zwischen den Zellen > 20mV ist.

Eine SOC Korrektur sehe ich fast immer nur wenn der Akku voll ist. Deutlich öfters wird der SOC nach oben korrigiert, seltener nach unten.
Du darfst diesen Dateianhang nicht ansehen. Du darfst diesen Dateianhang nicht ansehen.

Selten korrigiert sich der SOC auch mal bei leeren Akku (lang ists her), aber bisher ists mir noch nie im "Mittelfeld" aufgefallen.

Viele Grüße

Hadl

#5

Homematic / Aw: CULnano kann Unterputzscha...

Letzter Beitrag von Beta-User - 15 Oktober 2025, 11:33:38

Achso, 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.
Aber wie gesagt: Die Adressierung scheint ok zu sein, und der CUL war als funktionierend bekannt, der Teil sollte (!) eigentlich ok sein.

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Hadl - 15 Oktober 2025, 11:31:37

Ich 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.

Hallo Heiko, ich habs jetzt mal laufenlassen, aber bisher hatte ich trotz vieler Bewölkung immer deutlich mehr PV Ertrag als ich gebraucht hätte, daher sehe ich den Effekt von achievable=0 noch nicht.

Aber mir ist ein Fall eingefallen, wo ich das auch als Reading brauchen würde.
Ich habe in meinem Warmwasserspeicher einen Heizstab indem ich PV Überschuss zum Heizen verwende. Wenn achievable=0 ist würde ich den Heizstab auf jedem Fall aus lassen wollen, dann wird mit der klasischen Heizung (Öl) das Wasser erwärmt fals nötig. Der Heizstab wird mit fhem und einen shelly gesteuert.
Für andere optionale Verbraucher (E-Auto laden,...) würde ich das warscheinlich auch ähnlich machen.

#7

Homematic / Aw: CULnano kann Unterputzscha...

Letzter Beitrag von grossmaggul - 15 Oktober 2025, 11:20:36

O.K., danke, werde ich mal testen und melde mich, wenn ich was rausbekomme.

Vielleicht stelle ich das aber auch auf so ein Zigbee Teil um.

Achso, by-path sieht für mich unverdächtig aus:

Code Auswählen Erweitern

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
Das sind der MAX!- und HM-CUL und der Sonoff Zigbee Stick.

#8

Homematic / Aw: CULnano kann Unterputzscha...

Letzter Beitrag von RalfRog - 15 Oktober 2025, 10:59:01

Hallo
Ich würde bei mir mal versuchen herauszufinden ob der Schalter noch gepairt ist - wenn noch ordentlich sendet (siehe Post vorher).

So weit ich mich erinnere schreibt der CUL (Verbose 4 oder evtl. 5) den Verkehr mit auch wenn eine fremde Zentrale adressiert ist.

Wenn du den Schalter betätigst sollte im Log zu sehen sein mit welcher bzw. ob er mit einer bestimmten Adresse kommuniziert. Vermutlich lässt sich auch erkennen ob es per AES verschlüsselt ist.

Sollte sich mit ein paar Minuten Aufwand erledigen lassen.

Gruß Ralf

#9

TabletUI / Aw: ftui3 swiper Code-Problem

Letzter Beitrag von mr_petz - 15 Oktober 2025, 10:47:50

hi, versuche es mal so:
https://forum.fhem.de/index.php?topic=115259.msg1267949#msg1267949

es ist schon eine weile her daß ich es getestet habe.

#10

Homematic / Aw: CULnano kann Unterputzscha...

Letzter Beitrag von Beta-User - 15 Oktober 2025, 10:47:18

Zu a) Was meinst Du mit by-path Infos?

https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden#Problemf%C3%A4lle:_by-id
In deinem list fand ich die Verbindungsdauer auch eher kurz, die deutete aber nicht auf ein Problem hin und die Kommunikation mit der MCU scheint ja zu klappen. Von daher scheint es tatsächlich eher der Aktor zu sein, der zickt. Wie geschrieben: Das C26-Problem zeigt sich nicht immer gleich auf dieselbe Weise, es _kann_ schon sein, dass der Kondensator noch ausreichend funktioniert, um das eine Relay zu bedienen.
Z.B. bei diversen Rollladenaktoren hatte ich schon den Effekt, dass nur noch eine Fahrtrichtung zuverlässig funktionierte, und es die andere Richtung Glückssache war...
Eine VCCU und/oder irgendwelche auf dummy oder ignore stehenden CUL_HM-Devices gibt es nicht (die sind teilweise schwer zu finden)?

Zu 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.
Es gibt auch unzählige andere ZigBee-Geräte, die in europäische Dosen passen, die mit externem Bedienfeld kommen mal mit Tasterchen, mal mit Touch-Bedienung. Gemeinsam ist denen dann nur, dass sie wohl eher nicht in das "übliche" 55-er Maß passen. So kann man sowas daher nicht (einfach) in die hierzulande gängigen Schalterserien von Jung oder Gira einbauen, sondern muss die ganze "Reihe" tauschen, wenn man mehrere Elemente (Schalter oder Steckdosen usw.) unter- oder nebeneinander hat...
Von daher bin ich darauf ausgewichen, die UP-Varianten auf Vorrat zu beschaffen . Da gibt es auch welche, die keinen N-Leiter brauchen, man muss also beim Bestellen sehr aufpassen, dass man die Beschreibung richtig liest .