[Nut-upsuser] Lupus 500 MEC0003 Problems
clepple at gmail.com
Wed Jun 11 12:40:15 UTC 2014
On Jun 9, 2014, at 6:40 AM, Hill wrote:
> 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.
On the NUT lists, we don't set or alter the reply-to header, so please use "reply all" to make sure that your reply makes it to the archives. On the other hand, if you prefer, you can set the reply-to header in your mail client to point to the list (so as not to fill up your inbox, if you have filtering rules for list posts).
> 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.
Can you post the output of upsc, and note if any of those values look wrong?
> 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
Were the blazer and/or nutusb_qx drivers able to match the Krauler subdriver automatically, or did you have to specify it manually in ups.conf?
> 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.
We're happy to help integrate this into NUT.
> At the moment I have a modified nutdrv_qx driver which works for me but perhaps a more refined solution would be better.
I CC'd the nutdrv_qx maintainer - he would be able to say whether any additional information is needed, and in what format.
Ideally, if there is something that the driver can automatically match or query from the UPS, that would make it seamless for other users. If not, we can add some sort of flag that would get passed to the Krauler subdriver.
Unfortunately, we don't have a lot of sample output for krauler-based UPS equipment, so I don't know if it makes sense to match against the USB strings (iVendor, iProduct) or not:
(the driver lineage is megatec_usb -> blazer_usb -> nutdrv_qx)
For reference, here is the developer documentation for nutdrv_qx (even though it seems focused on non-Krauler text command strings):
clepple at gmail
More information about the Nut-upsuser