ir---goods-shed will not hold a steady reading with a stationary loco parked over it. Measured on the bench 2026-08-23, over 100 s, with the loco not moving:
18:04:07 clear 18:04:24 clear 18:04:59 occupied
18:04:08 occupied 18:04:26 occupied 18:05:00 clear
18:04:09 clear 18:04:27 clear 18:05:05 occupied
18:04:16 occupied 18:04:31 occupied 18:05:08 clear
18:04:19 clear 18:04:37 clear
cs---goods-shed over the same window was rock solid occupied, re-asserting every 25 s. So this is the beam, not the node, the transport, or the I2C path.
This is not switch bounce, and debouncing will not fix it
The dwell times are 1–5 seconds. Proper debouncing (landed alongside this issue) removed the sub-200 ms chatter that was previously flooding the broker at 2–3 flips per second, and what remains is a genuinely oscillating beam.
Raising DEBOUNCE_MS far enough to mask seconds-long dwells would be the wrong fix twice over: it would suppress real detections as readily as false ones, and it would add latency to a sensor type whose whole purpose (ir_position, docs/sensor-position.md #77) is knowing when a beam broke. A position fix that arrives two seconds late is worse than none.
Most likely physical: the loco is sitting right at the detection threshold, or the sensor wants alignment or a sensitivity adjustment. Related, and possibly the same root cause — these IR sensors are already known to be marginal for detecting passing rolling stock.
It is currently harmless, by design
The orchestrator's block occupancy never moved during the whole window — one retained occupied, no changes. domain/occupancy.ts clause 2 says only a block_detection sensor may assert a block is empty; an ir_position reading clear is a no-op. So the flapping beam cannot clear Goods Shed while the current-sensing detector holds it occupied.
That is the rule doing exactly the job it exists for, and it is worth recording as evidence that the asymmetry is correct rather than fussy.
Why it still matters
- It stops being harmless the moment IR is used for anything that consumes a rising edge: sub-block position (#77), and the berthing beam that
docs/automation.md uses to bring a train to a stand. A beam that breaks and remakes fifteen times would produce fifteen position fixes.
- It puts needless traffic on the broker and needless publishes through the modem.
- It is a standing false signal that makes any real future fault harder to spot.
Next
Physical investigation first — alignment, sensitivity, and whether the loco's underframe sits at the edge of range. No firmware change is warranted until that is understood, beyond the debouncing already landed.
ir---goods-shedwill not hold a steady reading with a stationary loco parked over it. Measured on the bench 2026-08-23, over 100 s, with the loco not moving:cs---goods-shedover the same window was rock solidoccupied, re-asserting every 25 s. So this is the beam, not the node, the transport, or the I2C path.This is not switch bounce, and debouncing will not fix it
The dwell times are 1–5 seconds. Proper debouncing (landed alongside this issue) removed the sub-200 ms chatter that was previously flooding the broker at 2–3 flips per second, and what remains is a genuinely oscillating beam.
Raising
DEBOUNCE_MSfar enough to mask seconds-long dwells would be the wrong fix twice over: it would suppress real detections as readily as false ones, and it would add latency to a sensor type whose whole purpose (ir_position,docs/sensor-position.md#77) is knowing when a beam broke. A position fix that arrives two seconds late is worse than none.Most likely physical: the loco is sitting right at the detection threshold, or the sensor wants alignment or a sensitivity adjustment. Related, and possibly the same root cause — these IR sensors are already known to be marginal for detecting passing rolling stock.
It is currently harmless, by design
The orchestrator's block occupancy never moved during the whole window — one retained
occupied, no changes.domain/occupancy.tsclause 2 says only ablock_detectionsensor may assert a block is empty; anir_positionreadingclearis a no-op. So the flapping beam cannot clear Goods Shed while the current-sensing detector holds it occupied.That is the rule doing exactly the job it exists for, and it is worth recording as evidence that the asymmetry is correct rather than fussy.
Why it still matters
docs/automation.mduses to bring a train to a stand. A beam that breaks and remakes fifteen times would produce fifteen position fixes.Next
Physical investigation first — alignment, sensitivity, and whether the loco's underframe sits at the edge of range. No firmware change is warranted until that is understood, beyond the debouncing already landed.