Hello, We have a Tripplite SMART1500RMXL2U and nut-2.2.0-6.el5 installed on Centos 5.3. I've been unsuccessful on getting upsmon to work. usdrvctl seems to start despite some warnings/errors: # upsdrvctl start smart1500 Network UPS Tools - UPS driver controller 2.2.0- Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11.1 (2.2.0-) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: TRIPP LITE/ Tripp Lite SMART1500RMXL2U libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 libusb_get_interrupt() returned -110 instead of 8 Unit ID: 257 Unknown protocol (4)Attached to Tripp Lite Tripp Lite SMART1500RMXL2U upsd looks okay, I'm not sure about upsc: # upsd Network UPS Tools upsd 2.2.0- listening on 0.0.0.0 port 3493 Connected to UPS [smart1500]: tripplite_usb-smart1500 # upsc smart1500 at localhost battery.voltage.nominal: 48 driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.2.0- driver.version.internal: 0.11.1 input.voltage.nominal: 120 outlet.1.desc: Load 1 outlet.1.id: 1 outlet.1.switch: 1 outlet.1.switchable: 1 outlet.2.desc: Load 2 outlet.2.id: 2 outlet.2.switchable: 0 ups.debug.0: 00 04 58 58 58 58 0d '..XXXX.' ups.debug.D: 37 38 38 38 0d 00 00 '7888...' ups.debug.L: 31 38 46 43 45 34 0d '18FCE4.' ups.debug.load_banks: 1 ups.debug.M: 30 32 38 32 0d 00 00 '0282...' ups.debug.S: 31 34 30 32 31 30 0d '140210.' ups.debug.T: 39 30 30 32 35 39 0d '900259.' ups.debug.V: 31 30 38 31 0d 00 00 '1081...' ups.delay.shutdown: 64 ups.firmware: F0970.B ups.firmware.aux: protocol 0004 ups.id: 257 ups.mfr: Tripp Lite ups.model: Tripp Lite SMART1500RMXL2U ups.power.nominal: 150 ups.status: I start upsmon anyways but get the following, I lose communication immediately.: Client monuser at 127.0.0.1 logged into UPS [smart1500] Communications with UPS smart1500 at localhost lost Is this because the protocol is unknown? I found stuff on the archive and changelog that indicate it may be fixed on nut-2.4.1, but I can't find any rpms for Centos 5.3. Is there an easier way than building an rpm? Thank you, Dianne -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090605/ecfe382c/attachment.htm>
On Fri, Jun 5, 2009 at 2:15 PM, Dianne Yumul<Dianne at wellsgaming.com> wrote:> Hello, > We have a Tripplite SMART1500RMXL2U and nut-2.2.0-6.el5 installed on Centos > 5.3. I've been unsuccessful on getting upsmon to work. > usdrvctl seems to start despite some warnings/errors: > # upsdrvctl start smart1500 > Network UPS Tools - UPS driver controller 2.2.0- > Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11.1 (2.2.0-) > Warning: This is an experimental driver. > Some features may not function correctly. > Detected a UPS: TRIPP LITE/ Tripp Lite SMART1500RMXL2U > libusb_get_interrupt() returned -110 instead of 8 > libusb_get_interrupt() returned -110 instead of 8 > libusb_get_interrupt() returned -110 instead of 8[...] At some point between 2.2.0 and 2.4.1, a retry count was increased, which would reduce the number of timeout (-110) errors. Also, in recent versions, the "unit.id" setting is not retrieved if you are using Protocol 4.> ups.status:The "ups.status" value is problematic - it should include at least OL or OB. Not sure whether it is due to Protocol 4-related changes, or the aforementioned timeout.> I start upsmon anyways but get the following, I lose > communication immediately.: > Client monuser at 127.0.0.1 logged into UPS [smart1500] > Communications with UPS smart1500 at localhost lost > Is this because the protocol is unknown? I found stuff on the archive and > changelog that indicate it may be fixed on nut-2.4.1, but I can't find any > rpms for Centos 5.3. Is there an easier way than building an rpm?It may not be too hard to modify the RPM file to use the NUT 2.4.1 source tarball instead of 2.2.0. -- - Charles Lepple
Citeren Charles Lepple <clepple op gmail.com>:>> ups.status: > > The "ups.status" value is problematic - it should include at least OL > or OB. Not sure whether it is due to Protocol 4-related changes, or > the aforementioned timeout.The above is due to a problem with calculation of the size of reports in libhid.c that was fixed more than a year ago. This fix requires nut-2.2.2 or newer. For many USB devices, anything earlier than that may mean that they run into this limitation (that existed since we first released newhidups by the way). Best regards, Arjen -- Please keep list traffic on the list
On Sun, Jun 7, 2009 at 12:51 PM, Arjen de Korte<nut+users at de-korte.org> wrote:> Citeren Charles Lepple <clepple at gmail.com>: > >>> ups.status: >> >> The "ups.status" value is problematic - it should include at least OL >> or OB. Not sure whether it is due to Protocol 4-related changes, or >> the aforementioned timeout. > > The above is due to a problem with calculation of the size of reports in > libhid.c that was fixed more than a year ago. This fix requires nut-2.2.2 or > newer. For many USB devices, anything earlier than that may mean that they > run into this limitation (that existed since we first released newhidups by > the way).Arjen, Are you sure this applies to pseudo-HID devices too? I agree that a newer version of NUT will include a version of tripplite_usb that should work better, but that driver only uses a few libhid.c functions for matching devices. -- - Charles Lepple