[Deprecated] Lutron Caseta Connect V1.5

I believe you can. I’ve see closeout requests in the forum before so I assume its possible.

I am sure there is a way, but I am failing to find it. Maybe I have to ask an admin? I bet @JDRoberts either knows how to lock a thread or can do it for me? Looking at locking that older Beta thread!

@njschwartz - You mentioned that we should give the SmartThings Hub & Lutron hub static IPs since the script will break if they change.

Do we need to give the machine running the LutronPi.py script a static IP also? I see the IP referenced in the SmartThings app (as PI/Caseta at: 192.x.x.x).

So Stephan I did what @sabray1 did after homebrew and still paramiko error. I reinstall python, twisted and paramiko

Hmmm, hopefully he chimes in with some suggestions. Otherwise look at @Joe_D’s note in the beta thread. They both got it working in MAC OS.

I can’t, but @slagle or @Aaron can. :sunglasses:

The when you want locked is the older beta thread, is that right?

1 Like

Got it working. I used homebrew shell to execute the script and voila

1 Like

Yes indeed. Getting lots of action on both and it is hard to keep up with who is doing and trying what. Thanks! :slight_smile:

There is code in the smartapp that SHOULD update the device if the IP address changes on your Pi/Server, however if you are able to set a static IP/DHCP reservation I would highly recommend it. It just makes things easier and less likely to fall apart.

1 Like

FYI. Just installed Homebridge on the same machine so thats running simultaneously with the Lutron script. Just info for anyone who wants to use and old mac to do both

1 Like

@njschwartz - super minor thing, but I wasn’t seeing any default icons for the dimmers, so I made the change in a branch in Github for the dimmer device handler to show the default switch icons.

I tried to look for the enumeration for the available icons in the SmartThings documentation but couldn’t find it. Can you (or someone else) point me in the right direction?

ETA: OK, found this thread which was helpful…

1 Like

I ended up changing my default icon for the dimmer to the overhead can light icon:
st.Lighting.light21

since that’s what most of my dimmers control.

1 Like

By the way, the reason no default was showing up based on the original device handler code was that the icon specified had a typo.
It should be:

st.Kids.kids10

and it was st.Kids.kid10

Not sure why you would want that as your default, though.

Lol. That’s kind of funny. To be honest I’ve been so focused on function that I have paid almost no attention to form. I’m glad you’ve pointed it out. Why it was the kids icon I have no idea. I borrowed a basic template and then altered it to work for this so I guess that’s where that came from. I’ll look into getting good icons up there soon.

1 Like

Thanks for this! Works great!

I have some Pico remotes that are just on/off switches, not dimmers and they have no favorite buttons. I added support for them, and submitted a pull request.

Edit: Hmm, I realized that the buttons are named 2 and 4 but I put in only a 3 button device. I’m wondering if you should remap the button numbers in the device handler parse function so you can create a ST DTH that only has 5/2 buttons instead of the 6/4 we’ll need here. That way no additional buttons show up in Smart Lighting or Core that will confuse users because the Picos don’t have that many buttons.

Hey Alan thanks for your work. I am working to add that as well as several other things as we speak. I have got ramp rates working, added the detection for standard switches and picos (your pull request THANK YOU!), and made it automatically apply the appropriate device type for those devices.

As far as the buttons, I think you are right I should correct for it in the code to simplify things and get the actual number of buttons correct. I am going to go look at the best way to achieve that. You said the buttons on the 2 button picos are buttons 2 and 4 correct? Of course it couldn’t be simple and both just be off by 1 one lol. Let me see what I can do and thanks again for your work.

I think it could be as straightforward as having a different device type for each type of Pico, and then in the Pico parse function:

switch(description.data.buttonNumber) {
  case 2: 
    buttonEvent(1)
    break
  case 4:
    buttonEvent(2)
    break
}

Yup that’s almost exactly what I did. It works. Do you want to try it out? I’ve made a ton of changes but haven’t tossed it up on the github yet.

Large changes were made over night to address many of the issues people have brought to me as well as to add Ramp Rate functionality. Please see the first post in this thread for more information! Thanks all for your support and feedback,

Hm… another recommendation: Put IP addresses in a separate config file, so we don’t have to change the LutronPi.py on every update.

3 Likes