similar to: The latest newhidups changes

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

Thomas, The none (-22) message in your log is an errno from the libusb_get_interrupt() call in HIDGetEvents() in libhid.c. It indicates an invalid ioctl type. In HIDGetEvents() there is a comment with that call: /* needs libusb-0.1.8 to work => use ifdef and autoconf */ You may want to make sure your libusb is up-to-date. Hope this helps, AG --

Peter, Here are the transitions that I have tested with your latest changes (on the APC/Back-UPS ES 650): 1) OL ==> OB DISCHRG followed by OB DISCHRG ==> OL (no CHRG inbetween) 2) OL CHRG ==> OL 3) OL CHRG ==> OL CHRG LB (by manipulating battery.charge.low) 4) OL CHRG LB ==> OL CHRG (i.e. transition from below) 5) OB DISCHRG ==> FSD OB DISCHRG LB followed by proper shutdown In

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, 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, 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

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

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

Hi Kirill, just to notify you that your al175 driver is being removed from the NUT tree, as of 2.4.0-pre1. if you wish to see it entering the tree again, please contact the Development mailing list to talk about it. Merry Christmas and happy New Year. Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader -

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, 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

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

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

Hello up there! Attached is my patch to add support for AL175 alarm module, Please ACK or NAK this. -- ?????? ??????? -------------- next part -------------- A non-text attachment was scrubbed... Name: al175.patch Type: text/x-diff Size: 35632 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20050919/84b639e0/al175-0001.bin

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

Gentlemen, I am making progress with with my APC USB device. However, I have encountered a problem with the current build for newhidups. The problem is that on my system libusb.so resides in /usr/lib, which at the end of the shutdown sequence is no longer available. I believe that this is probably a relatively generic problem, and I think that the proper solution is to link all usb drivers