networkupstools
Add support for new APC Modbus protocol
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:
- serial version: use the serial RTU support from libnutdrv_modbus (WIP)
- USB version: 2 possibilities
- create a HID subdriver, that marshals Modbus => better integration, easier for users
- create a new driver, which uses interrupt support in NUT libusb, but not libhid (for the 2 usages ModbusRTURx and ModbusRTUTx) => smaller driver footprint
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.
@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.
@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.
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)
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.
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
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
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.
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?
@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.
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.
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.
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.
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: .
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.
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.
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
- NUT team is not directly involved in that, though I'd be happy to help or accept PRs to maintain the "reference" init scripts and service definitions in NUT and reduce reinvention of the wheel across the board.
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.
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.
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
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?
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.
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.
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: @.***>
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?
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
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.
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.
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
