similar to: Why Type: UNKNOWN?

Here are a series of my recent changes to NUT. The first few in the set are primarily little fixes and improvements. In among those are a few for .gitignore files which of course you can ignore for SVN, and there's one for a commit to a generated file which of course should not be tracked in any VCS. Then there are a couple or three to do with generating the header files used by

Hi all! I'm wondering if there's anyone doing any hacking on the snmp-ups driver at the moment. I've started looking at implementing 3phase-support, and this uncovered some rather unpleasant stuff in the snmp-ups driver that I really need to fix in order to get things sane. Those of you that's allergic to SNMP might want to stop reading now, this is rather icky ;)

Gentlemen, I have now had a chance to run some initial tests of my changes to apc-hid.c of the current development tree. Running newhipups and inspecting the -DDDD output seems to indicate that with the fix below everything seems to work as expected. However, I have not yet shut my system in order to take the UPS out of action so that I can do my various tests with a lightbulb load. I still hope

On Apr 5, 2014, at 10:39 AM, Charles Lepple wrote: > On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at gmail.com> wrote: > >>> The upsrw command was designed for changing variables that are typically >>> stored in non-volatile memory on the UPS. Unfortunately, your UPS doesn't >>> seem to do that. >> >> Well, if it doesn't do that,

On Mar 3, 2017, at 8:21 AM, Charles Lepple <clepple at gmail.com> wrote: > > On Mar 2, 2017, at 3:38 PM, David Baker <david at baker.im> wrote: >> >> I?ve read the documentation, and it would appear that this can be set by the U-Talk protocol (page 34 of http://networkupstools.org/protocols/mge/9261zwfa.pdf) but I can?t seem to figure out how to send the device the

Hi all, we should have been found the problem. Attach the patch inclusive of this problem and the previous (Riello IDG400 wrong values & not powering off). Best regards, -----Messaggio originale----- Da: Nut-upsdev [mailto:nut-upsdev-bounces+e.parisi=riello-ups.com at lists.alioth.debian.org] Per conto di nut-upsdev-request at lists.alioth.debian.org Inviato: mercoled? 7 marzo 2018 13:03 A:

W dniu 24.08.2018 o 13:10, Charles Lepple pisze: > Sorry, I didn't mean to imply that the master branch was necessarily going to be different, just wanted to make sure you had everything set up to recompile. The real test is to see if things change after commenting out that line (such as by changing it to start with "//"): > > // { "shutdown.return", 0, 0,

On Saturday 05 Apr 2014 16:28:24 Charles Lepple wrote: > On Apr 5, 2014, at 10:39 AM, Charles Lepple wrote: > > On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at gmail.com> wrote: > >>> The upsrw command was designed for changing variables that are > >>> typically stored in non-volatile memory on the UPS. Unfortunately, > >>> your UPS

On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at gmail.com> wrote: >> The upsrw command was designed for changing variables that are typically >> stored in non-volatile memory on the UPS. Unfortunately, your UPS doesn't >> seem to do that. > > Well, if it doesn't do that, how come upsc reports the changed value? It is > only after I reboot the PC

Hi, I've recently got a Raspberry Pi working with NUT and my MGE Pulsar ESV+, using the U-TALK driver, a USB Serial adapter and original cable. I've overcome the documented problems with these units and have it running, except for one little niggle! It's installed in central Europe, where the utility voltage is 240v, it's constantly in trim mode and pushing the voltage down to

On Jun 3, 2014, at 1:28 AM, Mick wrote: > On Saturday 05 Apr 2014 16:28:24 Charles Lepple wrote: >> On Apr 5, 2014, at 10:39 AM, Charles Lepple wrote: >>> On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at gmail.com> wrote: >>>>> The upsrw command was designed for changing variables that are >>>>> typically stored in non-volatile memory on

Hi Arnaud & Charles, You?ll have to forgive my low level of Linux Understanding here?. I downloaded the source files, modified the appropriate driver file, re-compiled it (all of this was a lot of research and learning!) When I use the new driver I get ? Network UPS Tools - UPS driver controller 2.7.2 Network UPS Tools - MGE UPS SYSTEMS/U-Talk driver 0.93 (2.7.4.1) Can't chdir to

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 Here is a very minor patch for the bcmxcp.c driver, mainly fixing the function name used in debug statement, and at the same time fix indentation. Regards Alf Hogemark From 86c7940d0ea11b5b38a7f4518095ee2428d658c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alf=20H=C3=B8gemark?= <alf at i100.no> Date: Mon, 1 Jul 2013 21:11:40 +0200 Subject: [PATCH] bcmxcp: Fix method name outputted in

Hello Charles, Thank you for your reply. For the discrete value thing, this morning I did try to run sudo upsrw -s input.transfer.low=x -u * -p * ups I changed "x" value from 60 to 96 then checked upsc result. All the script return OK but only 84 and 96 got picked up and working. Out model is Eaton 3S 500. And in windows it has a Eaton Personal Solution Pac. In Battery transfer

On Jun 5, 2014, at 10:53 PM, Charles Lepple wrote: > As you have seen, the "default.*" and "overwrite.*" names are not actual variables: they are configuration options to change what is returned from upsc. That is why you get VAR-NOT-SUPPORTED. typo; should have been "override.*" -- Charles Lepple clepple at gmail

Thanks Charles, On Saturday 05 Apr 2014 12:53:06 Charles Lepple wrote: > On Apr 5, 2014, at 7:18 AM, Mick wrote: > > $ upsrw -s "ups.delay.shutdown"="30" iDowell at localhost > > Username (suzy): admin > > Password: > > OK > > This command is sending the value to the UPS (via the usbhid-ups driver). > > > $ upsc iDowell at localhost

Arnaud: in today's commits, I removed three lines that you apparently added on August 10: 1.1.1.1.8.1 (aquette 04-May-05): if (mode == HU_WALKMODE_INIT) 1.1.1.1.8.1 (aquette 04-May-05): { 1.1.1.1.8.1 (aquette 04-May-05): dstate_setflags(item->info_type, item->info_flags); 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): /* Verify variable setability/RW */

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

An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120214/96cc8043/attachment.html>