HM-SEC-SD-2 neu

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

Vorheriges Thema - Nächstes Thema

M_I_B

#165
Zitat von: martinp876 am 03 Mai 2016, 20:18:43Bei eq3 haben fast alle devices AES. Pflicht ist er bei keymatic und dem neuen SD. ...
... vermutlich fehlt mir da der Hintergrund... Aber wenn jetzt eQ3 auf die Idee kommt, die Key's zu wechseln, dann ist aber Essig, oder?

Zitat von: martinp876 am 03 Mai 2016, 20:18:43... 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.
Klar, das pairing steht korrekt auf der ID 0xF10000 bei "PairedTo" und "R-pairCentral" ohne set o.ä. davor. Das passt zumindest und auch gefakte Alarme (Zigarette) schlagen bei FHEM korrekt auf.
Mit Loggen meinst Du bestimmt die RAW? Muss ich mich erst mal schlau lesen, wie ich das für ein/dieses Gerät exklusiv anderer Messages bewerkstelligen kann; hab ich noch nie gemacht... Wird nachgereicht, sobald ich es auf die Reihe bekommen habe...

BTW: Könnte das ggf. ein Problem des Busware SCC in Verbindung mit einem RPi2 sein? Ich hege so langsam den Verdacht, da ja manchmal auch andere Geräte nicht so reibungslos reagieren, wie das hier oft als üblich beschrieben wird.
Ich plane allerdings, FHEM auf einen Banana M3 umzulegen und zumindest für HM den neuen HM-LAN zu nutzen ...

Nachtrag:
Habe gerade noch mal ein GetConfig gesendet. Den hat er jetzt sofort geschluckt, aber STATE stand weiterhin aus Missing ACK. Dann bin ich böse geworden und habe dem RM einen reset geschickt. Erster Versuch lief wieder auf einen CMD-Error und STATE wechselte von set_reset wieder auf Missing ACK. Also noch mal ... dann ging es ohne Fehler durch und STATE steht nun auf off...
Irgend was hakt da bei der Kommunikation... Abstand SCC mit 8dbi Antenne zum RM ~6m bei fast direkter Sicht.

martinp876

Kann ein Problem sein. Das io muss auf Kommando burst senden. Cul und cuno machen das. Hmlan und hmusb sowieso.

Nein, eq3 wird den key nicht aendern. Und wenn ist das kein Problem. Der User welcher AES nutzen will sollte tunlichst den key aendern! Der eq3 key bietet keinen Schutz da er irgendwo sichtbar sein muss. Sonst könnte ich die Lampen des Nachbarn steuern, oder seine tuer.

Loggen siehe sniffen im wiki, auch selektiv

M_I_B

#167
... ich glaube mal, das ich den AES-Key noch nicht geändert habe. Aber da wir hier auf'm Dorf wohnen und ich wohl das einzige Haus mit so was betreibe, dürfte die Gefahr verschwindend gering sein. Ich werde es trotzdem mal nachholen ... Dank für die Erinnerung!

... Sniffen ... Das war das Wort was mir nicht mehr eingefallen ist ;)

Für meinen SCC müsste ich dann quasi ...

attr global verbose 1
attr global mseclog 1
attr SCC1 verbose 4


einbauen. Aber da geht dann das selektive Loggen nicht wie bei HMlan ala HMID, oder kann ich einfach als letzte Zeile dazu notieren ...
attr global verbose 1
attr global mseclog 1
attr SCC1 verbose 4
attr SCC1 logIDs EG_RM_WZ,EG_RM_FZ,KG_RM_KF

... um ausschließlich die drei Rauchmelder zu loggen?

EDIT:
Also logIDs geht bei SCC nicht.
Ich habe verbose auf 5 gesetzt und das Log mitgelesen, um zu erkennen, wann was passiert. Das ist dabei heraus gekommen:
# set EG_RM_WZ reset #
2016.05.03 22:49:24.539 4: CUL_Parse: SCC2 A 0D 95 8410 448306 F10000 06011900EE -83
2016.05.03 22:49:24.541 5: SCC2 dispatch A0D958410448306F1000006011900::-83:SCC2
# MISSING ACK // CMDs_done_Errors:1 #

# set EG_RM_WZ getConfig #
2016.05.03 22:52:59.979 4: CUL_Parse: SCC2 A 0D A3 8410 448158 F10000 06010E0035 -47.5
2016.05.03 22:52:59.982 5: SCC2 dispatch A0DA38410448158F1000006010E00::-47.5:SCC2
2016.05.03 22:53:43.688 4: CUL_Parse: SCC2 A 0D 96 8410 448306 F10000 06011900F0 -82
2016.05.03 22:53:43.690 5: SCC2 dispatch A0D968410448306F1000006011900::-82:SCC2
# RESPONSE TIMEOUT:RegisterRead // CMDs_done_Errors:1 #

Ich habe immer in Kommentaren darüber geschrieben, was ich gesendet habe und darunter, was das Ergebnis war.
Eigentlich müsste da doch viel mehr an Daten kommen, oder nicht? Auffallen war auch, das Änderungen am Log immer mehr als 30 Sekunden gedauert haben (abzgl. 1 Sekunde Log-Refresh). Daher kann ich nicht sagen, ob die Einträge im Log durch den abgesetzten Befehl ausgelöst wurden oder aber sowieso gekommen wären durch Statusmeldungen anderer HM- Geräte; ich kann die Log- Einträge eh nicht interpetieren ...

martinp876

Bei deinem loggen stimmt etwas nicht. Da kein CUL_Send vorkommt wird nichts gesendet. Das ist sicher nicht korrekt da ja Antworten kommen.
Hast du etwas ausgeschnitten?

M_I_B

Zitat von: martinp876 am 04 Mai 2016, 06:24:22Hast du etwas ausgeschnitten?
...nö, nur die Kommentare hinzu gefügt...
Zum Verständnis gefragt: Wird das "CUL_Send" direkt vom Befehl generiert oder nur dann, wenn tatsächlich der CUL den Befehl empfangen hat? Anders herum: Wenn ich physisch keinen CUL dran habe, würde dann trotzdem von der Software (FHEM) ein "CUL_Send" ins Log geschrieben?

Ich werde von Anfang an das Gefühl nicht los, das die SCC mit der heißen Nadel gestrickt sind. Da hatte ich schon immer Probleme mit, wobei Busware das ziemlich egal ist, wie ich selbst erfahren konnte; Hauptsache verkauft...

Ich mache heute Nachmittag noch mal einen kompletten Neustart, klemme mal ein Scope an und versuche mal zu ergründen, ob diese Probleme auf Hard- oder Softwareseite zu suchen sind.

frank

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

M_I_B

... ja, genau so ist das >:( Was nutzt einem ein Stackable, wenn es gestackt nicht funktioniert?!? Aber Busware will davon nichts hören ...
Wie gesagt: Ich habe die Schn**** gestrichen voll von dem Murks und vorhin (entgegen meinem ersten Impuls) erstmal einen HMlan in Rund bestellt. Wenn ich jetzt noch was vergleichbares zum HMlan für IT finden würde, könnte ich das ganze Busware- Geraffel bei eBay entsorgen ...

Bytechanger

Na ja, also zumindest das "Stummschalten" der TeamMitglieder würde ich schon gerne über die Zentrale machen können.
Es wäre also toll, wenn es eine Lösung für das AES-Problem gäbe!

Außerdem um zwei Teams über die Zentrale zu koppeln (wie in meinem Fall ein Team alter SD und ein Team neuer SD2) wäre dies eine
zwingende Voraussetzung.

Greets


Byte

MarcelK

Zitat von: martinp876 am 02 Mai 2016, 06:29:41
Ich kann noch mehr Beispiele schicken.
Dann schick mal bitte. Cryptographie ist nicht mein Fachbereich, Security und Reverse-Engineering im allgemeinen aber schon, insofern würd ich's mir gerne zumindest mal anschauen.

mgernoth

#174
Hallo,

ich nehme schwer an, dass das diesmal RFChannel::performCBCAuthentification(BidcosFrame&) ist (siehe rfd aus alter CCU2-FW).

IIRC war das so:

x = 49 <sender> <empfaenger> xx yy zz 00 00 00 00 00 05
xx,yy,zz waren IIRC 3 andere Bytes aus dem Frame


Das ganze wird AES verschlüsselt, dann mit irgendwas ver-Xored und dann nochmal verschlüsselt. Mit was ver-Xored wurde, weiss ich nicht mehr, hab ich mir auch nicht aufgeschrieben damals :-(

Ich hab das nicht weiterverfolgt, da ich dann (komplett ohne Disassembler) den "richtigen" Algorithmus gefunden hatte...

Ich hab im Moment leider keinerlei Zeit, mir das nochmal genauer anzuschauen, aber ein alter rfd und IDA/Hopper könnten hier Erfolg versprechen.

Viele Grüße
  Michael

MarcelK

Hallo Michael,

super Hinweis, kann ich mir gerne mal näher im IDA reinziehen (sofern's die Zeit und Family zulässt...). Wieso muss es ein alter rfd sein? Wurde der mal mit Symbole gelinkt oder woher kommen die Namen?

Beste Grüße, Marcel

mgernoth

Hallo Marcel,

Zitat von: MarcelK am 06 Mai 2016, 10:36:28
Wieso muss es ein alter rfd sein? Wurde der mal mit Symbole gelinkt oder woher kommen die Namen?

Anscheinend ist das mittlerweile in der Firmware des Funkmoduls selbst implementiert und nicht mehr im rfd. Zumindest gibts den Code jetzt nicht mehr.

Viele Grüße
  Michael

Bytechanger

Hallo,

wie frage ich beim virtuellenTeamLeader ab, welcher Rauchmelder Alarm gemeldet hat?

Beim SD - TeamLeader ist es "smoke_detect".
Irgendwie sieht mein TeamLeader fürs SD2 anders aus und hat dieses Reading nicht!

Er ist in FHEM.cfg so konfiguriert:

define TeamDevSD2 CUL_HM 111113
attr TeamDevSD2 IODev HMLAN1
attr TeamDevSD2 model virtual_1
attr TeamDevSD2 subType virtual
attr TeamDevSD2 webCmd virtual
define Rauchmelder_Team2 CUL_HM 11111301
attr Rauchmelder_Team2 alarmDevice Sensor
attr Rauchmelder_Team2 alarmSettings alarm7,|Rauchmelder_Team2:.*smoke-Alarm.*|RauchAlarm|on
attr Rauchmelder_Team2 devStateIcon off:general_ok *:secur_alarm
attr Rauchmelder_Team2 group Rauchmelder Teamleader
attr Rauchmelder_Team2 icon secur_smoke_detector
attr Rauchmelder_Team2 model virtual_1
attr Rauchmelder_Team2 peerIDs bla,blalbla
attr Rauchmelder_Team2 room Rauchmelder
attr Rauchmelder_Team2 webCmd teamCall:alarmOn:alarmOff


Bei Readings gibt es nur peerList und state ...


Greets

Byte

martinp876

Sollte gleich sein. Du zeigst das device. Der lead ist der channel.

Depechem

Hallo @all,
könnte hier bitte jemand eine kurze gesamte Anleitung zur Anbindung der Rauchmelder in FHEM reinschreiben.
So wie hier bei dem alten SD:
http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder
Oder sind die Befehle alle identisch?

Vielen Dank im voraus
Gruß Thomas
RaspberryPi2 / FHEM / 3 Wand-Tablets mit Tablet UI / HM USB / verschiedene HM-Aktoren / JeeLink USB für WS1600 und mehrere LaCrosse Sensoren / HEOS ...