networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.99k stars 349 forks source link

Support for Tripp Lite SMART1500PSGLCD (3028) #2030

Open michaelfucci opened 1 year ago

michaelfucci commented 1 year ago

Hi,

I was wondering whether anyone has been able to a Tripp Lite SMART1500PSGLCD working with NUT. Adding productid=3028 to the Extra Arguments to driver section on the pfsense NUT configuration page results in a bare minimum of information returned (mfr., model, serial, driver, etc) and reports ups.status as OB (On Battery) when it's plugged in. Tripp Lite support was unable to help. Initially, they said it should work but then stated that it's unsupported (with no known plans to add support).

jimklimov commented 1 year ago

(Originally posted to nut-website): This repo is about the website, not NUT proper ;)

Can you try custom-building NUT with usbhid-ups enhanced to recognize this ID? Check NUT commit history, a couple of years back there was a similar trivial addition of support for 3024 (IIRC) which allegedly went well... #963 is a good example - but better try it with a local build and real device before merging (also bump TRIPPLITE_HID_VERSION).

CC @dzomaya

michaelfucci commented 1 year ago

Thanks for the reply. My apologies for posting to the wrong repo! Not quite sure how I managed that one. Custom-building NUT, unfortunately, isn't something I think I could manage :(

ThatWileyGuy commented 9 months ago

I will be taking a look at this.

ThatWileyGuy commented 9 months ago

I made similar changes to #963 and it doesn't seem to have helped:

$ sudo upsc ups
device.mfr: TRIPP LITE UPS
device.model: TRIPP LITE UPS
device.serial: <removed>
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 3028
driver.parameter.synchronous: auto
driver.parameter.vendorid: 09ae
driver.state: quiet
driver.version: 2.8.1
driver.version.data: TrippLite HID 0.85
driver.version.internal: 0.52
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
ups.mfr: TRIPP LITE UPS
ups.model: TRIPP LITE UPS
ups.productid: 3028
ups.serial: <removed>
ups.status: OB
ups.vendorid: 09ae

... but that status should be OL.

These were the changes:

diff --git a/drivers/tripplite-hid.c b/drivers/tripplite-hid.c
index ed93b3dd4..af95485bd 100644
--- a/drivers/tripplite-hid.c
+++ b/drivers/tripplite-hid.c
@@ -119,6 +119,8 @@ static usb_device_id_t tripplite_usb_device_table[] = {
        { USB_DEVICE(TRIPPLITE_VENDORID, 0x3016), smart1500lcdt_scale },
        /* e.g. TrippLite AVR750U (newer unit) */
        { USB_DEVICE(TRIPPLITE_VENDORID, 0x3024), smart1500lcdt_scale },
+       /* e.g. TrippLite SMART1500PSGLCD (newer unit) */
+       { USB_DEVICE(TRIPPLITE_VENDORID, 0x3028), smart1500lcdt_scale },
        /* e.g. TrippLite SmartOnline SU1500RTXL2UA (older unit?) */
        { USB_DEVICE(TRIPPLITE_VENDORID, 0x4001), battery_scale_1dot0 },
        /* e.g. TrippLite SmartOnline SU6000RT4U? */
diff --git a/scripts/upower/95-upower-hid.hwdb b/scripts/upower/95-upower-hid.hwdb
index c8e635660..8e2432533 100644
--- a/scripts/upower/95-upower-hid.hwdb
+++ b/scripts/upower/95-upower-hid.hwdb
@@ -129,6 +129,7 @@ usb:v09AEp3014*
 usb:v09AEp3015*
 usb:v09AEp3016*
 usb:v09AEp3024*
+usb:v09AEp3028*
 usb:v09AEp4001*
 usb:v09AEp4002*
 usb:v09AEp4003*
ThatWileyGuy commented 9 months ago

Are there any tools I can try to see how this UPS's communication differs from the previous ones?

ThatWileyGuy commented 7 months ago

I set debug=6 per https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity and got this (repeated endlessly):

Mar 06 16:34:41 jenova nut-driver@ups[6210]:  177.665330        [D2] nut_libusb_get_interrupt: Connection timed out
Mar 06 16:34:41 jenova nut-driver@ups[6210]:  177.665455        [D1] Got 0 HID objects...
Mar 06 16:34:41 jenova nut-driver@ups[6210]:  177.665500        [D1] Quick update...
Mar 06 16:34:41 jenova nut-driver@ups[6210]:  177.665554        [D5] send_to_all: SETINFO driver.state "quiet"
Mar 06 16:34:41 jenova nut-driver@ups[6210]:  177.665605        [D6] send_to_all: write 29 bytes to socket 10 succeeded (ret=29): SETINFO driver.state "quiet"
Mar 06 16:34:42 jenova nut-driver@ups[6210]:  178.915768        [D5] send_to_all: SETINFO driver.state "updateinfo"
Mar 06 16:34:42 jenova nut-driver@ups[6210]:  178.915913        [D6] send_to_all: write 34 bytes to socket 10 succeeded (ret=34): SETINFO driver.state "updateinfo"
Mar 06 16:34:42 jenova nut-driver@ups[6210]:  178.915958        [D1] upsdrv_updateinfo...
Mar 06 16:34:43 jenova nut-driver@ups[6210]:  179.666286        [D2] nut_libusb_get_interrupt: Connection timed out
Mar 06 16:34:43 jenova nut-driver@ups[6210]:  179.666408        [D1] Got 0 HID objects...
Mar 06 16:34:43 jenova nut-driver@ups[6210]:  179.666454        [D1] Quick update...
Mar 06 16:34:43 jenova nut-driver@ups[6210]:  179.666505        [D5] send_to_all: SETINFO driver.state "quiet"
Mar 06 16:34:43 jenova nut-driver@ups[6210]:  179.666556        [D6] send_to_all: write 29 bytes to socket 10 succeeded (ret=29): SETINFO driver.state "quiet"

... so it seems like we're not getting anything from the UPS at all?

HeedfulCrayon commented 7 months ago

Are there any tools I can try to see how this UPS's communication differs from the previous ones?

I am in the same boat, looking for support for the SMART1000PSGLCD. I did find that there is TrippLite's PowerAlert Local for fedora, but it is closed source... don't know if the traffic over the wire could potentially be sniffed to reverse engineer the communication

ThatWileyGuy commented 7 months ago

Oh, it could be interesting to get an strace of that? Would let us see the syscalls and buffers of USB traffic going back and forth...

HeedfulCrayon commented 7 months ago

@ThatWileyGuy another option could be to use the recommendation here to capture the USB traffic https://wiki.wireshark.org/CaptureSetup/USB#a-word-of-warning-about-usbpcap Unfortunately I don't really have the setup to test any of this, unless proxmox could do the same thing as virtualbox as far as usbpcap goes