Device / environment
- Device: Honeywell T6 Pro Z-Wave thermostat
- Fingerprint:
manufacturerId 0x0039, productType 0x0011, productId 0x0008 → honeywell/t6 → profile base-thermostat
- Driver:
SmartThings/zwave-thermostat (Edge)
- Hub: SmartThings v3 (Aeotec), current firmware
Summary
On the T6 Pro, relativeHumidityMeasurement never tracks the device. The humidity tile either stays blank or freezes at a stale value indefinitely, while temperature, mode, setpoint, operating state, and battery all update normally.
Root cause
The T6 Pro does not send unsolicited SensorMultilevel RELATIVE_HUMIDITY reports. It only returns humidity when explicitly polled with a typed SensorMultilevel v5 Get(sensor_type = RELATIVE_HUMIDITY).
The default refresh already issues that typed Get (see refresh_commands in test_zwave_thermostat.lua), so a manual refresh can populate humidity — but nothing polls it afterward, so it goes stale. Temperature stays current only because the device volunteers TEMPERATURE on change; it never does the same for humidity.
Evidence (SmartThings CLI edge:drivers:logcat)
The device answers a typed humidity Get:
sending SENSOR_MULTILEVEL GET {sensor_type="RELATIVE_HUMIDITY"} version=5
received SENSOR_MULTILEVEL REPORT {scale="PERCENTAGE", sensor_type="RELATIVE_HUMIDITY", sensor_value=61.0}
But over ~4 hours of passive monitoring it emitted unsolicited SensorMultilevel reports for TEMPERATURE only (drifting 78 → 75 °F), and zero unsolicited RELATIVE_HUMIDITY reports. So without a poll, the humidity attribute simply never changes after the initial refresh.
Impact
Every T6 Pro Z-Wave owner sees a humidity value that never updates, which reads as "humidity doesn't work." The capability is present in the profile and the device fully supports it — it's purely a matter of the driver not re-polling a value the device won't volunteer.
Suggested fix (deferring to maintainers on approach)
Periodically poll RELATIVE_HUMIDITY for this device family — e.g. a Honeywell T6 sub-driver that schedules the typed Get, fingerprint-gated to 0x0039 so no other thermostat is affected. I've already prototyped this on a fork and confirmed a ~60 s poll keeps the tile live. Happy to open a PR with unit tests if that approach is acceptable, or adapt to whatever pattern you'd prefer (e.g. a generic "poll capabilities the device doesn't volunteer" mechanism).
Workaround
A manual refresh repopulates humidity each time, but it freezes again until the next refresh.
Device / environment
manufacturerId 0x0039,productType 0x0011,productId 0x0008→honeywell/t6→ profilebase-thermostatSmartThings/zwave-thermostat(Edge)Summary
On the T6 Pro,
relativeHumidityMeasurementnever tracks the device. The humidity tile either stays blank or freezes at a stale value indefinitely, while temperature, mode, setpoint, operating state, and battery all update normally.Root cause
The T6 Pro does not send unsolicited
SensorMultilevelRELATIVE_HUMIDITY reports. It only returns humidity when explicitly polled with a typedSensorMultilevel v5 Get(sensor_type = RELATIVE_HUMIDITY).The default refresh already issues that typed Get (see
refresh_commandsintest_zwave_thermostat.lua), so a manual refresh can populate humidity — but nothing polls it afterward, so it goes stale. Temperature stays current only because the device volunteers TEMPERATURE on change; it never does the same for humidity.Evidence (SmartThings CLI
edge:drivers:logcat)The device answers a typed humidity Get:
But over ~4 hours of passive monitoring it emitted unsolicited
SensorMultilevelreports for TEMPERATURE only (drifting 78 → 75 °F), and zero unsolicited RELATIVE_HUMIDITY reports. So without a poll, the humidity attribute simply never changes after the initial refresh.Impact
Every T6 Pro Z-Wave owner sees a humidity value that never updates, which reads as "humidity doesn't work." The capability is present in the profile and the device fully supports it — it's purely a matter of the driver not re-polling a value the device won't volunteer.
Suggested fix (deferring to maintainers on approach)
Periodically poll
RELATIVE_HUMIDITYfor this device family — e.g. a Honeywell T6 sub-driver that schedules the typed Get, fingerprint-gated to0x0039so no other thermostat is affected. I've already prototyped this on a fork and confirmed a ~60 s poll keeps the tile live. Happy to open a PR with unit tests if that approach is acceptable, or adapt to whatever pattern you'd prefer (e.g. a generic "poll capabilities the device doesn't volunteer" mechanism).Workaround
A manual refresh repopulates humidity each time, but it freezes again until the next refresh.