[Nut-upsdev] usb ups on openindiana

[Charles Lepple]

On Nov 9, 2013, at 1:54 PM, Ted Mittelstaedt wrote:

> On 11/9/2013 5:24 AM, Jim Klimov wrote:
>> Hello all,
>> 
>> I am trying to set up my brother's UPS (remotely over internet)
>> on an OpenIndiana-based storage box. According to him, the UPS is
>> probably an Ippon Back Power Pro 600 dated around 2003 (battery
>> recently replaced), and it has an USB connection.
[...]
>> Main question is if this is some mistake of mine, an OS specific
>> thing, or just that this particular UPS is not supported (or maybe
>> its mgmt parts are broken - who knows, so far they haven't been
>> tested in any other OS)?
> 
> I think you have to step back from this for a moment
> and re-evaluate the real goals here.
> 
> Is your goal to:
> 
> 1) Get this OpenIndiana based storage box protected against power failures?
> 
> or is it to:
> 
> 2) Help the NUT project change the status of your UPS from Experimental to Production?

Ted brings up a good point here.

> If your goal is #1 then your going about this the wrong way - the best advise you can take would be to tell your brother to buy a supported UPS.  Since you have NUT already built, that would be an Eaton-manufactured UPS since Eaton is the main sponsor.

For option #1, if you are looking to buy local, Powercom might be another option (going by the country code on your email address). They have provided protocols and development hardware:

http://www.networkupstools.org/acknowledgements.html#_ups_manufacturers

> If your goal is #2 - which we all appreciate, thank you! - then once you have discovered that the UPS isn't fully supported you need to decide if your OK with this gear being unprotected for a while.
> 
> The track record of NUT developers adding support for drivers (or fixing bugs in drivers) is frankly pretty poor.  Many more bugs and problems are reported than are ever fixed.  Mostly this is likely
> because the developers don't have samples of the UPS in question.
> 
> Basically if your in your shoes - you have an unsupported UPS - then
> your choices are to replace the UPS and ship the unsupported UPS off
> to a developer, or to try to fix it yourself.

This was the mantra of Russell Kroll, the NUT project founder. Practically speaking, turning NUT developers into owners of the hardware doesn't scale well. You need to find a developer who is willing to take on a new project, and shipping them an UPS is probably not economical unless you already have a large number of these UPSes deployed. We'll do what we can to help you debug this remotely.

>> Running as root does work around the former problem, but the UPS
>> is still not recognized by any of the protocols:
>> 
>> # /usr/local/ups/bin/blazer_usb -DDDD -a ippon -u root
>> Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5)
>> 0.000000 debug level is '4'
>> 0.022634 Checking device (06DA/0003) (/dev/usb/6da.3/0)
>> 0.045564 - VendorID: 06da
>> 0.045663 - ProductID: 0003
>> 0.045733 - Manufacturer: OMRON
>> 0.045788 - Product: 87XXUPS
>> 0.045841 - Serial Number: unknown
>> 0.045899 - Bus: /dev/usb
>> 0.045951 Trying to match device
>> 0.046011 Device matches
>> 0.046187 Trying megatec protocol...
>> 0.049547 send: Q1
>> 0.101572 read: (217.0 2
>> 0.101674 blazer_status: short reply

^ This is somewhat promising, since "(217.0 2" is the beginning of a valid Megatec protocol response.

(Incidentally, this pretty much rules out the usbhid-ups driver, since HID PDC packets are almost never ASCII strings.)

What concerns me is that the reply seems to be exactly 8 characters, which is the maximum hardware packet size of low-speed USB.

Can you add "subdriver = ippon" to the ups.conf section for this UPS?

>> device.mfr: OMRON
>> device.model: 87XXUPS
>> device.type: ups
>> driver.name: usbhid-ups
>> driver.parameter.pollfreq: 30
>> driver.parameter.pollinterval: 2
>> driver.parameter.port: auto
>> driver.parameter.productid: 0003
>> driver.version: 2.6.5
>> driver.version.data: Liebert HID 0.3
>> driver.version.internal: 0.37
>> ups.mfr: OMRON
>> ups.model: 87XXUPS
>> ups.productid: 0003
>> ups.status: OB
>> ups.vendorid: 06da
>> 
>> 
>> I am puzzled why it is considered "OB" for example, which makes this
>> information somewhat useless for automated shutdowns...
>> 
> 
> If you pull the plug on the UPS does the ups.status change from OB to something else?

Pretty sure this won't change, and the OB is just the default value here.

>> It is indeed quite possible, that this particular piece of hardware is
>> just not supported by NUT and there are few-to-no problems regarding
>> the OS/Software side of my setup... I'd welcome confirmations though :)
>> And ideas about the volatility of device node setup (disappearance of
>> symlinks and changes of ownership with blazer_usb - but not with the
>> usbhid-ups driver) are also welcome.
>> 
> 
> Your UPS isn't supported by blazer_usb or by usbhid-ups, end of story.
> 
> There must be some sort of USB driver for Windows that came with the UPS, the manufacturer didn't put that USB port on there for no reason.
> 
> If you plug this UPS into a modern Windows machine does it setup as a
> HID UPS device, and work?  If it does, then the best chance for support
> is creating a usbhid-ups subdriver.  The process isn't that hard, it's
> documented here:

The problem is that most USB-to-serial converters show up as USB HID devices, but not as a Power Device Class (PDC) HID device (which is the HID class that the usbhid-ups driver is trying to use). HID devices are easy to access from userspace in older versions of Windows, so many manufacturers do that to avoid going down the rabbit hole of a kernel driver.

> http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#hid-subdrivers

The HID report descriptor is only 29 bytes, so it is too short to have any of the HID PDC elements that the above link talks about.

>> Also, for the record, it is very inconvenient that starting an UPS
>> driver requires an entry in the ups.conf nowadays - basically, to
>> find a matching driver I'd have to make dozens of such entries and
>> see if any of them works... I'm lucky I got a possible hit on my
>> second attempt.

If you think that is inconvenient, try writing a driver from scratch with no documentation on the protocol.

We are open to suggestions on how to make this easier, but I think that time might be better spent developing a better installation diagnostic procedure. Most people are going to only try a handful of drivers at most, and when they find the right one, they can just continue to use that version of ups.conf.

> There is NO industry standard for autodetection of UPSes on serial
> ports.  Indeed, for "dumb" contact-closure UPSes on serial ports,
> autodetection would be absolutely impossible since there is no intelligence in the UPS to communicate back to the computer.
> 
> And for USB upses, if ALL of the manufactured UPSes out there used
> the HID interface like they are supposed to, then we would have no problem since the usbhid-ups driver IS autodetecting, all we would have to do is tell people if they have a USB ups, use usbhid-ups
> 
> But what screws the pooch is that many USB UPSes use their serial protocol over the USB port.

... and these USB-to-serial converters are often not recognized by existing kernel drivers. If they were, users could just open the tty /dev node, and continue to use the serial-based NUT drivers.

> Your only working with a 600VA ups plugged into 1 device so you don't
> understand the issues here.  The typical production business may have
> multiple servers plugged into a large ups.  They cannot have the system
> that the UPS is plugged into, spewing all kinds of different autodetection data strings out the serial port (or USB port for serial
> over USB) when that monitor system reloads the UPS daemon.  All it would
> take is for one of those tests to be interpreted by some other vendors
> UPS as an immediate shutdown of UPS output power to cause a huge problem.


Incidentally, we have had reports of ModemManager doing that sort of auto-detection, and interfering with NUT.

-- 
Charles Lepple
clepple at gmail