[Nut-upsuser] OMNIVS1500XL and FreeBSD

[Charles Lepple]

On 3/4/07, Charles Sprickman <spork at bway.net> wrote:
> Yeah, at this point I figured it's two years or so since I last tried
> this, so maybe it'll work. :)

That's the spirit! :-)

> >> send_cmd: send_try = 3, recv_try = 1
> >
> > I'm a little concerned that it took three tries to send the command.
>
> Is this the point where we think about it being a FreeBSD issue instead of
> the UPS?

I think so, but again, I don't have this particular UPS to be sure.
(Mine is an OmniVS1000 with protocol 1001, and yours appears to be
2001.)

Abbreviated some more:

> send_cmd: received 53 31 34 30 30 00 30 0d 'S1400.0.' (OK)
> send_cmd: send_try = 5, recv_try = 1

> send_cmd: received 53 31 34 30 30 00 30 0d 'S1400.0.' (bad)
> send_cmd: send_try = 5, recv_try = 5

> send_cmd: received 53 31 34 30 30 00 30 0d 'S1400.0.' (bad)
> send_cmd: send_try = 5, recv_try = 5

> send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (bad)
> send_cmd: send_try = 5, recv_try = 5

> send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (bad)
> send_cmd: send_try = 5, recv_try = 5

> send_cmd: received 46 32 31 35 37 20 41 0d 'F2157.A.' (bad)
> send_cmd: send_try = 5, recv_try = 5

> send_cmd: received 46 32 31 35 37 20 41 0d 'F2157.A.' (bad)
> send_cmd: send_try = 5, recv_try = 5
>
> And so on...
>
> Notice that when I bumped retries up to 5 it now gets the info on the 5th
> try rather than the third?  Just a shot in the dark, but maybe something
> happens after the driver sends it's last request (something gets flushed,
> something lets go of some status line???) that allows a reply?

You're on the right track, I think, but here's the code:

http://boxster.ghz.cc/projects/nut/browser/trunk/drivers/tripplite_usb.c#L542

I guess I'm omitting the debug info for all the send/receive call
pairs, except the last one that fails. (From your log,
usb_set_report() never fails.)

Also, the USB receive never seems to fail, just that the data we read
does not match the data that gets sent.

e.g. if I send ":P<checksum>" then I expect to get a response that
starts with "P", otherwise it's just old data in the serial-to-USB
FIFO.

> > Also, someone submitted the patch for the 2001 protocol after some
> > experimentation, so I assume that they got status working at least
> > partially.
>
> I'd love to find that person.  :)

Tony will probably be upset at me for ratting him out, but I blame
Google and publicly-archived lists:
http://osdir.com/ml/monitoring.nut.user/2006-10/msg00013.html

> If there's some FreeBSD issue here, what's the best way to attack this?  I
> can't just wander onto -hackers and say "some guy says your software is
> broken"...

There are a couple of possibilities here.

I can move the OmniVS1000 to another box for testing, and I can try to
get FreeBSD up and running. Granted, we're dealing with two different
protocols and models, so that might be a dead end, and this week looks
like it's going to be busy for me.

Another option might be for you to see if you can connect that UPS to
a WinXP system and do some USB packet capture. (I'm not sure how
feasible this is, given your power situation.)

Since we know the basic commands, all you would have to do is get
PowerAlert to connect to the UPS, and check that it is properly
monitoring things.

-- 
- Charles Lepple