Trotz setList wird set nicht akzeptiert

[Damian]

Man könnte programmieren, dass ein set <DOIF> irgendetwas, das irgendetwas als Status schreibt und den Zustand cmd auf 0 setzt. Allerdings möchte man das vermutlich nicht, wenn setlist in Verbindung mit einem Reading eingesetzt wird.

Auf der anderen Seite, wenn man gar keinen Bezug auf das irgendetwas im DOIF haben möchte, warum sollte es dann in dem DOIF sein?

[Damian]

Ich habe mal spaßeshalber eine Version gebastelt, die alle set Befehle erlaubt ohne etwas zu tun, damit funktioniert so etwas dann:

defmod di_dd DOIF ([$SELF:"home"])\
DOELSEIF([$SELF:"away"])\
DOELSE\

attr di_dd cmdState home|away|sonstwas
attr di_dd setList away home

hier mal zum ausprobieren:

[vbs]

Also das klappt erstmal wie beschrieben.

Nochmal ein einfaches (anderes) Real-Life-Beispiel dazu:
Ich hab ein Dummy bei dem ich Heizpausen und Frostschutz für die Heizung einstellen kann:
1. Einen dummy "heatingMode", der hat setList "heatPause frostProtection normal"
2. Ein notify mit "heatingMode:.* { updateHeating($NAME, $EVENT) }", das die Funktion "updateHeating" aufruft, wenn sich heatingMode ändert

So wie ich dich verstanden habe, könnte man das jetzt als ein DOIF ungefähr so bauen:

Code Auswählen Erweitern

di_dd DOIF ([$SELF:"heatPause"]) { updateHeating($DEVIE, $EVENT) }
DOELSEIF([$SELF:"frostProtection"]) { updateHeating($DEVIE, $EVENT) }
DOELSEIF([$SELF:"normal"]) { updateHeating($DEVIE, $EVENT) }

attr di_dd cmdState heatPause|frostProtection|normal
attr di_dd setList heatPause frostProtection normal

Bin im Moment unsicher, ob ich das eleganter finde als die Variante mit zwei Devices. Mindestens etwas unschön ist mMn, dass man für jeden state einen eigenen DOIF-Zweig aufmachen muss. Vielleicht geht es ja aber auch einfacher, bin da nicht so fit mit DOIF.

Ich spinn mal etwas rum mit einer anderen Idee: das cmdState und die verschiedenen Zweige braucht man ja nur, weil das DOIF bei jedem Befehl in den state schreibt, richtig?. Was wäre denn, wenn das DOIF den state nie anfassen würde (evtl. steuerbar durch ein Attribut in der Art "dontTouchState") und man aber von außen durch die normalen set-Aufrufe auch den state setzen könnte.
Dann könnte das DOIF ungefähr so aussehen:

Code Auswählen Erweitern

di_dd DOIF ([$SELF]) { updateHeating($DEVIE, $EVENT) }
attr di_dd setList heatPause frostProtection normal
attr di_dd dontTouchState 1

Wie gesagt: ist kein Feature-Request oder so, einfach ein bisschen Spinnerei. Ich kann auch gut mit der bisherigen Variante leben.

[Damian]

Die SetList Sachen sind relativ neu im DOIF-Modul. Ellert hat es ja schon geschrieben, zunächst war die Lösung für Reading im DOIF angedacht und nicht für Stati. Wir dürfen das Konzept des Moduls nicht auf den Kopf stellen. Es arbeitet mit Zuständen und die entsprechen dem Status, daher möchte ich das Konzept an der Stelle nicht ändern.

Was ich aber noch zum Ausprobieren einbauen wollte ist folgendes Features:

Code Auswählen Erweitern

di_dd DOIF (1)
({updateHeating($DEVICE, $EVENT)})
DOELSEIF(1)
({updateHeating($DEVICE, $EVENT)})
DOELSEIF(1)
({updateHeating($DEVICE, $EVENT)})

attr di_dd cmdState heatPause|frostProtection|normal

SetList wäre in diesem Fall überflüssig, weil durch die Definition cmdState heatPause cmd_1 entspricht, frostProtection cmd_2 usw.

[Ellert]

Also das klappt erstmal wie beschrieben.

Nochmal ein einfaches (anderes) Real-Life-Beispiel dazu:
Ich hab ein Dummy bei dem ich Heizpausen und Frostschutz für die Heizung einstellen kann:
1. Einen dummy "heatingMode", der hat setList "heatPause frostProtection normal"
2. Ein notify mit "heatingMode:.* { updateHeating($NAME, $EVENT) }", das die Funktion "updateHeating" aufruft, wenn sich heatingMode ändert

So wie ich dich verstanden habe, könnte man das jetzt als ein DOIF ungefähr so bauen:

Code Auswählen Erweitern

di_dd DOIF ([$SELF:"heatPause"]) { updateHeating($DEVIE, $EVENT) }
DOELSEIF([$SELF:"frostProtection"]) { updateHeating($DEVIE, $EVENT) }
DOELSEIF([$SELF:"normal"]) { updateHeating($DEVIE, $EVENT) }

attr di_dd cmdState heatPause|frostProtection|normal
attr di_dd setList heatPause frostProtection normal

Bin im Moment unsicher, ob ich das eleganter finde als die Variante mit zwei Devices. Mindestens etwas unschön ist mMn, dass man für jeden state einen eigenen DOIF-Zweig aufmachen muss. Vielleicht geht es ja aber auch einfacher, bin da nicht so fit mit DOIF.

Ich spinn mal etwas rum mit einer anderen Idee: das cmdState und die verschiedenen Zweige braucht man ja nur, weil das DOIF bei jedem Befehl in den state schreibt, richtig?. Was wäre denn, wenn das DOIF den state nie anfassen würde (evtl. steuerbar durch ein Attribut in der Art "dontTouchState") und man aber von außen durch die normalen set-Aufrufe auch den state setzen könnte.
Dann könnte das DOIF ungefähr so aussehen:

Code Auswählen Erweitern

di_dd DOIF ([$SELF]) { updateHeating($DEVIE, $EVENT) }
attr di_dd setList heatPause frostProtection normal
attr di_dd dontTouchState 1

Wie gesagt: ist kein Feature-Request oder so, einfach ein bisschen Spinnerei. Ich kann auch gut mit der bisherigen Variante leben.

Das DOIF könnte auch so aussehen

Code Auswählen Erweitern

di_dd DOIF ([$SELF:heatingMode]) { updateHeating($DEVICE, [$SELF:heatingMode])

und die Attribute
do always

Code Auswählen Erweitern

readingList heatingMode
setList heatingMode:heatPause,frostProtection,normal
webCmd heatingMode
cmdState [$SELF:heatingMode]

Das Reading heatingMode dient als Frontendelement.
state nimmt den aktuellen Status aus dem Reading heatingMode.

Das würde in Dein Konzept nur passen, wenn der dummy "heatingMode" als Frontend-Element genutzt wurde.

Wenn der Dummy aber über eine Logik gesetzt wird (mit set), dann müsste die Logik statt set jetzt setreading verwenden. Die Attribute setList, redingsList und webCmd wären dann nicht erforderlich.

[vbs]

Code Auswählen Erweitern

cmdState [$SELF:heatingMode]
Hm, das ist ja auch interessant... ich komm aus dem Staunen gar nicht mehr raus
Ich glaub, ich würde aber gerne das normale "set" nutzen können. Das hab ich sonst vermutlich in 3 Monaten wieder vergessen, dass ich bei dem speziellen Device nur setreading verwenden darf...