Some MikroTik models report `mtxrGaugeValue` (mtxrGaugeUnit=1, °C) in
deci-degrees, while others — like the CRS317 in upstream test data —
return whole degrees. The MIB doesn't disclose which, so the YAML
profile can't pick one literal divisor. Result: a sensor that should
read 56.92 °C was being stored and alerted on as 5,692 °C.
- Towerops.Snmp.SensorScale.normalize/2: divide-by-10 a temperature
reading until it falls below 150 °C, capped at 3 iterations. Other
sensor types pass through untouched.
- DevicePollerWorker.poll_simple_sensor wires the normaliser in after
the YAML divisor is applied, so live polling stops storing bogus
values immediately.
- DeviceOverheating rule now bounds the query at 150 °C as defense in
depth so a future scaling glitch never produces a 5,000 °C alert.
- mix towerops.fix_mikrotik_temperature_scaling backfills any rows
already in the DB by re-running normalize/2 over them.
- routeros.yaml profile gets a comment pointing at the runtime
normaliser instead of a wrong unconditional divisor.
MikroTik mtxrGaugeTable temperature sensors report values in whole
degrees Celsius, not tenths. The MIB defines the unit as 'celsius(1)'
without the 'deci-' prefix used for voltage (dV), current (dA), and
power (dW).
This matches LibreNMS behavior which does not apply a divisor to
temperature sensors.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
