Autor Thema: Wunsch: Initiator bei Events in Variable übergeben  (Gelesen 520 mal)

Offline gvzdus

  • Full Member
  • ***
  • Beiträge: 426
Wunsch: Initiator bei Events in Variable übergeben
« am: 10 Mai 2020, 21:45:04 »
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?
« Letzte Änderung: 11 Mai 2020, 08:21:10 von gvzdus »

Offline cs-online

  • Hero Member
  • *****
  • Beiträge: 1087
Antw:Wunsch: Initiator bei Events in Variable übergeben
« Antwort #1 am: 24 Juni 2020, 19:32:47 »
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-CFG-USB-2, HM-WLAN-Gateway, einige HM-Aktoren,  2x EBUSD an Heizung und Solar, ESP8266 am Strom-, Gas- , Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Lacrosse-Gateway und Sensoren, Signalduino, Alexa-Fhem... und alles auf einem RPI und da geht noch mehr...

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 7951
  • NIVEAu ist keine Creme...
Antw:Wunsch: Initiator bei Events in Variable übergeben
« Antwort #2 am: 24 Juni 2020, 19:35:53 »
$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
« Letzte Änderung: 24 Juni 2020, 19:41:20 von MadMax-FHEM »
FHEM PI3B+ Buster: HM-CFG-USB, 40x HM, ZWave-USB, 6x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, KODI, alexa-fhem, ...
FHEM PI2 Stretch: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, KODI, ha-bridge, ...
FHEM PI3 Buster (Test)
FHEM PI3 Stretch (Test)

Offline amenomade

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5994
Antw:Wunsch: Initiator bei Events in Variable übergeben
« Antwort #3 am: 25 Juni 2020, 00:55:41 »

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
FHEM 5.9 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus
Informativ Informativ x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10837
  • eigentlich eher "user" wie "developer"
Antw:Wunsch: Initiator bei Events in Variable übergeben
« Antwort #4 am: 25 Juni 2020, 10:35:46 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal