2010/12/1 John Bayly <[email protected]> > On 01/12/2010 14:17, Arjen de Korte wrote: > >> Citeren Charles Lepple <[email protected]>: >> >> The get_belkin_reply() function looks fragile to me. Three seconds should >>> be >>> enough to fill the buffer, but if you put a few upsdebugx() calls around >>> ser_get_buf_len(), it should be evident whether the read is timing out, or >>> if there is a problem with the format of the response. >>> >> >> Starting with >> >> ser_flush_io(upsfd); >> > 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). cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
