Citeren Marco Chiappero <[email protected]>:
When you read the corresponding values from the summary page, the
values are reversed however. If we would parse the summary page
between these alarms (be it right after parsing an alarm or just
before receiving the next), with every new incoming alarm, the
previous status would be reset again. So if we want to keep the
alarms as they are, we should disregard the values set by the
summary page. However, since the above alarm bits are never cleared
by an alarm message after the test, this would mean that pressing
this test button once would effectively permanently disable the
outlet.
Well, the test is supposed to perform a shutdown, so it's assumed
that NUT is restarted. I see no problem in this behaviour.
There is no guarantee that the machine where the driver is running on
is also powered by the UPS. Most systems administrators like NUT
because it allows you to centralize UPS monitoring from a single
machine. Allowing the above would mean that each NMC would require a
dedicated machine to run the driver on. This pretty much defeats the
whole purpose of NUT.
I compiled your code yesterday evening, everything looks fine but I
noticed that every 180 secs a new subscription is made: is there a
reason for this?
The only reason could be that the driver is not getting alarm
messages. The driver should periodically receive empty alarm messages
from the NMC. If it doesn't, it assumes the connection is somehow lost
and subscribes again. Do you see the empty alarm messages if you run
the driver with -DD enabled?
And I see that +20-25% more traffic generated.
This could be the case since we poll both the summary and get_object
pages for each pollinterval. If this interval is short, you may notice
an increase compared to the previous code non-subscribed mode. The
only reason for adding the NSM subscribed mode, is to allow increasing
the pollinterval. If you keep it at something like 5 seconds, there is
no point in NSM subscriptions.
Thinking a little bit, I would just read alarm messages and the
get_object page: when everything is fine extended data is updated
once every pollinterval and the relevant one immediately by the
alarm messages, when the UPS goes on battery we can scan the summary
page too, frequently.
We're only reading the summary page because for some NMC models it
contains info the get_object page doesn't (environmental info mostly,
but some other things as well). Previously we would poll the summary
page only one out of ten calls. This is sufficient if the pollinterval
is short, but now that we poll much less frequently (pollinterval =
64), we should poll both at the same time.
Best regards, Arjen
--
Please keep list traffic on the list
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
