995 Zigbee Practical Exercises

995.1 Learning Objectives

By the end of this chapter, you will be able to:

Configure XBee Modules: Set up Zigbee coordinator and end devices with encryption
Integrate Zigbee2MQTT: Bridge Zigbee devices to Home Assistant via MQTT
Plan OTA Firmware Updates: Calculate update times and develop deployment strategies
Migrate to Matter: Develop transition strategies from Zigbee to Matter ecosystems

For Beginners: Getting Hands-On with Zigbee

What are these exercises? Practical projects that take you from theory to implementation. Each exercise builds skills you’ll use in real deployments.

Skill Progression:

Exercise	Skills Learned	Difficulty
1. XBee Setup	Hardware config, I/O binding	Beginner
2. Zigbee2MQTT	MQTT bridging, Home Assistant	Intermediate
3. OTA Updates	Firmware deployment, timing	Intermediate
4. Matter Migration	Future-proofing, hybrid networks	Advanced

What you’ll need: - XBee S2C modules (Exercise 1) - Raspberry Pi with CC2531 USB stick (Exercise 2) - Understanding of Zigbee protocol stack (Exercises 3-4)

Prerequisites: - Zigbee Fundamentals - Zigbee Hands-On Labs

995.2 Prerequisites

Before attempting these exercises, you should be familiar with:

Zigbee Fundamentals and Architecture: Core Zigbee concepts including device roles and the protocol stack
Zigbee Network Scaling Examples: Group messaging and network planning
Zigbee Device Binding Examples: Direct device control and ZCL clusters

995.3 Exercise 1: XBee Zigbee Network Setup and Binding

Objective: Configure XBee modules as Coordinator and End Devices, then implement direct binding for local control without cloud.

995.3.1 Hardware Requirements

3x XBee S2C modules
3x XBee USB adapter boards
1x Thermistor (10K NTC)
1x LED with resistor (330 ohm)
Jumper wires
XCTU software installed

995.3.2 Task 1: Hardware Setup

Configure 3 XBee S2C modules using XCTU software:

Module 1 (Coordinator):

CE = 1 (coordinator enable)
ID = 0x1234 (PAN ID)
SC = 0x7FFF (scan all channels)
EE = 1 (encryption enabled)
KY = 5A6967426565416C6C69616E636530 (network key in hex)

Module 2 (Router):

CE = 0 (not coordinator)
ID = 0x1234 (match PAN)
JV = 1 (coordinator verification)
EE = 1 (encryption enabled)
KY = 5A6967426565416C6C69616E636530 (same key)

Module 3 (End Device):

CE = 0 (not coordinator)
SM = 4 (sleep mode - cyclic sleep)
SP = 0x64 (10 second sleep period)
ST = 0x1388 (5 second awake time)
EE = 1 (encryption enabled)
KY = 5A6967426565416C6C69616E636530 (same key)

995.3.3 Task 2: Network Formation

Power on Coordinator first
Wait 10 seconds for network formation
Power on Router and End Device
Verify joining via XCTU “Discover devices” function

Expected XCTU Output:

Discovered 2 devices:
- Router: 0x0013A200XXXXXX (joined to coordinator)
- End Device: 0x0013A200YYYYYY (joined via router)

995.3.4 Task 3: I/O Binding

Configure End Device to send ADC (temperature sensor) readings directly to Router’s digital output (LED):

End Device Configuration:

D0 = 2 (ADC enabled on pin 20)
IR = 0x3E8 (sample every 1000ms)

Router Configuration:

DH = 0
DL = 0xFFFF (broadcast address initially)

Use AT+ID command to find Router’s 16-bit network address, then update End Device’s DL with Router’s address.

995.3.5 Task 4: Test Binding

Connect LED to Router’s DIO4 (pin 11)
Connect thermistor to End Device’s AD0 (pin 20)
Verify LED brightness changes with temperature

995.3.6 Expected Outcome

Network forms with Coordinator as Trust Center distributing keys
End Device wakes every 10 seconds, samples ADC, sends to Router, then sleeps
Router receives I/O sample packet, updates PWM output to control LED brightness proportional to temperature
Binding enables local automation without application server (sensor to actuator direct)

Learning Point

This exercise demonstrates that Zigbee’s I/O binding enables local automation loops without any application server or cloud. The sensor-to-actuator communication happens entirely within the mesh network, making it resilient to internet outages.

995.4 Exercise 2: Zigbee2MQTT + Home Assistant Integration

Objective: Bridge Zigbee devices to MQTT for integration with Home Assistant and create automation.

995.4.1 Hardware Requirements

Raspberry Pi 3/4
CC2531 USB stick (flashed with coordinator firmware)
Xiaomi temperature/humidity sensor
Home Assistant installation (HASS.io or standalone)

995.4.2 Task 1: Install Zigbee2MQTT on Raspberry Pi

Flash CC2531 with Coordinator Firmware:

# Using CCLoader + Arduino (alternative: J-Link programmer)
# Download coordinator firmware from Koenkk/Z-Stack-firmware
# Flash using CCLoader GUI or command line

Install Mosquitto MQTT Broker:

sudo apt update
sudo apt install mosquitto mosquitto-clients

Clone and Configure Zigbee2MQTT:

git clone https://github.com/Koenkk/zigbee2mqtt.git
cd zigbee2mqtt
npm ci

Configure data/configuration.yaml:

homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://localhost
serial:
  port: /dev/ttyACM0
advanced:
  network_key: GENERATE  # Generates random key on first start
  pan_id: 6754
  channel: 20

995.4.3 Task 2: Pair Zigbee Devices

Enable Pairing:

mosquitto_pub -t 'zigbee2mqtt/bridge/request/permit_join' -m '{"value": true}'

Put Xiaomi Sensor in Pairing Mode: - Hold button for 5 seconds until LED flashes

Verify Device Appears:

tail -f /var/log/zigbee2mqtt/log.txt
# Expected: "Successfully interviewed 'bedroom_temp_sensor'"

Rename Device in data/configuration.yaml:

devices:
  '0x00158d0001234567':
    friendly_name: 'bedroom/temp_sensor'

995.4.4 Task 3: Home Assistant Auto-Discovery

Ensure homeassistant: true in Zigbee2MQTT config, then:

Restart Home Assistant
Check Integrations -> MQTT -> Devices
Temperature sensor entity should auto-create as sensor.bedroom_temp_sensor_temperature

Verify MQTT Messages:

mosquitto_sub -v -t 'zigbee2mqtt/bedroom/temp_sensor'
# Output: {"temperature":22.5,"humidity":45,"battery":100}

995.4.5 Task 4: Create Automation

In Home Assistant, create an automation:

automation:
  - id: 'bedroom_temp_alert'
    alias: 'Bedroom Temperature Alert'
    trigger:
      - platform: numeric_state
        entity_id: sensor.bedroom_temp_sensor_temperature
        above: 25
        for:
          minutes: 5
    action:
      - service: notify.mobile_app
        data:
          title: "Temperature Alert"
          message: "Bedroom temperature high: {{ states('sensor.bedroom_temp_sensor_temperature') }}C"

995.4.6 Expected Outcome

Zigbee temperature sensor publishes to MQTT topic zigbee2mqtt/bedroom/temp_sensor every 5 minutes
Home Assistant automatically discovers sensor and creates entity
Automation triggers push notification when temperature exceeds 25C for 5 minutes
Understanding MQTT bridge architecture: Zigbee - Coordinator - Zigbee2MQTT - MQTT Broker - Home Assistant

Learning Point

Zigbee2MQTT demonstrates the protocol bridging pattern common in IoT integrations. Zigbee’s mesh network is excellent for low-power sensors, while MQTT provides standard integration with cloud and automation platforms.

995.5 Exercise 3: Zigbee OTA Firmware Update Simulation

Objective: Understand Over-The-Air (OTA) firmware update process and implement update strategy for deployed devices.

995.5.1 Task 1: OTA Process Understanding

Document the 7-step Zigbee OTA cluster flow:

Step 1: Query - End device queries Coordinator: “Any firmware updates available?” - Command: Query Next Image Request

Step 2: Response - Coordinator responds with firmware metadata - Payload: version, manufacturer ID, image type, file size

Step 3: Comparison - End device compares with current firmware version - If newer: requests download

Step 4: Transfer - Coordinator transfers firmware in blocks - Block size: 48-64 bytes per block (Zigbee payload limits)

Step 5: Recovery - End device requests missing blocks (if packet loss occurred)

Step 6: Verification - End device verifies image checksum (CRC32)

Step 7: Reboot - Device reboots and boots into new firmware

995.5.2 Task 2: Calculate Update Time

Given: - Firmware size: 128 KB - Zigbee payload: 64 bytes per block - Block interval: 2 seconds (sleep-wake cycle for battery device)

Calculation:

Total blocks: 128,000 / 64 = 2,000 blocks
Time per device: 2,000 x 2 sec = 4,000 sec = 66 minutes

For 100 devices (sequential update):
100 x 66 min = 6,600 min = 110 hours = 4.5 days

995.5.3 Task 3: Optimize Strategy

Implement batched updates to reduce total deployment time:

Group Devices by Proximity: - Reduces channel congestion from retransmissions - Nearby devices share routing paths

Update Routers First: - Routers are always-on (no sleep delays) - Estimated time: 128KB / 250 bps effective = ~17 minutes per router - Ensures mesh stability during end device updates

Schedule Low-Traffic Windows: - Updates during 2am-5am minimize interference with normal operation - Sensor reports typically occur on schedule, not continuous

Use Multicast Groups: - OTA cluster supports group addressing - Send each block once to group instead of per-device - Efficiency gain: 10 devices in group = 10x fewer transmissions

Optimized Timeline:

Phase 1: 36 routers, multicast groups of 6
- 6 groups x 17 min = 102 min (~2 hours)

Phase 2: 163 end devices, batches of 10
- 17 batches x 66 min / 10 (multicast savings) = 112 min (~2 hours)

Total: ~4 hours vs 4.5 days (27x improvement)

995.5.4 Task 4: Rollback Plan

If new firmware has bugs, how to revert?

Option A: Dual Partition (Preferred) - Device stores previous firmware in backup partition - If boot fails 3 times, automatically reverts - Recovery time: 30 seconds per device

Option B: Re-push Old Firmware via OTA - Push previous version as “new” update - Takes another 66 min per device - Recovery time: 4.5 days for 100 devices

Best Practice: - Always use dual-partition devices in production - Maintain firmware version database - Test on 5% of devices before mass deployment

995.5.5 Expected Outcome

Understanding that OTA is SLOW for battery devices (can take hours per device)
Recognition that Zigbee payload limits (64-100 bytes) create bottleneck
Best practice: Test firmware thoroughly before mass deployment (rollback is painful)
For time-critical updates, consider Thread’s larger IP packets (1280 bytes) or switch to Wi-Fi for update, Zigbee for operation

Critical Learning

OTA firmware updates are the highest-risk operation in IoT deployments. A buggy firmware can brick thousands of devices with no easy recovery. Always:

Test on 5% of fleet first
Implement dual-partition boot
Have rollback firmware pre-staged
Schedule updates during maintenance windows

995.6 Exercise 4: Zigbee to Matter Migration Planning

Objective: Develop migration strategy from legacy Zigbee network to Matter-compatible ecosystem.

995.6.1 Task 1: Current State Analysis

Inventory existing Zigbee deployment:

Current Deployment:

50 Zigbee Home Automation (ZHA) devices:
- 30 lights (various manufacturers)
- 15 sensors (Xiaomi, Aqara)
- 5 locks (Yale, Schlage)

1 SmartThings Hub (Zigbee coordinator)
Integration: Google Home via SmartThings cloud

Pain Points:
- Cloud dependency (SmartThings outage = no control)
- Single-vendor lock-in (hub-specific integrations)
- No Apple HomeKit support

995.6.2 Task 2: Matter Compatibility Assessment

Check device chipsets for Matter upgrade capability:

Chipset	Manufacturer	Matter Capable	Action Required
EFR32MG21	Silicon Labs	Yes	Firmware update
EFR32MG12	Silicon Labs	Yes	Firmware update
CC2530	Texas Instruments	No	Replace device
CC2652	Texas Instruments	Yes	Firmware update
nRF52840	Nordic	Yes	Firmware update

Assessment Results:

30 lights:
- 20 use EFR32 (Matter-capable via firmware)
- 10 use CC2530 (NOT Matter-capable, Zigbee-only)

15 sensors:
- Xiaomi/Aqara use proprietary chips (bridge required)

5 locks:
- 3 use CC2652 (Matter-capable)
- 2 use CC2530 (NOT Matter-capable)

995.6.3 Task 3: Migration Options

Option A: Coexistence Keep Zigbee network, add Matter-over-Thread border router, bridge between protocols.

Pros:
- No device replacement required
- Gradual migration possible
- Preserves existing investment

Cons:
- Complexity (two networks to manage)
- Bridge latency (20-50ms additional)
- Multiple failure points

Option B: Full Replacement Replace all devices with Matter-certified Thread/Wi-Fi devices.

Pros:
- Future-proof
- Single protocol
- Native local control

Cons:
- High cost ($50-100 per device x 50 = $2,500-5,000)
- Installation time
- Learning new device apps

Option C: Hybrid (Recommended) Replace coordinator with Matter controller, firmware-update compatible devices, bridge incompatible ones.

Pros:
- Balance of cost and modernization
- Preserves working devices
- Gradual transition

Cons:
- Some devices remain bridged
- Mixed automation capabilities

995.6.4 Task 4: Implementation Plan

For hybrid approach, create timeline:

Month 1: Deploy Matter Controller - Install Home Assistant with Matter support - Add Thread border router (Apple TV, HomePod Mini, or dedicated) - Verify Thread network formation - Cost: $50-150 for border router

Month 2: Firmware Update Compatible Devices - Update 20 lights with EFR32 to Matter - Update 3 locks with CC2652 to Matter - Total: 23 devices native Matter - Cost: $0 (software updates)

Month 3: Bridge Remaining Zigbee Devices - Keep SmartThings hub for 27 incompatible devices - Install Zigbee2MQTT as backup bridge - Configure Matter bridge for Zigbee2MQTT - Total: 27 devices bridged to Matter

Months 4-6: Gradual Replacement - Replace 10 CC2530 lights with Matter bulbs: $150 - Replace 2 CC2530 locks with Matter locks: $300 - Replace 15 Xiaomi sensors with Thread sensors: $225 - Monthly budget: $225/month

Final State:

Native Matter: 23 + 27 = 50 devices
Bridged Zigbee: 0 devices (all replaced)
Total migration cost: ~$675 over 6 months

995.6.5 Expected Outcome

Understanding that Matter is NOT a drop-in replacement for Zigbee (different network layer - Thread vs Zigbee mesh)
Coexistence is possible via bridges but adds complexity
Long-term trend: New products will be Matter-certified (Thread or Wi-Fi), Zigbee becomes legacy
Best practice: For new deployments (2024+), choose Matter; for existing Zigbee, maintain and gradually migrate

Learning Point

The Matter ecosystem represents a paradigm shift from proprietary protocols to an open standard. Unlike Zigbee’s fragmented profiles, Matter provides:

Multi-admin: Multiple apps can control same device
Multi-fabric: Device can join multiple homes
Local-first: No cloud required for basic operation
Cross-ecosystem: Works with Apple, Google, Amazon, Samsung

995.7 Knowledge Check

Quick Assessment

Question: What is the main advantage of Zigbee device binding over hub-routed commands?

Explanation: Device binding creates a direct path between devices (25ms latency) that works even when the coordinator is offline, compared to hub-routed commands (~100ms) that require the coordinator.

Question: Why is Zigbee OTA firmware update slow for battery-powered devices?

Explanation: Battery devices sleep between blocks to conserve power (2+ second intervals), and Zigbee’s 64-byte payload means 128KB firmware requires 2,000 blocks, taking ~66 minutes per device.

Question: What is the primary difference between Zigbee and Matter at the network layer?

Explanation: Matter uses standard IPv6 networking (via Thread or Wi-Fi), while Zigbee has its own proprietary network layer. This is why Matter devices need new chipsets or firmware updates - it’s a fundamental protocol change.

995.8 Summary

This chapter provided four hands-on exercises for practical Zigbee implementation:

XBee Network Setup: Configured coordinator, router, and end device with encryption and I/O binding for local automation
Zigbee2MQTT Integration: Bridged Zigbee devices to Home Assistant via MQTT for standard automation platform integration
OTA Firmware Planning: Calculated update times (66 min/device) and developed optimization strategies (multicast, batching) to reduce deployment from 4.5 days to 4 hours
Matter Migration: Assessed Zigbee device compatibility and created a 6-month hybrid migration plan balancing cost and modernization

995.9 What’s Next

After completing these exercises, explore the Zigbee Comprehensive Review for interactive visualizations and assessment tools to test your understanding.

Related Chapters

Prerequisites: - Zigbee Fundamentals - Core protocol concepts - Zigbee Hands-On Labs - Additional practical exercises

Worked Examples: - Zigbee Network Scaling Examples - Multi-floor deployment - Zigbee Device Binding Examples - Direct control

Review: - Zigbee Comprehensive Review - Assessment and visualization