You previously suggested updating devices closest to the coordinator first and ensuring only one update occurs at a time. However, I have approximately 60 devices, and updating them individually is problematic given that each update takes about 26 minutes.
Additionally, I found that performing a reconfigure and re-interview after the update does not resolve the issue after I attempt to update 3-4 devices simultaneously.
Could you please advise on a more efficient way to manage these updates?
@vladimir.korobov@stefan814
Hey, just wanted to put in my 2 cents, just in case it helps.
I had a similar issue. I had set up my zigbee network on the default channel (I think it was 1). Updates were taking a long time (1h+), they would fail partway through, and sometimes it wouldn’t “stick”. So what I did was change my wifi access points 2.4GHz channels to 1 and 6 (I have 2 APs). Then I changed my zigbee channel to 25. It cleared up all my issues updating. I also only updated 3-5 switches at a time. You can also schedule updates, so if it fails, it will try again.
Additional info about my APs: they have a channel width of 20 and a transmit power of “Low”. Most of the 2.4GHz wifi traffic was on channels 1 and 6 in my area from my neighbors.
WARNING: I had to re-adpot the all zigbee devices after chaning the zigbee channel. I spent a while doing this to my 30 switches.
The updates were completed successfully without any issues. However, despite my efforts in updating them one at a time, reconfiguring, and re-interviewing the switch after each update, they still appear as not updated after some time. I am finding this very frustrating.
@vladimir.korobov we can arrange an exchange for one of the switches and I can test it out on my network. I’ve updated a lot of them and have only had an occasional failure. Then I update again and it works. I will PM you and @Kaleb_Inovelli can create a label so it can be sent to me.
I just wanted to reply to this thread that it was discovered that @vladimir.korobov had the VZM31-SN which the early 2022 version can have issues updating. There should not be any issues updating the VZM32-SN with fw 1.01 and beyond. Just didn’t want anyone to be worried if they are looking at this thread.
I’d be interested in testing out the new firmware as well. I have about 20 of these switches and the occupancy state seems to get “stuck” on the device itself. Air gapping fixes the issue so I assume it’s probably a memory leak or something similar, but if the new firmware addresses anything like this I’d love to give it a shot!
I can confirm that this issue seems to be present on all mmwave blue switches and is even present in a ZHA custom quirk i am building to allow people with zha to use my addon along with z2m users.
The values are negated and the min/max positions are swapped, which is consistent with the firmware multiplying both values by -1 (turning 60 into -60 and 160 into -160, then reordering so that -160 < -60). Expected result:xMin=60, xMax=160
Chiming in that I’m seeing this exact behavior on all 18 of my VZM32-SN switches on v1.00.
Running HA 2026.4.2 and Z2M 2.9.2-1. What is interesting is that if looking at a switch’s Activity, I’m seeing two events when setting the Stay Area values and hitting “Apply” in Z2M, with the 2nd event being immediately after with the flipped values for width_min and width_max.
Would love to test the new firmware is this is fixed as it’s a pain to manage the switches as I’m trying to tweak the areas post-install.