Hallo zusammen,
ich habe ein Notify für einen Bewegungsmelder, das ich nicht korrekt zum Auslösen bringen kann.
Der Bewegungsmelder an sich ist per MQTT eingebunden, und übermittelt auf:subprocess.Popen(['/usr/bin/mosquitto_pub', '-u', 'user', '-P', '12345','-h', '192.168.x.x','-t','Wohnung/KUE/Bewegungsmelder/stat','-m','on']) bzw. 'off'seine Werte "on|off" an FHEM,
...wo es mitsubscribeReading_state Wohnung/KUE/Bewegungsmelder/stat
getriggert wird. Soweit läuft es perfekt.
Jetzt soll damit natürlich auch etwas passieren. Ich schalte damit zb die Ofenecke nach 20 Sekunden Aktivität an. Dazu brauche ich eine Glättung der getriggerten Meldungen des Bewegungsmelders.
Das habe ich so gemacht, das es ein 2. Reading "state_sum" im Device Bewegungsmelder gibt.
Das wird sofort mit "move" gefüllt, wenn eine Bewegung registriert wird.
Um den Wert "stop" zu erhalten, darf sich das state mit dem Wert "off" 5 Sekunden lang nicht verändert haben .. also keine Bewegunge registriert für 5 Sekunden
Ich rufe über das EVENT "on|off" eine Funktion auf, die das bewerkstelligen soll.sub bewegung ...
if($event eq "on") {
fhem("setreading Bewegungsmelder state_sum move"); ...
elsif($event eq "off") {
fhem("defmod wd_Bewegungsmelder_Ofenecke watchdog Bewegungsmelder:off.* 00:00:05 Bewegungsmelder:on.* {fhem(\"setreading Bewegungsmelder state_sum stop\")}");
...
Letztendlich möchte ich nun auf "state_sum" reagieren, nicht auf die zu oft getriggerten Events vom MQTT Device.
Dazu muß das Reading state_sum beim setzen selbst auch triggern, worauf ich dann reagieren würde. Das passiert über setreading ...
Und hier habe ich das Problem. stop kommt an, move nicht.
Ich mache hier anscheinend mit der RegEx irgendwas falsch, denn ein Notify nur auf .*state_sum.* reagierend macht es korrekt. Sowie ich die gleiche Syntax zusammen mit (on|off|,*state_sum.*) eintrage, wird nur noch stop durchgelassen.
Im Detail:
funktionierendes Notify:
defmod n_Bewegungsmelder notify Bewegungsmelder.*state_sum.*) { print ($NAME,$SELF,$EVENT) }
Ausgabe:
bm_Kueche n_Bewegungsmelder state_sum: move
Bewegungsmelder n_Bewegungsmelder state_sum: stop
Wenn ich jetzt on|off mit hinzugebe, kommt nur noch "on|off|stop" durch, move nicht:
defmod n_Bewegungsmelder notify Bewegungsmelder :(on|off|.*state_sum.*) { print ($NAME,$SELF,$EVENT) }
Ausgabe:
Bewegungsmelder n_Bewegungsmelder state_sum: stop
Hier das komplette list vom Bewegungsmelder:
Internals:
CFGFN
IODev MQTT_Broker
NAME Bewegungsmelder
STATE off
TYPE MQTT_DEVICE
.attraggr:
.attreocr:
state
.*state_sum.*
.attreour:
state
.*state_sum.*
.attrminint:
.qos:
* 0
.retain:
* 0
READINGS:
2018-08-01 15:01:07 Module 0
2018-08-01 14:58:16 state off
2018-08-01 14:58:21 state_sum stop
2018-08-01 14:58:16 transmission-state incoming publish received
message_ids:
sets:
subscribe:
Wohnung/KUE/Bewegungsmelder/stat
subscribeExpr:
^Wohnung\/KUE\/Bewegungsmelder\/stat$
subscribeQos:
Wohnung/KUE/Bewegungsmelder/stat 0
subscribeReadings:
Wohnung/KUE/Bewegungsmelder/stat:
cmd
name state
Attributes:
IODev MQTT_Broker
devStateIcon on:own-woman off:audio_repeat .*:audio_repeat .*:audio_repeat .*:audio_repeat
event-on-change-reading state,.*state_sum.*
event-on-update-reading state,.*state_sum.*
group IT
icon it_camera
room FHEM->- Bridges->MQTT,Räume->Küche
subscribeReading_state Wohnung/KUE/Bewegungsmelder/stat
userattr st_type_update st_type_update_map structexclude
Sowas wie: event-on-update-reading state,.*state_sum.* sind schon Verzweiflungstaten :D
Was passt hier nicht ?
Moin,
ehrlich gesagt kann ich der Erklärung des Problems nicht ganz folgen.
Was mir auffällt: Bewegungsmelder :(.*state_sum.*) es muss meiner Meinung nach Bewegungsmelder:(.*state_sum.*) heissen. Wobei die Klammern in dem Fall überflüssig sind.
Ich weiß nicht was passiert wenn zwischen Gerät und : ein Leerzeichen steht. Wahrscheinlich wird auf alles von Bewegungsmelder getriggert und der Rest als Ausführungsteil behandelt.
https://commandref.fhem.de/commandref_DE.html#notify
Zur Unterstützung und Fehlersuche kann vielleicht noch der überarbeitete Artikel im Wiki (https://wiki.fhem.de/wiki/Notify)helfen.
Gruß Otto
Hallo Otto,
Zitat von: Otto123 am 02 August 2018, 09:37:20Moin,
ehrlich gesagt kann ich der Erklärung des Problems nicht ganz folgen.
Was mir auffällt: Bewegungsmelder.*state_sum.*) es muss meiner Meinung nach Bewegungsmelder:(.*state_sum.*) heissen. Wobei die Klammern in dem Fall überflüssig sind.
Ich weiß nicht was passiert wenn zwischen Gerät und : ein Leerzeichen steht. Wahrscheinlich wird auf alles von Bewegungsmelder getriggert und der Rest als Ausführungsteil behandelt.
https://commandref.fhem.de/commandref_DE.html#notify (https://commandref.fhem.de/commandref_DE.html#notify)
Zur Unterstützung und Fehlersuche kann vielleicht noch der überarbeitete Artikel im Wiki (https://wiki.fhem.de/wiki/Notify)helfen.
Gruß Otto
oh, wie mans macht ... :) Ersteinmal Danke für die Geduld dir das trotzdem durchzulesen.
Eigentlich gehts nur um das Notify .. der Rest warum und wieso sollte nur den Rahmen aufzeigen, vlt gäbe es ja insg. bessere Ideen.
Das Leerzeichen war ein Versehen. Ich hab Bezeichnugen, ums etwas verständlicher zu machen, umgeschrieben, das war bestimmt nicht der einzige Übertragungsfehler ... das ist glaub ich nicht mein Problem.
Also kurz, vergiss das drumherum ;) Der watchdog aus der Funktion zB war an der Stelle falsch, da zu spät gesetzt.
Ich versuch das eigentliche Problem nochmal in Kurzform zu beschreiben:
Device Bewegungsmelder mit Reading "state_sum"
defmod Bewegungsmelder MQTT_DEVICE
Bewegungsmelder->R:state_sum1. Notify "n_Bewegungsmelder_mqtt" -> setzt mit "Glättung/Verzögerung" das Reading state_sum
defmod Bewegungsmelder bm_Kueche:(on|off) { call_sub($EVENT) } Der Aufruf in der Funktion call_sub macht letztlich:
fhem("setreading Bewegungsmelder state_sum move"); was das 2. Notify "n_Bewegungsmelder_move" auslösen soll -> auf dieses Reading reagiere ich dann mit den Geräten, nicht auf das state vom 1. Notify, da das zu oft getriggert wird.
defmod n_Bewegungsmelder_move notify Bewegungsmelder:(.*state_sum.*) { ..do_something.. }Und genau das klappt nicht so recht.
..... beim Zusammentragen hier bin ich gerade auf etwas gestoßen,
fhem("setreading Bewegungsmelder state_sum move"); setzt nicht auf "move", laut Notify Ausgabe wird "incomming" getriggert .. . jetzt bin ich komplett überrascht .. ich schau mir das erstmal an und schreib dann was dazu .. vlt hat sichs ja dadurch schon...
setreading Bewegungsmelder state_sum move
Das Suchmuster für einen Event auf das reading state_sum im Gerät Bewegungsmelder würde ich prinzipiell so verfassen:
Bewegungsmelder:state_sum.*Und gezielter dann eventuell so:
Bewegungsmelder:state_sum.(on|off|move).*Wobei wenn Du immer setreading selbst machst, dann reicht exakt:
Bewegungsmelder:state_sum.(on|off|move)
hallo ftsinuglarity,
kann es sein, dass du eine schleife gebaut hast?
also ein event eines devices (soll) löst über notify und setreading erneut ein event in diesem device aus.
solche schleifen versucht fhem zu verhindern.
Zitat von: Otto123 am 02 August 2018, 15:17:34
setreading Bewegungsmelder state_sum move
Das Suchmuster für einen Event auf das reading state_sum im Gerät Bewegungsmelder würde ich prinzipiell so verfassen:
Bewegungsmelder:state_sum.*Und gezielter dann eventuell so:
Bewegungsmelder:state_sum.(on|off|move).*Wobei wenn Du immer setreading selbst machst, dann reicht exakt:
Bewegungsmelder:state_sum.(on|off|move)
Danke Otto, das sieht sehr gut aus, hat aber auch nicht funktioniert. Jetzt ist mir auch klar warum, liegt nicht an deinem Statement:
trotz klarem:
setreading Bewegungsmelder state_sum move steht im Log:
2018-08-02_15:23:45 Bewegungsmelder state_sum: moveDen Doppelpunkt hinter state_sum habe ich die ganze Zeit ignoriert (sehe ich auch übers Notify, wenn ich keine RegEx angebe) .. hätte ich mal nicht. Keine Ahnung wo der jetzt herkommt, schau ich gleich.
Wenn ich deine RegEx anpasse und sowas schreibe:
Bewegungsmelder :state_sum.*:.(on|off|move|stop) { .. }greift das trotzdem nicht. Egal wie ich Wildcards setze, es will nicht.
Sollte nicht spätestens das hier funktionieren? :
Bewegungsmelder :.*state_sum.*:.*(on|off|move|stop).* { .. }Sieht zwar wild aus, sollte aber für mein Verständnis alles abdeckeln (der Doppelpunkt als solches ist hier vermutlich das Problem, weil er interpretiert wird in .* .. kann das sein?)
.* steht doch für alles beliebige oder gar nichts, korrekt?
Zitat von: frank am 02 August 2018, 15:25:05
hallo ftsinuglarity,
kann es sein, dass du eine schleife gebaut hast?
also ein event eines devices (soll) löst über notify und setreading erneut ein event in diesem device aus.
solche schleifen versucht fhem zu verhindern.
Hallo Frank,
ich denke nicht.
Es wird zwar in ein Device geschrieben, aber aus einem Reading der Wert gezogen (state on|off) (kommt vom Bewegungsmelder per MQTT),
und dann per Funktion das Reading state_sum auf move oder stop gesetzt. Auf Reading state_sum reagieren dann meine Geräte. Meinst du noch was anderes ?
Ja stimmt, hinter dem reading setzen steht meist(immer?) ein :
Dann würde ich es so machen:
Bewegungsmelder:state_sum:.(on|off|move)
Wobei der Eintrag im Log das Eine ist, das Wichtige ist der Event im Eventmonitor
https://wiki.fhem.de/wiki/Notify
Zitat von: Otto123 am 02 August 2018, 15:56:48
Ja stimmt, hinter dem reading setzen steht meist(immer?) ein :
Dann würde ich es so machen:
Bewegungsmelder:state_sum:.(on|off|move)
Wobei der Eintrag im Log das Eine ist, das Wichtige ist der Event im Eventmonitor
https://wiki.fhem.de/wiki/Notify (https://wiki.fhem.de/wiki/Notify)
Ich glaub ich hab schon alle Varianten durch .. da will nix. Ich denke ich schau mal lieber wo der Doppelpunkt auf einmal herkommt.. im Notify siehts genaus aus
trotzdem zum Verständnis:
Warum greift das hier nicht einfach alles ab ? (Es sei denn der Doppelpunkt ist hier wirklich n Problem)
Bewegungsmelder :.*state_sum.*:.*(on|off|move|stop).* { .. }
Der Doppelpunkt ist nicht die ganze Fehlerquelle.
Ich hatte eingangs ja schon erwähnt, das "setreading Bewegungsmelder state_sum move" nicht recht ankommt, bzw nicht richtig getriggert wird. Irgendwo ist hier der Wurm drin.
Folgendes passiert:
1. Bewegungsmelder setzt per mqtt subscribe reading das "state" vom Bewegungsmelder Device in FHEM auf on|off
2. Das 1. Notify reagiert auf on|off korrekt, und ruft die Funktion call_sub($EVENT) auf
3. Die Funktion setzt per "setreading Bewegungsmelder state_sum move" das Reading.
4. Im Log .. steht nichts.
5. Im 2. Notify sehe ich es, wenn ich dort keine RegEx einfüge (das eben besprochene Doppelpunkt Problem)
Das FHEM Device Bewegungsmelder steht auf:
event-on-change-reading .*
event-on-update-reading .*
Das LogDevice auf:
./bm-kue-%Y-%m.log Bewegungsmelder .. also Durchzug
Ich verstehe nicht, warum im Log nichts ankommt. Was vlt auch andere Probleme nach sich zieht
Edit:
Rufe ich direkt in der Komandozeile : setreading Bewgungsmelder state_sum move auf, erscheint es im Log und im Notify
Ein später in der Funktion aufgerufenes:
fhem("defmod ".$wd_timer_ofen." watchdog ".$dev.":off.* ".$time." ".$dev.":on.* {fhem(\"setreading ".$dev." ".$event_reading." stop\")}");
.. also nochmal verschachteltes und in einen watchdog gepacktes : setreading Bewgungsmelder state_sum stop
.. das haut hin. Das erscheint im Log und im Notify
Ich schreibe das, weil es aus irgendeinem Grund vlt einen Unterschied macht, ob setreading aus einer Funktion oder vom Watchdog aufgerufen wird. Ich wüßte nicht warum, aber wer weiß
Das ist im Moment aber alles abgeschaltet, ich setze in der Funktion nur setreading .. , sonst nichts
Wenn Du in der FHEM Kommandozeile ein setreading Bewegungsmelder state_sum moveabsetzt, musst Du im EVENTMONITOR einen Event sehen. Wenn nicht wird kein notify darauf anspringen.
ich würde event-on.* erstmal löschen!
Gruß Otto
Zitat von: Otto123 am 02 August 2018, 16:41:18
Wenn Du in der FHEM Kommandozeile ein setreading Bewegungsmelder state_sum moveabsetzt, musst Du im EVENTMONITOR einen Event sehen. Wenn nicht wird kein notify darauf anspringen.
ich würde event-on.* erstmal löschen!
Gruß Otto
Jup :) .. genau. Das passiert auch. Nur nicht aus der Funktion, why ever.
Sind nicht gesetzte event-on.* das gleiche wie = Reagiere auf alles ?
Edit: rausgelöscht, das gleiche Ergebnis .. na wenigstens ist diese Programmierung sportlich, so oft wie ich in die Küche latsche um den Bewegungsmelder auszulösen :D
Ich kapiers nicht. Hab nochmal direkt über den EventMonitor geschaut:
2018-08-02 16:51:44 MQTT_DEVICE Bewegungsmelder state_sum: move
.. im Log .. nüscht
nicht gesetzte event-on haben nichts mit reagieren zu tun. Sie steuern die Erzeugung von Events, an dem Device wo sie definiert sind. Nicht gesetzt bedeutet erzeuge die Events so wie sie sind....
setreading erzeugt unter bestimmten Umständen keine Events!
https://commandref.fhem.de/#setreading
Aber nach meinem Verständnis trifft das nicht in deinem Fall zu, aber das mit dem sleep kannst Du ja testen :)
Zitat von: Otto123 am 02 August 2018, 16:53:09
setreading erzeugt unter bestimmten Umständen keine Events!
https://commandref.fhem.de/#setreading (https://commandref.fhem.de/#setreading)
Aber nach meinem Verständnis trifft das nicht in deinem Fall zu, aber das mit dem sleep kannst Du ja testen :)
Du meinst: setreading won't generate an event for device X, if it is called from a notify for device X nehme ich an
Habs trotzdem getestet, und .. Es klappt !! Der Logeintrag wird geschrieben!
Das komplette Statement:
fhem("sleep 0.1;setreading Bewegungsmelder state_sum move;"); Zitat von: Otto123 am 02 August 2018, 16:53:09
nicht gesetzte event-on haben nichts mit reagieren zu tun. Sie steuern die Erzeugung von Events, an dem Device wo sie definiert sind. Nicht gesetzt bedeutet erzeuge die Events so wie sie sind....
Oh ja, das ist besser ausgedrückt. Events so wie sie sind werden doch aber auch bei event-on.* durchgegeben, nur nach Readings gefiltert wenn man möchte (zB event-on-update state) .. das meintest du wahrscheinlich ?
Danke Otto, ohne dich wär ich auf sleep 0.1 nicht gekommen, vielen vielen Dank!
Wenns dich nicht nervt... der Doppelpunkt, den bekomme ich nicht weg.2018-08-02 17:12:04 MQTT_DEVICE Bewegungsmelder state_sum: moveBei stop ist es das gleiche.
Rufe ich direkt auf:trigger Bewegungsmelder on ist der Doppelpunkt auch da. Über die Funktion aufgerufen das gleiche.
Wo könnte der herkommen ?
Edit:
Öhm, ich sehe gerade, das alle! Readings im EventMonitor einen : Doppelpunkt haben, ist mir noch nie aufgefallen.
set states haben das nicht.
also doch ne schleife.
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
Zitat von: frank am 02 August 2018, 17:15:58
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
Zitat von: Otto123 am 02 August 2018, 17:20:46
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 (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:
print("$NAME - $SELF - $EVENT"); Ergebnis:
Bewegungsmelder - n_Bewegungsmelder_move - state_sum: move Ich teste ... ist schonmal viel Wert wenn ich weiß wo das Problem liegt.
Zitat von: Otto123 am 02 August 2018, 17:20:46
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 !
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.
Zitat von: frank am 02 August 2018, 18:15:37
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 :D . 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 :D ...
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 ;)
Zitatsetreading 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.
Zitat von: frank am 02 August 2018, 21:58:40
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 ;)
Warum Du immer .* nehmen musst und den Doppelpunkt aussparst?
Bewegungsmelder:state_sum.*(move|stop)
funktioniert meine Variante wirklich nicht? :-[
Bewegungsmelder:state_sum:.(move|stop)
Zitat von: Otto123 am 02 August 2018, 23:26:23
Warum Du immer .* nehmen musst und den Doppelpunkt aussparst?
Bewegungsmelder:state_sum.*(move|stop)
funktioniert meine Variante wirklich nicht? :-[
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 :D
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 ..
das hier funktioniert schonmal im Notify n_Bewegungsmelder_move: defmod n_Bewegungsmelder_move notify Bewegungsmelder:state_sum.* { print("$EVTPART1");
Ausgabe bei trigger Bewegungsmelder on / off sind saubere:
move
stop
Feiner gefiltert:
defmod n_Bewegungsmelder_move notify Bewegungsmelder:state_sum.*(move|stop) { print("$EVTPART1");
Jetzt noch mit on |off zusammenbringen ...
das haut so hin:
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:
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:
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!
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:
n_Bewegungsmelder:(on|off|state_sum.*(move|stop)) { call_sub($NAME,$EVENT) }
2. Funktion call_subcall_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)
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
sub split_Event {
my @data = split( ' ', $_[0] );
my @events;
for my $part (@data) {
push(@events, $part) if( $part );
}
return @events;
}
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
Zitat von: Otto123 am 02 August 2018, 23:26:23
Warum Du immer .* nehmen musst und den Doppelpunkt aussparst?
Bewegungsmelder:state_sum.*(move|stop)
funktioniert meine Variante wirklich nicht? :-[
Bewegungsmelder:state_sum:.(move|stop)
Hallo Otto :)
hat mir dann doch keine Ruhe gelassen, warum das ..
Bewegungsmelder:state_sum:.(move|stop) .. nicht funktioniert. Sollte doch eigentlich ..
Beachtet sei auch nochmal: (aus: https://wiki.fhem.de/wiki/Notify#Suchmuster (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
(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
(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:
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!