search

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

MAKELSAN Lion 850VA UPS - help? #1308

Open jradxl opened 2 years ago

jradxl commented 2 years ago

Anyone any experience of this MAKELSAN Lion 850VA UPS? http://www.makelsan-ups.com/

# apt install nut-ipmi
# nut-scanner -U
Scanning USB bus.
[nutdev1]
    driver = "nutdrv_atcl_usb"
    port = "auto"
    vendorid = "0001"
    productid = "0000"
    bus = "001"

Certainly the USB IDs are correct Bus 001 Device 010: ID 0001:0000 Fry's Electronics

The UPS works on Windows 10, with the supplied UPSSmart v1.5 software, but the Linux version opens it's GUI but does not connect to the UPS.

The detected driver isn't right....

/lib/nut/nutdrv_atcl_usb -a nutdev1 -DDD
Network UPS Tools - 'ATCL FOR UPS' USB driver 1.1 (2.7.4)
Warning: This is an experimental driver.
Some features may not function correctly.

  14.347332 Checking USB device [0001:0000] (001/010)
  14.348660 Couldn't retrieve USB string descriptor for vendor. Check permissions?
  14.348698 Matched device with NULL vendor string.
  14.350568 USB device [0001:0000] opened
  14.350602 status interrupt read: error submitting URB: No such file or directory
  14.350615 Communications with UPS lost: Query to UPS failed

Things to try:
 - Connect UPS device to USB bus
 - Run this driver as another user (upsdrvctl -u or 'user=...' in ups.conf).
   See upsdrvctl(8) and ups.conf(5).

Fatal error: unusable configuration
 /lib/nut/nutdrv_qx -a nutdev1 -DDD
  18.375777 Checking device (0001/0000) (001/010)
  18.377071 - VendorID: 0001
  18.377104 - ProductID: 0000
  18.377115 - Manufacturer: unknown
  18.377126 - Product: unknown
  18.377136 - Serial Number: unknown
  18.377165 - Bus: 001
  18.377176 - Device release number: 0100
  18.377188 Trying to match device
  18.377203 Device matches
  18.377243 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
  18.377264 send: Q1
  18.378547 read: error sending control message: Operation not permitted (-5)
  18.378610 qx_process_answer: short reply (input.voltage)
#/lib/nut/usbhid-ups -a nutdev1 -DDD
 1.862551   Checking device (0001/0000) (001/010)
   1.863865 - VendorID: 0001
   1.863896 - ProductID: 0000
   1.863906 - Manufacturer: unknown
   1.863916 - Product: unknown
   1.863926 - Serial Number: unknown
   1.863938 - Bus: 001
   1.863951 - Device release number: 0100
   1.863961 Trying to match device
   1.863980 Device does not match - skipping
   2.274496 No appropriate HID device found
   2.274511 No matching HID UPS found

Anyone any suggestions?

jimklimov commented 2 years ago

Unfortunately this extremely random, unique and USB-forum purchased set of IDs (just kidding) matches a large number of unrelated devices. Effectively, it is a non-re-identified chip used for USB wire protocol, not an ID of the actual final product and its vendor because they did not bother to get and write one.

I think ATCL was documented as "one of NUT supported devices" with this ID pair in particular, and comes first alphabetically ;\ Maybe a (IIRC) nutdrv_qx would try the correct protocol for that.

jradxl commented 2 years ago

Thanks for your suggestions Using the Windows 10 UPSmart v1.5 software, it's Mega(USB) option that connects Does that mean anything to you? Perhaps megatec protocol?

On Linux: I do get a device match with nutdrv_qx, but no further. Using this command-line ./nutdrv_qx -a nutdev1 -DDD -x port=auto -x vendorid=0001 -x productid=0000 It's clearly probing the USB, but nothing gets found Does the snippet of driver output mean anything?

24.779225   Checking device (0001/0000) (001/061)
  24.780549 - VendorID: 0001
  24.780583 - ProductID: 0000
  24.780594 - Manufacturer: unknown
  24.780604 - Product: unknown
  24.780614 - Serial Number: unknown
  24.780629 - Bus: 001
  24.780642 - Device release number: 0100
  24.780655 Trying to match device
  24.780680 Device matches
  24.780722 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
  24.780736 send: Q1
  24.782035 read: error sending control message: Operation not permitted (-5)
  24.782101 qx_process_answer: short reply (input.voltage)
  24.782126 Device not supported!
  24.782137 Device not supported!
jimklimov commented 2 years ago

Here it seems like the driver process had no rights to probe the port. Can you re-run that test with -u root option (and starting as root, eg. via sudo)?

Also, it seems you are using the older (last released?) NUT version, so if you could retry with a local build of current master branch, that could be helpful too!

On Wed, Feb 23, 2022, 22:28 John Radley @.***> wrote:

Thanks for your suggestions Using the Windows 10 UPSmart v1.5 software, it's Mega(USB) option that connects Does that mean anything to you? Perhaps megatec protocol?

On Linux: I do get a device match with nutdrv_qx, but no further. Using this command-line ./nutdrv_qx -a nutdev1 -DDD -x port=auto -x vendorid=0001 -x productid=0000 It's clearly probing the USB, but nothing gets found Does the snippet of driver output mean anything?

24.779225 Checking device (0001/0000) (001/061) 24.780549 - VendorID: 0001 24.780583 - ProductID: 0000 24.780594 - Manufacturer: unknown 24.780604 - Product: unknown 24.780614 - Serial Number: unknown 24.780629 - Bus: 001 24.780642 - Device release number: 0100 24.780655 Trying to match device 24.780680 Device matches 24.780722 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0) 24.780736 send: Q1 24.782035 read: error sending control message: Operation not permitted (-5) 24.782101 qx_process_answer: short reply (input.voltage) 24.782126 Device not supported! 24.782137 Device not supported!

— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1308#issuecomment-1049232038, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFBN2AYV2S2IMDTTDS3U4VGODANCNFSM5O2T2LVA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

D13410N3 commented 1 year ago

Hello. Did you make this thing work? I'm planning to buy this one

jradxl commented 1 year ago

Alas, no. I gave up. I did try to contact Makelsan but received no reply (but I've no idea if my enquiry got though). As far as I remember it worked fine on ViewPower software. I just use it now without any use of the interface. Sorry

D13410N3 commented 1 year ago

@jradxl Thanks for your answer. Anyway, I have no choice - there are no any other UPS in local stores, so...

But I will try anyway

jimklimov commented 1 year ago

Recently a few improvements for nutdrv_qx have landed (into master branch, probably not yet distro packages). Some of those revolved around devices/firmwares that have got the Megatec Qx protocols wrong - assuming statistically that this one also talks Megatec...

One problem re-discovered and addressed there for some devices (but IIRC not yet holistically for "everything") is about hardware which ends its protocol report lines with a 0x00 NULL byte instead of CR. Many subdrivers consider this a "short read" (after debug-dumping a line with reasonable numbers, which obscured discovery of the problem), because the expected end-of-line was not found in the entirety of the read response.

Wondering if this would be the case here too, or if it just goes supported with existing drivers...

The permissions problem (Operation not permitted) posted originally still puzzles me. However it may be related to seeing effectively no identification from libusb (vendor/product unknown) and so is something about OS, udev, permissions, mismatch of run-time user vs. what udev config or devfs filesystem bits set... or even (not reported) virtualization and USB pass-through involved - which adds the same considerations for host system (that the hypervisor does not grab so much of the device that there's little left accessible for NUT or even whole guest OS to see). An lsusb might be helpful a bit to rule out the latter - there were cases where it reported the device details but libusb (used by NUT) did not. Running a driver as root might help for permissions mess-up - not encouraged if avoidable, but always an option...