[Nut-upsdev] Liebert PSI 1440 support

[Peter Selinger]

I'll get back to you next week. Real life is catching up with me as
well :)

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.

-- Peter



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! :)
> 
> 
> 
> Stewart,
>