Issue with Powersa RT3000 / Blazerusb driver

[garci66]

I have a UPS based on a generic brand (have seen it sold under various brands) and using blazer_usb it "almost" works. The initialization, for blazer_rating / blazer_vendor fails as it seems to UPS seems to be sending one byte less than expected by the driver. The \r at the end seems to be missing (can't see the raw USB data at the moment) but the log shows as follows when invoking

blazer_usb -x vendorid="ffff" -x productid="0000"  -a myups -x subdriver=krauler -u root -DDDD

   0.093142     Checking device (FFFF/0000) (004/002)
   0.125331     - VendorID: ffff
   0.125422     - ProductID: 0000
   0.125486     - Manufacturer:
   0.125530     - Product: 010937
   0.125565     - Serial Number:
   0.125600     - Bus: 004
   0.125631     Trying to match device
   0.125743     Device matches
   0.130330     Trying megatec protocol...
   0.130425     send: Q1
   0.407358     received 46 (40)
   0.407402     read: (227.0 120.0 000.0 000 49.9 2.28 25.0 00000001
   0.407509     Status read in 1 tries
   0.407519     Supported UPS detected with megatec protocol
   0.407530     send: F
   0.554359     received 21 (35)
   0.554409     read: #220.0 013 72.00 50.0
   0.554420     blazer_rating: short reply
   0.554430     Rating read 1 failed
   0.554439     send: F
   0.710376     received 21 (35)
   0.710419     read: #220.0 013 72.00 50.0
   0.710430     blazer_rating: short reply
   0.710439     Rating read 2 failed
   0.710448     send: F
   0.868276     received 21 (35)
   0.868321     read: #220.0 013 72.00 50.0
   0.868333     blazer_rating: short reply
   0.868343     Rating read 3 failed
   0.868352     Rating information unavailable
   0.868364     send: I
   1.104396     received 38 (35)
   1.104440     read: #Powersa         RT 3000    MP0013BS
   1.104450     blazer_vendor: short reply
   1.104459     Vendor information read 1 failed
   1.104469     send: I
   1.341387     received 38 (35)
   1.341429     read: #Powersa         RT 3000    MP0013BS
   1.341440     blazer_vendor: short reply
   1.341449     Vendor information read 2 failed
   1.341459     send: I
   1.576379     received 38 (35)
   1.576422     read: #Powersa         RT 3000    MP0013BS
   1.576433     blazer_vendor: short reply
   1.576442     Vendor information read 3 failed
   1.576451     Vendor information unavailable
   1.576459     No values provided for battery high/low voltages in ups.conf

   1.576485     Using 'guestimation' (low: -0.866667, high: -1.083333)!
   1.576496     Battery runtime will not be calculated (runtimecal not set)
   1.576522     send: Q1
   1.849411     received 46 (40)
   1.849454     read: (227.0 120.0 000.0 000 49.9 2.28 25.0 00000001
   1.849605     dstate_init: sock /var/run/nut/blazer_usb-myups open on fd 11
   1.849623     send: Q1
   2.124425     received 46 (40)
   2.124478     read: (227.0 120.0 000.0 000 49.9 2.28 25.0 00000001

when looking at

nut/drivers/blazer.c

Line 296 in 1ba5111

static int blazer_rating(const char *cmd)

I can see that it checks the length of the return string to include the \r. I think we could relax the lenght check to be one character less and the same thing on the blazer_vendor function.

[zykh]

Right. It's a known problem: #441.
Try nutdrv_qx from this branch: https://github.com/zykh/nut/tree/issue-441

[garci66]

Thanks! will do.. I tried searching for similar issues but wasn't finding it.

[garci66]

The fix seems to focus on the status messages (which in my case DO work). My problem is with the first two queries when trying to identify the vendor and rating of the UPS.

[zykh]

The fix seems to focus on the status messages (which in my case DO work).

actually, it should add a CR at the end of anything it reads, if it's not already there...

[jimklimov]

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 => #441 ?