[Nut-upsuser] Belkin Regulator Pro dropping connection and halting

[Gene Heskett]

On Thursday, December 02, 2010 10:05:54 am Arjen de Korte did opine:

> Citeren Arnaud Quette <aquette.dev at 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

I've been sitting here following this thread and wondering if the OP has 
told us everything?  He may indeed be using serial at the ups, but if he 
has a pl2303 ser-usb adapter in the signal path and is using a ttyUSB# 
connection, then there could be a possibility that the pl2303 adapter is 
eating his lunch, specifically the first byte of a packet at frequent 
intervals, and this will confuse virtually all upsd implementations 
regardless of whose upsd it is, including belkin's own, now Jurassic dated 
bulldog software.

Most of the more modern belkin UPS's do conform to the usb-hid specs, and I 
have had zero problems with loss of comm with mine over a pure usb circuit.

usb 2-9: new low speed USB device using ohci_hcd and address 5
usb 2-9: New USB device found, idVendor=050d, idProduct=0751
usb 2-9: New USB device strings: Mfr=4, Product=20, SerialNumber=0
usb 2-9: Product: Belkin UPS
usb 2-9: Manufacturer: Belkin

It is a 1500 WA rated device also.

I have another 1500WA rated Belkin, several years older and on its 4th set 
of batteries, that either isn't usb-hid con-formant, or when I last tried 
to run Nut against it, Nut's usb-hidraw wasn't up to speed.  It is now 
running my milling machines computer.  That computer is running 
Ubuntu-10.04, but emc is fussy about what you plug into a usb port, a usb 
key for instance is a guaranteed wrecked part because of the huge IRQ 
lockout times associated with the challenge/response time of the key as the 
I/O scheduler makes sure all the caches associated with have been flushed.

That is from lessons learned while talking to myself. ;-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Intel CPUs are not defective, they just act that way.
		-- Henry Spencer