Quote Originally Posted by dkulesza View Post
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.
Sorry in advance to revive an almost three year old thread, but can anyone let me know what ever came about this?

As a point of reference, we noticed this latency problem back in 2014-ish when we had a site that had some highly customized integration (using telnet interface to RR2 main repeater). It was working perfectly running v6.3.0 yet when we tried to upgrade to v7.x we noticed many repeater reporting/monitoring latency issues (including what is described in this thread). At the time we worked a bit with Lutron systems support and ultimately the engineers came back and admitted that there were some changes made to from v6 to v7 where by main repeater feedback has been changed to an extremely low priority in the processing by the main repeater in an effort to improve overall system stability.

Does anyone know what version of RA2 this thread was in reference to?

Was there any resolution?

Have things been changed regarding latency of feedback from RR2 Main Repeater in the more recent versions?

Since this issue we have watched the Ra2 software evolve quite a bit since it was introduced and this particular site was an odd beast as all our other integrations with Ra2 have been more standardized and we have not noticed any other latency problems.

Again, this goes back five some odd years to 2014 and this problem was specific to this RadioRa2 customer as our company had written a custom system and script to interface to large number of WIRED QS shades directly to the RadioRa2 repeater along with a proprietary security system (essentially it was a linux system that originated three telnet sessions, one to RadioRa2, one to a Wired QS shade NWK-E and one to the security system and then ran python scripts that kept track of states to essentially have all the shades run as if they were native RA2 and utilized the security system motion sensors to detect occupancy). If was a highly custom yet a really robust solution...in fact in my opinion it ran better (in terms of shade synchronization that RA2 wireless shade dongles would have ever accomplished). The guy who wrote it was actually a Homeworks programmer for us that was fed up with the 200 device limitation in Ra2 where each shade counted as a device and basically emulated what Homeworks does through his code along with more options to customize shade button behaviors. This house alone had 70+ existing wired QS shades and trying to get dongles to all of them would have been problematic (I knows, lots of glass). Needless to say this type of custom integration was highly dependent on timely feedback messages from the main repeater.

Sadly, our fix was to downgrade the site to v6.3.0 and leave it at that and the customer went silent until now. Now, they want to upgrade them to support a number of the modern new features and devices and they do not want to change to Homeworks for a number of reasons, not just cost, so we will be upgrading their RadioRa2 to version 12.0.1 and I am really curious if any of these latency issues from back in the day have gotten any better or worse.

Based on the thread it appears that back in July of 2016 it Lutron was going to look at this problem in their labs. Then everything went silent.