A speed change left Home Assistant showing the old airflow for up to SENSOR_POLL_INTERVAL, which is most of a minute of numbers describing a speed the fans are no longer running at. sensor_routine now waits on whichever comes first: the interval, or the fan confirming a new set point. The confirmed one rather than the requested one, because by then the fan has answered the write, so this poll cannot be queueing behind it for the modbus mutex. A change is answered by two readings rather than one. The fans do not step to a new speed, they travel to it: measured today, a change commanding 78 m3/h still read 82 and 84 sixteen seconds later and had settled by forty-six. So the first reading goes out immediately, because a number that moves is what asking for a speed change should look like, and SENSOR_POLL_SETTLE_DELAY later a second one catches where it arrived. That delay is a guess bounded by two samples rather than a measurement of the ramp, which is why the ordinary interval poll behind it still matters: that one is settled for certain. Nothing is lost to a change arriving mid-poll or during the settling wait — the watch holds the latest value until this receiver has seen it. Builds and runs on hardware; the trigger itself has not been watched fire yet, which needs a speed change from Home Assistant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>