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>
On Jun 9, 2014, at 6:40 AM, Hill wrote:> 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.No worries. 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 subdriverWere 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: https://github.com/zykh/nut-ddl-raw/commit/019f22208dc65e7769f5e6450806cbf851f57ec8 (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): http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#nutdrv_qx-subdrivers -- Charles Lepple clepple at gmail
Sorry for the huge delay and thanks Charles for taking care of this topic.>> 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?Seconding Charles's request.>> 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.Definitely usefull, let's recap, so far: - 0x(1+)8 -> shutdown return, 0x18 (24dec)= 30s; +0x10 (16dec) = +10s -> we can round a shutdown delay to tens, then index = 24 + [(delay - 30) / 10] * 16 -> that would result in a max delay usable in megatec command of 120 seconds (S02[R0001+]) - 0x(2+)0 -> shutdown stayoff, 0x20 (32dec) = 30s; +0x10 (16dec) +10s -> we can round a shutdown delay to tens, then index = 32 + [(delay - 30) / 10] * 16 -> that would result in a max delay usable in megatec command of 120 seconds (S02R0000) - 0x(1+)a -> cancel shutdown, most significant digit: 1 -> shutdown return; 2 -> shutdown stayoff - 0x24 -> load on [Going the 'usb subdriver way' we need to have both cancel shutdown and load.on executed when mapped to NUT's 'shutdown.stop' or 'load.on' (as they are both mapped to the 'C' command).] Can you confirm this scheme also for the next (not shown in your mail) indexes? Hopefully this UPS doesn't have the same implementation of the one from this old thread: http://lists.alioth.debian.org/pipermail/nut-upsdev/2007-September/002530.html Having the captures too would be pretty helpfull. Also, can you provide the logs of the initialization of the driver launched with a debug level of 3?> 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...or add it as a new subdriver if it ends up differing too much from krauler. Here's a first quick try at it (subdriver 'fabula'): https://github.com/zykh/nut/tree/fabula [I assumed the UPS returns something (an empty string maybe, not 'UPS No Ack') when we send it a command, so the load.on/shutdown.stop thing is after the parse of what we got from the UPS, probably this has to be improved] Feel free to send in your modified version of nutdrv_qx.