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
