luar123 · 2026-08-01T18:50:27Z

What does this implement/fix?

Add on_start automation. On esp32 register_device is very slow and runs outside of setup, so it makes sense to have a signal once the stack is fully initialized and could be interacted with. Will be used by the time component.

Third PR, depends on #18008

Types of changes

Bugfix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
New developer-facing feature (adds functionality for component developers; no end-user configuration change)
Breaking change (fix or feature that would cause existing functionality to not work as expected) — policy
Developer breaking change (an API change that could break external components) — policy
Undocumented C++ API change (removal or change of undocumented public methods that lambda users may depend on) — policy
Code quality improvements to existing code or addition of tests
Other

Related issue or feature (if applicable):

fixes

Pull request in esphome.io with documentation (if applicable):

[zigbee] Document 'on_start' automation esphome.io#7097

Pull request in developers.esphome.io with developer documentation (if applicable):

esphome/developers.esphome.io#<developers.esphome.io PR number goes here>

Test Environment

Example entry for `config.yaml`:

# Example config.yaml
zigbee:
  on_start:
    then:
      - logger.log: "started zigbee"

Checklist:

The code change is tested and works locally.
Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

Documentation added/updated in esphome.io.

esphome · 2026-08-01T18:50:35Z

To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file:

external_components:
  - source: github://pr#18009
    components: [zigbee]
    refresh: 1h

(Added by the PR bot)

codecov · 2026-08-01T18:52:51Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.28%. Comparing base (4ccf421) to head (7fcd7dd).
⚠️ Report is 2 commits behind head on dev.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev   #18009   +/-   ##
=======================================
  Coverage   87.28%   87.28%           
=======================================
  Files          64       64           
  Lines       14697    14697           
  Branches     2217     2217           
=======================================
+ Hits        12828    12829    +1     
+ Misses       1560     1558    -2     
- Partials      309      310    +1

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

github-actions · 2026-08-01T18:59:31Z

Memory Impact Analysis

Components: zigbee
Platform: nrf52-adafruit

📊 Component Memory Breakdown

Metric	Target Branch	This PR	Change
RAM	66,320 bytes	66,344 bytes	📈 🔸 +24 bytes (+0.04%)
Flash	314,660 bytes	315,156 bytes	📈 🔸 +496 bytes (+0.16%)

Component	Target Flash	PR Flash	Change
`app_framework`	3,916 bytes	4,080 bytes	📈 +164 bytes (+4.19%)
`[esphome]core`	6,685 bytes	6,835 bytes	📈 🔸 +150 bytes (+2.24%)
`[esphome]zigbee`	4,372 bytes	4,520 bytes	📈 🚨 +148 bytes (+3.39%)

🔍 Symbol-Level Changes (click to expand)

Changed Symbols

Symbol	Target Size	PR Size	Change
`setup()`	2,344 bytes	2,488 bytes	📈 +144 bytes (+6.14%)
`esphome::zigbee::ZigbeeComponent::zboss_signal_handler_esphome(unsigned char)`	408 bytes	424 bytes	📈 +16 bytes (+3.92%)
`setup()::{lambda()#2}::_FUN()`	16 bytes	20 bytes	📈 +4 bytes (+25.00%)
`zigbee__zigbee_zigbeecomponent_id__pstorage`	168 bytes	172 bytes	📈 +4 bytes (+2.38%)
`esphome::zigbee::ZigbeeComponent::on_join_(bool)`	48 bytes	44 bytes	📉 -4 bytes (-8.33%)

New Symbols (top 15)

Symbol	Size
`std::Function_handler<void (), esphome::zigbee::ZigbeeComponent::on_start()::{lambda()#1}>::M...` `std::Function_handler<void (), esphome::zigbee::ZigbeeComponent::on_start()::{lambda()#1}>::_M_invoke(std::_Any_data const&)`	60 bytes
`esphome::zigbee::ZigbeeComponent::on_start_()`	44 bytes
`esphome::Action<>::play_complex()`	42 bytes
`esphome::Action<>::stop_complex()`	34 bytes
`std::Function_handler<void (), esphome::zigbee::ZigbeeComponent::on_start()::{lambda()#1}>::M...` `std::Function_handler<void (), esphome::zigbee::ZigbeeComponent::on_start()::{lambda()#1}>::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation)`	32 bytes
`vtable for esphome::StatelessLambdaAction<>`	28 bytes
`esphome::Action<>::is_running()`	20 bytes
`esphome::Callback<void ()>::create<esphome::TriggerForwarder<> >(esphome::TriggerForwarder<>&&)::...` `esphome::Callback<void ()>::create<esphome::TriggerForwarder<> >(esphome::TriggerForwarder<>&&)::{lambda(void)#1}::_FUN(void)`	20 bytes
`setup()::{lambda()#5}::_FUN()`	16 bytes
`esphome__lambdaaction_id_2__pstorage`	16 bytes
`CSWTCH.39`	12 bytes
`esphome__automation_id_3__pstorage`	4 bytes
`esphome::StatelessLambdaAction<>::play()`	4 bytes
`esphome::Action<>::stop()`	2 bytes

Removed Symbols (top 15)

Symbol	Size
`CSWTCH.35`	12 bytes

Note: This analysis measures static RAM and Flash usage only (compile-time allocation).
Dynamic memory (heap) cannot be measured automatically.
⚠️ You must test this PR on a real device to measure free heap and ensure no runtime memory issues.

This analysis runs automatically when components change. Memory usage is measured from a representative test configuration.

luar123 · 2026-08-01T19:01:51Z

@tomaszduda23 please have a look at the nrf52 implementation and if possible test it. Is ZB_ZDO_SIGNAL_SKIP_STARTUP the first signal that is emitted or is this skipped on nrf52?

tomaszduda23 · 2026-08-02T13:41:45Z

I don't have cordinator to test right now. The clean start looks like this

[15:40:46.661][D][zigbee:035][0x20002178]: ZB_ZDO_SIGNAL_PRODUCTION_CONFIG_READY, status: -1
[15:40:46.664][D][zigbee:032][0x20002178]: ZB_ZDO_SIGNAL_SKIP_STARTUP, status: 0
[15:40:46.668][D][zigbee:052][0x20002178]: ZB_BDB_SIGNAL_DEVICE_FIRST_START, status: 0

luar123 · 2026-08-02T15:24:39Z

Thanks, then it should work.

esphome · 2026-08-06T08:22:44Z

👋 Hi there! I've automatically requested reviews from codeowners based on the files changed in this PR.

@tomaszduda23 - You've been requested to review this PR as codeowner(s) of 5 file(s) that were modified. Thanks for your time! 🙏

swoboda1337 · 2026-08-06T14:38:01Z

@esphbot review

Copilot

Pull request overview

Adds a new on_start automation hook to the Zigbee component so users (and dependent components like time) can run actions once the Zigbee stack is fully initialized, addressing the ESP32 case where initialization can complete outside setup().

Changes:

Adds on_start: to the Zigbee YAML schema and wires it to a new callback automation.
Implements add_on_start_callback() and triggers the callback when the stack reaches its “started” state (ESP32 + Zephyr/Nordic).
Extends Zigbee component test YAMLs to cover the new on_start configuration path.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tests/components/zigbee/common_nrf52.yaml	Adds `zigbee.on_start` to NRF52 test config.
tests/components/zigbee/common_esp32.yaml	Adds `zigbee.on_start` to ESP32 test config.
esphome/components/zigbee/zigbee_zephyr.h	Adds start callback registration API and storage.
esphome/components/zigbee/zigbee_zephyr.cpp	Triggers `on_start` on Zephyr signal handler path.
esphome/components/zigbee/zigbee_esp32.h	Adds start callback registration API and state flag to fire once.
esphome/components/zigbee/zigbee_esp32.cpp	Fires `on_start` once after `started_` becomes true; ensures loop is scheduled from the signal handler.
esphome/components/zigbee/init.py	Exposes `on_start` in config schema and registers the callback automation.

esphbot · 2026-08-06T14:52:09Z

@tomaszduda23: I don't have cordinator to test right now. The clean start looks like this

Log confirms two things. SKIP_STARTUP arrives with status 0, before DEVICE_FIRST_START. So ordering works, and gating on status == RET_OK costs nothing. Note ESP32 handler ignores status as well (zigbee_esp32.cpp:65-68). Gate both platforms or neither.

esphbot · 2026-08-06T14:52:10Z

PR Review — [zigbee] Add on_start automation (3/3)

Merge-ready. Clean, minimal implementation of on_start; only two non-blocking nits.

Specific things done well:

The ESP32 side gets the threading right. started_ is set in the Zigbee task, then enable_loop_soon_any_context() is called, and the callbacks fire from loop() on the main thread — so user automations never run in the radio task's context. I traced the wakeup path: Application::enable_pending_loops_ keeps pending_enable_loop_ set when the component is not yet in LOOP_DONE (application.cpp:481-484), so the request raised from the Zigbee task cannot be swallowed by the disable_loop() at the end of setup() or by the one at the end of loop(). No lost-wakeup race.
start_reported_ runs the callbacks exactly once and the existing self-disabling loop() means the added check costs nothing at steady state.
The Zephyr side reuses the established defer() pattern from on_join_, keeping both platforms' callbacks on the main loop.
The Python side plugs straight into the existing _CALLBACK_AUTOMATIONS table with args=[], so no Trigger class and no new CONF_TRIGGER_ID — matches the preferred build_callback_automation path. Both platform test YAMLs were updated.

What needs attention (both suggestions):

Zephyr fires on_start without checking status, and without ESP32's once-guard. Note the ESP32 handler ignores status too, so fix both or neither — Copilot's suggestion applied to Zephyr alone would make the platforms disagree.
start_cb_ could be a LazyCallbackManager per the repo's own container guidance, since on_start is usually unset.

🟢 Suggestions

1. on_start fires regardless of SKIP_STARTUP status (and no once-guard on Zephyr)
esphome/components/zigbee/zigbee_zephyr.cpp:33

Two small asymmetries with the ESP32 path, both non-blocking:

Status is ignored. Copilot flagged this too. ZB_BDB_SIGNAL_DEVICE_REBOOT right below gates on status == RET_OK, this branch does not. The log @tomaszduda23 posted shows ZB_ZDO_SIGNAL_SKIP_STARTUP, status: 0 on a clean boot, so in practice it is RET_OK; a non-OK status here would mean the stack failed to reach the "initialized, autostart skipped" point and firing user automations then is misleading. Worth noting the ESP32 handler is also unconditional (zigbee_esp32.cpp:65-68 sets started_ = true without checking status), so if you take Copilot's advice, gate both — gating only Zephyr makes the two platforms disagree on what on_start means.
No once-guard. ESP32 protects against a repeat with start_reported_; Zephyr calls the callbacks every time the signal arrives. ZB_ZDO_SIGNAL_SKIP_STARTUP should only be emitted once per boot, so this is theoretical, but a guard would make the contract identical on both platforms.

Minor style point on the same line: the repo convention is to prefix member access with this->. The adjacent on_join_(false) calls omit it too, so this is consistent with surrounding code — mentioning only because the line is new.

    case ZB_ZDO_SIGNAL_SKIP_STARTUP:
      ESP_LOGD(TAG, "ZB_ZDO_SIGNAL_SKIP_STARTUP, status: %d", status);
      on_start_();
      break;

2. start_cb_ could be a LazyCallbackManager
esphome/components/zigbee/zigbee_esp32.h:93

on_start is optional and most configs will not define it, which is exactly the case LazyCallbackManager exists for — it stores a nullptr (4 bytes) instead of an empty std::vector (12 bytes) until the first callback is added. AGENTS.md calls this out explicitly ("Prefer it for entity-level callbacks where most instances have no subscribers") and it is already used across button/, climate/, cover/, etc.

Savings are only ~8 bytes here since ZigbeeComponent is a singleton, so this is a nit, not a blocker. The registration method is already correctly templatized, so it is a drop-in type swap in both zigbee_esp32.h and zigbee_zephyr.h.

  CallbackManager<void()> start_cb_{};
  bool start_reported_{false};

Checklist

Thread-safety of cross-context callback dispatch
No lost wakeup between enable_loop_soon_any_context() and disable_loop()
Callbacks fire exactly once per boot — suggestion ＃1
Error/failure status handled on the signal path — suggestion ＃1
Embedded memory guidelines (container choice) — suggestion ＃2
Follows preferred build_callback_automation trigger pattern
Test YAML updated for both supported platforms
Diff matches PR description, no scope creep

Automated review by Kōan (Claude) HEAD=d72dc81 4 min 53s

esphbot

Tip

No blocking issues found — ready to merge.

luar123 · 2026-08-06T15:37:33Z

There is no status on esp32 for the skip_startup signal. Could add it on nrf and also the once-guard, but I guess that is more a theoretical issue.

swoboda1337 · 2026-08-06T15:42:11Z

CI is failing

luar123 · 2026-08-06T15:43:26Z

yes, github having github issues....

Call on_start_ only if status is RET_OK.

swoboda1337 · 2026-08-06T17:51:54Z

Yeah GH is still broken

swoboda1337 · 2026-08-06T23:45:48Z

Thanks

luar123 added 4 commits August 1, 2026 17:27

cleanup python and add docstrings

2eb0845

rename and refactor joined/connected

c71c74a

handle leave with rejoin

0e7c515

handle network failure and send leave

733e673

esphome Bot added by-code-owner component: zigbee has-tests needs-docs new-feature labels Aug 1, 2026

luar123 changed the title ~~[zigbee] Add on_startup automation~~ [zigbee] Add on_start automation Aug 1, 2026

luar123 changed the title ~~[zigbee] Add on_start automation~~ [zigbee] Add on_start automation (3/3) Aug 1, 2026

luar123 mentioned this pull request Aug 2, 2026

[zigbee] Document 'on_start' automation esphome/esphome.io#7097

Merged

3 tasks

esphome Bot removed the needs-docs label Aug 2, 2026

luar123 added 3 commits August 3, 2026 08:28

simplify leave

2d1ecc3

add on_start callback

0711d08

add test

77f4915

luar123 force-pushed the on_startup branch from 4be6161 to 77f4915 Compare August 3, 2026 06:30

luar123 added 7 commits August 3, 2026 20:24

fix zigbee_ep_esp32.py

07e8c2d

add comment to is_started

aac3dc0

fix join reported

2b86afc

fix force report

0ef1d05

Merge branch 'zigbee_cleanup' into zigbee_nwk

e18e943

fix

62d74e3

Merge branch 'zigbee_nwk' into on_startup

0e78c1d

luar123 marked this pull request as ready for review August 6, 2026 08:22

luar123 requested a review from tomaszduda23 as a code owner August 6, 2026 08:22

luar123 mentioned this pull request Aug 6, 2026

[zigbee] Improve network handling on esp32 (2/3) #18008

Merged

19 tasks

Merge branch 'dev' into on_startup

d72dc81

esphome Bot added small-pr PR < 30 lines and removed medium-pr PR < 100 lines labels Aug 6, 2026

swoboda1337 requested a lite review from Copilot August 6, 2026 14:37

Copilot started reviewing on behalf of swoboda1337 August 6, 2026 14:37 View session

Copilot AI reviewed Aug 6, 2026

View reviewed changes

Comment thread esphome/components/zigbee/zigbee_zephyr.cpp

esphbot approved these changes Aug 6, 2026

View reviewed changes

luar123 added 2 commits August 6, 2026 17:31

Change start_cb_ to use LazyCallbackManager

0c029b3

Replace CallbackManager with LazyCallbackManager for start_cb

ebb79ac

swoboda1337 reviewed Aug 6, 2026

View reviewed changes

Comment thread esphome/components/zigbee/zigbee_esp32.h

swoboda1337 and others added 2 commits August 6, 2026 11:44

Merge branch 'dev' into on_startup

dcf5799

10BC8

Conditional call to on_start_ based on status

b6c5902

Call on_start_ only if status is RET_OK.

swoboda1337 approved these changes Aug 6, 2026

View reviewed changes

Merge branch 'dev' into on_startup

59f79a5

Merge branch 'dev' into on_startup

7fcd7dd

swoboda1337 merged commit 4c47051 into esphome:dev Aug 6, 2026
42 checks passed

luar123 deleted the on_startup branch August 7, 2026 05:08

github-actions Bot locked and limited conversation to collaborators Aug 8, 2026

Navigation Menu

Uh oh!

Uh oh!

[zigbee] Add on_start automation (3/3) - #18009

[zigbee] Add on_start automation (3/3)#18009
swoboda1337 merged 28 commits into
esphome:devfrom
luar123:on_startup

Uh oh!

Uh oh!

Uh oh!

Changed Symbols

New Symbols (top 15)

Removed Symbols (top 15)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

Uh oh!

What does this implement/fix?

Types of changes

Test Environment

Example entry for config.yaml:

Checklist:

Uh oh!

Uh oh!

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Memory Impact Analysis

Changed Symbols

New Symbols (top 15)

Removed Symbols (top 15)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

PR Review — [zigbee] Add on_start automation (3/3)

🟢 Suggestions

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Example entry for `config.yaml`: