similar to: Multiple instances of the same model, with same ID and no serial number!

On Jul 10, 2014, at 1:00 PM, Steve Ballantyne <steve.ballantyne at gmail.com> wrote: > How is this for a conundrum? > > I have three Tripp-Lite SMART5001U's running in the same one rack, > attached to the same host running NUT. I am running the tripplite_usb > driver thanks to some crafty hacking of Charles (thank you sir!). Sounds like we can merge that branch into

On Thu, Jul 10, 2014 at 10:33 PM, Charles Lepple <clepple at gmail.com> wrote: > Sounds like we can merge that branch into master? I thought I had discovered a firmware difference (or something) because I couldn't get the battery tests to run. But then I realized that I wasn't running the actual test under the right user, with the right permissions. Duh. So I then went back

<nut-upsuser at lists.alioth.debian.org> I am doing my best to avoid have to spend $280 for a network monitoring card to put into a $190 UPS just to have some good remote monitoring capabilities. Rather, I would like to monitor my many 1U Tripp Lite's on my network using a Raspberry Pi running Raspian and using NUT. However, I cannot seem to get it working. And I while the hardware

Hello Charles, Thanks for the feedback. I will try to answer some of these questions: > 09AE/0001 is essentially a USB-to-serial converter, and is not > compatible with usbhid-ups. (Theoretically, we could have a companion > driver that talks the same protocols over a real RS-232 port, but the > hardware I used to develop the tripplite_usb driver only has a USB > port.) Ah, that

> Lots of good progress here! I tried to enable a few more commands for > your model. For instance, the "M" values seem to be min/max voltage, > so there is a "reset.input.minmax" command to use with upscmd. Also, > you can trigger a battery test with "test.battery.start". I assume the > work the same way as on Protocol 3003 :-) Hello Charles, The

Hello Charles, Thank you for all of your help this far. I have made some great progress. I was hung up with all sorts of USB problems which we can chalk up to a "blonde moment" for me (or more accurately, a *bald* moment). In all my starting over and screwing around, I had forgotten to reinstall libusb-compat. Duh! I am now to a point that I think we can dig a little deeper. The

> Lots of good progress here! I tried to enable a few more commands for > your model. For instance, the "M" values seem to be min/max voltage, > so there is a "reset.input.minmax" command to use with upscmd. Also, > you can trigger a battery test with "test.battery.start". I assume the > work the same way as on Protocol 3003 :-) > > The attached

Hey Charles, Many months ago you assisted me in making some code changes to get my Tripp Lite up and running. Thank you for that. Those changes you committed to the repository work very well. I just built a new image for a Raspberry Pi running the latest Raspbian OS and the latest nut-master. I have everything working ... except I seem to be losing my device periodically. So if I enable my

On Thu, Jun 26, 2014 at 10:20 PM, Steve Ballantyne <steve.ballantyne at gmail.com> wrote: >> However, we don't have all of the 09AE/0001 protocols decoded in the >> tripplite_usb driver. > > I can try to help out on this front? :-) Definitely. >> > 9.783126 Unknown input voltage range: 0x02 >> > 9.783308 Unknown number of switchable

On Thu, Jan 8, 2015 at 11:37 PM, Charles Lepple <clepple at gmail.com> wrote: > Although this tends to happen more with x86 systems and/or USB3, you might want to see if the disconnects are less frequent with a shorter or higher-quality USB cable. The more I look into this ... the more I think that it's exclusively Tripp-Lite weirdness! There are some things that I explored as far

On Tue, Jan 6, 2015 at 9:46 PM, Charles Lepple <clepple at gmail.com> wrote: > However, for the notifications, you could use "upssched" to only notify you if the UPS is disconnected for longer than the usual reconnection time. > Hello Charles, For my purposes, I will take an even easier route to resolution ... I will just comment this line out of my upsmon.conf file.

On Jan 7, 2015, at 12:49 PM, Steve Ballantyne <steve.ballantyne at gmail.com> wrote: > I would like to get to the root of the problem though. I may tweak > the code a bit and see if I can get better results. Although you are > right about the broken pipe. If the device is "unplugging" ... not > much you can do to fix that other than to just ignore it. Although this

Hello Charles, I think we are making progress! I grabbed nut using git, and applied your patch without any problems. Getting to the point that I could run a configure on my RPi - was something else. I found this blog post, which was very helpful (for anyone else that may try it): http://atelier-orchard.blogspot.com/2013/11/raspberry-pixf86-video-fbdev.html It's not in English, but you get

On Jan 6, 2015, at 3:44 PM, Steve Ballantyne <steve.ballantyne at gmail.com> wrote: > Does this snippet of a failure tell you anything? Is there something > I can do to tell the libusb to wait a little longer for the device to > come back? > > 3118.555755 libusb_get_interrupt: Connection timed out > 3118.557454 libusb_get_interrupt() returned 0 instead of 8 while

On Sun, Sep 28, 2014 at 4:32 PM, Kristian Rasmussen <kristian_rasmussen at fastmail.co.uk> wrote: > The entire command should be on one continuous line, and the double > quotes need to stay. I probably should have posted this as a pastebin link to retain carriage returns and such. Mailing lists have a way of mangling stuff like this. :-) Try this: http://pastebin.com/2hTBU8XF

On 28.09.2014 22:22, flavio wrote: > I follow your tutorial untill this instruction: > > wget "http://downloads.sourceforge.net/project/libusb/libusb-1.0/libusb- > 1.0.18/libusb-1.0.18.tar.bz2? > r=http%3A%2F%2Fwww.libusb.org%2F&ts=1404210716&use_mirror=softlayer-ams" > -O libusb-1.0.18.tar.bz2 > > in my opiniono there are 2 " that are not needed and

On Tue, Jul 1, 2014 at 9:17 AM, Steve Ballantyne <steve.ballantyne at gmail.com> wrote: > How would I go about providing you this stuff? Can you point me to > something that would help trace out the USB data? I thought I would try to make sense of the ups.debug data. All I have really figured out is that the fourth hex segment for S is a 00 for plugged in and a 01 for on-battery.

I installed nut from the epel repository on Scientific Linux 7. I would like to get my smart500rt1u working, but # upsc smart500 at localhost gives the following output: battery.voltage.nominal: 0 device.mfr: Tripp Lite device.model: SMART500RT1U device.type: ups driver.name: tripplite_usb driver.parameter.pollinterval: 5 driver.parameter.port: auto driver.version: 2.7.2 driver.version.internal:

On March 6, 2015, at 6:17pm, Charles Leppe ,cleppe at gmail.com> wrote: If this is the same protocol 3005 that we saw in mid-2014 (USB ID: 09AE:0001), then support will be part of the upcoming NUT 2.7.3 release. You wouldn't happen to know anyone who would be able to publish the specs of that protocol, would you? ;-) That would help remove the "experimental driver" warning.

I think I may be of some help in this matter. Since I am running a bunch of Raspberry Pi's with NUT and it took a lot of hacking to make it possible. You could probably copy and paste this right into a shell script and just run it ... # Do an rpi-update FIRST to prevent USB strangeness #some depencies from repo sudo apt-get -y install m4 libtool libudev-dev automake #fixing autoconf for