Nut upsuser - May 2006 - MGE Pulsar Extreme communication problems

Hi,
I am trying to talk to an MGE Pulsar Extreme UPS over RS232 with the 
mge-shut driver but I'm having some problems.

It appears to init OK but I can't, say, turn the outlets off, eg..
harrow:~>upsc mge@localhost
battery.charge: 78
battery.charge.low: 20
battery.runtime: 05760
driver.name: mge-shut
driver.parameter.port: /dev/cuad1
driver.version: 2.0.3
driver.version.internal: 0.65
input.frequency: 50
input.voltage: 237
outlet.0.desc: Main Outlet
outlet.0.id: 0
outlet.0.switchable: 0
outlet.1.autoswitch.charge.low: 0
outlet.1.delay.shutdown: -1
outlet.1.delay.start: -1
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 1
outlet.1.switch: 1
outlet.1.switchable: 1
outlet.2.autoswitch.charge.low: 0
outlet.2.delay.shutdown: -1
outlet.2.delay.start: -1
outlet.2.desc: PowerShare Outlet 2
outlet.2.id: 2
outlet.2.switch: 1
outlet.2.switchable: 1
output.frequency: 50
output.voltage: 231
output.voltage.target.battery: 48
output.voltage.target.line: 48
ups.delay.shutdown: -1
ups.delay.start: -1
ups.load: 26
ups.mfr: MGE UPS SYSTEMS
ups.power.nominal: 1500
ups.serial: 885F50007
ups.status: OL CHRG
ups.test.result: No test initiated

However...
harrow:/usr/local/etc/nut>upsrw -u admin -p password -s outlet.1.switch=0 
mge@localhost
harrow:/usr/local/etc/nut>upsrw -u admin -p password -s outlet.2.switch=0 
mge@localhost
harrow:/usr/local/etc/nut>upsc mge@localhost outlet.1.switch ; upsc 
mge@localhost outlet.2.switch
1
1

ie no change.
Also, trying to set, say ups.delay.shutdown works unreliably - I can set it
but I usually either have to wait a bit or repeat the command a few times.

I've tried USB comms but it comes up with a small subset of status..
(I see a lot of IO errors scroll by in debug mode)

I tried setting pollinterval=20 in ups.conf (in the mge section) but no
change.

I have sniffed the RS232 traffic using watch & hexdump and it seems to be
a fairly continuous stream of data.. Maybe the UPS can't keep up? I'm 
not seeing any buffer overflow type messages from my kernel so I think
the PC is OK.

Here is what it looks like starting up..
harrow:~>sudo /usr/local/libexec/nut/mge-shut -D -D -a mge
Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.65 (2.0.3)
debug level is '2'
entering upsdrv_initups()
entering shut_ups_start()

Communication with UPS established
entering shut_get_descriptor(n 21, 9)
shut_wait_ack(): ACK received
entering shut_get_descriptor(n 01, 18)
shut_wait_ack(): ACK received
Device Descriptor:
bLength:                0x12
bDescriptorType:                                        0x01
bcdUSB:                 0x0110
bDeviceClass:           0x00
bDeviceSubClass:                                        0x00
bDeviceProtocol:        0x00
bMaxPacketSize0:                                        0x08
idVendor:               0x0463
idProduct:              0xffff
bcdDevice:                                              0x0100
iManufacturer:          0x04
iProduct:                                               0x7c
iSerialNumber:          0x36
bNumConfigurations:     0x01

entering shut_get_descriptor(n 22, 1535)
shut_wait_ack(): ACK received
entering initinfo()

entering shut_identify_ups(0x0004, 0x007c)

shut_wait_ack(): ACK received
shut_wait_ack(): ACK received
] on /dev/cuad1 [885F50007
entering shut_get_report(id: 0c, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 34, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 0c, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 0d, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 16, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 17, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 2f, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 20, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 07, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 0a, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 0a, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 07, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 12, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
...

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20060516/853a5ab0/attachment.pgp

On Tuesday 16 May 2006 10:14, Daniel O'Connor wrote:
> I am trying to talk to an MGE Pulsar Extreme UPS over RS232 with the
> mge-shut driver but I'm having some problems.
..
Well I figured out my shutdown delay problem - setting it starts the shutdown 
process (this is different to the APC model which is what I have used in the 
past)

I still can't turn the outlets on and off though, the value doesn't
change
from 0 :( I have tried a few random numbers but no luck. Has anyone had this 
work? I've tested it using the Win32 software and it does switch so I at 
least know the hardware isn't broken :)

Also I think there is a bug in mge-shut.c - line 370 should read..
	if (!strcasecmp(cmdname, "test.battery.stop")) {

(ie cut and paste error)

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20060522/8dbaf374/attachment.pgp

2006/6/15, Daniel O'Connor
<doconnor@gsoft.com.au>:
> On Thursday 15 June 2006 18:40, Arnaud Quette wrote:
> > > Have you had a chance to look at this? We're getting pretty
close to ship
> > > date so I won't be able to test it after much longer.
> >
> > yes, I'm currently modifying some things on the Development tree.
> > outlet.X.switch doesn't work as expected, but you can have the
same
> > result by using outlet.x.delay.{shutdown,start), ie:
> > - the equivalent to load.off on outlet.1 is:
> > upsrw -u user -p password -s outlet.x.delay.shutdown=0 ups@host
> >
> > the same goes for load.on on outlet.1:
> > upsrw -u user -p password -s outlet.x.delay.start=0 ups@host
> >
> > I'll add new commands (ie outlet.X.load.{on,off}), but I don't
think
> > I'll backport it for 2.0.4. While waiting, you have the above
solution
>
> That is fine - the independent port switching is just gravy :)
>
> > > kiruna# /usr/local/libexec/nut/newhidups -k -u nutmon -D -D
> > >  ...
> >
> > a bit hard to check this line, with all the html noise.
> > can you send it back for validation.
>
> Hmm strange, it's just a text attachment... I generated it using
script.
>
> I've trimmed off the control characters and re-attached it.
>
> > > Shutoff command failed (setting ondelay)
> > > Shutdown failed.
> > > kiruna# ^D=08=08exit
> >
> > I've tried with several EXtreme 700C and 1000C (no 1500
underhand), on
> > Linux and everything works as expected. Note that both using inline
> > {off,on}delay (using "-x offdelay...") and config file
parameters
> > works.
>
> Hmm, could be a Linux vs FreeBSD USB problem :(
possible, I'm not sure for the moment.
what is sure that the problem comes from the fbsd usb stack or
possibly from libusb for bsd...
> > Here are several things to validate:
> > - are you sure about the ups.conf file used (ie configured in
> > /etc/nut, but using /usr/local/ups/etc...)?
>
> It is definitely using /usr/local/etc
> (I have no NUT config in /etc)
>
> > - are the device right ok (rw) for nutmon?
>
> Yes, I have chown'd /dev/ugen0* to the nutmon user.
>
> > - a good test is to try:
> > "newhidups -u root -DDD -x offdelay=90 -x ondelay=120 -k
auto"
> > after having done "export USB_DEBUG=3"
> > and then send me back the log excerpt (starting at "Initiating
UPS
> > shutdown")
>
> ...
> Initiating UPS shutdown
> entering setvar(ups.delay.start, 120)
>
> entering string_to_path()
> Looking up UPS
> Looking up PowerSummary
> Looking up DelayBeforeStartup
> usb_control_msg: 161 1 791 0 0x514f34 8 4000
> Report : (8 bytes) => 17 FF FF FF CB 1F 51 0A
> =>> SET: Before set: -10.00 (120)
> =>> SET: after exp: 12/12.00 (exp = 0.10)
> PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = -1
> =>> SET: after PL: 12
> ==> Report after setvalue: (8 bytes) => 17 0C 00 00 CB 1F 51 0A
>
> usb_control_msg: 33 9 791 0 0x514f34 8 4000
> USB error: error sending control message: Input/output error
       ^^^^^^^^^^^
the problem is here. But I don't know why we get an I/O error...
the USB data is fine and the HID report data seems too, so the problem
is deeper.

Another test: while having newhidups running in debug mode, call upsrw
to set ups.delay.start to 120, and check if the I/O error has been
reproduced. I don't have much to say for the moment, but after a good
night, I might be back with more... You should also contact bsd
hackers to see if there is something known, or other ideas.

finally, what are you bsd and libusb versions?

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/