433MHz-Funkrauchmelder Cordes CC-80, eTiger ES-D5B, Nemaxx HW-2, Jeising GS

[joachimD]

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

[joachimD]

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?

[KölnSolar]

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

[joachimD]

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!

[achim-g]

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

[joachimD]

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...

[andies]

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