[Nut-upsdev] USB support for Sweex 1000 VA UPS (was: Help with

[Peter Selinger]

I'll defer to Alexander Gordeev; he has worked extensively on the
megatec_usb driver, which is solving a somewhat similar problem,
although the protocol is different.

The UPS shutdown 30 seconds after the "low battery" event might have
been initiated by software. Or does the UPS also shut down at that
time when it's not being monitored?

-- Peter

Peter van Valderen wrote:
> 
> Hello Peter,
> 
> First off, thanks for your reply, it was very useful to me. I've
> gotten a lot done so far; I'd say my driver is about 80% done
> 
> On 5/22/07, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> 
> > That value that constantly fluctuates could be a voltage. Since you're
> > in Europe, perhaps it's a straight decimal conversion? FC =3D 252, F5 =3D
> > 245 etc? Seems a bit on the high side, as your nominal voltage is
> > supposed to be 230V. It could be some other measurement value, or
> > voltage on some other scale, or only a few of the bits are
> > significant... In any case, it probably doesn't matter.
> 
> Tried figuring that out, didn't really get anywhere.
> 
> > What you should try, however, is what happens when the battery gets
> > (1) low, and (2) empty. Aside from the "on power" flag, these are very
> > important flags that most UPS's will signal. The idea is that you
> > start shutting down your computer when the battery gets low.
> 
> I found out what happens when the battery goes to 'low', the following:
> 
>  01 04 02 F8 F5 FF                                 ...=F8=F5=FF
> 
> As compared to FA on battery, and FE on line. What I worked out from
> this is that the 3rd bit from the 4th byte shows the power status, and
> the 2nd bit shows the battery status.
> 
> What happened when the UPS shut down is a different story though. That
> happened about 30 seconds after the battery went 'low', that's not a
> lot to work with I suppose...
> 
> Here's what happened when the battery emptied:
> 
> 002540: Bulk or Interrupt Transfer (UP), 23.05.2007 03:18:55.390
> +0.718. Status: 0xc0000005
> 
> Pipe Handle: 0x8985485c (Endpoint Address: 0x81)
> Get 0x0 bytes from the device
> 
> 002541: Bulk or Interrupt Transfer (UP), 23.05.2007 03:18:55.390 +0.0.
> Status: 0xc0007000
> 
> Pipe Handle: 0x8985485c (Endpoint Address: 0x81)
> Get 0x0 bytes from the device
> 
> To be honest I haven't worked out what this means yet.
> 
> > Another important thing is to be able to shut off the UPS via a
> > command. Namely, after your computer shuts down in the case of a power
> > failure, you want to be able to turn the UPS power off. The idea is
> > that it should stay off until the line power returns, at which point
> > your computer reboots (if set to do so in the BIOS). Otherwise, you
> > might end up in limbo if the power comes back before the battery runs
> > out, but after your computer has shut down. If the Richcomm software
> > can do a forced shutdown, you might be able to see what command it
> > sends. (Perhaps not needless to say: don't plug your computer into the
> > UPS during these tests. Plug it into the wall).
> 
> I found out about this as well, however, here's where it got a bit
> confusing as well; in the richcomm utility there's not a lot you can
> do, the only thing related is the 'UPS signal polarity' menu, in which
> you can choose
> 
> AC failure: Cathode(default)/Anode
> Battery voltage low: Cathode(default)/Anode
> Shutdown UPS: Cathode/Anode(default)
> 
> When I change the first two around nothing gets sent to the UPS;
> however the software seems to think that the AC is on when it's not,
> and vice versa, same for the battery level.
> 
> When I change the shutdown to cathode when the UPS is not powered, it
> will shut down immediately, however it can still be polled. When this
> change is made with the power on, nothing seems to happen to the UPS.
> The following packet gets sent:
> 
> 002612: Class-Specific Request (DOWN), 23.05.2007 02:58:40.609 +0.078
> Destination: Interface, Index 0
> Reserved Bits: 34
> Request: 0x9
> Value: 0x200
> Send 0x4 bytes to the device
> 
>  02 01 00 00                                       ....
> 
> When the polarity is on anode and the power is off, it's no longer
> possible to turn the UPS back on with the button. When it is switched
> to cathode again when the power is off, it's possible to turn it back
> on manually. When it is switched to cathode and the power is, the UPS
> will power itself back on.
> 
> The following packet gets sent (headers the same as the previous packet):
> 
>  02 00 00 00                                       ....
> 
> Now I don't know if this is the normal way it works, it just seems a
> little confusing to me.
> 
> > NUT uses libusb (http://libusb.sourceforge.net/doc/) for all USB
> > functions. Unfortunately, the interface is badly documented and
> > underspecified, and impossible to read without the USB specification.
> >
> > Good luck! -- Peter
> 
> Well as I said I think I have most of it down now, I only just
> finished so I haven't been able to test it 'live'; I have just been
> running the driver with
> 
> cd ..;make;cd drivers;./sweex_usb -u root auto
> 
> Which seems to work. Basically I made my own standalone driver that
> uses nut_usb.c, I had to make two small patches to that to get it to
> work. I worked on the 2.1.0 SVN.
> 
> The changes for nut_usb entail putting the productid/vendorid in, and
> detaching the kernel driver that somehow claims the USB device.
> 
> I hope it's okay posting them here, sorry if it isn't!
> 
> Hopefully there are some things I can do to finalise the driver and
> maybe include it in the SVN?
> 
> Regards,
> Peter