similar to: [nut-commits] svn commit r1765 - in trunk: . drivers man

Carlos, Today I was browsing through the NUT Tracker and noticed an entry which linked to a message on nut-upsdev: http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-January/000559.html Although the fentonups driver is no longer in the tree (since it was replaced by the megatec driver), I think there is still some merit in this patch. Notice the following lines from this message: >

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 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 -

Hi there First a big thank you to all nut developers. I tried the 2.0.4 as well as the 2.0.5-pre1 versions with my CyberPower OP1000E connected to a serial to USB converter. All I got was the following: # /usr/local/ups/bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.0.5-pre1 Network UPS Tools - CyberPower text protocol UPS driver .05 (2.0.5-pre1) Warning: This is an

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

Hi! I've recently come into to the possesion of a couple of Belkin Omniguard 3200 UPS's. Given the horrible apache/java based software they come with, I decided to see if I cannot get them to work with NUT. To cut a long story short, they work out to be SEC -based, and extensively modifying the nut-1.4 driver code to come up with the attached two files. I've marked them

The tripplite driver was developed on a machine with a reliable serial connection, and inherited the assumption that the serial line connection would not drop, reorder, or fail character read and writes. This patch adds significantly improved failure mode handling and also does basic checks of data validity. There's also a few minor cleanups/beautification. I've tested this code on my

Best fortress support was understandably dropped, but we still use them, and someone else may want the driver I ported to nut-2.0. We also often attach the serial cable from a UPS to a network terminal server, since servers these days don't come with very many serial ports. (They call them "legacy" ports.) I submitted a patch to support these for nut-1.x, and it was rejected

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, 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

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 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]:

Description: Replace many usleep and some sleep calls with nanosleep. usleep is stated in its manual page as removed by POSIX. Contrary to its predecessors, nanosleep semantics is well defined. The replacement, which is mostly in drivers, is untested. Supplements http://bugs.debian.org/633791. Last-Update: Sat, 13 Aug 2011 14:04:48 +0300 Index:

Hi ups-devel, As I looked throw www.networkupstools.org site, haven't found any pointers where to send patches, so I hope this is the right place. (Please let me know weather this is the right place.) The patch contains a minor change in the logic of the driver, our Effekta MHD 3000 UPS continuously writes status data to the serial port, so one has to send a CR character and empty the

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

> Do you think there could be some merit in either embellishing dummy-ups or deriving a new driver from it that is sanctioned as a 'file-based' interface for NUT? I'd say one problem would be relative inefficiency and overheads: you have one process talking to the device to extract data, save it into a file, another process to regularly fopen() and read it and tell `upsd` to

Hi All, i'm running blazer_usb on my home orvaldi ups and i'm observing in dmesg one, two or three segafults of blazer_usb per day and notifications about broken/re-established communication like this: blazer_usb[2985]: Communications with UPS lost: status read failed! blazer_usb[2985]: Communications with UPS re-established today i've started ups service again with attached (c)gdb

Arnaud Quette wrote: > Anyhow, I would more see this as a merge of all these drivers, with > some autodetection or flag/param to switch the mfr/model and maybe > capabilities... Whatever the driver name is, a good thing would be the > name of the protocol or something generic enough, though powermust is > fine. Ok, I made some minor changes to powermust, to make it less

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); >

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