Re: [Nut-upsuser] FreeBSD backed with a PR1500LCDRT2U

2015-09-25 Thread Louis G. 
> 
>> usbconfig -u 4 -a 2 dump_curr_config_desc 
> 
> Here is output of the command. Thank you for your help with this. 
> 
> ugen4.2:  at usbus4, cfg=0 md=HOST spd=LOW 
> (1.5Mbps) pwr=ON (50mA) 
> 
[...] 
> bLength = 0x09 
> bDescriptorType = 0x21 
> bDescriptorSubType = 0x10 
>> RAW dump: 
>> 0x00 | 0x09, 0x21, 0x10, 0x01, 0x21, 0x01, 0x22, 0x90, 
>> 0x08 | 0x02 
>
> This looks reasonable. 
>
> What about this? 
>
> usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100 
>
> One thing I noticed about the report descriptor that NUT returned: it has 
> extra zero bytes. 
>
> For instance, these lines: 
>
> 0.157417 Report Descriptor: (656 bytes) => 05 00 84 00 09 00 04 00 a1 00 01 
> 00 09 00 
> 0.157431 24 00 a1 00 00 00 85 00 01 00 09 00 fe 00 75 00 08 00 95 00 01 00 15 
> 00 00 
>
> would parse fairly normally if they read as follows: 
>
> 0.157417 Report Descriptor: (656 bytes) => 05 84 09 04 a1 01 09 
> 0.157431 24 a1 00 85 01 09 fe 75 08 95 01 15 00 

Here is the output from that command. Thank you for your help. 

usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100
REQUEST = <0x05 0x84 0x09 0x04 0xa1 0x01 0x09 0x24 0xa1 0x00 0x85 0x01 0x09 
0xfe 0x75 0x08 0x95 0x01 0x15 0x00 0x26 0xff 0x00 0xb1 0x22 0x85 0x02 0x09 0xff 
0xb1 0x22 0x85 0x03 0x05 0x85 0x09 0x8f 0xb1 0x22 0x85 0x04 0x09 0x89 0xb1 0x22 
0x85 0x05 0x09 0x8b 0xb1 0x22 0x85 0x06 0x09 0x2c 0xb1 0x22 0x85 0x07 0x75 0x08 
0x95 0x05 0x25 0x64 0x09 0x83 0x09 0x8d 0x09 0x8e 0x09 0x8c 0x09 0x67 0xb1 0x22 
0x95 0x01 0x25 0x41 0x15 0x14 0x09 0x29 0xb1 0x22 0x25 0x64 0x15 0x00 0x85 0x08 
0x75 0x08 0x65 0x00 0x09 0x66 0x81 0x22 0x09 0x66 0xb1 0xa2 0x09 0x68 0x75 0x10 
0x27 0xff 0xff 0x00 0x00 0x66 0x01 0x10 0x81 0x22 0x09 0x68 0xb1 0xa2 0x09 0x2a 
0x26 0x58 0x02 0x81 0x22 0x09 0x2a 0xb1 0xa2 0x85 0x09 0x75 0x10 0x27 0xff 0xff 
0x00 0x00 0x05 0x84 0x09 0x40 0x67 0x21 0xd1 0xf0 0x00 0x55 0x06 0xb1 0x22 0x85 
0x0a 0x09 0x30 0xb1 0xa2 0x65 0x00 0x55 0x00 0x09 0x02 0xa1 0x02 0x85 0x0b 0x75 
0x01 0x95 0x06 0x25 0x01 0x05 0x85 0x09 0xd0 0x09 0x44 0x09 0x45 0x09 0x42 0x09 
0x46 0x09 0x43 0x81 0x22 0x09 0xd0 0x09 0x
 44 0x09 0x45 0x09 0x42 0x09 0x46 0x09 0x43 0xb1 0xa2 0x75 0x02 0x95 0x01 0x81 
0x01 0xb1 0x01 0xc0 0x85 0x0c 0x05 0x84 0x09 0x5a 0x75 0x08 0x15 0x01 0x25 0x03 
0xb1 0xa2 0x85 0x0d 0x09 0xfd 0x15 0x00 0x26 0xff 0x00 0xb1 0x22 0xc0 0x05 0x84 
0x09 0x1a 0xa1 0x00 0x85 0x0e 0x05 0x84 0x09 0x40 
0x75><$u&","u%dg"%A)"%duef"fhu'f"h*"*u'@g!U"0eUu%DEBFC"DEBFCuZu%&"@u>

Joe Gzesh 
Sent from Zimbra Open Source Mail Server. Hosted at my House. 
Ask me how to set up your own Zimbra server.

- Original Message -
From: "Charles Lepple" 
To: "Joseph Gzesh" 
Cc: nut-upsuser@lists.alioth.debian.org
Sent: Thursday, September 24, 2015 10:59:12 PM
Subject: Re: [Nut-upsuser] FreeBSD backed with a PR1500LCDRT2U

On Sep 24, 2015, at 10:28 AM, Louis G.  wrote: 
> 
>> usbconfig -u 4 -a 2 dump_curr_config_desc 
> 
> Here is output of the command. Thank you for your help with this. 
> 
> ugen4.2:  at usbus4, cfg=0 md=HOST spd=LOW 
> (1.5Mbps) pwr=ON (50mA) 
> 
[...] 
> bLength = 0x09 
> bDescriptorType = 0x21 
> bDescriptorSubType = 0x10 
> RAW dump: 
> 0x00 | 0x09, 0x21, 0x10, 0x01, 0x21, 0x01, 0x22, 0x90, 
> 0x08 | 0x02 

This looks reasonable. 

What about this? 

usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100 

One thing I noticed about the report descriptor that NUT returned: it has extra 
zero bytes. 

For instance, these lines: 

0.157417 Report Descriptor: (656 bytes) => 05 00 84 00 09 00 04 00 a1 00 01 00 
09 00 
0.157431 24 00 a1 00 00 00 85 00 01 00 09 00 fe 00 75 00 08 00 95 00 01 00 15 
00 00 

would parse fairly normally if they read as follows: 

0.157417 Report Descriptor: (656 bytes) => 05 84 09 04 a1 01 09 
0.157431 24 a1 00 85 01 09 fe 75 08 95 01 15 00 

-- 
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] FreeBSD backed with a PR1500LCDRT2U

2015-09-25 Thread Charles Lepple 
On Sep 25, 2015, at 9:21 AM, Louis G.  wrote:
> 
> For what it is worth, I also have a Cyber Power CP900AVR laying around that I 
> can test with. 

That could certainly help narrow down whether it is a problem with the UPS or 
with the OS.

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

[Nut-upsuser] Incorrect values returned from usbhid-ups

2015-09-25 Thread Alan White 
I have the same issue of incorrect output voltage being reported by usbhid-ups, 
as run on NAS4Free (FreeBSD). UPS is as shown below. There is a thread on this 
list from 2014 that has these same issues, apparently never addressed by any of 
the later usbhid-ups releases. I’m using 2.7.3.

The value I am especially concerned with is the output voltage; if ANY thing 
should be right on the report, it’s that one! I would hate to have servers 
running at 137V if they are supposed to be running on 120V.

The output.voltage value of 137 reported is suspiciously near the 
input.transfer.high value. It has often been EQUAL to that. The good news is 
that the ACTUAL output volts as measured by a voltmeter is 120VAC.

In addition...
The device.serial and ups.serial are both all zeroes…
battery.mfr.date is “CPS” rather than a date string…
battery.voltage should indeed be higher than the nominal of 24.0 if they are 
being charged…

It appears that incorrect data structure elements as returned by the UPS are 
being used in this usbhid-upsdriver. Of course, it’s possible that CyberPower 
is providing incorrect values to your driver. They sicced me onto you folks as 
a driver issue, not a UPS issue. Aren’t we lucky...

THANKS for all your work! We out here in userland appreciate it!

battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1890
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 24.0
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CP1000PFCLCD
device.serial: 
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.3
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.39
input.transfer.high: 136
input.transfer.low: 88
input.voltage: 121.0
input.voltage.nominal: 120
output.voltage: 137.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 19
ups.mfr: CPS
ups.model: CP1000PFCLCD
ups.productid: 0501
ups.realpower.nominal: 600
ups.serial: 
ups.status: OL
ups.test.result: Done and passed
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764___
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/NUT with openSUSE 13.1

2015-09-25 Thread Rob Groner 

> -Original Message-
> From: Charles Lepple [mailto:clep...@gmail.com]
> Sent: Thursday, September 24, 2015 10:33 PM
> To: Tim Dawson 
> Cc: Rob Groner ; nut-upsuser Mailing List  upsu...@lists.alioth.debian.org>
> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
> 
> On Sep 24, 2015, at 12:20 PM, Tim Dawson  wrote:
> >
> > The "#! " is a *nix thing that exists in every *nix I have ever 
> > seen, for
> as long as I know (mid 1980's for me . . ) and is used to specify what shell 
> is to
> be loaded to run that script
> 
> More specifically, this dates back to when the first two bytes of an a.out-
> format executable file were the "magic" values used to determine how to
> load it. The ASCII code for "#!" does not match any of those magic values,
> and has the added benefit of being the start of a shell comment line.
> 

Ya, that's the part that I hate the most, and why up until now I considered it 
dispensibleit's a COMMENT.  Nowhere in software engineering should a 
comment actually affect the running of the program!  

That rant aside, I'm still not sure why this DOES affect the running.  I'm not 
trying any fancy shell scripting tricks.  I'm simply calling upsdrvctl.  It's a 
single line in the file, and I can't imagine that bash or csh or any other 
scripting calls it differently.  But *shrug*  that's just my ignorance talking.

Either way, SOMETHING is different now besides that because I wasn't able to 
get the systemd service unit to work before, and that has nothing to do with 
bash/shells.  I'm going to try again today from scratch and make sure I've got 
it working.


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] FreeBSD backed with a PR1500LCDRT2U

2015-09-25 Thread Charles Lepple 
On Sep 25, 2015, at 7:34 AM, Louis G.  wrote:
>> One thing I noticed about the report descriptor that NUT returned: it has 
>> extra zero bytes. 
>> 
>> For instance, these lines: 
>> 
>> 0.157417 Report Descriptor: (656 bytes) => 05 00 84 00 09 00 04 00 a1 00 01 
>> 00 09 00 
>> 0.157431 24 00 a1 00 00 00 85 00 01 00 09 00 fe 00 75 00 08 00 95 00 01 00 
>> 15 00 00 
>> 
>> would parse fairly normally if they read as follows: 
>> 
>> 0.157417 Report Descriptor: (656 bytes) => 05 84 09 04 a1 01 09 
>> 0.157431 24 a1 00 85 01 09 fe 75 08 95 01 15 00 
> 
> Here is the output from that command. Thank you for your help. 
> 
> usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100
> REQUEST = <0x05 0x84 0x09 0x04 0xa1 0x01 0x09 0x24 0xa1 0x00 0x85 0x01 0x09 
> 0xfe 0x75 0x08 0x95 0x01 0x15 0x00 
[...]

Yeah, for some reason, NUT is getting different descriptor data than usbconfig.

I don't see anything obvious in the FreeBSD source code, and I can't test the 
latest FreeBSD on my systems here (computers are in pieces in the basement). Is 
there a chance that there is something different with NAS4Free's USB stack? 
Where do they keep their source code repository?

Or can you test NUT with actual FreeBSD 10.2 system?

-- 
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] FreeBSD backed with a PR1500LCDRT2U

2015-09-25 Thread Louis G. 
Charles,

For what it is worth, I also have a Cyber Power CP900AVR laying around that I 
can test with. 

Joe Gzesh 
Sent from Zimbra Open Source Mail Server. Hosted at my House. 
Ask me how to set up your own Zimbra server.

- On Sep 25, 2015, at 7:34 AM, Joseph Gzesh lo...@frentzgzesh.info wrote:

>> 
>>> usbconfig -u 4 -a 2 dump_curr_config_desc
>> 
>> Here is output of the command. Thank you for your help with this.
>> 
>> ugen4.2:  at usbus4, cfg=0 md=HOST spd=LOW
>> (1.5Mbps) pwr=ON (50mA)
>> 
> [...]
>> bLength = 0x09
>> bDescriptorType = 0x21
>> bDescriptorSubType = 0x10
>>> RAW dump:
>>> 0x00 | 0x09, 0x21, 0x10, 0x01, 0x21, 0x01, 0x22, 0x90,
>>> 0x08 | 0x02
>>
>> This looks reasonable.
>>
>> What about this?
>>
>> usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100
>>
>> One thing I noticed about the report descriptor that NUT returned: it has 
>> extra
>> zero bytes.
>>
>> For instance, these lines:
>>
>> 0.157417 Report Descriptor: (656 bytes) => 05 00 84 00 09 00 04 00 a1 00 01 
>> 00
>> 09 00
>> 0.157431 24 00 a1 00 00 00 85 00 01 00 09 00 fe 00 75 00 08 00 95 00 01 00 
>> 15 00
>> 00
>>
>> would parse fairly normally if they read as follows:
>>
>> 0.157417 Report Descriptor: (656 bytes) => 05 84 09 04 a1 01 09
>> 0.157431 24 a1 00 85 01 09 fe 75 08 95 01 15 00
> 
> Here is the output from that command. Thank you for your help.
> 
> usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100
> REQUEST = <0x05 0x84 0x09 0x04 0xa1 0x01 0x09 0x24 0xa1 0x00 0x85 0x01 0x09 
> 0xfe
> 0x75 0x08 0x95 0x01 0x15 0x00 0x26 0xff 0x00 0xb1 0x22 0x85 0x02 0x09 0xff 
> 0xb1
> 0x22 0x85 0x03 0x05 0x85 0x09 0x8f 0xb1 0x22 0x85 0x04 0x09 0x89 0xb1 0x22 
> 0x85
> 0x05 0x09 0x8b 0xb1 0x22 0x85 0x06 0x09 0x2c 0xb1 0x22 0x85 0x07 0x75 0x08 
> 0x95
> 0x05 0x25 0x64 0x09 0x83 0x09 0x8d 0x09 0x8e 0x09 0x8c 0x09 0x67 0xb1 0x22 
> 0x95
> 0x01 0x25 0x41 0x15 0x14 0x09 0x29 0xb1 0x22 0x25 0x64 0x15 0x00 0x85 0x08 
> 0x75
> 0x08 0x65 0x00 0x09 0x66 0x81 0x22 0x09 0x66 0xb1 0xa2 0x09 0x68 0x75 0x10 
> 0x27
> 0xff 0xff 0x00 0x00 0x66 0x01 0x10 0x81 0x22 0x09 0x68 0xb1 0xa2 0x09 0x2a 
> 0x26
> 0x58 0x02 0x81 0x22 0x09 0x2a 0xb1 0xa2 0x85 0x09 0x75 0x10 0x27 0xff 0xff 
> 0x00
> 0x00 0x05 0x84 0x09 0x40 0x67 0x21 0xd1 0xf0 0x00 0x55 0x06 0xb1 0x22 0x85 
> 0x0a
> 0x09 0x30 0xb1 0xa2 0x65 0x00 0x55 0x00 0x09 0x02 0xa1 0x02 0x85 0x0b 0x75 
> 0x01
> 0x95 0x06 0x25 0x01 0x05 0x85 0x09 0xd0 0x09 0x44 0x09 0x45 0x09 0x42 0x09 
> 0x46
> 0x09 0x43 0x81 0x22 0x09 0xd0
>  0x09 0x44 0x09 0x45 0x09 0x42 0x09 0x46 0x09 0x43 0xb1 0xa2 0x75 0x02 0x95 
> 0x01
>  0x81 0x01 0xb1 0x01 0xc0 0x85 0x0c 0x05 0x84 0x09 0x5a 0x75 0x08 0x15 0x01 
> 0x25
>  0x03 0xb1 0xa2 0x85 0x0d 0x09 0xfd 0x15 0x00 0x26 0xff 0x00 0xb1 0x22 0xc0 
> 0x05
>  0x84 0x09 0x1a 0xa1 0x00 0x85 0x0e 0x05 0x84 0x09 0x40
>  0x75><$u&","u%dg"%A)"%duef"fhu'f"h*"*u'@g!U"0eUu%DEBFC"DEBFCuZu%&"@u>
> 
> Joe Gzesh
> Sent from Zimbra Open Source Mail Server. Hosted at my House.
> Ask me how to set up your own Zimbra server.
> 
> - Original Message -
> From: "Charles Lepple" 
> To: "Joseph Gzesh" 
> Cc: nut-upsuser@lists.alioth.debian.org
> Sent: Thursday, September 24, 2015 10:59:12 PM
> Subject: Re: [Nut-upsuser] FreeBSD backed with a PR1500LCDRT2U
> 
> On Sep 24, 2015, at 10:28 AM, Louis G.  wrote:
>> 
>>> usbconfig -u 4 -a 2 dump_curr_config_desc
>> 
>> Here is output of the command. Thank you for your help with this.
>> 
>> ugen4.2:  at usbus4, cfg=0 md=HOST spd=LOW
>> (1.5Mbps) pwr=ON (50mA)
>> 
> [...]
>> bLength = 0x09
>> bDescriptorType = 0x21
>> bDescriptorSubType = 0x10
>> RAW dump:
>> 0x00 | 0x09, 0x21, 0x10, 0x01, 0x21, 0x01, 0x22, 0x90,
>> 0x08 | 0x02
> 
> This looks reasonable.
> 
> What about this?
> 
> usbconfig -u 4 -a 2 do_request 0x81 0x06 0x2200 0 0x100
> 
> One thing I noticed about the report descriptor that NUT returned: it has 
> extra
> zero bytes.
> 
> For instance, these lines:
> 
> 0.157417 Report Descriptor: (656 bytes) => 05 00 84 00 09 00 04 00 a1 00 01 00
> 09 00
> 0.157431 24 00 a1 00 00 00 85 00 01 00 09 00 fe 00 75 00 08 00 95 00 01 00 15 
> 00
> 00
> 
> would parse fairly normally if they read as follows:
> 
> 0.157417 Report Descriptor: (656 bytes) => 05 84 09 04 a1 01 09
> 0.157431 24 a1 00 85 01 09 fe 75 08 95 01 15 00
> 
> --
> 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

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser