core: Error in lutron.py -- Hass.io loses ability to control LutronRA2 entities
Home Assistant release with the issue: 0.85.1
Last working Home Assistant release (if known): 0.84.6
Operating environment (Hass.io/Docker/Windows/etc.): RPi3, Hass.io
Component/platform: https://www.home-assistant.io/components/lutron/
Description of problem:
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/service.py", line 287, in _handle_service_platform_call
await getattr(entity, func)(**data)
File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/light/lutron.py", line 73, in turn_off
self._lutron_device.level = 0
File "/usr/local/lib/python3.6/site-packages/pylutron/__init__.py", line 591, in level
Output._ACTION_ZONE_LEVEL, "%.2f" % new_level)
File "/usr/local/lib/python3.6/site-packages/pylutron/__init__.py", line 392, in send
self._conn.send(op + out_cmd)
File "/usr/local/lib/python3.6/site-packages/pylutron/__init__.py", line 91, in send
self._send_locked(cmd)
File "/usr/local/lib/python3.6/site-packages/pylutron/__init__.py", line 81, in _send_locked
self._telnet.write(cmd.encode('ascii') + b'\r\n')
File "/usr/local/lib/python3.6/telnetlib.py", line 290, in write
self.sock.sendall(buffer)
TimeoutError: [Errno 110] Operation timed out
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
lutron:
host: 192.168.1.225
username: lutron
password: integration
Traceback (if applicable):
Additional information:
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 145 (69 by maintainers)
Commits related to this issue
- Fix https://github.com/home-assistant/home-assistant/issues/20348 Fix a logging format error in the keypad component to use %s instead of %d for the keypad name. Also add a try/except around the m... — committed to thecynic/pylutron by cdheiser 5 years ago
- Fix https://github.com/home-assistant/home-assistant/issues/20348 Fix a logging format error in the keypad component to use %s instead of %d for the keypad name. — committed to thecynic/pylutron by cdheiser 5 years ago
- Fix https://github.com/home-assistant/home-assistant/issues/20348 Fix a logging format error in the keypad component to use %s instead of %d for the keypad name. — committed to thecynic/pylutron by cdheiser 5 years ago
I’ve pushed version 0.2.5 to pypi, will need to update HASS for new version and hopefully we can close this.
I found the bug. Proposing an edit now.
On Wed, Sep 4, 2019 at 3:04 PM Chris Heiser chris.heiser@gmail.com wrote:
I’m going to give it another go later on this afternoon. Maybe in an effort to get rid of extraneous login entries I deleted something important.
@Tangston311 Will be in the next version.
Once we go over the patch and get it submitted, the process is as follows:
On Thu, Sep 5, 2019 at 2:11 PM Tangston311 notifications@github.com wrote:
Checking in to say that it’s been smooth sailing all day long. Completely stoked to have this problem finally taken care of! Thanks to @cdheiser and @thecynic for your determination and patience.
I’d appreciate a recommendation on how long to leave the issue open. And also I’d appreciate your giving me a heads up on when to remove the custom component. (I know it’s not yet, but if you happen to know the version # that will include the fixed pylutron, please let me know.)
Once again, my thanks. If you guys were in my neighborhood I’d buy you a beer. Or three.
Pretty excited about this! Fingers crossed. I’ve got the new custom component installed on 0.98.3 and am going to let it run overnight. I also re-enabled my customary (non-mimimal) configuration.yaml, the OmniProBridge, and all automations, so I admit to throwing caution to the wind a bit. If things are still working in the AM, that’ll be a very good sign.
I still have all of the loggers enabled in case something goes wrong.
I think everything is there. This is really interesting. The last run of the background loop is at 17:55
2019-09-03 17:55:48 DEBUG (Thread-3) [custom_components.lutron.cdhlutron] Main run loop
It reads a change at 17:56: 2019-09-03 17:56:52 DEBUG (Thread-3) [custom_components.lutron.cdhlutron] Received line ~DEVICE,128,2,40 2019-09-03 17:56:52 INFO (Thread-3) [custom_components.lutron.cdhlutron] Updating 128(Fans 1): c=2 a=40 params=[] 2019-09-03 17:56:52 INFO (Thread-3) [custom_components.lutron.cdhlutron] Keypad: “Fans 1” Button name: “FamilyFan” num: 2 type: “Toggle” direction: “None” Action: 40 Params: []"
And then Thread-3 just goes silent… as if it’s wedged on something, or it’s just dead…
Once I don’t have a toddler nagging me, I’ll update the custom component one more time with some more instrumentation to see what’s happening to that thread. My guess is we’re throwing an uncaught exception, and it’s just killing the thread, and not getting logged.
On Tue, Sep 3, 2019 at 5:48 PM grantalewis notifications@github.com wrote:
I think I know what the problem is. I’ll send an updated custom component later today.
On Sat, Aug 31, 2019, 6:58 AM grantalewis notifications@github.com wrote:
Ok… I’m close to having something really simple, with some exception logging, and converting all debug logging to info logging since AFAICT, the logger doesn’t properly set components to debug, custom or otherwise.
On Fri, Aug 30, 2019 at 2:05 PM grantalewis notifications@github.com wrote:
I upgraded to 0.98.0 this morning:
After 3 hours, the setup was still working and so I took a snapshot and restored it to my RPi3. Unfortunately that caused the problem to occur once again. I’m now going to go back to the Virtual Box install to see if that causes any different behavior.
EDIT 2 hours later: still solid, no problems. I’ll probably leave it running on Virtual Box to see how it behaves for the rest of the night. Then I’ll try the RPi3 again tomorrow.
Just by giving this a once over, it looks like you’re having network issues. Lutron isn’t mentioned until the very end, but it looks like alarm.com is having connectivity issues, as well as darksky and lutron… total guess, it’s hard to tell whats going on with this.
wow, this is great news! Please keep us posted. I’d love it if this was the cause…
The only time I ever suffer connection issues is when I reprogram or otherwise power cycle the main repeater.
On Sun, Aug 18, 2019 at 11:02 AM Jon Gilmore notifications@github.com wrote:
I’m hopeful this will at least help… When I was testing last night with 2 diff HA setups using the same lutron username/password, I did see disconnects on the 2nd instance that started (but the instance kept re-connecting b/c of the re-connect code, lol)
@grantalewis You aren’t being stubborn 😃 I wanted to confirm whether or not we were losing communication with the lutron main repeater or if the issue is somewhere in HASS. Given that you can continue to change state via the API/service calls, it means that the underlying comms are good and the issue is in the HASS integration somewhere (either in HASS or in the callback mechanisms from pylutron)
@Tangston311 trying to reconcile your answer with @grantalewis… hmm
I don’t mean to be stubborn, but unless 0.84.6 is just more tolerant of borderline network issues, I just don’t think it’s network related. I have no problems with 0.84.6 whatsoever – not one, not ever.
I’m glad I found this because I’m experiencing exactly the same issue with HA and Ra2. At first everything seems to work just fine, but after an hour or so I experience the exact behavior seen in the video. My automations and service calls seems to still work just fine, but controlling through the front end becomes unusable.
Happy to do what I can to provide more info to help troubleshoot.
I’m on 93.1 using Hass.io.
Thats a good explanation, I appreciate it. The video helps me understand the behavior, which is different than I was understanding from your previous stuff in writing. Going to continue our convo on discord to keep this issue clean, if we come up with anything, we can post it here.
I had this same problem. Works for me in 0.86.4, failed when I updated to 0.88.1, I rolled back. I’m running HASS.IO in docker on Ubuntu 18.0.4 on a Laptop. Lutron Bridge is model L-BDG2
Error Log Entry:
This sounds like https://github.com/thecynic/pylutron/issues/17