Gelöst - Notify RegEx löst nur zum Teil aus

[frank]

also doch ne schleife.

[Otto123]

Dann ist der Teil des Events, ich kenne das auch aus anderen Geräten.
Warum ist der Doppelpunkt hinter dem Reading ein Problem?

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

Zum event-on ...
wenn du setreading device reading on machst gibt es einen Event.
Wenn du wieder setreading device reading on gibt es wieder einen Event, obwohl ja schon on war.
Wenn Du möchtest das solche, aus deiner Sicht redundanten, Events unterdrückt werden, setzt du
event-on-change reading
Danach wird nur noch beim Wechsel, also z.B. on nach off ein Event erzeugt.

Gruß Otto

[ftsinuglarity]

also doch ne schleife.

Könntest du mal näher beschreiben was du meinst, und wo die Schleife liegt ?


Du meintest: also ein event eines devices (soll) löst über notify und setreading erneut ein event in diesem device aus.

Kommt doch drauf an, was man mit den getriggerten Readings macht, und ob die sich gegenseitig triggern. Ansonsten ists doch ok, auch im gleichen Device ?

Bei mir läufts nur in einer Richtung und dann Ende:
mqtt cmd -> Bewegungsmelder:state -> Notify/Funktion setzt Bewegungsmelder:state_sum  auf stop|move -> Bewegungsmelder:state_sum triggert  NICHT Bewegungsmelder:state, sondern schaltet Geräte

[ftsinuglarity]

Dann ist der Teil des Events, ich kenne das auch aus anderen Geräten.
Warum ist der Doppelpunkt hinter dem Reading ein Problem?

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

Ja, ist Teil des Events. Um das zu testen, und weil ich das mit dem Doppelpunkt im EventMonitor irritierend finde, habe ich ins Notfiy oben folgendes geschrieben:

Code Auswählen Erweitern

print("$NAME - $SELF - $EVENT");
Ergebnis:

Code Auswählen Erweitern

Bewegungsmelder - n_Bewegungsmelder_move - state_sum: move

Ich teste ... ist schonmal viel Wert wenn ich weiß wo das Problem liegt.

Zum event-on ...
wenn du setreading device reading on machst gibt es einen Event.
Wenn du wieder setreading device reading on gibt es wieder einen Event, obwohl ja schon on war.
Wenn Du möchtest das solche, aus deiner Sicht redundanten, Events unterdrückt werden, setzt du
event-on-change reading
Danach wird nur noch beim Wechsel, also z.B. on nach off ein Event erzeugt.

Konform !

[frank]

es geht um die erzeugung des neuen readings state_sum durch die events des bereits existierenden readings state über notify -> setreading. es besteht also eine rückkopplung auf das triggernde device.

es sind zwar unterschiedliche readings, aber eine ungeschickte regex vom notify würde es wieder triggern, usw.

grundsätzlich kannst du das auch über userreadings verhindern. das wurde extra dafür gebaut. events eines devices erzeugen ein neues reading in diesem device mit entsprechenden events. funktioniert im prinzip wie ein device internes notify.

[ftsinuglarity]

es geht um die erzeugung des neuen readings state_sum durch die events des bereits existierenden readings state über notify -> setreading. es besteht also eine rückkopplung auf das triggernde device.

es sind zwar unterschiedliche readings, aber eine ungeschickte regex vom notify würde es wieder triggern, usw.

grundsätzlich kannst du das auch über userreadings verhindern. das wurde extra dafür gebaut. events eines devices erzeugen ein neues reading in diesem device mit entsprechenden events. funktioniert im prinzip wie ein device internes notify.

so .. wieder im Lande.  Hm, ok, könnte eine Schleife erzeugen, wenn man das ungeschickt macht, geb ich dir Recht.
Doch in dem Falle kann Event -> state -> Notify -> Funktion -> setreading anderes Reading -> Ende
da meines Erachtens nichts anstellen, da anderes_Reading (also state_sum) nicht wieder auf state triggert. Es wird sozusagen nur in eine Richtung geschossen . Reading state_sum wird nur mit move oder stop befüllt, nicht erzeugt.

Userreadings hab ich noch nie benutzt, das schaue ich mir an , danke für den Tip!


Edit: Schleifen hatte ich Anfangs weißGott genug, bis ich das getriggere mal gerafft habe ... 
Kann schnell passieren, der Hinweis darauf zu schauen ist selten verkehrt, gerade wenns denn viele Funkionen von vielen Events aufgerufen werden und miteinander agieren. Das manchmal ne harte Nuss, wenn ich im Vorraus nicht an alles gedacht habe. Da funktioniert dann schon lange ordnungsgemäß laufendes auf einmal nicht mehr .. was echt frustrierend sein kann. 
Aber hey, zwingt mich ja niemand

[frank]

setreading won't generate an event for device X, if it is called from a notify for device X

entscheidend ist nur die rückkopplung auf das device.

es gibt ja nun auch die sleep variante. die kannte ich noch gar nicht.

[ftsinuglarity]

entscheidend ist nur die rückkopplung auf das device.

Dabei denkst du dir ja was in Bezug auf das Geschriebene.
Ich weiß nicht, warum setreading aus dem Notify des eigenen Device heraus nicht funktioniert, kann ich mir nicht zusammenreimen.
Ebenso weiß ich nicht, WaruM ich das sleep 0.1 vor das setreading in der Funktion packen muß, damit auch gelogt wird. Event hats ja ausgelöst, aber nicht komplett (wie ja schon der Titel dieses Threads sagt) .. zumindest hats nicht für die Logs gereicht.
Ohne dir auf die Nüsse gehen zu wollen, wenn du den Nerv oder nen Link hast, der den Zusammenhang erklärt, .. ich sterb nicht gern doof

[Otto123]

Warum Du immer .* nehmen musst und den Doppelpunkt aussparst?

Code Auswählen Erweitern

Bewegungsmelder:state_sum.*(move|stop)
funktioniert meine Variante wirklich nicht? 

Code Auswählen Erweitern

Bewegungsmelder:state_sum:.(move|stop)

[ftsinuglarity]

Warum Du immer .* nehmen musst und den Doppelpunkt aussparst?

Code Auswählen Erweitern

Bewegungsmelder:state_sum.*(move|stop)
funktioniert meine Variante wirklich nicht? 

Code Auswählen Erweitern

Bewegungsmelder:state_sum:.(move|stop)

Oh, hab ich jetzt einfach nicht nochmal probiert. Mache ich jetzt ... War grad froh das das hinhaut und logisch war


Wenn ich statt state_sum.*(move|stop)  -> state_sum:.(move|stop)  verwende, wird exakt einmal bei move bzw stop ausgelöst, danach nicht mehr (wie kann sowas denn sein? Entweder matched oder matched nicht ? Confused) 
on | off werden sauber durchgelassen

Wenn ich das hier richtig verstehe, wird der 2. Doppelpunkt nur als String des Events verstanden:   (aus: https://wiki.fhem.de/wiki/Notify#Suchmuster)
Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events!


state_sum:.(move|stop)  sollte demnach funktionieren ..

[ftsinuglarity]

das hier funktioniert schonmal im Notify n_Bewegungsmelder_move:

Code Auswählen Erweitern

defmod n_Bewegungsmelder_move notify Bewegungsmelder:state_sum.* { print("$EVTPART1");
Ausgabe bei trigger Bewegungsmelder on / off sind saubere:
move
stop

Feiner gefiltert:

Code Auswählen Erweitern

defmod n_Bewegungsmelder_move notify Bewegungsmelder:state_sum.*(move|stop) { print("$EVTPART1");


Jetzt noch mit on |off zusammenbringen ...

das haut so hin:

Code Auswählen Erweitern

defmod n_Bewegungsmelder_move notify Bewegungsmelder:(on|off|state_sum.*(move|stop))  { }
Das man hier so (on|off|state_sum.*(move|stop))  verschachteln kann war mir neu .. probiert -> funktioniert


Jetzt noch das bei on|off nicht gesetzte EVTPART1 abfangen ..

Im Notify direkt funktioniert es so zumindest NICHT, weil $EVTPART1 immer! definiert sein muß, wenn das Notify aufgerufen wird, was bei "on" "off" aber nicht der Fall ist:

Code Auswählen Erweitern


if($EVENT =~ /state_sum/) {
    if($EVTPART1 eq "move")    { play_sound("sound_start") }
    elsif($EVTPART1 eq "stop") { play_sound("sound_bestaetigungston_ende") }
}   



CoolTux macht das hier:  https://forum.fhem.de/index.php/topic,50674.msg423063.html#msg423063
indem er das komplette Event an die Funktion weiterreicht, und es dort auseinandernimmt:

Code Auswählen Erweitern


sub multiroomradio($) {
       my @data = split( ' ', $_[0] );
        my $cmd = $data[0];
        my $sender = $data[1] if( $data[1] );
        ...

 



Damit ich den EVENT - Split immer wiederverwenden kann, habe ich mir eine Funktion gebastelt .. Thanks to CoolTux!

Code Auswählen Erweitern

sub split_Event {
    my @data = split( ' ', $_[0] );
    my @events;
   
    for my $part (@data) {
        push(@events, $part) if( $part );
    }
    return @events;
}


Damit ist dann alles gelöst!
Hier nochmal alles zusammen:

1. Notify n_Bewegungsmelder:

Code Auswählen Erweitern

n_Bewegungsmelder:(on|off|state_sum.*(move|stop)) {  call_sub($NAME,$EVENT)  }

2. Funktion call_sub

Code Auswählen Erweitern

call_sub($NAME,$EVENT) {
        my @events = split_Event($_[1]);
        my $event = $events[0];   
       $event = $events[1] if( $events[1] );
        ...
}

.. damit nicht jedes Mal split_Event aufgerufen werden muß, habe ich on und off abgefangen und lieber so geschrieben:(keine Ahnung was insgesamt schneller ist)

Code Auswählen Erweitern

call_sub($NAME,$EVENT) {
        my $event = "";
  if($_[1] eq "on" || $_[1] eq "off") { $event = $_[1]}
else {
my @events = split_Event($_[1]);
$event = $events[1] if( $events[1] );
}
        if($event eq "on") {
             fhem("sleep 0.1;setreading Bewegungsmelder state_sum move;");
            ...
        elsif($event eq "move") {
            ... do anything ..
        ...
    }
}

Das Doppelpunkt "Problem" hat sich damit dann auch gelöst, da in $events[1] nur move oder stop stecken kann.

 
3. Hier nochmal die split_Event() Funktion
nochmal Danke an CoolTux, die Idee mit split EVTPART "Fehler" abzufangen ist nicht auf meinem Mist gewachsen

Code Auswählen Erweitern

sub split_Event {
    my @data = split( ' ', $_[0] );
    my @events;
   
    for my $part (@data) {
        push(@events, $part) if( $part );
    }
    return @events;
}

Code Auswählen Erweitern

trigger bm_Kueche state_sum move
trigger bm_Kueche state_sum stop 
trigger bm_Kueche on
trigger bm_Kueche off

werden jetzt sauber getriggert.
Das Doppelpunkt Problem hat sich damit auch erledigt (siehe weiter oben)
Ich brauche jetzt nur noch ein Notify  (statt der zwei vorher um die Events zu trennen), so wie es angedacht war. Perfekt !

Vielen, vielen Dank an Otto und Frank!!   sleep 0.1 ey, echt ..
userreadings stehen als nächstes auf der Liste

[ftsinuglarity]

Warum Du immer .* nehmen musst und den Doppelpunkt aussparst?

Code Auswählen Erweitern

Bewegungsmelder:state_sum.*(move|stop)
funktioniert meine Variante wirklich nicht? 

Code Auswählen Erweitern

Bewegungsmelder:state_sum:.(move|stop)

Hallo Otto

hat mir dann doch keine Ruhe gelassen, warum das ..

Code Auswählen Erweitern

Bewegungsmelder:state_sum:.(move|stop)
.. nicht funktioniert. Sollte doch eigentlich .. 


Beachtet sei auch nochmal:  (aus: https://wiki.fhem.de/wiki/Notify#Suchmuster) 
Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! 


Also probiert ..
mit Doppelpunkt aber dahinter darf alles stehen bis zu move/idle

Code Auswählen Erweitern

(on|off|state_sum:.*(move|idle)) {  .. funktioniert. Also steht zwischen sate_sum und move|stop wohl noch ein Leerzeichen 
 
mit Doppelpunkt und dahinter 2 Punkte

Code Auswählen Erweitern

(on|off|state_sum:..(move|idle)) { und siehe da .. haut hin.

Du lagst völlig richtig mit deiner Syntax Otto!


Woher jetzt nu wieder das 2. Leerzeichen kommt, zumal ich das Reading ja nur an jeweils einer Stelle selbst setze:

Code Auswählen Erweitern

fhem("sleep 0.1;setreading ".$dev." ".$event_reading." move;");
fhem("defmod ".$at_timer_bm_idle." at +".$time." { fhem(\"setreading ".$dev." ".$event_reading." idle\") }");

.. is mir jetzt Wurscht. Wär jetzt nur Schönheitskorrektur .. funktioniert schön mit state_sum:.*(move|idle)) .. reicht jetzt Danke nochmal!