Nut upsdev - Jul 2014 - Documenting the NUT driver-qualification process

On 7/9/2014 6:51 AM, Charles Lepple wrote:
> On Jul 9, 2014, at 6:31 AM, Eric S. Raymond<esr at thyrsus.com> 
wrote:
>
>> What I'd like to do is this: confer in real-time, perhaps via IRC,
>> with someone who knows this process.  Ask about every step
>> (thought processes and diagnostics).  *Write them down* and turn
>> this into a document on how to qualify and support a new device.
>
> Happy to help, but scheduling something in real-time might not happen
> before this weekend. Feel free to email me off-list to schedule.
>
> I would also recommend that someone who is less involved with the
> development of NUT volunteer as well. I fully admit that I have some
> preferences about how things "should" be done, and they don't
seem to
> match what people are asking for. (A prime example: I think an UPS
> should shut down the system when the UPS says the battery has gone
> below a certain level, as determined by periodic battery tests,
> rather than shutting down after a certain time period on battery.)
>
> A few miscellaneous points about the UPS HOWTO:
>
> * While RS-232C interfaces are being phased out on servers and
> desktops, UPS vendors are just wrapping the serial protocol (or
> contact-closure lines) in a cheap USB-to-serial converter that may or
> may not show up as such in the OS. So you get the intersection of the
> flakiness of serial, plus the flakiness of USB. (The USB devices tend
> not to reconnect with the same device name, if the OS has a driver
> for the USB-to-serial converter.)
>
> * The suggestions also seem to be subtly Linux-centric: a lot of the
> advantages of USB are lost on systems with less robust USB stacks,
> such as the BSD family.
>
> * Several years ago, while developing drivers for early Tripp Lite
> models, I would have definitely recommended another vendor such as
> APC or MGE instead. Today, the tables are turned: MGE/Eaton have
> decreased their involvement in NUT, and APC has switched to a
> proprietary MODBUS-over-USB protocol that they have not publicly
> documented [1].
That is not true.  The MODBUS protocol has been documented by APC and 
the open source apcupsd program supports it.  The proprietary protocol
APC uses is yet another protocol they call microlink.  And the UPSLink 
protocol that NUT supports is still available via use of an add-on card. 
  Plus, many of the APC UPSes (the backups line) are simple UPSes
and don't use either the smartlink or the modbus protocol they use a
variant of the old upslink over usb.

Someone could write a driver for MODBUS for NUT, all of the information
and materials are available to do it.  The simple fact of it is that the
reason no one has done so is that the apcupsd program is available.

I guess the story about the big evil impersonal corporation beating up 
on the small OSS software project is more compelling than the reality 
that the big corporation has made development info available and the
small OSS software project isn't interested, even though the story is
fabrication.
> On the other hand, Tripp Lite approached the NUT
> project unsolicited with several documents worth of NUT integration
> testing results with their newer USB UPS models.[2] There is still
> some work to be done on correcting some of the values, but it's a
> move in the right direction.
>
> [1] http://forums.apc.com/thread/5374
>
> [2]
>
http://lists.alioth.debian.org/pipermail/nut-upsuser/2013-October/008675.html
>
>  * I am not sure that "bigger is better" when it comes to
replacement
> batteries. I have been buying slightly larger-capacity batteries for
> several different UPS brands and models, and the effect ranges from
> confusion about state-of-charge (~2002 350W APC; with battery door,
> incidentally) to fried battery charging circuitry (350W MGE
> Evolution).
>
I agree with that.
> * For testing power failure scenarios, I would use a power strip
> switch or a circuit breaker before tripping a GFCI. I have no
> scientific basis for that, just feels better for some reason.
>
The contacts in a GFCI  (if your talking about the GFCI's that are
inside an electrical outlet) are much smaller and not as robust as those
in a power strip switch or circuit breaker.  They are mainly intended as
emergency use, to save the life of the dumb bunny who accidentally drops 
their hairdryer into a sink full of water and reaches for it,
or a similar situation.
> * Although you certainly have a point about not letting UPS batteries
> wither on the shelf, if someone is planning to set up many
> independent UPS-computer pairs with inexpensive UPSes, it might be
> worth having a "hot spare" UPS that is rotated in occasionally
during
> service windows. The battery charger failure I mentioned above did
> not allow me to continue using the UPS even without a battery, so I
> had to swap in another unit.
>
It would be far better to refrain from using many independent 
inexpensive UPSes and use a fewer larger expensive UPSes, then you don't
have to bother with battery charger failures and the like.

There's a reason inexpensive UPSes exist - cheap parts.  Cheap parts 
fail a lot.

Ted

On Jul 9, 2014, at 11:24 AM, Ted Mittelstaedt <tedm at mittelstaedt.us>
wrote:
> Someone could write a driver for MODBUS for NUT, all of the information
> and materials are available to do it.  The simple fact of it is that the
> reason no one has done so is that the apcupsd program is available.
You're right, it's the microlink protocol that they have been promising
to release. My mistake. We even have a branch where Arnaud was starting to write
some code against libmodbus. However, the documentation seems to lag the
introduction of the new products that all of a sudden don't work with
existing software.
> I guess the story about the big evil impersonal corporation beating up on
the small OSS software project is more compelling than the reality that the big
corporation has made development info available and the
> small OSS software project isn't interested, even though the story is
> fabrication.
Sigh.

A simple "that's wrong; here are the facts" would have sufficed.

I did try to look up the correct information this morning, and I was getting 503
errors on apcupsd.org, and APC's forums were timing out.

My point, which I believe still stands, is that Tripp Lite has been implementing
the standard PDC HID protocols, and even testing against NUT, whereas APC has
been much more of a moving target. I don't believe I accused APC of malice
in their innovation, but if it sounds like I am frustrated with that situation,
I am.

When you're done picking apart Eric's UPS HOWTO, we have plenty of NUT
documentation that could also stand to be updated. Patches gladly accepted.
I'll even reformat them to Asciidoc if that's not your cup of tea.

-- 
Charles Lepple
clepple at gmail

On 7/9/2014 4:16 PM, Charles Lepple wrote:
> On Jul 9, 2014, at 11:24 AM, Ted Mittelstaedt<tedm at
mittelstaedt.us>
> wrote:
>
>> Someone could write a driver for MODBUS for NUT, all of the
>> information and materials are available to do it.  The simple fact
>> of it is that the reason no one has done so is that the apcupsd
>> program is available.
>
> You're right, it's the microlink protocol that they have been
> promising to release. My mistake. We even have a branch where Arnaud
> was starting to write some code against libmodbus.
Why don't you just lift all the APC modbus code from the modbus
module in apcupsd?  The work is already done there.
> However, the
> documentation seems to lag the introduction of the new products that
> all of a sudden don't work with existing software.
>
The Modbus doc for APC UPSes is here:

http://www.apc.com/whitepaper/?an=176
>> I guess the story about the big evil impersonal corporation beating
>> up on the small OSS software project is more compelling than the
>> reality that the big corporation has made development info
>> available and the small OSS software project isn't interested, even
>> though the story is fabrication.
>
> Sigh.
>
> A simple "that's wrong; here are the facts" would have
sufficed.
>
Your correct, my apologies!
> I did try to look up the correct information this morning, and I was
> getting 503 errors on apcupsd.org, and APC's forums were timing out.
>
> My point, which I believe still stands, is that Tripp Lite has been
> implementing the standard PDC HID protocols, and even testing against
> NUT, whereas APC has been much more of a moving target. I don't
> believe I accused APC of malice in their innovation, but if it sounds
> like I am frustrated with that situation, I am.
>
I understand the frustration! I noisily complained on the apcupsd forum
for several years about the situation.

Now I'm noisily complaining on the NUT forum about the situation. ;-) 
Fact is I use both apcupsd and NUT.

Anyway, APC is under the impression that NUT is sponsored by MGE/Eaton.
So, it interests me to read:

"..Today, the tables are turned: MGE/Eaton have decreased their 
involvement in NUT.."

If APC shipped a SMT UPS to you with MODBUS loaded on it would you 
develop an APC module for NUT?
> When you're done picking apart Eric's UPS HOWTO, we have plenty of
> NUT documentation that could also stand to be updated. Patches gladly
> accepted. I'll even reformat them to Asciidoc if that's not your
cup
> of tea.
>
OK I suppose I deserved that. ;-)   But Eric's a writer also and he 
should know how tempting it is to dangle a piece of ripe fruit like that 
in front of one.

I'll review the NUT docs.  What do you want them in?  My preferred 
editor for textfiles is vi.  I'm a minimalist.  I subscribe to the
notion that those who can write, write.  Those who can't, reformat 
documents with WYSIWYG.

Ted