WeekdayTimer state "active" statt der aktuellen Temperatur

Begonnen von persching, 24 Dezember 2019, 11:36:31

Vorheriges Thema - Nächstes Thema

persching

Hallo,
ich nutze verschiedene Weekdaytimer je Thermostat um verschiedene Szenarien gerecht zu werden. So gibt es "normal" für Arbeitstage, "KeinArbeitstag" für Ferien, Urlaub "Off" für den Sommerbetrieb und "Minimal" für die Übergangszeit. Über ReadingsVal wird das so gesteuert, dass jeweils nur eines dieser Weekdaytimer aktiv ist. Nun ist es aber so, dass bei machen (nicht bei allen!!) Weekdaytimern statt der aktuellen Temperatur dort nur "active" im state steht. Die Temperatur wird dann auch nicht gesetzt. Hier mal am Beispiel meines Schlafzimmerthermostats:

Internals:
   COMMAND   
   CONDITION  ((ReadingsVal("Familie","state","zuhause") ne "verreist")&&(ReadingsVal("KAT","state","0")==1)&&(ReadingsVal("HC_Schlafz_Profile","state","Fehler") eq "Auto"))
   DEF        OG_Schlafz_T 78|08:00|19 78|19:30|19.5 ((ReadingsVal("Familie","state","zuhause") ne "verreist")&&(ReadingsVal("KAT","state","0")==1)&&(ReadingsVal("HC_Schlafz_Profile","state","Fehler") eq "Auto"))
   DEVICE     OG_Schlafz_T
   FUUID      5d924a77-f33f-e65d-60c2-13698c196239e95a
   FVERSION   98_WeekdayTimer.pm:0.207690/2019-12-17
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       HC_Schlafz_KeinArbeitstag
   NR         273
   Profil 0: Sonntag 08:00:00 19, 19:30:00 19.5
   Profil 1: Montag 08:00:00 19, 19:30:00 19.5
   Profil 2: Dienstag 08:00:00 19, 19:30:00 19.5
   Profil 3: Mittwoch 08:00:00 19, 19:30:00 19.5
   Profil 4: Donnerstag 08:00:00 19, 19:30:00 19.5
   Profil 5: Freitag 08:00:00 19, 19:30:00 19.5
   Profil 6: Samstag 08:00:00 19, 19:30:00 19.5
   Profil 7: Wochenende 08:00:00 19, 19:30:00 19.5
   Profil 8: Werktags 08:00:00 19, 19:30:00 19.5
   STATE      active
   STILLDONETIME 0
   TYPE       WeekdayTimer
   READINGS:
     2019-12-24 08:10:28   currValue       19.5
     2019-12-24 08:10:28   nextUpdate      2019-12-25 08:00:00
     2019-12-24 08:10:28   nextValue       19
     2019-12-24 08:10:28   state           active
   SWITCHINGTIMES:
     78|08:00|19
     78|19:30|19.5
   TIMER:
     HC_Schlafz_KeinArbeitstag_2:
       HASH       HC_Schlafz_KeinArbeitstag
       MODIFIER   2
       NAME       HC_Schlafz_KeinArbeitstag_2
       forceSwitch 1
     HC_Schlafz_KeinArbeitstag_SetTimerOfDay:
       HASH       HC_Schlafz_KeinArbeitstag
       MODIFIER   SetTimerOfDay
       NAME       HC_Schlafz_KeinArbeitstag_SetTimerOfDay
       SETTIMERATMIDNIGHT 1
   dayNumber:
     !$we       8
     $we        7
     di         2
     do         4
     fr         5
     mi         3
     mo         1
     sa         6
     so         0
   helper:
     daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
     daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
         08:00:00   19
         19:30:00   19.5
       1:
         08:00:00   19
         19:30:00   19.5
       2:
         08:00:00   19
         19:30:00   19.5
       3:
         08:00:00   19
         19:30:00   19.5
       4:
         08:00:00   19
         19:30:00   19.5
       5:
         08:00:00   19
         19:30:00   19.5
       6:
         08:00:00   19
         19:30:00   19.5
       7:
         08:00:00   19
         19:30:00   19.5
       8:
         08:00:00   19
         19:30:00   19.5
     WEDAYS:
       1          1
       2          2. Weihnachtstag
       4          1
       5          1
   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
     nl:
       Zondag
       Maandag
       Dinsdag
       Woensdag
       Donderdag
       Vrijdag
       Zaterdag
       weekend
       werkdagen
   profil:
     1:
       EPOCH      1577170800
       PARA       19
       TIME       08:00
       WE_Override 0
       TAGE:
         7
         8
     2:
       EPOCH      1577212200
       PARA       19.5
       TIME       19:30
       WE_Override 0
       TAGE:
         7
         8
   profile_IDX:
     0:
       08:00:00   1
       19:30:00   2
     1:
       08:00:00   1
       19:30:00   2
     2:
       08:00:00   1
       19:30:00   2
     3:
       08:00:00   1
       19:30:00   2
     4:
       08:00:00   1
       19:30:00   2
     5:
       08:00:00   1
       19:30:00   2
     6:
       08:00:00   1
       19:30:00   2
     7:
       08:00:00   1
       19:30:00   2
     8:
       08:00:00   1
       19:30:00   2
   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
     nl:
       zo
       ma
       di
       wo
       do
       vr
       za
       $we
       !$we
Attributes:
   DbLogExclude .*
   WDT_Group  WDT_Schlafz
   WDT_delayedExecutionDevices OG_Schlafz_Fensterkontakt
   commandTemplate set $NAME desiredTemperature $EVENT
   group      Profile
   room       Roomdetails->Schlafzimmer
   switchInThePast 1


Hier fallen mir 2 Dinge auf, die meiner Meinung nach falsch sind:

STATE = active
nextUpdate  2019-12-25 08:00:00

der nächste Schaltpunkt ist doch 2019-12-24 19:30:00...

Beta-User

Hmm, also:

Ich nehme an, dass bei der Auswertung des ersten Schaltzeitpunkts (08:00 Uhr) mindestens einer der in CONDITION berücksichtigten Parameter nicht paßte. Der von dir gewählte WDT scheint am 24.12. daher "active" stehen geblieben zu sein, weil er nie eine Temperatur zu setzen hatte.
Damit war auch der folgende timer an dem Tag nicht als aktiver Timer zu erkennen, weswegen der WDT meldete, dass er davon ausgeht, dass an diesem Tag gar nicht mehr geschaltet werden muß (daher der nächste aktive Timer am Folgetag, für den noch keine Auswertung erfolgt war).
Am Internal "TIMER:HC_Schlafz_KeinArbeitstag_2" ist aber (indirekt) zu erkennen, dass er das "profil:2" (19:30 Uhr) noch ausführen wird, um zu checken, ob das zum Schaltzeitpunkt wirklich noch der Fall ist. Sollten also zu diesem Zeitpunkt dann alle CONDITION-Parameter gegeben gewesen sein, müßte auch die Temperatur gesetzt worden sein.

Kannst du das irgendwie verifizieren?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

persching

Das mit dem verifizieren wird schwierig. Andere WDT, die prinzipiell die selben Bedingungen haben, haben in der Nacht geschaltet. Es wurde durch das einschalten der Umwälzpumpe der Heizung je Raum ein WeekdayTimer_SetAllParms je WDT aufgerufen. KAT wurde am 23.12. (Ferienbeginn) auf 1 gesetzt, HC_Schlafz_Profile habe ich nach der Übergangszeit also irgendwann im Herbst auf "Auto" gesetzt. Und Familie ist natürlich abhängig von Presence der Handys.
Der Sollablauf wäre also gewesen, dass ca. um 2 oder 3 Uhr, wenn die Heizung per Außenfühler entschieden hat, dass die Nachtabsenkung vorbei ist werden alle Thermostate von 17°C auf ihre eingestellte Nachttemperatur eingestellt. Hintergrund: wenn die Umwälzpumpe ausgeschaltet ist kann der Thermostat regeln was er will, es wird nicht funktionieren. Und da in diesem Fall die Thermstate weit übersteuern, dann hab ich das eingebaut. Somit ist das übersteuern ein wenig besser. Die MAX Thermostate sind hier wesentlich schlechter als z.b einen Homematic Thermostat den ich habe.
Für die Fehlersuche wäre es natürlich besser, wenn es ein Fehler wäre, der ständig auftritt. Dem ist aber nicht so, es ist ab und zu schon gewesen, aber zu 99% funktioniert es.

Beta-User

Dann wird das schwierig festzustellen, ob überhaupt ein Fehler vorlag; sollte das nochmal auftreten, bitte die CONDITION auch auswerten - wobei auch das nichts (mehr) bringt, wenn zwischenzeitlich eine Änderung eingetreten sein sollte. CONDITION wird nämlich nur zur Schaltzeit ausgewertet, anders als eine delayedExecutionCond, die immer wieder überprüft wird.

Eventuell kannst du das ganze setup etwas vereinfachen, indem du die neue Option nutzt, einfach pro Thermostat nur einen WDT anzulegen und bei dem das weekprofile auszutauschen, je nachdem, welches Topic/Profil grade - abhängig von den anderen Rahmenbedingungen - aktiv sein soll.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

persching

Hallo beta-User,
von dieser neuen Methode habe ich gelesen, aber so wirklich überzeugt bin ich davon nicht.
1. für die Übertragung des Wochenprogrammes an 10 Thermostate werden sicherlich sehr, sehr viele Credits benötigt und darum dauert das ewig
2. Durch die Verwendung des Auto-modes nimmt man sich die Flexibilität der Anwesenheitssteuerung anhand von Presence.
Oder wie macht man das dann sinnvoll?

Beta-User

Moin. Habe ich vielleicht nicht gut erklärt: Der (dann nur noch eine) WeekdayTimer ist weiter das Element, das zur "richtigen Zeit" einfach nur die neue Solltemperatur übermittelt, es ändert sich also weder am Credit-Verbrauch was, noch nutzt man den "auto"-Mode der Thermostate.

Man kann zwar auch weekprofile nutzen, um Wochenprogramme auf diverse Thermostat-Typen zu schieben, bei der "neuen" Methode wird aber eben ein WeekdayTimer genutzt, der dann im laufenden Betrieb angewiesen werden kann, ein anderes Profil zu nutzen (ohne die DEF zu ändern).

Du legst also in weekprofile z.B. ein Profil für HC_Schlafz an, aktivierst die Nutzung von Topics und legst dann Profile für diverse Topics an wie KeinArbeitstag, Arbeitstag, Urlaub, Abwesend.
Dann läßt du den einen WDT, der für HC_Schlafz zuständig sein soll auf dieses weekprofile-Device hören und setzt z.B. das Profil KeinArbeitstag:HC_Schlafz. Schon sollte der WDT dieses Temperaturprofil fahren.

Hast du mehrere, sollte es möglich sein, über "set ... restore_topic KeinArbeitstag" alle WDT, die entsprechend konfiguriert sind mit dem für sie passenden Profil zu versorgen - wie gesagt, ohne dass dabei mehr wie die jeweils grade aktuelle Solltemperatur tatsächlich an die Thermostate geschickt wird...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

persching

Achso, das ist natürlich etwas ganz anderes. Dann hatte ich das in der Tat falsch verstanden und sollte mich mal damit beschäftigen. Dann wird das wohl meine nächste große Änderung.