Re: [Nut-upsuser] List of connected slaves

[Charles Lepple]

On Apr 13, 2018, at 8:21 AM, Larry Fahnoe  wrote:
> 
> Umm, the ups -c option "Lists each client connected on ups, one name per 
> line." according to the man page and it has worked for me for a long time.
> 
You're right, and I have no idea how I missed that the first time. The dangers 
of replying before sufficient coffee?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] List of connected slaves

[Charles Lepple]

On Apr 13, 2018, at 3:55 AM, Jon Bendtsen  wrote:
> 
> On 13/04/2018 07.56, zefanjas wrote:
>> Hi,
>> is there a command to get a list of connected slaves you can run on the
>> nutserver? I want to monitor the slaves and if their are actually
>> connected to server.
> 
> if there is no such command in NUT, then on my Debian Stretch using the lsof 
> -p command on the upsd proccess on my NUT server reveals TCP connections to 
> the clients.
> 
> I see 2 connections pr. client, probably because each client monitors 2 
> UPS's, one for each powersupply.

To be pedantic for a moment, the TCP connections to port 3493 are a superset of 
the slaves connected - the difference being tools that are monitoring but not 
logged in as a slave.

You can get a list of slaves with the following:

echo 'LIST CLIENT ups' | nc nut-server-host 3493

I thought there was an option to "upsc" for this, but I guess not. There is 
also a bug in the Python module: 
https://github.com/networkupstools/nut/issues/549
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Trying to update the official docs for nut on FreeNAS - help needed to ensure it's written correctly

[Charles Lepple]

On Mar 30, 2018, at 2:46 AM, Stilez Stilezy  wrote:
> GENERAL NUT + ETHERNET CONNECTIONS:
> 
> 1. Is "ethernet" likely to be synonymous with "snmp" for UPS network cards?

It is the most likely, but there are definitely Ethernet network cards for MGE 
models that support SNMP as well as an XML-based protocol over HTTP.

We have a similar situation with the USB-connected UPSes. The physical 
connector says nothing about the protocol (HID PDC, serial-over-USB, or other 
vendor proprietary).

> Is information update based entirely on the daemon periodically polling, or 
> does the UPS independently broadcast across the network upon a status issue, 
> for any device to receive? If the UPS can both broadcast and be polled, does 
> nut use both capabilities?

I don't see any mention of traps in the NUT documentation, so I think NUT is 
only polling the network card via SNMP.

Reference: http://networkupstools.org/docs/man/snmp-ups.html

> 2. What users/passwords provided/created/usual in nut -> Ethernet UPS?

I would phrase this a little differently to avoid confusion, in that NUT has 
the concept of users regardless of the connection to the UPS (USB, serial, 
network).

> For example, does 3rd party software need a user/pw for a nut client to 
> communicate with the daemon, and *also* the daemon need a separate user/pw to 
> login and get status info from the UPS?

Same thing here: NUT username/passwords are separate from the authentication 
used over SNMP. I would recommend using the specific SNMP terminology to avoid 
confusion.

The different versions of SNMP use various names for the authentication 
parameters. SNMPv1 uses "community" names, sent in the clear, and the read-only 
default name is "public". To have NUT command the UPS to shut itself off after 
the servers are powered down, you need a RW community name (which is usually 
treated like a password, but is also sent in the clear with SNMPv1).

SNMPv3 has authentication and privacy protocols, and the NUT configuration 
parameters (the ones that FreeNAS would need to write to ups.conf) are listed 
in the snmp-ups man page cited above.

> Is a user/pw combination needed just to get status info from the UPS, such as 
> if power is OK, or to be alerted if there is a power issue? (I'd expect so, 
> but worth checking explicitly)

No password needed to check NUT status (this is what happens when you run "upsc 
name-of-ups@name-of-server"), but a NUT username and password is needed to log 
in as a slave. Although a slave is just monitoring the master, the distinction 
is because the slaves are also capable of blocking the master shutdown sequence.

More info on NUT username/passwords: 
http://networkupstools.org/docs/man/upsd.users.html

> 3. What would be the basic config params needed to establish a data link to 
> an ethernet-connected UPS (other than user/pw) when using nut in a simple way 
> to communicate with the UPS?

I think both cases (NUT and SNMP) are covered in the answers above, but feel 
free to ask for clarification.

> FREENAS/FREEBSD SPECIFIC:
> 
> 4. Does anyone already use FreeNAS/FreeBSD with an APC UPS+AP963x network 
> card? If so, what nut config do you use - either FreeNAS GUI fields or nut 
> main config file entries that are important, would help. Are there any 
> crucial setup points you find important/necessary to get it working well, or 
> other comments on your config?

Might be worth checking the mailing list archives (search box is on 
http://networkupstools.org/support.html ) to see if anyone else has posted 
details.

> 5. The FreeNAS UPS service GUI has fields marked "monitor user+pw". Some web 
> references seem to suggest they contain the users defined externally in the 
> UPS through Powerchute/WebUI, other sources suggest they are used internally 
> by the nut client to communicate with a nut daemon. Nobody (including the 
> team itself) actually seems to be very sure which is somewhat intriguing! To 
> save dabbling in the codebase, does anyone happen to know for sure what the 
> data in these fields is used for, off the top of their head?

I suspect that if the fields do not go away if you choose a non-networked UPS, 
then it is referring to monitoring another NUT instance (you would also need 
the hostname of the NUT master system for that). You could also put in unique 
values for the user and password, and check which of the NUT configuration 
files they end up in.

(When replying, be sure to use "Reply All" to include the mailing list. Thanks!)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] problem with nut APC BackUPS RS 1500 (white)

[Charles Lepple]

On Mar 27, 2018, at 5:47 PM,  wrote:
> 
> if somebody has same problem with APC BackUPS (SmartUPS works correctly in 
> same USB)
> USE FASTEST USB that U have on board, (if you have USB 2.0 and USB 3.0 
> onboard use one 3.0 port for UPS),
> sounds like nonsense, but it works, just OMG and halelujah for linux usb 
> drivers.

According to this, your UPS is using the slowest possible USB 1.1 signaling 
rate, so success after changing from a 2.0 to a 3.0 port might just be 
coincidence:

  vvv
T:  Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#=  4 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=051d ProdID=0002 Rev=01.06
S:  Manufacturer=American Power Conversion
S:  Product=Back-UPS RS 1500 FW:8.g9 .I USB FW:g9

Also, if you are having intermittent trouble with drivers, you can use the 
maxrestart and retrydelay options: 
http://networkupstools.org/docs/man/ups.conf.html

We have had some reports of issues with VMware and USB. This can affect systems 
with APC UPSes, because the driver needs to be able to pull the model number to 
apply model-specific fixes. Versions after NUT 2.7.2 have a partial fix for 
this, but in your case, you should be able to automatically retry with the 
aforementioned options.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Best Power FE700VA?

[Charles Lepple]

On Mar 22, 2018, at 10:22 PM, David Melik  wrote:
> 
> I assume if I just go through the setup instructions on the NUT website, 
> that'll make the server automatically load this driver on boot.

If the Slackware startup scripts call "upsdrvctl start", and the UPS is listed 
in ups.conf, that should start the driver at boot.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Best Power FE700VA?

[Charles Lepple]

On Mar 20, 2018, at 6:06 PM, David Melik wrote:
> 
> On 03/19/2018 04:49 AM, Charles Lepple wrote:
>> The rc-style init systems typically want programs like the drivers to go 
>> into the background on their own (as the driver does without "-D", or when 
>> launched by "upsdrvctl start"). Other init systems like launchd or systemd 
>> will monitor the PID of the program to restart it if necessary, so they work 
>> best when the driver doesn't fork. 
> 
> Ok, around 24hrs ago I retested, but the (same) output is still on the screen 
> without it going into background to release tty/sh...

My mistake - I misinterpreted the log you posted. Without the "-D" flag, the 
driver should go into the background in a matter of seconds, usually.

Can you run the driver under strace, and see where it gets stuck?

Or did you only run it with the "-D" flag? In that case, if you are getting 
"Connection refused" from "upsc", you might need to start "upsd" by hand.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

[Charles Lepple]

On Mar 20, 2018, at 11:53 AM, Ken Olum <k...@cosmos.phy.tufts.edu> wrote:
> 
> Hi, Charles.  Are you by any chance planning to address my problems
> where NUT does not know how to schedule a shutdown of this Tripp-Lite
> UPS?  If not, could you point me in the right direction?  My best
> understanding of the situation of the moment is that the right control
> is UPS.OutletSystem.Outlet.DelayBeforeShutdown but that NUT does not
> know to use that.

Ken,

I apologize for the delay - I forgot that your segfault was on the master 
branch, not the libusb-1.0+0.1 branch. (There are some merge issues with the 
latter, and I have been fighting a losing battle trying to find time to test 
the merge with actual working hardware.)

If you pull the master branch again, you should get a tree that includes commit 
e34d94a94f0: "usbhid-ups: fix instcmd logging before fallback check", and 
rebuilding with that should fix the segfault.

I wouldn't read too much into the distinction between "outlet" and "load" and 
the UPS itself, especially for a single ganged output control.

Because of the way the code is written, it tries a bunch of different 
combinations of commands until one works, but unless someone provides debug 
logs, we don't know the exact sequence for a given UPS. That's why I am 
hesitant to push a change without doing baseline testing on known working 
hardware (and grabbing the logs).

I am attempting to gather the Ubuntu/Debian rebuild instructions here: 
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu

My only caution with removing the distro packages is that the init/systemd 
scripts from the NUT repository may not be the best match. (Then again, there 
are some open issues with Debian/Ubuntu package shutdown scripts...)

In an earlier email, you asked about matching up the NUT "usage path" to the 
Report ID. In Wireshark, find the "GET DESCRIPTOR Response" for the HID Report 
Descriptor (might say "Unknown type 34" if you have an old version like on this 
computer). Each of the NUT 32-bit hex components of the path are a combination 
of the 16-bit Usage Page and the 16-bit Usage. The dots in the path correspond 
to a Collection. The Report ID is nested in among all of the other items. Given 
this structure, and that Wireshark usually collapses all of the elements of the 
report descriptor, it is often easier to find report IDs in the usbhid-ups 
debug output.

-- 
- 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] Best Power FE700VA?

[Charles Lepple]

On Mar 19, 2018, at 4:00 AM, David Melik wrote:
> 
>> Then you can launch the driver with at least one "-D" flag:
>> 
>> /usr/libexec/nut/bestfcom -a ups -D
> 
> I thought there was a lot more to it than that, but after I ran that stuff, 
> the driver outputs.  However, /etc/rc.d/rc.ups initialization script might 
> not do anything yet (only the command you gave, also when forked, or it will 
> continue using the tty.)

The rc-style init systems typically want programs like the drivers to go into 
the background on their own (as the driver does without "-D", or when launched 
by "upsdrvctl start"). Other init systems like launchd or systemd will monitor 
the PID of the program to restart it if necessary, so they work best when the 
driver doesn't fork.
> 
> Here's output I got within the last few minutes, just wondering how to 
> complete configuration now (if this is working)...
> 
> root@darwinheim:~# Network UPS Tools - Best Ferrups/Fortress driver 0.12 
> (2.7.4)
> 
> Warning: This is an experimental driver.
> 
> Some features may not function correctly.
> 
>0.00 debug level is '1'
> 
> 8.434336  UPS Time: Saturday, July 18, 2009 - 16:01:08
> 
>   26.245736 Best Power Ferrups FE700 detected
> 
>   26.245755 Battery voltages: 13.58 nominal, 14.90 full, 11.00 low, 10.50 
> empty

This driver doesn't have any additional configuration options (or many debug 
log messages, for that matter), so the next step is to be sure that upsd has 
started, and run "upsc ups" to see all of the values.

The rest of the configuration is split between upsd (defining roles for 
monitoring) and upsmon (defining how to shut down or notify you of other 
events).


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

Re: [Nut-upsuser] Interfacing with Siemens SITOP UPS500S

[Charles Lepple]

On Mar 14, 2018, at 7:26 AM, Berge, Matthijs ten wrote:
> 
> Can anyone point me in the right direction where I should start? I already 
> found http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html, 
> but it doesn't give any specific tips for serial communication. For example, 
> which source can I use best as a starting point?
> Or does anyone recognize this protocol, and is it already compatible with an 
> existing driver?
> 
Those strings don't show up in a quick search of the driver source code, so it 
looks like you are correct in that you will need to write a new driver.

A little further down on the page you cited is the list of serial functions 
provided by NUT (Section 4.11). There are also a few contrived serial examples 
in drivers/skel.c, which we recommend copying as a starting point for a driver.

This is all assuming that your OS recognizes the FTDI chip as a USB-to-serial 
converter, and creates the appropriate character device (for instance, 
/dev/ttyUSB* on Linux). There are other USB drivers in NUT that communicate 
with non-kernel-supported USB-to-serial converters, but there are complications 
with wrestling the USB interface away from the kernel driver, so I'd advise 
against that if you can help it.

I don't recall any other drivers which parse a continuous stream of data 
without sending a query command. For a query/response example, ivtscd.c is 
relatively straightforward to understand.

Given the fixed-length strings and unambiguity of the commands, you might want 
a loop like the following:

ser_flush_in()
while(!done && !timed_out) {
ser_get_char()
// append to buffer
check for match
check for timeout
}

One thing that may be useful while waiting for hardware is to embed a test 
harness in the code. We don't have much of a standard for this, but as long as 
the code doesn't turn into spaghetti, feel free to use something like "#ifdef 
TESTING" to allow the driver to be tested offline.

If you do need to do systems-level testing before the driver is complete, you 
may be interested in the dummy-ups driver. It allows you to write a script of 
the data you expect the SITOP driver to return, and then test system shutdown 
or notifications. Obviously, this requires making a number of assumptions about 
the UPS, but it is a starting point if you want to allow some parallel 
development.

http://new.networkupstools.org/docs/man/dummy-ups.html or if the build 
infrastructure is being cranky,
http://networkupstools.org/docs/man/dummy-ups.html

Please use reply-all to include the list when responding - this list does not 
mangle the headers.
___
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 UPS wrong input voltage

[Charles Lepple]

On Mar 5, 2018, at 4:41 PM, Crispin Proctor  wrote:
> 
> The UPS functions as it should - it works when there is no power but cannot 
> test brownout or anything else.

Okay.
> 
> I ran the command you put but it fails to log anything to file. Not sure why.

I'm assuming a Bourne-compatible shell like bash or zsh - can't remember what 
it should be for csh/tcsh. Be sure there aren't spaces between "2>&1".
> 
> Here is the output though - hope there is enough here.
>  4.344452 Report[get]: (2 bytes) => 13 01
>4.344475 Path: UPS.PowerSummary.ACPresent, Type: Feature, ReportID: 
> 0x13, Offset: 0, Size: 8, Value: 1
>4.348575 Report[get]: (3 bytes) => 14 00 00
>4.348596 Path: UPS.PowerSummary.BelowRemainingCapacityLimit, Type: 
> Feature, ReportID: 0x14, Offset: 0, Size: 8, Value: 0
>4.348611 Report[buf]: (4 bytes) => 06 00 00 08
>4.348622 Path: UPS.PowerSummary.APCStatusFlag, Type: Feature, 
> ReportID: 0x06, Offset: 16, Size: 8, Value: 8
>6.329754 upsdrv_updateinfo...
> 
It's missing the report descriptor dump (part of the first few seconds) and the 
lines corresponding to voltages.
___
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 UPS wrong input voltage

[Charles Lepple]

[please use reply-all to CC the list, thanks!]

On Mar 3, 2018, at 11:42 AM, Crispin Proctor wrote:
> 
> Folks,
> 
> I've asked this question on the FreeNAS forum but there are no ideas there as 
> it looks like it's a NUT issue.
> 
> Original question: 
> https://forums.freenas.org/index.php?threads/apc-ups-reporting-wrong-input-voltage.60888/
> 
> the nut driver is reporting the wrong input voltage. I am in the UK, 230V but 
> it's reporting circa 108.
> 
> If I connect it to the laptop and run powerchute it reports the correct 
> voltage. 
> 
> AFAIK, the driver is the correct one.

The short version is that you shouldn't have to worry about the reported 
voltages affecting shutdowns, but I would still test it anyway (using a power 
strip or other switch to keep the UPS grounded while cutting the mains). There 
is a single bit coming back from the UPS for each of the OL/OB and LB states, 
and the UPS makes the decision as to when it considers its battery to be low.

device.mfr: American Power Conversion
device.model: Back-UPS XS 1400U 
device.serial: 3B1519X22971 
...
driver.version: 2.7.4
driver.version.data: APC HID 0.96
driver.version.internal: 0.41
...
input.voltage: 108.0
input.voltage.nominal: 102

^^^ Note that the nominal voltage is also off. This means it is most likely a 
scaling issue in the NUT code, but it derives those numbers from data provided 
by the UPS (which is frequently formatted incorrectly).

If you stop the UPS service on the NAS, and run the following as root, what do 
you get in the log file? (You can press Ctrl-C to kill it after 30-60 seconds - 
it will loop.)

/usr/local/libexec/nut -a ups -DDD 2>&1 | tee /tmp/APC-230V-log.txt
(^C)
gzip /tmp/APC-230V-log.txt



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

Re: [Nut-upsuser] Best Power FE700VA?

[Charles Lepple]

On Feb 19, 2018, at 3:44 PM, David Melik wrote:
> 
> Minicom listed a blank modem init string, and 'f' did nothing.

Do you have a pinout for that cable?

I forget if it is the default, but you might need to turn off the hardware and 
software flow control (minicom: Ctrl-A then letter O, "Serial port setup"). I 
would also recommend double-checking the serial port name (sometimes 
motherboards swap the headers around).

That said, if you have a maintenance window, it may be worth trying the 
bestfcom driver directly. It will set up all of the serial port parameters, and 
attempt to get an identification string.

I'm not sure if this is the recommended place to get NUT for Slackware, but 
this looks promising: https://slackbuilds.org/repository/14.2/system/nut/

For testing, you only need to do the first two steps (through "usermod -a -G 
dialout nut") after building. Then, add a section to ups.conf that looks like 
this:

[ups]
driver = bestfcom
port = /dev/ttyS0 ### replace with the actual serial port name.

Then you can launch the driver with at least one "-D" flag:

/usr/libexec/nut/bestfcom -a ups -D
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Best Power FE700VA?

[Charles Lepple]

On Feb 12, 2018, at 11:53 PM, David Melik wrote:
> 
> On 01/21/2018 05:53 AM, Charles Lepple wrote:
>> If you hook up a terminal emulator to the comms port (1200 baud, 8/N/1 
>> unless stickers and/or configuration DIP switches indicate otherwise), and 
>> type "f" , do you get a status line like one of the following?
>> 
>>
>> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/bestfcom.c#L226-L244
> 
> Of course, I got Eaton Powerware's RS-232 cable for FE700VA/etc. but don't 
> know what 'hook up a terminal emulator'... no Slackware GNU/Linux BASH 
> command 'f,' or do I run (or install/compile) a certain program to 
> enable/access that?

minicom or screen should work - after you configure the serial port settings, 
they will show everything sent by the UPS, and you can enter the "f" command in 
that session.

For initial setup, you can run "minicom -s" and it takes you right to the 
configuration screen. You will probably want to clear out some of the modem 
init strings if they are present - the UPS will likely not understand them.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] CentOS 7, systemd, nut-monitor, and failing to shut down the UPS

[Charles Lepple]

On Feb 2, 2018, at 8:07 AM, Roger Price wrote:
> 
>>  # check to see if we need to actually shutdown the UPS then do it
>>  /usr/sbin/upsmon -K >/dev/null 2>&1 && /usr/sbin/upsdrvctl shutdown
> 
> I don't have NUT + systemd + CentOS/RHEL, but I'm confused by your script. 
> "upsdrvctl" is a front end to your driver.  You are sending a command via 
> upsdrvctl and via your driver _after_ you have stopped the driver?  And it 
> works?

Roger,

"upsdrvctl shutdown" does not talk to the running driver - it starts a new copy 
with the "-k" flag to kill power.

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/upsdrvctl.c#L337
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] testing shutdown: pc not restarting; and "ups unavailable" messages

[Charles Lepple]

On Feb 1, 2018, at 10:58 AM, nut.user.u...@neverbox.com wrote:
> 
> According to the theory above, this should have caused the computer to detect 
> a power loss and turn itself back on. Instead it remained off (as I expected).

I have an older box set up this way for continuous integration, and it needs to 
see more than a few seconds of power loss for the "always turn on" BIOS setting 
to work. I forget how many different intervals I tried, but 30 seconds of off 
time is reliable for that particular box.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

[Charles Lepple]

On Jan 22, 2018, at 3:00 PM, Ken Olum  wrote:
> 
> I tested the effect of setting UPS.OutletSystem.Outlet.DelayBeforeShutdown
> using Tripp Lite's software, which appears to be as follows:
> 
Theoretically, this should be the same as running the command "upscmd 
bcpers@localhost -u  load.off.delay ".

> So if you could fix nut to use UPS.OutletSystem.Outlet.DelayBeforeShutdown
> in my case, or tell me how do it, I would appreciate that.

I still haven't had a good chunk of time to walk through the shutdown code (the 
part that handles "usbhid-ups ... -k"), but in the mean time, would you be 
interested in setting things up to rebuild the driver? (The next week is 
looking pretty ridiculous for me, so I don't anticipate being able to dust off 
my .deb build tree soon.)

My thought is that you can rebuild NUT with the same configuration options as 
the .debs, and the usbhid-ups driver should just drop in. The instructions are 
almost the same for Ubuntu as for Debian:

http://lists.alioth.debian.org/pipermail/nut-upsdev/2017-October/007341.html and

http://lists.alioth.debian.org/pipermail/nut-upsdev/2017-October/007343.html 
(omit the "git checkout" line; although we have a new-and-improved libusb 
branch, I think it's an unnecessary delta for your situation.)



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

Re: [Nut-upsuser] Best Power FE700VA?

[Charles Lepple]

On Jan 21, 2018, at 1:12 AM, David Melik <dchme...@gmail.com> wrote:
> 
> I have an excellent old Best Power FE700VA but am suprised it's unlisted.  I 
> thought Best Power ones were for critical applications, mostly for 
> POSIX-based (Unix, etc.) servers, so I want to run it on 64-bit Slackware 
> GNU/Linux.  I'm wondering why, or if it may be added in the future, or if 
> there are any other options.

My understanding was that many of the older Best Power units were downstream of 
generators, and as such, full-blown power outages of both mains and generator 
power were not expected.

That said, it might be that the "bestfcom" driver predates when we were 
actively collecting specific model names for the Hardware Compatibility List 
and the Device Dump Library. Does the manual linked below describe your model?

   http://unifiedpowerusa.com/wp-content/uploads/2017/04/ferrups-users-guide.pdf

If you hook up a terminal emulator to the comms port (1200 baud, 8/N/1 unless 
stickers and/or configuration DIP switches indicate otherwise), and type "f" 
, do you get a status line like one of the following?

   
https://github.com/networkupstools/nut/blob/v2.7.4/drivers/bestfcom.c#L226-L244

Let us know how it goes, and we can update the various compatibility lists:

   
http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/docs/latest/stable-hcl.html#footnotes

-- 
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] Eaton 5PX after battery replacement still says "replace battery" in NUT [HCL]

[Charles Lepple]

On Jan 16, 2018, at 6:07 PM, James Whitwell  wrote:
> 
> This might be a simple thing to fix, but I can’t figure it out.  We replaced 
> the battery for the first time in our Eaton 5PX a couple of weeks ago, but we 
> haven’t been able to clear the “ups.alarm: replace battery!” status.
> 
> Details of our installation are:
> OS: Debian 6
> NUT version: 2.7.4
> Installation method: from source tarball
> UPS device: Eaton 5PX2000IRT, 240V, 1800W, 2000VA, bought in October 2013
> 
We don't have a complete dump for the 5PX, but I would assume that it has at 
least one or two battery test commands, and I would recommend trying the quick 
one first. (If you can also send the output of "upscmd -l" and "upsrw", we can 
add it to our database.)

http://networkupstools.org/docs/man/upscmd.html

> 
> And here’s the output from /usr/local/nut/bin/usbhid-ups -DD -a 
> 
> I had to ^C it after a bit as it was just retrying.  Looks like a 
> communications problem with the UPS over the USB cable?  We’ve unplugged it 
> and replugged it half a dozen times before this.

The debug output looks normal - it loops like that during normal operation, but 
you won't see it without the "-D" flags.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

[Charles Lepple]

On Jan 11, 2018, at 3:14 PM, Ken Olum wrote:
> 
> So I monitored the USB port with wireshark (an interesting endeavor
> since I didn't start out with any knowledge of USB protocols).  But I
> have managed to discover that when I ask Tripp Lite's poweralert
> software to schedule a UPS shutdown, it does it by using the SET_REPORT
> function of the USB HID protocol with ReportType "Feature", ReportID 21
> (0x15), and 3 bytes of data which are 0x15 followed by the number of
> seconds to wait before shutting down in two bytes, LSB first.
> 
> Below I include wireshark packet dissections for two such commands.  The
> difference is in the "data fragment".  In the first case it is 150500,
> representing a shutdown in 5 seconds, and the second 153701,
> representing a shutdown in 311 = 0x0137 seconds.
> 
> Is this helpful?

Definitely. (The trick will be adding support for this without breaking other 
models.)

Here's the debug output describing ReportID 0x15:

  0.070916  Path: UPS.OutletSystem.Outlet.DelayBeforeShutdown, Type: 
Feature, ReportID: 0x15, Offset: 0, Size: 16, Value: 65535

(In case you are interested, this mapping between the "Path" and the report ID 
is in the HID Report Descriptor which should be early in the Wireshark capture.)

Other HID UPS models tend to provide both DelayBeforeShutdown and 
DelayBeforeStartup, so I will need to reacquaint myself with how that is 
handled in the code, since your UPS only seems to need one of those (and this 
command is an exception to the usual 1:1 mapping of HID Usage IDs to NUT 
variables). That might not happen until the weekend.

For completeness, would you mind sending the output of "upsrw" and "upscmd -l"? 
I would like to verify some of the other mappings, and also publish that here: 
http://networkupstools.org/ddl/Tripp_Lite/index.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

[Charles Lepple]

On Dec 20, 2017, at 10:32 AM, Ken Olum wrote:
> 
>   0.090564find_nut_info: unknown info type: load.on.delay
>   0.090577find_nut_info: unknown info type: load.on.delay
>   0.090585Initiating UPS shutdown
>   0.090593upsdrv_shutdown...
>   0.090601instcmd(shutdown.return, [NULL])
>   0.090614find_nut_info: unknown info type: shutdown.return
>   0.090624instcmd(load.on.delay, [NULL])
>   0.090633find_nut_info: unknown info type: load.on.delay
>   0.090641instcmd: info element unavailable load.on.delay
> 
>   0.090649instcmd(shutdown.reboot, [NULL])
>   0.091107upsdrv_cleanup...

Sorry, I missed this part from the "-k" output. This at least seems to explain 
the 10-second delay. Here's what I think is going on:

NUT looks up the "shutdown.return" ("Turn off the load and return when power is 
back") command, and finds nothing that matches your UPS. Then it tries 
"load.on.delay" - same problem. It then finds the path for "shutdown.reboot", 
which is most likely mapped to this line: 
https://github.com/networkupstools/nut/blob/v2.7.2/drivers/tripplite-hid.c#L394 
(IIRC it's the first match, otherwise it would be 
https://github.com/networkupstools/nut/blob/v2.7.2/drivers/tripplite-hid.c#L397 
)

That sends a value of 10 (likely corresponding to the 10-second delay) to 
UPS.OutletSystem.Outlet.DelayBeforeReboot

The fact that there is not a "UPS.OutletSystem.Outlet.DelayBeforeStartup" or 
"UPS.OutletSystem.Outlet.TLDelayBeforeStartup" in the debug output for your UPS 
means that the "wait for power" functionality is probably hidden behind 
something else, possibly another vendor-specific item (see, for instance, 
"UPS.OutletSystem.Outlet.00bc" and the other * names after 
"*.DelayBeforeShutdown").

To be honest, if you can set up the Tripp-Lite software somewhere temporarily 
(possibly an older laptop, or maybe even in a VM - though VMs have their own 
issues), that might be the quickest way to get the behavior you are looking 
for. You could set absurdly large shutdown timers, and fire up usbhid-ups in 
debug mode to watch the counters. I think that would be safer than trying to 
set various vendor-specific items to random values.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Debian 9.3 nut-client.service reports itself as nut-monitor.service

[Charles Lepple]

On Dec 28, 2017, at 6:35 AM, Roger Price  wrote:
> 
> It would be clearer to users if the service unit file was also called
> 
> /lib/systemd/service/nut-monitor.service
> 
>From what I can tell, the "nut-client.service" name comes from this 
>Debian-specific symlink:

https://sources.debian.org/src/nut/2.7.4-5.1/debian/rules/#L104
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

[Charles Lepple]

[please use reply-all to post to the list - the mailing list does not add a 
reply-to header. thanks!]

On Dec 18, 2017, at 11:37 AM, Ken Olum wrote:
> 
> I have a Tripp-Lite BCPERS450, connected to a system running Ubuntu
> 16.04.3 LTS and NUT 2.7.2-4ubuntu1.2.  I had to make my own
> /lib/systemd/system-shutdown/nutshutdown, but now everything is working
> except for powering on and off the UPS.  Regardless of the settings of
> offdelay and ondelay in upsconf, and regardless of whether the AC power
> is on, when I say "upsdrvctl shutdown" the UPS turns off the power to
> the system instantly and turns it back on in ten seconds.

Thanks for the specific version info and detailed logs.

This may sound like an apples-to-oranges comparison, but we did uncover an 
issue with CyberPower UPSes where the delay values needed to be greater than or 
equal to 60 (seconds), since they were being rounded down to integer numbers of 
minutes internally:

https://github.com/networkupstools/nut/issues/432

What was the largest delay you tried?

> ups.timer.reboot: 65535
> ups.timer.shutdown: 65535
> 

I can't test this on either one of my Tripp-Lite units (one is too old, and the 
other has the ill-fated 3016 protocol USB controller that can't stay on the bus 
long enough to do anything useful), but I seem to remember that these values 
should change to e.g. -60 if you set the delay to 60, and then they should 
begin counting down after the shutdown command is sent. It has been a while 
since I messed with that code, though.

What log messages do you get with "/lib/nut/usbhid-ups -DD -a bcpers450 -k"? 
(NOTE this will also tell the UPS to shut down immediately - it's the command 
that upsdrvctl runs, but with more debugging.)

For future reference, was this UPS manufactured recently? The NUT source code 
mentions that the TLCustom prefix is 0x0010, but the HID descriptor dump 
shows a few items under "UPS.0015". Hopefully the delays haven't been moved 
to those values, since we don't have good information on the corresponding 
names.

Also, it may be worthwhile to reach out to Tripp Lite support. A few years ago, 
the NUT project got a large spreadsheet of testing results (mostly upsc output, 
rather than full end-to-end) from connecting many of their their USB UPS models 
to NUT from one of their sales offices. Interestingly, the following models 
have the same USB product ID as your UPS, and the Smart1000LCD was on that list:

 * http://networkupstools.org/ddl/Tripp_Lite/AVR900U.html
 * http://networkupstools.org/ddl/Tripp_Lite/G1010USB.html
 * http://networkupstools.org/ddl/Tripp_Lite/SMART1000LCD.html

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


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

Re: [Nut-upsuser] Debian 9 : Can't open /etc/nut/upsd.users: Permission denied

[Charles Lepple]

On Dec 10, 2017, at 6:10 AM, Roger Price  wrote:
> 
> The nut:nut ownership seems to me to be more natural, and the root:nut 
> ownership looks like a bug in the Debian package.

I would argue it slightly differently: upsd has no need to write to upsd.users 
(or change permissions on that file), so root:nut makes sense to me, but with 
group-read permissions enabled.

Either way, the default permissions are under the packager's control, so I 
would recommend that you file a bug with Debian: 
https://www.debian.org/Bugs/Reporting (feel free to mention the bug number here)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] SNMPv3 fails when more than one UPS is configured in ups.conf

[Charles Lepple]

On Dec 4, 2017, at 2:43 PM, Lee Damon  wrote:
> 
> I have it "working" with the following settings changes from the default
> in the RPM. By "working" I mean it starts after reboot and after issuing
> 'sudo systemctl restart nut-driver' but, as expected, it takes quite a
> while to finish startup.

Yeah, this doesn't sound ideal.

How close do the EPEL RPM's systemd configuration files look to the ones in the 
NUT tree? e.g. 
https://github.com/networkupstools/nut/blob/v2.7.2/scripts/systemd/nut-driver.service.in

If the EPEL RPMs have a bug tracker, it might be worth pinging them about it. 
The "StopWhenUnneeded=no" part is odd, in my mind, although the idea is for 
"upsdrvctl start" to start the drivers, let them fork, then exit. (Were you 
running "upsdrvctl -D start" at the command line or under systemd? I would not 
expect the latter to work without modifications.)

There is also a proposal for reworking the NUT driver startup under systemd, in 
case problems crop up later, and you want to revisit this:

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

As I understand it, the drivers would each get their own systemd unit, so that 
might be easier for isolating failures.



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

Re: [Nut-upsuser] SNMPv3 fails when more than one UPS is configured in ups.conf

[Charles Lepple]

On Nov 30, 2017, at 6:31 PM, Lee Damon  wrote:
> 
> SNMPv3 works fine when I have any one of the three configured in
> ups.conf while the other two are configured with SNMPv1. It doesn't
> matter which _one_ UPS is configured for SNMPv3 in ups.conf, they all
> work individually (see below example).
> 
> However, if I configure any two or all three of them to use SNMPv3 then
> on startup upsdrvctl complains about "unhandled ASN 0x81 received from
> .1.3.6.1.4.1.318.1.1.1.9.3.3.1.7.1.1.3" and fails to start.
> 
Thanks for the detailed bug report. It's an interesting failure mode.

I created an issue on GitHub with a link back to the mail archive because the 
developers who are most involved with SNMP are more likely to see it there (and 
so it doesn't get lost; we're attempting to put together a new release at the 
moment): https://github.com/networkupstools/nut/issues/508 (feel free to reply 
to the list, or post there).

I suspect that the message you are seeing is from here in the snmp-ups driver:

   https://github.com/networkupstools/nut/blob/v2.7.2/drivers/snmp-ups.c#L706

(There are two other "unhandled ASN ..." messages, but due to the use of 
upsdebugx(), they probably wouldn't show up the way that upsdrvctl starts the 
drivers.)

To get more context on what is happening before this error, you can start the 
driver directly with a few "-D" flags. The command line can be found from a 
running driver, or you can pass "-D" to upsdrvctl itself (I think; there have 
been some changes to that code over the years) and it will show the whole 
command line.

Another option (which papers over the problem, but may help in the near term) 
is to see if this is just a startup issue. You can specify one UPS with 
"upsdrvctl start ups1", and then see if the other drivers still start if you 
wait until the first driver has completed its SNMPv3 handshake. You can 
automate this a bit with the "maxretry" and "retrydelay" options in ups.conf: 
http://networkupstools.org/docs/man/ups.conf.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Have any FreeBSD users tried the new libusb-1.0 branch?

[Charles Lepple]

> 
>> # nut-scanner
>> Cannot load USB library (/usr/lib64/libusb-1.0.so.0.1.0) : 
>> /usr/lib64/libusb-1.0.so.0.1.0: undefined symbol: usb_get_string_simple. USB 
>> search disabled.
> 
> Although I suspect that the USB portion of nut-scanner could probably be 
> replaced with a small shell script that parses the output of lsusb, this 
> shouldn't be too hard to fix. Logged, in case it is not as simple as it 
> looks: https://github.com/networkupstools/nut/issues/499

I don't currently have a physical Fedora test system, but can you see if this 
works at least as well as it did prior to the libusb-1.0 branch? (I have a few 
kludges in my tree to make this work on a Raspberry Pi, but they are not ready 
to push.)

https://github.com/networkupstools/nut/commit/170c0ee390c7ecdfb7d86d3b8ee6ca4240f72c2a
 or checkout branch fix_usb_scan_issue_499 from that Git repo.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Have any FreeBSD users tried the new libusb-1.0 branch?

[Charles Lepple]

On Nov 26, 2017, at 3:15 PM, Sam Varshavchik wrote:
> 
> Charles Lepple writes:
> 
>> still looking for volunteers to test the libusb-1.0 code on FreeBSD and 
>> other systems.
> 
> On Fedora 27, running commit 2999c95f0:

Thanks for checking this. I should have been more clear in the second email in 
the thread, but commit 2999c95f0 is on the original "libusb-1.0" branch, which 
had a bunch of half-duplicated commits and other junk on it. There is now a 
"libusb-1.0+0.1" branch with all of that cleaned up. Originally just at 
https://github.com/zykh/nut.git, it is now on 
https://github.com/networkupstools/nut with a few additions (currently at 
revision 80bc452cc).

> 
> # nut-scanner
> Cannot load USB library (/usr/lib64/libusb-1.0.so.0.1.0) : 
> /usr/lib64/libusb-1.0.so.0.1.0: undefined symbol: usb_get_string_simple. USB 
> search disabled.

Although I suspect that the USB portion of nut-scanner could probably be 
replaced with a small shell script that parses the output of lsusb, this 
shouldn't be too hard to fix. Logged, in case it is not as simple as it looks: 
https://github.com/networkupstools/nut/issues/499

> 
> There's also a bug in the configure script on 64 bit Fedora. The configure 
> script sets systemdsystemshutdowndir to /usr/lib64/systemd/systemd-shutdown 
> which misses the mark, a little bit. The fix:

Agreed - looks like we will have that after a merge from master:

https://github.com/networkupstools/nut/pull/496/commits/491d088af70a67b6ed1d2a6a6711d83be71dd911
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How to disable hal-addon-hid-ups

[Charles Lepple]

On Wed, Nov 16, 2016 at 11:28 PM, Stuart Gathman wrote:
> On 11/13/2016 10:08 AM, Charles Lepple wrote:
>>> Here is one of recipes I googled:
>>> https://github.com/sdgathman/trippfix/blob/master/halpolicy.fdi
>> What if you convert the USB ID numbers to decimal?
>>
>> 
>>   
>>
>> Ref: https://ubuntuforums.org/showthread.php?t=1253856
> Oooh.  I'll try that.

Stuart,

I was looking through old NUT issues, and ran across this:

https://github.com/networkupstools/nut/issues/340

Are you still using Centos 6.8, and if so, does converting the
vendor_id/product_id to decimal work to block HAL?

-- 
- 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] Have any FreeBSD users tried the new libusb-1.0 branch?

[Charles Lepple]

On Nov 22, 2017, at 7:39 PM, Charles Lepple <clep...@gmail.com> wrote:
> 
> The new branch will only attach to the device if I pass the '-u root' flag to 
> usbhid-ups.

fixed: https://github.com/networkupstools/nut/compare/dfd514e...80bc452

still looking for volunteers to test the libusb-1.0 code on FreeBSD and other 
systems.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Have any FreeBSD users tried the new libusb-1.0 branch?

[Charles Lepple]

Hi all,

I am doing some final testing of the libusb-1.0 branch (specifically 
https://github.com/zykh/nut.git branch libusb-1.0+0.1 @ dfd514e7), and I am 
running across a regression in usbhid-ups relative to the previous libusb-0.1 
code running on FreeBSD. Basically, the master (2.7.4+; c703fa75) code was able 
to start running as root, drop privileges (usually to uucp, the default for the 
ports tree), and then attach to the USB device. The new branch will only attach 
to the device if I pass the '-u root' flag to usbhid-ups.

So far, I have tested this on FreeBSD 11.0-RELEASE and 11.1-RELEASE. The error 
I get seems to be around where it claims the device.

Are there any FreeBSD users who have dealt with these sorts of USB issues 
before, or are willing to help debug this? At this point, I am not sure if I am 
just seeing weird build issues, and both test machines are kind of slow.

-- 

Thanks,
- 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] Cyberpower PR2200ELCDRT2U [HCL]

[Charles Lepple]

On Nov 10, 2017, at 5:31 PM, Christoph Lampl  wrote:
> 
> Dear Charles,
> 
> thanks for your quick answer and your information! I didn't know there is a 
> difference in the PR-series between old and new. So thanks for this valuable 
> information!

Just a lucky guess :-) We tend not to know about changes like this until 
someone reports an issue.
> 
> usbconfig dump_device_desc shows:
> 
> ugen0.2:  at usbus0, cfg=0 md=HOST spd=LOW 
> (1.5Mbps) pwr=ON (50mA)   
> 
>  bLength = 0x0012 
>  
>  bDescriptorType = 0x0001 
>  
>  bcdUSB = 0x0110  
>  
>  bDeviceClass = 0x 
>  
>  bDeviceSubClass = 0x 
>  
>  bDeviceProtocol = 0x 
>  
>  bMaxPacketSize0 = 0x0008 
>  
>  idVendor = 0x0764
>  
>  idProduct = 0x0601   
>  
>  bcdDevice = 0x0200   
>  
>  iManufacturer = 0x0003   
>  
>  iProduct = 0x0001  
>  
>  iSerialNumber = 0x
>  
>  bNumConfigurations = 0x0001
> 
> Right now, I selected " Cyber Power Systems ups 3 OR2200LCDRM2U USB 
> (usbhid-ups)" in the dropdown menu, in order to shift away from 
> powerpanel-driver to usbhid-driver.

Thanks, good to know. PR6000LCDRTXL5U would probably also work.

> However, when choosing this driver, freenas shows this log:
> 
> Nov 10 23:04:45 storageunit upsd[17599]: mainloop: Interrupted system call
> Nov 10 23:04:45 storageunit upsmon[17621]: upsmon parent: read
> 
> I guess, interrupted system call shows up, because FreeNAS is already trying 
> to "read" a response from the battery from the previous attempt, however is 
> still waiting? So, basically, the output is "upsmon parent: read"... however, 
> this is all and there is no further output. But I think, there should be 
> further output, shouldn't it? (some sort like "link established 
> successfully").

Those are likely from the previous instances of upsd and upsmon - they look 
like the "errors" you get from sending SIGTERM to them.

The UPS drivers send their "connected" message to stdout, and they are not 
consistent about that, either. Pretty sure we have that logged as a bug.

Do you know the lowest syslog level FreeNAS logs by default? (debug, info, 
notice, etc. - see 
https://www.freebsd.org/cgi/man.cgi?query=syslog=3=0 for the 
list, and it might be in /etc/syslog.conf)

> Meanwhile I tried connecting the UPS PR2200ELCDRT2U to pfSense system. 
> However, I'm receiving the same error there, too.
> 
> Nov 10 13:59:45   upsmon   49323   Poll UPS 
> [PR2200ELCDRT2U] failed - Driver not connected
> Nov 10 13:59:40   upsmon   49323   UPS PR2200ELCDRT2U 
> is unavailable
> Nov 10 13:59:40   upsmon   49323   Poll UPS 
> [PR2200ELCDRT2U] failed - Driver not connected
> Nov 10 13:59:35   upsmon   49323   Communications 
> with UPS PR2200ELCDRT2U lost
> Nov 10 13:59:35   upsmon   49323   Poll UPS 
> [PR2200ELCDRT2U] failed - Driver not connected
> Nov 10 13:59:35   upsd  49831   User monuser@127.0.0.1 logged 
> into UPS [PR2200ELCDRT2U]
> Nov 10 13:59:33   upsd  49831   Startup successful
> Nov 10 13:59:33   upsd  49649   Can't connect to UPS 
> [PR2200ELCDRT2U] (usbhid-ups-PR2200ELCDRT2U): No such file or directory
> 
> (newest entry is at top)

Again, the upsd and upsmon messages are secondary results from the driver not 
starting. Are there any log messages that reference usbhid-ups (the process 
name for your driver)?
> 
> So, back to FreeNAS, after selecting usbhid as driver, I ran following 
> commands from shell:
> 
> - upsc PR2200ELCDRT2U@localhost
> - upscmd -l PR2200ELCDRT2U
> - upsrw 

Re: [Nut-upsuser] Cyberpower model numbers in the HCL

[Charles Lepple]

On Nov 12, 2017, at 12:09 PM, Sam Varshavchik wrote:
> 
> http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/docs/latest//ddl/Cyber_Power_Systems/CP1500EPFCLCD.html
> 
> So, you have the entry for the CP1500EPFCLCD already. I'll grab the 
> CP1500PFCLCD model, and hope for the best.

I copied and pasted the wrong URL - the CP1500PFCLCD (non-E) model is here as 
well:

http://new.networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.html

Given the frequency with which UPS vendors redesign the innards of the smaller 
models, let us know whether or not the CP1500PFCLCD works. A positive result is 
still useful to know that things haven't changed much since previous reports.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Cyberpower model numbers in the HCL

[Charles Lepple]

On Nov 12, 2017, at 10:08 AM, Sam Varshavchik wrote:
> 
> The HCL has an entry for a Cyberpower model CP1500AVRLCD. Not listed is the 
> CP1500PFCLCD model, a newer, premium version of the unit; but the HCL does 
> have an entry for the CP1000PFCLCD model.
> 
> Pretty sure that the CP1500PFCLCD will work; but figure I ask if anyone knows 
> for sure.
> 

We have a bit of a backlog of HCL/DDL entries that haven't been pushed to the 
main website, including this one:

http://new.networkupstools.org/ddl/Cyber_Power_Systems/CP1000PFCLCD.html

Also, for others who might stumble across this, we have not yet seen any 
software differences between the PFCLCD and EPFCLCD (European) variants.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Cyberpower PR2200ELCDRT2U

[Charles Lepple]

[please use reply-all to include the list. thanks!]

> On Nov 9, 2017, at 9:19 PM, Christoph Lampl  wrote:
> 
> Hey guys, :)
>  
> recently, I installed Cyberpower PR2200ELCDRT2U, however, I have not managed 
> to get this UPS working with FreeNAS 11, yet.
>  
> According to compatibility list, PR2200 should work fine, when using 
> powerpanel driver:
> http://networkupstools.org/ddl/Cyber_Power_Systems/
> http://networkupstools.org/ddl/Cyber_Power_Systems/PR2200.html

Looking at the PR6000LCD... entry, it looks like PR*LCD models might be 
different than the older PR* ones.

What do you get from "sudo usbconfig dump_device_desc"? (You can trim any 
non-UPS data - I'm mostly interested in idVendor and idProduct. Also, if you 
don't want to share the full serial number, it would be good to know how many 
characters there are.)

I suspect this UPS will work with the usbhid-ups driver, or if not, it can be 
made to work with minor NUT configuration changes. I forget how you choose a 
"generic" USB connection in FreeNAS - maybe someone else can chime in on that 
point?

> However, when trying to establish a connection between battery and FreeNAS 
> Server, either using usb cable or serial cable, I receive the same error 
> messages in the console of FreeNAS:
>  
> Nov 10 03:01:37 storageunit root: /usr/local/etc/rc.d/nut: WARNING: failed 
> precmd routine for nut

^ This command probably indicates that the NUT driver failed to start, so the 
NUT upsd process probably will not start, either.

> Nov 10 03:01:37 storageunit upsmon[8817]: UPS [PR2200ELCDRT2U]: connect 
> failed: Connection failure: Connection refused
> Nov 10 03:01:37 storageunit upsmon[8817]: Communications with UPS 
> PR2200ELCDRT2U lost

^ upsmon "Connection refused" errors (on FreeNAS, or other connections to 
localhost) are usually a consequence of upsd not starting, so this should 
resolve itself once you can get the driver running.

> I tried connecting to PR2200 using a Laptop with preinstalled Cyberpower 
> Personal Edition. Everything is working fine at this point and the software 
> displays battery details correctly! However, as soon as I try to establish a 
> connection between FreeNAS and Cyberpower PR2200, I receive these error 
> messages. I spent many hours in reconfiguring and trying new/different ports, 
> however, it looks like I’m going in the wrong direction, because I can’t get 
> this battery communicating with FreeNAS correctly.

I doubt this will be an issue here, but I would recommend choosing the port you 
want to ultimately use (serial, USB, network) and making sure that it still 
works with Cyberpower's software before switching to NUT. Some older UPSes (and 
likely not even from Cyberpower) did not deal well with switching between 
ports, and required a power cycle to switch.

> OS Name and Version: FreeNAS 11.0U4, no custom modifications
> Cyberpower PR2200 Firmware: 4.520
> RMCARD205 Firmware: 1.0.9

for reference, I think this version of FreeNAS includes NUT 2.7.4.

If this works with a different driver, would you please send a snapshot of the 
information you get from upsc, upscmd and upsrw as mentioned here? 
http://networkupstools.org/stable-hcl.html#footnotes

Thanks!


___
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-server service fails to start at boot

[Charles Lepple]

On Oct 22, 2017, at 2:39 AM, Daniel Shields  wrote:
> 
> Oct 22 05:57:37 nut.tklapp.com upsd[341]: not listening on 192.168.213.189 
> port 3493
> Oct 22 05:57:37 nut.tklapp.com upsd[341]: not listening on 192.168.213.189 
> port 3493
> Oct 22 05:57:37 nut.tklapp.com upsd[341]: listening on 127.0.0.1 port 3493
> Oct 22 05:57:37 nut.tklapp.com upsd[341]: no listening interface available
> 
I think you're hitting this race condition: 
https://github.com/networkupstools/nut/issues/393

Using the LISTEN directive to selectively ignore certain interfaces worked a 
lot better when 1) we didn't have to worry about interfaces being removed and 
added at runtime and 2) when NUT was guaranteed to start after all of the 
network interfaces were already up.

Can you just use "LISTEN 0.0.0.0"? If there is one particular interface you are 
excluding, can you handle that with firewall rules?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Junda-tech

[Charles Lepple]

On Oct 17, 2017, at 8:48 AM, LLSJ Krüger  wrote:
> Results of 'lsusb -vvv -d 3344:'
[...]
>   wDescriptorLength 136
>  Report Descriptors:
>** UNAVAILABLE **
> 

Can you please re-run lsusb, possibly as root, to grab the contents of the 
"Report Descriptors" section? 

(Running "usbhid-ups" should have detached the kernel driver already, which 
should allow lsusb to retrieve that descriptor -- but if you have 
disconnected+reconnected the USB cable since testing, you will need to re-run 
"usbhid-ups" before "lsusb".)

> ran usbhid-ups - -u root -x explore -x vendorid=3344 -x port=auto -a
> myups >& /tmp/junda-tech.txt
> 
> and then
> 
> gen-usbhid-subdriver.sh < /tmp/junda-tech.txt' :
> 
[...]
> /* --- */
> /* HID2NUT lookup table*/
> /* --- */
> 
> static hid_info_t jundatech_hid2nut[] = {
> 
>   { "unmapped.ups.powersummary.capacitymode", 0, 0,
> "UPS.PowerSummary.CapacityMode", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.designcapacity", 0, 0,
> "UPS.PowerSummary.DesignCapacity", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.fullchargecapacity", 0, 0,
> "UPS.PowerSummary.FullChargeCapacity", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.presentstatus.acpresent", 0, 0,
> "UPS.PowerSummary.PresentStatus.ACPresent", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.presentstatus.charging", 0, 0,
> "UPS.PowerSummary.PresentStatus.Charging", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.presentstatus.discharging", 0, 0,
> "UPS.PowerSummary.PresentStatus.Discharging", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.rechargeable", 0, 0,
> "UPS.PowerSummary.Rechargeable", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.remainingcapacity", 0, 0,
> "UPS.PowerSummary.RemainingCapacity", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.imanufacturer", 0, 0,
> "UPS.PowerSummary.iManufacturer", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.iproduct", 0, 0,
> "UPS.PowerSummary.iProduct", NULL, "%.0f", 0, NULL },
>   { "unmapped.ups.powersummary.iserialnumber", 0, 0,
> "UPS.PowerSummary.iSerialNumber", NULL, "%.0f", 0, NULL },

This part looks promising - the UPS appears to implement a portion of the HID 
Power Device Class specification, rather than just being a HID-enabled 
USB-to-serial adapter.

In the generated code, the capitalized names are HID PDC names, which you can 
search for in the nut/drivers/ directory to see how other vendors use them. The 
script just maps them to generic numbers, but the values are most useful if 
mapped to proper types. For instance:

$ git grep UPS.PowerSummary.PresentStatus.ACPresent

drivers/apc-hid.c:  { "BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.ACPresent", 
NULL, NULL, HU_FLAG_QUICK_POLL, online_info },

drivers/belkin-hid.c:  { "BOOL", 0, 0, 
"UPS.PowerSummary.PresentStatus.ACPresent", NULL, NULL, HU_FLAG_QUICK_POLL, 
liebert_online_info },

...

This indicates that the APC models tend to follow the spec, but that we had to 
add a custom mapping function for Belkin/Liebert since their boolean True value 
is often 1e-7 instead of 1.

I would recommend checking the values to make sure that they match the labels, 
but static attributes such as CapacityMode, DesignCapacity, FullChargeCapacity 
and Rechargeable can get a HU_FLAG_STATIC or HU_FLAG_SEMI_STATIC flag (see 
drivers/usbhid-ups.h) so that the driver does not waste time polling them. Some 
values like iManufacturer, iProduct and iSerialNumber are likely duplicates of 
the values in the USB device descriptor, and do not need to be included.

>>> 
>> Which part of the website?
> As below except with some minor changes, like -a instead of -s

Ah, right - I will add a note to the text that `-s` might not be available yet.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Junda-tech

[Charles Lepple]

[please use Reply-All to include the list, thanks!]

> On Oct 11, 2017, at 12:20 PM, Louis LSJ Krüger  wrote:
> 
> Hi,
> 
> I have an UPS with only the marking D1000 on it and it came with
> Junda-Tech's UpsMate.

Not sure we have had any reports of Junda-Tech before. Is there a URL for the 
software?

> Its USB id is 3344:0025, which is apparently a microprocessor.
> 
> I've could get some of the HID interactions as described on the website,
> but there are some outstanding.

Which part of the website?

This section has some information:

http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#hid-subdrivers

There is a typo that affects this section:

https://github.com/networkupstools/nut/commit/5c9b57f105f5e81334450c378499bbb0c8ec74e4#diff-559ace1283bb758aa77e37c6a74dde4bR136

(basically, the "auto" at the end of the "usbhid-ups" command line should be 
"-x port=auto -s ups")

Also, can you send the output of "lsusb -vvv -d 3344:"?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Bug or feature? polling frequency = (pollfreq + pollinterval)

[Charles Lepple]

On Sep 19, 2017, at 9:50 PM, René Berber <rber...@fastmail.fm> wrote:
> 
> On 9/19/2017 6:45 PM, Charles Lepple wrote:
> 
>> On Sep 19, 2017, at 1:36 PM, René Berber wrote:
> 
>>> My guess is that they are the same version (Synology keeps it updated).
>> 
>> Is there a way to check which version they are using? (Just curious - 
>> probably will not affect the problem you described.)
> None I could find, tried strings, might try telnet but my guess is that
> it will spew the same modified version string.
> 
> Indirectly there is a Synology forum post
> (https://forum.synology.com/enu/viewtopic.php?f=3=134961=498189)
> where this user says they are installing a very outdated (circa 2012)
> version.  No idea how he found that out.

The HID driver version can help pin things down. "MGE HID 1.33" was committed 
in 2014:

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

So it is somewhere between v2.7.1 and v2.7.2.

> I also tried the open source repository put out by Synology and couldn't
> find NUT; which is odd.

I am not a lawyer, but my understanding is that if they are distributing 
binaries of NUT, they need to provide a way for customers to get the source.


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

Re: [Nut-upsuser] Bug or feature? polling frequency = (pollfreq + pollinterval)

[Charles Lepple]

On Sep 19, 2017, at 1:36 PM, René Berber  wrote:
> My guess is that they are the same version (Synology keeps it updated).

Is there a way to check which version they are using? (Just curious - probably 
will not affect the problem you described.)

> Read about pollfreq, and pollinterval, but didn't see NUT's code.

The usbhid-ups code is here:

   
https://github.com/networkupstools/nut/blob/v2.7.4/drivers/usbhid-ups.c#L851-L871

> The values of those are:
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 5
> 
> I found that power consumption (ups.realpower) only changes every 35
> seconds, which is (pollfreq + pollinterval).
> 
> Does this looks correct?  I would expect changes at pollfreq.

Since we can't control UPS latency, the polling does not have very tight 
timing. I would expect it to be closer to 30 seconds, though.

If you run the driver with a few "-D" options, you will see a timestamp at the 
beginning of each line, and you should be able to follow the various Quick and 
Full update cycles.

You could comment out some of the mapping lines in the mge_hid2nut table if you 
don't want to waste time reading certain values:

   https://github.com/networkupstools/nut/blob/v2.7.4/drivers/mge-hid.c#L1083

Note that there are some duplicates - your UPS will not have every one of those 
HID PDC usages (4th column).
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] building on Solus

[Charles Lepple]

On Sep 17, 2017, at 9:39 PM, MTS  wrote:
> 
> I am looking at the readme in /scripts/python but am unsure how to proceed.

To be honest, the install process for the GUI is pretty much "install the 
distro package", due to the additional dependencies. (I have been trying to 
install some Python GUI modules from PyPI for another project, and the .deb 
packages seem way cleaner.)

To install the PyNUT module, look for the 'site-packages' directory in the 
output of this command:

python -c 'import sys; print sys.path'

Copy PyNUT.py to that directory.

(The Debian/Ubuntu/Mint way is to put modules in python-support, then the 
postinst does some magic to compile the modules into the site-packages for each 
of the Python versions that are installed.)

To run the NUT-Monitor GUI, you will need PyGTK. For help there, you may need 
to ask on a Solus list or forum.





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

Re: [Nut-upsuser] building on Solus

[Charles Lepple]

On Sep 17, 2017, at 6:33 PM, MTS  wrote:
> 
> I am using the same configs as I have in Linux Mint. What do I need to change 
> here?

Sounds like this worked itself out, but if you change upsd.users in the future, 
you will need to reload (sudo upsd -c reload) or restart upsd.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] building on Solus (was: Flatpak request)

[Charles Lepple]

On Sep 15, 2017, at 11:15 PM, MTS  wrote:
> 
> Hi,
> 
> I thought it might be problematic. I am really frustrated I cannot get it 
> working on Solus.
> I use Solus way more than Mint these days and it would be nice to have NUT 
> working.

If you describe the problems you are having when trying to build it, maybe we 
can help. 

Please use reply-all to keep the list CC'd. 
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Flatpak request

[Charles Lepple]

On Sep 15, 2017, at 9:51 PM, MTS  wrote:
> 
> Is there a possibility of NUT being built into a Flatpak so all distributions 
> can use it.
> If it was available on Flathub it would be a simple and foolproof way of 
> installing it.

>From http://flatpak.org/faq.html :

"Can Flatpak be used on servers too?

"Flatpak is designed to run inside a desktop session and relies on certain 
session services, such as a dbus session bus and a systemd --user instance. 
This makes Flatpak not a good match for a server."

I am not familiar with Flatpak myself, but given the differences between all of 
the packages of NUT for various distros (especially in the way that they shut 
down the system and then the UPS), I don't know if it would be possible to 
reliably package anything more than the NUT-Monitor GUI for Flatpak.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] new NUT release please!

[Charles Lepple]

On 11/9/17 1:56 am, Dutchman01 wrote:
> 
> I request a new NUT release as current dates back to March 9, 2016: NUT 2.7.4
> 
> 
> The fact stays that not all distro’s use latest snapshots/commits from github 
> dev tree.
> 

Not all of the distros have moved to 2.7.4, either...

As Sam alluded to out on the list (are you subscribed?), if you have a specific 
issue (such as the one addressed by the libusb-1.0 branch), let us know and we 
can help you build packages for your distro that include the patches you need.

If you just want the latest version, note that the tarballs that you can get 
from http://buildbot.networkupstools.org (check for links on the Debian 
builders) are very similar to releases - we use the same `make distcheck` 
procedure to build and test what we can (without real UPS hardware) as when we 
build an "official" release.

I was going to push for a new release that includes the libusb-1.0 branch, and 
then I found some issues in the Git history that we need to resolve before 
merging (see discussion at https://github.com/networkupstools/nut/issues/300 ). 
Arnaud has also been busy lately, and I am in the midst of trying to move the 
server that includes, among other things, buildbot.networkupstools.org.

That said, let us know if you have specific issues that might have been solved 
post-2.7.4.

On Sep 10, 2017, at 5:27 PM, Tim Dawson wrote:

> And you can source build the current version from source on pretty much 
> anything, thus negating any value of distro centric packaging . . .

While this is true for many packages, I think this is a bit of a stretch for a 
tool like NUT when it is being used to shut down a system. Barring the 
inevitable bug that creeps in, I think the distros are in a much better place 
to fix integration problems with their shutdown scripts. Sam's suggestion of 
adding newer NUT sources to existing Fedora RPMs seems like it would reap the 
benefits of both the distro integration and the newer NUT features and bug 
fixes.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Problem with upsmon?

[Charles Lepple]

On Sep 2, 2017, at 1:55 PM, Michele Alzetta  wrote:
> 
> the brand is Vultech, but lsusb gives me this:
> 
> Bus 003 Device 006: ID 0925:1234 Lakeview Research

It is likely that someone just copied the USB device descriptor from the 
example in Jan Axelson's book. Whether this is the same hardware that the 
richcomm_usb driver works with is another question. 

What does this command return?

   lsusb -vvv -d 0925:

Might need to run it as root. ___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can not inialize SSL connection

[Charles Lepple]

On Aug 31, 2017, at 5:33 PM, Gareth Williams  
wrote:
> 
> I'm trying to get upsd (version 2.7.2 running on Debian) to work with an SSL 
> certificate.

>From https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1576584 :

"Please see https://github.com/networkupstools/nut/issues/190 for more 
information. I have included the text description from there below. Looks like 
the issue was fixed back in April of 2015 in 2.7.3."

If upgrading the distribution to stretch is not an option, you could request a 
backport. However, it might be possible (and quicker) to hack the init script 
to launch upsd in the foreground.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Windows Binary for 2.7.4

[Charles Lepple]

On Aug 13, 2017, at 10:29 PM, Jeff Silberberg  wrote:
> Looking at the project site the latest Windows Binary is a few back - 2.6.5.6
> 
> Has any one built a more recent version that they can upload and update the 
> Project site ?
> 
> Looking for Windows 7 / Windows 8, not running Windows 10 on any of my tool 
> Laptops and 
> I need to check some battery packs and overall status on a series of UPS 
> units in shelters,  The build 
> 2.6.5.6 gives my grirf in a number of areas including libusb0.dll  

The windows-port branch was not merged properly with the main NUT SVN trunk 
(now Git master branch) during development, so it is effectively stuck at 
2.6.5.x.

There was talk of rewriting the Windows compatibility layer for later versions 
of NUT. Some status is scattered across the following GitHub issues.

https://github.com/networkupstools/nut/issues?q=is%3Aopen+is%3Aissue+label%3AWindows

If your issue is mostly with USB, you might consider using an embedded Linux 
system as a NUT server, and running NUT 2.6.5-6 or ntUPSd on the clients.

Also, if you know of anyone willing to help out with the NUT Windows port, that 
would be most useful. (The intent is to cross-compile using the MinGW compilers 
so that we can easily keep the Windows code in sync with the classic NUT 
codebase, and I realize MinGW might be a turn-off to potential developers 
accustomed to Visual Studio.)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] TrippLite SMART1500LCD no delay before ups shutdown.

[Charles Lepple]

On Aug 21, 2017, at 1:35 PM, Whiteshell Tech  wrote:
> 
> I ran it again on battery and upsd running, set upsrw ok and then 
> shutdown.return gave an "ERR CMD-NOT-SUPPORTED" Odd thing is after running 
> that I am getting random timed ups powering off for one or two seconds then 
> turns back on even on battery. Server then starts shutting down. Some times 
> its right away sometimes after 4+ minutes.

That is going to be hard to diagnose without the usbhid-ups logs for the time 
when those commands are sent - can you try to keep the log going while sending 
them, then note the time when the command was sent? You can use the "tee" 
command:

/lib/nut/usbhid-ups -DD -a TrippLiteUPS 2>&1 | tee /tmp/log.shutdown.return.txt

(please use gzip before attaching the log - the mailing list does not accept 
messages over 40kB without manual intervention.)

> I did notice that that return.shutdown was not found in the list running 
> "upscmd -l TrippLiteUPS". I did see "load.off.delay" which also if I give a 
> value of 60 (or any other value) it shuts down in 20sec and stays off either 
> on battery or online. ups does come back on if i replug the ups.

I think the load.off.delay behavior is expected, but I really thought the 
others should honor the delay variables. Will have to look further.

> 
> 
> I am setting up a test computer with fresh Debian 9 for testing to see if all 
> my issues are still there without every thing else.
> 
> Thanks for taking the time when you have some.
> 
> 
> root@host:~# upscmd -l TrippLiteUPS
> Instant commands supported on UPS [TrippLiteUPS]:
> 
> beeper.disable - Disable the UPS beeper
> beeper.enable - Enable the UPS beeper
> beeper.mute - Temporarily mute the UPS beeper
> beeper.off - Obsolete (use beeper.disable or beeper.mute)
> beeper.on - Obsolete (use beeper.enable)
> load.off - Turn off the load immediately
> load.off.delay - Turn off the load with a delay (seconds)
> reset.watchdog - Reset watchdog timer
> shutdown.reboot - Shut down the load briefly while rebooting the UPS
> shutdown.stop - Stop a shutdown in progress
> test.battery.start.deep - Start a deep battery test
> test.battery.start.quick - Start a quick battery test
> test.battery.stop - Stop the battery test
> 
> 
> 
> root@host:~# upsrw -s ups.delay.shutdown=60 TrippLiteUPS@localhost
> Username (root): upsmon
> Password:
> OK
> 
> root@host:~# upscmd TrippLiteUPS shutdown.return
> Username (root): upsmon
> Password:
> Unexpected response from upsd: ERR CMD-NOT-SUPPORTED
> 

log trimmed; appears to be the same as before?




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

Re: [Nut-upsuser] TrippLite SMART1500LCD no delay before ups shutdown.

[Charles Lepple]

On Aug 21, 2017, at 8:33 AM, Charles Lepple <clep...@gmail.com> wrote:
> 
> That said, it looks like the TrippLite HID mappings (in v2.7.4 as well as 
> master) are missing the "shutdown.return" command. I'd look into it further, 
> but ironically, the local power company has scheduled maintenance coming up 
> soon, and I am typing this on a machine with a Tripp Lite UPS that doesn't 
> play well with NUT. Should have more time later today or this week.

My mistake, should be handled by the main driver code here:

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/usbhid-ups.c#L558-L583

Can you grab a log as before, but with upsd running? You can send the upsrw 
command to set the timer, then get upscmd to run the "shutdown.return" command 
(might need to be on battery for this to work). It might also be best to power 
the server from another outlet or UPS.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] TrippLite SMART1500LCD no delay before ups shutdown.

[Charles Lepple]

[when responding, please use reply-all - the list does not mangle the reply-to 
header]

> On Aug 21, 2017, at 12:45 AM, Whiteshell Tech  
> wrote:
> 
> I have attempted to set the delay higher using "upsrw -s 
> ups.delay.shutdown=120 TrippLiteUPS@localhost" and confirmed the value with 
> "upsc TrippLiteUPS@localhost" Still the UPS switches off right away.

Due to the way that the HID PDC shutdown sequence works, the value you see from 
"upsc ups.delay.shutdown" is just a variable in the driver. It does not write 
that to the UPS until the delayed shutdown command is sent, since the shutdown 
timer in the UPS starts when that value is written.

That said, it looks like the TrippLite HID mappings (in v2.7.4 as well as 
master) are missing the "shutdown.return" command. I'd look into it further, 
but ironically, the local power company has scheduled maintenance coming up 
soon, and I am typing this on a machine with a Tripp Lite UPS that doesn't play 
well with NUT. Should have more time later today or this week.

> At first after installing the debian nut packages with apt-get and setting up 
> the config files I had to setup a systemd service to exeu "upsdrvctl 
> shutdown" on shutdown or else the ups would not turn off at all. Now after 
> setting up that service is when I discovered the issue, that the ups does not 
> delay in shutting down. 
> 
This sounds like a bug in the Debian packaging (or Proxmox? Not sure where the 
dividing line is.) Can you check their bug trackers?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] New powercom device?

[Charles Lepple]

On Aug 16, 2017, at 8:36 PM, Harlan Stenn  wrote:
> 
>> 
>> Is it possible that you just need to load the usbserial kernel
>> module, and bind it to the UPS' 0d9f:0002 ID? Then the /dev/ttyUSB*
>> port can be passed to the "powercom" driver. (This is suggested by
>> http://networkupstools.org/stable-hcl.html?manufacturer=Powercom=USB
>> )
> 
> OK, thanks!  I read up about the stuff in the last paragraph, and it's
> not clear to me what I need to do to test this out.
> 
> % ls /lib/modules/`uname r`/kernel/drivers/usb/serial/
> ch341.ko  cp210x.ko  ftdi_sio.ko
> % lsusb
> Bus 004 Device 003: ID 0d9f:0002 Powercom Co., Ltd Black Knight PRO /
> WOW Uninterruptible Power Supply (Cypress HID->COM RS232)
> Bus 004 Device 001: ... root hub
> ...
> %
> 
> The debian docs say:  Look at the output of lsusb, and if it identifies
> the serial device, try installing the appropriate driver using modprobe.
> Then tell it about the new nyumber using "echo VENDOR PRODUCT
>> /sys/bus/usb-serial/drivers/DRIVER"
> 
> So any pointers on what I should do next would be appreciated.

In case you haven't done this, unplug and re-plug the USB cable after stopping 
usbhid-ups - that driver temporarily detaches any existing kernel drivers.

This post indicates that it might be the cypress_m8 driver: 
https://lists.alioth.debian.org/pipermail/nut-upsuser/2010-October/006260.html

Is it possible that the Cypress driver is built in to your kernel, or is there 
another potential modules directory? Both Debian jessie and stretch seem to 
have the module: 
https://packages.debian.org/search?searchon=contents=cypress_m8=filename=oldstable=any
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 16, 2017, at 3:27 AM, Song Teck  wrote:
> 
> How do I go about capturing the log?

You might want to discharge the battery most of the way to battery.charge.low 
(5%, if it is similar to the other unit listed in the DDL) before switching to 
debug mode, because it is fairly verbose. Then, stop the NUT components ("sudo 
stop nut-client" and "sudo stop nut-server") and run this:

sudo /lib/nut/usbhid-ups -DD -a name-of-ups 2>&1 | tee 
/tmp/OpenUPS2.low-battery.txt

Please gzip the log before emailing it to the list.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] New powercom device?

[Charles Lepple]

On Aug 10, 2017, at 12:19 AM, Harlan Stenn wrote:
> 
>   0.447497HID descriptor length 37
>   0.450449Report Descriptor size = 37
>   0.451062Using subdriver: PowerCOM HID 0.5
>   0.4519963 HID objects found
>   0.453502Path: ffa1.ffa1, Type: Input, ReportID: 0x00,
> Offset: 0, Size: 8, Value: 0
>   0.453677Path: ffa1.ffa2, Type: Output, ReportID: 0x00,
> Offset: 0, Size: 8, Value: 0
>   0.454070Path: ffa1.ffa3, Type: Feature, ReportID: 0x00,
> Offset: 0, Size: 8, Value: 0

Unfortunately, this won't be able to be supported by the usbhid-ups driver - it 
looks like they are using USB HID to emulate a serial port. (A true USB HID 
Power Device Class report descriptor is generally several hundred bytes long, 
versus the 37 shown here).

Is it possible that you just need to load the usbserial kernel module, and bind 
it to the UPS' 0d9f:0002 ID? Then the /dev/ttyUSB* port can be passed to the 
"powercom" driver. (This is suggested by 
http://networkupstools.org/stable-hcl.html?manufacturer=Powercom=USB 
)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] CyberPower ol2000ertxl2u

[Charles Lepple]

On Aug 8, 2017, at 4:57 AM, Greg Vickers wrote:
> 
> I'm picking up a CyberPower OL2000ERTXL2U tomorrow (needs new batteries), 
> should that be supported via the powerpanel driver?

Unfortunately, the author of the powerpanel driver has not had time to 
contribute to NUT for some time now, but if you have debug logs, we can try to 
sort through them (if it does not work outright).

Not sure if USB HID is an option for your setup, but the product web page 
mentioned something about HID support, so there is that.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Keep on losing communication: Raspberry Pi, CyberPower PR1500LCD

[Charles Lepple]

On Aug 12, 2017, at 12:00 PM, Rory Jaffe  wrote:
> 
> OS Version: Linux piaware 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 
> armv7l GNU/Linux
> Nut Version: 2.7.2-4
> Nut Installation Method: apt
> Device: CyberPower PR1500LCD
> Uses​ ​Generic HID driver 0.38 (2.7.2)

Is this stock Raspbian or another variant?

If it is Raspbian, I think it might be affected by a Debian issue with 
libusb-0.1. It is possible to rebuild from source and use libusb-1.0 instead - 
let us know if that sounds reasonable. You can also check the list archives for 
previous discussions (although I think we were seeing issues with Tripp-Lite 
hardware more frequently).

Also, sometimes swapping out the USB cable can help.
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 15, 2017, at 5:24 AM, Song Teck  wrote:
> 
> Hi Charles,
> 
> Have managed to make some progress after a fashion. Got the unit to work on 
> the jessie version of NUT (2.7.2). upsc does output the unit parameters, 
> along with the mis-scaled voltage readings described at 
> http://networkupstools.org/ddl/Mini-Box.com/OpenUPS2.html. Am now trying to 
> get the shutdown sequence to work properly. 
> 
> Have been following this: 
> http://networkupstools.org/docs/user-manual.chunked/ar01s06.html
> Unit performs as described in the "Testing shutdowns" section.
> 
> I have another question that I am hoping to get some clarification with.
> 
> The ups unit does not transit into OB LB even when Battery Charge falls below 
> the LB level. The unit does initiate power off properly when Battery 
> Charge/Runtime reaches 0. 
> Is this correct? Or should there be an earlier transition and shutdown 
> triggered by OB LB? 

The driver should recognize one of several standard shutdown notifications:

   
https://github.com/networkupstools/nut/blob/v2.7.2-signed/drivers/openups-hid.c#L300-L302

However, I don't know which of these is actually implemented in the firmware. 
If you can afford some downtime, you can capture a log as the battery 
discharges - let us know if you want to try that.

To synthesize the OB+LB state, you can use the "ignorelb" flag with 
override.battery.charge.low and/or override.battery.runtime.low as described in 
http://networkupstools.org/docs/man/ups.conf.html

You mentioned that the UPS powers off by itself when the charge reaches 0. Note 
that there does not seem to be a way to tell it to power off early with a 
command from NUT (e.g. "upsdrvctl shutdown", which gets translated to 
"/path/to/driver ... -k").

> 
> I have also not been able to successfully get NOTIFYMSG or NOTIFYFLAG to work 
> successfully although I suspect that has to do with my configuration of 
> NOTIFYCMD. Will pursue that a little more. 

I'd recommend a separate email thread for that, and check Roger Price's writeup 
for further information: http://rogerprice.org/NUT.html



___
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 Client Shuts Down After Brief Power Loss

[Charles Lepple]

On Aug 8, 2017, at 6:34 PM, Todd Benivegna  wrote:
> 
> OS name and version:  MacOS 10.9.5 on 2011 Mac mini
> NUT version:  2.7.4-1
> NUT installation method:  Package installed via FINK and FinkCommander
> Exact device name:  APC Back-UPS NS 650M1 (brand new)
> 
> Issue:  
> 
> I have the NUT client installed and running properly; two processes running 
> as root and the other as regular user processes.  The NUT server is my 
> Synology NAS (DS416).  Client is communicating with server (confirmed by 
> running "sudo upsc UPS@[Your_IP]”).  It receives events when I manually pull 
> the power plug and shuts down properly when I do a forced shutdown (by doing 
> “sudo upsmon -c fsd” via telnet on the NAS).
> 
> The problem is when there is an actual brief power outage of a few seconds, 
> maybe 5 - 10 seconds max.  The NAS stays powered up, however the Mac mini 
> (NUT client) shuts down.  When booted back up it immediately shuts down again.

When it is in that state, what do you get from "upsc UPS@[IP] ups.status"? (Not 
a big deal, but upsc doesn't need root privileges - it just connects over a TCP 
socket.)

> It will keep shutting down as soon as it boots up in MacOS and will keep 
> doing that until I reboot the NAS.  I’m not sure if the problem is the client 
> or server, however I’ve been talking to Synology Tech Support and this was 
> their last message:
> 
> "Can you please check the NUT settings on your Clients and make sure that 
> there is enough of a delay/wait period after it gets the signal.”
> 
> What delay are they talking about?  I have looked through the upsmon.conf and 
> am not sure if anything there is the appropriate delay to adjust.  Does that 
> even seem right?  Is the problem with the client or the server?  I can paste 
> my upsmon.conf and any logs if necessary.  Any help would be greatly 
> appreciated.  Thank you.

Unless the ups.status value is "OB LB", a basic upsmon configuration won't shut 
down a client system for just a brief excursion onto battery power. Beyond 
that, things get complicated, so we would need to see how things are 
configured. Be sure to blank out any passwords, and you can also strip out 
lines with comments in the configuration ("grep -v '^#'" or something similar).

Be sure to CC the list on the reply - other people on the list are more 
familiar with the "shut down after N minutes" style of shutdown than I am.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] I have a question in use CyberPower UPS.

[Charles Lepple]

On Aug 8, 2017, at 4:01 AM, Andy Jan <andy163...@gmail.com> wrote:
> 
> Hi Charles,
> 
> The attachment(gzip) is the CyberPower UPS USB HID data.
> It is worked! Thanks a lot.

That's from a different UPS, right?

Committed to master (as b898bc652). Thanks for testing!

-- 
- 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] I have a question in use CyberPower UPS.

[Charles Lepple]

On Aug 7, 2017, at 7:33 AM, Andy Jan  wrote:
> 
> [root@andy nut-2.7.4]# yum install libusb
> Loaded plugins: langpacks, presto, refresh-packagekit
> Package 1:libusb-0.1.3-11.fc18.i686 already installed and latest version

That is the runtime library. To rebuild nut, you will also need something like 
libusb-devel (not sure of the exact name)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] I have a question in use CyberPower UPS.

[Charles Lepple]

On Aug 4, 2017, at 4:56 AM, Andy Jan  wrote:
> 
> Is the modification will be released?

Let me know if it works, and I will merge that onto the master branch that will 
be used for the next release.
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 3, 2017, at 5:35 AM, Song Teck  wrote:
> 
> That package is supposed to install both server and client (according to the 
> description at https://packages.debian.org/stretch/nut anyway). I'll try both 
> server and client individually later and see if that helps.
> 
Right, but only if you install it via apt. If you install the 2.7.4 .deb with 
dpkg, and you have the 2.6.4 nut-client and nut-server .debs installed, the 
dependencies are satisfied. (The nut metapackage does not depend on specific 
versions.)
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 2, 2017, at 12:09 PM, Song Teck  wrote:
> 
> sudo dpkg -i nut_2.7.4-5_all.deb
> (Reading database ... 103447 files and directories currently installed.)
> Preparing to replace nut 2.6.4-2.3+deb7u1 (using nut_2.7.4-5_all.deb) ...
> Unpacking replacement nut ...
> Setting up nut (2.7.4-5) ...
> 
> which doesn't return an error but starting upsdrvctl after still shows v2.6.4 
> so that didn't work.
> 
The "nut" package only depends on "nut-client" and "nut-server", so you would 
need .debs for those as well. Those are the ones that I think would be likely 
to have issues.
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 1, 2017, at 12:01 PM, Song Teck  wrote:
> 
> Hi Charles,
> 
> Ok, I missed the absence from the backports as well. Again, some 
> unfamiliarity here, so 
> 
> 1) I presume I cannot use a metapackage meant for jessie or stretch on 
> wheezy? Or if I can, is there a way to deploy it from console?

The "nut" metapackage just depends on "nut-client" and "nut-server". The 
drivers are in the server package - you'd need to find a way to install a newer 
nut-server package, and I don't know if I would want to try and mix .deb 
versions like that (if it is even possible).

> 2) If not and I use the 2.7.4 tar found at 
> http://networkupstools.org/download.html, do i just run the classical 
> process? i.e.
> 
> ./configure
> make
> sudo make install

You could, but the paths would be slightly different from the .deb version, and 
it won't necessarily integrate with the system shutdown. However, the 
driver-to-upsd interface hasn't changed between 2.6.5 and 2.7.4, as long as you 
use the same paths for ./configure that the 2.6.5 Debian package used.

> 
> ./configure has a no under "install USB drivers" and when I add that handle 
> (--with-usb) in, it prompts for libusb. 
> 
> Does that mean I actually have to do the process referenced in your link? Or 
> is it fine to go ahead with that as USB drivers as a no?
> 

The OpenUPS2 is connected via USB, so you'll need the libusb dependencies.

> here is some info on that process: 
> http://lists.alioth.debian.org/pipermail/nut-upsuser/2016-October/010389.html
> 
> In your case, you probably don't need the libusb-1.0 branch snapshot, so you 
> could just use a NUT tarball from the downloads page: 
> http://networkupstools.org/download.html#_stable_tree_2_7
> 
To clarify: that thread was talking about a snapshot of a NUT branch that uses 
libusb-1.0, versus the original libusb-0.1 support. If you set things up to do 
"apt-get build-dep nut", it will pull in the libusb-dev package (which would 
cause the ./configure output to say yes for building USB drivers).
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] I have a question in use CyberPower UPS.

[Charles Lepple]

On Aug 1, 2017, at 5:47 AM, Andy Jan  wrote:
> 
> But I want to see the frequency in NUT by connecting CPS UPS. I have traced 
> the NUT source code and find that the CPS HID table doesn't build the 
> frequency.
> 
> Due to I know less about Linux and NUT. Could you help to revise the NUT CPS 
> HID table? My UPS model is PR750ELCD.
> 
Can you please send a log from "explore" mode?

http://networkupstools.org/docs/man/usbhid-ups.html

Not sure which distribution you are using, but on Debian/Ubuntu it will look 
something like this:

/lib/nut/usbhid-ups -DD -x explore -a name-of-ups 2>&1 | tee 
/tmp/explore-CPS.txt

It will loop continuously if it finds the UPS, so you can press Control-C after 
~ 30 seconds. Please gzip the log before emailing it to the list.
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 1, 2017, at 7:56 AM, Song Teck Ng  
wrote:
> 
> Hi Charles,
> 
> Thanks for your reply. So the Jessie or stretch versions will work then since 
> those are 2.7.2 and 2.7.4...
> 
> I will have to update my sources.list and follow this?
>  
> https://backports.debian.org/Instructions/

That was the thought, but I mistakenly thought that there was a NUT package in 
wheezy-backports. 
https://packages.debian.org/search?suite=wheezy-backports=nut-server 
does not list anything. (Debian only does backports by request, and that could 
take a while - especially for something in oldoldstable.)

Agreed that upgrading to jessie or stretch would work.

If you can install build-essential and the NUT build-deps, you could build a 
newer version from source.

here is some info on that process: 
http://lists.alioth.debian.org/pipermail/nut-upsuser/2016-October/010389.html

In your case, you probably don't need the libusb-1.0 branch snapshot, so you 
could just use a NUT tarball from the downloads page: 
http://networkupstools.org/download.html#_stable_tree_2_7
___
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 not recognising Mini-box OpenUPS 2

[Charles Lepple]

On Aug 1, 2017, at 3:14 AM, Song Teck Ng  
wrote:
> 4) Have edited the ups.conf and nut.conf files with the necessary entries but 
> trying to start the driver with upsdrvctl start gives:
> "Network UPS Tools - UPS driver controller 2.6.4
> 
> Network UPS Tools - Generic HID driver 0.37 (2.6.4)
> 
Support for the original OpenUPS was added in NUT v2.7.1. Is there any way you 
can use Debian Backports to get a newer version of NUT?


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

Re: [Nut-upsuser] Compaq R3000h support

[Charles Lepple]

[please don't use HTML email unless needed.]

sorry for the delay. 

> On Jul 22, 2017, at 11:33 AM, Tomas Larsson  wrote:
> 
> Now I have some access problems.
> This is what ends up un messages
> Hosts.allow is set to accept anyone on the local net.
> Username and passwords are the same
> Upsc gives proper output.
> System is Centos 6.8
>  
> Jul 22 17:20:06 BIFROST upscode2[10113]: Startup successful
> Jul 22 17:20:06 BIFROST upsd[10116]: listening on ::1 port 3493
> Jul 22 17:20:06 BIFROST upsd[10116]: listening on 192.168.0.1 port 3493
> Jul 22 17:20:06 BIFROST upsd[10116]: listening on 127.0.0.1 port 3493
> Jul 22 17:20:06 BIFROST upsd[10116]: Connected to UPS [R3000]: upscode2-R3000
> Jul 22 17:20:06 BIFROST upsd[10117]: Startup successful
> Jul 22 17:20:06 BIFROST upsmon[10121]: Startup successful
> Jul 22 17:20:06 BIFROST upsmon[10122]: Login on UPS [R3000@localhost] failed 
> - got [ERR ACCESS-DENIED]
> 
for upsmon-to-upsd access issues, you should to check that upsmon.conf is using 
a NUT login/password that is listed in upsd.users as having either "upsmon 
master" or "upsmon slave" privileges, as appropriate. If you change upsd.users, 
reload or restart upsd.

http://networkupstools.org/docs/man/upsd.html

http://networkupstools.org/docs/man/upsd.users.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Compaq R3000h support

[Charles Lepple]

On Jul 22, 2017, at 4:13 AM, Tomas Larsson  wrote:
> 
> I am planning to install NUT (master) on a headless CENTOS 6.8 system.
> Connect the UPS with seral cable.

It looks like this might be using the upscode2 driver (UPScode-II protocol), 
right?

> Now my main question is, Does NUT support the power segments on the UPS.
> My intention is to be able to take down the system in an ordered way before 
> the batteries are exhausted.

The upscode2 driver does not seem to support the segments, although this is a 
limitation of that driver rather than the rest of NUT. I have not looked into 
the protocol document too much, but it should be possible to add this. (It 
would probably be best if we could find someone with a spare UPS who is willing 
to test, though - you might not want to do this in production.)

> I.e 
> 5 mins after Power Loss take shut down the servers on segment 3.
> When they are down, shut down power for segment 3
> Then repeat for segment 2
> And finally process servers on segment 1
 
I do not use upsched (which is generally necessary for shutting down after a 
specified time on battery, rather than when the UPS determines that the battery 
is low), but it should be possible to do this even without controlling the 
segments.

Perhaps someone else with more recent experience can comment on this.

> Servers are a mix of Centos, W2k8R2 and ESXi5.5 with W2k8(R2).
> Workstationisi W10Pro
> NAS is Synology Rackstation RS816

I also have not used a Synology device, but as I recall, they generally expect 
to be the NUT master system. This may cause problems if you need to do 
something fancy with upssched.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

> On Jul 5, 2017, at 7:45 PM, Manuel Wolfshant  wrote:
> 
> udevadm control --reload ||:

from the man page:

--reload
   Signal systemd-udevd to reload the rules files and other databases 
like the kernel module index. Reloading rules and databases does not apply any 
changes to already existing devices; the new configuration will only be applied 
to new events.

So that might not be sufficient for devices that are plugged in at the time the 
package is installed.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

On Jul 5, 2017, at 7:23 PM, Manuel Wolfshant wrote:
> 
>> Manuel: did you happen to regenerate the udev files, or use one of the 
>> Buildbot tarballs? We typically don't bother to do that until "make dist" 
>> before a release (since the rules files are generated from *.in files based 
>> on configure parameters), so your package might still have the rules file 
>> from 2.7.4 (which does not include protocol 1330).
> yes, the package installed by Mr. Coletti includes the new rules:

Thanks for checking. (I really should set up a Fedora VM and/or learn how to 
use alien to check on things like this.)

Does udev automatically reload when the rules files change? The Debian/Ubuntu 
packages are supposed to run "udevadm trigger --subsystem-match=usb 
--action=change" as part of the postinst.

(I think udev rescans the rules when a device is plugged in, so unplugging and 
re-plugging the USB cable should work, too.)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

On Jul 5, 2017, at 5:34 PM, Ambrogio Coletti  wrote:
> 
> From section 4.23 of the Developer Guide:
> 
> "There are a few USB UPS devices that are not HID devices. These devices 
> typically implement some version of the manufacturer’s serial protocol over 
> USB (which is a really dumb idea, by the way). An example is the Tripplite 
> USB. Such devices are not supported by the usbhid-ups driver, and are not 
> covered in this document."
> 
> I guess that applies to me?

No, but my original comment does:

"The Protocol 1330 support was added after 2.7.4 was released. You might be 
able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but voltages 
might be off by a factor of 10. You will also need to adjust the udev files 
manually to fix /dev/bus/usb permissions."

Manuel: did you happen to regenerate the udev files, or use one of the Buildbot 
tarballs? We typically don't bother to do that until "make dist" before a 
release (since the rules files are generated from *.in files based on configure 
parameters), so your package might still have the rules file from 2.7.4 (which 
does not include protocol 1330).

The comment in the developer guide was mostly accurate when we first saw 
Tripp-Lite USB devices with VID:PID 09ae:0001. Technically, they implement the 
USB HID protocol, but not the intended USB HID PDC (Power Device Class) spec. 
It looks like every PID other than 0001 (including 1330) implements PDC.___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jul 5, 2017, at 7:05 AM, Andrea de Lutti  wrote:
> 
> Which are the ups.status I can use with ups in dummy mode?
> I have seen only OB, LB, OL...
> 
Those are the ones that upsmon will respond to. The dummy-ups driver accepts 
any string, AFAIK.

Others: 
http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_manipulating_the_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] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jul 3, 2017, at 11:06 AM, Andrea de Lutti  wrote:
> 
> ​I would like that NOTIFYCMD points to upssched​. 
> 
If I understand correctly, Roger is pointing out that your configuration is 
confusing upssched and upssched-script.

Since you are using Ubuntu, upsmon.conf should contain "NOTIFYCMD 
/sbin/upssched". Similarly, upssched.conf should contain "CMDSCRIPT 
/usr/local/bin/upssched-script".

Not sure if those passwords in the script are real, but if they are, you will 
want to change them now.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] SU2200RTXLCD2U and protocol 4006

[Charles Lepple]

On Jul 3, 2017, at 12:48 PM, Ambrogio Coletti wrote:
> 
> I wouldn't use the NUT at this point because I don't think I will be able to 
> write a software update to adapt the NUT to my needs.
> 
> My idea was first to test the protocol via a serial terminal client directly 
> connected to the UPS, and then write some simple code from scratch to 
> implement the protocol and use it for my basic needs.
> 

Ambrogio,

If you are considering writing serial code from scratch, I don't think it is 
that much more complicated to modify the existing NUT drivers (if that is even 
needed). In general, protocol revisions from Tripp Lite have not been very 
different from the previous versions.

First, which OS and distribution are you using?

Rudimentary support for the 4006 protocol over USB has been in the usbhid-ups 
driver since NUT 2.6.0, but since that information was apparently added from 
another project, we don't have an entry in the HCL for that protocol. So I 
would try the USB connection first.

Bear in mind that some UPS firmware cannot switch between USB and serial 
without first powering down completely (including disconnecting AC). We don't 
have good data on which UPSes require this low-level reset, but it is something 
to try.

I have an older Tripp-Lite UPS that uses a different driver, so when I run 
"lsusb -d 09ae:", I see the following:

$ lsusb -d 09ae:
Bus 006 Device 002: ID 09ae:0001 Tripp Lite 

Yours will probably say "09ae:4006" instead.

A note: drivers/tripplite_usb.c was written for older models which seem to have 
a rudimentary USB-to-serial converter built in. Some of the commands and 
responses match those in drivers/tripplite.c (which talks to a serial port). It 
would be interesting to see where your UPS fails during detection with the 
drivers/tripplite.c code. I seem to remember it does not have much in the way 
of debugging (but strace should work).

You mentioned "set the communication parameters to those indicated in the 
protocol spec" - is this published somewhere?

Larry,
Thanks for the kind words!

- 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] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 29, 2017, at 6:52 AM, Andrea de Lutti wrote:
>>> Anyway I still not receive any email on any test (power cord disconnected 
>>> and/or reconnected for example)
>> 
>> Oh, I misinterpreted "working script" as a script that was sending email, 
>> rather than work-in-progress. Does that same command work from the command 
>> line? Can you add something like "logger" before the mailx line to be sure 
>> that the script is executing properly? Be sure to "chmod a+x" the script.
>> 
> ​Yep, the script works flawlessy with a command line. It is a "modified" 
> script from other jobs, and I receive daily all the emails from them​

Bear in mind that upsmon runs as user "nut" on Ubuntu, as does the NOTIFYCMD 
script. At one point, you said that the script is in /root, which is not 
commonly readable by other users. Does the script work if you move it to, say, 
/usr/local/bin?

(With Ubuntu 16.04, there should be some error messages from upsmon in 
'journalctl' referencing permissions.)

>> 
>> I forget if I mentioned this earlier, but for testing notifications, you can 
>> use the dummy-ups driver:
>> 
>>http://networkupstools.org/docs/man/dummy-ups.html
>> 
>> The timer example will simulate the OL-OB-LB transition.
>> 
> ​Maybe I have missing someting. I have exported my configuration to a .dev 
> file, and then used for dummy ups, configured as dummy. Do i need to make 
> circular tests (timer configuration) or may I do them manually? Just beacuse 
> the only command allowed in dummy mode (upscmd -l dummy@artu) is load.off
> 

Under the Bugs heading, the man page says "Instant commands are not yet 
supported in Dummy Mode..." - one of the use cases was automated developer 
testing of NUT, and there isn't much use in simulating all of the commands in 
that case. "load.off" is probably worth implementing at some point for user 
testing.

So for your use case, the timers would probably be the easiest way with the 
current code.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 27, 2017, at 9:23 AM, Andrea de Lutti  wrote:
> 
> Sorry, I didn't received it...

You should be subscribed to the list now.

> I don't have any REPLBATT message

Right, you would only get REPLBATT messages when the UPS reports that the 
battery *needs to be replaced* (and then at regular intervals per the 
upsmon.conf parameters).

> , but when in battery test I have OL CAL status: it would be good to have the 
> result.

"OL CAL" or "OB CAL"? If the UPS is powering the load from the battery during 
calibration, it should report "OB CAL". The ONBATT handler in NOTIFYCMD can 
check for CAL at that point.

I don't think we considered the case where CAL is paired with OL.

> Anyway I still not receive any email on any test (power cord disconnected 
> and/or reconnected for example)

Oh, I misinterpreted "working script" as a script that was sending email, 
rather than work-in-progress. Does that same command work from the command 
line? Can you add something like "logger" before the mailx line to be sure that 
the script is executing properly? Be sure to "chmod a+x" the script.

I forget if I mentioned this earlier, but for testing notifications, you can 
use the dummy-ups driver:

   http://networkupstools.org/docs/man/dummy-ups.html

The timer example will simulate the OL-OB-LB transition.

> Does the runtime calibration test alter the values of ups.conf? Or do I have 
> to change it manually? Which would be the right procedure for changing the 
> battery for calibrating NUT (over the manufacturer's suggestions)?

The automatic calibration/battery test invoked by upscmd (or the UPS front 
panel button, if any) is for the UPS low battery warning.

The manual calibration ups.conf parameters are necessary (and need to be 
maintained separately) because Qx-based protocols do not all report the 
state-of-charge as calculated by the UPS.

I would recommend both forms of calibration after replacing the battery.

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


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

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 26, 2017, at 7:03 AM, Andrea de Lutti  wrote:
> 
> Are there no warnings for battery test?

not sure if you saw my reply on 2016-06-17:

Do you mean a notification that a test is in progress, or something for the 
results?

There is the REPLBATT message in upsmon when the battery test fails, but I 
don't think the generic Qx protocol supports the RB status flag.

You could possibly trigger on the OB status and look for the CAL flag in 
ups.status as well, but I haven't tried to automate that.

^^^ If you run "upsc $UPSNAME ups.status", do you see CAL in the status string 
during a battery test? If not, your UPS is not reporting this the way that the 
driver expects.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Why are LAN ports not standard on UPSs these days?

[Charles Lepple]

On Jun 25, 2017, at 8:53 AM, Philip Rhoades wrote:

> I don't understand why most of the UPS offerings available do not come 
> standard with a LAN port? Why is this?

As others have mentioned, it probably comes down to cost for a port that is not 
frequently used.

Something to consider is that there are add-on cards with LAN ports for mid- to 
upper-tier UPSes. Some cards also have environmental monitoring options as well.

On the other hand, these cards do not seem to be high-volume items, and the 
prices reflect that. If you don't need fancy temperature sensing, a Raspberry 
Pi or other single-board computer is IMHO a better way to spend that money (and 
it will probably turn out to be more versatile).

One thing about the NUT master/slave architecture is that it forces you to 
consider the shutdown order. The NUT master is responsible for commanding the 
UPS to turn off the power, so at that point, the master system should not be 
depending on any other systems for their services. A LAN card with SNMP doesn't 
really enforce this hierarchy, but then again, there are probably some 
high-availability cases where SNMP makes more sense.

> Do people have suggestions about my options?  I have two main machines - say 
> 250-400W total and a few small devices inc a Billion router and some USB 
> devices.

Be sure to factor your network infrastructure into that power estimate - you 
will want the network links between NUT master and slave systems to be on 
battery power as well, or else the master will resort to guessing  the status 
of the slaves.

> It would be nice to have at say 5-10 minutes battery backup before sending 
> shutdown messages to the Linux machines.

When you take the 5-10 minutes of runtime and turn that into a requirement for 
battery capacity, it is worth considering what amount of reserve power you 
would want in case you need to briefly power up a machine during an extended 
outage. I would also recommend buying an UPS that allows you to adjust its low 
battery threshold in terms of estimated remaining runtime (and not just 
percentage of full charge), as this should prevent surprises later as the 
battery ages. (The UPS should keep track of changes in runtime for a given load 
as part of its periodic calibration, automatic or manual.) The NUT variable for 
this limit is "battery.runtime.low" (expressed in seconds).

This brings me to the Device Dump List: http://new.networkupstools.org/ddl/ (or 
http://networkupstools.org/ddl/ if the first link is not working). Because 
suggestions are an inherently subjective topic, we have some user-provided data 
dumps of the readable and read/write values provided by many UPS vendors. We 
also try to flag values that are problematic in some way (wrong scale factor, 
doesn't ever update, etc). Ideally, we would fix this in the driver, but in 
some cases, that can be difficult to fix without breaking something else.

A more subtle aspect of the DDL is that you can see how the underlying firmware 
changes over time for the same marketing model name. For instance, there are 
two versions of the Tripp-Lite OMNIVS1000 with different internals, and as 
such, slightly different feature sets. Feel free to ask about any of these 
results - the underlying DDL repository has some links back to the source of 
these reports. You can often find discussions for other devices in the 
nut-upsuser archives.



___
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 supporting Modbus TCP

[Charles Lepple]

On Jun 24, 2017, at 10:57 AM, Sergei Naumov wrote:

> I was wonering if there is a driver that supports communicating with a Modbus 
> aware device over IP. I have a solar/wind invertor that can broadcast its 
> state and I would like to monitor the batteries. If they discarge to a 
> certain voltage or come to a defined state, I would perform a shutdown. All 
> of this information id provided in Modbus holding registers. This could of 
> course be done placing a Modbus-to-SNMP gateway but they seem to be somewhat 
> pricey.

There is a GitHub issue tracking the general idea of a NUT MODBUS driver: 
https://github.com/networkupstools/nut/issues/50

The skeleton code on the referenced branch uses libmodbus, which as I 
understand, can communicate over TCP.

However, since you have a specific device in mind, you might be better served 
by creating a new driver based on the phoenixcontact_modbus driver (which also 
uses libmodbus): https://github.com/networkupstools/nut/pull/404 and 
https://github.com/networkupstools/nut/blob/7bd8971db89eec51fa55bbb75c8a54ca4a46e7dc/drivers/phoenixcontact_modbus.c

Do you have a datasheet or protocol document for this device?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] man pages and asciidoc (was: Device not supported?)

[Charles Lepple]

On Jun 23, 2017, at 10:28 PM, Manuel Wolfshant wrote:
> 
> Unfortunately they do not include any man pages, I did not have time to find 
> a workaround for the hard requirement of newer versions for the tools used by 
> the build process to create the man pages.

You have mentioned the man pages several times, and I am slightly confused.

If I grab a tarball from 
http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/master/nut-latest.tar.gz
 , the man pages are included. Are they not being installed if there is not a 
new-enough version of asciidoc available?

Also, how much of a version mismatch are we talking about? I don't remember all 
of the errors in the older versions that led us to add the version checks to 
configure.ac, but we can certainly look into them.

However, asciidoc is not difficult to upgrade. True, it has a lot of 
dependencies, but those dependencies apply equally to the earlier versions as 
well.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti  wrote:
> 
> "This TrippLite device (09ae:1330) is not (or perhaps not yet) supported by 
> usbhid-ups. [...]" 
> but my device (SU2200RTXLCD2U) is supported, as clearly state here.

No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB PID other than 
0001 is generally the protocol number. So your SU2200* model is different.

https://github.com/networkupstools/nut/issues/64

> Then I thought I needed the last src code (2.7.4), hence I built it for my 
> machine, but when I run it by:
> /usr/local/ups/sbin/upsdrvctl start 

The Protocol 1330 support was added after 2.7.4 was released. You might be able 
to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but voltages might 
be off by a factor of 10. You will also need to adjust the udev files manually 
to fix /dev/bus/usb permissions.

If you do choose to build using the latest source code from Git, be aware that 
you will need more tools, as specified in the Developer Guide: 
http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building

It may be easier to use the 2.7.4 tarball, and add the patch which introduces 
Protocol 1330 support to the RPM spec file: 
https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 20, 2017, at 6:00 AM, Manuel Wolfshant wrote:
> 
>On 06/20/2017 04:08 AM, Charles Lepple wrote:
>> [...]
>> It does not get a length for method 1, so it moves on to method 2, which 
>> gets a length, but fails to get the rest of the descriptor. This is what is 
>> happening to lsusb, too (tries to fetch 549 bytes, gets only 9).
> and is there anything I can do to fix, short of hoping to receive an updated 
> unbroken firmware for the UPS from a support team which ignores me ?

I can't speak for Eaton, but given what I have seen so far, the symptoms do not 
necessarily point to the UPS. If I search my copy of the NUT mailing lists for 
"lsusb" and "incomplete report descriptor", I see two cases of a Liebert GXT-3, 
one CyberPower PP1100, one older Tripp-Lite unit, and an APC Smart-UPS 1000.

That sample set is not large enough to isolate the problem to a specific 
kernel, distribution or motherboard. Hopefully Eaton has a larger set of data 
points.

>>> However I am using the very same package on my personal workstation (which 
>>> is also running CentOS 6 but has a whole lot of packages installed either 
>>> from 3rd party repos or built by me  ) since Fri 09 Jan 2015 (I needed it 
>>> for heimdall ) and I had zero issues so far.
>> Can you be more specific about this? What hardware are you testing libusbx 
>> 1.0.19 with?
> Gigabyte F2A88X-D3H with AMD A8-6600K works fine with heimdall which I used 
> to connect to a Samsung S2+ and now to a Samsung A3 (2016) . Some similar 
> board ( I do not recall exactly what model was it, could have been either 
> identical or DH3 which is basically the same motherboard with some minor 
> modifications) was used by my colleague from the IT support dept 2-3 years 
> ago with my phone as well. The packages that I have installed are :

Oh, I thought you meant that libusbx was working fine with another UPS.

I don't know whether the 5E1500I is a 1.5 Mbit/sec or 12 Mbit/sec device, but I 
suspect that the other USB devices you are testing are faster than that. (Bear 
in mind that 480 Mbit/sec generally uses a different host controller interface, 
and 5.0 Gbit/sec uses a different PHY layer as well.)



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

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 7:56 PM, Manuel Wolfshant wrote:
> 
> On 06/20/2017 02:27 AM, Charles Lepple wrote:
>> On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
>> 
>>> #lsusb -vvv -d 0463:
>>> 
>>> Bus 002 Device 012: ID 0463: MGE UPS Systems UPS
>>> 
>> ...
>> 
>>>   HID Device Descriptor:
>>>  bLength 9
>>>  bDescriptorType33
>>>  bcdHID   1.10
>>>  bCountryCode   33 US
>>>  bNumDescriptors 1
>>>  bDescriptorType34 Report
>>>  wDescriptorLength 549
>>>  Warning: incomplete report descriptor
>>>  Report Descriptor: (length is 9)
>>>Item(Main  ): (null), data=none
>>>Item(Main  ): (null), data=none
>>>Item(Main  ): (null), data=none
>>> 
>>> 
>> If I recall, this is equivalent to the usbhid-ups "method 2" approach to 
>> retrieving the descriptor. 
> 
> That's greek to me, I am completely unfamiliar to any of nut ( and its 
> drivers ) internals :) But if I can configure usbhid-ups in a different 
> manner which I did not spot from the docs, please point me to the correct 
> docs.

No configuration needed - the driver tries both methods:

  1.013273 HID descriptor length (method 1) -1
  1.013277 i=0, extra[i]=09, extra[i+1]=21
  1.013283 HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 25 02
  1.013287 HID descriptor length (method 2) 549
  1.013290 HID descriptor length 549
  1.013920 Unable to get Report descriptor: Broken pipe

It does not get a length for method 1, so it moves on to method 2, which gets a 
length, but fails to get the rest of the descriptor. This is what is happening 
to lsusb, too (tries to fetch 549 bytes, gets only 9).

> However I am using the very same package on my personal workstation (which is 
> also running CentOS 6 but has a whole lot of packages installed either from 
> 3rd party repos or built by me  ) since Fri 09 Jan 2015 (I needed it for 
> heimdall ) and I had zero issues so far.

Can you be more specific about this? What hardware are you testing libusbx 
1.0.19 with?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
> 
> #lsusb -vvv -d 0463:
> 
> Bus 002 Device 012: ID 0463: MGE UPS Systems UPS
...
>   HID Device Descriptor:
>  bLength 9
>  bDescriptorType33
>  bcdHID   1.10
>  bCountryCode   33 US
>  bNumDescriptors 1
>  bDescriptorType34 Report
>  wDescriptorLength 549
>  Warning: incomplete report descriptor
>  Report Descriptor: (length is 9)
>Item(Main  ): (null), data=none
>Item(Main  ): (null), data=none
>Item(Main  ): (null), data=none
> 
If I recall, this is equivalent to the usbhid-ups "method 2" approach to 
retrieving the descriptor. 


>> If not (lsusb returns "Report Descriptors:" / "** UNAVAILABLE **"), it seems 
>> like the two options are to upgrade the kernel (which I understand is an 
>> issue),
> 
> unfortunately it is. If mandatory I guess I can do some tricks with cron to 
> rollback a known good situation but given that I have no idea what failed 
> during the previous attempt ( nothing got logged -- I suspect a kernel panic 
> although I have no idea why would this happen ) I'd prefer to avoid, if 
> possible.
> 
> 
>>  or try to roll back the userspace tools to match what was current when the 
>> kernel was current.
>> 
> I am afraid I did not understand this part...

If there are newer kernels out there, it is possible that some of the userspace 
tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it possible to 
downgrade any of them, to test with package versions that were released at the 
same time as the 2.6.32 kernel?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 4:27 AM, Manuel Wolfshant wrote:
> 
>   1.014501 [D2] Unable to get HID descriptor (Pipe error)
>   1.014511 [D3] HID descriptor length (method 1) -1

So at this point in the logs, the kernel USB HID driver is detached from the 
UPS HID interface (until the UPS USB cable is unplugged and reattached). If you 
run "lsusb -vvv -d 0463:", does it print the HID report descriptor? 
(Normally, lsusb will only print descriptors for interfaces that are not 
claimed by a kernel driver or userspace library.)

If so, then it is worth checking to see how usbutils is talking to the UPS.

If not (lsusb returns "Report Descriptors:" / "** UNAVAILABLE **"), it seems 
like the two options are to upgrade the kernel (which I understand is an 
issue), or try to roll back the userspace tools to match what was current when 
the kernel was current.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 19, 2017, at 4:02 AM, Manuel Wolfshant wrote:
> On 06/18/2017 05:42 PM, Charles Lepple wrote:
>> On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant wrote:
>>> 
>>> running autogen.sh was triggered automatically. but even if I do it 
>>> explicitly, I still get:
>>> + autoreconf -i 
>>>  
>>> configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call 
>>> detected in body 
>>> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
>>>  
>>> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... 
>>>  
>>> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...  
>>>  
>>> /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded 
>>> from...  
>>> /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from...   
>>>  
>>> /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from...   
>>>  
>>> /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from...
>>>  
>>> /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from...   
>>>  
>>> /usr/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...  
>>>  
>>> configure.ac:887: the top level   
...
>> This sounds like an autotools incompatibility. Which versions of autoconf, 
>> automake, libtool, etc. are you using?
> As I am a packager for Fedora & EPEL I usually try to rely exclusively on the 
> tools of the distribution ( RHEL / CentOS 6 in this case). Otherwise the 
> packages would not be accepted as they could not be built using the official 
> builders which use exclusively packages available in the distribution itself. 
> In this particular case though I have updated some tools to versions from 
> RHEL7 or Fedora so I am using:
>> autoconf-2.69-23.el6.noarch ( instead of distro's 2.63 )
>> automake-1.11.1-4.el6.noarch
>> libtool-2.2.6-15.5.el6.x86_64
>> libtool-ltdl-devel-2.2.6-15.5.el6.x86_64
>> m4-1.4.16-10.el6.x86_64 ( instead of 1.4.13 )
> 
With the exception of libtool (I can never get the hang of libtool), I don't 
believe any of those packages are needed to compile from a tarball of NUT.

Looking at the backtrace, though, I think that NUT is only including 
AC_PROG_LIBTOOL, so it seems like that version of libtool and autoconf are not 
compatible. (On Fink, I am currently using autoconf-2.69 and libtool-2.4.6)

> - building against libusb 0.1 does not change in any way the situation, I 
> still get the same error related to lack of ability to claim the interface

At some point, we took out a call to usb_set_altinterface() - the kernel is 
supposed to activate bAlternateSetting=0 automatically, and re-selecting it 
caused problems on other platforms. Maybe it was required with Linux kernel 
2.6.x. With libusb-0.1 linked in, does "-x usb_set_altinterface=0" change 
anything?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Charles Lepple]

On Jun 16, 2017, at 6:12 AM, Manuel Wolfshant  wrote:
> 
> running autogen.sh was triggered automatically. but even if I do it 
> explicitly, I still get:
> + autoreconf -i   
>
> configure.ac:887: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body 
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...  
>
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...   
>
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
>
> /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded 
> from...  
> /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... 
>
> /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... 
>
> /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from...  
>
> /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... 
>
> /usr/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
>
> configure.ac:887: the top level   
>
> [ looong part of output deleted...]
> 
> configure.ac:1526: required file `scripts/augeas/nutupsconf.aug.in' not found
> configure.ac:1526: required file `scripts/devd/nut-usb.conf.in' not found
> configure.ac:1526: required file `scripts/udev/nut-usbups.rules.in' not found
> Makefile.am: installing `./INSTALL'
> autoreconf: automake failed with exit status: 1

This sounds like an autotools incompatibility. Which versions of autoconf, 
automake, libtool, etc. are you using?

In the mean time, Buildbot generates snapshots using "make dist" that do not 
require auto*. Since there have not been any recent builds, they aren't on the 
first page of the waterfall, but usually there is a link to the snapshot off of 
the Debian jessie builder when the branch is rebuilt.

Here is the generic URL: 
http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/nut-latest.tar.gz
 


If you need a specific version for the .spec file, that link currently points 
to 
http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/libusb-1.0/rb1314c693bef0ce639991dcee6e5742f25e94a88-753/nut-v2.7.4-418-gb1314c62.7.4.1.tar.gz
 

 (not a typo; the code that generates the version stuck in both 2.7.4 and 
2.7.4.1)___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 16, 2017, at 9:19 AM, Andrea de Lutti  wrote:
> 
> Thanks mates,
> as suggested I have added 
> 
> runtimecal = 240,100,720,50
> default.battery.voltage.low = 10.4
> default.battery.voltage.high = 13.8 (the actual charging voltage)
> 
> In ups.conf
> 
> I have also added the startup procedure in rc.local file, everything is 
> fine...
> I have only to make a deep test.

Glad that worked.

> Is there a way to add a NOTIFYMSG value for the battery test?

Do you mean a notification that a test is in progress, or something for the 
results?

There is the REPLBATT message in upsmon when the battery test fails, but I 
don't think the generic Qx protocol supports the RB status flag.

You could possibly trigger on the OB status and look for the CAL flag in 
ups.status as well, but I haven't tried to automate that.

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

Re: [Nut-upsuser] Help with Elite 800VA usb UPS (/var/run/nut on Ubuntu 16.04)

[Charles Lepple]

On Jun 11, 2017, at 8:10 AM, Andrea de Lutti  wrote:
> 
> What's the right procedure for loading driver/daemon at boot?
> I have read a lot about /var/run/nut missing, but haven't find any 
> solution

Your copy of /etc/init.d/nut-server should have the following lines:

# Check if /var/run/nut exists and has the correct perms
check_var_directory() {
  [ ! -d ${pid_dir} ] && mkdir -p ${pid_dir} \
&& chown root:nut ${pid_dir} \
&& chmod 770 ${pid_dir} \
&& [ -x /sbin/restorecon ] && /sbin/restorecon ${pid_dir}
}

This works on my Ubuntu 16.04 test system. I am using a PPA with some 
libusb-1.0 changes, but this particular file does not seem to have changed 
since Ubuntu 14.04 (looks like there is some systemd emulation of SysV-style 
init scripts for NUT on 16.04). Are you using systemd or upstart?
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 16, 2017, at 2:20 AM, Andrea de Lutti  wrote:
> Using 'guestimation' (low: -0.87, high: -1.08)!
> Initial battery charge undetermined
> Driver failed to start (exit status=1)

The "low" and "high" voltages should correspond to the battery voltage when it 
is discharged (LB) and charged, respectively. For a 12V (nominal) battery, they 
should not be less than zero :-)

There is a check for whether the nominal battery voltage is 1, but it should be 
looking for -1. (This has been fixed in nutdrv_qx, but was not backported to 
blazer*)

As Manuel suggested, you can use the "defaults.battery.voltage.low" and 
"defaults.battery.voltage.high" options in ups.conf - there is a bit of a 
chicken-and-egg problem here, but you can still put in approximate values (say, 
10.4 and 13.0) in order to run the calibration, and then adjust them to the 
actual reported values.



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

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 15, 2017, at 4:09 PM, Robbie van der Walle  
wrote:
> What is the purpose of Boolean:  SuccessfulExit?
> 
All I remember is the comment on the next line: 

 I did have to fiddle with permissions of config files - Fink currently 
 builds NUT to run as user "nobody", so I have the following non-default 
 permissions:
 
 $ ls -l /sw/etc/nut
 ...
 -rw-r-+ 1 root  nobody   2177 Jun 15 08:42 upsd.users
 -rw-r-+ 1 root  nobody  15455 Jun 15 08:50 upsmon.conf
> 
> /sw/etc/nut
> 
> -rw-r--r--   1 root  admin  12199 Jun 10 16:22 upsmon.conf
> 
> This are default permissions. 

Well, technically the Fink package doesn't install the *.conf files, just the 
*.conf.sample versions.
> 
> I# For best results, you should create a new normal user like "nutmon",
> # and make it a member of a "nut" group or similar.  Then specify it
> # here and grant read access to the upsmon.conf for that group.
> #
> # This user should not have write access to upsmon.conf.
> #
> # RUN_AS_USER nutmon
> 
> RUN_AS_USER root
> 
> For security reasons you should change root to another user? 
> 
> which other rights are needed for this user to make it work? 

Not a lot - upsmon keeps a copy around that runs as root (in order to execute 
the shutdown command), but it parses the files and network traffic under the 
lesser RUN_AS_USER privileges. So the Fink default of "nobody" could work, if 
you change the group of the configuration file as well. I don't know if many 
other processes in OS X use "nobody".

See http://networkupstools.org/docs/man/upsmon.html#_reloading_nuances and 
http://networkupstools.org/docs/man/upsmon.conf.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 15, 2017, at 10:31 AM, Robbie van der Walle  
wrote:
> 
> Did you change anything in the plist or used mine ?
> 

Copied and pasted from yours.

If you run "sudo /sw/sbin/upsmon -D" from the command line, does it exit 
immediately?

I did have to fiddle with permissions of config files - Fink currently builds 
NUT to run as user "nobody", so I have the following non-default permissions:

$ ls -l /sw/etc/nut
...
-rw-r-+ 1 root  nobody   2177 Jun 15 08:42 upsd.users
-rw-r-+ 1 root  nobody  15455 Jun 15 08:50 upsmon.conf

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

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 14, 2017, at 1:54 PM, Robbie van der Walle  
wrote:
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
> ">
> 
> 
> Label
> org.networkupstools.upsmon
> RunAtLoad
> 
> ProgramArguments
> 
> /sw/sbin/upsmon
> -D 
> 
> KeepAlive
> 
> SuccessfulExit
>  
> 
> 
> 
> 
> sudo launchctl load /Library/LaunchDaemons/org.networkupstools.upsmon.plist
> 
> Doesn’t return an error. But when I check of upsmon is running I don’t see it 
> running. 

This works for me on 10.12.5. (There is a warning that SuccessfulExit is an 
"unknown key" from launchd.)

$ sudo launchctl list|fgrep -v com.app
PID Status  Label
...
89810   org.networkupstools.upsmon
...

Does anything for upsmon show up in system.log in Console.app?___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 14, 2017, at 9:12 AM, Robbie van der Walle  
wrote:
> 
> But I cannot load it with the command: 
> 
> $ sudo launchctl load /Library/LaunchAgents/com.networkupstools.upsmon.plist
> 
> /Library/LaunchAgents/com.networkupstools.upsmon.plist: Invalid property list
> 

I will try to look into this later, but three quick things:

1) does the base filename need to match the Label key? com.network... vs 
org.network...

2) maybe it doesn't like the comments (between "")?

3) should only need to go in /Library/LaunchDaemons  (LaunchAgents is to make 
it run at login, rather than system startup.)___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 11, 2017, at 7:15 AM, Robbie van der Walle  
wrote:
> 
> I see only a reboot. Not a shutdown.  But is this normal because shutdown -u 
> -h +0 is used? 
> 
To be honest, I haven't experimented much with this, but I saw a normal 
shutdown/reboot when I just tried this from the command line (10.12):

reboot~ Mon Jun 12 08:36 
shutdown  ~ Mon Jun 12 08:35 
clepple   ttys007   Sun Jun  4 21:52 - shutdown (7+10:43)

However, the "-u" flag did not seem to keep the Mac running for long after the 
shutdown (certainly seemed shorter than five minutes).

Maybe I can test this on another machine with the full NUT stack later.

Thanks for posting the osascript example - that looks useful!
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 9, 2017, at 4:47 AM, Robbie van der Walle  wrote:
> 
>> Under System Preferences, Energy Saver, there is a setting Start up 
>> automatically after a power failure. 
>> Running sudo pmset  -a autorestart 1 does the same trick. 
> 
> But unfortunately Mac stays . Step 7 
> 

You might want to save off the output of "pmset -g" before experimenting 
further - that way, after you find a solution, you can run it again to see what 
changed.

This page implies that the "sudo" and "-a" are not needed:

   
http://www.virtuallyghetto.com/2013/02/enable-auto-startup-after-power-failure.html

Also potentially useful, though I can't imagine it is changing different 
settings under the hood:

   
https://macminicolo.net/blog/files/Be-sure-your-Mac-mini-will-restart-automatically-when-needed.html

Alternatively, on 10.12 and 10.11, there is a "-u" option to shutdown:

 -u  The system is halted up until the point of removing system power, 
but waits before removing power for 5 minutes so that an external UPS 
(uninterruptible power supply) can forcibly remove power.  This simulates a 
dirty shutdown to permit a later automatic power on. OS X uses this mode 
automatically with supported UPSs in emergency shutdowns.

Let us know what works. (I have NUT set up on a Mac Mini, but we do not get 
frequent power outages, and the machine is set to wake up on a schedule anyway.)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 8, 2017, at 4:06 PM, Robbie van der Walle  wrote:
> 
> 7. No they didn’t restart. I know there is a setting on the NAS to activate 
> this. I will check and try again. 

Not sure for the NAS, but for the Mac, it is probably something like this:

   sudo pmset -a autorestart 1

There is also usually a checkbox in the Energy Saver panel in the System 
Preferences GUI.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 8, 2017, at 9:15 AM, Andrea de Lutti  wrote:
> 
> Thank you for your reply Charles,
> this is the "upsc" result:
> 
> root@artu:~# upsc ups@localhost
> Init SSL without certificate database
> Error: Unknown UPS
> 
Use the name from ups.conf in front of "@localhost".

> Trying with nutdrv_qx, protocol megatec the driver does not start...
> 
What if you try nutdrv_qx without specifying megatec? (It should autodetect.)

If that doesn't work, please try to get some logs - they will look like this:

   http://lists.alioth.debian.org/pipermail/nut-upsuser/2017-March/010555.html

The author of the driver recommends a debug level of 5: "-D"

(Note that we are not looking for the debug output for upsdrvctl, but rather 
for nutdrv_qx. If you pass "-D" flags to upsdrvctl, it should tell you how to 
start the driver in debug mode instead.)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Apple Mac slave

[Charles Lepple]

On Jun 7, 2017, at 1:14 PM, Roger Price wrote:
> 
> 2. On the NAS, use command
> 
>   upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS

Robbie,

The "upsrw" command contacts upsd, so it sounds like you should be able to add 
a user to upsd.users on the NAS, and then run something like this on the Mac:

   upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS@synology

Per http://networkupstools.org/docs/man/upsd.users.html , the "upsmaster" user 
would need at least "actions = SET". You will need to reload upsd after 
changing upsd.users.

If the UPS is not turning itself off after the NAS goes into safe mode, it 
might be possible to do this from the Mac. You probably have something like 
this in the Mac's upsmon.conf:

   SHUTDOWNCMD "/sbin/shutdown -h +0"

You could add an UPS shutdown command before the Mac shutdown command:

   upscmd -u upsmaster -s sekret UPS@synology shutdown.stayoff

but you would need to be sure that the UPS shutdown delay is long enough to 
allow the NAS to go into safe mode. (This is why it is recommended that the 
master (the NAS in your case) initiate the UPS shutdown.) Also, you would need 
to configure that NUT user to allow instant commands in upsd.users as well as 
upsrw access.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jun 7, 2017, at 12:54 AM, Andrea de Lutti  wrote:
> 
> 
> Hi, I have tried several drivers for make my Elite UPS working.
> With blazer_usb I can contact it, but I have no informations. This is the 
> best result.
> 
> OS: Ubuntu Xenial 16.04.2 LTS
> NUT Version: Nut 2.7.2-4Ubuntu1 (Installed from Ubuntu Software Center)
> Device name: Elite UPS 800VA (http://www.elit-ups.com/ita/pro_ups.html, 
> discontinued) I can provider their *not working* linux monitoring tool
> 
> Here is the result from starting upsdrvctl
> root@artu:~# 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
> Rating information unavailable
> Vendor information unavailable
> No values provided for battery high/low voltages in ups.conf
> 
> Using 'guestimation' (low: -0.87, high: -1.08)!
> Battery runtime will not be calculated (runtimecal not set)

What does "upsc" show for this UPS?

Note that the blazer_usb driver is no longer maintained. Its replacement is 
nutdrv_qx:

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