you really need to capture this at the zigbee frame (sniffer) level as some of the security transactions are handled by the chip directly so the hub doesn't see them.
@mike.maxwell something that our engineer is seeing: "At the beginning, VZM35 successfully joined the C8 network, but when vzm35 applied for the second Key, C8 did not reply"
We can provide the full log if needed. This lines up with what some are seeing where the switch works initially but then stops after a little while. The strange thing is that there are a lot of C8 users that do not have this problem . . . only some. Mine it is able to pair just fine.
2 Likes
email me the complete capture along with the transport key.
1 Like
I will have to look for it tomorrow
No the switch does not
You mean the first three hexadecimal digits of the ZIgbee ID are different?
That's correct mine 048727. I just tried adding a 2-1 switch and same result looks like it is on the controller side.
How did you pair the switch - in place or close to the HE hub?
C-8 or C-7?
both
Any updates on this? I randomly happened across this thread via Google search, and I get a very similar 'red lights flash and then the switch becomes uncontrollable' after initially being controllable for roughly 5 seconds. Believe it's 4 red light flashes. Interestingly enough, I'm using a Tubes ZB coordinator directly into Z2M...no HE involved.
Oddly enough, every single one of my 10 units did this same thing, but through random messing around during setup I noticed that if I pulled the air gap switch immediately after Z2M noted that it had successfully paired & interviewed, waited a few seconds, then restored power, it would typically work. Had a couple units I had to do this process twice on, but other than that they've all been working for about a month now...except this one which seems to be re-experiencing this issue the last few days or so.
EDIT: so I (force) removed the switch in question from my Z2M, hard reset it, then let it rejoin and followed my "air gap the moment it successfully sets up" procedure and now it's back to working...at least for the moment.
It is being worked. As to the depth and details they do not know yet what is causing this.
If possible to get a packet capture during the pairing that would be helpful. The only thing the engineer has discovered is that the switch is requesting a key, the hub doesn't respond, so the switch leaves the network.
We are still trying to figure out what is going on, but another capture with another hub might show something useful.
1 Like
Hmmmmm ok. Mine hasn't acted back up again since hard resetting it the other day. I'll look around the house and see if I have a spare 2531 stick laying around. I might have one in a drawer but I just can't recall, lol.
As @kkossev observed, this situation looks similar to the newer IKEA remotes failing to pair if not kept very close (2in/5cm) to the hub - to force them to choose the hub as their Zigbee parent. See my findings here:
After a successful pairing, the IKEA remotes work fine if they later migrate to another Zigbee parent (e.g.: are used far away from the hub).
1 Like
Interesting, I'll forward the info to the engineer. We are sending this to a silabs contact to help investigate it. The workaround mentioned by @d.ohlin is working though. @sky320 has been able to use it. Essentially you:
Pair the device like normal.
Right after the led flashes green (showing a successful pairing), you pull the airgap.
After waiting 15 or so seconds you push the airgap back in.
What we think is happening is that the step that would usually request a key and not get an answer is being skipped by pulling the airgap. After that unsuccessful key request is usually where the device would leave the network. Upon booting back up, the device is requesting a key and the hub is responding this time so it has fully joined.
3 Likes
Very good! I always love the "dumb luck" strategy by which I discovered this method LOL
4 Likes
