Sonance fixes

[haklai]

Sonance C4630 SE: fix EQ commands, response regex, and multi-query zone status

Tested on Sonance C4630 SE (6-zone). Three bugs prevented EQ and volume
status from working correctly with this amplifier.

Changes

pyxantech/series/sonance6.yaml

Add min_bass, min_treble, min_balance to the device config. The
max values were already present but the min values were missing, causing
get_device_config() to return None for EQ minimums and the clamping
logic to silently floor at 0.

pyxantech/__init__.py

Fix EQ command clamping: _set_bass_cmd, _set_treble_cmd,
_set_balance_cmd all hardcoded 0 as the minimum. They now read
min_bass/min_treble/min_balance from device config (falling back
to 0, so all other amp types are unaffected).

pyxantech/protocols/sonance.yaml — three fixes:

1. Signed EQ commands: set_bass/set_treble/set_balance used
   {value:02} which cannot represent negative numbers. Changed to
   {value:+03d} so negative values produce :L1-05 instead of
   garbage.

2. Multi-query zone status: :Z{zone}? only returns power state on
   Sonance — not volume, source, mute, or EQ. Added zone_status_queries
   list; __init__.py now sends separate queries for each attribute and
   merges the results into one ZoneStatus. Non-Sonance amp types are
   unaffected (no zone_status_queries defined in their protocol).

3. Response regex fixes:

   • Volume: \+V(?P<zone>\d+)(?P<volume>\d+) was greedy — +V460
     matched as zone=46, volume=0. Fixed by restricting zone group to
     [1-6].
   • Bass/treble/balance: patterns had spurious BS/TR/BA literals
     that don't appear in actual responses (device sends +L1+5, not
     +L1BS+5). Removed. Capture groups now match signed values with
     [+-]?\d+.

Affected hardware

• Sonance C4630 SE (6-zone)
• Sonance 875D MKII (4-zone, same protocol — unverified)

Other amp types (xantech8, monoprice6, dax88, zpr68) are unaffected:
the zone_status_queries path is only taken when the protocol config
defines that key, and their EQ min-value fallback is 0 as before.

[mesa-dot-dev]

Mesa Description

TL;DR

Fixes multiple bugs in the Sonance amplifier protocol, specifically related to EQ command formatting, response parsing, and multi-query zone status retrieval, ensuring correct functionality for Sonance C4630 SE and similar devices.

What changed?

• pyxantech/series/sonance6.yaml: Added min_balance, min_bass, and min_treble limits to the device configuration.
• pyxantech/__init__.py:
  • Modified EQ command clamping functions (_set_bass_cmd, _set_treble_cmd, _set_balance_cmd) to read minimum values from the device config.
  • Implemented multi-query zone status retrieval via new _zone_status_query_commands and _merge_zone_status_responses functions, updating synchronous and asynchronous zone_status methods.
• pyxantech/protocols/sonance.yaml:
  • Updated set_bass, set_treble, and set_balance commands to use {value:+03d} for signed, three-digit values.
  • Added zone_status_queries to define commands for individual attribute queries to construct full zone status.
  • Corrected volume_status regex to restrict the zone capture group to [1-6].
  • Removed spurious literals (BS, TR, BA) from bass/treble/balance response regexes and updated them to correctly match signed values ([+-]?\d+).

^{Description generated by Mesa. Update settings}

[mesa-dot-dev]

Performed full review of d994e0c...31e98f7

Analysis

• Silent failure mode in _merge_zone_status_responses() returns partial data without logging or indication to caller, creating observability gaps that make debugging communication issues harder and mask incomplete status as complete

• Configuration validation gap: new min_bass/min_treble/min_balance fields use fallback defaults when missing, allowing misconfigured devices to silently use incorrect EQ bounds without detection

• Inconsistent error handling between single-query path (with warnings via ZoneStatus.from_string()) and multi-query path (silent skipping of failed queries) reduces debuggability across protocol implementations

• Significant test coverage gap: no tests for negative EQ formatting, multi-query zone status flow, partial response handling, or new Sonance regex patterns, leaving edge cases around partial failures unvalidated

Tip

Help

Slash Commands:

• /review - Request a full code review
• /review latest - Review only changes since the last review
• /describe - Generate PR description. This will update the PR body or issue comment depending on your configuration
• /help - Get help with Mesa commands and configuration options

^{0 files reviewed | 5 comments | Edit Agent Settings • Read Docs}

[mesa-dot-dev]

The zone_status_queries list defines 7 separate queries that will be executed sequentially for each zone status check. This is a significant behavioral change:

Performance Impact: Single query → 7 sequential queries

• Each query involves serial I/O with response parsing
• For slow serial connections (9600 baud), this could add noticeable latency
• Consider if this could be optimized or cached

Network/Serial Load: 7x increase in command traffic

• Matters for polled status updates
• Consider rate limiting or batch status queries

Reliability: More opportunities for failure

• If 1 of 7 queries times out, you get partial data (see comment on _merge_zone_status_responses)

Document this trade-off and consider adding a config option for query timeout to fail fast if serial communication is unreliable.

 • 

Prompt for Agent

Task: Address review feedback left on GitHub.
Repository: rsnodgrass/pyxantech#7
File: pyxantech/protocols/sonance.yaml#L89
Action: Open this file location in your editor, inspect the highlighted code, and resolve the issue described below.

Feedback:
The `zone_status_queries` list defines 7 separate queries that will be executed sequentially for each zone status check. This is a significant behavioral change:

**Performance Impact**: Single query → 7 sequential queries
- Each query involves serial I/O with response parsing
- For slow serial connections (9600 baud), this could add noticeable latency
- Consider if this could be optimized or cached

**Network/Serial Load**: 7x increase in command traffic
- Matters for polled status updates
- Consider rate limiting or batch status queries

**Reliability**: More opportunities for failure
- If 1 of 7 queries times out, you get partial data (see comment on `_merge_zone_status_responses`)

Document this trade-off and consider adding a config option for query timeout to fail fast if serial communication is unreliable.