Define the UPS Data Dictionary Before Quoting DCIM Integration

Price meanings, not a protocol logo

“SNMP supported” leaves many quotation questions unanswered. Which points are present? Are they measurements, estimates or states? Does a receiver preserve their meanings? Which device/card revisions were checked?

Highidea documents communication options for relevant UPS products, but an interface option is not a complete point list. Request the selected card's documentation or an authorized representative readout. Record an unverified point as unknown rather than marking it available because the standard defines it.

RFC 1628 is a useful reference for UPS management semantics. It defines identification, estimated runtime, output-source states and scaled values. Its existence does not establish implementation on a particular host/card combination.

Work a small point dictionary

The following entries are illustrative RFC-based requirements, not a claim about a Highidea implementation. The selected supplier and integrator must populate their actual source and availability evidence.

The corresponding RFC objects are upsEstimatedMinutesRemaining for the runtime estimate, upsBatteryVoltage for battery voltage, and upsOutputSource for the output-source state. Keep these exact names in the implementation record.

Complete a worked voltage-point record

Use a fully specified point record for the actual quotation. The following worked entry describes RFC 1628's battery-voltage object only; implementation, receiver policy and acceptance are deliberately unresolved.

Do not apply the voltage object's rules to every other point. RFC 1628 defines upsEstimatedMinutesRemaining as a PositiveInteger estimate in minutes; a zero response needs implementation-specific investigation, not automatic acceptance as a standard unavailable marker. For upsOutputSource, the main object definition enumerates other(1), none(2), normal(3), bypass(4), battery(5), booster(6) and reducer(7); reconcile the exact supplier MIB and readout before accepting that receiver mapping.

Include the receiver's display name and transformation rule beside each source field. This makes a unit conversion or enum-mapping error visible during review, before it becomes a misleading dashboard.

Keep zero, unknown and stale distinct

A genuine reported zero, an unsupported point, a failed poll and an old retained value are different outcomes. If a receiver substitutes zero for all four, an outage can look like a real electrical observation.

Agree explicit states for unsupported, not yet observed, unavailable and stale. Preserve the last known value only with its age/status visible. Do not use it as a current measurement in an acceptance result.

For example, a previously received runtime estimate of 12 minutes that has not refreshed within the agreed observation policy should not silently remain a current “12 minutes remaining.” The 12-minute value is hypothetical, and this guide sets no universal poll or stale threshold.

Quote point-level delivery and acceptance

For every required point, identify supplier evidence, receiver mapping, transformation, display and proposed verification method. Classify it as confirmed, conditional, unsupported or not yet reviewed. Quote the unresolved work explicitly rather than promising a complete integration from a generic protocol statement.

A representative read-only comparison can verify type, unit and mapping where authorized. An alarm-delivery test is a separate exercise; a readable runtime point does not demonstrate notification routing or an end-to-end source event. Likewise, this dictionary does not authorize control-object writes.

Use the same dictionary during handover so the quoted scope and delivered scope can be reconciled without renaming points to hide omissions.

Keep the dictionary versioned

A card replacement, firmware change or receiver transformation can alter the interpretation. Record the tested equipment combination, dictionary revision and effective date. Refer unresolved differences to the responsible supplier and integrator.

Send Highidea the required point list with the desired integration scope. The result should identify the points verified for the selected implementation and price any remaining integration work explicitly.

Primary references

The references support the specific distinctions stated above. Manufacturer examples apply to their documented products; they do not establish the same capability in a Highidea model. Proposed worksheets and hypothetical examples are editorial decision tools, not approved installation or operating procedures.

IETF / RFC Editor: RFC 1628: UPS Management Information Base