(gelöst) HM-SEC-SD ändert STATE bei Alarm verzögert

Begonnen von Solero, 12 Dezember 2015, 15:56:01

Vorheriges Thema - Nächstes Thema

Solero

Hallo,

ich habe einen HM-SEC-SD (v1.1) der von einem aktuellen FHEM über einen HM-CFG-LAN gesteuert wird. Er hat seinen Virtuellen Lead und lässt sich grundsätzlich vollumfänglich darüber bedienen.

Das Problem ist, dass wenn ich über den Lead den alarmOn setze es mehrere Sekunden (im Schnitt 10) dauern kann, bis der Alarm wirlich losgeht. Ich habe einen Benachrichtigungsnotify, der bei mir das Licht anschaltet und eine E-Mail verschickt, wenn der Alarm los geht. Leider dauert es teilweise bis zu drei Minuten, bis aber "smoke_detect" und state im Melder und folglich auch Lead aktualisiert wird und der notify anschlägt.

Habe ich einen Parameter übersehen oder muss ich irgend eine Bursteinstellung anpassen, damit sowohl das alarmOn schneller geht (nicht ganz so wichtig) und die Benachrichtigung des Rauchmelders, dass er piept bei FHEM ankommt (sehr wichtig, sollte unter 5 Sekunden sein)?


Internals
DEF 12345B
HMLAN1_MSGCNT 2
HMLAN1_RAWMSG R12345678,0001,001234567,FF,FFC9,123456789012345678912345678
HMLAN1_RSSI -55
HMLAN1_TIME 2015-12-11 19:07:54
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 2
NAME RauchmelderFlur
NR 63
STATE off
TYPE CUL_HM
lastMsg No:03 - t:10 s:12345B d:123456 1234567890
peerList RauchmelderTeam
protLastRcv 2015-12-11 19:07:54
protSnd 2 last_at:2015-12-11 19:07:54
protState CMDs_done
rssi_HMLAN1 avg:-53 min:-53 max:-53 lst:-53 cnt:1
rssi_at_HMLAN1 avg:-55 min:-55 max:-55 lst:-55 cnt:2

Readings
Activity alive
CommandAccepted yes
D-firmware 1.1
D-serialNr LTK0123456
PairedTo 0x1234567
R-pairCentral 0x1234567
RegL_00: 02:12 0A:34 0B:56 0C:78 00:90
battery ok
level 1
peerList RauchmelderTeam,
powerOn 2015-11-14 00:25:33
recentStateType info
smoke_detect -
state off
teamCall from TeamVirtuell:1

Attributes
IODev HMLAN1
actCycle 099:00
actStatus alive
alias Rauchmelder Flur
autoReadReg 5_readMissing
expert 2_full
firmware 1.1
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,11111101
room Flur
serialNr LTK12345678
subType smokeDetector
webCmd statusRequest

RaspberryPi 4 (4GB) mit Raspbian und FHEM als Docker-Container; Homematic, CCU3, HM-LC-Dim1TPBU-FM, HM-LC-Sw1PBU-FM, HM-ES-PMSw1-Pl, HM-SEC-SD-2; Z-Wave, ZME_UZB1, FGRM222; CUL; Enocean, TCM_ESP3, PTM-215, Tasmota

LuckyDay

ZitatPairedTo      0x1234567

cool 7 stellig gepairt, wie geht das?

frank

PairedTo 0x1234567
was soll es bringen ein list zu posten, dass komplett von dir verändert ist?
noch nicht einmal in sich schlüssig, zudem an vielen stellen falsch.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Mach dir keine Gedanken um Sicherheit. Dein Nachbar kann, bis auf AES Schlüssel, alle messages lesen. Die ID deiner zentrale ist kein Geheimnis

Solero

#4
Der Rauchmelder ist bei mir per autocreate eingebunden und hat einen virtuellen Teamlead, ich kann seinen Status auslesen, ihn manuell in alarmOn und alarmOff versetzen. Er tut alles was er können soll, nur zu langsam.

Die ID sollte folglich keine Rolle spielen. Neben dem Zuordnen zu einem Team habe ich nur autoReadReg 5_readMissing gesetzt, da ich hier leider erfolglos eine möglich Ursache vermutete.

Meine Frage lautet also, ob das Phänomen der teilweise minutenlangen Verzögerung des Status bei Alarmauslösung schon bei anderen neu eingerichteten HM-SEC-SD beobachtet wurde oder möglicherweise die Hardware des Rauchmelders nicht so richtig will und ein Defekt vorliegen könnte? Meine HM-LC-Sw1PBU-FM sind deutlich fixer darin ihren Status zu updaten.

Wie lange dauert es bei euch, bis sich das reading in FHEM geändert hat, wenn der Rauchmelder los geht?
RaspberryPi 4 (4GB) mit Raspbian und FHEM als Docker-Container; Homematic, CCU3, HM-LC-Dim1TPBU-FM, HM-LC-Sw1PBU-FM, HM-ES-PMSw1-Pl, HM-SEC-SD-2; Z-Wave, ZME_UZB1, FGRM222; CUL; Enocean, TCM_ESP3, PTM-215, Tasmota

martinp876

Kannst du die Verzögerung genauer beschreiben?
Tritt sie beim versuchen eines SD auf oder beim auslösen eines alarms über den teamlead?
Geht es um den alarm oder den status im fhem oder beides?
Wenn es um Meldungen geht werde ich es mir ansehen, cool ist eine Beschreibung des Probleme mit messages log

Sollte die Erkennung im SD zu langsam sein bin ich raus

Solero

Wenn ich den SD über seinen teamlead auslöse dauert es unter 10 Sekunden, bis der Alarm wirklich losgeht. Das ist OK, wie ich finde.
Ich gehe dabei davon aus, dass der SD ab Empfang des Signals sofort piepst, ich habe bisher kein Testspray und möchte die Detektionskammer nicht unnötig mit Rauch belasten, nur um ihn zu testen.
Der SD piepst nun munter vor sich hin und jetzt beginnt der für mich interessante Zeitraum. Wie lange dauert es, bis ich den Alarm in FHEM in einer Statusänderung sehe und mir smoke_detect den auslösenden SD zeigt (in diesem Fall TeamVirtuell, da ich ihn darüber ausgelöst habe).

Als Maximum habe ich 75 Sekunden im Log finden können (Die drei Minuten in meinem ersten Post waren wohl zu hoch gegriffen). Gesternnacht hatte ich noch event-on-change-reading .* im SD gesetzt (im TeamLead war es bereits von mir gesetzt). Kürzeste Zeiten sind jetzt 7 Sekunden und als längste 35 Sekunden.

Ich verstehe hierbei einfach nicht, warum es so lange dauert. Der SD sollte sofort den State an fhem schicken, sobald er piepst.
Kommt ein Signal verzögert beim SD an kann ich das verstehen, weil ein Befehl vielleicht nicht als burst gesendet wird. Aber vom SD zu fhem sollte es doch in unter einer Sekunde klappen, schließlich lauscht fhem doch nonstop auf Befehle. Drehe ich an der Temperatur meines HM-CC-RT-DN sehe ich das unter 5 Sekunden später in fhem.

Eine Idee ist noch dass der SD nicht sofort sendet, weil er selbst den Alarm nicht ausgelöst hat, sondern nur den Befehl zum "mitpiepsen" bekam. Bräuchte ich evtl. doch Testspray, um das herauszufinden?

2015.11.20 20:27:57 3: CUL_HM set RauchmelderTeam alarmOn
2015.11.20 20:29:12 3: CUL_HM set LampeWzDF on

2015.12.13 00:53:00 3: CUL_HM set RauchmelderTeam alarmOn
2015.12.13 00:53:07 3: CUL_HM set LampeSzD on
2015.12.13 00:53:07 3: CUL_HM set LampeWzDF on
2015.12.13 00:53:14 3: CUL_HM set LampeWzDF statusRequest
2015.12.13 00:53:48 3: CUL_HM set RauchmelderTeam alarmOff
2015.12.13 00:54:59 3: CUL_HM set RauchmelderTeam alarmOn
2015.12.13 00:55:23 3: CUL_HM set LampeSzD on
2015.12.13 00:55:23 3: CUL_HM set LampeWzDF on
2015.12.13 00:55:30 3: CUL_HM set LampeWzDF statusRequest
2015.12.13 00:55:42 3: CUL_HM set RauchmelderTeam alarmOff
2015.12.13 00:57:35 3: CUL_HM set RauchmelderTeam alarmOn
2015.12.13 00:57:54 3: CUL_HM set LampeSzD on
2015.12.13 00:57:54 3: CUL_HM set LampeWzDF on
2015.12.13 00:58:01 3: CUL_HM set LampeWzDF statusRequest
2015.12.13 00:58:03 3: CUL_HM set RauchmelderTeam alarmOff
2015.12.13 00:59:39 3: CUL_HM set RauchmelderTeam alarmOn
2015.12.13 01:00:16 3: CUL_HM set LampeSzD on
2015.12.13 01:00:16 3: CUL_HM set LampeWzDF on
2015.12.13 01:00:20 3: CUL_HM set RauchmelderTeam alarmOff
RaspberryPi 4 (4GB) mit Raspbian und FHEM als Docker-Container; Homematic, CCU3, HM-LC-Dim1TPBU-FM, HM-LC-Sw1PBU-FM, HM-ES-PMSw1-Pl, HM-SEC-SD-2; Z-Wave, ZME_UZB1, FGRM222; CUL; Enocean, TCM_ESP3, PTM-215, Tasmota

martinp876

Da sind ein paar falsche annahmen drin.
Wenn du einen alarm von fhem auslöst meldet keiner der SDS etwas. Der Auslöser, hier die zentrale, meldete bereits.
Ein burst ist IMMER notwendig, mit SDS zu reden.
SDS starten immer mit einer zufälligen Verzögerung. M.e. ist dies dem Team geschuldet. Es sollen nicht alle synchron piepen sondern im Wechsel. Absolut sinnvoll.

Das melden in fhem hat also keine relevante Verzögerung.
Dein statusrequest ist manuell und eine andere Baustelle, das ist deine sache

Solero

#8
Das klingt logisch. Ich werde das ganze beizeiten mit Testspray probieren.
Ich gehe jetzt mal davon aus, dass an Hard und Software alles so funktioniert wie es soll.

Danke für die Erklärungen und deine superschnellen Antworten.

Einen schönen Restsonntag euch noch.
Solero

UPDATE: Ich habe mir Rauchmelder-Testspray geholt und damit das ganze erneut getestet.
Es funktioniert wie gewünscht. Der notify reagiert quasi instantan. Yay.
RaspberryPi 4 (4GB) mit Raspbian und FHEM als Docker-Container; Homematic, CCU3, HM-LC-Dim1TPBU-FM, HM-LC-Sw1PBU-FM, HM-ES-PMSw1-Pl, HM-SEC-SD-2; Z-Wave, ZME_UZB1, FGRM222; CUL; Enocean, TCM_ESP3, PTM-215, Tasmota