Handling vom Wochenenddienst

Begonnen von Nighthawk, 26 Juni 2019, 04:23:00

Vorheriges Thema - Nächstes Thema

Nighthawk

Hallo zusammen,

ich suche nun schon seit geraumer Zeit nach einer Lösung für mein Problem, habe aber bis heute noch nichts gefunden.
In meinem FHEM werkeln viele unterschiedliche Module die Wochentag, bzw. Wochenend- abhängig sind (Wecker, Jalosiesteuerung, diverse andere Automatismen...).
Aktuell wird alles von $we abhängig gesteuert, bzw. der Wecker (Alarmclock) hat feste Vorgaben.
Nun habe ich aber manchmal auch am Wochenende Dienst, dies muss ich aktuell manuell einpflegen (was eher schlecht als recht funktioniert, da ich es oft vergesse).
Gibt es einen Konzept ähnlich einer Holiday Datei, wo man die Wochenend-Arbeitstage eintragen kann und diese dann in der $we Variable entsprechend (als !$we) berücksichtigt werden?
Wie kann ich dies auch dem Wecker (Alarmclock) beibringen?


Gruß
Alex

Beta-User

Hmm, also grundsätzlich arbeitet $we (soweit es in fhem.pl verwendet wird, DOIF ist da ggf. "anders") nach einen Positiv-Prinzip, was bedeutet, dass die Variable wahr wird, wenn irgendwo ein "Hit" steht.

Du brauchst also imo. zwingend eine weitere Abfrage (die du vermutlich schon irgendwo in deinen Logiken drin hast), ob das $we denn als Wochentag behandelt werden soll. Wenn das so ist (und du z.B. einen Dummy auf "on" setzt, wenn du die Sonderbehandlung haben willst), ist es vermutlich das einfachste, diesen Dummy über einen entsprechenden (ical)-Calendar-Event zu setzen (das kann auch dein "normaler" Hauptkalender sein, wenn die Schlüsselwörter passen). Details siehe Commandref zu Calendar (oder einen Erklär-Thread dazu hier irgendwo im Forum von betateilchen).
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

rudolfkoenig

@Nighthawk: ich habe die $we Berechnung (d.h. die IsWe() Funktion) angepasst: falls holiday2we ein Element mit dem Namen weekEnd enthaelt, dann wird nicht mehr auf Samstag/Sonntag geprueft.

Mit dieser Methode kann man z.Bsp. auch Freitag+Samstag zu Wochenende erklären, wenn FHEM/weekEnd.holiday so aufgebaut ist:3 0 Fri 01 Alle Freitage in Januar
3 0 Sat 01 Alle Samstage in Januar
3 0 Fri 02 Alle Freitage in Februar
3 0 Sat 02 Alle Samstage in Februar
3 0 Fri 03 Alle Freitage in März
3 0 Sat 03 Alle Samstage in März
....


Und falls weekEnd nicht existiert, dann haengt $we nur von den anderen holiday Werten ab, Samstag/Sonntag zaehlt nicht.

Beta-User

Sehr coole Erweiterung :) .

Würde gerne eine weitere anregen (evtl. nur der Spur nach, weil die folgende Lösung evtl. andere Logiken in Modulen, die nicht den fhem.pl-Mechanismus nutzen durcheinanderbringen könnte, namentlich DOIF): noWeekEnd.holiday

Gibt's die, wird vorab auf positive Ergebnisse getestet und dann ein (bool-) NEGATIVES Ergebnis zurückgegeben.

So hätte unser TE die Option, nur einfach die paar einzelnen Tage als holiday-Datei zu pflegen (oder einen dummy positiv zu setzen), um seine wenigen einzelnen Ausnahmen rauszufischen...

Ablauf wäre:
1. noWeekEnd.holiday angegeben? => Durchlaufen, ob positiv. Ja => return 0;
2. weekend.holiday angegeben => übergehe 0/6 (Sa/So);
3. Werte alle .holiday aus (ggf. ohne noWeekEnd.holiday).

(Kann auch sein, dass ich mal wieder was an der Mächtigkeit deines Vorschlags verkenne, dann bitte schubsen... ::) )
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

Nighthawk

Hallo zusammen,

das was Beta-User schreibt ist genau das was ich mir vorgestellt habe.
Natürlich, Rudi, komme ich mit deiner Lösung auch ans Ziel, es müssen aber deutlich mehr Eingaben gemacht werden als wirklich nötig.


Danke und Gruß
Alex

Beta-User

Na ja,

du kannst das immer noch mit einem myUtils-Aufruf lösen, der genau das macht (z.B. myIsWe()). Das dann statt $we in deine Routinen => done...
Mein Vorschlag macht ja nur eine vorgelagerte Prüfung und "übergibt" dann an die heutige IsWe()-Logik.

(Falls Rudi das nicht zentral lösen möchte: kann da gerne unterstützen, würde es dann aber auf einen dummy als "Ausnahmedevice" beschränken wg. der vermuteten Nebenwirkung bei DOIF, falls jemand das dann kopieren will. Das ginge dann eben nicht für beliebige Tage, sondern nur für heute+/-1...)
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

rudolfkoenig

Ich habe den noWeekEnd Vorschlag eingebaut.

Beta-User

Zitat von: rudolfkoenig am 27 Juni 2019, 07:33:47
Ich habe den noWeekEnd Vorschlag eingebaut.
Wir sollten dazu irgendwie eine Kommunikation machen. Soll ich da was vorbereiten?
(Oder du machst was kurzes bei Ankündigungen, ich greife den IsWe()-Thread nochmal auf?)
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

rudolfkoenig

Ich halte diese Aenderung nicht fuer so bedeutend, dass es in Ankuendigungen erwaehnt werden muesste.
Im IsWe Thread (https://forum.fhem.de/index.php?topic=98583) habe ich einen Hinweis hinterlegt.

Nighthawk

Hallo Rudi, hallo Beta-User,

vielen Dank, ich mache mich dann mal ans Testen.

Gruß
Alex

Beta-User

Zitat von: rudolfkoenig am 27 Juni 2019, 08:17:02
Ich halte diese Aenderung nicht fuer so bedeutend, dass es in Ankuendigungen erwaehnt werden muesste.
"Bedeutend" im programmiertechnischen Sinne sicher nicht ;D .
Es ist vom Bauchgefühl her eher aus Anwendersicht interessant, weil es die vorhandenen Möglichkeiten auf einfache Weise m.E. deutlich erweitert, und der betroffene Userkreis ist auch nicht ganz klein; das Thema betrifft viele, die entweder Schichtdienst haben (und z.B. nach einer Nachtschicht schlafen wollen) oder eben gelegentlich am WE arbeiten müssen...

Wir werden sehen, wie das ankommt bzw. wie viele Fragen es gibt oder Leute, die das erst mal "verpassen" :) .



Vermute übrigens noch einen weiteren Kandidaten für "Nebenwirkungen": WeekdayTimer (&Co)... (Ich kümmere mich drum, muß da aber auch erst mal schauen, wie dieser Teil des Codes damals von Dietmar gedacht gewesen war, wird dauern). Selber schuld... ;D
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

Loredo

Evtl. ist in diesem Zusammenhang auch das noch in Entwicklung befindliche DaySchedule Modul erwähnenswert:
https://forum.fhem.de/index.php/topic,101942.0.html


Man kann damit etwas einfacher durch den Wert von IsWe() an einem bestimmten Tag navigieren.
Außerdem bringt das Modul eine noch erweiterte Logik für die Hinterlegung von Schichtplänen auch als Calendar-Device mit.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Beta-User

Zitat von: Loredo am 02 Juli 2019, 12:30:24
Außerdem bringt das Modul eine noch erweiterte Logik für die Hinterlegung von Schichtplänen auch als Calendar-Device mit.
Ohne mich jetzt im Detail mit den Optionen von diesem neuen Modul DaySchedule befaßt zu haben und dem, was mit "Wert von IsWe() an einem bestimmten Tag navigieren" gemeint ist:

Nach meinem Eindruck (!, muß also nicht richtig sein), sollte man den Code von IsWe() nicht noch weiter aufbohren.
Da Calendar ein sehr flexibles Tool ist, aber state seit langem nicht "none" liefert, ist es insbesondere kaum möglich, ein Calendar-Device im Rahmen von h2we sinnvoll zu verwenden (für gestern und morgen ggf. schon, wenn man - über welche Logik auch immer - passende Readings erzeugt). Was aber - wenn man die richtigen Parameter wählt - recht einfach ist, ist eine holiday-Datei zu erzeugen (jetzt mit yyyy-mm-dd vielleicht sogar noch einfacher), und die "ganz normal" einzubinden.
Hast du vor, da eine Art automatischen Export einzubauen? Oder soll das Modul einen passenden "state" haben und "klassisch" wie ein "normales" holiday-Device abfragbar sein?

(Wir sind für diese Fragen aber vermutlich im falschen Forenbereich, und ob das den TE in der Tiefe jetzt schon/noch interessiert?...)
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

Loredo

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Beta-User

Danke!

Da ich befürchte, dass der andere Thread ein Mega-Thread wird, den ich eigentlich nicht verfolgen will (rufe vorrangig immer die "Ungelesenen Antworten..." auf), daher nochmal eine kurze Antwort hier (sonst hätte ich schon vorhin dort geantwortet und andersrum zitiert):
Auch wenn es häufig mühsam sein mag, finde ich persönlich die Weiterentwicklung zentraler Logiken (und die Beibehaltung der Kompabilität) besonders wichtig (siehe die Vordiskussion zu IsWe()). Wenn du schreibst "sondern generiert daraus das Reading "DayType"", dann verursacht das bei mir ein nicht näher spezifiziertes Unbehagen... (Es impliziert, dass man mit sonstigen Logiken dann besser dort andockt.)

Wir können gerne (auch mit Rudi) darüber diskutieren, ob es Sinn macht, im Rahmen von h2we ein (!) bestimmtes Reading (vorgelagert zu state, aber bei allen in h2we angegebenen Devices identisch (!)) bei anderen als .holiday-Devices abzufragen, wenn das Sinn macht, aber das weiter aufzufächern, finde ich auf den ersten Blick nicht sooo prickelnd. Bin aber weder ein guter Programmierer, noch habe ich Erfahrung mit Softwarearchitektur, kann also sein, dass mein ungutes Bauchgefühl da völlig täuscht.

Wenn es im Rahmen von IsWe() Sinn macht, das zu diskutieren, kannst du gerne wieder zitieren und wir behandeln das in dem dortigen Thread ;) ?
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