Add support for new APC Modbus protocol #139
Comments
|
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 eddcd7e, 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. |
|
@clepple Thanks. I guess it's working up to that point, then. |
|
Yep guys, sorry. (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
|
|
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. |
@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 |
|
I'm using nut wrapper from Martin Lang and have both servers (apupsd and nut) available for clients. |
|
The solution for a nut issue is to use a nut emulator :( |
|
It's just a workaround for people like me who need to solve the problem now. |
|
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
<#139 (comment)>,
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>.
|
Unfortunately, alternatives doesn't work for /etc/ files AFAIK, because those are conffiles.
Indeed, those files come from the debian packaging. On closer inspection, I notice the conflicting file ( 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. |
|
When nothing else helps, RTFM ;) Per https://networkupstools.org/docs/developer-guide.chunked/apas02.html :
The |
|
Thanks, seems like they are mapped to the correct nut name!
Currently the driver is reporting the device values directly which are a % of total available capacity. The device also reports capacity, so the value in Watts/VA could be calculated. Current load is about 180W |
|
@galapogos01 I pushed a commit that changes power/realpower to absolute numbers. Edit: Also added the nominal values. |
|
Great work! Looking good here. Thank you so much again - it's great to see these very popular models finally get proper support in nut. |
Great work! Amazing to see this coming alive after 9yrs! 🥇 Does Modbus TCP output help at all? Modbus TCP Debug |
|
@PrplHaz4 it is great to know it is working, thanks for testing! What would also be of interest is whether reconnection is handled well. Like if you remove the cable and it times out or if the UPS closes the connection (not sure how to test that). As for your |
Thanks for the tip on /tmp - that worked to keep it running. I put the full build in a docker container, so other things might be going on, but after some time (maybe 5 mins?) the TCP connection times out and seems to loop on error (logs below). the TCP timeout might be a valid failure mode in general. I'll work on a plug/replug USB test as well. Modbus TCP Debug |
This indicates that it is getting a response to a previous command. There likely needs to be a buffer flush somewhere. I just pushed a commit for testing that does buffer flushing on reconnect and open. |
|
Do I need the patched Right now I am querying my SMT1500 using a custom Python script and pymodbus through this serial cable but I'd prefer to use NUT for this. |
|
@EetuRasilainen you don't need a patched libmodbus for serial. |
Thanks again! Still seeing these on 10071db after about 5 mins. Modbus TCP Debug |
|
Still looks like it receives a response packet that was expected for the previous command. Could you maybe do a I asked APC/SE to send me a NMC to test this but so far they only replied telling me where to buy one, and I'm not going to spend multiple hundred bucks on that :\ Maybe I should try to make a RS232 to TCP Modbus converter on a Raspberry Pi Pico. |
|
There is also something very similar here: stephane/libmodbus#525, stephane/libmodbus#255 |
|
Also, the serial backend of libmodbus handles such timeouts just fine, but I'll try some more to see if i can produce such a problem. |
|
@PrplHaz4 I made another change, give it a try. I haven't actually tested this yet because I am currently changing the USB modbus driver, but I think it might work. |
First look the additional flush seems to be allowing it to re-connect after timeout and resume displaying values (quickly) after that - so definitely a win there. There definitely seems to be a lot of noise in the output right now - I will get some better data tonight. I know nothing about modbus - is there a really short timeout expected between messages (due to it being more of a stream than a poll) or something like that? |
|
Great. What kind of noise do you mean? I also don't know much about modbus, but the need for a delay between frames seems to be because modbus frames do not really have a uniquely identifiable start condition / preamble, so there is a need to wait a certain time to make sure there is not a message currently transferring. I got this from the APC manual and initially I sometimes hit this delay, but in the current version at least on my computer it wasn't hit. |
Here is my capture from the train this morning (with a very spotty network connection - so the noise may be related to that). You can see a lot of TCP Modbus debug |
|
Oh, you did the capture through the spotty network? That does look like what I would expect there. I wonder if we actually need a higher timeout somewhere, it seems your connection is disconnecting when sending a command and already reconnecting before the response is received, then the response comes, sits in a buffer and gets received (now flushed) when sending the next command. I'll have to read the modbus TCP code for this some more. |
|
I'm also not sure if this is an issue with the APC firmware or libmodbus, but I don't think it is actually a problem in nut. We could also try just waiting some time after a reconnect, before flusing. |
|
@PrplHaz4 I pushed another commit that removes the flushing before register reads, but instead adds a 1 second delay between connecting and buffer flush. If this works we should try finding a good value for the delay because 1 second is just arbitrarily chosen by me. |
Yes, the capture above was on a spotty network. This capture is from a stable network. It looks like the failures start 184s into the run, and continues until at least 321s without "recovering". The previous capture from the spotty network appears to have recovered after some time, and went in and out of being able to pull full values. I'm not sure how to help on the timing of the flush - I'm sure it doesn't help providing data from two drastically different networking environments. TCP Modbus Debug - Stable Network |
|
Thanks for testing this. Could you maybe privately (or publicly if you want) share a packet capture from Wireshark or tcpdump on port 502? With Wireshark you can put a capture filter somewhere, just use With tcpdump you can use something like |
|
Hi, Good to see this work. If it helps, I just wanted to add that I found an APC SMT2200RMI2UC made in July 2019 didn't work with apcupsd 3.14.14 running on Windows Server 2016 via modbus over USB. modbus over serial was OK. With USB, it looked like an ordering error (responses out of order). apcupsd on Windows (2008 R2) was OK with modbus over USB with a SmartUPS 1500 LCD SMT1500I (vendor id 051d, product id 0003) made in 2015. Not with linux though, where it gave immediate errors. Also I note the new(ish) range of APC Smart-UPS's with Lithium batteries only support modbus over serial, not USB, at least in the brochures. So I wonder if working modbus over USB is restricted to older APC Smart UPS models ? Thanks. |
I haven't really had experience with newer APC units, mine is from 2015. If it works with on one OS and not on the other the issue must be software. It would be nice if you could try the code I posted in #2063, maybe we can diagnose what is going on. The implementation of this is not based on |
…etworkupstools#2063] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ndencies for apc_modbus [networkupstools#139, networkupstools#2063] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
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:
The text was updated successfully, but these errors were encountered: