similar to: Re: Serial Ports (Was Re: Common Power Management : NUT and HAL (stage 1))

Are there any plans for using serial PnP in NUT? I tried to implement this on the 'safenet' driver, but the support for this doesn't seem to be widespread among the UPSes compatible with this driver. So far, I have only managed to get one (a Sweex 1000) to output it, but unfortunately, it is probably too generic to be really useful for autodetection: PnP revision : 1.00 PnP EISA ID

I'm looking for people that are using the 'cyberpower' driver that has been available for some years now. It seems the overhauled 'powerpanel' driver could support your UPS too. The commands and status bytes used are identical, the only difference being the way the values read for battery charge, temperature and frequency are interpreted. If we can find a way to detect when to

I'm looking for people that are using the 'cyberpower' driver that has been available for some years now. It seems the overhauled 'powerpanel' driver could support your UPS too. The commands and status bytes used are identical, the only difference being the way the values read for battery charge, temperature and frequency are interpreted. If we can find a way to detect when to

>> Over the last couple months, we have had a couple incidents (luckily a= ll >> on weekends) where all 15 UPSs will mysteriously shut off, and we had = to >> manually power them back up. To top it off, there was nothing in syslo= g >> about any UPS going onto battery power and staying there - just a coup= le >> curious low-battery warnings from one of the UPSs. You

> Author: adkorte-guest > Date: Fri Feb 8 07:09:51 2008 > New Revision: 1285 > > Log: > Cleanup and change the arguments to the upsdebug_hex() function so that it > no longer requires casting to an unsigned char. > > Modified: > trunk/ChangeLog > trunk/common/common.c > trunk/include/common.h > > Modified: trunk/ChangeLog I would like to do

Citeren Arnaud Quette <aquette at alioth.debian.org>: > Author: aquette > Date: Mon May 18 12:14:54 2009 > New Revision: 1846 > > Log: > Enable timestamp on output messages (format "%H:%M:%S: msg") I think this should only be done for messages that are sent to stderr. In most cases, syslog will already prepend a timestamp, so this is probably redundant.

I want to propose to change the format of the entries in the data/driver.list file. Currently the format is (according to the header) # <manufacturer> <model name> <model extra> <driver> Of these fields, the <model extra> field is not very well defined now. For many devices, it contains information about the communication interface used (serial / USB / SNMP) while

Hi David and fellows, I'm reviving this important thread about a common power management. To sum up, the first aim is to allow a better user experience on Linux by bridging NUT with Linux HAL, and Gnome Power Management / any PM GUI. But it also initiate a bigger investigation about how to integrate NUT support for UPSs into the native OS Power Management infrastructure for all supported

> Added: > trunk/scripts/hotplug/Makefile.am > trunk/scripts/udev/Makefile.am > Modified: > trunk/ChangeLog > trunk/Makefile.am > trunk/configure.in > trunk/docs/configure.txt > trunk/scripts/Makefile.am > trunk/scripts/hotplug/ (props changed) > trunk/scripts/udev/ (props changed) > trunk/scripts/udev/README > Log: > -

Hi fellows, I'm really pleased to announce that a first stage of NUT and HAL [1] integration has been reached: NUT drivers (in fact, only newhidups, tripplite_usb and bcmxcp_usb for the moment) can feed HAL data. It's a "quick and dirty" hack, as a proof of concept, and there is still lots of things to be done, both on NUT and HAL sides. But it's a good base, and very

I don't understand how the info_len element from the hid_info_t structure is used in usbhid-ups. It appears to me that the only use of this element is now to indicate the length of the string: > float info_len; /* if ST_FLAG_STRING: length of the string */ The above is clear, if the element is flagged as a string, the size of this string is put in this variable, so that we can use this in

Hi Peter, The explanation on why I want to flush the report buffer after running instcmd() or setvar() was incorrect. It is not the variable thats get written, that needs to be read fresh from the UPS. That is already handled by HIDSetItemValue(), which reads back the value and thereby refreshes the report buffer. I goofed up here, I looked at the wrong parameters. :-( However, when I change the

> Author: adkorte-guest > Date: Mon Feb 25 20:40:41 2008 > New Revision: 1334 > > Log: > Allocate twice the maximum number of reports we expect (MAX_REPORTS), to > allow for bogus/duplicate reports. Retrospectively, this is gross hack at best and probably only good to fix the problem temporarily. I think I have a better solution available (in a similar way as r1210, that was

Maybe a stupid question, but how paranoid should I be when it comes to character maps? Is it safe to assume that if I want '\x41' to be sent to a UPS, that this equals sending the 'A' character? In other words, is it considered portable that (at least for the output of the serial functions) we use an ASCII character map? Otherwise, on (for example) an EBCDIC system (do these still

> +22 = Gamatronic UPSs with alarm interface > + [CP=RTS] [OL=CTS] [LB=\-DCD] [SD=DTR] > + > +22 = CyberPower SL seriess > + [CP=RTS] [OL=CTS] [LB=\-CAR] [SD=DTR] > + > + This part of the patch is no good. While TIOCM_CAR is equivalent to TIOCM_CD (at least in some implementations) CAR certainly isn't handled the same as DCD by genericups. It won't be

Browsing through the newhidups.c code, I stumbled across the following: /* master list of avaiable subdrivers */ static subdriver_t *subdriver_list[] = { #ifndef SHUT_MODE &generic_subdriver, #endif &mge_subdriver, #ifndef SHUT_MODE &apc_subdriver, &belkin_subdriver, &tripplite_subdriver, NULL #endif }; Shouldn't the 'NULL' terminator be outside the

> I see. For IP4 addresses, will ups@192.168.0.1:3493 still work as > expected? -- Peter Yes. Whatever is between '@' and the optional ':<portnumber>' is passed as hostname. Brackets (in case of domain literals) are removed. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57

> * are you sure you want to use fprintf(stderr, ...) in a library? > This doesn't seem like a good idea to me. Wouldn't it be more > consistent to extend upscli_errlist[] ? Errorcodes are passed in 'ups->upserror' (and 'ups->syserrno'). Uh oh, we don't have a connection to an UPS yet when we call upscli_splitname() or upscli_splitaddr(). The

> I see. For IP4 addresses, will ups@192.168.0.1:3493 still work as expected? -- Peter Yes. Whatever is between '@' and the optional ':<portnumber>' is passed as hostname. Brackets (in case of domain literals) are removed. One thing to note, in the released versions the use of IPv4 addresses for a hostname (in upsclient.c) is not guaranteed to work (according to POSIX):

> next_device: > + free(curDevice->Vendor); > + free(curDevice->Product); > + free(curDevice->Serial); > + free(curDevice->Bus); > usb_close(udev); > udev = NULL; > } Wouldn't it be necessary to check whether there is anything to free or not? Vendor, Product and Serial are set conditionally. In the lines upsdebugx(2, "-