Nut upsdev - Jun 2017 - New data for the Device Dump List

People,

A couple of decades before I was retired and was still working for other 
people I had cause to install UPSs and they usually had RS232 ports to 
allow the setting up of shutdown scripts to UNIX / Linux servers.  Now, 
after not having to be concerned by those issues for some time - most of 
my little web sites have been on Digital Ocean or other suppliers VMs 
for a long time - I am shutting down my DO servers and bringing my sites 
in-house.  However, now I need to be concerned about reliable power 
again so I have spent a bit of time looking at options and I don't 
understand why most of the UPS offerings available do not come standard 
with a LAN port?  Why is this?

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.  It would be nice to have at say 5-10 minutes battery 
backup before sending shutdown messages to the Linux machines.

Thanks,

Phil.
-- 
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil at pricom.com.au

I'll guess expense, and possibly inherent unreliability in that there is
more than a passive interconnect to the server. Having said that, higher end
gear appears far more likely to have a LAN port or capability thereof . . . the
cheap hope stuff does not, considering that it likely would not see much use. In
any case, NUT server mode pretty well negates any need . . . at least in my
experience . . .

On June 25, 2017 7:53:08 AM CDT, Philip Rhoades <phil at pricom.com.au>
wrote:
>People,
>
>A couple of decades before I was retired and was still working for
>other 
>people I had cause to install UPSs and they usually had RS232 ports to 
>allow the setting up of shutdown scripts to UNIX / Linux servers.  Now,
>
>after not having to be concerned by those issues for some time - most
>of 
>my little web sites have been on Digital Ocean or other suppliers VMs 
>for a long time - I am shutting down my DO servers and bringing my
>sites 
>in-house.  However, now I need to be concerned about reliable power 
>again so I have spent a bit of time looking at options and I don't 
>understand why most of the UPS offerings available do not come standard
>
>with a LAN port?  Why is this?
>
>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.  It would be nice to have at say 5-10 minutes battery 
>backup before sending shutdown messages to the Linux machines.
>
>Thanks,
>
>Phil.
>-- 
>Philip Rhoades
>
>PO Box 896
>Cowra  NSW  2794
>Australia
>E-mail:  phil at pricom.com.au
>
>_______________________________________________
>Nut-upsuser mailing list
>Nut-upsuser at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170625/fdd8afc0/attachment.html>

Hi Phil,

I don't have an answer to your question about the lack of LAN ports, but
can offer my experience with NUT for a home server environment.  I've
tended to prefer the Tripp-Lite UPS systems, mainly because I originally
felt they did a good job of power filtering.  I use a NUT master running on
a Raspberry Pi 3 which is easy to maintain and gets current updates via its
Debian roots.  I have two environments, one with a much older UPS which has
only serial, but the addition of a tiny card with a MAX3232 level-shifter
https://www.sparkfun.com/products/11189 allows the RPi to communicate
nicely, the second environment uses a USB connection from the RPi to the
UPS.  Both work very well with NUT, and then communicate with NUT clients
on the other systems.  I like that the RPi allows me to separate the NUT
master function from the main virtualization hosts, currently CentOS/KVM in
this case.

The real key is to ensure NUT supports the UPS, and then from there an
effort to use currently supported versions of NUT on a platform which is
receiving updates & life is quite good.

--Larry

On Sun, Jun 25, 2017 at 7:53 AM, Philip Rhoades <phil at pricom.com.au>
wrote:
> People,
>
> A couple of decades before I was retired and was still working for other
> people I had cause to install UPSs and they usually had RS232 ports to
> allow the setting up of shutdown scripts to UNIX / Linux servers.  Now,
> after not having to be concerned by those issues for some time - most of my
> little web sites have been on Digital Ocean or other suppliers VMs for a
> long time - I am shutting down my DO servers and bringing my sites
> in-house.  However, now I need to be concerned about reliable power again
> so I have spent a bit of time looking at options and I don't understand
why
> most of the UPS offerings available do not come standard with a LAN port?
> Why is this?
>
> 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.  It would be nice to have at say 5-10 minutes battery backup
> before sending shutdown messages to the Linux machines.
>
> Thanks,
>
> Phil.
> --
> Philip Rhoades
>
> PO Box 896
> Cowra  NSW  2794
> Australia
> E-mail:  phil at pricom.com.au
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>


-- 
Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
           Minneapolis, Minnesota       www.FahnoeTech.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170625/bbdc3b82/attachment.html>

Larry,


On 2017-06-25 23:26, Larry Fahnoe wrote:
> Hi Phil,
> 
> I don't have an answer to your question about the lack of LAN ports,

I think it is weird - with everything else being connected to LANs like 
fridges etc . . why not UPSs?

> but can offer my experience with NUT for a home server environment.
> I've tended to prefer the Tripp-Lite UPS systems, mainly because I
> originally felt they did a good job of power filtering.  I use a NUT
> master running on a Raspberry Pi 3 which is easy to maintain and gets
> current updates via its Debian roots.

Ah . . another good reason to get a RPi going . .

> I have two environments, one
> with a much older UPS which has only serial, but the addition of a
> tiny card with a MAX3232 level-shifter
> https://www.sparkfun.com/products/11189 allows the RPi to communicate
> nicely, the second environment uses a USB connection from the RPi to
> the UPS.  Both work very well with NUT, and then communicate with NUT
> clients on the other systems.  I like that the RPi allows me to
> separate the NUT master function from the main virtualization hosts,
> currently CentOS/KVM in this case.

Yes, good idea . .

> The real key is to ensure NUT supports the UPS, and then from there an
> effort to use currently supported versions of NUT on a platform which
> is receiving updates & life is quite good.

Yes, good point - which is why I came here!

Thanks,

Phil.

> --Larry
> 
> On Sun, Jun 25, 2017 at 7:53 AM, Philip Rhoades <phil at
pricom.com.au>
> wrote:
> 
>> People,
>> 
>> A couple of decades before I was retired and was still working for
>> other people I had cause to install UPSs and they usually had RS232
>> ports to allow the setting up of shutdown scripts to UNIX / Linux
>> servers.  Now, after not having to be concerned by those issues for
>> some time - most of my little web sites have been on Digital Ocean
>> or other suppliers VMs for a long time - I am shutting down my DO
>> servers and bringing my sites in-house.  However, now I need to be
>> concerned about reliable power again so I have spent a bit of time
>> looking at options and I don't understand why most of the UPS
>> offerings available do not come standard with a LAN port?  Why is
>> this?
>> 
>> 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.  It would be nice to have at say 5-10
>> minutes battery backup before sending shutdown messages to the Linux
>> machines.
>> 
>> Thanks,
>> 
>> Phil.
>> --
>> Philip Rhoades
>> 
>> PO Box 896
>> Cowra  NSW  2794
>> Australia
>> E-mail:  phil at pricom.com.au
>> 
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>> [1]
> 
> --
> 
> Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
>            Minneapolis, Minnesota       www.FahnoeTech.com [2]
> 
> Links:
> ------
> [1] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
> [2] http://www.FahnoeTech.com
-- 
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil at pricom.com.au

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.

Charles,


On 2017-06-26 03:43, Charles Lepple wrote:
> 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.

Wow!  Thanks for all of that!  I will start looking at it all . .

Regards,

Phil.
-- 
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil at pricom.com.au

On 06/25/2017 08:43 PM, Charles Lepple wrote:
>
> 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).
I am providing below two dumps for one UPS which is already in the list 
but taken when I was using an old version of nut, as well as one for 
Guardian LCD 1500 AP ( IGA1500LCD ) which is not in your list at all ( 
see 
https://lists.alioth.debian.org/pipermail/nut-upsuser/2017-January/010493.html 
as well when I first reported about it )

a) Ablerex MARS MS3000RT
battery.charge: 100
battery.voltage: 108.48
battery.voltage.high: 104.00
battery.voltage.low: 83.20
battery.voltage.nominal: 96.0
device.mfr: Ablerex
device.model: MS3000RT
device.type: ups
driver.name: blazer_ser
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyUSB0
driver.version: 2.7.2
driver.version.internal: 1.56
input.current.nominal: 14.0
input.frequency: 50.0
input.frequency.nominal: 50
input.voltage: 230.6
input.voltage.fault: 190.0
input.voltage.nominal: 220
output.voltage: 220.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: MS02035C
ups.load: 60
ups.mfr: Ablerex
ups.model: MS3000RT
ups.status: OL
ups.temperature: 38.2
ups.type: online


b)Guardian LCD 1500 AP ( IGA1500LCD ) ( more info including the config I 
use is in my older message about this UPS )

battery.charge: 100
battery.runtime: 1200
battery.voltage: 27.70
battery.voltage.high: 27.7
battery.voltage.low: 21.2
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productID: 0000
driver.parameter.protocol: q1
driver.parameter.runtimecal: 120,100,480,50
driver.parameter.synchronous: no
driver.parameter.vendorid: 0001
driver.version: 2.7.4
driver.version.data: Q1 0.07
driver.version.internal: 0.28
input.frequency: 50.0
input.voltage: 231.3
input.voltage.fault: 231.3
output.voltage: 231.3
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 10
ups.productid: 0000
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0001