notify anhand von einen Attribut Triggern

Begonnen von dulan_menace, 03 November 2018, 17:55:07

Vorheriges Thema - Nächstes Thema

dulan_menace

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

binford6000

Zitatnun 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



Byte09

Zitat von: dulan_menace 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


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

CoolTux

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.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Byte09

Zitat von: CoolTux 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.

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

Damian

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-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Byte09

Zitat von: Damian 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.

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

Damian

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-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Byte09

Zitat von: Damian 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.

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

Damian

Zitat von: Byte09 am 04 November 2018, 10:47:26
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-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Byte09

#10
Zitat von: Damian am 04 November 2018, 10:56:05
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

Damian

Zitat von: Byte09 am 04 November 2018, 11:03:59
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-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

dulan_menace

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