Core: Lutron Caseta switches lose state

Created on 9 Apr 2019  ·  29Comments  ·  Source: home-assistant/core

The Lutron Caseta component is not working 100% correctly. I see all of my switches in HA. When I toggle an HA switch to On, the light WILL turn on. But the HA switch immediately toggles itself back off. And if I manually turn a physical switch on or off, the HA switch does not follow along with the current state. I’m not seeing any errors in the log.

I created a post in the HA community for this issue, and it appears that it might be fairly common among other users:
https://community.home-assistant.io/t/lutron-caseta-switches-lose-state/108568/2

lutron_caseta

Most helpful comment

Hi,

The issue here isn't with homeassistant, rather it is with pylutron_caseta which homeassistant uses under the hood. I too was experiencing this issue when adding my new lutron caseta fan controller to my smart hub and when I dug deeper I was able to see that the returned json from the fan controller was different then the returned json from all other devices (it did not contain the level attribute but rather a new FanSpeed attribute). This caused the loading of devices and status checks of devices to error silently and stop dead in it's tracks.

I was able to make some adjustments to the pylutron_caseta class to get the state of deviecs to load (see pull request gurumitts/pylutron-caseta#34). I also added fan support to that pull request as well and created the appropriate fan component as part of this pull request here: #24770

I'm not sure if pylutron is still managed though so I am not sure if a merge will be coming or not. One thing to not with my pylutron pull request is that it was updated recently from what is in pypi to require ssl. This doesn't seem to work in homeassistnat so I had to revert back to ssl_context.verify_mode = ssl.CERT_NONE on line 50.

All 29 comments

Thoughts from any developers on this?

Bueller? Bueller?

Anyone? Anyone?

It does feel like they are not even looking at open issues.

Here's an update. I had the standard Caseta bridge, but purchased a Pro bridge last week so I can expose my PICO remotes to HomeKit using HomeBridge. I tried connecting the Pro bridge to Home Assistant, and it does correctly retain the device state. Granted, I have only migrated a couple of switches over to the Pro bridge. If I encounter the problem again after migrating more switches, I'll post an update here. Still, I am disappointed that no devs responded to this chain...

Hopefully they can get the non pro working again or remove it from supported devices. If its not getting the state its not useful.

So… As I stated previously, my original problem was with the standard bridge. I purchased the Pro bridge and everything was great. I have been slowly migrating switches over to the Pro, and tonight I noticed that it stopped working with HA. I wonder if it has something to do with the number of devices attached to the bridge? Devs??? Thoughts?????

One more update. Per this thread, some other HA users and I seem to have narrowed down the source of the bug to manifest when only when the new Lutron Caseta fan controller switch has been added to the Lutron bridge. Once the fan controller is removed, the HA functionality returns to normal.

I am having the same problem since installing the Lutron Caseta fan controller switch. The problems seems to be only with HA, I am not having the same issue with Homekit or the Caseta app

I too am also having this issue. Can confirm that adding fan controllers to the bridge creates the issue.

Hi,

The issue here isn't with homeassistant, rather it is with pylutron_caseta which homeassistant uses under the hood. I too was experiencing this issue when adding my new lutron caseta fan controller to my smart hub and when I dug deeper I was able to see that the returned json from the fan controller was different then the returned json from all other devices (it did not contain the level attribute but rather a new FanSpeed attribute). This caused the loading of devices and status checks of devices to error silently and stop dead in it's tracks.

I was able to make some adjustments to the pylutron_caseta class to get the state of deviecs to load (see pull request gurumitts/pylutron-caseta#34). I also added fan support to that pull request as well and created the appropriate fan component as part of this pull request here: #24770

I'm not sure if pylutron is still managed though so I am not sure if a merge will be coming or not. One thing to not with my pylutron pull request is that it was updated recently from what is in pypi to require ssl. This doesn't seem to work in homeassistnat so I had to revert back to ssl_context.verify_mode = ssl.CERT_NONE on line 50.

I am seeing this issue too and have both lights and the fan. @djj211 it looks like tests are failing on both of your PRs. I'll take a look and see if I can fix that as soon as I can. And if pylutron-caseta is unmaintained, we should fork it have and homeassistant use the fork.

@trashcan Thank you for testing. Are you using the pro smart bridge or or the standard? All of my testing was done with the standard. It would appear that something else is up with the pro that I won't be able to get to the bottom of without a pro of my own.

https://community.home-assistant.io/t/lutron-caseta-switches-lose-state/108568/48

I have been successfully running my code with a standard bridge for a full week now (which includes caseta fan support). The pylutron pull request I put in requires hat you edit line 50 before using (even with standard). The dev branch was changed there to require ssl and that did not work with my standard smart bridge. Not sure if you noticed that. Not changing line 50 will cause a connection failure to the smart bridge.

As far as the pylutron_caseta api. I don't believe that is maintained by HA. New here, but its my understanding that HA wants all apis hosted on the pypi. pylutron_caseta is pulled from the pypi and what is on the pypi is actually a few commits behind GitHub. So either the new fork will have to be hosted as a new library or the owner will have to update it. Unless, of course HA maintains libraries on the pypi as well.

Unfortunately I have the standard hub and not the pro as well. I believe I have applied the SSL fix, but my hass instance is in Docker so its a bit of a pain to modify so I'll have to double check. Thanks for all the extra info.

Also I didn't get much time to work on this, but I did at least fix a few flake8 and pep8 errors, mostly whitespace related things: https://github.com/trashcan/pylutron-caseta/commit/3dd621a76a7cfd5012150234a5497d7ac69da1ba

No idea on what the policy on forking is, but I have seen that at least some of the libraries HA uses are written by the authors and on github and pypi (like https://github.com/balloob/pychromecast)

@trashcan I made some updates to my pylutron_caseta and to my homeassistant forks/pull requests . I modify the create tls method in pylutron_caseta to accept a boolean. If true ssl verification will be set to CERT_REQUIRED and false will set it to none. The default in pylutron_caseta will be True. I then added a new optional config point to the lutron caseta component ("cert_required"). The default value for this in HA is false. Setting up this way, should get it to work without any code changes (line 50 above) and will keep HA and pylutron_caseta flexible for why it was every changed.

https://github.com/home-assistant/home-assistant/pull/24770
https://github.com/gurumitts/pylutron-caseta/pull/34
https://github.com/home-assistant/home-assistant.io/pull/9780

Also, the updates I made do not solve the reported issues regarding the Pro Hub. Additional research will be needed to get to the bottom of that. I don't have a pro bridge. So someone else will likely have to pick it up from here to test fully. Happy to contribute though.

One thing to not with my pylutron pull request is that it was updated recently from what is in pypi to require ssl. This doesn't seem to work in homeassistnat so I had to revert back to ssl_context.verify_mode = ssl.CERT_NONE on line 50.

I think there's a misunderstanding about the SSL required flag. The version of pylutron_caseta on PyPi does have the SSL required flag. You can check the code for yourself: https://pypi.org/project/pylutron_caseta/#files If you're having problems with the SSL certificates you should make sure you are using the same ones in your test environment that you were using in Home Assistant, and if those are the same check if you're using the same version of Python because I think there might have been an issue with that before.

You can also try checking the certificates using openssl s_client, but there was something weird about SNI: https://github.com/gurumitts/pylutron-caseta/pull/29

@mdonoughe I see what you mean. I forgot that I put off upgrading my environment to python 3.7. I upgraded to 3.7 and everything is working as you outlined. I un-did my changes in both my HA and pylutron_caseta commit and everything seems to be working. Sorry for the confusion.

It does look like the @gurumitts maintained repo is abandoned. Does anybody have documentation on exactly how best to go about getting HA to use a fork, officially?

bump. i would love working caseta fan support in HA

I would also like to get my Caseta fans working, along with the state changes being maintained.

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Is anyone still having problems with this? The new version supports fans and is more resilient to connection errors.

@mdonoughe The fans now work for me in the .103.x version, as well as maintaining the states of Lutron light switches.

looks fixed to me as well in .103.x

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

I wish I could check, but I switched to the pro hub because of this issue. It continues to work fine on the pro hub, not sure if it is still broken on the non-pro hub.

@trashcan This has been resolved in v.103.x.

This is fixed and can be closed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MartinHjelmare picture MartinHjelmare  ·  3Comments

Elmardus picture Elmardus  ·  3Comments

coolriku picture coolriku  ·  3Comments

kirichkov picture kirichkov  ·  3Comments

piitaya picture piitaya  ·  3Comments