FHEM Forum

Hallo allerseits,

ich habe zwar per Forensuche andere Anfragen gefunden, aber noch keine Lösungen.

Wie mir scheint, sind die Funkrauchmelder

Cordes CC-80  http://www.cordes-vertrieb.de/
eTiger ES-D5B http://etiger.com/eu/support/accessories/es-d5b/
Nemaxx HW-2 http://efulfillment-online.com/portfolio-items/hw-2-funkrauchmelder-hitzemelder-in-einem-geraet/
Jeising GS558 https://www.amazon.de/Jeising-Funkrauchmelder-Klebepad-Brandmelder-EN14604/dp/B017DGSS0M

vermutlich allesamt baugleich (zumindestens nutzen sie das gleiche Gehäuse, auch die Spezifikationen scheinen mir ziemlich identisch zu sein). Von FHEM werden sie bislang aber anscheinend noch nicht unterstützt; mein 433-MHz-CUL liefert (noch) wenig hilfreiche Daten.

Gibt es jemanden, der sich schon intensiver mit dem hier verwendeten Protokoll (wenn es wirklich überall dasselbe ist) auseinandergesetzt hat?

Viele Grüße
Joachim

Nachtrag: Die Kommunikation der Cordes CC-80-Rauchmelder beim Anlernen/Übertragen des Hauscodes liefert mit der a-culfw v1.21 auf dem CUL-433 folgende Protokolleinträge:

2016.10.25 19:43:43 5: CUL/RAW: /omDB6DB6DB0004
2016.10.25 19:43:43 4: CUL_Parse: CUL0 omDB6DB6DB0004
2016.10.25 19:43:43 5: CUL0 dispatch omDB6DB6DB0004
2016.10.25 19:43:43 5: CUL_REDIRECT (mDB6DB6DB0004) length: 13 RSSI: -72
2016.10.25 19:43:43 5: CUL_REDIRECT (mDB6DB6DB0004) match Manchester COODE length: 13
2016.10.25 19:43:43 5: CUL_REDIRECT decode Oregon 2 (DB6DB6DB0004)
2016.10.25 19:43:43 5: bitdata: 110110110110110110110110110110110000000000000100
2016.10.25 19:43:43 5: CUL_REDIRECT decode Oregon 3 (DB6DB6DB0004)
2016.10.25 19:43:43 5: bitdata: 110110110110110110110110110110110000000000000100
2016.10.25 19:43:43 5: CUL_REDIRECT decode Hideki (DB6DB6DB0004)
2016.10.25 19:43:43 5: CUL0: search in 110110110110110110110110110110110000000000000100
2016.10.25 19:43:43 5: protocol does not match, ignore received package (DB6DB6DB0004) Reason: Not a hideki protocol
2016.10.25 19:43:44 5: CUL/RAW: /omDB45E018
2016.10.25 19:43:44 4: CUL_Parse: CUL0 omDB45E018
2016.10.25 19:43:44 5: CUL0 dispatch omDB45E018
2016.10.25 19:43:44 5: CUL_REDIRECT (mDB45E018) length: 9 RSSI: -62
2016.10.25 19:43:44 5: CUL_REDIRECT (mDB45E018) match Manchester COODE length: 9
2016.10.25 19:43:44 5: CUL_REDIRECT decode Oregon 2 (DB45E018)
2016.10.25 19:43:44 5: bitdata: 11011011010001011110000000011000
2016.10.25 19:43:44 5: CUL_REDIRECT decode Oregon 3 (DB45E018)
2016.10.25 19:43:44 5: bitdata: 11011011010001011110000000011000
2016.10.25 19:43:44 5: CUL_REDIRECT decode Hideki (DB45E018)
2016.10.25 19:43:44 5: CUL0: search in 11011011010001011110000000011000
2016.10.25 19:43:44 5: protocol does not match, ignore received package (DB45E018) Reason: Not a hideki protocol
2016.10.25 19:43:45 5: CUL/RAW: /omDB681C1B
2016.10.25 19:43:45 4: CUL_Parse: CUL0 omDB681C1B
2016.10.25 19:43:45 5: CUL0 dispatch omDB681C1B
2016.10.25 19:43:45 5: CUL_REDIRECT (mDB681C1B) length: 9 RSSI: -60.5
2016.10.25 19:43:45 5: CUL_REDIRECT (mDB681C1B) match Manchester COODE length: 9
2016.10.25 19:43:45 5: CUL_REDIRECT decode Oregon 2 (DB681C1B)
2016.10.25 19:43:45 5: bitdata: 11011011011010000001110000011011
2016.10.25 19:43:45 5: CUL_REDIRECT decode Oregon 3 (DB681C1B)
2016.10.25 19:43:45 5: bitdata: 11011011011010000001110000011011
2016.10.25 19:43:45 5: CUL_REDIRECT decode Hideki (DB681C1B)
2016.10.25 19:43:45 5: CUL0: search in 11011011011010000001110000011011
2016.10.25 19:43:45 5: protocol does not match, ignore received package (DB681C1B) Reason: Not a hideki protocol

Gibt's Experten, die das übesetzen können?

Meine Übersetzung: Protokoll ist nicht in fhem bzw. a-culfw implementiert  :'( Dann wird es meist kompliziert. Allerdings scheinen es nur 9 nibbles zu sein. Lässt sich das durch Langzeittests bestätigen ? Vielleicht wurde auch nur eine Impuls als Übertragungsende erkannt  :( Sind die Meldungen im Log bei Auslösen eines Melders auch nur 9 nibbles ? Bei Batteriewechsel Änderung der Codes ? Ist der Logauszug von 3 verschiedenen Geräten ?
Grüße Markus

Zitat von: KölnSolar am 25 Oktober 2016, 20:58:58
Allerdings scheinen es nur 9 nibbles zu sein. Lässt sich das durch Langzeittests bestätigen ? Vielleicht wurde auch nur eine Impuls als Übertragungsende erkannt  :( Sind die Meldungen im Log bei Auslösen eines Melders auch nur 9 nibbles ? Bei Batteriewechsel Änderung der Codes ? Ist der Logauszug von 3 verschiedenen Geräten ?

Sorry für meine späte Antwort - versehentlich hatte ich keine Benachrichtigung aktiviert!

Ich fürchte, es ist nicht ganz so einfach. Die folgenden Nachrichten im FHEM-Protokoll führe ich auf die beiden Rauchmelder (mit gemeinsamen Hauscode) zurück, und die Länge ist zumindestens variabel (wenn der Code denn überhaupt richtig gelesen wird):

2016.10.29 19:59:52 4: CUL_Parse: CUL0 omA95554EA
2016.10.29 20:01:32 4: CUL_Parse: CUL0 omA8AA68E5
2016.10.29 20:01:32 4: CUL_Parse: CUL0 omAAD554E9
2016.10.29 20:01:39 4: CUL_Parse: CUL0 om92AAAAF9
2016.10.29 20:02:48 4: CUL_Parse: CUL0 omA92AAAA0F6
2016.10.29 20:02:48 4: CUL_Parse: CUL0 omA95554F5
2016.10.29 20:02:52 4: CUL_Parse: CUL0 omA92AAAA0F5
2016.10.29 20:04:52 4: CUL_Parse: CUL0 omA95554F9
2016.10.29 20:05:17 4: CUL_Parse: CUL0 omAACAAAA8F3
2016.10.29 20:05:17 4: CUL_Parse: CUL0 omA95554F4
2016.10.29 20:05:17 4: CUL_Parse: CUL0 omA92AAAA0F4
2016.10.29 20:05:22 4: CUL_Parse: CUL0 omA95550F8
2016.10.29 20:10:37 4: CUL_Parse: CUL0 omA92AAAA000
2016.10.29 20:10:48 4: CUL_Parse: CUL0 omA92AAAF7
2016.10.29 20:10:52 4: CUL_Parse: CUL0 omAAD55540F9
2016.10.29 20:13:07 4: CUL_Parse: CUL0 om92AAAAF2
2016.10.29 20:13:29 4: CUL_Parse: CUL0 omAACAAAA8FE
2016.10.29 20:13:33 4: CUL_Parse: CUL0 omAAAAAAA0FF
2016.10.29 20:13:36 4: CUL_Parse: CUL0 om95555400
2016.10.29 20:13:43 4: CUL_Parse: CUL0 omAAAAAAA0FF
2016.10.29 20:13:54 4: CUL_Parse: CUL0 omA92AAAA0F9
2016.10.29 20:13:54 4: CUL_Parse: CUL0 omA94AAAA8F9
2016.10.29 20:13:54 4: CUL_Parse: CUL0 omA92AAAA0F9
2016.10.29 20:59:49 4: CUL_Parse: CUL0 omA5551C
2016.10.29 22:05:26 4: CUL_Parse: CUL0 omDB2AA013
2016.10.29 22:52:17 4: CUL_Parse: CUL0 omA55506
2016.10.29 22:59:10 4: CUL_Parse: CUL0 omA55507
2016.10.29 23:04:10 4: CUL_Parse: CUL0 om92AAAA07
2016.10.29 23:05:08 4: CUL_Parse: CUL0 omDB555554F3
2016.10.29 23:05:10 4: CUL_Parse: CUL0 omDB2AAAFB
2016.10.29 23:06:45 4: CUL_Parse: CUL0 omDAAAAA80ED
2016.10.29 23:45:53 4: CUL_Parse: CUL0 omDB2A8025
2016.10.29 23:47:08 4: CUL_Parse: CUL0 omDAAAAAA824
2016.10.30 00:03:03 4: CUL_Parse: CUL0 omDAAAAA8017
2016.10.30 00:05:52 4: CUL_Parse: CUL0 omDB55401E
2016.10.30 00:22:42 4: CUL_Parse: CUL0 omD52AA410
2016.10.30 00:42:41 4: CUL_Parse: CUL0 om95569021
2016.10.30 01:03:12 4: CUL_Parse: CUL0 omDAAAAAAA8016
2016.10.30 01:03:23 4: CUL_Parse: CUL0 omDAAAAA8011
2016.10.30 01:05:58 4: CUL_Parse: CUL0 omDA555419
2016.10.30 01:09:17 4: CUL_Parse: CUL0 om92AA40F1
2016.10.30 09:01:38 4: CUL_Parse: CUL0 omD52AA0F8
2016.10.30 09:01:46 4: CUL_Parse: CUL0 omA92AAA40F0
2016.10.30 09:01:46 4: CUL_Parse: CUL0 omA92940EF

Momentan komme ich leider nicht zu systematischen Tests, aber ich werde das baldmöglichst nachholen (also: Synchronisieren von mehreren Rauchmeldern, Batterie raus/rein, Auslösen) und hier berichten.

Danke für's Mitdenken!

Hallo Joachim,
bist Du bei dem Thema hier schon weitergekommen?

Nein, leider nicht. Die Rauchmelder wurden jüngst in einem lokalen Baumarkt unter anderem Label noch günstiger verkauft - es wäre schon lohnenswert, das Protokoll genauer zu betrachten.

Habe aber nur sehr sporadisch Zeit dafür...

Ich versuche hier mal weiterzukommen, siehe https://forum.fhem.de/index.php/topic,31290.msg238036.html#msg238036 (https://forum.fhem.de/index.php/topic,31290.msg238036.html#msg238036)
Nur sollten wir das nur in einem Thread tun. Welchem?