yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

  • Ohne das ganze jetzt schlecht reden zu wollen. Ich finde die pure Ausrichtung auf lirc insgesamt als schlechte Idee. Richtig wäre meine Ansicht nach, alles im Microcontroller umzusetzen und sich dann zum System hin als Eventdevice zu melden.


    Tja, würde dann meine ir Tastatur auch funktionieren? Ich finde nen RAW ir Empfänger schon sinnig, sich da auf bestimmte Codes festzulegen schrängt nur unnötig ein.


    Nen rc Core Treiber (anstelle des lirc Userspace Treibers) wäre allerdings schön, dann hätte man alle Möglichkeiten. Aber das ist ja immer noch möglich, muss sich nur jemand mit Zeit/Fähigkeit/Interesse finden.



    Wobei man am Ende eh irgendwie wieder auf lirc muss (und sei es mit eventlirc/inputlirc), denn Eventdevices eigenen sich nicht sonderlich gut für Fernbedienungen (jedenfalls nicht für den ernsthaften Betrieb).


    cu

  • Scheinbar ist die aber Unterschied zwischen "Meinug äussern" und "ständig an allem zu nörgeln" nicht bekannt??


    BTW: Ob mich irgenwelche 19 Jährigen ignorieren, oder nicht, geht mir mir völlig am Arsch vorbei!

  • Ohne das ganze jetzt schlecht reden zu wollen. Ich finde die pure Ausrichtung auf lirc insgesamt als schlechte Idee. Richtig wäre meine Ansicht nach, alles im Microcontroller umzusetzen und sich dann zum System hin als Eventdevice zu melden.


    Du hast Recht, das ganze muss alles nach rc-core. Das mit diesem Ansatz nicht jede Hardware funktioniert (Keine_Ahnungs Tastatur?) ist nicht schlimm. Lirc ist ja nicht weg und irgendwann ist seine Tastatur auch kaputt. Man muss nicht wirklich auf jede Alt-Hardware Rücksicht nehmen. Wenn wieder erwarten viele diese Hardware noch nutzen, dann erbarmt sich ja vielleicht jemand und schreibt einen rc-core treiber dafür. Für yaUsbIr wäre es wirklich schade wenn das nicht passiert, auch wenn ich den Empfänger nicht aus eigener Erfahrung kenne. Der Ansatz gefällt mir aber.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Ist das ein 32- Bit System? Hast du die lircd.conf für den yaUsbIr schon an die passende Stelle kopiert?

    Ja, ist 32-bit.
    Passende Stelle?! Im Betrieb liegt sie unter /etc/lirc/lircd.conf und wird vom lircd gezogen.
    Ansonsten gebe ich sie direkt an:

    Code
    sudo daemons/./lircd -n --driver=ya_usbir /etc/lirc/lircd.conf

    , wenn ich gerade rumprobiere.


    Was mir noch auffällt: irw und mode2 liefern zuverlässig Werte. Trotzdem muss ich bei irrecord elend lange rumdrücken, bis ich mal die 2*80 Punkte zusammen habe.
    Ist das bei euch mit yaUsbIr auch so? Seriell ist das nicht so ein Gehakel.


    Viele Grüße,
    Chriss

  • Keine_Ahnung: Ich betreibe hier ernsthaft eine MCE-Fernbedienung mit dem remote-Plugin.


    OK, ich meinte "für mich akzeptabel ernsthaft" ;)


    Man kann keine Tasten doppelt belegen, man kann keine Systembefehle aufrufen *), man kann Repeatdelay/Repeat nicht für verschiedene Tasten unterschiedlich einstellen. Man kann verschiedene Fernbedienungen (die gleichzeitig genutzt werden) nicht mit unterschiedlichen Delays kofigurieren.


    Die Idee Fernbedienungen als Tastaturen abzubilden war extrem kurzsichtig von den rc Core Machern. Fernbedienungen und Tastaturen sind vollkommen unterschiedliche Dinge die auch vollkommen unterschiedlich verwendet werden.
    Und das man dann auch noch gezungen wird die FB Tasten auf die Tastaturtasten zu mappen ist schon ne sehr seltsame Idee. Da mappt man ne "Fav" Taste auf KEY_Y (weil mans halt auf irgendwas mappen muss) und das ist dann gut und übersichtlich?


    Du hast Recht, das ganze muss alles nach rc-core.


    Ich glaube er meint eher HID und nicht rc Core.


    und irgendwann ist seine Tastatur auch kaputt. Man muss nicht wirklich auf jede Alt-Hardware Rücksicht nehmen.


    Wenn ich irgendwo ne Fernbedienung sehe die ich nehmen möchte dann möchte ich die nehmen. Ich möchte nicht die nehmen die zufällig zum Empfänger passt.


    Wie gsagt, ich denke er meint HID mit Codeauswertung im Empänger.


    rc Core fände ich auch gut. Aber der Empfänger sollte RAW ir Daten liefern und nciht die Codes selber auswerten.


    cu


    *) z.B. die epgsearch Kanalliste öffnen und mit der selben Taste wieder schliessen. "svdrpsend plug epgsearch MENU NOW"

  • Da mappt man ne "Fav" Taste auf KEY_Y (weil mans halt auf irgendwas mappen muss) und das ist dann gut und übersichtlich?


    Eine kurze Google-Suche nach "ir-keytable" hat ergeben, dass KEY_FAVORITES auch valid zu sein scheint.

    Ich glaube er meint eher HID und nicht rc Core.


    Nein, nein. Ich meine schon rc_core. Zumindest ist bei mir dieses Kernel-Modul aktiv.

    *) z.B. die epgsearch Kanalliste öffnen und mit der selben Taste wieder schliessen. "svdrpsend plug epgsearch MENU NOW"


    Das wäre doch fast ein Featurerequest für den VDR wert.


  • Eine kurze Google-Suche nach "ir-keytable" hat ergeben, dass KEY_FAVORITES auch valid zu sein scheint.


    War ein Beispiel ;) Fakt ist man bekommt z.B, die X10 nicht vernünfig gemappt weil sinnige Namen in input.h fehlen.



    Nein, nein. Ich meine schon rc_core. Zumindest ist bei mir dieses Kernel-Modul aktiv.


    Weil du davon gesprochen hast die Codes im Mircocontroller zu dekodieren, das ist HID.


    cu

  • Mich nervt, dass anscheinend mittlerweile alles nach 'Copperhead' riechen muss, angefangen bei den vdr makefiles. Wie wäre es denn, wenn einmal(!) eine fertige und funktionierende Lösung präsentieren würdest, anstatt an Allem und Jedem nur zu Nörgeln!?!


    Ich sehe da kein Nörgeln, das ist einfach das eingeforderte Querdenken :unsch Sachliche VDR-Zusammenfassung gesucht
    Der Vorteil für mich ist: wenn es mal funktioniert macht es einiges einfacher beim Bauen der Plugins - wenn man sich die PKGBUILDs für die angepassten Plugins mal ansieht, springen die Vorteile deutlich ins Auge ;). IMHO sollte man das aber in einen anderen Thread auslagern, das Verhalten des yaUsbIr an 32-Bit Systemen ist ja ein völlig anderes Thema.


    Tja, würde dann meine ir Tastatur auch funktionieren? Ich finde nen RAW ir Empfänger schon sinnig, sich da auf bestimmte Codes festzulegen schrängt nur unnötig ein.


    Wenn man dem Empfänger das Protokoll beibringt kann das auch Vorteile haben... Ich habe auf Basis eines Arduinos mit IRMP einen Kompromiss-Ansatz ausprobiert - IRMP decodiert alle aktivierten Protokolle (für mich RC-5 und RC-6) und sendet dann einfach einen HEX-Code für die Tasten (momentan noch über eine serielle Verbindung). Was man dann damit anfängt (uinput-Device, LIRC-Daemon usw.) bleibt einem je nach Gusto selbst überlassen. Klappt auch gut, solange das benötigte Protokoll unterstützt wird und man fängt sich kein "Rauschen" ein - ein yaUsbIr oder Atric blinkt fröhlich unter bestimmten Energiesparlampen, ein Empfänger, den man auf bestimmte Protokolle festgenagelt hat, tut das i.d.R. nicht und rückt nur Tastencodes raus, die er selbst kennt, der Rest wird für den PC rausgefiltert. Wenn man sich ansieht wie bestimmte ASRock-Boards auf IR-Störungen über den CIR-Empfänger reagieren und dann beim Booten hängen bleiben, ist so eine Lösung für ein einzelnes System, das auf eine bestimmte Konstellation zugeschnitten ist, bestimmt kein zwangsläufiger Nachteil.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • theonlychriss: hast du schon mal die Version 1 des yaUsbIr-Patches ausprobiert - nur um Auszuschließen, dass es an einer Änderung im irsend-Teil liegt?
    http://www.vdr-portal.de/index.php?page=Attachment&attachmentID=30222&h=4acd3a0e79f1515829d495c5f2f724d57efda145

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • :cool1
    Und wieder hattest Du den richtigen Riecher! Danke Dir!!!


    Hehe, also mit der "alten" Version des Patches tut's wie's soll. Zumindest das An- und Abschalten der roten LED, irrecord und die ganz normale Bedienung per FB funktionieren jetzt wie erwartet.
    Den Rest probiere ich später, für heute reicht es.


    3PO: Vielleicht machst Du doch noch einen letzten Versuch?!


    Uwe: Kannst Du Dir das erklären?


    Viele Grüße,
    Chriss

  • Den Tip von seahawk1986 - 3 Posts früher:

    theonlychriss: hast du schon mal die Version 1 des yaUsbIr-Patches ausprobiert - nur um Auszuschließen, dass es an einer Änderung im irsend-Teil liegt?
    http://www.vdr-portal.de/index.php?page=Attachment&attachmentID=30222&h=4acd3a0e79f1515829d495c5f2f724d57efda145

    Viele Grüße,
    Chriss

  • So, ich habe jetzt mal etwas probiert und einen Patch für uwe67's Lirc-Patch (lirc-0.9.0_ya_usbirv2.diff) gebastelt:


    Damit klappt das Empfangen und Senden bei mir unter Ubuntu 12.04 64-Bit und 32-Bit (Pakete für yaVDR 0.5/Ubuntu Precise: https://launchpad.net/~seahawk…55/+listing-archive-extra) sowie Arch Linux 64-Bit.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke seahawk!


    Damit funktionieren wie gehabt Befehle, die mit

    Code
    C_IR

    eingeleitet werden.
    Auf

    Code
    C_WATCHDOG, C_INPUT, C_OUTPUT

    wird leider nicht reagiert. Auch kein Fehlerblinken, wenn man zwischen Präfix und Suffix den eigentlichen Befehl weglässt, wie z.B. bei

    Code
    C_WATCHDOG C_END


    Irgend etwas ist da noch nicht richtig.
    War übrigens bei original-V1 des Patches genauso.


    Viele Grüße,
    Chriss

  • Ich hatte gestern Abend nur Senden und Empfangen ausprobiert.
    Bei C_INPUT sehe ich in der Ausgabe von lircd einen Lese-Fehler in


    Offenbar reichen die 25 ms also noch nicht aus, damit da genug Daten zusammenkommen. Nach dem Hochdrehen des Timeouts klappt es hier mit C_INPUT:


    EDIT: C_WATCHDOG geht auch, für C_OUTPUT fehlt mir noch eine passende Test-Verkabelung.
    EDIT2: C_OUTPUT klappt auch.


    Können das mal Leute testen, die Probleme mit dem yaUsbIr und den irsend-Funktionen haben?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Edited 4 times, last by seahawk1986 ().

  • yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke für Deine unermüdliche Arbeit daran!

    Quote

    Bei C_INPUT sehe ich in der Ausgabe von lircd einen Lese-Fehler

    Bei mir wird kein Fehler ausgegeben, aber auch keine Bestätigung oder sonst eine Reaktion.
    Habe den Timeout auch schon auf 220 gestellt, wie es in der V1 des Patches war, ohne Erfolg.


    Viele Grüße,
    Chriss

  • Habe den Timeout auch schon auf 220 gestellt, wie es in der V1 des Patches war, ohne Erfolg.


    Das war zumindest bei mir im Test zu lang...


    Wie sieht denn der Aufruf bei dir aus?
    Lirc wird unter yaVDR effektiv z.B. so gestartet (der Name des Lirc-Sockels richtet sich nach der jeweils vergebenen PID):

    Code
    /usr/sbin/lircd --nodaemon --output=/var/run/lirc/lircd.11137 --driver=ya_usbir --listen


    Und ein C_INPUT-Aufruf sieht dementsprechend so aus:

    Code
    sudo irsend -d /var/run/lirc/lircd.11137 SEND_ONCE yaUsbIR_control C_INPUT 1 1 C_END # PIN #1 auf Pegel-Input umschalten
    sudo irsend -d /var/run/lirc/lircd.11137 SEND_ONCE yaUsbIR_control C_INPUT 3 1 C_END # PIN #1 Pegel abfragen
    sudo irsend -d /var/run/lirc/lircd.11137 SEND_ONCE yaUsbIR_control C_INPUT 1 2 C_END # PIN #2 auf Pegel-Input umschalten
    sudo irsend -d /var/run/lirc/lircd.11137 SEND_ONCE yaUsbIR_control C_INPUT 3 2 C_END # PIN #2 Pegel abfragen


    Und bei irw kommt dann das zurück:

    Code
    sudo irw /var/run/lirc/lircd.11137
    0000000000001f11 00 IN_1_H yaUsbIR_frontswitch
    0000000000001f13 00 IN_2_H yaUsbIR_frontswitch

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!