Nut upsdev - Jan 2013 - [blazer_usb] Support for TECNOWARE ERA LCD (FGCERALCD0K85)

Hi to all and happy new year!
I'm writing here as I'm trying to get nut supporting the UPS in the
subject; I didn't check well before buying and nowI discovered this is
kinda bad hardware (it doesn't have a valid USB id, it just reports
0000:0001 and linux support doesn't really work as they stated), but before
changing it I wanted to try to find a solution to get it work with nut and
hopefully help other people with the same problem.

I posted before into nuts-upsuser mailing list (
http://lists.alioth.debian.org/pipermail/nut-upsuser/2012-December/008165.html)
but the topic moved to the dev area so I'll try to resume all the
relevant info in this mail.

At the end you'll find my configuration, output errors are in the
attachment log.txt.
I tried to sniff some commands from Tecnoware software UPSilon2000 (windows
version, the only one working).
Sniffing results (here:
https://docs.google.com/open?id=0B9DltUspeUMtamFnRDlqazhLRTg ) seem to
confirm langid_fix value (0409).

On the other side, the problem seems to be due to some differences in
command string numbering or their prefix:

[nut actual blazer_usb code snippet:]

static int krauler_command(const char *cmd, char *buf, size_t buflen)
{
      /*       * Still not implemented:       * 0x6      T<n>  (don't
know how to pass the parameter)       * 0x68 and 0x69 both cause
shutdown after an undefined interval      */
      const struct {
            const char  *str;       /* Megatec command */
            const int   index;      /* Krauler string index for this command */
            const char  prefix;     /* character to replace the first
byte in reply */
      }  command[] = {
            { "Q1\r", 0x03, '(' },
            { "F\r",  0x0d, '#' },
            { "I\r",  0x0c, '#' },
            { "T\r",  0x04, '\r' },
            { "TL\r", 0x05, '\r' },
            { "Q\r",  0x07, '\r' },
            { "C\r",  0x0b, '\r' },
            { "CT\r", 0x0b, '\r' },
            { NULL }
      };


TL (0x05) or CT (0x0b) code seems not to be used in the relative
sniffed file and 0x07 (Q in nut coding) seems to be related to "UPS No
Ack" string).


Unfortunately I could only capture a few commands before leaving homr and
right now I have no access to the UPS from windows to complete the
sniffing, but I can still try nut (and any patch) in linux through remote
shell.
If anyone who knows more about Megatec driver or has any hints, he's more
than welcome.

Thanks in advance,
Rob

-------------------------------


Settings:

[ERA_LCD]
     driver = blazer_usb
     subdriver = krauler
     langid_fix=0x409
     port = /dev/bus/usb/002/002
     vendorid = 0001
     productid = 0000
     desc = "Tecnoware UPS ERA 0.8"

port was setted according to lsusb output:
$ lsusb
[...]
Bus 002 Device 002: ID 0001:0000 Fry's Electronics
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20130108/13609026/attachment.html>
-------------- next part --------------
$ sudo ./drivers/blazer_usb -a ERA_LCD -u root -DDDDD -q

Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5)
   0.000000     debug level is '5'
   0.002536     language ID workaround enabled (using '0x4095')
   0.173506     Checking device (1D6B/0001) (005/001)
   0.173652     - VendorID: 1d6b
   0.173667     - ProductID: 0001
   0.173678     - Manufacturer: Linux 3.2.0-35-generic-pae uhci_hcd
   0.173691     - Product: UHCI Host Controller
   0.173703     - Serial Number: 0000:00:10.3
   0.173714     - Bus: 005
   0.173725     Trying to match device
   0.173766     Device does not match - skipping
   0.173795     Checking device (1D6B/0001) (004/001)
   0.173848     - VendorID: 1d6b
   0.173862     - ProductID: 0001
   0.173873     - Manufacturer: Linux 3.2.0-35-generic-pae uhci_hcd
   0.173902     - Product: UHCI Host Controller
   0.173913     - Serial Number: 0000:00:10.2
   0.173925     - Bus: 004
   0.173936     Trying to match device
   0.173950     Device does not match - skipping
   0.173969     Checking device (1D6B/0001) (003/001)
   0.174020     - VendorID: 1d6b
   0.174033     - ProductID: 0001
   0.174044     - Manufacturer: Linux 3.2.0-35-generic-pae uhci_hcd
   0.174057     - Product: UHCI Host Controller
   0.174068     - Serial Number: 0000:00:10.1
   0.174079     - Bus: 003
   0.174090     Trying to match device
   0.174104     Device does not match - skipping
   0.174121     Checking device (0001/0000) (002/002)
   0.181800     - VendorID: 0001
   0.182344     - ProductID: 0000
   0.182684     - Manufacturer: unknown
   0.182999     - Product: unknown
   0.183255     - Serial Number: unknown
   0.183508     - Bus: 002
   0.183779     Trying to match device
   0.184084     Device matches
   0.187746     send_to_all: SETINFO ups.vendorid "0001"
   0.188120     send_to_all: SETINFO ups.productid "0000"
   0.191756     send_to_all: SETINFO device.type "ups"
   0.191993     send_to_all: SETINFO driver.version "2.6.5"
   0.192103     send_to_all: SETINFO driver.version.internal "0.09"
   0.192224     send_to_all: SETINFO driver.name "blazer_usb"
   0.192270     Trying megatec protocol...
   0.192384     send: Q1
   0.195773     read: error sending control message: Protocol error
   0.196029     blazer_status: short reply
   0.196145     Status read 1 failed
   0.196188     send: Q1
   0.199758     read: error sending control message: Protocol error
   0.200006     blazer_status: short reply
   0.200049     Status read 2 failed
   0.200168     send: Q1
   0.203763     read: error sending control message: Protocol error
   0.204019     blazer_status: short reply
   0.204136     Status read 3 failed
   0.204178     Trying mustek protocol...
   0.204218     send: QS
   0.204336     read: QS
   0.204414     blazer_status: short reply
   0.204526     Status read 1 failed
   0.204630     send: QS
   0.204670     read: QS
   0.204774     blazer_status: short reply
   0.204815     Status read 2 failed
   0.204932     send: QS
   0.204972     read: QS
   0.205077     blazer_status: short reply
   0.205118     Status read 3 failed
   0.205225     Trying megatec/old protocol...
   0.205267     send: D
   0.205305     read: D
   0.205706     blazer_status: short reply
   0.205932     Status read 1 failed
   0.205977     send: D
   0.206016     read: D
   0.206131     blazer_status: short reply
   0.206171     Status read 2 failed
   0.206273     send: D
   0.206319     read: D
   0.206357     blazer_status: short reply
   0.206461     Status read 3 failed
   0.206501     Trying zinto protocol...
   0.206610     send: Q1
   0.210744     read: error sending control message: Protocol error
   0.210953     blazer_status: short reply
   0.211064     Status read 1 failed
   0.211107     send: Q1
   0.214756     read: error sending control message: Protocol error
   0.215004     blazer_status: short reply
   0.215122     Status read 2 failed
   0.215166     send: Q1
   0.218756     read: error sending control message: Protocol error
   0.219004     blazer_status: short reply
   0.219120     Status read 3 failed
   0.219161     No supported UPS detected

On Jan 7, 2013, at 8:27 PM, Rob Power wrote:
> TL (0x05) or CT (0x0b) code seems not to be used in the relative sniffed
file and 0x07 (Q in nut coding) seems to be related to "UPS No Ack"
string).
If I'm reading drivers/blazer_usb.c correctly, "UPS No Ack" causes
the read loop to retry (up to 10 times). This is similar to the USB-to-serial
converter code in tripplite_usb.c, where it looks to make sure that the received
buffer differs from what was sent the last time. But it's possible that this
UPS doesn't use Q, just Q1 (string index 3, which does return a somewhat
normal-looking buffer).

                { "test.battery.start.deep", "TL\r" },
                { "test.battery.start.quick", "T\r" },
                { "test.battery.stop", "CT\r" },

Looks like TL and CT are for battery testing.

I hate to nitpick about log.txt, but it appears to have the results from the
original langid_fix setting (0x4095) instead of 0x409. Could you please capture
and send that again? Using -DDDDD worked well. (I remember you said it
didn't work, but we're looking for any small differences in the output
that might narrow down where the problem lies.)
> port was setted according to lsusb output:
> $ lsusb
> [...]
> Bus 002 Device 002: ID 0001:0000 Fry's Electronics
> 
Actually, for the USB drivers in NUT, the port setting is ignored (although the
NUT core needs some value, so we usually use 'auto'). The matching is
done by the numeric USB VID:PID combination.

What does 'lsusb -vvv -d 0001:0000' return?

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20130108/e9e686ca/attachment.html>