Many Home Assistant users with Zigbee devices are unaware that the Zigbee standard defines multiple routing strategies and that they have a choice in how their network handles message delivery. By default, ZHA uses Table Routing, a method that works well in small networks but can lead to congestion, increased route discovery traffic, and overall inefficiencies as the network expands. An alternative, Source Routing, shifts routing decisions to the coordinator, significantly reducing network overhead, avoiding redundant route discovery requests, and ensuring more predictable message delivery.

This article provides a clear breakdown of Table Routing vs. Source Routing, explaining their core differences, advantages, and potential drawbacks to help you make an informed decision. Most importantly, it will guide you on how to enable Source Routing in ZHA and explore why it could dramatically improve the stability and efficiency of your Zigbee network.

By understanding these mechanisms, you can make informed decisions to improve your smart home setup. Perhaps with enough user adoption and feedback, Source Routing could even become the default in ZHA, leading to better performance for all Home Assistant users.

How Zigbee Routing Works in ZHA

Zigbee is a dynamic and efficient wireless protocol designed to interconnect smart home devices in a self-healing mesh network. Unlike traditional point-to-point connections, Zigbee devices work together by relaying messages across the network, ensuring seamless communication even in large or complex environments. This mesh architecture enhances coverage, redundancy, and overall stability, making it ideal for home automation. The network is built on three essential device types:

• Coordinator – The central hub of the network, often Home Assistant with ZHA. It manages device communication, assigns addresses, and facilitates message routing. The coordinator is essential for forming and maintaining the Zigbee mesh.
• Routers – Zigbee devices that extend the network range by forwarding messages between other devices. These include powered devices like smart plugs and bulbs, which actively participate in message propagation and network stabilization.
• End Devices – Battery-operated or low-power devices such as sensors and buttons. They rely on routers or the coordinator for communication and often enter sleep modes to conserve energy, waking only when necessary to send or receive data.

In a Zigbee mesh, all devices work together to form a self-sustaining network, where messages hop from one node to another to reach their destination. This structure ensures strong connectivity, even in large setups with multiple routers and end devices.

Zigbee networks rely on routing to efficiently relay messages between devices, ensuring smooth communication and network stability. The protocol employs two primary routing mechanisms, each with its strengths and limitations:

• Table Routing (default in ZHA) – Each device maintains its own routing table, determining the next hop for messages independently. While this works well in small networks, it can cause congestion and inefficiencies as the network expands.
• Source Routing (often overlooked) – The coordinator predefines the entire route for each message, significantly reducing network overhead and improving message reliability.

Many users experience slow responses or unstable communication and mistakenly attribute these issues to ZHA itself, rather than the routing method in use. By understanding these mechanisms, users can diagnose and resolve performance bottlenecks and reduce unnecessary network traffic. Enabling Source Routing in ZHA can often lead to noticeable improvements, ensuring faster device responses and a more resilient smart home network.

Table Routing – The Default Mechanism

Table Routing is enabled by default in ZHA and remains the most common Zigbee routing strategy. Each router keeps a local routing table, listing possible paths to other devices. Whenever a device sends a message, it consults this table to determine the next hop, forwarding the packet until it reaches its destination.

Zigbee relies on a route discovery process to establish paths between devices, particularly when they communicate for the first time or after a route becomes invalid. This process involves routers exchanging messages to determine the best available path. However, as the network grows beyond the typical routing table capacity (often around 32 devices), excessive broadcast traffic and frequent route failures can occur.

Each router independently manages its routing table, which can lead to inconsistencies—especially when devices frequently join or leave the network. Over time, outdated or incorrect entries may accumulate, causing messages to take inefficient or broken paths. While the network periodically refreshes route tables to mitigate these issues, in dense environments, this can introduce additional overhead and delays, further straining network performance.

Zigbee employs several NWK command frames to build and maintain routes:

• Route Request (0x01): Broadcast when a device needs to establish a route to a specific destination, prompting nearby routers to assist in discovering the best path.
• Route Reply (0x02): Sent in response to a Route Request, confirming the discovered route and providing a return path for the originating device.
• Link Status (0x03): Periodically sent by all Zigbee devices—including coordinators, routers, and some end devices—to update neighbors on link quality and network stability.

According to the Zigbee Specification (Zigbee 3.0, Document 07-5356-17), these messages are crucial for keeping routes accurate. However, not all devices implement them reliably. Some have limited memory for storing routing information, causing frequent table purges that disrupt data flows.

Example: Table Routing in Action

Below is an example illustrating how a route is established from the coordinator (0x0000) to device 0x7747 using Table Routing. The log entries show the propagation of the Route Request and the subsequent Route Reply, along with the time delays.

1. Route Discovery Overhead: The coordinator (0x0000) broadcasts a Route Request (Packet 1394), as it does not have a pre-established route to 0x7747.
2. Flooding the Network: Since no route is known, multiple routers rebroadcast the Route Request (Packets 1395–1422), increasing network congestion.
3. Route Reply Processing: Once 0x7747 receives the request, it sends a Route Reply (Packet 1398) back along the discovered path to the coordinator.
4. Command Transmission Begins: After the route is established, the actual command (Packet 1423) is sent to 0x7747.
5. Delayed Response: The device 0x7747 processes the request and responds with an ACK (Packet 1433), followed by a Default Response (Packet 1437) and a Report Attributes message (Packet 1439). The final APS ACK from the device reaches the coordinator in Packet 1441.

Time Analysis

• Route Discovery Time: The Route Request and Route Reply exchange takes ~100ms before the route is established.
• Command Transmission Delay: The first command is sent at 261ms, and the APS Acknowledgment from 0x7747 arrives at 333ms, totaling 72ms.
• Final Acknowledgment: The final acknowledgment takes another 50ms to reach the coordinator, resulting in a total execution time of ~383ms.

This example demonstrates that Table Routing requires additional time due to route discovery overhead, which adds approximately 100ms to the overall execution. While this may seem negligible in isolation, the cumulative delay becomes significant in larger Zigbee networks where multiple devices communicate simultaneously. The total execution time for a single command—including route discovery, transmission, and acknowledgment—reaches approximately 383ms. This latency increases further when automations trigger multiple devices at once, leading to network congestion, noticeable slowdowns, or even timeouts.

Limitations of Table Routing

Several issues can arise when Table Routing is used, especially in larger networks:

• Faulty Router Implementations: Some devices, including those labeled Zigbee 3.0 (often Tuya-based), handle route discovery poorly or maintain incomplete routing tables. This can lead to intermittent connectivity and unpredictable device behavior.
• Limited Routing Table Size: Routers with small tables may struggle in big networks, leading to packet loss or delayed messages. As more nodes join, the router might cycle out old routes, forcing frequent rediscovery.
• No Exclusion of Bad Routers: If a router fails to forward messages properly, it may remain in the path. Zigbee does not provide a way to blacklist faulty routers, so removing or replacing them might be the only option for stability.
• Dynamic Updates: Unreliable routers can keep broadcasting link status frames, preventing them from being dropped from routing tables, thus cluttering the network with suboptimal paths.

Many users attribute network instability to Home Assistant or ZHA, not realizing that the problem may lie in how Table Routing is implemented by certain devices. This default behavior in ZHA works in smaller setups but can cause congestion and delays as networks grow. Moreover, if you’re rapidly expanding your smart home or adding a variety of third-party Zigbee devices, you may face these table-overflow issues sooner than you expect.

Source Routing – A More Efficient Alternative

Source Routing shifts routing decisions to the coordinator. Instead of each router maintaining its own table, the coordinator calculates the entire route and includes it in the packet header. In a typical Zigbee 3.0 network, this involves additional command frames beyond the standard Route Request/Reply:

• Many-to-One Route Request (NWK Command Frame: 0x06): Often initiated by a coordinator acting as a “concentrator.” This notifies routers that the coordinator will handle routing decisions and gather route information.
• Route Record (NWK Command Frame: 0x07): Used to accumulate the path a packet traverses, allowing the coordinator to learn and store complete routes.

By maintaining a global view of the network, the coordinator can choose paths that avoid devices with poor routing implementations. This approach offers several advantages:

• Fewer Routing Hops: By selecting an optimal path, the coordinator bypasses problematic or distant routers.
• Better Performance: Messages often travel faster, particularly in complex networks that rely on stable, well-defined routes.
• Easier Debugging: Each path is explicitly defined in the packet header, making it simpler to track hops and troubleshoot issues when they arise.

From personal experience, enabling Source Routing in ZHA has significantly improved network reliability. Communication becomes more responsive, and devices that struggled with Table Routing typically work better. This is especially noticeable if you frequently send commands to multiple devices at once or rely on intricate automations that trigger events in quick succession.

While Source Routing lets the coordinator define entire paths, it relies on having accurate network topology data. Many-to-One Routing collects this information by notifying routers that the coordinator is a central control or monitoring device. In essence, the coordinator becomes a ‘concentrator’ for route information.

• Coordinator as Concentrator – By initiating a Many-to-One Route Request, Home Assistant (as the coordinator) informs other devices that it will handle routing decisions.
• Route Record Accumulation – Routers send back route information, enabling the coordinator to maintain a global view of the network.
• Optimized Source Routing – With the knowledge gained, the coordinator can select the best path for each packet, avoiding unreliable routers and reducing broadcasts.

When combined, Many-to-One Routing and Source Routing significantly reduce the burden on individual routers, particularly those with limited memory, by shifting routing responsibilities to the coordinator. Instead of requiring each router to maintain large routing tables for every connected device, these methods centralize route management, reducing network congestion and overhead caused by frequent route discoveries.

This principle is widely recognized in the industry. Silicon Labs, a key player in Zigbee technology, highlights this in their documentation:

“Many-to-one routing is a simple mechanism to allow an entire network to have a path to a central control or monitoring device. Under normal table routing, the central device and the devices immediately surrounding it would need routing table space to store a next hop for each device in the network, as well as an entry to the central device itself. Given the memory-limited devices often used in Zigbee networks, these large tables are undesirable.” — Silicon Labs UG103.2: Zigbee Fundamentals

This recommendation reinforces why Many-to-One Routing is particularly effective in Home Assistant setups, where the coordinator acts as the primary hub for all network activity. Hardware manufacturers themselves emphasize the advantages of consolidating routing intelligence at the coordinator, rather than distributing it across memory-constrained routers. By enabling Source Routing and Many-to-One Routing, Home Assistant can function as an optimized Zigbee concentrator, ensuring efficient communication across the entire network while preventing unnecessary routing overhead.

Example: Command Execution with Source Routing

To provide a direct comparison with Table Routing, the following log captures the exact same command execution from Home Assistant to 0x7747, but this time with Source Routing enabled. This allows us to analyze the performance differences between the two approaches in a controlled scenario.

1. Predefined Route Included: The request (Packet 55843**) is sent without additional route discovery, as confirmed by the packet details in the screenshot, which display the Zigbee Network Layer data containing the predefined route.
2. First Relay Identified: The first relay, 0xa444, is already specified in the packet structure, ensuring the message follows a direct and optimized path without requiring intermediate route discovery.
3. Immediate Forwarding: The packet is forwarded to the first hop on the route (0xa444) and immediately relayed to the final destination (0x7747) in Packet 55845.
4. Acknowledgment Process: The target device (0x7747) acknowledges receipt in Packet 55847, meaning the command has already been processed at this point.
5. Final Acknowledgment to Coordinator: The acknowledgment for the coordinator is returned in Packet 55853, marking the completion of the exchange.

Timing Analysis

• First Acknowledgment: The target device confirms receipt in 24ms (Packet 55847).
• Full Exchange Completion: The full request-response cycle, including the final acknowledgment to the coordinator, is completed within 59ms** (Packet 55853).
• Efficiency Gain: Compared to Table Routing, Source Routing eliminates the 100ms+ route discovery overhead, leading to faster response times and less congestion.
• No Additional Route Discovery: Unlike Table Routing, no broadcast Route Requests are required, as the complete route is known in advance.
• Immediate Forwarding: The request is efficiently relayed through the precomputed path, reducing delay and network congestion.
• Reduced Network Traffic: Since no additional Route Requests are needed, the network avoids unnecessary broadcast traffic, improving overall performance.

Source Routing significantly improves network responsiveness and stability, particularly in home automation scenarios where multiple devices need to react quickly. Unlike Table Routing, which can introduce over 100ms of additional delay due to route discovery, Source Routing ensures that messages follow a predefined and optimized path, reducing latency and network congestion. In direct comparison, Table Routing required 383ms to complete a command exchange, whereas Source Routing achieved the same operation in just 59ms — a drastic reduction that directly impacts the perceived responsiveness of smart home automations.

For example, when a motion sensor triggers a lighting automation, it first sends a message to the coordinator (Home Assistant), which processes the automation logic and then issues commands to the respective lights.

In simpler scenarios, motion sensors can be directly bound to lights, allowing instant communication without involving Home Assistant. However, for more complex automations — such as adaptive lighting, conditional triggers, or multi-device coordination — centralized processing via Home Assistant is necessary. Learn more about how advanced lighting control can be implemented in this detailed guide.

With Source Routing, these messages traverse the network efficiently, ensuring near-instantaneous response times. In contrast, Table Routing may introduce delays due to frequent route requests and unnecessary network broadcasts.

• Faster Automation Execution: With Source Routing, devices receive commands more quickly, leading to more immediate responses in real-world use cases.
• Scalability for Larger Networks: As the number of Zigbee devices grows, Source Routing prevents congestion by reducing the overhead caused by continuous route discoveries.
• Improved Stability: Messages are delivered through predefined, reliable paths, reducing the likelihood of failures caused by inconsistent routing table entries.

If you experience random delays, inconsistent automations, or suspect that certain routers in your Zigbee network are not handling Table Routing efficiently, enabling Source Routing in ZHA is a straightforward way to enhance performance. It requires minimal setup, can be easily reversed if needed, and offers immediate improvements in communication speed and reliability.

Zigbee2MQTT and Source Routing – A Recommended Alternative

Many users recommend Zigbee2MQTT for its stability, which may be largely due to the fact that it enables Source Routing by default. Unlike ZHA, where Table Routing is the default, Zigbee2MQTT ensures that the coordinator calculates and dictates routes, reducing dependence on individual routers’ limited routing tables. This often results in a more stable and efficient network.

Here’s an excerpt from Koenkk (Zigbee2MQTT maintainer) in a related discussion:

“Source routing only applies to the CC2531 (due to memory constraints), the CC2652/CC1352 all have source routing enabled by default.” — Koenkk on Jun 8, 2021

This suggests that one key reason Zigbee2MQTT is frequently recommended over ZHA is its built-in reliance on Source Routing, avoiding many of the pitfalls of Table Routing.

However, this does not mean that switching to Zigbee2MQTT is the only solution. Simply enabling Source Routing in ZHA may provide similar benefits, potentially resolving common stability and congestion issues without requiring users to migrate their entire setup. Before making the switch, users should first try enabling Source Routing in ZHA to see if it sufficiently improves network performance.

Further Reading: If you’re deciding between Zigbee2MQTT and ZHA for your Home Assistant setup, check out this detailed comparison: Zigbee2MQTT vs. ZHA – Which One Should You Choose?

Choosing between Zigbee2MQTT (Z2M) and Zigbee Home Automation (ZHA) is a key decision for building a reliable Zigbee network in Home Assistant. ZHA offers seamless integration with minimal setup, while Z2M provides greater control and flexibility. The best choice depends on your network size, device compatibility, and how much customization you need.

How to Enable Source Routing in ZHA

Now that we’ve covered the theory and seen the tangible benefits of Source Routing, it’s time to put it into action! Enabling Source Routing in ZHA is straightforward and can lead to immediate improvements in network stability and performance — especially for users with larger setups or persistent routing issues.

To activate Source Routing in ZHA, simply modify your Home Assistant configuration, instructing Zigpy (the Zigbee stack used by ZHA) to use Source Routing. Here’s how:

1. Open your configuration.yaml file (usually found in your Home Assistant config directory).
2. Add or modify the zha section to include a zigpy_config entry:

   1 2 3

   zha: zigpy_config: source_routing: true

3. Save your changes.
4. Restart Home Assistant for the configuration to take effect.

Once Home Assistant is back up, ZHA will run with Source Routing enabled. To ensure the best results, give the coordinator enough time to analyze and optimize routes — this process happens automatically as devices communicate. Within the first 10 minutes, you should already notice an improvement in routing efficiency, particularly in larger networks or those with problematic routers. Over time, as the coordinator refines its route mapping, the stability and performance of your Zigbee network should continue to improve.

If you run into issues, you can disable Source Routing by removing or commenting out the source_routing: true line and then restarting Home Assistant again. Keep in mind that some devices may require a bit of time to fully adjust or rebuild their internal routing tables.

Conclusion – Why Source Routing Matters

Zigbee networks rely on efficient routing mechanisms to maintain stability and responsiveness, yet many users are unaware of the impact Table Routing and Source Routing can have on their setup. In ZHA, Table Routing is the default, but as networks grow, it can lead to congestion and delayed communication. Source Routing provides an alternative that reduces broadcast traffic and improves performance, particularly in larger networks.

By enabling Source Routing in ZHA, you might experience:

• Faster device responses and reduced latency
• Fewer routing-related issues, especially in larger Zigbee networks
• Improved network stability by bypassing unreliable routers

For those experiencing persistent network instability, Zigbee2MQTT is often recommended due to its stability, which may largely stem from the fact that it enables Source Routing by default. Instead of switching entirely, enabling Source Routing in ZHA may already be sufficient to resolve many issues. Before making any drastic changes, users should first test whether activating Source Routing in ZHA provides the expected benefits.

Ultimately, understanding and leveraging Source Routing can ensure your smart home runs smoothly, from simple single-device triggers to complex multi-device automations. Whether you’re troubleshooting persistent delays or simply seeking a more responsive system, Source Routing offers a compelling alternative to traditional Table Routing in Zigbee networks.

Have you tried Source Routing in ZHA? Share your experiences with the community—your feedback can help refine best practices and potentially encourage ZHA maintainers to consider making Source Routing the default option in the future.