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

Zitat von Copperhead

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

3PO: Du landest jetzt auf meiner Ignorierliste.
Ich darf hier so oft meine Meinung äußern wie ich das will. Ob es dir passt oder nicht.

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

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!

Zitat von Copperhead

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

Zitat von seahawk1986

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:

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

Zitat von Copperhead

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?

Zitat von gda

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

Ich glaube er meint eher HID und nicht rc Core.

Zitat von gda

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"

Zitat von Keine_Ahnung

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.

Zitat von Keine_Ahnung

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.

Zitat von Keine_Ahnung

*) 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.

Zitat von Copperhead

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.

Zitat von Copperhead

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

Zitat von Keine_Ahnung

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

Ich bin bis vor 5min auch noch davon ausgegangen, dass genau das passiert.

Zitat von 3PO

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 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.

Zitat von Keine_Ahnung

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.

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

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

Zitat von theonlychriss

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

Gerne, wenn Du mir sagst, was ich versuchen soll?

Den Tip von seahawk1986 - 3 Posts früher:

Zitat von seahawk1986

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:

--- a/daemons/hw_ya_usbir.c
+++ b/daemons/hw_ya_usbir.c
@@ -269,7 +269,7 @@
 	uint8_t ya_usbir_rxbuf[64];
 
 	if (ya_usbir_dev == NULL) return 0;
-	num = rawhidrecv(ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 1);
+	num = rawhidrecv(ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 25);
 	if (num < 0) {
 		logprintf(LOG_ERR,"yaUsbIr: error reading, device went offline");
 		return 0;
@@ -569,7 +569,7 @@
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 82;// 36,50 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 81;// 37,04 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 80;// 37,50 Khz
-			ya_usbir_txbuf[ya_usbir_txbufpos++] = 79;// 37,88 Khz
+			ya_usbir_txbuf[ya_usbir_txbufpos++] = 0x0D;// Fix Frequency
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 78;// 38,46 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 77;// 39,06 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 76;// 39,38 Khz

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.

Danke seahawk!

Damit funktionieren wie gehabt Befehle, die mit

C_IR

eingeleitet werden.
Auf

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

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

+static int parsesamples(int pipe_rxir_w)
+{
+	lirc_t rcvdata = 0;
+	int num, n;
+	uint8_t ya_usbir_rxbuf[64];
+
+	if (ya_usbir_dev == NULL) return 0;
+	num = rawhidrecv(ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 1);
+	if (num < 0) {
+		logprintf(LOG_ERR,"yaUsbIr: error reading, device went offline");
+		return 0;
+	}

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:

--- a/daemons/hw_ya_usbir.c
+++ b/daemons/hw_ya_usbir.c
@@ -269,7 +269,7 @@
 	uint8_t ya_usbir_rxbuf[64];
 
 	if (ya_usbir_dev == NULL) return 0;
-	num = rawhidrecv(ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 1);
+	num = rawhidrecv(ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 50);
 	if (num < 0) {
 		logprintf(LOG_ERR,"yaUsbIr: error reading, device went offline");
 		return 0;
@@ -569,7 +569,7 @@
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 82;// 36,50 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 81;// 37,04 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 80;// 37,50 Khz
-			ya_usbir_txbuf[ya_usbir_txbufpos++] = 79;// 37,88 Khz
+			ya_usbir_txbuf[ya_usbir_txbufpos++] = 0x0D;// Fix Frequency
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 78;// 38,46 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 77;// 39,06 Khz
 //			ya_usbir_txbuf[ya_usbir_txbufpos++] = 76;// 39,38 Khz

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?

Pakete für Precise/yaVDR 0.5 gibt es hier: https://launchpad.net/~seahawk1986-hotmail/+archive/misc/+packages?field.name_filter=lirc&field.status_filter=published&field.series_filter=

Danke für Deine unermüdliche Arbeit daran!

Zitat

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

Zitat von theonlychriss

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):

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

Und ein C_INPUT-Aufruf sieht dementsprechend so aus:

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:

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