similar to: logging strategy

Cheers, I don't think there is any particular strategy, at least not one I'd know of either :) So it is mostly ad-hoc, to keep smaller verbosity numbers reasonably quiet, and sufficient info to see the logic progression at a given debug level (e.g. if major milestones of a routine are logged at level N, further traces like "I saw value X here" would be N+1 or more). De-facto

Jim Klimov <jimklimov+nut at gmail.com> writes: > I don't think there is any particular strategy, at least not one I'd know > of either :) So it is mostly ad-hoc, to keep smaller verbosity numbers > reasonably quiet, and sufficient info to see the logic progression at a > given debug level (e.g. if major milestones of a routine are logged at > level N, further

I could not make the bestfortress driver 0.02 work for my Best Fortress LI675VA, so I have made a patch for the driver. The reason was, that all responses are preceded and terminated by CR LF, but the driver would discard everything after the first CR LF. The following patch discards everything up to the first LF. It also adds a debugging feature of displaying the accepted data (level 5 i.e. -D

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

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

I want to use upsdebugx, upslogx in 'clients/upsclient.c', however this fails with the following error messages (I trimmed the path to the build directory to <path> in order to prevent line wrapping): <path>/clients/upsclient.c:941: undefined reference to `upsdebugx' <path>/clients/upsclient.c:910: undefined reference to `upslogx'

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:

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

Hi all, I've been trying to get a TrippLite 700DV communicating with nut in Solaris. The problem was that I would successfully send a message to the ups, but wouldn't be able to receive anything. After some snooping around I found this bit of code in libusb.c libusb_get_interrupt(). #ifdef SUN_LIBUSB /* usleep(timeout * 1000); */ return 0;

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

I just hooked up an old Best Fortress (with new batteries). Those things are built like a tank, and it works out of the box in Fedora 14 (nut-2.6.2) thanks to the bestfortress driver still in the project. It had disappeared for 2.0, but I sent it in for 2.2, and you guys kept it going. -- Stuart D. Gathman <stuart at bmsi.com> Business Management Systems Inc. Phone: 703

Hi, Thanks to some older discussions on this list I found it quite easy to eventually track down problem with using USB cable with some more of Megatec/Q1 UPSes. The trick (which is done in megatec_usb, but not in blazer_usb) is to read in the junk that somehow gets into read buffers before sending any commands. (I inserted debug statements so it's easy to see that the data read is really

Hi all, I posted originally here last week: https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-October/013461.html Since then, I've been building and testing from source following the instructions a helpful reply in the above thread pointed out. The original problem is I've got one of these arduino HID power devices, as a project for a DIY UPS at home. This arduino is a composite

I am running nut in Fedora 17 (previously 16). There is a bug in startup that I think I understand well enough to explain. The symptom is that upsd refuses to start at boot time, complaining: Oct 12 22:28:22 melissa upsdrvctl[868]: Network UPS Tools - UPS driver controller 2.6.5 Oct 12 22:28:22 melissa bestfortress[937]: Startup successful Oct 12 22:28:22 melissa upsd[938]: fopen

[As posted as Ubuntu Question #184284 on Launchpad] Hi, I try to set up nut (2.4.3) on my Lucid (10.04.3 LTS) to make use of my old but very trusty UPS (Best Power Fortress 660 LI). Yes, this UPS is old (about 16 years), but with its third battery pack last week it is as good as new. It runs perfectly well with Windows XP, Vista and even Windows 7. But not so with Ubuntu and nut. After

Hi Jon, your patches are malformed because (presumably) your email client wrapped this lines. Could you please send these as a unified diff ("diff -u"), and send them in attachments, rather than as a copy-and-paste? Thanks, -- Peter Jon Gough wrote: > > Peter, > Here are the files I have worked on. I hope I have diff'd them > correctly. I have not touched the

Thank you for the investigation! I've thought about this in vague terms, i.e. that numbers like this should be configurable, but did not have time to read into USB-related libraries and specs to make any more specific sense of it (and the libusb code is not mine except the recent layers of cleanup). I guess I did not even realize that there is more than the regularly mentioned "interface

Hi, I started updating smart driver with a few things I've been missing. While going through the source: - in upsdrv_shutdown(), there're loads of printfs - they kinda look like a leftover from older debug times. Shouldn't they be changed into upsdebugx() or upslogx() ?

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.