widgets, zeitschalturen und baukästen

bgewehr · 26 Juli 2015, 14:18:40

Keine Logik im Frontend lautet die Devise, nur ein- und Ausgaben.

Damit bleibt das Frontend neutral und kann in fhem und Smarthome.py ohne Änderung verwendet werden.

Ich möchte darauf hinweisen, dass eine separate Funktion eher hinderlich ist, weil die Bildung des commandstrings pro Zeile den Befehl zum Schalten beinhalten muss, wie hier diskutiert:
http://forum.fhem.de/index.php/topic,33868.msg315531.html#msg315531

Das passiert also mitten in der UZSU_execute, da sehe ich es als nicht förderlich an, noch in eine andere Funktion zu springen...

Muk.s · 26 Juli 2015, 14:43:14

Hi,
Die komplette Logik natürlich im Backend. Vielleicht habe ich mich da etwas missverständlich ausgedrückt.
Wenn ich das richtig sehe, erfolgt die Bildung des commandstring doch in der UZSU_execute.
Ich sehe auf den ersten Blick jetzt mal keinen Grund den Conditionsteil in einer separaten Funktion abzuarbeiten.
Bin im Moment unterwegs und das tippen auf dem Smartphone ist in meinem fortgeschrittenen Alter doch etwas mühselig

. Schreibe später mal wie ich mir das im Detail vorstelle.
Gruß
Michael

bgewehr · 26 Juli 2015, 15:05:55

Ok, ich schau es mir dann an! Vielleicht finden wir einen simplen, guten Weg!

igami · 26 Juli 2015, 17:59:47

push. Oder falscher Thread?

Zitat von: igami am 16 Juli 2015, 07:45:18
Hallo zusammen,

für meine Wochenprogramme möchte ich die uzsu verweden mit folgenden Einstellmöglichkeiten:
uzsuSelect,Wochentage
uzsuDropDown,Uhrzeit in 15 Minuten Abstufungen
uzssuToggle,Tag,Nacht
Mehrere Einträge

Bekomme ich das mit dem uzsu so hin? Habe nun schon einiges ausprobiert, im Prinzip müsste ja nur bei uzsu das enable,disable gemappt werden und die Uhrzeit verfeinert.

Grüße
igami

bgewehr · 26 Juli 2015, 19:03:22

Hallo, Igami,

wenn es den anderen genauso geht, wie mir, dann wirst Du deswegen keine Antwort bekommen haben, weil die Frage einfach nicht verstanden wird.

Versuch doch nochmal etwas ausführlicher zu beschreiben, was Du erreichen möchtest, dann wird es sicher auch eine Angwort geben.

Muk.s · 26 Juli 2015, 20:06:02

Hallo Bgewehr,

möglicherweise habe ich ja etwas übersehen aber mal eine blöde Frage: Hast Du denn schon mal grundsätzlich getestet ob der WDT mit unterschiedlichen Bedingungen für die einzelnen Regeln umgehen kann? Aus der CommandRef geht das nämlich nicht hervor.

Sowas wie hier funktioniert:

Code Auswählen


dm.test.uzsu en   MO,TU,WE,TH,FR|08:30|off 
MO,TU,WE,TH,FR|{sunrise_abs("REAL",-3600,"04:45","05:00")}|on 
SA,SU|{sunrise_abs("REAL",3600,"07:00","08:00")}|on SA,SU|09:30|off 
MO,TU,WE,TH,FR,SA,SU|02:30|off 
MO,TU,WE,TH,FR,SA,SU|17:00|on { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }

Wohingegen dies hier Fehler produziert

Code Auswählen


dm.test.uzsu en   MO,TU,WE,TH,FR|08:30|off 
MO,TU,WE,TH,FR|{sunrise_abs("REAL",-3600,"04:45","05:00")}|on 
SA,SU|{sunrise_abs("REAL",3600,"07:00","08:00")}|on 
SA,SU|09:30|off MO,TU,WE,TH,FR,SA,SU|02:30|off { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) } 
MO,TU,WE,TH,FR,SA,SU|17:00|on { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }

Gruss
Michael

bgewehr · 26 Juli 2015, 20:44:08

@Michael: kannst Du diese Frage mal an Dietmar63 in dem anderen Thread stellen? Er ist der WDT Experte...

Muk.s · 27 Juli 2015, 00:09:33

@bgewehr: Damit dies hier funktioniert:

ZitatDamit kann dann jeder Schaltbefehl die gleiche oder auch andere Bedingungen haben

müßte der WDT unterschiedlichen Bedingungen für die einzelnen Regeln zulassen.
So wie ich es sehe bietet das WeekdayTimer Modul diese Möglichkeit (derzeit) aber nicht.

Anfrage an Dietmar zur Klärung ist raus, zu mehr hat die Zeit heute leider nicht mehr gereicht.

herrmannj · 27 Juli 2015, 08:51:34

vielleicht macht es doch Sinn ein dediziertes modul zu schreiben ?

vg
joerg

dev0 · 27 Juli 2015, 09:12:27

Zitat von: Muk.s am 26 Juli 2015, 20:06:02
Code Auswählen Erweitern
SA,SU|09:30|off MO,TU,WE,TH,FR,SA,SU|02:30|off { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) } MO,TU,WE,TH,FR,SA,SU|17:00|on { fhem("set @ %") if( Value("Ferientag") eq"1" && Value("Urlaub") eq "1")) }

Da ist aber auch jeweils eine runde schließende Klammer zuviel...

Muk.s · 27 Juli 2015, 12:12:48

Zitat von: dev0 am 27 Juli 2015, 09:12:27
Da ist aber auch jeweils eine runde schließende Klammer zuviel...

Stimmt, Tippfehler

Aber auch ohne funktioniert es nicht wie von Dietmar bestätigt:

ZitatUnterschiedliche Bedingungen sind nicht möglich

http://forum.fhem.de/index.php/topic,33868.msg316538.html#msg316538

Damit die UZSU trotzdem mit unterschiedlichen Bedingungen funktioniert, müßte man also entweder Dietmar "nötigen" das Modul entsprechend anzupassen oder seperate UZSU_WDT definieren wenn ein UZSU Schaltbefehl eigene Bedingungen enthält.

Joerg: Ein dediziertes Modul macht natürlich unabhängig(er) und hätte den Vorteil, daß das UZSU widget direkt mit dem Modul kommunizieren könnte, aber braucht es das wirklich?
Im Grunde genommen wäre es ja nur ein etwas "aufgebohrtes" WeekdayTimer modul. Vielleicht wäre Dietmar ja auch bereit sein Modul etwas anzupassen.

bgewehr · 27 Juli 2015, 15:36:54

Mein workaround ist ein wdt pro Profile. Das ist einfach und sicher. Da der Nutzer damit im Backend gar nichts zu tun hat, spricht meiner Ansicht nach nichts dagegen.

Wenn der WDT sich weiterentwickelt, kann man die Strategie jederzeit ändern.

Ich würde nicht einen zweiten WDT entwickeln, wenn es mit fast null Aufwand auch mit diesem geht.

Was meint Ihr?

Muk.s · 27 Juli 2015, 17:20:56

ZitatMein workaround ist ein wdt pro Profile.

Vielleicht könnte man das wie folgt umsetzen: Zusätzlich zu den Conditions pro Schaltbefehl gibt es auch eine globale Condition. Im UZSU widget gibt es dafür einen zusätzlichen Parameter mit dem man festlegt ob Conditions pro Schaltbefehl oder eine (einzige) globale Condition im Frontend angezeigt wird. Bei Conditions pro Schaltbefehl wird ein wdt pro Zeile erstellt, wohingegen bei der globalen Condition nur ein wdt erstellt wird.

Wäre das ein gangbarer Weg?

bgewehr · 27 Juli 2015, 17:25:46

Ich suche immer noch nach sinnvollen Anwendungsfällen, bei denen eine globale Regel sinnvoll ist, helft Ihr mir mal mit Euren Beispielen?

Urlaub, Wochenende und Feiertag sind doch mit $we und !$we ausreichend abgedeckt, oder nicht?

Muk.s · 27 Juli 2015, 21:33:30

Dann mache ich mal den Anfang:
Ich steuere z.B. über einen wdt die Temperatur im Arbeitszimmer, aber nur wenn ich zu Hause arbeite (homeoffice == 1)
HZ_Arbeitszimmer Mo-Fr|07:00|Comfort Mo-Fr|16:00|Auto (Value("Homeoffice") eq "1")

Bei einem wdt pro UZSU profil wären das zwei wdt Einträge in der fhem.cfg. Damit könnte man noch leben.

Hier wären es aber schon 6:
dm.FBDECT_16.uzsu en MO,TU,WE,TH,FR,SA,SU|02:30|off MO,TU,WE,TH,FR|08:30|off SA,SU|10:00|off MO,TU,WE,TH,FR|{sunrise_abs("REAL",-7200,"04:15","05:15")}|on MO,TU,WE,TH,FR,SA,SU|{sunset_abs("REAL",-3600,"15:00","16:30")}|on SA,SU|{sunrise_abs("REAL",-3600,"06:00","07:00")}|on { fhem("set FBDECT_16 %") if( Value("VirtuellerBewohner") eq "active" ) }