search

upsert / lutron-caseta-pro

Custom Home Assistant Component for Lutron Caseta Smart Bridge PRO / RA2 Select
Apache License 2.0
184 stars 38 forks source link

More than 5 switches causes issues #4

Closed kfcook closed 6 years ago

kfcook commented 6 years ago

Everything works perfectly if I have less than 5 switches manually defined. Once I define 5 or more, I get the following error:

2018-04-07 21:07:13 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/home/homeassistant/.homeassistant/custom_components/lutron_caseta_pro.py", line 251, in _read_next
    yield from callback.call(mode, integration, action, value)
  File "/home/homeassistant/.homeassistant/custom_components/lutron_caseta_pro.py", line 213, in call
    yield from attr(*args, **kwargs)
  File "/home/homeassistant/.homeassistant/custom_components/switch/lutron_caseta_pro.py", line 54, in read_output
    yield from device.async_update_ha_state()
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 192, in async_update_ha_state
    raise RuntimeError("Attribute hass is None for {}".format(self))
RuntimeError: Attribute hass is None for <Entity Master Bedroom Fan: on>

Every time I reboot, the device listed as having the error changes. Sometimes its a switch and sometimes its a fan. When I got this error, I removed one of my switches from my configuration.yaml file. After a reboot, everything worked fine. I tried adding back in the 5th switch and after a reboot, the error came back.

czoog commented 6 years ago

I am not seeing this behavior. I have 19 switches in my config:

`lutron_caseta_pro: bridges:

They all show up correctly in HA. Maybe check for extra space or missing comma?

upsert commented 6 years ago

I am not sure about this one. Looks like the device lost a reference to hass somehow but I don't see the significance of that happening after 5 devices.

It looks like it happens in the callback for the update that happens shortly after the device is registered. It is the first time it gets the state of the device. Could it be a particular device that is in the list? For example if you add the fifth one back and remove a different one does it make a difference?

And you mentioned a fan. Is that a fan speed control like RRD-2ANF available on Ra2 Select? I think those are supposed to act like a dimmer in terms of the Telnet interface and are best left out of the switches list.

kfcook commented 6 years ago

This happened to me today even with 4 devices, so I guess my theory about 5 devices was incorrect.

The fan is connected to a caseta switch, not to a fan controller. I also checked to make sure I didn't have any extra spaces or commas and I don't, but the issue is still happening. I reenabled my 5th switch. Now this issue seems to be happening even to normal dimers:

2018-04-21 20:18:11 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/home/homeassistant/.homeassistant/custom_components/lutron_caseta_pro.py", line 251, in _read_next
    yield from callback.call(mode, integration, action, value)
  File "/home/homeassistant/.homeassistant/custom_components/lutron_caseta_pro.py", line 213, in call
    yield from attr(*args, **kwargs)
  File "/home/homeassistant/.homeassistant/custom_components/light/lutron_caseta_pro.py", line 62, in read_output
    yield from device.async_update_ha_state()
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 192, in async_update_ha_state
    raise RuntimeError("Attribute hass is None for {}".format(self))
RuntimeError: Attribute hass is None for <Entity Living Room Couch: off>

I tried rebooting a few times and each time, the issue seems to be with a different device. I've tried all kinds of variations of adding and removing devices but it doesn't seem to help.

Are there any other logs I could collect?

jbgamez commented 6 years ago

I'm having the same problem. Every so often during a restart things seem to start working correctly until the next restart... This has happened three times (out of maybe 50 restarts) since I started having this problem a couple weeks ago.

I've tried with both the full json file from the app and also the following as a more basic one, and probably 20 iterations in between. I've tried different devices, dimmers and switches, with the same results.

{ "LIPIdList": { "Zones": [ { "Name": "Island Chandelier", "ID": 5, "Area": { "Name": "Kitchen" } } ] } }

Additional debugging can be turned on with this in the configuration.yaml logger: default: info logs: custom_components: debug

I can include full logs here if it'll be helpful.

This is the config that I'm currently using: lutron_caseta_pro: bridges:

Some additional details:

Any thoughts? Anything I can do to help track down the issue?

Thanks!

upsert commented 6 years ago

For this issue, is anything negative happening apart from errors in the log on startup? Do the affected devices not function if this error is seen?

I found this issue that sounds similar so I will add some protections to not update the HA state if the platform is not yet initialized. I should also be able to delay the initial update until after adding the platform to HA.

kfcook commented 6 years ago

When I hit this error, HA stops processing this component entirely. So, none of my Lutron devices are accessible - definitely negative.

Just a data point for me - I rebooted a bunch more times and finally got all of the devices to load up. Didn't change anything. Just kept rebooting until it worked. So, I guess I'm good to go until there is a power outage or HA crashes!!

jbgamez commented 6 years ago

For me, they all load to the main screen, and I can turn things on but not off. It seems to load the correct initial state, but then after turning the light on it still thinks it's off. Scenes work fine, but lights and switches have the same issue.

Also tried with haspbian 0.68.0, same behavior.

I'll give the new commit a try and report back.

Thanks!

jbgamez commented 6 years ago

Looks like that was it! Everything is working now.

I also upgraded to 0.68.1, and it's working there as well.

Thanks again!

ericgcollyer commented 6 years ago

I'm actually having very similar behavior currently on .70.1. My current workaround is to delete the json file that stores the integration report, reboot, and rerun the configuration. I'm seeing the exact same behavior @jbgamez indicated two replies ago. I'm also getting the same error @kfcook is getting:

Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/config/custom_components/lutron_caseta_pro.py", line 258, in _read_next yield from callback.call(mode, integration, action, value) File "/config/custom_components/lutron_caseta_pro.py", line 220, in call yield from attr(*args, **kwargs) File "/config/custom_components/switch/lutron_caseta_pro.py", line 56, in read_output yield from device.async_update_ha_state() File "/usr/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 199, in async_update_ha_state "No entity id specified for entity {}".format(self.name)) homeassistant.exceptions.NoEntitySpecifiedError: No entity id specified for entity Guest Bathroom Ceiling Fan

ericgcollyer commented 6 years ago

I updated to .71 and this issue persists. Interesting fact, it looks like commands are appropriately being sent and received by Lutron, but device states are not being accurately reported to Homeassistant. Here's my reasoning:

If I am experiencing this issue, all lutron devices will appear to be off. If I turn them on, they will turn on in the physical world. In homeassistant, they will briefly appear to be on, before the homeassistant switch turns back off. If I use a dimmer slider, the device will be set to that dimmer level, but will still appear to be off in homeassistant. I have Alexa and the Google Assistant enabled on my homeassistant instance, and I can still use these devices to control my lights. I can say "turn on master bedroom lights" or "set office lights to 50%" and these commands still work, but the states are not accurately displayed in homeassistant.

My gut tells me you were on the right track to delay update reporting as the system works if I delete and re add my integration report.

upsert commented 6 years ago

I have had the issue where the state of switches or dimmers is no longer retained after an upgrade to HA (and lights still work fine), but I'm not sure if it is related to this issue so I didn't add it. It only happens on upgrading through hass.io and then if you restart HA it doesn't happen again so it is difficult to reproduce the exact circumstances. I've never had it happen on a normal startup like in the original comment.

I will look into moving the initial value queries into async_added_to_hass() in the component. That may help with pushing the query for initial value later in the startup sequence.

upsert commented 6 years ago

I've updated the component to set the initial values in a different added_to_hass function to help with this issue. I was waiting for the update 0.72 and with these changes in place, I also had no issue updating to 0.72 and all switches and controls responding as expected.

If you are having any of the issues on upgrade or on HA restart mentioned above, please update your copy of the component and add a comment here if there are still issues.

upsert commented 6 years ago

I've gone through three updates of HA and one firmware update on the Lutron hub to 06.05.14f000 and so far everything is working and no issues on restart.

I will leave this issue open for a bit longer in case there is more feedback.

upsert commented 6 years ago

This issue is now stale and at least for the startup, appears to be resolved. No more issues found or reported. Closing it.