Zigbee, Engineered: Part 2
The remote that lives on a coin cell. Part 1 built the always-on half of a Zigbee network: a wall powered sensor and router that never sleeps. This is the other half, the half most real products are made of: a battery remote that sleeps with its radio off, wakes when you press it, toggles Part 1's bulb, reports its own battery, and takes its firmware updates in its sleep.
Preview build: the full course is readable here; checkout opens at launch.
Part 1 was the always-on world. This is the battery world.
Part 1's device plugs into the wall. Its radio listens around the clock, it routes other devices' traffic, and its power budget is whatever the mains feels like providing. You could learn commissioning, clusters, reporting and OTA updates there, and you did, without power ever once being the constraint.
Almost nothing you will ever ship works like that. Real Zigbee products run on coin cells and AA pairs, in remotes, buttons, contact sensors, leak detectors and thermostats, and they live or die on a number Part 1 never had to care about: average current. A device that draws 15 milliamps awake has to be asleep about 99.9 percent of its life to survive a year on a CR2032. Designing for that is not Part 1 with a battery bolted on. It is a different discipline, with different failure modes, different debugging, and a different definition of done.
The always-on world (Part 1)
- Wall power: the radio listens around the clock
- Routes other devices' traffic
- Power is never the constraint
- Updates arrive whenever the server offers them
The battery world (Part 2)
- A coin cell: average current is the product spec
- Asleep about 99.9 percent of its life, radio off
- Reachable only in the moments it chooses to poll
- Updates are scheduled around sleep, and resume after it
Part 2 exists to teach that discipline on the same desk, the same network and the same bulb, so the only new variable is the one that matters. The skill at its centre is power profiling: predicting a device's energy budget from a datasheet before it exists, measuring the real current properly (which on a development kit is its own skill: know what your header actually measures), and closing the gap between the two numbers until the prediction and the measurement agree. That loop, datasheet to budget to measurement to reckoning, is how battery products are actually engineered, quoted in job requirements, and almost never taught end to end. The skills in this course are the ones used to ship battery products that last years, not weeks.
And the budget is not decoration. Chapter 1 predicts about 13 µA average, about 1.7 years on the cell, as a labelled design target. Chapter 5 measures against it, Chapter 11 closes it with real numbers from your own bench, and every later chapter prices its feature in the same currency: polling intervals, debounce windows, even the LED blink that says "sent".
One remote, the whole battery discipline
A battery push-button controller on the nRF52840 DK: a Zigbee sleepy end device that joins the network Part 1 built, binds to the same IKEA bulb on its own endpoint, and drives its On/Off cluster (short press toggles, hold dims, through Level Control). It wakes from a GPIO interrupt, never from a polling loop; it classifies presses by timestamp; it measures its own supply with the SAADC and reports battery volts and percentage as standard ZCL Power Configuration attributes; it has a five-second-hold ship mode built on System OFF with GPIO sense wake; and it discovers, downloads and applies signed firmware updates on a wake schedule, resuming across sleeps, all before the finale takes it untethered onto a CR2032 in the DK's own holder.
The poll, up close
Data requests, parent buffering, and how frames reach a device that is usually deaf. (Chapter 4)
The device reports its own battery
SAADC to standard Power Configuration attributes. (Chapter 6)
Updates that survive naps
Block transfer across sleeps, resume, apply on wake. (Chapter 10)
What "advanced" means here, in the open
This is an advanced course, and the word is itemised rather than decorative. Some of it is core and hands-on; some is taught as far as it honestly goes on this hardware, and labelled that way, because Part 1's honesty rule about evidence applies to Part 2's claims too.
Core, built and measured
- End-device resilience: parent loss, rejoin, orphaning and recovery (Chapter 4)
- Retained RAM: what survives the deepest sleep, and what you do when the board gives you none (Chapter 8)
- APS frame counters, install codes and network key updates: the trust layer of a real deployment (Chapter 11)
- Press classes as a state machine: toggle, dimming, and the ship-mode hold, costed in microamps (Chapter 7)
Taught, with honest limits
- Touchlink commissioning: taught in Chapter 11, with a stretch exercise; it is a proximity phone-style flow that stays optional in most deployments, and the course says so
- Green Power: covered as a concept, with the reason stated plainly: Green Power proxy and sink infrastructure is beyond what this bench can honestly demonstrate
- Bench measurements: the course's own current figures are design targets until the author's hardware pass lands; your measurements on your bench are the course's real numbers, and the chapters are built around taking them
Real animations from inside the lessons
A sleepy device's life is timing: wakes, polls, naps, an update crossing the air in bursts between sleeps. The lessons animate those flows and hand you the controls. These three are the actual chapter animations, untouched: press play, or step through them frame by frame.
Press to light, in four moves
One poll cycle
Blocks at poll cadence
Chapter by chapter
Eleven chapters and a troubleshooting appendix. Total: about 30 to 36 hours of building, depending on your pace. One number runs through all of it: Chapter 1 predicts about 13 µA average; Chapter 5 measures against it; Chapter 11 closes the budget with your own numbers.
The sleepy end device: what changes when the battery is the boss
The always-on assumptions Part 1 let you keep, taken away one by one. The taxonomy (SED, MED, router), the energy budget built by hand before any instrument appears, and the number this course has to defend: about 13 microamps average.
Your first sleepy build
Start from the add-on’s light-switch SED sample and make the sleepy configuration real: the sysbuild snippet trap that silently skips low-power settings, and reading the built .config until sleep is proven, not assumed.
Buttons that do not burn the battery
The button wakes the device, the device polls its parent and sends an On/Off toggle to the same IKEA bulb by binding. Press-to-light latency becomes a defined, budgeted quantity, measured before it is believed.
Polling, parents, and staying joined
What a poll actually is (a MAC data request), long poll against fast poll, MAC indirect delivery, parent buffering and end-device aging: how a frame reaches a device that is usually deaf, and how not to orphan it.
Measure it: the budget meets reality
Power profiling done properly: what the P22 header on the DK actually measures, why SB40 comes out, what nRF ONLY mode proves, the difference between a floor reading and an average, and your measured average against Chapter 1’s prediction.
Battery health is a feature
The device measures its own supply with the SAADC and reports battery volts and percentage through the ZCL Power Configuration cluster, hourly, like a product. Includes a genuine upstream ZBOSS macro bug, found and worked around in the open.
Polish: dimming, feedback, and manners
Battery-context input engineering: debounce by timestamp in the only sane window, short and long press classification built on press duration, press-to-toggle versus hold-to-dim with Level Control, and LED feedback whose cost is stated, not free.
System OFF: the deepest sleep
The deepest sleep there is: System OFF with GPIO sense wake, exactly what survives in retained RAM, the DK’s missing retention region and what to do about it, the five-second-hold ship mode, and a full power-cycle rejoin that resumes polling and sending.
Sleepy OTA, part 1: an update that waits for naps
OTA re-thought for a device that is usually unreachable: the FOTA client on a sleepy endpoint, query and download intervals chosen from your energy budget, and a .zigbee package built with Part 1’s tooling for a new kind of consumer.
Sleepy OTA, part 2: download across sleeps, apply on wake
Downloads that survive naps: block transfer across sleeps, the reset-mid-download drill and resume, apply-on-wake with MCUboot underneath, rollback on an unconfirmed image, and the requested-upgrade behaviour that keeps the battery out of trouble.
Capstone: the untethered remote
Trust, then independence. Install codes and what they change at join time, APS frame counters and network key rotation, a structured failure drill across both courses, the final budget reckoning against Chapter 1, and the finale: CR2032 in, USB unplugged, verified from the coordinator shell and the sniffer alone.
Everything is a deliverable
- 11 hands-on labs: every lab builds in the pinned stack before publication, and the build log is quoted in the course. Measurements, the coin-cell finale and other physical steps are written as exact desk procedures in the lessons, labeled as such, for your own bench pass
- 100 quiz questions with full answer keys: self-check cards, graded as you go
- 17 diagrams, plus an animated diagram in every chapter: poll cycles, power paths, press classes, the sleepy OTA schedule
- A running energy budget: predicted in Chapter 1, measured in Chapter 5, closed in Chapter 11
- One public repo, exercise by exercise: github.com/learnbittoboard/zigbee-engineered-part2
- Stretch exercises: poll schedules pushed to their budget limit, touchlink, whole-board current accounting, ship-mode amnesia
- All 11 chapters, labs, quizzes and diagrams
- Lifetime access in the online player, nothing to install, read anywhere
- The full course repo, exercise by exercise
- Email support from the instructor
- Free updates to the course
Placeholder price for this preview build. Secure checkout opens at launch; the refund policy (14 days, no questions) will apply from day one.
Before you start
Part 2 continues Part 1's network, bulb and desk, so Part 1 comes first: you need its working network (coordinator plus at least one router) and its IKEA bulb. The hardware delta is one pack of CR2032 cells. Everything is built on the nRF52840 DK: its coin cell holder powers the untethered finale, so the DK is the platform the course completes on. A Nordic PPK2 is optional: the measurement chapters are written meter-agnostic, with a full path that needs only a multimeter.
What owners get
Buying the course is the start, not the whole deal. This is what's included with it, and the headline is a human being on the other end of an email.
Lifetime email support
Stuck on a poll interval, or a sleep current that will not come down? Email your question about the course to [email protected] and a working engineer answers, within 1 to 2 working days. Support covers questions about the course material and its labs. It is not general consulting, and it does not extend to debugging projects unrelated to the course. For as long as you own the course: no support tiers, no expiry, no ticket bot.
Animated diagrams
The moving parts (poll cycles, the press-to-light trip, blocks arriving at poll cadence, the untethered finale), taught as animations you play, pause and step through.
100 quiz questions, with answer keys
Every chapter ends in a self-check quiz with full answers, so you find the gaps while they're still cheap to fix.
The troubleshooting appendix
When it breaks. The field guide to this build's real failures: the silent snippet, the orphaned end device, the quietly tethered finale. Symptom, cause, fix, kept open beside the labs.
Exercise-by-exercise code
One public repo, one verified step at a time: the sleepy switch firmware growing chapter by chapter, exactly as the lessons build it.
More perks on the way
Owning a course here will keep getting better. More owner perks are in the works, and when they land, owners get them, free.
The switch, as a product
The device you build in this course lives on a development kit, headers and all. A finished version, an enclosed, battery powered Zigbee sleepy switch you can stick on a wall and use, is in development here as a Bit to Board product. Course owners will hear about it first.
No date, no price, nothing to pre-order. When it exists, it will be announced here and to the newsletter.
Before you ask
Do I need a PPK2?
No. The measurement chapters are written meter-agnostic, and there is a complete path that needs only a multimeter (the current-range series method on P22). The PPK2, or any proper current profiler, makes Chapter 5 easier and is used for the average-current work; if you buy one instrument for embedded power work, that is the one. But it is never a course requirement.
What new hardware do I need beyond Part 1?
A pack of CR2032 cells. That is the delta. Everything else (the DK, the dongle coordinator, the IKEA bulb, the sniffer) carries over from Part 1.
Do I really need Part 1 first?
Yes, as a working setup: Part 2's device joins Part 1's network and binds to Part 1's bulb, and Chapters 4 and 9 assume Part 1's endpoints and OTA machinery are familiar. The sleepy, power and measurement material itself is taught from zero.
Can I build it on a smaller board, like a XIAO?
The labs complete on the nRF52840 DK: its coin cell holder powers the untethered finale, and its headers and bridges are what the measurement chapters are written against. The firmware knowledge transfers to any nRF52840 board; the course's procedures, checkpoints and finale are DK procedures.