If the device does not support instant status, you will get better UI performance doing the polling. At least that has been my experience. I have a number of GE 12724 Dimmers (12730 Fan) and polling is required if you want the UI to update timely. My GE 14294 Dimmers do not need it.
Can confirm. Since I disabled all the options on z-wave last night my bathroom dimmers don’t respond well in the UI. And now that I think about it, this is what set me down the path of using the options. I still have all options off and will try to observe how things work over the next few days.
The usb extension is a good idea. Is 12’ a limitation of how z-wave will work or is it just the longest cable you have? If the later I’ll buy the longest shielded usb cable I can find!
EDIT: I found a 16’ one on amazon. But thinking on it, I’m not even sure where I will put the other end. Server is so far back. And while I can run ethernet most spots in the house I don’t have anywhere to put this beast.
The spec for USB 2.0 limits non-powered extension cables to 5 meters (16 feet). If you have powered hubs, it’s different. Also the longer the cable, if it doesn’t have adequate shielding, the more interference it is susceptible to and can cause communication problems. I had a 12’ shielded (about the thickness of standard coax RG-6 cable) laying around, so that’s what I went with.
Yep, read the exception note I had posted right after the part you quoted from my original post… dimmers act differently. I’m playing around with the refresh_value: True setting, but they may still need polling to display properly. Also in another post I confirmed the add-on switches in a 3-way configuration do not force the master switch to update its state regardless if the master is a switch or dimmer.
Ok so I want to clarify some things. I was wrong. I made some incorrect conclusions based on some testing I did and the results I saw, but I failed to dig further and confirm what was actually happening.
GE devices DO NOT do instant status updates. They appear to do instant status by using a workaround in the Z Wave protocol. As can be found in many other posts about Z Wave devices online, instant status is a patent (though the name is not patented, just the method) previously held by Lutron (US Patent #5,905,442). This patent is said to have expired, though I cannot confirm, but others have. GE decided not to license this patent from Lutron in their Z Wave and possibly others. The GE/Jasco 45XXX/12XXX series devices use a feature of the Z Wave protocol to get around this and make it look like it can do instant status updates. The new GE/Jasco 14XXX series devices still do not have instant status updates, but they support OTA firmware updates, so this may come in a future update.
What GE does to get around the instant status updates is send a hail command to the network. This is a broadcast message the controller responds to. From what I have read and understand, the controller is the only device that responds to these broadcast messages. So the device sending a hail must have the controller (node 1) as it’s primary or first neighbor. If the device has a routing slave between it and the controller, the routing slave will not re-broadcast or route broadcast messages. When the controller receives a hail command or broadcast message, it tells the controller to query the node that sent the message. The device responds to the query and tells the controller its new status.
What I was experiencing was some devices no longer had node 1 (the controller) as its primary neighbor. Those nodes were the ones not updating their status on physical interaction. I had to do multiple network heals and in OZWCP force an update of the return routes for specific nodes.
So to re-cap, GE/Jasco (and others that didn’t license the Lutron patent) can use hail commands on physical state change to provide pseudo instant status updates. However, if you have any devices that are far enough away from the main controller, you will want to setup polling for these devices.
To support my further research, here’s the two articles I read.
Comment from discussion GE instant status.
How to Fix GE Z-Wave Switches Not Updating in the Home Assistant UI
Also here is a snippet of my OZW log that shows physically interacting with a switch. This shows the hail command, the query from the controller, followed by the response from the device with its new status.
switch on:
2017-12-03 20:59:36.682 Detail, Node007, Received: 0x01, 0x11, 0x00, 0x49, 0x84, 0x07, 0x0b, 0x04, 0x10, 0x01, 0x25, 0x27, 0x75, 0x73, 0x70, 0x86, 0x72, 0x77, 0xcd
2017-12-03 20:59:36.682 Detail,
2017-12-03 20:59:36.682 Info, Node007, UPDATE_STATE_NODE_INFO_RECEIVED from node 7
2017-12-03 20:59:36.682 Detail, Node007, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Dynamic live=1
2017-12-03 20:59:36.682 Detail, Node007, QueryStage_Dynamic
2017-12-03 20:59:36.683 Detail, Node007, Queuing (Send) SwitchBinaryCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x25, 0x02, 0x25, 0x3b, 0xd9
2017-12-03 20:59:36.683 Detail, Node007, Queuing (Query) Query Stage Complete (Dynamic)
2017-12-03 20:59:36.683 Detail,
2017-12-03 20:59:36.683 Info, Node007, Sending (Send) message (Callback ID=0x3b, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x25, 0x02, 0x25, 0x3b, 0xd9
2017-12-03 20:59:36.690 Detail, Node007, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-12-03 20:59:36.690 Detail, Node007, ZW_SEND_DATA delivered to Z-Wave stack
2017-12-03 20:59:36.707 Detail, Node007, Received: 0x01, 0x07, 0x00, 0x13, 0x3b, 0x00, 0x00, 0x02, 0xd2
2017-12-03 20:59:36.707 Detail, Node007, ZW_SEND_DATA Request with callback ID 0x3b received (expected 0x3b)
2017-12-03 20:59:36.707 Info, Node007, Request RTT 24 Average Request RTT 25
2017-12-03 20:59:36.707 Detail, Expected callbackId was received
2017-12-03 20:59:36.717 Detail, Node007, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x07, 0x03, 0x25, 0x03, 0xff, 0x2f
2017-12-03 20:59:36.717 Detail,
2017-12-03 20:59:36.717 Info, Node007, Response RTT 34 Average Response RTT 35
2017-12-03 20:59:36.717 Info, Node007, Received SwitchBinary report from node 7: level=On
2017-12-03 20:59:36.717 Detail, Node007, Refreshed Value: old value=false, new value=true, type=bool
2017-12-03 20:59:36.718 Detail, Node007, Changes to this value are not verified
2017-12-03 20:59:36.718 Detail, Node007, Expected reply and command class was received
2017-12-03 20:59:36.718 Detail, Node007, Message transaction complete
2017-12-03 20:59:36.718 Detail,
2017-12-03 20:59:36.718 Detail, Node007, Removing current message
2017-12-03 20:59:36.718 Detail, Node007, Notification: ValueChanged
2017-12-03 20:59:36.718 Info, Notification: Value Changed Home 0xdd0757f3 Node 7 Genre user Class SWITCH BINARY Instance 1 Index 0 Type bool
2017-12-03 20:59:36.718 Detail, Node007, Query Stage Complete (Dynamic)
2017-12-03 20:59:36.718 Detail, Node007, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Configuration live=1
2017-12-03 20:59:36.718 Detail, Node007, QueryStage_Configuration
2017-12-03 20:59:36.718 Detail, Node007, QueryStage_Complete
2017-12-03 20:59:36.718 Warning, CheckCompletedNodeQueries m_allNodesQueried=0 m_awakeNodesQueried=1
2017-12-03 20:59:36.718 Warning, CheckCompletedNodeQueries all=0, deadFound=0 sleepingOnly=1
2017-12-03 20:59:36.718 Detail, Node007, Notification: NodeQueriesComplete
2017-12-03 20:59:36.718 Info, Notification: Node 7 Queries Complete
switch off:
2017-12-03 20:59:55.720 Detail, Node007, Received: 0x01, 0x11, 0x00, 0x49, 0x84, 0x07, 0x0b, 0x04, 0x10, 0x01, 0x25, 0x27, 0x75, 0x73, 0x70, 0x86, 0x72, 0x77, 0xcd
2017-12-03 20:59:55.720 Detail,
2017-12-03 20:59:55.720 Info, Node007, UPDATE_STATE_NODE_INFO_RECEIVED from node 7
2017-12-03 20:59:55.720 Detail, Node007, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Dynamic live=1
2017-12-03 20:59:55.720 Detail, Node007, QueryStage_Dynamic
2017-12-03 20:59:55.720 Detail, Node007, Queuing (Send) SwitchBinaryCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x25, 0x02, 0x25, 0x3c, 0xde
2017-12-03 20:59:55.720 Detail, Node007, Queuing (Query) Query Stage Complete (Dynamic)
2017-12-03 20:59:55.721 Detail,
2017-12-03 20:59:55.721 Info, Node007, Sending (Send) message (Callback ID=0x3c, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x25, 0x02, 0x25, 0x3c, 0xde
2017-12-03 20:59:55.728 Detail, Node007, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-12-03 20:59:55.728 Detail, Node007, ZW_SEND_DATA delivered to Z-Wave stack
2017-12-03 20:59:55.745 Detail, Node007, Received: 0x01, 0x07, 0x00, 0x13, 0x3c, 0x00, 0x00, 0x03, 0xd4
2017-12-03 20:59:55.745 Detail, Node007, ZW_SEND_DATA Request with callback ID 0x3c received (expected 0x3c)
2017-12-03 20:59:55.745 Info, Node007, Request RTT 24 Average Request RTT 24
2017-12-03 20:59:55.745 Detail, Expected callbackId was received
2017-12-03 20:59:55.756 Detail, Node007, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x07, 0x03, 0x25, 0x03, 0x00, 0xd0
2017-12-03 20:59:55.756 Detail,
2017-12-03 20:59:55.756 Info, Node007, Response RTT 35 Average Response RTT 35
2017-12-03 20:59:55.756 Info, Node007, Received SwitchBinary report from node 7: level=Off
2017-12-03 20:59:55.756 Detail, Node007, Refreshed Value: old value=true, new value=false, type=bool
2017-12-03 20:59:55.756 Detail, Node007, Changes to this value are not verified
2017-12-03 20:59:55.756 Detail, Node007, Expected reply and command class was received
2017-12-03 20:59:55.756 Detail, Node007, Message transaction complete
2017-12-03 20:59:55.756 Detail,
2017-12-03 20:59:55.756 Detail, Node007, Removing current message
2017-12-03 20:59:55.756 Detail, Node007, Notification: ValueChanged
2017-12-03 20:59:55.756 Info, Notification: Value Changed Home 0xdd0757f3 Node 7 Genre user Class SWITCH BINARY Instance 1 Index 0 Type bool
2017-12-03 20:59:55.756 Detail, Node007, Query Stage Complete (Dynamic)
2017-12-03 20:59:55.756 Detail, Node007, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Configuration live=1
2017-12-03 20:59:55.756 Detail, Node007, QueryStage_Configuration
2017-12-03 20:59:55.756 Detail, Node007, QueryStage_Complete
2017-12-03 20:59:55.756 Warning, CheckCompletedNodeQueries m_allNodesQueried=0 m_awakeNodesQueried=1
2017-12-03 20:59:55.757 Warning, CheckCompletedNodeQueries all=0, deadFound=0 sleepingOnly=1
2017-12-03 20:59:55.757 Detail, Node007, Notification: NodeQueriesComplete
2017-12-03 20:59:55.757 Info, Notification: Node 7 Queries Complete
I apologize if I led anyone astray in my posts. I apologize for the incomplete research and incorrect conclusions I made.
EDIT: For comparison, here is a snippet of the OZW log showing toggling the switch from a z wave command or HA frontend.
switch on:
2017-12-04 00:05:25.991 Info, Node006, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - True
2017-12-04 00:05:25.991 Info, Node006, SwitchBinary::Set - Setting node 6 to On
2017-12-04 00:05:25.992 Detail, Node006, Queuing (Send) SwitchBinaryCmd_Set (Node=6): 0x01, 0x0a, 0x00, 0x13, 0x06, 0x03, 0x25, 0x01, 0xff, 0x25, 0x57, 0x4a
2017-12-04 00:05:25.992 Detail, Node006, Queuing (Send) SwitchBinaryCmd_Get (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 0x02, 0x25, 0x02, 0x25, 0x58, 0xbb
2017-12-04 00:05:25.992 Detail,
2017-12-04 00:05:25.992 Info, Node006, Sending (Send) message (Callback ID=0x57, Expected Reply=0x13) - SwitchBinaryCmd_Set (Node=6): 0x01, 0x0a, 0x00, 0x13, 0x06, 0x03, 0x25, 0x01, 0xff, 0x25, 0x57, 0x4a
2017-12-04 00:05:25.999 Detail, Node006, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-12-04 00:05:25.999 Detail, Node006, ZW_SEND_DATA delivered to Z-Wave stack
2017-12-04 00:05:26.053 Detail, Node006, Received: 0x01, 0x07, 0x00, 0x13, 0x57, 0x00, 0x00, 0x06, 0xba
2017-12-04 00:05:26.053 Detail, Node006, ZW_SEND_DATA Request with callback ID 0x57 received (expected 0x57)
2017-12-04 00:05:26.054 Info, Node006, Request RTT 62 Average Request RTT 69
2017-12-04 00:05:26.054 Detail, Expected callbackId was received
2017-12-04 00:05:26.054 Detail, Expected reply was received
2017-12-04 00:05:26.054 Detail, Message transaction complete
2017-12-04 00:05:26.054 Detail,
2017-12-04 00:05:26.054 Detail, Node006, Removing current message
2017-12-04 00:05:26.054 Detail,
2017-12-04 00:05:26.054 Info, Node006, Sending (Send) message (Callback ID=0x58, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 0x02, 0x25, 0x02, 0x25, 0x58, 0xbb
2017-12-04 00:05:26.062 Detail, Node006, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-12-04 00:05:26.062 Detail, Node006, ZW_SEND_DATA delivered to Z-Wave stack
2017-12-04 00:05:26.119 Detail, Node006, Received: 0x01, 0x07, 0x00, 0x13, 0x58, 0x00, 0x00, 0x06, 0xb5
2017-12-04 00:05:26.119 Detail, Node006, ZW_SEND_DATA Request with callback ID 0x58 received (expected 0x58)
2017-12-04 00:05:26.119 Info, Node006, Request RTT 64 Average Request RTT 66
2017-12-04 00:05:26.119 Detail, Expected callbackId was received
2017-12-04 00:05:26.175 Detail, Node006, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x06, 0x03, 0x25, 0x03, 0xff, 0x2e
2017-12-04 00:05:26.175 Detail,
2017-12-04 00:05:26.175 Info, Node006, Response RTT 121 Average Response RTT 127
2017-12-04 00:05:26.175 Info, Node006, Received SwitchBinary report from node 6: level=On
2017-12-04 00:05:26.175 Detail, Node006, Refreshed Value: old value=false, new value=true, type=bool
2017-12-04 00:05:26.175 Detail, Node006, Changes to this value are not verified
2017-12-04 00:05:26.175 Detail, Node006, Expected reply and command class was received
2017-12-04 00:05:26.175 Detail, Node006, Message transaction complete
2017-12-04 00:05:26.176 Detail,
2017-12-04 00:05:26.176 Detail, Node006, Removing current message
2017-12-04 00:05:26.176 Detail, Node006, Notification: ValueChanged
2017-12-04 00:05:26.176 Info, Notification: Value Changed Home 0xdd0757f3 Node 6 Genre user Class SWITCH BINARY Instance 1 Index 0 Type bool
switch off:
2017-12-04 00:06:09.841 Info, Node006, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - False
2017-12-04 00:06:09.842 Info, Node006, SwitchBinary::Set - Setting node 6 to Off
2017-12-04 00:06:09.842 Detail, Node006, Queuing (Send) SwitchBinaryCmd_Set (Node=6): 0x01, 0x0a, 0x00, 0x13, 0x06, 0x03, 0x25, 0x01, 0x00, 0x25, 0x59, 0xbb
2017-12-04 00:06:09.842 Detail, Node006, Queuing (Send) SwitchBinaryCmd_Get (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 0x02, 0x25, 0x02, 0x25, 0x5a, 0xb9
2017-12-04 00:06:09.842 Detail,
2017-12-04 00:06:09.842 Info, Node006, Sending (Send) message (Callback ID=0x59, Expected Reply=0x13) - SwitchBinaryCmd_Set (Node=6): 0x01, 0x0a, 0x00, 0x13, 0x06, 0x03, 0x25, 0x01, 0x00, 0x25, 0x59, 0xbb
2017-12-04 00:06:10.349 Warning, WARNING: 500ms passed without reading the rest of the frame...aborting frame read
2017-12-04 00:06:10.350 Warning, WARNING: Out of frame flow! (0x13). Sending NAK.
2017-12-04 00:06:10.350 Detail, Node006, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-12-04 00:06:10.350 Detail, Node006, ZW_SEND_DATA delivered to Z-Wave stack
2017-12-04 00:06:10.351 Detail, Node006, Received: 0x01, 0x07, 0x00, 0x13, 0x59, 0x00, 0x00, 0x06, 0xb4
2017-12-04 00:06:10.351 Detail, Node006, ZW_SEND_DATA Request with callback ID 0x59 received (expected 0x59)
2017-12-04 00:06:10.351 Info, Node006, Request RTT 510 Average Request RTT 288
2017-12-04 00:06:10.351 Detail, Expected callbackId was received
2017-12-04 00:06:10.352 Detail, Expected reply was received
2017-12-04 00:06:10.352 Detail, Message transaction complete
2017-12-04 00:06:10.352 Detail,
2017-12-04 00:06:10.352 Detail, Node006, Removing current message
2017-12-04 00:06:10.352 Detail,
2017-12-04 00:06:10.352 Info, Node006, Sending (Send) message (Callback ID=0x5a, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 0x02, 0x25, 0x02, 0x25, 0x5a, 0xb9
2017-12-04 00:06:10.359 Detail, Node006, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-12-04 00:06:10.359 Detail, Node006, ZW_SEND_DATA delivered to Z-Wave stack
2017-12-04 00:06:10.415 Detail, Node006, Received: 0x01, 0x07, 0x00, 0x13, 0x5a, 0x00, 0x00, 0x06, 0xb7
2017-12-04 00:06:10.415 Detail, Node006, ZW_SEND_DATA Request with callback ID 0x5a received (expected 0x5a)
2017-12-04 00:06:10.415 Info, Node006, Request RTT 62 Average Request RTT 175
2017-12-04 00:06:10.415 Detail, Expected callbackId was received
2017-12-04 00:06:10.472 Detail, Node006, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x06, 0x03, 0x25, 0x03, 0x00, 0xd1
2017-12-04 00:06:10.472 Detail,
2017-12-04 00:06:10.509 Info, Node006, Response RTT 157 Average Response RTT 142
2017-12-04 00:06:10.509 Info, Node006, Received SwitchBinary report from node 6: level=Off
2017-12-04 00:06:10.509 Detail, Node006, Refreshed Value: old value=true, new value=false, type=bool
2017-12-04 00:06:10.509 Detail, Node006, Changes to this value are not verified
2017-12-04 00:06:10.510 Detail, Node006, Expected reply and command class was received
2017-12-04 00:06:10.510 Detail, Node006, Message transaction complete
2017-12-04 00:06:10.510 Detail,
2017-12-04 00:06:10.510 Detail, Node006, Removing current message
2017-12-04 00:06:10.510 Detail, Node006, Notification: ValueChanged
2017-12-04 00:06:10.510 Info, Notification: Value Changed Home 0xdd0757f3 Node 6 Genre user Class SWITCH BINARY Instance 1 Index 0 Type bool
7 Likes
Thanks a bunch - this is good info. I know that many switches and dimmers from the past few years do this.
It seems the latest switches/dimmers (typically Zwave plus) do now do status updates.
Is it possible to assign the neighbors manually?
Nope, it is discovered by the zwave protocol.
The closest I got to manually assigning neighbors was in the OZWCP you can assign return routes. I don’t think it sticks though as once I shut down the docker for OZWCP and started up HA again, I have one switch that doesn’t have node 1 as its primary neighbor. It’s probably my third most used switch out of 11 and the 6th closest node to the controller. But for that switch, the signal has to pass through 2 walls, a floor with HVAC, electrical, and plumbing in it and a stove (if following line of sight), so it makes sense why it found a better path for communication.
What’s interesting is some of my closest nodes are not registering the controller as first neighbor.
Do you know of a tool that will help visualize the mesh/neighbors? Would be cool to see an SVG output or something similar.
I’ve never gotten the topology option in OZWCP to work, but yes someone did make a network visualizer for HA. I’ve seen it floating around the forums. Might check the share your projects section.
I think you’re right. With the release of the 500 series z wave chips (Z Wave+) most new devices are doing instant status updates.
I’ve seen one showing relationships with entities and automations, scripts, etc but not zwave. I’ll take a look.
Do a search on the forums for the zwave mesh mapper - does exactly what you want
This is crucial information if we can get to the bottom of it.
I initially used the GE switches, not being familiar with the status issue. This caused lots of headaches and frustration, and I’m pretty disappointed in the result after the cost and work involved.
Once I understood the issue, I started springing for $50 Homeseer switches. These work brilliantly, but I’ve got at least 10 more switches to go, and the cost adds up.
If I buy the newer GE switches with zwave+, will instant status now work as well as it does on the Homeseer switches? Can anyone verify?
You can get a table format connectivity matrix by looking at the zwave log after running a network heal.
Maybe not as entertaining as a graphical view, but it has all the same information.
I do not have the new 14XXX series GE devices. However, one of the links I posted (and even in my post I call it out) says even the new series does not have instant status updates, but it supports OTA firmware updating, so it’s possible they may support it in a future update.
The new Leviton that are ZWP and the new GE plug in modules (14XXX) also have issues. They need to be polled; as well as if a dimmer the refresh option turned on.
The problem is with dimmers the hail functionality doesn’t work well as a work around. One way to fix this is to set the dim fade in/out on the switch so it doesn’t hail so many times (per step). A slow fade in/out means a hail for each step and this takes a lot of network bandwidth (remember Zwave is a SLOW network).
You can actually cause some Zwave network challenges by just having a chatty dimmer and turn it on/off repeatedly. This is because hail is prioritized over other traffic. For network geeks this is in essence a broadcast storm on a slow radio network thats set to reroute and retry for reliability 
The switches that work 100% reliably for me are HomeSeer. There is also a HomeSeer knock-off that works; by ZWD on Amazon. From what I can gather these are built in same factory but some different firmware branding. They used to also be called Dragon Tech or something. About $15 cheaper a switch. I have some of these and they are identical; except my OCD tells me they feel a bit cheaper to justify buying the more expensive brand.
Hope this helps.
2 Likes
Hi, I have put in a feature request to add optimistic mode to the zwave component. This should help the behavior we are seeing and lessen the need to add polling for each GE devices, at least in the UI where the switch flips back to the previous state.