x10 remote 01 k


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 (4)

Cancel or

  • Alexander Schulz
    @Frank
    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.
  • Frank
    Mit langen Antwortzeiten kann ich auch dienen aber das muss wohl so sein wenn man nur Hobby -bastler, -programmierer, -elektroniker ist.
    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)
  • Alexander Schulz
    Hallo und tut mir leid die lange Antwortzeit.
    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...
  • Frank
    Hallo erst einmal herzlichen Glückwunsch zu der tollen Anleitung.
    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