search for: pollfreq

Hello, I use the following in my ups.conf: # USB: [apc] driver = usbhid-ups port = auto desc = "APC 1500VA" pollfreq = 5 On my new motherboard (an Intel DP55KG), every once and awhile I get this: Broadcast Message from nut at box.com (somewhere) at 17:48 ... Communications with UPS apc at localhost lost Broadcast Message from nut at box.com (somewhere) at 17:48 ... Communications with UPS...

...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 get the same behavior. With the driver usbhid-ups, what is the relationship between pollfreq and pollinterval? It looks like pollinterval overrides pollfreq. usbhid-ups -a ups -DDDDD -x pollfreq=30 -i 30 2>&1 | egrep '(update|ups.status)'...

.... * UPS device name and related information Eaton 5PX 1500 * Problem description Not a problem, just an observation. I made a program to monitor my UPS, the final objective is to implement a power use totalizer, and wanted to see which polling frequency is the minimum required. Read about pollfreq, and pollinterval, but didn't see NUT's code. The values of those are: driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 5 I found that power consumption (ups.realpower) only changes every 35 seconds, which is (pollfreq + pollinterval). Does this looks correct? I would expect...

[please use Reply-All to keep the list CC'd, thanks] On Mar 30, 2015, at 11:04 PM, Jason Gould <jgould at cddiagnostics.com> wrote: > Thanks. I should also mention the freenas server is setup with an lacp lagg. > > I will also mention that even when not setting pollfreq (leave as default) the issue still occurs. > It looks like the default for pollfreq is actually 30 on snmp-ups, which means you would want DEADTIME to be at least 2x that in order for a single stale data event to not trigger the COMMBAD message, and the default is only 15. As you can imagine, c...

On Sep 19, 2017, at 1:36 PM, Ren? Berber <rberber at fastmail.fm> wrote: > My guess is that they are the same version (Synology keeps it updated). Is there a way to check which version they are using? (Just curious - probably will not affect the problem you described.) > Read about pollfreq, and pollinterval, but didn't see NUT's code. The usbhid-ups code is here: https://github.com/networkupstools/nut/blob/v2.7.4/drivers/usbhid-ups.c#L851-L871 > The values of those are: > driver.parameter.pollfreq: 30 > driver.parameter.pollinterval: 5 > > I found that p...

I missed that snmp-ups set pollfreq to 30 by default. I'd hope that it would set deadtime to an appropriate value as well than, no? Is there a way to query what the settings are or what the defaults are? I'm going to set POLLFREQ=30 and DEADTIME = 90 and see if that has any effect. I'll check for the logs. And if that do...

I see this in syslog: Aug 12 03:57:22 orion upsd[18274]: Data for UPS [a102-apc-10] is stale - check driver (one for each UPS). Then I see a bunch of messages like this: Aug 12 03:58:02 orion upsd[18274]: write() failed for ::1: Broken pipe Aug 12 03:58:02 orion snmpd[2872]: Connection from UDP: [127.0.0.1]:50940 And then it returns to normal like this: Aug 12 03:58:04 orion upsd[18274]: UPS

...ps driver that recommend implementing that there as well, but nobody has written that code yet. > Does it sound like a network delay and that's why it put NA and marked the data as stale? Packet loss between the driver and the SNMP card in the UPS is more likely than delay (the MAXAGE and pollfreq arguments are in seconds), but as I mentioned, the current version of NUT retries a few times, so ultimately, packet loss shouldn't be a problem. > -Bob > > -----Original Message----- > From: Charles Lepple [mailto:clepple at gmail.com] > Sent: Friday, August 14, 2015 8:28 AM...

On Sep 19, 2017, at 9:50 PM, Ren? Berber <rberber at fastmail.fm> wrote: > > On 9/19/2017 6:45 PM, Charles Lepple wrote: > >> On Sep 19, 2017, at 1:36 PM, Ren? Berber wrote: > >>> My guess is that they are the same version (Synology keeps it updated). >> >> Is there a way to check which version they are using? (Just curious - probably will not

...ow: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 450 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 16.0 battery.voltage.nominal: 24 device.mfr: CP850PFCLCD device.model: CRDA103.981 device.serial: CPS device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.4.3 driver.version.data: CyberPower HID 0.3 driver.version.internal: 0.34 input.transfer.high: 139 input.transfer.low: 88 input.voltage: 117.0 input.voltage.nominal: 120 output.voltage: 117.0 ups.beeper.status: enabl...

On Mar 31, 2015, at 9:07 AM, Jason Gould <jgould at cddiagnostics.com> wrote: > I missed that snmp-ups set pollfreq to 30 by default. I?d hope that it would set deadtime to an appropriate value as well than, no? Is there a way to query what the settings are or what the defaults are? There is a TODO comment in snmp-ups that mentions doing something similar to usbhid-ups: just poll the important status OIDs every...

...rom /lib/nut. I use driver usbhid-ups (which communicate with ups), but subdriver resolving is automatic (no subdriver param), as i read source code this driver uses usb manufacture signature (vendorid/productid) to choose subdriver so there was no chance to more tests, just few params (pollonly, pollfreq, maxreport). But... Help needed ! OS: Debian Jessie (Proxmox 4.3 distro) NUT: 2.7.2 driver: usbhid-ups #cat ups.conf [ups] driver = usbhid-ups port = auto vendorid = 06da productid = 0005 pollonly pollfreq = 15 # lsusb Bus 001 Device 003: ID 06da:0005 Phoenixtec Power Co., Ltd [..cut....

On 9/19/2017 6:45 PM, Charles Lepple wrote: > On Sep 19, 2017, at 1:36 PM, Ren? Berber wrote: >> My guess is that they are the same version (Synology keeps it updated). > > Is there a way to check which version they are using? (Just curious - probably will not affect the problem you described.) None I could find, tried strings, might try telnet but my guess is that it will spew

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 will return the same value 14 times. Is my reasoning correct? Thanks Alan

It looks like I'm currently on 4.4.0-38 uname -a: Linux kvm 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux On Mon, Oct 10, 2016 at 10:04 PM, Charles Lepple <clepple at gmail.com> wrote: > > On Oct 6, 2016, at 7:26 PM, Lane Russell <lanerussell028 at gmail.com> wrote: > > Ubuntu Server 16.04.1 LTS > NUT 2.7.2-4ubuntu1

...and 2.7.2 (including the OpenBSD patches), I don't see any changes in NUT that might cause this. Your ProductID of 0002 is old enough not to have the broken interrupt pipe firmware, but that expects the OS to handle USB Interrupt In transfers properly. Otherwise, it will take up to 30 seconds (pollfreq) to re-fetch all of the variables that the UPS should provide through the Interrupt In pipe. I would try starting the driver with "-DDD", and capture that to a log: /usr/local/bin/usbhid-ups -DDD -a apcusb 2>&1 | tee /tmp/apcusb.log Let it run for about two minutes, then ^C, com...

...01 battery.runtime: 1320 battery.runtime.low: 300 battery.temperature: 36.0 battery.type: PbAc battery.voltage: 25.7 battery.voltage.nominal: 24.0 device.mfr: American Power Conversion device.model: Smart-UPS 1500 device.serial: ASXXXXXXXXXX device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.7.2 driver.version.data: APC HID 0.95 driver.version.internal: 0.38 input.sensitivity: high input.transfer.high: 253 input.transfer.low: 208 input.transfer.reason: input voltage out of range input.voltage: 233.2 outp...

...01 battery.runtime: 2220 battery.runtime.low: 120 battery.temperature: 30.6 battery.type: PbAc battery.voltage: 27.4 battery.voltage.nominal: 24.0 device.mfr: American Power Conversion device.model: Smart-UPS 1500 device.serial: AS0614322014 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.7.2 driver.version.data: APC HID 0.95 driver.version.internal: 0.38 input.sensitivity: high input.transfer.high: 127 input.transfer.low: 106 input.transfer.reason: input voltage out of range input.voltage: 121.6 outp...

...ything looks fine. However after a few hours I started getting emails and messages in the console about communication lost (COMMBAD) and shortly after it being established. This happens over and over again. I thought perhaps I needed to change some of the settings in ups.conf. I tried adjusting the pollfreq up to 30, using an snmp_version v2c, and a few other adjustments. However the behavior persists. I just stated to use NUT. I'm not sure if NUT is causing this, or perhaps the SNMPwebcard in the UPS. Or perhaps a switch on the network. And I'm not really sure how to figure it out. I'm s...