Hi, I am trying to configure my Tripp Lite SU5000RT3U on Ubuntu 18.04 as I am not able to completely get all the data from the UPS. After installing all required packages from the Ubuntu repos (had to run sudo apt-get install dkms, I had to install the displaylink drivers from displaylink.org by doing sudo ./displaylink-driver-4.2.29.run, and I created a sim link by doing the following: sudo ln -s /usr/src/linux-headers-4.15.0-20-generic/include/generated/autoconf.h /usr/src/linux-headers-4.15.0-20-generic/include/linux/) and butchering a NUT configuration, I get the following output (after running upsc Tripp-Lite at localhost): Init SSL without certificate database battery.voltage.nominal: 48 device.mfr: Tripp Lite device.model: TRIPP LITE UPS device.type: ups driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.29 input.voltage.nominal: 208 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.switch: 1 outlet.2.switchable: 1 outlet.3.desc: Load 3 outlet.3.id: 3 outlet.3.switch: 1 outlet.3.switchable: 1 outlet.4.desc: Load 4 outlet.4.id: 4 outlet.4.switch: 1 outlet.4.switchable: 1 outlet.5.desc: Load 5 outlet.5.id: 5 outlet.5.switch: 1 outlet.5.switchable: 1 outlet.6.desc: Load 6 outlet.6.id: 6 outlet.6.switch: 1 outlet.6.switchable: 1 outlet.7.desc: Load 7 outlet.7.id: 7 outlet.7.switch: 1 outlet.7.switchable: 1 outlet.8.desc: Load 8 outlet.8.id: 8 outlet.8.switch: 1 outlet.8.switchable: 1 outlet.9.desc: Load 9 outlet.9.id: 9 outlet.9.switchable: 0 ups.debug.0: 00 05 58 58 58 58 0d '..XXXX.' ups.debug.D: 36 43 38 37 0d 00 00 '6C87...' ups.debug.L: 31 31 35 41 30 31 0d '115A01.' ups.debug.load_banks: 8 ups.debug.M: 30 30 37 31 0d 00 00 '0071...' ups.debug.P: 30 35 30 30 0d 00 00 '0500...' ups.debug.S: 31 34 30 30 30 30 0d '140000.' ups.debug.T: 39 31 32 35 37 31 0d '912571.' ups.debug.V: 33 30 38 38 0d 00 00 '3088...' ups.delay.shutdown: 64 ups.firmware: F1114.A ups.firmware.aux: protocol 0005 ups.id: 65535 ups.mfr: Tripp Lite ups.model: TRIPP LITE UPS ups.power.nominal: 500 ups.productid: 0001 ups.status: ups.vendorid: 09ae>From talking with the tech support, it seems that the protocol version forthis unit should be 0003 and not 0005. Is there a way to force the protocol version in the driver so I could test different results? Thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20180507/ba0d4de2/attachment.html>
Hi, I ported the serial tripplite.c driver to support the non-PDC USB models. It's a bit of a mess, but this is partially due to not getting any public documentation from Tripp Lite regarding these models. What you see below is an attempt to parse the debug variables based on what we know from other models. On May 7, 2018, at 3:33 PM, Michael <fax12345 at gmail.com> wrote:> > ups.debug.0: 00 05 58 58 58 58 0d '..XXXX.'The first two bytes are where the version (0005) is coming from. However, the NUT code only knows about a few protocols, and neither 0003 nor 0005 are among them: https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite_usb.c#L410-L433 It appears to be fairly similar to 0004, though.> ups.debug.D: 36 43 38 37 0d 00 00 '6C87...'https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite_usb.c#L1258-L1276 parses this into input.voltage and battery.voltage, but there is some weird scaling (or maybe even nonlinearity) going on with the input voltage. Does a nominal AC voltage of 208V or 240V sound right? The driver would probably calculate nominal battery voltage as 48V (using the "08" from ups.debug.V, times 6V). With the value above, you would have 0x87 * 48 / 12.0 = 54.0 Volts.> ups.debug.L: 31 31 35 41 30 31 0d '115A01.'Load might be 17% (0x11). I don't think we know what the other four digits are.> ups.debug.load_banks: 8The number of switchable outlets comes from the last '8' in the ups.debug.V string.> ups.debug.M: 30 30 37 31 0d 00 00 '0071...'These are probably input min/max voltages, which can often be reset by sending the 'Z' command.> ups.debug.P: 30 35 30 30 0d 00 00 '0500...' > ups.debug.S: 31 34 30 30 30 30 0d '140000.'Status '4' means that a battery test hasn't been done recently. Other values here: https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite_usb.c#L1152-L1180> ups.debug.T: 39 31 32 35 37 31 0d '912571.'0x257 = 599 = 59.9 Hz; the following '1' indicates a nominal value of 60 Hz. You might be able to extract temperature from the first two digits.> ups.debug.V: 33 30 38 38 0d 00 00 '3088...' >You would also want to test the shutdown command(s) to make sure that everything behaves as expected. With the OMNIVS1000 that I have here, it only supports a shutdown.return command with an offdelay, and it only works while on battery (so no cycling power if the power returns early). If you would like help patching in support for this protocol, let me know (reply-all so we can keep track of this in the list archives).
Hi Charles, I'll gladly help where I can. I did reach out to their product support, and I did not have install the displaylink driver as that is for a totally different product, so ignore all that. The 208 V makes sense. The unit spec designates it as a 208V input, and from looking at what we have in the server room, the battery is a 48VDC power source. For outputs, this UPS has (12) 5-15/20R; (2) L6-20R; (2) L6-30R, but according to the output that I posted, only 9 are detected. I'm new to this, so let me know what you need from me and I will try my best. This UPS does power our production servers, so shutting things down aren't an easy task, but this weekend might open up some opportunity for that if need be. If I need to test it by unplugging the main power, that I can do without problems. Thanks, Mike On Tue, May 8, 2018 at 8:06 AM, Charles Lepple <clepple at gmail.com> wrote:> Hi, I ported the serial tripplite.c driver to support the non-PDC USB > models. It's a bit of a mess, but this is partially due to not getting any > public documentation from Tripp Lite regarding these models. What you see > below is an attempt to parse the debug variables based on what we know from > other models. > > On May 7, 2018, at 3:33 PM, Michael <fax12345 at gmail.com> wrote: > > > > ups.debug.0: 00 05 58 58 58 58 0d '..XXXX.' > > The first two bytes are where the version (0005) is coming from. However, > the NUT code only knows about a few protocols, and neither 0003 nor 0005 > are among them: > > https://github.com/networkupstools/nut/blob/v2.7. > 4/drivers/tripplite_usb.c#L410-L433 > > It appears to be fairly similar to 0004, though. > > > ups.debug.D: 36 43 38 37 0d 00 00 '6C87...' > > https://github.com/networkupstools/nut/blob/v2.7. > 4/drivers/tripplite_usb.c#L1258-L1276 parses this into input.voltage and > battery.voltage, but there is some weird scaling (or maybe even > nonlinearity) going on with the input voltage. > > Does a nominal AC voltage of 208V or 240V sound right? > > The driver would probably calculate nominal battery voltage as 48V (using > the "08" from ups.debug.V, times 6V). With the value above, you would have > 0x87 * 48 / 12.0 = 54.0 Volts. > > > ups.debug.L: 31 31 35 41 30 31 0d '115A01.' > > Load might be 17% (0x11). I don't think we know what the other four digits > are. > > > ups.debug.load_banks: 8 > > The number of switchable outlets comes from the last '8' in the > ups.debug.V string. > > > ups.debug.M: 30 30 37 31 0d 00 00 '0071...' > > These are probably input min/max voltages, which can often be reset by > sending the 'Z' command. > > > ups.debug.P: 30 35 30 30 0d 00 00 '0500...' > > ups.debug.S: 31 34 30 30 30 30 0d '140000.' > > Status '4' means that a battery test hasn't been done recently. Other > values here: > > https://github.com/networkupstools/nut/blob/v2.7. > 4/drivers/tripplite_usb.c#L1152-L1180 > > > ups.debug.T: 39 31 32 35 37 31 0d '912571.' > > 0x257 = 599 = 59.9 Hz; the following '1' indicates a nominal value of 60 > Hz. You might be able to extract temperature from the first two digits. > > > ups.debug.V: 33 30 38 38 0d 00 00 '3088...' > > > > You would also want to test the shutdown command(s) to make sure that > everything behaves as expected. With the OMNIVS1000 that I have here, it > only supports a shutdown.return command with an offdelay, and it only works > while on battery (so no cycling power if the power returns early). > > If you would like help patching in support for this protocol, let me know > (reply-all so we can keep track of this in the list archives). > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20180508/ecb977b2/attachment-0001.html>
sorry, I thought I hit reply-all. CC'ing the list. On May 8, 2018, at 10:00 AM, Michael <fax12345 at gmail.com> wrote:> > Hi Charles, > > I'll gladly help where I can. I did reach out to their product support, and I did not have install the displaylink driver as that is for a totally different product, so ignore all that. > > The 208 V makes sense. The unit spec designates it as a 208V input, and from looking at what we have in the server room, the battery is a 48VDC power source.Sounds good.> > For outputs, this UPS has (12) 5-15/20R; (2) L6-20R; (2) L6-30R, but according to the output that I posted, only 9 are detected.I misspoke - "switchable outlets" should probably read "switchable outlet groups". I'm going to guess that quite a few of them are wired together, yielding eight groups, and the ninth group is always on when the inverter (or bypass circuitry, if applicable) is on.> > I'm new to this, so let me know what you need from me and I will try my best. This UPS does power our production servers, so shutting things down aren't an easy task, but this weekend might open up some opportunity for that if need be. If I need to test it by unplugging the main power, that I can do without problems.The first thing to try is building the latest NUT code from source. Version 2.7.4 is the latest released version, but after that, we'll switch to a new branch to add in the features for protocol 0005. Here are some instructions (not yet tested for Ubuntu 18.04): https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu There is always some level of risk with testing new code on an UPS, but if things didn't shut down before, you should be okay. You can try building this week, but I'd still wait until the weekend to test the new driver. - Charles> > Thanks, > Mike > > On Tue, May 8, 2018 at 8:06 AM, Charles Lepple <clepple at gmail.com> wrote: >> Hi, I ported the serial tripplite.c driver to support the non-PDC USB models. It's a bit of a mess, but this is partially due to not getting any public documentation from Tripp Lite regarding these models. What you see below is an attempt to parse the debug variables based on what we know from other models. >> >> On May 7, 2018, at 3:33 PM, Michael <fax12345 at gmail.com> wrote: >>> >>> ups.debug.0: 00 05 58 58 58 58 0d '..XXXX.' >> >> The first two bytes are where the version (0005) is coming from. However, the NUT code only knows about a few protocols, and neither 0003 nor 0005 are among them: >> >> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite_usb.c#L410-L433 >> >> It appears to be fairly similar to 0004, though. >> >>> ups.debug.D: 36 43 38 37 0d 00 00 '6C87...' >> >> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite_usb.c#L1258-L1276 parses this into input.voltage and battery.voltage, but there is some weird scaling (or maybe even nonlinearity) going on with the input voltage. >> >> Does a nominal AC voltage of 208V or 240V sound right? >> >> The driver would probably calculate nominal battery voltage as 48V (using the "08" from ups.debug.V, times 6V). With the value above, you would have 0x87 * 48 / 12.0 = 54.0 Volts. >> >>> ups.debug.L: 31 31 35 41 30 31 0d '115A01.' >> >> Load might be 17% (0x11). I don't think we know what the other four digits are. >> >>> ups.debug.load_banks: 8 >> >> The number of switchable outlets comes from the last '8' in the ups.debug.V string. >> >>> ups.debug.M: 30 30 37 31 0d 00 00 '0071...' >> >> These are probably input min/max voltages, which can often be reset by sending the 'Z' command. >> >>> ups.debug.P: 30 35 30 30 0d 00 00 '0500...' >>> ups.debug.S: 31 34 30 30 30 30 0d '140000.' >> >> Status '4' means that a battery test hasn't been done recently. Other values here: >> >> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite_usb.c#L1152-L1180 >> >>> ups.debug.T: 39 31 32 35 37 31 0d '912571.' >> >> 0x257 = 599 = 59.9 Hz; the following '1' indicates a nominal value of 60 Hz. You might be able to extract temperature from the first two digits. >> >>> ups.debug.V: 33 30 38 38 0d 00 00 '3088...' >>> >> >> You would also want to test the shutdown command(s) to make sure that everything behaves as expected. With the OMNIVS1000 that I have here, it only supports a shutdown.return command with an offdelay, and it only works while on battery (so no cycling power if the power returns early). >> >> If you would like help patching in support for this protocol, let me know (reply-all so we can keep track of this in the list archives). >> >> >
On May 8, 2018, at 10:05 PM, Charles Lepple <clepple at gmail.com> wrote:> >> I'm new to this, so let me know what you need from me and I will try my best. This UPS does power our production servers, so shutting things down aren't an easy task, but this weekend might open up some opportunity for that if need be. If I need to test it by unplugging the main power, that I can do without problems. > > The first thing to try is building the latest NUT code from source. Version 2.7.4 is the latest released version, but after that, we'll switch to a new branch to add in the features for protocol 0005. Here are some instructions (not yet tested for Ubuntu 18.04): > > https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu > > There is always some level of risk with testing new code on an UPS, but if things didn't shut down before, you should be okay. You can try building this week, but I'd still wait until the weekend to test the new driver. >If you have a chance to build the master branch to test, you can also try the tripplite_0005 branch. I need to dig out the OMNIVS1000 for regression testing, and of course I don't have a SU5000 to test with, but it should work based on the debug information you provided.