Jump to content
Flirc Forums

All Activity

This stream auto-updates     

  1. Past hour
  2. 1. The config is applied to the dongle, not on the computer. 2. Yes, it stays with the dongle when moved 3. Yes, install on the destination machine, or you can reach out to me directly, and if planned together, you can purchase custom units pre-loaded in white label boxes.
  3. Today
  4. We are deploying 150+ mini Windows 10 PCs that display a whiteboard and TV web app in hospital patient rooms. We built a configuration file for the USB dongle and include it in the deployment image, but have noticed that we have to manually apply the config file through the GUI whenever we install a box - is there a better way? Is the config file applied to the USB dongle itself? Will it "stick" if I unplug the dongle and plug it into a new box that has the flirc software installed? Is there any way to automate this deployment so the config file can be applied on first plugin? We have the rest of the windows image/build automated.
  5. 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
  6. Nothing I can do about two. You need to learn without your phone present, and then it should work fine. Can you confirm?
  7. 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.
  8. 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?
  9. Yesterday
  10. 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.
  11. 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).
  12. 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
  13. Go to File->Device Logging. Enable device logging. Let's see what kind of noise it's picking up.
  14. 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
  15. Last week
  16. Hello! Any progress or status update on this? Since then I tried with another remote (Hauppauge) with the same problem.
  17. 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
  18. 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.
  19. 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 ?
  20. 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! :)
  21. 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
  22. Earlier
  23. 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
  24. 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.
  25. 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,
  26. 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!
  27. 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.
  28. 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. :(
  29. 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?
  30. On my GUI, go to controllers->media keys. There is a suspend key there. Try that, and let us know.
  1. Load more activity
×
×
  • Create New...