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] building from git (was Re: Install problems (group permissions) with nut 2.7.2)
Ok, that worked great. I make a .tar, took it somewhere else, untarred it, configured, and built. Then I installed the result and ran it, and it shows 2.7.2.6_RTD for a version number. Awesome! Today I work on commands to tell the UPS to turn off...fun! Sincerely, Rob Groner Software Engineer RTD Embedded Technologies, Inc. ISO9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, March 10, 2015 7:48 PM To: Rob Groner Cc: nut-upsuser List Subject: Re: [Nut-upsuser] building from git (was Re: Install problems (group permissions) with nut 2.7.2) On Mar 10, 2015, at 11:20 AM, Rob Groner rgro...@rtd.com wrote: I added _RTD to the version string in configure.ac and ran autogen.sh and then configure, and it now shows the _RTD version string during configure. I did a clean make and install, but don't see where else the version number may be showing. When the executables startup, they show 2.7.2-signed-*. I never finished the cleanup of that code, I guess. If you build and install from the Git tree, it generates a version based on the latest tag in Git. The tarball generated from 'make dist' uses the version in configure.ac, but only if you build it outside of the Git working directory. -- 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
