Sensors Stop Responding - Requires Reboot #114
Comments
|
+1. Exact same scenario. Thought migrating to a Debian VM might help but it still requires that reboot frequently. |
|
Same for me. I've tried using previous versions of the component and keep needing to restart for the component to work again. It is AWESOME when it works but unfortunate when it doesn't. Here's what my last log on 0.0.7 says about the error: I'm on a HassOS 3.11 on a VirtualBox VM. |
|
Can you put your logs into Debug?
logger:
default: info
logs:
custom_components.wyzesense: debug
~Will
…On Fri, Mar 6, 2020 at 10:18 AM John Warne ***@***.***> wrote:
Same for me. I've tried using previous versions of the component and keep
needing to restart for the component to work again. It is AWESOME when it
works but unfortunate when it doesn't. Here's what my last log on 0.0.7
says about the error:
Log Details (ERROR)
Logger: custom_components.wyzesense.wyzesense_custom
First occured: 11:15:30 AM (1 occurences)
Last logged: 11:15:30 AM
[Errno 110] Operation timed out
I'm on a HassOS 3.11 on a VirtualBox VM.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#114?email_source=notifications&email_token=AC362MOG2AY4ZBLKIHG7R3TRGE5A3A5CNFSM4LC7JNG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOCKJZQ#issuecomment-595895526>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC362MIM53ECNFHX6Q4TYYTRGE5A3ANCNFSM4LC7JNGQ>
.
|
|
I am going to try this in my config until it gets sorted out. And have it reboot everyday. restart HA to keep it fresh
https://community.home-assistant.io/t/the-ability-to-schedule-a-reboot/30144 |
|
@cheechie I've had mine rebooting for other reasons nightly. Seems like wyze gets through most of the day but by evening it's always in need of a reboot. Too bad hourly restarts aren't feasible for the time being... |
You got it. I've got a log for a timeframe during which the component was working then failed. Where would you like me to send it? |
|
FYI, my system is also having this problem. I'm running HA on Ubuntu 18.04 in Docker container. It used to work fine but then I had a server power outage and ever since I've had issues. The only difference from the other comments is sometimes I have to stop the container, pull the controller for 10 sec, replace and then restart the container. I've turned on logging so if it happens again I'll upload the logs. |
|
@johnwarne can you post it to Pastebin and share a link here? |
|
btw, I'm pretty sure what is happening is the Home Assistant supervisor is restarting HA for some reason and we're not closing the connection the USB dongle. Then when it tried to re-initialize the connection it times out waiting on the initialization stage. |
|
Sure thing. I've removed everything except the component's logs: https://pastebin.com/Q8ETakPQ |
|
@johnwarne Can you try updating? You're on 0.0.4 from the debug logs, 0.0.7 fixes a lot of random issues. |
|
Apologies, I've been bouncing around between 0.0.5, 0.0.6, and 0.0.7. In HACS it says I'm currently on 0.0.6: https://www.dropbox.com/s/b3khmm9185t6mvk/Screenshot%202020-03-06%2014.16.32.png?dl=0. I'll update from 0.0.6 to 0.0.7 and will update this thread if/when I get another failure. |
|
Thanks @johnwarne , also please note the color of the LED on the dongle when it fails? |
|
@photinus The component has errored again. The light on the dongle is blue. Here's a link to the debug log: |
|
@johnwarne See this information on this error in virtualbox here: #20 (comment) |
|
EDIT (about 2 hours later): Just applied a HACS update and the problem seems to be resolved. = = = = = = = = = = Apologies if the above already discusses the problem I'm having. This morning I noticed that all of my Wyze sensors had stopped responding. I had added two sensors yesterday, but they were functioning fine when I went to bed. To troubleshoot, I restored to an earlier Snapshot which seemed to fix the problem... until I rebooted at which time all sensors went offline once again. I'm Running Home Assistant 0.106.5 on a Mac mini, Ubuntu 18.04.4 LTS, Docker. Supervisor version is 209. I installed the Wyze Sense Component through HACS. Previously-working configuation.yaml entry: Under Supervisor | System | Hardware | serial I see an entry for /dev/serial/by-id/usb-0658_0200-if00 Wyze USB dongle is solid blue. Word of warning: I'm not very familiar with Docker. It's running/working, but it confuses the heck out of me. I'm happy to try to issue Docker commands, but I'll need some firm hand-holding. Logs GREPd for any mention of wyze are in the accompanying .zip file. Any suggestions on how to get things back up and running? |
|
I'm also frequently experiencing this. Happens once or twice per week |
|
I'm also experiencing this about 1-2 times a week. I have 9 contact sensors and 3 motion sensors paired with it. Restarting HA doesn't fix it, removing/reinserting the dongle doesn't fix it. Only rebooting the whole host fixes it. Running Hass.io installed on Ubuntu LTS. |
Between switching to the USB 3.0 host controller and going back to 0.0.7 of the component, this seems to have solved my stability problems for the past several days (knocks on wood). I'd gone down to USB 2.0 since that helped with stability in the past, but perhaps with newer versions of the component that's not applicable. Thanks, @kevinvincent ! |
|
So what is the solution to this? or a workaround perhaps? I reboot my host (not hass) and it fixes the issue. I also figured out reinstalling the component and rebooting hass (not host) fixes it as well. Would really like to know how I can prevent my usb dongle from disconnecting every time supervisor updates, or worse at random like it seem to be doing about once every 2-3 days without manually rebooting the host. I run a vpn tunnel from my host as well (I know, I know, I need at least one more pi) but it's lightweight in the essence the ssh just needs to be kept open to keep the tunnel open. Nifty little failsafe. Anyway, I am experiencing all the issues described in this thread. The dongle disconnecting, not reconnecting, and the sensors remaining in their off position. This is only resolved with the methods I mentioned. Is using usb 3.0 instead of 2.0 the trick? Curious if it is, as on my rpi4b it happens with both usb 3.0 and usb2.0 BUT I am using powered usb3.0 hub as instructed by several guides for rpi4b and usb's. Something about their power circuitry only having a set amount of voltage across the usb lanes. Google it if you're curious. |
I have not seen a solution yet. I am running it in a VM in proxmox. I have to power of my HA VM and then uplug my USB dongle and then plug it back in and reboot. I might go back to hassio on the pie, because then I just had to reboot and the sensors would come back online. I sure hope this issue can be resolved, otherwise I will have to look for other sensors to use instead of wyze sensors. |
|
I updated the bridge firmware from .30 to .33 fixed the problem for me. |
|
@tteck, upgraded by plugging back into a wyze cam? I switched to the 3.0 VirtualBox driver and haven't had issues yet (although it often takes between 1-5 days for the issue to show back up). |
Yes, I had to purchase a Wyze cam (also picked up a spare starter kit) to see what firmware was on my bridge. Firmware was .30 updated to .33 on the new bridge (kept the old bridge at .30 just in case) re-scanned my sensors (20) It's been 3 weeks with no problems. |
|
Interesting. I've never even plugged the Sense Bridge into a Wyze Cam. Will give it a shot and see if the firmware update fixes it! |
I just updated my bridge firmware from 0.30 to 0.33. My HA would not recognize any of my sensors with the new firmware. I had to add all 24 of my wyze sensors again buy scanning and pushing the button with the pin. Hopefully this works! The firmware update is in camera settings ->Device Info ->Bridge Firmware Version |
|
@kevinvincent, my Wyze component stopped responding this afternoon and I have the debug logs. I've uploaded the relevant section to pastebin: https://pastebin.com/jiDDv4Cs The wyze logs just seem to stop at a "Trying to parse:" message. FYI, the LED on the dongle is still blue. My system is a Ubuntu 18.04 system with HA running in a Docker container. [Edit] I probably should mention that the system was running for almost exactly three days before it stopped handling events. Thanks! |
|
ugh, if I must update my firmware, I suppose that's the fix. No bother other then re-pairing my sensors. I will report once the firmware is updated on progress. Edit Curiously, when I plugged the bridge into the camera, it either auto updated almost instantly, or it was already on 0.33 firmware for the bridge. I'm willing to bet the former. I will attempt to run the system for a few days without reboot, maybe the update (or not) fixed it? Edit_2 Alright, it seems like it DID in fact update the bridge without me manually doing it once I plugged it into the camera and rebooted the camera, it applied the update within seconds. Secondly, the sensors all were unresponsive when I plugged it back into hass (which is why I think it updated,) I ran the wyzesense_scan call for every sensor (it did take about 20 minutes to go through them all) 16 sensors in total. The sensors are now responding normally, only time will tell if this solved the disconnect issues. Thanks for the tips! |
|
I do not have a camera as I purchased the sensors to use with HA. So far I have not had the disconnect Issues as others above. Is there a way to update firmware (if needed) without the camera? |
|
My bridge firmware is stuck on updating and never finishes. I'm thinking maybe it's because I have rstp firmware on camera. Anyone been able to successfully update firmware via camera with official rstp firmware? I also second the question on whether there is any way to update bridge firmware without camera. |
|
@daveenguyen, I haven't seen any error message yet with the latest code that I have implemented. I will report back if/when I do. |
|
I got my first non OSError message but Wyzesense has continued to run. Here is the messages around the error message: 2020-04-28 08:27:48 DEBUG (Thread-10) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa53193500000171c0c1af660ea2373738303233434402000bfa0821' I don't know how to get a traceback. |
|
Updated my branch to The gap between the |
|
I think people can use #129 as a simple workaround for now and share non-OSError they encounter |
|
@gterpstra75
|
|
Thanks @daveenguyen. So far, I have only had one non-OSE error message when I was running code (from #114 (comment)) which resulted in failure of wyzesence. I didn't get a traceback with the error message, just the message of the error. I am now running code similar to what you suggested above except that I have added the traceback. I do see the traceback in the log messages now. I also get several non-OSE error messages a day which doesn't result in failure of the wyzesence hub. I assume that previously (looking at the code, hey still trying to learn here) these would have resulted in failure due to the break statement. Thanks again, my wyzesense I believe has been much more stable this last week. |
|
I dont known if what I say will help or not but have to mention that I used to put my laptop in a closet, 2 meters above the ground and maybe I have to restart every two weeks for example. But lately I had to change the place of the closet and I put the laptop on the floor aganist the wall. I may restart now 2 times a day or every 3 days ... but it is being annoying now. So I am not sure maybe this place misses some packets and is not easy to communicate with the nodes and this weak connection leads to some type of error. |
|
@daveenguyen I've been struggling with this same issue with my project Wyzesense2MQTT. I believe it is an unknown packet type, likely triggered when a sensor's battery is low, as I seem to observe in my setup. The fix I'm testing is in the Parse function: I changed the else with an assert, into an elif instead, and added an else catchall to log the failures. Not sure if this will truly resolve the worker crashes, but wanted to share since I found you are having the same issues, and my logged issue with WyzeSensePy was linked above in this thread. If anyone wants to help determine what the err'ing packet actually is (low battery warning?), I'd love to see us actually be able to make use of it somehow with HA. |
|
I agree that it has to do with something being done with low batteries. I have about 30 sensors combined between motion and magnetic. It was at first i could go a week with no issues all bat show above 80 percent. Now i have stopped using HA because my wyze stops working min/sec after i reboot. All sensors still show good battery but nothing else has changed. It started to need a reboot closer and closer together until now it wont work more then a min or so. I have stopped putting time or using HA since all my automatons involve wyze sensors until this issue is solved. I am up for options on how to find low or bad sensors but updated firmware and everything has not lead to any bad sensors. I see the same errors as everyone is describing above. |
|
@robkiller26 You could certainly try testing modifying the Parse function in your copy of HA-WyseSense as I specified above and see if that keeps things more stable. It would be interesting to note if some (but not all) of your sensors stop sending data, at which point that might be a trigger to know there is a low battery. I love these sensors for cost, but their battery states are not very accurate. I've had ones that report 70%+, and then suddenly start having the bad MAC address issue. A battery replacement has almost always brought them back, but detecting when they actually need new batteries seems to only be reliable from the sensor itself when it starts flashing the led red periodically even without a sensor trigger. For the contact sensors, that is easy to see visually, but the motion sensors is harder as when you can see them, they can usually see you. :) |
|
I will look into that. I was wondering if the battery or issues showing up
with the sensors would be easier to see with the wayze app. I was thinking
about setting all my stuff up on the wayze camera and loading everything in
the app to see if it would tell me what sensor is having issues.
Anyone try that?
…On Mon, Jun 15, 2020, 8:35 AM Elias Hunt ***@***.***> wrote:
@robkiller26 <https://github.com/robkiller26> You could certainly try
testing modifying the Parse function in your copy of HA-WyseSense as I
specified above and see if that keeps things more stable. It would be
interesting to note if some (but not all) of your sensors stop sending
data, at which point that might be a trigger to know there is a low battery.
I love these sensors for cost, but their battery states are not very
accurate. I've had ones that report 70%+, and then suddenly start having
the bad MAC address issue. A battery replacement has almost always brought
them back, but detecting when they actually need new batteries seems to
only be reliable from the sensor itself when it starts flashing the led red
periodically even without a sensor trigger. For the contact sensors, that
is easy to see visually, but the motion sensors is harder as when you can
see them, they can usually see you. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#114 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEPBFB62DEI5M6HU5QIVTD3RWYWRHANCNFSM4LC7JNGQ>
.
|
|
I'm having similar issues on gosense. 2020-06-19T19:33:30.561536251Z DEBU[0578] readRawHid: 62 bytes: [ 55aa53193500000172ce123b360ea2373741313742414202010053064655aa531d1900000172ce123b39a2373741313742414202176400010100531606b5 ] Second message asserts that "state:0", e.g. no more motion. And it always happens 40 seconds after the motion is detected: 2020-06-19T19:34:10.558263651Z DEBU[0618] readRawHid: 62 bytes: [ 55aa53193500000172ce12d0230ea237374131374241420200005406c855aa531d1900000172ce12d026a237374131374241420217640001000054170738 ] Third message almost always (pretty much always), comes in exactly 2 minutes after the first motion detected message. 2020-06-19T19:35:30.557162901Z DEBU[0698] readRawHid: 39 bytes: [ 55aa53231900000172ce13f9f7ab37374131374241420200000100000100000100000117000776 ] Note that the last message is 39 bytes vs 62 bytes for the first two. It is misinterpreted by parser, but gosense library does not seem to care and chugs along nicely. All I get is a weird MQTT parsed message - battery says 0%, which is not true. |
|
this is what the misinterpreted 39-byte long message looks like in Node-Red, where I've subscribed to mqtt topic from gosense
|
@raetha has yours been more stable with this fix? I'm thinking of pulling it into the package. |
|
Hey Kevin - this fix definitely has, I believe this to be a good change. I'm still experiencing occasional outages that I think are related to issues with the udev and HA docker - those issues are 100% reproducible by unplugging and replugging your usb dongle in and out, and the HA container no longer has visibility into the hidraw device until HA restarts. And I think something with power management in my pi is causing this to occasionally blip out and require restart. For context: #66 That being said, anecdotally, since adding the diff you mention, I have noticed a perceivable decrease in frequency of restarts being required. So I personally feel this fix is a good one. |
|
My sensors have been running nonstop for over a month without any issue. Running VM in proxmox. It never requires a reboot anymore. |
|
@kevinvincent to confirm, it has helped significantly with the issues being seeing. We're still chasing down one lockup issue, but it seems to be related to the bridge and USB connection flaking out. I've just modified the retry settings on the connection function to ignore IOError to see if it covers that. But with just the assert change we aren't seeing the errant packet killing things anymore. So I think you are pretty safe. Still love to see someone with some hardware chops help us figure out what that packet really means though. If as I think, it's a low battery warning, that would be great to make use of, instead of getting stuck with the invalid MAC issue that shows up when a sensor runs too low. |
Should help with stability as reported here: #114 (comment) Thanks to @raetha for this contribution.
|
@raetha Great to hear. Yeah, unfortunately, I don't have too much experience with the reverse engineering side to figure out what exactly that packet means. It would be cool if it was a low battery warning we could catch. I've just had to check for the 3 fast blinks on my sensors to know when to replace them. I've gone ahead and released v0.0.9 with that fix. Thank you :) |
|
You are very welcome, happy to share. Feel free to pour through the rest of my project's code sometime and see if there might be anything else we've caught that could be useful to you. I don't remember all the things off the top of my head, just that I spent about a month right off the bat working through a variety of things that behaved weirdly. Now that the bad packets are at least getting something logged on my side, I'm going to watch for those log messages periodically and see if they seem to occur the next time I have a low battery. I don't know how to convert the packet to useful data, but it would be nice to confirm my suspicion that they are related. Then if we can at least parse the MAC from it somehow, we'd have a low battery warning. :) |
|
Running 0.9 on rpi and finding I need to reboot every now and then. Help :) |
|
@kevinvincent one of my contributors recently figured out how to modify the WyzeSensePy library and capture the ~4hr updates the sensors send with their current state. I haven't been able to test yet, but merged the code into my devel branch. Assuming it works, there isn't really a "low" batter alert, but rather more regular check-ins than just waiting until a sensor is tripped. A couple threads also mentioned that the battery level may be off by a factor of 5. Not sure we can count on that, but might look into applying that logic just to show a more realistic battery level. |
|
@raetha if you submit a pull request I can merge it in :-) |
|
This repo is marked as "No Longer Maintained". Is there any fork that still actively maintained? |
|
@photinus Unfortunately I'm struggling to find time to update my project with everything folks are asking for or finding. I still want to ultimately get my fork of WyzeSensePy submitted back to the root so that we don't need to maintain a separate copy. All changes are also not validated yet, and I think there are some issues. Hoping to test more myself soonish. If you want to scan it though, the file is at: https://github.com/raetha/wyzesense2mqtt/blob/devel/wyzesense2mqtt/wyzesense.py @atjshop I do know I've seen another HA custom_component called ha-wyzeapi that integrates Wyze devices through their web api, rather than a hardware bridge. That one will likely keep working (if Wyze lets it) when new hardware comes out since it goes directly to their sites which will certainly support the new hardware when it comes out. As a final aside though, it's best practice to create a new Issue on repo when asking questions like this. As this issue is focused on a different topic. |
Should help with stability as reported here: kevinvincent#114 (comment) Thanks to @raetha for this contribution.
and others
I was running hassio on a pie and the wyze sensors would just stop responding after a day or sometimes 3 days. A reboot would fix the problem. Recently I have switched to running home assistant in a VM (Proxmox), but i still get the same issue. A reboot of home assistant fixes it every time.
Let me know if I can provide any logs to help.
The text was updated successfully, but these errors were encountered: