Strange Zigbee Device Appearing on Network

🛎️ Get Help Devices
1

Hi,

I found a strange Zigbee device on my network and wondering if anyone has an idea what it might be...

How did I find it? I've been having some trouble with the reliability of my Zigbee mesh, so I've been scouring this forum and other sources for information about how to troubleshoot. I've got a Digi XStick and managed to get it to join my Zigbee network, and used XCTU to map out the mesh. I export the table from XCTU to a file, and wrote a script to correlate the XCTU data and the Hubitat device list, and spit out a CSV file I can review info with discernable names rather than just MAC and DNI of devices. That all works great and is helping me figure out what links have poor quality, etc.

While working on this, I added a check in my script so that when I take a DNI found in XCTU and look it up in the Hubitat device list, if the MAC of the device in XCTU doesn't match the MAC of the device in Hubitat, or if the DNI isn't found in Hubitat, then I'll get an error. And I did, which notified me of something weird.

In XCTU, I see a device that I can't find in Hubitat. The device has a MAC of 847127FFFE3610D7. I have several GE/Enbrighten/Jasco Zigbee dimmers, many of which have a MAC that starts with 847127FFFE3, so it seems likely that's what kind of device it is. Except that all of my GE/Enbrighten/Jasco Zigbee dimmers are accounted for, and none of them have this MAC. One has a very similar MAC of 847127FFFE361057 but that seems coincidental.

I scan my network with XCTU 10 times before exporting the output. XCTU finds every device on the 10th scan, except this one, which was last found on the 6th scan.

The "phantom" device has only one connection, to a Zigbee outlet. XCTU shows the link from the "phantom" device to the outlet as Active status. When I look at the outlet in XCTU, it shows 18 connections, including this one. The link from the outlet to the "phantom" device is listed as Unknown status. The outlet reports in Hubitat as eWeLink SA-003-Zigbee.

Not really sure what to make of all this, and wondering if anyone has any ideas? Assuming there's a logical explanation, I just can't figure out what it is.

Thanks...

2

Can you delete it from the mesh with something like xbee? (Note:I don't know if xbee can actually do this or not.)

3

Unfortunately, ghost devices are common for Z-wave, but I have never heard of one with Zigbee.

Have you recently added a new outlet to your Zigbee mesh? Ghosts sometimes occur with Z-wave when adding new devices. I expect the ghost device may be associated with the device that has a similar MAC address. Perhaps during the initiation process a couple of data bits were transmitted incorrectly. That can happen if the device is too far away from the hub during the pairing process. If removing the ghost device does not work, you might try removing both the actual device and its ghost from the mesh and then repairing the actual device.

4

This could happen if you had a Zigbee device that was removed from Hubitat but not reset. Normally, this will happen if the device is available when "Remove" on the device page is clicked, the normal way you might remove a Zigbee device, but if it was offline--unplugged, dead battery, etc.--at that point, then it won't be, and you'll need to manually reset it later. It can also happen if it's the rare Zigbee device that isn't always listening, like some (all?) Xiaomi, Sonoff, and probably other battery-powered devices. I'm not sure I've seen it with mains-powered devices, and I'm not sure if eWeLink fall in this category, but I do know that is how some Sonoff devices are branded, so...maybe?

But, then, you should have some outlet plugged in somewhere that you know exists but isn't paired to your hub.

2 Likes
5

As I understand it, XCTU recovers routing information from each router, and not the coordinator. The other possibility is that there is the zigbee equivalent of a "stale" route left in the zigbee outlet that the device was shown routing through. Or 1-bit of memory corruption that resulted in the wrong MAC address being stored.

Either way, unpowering the outlet and then repowering it should the spurious device disappear.

2 Likes
6

@aaiyar beat me to it: Speculation here, I wonder if it is not a coincidence that two 64 bit MAC addresses on your network differ by only a single bit (hex 'D' = 1101, hex '5' = 0101).

The bit pattern of the MAC is burned in ROM in some device on the NIC (either discrete or embeded in the SOC; not sure how they do this). I doubt the ROM is protected by parity or ECC, but the mfg. might have implemented some kind of power-on error checking when the device initializes (via CRC or checksum covering the programmed MAC field and the rest of the ROM data). However if this wasn't implemented, maybe a flaky bit in the ROM is randomly causing two MAC addreses (you did say you were having reliability issues with your mesh). Zigbee transmissions are protected by CRC, but if the device initializes itself with a corrupted MAC, the frame check sequences used during operation wouldn't prevent this kind of problem.

Is there a way you can verify that both the 'valid' device and the phantom are both present on your network simultaneously? Maybe unplug the valid device and redo a scan; if there is something flaky with it, you wouldn't expect to see the phantom when you map your mesh.

2 Likes
7

Thanks everyone for the ideas / suggestions! I decided to do a factory reset on the outlet, as well as the dimmer with a MAC similar to the "phantom" device. I did that last night. Coincidentally (I think) the Zigbee network went offline in Hubitat overnight, so I rebooted the hub this morning. Then I re-ran 10 back-to-back scans of the mesh from XCTU. This time, no "phantom" devices were discovered. I plan continue to run these scans periodically as part of my Zigbee network troubleshooting, and will repost to this thread if I encounter the "phantom" device again.

@rlithgow1 - I don't see an obvious way to do that from XCTU. There is a console mode within XCTU that seems geared toward observing serial commands but there could be a way to issue a command through the XStick that could change the state of the Zigbee network. However, that's way beyond what I know.

@rwclements228 - aside from the XStick, I believe the outlet in question was the last device I added to the network, about a month or two ago. It was shortly after I started having stability issues with Zigbee, so I don't attribute the issues to this outlet. But your idea that the "phantom" device is really the dimmer with the almost identical MAC (only one bit off, as another poster pointed out) makes sense.

@bertabcd1234 - so, the outlet reporting the connection to a phantom device was one of the last devices I added. I have never removed the outlet, and until last night had never performed a factory reset on it. the dimmer with the similar MAC, that might possibly be the same as the phantom device, has been reset a few times. but, it hasn't been reset since the outlet was added to the network. and, I am 95% sure I don't have any Zigbee devices powered on that aren't connected to Hubitat.

@aaiyar - the outlet had been powered off/on the day before I ran the scan, because the power to the house was interrupted. I did not try just powering it off/on and then re-running the scan, but I did do a factory reset on the device. makes perfect sense that if it was a "stale" route or 1-bit memory corruption that would clear it.

@Tony - the "valid" device is an in-wall dimmer, so I guess I would turn off the breaker to the dimmer rather than unplug it. I didn't try that, but I did do a factory reset on the dimmer, which it seems like would reset the device's in-memory representation of its MAC. if your theory is correct, I wouldn't be surprised to see this sort of phenomenon again in the future. at that point, I will try your suggestion to confirm that the problem device is the dimmer.

Thanks all!

2 Likes
8

2 thoughts, as I've had the same issue:

  1. a smart meter, maybe a water meter as some use zigbee
  2. could these stale entries be involved in mesh issues? or would the stale route eventually be cleared

Actually 3 thoughts... I've seen zigbee devices that present 2 unique addresses upon pairing. I don't recall the exact device. Maybe my Centralite Zigbee nightlight or a cheap Tuya device-I have too many devices and have trouble storing all the boxes and keeping track !

1 Like
9

They do. But usually it is lower channel zigbee (~900 MHz).

10

The 16-bit address may change but the 64-bit IEEE MAC is constant... Or at least it should be. That's how the device gets remembered between resets and subsequent pairings.

1 Like
11

Ah ha, I remember you had pointed that out once before. Do we think that could interfere with Z-wave?

I'm starting to hate my hub. Very inconsistent. It'll run fine for for a month, then without any changes, no new devices, no new rules, devices start failing to respond. Last night for example, all the lights on the front of my house went off on schedule, except one bulb(which for months has worked fine). It wouldn't respond at all even from the device page, but as soon as I disabled and re-enabled my zigbee radio, it started responding.

This all reminds of having a girlfriend who is crazy, but the s.. ah I better not.

1 Like
12

What channel is your zigbee on? Have you done a wifi scan to find the least busy channel (usually 20 and up is your best bet)

13

No, at least not in my limited experience. To expand somewhat - I have two zigbee networks (Channel 25 - 82 devices; Channel 15 - 38 devices), and one z-wave network with 60 devices. I have a smart meter that I have "read". But I have no issues with any of my z-wave devices.

14

Yes sir. I'm aware, my wifi is 1, my zigbee are 20 & 25, and my nearest neigbors' networks and other RF are at a low-85 - -95, and mostly on channel 6

1 Like