fix(connection): log status request NACK retries at DEBUG (#43)

[GreenGrassBlueOcean]

Summary

Fixes #43. Follows up on testing feedback from @TheDarkWizard in OpenWebNet-HA/MyHOME#402.

In OWNCommandSession._locked_send(), when a status request (is_status_request=True) is rejected with a NACK by the gateway:

• Attempt 1 was previously logged as self._logger.error("%s Could not send message %s. Retrying (%d)...") regardless of is_status_request.
• Attempt 2 was logged at DEBUG (Gateway rejected status request...).

This PR gates the retry log with if is_status_request: so that status request retries are logged at DEBUG rather than ERROR. This prevents downstream consumers like Home Assistant from emitting alarming error messages when discovery probes (*#4*0##, *#16*0##) receive standard NACKs for uninstalled subsystems.

Changes

• OWNd/connection.py: Log NACK retries for is_status_request at DEBUG.
• tests/test_connection.py: Assert logger.error.assert_not_called() and verify retry debug logging in test_rejected_status_request_is_logged_at_debug.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[xtimmy86x]

The core fix looks correct: status-request NACK retries are now logged at DEBUG, while NACKs for regular commands remain at ERROR. The test also covers both the retry and the expected logging behaviour, and all CI checks pass.

Before approval, I have one scope concern: this PR also includes the 2.0.0-b9 version bump and adds skip-existing: true to the release workflow, but neither change is mentioned in the description. In particular, skip-existing could hide an accidental duplicate or incorrectly versioned release.

Could you please remove these unrelated release changes and handle them separately, or explain and document why they are required here? It would also be useful to clarify that this fix changes the logging level only—the status request is still retried after a NACK.

Once this is addressed, the PR looks ready for approval.

[GreenGrassBlueOcean]

Thanks for the thorough review @xtimmy86x!

Context on the release changes

The skip-existing: true change was added following an incident earlier today during the v2.0.0-b8 release:

1. The release was first published to PyPI via manual workflow_dispatch (Run OWNd sometimes receives temperature WHO=4 as response to WHO=1 #8).
2. Shortly after, the GitHub Release v2.0.0-b8 was published in the UI, which triggered release.yml a second time (Run Cooling related offset values crash event loop #9) due to the on: release: [published] hook.
3. PyPI rejected the duplicate upload with HTTP 400 (File already exists), causing Run Cooling related offset values crash event loop #9 to fail.
4. skip-existing: true was added to make the publish step idempotent, alongside pre-emptively bumping __version__ to 2.0.0-b9 for this fix.

Action taken

You make a very valid point that skip-existing: true could mask cases where someone forgot to bump the version string, and that release chore changes belong in separate PRs (as done in #40 and #42).

I have removed both the version bump and the workflow change from this branch and force-pushed, leaving PR #44 strictly focused on the #43 logging fix. A separate release PR will be opened once this merges.

Clarification on retry behavior

To confirm: this PR modifies the logging level only. When a status request (is_status_request=True) receives a NACK on attempt 1, the session continues to retry the request exactly as before (continue loop); it simply logs the event at DEBUG instead of ERROR so that discovery probes against uninstalled subsystems do not emit spurious error alarms in downstream consumers like Home Assistant.