widgets, zeitschalturen und baukästen

[bgewehr]

@Jörg kannst Du bitte den PR mergen?

[herrmannj]

done. thnx

[Muk.s]

Hallo Zusammen,
zuerst einmal Kompliment und Danke für die bisher geleistete Arbeit hier.

Dank dem UZSU widget kann ich nun sehr komfortabel meine WeekdayTimer auch über SmartVisu bearbeiten. Doch leider bietet das widget ja (noch?) keine Möglichkeit die UZSU_WeekdayTimer mit Conditions zu verknüpfen. Deshalb helfe ich mir mit folgendem kleinen Workaround:

Die "Conditions" speichere ich 1zu1 in einem Reading (wdt_condition) und übergebe den Inhalt an die UZSU_execute()

Dazu wird das UZSU notify wie folgt erweitert:

Code Auswählen Erweitern

define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1, ReadingsVal($NAME,"wdt_condition"," ")) }

die ersten Zeilen der UZSU_execute funktion in der 99_fronthemUtils.pm entsprechend angepasst:

Code Auswählen Erweitern


sub UZSU_execute($$$)
{
  my ($device, $uzsu, $condition) = @_;


sowie der Befehl zum Erstellen der WDT:

Code Auswählen Erweitern

fhem('defmod wdt_uzsu_'.$device.' WeekdayTimer '.$device.' en '.$weekdays_part.' '.$condition);


Funktioniert bisher problemlos.

Gruß, Michael

[bgewehr]

Hallo, Michael!
Ich arbeite zusammen mit MWorion daran, die Bedingungen im UZSU Frontend editierbar zu machen.

Dein Ansatz hat einen deutlichen Nachteil, glaube ich: Du kannst nur eine Bedingung pro WDT definieren.

Das reicht vermutlich für viele Fälle, aber nicht für alle.

Deswegen wollen wir die Conditions in jeder Zeile separat pflegbar machen und in den commandstring der wdt Profile aufnehmen.

Damit kann dann jeder Schaltbefehl die gleiche oder auch andere Bedingungen haben.

Es würde helfen, wenn Du Deine Verwendung beschreiben könntest. Welche Bedingungen sind für Dich wichtig?

[Muk.s]

Stimmt, mein Ansatz erlaubt nur eine Bedingung bzw Bedingungskette pro WDT.
Das reicht, zumindest bei mir, z.Zt. in ca 90% der Fälle.
Die Conditions pro Zeile im UZSU Frontend zu verwalten ist ein guter Weg. Ideal wäre, wenn es keine vordefinierten Bedingungen gäbe, sondern individuell mittels Textfeld verwaltet werden (analog zu meinem Workaround reading). Würde für Euch Entwickler aber auch mehr Aufwand bedeuten hinsichtlich der Prüfung der Conditions auf mögliche Fehler. Vielleicht sollte man diese Möglichkeit auch nur in der Expertenansicht haben.

Zur Zeit setze ich die WDT für einfache sich wiederholende Schaltvorgänge ein, wie z.B. Licht zu bestimmten Zeiten an bzw ausschalten, aber nur wenn jemand Zuhause ist. Oder die Heizung im Arbeitszimmer hochzufahren, aber nur Mo-Fr, wenn ich ich Zuhause bin - kein Feiertag ist -keine Ferien/Urlaub sind. Standardkram halt.

Gruss,Michael

[bgewehr]

Also verwendest Du mehrere verkettete Bedingungen für eine UZSU?

Wir haben aktuell vorgesehen, drei Felder einzusetzen. Device, Komparator (< = > !=) und Wert.

Damit kann man aber keine Verkettungen machen.

Reicht der Ansatz nicht, müssen wir uns mehr einfallen lassen...

[bgewehr]

Ein weiterer Ansatz ist die Verkettung der Bedingungen in einem Dummy in fhem, dessen Wert dann für die UZSU verwendet wird.

Damit hat man sicher alle Möglichkeiten, da fhem ja darin sehr mächtig ist, Werte mit Bedingungen zu ermitteln.

In der UZSU würde dann nur der Status des einen Device abgefragt, dann reichen unsere drei Felder.

Was meint Ihr, ist das ein Plan?

[Muk.s]

Vereinzelt verwende ich schon mal mehrere verkettete Bedingungen und diese zum Teil auch noch UND|ODER verschachtelt.

Wie genau habt Ihr Euch bei den 3 Felder die Umsetzung für die Device Auswahl vorgestellt?
Wollt Ihr alle FHEM Devices in einer Liste anzeigen? Die dürfte unter Umständen ziemlich lang und 99% davon wohl auch nie benötigt werden.
Eventuell könnte man die Auswahl auf die Devices beschränken, die über ein entsprechendes Reading oder Attribut verfügen.
Auch die Auslagerung der Verkettungen in einen Dummy wäre ein gangbarer Weg.
Und wenn dann im Profimodus die Conditions auch direkt im Textfeld bearbeiten werden können, hätte man die volle Flexibilität.
   

[bgewehr]

Ehrlich gesagt hatten wir an Textfelder gedacht, nix Auswahl.

Devicename, komparator und Value als Listen zu gestalten wäre sehr fhem spezifisch und die UZSU ist für fhem UND smarthome.py.

Die drei Felder würden im Expert Bereich pro Zeile angezeigt.

Wenn ein Dummy die Verkettungslogik abbildet, muss dessen Logik in fhem bearbeitet werden, nicht in der UZSU.

Die Ansätze sind noch für beide Welten akzeptabel.

Könnt Ihr damit leben?

[Muk.s]

Textfelder sollten reichen.
Einen Vorschlag hätte ich aber noch 

Man könnte im "Device" Feld ja die Möglichkeit einfacher Verkettungen anbieten.
Verketten kann man nur 2 (oder maximal 3) Devices die den gleichen Wertetyp liefern (0|1, true|false, present|absent, usw) und es sind nur einfache Verkettungen möglich, also keine UND/ODER Verschachtelungen.
Die Eingabe könnte wie folgt aussehen:
Device1&&Device2 bzw Device1||Device2||Device3

Ich denke damit wäre ein Großteil der Verknüpfungen abgedeckt ohne jedesmal einen separaten Dummy erstellen zu müssen.

[bgewehr]

Hm. Würde bedeuten, die Inhalte der Felder parsen und interpretieren zu müssen. Ist was für Version 5, einverstanden? Erst mal beginnen...

[Muk.s]

Version 5 nicht unbedingt.

Vorschlag:
Ihr setzt die Conditions im UZSU Frontend so um wie von Euch angedacht, also 3 Textfelder.
Die Funktion für die 99_fronthemUtils zum prüfen und auswerten der Werte sowie der Erstellung des ConditionString liefere ich.
In der UZSU_execute parst ihr die 3 Werte einfach an die Funktion und bekommt den ConditionString zurückgeliefert.
Vorteil der separaten Funktion wäre, das die (Weiter)Entwicklung losgelöst von Eurem Code laufen könnte, solange an der Grundstruktur der 3 Textfelder nichts geändert wird.

[herrmannj]

Hi,

wäre es nicht besser die conditions komplett in fhem abzubilden ? Mit diesen Vorschlägen wird ja doch (mMn!) eine ganze Menge "Programmierung" in das frontend gezogen ?

Vielleicht liese sich das so lösen das man an die USZU einen (in fhem frei definierten) Satz von Möglichkeiten gibt. Also zum Beispiel "an Schultagen", "in den Ferien", "im Urlaub", "zur Weihnachtszeit", "im Sommer bei schönem Wetter" ...

Was dann "zur Weihnachtszeit" bedeutet könnte (sollte) in fhem vom user aus-programmiert werden ...

vg
joerg

[Muk.s]

Hallo Jörg,
Soviel mehr an Code sehe ich da nicht, denn auch bei Deinem Vorschlag muss das ganze ja im Frontend verarbeitet werden. Der Ansatz mit den 3 Textfelder halte ich für einen gangbaren Weg mit überschaubarem Programieraufwand. Durch die Textfelder bleibt das ganze auch flexibel und erweiterbar.
In der von mir angedachten Funktion könnte dann z.B. auch geprüft werden, ob das Device denn überhaupt existiert oder ob der Operator (eq, le, ne, <, =, >, etc) stimmt.
Gruss
Michael

[herrmannj]

Hi Michael,

ne, ich dachte daran das dass im Backend verarbeitet wird. Muss es mMn sowieso, im fe wird ja nur die setting für die Zeitsteuerung erstellt. Ausgeführt werden muss ja in fhem.

Oder missverstehe ich das ?

vg
joerg