Hi, I've been trying (unsuccessfully) to interact with the above UPS using its USB/HID interface and have come to the conclusion that it's not going to be as "easy" as I'd first thought :( My attempts have all been on FreeBSD-5 (kernel as of today) using NUT v2.0.2 and fiddling with newhidups -- I tried the simple approach of adding the IDs and "seeing what happens". Once I'd unloaded the uhid (FreeBSD) device-driver and figured out the device permissions, I got libusb talking to the device. However, it's unable to extract the manufacturer/product/serial, so something's not right. Having read some more of the archives, I've noted you've cleaned up the driver a fair bit in CVS (which I've not tried, yet) and would like to help/be helped in adding support for my UPS. So, what next? Stewart,
Have you run the driver as root? (-u root). This is often required to get the manufacturer/product/serial number. If you just want to read raw information from your device, you can use the program "get_descriptor.c" that I posted on the mailing list on Aug 30: http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-August/000088.html This might be a good start just to see if it's connected correctly, and if you can post a report descriptor (descriptor 0x22), that would reveal much of the relevant information for getting a driver to work. The CVS version is cleaner than the 2.0.2, but does not differ significantly in functionality. -- Peter Stewart Morgan wrote:> > > Hi, > > I've been trying (unsuccessfully) to interact with the above UPS using > its USB/HID interface and have come to the conclusion that it's not > going to be as "easy" as I'd first thought :( > > My attempts have all been on FreeBSD-5 (kernel as of today) using NUT > v2.0.2 and fiddling with newhidups -- I tried the simple approach of > adding the IDs and "seeing what happens". Once I'd unloaded the uhid > (FreeBSD) device-driver and figured out the device permissions, I got > libusb talking to the device. However, it's unable to extract the > manufacturer/product/serial, so something's not right. > > Having read some more of the archives, I've noted you've cleaned up the > driver a fair bit in CVS (which I've not tried, yet) and would like to > help/be helped in adding support for my UPS. So, what next? > > > Stewart, > > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >
Stewart Morgan wrote:> > > Hello, > > Having installed the MultiLink software and attempted to compare values, I've > managed to interpret one value: Battery Time Remaining in minutes; which is > represented by UPS.PowerSummary.0085006c. > > > >>Path: UPS.00860006.00860080, Type: Feature, Value: 2.000000 > > >>Path: UPS.00860006.00860081, Type: Feature, Value: 0.000000 > > >>Path: UPS.00860006.00860082, Type: Feature, Value: 2.000000 > > >>Path: UPS.00860006.00860084, Type: Feature, Value: 2.000000 > > >>Path: UPS.00860006.00860085, Type: Feature, Value: 3.000000 > > >>Path: UPS.00860006.00860086, Type: Feature, Value: 3.000000 > > >>Path: UPS.00860006.00860087, Type: Feature, Value: 0.000000 > > > Before, I suggested that "UPS.00860006.00860083: 120.00000" > might represent the "mains transfer voltage"; however it is also > possible that actully maps to the "Low battery warning" setting (in > seconds) of two minutes. Either that, or one of *80, *82 or *84 > above does, but in minutes.It is unlikely to be a transfer voltage, because 120V is actually the standard voltage! It would be silly to transfer to battery when the voltage is normal.> > Interestingly, the following, for example, all seem to me to be > > multiplied by ten. Does that mean I need to change the last arg to > > "liebert_10_conversion" in the lookup table? > > Replying to my own post here: I see that the value is the raw value before > being "converted" using the "liebert_10_conversion" function as reported later > -- sorry for the noise :) > > > The MultiLink software I'm using seems to only allow viewing the status of > thigns, so I'll see what else I can find that might enable me to configure it. > > > Stewart. >
Hello, Having installed the MultiLink software and attempted to compare values, I've managed to interpret one value: Battery Time Remaining in minutes; which is represented by UPS.PowerSummary.0085006c.> >>Path: UPS.00860006.00860080, Type: Feature, Value: 2.000000 > >>Path: UPS.00860006.00860081, Type: Feature, Value: 0.000000 > >>Path: UPS.00860006.00860082, Type: Feature, Value: 2.000000 > >>Path: UPS.00860006.00860084, Type: Feature, Value: 2.000000 > >>Path: UPS.00860006.00860085, Type: Feature, Value: 3.000000 > >>Path: UPS.00860006.00860086, Type: Feature, Value: 3.000000 > >>Path: UPS.00860006.00860087, Type: Feature, Value: 0.000000Before, I suggested that "UPS.00860006.00860083: 120.00000" might represent the "mains transfer voltage"; however it is also possible that actully maps to the "Low battery warning" setting (in seconds) of two minutes. Either that, or one of *80, *82 or *84 above does, but in minutes.> Interestingly, the following, for example, all seem to me to be > multiplied by ten. Does that mean I need to change the last arg to > "liebert_10_conversion" in the lookup table?Replying to my own post here: I see that the value is the raw value before being "converted" using the "liebert_10_conversion" function as reported later -- sorry for the noise :) The MultiLink software I'm using seems to only allow viewing the status of thigns, so I'll see what else I can find that might enable me to configure it. Stewart.