Re: [Nut-upsuser] UPS restart delay
Hi Dan, 2012/8/10 Daniel O'Connor docon...@gsoft.com.au On 09/08/2012, at 23:37, Arnaud Quette aquette@gmail.com wrote: sorry for the time taken to provide you an answer, but there it is :) No problem, I am happy you could try it on the same hardware . sure, it's always better to ensure a user problem is solved. There is a data (HID: UPS.PowerSummary.PresentStatus.Switchable) that wasn't mapped in NUT. This data allows to send shutdown order to the UPS, and is equivalent to what you have on the LCD screen of the UPS. I've not seen this before because this data is enabled by default... Hmm, what parameter is it called on the LCD panel? Refer to the manual: http://pqtools.eaton.com/download/intl/products/comet-ex-rt/148-man_uk_08.pdf page 27, chapter 3, ON/OFF features = UPS ON/OFF by software the parameter I've added in NUT (ups.shutdown) is directly connected to the same data than the above LCD feature. I was on holiday when the UPS was tested and shipped so I didn't get a chance to try things myself. the danger of letting other do the work ;-) The fix is both attached (limited to the code) and committed to the trunk r3717: http://trac.networkupstools.org/projects/nut/changeset/3717 Once applied, check with upsc that ups.shutdown is set to enabled. Otherwise, use: # upsrw -u user -p password -s ups.shutdown=enabled device name You can then test it using upsmon -c fsd if you have protected loads, or simply with: # upscmd -u user -p password device name shutdown.return Can you please confirm back that the issue is closed on your side? I should be able to try it later on today, or tomorrow. Thanks again! ok, let me know if you still face any issue. I'll be on vacation at the end of next week... cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110
Hi Massimo and Greg, 2012/8/9 Massimo Gais simosa...@gmail.com On Wed, Aug 8, 2012 at 1:32 PM, Greg Vickers daehe...@iinet.net.au wrote: Fantastic Massimo, thank you! I have yet to replace my 5110, so if there is anything I can contribute, I will do. It looks like the only difference between our systems is the kernel version (I've put the latest rasbian image on, which has kernel 3.2.0-3-rpi). Maybe the problem is specific to the RPi USB. This is the debug from my UPS plugged to old faithful NSLU2, when I launch the command /lib/nut/bcmxcp_usb -DDD -a ups: (...) 0.812160 get_answer: block_number = 1 0.812220 get_answer: data length = 121 0.812281 get_answer: need to read 6 more data 0.814929 get_answer: (128 bytes) = ab 01 79 01 02 50 00 50 01 00 0e 00 01 00 10 50 0.815110 4f 57 45 52 57 41 52 45 20 55 50 53 20 20 20 5c 00 00 00 00 00 00 00 00 00 0.815237 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 51 00 00 00 00 51 0.815357 00 00 00 00 00 00 00 f0 00 f0 00 00 00 f0 00 00 00 00 00 00 00 00 f0 00 00 0.815475 00 00 00 00 00 00 51 00 00 51 00 00 00 00 00 00 00 00 00 f0 00 00 00 00 00 0.815561 00 00 00 00 00 00 00 f0 18 3b ab 01 0.815611 get_answer: block_number = 1 0.815673 get_answer: data length = 121 0.815721 get_answer: sequence number (1) is ok 0.815777 get_answer: checksum is ok 0.815852 get_answer: block_number = 1 0.815915 get_answer: data length = 0 0.815975 Communications with UPS lost: get_answer: not the right sequence received 0!!! ... (then the driver tries a few more times to repeat the operation, but it fails the same way, and then about by timeout) It seems that for some reason the call to usb_interrupt_read() function is able only to 'nibble' 8 bytes at a time, not an issue, since I've modified the loop to be able to receive as many frames as needed. but the condition to continue receiving is not suitable for your case. instead of receiving the whole 171 bytes transfer in one single gulp. thus, the data of the 2nd sequence is missing (after 3b ab 01): 28 82 c0 01 00 02 00 00 80 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 80 40 00 00 00 00 00 00 03 00 08 16 00 00 00 0b 00 6b Looking at dmesg, I see that on RPi the USB is handled by dwc_otg driver, instead of the usual ohci_hcd, and on RPi forums they noticed that there is some issue with it, like... that dwc_otg generates on idle 8000 interrupts per second! I'm not too expert on USB things, but I wonder if that may affect the communication with the UPS. it will not help, but should not be a big issue for us. would you be able to compile code for testing patches? you will then just need to replace the driver on the RPi. cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110
On Fri, Aug 10, 2012 at 12:22 PM, Arnaud Quette aquette@gmail.com wrote: Hi Massimo and Greg, Hello Arnaud, instead of receiving the whole 171 bytes transfer in one single gulp. thus, the data of the 2nd sequence is missing (after 3b ab 01): 28 82 c0 01 00 02 00 00 80 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 80 40 00 00 00 00 00 00 03 00 08 16 00 00 00 0b 00 6b Exactly. would you be able to compile code for testing patches? you will then just need to replace the driver on the RPi. Yes I can do that. Actually I was already able to compile on the RPi the just-released 2.6.5 (although I did notice there was no change in bcmxcp_usb code). Obviously no improvement regarding this specific issue. Cheers, Massimo ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] problem_connection_NUT_infosec
On Aug 9, 2012, at 4:57 AM, jgoupil wrote: My Infosec's UPS is not in the list of supported UPS but the driver is the same than megatec's driver (This is the same factory with some differences...) So, here are my configurations : -- Ubuntu Desktop -- apt-get install nut OK UPS connected to ubuntu via USB cable After connecting my UPS, a new line appears in lsusb : Bus 001 Device 004: ID 0665:5161 Cypress Semiconductor USB to serial Try the blazer_usb driver. If it works, please send us some additional information about the UPS so we can list it on the compatibility page. Details: http://www.networkupstools.org/stable-hcl.html#footnotes -- 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] UPS restart delay
On 10/08/2012, at 16:17, Arnaud Quette aquette@gmail.com wrote: Hmm, what parameter is it called on the LCD panel? Refer to the manual: http://pqtools.eaton.com/download/intl/products/comet-ex-rt/148-man_uk_08.pdf page 27, chapter 3, ON/OFF features = UPS ON/OFF by software the parameter I've added in NUT (ups.shutdown) is directly connected to the same data than the above LCD feature. OK thanks. I was on holiday when the UPS was tested and shipped so I didn't get a chance to try things myself. the danger of letting other do the work ;-) :) The fix is both attached (limited to the code) and committed to the trunk r3717: http://trac.networkupstools.org/projects/nut/changeset/3717 Once applied, check with upsc that ups.shutdown is set to enabled. Otherwise, use: # upsrw -u user -p password -s ups.shutdown=enabled device name You can then test it using upsmon -c fsd if you have protected loads, or simply with: # upscmd -u user -p password device name shutdown.return Can you please confirm back that the issue is closed on your side? I should be able to try it later on today, or tomorrow. I applied the patch however it seems it's already enabled, ie [dhcp-72114 13:22] ~/nut-2.6.4 upsc ups1@localhost | grep ups.shu ups.shutdown: enabled I set it anyway, and the test seems to have worked - the load now goes off soon after the PC shuts off and waits until the battery charges. Thanks! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C smime.p7s Description: S/MIME cryptographic signature ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS restart delay
2012/8/10 Daniel O'Connor docon...@gsoft.com.au On 10/08/2012, at 16:17, Arnaud Quette aquette@gmail.com wrote: Hmm, what parameter is it called on the LCD panel? Refer to the manual: http://pqtools.eaton.com/download/intl/products/comet-ex-rt/148-man_uk_08.pdf page 27, chapter 3, ON/OFF features = UPS ON/OFF by software the parameter I've added in NUT (ups.shutdown) is directly connected to the same data than the above LCD feature. OK thanks. I was on holiday when the UPS was tested and shipped so I didn't get a chance to try things myself. the danger of letting other do the work ;-) :) The fix is both attached (limited to the code) and committed to the trunk r3717: http://trac.networkupstools.org/projects/nut/changeset/3717 Once applied, check with upsc that ups.shutdown is set to enabled. Otherwise, use: # upsrw -u user -p password -s ups.shutdown=enabled device name You can then test it using upsmon -c fsd if you have protected loads, or simply with: # upscmd -u user -p password device name shutdown.return Can you please confirm back that the issue is closed on your side? I should be able to try it later on today, or tomorrow. I applied the patch however it seems it's already enabled, ie [dhcp-72114 13:22] ~/nut-2.6.4 upsc ups1@localhost | grep ups.shu ups.shutdown: enabled strange! I set it anyway, and the test seems to have worked - the load now goes off soon after the PC shuts off and waits until the battery charges. the result is there, but still strange. can somebody have accessed and modify it locally in the meantime? you may want to perform some more shutdown cycles, to be 100% sure! cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110
Hello Arnaud, thanks for the effort for the patch! I took most of this afternoon looking at this issue, and this should be fixed with the attached patch It applies fine on 2.6.5, using the following command: # cd nut-2.6.5 # patch -p0 /path/to/xcp-rcv-loop.diff # make I've tested it on a 5110 only currently, so it's not applied to the development tree. for testing purpose, I've also used a byte frame size, to be in your condition (Ie, set the 4th param of usb_interrupt_read() to '8'). please tell me back how it behave on RPi. note that I'll probably have to do some code adjustment, and obviously regression testing on other units, before committing the patch to the main source tree. I applied your patch to the 2.6.5 code and run only the bcmxcp_usb driver and... I'm not sure that everything is ok. If I run the driver as ./bcmxcp_usb -u root -a ups it launches, but after a second I get a Communications with UPS lost: get_answer: not the right sequence received 0!!!. However the driver seems still to keep running. I also tried to start the driver under debug (-). In attachment you can see the output (until I typed ctrl-c), that also include some some of the 'communication lost' messages. Cheers, Massimo bcmxcp_patched.txt.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] Zigor Ebro 650 compatibility
On 8 August 2012 10:07, Martyn Hill martyn.joseph.h...@gmail.com wrote: Arnaud Quette aquette.dev at gmail.com writes: 2012/6/3 Chris Rees crees at freebsd.org: Hi all, Hi Chris, After some research I've found that this device should run with the blazer_usb driver. Jun 3 16:15:38 pegasus kernel: ugen0.4: vendor 0x0001 at usbus0 Jun 3 16:15:38 pegasus kernel: uhid0: vendor 0x0001 product 0x, class 0/0, rev 1.00/1.00, addr 4 on usbus0 However, even after shoehorning it; [crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D -x vendorid=0x0001 -x productid=0x -x subdriver=krauler Password: Network UPS Tools - Megatec/Q1 protocol USB driver 0.04 (2.6.3-Unversioned directory) 0.00 send_to_all: SETINFO driver.parameter.vendorid 0x0001 0.13 send_to_all: SETINFO driver.parameter.productid 0x 0.18 send_to_all: SETINFO driver.parameter.subdriver krauler 0.20 debug level is '9' 0.000874 language ID workaround enabled (using '0x409') 0.001019 No appropriate HID device found 0.001025 No supported devices found. Please check your device availability with 'lsusb' and make sure you have an up-to-date version of NUT. If this does not help, try running the driver with at least 'subdriver', 'vendorid' and 'productid' options specified. Please refer to the man page for details about these options (man 8 blazer). This is on FreeBSD with NUT updated to 2.6.3 (I've modified the port). Hi Chris Any chance you could share the FreeBSD port? Using the version (2.6.1) currently available in the ports tree, I can get a step closer than your tests above, but without the enhanced blazer_usb driver (0.0.4) in nut 2.6.3, I don't think I can get any further. All you need to do is edit the PORTVERSION value in the Makefile, and run make makesum :) I've just successfully upgraded to 2.6.4 this way The UPS comes with UPSilon, but it's several years (!) old and I can't even get it to install, let alone work. Have I sent enough info? I'm willing to have a go at hacking the driver, but having trouble getting started. Chris [crees at pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb langid_fix = 0x409 desc = Zigor UPS vendorid = 0001 productid = it's quite probably due to a permission issue. See 4) Permissions on http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt Thanks Arnaud, and sorry for the delay-- I've been on holiday. As I mentioned above I've now got it to 2.6.4, and have a new message; [crees@pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 (2.6.4-Unversioned directory) 0.00 debug level is '13' 0.001081 Checking device (0001/) (/dev/usb//dev/ugen2.3) 0.001688 - VendorID: 0001 0.001694 - ProductID: 0.001697 - Manufacturer: unknown 0.001701 - Product: unknown 0.001705 - Serial Number: unknown 0.001708 - Bus: /dev/usb 0.001712 Trying to match device 0.001717 Device matches 0.001737 send_to_all: SETINFO ups.vendorid 0001 0.001744 send_to_all: SETINFO ups.productid 0.001751 send_to_all: SETINFO device.type ups 0.001758 send_to_all: SETINFO driver.version 2.6.4-Unversioned directory 0.001764 send_to_all: SETINFO driver.version.internal 0.08 0.001770 send_to_all: SETINFO driver.name blazer_usb 0.001775 Trying megatec protocol... 0.001786 send: Q1 0.002191 read: Unknown error 0.002242 Permissions problem: Input/output error [crees@pegasus]/usr/local/libexec/nut% I had already chmod'd 777 all the USB nodes (just for debugging of course!) and: [crees@pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb Looks as though the UPS is answering in strange ways Chris ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] How to set a UPS variable
queequeg says hi. :) I am trying to set a UPS variable, specifically outlet.1.delay.shutdown I've been all over the online docs. I have found the full listing of the various variables that I can set. I've read the page that says, . C. NUT command and variable naming scheme This is a dump of the standard variables and command names used in NUT. Dont use a name with any of the dstate functions unless it exists here. If you need a new variable or command name, contact the Development Team first. Put another way: if you make up a name thats not in this list and it gets into the tree, and then we come up with a better name later, clients that use the undocumented variable will break when it is changed. .. The question I have is, how do I set the outlet.1.delay.shutdown variable to the value I want? Am I missing something obvious in the docs? Does it go into one of the config files? Do I have to run a separate program? Thanks in advance. ___ 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
On 10 August 2012 18:08, Chris Rees cr...@freebsd.org wrote: On 8 August 2012 10:07, Martyn Hill martyn.joseph.h...@gmail.com wrote: Arnaud Quette aquette.dev at gmail.com writes: 2012/6/3 Chris Rees crees at freebsd.org: Hi all, Hi Chris, After some research I've found that this device should run with the blazer_usb driver. Jun 3 16:15:38 pegasus kernel: ugen0.4: vendor 0x0001 at usbus0 Jun 3 16:15:38 pegasus kernel: uhid0: vendor 0x0001 product 0x, class 0/0, rev 1.00/1.00, addr 4 on usbus0 However, even after shoehorning it; [crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D -x vendorid=0x0001 -x productid=0x -x subdriver=krauler Password: Network UPS Tools - Megatec/Q1 protocol USB driver 0.04 (2.6.3-Unversioned directory) 0.00 send_to_all: SETINFO driver.parameter.vendorid 0x0001 0.13 send_to_all: SETINFO driver.parameter.productid 0x 0.18 send_to_all: SETINFO driver.parameter.subdriver krauler 0.20 debug level is '9' 0.000874 language ID workaround enabled (using '0x409') 0.001019 No appropriate HID device found 0.001025 No supported devices found. Please check your device availability with 'lsusb' and make sure you have an up-to-date version of NUT. If this does not help, try running the driver with at least 'subdriver', 'vendorid' and 'productid' options specified. Please refer to the man page for details about these options (man 8 blazer). This is on FreeBSD with NUT updated to 2.6.3 (I've modified the port). Hi Chris Any chance you could share the FreeBSD port? Using the version (2.6.1) currently available in the ports tree, I can get a step closer than your tests above, but without the enhanced blazer_usb driver (0.0.4) in nut 2.6.3, I don't think I can get any further. All you need to do is edit the PORTVERSION value in the Makefile, and run make makesum :) I've just successfully upgraded to 2.6.4 this way The UPS comes with UPSilon, but it's several years (!) old and I can't even get it to install, let alone work. Have I sent enough info? I'm willing to have a go at hacking the driver, but having trouble getting started. Chris [crees at pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb langid_fix = 0x409 desc = Zigor UPS vendorid = 0001 productid = it's quite probably due to a permission issue. See 4) Permissions on http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt Thanks Arnaud, and sorry for the delay-- I've been on holiday. As I mentioned above I've now got it to 2.6.4, and have a new message; [crees@pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 (2.6.4-Unversioned directory) 0.00 debug level is '13' 0.001081 Checking device (0001/) (/dev/usb//dev/ugen2.3) 0.001688 - VendorID: 0001 0.001694 - ProductID: 0.001697 - Manufacturer: unknown 0.001701 - Product: unknown 0.001705 - Serial Number: unknown 0.001708 - Bus: /dev/usb 0.001712 Trying to match device 0.001717 Device matches 0.001737 send_to_all: SETINFO ups.vendorid 0001 0.001744 send_to_all: SETINFO ups.productid 0.001751 send_to_all: SETINFO device.type ups 0.001758 send_to_all: SETINFO driver.version 2.6.4-Unversioned directory 0.001764 send_to_all: SETINFO driver.version.internal 0.08 0.001770 send_to_all: SETINFO driver.name blazer_usb 0.001775 Trying megatec protocol... 0.001786 send: Q1 0.002191 read: Unknown error 0.002242 Permissions problem: Input/output error [crees@pegasus]/usr/local/libexec/nut% I had already chmod'd 777 all the USB nodes (just for debugging of course!) and: [crees@pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb Looks as though the UPS is answering in strange ways Just for fun, I noticed the #ifdef TESTING in blazer_usb.c. I defined that, and got this output when running ./blazer_usb -a zigor: http://www.bayofrum.net/~crees/scratch/zigor-testing.txt Any hints there? Chris ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110
Hi Massimo and Greg, @Greg: if you yet returned your unit, you now have a solution ;) thanks for the effort for the patch! welcome ;) I took most of this afternoon looking at this issue, and this should be fixed with the attached patch It applies fine on 2.6.5, using the following command: # cd nut-2.6.5 # patch -p0 /path/to/xcp-rcv-loop.diff # make I've tested it on a 5110 only currently, so it's not applied to the development tree. for testing purpose, I've also used a byte frame size, to be in your condition (Ie, set the 4th param of usb_interrupt_read() to '8'). please tell me back how it behave on RPi. note that I'll probably have to do some code adjustment, and obviously regression testing on other units, before committing the patch to the main source tree. I applied your patch to the 2.6.5 code and run only the bcmxcp_usb driver and... I'm not sure that everything is ok. sorry, I forgot to explicitly request the trace (debug level 5) to validate on my side... If I run the driver as ./bcmxcp_usb -u root -a ups it launches, but after a second I get a Communications with UPS lost: get_answer: not the right sequence received 0!!!. However the driver seems still to keep running. I also tried to start the driver under debug (-). In attachment you can see the output (until I typed ctrl-c), that also include some some of the 'communication lost' messages. the driver runs fine. you should get a good upsc output now. the Comm lost msg are part of code adjustments needed, but the code already handle this fine, and recovers (check entering get_answer(33) for example). could you please confirm this by sending the upsc output, and starting upsmon to monitor on the RPi? cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ 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
On 10/08/2012 21:58, nut-upsuser-requ...@lists.alioth.debian.org wrote: Arnaud Quetteaquette.devat gmail.com writes: 2012/6/3 Chris Reescreesat freebsd.org: Hi all, Hi Chris, After some research I've found that this device should run with the blazer_usb driver. Jun 3 16:15:38 pegasus kernel: ugen0.4:vendor 0x0001 at usbus0 Jun 3 16:15:38 pegasus kernel: uhid0:vendor 0x0001 product 0x, class 0/0, rev 1.00/1.00, addr 4 on usbus0 However, even after shoehorning it; [creesat pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D -x vendorid=0x0001 -x productid=0x -x subdriver=krauler Password: Network UPS Tools - Megatec/Q1 protocol USB driver 0.04 (2.6.3-Unversioned directory) 0.00 send_to_all: SETINFO driver.parameter.vendorid 0x0001 0.13 send_to_all: SETINFO driver.parameter.productid 0x 0.18 send_to_all: SETINFO driver.parameter.subdriver krauler 0.20 debug level is '9' 0.000874 language ID workaround enabled (using '0x409') 0.001019 No appropriate HID device found 0.001025 No supported devices found. Please check your device availability with 'lsusb' and make sure you have an up-to-date version of NUT. If this does not help, try running the driver with at least 'subdriver', 'vendorid' and 'productid' options specified. Please refer to the man page for details about these options (man 8 blazer). This is on FreeBSD with NUT updated to 2.6.3 (I've modified the port). Hi Chris Any chance you could share the FreeBSD port? Using the version (2.6.1) currently available in the ports tree, I can get a step closer than your tests above, but without the enhanced blazer_usb driver (0.0.4) in nut 2.6.3, I don't think I can get any further. All you need to do is edit the PORTVERSION value in the Makefile, and run make makesum :) I've just successfully upgraded to 2.6.4 this way Aha! I also found a FreeBSD port patch on-line for 2.6.4 that has yet to be committed to the ports-tree. I'll try your route against the latest NUT release and see what we get. The UPS comes with UPSilon, but it's several years (!) old and I can't even get it to install, let alone work. Have I sent enough info? I'm willing to have a go at hacking the driver, but having trouble getting started. Chris [creesat pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb langid_fix = 0x409 desc = Zigor UPS vendorid = 0001 productid = it's quite probably due to a permission issue. See 4) Permissions on http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt Thanks Arnaud, and sorry for the delay-- I've been on holiday. As I mentioned above I've now got it to 2.6.4, and have a new message; [crees@pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 (2.6.4-Unversioned directory) 0.00 debug level is '13' 0.001081 Checking device (0001/) (/dev/usb//dev/ugen2.3) 0.001688 - VendorID: 0001 0.001694 - ProductID: 0.001697 - Manufacturer: unknown 0.001701 - Product: unknown 0.001705 - Serial Number: unknown 0.001708 - Bus: /dev/usb 0.001712 Trying to match device 0.001717 Device matches 0.001737 send_to_all: SETINFO ups.vendorid 0001 0.001744 send_to_all: SETINFO ups.productid 0.001751 send_to_all: SETINFO device.type ups 0.001758 send_to_all: SETINFO driver.version 2.6.4-Unversioned directory 0.001764 send_to_all: SETINFO driver.version.internal 0.08 0.001770 send_to_all: SETINFO driver.name blazer_usb 0.001775 Trying megatec protocol... 0.001786 send: Q1 0.002191 read: Unknown error 0.002242 Permissions problem: Input/output error [crees@pegasus]/usr/local/libexec/nut% I had already chmod'd 777 all the USB nodes (just for debugging of course!) and: [crees@pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb Looks as though the UPS is answering in strange ways I applied the 2.6.4 patch and recompiled and, after chown'ing the USB DEV nodes, got something very similar, effectively, the sequence: Trying megatec protocol... send: Q1 read: Unknown error Permissions problem: Input/output error I tried various protocol filters, but only the (new) megatec protocol gets this far... Just for fun, I noticed the #ifdef TESTING in blazer_usb.c. I defined that, and got this output when running ./blazer_usb -a zigor: http://www.bayofrum.net/~crees/scratch/zigor-testing.txt Any hints there? Chris Nice! I then installed the Upsilon s/w on my Windows XP laptop (which works effectively, even if it looks a bit 'old-school'..) I did take some comfort in seeing references to
Re: [Nut-upsuser] Zigor Ebro 650 compatibility
2012/8/10 Chris Rees cr...@freebsd.org On 8 August 2012 10:07, Martyn Hill martyn.joseph.h...@gmail.com wrote: Arnaud Quette aquette.dev at gmail.com writes: 2012/6/3 Chris Rees crees at freebsd.org: it's quite probably due to a permission issue. See 4) Permissions on http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt (...) Thanks Arnaud, and sorry for the delay-- I've been on holiday. no pb, I hope you enjoyed... mine are in a week from now ;) As I mentioned above I've now got it to 2.6.4, and have a new message; [crees@pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 (2.6.4-Unversioned directory) 0.00 debug level is '13' 0.001081 Checking device (0001/) (/dev/usb//dev/ugen2.3) 0.001688 - VendorID: 0001 0.001694 - ProductID: 0.001697 - Manufacturer: unknown 0.001701 - Product: unknown 0.001705 - Serial Number: unknown 0.001708 - Bus: /dev/usb 0.001712 Trying to match device 0.001717 Device matches 0.001737 send_to_all: SETINFO ups.vendorid 0001 0.001744 send_to_all: SETINFO ups.productid 0.001751 send_to_all: SETINFO device.type ups 0.001758 send_to_all: SETINFO driver.version 2.6.4-Unversioned directory 0.001764 send_to_all: SETINFO driver.version.internal 0.08 0.001770 send_to_all: SETINFO driver.name blazer_usb 0.001775 Trying megatec protocol... 0.001786 send: Q1 0.002191 read: Unknown error 0.002242 Permissions problem: Input/output error damn BSD USB stack. is it the new or the old (I may totally be off topic!) [crees@pegasus]/usr/local/libexec/nut% I had already chmod'd 777 all the USB nodes (just for debugging of course!) hem, ok, just for debugging purpose so ;) and: [crees@pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb Looks as though the UPS is answering in strange ways it's not answering at all for now! the I/O error is initial. you should try using export USB_DEBUG=3, which will enable libusb debug. I've just seen that Martin has sent more data... jumping on this mail. cheers, Arno ___ 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
2012/8/10 Martyn Hill martyn.joseph.h...@gmail.com On 10/08/2012 21:58, nut-upsuser-request@lists.**alioth.debian.orgnut-upsuser-requ...@lists.alioth.debian.orgwrote: Arnaud Quetteaquette.devat gmail.com writes: 2012/6/3 Chris Reescreesat freebsd.org: Hi all, Hi Chris, After some research I've found that this device should run with the blazer_usb driver. Jun 3 16:15:38 pegasus kernel: ugen0.4:vendor 0x0001 at usbus0 Jun 3 16:15:38 pegasus kernel: uhid0:vendor 0x0001 product 0x, class 0/0, rev 1.00/1.00, addr 4 on usbus0 However, even after shoehorning it; [creesat pegasus]/usr/local/libexec/**nut% sudo ./blazer_usb -a zigor -D -x vendorid=0x0001 -x productid=0x -x subdriver=krauler Password: Network UPS Tools - Megatec/Q1 protocol USB driver 0.04 (2.6.3-Unversioned directory) 0.00 send_to_all: SETINFO driver.parameter.vendorid 0x0001 0.13 send_to_all: SETINFO driver.parameter.productid 0x 0.18 send_to_all: SETINFO driver.parameter.subdriver krauler 0.20 debug level is '9' 0.000874 language ID workaround enabled (using '0x409') 0.001019 No appropriate HID device found 0.001025 No supported devices found. Please check your device availability with 'lsusb' and make sure you have an up-to-date version of NUT. If this does not help, try running the driver with at least 'subdriver', 'vendorid' and 'productid' options specified. Please refer to the man page for details about these options (man 8 blazer). This is on FreeBSD with NUT updated to 2.6.3 (I've modified the port). Hi Chris Any chance you could share the FreeBSD port? Using the version (2.6.1) currently available in the ports tree, I can get a step closer than your tests above, but without the enhanced blazer_usb driver (0.0.4) in nut 2.6.3, I don't think I can get any further. All you need to do is edit the PORTVERSION value in the Makefile, and run make makesum :) I've just successfully upgraded to 2.6.4 this way Aha! I also found a FreeBSD port patch on-line for 2.6.4 that has yet to be committed to the ports-tree. I'll try your route against the latest NUT release and see what we get. guys, I've released 2.6.5 yesterday! go the 2.6.5 route ;) The UPS comes with UPSilon, but it's several years (!) old and I can't even get it to install, let alone work. Have I sent enough info? I'm willing to have a go at hacking the driver, but having trouble getting started. Chris [creesat pegasus]/usr/local/libexec/**nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb langid_fix = 0x409 desc = Zigor UPS vendorid = 0001 productid = it's quite probably due to a permission issue. See 4) Permissions on http://people.freebsd.org/~**thierry/nut_FreeBSD_HowTo.txthttp://people.freebsd.org/%7Ethierry/nut_FreeBSD_HowTo.txt Thanks Arnaud, and sorry for the delay-- I've been on holiday. As I mentioned above I've now got it to 2.6.4, and have a new message; [crees@pegasus]/usr/local/**libexec/nut% sudo ./blazer_usb -a zigor -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 (2.6.4-Unversioned directory) 0.00 debug level is '13' 0.001081 Checking device (0001/) (/dev/usb//dev/ugen2.3) 0.001688 - VendorID: 0001 0.001694 - ProductID: 0.001697 - Manufacturer: unknown 0.001701 - Product: unknown 0.001705 - Serial Number: unknown 0.001708 - Bus: /dev/usb 0.001712 Trying to match device 0.001717 Device matches 0.001737 send_to_all: SETINFO ups.vendorid 0001 0.001744 send_to_all: SETINFO ups.productid 0.001751 send_to_all: SETINFO device.type ups 0.001758 send_to_all: SETINFO driver.version 2.6.4-Unversioned directory 0.001764 send_to_all: SETINFO driver.version.internal 0.08 0.001770 send_to_all: SETINFO driver.name blazer_usb 0.001775 Trying megatec protocol... 0.001786 send: Q1 0.002191 read: Unknown error 0.002242 Permissions problem: Input/output error [crees@pegasus]/usr/local/**libexec/nut% I had already chmod'd 777 all the USB nodes (just for debugging of course!) and: [crees@pegasus]/usr/local/**libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf [zigor] port = auto driver = blazer_usb Looks as though the UPS is answering in strange ways I applied the 2.6.4 patch and recompiled and, after chown'ing the USB DEV nodes, got something very similar, effectively, the sequence: Trying megatec protocol... send: Q1 read: Unknown error Permissions problem: Input/output error I tried various protocol filters, but only the (new) megatec protocol gets this far... Just for fun, I noticed the #ifdef TESTING in blazer_usb.c. I
Re: [Nut-upsuser] Zigor Ebro 650 compatibility
On 10/08/2012 22:34, Arnaud Quette wrote: Aha! I also found a FreeBSD port patch on-line for 2.6.4 that has yet to be committed to the ports-tree. I'll try your route against the latest NUT release and see what we get. guys, I've released 2.6.5 yesterday! go the 2.6.5 route ;) Yeah - saw that, but didn't see any specific changing referencing the blazer_usb driver, so haven't tried it yet... I applied the 2.6.4 patch and recompiled and, after chown'ing the USB DEV nodes, got something very similar, effectively, the sequence: Trying megatec protocol... send: Q1 read: Unknown error Permissions problem: Input/output error I tried various protocol filters, but only the (new) megatec protocol gets this far... Just for fun, I noticed the #ifdef TESTING in blazer_usb.c. I defined that, and got this output when running ./blazer_usb -a zigor: http://www.bayofrum.net/~crees/scratch/zigor-testing.txt http://www.bayofrum.net/%7Ecrees/scratch/zigor-testing.txt Any hints there? you've been fooled Chris. TESTING just fakes good values for... testing purpose ;) Nice! I then installed the Upsilon s/w on my Windows XP laptop (which works effectively, even if it looks a bit 'old-school'..) I did take some comfort in seeing references to 'Megatec(USB)' in the Upsilon software configuration... I ran USBSniff against the port whilst attaching the UPS. Unfortuately, I couldn't make much sense of the verbose USBSniff output, but if this is useful for debugging (for Arnaud?) I could share it. yup, there are not many people left out there, that speak Q1... could you please post a link, or a compressed archive (less than 40 Kb!)? Here's a 6KB rar file of a fresh SniffUSB log file, covering just the first minute after plugging-in the UPS to my XP laptop (UPSilon already running in Windows System tray). I've no idea what these 'URB' references are between sections, but around URB 60, I toggled the Beeper and then again around URB 65... Curiously, the documentation for the Zigor 650 states no Beeper toggle ability, but it does work... Hope that helps - more than happy to carry out further tests and record the output, if of any use to you... M. -- 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
Re: [Nut-upsuser] Zigor Ebro 650 compatibility
WITH attachment, this time... :-) On 10/08/2012 22:54, Martyn Hill wrote: On 10/08/2012 22:34, Arnaud Quette wrote: Aha! I also found a FreeBSD port patch on-line for 2.6.4 that has yet to be committed to the ports-tree. I'll try your route against the latest NUT release and see what we get. guys, I've released 2.6.5 yesterday! go the 2.6.5 route ;) Yeah - saw that, but didn't see any specific changing referencing the blazer_usb driver, so haven't tried it yet... I applied the 2.6.4 patch and recompiled and, after chown'ing the USB DEV nodes, got something very similar, effectively, the sequence: Trying megatec protocol... send: Q1 read: Unknown error Permissions problem: Input/output error I tried various protocol filters, but only the (new) megatec protocol gets this far... Just for fun, I noticed the #ifdef TESTING in blazer_usb.c. I defined that, and got this output when running ./blazer_usb -a zigor: http://www.bayofrum.net/~crees/scratch/zigor-testing.txt http://www.bayofrum.net/%7Ecrees/scratch/zigor-testing.txt Any hints there? you've been fooled Chris. TESTING just fakes good values for... testing purpose ;) Nice! I then installed the Upsilon s/w on my Windows XP laptop (which works effectively, even if it looks a bit 'old-school'..) I did take some comfort in seeing references to 'Megatec(USB)' in the Upsilon software configuration... I ran USBSniff against the port whilst attaching the UPS. Unfortuately, I couldn't make much sense of the verbose USBSniff output, but if this is useful for debugging (for Arnaud?) I could share it. yup, there are not many people left out there, that speak Q1... could you please post a link, or a compressed archive (less than 40 Kb!)? Here's a 6KB rar file of a fresh SniffUSB log file, covering just the first minute after plugging-in the UPS to my XP laptop (UPSilon already running in Windows System tray). I've no idea what these 'URB' references are between sections, but around URB 60, I toggled the Beeper and then again around URB 65... Curiously, the documentation for the Zigor 650 states no Beeper toggle ability, but it does work... Hope that helps - more than happy to carry out further tests and record the output, if of any use to you... M. -- There are 10 types of people in this world. Those who understand binary and those who don't. -- There are 10 types of people in this world. Those who understand binary and those who don't. UsbSnoop_20120809_2245.rar Description: Binary 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] Zigor Ebro 650 compatibility
On 10/08/2012 23:00, Martyn Hill wrote: WITH attachment, this time... :-) On 10/08/2012 22:54, Martyn Hill wrote: On 10/08/2012 22:34, Arnaud Quette wrote: Aha! I also found a FreeBSD port patch on-line for 2.6.4 that has yet to be committed to the ports-tree. I'll try your route against the latest NUT release and see what we get. guys, I've released 2.6.5 yesterday! go the 2.6.5 route ;) Yeah - saw that, but didn't see any specific changing referencing the blazer_usb driver, so haven't tried it yet... Just to add.. Just updated the FreeBSD port to 2.6.5 (using Chris's simple PORTVERSION/makesum instructions - thanks, Chris - the more I work with FreeBSD and ports, the more I love it...) Same result as with 2.6.4 and blazer 0.08 (now 0.09)... Better go to bed and leave it to the experts for now... Let me know how I can help next... -- 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
Re: [Nut-upsuser] UPS restart delay
On 11/08/2012, at 24:54, Arnaud Quette aquette@gmail.com wrote: I applied the patch however it seems it's already enabled, ie [dhcp-72114 13:22] ~/nut-2.6.4 upsc ups1@localhost | grep ups.shu ups.shutdown: enabled strange! Yeah :( I set it anyway, and the test seems to have worked - the load now goes off soon after the PC shuts off and waits until the battery charges. the result is there, but still strange. can somebody have accessed and modify it locally in the meantime? you may want to perform some more shutdown cycles, to be 100% sure! I'll see if the guy doing the installation can run another test. Have a good holiday :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C smime.p7s Description: S/MIME cryptographic signature ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
