IRMP Daemon (irmplircd) in Python - Verbesserungen,Ideen

Hi,

seit einiger Zeit arbeite bastle ich am IRMP auf dem Raspberry Pi Pico (RP2040).

Mein Fork von Jörgs Repo.

Im Verzeichnis Examples/Python habe ich ein paar Beispiele der Verwendung in Python geschrieben.

Jetzt auch einen irmplircd.py sowie lircd_client.py (~irw).

Einfach weil ich lernen wollte wie man sowas mit Python macht. Da bin ich Anfänger (aber +30 Jahre C/C++ und andere).

Meine Frage an die Geeks: Der originale irmplircd in C liest auch per evdev. Ist das nur weil er vom inputlircd abgeleitet ist oder braucht man das?

Habe ich noch nicht drin (und ist für meine Anwendung nicht notwendig).

Ideen:

- Map file als Verzeichnis (/etc/irmplircd/irmplircd.d)

- Map files auch für Rückwärtsübersetzung (Name nach Code)

- Clienten können per sendall IR-Codes senden (~irsend) (deshalb die Rückwärtsübersetzung)

- Clienten können per sendall die Status-LED schreiben und auch meine NeoPixelerweiterung verwenden

Dann wäre alles an einem Platz wie bei Lirc auch.

Meinungen?

ja, ist mir klar, habe mich nur gewundert warum das bei irmplircd noch drin ist.

Die Daten kommen (bei mir) direct vom HIDRAW device (IRMP), werden geparsed, dann werden Adr, Command etc in einen String gepackt (wie bei der C-Version auch und mit sendall in den Socket geschrieben.

IRW (oder mein Python client) lesen vom Socket und zeigen die Daten dann an.

./irmplircd.py
LIRC UNIX Socket listening on path /home/USER/lircd
Read the data in endless loop
Accepted connection from client
15000f042200 0 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP

irw /home/USER/lircd
15000f042200 0 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP

Das lokale Socketfile habe ich nurs für debugging, später wird der im /run sein wie bei der C-Version.

Es sind auch noch Debugausgaben drin.

Ich muss mir die C-Version nochmals anschauen...

Hi,

jetzt habe ich den C-Code analysiert und verstehe warum du meine Frage nicht verstandest.

Ich bin über den Variablennamen "evdev" gestolpert und habe deshalb in eine andere Richtung gedacht.

Aber das ist nur ein struct der den Pfad und file desc enthält (und zu weiteren verlinken kann).

typedef struct evdev {
    char *name;
    int fd;
    struct evdev *next;
} evdev_t;

Damit war die Funktion klar. So habe ich die HIDRAW früher (in C++) auch verwendet.

Ein QuickHack zeigt dass es auch in Python so geht.

Bin am überlegen ob ich das hidapi Modul raus nehme. Es bringt hier nichts und es ist eine weiter Abhängigkeit.

(und hat mich einiges Zeit gekostet bis ich die richtige udev Regel hatte. Deine udev reichte nicht aus)

Hi,

den Link hatte ich schon in meinen Bookmarks, aber früher mal nur überflogen.

Hi,

mal einen Status für irmplircd.py (Examples/Python/irmplircd.py):

Es werden jetzt einige Dinge vom originalen lircd unterstützt

• -- listen (senden der Codes/KEYS an andere lircd (auch übers Netz)
• -- connect (Codes/KEYS von anderen lircd erhalten (auch übers Netz)
• Kommandoschnittstelle,
  damit funktionieren irsend und lirctool
  send_once, list, simulate, version
  (SEND_START, SEND_STOP, SET_TRANSMITTERS fehlen noch, sind aber nicht so wichtig)

PS: Hat mir einiges an Verständnis über lirc gebracht.