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

[John Bayly]

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<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. ;-)
>
Nope, it's definately serial, UPS is on the D9 port (/dev/cuad0). I'm 
using the belkin driver, not the belkinunv or usb-hid drivers. 
Unfortunately Belkin seem to have disavowed all knowledge of the device 
as it's nowhere to be found on their website. Best description of it on 
a reseller's site: 
http://uk.insight.com/p/497211/belkin-regulator-pro-network-ups-ups-1400-va.html