[Nut-upsdev] Liebert PSI 1440 support
stewart at nameless-uk.com
Wed Oct 12 09:43:53 UTC 2005
Sorry I've not responded sooner, Real Life seems to have taken over
> This looks really good. In fact, it looks like the driver should be
> working - there is even a valid status indicator (OL CHRG).
This is good news! :)
> Now only some fine-tuning remains to be done.
> 1) to figure out what those remaining usages are:
[ Order rearranged ]
>>Path: UPS.00860006.00860083, Type: Feature, Value: 120.000000
> Could be a voltage?
This *could* refer to (from the manual): "the mains transfer voltage at
which the UPS will switch to battery power. This also affects the
According to the manual, it's measured in the US volt-range, but seems
to be automagically translated into the UK realm:
| Setting | Input Voltage | Output Voltage |
| | Range | (Battery Mode) |
| 120V (230V) | 166-272VAC | 230VAC |
| 110V (220V) | 158-260VAC | 220VAC |
| 127V (240V) | 172-283VAC | 240VAC |
"120V" is the default. I'll be able to confirm/denounce this if/when I
get a chance to offload the UPS
>>Path: UPS.00860006.00860080, Type: Feature, Value: 2.000000
>>Path: UPS.00860006.00860081, Type: Feature, Value: 0.000000
>>Path: UPS.00860006.00860082, Type: Feature, Value: 2.000000
>>Path: UPS.00860006.00860084, Type: Feature, Value: 2.000000
>>Path: UPS.00860006.00860085, Type: Feature, Value: 3.000000
>>Path: UPS.00860006.00860086, Type: Feature, Value: 3.000000
>>Path: UPS.00860006.00860087, Type: Feature, Value: 0.000000
> You can also try to see if some of these variables are writable (using
> upsrw), and figure out what the effects are (but careful - it might
> cause a shutdown. Make sure your computer does not depend on the UPS
> for power).
Yeah, this is a bit of a problem ATM; the UPS was originally bought
because we were having quite a few power-glitches (not full-out
failures). Consequentially, there's quite a bit of kit running off it
which needs to be powered elsewhere whilst testing -- this means weekend
time, of which I've not had much recently *sigh*. I'll see what I can
do this weekend tho.
Would there be any mileage in contacting Liebert directly? In which
case, what exactly am I asking for? A feature-descriptor map?
> 2) map any variables that are currently unmapped to variables or
> instant commands
Something I can do now is to install the Windows monitoring stuff onto
a laptop and see if anything looks like a good match...
Interestingly, the following, for example, all seem to me to be
multiplied by ten. Does that mean I need to change the last arg to
"liebert_10_conversion" in the lookup table?
> (e.g. UPS.LIEBERTControls.LIEBERTLoadOn and
> UPS.LIEBERTControls.LIEBERTLoadOff are currently unmapped, as are
> UPS.LIEBERTPowerState.LIEBERTInput.LIEBERTTemperature and several
> others (is this temperature in Celsius?)
How do you infer that they are unmapped? Is it because there is
nothing in the lookup table?
> 3) Another thing to figure out is if some sort of shutdown procedure
> will work. This is the Achilles heel of the Belkin - hopefully the
> Liebert will do better. In principle, this should be done by writing
> various combinations of values to
If I understand this those labels correctly, writing "1" (or more) to
the *LoadOn/Off descriptors should switch the output on/off
For these: *DelayBeforeShutdown corresponds to an interval after which
the load is switched off (whether there is line-mains or not)? And for
*DelayBeforeStartup would wait for the line-mains to have been around
for the specified period before switching the load back on?
> (USB variables shown here, not NUT variables).
> This needs to be tested quite thoroughly - for example, each shutdown
> could be:
> - a final shutdown (power will not come on until requested explicitly),
> - a timed shutdown (power comes on after specified time, whether there
> is a power outage or not)
> - a smart shutdown (power stays off during power outage, comes back on
> after outage ends, and possibly after battery charges to a
> minimum level - or if there is no power outage in progess, power
> just goes off for a few seconds).
> A smart shutdown is what is needed most. The problem with Belkin is
> that it does not implement one. I hope the Liebert does. Your
> experimentation will be needed.
Indeed. Well, hopefully I'll be able to get some testing done this
More information about the Nut-upsdev