similar to: possible regression in genericups with Tripplite UPS

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 -

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

This patch introduces a handful of new options, I mentioned earlier in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02088.html See the large commit message in the follow-up for the details and rationale. I realize it's a bit larger diff - so if it's required I can split it into few smaller ones. Michal Soltys (1): APC smart driver update and new features.

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

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

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the

> Author: adkorte-guest > Date: Mon Jun 25 19:26:09 2007 > New Revision: 988 > > Log: > Update to reflect changes in the way we deal with dstate_dataok() and > dstate_datastale(). > > Historically it was needed to call dstate_dataok() regularly, to prevent > staleness warnings. This is no longer needed, now the server will PING > drivers it has not heard of

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 -

Hmm. Is there maybe something there already that will do this? Maybe kind of back-handed. In drivers/dstate.c, I see: In status_init(), if ?driver.flag.ignorelb? is set in the driver state, the ?ignorelb? flag is set. In status_set(), if ignorelb is set, and the status being set (presumably from the UPS) is LB, it?s ignored. In other words, LB reported by the UPS is ignored. In status_commit(),

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 All, I've finally found solutions for my previous problems. But since this includes changes in the shared files, I'd like to discuss them here. 1. Driver restart problem. When I start the driver for the first time, everything is ok. But when I want to restart it, problems begin. The driver fails to read Report descriptor for the second time (libusb_open is used to open the device).

Hi again, On 5/22/23 18:31, Willcox David via Nut-upsuser wrote: > Hmm. Is there maybe something there already that will do this? Maybe > kind of back-handed. > > In drivers/dstate.c, I see: > > 1. In status_init(), if ?driver.flag.ignorelb? is set in the driver > state, the ?ignorelb? flag is set. > 2. In status_set(), if ignorelb is set, and the status being set

Hello, I am trying to understand how to create a custom configuration for the genericups driver. My system simply signals RI on a serial port on low battery. That's it, nothing else. This serial port is also being used for communications so the other lines are going to be changing all the time, unrelated to the UPS state. Is there a "null" upstype I can use, and then add LB=RNG?

On Jun 20, 2013, at 9:48 PM, Reed Hedges wrote: > UPSPORT=/dev/ttyS0 > > # type cablep kill t powerok battok cableok > robot --- RI 0 /RI --- --- > ? > > Is there an equivalent of ?---? in genericups? I think it's pretty much any value other than a valid

Hi, I'm new to this list and I have a question concerning using the genericups driver (type 22) with the Cyberpower 485 in serial mode. When running the driver in debug mode: genericups -a myupsname_genericups22 -DDDDDD I observe the following statuses as the mains power dies, switching over to battery power, and then letting it discharge. Initially, with mains power on, status =

Hello, ahgu >I have a unisys UPS, I probed the RS232 and notice that pin 2, >(receive data) is going from -6v (OL) to 12v(OB), but I don't see the >setting for the genericups. Seems nobody else is using the RD pin? >Any driver I can use? >Thanks >-Andrew Try RX as signal name (not RD). -- Best regards, Sergiy mailto:rendol@mail.zp.ua

OK, I'll try "none" and see what happens. -----Original Message----- From: Charles Lepple [mailto:clepple at gmail.com] Sent: Thursday, June 20, 2013 10:14 PM To: Reed Hedges Cc: nut-upsuser at lists.alioth.debian.org Subject: Re: [Nut-upsuser] help creating custom genericups configuration - RNG only! On Jun 20, 2013, at 9:48 PM, Reed Hedges wrote: > UPSPORT=/dev/ttyS0 >

I have just committed an updated version of 'drivers/genericups.c' in the Development tree. Since I have no access to a contact closure UPS at the moment (the only one I have is located two hours driving from where I'm now), can someone who has please verify that it now works? I'm fairly certain that it fixes this problem, but it would be nice to have a report that it is actually

It look to me that overwriting UPSTYPE CP signal or polarity in ups.conf have no effect. Looking at drivers/main.c source show that &upstab[upstype].line_norm is set to custom CP in initinfo() only _AFTER_ the serial signals are actually set by upsdrv_initups().

It look to me that overwriting UPSTYPE CP signal or polarity in ups.conf have no effect. Looking at drivers/main.c source show that &upstab[upstype].line_norm is set to custom CP in initinfo() only _AFTER_ the serial signals are actually set by upsdrv_initups().