Unbricking Wyze Contact Sensor - pcb reset pin

I wonder if I could do that with my bus pirate (that I have not learned to use yet), or the GPIO on an RPI like I did with my Zigbee dongle? Zigbee2MQTT


When you “unbrick” them, do you get the MAC Address back ?


To not lose the Mac value (the base holder are all messed up because of the replacement of bricked sensors) I’m planning to label the active sensors with the Mac address like the picture (so I can re-flash using the lauchpad).
Some of them may be visible from outside, do you believe this is a security flaw if I do that?
The other option is to label each with an ID and hold a spreadsheet with the Mac values.

Please advise.



I have been thinking about this as well for the past few days … is the LaunchPad really necessary? Cannot another microprocessor reflash the cc1310? I have yet to read the various cc1310 technical documents that I have downloaded, but to me, the flashing process is just software driven. Uniflash probably identifies a known board such as the LaunchPad and knows how to flash it.

1 Like

Those are some good ideas. I’ll probably take a screenshot of all mine in the Wyze app.

I don’t think it’s a huge security risk. >99% of people wouldn’t even know what to do with that Mac address, let alone how to pair it or spoof it or how doing any of that would be worth the time and effort, and if they even saw it, they’d already be inside your house. I’d be more concerned it would accidentally rub off.

Honestly, you don’t need to write it anywhere. As soon as it stops working, just go into the Wyze app before deleting the sensor and look at the MAC address that’s still saved in there already. As long as you don’t remove the device, you’ll have a copy of the MAC that it was paired to saved there under device info.


I had a look at a
Development Boards & Kits - Wireless CC1310 LaunchPad Evaluation Module

but i am puzzled why it has a CC1310 stuck on it. is the main job of a launchpad to demo the CC1310 stuck to it? and flashing external CC1310 is a secondary feature?

I believe it is a development board (more circuitry than just the chip) to prototype what you are trying to build using the cc1310 Wireless MCU. The large chip at the top left is a XDS110 debugger (actually the top third of the board looks like it is used for debugging) and this chip is used for flashing & debugging firmware on the cc1310 chip. This development board also has pinouts where you can piggyback the flashing process to flash a secondary cc1310 chip by using the jumpers that isolate the debugger from the MCU, power, UART and JTAG.

1 Like

What I did with my sensors was create all the firmware files at once for each sensor and change the file name to something descriptive of what sensor the file goes to. This way I’m spending less time restoring the sensor by trying to match mac addresses. The files themselves contain the corresponding mac addresses, the file names are inconsequential in the firmware restoration process.


You need to know what the MAC address is prior to unbricking them. Luckily, the mac address is in tiny print on the back of the sensor. If you’re using home assistant, the default entity id contains the mac address as well (hoping nobody changed their entity id’s). While I don’t use the app, folks say the app also will show you the mac address if you still have the bricked sensor in your list of devices.
The creator of the the wyzeback hack says there might be a way to read the config info from the sensor using the LaunchPad dev board, but I haven’t messed with trying that.


NICE! I didn’t realize this, so thanks for pointing this out. I had to use my phone and zoom in really big to be able to read it, but it’s all there. This is great. Makes me stress a little less. At least it is possible to recover/salvage the device(s) if I lose enough to feel it’s worth the aggravation and time to figure out. It would still be nice if Wyze made their own easy solution, but I’m glad someone was smart enough to at least figure out a work around.

You see that @vankfire ? No need to write the MAC on the sensor since it’s already on there on the back…just need a magnifer of some kind (ie: phone camera lens).

My problem is that I lost 5 sensors and I rearranged them with new ones (because the tape is on back piece and I didn’t want to damage the wall or the door for now I replaced only the electric piece and they now do not match the sensors if that makes sense).
Since I didn’t know why the sensors were going bad I didn’t bother to worry about matching the MAC address.


This is going to sound sarcastic but it’s not. I have a Wyze sensor starter kit I haven’t opened. Should I even bother to try it or should I explore something like Aqara instead? Those are about $10 a sensor. I don’t feel great about investing time into a system that becomes permanently useless / bricked when the battery runs low. By the time I get accustomed to it it’s very likely to just die.

The new Wyze sensors sound okay but I’m not really interested in 3rd party monitoring.

Some of you guys are doing heroic efforts trying to rescue the dead sensors but it doesn’t seem like a hole I want to be digging…

Honestly? If you don’t have any sense stuff in place, considering the propensity of death and hassle resurrecting, I’d maybe consider selling that kit on ebay? It seems like those sense kits sell on eBay for far more than they originally cost, so maybe could make a couple bucks off it.

Personally I like to tinker on stuff, but not things like door and window sensors. If they can’t be dead reliable, then they’re rally not gonna do me much good.

1 Like

I’ve not yet tried this, but a couple people have and experienced success

1 Like

if you download the wyzeback package , it contains a .bin file that you can use to flash your bricked sensor.

I am no expert but
if bus pirate can do cjtag, then it’s sounds feasible. cjtag is an open standard, not limited to Texas Instruments

1 Like

I just had another contact sensor die today, and could not revive it. I am now down to two working contact sensors. I am going to plug in the Robotic Vacuum tomorrow, hopefully it will work properly.

Submit a ticket to Support… They will require proof of purchase

Would you be able to share info regarding the flashing process using uniflash? I’ve got the launchpad and created the firmware with the correct MAC using wyzeback but can’t seem to get uniflash to actually flash the firmware to the sensor. I’m sure it’s a setting in uniflash that I’m overlooking but haven’t been successful in locating it. Any help is greatly appreciated and thanks in advance.

1 Like

I wrote up a little cheat sheet to remind myself how to do it since it may be months between having to do another resurrection but it’s on my laptop at home. I’ll clean it up a bit and share it here later tonight.


Restoring Wyze Door Contact Sensors MAC Addresses

Parts Needed:

  • Uses UniFlash 6 (search for NWJS.app on Macs)
  • CC1310 Launchpad Board w/ microUSB cable
  • Modified .bin file that contains matching MAC address ( see below)
  • Jumper Cable with 2 male pins
  • 2 mini-grabbers to female pin
  • Wyze Contact sensor removed from case
    • There’s a small white plastic melt that needs to be removed, it’s near the antenna/center of sensor

How to handle wyzeback on machines where the script doesn’t correctly create a valid bin:

  1. Locate the original wyzesense_door_AABBCCDD.bin file and open it in BBedit
  2. Do a Find and Replace, finding AABBCCDD and replacing with whatever the MAC address should be for the corresponding sensor
  3. Save the file as wyzesense_door_<new_mac_address>.bin denoting whatever the sensors original MAC address was OR rename with description of sensor location (ie front_door.bin)

Burning the firmware

  1. Use some double sided foam tape to secure the sensor down to the working surface. Avoid metal surfaces!
  2. Ensure magnet is making up the contact sensor (possibly puts sensor in fw load mode)!
  3. Connect the sensor to the LaunchPad like so
    1. GND goes to flat pad for the battery, ensure the mini grabber does not also contact the pcb via’s located right under the batter contact. Carefully hold the ring part of the battery contact while gentling prying the battery contact finger up
    1. 3.3V from LaunchPad goes to the tall part of the battery holder
    1. TMS from LaunchPad goes to the M pad on the sensor board.
    1. TCK from LaunchPad goes to the C pad on the sensor board
    • NOTE: The correct TMS and TCK are located in the center of the launchpad. Remove the black jumpers for both. If you use the TMS and TCK that are on the side of the launchpad, loading will not occur!

  1. Ensure that the pins touching the M and C pad have enough pressure and are aligned correctly for adequate contact with the 2 pads. It’s also possible that the pin for pad M can contact the 3.3 volts of the batter holder which will result in a failed load.
  2. Try to keep movement to a minimum while the pins are touching the pads
  3. Open UniFlash and Connect the USB cable
  4. Click Browse and navigate to where ever you saved your new .bin files, then select the .bin that has the correct MAC address for the sensor being loaded
  5. Select the Settings & Utilities tab on the left and click Erase Entire Flash
  6. Select the Program tab on the left, Click the Load Image and wait for the success.

After successful loading, it may be necessary to re-pair the sensor to Home Assistant

  1. Call the service wyzesense.scan
  2. Hold the button down on the door sensor until the red led blinks a few times

If issues ensue…

  1. Start a new session and ensure the pins are still contacting the M and C pads
  2. Attempt to get chip info by clicking the [more info] link at the top of the window
    Then select ‘read’ near the chip graphic to attempt to get the chip info. This verifies you have a good comm path to the sensor
  3. Select the Settings & Utilities tab on the right and click Erase Entire Flash again