Repository navigation
Round float values in OpenTherm Gateway MQTT commands - #186
EndPositive wants to merge 1 commit into
Conversation
Floating-point artifacts such as 56.602000000000004 were sent as CS=56.602000000000004. OTGW-firmware drops queued commands longer than 14 characters, so the boiler never received the control setpoint.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughThe OpenTherm MQTT coordinator now formats four setpoint command values to one decimal place before publishing. Command ordering and superclass calls remain unchanged. ChangesOpenTherm setpoint formatting
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~5 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to
|
Problem
SatOpenThermMqttCoordinatorinterpolates raw floats into OTGW commands (f"CS={value}"). When the dynamic minimum setpoint clamps the setpoint, the value can carry floating-point artifacts, e.g.:OTGW-firmware (seen on 1.7.7) silently drops queued commands longer than 14 characters (
OT_cmd_t.cmd[15],addOTWGcmdtoqueue: "command too long"). The shortPM=25andCH=1still arrive, but the control setpoint never reaches the boiler, so it does not heat.It can also lock up. With the boiler idle, the return temperature stays put, so the dynamic minimum recalculates to the same 21-character value on every cycle. In our case that lasted more than 6 hours, with no heat at all.
Change
Format the float commands (
CS,SW,TC,SH) with one decimal, matching theround(..., 1)already applied to the calculated setpoint inclimate.py.MMandCHare integers and are unchanged.Test plan
CS=56.602000000000004. The OTGW bus control setpoint never showed the value.55.0(dynamic minimum off), the boiler receivedCS=55.00and fired within 30 s.Summary by CodeRabbit