similar to: generic option for newhidups

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

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

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

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

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

Gentlemen, I have determined that on my UPS (APC Back-UPS ES 650 FW:818.w1.D USB FW:w1), the variable UPS.PowerSummary.RemainingCapacityLimit is writeable. I am setting this variable to start shutdown a little earlier. Appended is an unconditional patch for apc-hid.h. If, as indicated by the original code, there are APC UPS devices that don't allow setting of this variable, it becomes

Ladies and Gentlemen, Running newhidups with -DD shows the following line that starts with "-> String:" occasionally, with no contect that it is related to: ...... Can't find object UPS.Battery.Temperature -> String: PbAc (len = 4/4) Can't find object UPS.Output.PercentLoad ...... However, running newhidups with -DDD, shows the proper context: ...... hu_find_infoval:

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

Gentlemen, On several occasions now I would have liked to start a complete set of (newhidups + upsd + upsmon) in the background, but with significantly more output to syslog. From a cursory look at the code, it looks to me that it might be easy to add an option similar to -D that doesn't stop putting the process into the background. I understand that higher levels of debug would create a

Gentlemen, I am using upsmon, upsd, and newhidups to control my UPS. The UPS allows setting of two variables that are re-initialized to their default values whenever the UPS is restarted (e.g. after FSD). I am currently using upsrw in a startup script to set the above variables. This works fine, except that it requires -u and -p in the commandline, which I don't like to do, because I

Gentlemen, I just had time to start looking at the latest version of the development tree. I have built the apc-hid part of newhidups from the development tree and I am in the process of testing it with my "Back-UPS ES 650". As of right now I have incorporated the attached changes to apc-hid.c. I have been using the corresponding changes together with some changes from Arnaud with the

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