nanoCUL + Max

[martinehmke]

Hallo,

ich habe mir ein nanoCUL selbstgebaut und wie auf entsprechenden Seiten beschrieben getestet, d.h. ich kann mich mit screen/picocom connecten und über V die Version und Zr Pakete empfangen.
Version: 1.63 nanoCUL868

Ich kriege es jedoch weder mit dem maxcul-Binding von openhab noch direkt mit homegear zum Laufen. In homegear habe ich in physicaldevices die entsprechenden Zeilen einkommentiert und er sagt auch beim Starten:

Module MAX: Debug: Creating physical device. Type defined in physicalinterfaces.conf is: cul

Wenn ich über fs 4, ds c, pon versuche anzulernen, passiert nix. Er schreibt auch gar keine Pakete in die Konsole, obwohl ich den Debuglevel heraufgesetzt habe.

Kann mir jemand bitte helfen?
Martin

[sathya]

Hallo Martin,

der nanoCUL sollte natürlich funktionieren. Poste mal den Abschnitt aus der physicalinterfaces.conf und deine homegear.log vom Start bis zum Zeitpunkt, bis zumindest ein Paket empfangen sein sollte.

Liebe Grüße

Sathya

[martinehmke]

Hallo,

danke für die schnelle Antwort. Ich hatte auch schon an die Baudrate gedacht, aber wie ich sehen konnte sind die 38400 wohl korrekt.

03/29/15 22:02:21.957 Module MAX: Debug: Loading module…
03/29/15 22:02:21.976 Debug: Reading config for physical device family MAX!
03/29/15 22:02:21.976 Debug: id of family MAX! set to My-MAX-CUL
03/29/15 22:02:21.976 Debug: default of family MAX! set to 1
03/29/15 22:02:21.976 Debug: deviceType of family MAX! set to cul
03/29/15 22:02:21.976 Debug: device of family MAX! set to /dev/cul
03/29/15 22:02:21.977 Debug: responseDelay of family MAX! set to 40
03/29/15 22:02:21.977 Module MAX: Debug: Creating physical device. Type defined in physicalinterfaces.conf is: cul
03/29/15 22:02:21.977 Initializing database…
03/29/15 22:02:21.981 Initializing family controller…
03/29/15 22:02:21.981 Info: Not initializing device family HomeMatic BidCoS, because no physical interface was found.
03/29/15 22:02:21.981 Info: Not initializing device family HomeMatic Wired, because no physical interface was found.
03/29/15 22:02:21.981 Info: Not initializing device family INSTEON, because no physical interface was found.
03/29/15 22:02:21.981 Module MAX: Loading XML RPC devices…
03/29/15 22:02:21.981 Loading XML RPC device /etc/homegear/devices/4/BC-PB-2-WM.xml
03/29/15 22:02:21.982 Loading XML RPC device /etc/homegear/devices/4/BC-RT-TRX-CyG.xml
03/29/15 22:02:21.994 Loading XML RPC device /etc/homegear/devices/4/BC-TS-Sw-Pl.xml
03/29/15 22:02:22.003 Loading XML RPC device /etc/homegear/devices/4/BC-RT-TRX-CyG-3.xml
03/29/15 22:02:22.015 Loading XML RPC device /etc/homegear/devices/4/BC-TC-C-WM-2.xml
03/29/15 22:02:22.026 Loading XML RPC device /etc/homegear/devices/4/BC-TC-C-WM-4.xml
03/29/15 22:02:22.038 Loading XML RPC device /etc/homegear/devices/4/BC-SC-Rd-WM-2.xml
03/29/15 22:02:22.039 Loading XML RPC device /etc/homegear/devices/4/BC-RT-TRX-CyG-2.xml
03/29/15 22:02:22.047 Loading XML RPC device /etc/homegear/devices/4/BC-SC-Rd-WM.xml
03/29/15 22:02:22.047 Info: Not initializing device family Philips hue, because no physical interface was found.
03/29/15 22:02:22.048 Module Miscellaneous: Loading XML RPC devices…
03/29/15 22:02:22.048 Loading XML RPC device /etc/homegear/devices/254/Template.xml
03/29/15 22:02:22.049 Loading devices…
03/29/15 22:02:22.049 Module MAX: Loading device 4
03/29/15 22:02:22.050 Module MAX: Loading device 5
03/29/15 22:02:22.051 Module Miscellaneous: Loading Miscellaneous device 3
03/29/15 22:02:22.052 Start listening for packets…
03/29/15 22:02:22.473 Debug: Thread priority successfully set to: 45
03/29/15 22:02:22.473 Debug: Thread priority successfully set to: 45
03/29/15 22:02:22.473 Initializing RPC client…
03/29/15 22:02:22.473 Starting XML RPC server RPCServer1 listening on 0.0.0.0:2001…
03/29/15 22:02:22.474 Starting XML RPC server RPCServer2 listening on 0.0.0.0:2002, SSL enabled…
03/29/15 22:02:22.475 RPC Server (Port 2001): Info: RPC Server started listening on address 0.0.0.0 and port 2001
03/29/15 22:02:22.483 Starting XML RPC server RPCServer3 listening on 0.0.0.0:2003, SSL enabled, authentification enabled…
03/29/15 22:02:22.483 RPC Server (Port 2002): Info: RPC Server started listening on address 0.0.0.0 and port 2002
03/29/15 22:02:22.490 Starting CLI server…
03/29/15 22:02:22.490 RPC Server (Port 2003): Info: RPC Server started listening on address 0.0.0.0 and port 2003
03/29/15 22:02:22.491 Initializing event handler…
03/29/15 22:02:22.492 Loading events…
03/29/15 22:02:22.493 Startup complete.
03/29/15 22:02:22.493 All physical interfaces are connected now.

und

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

The device family this interface is for

[MAX]

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/cul

Should be “40” for MAX!

responseDelay = 40

Der Rest ist auskommentiert…

Danke

[sathya]

Das sieht soweit gut aus. Wenn kein anderes Gerät auf den CUL zugreift, gibt es eigentlich keinen Grund, warum die Pakete in screen sichtbar sind und in Homegear nicht. Das Gerät “/dev/cul” hast du auch in screen angegeben, nehme ich an? Da der CDC/ACM-Treiber verwendet wird, ist das Standardgerät ja “/dev/ttyACM0”. Die Baudrate ist relativ egal und die bestimmst du. Was für ein Paket sollte in dem geposteten Log sichtbar sein?

[martinehmke]

Ich /dev/cul natürlich in screen angeben. Allerdings zeigt der Link nicht auf /dev/ttyACM0…

automation@tv:~$ ls -la /dev/cul
lrwxrwxrwx 1 root root 7 Mär 29 20:04 /dev/cul -> ttyUSB0

Also im Screen kann ich die Anlernpakete sehen, wenn ich einen nicht angelernten Thermostat in den Anlernmodus setze. Ich kann auch irgendwelche anderen Nachrichten sehen, wenn ich beispielsweise die Temperatur an einem Wandthermostat verstelle.

Würde homegear entsprechende Log-Nachrichten schicken, wenn was empfangen wird?

[sathya]

Würde homegear entsprechende Log-Nachrichten schicken, wenn was empfangen wird?

Ja.

Probier mal, das Gerät direkt als “/dev/ttyUSB0” anzugeben, ändert das was?

LG Sathya

[martinehmke]

Das hat nix geändert.

[sathya]

ok. Lass es mal erst einmal auf “/dev/ttyUSB0”.

Starte mal Homegear und führe danach auf der Konsole aus:

echo "Zr" > /dev/ttyUSB0

Damit aktivierst du unabhängig von Homegear noch einmal den Empfang von MAX!-Paketen. Dann sende ein Paket und schau ob es im Log von Homegear auftaucht (screen etc. darf nicht laufen).

Falls nicht, führ auf der Konsole aus:

cat /dev/ttyUSB0

Sende wieder ein Paket und schau, ob es ausgegeben wird.

Wie sind die Berechtigungen auf “/dev/ttyUSB0”? Da es aber keine Fehlermeldung gibt, gehe ich nicht davon aus, dass irgendwelche Berechtigungsprobleme da sind.

Liebe Grüße

Sathya

[martinehmke]

Also mit Echo hat es nicht funktioniert. Ich konnte jedoch anlernen, wenn ich parallel nochmal ein picocom aufgemacht habe. Woran könnte es liegen, dass mein Stick nicht richtig funktioniert?

[sathya]

Hallo Martin,

ich habe mir gerade mal den nanoCUL-Quelltext angeschaut. Die Baudrate ist tatsächlich fix (das ist beim CUL nicht Fall). Das erklärt natürlich das Nicht-Funktionieren. Installier mal Homegear 0.6 von der Download-Seite, dann sollte die Baudrate stimmen. Hoffentlich klappt’s damit…

Liebe Grüße

Sathya

[martinehmke]

Hi,

habe ich ausprobiert, aber ändert nichts. Was sollte das Update ändern? Im Quelltext vom nanoCUL wird die Schnittstelle mit 38400 initialisiert. Das ist auch der Parameter, den ich noch bei picocom setzen muss, um korrekte Antworten zurückzubekommen.

Also was ich mache:

• homegear starten (ich sehe keine Pakete)
• picocom -b 38400 /dev/cul
• Zr (2. LED aufm nanoCUL fängt an zu leuchten und Pakete können durch homegear empfangen werden).
• Nach Beenden von picocom funktioniert alles weiterhin.

[sathya]

Hey,

Was sollte das Update ändern?

vor Version 0.6 hat Homegear mit 9600 Baud mit dem CUL kommuniziert. Ab Version 0.6 ist der Standard 38400 Baud. Ich schau mir das noch einmal an. Es scheint offenbar noch einen Unterschied in den seriellen Einstellungen zu geben. Ich habe mir jetzt mal ein Arduino-nano-kompatibles Modul bestellt. In ein paar Tagen kann ich dir vermutlich also sagen, wo das Problem liegt .

Ich melde mich.

Liebe Grüße

Sathya

[martinehmke]

Cool, danke.

[sathya]

Problem gelöst . Es war für den nanoCUL nur eine kleine Pause nach dem Setzen der seriellen Parameter nötig. Im ab jetzt nächsten Nightly (für den Raspberry Pi 0.6.0-103) ist die Änderung drin! Bin gespannt auf deine Rückmeldung .

Liebe Grüße

Sathya

[martinehmke]

Uh, ich nutze Ubuntu. Kannst Du dafür bitte auch einfach nochmal einen Nightly-Build erstellen? Danke

[sathya]

Hey,

die Nightlies erstellen sich automatisch . Ubuntu 14.04 sollte morgen Abend durch sein.

LG Sathya

[dukechaos]

Hallo,

der Thread ist zwar schon etwas älter, aber da die 0.5er-Version noch aktuell ist, wollte ich meine Lösung hier zum Besten geben, falls jemand anders drüberstoplern sollte.

Ich selbst hab zwar kein MAX und auch nicht direkt einen nanoCul, aber das Problem ist/war das selbe - ich konnte nicht pairen, obwohl ich die Signale über minicom gesehen hab.
Mein Setup ist mit Homematic und einer selbstgebauten Raspberry-Pi-Addon-Platine auf Arduino Pro Mini Basis.

Meine Lösung, um das Ganze mit der 0.5er Homegear-Version zum Laufen zu kriegen war einfach die Baud-Rate für die culfw runterzusetzen, neu zu kompilieren und zu flashen.
Hierzu die culfw runterladen (fhemwiki.de/wiki/Selbstbau_CUL#Software) entpacken und dann folgendes tun:

1. Ins nanoCul-Verzeichnis wechseln.

2. In der Datei board.h den Parameter UART_BAUD_RATE von 38400 auf 9600 setzen.

[quote]/#define UART_BAUD_RATE 38400/
#define UART_BAUD_RATE 9600[/quote]
3. Kompilieren:

4. Flashen

Letzteres funktioniert nur, wenn der nanoCul als einziger per USB angeschlossen ist. Ggf. muss hier der avrdude-Befehl selbst angepasst werden.

Viele Grüße,

Flo

Edit: LInk zur culfw angepasst.

[xibir]

Nabend!

Sitze hier grade vor demselben Problem…

Beim Upgrade auf die 0.6.0 konnte ich Homegear nicht mehr starten mit der Meldung “Interrupted System Call”

DIe Baudrate auf 9600 zu stellen hat leider auch keine Besserung gebracht.
PS.: In der culfw Version die auf der Homegear Seite beschrieben ist gibt es keinen Ordner “nanoCUL”

Ich bin mir auch nicht 100%ig sicher welcher Teil der /etc/homegear/physicalinterfaces.conf der richtige für eine nanoCUL ist.

Laut Minicom bekomme ich die beim Drücken auf die Anlernfunktion des Heizungsthermostaten die meldung “rf”. Aber das Anlernen will nicht.

Bin für jeden Tipp dankbar

[magcode]

Hi,

nicht sicher ob ich helfen kann. Aber ich habe einen NanoCul und die 0.6 für MAX zum Laufen gebracht…

culfw Version die auf der Homegear Seite beschrieben ist gibt es keinen Ordner “nanoCUL”

Ich bin danach vorgegangen: blog.gummibaer-tech.de/cul-stick … selbstbau/

welcher Teil der /etc/homegear/physicalinterfaces.conf der richtige für eine nanoCUL ist.

Die Datei ist m.W. nicht mehr aktuell.
Du musst die Änderung in “/etc/homegear/families/max.conf” machen

root@xxx-VirtualBox:/home/xxx# cat /etc/homegear/families/max.conf
___________________________________________________________________________

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

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

Baudrate

Da habe ich nichts geändert.

[xibir]

Ok habe es nochmal mit der 0.6.0 versucht und habe tatsächlich ein Pairing zustande bekommen!

Doch nach weiteren Versuchen homegear mit Openhab kommunizieren zu lassen tritt beim Starten von Homegear plötzlich folgender Fehler auf:

[quote]12/13/15 14:45:19.670 Module HomeMatic BidCoS: CUL “My-CUL”: Couldn’t open CUL device “/dev/ttyUSB0”: Interrupted system call
12/13/15 14:45:19.670 Critical: At least one of the physical devices could not be opened… Exiting…[/quote]

Ich glaibe es hat etwas mit der Config zu tun, denn wenn ich alles wieder auskommentiere startet Homegear zumindest wieder…
Meine /etc/homegear/families/homematicbidcos.conf:

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

The device family this interface is for

[CUL]

Specify an unique id here to identify this device in Homegear

id = My-CUL

When default is set to “true” Homegear will assign this device

to new peers.

default = true

Options: cul, cc1100, coc, cuno, hmcfglan, hmlgw

deviceType = cul

device = /dev/ttyUSB0

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