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

[Arjen de Korte]

Citeren Marco Chiappero <marco op absence.it>:

> Uhm are you saying we should subscribe even the netxml-ups driver to  
> lower NUT load? Maybe there's something I don't know yet about the  
> extrafd... but, shouldn't we make better to include the nsm code in  
> the netxml-ups driver/mge subdriver?

Yes, that's what I'm intending to do (and what I have already done for  
a large part already by the way). This will reduce the latency for  
changes in the power state to essentially zero. At the same time, we  
can increase the pollinterval to something like 60+ seconds or so.  
Receiving an alarm will then trigger a poll of the summary and/or  
get_object pages, to get all available data.

> However, only relevant data is sent over the NSM connection, if, for  
> example, "UPS.PowerConverter.Output.ActivePower" changes we're not  
> going to know it through alarm messages. But, at worst, it can  
> suffice to update that data every 60 seconds, which is reasonable.  
> Is it right? Is it what you meant?

Indeed. This still allows people who want to have more regular updates  
of whatever variable they want to get more frequent updates, but  
reduces the amount of polling we need to do when nothing critical is  
happing for most of the time. In order not to be left in the dark for  
too long, I intend to up the default pollinterval to something like 75  
seconds in the netxml-ups driver.

> I thought the NMC was using only udp broadcast messages but I'm  
> having some sniffing time and I discovered that, shutting down  
> outlet #2, much information is forwarded even to a host attached on  
> the main outlet. Everything but "System.Outlet[3].RunTimeToShutdown"  
> data (resulting in two empty messages for the connected client).  
> Interesting!

Yeah, this also surprised me. I too expected that the alarms where  
client based, but apparently this isn't the case. At least not for the  
NMC 66102 we're both using.

> [TCP]
> <ALARM level="1" object="UPS.PowerSummary.PercentLoad" value="39"  
> date="2009/11/03-11:59:46" messageID="5PAEI7">  </ALARM>
> <ALARM></ALARM>
> <ALARM></ALARM>
> <ALARM level="1"  
> object="UPS.OutletSystem.Outlet[3].DelayBeforeShutdown" value="125"  
> date="2009/11/03-11:59:56" messageID="6ZJJFK">  </ALARM>
>
> [UDP]
> <ALARM level="1" object="UPS.PowerSummary.PercentLoad" value="39"  
> date="2009/11/03-11:59:46" sessionID="53950" messageCount="22"  
> messageID="7KIWMV">  </ALARM>
> <ALARM level="3" object="System.Outlet[3].RunTimeToShutdown"  
> value="13" date="2009/11/03-11:59:50" sessionID="53950"  
> messageCount="23" messageID="1P31YU"> Group 2 system shutdown is  
> activated </ALARM>
> <ALARM level="3" object="System.Outlet[3].RunTimeToShutdown"  
> value="0" date="2009/11/03-11:59:52" sessionID="53950"  
> messageCount="24" messageID="59XJRJ"> Group 2 system shutdown is  
> activated </ALARM>
> <ALARM level="1"  
> object="UPS.OutletSystem.Outlet[3].DelayBeforeShutdown" value="125"  
> date="2009/11/03-11:59:56" sessionID="53950" messageCount="25"  
> messageID="H5RPLA">  </ALARM>

Interesting indeed.

> Have to investigate a bit more to be sure that  
> "UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit" object  
> is a host specific data. Then we should have a quite clear picture  
> of who is reading what. Well, for a simple UPS at least...

As far as I can see, the above value is not client specific. It would  
have been nice if it was (since that would allow us to easily see that  
the specific outlet was about to be shutdown), but as far as I can  
see, this is the global one (not outlet/client specific). What I'm not  
sure about, is what happens when you sent this via the UPS Controls  
page for a simulated shutdown event. It could very well be that this  
would be client specific in that case, but in practice this will be of  
little use for us. During an actual mains failure, it would only be  
raised when the batteries are almost flat. Since we would like to shed  
some loads on the two switchable outlets long before that (the whole  
point of this exercise), we probably can't use that.

>> We know when the timers are running (through the alarms) and we  
>> also know the shutdown duration requested on the outputs, so it  
>> shouldn't be too problematic to insert a FSD flag. I just wish the  
>> NMC would have used the ShutdownImminent flag that is supposed to  
>> tell this, but for some mysterious reason it doesn't seem to be  
>> used by the NMC.
> Yes and I agree. However, a question: if we use the FSD flag, in a  
> redundant configuration, and that UPS was not really necessary for  
> the system to live, doesn't it trigger the system shutdown in any  
> case?

No. A FSD flag only tells that this particular power source is about  
to lose power, it doesn't mean that a system that is monitoring this  
must shutdown. Here is where the MINSUPPLIES value in upsmon.conf  
comes into play. For instance, if you have two outlets that are  
powering a host of which at least one must be available, you'd give  
them a powervalue of 1 each and set MINSUPPLIES 1. During normal  
operation, this would give a total powervalue of 2. Only if both would  
fail, the total powervalue would drop to 0, which triggers a shutdown  
on the client. If only one fails, you still have a powervalue of 1.

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