Kann unter OpenHAB auf einem Raspberry Pi mit Homematic/Homegeare und FS20 Binding gleichzeitig über einen CUL betrieben werden? Die kurze Antwort: Leider NEIN.
Und hier die lange Beschreibung mit Vorgehen.
Die Homematic Geräte laufen über Homegeare mit dem Homematic Binding über eine CUL an dem seriellen USB Port /dev/ttyACM0 erfolgreich.
Nun wollte ich auch noch ein FS20 Gerät, das KSE (Klingelsignal-Erkennung) darüber laufen lassen. Also das FS20 Binding installiert.
sudo apt-get install openhab-addon-binding-fs20 sudo apt-get install openhab-addon-io-cul
Dann in der openhab.cfg die Serielle Schnittstelle des CULs angeben
fs20:device=serial:/dev/ttyACM0 fs20:baudrate=38400 fs20:parity=0
Anlegen einer FS20.items Datei mit den beiden Schaltern.
Switch klingelSchalterKanal1 "Klingelsignal Kanal 1" {fs20="C04B00"}
Switch klingelSchalterKanal2 "Klingelsignal Kanal 2" {fs20="C04B00"}
Adresse für den Schalter ermitteln, durch Neustart von openHab im debug Modus und im log schauen. Das Log:
18:29:43.750 [DEBUG] [.b.fs20.internal.FS20Activator:34 ] - FS20 binding has been started. 18:29:44.981 [DEBUG] [.io.transport.cul.CULActivator:35 ] - CUL transport has been started. 18:29:44.729 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'klingelSchalterKanal1 (Type=SwitchItem, State=Uninitialized)' with 'FS20GenericBindingProvider' reader. 18:29:44.811 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'klingelSchalterKanal2 (Type=SwitchItem, State=Uninitialized)' with 'FS20GenericBindingProvider' reader. 18:29:44.981 [DEBUG] [.io.transport.cul.CULActivator:35 ] - CUL transport has been started. 18:29:49.465 [INFO ] [o.i.t.c.i.CULSerialHandlerImpl:124 ] - Update config, baudrate = 38400 18:29:52.604 [ERROR] [.o.b.fs20.internal.FS20Binding:81 ] - Can't open cul device org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:269) ~[na:na] at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:154) ~[na:na] at org.openhab.io.transport.cul.CULManager.createNewHandler(CULManager.java:170) ~[bundlefile:na] at org.openhab.io.transport.cul.CULManager.getOpenCULHandler(CULManager.java:89) ~[bundlefile:na] at org.openhab.binding.fs20.internal.FS20Binding.getCULHandler(FS20Binding.java:78) [bundlefile:na] at org.openhab.binding.fs20.internal.FS20Binding.updateDeviceSettings(FS20Binding.java:72) [bundlefile:na] at org.openhab.binding.fs20.internal.FS20Binding.updated(FS20Binding.java:200) [bundlefile:na] at org.eclipse.equinox.internal.cm.ManagedServiceTracker$1.run(ManagedServiceTracker.java:183) [org.eclipse.equinox.cm_1.0.400.v20120522-1841.jar:na] at org.eclipse.equinox.internal.cm.SerializedTaskQueue$1.run(SerializedTaskQueue.java:36) [org.eclipse.equinox.cm_1.0.400.v20120522-1841.jar:na] Caused by: gnu.io.NoSuchPortException: null at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273) ~[na:na] at org.openhab.io.transport.cul.internal.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:244) ~[na:na] ... 8 common frames omitted
Oh, da steht ja keine Adresse sondern eine NoSuchPortException. Also dann mal schauen wie die Rechte so sind:
$ less /etc/group | grep dialout # Ergebnis, ok openhab der User unter dem openHAB läuft ist nicht in der Gruppe dialout:x:20:pi,homegear # User openhab der dialout Gruppe hinzugefügt $ sudo usermod -aG dialout openhab # Kontrolle $ less /etc/group | grep dialout # Ergebnis, openhab ist nun auch in der Gruppe dialout:x:20:pi,homegear,openhab # Restart
Ok, der Fehler ist immer noch da. Dann mal über die Konsole mit screen zu dem CUL verbinden.
sudo screen sudo screen /dev/ttyACM0 # Eingabe von V und Enter V # Liefert die Version des CUL_V3 V 1.66 CUL868
Ok, das läuft schon mal.
Dann mal schauen ob das FS20 Gerät auch Daten senden kann, die der CUL empfängt.
Signale der FS20 KSE werden auch empfangen, die HEX Werte bedeuten
# Faaaabbccdd # a=Hauscode # b=Geräte Adresse # c=Kommando # d=Zeitstempel # z.B.: F0000000011 F000001000F F0000001116 F000001111A F000000000E F0000000004 F0000000004 F0000000005 F00000011F9 F00000011F8 F00000011FA F00000100F8 F00000100FB F0000011103 F000000001B F0000010015
Also kann der CUL die Daten des FS20 empfangen. Dann mal die Rechte für die Schnittstelle für alle erlauben und in die richtige Gruppe aufnehmen:
# so sieht es zuerste aus ls -alh /dev/ttyACM0 rw-rw---- 1 homegear homegear 166, 0 Apr 5 19:26 /dev/ttyACM0 # den User homegear in die dialout Gruppe aufnehmen sudo usermod -aG dialout homegear # checken, ok less /etc/group | grep dialout # Ergebnis # dialout:x:20:pi,homegear,openhab # alle Rechte geben sudo chgrp dialout /dev/ttyACM0 crwxrwxrwx 1 homegear dialout 166, 0 Apr 5 19:26 /dev/ttyACM0 # Reboot
Ok, der Fehler ist immer noch da. Es geht also nicht.
Nach dem Reboot hat openHab auch die Rechte wieder auf ausschließlich homegeare gesetzt.
$ ls -alh /dev/ttyACM0 crw-rw---- 1 homegear homegear 166, 0 Apr 5 20:36 /dev/ttyACM
Das soll wohl heißen, das nur homegeare auf die Schnittstelle zur gleichen Zeit zugreifen kann.
Evl. habe ich auch was übersehen, deshalb noch einen Task im Wiki aufgemacht.
Fazit: Geht nicht.
Alles wieder löschen.
sudo apt-get remove openhab-addon-binding-fs20 sudo apt-get remove openhab-addon-io-cul
Einträge aus der openhab.cfg wieder löschen.
Die FS20.items Datei wieder löschen.
Eine Lösung währe, einen zweiten CUL an einem eigenen USB Port. Oder habt Ihr noch einen anderen Vorschlag?
Ähnliche Artikel:
- OpenHab: CUL an Homematic über Homegear auf dem Raspberry Pi unter Debian – Jessie
- Wie läuft die Installation von OpenHAB auf einem Raspberry Pi unter Jessie?
- Wie kann OpenHab und eine Demo-Anwendung auf einem Raspberry Pi (Debian) installiert werden?
