[Nut-upsuser] NUT Client Not Working, Server OK
Charles Lepple
clepple at gmail.com
Wed Jan 26 13:53:22 GMT 2022
On Jan 25, 2022, at 2:51 PM, William Cole via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:
>
> I hope that this is an appropriate post for this group. Please let me know if it should go elsewhere.
Yes, this is a good place to ask general questions. However, you may want to subscribe to the list, at least temporarily, so that we do not need to manually approve your messages:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
As such, you may have missed Roger's reply which looks like it went only to the list: https://alioth-lists.debian.net/pipermail/nut-upsuser/2022-January/012666.html
> I am running NUT on RaspberryPi 3B+ [RPi] units using Buster. The NUT version is 2.7.4.
Thanks for the info.
>
> I have two UPS's in two different physical locations. Each is attached to its own RPi.
> Both UPS's are APCs but of different models.
>
> I have one APC attached to an RPi w/NUT configured as a server with the following script entries:
> ---------------------------------
> nut.conf
> MODE=netserver
>
> ups.conf
> [APCES850Server]
> driver=usbhid-ups
> port=auto
> desc=”APC ES850”
> serial=4B2037P49872
> pollinterval=15
> vendorid=051d
> [APCES750Client]
> driver=usbhid-ups
> port=auto
> desc=”APC ES750”
> serial=3B0907X16989
> pollinterval=15
> vendorid=051d
It looks like you have the syntax correct for ups.conf, but the USB details like the serial number and vendorid should go in the ups.conf on the Pi that is directly connected to that UPS.
You can think of the client/server setup as follows: the server is providing the UPS status over the network to the clients, much as a simple file server has a local disk, and the files on that disk are available to other clients of that server.
>
> upsmon.conf
> MONITOR APCES850Server at 192.168.1.100 1 upsmon LASTPASS master
> MONITOR APCES750Client at 192.168.1.101 1 upsremote LASTPASS slave
>
> Usual entries for upsd.conf and upsd.users.
> -------------------------------
> The other APC is attached to a different RPi w/NUT configured as a client with the following script entries:
> -------------------------------
> nut.conf
> MODE=netclient
>
> ups.conf
> [no entries]
>
> upsmon.conf
> MONITOR APCES850Server at 192.168.1.100 1 upsmon LASTPASS master
> MONITOR APCES750Client at 192.168.1.101 1 upsremote LASTPASS slave
> ------------------------------
> The server works fine. The client will not connect, throwing a "UPS APCES750Client at 192.168.1.101 is unavailable"error.
If you look at the service status on 192.168.1.100, you will probably see that upsd was not able to connect to the ES750 over USB on that Pi. Since there is no entry for the ES750 in ups.conf on 192.168.1.101, that is why you get the "UPS ... is unavailable" error.
$ systemctl status nut-server
● nut-server.service - Network UPS Tools - power devices information server
Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-01-14 21:07:31 EST; 1 weeks 4 days ago
Main PID: 2187 (upsd)
...
Jan 14 21:07:31 <hostname> upsd[2023]: Connected to UPS [apc]: usbhid-ups-apc
The part that Roger and I aren't sure of is how you intend the rest of the monitoring to work.
Should the second Pi shut down when the UPS on the first Pi is exhausted? Or do you just want to log the status remotely?
As far as terminology, we covered the server/client side of things. There is also a similar concept of master/slave (exact terms to be changed later) which is more about which upsmon server (the master) waits for other clients (the slaves) to shut down before it does. It's more like a captain on a ship waiting for everyone else to get on the life rafts safely (or the captain goes down with the ship). If you do not want to create extra dependencies between the two Pis, each can have a "master" entry in its upsmon.conf that points to the directly-connected UPS.
--
Charles Lepple
clepple at gmail
More information about the Nut-upsuser
mailing list