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?
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?
Ja.
Probier mal, das Gerät direkt als “/dev/ttyUSB0” anzugeben, ändert das was?
LG Sathya
Das hat nix geändert.
ok. Lass es mal erst einmal auf “/dev/ttyUSB0”.
Starte mal Homegear und führe danach auf der Konsole aus:
echo "Zr" > /dev/ttyUSB0Damit 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/ttyUSB0Sende 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
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?
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
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.
Hey,
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
Cool, danke.
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
Uh, ich nutze Ubuntu. Kannst Du dafür bitte auch einfach nochmal einen Nightly-Build erstellen? Danke
Hey,
die Nightlies erstellen sich automatisch 
. Ubuntu 14.04 sollte morgen Abend durch sein.
LG Sathya
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:
- Ins nanoCul-Verzeichnis wechseln.
- 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:
- 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.
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 
Hi,
nicht sicher ob ich helfen kann. Aber ich habe einen NanoCul und die 0.6 für MAX zum Laufen gebracht…
Ich bin danach vorgegangen: blog.gummibaer-tech.de/cul-stick … selbstbau/
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
Da habe ich nichts geändert.
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:
Ok nach einem Neustart hat das Pairing nach neuer Installation wieder geklappt.
Jetzt kommt die Verbindung zu Openhab…
Openhab meldet:
oder aber
In der openhab.cfg steht:
Hier vielleicht eine Idee?
Mit der Option “homematic:callback.port=2001” ist nicht der Port von Homegear gemeint, sondern ein Port von OpenHAB , der von Homegear genutzt wird, um OpenHAB Ereignisse mitzuteilen (korrigiert mich, wenn ich falsch lieg ).
Der von dir angegebene Port 2001 ist allerdings schon von Homegear belegt.
Kommentier mal die beiden Optionen "homematic:callback.host " und “homematic:callback.port” wieder aus und versuchs nochmal.
Macht nicht nur Sinn sondern funktioniert auch 
Habs schon fast aufgegeben ^^
Jetzt würde ich im letzten Schritt gerne den Thermostaten per Slider oder Setpoint anpassen können.
Bekomme aber immer nur Exceptions…
Ist das überhaupt möglich?