FHEM Forum forum

Danke. Damit liegt es am Frequenzversatz des Sticks, nicht am Rollladen. FREQ_OFFSET gehört zum Container: Solange er mit -e FREQ_OFFSET=-27 angelegt ist, stellt QCCU den Wert bei jedem Start am Stick ein, auch nach einem Neustart des Containers. Neu angeben muss man ihn nur, wenn der Container neu angelegt wird, also auch beim Aktualisieren. Mehrfach starten zu müssen ist nicht normal; warum FSCTRL0 bei dir wiederholt nicht lesbar war, ist offen, deshalb unten die Bitte um die Logzeile. Ein Folgefehler ist seit 2026.9.14 behoben: ging nach dem Schreiben nur die Rückmeldung des Sticks verloren, addierte der nächste Start den Versatz ein zweites Mal. Aktuell ist 2026.9.15. Zum Aktualisieren: Code Auswählen Erweitern 1. aus docker logs die Zeile mit "nicht lesbar" wörtlich kopieren (mit dem alten Container ist das Log weg) 2. den alten Container entfernen, den Stick kurz abziehen und wieder anstecken (setzt den Versatz auf den Wert der Firmware zurück) 3. den Container mit 2026.9.15 und -e FREQ_OFFSET=-27 neu anlegen Der erste Start dauert länger als sonst, weil QCCU seine Gerätetabellen neu anlegt. Danach sollte auf der Startseite in der Zeile "Frequenzversatz" "FSCTRL0 +17 → -10" stehen. Bitte die Zeile aus 1. hier posten, dazu die Startseitenzeile, falls dort etwas anderes steht.

Hallo Before, die KI hat ggf. Recht. Allerdings stimmt die Begründung nicht ganz. Jedenfalls bin ich intensiv im Code Review bezüglich PID Handhabung. Meine Herausforderung, ich kann den Fehler in meiner MESH und nicht-MESH Umgebung mit 8 Fritz Geräten einfach nicht nachvollziehen. Grüße Jörg

Die Fehler im Modul, die hier thematisiert wurden, habe ich gefixed. Ist alles im neuen DEV Build auf Github enthalten. Das Problem mit dem .clientArray betrifft das Modul selbst nicht. Das müsste in fhem selbst gehärtet werden. Wegen des Vorschlags das Modul zu erweitern hab ich aber inzwischen bedenken, dass direkt in MQTT2_DISCOVERY abzubilden. Das würde dann nämlich immer eine zusätzliche Abhängigkeit neben MQTT2_DEVICE bedeuten. Ich halte es für besser, wenn die Laufzeitintegration in MQTT2_DEVICE erfolgen würde. Dafür würde ich in MQTT2_DEVICE eine Schnittstelle integrieren, z.b.: Code Auswählen Erweitern MQTT2_DEVICE_SetBindings($deviceHash,'mqtt2Discovery',$descriptor); MQTT2_DEVICE_DeleteBindings($deviceHash, 'mqtt2Discovery'); MQTT2_DEVICE_GetBindings($deviceHash, 'mqtt2Discovery'); MQTT2_DEVICE_ValidateBindings($descriptor); mqtt2Discovery wäre in dem Fall nur der Owner, um die von Discovery erzeugten Teile ersetzen oder entfernen zu können. MQTT2_DEVICE führt das anschließend alles intern selbst aus. Das hätte den großen Vorteil, dass ein laufendes FHEM keine Abhängigkeit von MQTT2_DISCOVERY hätte und das das Modul - so wie ursprünglich auch angedacht - nur für das Anlegen der Devices anhand der Discovery Topics zuständig bleibt. Dabei müssten dann manuell gesetzte setList/readingList Regeln im MQTT2_DEVICE Device die generierten Bindings überschreiben können. Die müssten dann aber tatsächlich nicht mehr befüllt werden, da MQTT2_DISCOVERY die oben genannten Schnit

Zitat Damit funktioniert alles und die OTP Steuerung klappt wieder wie gewünscht. Mal sehen was passiert wenn die 20 Tage rum sind. Na das sieht doch schonmal gut aus. Schauen wir mal ...

Hallo Rudi, ich gehe nach und nach alle bei mir im Einsatz befindlichen Module inkl. meiner eigenen hinsichtlich potentieller Speicherleaks durch. Dabei bin ich (bzw. mein Helferlein) im Modul 00_MQTT2_CLIENT.pm fündig geworden und habe die nachfolgenden Korrekturen eingebaut. Bei mir gibt es mehrere FHEM Instanzen, manche zeigen Speicherwachstum über die Zeit, andere nicht. Das Modul ist bei mir getestet und erfolgreich im Einsatz. Der Fund ist nur ein Bausteinchen und es wird noch weitere geben. Wegen der geringen Größe habe ich das Modul mit den beschriebenen Patches gleich hier angehängt. Zirkuläre Referenz in sendHash Fundstelle: MQTT2_CLIENT_doPublish, Zeile 638: Code Auswählen Erweitern push(@{$hash->{sendHash}}, \@_); \@_ ist eine Referenz auf das tatsächliche @_-Array des Funktionsaufrufs. @_ enthält $hash selbst (Signatur: my ($hash, $topic, $val, $retain, $immediate) = @_). Das ergibt: Code Auswählen Erweitern $hash → {sendHash} → [ [\@_] → $hash, ... ] ↑ Element [0] ist $hash! Diese Kette wird in MQTT2_CLIENT_Disco nicht aufgebrochen. Beim Device-Delete sinkt der Refcount von $hash durch delete $defs{$name} um 1 — aber da {sendHash} weiterhin eine Referenz hält, erreicht er nie 0 -> Speicherleck. FIX: Änderung 1 — MQTT2_CLIENT_doPublish (Zeile 638): Code Auswählen Erweitern # alt push(@{$hash->{sendHash}}, \@_); # neu push(@{$hash->{sendHash}}, [$topic, $val, $retain]); Änderung 2 — MQTT2_CLIENT_doinit, connecting == 3 (Zeile 237–238): Die Replay-Schleife greift a

Ich hab nun careCycle=20 gesetzt, das hat jedoch den Zähler zurückgesetzt und ich bekomme nun wieder 20 Tage: Code Auswählen Erweitern 2026.09.21 17:26:13 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 5 %, remain days until care SoC: 19, Target: 100 % Damit funktioniert alles und die OTP Steuerung klappt wieder wie gewünscht. Mal sehen was passiert wenn die 20 Tage rum sind. Aber je besser ich die SOC Steuerung verstehe desto mehr glaube ich das die für meinen Anwendungsfall eher deaktiviert werden sollte. Da mein Akku relativ klein im Vergleich zur PV Leistung ist begrenze ich eher das zu häufige Vollladen. Anfangs mit einem maximalen SOC, jetzt mit einer Maximalen Zellspannung. Damit komm ich quasi nie auf 100% geschätzten SOC, erreiche aber trotzdem den oberen Balancing trigger. Das er 20 Tage am Stück nicht voll wird ist eher unwarscheinlich bei mir, aber wenn mal lange Schnee liegt sicher auch möglich. Aber ja, die Beschreibung was denn die SOC Steuerung tut hab ich auch lange nicht verstanden. Vor allem die Beziehung mit loadTarget hat mich am Anfang glauben lassen das OptimumTargetSoC das Ziel ist bis zu dem geladen werden soll, aber das war falsch es ist das Ziel bis zu dem Entladen werden soll. Nachdem es aber immer auf 5% Stand hab ich es nie verwendet. Das könnte man sicherlich im Wiki nochmal besser abgrenzen und vor allem drauf hinweisen das man dies nicht verwenden sollte wenn man die Maximale Ladung auch begrenzt. Was ich n

Revision 31675: 98:SVG.pm: plotAsPng enhancements by pah (Forum #145492) 98:SVG.pm: plotAsPng enhancements by pah (Forum: #145492) Source: Revision 31675: 98:SVG.pm: plotAsPng enhancements by pah (Forum #145492)

Deine Herleitung ist sicherlich soweit schlüssig. DynLowerSoCBound finde ich allerdings nicht gut bzw. nicht besser, weil: - der Name mit Battery beginnen muß wegen der optischen Sortierung der Readings, d.h. müßte dann Battery_DynLowerSoCBound_XX heißen. - der Anspruch eines berechneten Optimums fehlt - sich mir nicht erschließt welchen Sachverhalt der Anwender aus diesem Namen besser ableiten soll als von Battery_OptimumTargetSoC_XX Er muß sich genauso wie aktuell die Doku dazu durchlesen um den Inhalt zu verstehen, d.h. was wird damit besser? Aber vllt. habe ich auch einen Tunnelblick und würde gerne weitere Meinungen dazu lesen.

Zitat von: DS_Starter am 22 September 2026, 11:45:19 ... Dass Du die Variable in einem SF-externen Code nutzt, habe ich mir schon gedacht, da das Reading sonst sicher ein SpecialReading geworden wäre. (M)ein Vorschlag wäre folgende Umbenennung: Code Auswählen Erweitern Battery_OptimumTargetSoC_XX -> Battery_DynLowerSoCBound_XX Warum Dyn(amic): Weil SF die untere Grenze flexibel den sich änderten Bedingungen anpasst. Ändert sich im Tagesverlauf z.B. die Erzeugugnsprognose für den Folgetag, so passt SF die Grenze an. Lower: Weil es die untere Grenze ist und daher auch als solche ausgewiesen werden sollte. SoC: Weil es um den SoC geht. Bound: Weil es sich um eine Grenze handelt, die vom tatsächlichen SoC nicht unterschritten werden sollte. Was das Search & Replace (OptimumTargetSoC -> DynLowerSoCBound) im Code und Wiki angeht, so kann ich das gerne übernehmen.

Danke fuer die Vorschlaege. Zitat 1. in Zeile 2029 ist by x= ... ein "'" zuviel. Entfernt. Zitat 2.Die beim Zeichnen von Symbolen verwendete sprintf-Funktion wirft eine Warnungsmeldung Die sprintfs ab Zeile 2029 umgebaut. Zitat 3. Die Funktion plotAsPng macht etwas Schwierigkeiten, die in der libRSVG-library begründet liegen. Ich habe die Hilfsfunktionen uebernommen, und kurz getestet. Zitat Und schließlich habe ich noch eine weitere Helperfunktion, Statt diese empfehle ich Code Auswählen Erweitern { WriteFile($file, plotAsPng($plot, undef, undef, $width)) }

Moin, ich schreibe das mal hier hinein, weil die Unterforen Bastelecke/3D-Druck kaum gelesen werden. Und es passt ja auch nur mit dem Homematic-Aktor. ich hatte in meinem Haus beim Einzug die Rollos im Wohnbereich mit Rohrmotoren ausgestattet und damals wegen der zahlreich vorhandenen elektrischen Gurtwickler drei Räume (Arbeitszimmer und das Schlafzimmer) noch mit Gurtmechanik belassen. Nun kommen die in die Jahre und ich baue die verbleibenden drei Rollos auf Rohrmotore um. Allerdings möchte ich derzeit nicht schon wieder renovieren (Schlitze fräsen usw.) und habe das folgendermaßen gemacht: Motor ist ein Nobily PE5 20 bzw. 30. Hier kann man rein elektrisch vom Schalter aus die Endlagen einstellen. Das Kabel ist dafür 5-adrig, deshalb brauchen wir einen Kabelschacht entsprechender Größe. Siehe unten. Der HMIP-BROLL2 kommt in die vorhandene Aufnahme für den alten Gurtwickler. Der ist natürlich zu lang und zu schmal. Deshalb habe ich mit FreeCAD eine Montageplatte konstruiert, in die der BROLL-2 genau passt, die die Gurtwickleröffnung bedeckt oben und unten Anschlüsse für die Kabelschächte besitzt und die man einfach mit den 4 Schrauben für den BROLL festschraubt. Nach oben führt ein halbrunder Kabelschacht mit 1.5cm Radius und nach unten zur Steckdose einer mit 1cm Radius. Gibt es beides bei OBI. Die Gurtwickleröffnung und wird mittig chirurgisch mit einem mittleren bis kleinen Beitel vergrößert. Ergebnis: siehe Foto. Das 3D-Werkstück ist als Makro erstellt, wodurch bei Beda

Hi, ich häng mich hier mal ins Thema mit rein, da ich glaube ich dasselbe Problem mit meinen beiden Repeatern 2400 und 1200 AX (beide Teil eines Meshs, keine Benutzerabfrage beim Weblogin, nur Passwort [das des Meshmasters]) habe. ich hab mal ein log für verbose = 5 angehängt und den Output auch mal mit etwas vorgeplänkel der KI gegeben. Was da rauskam (siehe PDF), kann ich aber nicht mehr bewerten, dafür fehlt mir das Wissen über das Modul, aber vielleicht hilft es ja dem Entwickler weiter und gibt eine Idee? Ich kann auch gerne andere Infos geben