Re: [Nut-upsuser] Problems with Unitek Alpha 1000 Ps

2009-01-27 Thread Arjen de Korte 
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

2009-01-27 Thread Arjen de Korte 
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

2009-01-27 Thread Jordi Moreno 
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] FreeBSD usbhid-ups problem

2009-01-27 Thread Daniel O'Connor 
On Tuesday 27 January 2009 20:32:55 Arnaud Quette wrote:
> > I think that the '#ifdef SUN_LIBUSB' should change to "#ifndef linux" -
> > it seems logical to close it before potentially reopening it and it's a
> > Linux bug
> > that this can cause a problem (mitigated by the fact you seem to be able
> > to 'double open' :)
>
> thanks for this feedback. we can now broaden the above to non linux...
> I've just applied it for the upcoming 2.4.0...

Sounds good!

> I still get this every update..
>
> > USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> > temporarily unavailable
>
> this is for the notifications (aka interrupts, ie data sent by the UPS
> itself)
> if the control pipe work (for polling), that's fine for the moment.
> btw, which release of libusb are you using?

It is version 0.1.12, although the bsd code is patched.. The code in bsd.c 
doesn't look very savoury to my eye though (very poor error handling).

> > Also, I don't understand the underlying problem of the IO error when
> > reading, and the EBUSY the first time it tries to reconnect.
>
> I don't understand too. maybe a bug in ugen or libusb on FreeBSD?!
> EBUSY might be due to resources not freed quickly enough somewhere.
> the IO error itself has to do with ugen, and I've no clue there.

Yeah.. I suspect there is some impedance mismatch between the libusb API and 
FreeBSD's ugen interface..

There is a new USB stack going into FreeBSD although it won't be back ported 
so I guess there is reason to make the libusb code less ugly :)

> > usb_set_debug: Setting debugging level to 3 (on)
> > usb_os_find_busses: Found /dev/usb0
> > usb_os_find_busses: Found /dev/usb1
> > usb_os_find_busses: Found /dev/usb2
> > usb_os_find_busses: Found /dev/usb3
> > usb_os_find_busses: Found /dev/usb4
> > usb_os_find_devices: Found /dev/ugen0 on /dev/usb0
> > usb_control_msg: 128 6 512 0 0xbfbfd204 8 1000
> > usb_control_msg: 128 6 512 0 0x8105910 34 1000
>
> apart from the above, does the communication appears to be somehow stable
> in the time?

Yes, it does cause errors, but it recovers so it is usable.
It does detect when the power goes away although I haven't tried a full 
shutdown or anything yet.

-- 
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



signature.asc
Description: This is a digitally signed message part.
___
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

2009-01-27 Thread Jordi Moreno 
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] FreeBSD usbhid-ups problem

2009-01-27 Thread Arnaud Quette 
Hi Daniel,

2009/1/27 Daniel O'Connor 

> On Thursday 25 September 2008 17:56:43 Daniel O'Connor wrote:
> > > you might want to have libusb debug trace also, to see more low level
> > > things. use "export USB_DEBUG=3" before launching usbhid-ups.
> > > you might also have a look at your kernel output for ugen to see if
> > > there is a problem here.
> >
> > Hmm..
> > I get this..
> > usb_control_msg: 161 1 769 0 0x813310c 2 4000
> > USB error: error sending control message: Input/output error
> > Can't retrieve Report 1: Input/output error
> > upsdrv_updateinfo...
> > Got to reconnect!
> >
> > usb_set_debug: Setting debugging level to 3 (on)
> > usb_os_find_busses: Found /dev/usb0
> > usb_os_find_busses: Found /dev/usb1
> > usb_os_find_busses: Found /dev/usb2
> > usb_os_find_busses: Found /dev/usb3
> > usb_os_find_busses: Found /dev/usb4
> > usb_os_find_devices: couldn't open device /dev/ugen0: Device busy
> > No appropriate HID device found
> > upsdrv_updateinfo...
> > Got to reconnect!
> >
> > Sorry for the late reply.. :(
>
> I finally got off my arse and tried to fix this today.
>
> I found that enabling the libusb_close (as for Sun) in drivers/libusb.c
> helps
> - it can now reconnect.
>
> I think that the '#ifdef SUN_LIBUSB' should change to "#ifndef linux" - it
> seems logical to close it before potentially reopening it and it's a Linux
> bug
> that this can cause a problem (mitigated by the fact you seem to be able to
> 'double open' :)
>

thanks for this feedback. we can now broaden the above to non linux...
I've just applied it for the upcoming 2.4.0...

I still get this every update..
> USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> temporarily unavailable
>

this is for the notifications (aka interrupts, ie data sent by the UPS
itself)
if the control pipe work (for polling), that's fine for the moment.
btw, which release of libusb are you using?

Also, I don't understand the underlying problem of the IO error when
> reading, and the EBUSY the first time it tries to reconnect.
>

I don't understand too. maybe a bug in ugen or libusb on FreeBSD?!
EBUSY might be due to resources not freed quickly enough somewhere.
the IO error itself has to do with ugen, and I've no clue there.

upsdrv_updateinfo...
> USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> temporarily unavailable
> Got -35 HID objects...
> Quick update...
> Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID:
> 0x01, Offset: 0, Size: 1, Value: 1.00
> Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID:
> 0x01, Offset: 2, Size: 1, Value: 0.00
> Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID:
> 0x01, Offset: 1, Size: 1, Value: 1.00
> Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type:
> Feature, ReportID: 0x01, Offset: 3, Size: 1, Value:
> 0.00
> upsdrv_updateinfo...
> USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> temporarily unavailable
> Got -35 HID objects...
> Quick update...
> usb_control_msg: 161 1 769 0 0x8130100 2 4000
> USB error: error sending control message: Input/output error
> Can't retrieve Report 1: Input/output error
> upsdrv_updateinfo...
> Got to reconnect!
>
> usb_set_debug: Setting debugging level to 3 (on)
> usb_os_find_busses: Found /dev/usb0
> usb_os_find_busses: Found /dev/usb1
> usb_os_find_busses: Found /dev/usb2
> usb_os_find_busses: Found /dev/usb3
> usb_os_find_busses: Found /dev/usb4
> usb_os_find_devices: couldn't open device /dev/ugen0: Device busy
> usb_os_close: closing endpoint 5
> No appropriate HID device found
> upsdrv_updateinfo...
> Got to reconnect!
>
> usb_set_debug: Setting debugging level to 3 (on)
> usb_os_find_busses: Found /dev/usb0
> usb_os_find_busses: Found /dev/usb1
> usb_os_find_busses: Found /dev/usb2
> usb_os_find_busses: Found /dev/usb3
> usb_os_find_busses: Found /dev/usb4
> usb_os_find_devices: Found /dev/ugen0 on /dev/usb0
> usb_control_msg: 128 6 512 0 0xbfbfd204 8 1000
> usb_control_msg: 128 6 512 0 0x8105910 34 1000
>

apart from the above, does the communication appears to be somehow stable in
the time?

Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer -
http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser