[Nut-upsdev] MGE NMC and NutShutdownModule (and other stuff)

[Arjen de Korte]

Citeren Marco Chiappero <marco op absence.it>:

>> Never mind. The alarm messages are not bound to a specific outlet,  
>> but are sent to all NSM clients that are connected.
> The NMC will send some alarm messages rather than others depending  
> on the outlet the client system it is attached to.

This is what I expected too, but from what I have observed when trying  
this out, this doesn't seem to be the case. If we poll for the XML  
summary pages after receiving an alarm, the discussion is moot anyway,  
since so far I have not seen any alarms that are not also available  
through polling the NMC.

> For example, if I remember correctly, I've seen a computer connected  
> to a programmable outlet receiving both  
> System.Outlet[1|2].RunTimeToShutdown and System.RunTimeToShutdown  
> messages, while a client on the main outlet receiving only the latter.

This is not what I observed.

>> Which means that a single connected driver can handle the alarm  
>> messages for all outlets.
>
> Well, alarm messages are host specific. That said, I can't  
> understand why we should need to read messages for outlets we are  
> not even using... Is there a reason for connecting a single host to  
> many outlets of a single ups?

Yes. This is how NUT is supposed to work. In larger installations,  
there usually will be only one upsd server that monitors a UPS and all  
systems that are powered by this UPS will only talk to this upsd  
server. When using non networked interfaces like USB or RS-232 this is  
of course mandatory, since other hosts will have no way to communicate  
with the UPS themselves. This is the very essence of NUT (driver <->  
server <-> client).

Using a networked UPS would indeed allow each host to talk to the UPS  
(NMC in this particular case). However, in that case the layered  
structure we use is overly complex. If you don't want the centralized  
upsd server, it would be much easier to just write an NSM client from  
scratch. This would remove quite a bit of overhead and people would  
only have to setup a single NSM client, instead of having to configure  
a driver, a server and a client.

[...]

> We still need a small polling interval if we want to keep things  
> easy and use a non blocking read from the socket. However this  
> implies more "work" on the client side only.

Not at all. Search the developer documentation for the 'extrafd' file  
descriptor that is used by drivers. Basically, this allow you to  
wakeup from the polling interval and run upsdrv_updateinfo() if  
something interesting happens on a socket. Adding

     extrafd = ne_sock_fd(sock);

after subscribing to the NMC will trigger reading the alarm  
immediately, regardless of the pollinterval that is defined. This (and  
as far as I can see now, only this) is why having NSM subscriptions is  
a good idea. All data that is sent through alarms is available through  
polling too as far as I can see now.

>> It looks like the connected clients need to determine themselves  
>> (based on the timer values) when to shutdown the host they are  
>> running on. Apparently, the decision when to shutdown is made by  
>> the NSM client, this is not signaled directly by the NMC.
> As far as I can say here, with my firmware revision, it doesn't work  
> like that. The client provides its own shutdown settings (local or  
> centralized - if centralized it needs to retrieve them before  
> subscription), then the NMC does calculations and commands shutdown  
> with an alarm (level 3) containing the  
> UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit=1 object.

This is what happens if you trigger a shutdown test. But if you switch  
off an outlet through the UPS Controls page, it will never reach that.

> The only degree of freedom (and decision) in the clients lies in  
> performing a specific action rather than another (or no action at  
> all) upon reception of a certain alarm message. Clients are  
> "stupid", as it should be.

For simple configurations this may be true, but for more complex ones  
both MGE/Eaton and I disagree with you here and clients should make  
the decision to shutdown themselves. Note that no matter how many  
hosts connect to a socket, they will all lose power at the same time.  
So some devices with a complex shutdown procedure may need more time,  
while others will need less time. You could be running a separate NMS  
client for each (with different settings), but this is not how NUT  
works. Basically what my objection is, that you're writing a NSM  
client using the layered NUT architecture. Although technically  
possible (you've already proven this), this doesn't fit in the one  
driver, one server, many clients approach that is the very basis of NUT.

Best regards, Arjen
-- 
Please keep list traffic on the list