Would ignorelb work on socomec double on-line conversion UPS
-
@chewie The ignorelb directive instructs NUT to ignore it if the UPS reports a low battery condition. This is probably the most misused directive in NUT.
You should not use ignorelb unless your UPS prematurely declares a low battery immediately after mains fail.
Moving on...
You can ignore the battery voltage reporting issue. It is a common issue with the blazer driver, and it isn't used for anything anyway. If it bothers you, look at setting the battery.packs value.
Before you do anything, the first thing you need to know is do you actually have a problem to begin with? Synology units don't actually shut down anymore, they go into a safe mode. So, is the UPS cutting power before the Synology reaches safe mode? If so, is the UPS running out of battery? Or is it because there is too short of a delay following the low battery declaration? Or is it because the UPS cuts power too quickly after being instructed to do so?
If you actually have a problem...
Things you will want to know: How long does it take for your Synology to get to safe mode? How low (runtime) does the UPS go before declaring a low battery? How long does your UPS wait to cut power after receiving the command to do so?
If at all possible you want to configure the variables governing runtime battery reserve and/or delays in the UPS itself. If your UPS does not offer this ability, then you can start down the path of configuration for NUT. Begin by looking at the HOSTSYNC and FINALDELAY variables.
-
@dennypage
Hello, sorry for the late response, had to find time to do further reading on nut in between work. Since the 2kva socomec is being used for another equipment, i was hesitant to use it for nut shutdown tests. I had to borrow an old APC Back-UPS XS 650CI and replace its battery. With as usbhid driver, ups status on pfsense shows this...It couldnt determine the ups load with the new battery installed.The APC is rated at 650VA and the load is a 135watt psu for pfsense and around 236 watts for synology, providing more than 30% of load, suppose to be enough for nut to show the load on the gui, but probably need to run battery calibration yet.
With just the upsd.conf modified for LISTEN interface and the upsd.users modified for synology, pulling the cord out of
the wall shows the following power-off times...- pfsense - 48 secs
- synology - 89.05 secs
- apc ups - 91.58 secs
Is this a normal behavior with pfsense shutting down first followed by the synology then the ups? I thought it was the other way around, synology first before pfsense.
I think the synology and pfsense has shutdown gracefully without me modifying HOSTSYNC and FINALDEALY. Do I still have to modify them to keep enough reserves for the battery and extend its life? Re-plugging the ups to the wall outlet, has re-started synology, pfsense and ups successfully and a battery charge at 98.
I have to return the APC, and purchase another socomec for its double on-line feature, but before our group would do so, the least available socomec wattage with double-on line conversion is 1 kva, basing on the poweroff times above would it be possible to modify the the variables to at least shutdown pfsense and synology at 90% battery charge on a socomec?
I revisited the UPS menu on the 2 kva socomec and does not offer modification on battery reserves and delays, So I am back with nut.
I re-tested the socomec with nut on the raspberry Pi, hoping to extrapolate the poweroff times from the APC and modify socomec's shutdown behavior, this time it showed a driver of...
[nutdev1] driver = "nutdrv_qx" port = "auto" vendorid = "0665" productid = "5161" bus = "001"
the only difference with the blazer driver was that nutdrv_qx showed only a battery charge of 91 as oppose to 100 with the blazer driver. Here are the variables...
Init SSL without certificate database battery.charge: 91 battery.energysave: no battery.packs: 1 battery.protection: yes battery.runtime: 20400 battery.voltage: 54.70 battery.voltage.nominal: 48.0 device.model: WPHVT2K0 device.type: ups driver.name: nutdrv_qx driver.parameter.bus: 001 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 15 driver.parameter.port: auto driver.parameter.productid: 5161 driver.parameter.synchronous: auto driver.parameter.vendorid: 0665 driver.version: 2.8.0 driver.version.data: Voltronic 0.06 driver.version.internal: 0.32 driver.version.usb: libusb-1.0.26 (API: 0x1000109) input.current.nominal: 8.0 input.frequency: 60.2 input.frequency.high: 63.0 input.frequency.low: 57.0 input.frequency.nominal: 60.0 input.phases: 1 input.transfer.high: 242 input.transfer.high.max: 254 input.transfer.high.min: 237 input.transfer.low: 218 input.transfer.low.max: 223 input.transfer.low.min: 206 input.voltage: 225.5 input.voltage.nominal: 230.0 output.current: 0.0 output.current.nominal: 8 output.frequency: 60.2 output.frequency.nominal: 60.0 output.phases: 1 output.power.maximum.percent: 0 output.power.minimum.percent: 0 output.powerfactor: 0.8 output.voltage: 229.5 output.voltage.nominal: 230.0 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.firmware: 01036.05 ups.firmware.aux: P01 ups.load: 0 ups.power.nominal: 2000 ups.productid: 5161 ups.start.auto: yes ups.start.battery: yes ups.status: OL ups.temperature: 24.0 ups.type: online ups.vendorid: 0665
The modifiable variables with upsrw socomec@localhost
[battery.energysave] Switch off when running on battery and no/low load Type: ENUM NUMBER Option: "no" SELECTED Option: "yes" [battery.packs] Number of battery packs Type: RANGE NUMBER Option: "1-99" SELECTED [battery.protection] Prevent deep discharge of battery Type: ENUM NUMBER Option: "no" Option: "yes" SELECTED [input.frequency.high] Maximum input line frequency (Hz) Type: RANGE NUMBER Option: "63-70" SELECTED [input.frequency.low] Minimum input line frequency (Hz) Type: RANGE NUMBER Option: "50-57" SELECTED [input.transfer.high] High voltage transfer point (V) Type: RANGE NUMBER Option: "237-254" SELECTED [input.transfer.low] Low voltage transfer point (V) Type: RANGE NUMBER Option: "206-223" SELECTED [ups.delay.shutdown] Interval to wait after shutdown with delay command (seconds) Type: RANGE NUMBER Option: "12-5940" SELECTED [ups.delay.start] Interval to wait before (re)starting the load (seconds) Type: RANGE NUMBER Option: "0-599940" SELECTED [ups.start.auto] UPS starts when mains is (re)applied Type: ENUM NUMBER Option: "no" Option: "yes" SELECTED [ups.start.battery] Allow to start UPS from battery Type: ENUM NUMBER Option: "no" Option: "yes" SELECTED
and upscmd -l socomec@localhost
Instant commands supported on UPS [socomec]: beeper.disable - Disable the UPS beeper beeper.enable - Enable the UPS beeper beeper.toggle - Toggle the UPS beeper bypass.start - Put the UPS in bypass mode bypass.stop - Take the UPS out of bypass mode load.off - Turn off the load immediately load.on - Turn on the load immediately shutdown.return - Turn off the load and return when power is back shutdown.stayoff - Turn off the load and remain off shutdown.stop - Stop a shutdown in progress test.battery.start - Start a battery test 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
It seems that you can not instruct socomec to shutdown at 90 battery charge or assign a battery run time.
Do I still need to modify HOSTSYNC and FINALDELAY based on the poweroff times on the APC? Our goal is hopefully to shutdown pfsense, synology and socomec at 90 battery charge. I am hesitant of copying scripts from various sites and running them on pfsense though. I suppose I can use the raspberry pi as nut master instead and run the scripts and make pfsense and synology run as nut slaves.Thank you again for your time.
-
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
With just the upsd.conf modified for LISTEN interface and the upsd.users modified for synology, pulling the cord out of
the wall shows the following power-off times...pfsense - 48 secs
synology - 89.05 secs
apc ups - 91.58 secs
Is this a normal behavior with pfsense shutting down first followed by the synology then the ups? I thought it was the other way around, synology first before pfsense.The server waits for clients to initiate their shutdown (indicated by the client logging out of the server) rather than complete their shutdown. The server has no way to know how long a client actually takes to complete the shutdown. Once all clients have logged out, the server initiates its own shutdown following a short delay (FINALDELAY).
pfSense generally shuts down relatively quickly, while Synology shuts down very slowly. So yes, it's reasonable to expect that pfSense would complete its shutdown before the Synology does. Variable ups.delay.shutdown can be used to cover this. You could also use FINALDELAY, but since your UPS has the capability to control the power off delay I would use that instead.
One question: you list a "power-off" for the Synology of 89 seconds. Was this an actual power off, or achievement of quiescent mode?
WRT the socomec, I expect the UPS vendor knows what they are doing, so setting battery.protection to true is probably sufficient to maintain battery life. Also, be sure to set ups.delay.shutdown to a sufficient value to cover the Synology's shutdown. Maybe 100-120 seconds.
As to where you run the server, you can run the server on pfSense or on the pi. Which system is more reliable? If you choose the pi, keep in mind that it may shut down even faster than pfSense. If so, you'll need to allow a little extra time. The only thing I would not do is to use the Synology as the master.
HTH
-
This post is deleted! -
Regarding the synology quiescent mode, I am not sure about this. I just have my settings same as server on
time before server enters standby mode under the UPS tab of the synology. Would gladly check it if you could
show me how. Perhaps under var/log/messages on synology?Do i put this line in the ups conf or in the extra arguments to driver to control ther power off delay?
ups.delay.shutdown = 120
or is it,
offdelay = 120
in Extra Arguments to driver
or should i issue this command via the cli?
upsrw -s ups.delay.shutdown =120
Is there way of making the soscomec shutdown immediately just for testing purposes? Since the scomec is 2 kva, it may
take forever for it to shutdown wtih just the Pi as its load. Mindful of your advice to use igbnorelb only when UPS
declares battery immediately after the mains fail?Luckily, I did read your post on why not to run nut master on synology...
Thank you very much
-
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
Regarding the synology quiescent mode, I am not sure about this. I just have my settings same as server on
time before server enters standby mode under the UPS tab of the synology. Would gladly check it if you could
show me how. Perhaps under var/log/messages on synology?Standby mode is quiescent mode. Older version of Synology would actually power off, now they just shut down all the services and sit there.
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
or should i issue this command via the cli?
upsrw -s ups.delay.shutdown =120
This.
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
Is there way of making the soscomec shutdown immediately just for testing purposes? Since the scomec is 2 kva, it may
take forever for it to shutdown wtih just the Pi as its load.You can instruct the UPS to power off immediately via a NUT command, but that's different than the UPS declaring LB (Low Battery).
-
@dennypage thank you again
-
@chewie Most welcome!
-
@dennypage said in Would ignorelb work on socomec double on-line conversion UPS:
This.
upsrw -s ups.delay.shutdown =120
doesn 't seem to persist across reboots. The ups dealy shutdown goes back to the deafualt value of 30. should i use the ..
offdelay = 120
in ExtraArgument to driver instead? This one seem to persist across reboots.
Thank you again.
-
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
doesn 't seem to persist across reboots. The ups dealy shutdown goes back to the deafualt value of 30.
Can you clarify what you mean by "Across reboots"?
Does this refer to the reboot of the OS? Or reboot of the UPS? Or the restart of the NUT daemon or NUT UPS driver?
-
@dennypage said in Would ignorelb work on socomec double on-line conversion UPS:
Can you clarify what you mean by "Across reboots"?
Does this refer to the reboot of the OS? Or reboot of the UPS? Or the restart of the NUT daemon or NUT UPS driver?
Restarting the Daemon successfully showed the delay shutdown at 120 but not when you reboot the OS.
-
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
Restarting the Daemon successfully showed the delay shutdown at 120 but not when you reboot the OS.
Okay, that's kinda weird. Only thing I can think of would be that the UPS is reseting when the USB resets. You can confirm by pulling the USB cable out for a 5-10 seconds, and then plugging it back in.
[Edit: By "restarting the Daemon" you mean completely restarting NUT, yes?]
-
@dennypage I apologize, this is what i did...
upsrw -s ups.delay.shutdown =120
and immediately the delay shutdown was set to 120 without me restarting nut with the circular arrow on the top right corner of pfsense. But the moment i hit that arrow the delay shutdown goes back to its original value of 30. Rebooting pfsense would still show the value at 30. I must be doing something wrong or not understanding something. Thank you very much
-
@chewie said in Would ignorelb work on socomec double on-line conversion UPS:
@dennypage I apologize, this is what i did...
upsrw -s ups.delay.shutdown =120
and immediately the delay shutdown was set to 120 without me restarting nut with the circular arrow on the top right corner of pfsense. But the moment i hit that arrow the delay shutdown goes back to its original value of 30. Rebooting pfsense would still show the value at 30.
Apologies for the delay, I've been busy/offline.
So I expect what is happening is that the NUT driver is resetting the shutdown delay on start, even though you have not specified a value. Lots of little quirks like this in NUT drivers.
So yes, I would recommend setting the offdelay parameter in the Extra Arguments to driver section. You can confirm that it is correctly setting the value in the UPS by using the upsrw command to read from the UPS after restarting NUT.