Neues Modul - Heating_Control, WeekdayTimer

gero · 20 April 2015, 11:38:32

Hallo Dietmar,

seit einem FHEM-Update heute morgen stehen zwei meiner Heating_Control Devices auf state inactive.

Hier die Ausgabe von einem list:

Code Auswählen

Internals: 
   COMMAND    {} 
   DEF        DG.SZ.MAX.Room Mo-So|09:30|18.0 Mo-So|16:00|16.0 {} 
   DEVICE     DG.SZ.MAX.Room 
   GlobalDaylistSpec 
   LANGUAGE   de 
   NAME       DG.SZ.MAX.HCB 
   NR         354 
   Profil 0: Sonntag 09:30:00 18.0, 16:00:00 16.0 
   Profil 1: Montag 09:30:00 18.0, 16:00:00 16.0 
   Profil 2: Dienstag 09:30:00 18.0, 16:00:00 16.0 
   Profil 3: Mittwoch 09:30:00 18.0, 16:00:00 16.0 
   Profil 4: Donnerstag 09:30:00 18.0, 16:00:00 16.0 
   Profil 5: Freitag 09:30:00 18.0, 16:00:00 16.0 
   Profil 6: Samstag 09:30:00 18.0, 16:00:00 16.0 
   STATE      inactive 
   TYPE       Heating_Control 
   CHANGETIME: 
   Helper: 
     Dblog: 
       State: 
         Mydblog: 
           TIME       1429518809.10066 
           VALUE      inactive 
   Readings: 
     2015-04-20 09:30:00   nextUpdate      16:00:00 
     2015-04-20 09:30:00   nextValue       16.0 
     2015-04-20 10:33:29   state           inactive 
   SWITCHINGTIMES: 
     Mo-So|09:30|18.0 
     Mo-So|16:00|16.0 
   Timer: 
     Dg.sz.max.hcb_16:00:00: 
       HASH       DG.SZ.MAX.HCB 
       MODIFIER   16:00:00 
       NAME       DG.SZ.MAX.HCB_16:00:00 
     Dg.sz.max.hcb_settimerofday: 
       HASH       DG.SZ.MAX.HCB 
       MODIFIER   SetTimerOfDay 
       NAME       DG.SZ.MAX.HCB_SetTimerOfDay 
   Daynumber: 
     !$we       8 
     $we        7 
     di         2 
     do         4 
     fr         5 
     mi         3 
     mo         1 
     sa         6 
     so         0 
   Helper: 
     DESIRED_TEMP_READING 
     daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we) 
     daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we) 
     Switchingtime: 
       0: 
         09:30:00   18.0 
         16:00:00   16.0 
       1: 
         09:30:00   18.0 
         16:00:00   16.0 
       2: 
         09:30:00   18.0 
         16:00:00   16.0 
       3: 
         09:30:00   18.0 
         16:00:00   16.0 
       4: 
         09:30:00   18.0 
         16:00:00   16.0 
       5: 
         09:30:00   18.0 
         16:00:00   16.0 
       6: 
         09:30:00   18.0 
         16:00:00   16.0 
   Longdays: 
     de: 
       Sonntag 
       Montag 
       Dienstag 
       Mittwoch 
       Donnerstag 
       Freitag 
       Samstag 
       Wochenende 
       Werktags 
     en: 
       Sunday 
       Monday 
       Tuesday 
       Wednesday 
       Thursday 
       Friday 
       Saturday 
       weekend 
       weekdays 
     fr: 
       Dimanche 
       Lundi 
       Mardi 
       Mercredi 
       Jeudi 
       Vendredi 
       Samedi 
       weekend 
       jours de la semaine 
   Profil: 
     09:30:00: 
       NEXTPARA   16.0 
       NEXTSWITCH 16:00:00 
       PARA       18.0 
       TIM        1429515000 
       TAGE: 
         0 
         1 
         2 
         3 
         4 
         5 
         6 
     16:00:00: 
       NEXTPARA   18.0 
       NEXTSWITCH 09:30:00 
       PARA       16.0 
       TIM        1429538400 
       TAGE: 
         0 
         1 
         2 
         3 
         4 
         5 
         6 
   Shortdays: 
     de: 
       so 
       mo 
       di 
       mi 
       do 
       fr 
       sa 
       $we 
       !$we 
     en: 
       su 
       mo 
       tu 
       we 
       th 
       fr 
       sa 
       $we 
       !$we 
     fr: 
       di 
       lu 
       ma 
       me 
       je 
       ve 
       sa 
       $we 
       !$we 
Attributes: 
   room       2.00_Heizung

Nachdem ich einen neuen Schaltzeitpunkt zum Testen hinzugefügt habe, wurde auch geschaltet und der korrekte State (Temperatur) wurde angezeigt. Aber nach Löschen von diesem Schaltzeitpunkt ging das Device zurück auf inactive. Ich bin mir nicht sicher, was du mit dem state inactive anzeigen möchtest. Aber ich benötige für meine Module, die Möglichkeit den aktuellen Wert des Heating_Control Devices abzufragen. Entweder sollte der aktuelle Werte in state stehen, oder ich bräuchte eine andere Möglichkeit (z.B. ein zusätzliches Reading).

Gruß,
Gero

ulli · 20 April 2015, 18:53:49

Super Sache Dietmar, ich teste es gleich mal. Danke!

Ascos · 20 April 2015, 19:07:16

Zitat von: gero am 20 April 2015, 11:38:32
Hallo Dietmar,

seit einem FHEM-Update heute morgen stehen zwei meiner Heating_Control Devices auf state inactive.

Hier die Ausgabe von einem list:
Code Auswählen Erweitern
Internals: COMMAND {} DEF DG.SZ.MAX.Room Mo-So|09:30|18.0 Mo-So|16:00|16.0 {} DEVICE DG.SZ.MAX.Room GlobalDaylistSpec LANGUAGE de NAME DG.SZ.MAX.HCB NR 354 Profil 0: Sonntag 09:30:00 18.0, 16:00:00 16.0 Profil 1: Montag 09:30:00 18.0, 16:00:00 16.0 Profil 2: Dienstag 09:30:00 18.0, 16:00:00 16.0 Profil 3: Mittwoch 09:30:00 18.0, 16:00:00 16.0 Profil 4: Donnerstag 09:30:00 18.0, 16:00:00 16.0 Profil 5: Freitag 09:30:00 18.0, 16:00:00 16.0 Profil 6: Samstag 09:30:00 18.0, 16:00:00 16.0 STATE inactive TYPE Heating_Control CHANGETIME: Helper: Dblog: State: Mydblog: TIME 1429518809.10066 VALUE inactive Readings: 2015-04-20 09:30:00 nextUpdate 16:00:00 2015-04-20 09:30:00 nextValue 16.0 2015-04-20 10:33:29 state inactive SWITCHINGTIMES: Mo-So|09:30|18.0 Mo-So|16:00|16.0 Timer: Dg.sz.max.hcb_16:00:00: HASH DG.SZ.MAX.HCB MODIFIER 16:00:00 NAME DG.SZ.MAX.HCB_16:00:00 Dg.sz.max.hcb_settimerofday: HASH DG.SZ.MAX.HCB MODIFIER SetTimerOfDay NAME DG.SZ.MAX.HCB_SetTimerOfDay Daynumber: !$we 8 $we 7 di 2 do 4 fr 5 mi 3 mo 1 sa 6 so 0 Helper: DESIRED_TEMP_READING daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we) daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we) Switchingtime: 0: 09:30:00 18.0 16:00:00 16.0 1: 09:30:00 18.0 16:00:00 16.0 2: 09:30:00 18.0 16:00:00 16.0 3: 09:30:00 18.0 16:00:00 16.0 4: 09:30:00 18.0 16:00:00 16.0 5: 09:30:00 18.0 16:00:00 16.0 6: 09:30:00 18.0 16:00:00 16.0 Longdays: de: Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag Wochenende Werktags en: Sunday Monday Tuesday Wednesday Thursday Friday Saturday weekend weekdays fr: Dimanche Lundi Mardi Mercredi Jeudi Vendredi Samedi weekend jours de la semaine Profil: 09:30:00: NEXTPARA 16.0 NEXTSWITCH 16:00:00 PARA 18.0 TIM 1429515000 TAGE: 0 1 2 3 4 5 6 16:00:00: NEXTPARA 18.0 NEXTSWITCH 09:30:00 PARA 16.0 TIM 1429538400 TAGE: 0 1 2 3 4 5 6 Shortdays: de: so mo di mi do fr sa $we !$we en: su mo tu we th fr sa $we !$we fr: di lu ma me je ve sa $we !$we Attributes: room 2.00_Heizung

Nachdem ich einen neuen Schaltzeitpunkt zum Testen hinzugefügt habe, wurde auch geschaltet und der korrekte State (Temperatur) wurde angezeigt. Aber nach Löschen von diesem Schaltzeitpunkt ging das Device zurück auf inactive. Ich bin mir nicht sicher, was du mit dem state inactive anzeigen möchtest. Aber ich benötige für meine Module, die Möglichkeit den aktuellen Wert des Heating_Control Devices abzufragen. Entweder sollte der aktuelle Werte in state stehen, oder ich bräuchte eine andere Möglichkeit (z.B. ein zusätzliches Reading).

Gruß,
Gero

Hey,

das Phänomen hatte ich auch. Das kommt dann vor, wenn deine Geräte in den FHEM Config nach deiner Heating Control definiert sind. Somit findet das Modul die Geräte noch nicht. Erst wenn es die Geräte einmal erfolgreich geschaltet hat, ändert sich der State.
Das er, nachdem du den Schaltzeitpunkt wieder gelöscht hast, wieder auf inaktive zurück ging, passt da ja auch, da das Modul ja nun wieder, seit dem FHEM Neustart das Gerät noch nicht geschaltet hat (da ja der gelöschte Zeitpunkt nun nicht mehr zählt).

So habe ich es mir zumindest erklärt.
Abhilfe soll es schaffen, wenn die Gerätedefnition ganz ans Ende der COnfig geschoben werden. Ich selbst habe es nicht getan, das es bei mir auch so läuft und der kurze Zeitraum des Inactive mich nicht stört.

VG
AScos

Dietmar63 · 20 April 2015, 21:21:22

@gero

Die Antwort von Ascos kann das Problem richtig beschreiben.
Wenn du deine Definition veröffentlichst, kann ich den Sachverhalt aber nochmals untersuchen.

Erklärung:
state nimmt immer den letzten Schaltbefehl des HC/WD auf.
Wenn die Bedingungen so sind, dass "scheinbar" nicht geschaltet werden kann geht der state auf inactive.
Dies ist leider immer nur eine Vermutung.
HC/WD bekommt gar nicht selbst gar mit, ob geschaltet wird, weil HC/WD nur einen String mit den Bedingungen und dem Schaltparameter wie

Code Auswählen


{my $days={};;       map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} ||  $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}
{my $days={1,2,3,4};;map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} ||  $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}

generiert und an fhem übergibt. Der Befehl wird dann durch die allgemeine Kommandoschleife in fhem ausgeführt, wie es beispielsweise auch der at-Befehl macht. Dadurch ist es möglich umfangreiche fhem-Befehlssequenzen(set xx on-for-timer), {PerlCode} oder ´unix Befehle´ zu übergeben.

Ob dann wirklich geschaltet wird, kann man nicht feststellen.

Der Zustand inactive in state ist immer nur eine Vermutung.
Am liebsten würde ich diesen Zustand durch etwas anderes ersetzen(), weil es immer wieder zu Problemen führt, zumal ich ja jetzt eine stark überarbeitete Version freigeschaltet habe, die intern anders arbeitet.

Inactive bedeutet nicht, dass der Timer nicht läuft. Inactive bedeutet nur, dass bisher scheinbar nicht geschaltet wurde.

Wenn du deine Definition veröffentlichst, kann ich nach der Ursache suchent und ggf. Abhilfe schaffen.

gero · 20 April 2015, 22:14:57

Zitat von: Dietmar63 am 20 April 2015, 21:21:22
@gero

Die Antwort von Ascos kann das Problem richtig beschreiben.
Wenn du deine Definition veröffentlichst, kann ich den Sachverhalt aber nochmals untersuchen.

Erklärung:
state nimmt immer den letzten Schaltbefehl des HC/WD auf.
Wenn die Bedingungen so sind, dass "scheinbar" nicht geschaltet werden kann geht der state auf inactive.
Dies ist leider immer nur eine Vermutung.
HC/WD bekommt gar nicht selbst gar mit, ob geschaltet wird, weil HC/WD nur einen String mit den Bedingungen und dem Schaltparameter wie
Code Auswählen Erweitern
{my $days={};; map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }} {my $days={1,2,3,4};;map{$days->{$_}=1}();; if ( (heizungAnAus("Ueb")) && (defined $days->{$wday} || $we || !$we)) { fhem("set HeizungWohnen desired-temp 22.0") }}
generiert und an fhem übergibt. Der Befehl wird dann durch die allgemeine Kommandoschleife in fhem ausgeführt, wie es beispielsweise auch der at-Befehl macht. Dadurch ist es möglich umfangreiche fhem-Befehlssequenzen(set xx on-for-timer), {PerlCode} oder ´unix Befehle´ zu übergeben.

Ob dann wirklich geschaltet wird, kann man nicht feststellen.

Der Zustand inactive in state ist immer nur eine Vermutung.
Am liebsten würde ich diesen Zustand durch etwas anderes ersetzen(), weil es immer wieder zu Problemen führt, zumal ich ja jetzt eine stark überarbeitete Version freigeschaltet habe, die intern anders arbeitet.

Inactive bedeutet nicht, dass der Timer nicht läuft. Inactive bedeutet nur, dass bisher scheinbar nicht geschaltet wurde.

Wenn du deine Definition veröffentlichst, kann ich nach der Ursache suchent und ggf. Abhilfe schaffen.

Hallo Dietmar,

Danke für deine Antwort.
Die Veröffentlichung der Definition meines Devices wird leider nicht viel bringen, da es sich um ein selbst geschriebenes Modul handelt.
Das Modul fasst alle MAX-Devices ein PID20 Regler und ein HCB Device für einen Raum zusammen. Im Endeffekt ist es ein erweiterter resingsProxy für mehrere Devices mit einer entsprechenden Schaltlogik.
Hier trotzdem das define:

Code Auswählen

DEF DG.SZ.TF,EG.GA.TF,DG.SZ.MAX.FK,,DG.SZ.MAX.HT,DG.SZ.MAX.HCB,DG.SZ.MAX.HT.pid
Das Device steht VOR dem HCB Device in der fhem.cfg. Allerdings wird das Device nicht durch das Heating_Control Device direkt gesteuert (siehe list Ausgabe von oben), sondern reagiert in der Notify Funktion auf Änderungen des states vom Heating_Control.

Ich werde wohl selbst noch etwas debuggen müssen, um das Verhalten zu verstehen. Ich melde mich nochmal, wenn ich mehr herausgefunden habe.

Gruß,
Gero

uwe.bart · 22 April 2015, 06:38:47

Ich würde eigentlich erwarten, dass im 'state' eben genau der Wert steht, der im Profile als Parameter übergeben wird: (lt. Doku)

profile
Define the weekly profile. All timings are separated by space. A switchingtime is defined by the following example:

[<weekdays>|]<time>|<parameter>

Ich habe bei mir die verschiedenen WeekdayTimer im Einsatz und die sind in der fhem.cfg als letztes definiert, dennoch steht der Status nach einem restart immer auf 'inactive'.
Die Timer schalten weitestgehend richtig. Allerdings hatte ich gestern die Situation, dass ein Timer auf 'inactive' stand und nicht geschaltet hat. Heute morgen hat er wieder geschaltet.... Das untersuche ich zur Zeit noch.
Bei mir treten die Problem mit dem Weekdaytimer seit meinem Update vom 17.April auf, vorher liefen die Timer monatelang störungsfrei.

Dietmar63 · 22 April 2015, 07:25:31

Veröffentliche bitte deine Definition

uwe.bart · 22 April 2015, 09:18:50

Hier ein Teil meiner Definitionen:

Code Auswählen

    
    # Dummy device nothing...
define nothing dummy
    # Heizung 'normal'
define wdt_normal WeekdayTimer nothing Mo-Fr|06:00|19.9 Di,Do|08:45|19 Di,Do|12:00|19.9 Mo-Do,So|22:00|16 Fr|22:30|16 So,Sa|07:30|19.9 Sa|22:30|16 {fhemWithLog("set WDTModus=normal desired %")}
attr wdt_normal alias normal
attr wdt_normal disable 0
attr wdt_normal group Heizung
attr wdt_normal room Zeitpläne
    # Heizung 'abgesenkt'
define wdt_abgesenkt WeekdayTimer nothing Mo-Fr|06:00|19 Mo-Do|22:00|16 Fr|22:30|16 So,Sa|08:00|19 So,Sa|19:47|16 {fhemWithLog("set WDTModus=abgesenkt desired %")}
attr wdt_abgesenkt alias abgesenkt
attr wdt_abgesenkt group Heizung
attr wdt_abgesenkt room Zeitpläne
    # Aussenlichter
define wdt_outdoorlights WeekdayTimer nothing Mo-Fr|06:15|on Mo-Fr|08:15|off Mo-Fr|16:30|on Mo-Fr|22:15|off Sa-So|16:30|on Sa-So|22:30|off {fhemWithLog("set WDTModus=Aussenlichtuhr %")}
attr wdt_outdoorlights alias Aussenlichter
attr wdt_outdoorlights disable 0
attr wdt_outdoorlights group Lichter
attr wdt_outdoorlights room Zeitpläne

Die Funktion fhemWithLog() ist die Funktion fhem() mit einem Log-Befehl...
Es gibt ein Device THRESHOLD mit einem Reading 'WDTModus'. Wenn das auf 'normal' steht, wird die Temperatur für 'normal' gesetzt usw...

gero · 22 April 2015, 09:56:47

Das Problem scheint aufzutreten, wenn das Device, dass in der Definition steht nicht in der Funktion WeekdayTimer_isHeizung gelistet ist.
Wenn ich bei mir statt meinem eigenen Device z.B. einen PID20 Regler nehme, funktioniert alles.

Wenn ich in der Funktion WeekdayTimer_SetTimer die Variable $grenzSeconds unabhängig von der Funktion WeekdayTimer_isHeizung setze, scheint der Fehler behoben zu sein:

Zitatsub WeekdayTimer_SetTimer($) {
my $hash = shift;
my $name = $hash->{NAME};

my $now = time();

my $switchedInThePast = 0;
my $isHeating = WeekdayTimer_isHeizung($hash);
# my $grenzSeconds = $isHeating ? -24*3600 : -5;
my $grenzSeconds = -24*3600 ;

@Dietmar: Vielleicht hilft dir das bei der Problemlösung weiter.

Gruß,
Gero

uwe.bart · 22 April 2015, 11:52:14

Das kann ich nur bestätigen.
Wenn ich als Device bei mir z.b. ein FHT angebe, springt der Status des WDT sofort auf den aktuellen Wert und alles ist gut.
Hab jetzt also ein Dummy FHT definiert.

Aus meiner Sicht brauchte der WeekdayTimer eigentlich gar kein Device, weil ich ausschließlich mit Befehlen arbeite, die zum entsprechenden Zeitpunkt ausgeführt werden.
Vielleicht könnte man den WeekdayTimer gegenüber dem Heating_Control dahingehend entsprechend abspecken...

uwe.bart · 22 April 2015, 18:49:29

Hat leider auch nix gebracht. Heute nachmittag steht das Device wieder auf inactive und hat auch nicht geschaltet

Dietmar63 · 22 April 2015, 19:32:15

@uwe.barth
Setze mal verbose 5 für den WD. Dann bekommst du debugging Info.

Dietmar63 · 22 April 2015, 20:47:26

Zitat von: uwe.bart am 22 April 2015, 09:18:50
Hier ein Teil meiner Definitionen:
Code Auswählen Erweitern
# Dummy device nothing... define nothing dummy # Heizung 'normal' define wdt_normal WeekdayTimer nothing Mo-Fr|06:00|19.9 Di,Do|08:45|19 Di,Do|12:00|19.9 Mo-Do,So|22:00|16 Fr|22:30|16 So,Sa|07:30|19.9 Sa|22:30|16 {fhemWithLog("set WDTModus=normal desired %")} attr wdt_normal alias normal attr wdt_normal disable 0 attr wdt_normal group Heizung attr wdt_normal room Zeitpläne # Heizung 'abgesenkt' define wdt_abgesenkt WeekdayTimer nothing Mo-Fr|06:00|19 Mo-Do|22:00|16 Fr|22:30|16 So,Sa|08:00|19 So,Sa|19:47|16 {fhemWithLog("set WDTModus=abgesenkt desired %")} attr wdt_abgesenkt alias abgesenkt attr wdt_abgesenkt group Heizung attr wdt_abgesenkt room Zeitpläne # Aussenlichter define wdt_outdoorlights WeekdayTimer nothing Mo-Fr|06:15|on Mo-Fr|08:15|off Mo-Fr|16:30|on Mo-Fr|22:15|off Sa-So|16:30|on Sa-So|22:30|off {fhemWithLog("set WDTModus=Aussenlichtuhr %")} attr wdt_outdoorlights alias Aussenlichter attr wdt_outdoorlights disable 0 attr wdt_outdoorlights group Lichter attr wdt_outdoorlights room Zeitpläne

Die Funktion fhemWithLog() ist die Funktion fhem() mit einem Log-Befehl...
Es gibt ein Device THRESHOLD mit einem Reading 'WDTModus'. Wenn das auf 'normal' steht, wird die Temperatur für 'normal' gesetzt usw...

ich habe deinen Timer(WD) mal bei mir eingegeben, verbose auf 4 gesetzt und ein wenig an den Zeiten gedreht und siehe da er funktioniert. die FM "Undefined ..." ist der Beweis dafür:

Code Auswählen


2015.04.22 20:43:00 3: Undefined subroutine &main::fhemWithLog called at (eval 8301) line 1.
2015.04.22 20:43:00 3: eval: {my $days={};map{$days->{$_}=1}(0,1,2,3,4); if ( 1 && (defined $days->{$wday})) {fhemWithLog("set WDTModus=normal desired 16")}}

2015.04.22 20:43:00 1: PERL ERROR: Undefined subroutine &main::fhemWithLog called at (eval 8301) line 1.
2015.04.22 20:43:00 4: [wdt_normal] command: {my $days={};;map{$days->{$_}=1}(0,1,2,3,4);; if ( 1 && (defined $days->{$wday})) {fhemWithLog("set WDTModus=normal desired 16")}} executed
2015.04.22 20:43:00 4: [wdt_normal] timer seems to be active today: 01234|20:43:00|16
2015.04.22 20:42:04 4: [wdt_normal] 07:30:00 19.9, 22:30:00 16 (Profil 6: Samstag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 22:30:00 16 (Profil 5: Freitag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 08:45:00 19, 12:00:00 19.9, 20:43:00 16 (Profil 4: Donnerstag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 20:43:00 16 (Profil 3: Mittwoch)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 08:45:00 19, 12:00:00 19.9, 20:43:00 16 (Profil 2: Dienstag)
2015.04.22 20:42:04 4: [wdt_normal] 06:00:00 19.8, 20:43:00 16 (Profil 1: Montag)
2015.04.22 20:42:04 4: [wdt_normal] 07:30:00 19.9, 20:43:00 16 (Profil 0: Sonntag)
2015.04.22 20:42:04 4: [wdt_normal] 05:29:46 21:06:50 Mittwoch

Dietmar63 · 22 April 2015, 21:13:51

@uwe:

Zitat
Ich habe bei mir die verschiedenen WeekdayTimer im Einsatz und die sind in der fhem.cfg als letztes definiert, dennoch steht der Status nach einem restart immer auf 'inactive'.

@gero:

Zitat von: gero am 22 April 2015, 09:56:47
Das Problem scheint aufzutreten, wenn das Device, dass in der Definition steht nicht in der Funktion WeekdayTimer_isHeizung gelistet ist.
Wenn ich bei mir statt meinem eigenen Device z.B. einen PID20 Regler nehme, funktioniert alles.

Wenn ich in der Funktion WeekdayTimer_SetTimer die Variable $grenzSeconds unabhängig von der Funktion WeekdayTimer_isHeizung setze, scheint der Fehler behoben zu sein:
@Dietmar: Vielleicht hilft dir das bei der Problemlösung weiter.

Gruß,
Gero

Das ist richtig, nicht wirklich verwunderlich, ja sogar Absicht.:
Geschichte:

WD und HC basieren auf dem gleichen Code. Ursprüngliche wollte ich damit eine Heizung(FHT) steuern.

Wenn man eine Heizungssteuerung definiert, dann wollte ich, dass zum Zeitpunkt der Definition oder eines Neustarts von fhem der zuletzt gültige Temperaturwert an die Heizung übergeben wird, egal wann am Tag der Zeitpunkt für die Schaltung war:

Code Auswählen

define wdt_normal WeekdayTimer nothing Mo-Fr|06:00|19.9 Mo-Fr|16:00|16

Wenn dieser Timer mittags gegen 12 definiert wird oder ein restart erfogt, wollte ich bewirken, dass der Heizung 19.9° gesendet wird.

Deshalb die Funktion isHeizung(). Immer wenn HC/WD erkennt, dass eine Heizung gesteuert wird, erfolgt auch ein Schalten in der Vergangenheit.

Bei Lichtsteuerungen ist dies aus meiner Sicht nicht wünschenswert. Wenn ich im Tagesverlauf gegen 12:00 Uhr eine Definition wie oben erstelle und das Gerät "nothing" eine Lampe ist, will ich nicht, dass die Lampe geschaltet wird.

Weil dein(uwe) dummy und dein(gero) "eigenes device" in isHeizung() nicht erkannt werden, werden sie wie Lichtschalter behandelt und erst zum nächsten Zeitpunkt geschaltet. Leider scheint es auch so zu sein, dass erst mit der ersten echten Schaltung der Wert inactive auf <16> wechselt. Das sehe ich mir nochmals an.

Für solche Sonderfälle könnte ich ein Attribut aufnehmen, dass das Schalten in der "Vergangenheit" erzwingt.

Code Auswählen

attr wdt_normal switchInThePast 1

Dietmar63 · 22 April 2015, 21:15:22

Zitat
Aus meiner Sicht brauchte der WeekdayTimer eigentlich gar kein Device, weil ich ausschließlich mit Befehlen arbeite, die zum entsprechenden Zeitpunkt ausgeführt werden.
Vielleicht könnte man den WeekdayTimer gegenüber dem Heating_Control dahingehend entsprechend abspecken...

Das mag für dich so sein. Andere werden sich vielleicht nicht darüber freuen wenn ich das ausbauen würde.