On Jul 16, 2015, at 5:09 AM, paul at paulcarmichael.org wrote:
> On 10/07/15 04:26, Charles Lepple wrote:
>> On Jul 9, 2015, at 9:43 AM, paul at paulcarmichael.org wrote:
>>
>>> Is there currently a way of implementing NUT with an Ovislink
Chrome 1500 UPS?
>>
>> Not sure. There was a thread in February talking about an Ovislink
Chrome 1000, but I don't think we ever resolved what was causing the
"Device busy" error:
>
> Is there an "official" way to request support for a certain UPS?
The words "official" and "support" are somewhat overloaded.
As implied in the "no warranty" clause in the GPL, "support"
means that the software attempts to work with a given device-- rather than
"support" as in "support contract". So if there is no
warranty, what does that mean in practical terms? I'll try to explain in
terms of other UPS manufacturers:
MGE Office Protection Systems (and to some degree, Eaton) have supported NUT
driver development in the past by providing engineering resources as well as
protocol documentation for their hardware. This corresponds to a "support
level" of 5 stars (out of 5) in our Hardware Compatibility List (HCL),
although there is a bit of a backlog of unanswered questions recently:
http://www.networkupstools.org/stable-hcl.html
Tripp Lite put some engineering resources into testing their USB HID PDC
hardware against NUT, which saves users from having to do that themselves.
However, there are still a few vendor-specific HID values that we don't know
what they mean, and there are some models that return improperly scaled values.
(Documented in on the mailing lists and in the DDL, if you are interested.)
Still, fairly solid for unattended shutdowns.
APC also uses the USB HID PDC standard for their hardware, but they also have
various other open and proprietary protocols that I am not very familiar with
(my HID UPS from 2002 predates the proprietary switch). To my knowledge, they
have not contacted the NUT project about testing, but I would imagine they would
reach out to the apcupsd project first.
From what I can tell as an outsider, these companies are large enough to do the
engineering in-house for their hardware (or to lean on their contractors to get
protocol documentation). The "ATCL FOR UPS" module in your UPS is
likely an OEM part, and so if you were to ask Ovislink for protocol
documentation, they might not have much leverage with the OEM (depending on how
many other manufacturers would continue to buy that part without documentation).
Publishing the documentation might also be seen as an affront to the company
that makes the official software for your UPS, although that software is often
free-as-in-beer these days.
As a customer, you could still ask for protocol documentation, though. I suspect
that many UPS vendors are not familiar with the portion of their customer base
that uses Unix-like OSes.
After that, there is a bit of software engineering to do. This is where you
would want to do a cost-benefit analysis: if you only have one UPS from a given
vendor, spending a lot of time on writing and debugging a driver may not be
worthwhile. However, if you have a large deployment, or if it turns out that
only minor changes are needed to an existing driver, it might be cheaper than
upgrading to an already-supported UPS model.
(Usual disclaimers apply: I am speaking from my own experience, and not for my
employer. If it looks like an opinion, it probably is-- but feel free to ask for
clarification and facts to back up the opinions.)
--
Charles Lepple
clepple at gmail