Re: [Nut-upsuser] Frys Electronic / ATCL FOR UPS / Debian Jessie

[hyo...@gmail.com]

> If that doesn't work, can you post the debug messages from the driver? On 
> Debian, after running 'service stop nut-server', you can start the driver 
> manually with '/lib/nut/nutdrv_qx -a  -DD'.

Possibly with a debug level of 5 (i.e. `/lib/nut/nutdrv_qx -a
 -D`).
[I know, I know... it's my fault... we (I) need to harmonize the use
of debug levels across the various components of NUT (or, at least, of
that driver)... I'm working on it...]

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powerwalker VI 2200VA LCD

[hyo...@gmail.com]

Lars, the log ends around 41998 seconds (~ 11 1/2 hours) and, till
that point, from what I can see, nothing strange happens: both the
interrupt pipe and polling work as expected.
Now, you mentioned that something changes when you alter the polling
frequency (I think you refer to 'pollfreq' and not to 'pollinterval',
but correct me if I'm wrong), but without seeing it happen, we can't
say whether the problem is caused by an interrupt, a quick update or a
full update.

Another couple of things you could try to narrow down the candidates:
- disable the interrupt pipe ('pollonly'), or
- (if you can upgrade to at least 2.7.4) disable polling ('interruptonly').

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powerwalker VI 2200VA LCD

[hyo...@gmail.com]

2016-11-09 14:57 GMT+01:00 Lars de Bruin :
> Hi,
>
> - The device never re-connects to the system, i have to physically remove
> the USB plug and insert it again for the device to come back.
> - This does not happen when running the driver from the supplier. (java
> process)

Ok, if they do, we should be able to do it too.

> - When i poll every 60s it works for about 3 days, anything lower or higher
> causes it to disconnect faster
> - The big log i sent is not the output of the driver? if not how can i
> enable that ?

Sorry if I wasn't clear, it is the right log, but it ends too early:
we could get more answers if the log covers the moments before the
disconnection.

>
>
> Thank you for your time..

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powerwalker VI 2200VA LCD

[hyo...@gmail.com]

The huge log doesn't show anything troublesome or problematic.

The part of the driver output you posted on your third-to-last email
only shows that the device disconnects and then it doesn't reconnect,
or, at least, the driver doesn't see it:
- At that point, does the device reconnet to the system? (Does it show
up on dmesg? What does `lsusb -d 06da: -v` return?)
- It could be helpful to know what happened just before the
disconnection to see if there is any correlation with driver activity:
any chance you have the log of the driver running in debug mode till
that point?

A fair guess could be that the device is already busy doing something
and considers communication of a lower priority and hence stops it.
Were this the case (but, then, I would expect the device to reconnect
and the driver to restart communication), a 'full update' would likely
be the culprit, and hence increasing 'pollfreq', while not curing the
problem, could at least decrease the chance of experiencing it.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powerwalker VI 2200VA LCD

[hyo...@gmail.com]

2016-10-10 15:28 GMT+02:00 Lars de Bruin :
> The UPS seems to disconnect totally, i need to physically disconnect the
> cable to get the UPS connected again.
> A reboot is not enough.

Ouch, this is more severe than what I thought.
As a first step, you could try and increase the timeouts for pollfreq
and pollinterval.
Again, a log (compressed) of the driver running in debug mode when
those problems occur would be helpful.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powerwalker VI 2200VA LCD

[hyo...@gmail.com]

2016-10-03 14:56 GMT+02:00 Lars de Bruin :
> Hi,
>
> The UPS is now connected via HID-USB, but seems to randomly disconnect.
> Sometimes after a few hours, other times days...
> Any suggestions?

A log would help, but, in general, if the device disconnects and,
after a short time, the connection is restored, it could be a cable
problem, or the UPS not keeping the pace needed to update all the
necessary data.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] connection pb with blazer_usb with infusec UPS

[hyo...@gmail.com]

Please keep the list CC'd, thanks.

2016-10-07 8:54 GMT+02:00 MATHIEU Clement :
> Hello
> thanks for your answer
> i’ve tried with nutdrv_qx driver
> and i got this result
>
> lsusb :
>
> Bus 001 Device 058: ID 0665:5161 Cypress Semiconductor USB to Serial
> Bus 001 Device 005: ID 13ee:0001 MosArt
> Bus 001 Device 004: ID 0a81:0101 Chesen Electronics Corp. Keyboard
> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514
> Fast Ethernet Adapter
> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> sudo /lib/nut/nutdrv_qx -a HERO -DDD -u root
>
> Network UPS Tools - Generic Q* USB/Serial driver 0.06 (2.7.2)
> USB communication driver 0.32
>0.00 debug level is '3'
>0.002329 upsdrv_initups...
>0.003541 Checking device (0665/5161) (001/036)
>0.014412 - VendorID: 0665
>0.014521 - ProductID: 5161
>0.014608 - Manufacturer: INNO TECH
>0.014697 - Product: USB to Serial
>0.014783 - Serial Number: unknown
>0.014875 - Bus: 001
>0.014961 Trying to match device
>0.015172 Device matches
>0.015305 failed to claim USB device: could not claim interface 0: Device
> or resource busy
>0.015942 detached kernel driver from USB device...
>0.017534 send: QGS
>0.152570 read: N
>0.153407 qx_process_answer: short reply (input.voltage)
>0.154812 send: QGS
>0.289577 read: N
>0.290254 qx_process_answer: short reply (input.voltage)
>0.291575 send: QGS
>0.426589 read: N
>0.427286 qx_process_answer: short reply (input.voltage)
>0.428596 send: M
>0.552624 read: P
>0.553499 voltronic_qs_protocol: invalid protocol [P]
>0.554862 send: M
>0.678625 read: P
>0.679343 voltronic_qs_protocol: invalid protocol [P]
>0.680625 send: M
>0.804641 read: P
>0.805347 voltronic_qs_protocol: invalid protocol [P]
>0.806638 send: QS
>2.041443 read: could not claim interface 0: Device or resource busy
>2.042383 qx_process_answer: short reply (input.voltage)
>2.043674 send: QS
>3.277104 read: could not claim interface 0: Device or resource busy
>3.277275 qx_process_answer: short reply (input.voltage)
>3.277954 send: QS
>4.512612 read: could not claim interface 0: Device or resource busy
>4.512787 qx_process_answer: short reply (input.voltage)
>4.513487 send: D
>4.638121 read: N
>4.638259 qx_process_answer: short reply (input.voltage)
>4.638996 send: D
>4.763133 read: N
>4.763241 qx_process_answer: short reply (input.voltage)
>4.764012 send: D
>4.888154 read: N
>4.888259 qx_process_answer: short reply (input.voltage)
>4.889028 send: Q1
>5.019190 read: N
>5.019383 qx_process_answer: short reply (input.voltage)
>5.020180 send: Q1
>5.150184 read: N
>5.150289 qx_process_answer: short reply (input.voltage)
>5.151061 send: Q1
>5.281199 read: N
>5.281306 qx_process_answer: short reply (input.voltage)
>5.282077 send: Q1
>5.412245 read: N
>5.412437 qx_process_answer: short reply (input.voltage)
>5.413234 send: Q1
>5.543247 read: N
>5.544118 qx_process_answer: short reply (input.voltage)
>5.545492 send: Q1
>5.675251 read: N
>5.675956 qx_process_answer: short reply (input.voltage)
>5.677259 send: Q1
>5.807269 read: N
>5.808067 qx_process_answer: short reply (input.voltage)
>5.809396 send: Q1
>5.939284 read: N
>5.939965 qx_process_answer: short reply (input.voltage)
>5.941293 send: Q1
>6.071312 read: N
>6.072170 qx_process_answer: short reply (input.voltage)
>6.073557 send: Q1
>6.203318 read: N
>6.204040 qx_process_answer: short reply (input.voltage)
>6.205327 send: Q1
>6.335336 read: N
>6.336029 qx_process_answer: short reply (input.voltage)
>6.337338 send: Q1
>6.467375 read: N
>6.468330 qx_process_answer: short reply (input.voltage)
>6.469048 Device not supported!
>6.469736 Device not supported!
>
> any idea ?

The reply ('P') to the 'M' query seems to confirm my belief that this
device might be supported by 'nutdrv_qx' driver with
'voltronic-qs-hex' protocol.

>
> how do you install from repository ver 2.7.4. ?

Well, if you want the most recent source, you can either start from
our Git tree, or use the tarball snapshots from our Buildbot (see
http://networkupstools.org/download.html ), then follow our user
manual ( http://networkupstools.org/docs/user-manual.chunked/ar01s05.html
- some steps are not needed if you already have NUT installed, just be
sure to use compatible configure/install options).

>
> i’v also tried with combo  06da/.
> it does not work…
> thanks

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powerwalker VI 2200VA LCD

[hyo...@gmail.com]

> [powerwalker]
>driver = blazer_usb
>vendorid = 06da
>port = auto
>desc = "Powerwalker VI 2200VA LCD"
>productid = 
>bus = "001"

The VID/PID combo 06da/ is used by some devices supported by the
'usbhid-ups' driver: did you have a chance to try it?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] connection pb with blazer_usb with infusec UPS

[hyo...@gmail.com]

2016-10-01 17:59 GMT+02:00 MATHIEU Clement :
> Hello
>
> i need your help regarding the following issue :
>
> i have a hero touch ups from infosec. it is connected via USB to a raspberry
> pi 3.
> i’ve configure ups.conf file as below
>
> [HERO]
>driver = blazer_usb
>vendorid = 0665
>productid = 5161
>
> either with
>port = auto
> or
>port = /dev/hidraw0
> or
>   port = /dev/ttySo
>
> the connection never works

The 'blazer_usb' driver (like others based on libusb) don't actually
use the 'port' argument, but, since it is still required by NUT, you
should set it to 'auto'.

>
> i get the following log from command line :
> sudo /lib/nut/blazer_usb -a HERO -DDD -u root
> Network UPS Tools - Megatec/Q1 protocol USB driver 0.11 (2.7.2)
>0.00 debug level is '3'
>0.003947 Checking device (0665/5161) (001/116)
>0.016760 - VendorID: 0665
>0.017245 - ProductID: 5161
>0.017686 - Manufacturer: INNO TECH
>0.018127 - Product: USB to Serial
>0.018598 - Serial Number: unknown
>0.019086 - Bus: 001
>0.019540 Trying to match device
>0.020136 Device matches
>0.020655 failed to claim USB device: could not claim interface 0: Device
> or resource busy
>0.021625 detached kernel driver from USB device...
>0.022676 Trying megatec protocol...
>0.025291 send: Q1
>0.153928 read: N
>0.154751 blazer_status: short reply
>0.155441 Status read 1 failed
>0.156783 send: Q1
>0.286922 read: N
>0.287605 blazer_status: short reply
>0.288335 Status read 2 failed
>0.289796 send: Q1
>0.419969 read: N
>0.420052 blazer_status: short reply
>0.420081 Status read 3 failed
>0.420107 Trying mustek protocol...
>0.420818 send: QS
>1.654899 read: could not claim interface 0: Device or resource busy
>1.655782 blazer_status: short reply
>1.656445 Status read 1 failed
>1.657598 send: QS
>2.891901 read: could not claim interface 0: Device or resource busy
>2.892810 blazer_status: short reply
>2.893497 Status read 2 failed
>2.894755 send: QS
>4.129250 read: could not claim interface 0: Device or resource busy
>4.129411 blazer_status: short reply
>4.129503 Status read 3 failed
>4.129590 Trying megatec/old protocol...
>4.130286 send: D
>4.254420 read: N
>4.254520 blazer_status: short reply
>4.254608 Status read 1 failed
>4.255296 send: D
>4.379452 read: N
>4.379601 blazer_status: short reply
>4.379692 Status read 2 failed
>4.380447 send: D
>4.504477 read: N
>4.504631 blazer_status: short reply
>4.504725 Status read 3 failed
>4.504812 Trying zinto protocol...
>4.505581 send: Q1
>4.635465 read: N
>4.635565 blazer_status: short reply
>4.635654 Status read 1 failed
>4.636344 send: Q1
>4.766481 read: N
>4.766580 blazer_status: short reply
>4.78 Status read 2 failed
>4.767360 send: Q1
>4.897519 read: N
>4.897659 blazer_status: short reply
>4.897749 Status read 3 failed
>4.897835 No supported UPS detected
> any idea ?

This seems like something that might be supported by 'nutdrv_qx'
driver with 'voltronic-qs-hex' protocol, an early version of which is
part of the 2.7.3 release, while an improved version with support for
more devices is available in 2.7.4. If possible, give it a try.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Blazer_usb driver almost supports Centralion Titan Elite, but not quite

[hyo...@gmail.com]

Can you please switch to driver 'nutdrv_qx' with all the optional
settings (vendorid, productid, subdriver, protocol, synchronous,
novendor, norating, pollinterval) removed and report back?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_qx - Device not supported

[hyo...@gmail.com]

> I have the RCT 3KVA Axpert solar hybrid inverter.  It is also known as the
> MPP Solar PIP-MS series, the IPS-4000WM and the Voltronic Axpert MKS.  I am

This device could be supported by nutdrv_qx (subdriver
'voltronic-sunny') built starting from this branch:
https://github.com/zykh/nut/tree/nutdrv_qx_voltronic-sunny_rebased+command

Please note that this subdriver is not ready yet for primetime (I'm
working on it with Nick, CC'ed. - Sorry for my delay, Nick, I'll
review your new work as soon as possible), so there could still be
some issues.
Apart from that, the main problem is that NUT is, to some extent,
still too much UPS-centric, so we'll have to change a couple of things
in our source code before we can fully support this kind of devices.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powermust 1400 USB

[hyo...@gmail.com]

mmh.. the logs don't look good.

Some UPSes don't communicate through both serial and USB at the same
time, some even refuse to work when you change from USB to serial and
viceversa unless you reboot them, so maybe it's worth trying to unplug
the USB from the UPS, reboot the UPS and then plug the serial cable
and see if it works.

Also:
- which are the specs and configuration of the serial port on your computer?
- the serial cable was shipped with the UPS?
- did the UPS come with some sort of controling software? If so, does it work?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powermust 1400 USB

[hyo...@gmail.com]

3 additional requests:
- can you plug the UPS to the serial port and test it with nutdrv_qx
(still with a debug level of 5)?
- can you test the UPS with blazer_usb and blazer_ser with a debug level of 3?
- which version of libusb/libusb-compat do you have?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powermust 1400 USB

[hyo...@gmail.com]

Can you try the nutdrv_qx driver with a debug level of 5 (i.e. five D
flags, nutdrv_qx -a upsname -D )?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Fry's Electronics UPS...

[hyo...@gmail.com]

2015-04-23 19:16 GMT+02:00 James Hammond james_r_hamm...@hotmail.com:
 #lsusb

 Bus 001 Device 003: ID 0001: Fry's Electronics

[...]

   iManufacturer   1 ATCL FOR UPS
   iProduct1 ATCL FOR UPS
   iSerial 1 ATCL FOR UPS

[...]

 root@unifi:/lib/nut# ./blazer_usb -DD -a nutdev1
 Network UPS Tools - Megatec/Q1 protocol USB driver 0.10 (2.7.1)
0.00 debug level is '2'

[...]

0.244816 Checking device (0001/) (001/003)
0.244939 - VendorID: 0001
0.244961 - ProductID: 
0.244973 - Manufacturer: unknown
0.244984 - Product: unknown
0.244992 - Serial Number: unknown
0.245003 - Bus: 001
0.245015 Trying to match device
0.245134 Device does not match - skipping

What happened to the iManufacturer/iProduct/iSerialNumber strings?
Try removing the 'product'/'serial'/'vendor'/'bus' lines from here:

 [nutdev1]
 driver = blazer_usb
 port = auto
 vendorid = 0001
 productid = 
 product = ATCL FOR UPS
 serial = ATCL FOR UPS
 vendor = ATCL FOR UPS
 bus = 001

Then try again.
(I'm not expecting it to work but.. who knows..)

 Is there anything else I can try or just forget it?

It could work with drivers 'nutdrv_atcl_usb' (available since NUT
version 2.7.2) or with 'nutdrv_qx' (since 2.7.3).

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_atcl_usb

[hyo...@gmail.com]

Thanks! Now merged into master, it'll be in the upcoming 2.7.3.

As icing on the cake, we'd appreciate a upsc/upsrw/upscmd dump for our own DDL:
http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/
https://github.com/networkupstools/nut-ddl

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_atcl_usb

[hyo...@gmail.com]

2015-03-11 14:21 GMT+01:00 Jakub Scepka jakub.sce...@gmail.com:
 Would you be so kind and provide some examples (commands), please?
 I would run them today in the evening and report back with the logs.

First, be sure to have in upsd.users a valid entry to set vars and
execute instant commands:

[username]
password = password
actions = SET
instcmds = ALL

where username and password are strings of your choice.

Then stop all the NUT-related things already running and (as per
configuration you posted earlier):

- terminal #1 - as root (this should generete the log we are after):
nutdrv_qx -a ups -D  /path/to/my/precious/log 21
And keep it running all the time till the tests are over.

- terminal #2 - as root:
upsd -D
This one too is expected to be kept alive all the time.

- terminal #3:
# shutdown.stayoff with ups.delay.shutdown set to 30 seconds;
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upscmd -u username -p password ups shutdown.stayoff

# shutdown.stayoff with ups.delay.shutdown set to 60 seconds;
upsrw -s ups.delay.shutdown=60 -u username -p password ups
upscmd -u username -p password ups shutdown.stayoff

# shutdown.return with ups.delay.shutdown set to 30 seconds and
ups.delay.start set to 60 seconds;
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upsrw -s ups.delay.start=60 -u username -p password ups
upscmd -u username -p password ups shutdown.return

# shutdown.return with ups.delay.shutdown set to 30 seconds and
ups.delay.start set to 0 seconds;
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upsrw -s ups.delay.start=0 -u username -p password ups
upscmd -u username -p password ups shutdown.return

# shutdown.return with ups.delay.shutdown set to 60 seconds and
ups.delay.start set to 60 seconds;
upsrw -s ups.delay.shutdown=60 -u username -p password ups
upsrw -s ups.delay.start=60 -u username -p password ups
upscmd -u username -p password ups shutdown.return

# shutdown.return with ups.delay.shutdown set to 60 seconds and
ups.delay.start set to 0 seconds;
upsrw -s ups.delay.shutdown=60 -u username -p password ups
upsrw -s ups.delay.start=0 -u username -p password ups
upscmd -u username -p password ups shutdown.return

# shutdown.stop executed after one of the previous commands (while
ups.delay.shutdown elapses);
# e.g. after a shutdown.return:
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upsrw -s ups.delay.start=60 -u username -p password ups
upscmd -u username -p password ups shutdown.return
# wait ~15 seconds, then:
upscmd -u username -p password ups shutdown.stop

# load.on executed after one of the previous shutdowns (after a
successful shutdown.stayoff or while ups.delay.start elapses);
# e.g. after a shutdown.return:
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upsrw -s ups.delay.start=60 -u username -p password ups
upscmd -u username -p password ups shutdown.return
# wait ~45 seconds, then:
upscmd -u username -p password ups load.on

# load.off and then load.on.
upscmd -u username -p password ups load.off
# wait ~30 seconds, then:
upscmd -u username -p password ups load.on

If you want to stop the shutdowns, you can issue a shutdown.stop:
upscmd -u username -p password ups shutdown.stop

If the shutdown.stayoff commands succeed you can turn on the ups with a load.on:
upscmd -u username -p password ups load.on

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_atcl_usb

[hyo...@gmail.com]

2015-03-11 21:43 GMT+01:00 Jakub Scepka (private) jakub.sce...@gmail.com:
 Thank you for the commands...
 Please find attached log...

Looking at the log it seems that the only commands understood by the
UPS are the two shutdown.return with ups.delay.start=0.
If this is the case, I must confess I was sort of expecting something
like this as the other ups.delay.{start,shutdown}s and
shutdown.stayoff/load.off imply the use of 'SnRm' command which is too
long to fit in one 8 bytes interrupt (and then the driver has to use 2
interrupts).

 Im not sure if the Load.on worked, because in the end I had to manually
 start the UPS (with button).
 Anyway, let me know should I need to perform some steps again (probably yes,
 since I believe it was off).

But.. you say the UPS at the end of the test was off - so I'm a bit
puzzled now: I need you to help me clear my mind.
A little more testing and logs to produce.

First, put a dummy load (something like a lamp should suffice) under
UPS protection; cut the power to the UPS (but leave it grounded, I
don't want to have you on my conscience) to put it on battery.
Then, yet again:
- terminal #1 - as root:
nutdrv_qx -a ups -D  /path/to/my/precious/log 21

- terminal #2 - as root:
upsd -D

- terminal #3:
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upsrw -s ups.delay.start=0 -u username -p password ups
upscmd -u username -p password ups shutdown.return
# Wait ~15 seconds, then:
upscmd -u username -p password ups shutdown.stop
# Does this stop the shutdown? If so, wait ~60 seconds then:
upscmd -u username -p password ups shutdown.return
# Then wait till the UPS shutdowns the load (does it happen?); wait
one minute or so and then give back power to the UPS.
# In a short time frame the UPS should now start again bringing back
power to the attached load: does this happen?

# Now, just to confirm that the various 'SnRm' commands don't work,
cut again the power to the UPS and then:
upsrw -s ups.delay.shutdown=30 -u username -p password ups
upsrw -s ups.delay.start=60 -u username -p password ups
upscmd -u username -p password ups shutdown.return
# Wait ~60 seconds: does the UPS shutdown the load?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_atcl_usb

[hyo...@gmail.com]

2014-11-09 16:29 GMT+01:00 Charles Lepple clep...@gmail.com:
 On Nov 8, 2014, at 7:01 PM, hyo...@gmail.com wrote:

 Since this UPS seems to be supported by UPSmart2000I, it could use a
 serial-over-usb implementation of the megatec protocol.

 Dan, that is a good point - I had not considered it. I assume companies will 
 copy bogus product IDs, but the use of the exact same USB string descriptor 
 is odd.

 Did you have a chance to compare the rest of the lsusb output that Jani sent 
 earlier in this thread? If it matches, then maybe the ATCL FOR USB string 
 comes from some generic USB-to-serial adapter chip.

Ops, sorry - I didn't notice your reply before.
I only have the following thing

kernel: usb 8-2: new low-speed USB device number 2 using xhci_hcd
kernel: usb 8-2: New USB device found, idVendor=0001, idProduct=
kernel: usb 8-2: New USB device strings: Mfr=1, Product=1, SerialNumber=1
kernel: usb 8-2: Product: ATCL FOR UPS
kernel: usb 8-2: Manufacturer: ATCL FOR UPS
kernel: usb 8-2: SerialNumber: ATCL FOR UPS
kernel: usb 8-2: ep 0x81 - rounding interval to 64 microframes, ep
desc says 80 microframes
kernel: usb 8-2: ep 0x2 - rounding interval to 64 microframes, ep desc
says 80 microframes
kernel: hid-generic 0003:0001:.0002: hiddev0,hidraw1: USB HID
v1.11 Device [ATCL FOR UPS ATCL FOR UPS] on usb-:03:00.0-2/input0

and the attached capture.


Gembird-UPS-PS-001.pcap.tar.gz
Description: GNU Zip compressed data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_atcl_usb

[hyo...@gmail.com]

Nice!
By the way, to avoid the initial protocol autodetection procedure and
to speed up the startup, you should set 'protocol=megatec'.
Do the various instant commands seem to work? Can you test them all
and report back the logs (a debug level of 5 should be enough)?
Also, what's the output of 'lsusb -vvv -d 0001:' (as root)?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Fwd: Data stale error after short while

[hyo...@gmail.com]

mmh.. I looked quickly at the logs:
- from time to time some character is swapped with something other
(just like in the 'F' reply of your previous logs), but this shouldn't
be a big problem;
- then, suddenly, the queries timeout (just like when you relaunch the
driver after a stale) - this is the problem.

We need to make sure this isn't something vm-related (if so, having
almost zero experience with it, I'm not the right person to help):
- can you test it with the same os out of a vm? or
- can you setup a vm with an old version of ubuntu server (I'm
thinking of 10.04) and see if it behaves differently? (We had atleast
one somewhat similar issue in the past - with a different driver -,
claimed to be caused by usb/kernel interactions, GitHub #122)
- you previously said you were not able to restart blazer_usb but
successfully (albeit unintentionally) shut down the UPS after the
driver stopped working: is this reproducible? Can you log the launch
of blazer_usb with the 'k' switch (and still with -DDD) after the
driver stops working?

Also:
- have you tried playing with poll interval ('i' option)?
- do you see any difference if you launch, as root, the driver with
the '-u root' option?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Data stale error after short while

[hyo...@gmail.com]

 I'm trying to build the whole project but am obviously missing
 dependencies... I've come across a configure error

 syntax error near unexpected token `CPPUNIT,'

Did you rerun the autogen.sh script after installing pkg-config and
before launching configure?

 which I've seen in a previous discussion you (Charles) had with another user
 should be missing pkg-config dependency, but I do have pkg-config installed.
 I haven't been able to track down an idiot proof installation guide. Happy
 to continue to hack but if there is a guide it will speed me up.

I'm not overly familiar with ubuntu et similia, however I installed
ubuntu server 14.04.1 on a vm and got it working like this:

sudo apt install build-essential autoconf libtool pkg-config libusb-dev
cd /path/to/nut_source_dir/
./autogen.sh
./configure \
--without-all \
--without-ssl \
--with-usb \
--with-drivers=nutdrv_qx \
--sysconfdir=/etc/nut \
--with-drvpath=/lib/nut \
--with-statepath=/var/run/nut \
--with-altpidpath=/var/run/nut \
--with-pidpath=/var/run/nut \
--datadir=/usr/share/nut \
--with-udev-dir=/lib/udev \
--with-systemdsystemunitdir=/lib/systemd/system \
--with-user=nut \
--with-group=nut
make

(well, probably that configure line can be shrunk a little..)

Provided that you have already installed and configured the nut-server
package, you can simply launch the driver:
sudo /path/to/nut_source_dir/drivers/nutdrv_qx -a ups_name -DDD

Hope this helps.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Data stale error after short while

[hyo...@gmail.com]

Hello there.
I looked quickly at the logs:
1. this UPS seems to have a somewhat strange implementation of the
megatec protocol (or maybe it's just the usb-to-serial thing): 'F'
reply begins with '!' - it should be a '#' -, is it always like that?
2. after some time the expected first character ('(') of the 'Q1'
reply is replaced by a '$' but, alas, there was a bug in early
versions of nutdrv_qx that prevented the driver from getting a fresh
reply from the UPS under some circumstances, so probably it gets stuck
using always the same malformed reply.
If possible, upgrade to the current git head, maybe after some replies
with the first character swapped the UPS get back to the usual
behaviour.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nutdrv_atcl_usb

[hyo...@gmail.com]

If you still can't get it to work with nutdrv_atcl_usb, another
approach could be worth considering.

Since this UPS seems to be supported by UPSmart2000I, it could use a
serial-over-usb implementation of the megatec protocol.

A very first early version of the nutdrv_qx driver that should support
it can be found here:
https://github.com/zykh/nut/tree/nutdrv_qx-fuji

(USB subdriver 'fuji'; but it shouldn't be necessary to set it, as the
driver is expected to automatically select it according to the
iManufacturer/iProduct strings)

Note that the user I first developed it for abruptly stopped replying
to my mails (maybe his UPS went boom.. who knows?), so I don't really
know if it works or not: quite a lot of testing may be needed.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Lupus 500 MEC0003 Problems

[hyo...@gmail.com]

 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

My fault, fixed.

Plus, I changed the way the driver matches the usb devices, so that
your UPS should now be able to be recognized without specifying
subdriver/VID/PID.
Just specifying the driver/port in ups.conf should suffice now.

Here's the updated driver:
https://github.com/zykh/nut/tree/fabula-updated2

Let me know if it works.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Lupus 500 MEC0003 Problems

[hyo...@gmail.com]

 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.

 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?

 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.

 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.

 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?
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 i10 loop I'm not sure of it's
 purpose but I reduced it to i1 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.

Here's the updated driver:
https://github.com/zykh/nut/tree/fabula-updated

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] AtlantisLand don't want to wake up after the whiteout

[hyo...@gmail.com]

2013/12/6 Fabio Cecamore ceca...@hotmail.com:
 Hi all,

Hi

 I've problem with the management of my AtlantisLand UPS, the UPS don't want
 to wake up after the whiteout and I don't have any idea why..

Some (very old) units are known to have problems with small values for
ondelay (hence the default 3 minutes value):

https://github.com/networkupstools/nut/blob/master/drivers/blazer.c#L443

Have you tried increasing the standard ondelay?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Salicru SPS One in Debian

[hyo...@gmail.com]

Not of a big help here, but I think it's a voltronic power vesta 650:
http://www.voltronicpower.com/oCart2/index.php?route=product/productpath=37product_id=52

If that is the case, it should work both with the blazer drivers (i.e.
all but the shutdown sequence) and with the now defunct voltronic
ones.

With arno's words:
We are currently merging a new driver to replace blazer_* and would
also appreciate feedback on this if you can.

2013/11/9 Charles Lepple clep...@gmail.com:
 On Nov 8, 2013, at 3:23 AM, Josu Lazkano wrote:

 Hello, I have a Salicru SPS One 700VA device, I want to manage it with
 Debian Whezzy.

 I read some information in the net about how to configure but I can
 not get it working.

 I'm assuming you mean this blog post?

 http://blog.ciberterminal.net/2013/04/28/ups-salicru-en-nut/

 Could you help with this?

 This is the log when I connect the USB:

 [ 3194.688204] usb 4-4: new low-speed USB device number 2 using ohci_hcd
 [ 3194.857239] usb 4-4: New USB device found, idVendor=0665, idProduct=5161
 [ 3194.857250] usb 4-4: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=0
 [ 3194.857258] usb 4-4: Product: USB to Serial
 [ 3194.857264] usb 4-4: Manufacturer: INNO TECH
 [ 3194.997545] generic-usb 0003:0665:5161.0001: hiddev0,hidraw0: USB
 HID v1.00 Device [INNO TECH USB to Serial] on
 usb-:00:12.0-4/input0
 [ 3194.997596] usbcore: registered new interface driver usbhid
 [ 3194.997601] usbhid: USB HID core driver

 OS name and version: Debian Whezzy (3.2.0-4-amd64 kernel)
 NUT version: 2.6.4-2.3
 NUT installation method: apt-get install nut
 exact device name and related information: Salicru SPS One 700VA

 I try with this configuration:

 nut.conf: http://paste.debian.net/plain/64527

 It's really not necessary to use a pastebin for a one-line configuration 
 file...

 ups.conf: http://paste.debian.net/plain/64528
 upsd.conf: http://paste.debian.net/plain/64529
 upsd.users: http://paste.debian.net/plain/64530

 I would recommend changing the password once you put this system into 
 production.

 upsmon.conf: http://paste.debian.net/plain/64531

 When I try to get the device info, I get this:

 # upsc salicru
 Error: Driver not connected


 What other startup and debugging steps did you take?

 For testing on Debian, I would try 'sudo /lib/nut/blazer_usb -a salicru -DDD'

 If that works, you can ^C that and run 'sudo /etc/init.d/nut-server start'.

 --
 Charles Lepple
 clepple@gmail




 ___
 Nut-upsuser mailing list
 Nut-upsuser@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Zigor Ebro 650 compatibility - revisited (on Windows, at least)

[hyo...@gmail.com]

2013/9/16 Martyn Hill martyn.joseph.h...@gmail.com:
 Hi Arnaud and NUT team

 You may recall some time ago, I and a few others posted questions about the
 above referenced (cheap and cheerful) USB-based UPS - specifically regarding
 FreeBSD USB support in NUT. The original posting was entitled Zigor Ebro
 650 compatibility.

 I've since tried the latest Windows port of NUT with my WinXP laptop
 connected to the Zigor Ebro and finally gotten somewhere!

 NUT and Blazer version: Network UPS Tools - Megatec/Q1 protocol USB driver
 0.09 (2.6.5-3780M)

 This at least proves that my previously moody Zigor device _can_ communicate
 nicely with NUT - and one step closer to getting it to work in FreeBSD (with
 its fancy USB stack...) - which is my ultimate aim.

 I attach the output from running the blazer_usb.exe command in debug mode,
 with a very similar ups.conf that I had been using on FreeBSD, thus:

 [zigor_ebro_blazer]
 driver = blazer_usb
 port = auto
 desc = Zigor Ebro 650 USB UPS
 subdriver = krauler
 protocol = megatec
 langid_fix = 0x409
 vendorid = 0001
 productid = 
 bus = bus-0# This was different for FreeBSD, naturally.

 Aside from the occasional blazer_status: short reply ... Communications
 with UPS lost: status read failed! messages (from which it appears to
 recover perfectly well), plus the odd corrupted reply from the device - e.g.
 read: #Ff .0 2.0 12.00 50.0... blazer_rating: non numerical value [Ff .0],
 the output seems quite promising!

 Any ideas where I go from here - firstly to iron-out those buggy responses
 from the device and secondly (and where we left it previously), how to get
 FreeBSD to 'talk' libusb-0.1 or else allow FreeBSD (8.2) and NUT to work
 with this USB device?

If you're not interested in input.{voltage, current,
frequency}.nominal and battery.voltage.nominal you could add the
'norating' flag in your ups.conf: doing so the driver won't send to
the UPS the 'F' query, whose answer is causing those messages (i.e.
blazer_rating: non numerical value [Ff .0]).

There's something weird in the reply from the UPS: while it should be
like #nnn.n nnn nnn.n/nn.nn nn.ncr (n: 0..9), the input voltage
nominal - i.e. the first token - appears to be 'Ff\u0018.0'.
Here
https://lists.alioth.debian.org/pipermail/nut-upsuser/2012-September/007944.html
I see that he has the same UPS and its input.voltage.nominal it's ok.
So, if it's not because of some different configuration in the
ups.conf for the usb quirkiness, maybe it's something os-related.

/dan


 Thanks in advance for any guidance in troubleshooting this (possibly not
 very common) configuration.
 Martyn
 London.

 --
 There are 10 types of people in this world. Those who understand binary and
 those who don't.


 ___
 Nut-upsuser mailing list
 Nut-upsuser@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How to shutdown the system and put UPS in stayoff status rather than in return status

[hyo...@gmail.com]

Hi Roberto,
I wrote a new driver that should work also with your UPS, but I can't test
the USB version since my UPS has only a serial port.
I've addressed also your request to shutdown  stayoff instead of shutdown
 return. Are you willing to test it?
Please refer to
http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-April/006431.htmland
to
http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-April/006438.html
/thanks dan
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How to shutdown the system and put UPS in stayoff status rather than in return status

[hyo...@gmail.com]

Gmail 'ate' the first link:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-April/006431.html
Plus, i forgot to mention the link of Roberto's thread:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2013-March/008311.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser