Poll the Si7021 every 100 ms and report cabin readings on change #92
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/heater-sensor-rate"
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?
The Si7021 is now polled every 100 ms.
ReadoutEndpointgains an optional change threshold in the endpoint's own units: when non-zero, a status change or a change of at least the threshold marks it for report, on top of the 10 s heartbeat. Zero keeps today's periodic-only behaviour, so no other node changes. The cabin temperature and humidity readouts use a threshold of 1.The motor is now written only when its level changes.
LevelEndpoint::requestmarks the endpoint dirty even for an unchanged level (vianoteChange), so that guard is what prevents a state frame per pass.Stacks on #89, #90 and #91.
Humidity may report several times a second at the 0.1 % step; a deadband is the fix if the bench shows it is too chatty. Tested:
pio test -e nativeandpio run -e node_heater. Not tested on hardware.Ticket: CCS-WHP-15
Two findings on
079194a.@ -92,0 +124,4 @@const bool linkLost = heater.linkLost();const can::Origin origin = linkLost ? can::Origin::Failsafe : can::Origin::Automation;const uint16_t level = blowerControl.update(linkLost, heater.blowerOn(), cabinSensor.temperature(), heater.setpoint(), secondsSinceReading);if (level != appliedBlowerLevel && blowerMotor.commandAllowed(origin, now)) {Dropping
newReadingfrom the guard changes behaviour beyond the task. Before, every new reading re-asserted the motor level. Now, if a human overrides the blower and the lockout expires, an unchangedlevelis never re-applied, so the manual value sticks until the level next changes. Either keepnewReading ||or confirm in the spec that automation only writes on level change.@ -55,0 +73,4 @@void test_a_one_unit_change_reports_at_threshold_one() { TEST_ASSERT_TRUE(reportsAfter(1, okAt(200), okAt(201))); }void test_a_status_change_reports_at_threshold_one() { TEST_ASSERT_TRUE(reportsAfter(1, okAt(200), {0, can::units::Status::Fault, can::units::i16Fault})); }This test cannot fail if the status comparison is removed. 200 to
i16Faultis a huge value change, so the threshold branch fires anyway. Use the same value with a different status, e.g.{0, Status::Fault, 200}.Nothing to act on in
0ca99e3.