yawor

Look around the How To forum. There's my topic somewhere describing how to use Flirc with EventGhost's Generic HID plugin. Well, at least partially. I've had to modify the Generic HID plugin a little for it to behave correctly. You'll find all the details in the topic. --edit-- Ok, here's the topic: Please take into account, that the attached custom generic hid plugin code is quite old. There might have been many changes to the EG plugins over the years and it may not work anymore.

@Cheater yes, you can. Open the Flirc GUI and go to File menu. There's a Device Log option. It opens Log window. You need to check the IR Debug checkbox. After that you'll get the IR sequence for each key press.

This is the first generation Flirc - the older one. If you can, return it and get a 2nd gen one, which is in the metal case. Anyway, it should work. The driver installation looks fine for the 1st gen. I haven't used Windows for quite some time now so it's hard for me to be more helpful in your case.

@jason this is a G.I. Cable protocol. Here's a thread from about a week ago with my analysis of the same issue (different user):

Use volume keys on Media Keys controller in the GUI.

Your TV uses NEC signals. These are well known and work well with Flirc. On the other hand your STB probably uses G.I.Cable protocol. If I'm right the remote should produce one full frame (the one you see) and then multiple short frames (called ditto frames), which should all look like this (real values can oscillate a little around these values): 0,8820,2205,490 NEC1 also uses ditto frames for repeats (but for NEC1 the timings are different) and Flirc supports them properly. Theoretically it should be possible to support that but I don't know why you don't see these in the log.

Can you record the arrow button again, but this time hold it longer? Because the log file for the arrow key contains only a single signal. Then post the new log file.

This seems to be a remote for remote controlled light dimmers. I don't recognise this protocol. It seems to be really simple, as it looks that it only sends 6-bit message on repeat. I see two issues: - The signal doesn't seem to be robust - it could be triggered from other remotes by accident. - The delay between repeats is really small, only 8 ms - Flirc won't recognise this as a repeated signal. I think this is the main issue: Flirc thinks that the signal is different depending on how long you hold the button on the remote. 8 ms gap between repeats (frames) is too small. Flirc needs at least about 13 ms gap to recognise this a multiple signals sent when the button is being held down. There are some overrides for different protocols, for example for Sony where the gap can go down to 9 ms. It's done by trying to detect a protocol. If Sony protocol is detected then different settings are applied. The problem is that this protocol is too simple and the signals are too short to write a proper protocol detector for it. As the signal is not robust, other remotes/protocols could be affected by that change too, breaking compatibility with them. TL;DR. I'm sorry to say but I don't think it's possible to support this remote.

Hi, No, the firmware is not open. Regarding the possibility of implementing support for this protocol, currently I don't see a way to do this. For Flirc to support many different remotes/protocols, it doesn't decode the signals, but uses some transformations which lead to generating a hash value for the signal. It's the hash value that is stored in the configuration in the flash memory of the device and is compared then against incoming signals. This allows Flirc to work with a lot of different IR protocols, but the downside is that a protocol like Denon won't work correctly. The problem is that Denon protocol is not robust if not decoded correctly. This means that signals similar to the Denon signals can be randomly received from different sources (at least according to description of that protocol in IrScrutinizer software) and can falsely trigger some functions. Only fully decoded full frame (which consists of two half-frames which complement each other) is considered robust. And like I've mentioned above, Flirc doesn't decode the signal.

Hi, This remote uses Denon proprietary protocol. I'm sorry to say this but I don't see a way to support this protocol. The protocol itself is not that complicated. When you press a button on the remote, the remote sends at least two frames. The issue is that odd frames differ from even frames in a very substantial way because the protocol inverts some bits. Flirc sees this as two alternating signals instead of just the same button being held.

This remote seems to use MCE protocol. I've analysed all the buttons and I couldn't find any issues with the signals. They all decoded correctly. Flirc v2 shouldn't have any issues with MCE. Go to Advanced settings in Flirc GUI and disable all built in profiles. MCE protocol uses a toggle bit, which means if you press the same button two times in a row, the remote is going to send two slightly different signals. So to properly record your remote, you need to record each button twice in a row - select the same function in the GUI the second time to have both signal variants assigned to the same function.

Short answer: no. As you've mentioned it yourself, Flirc uses USB HID, so something on the system needs to be able to support specific usage page and translate HID codes into some action. To send Android Keycode directly, Flirc would need to implement whole ADB protocol to be able to speak to ADB on the device and execute shell commands on it. Can you even use ADB on the device in USB host mode? Flirc is an USB device, so anything you plug it into needs to work as USB host.

@GuiBacon is your reply related to Flirc Raspberry Pi case in any way? Because it's hard to understand what do you mean in the context of this thread.

Did you use the same USB cable to the hub before and after moving the HTPC? Interference issues may be hard to handle. Is all your equipment properly grounded? This includes a ground connection in your mains socket, extension cords/power strips etc. Maybe that's an electrical issue, some EM interference. Some people had some problems with the older 1st gen Flirc, when their equipment wasn't grounded and properly grounding the installation helped resolving the problems. There were no such issues with 2nd gen but may still be possible.

Hi, Flirc v2 has a built in support for MCE remote, but it's not a direct replacement for the original MCE receiver. Flirc is seen as an USB keyboard in the system. That means that for Flirc to work with some software, it needs to know how to map a button press on the remote to some keyboard function or letter. As I mentioned above, Flirc has a built-in profile for MCE remotes and it should at least do something in the Kodi or notepad, but it's not meant to use with Kodi. You can try following. In the Flirc GUI, go to Advanced settings and actually disable available built-in profiles then close advanced settings dialog. In the GUI's menu select Controllers and Full keyboard. Click some letter (for example A) on a virtual keyboard in the Flirc program - it should ask you to press a button on the remote. So press one of the buttons - but don't just quickly press and release, it's better to hold the button until the message disappears. Then do a test in the notepad. Press the same button you've recorded few times when the notepad window is active. It should print the letter a. If you followed everything above then probably letter a is only showing every other press on the remote. That's because MCE IR protocol changes signal a little between every other key press (it has a toggle bit). This means that you should actually repeat programming two times for each remote button in the GUI (for example, click on Up Arrow in the GUI, press Up button on the remote, click on Up Arrow again, and again press the button).