Couldn’t find anything in the documentation - what does this toggle do ?
By default, telnet communications happen from the parent app or device created by Hubitat's Lutron integration (I can't remember which--but one of them maintains the telnet connection), so the child devices--your individual Lutron switches, sensors, etc.--use that to communicate to the Lutron Bridge or Repeater. With this option enabled, the device will bypass that and use telnet on its own directly to the Bridge/Repeater. This saves what I assume is a small amount of overhead. Staff have recommended enabling it, but haven't looked into automatically enabling it for existing users. It's new in 2.2.6.
If I had to guess why it was introduced, my guess is that people were concerned that the "Lutron Telnet" device (or app? again, I can't recall...) tended to rank highly in your app/driver stats, also new in 2.2.5 and improved in 2.2.6, especially if you have a lot of Lutron sensors where all motion and whatnot goes through the parent device. (Picos and switches/dimmers are probably a bit less chatty unless you're always manipulating them.) Maybe there's actually something to it and staff were concerned, too. Just guessing here. 
2 Likes
Thanks - that’s helpful !
No, this isn't the reason. The Lutron Integration was the very first one ever created for Hubitat Elevation. It's been on the hub since a year before it was launched, so over 4 years now. Over that time we've added to it and improved it. But it's basic design was not ever thought about too much, and Mike and I have learned a few things in the interim. It occurred to us that we could improve its performance a bit by removing the parent app (Lutron Integration) from the communications path between Lutron device drivers and the Lutron Telnet device (which talks to Lutron system). So that's what Lutron Direct does. Going forward we will make this option invisible to new installs, and recommend that people switch to using it.
I have a large Lutron system and I couldn't see any noticeable change in performance. I'm not one to study app/driver stats, although suffice it to say that Lutron Telnet is my most used driver, and before this change Lutron Integration the most used app -- now it doesn't even show up on my list. Lutron Telnet is used an order of magnitude more than any other driver.
3 Likes
Thanks Bruce
Thanks for the explanation! (I've also wondered about parent/child overhead with my custom Hue Bridge integration--and I'm pretty sure the built-in one works the same--but this is more complicated since there is some "authentication" that is convenient to store in one place, like the parent app. I've contemplated caching this in child devices to avoid that but don't really know if it would be worth it, especially since to my knowledge this has never been a source of a problem--but no one wants a custom app to be high on the stats lists. 
)
One reason I was curious about this was that I have a 3 button Pico and 2 of those buttons toggle a Lutron dimmer to a preset level. I run this through Hubitat as the RA2 select doesn’t have a way to set the initial dim level.
I haven’t really dug in to it yet but there is a visible lag when turning the light on. It’s noticeable enough for it to be an annoyance but doesn’t cause too much of a usability issue.
I understand that there are additional hops involved when going via Hubitat so it may not be quite as responsive but not having anything to bench mark it against other than the native capability I don’t really know if I have an issue or it’s what to expect …
LOL. Or have log errors, etc.
There is a known Lutron issue with channel occupancy blocking commands from Pico via hub to Lutron. On RA2 there is a 1 second lockout. On Caséta it can be a number of seconds. How long are you seeing?
One fix is to use some non Lutron button device instead of a Pico. Another fix is to invest in a RA2 main repeater that can put your Picos on a different frequency than your RA2 Select system.
It probably is around one second and my perception was that it was worse if there were events in quick succession eg an off then on, the on would be slightly delayed….
That's better than Caséta for sure.
Do you know if the ramp up / down speed of a dimmer can be adjusted through the telnet interface ? You don’t have any control over this on the ra2 select app, but this adds to the perception of a “delay” too..
I just ran a quick test on my Caseta system, using Basic Rules to link a Pico to a Caseta Dimmer. The delay is exactly one second.
1 Like
That’s great! That certainly helps with reducing the perception of a delay! I had missed that!
[quote="bravenel, post:4, topic:69855, full:true"]
...So that's what Lutron Direct does. Going forward we will make this option invisible to new installs, and recommend that people switch to using it... [/quote]
Hi Bruce,
I'm intrigued by the Direct option - just to confirm your quote here, you're saying that at some point in the future, Direct will be the default option and that you recommend that folks consider starting to use it now?
It's been a long week and I'm not firing on all cylinders, so I'd be grateful to confirm I'm understanding that correctly - thanks!
Cheers, Chris
Yes, turn on direct and hit Done.
In the future new installations won't even see the toggle, will just use direct.
1 Like
Perfect - thanks!
I was initially thrown off by the "make this option invisible" remark, but I get it now 
Done & done - thanks again!
@bravenel I just clicked the Telnet Direct option and clicked done in Lutron Integration app and got a bunch of errors for each of my Picos. Everything still works but I repeated steps and got same errors.
And errors go away if you disable it?
