First of all when you have multiple upses connected to a computer
you have to distinguish between local-powering upses and remote power lines.
This is important because the do_events code will do the events only for
the local ups. Local ups is a generic concept that works both on the server
and on the clients.
Let's say that PC1 is connected to UPS1 and UPS2.
UPS1 is powering PC1
UPS2 is powering PC2
so
UPS1 is local to PC1
UPS2 is local to PC2
local is "who is powering me". This said, the apcupsd will treat hard and net-connected upses in the same way.
UPS1 and UPS2 are hard to PC1
UPS2 is net to PC2
But hard and net connections are transparent to the do_actions code so the same do_action is called on
PC1 (for UPS1 that is local and hard)
PC2 (for UPS2 that is local and net)
From this explanation you see that
PC1 must know 2 UPSES: UPS1 and UPS2, the config file must describe
both UPS1 and UPS2 that are hard.
PC2 must know 1 UPS: UPS2, and its config file describe only UPS2 that
is net.
This raises another matter: net must be like hard because PC2 must know
the exact same infos that PC1 knows about UPS2.
Another matteris that net must be multi-ups because if you think at
this config:
PC1: UPS1 (hard, local), UPS2 (hard), UPS3 (hard)
PC2: UPS2 (net, local)
PC3: UPS3 (net, local)
you see that net must be multi-ups. From this, if we are brave enough (and I WANT to be this way .. brave), we can think of this configuration:
PC1: UPS1 (hard, local), UPS2 (hard), UPS3 (hard), UPS4 (hard)
PC2: UPS2 (net, local)
PC3: UPS3 (net, local)
PC4: UPS4 (net, local)
PC5: UPS1 (net), UPS2 (net), UPS3 (net), UPS4 (net)
where PC5 is simply a monitor .. may be on the other side of a firewall where the 4 UPSes can be monitored, 1 hop away from the real machine. This allow us to monitor over the internet in a secure way. PC5, due to the transparency of hard/net connections, knows exactly what PC1 knows and can give any info over the net. In fact PC5 do not have any local ups: it works only as an "apcupsd gateway" of information about the upses. And look .. the difference between hard and net in the config file is:
hard: DEVICE /dev/ttyS4
net: DEVICE 192.168.1.31:7777
no special switches in config file, net and hard devices are only devices, no matter if one is serial wire and the other is ethernet wire.
The implementation comes directly from this design.
The config file for multi ups is divided in two sections.
My config file do have this layout:
<global parameters>
upsstart <name>
<ups parameters>
upsend <name>
This allows us to add as many upses as we want. On the other side, when a single ups is connected, upsstart/upsend is still needed. I didn't wanted to make a special case for single ups to avoid this pair. If you don't like this, I'm sure we can write a special-case for single ups where we don't require upsstart/upsend.
As I said, network must be reviewed. When you connect to the net server you have to ask for one of the upses it knows. So I have decided to rewrite network from scratch to use a much cleaner concept of client/server instead of master/slave. Single daemon, net connections always opened, character based interface (sendmail, pop3, nntpd, control connection of ftp .. you see we have many examples of this), multi-ups support, id/pw authentication, tcp wrappers, selection of net interfaces for listening. All things that with the old networking was a bit difficult to handle. Now they are, but if you don't like this way of handling network, I'm sure we can accomodate the old networking for handling all of these (except character based interface that is a design choice).
The old cgi code is still working but with time I want to rewrite it
to make use of the new network interface: no need to have many servers.
But of course it's no problem in keeping the old cgi networking forever
.. but even this must be changed to handle multi-ups.