fix(librenms-health): report numeric sensors that breach their limits#1329
Open
NavidSassan wants to merge 1 commit into
Open
fix(librenms-health): report numeric sensors that breach their limits#1329NavidSassan wants to merge 1 commit into
NavidSassan wants to merge 1 commit into
Conversation
The plugin derived a sensor's state only from LibreNMS' state_generic_value, which is populated exclusively for discrete state-class sensors. For numeric sensors (temperature, humidity, voltage, power, ...) that column is NULL, so every over- or under-limit reading was silently reported as OK. Mirror LibreNMS' own Sensor::currentStatus() so the check agrees with the severity shown on the LibreNMS device health pages: CRITICAL at or beyond the hard sensor_limit / sensor_limit_low, WARNING at or beyond the soft sensor_limit_warn / sensor_limit_low_warn (inclusive comparison), UNKNOWN for a state sensor without a translation or a numeric sensor without a reading. The decision is extracted into a pure get_sensor_state() helper computed before the row values are turned into display strings. The value column now shows both limit ranges as "low_warn..high_warn/low_crit..high_crit" (header "Val (warn/crit Range)"); an unset range is shown as "-" so the remaining one stays unambiguous, since LibreNMS auto-discovery commonly configures only the critical limits. Add a --test seam plus a unit-test suite (15 cases) covering the warn/crit low and high bands, inclusive boundaries, single-sided limits, the "-" placeholder, state sensors, missing readings, mixed batches and --always-ok, driven by JSON row fixtures without a live database. Also drop three dead HTTP-era DEFAULT_* constants and the unused lib.librenms import.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
librenms-healthderived each sensor's state solely from LibreNMS'state_generic_value, which LibreNMS populates only for discrete state-class sensors (fan ok/fail, psu present/absent, ...). For numeric sensors (temperature, humidity, voltage, power, ...) that column isNULL, so the plugin forced them to OK and every over- or under-limit reading was silently reported as OK. A humidity sensor reading 71.7 with a high limit of 70 showed[OK]while LibreNMS itself flagged it critical.This is not a regression: numeric-limit alerting was never implemented (the pre-2024 API version never set a state at all).
Fix
Mirror LibreNMS' own
Sensor::currentStatus()so the check agrees with the severity shown on the LibreNMS device health pages:sensor_limit/sensor_limit_lowsensor_limit_warn/sensor_limit_low_warn>=/<=), matching LibreNMSThe decision lives in a pure
get_sensor_state()helper, computed before the row values are turned into display strings.Output
The value column now shows both limit ranges as
low_warn..high_warn/low_crit..high_crit(headerVal (warn/crit Range)). An unset range renders as-so the remaining one stays unambiguous — LibreNMS auto-discovery commonly configures only the critical limits, so many sensors legitimately show only a critical range:Tests
Adds a
--testseam plus a 15-case unit-test suite (JSON row fixtures, no live database) covering the warn/crit low and high bands, inclusive boundaries, single-sided limits, the-placeholder, state sensors, missing readings, mixed batches and--always-ok.Also
DEFAULT_*constants and the unusedlib.librenmsimport.