Unbricking Wyze Contact Sensor - pcb reset pin

So prepend zeros onto the sensor MAC address found in the app or on the back of the houseing like:

I had posted a link to the TI development kit earlier up , the user manual there has a screen shot showing the expected MAC address format.

but before you even reach that stage, you would need to buy the right launch pad model and configure everything. then I imagine you need a way of wiring it to the sensor, just holding the wiring to the pins will be difficult as they are tiny, you will need to build a custom rig. and later when you miss a battery change you will have to go through this trouble all over again.

this is not a practical solution. something straightforward for us users is a firmware fix from wyze to work like home assistant

My guess.
xiaomi assembled board, then insert battery.
put it on a test jig to flash mac address.
then install onto the housing and weld plastic standoff.

you need a jig with pin/nails to the board to program using jtag2usb cable. I made on before toto program tv remote.

if you have not delete device from app, you may be able find the original mac address.

afaik, the sensors use a shorter address scheme that are only 8 digits. What is shown on the app and case are exactly it. They are not the same as the longer 12-digit WiFi/Ethernet MACs.

I made a jig for this, but it turns out I didn’t have anything that can speak cJTag, so that was kinda pointless… lol


actually it does serve a purpose, as it shows how much work & fiddling around would need to go to fix just one sensor, till the next low battery happened. thats why i am asking for Wyze to fix this from their firmware


i can confirm that in my home assistant the mac of many of my sensors change to 00 00 00 00 00 00 00

1 Like

Sgi, thanks for sharing this post, I’m learning more about HA, I’m setting up my raspberry pi and will try some tricks.

This is what I currently have as dead devices, other 20 are still running fine over the house.

Home assistant is really good i use it on a first generation intel nuc and in a old gigabyte brix , works great ,

i recomend that you get a mini pc and istall debian 10 and use docker to install home assistant , it will run for years instead of rpi that will cause the sdcard to break any time , trust me my i gave a rpi to my brother with homeassistant and is a pain to do manual reboots as it crash random

Thanks for the tip.
I have a couple of rpi, rzero and one arduino for test and projects so I will use the rpi to learn and go with the mini pc when I fully understand what I need.
Again thanks for your advice.

rpizero will not work with home assistant , but the rpi 3 + will do fine, for a few months

Wouldn’t using the same Pi with a hard disk or SSD allay your concerns?

it ill help for rpi 4 but for the rpi 3 it will use it as a usb , is slower usb than sdcard, but you can do it, i use mine for a year on a usb , remember to enable boot from usb on your rpi

1 Like

I have theWyze Sense Bridge plugged into an ESP32/UHS-Mini running a self programmed standalone monitoring system. Alarms are sent via SMS.


that’s pretty neat MarkR, i had thought the bridge usb port had some propriety pinout ,

in theory could I plug the Wyze bridge into a laptop and use it from there to get more info on why the sensors are bricked?

also have you had this problem of battery low- bricked sensors yet?


1 Like

Whatever device you plug the Wyze Bridge into its USB port, the device must:

  1. support hidraw via a driver (aka software).
  2. have an app running that can communicate with the bridge via the driver.

My 1st try was to use an Android device (os 6) which supports OTG. I strongly believe this failed due to a lacking hidraw kernal (I have no idea if Android 10 would work either). My 2nd try was to use an ESP32. An rPi supports hidraw and with the aid from wyzesense.py, this setup can communicate with the bridge.

My sensors are all still working correctly.

My understanding of this problem is that the sensor firmware somehow gets corrupted, possibly associated with a low battery voltage, and the mac value resets to 0 in the firmware, but not in the “config memory area”. I still cannot fathom how this can occur thou. It appears that these “bricked” sensors can still communcate with the bridge but indicate its mac address is 0. Reflashing the sensor with firmware holding the correct mac will correct this issue, but fails to function if the mac does not match the one that is stored in the “config memory area”. I do not know if the bridge is capable of OTA firmware upgrades to the sensors. If Wyze allowed/processed sensors having a mac of 0, they would all become “generic” since you cannot identify which sensor it actually is. Wyze would need to update the V2 cam (and cam pan) firmware to allow pairing & processing events from sensors having a mac of 0 and possibly their server software to make this happen. It would be interesting to know what happens when a bridge that has already been paired to a sensor having a mac of 0 using HA is plugged back into a V2 cam. Does the V2 cam pass events from sensors having a mac of 0 to the Wyze servers?


has anyone ever tried this ( pairing a bricked/ non bricked sensor to both HA and wyze bridge) ?

@stanwebber would be one based on a quick review of this thread. HA is using the wyze bridge …

I have had great success unbricking my contact sensors using the wyzeback. I didn’t bother to setup a rig for it like the pic above shows, I used some simple mini-grabbers for power and 2 pin jumpers taped together and bent at a 90 degree angle to more easily make contact with the flash pads on the circuit board. Tonight it took me 5 minutes to resurrect a sensor. $35 for the LaunchPad was a small price to pay to ensure that even if my sensors go bad, they can still be fixed.

I too have been using home assistant (hassio) to connect with these sensors and it’s been a pretty solid setup until the sensors started dying! It runs on my Mac that has hassio running inside VirtualBox. The wyze bridge plugs straight into my Mac and VirtualBox automatically takes control away from the Mac so hassio always has access to it. As for the hidraw drivers, they’re installed inside the hassio virtual machine, not on the Mac (since there is no Mac version of the drivers)


Wow, that is really cool, thanks for sharing! I may buy that LaunchPad myself if I have another sensor go dead without my notice. It is a little expensive considering the sensors were only $5 each, but the insurance is nice for long term use.