HM-SEC-SD Rauchmelder kann nicht gepaired werden

[Barracus]

Hallo zusammen,

ich habe ein Problem mit diesem Rauchmelder.
Ich hatte bis vor ca. einem Jahr 3 Stück einwandfrei im Betrieb (mit einander gepeered und mit fhem gepaired).
Dann haben sie aufgehört mit der zentrale zu sprechen und ich wollte es jetzt wieder in Ordnung bringen.
Dazu habe ich mir noch zusätzliche 5 gekauft.
Das Problem betrifft alle Geräte, alte und neue (alles das gleiche Modell, HM-SEC-SD).

Die unten genannten Geräte sind neu und waren fhem noch nicht bekannt.

Problem:
Ich habe beide Geräte mit einander gepeered (ohne fhem) und will sie jetzt in fhem anlernen.
Das Anlernen funktioniert es aber nicht, wie das "R-pairCentral   set_0xAAA001" zeigt (list habe ich unten hinzugefügt).
Was mache ich falsch?

Danke.

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        4504F3
   HMCUL_MSGCNT 18
   HMCUL_RAWMSG A0D00A4104504F3AAA00106010000::-61:HMCUL
   HMCUL_RSSI -61
   HMCUL_TIME 2017-02-01 10:11:55
   HMLANHUB_MSGCNT 18
   HMLANHUB_RAWMSG E4504F3,0000,07DBC01C,FF,FFC0,00A4104504F3AAA00106010000
   HMLANHUB_RSSI -64
   HMLANHUB_TIME 2017-02-01 10:11:55
   IODev      HMCUL
   LASTInputDev HMLANHUB
   MSGCNT     36
   NAME       eg.wz.rauchmelder
   NOTIFYDEV  global
   NR         885
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:00 - t:10 s:4504F3 d:AAA001 06010000
   protCmdDel 4
   protErrIoAttack 1 last_at:2017-02-01 10:06:39
   protErrIoId_44EA4A 6 last_at:2017-02-01 10:05:04
   protLastRcv 2017-02-01 10:11:55
   protNack   2 last_at:2017-02-01 10:05:04
   protResnd  2 last_at:2017-02-01 10:16:34
   protResndFail 2 last_at:2017-02-01 10:16:40
   protSnd    6 last_at:2017-02-01 10:16:30
   protState  CMDs_done_Errors:1
   rssi_at_HMCUL min:-64.5 avg:-61.61 lst:-61 max:-59 cnt:18
   rssi_at_HMLANHUB avg:-61.61 cnt:18 max:-58 lst:-64 min:-65
   Readings:
     2017-02-01 10:06:39   Activity        alive
     2017-02-01 10:06:39   CommandAccepted yes
     2017-02-01 10:06:39   D-firmware      1.1
     2017-02-01 10:06:39   D-serialNr      NEQ0060668
     2017-02-01 10:06:32   R-pairCentral   set_0xAAA001
     2017-02-01 10:18:26   RegL_00.
     2017-02-01 10:05:06   SDteam          add_og.bz.rauchmelder
     2017-02-01 10:11:55   battery         ok
     2017-02-01 10:11:55   level           0
     2017-02-01 10:11:55   powerOn         2017-02-01 10:11:55
     2017-02-01 10:11:55   recentStateType info
     2017-02-01 10:05:04   sabotageAttackId_ErrIoId_44EA4A  cnt:6
     2017-02-01 10:06:39   sabotageAttack_ErrIoAttack cnt 1
     2017-02-01 10:16:41   state           RESPONSE TIMEOUT:RegisterRead
   Helper:
     HM_CMDNR   1
     PONtest    0
     cSnd       01AAA0014504F300040000000000,01AAA0014504F300040000000000
     getCfgListNo
     mId        0042
     rxType     2
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4504F3,00,00,00
       nextSend   1485940315.29008
       prefIO
       rxt        0
       vccu
       p:
         4504F3
         00
         00
         00
     Mrssi:
       mNo        00
       Io:
         HMCUL      -59
         HMLANHUB   -64
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat   00
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMCUL
       flg        A
       ts         1485940315.19919
       ack:
         HASH(0x359c558)
         008002AAA0014504F300
     Rssi:
       At_hmcul:
         avg        -61.6111111111111
         cnt        18
         lst        -61
         max        -59
         min        -64.5
       At_hmlanhub:
         avg        -61.6111111111111
         cnt        18
         lst        -64
         max        -58
         min        -65
     Shadowreg:
       RegL_00.    02:01 0A:AA 0B:A0 0C:01
Attributes:
   IODev      HMCUL
   IOgrp      VCCU:HMCUL
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-SEC-SD
   msgRepeat  1
   room       CUL_HM
   serialNr   NEQ0060668
   subType    smokeDetector
   webCmd     statusRequest


[frank]

Ich habe beide Geräte mit einander gepeered (ohne fhem) und will sie jetzt in fhem anlernen.

das verstehe ich nicht. was ist dein plan? du kennst das wiki?
ich habe einen virtuellen teamlead, der mit jedem rauchmelder gepeert ist. nicht alles kreuz und quer durcheinander.

Code Auswählen Erweitern

     2017-02-01 10:05:04   sabotageAttackId_ErrIoId_44EA4A  cnt:6
     2017-02-01 10:06:39   sabotageAttack_ErrIoAttack cnt 1
wer ist 44EA4A? der gepeerte rm?
vielleicht lassen die sich nicht mehr pairen, wenn sie vorher untereinander gepeert worden sind. habe ich nie probiert, wozu auch.

[Barracus]

Hallo Frank,

du kennst das wiki?

Jawohl!

wer ist 44EA4A? der gepeerte rm?

Jup, genau.

vielleicht lassen die sich nicht mehr pairen, wenn sie vorher untereinander gepeert worden sind. habe ich nie probiert, wozu auch.

Laut Betriebsanleitung ist es möglich sie erst mit einander zu peeren, dann mit einer Zentrale anlernen. (Umgekehrt funktioniert es aber nicht)

Außerdem macht es in meinem Fall keinen Unterschied:
Auch mit einem frisch-zurückgesetztem RM, ohne vorher ein peering vorzunehmen, funktioniert das Anlernen mit der Zentrale nicht.

Ciao!

[MadMax-FHEM]

Hallo,

wahrscheinlich ist das das Problem:

2017-02-01 10:16:41   state           RESPONSE TIMEOUT:RegisterRead

Steht zusätzlich etwas im Log?

Es gibt immer wieder Probleme bzgl. Timing bei CUL und Homematic...

Evtl. mal dort reinschauen oder umsteigen auf diese FW:

https://forum.fhem.de/index.php/topic,24436.0.html

Gruß, Joachim

[Barracus]

Hallo Joachim,

die Log-Einträge sind in dem Fall ziemlich "sparsam":

Code Auswählen Erweitern


2017.02.01 11:34:23 3: Device og.bz.rauchmelder added to ActionDetector with 099:00 time
2017.02.01 11:34:23 3: CUL_HM pair: og.bz.rauchmelder smokeDetector, model HM-SEC-SD serialNr NEQ0058916
2017.02.01 11:34:56 3: CUL_HM set og.bz.rauchmelder getConfig


Ich habe eine VCCU mit einem CUL und HMLAN im Betrieb.
Das Problem trat aber schon auf, als ich nur den HMLAN hatte.

Ich schaue mal auch im anderen Thread rein.

Danke!

Ciao.

[MadMax-FHEM]

Hallo Joachim,

die Log-Einträge sind in dem Fall ziemlich "sparsam":

Code Auswählen Erweitern


2017.02.01 11:34:23 3: Device og.bz.rauchmelder added to ActionDetector with 099:00 time
2017.02.01 11:34:23 3: CUL_HM pair: og.bz.rauchmelder smokeDetector, model HM-SEC-SD serialNr NEQ0058916
2017.02.01 11:34:56 3: CUL_HM set og.bz.rauchmelder getConfig


Ich habe eine VCCU mit einem CUL und HMLAN im Betrieb.
Das Problem trat aber schon auf, als ich nur den HMLAN hatte.

Ich schaue mal auch im anderen Thread rein.

Danke!

Ciao.

Ah, du hast 2 IODevs.

Dann probier doch mal den CUL zu deaktivieren während du pairst...
...oder weise den Rauchmeldern gleich als preferredIO den HMLAN zu...
...sofern die Reichweite reicht...

Ansonsten kann es immer wieder mal Probleme geben mit dem CUL und der "Standard-FW"...

Das mit dem Log war nur, weil manchmal vergessen wird/wurde die "Verschlüsselungs-Lib" zu installieren und die Rauchmelder sind ja mit AES (soweit ich weiß).

Gruß, Joachim

[frank]

hallo barracus,

Laut Betriebsanleitung ist es möglich sie erst mit einander zu peeren, dann mit einer Zentrale anlernen. (Umgekehrt funktioniert es aber nicht)

es ist immer möglich zuerst alle devices mit fhem zu pairen und anschliessend über fhem 2 devices untereinander zu peeren.

Außerdem macht es in meinem Fall keinen Unterschied:
Auch mit einem frisch-zurückgesetztem RM, ohne vorher ein peering vorzunehmen, funktioniert das Anlernen mit der Zentrale nicht.

mit dem hmlan als preffered io sollte es funktionieren. einfach öfter drüber pairen.
wenn aber andere rm weiterhin dazwischen "quatschen", könnte das auch ein problem sein.
das sniffen des pairens würde es zeigen.

[martinp876]

Wenn ein device gepairt ist kann es sich selbst nicht mehr peeren.
Die zentrale ( fhem) kann immer alle peeren. Wenn sie gepairt ist, sonst ist es keine zentrale, logisch.

[Barracus]

Danke für eure Tipps.

Ich weiß, dass man das Peeren auch jeder Zeit in FHEM machen kann, aber in dem Fall ist für mich schneller auf die Tasten zu drucken, da ich alle RM auf dem Tisch liegen habe und mir die Tipperei spare:)

aber... Abgesehen vom Peeren: in meinem Fall ist es egal ob das Gerät noch "frisch" ist oder schon gepeert, das Pairen mit FHEM klappt nicht.

Ich würde außerdem folgenden Ursachen ausschließen:

• Andere RM die dazwischen funken: das Problem besteht auch wenn ich alle RM vom fhem entferne, die Batterien aus alle RM rausnehme, so dass sie aus sind, und nur einen frischen RM versuche zu pairen
• zusammenspiel zwischen CUL oder HMLAN: wie geschrieben, das Problem trat schon auf, als ich nur HMLAN hatte. Auch ein direktes Pairen mit dem CUL funktioniert nicht. Außerdem sollte sich die VCCU um das zusammenspiel kümmern (wenn ich die Funktion richtig verstanden habe )

Ich werde in den nächsten Tagen versuchen zu "Sniffen", mal schauen

Danke nochmal!

(Falls jemand noch Ideen hat, sehr gerne )

Ciao![/list]

[Barracus]

Hallo,

ich habe heute wieder Zeit gehabt und habe den Paring-Versuch gesniffed.
Ich muss aber gestehen... mir sagen die Botschaften eigentlich nichts

Sieht jemand etwas verdächtiges?

Ich habe diese 3 Schritte durchgeführt:
- Pairing
- Umbenennen in eg.wz.rauchmelder
- getConfig

Code Auswählen Erweitern


2017.02.04 21:37:12.792 4: CUL_Parse: HMCUL A 0F CD 8610 38E44D 000000 0AA8E10B0340F1 -81.5
2017.02.04 21:37:16.354 4: CUL_Parse: HMCUL A 0F C7 8610 220A06 000000 0A90E90E001715 -63.5
2017.02.04 21:37:31.488 4: CUL_Parse: HMCUL A 0F 44 8610 220A01 000000 0AA8E80E0026F3 -80.5
2017.02.04 21:37:36.020 4: CUL_Parse: HMCUL A 0F 20 8610 38EDCF 000000 0AB8FB0B054002 -73
2017.02.04 21:38:00.879 4: CUL_Parse: HMCUL A 1A 02 8400 4504F3 000000 1100424E455130303630363638CD0001001E -59
2017.02.04 21:38:00.981 4: CUL_send:  HMCULAs 10 2A A001 AAA001 4504F3 00050000000000
2017.02.04 21:38:01.309 4: CUL_send:  HMCULAs 13 2B A001 AAA001 4504F3 000802010AAA0BA00C01
2017.02.04 21:38:01.324 4: CUL_Parse: HMCUL A 0A 2A 8002 4504F3 AAA001 0020 -58
2017.02.04 21:38:01.467 4: CUL_Parse: HMCUL A 0A 2B 8002 4504F3 AAA001 0021 -57.5
2017.02.04 21:38:01.568 4: CUL_send:  HMCULAs 0B 2C A001 AAA001 4504F3 0006
2017.02.04 21:38:01.724 4: CUL_Parse: HMCUL A 0A 2C 8002 4504F3 AAA001 0020 -58
2017.02.04 21:38:14.211 4: CUL_Parse: HMCUL A 0D 00 8410 4504F3 000000 060100001F -58.5
2017.02.04 21:38:15.264 4: CUL_Parse: HMCUL A 0F 47 8610 38ED98 000000 0AB0F10C0340F6 -79
2017.02.04 21:38:16.649 4: CUL_Parse: HMCUL A 1A 01 8400 4504F3 000000 1100424E455130303630363638CD0001001F -58.5
2017.02.04 21:38:27.619 4: CUL_Parse: HMCUL A 0F 43 8610 220A1D 000000 0AA4EA0E00181B -60.5
2017.02.04 21:38:35.686 4: CUL_Parse: HMCUL A 0F ED 8610 22324E 000000 0A98D50F005811 -65.5
2017.02.04 21:38:38.887 4: CUL_Parse: HMCUL A 0F 2E 8610 220A19 000000 0AA4E70E00611E -59
2017.02.04 21:38:39.778 4: CUL_Parse: HMCUL A 0F F4 8610 2209EE 000000 0AA8E20D0563FB -76.5
2017.02.04 21:38:46.436 4: CUL_Parse: HMCUL A 0F 66 8610 221663 000000 0AA0DF0E002917 -62.5
2017.02.04 21:38:47.218 4: CUL_Parse: HMCUL A 0F 83 8610 38EBDC 000000 0A88AC0C004034 -48
2017.02.04 21:38:48.172 4: CUL_Parse: HMCUL A 0F 89 8610 38EB06 000000 0AB0F40B0240F7 -78.5
2017.02.04 21:38:57.988 4: CUL_Parse: HMCUL A 0F E9 8610 38ED13 000000 0A94E10B004007 -70.5
2017.02.04 21:39:06.599 4: CUL_Parse: HMCUL A 1A 02 8400 4504F3 000000 1100424E455130303630363638CD0001001E -59
2017.02.04 21:39:07.960 4: CUL_send:  HMCULAs 10 2A A001 AAA001 4504F3 00050000000000
2017.02.04 21:39:08.117 4: CUL_Parse: HMCUL A 0A 2A 8002 4504F3 AAA001 0022 -57
2017.02.04 21:39:08.218 4: CUL_send:  HMCULAs 13 2B A001 AAA001 4504F3 000802010AAA0BA00C01
2017.02.04 21:39:08.521 4: CUL_send:  HMCULAs 0B 2C A001 AAA001 4504F3 0006
2017.02.04 21:39:08.535 4: CUL_Parse: HMCUL A 0A 2B 8002 4504F3 AAA001 0022 -57
2017.02.04 21:39:08.678 4: CUL_Parse: HMCUL A 0A 2C 8002 4504F3 AAA001 0023 -56.5
2017.02.04 21:39:09.104 4: CUL_Parse: HMCUL A 0F BC 8610 38EE53 000000 0A88AD0C05402E -51
2017.02.04 21:39:32.106 4: CUL_Parse: HMCUL A 0F C8 8610 220A06 000000 0A90E90E001715 -63.5
2017.02.04 21:39:42.541 4: CUL_Parse: HMCUL A 0F CE 8610 38E44D 000000 0AA8E10B0340F1 -81.5
2017.02.04 21:39:43.271 4: CUL_Parse: HMCUL A 0F 21 8610 38EDCF 000000 0AB8FB0B064002 -73
2017.02.04 21:39:46.738 4: CUL_Parse: HMCUL A 0F 45 8610 220A01 000000 0AA8E70E0026F2 -81
2017.02.04 21:40:24.105 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_autocreate.pm line 344.
2017.02.04 21:40:24.105 1: ./log/eg.wz.rauchmelder-2017.log or :
2017.02.04 21:40:42.065 4: CUL_send:  HMCULAs 10 2D B001 AAA001 4504F3 00040000000000
2017.02.04 21:40:45.516 4: CUL_Parse: HMCUL A 0F 48 8610 38ED98 000000 0AB0F10C0340F4 -80
2017.02.04 21:40:47.340 4: CUL_send:  HMCULAs 10 2D B001 AAA001 4504F3 00040000000000
2017.02.04 21:40:49.422 4: CUL_Parse: HMCUL A 0F 8A 8610 38EB06 000000 0AB0F40B0240F5 -79.5


Danke!

Ciao.

[martinp876]

Ich sehe ein config mit pairen.
15s später ein neues config. Hast du noch einmal gedrückt? Oder reset gemacht?
Ein SD muss immer ansprechbar sein. Wie könnte sonst die Gruppenschaltung funktionieren?
Dann noch ein config, noch einmal gepairt. Kann man häufiger machen. Macht aber keinen Sinn.

Drückst du nach dem pairen auf den Buttons rum?

[Barracus]

Hallo Martin,

nein ich habe nicht rumgedrückt.

Ich habe folgendes gemacht:
- Gerät von FHEM entfernt
- VCCU auf Pairing gesetzt und am SD gedrückt.
- Taster am SD gedrückt... hat aber rot geblinkt, da schon gepaired (war aber in FHEM nicht ansprechbar) - ich hatte vergessen den SD zurückzusetzen.
- SD zurückgesetzt
- VCCU nochmal auf pairing
- Taster am SD gedrückt. Hat einmal gelb geblinkt und aufeghört.
- in FHEM umbenannt
- getConfig

Das getConfig funktioniert aber nicht. Der Status vom SD ist RESPONSE TIMEOUT:RegisterRead

Ciao.

[martinp876]

Das erklärt das mehrfache pairen.
Der SD reagiert nicht auf das getconfig. Der burst wird korrekt gesendet.
Bei mir funktioniert es. Der einzige Unterschied ist, dass meine bereits in einem Team sind. Also Empfangsbereich sein müssen. Schon einige Zeit her, aber ich denke die SDS müssen nicht gepeerten sein um burst einzuschalten.
Sorry, geht einfach nicht. Ich halte ihn für defekt, da es ein ganz einfacher Ablauf ist.

Allerdings: welche SW setzt du ein? Warum die rssi Werten in den logs? Ist alles auf stand?

[Barracus]

Was meinst du mit SW?

in FHEM ist alles auf Stand (mache regelmäßig Updates - das letzte Mal heute Abend)
Für die Geräte habe ich noch keine FW Updates durchgeführt.

Das das Gerät Defekt ist würde ich aus folgendem Grund ausschließen:
Historie:
Am Anfang hat 1 SD aufgehört zu funktionieren, den ich mittlerweile glaube defekt zu sein, da auch nach dem Zurücksetzten sich einfach nicht pairen bzw. peeren (auch außerhalb fhem lässt).
Die weitere 2 haben dann nach kurzem auch aufgehört zu funktionieren.
Als alle 3 noch funktioniert haben, hatte ich mir noch 5 Stück gekauft (wir sind in einem großeren Haus umgezogen).
Das alles als ich nur einen HMLAN im Einsatz hatte.

Deswegen sitze ich jetzt da mit 1 defekten SD, 2 alte funktionierenden und 5 neue

Die Pairing-Tests habe ich mit 2 neuen und den 2 alten gemacht, mit dem HMLAN, mit dem CUL und neulich mit der VCCU. Hat leider immer nicht geklappt.
(Bei der ersten Tests hatte ich nur den HMLAN aktiv, der CUL lag in einer Schublade und wurde erst später in Betrieb genommen )

Ich bin ratlos....

[martinp876]

Da bin ich auch ratlos.
Das pairing funktioniert. Das device antwortet und ist zufrieden.
Nun müsste es auf burst antworten. Also dein io sendet burst, der SD wacht auf und antwortet.
Das burst Kommando geht raus. Allerdings antwortet das device nicht.
Jetzt könnte das io den burst nicht wie angefordert senden. Oder der SD empfängt diesen nicht.
Wenn du einen Status req an andere SDs loswerden kannst dann funktioniert das io. Dann bleibt nur der SD.