Thanks Thanks:  0
Likes Likes:  0
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Processing Latency - Part 2

  1. #11
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Thanks for reminding me the two main repeater is ethernet on RadioRA2.

    I've been reading the Homework QS documents lately as well and they use RS-485 for Hybrid Repeater -> Main Controller.

  2. #12
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    I was able to spend some more time on this and have identified what behavior causes the "slowdown."

    When using the keypad attached to a load (Whether it's an actual load attached or a phantom load), the keypad presses are fairly responsive. Even when I repetitively press on the keypad, it's able to keep up. I can induce a slight delay, but not to the unresponsiveness extreme I could create in prior testing.

    When removing a load and having it behave in the unprogrammed mode, this is where I notice all the delays occurring. When pressing the keypad and releases a few times, you can see the processor sending out the Press/Release signals (3 and 4), but it becomes to become backed up.

    So my thoughts are the keypad most likely doing something similar to:
    • Trying to execute some code path where it expects a load to exists and causing a "timeout" to occur and then it finally sends.
    • Overfilling some sort of queue or single threading the button press/release messaging.


    Unfortunately, with loads assigned you can't receive the "release" signal, so I have no way of pinpointing the "why" and creating a work around.

  3. #13
    Senior Member
    Join Date
    Jul 2014
    Posts
    108
    Have you tried assigning the button to a dummy load? That is, a load device (dimmer) defined in Essentials/Inclusive, but with no actual device activated? I've had to do that a few times where I was using a keypad control for a non-Lutron device and couldn't get the keypad LEDs to do behave properly with a programmed (if non-existant) load.

  4. #14
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Yes. That's what I was referring to a phantom load.

    When a dummy load is assigned you lose press/release notifications.

    This is where all the issues crop up.

    I'm really leaning on code/firmware issue when using unprogrammed buttons for integration.

  5. #15
    Junior Member
    Join Date
    Jul 2016
    Posts
    3
    I observed the same thing tonight (just because I happened to have a keypad with both assigned & unassigned buttons nearby, and the Telnet session open).

    An interesting fact to add: I saw no delays from Picos (both 3-button R/L and 4-button). The telnet window printed out the responses as fast as I could physically press the Pico buttons, for 30 seconds straight!

    So I doubt the repeater is CPU bound. It also doesn't support your code path theory (that if the button has nothing to control the repeater has to "timeout" or go through a queue).
    I wonder if it is related to the keypad's LED. You'll notice that an unprogrammed Keypad button's LED will turn on once you press the button, then turn itself off after a few seconds. Perhaps something about that is causing this integration delay we're seeing.


    • Repeatedly pressing a scene-programmed keypad button: no delay in ~DEVICE prints, but it only reported the Press, not the Release.
    • Repeatedly pressing a non-programmed keypad button: delays in ~DEVICE prints, reported both Press & Release
    • Repeatedly pressing a scene-programmed Pico button: no delay in ~DEVICE prints, reported both Press & Release
    • Repeatedly pressing a non-programmed Pico button: no delay in ~DEVICE prints, reported both Press & Release



    Maybe you could consider Picos for some use cases? The raise/lower ones would make nice volume controls :)

    I am considering some similarly tight integrations. I'd really like to be able to modify Lutron scenes from a third-party controller though, to eliminate some of the integration hops for lighting control.

  6. #16
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    natem345:

    Great information regarding the pico buttons. This may mean that the current keypad behavior is a "bug" and could be improved/fixed. Hopefully someone from Lutron/Support can chime in.

    Regarding the "code path theory", I was really referring to behavior on the keypad rather than repeater. The more I read through documentation, observe behavior, it appears that the homeworks/radiora behavior splits behavior between the devices and repeater. I think this is how Lutron optimized their architecture for near instantaneous response and as minimal reliance on the RF during operation. You can somewhat see this "split brain" behavior when using the integration with "dummy loads." The controllers will report back status for a device that doesn't exist.

    I would gladly use the Picos, but I currently have keypads mounted on the wall for tactile input. I also will be placing touch panels near all lighting controls for more "advanced" interaction. However, for the wife and most day to day, I want to simplify to a few essentials keys on the radiora keypad.

    Going back to the keypad behavior: Hopefully this is a bug and we can get support to help out. Right now I'm having to create dummy loads to remove the press/release status (which I don't want to lose) so it doesn't go into this non-programmed delay behavior. In addition, the unactivated dummy loads eat into the 100/200 device limit - so it's really not a good workaround.

  7. #17
    Junior Member
    Join Date
    Jul 2016
    Posts
    3
    We can certainly hope this latency is improved!
    I do definitely believe the repeater is involved in every RF communication (keypad/button press), because the L1 training spoke about how they didn't believe mesh networking was ideal for lighting control. Therefore, I'm sure each device speaks to the repeater, which repeats (heh) the commands to all client devices (some of which may ignore it).

    I do have a couple questions about your specific setup, because I'm considering similar. Could we discuss off-forum? You can email lutronforum@midlane.net (will remove shortly) or find natem345 on Reddit

  8. #18
    Authorized Lutron Contributor
    Join Date
    May 2013
    Posts
    245
    dkulesza, I'd be interested in mocking this up on our test board. Would it be possible for you to send in a project where you have experienced this latency? You can send it in to SystemSupport@lutron.com and put the subject as Attn: Mike S. I'll mock it up and get our Engineers involved so we can take a look to see what may be causing the latency you're seeing.

  9. #19
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Quote Originally Posted by Mike S. View Post
    dkulesza, I'd be interested in mocking this up on our test board. Would it be possible for you to send in a project where you have experienced this latency? You can send it in to SystemSupport@lutron.com and put the subject as Attn: Mike S. I'll mock it up and get our Engineers involved so we can take a look to see what may be causing the latency you're seeing.
    Absolutely! I'll get you a project file once I can get my hands on it.

    In mean time, the latency issue I'm seeing (that I can't code around) appears to be common with natem345 as well. It appears pervasive regardless of the configuration (I could be wrong). I would think just having a simple dimmer and keypad setup would exhibit this behavior. Just don't assign a button on a keypad any behavior (scene or toggle) and the delayed press/release behavior should start to crop up:

    Again - happens when they keypad gets a few presses - compounds problem.

    This becomes more obvious to end user when a button press goes from sub second to 2-3 second response.

    I'm excited to hear we can work together on this - will bring back great flexibility in a radiora2 deployment and integration.

  10. #20
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Project sent.

    Looking forward to working with you!

Page 2 of 3 FirstFirst 123 LastLast

Similar Threads

  1. 3rd Part Curtain Motor
    By jonerdimatulac in forum 3rd-party Integration - HWQS
    Replies: 1
    Last Post: 10-04-2016, 02:56 AM
  2. Command Processing Latency
    By dkulesza in forum 3rd-party Integration - RA2
    Replies: 4
    Last Post: 05-06-2016, 11:16 PM
  3. RadioRa2 latency through RTI system
    By totalcontrol in forum Troubleshooting - RA2
    Replies: 7
    Last Post: 02-09-2016, 08:39 PM
  4. Caseta Kit Part nos
    By mark2457 in forum General Discussion - CAS
    Replies: 1
    Last Post: 11-17-2015, 04:17 PM
  5. Part Number Clarification
    By Rekoj in forum General Discussion - CAS
    Replies: 1
    Last Post: 03-31-2015, 08:29 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •