[Nut-upsuser] Lupus 500 MEC0003 Problems

[Hill]

Sorry for my delay, I've only just read this mail.
At first glance the driver looks like it should work, I will test it 
tomorrow (if possible) and let you know.
I'll also give a reply to your questions.
Many thanks for the work you've already put into this.



--------------------------------------------------
From: <hyouko at gmail.com>
Sent: Monday, June 30, 2014 12:42 AM
To: "Charles Lepple" <clepple at gmail.com>
Cc: "Hill" <hill at fermot.com.pl>; <nut-upsuser at lists.alioth.debian.org>
Subject: Re: [Nut-upsuser] Lupus 500 MEC0003 Problems

> 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.