Jump to content
Flirc Forums

All Activity

This stream auto-updates     

  1. Past hour
  2. I'm trying to use a Silex DS-510 to allow me to network separate my PC and my Flirc over the LAN. The server sees the device just fine, but when I try to run the Flirc GUI to set up keys it crashes. Any suggestions (other than, don't use the Silex)? Fault bucket 1792742314677437130, type 1 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: Flirc.exe P2: 1.0.0.0 P3: 5e38d875 P4: Flirc.exe P5: 1.0.0.0 P6: 5e38d875 P7: c0000005 P8: 0004bad0 P9: P10: Analysis symbol: Rechecking for solution: 0 Report Id: 97137a67-c15d-11ea-979a-78929ce073dc Report Status: 0 Hashed bucket: 2167b6484183aa8928e119a3082902ca
  3. Today
  4. Nothing I can do about two. You need to learn without your phone present, and then it should work fine. Can you confirm?
  5. Sure. :) Both problems remain: Flirc (including Firmware 4.9.4) does not emit KEY_SLEEP (page 7, keycode 142), thus I cannot put by projector into standby as intended, and I suspect the reason is that the HID device "flirc.tv flirc Keyboard" does only announce code 1..127 to be supported. When my phone lays open in the same room, I am not able to reliably control the dori Flicr (or even have my notbook computer in suspend mode if Flirc is attached), as it goes bonkers over my phone's proximity sensor.
  6. Yeah that’s really interesting about the phone. I wouldn’t have suspected that. Sensitivity is the same. It’s the same sensor. A better algorithm. It’s not as responsive because it’s less “slippery”. It’s more consistent about button presses and when you let go real quick or when you are holding it down. i don’t follow the remaining problems. Can you summarize?
  7. Yesterday
  8. The device laid on a low coffee table about 3m (~10ft) away from me, in the opposite direction of the Flirc sensor window, which is quite distant, I think. The living room is ca. 65m² (~700sqft) with both white ceiling and floor, but coloured walls and dark furniture. I did not experience any problems with IR controlled devices so far.
  9. I just found out that my notebook immediately wakes up from suspend if the Flirc is connected, but does not if I cover the Flirc. Using this I found that the problem is not caused by my notebook's screen, but by the IR LED of the proximity sensor of my Samsung Galaxy S9, which is used to determine whether the always-on display shall be active (uncovered) or not (covered). The signal seems to have been reflected by the ceiling. Once I cover the phone's proximity sensor, the Flirc responds to remote button presses quite well, even if I direct the remote in the opposite direction (although subjectively it seems to be not as responsive as I experienced with the Flirc Gen 1 devices).
  10. HI @jason, I enabled IR debugging and recorded a few seconds, log attached. When I hold my hand between notebook screen and Flirc, the output stops. Best regards, // Veit my_flirc_log.txt
  11. Go to File->Device Logging. Enable device logging. Let's see what kind of noise it's picking up.
  12. Hi @jason, I purchased a Flirc Gen. 2 Dori and it was delivered today. On it I installed your firmware, but it did not work; I still can record KEY_SLEEP using "flirc_util record_api 0 142", but nothing is being submitted when the bound remote button is pressed. I suspect this is caused as the device only reports event type 1, event code 1..127 being supported, thus other codes might be ignored by the driver: Input device ID: bus 0x3 vendor 0x20a0 product 0x6 version 0x101 Input device name: "flirc.tv flirc Keyboard" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 1 (KEY_ESC) Event code 2 (KEY_1) ... Event code 126 (KEY_RIGHTMETA) Event code 127 (KEY_COMPOSE) Event type 4 (EV_MSC) Event code 4 (MSC_SCAN) Key repeat handling: Repeat type 20 (EV_REP) Repeat code 0 (REP_DELAY) Value 250 Repeat code 1 (REP_PERIOD) Value 33 Properties: Could you add code 142 (KEY_SLEEP) to this list for testing, please? Furthermore I have the issue that my brand new Dori recognises something within my living room as IR input, which means for programming I need to shadow the Flirc so it only sees the remote that I want to program a key from. Also remote key presses are only detected reliably if I hold the IR LED of the remote directly (0-3cm) in front of the Flirc's sensor window or shadow it again. None of my set of 3 Flirc Gen. 1 devices showed this behaviour, neither while recording nor while interpreting key presses. They just worked and recognised remote button presses no matter in which direction I pointed with the remote. I have switched off or covered all artificial light sources in the room (projector, ambient lights, LED clock, harmony hub, keyboard illumination, internet router LEDs, ...). I am sitting in an almost completely dark room now, only some moon light thru the window and my notebook screen dimmed to minimum, but the problem persists. I suspect the notebook screen to be the cause, as even though it is dimmed to minimum and almost unreadable, the remote button recognition increases if I put my hand between screen and Flirc. It does not seem to be a PWM flanking issue, as turning the screen to maximum brightness (which I suppose to source the backlight without any PWM signal downs) almost completely kills remote button recognition even if I put the remote's LED in direct contact with the Flirc's sensor window. Any help is appreciated. Best regards, // Veit
  13. Last week
  14. Hello! Any progress or status update on this? Since then I tried with another remote (Hauppauge) with the same problem.
  15. I think it would be amazing if a new Flirc case came out for the Pi 4 that provided easy access to not just the GPIO sockets, but also the camera and touchscreen sockets. Any news about whether this possibility is upcoming and if so, when? <3
  16. Yes, unfortunately this is a version 2 only feature. It definitely wont work on version 1 due to various limitations, and I have no intention on doing anything other than maintenance releases for gen1 devices.
  17. So apparently if I do a mpc toggle to stop the music, send the volume up/down IR code for instance and mpc toggle to carry on playing it will work but having the music interrupted each time I change the volume is not ideal. Nobody else went through this issue ? No fix ?
  18. Hi @jason, thank you very much! I am new to Flirc, thus having a question on the upgrade process: All my three Flircs seem Gen 1 devices, the SKU reported for all of them is "flirc", not "dori" or "nemo": $ ./flirc_util version 3.25.3 FW Version: v3.11.0 SKU: flirc Hash: 0xA41ECA3A The FW version (though the GUI tells me is the latest version) is one major off. Is my assumption correct that both dori and nemo are Gen 2 devices, which run on FW 4 while "flirc" run FW 3? If yes, could we please get a FW 3 with the HID code limit removed, too? Thanks in advance and best regards! :)
  19. It's not the CLI that needed to be updated, but the firmware No guarantee this will break something else. I've updated the report ID so that you can go as high as 255. Try it and let me know. dori.release-4.9.4.bin nemo.release-4.9.4.bin
  20. Earlier
  21. Hellou everyone. Bought 2 Flirc devices newer generation and they are just sitting now and catching dust. The Flircs specs say 1 IR transmitter, 1 IR receiver. Is it possible to catch the ON/OFF codes from my AC remote and try to turn ON/OFF my AC with FLIRC? Can someone tell me if that for some kinda reason is not possible? p.s. not at home to try it out... but was devastated after searching for options to Smartify my old AC, and I remembered that I have 2 flirc devices :) Anyways, thanks to anyone who responds
  22. Use this guide to derive the HID page and key code of an HID event device or original remote connected e.g. via USB, I2C or Bluetooth to a Linux PC, or to verify that your Flirc actually sends the events you expect. HID page and key code can be grabbed under Linux following these steps: 1. Find the event devices associated with your HID devices using "udevadm info -a <device>" with <device> walking through /dev/input/event*. There might be multiple devices for a single hardware component, e.g. for a Harmony Hub there is one for HID mouse events, one for HID keyboard events, one for HID consumer control events, one for HID system control events, ... 2. Monitor the desired event devices (usually requires root) using "sudo evtest [--grab<] <device>" for each device required. The optional parameter "--grab" is essential if you want to stop the recorded events to be forwarded to and interpreted by the system, like I did to stop my system going into standby whenever I sent the sleep event that I wanted to record. If you want to use "--grab" on your local keyboard or such, you might want to either attach a second keyboard or run the command over the network via SSH, so you can abort the monitoring by sending Ctrl+C. 3. Perform the key presses on the device you want to record. Each key press will emit 2 events, one for key down (press), one for key up (release), example output for the "0" key: Event: time 1593381762.020128, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70027 Event: time 1593381762.020128, type 1 (EV_KEY), code 11 (KEY_0), value 1 Event: time 1593381762.020128, -------------- SYN_REPORT ------------ Event: time 1593381762.020198, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70027 Event: time 1593381762.020198, type 1 (EV_KEY), code 11 (KEY_0), value 0 Event: time 1593381762.020198, -------------- SYN_REPORT ------------ 4. Interpret the output; you are interested in the value of the MSC_SCAN (scancode) of EV_MSC (miscellaneous) events. The value is hexadecimal and for HID devices with the last 4 digits being the HID key code (0x0027) and leading digit(s) the HID page (0x07). 5. HID page 0x07 events (HID keyboard) can be programmed using "flirc_util record_api <modifiers> <key code>", where <key code> is the decimal representation of the HID key code you fetched above (e.g. 0x27 = 39), and <modifier> is a logical or-ed list of modifier keys to be held down while <key code> is sent (see "flirc_util help record_api"). I ran into an intentional limitation of flirc_util, limiting <key code> to values <= 101. Unfortunately, flirc_util silently programs the key anyway without a warning, leaving a key that is never sent. This cost me a lot of time while trying to send the correct codes to my hardware, being the Flirc the culprit by never sending the programmed keys. Jason is currently checking whether the limitation will be removed.
  23. hey all, I have a MyGica KR301 remote that i would love to use with my flirc to control a home theatre PC. the remote is perfectly suited to this task as it has a standard remote on one side and a keyboard on the other. i have been using FLIRC's for a long time and am no stranger to the set up. when i trier to get the flirc to learn the keys of the MyGica remote i ran into trouble. for some reason the keys would not pair. Help please. Thanks,
  24. This is a thing that I already tried before posting this topic. It works in that way that it causes my projector to open the shutdown menu, which allows me only to perform a full system shutdown. But what I want to do is putting it in standby, and I extracted the way how the Harmony Hub does this when using the "NVIDIA Shield" configuration (*not* "NVIDIA Shield TV") vial Bluetooth, which works but BT connection is unreliable. This configuration emits HID page 0x07 (keyboard) code 0xf8 (KEY_SLEEP). At least key codes >101 / >0x65 are used widely for system control keys in keyboard page in both Linux and Android, according to Android's HID documentation: https://source.android.com/devices/input/keyboard-devices I assume that the Linux kernel devs did not make these codes up but derived them from real-world hardware. In the basement I just found this wireless keyboard from Grundig whose USB receiver also emits page 0x07 code 0xf8 (KEY_SLEEP) instead of Sleep from the consumer page when pressing its standby button in the top right corner: Event: time 1593216654.871345, -------------- SYN_REPORT ------------ Event: time 1593216656.276019, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700f8 Event: time 1593216656.276019, type 1 (EV_KEY), code 142 (KEY_SLEEP), value 1 Event: time 1593216656.276019, -------------- SYN_REPORT ------------ Event: time 1593216656.351066, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700f8 Event: time 1593216656.351066, type 1 (EV_KEY), code 142 (KEY_SLEEP), value 0 Event: time 1593216656.351066, -------------- SYN_REPORT ------------ So unlimiting flirc_util would be greatly appreciated. :) Best regards!
  25. no, it wouldn't be in the HID table, it would be in the consumer table, which is a valid system wide table for system control, and should work. My keyboard report is limited to 101, artificially. I could extend this, but I would need to look into the impact. Anything above 231 is reserved.
  26. Hi Jason, thanks for the hint, but the suspend button does not emit HID page 0x07 code 0xf8, thus does not work for my purpose. :(
  27. Using evtest I found out that the Harmony Hub emits HID page 0x07 code 0xf8 (KEY_SLEEP), thus using "flirc_util record_api 0 248" should record a key that emits this button press. The key gets recorded by the command without any error or warning, but also using evtest I found out, that the button press is actually not emitted (nothing is emitted at all). This is not limited to key code 248 but seems to be true for every key code >101. Is this a bug in flirc_util or in the Flirc firmware?
  28. On my GUI, go to controllers->media keys. There is a suspend key there. Try that, and let us know.
  29. Hi, I just bought a Flirc to finally get control over my Xiaomi Laser TV. It is an Android TV based projector that I currently control using a Harmony Hub via Bluetooth, but the BT connection is not reliably established, so this is where Flirc shall get into the game. I was able to set up all keys using flirc_util recory_api and both the HID Keyboard/Keypad and Consumer pages from the Android documentation [ https://source.android.com/devices/input/keyboard-devices ] and the USB.oro and FreeBSD HID documentation except for the PowerOff button, that should put the device into standby mode. Unfortunately all the Power/Sleep/Coffee/Screenlock keycodes from the docs either let the shutdown menu pop up (which does not allow activating standby but only full system shutdown), or have no function. So I tried adding a new "NVIDIA Shield" (not Shield TV) device, which emits the correct PowerOff command via BT, to the Harmony Hub and pair it with my Linux PC to try and extract the keycode using e.g. xev. Unfortunately, sending this command to my PC via BT immediately puts it into sleep mode without logging any keypress, even after removing the corresponding keyboard bindings from the GNOME settings and systemd-logind. Also issuing the PowerOn button only emits the character "0" (== keycode 102, which is used for all keycodes from HID page 0x0c), but not the required modifiers which encode the actual command on page 0x0c. So I have to assume that the PowerOff button will give me unuseful information, too. Any help or hints on either how to capture the required HID data for this key from BT further commands to try beside those from https://source.android.com/devices/input/keyboard-devices pages 0x07 und 0x0c how to encode further HID pages such as 0x01 generic system commands with flirc_util record_api is greatly appreciated. Thanks in advance! UPDATE WITH SOLUTIONS TO MY REQUEST ABOVE (for anyone running into a similar problem): HID page and code can be grabbed under Linux following these steps: 1. Find the event devices associated with your HID devices using "udevadm info -a <device>" with <device> walking through /dev/input/event*. There might be multiple devices for a single hardware component, e.g. for my Harmony Hub there is one for HID mouse events, one for HID keyboard events, one for HID consumer control events, one for HID system control events, ... 2. Monitor the desired event devices (usually needs root) using "evtest --grab <device>" for each device required. The parameter --grab is essential if you need to stop the recorded events to be forwarded to the system, like I did to stop my system going into standby whenever I send the sleep event that I want to record. 3. Perform the key presses on the device you want to record. Each key press will emit 2 events, one for key down (press), one for key up (release), example output for the "0" key: Event: time 1593381762.020128, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70027 Event: time 1593381762.020128, type 1 (EV_KEY), code 11 (KEY_0), value 1 Event: time 1593381762.020128, -------------- SYN_REPORT ------------ Event: time 1593381762.020198, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70027 Event: time 1593381762.020198, type 1 (EV_KEY), code 11 (KEY_0), value 0 Event: time 1593381762.020198, -------------- SYN_REPORT ------------ 4. Interpret the output; you are interested in the value of the MSC_SCAN (scancode) of EV_MSC (miscellaneous) events. The value is hexadecimal and for HID devices with the last 4 digits being the HID key code (0x0027) and leading digit(s) the HID page (0x07). 5. HID page 0x07 events (HID keyboard) can be programmed using "flirc_util record_api <modifiers> <key code>", where <key code> is the decimal interpretion of the HID key code you fetched above (e.g. 0x27 = 39), and <modifier> is a logical or-ed list of modifier keys to be held down while <key code> is sent (see "flirc_util help record_api"). I ran into an intentional limitation of flirc_util limiting <key code> to values <= 101. Unfortunately, flirc_util silently programs the key anyway without a warning, leaving a key that is never sent. This is what initially cost me a lot of time while trying to send the correct codes to my hardware, being the Flirc the culprit by never sending the programmed keys. Jason is currently checking whether the limitation will be removed.
  30. I love the present configuration of the Flirc Case, but I think it can be improved greatly. One of the things I like less about the raspberry pi configuration is the mess of cables. I recently purchased an Argon One case and I really like it. In fact I considered replacing my Flirc Case with it until I realized that the USB ports now come out the back, thus rendering the remote sensor inoperative. The obvious solution is to have one of them routed by a hat to face front and have the sensor actually be embedded in the case facing the user or similar. As Pis become more powerful I see more people turning to them for more things. In my opinion the Pi still needs a lot of work done in the case area and I personally prefer the aluminum cases. These are just my thoughts. What are your thoughts?
  1. Load more activity
×
×
  • Create New...