similar to: RE: newhidups and APC Back-UPS CS 350 (Thomas Jarosch)

Hello, I'm currently try to get newhidups running with the newhidups driver from nut 2.0.2. After some USB issues (usb_claim_interface() works only as root so far) newhidups is recognizing the device. Though it doesn't detect any state changes, meaning when I run the battery test mode it's not recognized. I wanted to try the CVS version but it seems anonymous CVS is broken. The

Peter, You may want to have a look at the comments to Bug 164524 at bugzilla@redhat.com: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164524 I filed this a long while ago, because of the mess we get into when shutting down Linux via /etc/rc.d/init.d/halt, and the UPS device no longer being reachable when we want shut it down. There seem to be some changes to libusb on the way, that

Gentlemen, As reported earlier, my UPS burps a lot of unsolicited interrupt messages. I have made some experiments with the UPS using newhidups directly, and noticed that the poll frequency of the dstate_poll_fds() calls in main.c can be heavily skewed by the timeout provided in the libusb_get_interrupt() call in libhid.c (currently 5 sec!). For a UPS that provides few interrupt messages, this

Gentlemen, I think this question is mainly for Arnaud again: When I run my UPS directly with newhidups -D -D -D, with no data changes, and I then observe the interaction with my UPS (still Back-UPS ES 650 FW:818.w1.D USB FW:w1), I see the updateinfo cycle through 3 different forms: (1) a (2 bytes) => 06 08 notification that provides one item: UPS.PowerSummary.APCStatusFlag Note that

Arnaud, > first, even if your battery is full, and your ups is online, there is a > small amount of power drawn. So having always is CHRG status is normal. > In fact, these complementary status are more interesting for higher end > UPSs. > > second, these status need not to be handled like LB, as each one clears the > other. While LB had no pending event (!LB) before... >

Peter, Thanks a lot for your latest changes to newhidups, which I like a lot. Unfortunately, when I tried to build the latest development tree stuff, I got a compile time error when compiling al175.c. It looks to me like my compiler, gcc-3.4.4-2.fc3, doesn't like the macro definition for "RECV(reg) do" because of a poorly inserted comment. I fixed the problem locally by the

I was testing out newhidups with an APC UPS, and I noticed that I needed '-x vendor=American.Power.*' instead of '-x vendor=APC.*' as indicated in the man page. Do other APC USB UPSes use 'APC' in the vendor string? Should we sidestep any such problems and just go with the hex vendor ID for APC examples? This was tested with a snapshot from the development branch, but the

Gentlemen, I have now had a chance to run some initial tests of my changes to apc-hid.c of the current development tree. Running newhipups and inspecting the -DDDD output seems to indicate that with the fix below everything seems to work as expected. However, I have not yet shut my system in order to take the UPS out of action so that I can do my various tests with a lightbulb load. I still hope

Ladies and Gentlemen, I have been playing around with Arnaud's new HAL stuff a bit, and have some questions and observations. First my configuration: my UPS (Peter may remember): ups.mfr: APC ups.model: Back-UPS ES 650 ups.productid: 0002 ups.firmware: 818.w1.D ups.firmware.aux: w1 kernel: 2.6.18-92.1.6.el5 hal-0.5.8.1-35.el5, nut based on nut-2.2.2.tar.gz, small changes to

Ladies and Gentlemen, I have been trying to sort out a nasty kernel oops for which I would like to ask for some advice. I don't actually think that this is a nut problem, although it is triggered by upsdrvctl or usbhid-ups. I rather suspect the USB library or the associated kernel code. Here is the configuration information: * system: Centos-5.5 * kernel: 2.6.18-194.32.1.el5, latest vanilla

Hi. I'm having trouble with nut-2.0.3 on a linux kernel 2.4.32 machine and a MGE Evolution 3000. The problem is that I'm getting the following message, repeatidly, on dmesg: usbdevfs: usb_submit_urb returned -22 (-22 means -EINVAL) I traced the problem with newhidups -DDDDDD auto and found out that the -22 error appears in a line "none (-22)" of the output as: ----------

Gentlemee, I have just encountered a problem with low battery status in newhidups. Here is the situation: 1) The system goes through the shutdown sequence due to low battery, the UPS receives the shutdown.return and shuts off power, 2) After power returns, the UPS turns on power before its battery reserves have reached low battery level (a potentially risky situation if we get another

Gentlemen, This is probably for Arnaud, since he has already addressed a somewhat similar problem. I am running newhidups from the development tree (actually everything is from there). However, I have observed the same problem with a 2.0.2 system as well. Here is what I observe: * upsc shows the ups.status: is "OL" * there is a very short interruption of power * upsc shows the

In an earlier message Arnaud wrote: > before digging further, you'll have to make some test to > see if the data changes upon status change. > libhid is your friend, especially test_libhid. You'll have > to modify it a bit to get the values of the below path I just got the CVS tree, but I didn't find test_libhid, but it looks like this would indeed be what I would like to

Gentlemen, I assume this is really for Arnaud: I am looking at the code in upsdrv_updateinfo() where it is processing a HID notification, i.e. it is not doing a full update: Question one, is it implicitely assumed that ups.status related items will always require a translation (i.e. item->hid2info != NULL) in order to be effective? I haven't seen any place where that is enforced, but

Peter, I just saw Scott Alfter's report. I just wanted to say that this is such a nice addition, I like it very much, it makes finding what is needed so much easier! One suggestion if I may, a timestamp of some kind with each =>Got line might be helpful for determining the notification frequencies. Thanks for the new option, AG --

Gentlemen, Please note that what follows pre-dates the latest changes from Arnaud (just thought someone might want to look at these before I can test the latest!). When running newhidups with -D -D -D I saw messages that looked like errors, and it took me a while to understand that they were not really errors. I therefore added two new entries in apc-hid.h, and I modified a couple of diagnistic

Peter, Just to let you know that I have done all my tests with the latest development stuff (Oct 3 23:46 to be specific, with NO local patches!), and everything turned out fine except for the cleaning up of ups.status: as presented by upsc that I reported earlier. I suspect that that cleanup is generic to newhidups, because a couple of month ago Arnaud made some changes for cleaning up LB

Gentlemen, I have done some experiments with an APC Back-UPS ES 650, to identify the currently specified items that are not available with this device, and to find out what non-standard items the device provides. Of the currently specified items, the following are not available: UPS.Battery.Temperature UPS.Output.PercentLoad UPS.PowerSummary.DelayBeforeShutdown UPS.Battery.Test

Charles, When sorting out the library problem for shutdown, please also keep in mind that the shutdown scripts (at least those that I have encountered so far) insist on unmounting /dev/usb. This requires that libusb does not rely on its presence to do the reconnection for the shutdown. I don't know if this is a part of the definition of the functionality of libusb and if it can safely be