Ted Mittelstaedt
2014-Jul-09 15:24 UTC
[Nut-upsdev] 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
Charles Lepple
2014-Jul-09 23:16 UTC
[Nut-upsdev] Documenting the NUT driver-qualification process
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
Ted Mittelstaedt
2014-Jul-10 07:39 UTC
[Nut-upsdev] Documenting the NUT driver-qualification process
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
Maybe Matching Threads
- Documenting the NUT driver-qualification process
- Documenting the NUT driver-qualification process
- New APC "SMT" UPSes support MODBUS, will there be support in NUT?
- New APC "SMT" UPSes support MODBUS, will there be support in NUT?
- APC protocols and drivers (was: Documenting the NUT driver-qualification process)