[Nut-upsuser] Lupus 500 MEC0003 Problems

[Hill]

Hi,
This is my first post ever on a technical forum, so please forgive any poor etiquette etc.
Also I'm totally new to Linux all of my experience has been trying to get this UPS to work. So please bear this in mind.

I'm running OpenSuse 13.1 and I have a Lupus 500 USB (Fideltronik)

After quite a bit of playing around I managed to get the status of the UPS using the blazer_usb driver and running NUT 2.6.5.
But unfortunately none of the Instcmds such as load.off etc. worked.

Some of the more pertinent info from the status:

productid 0000
vendorid 0001
firmware VER40141F1

and from lsusb

idvendor 0x0001 Fry's Electronics
iManufacturer MEC
iProduct MEC0003

The driver is using the Megatec protocol with the Krauler subdriver

So I connected the USB to my Windows machine and using Upsilon2000 it was possible to shutdown the UPS.

I then installed NUT 2.7.1 and tried the nutusb_qx driver to see if this improved matters, unfortunately it didn't help.

So after some sniffing on the USB port I observed that there were some differences between Upsilon200 and NUT (on Upsilon only the shutdown command and beeper toggle have any effect)

So I downloaded NUT 2.7.1 from source and played around with the nutdrv_qx driver re-compiled and tested.

Here are some of my observations.

It appears that the USB to serial conversion fixup that the UPS manufacturer is using can't handle any values.
To this end it appears that they use different Descriptor Indexes to acieve the desired effects.

0x18 Performs a shutdown.return with 30s delay and 10s delay before restart
0x1a Cancels the shutdown.return request (but not shutdown.stayoff)
0x20 = shutdown.stayoff with 30s delay
0x28 = shutdown.return with 40s delay
0x2a = cancel.shutdown.stayoff
0x24 = load.on
0x30 = shutdown.stayoff with 40s delay

and so on with different indexes giving different delays.

I'm in the process of mapping all of these commands at the moment and up until now I haven't found any battery test commands.

My question is. Is this information of any use to you and in what format would it be needed? Is there any other info I should give.

At the moment I have a modified nutdrv_qx driver which works for me but perhaps a more refined solution would be better.

Steven Hill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140609/b799c4c5/attachment.html>