Add a heater_blower type driven by a flow5d heater #141
rob
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/yaml-blower"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
YN-23, reworked after review. Stacks on #140 (YN-21), so the diff also shows that PR's commits (and #139 and #137 under it) until they merge.
New output type
heater_blower: the blower motor of aflow5don the same node, a PWMLevelEndpointofEndpointType::FanwithFailsafe::Autonomous, run byheater::BlowerControl. Fields arepinorpins,frequency(default 1000),heater(label of the flow5d, resolved on the same node only),thresholdand optionaldisabled_modes.thresholdis a coolant temperature in °C to one decimal place, or the label of a same-nodesettingofsetting_type: temperature. It takes nobinds,failsafe,invertorfade; the config leaves the fade at the library defaults, as the hand-written node does. For a literal threshold the generator declares an unregisteredSettingEndpointholding that value, sinceBlowerControlreads a setting. The control objects are declared after all the endpoints, so list order does not matter, andloopcalls<name>Control.loop(ctrl::nowMs())beforenode.loop().BlowerControlmoved fromsrc/node_heaterinto its own library,lib/heater-blower(namespaceheater::as before, with alibrary.jsondepending onnode-runtime), because it is specific to the heater and does not belong in the runtime. The hand-written heater node only changes its include from"blower_control.h"to<blower_control.h>,test_blower_controlis unchanged, and the native env lists the library and its include path. No behaviour change.Until YN-22 adds the measure bind, a generated heater's measured reading is Unknown, so the blower runs full in the PI branch (its cabin reading is not usable).
Schema regenerated (per-type
frequencydefault,heaterandthresholdrequired, threshold as number or label). README gets the type row and a Heater blower section saying it must share the node with its heater. The heater fixture gains two blowers, one with a setting label and one with a literal, so CI compiles both.Tested: Python 124 and native 639, none skipped locally. Tests cover the heater-label resolution and cross-node rejection, both threshold forms and their ranges, the rejected fields and the render; changing the failsafe fails them. All fixtures and
pio runbuild.nodes/README.md, Heater blower: it says the blower "follows a PI loop on the heater's setpoint and the cabin temperature". The generated cabin reading is always
can::SensorScalar{}(status Unknown), so the loop never runs. The blower is only ever off or flat out. Say that plainly, or the PI sentence will mislead anyone configuring it.Claude referenced this pull request2026-10-17 09:40:49 +00:00
@ -0,0 +1,97 @@#pragma onceThis file shouldn't be part of the runtime as it's hardware specific. Put it in its own library
1f2107d6ede00319f99dnodes/README.md, Heater blower section: "
temperature_setting" is a stale name. Say asettingwithsetting_type: temperature. Also rewrap the paragraph; one line runs long after the last edit.