v0.7.2

Bug fix — realtime data never arriving

Root cause: read_timeout=1 causes Linux epoll to fire EPOLLIN after 1 second via the termios VTIME mechanism, even when no serial data is present. serialx's descriptor_transport treats the resulting empty os.read() as peer-closed (EOF) and permanently shuts the stream reader down. Historical packets flow without issue because they arrive with sub-second gaps; the 2–6 second pause between history completion and the first realtime packet is long enough to trigger the false EOF.

Fix: read_timeout=0 (non-blocking / VMIN=0 VTIME=0) — epoll only wakes on real data, so os.read() never returns b"" spuriously.

v0.7.1

Bug fix

• Fix CONTINUE_REQUEST and START_REQUEST constants from list to bytes — serialx>=1.7.2 now strictly requires bytes/bytearray/memoryview in write(), causing an AssertionError on connect with [165].

v0.7.0: migrate to serialx

Migrate from pyserial-asyncio-fast to serialx>=1.7.2.

serialx 1.7.2 fixed the non-POSIX baud rate bug (termios2 sentinel search) that caused 250000 baud to fail on real hardware (issue: puddly/serialx#83).

Changes:

• Replace pyserial-asyncio-fast with serialx>=1.7.2
• Update serial connection to use serialx API (Parity, StopBits enums, byte_size, read_timeout, write_timeout params)
• Update tests to mock serialx

v0.6.1

v0.6.1 — Revert to pyserial-asyncio-fast

Reason

serialx 1.7.1 fails to set 250000 baud on certain Linux platforms (including Home Assistant OS targets). Its _set_non_posix_baudrate method auto-detects the c_ispeed/c_ospeed field offsets in the termios2 struct by searching for a 115200 sentinel value, but this search fails on kernels that populate those fields differently. pyserial hardcodes the offsets directly and works reliably on all tested platforms.

Error seen: Could not determine offset of termios2 speed fields: …

A bug report has been filed at https://github.com/puddly/serialx/issues. The migration to serialx will be retried once the upstream issue is fixed.

What changed vs v0.6.0

• Dependency reverted to pyserial-asyncio-fast>=0.16,<2.0
• Exception handling improvements from v0.6.0 are kept (OSError | TimeoutError | SerialException instead of bare Exception)

v0.6.0

v0.6.0 — Migrate from pyserial-asyncio-fast to serialx

Changes

• Dependency: replaced pyserial-asyncio-fast with serialx (>=1.7), the library now recommended by Home Assistant for serial communication
• API: open_serial_connection call updated to serialx parameter names (byte_size, read_timeout, write_timeout) and enum constants (Parity.NONE, StopBits.ONE)
• Error handling: tightened exception catches to OSError | TimeoutError | serialx.SerialException instead of broad Exception
• Tests: added 37 unit tests covering packet parsing, historical data, connect/disconnect, and state accessors

Migration for users of the library directly

Replace pyserial-asyncio-fast with serialx in your environment:

pip install serialx

No changes to the public API (CMDataCollector, get_async_datacollector, SUPPORTED_SENSORS).

v0.5.2: Critical Handshake Protocol Fix

🚨 Critical Hotfix

IMPORTANT: This release fixes a critical protocol bug that was the actual root cause of the CM160 historical sync issue.

Root Cause Identified

The device sends IDTWAITPCR (with 'R' at the end) but the library was only checking for IDTWAITPC (missing 'R'). This caused the handshake to fail completely, leading to the infinite loop described in the bug report.

Technical Fix

• Protocol Correction: Fixed ID_WAIT_HISTORY constant from "IDTWAITPC" to "IDTWAITPCR"
• Buffer Decoding: Extended message decoding from bytes 1-9 to 1-10 to capture the full 10-character message
• Reference Compliance: Now matches the reference implementation exactly

Message Analysis

Bug report showed device sending: a949445457414954504352

• Decoded: IDTWAITPCR (10 characters)
• Previous code only checked: IDTWAITPC (9 characters)
• Result: Handshake never completed, causing infinite loop

Impact

This was the actual root cause of the CM160 getting stuck in historical sync mode. The timeout fix in v0.5.1 helped as a workaround, but this fix addresses the fundamental protocol issue.

Recommendation: Upgrade immediately from v0.5.1 for proper protocol compliance.

v0.5.1: Fix CM160 Historical Sync Bug

🔧 Bug Fixes

Critical Fix: Resolved CM160 device getting stuck in historical sync mode after Home Assistant reboot.

Issues Resolved

• Device would continuously send handshake messages without transitioning to real-time mode
• Only 1 historical record was processed before getting stuck in handshake loop
• Infinite 5-second handshake pattern (a949445457414954504352) preventing normal operation

Technical Improvements

• Implemented timeout-based historical data completion detection (5-second timeout)
• Enhanced protocol state machine with proper transitions
• Added timeout monitoring following reference implementation pattern
• Improved reliability of historical-to-realtime mode transition

🆕 New Features

Device State Monitoring API

• get_device_state(): Returns current communication state
• get_device_state_info(): Detailed state information with historical count, connection status
• Enhanced debugging and monitoring capabilities for Home Assistant integration

State Machine States

• Unknown: Initial state, device not yet identified
• IdentifierReceived: Device found and identified
• TransmittingHistory: Historical data transmission in progress
• TransmittingRealtime: Real-time data transmission active

📖 Documentation

• Updated README with new API documentation
• Added device state monitoring examples
• Enhanced integration guidelines for Home Assistant developers

This release ensures reliable operation after Home Assistant reboots and provides better visibility into the device communication process.

0.4.3

Full Changelog: 0.4.0...0.4.3