APC UPS Multiple shutdown using NUT

Find a tutorial that shows how to set up the NUT client. There were three config files that I had to edit I think iirc.

just seen it :frowning: faceslap

will report back

Thanks again

I have finally got this working

my ups is connected too my nas via USB

I used winnut for my Windows 10 Machine and pointed it towards the nas shutdown set too 2 mins (works perfectly)

Rasberry pi also connected but unsure if it will shutdown or how long it waits I will look into changing the wait time after testing

i have also got the ups network binding working

For anyone needing help with what the items a mean here you go


1 Like

@rlkoshak after running a test my rpi did not shut down any pointers for how too configure this

The rpi is connected too the master you can run commands too check the status of the ups now and network ups is working too

I pulled the power from the ups and my windows 10 system shutdown as expected I waited until my nas shutdown before stopping the test the rpi was still online with only a tiny battery percentage left

I don’t think there was any point as the nas is the master and the clients should go off first

Do you have the RPi set up as a client? nut.conf should show MODE=netclient

Make sure that the shutdown command in upsmon.conf is valid for the RPi. Check the rest of the parameters in upsmon.conf to make sure they make sense.

Did you see any broadcast notifications on the command prompt on the RPi when the UPS lost power? That would indicate whether or not the RPi ever successfully received the notification in the first place.

Beyond that you will probably want to go through the NUT forums and such since this isn’t an OH problem. You are more likely to find useful answers there.

I do know that I have to make changes to the client configs on my setup, but like I said above, I’ve not fully tested everything out yet.

Thanks for the response


"/sbin/shutdown -h +0"

Do you mean with a monitor connected I was just sitting on the ssh console

Agreed I just thought with already posting here and you running a similar setup it made sense if no luck here I will post there and post back here after

I did notice something about needing a user for running the shutdown command I don’t think I have one setup

Should I create a user called nut or change the user too something else?

It should show up with just an ssh terminal. When NUT kicks in it should broadcast to all logged in terminals a message indicating the computer is on battery power.

I don’t really know. I’ve never tested my setup to failure yet.

I think by default nut runs as root or maybe the nut user. I don’t remember doing anything special here.

This book might be useful:


1 Like

@rlkoshak Success

I have got this working and my RPI now powers off as expected

Quick question

If the wall power is gone and the battery completely dead the rpi will boot up and come on but if theres still battery it stays in a shutdown state is there anyway around this?

Hoping for your opinion

My idea

add a separate rpi too act as the nut master and also get it too send wake on lan too wake the OH rpi

1 Like

Fantastic! Please post what you did because I just realized that I have a new VM I need to set up and I haven’t the first clue any more how I set everything else up.

I’ve no ideas to suggest. Your WOL idea sounds like a good one. An RPi 0w would fit the job nicely. You can send the WOL message when the ups.status goes back to OL.

That’s what I was thinking

I will post the guide i used when I get home be about 10 mins


You need too install nut

Edit nut.conf and upsmon.conf

Then change permissions

1 Like

Cool. So I didn’t leave anything out. I just need to test it.

And I found that I had written a nut Ansible playbook to set up the server so I added another one for the client and edited it a bit. They are not very modular with lots of stuff hard coded. I could pull a bunch more stuff out into vars to make this more generic.

**Nut Server **

# tasks file for nut

- name: Install nut server
    name: "{{ item }}"
    update_cache: no
  become: true
    - nut
    - nut-client
    - nut-server
  register: nut_installed

- name: Configure NUT for the CyberPower CP1500AVRLCD
    path: /etc/nut/ups.conf
    state: present
    section: cyberpower1
    option: "{{ item.option }}"
    value: "{{ item.value }}"
    - { option: "driver", value: "usbhid-ups" }
    - { option: "port", value: "auto" }
    - { option: "desc", value: "\"CyberPower CP1500AVRLCD\"" }
    - { option: "pollinterval", value: "15" }
  become: true

- name: Reboot
    name: reboot
  when: nut_installed.changed

- name: Start the NUT Driver
    daemon_reload: yes
    enabled: yes
    name: nut-driver
    state: started
  become: true

- name: Update upsd.conf
    path: /etc/nut/upsd.conf
    block: |
      MAXAGE 25
  become: yes

- name: Add nut users
    path: /etc/nut/upsd.users
    state: present
    section: "{{ item.section }}"
    option: "{{ item.option }}"
    value: "{{ item.value }}"
    - { section: "admin", option: "password", value: "{{ share_pass }}" }
    - { section: "admin", option: "actions", value: "SET" }
    - { section: "admin", option: "instcmds", value: "ALL" }
    - { section: "rich",  option: "password", value: "{{ share_pass }}" }
    - { section: "rich",  option: "upsmon", value: "master" }
  become: true

- name: Configure the server to run
    backrefs: yes
    line: MODE=standalone
    path: /etc/nut/nut.conf
    regexp: MODE=none
    state: present
  become: yes

- name: Start the NUT Server
    daemon_reload: yes
    enabled: yes
    name: nut-server
    state: started
  become: true

- name: Set up the NUT client on the server
    name: nut-client

- name: Cycle the services
    name: "{{ item }}"
    state: started
  become: true
    - nut-driver
    - nut-server
    - nut-monitor

NUT Client Config


- name: Install nut client
    name: nut
    update_cache: no
  become: true

- name: Set up the NUT client
    path: /etc/nut/upsmon.conf
    block: |
      MONITOR cyberpower1@localhost 1 rich {{ share_pass }} master
      DEADTIME 25
      NOTIFYCMD /etc/nut/notifycmd.sh
  become: true

- name: Copy the notify shell script
    src: notifycmd.sh
    dest: /etc/nut/notifycmd.sh
    mode: 0755
    owner: root
    group: nut
  become: yes

And the notify script

to='To: '$email'\n'
from='From: '$email'\n'
hostname=$(uname -n)
subject='Subject: NUT ALERT: '$NOTIFYTYPE'\n\n'
body='Alert type: '$NOTIFYTYPE


echo -e "$msg" | $sendmail $email

I use ssmtp as explained in your link for email.

Maybe someone will find this useful as well. Based on the tutorial you posted I think I have everything configured. I just need to test my UPS to failure (i.e. running out of battery) at some point to verify. I was able to verify that I get the notifications on my command line.


found this thought may be of use too you maby you already know

To test a synchronized shutdown without pulling the plug on your UPS(es), you need only set the forced shutdown (FSD) flag on them. You can do this by calling upsmon again to set the flag, i.e.:

upsmon -c fsd
1 Like

@rlkoshak do you know how I would convert this into a command that openhab could use in a rule

I have a button (Hue Dimmer) that I want too press too set my hue lights too maximum brighness, disable the motion sensors, send a notification too Google home saying network going offline and then finally set the ups too a state that shutsdown all connected devices all done apart from the command too power off the load

I’m assuming I would need too use the exec binding but I’m not sure what you need too do here

Exec binding or the executeCommandLine Action is how you would call this. Either one would be fine in this case, though the Action will be a little easier to use. There are no Things or the like.

If you need the result of the command or need to way for the command to finish before continuing your rule, make sure to include the time out on the call to executeCommandLine.

I’m planning to set up a UPS for my openHABian server, and all the posts I’ve read talk about NUTS being installed on a separate machine from the openHABian server. Can I run NUTS side by side with openHABian on one RPi, or would you foresee that causing problems? I only need it to shut down my RPi.

If the UPS and the server are co located I see no reason why they can’t run on the same machine. There are reasons why I don’t. I need my host OS (ESXi) to be a client to NUT. If I put the NUT server on one of the VMs, then when the battery gets close to running out of power it will shutdown the host (ESXi) which will shutdown the VMs. Consequently, the NUT server won’t be the last machine to close down and you want the NUT Server to be the last to close down or else some of the clients might be left running.

Thanks, Rich! I was worried that there might be resource issues. I’ll try it out, and if it works out I’ll take a shot at writing a tutorial. I’m sure there are others in the same scenario as me.