Displaying 20 results from an estimated 4000 matches similar to: "bcmxcp in development tag."
2005 Oct 10
1
Bcmxcp backport.
Hi.
Have back-ported the bcmxcp and bcmxcp_usb driver from Development.
I hope it's done right.
Tested a clean cvs fetch after commit and it build and install ok.
Regards
Kjell
2011 Jan 14
2
Fwd: Question about Network UPS Tools bcmxcp driver
Hi,
Got this mail.
It looks like he has a ups with revision before K, and need another
startup. The 'PW_SET_REQ_ONLY_MODE' is not implemented,
so to make it work we have to follow the protocol and send
a 'PW_ID_BLOCK_REQ'. This in comsetup of bcmxcp_ser.c
Also the standard id block ends with 'Statistics Map', so we have to
Skip after reading the length of the 'Size
2013 Jul 03
1
bcmxcp: Patch for adding ups.load and battery.voltage.low
On Jul 2, 2013, at 5:16 PM, Kjell Claesson wrote:
>> I hope other people can also test this.
>>
>> Regards
>> Alf Hogemark
>
> Due to some crashes on the disks and lack of time I don't have the git on the
> pc now. But maybe some other can commit this.
I'd like to ask people to specifically try the bcmxcp branch on GitHub - it includes some changes
2013 Jul 02
0
bcmxcp: Patch for adding ups.load and battery.voltage.low
tisdagen den 2 juli 2013 20.24.47 skrev Alf H?gemark:
> Hi
>
Hi Alf,
> I have the following UPS :
> ups.mfr: Eaton
> ups.model: POWERWARE UPS 500i
> ups.power.nominal: 500
>
> It is using the bcmxcp_usb driver.
>
> I started the driver with debug options, and noticed the following for
> the meter map :
>
> 0.475625 0027 0000 51
2009 Dec 15
2
drivers/bcmxcp.c portability issue
I ran into a portability issue with drivers/bcmxcp.c in nut-2.4.1 on
my UnixWare 7.1.4 machine. The error I get is
.....
UX:acomp: ERROR: "/opt/src/utils/nut-2.4.1/drivers/bcmxcp.c", line 835: integral constant expression expected
.....
Looking at the code we see
.....
int init_outlet(unsigned char len)
{
unsigned char answer[len];
.....
Although gcc can handle it, it's not
2005 Nov 11
2
Powerware 9125 - bcmxcp - shutdown problem
Hi,
just through setting up nut-2.0.2 I ran into a shutdown problem. As I have
already spend some time on it and don't know any further, I like to ask for
advice.
Situation:
Powerware 9125 serially connected using /dev/cua0
nut compiled and installed fine
system shall
- broadcast a message and shut down if ups on battery for 30+ s
- wait 120 s
- broadcast another message
- give system 120
2009 May 21
1
Nut and PowerWare 5115
Hi Arnaud,
Any luck with the latest subversion trunk?
From: Greg
Sent: Wednesday, May 13, 2009 10:34 PM
To: Greg ; Arnaud Quette
Cc: Kjell Claesson ; nut-upsuser at lists.alioth.debian.org
Subject: Re: [Nut-upsuser] Nut and PowerWare 5115
Hi Arnaud,
Some more testing on Ubuntu 9.04.
Here is the output of bcmxcp_usb and lsusb
============================================
root at
2008 Jan 07
2
bcmxcp patch
Hi Michael,
I've forwarded your patch to Kjell, who's maintaining the bcmxcp
driver, and to the nut development list.
Kjell and others have more knowledges of the xcp protocol and will be
able to analyze your patch.
2008/1/4, michalwd1979 <michalwd1979 at o2.pl>:
> Hello Arnaud,
> I am sending You a small patch to bcmxcp.c and bcmxcp.h files from nut-2.2.0. I written this
2009 Aug 27
2
Serial comm errors with bcmxcp on HP R3000 XR
I have setup nut-2.4.1 with the bcmxcp driver for my HP R3000 XR unit
and although it appears to work, I receive the following sorts of errors
in syslog:
Aug 27 10:33:05 sv18 bcmxcp[6373]: Communications with UPS lost: Receive
error (data): got 0 bytes instead of 64!!!
Aug 27 10:33:15 sv18 bcmxcp[6373]: Communications with UPS lost: Receive
error (data): got 0 bytes instead of 64!!!
Aug 27
2013 Jul 02
2
bcmxcp: Patch for adding ups.load and battery.voltage.low
Hi
I have the following UPS :
ups.mfr: Eaton
ups.model: POWERWARE UPS 500i
ups.power.nominal: 500
It is using the bcmxcp_usb driver.
I started the driver with debug options, and noticed the following for
the meter map :
0.475625 0027 0000 51 output.frequency
0.475634 0028 0004 51 input.frequency
0.475641 0033 0008 51 battery.voltage
2005 Oct 09
3
bcmxcp - Powerware 9125
I'm currently testing the bcmxcp driver for NUT, and it causes me some
trouble. And when scanning the archives it seems like the 3110 USB problem
reported recently.
The bcmxcp daemon stops running, and the logs shows the following:
Oct 6 14:22:32 host.dom.tld bcmxcp[82628]: Communications with UPS lost:
Receive error (data): got -1 bytes instead of 28!!!
Oct 6 14:22:33 host.dom.tld
2007 May 23
1
[nut-commits] svn commit r915 - in trunk: . drivers
On 5/23/07, Kjell Claesson <keyson-guest at alioth.debian.org> wrote:
> Author: keyson-guest
> Date: Wed May 23 21:12:51 2007
> New Revision: 915
>
> Log:
> - Enabled requested Alarm function in bcmxcp.c
>
> Modified:
> trunk/ChangeLog
> trunk/drivers/bcmxcp.c
Looks like this breaks when HAL is enabled.
At the end of:
2009 Mar 23
1
[nut-commits] svn commit r1817 - in trunk: . data
Citeren Kjell Claesson <keyson-guest op alioth.debian.org>:
> Author: keyson-guest
> Date: Mon Mar 23 17:37:37 2009
> New Revision: 1817
>
> Log:
> data/driver.list, add Eaton Powerware 9130 compatibility with bcmxcp
> and usbhid-ups.
1) Is this really true? I would have expected that this device would
be supported through bcmxcp (serial) and bcmxcp_usb (USB), like
2005 Sep 23
11
trying to use powerware 3110 USB with NUT
Ok, I installed the ups, and installed nut, and /proc/bus/usb/devices says
this
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=06da ProdID=0002 Rev= 0.01
S: Manufacturer=POWERWARE
S: Product=Powerware UPS
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 20mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00
2007 Jul 10
1
[nut-commits] svn commit r1019 - in trunk: . drivers
Hi Kjell,
a few notes:
- you should bump the DRV_VERSION upon every change
- you should track the drivers TODO list in a comment header (such as
"implement smart load segment detection" completed with your info,
...). That would help to bootstrap new contributors.
- you can also use the alioth trackers (features request, or task) to
give some external visibility on what remains to be
2005 Nov 04
2
bcmxcp_usb / kernel 2.4.32-rc2
Hi,
I recently downgraded my kernel to 2.4 series (2.4.32-rc2). Now I can't
get nut running. It was fine with 2.6.14.
It say's:
---------------------
# ./bcmxcp_usb -uroot AUTO
Network UPS Tools - BCMXCP UPS driver 0.10 (2.1.0)
Can't reset POWERWARE USB endpoint
Unable to find POWERWARE UPS device on USB bus
...
---------------------
I've straced it in nut_usb.c
2010 Jul 01
1
HP R3000 XR (BCMXCP) serial connection problem: e7!!! and e2!!!
UPS: HP R3000 XR with HP UPS Management Module
What I Want:
I just want the UPS to shut down the client called "tor" before the UPS
power drains out, I'd prefer to use a direct serial cable instead of
network, in case the network doesn't work.
I'll manage the UPS trough the ethernet using the built-in HTTP
webinterface in the HP UPS Management Module.
I've created a
2007 Apr 17
1
HP R3000 XR, warning or perhaps error
Hi,
So far I've gleaned heaps of useful info from the list and got mostly
running with NUT. There was a thread by Paul Battaglia and Kjell
Claesson about the R3000 which has helped me get so far, but now with
the patched driver I still have this on startup:
# /usr/local/ups/bin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.0.5
Network UPS Tools - BCMXCP UPS driver 0.11
2013 Jun 29
0
upsrw doesn't set variable
On 6/29/2013 at 6:16 PM Kjell Claesson wrote:
|l??rdagen den 29 juni 2013 11.28.14 skrev Mike.:
|8<------------------snip---------------------
|Hi Mike,
|>
|> Thanks for the quick reply.
|>
|> I checked the log file (which, admittedly, I should have done before
I
|> posted about the problem :) ).
|>
|> Here's the command and the corresponding log message:
|>
2013 Jun 29
1
upsrw doesn't set variable
l?rdagen den 29 juni 2013 15.22.44 skrev Mike.:
8<-------------snip-----------------
Sorry for the delay.
> Here is the console output of bcmxcp with -DDD specified:
>
>
> [snip]
> 13.721204 Auto delay on: 2
>
> 13.721243 send_command: (4 bytes) => ab 01 35 1f
> 13.821127 send_command: (4 bytes) => ab 01 33 21
> 13.920982