similar to: New variables?

Dear Andreas, some googling revealed, you created a driver for the xanto series of online-usv.de. In what state it is currently? I've to manage a S2000 and would like to use nut for it, is it usable by now? Do you need another tester? TIA, Pete

From private E-mail: > > My question to you is how I should go about getting > > the changes back into the system. My work has been exclusively on the ONEAC > > driver and man page. The driver .c file is almost completely redone. > >how can you warrant compat? >Ie, if it's a full rewrite, what have you done to ensure that >currently supported devices will still

Hi Arnaud, Hi Scott, Hi list, Here is a patch to support the Zinto D from ONLINE USV-Systeme AG. I already sent a version to Russell Kroll (2006-04-09), without no response and I cannot find support for Zinto in svn until now. I found a discussion on this list about the Xanto from ONLINE, but the Zinto seems to use different commands. The commands are quite similar to those for Opti-UPS, so I

Hi Kirill, just to notify you that your al175 driver is being removed from the NUT tree, as of 2.4.0-pre1. if you wish to see it entering the tree again, please contact the Development mailing list to talk about it. Merry Christmas and happy New Year. Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader -

Hello, The UPS I am developing a driver to is able to report several flags for critical hardware conditions, like overheat, overload, inverter failure, output short etc. What should be the correct policy of operation when such a condition occurs? I think that the an UPS in such a condition is not reliable and therefore a system shutdown should be called. However, the developer's manual and

Hi all! The following files emits warnings when compiled with gcc 4.0: al175.c bcmxcp_ser.c belkinunv.c cyberpower.c everups.c powercom.c solis.c All warnings seem to be of this variety: everups.c:38: warning: pointer targets in passing argument 2 of 'ser_get_char' differ in signedness I suggest that those who fiddles with those drivers fixes the warnings and verifies that it works

I've just written an NUT driver to manage a Masterguard UPS connected via USB, and some questions arose. Why I wrote a new driver? The servers in question only have two serial ports, so I want to use USB. I first wrote the low-level USB routines expecting to integrate them into the existing masterguard driver. However, that driver was so rudimentary I wrote my own one. It can be

Hi Henning, you should get in touch with Carlos, who his developing a generic megatec driver (available from svn: http://eu1.networkupstools.org/source.html) Arnaud -- Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ OpenSource Developer -

Here are a series of my recent changes to NUT. The first few in the set are primarily little fixes and improvements. In among those are a few for .gitignore files which of course you can ignore for SVN, and there's one for a commit to a generated file which of course should not be tracked in any VCS. Then there are a couple or three to do with generating the header files used by

Hello, First of all thank you so much for the information. At 22:43 -0400 on 2014-5-15 Charles Lepple wrote: > > On May 15, 2014, at 9:39 PM, Stefan Bruda wrote: > > > What bugs be though is that I cannot seem to be able to read the > > remaining run time on battery. The battery charge is also widely > > inaccurate (it drops to zero really fast and stays

Cheers, One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 The gist of it is that "battery.voltage" and "battery.charge" were not always reported correctly with nutdrv-qx driver (might be handled better by blazer drivers though), and the overrides

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

G'day y'all, Here's a tiny patch set for drivers/apcsmart.c and drivers/apcsmart.h. Adds APC SmartUPS 1250 ("8QD" case) + 940-0024C recognition to apcsmart. (Unpatched apcsmart.c v1.99.8 misidentifies the SmartUPS 1250 as a "dumb" UPS.) For NUT 2.0.5+. NUT 2.0.5: Patches apply successfully. Builds successfully. Works as expected under Ubuntu 7.04. NUT 2.2:

On May 15, 2014, at 9:39 PM, Stefan Bruda wrote: > What bugs be though is that I cannot seem to be able to read the > remaining run time on battery. The battery charge is also widely > inaccurate (it drops to zero really fast and stays there). I read > somewhere that the usb.debug numbers may hold the key to this (at > least to the running time that is), but I don't know what

On May 19, 2014, at 7:12 PM, Stefan Bruda wrote: > Hello, > > First of all thank you so much for the information. No problem, glad it is useful. > [...] > Therefore as far as my UPS is concerned s_value[5] is wildly > incorrect. So it turns out that the RM15002U also does not report anything useful for s_value[5]:

Hello, I own an older Tripp Lite SMART3000RM2U (protocol 3003). It does not work with usbhid-ups but it mostly works with the tripplite_usb driver (nut 2.7.1, the latest in the Gentoo tree), in the sense that the status (on line, on battery, etc.) is detected correctly, the machine is shut down on critical battery, and I can even get some information from the UPS. This is how it all looks:

Hi, I'm having a hard time configuring a Mustek Powermust 600VA ups to work via USB with nut. I read somewhere that nut works OK via the rs232 cable, but unfortunately I don't have a COM port in my computer. The kernel detects the ups as an Xbox pad :) and loads the xpad module. I tried running /lib/nut/megatec with different /dev/ttySx but it displays megatec protocol UPS was not

Carlos Rodrigues wrote: > Author: carlosefr-guest > Date: Sat Dec 29 20:17:01 2007 > New Revision: 1204 > > Log: > - drivers/megatec.c: detect OB status while OFF. You've changed a bit more than this line suggests. [...] > @@ -565,10 +575,16 @@ > dstate_setinfo("input.voltage.fault", "%.1f", query.fvolt); >

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