HM-SEC-SD-2 neu

[M_I_B]

... 24.07.2016 - Fehlalarm um 01:40 ...

Dabei sind folgende Merkwürdigkeiten aufgefallen:

Der laut LOG auslösender RM im Keller hat keinen Alarmton abgegeben und kein Notlicht eingeschaltet, wie es die beiden RM im EG taten. Dafür blinkte der auslösende RM hektisch rot. Ein Abschalten des Alarms war am auslösenden RM nicht möglich.

Die RM im OG funktionierten korrekt. Abschaltung über diese RM nicht möglich.

TeamLeader zeigte keinen Alarm mehr an, nachdem ich den Rechner erreicht hatte, da sich der Alarm nicht am RM löschen lies. Auch ein mehrfaches Senden von AlarmOFF über den TeamLeader half nicht, den Alarm zu löschen.

Da zwischenzeitlich meine Frauen und vor allem unsere Tiere langsam irre wurden, habe ich die RM alle abgeschaltet (SchalterHack) und bis zum Morgen li8egen lassen. Seit dem alles wieder normal...


@Martin: War es denn nicht mal von Dir so gemacht worden, das der TeamLeader das Sagen hat und ein Alarm vom TM zu löschen ist? Mir ist so als wenn mal gesagt wurde, das der TM der Master ist und der Anwender am Rechner wissen sollte, was er tut (oder so ähnlich).

Die zweite Frage ist natürlich, warum der auslösende RM keinen Laut von sich gegeben hat; funktionieren tut er und auch ein TeamCall wird brav gemeldet

Dritte Frage bezieht sich auf die Art der Alamierung: Mir war so, das ein TeamCall ein anderes Intervall hat wie ein "echter" Alarm, oder nicht? Hier zumindest unterscheiden sich beide Arten der Signalgebung nicht; 3 x Signal - Pause, 3 x Signal - Pause ...

Code Auswählen Erweitern

2016-07-24_01:39:37 HM1RM1 smoke_detect: HM1RM3
2016-07-24_01:39:37 HM1RM1 smoke-Alarm_01
2016-07-24_01:39:37 HM1RM2 smoke_detect: HM1RM3
2016-07-24_01:39:37 HM1RM2 smoke-Alarm_01
2016-07-24_01:39:37 HM1RM3 battery: ok
2016-07-24_01:39:37 HM1RM3 smoke_detect: HM1RM3
2016-07-24_01:39:37 HM1RM3 smoke-Alarm_01
2016-07-24_01:39:37 HM1RM3 trigLast: Team_RM:198
2016-07-24_01:39:37 HM1RM3 trig_Team_RM: 198
2016-07-24_01:39:37 Team_RM eventNo: 01
2016-07-24_01:39:37 Team_RM level: 198
2016-07-24_01:39:37 Team_RM smoke_detect: HM1RM3
2016-07-24_01:39:37 Team_RM smoke-Alarm_01
2016-07-24_01:39:37 Team_RM trigger_cnt: 1
2016-07-24_01:39:42 HM1RM3 trigLast: Team_RM:199
2016-07-24_01:39:42 HM1RM3 trig_Team_RM: 199
2016-07-24_01:39:42 Team_RM trigger_cnt: 1
2016-07-24_01:42:26 HM1RM1 battery: ok
2016-07-24_01:42:26 HM1RM1 smoke_detect: none
2016-07-24_01:42:26 HM1RM1 off
2016-07-24_01:42:26 HM1RM1 trigLast: Team_RM:2
2016-07-24_01:42:26 HM1RM1 trig_Team_RM: 2
2016-07-24_01:42:26 HM1RM2 smoke_detect: none
2016-07-24_01:42:26 HM1RM2 off
2016-07-24_01:42:26 HM1RM3 smoke_detect: none
2016-07-24_01:42:26 HM1RM3 off
2016-07-24_01:42:26 Team_RM eventNo: 01
2016-07-24_01:42:26 Team_RM level: 2
2016-07-24_01:42:26 Team_RM smoke_detect: none

[martinp876]

Lead ist nicht ganz korrekt. Ich glaube immee behauptet zu haben, dass es keinen lead gibt. Philoyophie ist, dass es ein komplett verteiltes system ist. Keines der devices hat eine sonderstellung.
Nun ja. Da sind beim sd2 schon einmal die repeater.
Und einer muss seine hmid hergeben um diese als teamid zu nutzen. Dieser wird als lead genutzt.
Da die hmid des lead genutzt wird um teamcall und alarm zu steuern werden die kommandos auch nur ueber diese entity ausgeloest.

Warum der sdkeller nicht hupt kann ich nicht sagen, wuerde aber mit zigarre in den keller gehen um das sicher zu stellen.
Ich werde am wochenende versuche machen. Von welchem sd man loeschen kann wenn ein alarm ansteht.
Ist mir aktuell unklar ob dies von jedem geht oder nur vom ausloesenden, oder dann nir lokal, oder.....

[automatisierer]

Jo, in der Anleitung steht:

Code Auswählen Erweitern

Durch das Anlernen zweier oder mehrerer Rauchwarnmelder wird ein Funknetz gebildet. Der Rauchalarm eines Rauchwarnmelders im Netz wird dadurch automatisch an alle anderen Melder im Netz mit der gleichen Gruppenadresse weitergegeben.
....
Die ersten beiden Rauchwarnmelder im System definieren eine Gruppenadresse. Jeder weiter Rauchwarnmelder kann an einen beliebigen bereits im System befindlichen Rauchwarnmelder angelernt werden und erhält automatisch die vorab definierte Gruppenadresse.

!! Jeder Rauchwarnmelder innerhalb eines Systems muss jeden anderen Rauchwarnmelder des Systems und ggf. die Zentrale erreichen können.
...

7.3 Stummschaltung bei Alarm

Bei unerwünschten Alarmen kann der Alarm für 10 Minuten deaktiviert werden.
...
Der Alarm wird stumm geschaltet und die Rauchdetektion für 10 Minuten deaktiviert. Für die Zeit blinkt LED alle 10 Sek. rot. Eine Alarm-Stummschaltung bei Alarm führt zur Alarm-Deaktivierung bei allen über Funk vernetzten Rauchwarnmeldern, die keinen eigenen Alarm haben, d.h. keinen Rauch in der Rauchkammer. Rauchmelder mit eigenem Alarm können nur direkt am entsprechenden Gerät deaktiviert werden... .


Also sollte man über das virtuelle-Teammitglied (diese Bezeichnung pass wohl besser als TeamLead) alle Rauchmelder für 10 Minuten stumm schalten können, bis auf den, an dem der Alarm entstanden ist.

Von einem richtigen Team-Mitglied aus stellt man den Alarm mit einem kurzen Tastendruck ab.


Zu den Blinksignalen:

Code Auswählen Erweitern

Rauchalarm lokal: rotes Blinekn und Notbeleuchtung mit anschließender LED-Nachlaufzeit von 24 h (30 min schnelles Blinken, anschließend doppeltes Blinken alle 43 s. Vorzeitige Beendigung des schnellen Blinkens ist durch Tastendruck möglich.)


Das würde ja das hektische Blinken erklären...

Das Verhalten liesse sich so erklären: Der Melder wurde durch "irgendwas" fehl ausgelöst und bis du bei dem Melder gewesen warst, lag dieser "Fehler" nicht mehr an. Daher kein Alarm und keine Notbeleuchtung mehr sondern nur noch das schnelle rote Blinken.

[M_I_B]

@Martin: ... ich meinte auch den "Virtuellen" Leader. Da im Grunde kein RM den Leader macht sondern FHEM (auch wenn einer dafür seine ID hergeben muss), hatte ich es eben als TL bezeichnet...Aber gut... Das is wohl Haarspalterei
Noch mal zu meiner Konfig: Der (pöse) RM im Keller, ein RM auf dem Flur im Schlaftrakt, ein RM im Durchgang WZ/EZ, welcher auch den Repeater macht, da sonst der im Schlaftrakt den im Keller nicht "hört".
Auslösen des Test funktioniert bei allen und alle bekommen es auch mit. Ebenso das Auslösen/Löschen aus FHEM über den TL. Daran sollte es also nicht liegen; da gab es bisher auch keine Störungen.
Den "Zigarrentest" mache ich mit den genormten Qualmstengeln für RM; hab noch ein paar aus der Vergangenheit (VdI- zertifizierte Räucherstäbchen  ). Aber dafür muss ich immer Zeiten abpassen, wenn die Frauen, Hund und Katzen außer Haus sind, sonst ticken die aus; der WAF/PAF solch einer Aktion ist doch sehr gering...

@automatisierer: ... Deine Schlussfolgerung hatte ich zu erst auch, aber nach Rücksprache mit meinen Frauen war ich innerhalb 2 Minuten im Keller (da steht die meiste Technik, die qualmen kann...). Auch wenn der einen Fehlalarm hatte, so ist das doch immerhin ein Alarm, was ja auch die hektisch blinkende LED angesagt hat. Dennoch war Schweigen und Dunkelheit; sollte nicht sein...


@Allgemein: Ich werde das mal weiter beobachten. Vielleicht tragen wir mal alle gemeinsam solche "Fehlalarme" mit all den Begleitumständen zusammen, in der Hoffnung, da irgendwann einen Zusammenhang erkennen zu können ...

[Bytechanger]

Der Begriff Teamleader provoziert offensichtlich immer wieder Fehlinterpretationen. Vielleicht sollte man einen anderen Begriff wählen?

Ich habe das System so verstanden:
Der sogenannte Teamleader gibt nur seinen Namen. Ansonsten wird er vom System als normaler Rauchmelder wargenommen!

Es beunruhigt mich nur der Fehlarlarm des SD2. Das Problem schien es beim SD auch schon mal gegeben zu haben. Damals wurde durch ein Softwareupdate mit Auslöseverzögerung gegengesteuert (m.E. schlechte Lösung, da ich eine frühe Warnung bevorzuge). Der SD2 soll ja ein Fliegengitter haben..


Greets

Byte

[M_I_B]

Der SD2 soll ja ein Fliegengitter haben..

... hat er. Innenleben ist gut auf den Bildern zum SchalterHack zu sehen ...

Na, warten wir mal, wie viele Meldungen über Fehlalarme es in Zukunft geben wird; ich bin ja da sicherlich nicht der Einzige auf der Welt ...

[Bytechanger]

Tja, habe 9 sd2 und 3 sd.
Mal sehen, wann es mich erwischt..


Greets

Byte

[Christian Uhlmann]

Hallo zusammen,
meine 6 SD-2 hängen seit dem Wochenende. Davor waren zwei für mehre Wochen im Testbetrieb. Bisher keine Fehlalarme.
Christian

[N4unch0rch]

Hallo zusammen. Ich habe insgesamt 8 RMs die ich einbinden will, es scheitert bei mir jedoch schon beim Ersten. Ich kann ich nicht gescheit pairen. Ich setzte den RM und FHEM in den Pairing-Modus und der RM schlägt im Event Monitor auf, schickt seine Daten und wird per AutoCreate angelegt.
Anschließend zieht er sich den AES-Key und dieser wird abgelehnt, aber wieso ? Und wieso kann ich ab diesem Moment nichtmehr mit dem RM kommunizieren ? Ab dann bekomme ich immer: No ACK.
Ich habe das schon mehrmals neu versucht und jedesmal das selbe Problem.
Hier die LOGs:

Code Auswählen Erweitern

2016.07.29 16:44:25.969 0 : HMLAN_Parse: HMUSB R:E47CC31 stat:0000 t:00071F90 d:FF r:FFD1 m:89 8400 47CC31 000000 1000AA4E525730303037313336CE000100
2016-07-29 16:44:26.010 Global global UNDEFINED HM_47CC31 CUL_HM 47CC31
2016-07-29 16:44:26.010 Global global DEFINED HM_47CC31
2016-07-29 16:44:26.010 Global global DEFINED FileLog_HM_47CC31
2016-07-29 16:44:26.010 Global global SAVE
2016.07.29 16:44:26.101 0 : HMLAN_Send: HMUSB S:S371D0E7F stat: 00 t:00000000 d:01 r:371D0E7F m:8A A001 123400 47CC31 00050000000000
2016-07-29 16:44:26.113 CUL_HM ActionDetector status_HM_47CC31: alive
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 Activity: alive
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 D-firmware: 1.0
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 D-serialNr: NRW0007136
2016-07-29 16:44:26.118 CUL_HM HM_47CC31 sdRepeat: invalid
2016.07.29 16:44:26.289 0 : HMLAN_Parse: HMUSB R:E47CC31 stat:0100 t:000720BF d:FF r:FFD0 m:8A A002 47CC31 123400 04F6C0BB821BEA00
2016-07-29 16:44:26.296 CUL_HM HM_47CC31 aesCommToDev: pending
2016-07-29 16:44:26.296 CUL_HM HM_47CC31 aesKeyNbr: 00
2016.07.29 16:44:27.217 0 : HMLAN_Parse: HMUSB R:R371D0E7F stat:0030 t:000720C4 d:00 r:FFD0 m:8A A002 47CC31 123400 04F6C0BB821BEA00
2016.07.29 16:44:27.218 0 : HMLAN_Parse: HMUSB AES code rejected for 123400 48
2016.07.29 16:44:27.225 0 : HMLAN_Send: HMUSB S:S371D132F stat: 00 t:00000000 d:01 r:371D132F m:8B A001 123400 47CC31 000802010A120B340C00
2016.07.29 16:44:27.227 0 : HMLAN_Send: HMUSB I:K
2016-07-29 16:44:27.237 CUL_HM HM_47CC31 aesKeyNbr: 00
2016.07.29 16:44:27.281 0 : HMLAN_Parse: HMUSB V:03C7 sNo:NEQ0369509 d:49AD75 O:123400 t:000724B4 IDcnt:0003 L:89 %
2016-07-29 16:44:27.287 HMLAN HMUSB loadLvl: batchLevel
2016.07.29 16:44:27.858 0 : HMLAN_Parse: HMUSB R:R371D132F stat:0008 t:00000000 d:FF r:7FFF m:8B A001 123400 47CC31 000802010A120B340C00
2016.07.29 16:44:27.859 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016.07.29 16:44:30.161 0 : HMLAN_Send: HMUSB S:S371D1EA5 stat: 00 t:00000000 d:01 r:371D1EA5 m:8B B001 123400 47CC31 000802010A120B340C00
2016-07-29 16:44:30.399 FRITZBOX FritzBox disabled
2016-07-29 16:44:31.001 CUL_HM HM_47CC31 Activity: alive
2016.07.29 16:44:31.005 0 : HMLAN_Send:  HMUSB I:+47CC31,00,01,00
2016.07.29 16:44:31.986 0 : HMLAN_Parse: HMUSB R:R371D1EA5 stat:0208 t:00000000 d:FF r:7FFF m:8B B001 123400 47CC31 000802010A120B340C00
2016.07.29 16:44:31.987 1 : HMLAN_Parse: HMUSB new condition Warning-HighLoad
2016-07-29 16:44:31.992 HMLAN HMUSB cond: Warning-HighLoad
2016-07-29 16:44:31.992 HMLAN HMUSB Xmit-Events: ERROR-Overload:8 ok:5 disconnected:8 init:7 Warning-HighLoad:11
2016-07-29 16:44:31.992 HMLAN HMUSB prot_Warning-HighLoad: last
2016.07.29 16:44:31.995 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016-07-29 16:44:34.232 CUL_HM HM_47CC31 ResndFail
2016-07-29 16:44:34.237 CUL_HM HM_47CC31 MISSING ACK
2016-07-29 16:44:37.024 CUL_HM HM_47CC31 unreachable
2016-07-29 16:44:40.412 FRITZBOX FritzBox disabled
2016.07.29 16:44:46.075 0 : HMLAN_Send: HMUSB S:S371D5CD1 stat: 00 t:00000000 d:01 r:371D5CD1 m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:47.892 0 : HMLAN_Parse: HMUSB R:R371D5CD1 stat:0208 t:00000000 d:FF r:7FFF m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:47.893 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016-07-29 16:44:50.416 FRITZBOX FritzBox disabled
2016.07.29 16:44:50.753 0 : HMLAN_Send: HMUSB S:S371D6F17 stat: 00 t:00000000 d:01 r:371D6F17 m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:52.229 0 : HMLAN_Send: HMUSB I:K
2016.07.29 16:44:52.244 0 : HMLAN_Parse: HMUSB V:03C7 sNo:NEQ0369509 d:49AD75 O:123400 t:00078635 IDcnt:0003 L:99 %
2016-07-29 16:44:52.251 HMLAN HMUSB loadLvl: suspended
2016.07.29 16:44:52.564 0 : HMLAN_Parse: HMUSB R:R371D6F17 stat:0208 t:00000000 d:FF r:7FFF m:8C B001 123400 47CC31 00040000000000
2016.07.29 16:44:52.565 0 : HMLAN_Parse: HMUSB no ACK from 47CC31
2016-07-29 16:44:56.669 CUL_HM HM_47CC31 ResndFail
2016-07-29 16:44:56.680 CUL_HM HM_47CC31 RESPONSE TIMEOUT:RegisterRead

Ich hoffe es kann mir jemand weiterhelfen, ich möchte ungern umsonst soviel Geld investiert haben.

[frank]

Code Auswählen Erweitern

2016.07.29 16:44:27.218 0 : HMLAN_Parse: HMUSB AES code rejected for 123400 48

hast du das perl modul installiert: crypt-rijindael oder so ähnlich?

Code Auswählen Erweitern

2016-07-29 16:44:31.992 HMLAN HMUSB Xmit-Events: ERROR-Overload:8 ok:5 disconnected:8 init:7 Warning-HighLoad:11
der hmusb ist auch am sendelimit.

[Bytechanger]

Es meist du mit:
Zieht er sich den aes-key?
Mit den sd2 kommst du schnell ins overload. Sind halt burst devices. Dann geht für eine Stunde nix mehr...

Wurde der aes-key erfolgreich übertragen?
Versuchs erstmal mit pairen und zieh mit getConfig die Daten. Davon schauen, ob erfolgreich gepaird wurde, also die zentrale eingetragen ist.
Ggf. Mal einen reichweitentest starten.
Wenn der rm nicht die zentrale hat,akzeptiert er auch nix..

Greets

Byte

[N4unch0rch]

Hallo und vielen Dank für die schnelle Antwort.

Das Modul habe ich installiert, dass er ins Overload kommt weiß ich, nervt auch ziemlich beim Testen.
Die Zentrale ist im RM eingetragen, ich kann jedoch auch kein getConfig machen, danach kommt immer ein "no ACK".

Code Auswählen Erweitern

2016.07.30 13:01:14.958 0 : HMLAN_Send: HMUSB S:S3B7715A3 stat: 00 t:00000000 d:01 r:3B7715A3 m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:16.856 0 : HMLAN_Parse: HMUSB R:R3B7715A3 stat:0008 t:00000000 d:FF r:7FFF m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:16.857 0 : HMLAN_Parse: HMUSB no ACK from 47CC29
2016-07-30 13:01:19.048 FRITZBOX FritzBox disabled
2016.07.30 13:01:20.707 0 : HMLAN_Send: HMUSB I:K
2016.07.30 13:01:20.723 0 : HMLAN_Parse: HMUSB V:03C7 sNo:NEQ0369509 d:49AD75 O:123400 t:04613BF7 IDcnt:0004 L:89 %
2016-07-30 13:01:20.732 HMLAN HMUSB loadLvl: batchLevel
2016.07.30 13:01:20.912 0 : HMLAN_Send: HMUSB S:S3B772CE4 stat: 00 t:00000000 d:01 r:3B772CE4 m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:22.739 0 : HMLAN_Parse: HMUSB R:R3B772CE4 stat:0208 t:00000000 d:FF r:7FFF m:04 B001 123400 47CC29 00040000000000
2016.07.30 13:01:22.748 0 : HMLAN_Parse: HMUSB no ACK from 47CC29
2016-07-30 13:01:25.995 CUL_HM HM_47CC29 ResndFail
2016-07-30 13:01:26.011 CUL_HM HM_47CC29 RESPONSE TIMEOUT:RegisterRead

[automatisierer]

wenn du nen overload hast, sollte das mit einmal aus- und einstecken weg sein, ne stunde warten musst du da nicht.

zum Rest, list vom Device machen und posten, dann kann man evtl. sehen woran es liegt.

[Thomask]

Hallo,
ich habe lange gezögert, welche Rauchmelder ich mir zulegen soll.
Habe mich dann für die neuen SD2 entschieden.
3er Pack bei ELV bestellt und eingebunden mit virtuellen TeamLead in FHEM.
Ging auch alles glatt.
Hatte die Dinger keine Woche in Betrieb und die Biester gingen alle 3 (korrekt, waren ja mit dem Teamlead gepeert) mitten in der Nacht ohne Grund los.
Habe sie sofort an ELV zurückgeschickt und anstandslos Gutschrift zugesagt bekommen.
Sind also anscheinend auch nicht besser als die SD.
Fehlalarme sind völlig inakzeptabel (Urlaub u.ä.).
Gruß
Thomas

[Bytechanger]

Komisch, bei Dir scheint der "Feinstaub" sehr hoch zu sein 
Ich habe 12 Stück, davon auch einige (SD und SD2) im Keller. Da ist es sehr staubig
Einer in der Küche (war mal SD, jetzt SD2) .....
Bisher noch keinen Fehlalarm gehabt...


Greets

Byte