gelöst - readingsProxy Impulse auswerten

Begonnen von tfriedrich85, 31 Juli 2020, 12:14:34

Vorheriges Thema - Nächstes Thema

tfriedrich85

Hallo zusammen,

meine Frage bezieht sich auf readingsProxys, ich habe viele Eingänge die ich über readingsProxys in Fhem auswerten kann, das funktioniert auch prächtig.
Beispiel:
Lichtschalter 1x Drücken --> Licht/Lichtszene an.

Frage: Ich hätte gerne die Möglichkeiten: Wenn Lichtschalter 1 x gedrückt dann Option 1 wenn Lichtschalter 2 x gedrückt dann Option 2.
Aktuell mache ich das mit Modul lightsczene, damit schalte ich bei jedem Tastendruck in die nächste Lichtszene.

Ich würde aber gerne unabhängig von der Lichtszene jedesmal beim 1 x Betätigen des Schalters zu Option 1 und beim doppelt drücken zu Option 2 kommen, gibts dazu Ideen?

Vielen Dank schonmal im Voraus.
hier das Reading
Internals:
   DEF        InputE3b:Port6
   DEVICE     InputE3b
   FUUID      5cf6c115-f33f-aed9-02d6-0bbcdcec555084e0
   NAME       E3b.6
   NOTIFYDEV  InputE3b,global
   NR         185
   NTFY_ORDER 50-E3b.6
   READING    Port6
   STATE      off
   TYPE       readingsProxy
   CONTENT:
     InputE3b   1
   READINGS:
     2020-07-31 04:38:44   state           off
Attributes:
   alias      Taster_Schlafzimmer rechts
   group      Inputs
   icon       Shutdown
   room       Schlafzimmer,i2c

MadMax-FHEM

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Evtl. ist auch sequence ein Ansatz (mit trigger partial).

Bitte aber bei beidem (auch der hier vermutlich passenderen "Taster"-Lösung) beachten, dass readingsProxy keine Events wirft (evtl. doch, wenn man "event-on-update-reading .*" setzt), und du daher besser das Ausgangsevent überwachen solltest.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

tfriedrich85

Zitat von: Beta-User am 31 Juli 2020, 12:35:39
Evtl. ist auch sequence ein Ansatz (mit trigger partial).

Bitte aber bei beidem (auch der hier vermutlich passenderen "Taster"-Lösung) beachten, dass readingsProxy keine Events wirft (evtl. doch, wenn man "event-on-update-reading .*" setzt), und du daher besser das Ausgangsevent überwachen solltest.

Danke das war der richtige Hinweis!

Ich konnte das mit Sequence lösen.

DEF        E3c.7:on 00:01 E3c.7:on
und dem anschließende notify
DEF seq_AZ:trigger set ... on

Danke

tfriedrich85

Mit sequenz funktiert das Auswerten der Reading proxys zwar, allerdings ergibt sich ein Problem:

Wenn man bei einem einmaligen Tastendruck Aktion 1 erfolgen soll und bei doppeltem Tastendruck Aktion 2 wird natürlich immer Aktion 1 vor Aktion 2 ausgeführt. Weil ein einmaliger Tastendruck immer in einem doppelten Tastendruck enthalten ist :-)

Wie kann man das umgehen? Gibts die möglichkeit immer erst nach 2 Sekunden auszuwerten, wieviele Tastimpulse es gab?


Beta-User

Du scheinst mehrere sequence-Devices und/oder notify zu haben, die auf den Taster (wohl eher nicht auf den readingsProxy?) hören.

Da ist es geschickter, nur _eine_ sequence zu definieren und "triggerPartial" zu setzen und dann deren Events auszuwerten. Siehe auch die Beispiele in der commandref zu sequence, da wird das genau auch behandelt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

tfriedrich85

Danke - Beta-User! hat genau so funktioniert. Die Comandref hilft.