Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Arjen de Korte escribió: > > Upgrade to nut-2.4.0 where this has been fixed. We used to expect a > timeout after sending the shutdown.return command, but in case a USB > interface is used, we should look for an error instead. This has been > corrected. > Ok, I fixed my autoconf/automake installation and I tried SVN version... now it works like a charm! > >> This seems to work ok for now... but I need >> that the UPS turns on the load again when the line comes back, and it >> doesn't happen as expected... line comes back but the UPS won't turn >> on... > > That's outside of our control. After sending 'S01R0003' to the UPS, it > should switch off in one minute (S01) and switch back on after three > minutes (R0003). If the line power is still gone at the time the restart > timer elapsed, the UPS will wait until the power returns. > Well, I tried but this UPS doesn't seem to handle well this situation. It won't turn on when the line comes back... Before buying this UPS, I had a little MGE, and I remember I had to set a value on it with the W**dows control program in order for it to turn on when the line is up again... Winpower doesn't offer this feature, and trying to set some other values in the UPS (like beeper.toggle or test.battery.start) didn't work neither... it seems that this is a REALLY DUMB UPS... nevertheless, as I said before, everything else is working ok, so you can include this UPS (Unitek ALPHA 1000 Ps) in the list of supported models... at least we have something! Thank you for all your help! :D ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno : > vendorid = 0665 > productid = 5161 > subdriver = phoenix Don't use this, unless this is really needed! It is redundant for this driver and you risk that if we ever change these, it will break your installation. These keywords should only be used to use devices that are not already supported by this driver out of the box. Yours is, so you shouldn't use them. [...] > It returns error messages, but it seems to do the job just ok... It > shuts down past 60 seconds and turns on again in 2 minutes. Upgrade to nut-2.4.0 where this has been fixed. We used to expect a timeout after sending the shutdown.return command, but in case a USB interface is used, we should look for an error instead. This has been corrected. > There's only > one little thing... in my config, when line goes down, nut launches a > script that initiates a shutdown sequence in a minute if the line don't > come back... just before shutting down the server (in rc.6), it sends a > shutdown command to the UPS. Via 'upsdrvctl shutdown' I presume? Note that this will call the driver with the same '-k' option as used during your previous debugging commands so if you want to see what is happening, use bin/blazer_usb -a unitek -u root -x ondelay=2 -k -DDD instead. > This seems to work ok for now... but I need > that the UPS turns on the load again when the line comes back, and it > doesn't happen as expected... line comes back but the UPS won't turn > on... That's outside of our control. After sending 'S01R0003' to the UPS, it should switch off in one minute (S01) and switch back on after three minutes (R0003). If the line power is still gone at the time the restart timer elapsed, the UPS will wait until the power returns. > I have read in the blazer man page about the shutdown.return > command... How can I make NUT to send this command instead of > shutdown.stayoff (as it seems to be sending). What value for ondelay > should I give in order to do this? It already uses the shutdown.return command (see the debug output), so you can't change that. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Arjen de Korte escribió: > Citeren Jordi Moreno : > >> chopito:/usr/local/ups# bin/blazer_usb -a unitek -u root -x >> vendorid=0665 -k -D > > Try > > bin/blazer_usb -a unitek -u root -x offdelay=60 -k -DDD > > instead. Your UPS may not understand an offdelay smaller than 60 seconds. > > Best regards, Arjen Ok, I modified my ups.conf as follows: [unitek] driver = blazer_usb port = auto offdelay = 60 vendorid = 0665 productid = 5161 subdriver = phoenix desc = "Unitek Alpha 1000 PS" And I tried: # bin/blazer_usb -a unitek -u root -k -x ondelay=2 -DDD ... Device does not match - skipping Checking device (0665/5161) (003/005) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches failed to claim USB device: could not claim interface 0: Device or resource busy detached kernel driver from USB device... Initiating UPS shutdown send: S01R0003 read: Resource temporarily unavailable blazer_command: Resource temporarily unavailable instcmd: command [shutdown.return] failed ... Checking device (0665/5161) (003/005) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches send: S01R0003 read: Resource temporarily unavailable blazer_command: Resource temporarily unavailable instcmd: command [shutdown.return] failed ... Checking device (0665/5161) (003/005) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches send: S01R0003 read: Resource temporarily unavailable blazer_command: Resource temporarily unavailable instcmd: command [shutdown.return] failed Shutdown failed after 3 retries! It returns error messages, but it seems to do the job just ok... It shuts down past 60 seconds and turns on again in 2 minutes. There's only one little thing... in my config, when line goes down, nut launches a script that initiates a shutdown sequence in a minute if the line don't come back... just before shutting down the server (in rc.6), it sends a shutdown command to the UPS. This seems to work ok for now... but I need that the UPS turns on the load again when the line comes back, and it doesn't happen as expected... line comes back but the UPS won't turn on... I have read in the blazer man page about the shutdown.return command... How can I make NUT to send this command instead of shutdown.stayoff (as it seems to be sending). What value for ondelay should I give in order to do this? Thank you folks for all your help, it is almost working perfectly thanks to your advice... ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno : > chopito:/usr/local/ups# bin/blazer_usb -a unitek -u root -x > vendorid=0665 -k -D Try bin/blazer_usb -a unitek -u root -x offdelay=60 -k -DDD instead. Your UPS may not understand an offdelay smaller than 60 seconds. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno : > Couldn't test SVN version. After downloading, autoreconf --install gives > me the following output: > > # autoreconf --install > aclocal: macro `NUT_OS_FUNCTIONS' required but not defined > aclocal: configure.in: 65: macro `AM_PROG_CC_C_O' not found in library > autoreconf: aclocal failed with exit status: 1 You probably don't have all the autoconf tools needed installed. I don't know how to fix this though. > Maybe I'm missing something... However, I've tried last testing version > (2.4.0-pre2), because it seems to include the same version of > blazer_usb.c, blazer.c and blazer.h (checked with diff). Indeed. That's a good alternative to running the SVN version, although it is a bit more difficult to get to any changes that I may need to commit to this driver based on your input. > At first, it seems to detect the UPS properly: > > # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 > > Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) > Supported UPS detected with megatec protocol > Vendor information read in 1 tries Good. Note that specifying vendorid and productid is useless without also specifying the subdriver that needs to be used. Since the driver already knows them, it is not needed to list these. > But if I try to send a shutdown command: > > # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 -k > Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) > Initiating UPS shutdown > instcmd: command [shutdown.return] failed > instcmd: command [shutdown.return] failed > instcmd: command [shutdown.return] failed That could be due to an unsupported ondelay and/or offdelay value. Try if different values help here. It could also be that your UPS responds with an unsupported return value. You may wish to run the driver as follows to debug this bin/blazer_usb -DDD -a unitek -x ondelay=3 -x offdelay=60 -k This will make the driver run the shutdown command only with enough debugging info to see what is happening. > And giving more debug information: > > # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 > -D > Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) > debug level is '5' > ... > Checking device (0665/5161) (003/003) > - VendorID: 0665 > - ProductID: 5161 > - Manufacturer: WayTech Development(S) > - Product: WayTech USB-RS232 Interface (V1.0) > Baud rate 2400bps > - Serial Number: unknown > - Bus: 003 > Trying to match device > Device matches > Trying megatec protocol... > send: Q1 > read: (218.0 216.0 187.0 000 49.9 13.6 24.0 1000 > send_to_all: SETINFO input.voltage "218.0" > send_to_all: SETINFO input.voltage.fault "216.0" > send_to_all: SETINFO output.voltage "187.0" > send_to_all: SETINFO ups.load "0" > send_to_all: SETINFO input.frequency "49.9" > send_to_all: SETINFO battery.voltage "13.60" > send_to_all: SETINFO ups.temperature "24.0" > send_to_all: SETINFO beeper.status "disabled" > send_to_all: SETINFO ups.type "offline / line interactive" > send_to_all: SETINFO ups.status "OL" > Status read in 1 tries Looks good. > Supported UPS detected with megatec protocol > send: F > read: #230.0 000 012.0 50.0 > send_to_all: SETINFO input.voltage.nominal "230" > send_to_all: SETINFO input.current.nominal "0.0" > send_to_all: SETINFO battery.packs "1" > send_to_all: SETINFO battery.voltage.nominal "12.0" > send_to_all: SETINFO input.frequency.nominal "50" > Ratings read in 1 tries Same here. > send: I > read: #UNITEK POWERSCU8UPEG V8.0 > send_to_all: SETINFO ups.mfg "UNITEK" > send_to_all: SETINFO ups.model "POWER" > send_to_all: SETINFO ups.firmware "SCU8UPEG" > Vendor information read in 1 tries I was already slightly worried about this. Your UPS has spaces in the manufacturer name, which is unexpected. It looks like I need to change this, to use fixed length values. [...] > And it seems to stand forever sending those Q1 commands... That's correct, that's what you get in debugging mode. > Well, it seems we've advanced somehow... at least I can read some values > from the UPS now. But I really need the shutdown command to work... > > By the way, trying to execute upsd: > > # /usr/local/ups/sbin/upsd > Network UPS Tools upsd 2.4.0-pre2 > listening on 127.0.0.1 port 3493 > Can't connect to UPS [unitek] (blazer_usb-unitek): No such file or directory You need to use 'upsdrvctl' to start the driver. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Jordi Moreno escribió: > > But if I try to send a shutdown command: > > # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 -k > Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) > Initiating UPS shutdown > instcmd: command [shutdown.return] failed > instcmd: command [shutdown.return] failed > instcmd: command [shutdown.return] failed > Replying to myself... I forgot to set debug level to the above command... maybe it could be helpful! chopito:/usr/local/ups# bin/blazer_usb -a unitek -u root -x vendorid=0665 -k -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) debug level is '5' ... Checking device (0665/5161) (003/003) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches failed to claim USB device: could not claim interface 0: Device or resource busy detached kernel driver from USB device... Initiating UPS shutdown send: S.5R0003 read: Resource temporarily unavailable blazer_command: Resource temporarily unavailable instcmd: command [shutdown.return] failed ... Checking device (0665/5161) (003/003) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches send: S.5R0003 read: Resource temporarily unavailable blazer_command: Resource temporarily unavailable instcmd: command [shutdown.return] failed ... Checking device (0665/5161) (003/003) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches send: S.5R0003 read: Resource temporarily unavailable blazer_command: Resource temporarily unavailable instcmd: command [shutdown.return] failed Shutdown failed after 3 retries! What are these "failed to claim USB device: could not claim interface 0: Device or resource busy" and "read: Resource temporarily unavailable" messages about? Maybe permission problems? I'm running blazer_usb as root... Another matter... the UPS beeped more or less five minutes after I executed that command! But it didn't changed its state... it shows "on line" forever! Thanks in advance... ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Arjen de Korte escribió: > Citeren Jordi Moreno : > >> I'm attaching usbsnoop.log.tgz. I've tried to keep the log as little >> as possible, only logging Winpower agent's start. >> >> I hope it will help... > > It does. This looks like a Q1/megatec protocol UPS, unlike what I > expected based on earlier megatec logs: > > out: 46 0d 4d 6f f1 cf 11 88 > F \r > in : 23 32 33 30 2e 30 20 30 30 30 20 30 31 32 2e 30 20 35 30 2e 30 0d > 00 00 > # 2 3 0 . 0 sp 0 0 0 sp 0 1 2 . 0 sp 5 0 . 0 \r > > out: 51 31 0d 6f f1 cf 11 88 > Q 1 \r > in : 28 32 31 36 2e 30 20 32 31 38 2e 30 20 32 31 31 2e 30 20 30 30 30 > 20 34 > ( 2 1 6 . 0 sp 2 1 8 . 0 sp 2 1 1 . 0 sp 0 0 0 sp 4 > 39 2e 39 20 31 33 2e 36 20 32 34 2e 30 20 30 30 30 30 31 30 30 30 > 0d 00 > 9 . 9 sp 1 3 . 6 sp 2 4 . 0 sp 0 0 0 0 1 0 0 0 \r > > So based on this log, I would have expected that the UPS would be > supported by the megatec_usb driver out of the box. Going back to your > first post, it looks like the megatec_usb driver only read the last 8 > bytes of the answer to the Q1\r command. The reason could be the > somewhat dodgy way of reading the reply from the interrupt report in > this driver. It really doesn't handle unexpected lengths correctly. > Could you try the latest bleeding edge version from the SVN trunk > instead? There is a new driver (blazer_usb) that deals with this better. > > Best regards, Arjen Hi all, Couldn't test SVN version. After downloading, autoreconf --install gives me the following output: # autoreconf --install aclocal: macro `NUT_OS_FUNCTIONS' required but not defined aclocal: configure.in: 65: macro `AM_PROG_CC_C_O' not found in library autoreconf: aclocal failed with exit status: 1 Maybe I'm missing something... However, I've tried last testing version (2.4.0-pre2), because it seems to include the same version of blazer_usb.c, blazer.c and blazer.h (checked with diff). At first, it seems to detect the UPS properly: # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) Supported UPS detected with megatec protocol Vendor information read in 1 tries But if I try to send a shutdown command: # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 -k Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) Initiating UPS shutdown instcmd: command [shutdown.return] failed instcmd: command [shutdown.return] failed instcmd: command [shutdown.return] failed And giving more debug information: # bin/blazer_usb -a unitek -u root -x vendorid=0665 -x productid=5161 -D Network UPS Tools - Megatec/Q1 protocol USB driver 0.02 (2.4.0-pre2) debug level is '5' ... Checking device (0665/5161) (003/003) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 003 Trying to match device Device matches Trying megatec protocol... send: Q1 read: (218.0 216.0 187.0 000 49.9 13.6 24.0 1000 send_to_all: SETINFO input.voltage "218.0" send_to_all: SETINFO input.voltage.fault "216.0" send_to_all: SETINFO output.voltage "187.0" send_to_all: SETINFO ups.load "0" send_to_all: SETINFO input.frequency "49.9" send_to_all: SETINFO battery.voltage "13.60" send_to_all: SETINFO ups.temperature "24.0" send_to_all: SETINFO beeper.status "disabled" send_to_all: SETINFO ups.type "offline / line interactive" send_to_all: SETINFO ups.status "OL" Status read in 1 tries Supported UPS detected with megatec protocol send: F read: #230.0 000 012.0 50.0 send_to_all: SETINFO input.voltage.nominal "230" send_to_all: SETINFO input.current.nominal "0.0" send_to_all: SETINFO battery.packs "1" send_to_all: SETINFO battery.voltage.nominal "12.0" send_to_all: SETINFO input.frequency.nominal "50" Ratings read in 1 tries send: I read: #UNITEK POWERSCU8UPEG V8.0 send_to_all: SETINFO ups.mfg "UNITEK" send_to_all: SETINFO ups.model "POWER" send_to_all: SETINFO ups.firmware "SCU8UPEG" Vendor information read in 1 tries send_to_all: SETINFO ups.delay.start "180" send_to_all: SETINFO ups.delay.shutdown "30" send_to_all: ADDCMD beeper.toggle send_to_all: ADDCMD load.off send_to_all: ADDCMD load.on send_to_all: ADDCMD shutdown.return send_to_all: ADDCMD shutdown.stayoff send_to_all: ADDCMD shutdown.stop send_to_all: ADDCMD test.battery.start send_to_all: ADDCMD test.battery.start.deep send_to_all: ADDCMD test.battery.start.quick send_to_all: ADDCMD test.battery.stop send_to_all: SETINFO ups.vendorid "0665" send_to_all: SETINFO ups.productid "5161" send: Q1 read: (222.0 224.0 189.0 000 49.9 13.6 24.0 1000 send_to_all: SETINFO input.voltage "222.0" send_to_all: SETINFO input.voltage.fault "224.0" send_to_all: SETINFO output.voltage "189.0" send_to_all: DATAOK dstate_init: sock /var/state/ups/blazer_usb-unitek open on fd 5 send_to_all: SETINFO
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno : > I'm attaching usbsnoop.log.tgz. I've tried to keep the log as little > as possible, only logging Winpower agent's start. > > I hope it will help... It does. This looks like a Q1/megatec protocol UPS, unlike what I expected based on earlier megatec logs: out: 46 0d 4d 6f f1 cf 11 88 F \r in : 23 32 33 30 2e 30 20 30 30 30 20 30 31 32 2e 30 20 35 30 2e 30 0d 00 00 # 2 3 0 . 0 sp 0 0 0 sp 0 1 2 . 0 sp 5 0 . 0 \r out: 51 31 0d 6f f1 cf 11 88 Q 1 \r in : 28 32 31 36 2e 30 20 32 31 38 2e 30 20 32 31 31 2e 30 20 30 30 30 20 34 ( 2 1 6 . 0 sp 2 1 8 . 0 sp 2 1 1 . 0 sp 0 0 0 sp 4 39 2e 39 20 31 33 2e 36 20 32 34 2e 30 20 30 30 30 30 31 30 30 30 0d 00 9 . 9 sp 1 3 . 6 sp 2 4 . 0 sp 0 0 0 0 1 0 0 0 \r So based on this log, I would have expected that the UPS would be supported by the megatec_usb driver out of the box. Going back to your first post, it looks like the megatec_usb driver only read the last 8 bytes of the answer to the Q1\r command. The reason could be the somewhat dodgy way of reading the reply from the interrupt report in this driver. It really doesn't handle unexpected lengths correctly. Could you try the latest bleeding edge version from the SVN trunk instead? There is a new driver (blazer_usb) that deals with this better. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Hi all, I'm attaching usbsnoop.log.tgz. I've tried to keep the log as little as possible, only logging Winpower agent's start. I hope it will help... Thank you for all! --- Un saludo, Jordi Moreno CIM Internet, S.L. jmor...@cim.es Alexander I. Gordeev escribió: Hi Jordi, On Mon, Jan 26, 2009 at 11:55:42AM +0100, Jordi Moreno wrote: I've tried usbsnoop on a Windows machine, connected to the UPS. Software bundled with the UPS is WinPower, and it seems to work fine. The problem is that I don't know what to look for at the usbsnoop log, since there's too much information on it (running for five minutes, more or less, generated a 1MB log file!). I'm not a device driver developer but I would gladly help in anything I can. There's a version of WinPower for *nix, but unfortunately it won't work with an USB connection. Is there any way I can make the USB connection work as a serial one? Since the device detected is an USB-RS232 interface, I think it cold be an option... I've tried with usbserial with no success. If I could achieve this, WinPower would do the work while I investigate more... If not, I will need to buy another UPS... Please send the log to the list or privately (packed) or make it available to us in some other way. -- Alexander usbsnoop.log.tgz Description: application/compressed-tar ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Hi Jordi, On Mon, Jan 26, 2009 at 11:55:42AM +0100, Jordi Moreno wrote: > I've tried usbsnoop on a Windows machine, connected to the UPS. Software > bundled with the UPS is WinPower, and it seems to work fine. The problem > is that I don't know what to look for at the usbsnoop log, since there's > too much information on it (running for five minutes, more or less, > generated a 1MB log file!). I'm not a device driver developer but I > would gladly help in anything I can. > > There's a version of WinPower for *nix, but unfortunately it won't work > with an USB connection. Is there any way I can make the USB connection > work as a serial one? Since the device detected is an USB-RS232 > interface, I think it cold be an option... I've tried with usbserial > with no success. If I could achieve this, WinPower would do the work > while I investigate more... If not, I will need to buy another UPS... Please send the log to the list or privately (packed) or make it available to us in some other way. -- Alexander ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Arjen de Korte escribió: > Citeren Jordi Moreno : > >> Asking for UPS status [Q1]... >> get_data_agiler: raw dump: (0 bytes) => >> get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 >> Q1 => FAILED [short read] >> Q1 detail: (6 bytes) => 30 30 31 30 30 30 > > [...] > >> Megatec protocol UPS not detected. > > This UPS isn't speaking the Megatec protocol. It doesn't look like > anything familiar to me either. > >> Trying with usbhid-ups: > > It most certainly isn't a HID Power Device Class UPS, looking at the > length of the report descriptor, so this won't work either. > > [...] > >> So, can I try a different driver? Could be this UPS supported by NUT? I >> can give strace information too, but I don't want to make my mail >> longer! > > Strace is a waste of effort here. We're not debugging a timing problem > here, we just don't what protocol the UPS uses. If you have (bundled) > software available for Windows, you might use usbsnoop to try and see if > you can find out how to communicate with this device. Until then, there > is nothing we can do for you. > >> Sorry, but I'm a bit desperate... I have searched the web and >> didn't found any information about this UPS. > > You could also reverse this. If you really need your UPS to be supported > in NUT, buy something that is listed as 'supported' instead. If you're > looking to quickly resolve this, this might be the best advice we can > give you. Currently, you're lacking both the protocol information and a > driver to use it. Getting this supported may take a while. > > Best regards, Arjen Hi, I've tried usbsnoop on a Windows machine, connected to the UPS. Software bundled with the UPS is WinPower, and it seems to work fine. The problem is that I don't know what to look for at the usbsnoop log, since there's too much information on it (running for five minutes, more or less, generated a 1MB log file!). I'm not a device driver developer but I would gladly help in anything I can. There's a version of WinPower for *nix, but unfortunately it won't work with an USB connection. Is there any way I can make the USB connection work as a serial one? Since the device detected is an USB-RS232 interface, I think it cold be an option... I've tried with usbserial with no success. If I could achieve this, WinPower would do the work while I investigate more... If not, I will need to buy another UPS... Thank you very much for your help. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Citeren Jordi Moreno : > Asking for UPS status [Q1]... > get_data_agiler: raw dump: (0 bytes) => > get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 > Q1 => FAILED [short read] > Q1 detail: (6 bytes) => 30 30 31 30 30 30 [...] > Megatec protocol UPS not detected. This UPS isn't speaking the Megatec protocol. It doesn't look like anything familiar to me either. > Trying with usbhid-ups: It most certainly isn't a HID Power Device Class UPS, looking at the length of the report descriptor, so this won't work either. [...] > So, can I try a different driver? Could be this UPS supported by NUT? I > can give strace information too, but I don't want to make my mail > longer! Strace is a waste of effort here. We're not debugging a timing problem here, we just don't what protocol the UPS uses. If you have (bundled) software available for Windows, you might use usbsnoop to try and see if you can find out how to communicate with this device. Until then, there is nothing we can do for you. > Sorry, but I'm a bit desperate... I have searched the web and > didn't found any information about this UPS. You could also reverse this. If you really need your UPS to be supported in NUT, buy something that is listed as 'supported' instead. If you're looking to quickly resolve this, this might be the best advice we can give you. Currently, you're lacking both the protocol information and a driver to use it. Getting this supported may take a while. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Problems with Unitek Alpha 1000 Ps
Hello to all list members, I'm trying to make my UPS work with nut-2.2.2 (using Debian Testing, but compiled from source code) for a week ago, with not success. It's a Unitek Alpha 1000Ps, and I supossed it would work with megatec_usb driver, as other Unitek models. It has an USB interface, and when I plug it into my system I've got this message: chopito:/home/jordi# dmesg | tail -n4 input: WayTech Development(S) WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps as /class/input/input4 input: USB HID v1.00 Gamepad [WayTech Development(S) WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps] on usb-:00:1d.1-2 So, apparently, it has an USB-HID interface. Output from lsusb: chopito:/home/jordi# lsusb Bus 005 Device 001: ID : Bus 002 Device 004: ID 0665:5161 Bus 002 Device 001: ID : Bus 004 Device 001: ID : Bus 003 Device 001: ID : Bus 001 Device 001: ID : chopito:/home/jordi# lsusb -vvv -d 0665:5161 Bus 002 Device 004: ID 0665:5161 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0665 idProduct 0x5161 bcdDevice0.01 iManufacturer 1 WayTech Development(S) iProduct2 WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 3 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 4 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.00 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 35 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x (Bus Powered) When I try to make it work with megatec_usb, I get the following output: chopito:/usr/local/ups# bin/megatec_usb -D -a unitek -u root -x vendorid=0665 -x productid=5161 Network UPS Tools 2.2.2 - Megatec protocol driver 1.5.14 [megatec_usb] Carlos Rodrigues (c) 2003-2008 Serial-over-USB transport layer for Megatec protocol driver [megatec_usb] Andrey Lelikov (c) 2006, Alexander Gordeev (c) 2006-2007, Jon Gough (c) 2007 debug level is '5' Checking device (/) (005/001) - VendorID: - ProductID: - Manufacturer: Linux 2.6.22-2-686 ehci_hcd - Product: EHCI Host Controller - Serial Number: :00:1d.7 - Bus: 005 Trying to match device Device does not match - skipping Checking device (0665/5161) (002/005) - VendorID: 0665 - ProductID: 5161 - Manufacturer: WayTech Development(S) - Product: WayTech USB-RS232 Interface (V1.0) Baud rate 2400bps - Serial Number: unknown - Bus: 002 Trying to match device Device matches get_data_agiler: raw dump: (0 bytes) => Starting UPS detection process... Asking for UPS status [Q1]... get_data_agiler: raw dump: (0 bytes) => get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 Q1 => FAILED [short read] Q1 detail: (6 bytes) => 30 30 31 30 30 30 Asking for UPS status [Q1]... get_data_agiler: raw dump: (0 bytes) => get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 Q1 => FAILED [short read] Q1 detail: (6 bytes) => 30 30 31 30 30 30 Asking for UPS status [Q1]... get_data_agiler: raw dump: (0 bytes) => get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 Q1 => FAILED [short read] Q1 detail: (6 bytes) => 30 30 31 30 30 30 Asking for UPS status [Q1]... get_data_agiler: raw dump: (0 bytes) => get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 Q1 => FAILED [short read] Q1 detail: (6 bytes) => 30 30 31 30 30 30 Asking for UPS status [Q1]... get_data_agiler: raw dump: (0 bytes) => get_data_agiler: raw dump: (8 bytes) => 30 30 31 30 30 30 0d 00 Q1 => FAILED [short read] Q1 detail: (6
