Add boot improvements and version sensors

[bharvey88]

Summary

Adds diagnostic text sensors and connection status indication during boot sequence.

Changes

• Text Sensors: Added ESPHome Version and Apollo Firmware Version sensors for diagnostics
• Connection Status: Added statusCheck script matching BTN-1 implementation
  • Blue light (5s): Connected to Home Assistant
  • Green light (5s): Connected to WiFi only
  • Yellow light (5s): Not connected
• Boot Sequence: Updated to show connection status before hardware test
• Cleanup: Removed redundant white startup blink

Testing Status

Ready for local testing and validation on hardware.

Files Modified

• Core.yaml - Added text sensors and statusCheck script
• MTR-1.yaml - Updated boot sequence
• MTR-1_BLE.yaml - Updated boot sequence
• MTR-1_Factory.yaml - Updated boot sequence

Summary by CodeRabbit

• New Features

  • Two text sensors added for ESPHome and device firmware versions.
  • New statusCheck and diagnosticCheck scripts to indicate connection state via RGB status and run diagnostic sequences; Boot Status LED switch added to control boot-status behavior.
  • Short button press now triggers a diagnostic check.

• Chores

  • Boot/connect sequencing adjusted so status checks run reliably on first boot and reconnects.

[coderabbitai]

Walkthrough

Added boot-status globals, new diagnostic text sensors, a Boot Status LED switch, statusCheck and diagnosticCheck scripts, an api.on_client_connected handler, and updated device on_boot/wifi connect sequences to run statusCheck on first boot when enabled.

Changes

Cohort / File(s)	Summary
Core — Integrations/ESPHome/Core.yaml Integrations/ESPHome/Core.yaml	Added globals first_boot_done (bool, initial false, no restore) and boot_status_enabled (bool, initial true, restore yes). Added api.on_client_connected handler (1s delay) to run statusCheck. Added text_sensor entries (ESPHome Version, Apollo Firmware Version). Added switch template for Boot Status LED controlling boot_status_enabled. Added script entries statusCheck and diagnosticCheck (connectivity checks, RGB control, delays) and exposed them as public. Adjusted button diagnostic threshold logic to 2000ms and diagnosticCheck invocation.
Device configs — on_boot / wifi connect Integrations/ESPHome/MTR-1.yaml, Integrations/ESPHome/MTR-1_BLE.yaml, Integrations/ESPHome/MTR-1_Factory.yaml	Changed esphome.on_boot.priority from -10 to 600. Added wifi.on_connect / wifi.ap.on_connect sequences with delay: 10s and an if guard !id(first_boot_done) && id(boot_status_enabled) that sets id(first_boot_done)=true and executes statusCheck.

Sequence Diagram(s)

sequenceDiagram
    participant Device as Device (on_boot / wifi.on_connect)
    participant API as API (on_client_connected)
    participant Script as Script (`statusCheck`)
    participant HA as HomeAssistant (ink_ha_connected)
    participant WiFi as WiFi (wifi.connected)
    participant RGB as RGB Light (rgb_light)

    Device->>API: on_client_connected / client connects
    API->>Script: delay 1s\nexecute statusCheck
    Script->>HA: check ink_ha_connected
    Script->>WiFi: check wifi.connected
    alt HA connected
        Script->>RGB: set color rgba(0,128,255,0.5)
    else WiFi only
        Script->>RGB: set color rgba(0,128,0,0.5)
    else neither
        Script->>RGB: set color rgba(255,165,0,0.5)
    end
    Script->>Script: delay 5s
    Script->>RGB: turn off

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Suggested labels

bugfix

Suggested reviewers

• TrevorSchirmer

Poem

🐰 I nudged the boot flag, sniffed the air so bright,
I blinked blue for the host and green for Wi‑Fi light.
Amber if lonely, five seconds then dim —
I’m a hopping little rabbit, testing each limb.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main changes: boot sequence improvements and version sensor additions, covering the primary objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fw-boot-improvements

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@Integrations/ESPHome/MTR-1.yaml`:
- Around line 12-15: The on_boot trigger is running statusCheck before WiFi is
connected (so it always reports "not connected"); replace the on_boot block with
the WiFi component's on_connect trigger so statusCheck runs after connection is
established — locate the on_boot block that executes script.execute: statusCheck
and change it to an on_connect trigger under the WiFi component (using
on_connect then: - script.execute: statusCheck), ensuring the statusCheck script
is invoked only after WiFi connects.

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

Integrations/ESPHome/MTR-1.yaml (1)

12-19: ⚠️ Potential issue | 🟠 Major

Boot test shows LED before status check due to timing, inverting the desired LED sequence when status is enabled.

On boot (priority 600), testScript executes immediately if runTest is true. However, statusCheck only runs later when WiFi or API connects and only on first connection (guarded by first_boot_done and boot_status_enabled). This means the test LED displays before the status LED, which conflicts with the intent to show connection status before hardware diagnostics. When boot_status_enabled is true, use diagnosticCheck instead—it explicitly runs status first, then the test.

Suggested adjustment

   on_boot:
     priority: 600
     then:
       - if:
           condition:
             - lambda: "return id(runTest);"
           then:
             - if:
                 condition:
                   - lambda: "return id(boot_status_enabled);"
                 then:
                   - script.execute: diagnosticCheck
                 else:
                   - script.execute: testScript

Integrations/ESPHome/MTR-1_Factory.yaml (1)

12-19: ⚠️ Potential issue | 🟠 Major

Gate testScript execution on boot_status_enabled to sequence connection status before hardware test.

When both runTest and boot_status_enabled are true, testScript runs immediately on boot while statusCheck attempts to run ~10 seconds later on WiFi connect. This causes LED display conflicts since both scripts control the RGB light independently. The intended sequence is to show connection status first, then run the hardware test.

Use diagnosticCheck when boot_status_enabled=true to ensure statusCheck (connection LED) runs before testScript (test result LED):

Suggested adjustment

   on_boot:
     priority: 600
     then:
       - if:
           condition:
             - lambda: "return id(runTest);"
           then:
-            - lambda: "id(testScript).execute();"
+            - if:
+                condition:
+                  - lambda: "return id(boot_status_enabled);"
+                then:
+                  - script.execute: diagnosticCheck
+                else:
+                  - script.execute: testScript