FHEM - Hausautomations-Systeme > Unterstützende Dienste

$we und IsWe() liefert immer 1

<< < (2/3) > >>

Beta-User:

--- Zitat von: rudolfkoenig am 01 Oktober 2021, 15:19:55 ---Ich kenne Calendar nicht.
Was bedeutet "triggered"?
Wuerde es helfen, wenn IsWe neben none auf triggered prueft?

--- Ende Zitat ---
"triggered" ist mAn. unspezifisch, v.a., wenn es ein "allgemeiner Kalender ist, in dem "alles mögliche" steht:

--- Zitat ---Wenn der Kalendar neu geladen oder aktualisiert oder eine Alarm-, Start- oder Endzeit erreicht wurde, wird ein FHEM-Event erzeugt: triggered

 Man kann sich darauf verlassen, dass alle Readings des Kalenders in einem konsistenten und aktuellen Zustand befinden, wenn dieses Event empfangen wird.
--- Ende Zitat ---

Wir hatten eine ähnliche Diskussion mal zu den IsWe()-Entwicklungszeiten. Da war die Frage aber, ob man neben/anstatt "state" noch auf ein anderes Reading für "today" schauen sollte (wenn es da ist). Damit könnte man uU. über einen userReadings-Mechanismus in Calendar dann Code anflanschen, der das passend befüllt. Im Ergebnis ist es aber mAn. dann auch nicht komplizierter, das in einen passenden dummy zu schreiben, oder eben meinen Code für die Generierung von holiday-Files zu übernehmen (der ist generisch, "muell" wird z.B. dann auch nicht für h2we verwendet und dient nur zur Anzeige).
IsWe() sollte schnell bleiben, von daher finde ich zumindest heute deine ablehnende Haltung gegen was anderes wie "state" völlig berechtigt.

rudolfkoenig:
Verstehe ich richtg, IsWe() bzw $we hat (ueber holiday2we) fuer Calendar nie funktioniert?

Hab gedacht, dass diese (mir unbekannte) Kombination durch eine Aenderung in Calendar Modul kaputtgegangen ist, da ich IsWe seit zwei Jahren nicht angefasst habe.

betateilchen:

--- Zitat von: Nighthawk am 01 Oktober 2021, 14:54:59 ---Was mich wundert, früher (vor ~1,5-2 Jahren) hat es bei mir problemlos funktioniert (ich war längere Zeit im Ausland).

--- Ende Zitat ---

Das Calendar Modul wurde vor einiger Zeit komplett umgebaut - vielleicht war das während Deiner Abwesenheit. Dabei haben sich eine ganze Reihe grundlegender Mechanismen geändert.

Ich kann mich irren, aber ich vermute, IsWe() ist primär für die Verwendung mit holiday devices gedacht und nicht generisch für Calendar-devices.

Fakt ist: eine Abfrage auf ein CalendarDevice zum Beispiel in der Form "get <calDev> tomorrow" wird nicht das Ergebnis liefern, das Du erwartest, sondern eine Fehlermeldung.


--- Code: ---Unknown argument tomorrow, choose one of update:noArg reload:noArg events find text full summary location description categories alarm start end vcalendar:noArg vevents:noArg
--- Ende Code ---

betateilchen:

--- Zitat von: rudolfkoenig am 01 Oktober 2021, 15:44:38 ---Verstehe ich richtg, IsWe() bzw $we hat (ueber holiday2we) fuer Calendar nie funktioniert?

--- Ende Zitat ---

Richtig verstanden.

Beta-User:

--- Zitat von: betateilchen am 01 Oktober 2021, 15:48:49 ---Ich kann mich irren, aber ich vermute, IsWe() ist primär für die Verwendung mit holiday devices gedacht und nicht generisch für Calendar-devices.

--- Ende Zitat ---
Jein. $we und h2we hatten ganz klar schon immer holiday im Blick und nie Calendar oder sonst was. Es kann aber im Prinzip jeder TYPE abgefragt werden, es werden einfach die jeweiligen Readings für "gestern bis morgen" ausgelesen, und alles, was nicht "none" ist, ist halt "1". Da aber Calendar "state" (für "heute") anders versteht, klappt das weder da, noch bei anderen TYPE, die "state" in ihrem eigenen Sinne interpretieren bzw. befüllen.

IsWe() macht nur die "alte Variable" $we systemweit einheitlich verfügbar.

MAn. macht es auch keinen Sinn, Calendar irgendwie für h2we/IsWe() aufzubohren, weil da "alles mögliche" drinstehen kann und man die Daten sowieso irgendwie aufbereiten muss.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln