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.
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.
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.
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?
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?
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.
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?
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…
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.
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 .
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 .
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:
Ins nanoCul-Verzeichnis wechseln.
In der Datei board.h den Parameter UART_BAUD_RATE von 38400 auf 9600 setzen.
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.
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
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:
.
. 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 
.
. Ubuntu 14.04 sollte morgen Abend durch sein.
