similar to: CGI-BIN for Nut

Thanks to the great help here, I now have a UPS spitting out something resembling a report descriptor. So since I seem destined to have to create a new USB HID subdriver, I figured I'd get started on the path. I followed all of the directions on the web....I used the script to generate the usbhid subdriver, feeding it the output of the usbhid-ups driver from reading my UPS. All that worked

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Has anyone gotten it working at all with Linux :) I picked one up for thiry bucks and would love to monitor it! Liz - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD/5fEIACpLcG4dhwRAmeCAJ9+8FGXqKoOlZdkw/KFXb9n0PEemwCdHaoD NVnv7JjmBAjNsExK6WzAdnA= =pcPX - -----END PGP

Den 14-03-2014 21:29, Rob Groner skrev: > It works pretty good after that. However, if I'm going to tailor > my hid2nut table, it would really help if there was some master list > of all the paths (input.voltage, battery.temperature, etc) NUT supports, > instead of having to dig through different driver files to see what's available. Is there some list? How about

Thanks to Olli, I can now talk to my PW9125 via SNMP: > upsc cscfups001@localhost ambient.temperature: 031.0 battery.charge: 090.0 battery.runtime: 2640.0 battery.voltage: 055.5 driver.name: snmp-ups driver.parameter.mibs: pw driver.parameter.port: cscfups001.cs.uwaterloo.ca driver.version: 2.1.0 driver.version.internal: 0.41 input.frequency: 060.0 input.voltage: 120.0 output.current: 020.0

Hi, These are the instructions I have about accessing nut online. By using the cgi use flag you have the files to use on the webserver. > > If you look in /usr/html after emerge you find the html files. > Copy this files to /var/www/localhost/htdocs/nut > (if you want it as www.my.org/nut ) > > > In /usr/share/nut you find the cgi files. Copy this files to >

I've recently moved from installing NUT from source to installing NUT from the FreeBSD package (FreeBSD 9.1). One would think that I might have learned not to change anything, but I made the change. And here is my tale of woe..... My first question is: is it possible to simulate a "UPS is on battery" state? Some background: UPS comm port is connected to and monitored by

I'm trying to set up nut with a MGE UPS equiupped with a network management card, but encountered a problem. UPS: MGE Pulsar M 3000 Network Management card (installed in the UPS): 66102 (2006 edition) Operating system: FreeBSD Nut port version: 2.0.5 Nut driver: snmp-ups According to MGE in Norway this card is supported by nut, but only the old version of the card (66244) is listed on

With automake, we collectively need to check to see if 'make distcheck' still works after adding or removing files. Basically, nothing will make its way into the NUT distribution tarball unless it is somehow mentioned in one of the Makefile.am files. See the packaging/RedHat directory for an example. Niels, thank you for spotting the extra nut.spec file in SVN; however, it needs to be

Great, thanks! Two questions: * what is a domain literal? Is this something like 192.168.0.1? In this case, the '[]' are probably unnecessary. * 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[] ? -- Peter Arjen de Korte wrote: > > Author:

Hi - I have 5 Linux servers connected to 1 SmartUPS 2200 VA. The software from APC for Linux requires a Windows machine be present on the network as a server in order to manage the Linux machines. This is a show stopper for us since we don't have access to any Windows machines. My first impression of NUT is it can shutdown the machine connected to the UPS via the serial cable but it

> Author: nba-guest > Date: Mon Apr 24 20:45:39 2006 > New Revision: 414 > > Modified: > trunk/CHANGES > trunk/drivers/cpsups.c > Log: > Fix C++ style declarations between statements > > Modified: trunk/CHANGES Niels, What is the reason for 'fixing' this? Constructions like these are used in many locations throughout the sources (not only in the

Hi developers, the current setup when doing a make (even a make -s) is very noisy, and makes it very easy to miss warnings from gcc. I would like to add a --slient option to libtool. How do the rest of you feel about that? /Niels -- Niels Baggesen - @home - ?rhus - Denmark - nba@users.sourceforge.net The purpose of computing is insight, not numbers --- R W Hamming

Since there is apparently no immediate solution to upsstats.cgi not reading the output voltage correctly, I have moved on to trying to use upsset.cgi. To recap the UPS is a CyberPower CyberPower CP1500PFCLCD UPS running on a headless server running Slackware 14.1 with the 3.10.7 kernel. The version of NUT is 2.71 and I am using usbhid-ups for communication with the UPS The problem is that when

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

My Belking is no longer responding to the megatec driver. I get * Starting UPS drivers ... Network UPS Tools - UPS driver controller 2.0.5 Network UPS Tools - Megatec protocol driver 1.5 (2.0.5) Carlos Rodrigues (c) 2003-2006 Megatec protocol UPS not detected. Driver failed to start (exit status=1) * Failed to start UPS drivers! Thank you, Barbara Smith -- Using Opera's

Whenever I try to set a value like battery.charge.low using the Network UPS Tools upsset 2.4.3 cgi script, I get an error: Unexpected response: ERR ACCESS-DENIED I can not start a quick UPS test either. Which credentials are used to logon to the upsset.cgi page? I've tried... the username that I configured in upsd.users the root credentials adding a POSIX account & password to match

Bill S wrote, On 4/15/2014 11:18 AM: > The problem is that when I run upsset.cgi I first get a prompt for > user name and password. I then enter the same username and password > as I established in upsd.users and it seems to accept it. upsset.cgi doesn't check that user/password is valid, it just tries it when doing a command. I just tested it, it is working for me on a remote and

I've got persistent trouble getting nut to work, though I think I've done everything by the book (the Debian specific readme included). I've tracked it down to upsd not working as it should: it just won't keep going. :( I.e. checking the process list (or using its reload command) shows that there just isn't a upsd process, at all. Starting upsd with a few -D's for

Den 28-06-2013 04:17, Mike. skrev: > > My first question is: is it possible to simulate a "UPS is on battery" > state? Instead of the real ups, use the dummy-ups driver /Niels -- Niels Baggesen - @home - ?rhus - Denmark - nba at users.sourceforge.net The purpose of computing is insight, not numbers --- R W Hamming

2006/4/4, Niels Baggesen <nba@users.sourceforge.net>: > On Tue, Apr 04, 2006 at 10:57:51PM +0200, Nick Rosier wrote: > > Again, with an unstripped version of newhidups. But it doesn't seem to > > give more information; no core dump either. Anything else I can try? > > Strace it and hope the file doesn't fill up my disk :-) > > It is probably better to try