HM-SEC-SD-2 neu

[DerFrickler]

Der Batteriestatus wird aber doch übertragen, oder?

zwar nur in dieser Form, aber ja..

Code Auswählen Erweitern

battery                       ok                    2016-05-01 10:38:57

[martinp876]

Alles richtig.
AES fuer Alarme ist nicht abschaltbar.
Batteriestatus wird angezeigt.
Burst erkennt fhem automatisch
Offen ist also das AES.

[cerberus]

Hallo, ich bekomme den HM-SEC-SD-2 mit FHEM nicht mal gepaired. Ich nutze ein SCC (CUL) und habe AES bisher nicht verwendet. Muss ich also AES in der VCCU einschalten um die HM-SEC-SD-2 mit FHEM pairen zu können?

Grüße
cerberus

[martinp876]

Muss ich also AES in der VCCU einschalten um die HM-SEC-SD-2 mit FHEM pairen zu können?

nein. Dieser Teil fuktioniert ohne AES einwandfrei.
Logge das einmal (sniffen). ich sehe kein Problem - hauptsache die CUL funktioniert.

[cerberus]

Danke Martin, ich habe es erstmal, war ein Empfangsproblem.

Was muß der virtuelle TeamLeader für einen Status haben? Bei mir steht dort immer noch als Status der letzte Alarm drin.

Gruß
cerberus

[martinp876]

anbei ein Mitschnitt
sdTeam2 ist der virtuelle Lead.
Es wird alles wieder ausgeschaltet wenn man "den Knopf drückt".
Klappt alles prima.

Level 2 heist dass jemand bei einem mit-melder (SD im Team, ohne Alarm aber tutet) "aus" gedrückt hat. Das werte ich aktuell nicht separat aus.
Der Melder meldet keinen wirklichen Level, das sind fixe Werte, was ihr unter Level zu sehen bekommt.

Ich habe mit und ohne virtuellem Lead getestet - alles prima bei mir.
Jetzt sind die Räucherstäbchen meiner "Besten" alle.
sd4 und sd5 sind die beiden Melder des Teams.
Verbessern könnte man m.E. noch beim Abschalten welcher SD gemeldet und welcher noch nicht aus ist.
Ich denke aber es passt so

Immer noch offen ist das auslösen von Alarmen und teamcall aus der Zentrale (habe ich nicht vergessen - ist aber schwierig). Vielleicht hat jemand eine Idee zu AES berechnungen?

Code Auswählen Erweitern

19:45:31.761 CUL_HM sd4 smoke_detect: sd4
19:45:31.761 CUL_HM sd4 smoke-Alarm_10
19:45:31.761 CUL_HM sd4 trigLast: sdTeam2:198
19:45:31.761 CUL_HM sd4 trig_sdTeam2: 198
19:45:31.797 CUL_HM sd5 smoke_detect: sd4
19:45:31.797 CUL_HM sd5 smoke-Alarm_10
19:45:31.811 CUL_HM sdTeam2 eventNo: 10
19:45:31.811 CUL_HM sdTeam2 level: 198
19:45:31.811 CUL_HM sdTeam2 smoke_detect: sd4
19:45:31.811 CUL_HM sdTeam2 smoke-Alarm_10
19:45:31.811 CUL_HM sdTeam2 trigger_cnt: 16

19:45:48.784 CUL_HM sd4 smoke_detect: sd5
19:45:48.784 CUL_HM sd4 smoke-Alarm_12
19:45:48.816 CUL_HM sd5 smoke_detect: sd5
19:45:48.816 CUL_HM sd5 smoke-Alarm_12
19:45:48.816 CUL_HM sd5 trigLast: sdTeam2:2
19:45:48.816 CUL_HM sd5 trig_sdTeam2: 2
19:45:48.830 CUL_HM sdTeam2 eventNo: 12
19:45:48.830 CUL_HM sdTeam2 level: 2
19:45:48.830 CUL_HM sdTeam2 smoke_detect: sd5
19:45:48.830 CUL_HM sdTeam2 smoke-Alarm_12
19:45:48.830 CUL_HM sdTeam2 trigger_cnt: 18

19:45:56.281 CUL_HM sd4 smoke_detect: none
19:45:56.281 CUL_HM sd4 off
19:45:56.281 CUL_HM sd4 trigLast: sdTeam2:0
19:45:56.281 CUL_HM sd4 trig_sdTeam2: 0
19:45:56.313 CUL_HM sd5 smoke_detect: none
19:45:56.313 CUL_HM sd5 off
19:45:56.327 CUL_HM sdTeam2 eventNo: 11
19:45:56.327 CUL_HM sdTeam2 level: 0
19:45:56.327 CUL_HM sdTeam2 smoke_detect: none
19:45:56.327 CUL_HM sdTeam2 off
19:45:56.327 CUL_HM sdTeam2 trigger_cnt: 17

[Bytechanger]

Kurze Frage:

Da ich SD und SD2 jeweils mit eigenem TeamLeader habe, würde ich gerne beide über FHEM "verbinden".

D.h. löst ein Melder eines Teams aus, würde ich über FHEM das andere Team auch aktivieren wollen.
Gleichzeitig soll auch das "Stummschalten" weitergetragen werden.
(JA SD2 geht erst, wenn martin876 das AES-Problem gelöst hat).

Eine Frage insbesondere an martin876: worauf muss ic bei SD und SD2 -Teamleadern triggern, um das Stummschalten zu bekommen?

Also Rauchalarm geht ja mit

Code Auswählen Erweitern

Rauchmelder_Team:.*smoke-Alarm.* {
Aber was kommt beim Stummschalten (SD und SD2) ??
?

Code Auswählen Erweitern

Rauchmelder_Team:.*off.* { ?


PS: Grundsätzlich finde ich den SD2 ja besser. Was mich nur stört ist, dass ich in ca. 10 Jahren alle Geräte neu kaufen muss. Bei SD stört mich, dass augenscheinlich die "Rauchkammer" sehr klein ist und gefühlt der Melder mir etwas unempfindlich ist, also erst sehr spät auslöst.

Greets

Byte

[MarcelK]

Immer noch offen ist das auslösen von Alarmen und teamcall aus der Zentrale (habe ich nicht vergessen - ist aber schwierig). Vielleicht hat jemand eine Idee zu AES berechnungen?

Schlimmstenfalls haben sie für die SD-2 einen eigenen Key eingeführt. Hast Du noch mehr Beispiel-Telegramme?

War der Burst jetzt eigentlich irgendwas besonderes?

[martinp876]

Ich kann noch mehr Beispiele schicken.
Tripple burst .... scheint tatsächlich mehr burst zu benötigen. Das wird idR von den Wiederholungen ausreichend geleistet. Bei den Versuchen hat es immer funktioniert mit den gegebenen Einstellungen. Daher sehe ich keinen Grund das io durch mehr versuche stärker zu belasten.
Interessant ist dass im Gegensatz zu den alten alle Alarme nicht 3mal sondern 6mal gesendet und wiederholt werden.

[Christian Uhlmann]

Hallo zusammen,
interessant fände ich auch den Kommunikationstest (Kapitel 7.2) dabei sollte einiges per Funk übertragen werden. Hat das schon mal jemand gemacht, könnte man das aus FHEM heraus triggern?

Was mich noch stört ist das alle 43 Sekunden die LED blinkt. Das geht in den Schlafzimmern gar nicht. Muss ich da Kabel abtrennen oder ist das ggf. über eine Register steuerbar?

LG Christian

P.S. Vielen Dank Martin für deine Arbeit.

[M_I_B]

... Kommunikationstest ... könnte man das aus FHEM heraus triggern?

Nette Idee! Ich habe gerade nicht auf'm Schirm, ob die sich nicht sowieso über irgend etwas melden, wenn die Kette gestört ist, aber wenn man aus FHEM heraus regelmäßig einen KommuTest anstoßen und auf Fehler reagieren könnte, wäre das ein netter Sicherheitsgewinn ...

Was mich noch stört ist das alle 43 Sekunden die LED blinkt. Das geht in den Schlafzimmern gar nicht. Muss ich da Kabel abtrennen oder ist das ggf. über eine Register steuerbar?

... wat bist Du empfindlich Aber ok... Wir hatten auch mal einen RM, welcher extrem hell geblinkt hat. Mich störte das nicht, aber Frauchen... Lösung: kleinen selbstklebenden Filzgleiter in weiß über die LED geklebt.
Ich kann mir nicht vorstellen, das man die LED per Register abschalten kann. Das stände m.E. einer Zulassung im Wege...

P.S. Vielen Dank Martin für deine Arbeit.

*zustimm*

[martinp876]

Den kommTest nicht falsch verstehen. Das ist der teamcall welcher den kommTest darstellt. Es ist so, dass du ihn von einem SD auslöst und dann ALLE anderen auf bllinken kontrollierst. Dann den nächsten druecken, wieder alle kontrollieren. Und so fort.
Von der zentrale aus geht das in diesem Umfang nicht. Ein SD der gehört hat sendet nichts. Kontrolle nur über die led.

Du kannst also nur prüfen, ob die zentrale Kontakt zu allen hat. Nicht mehr und nicht weniger.
Das aber passiert automatisch. Das device meldet sich regelmässig.
Wer will kann einen statusrequest regelmässig ausführen. Das kostet aber Batterien.

Von der zentrale einen teamcall auszuführen bringt somit wenig added value. Du musst dann alle SDS anschreiten uns LEDs prüfen. Ohne aufstehen geht das nicht.

Da teamcall AES signiert ist kann fhem das aktuell nicht. Aus meiner Sicht ein ärgerlicher aber geringer Verlust.
Fuer alarm sieht es schon anders aus. Auch AES Problem.

[Bytechanger]

Klingt nach einem großen Problem mit AES!
Ich hoffe es ist lösbar!

Ich hoffe auch, dass eq3 nicht noch mehr Komponenten mit dieser Verschlüsselung einführt, dann könnte es um FHEM dunkel werden, wenn keine Lösung gefunden wird.


Greets

Byte

[M_I_B]

Von der zentrale aus geht das in diesem Umfang nicht. Ein SD der gehört hat sendet nichts. Kontrolle nur über die led.

... ja, das macht Sinn; so weit hatte ich gar nicht gedacht ...

Wer will kann einen statusrequest regelmässig ausführen. Das kostet aber Batterien.

Funktioniert bei mir nicht wirklich. Sobald ich einen StatusRequest anfordere, reagieren alle 3 RM mit:

Code Auswählen Erweitern

SCC2_MSGCNT 2
   SCC2_RAWMSG A0E88A61048F213F10000060100002F::-55:SCC2
   SCC2_RSSI  -55
   SCC2_TIME  2016-05-03 17:46:00
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:88 - t:10 s:48F213 d:F10000 060100002F
   peerList   Team_RM,
   protCmdDel 1
   protLastRcv 2016-05-03 17:46:00
   protResnd  2 last_at:2016-05-03 17:46:29
   protResndFail 1 last_at:2016-05-03 17:46:34
   protSnd    4 last_at:2016-05-03 17:46:20
   protState  CMDs_done_Errors:1
   rssi_SCC2  lst:-47 max:-47 min:-47 avg:-47 cnt:1
   rssi_at_SCC2 max:-55 lst:-55 cnt:2 avg:-55.5 min:-56 
Wie man sieht, läuft der z.B. auf einen MISSING ACK. Das passiert auch z.B. bei einem GetConfig o.ä.. Irgendwie wachen die nicht auf. Wenn ich die aber in den Testmode setze (Tastendruck), dann geht's ...
Das die dabei Batterie verpulvern stört mich nicht wirklich. Ob ich die Zellen nun nach 5 Jahren oder 8 Jahren tauschen muss, ist mir ehrlich gesagt mumpe...

Ich hoffe auch, dass eq3 nicht noch mehr Komponenten mit dieser Verschlüsselung einführt, dann könnte es um FHEM dunkel werden, wenn keine Lösung gefunden wird.

... komisch, diese dunkle Wolke geisterte auch schon in meinem Unterbewustsein herum. Das wäre eine gute Option für eQ3, die Leute mit mittleren und großen Installationen an die eigenen Produkte zu binden und diese dann mit noch mehr Marge als jetzt schon zu verticken.

[martinp876]

Bei eq3 haben fast alle devices AES. Pflicht ist er bei keymatic und dem neuen SD.
Fhem kann AES fuer alle ausser die neuen sd2. Eigentlich auch fuer sd2, nur eben nicht die Kommunikation eines sdlead faken.
Statusrequest ist nicht dokumentiert. Wenn dein device aber auch kein getconfig ausführt liegt es nicht am Kommando. Ist das device gepairt? Das ist das erste Problem.
Lese die config mit dem Button und prüfe das pairing. Ansonsten Logge die messages damit ich den burst sehen kann.