Open/close sensors all stopped working after recent HA update

[beaulebens]

All of my Wyze door sensors suddenly stopped working. Motion sensors seem to work still.

Here's my log with debugging turned on https://pastebin.com/nVJNxnkx

Here's the info from Configuration > Info (running on a Pi)

arch | aarch64
-- | --
chassis | embedded
dev | false
docker | true
docker_version | 19.03.11
hassio | true
host_os | HassOS 4.13
installation_type | Home Assistant OS
os_name | Linux
os_version | 4.19.127-v8
python_version | 3.8.5
supervisor | 247
timezone | America/Denver
version | 0.116.2
virtualenv | false

I've tried a few restarts, and have tried removing and re-adding the hub/USB dongle.

My configuration.yaml just has;

binary_sensor:
  - platform: wyzesense
    device: auto

At first I thought it was related to a HA update (0.116.2), but I realized that I have a recorded door open/close after I did that update, so I guess it's not that.

[erlanger]

I am also having a problem after the 0.116.2 update, I get the following error in the log:

ERROR (Thread-6) [custom_components.wyzesense.wyzesense_custom] Invalid packet: b'55aa4304280101'

Besides the normal warning about a custom component I don't have any other wyzesense errors in the log.

but I am getting data from the sensors.

[jes1417]

I am also seeing these errors as of late, I also noticed the sensor getting stuck "on" I can go to devtools/states and set to off and they will work again but it's happening more frequently.

Logger: custom_components.wyzesense.wyzesense_custom
Source: custom_components/wyzesense/wyzesense_custom.py:140
Integration: wyzesense (documentation)
First occurred: 3:25:14 PM (1 occurrences)
Last logged: 3:25:14 PM

Mismatched checksum, remote=079E, local=0812

Logger: custom_components.wyzesense.wyzesense_custom
Source: custom_components/wyzesense/wyzesense_custom.py:139
Integration: wyzesense (documentation)
First occurred: 3:25:14 PM (1 occurrences)
Last logged: 3:25:14 PM

Invalid packet: b'55aa531d190000757523a2f026a2373739423233464502175e0001000e665e079e'

[jes1417]

And then right after a reboot

Logger: custom_components.wyzesense.wyzesense_custom
Source: helpers/entity.py:422
Integration: wyzesense (documentation)
First occurred: 8:33:24 PM (2 occurrences)
Last logged: 8:33:27 PM

Ignoring non-OSError in worker thread. Please share the error logs with the developers.
Traceback (most recent call last):
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 373, in _Worker
    self._HandlePacket(pkt)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 346, in _HandlePacket
    handler(pkt)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 271, in _OnSensorAlarm
    self.__on_event(self, e)
  File "/config/custom_components/wyzesense/binary_sensor.py", line 110, in on_event
    entities[event.MAC].schedule_update_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 422, in schedule_update_ha_state
    assert self.hass is not None
AssertionError

[swm5126]

Also having this issue. Not getting any errors that I can see with invalid packets, but my door sensors have all ceased working as well after the recent HA update.

[sanmagal]

Same problem here. the motion sensor working fine but the door sensors are not detecting the state change. The only log msg I get is :

Logger: homeassistant.loader Source: loader.py:440 First occurred: 11:42:05 (1 occurrences) Last logged: 11:42:05 You are using a custom integration for wyzesense which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.

System info:

	armv7l
chassis
dev	false
docker	true
docker_version	19.03.8
hassio	true
host_os	Raspbian GNU/Linux 10 (buster)
installation_type	Home Assistant Supervised
os_name	Linux
os_version	4.19.97-v7l+
python_version	3.8.5
supervisor	247
timezone	Europe/Lisbon
version	0.116.4
virtualenv	false

[langejos]

Same issue here, a few days after upgrading to 0.116.4 all sensors stopped working. Log shows: File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 193, in _async_setup_platform await asyncio.shield(task) File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/wyzesense/binary_sensor.py", line 78, in setup_platform _LOGGER.debug("Attempting to open connection to hub at " + config[CONF_DEVICE]) TypeError: can only concatenate str (not "NoneType") to str

[geomoetric]

Same issue here for both door and motion sensors. Has anyone had luck reinstalling their sensors?

[langejos]

Same issue here for both door and motion sensors. Has anyone had luck reinstalling their sensors?

I don't think reinstallation solves the issue. Looks like something's broken in the integration.

[lee3521]

So far I have been able to run it with no issues under 116.4 and Ubuntu server 20.04. I only had two hiccups along the way.

1. I banged my head against the wall for hours trying to make the sense bridge work only to find that the usb sense bridge itself was bad. Replaced the bridge with a spare and all worked great.
2. After an HA upgrade and reboot, my door contacts and motion sensors stopped working. Upon investigating the issue, I found that the permissions had changed somehow on /dev/hidraw0 (possibly self inflicted due to installing Linux updates just before rebooting.) I corrected the permissions, unplugged / re-plugged the sense bridge and restarted HA and all started working again and has been working ever since.

Just curious, if you were to do a ls -la /dev/hi* do you actually see the device? If so, what are the permissions? Also, I am running my installation in a docker container so I can launch a terminal within the docker container and view the /dev folder to verify that the device is being passed from the host into the docker container.

If I were a programmer I would try to help you guys out, but unfortunately, if its much more than permissions, I'm not of much help.

[beaulebens]

Just curious, if you were to do a ls -la /dev/hi* do you actually see the device?

I am not able to see the device this way, and if I do a ha hardware info I see the following (excerpted);

serial:
- /dev/ttyACM0
- /dev/serial/by-id/usb-0658_0200-if00
- /dev/ttyACM1
- /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2221308-if00
- /dev/ttyAMA0
usb:
- /dev/bus/usb/001/001
- /dev/bus/usb/001/002
- /dev/bus/usb/001/003
- /dev/bus/usb/001/004
- /dev/bus/usb/001/005
- /dev/bus/usb/001/007
- /dev/bus/usb/002/001

I've got Wyze, a ConBee Zigbee adaptor, and a Z-Wave stick all connected via USB.

[langejos]

Just curious, if you were to do a ls -la /dev/hi* do you actually see the device? If so, what are the permissions? Also, I am running my installation in a docker container so I can launch a terminal within the docker container and view the /dev folder to verify that the device is being passed from the host into the docker container.

That was actually very helpful, thank you! I realized the bridge is now on hidraw1 and no longer on 0. I updated my config from "auto" to "/dev/hidraw1" and paired all sensors again.

Thank you!

[lee3521]

ha hardware info

@beaulebens What platform (hardware / software) are you running HA on?

[beaulebens]

@lee3521 I'm using a Raspberry Pi, with HassOS 4.14, and am now on Home Assistant 0.116.4.

Here are some system details in case any are relevant:

arch: aarch64
channel: stable
docker: 19.03.11
features:
- reboot
- shutdown
- services
- network
- hostname
- hassos
hassos: "4.14"
homeassistant: 0.116.4
hostname: homeassistant
logging: info
machine: raspberrypi4-64
operating_system: HassOS 4.14
supervisor: "249"
supported: true
supported_arch:
- aarch64
- armv7
- armhf
timezone: America/Denver```

[lee3521]

@beaulebens If you ssh into your Raspberry pi, can you run the command: dmesg | grep e024 e024 should be the product id of the Wyze sense usb bridge. I'll load an identical config to yours in a spare Raspberry pi tomorrow when I get my 2nd spare sense bridge. I will see if I can duplicate the problem you are having. This is how my machine sees the sense bridge from the above dmesg command:

This is how the device shows up in my /dev folder:

[beaulebens]

@lee3521 thanks for that, I see

[    1.785289] usb 1-1.4.1: New USB device found, idVendor=1a86, idProduct=e024, bcdDevice= 1.0c
[    1.792403] hid-generic 0003:1A86:E024.0001: hiddev96,hidraw0: USB HID v1.00 Device [HID 1a86:e024] on usb-0000:01:00.0-1.4.1/input0

So looks like i'm on hidraw0. With that info, I changed my configuration.yaml to use device: "/dev/hidraw0" and restarted, then was able to confirm that my motion sensors are still working.

I still can't see the hidraw0 entry in /dev.

Unfortunately I don't seem to be able to get door sensors still either;

• tried doing a wyzesense.scan service call (completed with no sensors found)
• tried removing (wyzesense.remove) a sensor, and then scanning/adding it back along with pushing a pin in the hole -- "completed with no sensors found" again

[cree8]

Seems as if this may be dead in the water. I have numerous amounts of these sensors and an HA update broke it, along with seemingly no feedback from the original creator. Looks like it may be time to retire these sensors and write them off.

[HypervisorX]

I had basically this same issue myself, but in my case I was just beginning to setup Home Assistant on a Pi 4 with Wyze so I had never had the fortune of having the dongle work properly. After spending a fair bit of time debugging the issue, learning about Home Assistant, and trying to come up with a solution that will work, I found one that seems to always work for my setup. I have tried to add more detail than usual so that it can be helpful to as many people as possible.

The basic premise is to recompile the built in Home Assistant Operating System (formerly HassOS) with support for uhubctl and then add an extremely basic service definition that is called every time at boot that will send a command to uhubctl causing it to cycle the USB ports power, which then causes the wyze USB device to start properly responding and appear as expected such as in /dev/hidraw0 More details below.

Follow the instructions to compile Home Assistant OS. See Development Getting Started for more details, but once you have downloaded the copy of the operating-system see my instructions on what to edit before proceeding with the rest of the compilation. The good news is we only need to simply edit 1 file, and add 1 file before actually compiling.

This is assuming you are using a Raspberry Pi 4. If you have a different device you will need to edit a different defconfig file other than rpi4_defconfig I will be assuming you are following the example path layout in the Development Getting Started guide where the operating system repo is checked out inside of the ~/codebase/ folder. After checking out or downloading a copy of the operating-system repository edit ~/codebase/operating-system/buildroot-external/configs/rpi4_defconfig and add the following line in order to add uhubctl support. BR2_PACKAGE_UHUBCTL=y You should probably search and make sure there is not already a BR2_PACKAGE_UHUBCTL line defined somewhere else in the file, especially if you are doing this for another platform or these instructions are old by the time you are following them.

create a new service file for cycling the USB hub power at ~/codebase/operating-system/buildroot-external/rootfs-overlay/usr/lib/systemd/system/usb-power-cycle.service with the following contents

[Unit]
Description=Power Cycle USB Devices and Ethernet using uhubctl
RequiresMountsFor=/sbin
ConditionFileNotEmpty=/sbin/uhubctl

[Service]
#cycle hub off wait Delay (-d) of 1 second and turn hub back on. On Raspberry Pi <4 the 
#Ethernet is attached to hub and will also drop while the hub is being cycled.
ExecStart=/sbin/uhubctl -a cycle -d 1

[Install]
WantedBy=sysinit.target

The only other notes I have for you is that your prize should be an image you can write directly to an SD card if you are successful. The image will be in the ~/codebase/operating-system/release/ folder. Also when checking out your copy of the operating system you probably want to check out the current stable version rather than whatever the current development version is so when checking it out use the tag for the release number you want, or just get the source code zip file for that version instead of whatever the dev version is. Also in the Development Getting Started when you get to the step that mentions make ova, besides obviously needing it to be make rpi4 instead of ova, I found I had to call it with sudo FORCE_UNSAFE_CONFIGURE=1 otherwise eventually partway through the compilation there would be an error so if you run into any errors running make rpi4, try running sudo FORCE_UNSAFE_CONFIGURE=1 make rpi4 instead for that step

I imagine there is probably a better way of doing things but at least this provides a working solution that doesn't require physical intervention and is fully automatic. I'd also love to hear what the proper way to solve this is, I just needed something that works; I have HA set up somewhere else physically so walking over to unplug/replug the USB bridge is not even possible in my case even if that were somehow the desired solution.

Also for anyone trying to more thoroughly track down the cause, or solve the problem, it seems to be caused by the wyze USB device not properly responding to some kind of setup request (I think?). In the host logs you will find lots of entries similar to:

[    9.989857] usb 1-1.4: new full-speed USB device number 12 using xhci_hcd
[   10.090065] usb 1-1.4: device descriptor read/64, error -32
[   10.310050] usb 1-1.4: device descriptor read/64, error -32
[   10.440078] usb 1-1-port4: attempt power cycle
[   11.099861] usb 1-1.4: new full-speed USB device number 13 using xhci_hcd
[   11.100104] usb 1-1.4: Device not responding to setup address.
[   11.320067] usb 1-1.4: Device not responding to setup address.
[   11.539857] usb 1-1.4: device not accepting address 13, error -71
[   11.639856] usb 1-1-port4: unable to enumerate USB device

I also found it very interesting that the errors state it will attempt to power cycle the device, but clearly that's not working properly. You can see in the logs that its claiming to try and power cycle the device when its not working, but likely whatever is supposedly doing the power cycling probably doesn't properly handle the unusual case of at least the raspberry pi 4 which has 4 ports that are ganged together (in terms of power switching) in addition to those ports being both a USB2 hub and a USB3 hub more details.

Luckily uhubctl does work properly for power cycling the pi USB hubs and so compiling Home Assistant OS with that and adding a service that calls it to cycle the usb hubs at boot seems to 100% resolve the issue for me. After the service calls uhubctl to power cycle the usb hubs, the device properly identifies itself and everything works properly.

[roblefko]

@cree8, what problem are you encountering?

[cree8]

@cree8, what problem are you encountering?

I get an AssertionError twice during the startup of the plugin, afterwards no more packets are received from the USB hub. Well at least, the log does not show any more Wyzesense debug messages

Traceback (most recent call last): File "/config/custom_components/wyzesense/wyzesense_custom.py", line 373, in _Worker self._HandlePacket(pkt) File "/config/custom_components/wyzesense/wyzesense_custom.py", line 346, in _HandlePacket handler(pkt) File "/config/custom_components/wyzesense/wyzesense_custom.py", line 271, in _OnSensorAlarm self.__on_event(self, e) File "/config/custom_components/wyzesense/binary_sensor.py", line 110, in on_event entities[event.MAC].schedule_update_ha_state() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 422, in schedule_update_ha_state assert self.hass is not None AssertionError

[xtalker]

So frustrating! I made contact sensors into deadbolt sensors and installed on 5 doors. Worked great for quite awhile, now nothing seems to work. Dead sensors have the "5 blink issue". Now after a "Home Assistant Core 0.117.0" update none of them work!

[roblefko]

I rolled back to HA 0.116.0 a few days ago, and have been trouble-free.

[fifa255]

I had same AssertionError. I believe its because the sensor is being update before homeassistant is fully started after upgrading so the addon fails start properly.

The below modification to binary_sensor.py in the custom_components/wyzesense directory seems to make things right. You also need to unplug the usb dongle and plug back it back in and restart home assistant.

CHANGE: entities[event.MAC].schedule_update_ha_state() TO: try: entities[event.MAC].schedule_update_ha_state() except (AttributeError, AssertionError): _LOGGER.debug("wyze Sensor not yet ready for update")

At least this worked for me. Hope it helps others.

[cjackson234]

I had same AssertionError. I believe its because the sensor is being update before homeassistant is fully started after upgrading so the addon fails start properly.

The below modification to binary_sensor.py in the custom_components/wyzesense directory seems to make things right. You also need to unplug the usb dongle and plug back it back in and restart home assistant.

CHANGE: entities[event.MAC].schedule_update_ha_state() TO: try: entities[event.MAC].schedule_update_ha_state() except (AttributeError, AssertionError): _LOGGER.debug("wyze Sensor not yet ready for update")

At least this worked for me. Hope it helps others.

Why not throw up a pull request for this?

[stephywephy88]

I had same AssertionError. I believe its because the sensor is being update before homeassistant is fully started after upgrading so the addon fails start properly.

The below modification to binary_sensor.py in the custom_components/wyzesense directory seems to make things right. You also need to unplug the usb dongle and plug back it back in and restart home assistant.

CHANGE: entities[event.MAC].schedule_update_ha_state() TO: try: entities[event.MAC].schedule_update_ha_state() except (AttributeError, AssertionError): _LOGGER.debug("wyze Sensor not yet ready for update")

At least this worked for me. Hope it helps others.

Hi, when I tried this, I got this in my log and all sensors turned "Unavailable":

File "/config/custom_components/wyzesense/binary_sensor.py", line 110 except (AttributeError, AssertionError): ^ SyntaxError: invalid syntax

I spaced the three lines direct underneath one another just as your example shows - was that the correct syntax?

[geomoetric]

Recently removed some laggy scrape integrations from my config.yaml file and suddenly everything works again? Seems to further support the theory that anything interrupting the restart process throws this integration off.

[cree8]

The correct form is as follows: try: [tabbed content] except (error): [tabbed con

I had same AssertionError. I believe its because the sensor is being update before homeassistant is fully started after upgrading so the addon fails start properly. The below modification to binary_sensor.py in the custom_components/wyzesense directory seems to make things right. You also need to unplug the usb dongle and plug back it back in and restart home assistant. CHANGE: entities[event.MAC].schedule_update_ha_state() TO: try: entities[event.MAC].schedule_update_ha_state() except (AttributeError, AssertionError): _LOGGER.debug("wyze Sensor not yet ready for update") At least this worked for me. Hope it helps others.

Hi, when I tried this, I got this in my log and all sensors turned "Unavailable":

File "/config/custom_components/wyzesense/binary_sensor.py", line 110 except (AttributeError, AssertionError): ^ SyntaxError: invalid syntax

I spaced the three lines direct underneath one another just as your example shows - was that the correct syntax? tent]

[cree8]

I want to report back that using the try block to handle the exception worked like a charm. Pull request needed indeed.

[RoldyBuffalo]

Wyze Home Assistant integration request Please Upvote this integration request on the wyze forums if possible. 70+ open issue tickets on this repo. Tons of other folk with similar issues. We need a Wyze API. Thank you for reading. :)

[drinfernoo]

Please also vote in the API for Download and Control thread, as what is really needed from Wyze is an API... the community will likely handle the rest in short order 😁

[cj922]

If you're like me and your brain was ignoring the word "try", this is the correct syntax:

Change:

entities[event.MAC].schedule_update_ha_state()

TO:

try:
     entities[event.MAC].schedule_update_ha_state()
except (AttributeError, AssertionError):
     _LOGGER.debug("wyze Sensor not yet ready for update")

This seemed to fix issues I was having.

[drinfernoo]

I'm not having this issue. I have one motion sensor and six contact sensors, that are all working fine, as far as I can tell...

Is there anything I can do to help out?

[stanwebber]

the erlanger fork of this repository has this fix correctly implemented if you need to see an example or want a quick build 1 commit past master.