expose SHT40 temperature and humidity readings

[g4bri3lDev]

Why

Some boards ship an SHT40 which the firmware exposes, yet this library ignored it. That was half true: we already parsed the sensor config (TLV packet 0x23 → SensorData, SensorType.SHT40, and opendisplay info printing Sensor 0 SHT40 (bus 2)), but never the readings. SensorData.msd_data_start_byte — the field naming where the reading lives — had zero consumers.

The reason it was missed: the firmware gives the SHT40 no GATT characteristic. It bit-packs the reading into 3 bytes of the 11-byte dynamic block broadcast in every advertisement — the same block already decoded for buttons and touch. The third decoder was simply never written.

Wire format

Verified against firmware upstream/main (sensor_sht40.cpp, opendisplay_sensor_sht40.c, identical in both). 24-bit little-endian, 21 bits used:

bits	field	decode
0–9	humidity, 0.1 %RH steps	(v & 0x3FF) / 10
10–20	temperature, biased	(((v >> 10) & 0x7FF) - 400) / 10

Two patterns are not measurements and decode to None:

• FF FF FF — the firmware's read-failure sentinel; ordinary range checks reject it.
• 00 00 00 — a slot never written. It decodes to exactly -40.0 °C / 0.0 %RH, the simultaneous floor of both ranges, so range checks alone would pass it as a plausible reading. Rejected explicitly, so an uninitialised sensor reads as "no data" rather than writing a hard -40 °C into consumers' long-term statistics. The cost, documented in the tests, is that a genuine -40.0 °C at exactly 0 %RH is dropped.

Two read paths

Passive — AdvertisementData.sht40_reading(start_byte), mirroring the existing button_event() / touch_event(). This is the path Home Assistant wants: it already parses every advertisement and already caches GlobalConfig, so it can build one entity per measurement with the offset closed over at setup.

Connected — CMD_READ_MSD (0x0044), new here. The response carries the 16-byte record with its company-ID prefix intact, which parse_advertisement already strips, so device.read_msd() is pure reuse with no new parsing. It works on transports where no BLE advertisement is observable and needs no scan, which is why info uses it instead of scanning after disconnect.

read_sensor_values(config, advertisement) in the new sensors.py joins the two halves for scripts and the CLI. Deliberately no Sht40Tracker: the existing trackers exist to diff state into transition events, whereas a reading is a stateless value per advertisement.

The offset must come from config

Decoding at the wrong offset yields plausible garbage — a real button byte of 0x28 decodes as -39.9 °C / 4.0 %RH. And shipped boards disagree with the firmware default of 7: reTerminal E1001/E1002/E1004 use 1. A connection-free scan column was considered and rejected for exactly this reason.

SensorData.sht40_msd_start_byte is named for the SHT40 on purpose. The fuel gauges read msd_data_start_byte literally — 0 means byte 0, 0xFF means "do not publish" — so the SHT40's 0/0xFF → 7 rule must not be applied to them.

Also

Adds SensorType.NPM1300 (6), which shipped boards use and info previously rendered as 0x0006. Its readings are not decoded: its SOC is a linear voltage estimate, less accurate than our existing voltage_to_percent(), so only its charging bit would be new information. Same for the BQ27220 — left for a follow-up.

Verification

1008 tests pass; ruff, ruff-format, mypy strict and pylint all clean.

Beyond mocks, verified on real hardware:

• Decode — live on a reTerminal broadcasting at offset 1, tracking 27.7 → 28.0 °C as the loop counter advanced, with chip temperature correctly higher than ambient.
• READ_MSD — round-trip against an E1003 on firmware 2.26.0.
• No-sensor path — a device with no 0x23 packet returns [] and renders unchanged.
• End to end — after adding a 0x23 packet to an E1003 (see add missing SHT40 sensor to reTerminal E1003 preset opendisplay.org#74), info renders:

├── Sensors
│   └── Sensor 0 SHT40  (bus 0)  28.0 °C  63.6 %RH

Follow-ups, not in this PR

• Home Assistant needs a core-side change beyond a version bump: BASE_PLATFORMS omits Platform.SENSOR, so a non-Flex SHT40 board would decode fine and show zero entities.
• Pre-existing bug: AdvertisementTracker decodes all 11 dynamic bytes as buttons, so SHT40 and touch slots emit phantom button_slot_changed events when a reading changes. This predates this PR (touch has always triggered it) and is masked in HA by its byte_index filtering, but any other consumer would trust it.
• Fuel-gauge (BQ27220 / nPM1300) decoding.

[codecov]

Codecov Report

❌ Patch coverage is 84.55285% with 19 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/opendisplay/cli.py	71.87%	9 Missing ⚠️
src/opendisplay/device.py	41.66%	7 Missing ⚠️
src/opendisplay/models/advertisement.py	94.44%	2 Missing ⚠️
src/opendisplay/protocol/commands.py	66.66%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!