[Nut-upsdev] megatec_usb: Ippon BackComfoPro (06da:0003 Phoenixtec Power)

Arjen de Korte nut+devel at de-korte.org
Sat Dec 20 13:00:59 UTC 2008


Citeren Roman Mamedov <roman at rm.pp.ru>:

>> This is a known problem with some UPS'es that lock up if you send
>> them the 'F\r' and 'I\r' commands. Put the 'norating' and 'novendor'
>> flags in 'ups.conf' (seen 'man 8 blazer') and you'll probably be fine
>> (after replugging the UPS).
>
> Unfortunately that does not help.

At least we now get a good response the first time. This looks a lot better.

> ups.conf:
>
> [ippon-blazer]
>         driver = blazer_usb
>         port = auto
>         vendorid = 06da
>         productid = 0003
>         norating
>         novendor
>
> log:
>
> $ sudo ./blazer_usb -DDD -a ippon-blazer
> Network UPS Tools - Megatec/Q1
> protocol USB driver 0.02 (2.3.0-1660M) debug level is '3'
> Checking device (1D6B/0002) (002/001)
> - VendorID: 1d6b
> - ProductID: 0002
> - Manufacturer: unknown
> - Product: unknown
> - Serial Number: unknown
> - Bus: 002
> Trying to match device
> Device does not match - skipping
> Checking device (06DA/0003) (001/006)
> - VendorID: 06da
> - ProductID: 0003
> - Manufacturer: CTN
> - Product: USB UPS
> - Serial Number: unknown
> - Bus: 001
> Trying to match device
> Device matches
> Trying megatec protocol...
> send: Q1
> read: (206.0 206.4 206.4 023 50.1 13.8 25.0 00001001

This is just what we expect. Apparently, the device isn't always  
returning the number of bytes that we ask for (8). The 'megatec_usb'  
driver assumes it does, but the 'blazer_usb' driver will use the  
actual number returned.

> Status read in 1 tries
> Supported UPS detected with megatec protocol
> send: Connection timed out
> blazer_command: Connection timed out
> blazer_status: short reply

That's weird. The libusb library is telling us that the connection  
timed out when sending the status query. We allow 4 seconds (so that  
should be plenty) but apparently it isn't.

[...]

> Communications with UPS lost: status read failed!
> dstate_init: sock /var/run/nut//blazer_usb-ippon-blazer open on fd 5
> send: Timer expired
> blazer_command: Timer expired
> blazer_status: short reply

And it doesn't improve either on subsequent tries... :-(

You could try inserting something between lines 259 and 260 in  
'blazer_usb.c'. This will make the driver bluntly reconnect on almost  
all errors it sees, including timeouts:

259	case ENOENT:
	default:
260		/* Uh oh, got to reconnect! */

Another useful thing would be to run the bundled driver on a Windows  
box while running 'usbsnoop' so that we can get an idea what it is  
doing. Maybe we're missing something here.

Best regards, Arjen
-- 
Please keep list traffic on the list




More information about the Nut-upsdev mailing list