Verzweiflung beim Pairingversuch mit nanoCul und MAX!

phiomet · March 1, 2019, 10:05pm

Hallöchen,

folgende Ausgangssituation:

BC-RT-TRX-CyG-3 Max! Thermostat
NanoCUL mit a-culfw_1.26.05_build_312
Raspberry Pi 3 B+ mit Openhabian in der aktuellsten Version
Homegear 0.7.37-2722

Meine max.conf hat folgende Einträge:
## The device family this interface is for
[CUL]
## Specify an unique id here to identify this device in Homegear
id = My-MAX-CUL
## When default is set to “true” Homegear will assign this device
## to new peers.
default = true
## Options: cul, coc, cc1100
deviceType = cul
device = /dev/ttyUSB0
## Should be “40” for MAX!
responseDelay = 40

Auch mit /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 statt ttyUSB0 komme ich nicht weiter.

Wenn ich homegear auf pairing stelle und dies dann am Thermostat starte, kann er Signale vom Thermostat lesen, pairen scheint aber unmöglich:

[22:19:35] openhabian@openHABianPi:~$ cat /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
Z1700040018AA52FD0002001001A04F45513131333432303215
Z1700040018AA52FD0002001001A04F4551313133343230321F
Z1700040018AA52FD0002001001A04F45513131333432303223
Z1700040018AA52FD0002001001A04F45513131333432303223
Z1700040018AA52FD0002001001A04F45513131333432303224
Z1700040018AA52FD0002001001A04F45513131333432303223
Z0A000A0318AA52FD00020021
Z0B8B063019056A17C8D700101D

Ausgeführt habe ich:

[22:20:16] openhabian@openHABianPi:~$ sudo homegear -r
[sudo] Passwort für openhabian:
Connected to Homegear (version 0.7.37-2722).

Please type >>help<< to list all available commands.
> ls
   ID │ Name
──────┼───────────────────────────────
    1 │ HomeMatic Wired
    4 │ MAX!
  254 │ Miscellaneous
──────┴───────────────────────────────
> fs 4
For a list of available family commands type >>help<<.
Family 4> ls
No peers are paired to this central.
Family 4> pon
Pairing mode enabled.
Family 4> pof
Pairing mode disabled.
Family 4> ls
No peers are paired to this central.

Habe ich irgendwo einen grundlegenden Denkfehler? Das selbe passiert auch mit dem Fensterkontakt. Beide Geräte habe ich vorher komplett resettet (Batterie raus, 1 min warten, alle 3 Knöpfe drücken beim Einlegen der Batterien usw.)

Im Log sehe ich folgendes im Debuglevel 10:

03/01/19 23:03:29.001 RPC Server (Port 2001): Info: RPC server client id for client number 9 is: 0

03/01/19 23:03:29.002 RPC Server (Port 2001): Listening for incoming packets from client number 9.
03/01/19 23:03:29.003 RPC Server (Port 2001): Debug: Packet received: 474554202F6465736372697074696F6E2E786D6C20485454502F312E310D0A43616368652D436F6E74726F6C3A206E6F2D63616368650D0A436F6E6E656374696F6E3A204B6565702D416C6976650D0A507261676D613A206E6F2D63616368650D0A4163636570743A20746578742F786D6C2C206170706C69636174696F6E2F786D6C0D0A557365722D4167656E743A204644535344500D0A486F73743A203139322E3136382E312E363A323030310D0A0D0A
03/01/19 23:03:29.026 RPC Server (Port 2001): Debug: Connection to client number 9 closed.
03/01/19 23:03:29.033 RPC Server (Port 2001): Debug: Connection to client number 9 closed (1).

pmayer · March 2, 2019, 12:25am

Hmm… empfangen geht anscheinend schon mal. Senden scheint das Problem zu sein. Zeig mal bitte deinen nanoCUL (Foto).

phiomet · March 2, 2019, 2:33pm

Hier Fotos:

pmayer · March 2, 2019, 3:44pm

Hmm… wollte sicher gehen, dass es sich um ein 868er Modul handelt. Kannst du irgendwei verifizieren, dass der CUL tut was er soll? Vielleicht an einer anderen Installation testen?

phiomet · March 4, 2019, 7:07am

Ich probiere das Ganze dann mal an meinem Linux Rechner, ob Homegear da mit den Geräten mehr reden mag. Hoffentlich komme ich heut dazu.

phiomet · March 4, 2019, 7:18pm

So, ich habe es jetzt bei meiner Debianmaschine probiert. Selbes Problem. Er sieht das Thermostat, pairt aber nicht. :-/

pmayer · March 4, 2019, 8:17pm

Was sein kann ist, das die GDO-Leitung für das Funkmodul nicht korrekt eingestellt ist. Die wird benötigt um in den Sendebetrieb zu schalten.

Hast du den Selbstbau-CUL selbst geflasht und da evtl. eine falsche Einstellung vorgenommen?

Oder, das Funkmodul hat einfach einen Hau…

phiomet · March 4, 2019, 8:42pm

Ok, bei GDO steig ich aus. Da muss ich mich erst einlesen.

Das Modul habe ich selbst geflasht nach folgender Anleitung mit der a-culfw https://www.smarthome-agentur.de/blog/tutorial-die-nanocul-firmware-updaten/

pmayer · March 4, 2019, 8:55pm

Der CC1101 (dein Funkmodul) hat zwei GDO-Pins (GDO0 und GDO2). Einer davon sollte anhand deiner Adapterplatine mit dem Arduino Nano verbunden sein.

Die Frage ist also welcher von beiden und auf welchem Pin den Nano er landet. Das muss in der Firmware entsprechend hinterlegt sein.
Eventuell muss du die NanoCUL-Firmware dafür selbst kompilieren.

phiomet · March 5, 2019, 6:36pm

Als Ergänzung: hier hab ich den Stick her: (ich hoffe, ich darf den Link posten, sonst entferne ich natürlich sofort wieder) https://www.ebay.at/itm/nanoCUL-USB-Stick-FTDI-CC1101-868MHz-FW-1-67-Knick-Antenne-FHEM-CUL-868-Adapter/372221622516

Ich versuche nochmal die andere Firmware. Kann ich irgendwie sonst die Sendefunktion testen?

pmayer · March 5, 2019, 7:34pm

Woah, 38eu ist frech. Für ein CC1101-Modul was 2€ auf eBay kostet. Der Nano (also Klon) kostet auch nur 3€. Die Platine dazwischen bekommt man für 2€ bei oshpark… dann noch die Antenne dazu und ich komme auf max 12€, mit Gewinn 15-18€.
Von fehlender WEEE-Registrierung bei dem ebay-Händler will ich gar nicht sprechen…
Abgesehen davon ist das Platinenlayout wirklich wirklich gräuselich…

Vielleicht sollte ich sowas mal bauen, mit besseren - sprich - funktionierenden Modulen
Wenns dir nur um Homematic oder MAX! in Verbindung mit Homegear geht mag ich dir eins unserer Module empfehlen. Das ist nur der Funkchip mit Antenne, Homegear macht den kompletten Softwareteil: https://shop.codm.de/module/3/cc1101-raspberry-pi-spi-modul-v0.3
Ok, das war jetzt vielleicht etwas Werbung

Für das Geld hättest du fast einen busware-CUL kaufen können: http://shop.busware.de/product_info.php?products_id=29

phiomet · March 5, 2019, 8:04pm

Hmm, ok, die Kritik kann ich nachvollziehen.

Mir ist nur jetzt noch was anderes eingefallen, was ich getestet habe. Ich habe noch einen MAX! Cube rumliegen, hab den auf culfw geflasht und das Ganze damit nun auch getestet. Strange ist, dass ich am Rechner und am Pi das selbe Ergebnis habe, wie mit dem NanoCul. Mit einem Thermostat und einem Fenster Sensor.

Ich habe nun irgendwie Zweifel, dass es am Stick liegt.

Nur noch mal zum sicher gehen:

[20:44:51] openhabian@openHABianPi:~$ homegear -r
Connected to Homegear (version 0.7.37-2722).

Please type >>help<< to list all available commands.
> ls
   ID │ Name
──────┼───────────────────────────────
    1 │ HomeMatic Wired
    4 │ MAX!
  254 │ Miscellaneous
──────┴───────────────────────────────
> dl 10
Debug level set to 10.
> fs 4
For a list of available family commands type >>help<<.
Family 4> pon
Pairing mode enabled.
Family 4> pof
Pairing mode disabled.
Family 4> ls
No peers are paired to this central.
Family 4> pon
Pairing mode enabled.
Family 4> pof
Pairing mode disabled.
Family 4> ls
No peers are paired to this central.

Die Befehle passen so?

pmayer · March 5, 2019, 8:11pm

Ja, dl 5 sollte aber reichen.
Was sagt das Log (/var/log/homegear.log) während des Anlernvorgangs?

phiomet · March 6, 2019, 4:55am

Irgendwie sagt der viel zu wenig:

03/06/19 05:53:27.807 IPC Server: Info: Client number 1 is calling RPC method: cliFamilyCommand
(Integer64) 4
(String) pon
03/06/19 05:53:27.807 IPC Server: Debug: CLI client 1 is executing family command: pon
03/06/19 05:53:27.808 IPC Server: Response:
(String) Pairing mode enabled.

03/06/19 05:53:30.580 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:53:30.681 UPnP Server: Debug: Sending notify packets.
03/06/19 05:53:30.884 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:53:30.904 Debug: Sleeping 2942ms before sending response.
03/06/19 05:53:33.846 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:53:33.947 UPnP Server: Debug: Sending notify packets.
03/06/19 05:53:33.947 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:53:33.968 Debug: Sleeping 366ms before sending response.
03/06/19 05:53:34.334 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:53:34.434 UPnP Server: Debug: Sending notify packets.
03/06/19 05:53:36.207 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:53:36.227 Debug: Sleeping 1805ms before sending response.
03/06/19 05:53:38.032 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:53:38.133 UPnP Server: Debug: Sending notify packets.
03/06/19 05:53:46.207 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:53:46.227 Debug: Sleeping 3947ms before sending response.
03/06/19 05:53:50.175 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:53:50.275 UPnP Server: Debug: Sending notify packets.
03/06/19 05:53:56.207 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:53:56.227 Debug: Sleeping 1703ms before sending response.
03/06/19 05:53:57.931 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:53:58.031 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:06.208 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:06.229 Debug: Sleeping 1847ms before sending response.
03/06/19 05:54:08.076 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:54:08.199 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:16.208 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:16.228 Debug: Sleeping 659ms before sending response.
03/06/19 05:54:16.887 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:54:16.987 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:19.307 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:19.328 Debug: Sleeping 123ms before sending response.
03/06/19 05:54:19.707 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:54:19.807 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:19.808 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:19.828 Debug: Sleeping 198ms before sending response.
03/06/19 05:54:20.026 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:54:20.127 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:21.619 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:21.639 Debug: Sleeping 2948ms before sending response.
03/06/19 05:54:24.588 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:54:24.688 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:24.688 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:24.708 Debug: Sleeping 4182ms before sending response.
03/06/19 05:54:28.891 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900
03/06/19 05:54:28.991 UPnP Server: Debug: Sending notify packets.
03/06/19 05:54:28.991 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900
03/06/19 05:54:29.012 Debug: Sleeping 2446ms before sending response.

pmayer · March 6, 2019, 11:57am

Absolut.
Du hast den CUL auch in keiner anderen Config in Homegear aktiv? Zeig die max.conf zur Sicherheit noch mal.

AndrejDelany · March 6, 2019, 3:48pm

Ich habe einen sehr ähnlichen (den gleichen?) Stick im Einsatz, den ich hier gekauft habe:
https://www.ebay.de/itm/372221622516

Ich nutze den allerdings für HomeMatic BidCos und nicht für MAX!. Vllt. hilft dir hier meine Config weiter:

[CUL]
id = My-CUL
default = true
deviceType = cul
device = /dev/ttyUSB0
responseDelay = 95

Bei mir läuft das Ding mit der Firmware, die drauf war, gut. Falls du die nochmal flashen willst, gibt es die direkt beim Anbieter:
https://www.smart-home-komponente.de/support/firmware/

phiomet · March 6, 2019, 5:28pm

Hier nun mal mein komplettes max.conf file:

[18:25:16] openhabian@openHABianPi:~$ cat /etc/homegear/families/max.conf
___________________________________________________________________________

---------------------------------- MAX!  ----------------------------------
___________________________________________________________________________

#######################################
########## General Settings  ##########
#######################################

[General]

moduleEnabled = true

## The MAX! address of Homegear. It is recommended to change this to a random 3 byte hexadecimal
## value starting with 0xFD (e. g. 0xFD43AB). Only change this, when no MAX! devices
## are paired to Homegear as existing pairings will not work anymore!
centralAddress = 0xFD0002

#######################################
################# CUL #################
#######################################

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

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

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

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

device = /dev/ttyUSB0

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

#######################################
########## TI CC1101 Module  ##########
#######################################

## The device family this interface is for
#[TI CC1101 Module]

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

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

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

#device = /dev/spidev0.0

## Default: responseDelay = 95
## Should be "40" for CUL or COC and "45" for TI CC1101.
#responseDelay = 45

## The interrupt pin to use. "0" for GDO0 or "2" for GDO2.
## You only need to connect one of them. Specify the GPIO
## you connected the interrupt pin to below.
#interruptPin = 2

## The GPIO GDO0 or GDO2 is connected to. Specify which GDO to use above.
#gpio1 = 23

### Additional TI CC1190 Config ###

## The GPIO high gain mode of the CC1190 is connected to.
## Default: -1 (disabled)
#gpio2 = 5

## The hexadecimal value for the PATABLE of the TI CC1101.
## Default:
## - Without high gain mode: 0xC2
## - With high gain mode: 0x27 (maximum legally allowed setting)
#txPowerSetting = 0x27


#######################################
################ CUNX  ################
#######################################

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

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

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

## Options: cul, cc1100, coc, cunx, hmcfglan, hmlgw
#deviceType = cunx

## IP address of your CUNX
#host = 192.168.178.100

## Port number your CUNX listens on. Normally 2323.
#port = 2323

## Default: responseDelay = 95
## Should be "40" for CUNX
#responseDelay = 40


#######################################
######### COC, SCC, CSM, CCD  #########
#######################################

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

phiomet · March 9, 2019, 12:44pm

Ahja, ich habe alle anderen Module entfernt. Max ist das Einzige. Damit sich nix in die Quere kommen kann.

pmayer · March 9, 2019, 2:53pm

Auf Konfigurationsseite sieht für mich alles gut aus. Bleibt mir leider nichts übrig als auf entweder ein kaputtes Max!-Gerät oder die Firmware des CUL zu tippen.

phiomet · March 11, 2019, 4:49am

2 kaputte Max! Geräte. Daher scheint mir das so unwahrscheinlich. Ich flashe beide noch mal um und probiere weiter. Das ist echt frustrierend.

Wenn das nix hilft, werde ich mir noch einen Kauf des hier erwähnten Pi Moduls überlegen.