HM-SEC-SD-2 neu

Begonnen von martinp876, 21 März 2015, 17:28:26

Vorheriges Thema - Nächstes Thema

martinp876

Die melder sind soeben angekommen, danke an alle.
Erste ergebnisse: anlernen an die zentrale problemlos.
Die melder werden wohl nicht den alarm melder zu melder weiterreichen. Das sehe ich nicht am melder, das steht in der anleitung. Jeder melder muss zu allen in reichweite sein.
Das peeren ist identisch beschrieben. Werde ich testen, erwarte aber keine unterschiede.

Mehr am wochenende
Es gibt mehr register

MadMax-FHEM

Hi martinp876,

vielen Dank schon mal!

Bin gespannt!

Will demnächst auch meine Wohnung ausrüsten...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MarcelK

Zitat von: martinp876 am 27 April 2016, 21:47:10
Die melder werden wohl nicht den alarm melder zu melder weiterreichen. Das sehe ich nicht am melder, das steht in der anleitung. Jeder melder muss zu allen in reichweite sein.
Fehlt in Deiner Anleitung Kapitel 7.5?

kvo1

Zitat von: MarcelK am 27 April 2016, 21:55:42
Fehlt in Deiner Anleitung Kapitel 7.5?
Hallo Martin,
die Repeaterfunktion wird doch überall erwähnt ! das sollte schon funktionieren!

Gruß Klaus
RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

M_I_B

Zitat von: kvo1 am 27 April 2016, 22:24:00... die Repeaterfunktion wird doch überall erwähnt ! das sollte schon funktionieren!

Kann ich nur bestätigen. Habe ich schon in alle Richtungen durchgetestet, allerdings nur mit 3 RM. Lt. Beschreibung sind auch mehrere Repeater möglich... Ohne diese Funktion wäre ich angesichts unserer Stahlbeton-Decken ziemlich aufgeschmissen...

Bytechanger

Alte Rauchmelder bestellt?

-Repeaterfunktion - Damit wird doch geworben und steht in der Produktbeschreibung!
Es dürfen maximal 3 Rauchmelder als Repeater eingesetzt werden.


Auch steht in der Anleitung, dass die neuen SD2 nicht kompatibel zu dem Funkprotokoll des SD sind!
max. 40 Rauchmelder im Verbund
Und Punkt 7.5 Repeaterfunktion


Greets

Byte

martinp876

Ok, kann er wohl doch. Seltsamer Kommentar.
Das Register zum Einschalten des repeater ist klar, werde ich am Wochenende einbauen.

martinp876

einiges ist klarer - einen Update habe ich eingestellt. Es fehlt aber noch einiges.

a) der SD arbeitet IMMER mit AES (steht sowieso im handbuch). Um also kommandos zu starten ist (Teamcall,...) muss man AES beherrschen. Das ist ein Hinweis insbesondere für CUL Nutzer

b)repeater habe ich eingeschaltet - bislang ohne sichtbaren Erfolg. Ich sehe keine wiederholungen. Evtl ist es inteligent und wiederholt nicht wenn RSSI zu hoch ist. Das einschalten geht mit Register devRepeatCntMax (seltsamer Name...)

c) die CCU kann ja garnichts. Ich weiss schon warum ich FHEM nutze und nicht die CCU2 ;)

d) Statusrequest ist eingebaut.

e) Rauchtests sind noch komplett offen - ich muss eine Zigarre suchen :)

Der Update ist eingecheckt, more to come

morph

wie erkenne ich, ob ich "alte" rauchmelder bekommen habe oder "neue"?

martinp876

der neue heisst nicht SD sondern SD-2. Die sehen auch ganz anders aus. Der neue hat keine Batterie ;). also keine von dir tauschbare.

Repeater funktioniert jetzt. Was bei 2 Repeatern passiert kann ich nicht deuten - ich vermute einmal das gleiche wir beim Erste.

Neue SW eingecheckt.
Offen immer noch: AES Kalkulation der operationellen Messages

martinp876

das Problem aktuell ist die message
01 1441 44E347 44E347 0101960000 03 0A802A78

03 muss die Nummer des keys sein
0A802A78 ist dann der key.
Ich gehe davon aus, dass
01 1441 44E347 44E347 0101960000
kodiert wird.
Da ich keinen Key übertragen habe muss das der Default key sein.

kvo1

Hallo Martin,
Lässt sich den AES nicht abschalten ?

Gruß Klaus
RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

Bytechanger

Wie ist denn der aktuelle Stand?

Können die Geräte verwendet werden, welche Einschränkung gibt es derzeit?
AES war doch für CUL auch kein Problem, oder?

Gibt es Probleme, wenn ich meinen eigenen AES-Key übertrage?


Gruß

Byte

martinp876

Stand:
das Handbuch stimmt (kein Wunder ;) ):
- Man kann alte und neue SDs nicht direkt peeren.
- man kann einen Repeater einschalten. Kann über FHEM gesteuert und kontrolliert werden.
- Alarme und teamcall werden von FHEM erkannt und angezeigt.
- peeren (teamen) ist möglich
- Burst-verfahren ist funktionsfähig

Offen ist das Thema Teamcall und Alarm von FHEM ein und auszuschalten. Problem ist das AES welches leicht anders funktioniert.
AES wird nicht also Signatur gesendet sondern gleich mit dem Kommando. eQ3 hat sich ein Verfahren ausgedacht was kodiert werden muss. Offensichtlich ist es nicht allein die Message. Man kann eine gesendete Message nicht einfach wiederholen - das wird ignoriert. Das gilt es zu knacken.
Bei meinen SDs habe ich keinen key gesetzt. die SDs verstehe sich also mit dem default-key.
AES Kommunikation zum Einrichten des Device ist nicht gefordert.


Bytechanger

Danke für die Mühen.

Also ich nehme für mich mit:

1. ich kann die neuen SDs mit einem VirtuellenTeamLead nach Anleitung Wiki http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead  verbinden
   (hierbei muss ich für jeweils die alten SD und die neuen SD2 jeweils einen eigenen virtuellen TeamLeader bestimmtn)

2. FHEM kann "mitlesen" und bekommt Alarme/Batteriewarnungen mit.

3. derzeit ist es aufgrund des geänderten AES-Verfahrens nicht möglich den SD2 Befehle in Form von TeamCall oder Alarm ein / Alarm aus zu geben..

4. muss ich augrund des geänderten Deviceverhaltens (Burst) andere Attribute als im Wiki vorsehen?
Attribute

besondere Attribute

    msgRepeat sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms.
    actCycle wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.
    msgRepeat 1

Allgemein vorgeschlagen

    IODev [HMLAN/HMUSB/CUL]
    autoReadReg 5_readMissing
    event-on-change-reading .*

Optional, nur als Anregung zu verstehen

    devStateIcon off:general_ok *:secur_alarm
    group smokeDetect
    icon secur_smoke_detector



Ich hoffe, dass AES-Problem lässt sich in den Griff bekommen.
Der Batteriestatus wird aber doch übertragen, oder?

Greets

Byte