HM-Sen-Db-Pcb

Begonnen von marko67, 11 Dezember 2014, 11:35:46

Vorheriges Thema - Nächstes Thema

DerTom

Hallo,

habe eben ein solches Gerät angelernt und es funktioniert auf Anhieb tadellos...

Ralf W.

#31
Hallo,

das Ding hat mich ja echt genervt. Aber ich habe es geschafft:
Internals:
   CFGFN
   DEF        3076DC
   HMLAN1_MSGCNT 56
   HMLAN1_RAWMSG RE5835A44,0001,446286FF,FF,FFB9,1DA0103076DC1E9E3701000000
   HMLAN1_RSSI -71
   HMLAN1_TIME 2015-01-13 23:56:38
   HMUSB_MSGCNT 56
   HMUSB_RAWMSG E3076DC,0000,00239500,FF,FFD2,1DA0103076DC1E9E3701000000
   HMUSB_RSSI -46
   HMUSB_TIME 2015-01-13 23:56:38
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     112
   NAME       CUL_HM_HM_Sen_DB_PCB_3076DC
   NR         414
   STATE      Btn1 offShort (to VCCU)
   TYPE       CUL_HM
   lastMsg    No:1D - t:10 s:3076DC d:1E9E37 01000000
   protLastRcv 2015-01-13 23:56:38
   protSnd    43 last_at:2015-01-13 23:56:38
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-72.94 min:-93 max:-62 lst:-71 cnt:56
   rssi_at_HMUSB avg:-40.03 min:-52 max:-36 lst:-46 cnt:56
   Readings:
     2015-01-13 23:53:07   CommandAccepted yes
     2015-01-13 23:56:37   D-firmware      1.0
     2015-01-13 23:56:37   D-serialNr      LEQ1220673
     2015-01-13 23:56:37   PairedTo        0x1E9E37
     2015-01-13 23:39:09   R-longPress     0.4 s
     2015-01-13 23:53:08   R-pairCentral   0x1E9E37
     2015-01-13 23:39:09   R-sign          off
     2015-01-13 23:56:37   RegL_00:          02:01 05:00 0A:1E 0B:9E 0C:37 14:06 18:00 00:00
     2015-01-13 23:56:38   RegL_01:          04:10 08:00 30:06 00:00
     2015-01-13 23:52:55   alive           yes
     2015-01-13 23:52:55   battery         ok
     2015-01-13 23:52:55   powerOn         2015-01-13 23:52:55
     2015-01-13 23:52:55   recentStateType info
     2015-01-13 23:44:52   state           Btn1 offShort (to VCCU)
     2015-01-13 23:44:52   trigDst_VCCU    noConfig
     2015-01-13 23:44:52   trigger         Short_12
     2015-01-13 23:44:52   trigger_cnt     12
   Helper:
     addVal     1
     cSnd       011E9E373076DC0103
     mId        00DC
     peerIDsRaw ,00000000
     rxType     4
     Io:
       newChn     +3076DC,00,01,FE1F
       nextSend   1421189798.64627
       rxt        0
       vccu       VCCU
       p:
         3076DC
         00
         01
         FE1F
       prefIO:
         HMLAN1
     Mrssi:
       mNo        1D
       Io:
         HMLAN1     -69
         HMUSB      -46
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1421189798.54231
       ack:
         HASH(0x3668fc8)
         1D80021E9E373076DC00
     Rssi:
       At_hmlan1:
         avg        -72.9464285714286
         cnt        56
         lst        -71
         max        -62
         min        -93
       At_hmusb:
         avg        -40.0357142857143
         cnt        56
         lst        -46
         max        -36
         min        -52
     Shadowreg:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU:HMLAN1
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-Sen-DB-PCB
   peerIDs    00000000,
   room       CUL_HM
   serialNr   LEQ1220673
   subType    pushButton


Die Lösung war der Austausch der mitgelieferten Batterien. Pairing angeschmissen, Taste gedrückt, fertig. battery bei allen Fehlversuchen stand auf ok

MfG
http://twitter.com/RWausD
Schon gewusst, dass Haarausfall zu einer Glatze führen kann?

FHEM: NUC7PJYH2, Ubuntu Server 22.04.2 LTS, HMCCU - RaspberryMatic, DE ConBee II, diverse Sensoren und Aktoren.

vuffiraa

Zitat von: Ralf W. am 14 Januar 2015, 00:03:36
Die Lösung war der Austausch der mitgelieferten Batterien. Pairing angeschmissen, Taste gedrückt, fertig. battery bei allen Fehlversuchen stand auf ok

Bei meinem Bausatz waren gar keine Batterien dabei  :( Ich hatte bei ELV bestellt.
Also einfach immer mal probieren...

Gruß
FHEM 5.8 auf Cubietruck, Raspi B+

Weinzierl KNX IP BAOS 770, Homematic, EnOcean

Ralf W.

Zitat
... Bei meinem Bausatz waren gar keine Batterien dabei  ...

Mmmhhh ...
Wenn ich noch mal überlege, kann ich gar nicht mehr sagen, ob Batterien dabei waren. Habe an dem Tag mehrere neue Devices in Betrieb genommen. Aber Batteriewechsel hat geholfen.

MfG
http://twitter.com/RWausD
Schon gewusst, dass Haarausfall zu einer Glatze führen kann?

FHEM: NUC7PJYH2, Ubuntu Server 22.04.2 LTS, HMCCU - RaspberryMatic, DE ConBee II, diverse Sensoren und Aktoren.

vuffiraa

#34
Ok, einen Versuch ist es wert. Bei ELV in den Diskussionen zum Klingelsensor gibt es einen ähnlichen Beitrag. Da hat die Anbindung an eine CCU2 erst mit starken Batterien geklappt.

Ich mach mich dann mal auf die Suche nach frischen Batterien  ;)

Edit: Der Versuch war leider nicht erfolgreich. Ich habe die stärksten Batterien einer neuen Packung versucht und konnte den Klingelsensor nicht mit Fhem pairen :(
FHEM 5.8 auf Cubietruck, Raspi B+

Weinzierl KNX IP BAOS 770, Homematic, EnOcean

ohweh

#35
Moin,

mein HM-SEN-DB-PCB liess sich ebenfalls nicht pairen (aktuelles FHEM mit CUL v3, FW v1.62). Basierend auf Martins Hinweisen hab ich mir die Kommunikation dann im Detail angeschaut.

1.) Existiert das Device nicht (i.e. AutoCreate wird durchlaufen), kann FHEM/CUL die ~120 ms nicht halten. Der Sensor empfängt das Paket nicht (weil Timing daneben), und wiederholt. Der Pairing-Request müsste ein zweites mal zum Sensor geschickt werden, das bleibt aber aus (all das hat Martin ja auch schon treffend beschrieben). Kommunikation beendet, LED blinkt rot.

2015.01.17 09:18:04.829 4: CUL_Parse: HM_CUL A 1A 02 8400 3077AC 000000 1000DC4C455131323230383831400101013A -45
2015.01.17 09:18:04.659 4: CUL_send:  HM_CULAs 10 01 A001 F12233 3077AC 00050000000000
2015.01.17 09:18:04.588 3: CUL_HM set CUL_HM_HM_Sen_DB_PCB_3077AC getConfig
2015.01.17 09:18:04.576 3: CUL_HM pair: CUL_HM_HM_Sen_DB_PCB_3077AC pushButton, model HM-Sen-DB-PCB serialNr
2015.01.17 09:18:04.335 2: CUL_HM Unknown device CUL_HM_HM_Sen_DB_PCB_3077AC is now defined
2015.01.17 09:18:04.332 4: CUL_Parse: HM_CUL A 1A 01 8400 3077AC 000000 1000DC4C4551313232303838314001010131 -49.5


2.) Weitere Versuche sind erstmal sinnlos, FHEM/CUL erhöht seinen Paket-Counter um 1, schickt also den nächsten Request mit "2" los. Während der Sensor wieder zwei Antworten schickt (3 + 4), die aber nicht zum Request passen. Die LED blinkt jedesmal rot. Aber das Timing stimmt.

2015.01.17 09:21:18.468 4: CUL_Parse: HM_CUL A 1A 04 8400 3077AC 000000 1000DC4C455131323230383831400101012A -53
2015.01.17 09:21:18.299 4: CUL_send:  HM_CULAs 10 02 A001 F12233 3077AC 00050000000000
2015.01.17 09:21:18.198 4: CUL_Parse: HM_CUL A 1A 03 8400 3077AC 000000 1000DC4C4551313232303838314001010124 -56


3.) Lässt man FHEM weiter laufen, resettet das HM-SEN-DB-PCB, und versucht wieder zu pairen, kriegt man das hier zu sehen:

2015.01.17 09:31:53.245 4: CUL_Parse: HM_CUL A 0A 05 8002 3077AC F12233 8039 -45.5
2015.01.17 09:31:53.090 4: CUL_send:  HM_CULAs 13 05 A001 F12233 3077AC 000802010AF10B220C33
2015.01.17 09:31:52.989 4: CUL_Parse: HM_CUL A 1A 04 8400 3077AC 000000 1000DC4C4551313232303838314001010136 -47
2015.01.17 09:31:52.820 4: CUL_send:  HM_CULAs 10 04 A001 F12233 3077AC 00050000000000
2015.01.17 09:31:52.718 4: CUL_Parse: HM_CUL A 1A 03 8400 3077AC 000000 1000DC4C4551313232303838314001010135 -47.5


FHEM/CUL schickt seinen Pairing-Request mit 4, und das Device antwortet auch mit Paket-ID 4. Dummerweise ist die Antwort Quatsch, das Device hat den Pairing-Request nicht geschluckt. Sondern schickt nur seinen Status. Weiss FHEM/CUL nicht (wobei, müsste es nicht auf Reply "00" prüfen?) und fordert weitere Daten an (5), was der HM-SEN-DB-PCB mit einem NACK quittiert. Aber ab diesem Moment blinkt die LED grün.

4.) Schmock, Zeit für Plan B. Also hab ich einen HM-CFG-USB und die hauseigenen Homematic-Tools belauscht (hmId ist gleich, also nicht wundern).

2015.01.14 09:09:20.386 4: CUL_Parse: CUL_HM  960386 A FF01 04481080 11 04 A002 3077AC F12233 04BE3EDE41BE3E00 -40.5
2015.01.14 09:09:20.371 4: CUL_Parse: CUL_HM  960371 A FF01 04480960 19 04 A004 F12233 3077AC B98D06604B0E3E68EDC25CE610A7D778 -50
2015.01.14 09:09:20.366 4: CUL_Parse: CUL_HM  960365 A FF01 04480888 0A 03 8002 3077AC F12233 00 -40.5
2015.01.14 09:09:20.211 4: CUL_Parse: CUL_HM  960210 A FF01 04480752 0B 03 A001 F12233 3077AC 0006 -49.5
2015.01.14 09:09:20.205 4: CUL_Parse: CUL_HM  960205 A FF01 04480688 0A 02 8002 3077AC F12233 00 -41
2015.01.14 09:09:20.195 4: CUL_Parse: CUL_HM  960195 A FF01 04480568 13 02 A001 F12233 3077AC 000802010AF10B220C33 -50
2015.01.14 09:09:20.189 4: CUL_Parse: CUL_HM  960189 A FF01 04480472 0A 01 8002 3077AC F12233 00 -41.5
2015.01.14 09:09:20.179 4: CUL_Parse: CUL_HM  960179 A FF01 04480352 10 01 A001 F12233 3077AC 00050000000000 -49.5
2015.01.14 09:09:20.165 4: CUL_Parse: CUL_HM  960164 A FF01 04480320 1A 02 8400 3077AC 000000 1000DC4C45513132323038383140010101 -42
2015.01.14 09:09:19.928 4: CUL_Parse: CUL_HM  959927 A FF01 04480184 10 01 A001 F12233 3077AC 00050000000000 -47
2015.01.14 09:09:19.711 4: CUL_Parse: CUL_HM  959711 A FF01 04479688 1A 01 8400 3077AC 000000 1000DC4C45513132323038383140010101 -44.5


Schau an, deren AutoCreate hat auch nen Delay von 200 ms :) Viel interessanter aber ist, dass der HM-SEN-DB-PCB auch hier zweimal seinen Status schickt. Und der HM-CFG-USB zwei mal mit einem Pairing-Request antworten muss, bevor der HM-SEN-DB-PCB diesen auch schluckt. Ich bin jetzt überfragt ob das bei anderen Homematic-Devices auch so ist? Ich bin mir aber sicher, dass Martin das weiss :)

5.) Zuguterletzt hab ich mir ein HM-CFG-LAN besorgt und eine vCCU gebaut (CUL + HMLAN). Den CUL rausgezogen und erneut gepaired.

2015.01.17 10:27:42.864 5: HMLAN_Parse: HM_LAN1 R:RF7383159 stat:0001 t:00164DDD d:FF r:FFE5     m:2C A010 3077AC F12233 02020105000AF10B220C33140618000000
2015.01.17 10:27:42.759 5: HMLAN_Parse: HM_LAN1 R:E3077AC   stat:0000 t:00164DD8 d:FF r:FFE5     m:2C A010 3077AC F12233 02020105000AF10B220C33140618000000
2015.01.17 10:27:42.438 5: HMLAN_Send:  HM_LAN1 S:SF7383159 stat:  00 t:00000000 d:01 r:F7383159 m:2C A001 F12233 3077AC 00040000000000
2015.01.17 10:27:42.344 5: HMLAN_Parse: HM_LAN1 R:RF7382FC0 stat:0001 t:00164C40 d:FF r:FFE5     m:2B 8002 3077AC F12233 00
2015.01.17 10:27:42.027 5: HMLAN_Send:  HM_LAN1 S:SF7382FC0 stat:  00 t:00000000 d:01 r:F7382FC0 m:2B A001 F12233 3077AC 0006
2015.01.17 10:27:41.935 5: HMLAN_Parse: HM_LAN1 R:RF7382E37 stat:0001 t:00164AA6 d:FF r:FFE5     m:2A 8002 3077AC F12233 00
2015.01.17 10:27:41.631 5: HMLAN_Send:  HM_LAN1 S:SF7382E37 stat:  00 t:00000000 d:01 r:F7382E37 m:2A A001 F12233 3077AC 000802010AF10B220C33
2015.01.17 10:27:41.537 5: HMLAN_Parse: HM_LAN1 R:RF7382C95 stat:0001 t:00164917 d:FF r:FFDF     m:29 8002 3077AC F12233 00
2015.01.17 10:27:41.407 5: HMLAN_Parse: HM_LAN1 R:E3077AC   stat:0000 t:00164878 d:FF r:FFDF     m:02 8400 3077AC 000000 1000DC4C45513132323038383140010101
2015.01.17 10:27:41.203 5: HMLAN_Send:  HM_LAN1 S:SF7382C95 stat:  00 t:00000000 d:01 r:F7382C95 m:29 A001 F12233 3077AC 00050000000000
2015.01.17 10:27:40.914 2: CUL_HM Unknown device CUL_HM_HM_Sen_DB_PCB_3077AC is now defined
2015.01.17 10:27:40.911 5: HMLAN_Parse: HM_LAN1 R:E3077AC   stat:0000 t:001646A2 d:FF r:FFDA     m:01 8400 3077AC 000000 1000DC4C45513132323038383140010101


Pairing klappt sofort. Wobei der initiale Pairing-Request mit ~300 ms Verzögerung losgetreten wird, und auch nicht wiederholt werden muss (das hätte ich jetzt eigentlich erwartet...).

Sieht für mich auf den ersten Blick nach einem CUL-FW-Problem aus. Aber vielleicht auch nur schlicht ein Timing-Problem des HM-SEN-DB-PCB? Ich versteh nicht warum der um 300ms verzögerte Pairing-Request akzeptiert wird.

Gruss
Oliver

martinp876

das pairing ist vom Ablauf her korrekt. wenn das device noch einmal wiederholt ist das schon ok.
das timing in FHEM ist natürlich nicht das Timing in der Luft. Und das ist entscheidend. da gibt es noch delay auf den interfaces. Für HMLAN/USB können wir es recht gut kompensieren. Bei der CUL arbeiten wir noch dran - es gibt schon eine Version.

Das scheint mir der Grund. HMLAN ist aktuell einfach besser von timing her. ggf. probiere die Version irgendwo in diesem Forum bei CUL

Xaser

Hallo,

meine Sprechanlage hat im Leerlauf schon eine Spannung von ca 20-30 V. Kann ich diesen Sensor nutzen, um eine Spannungsspitze als auslöser zu verwenden`? Soll heißen: Wenn jemand klingelt, steigt die spannung und FHEM löst ein Ereignis aus.

Gruß

Sebastian

vuffiraa

Zitat von: Xaser am 18 Januar 2015, 18:23:13
meine Sprechanlage hat im Leerlauf schon eine Spannung von ca 20-30 V. Kann ich diesen Sensor nutzen, um eine Spannungsspitze als auslöser zu verwenden`? Soll heißen: Wenn jemand klingelt, steigt die spannung und FHEM löst ein Ereignis aus.

In den technischen Daten steht:

  • Auslösespannung:   5–12 V AC DC

Daher denke ich mal, dass der Sensor nicht so gut für dich geeignet ist.
FHEM 5.8 auf Cubietruck, Raspi B+

Weinzierl KNX IP BAOS 770, Homematic, EnOcean

ohweh

Zitat von: martinp876 am 18 Januar 2015, 17:48:53
das pairing ist vom Ablauf her korrekt. wenn das device noch einmal wiederholt ist das schon ok.
das timing in FHEM ist natürlich nicht das Timing in der Luft. Und das ist entscheidend. da gibt es noch delay auf den interfaces. Für HMLAN/USB können wir es recht gut kompensieren. Bei der CUL arbeiten wir noch dran - es gibt schon eine Version.

Das scheint mir der Grund. HMLAN ist aktuell einfach besser von timing her. ggf. probiere die Version irgendwo in diesem Forum bei CUL

Hi Martin,

die andere FW mit der Timing-Optimierung hab ich schon getestet (Version vom 10.01.), aber ohne Erfolg. Selbiges Ergebnis mit einem zweiten CUL... Ich versteh auch dass das mit dem Timing beim CUL (noch) nicht optimal ist, auf der anderen Seite hab ich ne Menge HM-Geräte am Start und keine nennenswerten Probleme. Insofern glaube ich, dass am Sensor irgendwas oberfaul bzw. anders ist als sonst.

Aber wir sind uns doch einig, dass der Pairing-Request wiederholt werden sollte wenn das Device nicht auf den Request reagiert?

Gruss
Oliver

martinp876

das device wiederholt - oder nicht.
FHEM wiederholt, was es sendet, wenn keine Antwort kommt - begrenzt natürlich

raimundl

Hallo!

Ja leider lässt sich mein "Doorbell Sensor" wie hier bereits ausführlich beschrieben nicht pairen:

R-pairCentral:  set_0xF21034.

Wenn man jedoch entgegen der ELV Anleitung den Taster zwischen "input" und "Push Button" anschließt, kommt beim Drücken folgender:

STATE: Btn1 offShort (to broadcast)
CUL_0_MSGCNT:  16 (zählt hoch).

Könnte man diese Reaktion für Schaltzwecke vorerst ausnützen??
Als Zwischenlösung bis das Pairingproblem gelöst ist?

LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

vuffiraa


Zitat von: raimundl am 14 Februar 2015, 20:33:36
Könnte man diese Reaktion für Schaltzwecke vorerst ausnützen??
Als Zwischenlösung bis das Pairingproblem gelöst ist?
Hallo,
mein Klingelsensor ist leider auch nicht so kommunikativ. Ich konnte ihn bisher weder mit Fhem pairen noch mit meinem Funkgong peeren. Per notify habe ich alles zum Laufen bekommen. Die Lösung braucht halt ein laufendes Fhem. Im EventMonitor sieht man ganz gut, vorauf man das notify ansetzen kann.
Hier meine Definition als Beispiele:
define Klingel notify HM_Sen_DB_PCB:trigger:.* {\
  fhem("set HM_OU_CF_PL_Led,HM_OU_CF_PL_Sound on")\
}


Gruß
FHEM 5.8 auf Cubietruck, Raspi B+

Weinzierl KNX IP BAOS 770, Homematic, EnOcean

raimundl

Herzlichen Dank - funktioniert!

Jetzt muss nur noch die Reichweite passen um als Klingel in ca. 60 Meter Entfernung zu funktionieren.

Danke und LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

frank

ZitatJetzt muss nur noch die Reichweite passen um als Klingel in ca. 60 Meter Entfernung zu funktionieren.
die hoffnung stirbt zuletzt.  :)
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