- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von jkriegl - 19 Februar 2026, 14:15:57Beobachte Vergleichbares wie Elektron
Plug-A (Trinkwasserstation) schaltet per script Plug-B (Zirkulation) mit toggle_after (bzw. Auto OFF).
Über B beobachte ich in fhem die Schaltungen. Spordisch kommt es vor, dass state und relay nicht mehr aktualisiert werden. Die kürzeste Schaltung ist 45, interval ist 30 Sek. Selbst wenn ein off verpasst wurde, müsste relay später aktualisiert werden.
FHEM und firmware sind aktuell. Ein get <device> status hilft.
Erst seit 1 Woche im Einsatz, davor mqtt-Lösung, soll aber autark (ohne FHEM u. cloud) laufen.
Bin an einer Lösung die Plug-B-Schaltungen (Log) an FHEM zu schicken dran. Ein Shelly.call("HTTP.GET" .. fhem?cmd=setreading ..) habe ich noch nicht getestet.
Via Action bekomme ich nur die Event trigger "Switch toggled on/off"
Jede Hilfe dazu ist willkommen.
Plug-A (Trinkwasserstation) schaltet per script Plug-B (Zirkulation) mit toggle_after (bzw. Auto OFF).
Über B beobachte ich in fhem die Schaltungen. Spordisch kommt es vor, dass state und relay nicht mehr aktualisiert werden. Die kürzeste Schaltung ist 45, interval ist 30 Sek. Selbst wenn ein off verpasst wurde, müsste relay später aktualisiert werden.
FHEM und firmware sind aktuell. Ein get <device> status hilft.
Erst seit 1 Woche im Einsatz, davor mqtt-Lösung, soll aber autark (ohne FHEM u. cloud) laufen.
Bin an einer Lösung die Plug-B-Schaltungen (Log) an FHEM zu schicken dran. Ein Shelly.call("HTTP.GET" .. fhem?cmd=setreading ..) habe ich noch nicht getestet.
Via Action bekomme ich nur die Event trigger "Switch toggled on/off"
Jede Hilfe dazu ist willkommen.
#2
Sonstiges / Aw: Dispatch und readingsBegin...
Letzter Beitrag von JoWiemann - 19 Februar 2026, 13:04:00Hallo,
das Wiki ist nicht die Bibel, sondern eine Handreichung. Vieles hat sich Laufe der Zeit entwickelt, oft das Wiki nicht, das von Benutzern für Benutzer ist. Auch ich pflege als Maintainer nicht das Wiki, sondern nur die commadRef.
In vielen Modulen, auch in meinen, wird das Ändern von Attributen nicht nur validiert, sondern es werden auch Aktionen angestoßen.
Beispiel ist das Setzen des boxUser im FritzBox Modul. Erst mit setzen des Users und vorhandenen Passwort wird im Hash hinterlegt, dass ein Verbindungsversuch zur FritzBox gestartet wird.
Grüße Jörg
das Wiki ist nicht die Bibel, sondern eine Handreichung. Vieles hat sich Laufe der Zeit entwickelt, oft das Wiki nicht, das von Benutzern für Benutzer ist. Auch ich pflege als Maintainer nicht das Wiki, sondern nur die commadRef.
In vielen Modulen, auch in meinen, wird das Ändern von Attributen nicht nur validiert, sondern es werden auch Aktionen angestoßen.
Beispiel ist das Setzen des boxUser im FritzBox Modul. Erst mit setzen des Users und vorhandenen Passwort wird im Hash hinterlegt, dass ein Verbindungsversuch zur FritzBox gestartet wird.
Grüße Jörg
#3
Sonstiges / Aw: Dispatch und readingsBegin...
Letzter Beitrag von Beta-User - 19 Februar 2026, 10:58:23Zitat von: olwaldi am 19 Februar 2026, 07:52:12Aus meiner Sicht (so lese ich das fhem-Wiki bzgl. Modulentwicklung) heißt das aber auch, daß AttrFn nur zum Checken gedacht ist, nicht zum Reagieren.Könnte man als Punkt für dich werten
.Das "Problem": Das Wiki hat auch jemand geschrieben, und dort sein (ziemlich sicher mit Rudi abgestimmtes) Verständnis nachlesbar gemacht. Das bedeutet aber nicht, dass das abschließend und/oder vollständig ist. Na ja, vielleicht liest Rudi mit und wir ergänzen dann im Wiki z.B. sowas:
"Falls im Zusammenhang mit der Änderung von Attributen Aktionen auszulösen sind (z.B. InternalTimer zu setzen oder zu löschen), kann und sollte dies hier erfolgen."
Jedenfalls finde ich es nicht logisch, wenn man erst via AttrFn() nur die Gültigkeit prüft, um dann (ausschließlich zu diesem Zweck) per NotifyFn() zu checken, ob man denn jetzt noch irgendwas veranlassen muss (und dabei nochmal einen (denselben...) Attribut-if-elsif-Bandwurm kreiert).
Letztlich finde ich das auch sehr viel schwieriger zu warten.
Und man riskiert nicht, dass sich andere Module in der Eventverarbeitung weiter vorne einklinken und dann Situationen entstehen, die nicht zueinander passen (sowas ähnliches "durfte" ich mal rund um CUL_HM fixen, das man sicher zu diesem Zeitpunkt bereits als sehr ausgereift ansehen durfte!).
ZitatUnd der "selbstgebaute" ConnectionCheck funktioniert anders als ReadyFn "aktiv" und erkennt Verbindungsabbrüche direkt, was ich gerade vorgestern konkret beobachten konnte, als ich meinen Denon resetten mußte. Dann gibt es minutenlang kein TCP/IP, aber mit ReadyFn blieb der On-Button grün. Genau das hat mich veranlaßt, genauer nach den Checks zu gucken.
Das leitet unmittelbar zu dem hier über:
Zitat von: olwaldi am 19 Februar 2026, 07:52:12Aber ich bin ja auch nicht der Modul-Autor, sondern will mit möglichst wenigen Änderungen ein sehr gutes Modul einen Tick wartbarer machen und ein paar Minibugs fixen.Im Moment bist du vermutlich sehr viel besser im Code eingearbeitet als der Autor bzw. Maintainer. Mir geht es jedenfalls so: Wenn ich ein Modul mal 6 Monate nicht angefasst habe, beginne ich fast von vorne. Von daher habe ich bei fast allen Modulen, die ich in der Pflege habe in der Regel bei der Übernahme jeweils erst mal damit begonnen, alles "für mich" lesbarer zu machen - als Folge "heftiger Schläge" (v.a. seitens RichardCZ) zum vorgefundenen Code...
Es spricht m.E. sehr viel dafür, die Gelegenheit zu nutzen, nicht um ein sehr gutes Modul wesentlich zu verbessern, sondern schlicht, um das vorhandene Modulverständnis in (noch) besser wartbaren Code zu überführen. (Willige) Tester und Mitmacher scheint es ja zu geben, also why not?!?
Ich würde z.B. darauf tippen, dass das mit der ReadyFn() und dem internen Check eigentlich auf ein Logikproblem hinweist, das nicht optimal gelöst ist. Aber so tief bin ich nicht im Code, wie geschrieben: ich habe nicht mehr gemacht, wie 2-3 Mal die svn überflogen...
#4
Solaranlagen / Aw: Modul für Ecoflow-Komponen...
Letzter Beitrag von Neolux - 19 Februar 2026, 10:21:02Nice, gefällt mir. Sollten wir den SourceCode nach Github transferieren?
Sorry, über dne Winter war ich ziemlich untätig, weil meine Solaranlage da auch nicht so viel zu tun hatte.
Sorry, über dne Winter war ich ziemlich untätig, weil meine Solaranlage da auch nicht so viel zu tun hatte.
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 19 Februar 2026, 09:25:13Mach 1 x Folgendes:
get <SFNAMEeinsetzen> pvHistory
Suche in dem Ergebnis 13' - dann sollte sich der Übeltäter zeigen und du kannst ihn anhand Datum - Uhrzeit löschen.
get <SFNAMEeinsetzen> pvHistory
Suche in dem Ergebnis 13' - dann sollte sich der Übeltäter zeigen und du kannst ihn anhand Datum - Uhrzeit löschen.
Code Auswählen
Um eine bestimmte Stunde eines historischer Tages zu löschen:
set <name> reset pvHistory <Tag> <Stunde> (z.B. set <name> reset pvHistory 08 10) #6
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 19 Februar 2026, 09:08:35Das sieht nach einem nichtnumerischen Wert in der PVHistory aus der mit den -'- Zeichen angehängt und darin abgespeichert ist.
Von welcher Version bist du auf die 2.2.0 ?
Von welcher Version bist du auf die 2.2.0 ?
#7
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von Starkstrombastler - 19 Februar 2026, 09:03:22Zitat von: Elektron am 17 Februar 2026, 13:08:09die Zustände eines Shelly1MiniG3 nicht mehr regelmäßig in FHEM aktualisiert werden.Wenn du das Shelly-Modul nutzt: Das regelmäßige Polling der Daten vom Shelly erfolgt gemäß des via Attribut eingestellten Intervalls. Versuchsweise auf einen kleinen Wert, z.B. 30, einstellen.
Wie lautet das Internal "INTERVAL"?
#8
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von MartinD - 19 Februar 2026, 08:57:52 #9
Sonstiges / Aw: Dispatch und readingsBegin...
Letzter Beitrag von olwaldi - 19 Februar 2026, 07:52:12Zitat von: Beta-User am 18 Februar 2026, 16:29:54Das ist für Querschnitts-Module wie MQTT_GENERIC_BRIDGE (oder readingsWatcher etc.) vielleicht korrekt, aber für die Zwecke des hier in Rede stehenden Modul ist es "gefühlter Unsinn".Ich bin auch grundsätzlich Deiner Meinung, eher die vom framework bereitgestellten Funktionen zu nutzen statt eigene zu erstellen. Aber ich bin ja auch nicht der Modul-Autor, sondern will mit möglichst wenigen Änderungen ein sehr gutes Modul einen Tick wartbarer machen und ein paar Minibugs fixen.
...
(Und auch bei dem anderen Thema mit dem ReadyFn() würde ich dafür plädieren, das Problem primär darüber zu lösen, und z.B. den anderen Timer dann darin auch immer wieder zu erneuern bzw. den auf eine längere Periode anzusetzen als die ReadyFn()).
Man sollte immer primär die vom framework bereitgestellten (Spezial-) Funktionen nutzen, statt selbst workarounds einzubauen.
Aus meiner Sicht (so lese ich das fhem-Wiki bzgl. Modulentwicklung) heißt das aber auch, daß AttrFn nur zum Checken gedacht ist, nicht zum Reagieren. Und der "selbstgebaute" ConnectionCheck funktioniert anders als ReadyFn "aktiv" und erkennt Verbindungsabbrüche direkt, was ich gerade vorgestern konkret beobachten konnte, als ich meinen Denon resetten mußte. Dann gibt es minutenlang kein TCP/IP, aber mit ReadyFn blieb der On-Button grün. Genau das hat mich veranlaßt, genauer nach den Checks zu gucken.
Vermutlich werden wir geide weiterhin unterschiedlicher Meinung sein, ist ja voll OK.
Grüßle, Michael
#10
FHEM Code changes / Revision 30872: controls_fhem....
Letzter Beitrag von System - 19 Februar 2026, 07:51:05Revision 30872: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 30872: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 30872: controls_fhem.txt: fhemupdate checkin