On Thursday, December 02, 2010 04:36:43 pm John Bayly did opine:
> On 02/12/2010 15:28, Gene Heskett wrote:
> > On Thursday, December 02, 2010 10:05:54 am Arjen de Korte did opine:
> >> Citeren Arnaud Quette:
> Thanks for the suggestions, I've added the flush statement as well
> as some
On 02/12/2010 15:28, Gene Heskett wrote:
On Thursday, December 02, 2010 10:05:54 am Arjen de Korte did opine:
Citeren Arnaud Quette:
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 th
On Thursday, December 02, 2010 10:05:54 am Arjen de Korte did opine:
> Citeren Arnaud Quette :
> >> 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 repeate
On 02/12/2010 10:54, Arjen de Korte wrote:
Citeren John Bayly :
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.
Can you suggest what driver would be a good template to use?
Take a
Citeren John Bayly :
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.
Can you suggest what driver would be a good template to use?
Take a look at the upsdrv_updateinfo() function
On 02/12/2010 10:08, Arjen de Korte wrote:
Citeren Arnaud Quette :
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 d
Citeren Arnaud Quette :
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 th
2010/12/1 John Bayly
> On 01/12/2010 14:17, Arjen de Korte wrote:
>
>> Citeren Charles Lepple :
>>
>> 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
On 01/12/2010 14:17, Arjen de Korte wrote:
Citeren Charles Lepple :
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
Citeren Charles Lepple :
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 t
On Dec 1, 2010, at 7:42 AM, John Bayly wrote:
I've a Belkin Regulator Pro (F6C1400-EUR) connected via serial to a
FreeBSD machine using NUT v.2.4.3
Sometimes I get a series of logged messages saying that the data is
switching between stale and valid, this in itself isn't an issue,
however
I've a Belkin Regulator Pro (F6C1400-EUR) connected via serial to a
FreeBSD machine using NUT v.2.4.3
Sometimes I get a series of logged messages saying that the data is
switching between stale and valid, this in itself isn't an issue,
however occasionally when the communication is re-establis
12 matches
Mail list logo
