Jump to content
Flirc Forums

yawor

Administrators
  • Posts

    1,003
  • Joined

  • Last visited

  • Days Won

    74

Everything posted by yawor

  1. Hi, As long as you are aware that you need two separate device profiles on the remote (use different device brands to be sure) you won't have any problems with such setup. If you are going to use a built-in profile on one Flirc remember to disable it on the second. For programming purposes plug in only one Flirc at once to your computer.
  2. Hi, Back is a function that makes the application "go back" to previous menu or screen. What button on the remote you record for that function depends on the remote itself. For example I have a "Back" button on my remote so it is obvious that I'm using it. But it would also be OK to record return, escape or exit buttons as back key, or even some totally different button - it all depends on the available remote buttons, their layout and personal preferences :). BTW the actual key behind the "back" key in Flirc depends heavily on the controller you select. I don't know what key is assigned for back key on minimal setup, but for example on XBMC controller the back key is a backspace key. On the other hand for FireTV controller the back key is a "browser history back" key.
  3. The software version 1.3.4 includes firmware 3.5 :).
  4. I see at least one issue when it comes to a XBMC profile in Harmony - there are many Harmony models and they have different buttons (besides most common ones) and layouts. I don't know how Logitech is managing that but I think it's extremely hard to support all their remotes in a way that all users are happy from the way the keys are mapped to device functions. I would also like that but I see here two issues: 1. Flirc saves HID codes, not keyboard scan codes. This shouldn't really be a problem because the software already needs to know them to record them in Flirc. 2. All Flirc and its software know about your remote are the hash values of the IR signals sent from remote for each button. So unless someone make a big database of hashes (compatible with Flirc) or IR signals for different remotes all you can get is the hash, not the name of the button.
  5. It's a little strange that the reboot was required. McButton have you tried unplugging and plugging the Flirc back after upgrade before trying to reboot?
  6. I could be wrong but I think there was a backward incompatible firmware change somewhere between 2.0 and 2.5 and it was required to clear the config and record all the buttons from the beginning. The same thing happened with firmware 3.x (it's not compatible with buttons recorded on 2.x). I think that the best way now is to upgrade to latest software and firmware, clear the config and record again. You could stay on 2.5 if it works for you but then you would need to repeat everything again when going to 3.x.
  7. This was originally found out and suggested by Jason. There is a big chance, that when pointing a remote directly at Flirc from small distance when recording, the signal received by Flirc is distorted because it is too strong for receiver signal range - something like an overdrive effect for electric guitar. Because of the distortion Flirc stores different value for this signal than it would when operated from a normal distance (couple of meters usually) when the signal is received correctly. The solution is to record the signal from a greater distance or not to point the remote in the direction of the Flirc but at a wall or ceiling where the signal will bounce and return to the Flirc. In my opinion the best solution is to record buttons from the location where the remote will be used in normal operation so there are almost no variations to the signal.
  8. To be honest I even didn't know about this :). But I think that this feature was implemented in 2.x firmware. In 3.x Jason has re-written a big portion of the firmware so there is a chance that this particular feature has been omitted (probably by accident). We need to wait for his response to be sure. I would assume that configuration is stored in EEPROM memory as it's easier to write into it than to the Flash in this particular microcontroller - EEPROM is byte addressable and writing only require erasing bytes that are written, but the Flash is written in pages and require erasing whole page before writing even a single byte into it. Flash memory stores the bootloader and firmware.
  9. You can't do that directly, but there are some ways to work around the problem: 1. Use an universal remote which can control multiple devices - you can decide which device on the remote control which application and then record the buttons accordingly. To control different app just select different device on the remote. + you don't need additional software running on the Windows - you need to use a device on the remote for each app you want to control (or even buy a new remote if you don't have an universal one right now) 2. Use some automation software between Flirc and the apps you want to control like AutoHotKeys or EventGhost. Record buttons once but use some unused key combinations (with shift, alt, win and ctrl) and then map those combinations in the software to different apps. In the EventGhost you can use a plugin to automatically activate and deactivate action groups depending on which app you currently have in focus. + it is a very flexible solution that can achieve much more functionality than the Flirc alone + you can use your current remote - you need to run additional software on the Windows - you need to find keyboard shortcuts that are not used by other software so you can capture them in the automation software
  10. He probably could, but then he would need to keep rpm version up to date himself and this would probably require to keep an RPM based distribution to prepare the package or even keep a yum repository. I think there is nothing wrong with third party repackaging and keeping it as external repositories. For example Flirc software is already available in AUR which is Arch Linux User Repository and have a maintainer there and its going into official Arch Linux repositories sooner or later.
  11. Flirc can't do that by itself. You need some other software for this. There are already some threads on the forum how to do that. Take a look here
  12. There is no such function right now neither in the Flirc's firmware nor the software. There may be something in the future (to make debugging problems some people are having with their remotes/setups) but I don't know what priority it has (only Jason knows this). It's even possible that this won't ever be in a public release, but some special debug firmware version. What do you need the raw IR signal anyway? Do you want to feed it to some IR blaster or create Pronto codes? I think there are better devices for achieving this as Flirc is very specific device for creating working IR control setup very fast without the need of any runtime software on the host, as it acts as a keyboard in the OS. For example my remote (OFA URC-6440) has IR receiver built-in as it has a learning function. I can learn a signal from other remote and then download config to RemoteMaster software which is able to decode learned signal - you get what protocol is used and what payload is sent. This data can be used to recreate original IR signal (for example to use it in IR blaster or send by the remote itself).
  13. I know RemoteMaster :). I'm also the newest member of the RMIR developers team but I'm focusing on the SimpleSet remotes (like European URC-6440 or US OARUSB04G). I like my URC-6440 as it has a fairly good set of buttons with nice layout and backlight. With recently finished Extender for this model this is one of the best OFA/EUI remotes to date and it's very cheap (I've paid for it about $20 in local electronics retail shop in my country).
  14. Basically you need to find a remote configuration which won't interfere with your other hardware (like TV etc) and will send a code for every button on the remote. Many devices don't need all the keys on the remote so universal remotes deactivate some of the buttons when they're not needed for specific device. Second criteria for choosing remote config is IR signal protocol used by the device. There are many different protocols but I personally like to use a device with NEC1 protocol. For example (at least some) newer LG, Samsung and Panasonic devices use this protocol. Also try to set up the device as TV as they usually have all the remote keys active. I'm using One-For-All URC-6440 remote and I've set a Samsung TV code on PVR device button for use with Flirc and all the keys are active and send unique signals. Of course I don't have a Samsung TV so I don't need to worry about Flirc interfering with my TV.
  15. Hi, When you record keys please record them either from a larger distance (1-2 meters or 3-6 feet) or point the remote at the ceiling instead of directly at Flirc (so Flirc will catch reflected signal). Flirc's receiver is very sensitive and it's easy to overdrive the signal: when it's too strong it will be distorted and won't work very well.
  16. Does the AC Back work on Windows or Linux in a browser? I don't know if this require some extra xorg configuration for those buttons to work properly under Linux.
  17. By "modified Generic HID plugin" I mean that I've copied original Generic HID plugin code, changed its internal ID and name (added a suffix to its name) so both plugin versions can coexist in a single EventGhost install and changed the code so it works better with Flirc sending custom HID codes. The EventGhost differentiates between single events (short events) and enduring ones, which can have extended length. The original HID plugin for EG uses only short events so when you hold down the remote button you get a lot of short events. I've modified the code so HID plugin is generating an enduring event for as long as you keep the button pressed, so you only get a single event but it is active as long as you keep holding the button down. That way you can define repeats and long-press actions in the EventGhost without any problems. You can download the plugin here: https://www.dropbox.com/s/j7ajh7rvoa2qpa9/MyHID.zip?dl=0 Go to the folder where you have EventGhost installed. You'll find plugins folder there. Unpack the downloaded zip to the plugins folder (it should create a MyHID folder). You can compare the __init__.py file with the original plugin code in the plugins\HID folder. There are only a few changes so it's easy to check that there is nothing malicious added in the code (even for non-programmers I think). To use the plugin in EG you need to first restart EG for it to see new plugin. Then you add "Generic HID (mod)" plugin to Autostart folder in your EG config. You need to select Flirc from the device list in the plugin config window. There can be more than one device there so you need to do some testing which one works. You can also enter a prefix into Event prefix text input (I've set it to Flirc). I'm also using Remote event mapper plugin where I map Flirc.Button.X (where X is the HID code) events as Remote.YYYY (where YYYY is given button name like Play, Pause etc). That way I don't need to remember under which HID code I have a specific button mapped in Flirc. The rest of the EG config is very specific to my needs. Of course I use XBMC2 plugin to control Kodi using remote API and also I use Task Create/Switch Events plugin to enable/disable actions groups depending on the app in focus (you don't need that if you want to control Kodi out of focus).
  18. The delay is not introduced by the Flirc itself but by the operating system's keyboard settings. Flirc just tells the OS that key is held pressed and when it is released. Until you can set these params separately for cursor keys in your OS I think there is nothing that can be done on the Flirc side.
  19. I'm using this setup (flirc with hid keys and EventGhost with generic hid plugin) for quite some time now and I don't see any outstanding issues with it. I don't know how well you'll be able to run htpc in dual monitor mode with both displays active at the same time. I think that xbmc/kodi exits full screen mode when you click something on second monitor. I can share my modified generic hid plugin when I'm back at home in couple of days.
  20. Yes, you are correct :). For loading your config into another Flirc you just need to be sure that firmware versions on Flirc you are saving the config from and the one you are loading it to are compatible. For now firmwares 2.x and 3.x are not compatible with each other because IR signal recognition algorithm has changed in 3.0. Loading the 2.x config won't break the 3.x unit but it won't recognize recorded key presses.
  21. As those are universal remotes you can use any IR protocol depending on the selected device's manufacturer, model and type. Some IR protocols, like RC-6 (used by Microsoft's MCE remotes for example) use alternating signals for each button press. I don't know what "irw" is exactly (I'll assume it's an IR receiver) but maybe it's able to recognize the protocol and decode its payload (function code) instead of using the raw signal. The function code should be the same on each button press. You don't need to format your Flirc. Find the button that works every second time and record it again in Flirc GUI to the same key combination it was recorded before. If you get error that the button is already recorded do it one more time (you can actually try multiple times just to be sure - if you start getting the error every time then all its signals are already recorded).
  22. Hi, Galaxy S5 has a built-in IR blaster. Maybe there is some setting that keeps sending something with it all the time (or you have some software installed that does that). I don't see any other reason.
  23. Unfortunately, with current Flirc possibilities, you can't access keys from HID Customer usage table with codes above 0xFF. Each recorded button takes 6 bytes: 4 bytes for IR code hash and 2 bytes for the HID code. To use codes from Customer usage tables the second byte must have value of 102 (decimal) so you only have a single byte for key code. To address 0x224 you would need 2 bits extra. I think there are 2 possible ways (both require changes to firmware and software): 1. Extend structure from 6 to 7 bytes to allow bigger code space - this unfortunately would mean that the capacity would drop (from current 169 to about 144 from a quick calculation) but I think it would be a waste of space because there are not so many usage cases for those codes (so in most cases the additional byte would always be 0) - this requires changes to both firmware and software. 2. Add extra markers like the mentioned value 102 (0x66). There is for example a key code 101 (0x65) - Keyboard Application - I don't think there are any usage cases for this key to be used with Flirc. Using this value as a key code could send a key from Customer usage table with code 0x100 + modifier value. There are also F13-F24 keys that, at least on Windows are not usable anyway, so their codes could also be used as more markers to bump the value higher. To sum it up: - For key code 0x66, send modifier value as a key code from Customer usage table, - For key code 0x65, send modifier value + 0x100 (0x100 to 0x1FF range) as a key code from Customer usage table, - For key code 0x73 (F24), send modifier value + 0x200 (0x200 to 0x2FF range) as key code from Customer usage table. With values from above proposition you would be able to record AC Back button using: flirc_util record_api 36 115 It all depends on whether or not Jason can/want to implement this. This also only require a change to the firmware. No software changes would be required.
  24. You don't load the config into GUI. It is loaded directly into Flirc. So you just need to connect next Flirc and select Load configuration from menu or use flirc_util loadconfig command and that's all. You don't need to do anything else.
  25. I've been wondering if having a built-in profiles in current form is really a good idea. I know that it allows a fast start if all someone wants is to control XBMC with Harmony (it only requires from the user to set up the Harmony remote with correct profile), but on the other hand it probably takes some space in the flash memory which could be used for some other functionality, given that the micro used in Flirc doesn't have it that much. There are also other problems like for example differences in key shortcuts between software versions - like right now there are differences between XBMC and Kodi so it would require a new Harmony profile with at least some codes different from current one. I think it would be better to remove built-in profiles and ship Flirc with pre-programmed one for XBMC/Harmony setup (if this is main reason for the built-in profiles to exist in the first place). Profile definitions could be defined in some file format loadable by the Flirc software. It would be even better if the profile definition could be in some easily editable format like ini, so the community can create new profiles by themselves. There could be two types of ini files: remote definition and application definition. Remote definitions would assign a set of names to hex hashes of IR signals each button creates (with an ability to assign multiple hashes to a single name for MCE/RC6 remotes and other similar) - one file per remote model. Application definitions would assign a name of function in the app to a key combination (could be in the same format as for record_api). It could also provide default remote button name (from remote definitions). Flirc app would need to allow selecting a remote profile and app profile pair (or even more pairs if capacity still allows to store multiple mappings). There will be of course situations that some remotes can have more or less buttons or even different button names so the Flirc app itself would need to allow customization of function to button mappings (for example by displaying available functions and providing dropdown with button selection). Changed mappings could be saved as new app profile in user profiles dir (given that there are Flirc provided profiles and user profiles kept separately).
×
×
  • Create New...