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 
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
https://networkupstools.org/docs/developer-guide.chunked/apas01.html
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
Yes
"/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.
@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
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
apt:
name: "{{ item }}"
update_cache: no
become: true
with_items:
- nut
- nut-client
- nut-server
register: nut_installed
- name: Configure NUT for the CyberPower CP1500AVRLCD
ini_file:
path: /etc/nut/ups.conf
state: present
section: cyberpower1
option: "{{ item.option }}"
value: "{{ item.value }}"
with_items:
- { option: "driver", value: "usbhid-ups" }
- { option: "port", value: "auto" }
- { option: "desc", value: "\"CyberPower CP1500AVRLCD\"" }
- { option: "pollinterval", value: "15" }
become: true
- name: Reboot
include_role:
name: reboot
when: nut_installed.changed
- name: Start the NUT Driver
systemd:
daemon_reload: yes
enabled: yes
name: nut-driver
state: started
become: true
- name: Update upsd.conf
blockinfile:
path: /etc/nut/upsd.conf
block: |
LISTEN 127.0.0.1
LISTEN 10.10.1.121
MAXAGE 25
become: yes
- name: Add nut users
ini_file:
path: /etc/nut/upsd.users
state: present
section: "{{ item.section }}"
option: "{{ item.option }}"
value: "{{ item.value }}"
with_items:
- { 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
lineinfile:
backrefs: yes
line: MODE=standalone
path: /etc/nut/nut.conf
regexp: MODE=none
state: present
become: yes
- name: Start the NUT Server
systemd:
daemon_reload: yes
enabled: yes
name: nut-server
state: started
become: true
- name: Set up the NUT client on the server
include_role:
name: nut-client
- name: Cycle the services
systemd:
name: "{{ item }}"
state: started
become: true
with_items:
- nut-driver
- nut-server
- nut-monitor
NUT Client Config
---
- name: Install nut client
apt:
name: nut
update_cache: no
become: true
- name: Set up the NUT client
blockinfile:
path: /etc/nut/upsmon.conf
block: |
MONITOR cyberpower1@localhost 1 rich {{ share_pass }} master
DEADTIME 25
NOTIFYCMD /etc/nut/notifycmd.sh
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
become: true
- name: Copy the notify shell script
copy:
src: notifycmd.sh
dest: /etc/nut/notifycmd.sh
mode: 0755
owner: root
group: nut
become: yes
And the notify script
#!/bin/bash
sendmail=/usr/sbin/sendmail
email=rlkoshak@gmail.com
to='To: '$email'\n'
from='From: '$email'\n'
hostname=$(uname -n)
subject='Subject: NUT ALERT: '$NOTIFYTYPE'\n\n'
body='Alert type: '$NOTIFYTYPE
msg=${to}${from}${subject}${body}
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.
2 Likes