Skip to content

Ragtech Driver: can't communicate with Easy Way 1500 GT #3755

Open

Description

@pedroaugustosmribeiro

On Fedora 44, using standard RPM package nut 2.8.5 from OS repo and source compiled Ragtech 0.10 driver from latest master.

Device Information

  • Manufacturer: Ragtech Sistemas de Energia
  • Model: Easy Way 1500VA GT. not Pro.
  • Firmware: bcdDevice 1.00
  • USB VID/PID: 04d8:000a
  • Manufacturer: Ragtech Sistemas de Energia
  • Product: USB Serial Port
  • Port: /dev/ttyACM0

I took a glance at #3500 , so I guess maybe this model uses a different mapping of the bytes, but I'm not a low level programmer, it's beyond my current knowledge.

I can take a few more info from Fedora 44 and Windows 11 communicating with this model, if it helps.

Activity

  1. pedroaugustosmribeiro commented on Oct 20, 2026

    @pedroaugustosmribeiro
    Author

    Example of hex monitoring at 4800 baud 8N1 using VS Code serial monitor in raw hex mode on Windows 11, with Supervise services off:

    66 e6 66 e6 f8 e6 9e 80 fe 80 e6 f8 20 26 fe 18
    f8
    ce f8 e6 00 18 f8 1e 00 f8 1e fe 00 e0 00 00 60
    1e
    78 fe 3e fe 1e 06 00 1e fe fe c0 06 e0 20 f8 86
    c0
    38 fe 66 e6 66 e6 f8 e6 9e c0 fe c0 e6 f8 20 26
    fe 18
    f8
    9e f8 e6 00 18 f8 1e 00 f8 1e 00 e0 00 00 60 1e
    7e
    fe 3e fe 1e f8 fe 00 20 3e 80 06 e0 66 f8 86 80
    78
    26 e6 26 e6 f8 e6 9e c0 fe c0 e6 f8 20 26 fe 18
    f8 ce
    f8
    e6 00 18 f8 1e 00 f8 1e fe 00 e0 00 00 60 1e 78
    3e
    9e 1e 38 00 1e fe fe 06 e0 20 f8 86 c0 9e fe 66
    e6 26 e6 f8 e6 9e c0 fe c0 e6 f8 20 26 3e e0 f8
    ce f8
    e6
    00 18 f8 00 00 f8 06 fe e0 00 00 60 1e 78 fe 7e
    fe
    1e 18 00 60 7e 80 06 e0 26 f8 86 c0 3e fe

  2. added
    Incorrect or missing readingsOn some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.)
    impacts-release-2.8.5Issues reported against NUT release 2.8.5 (maybe vanilla or with minor packaging tweaks)
    RagtechDevices made by Ragtech Sistemas de Energia
    on Oct 21, 2026
  3. jimklimov commented on Oct 21, 2026

    @jimklimov
    Member

    CC @juslex : would you please have time to look at this?

  4. added this to the 2.8.7 milestone on Oct 21, 2026
  5. juslex commented on Oct 21, 2026

    @juslex
    Contributor

    Hi @pedroaugustosmribeiro, thanks for the report and the dump.

    A first reading: the ragtech driver currently speaks only the request/response protocol of the Easy Pro line ("family 10"): the UPS stays silent until the driver sends a 6-byte 0xAA ... read command. Your dump looks different in two ways:

    1. The unit seems to transmit on its own, with a frame of roughly 52 bytes that repeats (66 e6 66 e6 f8 e6 9e ... comes back on every cycle).
    2. The bytes look like a baud-rate mismatch (lots of f8, fe, e6, 1e, 80, c0, e0). On the Easy Pro the PIC runs the CDC firmware itself and the baud rate is cosmetic, but on your Easy Way the PIC may be a USB-to-UART bridge in front of another MCU, in which case the line speed does matter.

    So the Easy Way is most likely a different protocol family, not just a missing model entry. To tell for sure, could you collect the following? Please do not set allow_shutdown and do not send any command to the UPS while testing; passive listening is enough for now.

    On Linux

    • lsusb -v -d 04d8:000a
    • The same passive capture at 2400, 9600 and 19200 baud (8N1), each for 10-20 seconds, plus a note of which tool and settings you used. We are looking for the speed at which the frame becomes stable and readable, e.g. always starting with the same byte. For example:
      stty -F /dev/ttyACM0 9600 raw -echo
      timeout 15 cat /dev/ttyACM0 | xxd > easyway-9600.txt
      
    • A driver debug run, so we can see whether the unit answers the Easy Pro commands at all:
      ragtech -DDDDD -a <your-ups-name> 2>&1 | head -200
      
      together with the ups.conf section you used.

    On Windows (this is the most valuable part)

    • The name and version of the Ragtech software you use (Supervise, or something else).
    • The file devices.xml (or similar XML) from its installation folder. For the Easy Pro, that file describes the register map and scaling, and it may tell us which family the Easy Way belongs to.
    • If you can, a USB capture with USBPcap + Wireshark while the vendor software is running and showing readings, saved as .pcapng. Please also note the readings shown on screen at the time of the capture (input/output voltage, load %, battery %), so we can match bytes to values. This is exactly what made the Easy Pro support possible in Ragtech driver: Easy Pro 3200VA GT CBU-TI — no reply to initial status poll #3500.

    With that we can see whether the Easy Way can be added to ragtech as a second family or needs its own code path.

  6. pedroaugustosmribeiro commented on Oct 23, 2026

    @pedroaugustosmribeiro
    Author

    Output of lsubs -v -d 04d8:000a:

    Bus 001 Device 005: ID 04d8:000a Microchip Technology, Inc. CDC RS-232 Emulation Demo
    Negotiated speed: Full Speed (12Mbps)
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            2 Communications
      bDeviceSubClass         0 [unknown]
      bDeviceProtocol         0 
      bMaxPacketSize0         8
      idVendor           0x04d8 Microchip Technology, Inc.
      idProduct          0x000a CDC RS-232 Emulation Demo
      bcdDevice            1.00
      iManufacturer           1 Ragtech Sistemas de Energia
      iProduct                2 USB Serial Port
      iSerial                 0 
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength       0x0043
        bNumInterfaces          2
        bConfigurationValue     1
        iConfiguration          0 
        bmAttributes         0xc0
          Self Powered
        MaxPower              100mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0 
          CDC Header:
            bcdCDC               1.10
          CDC ACM:
            bmCapabilities       0x02
              line coding and serial state
          CDC Union:
            bMasterInterface        0
            bSlaveInterface         1 
          CDC Call Management:
            bmCapabilities       0x00
            bDataInterface          1
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0008  1x 8 bytes
            bInterval               2
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass        10 CDC Data
          bInterfaceSubClass      0 [unknown]
          bInterfaceProtocol      0 
          iInterface              0 
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x03  EP 3 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x83  EP 3 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               0
    Device Status:     0x0001
      Self Powered
  7. pedroaugustosmribeiro commented on Oct 23, 2026

    @pedroaugustosmribeiro
    Author

    In attachment, files for baud rates 9600 and 19200, 2400 came empty.
    Used stty for configuring baud rates stty -F /dev/ttyACM0 RATE raw -echo
    Captured with cat and translated with xxd, as sugested: timeout 15 cat /dev/ttyACM0 | xxd > easyway-RATE.txt

    My ups.conf on Fedora 44 KDE (kernel 7.2.11-200.fc44.x86_64) is:

    [nobreak]
    driver = ragtech
    port = /dev/ttyACM0
    desc = "Ragtech NEP 1200"

    Output of ragtech -DDD -a nobreak 2>&1 | head -200:

       0.000000     [D3] setproctag: starting first tagging as 'ragtech'...
       0.000012     [D3] getprocname: /proc is an accessible directory, investigating
       0.000019     [D3] getprocname: located symlink for PID 12715 at: /proc/12715/exe
       0.000040     [D1] getprocname: determined process name for PID 12715: /home/pedro/nut/drivers/ragtech
    Network UPS Tools 2.8.5.1466-1466+g73c450219 (development iteration after 2.8.5) - Ragtech UPS driver 0.10
       0.000123     [D3:ragtech] do_global_args: var='maxretry' val='3'
       0.000159     [D3:ragtech] main_arg: var='driver' val='ragtech'
       0.000161     [D3:ragtech] main_arg: var='port' val='/dev/ttyACM0'
       0.000163     [D3:ragtech] main_arg: var='desc' val='Ragtech NEP 1200'
       0.000166     [D1] Network UPS Tools version 2.8.5.1466-1466+g73c450219 (development iteration after 2.8.5), 64-bit build for x86_64, built with gcc (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2) and configured with flags: --prefix=/usr --sysconfdir=/etc/ups --includedir=/usr/include --with-docs=no --libdir=/usr/lib64 --libexecdir=/usr/libexec/nut --with-statepath=/run/nut --with-altpidpath=/run/nut --with-drvpath=/usr/libexec/nut --with-pidpath=/run/nut --datadir=/usr/share/nut --with-user=nut --with-group=nut --with-udev-dir=/usr/lib/udev --with-drivers=ragtech
       0.000169     [D1:nobreak] debug level is '3'
       0.000561     [D1:nobreak] Succeeded to become_user(nut): now UID=57 GID=57
       0.000584     [D1:nobreak] Signalling UPS [nobreak]: driver.exit (quietly, no fuss if no driver is running or responding)
       0.000591     Can't open /run/nut/ragtech-nobreak: No such file or directory
       0.000592     [D1:nobreak] Request for other driver to exit returned code -1
       0.000593     [D1:nobreak] Socket dialog with the other driver instance (may be absent) failed: Success
       1.257320     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       1.257342     [D1:nobreak] initial status poll attempt 1/10 got no reply
       2.538057     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       2.538079     [D1:nobreak] initial status poll attempt 2/10 got no reply
       3.825146     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       3.825167     [D1:nobreak] initial status poll attempt 3/10 got no reply
       5.105721     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       5.105743     [D1:nobreak] initial status poll attempt 4/10 got no reply
       6.384656     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       6.384676     [D1:nobreak] initial status poll attempt 5/10 got no reply
       7.673656     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       7.673678     [D1:nobreak] initial status poll attempt 6/10 got no reply
       8.951643     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
       8.951665     [D1:nobreak] initial status poll attempt 7/10 got no reply
      10.236645     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
      10.236670     [D1:nobreak] initial status poll attempt 8/10 got no reply
      11.514752     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
      11.514776     [D1:nobreak] initial status poll attempt 9/10 got no reply
      12.804155     [D2:nobreak] ragtech_read(0x0080,30): short RX (0/30)
      12.804176     [D1:nobreak] initial status poll attempt 10/10 got no reply
      13.004318     no reply to initial status poll -- is the UPS connected and not held by another program (e.g. Ragtech supsvc)?
      13.005810     [D3:nobreak] procname_cleanup: starting for: myProcName=[/home/pedro/nut/drivers/ragtech] myProcBaseName=[ragtech] proctag=[nobreak] proctag_lib=[(null)]
      13.005834     [D3:nobreak] proctag_cleanup:  starting for: myProcName=[/home/pedro/nut/drivers/ragtech] myProcBaseName=[ragtech] proctag=[nobreak] proctag_lib=[(null)]
      13.005842     [D2:nobreak] a ragtech sub-process (nobreak) is exiting now
      13.005856     upsnotify: notify about state NOTIFY_STATE_STOPPING with libsystemd: was requested, but not running as a service unit now, will not spam more about it
      13.005862     [D1] On systems without service units, consider `export NUT_QUIET_INIT_UPSNOTIFY=true`
      13.005866     [D1] upsnotify: failed to notify about state NOTIFY_STATE_STOPPING: no notification tech defined, will not spam more about it
      13.005877     [D1] sock_close: starting...
      13.005881     [D1] sock_close: finished
      13.005885     [D1] exit_cleanup: finished, exiting
    Warning: This is an experimental driver.
    Some features may not function correctly.
    

    easyway-9600.txt
    easyway-19200.txt

  8. pedroaugustosmribeiro commented on Oct 23, 2026

    @pedroaugustosmribeiro
    Author

    In attachment, devices.xml from Windows 11 Supervise 8.9.7 installation folder, downloaded from https://ragtech.com.br/downloads/softwares-supervise-beta/ and captures with Wireshark + usbpcap and Supervise log

    devices.xml

    supervise_log_easywat_1500gt.csv

    easyway1500gt.pcapng

  9. juslex commented on Oct 23, 2026

    @juslex
    Contributor

    Thanks a lot, @pedroaugustosmribeiro, this was exactly what was needed. Here is what the data shows.

    Your unit is a different protocol family. In the Supervise devices.xml, the Easy Way line is family 14 ("NEW/QUADRI"), with 21 models (EASY WAY-TI/M1/M2, 500 to 1600 VA). The ragtech driver currently implements only family 10 (Easy Pro). Your unit reports model byte 0x0F = EASY WAY-TI 1400, which is probably sold as the 1500 VA model.

    It pushes data on its own, at 2400 baud 8N1. In your USB capture, Supervise never sends a single byte to the UPS. The UPS sends a 32-byte frame by itself, about every 1.28 s:

    55 55 AE | 27 data bytes (registers 0x00..0x1A) | 09 | CS
    55 55 ae 0b 0f 9d 84 75 e2 6e ae 00 22 c3 30 e3 10 00 00 04 03 74 b6 03 e3 00 73 0f 11 37 09 f8
    

    CS is the 8-bit sum of the 31 preceding bytes, and it checks out on all 24 frames in the capture. The 27 data bytes match the family 14 register map in the XML. Decoding them with the XML formulas gives the same values as your Supervise CSV at the same timestamps: 122.3 V in, 106.0 V out, 59.6 Hz, 12 % load, 13.6 V battery, temperature 55. Your first dump at 4800 baud was this same frame read at twice the line speed; simulating that reproduces your bytes exactly. So on this model the line speed matters, unlike on the Easy Pro.

    This means the Easy Way can most likely be supported inside ragtech as a second, read-only family. The XML defines no shutdown action for family 14 and the capture shows no command being sent, so shutdown support would stay off.

    Two more tests would close the remaining gaps. As before, please don't send anything to the UPS; listening is enough.

    1. Listening at 2400 baud, configuring and reading the port in one go

    Your 2400 capture came back empty, probably because stty and cat each opened the port separately, so the setting may not have stuck. This keeps the port open across both steps (stop any other program using the port first):

    ( stty 2400 cs8 -parenb -cstopb raw -echo -hupcl; timeout 15 xxd ) < /dev/ttyACM0 > easyway-2400.txt
    

    If it works, we should see lines starting with 55 55 ae.

    2. A short power cut, to see the "on battery" flags

    None of the on-battery, low-battery or fault bits changed in the capture, because the UPS was on mains the whole time. Could you record a short outage?

    • Keep only a small load on the UPS.
    • Start the capture: either the Linux command above with timeout 120, or USBPcap + Supervise logging on Windows as before.
    • About 20 s after starting, unplug the UPS from the wall for about 30-40 s, then plug it back in. Please don't let it run until low battery.
    • Note the times you unplugged and replugged it, and attach the capture (plus the Supervise CSV, if you used Windows).

    If your UPS beeps or shows anything during that time, a note on that helps too.

  10. pedroaugustosmribeiro commented on Oct 23, 2026

    @pedroaugustosmribeiro
    Author

    Here we go, when it was unplugged it beeped within several seconds interval.
    Unplugged 15:26:10 (UTC -3)
    Re-plugged 15:27:03

    supervise_log_easy_way_1500_gt_online_offline_online_test.csv

    easyway1500gt_online_offline_online_test.pcapng

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Incorrect or missing readingsOn some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.)RagtechDevices made by Ragtech Sistemas de EnergiaUSBimpacts-release-2.8.5Issues reported against NUT release 2.8.5 (maybe vanilla or with minor packaging tweaks)

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions