[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