search

SecKatie / ha-wyzeapi

Home Assistant Integration for Wyze devices.
746 stars 114 forks source link

Color Bulbs: "Failed to connect to bulb" #315

Closed tggman closed 2 years ago

tggman commented 2 years ago

Describe the bug Unable to control (e.g. power on/off) my Wyze Color Bulbs. Issue began when local loop/local control was added to the WyzeAPI

To Reproduce Steps to reproduce the behavior:

  1. Toggle the power on one of the offending bulbs.
  2. Bulb fails to respond
  3. Wait a few seconds and observe how the power slider for the bulb toggles back to it's previous state

Notes:

  1. Issue seems to occur randomly on different bulbs, but once the problem occurs on a given bulb, it remains unresponsive.
  2. Power cycling the bulbs coupled with a HA restart sometimes (but not always) fixes the issue.
  3. Bulbs may work initially after a HA restart, but can fail function later - after its been up for a time
  4. Bulbs function as expected in the Wyze app.

Expected behavior Function as expected via automations/manual control.

System configuration WyzeAPI v0.1.2

System Health

version core-2021.12.3
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.7
os_name Linux
os_version 5.10.83
arch aarch64
timezone America/Chicago
Home Assistant Community Store GitHub API | ok -- | -- Github API Calls Remaining | 5000 Installed Version | 1.18.0 Stage | running Available Repositories | 929 Installed Repositories | 2
Home Assistant Supervisor host_os | Home Assistant OS 7.0 -- | -- update_channel | stable supervisor_version | supervisor-2021.12.2 docker_version | 20.10.9 disk_total | 113.9 GB disk_used | 10.2 GB healthy | true supported | true board | odroid-n2 supervisor_api | ok version_api | ok installed_addons | Samba share (9.5.1), Terminal & SSH (9.2.1), Let's Encrypt (4.12.0), Duck DNS (1.14.0), Z-Wave JS (0.1.50)
Lovelace dashboards | 1 -- | -- resources | 0 views | 13 mode | storage

home-assistant.log

home-assistant.log

ItsRhen commented 2 years ago

Same happening here. I appreciate the work on this integration!

jscherry commented 2 years ago

Color bulbs stopped connecting after light strip added. Light strip pro working well though. Josh i've been reading the info on github pull releases etc so I can help in the future.

brg468 commented 2 years ago

All color bulbs? Or the same intermittent behavior as described above?

Color bulbs stopped connecting after light strip added. Light strip pro working well though. Josh i've been reading the info on github pull releases etc so I can help in the future.

tggman commented 2 years ago

Until this issue is resolved, can we please either disable the local loop feature (which I would love if it was reliable) or make it an option. May smart home is acting real dumb...

Also, one of my 8 bulbs failed to respond/power on via the Wyze app and the Wyze app indicated that it was no longer connecting to the Wyze cloud! I actually had to perform a hard reset (turn bulb on/off 5 times) to bring it back to life. This could be unrelated - but I doubt it since it's never happened before.

djljr commented 2 years ago

I believe the cause of the color bulbs not working is this conditional here: https://github.com/JoshuaMulliken/wyzeapy/pull/32/files#diff-68dc0b66d98ff1a4284e5dc7e17a632d16e7f4091b61dc966556ed11ecb868f5R83

The and has higher precedence than the or causing it to try and set values for the color property of the bulb that are not hex strings. This causes this error when it asserts the value is a hex string, at least for me:

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 431, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 684, in async_device_update
await task
File "/config/custom_components/wyzeapi/token_manager.py", line 45, in inner_function
await func(*args, **kwargs)
File "/config/custom_components/wyzeapi/light.py", line 232, in async_update
self._bulb = await self._bulb_service.update(self._bulb)
File "/usr/local/lib/python3.9/site-packages/wyzeapy/services/bulb_service.py", line 88, in update
bulb.color = value
File "/usr/local/lib/python3.9/site-packages/wyzeapy/services/bulb_service.py", line 60, in color
assert re.match(r"^([A-Fa-f\d]{6}|[A-Fa-f\d]{3})$", value) is not None
AssertionError
brg468 commented 2 years ago

I believe the cause of the color bulbs not working is this conditional here: https://github.com/JoshuaMulliken/wyzeapy/pull/32/files#diff-68dc0b66d98ff1a4284e5dc7e17a632d16e7f4091b61dc966556ed11ecb868f5R83

The and has higher precedence than the or causing it to try and set values for the color property of the bulb that are not hex strings. This causes this error when it asserts the value is a hex string, at least for me:

Yep, you are absolutely right. I screwed that one up. Will get a fix in tomorrow!

brg468 commented 2 years ago

New PR's submitted to correct the broken color bulbs.

https://github.com/JoshuaMulliken/ha-wyzeapi/pull/316 https://github.com/JoshuaMulliken/wyzeapy/pull/33

I don't have any bulbs, which is how I missed this the first time. If anybody with bulbs wants to test this I would appreciate it.

tggman commented 2 years ago

New PR's submitted to correct the broken color bulbs.

316 JoshuaMulliken/wyzeapy#33

I don't have any bulbs, which is how I missed this the first time. If anybody with bulbs wants to test this I would appreciate it.

Be glad to ... how do I get the updated/latest version? Obviously I can handle via HACS (e.g. if it comes out as a beta) or I can download and manually copy the files into the custom_components folder. However, if there are other files that need updating elsewhere I'd need to know where they are / where to put them.

brg468 commented 2 years ago

If you want you can download and replace the wyzeapi folder in custom_components from here .

Then just drop the wyzeapy folder into your config folder from here (That will use the updated dependency).

That being said I think an update will be out soon.

tggman commented 2 years ago

@brg468 for test purposes, can I simply replace lines 120-122 with the new code in lines 120-124 in the file lights.py?

brg468 commented 2 years ago

Unfortunately no, there was a similar error in bulb_service.py in the dependency (wyzeapy). They both need to be updated. If you can find wyzeapy you can update it as well, or dropping that folder into your config should have the same effect.

tggman commented 2 years ago

I've looked for wyzeapi in the past (so as to avoid installing HACS) but gave up. Didn't know I could just drop it in the config folder. Thanks for the info.

I don't mind doing this if it becomes necessary, but if it fails to correct the issues, there will still be questions. So at this point, lets just wait for the update to be pushed out and take it from there. Thanks again for your help and support.

brg468 commented 2 years ago

👍. And just to be clear, this won’t address the original issue of the bulbs intermittently stopping working, this is just to fix the issue with all color bulbs that was introduced with the light strip addition.

tggman commented 2 years ago

That is exactly my concern. I myself didn't think it would solve the disconnect issue, but I thought that was the consensus here. Well that sucks.

I am really getting sick of Wyze on so many fronts. I have a ton of LIFX lights which cost 3x more but have an open API and work flawlessly. Getting real close to biting the bullet and spending a bunch of money on LIFX. Anybody interested in 8 Wyze color bulbs? LOL

tggman commented 2 years ago

👍. And just to be clear, this won’t address the original issue of the bulbs intermittently stopping working, this is just to fix the issue with all color bulbs that was introduced with the light strip addition.

@JoshuaMulliken would it make sense at this point to disable local control until we find an actual fix for the disconnect issue? Right now 5 out of my 8 bulbs fail to connect - even after a HA restart.

brg468 commented 2 years ago

@tggman Just curious,..Are they unavailable in HA or uncontrollable? Also, if its still available, does the IP address for the bulb(s) shown in the attributes in HA still reflect the correct IP?

tggman commented 2 years ago

As it stands now, they are unavailable - which seems to coincide with them not coming back after a HA restart. And when they are unavailable, the IP and MAC attributes are missing so I can't say.

When I first encountered the problem, they simply failed to respond as I described in this issue. At that time, I checked the MAC (and the IP but not as sure) and it was correct.

brg468 commented 2 years ago

Are you running the newest version (so far) that added the light strips? Any new warn/error messages on startup with them being unavailable?

tggman commented 2 years ago

I'll restart in a sec, but here is what it looks like after its been running for 24hrs

Logger: homeassistant.helpers.service Source: helpers/service.py:129 First occurred: December 21, 2021, 6:22:50 PM (542 occurrences) Last logged: 4:08:47 PM

Unable to find referenced entities light.kitchen_microwave Unable to find referenced entities light.kitchen_stove Unable to find referenced entities light.kitchen_ceiling_1, light.kitchen_ceiling_2, light.kitchen_ceiling_3 Unable to find referenced entities light.basement_desk_lamp_2 Unable to find referenced entities light.laundry_1, light.laundry_2

tggman commented 2 years ago

Here's the (warning level) errors on startup:

Logger: homeassistant.components.light Source: custom_components/wyzeapi/light.py:232 Integration: Light (documentation, issues) First occurred: 4:17:42 PM (8 occurrences) Last logged: 4:17:43 PM

wyzeapi: Error on device update! Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 431, in _async_add_entity await entity.async_device_update(warning=False) File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 684, in async_device_update await task File "/config/custom_components/wyzeapi/token_manager.py", line 45, in inner_function await func(*args, **kwargs) File "/config/custom_components/wyzeapi/light.py", line 232, in async_update self._bulb = await self._bulb_service.update(self._bulb) File "/usr/local/lib/python3.9/site-packages/wyzeapy/services/bulb_service.py", line 88, in update bulb.color = value File "/usr/local/lib/python3.9/site-packages/wyzeapy/services/bulb_service.py", line 60, in color assert re.match(r"^([A-Fa-f\d]{6}|[A-Fa-f\d]{3})$", value) is not None AssertionError

Logger: homeassistant.helpers.service Source: helpers/service.py:129 First occurred: 4:17:49 PM (2 occurrences) Last logged: 4:17:49 PM

Unable to find referenced entities light.family_room_tv_bookshelf (this is the guy that I had to hard reset at one point)

brg468 commented 2 years ago

Ok that first error is what was introduced by my (poorly) added light strip addition. So for now that’s blocking anything from being added.

tggman commented 2 years ago

I believe the cause of the color bulbs not working is this conditional here: https://github.com/JoshuaMulliken/wyzeapy/pull/32/files#diff-68dc0b66d98ff1a4284e5dc7e17a632d16e7f4091b61dc966556ed11ecb868f5R83

The and has higher precedence than the or causing it to try and set values for the color property of the bulb that are not hex strings. This causes this error when it asserts the value is a hex string, at least for me:

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 431, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 684, in async_device_update
await task
File "/config/custom_components/wyzeapi/token_manager.py", line 45, in inner_function
await func(*args, **kwargs)
File "/config/custom_components/wyzeapi/light.py", line 232, in async_update
self._bulb = await self._bulb_service.update(self._bulb)
File "/usr/local/lib/python3.9/site-packages/wyzeapy/services/bulb_service.py", line 88, in update
bulb.color = value
File "/usr/local/lib/python3.9/site-packages/wyzeapy/services/bulb_service.py", line 60, in color
assert re.match(r"^([A-Fa-f\d]{6}|[A-Fa-f\d]{3})$", value) is not None
AssertionError

Yeah I noticed ... which is what gave me hope

tggman commented 2 years ago

Question: Does wyzeapi use the MAC or IP?

brg468 commented 2 years ago

Mainly the MAC, but it looks like for local control it’s using the IP to send the command.

tggman commented 2 years ago

Well at this point lets wait for the dust to settle and update push. I'm guessing things will improve but not be 100% but who knows. Take care

tggman commented 2 years ago

As it stands now, the resolution of issue #316 by @brg468 seems to have corrected this issue. Once @JoshuaMulliken merges both ha-wyzeapi and wyzeapi into the master, I'll reupdate, test it for a few days and close this issue.

SecKatie commented 2 years ago

@tggman It has been merged and released to master. I am away from my main machine so I cannot test super heavily. Thanks for all your help with getting this tested and working!

tggman commented 2 years ago

No problem @JoshuaMulliken. Glad to help.

Just updated to the master and so far so good. I'll wait a bit and close the issue if all remains well over the next couple days and to give those watching/participating in this issue a chance to sound off if they are still having any relevant issues.

boomam commented 2 years ago

Just to add to this - the latest update (0.1.4) has made the lights appear in HA again, however it does nothing. I can see the state/s in HA if I go and make the change in the Wyze app, however tapping the lovelace card buttons to turn on/off, adjusting the brightness, etc. is broken. Does nothing.

Error from the log - 

Logger: wyzeapy.services.base_service
Source: /usr/local/lib/python3.9/site-packages/wyzeapy/services/base_service.py:613
First occurred: 20:48:19 (29 occurrences)
Last logged: 21:09:02

* Failed to connect to bulb
tggman commented 2 years ago

@boomam I'm guessing you tried this already but I'll ask anyhow. did you try electrical power cycling the bulbs (pull power/wait 5-10s/restore power), then restarting HA? I had to do a bunch of gymnastics to get my bulbs to work right after this fix.

I also noticed that if the Wyze App and HA are initially out of sync, one can undo what the other does until they get back in sync.

boomam commented 2 years ago

@boomam I'm guessing you tried this already but I'll ask anyhow. did you try electrical power cycling the bulbs (pull power/wait 5-10s/restore power), then restarting HA? I had to do a bunch of gymnastics to get my bulbs to work right after this fix.

I also noticed that if the Wyze App and HA are initially out of sync, one can undo what the other does until they get back in sync.

Morning! I will try that when i get home tomorrow and report back :-)

djljr commented 2 years ago

Everything working well on my end after the fix, thanks @brg468 !

boomam commented 2 years ago

Just re-tested after doing a power off of the bulbs, same issue. The state shows in HA (on, off, what its colour is, etc.) but there is zero control. Same errors as before - 

Logger: wyzeapy.services.base_service
Source: /usr/local/lib/python3.9/site-packages/wyzeapy/services/base_service.py:613
First occurred: 24 December 2021, 20:48:19 (39 occurrences)
Last logged: 14:53:48
* Failed to connect to bulb XYZ
boomam commented 2 years ago

To add, interestingly, blowing the config/addon/HACS integration out, and re-adding it, appears to make it work again. Only issue I've noticed is that the grouping of lights for the kitchen (2x lights) doesn't work, despite the same names on the entities.

tggman commented 2 years ago

At this point, I think it's best to re-open this issue since it seems to be different enough from issue #297 and is/may be specific to color bulbs and the local IP method only.

Opinion / Suggestion: Until this issue can be resolved and IMHO, it's time we go back to using the cloud method of controlling color lights instead of using the local IP. The local IP method just isn't working reliably enough (for me at least) and it seems like we are no closer to finding root cause let alone a fix.

brg468 commented 2 years ago

@tggman would you want to try this out and see if it works for you? In the limited amount of testing I did (I only have the light stirp and no bulbs but I was able to reproduce what seemed like the same error) it seemed to work. There will be a delay of a few seconds when a bulb no longer responds locally but after that it should flag as offline and send the rest of the commands to the cloud for that bulb. 🤞 Again put the wyzeapy folder in your config folder, nothing to change in custom_components.

https://github.com/brg468/wyzeapy/tree/cloud-fallback-test

tggman commented 2 years ago

Sure I'll give it a shot! I'll Install it tomorrow. Be advised that it will take quite a bit of time (at least a week) to fully vet since this is a highly intermittent issue. Will this create a log entry each time it's forced to fall back to the cloud?

brg468 commented 2 years ago

It will only log the error once when it first happens.

If you want to, you can replace the light.py file or the whole ha-wyzeapi folder in custom_components with this. I added an attribute to indicate cloud status in HA

https://github.com/brg468/ha-wyzeapi/tree/cloud-state

tggman commented 2 years ago

@brg468 it's Installed and running. I'll let you know ... and thanks!!

Note: All of my bulbs show cloud: false on startup and I didn't see any relevant errors in the log on startup. I'll let it run for a bit and put each bulb to the test later today when I get some free time.

kmoniker commented 2 years ago

Following this since I'm having the same problem. Hoping this fix works!

SecKatie commented 2 years ago

@brg468 Great work! Can you submit a PR with your changes?

brg468 commented 2 years ago

@JoshuaMulliken I was gonna let @tggman test it for a day or 2 and assuming it’s working correctly I’ll be happy to submit the PR’s.

tggman commented 2 years ago

@JoshuaMulliken its up and running on my install. the problem is this is a very intermittent issue and I can't force a local access error since we don't know root cause.

I'm not an expert on the release process, but if you're proposing it be released as a beta that would be good since it may take awhile for it to fail local access and revert to he cloud on a single install.

@brg468 will wyzeapy gracefully handle a total network connection fail (no local or internet/cloud access, e.g. router reboot)?

brg468 commented 2 years ago

will wyzeapy gracefully handle a total network connection fail (no local or internet/cloud access, e.g. router reboot)?

Overall that’s probably a better question for Josh, but as far as the changes I made, what I assume would happen is that the attempt to connect locally will fail, it will attempt to use the cloud, which should work again once cloud access is restored. All the devices would continue using the cloud until the next HA restart.

And that assumes you sent a command during the time the router was down..if not it shouldn’t affect anything.

tggman commented 2 years ago

So far, all my bulbs are still functioning BUT I also don't have any cloud: true attributes. So this change remains untested on my HA server as of today -- proving once again, that intermittent problems never occur when you want them to.

I'll keep watching ...

tggman commented 2 years ago

Day 4: Still NO bulb issues or cloud: true attributes. I'll keep monitoring.

InstigatorX commented 2 years ago

@brg468 Dropped your wyzeapy in config and updated light.py. I've got a bulb flagged as Cloud: true, but it's still uncontrollable.

brg468 commented 2 years ago

@brg468 Dropped your wyzeapy in config and updated light.py. I've got a bulb flagged as Cloud: true, but it's still uncontrollable.

Intersting... anything in the logs? And I assume its till controllable from the Wyze app?

InstigatorX commented 2 years ago

Yes, controllable by the Wyze app. Here's the log entry...

Logger: wyzeapy.services.base_service Source: wyzeapy/services/base_service.py:613 First occurred: 2:38:44 PM (1 occurrences) Last logged: 2:38:44 PM

Failed to connect to bulb 7C78B214131E, reverting to cloud.

EDIT: @brg468 Should "_run_action_list" be used instead of "_set_property_list"?

EDIT2: and of course I tried the above, restarted HA, and now bulb works again. Can't get bulb to go cloud_fallback=true.

EDT3: Got one of them to go true and changing to "_run_action_list" made it work.

brg468 commented 2 years ago

EDT3: Got one of them to go true and changing to "_run_action_list" made it work.

Nice catch! It should be _run_action_list for the color bulbs. I swear I tested it and it worked, but I don't have bulbs, only the lightstrip so maybe that's why.

Thanks for testing this out, I'll update and get a PR submitted

EDIT: Just to confirm I wasn't crazy, I tried it again with _set_property_list and _run_action_list. Both work for the lightstrip.