[OBSOLETE] LutronPro Caseta v1.0

@njschwartz its been awhile since I configured this since I have had it working ok, minus the ramping haven’t had time to test that. But I was wondering if there were any improvements made to the nodejs server like not having to restart the server when adding new picos.

Jeff, I saw a similar thing happen during my initial setup and testing. I can’t tell you either exactly how it happened, but I can tell you that if you follow the directions I wrote here under troubleshooting, your duplicate Pico remotes will disappear and if you first head over to your Lutron bridge and name the Pico remotes there, when you bring them in again, they will have the correct names. Not sure if you’re using ABC to program them or WebCore, but I can tell you that you don’t have to worry about your configuration if you’re using ABC. When you bring them back in, you just open ABC, select the appropriate Pico for the mapping and everything is there and working again.

Mr. @SmartHomePrimer has it from a practical sense: currently the only way to reflect (within SmartThings) a device name change made within the Lutron app is to remove the Lutron device as listed in the SmartApp discovery page (un-checkmark it and then next/save/etc. all the way out), and then re-discover/re-select it the same way. (I think this is true for any of the Lutron devices, not just the Picos.) Just re-discovering it won’t do the trick, even though you see the new Lutron name on the device (PIco, here) discovery page.

The underlying reason is pretty simple: that’s just the way Nate wrote the code, at least for the moment. The SmartApp just doesn’t take into account the possibility that the name has changed (or the device ID, for that matter) – if the same physical device is re-discovered and still selected, it’s ignored rather than updated. That issue is certainly a good candidate for a future SmartApp update.

I don’t seem to have any trouble changing the name of a Pico within SmartThings, and it seems to “stick” ok and is used by (say) Advanced Button Controller SmartApp. But that name change doesn’t reflect back to this SmartApps’s discovery page (because the device handler + SmartApp code just plain doesn’t do it, as above), nor does it reflect back to the node server (again, just not implemented) nor to the Lutron app/bridge itself for that matter. I’m not aware that anyone’s figured out how to do that latter, as yet.

Handling name changes originating at the Lutron end is pretty feasible – just a SMOP as we used to say :stuck_out_tongue: – but then some decision would have to be made about those stomping on name changes made at the SmartThings end to the same device.

1 Like

I’m patiently waiting for this to work for RA2 Select to work with Pico, the switches works already.
Fingers crossed @njschwartz.

What does the logging from the node server look like when connected to the RA2 Select, as far as Picos are concerned? Do they show up in the device list? Do the Picos show up in the SmartApp discovery and can be selected, but just don’t do anything? Is there any logging activity on the node server when you press a Pico button; if so, what?

(btw, any chance the Pico issue is just a matter of turning on the Lutron app’s Telnet Support? Setup(Gear) -> Advanced -> Integration -> Telnet Support = ON has to be done for Picos with the Caseta bridges, at least, probably the RA2 Select also)

@BHO
RA2 Select is basically a Caseta Pro with a RadioRA2 radio. It uses the same apps, same apis/integrations, and has telnet.

My telnet support is already on.
The issue, however, seems to be that @njschwartz has the pico remote enabled only if it identifies the main repeater to be a Caseta Pro. So Caseta (retail) and RA2 Select is set to not support pico with his logic.

I don’t know where in the code to change it to accomidate the RA2 Select repeaters.
@njschwartz mentioned that he can make the other keypads work as well (since RA2 Select supports many scene specific keypads).

Hopefully, he’ll have some time soon to help me out. I’d appreaciate your assistance @BHO if you want to tackle it.

Just purchased a Lutron PJ2-2BRL to test 4 button picos with Stringify integration, but they don’t show up in the Lutron Caseta Service Manager. I see it in the Node.js when I restart the Node.js server, but cannot see it in the SmartApp. What am I missing?

@thegilbertchan - I knocked together a quick patch to my earlier patched version of Nate’s node server, which MAY let the RA+/Select be recognized as a pseudo-Caseta-Pro hub and so let the Picos work. If you are feeling brave…

FIRST make sure you save your current almost-working copy of node_modules/lutronpro/lutronpro.js
THEN replace that with a copy of my current patched version, found here:

And I’ll be interested in your results. Just be sure you can roll it back if necessary!

@SmartHomePrimer – Nate’s current SmartApp and Device Handlers just plain do not take the 4-button Picos into account at all. Complete support would require modifying the SmartApp and adding a new (or modified) Device Handler… maybe several, since I gather that there are several types of 4-button Picos that work slightly differently from each other (Pico4ButtonScene vs. Pico4ButtonZone, etc.)

BUT in the meantime, while I was messing with the RA+/Select issue, I added a patch to lutronpro.js that may be ‘good enough’ for the moment. It just fakes 4-button Picos to appear as 3RaiseLower (5-button) Picos to the SmartApp/Device Handler. Seems to work OK with my Pico4ButtonZone I have here, at least insofar as I can make the Advanced Button Controller SmartApp work with it. The button mappings are, from the top of the 4-button Pico: 1st=3-Button “ON”; 2nd=3-Button “RAISE”, 3rd=3-Button “LOWER”; 4th=3-Button “OFF”.

If you are feeling adventurous, you might grab my patched version of lutronpro.js and try it (and do keep a copy of your working lutronpro.js to fall back to if necessary!). See my reply to @thegilbertchan just above for the link. I’ll be interested to know if it works for you, and if not, what the logging looks like.

p.s. because of a quirk in Nate’s original device discovery code, it may be necessary to discover the Picos (or really, ANY new device) TWICE before they appear for selection. That’s because the node server code returns the OLD list of devices to the SmartApp before it gets the NEW list.

Thanks Bill. I noticed that too. Will try the patched lutronpro.js and let you know what happens on this end.

Thanks Bill. The second version absolutely works for Lutron Pro Service Manager and the button definitions in ABC are spot on. Unfortunately since Button 3 is the center button on the Lutron 3BRL remote, its undefined when you import the 2BRL into Stringily. So you cannot specify what the lower (down arrow) button does.

Aha. I had to go read up on Stringify to see what you’re talking about (hadn’t really heard of it before… a kind of IFTTT that allows more complex logic chaining?). Anyone, do I have this right that Stringify really wants to map the Pico onto an Aeon 4-button remote… and their model of a remote sort of runs out of buttons when the Pico gets to #5 (the down-arrow “Lower”). Something like that? I gather you’d have the same problem with a ‘real’ 3-button Raise/Lower Pico, then?

So… hmm, what’s the best approach that doesn’t also mess up the obvious ABC mapping? I suppose a special case for the PJ2-2BRL could be: if you press button 5 “Lower”, then ALSO pseudo-press the missing button 3? Weird, ugly, but maybe usable?

Long term, the missing pieces are support for 5 different Lutron pico button types, maybe 6, but it would be strange to me that the Pico audio remote is really all that different other than labelling where LutronPro Caséta v1.0 and ABC are concerned. Stringfiy too for the that matter. To them, what we ultimately want is for them to be recognized as a button devices, with x number of buttons that can be mapped to whatever we choose. I have a hard time wrapping my head around buying a $100 Pico audio remote, when you could turn a $20 3BRL into that same remote with this setup.

Stringify can be described as “like IFTTT”, but it’s actually really powerful and fast. You can create very complex flows, and you can also pass them to and from IFTTT, so even if the device isn’t supported by Stringify or IFTTT, it can be supported by IFTTT and Stringify together. It’s a nice visual alternative to WebCore as well. If you have never played with it, you should give it a try. Totally free and very easy to get sucked into for hours, automating disparate devices that would not otherwise talk and putting them into both simple and complex flows.

Dude @BHO you’re amazing. It worked.
It’s a bit out of order, but that’s okay. It works with the scene keypads as well.

Hey, cool, something worked out of the gate! Well, almost. If you can send me a dump of the start up log with all the device listings, and sort of annotate what you find in disarray, maybe it can be patched up pretty easily. Feel free to dump it into a private thread if you don’t want to clutter up this main topic. Can’t promise anything but I’ll take a look!

Gilbert, are you controlling any Maestro products with the RA2 Select? I’m confused about how that bridge works with Maestro. Lutron list a few Maestro lighting controllers and a fan controller that are compatible, but does that mean that only those particular Maestro products are compatible with the RA2 Select bridge? And if so, what ever could their reasoning be for that? With Bill’s changes to allow the Node.js server to access the RA2 Select, I’d strongly consider getting one if I could also control these Maestro fan and light controllers.

Hey @SmartHomePrimer. I believe the Maestros are their non-radio / dumb switches.

RA2 Select is using all the programming and apis/integrations as a Caseta, while using the radio frequency and hardware of their professionally installed Radio RA2 line.

RA2 Select is not meant to be DIY like Caseta and requires you to have it installed by a Lutron provider (their are a few people online that will sell you the hardware but you’ll have to figure out what you need and program it yourself).

I’m absolutely loving my RA2 Select setup. Way better than all my zigbee / zwave switches I’ve installed previously. It being compatible with all Caseta integrations is a huge plus. I get the reliability of Radio Ra2 and the flexibility of Caseta.

To get started, you’ll need a RA2 Select Main Repeater, and any Radio Ra2 switch (most will work). Most Radio Ra2 starts with RRD-___.
The Maestro one you linked won’t work.

Hi Gilbert,

Thanks so much for your reply. There are indeed three Maestro switch types compatible with RA2 Select and benefits to using them in certain situations. Having said that, I’m sure you’re correct about the consumer version of the Maestro fan/dimmer I posted.

Good to hear you’re enjoying the RA2 setup. Lutron definitely produces some stable products.

Not sure if I got this right, but I am only a the step of installing and got this after. Also, I’m trying to figure out where this got installed (which directory) so I can make the .js file with the IP info, etc:

npm WARN saveError ENOENT: no such file or directory, open '/package.json’
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/package.json’
npm WARN !invalid#1 No description
npm WARN !invalid#1 No repository field.
npm WARN !invalid#1 No README data
npm WARN !invalid#1 No license field.