Fixes for issues with Device Groups

[NorthernMan54]

Finally after 3 years looked into why the device groups worked inconsistenttly and compared the implementation to the reference implementation and found a couple of gaps.

The smoking gun was that devgroupstatus never listed the OpenBK devices, so this resolves that issue and the inconsistency while using it.

[openshwprojects]

Nice, tested, ready for merge? @divadiow can u check?

[NorthernMan54]

My local testing has been flawless for 24 hours now, so this should be good to go.

Tasmota wall switch controlling OpenBK pot lights. On/Off, colour and brightness.

[divadiow]

to this day I haven't experimented with device groups :o

lazy GPT review of PR :)

-Do not call DGR_CheckSequence() for ACKs. Use acked_sequence for ACK state, and keep it separate from received-message duplicate detection.
-ACKs should be unicast to the packet sender, or reliability/ACK behaviour should not be added yet. Reusing the multicast send queue for ACKs is wrong.
-Use bit tests for status request handling, not flags == 2.
-Respond to status requests with a full status packet, or remove the misleading “handshake protocol” framing and keep this PR scoped to announcements/member visibility.
-Start discovery on successful init, not only during socket retry, if discovery is intended.
-Consider increasing msgbuf to at least 128, preferably matching the send queue/message maximum, and fix the msgbuf[nbytes] = '\0' edge case.

I can post the full details if any of these warrant further investigation

[divadiow]

pr_review.txt

[NorthernMan54]

Tks, will pass along to Claude

[NorthernMan54]

@divadiow Can you run it thru ChatGPT again, it should come back clean this time.

[divadiow]

sure.

I have a 'suggested response' :)

This is much improved and it fixes several of the earlier protocol concerns: ACKs are now unicast, ACKs no longer go through normal received-sequence handling, status requests are checked as a flag, receive buffer sizing is safer, and initial discovery now starts after successful init.

I still think this needs a small follow-up before merge:

1. g_dgr_next_announcement_time is set to 0xFFFFFFFF during init discovery, but I don't see it being reset when discovery finishes. That appears to suppress periodic announcements after normal startup until tick wrap/max.

2. DRV_DGR_SendFullStatus() is currently only sending channel 1 power state with DGR_FLAG_FULL_STATUS. That is not really full status for multi-relay/light devices and also bypasses the existing channel-offset detection used elsewhere.

3. ACKs are handled before checking whether groupName matches our configured group, so an ACK for another group can still update member ACK state.

4. Both DGR_AddToSendQueue() and the new DGR_AddToUnicastSendQueue() can return while holding g_mutex if the queue is full. The multicast version was already like this, but the new unicast path duplicates it and the extra ACK/status traffic makes queue exhaustion more plausible.

I would be happy with this after those are addressed, or if the full-status function is explicitly documented as a minimal power-only response rather than full protocol parity.

[divadiow]

not meant to be shouty. formatting fail

[divadiow]

pr_2145_remaining_problems.txt