Neulich habe ich im FHEM-Forum ein neues Modul (37_linuxHid.pm) gefunden, mit dessen Hilfe HID-Geräte unter Linux mit FHEM verwendet werden können: http://forum.fhem.de/index.php/topic,36257.0.html,36257.0.html
Da fiel mit ein, dass ich irgendwo eine X10-Fernbedienung nutzlos herumliegen habe. Ich weiß auch gar nicht mehr wann und wofür ich sie besorgt habe. In jedem Fall sind soche Geräte (samt USB-Empfänger) immer noch günstig im Internet zu finden (z.B. bei pollin.de). Es gibt mehrere Varianten davon.
Mal sehen, ob damit eine günstige Fernsteuerung für die Automation-Aufgaben realisiert werden kann...
Im Thread ist grundsätzlich beschrieben, wie die Einbindung vorgenommen werden soll. Das Modul war noch nicht in Repository aufgenommen und musste direkt aus dem Forum geladen werden. Noch bevor das geshehen ist, sollte man nachsehen, ob der angeschlossene Empfänger überhaupt im System zu sehen ist.
Wenn dem so ist, sollte es unter /proc/bus/input/devices vorhanden sein.
cat /proc/bus/input/devices
Und tatsächlich meldet sich das Gerät:
I: Bus=0003 Vendor=0bc7 Product=0006 Version=0100
N: Name="X10 WTI RF receiver"
P: Phys=usb-sw-ehci-1.5/input0
S: Sysfs=/devices/platform/sw-ehci.1/usb2/2-1/2-1.5/2-1.5:1.0/rc/rc2/input5
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=100013
B: KEY=108fcf32 ac10043 0 0 0 8 2008000 10180 80002801 9e9680 0 0 ffc
B: MSC=10
I: Bus=0003 Vendor=0bc7 Product=0006 Version=0100
N: Name="X10 WTI RF receiver mouse"
P: Phys=usb-sw-ehci-1.5/input1
S: Sysfs=/devices/platform/sw-ehci.1/usb2/2-1/2-1.5/2-1.5:1.0/input/input6
U: Uniq=
H: Handlers=mouse0 event2
B: PROP=0
B: EV=7
B: KEY=1b0000 0 0 0 0 0 0 0 0
B: REL=3
Weiterhin kann man sehen, dass zwei neue Handler zur Verfügung stehen: event1 und event2, zu finden unter /dev/input/
~ $ ls -l /dev/input/
total 0
drwxr-xr-x 2 root root 100 Aug 4 16:47 by-id
drwxr-xr-x 2 root root 120 Aug 4 16:47 by-path
crw------- 1 root root 13, 64 Aug 4 01:35 event0
crw------- 1 root root 13, 65 Aug 4 16:47 event1
crw------- 1 root root 13, 66 Aug 4 16:47 event2
crw------- 1 root root 13, 63 Aug 4 01:35 mice
crw------- 1 root root 13, 32 Aug 4 16:47 mouse0
Wenn man mit cat den Inhalt von event1 ausgibt und dabei ein Paar Tasten auf der Fernbedienung drückt, sollte man die Ausgaben sehen. Diese sind zwar nicht im ACSII-Format, aber das stört nicht weiter. Es war nur wichtig, eine Reaktion zu sehen (vor allem um zu wissen, dass man das richtige Gerät gefunden hat).
Eigentlich reicht dem Modul bereits die Pfandangabe im Form /dev/input/event1.
define x10_receiver linuxHid event1
Das Problem ist hier nur, dass sich dieser Pfad ändern kann, z.B. wenn weitere Geräte angeschlossen werden. Das Modul bietet dafür eine bessere Lösung: eine Angabe mit Vendor- und Product-ID. Diese sind im ersten Listing bereits zu sehen, die Definition ändert sich damit folgendermaßen:
define x10_receiver linuxHid :0x0bc7:0x0006
Leider reicht das auch noch nicht aus und der Grund dafür ist im zweiten Listing sichtbar. Die neuen Geräte sind nur für den root alleine lesbar. Sicher, man könnte FHEM als root laufen lassen, aber dies wäre wirklich keine so gute idee. Da diese Einträge keine 'normalen' Dateien sind, kommt man auch mit chmod nicht weiter. Spätestens beim Neustart (oder Neueinstecken des Empfängers) werden die Gerätedateien mit alten Rechten neu erstellt.
Eine eigene udev-Regel bietet dafür die Lösung (mehr Info: http://wiki.ubuntuusers.de/UDEV).
Dafür muss eine neue Datei ( sudo nano /etc/udev/rules.d/80-persistent-x10.rules ) mit folgendem Inhalt erstellt werden:
# Diese Regel sorg dafuer, dass der X10-USB-Funkempfaenger beimAnlegen für alle lesbar wird
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc7", ATTRS{idProduct}=="0006", ACTION=="add", MODE="0644"
Hier wird mittels Schlüsselwörter (SUBSYSTEM und ATTRS) das gewünschte Gerät ausgewähl, ACTION="add" besagt, dass die Regel beim Anlegen (also Einstecken) des Empfängers gilt und MODE="0644" legt letztendlich die gewünschte Zugriffsrechte fest. Wieder werden hier Vendor- und Product-ID benötigt.
Nach dem Abziehen und Neuverbinden des Empfängers sieht man auch das Ergebnis:
crw-r--r-T 1 root root 13, 65 Aug 4 17:04 event1
crw-r--r-T 1 root root 13, 66 Aug 4 17:04 event2
Jetzt zeigt FHEM Event Monitor auch schon die Aktionen der Vernbedienung.
2015-08-04 02:12:00 linuxHid x10_receiver EV_KEY: KEY_UP PRESS
2015-08-04 02:12:04 linuxHid x10_receiver EV_KEY: KEY_217 PRESS
2015-08-04 02:12:07 linuxHid x10_receiver EV_KEY: KEY_VOLUMEUP PRESS
2015-08-04 02:12:07 linuxHid x10_receiver EV_KEY: KEY_VOLUMEUP PRESS
2015-08-04 02:12:10 linuxHid x10_receiver EV_KEY: KEY_VOLUMEDOWN PRESS
2015-08-04 02:12:10 linuxHid x10_receiver EV_KEY: KEY_VOLUMEDOWN PRESS
2015-08-04 02:12:11 linuxHid x10_receiver EV_KEY: KEY_MUTE PRESS
2015-08-04 02:12:13 linuxHid x10_receiver EV_KEY: KEY_CHANNELDOWN PRESS
2015-08-04 02:12:14 linuxHid x10_receiver EV_KEY: KEY_CHANNELUP PRESS
2015-08-04 02:12:14 linuxHid x10_receiver EV_KEY: KEY_DOWN PRESS
2015-08-04 02:12:15 linuxHid x10_receiver EV_KEY: KEY_UP PRESS
2015-08-04 02:12:16 linuxHid x10_receiver EV_KEY: KEY_RIGHT PRESS
2015-08-04 02:12:16 linuxHid x10_receiver EV_KEY: KEY_LEFT PRESS
2015-08-04 02:12:18 linuxHid x10_receiver EV_KEY: KEY_RIGHT PRESS
2015-08-04 02:12:24 linuxHid x10_receiver EV_KEY: KEY_RIGHT PRESS
2015-08-04 02:12:25 linuxHid x10_receiver EV_KEY: KEY_352 PRESS
2015-08-04 02:12:25 linuxHid x10_receiver EV_KEY: KEY_352 PRESS
2015-08-04 02:12:25 linuxHid x10_receiver EV_KEY: KEY_5 PRESS
2015-08-04 02:12:25 linuxHid x10_receiver EV_KEY: KEY_141 PRESS
Um darauf zu reagieren, verwendet man FHEM-typisch notify-Regeln. Z.B. so:
define n_x10_test1_notifier notify x10_receiver:.*KEY_UP.* set EG_WZ_DA01_Licht_Rechts_Sw on
define n_x10_test2_notifier notify x10_receiver:.*KEY_DOWN.* set EG_WZ_DA01_Licht_Rechts_Sw off
define n_x10_test3_notifier notify x10_receiver:.*KEY_352.* set tts tts Hallo
Damit hat man eine günstige FHEM-taugliche Fernbedienung. Allerdings sollte man sich im klaren sein, dass diese nicht eine (wesentlich teurere) HomeMatic-Fernbedienung (und vergleichbare Geräte) ersetzen kann. Die X10 bietet weder eindeutige IDs noch irgendeine Art von Sicherheit. Jeder, der eine solche Fernbedienung hat, kann damit die gleichen Aktionen im Haus auslösen. Dank Funk und einer guten Reichweite (ca. 8 Meter durch die Wände und 4-5 Meter in dem oberen Stockwerk, also durch eine Stahlbetondecke hindurch) geht das auch von der Straße aus. Um sicherheitskritische Vorgänge zu steuern, eignet sich dieses Gerät nicht. Ich würde auch empfehlen, die Steuerregeln etwas komplexer zu gestallten. Wenn nur auf Tastenfolgen reagiert wird, verringert sich das Risiko eines ungewollten Schaltvorgangs erheblich. Beispiel: Taste on/off versetzt FHEM für eine kurze zeit in Bereitschaft auf neue Befehle zu reagieren, die Taste mit dem roten Strich wählt Beleuchtung als Zielsystem aus, jetzt können die Pfeiltasten zum Dimmen der Beleuchtung verwendet werden.
Vollständigkeitshalber: noch mehr technische Information liefern Befehle sudo lsusb und sudo lsusb -vs <BUS>:<DEVICE>. (Konkret für dieses Device: sudo lsusb -vs 002:031)
~ $ sudo lsusb
Bus 002 Device 012: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 030: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 002 Device 029: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 026: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 002 Device 023: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 031: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)
Bus 002 Device 024: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
~ $ sudo lsusb -vs 002:031
Bus 002 Device 031: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0bc7 X10 Wireless Technology, Inc.
idProduct 0x0006 Wireless Transceiver (ACPI-compliant)
bcdDevice 1.00
iManufacturer 1 X10 WTI
iProduct 2 RF receiver
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Kommentare (5)
wieder mal eine lange Zeit vergangen aber "Gut Ding will Weile haben".
Also anhand deines Scriptes hab ich es versucht. Der Wert 1 wurde auch immer brav geliefert jedoch hing es bei mir daran das Notify entsprechend zu gestalten. In diesem Zuge habe ich natürlich auch etliche Tutorials studiert um mehr über die Notifys zu lernen.
Dabei bin ich dann auch über diese Stelle gestolpert.
https://wiki.fhem.de/wiki/Notify#Schalter_entprellen
Und siehe da, das Beispiel funktioniert!
Ich habe zwar immer noch Probleme damit werte aus Perlscripts zu übernehmen/verarbeiten aber das ist ein anderes Thema.
Bis hierher also also schon mal vielen Dank für dein Mühen und erfolgreiches basteln weiterhin.
Freut mich, dass es klappt :)
Als 'Debouncer' verwende ich (seit langem) folgendes Script. Es kann man sicher besser lösen, aber bis jetzt funktioniert.
Perl-Sub in 99_MyUtils.pm:
###############################################################################
my $debounce_map;
###############################################################################
# Eine Art Entprellung.
# Es wird geprüft, ob der Schluessel in der angegebenen Zeit bereits
# angefragt wurde. Dann wird liefert 1 (true), sonst 0 (false).
# Damit kann z.B. sichergestellt werden, dass nur ein Befehl
# in der angegebenen Zeit ausgefuehrt wird. Nuetzlich bei notify-Befehlen.
#
# Parameter: Key - Schluessel; time - Zeit in Sekunden
###############################################################################
sub
debounce($$)
{
my($key, $dtime) = @_;
my $ctime = time();
my $otime = $debounce_map->{$key};
if(!defined($otime)) {
# neuer Key, Zeitstempel speichern
$debounce_map->{$key}=$ctime;
return 1;
}
# Zeitablauf pruefen
my $delta = $otime+$dtime-$ctime;
if($delta gt 0) {
# Zeitfenster noch nicht abgelaufen
return 0;
}
# Zeit abgelaufen, Zeitstempel redefinieren
$debounce_map->{$key}=$ctime;
return 1;
}
if(debounce("irgendein-name",1)) {
...
}
Dann musst Du für alle Vorgänge, die zusammengehören, den gleichen 'key' angeben, dann werden innerhalb der gegebener Zeit die anderen mit selben Key ignoriert.
Es war genau wie Du geschrieben hattest und seither funktioniert es wunderbar.
Was ich aber seit einiger Zeit, leider ohne Erfolg, versuche ist das prellen zu verhindern. Solange ich, wie in der Anleitung, mit einem Tastendruck ON und mit einem anderen OFF schalte gibt es keine Probleme.
Trage ich jedoch toggle ein wie in:
x10_receiver:.*KEY_9.* set Licht toggle
schaltet sich das Relais wie ein Maschinengewehr ein und aus solange man die Taste drückt. Inzwischen habe ich zwar raus wie "kurz" ich die Taste drücken muss jedoch ist WaF nicht zu unterschätzen.
Befehle wie Debounce oder event-min-interval funktionierten leider auch nicht bei diesem konkreten Beispiel.
Hast Du da vielleicht auch eine schnelle Lösung oder muss das über ein kleines Perl-script gelöst werden?
Ansonsten erst mal Danke für Deine tollen Beschreibungen und Anleitungen (Das Liveimage auf externem Medium... hat bei mir auf Anhieb funktioniert)
Dein Listing zeigt, dass nur Eigentümer und Gruppe von dem Device lesen (und auch schreibewn) darf. Das bedeutet, das die Udev-Regle (wenn Du es wie bei mir übernommen hast), nicht zieht, sonst dürfte jeder lesen. Aber ok. Wenn FHEM in der Gruppe 'input' ist, sollte es auch klappen. Prüfe ggf., ob die Regel korrekt ist: Vendor/Product-ID...
Jedoch funktioniert es bei mir (noch) nicht ganz.
Ein ls -l /dev/input/ liefert:
drwxr-xr-x 2 root root 100 Jun 18 13:44 by-id
drwxr-xr-x 2 root root 100 Jun 18 13:44 by-path
crw-rw---- 1 root input 13, 64 Jun 18 13:44 event0
crw-rw---- 1 root input 13, 65 Jun 18 13:44 event1
crw-rw---- 1 root input 13, 63 Jun 18 12:41 mice
crw-rw---- 1 root input 13, 32 Jun 18 13:44 mouse0
mit cat /dev/input/event0 reagiert der Raspberry auch auf Tasten der Fernsteuerung und ich bekomme die zumindest kryptische Zeichen angezeigt.
Die udef Regel habe ich nach Deinen Vorgaben eingerichtet.
Ich Fhem jedoch steht im Log dauerhaft:
x10_receiver: error opening /dev/input/event0