Signed int16 fields parsed as unsigned, and wrong unknown sentinel (0xFFFF vs 0x7FFF)

Was working on a SEN66 project and Claude brought up the following issue. Thought I would pass it along:

> Every word off the wire is unpacked with struct.unpack(">H", ...) (line 324) and every field is checked against a single _UNKNOWN_VALUE = 0xFFFF (line 108). The datasheet specifies temperature, humidity, and the VOC/NOx indices as signed int16 with 0x7FFF as the unknown marker. Two bugs fall out of that:
>
> 1. Negative temperatures wrap. −10 °C comes back as raw 0xF830 → 63536/200 = +317.68 °C. Every sub-zero reading lands in the ~317–327 °C band
> 2. The unknown sentinel leaks through as data. 0x7FFF converts to 163.835 °C, 327.67 %RH, and 3276.7 for the VOC/NOx indices (NOx returns it for the first ~11 s after startup, so every boot emits these). The docstrings promise None for unknown, so downstream is None checks pass them through as real readings.
>
> The comments at lines 916/920 already say int16, 0x7FFF = unknown — the code just doesn't do it. Same pattern in the other read paths: lines 498–499 (SEN63C ambient), 969–970 (raw_values), 1216–1223. The unsigned fields (PM, NC, CO2) are handled correctly.
>
> Fix is small: for the int16 fields, check 0x7FFF before conversion and sign-extend (or unpack those words with ">h").
>
> Seen on 1.1.0 / current main.

Start at the struct.unpack(" >H", ...) call around line 324 and compare the signed-field paths at lines 498–499, 969–970, and 1216–1223 with the int16 comments at lines 916/920. Verify that 0x7FFF produces None and negative raw values produce signed readings for temperature, humidity, and VOC/NOx, while the unsigned PM, NC, and CO2 fields remain unchanged.

Written by the indexing model from the issue text.