Erledigt: Fhem mitteilen dass kein Wochenende ist

[rischbiter123]

Moin @all,

Meine Frage hat folgenden Sinn:
Ich habe mehrere DOIF und WeekdayTimer, die am WE anders schalten, als unter der Woche. Nun kommt es aber öfters mal vor, dass ich Sa oder So arbeiten muss. Ich könnte zwar einen Dummy mit arbeit/frei setzen und den in die Schaltbedingungen mit reinnehmen, aber es wäre schöner, wenn ich Fhem sagen könnte, der Tag ist kein WE.
Gibt es da eine Möglichkeit, oder muß ich tatsächlich alle Devices bearbeiten?

LG

Andreas

[Damian]

Stichwort indirekte Wochentagangaben beim DOIF.

Durch Ändern des Inhalts eines Dummys der als Wochentagangabe definiert ist, kann man das Schaltverhalten ändern. Siehe Beispiel mit myweekday hier: https://fhem.de/commandref_DE.html#DOIF_Wochentagsteuerung

[rischbiter123]

Moin,

also tatsächlich das, was ich befürchtet hatte. Jedes DOIF mit Wochentagssteuerung bearbeiten. Danke für den Tip. Man müsste die Hilfe mal als PDF ausdrucken, um sie Abends auf der Couch mal in Ruhe durchzulesen.
Oder mal ein Webseminar. 

LG

Andreas

[Beta-User]

Bin da anderer Meinung:

Man sollte nicht für alles irgend ein Beispiel in einer übermächtigen Doku haben, die selbst die Experten kaum verstehen, sondern "ähnlich wie $we" für solche Abfragen eine globale Funktion bereitstellen, die man von überall her abfragen kann dahingehend, ob gestern, heute oder morgen holiday ist (unabhängig vom Wochentag). Von mir aus gerne mit einem oder mehreren "Negativjoker".

Ansonsten kann WeekdayTimer das nicht ohne weiteres, um den Teil der Frage zu beantworten; der geht von $we=0,6 aus _und_ der Abfrage von holiday2we.

@damian: Du darfst da gerne die Initiative ergreifen, sollte jetzt ja klar sein, wie es ginge .

[pcbastler]

Wäre evtl. auch ein anderer Ansatz denkbar?
Bei mir ist z.B.
Arbeit = abwesend  --> Heizung auf 16°C
HomeOffice = anwesend --> Heizung auf 21°C

Somit ist man nicht auf feste Wochentage beschränkt.

[nils_]

Wäre evtl. auch ein anderer Ansatz denkbar?
Bei mir ist z.B.
Arbeit = abwesend  --> Heizung auf 16°C
HomeOffice = anwesend --> Heizung auf 21°C

Somit ist man nicht auf feste Wochentage beschränkt.

grundsätzlich ist das möglich....

der geht von $we=0,6 aus _und_ der Abfrage von holiday2we.

bedeutet die Wochentage (Samstag/Sonntag) plus (!!!) was in den holiday2we devices drin steht, wird von der IsWe(...)-Funktionalität berücksichtigt.

für deine anforderung (homeoffice, arbeit) wäre eine _eigene_ auswertun nötig, wenn du auch am WE unterwegs bist.
oder du bittest rudi, das er was einbaut in IsWe(...) um die Samstage und Sonntage zu ignorieren und nur holiday2we auszuwerten.

[Beta-User]

bedeutet die Wochentage (Samstag/Sonntag) plus (!!!) was in den holiday2we devices drin steht, wird von der IsWe(...)-Funktionalität berücksichtigt.

Korrekt, das ist die Funktionsweise bei IsWe(), die neuerdings intern von fhem.pl aufgerufen wird, wenn jemand in Perl-Code $we abfragt. Aber da diese Funktion bisher nicht zentral für die Abfrage durch Module bereitstand, gibt es einige separate Implementierungen des Themas. Nach meiner Kenntnis nutzen bisher nur WeekdayTimer und AutoShuttersControl den neuen Mechanismus.
Aber der Rückgabewert von $we ist natürlich weiter derselbe (genauer: es sei denn, man hatte stateFormat bei den in holiday2we eingetragenen Devices verwendet; da haben wir in dem Zusammenhang auch was "modernisiert").

für deine anforderung (homeoffice, arbeit) wäre eine _eigene_ auswertun nötig, wenn du auch am WE unterwegs bist.
oder du bittest rudi, das er was einbaut in IsWe(...) um die Samstage und Sonntage zu ignorieren und nur holiday2we auszuwerten.

Das in IsWe() einzubauen, wurde mit einiger Absicht verworfen, diese Funktion soll v.a. schnell sein und rückwärtskompatibel.
Wenn, dann bau' eine eigene IsHoliday().
Sollte nicht sooo schwer sein, einfach den Code aus fhem.pl für IsWe() holen, die Wochentagsauswertung vorneweg ausbauen und das ganze in MyUtils verpacken, fertig.

Wenn ich dazu komme, poste ich am WE mal was dazu.

Ändert aber nichts daran, dass WeekdayTimer das dann immer noch nicht "ohne weiteres" verarbeiten kann, und du bei Schichtarbeit dann sinnvollerweise vorneweg erst noch die Negativprüfung bräuchtest, ob du arbeitest, obwohl grade Ostern ist.

[Wuppi68]

ich würde z.B. in einer 99_utils.pm die IsWe Funktion kapseln/"überschreiben" und dort die Sonderbehandlung durchzuführen
hätte den charmanten Vorteil auch von den Updates von (original) IsWe zu profitieren

[rischbiter123]

Moin,

ich wollte eigentlich keine Grundsatzdiskussion lostreten. Meine Überlegung war eigentlich nur, da es ja möglich ist, Fhem z.B. durch einen Eintrag in der Hollidaydatei mitzuteilen, dass ein F(r)eiertag vorliegt, obwohl Wochentag, es evtl. auch die -von mir nur noch nicht entdeckte- entgegengesetzte Möglichkeit gibt.

Ich werde mir am WE dann jetzt einfach die Arbeit machen, die entsprechenden DOIF zu erweitern und die relevanten WeekdayTimer zu ersetzen.

LG

Andreas

[Damian]

Moin,

also tatsächlich das, was ich befürchtet hatte. Jedes DOIF mit Wochentagssteuerung bearbeiten. Danke für den Tip. Man müsste die Hilfe mal als PDF ausdrucken, um sie Abends auf der Couch mal in Ruhe durchzulesen.
Oder mal ein Webseminar. 

LG

Andreas

Ich halte es für keine gute Idee grundsätzlich Wochenende zu nicht Wochenende systemweit umzudefinieren, womöglich gibt es auch Definitionen, die weiterhin die "echte" Wochenende-Definition benötigen. Es wäre vielmehr klug gewesen, die Stellen, wo die Übersteuerung stattfinden soll, bereits bei der Definition entsprechend konzeptionell vorzusehen. Beim DOIF z. B.:

aus z. B. [08:00|8] schalten an Arbeitstagen

macht man eine indirekte Wochentagangabe über einen Dummy (könnte auch ein Reading sein)

[08:00|[arbeitstag]]

mit set arbeitstag 8 wird wie üblich um 08:00 Uhr von Mo bis Fr  geschaltet

mit set arbeitstag 7 wäre die Übersteuerung des Wochenendes/Feiertags zum Arbeitstag

mit set arbeitstag 78 wird jeden Tag geschaltet

Dann kannst du die Sache erweitern, indem du z. B. im Kalender (cal) die Information, ob du arbeiten musst oder nicht ablegst und abhängig von dieser Information deinen Dummy arbeitstag  entsprechend belegst.

Natürlich kannst du auch in Perl eigene Funktionen programmieren (z. B. IsMyWe) die du auswerten kannst:

z. B.

([08:00] and !IsMyWe)

[rischbiter123]

Moin,

so habe ich es jetzt auch vor. Nur zum Zeitpunkt der ursprünglichen Programmierung war für mich WE noch WE. Das hat sich erst vor kurzem geändert, dass ich auch mal Sa oder So arbeiten muss. Und, wie schon geschrieben, hatte ich einfach gehofft, mir das Umprogrammieren sparen zu können.

LG

Andreas

[Beta-User]

Moin,

ungetestet mal code für myUtils, um das mit Leben zu füllen:

Code Auswählen Erweitern


sub
myIsHoliday(;$$) {
  my ($when,$negativeLookup) = @_;
  my $ret =1;
  if(defined($negativeLookup)) {
    my $b = ReadingsVal($negativeLookup, $when, 0);
    return 0 if($b && $b ne "none");;
  }
  return IsWe($when,8);
}


Sollte ermöglichen, dass man zum einen "nur" einen Wahrheitswert zurückbekommt, wenn ein holiday2we-Device einen Treffer meldet (optionale Abfrage von "yesterday" oder "tomorrow", sonst für heute = jeweils das Reading "state").

Die zweite kann zusätzlich einen Tag fest zum Arbeitstag (wieder für gestern bis morgen) definieren, wenn am optionalen, als 2. Parameter definierten Device das betreffende Reading vorhanden ist und nicht "none".

Was das "Grundsätzliche" angeht:
Es ist erfahrungsgemäß aus Usersicht irritierend, wenn unterschiedliche Module auf (scheinbar) dieselbe Angabe ($we) unterschiedlich reagieren. Daher bin ich der Überzeugung, dass man solche Funktionen oder Abfragen (zumindest die IsHoliday()) besser allgemein zur Verfügung stellen sollte und ggf. Entwickler, die für sowas Bedarf sehen, entsprechende Veränderungen im generellen Code anstoßen sollten. Da haben manche Entwickler aber scheinbar andere Vorstellungen.

Sonst hat man genau wieder die Situation wie neulich, dass verschiedene Module bei Änderungen anzufassen sind, obwohl die Anpassung an einer Stelle an sich genügt hätte, wenn den nur der betreffende Code bereits zentral anzusteuern gewesen wäre...

EDIT: Code geändert

[nils_]

ich kann es gerade nicht testen, aber was passiert denn bei der IsWe-Sub (aus fhem.pl https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L5906 ), wenn man die so aufruft

Code Auswählen Erweitern

IsWe("today", 99);

ist das zulässig mit den 2 Argumenten??

wenn ich den code da richtig verstehe (vermutlich ist das schon der fehler ), dann sollte damit die tages-abfrage immer fehlschlagen, weil wday = 99.
und dann wären einzig und allein einträge in holiday2we dafür verantwortlich ob $we nun 1 oder 0 ist.

[Beta-User]

ist das zulässig mit den 2 Argumenten??

Jup, Code richtig interpretiert!

Wie cool ist das denn...

wenn ich den code da richtig verstehe (vermutlich ist das schon der fehler ), dann sollte damit die tages-abfrage immer fehlschlagen, weil wday = 99.
und dann wären einzig und allein einträge in holiday2we dafür verantwortlich ob $we nun 1 oder 0 ist.

Ja. Werde meinen Vorpost editieren, dann bliebt davon nur der negative lookup übrig...

[nils_]

Ja. Werde meinen Vorpost editieren, dann bliebt davon nur der negative lookup übrig...

nur zum verständnis: negativelookup bedeutet, das egal was holiday2we sagt, we oder nicht, es wird "übersteuert".
also in einem dummy (befüllt durch calender/notify/at/.....) steht das ich arbeiten muss -> bin also weg, obwohl weihnachten und ostern und urlaub auch an diesem Tag ist


ich glaub dann passt dein code erstmal so.
ohne ein "noHoliday" device und/oder steuerbare verknüpfungslogik der holidays wüsste ich keine andere lösung.