In a large network, the risk for instabilities increases over time as more and more devices are added.
Z-wave uses mesh networking to extend the range and secure connections through the network. An important part of this is that each unit knows or can find a working path. One type of instabilities here is that the working route changes over time or that the devices don’t have a working path to use. This leads to extensive extra signaling in the network in search of a working path.
Problems like this in a mesh network is tricky to discover, ambiguous symptom as increased latency and increased current consumption of devices. Instabilities generate a lot more signaling to the network. A failed message leads automatically to re-sending within the default route; thereafter, the alternative route is tried. If that one is not working, either a search for a new route is performed. In total, up to 7 attempts are made to contact the Controller.
To get a stable mesh network, it is recommended to do a complete re-installation of the Z-wave network. After excluding all devices (no devices have to be demounted from their positions). The adding of devices should be done when they are at their actual position.
The important thing is to start with the routing devices nearest the Controller and gradually add routing devices further away from the Controller.
With all routing devices in place, a network healing could be performed before adding sleeping devices. Battery-powered devices are normally sleeping devices. Same here; add the devices closest to the Controller first and work gradually further away. This ensures a stable working path is stored as the default path used during the inclusion process.
This is a tedious work effort that takes time to do. Unfortunately, mesh networks can be tricky, difficult to understand what is actually ongoing. Even if they seem to work fine, there can be a lot of excess traffic ongoing under the surface, leading to increased battery consumption and eventually decreased performance, response time, and drop out of units.
More tips to get a stable network
Avoid unnecessary traffic to keep the air “free” for important messages, avoiding collisions between messages, and resending of these by:
- Making sure that each unit is within range of the controller or a routing device.
- Exclude devices from the controller that are no longer needed.
- Removing dead or otherwise unreachable units will create overhead traffic in the network until they are marked as failed by the controller.
- Exclude all disappeared devices from programmed scenarios or events (association groups).
- Avoiding frequent reallocation of devices. Moving a device will require a network heal (updating of routing tables for all devices).
- Use reasonable polling intensity in the controller settings. Heavy polling creates a lot of traffic and should therefore be limit.
- Setting long wake-up intervals for all included devices (preferably to the maximum).
- Most metering devices (power-, temperature measuring devices, etc.) are configurable to send sensor data at different frequencies or only send when a change occurs. Use these settings to avoid unnecessary reporting.
- Devices that now or then drops out of direct contact with the controller and have to use a routing devise occasionally will trigger a network heal each time. Place the unit either for stable direct contact with the controller or so that the same routing device is used all the time.
- Some controllers support manual activation of network heal (updating device’s routing tables). It is good practice to do this each time a device has been added/remover or moved, but not regularly due to the extensive signaling it generates.
