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<[email protected]>: > >>>> 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
That appears to be the Euro version of my older one, same box and front panel. And my snmp slot was empty, so I did not re-install the card slot for it when I last had it apart last spring to replace the batteries. I had to dismantle it quite far as the old ones had swelled and were bound in the frame. This one does not have a usb port, although it looks as if there might be a 9 pin usb header on its controller board, a dual row of 5 with one of the end pins missing. In fact, I wonder if a std computer breakout, back panel to motherboard usb kit might actually work? I have a spare of those, and the next time I haul it off the shelf (its 6+ feet up in the air, sitting on a brace across the rafters in my shop building, and pretty heavy for the old man to get it down & back up), so I might just see what I blow if I hook it up to a usb port. I will probably be needing batteries again by then, and if I let the smoke out or break the mirror, I have had close to 10 years out of it anyway. -- 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) I'm totally DESPONDENT over the LIBYAN situation and the price of CHICKEN ... _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
