FHEM vs. irTrans USB Device Krieg

Begonnen von invalid, 07 Dezember 2014, 16:27:42

Vorheriges Thema - Nächstes Thema

invalid

Hallo zusammen,

ich weiß nicht, ob jemand die Firma irtrans aus München kennt, die bauen jedenfalls Hochleistungs-Infrarot-Sender, die man u.A. per USB ansteuern kann.
Dafür gibt es sen Source Code, den man für ARM eben kompilieren muss, ist aber kein Problem.

Ich habe also einen Banana Pi (ARM v7, RPi Ableger) mit Debian drauf und darauf FHEM über die Packetquellen installiert.
Den CUL habe ich per USB angeschlossen und das funktioniert ganz gut, nur manchmal detektiert er neue Funkbefehle nicht, dann muss ich fhem eben neu starten.
Halb so wild, da ich beim Einrichten eh über SSH verbunden bin und das neustarten ja schnell geht.
Außerdem habe ich dann einen irtrans Infrarot-USB-Sender & Empfänger (Translator genannt) angeschlossen, den server kompiliert und gestartet, per Windows Client über LAN das Ganze gestestet, geht auch ohne Probleme.
Mir ist es auch gelungen mit FHEM ein Infrarot-Signal zu senden (über perl system execute).

Nach nem Neustart habe ich jetzt folgendes Problem:
FHEM startet nur, wenn kein USB Gerät oder nur der CUL angeschlossen ist.
der IR-Server startet nur, wenn der Translator angeschlossen ist.
FHEM startet NICHT, wenn der Translator angeschlossen ist.
der IR-Server startet NICHT, wenn FHEM läuft oder der CUL angeschlossen ist.

Ergo kann ich nur eines von beiden gleichzeitig betreiben, was mich schon ziemlich nervt.


FHEM bleibt beim Start bei "Probing FRM device /dev/ttyUSB0" hängen.
Wenn der Translator nicht dranhängt, beendet er "usb create starting" erfolgreich, der Befehl oben ist Teil dieser Routine.

Hat jemand eine Idee, wie ich das Problem löse ?
Ich habe leider an dem Gerät nur einen USB Kanal mit 2 Ports.

Meine einzige Idee war bisher einen 2. Pi daneben zu stellen, der eine der beiden aufgaben übernimmt und die befehle über lan weiter zu geben.
Da nur Infrarot gesendet und nicht empfangen werden soll, wäre das möglich wenn auch nicht besonders elegant.

Hat jemand also vielleicht eine Alternative ?

kaihs

Du könntest mal versuchen initialUsbCheck abzuschalten:


attr initialUsbCheck disable 1


Wenn fhem Usb probing allerdings hängen bleibt ist das mglw. ein Bug der behoben werden sollte.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

invalid

Zitat von: kaihs am 07 Dezember 2014, 17:18:26
Du könntest mal versuchen initialUsbCheck abzuschalten:


attr initialUsbCheck disable 1


Wenn fhem Usb probing allerdings hängen bleibt ist das mglw. ein Bug der behoben werden sollte.


hat geholfen danke