{"id":693,"date":"2019-12-19T09:01:46","date_gmt":"2019-12-19T14:01:46","guid":{"rendered":"https:\/\/crossan007.dev\/blog\/?p=693"},"modified":"2020-02-10T15:03:57","modified_gmt":"2020-02-10T20:03:57","slug":"configuring-multiple-networked-apc-ups-devices","status":"publish","type":"post","link":"https:\/\/crossan007.dev\/blog\/linux\/configuring-multiple-networked-apc-ups-devices\/","title":{"rendered":"Configuring Multiple Networked OR USB APC UPS devices"},"content":{"rendered":"\n
Tweet<\/a><\/div>\n\n

As any proper IT-nerd would agree, UPS devices are critical pieces of equipment not only in the data center, but also at home. However, most home users are not in a position to acquire a massive 10+ kilovolt-amp<\/a> UPS capable of protecting all circuits by which our various “personal devices” are powered; rather, most home\/small office UPS installations are often small desktop units usually under 3kVA. In this scenario, these smaller units are typically allocated to individual devices \/ ares, and are typically only responsible for signaling the status of the incoming utility power to one device.<\/p>\n\n\n\n

What about using multiple UPS devices for different components of the same “workspace”? Or home networks with access points and switches in more than one location (therefore each having its own battery backup)? How would one monitor multiple distributed battery backup units (presuming each UPS unit has only USB connectivity)?<\/p>\n\n\n\n

APCUPSD<\/h2>\n\n\n\n

Enter apcupsd<\/em><\/a>: “A daemon for controlling APC UPSes.” Unfortunately, the plurality of this utility’s tagline indicates a wide range of supported devices rather than multiple concurrently connected devices. To date, I’ve found one article describing how to configure apcupsd <\/em>to support multiple<\/strong> USB-attached UPS devices<\/a>, and it’s not really pretty. The gist of the process is as follows:<\/p>\n\n\n\n

  1. Configure udev rules to ensure a consistent mapping (by UPS serial number) to a named mount point<\/li>
  2. Create multiple apcupsd<\/em> configuration files for each connected UPS<\/li>
  3. Create new “action” and “control” scripts for each UPS<\/li>
  4. Re-configure the apcupsd<\/em> init.d\/systemd scripts to launch multiple instances of the daemon (one for each UPS) <\/li><\/ol>\n\n\n\n

    I’m generally not a fan of creating large “custom” configuration files in obscure locations with great variance from the distributed package, so this process seemed a little “hackey” to me; especially since the end result of all of these configuration files was to have “isolated processes” for each UPS to monitor.<\/p>\n\n\n\n

    Dockerizing APCUPSD<\/h2>\n\n\n\n

    At this point, I decided to take a different approach to isolating each apcupsd<\/em> process: an approach with far greater discoverability, version-control potential, and scalability. Docker.<\/p>\n\n\n\n

    I decided to use the first step outlined in the apcupsd<\/em> guide on the Debian Wiki<\/a> (creating udev rules to ensure physical devices are given a persistent path on boot\/attach). UPS devices are generally mounted at \/dev\/usb\/hiddev*<\/code>, so we should confirm that we have a few present:<\/p>\n\n\n\n

    # ls \/dev\/usb\nhiddev0  hiddev1\n\n# lsusb\nBus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub\nBus 004 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply\nBus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub\nBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub\nBus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply\nBus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<\/code><\/pre>\n\n\n\n
    Great! we’ve got things that look like<\/strong> UPS devices on \/dev\/usb\/hiddev0<\/code> and \/dev\/usb\/hiddev1<\/code>.  Now to get the serialnumbers:<\/p>\n\n\n\n
    # udevadm info --attribute-walk --name=\/dev\/usb\/hiddev0 | egrep 'manufacturer|product|serial'\n    ATTRS{manufacturer}==\"American Power Conversion\"\n    ATTRS{product}==\"Back-UPS BX1500G FW:866.L5 .D USB FW:L5 \"\n    ATTRS{serial}==\"8975309\"\n    ATTRS{manufacturer}==\"Linux 4.4.0-170-generic ohci_hcd\"\n    ATTRS{product}==\"OHCI PCI host controller\"\n    ATTRS{serial}==\"0000:00:02.0\"\n# udevadm info --attribute-walk --name=\/dev\/usb\/hiddev1 | egrep 'manufacturer|product|serial'\n    ATTRS{manufacturer}==\"American Power Conversion\"\n    ATTRS{product}==\"Back-UPS NS 1100M2 FW:953.e3 .D USB FW:e3     \"\n    ATTRS{serial}==\"8675310\"\n    ATTRS{manufacturer}==\"Linux 4.4.0-170-generic ohci_hcd\"\n    ATTRS{product}==\"OHCI PCI host controller\"\n    ATTRS{serial}==\"0000:00:04.0\"<\/code><\/pre>\n\n\n\n
    With the now known serial numbers, we create udev rules to persist these devices to known map points:<\/p>\n\n\n\n
    ## FILE AT \/lib\/udev\/rules.d\/ups.rules\n\n# SCREEN UPS\nKERNEL==\"hiddev*\", ATTRS{manufacturer}==\"American Power Conversion\", ATTRS{serial}==\"8975309\", OWNER=\"root\", SYMLINK+=\"usb\/ups-screen\"\n\n# ComputeAndNetwork UPS\nKERNEL==\"hiddev*\", ATTRS{manufacturer}==\"American Power Conversion\", ATTRS{serial}==\"8675310\", OWNER=\"root\", SYMLINK+=\"usb\/ups-compute-and-network\"<\/code><\/pre>\n\n\n\n
    And now to re-run the udev rules:<\/p>\n\n\n\n
    udevadm trigger --verbose --sysname-match=hiddev*<\/code><\/pre>\n\n\n\n
    Now, we should have some “nicely named” UPS USB devices:
    <\/p>\n\n\n\n
    # ls -la \/dev\/usb\ntotal 0\ndrwxr-xr-x  2 root root    120 Dec 18 19:55 .\ndrwxr-xr-x 22 root root   4280 Dec 18 19:55 ..\ncrwxrwxrwx  1 root root 180, 0 Dec 18 19:55 hiddev0\ncrwxrwxrwx  1 root root 180, 1 Dec 18 19:55 hiddev1\nlrwxrwxrwx  1 root root      7 Dec 18 19:55 ups-compute-and-network -> hiddev1\nlrwxrwxrwx  1 root root      7 Dec 18 19:55 ups-screen -> hiddev0<\/code><\/pre>\n\n\n\n
    Excellent!   Now, anytime these devices are plugged\/unplugged, we shouldn’t have to guess which is hiddev0<\/code> and which is hiddev1<\/code>, since udev will automagically provide us named mount points <\/strong>for these USB devices, which will be critical to the next steps<\/p>\n\n\n\n
    Next, I created a docker-compose<\/code> file <\/a>with the three<\/em> “services” I decided I’d like for this setup: <\/p>\n\n\n\n