chore(knx): changelog entry for the payload fix, bump to 0.5.0

The unreleased section already carries breaking changes (the sans-io engine
rework: `ConnectorBuilder::build` returning `Vec<BoxFuture>`, the Embassy
`KnxConnectorBuilder::new` signature, the deleted `KnxCommand` types), so
the next release is a minor bump under 0.x semver.

Cargo.lock is left out: it currently also carries an unrelated defmt and
heapless refresh from the working tree.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: lxsaah

aimdb-knx-connector/CHANGELOG.md

@@ -13,6 +13,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- **Inbound single-octet telegrams no longer decode to `0` (#210).** A telegram carrying exactly one data octet — every DPT5 datapoint (5.001 percentage, 5.003 angle, 5.010 counter, …) — was published as `0` instead of its value. `knx-pico` derived the application data as `[9 .. 7 + npdu_length)`, one octet short of the KNX encoding (the NPDU length octet counts the APCI octet plus the data octets, so the data spans `[9 .. 8 + npdu_length)`); the slice came back empty, the telegram was taken for a 6-bit encoded one, and its value was read out of the APCI octet as `0x80 & 0x3F` — zero. Only single-octet payloads were affected: DPT1 was genuinely 6-bit encoded, and DPT9/DPT14 happened to work because the old code ignored the parsed slice and read to the end of the datagram. Fixed at the root in the fork (`aimdb-dev/knx-pico` `b4883c4`, reported upstream as [cc90202/knx-pico#4](https://github.com/cc90202/knx-pico/issues/4)) — the same off-by-one that made 6-bit telegrams panic, which the previously carried patch had only clamped to an empty slice. `parse_telegram` now reads the parsed frame instead of re-deriving cEMI offsets, so the payload is bounded by the NPDU length octet rather than running to the end of the datagram. **Requires the updated fork** — see the patch note in the [usage guide](../docs/aimdb-usage-guide.md).
 - **Heartbeat-response liveness — a dead send path or expired gateway channel now reconnects (review follow-up to #135).** The engine tracks each CONNECTIONSTATE_REQUEST and drops the connection when the gateway's CONNECTIONSTATE_RESPONSE doesn't arrive within the new `TunnelConfig::heartbeat_response_timeout_ms` (default 10 s, the KNX spec timeout) or reports a non-zero status (e.g. the gateway expired the channel during an outage). This restores the old tokio client's recovery from silently-failing sends — the recv path of an unconnected UDP socket never errors, so without it a route flap left the tunnel `Connected` forever with a stale channel id — and adds genuine liveness detection on both runtimes.
 - **Pending-ACK tracking is accurate under send failures and bursts.** A frame the transport could not hand to the socket is untracked (`TunnelIo::send` reports success; previously the 3 s sweep warned "ACK timeout" for a telegram that never left the host), and a burst deeper than the 16-entry pending map evicts-and-reports the oldest entry instead of silently dropping its timeout reporting.
 - **Tokio: the gateway address is validated in `build()` (issue #133 contract).** A typo'd IP — or a hostname, which `SocketAddr` parsing never resolves — now fails `ConnectorBuilder::build` like on Embassy, instead of producing a healthy-looking connector whose task parked forever logging once per hour.

aimdb-knx-connector/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "aimdb-knx-connector"
-version = "0.4.0"
+version = "0.5.0"
 edition = "2021"
 authors.workspace = true
 license.workspace = true