Citeren Arnaud Quette <aquette....@gmail.com>:
Thanks for the suggestions, I've added the flush statement as well as some
debugging information. As this is a intermittent issue I decided to try
overloading the UPS by sending it repeated beeper commands while watching
the debug output. What appears to happen is that the UPS returns an unknown
"~00R000" response. This means get_belkin_reply() returns -1, causing a
datastale state is set when called from do_status().
you should remove the datastale() call since upsd will automatically flag
the device as stalled if it has failed to update its data for 15 seconds
(default of MAXAGE).
Not at all!
The upsd server will only declare the *driver* stale if it fails to
respond within MAXAGE seconds. However, as long as it keeps answering
the PING from the server, it will not be declared stale. This
mechanism is something completely different from what happens if the
driver calls dstate_datastale(). In that case the driver tells the
upsd server that the *UPS* fails to respond. See the chapter on
"Staleness control" in docs/new-drivers.txt.
What really needs to be done, is that the driver doesn't treat the
"~00R000" reply as an error condition. Apparently the UPS acknowledges
the receipt of data, without further response (indicating that 0 bytes
follow). The belkin driver doesn't accept this at the moment and
requires that a reply follows. This is what needs to be changed.
Last but not least, in most drivers, we allow a couple of missed
replies before we call dstate_datastale() so that glitches don't lead
to automatic reconnects.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
