Lutron Caseta switches lose state

Removing the fan component did the trick. Will be looking into the custom component. Thanks for the tip!

1 Like

Hi all - This problem has reared its ugly head again for me. I’m not sure exactly when it started failing again, but my Caseta switches are instantly toggling off as soon as I turn them on (in Lovelace). This is without my Caseta fan switches connected to this hub, so I’m not sure what the problem is. Is anyone else experiencing the problem again? @Phillip_Sperry? @thowell3? @BigMal?

@_Mike – I was never able to get this to work for me so I bought a Pro bridge and started using the custom component here – https://github.com/upsert/lutron-caseta-pro

It works perfectly for me and I have experienced no issues. It is actively supported and works with a broader range of Lutron products – like Picos – which are super useful to control any number of devices – not just Lutron.

Plus, it controls the hub using telnet, which, I assume means the access is local, which is increasingly important to me.

Thanks @Phillip_Sperry. Maybe I just need to make the switch to the custom component. I do have the pro bridge.

Hi All,

It looks like the issue is actually coming from pylutron and not homeassistant itself (see my comment here: https://github.com/home-assistant/home-assistant/issues/22907).

Essentially, the returned JSON for the new fan switch contains a new attribute “FanSpeed” and does not contain “level”. This caused errors. I made some adjustments to pylutron_caseta and added the fan to the lutron_caseta component (after learning more about the lutron integration) and I believe I have this working now:


I added pull request to both projects to see what will happen. But if you want to get your homeassitant working again with the standard bridge you can just replace the files with the one’s from those branches. For me the directories were:
/srv/homeassistant/lib/python3.5/site-packages/pylutron_caseta
/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/lutron_caseta

Be weary of doing this, though, because I assume upgrades will overwrite these files. We’ll see how things go, if pylutron_caseta isn’t managed anymore then I might just bring it into a custom component.

One last thing to note is that the pylutron_caseta repository added an SSL requirement that does not work with homeassistnat. In order to get my commit to work I had to replace line 51 in smartbridge.py with ssl_context.verify_mode = ssl.CERT_NONE

Dan

@Phillip_Sperry - I finally got around to trying the custom component today. Worked like a charm! Even with the latest version of HA (0.95.4), the native component still wasn’t working. Not sure why it’s such a piece of junk. But I’m glad the custom component is working!! Thanks again!

@djj211 - Just an FYI, the native component is failing for me with a Pro bridge but WITHOUT any fan switches connected to it. So it appears there is more to this.

@_Mike I only tested my code mods with a standard smart bridge and not the pro, so I am not sure what might be happening with the pro. My guess is that it is something similar: the responses from the pro smart bridge have probably changed in such a way that the underlying program (pylutron_caseta) is failing silently. It’s expecting a particular status response and receiving something entirely different. The fact that initial status is reported and that you can toggle it on/off means that you can make a communication and can send messages successfully. The problem, then, is still with the status updates.

I’m happy to to take a look at some logs. Someone with a pro bridge would just have to enable debug on the lutron_caseta component. The underlying program should debug the responses it receives from status requests. Those would tell you what’s up. Though it sounds like you might have this sorted with the cust component.

One of the problems we may encounter here is pylutron_caseta is not managed by HA bit was a separate library that it relied on. I don’t see any one really supporting that anymore (what’s published is really old). So even if we get to the bottom of this, we may still need to create a custom component. The HA models is built by using separate libraries so it’s unlikely that they take ownership.

Thanks @_Mike, removing the fans from the Caseta app and restarting Home Assistant fixed my state issues. I tested on/off/brightness and they all seem to be working. I was very close to buying the Pro Bridge and trying out the custom component but this seems to be working. Just wish the fan switches could be added! I have 5.

Glad you got it to work! I do recommend getting the pro bridge eventually. I love that I can also use my Pico remotes with the custom component.

Yeah, I’m keeping an eye out on Craiglist and OfferUp cause I am not paying the $100+ I’m seeing online for it. It would be great to get the pro for the Pico remote control. I literally have 10 unused remotes cause they came as a bundle with each switch I bought. Anyway, thanks again!

I had the same issue and removing the fan control switch from the lutron app also fixed it. I am running the regular caseta bridge with Hassio (version 0.98.0) Thanks for working on this.

@djj211 Are you using HASS through a previously installed Linux OS, or are you using HASSOS? I don’t appear to have access to those directories through HASSOS. If you are using HASSOS, how did you get to those directories? Thanks in advance for any information! Really looking forward to getting the states and fans working in HASS!!