Jump to content

How to see ISY nearest neighbors


Recommended Posts

When you look at network details for particular node and very first one listed is " 1 - [This ISY] ", it means that it has direct connection to ISY without a need to go through another device.

Link to comment
Share on other sites

8 hours ago, tibbar said:

When you look at network details for particular node and very first one listed is " 1 - [This ISY] ", it means that it has direct connection to ISY without a need to go through another device.

When I right-click on device then  "Zwave" - "Show information in event viewer" - "Network details",  I get message in event viewer that " Installed Zwave firmware does not support neighbor information " ..........

Link to comment
Share on other sites

Thus, again, I'd like to know how to ask the "ISY ITSELF" what it sees as 1-hop neighbors...

It would be great too, if the ISY would build a map/grid of the Z-wave network, by polling all of the devices, and build...
@michel could this be a future item?


Link to comment
Share on other sites

Kinda sorta, johnstonf -- the zwave thing for the ISY isn't much different than the Insteon PLM in that the actual details of the protocol are handled outboard.  For Insteon, it's done by the PLM, for z-wave, it's done by the so-called "dongle" (it's really a board).  The z-wave device looks like a serial modem to the ISY, and protocol details such as neighbors and heals are all done by that device.  So I think what Michel means is to see if there's a way to extract information about the immediate neighbors from the particular z-wave chipset and software on that board.

There's a huge advantage to hiding the details like this - but it also means that like Insteon, UDI is limited in what they can do by the z-wave mfgr's firmware.

Link to comment
Share on other sites

During the network heal (as well as zwaves self healing ability), it's the individual switches that talk to one another and figure out the best path to take.

This is why you should run a heal every time you swap or move a device. While your controller knows of the devices existence, none of your devices know of each other and their relation to one another. 

This information is generally stored within the devices themselves and may not be available to be pulled from the devices by the isy. 

Unfortunately, it does mean you have to figure out the best placement of devices to achieve a full mesh network. Once you have enough devices for communication, the system itself will do the rest for you. 

Link to comment
Share on other sites

Pretty good article...
I sure like Insteon better than zwave by a hundred times! Dualband, everywhere automatically, add device, boom/better


paste of some of it...
You have a Smart Home using Z-Wave as a wireless technology for all these Internet of Things (IoT) devices to communicate with each other. But maybe things are not working quite as well as you expect. You press a button on your phone and 1… 2… 3… and then finally a light comes on or maybe it doesn’t come on at all! Another common problem is when a battery powered sensor was updating the temperature last week and this week it just doesn’t seem to be sending updates anymore or at best sporadically. As a Z-Wave expert I’ve built and rebuilt hundreds of Z-Wave networks and have come up with a few habits to make Z-Wave networks more reliable.

1. Minimize Polling
This is probably THE number one mistake new users of Z-Wave make. They figure Z-Wave is a high speed network so they can just poll a light switch every 3 seconds and then react to any change in the switch. Z-Wave and most other wireless networks work best when the network is highly available. If the network is busy, every device that needs to send a message has to wait its turn and then compete (and often collide) with all that polling traffic. Collisions slow everything down just like rubber-necking on the highway.

Polling used to be the only way to get around a patent that fortunately expired in February 2016. The patent forced many light switch manufacturers to not send a message when you flipped the switch. Several manufacturers found ways to get around this or they licensed the patent. But now that the patent has expired, you can get light switches that do send a report immediately when their state has changed.

So the primary way to minimize polling is to replace the few devices in your Smart Home that trigger an event (or SmartApp or Magic or whatever your hub calls it) with one that will instantly send an update. If you have some older switches but they’re not that important to instantly know their state has changed, you can still poll them but no more than once every few minutes. Remember that if you have 60 Z-Wave devices and you poll each one once/min then you are polling once/second and the network is hammered! So only poll a couple of nodes!

2. Have enough devices to create a mesh
I can’t tell you how many people I’ve worked with that had a door lock and a hub and nothing else, maybe a battery powered thermostat. And they wondered why the connection to the lock was unreliable when the hub was at the far end of the building! Z-Wave relies on Always-On (110VAC powered) nodes to build a “mesh” network. The mesh is the key to Z-Wave reliability. Every Always-On node acts as a repeater in the mesh and is able to forward a message from one node to another in the mesh. But only the Always-On nodes can forward a message. Battery powered devices like door locks and battery powered thermostats cannot forward messages. Only the Always-On nodes can.

Solution: If some devices are not reliable, add more Always-On devices. Add a Z-Wave repeater or any device like a lamp dimmer. Even if you don’t use the lamp dimmer it will act as a repeater and improve the network. I have a few lamp switches I use for my Christmas lights which I leave plugged in year round because they help the Z-Wave network since these nodes are at the periphery of my home.

Distance between nodes is not always the criteria for adding more nodes in a network. The Z-Wave radio signals may bounce off metal objects like mirrors or appliances and cause two nodes that are only a few feet apart be completely unable to talk to each other due to reflections of the radio signals. Adding more nodes in the mesh provide alternate routes to nodes that otherwise might be in a dead zone due to these reflections cancelling out the radio signals.

3. Place the hub in a central location
Putting the hub in a corner of the basement might be convenient, but its a terrible idea for Z-Wave. The hub is the most important node in the network and should have the best location possible. While Z-Wave is a mesh network and can route or hop thru other nodes in the mesh, each hop is a significant delay and chokes up the network with more traffic. Ideally the hub should reach 90% of the nodes in your Smart Home without relying on routing. If the hub has Wifi then putting it in a central location is easy, you just need a wall outlet to plug it in. I have my hub hung off the back of a TV cabinet in roughly the middle of the first floor of my home.

4. Heal the Network
Once a Z-Wave network is built, it has to be “healed” so every node can use all the other nodes in the network to route messages. This healing process can take many minutes to even hours depending on the size of the network. When you first build a Z-Wave network, the first node added only knows that the hub is in the network. When you add a second node, the hub knows that both the nodes are in the network but the first node you added has no idea that node 2 is there – unless you heal the network. So any time you add a node, you need to heal at least a few nodes in the network if not the entire network. Be cautious with the healing process – it uses 100% of the Z-Wave bandwidth during the process and every node will wake up every FliR node (door locks) at least once which will drain the batteries of the FLiR node. Generally only heal when nodes have been added or removed or if there seems to be a problem in the network.

Z-Wave is able to self-heal automatically. Z-Wave nodes will try various routes to get their message thru if at first it doesn’t succeed. The node will remember the Last Working Route and try that one first for the next message. But if the nodes have no idea there are other nodes in the network they have no way of knowing what routes to try so at least one full heal of the network is required.

homeseerhealHomeSeer has several platforms so the precise method might be slightly different than shown here. From the web interface home page select the menu Plug-Ins->Z-Wave->Controller Management then select the Action “Fully Optimize a Network”. The network wide heal will take some time depending on the size of the network.

SmartThings Expert Z-Wave Eric Ryherd DrZwaveSmartThings user interface is thru their app which makes finding the network heal a bit of a challenge. Start from the dashboard and click on the three lines in the upper left corner. Your Hub should be the first choice in the menu that slides out, click on your hub. A new menu comes up, click on the last choice “Z-Wave Utilities”. The last choice on the next menu that slides in is “Repair Z-Wave Network” so click on it and then click on “Start Z-Wave Network Repair”. The repair will take from minutes to over an hour depending on the size of your network.

verahealVera has several versions of their UI but each of them has a similar menu structure so these instructions should work on any version. The Vera version shown here is UI7. Use a PC to log into GetVera.com and select your hub. From the Dashboard, select Settings->Z-Wave Settings and then click on the advanced tab. At the bottom of the advanced tab is the GO button to run the “Update Node Neighbors”. Depending on the size of the Z-Wave network this process will take several minutes to over an hour.

5. If a device doesn’t pair, first exclude it, then include it
You’ve taken the brand new Z-Wave IoT widget out of the box and you’ve tried to pair it (the Z-Wave term is “inclusion”) but it just won’t include! Arrrghhh! The first thing to try is to exclude the node first and then try including it. Any hub can “reset” or exclude a Z-Wave device even if that device was previously connected to another network. Some manufacturers occasionally fail to exclude the device during testing so the device may already be connected to their test network. Z-Wave Expert IoT WirelessOr you may have inadvertently included the device but the inclusion process failed somehow and the hub is confused. Excluding the node should reset it to the factory fresh state. Newer Z-Wave Plus devices (which have this logo on them) are required to have a way to reset them to factory defaults using just the device itself. Every device is different so you’ll have to refer to the device manual to perform a factory reset but if all else fails this should make the device ready to pair. Naturally having the hub physically close to the device being paired will also help though most devices can be paired from a distance.

Secure devices like door locks are particularly challenging to pair. First the secure device has to join the Z-Wave network, then the AES-128 encryption keys have to be exchanged and if that process fails (which it does on occasion), then you have to exclude and try the inclusion process all over again. Secure devices definitely want to be within a few feet of the hub during inclusion to ensure reliable and speedy Z-Wave communication.

6. Battery life and how to maximize it
When a battery powered Z-Wave device wakes up and turns on its radio, it uses 10,000 times more battery power than when it’s asleep. So the entire trick to making batteries last is to minimize the amount of time the device is awake. Some devices naturally have other battery draining activities mostly involving motors to throw a deadbolt or raise a window shade. Obviously any motor will use a lot more battery power than the Z-Wave radio but the radio will play a significant role in battery life.

When a battery powered device is added to a Z-Wave network the hub should do two things:

Assign the Association Group 1 NodeID to the hub
Association Group 1 is the “LifeLine” in Z-Wave and devices use this lifeline to send all sensor data and alerts to this node
All hubs are required to assign Group 1 but double check this assignment
Set the Wake Up Interval to no more than once per hour and ideally only a few times per day
Every hub assigns the WakeUpInterval differently and largely handles it behind the scenes so this may be difficult to verify or change
If the device is waking up every few minutes and sends a sensor reading then its battery life isn’t going to be more than a few weeks
The battery level of the device is usually reported at the WakeUpInterval rate
Many sensors have other Association Groups or Configuration Parameters that will let you specify the frequency of sensor readings. Realize that the more often the sensors report in, the shorter the battery life.

7. Dead nodes in your controller
One of the big problems in Z-Wave network maintenance is eliminating “dead” nodes. When a device fails or for whatever reason is no longer in use, then it needs to be removed from the controller. If it remains in the controller then the controller will try to route thru this dead node on occasion resulting in delays in delivering messages. Eventually the self-healing aspects of Z-Wave will make this less likely but various devices will on occasion attempt to route thru it. Since the node is dead, that wastes valuable Z-Wave bandwidth and potentially battery power of sleeping devices. Occasionally running a Heal on the network will remove the node from the routing tables but it will remain in the controllers routing tables. It is best to completely remove this dead node. Each hub has a different method for removing dead nodes and usually requires going into an advanced Z-Wave menu.

Following these guidelines will help your Z-Wave experience be more robust. If you have more questions please feel feel to reach out via email to drzwave at expresscontrols.com.


EZMultipli How-To for SmartThings
In "EZMultipli Multi-sensor"
SiLabs acquires Z-Wave - Good or Bad?
In "News"
Z-Wave Multi-sensor Version 2.0 with SmartStart - Batteries not Required
In "EZMultipli Multi-sensor"
Post navigation
Z-Wave Repeaters cannot test FLiR Nodes using Power Level CC
EZMultipli How-To for HomeSeer HSM200
Pingback: EZMultipli How-To for HomeSeer HSM200 – drzwave
Pingback: EZMultipli How-To for Vera – drzwave
Aaron (@aaronwolen)
FEBRUARY 22, 2017 AT 10:31 AM
Really informative article, thanks for writing it. Regarding habit 1, how can you tell if a dimmer switch is capable of triggering an event (rather than polling)? Could you make a few recommendations?


FEBRUARY 22, 2017 AT 1:42 PM
Generally most Z-Wave PLUS (the key is the PLUS) certified dimmers have “instant status” where they report their status automatically. Many new dimmers are also coming out with Central Scene Command Class which enables multiple taps of the switch to activate various scenes. For example, double tapping the top half of the switch can execute a special scene that dims the lights to watch TV whereas a single tap just turns that one light on.
The new Nortek WD500Z5 (not the older WD500Z – note the 5 on the end) and the Dragon Tech dimmers have central scene.
HomeSeer has a listing of a few dimmers but there are a lot of other ones on the market.


Rob Mouritsen (@robmouritsen)
AUGUST 19, 2017 AT 4:19 AM
Will Z-Wave and Z-Wave Plus devices mesh together?


AUGUST 20, 2017 AT 1:32 PM
Yes! Z-Wave and Z-Wave Plus are 100% compatible with each other. The Radio Technology is identical. Z-Wave Plus adds a lot of checks during Z-Wave certification so you can buy with confidence that the quality of the product (at least as far as Z-Wave is concerned) is much higher.

I recommend buying primarily Z-Wave Plus devices.


OCTOBER 10, 2017 AT 2:50 AM
Regarding Z-Wave heals, Vera has removed this function from it’s most recent UI7 firmware stating that this was due to a recent change at the protocol level (by Sigma) which means heals are no longer required. But I don’t understand this. What happens if I change the location of a device? How do I ensure routing is optimal if I can no longer run a network heal?
Thanks for a great article.


OCTOBER 12, 2017 AT 5:45 PM
I’ve sent a request in to Vera to see if they have in fact removed “heal”. UI7 still has Settings->Z-Wave settings->Advanced and then the Update Neighbor Nodes which does appear to do a heal to at least some (but not all) nodes. I’v sent in a request to Vera for more details.


OCTOBER 17, 2017 AT 3:01 PM
I heard back from Vera. They do still have Heal which is under the Settings menu as described above. What they have removed was their own routing algorithms. With a 500 series controller, they utilize the built-in routing algorithms from Sigma Designs. The main reason for using their own algorithms for the 300 series controllers (and earlier), was that the routing algorithm was potentially infinite. The controller would continue to try EVERY possible route which in a large network would take minutes. With the 500 series, the Last Working Route (LRW) is always tried and then up to 5 alternate routes are attempted. If those don’t work, then the frame is not delivered and dropped. This ensures that any frame will always timeout in about 10 seconds (a little longer when talking to FLiRS nodes).

With a 500 series controller, you also get Explorer frames so the network will automatically Heal itself to find a new LRW. But a full neighbor rediscovery is still better.


JANUARY 9, 2018 AT 7:00 PM
Will multiple Z-wave mesh’s piggyback off each other?

I have a single hub at the moment, my alarm panel that controls door locks/cameras/perimeter sensors/etc. But it’s pretty much locked down to a very small feature set and doesn’t play well when I put other devices on it (smart plugs/switches/lighting/etc). So I’m looking at getting another hub to control everything that isn’t security related, either a ST or a Pi with Hass.io and a Zwave/Zigbee stick.

If I went this route, would this require me to build another mesh with just the devices talking to the new ST/Hassio hub or would both mesh networks be able to bounce off each other to communicate with their respective nodes?


JANUARY 9, 2018 AT 7:17 PM
If you build two Z-Wave networks with the the security items related on one and the lights/thermostats/sensors on the other, then the two networks are separate and will not utilize each other for the mesh. Worse, you now have two networks that will interfere with each other.

You should be able to get all these devices on one Z-Wave network though. The security panel should be able to join another network or allow another hub to connect to it. Then you have 2 hubs on 1 network and it is up to you to manage who is in charge of which devices.

The best solution however is to get all the devices controlled via one hub – SmartThings, HomeSeer, Vera, Iris, Nexia, will all do what you are looking for. Homeseer has several plugins for certain security panels.


JANUARY 9, 2018 AT 7:48 PM
Yeah,that’s what I was afraid of, thanks for the quick reply. Security panel is from Vivint and from what I have been reading they don’t play well with secondary hubs/controllers but a few people have managed to get a ST hub working with it, will look further into HomeSeer and/or Hass.io as well. Thanks again!


Pingback: Z-Wave Basics - Notes For Beginners
Your email address will not be published. Required fields are marked *


Name *

Email *


Notify me of new comments via email.

Search for:
Search …
Z-Wave Multi-sensor Version 2.0 with SmartStart – Batteries not Required
ZWP500 Z-Wave Module Programmer and Tester
CES 2018
SiLabs acquires Z-Wave – Good or Bad?
How to make a Z-Wave SUPER Sniffer
dbetz52 on ZWP500 Z-Wave Module Programme…
DrZWave on SiLabs acquires Z-Wave –…
Z-Wave Basics - Note… on Seven Habits of Highly Effecti…
DrZWave on EZMultipli How-To for SmartThi…
John Dong on EZMultipli How-To for SmartThi…
March 2018
February 2018
January 2018
December 2017
October 2017
September 2017
August 2017
July 2017
April 2017
March 2017
February 2017
January 2017
Coding Guides EZMultipli Multi-sensor HomeSeer Hubs MDU News Presentations Raspberry Pi SmartThings Summit Teardowns Uncategorized Vera Z-Wave Controllers Z-Wave Developers Z-Wave Mesh Z-Wave Network Z-Wave Slaves Z-Wave Users
Blog at WordPress.com.

Sent from my SM-N910W8 using Tapatalk

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...