yawor
-
Posts
1,003 -
Joined
-
Last visited
-
Days Won
74
Posts posted by yawor
-
-
Just to be sure, as you've mentioned loading the old config and saving it to the new Flirc. Exactly which options are you using? You should plug just the old Flirc, then save configuration (it saved configuration from device to a file), then unplug old one and plug in new one and finally load configuration (it loads configuration from a file to the device). Is this exactly what you're doing?
-
@Kevin Cowans good find. So it's some kind of hardware conflict. Unfortunately I also have Logitech Unifying receiver (with 3 devices paired to it) plugged in to my PC and both Logitech SetPoint (for K800 keyboard and MX Performance mouse) and Logitech Options (for MX Master mouse) software installed. I see that the K830 is a newer hardware which also requires Options software. I wonder if you maybe have some newer revision of the Unifying receiver.
Can you do a test and remove pairing (in Unifying software) between your receiver and the keyboard? Then make a test with receiver plugged in but no K830 present in the system. After that you should have no issues with pairing it back to the receiver.
-
Even it would in be as fast, a virtual remote is still a massive pain the rear.
Nothing can beat a remote with physical buttons :). Especially one with good key layout which makes it easy to control your equipment without looking at the controller.
-
1
-
-
I've tested 4.0.12 on my PC (with Win 7) and it wakes 100% of times using remote from both sleep and hibernate. After wake up, the Flirc is still responsive and is able to wake the PC again (without unplugging it and plugging it back of course). I've tested this with different sleep time spans (1 hour, 2 hours, over night etc).
I've also tested waking from sleep on a laptop with Linux and it also works without issues. Unfortunately I can't test hibernation (suspend to disk) mode because my laptop freezes during wake up from that mode (not related to Flirc, it's an issue with the hardware incompatibility with Linux).
I think it's either related to some specific hardware configurations or something environmental. With 1st gen Flirc, for example, there were issues in some cases if a controlled device wasn't connected to properly grounded mains connection. We've spent a lot of time trying to resolve the issue, but in the end fixing a ground connection resolved the issues. I don't say that this is a case here, just giving an example. Maybe there are some random power surges or voltage drops when the PC enter sleep or hibernation causing Flirc not to respond. Unfortunately there's no easy way to test this hypothesis unless you own (or have access to) an oscilloscope to capture the behaviour of USB lines (especially the 5 V one) during entering suspended state.
-
Yeah. Flirc has a really good sensitivity and doesn't need to be in a direct line of sight :). In my setup, I have RPi 3 with Flirc mounted behind my TV (which is hanging on the wall). There's no direct line of sight at all but remote works with 100% accuracy. This is true for both old and new Flirc.
Thanks for posting a solution to your issues.
-
Can you add Flirc/Kodi to your Harmony and test if Flirc recognises each key separately?
-
It seems you have the same or similar issue to one described in thread linked below.
I'll be replying there as there's no point to keep this it two separate threads. Please check it and reply there.
-
@BTSpaniel, have you updated to the latest firmware? Current firmware version is 4.0.10 and software 2.3.0. I think Jason fixed the sticky keys issue.
Also there's no old software for new Flirc, as new Flirc is a totally different hardware platform compared to the old one. It can't just run old firmware.
-
@ixian I don't think this is a matter of manufacturers sharing IR protocols. It's a matter of transfer medium and how easy/hard it is to analyse the signals. To analyse even some new IR protocol you should be able to do that using equipment that costs less than $20-$30. There's really not much variance between different protocols: they can vary in carrier frequency, timings between bursts and lengths of the bursts themselves. The only issue may be in decoding how to interpret these bursts as ones and zeros. Medium (as in IR light) is relatively easy to work with. Also it's usually a one way communication so you don't need to track it in both ways. Actually you really don't need to even decode the original command and use different techniques to just create your own information from detected timings. Flirc works like that. Most of the generic IR receivers (non-MCE) that can capture almost any remote work like that. Unfortunately there are some protocols which send the same command code with varying signals (so each button press sends a signal that is somehow different from the previous). RC-5 is such protocol for example. It changes a single bit between presses. That's why you need to record each key twice in Flirc if you use RC-5 protocol (like MCE).
BT is at a totally different level. You have bi-directional communication. BT remotes usually are first paired to the target device (so the remote knows BT address of controlled device and the device knows the BT address of the remote). Pairing can be a standard one (like in case of PS4) or proprietary (like in case of LG Magic Remote). After that you need to know how a device is controlled. This can be done with different BT profiles (serial profile, HID profile, Bluetooth Low Energy, etc) where each profile has totally different setup and way of working with. Hardware which allows to capture and analyse BT traffic is horrendously expensive. Medium (as in RF @ 2.4 GHz) is not easy to work with because there are other protocols also working in that band (mostly Wi-Fi).
@Hotwire I still think that the best approach with BT would be to use BT adapter. But it requires some work to be done. First of all you need to find out what's the control scheme of specific BT remote and if it's possible to pair it with generic BT adapter. Then some software would be required to translate BT commands into commands usable on the target device. There's also a chance that the remote uses HID profile and at least some keys can work without additional software (like direction keys).
-
1
-
-
Do you have USB debugging enabled? If yes, then disable it.
-
Ah so it's not a problem with remote. Now I understand what's your problem. To configure Flirc SE power button feature you need to use command line utility flirc_util.exe. The command has been posted in this thread already:
flirc_util.exe record power
After pressing enter, the command will wait for you to press a button.
-
It depends. If you want to have a different set of keyboard assignments in Flirc (for example one activity for Kodi and another one for some other software), then you need something else than Flirc/Kodi. You can add one of the other Flirc/* profiles (I don't tell you what they are as I'm not up to speed with Harmony) or almost any other hardware profile. For example you can use a profile for some TV model - it's only important that it's not a profile for the TV or other hardware you already have at home :). I would also not use any Windows Media Center edition profiles.
-
Yes, you can. You need to add another device profile to Harmony (different than your current profiles) and then record and assign remote's buttons to keyboard keys you want (of course with new profile active on the remote).
-
I can't find any detailed information about this remote. Do you know for which TV model is this remote?
-
Flirc has nothing to do with Bluetooth.
Do you have USB debugging turned on? If yes then you need to turn it off for OTG to work.
You can also test if OTG works properly by connecting a standard USB keyboard to your Nexus Player and check if you can control it with the keys on the keyboard. Flirc acts as a keyboard so if a real one can control the device then Flirc should also work.
-
@Budwyzer No such function yet, sorry :). Maybe there's a chance for something like this with the new Flirc USB (2nd gen) as its hardware is much more capable than the old one. But new hardware brings new challenges and there are still some issues to work on before Jason starts adding new features.
-
As you probably know, Flirc acts as a keyboard. You can do anything (or almost anything) with Flirc which you can also do using a keyboard. Can you do what you want with a keyboard? Probably not, but I'm not a Windows expert.
Also please remember, that anything Flirc can do, a standard keyboard is also probably capable of, so if you manage to somehow add some shortcut in Windows which would skip the logon screen, then the same shortcut used on a keyboard would also do the same.
-
Yes, I know what advantages it would bring. It's not my decision to make of course, but to be honest, I don't see that ever happening.
- First of all, Logitech probably has agreements with all manufacturers which they support with their BT remote control. That gives them an access to protocol specifications. I don't say it's impossible, but certainly hard for a small company like Flirc to get such an agreement from big TV appliance producers.
- Every manufacturer uses rather their own control protocol. Flirc would need a separate support (in the firmware) for each manufacturer's BT remote control. This is NOT standardised in any way.
- This applies at least to Samsung and LG (I don't know about others): BT TV remotes still require an IR to turn the TV on first as they don't support turning on over BT. This means that the remote won't send a BT command for power button.
I hope I'm in the wrong here though as that would certainly be a nice feature. But I won't hold my breadth.
-
1
-
@fredfred I think there's really no problem with Shield itself. It's just an Android device after all. The problem is with different applications you want to run. Whether they respect a keyboard input or not. Or how complete is the keyboard input support. If a specific app lack support of keyboard events (or is incomplete) then there's no way to properly control it using Flirc.
BTW a question to Shield users. What is the current Android version on the device? Does it allow installing software from other sources (e.g. from the apk file)? I'm thinking that there may be a way to write a background service application which would then map keyboard input to other input events depending on the application which is in focus.
-
Wouldn't it be simpler to just use USB BT adapter (or built-in one in case there is one)? You've presented a single example (PS4) where the protocol description is actually available. Adding whole BT stack to Flirc just for PS4 is not very good idea in my opinion. Do you have more examples of BT remote interoperability between different producers?
As an example, I have an LG magic remote for my TV. It uses BT. I've been trying hard to pair it with my PC without any success. I assume it's exactly the same situation with other producers.
-
Guys,
Please read what Jason is saying. I've also posted this multiple times already. Advanced options are not available for new Flirc USB because they are not needed. It's not an error that they are greyed out when new Flirc USB is connected.
-
@H8me you have everything describe in this topic. Read it through first (maybe even few times). Also let us know what keyboard layout you are using.
-
2nd gen doesn't give much advantage right now (it basically has the same features as 1st gen), but its hardware is capable of much more things in the future. Thanks to much more config space on the chip, things like key sequencing (sending not only single key, but a sequence of keys) will be possible. Also 2ng gen contains IR transmitter hardware on board. It's not yet active but it's something I'm eagerly waiting for myself.
-
BT remotes require pairing and they usually use a proprietary protocols. I don't think there's any possibility to support such devices.
Transfer "old" configurations to a new Flirc dongle
in General Questions
Posted
Ok, I've just checked this myself and there's really some problem with config loading.