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
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).
@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.
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... ::) )
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
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...)
Ich habe den noWeekEnd Vorschlag eingebaut.
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?)
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.
Hallo Rudi, hallo Beta-User,
vielen Dank, ich mache mich dann mal ans Testen.
Gruß
Alex
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
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 (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.
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?...)
Ich habe dir hier (https://forum.fhem.de/index.php/topic,101942.msg954652.html#msg954652) geantwortet.
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 ;) ?
https://forum.fhem.de/index.php/topic,98583.msg954937.html#msg954937 (https://forum.fhem.de/index.php/topic,98583.msg954937.html#msg954937)
Hallo Rudi,
ich bin endlich mal dazu gekommen das noWeekEnd Feature zu testen.
Im großen und ganzen funktioniert es.
Ich habe aber einen Sonderfall entdeckt:
am 27.07 habe ich einen Arbeitssamstag, aber auch gleichzeitig Urlaub.
In diesem Fall gewinnt noWeekEnd und {IsWe("tomorrow")} ergibt 0, hier sollte aber das normale holiday device die prio haben.
noWeekEnd.holiday:
Internals:
FUUID 5d1b4e6f-f33f-69d4-de29-fa916742814858c8
HOLIDAYFILE ./FHEM/holiday/noWeekEnd.holiday
NAME noWeekEnd
NR 175
READONLY 1
STATE none
TRIGGERTIME 1564156802.70919
TYPE holiday
Helper:
DBLOG:
state:
logdb:
TIME 1564134616.72061
VALUE none
tomorrow:
logdb:
TIME 1564134616.72061
VALUE Einarbeiten U
yesterday:
logdb:
TIME 1564134616.72061
VALUE none
READINGS:
2019-07-26 17:50:16 state none
2019-07-26 17:50:16 tomorrow Einarbeiten U
2019-07-26 17:50:16 yesterday none
Attributes:
group Termine
CC.holiday:
Internals:
FUUID 5d1b4dd2-f33f-69d4-15ff-9997b20b2a3d23b8
HOLIDAYFILE ./FHEM/holiday/CC.holiday
NAME CC
NR 174
READONLY 1
STATE none
TRIGGERTIME 1564156802.6899
TYPE holiday
Helper:
DBLOG:
state:
logdb:
TIME 1564134616.7066
VALUE none
tomorrow:
logdb:
TIME 1564134616.7066
VALUE Urlaub CC
yesterday:
logdb:
TIME 1564134616.7066
VALUE none
READINGS:
2019-07-26 17:50:16 state none
2019-07-26 17:50:16 tomorrow Urlaub CC
2019-07-26 17:50:16 yesterday none
Attributes:
group Termine
global:
Internals:
DEF no definition
FD 3
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2019-KW29.log
logfile ./log/fhem-%Y-KW%U.log
Helper:
DBLOG:
state:
logdb:
TIME 1564134718.13114
VALUE ATTR global holiday2we CC,noWeekEnd
Attributes:
autoload_undefined_devices 1
autosave 0
backup_before_update 1
configfile fhem.cfg
group System
holiday2we CC,noWeekEnd
logfile ./log/fhem-%Y-KW%U.log
modpath .
motd 1
room System
statefile ./log/fhem.save
updateInBackground 1
verbose 3
version fhem.pl:19805/2019-07-09
Gruß
Alex
Works as designed:
Zitat von: Beta-User am 26 Juni 2019, 21:18:47
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).
In dem Fall mußt du dafür sorgen, dass der Sa. aus noWeekEnd genommen wird, eine Änderung der Logik ist m.E. nicht sinnvoll. Denn sonst müßte man wissen, welcher der anderen h2we-Devices "höherrangig" zu noWeekEnd sein soll.
OK, danke für die Rückmeldung.
Gruß
Alex