similar to: upsdrv_updateinfo() in newhidups.c

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

Gentlemen, I have a new HID USB device, that seems to be quite similar to the currently supported APC HID UPS. I append the dump-tree output, and would much appreciate advice on how to proceed. Certain entries for the current device are not available, but maybe there are some replacements that could be used. This may of course require a new table in apc-hid.h, and I would prefer not to do this

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

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

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

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

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

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

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

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

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: