Door sensors are being added with 00000000 mac and all act under same mac

[P1X3]

I am attempting to add couple more door sensors into my home assistant that is running on as docker container. Call to service is made okay and led is flashing blue. Once reset pin on door sensor is pressed and light flashes, the door sensor entity shows up in home assistant notification with no mac id like other door sensors or motion sensors.

However, in debug log the sensor still sends and home assistant receives changes, but notice the mac address.

2020-04-30 20:57:54 DEBUG (Thread-2) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '\x00\x00\x00\x00\x00\x00\x00\x00', 'state': 0, 'device_class': 'door', 'timestamp': '2020-04-30T20:57:42.800000', 'rssi': -71, 'battery_level': 97}

I tried to remove this device using its actual mac address and the 00000000 mac. Neither produced anything. What is more crazy, if I connect battery to another door sensor that is not added yet, yes I have only one cr1632 battery for now, it is automatically sending updates to home assistant without me adding it. I take the battery out, and put it in yet another door sensor that was not added to home assistant, and it also sends changes to home assistant. However, they all send it under 00000000 mac.

These sensors were used originally with wyze cam, but then batteries died and until now I didn't bother to install them in new house.

[BaconWithThat]

Having a similar issue. 2 of my sensors stopped responding and after trying to rescan them they present with a blank MAC. I took 2 new sensors out of the box and they scanned perfectly fine.

[P1X3]

Having a similar issue. 2 of my sensors stopped responding and after trying to rescan them they present with a blank MAC. I took 2 new sensors out of the box and they scanned perfectly fine.

After addicting new sensor with normal mac, do other still add with zero mac?

All of my sensors were previously paired with wyze hub and were used in wyze ecosystem. While moving to a house door sensors discharged fully. After relocating I straight up setup wyze hub for home assistant. None of the sensors were added automatically, still not sure if should have, but I just started pairing sensors again and all except those with dead batteries were added.

[BaconWithThat]

I haven't tried to repair the ones with a zero mac since adding the fresh out of the box sensors, but I can try that later today.

[jes1417]

Try replacing the batteries

On Fri, May 1, 2020, 9:08 AM BaconWithThat notifications@github.com wrote:

I haven't tried to repair the ones with a zero mac since adding the fresh out of the box sensors, but I can try that later today.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kevinvincent/ha-wyzesense/issues/130#issuecomment-622402814, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJCT7SZADNWJAWJ2ATHCY4DRPLJWTANCNFSM4MWYSQ3A .

[BaconWithThat]

Try replacing the batteries

I tested the batteries on my multi-meter and they were both 2.95v or above.

[P1X3]

I am also testing with brand new energizer lithium battery and still same 00 mac

[P1X3]

Tested same sensors with original wyze ecosystem (wyzecam + same bridge) and contact sensors are not pairing either. Sensor does blink when reset for pair and does blink when there is contact with magnet. It also does respond to hub via homeassistant but it seems like sensors mac got overwritten with 00000000.

Point is, sensors are not dead, their mac was overwritten.

[P1X3]

2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa531d1900000171d6de4024a2000000000000000001175e000101000b4c0583'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5319, Payload=b'00000171d6de4024a2000000000000000001175e000101000b4c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5319)
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555319ff026a'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '\x00\x00\x00\x00\x00\x00\x00\x00', 'state': 1, 'device_class': 'door', 'timestamp': '2020-05-02T15:30:21.860000', 'rssi': -76, 'battery_level': 94}
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa53193500000171d6de42b80ea200000000000000000100000c057d'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa53193500000171d6de42b80ea200000000000000000100000c057d'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5335, Payload=b'00000171d6de42b80ea200000000000000000100000c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5335)
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555335ff0286'
2020-05-02 15:30:28 INFO (Thread-2) [custom_components.wyzesense.wyzesense_custom] LOG: time=2020-05-02T15:30:22.520000, data=b'a200000000000000000100000c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa531d1900000171d6de42cca2000000000000000001175e000100000c4b062c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa531d1900000171d6de42cca2000000000000000001175e000100000c4b062c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5319, Payload=b'00000171d6de42cca2000000000000000001175e000100000c4b'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5319)
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555319ff026a'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '\x00\x00\x00\x00\x00\x00\x00\x00', 'state': 0, 'device_class': 'door', 'timestamp': '2020-05-02T15:30:22.540000', 'rssi': -75, 'battery_level': 94}
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa531d1900000171d6de42cca2000000000000000001175e000100000c4b062c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa531d1900000171d6de42cca2000000000000000001175e000100000c4b062c'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5319, Payload=b'00000171d6de42cca2000000000000000001175e000100000c4b'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5319)
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555319ff026a'
2020-05-02 15:30:28 DEBUG (Thread-2) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '\x00\x00\x00\x00\x00\x00\x00\x00', 'state': 0, 'device_class': 'door', 'timestamp': '2020-05-02T15:30:22.540000', 'rssi': -75, 'battery_level': 94}
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa53193500000171d6de461b0ea200000000000000000101000d04e6'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa53193500000171d6de461b0ea200000000000000000101000d04e6'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5335, Payload=b'00000171d6de461b0ea200000000000000000101000d'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5335)
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555335ff0286'
2020-05-02 15:30:29 INFO (Thread-2) [custom_components.wyzesense.wyzesense_custom] LOG: time=2020-05-02T15:30:23.387000, data=b'a200000000000000000101000d'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa531d1900000171d6de462fa2000000000000000001175e000101000d4c0596'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa531d1900000171d6de462fa2000000000000000001175e000101000d4c0596'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5319, Payload=b'00000171d6de462fa2000000000000000001175e000101000d4c'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5319)
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555319ff026a'
2020-05-02 15:30:29 DEBUG (Thread-2) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '\x00\x00\x00\x00\x00\x00\x00\x00', 'state': 1, 'device_class': 'door', 'timestamp': '2020-05-02T15:30:23.407000', 'rssi': -76, 'battery_level': 94}
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa53193500000171d6de489b0ea200000000000000000100000e0568'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa53193500000171d6de489b0ea200000000000000000100000e0568'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5335, Payload=b'00000171d6de489b0ea200000000000000000100000e'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5335)
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555335ff0286'
2020-05-02 15:30:30 INFO (Thread-2) [custom_components.wyzesense.wyzesense_custom] LOG: time=2020-05-02T15:30:24.027000, data=b'a200000000000000000100000e'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa531d1900000171d6de48afa2000000000000000001175e000100000e4c0618'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa531d1900000171d6de48afa2000000000000000001175e000100000e4c0618'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5319, Payload=b'00000171d6de48afa2000000000000000001175e000100000e4c'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5319)
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555319ff026a'
2020-05-02 15:30:30 DEBUG (Thread-2) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '\x00\x00\x00\x00\x00\x00\x00\x00', 'state': 0, 'device_class': 'door', 'timestamp': '2020-05-02T15:30:24.047000', 'rssi': -76, 'battery_level': 94}```

Here is a log of the contact sensor. 

[dale3h]

I just had this happen to one of my contact sensors after updating to 0.0.7. I haven't yet attempted to pull it off of the door to get its original MAC from the back, but when paired it seems to have a null MAC. I'm about to swap it out with an extra I have, so I'll be able to test it further and provide whatever is needed to help fix this issue.

[dale3h]

So, I went to replace the door sensor and ended up having the same issue with the replacement. I have two set aside for testing and development purposes, and the one that was modified was the only one of the two that still had a valid pairing to the bridge. After many attempts, I was finally able to get at least one of them to pair with a MAC address, which happened to be the replacement. I haven't tried the original yet as I was excited that this may not be a consistent bug, but rather a random one that involves very specific circumstances.

[blulite]

I am having the same issue with two of my sensors. My Home Assistant is brand new and I can try stuff and/or completely wipe if that helps during the debug.

Is there a command that we can write a new MAC Address?

I had three switches that required batteries. Two came up with the NULL MAC, one is fine. I'm curious if the combination of low battery and pairing caused a zeroing of the MAC in the switch? Maybe having nothing to do with HA, just the fact that we are pairing with a low battery? Bear in mind, the paring event is usually done with a new switch and a new battery.

[bschatzow]

I had on sensor do the similar null Mac. After trying for several weeks, I assumed the sensor was bad and I replaced it with a new sensor and the new works fine. Do you have access to the wyse camera ( I don't) ? If so, does the wyse software see it correctly?

[blulite]

The Wyze software does not pair with it. If I call Wyze it's probably a "bad" switch. I would still like to hear if the API allows for a write MAC address?

[smoke007]

@blulite My test Wyze contact sensor just ate a battery, while not being used... (Spoiler, I'm guessing that might have something to do with what's wrong with this sensor) Anyways, I installed a new battery, but it wouldn't trigger state changes in HA, so I re-paired it and found the MAC as "\0\0\0\0\0\0\0\0". After trying everything to troubleshoot this, I finally connect the bridge back to a Wyze cam v2 and confirmed the senor doesn't work their either. Good news is that I chatted with Wyze support and they warrantied the sensor for me after providing my order #!

Back to HA; I found that I can override the bad MAC in HA under Configuration, Customizations, pick the sensor, and change the mac line. Type in the MAC found on your sensor in quotes; example "123456AB", then click save. Now, reboot HA. Go back to Customizations again. You will find a new sensor option has been inserted, named "assumed_state". This option will get removed if you trigger your sensor state change. So, while it's listed here, edit that option, don't un-check it though, and click save at the button.

Now you can use the bad sensor like normal, but I assume you can only use one bad sensor like this with an all zero MAC. I only have one bad one, so can't test if I had two bad with all zero MACs.

[smoke007]

@P1X3

I tried to remove this device using its actual mac address and the 00000000 mac. Neither produced anything. I was able to remove the sensor with all zero MAC using the wyzesense.remove service, but I had to use mac: "\0\0\0\0\0\0\0\0" for the Service Data YAML. I could then reboot HA, go to Configuration, Entities, find and delete the sensor entity. However, it didn't matter, because when I scanned for the sensor again, it would always come back with the same 00000000 MAC.

I posted on https://github.com/kevinvincent/ha-wyzesense/issues/130#issuecomment-624960162 how I changed the MAC within HA using Customizations if you're interested in testing that also. Sounds like you have multiple contact sensors with this issue. I have a feeling you'll only be able to use one of them with all zero MACs, but you can test for us. :) If they are all using MAC 00000000, then they won't be unique from each other and would act like a "group" of sensors. Good luck!

PS, I would recommend trying to get them warrantied for free through Wyze support chat like I did. You'll have to connect your bridge back to a camera again to go through the troubleshooting with them. My other contact and motion sensor are still working fine though and haven't yet used up their first battery. I hope these sensor don't all zero out the MAC when the battery runs low.

[CorneliousJD]

I guess I didn't need to open a new issue, crap. sorry guys.

Basically though 2 sensors w/ previously dead batteries both show MAC 00000000 now and I cannot use them.

If nobody here can get it to pair with their Wyze cam's using the sense bridge either then it may seem like these devices have a pretty serious flaw where if they sit too long w/ no battery they go bad completely by having their MACs overwritten somehow? Strange. Looking for input to see what we can do to troubleshoot/fix?

EDIT - Also adding 2 sensors w/ 00000000 MACs mace them both act like the same thing - no way to differentiate them at all so having two like this is useless. Which is fine becuase I just broke one of them :)

[CorneliousJD]

So, I went to replace the door sensor and ended up having the same issue with the replacement. I have two set aside for testing and development purposes, and the one that was modified was the only one of the two that still had a valid pairing to the bridge. After many attempts, I was finally able to get at least one of them to pair with a MAC address, which happened to be the replacement. I haven't tried the original yet as I was excited that this may not be a consistent bug, but rather a random one that involves very specific circumstances.

Any luck with testing with your old sensors again?

I was able to register NEW door sensors but not old ones as of now, broke one of the two old ones by messing with it (whoops) but I still have one that doesn't work and am fearful that the new ones will fall into thos 00000000 MAC issue when their batteries die eventually?

[WarbleSync]

Yup I'm having the same issue as well. It is weird to me because things like mac shouldn't be negotiable or be able to be overwritten. My assumption is the bridge is assigning a mac and for whatever reason it is blank or invalid and python is doing the /u0000 thing as a error handling. I haven't looked at the code (not sure I would understand it as I'm not a python dev by trade).

Would it be possible for us to update wyzesense.json with correct mac information found on the sensor or does that not matter. I'm guessing the mac was/is the key used to decide which device is which and if more than one device has the /u000 mac then it updates both states with the same info. Is there any other uuid or identifier that can be used to id the sensor? And instead of using an array maybe using an object with the mapping of { 'uuid':'mac' }? I'm just spit balling here so take that for what it is worth. Seems like this is a growing issue but I do appreciate the hard work that has been done here.

[smoke007]

@WarbleSync Have you tried connecting your contact sensor back to the Wyze Bridge? I did and it would no longer work with Wyze hardware either. Wyze support warrantied it for me and sent me a new one that works fine. If the sensor no longer works with Wyze bridge either, then that should indicate that the issue isn't with the code on HA, right?

My theory is that their is a flaw in the board hardware or software and it's corrupting itself on a low voltage state. Perhaps the MAC on these are changeable via software, like an asset tag number, not a true MAC.

Sadly, the new contact sensor they sent me has the same v2.1 on the board that my old one has, with the MAC issue. However, the new board also has a date printed on the board by the version: 2019-05-13. I also swapped batteries from the new one with the old one, but no change, as expected.

[CorneliousJD]

Sadly, the new contact sensor they sent me has the same v2.1 on the board that my old one has, with the MAC issue. However, the new board also has a date printed on the board by the version: 2019-05-13. I also swapped batteries from the new one with the old one, but no change, as expected.

I haven't personally tried connecting the bridge back to a camera because that's a lot of work ;)

Yeah my new ones all have v2.1 as well but now have dates on the boards, old ones did not have dates. No changes with me and my old ones eitehr.

I did reach out ot Wyze noting that I had two that this was happening on and they didn't even really have me do much troubleshooting and stated they would replace them if they're under warranty. I sent them my proof of purchase and everything just waiting on confirmation from them now.

I'm just worried at this point it will end up happening to all 6 of my contact sensors plus the new ones and I'll have to keep doing this dance. If it does I'll probably end up dropping the Wyze ones and going to something zigbee based instead, I don't want to though, I would love to continue to use these tiny little, very cheap sensors. Fingers crossed!

[Bottleface]

I'm seeing the same issue. I bought the Wyze Sense kit when it first came out and the batteries for my two contact sensors and my one motion sensor finally died. I can't get either of my contact sensors to pair to the bridge with an actual MAC, it's always 00000000, and because they both get added with the same MAC, they are indistinguishable at the software level. The more I dig around this issue the more it seems that it's an issue with the hardware and not the software. From what I can tell this integration simply interfaces with the bridge. So the issue exists before we even get into the HA realm. The fact that these sensors can't even be paired within Wyze's ecosystem further supports that point. Maybe I'm wrong, but that is my current line of thinking.

Something interesting that I noticed, according to their instructions on battery replacement, the red status light should flash once when the new battery is replaced, my presumably dead contact sensors always flash twice when putting a battery in them. I've tried multiple batteries, all with the same result.

Furthermore when pairing either of my contact sensors the red status light always flashes five times when I'm pretty sure their instructions say it should only flash three times.

I also have three motion sensors, and NONE of them exhibit this behavior. When adding a new battery (which I legitimately had to do recently because my original one died), they flash once. I just bought two new motion sensors and when I paired them they flashed three times, exactly like their documentation states. Also the flashes with the motion sensors seem to be slower, but that could just be differences with the hardware.

I have a support ticket open with Wyze specifically asking them what two flashes means when inserting a battery as well as what five flashes means when pairing. If I get any meaningful response I will post here. Until then I'm afraid I will just need to buy their set of four new contact sensors and hope that this doesn't happen in a year when their batteries die.

[CorneliousJD]

Thanks! I'm with you on this line of thinking too. I'm hoping the hardware has been "fixed" even tho the new ones say v2.1 orn the board still... they DO have the date printed when my origianl set of 2 sensors did NOT.

I have 8 sensors now one totally broken (oops, my fault!) One that registers with all 0's for the MAC 4 new ones just recently ordered 2 that Wyze replaced becuase of this MAC issue.

I really hope these new ones are fixed and we don't encounter the same issue in a year, because I'd rather buy Zigbee contact sensors at that point and be able to actually replace batteries rather than replacing sensors ever year :(

Fingers crossed! Keep us posted on what you hear from them!

[Mincka]

Same issue here with one door / contact sensor. I get the MAC with 0s when trying to pair it again after the battery swap.

But two weeks after, my motion sensor also fails to report its status properly... I tried to add it again in HA but special characters are displayed for the MAC address:

In my case, I can even buy a pack of door sensors or a new motion sensor from the official site. I bought a starter pack from Amazon USA with shipping to France. The sensor packs are not available on Amazon. It would cost to much to order from the official site with a international shipping service.

I think I am going to replace them with Aquara door sensors and Philips Motion Sensors. They are way more expensive than the Wyze sensors but also more reliable, and without tricks to use them with HA.

[Bottleface]

Alright, I'm a little slow to report back, but Wyze support got back to me shortly after I submitted my ticket. I would have liked a little more detail, but the gist of what they told me was this:

Normally sensors that are showing 5 blinks are indication of a sensor going bad.

So, I guess that is some kind of official indicator that things aren't working. Wyze Support is sending me 2 replacement sensors free of charge, even though I'm about 2 months beyond their warranty (I love Wyze, they are awesome). I am hoping that the new sensors work as expected. @CorneliousJD I also really hope that I don't have to do this again in a year. I'd much rather replace batteries than sensors.

[EspElement]

I can confirm the same thing. It only seems to be happening with my door sensors though, my motion ones work fine. Mac is 0000000 and now I cannot even add them back as wyzesense.scan doesn't find them anymore. Tired new batteries too.

[andystewart999]

Yep, I've got the same issue with the only two Wyze door sensors I've got. I'm going to raise a ticket with Wyze, the issue I have is that I'm in Australia so technically out of their support area. Fingers crossed.

[bcwhite-code]

I have a motion sensor that was working perfectly for months and then just stopped. The red light would still blink if I moved in front of it but HA didn't get the events. The last received event on Oct 12th gave an rssi=-89 and battery=90.

Playing with it, I found that a reset by holding the button for 3+ seconds did nothing. After that it didn't work at all. I took a battery from a new motion sensor and tried that. Now the motion detector works but the MAC is all zeros and, of course, does not work properly with HA.

It seems that power issues can cause the MAC to be erased. But not just any power issue... When I place the battery back in the new sensor I took it from, it functions fine (has the same valid MAC).

From my previous work with embedded systems, I can tell you that MACs are not burned into the phy. It's stored in some sort of persistent memory (typically EEPROM or Flash) and loaded as configuration into the phy during startup.

It's likely that this memory unit either failed or was cleared/overwritten by a bug in the hardware or firmware. Given the number of reported cases, I strongly favor the latter reason. Since every report I've seen mentions battery replacement, my best guess is that an under-limit voltage caused the memory to erase.

The MAC can certainly be reprogrammed since it was originally programmed on the assembly line but not by us mere mortals. Specialized equipment would be needed, probably via custom taps on the PCB.

Best thing, IMO, is to open a support request with Wyze and request a replacement. They're certainly aware of the issue and may replace older devices with a new spin of the hardware that doesn't have the problem (or be encouraged to do such a respin if they haven't already).

Update: You can tell a sensor with a bad MAC because the Notification created by HA just says "binarysensor.wyzesense" instead of "binary_sensor.wyzesense_XXXXXXXX". Though you can add use a device like that, you can only use one. Weird things will happen when a second one comes along.

[bcwhite-code]

With regard to this bug... I recommend refusing to add a sensor with an empty MAC and stating such in the generated HA Notification. Link to a FAQ or even this bug for "more information".

[andystewart999]

The 'all zero mac' issue is known to Wyze. Raise a ticket, they'll replace it.

---

From: bcwhite0 notifications@github.com Sent: Sunday, October 25, 2020 2:13:57 AM To: kevinvincent/ha-wyzesense ha-wyzesense@noreply.github.com Cc: andystewart999 andy.stewart@live.com; Comment comment@noreply.github.com Subject: Re: [kevinvincent/ha-wyzesense] Door sensors are being added with 00000000 mac and all act under same mac (#130)

I have a motion sensor that was working perfectly for months and then just stopped. The red light would still blink if I moved in front of it but HA didn't get the events. The last received event on Oct 12th gave an rssi=-89 and battery=90.

Playing with it, I found that a reset by holding the button for 3+ seconds did nothing. After that it didn't work at all. I took a battery from a new motion sensor and tried that. Now the motion detector works but the MAC is all zeros and, of course, does not work properly with HA.

It seems that power issues can cause the MAC to be erased. But not just any power issue... When I place the battery back in the new sensor I took it from, it functions fine (has the same valid MAC).

From my previous work with embedded systems, I can tell you that MACs are not burned into the phy. It's stored in some sort of persistent memory (typically EEPROM or Flash) and loaded as configuration into the phy during startup.

It's likely that this memory unit either failed or was cleared/overwritten by a bug in the hardware or firmware. Given the number of reported cases, I strongly favor the latter reason. Since every report I've seen mentions battery replacement, my best guess is that an under-limit voltage caused the memory to erase.

The MAC can certainly be reprogrammed since it was originally programmed on the assembly line but not by us mere mortals. Specialized equipment would be needed, probably via custom taps on the PCB.

Best thing, IMO, is to open a support request with Wyze and request a replacement. They're certainly aware of the issue and may replace older devices with a new spin of the hardware that doesn't have the problem (or be encouraged to do such a respin if they haven't already).

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkevinvincent%2Fha-wyzesense%2Fissues%2F130%23issuecomment-715928774&data=04%7C01%7C%7C966e20fd93714e0bf68308d8782f6da8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637391492377336382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2i7JqJzPOnqXxrYKZO%2BmP1%2FXu1JNwlzGaRzVsohNmbE%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEMUTCJUIIS3FB7S4KA24HLSMLVLLANCNFSM4MWYSQ3A&data=04%7C01%7C%7C966e20fd93714e0bf68308d8782f6da8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637391492377346374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=76aBdvh4lWWU63zS9XyhGk9eKxeaRaTq9ez%2B%2BkqC7gE%3D&reserved=0.