Hallo zusammen,
gerade rief mich meine Frau bei der Arbeit an.
Ich habe sie kaum verstanden, denn sie stand im Wohnzimmer, wo ich an zentraler Stelle an der Decke
die Aeotec zWave Sirene angebracht habe, und die Sirene lauthals ihren Dienst verrichtete.
Mir ist es seit meinem Umzug vom Raspi3 auf den NUC schon 2-3 Mal passiert, dass das Teil ausgelöst hat.
Ich habe allerdings den outdoor zWave Bewegungsmelder am Carport im Verdacht.
Weil ich die Zusammenhänge noch nicht so recht durchschaue, dachte ich mir: "Schaust halt ins Log der Sirene..."
Leider steht dort nur drinnen, wann sie an oder aus war, nicht jedoch, wer den Alarm ausgelöst hat.
Hat jemand eine Idee, wie man an die notwendigen Infos rankommt?
Gruß
Markus
Du könntest den globalen Verboselevel erhöhen oder den Eventmonitor mit laufen lassen.
Zitat von: MarkusAutomaticus am 05 Oktober 2016, 10:05:50
Ich habe allerdings den outdoor zWave Bewegungsmelder am Carport im Verdacht.
Hi,
ich denke da musst Du nochmals über Deinen Alarmplan nachdenken. Stimmen die Zeiten, die Events, devices, etc. ?
Nachdem bei mir das Gleiche das 3te mal passiert ist, ich überwache Wasser, Rauch und nicht abgeschlossene Türen/Fenster mit der Sirene, hat mich meine Frau ziemlich rund gemacht, sie war gerade am Einschlafen. Es waren immer nicht abgeschlossene Türen/Fenster.
Also habe ich für den Fall zwei Voralarme eingebaut. Eine Stunde vor der Scharfschaltung wird ein Telegram an dem Account meiner Frau und an meinem geschickt.
(Natürlich nur wenn nicht abgeschlossen.) Sie hat meistens ihr iPhone oder iPad in der nähe. Passiert aber nichts, also haben wir beide dass verpennt, beginnen 20 Minuten vor der Scharfschaltung diverse Lampen an zu blinken. Wird dass 5 Minuten ignoriert, könnten wir uns 15 Minuten später am satten Sound der Sirene erfreuen. ;)
Seit dem ist aber der Fall nie mehr eingetreten.
Fehlalarme sind so ungefähr das lästigste was man in einem SmartHome gebrauchen kann.
Grüße, Josef
Hallo zusammen,
Danke für eure Antworten!
Ich habe die ganze fhem.cfg auf Hinweise bezüglich Sirene und entsprechenden notifies durchsucht,
aber nichts Auffälliges gefunden.
Anscheinend war das Flutlicht am Carport auch an.
Alle drei, die Sirene, der Bewegungsmelder und das Flutlicht sind zWave-Devices.
Kann es sein, dass durch ungeschickte Assoziationen der Devices der Bewegungsmelder von alleine einen Alarm an den beiden Anderen auslöst,
ohne dass FHEM überhaupt etwas davon mitbekommt?
Gruß
Markus
ZitatKann es sein, dass durch ungeschickte Assoziationen der Devices der Bewegungsmelder von alleine einen Alarm an den beiden Anderen auslöst, ohne dass FHEM überhaupt etwas davon mitbekommt?
Ja. Wer wen benachrichtigt kriegt man mit "get <Geraet> associationAll".
Hallo Rudolf,
Vielen Dank für Deine Antwort!
Bei der Sirene ergibt get <Geraet> associationAll
2016.10.07 18:19:09 3: ZWave get SireneWohnzimmer associationGroups
2016.10.07 18:19:09 3: ZWave get SireneWohnzimmer association 1
Beim Bewegungsmelder:
ZWave get CarportBewegungsmelder associationGroups
Da fehlt vielleicht noch der zweite Teil? Wo bei auch nach längerem Warten nichts mehr im Log auftaucht.
Beim Flutlicht:
2016.10.07 18:26:21 3: ZWave get CarportFlutlicht associationGroups
2016.10.07 18:26:21 3: ZWave get CarportFlutlicht association 1
2016.10.07 18:26:21 3: ZWave get CarportFlutlicht association 2
2016.10.07 18:26:21 3: ZWave get CarportFlutlicht association 2
2016.10.07 18:26:21 3: ZWave get CarportFlutlicht association 3
2016.10.07 18:26:21 3: ZWave get CarportFlutlicht association 3
Die Frage, die sich mir stellt: "Wie bekomme ich die Kontrolle zurück?"
Sprich, was muss ich tun, damit alles ausschließlich über FHEM läuft?
Gruß
Markus
Bitte poste die Ausgabe von "list <device>" der betroffenen Geraete. Dort sieht man das Ergebnis der Abfragen in den Readings (bei Wake_UP-Geraete erst nach dem naechsten erfolgreichen WakeUP!).
Du hast nur die Auflösung der Sammelabfrage (..All) in die Einzelabfragen (associationGroups, association..) gepostet.
Alles klar.
Hier die Lists:
Sirene:
Internals:
DEF fd1cb8e9 6
IMAGE /fhem/deviceimages/zwave/bac8e93650a4966a3aa518fc2ef01124fb663cb8.png
IODev ZWDongle_0
NAME SireneWohnzimmer
NR 43
STATE off
TYPE ZWave
ZWaveSubDevice no
homeId fd1cb8e9
nodeIdHex 06
Readings:
2016-10-07 18:19:09 assocGroup_1 Max 5 Nodes ZWDongle_0
2016-10-07 18:19:09 assocGroups 1
2016-10-07 18:52:33 model Aeotec DSD31 Siren Gen5
2016-10-07 18:52:33 modelConfig aeotec/dsd31.xml
2016-10-07 18:52:33 modelId 0086-0004-0050
2016-10-07 13:13:47 state off
2016-10-07 18:52:33 timeToAck 0.026
2016-10-07 18:52:33 transmit OK
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO SWITCH_BINARY CONFIGURATION ASSOCIATION ASSOCIATION_GRP_INFO MANUFACTURER_SPECIFIC SCENE_ACTIVATION SCENE_ACTUATOR_CONF VERSION FIRMWARE_UPDATE_MD POWERLEVEL SECURITY MARK DEVICE_RESET_LOCALLY HAIL BASIC
icon audio_volume_high
neighborListPos 536.7656035700221,54.830407096511784
room Alarm,Wohnzimmer,ZWave
vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 HAIL:1 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SCENE_ACTIVATION:1 SCENE_ACTUATOR_CONF:1 SECURITY:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2
Bewegungmelder:
Internals:
DEF fd1cb8e9 11
IMAGE
IODev ZWDongle_0
NAME CarportBewegungsmelder
NR 57
STATE 0
TYPE ZWave
ZWaveSubDevice no
homeId fd1cb8e9
nodeIdHex 0b
Readings:
2016-10-07 09:31:14 UNPARSED BASIC 03200504
2016-10-07 18:02:00 basicSet 0
2016-10-07 18:02:00 battery low
2016-10-07 18:07:14 timeToAck 0.050
2016-10-07 18:07:14 transmit OK
2016-10-07 18:07:11 wakeup notification
Attributes:
IODev ZWDongle_0
classes SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY MARK BASIC ALARM
icon IR
neighborListPos 607.4336980503906,15.481336348834734
room Carport,ZWave
stateFormat {ReadingsVal('CarportBewegungsmelder','basicSet','')}
vclasses ASSOCIATION:1 BASIC:1 BATTERY:1 CONFIGURATION:1 MANUFACTURER_SPECIFIC:1 SENSOR_BINARY:1 VERSION:1
Flutlicht (zwave U-putz Relais):
Internals:
DEF fd1cb8e9 10
IMAGE /fhem/deviceimages/zwave/271.514.4098_fgs222.double.relay.switch.jpg
IODev ZWDongle_0
NAME CarportFlutlicht
NR 52
STATE associationAdd 3 1
TYPE ZWave
ZWaveSubDevice no
endpointChildren ZWave_SWITCH_BINARY_10.01,CarportAussenlampen
homeId fd1cb8e9
nodeIdHex 0a
Readings:
2016-10-07 18:26:21 assocGroup_1 Max 5 Nodes ZWDongle_0
2016-10-07 18:26:21 assocGroup_2 Max 5 Nodes
2016-10-07 18:26:21 assocGroup_3 Max 1 Nodes ZWDongle_0
2016-10-07 18:26:21 assocGroups 3
2016-10-07 18:35:29 model FIBARO System FGS222 Double Relay Switch 2x1.5kW
2016-10-07 18:35:29 modelConfig fibaro/fgs222.xml
2016-10-07 18:35:29 modelId 010f-0202-1002
2016-10-07 13:10:58 reportedState on
2016-10-07 18:35:29 state associationAdd 3 1
2016-10-07 18:35:30 timeToAck 1.056
2016-10-07 18:35:30 transmit OK
Attributes:
IODev ZWDongle_0
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
icon building_carport_light
neighborListPos 281.8461739249674,14.741397153334518
room Licht,Carport,ZWave
vclasses ASSOCIATION:2 CONFIGURATION:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL:2 MULTI_CHANNEL_ASSOCIATION:1 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:1
Ich hoffe, die Teile waren wach genug, um alles rauszurücken.
Gruß
Markus
Zitat von: MarkusAutomaticus am 07 Oktober 2016, 19:10:09
Ich hoffe, die Teile waren wach genug, um alles rauszurücken.
Hmm, bei der Abfrage des Bewegungsmelders stimmt etwas nicht. Readings zu association.* sind nicht vorhanden. Der Wakeup-Sendstack ist aber leer. Es gibt auch keine modelId=kein DeviceImage.
Ich sehe beim Problemgeraet Sirene keinen anderen Auslöser für Alarm als das Dongle. Also löst Du den ungewollten Alarm wohl über FHEM aus oder hast an der Sirene etwas in der Config komisch eingestellt.
Btw:
stateFormat {ReadingsVal('CarportBewegungsmelder','basicSet','')kannst Du mMn einfacher so schreiben:
stateFormat basicSet
Hallo Markus!
Laurt Deinen Logauszügen hast Du ein
get <Geraet> associationGroups
und kein
get <Geraet> associationAll
abgesetzt!
Danach nicht im Log, sondern in den Readings des Gerätes nachschauen!
LG
Rainer
Zitat von: gamauf am 07 Oktober 2016, 19:40:34
Hallo Markus!
Laurt Deinen Logauszügen hast Du ein
get <Geraet> associationGroups
und kein
get <Geraet> associationAll
abgesetzt!
Markus hat das soweit ich das erkenne schon richtig gemacht. "get <device> assciationAll" ist kein einfacher ZWave-Befehl, sondern ein Sammelbefehl/Funktion von FHEM, der nacheinander mehrere ZWave-Befehle absetzt: Zunaechst "get <device> associationGroups" und dann entsprechend dem Ergebnis dieser Abfrage alle AsscoicationGroups mit "get <device> association <group>" nacheinander abfragt. Entsprechend wird das auch im Log protokolliert.
Hallo zusammen,
irgendwie komme ich hier nicht recht weiter.
Als ersten Schritt habe ich mit den anderen Familienmitgliedern zusammen versucht herauszufinden.
welcher Sirenenton am Schonendsten ist.
Aber selbst die Mindestlautstärke von 88dB ist unerträglich, wenn die Sirene direkt über der Couch an der Decke ist.
(Ich hatte da früher einen Beamer, weshalb da jetzt praktischerweise eine Steckdose ist)
Ausstecken möchte ich die Sirene aber auch nicht, weil sie der zentrale zWave-Router ist.
Dann habe ich eine Suche über das gesamte /opt/fhem Verzeichnis inkl. Unterverzeichnisse nach Dateien gemacht, die das Wort "Sirene" enthalten.
Aber auch da schien alles seine Richtigkeit zu haben.
Kann man denn den Bewegungsmelder wieder in einen Zustand versetzen, beim dem alle überflüssigen Assoziationen gelöscht sind?
Exkludieren?
Werksresett?
associationDel?
Was ist die praktikabelste Lösung?
Gruß
Markus
Zitat von: MarkusAutomaticus am 10 Oktober 2016, 09:19:57
Hallo zusammen,
irgendwie komme ich hier nicht recht weiter.
[...]
associationDel?
Was ist die praktikabelste Lösung?
Gruß
Markus
Hallo Markus,
natürlich ist associationDel die feinste Lösung.
Aber das list Deines Bewegungsmelder scheint nicht komplett zu sein, habe gar keine Ahnung was dass sein könnte, aber die Batterie solltest Du schon tauschen. Ansonsten sehe ich keine Assotiationen in den devices.
Grüße, Josef
Zitat von: krikan am 07 Oktober 2016, 20:37:30
... "get <device> assciationAll" ist kein einfacher ZWave-Befehl, sondern ein Sammelbefehl/Funktion von FHEM, der nacheinander mehrere ZWave-Befehle absetzt: Zunaechst "get <device> associationGroups" und dann entsprechend dem Ergebnis dieser Abfrage alle AsscoicationGroups mit "get <device> association <group>" nacheinander abfragt. Entsprechend wird das auch im Log protokolliert.
ja, eben! Hab ja geschrieben, daß ein "get <device> associationGroups" alleine nicht reicht, sondern ein "get <device> assciationAll" abgesetzt werden sollte.
@Markus:
poste doch bitte nochmal des vollständige Listing des Bewegungsmelders. Also erst
"get CarportBewegungsmelder assciationAll"
danach
"list CarportBewegungsmelder"
Hallo zusammen,
anbei das Resultat von get CarportBewegungsmelder assciationAll
Internals:
DEF fd1cb8e9 11
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 65
NAME CarportBewegungsmelder
NR 57
STATE 0
TYPE ZWave
ZWDongle_0_MSGCNT 65
ZWDongle_0_RAWMSG 0004040b038003ff
ZWDongle_0_TIME 2016-10-10 13:19:27
ZWaveSubDevice no
homeId fd1cb8e9
isWakeUp 1
lastMsgSent 1476095915.11242
nodeIdHex 0b
Readings:
2016-10-07 09:31:14 UNPARSED BASIC 03200504
2016-10-10 13:19:24 basicSet 0
2016-10-10 13:19:27 battery low
2016-10-10 12:38:35 timeToAck 0.026
2016-10-10 12:38:35 transmit OK
2016-10-10 12:38:33 wakeup notification
SendStack:
get:130b0285052536
Attributes:
IODev ZWDongle_0
classes SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY MARK BASIC ALARM
icon IR
neighborListPos 607.4336980503906,15.481336348834734
room Carport,ZWave
stateFormat {ReadingsVal('CarportBewegungsmelder','basicSet','')}
vclasses ASSOCIATION:1 BASIC:1 BATTERY:1 CONFIGURATION:1 MANUFACTURER_SPECIFIC:1 SENSOR_BINARY:1 VERSION:1
Dass bereits nach 3,5 Monaten die Batterien den Status "Low" haben, finde ich ärgerlich.
Nicht dass die Falschmeldungen daher rühren?!
Gruß
Markus
Hi Markus,
Zitatanbei das Resultat von get CarportBewegungsmelder assciationAll
der Befehl liegt immer noch auf dem SendStack. Du musst das Gerät aufwecken das Du die aktuellen Informationen erhälst. Und wenn Du schon dabei bist, setz bitte vor dem Aufwecken ein get configAll ab. ;)
Grüße, Josef
Zitat von: jeep am 10 Oktober 2016, 15:27:49
Und wenn Du schon dabei bist, setz bitte vor dem Aufwecken ein get configAll ab. ;)
Hallo Josef,
get configAll erzeugt eine Messagebox mit folgendem Inhalt:
configAll: no model specific configs foundIch spendier dem Teil mal einen Satz frische Batterien
Gruß
Markus
ich glaub' da ist beim Inkludieren schon 'was schiefgelaufen..
vielleicht kann man es mit "get <device> model" noch geradeziehen...
Zitat von: MarkusAutomaticus am 10 Oktober 2016, 17:43:54
Hallo Josef,
get configAll erzeugt eine Messagebox mit folgendem Inhalt:
configAll: no model specific configs found
Ich spendier dem Teil mal einen Satz frische Batterien
Gruß
Markus
Hi Markus,
dass hat ja scheinbar schon mal alles funktioniert. Möglich ist natürlich dass nach der Übernahme vom RPi auf dem NUC noch was im Unstand ist. Wenn das "get devicename model" nichts bringt, hilft vermutlich nur exclusion und neue inclusion. Dann bist Du auch eventuell ungewollte associations los. Aber vielleicht kanst Du uns schon mal sagen was für ein Bewegungsmelder das ist, Fibaro, Aeotec, etc.
Grüße, Josef
Zitat von: jeep am 10 Oktober 2016, 19:22:20
Aber vielleicht kanst Du uns schon mal sagen was für ein Bewegungsmelder das ist, Fibaro, Aeotec, etc.
Hallo Josef,
da ich das Ding im Freien (wenn auch unter dem Carportdach) betreibe, sind die üblichen Verdächtigen von Fibaro und Aeotec ausgeschieden.
Ich habe stattdessen dieses Prachtexemplar verwendet, welches schon von Anfang an leicht unrund lief:
Everspring Bewegungsmelder-Z-Wave (EVR_SP103) Das mit dem Excludieren und Includieren werde ich auf jeden Fall machen, sobald ich eine möglicherweise geignetere Stelle gefunden habe.
Wenn man sich die Anleitung eines solchen PIR nämlich genauer durchliest, gibt es einige Ausschlusskriterien:
- kein direktes Sonnenlicht
- nicht gegenüber einem Fenster
- keine Zugluft (ohne Scheiß ::))
- nicht in der Nähe von Wärmequellen
- etc...
Wenn man dann noch berücksichtigen will, dass
- Bewegung auf dem angrenzen Fußweg/Straße nicht erfasst werden soll
- man das Teil nicht einfach im Vorbeigehen abpflücken können soll
- trotzdem der gesamte Bereich überwacht werden soll, ohne dass man hinten dran vorbeilaufen kann
Könnte man einen Studenten eine Seminararbeit über den Aufstellungsort schreiben lassen ::)
Gruß
Markus
Zitat von: MarkusAutomaticus am 11 Oktober 2016, 09:11:48
Ich habe stattdessen dieses Prachtexemplar verwendet, welches schon von Anfang an leicht unrund lief:
Everspring Bewegungsmelder-Z-Wave (EVR_SP103)
Hallo Markus,
besten Dank für die Info. Hatte schon befürchtet das Du einen Fibaro MS-001 hast. Den würde ich an Deiner Stelle versuchen.
Ich beabsichtige nämlich zwei Stück Fibaro MS-001 im Aussenbereich zu plazieren, eines auch unter dem Dach. Mit dem zweiten, der an an der Markise montiert wird, will ich versuchen mit der Tamper Funktion die Markise bei aufkommenden Wind einzufahren. Das POPP ZWeather ist dazu nicht geeignet da für mich zu träge.
Ja, so wie Du dass beschreibst, Bedarf der Auffstellungsort des EVR_SP103 scheinbar wirklich wissenschaftlichen analysen.
Sollte nach Batterietausch und neuer Inclusion keine Besserung der Situation eintreten, würde ich ein anderes Produkt empfehlen.
Grüße, Josef
Hallo Josef,
der MS-001 ist doch "das Auge" oder nicht?
Die sind doch weder für den Außenbereich gedacht, noch vandalismussicher.
Mit andern Worten: man kann den "Augapfel" ganz einfach aus der Fassung pflücken.
Es würde mich nicht mal wundern wenn das Teil runterfällt, wenn Kinder einen Ball gegen einen der Pfosten kicken.
Im Innenbereich habe ich auch zwei davon, aber da geht es potentiell auch weniger rau zu.
Gruß
Markus
Zitat von: MarkusAutomaticus am 11 Oktober 2016, 15:54:17
der MS-001 ist doch "das Auge" oder nicht?
Die sind doch weder für den Außenbereich gedacht, noch vandalismussicher.
Hallo Markus,
da mein Grundstück abseits der Straße liegt und der Zugang über einen 30 Meter langen Privatweg führt, ist das kein Thema. Ich habe unter der Dachschräge auch eine Axis Indoor Kamera, die hat bis jetzt 4 kalte Winter und heiße Sommer überlebt. Ich denke das Auge wird es auch überleben, da am Aufstellungsort kein Regen, Wind, oder direkte Sonneneinstrahlung ist.
Grüße, Josef
So, das Teil ist wieder montiert.
Bisher habe ich nur
set ZWDongle_0 addnode on
und
set CarportPIR associationAdd 01 01
durchgeführt, sowie versucht, das WakeUpInterval zu verkürzen.
Hier ist das List:
Internals:
CFGFN
DEF fd1cb8e9 18
IMAGE /fhem/deviceimages/zwave/bead0dfe2907fb1c41613658ca76b8ae1f07f487.jpg
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 1623
NAME CarportPIR
NR 30244
STATE wakeupInterval 86400 1
TYPE ZWave
ZWDongle_0_MSGCNT 1623
ZWDongle_0_RAWMSG 00040012028407
ZWDongle_0_TIME 2016-10-12 10:19:15
ZWaveSubDevice no
homeId fd1cb8e9
isWakeUp 1
lastMsgSent 1476260357.28076
nodeIdHex 12
Readings:
2016-10-11 16:55:11 CMD ZW_APPLICATION_UPDATE
2016-10-11 17:03:10 UNPARSED BASIC 03200000
2016-10-11 16:54:47 alarm_type_01 level 11
2016-10-12 10:10:49 basicSet 0
2016-10-11 19:58:54 configONPhaseLevel 255
2016-10-11 19:58:54 configPowerSaving 0
2016-10-11 22:01:33 model Everspring SP103 PIR Motion Sensor
2016-10-11 22:01:33 modelConfig everspring/sp103.xml
2016-10-11 22:01:33 modelId 0060-0101-0001
2016-10-11 20:41:42 neighborList ZWDongle_0 HzgKinderBad SireneWohnzimmer
2016-10-11 18:57:52 neighborUpdate failed
2016-10-11 16:48:54 state wakeupInterval 86400 1
2016-10-12 10:19:17 timeToAck 0.223
2016-10-12 10:19:17 transmit OK
2016-10-12 10:19:15 wakeup notification
Attributes:
IODev ZWDongle_0
classes SENSOR_BINARY CONFIGURATION WAKE_UP MANUFACTURER_SPECIFIC VERSION ASSOCIATION BATTERY MARK BASIC ALARM
icon IR
room Alarm,Aussenbereich,Carport,ZWave
vclasses ASSOCIATION:1 BASIC:1 BATTERY:1 CONFIGURATION:1 MANUFACTURER_SPECIFIC:1 SENSOR_BINARY:1 VERSION:1 WAKE_UP:1
Der angelegte Plot zeigt schön die erkannten Bewegungen, nur die Notifies wollen nicht so richtig.
Kann mir bitte mal einer auf die Sprünge helfen, wie ich hier die Bewegung abgreife?
define n_CarporBewegung notify CarportPIR.basicSet:255 set JarviTTS tts Bewegung beim Carport
will noch nicht so richtig.
Gruß
Markus
Hallo Markus!
Setze einmal im Event monitor den Filter
CarportPIR.*
und dann spazier am Bewegungsmelder vorbei.
Danach poste bitte hier den Output des Event monitor.
Außerdem kann's nicht schaden nach eimem
get CarportPIR assotioationAll
get CarportPIR config All
get CarportPIR version
und abwarten des nächsten Wakeup das List nochmal zu posten.
Grüße
Rainer
Hallo Rainer,
vielen Dank für deine Antwort.
Leider bekomme ich das mit dem Filtern der Events nicht hin.
Im Wiki steht vor einem best. Datum müsse der Filter in die URL geschrieben werden.
Da ich mein FHEM fast täglich aktualisiere ist für mich eher die zweite Variant gültig:
ZitatDer Filter muss nicht mehr über eine Anpassung der URL, sondern kann direkt im Event Monitor dialogunterstützt eingestellt werden
Allerdings erschließt sich mir nicht, wo der Einstieg in besagten Dialog ist.
Gruß
Markus
Ok, ok,
hätte ich noch ein wenig weiter im Wiki gelesen, hätte ich es selber gefunden.
Man muss also auf das .* drücken, um zu dem Filter-Dialog zu kommen.
Das lässt mich spontan an die alten Edgar Wallace Filme denken,
wo man in einer Bibliothek ein bestimmtes Buch aus dem Regal ziehen muss, um eine Geheimtür zu öffnen.
Im Film geht es darum, die Geheimtür zu verbergen, aber im Frontend von FHEM?
Warum gibt es nicht etwas Buttonähnliches, auf dem "Filter" steht?
Grübel ::)
Zitat von: gamauf am 13 Oktober 2016, 14:17:03
Hallo Markus!
Setze einmal im Event monitor den Filter
CarportPIR.*
und dann spazier am Bewegungsmelder vorbei.
Danach poste bitte hier den Output des Event monitor.
Hallo Rainer,
Die nach CarportPIR.* gefilterten Events ergeben Folgendes (Auszug):
..
2016-10-13 16:05:11 ZWave CarportPIR basicSet: 0
2016-10-13 16:05:11 ZWave CarportPIR basicSet: 255
2016-10-13 16:05:12 ZWave CarportPIR basicSet: 0
2016-10-13 16:05:12 ZWave CarportPIR basicSet: 255
2016-10-13 16:05:13 ZWave CarportPIR basicSet: 0
...
Dabei tritt
255 auf, wenn man durch den aktiven Bereich des PIR-Fächers läuft.
Darauf wäre also das
notify zu triggern.
Zitat von: gamauf am 13 Oktober 2016, 14:17:03
Außerdem kann's nicht schaden nach eimem
get CarportPIR assotioationAll
get CarportPIR config All
get CarportPIR version
und abwarten des nächsten Wakeup das List nochmal zu posten.
Grüße
Rainer
Hab ich abgesetzt und poste das Ergebnis, wenn es da ist.
Gruß
Markus
Hallo Markus!
Das <pattern> im http://fhem.de/commandref.html#notify hat den Aufbau:
Zitat<pattern> is either the name of the triggering device, or devicename:event.
Also bei Dir so etwas in der Art:
CarportPIR:basicSet..255Gruß, Christian
Hallo Christian,
danke für deine Antwort!
Ich habe deinen Code
CarportPIR:basicSet..255
eingegeben, aber warum zwischen basicSet und 255 zwei Punkte kommen,
ist mir unklar.
Hat vermutlich mit Perl und/oder regular expressions zu tun?
Aber egal! Es funktioniert! Gerade kam ein Telegram "Bewegung beim Carport" auf die SmartWatch :D ;D :D ;D
Vielen Dank allen Threadschreibern!
Das hätte ich alleine nicht hinbekommen.
Gruß
Markus
PS.: um zum Topic zurückzukommen: Fehlalarme sind bisher auch keine mehr vorgekommen