[Nut-upsdev] USB support for Sweex 1000 VA UPS (was: Help with USB support for a Kebo UPS-650D)

Peter van Valderen p.v.valderen at probu.nl
Sun May 20 05:57:52 UTC 2007


First off, my apologies for bringing back this thread from the dead
(September 2005,
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-September/000150.html),
however my problem seems relevant enough that I wondered what happened
to this thread as it seems to have died after the message I quote
below.

Despite the fact that I am having trouble getting my Sweex 1000VA UPS
(USB) to work, and the original thread was about a Kebo UPS-650D, I
think these are based on the same hardware. In fact they even seem to
have the exact same VendorID/ProductID, as per:

root at router:/usr/local/ups/bin# ./newhidups -DD -u root /dev/hiddev0
Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5)

debug level is '2'
Checking device (0925/1234) (001/008)
- VendorID: 0925
- ProductID: 1234
- Manufacturer: ?
- Product: UPS USB MON V1.4
- Serial Number: unknown
- Bus: 001
Trying to match device
Device matches
*SNIP*

I read everything in that thread, did everything, compiled the 'KEBO
stub driver', and it seems to load and give a whole lot of output,
however after that I kind of get stuck.

However in the SVN trunk the newhidups driver seems to be gone, so I
figured this might not even be relevant anymore, but I thought I'd
give it a shot anyway.

I patched the files mentioned in the old thread in the latest 2.0.5
source, and that seemed to work just fine.

In case anyone is interested, the entire output of 'newhidups -DDDDD
-x productid=1234 -u root /dev/hiddev0' can be found here (I didn't
include it because it's rather long):
http://probu.nl/users/p.v.valderen/output.txt

I'd love to get this thing working in Linux ;-)

Peter Selinger wrote:

>Andrew Dancy wrote:
>>
>> Apologies - I clean forgot to add the "-u root" switch. Here's the output
>> with that switch added - looks more promising!
>
>Indeed, very promising. The important bits are:
>
>Path: ffa00001.ffa00002.ffa10003, Type: Input
>Path: ffa00001.ffa00002.ffa10004, Type: Input
>Path: ffa00001.ffa00002.ffa10005, Type: Input
>Path: ffa00001.ffa00002.ffa10006, Type: Input
>Path: ffa00001.ffa00002.ffa10007, Type: Input
>Path: ffa00001.ffa00002.ffa10008, Type: Input
>Path: ffa00001.ffa00002.ffa10009, Type: Output
>Path: ffa00001.ffa00002.ffa1000a, Type: Output
>Path: ffa00001.ffa00002.ffa1000b, Type: Output
>Path: ffa00001.ffa00002.ffa1000c, Type: Output
>
>The next steps are:
>* see if we can read any data from these variables (see below),
>* monitor them to figure out what they might mean (see below),
>* map them to the proper NUT variables and instant commands
>
>> Please also try the program from this post:
>>
>> http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-September/000144.ht
>> ml
>>
>> This is just a simple program that connects to USB devices and prints
>> some information about them. Nothing fancy and nothing UPS specific,
>> but if this works then there's no reason NUT could not connect to
>> it. They must be run as root. Please post the output.
>>
>> -------------
>>
>> Tried to compile with gcc -I/usr/include usbtest.c and got the following
>> (extract)
>>
>> usbtest.c:1: error: syntax error before '--' token
>>
>> ...
>
>It looks like you forgot to remove the separator line "--------------"
>from the beginning of the file. All those errors are bogus. But this does
>not matter any more, since NUT now connects to this device.
>
>Below is a "stub" subdriver kebo-hid.c. This is not really a complete
>subdriver yet, because it does not know what the individual variables
>stand for. But it should allow you to experiment. If all goes well,
>you should be able to "monitor" the UPS variables with upsd/upsc
>and you should be able to write to some of them with upsrw.
>
>For the time being, it is best to run the driver and upsd as root,
>because you don't want to get any additional trouble to do with
>permissions until this is at least demonstrated to work.
>
>Also, don't run upsmon yet, as you don't want your system to shut down
>accidentally.
>
>Also, don't connect your computer's power supply to the UPS yet, as
>you need to experiment with how to shut it down, and you don't want
>your computer to crash if you succeed.
>
>You'll probably need to set up ups.conf, upsd.conf, and upsd.users at
>this point. Then run some combination of the following:
>
>upsmon -c stop     # to make sure upsmon is not running
>upsdrvctl stop     # to make sure no other drivers are running
>upsd -c stop       # to make sure upsd is not running
>
>upsd -u root       # run upsd without dropping root privileges
>drivers/newhidups -DD -u root -a myups   # or similar...
>
>upsc myups at localhost
>	# to see if you can read any variables, see if they change,
>        # guess what they are
>
>upsrw -s kebo.output9=1 -u USERNAME -p PASSWORD myups
>	# to see if you can set any variables. Experiment with
>	# different variable/value pairs. USERNAME and PASSWORD
>	# are from upsd.users
>
>The idea is to figure out what the variables are from looking at their
>values. For example, a value of 117 or 218 (depending on location) is
>likely a voltage, a value of ca. 24 is likely a battery voltage, and a
>value such as 4097 is likely a binary status indicator.
>
>Also, some of the "outputs" are likely settable variables that
>initiate things such as shutdown procedures.
>
>It's possible that your driver won't show any values at all. In this
>case, we'll have to fine-tune.
>
>I have not yet seen a UPS device that had "Output" items - usually
>there is only "Input" and "Feature". So I am not sure if this will
>work. We'll have to wait for the outcomes of your experiments.
>
>Here's the stub driver, don't forget to remove the separator line:
>
>*SNIP*



More information about the Nut-upsdev mailing list