Thank you for your reply and help.
I admit to still learning how to use NUT.
My general NUT-use plan is as follows: the NUT server Pi controls a number
of network devices; router, VoIP, mesh pod, fiber connection, etc., but no
computers other than the Pi server. It would shut down last. The client
Pi controls two PCs and would shut down first after shutting down its
attached devices. If this is not workable, please let me know.
I have made the change to the client's* ups.conf *adding the entry for
APCES750 [and keeping it on the server's* ups.conf*]. However, I am now
getting this message set when I run *sudo service nut-client status* on the
client:
*UPS [APCES750 at 192.168.101] connect failed: Connection failure: Network is
unreachable*
*Master privileges unavailable on UPS [APCES850 at 192.168.1.100
<APCES850 at 192.168.1.100>]*
*Response: [ERR ACCESS-DENIED]*
*UPS [ [APCES750 at 192.168.101] connect failed: Connection failure:Connection
refused*
* UPS [ [APCES750 at 192.168.101] connect failed: Connection
failure:Connection refused *
* UPS [ [APCES750 at 192.168.101] connect failed: Connection
failure:Connection refused *
* UPS [ [APCES750 at 192.168.101] connect failed: Connection
failure:Connection refused *
* UPS [ [APCES750 at 192.168.101] connect failed: Connection
failure:Connection refused *
Which looks like some kind of authentication problem. Maybe.
Bill Cole
On Wed, Jan 26, 2022 at 8:53 AM Charles Lepple <clepple at gmail.com>
wrote:
> 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
--
Fredericksburg, VA
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220126/9cc7182f/attachment.htm>