[Nut-upsdev] UPS serial protocol

[Rob Groner]

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.

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.

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?

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. :)

Thanks,

Rob Groner
Senior Software Engineer

RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
Ph: [phone]
www.rtd.com<http://www.rtd.com/>

[Charles Lepple]

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.

[Rob Groner]

-----Original Message-----
Sent: Saturday, November 07, 2015 12:39 PM
Subject: Re: [Nut-upsdev] UPS serial protocol

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.
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).

Ya, I hadn't planned on supporting serial NUT as well as USB, but I now have time to devote to it.

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.

I have an advantage, which is that I can sort of do both. The hardware engineer on the project basically came up with his own means of talking to the UPS through serial, so I have to preserve that in some manner. By adapting it some, it becomes a more readable and intuitive protocol ("!bv?" gets you battery voltage, etc). But I don't see why I can't support that as well as a more concise protocol like the qx. It seems pretty simple and straight-forward.

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.

Good point. I'm going to change our default from 115200 to 2400. I have commands in place that they can change the port settings if they need to.

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.

The original requirements and customer feature list was handled a long time ago....it wasn't much. I'm trying now to fill out everything else before we offer the UPS on our website to the "general public".

Thanks for the help, that was good guidance. I may need some more help when it comes to getting NUT to talk to the UPS via serial, as I haven't tried that before. I know it should be straight-forward.


Rob Groner
Senior Software Engineer

RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
www.rtd.com