#27: Fix CDR_ZWPv2IndicatorCCRequirements_Rev01

[Aydogan Ersoz (silabs-aydogane)]

Issue

• Fix CDR_ZWPv2IndicatorCCRequirements_Rev01 #27
• JIRA: ZWAVE_SDK-2038

Closes: #27

Change

Must be merged after #56.

• Publish an MQTT IndicatorSet message when ZPC receives an Indicator Set command.
• Store Indicator Get/Set data on the ZPC endpoint node instead of the source endpoint. ZPC is the DUT so the data must live under ZPC's own node.
• Ignore logs/, ci-logs/, and tmp/ in .gitignore.

MQTT handler wait is in #56.

Checklist

• Pull request template has been filled out correctly
• ./ci/scripts/clang-tidy.sh check has been run locally (see CONTRIBUTING.md)
• Documentation has been updated if necessary
• A Contribution License Agreement has been established between Silicon Labs (@SiliconLabs) and author's company (matching email domain)

[cursor]

PR Summary

Low Risk
Localized Indicator command-class and MQTT reporting changes with stricter endpoint validation; no auth or broad architectural impact.

Overview
When the ZPC handles an incoming Indicator Set (support path), it now emits an MQTT report so integrators can observe the command without polling the attribute store.

After persisting the set into the indicator report group, on_indicator_set_support_received calls new publish_indicator_set_received, which builds a JSON payload (indicator_0_value, properties1.indicator_object_count, and vg1 entries as hex strings) and publishes to {baseTopic}{commandClass}/Report/IndicatorSet.

Indicator get/set support handling also resolves the endpoint via get_zpc_endpoint_id_node from the local connection endpoint instead of command_class_utils::get_endpoint_node, and returns SL_STATUS_FAIL when that node is invalid.

^{Reviewed by Cursor Bugbot for commit d935458. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 09e0cfd. Configure here.}

[cursor]

Current version of PR was reviewed by /review-bugbot on Aug 31, 11:59 GMT+2. It flagged 0 findings.

^{Bugbot on commit 76fb590 is skipped.}

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3586/

[Aydogan Ersoz (silabs-aydogane)]

bugbot run

[cursor]

Current version of PR was reviewed by /review-bugbot on Aug 31, 11:59 GMT+2. It flagged 0 findings.

^{Bugbot on commit 76fb590 is skipped.}

[cursor]

Current version of PR was reviewed by /review-bugbot on Aug 31, 11:59 GMT+2. It flagged 0 findings.

^{Bugbot on commit ebeff6d is skipped.}

[cursor]

Current version of PR was reviewed by /review-bugbot on Aug 31, 11:59 GMT+2. It flagged 0 findings.

^{Bugbot on commit 7f1c1fc is skipped.}

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3589/

[Aydogan Ersoz (silabs-aydogane)]

Claude AI reasoning:

Old code:

while (auto msg = publish_queue.try_pop()) { ... }  // drain whatever is there RIGHT NOW
...
if (!processed_any) {
    sleep_for(100ms);  // blind sleep, no way to be woken early
}

try_pop() checks the queue once, takes everything that is already there, and returns immediately with nothing if the queue is empty. It never waits. So if the queue is empty at that moment, the thread falls through to sleep_for(100ms) which is a dumb timer with no connection to the queue.

When publish() is called on another thread during that sleep, the message sits in the queue. The handler thread has no idea. It wakes up only when the 100 ms timer expires, then calls try_pop() again and finally processes the message.

New code:

if (auto msg = publish_queue.pop(100)) { ... }  // blocks until something arrives OR 100ms pass

pop(timeout) goes to sleep on the queue's own condition variable. push() always calls notify_one() on that same condition variable. So the handler thread wakes up the moment publish() pushes a message and not after the timer.

The while loop in the old code looked like it was "waiting" but it was only draining what was already there. The actual wait was the sleep_for at the bottom, which was deaf to new arrivals.

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3609/

[Peter Balogh (silabs-peterb)]

After this MQTT component change a stress test would be nice. Even locally.

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3613/

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3618/

[Aydogan Ersoz (silabs-aydogane)]

After this MQTT component change a stress test would be nice. Even locally.

I abandoned that change.

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3625/

[Tamás Fraknói (tamas-fraknoi)]

CTT test CDR_ZWPv2IndicatorCCRequirements_Rev01 now passes.