Arnaud Quette
2008-May-07 13:38 UTC
[Nut-upsuser] validating ambient.temperature from APC IEM (AP9618, AP9619) patch
Hi Dmitry and the list, would you (or anyone owning such a device) be able to validate the below patch: https://alioth.debian.org/tracker/index.php?func=detail&aid=310613&group_id=30602&atid=411542 Most notably, it's about the paths changes: -#define APCC_OID_IEM_TEMP ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.0" -#define APCC_OID_IEM_TEMP_UNIT ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.5.0" +#define APCC_OID_IEM_TEMP ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.1" +#define APCC_OID_IEM_TEMP_UNIT ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.5.1" #define APCC_IEM_FAHRENHEIT 2 -#define APCC_OID_IEM_HUMID ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.6.0" +#define APCC_OID_IEM_HUMID ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.6.1" thanks, Arnaud -- Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/
Dmitry Frolov
2008-May-08 06:52 UTC
[Nut-upsuser] validating ambient.temperature from APC IEM (AP9618, AP9619) patch
Please CC me on replies, as I'm not subscribed. * Arnaud Quette <aquette.dev at gmail.com> [07.05.2008 20:38]:> Hi Dmitry and the list, > > would you (or anyone owning such a device) be able to validate the below patch: > https://alioth.debian.org/tracker/index.php?func=detail&aid=310613&group_id=30602&atid=411542 > > Most notably, it's about the paths changes: > -#define APCC_OID_IEM_TEMP ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.0" > -#define APCC_OID_IEM_TEMP_UNIT ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.5.0" > +#define APCC_OID_IEM_TEMP ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.1" > +#define APCC_OID_IEM_TEMP_UNIT ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.5.1" > #define APCC_IEM_FAHRENHEIT 2 > -#define APCC_OID_IEM_HUMID ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.6.0" > +#define APCC_OID_IEM_HUMID ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.6.1"It will probably work here on SURT5000XL+AP9619, that I have access to, i.e. starting index in iemStatusProbesTable is 1, not 0: PowerNet-MIB::iemStatusProbesNumProbes.0 = INTEGER: 1 PowerNet-MIB::iemStatusProbeNumber.1 = INTEGER: 1 PowerNet-MIB::iemStatusProbeName.1 = STRING: "Integrated" PowerNet-MIB::iemStatusProbeStatus.1 = INTEGER: connected(2) PowerNet-MIB::iemStatusProbeCurrentTemp.1 = INTEGER: 24 PowerNet-MIB::iemStatusProbeTempUnits.1 = INTEGER: celsius(1) PowerNet-MIB::iemStatusProbeCurrentHumid.1 = INTEGER: -1 PowerNet-MIB::iemStatusProbeHighTempViolation.1 = INTEGER: disabled(3) PowerNet-MIB::iemStatusProbeLowTempViolation.1 = INTEGER: disabled(3) PowerNet-MIB::iemStatusProbeHighHumidViolation.1 = INTEGER: disabled(3) PowerNet-MIB::iemStatusProbeLowHumidViolation.1 = INTEGER: disabled(3) As I can see the 0-s at the end of the OIDs were added blindly while converting GETNEXT->GET, so replacing them with 1-s shouldn't break anything. Here is a sample snmpwalk on SURT5000XL+AP9619 and SU750RM+AP9617 for reference if anyone needs it: http://kaya.nov.net/frol/tmp/apc-snmpwalk.zip> > thanks, > Arnaud > -- > Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com > Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ > Debian Developer - http://people.debian.org/~aquette/ > Free Software Developer - http://arnaud.quette.free.fr/