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

[Edgar Fuß]

> Can you post the driver here, even if it is not completely ready?
I can post what I've got so far for review purposes, sure. I was not  
in a mood of testing shutdown commands and the like from home (the  
UPS is installed at work). I will incorporate changes based on your  
comments before I post. Also, I'll have to ask a few more questions  
at the incredibly helpful technicians at Masterguard tomorrow.

> My personal opinion is, don't bother with it.
As this seems to make for a lot of debate, I'll probably go for  
#ifdef INFER.

> If these are not read from the UPS, don't make them up.
So drivers should also not make up for minimum and maximum observed  
input voltage? I saw several drivers doing so.

> Yes, input.frequency.low/high. See 'docs/new-names.txt'.
I guess my version of that file is out-dated (it's from 2.0.4).

> Please use the battery temperature for that.
Hm? I don't see min/max values there either. Besides, I don't know  
the battery temperature with the external packs of an A3000-19.

> Generally speaking, you'd need dstate_setinfo() to propagate  
> changes to
> the server (and ultimately the clients) too.
I meant the following: If the generic code calls my setvar() routine  
and I return STAT_SET_HANDLED, then the generic code could set deduce  
that the variable has changed to the value given. Instead, I  
additionally call dstate_setinfo() to propagate the value?

> That depends on the driver, but if you have the choice, I would opt  
> for
> the time until "LB" (Low Battery) is signalled.
OK, so "calibrate" means "try to run on battery as long as possible now"

> These delay values are always good for a lot of confusion.
Ah. Thanks a lot for your explanation.
I've no influence on the behaviour when power returns. The UPS will  
simply turn on immediately.