Wunsch: Initiator bei Events in Variable übergeben

Begonnen von gvzdus, 10 Mai 2020, 21:45:04

Vorheriges Thema - Nächstes Thema

gvzdus

Bitte nicht Teeren & Federn, falls das schon längst geht: Google & Wiki habe ich bemüht.

Ich wüsste gerne bei einem Event, welches Gerät dieses ausgelöst hat
Beispiel:Eine Lampe wird eingeschaltet oder auf einen Dimmwert gesetzt. Ein notify ist auf diese Änderung subscribed. Für die Behandlung im Notify wäre es jetzt hilfreich zu wissen, wer den Stellwert der Lampe geändert hat, indem z.B. eine Variable $INITIATOR auf das ursprünglich auslösende Gerät verweist.

Anwendungsbeispiel:
Die Lampe wird von Alexa, der FHEM-Zeile, einem Dimmswitch, zwei Bewegungsmeldern und einer at-Direktive getriggert (man kann es auch einfacher fassen, aber warum?).
"Total logisch" sind nun folgende Hierarchie-Ebenen:

  • at ist ein Default der niedrigsten Priorität, wenn z.B. bei Dämmerung ein schwaches Grundleuchten eingeschaltet werden soll
  • Der Bewegungsmelder darf die Lampe einschalten, sollte sie aber nicht ausschalten, wenn sie vorher durch ein Kommando (Dimmswitch / Alexa) eingeschaltet wurde
  • Möglicherweise überlappen sich Bewegungen bei beiden Bewegungsmeldern. "Ausschalten" sollte die Lampe nur der Bewegungsmelder, bei dem die Bewegung zuletzt stoppt.
  • Den Befehlen von Switch und Alexa ist unmittelbar Folge zu leisten
Im Kern stelle ich mir vor, dass ein Dummy eine Liste der Geräte enthält, die sich z.Zt. für in der Verantwortung halten, "das Licht auszumachen". Erlischt die Bewegungsmeldung am 1. Melder, wird geprüft, ob Melder 1 der einzige in der Liste ist. Wenn ja, macht er das Licht aus. Wenn nein, löscht er sich in der Liste, denn "der Letzte macht das Licht aus". Ist er nicht in der Liste, macht er gar nichts. Ein Willenbekundungsgerät wie Schalter oder Alexa hingegen löschen die Liste, sodass die Abschaltung durch Bewegungsmelder dadurch entfällt.

Nun könnte ich für jeden Eingabekanal ein Dummy vorschalten, dass neben der Operation auf der Lampe selbst die "Wer macht das Licht aus?"-Liste manipuliert. Alexa hat also ihren Dummy für die Lampe, der Switch einen anderen, u.s.w. Einfacher wäre es, auf die Lampe ein Notify zu hängen und je nach Initiator die Logik abzubilden.

Denke ich hier verquer?

cs-online

Hallo,

ja da gibts schon was (ich meine ich hätt das auch schon mal eingesetzt), schaust du mal z.B.

https://wiki.fhem.de/wiki/Notify

nach $EVENT und $EVTPART...

Grüße

Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

MadMax-FHEM

#2
$NAME ist denke ich besser ;)

EDIT: wenn ich allerdings dein Vorhaben so lese wird dir das nicht wirklich helfen.

Weil: wenn du ein notify auf Änderung der Lampe (reagierender Aktor) machst, dann ist der "Initiator" des notify IMMER diese Lampe...

Du müsstest evtl. beim Absetzenden "Device" des Schaltbefehls ein Reading in der Lampe entsprechend setzen.

Also bei jedem set Lampe irgendwas auch immer ein setreading Lampe Initiator IchWarEs hinterher schicken ;)

EDIT: der ausführende Aktor weiß ja nicht woher der Befehl kam... (und es ist ihm letzendlich auch egal ;)  )

Gruß, Joachim
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)

amenomade

Zitat von: MadMax-FHEM am 24 Juni 2020, 19:35:53

Weil: wenn du ein notify auf Änderung der Lampe (reagierender Aktor) machst, dann ist der "Initiator" des notify IMMER diese Lampe...

Du müsstest evtl. beim Absetzenden "Device" des Schaltbefehls ein Reading in der Lampe entsprechend setzen.

Also bei jedem set Lampe irgendwas auch immer ein setreading Lampe Initiator IchWarEs hinterher schicken ;)

EDIT: der ausführende Aktor weiß ja nicht woher der Befehl kam... (und es ist ihm letzendlich auch egal ;)  )

Gruß, Joachim

Erinnert mich an etwas... ;) https://forum.fhem.de/index.php/topic,74117.msg658179.html#msg658179
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Zitat von: amenomade am 25 Juni 2020, 00:55:41
Erinnert mich an etwas... ;) https://forum.fhem.de/index.php/topic,74117.msg658179.html#msg658179
Danke, dass $SELF auch im notify-Kontext funktioniert, war mir neu, ist interessant.

Zum Rest:
Eine Art statemachine zu bauen, ist eigentlich die ursprüngliche "Kernidee" hinter DOIF, wenn ich das richtig verstanden habe. Also ein DOIF je Zieldevice, dessen Zustand sich dann eben nach dem DOIF richtet, das alle Schaltmöglichkeiten beinhaltet. Mag jeder selbst beurteilen, ob das ein guter Weg ist.

Ich nutze das jedenfalls nicht und löse solche Problemstellungen tendenziell eher dadurch, dass zentrale myUtils-routinen aus notify heraus angesprochen werden, die sich dann anhand des Auslösers die notwendigen Daten selbst zusammensuchen (teils aus setreading-Infos bzw. userAttr-Inhalten entnommen, teils mit getKeyValue).

Eine neuere, mAn. sehr interessante Möglichkeit hat justme1968 jüngst mit "combine" aufgezeigt. Siehe https://forum.fhem.de/index.php/topic,110165.msg1041882.html#msg1041882. Scheint weniger mächtig, dafür aber "durchsichtiger" zu sein als DOIF.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files