On Nov 5, 2015, at 11:33 AM, Rob Groner <[email protected]> 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. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
