Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

IT- (Hand-) Sender: Zusätzlicher Status möglich? Wer ist zuständig?

Begonnen von M_I_B, 17 November 2016, 18:16:12

Vorheriges Thema - Nächstes Thema

M_I_B

Moin Kinnaz,

wäre es irgendwie möglich, den IT- Sendern irgendwie zu den Stati "on" und "off" einen dritten Status, z.B. "0" zu verpassen, welcher sich nur manuell resp. Ablaufgesteuert setzen lässt? Wer wäre denn dafür zuständig?

Hintergrund ist z.B. die Steuerung einen (HM-) Dimmers. Im Moment muss man mehrfache "on" resp. "off" Tastendrücke ziemlich umständlich über die Zeit des Events rausfrickeln. Das macht nicht nur den Code recht unleserlich, sondern birgt auch massiv Stolpersteine und Fehlerquellen. Wenn jetzt aber z.B. per DOIF der Status auf "0" an Stelle von "on" oder "off" gesetzt werden könnte, nachdem ein "on" oder off" Event aufgeschlagen ist, könnte man die Sache enorm vereinfachen... Also quasi z.B. so:

define it2dimm DOIF ([CH01] eq "on") (set HM_dimmer up, set CH01 0) \
DOELSEIF ([CH01] eq "off") (set HM_dimmer down, set CH01 0)
attr it2dimm do always


Das Ganze wäre auch zu allen bisherigen Codes kompatibel, da ein dritter Status bisher nicht abgefragt werden konnte

Ellert


M_I_B

... öhhh, bei IT auch? Ok, das wäre mir jetzt neu; wieder was gelernt... ty...

Aber wäre es nicht schöner, wenn das nativ möglich wäre?


M_I_B

... die Liste kannte ich noch nicht; gleich mal in die FAV's gelegt... besser is dat ;)

aBär der Forenbereich ist damit ja schon korrekt...

EDIT:
Ich habe das mal mit setreading zusammen gebaut. Das hat allerdings zwei Nachteile. Zum einen unterdrückt ein "setreading" in einem zusammengesetzten Befehlsteil z.B. eines DOIF den Event des vorhergehenden "set", was zum anderen und in der Folge an jeder Stelle ein "sleep x" benötigt... Also bei z.B. ...

DOIF ([HM6TA2_2:?Long.*] and [HM2DI1_1:pct] >= 60) (set HM2DI1_1 100, setreading HM6TA2_2 state 0)

... unterdrückt das setreading den davor auszuführenden "set HM..." Befehl. Das lässt sich wiederum nur mit einem Nickerchen dazwischen wie ...

DOIF ([HM6TA2_2:?Long.*] and [HM2DI1_1:pct] >= 60) (set HM2DI1_1 100, sleep 0.1, setreading HM6TA2_2 state 0)

... beseitigen.

In Hinblick auf das letzte Beispiel wäre ein nativer Status "0" (TriState- Modus) im Grunde bei allen sendenden Devices, egal ob HM oder IT oder ... ziemlich schlau (meine Meinung). Dann wäre das obige Beispiel ganz einfach mit ...

DOIF ([HM6TA2_2:?Long.*] and [HM2DI1_1:pct] >= 60) (set HM2DI1_1 100, set HM6TA2_2 0)

... erschlagen, ohne ein sleep und ohne unterdrückten Events ...

EDIT2: ... und wenn die "0" irgendwo mit bereits vorhandenen Stati kollidiert, wäre ja auch einheitlich für alle Befehlsgeber "stb", "sby" oder "sb" oder ... (für StandBy) denkbar... oder was anderes, was in dem Zusammenhang nie vorkommt und die Kompatibilität zu bestehenden Codes nicht tangiert ...