Pairing mit BC-SC-Rd-WM-2-KH MAX! Fensterkontakt klappt nicht

Deutsche Foren Geräte
#1

Homegear scheint den MAX! Fensterkontakt BC-SC-Rd-WM-2-KH nicht zu erkennen.

Meine Vorgehensweise:

$ sudo homegear -r
#  HomeMatic BidCoS wählen
families select 0 
pairing on
# Fensterkontakt in Pairing Mode setzen

Die Device Support List führt den BC-SC-Rd-WM-2 auf.
Mein Modell führt noch die Suffix -KH. Ich gehe davon aus, dass die Suffix für den Herstellernamen Komforthaus steht.
Kann es sein, dass es Unterschiede zwischen den Versionen gibt?
Das Pairing zwischen SCC dem Homematic Fensterkontakt hat ohne Probleme funktioniert.
Als homegear-Neuling bin ich gerade etwas unsicher wie ich das Problem debuggen kann. Die logs in /var/log/homegear/ zeigen leider auch nichts von Wert.

Deshalb ein paar Fragen zum Verständnis:

  • Wie kann ich den Loglevel bei homegear auf debug setzen? Was ist der Standard Loglevel?
  • Was ist der Unterschied zwischen families und modules?
    Verstehe ich es richtig das Module erst geladen werden, wenn ein entsprechendes Gerät gepaired wurde?

$ sudo homegear -r
> modules list
ID    Family Name                   Filename                      Compiled For  Loaded
0     HomeMatic BidCoS              mod_homematicbidcos.so        0.6.13-864    true
...
...
...
4     MAX!                          mod_max.so                    0.6.13-864    false

Das MAX! module scheint nicht geladen zu werden. Liegt es also daran, dass ich das MAX! device nicht pairen konnte?

Danke schon einmal für Eure Hilfe!

#2

Sers,

das Loglevel setzt du in der main.conf. Zeig auch mal deine /etc/homegear/families/max.conf.

so long,
p

#3

Hey @pmayer,

danke für deine Antwort.
Gut dass du nach der max.conf fragst. Da ich ein SCC habe, bin ich unsicher in welcher Sektion ich das Teil konfigurieren muss, i.e. bei [CUL] oder bei [TI CC1101 Module].

Des Weiteren bin ich mir unklar über den korrekten responseDelay, muss das der gleiche sein wie bei Homematic? Oder hängt das davon ab, ob man ein SCC, COC oder CUL hat?

Was ist mit der id? Sollte ich zwischen Protokollen unterscheiden, auch wenn die gleiche Hardware angesprochen wird? I.e. id = SCC-MAX und id = SCC-HM?

Meine edits in der max.conf:

## The device family this interface is for
#[CUL]

## Specify an unique id here to identify this device in Homegear
id = SCC

## When default is set to "true" Homegear will assign this device
## to new peers.
#default = true

## Options: cul, coc, cc1100
deviceType = coc

device = /dev/ttyACM0
# Should be "40" for MAX!
responseDelay = 40

## Default: gpio1 = 0
## "17" for COC, SCC and CCD. Empty for CSM.
gpio1 = 17

## Default: gpio2 = 0
## "18" for COC and SCC. "22" for CCD. Empty for CSM.                                                                                                                             gpio2 = 18

und hier meine Settings in der homematicbidcos.conf

## The device family this interface is for
[COC, SCC, CSM, CCD]

## Specify an unique id here to identify this device in Homegear
id = SCC

## When default is set to "true" Homegear will assign this device
## to new peers.
default = true

## Options: cul, cc1100, coc, cunx, hmcfglan, hmlgw, hm-mod-rpi-pcb
## Also use "coc" for SCC, CCD and CSM
deviceType = coc

device = /dev/ttyAMA0


## Default: responseDelay = 95
## Should be "95" for CUL or COC, "100" for TI CC1101 and "60" for HM-CFG-LAN or HM-LGW
responseDelay = 95

## Default: gpio1 = 0
## "17" for COC, SCC and CCD. Empty for CSM.
gpio1 = 17

## Default: gpio2 = 0
## "18" for COC and SCC. "22" for CCD. Empty for CSM.
gpio2 = 18

## Default: stackPosition = 0 (= no stacking)
## Set stackPosition if you use the SCC and stacked multiple devices.
## Set stackPosition to "1" for the lowest device, to "2" for the device
## above that and so on.
# stackPosition = 0

Im Log bekomme ich Folgendes, wenn ich :

01/29/17 14:41:09.294 Module MAX: COC "SCC": Error in file PhysicalInterfaces/COC.cpp line 178 in function virtual void MAX::COC::startListening(): Couldn't open device "/dev/ttyACM0": No such file or directory
#4

Das kann ich dir leider nicht sagen, da ich nur ein CC1101 habe und den SCC nicht kenne. responseDelay ist meines Wissens nach abhängig von dem verwendeten Device (CUL, CC, etc.).

Soweit ich weiß, kann ein Gerät immer nur mit einem CUL/CC gepaired werden. Die Kommunikationsmodule müssen alle eine eindeutige ID haben.

Aber, du hast einen Fehler in deiner max.conf, du must die entsprechende Sektion auch einkommentieren, nicht nur die Eigenschaften…

wird [CUL]

So long,
p

#5

Ok. Auch nach dem Auskommentieren der obigen Zeile geht es nicht.
Zumindest bekomme ich keine Fehlermeldungen mehr im Log.

Ich bin mir gerade unklar darüber, ob ein SCC mehrere Protokolle gleichzeitig kann, i.e. Homematic und MAX!. Oder ob ich für jedes Protokoll ein eigenes SCC, COC benötigen werde.
Ich meine irgendwo gelesen zu haben (ich glaube im FHEM-Forum, finde es leider nicht mehr) dass die CULs zwischen den Protokollen springen können. Vielleicht habe ich damals aber auch etwas falsch verstanden.

Meinst du das damit @pmayer?

Soweit ich weiß, kann ein Gerät immer nur mit einem CUL/CC gepaired werden. Die Kommunikationsmodule müssen alle eine eindeutige ID haben.

@sathya hast du ggfs. noch eine Idee was ich machen könnte?
Danke nochmal für Eure Hilfe.

#6

Ein Gerät kann immer nur auf eine Frequenz und ein Protokoll “hören”.

Du kannst natürlich auf einem anderen Protokoll der selben Frequenz senden, nur verlierst du dann die Möglichkeit des Empfangs des Bestätigungstelegramms für das zweite Protokoll.
Ein Sensor/Aktor kann immer nur mit einer baseId gepaired werden - es muss ja teilweise auch mit einem Handshake authentifiziert werden. Der Funkchip präsentiert diese baseId.

Die CC1101 können sogar 433MHz und 868MHz… allerdings benötigen Sie dafür eine andere Antennenkonfiguration. Damit entfällt das auch.

Grundliegend Empfehlung: Pro Protokoll ein dediziertes Sende-/Empfangsgerät. Du kannst in homegear nicht das selbe Kommunikationsgerät für mehrere Protokolle nutzen, da dafür exklusiver Zugriff benötigt wird.

Hast du mal nen Link zum SCC? Kenne den nicht…

#7

Hier die Config aus dem aktuellen Nightly (bisher fehlte der Eintrag für den COC):

## The device family this interface is for
#[COC, SCC, CSM, CCD]

## Specify an unique id here to identify this device in Homegear
#id = My-COC

## When default is set to "true" Homegear will assign this device
## to new peers.
#default = true

#deviceType = coc

#device = /dev/ttyAMA0

## Default: gpio1 = 0
## "17" for COC, SCC and CCD. Empty for CSM.
#gpio1 = 17

## Default: gpio2 = 0
## "18" for COC and SCC. "22" for CCD. Empty for CSM.
#gpio2 = 18

## Should be "40" for MAX!
#responseDelay = 40

## Default: stackPosition = 0 (= no stacking)
## Set stackPosition if you use the SCC and stacked multiple devices.
## Set stackPosition to "1" for the lowest device, to "2" for the device
## above that and so on.
# stackPosition = 0

Damit sollte es eigentlich klappen. Der Name der Sektion ist irrelevant. Korrekter responseDelay ist wichtig und muss 40 sein. Ein SCC für HomeMatic und ein separater SCC für MAX! sind korrekt.

Mit welchem Kommunikationsmodul das Gerät angelernt wird, ist egal. Hauptsache die Zentrale ist die gleiche. Nach dem Anlernen kann das Kommunikationsmodul aber auch problemlos gewechselt werden bzw. bei mehreren Kommunikationsmodulen sogar im laufenden Betrieb umgeschaltet werden.

Falls du einen Raspberry Pi 3 hast, ist es noch wichtig, den Haupt-UART frei zu machen. Sonst kann es nicht funktionieren. Siehe dazu die HomeMatic-BidCoS-Dokumentation auf https://doc.homegear.eu.

Ich hoffe, das hilft ;-).

Viele Grüße

Sathya

1 Like
#8

@pmayer der SCC bei busware.
Jetzt weiss ich endlich woran es liegt!
Ich werde dann noch mindestens zwei SCC kaufen müssen um alle Protokolle abzudecken.
Danke euch für die Hilfe.

1 Like
#9