[Nut-upsuser] Lupus 500 MEC0003 Problems

[Hill]

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

>> Everything looks fine apart from ups.beeper.status  always shows enabled
>> even if the status bit fom the ups has changed state.
>
> Probably because the driver updates the beeper status only every
> 'pollfreq' (default 30) seconds, so it may have missed the change.

My mistake testing too quickly to have seen the update.
>
>> After more testing the indexes work as follows
>>
>> 0x0a = load.on / cancel.shutdown.stayoff / cancel.shutdown.return
>
> For future reference only (since the following ones are not used in
> the subdriver):
> - 0x1A -> cancel shutdown.return,
> - 0x2A -> cancel shutdown.stayoff,
> - 0x24 -> load on
> Are these still valid?

0x0a ... 0xfa = cancel shutdown.stayoff / cancel shutdown.return / load.on
0x24  My mistake this appears to do nothing
>
>> 0x10 and 0x18 are shutdown.stayoff and shutdown.return respectively both
>> with 30 sec delay
>> 0x20 and 0x28 = 35 sec delay
>> 0x30 and 0x38 = 40 sec delay
>> 0x40 and 0x48 = 45 sec delay
>> 0x50 and 0x58 = 52.5 sec delay
>> 0x60 and 0x68 = 60 sec delay
>> 0x70 and 0x78 = 2 min delay
>> .........
>> 0xf0 and 0xf8 = 10 min delay
>
> Ah.. even easier: +0x10 (16dec) = next megatec delay
> Sn[Rm], n: .2 (this UPS only supports .5+) -> .9; 01 -> 10
>
> .5 (60 * .5 = 30 seconds) -> 0x1(0|8)
> .6 (60 * .6 = 36 seconds) -> 0x2(0|8)
> ...
> 01 (60 * 01 = 60 seconds) -> 0x6(0|8)
> ...
> 10  (60 * 10 = 600 seconds) -> 0xF(0|8)
>
> Updated the subdriver accordingly.

Works more or less OK but for 36 secs creates an index of 0x1f (should be 
0x20) and for 42 secs creates 0x2f.   30, 48 and 54 secs work OK.
I added forced type conversion with rounding in the driver program and then 
everything worked OK

>
>> The fabula driver seems to work fine apart from a problem with the LANGID 
>> (
>> UPS sends 0x0009) and the driver appears to send a langid request every 
>> time
>> the ups is polled but apart from this everythin seems to work
>> If the langid_fix in ups.conf is set to 0x409 everything works fine and 
>> the
>> extra langid requests aren't sent
>
> That's because, when langid_fix is not set, the subdriver uses the
> usb_get_string_simple function (libusb/compat 0.1) that, in turn,
> calls the libusb_get_string_descriptor_ascii function (libusb 1.x)
> that first asks the device for all the supported langids and then uses
> the first one to get the string descriptor at the requested index.
> Nothing to worry about. So, to simplify the subdriver, I removed the
> langid thing from it.

A langid request (index 0x00) is still sent every cycle. The UPS returns 
0x0009
It's not really a problem as everything works OK regardless

>
>> This ups sends UPS No Ack to acknowledge everything (or not!) apart from 
>> Q1
>> / F / and I (when data is actually returned)
>>
>> If you send index 0x0e or 0x0f to the UPS you receive a faulty packet /
>> broken pipe message (I don't know enough about usb protocols to 
>> understand
>> any of this.
>
> So.. *unsupported* indexes silently fail.
> While every *supported* index/command that fails or succeeds
> (obviously excluding the queries when data is returned) gets 'UPS No
> Ack'.
> Just to be sure, if you execute a beeper.toggle when the UPS is not on
> battery do you get 'UPS No Ack' just like when it is on battery,
> right?

Yes. If you execute beeper.toggle whilst not on battery the UPS responds 
with 'UPS No Ack'


> That's a bit weird as we can't discern the succeeded commands from the
> failed ones... at the moment the subdriver always return 0 on 'UPS No
> Ack': this way queries will see it as a failure while instant commands
> as a sucess (just like it happens with those serial devices that
> always reply with 'ACK' even if the command does not succeed and echo
> back the commands only when unknown/unsupported).
> This is less than ideal, but I can't find a better way to handle this 
> situation.
>
>> One other thing I modified was a for i =0 i<10 loop I'm not sure of it's
>> purpose but I reduced it to i<1 because all comands other than Q1 /F and 
>> I
>> were repeated 10 times
>
> Since you previously said your UPS worked with the krauler subdirver,
> I based the fabula subdriver on it, where the loop is needed because
> of the crappiness of most of the supported devices that have a natural
> inclination to fail more often than not. As it doesn't seem to be the
> case here, I removed it from the fabula subdriver.

Everything works rock solid on this UPS. It's very limited but behaves 
itself very well
>
> Here's the updated driver:
> https://github.com/zykh/nut/tree/fabula-updated

Everything is great with the added type conversion with rounding and the 
driver looks really neat and compact.

Thanks once again I think we can say that this is as far as we can go with 
this UPS. It would be interesting to know if any other UPS's which appear to 
half work with the blazer_usb driver would work better with this one.

Best regards,

Steven Hill