[Plugin] NUT v2 - Network UPS Tools


dmacias

Recommended Posts

11 hours ago, arghhh40k said:

Hi, I got my Eaton 9PX ups working over SNMP v3 but it's using a old MIB. I have the new supported MIBs from Eaton. How do I get NUT to use them?

 

It's not possible to just add a MIB, they have to be coded into the UPS driver in the backend.

You can open an issue here attaching your new MIB: https://github.com/networkupstools/nut/issues

What is the problem with the older MIB, what information are you missing on your 9PX or doesn't work at all?

Link to comment
16 hours ago, UFKEL said:

First of all: THANK YOU so much for actively maintaining this plugin.

 

I have a small feature request:

The plugin right now seems to dislike hyphenated UPS names, like ups-main and ups-22. The GUI does not let you enter those names, even in manual config mode hyphenated UPS names do not work correctly.

 

It would be great to support hyphenated UPS names.

 

I have just pushed an update which allows for hyphens in the UPS name (among other changes).

  • Like 1
Link to comment
8 hours ago, Rysz said:

What is the problem with the older MIB, what information are you missing on your 9PX or doesn't work at all?

It is missing VA and efficiency along with a lot of the newer UPS status like on high efficiency mode and a lot of new alarms. Looks like the are actively updating the MIBs with the release of the new M2 and M3 cards.

 

Thank you for the support, I will log it on github with the new MIBs. Github issue #2372.

 

Edit: I just noticed the ups.power is incorrect and only showing 1 phase of the split phase and not the total output of the UPS.

28% of 5520 is 1545w not 627w

image.png.52db58fd72e9ef29559be3b3de16afd6.png

Edited by arghhh40k
  • Thanks 1
Link to comment
On 3/18/2024 at 1:13 PM, hfuhruhurr said:

Responding to below post dated 3/18/24, subject: NUT with APC Back-UPS BGM1500 biweekly test shuts down immediately

 

The problem still persists but my current NUT version still shows 2.8.0. I have changed the default to 2.8.1 and rebooted. Ther backend now shows version nut-2.8.1-x86_64-2stable.ssl11, and is running. Will advise if the the issue occurs (based on previous schedule, it should shutdown on 3/26/24 at ~1:00am). Thanks for the message!

 

 

 

The scheduled test ran last night and the Unraid server shut down again. I installed a NUT update this morning and here are the install messages:

 

Executing install script for nut-plugin-2024.03.26-x86_64-1.txz. Updating permissions for NUT... Package nut-plugin-2024.03.26-x86_64-1.txz installed. Package nut-plugin-2024.03.16-x86_64-1 upgraded with new package /boot/config/plugins/nut-dw/nut-plugin-2024.03.26-x86_64-1.txz. Reading NUT configuration... Determining if NUT services should be started... Starting NUT services... Writing NUT configuration... Updating permissions for NUT... Checking if the NUT Runtime Statistics Module should be enabled... Enabling the NUT Runtime Statistics Module... NUT Runtime Statistics is requesting the first batch of data... NUTSTATS: NUT upsmon is not (yet) running... exiting HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x0c HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x22 HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x40 Using subdriver: APC HID 0.100 Network UPS Tools - Generic HID driver 0.52 (2.8.1) USB communication driver (libusb 1.0) 0.46 ups_status_set: seems that UPS [ups] is in OL+DISCHRG state now. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge' option). Network UPS Tools - UPS driver controller 2.8.1 ----------------------------------------------------------- Network UPS Tools (NUT) for UNRAID has been installed. Version: 2024.03.26 / Plugin Maintainer: desertwitch ----------------------------------------------------------- plugin: nut-dw.plg updated Executing hook script: gui_search_post_hook.sh Executing hook script: post_plugin_checks

 

Also, in my system log I am getting this message repeated every few seconds:

Mar 26 06:57:27 Mongo usbhid-ups[3678]: ups_status_set: seems that UPS [ups] is in OL+DISCHRG state now. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge' option).
 
Link to comment
6 minutes ago, hfuhruhurr said:

 

The scheduled test ran last night and the Unraid server shut down again. I installed a NUT update this morning and here are the install messages:

 

Executing install script for nut-plugin-2024.03.26-x86_64-1.txz. Updating permissions for NUT... Package nut-plugin-2024.03.26-x86_64-1.txz installed. Package nut-plugin-2024.03.16-x86_64-1 upgraded with new package /boot/config/plugins/nut-dw/nut-plugin-2024.03.26-x86_64-1.txz. Reading NUT configuration... Determining if NUT services should be started... Starting NUT services... Writing NUT configuration... Updating permissions for NUT... Checking if the NUT Runtime Statistics Module should be enabled... Enabling the NUT Runtime Statistics Module... NUT Runtime Statistics is requesting the first batch of data... NUTSTATS: NUT upsmon is not (yet) running... exiting HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x0c HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x22 HIDParse: LogMax is less than LogMin. Vendor HID report descriptor may be incorrect; interpreting LogMax -1 as 255 in ReportID: 0x40 Using subdriver: APC HID 0.100 Network UPS Tools - Generic HID driver 0.52 (2.8.1) USB communication driver (libusb 1.0) 0.46 ups_status_set: seems that UPS [ups] is in OL+DISCHRG state now. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge' option). Network UPS Tools - UPS driver controller 2.8.1 ----------------------------------------------------------- Network UPS Tools (NUT) for UNRAID has been installed. Version: 2024.03.26 / Plugin Maintainer: desertwitch ----------------------------------------------------------- plugin: nut-dw.plg updated Executing hook script: gui_search_post_hook.sh Executing hook script: post_plugin_checks

 

Also, in my system log I am getting this message repeated every few seconds:

Mar 26 06:57:27 Mongo usbhid-ups[3678]: ups_status_set: seems that UPS [ups] is in OL+DISCHRG state now. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge' option).
 

 

Do you have the log from before the shutdown?

We need to figure out what your UPS was doing before the server decided to shutdown.

 

Also, please post your diagnostics.

 

Edited by Rysz
Link to comment
8 hours ago, hfuhruhurr said:

I believe the relevant log data in the /logs/syslog-previous.txt file of this archive.

Thanks for looking into this!

 

Donn

 

Thanks for the logs, those helped me narrow down the problem some more. It seems this is a general compatibility problem of your UPS with the UPS driver. The shutdown is caused by the UPS Driver thinking your UPS is on battery and then on critical low battery, resulting in an immediate shutdown, when in fact it is calibrating and possibly cycling through those states as part of that process.

 

Mar 26 01:48:49 Mongo upsmon[17800]: UPS [email protected] on battery
Mar 26 01:48:49 Mongo nut-notify: [ups] UPS is on battery. The system will shutdown when there is 240  runtime left on the UPS battery.
Mar 26 01:48:54 Mongo upsmon[17800]: UPS [email protected] battery is low
Mar 26 01:48:54 Mongo upsd[17797]: Client [email protected] set FSD on UPS [ups]
Mar 26 01:48:54 Mongo nut-notify: [ups] UPS [email protected] battery is low
Mar 26 01:49:00 Mongo upsmon[17800]: Executing automatic power-fail shutdown
Mar 26 01:49:00 Mongo upsmon[17800]: Auto logout and shutdown proceeding
Mar 26 01:49:05 Mongo shutdown[15423]: shutting down for system halt

 

As a workaround we can attempt the following, hopefully it'll solve the problem with the shutdowns.

 

Put these two lines in your UPS.CONF file using the GUI configuration editor.

Make sure to put them on line 10 and 11 so they are not overwritten by the GUI:

 

ignorelb
onlinedischarge_calibration

 

Then "Restart NUT" to make sure that the changes are applied.

Check your UPS.CONF file to confirm the lines are still there after you restarted NUT.

 

The first line is to tell the UPS driver to ignore the low battery state and instead determine if the battery is low from the reported battery charge and runtime only, this should prevent the immediate shutdown when the battery calibration is cycling through the low battery state and the driver thinks the UPS is on low battery when it's actually calibrating.

 

The second line tells the UPS driver to treat OL+DISCHRG as CAL and will hopefully stop the massive log spamming that is going on because your UPS seems to be in OL+DISCHRG state almost permanently (or the UPS driver seems to think so at least). This will probably result in your UPS showing as calibrating instead of being online in the dashboards most of the time, but I think it's a small price to pay for the reduced log volume.

 

Please let me know if that worked for you!

 

Edited by Rysz
Link to comment

hi @Rysz

 

new issue now, Server turns off at midnight each night as per sleep scehdule. at 6am it then turns back on via BIOS alarm. but now NUT will not start. when i go into NUT settings and say "Yes" to Start NUT service.

 

it then starts and runs.

 

i attach diag prior to manually starting NUT and after i have started NUT.

 

what have i busted this time?

nut-debug-20240327091949 post.zip nut-debug-20240327091532 pre.zip

Link to comment
1 minute ago, Jammy B said:

hi @Rysz

 

new issue now, Server turns off at midnight each night as per sleep scehdule. at 6am it then turns back on via BIOS alarm. but now NUT will not start. when i go into NUT settings and say "Yes" to Start NUT service.

 

it then starts and runs.

 

i attach diag prior to manually starting NUT and after i have started NUT.

 

what have i busted this time?

nut-debug-20240327091949 post.zip 14.74 kB · 0 downloads nut-debug-20240327091532 pre.zip 14.32 kB · 0 downloads

 

Can you please also post the diagnostics?

Link to comment
7 minutes ago, Jammy B said:

 

Thanks for getting back to me, honestly I'm at a loss as to what the problem with your UPS could be. It really does seem like nothing is working as it should (even in their own software, judging by the screenshot). NUT is trying to bring up the driver as it should, but it fails to do so when your system boots for reasons beyond my understanding - especially when considering that the configuration itself doesn't change between the system boot and you manually starting NUT.

 

A wild guess would be that the UPS takes a long time to get ready for a USB connection once noticing that there's something active on the other end of its USB connection. Meaning that the NUT driver startup at system boot might be happening at a stage where the UPS is not ready for a connection yet. But that would be the first time that I'm seeing something like this and I'm also wondering why this wasn't a problem for you before and has become one now... what's changed except for your batteries?

 

Honestly after all this trouble and at this stage, if it were my UPS, I would scrap that UPS because I would not be able to trust it after the mess with the batteries not holding their load, voltages all over the place and now the software parts acting up as well - the software remains a big part of the equation after all. I mean a good UPS should be a device you can trust to protect your data and not burn down your house while at it, definitely something to not have to worry about every day.

 

Used but good condition UPS can be found for cheap and even brand new UPS from reputable brands are not out of this world expensive. Personally I'd invest in a proper Eaton UPS, they have great support as far as NUT is concerned (having sponsored and contributed developing the NUT project for many years) and I personally use them with zero problems - the 5P series being my go-to UPS for almost all applications. I don't want this to be a sales pitch but something to consider from my experience.

 

If you must keep using your current UPS, have you tried using it with APCUPSD (the in-built "UPS Settings")? If not, it might be worth a try - just make sure to stop the NUT services first. Maybe it'll be the solution to all your problems. 🙂 

Link to comment
7 minutes ago, Rysz said:

 

Thanks for getting back to me, honestly I'm at a loss as to what the problem with your UPS could be. It really does seem like nothing is working as it should (even in their own software, judging by the screenshot). NUT is trying to bring up the driver as it should, but it fails to do so when your system boots for reasons beyond my understanding - especially when considering that the configuration itself doesn't change between the system boot and you manually starting NUT.

 

A wild guess would be that the UPS takes a long time to get ready for a USB connection once noticing that there's something active on the other end of its USB connection. Meaning that the NUT driver startup at system boot might be happening at a stage where the UPS is not ready for a connection yet. But that would be the first time that I'm seeing something like this and I'm also wondering why this wasn't a problem for you before and has become one now... what's changed except for your batteries?

 

Honestly after all this trouble and at this stage, if it were my UPS, I would scrap that UPS because I would not be able to trust it after the mess with the batteries not holding their load, voltages all over the place and now the software parts acting up as well - the software remains a big part of the equation after all. I mean a good UPS should be a device you can trust to protect your data and not burn down your house while at it, definitely something to not have to worry about every day.

 

Used but good condition UPS can be found for cheap and even brand new UPS from reputable brands are not out of this world expensive. Personally I'd invest in a proper Eaton UPS, they have great support as far as NUT is concerned (having sponsored and contributed developing the NUT project for many years) and I personally use them with zero problems - the 5P series being my go-to UPS for almost all applications. I don't want this to be a sales pitch but something to consider from my experience.

 

If you must keep using your current UPS, have you tried using it with APCUPSD (the in-built "UPS Settings")? If not, it might be worth a try - just make sure to stop the NUT services first. Maybe it'll be the solution to all your problems. 🙂 

 

 

its a cheap UPS, its just had new batteries put into it.

 

when they "fail" in a couple years i will look at it then.

 

in the meantime, is there a script i can make/run that runs 5 minutes after startup to restart Nut?

 

odd that the NUT starting issue only started after i removed the battery voltage and nominal voltage in the ups.conf, i might re-instate the nominal voltage today to see if it "cures" the issue, then if need be, reinstate the battery voltages and reduce "on battery" runtime to 1 minute instead of 2 minutes.

 

thanks for looking at it. :)

Link to comment
15 minutes ago, Jammy B said:

 

 

its a cheap UPS, its just had new batteries put into it.

 

when they "fail" in a couple years i will look at it then.

 

in the meantime, is there a script i can make/run that runs 5 minutes after startup to restart Nut?

 

odd that the NUT starting issue only started after i removed the battery voltage and nominal voltage in the ups.conf, i might re-instate the nominal voltage today to see if it "cures" the issue, then if need be, reinstate the battery voltages and reduce "on battery" runtime to 1 minute instead of 2 minutes.

 

thanks for looking at it. :)

 

Yes, you could put this command in your /boot/config/go file or in a User Scripts (plugin) script configured to run at system startup - which will restart the NUT service 5 minutes after system startup:

at -M now +5 minutes <<< "/etc/rc.d/rc.nut restart | logger"

 

Regarding your startup problem I think you could be right about the now removed voltage estimation settings causing this, although I'm not sure why it happens only at startup for you and not always. This user reported a similar problem - maybe that thread has some more information:

 

https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-June/010757.html

https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-June/010759.html

 

So all that said putting back the voltage estimation settings in the UPS.CONF file might be the "solution" to that issue at least, but I'd monitor the UPS closely nonetheless all things considered.

 

Edited by Rysz
Link to comment
19 hours ago, Rysz said:

 

Thanks for the logs, those helped me narrow down the problem some more. It seems this is a general compatibility problem of your UPS with the UPS driver. The shutdown is caused by the UPS Driver thinking your UPS is on battery and then on critical low battery, resulting in an immediate shutdown, when in fact it is calibrating and possibly cycling through those states as part of that process.

 

Mar 26 01:48:49 Mongo upsmon[17800]: UPS [email protected] on battery
Mar 26 01:48:49 Mongo nut-notify: [ups] UPS is on battery. The system will shutdown when there is 240  runtime left on the UPS battery.
Mar 26 01:48:54 Mongo upsmon[17800]: UPS [email protected] battery is low
Mar 26 01:48:54 Mongo upsd[17797]: Client [email protected] set FSD on UPS [ups]
Mar 26 01:48:54 Mongo nut-notify: [ups] UPS [email protected] battery is low
Mar 26 01:49:00 Mongo upsmon[17800]: Executing automatic power-fail shutdown
Mar 26 01:49:00 Mongo upsmon[17800]: Auto logout and shutdown proceeding
Mar 26 01:49:05 Mongo shutdown[15423]: shutting down for system halt

 

As a workaround we can attempt the following, hopefully it'll solve the problem with the shutdowns.

 

Put these two lines in your UPS.CONF file using the GUI configuration editor.

Make sure to put them on line 10 and 11 so they are not overwritten by the GUI:

 

ignorelb
onlinedischarge_calibration

 

Then "Restart NUT" to make sure that the changes are applied.

Check your UPS.CONF file to confirm the lines are still there after you restarted NUT.

 

The first line is to tell the UPS driver to ignore the low battery state and instead determine if the battery is low from the reported battery charge and runtime only, this should prevent the immediate shutdown when the battery calibration is cycling through the low battery state and the driver thinks the UPS is on low battery when it's actually calibrating.

 

The second line tells the UPS driver to treat OL+DISCHRG as CAL and will hopefully stop the massive log spamming that is going on because your UPS seems to be in OL+DISCHRG state almost permanently (or the UPS driver seems to think so at least). This will probably result in your UPS showing as calibrating instead of being online in the dashboards most of the time, but I think it's a small price to pay for the reduced log volume.

 

Please let me know if that worked for you!

 

 

I added the two lines to UPS.conf as requested. The UOS.conf file now looks like this:

[ups]
    driver = "usbhid-ups"
    port = "auto"
    vendorid = "051D"
    productid = "0002"
    product = "Back-UPS BGM1500  FW:31316S12-31320S10"
    serial = "0B2121P12408"
    vendor = "American Power Conversion"
    bus = "001"
    ignorelb
    onlinedischarge_calibration

 

 

 

    override.battery.charge.low = 30

-----

To clarify the issue, this is an APC Back-UPS BGM1500 and it apparently runs a test diagnostic every two weeks (I havbe tried to change it but changes have no effect). When this test runs, the Unraid server immediately starts shutdown. I would like the test to run uninterrupted but to not cause the shutdown unless the UPS doesn't come back online within set parameters.

 

Thanks!

Link to comment
On 10/1/2023 at 3:51 PM, Rysz said:

Please install Network UPS Tools (NUT) for UNRAID by Rysz from Community Applications. The older plugins (including the one in the first post of this topic) are deprecated/now unsupported.

 

Hello, thanks to the greate plugin, Network UPS Tools (NUT) for UNRAID, works well. And I have a small question to  ask.
My UPS has 6 modes listed here:

Online mode
When the input voltage is within the allowable range, the inverter works to provide stable pure sinusoidal AC power output and charge the battery at the same time. In the event of a power outage, the switching time to battery power is 0ms.

ECO mode
When the input voltage is within the set voltage range, the UPS will switch to bypass mode to achieve energy saving. In the event of a power outage, the switching time to battery power is <4ms.

Frequency Conversion mode
When the input frequency is within the set allowable range, the UPS can set the output frequency to 50Hz or 60Hz, and the UPS will charge the battery at the same time.

Battery mode
When the input voltage is abnormal or there is a power outage, the UPS switches to battery mode and the buzzer sounds once every 4 seconds, and the UPS will be powered by battery power.

Bypass mode
When the UPS is operating in online mode and is overloaded, if the input voltage is within the allowable range, the UPS will automatically enter bypass mode.

Standby mode
When the UPS is plugged into the mains supply and not turned on, the UPS works in standby mode, only charging the battery, and the UPS has no output.

Personally, I use Eco mode, because it saves energy and reduces heat and fan noise.
The UPS works on Eco mode, But the NUT says “On Line - UPS bypass circuit is active (no battery protection is available)”
What can I do to solve the alert? or Could you add an option to set whether to hide this alert?
Thanks a lot.

 

Snipaste_2024-03-28_09-46-27.png.87cbf613746333abf55b882da224156a.png

 

Snipaste_2024-03-28_09-46-00.thumb.png.53a77d6416415519c7d3d0f931bec670.png

Link to comment
8 hours ago, mathgoy said:

Hi all, I am using this UPS

I configured NUT so it uses the blazer_usb driver as per the documentation.

I can see the UPS is online, I can see the battery level and the UPS load but I cannot see the runtime left.

image.thumb.png.052772059ee7a9e1d792cc7a3fe92642.png

 

Maybe I did something wrong. How can I get the runtime left ?

 

Thanks

 

You did not do anything wrong, it's possible your UPS does not send this information for NUT to read. Unfortunately you cannot do anything about that, but you can still use the "Shutdown Mode": "Battery Level" and "Time on Battery", which are the more reliable shutdown modes anyhow. "Runtime Left" is the least reliable shutdown mode and that's the only one that won't work for you because of the missing runtime variable. So basically NUT already has all the information it needs to work reliably and that's good even if some of the variables are missing here. You will see some more information (not the runtime, but at least the power consumed) if you set this setting as follows:

 

grafik.thumb.png.fbf65bf6c13e83dba4d020de00ab8823.png

 

3 hours ago, hfuhruhurr said:

 

I added the two lines to UPS.conf as requested. The UOS.conf file now looks like this:

[ups]
    driver = "usbhid-ups"
    port = "auto"
    vendorid = "051D"
    productid = "0002"
    product = "Back-UPS BGM1500  FW:31316S12-31320S10"
    serial = "0B2121P12408"
    vendor = "American Power Conversion"
    bus = "001"
    ignorelb
    onlinedischarge_calibration

 

 

 

    override.battery.charge.low = 30

-----

To clarify the issue, this is an APC Back-UPS BGM1500 and it apparently runs a test diagnostic every two weeks (I havbe tried to change it but changes have no effect). When this test runs, the Unraid server immediately starts shutdown. I would like the test to run uninterrupted but to not cause the shutdown unless the UPS doesn't come back online within set parameters.

 

Thanks!

 

Yeah I understood the issue and the two settings you've now added should fix that problem for you. 🙂 

Please let me know after the next test if your system has shutdown or if it is working for you as it should now.

 

2 hours ago, neatgz said:

 

Hello, thanks to the greate plugin, Network UPS Tools (NUT) for UNRAID, works well. And I have a small question to  ask.
My UPS has 6 modes listed here:

Online mode
When the input voltage is within the allowable range, the inverter works to provide stable pure sinusoidal AC power output and charge the battery at the same time. In the event of a power outage, the switching time to battery power is 0ms.

ECO mode
When the input voltage is within the set voltage range, the UPS will switch to bypass mode to achieve energy saving. In the event of a power outage, the switching time to battery power is <4ms.

Frequency Conversion mode
When the input frequency is within the set allowable range, the UPS can set the output frequency to 50Hz or 60Hz, and the UPS will charge the battery at the same time.

Battery mode
When the input voltage is abnormal or there is a power outage, the UPS switches to battery mode and the buzzer sounds once every 4 seconds, and the UPS will be powered by battery power.

Bypass mode
When the UPS is operating in online mode and is overloaded, if the input voltage is within the allowable range, the UPS will automatically enter bypass mode.

Standby mode
When the UPS is plugged into the mains supply and not turned on, the UPS works in standby mode, only charging the battery, and the UPS has no output.

Personally, I use Eco mode, because it saves energy and reduces heat and fan noise.
The UPS works on Eco mode, But the NUT says “On Line - UPS bypass circuit is active (no battery protection is available)”
What can I do to solve the alert? or Could you add an option to set whether to hide this alert?
Thanks a lot.

 

Snipaste_2024-03-28_09-46-27.png.87cbf613746333abf55b882da224156a.png

 

Snipaste_2024-03-28_09-46-00.thumb.png.53a77d6416415519c7d3d0f931bec670.png

 

Yes, this is basically correct information being shown by NUT. The yellow colour is not an alert, it just means that something that is not 100% standard operation is happening for the user to be aware of:

 

ECO mode: When the input voltage is within the set voltage range, the UPS will switch to bypass mode to achieve energy saving. In the event of a power outage, the switching time to battery power is <4ms.

 

I agree that "no battery protection is available" is maybe not 100% correct in your case, but the UPS being on BYPASS is correctly reported by NUT. Usually BYPASS does mean that the UPS circuit is completely bypassed (like in datacenters during UPS battery maintenance) so in such cases there really is no battery protection available while the UPS is on BYPASS. It seems in your case they have a smart switching mechanism and not powering the rectifier and battery circuits is saving that energy and thermal heat to be called ECO mode. I'm also not sure if the UPS is able to condition input power (Volts and Hz) in ECO mode, if that's something that matters to you.

 

By the way, "blazer_usb" is the legacy driver for the newer "nutdrv_qx" driver, you can try setting the UPS Driver to "nutdrv_qx" and see if that will show more or better information (also regarding the BYPASS) - it should work (see this report): https://github.com/networkupstools/nut/issues/1872

 

Edited by Rysz
  • Like 1
Link to comment
1 hour ago, Rysz said:

I'm also not sure if the UPS is able to condition input power (Volts and Hz) in ECO mode, if that's something that matters to you.

 

I asked the manufacturer.
1, They responded with some instructions for ECO mode, which works like a backup-UPS, but with a little difference. When the input voltage meets the set range (for example 220v±5v), it directly outputs 220v±5v, the rectifier and inverter are not working but are standby, which can save energy and reduce heat generation. When the input voltage exceeds the set range, (for example 230v), the inverter works to provide stable pure sinusoidal 220v AC power output with a conversion time of 0ms. When there is a power outage, the inverter works and is powered by the battery, outputting 220v AC power with a conversion time of 1.8ms (< 4ms).
2, The manufacturer responded with some instructions about ups.status.

ups.status OL           means Online mode
ups.status OL BYPASS    means ECO mode
ups.status OL CHRG      means Online mode, charging
ups.status BYPASS       means Bypass mode
ups.status OVER BYPASS  means Bypass mode, overloaded
ups.status OB           means Battery mode
ups.status LB           means Low battery
....

Personally, Saves energy reduces heat and fan noise are more important for me than the stable pure sinusoidal AC output. so I choose to use Eco mode.
I was confused why they chose to use "OL BYPASS" for their ECO mode.
Anyway, as long as it works normally, this warning doesn't matter.
Thanks again.

  • Thanks 1
Link to comment
16 minutes ago, neatgz said:

 

I asked the manufacturer.
1, They responded with some instructions for ECO mode, which works like a backup-UPS, but with a little difference. When the input voltage meets the set range (for example 220v±5v), it directly outputs 220v±5v, the rectifier and inverter are not working but are standby, which can save energy and reduce heat generation. When the input voltage exceeds the set range, (for example 230v), the inverter works to provide stable pure sinusoidal 220v AC power output with a conversion time of 0ms. When there is a power outage, the inverter works and is powered by the battery, outputting 220v AC power with a conversion time of 1.8ms (< 4ms).
2, The manufacturer responded with some instructions about ups.status.

ups.status OL           means Online mode
ups.status OL BYPASS    means ECO mode
ups.status OL CHRG      means Online mode, charging
ups.status BYPASS       means Bypass mode
ups.status OVER BYPASS  means Bypass mode, overloaded
ups.status OB           means Battery mode
ups.status LB           means Low battery
....

Personally, Saves energy reduces heat and fan noise are more important for me than the stable pure sinusoidal AC output. so I choose to use Eco mode.
I was confused why they chose to use "OL BYPASS" for their ECO mode.
Anyway, as long as it works normally, this warning doesn't matter.
Thanks again.

 

Thanks for getting back to me and asking the manufacturer too, this is very interesting information to me. I also have an update in the works where I'm generally shortening the UPS statuses, e.g. the currently extremely long BYPASS status will simply be "On Bypass" in the future, which will look better in the dashboards and not exceed the table dimensions even when multiple statuses are present (e.g. OL DISCHRG CAL) as seen with some UPS. I don't think an explanation that long is necessary for most UPS statuses and it looks weird when grouped together in the dashboard like that.

 

Extreme Example - Before:

grafik.thumb.png.56ec5b7462c66253aff9107e9014863d.png

 

Extreme Example - After:

grafik.thumb.png.b1722be706f3081464871a3452d67a4e.png

 

Edited by Rysz
Link to comment
16 hours ago, Rysz said:

 

Yes, you could put this command in your /boot/config/go file or in a User Scripts (plugin) script configured to run at system startup - which will restart the NUT service 5 minutes after system startup:

at -M now +5 minutes <<< "/etc/rc.d/rc.nut restart | logger"

 

Regarding your startup problem I think you could be right about the now removed voltage estimation settings causing this, although I'm not sure why it happens only at startup for you and not always. This user reported a similar problem - maybe that thread has some more information:

 

https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-June/010757.html

https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-June/010759.html

 

So all that said putting back the voltage estimation settings in the UPS.CONF file might be the "solution" to that issue at least, but I'd monitor the UPS closely nonetheless all things considered.

 

 

thanks for the script. i've put that in as even after adding the nominal voltage in yesterday, NUT failed this morning. 

 

will report back tomorrow if the script does the job.

 

thank you for the assistance on all this as always. :)

Link to comment
3 hours ago, mathgoy said:

thanks @Rysz. This is very helpful!

 

By the way - this also applies to you - "blazer_usb" is the legacy driver of the newer "nutdrv_qx" driver, you can try setting the UPS Driver to "nutdrv_qx" and see if that will show more or better information (also regarding the runtime). If not or worse, you can still go back to "blazer_usb" if that works better for you.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.