[Nut-upsdev] [PATCH 12/36] ups.id and battery.date can be changed at any time by SNMP
Arnaud Quette
aquette.dev at gmail.com
Mon May 14 08:22:19 UTC 2012
Greg,
2012/3/9 Greg A. Woods <woods at planix.com>:
> From: "Greg A. Woods" <woods at planix.com>
>
> Do not mark them as a static values.
> ---
> drivers/apc-mib.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/apc-mib.c b/drivers/apc-mib.c
> index 30a0ebb..ef78503 100644
> --- a/drivers/apc-mib.c
> +++ b/drivers/apc-mib.c
> @@ -171,8 +171,8 @@ static snmp_info_t apcc_mib[] = {
> { "battery.current", 0, 1, ".1.3.6.1.4.1.318.1.1.1.2.2.9.0", "", SU_FLAG_OK, NULL },
> { "battery.packs", 0, 1, ".1.3.6.1.4.1.318.1.1.1.2.2.5.0", "", SU_FLAG_OK, NULL },
> { "battery.packs.bad", 0, 1, ".1.3.6.1.4.1.318.1.1.1.2.2.6.0", "", SU_FLAG_OK, NULL },
> - { "battery.date", ST_FLAG_STRING | ST_FLAG_RW, 8, ".1.3.6.1.4.1.318.1.1.1.2.1.3.0", "", SU_FLAG_OK | SU_FLAG_STATIC | SU_TYPE_STRING, NULL },
> - { "ups.id", ST_FLAG_STRING | ST_FLAG_RW, 8, ".1.3.6.1.4.1.318.1.1.1.1.1.2.0", "", SU_FLAG_OK | SU_FLAG_STATIC | SU_TYPE_STRING, NULL },
> + { "battery.date", ST_FLAG_STRING | ST_FLAG_RW, 8, ".1.3.6.1.4.1.318.1.1.1.2.1.3.0", "", SU_FLAG_OK | SU_TYPE_STRING, NULL },
> + { "ups.id", ST_FLAG_STRING | ST_FLAG_RW, 8, ".1.3.6.1.4.1.318.1.1.1.1.1.2.0", "", SU_FLAG_OK | SU_TYPE_STRING, NULL },
> { "ups.test.result", ST_FLAG_STRING, SU_INFOSIZE, APCC_OID_TESTDIAGRESULTS, "", SU_FLAG_OK, apcc_testdiag_results },
> { "output.voltage", 0, 1, ".1.3.6.1.4.1.318.1.1.1.4.2.1.0", "", SU_FLAG_OK, NULL },
> { "output.phases", ST_FLAG_STRING, 2, ".1.3.6.1.4.1.318.1.1.1.9.3.2.1.2.1", "", SU_FLAG_STATIC | SU_FLAG_OK, NULL },
this patch should not be needed:
this SU_FLAG_STATIC is just there to avoid refreshing data that are
not changing, apart from user settings.
in this last case, the data is both set in the device, and updated in
NUT (Ie dstate_setinfo...)
have you had any specific issue that motivated this change?
For now, I'll postpone this patch.
FYI, a complete rewrite of snmp-ups is scheduled, to be up to par with
the latest generic engine and features (as in usbhid-ups).
the same mechanisms are applicable on both sides...
cheers,
Arnaud
--
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
More information about the Nut-upsdev
mailing list