search for: hu_flag_quick_pol

...", NULL, "%s", HU_FLAG_STATIC, stringid_conversion}, + {"battery.mfr.date", 0, 0, "UPS.PowerSummary.iOEMInformation", NULL, "%s", 0, stringid_conversion}, + {"battery.voltage", 0, 0, "UPS.PowerSummary.Voltage", NULL, "%.2f", HU_FLAG_QUICK_POLL, NULL}, + /* { "battery.voltage.nominal", 0, 0, "UPS.PowerSummary.ConfigVoltage", NULL, NULL, HU_FLAG_QUICK_POLL, openups_vbat_info }, */ + {"battery.current", 0, 0, "UPS.PowerSummary.Current", NULL, "%.3f", HU_FLAG_QUICK_POLL, NULL}, + {"batt...

..."%s", HU_FLAG_STATIC, stringid_conversion}, {"battery.mfr.date", 0, 0, "UPS.PowerSummary.iOEMInformation", NULL, "%s", HU_FLAG_STATIC, stringid_conversion}, - {"battery.voltage", 0, 0, "UPS.PowerSummary.Voltage", NULL, "%.2f", HU_FLAG_QUICK_POLL, NULL}, + {"battery.voltage", 0, 0, "UPS.PowerSummary.Voltage", NULL, NULL, HU_FLAG_QUICK_POLL, openups_vbat_info }, /* { "battery.voltage.nominal", 0, 0, "UPS.PowerSummary.ConfigVoltage", NULL, NULL, HU_FLAG_QUICK_POLL, openups_vbat_info }, */ {"ba...

Hi, I've been checking out NUT with an OpenUPS board over the last couple of weekends, and have noticed that it doesn't seem to report sensible values. This lead me to investigate usbhid-ups and delve into various issues. As mentioned in a github issue, one of the problems is with the report descriptor - dumping this from the usbhid-ups debug output and picking through it reveals that

...ctions present are commented as: /* USB HID PDC defaults */ I my local source tree, I made changes to these entries copied from another USB HID-based subdriver, to add: /* USB HID UPS Status*/ {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Charging", NULL, NULL, HU_FLAG_QUICK_POLL, charging_info}, {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Discharging", NULL, NULL, HU_FLAG_QUICK_POLL, discharging_info}, {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.NeedReplacement", NULL, NULL, 0, replacebatt_info}, {&quot...

...gt; /* USB HID PDC defaults */ > > I my local source tree, I made changes to these entries copied from > another USB HID-based subdriver, to add: > /* USB HID UPS Status*/ > {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Charging", NULL, > NULL, HU_FLAG_QUICK_POLL, charging_info}, > {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Discharging", NULL, > NULL, HU_FLAG_QUICK_POLL, discharging_info}, > {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.NeedReplacement", > NULL, NULL, 0, replacebatt_i...

...lts */ >> >> I my local source tree, I made changes to these entries copied from >> another USB HID-based subdriver, to add: >> /* USB HID UPS Status*/ >> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Charging", NULL, >> NULL, HU_FLAG_QUICK_POLL, charging_info}, >> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Discharging", >> NULL, NULL, HU_FLAG_QUICK_POLL, discharging_info}, >> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.NeedReplacement", >> NULL, NULL,...

...ndors use them. The script just maps them to generic numbers, but the values are most useful if mapped to proper types. For instance: $ git grep UPS.PowerSummary.PresentStatus.ACPresent drivers/apc-hid.c: { "BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.ACPresent", NULL, NULL, HU_FLAG_QUICK_POLL, online_info }, drivers/belkin-hid.c: { "BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.ACPresent", NULL, NULL, HU_FLAG_QUICK_POLL, liebert_online_info }, ... This indicates that the APC models tend to follow the spec, but that we had to add a custom mapping function for Belk...

Arjen de Korte wrote: > > Author: adkorte-guest > Date: Fri Aug 10 20:23:27 2007 > New Revision: 1041 > > Log: > * drivers/usbhid.[ch]: > - Moved the struct & data for ups.status processing to usbhid.c, since this is only used in there. Subdrivers report the status through text messages, they don't set the status bits directly. > - Rewrote (flattened) the

...>> I my local source tree, I made changes to these entries copied from >>> another USB HID-based subdriver, to add: >>> /* USB HID UPS Status*/ >>> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Charging", NULL, >>> NULL, HU_FLAG_QUICK_POLL, charging_info}, >>> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Discharging", >>> NULL, NULL, HU_FLAG_QUICK_POLL, discharging_info}, >>> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.NeedReplacement", >>&...

Linux NUT 2.7.1 Eaton 5PX usbhid-ups It would appear that interrupts are not actually working on my 5PX using the usbhid-ups driver. I will be trying the serial mge-shut driver next. It just seemed like it was working before because of the default pollinterval of 2 seconds. The status update comes in during the pollinterval no matter what I have pollfreq set to. And I can set pollonly and

Hi, I have an UPS with only the marking D1000 on it and it came with Junda-Tech's UpsMate. Its USB id is 3344:0025, which is apparently a microprocessor. I've could get some of the HID interactions as described on the website, but there are some outstanding. Junda-Tech does not respond to any queries. Does anybody else have the same or a similar UPS with more information? What is the

Hello, is there a way to query from the cmdline if the UPS data is stale? "upsc" outputs a lot of information, but not if the data is stale. Example output from a "stale" UPS on the server: (nut version: nut-2.7.2-3.el7) # upsc apcsmart battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.mfr.date: 2014/09/01 battery.runtime: 1320

...river.name: usbhid-ups > driver.parameter.pollfreq: 30 > driver.parameter.pollinterval: 2 You can tune these parameters to avoid the stale condition, at the expense of slightly longer latency for updates. The smaller `pollinterval` (seconds between poll cycles) is used for items marked "HU_FLAG_QUICK_POLL" in the HID tables: https://github.com/networkupstools/nut/blob/master/drivers/apc-hid.c#L301 and the `pollfreq` value is used for polling the rest. More information here: http://networkupstools.org/docs/man/usbhid-ups.html (I think the interrupt stuff applies to APC models with USB ID 051d:...

Hi, I am studying (in a few months I might go on a TV quiz show :-) Rodger's excelent guide and wanted to confirm that all measurements in NUT are in seconds. For example, the Cyber Power System CP1500 AVR UPS returns that the **driver.parameter.pollfreq = 30**. This means that I can (maybe should) adjust the settings within NUT.CONF to match this value. Setting this value to 2 seconds gains

...uring the Quick update every two seconds. On the other hand, the whole reason for the two separate polling frequencies is that low-speed USB is only 1.5 Mbit signaling, and has even lower throughput, so it isn't possible to poll all of the variables every two seconds. You could try setting the HU_FLAG_QUICK_POLL bit in drivers/apc-hid.c on RemainingTimeLimit. At that point, you should be able to see how often the UPS updates the runtime estimate - it might be dropping below 90 (or whatever the internal threshold is for RemainingTimeLimit) for short intervals. -- Charles Lepple clepple at gmail ------...

...iver.parameter.pollfreq: 30 > > driver.parameter.pollinterval: 2 > > You can tune these parameters to avoid the stale condition, at the expense > of slightly longer latency for updates. The smaller `pollinterval` > (seconds between poll cycles) is used for items marked > "HU_FLAG_QUICK_POLL" in the HID tables: > https://github.com/networkupstools/nut/blob/master/drivers/apc-hid.c#L301 > and the `pollfreq` value is used for polling the rest. > > More information here: http://networkupstools.org/docs/man/usbhid-ups.html > (I think the interrupt stuff applies to APC...

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

On 10/01/2015 00:45, Charles Lepple wrote: > On Jan 8, 2015, at 11:43 PM, Graham Menhennitt > <graham at menhennitt.com.au <mailto:graham at menhennitt.com.au>> wrote: > >> Hello Nutters, >> >> I'm running nut 2.7.2 on FreeBSD 10-stable (via the FreeBSD port) >> with an APC Back-UPS CS 350 connected via USB. I get persistent >> (every few