Apparently some devices don't close their replies to our commands/queries with the expected (and mandated by the specs) CR and, at the moment, this is not supported by nutdrv_qx:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2017-June/010714.html
('krauler' USB subdriver)
As far as I can remember, this eventuality can only happen with certain USB subdrivers that only read a predetermined amount of data, read data from a given index or wait till no more data is available (if I recall correctly, serial communication and other USB subdrivers need the terminating CR in order to work properly), so, probably, the easiest fix should be to handle this situation in those USB subdrivers.
Also, this should not be considered an improvement, but a regression that needs to be solved, since blazer_* drivers, being less strict on the terminating CR of Q1 replies (3747fd5), should (sort of) support (some of) this kind of devices.
MAINTAINER NOTE: The null byte vs. \r at end of reads sounds reminiscent of work recently done by @blaa for the nutdrv_qx subdriver for armac in #2005; maybe this part should/can be generalized somehow to help with all devices that do not use CR/LF in protocol? It seems that the 1595a06 commit which allegedly solved this issue previously added the fix for certain *_command() methods, and so is lacking in some others that appeared afterwards.
Apparently some devices don't close their replies to our commands/queries with the expected (and mandated by the specs) CR and, at the moment, this is not supported by nutdrv_qx:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2017-June/010714.html
('krauler' USB subdriver)
As far as I can remember, this eventuality can only happen with certain USB subdrivers that only read a predetermined amount of data, read data from a given index or wait till no more data is available (if I recall correctly, serial communication and other USB subdrivers need the terminating CR in order to work properly), so, probably, the easiest fix should be to handle this situation in those USB subdrivers.
Also, this should not be considered an improvement, but a regression that needs to be solved, since blazer_* drivers, being less strict on the terminating CR of Q1 replies (3747fd5), should (sort of) support (some of) this kind of devices.
MAINTAINER NOTE: The null byte vs.
\rat end of reads sounds reminiscent of work recently done by @blaa for thenutdrv_qxsubdriver forarmacin #2005; maybe this part should/can be generalized somehow to help with all devices that do not use CR/LF in protocol? It seems that the 1595a06 commit which allegedly solved this issue previously added the fix for certain*_command()methods, and so is lacking in some others that appeared afterwards.