Hallo,
ich verwende zur Statusbestimmung meines Garagentors einen optischen Tür/Fensterkontakt. Dabei soll der Sensor bei Änderung des Status eine Pushnachricht via PushOver an mich senden. Das macht er auch, jedoch macht er das alle 50-60 Minuten.
Lässt sich diese regelmäßige Statusmeldung abschalten?
Grüße Markus
Hallo,
Schaue mal nach 'event-on-change-reading'
Also beispielsweise:
attr DeviceName event-on-change-reading .*
Damit werden nur noch Events bei Änderung gefeuert...
Gruß, Joachim
Hat super funktioniert.
Herzlichen Dank
Hat doch nicht so ganz funktioniert. Heute um 01:27 wurde erneut eine unnötige Statusmeldung verschickt. Gibt es da vielleicht noch etwas, was deaktiviert werden muss?
Hallo,
eigentlich sollte nur noch ein Event erzeugt werden, wenn sich der Zustand ändert.
Hast du eine Logdatei für das Gerät?
Evtl. steht das was drin, dass sich der Zustand doch mal geändert hat?
(Obwohl für dich "unnötig", da ja das Fenster/Tür nicht wirklich geöffnet war!?)
Schickst du die Nachricht per notify!?
Wie ist das definiert?
Nicht dass es bei einem weiteren (ähnlichen) Event triggert, der sich auch ohne auf/zu ändert und dann eine für dich unnötige Nachricht schickt...
Gruß, Joachim
Hallo Joachim,
die Nachricht wird über ein Notify versandt.
Die Def dazu lautet:
Tor_Sen1:closed { system("curl -s -F 'token=MeinToken' -F 'user=MeinUser' -F 'message=Garagentor wurde geschlossen' https://api.pushover.net/1/messages.json")}
Tor_Sen1 Log von 26.06.16 bis heute:
2016-06-26_00:31:59 Tor_Sen1 alive: yes
2016-06-26_00:31:59 Tor_Sen1 battery: ok
2016-06-26_00:31:59 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_00:31:59 Tor_Sen1 sabotageError: off
2016-06-26_00:31:59 Tor_Sen1 closed
2016-06-26_01:28:32 Tor_Sen1 alive: yes
2016-06-26_01:28:32 Tor_Sen1 battery: ok
2016-06-26_01:28:32 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_01:28:32 Tor_Sen1 sabotageError: off
2016-06-26_01:28:32 Tor_Sen1 closed
2016-06-26_02:20:59 Tor_Sen1 alive: yes
2016-06-26_02:20:59 Tor_Sen1 battery: ok
2016-06-26_02:20:59 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_02:20:59 Tor_Sen1 sabotageError: off
2016-06-26_02:20:59 Tor_Sen1 closed
2016-06-26_03:17:16 Tor_Sen1 alive: yes
2016-06-26_03:17:16 Tor_Sen1 battery: ok
2016-06-26_03:17:16 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_03:17:16 Tor_Sen1 sabotageError: off
2016-06-26_03:17:16 Tor_Sen1 closed
2016-06-26_11:25:51 Tor_Sen1 contact: open (to broadcast)
2016-06-26_11:25:51 Tor_Sen1 open
2016-06-26_11:25:51 Tor_Sen1 trigger_cnt: 22
2016-06-26_11:26:25 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_11:26:25 Tor_Sen1 closed
2016-06-26_11:26:25 Tor_Sen1 trigger_cnt: 23
2016-06-26_11:27:44 Tor_Sen1 contact: open (to broadcast)
2016-06-26_11:27:44 Tor_Sen1 open
2016-06-26_11:27:44 Tor_Sen1 trigger_cnt: 24
2016-06-26_11:28:14 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_11:28:14 Tor_Sen1 closed
2016-06-26_11:28:14 Tor_Sen1 trigger_cnt: 25
2016-06-26_19:55:06 Tor_Sen1 contact: open (to broadcast)
2016-06-26_19:55:06 Tor_Sen1 open
2016-06-26_19:55:06 Tor_Sen1 trigger_cnt: 26
2016-06-26_19:55:15 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_19:55:15 Tor_Sen1 closed
2016-06-26_19:55:15 Tor_Sen1 trigger_cnt: 27
2016-06-26_20:20:14 Tor_Sen1 contact: open (to broadcast)
2016-06-26_20:20:14 Tor_Sen1 open
2016-06-26_20:20:14 Tor_Sen1 trigger_cnt: 28
2016-06-26_20:21:18 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_20:21:18 Tor_Sen1 closed
2016-06-26_20:21:18 Tor_Sen1 trigger_cnt: 29
2016-06-26_20:24:25 Tor_Sen1 contact: open (to broadcast)
2016-06-26_20:24:25 Tor_Sen1 open
2016-06-26_20:24:25 Tor_Sen1 trigger_cnt: 30
2016-06-26_20:24:57 Tor_Sen1 contact: closed (to broadcast)
2016-06-26_20:24:57 Tor_Sen1 closed
2016-06-26_20:24:57 Tor_Sen1 trigger_cnt: 31
2016-06-27_00:27:13 Tor_Sen1 ResndFail
2016-06-27_00:27:13 Tor_Sen1 MISSING ACK
2016-06-27_01:27:06 Tor_Sen1 closed
2016-06-27_06:51:52 Tor_Sen1 contact: open (to broadcast)
2016-06-27_06:51:52 Tor_Sen1 open
2016-06-27_06:51:52 Tor_Sen1 trigger_cnt: 32
2016-06-27_06:53:04 Tor_Sen1 contact: closed (to broadcast)
2016-06-27_06:53:04 Tor_Sen1 closed
2016-06-27_06:53:04 Tor_Sen1 trigger_cnt: 33
Der Sensor schickt regelmäßig Statusmeldungen. Um 00:27 (27.06.16) war der Sensor wohl nicht erreichbar und um 01:27 hat er dann ein "closed" versandt, obwohl das Tor definitiv seit 20:24:57 (26.06.16) geschlossen war. Das hat mir dann das Notify ausgelöst.
Die einzelnen "closed" am 26.06 um 00:31:59, 01:28:32, 02:20:59 und 03:17:16 haben (im Sinne von Tor öffen/schliessen) so in der Realität nicht stattgefunden. Die wurden aber noch vor dem Einbau von "event-on-change-reading" gefeuert. Ich war lange wach und habe dieses Attribut so gegen halb vier Uhr früh eingebaut. Danach sind dann eigentlich wie gewünscht nur noch "open" und "closed" versandt worden. Scheinbar sendet der Sensor nachdem er wieder verfügbar ist den aktuellen Status.
Grüße Markus
Du könntest auch DOIF verwenden und auf open und closed triggern, dann wird erst wieder nach einem Zustandswechsel gesendet.
(["Tor_Sen1:^closed$"]) ({ system("curl ...)
DOELSEIF (["Tor_Sen1:^open$"])
Hallo,
sieht doch erst mal so aus, als ob jetzt nur noch abwechselnd open-closed käme.
War es "nur" das eine mal?
Oder trotzdem häufiger?
Für das eine mal könnte ein Sendefehler/Wiederholung schucld sein:
2016-06-26_20:24:57 Tor_Sen1 closed
2016-06-26_20:24:57 Tor_Sen1 trigger_cnt: 31
2016-06-27_00:27:13 Tor_Sen1 ResndFail
2016-06-27_00:27:13 Tor_Sen1 MISSING ACK
2016-06-27_01:27:06 Tor_Sen1 closed
Aber vielleicht ist das mit dem DOIF die Lösung...
Gruß, Joachim
Es ist in der Form bisher nur dieses eine Mal vorgekommen. MISSING ACK hatte ich aber bei diesem Sensor bereits einige Male. Grundsätzlich wäre es jetzt auch nicht so schlimm, aber um halb zwei Uhr Nachts kommt so eine Pushmitteilung im Schlafzimmer nicht so gut an (meine Frau hat keinen tiefen Schlaf) ;-)
Ich habe es nun mit dem Vorschlag von Ellert probiert, aber damit passiert garnichts. Es wird auch kein Log erzeugt. Vielleicht mache ich da auch was falsch.
(["Tor_Sen1:^closed$"]) ({ system("curl -s -F 'token=MeinToken' -F 'user=MeinUser' -F 'message=Garagentor wurde geschlossen' https://api.pushover.net/1/messages.json")}) DOELSEIF (["Tor_Sen1:^open$"])
Zitat von: maxxnet am 27 Juni 2016, 20:36:33
Es ist in der Form bisher nur dieses eine Mal vorgekommen. MISSING ACK hatte ich aber bei diesem Sensor bereits einige Male. Grundsätzlich wäre es jetzt auch nicht so schlimm, aber um halb zwei Uhr Nachts kommt so eine Pushmitteilung im Schlafzimmer nicht so gut an (meine Frau hat keinen tiefen Schlaf) ;-)
Ich habe es nun mit dem Vorschlag von Ellert probiert, aber damit passiert garnichts. Es wird auch kein Log erzeugt. Vielleicht mache ich da auch was falsch.
(["Tor_Sen1:^closed$"]) ({ system("curl -s -F 'token=MeinToken' -F 'user=MeinUser' -F 'message=Garagentor wurde geschlossen' https://api.pushover.net/1/messages.json")}) DOELSEIF (["Tor_Sen1:^open$"])
Gibt es eine Fehlermeldung im DEF-Editor beim Erstellen/Triggern des DOIF?
Mach bitte mal ein Listing vom DOIF.
Versuch mal, ob das DOIF mit Log-Befehl funktioniert, ggf. Regex anpassen:
(["Tor_Sen1:^closed$"]) ({ Log 1, "closed"})
DOELSEIF (["Tor_Sen1:^open$"]) ({ Log 1, "open"})
Im Editor wird kein Fehler angezeigt. Mit Log-Befehl kommt beim triggern
return value: Unknown command ({, try help
Zitat von: maxxnet am 27 Juni 2016, 22:39:37
Im Editor wird kein Fehler angezeigt. Mit Log-Befehl kommt beim triggern
return value: Unknown command ({, try help
Die Fehlermeldung kam von einem anderen Befehl. Der Log-Befehl schreibt demnach nichts ins Log.
Hi Ellert,
ich bin ja nicht (so) fit in der Nutzung von DOIF etc.
Aber wie würde DOIF helfen, wenn 2x closed kommt?
Nur so zum Verständnis, danke!
Gruß, Joachim
Aus der Einleitung der deutschsprachigen Befehlsreferenz des DOIF:
ZitatDas Modul merkt sich den zuletzt ausgeführten Ausführungszweig und wiederholt diesen standardmäßig nicht.
Hi Ellert,
ups, okok, Comandref ;-)
Vielen Dank!
Gruß, Joachim
2016-06-26_20:24:57 Tor_Sen1 closed
2016-06-27_00:27:13 Tor_Sen1 ResndFail
2016-06-27_00:27:13 Tor_Sen1 MISSING ACK
2016-06-27_01:27:06 Tor_Sen1 closed
da sich hier der state des devices geändert hat, wird für die regelmässige statusmeldung dann auch wieder ein event ausgelöst.
bei homematic würde ich (fast) immer nicht den state vom device überwachen, sondern ein anderes reading nutzen. davon gibt es ja mehr wie genug. für diesen fall das reading contact, da hier keine zusätzlichen protokollmeldungen auftauchen.
allerdings gibt es hierbei wahrscheinlich folgendes problem: sollte der contact gepeert sein, wird es jeweils 2 meldungen für closed/open geben: zb. "closed (to broadcast)" und "closed (to my_peer)".
Zitat von: frank am 28 Juni 2016, 09:56:12
2016-06-26_20:24:57 Tor_Sen1 closed
2016-06-27_00:27:13 Tor_Sen1 ResndFail
2016-06-27_00:27:13 Tor_Sen1 MISSING ACK
2016-06-27_01:27:06 Tor_Sen1 closed
da sich hier der state des devices geändert hat, wird für die regelmässige statusmeldung dann auch wieder ein event ausgelöst.
bei homematic würde ich (fast) immer nicht den state vom device überwachen, sondern ein anderes reading nutzen. davon gibt es ja mehr wie genug. für diesen fall das reading contact, da hier keine zusätzlichen protokollmeldungen auftauchen.
allerdings gibt es hierbei wahrscheinlich folgendes problem: sollte der contact gepeert sein, wird es jeweils 2 meldungen für closed/open geben: zb. "closed (to broadcast)" und "closed (to my_peer)".
Das DOIF https://forum.fhem.de/index.php/topic,54982.msg466679.html#msg466679 würde es abfangen, da nur auf closed/open getriggert wird, abwechselnd einmal.