search for: poll_interv

...qt 128 rq 6 len 256 > + ret -110 > +.fi > + > +In this case, simply modify the general parameter "pollinterval" to a higher > +value (like 10 for 10 seconds). This should solve the issue. > + Should we make this the default for this driver? For instance, by adding poll_interval = 10; in upsdrv_makevartable? It would still allow people to override this (driver specific) default value, but might be a safer default than the present default that is set in main.c and main-hal.c. Best regards, Arjen -- Please keep list traffic on the list

...h]: added sleep here, to limit the polling rate > (previously, the driver would completely ignore the poll interval and > would run upsdrv_updateinfo() without any delay in between) > > The changes to dstate-hal.[ch] should probably be backported to Testing > ASAP, since ignoring the poll_interval is not a good idea (you'll be > basically polling the UPS in a continuous loop, without any delays) The above is not true, I should have looked in main-hal.c before making all this noise. The function isn't used, so it is pretty irrelevant what is done inside it. Having said that, it...

...emainingTimeLimitExpired UPS.PowerSummary.PresentStatus.NeedReplacement UPS.PowerSummary.PresentStatus.OverLoad Note that these are all events that appear through HIDGetEvents() in upsdrv_updateinfo(), and all relevant elements are updated there. Here is my puzzlement: If I run with the default poll_interval (which first applies to dstate_poll_fds(), but indirectly also controls the upsdrv_updateinfo() frequency), there are updates roughly every 2 sec, as expected, and the three forms seem to cycle like this: (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (3) ... which has the effect that...

...for paranoid me. I do not know much about NUT, but after some Googling, one idea I have is to in /etc/nut/upsmon.conf on client change to this NOTIFYCMD "/etc/nut/shutdown_script.sh" NOTIFYFLAG ONBATT EXEC And then in /etc/nut/shutdown_script.sh have something like this #!/bin/bash poll_interval=5 wait_time=120 counter=0 no_wait_time=60 no_counter=0 while true do output=$(upsc qnapups at 192.168.222.252 ups.status) if echo "$output" | grep -q "OB" then counter=$((counter + poll_interval)) no_counter=0 else counter=0 no_counter=$((no_counter +...

...s function 1st argument is the struct timeval passed by value(!) Ergo, each time it's called in the { poll_and_process() }* loop, it's simply set to the same time (in future). The function then computes a difference with the actual time and uses the result as select timeout... I.e, if the poll_interval was simply passed to the function and directly used as select timeout, the result would be exactly the same. I think this definitely isn't the intended functionality; obviously, what was ment is to poll at most poll_interval seconds, then update data and poll again; i.e. the timeout should...

On Thu, Jun 14, 2018 at 09:24:48PM +0300, Nir Soffer wrote: > On Thu, Jun 14, 2018 at 9:16 PM Nir Soffer <nirsof@gmail.com> wrote: > > + headers = {"Content-Type": "application/json", > > + "Content-Length", str(len(buf))} There were a few Python syntax errors such as this one. They can be found by running: make -C v2v check

...]) * 0.6)) ; This suggests a fixed relationship between apparent and active power. This might be the case for the nominal values, but this is not true in the general case. So don't export 'ups.realpower' unless it is truly measured (which is not the case here). > 645 poll_interval = 2; Any particular reason to hardcode this? This might surprise people that attempt to override this value, so unless there is a real good reason to do this, it will be confusing. > 899 dstate_setinfo("ups.StatusUPS", "%08lX", > ups.StatusUPS) ;...

...> Actually it is easy to use real imageio server for testing. 1. install ovirt-imageio-daemon 2. configure it for testing # /etc/ovirt-imageio-daemon/daemon.conf [daemon] # directory with this structure # certs/ # vdsmcert.pem # keys # vdsmkey.pem pki_dir = test/pki poll_interval = 0.1 [images] port = 9876 [tickets] socket = /tmp/ovirt-imageio-daemon.sock 3. Now you can run it /usr/bin/ovirt-imageio-daemon To upload, without real engine, you can install your own ticket like this: 1. Create a ticket json: $ cat ticket.json { "uuid": "t...

...mocking the other engine methods: > Another option is to start the server from your tests like this. This > is how we run our tests. > > from ovirt_imageio_daemon import server > from ovirt_imageio_daemon import config > > config.daemon.pki_dir = test/pki > config.daemon.poll_interval = 0.1 > config.images.port = 9876 > config.tickets.socket = "/tmp/ovirt-imageio-daemon.sock" > > server.start(config) > > # run your test here... > > server.stop() [...] > However you can run virt-v2v locally against an oVirt instance without > > nee...

...; secret code for performing hangups and ; transfers flash_dir=/var/www/html/panel ; location of the .swf file in your disk ; (must reside somewhere inside your web root) poll_interval=120 ; Frequency in second to poll for sip status poll_voicemail=1 ; Poll for voicemail status also kill_zombies=0 ; 1 Enable automatic hangup of zombies...

...t; > Another option is to start the server from your tests like this. This > > is how we run our tests. > > > > from ovirt_imageio_daemon import server > > from ovirt_imageio_daemon import config > > > > config.daemon.pki_dir = test/pki > > config.daemon.poll_interval = 0.1 > > config.images.port = 9876 > > config.tickets.socket = "/tmp/ovirt-imageio-daemon.sock" > > > > server.start(config) > > > > # run your test here... > > > > server.stop() > > [...] > > However you can run virt-v2v loca...

2011/2/15 Lupe Christoph > On Monday, 2011-02-14 at 21:54:20 -0000, Arnaud Quette wrote: > > I definitely need more info! > > please reply to ALL: > > > - what is the exact model and date of manufacturing? > > SmartUPS 300I NET. I have the serial number (GS9809283199) but no date. > it seems to be a recent model. > - are you sure this unit is ok? > >

2011/2/15 Lupe Christoph > On Monday, 2011-02-14 at 21:54:20 -0000, Arnaud Quette wrote: > > I definitely need more info! > > please reply to ALL: > > > - what is the exact model and date of manufacturing? > > SmartUPS 300I NET. I have the serial number (GS9809283199) but no date. > it seems to be a recent model. > - are you sure this unit is ok? > >

...); /* publish the top-level data: version number, driver name */ - dstate_setinfo("driver.version", "%s", UPS_VERSION); + dstate_setinfo("driver.version", "%s", upsversion()); dstate_setinfo("driver.name", "%s", progname); /* The poll_interval may have been changed from the default */ Index: drivers/main.c =================================================================== --- drivers/main.c (revision 916) +++ drivers/main.c (working copy) @@ -578,7 +578,7 @@ dstate_init(progname, device_name); /* publish the top-level data: ver...

...DEBUG > interval(); > @@ -716,7 +721,7 @@ > /* Process pending events (HID notifications on Interrupt pipe) */ > for (i = 0; i < evtCount; i++) { > > - if (HIDGetDataValue(udev, event[i], &value, 2) != 1) > + if (HIDGetDataValue(udev, event[i], &value, poll_interval) != 1) > continue; > > if (nut_debug_level >= 1) { > @@ -807,7 +812,7 @@ > > void upsdrv_initups(void) > { > - int i; > + int i, mode = MODE_OPEN; > #ifndef SHUT_MODE > /*! > * SHUT is only supported by MGE UPS SYSTEMS units > @@ -831...

Hi; I'm having some trouble to comunicate with my just bought (08/17/15) Ups. According to SOLIS(8): SUPPORTED HARDWARE This driver has been tested with : Solis 1000 VA Solis 1500 VA Solis 2000 VA Solis 3000 VA Back-UPS BZ1200-BR Back-UPS BZ2200BI-BR So solis is the one to go for. Here is my scenario: SW: nut-2.7.3 (compiled from ports) OS: FreeBSD

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -