Hauptmenü

Neueste Beiträge

Seiten 1 2 3 4 5 ... 10
#21
Bastelecke / Aw: ESP RGBWW Controller - Fir...
Letzter Beitrag von pjakobs - 20 September 2026, 20:11:03
einfach und effektiv. Ich hab schon überlegt, das in eine kleine Library zu gießen. Die ganze CrashDump Struktur sind 240 Bytes, die kann man dann auch locker über mqtt verschicken und so prima remote Crash analyse machen.
#22
Sonstiges / Aw: [patch] readingsBulkUpdate...
Letzter Beitrag von rudolfkoenig - 20 September 2026, 20:05:31
@snoonsons:
Danke fuer den Hinweis und die Arbeit.
Ich habe das Uebersetzen der Regexp jetzt in CommandAttr eingebaut, weil es da hingehoert.
Die 44_S7_.* Module aendern .attreocr nicht, sie setzen es nur sinnloserweise nochmal.
Und es bleibt mir ein Raetsel warum der Autor die Funktionalitaet aus fhem.pl in den 4 Modulen dupliziert hat.

@Sidey:
Danke fuer den Hinweis.
computeClientArray uebersetzt jetzt Match nach MatchRe, und Dispatch verwendet MatchRe.
Eine Aenderung in den Modulen sollte damit ueberfluessig werden.

@DS_Starter:
Danke, habs uebernommen.
#23
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 20 September 2026, 19:52:57
Nabend Hadl,

Schön mal wieder von dir zu lesen.  ;) Es gibt zwei Punkte die ich sehe ...

1. Die Debug-Meldung ist irreführend formuliert

Die Zeile
Code Auswählen
SoC Step6 Bat 01 - force charging request: yes (battery charge is below minimum SoC)
Der Code vergleicht dort nicht mit dem lowSoc (5 %), sondern mit dem berechneten Ziel-SoC (target). Da der target in deinem Fall auf 100 % liegt und 83,3 % < 100 % ist, wird die Ladeanforderung korrekt gesetzt. Der Text "below minimum SoC" ist irreführend, das korrigiere ich in der nächsten Version.

2. Der eigentliche Punkt des Verhaltens (m.M. nach): careCycle und stepSoc

Im Log steht:
Code Auswählen
calc care SoC -> docare: 1, care SoC: 100 %, remain days until care SoC: 0, Target: 100 %
remain days until care SoC: 0 bedeutet, dass der Pflegezyklus dauerhaft als überfällig gilt. Dadurch wird docare=1 gesetzt, was den Target-SoC auf 100 % erzwingt — unabhängig von Überschuss oder Tageszeit. Das hält die $soc < $target-Bedingung dauerhaft wahr und zieht in der OTP-Logik zum Stundenende die Ladeleistung ans Maximum, sobald der verbleibende Überschuss der aktuellen Stunde gegen null geht.

Die wahrscheinliche Ursache dafür:
Die Werte stepSoc=5 % und careCycle=25 verletzen eine interne Constraint, die vorschreibt dass stepSoc × careCycle = 100 sein muss (also z.B. 5 × 20 oder 4 × 25). Bei 5 × 25 = 125 ist die Berechnung des Pflegeintervalls nicht mehr stimmig.


Welche Version von SolarForecast ist bei dir aktiv? In der aktuellen Version wird diese Kombination bereits bei der Eingabe geprüft und bei Verletzung der Bedingung abgelehnt.
Korrigiere testweise entweder careCycle auf 20 (bei stepSoc=5) oder stepSoc auf 4 (bei careCycle=25).

Das sollte das Verhalten (vermutlich) normalisieren.

LG,
Heiko
#24
Wallboxen und E-Fahrzeuge / Aw: RenaultZE
Letzter Beitrag von fred_feuerstein - 20 September 2026, 19:40:06
Nochmal zurück zur Location. Meine Alpine A290 meldet eigentlich immer die aktuelle Parkposition als Koordinaten. Was manchmal nicht passt, ist die übermittelte Info ob zuhause (home) oder nicht zuhause (away) mit komischer Entfernungsangabe zu "home".

Deshalb lasse ich mir die Koordinaten über mapbox (dafür hatte ich einen Api-Key) in eine Adresse umwandeln und zeige diese Adresse an. Dann sehe ich direkt wo das Auto steht.

Damit hatte ich bisher eigentlich keine Probleme.


#25
FRITZ!Box / Aw: FritzSmart mit Fritz Labor...
Letzter Beitrag von JoWiemann - 20 September 2026, 19:39:10
Zitat von: roelleke am 20 September 2026, 12:02:17Das List des Fritzbox Devices und das LOG sind im Anhang, da sie wohl zu groß ist um eingefügt zu werden.
Die ersten beiden Zeilen des Logs sind mit verbose 2 und der Rest mit verbose 4.
Ich hoffe die Angaben reichen so aus.

Hallo,

vielen Dank für die Infos. Leider habe ich noch keine wirkliche Idee. Bitte probiere aber mal die Version von hier: https://forum.fhem.de/index.php?msg=1369248 aus. Ist nur ein Versuch.

Grüße Jörg
#26
FRITZ!Box / Aw: FritzSmart ab Modul-Versio...
Letzter Beitrag von JoWiemann - 20 September 2026, 19:36:14
Hallo kabanett,

da bin ich jetzt irritiert. Ich habe in der Version 26.09.15 noch zwei Kleinigkeiten gefunden, die aber nicht direkt das Verhalten bei Dir erklären würden. Trotzdem, spielt doch bitte die angehängte Version einmal ein. Bitte zwingend Fhem neu starten.
Was ich schon mal hatte, war ein ähnliches Verhalten, das sich nur durch einen Neustart des Server auf dem Fhem läuft beheben lies. Hier war es allerdings so, dass einige Fhem Devices ein komisches Verhalten gezeigt haben.

Grüße Jörg
#27
Anfängerfragen / Aw: PERL WARNING: Argument "" ...
Letzter Beitrag von Adimarantis - 20 September 2026, 19:29:30
Danke für den Hinweis.
Da ich mir nicht sicher bin, mit welchem Wert das zu initialisieren ist, hab ich das jetzt eher an der Fehlerzeile gelöst:
Code Auswählen
sub elapsed($$) {
  my ($self, $t)= @_;
  return defined($self->{autoreset}) && $self->{autoreset} ne '' && defined($self->{_t0}) && ($t - $self->{_t0} >= $self->{autoreset});
}
Langsam wird die Liste an Modulen die ich vom Autoupdate ausschliessen muss immer länger. Teilweise hatte ich da versucht Kontakt mit den Autoren aufzunehmem, aber ohne Rückmeldung. Ich spiele mit dem Gedanken meine inzwischen über Monate bis Jahre bewährten Änderungen einfach einzuchecken

Jörg
#28
Sonstiges / Aw: MQTT best current practice
Letzter Beitrag von TomLee - 20 September 2026, 18:49:50
ZitatAls Absicherung in `fhem.pl` würde ein `next if(!$modules{$m}{ParseFn});` in der Dispatch-Schleife genügen, unabhängig davon, wer den Eintrag erzeugt hat.

Könntest du dich bitte damit noch beschäftigen und dazu deine Meinung teilen?





#29
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Hadl - 20 September 2026, 18:38:16
Hallo,
ich nutze die Batteriesteuerung mit OTP schon länger, aber seit ca. 2 Wochen klappt das nichtmehr.
Jeweils zum Ende einer Stunde bekomme ich "target likely achievable? no" und einen sehr geringen "Ratio of remaining surplus", und dadurch eine hohe Ladeleistung.
Zum Beginn der neuen Stunde ist dann wieder Überschuss vorhanden und die Ladeleistung wird wieder beschränkt.
Code Auswählen
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ######################### Start Battery Management DebugLog #########################
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> setup values: lowSoc=5 %, upSoc=20 %, maxSoc=100 %, stepSoc=5 %, careCycle=25
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> pvHistory values: yesterday=19, batymaxsoc=94.9 %, batysetsoc=100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> current values: SoC=83.3 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> today -> PV fc: 53900 Wh, con till sunset: 24 Wh, Surp: 53876 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> tomorrow -> PV fc: 64569 Wh, con till sunset: 2096 Wh, Surp: 62997 Wh (75% con)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> selected energy for charging (the higher positive Surp value from above): 62997 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> expected energy for charging after application Share factor: 62997 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 62997 Wh, need until maxsoc: 1283 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 1, care SoC: 100 %, remain days until care SoC: 0, Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: -720 %, newtarget: -720 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 1, Target: 100 % (no change)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 1, lowSoc: 5 %, upSoc: 20 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: yes (battery charge is below minimum SoC)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - general load termination condition: 0
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier SoC: 50 % / 3840 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier Parameter: set:4444
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Target load and target time: 100 % / 7680 Wh / -
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 1475 Wh -> target likely achievable? no
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 130 Wh / energy requirement to achieve the load target: 8.82 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/10 - hod:11/00, lr/lc:1/1, SocS/E:6397/7680 Wh, SurpH/D:7794/130 Wh, OTP:3000/149 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/11 - hod:12/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/12 - hod:13/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W

...

2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 1475 Wh -> target likely achievable? yes
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 8933 Wh / energy requirement to achieve the load target: 605.75 %
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/11 - hod:12/00, lr/lc:1/1, SocS/E:6397/7680 Wh, SurpH/D:8933/8933 Wh, OTP:1768/1473 W
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/12 - hod:13/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/13 - hod:14/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- WDu darfst diesen Dateianhang nicht ansehen.
Die Ladeleistung OTP wird daher zum Ende der Stunde immer ans Maximum gezogen und es wird "not Acchievable" angezeigt.
Heute war für PV sogar ein sehr guter Tag, es war reichlich Überschuss vorhanden.

An der SF Config habe ich seit einiger Zeit nichtsmehr geändert, woran könnte das liegen?
Auffällig ist das "SurpH/D" für alle Stunden außer der aktuellen immer 0 ist und "con till sunset" sehr gering ist.


Vielen Dank

Hadl
#30
FHEM Code changes / Revision 31668: 14_SD_RSL.pm: ...
Letzter Beitrag von System - 20 September 2026, 18:11:04
Revision 31668: 14_SD_RSL.pm: precompile Match regex, use code references for module ...

14_SD_RSL.pm: precompile Match regex, use code references for module functions, add FHEM::Meta support

Source: Revision 31668: 14_SD_RSL.pm: precompile Match regex, use code references for module ...
Seiten 1 2 3 4 5 ... 10