feat(connection): add OWNSession.is_open and reset is_connected on close

[GreenGrassBlueOcean]

Summary

This PR addresses and closes #34 by providing a truthful transport view of the command session's socket state and aligning close() semantics:

1. OWNSession.is_open:

   • Exposes True iff both _stream_reader and _stream_writer are set and active.
   • Allows integrations (such as MyHOME) to verify whether the command session has an open socket without reaching into private stream attributes.

2. OWNSession.close() resets is_connected:

   • Explicit close() now drops the streams and clears _connected, notifying on_state_change on the transition so consumers don't see is_connected == True after teardown.
   • Internal stream recycles (_reconnect() and retry loops) use _close_streams(), preserving the no-flap behavior for transient reconnects.
   • OWNEventSession._close_streams() ensures keepalive tasks are cleanly canceled during teardown and recycles.

Closes #34.

[codecov-commenter]

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

Codecov Report

❌ Patch coverage is 99.15966% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
OWNd/connection.py	99.15%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[Interstellar0verdrive]

I checked the one thing that came out of the #318 finding, not the whole diff.

It does what it should: is_open reads the two streams, which is what send() actually looks at before reopening, and it's documented as distinct from is_connected. close() now releases the socket and clears the connected flag, while the internal recycling paths (_reconnect() and the retry loop inside connect()) go through the new _close_streams(), so a routine reconnect still doesn't flap availability. The command session's override moved to _close_streams() too, so the keepalive can't outlive the socket on either path. The three new tests cover exactly those cases, including the one that matters most: closed, flag False; recycled, flag untouched.

One inconsistency, and I'd rather ask than assert since the library isn't my ground: inside _locked_send the failure paths still call self.close() — the timeout, the connection-reset retry, the cancellation, the "session unavailable" branch. By the rationale in your own docstring those look like internal recycling, so _close_streams() would be the match; as written, a single command timeout now flips is_connected and notifies the consumer, where before the flag stayed put. It happens to be harmless for MyHOME today, because the command session is built without an on_state_change callback there (only the event session has one), so nothing downstream sees it. But it's a behaviour change that's invisible until someone wires that callback up, and then a busy bus would look like a gateway going offline and back.

Everything beyond this point in the diff needs someone who knows the library; I'd defer to @fedem95 or @xtimmy86x for the rest.

[xtimmy86x]

Thanks for this improvement. I reviewed 1fe9d81 and can confirm @Interstellar0verdrive’s concern.

In an isolated simulation using the PR’s actual methods, a status request encounters a connection reset, retries successfully, and returns success—but on_state_change receives [False, True]. This happens because _locked_send() still calls close() before retrying, which now clears the connected flag.

Please use _close_streams() for recoverable retries, preserving the connected state when recovery succeeds. Definitive failures and explicit teardown should still report disconnection; I would avoid replacing every close() call indiscriminately.

A regression test should verify both cases: no offline/online transition during a successful retry, and a disconnection notification when recovery fails.

The distinction between is_open and is_connected is useful, and CI is green. I would like this remaining inconsistency addressed before approving. My verification was an isolated simulation, without hardware testing.

[GreenGrassBlueOcean]

@xtimmy86x , @Interstellar0verdrive addressing this as we speak

[GreenGrassBlueOcean]

@xtimmy86x — confirmed and fixed in 54f61e9. Your simulation was right: _locked_send() closed the session on a transport error before deciding whether it would retry, and after 1fe9d81 that close carries the flag.

What changed — one path only, as you suggested, not a blanket replacement:

• ConnectionResetError / IncompleteReadError / LimitOverrunError / OSError in _locked_send(): now _close_streams() first, then the existing retry decision. If it retries (status request, or a command not yet written) the reconnect is an internal recycle and the consumer hears nothing. If it does not retry, _set_connected(False) — the loss is definitive and reported once.
• Every other close() in _locked_send() stays: connect() giving up, the response timeout, cancellation, the crash path. None of those retries, so each is a real loss.

Regression tests (tests/test_connection_extended.py, TestOWNCommandSession), covering both halves you asked for and the third case in between:

case	on_state_change sees
status request, reset, retry succeeds	[True] — nothing new
status request, reset on both attempts	[True, False]
command already written, ack lost (never replayed)	[True, False]

The first one fails on 1fe9d81 with exactly your observation ([True, False, True]). OWNd: 630 passed, mypy and ruff clean. MyHOME's full suite against this branch: 1599 passed.

#36 is rebased on top (9c122ec), no changes of its own. I'll keep the two landing in that order: #35 first, on its own.

[xtimmy86x]

Thanks for addressing this in 54f61e9. I reviewed the fix and reran the isolated simulation: a successful retry now completes without an offline/online notification.

The change preserves disconnection reporting for definitive failures and avoids replaying commands already written. The three regression tests cover the requested cases, and CI is green across Python 3.11–3.14, with 630 tests passing.

My previous concern is resolved. No further blocking concerns from my review—approved.