[Nut-upsdev] Liebert PSI 1440 support

[Stewart Morgan]

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,