Re: [Nut-upsuser] Driver macosx-ups failing on Yosemite

[Charles Lepple]

On Sun, Jun 28, 2015 at 11:58 AM, Charles Lepple wrote:

> Another potential problem that you might see is that the driver will trigger 
> an assertion and exit when the UPS is unplugged. Theoretically, this could be 
> fixed with a launchd plist that restarts the driver, but the usual way to 
> handle this in NUT is to mark the data as stale, and wait for the UPS to 
> reappear. (Does MacPorts use a launchd plist?)

Hi Sundeep,

If you pull from the latest Git master branch of NUT (as of
2015-09-07), I fixed the assertion when the cable is unplugged. Now,
it should mark the data as stale, and you should be able to unplug and
replug the USB cable.

I did a basic sanity check with an APC Back-UPS LS500, but as
mentioned before, if you see any problems with high CPU usage, please
use the Sample Process option.

-- 
- Charles Lepple

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (New output)

[Charles Lepple]

On Sep 11, 2015, at 8:11 AM, Mario Lobo <ml...@digiart.art.br> wrote:
> 
> On Thu, 10 Sep 2015 22:31:08 -0400
> Charles Lepple <clep...@gmail.com> wrote:
> 
>> On Sep 9, 2015, at 2:06 PM, Mario Lobo <ml...@digiart.art.br> wrote:
>>> 
>>> By the constance of header and footer bytes, I think something
>>> different is going on now.
>> 
>> Right, this is the resync code that @rpvelloso suggested.
>> 
>> https://github.com/networkupstools/nut/issues/231#issuecomment-138971923
>> 
>>> It still identifying as a Solis 1.0 (which is not) but at least it
>>> is doing it on its own, without gdb.
>> 
>> If I remember correctly, Bruno was mainly looking for OB/LB status,
>> so he mapped the APC model to the nearest Solis model. I've CC'd him
>> in case he has any other insights.
>> 
>> Bruno, the mailing list thread starts here:
>> http://article.gmane.org/gmane.comp.monitoring.nut.user/9306 and
>> here: http://article.gmane.org/gmane.comp.monitoring.nut.user/9317
>> 
> 
> Charles;
> 
> Do you think I could try this solis with nut and see what comes up?
> 
> Or you think it is not worth it yet?

The only way we will know if this works is if someone tests it...

It looks like the low-battery signal is calculated from the charge. I am not 
sure what effect the incorrect voltages will have on that calculation (I have 
not seen any numbers) but if they are all off by a constant factor, it should 
work.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Charles Lepple]

On Sep 10, 2015, at 8:49 AM, Rob Groner <rgro...@rtd.com> wrote:
> 
> Charles,
>  
> 3.16.6.-2-desktop

I think that corresponds to this file: 
http://lxr.free-electrons.com/source/drivers/usb/core/devio.c?v=3.16 (but I 
don't see anything obvious there)

What does "lsusb -vvv -d 2a37:" return? Usually I'd say run that as root when 
the driver isn't running, but I'm looking for the device descriptor, which 
should be available regardless.

The version number of your driver says "2.7.2.6_RTD". Which Git revision does 
that correspond to in the NUT repository (aside from your changes)? I'm curious 
because somewhere (af5f84c5) between 2.7.2 and 2.7.3, I removed a spurious 
usb_set_altinterface() call, and I'm wondering if that changes the claim/detach 
error messages.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] blazer_usb Shutdown

[Charles Lepple]

(please use reply-all - this list does not alter reply-to headers)

On Sep 10, 2015, at 6:23 AM, Thomas Aichinger <ta...@qpl.at> wrote:
> 
> Hi,
> 
> I am using a ALLNET 91500 UPS with blazer_usb driver
> 
> /usr/lib/ups/driver/blazer_usb -a ups91500 -L
> Network UPS Tools - Megatec/Q1 protocol USB driver 0.10 (2.7.1)
[...]
> I set delay.shutdown to 600 sec but UPS turns power off after about 120 sec.

The shutdown delay gets discretized into a few different values, and is then 
sent to the UPS:

http://www.networkupstools.org/protocols/megatec.html#_shutdown_command

I'm not too familiar with the internals of this driver (development has shifted 
to its successor, nutdrv_qx, which should also be available in v2.7.1) but it 
looks like you can manually test the shutdown with the following command (after 
everything else has been stopped; perhaps send this from another system?):

/usr/lib/ups/driver/blazer_usb -a ups91500 -DDD -k

You should see a debug line with "send: S10R000".

Although it appears that a 600-second delay is within spec, you could try 540 
to see if it makes a difference. It is also possible that the UPS is hardwired 
for a two-minute delay.

> I also tried to raise FINALDELAY to 600 and changed SHUTDOWNCMD to shutdown 
> -h +10

These don't affect the shutdown command that is sent to the UPS.

> This is quite useless ups always turns power off after about 120 sec, 
> regardless how much charge is left.
> Since my ESX needs about 5 min to stop all virtual machines and calm down it 
> is not helpful when UPS kills power after 2 min.
> 
Understood. We try to collect these differences between spec and response in 
the DDL, but your UPS had not been reported as of yet: 
http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/ 
(canonical URL is http://www.networkupstools.org/ddl/ but I'm getting a 503 
error at the moment.)

There is a similar problem with this UPS: 
http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/Fideltronik_INIGO/Viper_1200.html
 (Not to pick on Fideltronik, but they were the first entry I found.)

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] why upsc need no authentication?

[Charles Lepple]

On Sep 10, 2015, at 10:23 AM, d tbsky <tbs...@gmail.com> wrote:
> 
> Hi:
> I  found I can setup password for uspmon. but upsc can connect to
> any upsd without authentication. although the ups data is not very
> confidential, but I would like not to expose it to anyone who can
> connect to server.
> 
>is there any method to harden upsd? thanks for hint.

There are a few different approaches. If your version of NUT was build with 
TCP-wrappers, you can configure NUT to only allow certain clients to connect.

However, in most cases where you would consider TCP-wrappers, you would 
probably be better served with a kernel-level firewall.

There is also an option to compile NUT to verify client SSL certificates: 
http://www.networkupstools.org/docs/user-manual.chunked/ar01s09.html#_upsd_optional_client_authentication

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (New output

[Charles Lepple]

On Sep 9, 2015, at 2:06 PM, Mario Lobo <ml...@digiart.art.br> wrote:
> 
> By the constance of header and footer bytes, I think something
> different is going on now.

Right, this is the resync code that @rpvelloso suggested.

https://github.com/networkupstools/nut/issues/231#issuecomment-138971923

> It still identifying as a Solis 1.0 (which is not) but at least it is
> doing it on its own, without gdb.

If I remember correctly, Bruno was mainly looking for OB/LB status, so he 
mapped the APC model to the nearest Solis model. I've CC'd him in case he has 
any other insights.

Bruno, the mailing list thread starts here: 
http://article.gmane.org/gmane.comp.monitoring.nut.user/9306 and here: 
http://article.gmane.org/gmane.comp.monitoring.nut.user/9317

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Charles Lepple]

On Sep 10, 2015, at 10:28 AM, Rob Groner <rgro...@rtd.com> wrote:
> [...]
> I noticed the "can't open device" at the top of the listing before, but I 
> also saw that every other entry in the results from "lsusb -vvv" (including 
> the mouse) had the same string, so I didn't think it was unusual.  I did 
> notice that my USB stick didn't have that message.

Not a big deal, in this case. I was just looking for the device/configuration 
descriptors, and things look reasonable.

> Unfortunately, I don't recall much about the git pull, except when you told 
> me how to do it however many months back it was.  I pulled it and then went 
> on my merry way modifying it.  Is there some way to look in the code/data to 
> see it?

If it is still the same directory (with the .git metadata directory at the top 
level), you can say "git show".

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Charles Lepple]

On Sep 9, 2015, at 9:40 AM, Rob Groner  wrote:
> 
> I'm not sure which USB lib it compiled against.

What does this return?

ldd /path/to/driver___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Charles Lepple]

> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgro...@rtd.com> wrote:
> 
> linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups
> linux-vdso.so.1 (0x7fff403fc000)
> libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x7f7c34b56000)

The last line seems to indicate that it is the real libusb-0.1, not -compat.

What kernel version on openSUSE?

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

[Charles Lepple]

On Sep 8, 2015, at 4:48 PM, Rob Groner <rgro...@rtd.com> wrote:
> 
>   0.005927Device matches
>   0.005940failed to claim USB device: Device or resource busy
>   0.005954failed to detach kernel driver from USB device: No such file or 
> directory

Rob,

this is a bit of a tough one to track down.

The "Device or resource busy" message can either come from a kernel driver 
(usbhid, etc.) or from another userspace program. The simplest thing is to 
check for other copies of usbhid-ups (at the point when you run ' -k', 
it is expected that most processes will have terminated).

If it isn't that, you may need to verify whether you are compiling against 
libusb-0.1.x, or libusb+libusb-compat. In theory, it shouldn't make any 
difference, but in practice, there might be subtle differences in error 
messages that could help narrow things down.

Also, what does 'dmesg' say around the time that you run the driver?

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] monitoring Eaton parallel/redundant UPSs

[Charles Lepple]

On Sep 2, 2015, at 5:54 PM, John Thurston <john.thurs...@alaska.gov> wrote:
> 
> But what about that "Bypass Paralleling Switchboard"? I suspect it is 
> possible that it could be used to ignore the input from UPS-A and rely only 
> on UPS-B to handle the load. If I'm only monitoring the status of the UPSs, 
> how will I know that having UPS-A OL and 100% is irrelevant? Does anyone know 
> how to incorporate the state of this "paralleling" component into my NUT 
> monitoring?

Hi John,

I am not qualified to offer any advice about that bypass system (I try not to 
touch anything bigger than 120V/15A), but since nobody else has piped up yet: 
if you can get details from your clients about how that works conceptually, we 
can help map that into a NUT configuration.

The big question in my mind is whether there is some way to programmatically 
determine what state the circuit is in. If not, there is still probably a way 
to manually use the dummy-ups driver to add in a phantom UPS representing the 
parallel-fed state.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (update)

[Charles Lepple]

@rpvelloso on Github suggested some changes (driver version v0.64) that should 
help with the initial sync:

https://github.com/networkupstools/nut/commit/debc8e0280ea4de9a0db5ca34aa66705b285f61f

It's the solis_debug branch on Github.

Does that help? I'm concerned that it might get out of sync later, but I don't 
want to change too much at once.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] functional bug in code /clients/nutclient.cpp

[Charles Lepple]

On Sep 3, 2015, at 9:11 AM, Charles Lepple <clep...@gmail.com> wrote:
> 
> Which options are you passing to ./configure?

Just noticed that this defaults to "no":


./configure --help
[...]
  --with-dev  build and install the development files (no)


-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] functional bug in code /clients/nutclient.cpp

[Charles Lepple]

On Sep 1, 2015, at 4:26 AM, Paul Vermeer <p...@elspaulnz.com> wrote:
> 
> Hi nut users, (this is a re-send from the correct account)
>  
> With pleasure, I have been using the code provided. Managed to get all 
> working properly, except for the nutclient lib in C.

As you have noticed, nutclient has a few rough edges. The original upsclient 
library has had a lot more testing, although it is written in straight C.

Be careful with some of the other nutclient wrappers. There are try/catch 
blocks that mask exceptions.
 
> Both functions stringset_to_strarr and stringvector_to_strarr have a similar 
> bug in play. Although trivial in code, the coded function does not operate as 
> intended.
> The pointer increment is missing (see added line marked yellow below 
> [pstr++;]), which results in the same element being updated over and over 
> again, and then only leaving the last element of the list in the array.
 
I created an issue on Github to track this: 
https://github.com/networkupstools/nut/issues/232 
<https://github.com/networkupstools/nut/issues/232>

Should be easy to fix, but we also need to add some unit tests to keep this 
sort of thing from cropping up again.

> Kind regards, Paul Vermeer.
>  
>  
> (also I could not find out how to ‘install’ the include files properly using 
> the autogen.sh / .configure and make and make install scripts. – had to copy 
> them manually as I’m no expert in make scripts)
 
I was going to suggest that we should compare your settings to what Linux 
distributions do to package nutclient, but neither Debian nor Ubuntu has 
packaged it (only libupsclient*), and I haven't looked at other distributions 
yet. (This might be a sign...)

Which options are you passing to ./configure?

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] USB HID Spec help (passing strings)

[Charles Lepple]

On Sep 2, 2015, at 8:54 AM, Rob Groner <rgro...@rtd.com> wrote:
> 
>  
> No, just as a variable string descriptor.
>  
> By “variable string descriptor”, do you mean what is contained in the example 
> in the App Note?  I’m just asking for clarification, in case variable string 
> descriptor is something different than shown there.

By "variable" I mean "not const". Although they did not explicitly mark any of 
the structs "const", their code does not change any of the string descriptors 
at runtime.

>  
> The way they do the string descriptors in the example is how I have mine now. 
>  They return a size and address, but it is to something that was defined at 
> compile time.  I guess I’ve been fixated on that, so I don’t know if I can 
> simply pass a different string that what was defined before.  And I don’t 
> know how to handle something of an unknown size (though in my case, the MAX 
> size of the serial number can be defined)
Because the structs are not const, you should be able to write new values into 
them at runtime. (It's up to you to do this before the string is actually 
requested, but since string descriptors are not requested often, you could do 
it in something like GetStringDescriptor() just before it returns.)

You would need to change the "sizeof()" to be the actual length of that struct 
at runtime. It's a little tricky, because the base struct is 
sizeof(USB_STRING_DESCRIPTOR), and then you need to add 2*strlen(serial_number) 
if your copy of the serial number from EEPROM is ASCII. (Note that the ['M', 
'i', 'c', 'r', 'o'...] initialization is for a WORD[] rather than char[]. USB 
strings are 16-bit little-endian Unicode.)

Dragging in a copy of sprintf() might be overkill, but you could have a loop 
that reads in the bytes of the serial number, adds '0' (0x30) to each 4-bit hex 
digit, and writes that into the string descriptor.
>  
> That’s why I was asking about the variable string descriptor...it sounds more 
> like something where you can pass a string of any size and address, which 
> would definitely be what I’m looking for.
GetStringDescriptor() is returning a pointer via "return", and a length passed 
by reference ("*length = ..."), so as long as you construct the string 
descriptor to look the same as the statically-initialized ones, you should be 
all set.
>  
> Looking at the data being passed, I realized that battery.type is something 
> else that I possibly won’t know until the code is running.  Our UPS can use 
> different attached batteries, and will be able to discern what it is at 
> runtime, and that’s when it would be able to report battery.type.
For returning one choice from a limited set, you might want to create one const 
string descriptor for each battery type string, and choose one pointer/length 
pair at runtime.
>  
> Thanks for the help Charles…that is a very good link to the Appnote 
> considering you haven’t done PIC32 work.  J  My google skills failed me.
> 
No problem. Using the standard string descriptors means fewer special cases in 
our source code :-)

Note that you should be able to test reading the string descriptors by simply 
using "lsusb -v -d VID:" on your device (might need to be run as root, 
depending on permissions). Next to the iSerialNumber value, it will try to 
fetch the corresponding string descriptor and print it.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] Loses connection after a month or so

[Charles Lepple]

On Aug 29, 2015, at 3:11 AM, p...@smithp.co.uk wrote:
> 
> Is there a way (has anyone done it) to reboot (not shutdown!!) the host if 
> communications to the UPS fails – I want to automatically reboot my Pi after 
> a couple of minutes of no communications.
>  
> Has anyone done this? Is there a setting that I can add to monitor nut or the 
> usb subsystem and find out that comms has failed, then run a script to 
> reboot? 
>  
> I note that there is a message “Communications with UPS Liebert@192.x.x.x 
> lost” which occurs in /var/daemon.log if that helps!
> 
The "communications lost" message corresponds to the "COMMBAD" event. The list 
of events is here:

   http://www.networkupstools.org/docs/man/upsmon.html#_notify_events

There is a similar event, "NOCOMM", which is probably closer to what you are 
looking for. The `upsmon` daemon checks to see if it has been in the lost-comms 
state for a certain amount of time (controlled by the "NOCOMMWARNTIME" variable 
in upsmon.conf; defaults to five minutes), and if so, upsmon triggers the 
NOCOMM event periodically. In your case, you wouldn't care about the periodic 
nature, but the NOCOMMWARNTIME delay prevents the Pi from rebooting immediately 
upon an error.

You would then set up the NOCOMM event to trigger the EXEC rule (add "+EXEC" to 
the NOTIFYFLAG section of upsmon.conf), and then configure NOTIFYCMD to run a 
script that would reboot the Pi if the first parameter to the script is NOCOMM. 
If you don't already have a NOTIFYCMD, you could skip the script, and reboot 
directly.

It might sound complicated, but if you don't have anything else in upsmon.conf, 
it all boils down to this:

# Reference: http://www.networkupstools.org/docs/man/upsmon.conf.html
NOCOMMWARNTIME 240 # 4 minutes after COMMBAD
NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC
NOTIFYCMD "/sbin/shutdown -r now 'lost comms to UPS'"

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] USB HID Spec help (passing strings)

[Charles Lepple]

On Aug 28, 2015, at 2:21 PM, Rob Groner rgro...@rtd.com wrote:
 
 We’re wrapping up our first version of the UPS we’re making, and so I’m going 
 over the USB code and came across one loose end.  The serial number of the 
 unit (iSerialNumber according to the USB HID doc) is a constant, but it’s of 
 course a different constant for each UPS.

iSerialNumber does not need to be unique per device - it is not very many bits 
wide.

   Right now we store that value in the Flash on the device, but the only way 
 I’ve seen to pass the serial number over USB is to encode it as a constant in 
 the code and then reference it as a USB HID String Index.  We aren’t going to 
 rebuild/program for each UPS, so there must be a way to take the value in 
 flash memory and send that as the serial number.  In other words, how do you 
 send a “variable” length string across USB?  Actually, the length can be 
 known ahead of time, but the data itself will be the variable.

NUT and other tools match against the string returned from the get string 
descriptor request (not iSerialNumber itself - the string indexed by it) and 
the procedure for modifying that is going to be specific to each USB device 
controller.

Typically the string descriptor table is an array of pointers, and this is 
often why USB devices cluster the string indexes together starting at 1 (rather 
than having a sparse array). If you can make the pointer corresponding to the 
serial number point to RAM, you should be all set (Harvard architecture chips 
like PICs make this harder, but there is a C __attribute__ or something that 
you should be able to use). Otherwise, does your USB framework allow callbacks 
for arbitrary requests?

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (update)

[Charles Lepple]

On Aug 26, 2015, at 4:43 PM, Mario Lobo ml...@digiart.art.br wrote:
 
 1) run stty -f /dev/cuaU0 raw jusbefore running solis

What about this: run solis first, let it fail, then run stty?

The default settings look wrong, but in theory the driver should fix them up. 
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (update)

[Charles Lepple]

Turns out another user reported the same issue with a slightly different model: 
https://github.com/networkupstools/nut/issues/231 
https://github.com/networkupstools/nut/issues/231

The stty -f /dev/cuaU0 raw trick should help, but I am confused as to why 
FreeBSD has different raw settings than what is set up at the same time as 
the baud rate: 
https://github.com/networkupstools/nut/blob/master/drivers/serial.c#L163 
https://github.com/networkupstools/nut/blob/master/drivers/serial.c#L163

Before running stty raw, can you please send the output of stty -a -f 
/dev/cuaU0?

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (update)

[Charles Lepple]

On Aug 23, 2015, at 6:26 PM, Mario Lobo ml...@digiart.art.br wrote:
 
 I hope it helps!

It is a bit easier to read than the ktrace output. Here are the bytes received, 
without the other messages:

Network UPS Tools - Microsol Solis UPS driver 0.63 (2.7.3.1)
CommReceive: RecPack: (25 bytes) = 00 17 91 49 5e 5e bc fe bb 46 88 ac 1b 0a 
a0 ed 01 07 07 bb 46 82 ae 1b 09
CommReceive: RecPack: (25 bytes) = a0 04 02 06 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e dc fe bb 47 83 ad 1a 09
CommReceive: RecPack: (25 bytes) = a0 0a 02 07 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e e3 fe bb 46 88 ac 1a 0a
CommReceive: RecPack: (25 bytes) = a0 f4 01 08 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e d1 fe bb 46 88 ad 02 0b
CommReceive: RecPack: (25 bytes) = a0 0b 02 09 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e d4 fe bb 46 88 ad 1e 0a
CommReceive: RecPack: (25 bytes) = a0 1b 02 0a 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e 00 fe bb 46 88 ad 1d 0a
CommReceive: RecPack: (25 bytes) = a0 f6 01 0b 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e da fe bb 47 83 ac 1a 09
CommReceive: RecPack: (25 bytes) = a0 f4 01 0c 1d 0d 03 00 00 00 01 00 17 91 
49 5e 5e d0 fe bb 46 88 ad 1e 0a
CommReceive: RecPack: (25 bytes) = 0d 02 0d 1d 0d 03 00 00 00 01 00 17 91 49 
5e 5e f5 fe bb 47 83 ad 02 09 a0
CommReceive: RecPack: (25 bytes) = 02 0e 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e d9 fe bb 46 88 ac 1e 0b a0 1d
CommReceive: RecPack: (25 bytes) = 02 0f 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e 07 fe bb 47 88 ac 1c 0a a0 04
CommReceive: RecPack: (25 bytes) = 02 10 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e ed fe bb 46 88 ac 19 0a a0 07
CommReceive: RecPack: (25 bytes) = 02 11 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e ed fe bb 47 88 ad 23 0c a0 4c
CommReceive: RecPack: (25 bytes) = 02 12 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e 41 fe bb 46 83 ae 02 0a a0 1b
CommReceive: RecPack: (25 bytes) = 02 13 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e e9 fe bb 46 88 ad 1d 0a a0 f8
CommReceive: RecPack: (25 bytes) = 01 14 1d 0d 03 00 00 00 01 00 17 91 49 5e 
5e e5 fe bb 46 88 ae 1a 0a a0 ef
CommReceive: RecPack: (25 bytes) = 15 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e 
db fe bb 46 88 ad 1b 0a a0 f2 01
CommReceive: RecPack: (25 bytes) = 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e df 
fe bb 47 88 ad 1a 0a a0 f8 01 17
CommReceive: RecPack: (25 bytes) = 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e e6 
fe bb 46 83 ad 02 0a a0 e3 01 18
CommReceive: RecPack: (25 bytes) = 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e b4 
fe bb 47 88 ad 1d 0a a0 0f 02 19
Solis not detected! aborting ...

I highlighted the final character (0xfe/254). It seems as though the code 
expects the serial stream to always put the 0xfe character at the end of the 
buffer, but as you can see, that is not the case in the debug output. (The code 
loops twenty times, so it is not impossible for it to sync: this may be what 
happened when you ran the driver in gdb.)

We could modify the code to re-sync with the start character, but what concerns 
me is that a byte gets dropped occasionally. If you run stty -f /dev/cuaU0 
raw, then run the driver with the same debug flags, do you get the same sort 
of output, where the fe character moves left? You might also try unplugging 
the USB cable, then running the driver immediately after plugging it in again 
(maybe there is a buffer filling up - that happened a number of years ago on 
another USB interface on FreeBSD).

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR

[Charles Lepple]

On Aug 21, 2015, at 10:10 AM, Mario Lobo ml...@digiart.art.br wrote:
 
 Not sure what to look for yet. It might be easier to add in the debug
 calls to the source code-- can you try building NUT from source? If
 you installed via the ports tree (as opposed to binary packages), you
 should have most of the dependencies installed. You might also need
 libtool and autoconf, as mentioned in the second link below:
 
 http://www.networkupstools.org/docs/developer-guide.chunked/ar01s03.html#_source_code_management
 and
 http://www.networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building
 
 
 Yes I did build it through ports. I try to build a debug version of it.

Mario,

I added a few debug statements throughout the solis driver:

https://github.com/networkupstools/nut/tree/solis_debug

If you run into trouble with the initial build, there will be a tarball 
snapshot here shortly that bypasses some of the autoconf/libtool issues (look 
for the nut-* link under step 5):

http://buildbot.networkupstools.org/public/nut/builders/Debian-x64-gcc/builds/389

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] [meta] Yahoo, Gmail and DMARC

[Charles Lepple]

All,

Within the last year, Yahoo has published some strict DMARC filtering policies, 
and Gmail is dutifully rejecting emails that fail the DMARC policies. 
Unfortunately, this has some negative consequences for other list members, even 
those without a Yahoo address (in particular, Gmail bounces messages that fail 
the DMARC checks, and after a certain number of bounces, Mailman unsubscribes 
the Gmail member from the list).

Details: http://wiki.list.org/DEV/DMARC

The NUT lists are hosted on Debian's Alioth service, which appears to be 
running Mailman version 2.1.15. Unfortunately, this is too old to automatically 
adjust the headers to make the mail appear to be coming from the list server 
instead of the original sender. I have adjusted some of the parameters, but 
this is more to keep my mailbox from filling up with the 100+ bounce messages 
that came in this afternoon.

I would ask those who use a Yahoo address to please consider posting from 
another email address for the time being. As an alternative, you may also open 
an issue on our Github repository, even if it is more of a question than a bug, 
and we'll try to get back to you.

[Also, sorry for the cross-post: although not yet affected, I included 
nut-upsdev@ since the problem could also manifest itself there.]

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsdev] [meta] Yahoo, Gmail and DMARC

[Charles Lepple]

All,

Within the last year, Yahoo has published some strict DMARC filtering policies, 
and Gmail is dutifully rejecting emails that fail the DMARC policies. 
Unfortunately, this has some negative consequences for other list members, even 
those without a Yahoo address (in particular, Gmail bounces messages that fail 
the DMARC checks, and after a certain number of bounces, Mailman unsubscribes 
the Gmail member from the list).

Details: http://wiki.list.org/DEV/DMARC

The NUT lists are hosted on Debian's Alioth service, which appears to be 
running Mailman version 2.1.15. Unfortunately, this is too old to automatically 
adjust the headers to make the mail appear to be coming from the list server 
instead of the original sender. I have adjusted some of the parameters, but 
this is more to keep my mailbox from filling up with the 100+ bounce messages 
that came in this afternoon.

I would ask those who use a Yahoo address to please consider posting from 
another email address for the time being. As an alternative, you may also open 
an issue on our Github repository, even if it is more of a question than a bug, 
and we'll try to get back to you.

[Also, sorry for the cross-post: although not yet affected, I included 
nut-upsdev@ since the problem could also manifest itself there.]

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] Need help with Tripp Lite SMART1300LCDT NUT v2.7.3

[Charles Lepple]

On Aug 22, 2015, at 1:15 PM, Johnny Wong e430ben...@yahoo.com wrote:
 
 Did my last message get through?  I got a message from the list saying it 
 bounced or something like that?
 
I was just about to send an email about that. Your message got into the list 
archives: http://article.gmane.org/gmane.comp.monitoring.nut.user/9312

...but it is possible that others might not receive it due to Yahoo's DMARC 
policy.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR

[Charles Lepple]

On Aug 21, 2015, at 9:19 AM, Mario Lobo ml...@digiart.art.br wrote:
 
 On Aug 20, 2015, at 10:26 PM, Charles Lepple clep...@gmail.com wrote:
 
 On Aug 20, 2015, at 6:33 PM, Mario Lobo ml...@digiart.art.br wrote:
 
 ** cuaU0
 
 []/usr/local/libexec/nut/solis -D -a lobos -u root
 Network UPS Tools - Microsol Solis UPS driver 0.62 (2.7.3)
  0.00 debug level is '1'
 21.065536 Solis not detected! aborting ...
 
 It looks like /dev/cuaU0 is the port that was suggested for a 
 similarly-named model last year:
 
 http://article.gmane.org/gmane.comp.monitoring.nut.user/8554
 
 The binary patches mentioned in that thread have been superseded by source 
 code chances that are part of NUT 2.7.3.
 
 Unfortunately, as you have seen, the solis driver does not have much debug 
 output. What happens when you run it under ktrace?
 Man ... the output of ktrace is really big! it produced an output file
 of 200 k, attached to this e-mail (solis.txt).
 
 I don't even know what to look for!
 
 Do you have any ideas?

It's fairly large, but it compresses well. (Please keep the list CC'd - this is 
how people can find this information in the future.)

Not sure what to look for yet. It might be easier to add in the debug calls to 
the source code-- can you try building NUT from source? If you installed via 
the ports tree (as opposed to binary packages), you should have most of the 
dependencies installed. You might also need libtool and autoconf, as mentioned 
in the second link below:

http://www.networkupstools.org/docs/developer-guide.chunked/ar01s03.html#_source_code_management
 and 
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building

-- 
Charles Lepple
clepple@gmail




solis.txt.gz
Description: GNU Zip compressed data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR

[Charles Lepple]

On Aug 20, 2015, at 6:33 PM, Mario Lobo ml...@digiart.art.br wrote:
 
 ** cuaU0
 
 []/usr/local/libexec/nut/solis -D -a lobos -u root
 Network UPS Tools - Microsol Solis UPS driver 0.62 (2.7.3)
   0.00 debug level is '1'
  21.065536 Solis not detected! aborting ...

It looks like /dev/cuaU0 is the port that was suggested for a similarly-named 
model last year:

http://article.gmane.org/gmane.comp.monitoring.nut.user/8554

The binary patches mentioned in that thread have been superseded by source code 
chances that are part of NUT 2.7.3.

Unfortunately, as you have seen, the solis driver does not have much debug 
output. What happens when you run it under ktrace?

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need help with Tripp Lite SMART1300LCDT NUT v2.7.3

[Charles Lepple]

On Aug 19, 2015, at 12:08 AM, Johnny Wong e430ben...@yahoo.com wrote:
 
 Here are couple of things I tried.
  
 1)  Changed the USB cable.  Same problem
 2)  I put an old CyberPower CP550SL w/USBSERIAL and it recognize it 
 right away via the USB port
 I don’t know if that will give you any insight or eliminate certain things 
 with the Tripp Lite SMART1300LCDT or not.
  

Thanks for testing the USB cable and the other UPS - those are good data points.

I am surprised that I did not run across this thread earlier: 
http://article.gmane.org/gmane.comp.monitoring.nut.user/8700 (SMART1500RM2UN 
disconnects every 40-45 seconds)

I also did not see any changes in the FreeBSD source code that specifically 
mention the USB alt setting (although they have an unbelievable number of 
different ways to spell that). I will still try to set up a FreeBSD 10.2 box at 
some point for system testing.

You might also try booting from a Linux live CD and using their version of NUT 
to see if the SMART1300LCDT still disconnects. Tripp Lite has said that they 
only support certain distributions of Linux (I don't recall which, but I would 
assume Red Hat is among them), so if you can prove that there are problems with 
a supported Linux distribution, you might be able to get warranty service.

-- 
- Charles Lepple
https://ghz.cc/charles/



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need help with Tripp Lite SMART1300LCDT NUT v2.7.3

[Charles Lepple]

On Aug 17, 2015, at 11:56 AM, Johnny Wong e430ben...@yahoo.com wrote:
 
  What does that revision number correspond to in FreeBSD release numbers? 
  (e.g. 9.3, 10.0)
 
 FreeBSD 10.2-RELEASE #0 r286738M

Okay, thanks. I think this is the first report of FreeBSD 10.2, so hopefully it 
is not an issue inherent in the OS. I will see if I can upgrade one of my 
machines to test with another UPS brand.

 the last person probably wasn't able to give the ./configure probably because 
 most people uses the precompiled iso to install NAS4Free.  if you need the 
 ./configure I might have to look for their source on GitHub or something.

True, most people won't need to know the ./configure parameters. It looks like 
you found the driver path and the UPS name, so we're set for now. However, if 
you run across that part of the source code, it might be useful for later in 
case we need to rebuild a driver.

 
 /usr/local/libexec/nut/usbhid-ups -a upstl1300 -DDD
 Network UPS Tools - Generic HID driver 0.39 (2.7.3)
 USB communication driver 0.32
0.00 debug level is '3'
0.006296 upsdrv_initups...
[...]
   0.013551 Checking device (09AE/3016) (/dev/usb//dev/ugen0.5)
0.278818 - VendorID: 09ae
0.278835 - ProductID: 3016
0.278843 - Manufacturer: unknown
0.278852 - Product: unknown
0.278859 - Serial Number: unknown
0.278867 - Bus: /dev/usb
0.278876 Trying to match device
0.278925 Device matches
0.278937 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 
 0)

Just for grins, can you try adding usb_set_altinterface to the ups.conf 
section for your UPS, and see if that changes this part of the log? (That is, 
after [upstl1300]).

0.306126 HID descriptor, method 1: (9 bytes) = 09 21 11 01 00 01 22 
 6e 03
0.306148 HID descriptor, method 2: (9 bytes) = 09 21 11 01 00 01 22 
 6e 03
0.306156 HID descriptor length 878
5.279939 Unable to get Report descriptor: Input/output error

My other concern is that FreeBSD might not allow the method that we use to 
retrieve the Report Descriptor.

What do the following commands return (need to run them as root)?

usbconfig -u 0 -a 5 dump_device_desc
usbconfig -u 0 -a 5 dump_curr_config_desc
usbconfig -u 0 -a 5 do_request 0x81 0x06 0x2200 0 0x100

(I'm guessing on -u 0 -a 5 based on .../dev/ugen0.5 -- that might change if 
the UPS USB cable is unplugged and re-inserted.)

 cat /var/etc/ups.conf
 [upstl1300]
 driver = usbhid-ups
 port = auto
 pollfreq = 30
 productid = 3016
 
 Let me know what other information is required, I'll try my best to obtain it.

Thanks for sending ups.conf. That's all I can think of for now.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need help with Tripp Lite SMART1300LCDT NUT v2.7.3

[Charles Lepple]

On Aug 18, 2015, at 9:07 PM, Johnny Wong e430ben...@yahoo.com wrote:
 
 Is it possible that there is another copy of the driver running in the 
 background? There is apparently an issue where we only write a PID file when 
 the driver goes into the background, and -D prevents that.
  
 I don't see another usbhid-ups running ... unless its hidden  I would 
 have to install the unhide package then
 

What I mean is that you can't have more than one usbhid-ups process talking to 
the same UPS at one time - regardless of whether they write a PID file. In the 
case of running with -D, you would need to double-check for any in the 
background (and there was a PID file named usbhid-ups-upstl1300.pid). ps 
auxww|grep [u]sbhid-ups should show only one driver in either case.

Still looking into the altsetting issue. I would have to shuffle a few machines 
around to get a copy of 10.2 running on a box that isn't being actively used 
for anything else, but maybe there is something in their source control logs.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need the date included in nuts -wall msgs.

[Charles Lepple]

On Aug 18, 2015, at 1:22 PM, Gene Heskett ghesk...@wdtv.com wrote:
 
 On Tuesday 18 August 2015 09:50:32 Charles Lepple wrote:
 
 On Aug 18, 2015, at 3:27 AM, Gene Heskett ghesk...@wdtv.com wrote:
 Greetings all;
 
 Is it possible to set a logging option in one of the config files so
 that when we have a 1 second power bump, the date is included, both
 in the log, and in the -wall broadcast?
 
 Hey Gene,
 
 The syslog entry should have one-second resolution in the timestamps,
 and you could use the EXEC option in NOTIFYFLAG in upsmon.conf to
 call your own script on the ONBATT and ONLINE events (which would
 allow you to pass whatever message you want to wall).
 
 The syslog does not date that specific event:

Sorry, I wasn't specific. The logging goes through the (r)syslog daemon 
(LOG_NOTICE level for upsmon), and I think the default is for daemon messages 
to go to /var/log/daemon.log (although I am seeing a number of them in 
/var/log/syslog as well).

If /var/log/daemon.log is listed in /etc/syslog.conf (or rsyslog.conf? depends 
on the vintage) then you might check to see if that log file is still there, 
and has similar permissions to the other files in /var/log.

 I cannot put that printer on the 1500 WA UPS, as its drum heaters
 kicking in at the start of a job or at power up, cause the UPS to do an
 instant, protective shutdown.  But these bumps are so short the printer
 does not forget its turned on, but does trigger a re-init cycle.

There was a discussion a while back about using a mouse with its DC power lines 
routed through a relay with its coil on AC. That would take less power than 
using a printer as a power-fail sensor ;-)

 
 However, for a one-second glitch, many of the NUT drivers might miss
 that in their polling cycle. (This usually isn't a problem, since an
 UPS with a good battery should be able power the load for much longer
 than one poll interval.)
 
 This is one of the few cases where a dumb contact-closure UPS and a
 dedicated serial port monitor program might be a better fit. Which
 driver(s) are you using?
 
 Its a Belkin, ups.conf:driver=usbhid-ups.

This is one of those cases where you might be able to catch one-second events 
by reducing the driver parameter pollinterval from 2 to 1 second in ups.conf, 
and likewise for both POLLFREQ and POLLFREQALERT in upsmon.conf. However, 
hand-waving about Nyquist sampling rates and you're still talking 1+/-1 
second time resolution at the driver, and possibly worse at upsmon.

In usbhid-ups, the on-line/on-battery bits are refreshed at the higher 
pollinterval rate, and other less-important variables are polled every 30 
seconds. The Belkin driver appears to properly mark the important variables, 
but the higher polling rate hasn't been tested to my knowledge.

To get closer to the exact time, you could also add some custom logging right 
in the driver. It bypasses the upsmon latency, at least. Would require 
rebuilding the driver, but it's not too bad. This is on Ubuntu, right? Which 
version?

-- 
- Charles Lepple
https://ghz.cc/charles/



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need the date included in nuts -wall msgs.

[Charles Lepple]

On Aug 18, 2015, at 3:27 AM, Gene Heskett ghesk...@wdtv.com wrote:
 
 Greetings all;
 
 Is it possible to set a logging option in one of the config files so that 
 when we have a 1 second power bump, the date is included, both in the 
 log, and in the -wall broadcast?

Hey Gene,

The syslog entry should have one-second resolution in the timestamps, and you 
could use the EXEC option in NOTIFYFLAG in upsmon.conf to call your own 
script on the ONBATT and ONLINE events (which would allow you to pass whatever 
message you want to wall).

However, for a one-second glitch, many of the NUT drivers might miss that in 
their polling cycle. (This usually isn't a problem, since an UPS with a good 
battery should be able power the load for much longer than one poll interval.)

This is one of the few cases where a dumb contact-closure UPS and a dedicated 
serial port monitor program might be a better fit. Which driver(s) are you 
using?

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need help with Tripp Lite SMART1300LCDT NUT v2.7.3

[Charles Lepple]

On Aug 17, 2015, at 1:00 AM, Johnny Wong e430ben...@yahoo.com wrote:
 
 OS = NAS4Free (FreeBSD Revision: 199506)

What does that revision number correspond to in FreeBSD release numbers? (e.g. 
9.3, 10.0)

 NUT Version = 2.7.3 for other parts of NUT version is listed below
 NUT is part of the NAS4Free distribution
 Device = Tripp Lite SMART1300LCDT URL 
 http://www.tripplite.com/line-interactive-ups-system-desktop-tower-1300va-120v-usb-port-lcd-screen~SMART1300LCDT/
  
 PROBLEM:  NUT is ABLE to see the UPS BUT it is not getting the right(?) 
 descriptor?  I am using the usbhid-ups driver set.  I have tried others, 
 tripplite, tripplite_usb, and blazer_usb and none works.  This is the closest 
 I can see it being “working”
 
For that USB ID (09AE/3016), usbhid-ups is the correct driver.

 According to 
 http://www.networkupstools.org/ddl/Tripp_Lite/SMART1300LCDT.html.  It was 
 “verified” working with NUT version 2.6.4  

In a message on nut-upsdev, Marco Walther just cited this thread: 
http://thread.gmane.org/gmane.comp.monitoring.nut.devel/6482 which mentions 
that the UPS works on Debian Linux 7.1. Marco's patch is against NUT 2.7.3, and 
it just corrects some scaling of the variables, so it would have gotten well 
past the problem you mentioned. It sounds like this might be an issue with the 
FreeBSD USB stack.

I am not familiar with NAS4Free, but what do you get when you start the driver 
in debug mode? You will need to get to a root shell, then run something like 
/usr/local/libexec/nut/usbhid-ups -a upsname -DDD (replacing upsname with 
the name in ups.conf). Apologies in advance if you need to go hunting for the 
exact path of the driver or ups.conf: the last person to have an issue with 
NAS4Free did not get back to the NUT lists with the ./configure settings that 
NAS4Free uses to compile NUT.

[please use reply-all]

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] Small patch to scale the values for TRIPP-LITE SMART*LCDT's (please test)

[Charles Lepple]

On Aug 15, 2015, at 3:15 AM, Marco Walther ma...@sonic.net wrote:
 Hi,
 
 I just decided to fix some scaling issues for my UPS (TRIPP-LITE 
 SMART1500LCDT). Apparently that issue existed for some time (and I knew about 
 it as well:-()
 
 See http://thread.gmane.org/gmane.comp.monitoring.nut.devel/6482 for a thread.
 
 My little patch is attached (against 2.7.3). It seems to be working better 
 for me but I don't have any other TRIPP-LITE's to test that I did not break 
 anything:-( So, please check it!

Hi Marco,

Thanks for the patch. I'm switching this to the nut-upsuser list to get a wider 
audience for testing.

In case others run across this problem, could you please send the output of 
upsc for your UPS, and also the output of lsusb -vvv -d 09ae:? If you want 
to mask out part of the serial number, it is listed in ups.serial (and 
device.serial) but the more information you can leave, the better we can 
identify any patterns.

If there is firmware version information in the USB descriptors, we might want 
to limit the scaling to certain versions.

Thanks,

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] [Nut-upsdev] Small patch to scale the values for TRIPP-LITE SMART*LCDT's (please test)

[Charles Lepple]

On Aug 15, 2015, at 3:15 AM, Marco Walther ma...@sonic.net wrote:
 Hi,
 
 I just decided to fix some scaling issues for my UPS (TRIPP-LITE 
 SMART1500LCDT). Apparently that issue existed for some time (and I knew about 
 it as well:-()
 
 See http://thread.gmane.org/gmane.comp.monitoring.nut.devel/6482 for a thread.
 
 My little patch is attached (against 2.7.3). It seems to be working better 
 for me but I don't have any other TRIPP-LITE's to test that I did not break 
 anything:-( So, please check it!

Hi Marco,

Thanks for the patch. I'm switching this to the nut-upsuser list to get a wider 
audience for testing.

In case others run across this problem, could you please send the output of 
upsc for your UPS, and also the output of lsusb -vvv -d 09ae:? If you want 
to mask out part of the serial number, it is listed in ups.serial (and 
device.serial) but the more information you can leave, the better we can 
identify any patterns.

If there is firmware version information in the USB descriptors, we might want 
to limit the scaling to certain versions.

Thanks,

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Anyone still have a Tripp-Lite 3004-protocol USB UPS?

[Charles Lepple]

I was cleaning up some digital detritus when I ran across an old SVN
branch for the proprietary Tripp Lite 3004 USB protocol (the non-PDC
variety). It looks very similar to the binary 3005 protocol, which has
been added to NUT, but I'd like to have someone sanity-check things
before we claim compatibility.

Any volunteers?

I'm not sure what models this covers, except maybe the SMART1050SLT.
These are units with USB ID 09AE:0001, and they get further along in
the detection sequence with the tripplite_usb driver than with the
other USB drivers.

-- 
- Charles Lepple

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] occassional problem wtih upslog and apc ups units via snmp ... [NA] status

[Charles Lepple]

On Aug 14, 2015, at 8:53 AM, Bob Brown bbr...@harpercollege.edu wrote:
 
 I see this in syslog:
 Aug 12 03:57:22 orion upsd[18274]: Data for UPS [a102-apc-10] is stale - 
 check driver

I don't have a SNMP UPS to test with, and this might be different for NUT 
2.4.1, but the current defaults seem to make stale data more likely in your 
case.

In http://www.networkupstools.org/docs/man/snmp-ups.html#_extra_arguments the 
default for pollfreq is 30 seconds, and in 
http://www.networkupstools.org/docs/man/upsd.conf.html the MAXAGE default is 
15 seconds. So you might want to either increase MAXAGE, or decrease pollfreq.

I would recommend making MAXAGE at least pollfreq (possibly 1.5x larger), 
because decreasing pollfreq might run up against the amount of time that it 
takes to poll all of the SNMP variables from the UPS. There are some retries 
and timeouts in snmp-ups which make this difficult to guess without seeing the 
debug logs. You might check the list archives to see if anyone has suggestions 
on what pollfreq and MAXAGE values worked for them.

 (one for each UPS).
 
 Then I see a bunch of messages like this:
 
 Aug 12 03:58:02 orion upsd[18274]: write() failed for ::1: Broken pipe

This just means that the client (upslog, probably) disconnected before upsd 
expected the session to end. The upsd-to-driver connection is a Unix-domain 
socket (and the driver-to-UPS connection is UDP).

 Aug 12 03:58:02 orion snmpd[2872]: Connection from UDP: [127.0.0.1]:50940
 

Might be unrelated, unless I misunderstood your NUT setup (upslog - upsd - 
snmp-ups - UPS). The snmpd daemon and the UPS comms card are SNMP servers 
(agents in SNMP parlance, IIRC), and snmp-ups is a SNMP client.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] occassional problem wtih upslog and apc ups units via snmp ... [NA] status

[Charles Lepple]

[please keep the list CC'd, thanks]

 On Aug 14, 2015, at 10:27 AM, Bob Brown bbr...@harpercollege.edu wrote:
 
 Would it put NA in the log files if maxage was too short?

I think so. I haven't tried it, but if snmp-ups polls every 30 seconds, and 
MAXAGE is 15, then with a random polling interval, 50% of the time the data 
would be more than 15 seconds old. In practice, the driver and upsd were 
probably started around the same time, and due to differences in timing between 
upsd and the driver, they occasionally drift out of sync. (Increasing MAXAGE is 
probably the simplest way around that.)

The usbhid-ups USB driver (which tends to get a lot more testing these days) 
splits polling into high and low priority updates, so that important variables 
get update frequently (many times in one MAXAGE period), and other variables 
get updated later. But successful high-priority updates clear out the data 
stale flag. There are comments in the snmp-ups driver that recommend 
implementing that there as well, but nobody has written that code yet.

  Does it sound like a network delay and that's why it put NA and marked the 
 data as stale?

Packet loss between the driver and the SNMP card in the UPS is more likely than 
delay (the MAXAGE and pollfreq arguments are in seconds), but as I mentioned, 
the current version of NUT retries a few times, so ultimately, packet loss 
shouldn't be a problem.

 -Bob
 
 -Original Message-
 From: Charles Lepple [mailto:clep...@gmail.com] 
 Sent: Friday, August 14, 2015 8:28 AM
 To: Bob Brown
 Cc: nut-upsuser@lists.alioth.debian.org
 Subject: Re: [Nut-upsuser] occassional problem wtih upslog and apc ups units 
 via snmp ... [NA] status
 
 On Aug 14, 2015, at 8:53 AM, Bob Brown bbr...@harpercollege.edu wrote:
 
 I see this in syslog:
 Aug 12 03:57:22 orion upsd[18274]: Data for UPS [a102-apc-10] is stale - 
 check driver
 
 I don't have a SNMP UPS to test with, and this might be different for NUT 
 2.4.1, but the current defaults seem to make stale data more likely in your 
 case.
 
 In http://www.networkupstools.org/docs/man/snmp-ups.html#_extra_arguments the 
 default for pollfreq is 30 seconds, and in 
 http://www.networkupstools.org/docs/man/upsd.conf.html the MAXAGE default 
 is 15 seconds. So you might want to either increase MAXAGE, or decrease 
 pollfreq.
 
 I would recommend making MAXAGE at least pollfreq (possibly 1.5x larger), 
 because decreasing pollfreq might run up against the amount of time that it 
 takes to poll all of the SNMP variables from the UPS. There are some retries 
 and timeouts in snmp-ups which make this difficult to guess without seeing 
 the debug logs. You might check the list archives to see if anyone has 
 suggestions on what pollfreq and MAXAGE values worked for them.
 
 (one for each UPS).
 
 Then I see a bunch of messages like this:
 
 Aug 12 03:58:02 orion upsd[18274]: write() failed for ::1: Broken pipe
 
 This just means that the client (upslog, probably) disconnected before upsd 
 expected the session to end. The upsd-to-driver connection is a Unix-domain 
 socket (and the driver-to-UPS connection is UDP).
 
 Aug 12 03:58:02 orion snmpd[2872]: Connection from UDP: [127.0.0.1]:50940
 
 
 Might be unrelated, unless I misunderstood your NUT setup (upslog - upsd - 
 snmp-ups - UPS). The snmpd daemon and the UPS comms card are SNMP servers 
 (agents in SNMP parlance, IIRC), and snmp-ups is a SNMP client.
 
 -- 
 Charles Lepple
 clepple@gmail
 
 
 

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] occassional problem wtih upslog and apc ups units via snmp ... [NA] status

[Charles Lepple]

On Aug 13, 2015, at 12:45 PM, Bob Brown bbr...@harpercollege.edu wrote:
 
 Os is redhat enterprise, kernel 2.6.18-164.2.1.e15
 NUT is apparently 2.4.1
 It was installed by tar.
  
 Monitoring a lot of apc UPS units—mostly Smart-UPS of various flavors, also a 
 Silcon DP380E.
  
 Normally works just fine…  “upslog” writes status log every 30 seconds with 
 various parameters..
  
 Every so often, one of the UPS units has a log entry of:
  
 20150812+035542+NA+NA+NA+[NA]+NA+NA+NA
  
 When it normally looks like:
  
 20150813+114309+100.00+115.00+39.00+[OL]+25.00+60.00+1020.00
  
 What does it mean when it  puts NA in the log file?

Every log interval, each variable is fetched from the server, and if there is 
an error retrieving that value at that time, NA is logged:

https://github.com/networkupstools/nut/blob/master/clients/upslog.c#L203

Since they are all NA at the same time, it is likely that there is a 
communication problem, either between upslog and upsd, or between upsd and the 
driver. In either case, there is probably a syslog message describing the 
problem in more detail.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

[Charles Lepple]

On Jul 28, 2015, at 12:13 PM, AIYL adliya...@gmail.com wrote:

 Before contacting Synology and Netgear/Readynas, I’d prefer to make sure that 
 the NUT UPS Server has been setup correctly and that the “experimental” 
 MACOSX-UPS driver is equivalent to a standard “usb” driver in terms of 
 server/client communications.

I flagged it experimental because the UPS-to-driver interface is not as 
robust as USB or serial, but that shouldn't affect the upsd-to-NAS connection. 
Once the driver starts, and assuming the UPS is not disconnected, things should 
work similarly to other drivers.

Gracefully handling disconnection is a known issue for the macosx-ups driver, 
and it is also known that the information provided by OS X is less detailed 
than what you would get from usbhid-ups on a non-OSX system. Hopefully the 
latter is not causing an issue: the NAS should not be relying on anything other 
than ups.status and possibly a few other variables.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

[Charles Lepple]

[forwarded without attachment]

I’ve not been able to solve some issues regarding the communication between a 
NUT Server running the MACOSX-UPS driver and the NUT clients on networked 
NAS’es.

NUT Software installed on a Macmini running OSX Yosemite has managed to 
shutdown the networked devices, a Readynas and a Synology NAS, being all 
devices powered by the same UPS.

Network setup:

Network UPS Management Software:
NUT ver 2.7.3, installed via Fink Commander in Mac mini.
Driver: MACOSX-UPS Ver 1.1

Macmini running NUT Server connected via USB to the UPS:
Model Name: Mac mini mid 2011
System Version: OS X 10.10.4 (14E46)
  Kernel Version:   Darwin 14.4.0

UPS:
APC Back-UPS 550 BE550G

NAS #1:
Model: Netgear ReadyNAS NV+ v1 [X-RAID]
Firmware: RAIDiator 4.1.14 [1.00a043] 
Memory: 1024 MB [2.5-3-3-7]

NAS #2:
Model name: Synology DS211j
DSM version: DSM 5.2-5592 Update 1

NUT Terminal commands and output:
A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsdrvctl start
Password:
Network UPS Tools - UPS driver controller 2.7.3
Network UPS Tools - Mac OS X UPS meta-driver 1.1 (2.7.3)
Warning: This is an experimental driver.
Some features may not function correctly.

kill: No such process
A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsd
Network UPS Tools upsd 2.7.3
kill: No such process
/sw/etc/nut/upsd.conf is world readable
listening on 10.0.2.151 port 3493
listening on 127.0.0.1 port 3493
/sw/var/run/ups is world readable
Connected to UPS [ups]: macosx-ups-ups
/sw/etc/nut/upsd.users is world readable
A-Mac-mini:~ admmacmini$ upsc ups
battery.charge: 42
battery.runtime: 180
battery.voltage: 13.010
device.mfr: (unknown)
device.model: Back-UPS ES 550 FW:843.K2 .D USB FW:K2
device.type: ups
driver.name: macosx-ups
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.3
driver.version.internal: 1.1
ups.status: OL CHRG
A-Mac-mini:~ admmacmini$ 


Comments:
1.- The two NAS’es performed a shutdown after UPS power loss. Main objective 
accomplished.


2.- The Readynas acknowledges partial connection to the UPS server, the 
following messages can be read:

a.- Frontview Health Report
See fig ‘A

b.- Frontview Log
See fig “B


3.- The Synology inconsistently acknowledges connection to the UPS server , the 
following messages can be read:

a.- Control Panel UPS setup menu
See fig “C

b.- Logs Report
See fig “D


4.- Although the communication problem between the UPS server and the NAS’es 
NUT clients has not been solved, it doesn’t affect the main function, which is 
to shutdown the NAS’es during a power loss of the UPS.


I’ll appreciate any help in setting up the NUT server configuration to improve 
the communication between the clients and the server.


Thanks,

Adolfo Yanes



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

[Charles Lepple]

 I’ve not been able to solve some issues regarding the communication between a 
 NUT Server running the MACOSX-UPS driver and the NUT clients on networked 
 NAS’es.
 
 NUT Software installed on a Macmini running OSX Yosemite has managed to 
 shutdown the networked devices, a Readynas and a Synology NAS, being all 
 devices powered by the same UPS.
 
 Network setup:
 
 Network UPS Management Software:
 NUT ver 2.7.3, installed via Fink Commander in Mac mini.
 Driver: MACOSX-UPS Ver 1.1
 
 Macmini running NUT Server connected via USB to the UPS:
 Model Name:   Mac mini mid 2011
 System Version:   OS X 10.10.4 (14E46)
   Kernel Version: Darwin 14.4.0
 
 UPS:
 APC Back-UPS 550 BE550G
 
 NAS #1:
 Model: Netgear ReadyNAS NV+ v1 [X-RAID]
 Firmware: RAIDiator 4.1.14 [1.00a043] 
 Memory: 1024 MB [2.5-3-3-7]
 
 NAS #2:
 Model name: Synology DS211j
 DSM version: DSM 5.2-5592 Update 1
 
 NUT Terminal commands and output:
 A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsdrvctl start
 Password:
 Network UPS Tools - UPS driver controller 2.7.3
 Network UPS Tools - Mac OS X UPS meta-driver 1.1 (2.7.3)
 Warning: This is an experimental driver.
 Some features may not function correctly.
 
 kill: No such process
 A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsd
 Network UPS Tools upsd 2.7.3
 kill: No such process
 /sw/etc/nut/upsd.conf is world readable
 listening on 10.0.2.151 port 3493
 listening on 127.0.0.1 port 3493
 /sw/var/run/ups is world readable
 Connected to UPS [ups]: macosx-ups-ups
 /sw/etc/nut/upsd.users is world readable
 A-Mac-mini:~ admmacmini$ upsc ups

Can you try 'upsc ups@10.0.2.151' from another system on the network? This will 
rule out any firewall issues on the Mac Mini.

 battery.charge: 42
 battery.runtime: 180
 battery.voltage: 13.010
 device.mfr: (unknown)
 device.model: Back-UPS ES 550 FW:843.K2 .D USB FW:K2
 device.type: ups
 driver.name: macosx-ups
 driver.parameter.pollinterval: 2
 driver.parameter.port: auto
 driver.parameter.synchronous: no
 driver.version: 2.7.3
 driver.version.internal: 1.1
 ups.status: OL CHRG
 A-Mac-mini:~ admmacmini$ 
 
 
 Comments:
 1.- The two NAS’es performed a shutdown after UPS power loss. Main objective 
 accomplished.
 
 
 2.- The Readynas acknowledges partial connection to the UPS server, the 
 following messages can be read:
 
 a.- Frontview Health Report
 See fig ‘A
 
 b.- Frontview Log
 See fig “B

Not sure what you mean by partial connection. The original screenshot in Fig. 
A said Remote Error, Battery charge: 42%, 3 minutes / Out of Spec, and Fig B. 
said UPS is on Battery Power / Communication with UPS OK. The text in Fig. A 
is not coming directly from NUT, so it is unclear what the issue is - you may 
want to check the Synology documentation, or ask their support group. (A 
battery.runtime value of 180 (3 minutes) seems short, but that's all I can 
think of.)

 
 3.- The Synology inconsistently acknowledges connection to the UPS server , 
 the following messages can be read:
 
 a.- Control Panel UPS setup menu
 See fig “C
 
Information: Cannot connect to the network UPS server

See comments above regarding 'upsc'.

 b.- Logs Report
 See fig “D

Those log messages are also not generated by NUT.

 
 4.- Although the communication problem between the UPS server and the NAS’es 
 NUT clients has not been solved, it doesn’t affect the main function, which 
 is to shutdown the NAS’es during a power loss of the UPS.
 
 
 I’ll appreciate any help in setting up the NUT server configuration to 
 improve the communication between the clients and the server.
 
 
 Thanks,
 
 Adolfo Yanes
 
 
 

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ups does not reboot itself

[Charles Lepple]

On Jul 20, 2015, at 5:41 AM, dmanye dma...@urv.cat wrote:

 i think the problem is that the nut stop scripts does not trigger the ups 
 reboot *before* finishing and before the stop system pass to the next level. 
 the process to trigger the reboot is done in parallel with the system 
 shutdown and if /usr is gone it fails to reboot the ups.

I agree with your assessment, but I would encourage you to file a Debian bug: 
the NUT init scripts are provided by Debian. The NUT configure scripts allow 
all of the various paths to be configured at build time.

I looked up the previous issue regarding /usr on a separate partition, and it 
was due to libusb being installed to /usr/lib rather than /lib:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268723

Do you see any similar /usr dependencies on your system? I checked the output 
of 'ldd' for several NUT binaries in Debian wheezy, and could not find anything 
obvious. (I still have a few more things to do before I can upgrade that system 
to jessie.)

Here is a sample build log:

https://buildd.debian.org/status/fetch.php?pkg=nutarch=amd64ver=2.7.2-1%2Bb3stamp=1415470382

The ./configure string from that log, formatted:

./configure --build=aarch64-linux-gnu --prefix= --includedir=/usr/include \
--mandir=/usr/share/man --infodir=\${prefix}/share/info \
--sysconfdir=/etc/nut --localstatedir=/var \
--libexecdir=\${prefix}/lib/nut --srcdir=. --disable-maintainer-mode \
--disable-dependency-tracking --disable-silent-rules  \
--libdir=\${prefix}/lib/aarch64-linux-gnu --with-ssl --with-nss \
--with-cgi --with-dev --enable-static --with-statepath=/var/run/nut \
--with-altpidpath=/var/run/nut --with-drvpath=/lib/nut \
--with-cgipath=/usr/lib/cgi-bin/nut --with-htmlpath=/usr/share/nut/www \
--with-pidpath=/var/run/nut --datadir=/usr/share/nut \
--with-pkgconfig-dir=/usr/lib/aarch64-linux-gnu/pkgconfig \
--with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
--with-systemdsystemunitdir=/lib/systemd/system 

/usr/share/nut is DATADIR, which is optional and only used directly by upsd. At 
the point when the system invokes the driver shutdown command, upsd should be 
stopped.

So I suspect that there is an indirect dependency on /usr, possibly in another 
package.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ups does not reboot itself

[Charles Lepple]

On Jul 17, 2015, at 9:42 AM, dmanye dma...@urv.cat wrote:

 so i reinstalled again... but instead of using four separate partitions for 
 /, /usr, /var and /tmp, put all the stuff under an unique / partition and... 
 it works! why exactly? no idea, because if i'm not wrong, nut sensitive stuff 
 is under /lib, /sbin, /etc...

Please file a bug with Debian - I thought that multiple partitions worked?

However, I wonder if something got broken with having /var on a separate 
partition. NUT stores some files in /var/run/nut but on my wheezy setup, 
/var/run is a symlink to /run (on tmpfs) so there shouldn't be an issue. Does 
'lsof' show any references to /var that would prevent proper shutdown?

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Bug#589565: fixed upstream since v2.4.2

[Charles Lepple]

fixed nut/2.4.3-1
thanks

You can use -p pidbase to monitor multiple UPSes.

Reference:
https://github.com/networkupstools/nut/commit/d1c5f0cc448b23933d6a8a00d3da2642eed4c847


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783021: nut-server: usbhid-ups keeps losing contact with apc ups

[Charles Lepple]

tags 783021 + moreinfo
thanks

Could you please check /var/log for information from usbhid-ups around the
time that you get the UPS is unavailable notification?

If there are no log messages, you might need to run usbhid-ups in gdb to
determine why it is disconnecting. Email if you need additional details.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [Nut-upsdev] Ovislink

[Charles Lepple]

On Jul 16, 2015, at 5:09 AM, p...@paulcarmichael.org wrote:

 On 10/07/15 04:26, Charles Lepple wrote:
 On Jul 9, 2015, at 9:43 AM, p...@paulcarmichael.org wrote:
 
 Is there currently a way of implementing NUT with an Ovislink Chrome 1500 
 UPS?
 
 Not sure. There was a thread in February talking about an Ovislink Chrome 
 1000, but I don't think we ever resolved what was causing the Device busy 
 error:
 
 Is there an official way to request support for a certain UPS?

The words official and support are somewhat overloaded. As implied in the 
no warranty clause in the GPL, support means that the software attempts to 
work with a given device-- rather than support as in support contract. So 
if there is no warranty, what does that mean in practical terms? I'll try to 
explain in terms of other UPS manufacturers:

MGE Office Protection Systems (and to some degree, Eaton) have supported NUT 
driver development in the past by providing engineering resources as well as 
protocol documentation for their hardware. This corresponds to a support 
level of 5 stars (out of 5) in our Hardware Compatibility List (HCL), although 
there is a bit of a backlog of unanswered questions recently:

   http://www.networkupstools.org/stable-hcl.html

Tripp Lite put some engineering resources into testing their USB HID PDC 
hardware against NUT, which saves users from having to do that themselves. 
However, there are still a few vendor-specific HID values that we don't know 
what they mean, and there are some models that return improperly scaled values. 
(Documented in on the mailing lists and in the DDL, if you are interested.) 
Still, fairly solid for unattended shutdowns.

APC also uses the USB HID PDC standard for their hardware, but they also have 
various other open and proprietary protocols that I am not very familiar with 
(my HID UPS from 2002 predates the proprietary switch). To my knowledge, they 
have not contacted the NUT project about testing, but I would imagine they 
would reach out to the apcupsd project first.

From what I can tell as an outsider, these companies are large enough to do 
the engineering in-house for their hardware (or to lean on their contractors 
to get protocol documentation). The ATCL FOR UPS module in your UPS is 
likely an OEM part, and so if you were to ask Ovislink for protocol 
documentation, they might not have much leverage with the OEM (depending on 
how many other manufacturers would continue to buy that part without 
documentation). Publishing the documentation might also be seen as an affront 
to the company that makes the official software for your UPS, although that 
software is often free-as-in-beer these days.

As a customer, you could still ask for protocol documentation, though. I 
suspect that many UPS vendors are not familiar with the portion of their 
customer base that uses Unix-like OSes.

After that, there is a bit of software engineering to do. This is where you 
would want to do a cost-benefit analysis: if you only have one UPS from a given 
vendor, spending a lot of time on writing and debugging a driver may not be 
worthwhile. However, if you have a large deployment, or if it turns out that 
only minor changes are needed to an existing driver, it might be cheaper than 
upgrading to an already-supported UPS model.

(Usual disclaimers apply: I am speaking from my own experience, and not for my 
employer. If it looks like an opinion, it probably is-- but feel free to ask 
for clarification and facts to back up the opinions.)

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Good news

[Charles Lepple]

On Jul 15, 2015, at 12:38 PM, john hart jsa...@yahoo.com wrote:

 So, the system shut down and turned off the UPS, which is exactly what I 
 would have expected.  Also, when I 
 reconnected the AC power the system did NOT automatically start up, which 
 again is what I would have wanted,
 and hoped for.  

Good to hear!

 So, in conclusion, NUT appears to be working correctly.  Just wish I new why 
 I wasn't getting messages.  But I 
 can live with the way it is.  Thanks for all your help and a big thank you to 
 the developers.  

Not sure if you mentioned, but if you run something like echo hi | wall, does 
it broadcast a message? If not, I'd say that's a bug in wall, but you could 
configure upsmon to run a different program to send a message.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] no /etc/default/nut

[Charles Lepple]

On Jul 14, 2015, at 3:55 PM, john hart jsa...@yahoo.com wrote:

 Looking in to my previous question about no messages until clicking NUT 
 Monitor GUI,
 I found that it was recommend to make sure that /etc/default/nut  should be 
 as follows:
 
 # /etc/default/nut
 START_UPSD=yes
 START_UPSMON=yes
 However, there is no '/etc/default/nut' .   Do I need to create it ?
 
No, /etc/default/nut is an old name - prior to systemd, NUT on Debian consulted 
/etc/nut/nut.conf to determine which daemons to start. I assume that systemd is 
backwards-compatible.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] No messages

[Charles Lepple]

On Jul 14, 2015, at 8:10 PM, john hart jsa...@yahoo.com wrote:

 This is how I have the upsmon.conf set up.  The only time I get a message is 
 if the 
 NUT Monitor gui is running.  I open LXterminal, pull the wall plug, and I get 
 no messages
 in the terminal.

Hopefully someone else on the list can help with the NUT Monitor GUI part - I 
mostly run NUT on servers, so when I SSH in, the message shows up on that 
terminal.

Does the wall command work on its own?

Also, I assume that the upsmon binary is running, and if you changed 
upsmon.conf, you have restarted since that change.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] New questions

[Charles Lepple]

On Jul 14, 2015, at 12:50 PM, john hart jsa...@yahoo.com wrote:

 Here is the previous email that I sent directly to Charles Lepple.  I am now 
 sending to the correct email with cc to Charles.
 
 
 
 I am looking at, and trying to understand the rest of the conf files.  But 
 first want to ask
 about something from this message:
 [CODE]
 root@debian:/home/john# upsdrvctl start
 Network UPS Tools - UPS driver controller 2.7.2
 Network UPS Tools - Megatec/Q1 protocol USB driver 0.11 (2.7.2)
 Supported UPS detected with megatec protocol
 Vendor information unavailable
 No values provided for battery high/low voltages in ups.conf
 
 Using 'guestimation' (low: 10.40, high: 13.00)!
 Battery runtime will not be calculated (runtimecal not set)
 [CODE]
 
 I recall, from past experience with this UPS, that the nominal voltage is 
 around 13.1 .  I have 
 no idea what the low voltage should be, but 10.4 is probably okay. So, would 
 I add the following 
 in the ups.conf 
 
 [CODE]
 default.battery.voltage.high = 13.5
 default.battery.voltage.low = 10.4
 default.battery.voltage.nominal = 13.1
 [CODE]

As mentioned in the man page 
http://www.networkupstools.org/docs/man/blazer_usb.html, the nominal voltage 
is not used in the charge calculation.

Generally, nominal battery voltage is a round number, such as 12V (even 
though the actual voltage is usually higher).

The man page also defines battery.voltage.high as the Maximum battery voltage 
that is reached after about 12 to 24 hours charging, and battery.voltage.low 
as Minimum battery voltage just before the UPS automatically shuts down.

Your use of the default. prefix in ups.conf seems correct, but I would 
monitor the battery voltage to get the actual values for high and low. Plus, 
you would need to specify runtimecal, which requires some testing at different 
load levels.

All of this is for estimating the percent charge, though. The internal UPS low 
battery (LB) signal does not depend on this.

 Now, on to the  'upsmon.conf'  file.  I am a bit lost as to what all is 
 required in this file.

It depends on what you are trying to do. The configuration is a lot simpler if 
you just want to shut down when LB is asserted by the UPS - in that case you do 
not need upssched.

  Looking
 at just the first part of the example from Price, I see :
 
 [CODE]
 # /etc/ups/upsmon.conf
  MONITOR Eaton-66781@localhost 1 upsmaster sekret master
  MINSUPPLIES 1
  SHUTDOWNCMD /sbin/shutdown -h +0
  NOTIFYCMD /usr/sbin/upssched
  POLLFREQ 5
  POLLFREQALERT 5
  HOSTSYNC 15
  DEADTIME 15
  POWERDOWNFLAG /etc/killpower
 [CODE]
 
 I have modified the MONITOR line as appropriate for my system but wonder 
 about a couple
 of entries.  The referenced binary '/usr/sbin/upssched' appears to be in 
 '/sbin' not '/usr/sbin' .
 Is that the '/sbin/upssched' the correct file to use ?

Correct, that is the closest match out of dpkg --search upssched.

  Also, the '/etc/killpower'  does not appear
 anywhere in my system.  I did a 'locate killpower' and came up empty .  I now 
 see that the
 killpower is generated automatically (I think).

Correct, as mentioned in the upsmon.conf man page: upsmon creates this file 
when running in master mode when the UPS needs to be powered off. You should 
check for this file in your shutdown scripts and call upsdrvctl shutdown if it 
exists.

 Also, do I need all of the NOTIFYMSG and NOTIFYFLAG things?   I guess I am 
 looking to do
 the minimum just to get things running.  I assume I can modify things later 
 as I learn enough
 to do so correctly.  Looks like the NOTIFYMSG will send a message to a 
 terminal. Is that correct?

NOTIFYMSG is the format string for the message that gets sent out to the 
various notification systems. The part that makes it go to the terminal is the 
WALL flag on the NOTIFYFLAG line (for each type of event).

The default is WALL+SYSLOG, so if you don't want terminal messages, you would 
specify just SYSLOG for those events.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Strange

[Charles Lepple]

On Jul 14, 2015, at 3:48 PM, john hart jsa...@yahoo.com wrote:

 I tested shutdown by pulling the plug from the wall socket and observed that 
 I was not
 getting any notifications.  Then I opened the NUT Monitor GUI and immediately 
 got notified.
 
 What did I do wrong?  I think that upsmon runs at startup so why do I have to 
 open the GUI 
 in order to get messages?  

Are you sure this is not a coincidence? Sometimes there is a delay from when 
you pull the plug, and when the power failure propagates through the NUT 
toolchain.

You should see a startup message from upsmon in /var/log/syslog.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Totally beyond me

[Charles Lepple]

Please use Reply-All.

On Jul 13, 2015, at 11:00 PM, john hart jsa...@yahoo.com wrote:

 Okay.  I went through the pages from Roger Price and have set up enough, I 
 think that I 
 should at least get an 'OL' response when I run  'upsdrvctl start' .  Instead 
 I get this:
 [CODE]
 root@debian:/home/john# upsdrvctl start
 Network UPS Tools - UPS driver controller 2.7.2
 Network UPS Tools - Generic HID driver 0.38 (2.7.2)
 USB communication driver 0.32
 No matching HID UPS found
 Driver failed to start (exit status=1)
 [CODE]
 
 Is this because there is no specific driver for my UPS ?   I am totally 
 perplexed.

No, it says that the HID driver did not match your UPS. The list archives 
mention that the blazer_usb (and now nutdrv-qx) drivers work with some models 
that use WinPower, but this is not guaranteed (WinPower may have been extended 
since then). What does lsusb show?

 John 
  
 Science is organized common sense. Philosophy is organized piffle 
 -attributed to Bertrand Russel
 
 From: Charles Lepple clep...@gmail.com
 To: john hart jsa...@yahoo.com 
 Cc: nut-upsdev@lists.alioth.debian.org nut-upsdev@lists.alioth.debian.org 
 Sent: Monday, July 13, 2015 7:24 PM
 Subject: Re: [Nut-upsdev] Totally beyond me
 
 On Jul 13, 2015, at 7:59 PM, john hart jsa...@yahoo.com wrote:
 
  When I ran  upsdrvctl start  I got a message about the usbhid-ups driver.  
  It appears that NUT
  is not configured with the driver.
 
 What is the exact message?
 
 The nut package in Debian depends on both nut-client and nut-server, 
 and the USB drivers are in nut-server. (There are other packages for the less 
 common drivers.)
 
 https://packages.debian.org/jessie/i386/nut-server/filelist
 
   The instructions in the man page is all greek to me.
 
 As you may be aware, most man pages are reference material. However, in the 
 See Also section at the end of most (if not all) of the NUT man pages, it 
 mentions the NUT website. The documentation for installing the packages is 
 online, as well as in the nut-doc package: 
 http://www.networkupstools.org/docs/user-manual.chunked/ar01s05.html#Installing_packages
  
 
 There is also this document by Roger Price: http://rogerprice.org/NUT.html. 
 While it is written with openSUSE in mind, the Debian version would not be 
 that different. Configuration files are stored in /etc/nut rather than 
 /etc/ups, and you determine the Debian paths of other files by searching the 
 package database for the last part of the path, e.g.:
 
 $ dpkg --search usbhid-ups
 nut-server: /lib/nut/usbhid-ups
 nut-server: /usr/share/man/man8/usbhid-ups.8.gz
 
 
 
 
  As I said before, I am not a programmer.  I suspect that NUT might need to 
  be compiled with that driver, but I really don't know.  Any instructions 
  would have to be written so that ANYBODY could follow them, not just 
  programmers.
 
 
 Writing good software documentation involves having non-programmers work with 
 programmers to identify the parts that non-programmers shouldn't need to 
 know. It would be great if you could let us know where we should put extra 
 pointers to the documentation that we have.
 
 -- 
 Charles Lepple
 clepple@gmail
 
 
 
 
 

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Totally beyond me

[Charles Lepple]

On Jul 13, 2015, at 7:59 PM, john hart jsa...@yahoo.com wrote:

 When I ran  upsdrvctl start  I got a message about the usbhid-ups driver.  It 
 appears that NUT
 is not configured with the driver.

What is the exact message?

The nut package in Debian depends on both nut-client and nut-server, and 
the USB drivers are in nut-server. (There are other packages for the less 
common drivers.)

https://packages.debian.org/jessie/i386/nut-server/filelist

  The instructions in the man page is all greek to me.

As you may be aware, most man pages are reference material. However, in the 
See Also section at the end of most (if not all) of the NUT man pages, it 
mentions the NUT website. The documentation for installing the packages is 
online, as well as in the nut-doc package: 
http://www.networkupstools.org/docs/user-manual.chunked/ar01s05.html#Installing_packages
 

There is also this document by Roger Price: http://rogerprice.org/NUT.html. 
While it is written with openSUSE in mind, the Debian version would not be that 
different. Configuration files are stored in /etc/nut rather than /etc/ups, and 
you determine the Debian paths of other files by searching the package database 
for the last part of the path, e.g.:

$ dpkg --search usbhid-ups
nut-server: /lib/nut/usbhid-ups
nut-server: /usr/share/man/man8/usbhid-ups.8.gz

 As I said before, I am not a programmer.  I suspect that NUT might need to be 
 compiled with that driver, but I really don't know.  Any instructions would 
 have to be written so that ANYBODY could follow them, not just programmers.

Writing good software documentation involves having non-programmers work with 
programmers to identify the parts that non-programmers shouldn't need to know. 
It would be great if you could let us know where we should put extra pointers 
to the documentation that we have.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Ovislink

[Charles Lepple]

On Jul 10, 2015, at 9:02 AM, p...@paulcarmichael.org wrote:

 On 10/07/15 14:30, p...@paulcarmichael.org wrote:
 On 10/07/15 04:26, Charles Lepple wrote:
 On Jul 9, 2015, at 9:43 AM, p...@paulcarmichael.org wrote:
 
 Is there currently a way of implementing NUT with an Ovislink Chrome 1500 
 UPS?
 
 Not sure. There was a thread in February talking about an Ovislink Chrome 
 1000, but I
 don't think we ever resolved what was causing the Device busy error:
 
 http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-February/009527.html
 
 What does 'lsusb' list about this UPS?
 
 Bus 004 Device 003: ID 0001: Fry's Electronics
 
 
 
 
 And:
 
 [3.613024] usb 4-2: New USB device found, idVendor=0001, idProduct=
 [3.613029] usb 4-2: New USB device strings: Mfr=1, Product=1, 
 SerialNumber=1
 [3.613033] usb 4-2: Product: ATCL FOR UPS
 [3.613036] usb 4-2: Manufacturer: ATCL FOR UPS
 [3.613039] usb 4-2: SerialNumber: ATCL FOR UPS
 [3.618015] usb 4-2: can't set config #1, error -84
 [4.056102] usb 4-2: USB disconnect, device number 3

# define EILSEQ 84  /* Illegal byte sequence.  */

I forget what this error means in the context of USB, but if it happens a lot, 
I would be concerned about relying on this UPS. (The kernel basically gave up 
on the first attempt to configure it.)

 [4.296036] usb 4-2: new low-speed USB device number 4 using uhci_hcd
 [4.481018] usb 4-2: New USB device found, idVendor=0001, idProduct=
 [4.481024] usb 4-2: New USB device strings: Mfr=1, Product=1, 
 SerialNumber=1
 [4.481027] usb 4-2: Product: ATCL FOR UPS
 [4.481030] usb 4-2: Manufacturer: ATCL FOR UPS
 [4.481033] usb 4-2: SerialNumber: ATCL FOR UPS

hyouko mentioned the following in a thread in April:

It could work with drivers 'nutdrv_atcl_usb' (available since NUT
version 2.7.2) or with 'nutdrv_qx' (since 2.7.3).

Unfortunately, I don't think there is a way to tell which driver is needed, 
since the idVendor and idProduct numbers are the same for both hardware 
variants.
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] need help [usb_submit_urb; Linux kernel]

[Charles Lepple]

Note: the NUT list email address is nut-upsuser@ - the nut-upsuser-owner@ 
address only goes to the list owners.

On Jul 10, 2015, at 7:52 AM, taoufik abidi ing.ab...@gmail.com wrote:

 hi,
 I got stuck on this error I am researching to solve the problem but I found 
 nothing
 Here the error drivers / hid / usbhid / hid-core.c usb_submit_urb (ctrl) 
 failed
 the problem generated when I connect the UPS to the server via the USB cable.

hid-core.c is part of the Linux kernel, not NUT. You may have better luck 
asking on the linux-usb mailing list, but they will want to know the version of 
the kernel that you are using, and the exact output dmesg.

Sometimes, this error/warning is generated when the kernel requests extra 
identification from the UPS. It is most likely benign, unless there is a 
disconnection message like the following:

[3.618015] usb 4-2: can't set config #1, error -84
[4.056102] usb 4-2: USB disconnect, device number 3

If the UPS logically disconnects, it will make it harder for user-space 
software like NUT to reliably communicate with it.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] [HCL] Fideltronik INIGO Viper 1200 supported by nutdrv_qx

[Charles Lepple]

On Jul 10, 2015, at 7:42 AM, AWa. awa...@wp.pl wrote:

 Device  manufacturer: Fideltronik INIGO
 Device  name: Viper 1200
 Device type: UPS
 Bus type: USB
 WWW: http://fideltronikinigo.com/viper/viper-1200/
 
Thank you!

One question: is ups.load always 0?

Some of the NUT command comments didn't make it in, but if you have any other 
suggestions, this is the source file:

https://github.com/networkupstools/nut-ddl/blob/fdbf133ce46d40a9dd447287e72066c046b787b1/Fideltronik_INIGO/Fideltronik_INIGO__Viper_1200__nutdrv_qx__2.7.3.1__01.dev

and this is how it will be rendered in the DDL:

http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/Fideltronik_INIGO/Viper_1200.html

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Ovislink

[Charles Lepple]

On Jul 9, 2015, at 9:43 AM, p...@paulcarmichael.org wrote:

 Is there currently a way of implementing NUT with an Ovislink Chrome 1500 UPS?

Not sure. There was a thread in February talking about an Ovislink Chrome 1000, 
but I don't think we ever resolved what was causing the Device busy error:

http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-February/009527.html

What does 'lsusb' list about this UPS?

 Is this even the right place to ask such a question?

Sure, either the nut-upsdev or nut-upsuser lists will reach the developers.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] GUI on Ubuntu

[Charles Lepple]

On Jul 9, 2015, at 8:38 PM, Ken Mandelberg k...@mathcs.emory.edu wrote:

 Pardon the naive question, but I'm obviously missing something. I'm running 
 the tools in standalone mode on Ubuntu 14.04. All is working well. upsc 
 nicely shows me all the status info from command line.
 
 What I'm missing is how to get the GUI display.

There are a few options:

If you have a web server, there is a CGI script in 
http://packages.ubuntu.com/trusty/nut-cgi

The following GUI only pulls in a few Qt libraries: 
http://packages.ubuntu.com/trusty/knutclient

Or this GUI uses Python: http://packages.ubuntu.com/trusty/nut-monitor

You can also use http://packages.ubuntu.com/trusty/collectd to monitor many 
other statistics besides just those provided by NUT (processor load, 
temperature, network traffic, RAM/disk usage, etc) then use 
http://packages.ubuntu.com/trusty/kcollectd to interactively build a 
time-series graph dashboard.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] UPS integration into NUT

[Charles Lepple]

On Jul 8, 2015, at 9:17 AM, Brandt, Dieter dieter.bra...@aegps.com wrote:

 we are developer and producer of UPS devices. Now we would like to integrate 
 a small UPS via USB connection to  NAS systems. We heart from third party 
 that we need a special driver for NAS systems to work fine and to display 
 also the company name and UPS device name in the web page / software of NAS.

Each NAS vendor has their own timeline for integrating new versions of NUT into 
their software stack. Is there a specific NAS system you are interested in?

 Currently we have a UPS with USB and our own VID (0x2B2D) and PID (0x). 
 It should be compatible to NUT.

When you say it should be compatible, do you mean that the UPS implements a 
protocol that NUT already supports?

There are several USB UPS standards, including one formal standard (USB HID 
Power Device Class [PDC]) and several de facto serial-over-USB standards. I see 
one AEG listing on the current compatibility list: 
http://www.networkupstools.org/ddl/AEG_Power_Solutions/ - is it the same 
Blazer/PhoenixTec protocol? What UPS control software do you recommend to your 
customers?

If it is one of the supported protocols, often it is just a matter of adding 
your USB VID/PID to the tables in the existing NUT drivers.

 What have we to do to integrate our UPS device into NUT as well as NAS 
 devices now?  What are the steps?
 Who can help us?
 Who can do this?
 What does it cost?

The NUT project is currently supported by volunteers (with some help from 
Eaton). It costs nothing but time, although you could also hire a third-party 
contractor to help with the integration.

 What could be the timeline for integration?

With volunteers, we do not commit to timelines. An informal goal is to put 
together a formal NUT release once or twice a year, but since the source code 
is available under the terms of the GPL, your company could also provide source 
and binaries for an interim NUT release that supports your products.

 IMPORTANT NOTICE. This email and any attachments are confidential. If you are 
 not the intended recipient, you must not use or disseminate the information.


Although I realize that the footer of your email is probably a company 
standard, I feel compelled to point out that the best support in NUT comes from 
UPS protocols that can be published and freely distributed. There is plenty of 
room for innovation in the algorithms running on the UPS embedded controller, 
but to be compatible with an open-source project like NUT, the protocol cannot 
be considered confidential or proprietary. If it is impractical to publish your 
current protocol documentation, I would recommend looking at HID PDC: 
http://www.usb.org/developers/hidpage/pdcv10.pdf

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] upsd not starting sometimes (Porteus 3.1, nut 2.7.2)

[Charles Lepple]

On Jul 7, 2015, at 4:12 PM, Rob Groner rgro...@rtd.com wrote:

 It does that MOST of the time.  However, a significant part of the time, the 
 system comes up, and then doesn’t respond to loss of power.  Doing some 
 checking, I find that the reason is because upsd never started.  Capturing 
 its output, I see that it says :
  
 Fatal error: A previous upsd instance is already running!
 Either stop the previous instance first, or use the 'reload' command.

What might be happening is that the PID file is left over from the last test, 
and another process got that PID instead.

Due to history and conflicting requirements, the path selection is not as 
simple as it could be. From ./configure --help:

  --with-statepath=PATH   path for ups state files (/var/state/ups)
  --with-altpidpath=PATH  path for driver/upsd .pid files (statepath)
[...]
  --with-pidpath=PATH path for .pid files (/var/run)

You might not want to use the default for --with-altpidpath: /var/state/* is 
not generally cleared at boot time, whereas /var/run is either wiped or mounted 
on a RAM filesystem.

However, you might want the statepath protected - Debian uses the following:

$ ls -ld /var/run/nut
drwxrwx--- 2 root nut 60 Jun 24 17:13 /var/run/nut

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] New snmp-ups subdriver for Huawei

[Charles Lepple]

On Mar 31, 2015, at 3:20 AM, Arnaud Quette aquette@gmail.com wrote:

 first comment:
 it would have been great if you used the SNMP subdriver generator [1]
 It creates a dump of the whole structure pointed by the sysOID, and help to 
 track the remaining unimplemented features...
...
 [1] 
 http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers
 https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh

Arnaud, although I agree this would be useful for a later revision, I went 
ahead and merged the current patch.

 [2] http://www.networkupstools.org/ups-protocols.html

Stuart, if we add the copy of the MIB to that protocols page, do you have a 
source link?

Thanks,

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [Nut-upsuser] Nut-2.7.3 gcc-3.3.6

[Charles Lepple]

On Jul 6, 2015, at 10:32 AM, Sergey Talchuk tals1...@gmail.com wrote:

 /bin/sh ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
 -I../include  -MT nutclient.lo -MD -MP -MF $depbase.Tpo -c -o 
 nutclient.lo nutclient.cpp \
 mv -f $depbase.Tpo $depbase.Plo
 libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD 
 -MP -MF .deps/nutclient.Tpo -c nutclient.cpp  -fPIC -DPIC -o .libs/nutclient.o
 In file included from nutclient.cpp:20:
 nutclient.h:26:18: string: No such file or directory
 nutclient.h:27:18: vector: No such file or directory
 nutclient.h:28:15: map: No such file or directory
 nutclient.h:29:15: set: No such file or directory
 nutclient.h:30:21: exception: No such file or directory


This is going to be slightly harder to auto-detect. You have g++, but 
apparently it cannot find STL.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [Nut-upsuser] Nut-2.7.3 gcc-3.3.6

[Charles Lepple]

On Jul 6, 2015, at 4:40 AM, Sergey Talchuk wrote:

 Dear developers,
 
 libnutclient has been added as a C++ alternative to libupsclient in 2.7.1. As 
 a result I can't compile nut 2.7.3 with gcc-3.3.6.

What does the error message look like? Does the configure script fail when 
checking for the C++ compiler, or later on?
 There wasn't such a problem with nut-2.6.5.
 
 Is it possible to add a configuration parameter like '-without-libnutclient' 
 to provide better compatibility with older gcc versions please (since 
 libnutclient is an alternative to libupsclient)?

Certainly possible - the NUT clients (upsc, upsmon, etc.) do not use 
libnutclient. I would like the defaults to work, though - hence the previous 
question.
 Or maybe use C instead of C++ for libnutclient?

As I understand it, the purpose of libnutclient was to provide a more 
object-oriented API to NUT. I'm not sure we need two different C APIs.
 
 Unfortunately, is not that easy to upgrade glibc in an embedded system.
 

Thanks for the feedback. I agree that libnutclient should be optional, but it 
is good to confirm that it is a problem in the field.

No need to email both NUT lists - we can post results to nut-upsuser later.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] upsd: ERR ACCESS-DENIED with PowerWalker UPS

[Charles Lepple]

On Jul 3, 2015, at 8:45 AM, Sami Mäntysaari s...@sami-mantysaari.com wrote:

 /etc/hosts.allow:
 code
 # /etc/hosts.allow: list of hosts that are allowed to access the system.
 #   See the manual pages hosts_access(5) and
 hosts_options(5).
 #
 # Example:ALL: LOCAL @some_netgroup
 # ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
 #
 # If you're going to protect the portmapper use the name rpcbind for the
 # daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
 #
 
 upsd : admin at localhost : ALLOW
 /code

I started looking into this a bit more. There are a few debug statements we 
could add to the upsd source code, but to be honest, my personal preference is 
to use a kernel-level firewall and/or bind to the localhost interface, rather 
than use tcp_wrappers and hosts.allow.

By default, upsd will listen to localhost:3943 (unless you add additional 
LISTEN statements to upsd.conf, or compile in a different listening address). 
So commenting out the upsd:... line in /etc/hosts.allow should work.

If your upsd.conf had extra LISTEN statements, you will need to completely 
restart upsd (the upsd -c reload only works for basic configuration changes).

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] upsd: ERR ACCESS-DENIED with PowerWalker UPS

[Charles Lepple]

[please keep the list CC'd]

On Jul 4, 2015, at 8:09 AM, Sami Mäntysaari s...@sami-mantysaari.com wrote:

 I have reloaded it, but still the same result.
 
 Any ideas?

Not sure. Can you provide any additional details about the OS and version of 
NUT?

 snip from syslog:
 code
 Jul  4 15:04:25 HP-Opreon kernel: [66083.548290] usb 2-1: usbfs:
 USBDEVFS_CONTROL failed cmd blazer_usb rqt 33 rq 9 len 8 ret -110
 Jul  4 15:06:31 HP-Opreon blazer_usb[1143]: Signal 15: exiting
 Jul  4 15:06:31 HP-Opreon upsd[1145]: Can't connect to UPS [PowerWalker]
 (blazer_usb-PowerWalker): No such file or directory
 Jul  4 15:06:31 HP-Opreon upsmon[1078]: Poll UPS [PowerWalker@localhost]
 failed - Driver not connected
 Jul  4 15:06:31 HP-Opreon upsmon[1078]: Communications with UPS
 PowerWalker@localhost lost
 Jul  4 15:06:36 HP-Opreon upsmon[1078]: Poll UPS [PowerWalker@localhost]
 failed - Driver not connected
 Jul  4 15:06:38 HP-Opreon blazer_usb[12941]: Startup successful
 Jul  4 15:06:40 HP-Opreon upsd[1145]: Connected to UPS [PowerWalker]:
 blazer_usb-PowerWalker
 Jul  4 15:06:41 HP-Opreon upsmon[1078]: Communications with UPS
 PowerWalker@localhost established
 Jul  4 15:07:29 HP-Opreon upsd[1145]: mainloop: Interrupted system call
 Jul  4 15:07:29 HP-Opreon upsd[1145]: SIGHUP: reloading configuration
 /code
 
 3.7.2015, 17:09, Charles Lepple kirjoitti:
 On Jul 3, 2015, at 8:45 AM, Sami Mäntysaari s...@sami-mantysaari.com wrote:
 
 root@HP-Opreon:/# upscmd PowerWalker@localhost test.battery.start.deep
 Username (root): admin
 Password:
 Unexpected response from upsd: ERR ACCESS-DENIED
 Did you reload the upsd after editing the configuration files? `upsd -c 
 reload` as root.
 
 Also, check syslog for further details on the error.
 
 

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Need help [OS X]

[Charles Lepple]

On Jul 1, 2015, at 1:36 AM, Jeroen Vrijenhoek pr0ducti...@me.com wrote:

 I run os x yosemite and found out about NUT tonight. I messed around with 
 fink and macports but get stuck very soon. 

If you want to try again with Fink or MacPorts, we can certainly try to help, 
but we would definitely need more details.

 I dont know how to install anything that doesnt have a .dmg or .pkg 
 installer. 

We're working on this, but nobody has had the time to package and test it. 
https://github.com/networkupstools/nut/issues/126

 Does anyone have a step by step (written in for dummies format on how to 
 get this all to work? Just looking for a PowerChute alternative that actually 
 lets me control and monitor my UPS, not dealing with all this code stuff.

There is an old guide here: 
http://trac.networkupstools.org/projects/nut/wiki/NutOnMacOSX

I'm not sure if Yosemite supports that style of startup script, however. (This 
is part of the problem with the Fink and MacPorts packages - writing a generic 
startup script for a wide variety of OS X versions and NUT configurations is 
hard.) Also, the ACL/ACCEPT/REJECT part of that guide is out-of-date (it refers 
to a much earlier version of NUT).

This document is for openSUSE, but walks through the process in more detail, 
and has up-to-date access control configuration information: 
http://rogerprice.org/NUT.html

However, you mentioned PowerChute. As much as I would like to enlist your help 
in making NUT easier to use on OS X, I am wondering if you have an APC UPS, and 
if you might be better served by apcupsd: http://www.apcupsd.org (It has a Mac 
GUI monitor, and a DMG-based installer.) The main advantage of NUT is its 
support for non-APC hardware (now that apcupsd also has client-server 
networking), but that comes at the cost of platform-specific GUI support.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nut UPS kill inverter: offdelay ignored

[Charles Lepple]

  
   
   
   
 ups.mfr: EATON
   
   
   
 ups.model: 5E 650i
   
   
   
 ups.power.nominal: 650
   
   
   
 ups.productid:    
   
   
   
 ups.start.battery: yes
   
   
   
 ups.status: OL CHRG   
   
   
   
 ups.timer.shutdown: -1
   
   
   
 ups.vendorid: 0463
 
 
 ___
 Nut-upsuser mailing list
 Nut-upsuser@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Driver macosx-ups failing on Yosemite

[Charles Lepple]

On Jun 26, 2015, at 11:07 PM, Sundeep Mediratta smed...@gmail.com wrote:

   0.000233upsdrv_initups(): Power Sources blob:
 CFArray 0x7ffd18605480 [0x7fff7443bed0]{type = immutable, count = 1, values 
 = (
   0 : CFBasicHash 0x7ffd18605360 [0x7fff7443bed0]{type = immutable 
 dict, count = 10,
 entries =

Thanks. There is a subtle difference in the Power Sources blob: on 10.9 and 
earlier, it is a dictionary rather than an array. I will try later today to see 
if there is a better way to enumerate the power sources.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Driver macosx-ups failing on Yosemite

[Charles Lepple]

On Jun 26, 2015, at 8:35 AM, Sundeep Mediratta smed...@gmail.com wrote:

 OSX Yosemite 10.10.3
 Nut version 2.6.5
 Installed via Macports
 Device is Cyberpower CP1000AVRLCD
 Device is visible and is monitored in the OSX control panel
 
 Error-
 
 macosx-ups -DD -a cyberpower

Can you please increase the debug level to -DDD?

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] neon (was libusb_get_string: invalid argument (other usbhid-ups users, please test))

[Charles Lepple]

On Jun 12, 2015, at 10:33 AM, Greg Hersch hersch.g...@gmail.com wrote:

 thanks - this has been fun.
 
 There is one other thing I have been having trouble with - and i've tried it 
 on two archlinuxarm installs and gotten the same thing. i am not even sure if 
 its important for me. but if i try to configure and make with neon support - 
 it cant find the neon libraries. despite neon having been installed several 
 different ways (i tried pacman, as well as compiling and installign neon from 
 source)
 
 i only came across this because when i originally tried installing nut, i 
 tried doing it from the archlinux AUR. There, neon is enabled by default. and 
 i couldnt get it to build. so i ended up going to the source.

Short answer: you don't need it for usbhid-ups.

libneon is used by http://www.networkupstools.org/docs/man/netxml-ups.html to 
connect to some MGE/Eaton hardware, and by the corresponding nut-scanner module.

I'm not familiar with archlinux or AUR, but if you still have the logs, we can 
certainly take a look. It might be that NUT is looking for an older version of 
libneon, or that there is another dependency that is needed at build time.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] libusb_get_string: invalid argument (other usbhid-ups users, please test)

[Charles Lepple]

Greg,

I think I fixed it. Thanks for your patience.

https://github.com/networkupstools/nut/pull/213

Diffs: 
https://github.com/networkupstools/nut/compare/usbhid_ups_input_vs_feature

If anyone else can test usbhid-ups against their hardware before I merge this 
to master, I would appreciate it. I tried my MGE UPS on a Linux box as well, 
and it does not get interrupt events there, either.

- Charles Lepple

On Jun 11, 2015, at 9:13 AM, Charles Lepple clep...@gmail.com wrote:

 Greg,
 
 I'm still not 100% on what is going on, but after comparing the call stack 
 with a debug session here, I think I have at least identified why I wasn't 
 seeing similar behavior.
 
 There are two ways that the driver can get information from the UPS: asking 
 the UPS for a specific report (which returns one or more values), and 
 checking the interrupt pipe (which the UPS can fill with whatever has 
 changed). With the interrupt pipe results, the driver has to do an additional 
 HID table lookup to determine exactly what is being returned.
 
 It looks like the driver is processing the latter case when it throws that 
 error. I wasn't seeing that here, apparently because my MGE UPS on FreeBSD is 
 never getting anything via the interrupt pipe. (The driver falls back to the 
 polling method.)
 
 I might have some time later to reconnect that UPS to a Linux system and see 
 if the error crops up there. However, I have a suspicion that the bug is 
 triggered because the first entry in the Tripp Lite table has a conversion 
 function, and when the table lookup fails (your UPS does not have the HID 
 item corresponding to a manufacturer's part number), the lookup function 
 incorrectly returns that first table entry by default.
 
 - Charles
 
 On Jun 10, 2015, at 12:18 PM, Greg Hersch hersch.g...@gmail.com wrote:
 
 
 And here are the logs and GDB output from the reconfigured/recompiled 
 CFLAGS=-G program. You will notice i made a change to the version definition 
 of tripplite-hid.c just to make sure i am working with the updated version.
 
 On Tue, 9 Jun 2015, Charles Lepple wrote:
 
 On Jun 9, 2015, at 4:55 PM, Greg Hersch wrote:
 
 (gdb) bt
 #0  libusb_get_string (udev=0x43110, StringIdx=0, buf=0x40204 buf
 , buflen=20) at libusb.c:496
 #1  0x00015330 in HIDGetIndexString (udev=optimized out,
 Index=optimized out, buf=0x40204 buf , buflen=optimized out)
 at libhid.c:407
 #2  0x00012e18 in ups_infoval_set (item=0x3ee48 tripplite_hid2nut,
 value=optimized out) at usbhid-ups.c:1552
 #3  0x00013da8 in upsdrv_updateinfo () at usbhid-ups.c:835
 #4  0x00012410 in main (argc=optimized out, argv=optimized out) at
 main.c:708
 
 You did everything right on the backtrace, but that is puzzling.
 
 At #2, ups_infoval_set() apparently calls HIDGetIndexString(), but I don't 
 see where it does that in the code. There must be some pointers, or 
 something.
 
 The easiest thing might be to crank the debug output up a bit more (5x -D, 
 even) but since that will be a bit more output, please redirect it to a 
 file, and gzip the log before attaching it. Doesn't need to be long, just 
 enough to see one or two errors.
 
 Another idea is to recompile without optimizations, to see if that helps 
 the gdb backtrace. NUT apparently sets CFLAGS=-O if it is not set already, 
 so adding CFLAGS=-g to the ./configure line should do it.
 
 Arnaud, am I missing something obvious here? After making device.part 
 HU_STATIC, there shouldn't be any other string descriptors retrieved in 
 drivers/tripplite-hid.c.
 
 -- 
 Charles Lepple
 clepple@gmail
 
 
 
 typescript-GDB-withCFLAGchange.gztypescript_LOG_withCFLAG.gz
 


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] libusb_get_string: invalid argument

[Charles Lepple]

Greg,

I'm still not 100% on what is going on, but after comparing the call stack with 
a debug session here, I think I have at least identified why I wasn't seeing 
similar behavior.

There are two ways that the driver can get information from the UPS: asking the 
UPS for a specific report (which returns one or more values), and checking the 
interrupt pipe (which the UPS can fill with whatever has changed). With the 
interrupt pipe results, the driver has to do an additional HID table lookup to 
determine exactly what is being returned.

It looks like the driver is processing the latter case when it throws that 
error. I wasn't seeing that here, apparently because my MGE UPS on FreeBSD is 
never getting anything via the interrupt pipe. (The driver falls back to the 
polling method.)

I might have some time later to reconnect that UPS to a Linux system and see if 
the error crops up there. However, I have a suspicion that the bug is triggered 
because the first entry in the Tripp Lite table has a conversion function, and 
when the table lookup fails (your UPS does not have the HID item corresponding 
to a manufacturer's part number), the lookup function incorrectly returns that 
first table entry by default.

- Charles

On Jun 10, 2015, at 12:18 PM, Greg Hersch hersch.g...@gmail.com wrote:

 
 And here are the logs and GDB output from the reconfigured/recompiled 
 CFLAGS=-G program. You will notice i made a change to the version definition 
 of tripplite-hid.c just to make sure i am working with the updated version.
 
 On Tue, 9 Jun 2015, Charles Lepple wrote:
 
 On Jun 9, 2015, at 4:55 PM, Greg Hersch wrote:
 
 (gdb) bt
 #0  libusb_get_string (udev=0x43110, StringIdx=0, buf=0x40204 buf
 , buflen=20) at libusb.c:496
 #1  0x00015330 in HIDGetIndexString (udev=optimized out,
 Index=optimized out, buf=0x40204 buf , buflen=optimized out)
 at libhid.c:407
 #2  0x00012e18 in ups_infoval_set (item=0x3ee48 tripplite_hid2nut,
 value=optimized out) at usbhid-ups.c:1552
 #3  0x00013da8 in upsdrv_updateinfo () at usbhid-ups.c:835
 #4  0x00012410 in main (argc=optimized out, argv=optimized out) at
 main.c:708
 
 You did everything right on the backtrace, but that is puzzling.
 
 At #2, ups_infoval_set() apparently calls HIDGetIndexString(), but I don't 
 see where it does that in the code. There must be some pointers, or 
 something.
 
 The easiest thing might be to crank the debug output up a bit more (5x -D, 
 even) but since that will be a bit more output, please redirect it to a 
 file, and gzip the log before attaching it. Doesn't need to be long, just 
 enough to see one or two errors.
 
 Another idea is to recompile without optimizations, to see if that helps the 
 gdb backtrace. NUT apparently sets CFLAGS=-O if it is not set already, so 
 adding CFLAGS=-g to the ./configure line should do it.
 
 Arnaud, am I missing something obvious here? After making device.part 
 HU_STATIC, there shouldn't be any other string descriptors retrieved in 
 drivers/tripplite-hid.c.
 
 -- 
 Charles Lepple
 clepple@gmail
 
 
 
 typescript-GDB-withCFLAGchange.gztypescript_LOG_withCFLAG.gz


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] libusb_get_string: invalid argument

[Charles Lepple]

On Jun 9, 2015, at 4:55 PM, Greg Hersch wrote:

 (gdb) bt
 #0  libusb_get_string (udev=0x43110, StringIdx=0, buf=0x40204 buf
 , buflen=20) at libusb.c:496
 #1  0x00015330 in HIDGetIndexString (udev=optimized out,
 Index=optimized out, buf=0x40204 buf , buflen=optimized out)
 at libhid.c:407
 #2  0x00012e18 in ups_infoval_set (item=0x3ee48 tripplite_hid2nut,
 value=optimized out) at usbhid-ups.c:1552
 #3  0x00013da8 in upsdrv_updateinfo () at usbhid-ups.c:835
 #4  0x00012410 in main (argc=optimized out, argv=optimized out) at
 main.c:708

You did everything right on the backtrace, but that is puzzling.

At #2, ups_infoval_set() apparently calls HIDGetIndexString(), but I don't see 
where it does that in the code. There must be some pointers, or something.

The easiest thing might be to crank the debug output up a bit more (5x -D, 
even) but since that will be a bit more output, please redirect it to a file, 
and gzip the log before attaching it. Doesn't need to be long, just enough to 
see one or two errors.

Another idea is to recompile without optimizations, to see if that helps the 
gdb backtrace. NUT apparently sets CFLAGS=-O if it is not set already, so 
adding CFLAGS=-g to the ./configure line should do it.

Arnaud, am I missing something obvious here? After making device.part 
HU_STATIC, there shouldn't be any other string descriptors retrieved in 
drivers/tripplite-hid.c.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Nut and liebert ups

[Charles Lepple]

On Jun 8, 2015, at 3:10 PM, jean-marie.caous jean-marie.ca...@wanadoo.fr 
wrote:

 Hello I'm trying to manage my  liebert UPS with nut  installed on a raspberry 
 pi
 Installation of nut  is OK but thé driver doesn t works 
 Could y ou help me ?

Please provide some more details: http://www.networkupstools.org/support.html 
(under Request help)

 Best regards
 Jean-marie
 ___
 Nut-upsdev mailing list
 Nut-upsdev@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] libusb_get_string: invalid argument

[Charles Lepple]

[please use reply-all to include the list, as the list does not override the 
Reply-To header.]

On Jun 7, 2015, at 5:02 PM, Greg Hersch hersch.g...@gmail.com wrote:

 Here is the driver debug log. If I just let it run, it pops up with
 libusb_get_string_invalid argument over and over again, mixed in the
 debug output. seems to be several issues reported in the log, but they
 arent easily interpreted.

Does the libusb_get_string error occur only every 30 seconds or so?

   1.164089 Path: UPS.0015.[1].00c5, Type: Feature,
 ReportID: 0x9b, Offset: 0, Size: 16, Value: 3
   1.172696 libusb_get_report: Value too large for defined data type
   1.172928 Can't retrieve Report c2: Value too large for defined data type

The entries with hex numbers in the path aren't important - the driver tries to 
dump them once at startup, then does not refer to them again.

   3.402389 libusb_get_string: Invalid argument

I think this is from trying to retrieve the value corresponding to 
device.part - which should also only be attempted once at startup.

Try the attached patch?

Also, I would be interested in the output of lsusb -vvv -d 09ae: for your UPS.

-- 
Charles Lepple
clepple@gmail




tripplite_device_path.patch
Description: Binary data
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] iMAC does not shutdown

[Charles Lepple]

On Jun 5, 2015, at 4:36 AM, Simone Severini severini.sim...@gmail.com wrote:

 Which command should I run on /opt/local/var/run/.
 
 Current permission: drwxr-xr-x   4 root  admin  136 Jun  4 19:59 run
 


sudo chgrp _nut /opt/local/var/run
sudo chmod g+w /opt/local/var/run

(assuming that gid 502 is _nut)

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] iMAC does not shutdown

[Charles Lepple]

On Jun 4, 2015, at 10:41 AM, Simone Severini severini.sim...@gmail.com wrote:

 Thanks for your help!
 In red below.
 Cheers
 simone
 
 
 
 On Thu, Jun 4, 2015 at 2:45 PM, Charles Lepple clep...@gmail.com wrote:
 On Jun 3, 2015, at 11:45 AM, Simone Severini severini.sim...@gmail.com 
 wrote:
 
 Hi everybody!
 It has been a journey but I almost manage to make my UPS properly 
 communicate.
 
 This is the config:
 
 UPS Mecer/Mustek 2000 VA connected via USB with blazer_usb driver. 
 MASTER Raspberry PI-1 
 SLAVE Raspberry PI-2 
 SLAVE iMac OSX 10.10.3 
 
 I can get access to the UPS from any of the three devices successfully.
 
 Problems:
 1. When I launch /usr/local/ups/sbin/upsmon -c fed for testing I see Rasp-2 
 Slave going down, Rasp-1 going down, iMac completely ignoring and not 
 receiving any broadcast message on the terminal then brutally killed as the 
 UPS auto shutdown.
 
 
 If you search for 'upsmon' in /var/log/system.log on the iMac, does it appear 
 to be logged in to upsd on the master?
 Jun  4 16:34:23 Simone.Home upsmon[1081]: writepid: fopen 
 /opt/local/var/run/upsmon.pid: Permission denied
 Jun  4 16:34:24 Simone.Home upsmon[1081]: Login on UPS [ME-2000@192.168.1.69] 
 failed - got [ERR ACCESS-DENIED] 
 
 So there is one problem. How can I change permission on upsilon.pid.

The driver writes the PID file when it starts, and it drops privileges to a 
system username specified at ./configure time. So you would need to allow that 
user to write to /opt/local/var/run/ (or better yet, a NUT-specific 
subdirectory like /opt/local/var/run/nut).

 The access denied is it due to wrong username/password?
 
Yes. Bear in mind that these are NUT users defined in etc/upsd.users, not 
system usernames.

 My Mac has a local UPS, so I haven't looked into whether upsmon properly 
 reconnects after sleep.
 
 2. When I have done a live test, the Master Rasp never intercepted any FLAG 
 from UPS and UPS just died but halting just RASP-1 properly (connected via 
 cable). iMac ignored the whole procedure.
 
 You didn't mention which version of NUT you are using, but for recent 
 versions, both the blazer_usb and nutdrv_qx drivers can be configured to 
 generate their own LB signal based on runtime or percent charge. See the 
 documentation for 'ignorelb' in ups.conf.
 
 Thanks. I'm running Network UPS Tools upsmon 2.6.5-Unversioned directory 

From MacPorts?


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] iMAC does not shutdown

[Charles Lepple]

On Jun 3, 2015, at 11:45 AM, Simone Severini severini.sim...@gmail.com wrote:

 Hi everybody!
 It has been a journey but I almost manage to make my UPS properly communicate.
 
 This is the config:
 
 UPS Mecer/Mustek 2000 VA connected via USB with blazer_usb driver. 
 MASTER Raspberry PI-1 
 SLAVE Raspberry PI-2 
 SLAVE iMac OSX 10.10.3 
 
 I can get access to the UPS from any of the three devices successfully.
 
 Problems:
 1. When I launch /usr/local/ups/sbin/upsmon -c fed for testing I see Rasp-2 
 Slave going down, Rasp-1 going down, iMac completely ignoring and not 
 receiving any broadcast message on the terminal then brutally killed as the 
 UPS auto shutdown.

If you search for 'upsmon' in /var/log/system.log on the iMac, does it appear 
to be logged in to upsd on the master?

My Mac has a local UPS, so I haven't looked into whether upsmon properly 
reconnects after sleep.

 2. When I have done a live test, the Master Rasp never intercepted any FLAG 
 from UPS and UPS just died but halting just RASP-1 properly (connected via 
 cable). iMac ignored the whole procedure.

You didn't mention which version of NUT you are using, but for recent versions, 
both the blazer_usb and nutdrv_qx drivers can be configured to generate their 
own LB signal based on runtime or percent charge. See the documentation for 
'ignorelb' in ups.conf.

 3. Is there any way to intercept which type of flag message my UPS sends (log 
 files) to upsmon?

If you run upsmon with '-DDD', it will log changes to stderr. Another '-D' 
should log each poll cycle regardless of whether status has changed.

Another option is to run upslog to see the rate of discharge when the UPS is on 
battery. If the charge is falling faster than you expect, the battery may be 
dead, or the UPS may need to be recalibrated. This may help with the previous 
question.

 4. I need to halt manually a linux based NAS via SSH. What is the best way 
 (upsched or a script that parses battery.charge and takes decision 
 independently from NUT).

It depends what you want the trigger to be. You can use upssched to power down 
after a certain amount of time on battery, or when the low battery flag is 
sent. Either way, you will probably need to ensure that the UPS shuts off its 
outlets momentarily after the NAS has received the shutdown signal, especially 
when the power comes back before the UPS battery is depleted.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] upsmon and Chloride UPS

[Charles Lepple]

Please use reply-all to keep the discussion on the list. 

On May 29, 2015, at 11:55 AM, Zena Bingani roger...@gmail.com wrote:

 Hi,
 
 Yes my two 120 kva UPS ( Chloride 80 Net 120 ) are newer than the entry in 
 the compatibility list.
 
 Their windows monitoring software is Chloride MopUps P/R.
 
 It uses these protocols : RCCMD ( that is more interesting ) and MopUps ( 
 their Own protocol ). 
 
 Roger
 

That seems consistent with the brochure Ted found. 

Those protocols don't sound familiar, though. 

 
 
 
 
 2015-05-29 4:06 GMT+02:00 Charles Lepple clep...@gmail.com:
 On Thu, May 28, 2015 at 11:56 AM, Zena Bingani roger...@gmail.com wrote:
  Hi,
 
  We have 2 UPS Chloride 80 NET 120 ( a black and white one )  in our
  datacenter.
 
  Could you please tell me if it is possible to use upsmon or other free
  solution with these two UPS for shuting down servers during electrical lost
  power before battery crash
 
 Unclear. There is only one entry for Chloride in our compatibility list:
 
 http://www.networkupstools.org/stable-hcl.html?manufacturer=Chloride
 
 Do you know the name of the protocol that it uses, or the name of the
 Windows monitoring software the manufacturer recommends?
 
 --
 - Charles Lepple
 
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Charles Lepple]

On May 29, 2015, at 8:09 AM, Bastien Nocera had...@hadess.net wrote:

 It would also be useful to include a full URL to the NUT Perl script
 (to a git repository perhaps), so people don't need to check out the
 full repo to update it.

I'm not sure how useful the nut-usbinfo.pl script will be without the NUT 
repository: it scans the NUT source files for certain macros containing USB 
VIDs and PIDs.

The NUT URL listed in the file 
https://github.com/networkupstools/nut/commits/master/scripts/upower/95-upower-hid.rules
 refers to the history of a checked-in version of the output of nut-usbinfo.pl. 
The file itself is two clicks away, but if it would help, we could include that 
URL as well.

We're certainly open to suggestions as to how we can handle this better (the 
concept of checking in an auto-generated file irks me), but for the benefit of 
those of us who aren't as familiar with UPower, is there an introduction to how 
this information is used outside of NUT?

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] Random data stale error (driver intermittently does not start on Windows)

[Charles Lepple]

On May 22, 2015, at 2:34 PM, Humberto Möckel hamber...@gmail.com wrote:

 Hello, after some time monitoring my installation to see how its working, I 
 found that some ramdom times, like one or two days in a week, the driver 
 fails to start and upsmon keeps registering a data stale error on Windows' 
 event log.

The upsmon data stale error is a symptom of the driver not starting. Is there 
any other information in the event log about why the driver did not start?

Also, when you say one or two days in a week, is the driver failing during 
that time, or is the computer restarted that often?

 I've set the NUT service to delayed start to see if it was a driver 
 conflict on the system start rush, but it keeps doing it anyways.
 
 ¿How can I know what's happening? ¿Can I, in some way, config NUT to shutdown 
 the daemon and driver and restart them when data stales?
 
 Windows 8
 Using last port of NUT for Windows

None of our releases are labeled last port :-) What is the version number?

Also, if you have a Linux system that can talk to the UPS, that is probably a 
more reliable solution. At the very least, it is easier to get debugging 
information out of the driver.

 Generic Megatec protocol UPS over USB (USB-to-Serial converter built in)
 Blazer USB driver

As mentioned earlier, the blazer driver has been replaced with the nutdrv_qx 
driver, but as you may have seen, that is not in the Windows port of NUT yet. 
If you know of any Windows (mingw) developers who are interested, we would 
appreciate their help.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Question about NUT config

[Charles Lepple]

On May 21, 2015, at 10:08 AM, Tony Harris neth...@gmail.com wrote:

 Hi all,
 
 I've been doing some searching, but I am not able to find what I'm looking 
 for so I'm hoping someone here might be able to help.
 
 I have NUT installed and connected to my UPS, although not configured to do 
 anything yet.  I have 2 clusters that I need to shutdown in a specific order 
 to make sure it is all powered down correctly - I know it probably needs to 
 happen through the scripting, but I am not sure how to implement it.
 
 Cluster 1 is storage
 Cluster 2 is vm hosts
 
 The vm hosts need to be shut down first (all of the hosts at once sent a 
 shutdown command is fine) when there is at least 6 minutes left on the 
 battery backup powering the storage cluster
 
 Once the VM hosts are shut down or when the batteries are down to 3 minutes, 
 the storage cluster needs to:
 
 Properly stop the network storage - once that process completes, send a 
 shutdown to all of the storage nodes.
 
 The UPS is connected to one of the storage cluster nodes, and I am able to 
 communicate with it (so I know that part is setup properly); Should I setup 
 the other nodes as slaves or just create a command line script on the master 
 to go in sequence shutting everything down?  If I set them up as slaves, I'm 
 not sure how to setup NUT to tell specific slaves to shutdown in a specific 
 order...

The whole master/slave situation is really intended for when you are starting 
the shutdown from the UPS low battery signal, as opposed to timing thresholds. 
I haven't tried something like your setup, but you could synthesize a LB 
status using runtime (override.battery.runtime.low = 360 for your example) or 
battery charge levels via ignorelb: 
http://www.networkupstools.org/docs/man/ups.conf.html#_ups_fields

The problem is that this only provides a single timing stage. I hesitate to 
recommend adding a repeater with dummy-ups (and a separate set of ignorelb 
conditions) for the storage cluster - but if you have a way to test all of this 
on a non-production system, it's worth a try.

As for which way is easier to shut down the VMs, it will probably depend on 
your virtualization software, and how reliable the guests are. You might want 
to allow some time between a soft shutdown (simulating an ACPI power button), 
and a hard stop of the VM. I suspect that is easier to script on the host side.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Fink-devel] dbi-pm fails to compile

[Charles Lepple]

On May 4, 2015, at 8:41 AM, Kevin Horton khorto...@rogers.com wrote:

 dbi-pm5182-1:1.630-1 fails to compile on OS X 10.10.4 (beta) with:
 
 cp lib/DBI/Const/GetInfoType.pm blib/lib/DBI/Const/GetInfoType.pm
 /usr/bin/arch -x86_64 perl5.18 -x86_64 perl5.18 -Iblib/arch -Iblib/lib 
 dbilogstrip.PL dbilogstrip
 


It looks like Perl 5.18 has been dropped from 10.10:

http://pdb.finkproject.org/pdb/package.php/perl5182

-- 
Charles Lepple
clepple@gmail



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Nut-upsdev] make environment for automated testcases

[Charles Lepple]

On Apr 26, 2015, at 5:05 PM, Nick Ma. nick.mayerho...@enchant.at wrote:

 and I also tried autoreconf -i which gave me an:
 autoreconf: 'configure.ac' or 'configure.in' is required

autoreconf has to be run from the top level directory. (Not related to this 
issue, but you might want to use the autogen.sh script to catch any other 
dependencies, then add --enable-maintainer-mode to the configure parameters so 
you don't need to manually re-run the auto-tools.)

Do you have cppunit installed?
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] Fry's Electronics UPS...

[Charles Lepple]

On Apr 23, 2015, at 1:16 PM, James Hammond james_r_hamm...@hotmail.com wrote:

 I am running Ubuntu 14.04 and using NUT version 2.73 installed from apt-get 
 package.

Hmm, the version below says 2.7.1, not 2.7.3.

 Driver debug output:
 
 root@unifi:/lib/nut# ./blazer_usb -DD -a nutdev1
 Network UPS Tools - Megatec/Q1 protocol USB driver 0.10 (2.7.1)
 

To get the drivers hyouko mentioned on Ubuntu, the easiest way might be to use 
a PPA:

https://launchpad.net/~clepple/+archive/ubuntu/nut

(the strange version number in the PPA is because the packages were built from 
Git just before the official 2.7.3 tarball was released.)

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Cannot connect to a GPSER on serial, USB returning wrong data

[Charles Lepple]

On Apr 15, 2015, at 3:56 PM, Dan Craciun dany.crac...@gmail.com wrote:

 I'm using Nut 2.7.2 with riello_ser and riello_usb 0.3 (upgraded from
 0.2). Raspbian on Raspberry PI model 2015.
 
 The drivers work on SENTR models.
 
 But on several GPSER the behaviour is erratic:
 - usually, the serial driver cannot connect with the UPS. But, when left
 on for several days, I found that it suddenly connected on one machine...
 - the usb driver connects immediately, but failes to recognize the UPS
 model and the readings are wrong. The GPSER models we have are single
 phase, the drive sees them as 3-phase. The output of upsc is below.
 You'll notice a lot of 52432 values.

I CC'd Elio from Riello. Maybe they have seen this before?

I am not very familiar with the code or the protocol, but a quick look at the 
driver says that you should be able to see traces of the data by passing -DDD 
to the driver.

If you capture the logs this way, I don't think it needs to be for long - 
especially because it incorrectly detected the phases during initialization. 
Please gzip the output before emailing the list. Thanks!

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] fsd fails to notify slaves

[Charles Lepple]

On Apr 21, 2015, at 12:09 PM, dmanye dma...@urv.cat wrote:

 Apr 21 17:45:23 jessie641 upsmon[532]: FSD set on UPS smt750i@10.21.102.241 
 failed: ERR ACCESS-DENIED
 Apr 21 17:45:23 jessie641 upsmon[532]: Executing automatic power-fail shutdown
 Apr 21 17:45:23 jessie641 upsmon[532]: Auto logout and shutdown proceeding
 
 i think the problem may be the first line. do you know what can be the cause?

The MONITOR line in upsmon.conf needs to correspond to one of the user 
definitions in upsd.users, and that user needs upsmon master or upsmon 
slave permission.

Note that entries in upsd.users should probably be called roles to avoid 
confusion with system users in /etc/passwd, but that is how everything is named 
at the moment.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [libhid-discuss] OS X build

[Charles Lepple]

On Jan 14, 2015, at 6:18 AM, Edgar Fuß e...@math.uni-bonn.de wrote:

 Thanks for your quick reply.
 
 To be honest, it should be using the output of `libusb-config --libs` 
 instead (which implicitly addresses both of those points).
 Yes, probably.
 
 But once you do that, you are still fighting the OS X USB HID drivers. [...]
 You may want to check out the HIDAPI project instead [...]
 Well, to be honest, I just wanted avrdude from pkgsrc to build. It has a 
 dependency on libhid which I needed to satisfy somehow. My AVR programmer is 
 connected via a USB-RS232 dongle, not as a HID device, so I in fact don't 
 really care whether the libhid I built actually works.

Hi Edgar,

I was just looking at the avrdude source code, and it seems like their check 
for libhid is only for the Windows hid.lib (with HidD_ prefix on the symbols):

http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/configure.ac?revision=1350root=avrdudeview=markup

You may want to check and see if your version is actually linking against the 
other libhid (with hid_ symbol prefixes), and if not, let the pkgsrc people 
know.

- Charles
___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [Nut-upsdev] Roadmap to 2.7.3

[Charles Lepple]

On Apr 16, 2015, at 5:46 AM, Arnaud Quette arnaud.que...@gmail.com wrote:

 
 
 2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com:
 On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote:
 
 Hi Charles,
 
 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com:
 On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote:
 
 cool (bis), I'll check over the day to complete as per my latest merges and 
 possibly (if time permits) to publish 2.7.3.
 
 
 We should probably add a release checklist to the developer documentation, 
 but for now:
 
 the maintainer guide [1] (not distributed) is more suitable.
  
 • update version to 2.7.3 in nut/configure.ac
 
 done 
 • create a GPG-signed tag v2.7.3
 
 done  + a non-signed one (not sure it's worth!)

Yeah, I guess I meant that we should have a signed tag (v2.7.3) but it doesn't 
need -signed in the name. We only had to do that last time because there was 
already an unsigned v2.7.2 tag.

 • make dist
 
 done 
 • maybe update nut/configure.ac version to 2.7.3.1 or .5?
 
 not sure to get why .5...
 
 it's what we did last time :-)
 
 the history log is also saying so... but still failing to understand the jump 
 to .5
 anyway, it's probably too hot here (almost jumped from winter to summer) ;)
  
 My main reason was to create a different name for the tarball in the Buildbot 
 snapshot builder. After 2.7.3 is released, I plan to go back to the previous 
 way of injecting the Buildbot build number and Git hash into the tarball 
 name. (The long filenames in the Java package were preventing us from doing 
 this before.)
 
  so should I really update configure.ac to 2.7.3.1 or?

Yes, since I don't know how long it will take to reconfigure Buildbot. (I would 
also like to get it to automatically build the website - currently that needs 
to be triggered manually.)

 • push commits and tag
 
 done 
 • update nut/ and ddl/ submodules in nut-website/ (this should update the 
 website's version as well)
 
 WIP, however we should detail the process here:
 either 
 - a generic git submodule foreach git pull origin master (I did that one)
 - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and 
 more stable
I suppose we could tag the DDL repository as well.

  
 • add download hashes for tarball
 
 for hashes and sig:
 make dist-sig
 make dist-hash
 
  WIP, however access to my Gandi PaaS is underway at Eaton (forgot to request 
 that one :-/)
 so a bit more delay in the release publication
 
 I once started to create a publication script, but... hem can't find it back.
 more to resume ;)
  
 After the new version is tagged, I'll update my Ubuntu PPA.
 
 cool!
 shouldn't we add it to the Download page?
 
 It's really more of a temporary solution. Now that our primary Debian 
 maintainer is back, all of the packages will be up-to-date, right? /me ducks
 
 woow, cool, our beloved DD is back?! 8-)
 need a bit more time for that too, slowly ramping up on all (of the many) 
 dimensions ;)
 
:-)

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Roadmap to 2.7.3

[Charles Lepple]

On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote:

 Hi Charles,
 
 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com:
 On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote:
 
 cool (bis), I'll check over the day to complete as per my latest merges and 
 possibly (if time permits) to publish 2.7.3.
 
 
 We should probably add a release checklist to the developer documentation, 
 but for now:
 
 the maintainer guide [1] (not distributed) is more suitable.
  
 • update version to 2.7.3 in nut/configure.ac
 • create a GPG-signed tag v2.7.3
 • make dist
 • maybe update nut/configure.ac version to 2.7.3.1 or .5?
 
 not sure to get why .5...

it's what we did last time :-)

My main reason was to create a different name for the tarball in the Buildbot 
snapshot builder. After 2.7.3 is released, I plan to go back to the previous 
way of injecting the Buildbot build number and Git hash into the tarball name. 
(The long filenames in the Java package were preventing us from doing this 
before.)
 
 • push commits and tag
 • update nut/ and ddl/ submodules in nut-website/ (this should update the 
 website's version as well)
 • add download hashes for tarball
 
 for hashes and sig:
 make dist-sig
 make dist-hash
 
 I once started to create a publication script, but... hem can't find it back.
 more to resume ;)
  
 After the new version is tagged, I'll update my Ubuntu PPA.
 
 cool!
 shouldn't we add it to the Download page?

It's really more of a temporary solution. Now that our primary Debian 
maintainer is back, all of the packages will be up-to-date, right? /me ducks

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

[Charles Lepple]

On Apr 13, 2015, at 11:51 AM, Eric Cobb eric_c...@tripplite.com wrote:

 Here are the output log files as requested.
[...]
 If I leave the driver alone it does not eventually start.  It continues to 
 report that it is unable to connect.  I have to perform a upsdrvctl stop ; 
 upsdrvctl start (I actually just perform a init stop and start so that upsd 
 and upsmon both restart) for the driver to actually connect to the ups.
  
 I have attached an strace of the upsdrvctl start command when it is ran at 
 boot time via the init script. I'll let the experts make their assessment of 
 what is going wrong.
  
Hmm, the two logs you attached don't seem to contain the error you mentioned. 
Was the debug output from boot time?

This part of dmesg looks normal:

usb 1-1.1: new low speed USB device number 3 using ehci_hcd
usb 1-1.1: New USB device found, idVendor=09ae, idProduct=0001
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1: Product: TRIPP LITE SMART500RT1U 
usb 1-1.1: Manufacturer: Tripp Lite 
usb 1-1.1: configuration #1 chosen from 1 choice
generic-usb 0003:09AE:0001.0001: hiddev96,hidraw0: USB HID v1.10 Device [Tripp 
Lite  TRIPP LITE SMART500RT1U ] on usb-:00:16.0-1.1/input0

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] NUTDRV_ATCL_USB driver on Windows

[Charles Lepple]

On Apr 13, 2015, at 6:56 AM, Humberto Möckel hamber...@gmail.com wrote:

 Hello again! I'm the guy from the blazer_usb shutdown problem the other day. 
 Now I moved on installing the system in another work PC with another kind of 
 rebranded UPS. This ups is a double battery 1000VA UPS brand. Device 
 identifies itself as ATCL FOR USB on device description. Blazer_usb seems 
 to identify it as compatible but fails at sending commands.

Yes, unfortunately there are several broken UPS models which all report VID:PID 
0001:. The worst part is that there are now at least two with the string 
ATCL FOR UPS that are not compatible with each other.

Here is the other thread: 
http://thread.gmane.org/gmane.comp.monitoring.nut.user/8808/focus=8839

 
 Further reading took me to the NUTDRV_ATCL_USB driver that seems to be 
 specifically for my type of UPS. The problem is it isn't present in the 
 Windows port of NUT. ¿What can I do?
 

I would recommend testing on a Linux box first to determine whether the 
nutdrv_atcl_usb or the new nutdrv_qx will handle your UPS properly.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] Roadmap to 2.7.3

[Charles Lepple]

On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote:

 cool (bis), I'll check over the day to complete as per my latest merges and 
 possibly (if time permits) to publish 2.7.3.


We should probably add a release checklist to the developer documentation, but 
for now:

• update version to 2.7.3 in nut/configure.ac
• create a GPG-signed tag v2.7.3
• make dist
• maybe update nut/configure.ac version to 2.7.3.1 or .5?
• push commits and tag
• update nut/ and ddl/ submodules in nut-website/ (this should update the 
website's version as well)
• add download hashes for tarball

After the new version is tagged, I'll update my Ubuntu PPA.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] SSL only working in DEBUG mode

[Charles Lepple]

On Sun, Mar 29, 2015 at 1:50 PM, Melkor Lord melkor.l...@gmail.com wrote:
 On Thu, Mar 26, 2015 at 9:16 AM, Emilien Kia kiae@gmail.com wrote:



 After looking a bit deeply, we have another little problem. When we intend
 to start upsd with the init script (at least under debian-based distrib -
 tested on Linux Mint 17.1) when we have the NSS problem, the init script
 exit with the [OK] state even if the real deamon process does not run
 correctly.

 Perhaps we could add some tests to validate if the deamonization is OK.
 But it is a little bit out of my competencies (I am not a bash and
 linux-init-process expert).

The Ubuntu/Mint script is explicitly catching any non-zero exit codes
(with the '|| log_progress_msg (upsd failed)' portion). I wonder if
this was intentional to keep going after upgrades, the way that the
Debian+systemd scripts do?

 I'm running Ubuntu Server 14.04 in all the servers I maintain and also use
 NUT. The process is started with the following command in
 /etc/init.d/nut-server:

 start-stop-daemon -S -p $upsd_pid -x $upsd \
   -- $UPSD_OPTIONS /dev/null 21 
   log_progress_msg upsd || log_progress_msg (upsd failed)

 and obviously, a backslash is missing on the second line! (line 83 on the
 real script) So even if it fails, the next command (log_process_msg) will
 always start as if the previous command returned 0 (OK). This script always
 write upsd after starting instead of the right text, depending on the
 correct execution of $upsd!

Close, but not quite. If I tweak $upsd to point to the wrong filename
(after the -x check at the beginning), it will call the second
log_progress_msg() on my system (Mint 17). See below for the reason.

 In normal conditions, this construction shouldn't work. Try ping localhost
  for example and any shell would wait for more data before executing the
 line.

 But these lines are in a function which is called inside a switch/case
 construct and by some nesting effect and redirection to /dev/null, it works
 with the missing backslash and nothing is printed out!

The backslash is needed on the start-stop-daemon line because it is
syntactically complete as-is. The line ending in  is not complete,
so the shell continues to read to the next line.

The fact that it prints nothing is due to Ubuntu redefining
log_progress_msg() in /lib/lsb/init-functions.d/50-ubuntu-logging
(which masks the definition in  /lib/lsb/init-functions).

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] Roadmap to 2.7.3

[Charles Lepple]

On Apr 8, 2015, at 9:44 AM, Arnaud Quette arnaud.que...@gmail.com wrote:

 - #190: upsd: NSS SSL only working in debug mode = NEED TESTING before 
 merging
 Emilien has made a fix and PR  (#199: Initialize SSL after deamonize and 
 downgrade to user.)
 The user (Melkor Lord) has ack'ed the fix.
 The fix is indeed trivial but I want to ensure that there is no regression 
 for OpenSSL now (though theoretically, there shouldn't be).
 Testing welcome, while waiting to discuss with Emilien to see if he did some 
 non-reg testing too.
 Thanks a lot to Emilien for his work on this!

Just tested Emilien's fix against OpenSSL on Linux Mint 17 - no issues there.

I did notice an issue when trying to test against OpenSSL 1.0.2a on OS X:

upsd[27047]: Unknown return value from SSL_accept: Resource temporarily 
unavailable

However, this happens on master as well as the #199 branch, so it is 
technically not a regression. As with the previous bug, it fails safe, and does 
not crop up if SSL is not enabled. I'll file a bug, but I really don't want to 
tackle that until we fix the logging in the SSL code.

Merged.

 Now, there just remain the Release things, such as NEWS and the like...

NEWS and UPGRADING should be up to-to-date, except possibly for your latest 
merges. I added UPGRADING notes for the NSS SSL issue.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] APC 800VA supported by None [openmediavault]

[Charles Lepple]

On Apr 9, 2015, at 12:46 PM, Khampol khampo...@gmail.com wrote:

 I use a UPS APC 800VA. Use it with Openmediavault + Ups Nut plugin.
 My UPS is not in your list. :(

We typically do not list all of the VA ratings for APC models - the more 
important distinction is whether they are part of the Smart-UPS, Back-UPS or 
Matrix-UPS lines. For USB models, the VID:PID is also helpful to know.

 I try in Driver configuration directive
 
 driver = usbhid-ups
 port = auto
 
 I have this in the log :
 
 omvhome upsmon[21683]: Poll UPS [ups@localhost] failed - Driver not connected

Per http://www.networkupstools.org/support.html#_request_help it would be 
helpful to have the following information:

 * OS version (in this case, which version of Debian is your version of 
openmediavault based on)
 * Exact NUT version
 * exact device name and related information (manufacturing date, web pointers, 
…),
 * complete problem description, with any relevant traces, like system log 
excerpts, and driver debug output. You can obtain the latter using the 
following command, as root and after having stopped NUT:

/lib/nut/driver -DD -a upsname

-- 
Charles Lepple
clepple@gmail




___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

[Charles Lepple]

On Apr 8, 2015, at 2:04 PM, Eric Cobb eric_c...@tripplite.com wrote:Charles and list,If I leave the driver alone it does not eventually start. It continues to report that it is unable to connect. I have to perform a upsdrvctl stop ; upsdrvctl start (I actually just perform a init stop and start so that upsd and upsmon both restart) for the driver to actually connect to the ups.I have attached an strace of the upsdrvctl start command when it is ran at boot time via the init script. I'll let the experts make their assessment of what is going wrong.Here is the exact line out of the /etc/init.d/ups that i ran (I added -D and -u nut on the latest runs, I get the same issue with or without it) Let me know if you would like any further symptoms or output.start() { echo -n $"Starting UPS Driver:" echo "UPS DRIVER START"  /var/log/upslog strace -f -o /var/log/nut/strace.log /usr/sbin/upsdrvctl -D -u nut start  /var/log/upslog 21  success || failure RETVAL=$? EchoEric Cobbekc...@tripplite.comThe mailing list doesn't accept large attachments, so I attached a gzip'd copy of the log in case anyone else wants to take a look.It doesn't show timing information, or the content of the URBs, so it is hard to tell what the driver is trying to do at any given point.I recognize that it is a slight change of the experiment to remove upsdrvctl, but could you please start the driver directly in the init script with -DDD (path should be in the output of '/usr/sbin/upsdrvctl -D'), and redirect that output to a log file? (We had a reason for why upsdrvctl does not pass '-D' flags through to the driver, but the reason escapes me at the moment.)It would also be useful to have the output of dmesg (or at least the USB-related subset), in case it has additional information on why libusb_get_interrupt() is failing.
--Charles Leppleclepple@gmail




tripplite_3005_CentOS_6.6_strace.log.gz
Description: GNU Zip compressed data
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

[Charles Lepple]

On Apr 6, 2015, at 1:58 PM, Eric Cobb eric_c...@tripplite.com wrote:

 That worked out just fine. What I am currently running into are conditions 
 where I am getting the following error that I figured I would share.
  
 Error:
 libusb_get_interrupt() returned 0 instead of 8 while sending 3a 4d b2 0d 00 
 00 00 00 '.M..'
  
  
 Conditions: upsdrvctl start via Init Script at Boottime.  If I run the init 
 script after boot, I do not receive this error.

That is odd. Running the init script later should pass the same parameters to 
the driver. The only thing I can think of: other processes are interfering at 
boot time?

Does the driver eventually start, or does that error continue?

-- 
Charles Lepple
clepple@gmail



___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] nutdrv_qx hangs after send: QS

[Charles Lepple]

On Apr 6, 2015, at 8:46 AM, Richard Flint richard.fl...@gmail.com wrote:

 Unfortunately this approach isn't going to work.
 
 I've done some further research and it would appear that it is the underlying 
 ugen device and not libusb that is failing to honor the timeout.
 
 https://mail-index.netbsd.org/tech-misc/2006/03/17/.html
 
 The person above worked around this by having the device opened in non 
 blocking mode using the O_NONBLOCK flag but this required changing libusb.

Unfortunately, the ugen drivers in Solaris, NetBSD, FreeBSD, etc. are similarly 
named, but not necessarily the same code. At least with the *BSDs, you can 
inspect the code to see what has changed (and the BSD USB support has improved 
significantly across the board since 2006 when that message was posted).

OpenUSB seems to work around the blocking issue by creating a separate timeout 
thread, so I still think there is some hope there.

On the other hand, if that doesn't work, I would consider setting up another 
system dedicated to monitoring the UPS, and setup NUT on Solaris to be a client 
to the other system. Linux on x86_64 is probably the best supported OS for NUT 
and a USB UPS, but others have had success with embedded ARM and MIPS Linux 
systems. I have a Soekris net5501 running FreeBSD monitoring the USB UPS in my 
home data center in the basement, and it has been very reliable: 
http://soekris.com/products/net5501.html (also available in a rack-mount form 
factor; I have no connection to Soekris other than using their equipment)

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_qx hangs after send: QS

[Charles Lepple]

On Apr 5, 2015, at 12:26 AM, Richard Flint richard.fl...@gmail.com wrote:

 Any idea how i can get NUT to build against this libopenusb which has been 
 installed by Solaris?
...
 It might be possible to do the following:
 
 • install openusb into an alternate directory (e.g. $HOME/local)
 • set PKG_CONFIG_PATH to anything that doesn't contain the system libusb.pc
 • put $HOME/local/bin (or wherever openusb-config gets installed) at the 
 front of the $PATH, and symlink openusb-config to libusb-config
 • reconfigure NUT
 


Same sort of thing, just symlink or copy the openusb-config file such that 
NUT's configure script picks that up first (it's looking for libusb.pc first, 
then libusb-config).

If that works, we can add openusb-config into the search.

-- 
Charles Lepple
clepple@gmail



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser