search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
2.13k stars 355 forks source link

Add support for new APC Modbus protocol #139

Closed aquette closed 1 year ago

aquette commented 10 years ago

From APCUPSD (http://apcupsd.cvs.sourceforge.net/viewvc/apcupsd/apcupsd/ReleaseNotes?pathrev=Release-3_14_11): "APC publicly released documentation[1] on a new UPS control and monitoring protocol, loosely referred to as MODBUS (after the historic industrial control protocol it is based on). The new protocol operates over RS232 serial lines as well as USB connections and is intended to supplement APC's proprietary Microlink protocol. Microlink is not going away, but APC has realized that third parties require access to UPS status and control information. Rather than publicly open Microlink, they have created another protocol to operate along side it.

Many existing Microlink UPSes can be upgraded to support MODBUS via a firmware update. See [2]. Certain older models are not upgradeable. APC support will be your best contact for determining if your UPS supports a MODBUS upgrade the information linked below does not make it clear."

[1] http://www.apc.com/whitepaper/?an=176 [2] http://www.schneider-electric.us/support/index?page=content&country=ITB&lang=EN&id=FA164737 [3] http://www.apcupsd.com/manual/manual.html

Add support for MODBUS over RS232 and USB in NUT. This effort must be synchronized with the general Modbus support in NUT ( #50 )

Implementation notes:

ggershwf commented 10 years ago

I'm not having much success with this, unfortunately. I'm sure I'm doing something wrong, but I'm not sure what. I've got an APC Smart UPS 1500 (made in 2013). It appears that I've defined it correctly, since the drivers starts, but I get a continuous stream of "Data Stale" from upsmon. I am using Network UPS Tools upsc 2.6.5, if that makes any difference.

clepple commented 10 years ago

@ggershwf if you are referring to the nutdrv-modbus branch, then as of commit eddcd7ef00, the driver does not actually retrieve anything yet. It just links against the modbus library, and attempts to open the serial device.

It does not matter if you use an earlier version of upsc - as seen in the README file, any 2.0+ client (e.g. upsc) can talk to a 2.0+ server. The interface that is not guaranteed to be stable between versions is the driver-upsd socket interface.

clepple commented 10 years ago

@aquette link 1 is broken; searching for the filename turned up this:

http://www.apcmedia.com/salestools/MPAO-98KJ7F/MPAO-98KJ7F_R0_EN.pdf

The paragraph at the bottom of the second page looks troubling.

ggershwf commented 10 years ago

@clepple Thanks. I guess it's working up to that point, then.

aquette commented 10 years ago

Yep guys, sorry. I was in the middle of this when I got caught by family vacations. Resuming ops...

(sent from my eeePad... please excuse my brevity)

jeffsf commented 9 years ago

I'd definitely like to see this as well, especially as SUA-series APC units that aren't trashed are getting pretty scarce and the SMT-series units are coming down to a reasonable point (finally).

I have two SMT1500 units that I can work with here to help support the effort.

anthonysomerset commented 7 years ago

throwing my hat into the ring with an offer to support with testing

i have an SMT2200

ups.firmware: UPS 09.3 / ID=18 ups.mfr: American Power Conversion ups.mfr.date: 2016/11/26 ups.model: Smart-UPS 2200 ups.productid: 0003

edalquist commented 7 years ago

Is there any progress here? I have a SMC1500 and two SMT1500s. They both have basic functionality in NUT but don't report input/output voltage or load.

"All Data" dumps of the two units: https://gist.github.com/edalquist/3fb91870830242fe8016710449ce0a14

clepple commented 7 years ago

Question for those who have offered to test: does your APC UPS have a serial port, and if so, do you know if it supports MODBUS?

I ask because the effort mentioned in issue #50 seems to be focused on using libmodbus - but that library currently supports only serial and TCP. APC's method of tunneling MODBUS over USB HID reports is probably similar to the serial stream, but it sounds like it will involve rewriting a lot of code.

pjcreath commented 6 years ago

According to the white paper, all SRT models and SMT models (excluding rack mount 1U) running firmware >= UPS 09.0 support modbus. SMT models with firmware >= UPS 08.0 can be updated to 09.x, which according to the FAQ includes all 2U models and some tower models.

Given that, @anthonysomerset's SMT2200 with 09.3 should support modbus. Note that modbus is disabled by default, and has to be enabled in the Advanced menu from the front control panel.

All of these devices have serial ports (RJ45) in addition to USB. The white paper documents APC's implementation of modbus, along with its USB encapsulation.

Is this ticket no longer of interest to the team (given apcupsd's support for modbus and modbus-usb), or would you be interested in receiving a sample UPS?

clepple commented 6 years ago

@pjcreath thanks for the info.

Thank you for your offer of an UPS. I can't speak for the other NUT developers, but for me, time for development has been the primary issue. Most of that time has gone to other efforts like issue #300, and in the case of modbus-over-USB, it really would make sense do this after #300 is resolved to avoid code thrashing. I have an SMT unit in storage, and it probably won't even see the light of day for another few weeks.

We have also fielded some suggestions to just bolt some of the apcupsd modbus code onto NUT's driver system. While the licenses would certainly allow that, I don't see that as being much better than using the apcupsd-ups driver to talk to apcupsd. I would like to understand some of the nuances of the modbus implementation before adding direct support to NUT.

pjcreath commented 6 years ago

Thank you for the quick response and insight into your thinking. Yes, #300 looks more fundamental and important. And since you already have an SMT, it seems like you're all set for whenever you get around to this feature.

Bolting on the abpcupsd modbus code sounds like a wise approach, since otherwise reimplementing modbus support would just be reinventing the wheel that seems to have received actual support from APC.

To answer your question, the primary benefit of incorporating apcupsd modbus code rather than simply using the apcupsd-ups driver is for appliance and appliance-like projects (such as FreeNAS) that want to provide vendor-agnostic UPS support, and thus don't want to install and manage (and secure) an additional daemon just for APC.

Whether or not that's a reasonable position for downstream projects to take, it seems to be the current practice.

WiredWonder commented 4 years ago

Can nut-server and apcupsd run on the same machine when using the apcupsd-ups driver? Debian won't allow them both to install. I would really like to get the load level logged.

clepple commented 4 years ago

Can nut-server and apcupsd run on the same machine when using the apcupsd-ups driver? Debian won't allow them both to install. I would really like to get the load level logged.

@galapogos01 I don't see why they can't. NUT upsd and apcupsd listen on different ports. I guess I've always tested with NUT and apcupsd on separate machines, or with NUT installed from source. It might be worth filing a bug with Debian to remove the conflict.

That said, it wouldn't be too hard to build NUT from source, since the apcupsd-ups driver doesn't have complicated dependencies. More info in the wiki. Since that's starting to get a little far afield of the original topic of this issue, though, I'd recommend opening a separate issue here if you get stuck.

fastcat commented 3 years ago

The package conflict on Debian actually comes from the nut-client package, because both provide /etc/init.d/ups-monitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=170655 -- I double checked, that's still an issue. You can't install two packages providing the same file, and since nut-server depends on nut-client, you can't install both nut & apcupsd on Debian at the same time to work around this :disappointed: .

blackie333 commented 2 years ago

I'm using nut wrapper from Martin Lang and have both servers (apupsd and nut) available for clients. Please see the details here: https://www.reddit.com/r/homelab/comments/ar0h9l/apcupsd_nut_wrapper_script_apcupsd_and_nut_on_the/ For Raspbian I have created script for starting/stoppping the wrapper as a service: nutwrapper.txt I works for my Synology NAS and Domoticz nut plugin just fine.

WiredWonder commented 2 years ago

The solution for a nut issue is to use a nut emulator :(

blackie333 commented 2 years ago

It's just a workaround for people like me who need to solve the problem now. Seems that proper modbus implementation could take some time.

jimklimov commented 2 years ago

Note that recently a few modbus drivers did appear (merged in NUT master branch).

As for packaging conflicts, that ball is purely on distro maintainers' side

The file conflict should be solvable by Debian "alternatives" mechanism to activate one of several implementations, but that needs two package sets to adapt to that.

Probably you can mv one of those files to another name and force package installation.

Or build from recent source and make install.

Lots of possibilities...

Notably, haven't seen /etc/init.d/nut* anything for a decade, it's all service units now on Linux and Solaris/illumos.

On Sun, Dec 5, 2021, 21:44 blackie333 @.***> wrote:

It's just a workaround for people like me who need to solve the problem now. Seems that proper modbus implementation could take some time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/139#issuecomment-986296960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFHPVW7YYZLKT7VCGJ3UPPFL5ANCNFSM4ASFATPQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

fastcat commented 2 years ago

The file conflict should be solvable by Debian "alternatives" mechanism to activate one of several implementations, but that needs two package sets to adapt to that.

Unfortunately, alternatives doesn't work for /etc/ files AFAIK, because those are conffiles.

Notably, haven't seen /etc/init.d/nut* anything for a decade, it's all service units now on Linux

Indeed, those files come from the debian packaging.

On closer inspection, I notice the conflicting file (/etc/init.d/ups-monitor) is just a symlink in the nut package, so it may be safe to remove it, with appropriate alerts to the admin, or post-upgrade script to deal with anyone that had enabled the system through that name instead of the "canonical" nut-client name.

I've filed a debian bug to remove that symlink, we'll see what the maintainers say.

5ft24dave commented 2 years ago

I would be willing to help test as well. I have an APC Back-UPS Pro 1000, Model BX1000M and it also is missing the output voltage data. upsc C64ups@localhost battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.date: 2001/09/25 battery.mfr.date: 2019/10/11 battery.runtime: 13032 battery.runtime.low: 120 battery.type: PbAc battery.voltage: 13.8 battery.voltage.nominal: 12.0 device.mfr: American Power Conversion device.model: Back-UPS XS 1000M device.serial: 3B1941X68111 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 15 driver.parameter.port: auto driver.parameter.productid: 0002 driver.parameter.serial: 3B1941X68111 driver.parameter.synchronous: no driver.parameter.vendorid: 051d driver.version: 2.7.4-4245-g36181e16 driver.version.data: APC HID 0.96 driver.version.internal: 0.44 driver.version.usb: libusb-0.1 (or compat) input.transfer.high: 139 input.transfer.low: 88 input.voltage: 120.0 input.voltage.nominal: 120 ups.beeper.status: disabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 945.d9 .D ups.firmware.aux: d9 ups.load: 2 ups.mfr: American Power Conversion ups.mfr.date: 2019/10/11 ups.model: Back-UPS XS 1000M ups.productid: 0002 ups.realpower.nominal: 600 ups.serial: 3B1941X68111 ups.status: OL ups.test.result: No test initiated ups.timer.reboot: 2 ups.timer.shutdown: -1 ups.timer.start: 2 ups.vendorid: 051d

WiredWonder commented 2 years ago

I've filed a debian bug to remove that symlink, we'll see what the maintainers say.

Thanks, is there a reference for this?

With the recent merge of the newer version of libusb is there an alternate solution to installing apcupsd?

jimklimov commented 2 years ago

With the recent merge of the newer version of libusb is there an alternate solution to installing apcupsd?

That is a loaded question :) If the problem was indeed about stability of USB software communications, this might solve it. Maybe fiddling with pollonly to help on some platforms.

If the problem was with missing or broken USB HID mapping to translate into NUT data and concepts, the libusb version should not matter but other merged PRs might. In particular, the chain from #1023 about broken data encoding some devices send, and an effort at generic detection and hotfix of some such issues (#1246).

For missing mappings, someone should find them and PR the updated tables. Maybe the script documented to boot-strap subdriver development can help extract data from your device, and a diff could help find the missing data points.

WiredWonder commented 2 years ago

Sorry if my comment appeared out of context. My Smart-UPS X 750 works reliably with usbhid-ups however it does not report critical data (eg. load, line voltage).

Due to the Debian dependency issues mentioned in my comment above, I can't install apcupsd & nut at the same time.

jimklimov commented 2 years ago

Yes, I hoped I remembered the context from earlier reading :) Or was it another thread, where apcupsd talked to the device as being better compatible, and NUT retranslated that for networking?

My point was, I can't say OTOH whether a build of current NUT master branch (gets fixes daily recently) would "just work" for your device, allowing to not chain per above via apcupsd anymore - but an experiment can show that. (If you still need apcupsd for other reasons, and current packaging precludes that, that is a problem for distros to solve - NUT team members can at best suggest and assist).

Notably, you can build NUT locally, stop its packaged services (to release communication ports), and run the driver in data-dumping mode without replacing the stable setup. You may need to craft a config file in e.g. /tmp/ups.conf and run it like this:

$ NUT_STATEPATH=/tmp NUT_CONFPATH=/tmp ./usbhid-ups -a testdevice -d 1

to do a single data walk and check the recognized data points.

You can also build with "configure" settings copied from your distro source package for NUT, then a sudo make install would replace the files on your system.

Maybe the explore-mode tools detailed in docs/hid-subdriver.txt can help find and map the missing data points for your device support (text focuses on new subdriver generation, but the findings should be portable to existing one with any difftool -- I like "meld" for that) -- and then a PR would be welcome then to share the improvement :)

On Mon, Jan 17, 2022, 10:23 Jason @.***> wrote:

Sorry if my comment appeared out of context. My Smart-UPS X 750 works reliably with usbhid-ups however it does not report critical data (eg. load, line voltage).

Due to the Debian dependency issues mentioned in my comment above, I can't install apcupsd & nut at the same time.

— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/139#issuecomment-1014306206, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFEX76Y4S2PT7MAV4ZTUWPNZDANCNFSM4ASFATPQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

WiredWonder commented 2 years ago

I thought I'd give master a go instead of doing other work... Anyway, I got as far as this:

Network UPS Tools - Generic HID driver 0.44 (2.7.4-4271-gd70124c0) USB communication driver (libusb 0.1) 0.35 interrupt pipe disabled (add 'pollonly' flag to 'ups.conf' to get rid of this message) Can't claim USB device [051d:0003]@0/0: could not detach kernel driver from interface 0: Operation not permitted

There were no other nut processes running on the machine at the time & I was running as root. Any ideas?

jimklimov commented 2 years ago

One idea might be about running the driver (properly) as the non-root user, which then needs udev rules (or some equivalent way for other systems) which would set the device-node permissions for this user (or anyone unsafely): by default, the kernel or some system daemon holds the devices.

A build of NUT should include generated rule-sets to install into the OS for that; I'd assume blindly that your existing (packaged) set-up already pushed that, but it makes sense to check if it did and if the build provided some newer relevant rules.

Also, if you start the test as root you can tell the driver to not drop privileges with -u root explicitly, e.g. I recently collected data-dumps with:

# NUT_STATEPATH=/tmp ./drivers/usbhid-ups -s xxx -d 1 -x port=auto -x vendorid=0463 -x productid=FFFF -DDDDDD -u root
WiredWonder commented 2 years ago

Thanks.

I got it to run by using the correct user. The latest (master) version of usbhid-ups does not report any additional data for my APC Smart-UPS X 750.

fastcat commented 2 years ago

I've filed a debian bug to remove that symlink, we'll see what the maintainers say.

Thanks, is there a reference for this?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001302

My TL;DR of the maintainers response is "removing sysvinit support would probably break things for folks, and breaking power management is pretty bad" ... which isn't unreasonable.

There might be ways to break out that piece and have the "alternatives" system handle it, but that's a fair bit of work, and would still require a lot of testing of upgrade paths to be safe.

fronczek commented 2 years ago

I've just added NUT support to my PRTG helper script, so you han check if interested ;-) It's using APC modbus tcp protocol. https://github.com/fronczek/prtg-apc-modbus

man55 commented 1 year ago

Any news here about MODBUS USB support? I bought a new APC Smart-UPS SMT1000ic, connected via USB to a NUT Raspberry, but most of the data is not displayed ((. I read everything here and in related tickets, after which I installed Apcupsd UPS control system, set it to MODBUS USB and it perfectly sees all the data, voltages, load etc... But it's not compatible with the NUT server I use elsewhere with other UPSs and would like to monitor everything together rather than having separate systems. Tnx.

p.s. Yes, I read that it can work through the APC9630, but it is expensive and I see no reason to buy it, while UPS already has USB and it is possible to pull more data.

fronczek commented 1 year ago

Any news here about MODBUS USB support? I bought a new APC Smart-UPS SMT1000ic, connected via USB to a NUT Raspberry, but most of the data is not displayed ((. I read everything here and in related tickets, after which I installed Apcupsd UPS control system, set it to MODBUS USB and it perfectly sees all the data, voltages, load etc... But it's not compatible with the NUT server I use elsewhere with other UPSs and would like to monitor everything together rather than having separate systems. Tnx.

p.s. Yes, I read that it can work through the APC9630, but it is expensive and I see no reason to buy it, while UPS already has USB and it is possible to pull more data.

Try using MODBUS TCP maybe... Works for me ;-)

jimklimov commented 1 year ago

MODBUS TCP won't help for USB-only links...

AFAIK nobody contributed a new driver yet, so... Per http://www.apcupsd.org/ and https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/ latest release was 2016 and latest commits overall in 2017, and it is also GPLv2 - maybe it would be right to port their logic as a NUT driver proper?

man55 commented 1 year ago

Try using MODBUS TCP maybe... Works for me ;-)

Is it via usb connection? Unfortunately, I could not find and understand how to do this. Could you suggest which driver to use and how to set it up?

jimklimov commented 1 year ago

Also, this puzzles me: "But it's not compatible with the NUT server I use elsewhere with other UPSs and would like to monitor everything together rather than having separate systems."

Did you try NUT's apcupsd-ups driver (retranslates info from apcupsd to NUT server)? Did it not work with releases you have, or did it not relay all info you have (maybe some mappings need to be added)?

man55 commented 1 year ago

Did you try NUT's apcupsd-ups driver (retranslates info from apcupsd to NUT server)? Did it not work with releases you have, or did it not relay all info you have (maybe some mappings need to be added)?

apcupsd-ups driver in NUT did not work for me or I can't understand how to do this. Now I use Apcupsd from apcupsd.org, it's just another monitoring system and installing it automatically removes NUT. They are not compatible.

jimklimov commented 1 year ago

My understanding is that you first start the real apcupsd to talk to the ups, and then NUT's apcupsd-ups to talk to it (localhost:port usually) and represent the device in common NUT client/server ecosystem.

This may be overkill when you only have one UPS and a PC (makes sense still if you know NUT and its clients better), but is useful to coordinate many devices.

man55 commented 1 year ago

My understanding is that you first start the real apcupsd to talk to the ups, and then NUT's apcupsd-ups to talk to it (localhost:port usually) and represent the device in common NUT client/server ecosystem.

This may be overkill when you only have one UPS and a PC (makes sense still if you know NUT and its clients better), but is useful to coordinate many devices.

No, I have more than 3 UPS's in different places and two rasppi for monitor it (tnx to stupid russia that bombs our energy infrastructure). The last setup is a new APС SMT1000i with modbus and a separate raspberry to connect to the network (rasp is cheaper than APC9630 + a separate access point). And I would like to use NUT here, but it does not read almost all the data.

fronczek commented 1 year ago

MODBUS TCP won't help for USB-only links...

I know, and I wanted something more universal that's why I created python interface for NUT and PRTG (see https://github.com/fronczek/apc_modbus ) You don't need expensive SNMP card and you can forget about USB connection and use builtin TCP comm. The only thing you need to do is to enable modbus tcp via the buttons in UPS menu. It's kind of "hidden" but should ba available on all new "cloud enabled" UPSes.

man55 commented 1 year ago

use builtin TCP comm

How to connect it? Which cabble?

fronczek commented 1 year ago

use builtin TCP comm

How to connect it? Which cabble?

Normal ethernet cable (upper left corner: https://download.schneider-electric.com/files?p_Doc_Ref=SPD_CENZ-AW76YB_B_V&p_File_Type=rendition_1500_jpg)

The flow: You enable modbus-tcp on UPS You create "dummy" SNMP extend on raspberry (python script will connect via modbus-tcp and "translate modbus to snmp" values) You connect NUT to raspberry itself with regular SNMP driver (or any device which understands SNMP UPS like Synology etc)

EetuRasilainen commented 1 year ago

Regarding apcupsd-ups: you need to be super careful when running apcupsd on the same system as NUT. Many distributions will not allow this for good reasons. If you want NUT to issue a killpower command during shutdown you might end up with a stopped apcupsd instance at the stage that NUT actually wants to call upsdrvctl shutdown. It's possible to work around this, but you really need to know what you are doing. Otherwise you'll end up with an undesirable UPS state in case of a power outage.

Regarding this apc_modbus Python interface/wrapper: I'd consider it a good proof-of-concept for Modbus communication from Python code. I would not run it in production as a NUT backend as it introduces the same issues as running apcupsd on the same machine as NUT. The dummy-ups approach does not support sending any commands to the UPS anyway. And the SNMP approach won't work during system shutdown unless you take extra caution. And apparently advanced features such as load calibration, setting battery replacement date, configuring self-test intervals or even controlling outlet groups are also not available.

All this can only be solved properly through a native modbus_apc driver within NUT. But this means somebody with C coding skills needs to pick up the challenge.

Or maybe somebody wants to ask the APC support if they are willing to contribute some code to the NUT project. Proper NUT support for recent APC devices would definitely be a selling point for APC so it's not completely unlikely to happen.

jimklimov commented 1 year ago

Thinking of it, another option may be to somehow absorb apcupsd (pick up their code for device support?) as a "native" NUT driver with better device support than what we have now. It unfortunately seems that project is stale (last commits about 5-6 years ago), but at least both codebases are licensed under the terms of GPL so in FOSS spirit it would give another useful life to somebody's prior effort.

FWIW I'll stash a one-off copy of their history at https://github.com/networkupstools/apcupsd using GitHub importer for SVN sources to grab the current state of https://svn.code.sf.net/p/apcupsd/svn

EchterAgo commented 1 year ago

I'm working on adding support for APC's USB Modbus to libmodbus:

https://github.com/EchterAgo/libmodbus/commits/rtu_usb

This already works (tested on APC Smart-UPS1500), but it needs to have the 35ms inter-frame delay added properly and there needs to be a better way to specify the device when using modbus_new_rtu_usb. Autotools also needs some work to find libusb as a dependency and only compile the new code if found. Also we need a good way to get the RX/TX report id from the USB report descriptor.

jimklimov commented 1 year ago

@EchterAgo : thanks for the heads-up, sounds great! :) I've posted some comments on your initial commits there. One was actually about autotools and detection, sorry missed it in your concerns here - rushed to take a look :)

As for NUT support for APC ModBus, I worry if it is about not only "low-level" connectivity handled by libmodbus, but also about a NUT driver knowing what questions to ask and what reports to expect in return...

EchterAgo commented 1 year ago

@jimklimov I plan to also add a NUT driver based on the generic modbus driver when I find the time. I posted the libmodbus change here because I wanted to see what people here think about adding USB support to libmodbus.

WiredWonder commented 1 year ago

Love your work!

blackie333 commented 1 year ago

This is a great news, for years we wait for improved APC support in NUT able to report all values (as apcupsd). Excited for testing on my SMT750i, keep up the good work guys.

EchterAgo commented 1 year ago

Good to see there is some demand for this. If anyone wants to test something with a USB APC Modbus unit it would be good to test libmodbus, download my rtu_usb branch, it needs libusb-1.0 development libraries installed. Compile it (something like ./autogen.sh ; ./configure ; make, then run ./tests/apc-test-client. It should output some measurements, but it could also fail because the hardcoded USB report ids are wrong for your model. See src/modbus-rtu-usb-private.h to change the ids.

Yesterday I compiled a list of tasks to make the new driver and some challenges. It is not a lot, I hope to have something basic for testing ready soon™.

I'm also not sure yet how much we need to account for different models. I have 3 different Modbus capable APC units here and I'll try to test on each of them.

jimklimov commented 1 year ago

As noted earlier, I think it is fair game to inspire new drivers from apcupsd which is also GPL'ed and seems a bit stale (active community, but last commits ~6 years ago last I looked) so it would be more resuscitation than heist :)