Thanks for the quick response! On Sat, Jun 27, 2020, at 22:17, Manuel Wolfshant wrote:> On 6/28/20 4:25 AM, Scott Colby wrote: > > Hello, > > > > I am having difficulty using NUT to shut down my Netgate SG-1100 > > (a pfSense router) when the power level of the UPS gets critically > > low. > > > > Here is some relevant information: > > - OS: pfSense 2.4.5-RELEASE-p1 (FreeBSD 11.3-STABLE) > > - NUT version: 2.7.4 > > - Installed from: pfSense package 2.7.4_7 > > - UPS: AVR750U (Device release number 2) > > - I have included my config files, output from `upsc`, and output > > from running the driver in debug mode at the bottom of this message. > > > > To get this UPS to work with NUT, I had to create a custom devd > > rule: > > # cat /usr/local/etc/devd/nut-usb-custom.conf > > notify 100 { > > match "system" "USB"; > > match "subsystem" "DEVICE"; > > match "type" "ATTACH"; > > match "vendor" "0x09ae"; > > match "product" "0x3024"; # difference from default config here > > action "chgrp uucp /dev/$cdev; chmod g+rw /dev/$cdev"; > > }; > > It seems like my particular AVR750U has a different product id than > > the one that came in the package at /usr/local/etc/nut-usb.conf, > > which has a similar rule entry but with product id 0x1007. I'm not > > sure if this is a package maintainer issue or a NUT isue. > > Manufacturers change product IDs over time. Both nut as product and the > various packages shipped by unix distributions need to adjust according > to those changes > > > > > > > I unplugged the UPS from the mains power and let it run down. The > > battery level and time remaining numbers seemed to update correctly > > during this, but when the battery got down to 1% and showed less > > than one minute of time remaining, NUT still hadn't shut down the > > device--I chickened out and plugged it back in. Following the advice > > from usbhid-ups(8), I ran `upsmon -c fsd` which properly brought > > the system down but did not power cycle the UPS. > > > > I am a little unclear on what actually causes NUT to issue the > > shutdown command. I've read something about the "low power flag:" > > is that something that the UPS decides on? > > Indeed, the UPS sends a specific flag ( LB == low battery ) when it > believes that the battery is depleted below a specific level. How nut > behaves depends on the actual configuration, as a few other variables > are also taken into account. > > > > > > Have I made a configuration error? > > yes, I think that you did a small error. see below > > > > Do I need to set some configuration > > on the UPS with `upsrw` or something? Do I need to use Tripp Lite's > > Windows software to configure something before using it with NUT? > > Is this a new version of the AVR750U that's not compatible yet with > > NUT? > > no, no and no. > > > > > > Thank you for your attention to my questions, > > Scott > > > > > > # cat nut.conf > > MODE=none > > According to the documentation included in the nut.conf file ( at least > in linux.. ), you should change this line to > > MODE=standalone > > because "none" means nut is not yet configured and prohibits it from > even starting . You can of course use "netserver" instead if you plan to > power down more servers that will talk with the one which is actually > connected to the UPS. Do not forget to start the services after > modifying the config file > > Here is a quote from the content of that file from a linux box: > > # The values of MODE can be: > # - none: NUT is not configured, or use the Integrated Power Management, > or use > # some external system to startup NUT components. So nothing is to be > started. > # - standalone: This mode address a local only configuration, with 1 UPS > # protecting the local system. This implies to start the 3 NUT layers > (driver, > # upsd and upsmon) and the matching configuration files. This mode can > also > # address UPS redundancy. > # - netserver: same as for the standalone configuration, but also need > # some more network access controls (firewall, tcp-wrappers) and > possibly a > # specific LISTEN directive in upsd.conf. > # Since this MODE is opened to the network, a special care should be > applied > # to security concerns. > # - netclient: this mode only requires upsmon > >I'm not convinced this is the problem; I think that pfSense has an alternative way of running the NUT components: # ps aux | grep ups root 45456 0.0 0.1 6796 884 - Is 02:22 0:00.01 /usr/local/sbin/upsmon uucp 45751 0.0 0.1 6796 772 - S 02:22 0:00.10 /usr/local/sbin/upsmon uucp 46796 0.0 0.1 6888 888 - Ss 02:22 0:00.45 /usr/local/libexec/nut/usbhid-ups -a AVR750U root 56752 0.0 0.1 6788 832 - Ss 02:22 0:00.13 /usr/local/sbin/upsd -u root root 39437 0.0 0.2 6828 2464 0 S+ 02:46 0:00.01 grep ups Is there anything else that should be running? Would you expect `upsmon -c fsd` to not work as I described above (system halting but UPS not power cycling) if MODE was set to none but upsmon, the driver, and upsd were running?> > > > > # cat ups.conf > > [AVR750U] > > driver=usbhid-ups > > port=auto > > productid=3024 > > > > # cat upsmon.conf > > MONITOR AVR750U 1 local-monitor <password> master > > SHUTDOWNCMD "/sbin/shutdown -p +0" > > POWERDOWNFLAG /etc/killpower > > NOTIFYCMD /usr/local/pkg/nut/nut_email.php > > NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC > > NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC > > NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC > > NOTIFYFLAG FSD SYSLOG+WALL+EXEC > > NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC > > NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC > > NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC > > NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC > > NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC > > NOTIFYFLAG NOPARENT SYSLOG+WALL+EXEC > > > > # upsc AVR750U > > battery.charge: 100 > > battery.charge.warning: 30 > > battery.runtime: 3649 > > battery.type: PbAc > > battery.voltage: 0.0 > > battery.voltage.nominal: 12.0 > > device.mfr: Tripp Lite > > device.model: AVR750U > > device.serial: 2945CVLOM87C901526 > > device.type: ups > > driver.name: usbhid-ups > > driver.parameter.pollfreq: 30 > > driver.parameter.pollinterval: 2 > > driver.parameter.port: auto > > driver.parameter.productid: 3024 > > driver.parameter.synchronous: no > > driver.version: 2.7.4 > > driver.version.data: TrippLite HID 0.82 > > driver.version.internal: 0.41 > > input.frequency: 5990.0 > > This value is definitely incorrectly reported. Based on the voltages > below I assume you are in USA and the displayed value could be an > incorrectly scaled 59.9 Hz > >You are correct about my location and expected voltage. Is there somewhere that I can change the scaling factor used by NUT?> > > input.transfer.high: 145.0 > > input.transfer.low: 89.0 > > input.voltage: 0.0 > > input.voltage.nominal: 120 > > output.current: 0.0 > > output.frequency: 5990.0 > > As above, I guess this should actually be 59.9 Hz > > > > output.frequency.nominal: 60 > > output.voltage: 0.0 > > output.voltage.nominal: 120 > > ups.beeper.status: muted > > ups.delay.shutdown: 20 > > ups.delay.start: 30 > > ups.load: 0 > > ups.mfr: Tripp Lite > > ups.model: AVR750U > > ups.power: 0.0 > > ups.power.nominal: 750 > > ups.productid: 3024 > > ups.serial: 2945CVLOM87C901526 > > ups.status: OL > > ups.timer.reboot: 65535 > > ups.timer.shutdown: 65535 > > ups.timer.start: 65535 > > ups.vendorid: 09ae > > ups.watchdog.status: 0 > > > > # /usr/local/libexec/nut/usbhid-ups -DD -a AVR750U > > Network UPS Tools - Generic HID driver 0.41 (2.7.4) > > USB communication driver 0.33 > > 0.000000 debug level is '2' > > 0.001637 upsdrv_initups... > > 0.002374 Checking device (09AE/3024) (/dev/usb//dev/ugen1.2) > > 0.014968 - VendorID: 09ae > > 0.015020 - ProductID: 3024 > > 0.015031 - Manufacturer: Tripp Lite > > 0.015041 - Product: AVR750U > > 0.015052 - Serial Number: 2945CVLOM87C901526 > > 0.015061 - Bus: /dev/usb > > 0.015071 - Device release number: 0002 > > 0.015084 Trying to match device > > 0.015265 Device matches > > 0.016003 HID descriptor length 885 > > 0.020119 Report Descriptor size = 885 > > 0.021057 Using subdriver: TrippLite HID 0.82 > > 0.021116 87 HID objects found > > 0.022059 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x28, Offset: 0, Size: 8, Value: 1 > > 0.023013 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID: 0x29, Offset: 0, Size: 8, Value: 5 > > 0.024007 Path: UPS.PowerSummary.iManufacturer, Type: Feature, ReportID: 0x2b, Offset: 0, Size: 8, Value: 3 > > 0.025006 Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, ReportID: 0x30, Offset: 0, Size: 8, Value: 120 > > 0.025997 Path: UPS.PowerSummary.Input.Voltage, Type: Feature, ReportID: 0x31, Offset: 0, Size: 16, Value: 0.001233 > > 0.027006 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, ReportID: 0x11, Offset: 0, Size: 8, Value: 3 > > 0.027995 Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Feature, ReportID: 0x32, Offset: 7, Size: 1, Value: 0 > > 0.028034 Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Input, ReportID: 0x32, Offset: 7, Size: 1, Value: 0 > > 0.028059 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Feature, ReportID: 0x32, Offset: 9, Size: 1, Value: 0 > > 0.028084 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Input, ReportID: 0x32, Offset: 9, Size: 1, Value: 0 > > 0.028138 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x32, Offset: 16, Size: 1, Value: 1 > > 0.028164 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x32, Offset: 16, Size: 1, Value: 1 > > 0.028188 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Input, ReportID: 0x32, Offset: 18, Size: 1, Value: 0 > > 0.028212 Path: UPS.PowerSummary.PresentStatus.FullyCharged, Type: Input, ReportID: 0x32, Offset: 19, Size: 1, Value: 1 > > 0.028237 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input, ReportID: 0x32, Offset: 20, Size: 1, Value: 0 > > 0.028262 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Input, ReportID: 0x32, Offset: 21, Size: 1, Value: 0 > > 0.028286 Path: UPS.PowerSummary.PresentStatus.FullyDischarged, Type: Input, ReportID: 0x32, Offset: 22, Size: 1, Value: 0 > > 0.028310 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Input, ReportID: 0x32, Offset: 23, Size: 1, Value: 0 > > 0.028333 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, ReportID: 0x32, Offset: 18, Size: 1, Value: 0 > > 0.028357 Path: UPS.PowerSummary.PresentStatus.FullyCharged, Type: Feature, ReportID: 0x32, Offset: 19, Size: 1, Value: 1 > > 0.028383 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x32, Offset: 20, Size: 1, Value: 0 > > 0.028407 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID: 0x32, Offset: 21, Size: 1, Value: 0 > > 0.028430 Path: UPS.PowerSummary.PresentStatus.FullyDischarged, Type: Feature, ReportID: 0x32, Offset: 22, Size: 1, Value: 0 > > 0.028454 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Feature, ReportID: 0x32, Offset: 23, Size: 1, Value: 0 > > 0.029017 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x2a, Offset: 0, Size: 8, Value: 4 > > 0.030035 Path: UPS.PowerSummary.iOEMInformation, Type: Feature, ReportID: 0x62, Offset: 0, Size: 8, Value: 2 > > 0.030999 Path: UPS.PowerSummary.CapacityMode, Type: Feature, ReportID: 0x33, Offset: 0, Size: 8, Value: 2 > > 0.031992 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID: 0x34, Offset: 0, Size: 8, Value: 100 > > 0.032029 Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, ReportID: 0x34, Offset: 0, Size: 8, Value: 100 > > 0.033026 Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature, ReportID: 0x37, Offset: 0, Size: 8, Value: 100 > > 0.034014 Path: UPS.PowerSummary.DesignCapacity, Type: Feature, ReportID: 0x36, Offset: 0, Size: 8, Value: 100 > > 0.035013 Path: UPS.PowerSummary.WarningCapacityLimit, Type: Feature, ReportID: 0x38, Offset: 0, Size: 8, Value: 30 > > 0.035995 Path: UPS.PowerSummary.Rechargeable, Type: Feature, ReportID: 0x2c, Offset: 0, Size: 8, Value: 1 > > 0.037002 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID: 0x35, Offset: 0, Size: 16, Value: 3650 > > 0.037045 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID: 0x35, Offset: 0, Size: 16, Value: 3650 > > 0.038032 Path: UPS.BatterySystem.Battery.ConfigVoltage, Type: Feature, ReportID: 0x04, Offset: 0, Size: 16, Value: 12 > > 0.038999 Path: UPS.BatterySystem.Battery.Voltage, Type: Feature, ReportID: 0x20, Offset: 0, Size: 16, Value: 0.000137 > > 0.040012 Path: UPS.BatterySystem.Battery.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, ReportID: 0x23, Offset: 2, Size: 1, Value: 0 > > 0.040243 Path: UPS.BatterySystem.Battery.PresentStatus.FullyCharged, Type: Feature, ReportID: 0x23, Offset: 3, Size: 1, Value: 1 > > 0.040273 Path: UPS.BatterySystem.Battery.PresentStatus.Charging, Type: Feature, ReportID: 0x23, Offset: 4, Size: 1, Value: 0 > > 0.040298 Path: UPS.BatterySystem.Battery.PresentStatus.Discharging, Type: Feature, ReportID: 0x23, Offset: 5, Size: 1, Value: 0 > > 0.040321 Path: UPS.BatterySystem.Battery.PresentStatus.FullyDischarged, Type: Feature, ReportID: 0x23, Offset: 6, Size: 1, Value: 0 > > 0.040345 Path: UPS.BatterySystem.Battery.PresentStatus.NeedReplacement, Type: Feature, ReportID: 0x23, Offset: 7, Size: 1, Value: 0 > > 0.041012 Path: UPS.BatterySystem.Battery.RemainingCapacity, Type: Feature, ReportID: 0x21, Offset: 0, Size: 8, Value: 100 > > 0.042012 Path: UPS.BatterySystem.Battery.Test, Type: Feature, ReportID: 0x10, Offset: 0, Size: 8, Value: 6 > > 0.043020 Path: UPS.Flow.ConfigVoltage, Type: Feature, ReportID: 0x01, Offset: 0, Size: 8, Value: 120 > > 0.044002 Path: UPS.Flow.ConfigFrequency, Type: Feature, ReportID: 0x02, Offset: 0, Size: 8, Value: 60 > > 0.045016 Path: UPS.Flow.ffff0097, Type: Feature, ReportID: 0x55, Offset: 0, Size: 8, Value: 2 > > 0.046012 Path: UPS.Flow.ConfigApparentPower, Type: Feature, ReportID: 0x03, Offset: 0, Size: 16, Value: 750 > > 0.047000 Path: UPS.PowerConverter.Input.Voltage, Type: Feature, ReportID: 0x18, Offset: 0, Size: 16, Value: 0.001233 > > 0.048042 Path: UPS.PowerConverter.Input.Frequency, Type: Feature, ReportID: 0x19, Offset: 0, Size: 16, Value: 5990 > > So the UPS reports a frequency which nut should scale ... > > > > > > 0.049011 Path: UPS.PowerConverter.Output.Voltage, Type: Feature, ReportID: 0x1b, Offset: 0, Size: 16, Value: 0.001233 > > 0.050013 Path: UPS.PowerConverter.Output.Frequency, Type: Feature, ReportID: 0x1c, Offset: 0, Size: 16, Value: 5990 > > Again , scaling error... > > > > > 0.050996 Path: UPS.PowerConverter.Output.Current, Type: Feature, ReportID: 0x46, Offset: 0, Size: 16, Value: 0 > > [...] > > 0.083217 Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, ReportID: 0x30, Offset: 0, Size: 8, Value: 120 > > 0.083281 Path: UPS.PowerSummary.Input.Voltage, Type: Feature, ReportID: 0x31, Offset: 0, Size: 16, Value: 0.001233 > > 0.083375 Path: UPS.PowerConverter.Input.Frequency, Type: Feature, ReportID: 0x19, Offset: 0, Size: 16, Value: 5990 > > and again... > > > > 0.083451 Path: UPS.PowerConverter.Output.LowVoltageTransfer, Type: Feature, ReportID: 0x06, Offset: 0, Size: 16, Value: 89 > > 0.083579 Path: UPS.PowerConverter.Output.HighVoltageTransfer, Type: Feature, ReportID: 0x09, Offset: 0, Size: 16, Value: 145 > > 0.083698 Path: UPS.Flow.ConfigVoltage, Type: Feature, ReportID: 0x01, Offset: 0, Size: 8, Value: 120 > > 0.083761 Path: UPS.PowerConverter.Output.Voltage, Type: Feature, ReportID: 0x1b, Offset: 0, Size: 16, Value: 0.001233 > > 0.083847 Path: UPS.PowerConverter.Output.Current, Type: Feature, ReportID: 0x46, Offset: 0, Size: 16, Value: 0 > > 0.083909 Path: UPS.Flow.ConfigFrequency, Type: Feature, ReportID: 0x02, Offset: 0, Size: 8, Value: 60 > > 0.084153 Path: UPS.PowerConverter.Output.Frequency, Type: Feature, ReportID: 0x1c, Offset: 0, Size: 16, Value: 5990 > > and again > > > wolfy > > >Thanks, Scott
Manuel Wolfshant
2020-Jun-28 03:11 UTC
[Nut-upsuser] AVR750U Low Power not Triggering Shutdown
On 6/28/20 5:54 AM, Scott Colby wrote:> > I'm not convinced this is the problem; I think that pfSense has > an alternative way of running the NUT components: > # ps aux | grep ups > root 45456 0.0 0.1 6796 884 - Is 02:22 0:00.01 /usr/local/sbin/upsmon > uucp 45751 0.0 0.1 6796 772 - S 02:22 0:00.10 /usr/local/sbin/upsmon > uucp 46796 0.0 0.1 6888 888 - Ss 02:22 0:00.45 /usr/local/libexec/nut/usbhid-ups -a AVR750U > root 56752 0.0 0.1 6788 832 - Ss 02:22 0:00.13 /usr/local/sbin/upsd -u root > root 39437 0.0 0.2 6828 2464 0 S+ 02:46 0:00.01 grep ups > > Is there anything else that should be running?AFAIK, no, those 3 daemons should do the job. But just for the fun of it, I would test changing that variable anyway. There is nothing to lose, after all.> > Would you expect `upsmon -c fsd` to not work as I described above > (system halting but UPS not power cycling) if MODE was set to none > but upsmon, the driver, and upsd were running?If it is running ( i.e. started ) -c fsd should trigger an immediate shutdown. quote from man upsmon: *-c* /command/ Send the command /command/ to the existing upsmon process. Valid commands are: *fsd* shutdown all master UPSes (use with caution)>>> # cat ups.conf >>> [AVR750U] >>> driver=usbhid-ups >>> port=auto >>> productid=3024 >>> >>> # cat upsmon.conf >>> MONITOR AVR750U 1 local-monitor <password> master >>> [...] >>> driver.version.internal: 0.41 >>> input.frequency: 5990.0 >> This value is definitely incorrectly reported. Based on the voltages >> below I assume you are in USA and the displayed value could be an >> incorrectly scaled 59.9 Hz >> >> > You are correct about my location and expected voltage. Is there > somewhere that I can change the scaling factor used by NUT? > >not that I know of. and https://networkupstools.org/docs/man/usbhid-ups.html does not show any either. fortunately the errors are purely cosmetic -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200628/092f8f1c/attachment.html>
On Sat, Jun 27, 2020, at 23:11, Manuel Wolfshant wrote:> On 6/28/20 5:54 AM, Scott Colby wrote: >> >> I'm not convinced this is the problem; I think that pfSense hasan alternative way of running the NUT components: # ps aux | grep ups root 45456 0.0 0.1 6796 884 - Is 02:22 0:00.01 /usr/local/sbin/upsmon uucp 45751 0.0 0.1 6796 772 - S 02:22 0:00.10 /usr/local/sbin/upsmon uucp 46796 0.0 0.1 6888 888 - Ss 02:22 0:00.45 /usr/local/libexec/nut/usbhid-ups -a AVR750U root 56752 0.0 0.1 6788 832 - Ss 02:22 0:00.13 /usr/local/sbin/upsd -u root root 39437 0.0 0.2 6828 2464 0 S+ 02:46 0:00.01 grep ups Is there anything else that should be running?> AFAIK, no, those 3 daemons should do the job. But just for the fun of it, I would test changing that variable anyway. There is nothing to lose, after all.>I changed to MODE=standalone and found some new behavior, see below.>>> Would you expect `upsmon -c fsd` to not work as I described above(system halting but UPS not power cycling) if MODE was set to none but upsmon, the driver, and upsd were running?>> > If it is running ( i.e. started ) -c fsd should trigger an immediate shutdown. quote from man upsmon:> *-c* *command* > Send the command *command* to the existing upsmon process. Valid commands are:> *fsd* > shutdown all master UPSes (use with caution)>After rebooting having set MODE=standalone, I found that `upsdrvctl shutdown` now successfully shuts down the UPS. I changed back to MODE=none and the same command still works. I'm not sure what's going on there other than perhaps I wasn't being patient enough on my earlier attempts. Unfortunately, `upsmon -c fsd` still does not power off the UPS, no matter how long I wait. It seems like this used to be an issue earlier (https://forum.netgate.com/post/707181)--maybe it has come back? I may reach out on the Netgate forums as well. I also tried `upscmd AVR750U shutdown.return`, which properly shut down the UPS but did not ever bring it back up. I tried this both on mains power and on battery. In the latter case, I reconnected the UPS to the mains and waited 5 minutes. It didn't turn itself back on. I'm now becoming suspicious of a couple of the values reported by `upsc`: - battery.charge.warning = 30, but there is no battery.charge.low. Does this mean that the low battery flag will never be raised? - ups.timer.reboot, ups.timer.shutdown, and ups.timer.start all are 65535. I know this is FFFF, and so there's a chance that it's just the default response for an unsupported variable, but could this mean that the UPS will wait 18 hours before turning itself back on? It's time for me to sleep on this for a bit and come back to troubleshooting later. Thanks for your help tonight!