[Nut-upsdev] [nut] question regarding potential new smart driver or patches for existing apcsmart driver

[Arnaud Quette]

Hi Michal,

I'm cc'ing the NUT development mailing list. you should also subscribe to
it.

2010/10/28 Michal Soltys

> Greetings
>
> I have loads of relatively old smart upses that I currently control using a
> bit patched version of apcupsd - the reason for those patches is the age of
> the upses - roughly 10 years old+, which are can be a bit tricky to control.
> From issues related to them:
>
> - no eeprom programming or calibration. So - no grace periods or minimal
> battery level to power up
> - @000 command is no-op - the only effect of it is happy led flashing
> - @nnn will power up the ups right after 6*nnn minutes unconditionally
> (regardless if the power returned or not - modern units are smarter, and the
> delay is counted from power's return + eeprom preprogrammed delay)
> - S as usual works only when on batteries, but with no eeprom programmed
> delays, the ups is up as soon as the power is back
> - low power signal (both on old and new units) is somewhat unreliable as
> far as APC upses go - and in my experience it's far better to just monitor
> remaining time and/or current battery level and issue shutdown when
> necessary (so in context of nut's driver - provide "custom" LB status)
>
> Anyway, I submitted the patches to apcupsd, but while some of them might go
> into upstream (ignore low battery knob) other ones (knobs to control manual
> delays and selection of shutdown methods) are for now considered too complex
> for users (?).
>
> Having peeked into nut sources, my question thus is: would a patch adding
> either a new driver (probably far better option) or adding a set of options
> to existing apcsmart driver (worse option) be acceptable ? The features that
> would be provided:
>
> - precise shutdown method control (S, @, K, +potential hacks)
> - allow supplying @'s delay
> - ignore or honor ups-sent low batt signal
> - using battery level and/or time as calculated by ups to decide on
> shutdown moment (so kinda provide "custom" LB info) - with levels controlled
> by user
> - anything else needed
>
> As you can see, the general functionality would look similar to apcupsd's
> smart part.
>
> I don't know when/if I have time to add it, but nut's code looks pretty
> clean + there's good amount of docs, so it should be doable in not too
> distant future and in reasonable timeframe.
>
> Either way, is there a chance for future upstream-inclusion of such driver
> ?
>

sure, more than a chance ;-)
you will have to follow the NUT developer guide (
http://new.networkupstools.org/developer-guide.html) chapters 3 and 4.
the preferred way is to enhance apcsmart, in a way that doesn't introduce
possible regressions on working models.
thus, in case you doubt, prefer to create a driver option to enable it.
you will get help by posting your contributions and asking for comments on
the NUT development mailing list.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20101028/797f2bfa/attachment.htm>