Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Processing Latency - Part 2

  1. #1
    Junior Member
    Join Date
    Mar 2016
    Posts
    24

    Processing Latency - Part 2

    In my prior post I encountered latency issues when a 3rd party integration was sending commands to the processor to act on. (Primarily #OUTPUTs). Its still not perfect but I optimized the interface to reduce delay I was seeing (Mainly with the 3rd party integration trying to drive dimming with multiple levels rather than letting the controller handle ramping).

    My part2 is encountering delays when Lutron keypad(s) have button(s) pressed rapidly. It appears you can overload the repeater/processor when multiple keypad events are sent to the RadioRA2 main repeater.

    A way to produce/reproduce this behavior:

    1 Keypad with no levels programmed
    1 Scene/Zone controlled through integration

    Log in to the main repeater with the lutron/integration account and appropriate monitoring levels set. If you press the keypad button 20 times quickly and then try and executing a #DEVICE/#OUTPUT to change a zone/scene it will not execute until the system handles the 20 keypad presses. This can bring the system to a halt for 30+ seconds until it recovers (If it recovers - can cause the Repeater to enter safe mode. I have had this happen).

    What's interesting is pressing a keypad button that is programmed to a scene will still act immediately (No waiting for the queue to clear on the processor?) when this situation is created.

    1) Has someone experienced something similar when trying to use the keypads generically with integration?
    2) More of an engineering/support question: Why does this occur and why are the programmed keypads not affected? Trying to understand why telnet integration is blocked vs keypad seems to still function.

    I haven't tested serial vs telnet to see if that relieves overhead on the processor.

    I was REALLY hoping to use the keypads generically and have my processor handle turning on scenes through phantom keys on the processor but this doesn't seem resilient at all. I don't like the idea that in a certain scenarios (multiple users in house leveraging keypad, rapid taping of a raise/lower key, troublesome child/elder) could bring the system down and potentially put the repeater in safe mode/overload.

  2. #2
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Target architecture I'm trying to drive towards:


    RadioRA2 Keypad ---------> 3rd party processor -------------> Device action

    This could be:

    RadioRA2 Keypad -------> Processor -----------> RadioRA Scene (Different scene based on time of day or other variable)

    RadioRA2 Keypad ------> Processor --------> Television

    Or any combination of above.

    This seemed do-able considering it would be how HomeworkQS works to some degree, but something is different with RadioRA2 that doesn't allow this to work.

    I'm hoping someone says this is me and not RadioRA2. Don't feel like ripping this out as I love how it works independently as just lighting.

  3. #3
    Quote Originally Posted by dkulesza View Post
    Target architecture I'm trying to drive towards:


    RadioRA2 Keypad ---------> 3rd party processor -------------> Device action

    This could be:

    RadioRA2 Keypad -------> Processor -----------> RadioRA Scene (Different scene based on time of day or other variable)

    RadioRA2 Keypad ------> Processor --------> Television

    Or any combination of above.

    This seemed do-able considering it would be how HomeworkQS works to some degree, but something is different with RadioRA2 that doesn't allow this to work.

    I'm hoping someone says this is me and not RadioRA2. Don't feel like ripping this out as I love how it works independently as just lighting.
    What is it about the above scenarios that doesn't work? I'm doing essentially the same thing using Indigo (on a mac Mini) as the 3rd party processor. The mac is connected to the repeater via ethernet. I will admit I've never tried the "press button 20 times quickly" test, as there's no user in the household that would ever try to do such a thing. As much as possible, the actual lighting control is kept on the Lutron system. That is, Indigo rarely sends multiple Lutron command based on one action. If I need multiple things to happen on the Lutron side, they're all done in one scene and Indigo only sends one phantom button press to activate them. But other actions (outside of Lutron) are triggered by Lutron button presses.

  4. #4
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Quote Originally Posted by FlyingDiver View Post
    What is it about the above scenarios that doesn't work? I'm doing essentially the same thing using Indigo (on a mac Mini) as the 3rd party processor. The mac is connected to the repeater via ethernet. I will admit I've never tried the "press button 20 times quickly" test, as there's no user in the household that would ever try to do such a thing. As much as possible, the actual lighting control is kept on the Lutron system. That is, Indigo rarely sends multiple Lutron command based on one action. If I need multiple things to happen on the Lutron side, they're all done in one scene and Indigo only sends one phantom button press to activate them. But other actions (outside of Lutron) are triggered by Lutron button presses.

    Thanks for replying. One reason for me posting is to see if it's just my setup or the platform. Maybe my experience isn't typical behavior.

    The "press button 20 times quickly" test was really just to exacerbate other issues I was noticing.

    Scenarios where this behavior is problematic:

    1) Volume up / Volume down - Some people don't hold volume up/down, they like to press it individually for each incremental click up/down
    2) Button to cycle (Next song, different scenes, etc.)

    I originally noticed this when I had three buttons on a keypad I needed to press in succession (Button 1, Button 2, Button 3). By the time I got to button 3, I could noticeably see delay. This is when I removed all behavior from the keypad and monitored it in telnet and observed the lag compounding with each button press.

    While this lock-up / slow-down is occurring - what's strange is keypad programmed scenes aren't affected. (But going to another keypad pressing a button or two with no scene programmed would be impacted).

  5. #5
    Are you using serial or ethernet to connect your automation system to the repeater? Serial is slower, so if you're sending/receiving many commands it's going to take longer to get them all transmitted.

    Keypad programmed scenes don't necessarily go through the main repeater. The scene ID is transmitted directly to all devices and they react to it independently of what the repeater is doing over the integration interface. That's why Lutron scene devices work simultaneously - they're not serialized through the repeater.

    I'm not sure I'd use Lutron keypads for what you're trying to do. You're probably better off using something that communicates directly to the automation processor. But if you're trying to mix lighting and automation controls on the same keypad, including using the up/down buttons for both light levels and sound levels, you might not have a choice. What automation system are you using?

  6. #6
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    I'm not using serial - using Ethernet - but I was curious if it may be faster due to less overhead of Ethernet stack and tcp/ip. (Latency vs throughput)


    Your comment about keypads not going through repeater makes complete sense - are you aware of documentation that outlines behavior? That may help and answer my questions. I'm still surprised there is a delay with repeater though. I have no processing going on and it's purely just receiving the wireless signal (what button press). Why would any major delay/latency occur? Realistically we are talking maximum 4 button presses a second and the system chokes on that for integration. I'm just surprised such low volume is still a performance challenge for this design.

    As of now I'm using a crestron processor. But trying to architect the house so I can change at any time and not be dependent - hence lutron lighting.

    However, with all of these gotchas I'm experiencing - I'm wishing I just went 100% crestron and it just worked. Considering I'm doing all programming myself - cost of crestron hardware is similar price or less in most cases. Also more flexibility as pressing a dimmer switch doesn't have to be tied to the same load.

    Of course this comes at a cost - when processor goes down - light control is limited.

  7. #7
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    And let me qualify a statement I made before: "are you aware of documentation that outlines behavior?" I've read the Clear Connect RF technology document, but it doesn't dive into enough detail to truly understand the behavior. It's unclear from that document what role the main repeater has in message delivery. (Do commands go to the main repeater and back to a device or does the device broadcast a generic command in an area).

    The more I think of it, I'm curious what the behavior is when you have an Inclusive setup with two repeaters then. If performance issues arise when the repeater is responsible for relaying the messages (My button press example), then you would/should be able to see noticeable latency/performance issues with a few commands if you had multiple scenes that had to cross a repeater boundary/border there were triggered simultaneously.

  8. #8
    I'm certainly not an expert on RRA2 internals, but I think it's important to keep in mind that the Integration Interface (serial or ethernet) is just that, an integration interface. It's not how RRA2 communicates internally. I have a two main repeater setup, and scenes with devices on both repeaters work quite well. There's no noticeable lag between them, but I don't have any rooms split between repeaters. So scenes that trigger devices in multiple rooms (sunset, etc) may have a very small lag between rooms, but not enough that I can really tell.

    Also, if you're telnetting into a repeater, you should be seeing a LOT of traffic. All those status messages are one of the reasons that there's a limit to how fast things can go over that interface. I do wonder how powerful the Crestron processor is, and if it's taking a long time to deal with the traffic it might be slowing things down. Or at least slowing down what you're seeing. The only way to really tell would be to repeat the tests with a different automation device.

    For me, the interface works fine. But I also try to limit the number of actions doing round trips from Lutron to the Mac and back again.

  9. #9
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Traffic on the repeater is limited as the MONITORING is tuned (Crestron driver tunes it to only request the bare minimum for integration purposes).

    My testing has been done while removing the processor (eliminating any bottleneck/performance there). I telnet'd directly into the processor and watching the ~DEVICE messages 3 (PRESS) and 4 (RELEASE) come over the wire. This slow/delayed behavior was exhibited with no third party interaction - all Lutron.

    I completely understand your point that the ethernet is only for integration and is not how luton natively communicates. The reason I bring up a two repeater setup is if the two repeaters are able to respond near real time - then why is there any limitation on the integration performance (Unless bad design/intentional). If a button pass can be relayed near realtime through the wireless repeater or RS-485 link, then what would limit it from occurring near real time over the integration.

    Maybe someone with more intimate knowledge of RadioRA/ClearConnect can share some insight.

  10. #10
    I suspect, but have no concrete evidence, that the integration interface is deliberately limited to ensure that it cannot (or should not) effect normal operation of the system. I don't think the repeater has a very powerful processor and that's one way of protecting it. And FWIW, two main repeaters communicate via ethernet. Not RS-485. RS-485 is for main to aux repeater communication. I don't have any aux repeaters in my setup, so I don't know what if any effect they have on system performance. But I am sure that communication to the aux repeaters would be prioritized higher than the integration interface.

Page 1 of 2 12 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
  •