Wakuptimer aus Residents-Modul und holiday Device(s)

Begonnen von Bitschubser, 08 Juli 2020, 17:40:54

Vorheriges Thema - Nächstes Thema

Bitschubser

Hallo,

ich versuche mich grade an einer Weckroutine für mich und die Kinder.
Laut Commandref kann auch ein Hoiday Device mit einbezogen werden, sodass der Wecker eben nicht jeden Wochentag loslegt.
Nun habe ich leider nicht so viel Urlaub wie die Kinder Ferien haben.  :(
Daher die Idee unterschiedliche Holiday Devices zu definieren. Eines für die Kinder und eines für mich.
Aber wie können diese den Wakeuptimern zugeordnet werden?
Oder mache ich da einen Denkfehler und das ist so gar nicht vorgesehen?

Jens
FHEM in VM auf Proxmox, Homematic über 2x HM-Lan, Homematic-IP über Raspimatic in VM auf Proxmox, SMA-Wechselrichter, Pushover, TTS, Shelly + Sonoff über MQTT

amenomade

Nw. wird nur ein holiday Device definiert. Es hat auch Einflus auf Funktionen wie IsWe() oder einige Devices, die $we benutzen.

Einfacher wäre es wahrscheinlich mit Kalender-Schalten
https://wiki.fhem.de/wiki/Wochenende,_Feiertage_und_Schulferien#Feiertage_mittels_Internet-Kalender
https://wiki.fhem.de/wiki/Google-Kalender_zur_Steuerung_von_Dummies
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Kleine Klarstellung: Ein holiday-device sollte nur dann Einfluss auf IsWe() (und damit $we) haben, wenn es auch in die Liste in global/holiday2we aufgenommen wurde.

Was den Rest angeht: Auf welche Anleitung usw. beziehst du dich?
Vermutlich geht das schon, du greifst vermutlich ja nur mit ReadingsVal() auf irgendwas zu...?
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

amenomade

#3
Meiner Meinung nach meint er das:

ZitatRESIDENTS Toolkit

        Using set-command create you may add pre-configured configurations to your RESIDENTS, ROOMMATE, GUEST or PET devices for your convenience.
        The following commands are currently available:

        wakeuptimer   -   adds a wake-up timer dummy device with enhanced functions to start with wake-up automations
            A notify device is created to be used as a Macro to carry out your actual automations. The macro is triggered by a normal at device you may customize as well. However, a special RESIDENTS Toolkit function is handling the wake-up trigger event for you.
            The time of activated wake-up timers may be relatively increased or decreased by using + or - respectively. +HH:MM can be used as well.

            The wake-up behaviour may be influenced by the following device attributes:
            wakeupAtdevice - backlink the at device (mandatory)
            wakeupDays - only trigger macro at these days. Mon=1,Tue=2,Wed=3,Thu=4,Fri=5,Sat=6,Sun=0 (optional)
            wakeupDefaultTime - after triggering macro reset the wake-up time to this default value (optional)
            wakeupEnforced - Enforce wake-up (optional; 0=no, 1=yes, 2=if wake-up time is not wakeupDefaultTime, 3=if wake-up time is earlier than wakeupDefaultTime)
            wakeupHolidays - May trigger macro on holidays or non-holidays (optional; andHoliday=on holidays also considering wakeupDays, orHoliday=on holidays independently of wakeupDays, andNoHoliday=on non-holidays also considering wakeupDays, orNoHoliday=on non-holidays independently of wakeupDays)

https://fhem.de/commandref.html#RESIDENTS

EDIT : Und meines Wissens greift das tatsächlich auf den holiday Devices, die in global holiday2we definiert sind. Deswegen meine Vermutung, das was der TE sich vorstellt nicht möglich ist. Kann mich aber irren.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Hmm, vermutlich hast du recht (und der Threadtitel sagt auch klar, dass es um Residents geht), aber andererseits erschließt sich mir dann auch nicht, wie es mit individuellen dummys gehen sollte. (Muß aber zugeben, dass ich Residents&Co bisher "ausgespart" habe, vermutlich übersehe ich da mal wieder was essentielles...).
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

Bitschubser

Ja, es geht um das residents-Modul.

prinzipiell wäre es mir am liebsten wenn ich den Wecker wie amenomade schon schrieb direkt von einem Dummy abhängig machen könnte. Denn in der Tat frage ich den Ferienkalender bereits auch aus dem Internet ab. Und an meinem Bürokalender arbeite ich.  Aber bisher habe ich nur die Möglichkeit über WakeupHolidays gefunden.

Natürlich ist es möglich über DOIF oder ähnliches ein set rr_Jens_wakeuptimer1 OFF abzusetzen, aber schöner wäre es halt direkt im Modul.
FHEM in VM auf Proxmox, Homematic über 2x HM-Lan, Homematic-IP über Raspimatic in VM auf Proxmox, SMA-Wechselrichter, Pushover, TTS, Shelly + Sonoff über MQTT

Beta-User

Bin mal gespannt, was die Residents-Spezialisten dann dazu beitragen können und ob es möglich ist, neben den in global angegebenen h2we-Devices (die übrigens auch dummys sein können) auch weitere "Frei"-Devices mit einzubinden.

Ich nutze btw. auch Calendar, allerdings ist der Ferienkalender dort Teil unseres "normalen" Kalenders, der z.B. auch Müllabfuhr beinhaltet. Jedenfalls kippe ich die Infos dann nicht in dummy-TYPE-Devices, sondern mache diverse holidays draus. Das hat imo zwei  Vorteile: Zum einen ist es "vorausschauender", wie wenn man das "nur" mit dummy macht (WeekdayTimer sehen dann z.B. auch "übermorgen" richtig, wenn der betreffende holiday in h2we steht), und zum anderen muß ich mich nicht mehr um das richtige timing kümmern (wenn man den dummy später befüllt wie diverse Module am Tagesanfang voraussetzen, müßte man alles manuell neu initialisieren oä.).

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

Bitschubser

@Beta-User
Kannst du mal zeigen wie das aussieht. Calendar habe ich bisher nicht im Einsatz, steht aber auf der Liste. Leider grade hochaktuell nachdem wir heute fast den Biomüll vergessen hätten.  >:(
FHEM in VM auf Proxmox, Homematic über 2x HM-Lan, Homematic-IP über Raspimatic in VM auf Proxmox, SMA-Wechselrichter, Pushover, TTS, Shelly + Sonoff über MQTT

Beta-User

Den Kern des ganzen habe ich hier erläutert: https://forum.fhem.de/index.php/topic,85759.0.html

Das ganze ist so aufgebaut, dass mir ein at 1* täglich um 5 Uhr den ical per wget vom eigenen (kronolith)-Server holt, auf diese Datei greift dann das Calendar-Device zu - Calendar mit Web-Quelle sollte aber genauso gehen, ab da geht es dann mit dem verlinkten Code weiter...

Falls Fragen dazu sind: gerne in dem anderen Thread, hier geht es ja eigentlich vorrangig um die Frage, wie man residents+"irgendein Urlaubsdevice" individualisiert bekommt, oder?
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