- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Sonstige Systeme / Aw: Shelly 1 mini Gen3 in Verb...
Letzter Beitrag von edouard - 02 März 2026, 05:27:08Zitat von: WolfS am 27 Oktober 2024, 21:55:31Die neue Version des Shelly-Moduls 36_Shelly.pm erzeugt in Verbindung mit einem Shelly 1 mini Gen3 einen Fehler mit dem Hinweis: "bad timer argument"I've also encountered the "bad timer argument" error after updating the Shelly module. Rolling back to the March 2024 version fixed it for me too. It's like my smart home automation suddenly decided to stop baking cookies! Anyone else experiencing similar issues with their Shelly 1 mini Gen3? Feels like I'm playing a real-life, buggy version of Cookie Clicker, waiting for the automation to click back into place. Any advice is appreciated!
Die Version vom März 2024 funktioniert ohne Probleme. Cookie Clicker
Hat sonst noch jemand dieses Problem und kann mir evtl. Hilfestellung geben?
Danke!
#2
Sonstiges / Aw: Neue Versionen und Support...
Letzter Beitrag von freetz - 02 März 2026, 03:26:32Und die Lösung kommt nun auch schon hinterher: Das DOIF muss mit einer Sekunde verzögerung (Attribut: "wait" mit je einer Sekunde pro Zweig, also in meinem Fall: "1:1:1:1") ausgeführt werden, dann ist das Problem gelöst 
...
... #3
Sonstiges / Aw: Neue Versionen und Support...
Letzter Beitrag von freetz - 02 März 2026, 03:20:13Ergänzung:
Ich habe ein DOIF, das auf ModbusAttr Events reagiert, und das dann wiederum per "set" einen Parameter über ModbusAttr ändert (Beispiel: Wenn PV-Produktion sinkt unter einen bestimmten Wert -> wechsle von Export auf Eigenverbrauch). Sobald das passiert, kommt der Timeout oben. Aber wie gesagt, es wird sowohl der korrekte Wert abgerufen, als auch das Set korrekt ausgeführt...
Ich habe ein DOIF, das auf ModbusAttr Events reagiert, und das dann wiederum per "set" einen Parameter über ModbusAttr ändert (Beispiel: Wenn PV-Produktion sinkt unter einen bestimmten Wert -> wechsle von Export auf Eigenverbrauch). Sobald das passiert, kommt der Timeout oben. Aber wie gesagt, es wird sowohl der korrekte Wert abgerufen, als auch das Set korrekt ausgeführt...
#4
Sonstiges / Seltsame Timeout-Probleme bei ...
Letzter Beitrag von freetz - 02 März 2026, 01:58:38Hallo zusammen,
ich habe versucht die Suche zu bemühen, aber wenn ich "Timeout" oben in der Suche für "Dieses Thema" eingebe, kommt nichts, obwohl Google mich (auch) auf diesen Thread gestoßen hat. Das nur zur Entschuldigung, falls ich etwas übersehen haben sollte.
Ich habe meinen SolarEdge Wechselrichter über ModbusAttr an FHEM angebunden. Das klappt grundsätzlich prima, es tauchen jedoch mit unterschiedlich langen (eher: kurzen) Unterbrechungen diese Timeout-Fehler auf:
Ich frage mich, warum/woher dann dieser Timeout kommt?
Ich polle 5 Holding-Register alle 20 Sekunden, das sollte doch nicht zu viel sein?
Weil die Werte in der Anzeige im Modul wie gesagt problemlos aktualisiert werden, habe ich mich bisher nicht darum gekümmert, aber da das die Logfiles doch sehr start füllt, wollte ich fragen, ob das Problem bekannt ist, und wenn ja, wie ich es lösen kann.
Vielen Dank auf jeden Fall schon mal!
F.
ich habe versucht die Suche zu bemühen, aber wenn ich "Timeout" oben in der Suche für "Dieses Thema" eingebe, kommt nichts, obwohl Google mich (auch) auf diesen Thread gestoßen hat. Das nur zur Entschuldigung, falls ich etwas übersehen haben sollte.
Ich habe meinen SolarEdge Wechselrichter über ModbusAttr an FHEM angebunden. Das klappt grundsätzlich prima, es tauchen jedoch mit unterschiedlich langen (eher: kurzen) Unterbrechungen diese Timeout-Fehler auf:
Code Auswählen
2026.03.02 01:40:55 3: BydBattery: Timeout in Readanswer, current frame / read buffer: 00d00000000d01030a2653cd6720a53848fffc, id 1, fCode 3, tid 208,
request: id 1, read fc 3 h40206, len 5, tid 208, master device BydBattery, reading Meter_Power (getUpdate for Meter_Power len 5), queued 2.30 secs ago, sent 2.05 secs ago,
response: id 1, fc 3, h40206, len 5, values 2653cd6720a53848fffc
2026.03.02 01:41:18 3: BydBattery: Timeout in Readanswer, current frame / read buffer: 00080000000d01030a12d8e9319d118c97fffd, id 1, fCode 3, tid 8,
request: id 1, read fc 3 h40206, len 5, tid 8, master device BydBattery, reading Meter_Power (getUpdate for Meter_Power len 5), queued 5.30 secs ago, sent 5.05 secs ago,
response: id 1, fc 3, h40206, len 5, values 12d8e9319d118c97fffdBeim ersten Abruf war dev-timing-timeout noch auf 2, beim zweiten Abruf auf 5. Das Seltsame ist, dass der Timeout zwar kurz nach dem Ende des Timeout-Intervalls kommt, aber in beiden Fällen der read buffer mit einem gültigen Wert zurück kommt, der dann auch einen gültigen "values" Wert erzeugt und dann auch im Modul der korrekte Wert angezeigt wird.Ich frage mich, warum/woher dann dieser Timeout kommt?
Ich polle 5 Holding-Register alle 20 Sekunden, das sollte doch nicht zu viel sein?
Weil die Werte in der Anzeige im Modul wie gesagt problemlos aktualisiert werden, habe ich mich bisher nicht darum gekümmert, aber da das die Logfiles doch sehr start füllt, wollte ich fragen, ob das Problem bekannt ist, und wenn ja, wie ich es lösen kann.
Vielen Dank auf jeden Fall schon mal!
F.
#5
FRITZ!Box / Aw: AVM SmartMeter und Monatsw...
Letzter Beitrag von Marko1976 - 02 März 2026, 01:00:26Im Moment versuche ich noch mich mit dem statistics-Modul auseinander zusetzen.
Vielleicht mache ich ja auch noch was in der Bedienung falsch.
Wenn ich die Standardberechnungen ignorieren lassen und für einzelne Readings spezielle Statistiken erstellen lassen will funktioniert das nämlich noch nicht.
Jedenfalls werden abseits der Standardreadings keine extra angelegten Readings ausgewertet.
Habe es mit verschiedenen Attributen im Statistics-Device probiert. Hier das List:
Ich möchte eigentlich erstmal nur einen Durchschnitt für den aktuellen Verbrauch (power_round) für verschiedene Zeitperioden und für den Gesamtverbrauch das Delta für verschiedene Zeitabstände.
Vielleicht mache ich ja auch noch was in der Bedienung falsch.
Wenn ich die Standardberechnungen ignorieren lassen und für einzelne Readings spezielle Statistiken erstellen lassen will funktioniert das nämlich noch nicht.
Jedenfalls werden abseits der Standardreadings keine extra angelegten Readings ausgewertet.
Habe es mit verschiedenen Attributen im Statistics-Device probiert. Hier das List:
Code Auswählen
Internals:
CFGFN
DEF FBDECT_Fritzbox_Actors_15282_0919488_1
DEV_REGEXP FBDECT_Fritzbox_Actors_15282_0919488_1
FUUID 69a1cf31-f33f-7706-a527-c7e15bc12c3802f6
NAME Statistik_SmartMeter
NOTIFYDEV global,FBDECT_Fritzbox_Actors_15282_0919488_1
NR 52474
NTFY_ORDER 10-Statistik_SmartMeter
PREFIX stat
STATE Statistic value(s) reset: all
TYPE statistics
eventCount 3604
READINGS:
2026-02-27 18:07:08 monitoredDevicesFBDECT FBDECT_Fritzbox_Actors_15282_0919488_1
2026-02-27 18:32:28 monitoredDevicesUnsupported FBDECT_Fritzbox_Actors_15282_0919488_1#FBDECT
2026-03-01 23:59:55 nextPeriodChangeCalc 2026-03-02 00:59:55
2026-02-28 23:37:35 state Statistic value(s) reset: all
fhem:
modulVersion $Date: 2024-05-18 09:37:34 +0200 (Sat, 18 May 2024) $
nextPeriodChangeTime 1772409595
Attributes:
alias Statistic Device SmartMeter
deltaReadings FBDECT_Fritzbox_Actors_15282_0919488_1:energy_kWh
durationPeriodHour 1
durationReadings FBDECT_Fritzbox_Actors_15282_0919488_1:power_round
ignoreDefaultAssignments 1
room Test
specialDeltaPeriodHours FBDECT_Fritzbox_Actors_15282_0919488_1:energy_kWh:Month:01:03:06:12
specialDeltaPeriods FBDECT_Fritzbox_Actors_15282_0919488_1:energy_kWh:Month:01:03:06:12Vielleicht findet ja jemand meinen Fehler. Ich denke ich habe alles so gemacht wie es im Wiki bzw. der commandref steht.Ich möchte eigentlich erstmal nur einen Durchschnitt für den aktuellen Verbrauch (power_round) für verschiedene Zeitperioden und für den Gesamtverbrauch das Delta für verschiedene Zeitabstände.
#6
Bastelecke / Aw: ESP RGBWW Wifi Led Control...
Letzter Beitrag von vbs - 01 März 2026, 23:04:35Ich hab mal das FHEM-Modul geupdatet im master-Branch. Das Modul ist jetzt (mutmaßlich) mit der alten und auch mit der neuen (6.x) Firmware kompatibel. Ich hab es nicht explizit getestet, aber sollte dann auch mit pjakobs Firmware funktionieren.
Ein Hinweis: da der Modus "solid" aus der neuen (6.x) Firmware rausgeflogen ist, ist das auch im FHEM-Modul nicht mehr drin. Also auch mit der alten FW ist dann "solid" nicht mehr nutzbar. Bin mir aber sehr sicher, dass das ohnehin niemand verwendet hat.
Das liegt jetzt wieder im master-Branch. Also in FHEM folgendermaßen einrichten:
Falls man den 6er-Branch des FHEM-Moduls benutzt hat, dann vorher so löschen:
Ein Hinweis: da der Modus "solid" aus der neuen (6.x) Firmware rausgeflogen ist, ist das auch im FHEM-Modul nicht mehr drin. Also auch mit der alten FW ist dann "solid" nicht mehr nutzbar. Bin mir aber sehr sicher, dass das ohnehin niemand verwendet hat.
Das liegt jetzt wieder im master-Branch. Also in FHEM folgendermaßen einrichten:
Code Auswählen
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txtFalls man den 6er-Branch des FHEM-Moduls benutzt hat, dann vorher so löschen:
Code Auswählen
update delete https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/dev-6.0/controls_espledcontroller.txt #7
DOIF / Aw: DOIF reagiert verzögert au...
Letzter Beitrag von holle75 - 01 März 2026, 22:42:31das doif berechnet den Strom den ein AC gekoppelter Mikrowechselrichter leisten darf. Bei jeder Änderung im Haupt-Solarcharger. Wenn er mehr darf wird das verzögert, wenn er weniger darf sofort. Warten, damit die Wahrscheinlichkeit einer Überschneidung (Zeit Steuerkette) minimiert wird. Zu wenig für ein paar Sekunden ist easy. Zuviel für nur ne Millisekunde kann teuer werden.
Ich nehm das wait morgen mal raus. Hab aber zig andere Doifs mit waits und da ist mir noch nie eine Verzögerung beim Schalten aufgefallen.
Ich will es nochmal betonen: mir gehts um das initialize/disable des Doifs, nicht um die Funktionalität.
Ich nehm das wait morgen mal raus. Hab aber zig andere Doifs mit waits und da ist mir noch nie eine Verzögerung beim Schalten aufgefallen.
Ich will es nochmal betonen: mir gehts um das initialize/disable des Doifs, nicht um die Funktionalität.
#8
DOIF / Aw: DOIF reagiert verzögert au...
Letzter Beitrag von Guybrush - 01 März 2026, 22:25:36was heisst denn zu schnelles hochschalten? der Wert ist doch da. Wieso dann 10 sek warten? Das wait 10:0 blockiert die Ausführung des ersten Teils für 10 Sekunden. Ich weiß halt nicht, wie das intern im doif modul läuft. Gut möglich, dass das device solang blockiert ist, bis das wait rum ist. das devstateicon wird ja vom modul selbst abhängig sein. Wäre jedenfalls plausibel...
#9
DOIF / Aw: DOIF reagiert verzögert au...
Letzter Beitrag von holle75 - 01 März 2026, 22:18:38Du meinst das wait 10?
Das verhindert ein zu schnelles Hochschalten des erlaubten Stroms. Nach unten "sofort", nach oben mit 10 Sek Verzögerung.
Könnte ich mal rausnehmen, aber dass das was mit Schalten von DevStateIcon zu tun hat, würde mich wundern. Die 10 Sekunden Verzögerung beim Schalten sind auch eher gefühlt als genau 10 Sekunden.
Das verhindert ein zu schnelles Hochschalten des erlaubten Stroms. Nach unten "sofort", nach oben mit 10 Sek Verzögerung.
Könnte ich mal rausnehmen, aber dass das was mit Schalten von DevStateIcon zu tun hat, würde mich wundern. Die 10 Sekunden Verzögerung beim Schalten sind auch eher gefühlt als genau 10 Sekunden.
#10
DOIF / Aw: DOIF reagiert verzögert au...
Letzter Beitrag von Guybrush - 01 März 2026, 21:46:52nimms doch mal raus und guck dann. versteh den sinn vom wait da ohnehin nicht