[Nut-upsdev] UPS serial protocol
clepple at gmail.com
Sat Nov 7 17:38:41 UTC 2015
On Nov 5, 2015, at 11:33 AM, Rob Groner <rgroner at RTD.com> wrote:
> Having dealt with the USB portion of our UPS, I’m now reviewing our serial port communication. I’ve looked over some of the drivers in NUT to see how they handle it so I can get an idea of what the “standard” is for how to accomplish it. I’d like to do something simple and human readable.
The de facto standard is some variant of the Megatec protocol: http://www.networkupstools.org/protocols/megatec.html
The Phoenixtec (SOLA) protocol is similar: http://www.networkupstools.org/protocols/sola.html
These two protocols (plus their spin-offs) are currently handled by the nutdrv_qx driver (and previously by blazer_ser). It auto-detects the protocol variants, so this is probably your best bet to get something supported out-of-the-box (although I realize you are planning to ship a NUT driver for the USB side).
They are basically ASCII, but not self-describing. I guess it depends on your motivation for the human-readable part. There are a few more ASCII-based protocols where the command names are more verbose, but then you're hitching your wagon to a less-often-used driver.
zykh can comment on whether it makes sense to try and match some of the Voltronic protocol, which IIRC is an extension (and is also handled by nutdrv_qx).
Until you get to the binary protocols like BCM/XCP, the serial port speeds tend to be slow (2400-9600). This is a cheap way to get noise resistance. Faster speeds go hand-in-hand with checksums.
> It seems like most data is gathered from a query and a response. Is that typical? I could have our UPS output data asynchronously…say, time remaining when on battery, or when states change, etc.
Query/response is typical. Many UPS cables don't properly implement hardware handshaking, so polling every few seconds is a cheap way to confirm that the UPS is still connected. Also, by keeping the protocol-level handshaking to a minimum, you can easily disconnect the cable and reconnect it without complicated resynchronization logic.
> What format should all responses by the UPS take so that parsing them is easiest in NUT? Bracketed by tags of some kind? Or is ending with a ‘\n’ enough?
The ser_get_line() function is flexible enough to handle various line endings: http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_serial_port_handling
> Any general suggestions or comments about serial port communication with UPSes? I don’t want to reinvent the wheel here, or leave out some key functionality/commands that is going to make using our UPS through a serial port into a chore. Otherwise, if there really is no “standard”, I’ll just try to make the best choices I can, and our users can deal with it. J
The nutdrv_qx/blazer_ser drivers implement the necessary status/command features for safely shutting down a system, plus some basic monitoring features and test commands. If your customers' desired feature list matches that, you should be all set.
clepple at gmail
More information about the Nut-upsdev