Sensors stopped picking up events #58
Comments
|
More data - I'm trying to launch the CLI to debug, and it appears the device is not showing up on /dev/hidraw0 anymore. I also tried /dev/hidraw1 /dev/hidraw2 etc. with no luck. Something must be causing the device to be unrecognizable after a period of time? |
|
I've left the system in this state to try to debug (and will continue to do so for the next day or two), so if there things you would recommend for me to try or gather some data, I'd be happy to do so. |
|
With the following command I checked my USB devices: My understanding is that HID 1a86:e024 is the wyzesense dongle. It appears it is saying it is on hidraw1, which matches my expectations, as that is what I use in my docker-compose.yaml. Yet when I try CLI for hidraw1 since this issue started happening (it randomly crashed) I see the following: |
|
I've rebooted the VM and still experienced this issue. I rebooted the NUC and am now back up and running, but I worry it will break again in a few days with same cause as I don't know what caused it. I'll monitor and report back if and when it crashes again. |
|
Edit - the below fix did not fix anything.
|
|
Hello - after a couple weeks, my sensors stopped picking up events again. All I see following this event is endless list of PINGREQ and PINGRESP. Any other logs or data I can provide to help track this down? |
|
I've been having this issue for a while as well. I can usually get it running by restarting the service though. My intermediate fix is an automation that makes an ssh call to restart the service if it hasn't seen any MQTT events from the service in the last hour. With the amount of contact and motion sensors I have, we rarely go that long without triggering one of them. |
|
@nabahr I’m curious if you are using docker as well? |
|
I am running the service in a proxmox VM (Debian 10), along with zigbee2mqtt. I haven't had any issues with my zigbee service so far. Here is my VM config. |
|
@nabahr and @RonSpawnson I've not been unfortunate enough to run into this issue lately. Next time it happens can you publish to the reload MQTT topic so that we can force it to attempt to the dongle. I'm curious if it will crash/error out when it attempts to write the packet bytes. |
|
Just tried publishing reload topic. Saw a bunch of activity in the output, but still no events. Detailed log snippet
|
|
New working theory - In my Debian OS I'm noticing "Power - 1 new notification" and "Automatic suspend - computer will suspend very soon because of inactivity". I'm wondering if this causes it to lose USB access for some reason? I have now tried the fix detailed in https://askubuntu.com/a/1262605 and will report back if the issue reproduces again. If you don't hear back from me in the next 4 weeks or so it can be assumed this fixes the issue for proxmox users. Else, we are still looking for the cause/fix. |
|
Stopped picking up events again after a restart of HA due to software upgrade. One more theory - I realized I still have the ha-wyzesense custom component. I wonder if when I restarted HA, ha-wyzesense custom component "took over" the wyze sense USB dongle. I'm going to remove the ha-wyzesense custom component and see if that resolves my issues. |
|
I have finally had the sensors stop reporting again and was able to try publishing a reload rather than restarting the service altogether and it did work! The sensors started reporting state again. I attached the relevant portion of the log, it was at around 16:35 when I noticed the sensors weren't triggering and issued the reload shortly after. I do see some errors later down in the log that might be of interest Edit: I take that back, it worked once right after the reload but that's it. It was a motion sensor trigger and it didn't stay up long enough to even get the clear signal. |
|
I'm happy to report that after the combination of things I've tried above, I am now fully stable! I no longer have the sensors stopping publishing events issue. I'm unsure of which combination of factors solved this for me, but I do think the fact that I had the old HA wyzesense integration combating with this for the same USB sensor at the same time was likely a cause. I'm going to close this issue as I seem to have been able to successfully fix my issue with the above steps, and now have a rock solid integration. Those still experiencing issues can experiment with some of the fixes I mentioned above, and let us know if any of them also solved your issue! If you are still having trouble, I encourage you to open your own ticket. Thanks for the help everyone! |
|
Unfortunately this issue is again occurring for me, it just only happens once every month or two. I tried transitioning my environment to running in a docker container on UNRAID to isolate any VM oddities. It ran well for a month but then the sensor events randomly stopped populating. Restarting the container and it fails to start with the following in logs: I still see /dev/hidraw0 on the UNRAID CLI. No amount of restarts of the container fix this. I'm going to try restarting UNRAID to see if that resolves it. Is there any chance either the hardware (wyze bridge) is defective and if so can it be patched/fixed? Secondarily, any chance there is a resiliency issue in this code-base somewhere? Given restarts of the container are not successful, it would appear there's something getting in the way from the application from accessing the hidraw device until the parent host is restarted, and this applies to when I ran in Proxmox VM and UNRAID container on different host machines. |
|
Update: A soft "restart" of UNRAID still didn't bring it back up. I had to physically power down the machine running UNRAID and bring it back up and then it started working again. Very odd. I'm curious what is happening when this happens and how we can avoid it? |
|
This is happening for me, too. However, I'm running stock Homebridge on Debian 11 without Docker on a RaspPi 3+. |
|
Since I opened this issue, I have since switched to a spare dongle that I had sitting in the drawer. The new dongle works way better than the old one. The old one has packet errors all the time, the new one very rarely has any packet errors (e.x. mismatched checksums). The new dongle does, for whatever reason, still stop working maybe once every one or two months. The only way to get it back working stable is to unplug the dongle and plug it back in. I can get it working sometimes by just restarting the service, but it's not stable and stops working again after only a couple hours. At this point I am chalking it up to subpar firmware from wyze on the first gen devices, not a stretch considering the null mac issue with the sensors themselves. |
|
@nabahr Thanks for the update! Unfortunately, I don't have that option, as my bridge is actually a Neos Smart Bridge. I just tried updating the firmware on it to the Wyze firmware that @AK5nowman posted on his repo (since they are very similar), but I bricked my bridge, hah. Oh well! It actually worked at first, then somehow bricked itself after a few minutes. |
|
hey, i started playing with this project recently, and ran into similar issue, which turned out to be an exception in the reader thread: In my case, it's caused by the packet from climate sensor i paired. You can see this if you go check console output (the error messages are not in any log files). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the Bug
After a few days of running the project, my sensors no longer seem to be picking up the events. I see MQTT pings in the logs, but no more sensor events after a particular time, even when I trigger motion or contact sensor.
Logs from the last period in which motion events were ocurring:
The log is then further filled with nothing other than PINGREQ and PINGRESP.
Hardware
I'm running wyzesense2mqtt as a docker container on an Intel NUC, Debian OS managed by Proxmox.
The text was updated successfully, but these errors were encountered: