search for: variace

On 5/21/2017 10:39 AM, Charles Lepple wrote: > Mike, > > Thanks for the info. I have enough to add an entry to the DDL, but I have a few more questions inline. > > On May 14, 2017, at 1:21 PM, Mike wrote: >> >> [updated] >> >> OpenBSD 6.1/amd64 >> NUT 2.7.4p0 (from OpenBSD package) >> >> >> Results of upsc: >> >>

On Mar 23, 2014, at 11:12 PM, Bill S wrote: > The output of the driver is below. The incorrect voltage of 136 is > shown at 0.265256. It should match input voltage of 119 as shown at > 0.265219 but it doesn't. The voltages displayed on the UPS LCD panel > information however are equal and match the input voltage provided by > the driver. There might be other incorrect

On 5/30/2017 10:47 PM, Charles Lepple wrote: > On May 22, 2017, at 11:13 AM, Mike <the.lists at mgm51.com> wrote: >> >> On 5/21/2017 10:39 AM, Charles Lepple wrote: [snip] > Even though the CPS sub-driver has been written already, I would like to take a look at the raw "explore" mode output: > >

Dear helpers, does anyone know a function to fit a model with: - y mean that is regressed on a set of explanatory variables - y variace behaving as a garch or as a garch in mean Thank you so much for your help, Carlo

On May 22, 2017, at 11:13 AM, Mike <the.lists at mgm51.com> wrote: > > On 5/21/2017 10:39 AM, Charles Lepple wrote: >> >> Let me know if you're interested in figuring out if the battery.mfr.date value is stored somewhere else. > > Of course. The UPS is in production (ie., powering the servers in my > house), so it may be a few days before I can ~play~.

On Jun 3, 2017, at 2:21 PM, Mike <the.lists at mgm51.com> wrote: > > On 5/30/2017 10:47 PM, Charles Lepple wrote: >> On May 22, 2017, at 11:13 AM, Mike <the.lists at mgm51.com> wrote: >>> >>> On 5/21/2017 10:39 AM, Charles Lepple wrote: > [snip] > >> Even though the CPS sub-driver has been written already, I would like to take a look at the

On Nov 7, 2014, at 5:31 PM, hyouko at gmail.com wrote: >> Sure enough, it turned off after about 30 seconds (t=228). I unplugged it for about five seconds, and it came back on three minutes after I plugged it back in. However, the bypass bit inversion might be responsible for this: >> >> 228.304623 send: 'Q1' >> 228.515426 read: '(119.0 119.0 000.0 000

I have attached two .gz files of the driver output with the -DDDD option. One is for when the unit is on the line AC and the the other is when it is on battery so that there are at least two points of reference. In earlier tests, I did note that when the unit was placed on battery that the upsstats.cgi screen reported that the input voltage from 119V to 120V and did not go to zero as I expected

...$transect) flormat=as.matrix(florabund) abund.nb <-manyglm(flormat~transect*vegtype, family="nagative.binomial") predict(abund.nb, type= "response") ##Checking Model Assumptions plot(abund.nb) meanvar.plot(flormat~transect, col=as.numeric (vegtype)) #direct plot of mean-variace relationship anova(abund.nb, p.uni="adjusted") It's after running the last code line [>anova(abund.nb, p.uni="adjusted")], when I get thiis error: Error in XvarIn[nterms - i, varseq > i + minterm] <- 0 : (subscript) logical subscript too long Any idea what...

I recently purchased a CyberPower CP1500PFCLCD UPS as a replacement UPS for a headless server running Slackware 14.1 with the 3.10.7 kernel. I then downloaded the NUT 2.7.1 tarball on the server and following the directions installed the software. The installation went well and the UPS will shutdown the server using the forced down test and then it powers back up as it should. The

Yet again, sorry for the delay - I hope the UPS is still alive. >> I noticed that your UPS seems to support the 'M' command as a query of >> some sort (it replies '0'): now I'm curious as to what it does mean. >> >> It could be the 0-9 index of the user-settable voltage limits, page 19 of: >>

> Sure enough, it turned off after about 30 seconds (t=228). I unplugged it for about five seconds, and it came back on three minutes after I plugged it back in. However, the bypass bit inversion might be responsible for this: > > 228.304623 send: 'Q1' > 228.515426 read: '(119.0 119.0 000.0 000 60.0 13.5 XX.X 00001010' > 228.515494 ups_infoval_set: non

On Nov 1, 2014, at 9:28 PM, hyouko at gmail.com wrote: > Provided that the subdriver works, I'd like to see, if possible, the logs of: > - driver startup > - a command that succeeds > - a command that fails > - q1 when online and all's ok > - q1 on battery > - setting pins_shutdown_mode Attached is a log of most of these conditions. Looks like reading the status for

Sorry for my delay, I've only just read this mail. At first glance the driver looks like it should work, I will test it tomorrow (if possible) and let you know. I'll also give a reply to your questions. Many thanks for the work you've already put into this. -------------------------------------------------- From: <hyouko at gmail.com> Sent: Monday, June 30, 2014 12:42 AM To:

Sorry for the huge delay and thanks Charles for taking care of this topic. >> I'm running OpenSuse 13.1 and I have a Lupus 500 USB (Fideltronik) >> >> After quite a bit of playing around I managed to get the status of the UPS using the blazer_usb driver and running NUT 2.6.5. >> But unfortunately none of the Instcmds such as load.off etc. worked. > > Can you post

Finally I got time to test this. >>> Can you post the output of upsc, and note if any of those values look >>> wrong? serwer2:/tmp/nut-fabula # upsc myups battery.charge: 100 battery.voltage: 13.10 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.model: 500VA UPS device.type: ups driver.name: nutdrv_qx driver.parameter.pollfreq: 30