[Nut-upsdev] Liebert PSI 1440 support
selinger at mathstat.dal.ca
Wed Oct 12 16:08:16 UTC 2005
I'll get back to you next week. Real life is catching up with me as
Just a quick comment: The "divide by 10" conversion is already taken
care of by the driver. You should try
"upsc your-ups at localhost"
to see all the variables that the driver actually reports. Don't rely
only on debug messages - because they are meant for debugging. To see
what the driver does, you need to play with "upsc" and perhaps
"upsrw". "upsc" is read-only and so is not dangerous.
Stewart Morgan wrote:
> Hi Peter,
> Sorry I've not responded sooner, Real Life seems to have taken over
> recently :)
> > 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
> inverter voltages."
> 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?
> UPS.LIEBERTPowerState.LIEBERTInput.LIEBERTVoltage: 2370
> UPS.LIEBERTPowerState.LIEBERTInput.LIEBERTFrequency: 500
> UPS.LIEBERTPowerState.LIEBERTOutput.LIEBERTVoltage: 2389
> UPS.LIEBERTPowerState.LIEBERTOutput.LIEBERTFrequency: 500
> UPS.LIEBERTBatterySystem.LIEBERTVoltage: 560
> > (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
> > UPS.LIEBERTControls.LIEBERTLoadOn,
> > UPS.LIEBERTControls.LIEBERTLoadOff,
> If I understand this those labels correctly, writing "1" (or more) to
> the *LoadOn/Off descriptors should switch the output on/off
> respectively, yes?
> > UPS.LIEBERTControls.LIEBERTDelayBeforeShutdown,
> > UPS.LIEBERTControls.LIEBERTDelayBeforeStartup
> 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
> weekend! :)
More information about the Nut-upsdev