Verify rain_rate conversion against rain_cal — unaddressed in #149

[kanfei-code-agent]

Context

#149 fixed LinkDriver.poll's rain_daily and rain_yearly to use the proper rain_cal-aware formula (register × 25.4 / rain_cal).

rain_rate was deliberately left alone in that PR because it lives on a different code path and I didn't have hardware to verify whether it has the same scaling bug.

What needs verifying

Two suspect lines:

1. backend/app/protocol/link_driver.py:1025 — LinkDriver.poll does reading.rain_rate / 10.0. reading.rain_rate arrives already-converted by _to_si (below), so the /10.0 here just unscales from "tenths of mm/hr" back to "mm/hr". This part is fine IFF the upstream conversion is right.

2. backend/app/protocol/loop_packet.py:54-55, 67 — _to_si applies in_hundredths_to_mm_tenths(reading.rain_rate) to LOOP packet rain fields, which is × 2.54. That assumes the LOOP packet's rain_rate field is in hundredths of an inch independent of rain_cal. If the LOOP packet's rain_rate is actually scaled the same way as the memory registers (i.e., depends on rain_cal), then the conversion is off by rain_cal / 100× for any setting except the default.

How to verify on hardware

With a station whose rain_cal differs from 100 (e.g., back at the workaround rain_cal=254, or any other custom value):

1. Trigger known bucket tips manually (or pour a measured amount of water through the gauge).
2. Observe the live rain_rate value in the UI immediately after.
3. Compare against the expected mm/hr for the known tip count + elapsed time.
4. Repeat at rain_cal=100 (after Fix rain unit conversion: use rain_cal instead of hardcoded /10 #149 lands).

If rain_rate reads correctly at one calibration and incorrectly at the other, the LOOP-packet conversion has the same bug shape as the register one and needs rain_cal plumbed into _to_si.

If rain_rate reads correctly at both calibrations, the LOOP packet is genuinely independent of rain_cal and no change is needed.

Why this isn't urgent

The visible bug from this session was on rain_daily / rain_yearly (daily totals on the dashboard) — that's what users notice. rain_rate is transient and small; under-reporting by ~2.54× during a storm matters but is less obvious than a wrong daily total. Worth fixing properly once we have a verification cycle.

Acceptance criteria

• A hardware verification run is documented (in a follow-up PR description or comment) showing whether rain_rate is rain_cal-dependent.
• If dependent: fix is _to_si accepting a rain_cal param (or moving the conversion out of _to_si to the driver where rain_cal is in scope), and _rain_register_to_mm from Fix rain unit conversion: use rain_cal instead of hardcoded /10 #149 gets used for rain_rate too.
• If independent: close this issue with a comment recording the verification result.

— Code Agent