Going deeper into NUT

1. offizieller Beitrag

    After the recent battery replacement of my UPS (APC Back-UPS 1400VA 230V), I have investigated more about the operation of NUT, a tool that allows the control of a UPS connected to our OpenMediaVault (OMV).


    Before I expand on this, I would like to share some useful links that have helped me to customise my configuration and to understand NUT a little better.

    In the forum there are several threads related to NUT that I found worth referencing.

    After replacing the battery in my APC, I would like to go through what I think is the best way to do this:

    • Modify the value of the battery.mfr.date variable
    • Perform a battery test

    With the NUT tool and the driver I'm using (usbhid-ups) I haven't seen a way to do it. However, the manufacturer of my unit provides an application (PowerChute Personal Edition or PowerChute Serial Shutdown) for Windows to control the UPS. With this tool I was able to update the battery date and perform a battery test.


    From the command line we can check if the actions performed from PowerChute are reflected in NUT. Launch the command upsc apc. The following output is returned:

    Code
    battery.mfr.date: 2024/11/05ups.test.result: Done and passed

    Note that the value of the ups.test.result variable is not persistent. In subsequent checks it might be set to ‘No test initiated’.


    Before I move on to the next points I would like to share my current configuration.


    I have OMV installed on an HP Proliant Gen 8. I have the UPS connected to it both via USB (to monitor it from the NUT) and via power. In addition, I have other devices connected such as a router. The only device connected to the UPS that is configured to shut down safely is the server with OMV installed.


    I have configured NUT in OMV with the shutdown mode as ‘UPS is using battery’. This way we can set a shutdown timer so that after that time the system is safely shut down. This means that once the OMV shutdown is initiated, it sends a signal so that the UPS shuts down after a delay (by default I think it is 20 seconds). When the UPS shuts down the rest of the connected devices lose power.

    This is not the ideal scenario, since I would like to keep the rest of the devices powered by the battery of the UPS. The server with OMV shuts down after several minutes with the UPS on battery because it is the device with the highest consumption and the only one that I consider relevant to have a safe shutdown. In other words, the ideal scenario would be to set a timer for OMV shutdown and to set that after reaching a percentage of battery discharge defined by the user, the UPS would shut down regardless of whether  there are connected devices running or not.


    I have not found the way to implement this customised configuration, in which we granularly configure the shutdown of different devices. However, checking the reference links I have shared, it is possible to delay the shutdown of the UPS once the monitoring server has triggered the shutdown process. To do so just add offdelay = seconds_to_delay in driver configuration directives.


    The NUT developers seem to have thought that it is important to provide the ability to delay the shutdown of the UPS. Why? As explained in this document (section 2.6 on page 15), sometimes the shutdown of a device may not be completed before the UPS shuts down. So this shutdown delay time is designed for these situations.


    The usual process after a power failure is to recover the power supply within a short period of time. There is a risk that the UPS may start up the machines with a low battery and then a power cut occurs again without enough charge in the UPS batteries to allow the safe shutdown of the devices connected to it.


    To avoid this, it would be useful setting the UPS to turn on (or at least send the power signal to the devices connected to it) when a user-defined minimum battery charge is reached. It seems that there are enterprise UPS models that can allow this more advanced configuration. In fact, in this page of NUT we can see that they talk about Return treshold. A writable variable that allows to set the battery percentage to turn on the UPS after the power is restored.


    For users who do not have such advanced models, there is another option available. Set a delay on UPS start up. In order to apply it in OMV it is necessary to set the value ondelay = seconds_to_delay. Note that the delay is from the moment the OMV shutdown is initiated.


    I would like to know what UPS and NUT settings you have on your systems :)

    First of all: thanks for all the details, I will need to go thoroughly through them. Came here for something else, left with more questions

    Second of all: I landed here after a forum search and wanted to say that your post shows crazy with all the "nuts" highlighted :D


    ... my topic is: I am not very happy with how the NUT Plugin displays the UPS info and was wondering if I can connect both my OMV and my Home Assistant to the "nut-info" :)

    omv 7.4.7-1 (Sandworm) | x86_64 | Linux 6.8.12-1-pve Kernel

    plugins: omvextrasorg 7.0 | backup 7.1.4 | borgbackup 7.0.8 | compose 7.2.3 | cputemp 7.0.2 | diskstats 7.0.1-1 | kernel 7.1.2 | resetperms 7.1 | sharerootfs 7.0-1 | wol 7.0.1 | zfs 7.1.1 (I know, I know, I need a clean up...)

    Thank you for your feedback 😀


    I have never used Home Assistant. I don't know much about it, so not sure if I can help you out.


    On the Home Assistante website, in the Integrations section, the Network UPS Tools (NUT) device is available. It seems that it can be configured by auto-discover. There is also the option of configuring it manually.


    This blog post might help you. Note that each user's configuration may be different

    • Where is Home Assistant deployed?
    • Do you just want to monitor the UPS or do you want to perform some additional tasks?
    Zitat von tzinm

    I have not found the way to implement this customised configuration, in which we granularly configure the shutdown of different devices. However, checking the reference links I have shared, it is possible to delay the shutdown of the UPS once the monitoring server has triggered the shutdown process. To do so just add offdelay = seconds_to_delay in driver configuration directives.

    Thank you for pointing to this option! So far I was using CLI to set the ups.delay.shutdown value.

    Using GUI is much more convenient.

    I want my OMV to be a client. But for my primary, I've had to build a custom build off of NUT's GitHub, and now I wonder whether it's not better to do the same on my OMV system.


    But that would then be via the CLI, instead of the plugin. Is there a downside to that approach? Or is the plugin just an easier way (the green CLI output window seems to indicate that all that is done is regular CLI stuff)?

    To avoid the risk of a "Frankendebian", I decided not to build a custom build, and use the plugin instead.


    However, OMV raises errors...


    This is my setup:


    192.168.1.9 is the IP address of the Linux box that "controls" the UPS. On 192.168.1.9, there are these settings:


    I entered REDACTED2 in the field Netclient wachtwoord. I didn't know what to do with Uitschakelmodus, but I assume it doesn't matter when in Netclient mode. Op afstand observeren is disabled.



    Anyway, when trying to apply, I get this error:


    Thanks in advance for anyone who can shed some light!

    • Offizieller Beitrag

    Could you please post the output of


    Bash
    # dpkg -l | grep openmediavault


    Zitat

    The state 'nut' does not exist

    It looks like the NUT plugin is not installed.

    Zitat von votdev

    Could you please post the output of


    Bash
    # dpkg -l | grep openmediavault


    It looks like the NUT plugin is not installed.



    But I went ahead and uninstalled the plugin, rebooted and reinstalled the plugin again, and then rebooted again (one can never reboot enough ;)). However: see attachment (since the message is too long). The latest reboot also triggered these e-mails:

    &


    Now this is the output of your requested command:


    Maybe I did remove some stuff some time ago... I would have expected that a reinstallation would fix that?


    It looks like group nut is especially missed. But why isn't it created during plugin install...?

    I do notice that some directories seem to be owned by user nut, but no such user exists:


    Does that make sense?

    Zitat von votdev

    This user should be created by the Debian nut package during the installation. If this does not exist, this might be an indication that the installation was not successful.


    Try running the following command to fix that.

    Bash
    # apt-get install --reinstall nut


    So no effect...


    Maybe I should just create the user manually, like I added the group and relevant directories manually?

    Aside from the user which is missing (but I haven't had time to investigate further): I get these emails when rebooting:

    &


    That looks like something's still wrong, no?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden