Controlling recent APC UPS via USB - BSD

This is a discussion on Controlling recent APC UPS via USB - BSD ; I recently picked up an APC UPS unit on a whim. I figured even if I couldn't get the status from the unit via USB, at least I'd have something like 1.5 hrs of battery time to smooth over all ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Controlling recent APC UPS via USB

  1. Controlling recent APC UPS via USB

    I recently picked up an APC UPS unit on a whim. I figured even if I
    couldn't get the status from the unit via USB, at least I'd have
    something like 1.5 hrs of battery time to smooth over all brownouts and
    short blackouts I get all summer. I know I should have shopped around
    for a unit that has a traditional serial port, but there you have it.

    I was impressed that once I did plug the unit into an OpenBSD 4.1 (now
    4.2) box, I got a nice message with the exact model details telling me
    it was connected to /dev/ugen0 (only). It looks like later releases of
    OpenBSD are treating non-HID stuff like this smarter (thanks guys), so I
    was inspired to actually see if I could use the UPS smarter.

    This weekend I gave the two UPS server control software candidates a try
    with mixed success until this morning, where I finally got things to work.

    In a nutshell:

    - NUT is a wash-out. I can't figure out how to tell it to not use USB
    HID. Both the source and the old port/package had this problem.
    - apc-upsd from ports/packages is really old, and is not compiled with
    the USB driver. It also comes with minimal docs, and even the main
    apcupsd site no longer seems to host the docs from this old release.
    - The latest apcupsd from source looks like it is rarely tested against
    BSD USB, since there were some pretty basic compilation and linking
    errors. However, the BSD USB code is sound, and is able to talk to ugen
    devices without a problem.

    Short answer: I have successfully got an "APC Back-UPS XS 1300" talking
    BSD, with access to all functionality, including being able to invoke
    diagnostics and manipulate settings. I can see the UPS events go by in
    the log, though right now my event script is stubbed out. I assume that
    other similar units will also work.

    I figure I'd cook up my own apcupsd package from the latest source (with
    my patches so it builds on BSD), USB flavour, so I can update it easily
    in the future. I'm not sure I want to commit to supporting such a port
    myself, but I can make the (untested, obviously) package available once
    it is complete. After a weekend of Googling, I know I'm not the only
    one who has wanted a solution for the ubiquitous APC devices that are
    found in every big-box store.

    As an aside, the apcupsd tiprev via CVS does not agree with OpenBSD
    pthreads at all (and the config did not accept any contortions to not
    build with pthreads). Hopefully, this is addressed before CVS moves to
    stable.

    -- clvrmnky
    Replace "spamtrap" with my name to email me directly. Direct replies
    will result in a blacklisted server.

  2. Re: Controlling recent APC UPS via USB

    Begin
    On Mon, 28 Jan 2008 13:37:33 -0500,
    Clever Monkey wrote:
    [snip]
    > - The latest apcupsd from source looks like it is rarely tested against
    > BSD USB, since there were some pretty basic compilation and linking
    > errors. However, the BSD USB code is sound, and is able to talk to ugen
    > devices without a problem.


    A bit late, but: You could try and look at the port patches. If they
    don't apply to the newer version they at least might point at how to go
    about fixing things. I have, on occasion, successfully taken a newer
    tarball and applied the port's patches to it in a working directory.


    > I figure I'd cook up my own apcupsd package from the latest source (with
    > my patches so it builds on BSD), USB flavour, so I can update it easily
    > in the future. I'm not sure I want to commit to supporting such a port
    > myself, but I can make the (untested, obviously) package available once
    > it is complete.


    Well, you could try and submit your patches to the maintainer. It'd save
    him work, and doesn't commit you to maintaining the port.


    And of course the usual ``BSD'' is not equal to {Open,Net,Free,...}BSD
    nitpick. Even if you take it to mean the entire family, are you certain
    this'll work equally well on the others? It'd be nice, of course, but
    I'd not expect it without testing.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: Controlling recent APC UPS via USB

    jpd wrote:
    > Begin
    > On Mon, 28 Jan 2008 13:37:33 -0500,
    > Clever Monkey wrote:
    > [snip]
    >> - The latest apcupsd from source looks like it is rarely tested against
    >> BSD USB, since there were some pretty basic compilation and linking
    >> errors. However, the BSD USB code is sound, and is able to talk to ugen
    >> devices without a problem.

    >
    > A bit late, but: You could try and look at the port patches. If they
    > don't apply to the newer version they at least might point at how to go
    > about fixing things. I have, on occasion, successfully taken a newer
    > tarball and applied the port's patches to it in a working directory.
    >

    Maybe, but it looks like the code base has changed completely. The USB
    code is completely different, and many of the artefacts, config files
    and config options are different, or mean something different.

    The port is several years out of date with respect to the latest stable
    release, and it appears that much has changed since then. I would have
    also had to hack the port to include USB anyway, as it seems that the
    current port does not do this.

    So, you can see why I opted to go to the source. Well, that and I just
    installed 4.2 and have not installed the ports tree (yet). I'm

    >> I figure I'd cook up my own apcupsd package from the latest source (with
    >> my patches so it builds on BSD), USB flavour, so I can update it easily
    >> in the future. I'm not sure I want to commit to supporting such a port
    >> myself, but I can make the (untested, obviously) package available once
    >> it is complete.

    >
    > Well, you could try and submit your patches to the maintainer. It'd save
    > him work, and doesn't commit you to maintaining the port.
    >

    Might be a good idea, pending issues with the caveats above. If this
    means the maintainer might be prompted to update to the latest stable
    release of the app and cut flavours of the port that target USB, then
    this is a good idea.

    I'll drop the maintainer or ports@ a line about this.

    > And of course the usual ``BSD'' is not equal to {Open,Net,Free,...}BSD
    > nitpick. Even if you take it to mean the entire family, are you certain
    > this'll work equally well on the others? It'd be nice, of course, but
    > I'd not expect it without testing.
    >

    Of course. I'm following the apcupsd project nomenclature here.

    They have a mostly un-munged (by configure) directory of "BSD USB" code
    that is built on all BSD-like platforms with only small config changes
    made to Makefiles. They can do this because they've abstracted core USB
    stuff out from Linux and so on, and the various BSD flavours have
    (apparently) kept pretty close in step as far as USB userland stuff is
    concerned.

    I haven't seen any flavour-specific ifdefs in the code. BSD is treated
    in a very agnostic manner.

    Whether it builds and runs on .*BSD only with my changes is untested, of
    course. Basically, the BSD USB code in the project wouldn't build on
    any platform, since all I had to fix were some variable and function
    declarations. It will certainly build /further/ on (say) FreeBSD.

    Whether or not the server could find the UPS on whatever ugen or HID
    device it happens to bind to is another question altogether, and one
    that I am not qualified to even comment on.

  4. Re: Controlling recent APC UPS via USB

    Begin
    On Mon, 28 Jan 2008 15:42:21 -0500,
    Clever Monkey wrote:
    > jpd wrote:

    [snip!]
    >> And of course the usual ``BSD'' is not equal to {Open,Net,Free,...}BSD
    >> nitpick. Even if you take it to mean the entire family, are you certain
    >> this'll work equally well on the others? It'd be nice, of course, but
    >> I'd not expect it without testing.
    >>

    > Of course. I'm following the apcupsd project nomenclature here.


    Ah. That wasn't clear, at least to me, from the original message, though.


    > Whether it builds and runs on .*BSD only with my changes is untested, of
    > course. Basically, the BSD USB code in the project wouldn't build on
    > any platform, since all I had to fix were some variable and function
    > declarations. It will certainly build /further/ on (say) FreeBSD.


    In that case it might be interesting to announce your patches to the
    other projects' ports lists, maybe.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  5. Re: Controlling recent APC UPS via USB

    Clever Monkey writes:

    > Short answer: I have successfully got an "APC Back-UPS XS 1300" talking BSD,
    > with access to all functionality, including being able to invoke diagnostics
    > and manipulate settings. I can see the UPS events go by in the log, though
    > right now my event script is stubbed out. I assume that other similar units
    > will also work.


    I'm using a patched version of 3.14.0 lastfrom about about a year ago.
    I don't remember what patches I needed. I'm not even 100% sure I needed
    patches with that version and "cvs diff" isn't helpful here. More
    in a sec...

    > As an aside, the apcupsd tiprev via CVS does not agree with OpenBSD pthreads
    > at all (and the config did not accept any contortions to not build with
    > pthreads). Hopefully, this is addressed before CVS moves to stable.


    Just tried the latest version. The code that is causing problems
    didn't exist in 3.14.0. Figures. I just grabbed a copy using
    -D2007-02-11 to compare with my sources.... how about that. No
    patches needed. I build from those sources using

    ./configure --enable-usb
    make
    sudo make install

    // marc

  6. Re: Controlling recent APC UPS via USB

    Marco S Hyman wrote:
    > Clever Monkey writes:

    [...]
    >> As an aside, the apcupsd tiprev via CVS does not agree with OpenBSD pthreads
    >> at all (and the config did not accept any contortions to not build with
    >> pthreads). Hopefully, this is addressed before CVS moves to stable.

    >
    > Just tried the latest version. The code that is causing problems
    > didn't exist in 3.14.0. Figures. I just grabbed a copy using
    > -D2007-02-11 to compare with my sources.... how about that. No
    > patches needed. I build from those sources using
    >
    > ./configure --enable-usb
    > make
    > sudo make install
    >

    Weird. 3.14.3 (the latest "stable" release) will not build for me out
    of the box. There are some missing declarations and an incorrect
    signature for an exported library, all in bsd-usb. Pulling apcupsd from
    CVS resulted in a bunch of errors in and around pthreads, but I haven't
    gone much down that road.

    Here's a unified diff of what I changed from apcupsd-3.14.3:

    [...]
    --- bsd-usb.c Sat Oct 27 13:15:14 2007
    +++ /home/clvrmnky/apcupsd-3.14.3/src/drivers/usb/bsd/bsd-usb.c Mon Jan
    28 10:23:04 2008
    @@ -353,8 +353,9 @@
    {
    int i, rc, ci, phys;
    USB_DATA *my_data = (USB_DATA *)ups->driver_internal_data;
    - hid_item_t item;
    + hid_item_t item, witem;
    USB_INFO *info;
    + int input, feature;

    write_lock(ups);

    @@ -506,7 +507,7 @@

    // Store a (possibly truncated) copy of the floating point value
    in the
    // integer field as well.
    - val.iValue = val.dValue;
    + val.iValue = (int) val.dValue;

    Dmsg4(200, "Def val=%d exp=%d dVal=%f ci=%d\n", info->value,
    exponent, val.dValue, info->ci);
    @@ -775,7 +776,7 @@
    return true;
    }

    -int pusb_write_int_to_ups(UPSINFO *ups, int ci, int value, char *name)
    +int pusb_write_int_to_ups(UPSINFO *ups, int ci, int value, const char
    *name)
    {
    USB_DATA *my_data = (USB_DATA *)ups->driver_internal_data;
    USB_INFO *info;
    [...]

    Without most of these changes it will fail to compile, and later, link
    on my 4.2 i386 box. The cast I did just to tell the compiler to shut up
    about an expected warning. Trivial changes, but apcpsd stable will
    never compile and link on BSD without them.

  7. Re: Controlling recent APC UPS via USB

    Clever Monkey wrote:
    > Marco S Hyman wrote:
    >> Clever Monkey writes:

    > [...]
    >>> As an aside, the apcupsd tiprev via CVS does not agree with OpenBSD
    >>> pthreads
    >>> at all (and the config did not accept any contortions to not build with
    >>> pthreads). Hopefully, this is addressed before CVS moves to stable.

    >>
    >> Just tried the latest version. The code that is causing problems
    >> didn't exist in 3.14.0. Figures. I just grabbed a copy using
    >> -D2007-02-11 to compare with my sources.... how about that. No
    >> patches needed. I build from those sources using
    >>
    >> ./configure --enable-usb
    >> make
    >> sudo make install
    >>

    > Weird. 3.14.3 (the latest "stable" release) will not build for me out
    > of the box. There are some missing declarations and an incorrect
    > signature for an exported library, all in bsd-usb. Pulling apcupsd from
    > CVS resulted in a bunch of errors in and around pthreads, but I haven't
    > gone much down that road.
    >
    > Here's a unified diff of what I changed from apcupsd-3.14.3:
    >
    > [...]
    > --- bsd-usb.c Sat Oct 27 13:15:14 2007
    > +++ /home/clvrmnky/apcupsd-3.14.3/src/drivers/usb/bsd/bsd-usb.c Mon
    > Jan 28 10:23:04 2008
    > @@ -353,8 +353,9 @@
    > {
    > int i, rc, ci, phys;
    > USB_DATA *my_data = (USB_DATA *)ups->driver_internal_data;
    > - hid_item_t item;
    > + hid_item_t item, witem;
    > USB_INFO *info;
    > + int input, feature;
    >
    > write_lock(ups);
    >
    > @@ -506,7 +507,7 @@
    >
    > // Store a (possibly truncated) copy of the floating point value
    > in the
    > // integer field as well.
    > - val.iValue = val.dValue;
    > + val.iValue = (int) val.dValue;
    >
    > Dmsg4(200, "Def val=%d exp=%d dVal=%f ci=%d\n", info->value,
    > exponent, val.dValue, info->ci);
    > @@ -775,7 +776,7 @@
    > return true;
    > }
    >
    > -int pusb_write_int_to_ups(UPSINFO *ups, int ci, int value, char *name)
    > +int pusb_write_int_to_ups(UPSINFO *ups, int ci, int value, const char
    > *name)
    > {
    > USB_DATA *my_data = (USB_DATA *)ups->driver_internal_data;
    > USB_INFO *info;
    > [...]
    >
    > Without most of these changes it will fail to compile, and later, link
    > on my 4.2 i386 box. The cast I did just to tell the compiler to shut up
    > about an expected warning. Trivial changes, but apcpsd stable will
    > never compile and link on BSD without them.


    FYI there was a thread about this on apcupsd-users@lists.sourceforge.net
    just a few days ago.

+ Reply to Thread