Duplicate sensors in DCE: MIB issue? DDF issue?

[4jp]

We have an issue that is consistent across all of our Liebert / Vertiv devices - in the sensors menu in DCE, there are multiple sensors that point to the same data point with different values and units of measure. 

For example there is an Output Source sensor and an UPS Output Source sensor (the latter showing the OID that it cooresponds to).

Now, I am not sure where this info is getting lost in translation - I can download the SNMPtraps file from one of these devices and it shows that the UPS Output Source sensor should have these values, which matches the generic sensor: 

I believe "output source" in this example is coming from the generic RFC 1628 MIB file, and the other sensors from one of the lgp customized MIB files from Vertiv

Here is what I don't understand:
I can directly query these OIDs and they return the correct values: 

But (at least what I believe) is the same OID / sensor in DCE just returns an integer - in this case a value between 1-7

These sensors not being queried correctly: can this be a symptom of a bad DDF, the MIB on the UPS not being constructed correctly, or something else within DCE? I've tested this on 7.8.1 and a brand new 8.0 installation, both with the latest Liebert DDF installed.

Also, why is the OID being listed as a part of the sensor name?

[4jp]

Just as an update to this.... I believe, at least some of the duplicates are originating from the generic RFC 1628 MIB file that all UPS's support - there is a setting (that defaults to ON) on the Vertivs that enables SNMP traps for the generic MIB files as well as the Liebert specific MIB files. This causes duplicate alerts / sensors to be created by DCE.

Now what I don't understand still - is why DCE doesn't seem to take this into account, why there is only units of measure on the sensors coming from the generic MIB, or if there is even a need to enable the generic one in addition to the Liebert one.

[Gabi]

Hello,

I cannot see your screenshots but:

there are two DDF on your DCE....one named Liebert and one UPS MIB

the second one contains RFC 1628 and you can disable it from your UPS management card

values with numbers and part of OID in sensor name is from Liebert DDF and have some issues 🙂

I do not know why they put all enterprise 476 in one huge file and they not split it by equipment type....at least

Vertiv use kind of table 

Name/OID: .1.3.6.1.4.1.476.1.42.3.9.20.1.10.1.2.1.4872; Value (OctetString): UPS Output Source

Name/OID: .1.3.6.1.4.1.476.1.42.3.9.20.1.20.1.2.1.4872; Value (OctetString): Normal

Name/OID: .1.3.6.1.4.1.476.1.42.3.9.30.1.40.1.2.1.4872; Value (Integer): enum (6)

Name/OID: .1.3.6.1.4.1.476.1.42.3.9.30.1.20.1.2.1.4872; Value (Gauge): 3

last one is the value and does not have a mapping like

<enumMap ruleid="upsOutputSource-em">
<label>Unknown</label> value 0
<label>Other</label> value 1
<label>None</label> value 2
<label>Normal</label> value 3
<label>Bypass</label> value 4
<label>Battery</label> value 5
<label>Booster</label> value 6
<label>Reducer</label> value 7
</enumMap>

LgpFlexibleBasicEntry
SEQUENCE
	lgpFlexibleEntryIndex	OBJECT IDENTIFIER
	lgpFlexibleEntryDataLabel	DisplayString
	lgpFlexibleEntryValue	DisplayString
	lgpFlexibleEntryUnitsOfMeasure	DisplayString

LgpFlexibleExtendedEntry
SEQUENCE
	lgpFlexibleEntryIntegerValue	Integer32
	lgpFlexibleEntryUnsignedIntegerValue	Unsigned32
	lgpFlexibleEntryDecimalPosition	Unsigned32
	lgpFlexibleEntryDataType	INTEGER
	lgpFlexibleEntryAccessibility	INTEGER
	lgpFlexibleEntryUnitsOfMeasureEnum	INTEGER
	lgpFlexibleEntryDataDescription	DisplayString

[4jp]

I was able to talk to someone at Vertiv to better understand this, but we think what's going on is that within the Vertiv MIBs there exists 2 tables that contain sensor values which Struxureware queries - lgpFlexibleBasicTable and lgpFlexibleExtendedTable.

In the lgpFlexibleBasicTable the "UPS Output Source" sensor - .1.3.6.1.4.1.476.1.42.3.9.20.1.20.1.2.1.4872 - queries as "Normal"

But in the lgpFlexibleExtendedTable, the same sensor (which has a slightly different OID -.1.3.6.1.4.1.476.1.42.3.9.30.1.20.1.2.1.4872) queries as "3"

These readings match exactly what the data mapping files from the UPS say about this sensor:

UPS Output Source,1.3.6.1.4.1.476.1.42.3.9.20.1.20.1.2.1.4872
 Possible states for the OID above:
  1: "Other"
  2: "Off"
  3: "Normal"
  4: "Bypass"
  5: "Battery"
  6: "Booster"
  7: "Reducer"

This behavior also matches the sensor values we see in DCE, so I'm thinking that for some reason the Vertiv/Liebert DDF is querying the wrong table, which is why so many of these sensors do not have a unit of measure.

There may be a good reason for this but I do not know why. Those two tables seem to contain the same information, just in different formats.