Summary
On a live HA soak (integration v0.3.1), every favourite activation (sending a 0x30 FavouriteControl message) is followed by a header-parse failure logged at DEBUG:
[airtouch2.at2plus.At2PlusClient] ValueError: 253 is not a valid AddressSource
Failed reading header, trying again
The frame being read is e.g. 55 55 fd 80 2e c0 00 36 ... - i.e. the address-source byte is 0xFD (253), which AddressSource does not enumerate (it only has SELF=0xB0, OTHER=0x9F), so Header.from_bytes raises.
Impact
Cosmetic / self-recovering. The reader resyncs on the next 55 55 preamble and successfully reads the subsequent clean 0x31 favourite-status reply, so favourites still update and there is no dropout. It just produces DEBUG noise once per activation round-trip.
Cause (to confirm)
Either (a) the favourite-activation response path genuinely uses an undocumented address source 0xFD, or (b) a brief framing mis-alignment right after the 0x30 send causes a mid-stream byte to be read as a header. Needs a quick look at the bytes immediately around the failure.
Suggested fix
- Make header parsing tolerant of unknown
AddressSource values (fall back to an UNKNOWN member rather than raising), and/or add 0xFD once its meaning is confirmed.
- Confirm whether the
0xFD frame carries useful data (likely a control echo) or can be safely ignored.
Low priority - no functional impact, log noise only.
Summary
On a live HA soak (integration v0.3.1), every favourite activation (sending a
0x30FavouriteControl message) is followed by a header-parse failure logged at DEBUG:The frame being read is e.g.
55 55 fd 80 2e c0 00 36 ...- i.e. the address-source byte is0xFD(253), whichAddressSourcedoes not enumerate (it only hasSELF=0xB0,OTHER=0x9F), soHeader.from_bytesraises.Impact
Cosmetic / self-recovering. The reader resyncs on the next
55 55preamble and successfully reads the subsequent clean0x31favourite-status reply, so favourites still update and there is no dropout. It just produces DEBUG noise once per activation round-trip.Cause (to confirm)
Either (a) the favourite-activation response path genuinely uses an undocumented address source
0xFD, or (b) a brief framing mis-alignment right after the0x30send causes a mid-stream byte to be read as a header. Needs a quick look at the bytes immediately around the failure.Suggested fix
AddressSourcevalues (fall back to anUNKNOWNmember rather than raising), and/or add0xFDonce its meaning is confirmed.0xFDframe carries useful data (likely a control echo) or can be safely ignored.Low priority - no functional impact, log noise only.