At the moment, SEC protocol [1] is only (partially) supported by gamatronic driver [2] (and only if the device ends messages with a CR - not a standard feature) [3].
So, I think it's worth adding a new driver ('nutdrv_sec') with various subdrivers (à la usbhid-ups/nutdrv_qx/...), to support:
- standard SEC protocol,
- gamatronic flavour,
- voltronic P35 and P36 protocols.
The driver needs to support both USB (cypress for voltronic devices) and serial communication and let subdrivers do some preprocessing on data and CRC checks.
In my view a simplified take on nutdrv_qx (it already has the serial/usb combo and the items grouped by commands to use the same successful answer more times), that expects data in SEC format (^P|S|D<length><data>, ^0->nak, ^1->ack) and splits lines on commas (instead of data at fixed indexes as is in the various Q* protocols) letting subdrivers access the tokens, would do.
Thoughts? Rants?
Waiting for your blessing...
(please, note that I cannot test it with real hardware)
- http://www.networkupstools.org/ups-protocols.html#_sec
-
- also, see:
At the moment, SEC protocol [1] is only (partially) supported by gamatronic driver [2] (and only if the device ends messages with a CR - not a standard feature) [3].
So, I think it's worth adding a new driver ('nutdrv_sec') with various subdrivers (à la usbhid-ups/nutdrv_qx/...), to support:
The driver needs to support both USB (cypress for voltronic devices) and serial communication and let subdrivers do some preprocessing on data and CRC checks.
In my view a simplified take on nutdrv_qx (it already has the serial/usb combo and the items grouped by commands to use the same successful answer more times), that expects data in SEC format (
^P|S|D<length><data>,^0->nak,^1->ack) and splits lines on commas (instead of data at fixed indexes as is in the various Q* protocols) letting subdrivers access the tokens, would do.Thoughts? Rants?
Waiting for your blessing...
(please, note that I cannot test it with real hardware)