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
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
