I recently took over maintenance of a linux computer which is drawing power from a "Maruson Power Net 1500" UPS. However, there is currently no monitoring or control of the UPS by this (or any other) computer. Can nut control this device? There are serial, usb, and EPO connectors on the back of the unit. (There may be a manual but I'm going to have to hunt for it.) Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
On Thu, May 8, 2008 at 1:46 PM, David Mathog <mathog at caltech.edu> wrote:> I recently took over maintenance of a linux computer which is drawing > power from a "Maruson Power Net 1500" UPS. However, there is currently > no monitoring or control of the UPS by this (or any other) computer. > Can nut control this device? There are serial, usb, and EPO connectors > on the back of the unit. (There may be a manual but I'm going to have > to hunt for it.)I would guess that the nut-upsuser list might reach a broader audience, but I don't think we have heard of any user experiences with this brand. Have you checked the manufacturer's website for drivers? Even if they do not have Linux drivers, the name of the Windows monitoring software can sometimes be a clue to the name of the OEM (if it is rebranded). If you do decide to poke around with the connectors on the back of the UPS, you might want to do it with the critical equipment powered down, or at least not plugged into that UPS. Serial port contact-closure interfaces are often wired differently than standard serial ports, and it is all too easy to accidentally shut down an UPS with a normal cable. Less risky is to plug in a USB cable. There is a certain amount of device identification information that you can retrieve without much danger of shutting down the UPS. Running 'lsusb' to determine the device ID, then running 'sudo lsusb -d [vendor]:[product] -vvv' should tell us whether it is close to being supported by one of the NUT USB drivers. Also, consider how much time you want to spend tracking this down. Some of us relish the idea of reverse-engineering a new protocol, but what starts as a two-hour setup job could turn into a month-long driver-writing project. -- - Charles Lepple
Charles Lepple wrote:> > I would guess that the nut-upsuser list might reach a broader > audience, but I don't think we have heard of any user experiences with > this brand. > > Have you checked the manufacturer's website for drivers? Even if they > do not have Linux drivers, the name of the Windows monitoring software > can sometimes be a clue to the name of the OEM (if it is rebranded).Apparently Maruson builds some of Belkin's UPS units with the same innards but different cases, and the equivalent sized Belkin UPS, the F6C1500-TW-RK, is theoretically supported now in nut. The software from Maruson is a Java package called "WinPower 2.0" whose GenericUnix version installed in /opt/upspilot. This software runs, putting up a nice GUI. However, for some obscure reason it will not accept a serial port configuration, and so cannot talk to the UPS. The software lists both ttyS0 and ttyS1, but "ok" is grayed out, so there is no way to make it use one or the other. This software does not support USB on linux. The Belkin site distributes something called "Bulldog Plus" for their UPS, but that would not even run. This is on an SMP x86-64 system, and the ELF binaries were over 5 years old. When the UPS was plugged in this appeared in /var/log/messages: May 19 14:44:37 M kernel: [15917.903404] usb 3-3.3: new low speed USB device using ehci_hcd and address 10 May 19 14:44:37 M kernel: [15918.020132] usb 3-3.3: configuration #1 chosen from 1 choice May 19 14:44:37 M kernel: [15918.027496] hiddev96: USB HID v1.11 Device [OMRON USB UPS] on usb-0000:00:03.2-3.3 I built nut 2.2.2 from scratch and tried the usbhid-ups driver, but it did not see the UPS. Put this in ups.conf [MarusonTop] driver = usbhid-ups port = auto desc = "Top Maruson UPS" Then: % /usr/local/ups/bin/usbhid-ups -a MarusonTop Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) This Liebert device (06da:0003) is not (or perhaps not yet) supported by usbhid-ups. Please make sure you have an up-to-date version of NUT. If this does not fix the problem, try running the driver with the '-x productid=0003' option. Please report your results to the NUT user's mailing list <nut-upsuser at lists.alioth.debian.org>. No matching HID UPS found No idea why it thinks it is a Liebert. Anyway... % /usr/local/ups/bin/usbhid-ups -a MarusonTop -x productid=0003 Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) No matching HID UPS found % lsusb -vvv Bus 003 Device 010: ID 06da:0003 Phoenixtec Power Co., Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x06da Phoenixtec Power Co., Ltd idProduct 0x0003 bcdDevice 2.00 iManufacturer 3 OMRON iProduct 1 USB UPS iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 27 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 20 Device Status: 0x0000 (Bus Powered) Suggestions? Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
By the way, is it possible to force usbhid-ups to pretend that a given USB device is another device? That is, force it to ignore the vendor and manufacturer strings and use instead the ones supplied from the command line? In this instance with the goal of trying to force the Maruson device to be accessed as the nearest Belkin. I see the Regular expression options, but that's to find a USB device, whereas here we know where it is, but want to convince usbhid-ups that it is something else. Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
As suggested, the megatec_usb driver was attempted. ups.conf has: driver = megatec_usb port = auto desc = "Top Maruson UPS" Unfortunately, both as ups (the account created when nut was compiled/installed) and as root, this is what happens: % /usr/local/src/nut-2.2.2/drivers/megatec_usb -a MarusonTop -DDDD Network UPS Tools 2.2.2 - Megatec protocol driver 1.5.14 [megatec_usb] Carlos Rodrigues (c) 2003-2008 Serial-over-USB transport layer for Megatec protocol driver [megatec_usb] Andrey Lelikov (c) 2006, Alexander Gordeev (c) 2006-2007, Jon Gough (c) 2007 debug level is '4' Checking device (06DA/0003) (003/014) - VendorID: 06da - ProductID: 0003 - Manufacturer: unknown - Product: USB UPS - Serial Number: unknown - Bus: 003 Trying to match device Device matches failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... trying again to claim USB device... Starting UPS detection process... Asking for UPS status [Q1]... Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 33 2e 39 20 31 30 30 31 30 30 30 Asking for UPS status [Q1]... Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 33 2e 39 20 31 30 30 31 30 30 30 Asking for UPS status [Q1]... Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 33 2e 38 20 31 30 30 31 30 30 30 Asking for UPS status [Q1]... Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 33 2e 39 20 31 30 30 31 30 30 30 Asking for UPS status [Q1]... Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 33 2e 39 20 31 30 30 31 30 30 30 5 out of 5 detection attempts failed (minimum failures: 2). Megatec protocol UPS not detected. lsusb still shows the device, ie % lsusb -vvv Bus 003 Device 016: ID 06da:0003 Phoenixtec Power Co., Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x06da Phoenixtec Power Co., Ltd idProduct 0x0003 bcdDevice 2.00 iManufacturer 3 OMRON iProduct 1 USB UPS iSerial 0 etc. I think the udev stuff is working properly, as the nut script was installed in there, and the action of the driver changed to the above (from something even less useful) after the UPS was unplugged, and then plugged back in, subsequent to nut installation. It looks like it has the ability to read/write to the USB device, but what's coming back is not what it expected to see (only 14 bytes insetad of ???), hence the short read messages. Suggestions??? Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
> - if the trunk doesn't work any better it could be helpful to sniff > USB traffic while using supplied Windows driverYeah, I'm thinking that would be useful too. What (free) software do you folks use for this? Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
Here is the USB snoop of the data going to/from the UPS. It was made the following way: 1. get usb snoop configured, plug in UPS so that a device appeared in the applications list, unplug UPS. 2. select UPS USB device and click "install" in usb snoop to start logging. 3. plug in the USB cable connecting the UPS. 4. Start the WinPower (aka upspilot) application. 5. In WinPower see the data values returned. This showed voltages around 114V, load at around 35%, and status Normal. The information shown was very "light" compared to some other UPS units I have seen. I did not send the UPS any explicit commands (shutdown or test), but WinPower may have sent some requests for data all by itself. 6. Turn off Winpower 7. Unplug the USB cable The log file is available here (this is a retrieve only link, the directory it is in cannot be listed) http://saf.bio.caltech.edu/pub/pickup/maruson_usb.txt The messages coming back seem to be very short, and most of the bytes are outside of the printable characters for the ASCII range. Hopefully this will look familiar to the Megatec driver developers. Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
> - get the latest SVN trunk and try 'agiler_old', 'agiler', 'phoenix' > subdrivers and report back the resultsSorry to be dense, but, how exactly does one "try" a subdriver? I see these listed inside the megatec_usb.c, but not how to force one to be used. Is there a command line way to do this, or am I supposed to hack the megatec_usb.c code to force the setting of the "subdriver" variable? Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
In the meantime I put some printf(stderr,"DEBUG...") statements in the 2.2.2. megatec_usb.c and ran it like this: /usr/local/src/nut-2.2.2/drivers/megatec_usb -a MarusonTop -DDDDDD 2>&1 | tee /tmp/megatec_2.2.2.txt Looking at just the last Q1 exchange it showed; DEBUG get_data_agiler length -110 expected 8 get_data_agiler: raw dump: (0 bytes) => DEBUG total read 0 DEBUG raw data: ok DEBUG get_data_agiler length 8 expected 8 ok DEBUG get_data_agiler length 8 expected 8 ok DEBUG get_data_agiler length 8 expected 8 ok DEBUG get_data_agiler length 8 expected 8 ok DEBUG get_data_agiler length 8 expected 8 ok DEBUG get_data_agiler length 8 expected 8 DEBUG total read 48 DEBUG raw data: 28 31 31 33 2e 38 20 31 30 30 31 30 30 30 d 33 2e 38 20 30 33 38 20 36 30 2e 30 20 35 34 2e 31 20 35 30 2e 36 20 30 30 30 30 31 30 30 30 d 33 Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 33 2e 38 20 31 30 30 31 30 30 30 So here is the first thing I don't understand. The program read 48 bytes in but then for some reason only retained 14 of them. It said this was a short read. However AGILER_REPORT_SIZE is 8 and AGILER_REPORT_COUNT is 6, so 48 seems like exactly the expected number. Perhaps the "detail" routine only shows the first 14 bytes no matter how long the read was, but 48 was expected, 48 was read, and yet it was "short". Translating the 48 bytes gives: ( 1 1 3 . 8 sp 1 0 0 1 0 0 0 CR 3 . 8 sp 0 3 8 sp 6 0 . 0 sp 5 4 . 1 sp 5 0 . 6 sp 0 0 0 0 1 0 0 0 cr 3 Some of those look like expected data: 113.8 is probably the voltage and 60.0 the line frequency. 038 is likely the load factor. I have no idea what 1001000, 3.8, 54.1, 50.6, 00001000, and 3 are though. Regards, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
I tracked down some of the problem. In megatec_usb it reads 48 bytes like this: 28 31 31 33 2e 38 20 31 30 30 31 30 30 30 d 33 2e 38 20 30 33 38 20 36 30 2e 30 20 35 34 2e 31 20 35 30 2e 36 20 30 30 30 30 31 30 30 30 d 33 but in a later routine saw only 14 bytes. Notice that there are TWO sets of "d 33" in there. The code in 2.2.2 only expects the latter set, to drop the message down from 48 bytes to 46. ser_get_line in megatec.c passes ENDCHAR as \r, or hex d. So it truncates at the first d instead of the second, and ends up with the 14 byte line. Here it is translated in a nicer format: (113.8 1001000<CR>3.8 038 60.0 54.1 50.6 00001000<cr>3 What do these messages look like on other Phoenixtec UPS devices? I'll build the trunk after lunch. I tried just putting in megatec_usb.c but it had some incompatibility with the rest of 2.2.2. Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech
Umm, I have autoconf and automake, but at the top of the trunk it does...
% autoreconf
configure.in:69: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:312: error: possibly undefined macro: AC_DISABLE_STATIC
autoreconf: /usr/bin/autoconf failed with exit status: 1
The only build from trunk instruction I could find just said to use
autoreconf. What am I doing wrong?
autoconf 2.61
automake 1.10
Thanks,
David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
On Wed, May 21, 2008 at 3:41 PM, David Mathog <mathog at caltech.edu> wrote:> Umm, I have autoconf and automake, but at the top of the trunk it does... > > % autoreconf > configure.in:69: error: possibly undefined macro: AC_PROG_LIBTOOL > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.in:312: error: possibly undefined macro: AC_DISABLE_STATIC > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > The only build from trunk instruction I could find just said to use > autoreconf. What am I doing wrong? > > autoconf 2.61 > automake 1.10It should have also said "install libtool" as well. What instructions should we be updating? -- - Charles Lepple
Charles Lepple wrote> It should have also said "install libtool" as well. What instructions > should we be updating?Right. That did it. Unfortunately the trunk has exactly same problem as 2.2.2, it is truncating the returned string at the 15th byte, which is an 0D hex. On the plus side, the debugging info is a little better out of the box, I didn't have to put in any of my own debug printf's. Here's part of it: % drivers/megatec_usb -a MarusonTop -DDDDDD (snip) Asking for UPS status [Q1]... none (-110) ok get_data_phoenix: got so far [(114.6 1] get_data_phoenix: (8 bytes) => 28 31 31 34 2e 36 20 31 ok 4]t_data_phoenix: got so far [(114.6 1001000 get_data_phoenix: (16 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 ok 4.6 033 6]hoenix: got so far [(114.6 1001000 get_data_phoenix: (24 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 ok 4.6 033 60.0 54.0]got so far [(114.6 1001000 get_data_phoenix: (32 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 30 2e 30 20 35 34 2e 30 ok 4.6 033 60.0 54.0 51.1 00]ar [(114.6 1001000 get_data_phoenix: (40 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 30 2e 30 20 35 34 2e 30 20 35 31 2e 31 20 30 30 ok 4]6 033 60.0 54.0 51.1 00001000114.6 1001000 get_data_phoenix: (48 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 30 2e 30 20 35 34 2e 30 20 35 31 2e 31 20 30 30 30 30 31 30 30 30 0d 34 ok 4.6 033 6].0 54.0 51.1 00001000114.6 1001000 get_data_phoenix: (56 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 30 2e 30 20 35 34 2e 30 20 35 31 2e 31 20 30 30 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 ok 4.6 033 60.0 54.0]51.1 00001000114.6 1001000 get_data_phoenix: (64 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 30 2e 30 20 35 34 2e 30 20 35 31 2e 31 20 30 30 30 30 31 30 30 30 0d 34 2e 36 20 30 33 33 20 36 30 2e 30 20 35 34 2e 30 none (-110) Q1 => FAILED [short read] Q1 detail: (14 bytes) => 28 31 31 34 2e 36 20 31 30 30 31 30 30 30 5 out of 5 detection attempts failed (minimum failures: 2). Megatec protocol UPS not detected. Network UPS Tools 2.3.0 - Megatec protocol driver 1.5.14 [megatec_usb] Carlos Rodrigues (c) 2003-2008 Serial-over-USB transport layer for Megatec protocol driver [megatec_usb] Andrey Lelikov (c) 2006, Alexander Gordeev (c) 2006-2007, Jon Gough (c) 2007 Thanks, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech