You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ragtech Driver: can't communicate with Easy Way 1500 GT #3755
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.
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
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:
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).
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:
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.
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:
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, exitingWarning: This is an experimental driver.Some features may not function correctly.
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:
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):
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.
Activity
pedroaugustosmribeiro commentedon Oct 20, 2026
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
jimklimov commentedon Oct 21, 2026
CC @juslex : would you please have time to look at this?
juslex commentedon Oct 21, 2026
Hi @pedroaugustosmribeiro, thanks for the report and the dump.
A first reading: the
ragtechdriver currently speaks only the request/response protocol of the Easy Pro line ("family 10"): the UPS stays silent until the driver sends a 6-byte0xAA ...read command. Your dump looks different in two ways:66 e6 66 e6 f8 e6 9e ...comes back on every cycle).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_shutdownand do not send any command to the UPS while testing; passive listening is enough for now.On Linux
lsusb -v -d 04d8:000aups.confsection you used.On Windows (this is the most valuable part)
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..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
ragtechas a second family or needs its own code path.pedroaugustosmribeiro commentedon Oct 23, 2026
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 Poweredpedroaugustosmribeiro commentedon Oct 23, 2026
In attachment, files for baud rates 9600 and 19200, 2400 came empty.
Used stty for configuring baud rates
stty -F /dev/ttyACM0 RATE raw -echoCaptured with cat and translated with xxd, as sugested:
timeout 15 cat /dev/ttyACM0 | xxd > easyway-RATE.txtMy 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:easyway-9600.txt
easyway-19200.txt
pedroaugustosmribeiro commentedon Oct 23, 2026
In attachment,
devices.xmlfrom 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 logdevices.xml
supervise_log_easywat_1500gt.csv
easyway1500gt.pcapng
juslex commentedon Oct 23, 2026
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). Theragtechdriver currently implements only family 10 (Easy Pro). Your unit reports model byte0x0F=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:
CSis 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
ragtechas 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
sttyandcateach 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):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?
timeout 120, or USBPcap + Supervise logging on Windows as before.If your UPS beeps or shows anything during that time, a note on that helps too.
pedroaugustosmribeiro commentedon Oct 23, 2026
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