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.
2 Likes
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:
- Locate the original wyzesense_door_AABBCCDD.bin file and open it in BBedit
- Do a Find and Replace, finding AABBCCDD and replacing with whatever the MAC address should be for the corresponding sensor
- 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
- Use some double sided foam tape to secure the sensor down to the working surface. Avoid metal surfaces!
- Ensure magnet is making up the contact sensor (possibly puts sensor in fw load mode)!
- Connect the sensor to the LaunchPad like so
-
- 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
-
- 3.3V from LaunchPad goes to the tall part of the battery holder
-
- TMS from LaunchPad goes to the M pad on the sensor board.
-
- 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!
- 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.
- Try to keep movement to a minimum while the pins are touching the pads
- Open UniFlash and Connect the USB cable
- 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
- Select the Settings & Utilities tab on the left and click Erase Entire Flash
- 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
- Call the service wyzesense.scan
- Hold the button down on the door sensor until the red led blinks a few times
If issues ensue…
- Start a new session and ensure the pins are still contacting the M and C pads
- 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 - Select the Settings & Utilities tab on the right and click Erase Entire Flash again
11 Likes
thanks exeljb for the superb howto.
i followed it & flashed 3 contact sensors. they no longer give the 2 flashes on startup/5 flashes on pin typical of bricked sensors, but give the expected 1 flash on startup, 3 flashes on pin insertion.
Unfortunately i couldnt get them to connect to either of my 3 Wyzecamera bridges .As the sensors were still listed in the Wyze app I tried invoking them with a magnet to see if the state would change, Then i deleted them from the app and tried adding them again. no luck.
I also tried using the uniflash memory read, and i could actually see the right MAC address was in the memory (i found the offset addresses by looking at positions of AABBCCDD in the patchedAABBCCDD.bin file with a hex editor)
[this screenshot is from google images]
in my case prior to flashing I had to use the erase function before the program load would succeed.
either i am doing something elementary wrong here with the pairing to the bridge, or the flash somehow is failing silently. One thing i noticed was the verify never succeeds, but the offset it complains about is towards the end of the binary file (maybe its endof memory file filler? anyone else notice this verify issue when flashing?)
this is the console error for verify
any suggestions from anyone here on the forum of things to try when pairing with the wyze app or where i could have got a step wrong are more than welcome.
thanks
S
I just have to ask … is your mac really AABBCCDD?
Also, did you change all 8 occurrances in the bin file?
And one final thought. Which .bin did you modify and use … door OR motion?
yes please do fire away, as my sensors didn’t pair, it must be that I missed some minor detail some where.
the AABBCCDD is inside the wyzesense_door_AABBCCDD.bin which is part of the wyzeback.py package. the authors python code does a global file & replace in this file with the MAC you supply as an argument. I used it but
you could also opt to use a hexeditor instead.
I used the MAC addresses which were still saved in the wyze app . and when I didn’t manage I peeled one of the sensors original backing off it’s window frame to double check.
thanks
I"m unfortunately not that experienced with the pairing of the sensors to the wyze app since I’m only using Home Assistant with the sense bridge plugged straight into my computer. When you entered the mac addresses, did you use capital letters or lower case ones? It probably doesn’t matter but maybe when the sensor compares the mac address, A doesn’t equal a? All of my address entries are lower case.
Another thing to check is that you have a solid blue light on your bridge and a blinky blue when attempting to pair. I’m guessing that behavior is the same regardless if the wyze cam/app or home assistant is requesting a sensor pair.
I didn’t get the verify function to work either. I’m not too sure of that functionality. My verification was the single blink at boot up and successful pairing to home assistant.
EDIT: Scratch that last paragraph, I gave it a try tonight when i was farting around with a sensor and the verification succeeded. You might have to power cycle the launchpad and the sensor for it to successfully to a verification.
If I have anymore ideas or questions, I’ll post em
regards case of the MAC, i couldnt remember which case i used, so i referred to the code in wyzeback.py ,it caters for either case
has anyone heard/read on the forums of someone who managed to unbrick using a launchpad, and then managed to connect the sensors to the Wyze app (i.e. not Home Assistant) ?
1 Like
I did some tinkering tonight and wanted to share the weird behavior I observed with one of these contact sensors. I’ve been testing with this sensor using a battery that has a small test led across it to speed up the drain a bit. One odd thing I noticed with this setup was whenever the magnet made up the reed switch, the test led would blink. It looked like a large voltage drop was occurring but my meter is too slow to show the actual voltage that it dropped to. It was showing only a 0.2v drop. Later on as the voltage of the battery dropped further, around the 2.5v range, the sensor became unresponsive to reed switch changes and the test led would continuously pulse on and off. again only dropping 0.2v. I’ll need to use a quicker way to record that voltage measurement to see more about what’s going on, but that was pretty unexpected activity.
Another thing I noticed during those tests were when disconnecting power to the sensor, either after through battery power or launchpad power, there’s still voltage sensed on the sensors battery terminals. It slowly decreases when the magnet isn’t making up the reed switch, but moving the magnet close to make up the switch will speedily drop that voltage. So there’s some sort of capacitive energy storage going on in this circuit. It’s probably a good idea to do your battery changes away from the magnet to give you more time while that charge dissipates.
So on to my tinkering tonight. That battery was dead dead, 0v. I powered up the sensor using the launchpads 3.3v and it did nothing. no power on led blinks, no reed switch blinks, it did nothing. However it did communicate with my laptop and load a wyzeback.bin file tho, so the mcu was still there in some weird state. I grabbed a battery that was at 3.02v and put it in the sensor, then the sensor started up and did it’s 3 blink low battery blink. Weird. Pairing it with home assistant and the mac address was zeros! Keep in mind, this was immediately after i loaded the wyzeback with the correct mac address. I did another firmware load just to make sure i didn’t screw up and enter the wrong mac address/select the wrong .bin file but the sensor acted the same way using the 3.02v battery. I grabbed a brand new battery that was at 3.2v and found I had to re-pair it to home assistant. Weird. Home assistant came back and found the sensor with the correct mac address. I quickly swap out to the 3.02v battery and no issues…the sensor responds correctly in home assistant. More weird. It also wasn’t showing the 3 blink low battery notification either.
Why would a battery that doesn’t work when powering up the sensor work when it’s swapped out quickly but will not work if powering it up after a few moments of the sensor not having any power applied? This behavior just seems so odd. It really makes me wonder how crazy the firmware programming is in these things. It’s a shame we’ll probably never get a chance to see the source programming of these sensors.
1 Like
I wonder if you could use a raspberry pi to reprogram them using info from Here:Raspberry Pi (2/3) as a JTAG/SWD adapter.
i would expect it to work jtag is an open standard, the article you mentioned refers to the full jtag, where on this little board compact cjtag is used, 2 pins power, 2 pins data. the 4 pins correspond to the 4 holes drilled into the sensor back cover. you would need to find the cjtag equivilent for the raspberry…
illustration from the wyzeback github page
Also if you are interested temperature thread link
I looked into this a while back for the Raspberry Pi and BusPirate… Since OpenOCD doesn’t support cJTAG, you will need to use JTAG (CC1310 does support it). The problem is the 2 extra JTAG pins are not easily accessible, and you will need to solder them directly on the CC1310’s crazy tiny pads.
Why would Wyze disable the button?
If anyone’s interested, you can write protect the flash to stop the sensor from writing to the flash & corrupting the MAC address…
Flash Programmer 2: Go to Edit, select CCFG, click Read. Go to 1FFF0, change the FF FF FF FF to 00 00 00 00, then click Write.
UniFlash: Go to Memory, click Read, Export, enter address 0x0, size 0x20000, Generate. Open the file using a hex editor, go to offset 1FFF0 and replace the FF FF FF FF with 00 00 00 00. Flash the file as usual.
This sets CCFG_PROT_31_0 setting in the CCFG.
But before doing this, make sure the sensor is paired to the bridge since you can’t change it once it’s set.
To flash a new image in the future, erase the entire flash first.
6 Likes
This is a brilliant solution!
I think I will wait until the new V2 hub comes in, then pair all the V1 sensors to that, then write-protect them so I don’t have to worry so much about this problem. Thanks for sharing! I love this option
I concur - considering the alternatives so far, that is a brilliant stopgap idea. I assume this just relies on the USB connection and software previously described?
1 Like
Sorry, I should have said it requires a cJTAG programming device, like a TI Launchpad (any version with XDS110).
3 Likes
I didn’t think the new hub supported the version 1 sensors ?
Chas
still an excellent contribution from your end null.
Can you simplify the process and include instructions for those who use apple products
Yeah, that’s a common misunderstanding that I had clarified with Wyze employees.
The new hub DOES actually support running the v1 sensors (the v1 sensors can connect to it and run off of it instead of the bridge in the V2 cams). However, what they were saying is that the v1 sensors will NOT be allowed to be used as part of the Home Monitoring Service. They cannot be added to the HMS tab, they cannot set off Security “Alerts” nor Security “Alarms” or anything.
When connected to the hub, they will simply continue to function as they currently do…still logging open or closed, run rules, send normal app notifications if you set up to receive them.
So when they say V1 sensors don’t work with the HMS system, they just mean the HMS tab, alerts/alarms, but it will connect to the hub. Or so they clarified to me when I asked about this.
1 Like