(gelöst) HM-PB-2-FM Bausatz defekt? kein pairing

[linuzer]

Hallo

ich versuche verzweifelt seit Tagen obigen Schalter mit meinem CUL zu pairen, aber ohne Erfolg!
Den Schalter habe ich als Bausatz gekauft und selbst zusammengelötet, was nicht weiter schwierig war und meines Erachtens sauber ausgeführt wurde (obwohl ich kein Profi-Elektroniker bin).

Der Schalter taucht in FHEM auch auf, sieht auch alles scheinbar gut aus, ich kann ihn sogar mit meinem Dimmer peeren, aber das pairing mit der Zentrale scheint nicht abgeschlossen zu werden, denn über den Zustand

Code Auswählen Erweitern

R-pairCentral    set_0xF11134
kommt er nicht hinaus, was mir sagt, dass das pairing nicht abgeschlossen wurde.

Ich habe schon alles erdenkliche probiert, insbesondere den Schalter auf Werkeinstellungen zurück gesetzt, auch das peering mit dem Dimmer gelöscht, unzählige GetConfigs... aber egal, was ich anstelle, das pairing wird nicht abgeschlossen. Somit bin ich langsam mit meinem Latein am Ende und suche nach Experten, die mir weiterhelfen können...

1. Wie kann ich sicherstellen, dass ich beim Löten nichts verkehrt gemacht habe, bzw. kein Bauteil beschädigt ist?
2. Was kann ich noch tun, um das pairing erfolgreich durchzuführen?
3. Gibt es ein Procedere, das eventuell vorher durchgeführte pairings/peerings garantiert löscht? Oder ist das durch einen Werksreset sichergestellt?

Ich hoffe, irgend jemand hat eine gute Idee...
Vielen Dank schonmal im Voraus!

VG linuzer

[Bennemannc]

Hallo,

normalerweise werden alle Register beim Werksreset gelöscht - also auch die pairing-Register. Hast Du die culfw mit der Timinganpassung drauf ?

Code Auswählen Erweitern

http://forum.fhem.de/index.php/topic,31421.0.html
könnte helfen.

Gruß Christoph

[linuzer]

Hallo Christoph,

vielen Dank für den Link, den hatte ich noch nicht gefunden. Auf das Stichwort "Timingprobleme" bin ich zwar schon gestoßen und habe deswegen bereits die neueste Firmware-Version von https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/ installiert. Enthält die auch diese Timinganpassungen?

Parallel habe ich jetzt versucht die von dir verlinkte Firmware zu installieren, habe es aber nicht geschafft, weil FHEM nur meldet

Code Auswählen Erweitern

CULflash CUL_0 CUL_V3
dfu-programmer: no device present.
Habe ich was übersehen?

Auf der letzten Seite in dem von dir verlinkten Thread warnt Ansgar:

Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM Modulen auf einem Stand von Ende 2014

Das klingt nicht sehr vertrauenserweckend... Funktioniert diese Version mit neuestem FHEM (5.7)?

Gruß, linuzer

[Bennemannc]

Hallo,

ich habe keinen CUL, und habe den Beitrag nur durch suchen gefunden. Da in der culfw eigentlich nur das Timingverhalten des CUL im Bezug auf HM Komponente verbessert wurde, sollte das zu der aktuellen Fhem Software passen.
Homematic arbeitet ja mit einer Antwort, und die muss in einem bestimmten Zeitfenster gesendet werden, sonst wiederholt der Sender seine Message. Klappt das 3 mal nicht, wird aufgegeben.
Ich habe letztens mit nanoCUL rungespielt. Die werden über avrdude geflasht - dabei darf fhem nicht laufen. Wie das aus fhem geht - wie gesagt ich habe keinen CUL.

Gruß Christoph

[linuzer]

Ich glaube, ich habe die Firmware jetzt aufgespielt. Mein CUL zeigt das Reading

Code Auswählen Erweitern

VERSION    V 99.78 CUL868
Ist das die richtige Version?

Auf jeden Fall habe ich damit jetzt erneut einen Werksreset meines Schalters gemacht, kann aber keinen Unterschied feststellen. Der Schalter zeigt bei einem GetConfig ziemlich lange "Commands pending" an, welches nach mehrmaligem betätigen des Schalters, sowie Refresh der Anzeigeseite dann in ein

Code Auswählen Erweitern

state   RESPONSE TIMEOUT:RegisterRead wechselt 

Gruß linuzer

[Bennemannc]

Hallo,

wenn das pairing nicht sauber ist, funktioniert auch getConfig nicht richtig.

Gruß Christoph

[linuzer]

Hallo Christoph,

ja, das verstehe ich ... Aber was kann ich tun, um das Problem zu ergründen und zu lösen?

Gruß, linuzer

[ph1959de]

Kannst Du irgendwie testen / verifizieren, dass das Gerät überhaupt etwas empfängt?

Ich weiß nicht, was bei dem Bausatz alles zu löten war, kann nur von einem Fall bei mir berichten, wo ich das Funkmodul unsauber eingelötet hatte. Die Effekte waren ähnlich: das Gerät konnte offensichtlich senden (wurde also in Fhem "erkannt"), hat aber wohl nie etwas empfangen (also auch nicht die Pairing / getConfig von der Zentrale / Fhem).

Gruß, Peter

[linuzer]

Guter Gedanke! Also der Schalter hat ja nur eine LED. Beim Pairen blinkt diese auch einige Sekunden schnell gelb und am Ende grün. Laut Doku bedeutet "schnelles oranges Blinken" = "Anlernmodus Daten werden empfangen". Des weiteren "nach erfolgreicher Funkübertragung leuchtet die LED für 1 s grün"
Bedeutet das jetzt aber, dass der Schalter alles erfolgreich gesendet hat, oder heißt das, dass er auch etwas empfangen hat? Da bin ich leider überfragt...

[frank]

sniffe die messages, wie im wiki homematic sniffen beschrieben.

[linuzer]

OK, habe ich gemacht. Hier die Messages von einem einfachen Schaltvorgang:

Code Auswählen Erweitern

2016.03.01 13:43:44.003 4: CUL_Parse: CUL_0  304130 A FF01 07080712 00 0B 02 A240 3BB650 F11134 0101 -68.5
2016.03.01 13:43:44.126 5: CUL_HM HM_3BB650 prep ACK for 01
2016.03.01 13:43:44.128 4: CUL_send:  CUL_0                       Aa 816E 0A 02 8002 F11134 3BB650 00
2016.03.01 13:43:44.139 3: CUL_send:  CUL_0  id:3BB650 dDly:-21
2016.03.01 13:43:44.140 5: CUL_HM HM_3BB650 protEvent:CMDs_done
2016.03.01 13:43:44.141 5: CUL_HM HM_3BB650 sent ACK:2
2016.03.01 13:43:44.184 3: CUL_ParseTsHM: CUL_0  id:3BB650 dhmSt:128
2016.03.01 13:43:44.184 4: CUL_Parse: CUL_0  304311 A FF13 07080840 00 0A 02 8002 F11134 3BB650 00 -138
2016.03.01 13:43:44.990 4: CUL_send:  CUL_0                            Ap C3     
2016.03.01 13:43:45.005 4: CUL_Parse: CUL_0  305131 A FF12 07081704 00 01 C3 -138


und hier vom Pairing-Vorgang:

Code Auswählen Erweitern

2016.03.01 13:48:07.104 4: CUL_Parse: CUL_0  042943 A FF01 07343824 00 1A 01 8400 3BB650 000000 1100BF4D45513032373938343540020000 -45.5
2016.03.01 13:48:07.110 3: CUL_HM pair: HM_3BB650 pushButton, model HM-PB-2-FM serialNr MEQ0279845
2016.03.01 13:48:07.116 5: CUL_HM HM_3BB650 protEvent:CMDs_pending pending:1
2016.03.01 13:48:07.118 5: CUL_HM HM_3BB650 protEvent:CMDs_pending pending:2
2016.03.01 13:48:07.118 5: CUL_HM HM_3BB650 protEvent:CMDs_pending pending:3
2016.03.01 13:48:07.122 4: CUL_send:  CUL_0                       Aa 01E7 10 02 A001 F11134 3BB650 00050000000000
2016.03.01 13:48:07.133 3: CUL_send:  CUL_0  id:3BB650 dDly:84
2016.03.01 13:48:07.136 5: CUL_HM HM_3BB650 protEvent:CMDs_processing... pending:2
2016.03.01 13:48:07.236 3: CUL_ParseTsHM: CUL_0  id:3BB650 dhmSt:104
2016.03.01 13:48:07.236 4: CUL_Parse: CUL_0  043075 A FF13 07343928 00 10 02 A001 F11134 3BB650 00050000000000 -138
2016.03.01 13:48:07.363 4: CUL_Parse: CUL_0  043203 A FF11 07344072 00 0A 02 8002 3BB650 F11134 00 -47.5
2016.03.01 13:48:07.370 4: CUL_send:  CUL_0                         Aw 0B 13 03 A001 F11134 3BB650 000802010AF10B110C34
2016.03.01 13:48:07.381 3: CUL_send:  CUL_0  id:3BB650 dDly:84
2016.03.01 13:48:07.383 5: CUL_HM HM_3BB650 protEvent:CMDs_processing... pending:1
2016.03.01 13:48:07.494 3: CUL_ParseTsHM: CUL_0  id:3BB650 dhmSt:112 hmSioDly:2
2016.03.01 13:48:07.495 4: CUL_Parse: CUL_0  043333 A FF13 07344184 00 13 03 A001 F11134 3BB650 000802010AF10B110C34 -138
2016.03.01 13:48:07.611 4: CUL_Parse: CUL_0  043450 A FF11 07344328 00 0A 03 8002 3BB650 F11134 00 -48.5
2016.03.01 13:48:07.617 4: CUL_send:  CUL_0                         Aw 0C 0B 04 A001 F11134 3BB650 0006
2016.03.01 13:48:07.628 3: CUL_send:  CUL_0  id:3BB650 dDly:93
2016.03.01 13:48:07.630 5: CUL_HM HM_3BB650 protEvent:CMDs_processing... pending:0
2016.03.01 13:48:07.744 3: CUL_ParseTsHM: CUL_0  id:3BB650 dhmSt:112 hmSioDly:4
2016.03.01 13:48:07.745 4: CUL_Parse: CUL_0  043583 A FF13 07344440 00 0B 04 A001 F11134 3BB650 0006 -138
2016.03.01 13:48:07.880 4: CUL_Parse: CUL_0  043720 A FF11 07344600 00 0A 04 8002 3BB650 F11134 00 -48
2016.03.01 13:48:07.886 5: CUL_HM HM_3BB650 protEvent:CMDs_done
2016.03.01 13:48:09.633 4: CUL_send:  CUL_0                            As 0B 03 8670 200101 000000 00C4
2016.03.01 13:48:09.685 4: CUL_Parse: CUL_0  045524 A FF13 07346360 00 0B 03 8670 200101 000000 00C4 -138
2016.03.01 13:48:10.541 4: CUL_send:  CUL_0                            As 0B 03 8670 FF0101 000000 00DF
2016.03.01 13:48:10.594 4: CUL_Parse: CUL_0  046433 A FF13 07347264 00 0B 03 8670 FF0101 000000 00DF -138

Gruß, linuzer

[Bennemannc]

Hallo,

Code Auswählen Erweitern

2016.03.01 13:48:07.236 4: CUL_Parse: CUL_0  043075 A FF13 07343928 00 10 02 A001 F11134 3BB650 00050000000000 -138
2016.03.01 13:48:07.363 4: CUL_Parse: CUL_0  043203 A FF11 07344072 00 0A 02 8002 3BB650 F11134 00 -47.5
wenn ich das richtig lese sind das hinten die RSSI Werte. Der eine Empfängt mit -47.5 und der andere mit -138. Die -138 sind unterirdisch - das kann so nicht gut gehen.

Gruß Christoph

[frank]

also das pairing sieht doch erfolgreich aus. es wurde aber kein automatisches getconfig ausgelöst. mach ein manuelles getconfig im parent channel, damit sollte das "set_" dann verschwinden.

die -138 sind seltsam. das ist aber nicht der rssi vom schalter. der cul sendet ja.

[linuzer]

Hallo Frank,

sorry, da muss ich nochmal nachfragen:

mach ein manuelles getconfig im parent channel

Was meinst du mit "parent channel"?

VG linuzer

[franky08]

Vom device nicht von einem channel des devices.

VG
Frank