Increase the broadcast budget

[puddly]

Follow up to #54 (and #43).

I ran a quick packet capture test on my home network while spamming broadcasts (setting Ziggurat's limit to 255) and noticed something odd: none of my home routers behaved the way the SiLabs SDK claims they should and none of the routers ever really stopped relaying packets during a sustained burst of almost 64 broadcasts in 20 seconds.

Many manufacturers using SiLabs chips thankfully do not enable firmware encryption so we can statically analyze what they use as the firmware config. The results are a little surprising (the IKEA ones were checked by hand, the rest were checked with a script that speeds up the analysis):

Vendor	Images	Table size(s)
NodOn	35	15 (3), 35 (32)
IKEA	31	15 (6), 46 (4), 50 (14), 56 (7)
Innr	15	40
Bosch	5	15
SalusControls	5	15
Niko	4	40 (3), 50 (1)
Datek	3	15
Gledopto	2	40
Heiman	2	15
LEDVANCE	2	50
Aeotec	1	15
EcoDim	1	50
Inovelli	1	15

All new generation IKEA devices override the broadcast table size to 50! Inner and Gledopto use 40, LEDVANCE uses 50. Hue images are encrypted but they behaved identically to IKEA so I would assume they use at least 40-50 as well.

For a network consisting of popular router devices (IKEA, Hue, Innr, etc.), every router on the network has a broadcast table size of 40-50 and theoretically can relay broadcasts at a rate of 2/second. I think we can adjust the Ziggurat rate limiting accordingly.

[Copilot]

Pull request overview

This pull request adjusts Ziggurat’s broadcast rate limiting defaults (token bucket capacity and refill rate) to better match observed real-world Zigbee router broadcast table sizes/rates (e.g., IKEA/Hue/Innr-class meshes), improving sustained broadcast throughput and burst tolerance.

Changes:

• Increased the broadcast token bucket capacity (broadcast_budget_tokens) from 15 to 40.
• Increased the sustained broadcast admission rate by decreasing broadcast_token_refill from 1800ms to 675ms (~1.48 broadcasts/sec).

Comments suppressed due to low confidence (1)

crates/ziggurat-zigbee/src/constants.rs:388

• The doc comment for broadcast_critical_reserve says stack-critical broadcasts may draw these tokens, but the implementation admits TrafficClass::Critical without drawing from the bucket (BroadcastBudget::take bypasses tokens entirely). This makes the comment misleading—these tokens currently act as an unconsumable floor for host/forwarding traffic, not a critical-only reserve.

    broadcast_token_refill: Duration = Duration::from_millis(675),

    /// Broadcast tokens only stack-critical broadcasts (route discovery, key updates,
    /// leaves, ZDO management) may draw; a host flood can never consume them.
    broadcast_critical_reserve: u8 = 3,

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.