irmplircd für USB IR Remote Receiver (based on irmp)

Hallo,
habe auch einen Empfänger auf USBasp-Basis aufgebaut.
- nur USBasp mit Atmega8A aus Hong Kong von hier: http://www.ebay.de/itm/310506909410?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
- TSOP direkt verbunden (Spannungsstabi über RC-Glied dürfte bei USB-Power überflüssig sein) an SCK/Pin7 der 10-Port Buchse.
- main.hex mit arduino und auch einem anderen USBasp geflasht. verify war ok.
- FUSES auf 0xC9 und 0xEF

Damit wir unter Linux ein hidraw0 erstellt und lsusb zeigt mir das Gerät auch an.
Wenn ich auf verschiedene Fernbedienungen drücke flackert die grüne LED, die rote ist dauerhaft an.
ABER:
cat /dev/hidraw0 bringt NICHTS!

Daher kann irmplircd, irw etc. auch nichts mehr anzeigen.
Was stimmt denn hier nicht?

NACHTRAG:
Mmm, Kommando zurück. Auf einem "richtigen" Rechner mit Debian 7.0.5 live-CD ging's jetzt.
Kann es sein, dass ein Laptop am USB-Port zuwenig Strom liefert?!

NACHTRAG2:
OK, ich bin doof.
hidraw0 war das device der Maus, nicht vom USBasp. Ergo: geht auch am Laptop, wenn man das richtige hidrawX erwischt.

Gibts eigentlich schon ein plugin für OpenELEC?

Hallo,
ich habe ein Verständnisproblem. Wenn ich mir diese Grafik ansehe, gibt's zig Wege IR-codes irgendwie "erkennen" zu können:
http://www.yavdr.org/documentation/0.5/de/ch02s03.html

Nun kann man udev-rules erstellen, damit beim Anstecken des USBasp-IR-Geräts der irmplircd geladen wird. Eigentlich ist das jedoch umständlich, da man extra nen extra dämon kompilieren und laden muss. Evtl. auch noch cross-compile und fürs OpenELEC-image sowieso total umständlich.

Der USBasp erstellt mir ja schon ein hidraw-device. Kann man da nicht irgendwo ne .map erstellen, dass das System LIRC-events zu hören bekommt?
Warum hört mein System keine LIRC-events vom hidraw-dev? Tastatur-hid-events kommen ja auch durch!?
"Irgendwie" scheinen da ja schon etliche Protokolle und IR-Empfänger implementiert zu sein, ich verstehe aber nicht wie das System die Codes letztlich "bekommt", bzw ausführt.
Blickt da jemand durch?

Eine weitere Frage ist, warum der USBasp+IR-Empfänger sich nicht gleich als event-dev anmeldet. Wäre da ein extra kernel-modul nötig?

Hallo,

ich brauchte fuer die Zusammenarbeit mit vompclient einen irmplircd, der mit uinput zusammenarbeitet (aehnlich wie lircd mit der option -u). Ich habe irmplicrd entsprechend erweitert.
Auf meinem raspberry-pi laeuft das gut.
Es ist zwar ein uebler hack, aber bei Interesse kann ich das gerne zur Verfuegung stellen.

Gruss

Wolfgang

Gibts ein Trick damit irmpexec wie irexec funktioniert, in dem man eine Taste mehrmals betätigen muss und der Befehl erst nach dem x-mal ausgeführt wird?

Meine irexec.conf sieht so aus:

begin
  prog = irexec
  button = KEY_POWER
  button = KEY_POWER                  	
  button = KEY_POWER
  button = KEY_POWER
  button = KEY_POWER                  	
  config = reboot
end

Um noch einmal auf das repetition flag zurückzukommen: Das wird in irmplircd ja gar nicht ausgewertet. Die Variable repeat wird ja ausschließlich auf Basis der Zeit hochgezählt. Könnte man das flag nicht auswerten, wenn z.B. das Argument repeat-time beim Aufruf nicht gesetzt ist? Oder meinetwegen, wenn es auf einen negativen Wert gesetzt wird.

--- a/irmplircd.c	2014-11-17 10:12:54.291936000 +0100
+++ b/irmplircd.c	2014-11-17 10:12:28.425761000 +0100
@@ -50,6 +50,8 @@
 #include "hashmap.h"
 #include "mapping.h"
 
+#define IRMP_FLAG_REPETITION 0x01
+
 typedef struct {
   uint8_t	dummy;		// additional useless byte 
   uint8_t	protocol;	// protocol, i.e. NEC_PROTOCOL
@@ -194,7 +196,7 @@ static void processevent(evdev_t *evdev)

 	struct timeval current;
 	gettimeofday(&current, NULL);
-	if(time_elapsed(&previous_input, &current) < repeat_time)
+	if(time_elapsed(&previous_input, &current) < repeat_time || (!repeat_time && event.flags & IRMP_FLAG_REPETITION))
 		repeat++;
 	else 
 		repeat = 0;

Das Repetition-Verhalten nach deinem Commit passt jetzt. Macht Sinn das Flag zu löschen, es wird ja sonst als andere Taste erkannt. Allerdings war noch ein kleiner Bug drin, deshalb der PullRequest.

Du hast ja bei dir in IRMP_DATA ein uint8_t dummy, was ja die ReportID darstellt. Könnte man sich drauf einigen, dass irmplircd nur bei einer gewissen ReportID Meldung auf dem lirc Socket macht und die anderen ignoriert?
Ich bin nämlich gerade dabei jrie STM32 Projekt bisschen umzubauen und es wäre schön, wenn man das Konfigurationsprogramm parallel zu irmplircd ausführen könnte, ohne das irmplircd auf die Erfolgs-/Fehlermeldung vom STM32 nach erfolgter Konfiguration reagieren würde - und damit Tastendrücke meldet, die gar keine waren.
Welche Projekte außer dem USBASP Einschalter verwenden denn noch den irmplircd?

Ich vermute, das von olebowle angesprochene Problem betrifft auch die USBasp Firmware.
Die benutzt Report ID 0x01 für's IR Code übertragen. Ich könnte IRMP_STM32 auch auf 0x01 umstellen.
Insofern ist olebowle's Vorschlag schon sinnvoll.

Hugo Portisch's "USB IR Remote Receiver" und alle davon abgeleiteten Projekte, wie der USBasp, können mit irmplircd benutzt werden.

Schön wäre es wenn die alten Projekte nicht beeinträchtigt werden wenn irmplircd aktualisiert wird. Dazu gibt es sicherlich verschiedene Wege. (=> Ziel: Keine bestehende HW neu flashen müssen nur weil jemand den "Treiber" verbessert)

PS: Wenn jemand das Konfigurationsprogramm 1-2 Mal nutzt um den Einschaltcode zurückzusetzen, dann stören ein paar falsch empfangene IR Codes auch nicht großartig. Störend wird es eher bei Szenarien wo man das Konfigprogramm ständig verwendet. Nur fällt mir gerade kein Grund dazu ein.

Ich denke auch, dass andere Projekte nicht zu beeinträchtigen die Maxime sein sollte. Also doch nur eine ReportID blacklisten?

Alles was auf Portisch basiert sendet IR Codes mit Report ID 0x01, mein IRMP_STM32 mittlerweile auch.
Von daher spricht nichts dagegen, nur 0x01 durch zu lassen.
Lieber gleich richtig

In meinem Projekt muss dann allerdings die Konfiguration auf eine andere Report ID gelegt werden, bei mir läuft zur Zeit alles über eine.

Ich hab die ReportID 0x02 zur Konfiguration gesetzt. Es kommen jetzt nur noch IR-Codes durch.

Moin,

ich hab ein STM32F103 Board mit IRMP am laufen (Projekt siehe: hier bzw. hier)

cat /dev/hidraw1 liefert etwas. Ebenfalls das Programm vom Autor des STM32 IRMP Projekts. wenn ich irmplircd mit

irmplircd /dev/hidraw1

starte und danach irw kommen keine Tastencodes. Als FB nutze ich eine von Technotrend (TT-3600?)

Was mache ich falsch, bzw. wie kann ich dem Problem auf die Spur kommen?

Benutzt du den aktuellen git Stand von irmplircd (geändertes ReportID-handling)?
Es gab einige Veränderungen in der Firmware zum STM32. Könntest du mal folgende Firmware flashen: https://github.com/j1rie/IRMP_STM32?

Mit der überarbeiteten Version in meinem github läuft das aktuelle irmplircd.

Ich hatte natürlich noch die veraltete Firmware, da bis gestern jrie git-hub repo leer war.

Jetzt kommen einwandfrei über irw die Keycodes rein.

Danke