[Nut-upsuser] Lupus 500 MEC0003 Problems

[hyouko at gmail.com]

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.