[JYMatanki]

Reason for change: Add RBUS event publishing for active Wi-Fi / POD client presence. Guard low-power functionality with LPM_MANAGER_SUPPORT.

Test Procedure: Validate by no clients connected, atleast one WiFi client, atleast one POD client and confirm the LPM state changes as expected
Risks: Medium
Priority: P1

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

1 out of 2 committers have signed the CLA.
✅ snayak002c
❌ JYMatanki
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[Copilot]

🟡 Changes recommended

Presence reporting can incorrectly indicate no clients, and reconnecting subscribers can miss their initial state.

3 open issues

• Treat unreadable backhaul counts as unknown, not zero · New
• Include XlmHosts clients when checking active Wi-Fi devices · New
• Publish initial state for new subscriptions · New

What changed in this PR

Adds Wi-Fi client presence reporting to LM Lite for Eco Mode under LPM_MANAGER_SUPPORT.

Changes:

• Registers an RBUS presence event with GET and subscription handlers.
• Detects active Wi-Fi/MLO clients and queries mesh backhaul counts.
• Publishes initial presence and subsequent changes when low-power support is enabled.

File	Description
source/​lm/​lm_rbus_api.h	Declares presence event APIs.
source/​lm/​lm_rbus_api.c	Implements event registration, handlers, and publication.
source/​lm/​lm_main.h	Declares the presence getter and includes Boolean support.
source/​lm/​lm_main.c	Adds presence detection and periodic publication.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Presence reporting can miss XHS clients in resource-optimized builds and leave subscribers with stale state after entering bridge mode.

No open issues 🎉

2 previously missed issues

In code that hasn't changed since last review

Optimized builds miss XHS-only Wi-Fi clients

source/​lm/​lm_main.c:2916

With both LPM_MANAGER_SUPPORT and RESOURCE_OPTIMIZATION enabled, an XHS-only connection is reported as no active Wi-Fi clients. Wifi_ServerSyncHost() routes SSID 3/4 updates into a branch compiled out in optimized builds (lines 3950–4087), so these clients are absent from lmHosts as well as XlmHosts. The remaining fallback checks only backhaul APs 13/14. Both GET and published events can therefore report false while an XHS client is connected. Query the XHS association counts directly in optimized builds, or retain minimal XHS association tracking, before reporting absence.

Bridge mode skips publication after host removal

source/​lm/​lm_main.c:3150

The publisher runs only in the non-bridge branch. If true was published before entering bridge mode, the bridge branch clears lmHosts with Hosts_RmHosts() but never calls the publisher while bridge mode remains active. With no XHS clients or pods, GET then returns false while an existing subscriber receives no update and can retain true indefinitely. The consumer's initial GET after subscribing does not cover this later transition. Move the low-power publication check outside the bridge/non-bridge conditional so it also observes host removal.

3 resolved since last review

• Treat unreadable backhaul counts as unknown, not zero
• Publish initial state for new subscriptions
• Include XlmHosts clients when checking active Wi-Fi devices

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

POD-only transitions lack notification triggers, and concurrent host updates can publish stale absence states.

2 open issues

• POD presence changes are not published without periodic polling · New
• XHS presence snapshots can publish stale state out of order · New

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Host-table teardown leaves stale client counts, causing incorrect presence reporting after bridge-mode transitions.

3 open issues

• Fix helper call and aggregate XHS client activity
• XHS presence snapshots can publish stale state out of order
• Publish active state when Wi-Fi client count remains nonzero

1 previously missed issue

In code that hasn't changed since last review

Reconcile active-client count during host-table teardown

source/​lm/​lm_main.c:3185

[P2] The new counter is never reconciled when the bridge-mode path calls Hosts_RmHosts(), which deletes the main host table without running active-state transitions. If Wi-Fi clients were active before that cleanup, returning to router mode leaves a positive count even with no clients or pods; subsequent connects/disconnects retain the stale offset. Reconcile the counter during host-table teardown/rebuild while preserving any XHS contribution, or derive presence from the current host tables instead.

1 resolved since last review

• Remove stray plus causing LPM branch compilation failure

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Incorrect XHS reporting, stale client counts, and publication races can provide unreliable presence information to the low-power manager.

4 open issues

• Fix helper call and aggregate XHS client activity
• XHS presence snapshots can publish stale state out of order
• Update shared count for XHS transitions instead of publishing stale state · New
• Publish active state when Wi-Fi client count remains nonzero

2 previously missed issues

In code that hasn't changed since last review

Reconcile active-client count when clearing hosts

source/​lm/​lm_main.c:232

Hosts_RmHosts() clears the host table during bridge mode without decrementing or resetting this counter. After router mode resumes, rebuilding the table can count clients again, leaving a positive total even after every client disconnects and indefinitely reporting presence. Reconcile the counter when hosts are removed, under the appropriate locks, while preserving any separately tracked XHS clients.

Prevent stale polling results from overwriting newer publications

source/​lm/​lm_main.c:3193

After polling reads zero clients and releases the count mutex, a Wi-Fi connection can publish true while the pod query runs; the poll can then overwrite it with its stale false result. LpmPublishMutex serializes publications but not their snapshots, so consumers can see false absence until the next poll. Coordinate sampling with publication, or use a state generation to discard outdated observations before publishing.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Presence-accounting errors and a publication race can leave LPM Manager with incorrect client presence and cause inappropriate low-power decisions.

7 open issues

• Reset active client count when clearing host tables · New
• Publish active presence when remaining Wi-Fi clients exist · New
• Synchronize presence sampling with publication · New
• Fix helper call and aggregate XHS client activity
• XHS presence snapshots can publish stale state out of order
• Update shared count for XHS transitions instead of publishing stale state
• Publish active state when Wi-Fi client count remains nonzero

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The supplied review evidence identifies unresolved presence-tracking and notification errors that can leave the low-power manager out of sync with actual connectivity.

6 open issues

• Publish active presence when remaining Wi-Fi clients exist
• Reset active client count when clearing host tables
• Fix helper call and aggregate XHS client activity
• XHS presence snapshots can publish stale state out of order
• Update shared count for XHS transitions instead of publishing stale state
• Publish active state when Wi-Fi client count remains nonzero

1 resolved since last review

• Synchronize presence sampling with publication

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Presence reporting can remain incorrect because last-POD disconnects are not published, bridge-mode host removal leaves stale counts, and concurrent updates can publish outdated state.

1 open issue

• Reset active client count when clearing host tables

2 resolved since last review

• Publish active presence when remaining Wi-Fi clients exist
• Update shared count for XHS transitions instead of publishing stale state

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

With RESOURCE_OPTIMIZATION disabled, resetting the combined Wi-Fi/XHS counter while XHS entries remain active can cause later Wi-Fi events to falsely report that no clients are active.

1 open issue

• Preserve XHS count when resetting combined Wi-Fi counter · New

1 resolved since last review

• Reset active client count when clearing host tables

_{Review effort: Balanced}