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.
|
1 2 |
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
|
1 2 3 |
fs20:device=serial:/dev/ttyACM0 fs20:baudrate=38400 fs20:parity=0 |
Anlegen einer FS20.items Datei mit den beiden Schaltern.
|
1 2 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
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:
|
1 2 3 4 5 6 7 8 9 10 |
$ 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.
|
1 2 3 4 5 |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# 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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# 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.
|
1 2 |
$ 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.
|
1 2 |
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?