On Jul 16, 2015, at 5:09 AM, p...@paulcarmichael.org wrote: > On 10/07/15 04:26, Charles Lepple wrote: >> On Jul 9, 2015, at 9:43 AM, p...@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@gmail _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
