WakeUpTimer (dummy device) funktioniert mit Übernahme in neue config nicht mehr

Begonnen von ih-sqeezer, 21 November 2018, 23:30:40

Vorheriges Thema - Nächstes Thema

ih-sqeezer

Hallo zusammen,

ich habe mich seit ein paar Tagen mit dem WakeUpTimer in Kombination mit dem Residents Modul beschäftigt. Ich würde gern via AMAD vom Smartphone den Wecker in FHEM stellen und dementsprechend einige Geräte früh einschalten. Zunächst habe ich mit dem "create" Makro sämtlich benötigte devices von FHEM anlegen lassen. Ebenfalls habe ich das notify angelegt, welches die Weckzeiten vom AMAD device abholt ("set rr_Ingo_wakeuptimer1 nextRun $EVTPART1"). Auch das Makro am Ende, welches die Aktionen am Morgen schalten soll ist korrekt definiert worden. Soweit so gut. Mit diesem einen WakeUpTimer kann ich wunderbar die Geräte schalten lassen. Die Readings im WakeUpTimer1 sehen wie folgt aus:

lastRun   07:15
nextRun   06:45
state   OFF

Nun zu meinem Problem. Sofern ich einen weiteren WakeUpTimer2 erstellen lasse (erneut via FHEM Makro "create"), werden auch alle devices korrekt definiert. Jedoch werden in BEIDEN WakeUpTimer1/2 das STATE nicht mehr korrekt in "nextRun" und dann nach dem Auslösen "lastRun" aufgelöst. Das notify für das Einstellen der WakeUpTimer1/2 setzt nur noch den STATE:

state   nextRun 06:45

Das dumme ist nur, dass somit kein Wecker zur gewünschten Zeit mehr ausgelöst wird. Auch wenn ich die WakeUpTimer1/2 manuell definiere über das nextRun > dropDown, wird kein Wecker zu dieser Zeit ausgelöst. Ich habe mir dazu mal die WakeUpTimer1/2 mit verbose 4 loggen lassen.

Hier mal ein list vom WakeUpTimer1:

Internals:
   NAME       rr_Ingo_wakeuptimer1
   NR         981
   STATE      nextRun 06:45
   TYPE       dummy
   READINGS:
     2018-11-21 14:16:56   state           nextRun 06:45
Attributes:
   alias      Wake-up Timer 1
   devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
   group      Presence
   icon       time_timer
   room       Wohnung
   setList    nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:,andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3
   sortby     6
   userattr   wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupMacro wakeupUserdevice wakeupAtdevice wakeupResetSwitcher wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2,3 wakeupWaitPeriod:slider,0,1,360
   verbose    4
   wakeupAtdevice at_rr_Ingo_wakeuptimer1
   wakeupDays 0,1,2,3,4,5,6
   wakeupMacro Macro_rr_Ingo_wakeuptimer1
   wakeupOffset 30
   wakeupUserdevice rr_Ingo
   webCmd     nextRun

Der Witz an der Sache ist, sofern ich alle devices für diese Weckautomatisierung wieder lösche und erneut einen WakeUpTimer1 generiere, funktioniert die Sache wieder.

Also entweder ich habe noch irgendein Problem bisher übersehen oder meine dummy devices (WakeUpTimer1/2) werden durch irgendein Interrupt intern nicht weiter verabeitet.

Hatte da zufällig jemand in der letzten Zeit das gleiche oder ein ähnliches Problem damit? Bzw. wer kann mir hierbei helfen? Ich bin wirklich für jede Hilfe dankbar!

UPDATE:

Ich habe erneut etwas mit dem Wecker herumgebastelt und festgestellt, dass es mit dem Speichern der config zu tun hat. Und zwar generiere ich mir meine Wecker wie immer über die Konsole in FHEM, sodass die Syntax natürlich gleich mit geprüft wird. Jedoch bin ich ein Freund der Ordnung und ziehe mir nach einer erfolgreichen Implementation neuer Funktionen immer gern mal die aktuelle fhem.cfg über "Edit files" und sortiere bzw kommentiere noch einige Zeilen. Danach speichere ich die config dort wieder. Es erscheinen keine Fehler von FHEM, als ist für mich die config OK. FHEM startet neu durch und ab dort an funktioniert das setzen der WakeUpTImer nicht mehr. Also, es wird immer nur das STATE vom WakeUpTimer wie oben beschrieben gesetzt, jedoch nicht das Reading "nextRun". Somit funktionieren die Timer nicht mehr. Meiner Meinung nach muss dies ja etwas mit dem notify (Weckzeittransfer AMAD => WakeUpTimer) zu tun haben!?

Grüße,
Ingo

ih-sqeezer

Hallo,

ich muss das Thema nochmal aufgreifen, da es noch immer nicht gelöst ist.

Und zwar beschränkt sich das Problem eigentlich auf das dummy device vom WakeUpTimer. Dieser ist mit einem setlist für unterschiedliche Kommandos ausgelegt.
Sofern dieses dummy device durch die WakeUpTimer creation Routine erstellt wird, nimmt dieser dummy auch das Kommando "set WakeUpTimer nextRun 18:00" korrekt an.
Wenn ich jedoch diesen automatisch erstellten dummy über eine neue fhem.cfg einbinden möchte, funktioniert das interne setzen der dummy Readings nicht mehr. Sprich, wenn ich den Befehl "set WakeUpTimer nextRun 18:00" erneut absetze, wird das "nextRun 18:00" nur in den state gesetzt und intern wird kein Reading "nextRun" ausgelesen. Da stimmt irgendetwas nicht mit der Syntax vom dummy Modul.

Hatte jemadn vlt dieses Problem schon mal bzw in einem anderen Zusammenhang?

Danke und Grüße,
Ingo

dev0

ZitatJedoch bin ich ein Freund der Ordnung und ziehe mir nach einer erfolgreichen Implementation neuer Funktionen immer gern mal die aktuelle fhem.cfg über "Edit files" und sortiere bzw kommentiere noch einige Zeilen. Danach speichere ich die config dort wieder.
Auch wenn das Editieren der fhem.cfg in vielen Fällen funktioniert, funktioniert es manchmal eben auch nicht. Je nach Modul werden bspw. bestimmte Daten auch in anderen Dateien abgelegt. Gewöhne Dir besser an Änderungen via Modul Befehl, via "Raw definition" in FHEMWEB oder via Telnet vorzunehmen. Sollte das auch nicht funktionieren, dann wird der entsprechende Maintainer sicher auch gerne Support leisten.

ih-sqeezer

Zitat von: dev0 am 20 Januar 2019, 09:01:31
Auch wenn das Editieren der fhem.cfg in vielen Fällen funktioniert, funktioniert es manchmal eben auch nicht. Je nach Modul werden bspw. bestimmte Daten auch in anderen Dateien abgelegt. Gewöhne Dir besser an Änderungen via Modul Befehl, via "Raw definition" in FHEMWEB oder via Telnet vorzunehmen. Sollte das auch nicht funktionieren, dann wird der entsprechende Maintainer sicher auch gerne Support leisten.

Das Editieren der config von FHEM sollte dennoch möglich sein! Was ist denn das bitte schön für ein flow, wenn Konfigurationen seitens eines automatischen flows vorgenommen werden und diese nicht mal in der config abgespeichert werden? Dies ist bestimmt auch nicht das eigentliche Konzept von FHEM. Weiterhin sollte man diese Konfigurationen zumindest mit ins Wiki aufnehmen. Woher soll der Anwender das sonst Wissen? Sofern es überhaupt so ist.

Ich räume das config file lediglich ab und zu mal auf. Es ist wirklich eine unschöne Sache, wenn man nach 6 Monaten Entwicklung wieder Zeit für das debugging nach einem FHEM restart mit aufgeräumter config investieren muss.

Schlussendlich würde ich das Problem gern verstehen wollen und eventuelle Korrekturen vornehmen. Ich kann mir nicht vorstellen, dass ich bisher der Einzige mit diesem Problem bin.
Ich bin demzufolge offen für Vorschläge. Weiterhin bin ich gerade dabei eine Alternative zu entwickeln.

Grüße,
Ingo