Re: [Nut-upsuser] NUTDRV_ATCL_USB driver on Windows
On Apr 13, 2015, at 6:56 AM, Humberto Möckel hamber...@gmail.com wrote: Hello again! I'm the guy from the blazer_usb shutdown problem the other day. Now I moved on installing the system in another work PC with another kind of rebranded UPS. This ups is a double battery 1000VA UPS brand. Device identifies itself as ATCL FOR USB on device description. Blazer_usb seems to identify it as compatible but fails at sending commands. Yes, unfortunately there are several broken UPS models which all report VID:PID 0001:. The worst part is that there are now at least two with the string ATCL FOR UPS that are not compatible with each other. Here is the other thread: http://thread.gmane.org/gmane.comp.monitoring.nut.user/8808/focus=8839 Further reading took me to the NUTDRV_ATCL_USB driver that seems to be specifically for my type of UPS. The problem is it isn't present in the Windows port of NUT. ¿What can I do? I would recommend testing on a Linux box first to determine whether the nutdrv_atcl_usb or the new nutdrv_qx will handle your UPS properly. -- 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] NUTDRV_ATCL_USB driver on Windows
Hello again! I'm the guy from the blazer_usb shutdown problem the other day. Now I moved on installing the system in another work PC with another kind of rebranded UPS. This ups is a double battery 1000VA UPS brand. Device identifies itself as ATCL FOR USB on device description. Blazer_usb seems to identify it as compatible but fails at sending commands. Further reading took me to the NUTDRV_ATCL_USB driver that seems to be specifically for my type of UPS. The problem is it isn't present in the Windows port of NUT. ¿What can I do? 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] nutdrv_atcl_usb
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
[attachments were 100kB; trimmed] Begin forwarded message: From: Jakub Scepka (private) jakub.sce...@gmail.com Subject: Re: [Nut-upsuser] nutdrv_atcl_usb Date: March 13, 2015 at 4:30:08 PM EDT To: hyo...@gmail.com hyo...@gmail.com Cc: nut-upsuser nut-upsuser@lists.alioth.debian.org Hello Im back with my findings: J: I was very complicated to find some device with higher consumption (except of NAS server, which is not ideal for these tests), so I ended with attached air purifier. - terminal #3: upsrw -s ups.delay.shutdown=30 -u admin -p pass ups J: nothing visible happened upsrw -s ups.delay.start=0 -u admin -p pass ups J: nothing visible happened upscmd -u admin -p pass ups shutdown.return # Wait ~15 seconds, then: J: nothing visible happened upscmd -u admin -p pass ups shutdown.stop J: nothing visible happened # Does this stop the shutdown? If so, wait ~60 seconds then: J: No it did not I'm waiting... nothing... nothing visible happened upscmd -u admin -p pass ups shutdown.return J: I'm waiting a few seconds... and... yes, its gone # Then wait till the UPS shutdowns the load (does it happen?); wait one minute or so and then give back power to the UPS. J: Power cable reconnected, UPS remains totally death... # In a short time frame the UPS should now start again bringing back power to the attached load: does this happen? J: No, it didn't started I had to start it with button. It didn't started because circuit breaker did its job :D I'm going back to upscmd -u admin -p pass ups shutdown.return stepm this time with power cable attached. Again I had to start it with button. # 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 admin -p pass ups J: nothing visible happened upsrw -s ups.delay.start=60 -u admin -p pass ups J: nothing visible happened upscmd -u admin -p pass ups shutdown.return # Wait ~60 seconds: does the UPS shutdown the load? J: Waiting 1 minute or so nothing visible happened Log: log-friday_13.log.tar.gz J: Im going o try it again with power disconnected J:the same results, but this time, when I connected power cable, the circuit braker was fine, and UPS started fine (without touching the button). Log: log-friday_13-second_attept.log.tar.gz ___ 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
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
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
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. Thank you. Jakub S. On Tue, Mar 10, 2015 at 11:44 PM, hyo...@gmail.com hyo...@gmail.com wrote: mmh.. it looks like someone forgot to hit 'reply all'. - relaying the originally attached files (gzipped, minus the two screenshots, to keep size down). 2015-03-09 23:20 GMT+01:00 Jakub Scepka (private) jakub.sce...@gmail.com : Hi everyone! Here is summary for our fellows wit the same/similar UPS to save them 3 weeks of life :) First of all I'm running Ubuntu 14.10 (Utopic) on a normal laptop (not VirtualMachine!) and I had to download the source from: https://github.com/zykh/nut/tree/nutdrv_qx-fuji (Thank you Charles) #sudo apt-get remove nut #sudo su #apt-get install autoconf #apt-get install libtool #apt-get install libusb-dev #./configure --without-ssl --with-usb --with-user=nut --with-group=nut #make #make install #lsusb -vvv -d 0001: (see attached lsusb.log) Content of ups.conf: [ups] driver=nutdrv_qx protocol=megatec subdriver=fuji port=auto vendorid=0001 productid= #/usr/local/ups/bin$ sudo ./nutdrv_qx -a ups -D (see attached log.log) - I have tried to pull the plug - reinsert / reconnect it (220V) - poweroff the UPS (by button) - and power on (by button) #/usr/local/ups/sbin$ sudo ./upsdrvctl start Network UPS Tools - UPS driver controller 2.7.2.5 Network UPS Tools - Generic Q* USB/Serial driver 0.13 (2.7.2.5) USB communication driver 0.32 Using protocol: Megatec 0.02 No values for battery high/low voltages Using 'guesstimation' (low: 31.20, high: 39.00)! Battery runtime will not be calculated (runtimecal not set) # /usr/local/ups/sbin$ sudo ./upsd Network UPS Tools upsd 2.7.2.5 fopen /var/state/ups/upsd.pid: No such file or directory listening on 0.0.0.0 port 3493 Connected to UPS [ups]: nutdrv_qx-ups NUT monitor (GUI): see screenshot3.png and screenshot4.png I have tested (and it worked like a charm): - beeper.toggle - test.battery.start - test.battery.stop THANKS TO ALL OF YOU PEOPLE -- Originally my planes were to install NUT on a router (DD-WRT/Tomato) or on QNAP NAS (ARM arch.) but packages for these devices are too old and I don't know (so far) anything about compiling on/for these devices. My next logical step was to install Debian Virtual Machine on ESX server and compile NUT on it. But, this setup suddenly didn't worked, I blame ESX USB passthrought, or maybe I'm missing something else... Who knows... :) See nutdrv_qx_5xD.txt (commands: ./nutdrv_qx -a ups -D and ./nutdrv_qx -a ups -D -u root) or debianVM.txt (command: lsusb) if you are interested... It look similar to this: http://comments.gmane.org/gmane.comp.monitoring.nut.user/8970 -- BR Jakub On 09.03.2015 16:27, hyo...@gmail.com wrote: 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)? So far, so good! However, I need a little more testing before I can merge this into master. If possible, I'd like you to test and report back the logs (still with a debug level of 5) of: - shutdown.stayoff with ups.delay.shutdown set to 30 seconds; - shutdown.stayoff with ups.delay.shutdown set to 60 seconds; - shutdown.return with ups.delay.shutdown set to 30 seconds and ups.delay.start set to 60 seconds; - shutdown.return with ups.delay.shutdown set to 30 seconds and ups.delay.start set to 0 seconds; - shutdown.return with ups.delay.shutdown set to 60 seconds and ups.delay.start set to 60 seconds; - shutdown.return with ups.delay.shutdown set to 60 seconds and ups.delay.start set to 0 seconds; - shutdown.stop executed after one of the previous commands (while ups.delay.shutdown elapses); - load.on executed after one of the previous shutdowns (after a successful shutdown.stayoff or while ups.delay.start elapses); - load.off and then load.on. Thanks in advance for your patience. ___ 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
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
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] nutdrv_atcl_usb
On Mar 9, 2015, at 11:28 AM, hyo...@gmail.com wrote: 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 Hmm, the enumeration seems to be missing. But it definitely seems to be more of a query-response protocol. The nutdrv_atcl_usb driver just reads interrupt packets, and doesn't send anything except to trigger a shutdown. Could be a generic USB-to-serial chip, then. Too bad there isn't more to distinguish the two UPS types. -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
Suddenly yes, I also ended with Communications with UPS lost: Query to UPS failed (on Ubuntu 14.10) and have tried everything in this thread. Mine is called EUROCASE - UPS EA200N 2000VA, 2000VA, line interactive it looks exactly as EAST UPS - Pure Sine Wave UPS with LCD Display 2000VA or even brand Vivaldi. I would say is the same hardware with different branding. Mine is shipped with windows software UPSmart2000I EAST uses UPSmart (name is very similar too). It would be nice to try EAST UPS (windows) software with my UPS, to make sure is the same HW. I didnt tried yet nutdrv_qx-fuji BR Jakub On Thu, Mar 5, 2015 at 5:08 PM, Charles Lepple clep...@gmail.com wrote: On Mar 5, 2015, at 2:34 AM, Jakub jakub.sce...@gmail.com wrote: Come on, it started to be interesting! Do you have one of these UPSes? If so, here was Dan's email about a branch to test: 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. -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
It seems like it works (partially?) with NUT/driver you mentioned. I will test it more when I return home. root@Failure:/lib/nut# ./nutdrv_qx -a test -x subdriver=fuji -u root -x productid= -x vendorid=0001 -DD Network UPS Tools - Generic Q* USB/Serial driver 0.13 (2.7.2.5) USB communication driver 0.32 0.00 debug level is '6' 0.001247 upsdrv_initups... 0.311772 Checking device (1D6B/0001) (008/001) 0.335913 - VendorID: 1d6b 0.335937 - ProductID: 0001 0.335948 - Manufacturer: Linux 3.16.0-31-generic uhci_hcd 0.335959 - Product: UHCI Host Controller 0.335968 - Serial Number: :00:1d.2 0.335978 - Bus: 008 0.335987 Trying to match device 0.336008 Device does not match - skipping 0.336099 Checking device (1D6B/0001) (007/001) 0.359946 - VendorID: 1d6b 0.359970 - ProductID: 0001 0.359981 - Manufacturer: Linux 3.16.0-31-generic uhci_hcd 0.359991 - Product: UHCI Host Controller 0.360001 - Serial Number: :00:1d.1 0.360010 - Bus: 007 0.360019 Trying to match device 0.360032 Device does not match - skipping 0.360118 Checking device (0001/) (006/002) 0.398370 - VendorID: 0001 0.398393 - ProductID: 0.398403 - Manufacturer: ATCL FOR UPS 0.398413 - Product: ATCL FOR UPS 0.398422 - Serial Number: ATCL FOR UPS 0.398431 - Bus: 006 0.398440 Trying to match device 0.398516 Device matches 0.398548 failed to claim USB device: could not claim interface 0: Device or resource busy 0.398585 detached kernel driver from USB device... 0.398627 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0) 0.398652 send_to_all: SETINFO ups.vendorid 0001 0.398667 send_to_all: SETINFO ups.productid 0.398711 command: (8 bytes) = 80 06 04 03 51 47 53 00 0.403387 send: QGS 1.406382 read: could not claim interface 0: Device or resource busy (-110) 1.406443 qx_process_answer: short reply (input.voltage) 1.406477 command: (8 bytes) = 80 06 04 03 51 47 53 00 1.411388 send: QGS 2.413380 read: could not claim interface 0: Device or resource busy (-110) 2.413421 qx_process_answer: short reply (input.voltage) 2.413452 command: (8 bytes) = 80 06 04 03 51 47 53 00 2.419388 send: QGS 3.421378 read: could not claim interface 0: Device or resource busy (-110) 3.421417 qx_process_answer: short reply (input.voltage) 3.421442 command: (8 bytes) = 80 06 02 03 4d 00 00 00 3.427373 send: M 4.429381 read: could not claim interface 0: Device or resource busy (-110) 4.429439 qx_process_answer: short reply (ups.firmware.aux) 4.429467 command: (8 bytes) = 80 06 02 03 4d 00 00 00 4.435376 send: M 5.437377 read: could not claim interface 0: Device or resource busy (-110) 5.437461 qx_process_answer: short reply (ups.firmware.aux) 5.437524 command: (8 bytes) = 80 06 02 03 4d 00 00 00 5.443380 send: M 6.445376 read: could not claim interface 0: Device or resource busy (-110) 6.445418 qx_process_answer: short reply (ups.firmware.aux) 6.445444 command: (8 bytes) = 80 06 02 03 4d 00 00 00 6.451412 send: M 7.454378 read: could not claim interface 0: Device or resource busy (-110) 7.454441 qx_process_answer: short reply (ups.firmware.aux) 7.454469 command: (8 bytes) = 80 06 02 03 4d 00 00 00 7.459388 send: M 8.462379 read: could not claim interface 0: Device or resource busy (-110) 8.462427 qx_process_answer: short reply (ups.firmware.aux) 8.462452 command: (8 bytes) = 80 06 02 03 4d 00 00 00 8.467379 send: M 9.469379 read: could not claim interface 0: Device or resource busy (-110) 9.469420 qx_process_answer: short reply (ups.firmware.aux) 9.469446 command: (8 bytes) = 80 06 03 03 51 53 00 00 9.475378 send: QS 10.477351 read: could not claim interface 0: Device or resource busy (-110) 10.477387 qx_process_answer: short reply (input.voltage) 10.477402 command: (8 bytes) = 80 06 03 03 51 53 00 00 10.483349 send: QS 11.485378 read: could not claim interface 0: Device or resource busy (-110) 11.485419 qx_process_answer: short reply (input.voltage) 11.485447 command: (8 bytes) = 80 06 03 03 51 53 00 00 11.491377 send: QS 12.494391 read: could not claim interface 0: Device or resource busy (-110) 12.494430 qx_process_answer: short reply (input.voltage) 12.494456 command: (8 bytes) = 80 06 02 03 44 00 00 00 12.499380 send: D 13.501395 read: could not claim interface 0: Device or resource busy (-110) 13.501554 qx_process_answer: short reply (input.voltage) 13.501628 command: (8 bytes) = 80 06 02 03 44 00 00 00 13.507372 send: D 14.509379 read: could
Re: [Nut-upsuser] nutdrv_atcl_usb
On Mar 5, 2015, at 2:34 AM, Jakub jakub.sce...@gmail.com wrote: Come on, it started to be interesting! Do you have one of these UPSes? If so, here was Dan's email about a branch to test: 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. -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
Come on, it started to be interesting! ___ 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
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] nutdrv_atcl_usb
On Nov 5, 2014, at 1:36 AM, jani jani.tali...@gmail.com wrote: Ok, I installed a fresh Debian testing (jessie) onto a laptop to try making sure it wasn't my current Ubuntu server causing the issue. Kernel is 3.16-3-686-pae #1 SMP Debian 3.16.5-1 (2014-10-10). The only thing installed besides the stock debian desktop is nut. The UPS still refuses to talk to the driver, the error messages appear to be identical, but I attached them just in case I'm missing something important. I tried changing the permissions and running as root just in case, and they made no difference. Hmm, maybe those aren't the /dev node names that it is using. Can please you send the output of: strace -o nutdrv_atcl_usb.strace /lib/nut/nutdrv_atcl_usb -a name -DD Also, if you run 'ldd /lib/nut/nutdrv_atcl_usb', is it linking against 'libusb-0.1.so.4' or libusb-compat? -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
The output of the ldd command is: root@minime:~# ldd /lib/nut/nutdrv_atcl_usb linux-gate.so.1 (0xb7722000) libusb-0.1.so.4 = /lib/i386-linux-gnu/libusb-0.1.so.4 (0xb76fe000) libpthread.so.0 = /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb76e2000) libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7536000) /lib/ld-linux.so.2 (0xb7725000) The UPS was connected to device 001/002 again as I ran the strace. The output is attached. On 6 November 2014 00:22, Charles Lepple clep...@gmail.com wrote: On Nov 5, 2014, at 1:36 AM, jani jani.tali...@gmail.com wrote: Ok, I installed a fresh Debian testing (jessie) onto a laptop to try making sure it wasn't my current Ubuntu server causing the issue. Kernel is 3.16-3-686-pae #1 SMP Debian 3.16.5-1 (2014-10-10). The only thing installed besides the stock debian desktop is nut. The UPS still refuses to talk to the driver, the error messages appear to be identical, but I attached them just in case I'm missing something important. I tried changing the permissions and running as root just in case, and they made no difference. Hmm, maybe those aren't the /dev node names that it is using. Can please you send the output of: strace -o nutdrv_atcl_usb.strace /lib/nut/nutdrv_atcl_usb -a name -DD Also, if you run 'ldd /lib/nut/nutdrv_atcl_usb', is it linking against 'libusb-0.1.so.4' or libusb-compat? -- Charles Lepple clepple@gmail nutdrv_atcl_usb.strace.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
On Nov 5, 2014, at 4:39 PM, jani jani.tali...@gmail.com wrote:
The output of the ldd command is:
root@minime:~# ldd /lib/nut/nutdrv_atcl_usb
linux-gate.so.1 (0xb7722000)
libusb-0.1.so.4 = /lib/i386-linux-gnu/libusb-0.1.so.4 (0xb76fe000)
libpthread.so.0 = /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
(0xb76e2000)
libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7536000)
/lib/ld-linux.so.2 (0xb7725000)
The UPS was connected to device 001/002 again as I ran the strace. The output
is attached.
That's strange. The return codes seem to imply that the requests are timing
out, rather than there being a permissions problem:
open(/dev/bus/usb/001/002, O_RDWR)= 4
ioctl(4, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xbff9a28c) = 4
ioctl(4, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xbff9a28c) = 26
ioctl(4, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xbff9a28c) = 4
ioctl(4, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xbff9a28c) = 26
ioctl(4, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xbff9a28c) = 4
ioctl(4, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xbff9a28c) = 26
gettimeofday({1415223033, 301661}, NULL) = 0
write(2,0.365267\t, 12) = 12
write(2, - VendorID : 0001\n, 22) = 22
gettimeofday({1415223033, 303407}, NULL) = 0
write(2,0.367013\t, 12) = 12
write(2, - ProductID: \n, 22) = 22
gettimeofday({1415223033, 304892}, NULL) = 0
write(2,0.368498\t, 12) = 12
write(2, - Manufacturer : ATCL FOR UPS\n, 30) = 30
gettimeofday({1415223033, 306351}, NULL) = 0
write(2,0.369957\t, 12) = 12
write(2, - Product : ATCL FOR UPS\n, 30) = 30
gettimeofday({1415223033, 307797}, NULL) = 0
write(2,0.371403\t, 12) = 12
write(2, - Serial Number: ATCL FOR UPS\n, 30) = 30
gettimeofday({1415223033, 308963}, NULL) = 0
write(2,0.372569\t, 12) = 12
write(2, - Bus : 001\n, 21) = 21
gettimeofday({1415223033, 310519}, NULL) = 0
write(2,0.374125\t, 12) = 12
write(2, Matched expected vendor='ATCL FO..., 40) = 40
ioctl(4, USBDEVFS_SETCONFIGURATION, 0xbff9a424) = 0
ioctl(4, USBDEVFS_CLAIMINTERFACE, 0xbff9a424) = 0
gettimeofday({1415223033, 315012}, NULL) = 0
write(2,0.378618\t, 12) = 12
write(2, USB device [0001:] opened\n, 30) = 30
gettimeofday({1415223033, 316830}, NULL) = 0
ioctl(4, USBDEVFS_SUBMITURB, 0xbff9a580) = 0
ioctl(4, USBDEVFS_REAPURBNDELAY, 0xbff9a564) = -1 EAGAIN (Resource temporarily
unavailable)
select(5, NULL, [4], NULL, {0, 1000}) = 0 (Timeout)
On 6 November 2014 00:22, Charles Lepple clep...@gmail.com wrote:
On Nov 5, 2014, at 1:36 AM, jani jani.tali...@gmail.com wrote:
Ok, I installed a fresh Debian testing (jessie) onto a laptop to try making
sure it wasn't my current Ubuntu server causing the issue. Kernel is
3.16-3-686-pae #1 SMP Debian 3.16.5-1 (2014-10-10). The only thing installed
besides the stock debian desktop is nut.
When you say the stock debian desktop, what is running at that point,
something like Gnome, Xfce or LXDE?
If possible, it would be good to do the test on a text-mode console, with
nothing else running.
The UPS still refuses to talk to the driver, the error messages appear to be
identical, but I attached them just in case I'm missing something important.
I tried changing the permissions and running as root just in case, and they
made no difference.
Hmm, maybe those aren't the /dev node names that it is using. Can please you
send the output of:
strace -o nutdrv_atcl_usb.strace /lib/nut/nutdrv_atcl_usb -a name -DD
Also, if you run 'ldd /lib/nut/nutdrv_atcl_usb', is it linking against
'libusb-0.1.so.4' or libusb-compat?
--
Charles Lepple
clepple@gmail
nutdrv_atcl_usb.strace.gz___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
--
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
Re: [Nut-upsuser] nutdrv_atcl_usb
For reference, here's the thread discussing the development of that driver: http://news.gmane.org/find-root.php?message_id=52B4C54E.1050106%40ariwainer.com.ar It seems to have worked under Kubuntu 13.10.___ 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
I'm running Ubuntu 14.04.1 LTS with kernel 3.13.0-39-generic x86_64. The security mechanisms I haven't played with at all, and up until last week nut was running just fine on an Eaton E series NV UPS with a USB connection (from memory it used the blazer_usb driver). I installed the nut packages from debian sid (ubuntu is still stuck on nut version 2.7.1) to get the 2.7.2 version with the nutdrv_atcl_usb driver. I tried adding the -u root to the driver command line, that didn't change anything. I might try to find a spare machine to run Debian on to see if it works that way. On Tue Nov 04 2014 at 3:38:21 PM Charles Lepple clep...@gmail.com wrote: On Nov 3, 2014, at 9:01 PM, jani jani.tali...@gmail.com wrote: Hello again, I ran the commands again, checking to make sure the UPS was still device 005/002, and the results is: root@microserver:~# ls -l /dev/bus/usb/005/002 crw-rw-r-- 1 root nut 189, 513 Nov 4 12:55 /dev/bus/usb/005/002 I tried setting permissions of /dev/bus/usb/005/002 to 777 and ran the test again to see what that would do, but there was no difference in the status interrupt read error messages. Well, that's odd. Can you provide a little more detail about your system? (distribution, kernel version, any security mechanisms like SELinux or AppArmor, etc.) Also, what happens if you add -u root to the driver command line? (The 'chmod 777' should have been sufficient...) -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
Ok, I installed a fresh Debian testing (jessie) onto a laptop to try making sure it wasn't my current Ubuntu server causing the issue. Kernel is 3.16-3-686-pae #1 SMP Debian 3.16.5-1 (2014-10-10). The only thing installed besides the stock debian desktop is nut. The UPS still refuses to talk to the driver, the error messages appear to be identical, but I attached them just in case I'm missing something important. I tried changing the permissions and running as root just in case, and they made no difference. On 5 November 2014 11:55, jani jani.tali...@gmail.com wrote: I'm running Ubuntu 14.04.1 LTS with kernel 3.13.0-39-generic x86_64. The security mechanisms I haven't played with at all, and up until last week nut was running just fine on an Eaton E series NV UPS with a USB connection (from memory it used the blazer_usb driver). I installed the nut packages from debian sid (ubuntu is still stuck on nut version 2.7.1) to get the 2.7.2 version with the nutdrv_atcl_usb driver. I tried adding the -u root to the driver command line, that didn't change anything. I might try to find a spare machine to run Debian on to see if it works that way. On Tue Nov 04 2014 at 3:38:21 PM Charles Lepple clep...@gmail.com wrote: On Nov 3, 2014, at 9:01 PM, jani jani.tali...@gmail.com wrote: Hello again, I ran the commands again, checking to make sure the UPS was still device 005/002, and the results is: root@microserver:~# ls -l /dev/bus/usb/005/002 crw-rw-r-- 1 root nut 189, 513 Nov 4 12:55 /dev/bus/usb/005/002 I tried setting permissions of /dev/bus/usb/005/002 to 777 and ran the test again to see what that would do, but there was no difference in the status interrupt read error messages. Well, that's odd. Can you provide a little more detail about your system? (distribution, kernel version, any security mechanisms like SELinux or AppArmor, etc.) Also, what happens if you add -u root to the driver command line? (The 'chmod 777' should have been sufficient...) -- Charles Lepple clepple@gmail atcl_logs.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
Hello again, I ran the commands again, checking to make sure the UPS was still device 005/002, and the results is: root@microserver:~# ls -l /dev/bus/usb/005/002 crw-rw-r-- 1 root nut 189, 513 Nov 4 12:55 /dev/bus/usb/005/002 I tried setting permissions of /dev/bus/usb/005/002 to 777 and ran the test again to see what that would do, but there was no difference in the status interrupt read error messages. On 1 November 2014 23:55, Charles Lepple clep...@gmail.com wrote: On Nov 1, 2014, at 8:09 AM, jani jani.tali...@gmail.com wrote: Hi Charles, Here is the output of those. I also ran the driver a second time with debug level 4, just in case there were any extra hints in there. Here's the culprit: 5.338858 status interrupt read: error sending control message: Operation not permitted What does 'ls -l /dev/bus/usb/005/002' say? If the UPS has been unplugged since the logs were generated, replace 005/002 with the path suffix from this set of messages: 5.499162 Checking USB device [0001:] (005/002) 5.510156 - VendorID : 0001 5.510202 - ProductID: 5.510209 - Manufacturer : ATCL FOR UPS 5.510219 - Product : ATCL FOR UPS 5.510225 - Serial Number: ATCL FOR UPS 5.510231 - Bus : 005 5.510237 Matched expected vendor='ATCL FOR UPS'. 5.512216 USB device [0001:] opened Depending on your distribution and how you installed NUT, some extra steps may be necessary to fix the permissions every time the UPS is plugged in. (NUT ships with a udev rules file.) We need to fix the logging levels - the permissions message should have been logged at a higher priority. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
On Nov 3, 2014, at 9:01 PM, jani jani.tali...@gmail.com wrote: Hello again, I ran the commands again, checking to make sure the UPS was still device 005/002, and the results is: root@microserver:~# ls -l /dev/bus/usb/005/002 crw-rw-r-- 1 root nut 189, 513 Nov 4 12:55 /dev/bus/usb/005/002 I tried setting permissions of /dev/bus/usb/005/002 to 777 and ran the test again to see what that would do, but there was no difference in the status interrupt read error messages. Well, that's odd. Can you provide a little more detail about your system? (distribution, kernel version, any security mechanisms like SELinux or AppArmor, etc.) Also, what happens if you add -u root to the driver command line? (The 'chmod 777' should have been sufficient...) -- 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
Re: [Nut-upsuser] nutdrv_atcl_usb
On Nov 1, 2014, at 1:30 AM, jani wrote: Hi Charles, I just bought a UPS that announces itself as 'ATCL FOR UPS' with VendorId of 0001. It seems to be a re-badged unit manufactured by Guangdong East Power company, and besides the little brand stamp it looks identical to: http://eastups.com/en/productshow.aspx?CateId=473Id=164PCateId=447 It came with a windows cd containing the windows software entitled UPSmart2000I version 3.7 and while I haven't installed it the screenshots show that you can get input and output voltage and battery voltage information out of the thing. The problem is the nutdrv_atcl_usb driver out of nut 2.7.2 doesn't seem to function, I get the following in my logs: Nov 1 16:28:49 microserver nutdrv_atcl_usb[2242]: Warning: excessive comm failures, limiting error reporting Nov 1 16:28:49 microserver nutdrv_atcl_usb[2242]: Communications with UPS lost: Query to UPS failed Is there anything I can do to help troubleshoot the issue? Please run (as root) 'killall nutdrv_atcl_usb' and re-run the driver with the debug level set to at least 2: /path/to/nutdrv_atcl_usb -a name -DD 21 | tee nutdrv_atcl_usb.log Then, please gzip and send the log as an attachment (to keep the size down, and to prevent the lines from getting mangled). Also, the output of 'lsusb -vvv -d 0001:' (run as root) would be useful for comparison. ___ 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
Hi Charles, Here is the output of those. I also ran the driver a second time with debug level 4, just in case there were any extra hints in there. cheers, Jani On 1 November 2014 22:12, Charles Lepple clep...@gmail.com wrote: On Nov 1, 2014, at 1:30 AM, jani wrote: Hi Charles, I just bought a UPS that announces itself as 'ATCL FOR UPS' with VendorId of 0001. It seems to be a re-badged unit manufactured by Guangdong East Power company, and besides the little brand stamp it looks identical to: http://eastups.com/en/productshow.aspx?CateId=473Id=164PCateId=447 It came with a windows cd containing the windows software entitled UPSmart2000I version 3.7 and while I haven't installed it the screenshots show that you can get input and output voltage and battery voltage information out of the thing. The problem is the nutdrv_atcl_usb driver out of nut 2.7.2 doesn't seem to function, I get the following in my logs: Nov 1 16:28:49 microserver nutdrv_atcl_usb[2242]: Warning: excessive comm failures, limiting error reporting Nov 1 16:28:49 microserver nutdrv_atcl_usb[2242]: Communications with UPS lost: Query to UPS failed Is there anything I can do to help troubleshoot the issue? Please run (as root) 'killall nutdrv_atcl_usb' and re-run the driver with the debug level set to at least 2: /path/to/nutdrv_atcl_usb -a *name* -DD 21 | tee nutdrv_atcl_usb.log Then, please gzip and send the log as an attachment (to keep the size down, and to prevent the lines from getting mangled). Also, the output of 'lsusb -vvv -d 0001:' (run as root) would be useful for comparison. atcl_usb_logs.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
On Nov 1, 2014, at 8:09 AM, jani jani.tali...@gmail.com wrote: Hi Charles, Here is the output of those. I also ran the driver a second time with debug level 4, just in case there were any extra hints in there. Here's the culprit: 5.338858 status interrupt read: error sending control message: Operation not permitted What does 'ls -l /dev/bus/usb/005/002' say? If the UPS has been unplugged since the logs were generated, replace 005/002 with the path suffix from this set of messages: 5.499162 Checking USB device [0001:] (005/002) 5.510156 - VendorID : 0001 5.510202 - ProductID: 5.510209 - Manufacturer : ATCL FOR UPS 5.510219 - Product : ATCL FOR UPS 5.510225 - Serial Number: ATCL FOR UPS 5.510231 - Bus : 005 5.510237 Matched expected vendor='ATCL FOR UPS'. 5.512216 USB device [0001:] opened Depending on your distribution and how you installed NUT, some extra steps may be necessary to fix the permissions every time the UPS is plugged in. (NUT ships with a udev rules file.) We need to fix the logging levels - the permissions message should have been logged at a higher priority. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser -- 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
