Why a threshold is a decision, not a number
A reading is data. A threshold is a decision that encodes three things: the value that is acceptable, the action that follows, and the person who carries it out. Get any one of them wrong and the instrumentation is worthless: a tight limit produces alarms nobody believes, and a loose one produces silence until something fails on its own terms. That is why the published mechanism on the Newsunn intelligent PDU range is a decision framework rather than a feature list. The unit accepts limit values and raises alarms when they are crossed; it cannot know which values suit a room, who is on call, or what should happen to the load if the condition persists.
- The value states the worst condition you accept in that cabinet, not a specification copied from a data sheet.
- The action is part of the threshold: the same value can raise an alarm or, with the published power-off capability, cut power.
- The owner decides whether a 03:00 alert is a useful escalation or an irritation that trains people to ignore it.
The measurement point: what the published sensor set actually is
The published sensor set is small and specific. Temperature and humidity monitoring is available, and that sensor is sold separately. Door, smog and water logging sensors are optional. The metering list published for total metering covers total current, voltage, power, energy, temperature, humidity, smog, water logging and entrance guard.
Two consequences follow. The sensor is a separate item, so a PDU can arrive with the port on the panel and nothing fitted to it, so it belongs in the specification as a named line. And it measures the air where it is mounted: one sensor on one PDU is one point for one rack, not a measurement for every device in it, and the value you threshold is the cabinet’s air rather than the server inlet.
The limit mechanism the PDU gives you
The published function matrix on the 3-phase intelligent monitored PDU is where the mechanism becomes concrete. Under setting a limit value to alarm, the published limiting ranges cover total load current, the load current of each outlet, the working voltage, and temperature and humidity. Under system automatic alarm, the published alarm conditions are total load current over limit, outlet load current over limit, temperature or humidity over limit, smog, water logging and door opening.
Which lines exist in a given unit is decided by the function model, published as combinations of metering and switching.
| Function model | Published combination | What it means for thresholds |
|---|---|---|
| Type A | Total metering + total switching + individual outlet metering and switching | Total, outlet and environmental limit rows all apply |
| Type B | Total metering + total switching | Total and environmental limits; no outlet-level limit rows |
| Type C | Total metering + individual outlet metering | Total and environmental limits, per-outlet current |
| Type D | Total metering | Total and environmental limits; the smallest configuration to specify |
Note what is not in this mechanism. The PDU compares a value against a limit and raises an alarm. It does not know whether the alarm matters, who is on shift, or whether the condition is a one-off or a trend. Those jobs belong to the platform.
The shipped defaults are not thresholds
The published Alarm Limit screen is the clearest evidence of how this is meant to work. The General Setting table lists nine editable limit values, and a shipped unit shows: temperature upper limit 90, temperature lower limit 1, humidity upper limit 90, main current first upper limit 28, main current second upper limit 32, sublet current first upper limit 16, sublet current second upper limit 20, voltage upper limit 270 and voltage lower limit 80.
Read those as what they are: a generic product default set. A temperature and humidity upper limit of 90 will not alert you before a condition becomes a problem, and a temperature lower limit of 1 is effectively a floor. They will not cause false alarms in a warehouse, and they are useless as protection in a live data hall.
The menu around that screen is informative too: System info, Overview, Alarm Limit, Outlet Control, Outlet Current, Set Delaytime, Rename Outlet, Open Door, SMS Alarm, IP Setting and Logout. The threshold sits next to the actions you take when it fires, which suggests how the unit is meant to be used: configured once, then left alone. The same material is published on the intelligent power distribution unit solution page.
Where the threshold should come from
The basis for the number is not the PDU catalogue. It is the environment class of the equipment in the cabinet, because that is what its manufacturer designed for. ASHRAE’s data centre resources set out the recommended and allowable envelopes for classes A1 to A4, and those are the numbers to start from: take the recommended range for your class, then place the PDU limit inside it rather than at the allowable edge.
Placing the limit inside the recommended envelope is arithmetic, not timidity. The sensor is not at the server inlet; it sits in the cabinet and sees its mixed air, and the recommended envelope already carries margin for it. Set the limit at the allowable edge and the sensor offset becomes a false alarm.
Temperature and humidity are two decisions rather than one. Humidity carries two failure directions: high humidity against a cool surface produces condensation, while low humidity is the static and corrosion regime. The published interface exposes one humidity upper limit, so if both directions matter, the second belongs on the platform. And because the published power-off capability can cut power, a threshold is also a switching decision belonging to whoever owns the response plan.
Warning, limit, power-off: three thresholds, three owners
The published PDU gives you one class of limit per measured value and fires when the value crosses it. Everything graduated above that has to live elsewhere.
| Layer | Where it is set | What it does | Who owns the response |
|---|---|---|---|
| Advisory | Monitoring platform, from reported values | Trend against the class envelope; ticket only | Monitoring team, in hours |
| PDU limit | The PDU Alarm Limit screen | Crossing the value raises the published automatic alarm and notification | On-call engineer |
| PDU power-off | The same value, with the published power-off capability enabled | Equipment is powered down when the limit is exceeded | Operations lead, pre-authorised |
The layer that is usually missing is the middle one, for an understandable reason: nobody wants to be the team paged for a threshold they did not set. The way out is to write the threshold into the response plan with a name attached, and to accept that the PDU will alarm on it whether or not the plan is followed.
How the alarm actually reaches a human
The published notification set is four channels and they are not interchangeable. Audible alerting matters when somebody is in the aisle. Email and SMS alerting reaches a person, with the published feature of alerting users to impending power overloads or temperature problems. SNMP traps are for the systems layer, and the product pages publish that power events are pushed immediately by email, SMS text or trap.
For the systems channel, be precise. The objects a trap carries and their semantics are described in the SNMP application documents, RFC 3413; the convention for defining traps is RFC 1215, the reference to point a supplier at if a custom value has to be added; and the transport mapping, including where a trap is delivered, is RFC 3417. A trap a platform cannot interpret exists only in the PDU.
One more published fact belongs in the specification. The protocol set is SNMP v1 and v2, with Modbus TCP/IP and Modbus RTU over RS-485, and IPv4 for browser access. Version 1 and 2 carry community strings rather than the user-based security model in RFC 3414, so the management path has to be isolated and access-controlled at the network layer, and that cannot be added to an installed fleet afterwards.
The acceptance test that proves the threshold works
A threshold that has never been seen to fire is an assumption, and the test is simple. For every configured limit, drive the value past it and confirm four things: the PDU raises the published automatic alarm, the notification arrives on each configured channel, the platform records the value and the event, and, where power-off is enabled, the load goes down as the response plan describes.
Test the sensor connection in the same session. Because the sensor is sold separately, confirm at handover that it is fitted to the Temp/Humidity port and reporting a plausible value: a port with no sensor behind it reads a default rather than failing loudly, the quietest failure mode in the list. Record the shipped limit values next to the configured ones, with the date and the name of the person who set them.
Two disciplines keep thresholds alive. Repeat the acceptance test after a firmware update, because the published firmware is downloadable over the network and a configuration reset carries maintenance-window risk. And keep a short response note next to the alarm definition: what the value means, what to check first, who may authorise the power-off.
What to write into the purchase specification
Most lines in a specification are decisions rather than products. Name the function model, because the published limit and alarm rows differ between models. Name the sensor list explicitly, including the temperature and humidity sensor as a separate line, plus door, smog and water logging where the room justifies them. Confirm the unit carries the Temp/Humidity port and the Sensor port for smoke and water, with Ethernet, RS-485 and I/O as required.
Then specify the behaviour: that limit values for temperature and humidity are configurable and visible in the published menu, that the notification set includes audible, email and SMS plus SNMP trap, that the platform consumes the traps, and that firmware remains upgradeable. Add the quality evidence you expect, published for this product line: 2000 V hi-pot, ground and insulation resistance testing, a 48-hour online aging test, a 120 % load test and function testing, with the certification marks your market requires: CE, GS, UL, NF and EESS. ISO 9001 asks any supplier to evidence that.
The last line is the one people forget. If the thresholds belong to your site, the documented settings, the response plan and the handover file should travel with the equipment as a set, and any OEM programme should be built around that set rather than the metal box. The published OEM flow is straightforward: the requirement is confirmed on a drawing, a sample is made for testing, and mass production follows.
Questions from the people who own the thresholds
What temperature and humidity thresholds should a rack PDU use?
There is no universal pair, and anyone who quotes one is quoting a default. Take the recommended envelope for the equipment class in that cabinet from ASHRAE’s data centre resources, set the limit inside the recommended band rather than at the allowable edge, treat humidity as a separate decision, and check what the unit shipped with.
Our PDUs arrived without a temperature sensor. Can one be added later?
The hardware supports it: the control module carries a dedicated Temp/Humidity port and a Sensor port for smoke and water. What has to be ordered is the sensor itself, published as a separate item. Specify it as a named line, confirm at handover that it is fitted and reporting, and check the shipped limit values, because a sensor added later will not set its own thresholds.
Is one threshold for the whole row enough, or does every cabinet need its own?
Every cabinet needs its own value, because one sensor on one PDU is one point for one rack, and no two cabinets carry the same load or airflow. Type A carries total and individual outlet metering and switching where you need that. Set values per cabinet and let the platform aggregate.
Who responds when a temperature alarm fires at 03:00, and who owns the decision to power off?
The PDU detects and notifies; it does not decide who acts. The published capability is that a threshold raises an alarm and, where enabled, powers equipment down. That makes the power-off a switching decision to be pre-authorised: the value, the scope, the authoriser and the person called at 03:00 belong in the response plan before the limit is typed in.
We are a colocation site with mixed loads and we are worried about alarm fatigue. How do we avoid it?
Split the layers and you get most of the way there. Keep advisory thresholds on the platform, where they can sit close to the class envelope and trend quietly, and reserve the PDU limit for a value that needs a person. Set that value per cabinet rather than per row, and de-duplicate on the platform side so one condition does not arrive as forty messages.
Engineering note and the author
Newsunn
Senior PDU Product Engineer, Ningbo Hi-Tech Zone Newsunn Optronics Technology Co., Ltd.
We design and manufacture rack power distribution units, and we have more than a decade of it. The team is backed by eight R&D engineers and a 30,000 square metre production base, which means the range runs from standard rack units through to fully customised intelligent power distribution systems.
Our work is mostly on the electrical side of the rack: metering that a monitoring platform can consume, switching that a response plan can use, and form factors that fit the rack you already have. Environmental thresholds sit between the two, because a sensor reading becomes protection only once somebody has decided what the number should be and who has to answer it.
Post time: Oct-29-2026