kevinvincent / ha-wyzesense

A Home Assistant Component to interface with the WYZE Sense hub and sensor system
368 stars 97 forks source link

this project should be un-mothballed as there is now a solution to permanently fix bricked sensors #202

Open stanwebber opened 3 years ago

stanwebber commented 3 years ago

sycophantic on github has devised an economical jtag method to unbrick motion and contact sensors: https://github.com/sycophantic/wyzeback

null on the wyze community forums has identified how to write-protect the sensor firmware to prevent the mac from being overwritten in a low-battery state so that the sensors never get bricked in the first place: https://forums.wyzecam.com/t/unbricking-wyze-contact-sensor-pcb-reset-pin/146856/112

photinus commented 3 years ago

It's awesome to hear someone found a way to resurect dead sensors, though I think at least in my case without being able to buy new sensors and not having an easy way to recover the old mac from the sensors, I'm not sure it's worth trying to continue the development.

stanwebber commented 3 years ago

if I correctly interpret the outcome of issue 6 from the wyzeback project along with other comments i've seen online, it would appear that home assistant can pair with any arbitrary mac that is flashed regardless of what the original mac was. only the wyze app seems to be stuck on performing a check against the original mac.

as it stands now, the erlanger wyzesense fork has been performing flawlessly for me going from hass v4.17 all the way up to v2021.1.5. it is only 1 commit ahead of master and utilizes a fix identified in issue #189. I worry that keeping hass current all but guarantees that wyzesense will eventually break on me.

andystewart999 commented 3 years ago

@stanwebber - Hi Stan, I'm thinking about moving to erlanger's fork based on your feedback. How was the transition? I'm assuming that I don't have to unregister/re-register the devices I've got as it will still be referring to the original database.

Also do you know if the 'wyzesense stops sending state changes' issue that requires a hard boot is fixed in this fork? #189 doesn't seem to be quite the same issue...

Cheers, Andy

atjshop commented 3 years ago

Does anyone experience that the integration died silently?

Today I found that none of my contact/motion sensor is working, no error in HASS log either. The bridge LED is blue. To fix it, I just unplug the bridge and plug it again, find the device name and change it in HASS docker-compose file and restart HASS again.

The annoying thing is that there is symptom that it is not working, no error log either.

andystewart999 commented 3 years ago

Yes, I get that issue semi-regularly as well. My workaround is a full Pi reboot, seems to do the trick.

I've got a Node-Red flow that checks for recent state changes, if there are none for 12 hours it kicks off the reboot. Not ideal, but it gets the job done.

oudoulj commented 3 years ago

Does anyone experience that the integration died silently?

Today I found that none of my contact/motion sensor is working, no error in HASS log either. The bridge LED is blue. To fix it, I just unplug the bridge and plug it again, find the device name and change it in HASS docker-compose file and restart HASS again.

The annoying thing is that there is symptom that it is not working, no error log either.

Same for me since yesterday :( But just lost access to Home Assistant after updating to latest version, great... [Edit] finally regained access to HA and my Wyze sensors after restarting my RPi once again

stanwebber commented 3 years ago

Hi Stan, I'm thinking about moving to erlanger's fork based on your feedback. How was the transition? I'm assuming that I don't have to unregister/re-register the devices I've got as it will still be referring to the original database.

I implemented using that fork from scratch in hacs. i guess in your situation i would just manually overwrite the existing folder in custom components with the new fork. if you're already up to date with master, only a few lines of 1 file have changed. you could make the edits yourself on the server via nano with things shut down.

andystewart999 commented 3 years ago

Yep, that was my plan. All the sensors stopped reporting again about two hours so I'm testing the new version as of now :-)

atjshop commented 3 years ago

Yes, I get that issue semi-regularly as well. My workaround is a full Pi reboot, seems to do the trick.

I've got a Node-Red flow that checks for recent state changes, if there are none for 12 hours it kicks off the reboot. Not ideal, but it gets the job done.

Could you share the node-red flow you use? Thanks!

andystewart999 commented 3 years ago

Here it is - I've made life slightly more complicated by being aware of general family presence, plus the time, to try and narrow the window of expected state changes. It could be made a lot more easy!

[{"id":"91300a70.717c78","type":"tab","label":"Wyze status check","disabled":false,"info":""},{"id":"8dadf5a1.cfb3b8","type":"ha-get-entities","z":"91300a70.717c78","server":"eade109e.efa26","name":"Poll all Wyze devices","rules":[{"property":"entity_id","logic":"starts_with","value":"binary_sensor.wyzesense_","valueType":"str"}],"output_type":"split","output_empty_results":false,"output_location_type":"msg","output_location":"payload","output_results_count":1,"x":580,"y":100,"wires":[["380a837d.78226c"]]},{"id":"1dbf9f75.7666a1","type":"inject","z":"91300a70.717c78","name":"Every hour","props":[],"repeat":"3600","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":120,"y":100,"wires":[["cb7273b1.340b"]]},{"id":"cb7273b1.340b","type":"change","z":"91300a70.717c78","name":"Reset variables","rules":[{"t":"set","p":"most_recent_change","pt":"flow","to":"9999999999","tot":"num"},{"t":"set","p":"most_recent_entity","pt":"msg","to":"","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":100,"wires":[["8dadf5a1.cfb3b8"]]},{"id":"380a837d.78226c","type":"function","z":"91300a70.717c78","name":"Store most recent change","func":"// Store the oldest change in the 'most_recent_change' flow variable\n\nlMostRecentChange = flow.get(\"most_recent_change\");\nlCurrentChange = msg.payload.timeSinceChangedMs;\n\nif (lCurrentChange < lMostRecentChange) {\n flow.set(\"most_recent_change\", lCurrentChange);\n flow.set(\"most_recent_entity\", msg.payload.attributes.friendly_name);\n}\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":850,"y":100,"wires":[["b34634fe.abbdf8"]]},{"id":"53ae40ad.e4b95","type":"change","z":"91300a70.717c78","name":"Set debug output","rules":[{"t":"set","p":"payload","pt":"msg","to":"most_recent_change","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":1330,"y":300,"wires":[["95bfb8cd.2d3ed8"]]},{"id":"9cc67525.a19198","type":"switch","z":"91300a70.717c78","name":"Activity in the last 12 hours?","property":"most_recent_change","propertyType":"flow","rules":[{"t":"lt","v":"43200000000","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1800,"y":220,"wires":[[],["886d0e0f.07e7c"]]},{"id":"886d0e0f.07e7c","type":"api-call-service","z":"91300a70.717c78","name":"Reboot host","server":"eade109e.efa26","version":1,"debugenabled":false,"service_domain":"hassio","service":"host_reboot","entityId":"","data":"","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":2050,"y":100,"wires":[[]]},{"id":"95bfb8cd.2d3ed8","type":"debug","z":"91300a70.717c78","name":"Most recent change","active":true,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":1570,"y":300,"wires":[]},{"id":"fb89024a.a1ccb","type":"api-current-state","z":"91300a70.717c78","name":"Anyone home?","server":"eade109e.efa26","version":1,"outputs":2,"halt_if":"home","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"entity_id":"group.stewart_family","state_type":"str","state_location":"","override_payload":"none","entity_location":"","override_data":"none","blockInputOverrides":false,"x":1320,"y":100,"wires":[["35fbd25c.62da4e"],["9cc67525.a19198"]]},{"id":"c902116f.1c06a","type":"switch","z":"91300a70.717c78","name":"Activity in the last 4 hours?","property":"most_recent_change","propertyType":"flow","rules":[{"t":"lt","v":"14400000000","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1800,"y":160,"wires":[[],["886d0e0f.07e7c"]]},{"id":"35fbd25c.62da4e","type":"time-range-switch","z":"91300a70.717c78","name":"Sleeping time?","lat":"-33.735721","lon":"151.165734","startTime":"22:00","endTime":"07:00","startOffset":0,"endOffset":0,"x":1540,"y":100,"wires":[["478f0c7c.236634"],["c902116f.1c06a"]]},{"id":"478f0c7c.236634","type":"switch","z":"91300a70.717c78","name":"Activity in the last 8 hours?","property":"most_recent_change","propertyType":"flow","rules":[{"t":"lt","v":"28800000000","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1800,"y":100,"wires":[[],["886d0e0f.07e7c"]]},{"id":"b34634fe.abbdf8","type":"join","z":"91300a70.717c78","name":"Wait until done","mode":"auto","build":"string","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1100,"y":100,"wires":[["fb89024a.a1ccb","53ae40ad.e4b95"]]},{"id":"eade109e.efa26","type":"server","name":"Home Assistant","addon":true}]

andystewart999 commented 3 years ago

Ah, I just realised that my 4, 8 and 12-hour counters were off by a factor of 1,000! They should be 14400000, 28800000 and 43200000 respectively.

andystewart999 commented 3 years ago

Yep, that was my plan. All the sensors stopped reporting again about two hours so I'm testing the new version as of now :-)

I've just had the 'no state change' issue again, using erlanger's fork. I'll raise an issue.

ballakers commented 3 years ago

@kevinvincent - This integration is working great for me so far. I didn't bother previous because I thought the project was dead with issues aside from just the hardware issue on wyze's part. So far no issues at all. It was even able to pair one of the sensors with the erased MAC (shows as wyzesense_"blank here"), unfortunately can only add one bricked sensor with the erased MAC but I'm still happy. The second without a mac is recognized upon pairing but guessing since HomeAssistant sees both as the same blank MAC address that's why the second one won't show up as an entity. Not sure what happens to or where the info goes for the second bricked sensor after it is added. Guessing the only way to assign a new MAC is via wyzeback but buying a LAUNCHXL-CC1310 just doesn't make sense to unbrick a few cheap sensors. Super happy though that the one previously brocked sensor is working - now only one of my 6 sensors is out of commission. Thanks again Kevin for this nice piece of work. Working great to trigger my ESPhome bed lighting!!!

stanwebber commented 3 years ago

@ballakers the sensors with null macs will act as a group under that single hass entity. say you have six windows with six null sensors. opening or closing any window will trigger the entity. you'll get an alarm or notification, but you won't know which specific window was breached. it's only necessary to register the first null sensor with the bridge--all the others are automatic since they're essentially duplicates. if a close neighbor also uses wyze sense it could be problematic for you if their sensors also go null.

ballakers commented 3 years ago

@ballakers the sensors will null macs will act as a group under that single hass entity. say you have six windows with six null sensors. opening or closing any window will trigger the entity. you'll get an alarm or notification, but you won't know which specific window was breached. it's only necessary to register the first null sensor with the bridge--all the others are automatic since they're essentially duplicates. if a close neighbor also uses wyze sense it could be problematic for you if their sensors also go null.

Awesome thanks for the info. Guess that won't work for me how the other null sensor is set up at the moment but I'm a happy camper either way and in the future maybe I'll put it to use if I change the use of the currently used null sensor. Thanks again!

isuelt commented 3 years ago

@andystewart999

Here it is - I've made life slightly more complicated by being aware of general family presence, plus the time, to try and narrow the window of expected state changes. It could be made a lot more easy!

What do you use for presence detection ?

andystewart999 commented 3 years ago

I don't do a whole lot with PD. I use the motion sensors at night to dimly turn on some hue lights (if someone walks through the house), and I use them as part of a home-brew alarm, but that's about it.

isuelt commented 3 years ago

@andystewart999

I don't do a whole lot with PD. I use the motion sensors at night to dimly turn on some hue lights (if someone walks through the house), and I use them as part of a home-brew alarm, but that's about it.

Ok you "don't do a whole lot with PD" but it seems to be in your Node-Red ( group.stewart_family ). I was just wondering "what" you used for PD, not how much you relied on it. I've just always had a problem setting any workable PD - that's why I asked.

andystewart999 commented 3 years ago

Ah, OK. Yes, that group is a collection of device_tracker entities, that really only care if anyone is 'Home' or not.

capnkirk13 commented 3 years ago

I agree that this should be kept alive as I've been able to keep my sensors working via this method I discovered when I first got a Wyze kit. I just had all my sensors stop reporting as of 4 days ago (was on vacation) so I'm going to reboot Pi and see what happens.