Thanks Thanks:  0
Likes Likes:  0
Results 1 to 5 of 5

Thread: Command Processing Latency

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

    Command Processing Latency

    Is it typical for a RadioRA2 Main Repeater to struggle when processing multiple integration commands? It appears commands are processed serially and when a processor sends a lot of commands the entire RadioRA2 process will hang while attempting to digest the data.

    One example was allowing the third party processor handling the ramping commands. Seems 20-30 commands sent to one light completely consumes the processor.

    Is this expected behavior? Was a bit surprised how the RadioRA2 struggled.

  2. #2
    Senior Member
    Join Date
    Oct 2013
    Posts
    518
    What kind of command sequences are you sending?

    Would those be better served as being handled by a scene? You can always use a phantom button for a scene and then call that from your external control. With a scene it's the devices themselves that handle setting themselves up. One scene command can touch any combination of device start delay, light level and ramp up time. This also helps avoid the 'popcorn effect' of multiple lights in the same area coming on separately. Put them in a scene and you can ramp them up all together for a very sophisticated look. Even ramp up over the length of a path or other sequential kind of arrangement, with just one command.

    Letting a 3rd party system do the control without taking advantage of Lutron's features is likely to have less-than-impressive results.

  3. #3
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    I was originally having the application handle load ramping. 0, 25, 50, 75, 100. I have a user interface with four loads on a page and I turned each one on individually back to back. This was too much data for the RadioRA2 to handle (which was very disappointing). I could understand trying to send 100+ commands to turn of every light in the house and causing an overload (instead of using an ALL OFF scene), but this was relatively lite IMHO.

    What would be nice is to have a "transaction" type command to do the following:
    #TRANSACTION_START
    #OUTPUT,xyz...
    #OUTPUT,xyz...
    #OUTPUT,xyz...
    #TRANSACTION_END

    To avoid the popcorn effect. Not sure if this is technically possible, as I have a suspicion that each scene is pre-programmed on the switchers/dimmer so a single command can be sent (Preset 1, Preset2, etc.) and avoid RF chatter.

    Obviously this can be worked around by building scenes in Essentials and then mapping scenes in the home controller software.

    However, still have other issues how this behaves:

    1) On physical button raise/lower release (falling-edge) is when the OUTPUT response is sent out over RF. This is NOT consistent with out 3rd party integration behaves, it responds acknowledging the command (immediately after it's received) rather than when the level set is complete..
    2) You can't determine when an ~OUTPUT is in response to a physical button on dimmer/keypad or within your application.

    Example - You always want the ~OUTPUT feedback to set the level within your 3rd party UI, but you don't really want the ~OUTPUT level from 3rd party commands (sent from your integration) to reset the level and create actual feedback/noise.

    So, would be nice to have transaction ID's for each request/response pair (3rd party integration) and further be able to distinguish physical keypad level sets.

    I'm just seeing a lot of minor issues when trying to develop a truly resilient user interface. Once you know these quirks - you can see the actual challenges surface in the Lutron iPhone/Android application(s). They were just very aware of the issues and coded workarounds for the behavior.

  4. #4
    Senior Member
    Join Date
    Oct 2013
    Posts
    518
    Quote Originally Posted by dkulesza View Post
    I'm just seeing a lot of minor issues when trying to develop a truly resilient user interface. Once you know these quirks - you can see the actual challenges surface in the Lutron iPhone/Android application(s). They were just very aware of the issues and coded workarounds for the behavior.
    I am in total agreement with you there. "Once you know" indeed.

    Likewise the lack of being able to distinguish what was an actual user interaction, versus a programmatic one (scheduled or 3rd party). It makes it difficult to 'be sure' of what's going on.

    It would be nice to be able to create or otherwise save a scene based on live lighting settings. As in, capture how they're set now and save that. Barring an actual addition of it as a stored scene, just being able to import that back to Inclusive would be convenient.

  5. #5
    Junior Member
    Join Date
    Mar 2016
    Posts
    24
    Well... There is the undocumented way of manipulating keypads programmatically and set levels to make scenes. I haven't tried it on phantom buttons but know it will work with keypads. You could write a quick method to query all the lights you want in a scene and then add a new scene/edit existing. It's not the fastest method and takes about .5s per load to program.....

    Keep in mind - anything the lutron app (or other interfaces can do) you can do as well - just not in a documented / supported fashion.

Similar Threads

  1. How to receive custom command string from 3rd party?
    By malkev in forum 3rd-party Integration - HWQS
    Replies: 8
    Last Post: 04-20-2016, 11:14 AM
  2. RadioRa2 latency through RTI system
    By totalcontrol in forum Troubleshooting - RA2
    Replies: 7
    Last Post: 02-09-2016, 08:39 PM
  3. Siri Command List
    By msterling in forum General Discussion - CAS
    Replies: 7
    Last Post: 10-20-2015, 02:17 PM
  4. HVAC Controller erratic command response
    By Fiasco in forum 3rd-party Integration - RA2
    Replies: 4
    Last Post: 08-22-2014, 05:53 PM

Posting Permissions

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