VZM31-SN 2.14 causing Zigbee mesh to be unreliable

Switches Firmware Discussion
1

I installed 20 VZM31-SN switches, they are all running 2.14 firmware in smart bulb mode. I have a Zigbee mesh of ~175 devices.

Since installing the switches, I have noticed issues communicating with lights and door, and motion sensors: like the Inovelli switches are dropping devices that are connected to them.

I assumed it was an issue with my CC2625P coordinator, so I swapped it for a EFR32MG21 coordinator and I am experiencing the same issues.

Devices experiencing issues:

Lamps: Philips Hue, LCA003, LCT001, LCT007, LCT016, LST002, LTA003, LTA008, LTE001, LTW015, LWA003, LWB014, LWB015,

Sensors:
Philips Hue SML001, SML003
Aqara RTCGQ11LM, WSDCGQ11LM, WXKG11LM, MCCGQ11LM

Smart plugs:

Sengled E1C-NB7

Please help. I am about ready to remove all the Inovelli switches I just painstakingly installed.

2

Further to that: I’ve setup a separate Zigbee network on a different channel, I can pair all my Hue lights just fine but when I go to pair an Inovelli switch: They start the interview process but don’t complete it.

These aren’t in the recall batch (E07:98:DF:… start of IEEE) but they are exhibiting similar behaviour.

3

I’d be putting those Aqara sensors on their own network. In fact, that’s exactly what I did at my place. They do not run the standard zigbee communication protocol and are known to cause havoc on zigbee networks and drop right off.

I had lots of similar issues until I split everything Aqara off, and used Ikea plugs and USB repeaters to build out a second network since they’re known to work well with Aqara. Since then everything has been rock solid.

4

The Aqara devices are EndDevices and do not route traffic.

This also does not explain the inability to include Inovelli devices on the 2.14 firmware on a brand new network. Nor the fact that my network was stable prior to installing Inovelli switches.

5

With a brand new switch out of the box, 2.08. Separate coordinator: Zigbee channel 25. Sniffer sitting next to the switch and the coordinator about six feet away.

The switch sends a beacon frame, association request and then just nothing:

No. Time Source Destination Protocol Length Extended Source Info
529 2023-04-23 09:47:36.127646 6c:5c:b1:ff:fe:5e:8b:37 0x0000 IEEE 802.15.4 21 6c:5c:b1:ff:fe:5e:8b:37 Association Request, FFD
1530 2023-04-23 09:47:36.773957 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1531 2023-04-23 09:47:36.786818 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1532 2023-04-23 09:47:36.800965 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1533 2023-04-23 09:47:36.813960 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1534 2023-04-23 09:47:36.828096 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1535 2023-04-23 09:47:36.842174 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1536 2023-04-23 09:47:36.856388 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1537 2023-04-23 09:47:36.869472 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1538 2023-04-23 09:47:36.883542 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1539 2023-04-23 09:47:36.897837 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1540 2023-04-23 09:47:36.912064 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1541 2023-04-23 09:47:36.927232 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1542 2023-04-23 09:47:36.941396 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1543 2023-04-23 09:47:36.956642 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1544 2023-04-23 09:47:36.970639 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1545 2023-04-23 09:47:36.985916 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1546 2023-04-23 09:47:37.000026 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1547 2023-04-23 09:47:37.014134 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1548 2023-04-23 09:47:37.027244 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1549 2023-04-23 09:47:37.041408 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1550 2023-04-23 09:47:37.055480 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1551 2023-04-23 09:47:37.068619 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1552 2023-04-23 09:47:37.082689 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1553 2023-04-23 09:47:37.095829 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1554 2023-04-23 09:47:37.109959 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1555 2023-04-23 09:47:37.122994 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1556 2023-04-23 09:47:37.137216 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1557 2023-04-23 09:47:37.150149 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1558 2023-04-23 09:47:37.163335 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1559 2023-04-23 09:47:37.177533 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1560 2023-04-23 09:47:37.189298 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1561 2023-04-23 09:47:37.203311 0x0000 0xbf55 ZigBee 73 00:12:4b:00:24:bc:3d:3b APS: Command
1573 2023-04-23 09:47:42.917003 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1574 2023-04-23 09:47:43.629325 0x0000 Broadcast ZigBee 59 00:12:4b:00:24:bc:3d:3b Route Request, Dst: 0xbf55, Src: 0x0000
1584 2023-04-23 09:47:56.654870 0x0000 Broadcast ZigBee 59 00:12:4b:00:24:bc:3d:3b Route Request, Dst: 0xbf55, Src: 0x0000
1586 2023-04-23 09:47:57.259748 0x0000 Broadcast ZigBee 51 00:12:4b:00:24:bc:3d:3b Many-to-One Route Request, Dst: 0xfffc, Src: 0x0000
1591 2023-04-23 09:47:58.747873 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1609 2023-04-23 09:48:14.576229 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1614 2023-04-23 09:48:19.692389 0x0000 Broadcast ZigBee 59 00:12:4b:00:24:bc:3d:3b Route Request, Dst: 0xbf55, Src: 0x0000
1646 2023-04-23 09:48:30.403801 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1663 2023-04-23 09:48:42.719947 0x0000 Broadcast ZigBee 59 00:12:4b:00:24:bc:3d:3b Route Request, Dst: 0xbf55, Src: 0x0000
1669 2023-04-23 09:48:46.234755 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1683 2023-04-23 09:49:00.173329 0x0000 Broadcast ZigBee 51 00:12:4b:00:24:bc:3d:3b Many-to-One Route Request, Dst: 0xfffc, Src: 0x0000
1684 2023-04-23 09:49:02.062748 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1690 2023-04-23 09:49:05.760172 0x0000 Broadcast ZigBee 59 00:12:4b:00:24:bc:3d:3b Route Request, Dst: 0xbf55, Src: 0x0000
1703 2023-04-23 09:49:17.890408 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1739 2023-04-23 09:49:28.796936 0x0000 Broadcast ZigBee 59 00:12:4b:00:24:bc:3d:3b Route Request, Dst: 0xbf55, Src: 0x0000
1746 2023-04-23 09:49:33.721211 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1769 2023-04-23 09:49:49.549530 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1785 2023-04-23 09:50:03.088854 0x0000 Broadcast ZigBee 51 00:12:4b:00:24:bc:3d:3b Many-to-One Route Request, Dst: 0xfffc, Src: 0x0000
1789 2023-04-23 09:50:05.379436 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1823 2023-04-23 09:50:21.208787 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
1849 2023-04-23 09:50:37.035507 0x0000 Broadcast ZigBee 47 00:12:4b:00:24:bc:3d:3b Link Status
6

Untitled
Untitled1440×3200 406 KB

For the heck of it, I setup another test network with a CC2562P stick on Channel 25. I then built a test bench for a brand new out of the box Inovelli Blue and it still won’t pair.

I see the beacon request, I see the response from the coordinator and request for data (like above) and nothing back from the switch>

These are the only devices that have problems in my network. I don’t think it’s a hardware problem because if I try like 50 times to pair them, they eventually pair and have fine LQI (>200).

7

Agreed. But it’s also a well known issue.

Straight from zigbee2mqtt’s Aqara device page

Troubleshooting: device stops sending messages/disconnects from network

Since Xiaomi devices do not fully comply to the Zigbee standard, it sometimes happens that they disconnect from the network. Most of the times this happens because of the following reasons:

  • Device has a weak signal, you can see the signal quality in the published messages as linkquality. A linkquality < 20 is considered weak.
  • Low battery voltage, this can even happen when the battery still appears full. Try a different battery.
  • The device is connected through a router which cannot deal with Xiaomi devices. This is known to happen devices from: Centralite, General Electric, Iris, Ledvance, Legrand, OSRAM, Sylvania, SmartThings, Securifi. A possible solution is to connect the device directly to the central coordinator by pushing the reset button while being physically close to it.

From personal experience, you can’t always force a device that is far away to connect directly to a coordinator. You also cannot force a device to stay connected to the coordinator when there’s a router nearby with a better connection.

Since 2/3 devices you’re having issues with are Aqara devices, this is most likely your issue. You can find tons of info on this on any smarthome platform’s boards. Here’s a thread on Hubitat’s community with nearly 900 replies.
Xiaomi & Aqara Devices - Pairing & Keeping them connected - :bellhop_bell: Get Help / Devices - Hubitat

8

I appreciate your attempts to help (and my initial message was not clear), but it is clear you are not reading the issues I am having and you are assuming they are related to Aqara. They are not. They are:

  1. Problems pairing Inovelli devices, both on my original mesh AND various test coordinators (CC2526P, EFR32MG21, Raspbee II).
  2. Problems with my main Zigbee network since I added the Inovelli switches. Prior to that, my network was 100% stable with no issues.

In my response, which was glazed over, that is the attempt of an Inovelli switch to connect to a test coordinator within eye sight of the switch.

These units are not in the bad IEEE batch, but there is clearly something going on with them. If I can pair Hue, Sengled, Aqara, Sonoff devices both battery and mains powered to my test environment AND my production environment, and Inovelli is the only ones with an issue …

9

OK you’ve confused me. Your initial post says after updating to 2.14 you’re having issues with things like door and motion sensors dropping off your network. Hence my recommendation to move the Aqara devices to a standalone network since this is a known issue due to Aqara not using standard zigbee protocols.

But you then say that you’re having pairing issues with the Inovelli switches and they’re the only devices having issues on your network.

So are we looking at a devices dropping off after 2.14 issue? Or are we looking at a pairing of your switches issue?

1 Like
10

Edit: To clarify, I originally thought this was a firmware issue specific to 2.14. I now do not think so.

I just purchased these switches 2 weeks ago and have installed them.

I originally paired them fine with 2.08, albit after 1-2 attempts per switch.

They then OTAed to 2.14, at which point I noticed issues with the performance of my Zigbee network.

I attempted to troubleshoot the issue by creating a separate Zigbee network for my Inovelli switches, only to discover that I could not actually add them to any new network! It took me like 30 tries (literally) to re-pair 2 of my ‘production’ switches that I removed to test to my main network, and I could never get them to add to my test networks.

I have setup a bunch of test networks, on different coordinators (CC2562P, Raspbee II, EMBRnet), with different firmwares, assuming it was an issue with the Z-Stack or EmberNet firmwares. It does not appear to be the case.

I then opened a new box with a 2.08 firmware, only to discover that the switch will not pair, it does a Beacon request but then doesn’t respond to the coordinator.

If it was an environment issue, or an issue with my coordinator, I would expect to see the pairing issue happening on all my devices.

During this time, I have moved Hue lights, as well as battery operated devices (Sonoff, Aqara, Hue) between networks to test things out, and all the devices other than the Inovelli’s pair just fine.

I have 20 Inovelli switches installed on my ‘production’ network, they are connected, performing, but they keep dropping their children which is causing issues with my devices.