GE 45612 switch not reporting on/off status

I wired a 4 way light circuit that had 4 switches. I bought the GE45613 kit that includes one 45612 main switch and one 45610 aux switch. I used two Jasco 45710 for the other aux switches. The circuit works fine in that all four switches will turn on/off the lights. I can also turn it on and off with my Veralite controller.

If I turn on/off the lights by tapping the 45612 main switch, the controller detects the on/off status fine. But if I turn on/off the lights using any of the aux switches (the 45610 or 45710), the control does not detect the on/off state.

How do I get my controller to detect on/off state of the lights regardless of what switch I used to turn them on/off?

Thanks, Todd

The issue you are experiencing is that the GE/Jasco switches do not support a feature called Instant Status, that is needed to immediately update Vera about state changes.

The 45612 issues a Network Information Frame(NIF), that is part of the include exclude process, whenever the 45612 button is pressed. Vera implements a “cheat” that interprets the NIF as a status update to fake teh Instant Status capability. Note that NIFs are not routed through intermediate nodes, so this only works when Vera is within direct communication range of the 45612.

Your specific problem is that the 45612 only broadcasts the NIF when its button is pressed. It does not broadcast a NIF when the Aux(45610) buttons are pressed. The only way to resolve your issue is to replace the 45612 with a switch that supports Instant Status. See Leviton VRI06.

Zwaver is right on that aux switch. If that is used vera doesn’t know until it polls it.

There has been post on here os ways to try and help releave this problem a bit. Before you run a scene or somthing you can have vera manually poll it to check its current status.

But thats only for certian situations not just to say update the icon on your app.

Thanks all for the quick response :slight_smile: I guess I’ll have to replace the 45612 switch with the Leviton VRI06. Thanks again!

I’ll look for that post to see if I can get the Vera to poll its state before I replace the switch.

Also look at the leviton vrmx1, it requires a neutral but will dim led’s beter then the vri06 which does not require a neutral. your aux switches will need to be replaced as well if you go the leviton route

Thanks. I found the following post. I see GE/Jasco must not have wanted to pay the licensing fee for reporting instant status to the controller. Sounds like from this post that the controller will eventually get around to polling the switch state but its just not instant.

[quote=“JamesDVB, post:5, topic:178912”]This has been answered countless times in this forum.

Lutron owns a patent relating to instant status, which is the ability for switches to notify the controller when the switch is manually flipped. Some companies like Cooper and Leviton license the patent so their products can use instant status.

The GE/Jasco switches don’t support instant status, and therefore do not report their status change to the controller when the switches are manually flipped.

Therefore, the controller periodically polls the switches to find out if they’ve been flipped. Depending on how many switches you have, this could range from minutes to hours before it cycles through and polls every switch.

There is a bit of a workaround that Vera controllers use with GE/Jasco switches, which helps the controller know sooner in some scenarios. Basically, the switch sends out a broadcast message when it’s flipped, and if the controller sees that message, it knows something happened, and polls the switch immediately, and sees the status has changed. However that only works when the switch is communicating directly with the controller, and isn’t routed through other devices on the z-wave mesh network, and it’s not always reliable.

You can’t expect your controller to be notified of status changes for switches that do not support instant status, such as the GE/Jasco switches. When it does happen to work, it’s because of the work-around mentioned above, but the behavior you are seeing is expected.[/quote]