Leaderboard

** May 03, 2024 ** - Updating links Fairly close to a release candidate. List of what's still left is at the bottom. Critical - Learning requires both remotes to be facing each other and about 1 inch apart. Further detail here along in previous releases: Alpha 1 Alpha 2 Alpha 3 Alpha 4 Alpha 5 Here is how it works: CleanShot 2023-12-15 at 22.54.49.mp4 You need to be using the included firmware in order to do any recording. The version embedded is v4.13.2 Changelog Improved - Many Recording bugs Improved - Decoding Library Improved - Panasonic Decoding Improved - Ability to capture x1 signals automatically Improved - Manual Recording Overrides Improved - Logging Improved - User Feedback and Messaging during recording Improved - Bad capture detection and feedback Database - Updates Fixed - Windows - Unable to connect with Server Fixed - Bottom and Top bar z-index during wizard Firmware - Battery Improvements Mac Download Windows Download Linux - We understand the issue, and have one more bug to solve. We're working on it. Firmware Update If you are not presented with update dialog, please follow the directions outlined here. What's Next User config optimizations More bad capture edge cases we are aware of Updated Decoding Library Save the button layout for later recall or editing Save the button layout for user config export Fix linux

Worked very well under Windows 11, thank you! The overall UI seems to be more responsive/ behaving more consistent as expected. Especially clicking back and forth got more reliable :-) A few things you might already be aware of: My remote I wanted to copy has two left/right buttons (2 single buttons and one cross up/down/left/right/center) -> If I use the predefined element for the "cross" element and the single buttons they act as the same function (which makes sense for normal use cases). I ended up using "custom" buttons and label them accordingly (different audio input channels). I already had imported a similar config file I found online, but didn't work. I entered the same name for the custom device/manufacturer which ended up with a message that this name already existists. Even though I clicked to replace the old config, it didn't recognize it as a new setup -> I was not able to sync it to the remote. Even removing it from the device list the channel (A) and re-adding it didn't trigger the sync-button. After removing it from the admin panel and added the remote again, it worked as expected. While entering a new manufacturer and device name: When pressing tab on the keyboard, it jumps to the next field, but the cursor is not yet set in the text box (even though the field got highlighted already) Thanks for the great work! It is somehow satisfying to use 3 devices with one remote like it is one device :-) The TV interface is even snappier compared to the original remote, feels now like the remote controller via bluetooth - I always thought the OS of the TV (Hisense) is just laggy / slow. Regards, Lennard

This is probably unsupported in any way by Jason so please don't report bugs in other threads when using this solution. If you have any problems with this setup it is better to post them here and I'll try to help if I have time to do so. Hi, This how-to is for users who want to build more advanced control schemes using their Flirc devices. It is mainly directed to Windows users because there is no way in Windows to capture input from a single keyboard, but can be done in Linux. But it should be also applicable in other OS-es when used with correct software. The problem is that not everything can be done just by defining a single key combinations. There are applications like AutoHotKey (AHK) or EventGhost (EG) that can capture specific key combinations but there is a problem. Having many buttons on the mapped remote it is sometimes hard to find key combinations that are not used as OS or other apps shortcuts already. By capturing the specific key combination in AHK or EG user basically blocks this combination even on a normal keyboard connected to the PC (as there is no way in Windows to capture only input from one specific keyboard). Here comes HID standard for the rescue. HID keyboards are just one of the many usages of this standard. Because of that the HID standard has been split into multiple usage tables. Standard keys on keyboards use table 7 and in Windows codes from this table are immediately captured by HID keyboard filter driver and are converted into key presses. On the other hand keys like multimedia keys are defined in usage table 12. Codes from this table are not captured by the Windows. Only a few of them are natively supported (like volume, mute, play, pause etc). Flirc GUI and CLI util provide the ability to map only a few of the keys from table 12. Those keys when mapped are not recognized by AHK or EG when used with keyboard input plugins. This gave me an idea to do some experiments. I needed to find out how these multimedia keys are stored in the Flirc which can be checked by inspecting saved config file. After that I checked if I can assign any HID code from the table 12 and I was successful. I've found out that there is a key code which acts as a marker for Flirc to send usage 12 instead o 7. When this marker is found then the actual HID key ID is stored as a modifier. It is possible to use flirc_util to map almost any code from table 12: flirc_util.exe record_api 176 102 where 176 is decimal value of key ID (Play key in this case) and 102 is a marker that tells Flirc that this is key from table 12. Table 12 has more than 256 keys defined but unfortunately Flirc can only hold a single byte value so there is still a restriction in the number of keys. There are also holes in the list of keys in this table which I've used in my own config so I don't have any conflicts with other hardware and software. These are the usable values: 4-31, 34-47, 55-63, 73-95, 103-127, 159, 165-175. There are probably more but I've stopped looking other codes that are not mentioned by the standard. I think that other keys that are in the standard are also usable. Most of them are not natively supported by the Windows but I used these ranges in my case to be on the safe side. The way to record these keys is to change the first value to one in these ranges and record a button to them incrementally. In my setup I've used EventGhost to capture HID events and map them to things I want them to do. It provides some nice features like programmable on screen menus and many plugins for specific apps like XBMC (it uses XBMC RPC API). To capture events from HID device a Generic HID plugin must be used. Unfortunately there is a small problem with this plugin and it sometimes sends multiple HID events on single button press (this is not the same problem as with repeated keys). I have a modifier Generic HID plugin that works very well with Flirc in this mode of operation. I can share it if there is a demand for it. I can also extend the how-to to some basic EG configuration. I haven't used AHK but I know that there is also a way to capture HID events in it and use them to control things. All the numbers I'm referring to are taken from this document http://www.freebsddiary.org/APC/usb_hid_usages.php