[Nut-upsdev] Some questions on driver implementation and variable

[Peter Selinger]

Hi Edgar,

did you check if your device is already supported by the
newhidups/usbhid_ups driver? This driver supports all USB HID devices,
and even if your device is not supported "out of the box", it is
usually a question of adding a few lines of code to support a new
device. You can run the newhidups/usbhid_ups driver with the "-x
explore" option to print enough debugging information to determine if
the device is supportable. 

On the other hand, if it is not a HID device, then it is most likely a
serial-over-USB protocol, which is not be supported by the
newhidups/usbhid_ups driver, but might be supportable by one of the
existing serial-over-USB drivers (megatec_usb, tripplite_usb, etc).

An entirely new driver would only be warranted if it's a genuinely new
protocol.

If you post your driver here, someone can probably tell you if the
protocol resembles a known one. 

-- Peter

Edgar Fuss wrote:
> 
> I've just written an NUT driver to manage a Masterguard UPS connected  
> via USB, and some questions arose.
> 
> Why I wrote a new driver? The servers in question only have two  
> serial ports, so I want to use USB. I first wrote the low-level USB  
> routines expecting to integrate them into the existing masterguard  
> driver. However, that driver was so rudimentary I wrote my own one.  
> It can be trivially extended to talk via a serial line.
> 
> Now to my questions:
> 
> In case there is some variable (like ups.power) the UPS does not  
> directly exhibit, but which can be computed by other known values  
> (nominal power, load); should I compute and set that variable or  
> should I only set values directly obtained form the UPS?
> 
> There are variables for minimum and maximum observed input voltage,  
> but not for frequencies. Is it OK to set input.frequency. 
> {minimum,maximum}?
> 
> We have input.transfer.low and the like, but this UPS also gives me a  
> frequency range outside which it will go offline. Any variable names  
> for that?
> 
> Same for temeratures: We have ambient.temperature.alarm.{min,max} 
> imum, but nothing nike it for ups internal temperatures.
> 
> I assume battery.runtime shold give the estimated runtime under  
> current load. I also have nominal on-battery runtime for 100% and 50%  
> load. Any names for those?
> 
> When running a battery test, apart from running until empty, I can  
> set a time. Anything like ups.test.duration?
> 
> In case my setvar routine knows the name, but the value is illegal, I  
> suppose I have to return STAT_SET_UINKNOWN despite the name being  
> known, right?
> 
> If I accept a setvar(), do I have to dstate_setinfo() the variable or  
> does some generic routine do so for me?
> 
> Does "calibrate" mean to run on battery until exhausted or seomething  
> else?
> 
> The text for the "OB" status says "inverter is powering the load".  
> Despite that, I assume that with an online UPS, I'm not supposed to  
> always set that flag, but only when on battery, right? Am I right to  
> believe that "OL" and "OB" are mutually exclusive?
> 
> Finally, I'm not sure I understand the different ups.delay.*  
> variables correctly. When initiating a shutdown, there are two things  
> I can set: The duration of the countdown (e.g. time from now to power- 
> off) and the time from then until restarting the load (the UPS will  
> always auto-power-on after a line failure). I guess the later is  
> ups.delay.start and the former is ups.delay.reboot for  
> shutdown.reboot.graceful, zero for shutdown.reboot and  
> ups.delay.shutdown for shutdown.{return,stayoff}. Or am I getting it  
> wrong?
> 
> Thanks for your help.