Finally I got time to test this.
>>> Can you post the output of upsc, and note if any of those values
look
>>> wrong?
serwer2:/tmp/nut-fabula # upsc myups
battery.charge: 100
battery.voltage: 13.10
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.model: 500VA UPS
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0000
driver.parameter.protocol: megatec
driver.parameter.subdriver: fabula
driver.parameter.vendorid: 0001
driver.version: 2.7.2.5
driver.version.data: Megatec 0.01
driver.version.internal: 0.07
input.current.nominal: 2.2
input.frequency: 50.0
input.frequency.nominal: 50
input.voltage: 225.4
input.voltage.fault: 225.4
input.voltage.nominal: 230
output.voltage: 231.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: VER40141F1
ups.load: 0
ups.productid: 0000
ups.status: OL
ups.temperature: 0.0
ups.type: offline / line interactive
ups.vendorid: 0001
Everything looks fine apart from ups.beeper.status always shows enabled
even if the status bit fom the ups has changed state.
Saying that this ups only disables the beeper whilst working on battery.
Whilst waiting to shutdown you can't disable the beeper.
I've tested quite a lot and all the status messages appear logical, just in
case here is my interpretation of the ups status bits (8 bits)
MSB first
7: Utility failure
6: Battery low
5: Not 100% certain but probably bypass mode ( I haven't got a variac to
mess about with my supply to test this)
4: UPS alarm (alarm shows on ups LCD display when this bit is set. It comes
on when battery is critically low or when ups is overloaded)
3: Haven't a clue it's set all the time, nothing seems to change it
2: Haven't a clue it's always off
1: Shutdown active
0: Beeper status
After more testing the indexes work as follows
0x0a = load.on / cancel.shutdown.stayoff / cancel.shutdown.return
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
I modified the driver slightly to give 30 / 40 / and well almost 50 second
delays and after that every minute up to 10 mins.
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
>> [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]
Heres the driver startup
serwer2:/tmp/nut-fabula # /usr/lib/ups/driver/nutdrv_qx -a myups -DDD
Network UPS Tools - Generic Q* USB/Serial driver 0.07 (2.7.2.5)
USB communication driver 0.32
0.000000 debug level is '3'
0.000278 upsdrv_initups...
0.003711 Checking device (058F/6387) (002/002)
0.005690 - VendorID: 058f
0.005705 - ProductID: 6387
0.005713 - Manufacturer: Generic
0.005720 - Product: Mass Storage
0.005727 - Serial Number: BAE1A6A5
0.005733 - Bus: 002
0.005739 Trying to match device
0.005767 Device does not match - skipping
0.005790 Checking device (1D6B/0002) (002/001)
0.005876 - VendorID: 1d6b
0.005885 - ProductID: 0002
0.005892 - Manufacturer: Linux 3.11.10-11-desktop ehci_hcd
0.005898 - Product: EHCI Host Controller
0.005905 - Serial Number: 0000:00:1d.7
0.005913 - Bus: 002
0.005919 Trying to match device
0.005928 Device does not match - skipping
0.005943 Checking device (0001/0000) (008/034)
0.028354 - VendorID: 0001
0.028397 - ProductID: 0000
0.028404 - Manufacturer: MEC
0.028412 - Product: MEC0003
0.028418 - Serial Number: unknown
0.028425 - Bus: 008
0.028432 Trying to match device
0.028484 Device matches
0.031351 Skipping protocol Voltronic 0.01
0.031395 Skipping protocol Voltronic-QS 0.01
0.031487 Skipping protocol Mustek 0.02
0.031510 Skipping protocol Megatec/old 0.02
0.031533 Skipping protocol Mecer 0.02
0.031560 send: Q1
0.286316 received 47 (40)
0.286353 read: (225.4 225.4 231.0 000 50.0 13.1 00.0 00001001
0.286429 send: I
0.494334 received 39 (35)
0.494365 read: # 500VA UPS VER40141F1
0.494405 Using protocol: Megatec 0.01
0.494420 upsdrv_initinfo...
0.494440 send: Q1
0.748332 received 47 (40)
0.748364 read: (225.4 225.4 231.0 000 50.0 13.1 00.0 00001001
0.748472 send: F
0.873310 received 22 (35)
0.873339 read: #230.0 2.2 12.00 50.0
0.873407 send: I
1.081304 received 39 (35)
1.081332 read: # 500VA UPS VER40141F1
1.081349 ups_infoval_set: non significant value [device.mfr]
1.081414 No values for battery high/low voltages
1.081433 Using 'guesstimation' (low: 10.400000, high: 13.000000)!
1.081447 Battery runtime will not be calculated (runtimecal not set)
1.081470 upsdrv_updateinfo...
1.081479 Quick update...
1.081487 send: Q1
1.336295 received 47 (40)
1.336324 read: (225.4 225.4 231.0 000 50.0 13.1 00.0 00001001
1.336470 dstate_init: sock /var/lib/ups//nutdrv_qx-myups open on fd
13
1.336484 upsdrv_updateinfo...
1.336492 Quick update...
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.
I've attached a wireshark file to this message including this I don't
know
wether it's significant or not.
I've also attached my slightly modified nutdrv_qx.c
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
Because of this the beeper.disable never worked because it was switched on
and off 5 times
One more thing just to confirm the shutdown.return return time is always 10
seconds and there is a 10 second delay to load on as well (if the auto start
switch on the ups is on)
Also once you have executed a shutdown.return it's impossible to switch the
UPS off with it's push-button without the power returning after 10 seconds.
To get out of this you have to unplug the ups from the mains supply switch
it off and wait for 30 seconds. After this it returns to normal operation.
But if the auto start switch on the ups is turned off the power does not
return after a shutdown.return. If you execute load.on the power returns
instantly without the 10 second delay and you never have the problem that
the UPS push button can't keep the UPS switched off. But of course you
won't
have automatic return of the computer after mains failure and subsequent
return.
Finally the battery guesstemation works very well (to within 5 seconds for
the critically low alarm)
If you need any more information or more wireshark files please let me know.
Once again thank you very much for the support this UPS is no longer useless
although quite limited it's adequate for straightforward applications.
Best regards to you all
Steven Hill
--------------------------------------------------
From: "Hill" <hill at fermot.com.pl>
Sent: Monday, June 30, 2014 10:35 PM
To: <hyouko at gmail.com>; "Charles Lepple" <clepple at
gmail.com>
Cc: <nut-upsuser at lists.alioth.debian.org>
Subject: Re: [Nut-upsuser] Lupus 500 MEC0003 Problems
> 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.
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lupus500.pcapng
Type: application/octet-stream
Size: 3716 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140705/e8801d43/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nutdrv_qx.c
Type: application/octet-stream
Size: 69384 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140705/e8801d43/attachment-0003.obj>