Autor Thema: notify anhand von einen Attribut Triggern  (Gelesen 307 mal)

Offline dulan_menace

  • New Member
  • *
  • Beiträge: 11
notify anhand von einen Attribut Triggern
« am: 03 November 2018, 17:55:07 »
Hallo,

ich würde gerne bei unterschiedlichen Geräten automatisiert ein UserReading Namens 'TRIGGER' befühlen...
aktuell hab ich bei meinen notify als Trigger jeden Device einzelln trinnen...
define TRIGGER_NOTIFY notify (DEVICE_1|DEVICE_2|DEVICE_3):.*

jedes Gerät hätte aber auch ein UserAttribut 'ATTR_TRIGGER_DEVICE' welches den Wert TRUE hat...

nun würde ich gerne das notify so umbauen das ich nur das Attribut hinterlegen muss bei einen neuen DEVICE und nicht das notify ändern muss...
vorgestellt hätte ich es mir so, was jedoch leider nicht funktioniert...
define TRIGGER_NOTIFY notify (a:ATTR_TRIGGER_DEVICE=TRUE):.*\

mein Test notify sieht at Time so aus....
also das Gerät wo das Attribut ATTR_TRIGGER_DEVICE den Wert TRUE hat soll in einen Gerät das Reading TRIGGER mit den Namen des TriggerObjektes beschreiben wenn das ATTR_TRIGGER den Namen des Objetes besitzt...
der Befehl welche vom notify ausgeführt wird funktioniert und schreibt den Wert auf das jeweilige Objekt...
also das Problem ist der TRIGGER! des notify's

define TRIGGER_NOTIFY notify (a:ATTR_TRIGGER_DEVICE=TRUE):.*\
{\
    fhem("setreading a:ATTR_TRIGGER=$NAME TRIGGER $NAME");;\
}

wäre super wenn Ihr mir helfen könnt
DANKE
LG.
ERwin
- UBUNTU Server -- PhilipsHue -- Buderus -- FHEM2FHEM -- FroniusSymo -- SiemensLogo 8 -- AVM FritzBox
- Raspberry PI 2 -- WH1080 -- VZLogger -- RS485

Offline binford6000

  • Sr. Member
  • ****
  • Beiträge: 598
  • 🏠⚙️🛠📱
Antw:notify anhand von einen Attribut Triggern
« Antwort #1 am: 03 November 2018, 23:04:48 »
Zitat
nun würde ich gerne das notify so umbauen das ich nur das Attribut hinterlegen muss bei einen neuen DEVICE und nicht das notify ändern muss...
Warum denn so kompliziert?! Und außerdem wird das so wie du dir das vorstellst nicht funktionieren...

Mach dir lieber mal Gedanken über ein einheitliches und systematisches Namens-Schema für deine Geräte.
Dann kannst du in notifys ganz einfach mit regex arbeiten. Hier ein Beispiel mit Bewegungsmeldern:

Die Benamung lautet <Raumname>_bwm.
Und schon kann man mit folgendem notify auf alle Geräte (Bewegungsmelder) triggern:
.*_bwm:.* {...}Oder auch nur auf bestimmte Bewegungsmelder:
(bu|bz|sz)_bwm:.* {}
Kommt jetzt ein neuer bwm hinzu, wird er automatisch vom notify erfasst.
Solange du ihn mit dem bwm-Namens-Schema benannt hast  ;)

PS: ...Bei Änderungen (und nur dann) eines Attributes erzeugt das device global ein Event. Ergo kannst du kein notify bauen,
welches nur auf Geräte mit einem bestimmten Wert eines Attributes triggert.
siehe auch hier: https://fhem.de/commandref_DE.html#notify

VG Sebastian


FHEM 5.9 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:notify anhand von einen Attribut Triggern
« Antwort #2 am: 04 November 2018, 09:07:46 »
Hallo,

ich würde gerne bei unterschiedlichen Geräten automatisiert ein UserReading Namens 'TRIGGER' befühlen...
aktuell hab ich bei meinen notify als Trigger jeden Device einzelln trinnen...
define TRIGGER_NOTIFY notify (DEVICE_1|DEVICE_2|DEVICE_3):.*

jedes Gerät hätte aber auch ein UserAttribut 'ATTR_TRIGGER_DEVICE' welches den Wert TRUE hat...

nun würde ich gerne das notify so umbauen das ich nur das Attribut hinterlegen muss bei einen neuen DEVICE und nicht das notify ändern muss...
vorgestellt hätte ich es mir so, was jedoch leider nicht funktioniert...
define TRIGGER_NOTIFY notify (a:ATTR_TRIGGER_DEVICE=TRUE):.*\

mein Test notify sieht at Time so aus....
also das Gerät wo das Attribut ATTR_TRIGGER_DEVICE den Wert TRUE hat soll in einen Gerät das Reading TRIGGER mit den Namen des TriggerObjektes beschreiben wenn das ATTR_TRIGGER den Namen des Objetes besitzt...
der Befehl welche vom notify ausgeführt wird funktioniert und schreibt den Wert auf das jeweilige Objekt...
also das Problem ist der TRIGGER! des notify's

define TRIGGER_NOTIFY notify (a:ATTR_TRIGGER_DEVICE=TRUE):.*\
{\
    fhem("setreading a:ATTR_TRIGGER=$NAME TRIGGER $NAME");;\
}

wäre super wenn Ihr mir helfen könnt
DANKE
LG.
ERwin


obwohl ich binford6000 im grunde recht gebe, finde ich die Idee eines 'dynamischen' triggerns nicht so schlecht und hätte da durchaus auch anwendungsideen für mich selber.


daher bin ich gerade dabei , diese Funktion in meinem Modul 'Mswitch' zu integrieren. Diese wird mit kommendem Update verfügbar sein.

gruss Byte09
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16741
Antw:notify anhand von einen Attribut Triggern
« Antwort #3 am: 04 November 2018, 09:40:46 »
Ich halte es für unnötig um nicht sogar zu sagen verkehrt. Ein Attribut sollte nicht dynamisch sein, ist es das ist es kein Attribut mehr sondern ein Reading.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:notify anhand von einen Attribut Triggern
« Antwort #4 am: 04 November 2018, 09:45:28 »
Ich halte es für unnötig um nicht sogar zu sagen verkehrt. Ein Attribut sollte nicht dynamisch sein, ist es das ist es kein Attribut mehr sondern ein Reading.

ein attribut soll ja auch nicht dynamisch sein oder werden , aber der auslöser des triggers soll es sein , so dass oben genanntes Konstrukt möglich ist ( frei übersetzt : TRIGGER_MSwitch MSwitch (a:ATTR_TRIGGER_DEVICE=TRUE) )

gruss Byte09
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5758
Antw:notify anhand von einen Attribut Triggern
« Antwort #5 am: 04 November 2018, 09:49:04 »
Dynamische Event-Abfragen würde ich über Readings und nicht über Attribute machen. Alleine deswegen schon, weil eine Änderung des Attributes eine Konfigurationsänderung bedeutet und ein save erfordert.
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:notify anhand von einen Attribut Triggern
« Antwort #6 am: 04 November 2018, 09:54:32 »
Dynamische Event-Abfragen würde ich über Readings und nicht über Attribute machen. Alleine deswegen schon, weil eine Änderung des Attributes eine Konfigurationsänderung bedeutet und ein save erfordert.

ich glaube, hier reden 3 Leute völlig aneinander vorbei.  ;)

weder soll automatisch ein reading geändert werden , und schon gar nicht ein Attribut ( eigentümer = user ) . aber es soll auf das vorhandensein eines - in diesem Fall attributes in x-beliebigem device- reagiert werden. D. H das Device , welches den trigger abarbeiten soll ( sagen wir halt notify, um bei notify zu bleiben ) , muss sich selber aktualisieren und sein 'NOTIFYDEV' selbständig ändern , bei entsprechender Attributänderung - in welchem Device auch immer.

... finde ich halt nicht uninteressant ( für mich )  ;)

gruss Byte09
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5758
Antw:notify anhand von einen Attribut Triggern
« Antwort #7 am: 04 November 2018, 10:12:52 »
OK, dann ist es für einen DOIF-User nichts besonders:

DOIF (["myevent"] and AttrVal("$DEVICE","ATTR_TRIGGER","") eq "1") (....)
Beim notify halt mit if.
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:notify anhand von einen Attribut Triggern
« Antwort #8 am: 04 November 2018, 10:47:26 »
OK, dann ist es für einen DOIF-User nichts besonders:

DOIF (["myevent"] and AttrVal("$DEVICE","ATTR_TRIGGER","") eq "1") (....)
Beim notify halt mit if.

hmm, ok . zugegebener maßen kenne ich mich mit doif überhaupt nicht aus, und weiss somit nicht wie du es löst. aber beim notify reich mir ja ein if nicht aus . ich muss ja zumindest erstmal im ansatz festlegen , auf events welcher geräte denn nun eigentlich vom if,doif oder was auch immer reagiert werden soll ( NOTIFYDEV ) , oder ich prüfe alle eingehenden Events . Und genau darum geht es mir , das zu vermeiden - bei mir sind das 'hunderte' von events in der minute die erzeugt werden .

.... oder liege ich jetzt total falsch ?

gruss Byte09
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5758
Antw:notify anhand von einen Attribut Triggern
« Antwort #9 am: 04 November 2018, 10:56:05 »
hmm, ok . zugegebener maßen kenne ich mich mit doif überhaupt nicht aus, und weiss somit nicht wie du es löst. aber beim notify reich mir ja ein if nicht aus . ich muss ja zumindest erstmal im ansatz festlegen , auf events welcher geräte denn nun eigentlich vom if,doif oder was auch immer reagiert werden soll ( NOTIFYDEV ) , oder ich prüfe alle eingehenden Events . Und genau darum geht es mir , das zu vermeiden - bei mir sind das 'hunderte' von events in der minute die erzeugt werden .

.... oder liege ich jetzt total falsch ?

gruss Byte09

Das ist schon richtig.

Ich habe es mal beim DOIF nach gemessen, weil DOIF auf alles reagiert. Im Durchschnitt waren es bei meinem System 0,3 Millisekunden pro Event - also bei Hunderten von Events in einer Sekunde würde ich mir tatsächlich anfangen Gedanken zu machen. :)
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:notify anhand von einen Attribut Triggern
« Antwort #10 am: 04 November 2018, 11:03:59 »
Das ist schon richtig.

Ich habe es mal beim DOIF nach gemessen, weil DOIF auf alles reagiert. Im Durchschnitt waren es bei meinem System 0,3 Millisekunden pro Event - also bei Hunderten von Events in einer Sekunde würde ich mir tatsächlich anfangen Gedanken zu machen. :)

ok 'hunderte' war auch einfach mal nur in den raum gestellt.

hat sich aber sowieso erledigt , da mir bis vor 5 minuten irgendwie nicht bewusst war, das solche Angaben a:MSwitch_test=on al la 'devspec' im  'NOTIFYDEV' funktionieren . Nun weiss ich es und damit ist die Funktion bereits gegeben.


.... wird aber irgendwie OT

gruss Byte09
« Letzte Änderung: 04 November 2018, 11:11:40 von Byte09 »
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Damian

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5758
Antw:notify anhand von einen Attribut Triggern
« Antwort #11 am: 04 November 2018, 11:07:46 »
ok 'hunderte' war auch einfach mal nur in den raum gestellt.

hat sich aber sowieso erledigt , da mir bis vor 5 minuten irgendwie nicht bewusst war, das solche Angaben a:MSwitch_test=on al la 'devspec' im  'NOTIFYDEV' funktionieren . Nun weiss ich es.


.... wird aber irgendwie OT

gruss Byte09


Wenn du im Schnitt nur 10 Events/Sekunde hättest, dann wäre das schon sehr viel ;)
Programmierte FHEM-Module: DOIF mit uiTable, DOIF-Perl, THRESHOLD, FHEM-Befehl: IF

Offline dulan_menace

  • New Member
  • *
  • Beiträge: 11
Antw:notify anhand von einen Attribut Triggern
« Antwort #12 am: 04 November 2018, 18:36:07 »
Hallo Zusammen,

DANKE für die Teilnahme / Feedback und Info...
und ja ein bisschen aneinander vorbei ging es teilweise schon ;)

also ich fasse noch mal kurz zusammen...
es gibt folgende ATTRIBUTE
- ATTR_TRIGGER_DEVICE -> TRUE wenn das Gerät wo dieses Attribut hinterlegt ist den notify auslösen soll (bzw. halt der Trigger ist wenn sich bei diesen Device etwas ändern...)
- ATTR_TRIGGER -> hier wird bei einen AKTOR / SENSOR (DUMMY) der Namen des ATTR_TRIGGER_DEVICES hinterlegt welches durch eine Änderung des TRIGGER_DEVICES seine state Format neu berechnen soll, bzw. bei diesen ggf. ein UserReading beeinflussen soll...

so nun zu den Thema notify...
ich könnte natürlich bei den notify sämtliche DEVICE mit regex hinterlegen...
(Namenskonvention für Sensoren / Räume / usw. hab ich und wird auch strengstens eingehalten [meine Kollegen und Frau nennen mich liebevoll Monk ;-) ])

nun zur Erklärung warum ich mir diese Funktion wünsche...
z.B. ich bekomme ein neues Gerät (TürSensor - 1) welches gewisse Aktionen ausführen soll...
diese soll nun über wenig aufwand x notify beeinflussen ohne das ich diese notify alle bearbeiten muss...

wenn ich nun die TürSensor - 1 über ATTR Klassifizieren kann...
könnte ich somit standardisierte notify's ohne viel aufwand für neue Funktionen nutzen...
bzw. Triggert möglicherweise automatisiert gewisse funktionen an die ich ansonsten erst umschreiben müsste...
(ja ein regex mit den Namen funktiniert das auch aber ich bin nicht ganz so flexibel... (mehrere Attribute -> mehrere Aktionen mit den Namen nur eingeschränkt möglich))

geplant hätte ich z.B. auch ein ATTR_PUSHOVER bzw. ATTR_PUSHOVER_MSG...
das bedeutet bei ATTR_PUSHOVER soll TRUE hinterlegt werden...
wenn dies TRUE ist und sich das Gerät ändert soll der Text welcher unter ATTR_PUSHOVER_MSG hinerlegt ist versendet werden...

so könnte ich mit einer Arbeitsweise x Funktionen und befehle Ausführen...
und sämtliche Berechnungen usw. sind in stateFormat oder dem Gerät über UserAttribute / UserReadings definiert...
wenn ich etwas ändern möchte muss ich dies immer genau in den Gerät machen wo die Änderung nötig ist und nicht in einen notify welcher irgendwo 'versteckt' ist ;-)

die Information von DAMIAN muss ich mir anschauen ob dies so ist wie ich es mir erwarte...

wenn Ihr noch Fragen zu meinen Vorhaben habt, oder ihr verbesserungsvorschläge diesbezüglich habt bitte um Info!!!!
bzw. ein paar Informationen sind auch in diesen Thema enthalten (welches jedoch schon gelöst ist und funktioniert ;-) )
https://forum.fhem.de/index.php/topic,92715.msg852731.html#msg852731

LG.
Erwin
- UBUNTU Server -- PhilipsHue -- Buderus -- FHEM2FHEM -- FroniusSymo -- SiemensLogo 8 -- AVM FritzBox
- Raspberry PI 2 -- WH1080 -- VZLogger -- RS485