Jasco/GE In-wall ZigBee switch delay

I’ve been putting in a bunch of in-wall switches. They’ve all had a bit of a delay to them, which I decided I could live with (it does confuse the kids though). However, last night I installed my first add-on switch and the add-on switches have no delays at all. Performance was just as good as the original pole switches.

Anyone know why the add-on switches perform better when they communicate only with the primary switch anyways? If there a way to fix the lag on the primary since it’s obviously not a hardware limitation.

Are they on/off switches or dimmers? The dimmers ramp up, so maybe the aux switch bypasses the ramping?

They’re on/off switches. Do people with the ZWave on/off switches notice any delay?

I have the z-wave version and there is roughly a 500ms delay (due to the physical relay in the switch). The add-on switch doesn’t do anything but send a command back to the base switch, the delay should be exactly the same (though you won’t hear the click which could make it seem faster).

CThere are many different factors that can add or remove lag from a system, whether it is zigbee or Z wave.

First, what is the brand and model of the switches? If these are the GE or Leviton that use an actual physical traveler wire between the auxiliary switch and the master, then the reason why you’re seeing no lag is because it’s not using the network at all. It’s just an electrical pulse from the auxiliary to the master over the traveler wire.

In a mesh network, whether it is zigbee or Z wave, each individual device keeps its own little neighbor table which shows the neighbors that are physically closest to it. This neighbor table is built at the time the device joined the network.

If, as many people do, you initially paired the device by bringing itclose to the hub and then you either move the device to its final location or you took the hub back to its usual location, that’s fine. That’s called “bench pairing.” But it means that the neighbor table will be incorrect, because it’s based on the neighbors at the time of the original pairing.

Another issue that can arise is if you add additional devices that are repeaters to your network. The new devices will have up-to-date neighbor tables. But the devices around them don’t even know that that new device exists. They are still working off of their old neighbor tables.

So how do you get the devices to update their neighbor tables? For Zigbee, it’s easy. Just take the hub off of power for at least 15 minutes. (Unplugged and remove any batteries from it.) You don’t have to do anything with the other devices. Eventually the other devices realize that the hub is missing, and they go into panic mode. Now when the hub comes back on power everybody will update their individual neighbor tables. It can take a little while for this to get done for every device, so you may not see any improvement until the next day, but this should improve the overall efficiency of your network.

( there’s a different procedure for zwave devices, with the same general idea.)

Whatever you add new devices to your network, or move devices from one physical location to another, you should do the procedure to get the neighbor tables updated.

This alone can greatly reduce the lag in a network. :sunglasses:

@blebson Trust me, it’s instantaneous with the physical add-on switch. I’ll try to take video later.

@JDRoberts The GE with the physical traveller wire. Even when I had one switch, there would still be that little bit of lag.

Here’s the video. The switch with the wall covering is a primary switch. The switch with no wall plate is an add-on. Notice the speed difference. https://goo.gl/photos/2ovAGAtwmTiuYqco6

When did you last heal the network (rebuild the neighbor tables)?

Interesting. I just tried a couple of my GE’s (all zwave) that use an add-on switch, and sure enough mine do what yours do in the videos. The main switch is just a little slower to turn on/off the lights than when using the add-on switch. Super odd, and in the last 2 years of having these I have never noticed. I can click on/off the lights in fast succession with the add-on, but the main is just a hair slower so that I couldn’t do as many on/off’s in the same time frame I could with the add-on.

I have no idea how to explain why, and quite honestly, not a big enough deal for me. We’ve been using these for so long that it wasn’t anything noticable for us.

@JDRoberts, it’s definitely not a mesh thing. It’s all physical at the switch. When using the main switch and turning on/off you can feel/hear the click of the button, then hear the click of the relay, and then the light goes on. Using the add-on, it goes through the same sequence except it’s a split second faster. Like I said, it’s odd.

Interesting. I still think the radio may be being bypassed when the traveler wire is used. That could make using the aux faster.

I don’t have these switches, but I seem to remember people saying status wasn’t updated as quickly (or at all?) If the aux was used instead of the master. If the master sends association commands before it closes the circuit, but doesn’t for the aux, that might account for the delay.

Hi @JDRoberts, I think you’re right because the status was almost instant when using the main switch vs a long delay using the add-on. I just did that to the same switch I tested above.

This does seem to be the case. I did reach out to GE/Jasco support. Hopefully they know some way to reverse the order of operations.

Any random thoughts why they’d do this? I mean, it’s not like they would wait to process a response, and even if they did, the response wouldn’t get received if it was occuring from the aux switch.

Maybe it has something to do with double-tap support? If you hit the switch twice rapidly it won’t turn on the switch, leaving me to believe there may be some built in delay to allow for a ‘double-tap’ type interaction.

The master may send out commands before increasing the current in order to avoid the popcorn effect where multiple lights are supposed to come on at the same time but instead they come on with visible Separation. Many people find that really annoying, and quite a few automated lighting systems use a slight delay on the master in order to allow the followers to catch up and reduce the overall popcorn effect. Since an auxiliary that uses a physical traveler wire in most lighting installation is only supposed to turn on that specific light, they wouldn’t have to pause.

But this is an area where different manufacturers have different delivery philosophies. So it could be set up either way. That was just my first thought based on what you were saying.

And I know I say this a lot, but I am going to recommend again doing the network heal, not because I think it will change the relative operation of the master and the aux that you are seeing, but because it should make the master as fast as it can be. It’s just improving the overall efficiency of the network. :sunglasses:

True, but then double tap is broken on the add-on switches.

Did you ever find a solution? I have the exact same problem. Instantaneous reaction to the add-on switch, and 500ms delay on the primary zigbee switch.

If you are using them as switches there is should be no delay.

If you are using them as scene controllers with hold, double toggle, etc. options there will be a delay. The switch is waiting to see how many toggles you are going to make.