Hi, Arnaud Thank You for Your kind answer.
I attempted to use USB, as You suggested. After connecting the cable, kernel detects HP R 5000 as HID like this: [ 1701.100025] usb 2-1: new full speed USB device using ohci_hcd and address 2 [ 1701.324982] usb 2-1: New USB device found, idVendor=03f0, idProduct=1fe7 [ 1701.324985] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 [ 1701.324989] usb 2-1: Product: HP R5000 [ 1701.324991] usb 2-1: Manufacturer: HP [ 1701.324992] usb 2-1: SerialNumber: 3C81520083 [ 1701.325147] usb 2-1: configuration #1 chosen from 1 choice [ 1701.391326] usbcore: registered new interface driver hiddev [ 1701.433359] generic-usb: probe of 0003:03F0:1FE7.0001 failed with error -22 [ 1701.433395] usbcore: registered new interface driver usbhid [ 1701.433460] usbhid: v2.6:USB HID core driver Although generic-usb fails with error -22, I hope this should not be a problem, since next lines, usbcore and usbhid show no no sign of trouble. I set ups.conf like this: protocol = usbhid-ups port = auto However, starting upsdrvctl shows this error: Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 No matching HID UPS found Driver failed to start (exit status=1) Should I use some exact vendor specification in ups.conf and if, what should it be? Or is there other source of trouble? cheers, Peter ----------------Pôvodná správa----------------- Od: "Arnaud Quette" [email protected] Komu: "Peter Tuhársky" [email protected] Kópia: [email protected] Dátum: Thu, 29 Mar 2012 18:38:17 +0200 ------------------------------------------------- > Hi Peter, > > sorry for the lag in answering... crowded week. > > One thing bothers me. I don't see parameters like "battery.runtime.low" >> here. How will the UPS notice the NUT that it is running critically low? Or >> better said, when will it do that? >> >> With APC, there is such parameter, default set to 120 seconds. As I >> understand, when battery goes critically low (2 minutes before getting >> fully discharged), it sends "battery critical" to the NUT server, and the >> NUT sends "shutdown" command to clients. >> > > that's it. > > However with the HP, either R5000 or R5500, there is no such parameter, and >> I even didn't find it in web interface settings. There is quite opposite >> setting possible (custom): how many seconds AFTER the UPS goes battery, >> should it switch off. This is quite illogical, though. >> > > a fallback option is to use upssched: > > http://www.networkupstools.org/docs/user-manual.chunked/ar01s07.html > #_the_advanced_approach_using_upssched > > If you, for example, have 10 mn of runtime, and need 2 mn to shutdown the > system, then you would declare a (max) 8 mn timer when switching on battery. > > So, I'm afraid a bit doing UPS fullscale test because I don't know, whether >> servers will have enough time to shutdown before UPS switches itself off. I >> know I will face it in future, however need more info now. >> > > your remarks are valid! > I entered the round lately on this driver, following Eaton acquisition of > MGE OPS. > The thing is that, since that time, the various redundant Eaton protocols > coming from Eaton or MGE (Ie serial XCP Vs SHUT, USB XCP Vs USB/HID, ...) > have seen some decision: XCP has been superseded by SHUT and HID. > My main focus has so gone to these, though I've also been putting some > efforts to improve the XCP driver. > > So, mge-shut and usbhid-ups (Eaton and derivative products) provide support > for lot more data and features. > battery.runtime.low is for example supported. > And R5000 is supported by usbhid-ups through the USB port. > > Otherwise, there are still planned improvement for XCP (and a lot around > configuration). > The best would be a driver rewrite, but I've currently not enough resources > to staff one on this. > But I think I've identified what should be mapped battery.runtime.low. > So I you really want to go the XCP way, let me know and I'll check what I > can do. > One thing that may help is to tell HP that you want a better NUT support... > > I hope this will shed some light on this, and provide you at least a > suitable solution. > > cheers, > Arnaud > -- > Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com > Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ > Debian Developer - http://www.debian.org > Free Software Developer - http://arnaud.quette.free.fr/ > _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
