similar to: Small patch to apcsmart driver

Hi, We have a several AP9612TH environmental cards (they have 2 probe connectors) inserted into our APC UPS devices which monitor temperature and humidity. The apcsmart nut module knows how to query the ambient.temperature and ambient.humidity using the 't' and 'h' commands of the UPS (refer to apcsmart.h). The results of the 't' and 'h' commands are from probe 1.

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

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 -

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.

Hey Jarett, 2009/2/24 <jarett.stevens at usermail.com> > After upgrading to the 2.4.1 version, I wasn't able to read as many > variables from my UPS. After a bit of experimentation, I determined that > the firmware on my UPS was different than what is currently in the > apcsmart driver, though it had worked before. I located my firmware > version (5ZM), and added in

Hi Alex, since I have no knowledge of the apcsmart driver, nor much time currently, I've forwarded your msg to the NUT development list. I hope somebody can take over your call. btw, please subscribe to the list for further discussions... 2007/5/28, Alex Brodsky <abrodsky at acs.uwinnipeg.ca>: > Hi, > > My name is Alex Brodsky, I am a faculty member at University of >

Hi Paul, Aha - we have both found the same. I am referring to your post from: http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-November/001344.html Looking at the source code the temp value is obtained by querying the following OID: #define APCC_OID_IEM_TEMP ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.0" notice that the OID ends with .0 (index zero). Well, looking at the

Perhaps someone else could confirm this, I have an APC UPS with a built-in network management card with environmental sensor for temp/humidity. The OID index for the sensors appears to be .1 (the last component for each of the OIDs listed below). The original source code has them at .0 drivers/apccmib.h #define APCC_OID_IEM_TEMP ".1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.1" #define

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() ?

Citeren Michal Soltys <msoltyspl-guest at alioth.debian.org>: > @@ -251,14 +251,14 @@ > if (do_lock_port) { > errno = 0; > ret = 0; > -#ifdef HAVE_UU_LOCK > + #ifdef HAVE_UU_LOCK > ret = uu_lock(xbasename(device_path)); > -#elif defined(HAVE_FLOCK) > + #elif defined(HAVE_FLOCK) > ret = flock(fd, LOCK_EX | LOCK_NB); > -#elif

Michal, Could we make this error a warning, or make the readback configurable? - Charles On Oct 21, 2011, at 7:56 PM, <nut-bugs at alioth.debian.org> <nut-bugs at alioth.debian.org > wrote: > Bugs item #313395, was opened at 2011-10-21 16:56 by Jesse Peterson > You can respond by visiting: >

I get the following errors constantly in my messages log: Sep 21 11:53:37 cgydc002 upsd[22659]: Connection from 127.0.0.1 Sep 21 11:53:37 cgydc002 upsd[22659]: Host 127.0.0.1 disconnected (read failure) Sep 21 11:53:37 cgydc002 upsd[22659]: Connection from 127.0.0.1 Sep 21 11:53:37 cgydc002 upsd[22659]: Host 127.0.0.1 disconnected (read failure) Sep 21 11:53:37 cgydc002 upsd[22659]: Connection

Hello, We have a APC SMART-UPS 2200 which gives the following status information: battery.alarm.threshold: 0 battery.charge: 089.0 battery.charge.restart: 00 battery.date: 01/10/04 battery.packs: 000 battery.runtime: 21180 battery.runtime.low: 120 battery.voltage: 52.95 battery.voltage.nominal: 048 driver.name: apcsmart driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0

I've merged apcsmart branch with master, so it should cover past issues mentioned on the mailing list - among those: - it's possible to select canonical and non-canonical mode - with the latter functioning as in apcsmart-old - CR is back to ignored characters, as IGNCR was not honored in some cases (mainly windows machines) - mutilvalue variables are now supported - the driver can

I've merged apcsmart branch with master, so it should cover past issues mentioned on the mailing list - among those: - it's possible to select canonical and non-canonical mode - with the latter functioning as in apcsmart-old - CR is back to ignored characters, as IGNCR was not honored in some cases (mainly windows machines) - mutilvalue variables are now supported - the driver can

Michal, I ran across this Debian bug today: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707223 It's a bit of a corner case, and it's for NUT 2.6.4 (apcsmart driver v3.04), but I was wondering if it was still applicable for the latest code? "nut reports 100% battery charge after unplugging the battery on a Smart-UPS 2200 RM (SUA2200RMI2U) using apcsmart. Powerchute correctly

On Aug 9, 2013, at 7:18 AM, Michal Soltys wrote: > I'm still a bit reluctant to merge it without a bit wider exposure, so if anyone has a possiblity to test it with some apc units - any feedback would be most welcome. Apparently, a lot of people are using NUT via packages, so: * users might not want to build from source if things are working * the packagers might not pick up a 2.7.x

https://alioth.debian.org/tracker/?func=detail&atid=411544&aid=311678&group_id=30602 I wanted to do it somewhat more flexibly/elegantly, so this is what I've been thinking about (or rather sitting on mostly implemented piece, still needing some testing though): - any variable that may include multiple data, would be (during runtime) split into appropriate *.N.* sets; for

Hello, I am working on getting NUT working with my Smart-UPS 900 UPS (with the C c= able) For several years, I have used the apcupsd product, but because of the nagios support for nut, I am working on switching over. Under apcupsd, I get tons of information from my UPS: # /usr/local/sbin/apcaccess status DATE : Sat Jul 09 12:56:41 CDT 2005 HOSTNAME : homer RELEASE : 3.8.6 UPSNAME :

Citeren Michal Soltys <msoltyspl-guest at alioth.debian.org>: > @@ -417,10 +414,12 @@ > if (flags & SER_CC) { > iset = IGN_CCCHARS; > aset = ""; > + sec = 6; usec = 0; > } > if (flags & SER_CS) { > iset = IGN_CSCHARS; > aset = ""; > + sec = 6; usec = 0; > } > > memset(buf, '\0', buflen);