Ragtech driver: Easy Pro 3200VA GT CBU-TI — no reply to initial status poll

[LanayAlves]

Device Information

• Manufacturer: Ragtech Sistemas de Energia
• Model: Easy Pro 3200VA GT CBU-TI
• Firmware: bcdDevice 1.00
• USB VID/PID: 04d8:000a
• iManufacturer: Ragtech Sistemas de Energia
• iProduct: USB Serial Port
• USB Speed: Full Speed (12Mbps)
• Port: /dev/ttyACM0

System

• OS: Debian Trixie (Linux 6.18.33 aarch64)
• Hardware: Raspberry Pi 4 Model B 8GB
• NUT version: 2.8.5.534 (built from source, commit 9b8e1c0)

ups.conf

[easyPro]
    driver = ragtech
    port = /dev/ttyACM0
    desc = "Ragtech Easy Pro 3200VA"

Serial port settings

speed 9600 baud; cs8; hupcl; clocal; -crtscts

icrnl ixon; opost onlcr

strace analysis

The driver sends handshake and poll correctly but receives no response:
write(4, "\xff\xfe\x00\x8e\x01\x8f", 6) ← handshake sent
ioctl(4, TCFLSH, TCIOFLUSH) ← buffer flushed
write(4, "\xaa\x04\x00\x80\x1e\x9e", 6) ← poll sent
ioctl(4, TCSBRK, 1) ← drain
→no read() from UPS follows ← no response

Observation

The TCFLSH/TCIOFLUSH after the handshake may be discarding the
UPS response before it is read. The UPS works correctly with
Ragtech Supervise 8 on Windows (confirmed via exported CSV log
showing voltage ~120V, frequency 59.6Hz, battery ~26.7V,
temperature ~48°C, load ~11%).

Increasing RAGTECH_POST_OPEN_MS from 200ms to 3000ms did not help.

Question

Is TCIOFLUSH intentional after the handshake? Could it be
discarding the UPS reply on this model? Would it be possible
to test with TCIFLUSH (input only) or removing the flush
before the read?

[jimklimov]

Thanks for the report/question. CCing @juslex - deferring to contributor of the driver.

[juslex]

Hey, thanks for the careful writeup, the strace breakdown is more useful than most issue reports get.

Quick context: family 10 (Easy Pro 600..2200 TI/M2 in our model table) lets us send the handshake and then the first read without consuming any reply, the firmware doesn't seem to care that we discard whatever it sent back. The OEM Supervise tool does basically the same on those units, which is why the flush in ragtech_read is intentional but only verified against family 10. Your unit is a 3200VA GT, which isn't in the table and the "GT" badge isn't something I've seen before. Could easily be a different family with different protocol expectations.

Your hypothesis is plausible. To narrow it down without needing Windows, I put together a small probe script that bypasses the flush between handshake and read, so any reply the firmware sends to the handshake will show up. It only sends read opcodes (0x04), so it can't change UPS state, and it writes a self-contained log file (with your uname/lsusb/stty details prepended) that you can attach here:

https://gist.github.com/juslex/90f43a26fb17f11ef85fa6acd1cbdcf5

sudo systemctl stop nut-driver
sudo apt install python3-serial
wget https://gist.githubusercontent.com/juslex/90f43a26fb17f11ef85fa6acd1cbdcf5/raw/ragtech-probe.py
sudo python3 ragtech-probe.py /dev/ttyACM0

How to read the output:

• If step 2 returns 2 bytes (aa XX), XX is your model ID byte. Family-10 framing works on your unit and the table is just missing your model, which is an easy fix.
• If step 4 returns 31 bytes, the full main range works too, even better.
• If only step 1 returns bytes and 2/3/4 don't, the handshake reply contains something the firmware expects us to consume before the next commands work, the log will show what came back and we'll figure it out.
• If everything returns (nothing), your firmware speaks a different protocol entirely and we'd need a USBPcap of Supervise 8 to move forward. That's how family 10 got reverse engineered originally, so there's precedent.

Just attach the generated ragtech-probe-<timestamp>.log here and we'll dig in. Worth keeping the issue open either way — at minimum the driver should give a better error than "no reply to initial status poll" when the UPS isn't a family-10 model.

[LanayAlves]

I'm happy to be able to contribute meaningfully to the project. Please find the attached probe log.
The results confirm that the Easy Pro 3200VA GT firmware replies to the handshake with ca ca before accepting any further commands. The TCIOFLUSH executed right after the handshake in the current driver discards this reply, causing the firmware to ignore all subsequent commands. Once the flush was removed — or replaced with TCIFLUSH after consuming the handshake reply — all 4 probe steps worked correctly, including the full 30-byte main range read.
Additional findings that may help:

Model ID byte: 0x12 (from step 2, register 0x9A)
Baud rate: The Linux kernel enumerates the port at 9600 baud. A Brazilian community member who reverse-engineered the protocol via USB sniffing on Windows uses 2400 baud in their Node-RED implementation and reports success. It is unclear whether the CDC-ACM layer ignores baud rate at the wire level or if this matters for other models.
Full 30-byte main range response: aa 21 00 0c 49 ff ff ff ff 00 ca c9 6f 10 0e 30 72 00 00 03 82 c2 03 a8 3d 00 70 12 0a 00 d7
Reference community implementation: https://community.home-assistant.io/t/home-assistant-ragtech-nobreak-easy-pro-ups-monitoring/678828

ragtech-probe.log

[juslex]

Olá @LanayAlves tudo bem? primeiramente, eu não sou desenvolvedor, apenas um curioso e entusiasta de tecnologia e um usuário de home assistant desde 2020. Com ajuda do claude code, consegui fazer uma engenharia reversa para construir o drive. Após teu issue, pedi para o claude analisar e testamos a solução, como na minha máquina estava tudo ok, pedi para ele subir o fix e o drive está ok aqui. Acredito que você seja da área de TI, de todo modo, segue um workflow para tu baixar meu fix e poder testar ai, caso dê certo, avisa aqui para podemos sinalizar para o @jimklimov fazer o merge do PR.

Hello @LanayAlves, how are you? First of all, I'm not a developer, just a curious and technology enthusiast and a home assistant user since 2020. With the help of Claude Code, I was able to reverse engineer to build the drive. After your issue, I asked Claude to analyze and we tested the solution, as in my machine everything was ok, I asked him to upload the fix and the drive is ok here. I believe you are from the IT area, anyway, here is a workflow for you to download my fix and be able to test it there, if it works, let me know here so we can signal @jimklimov to merge the PR.

git clone --branch feat/ragtech-fixes --single-branch https://github.com/juslex/nut.git nut-fix
cd nut-fix
./autogen.sh
./configure --with-serial --without-usb --without-snmp --without-doc # + flags dela
make -C drivers ragtech

[LanayAlves]

Great news — it works! 🎉
Here's a detailed breakdown of everything we went through to get it running, in case it helps narrow down what needs to be fixed in the driver itself.
Environment

Hardware: Raspberry Pi 4 Model B 8GB
OS: Debian Trixie (Linux 6.18.33 aarch64)
UPS: Ragtech Easy Pro 3200VA GT CBU-TI (USB VID 04d8 / PID 000a)
NUT: built from your feat/ragtech-fixes branch (driver version 0.08)

What i tried before your fix worked
After cloning and building your branch, the driver still failed with no reply to initial status poll. Running strace revealed:
write(4, "\xff\xfe\x00\x8e\x01\x8f", 6) ← handshake sent
ioctl(4, TCSBRK, 1) ← drain
write(4, "\xaa\x04\x00\x80\x1e\x9e", 6) ← poll sent immediately
ioctl(4, TCSBRK, 1) ← drain
→ no read() from UPS ← no response
The handshake drain loop (your ser_get_buf fix) was exiting immediately without receiving the ca ca reply, causing the poll to be sent before the UPS was ready.
Root cause
Checking stty -a on /dev/ttyACM0 showed the port was in canonical mode (icanon):
isig icanon iexten echo echoe echok ...
In canonical mode, the Linux kernel buffers incoming data until it receives a newline character. Since the UPS sends raw binary bytes (ca ca), no newline ever arrives and the kernel never delivers those bytes to ser_get_buf — so the drain loop always timed out empty-handed, and the poll was sent while the UPS firmware was still busy transmitting its handshake reply.
The fix
Setting the port to raw mode before starting the driver solved it completely:
bashstty -F /dev/ttyACM0 raw -echo -echoe -echok -echoctl -echoke
upsdrvctl -u root start
After that, upsc easyPro@localhost returned full data:
battery.charge: 100.0
battery.voltage: 26.80
battery.voltage.nominal: 24
device.mfr: Ragtech
device.model: Easy 2200 TI
input.voltage: 116.6
output.frequency: 59.64
output.voltage: 116.6
ups.load: 23.2
ups.status: OL
ups.temperature: 48
What this means for the driver
The driver should set the port to raw mode itself during upsdrv_initups(), before sending the handshake. Something like:
cstruct termios tio;
tcgetattr(upsfd, &tio);
cfmakeraw(&tio);
tcsetattr(upsfd, TCSANOW, &tio);
This would make the fix transparent to users without requiring manual stty intervention.
Regarding the original comment in the driver that says "NEVER call tcsetattr (it pulses DTR and the UPS interprets that as a shutdown signal on some Ragtech families)": i did not observe any unintended shutdown or DTR pulse when calling tcsetattr with cfmakeraw during my tests. However, this should be verified carefully on other models before landing in the driver. Clearing HUPCL explicitly before the tcsetattr call may be the safest approach to avoid any risk of DTR pulsing:
cstruct termios tio;
tcgetattr(upsfd, &tio);
cfmakeraw(&tio);
tio.c_cflag &= ~HUPCL;
tcsetattr(upsfd, TCSANOW, &tio);
Additional notes
I also commented out the two ser_flush_io(upsfd) calls inside ragtech_read and ragtech_write_reg during our debugging process. It is unclear whether this was strictly necessary for the fix or whether raw mode alone was sufficient. If helpful, i can revert those changes and retest in isolation to identify the exact minimal fix required.
The model was identified as Easy 2200 TI — the 3200VA GT likely shares the same firmware family, just with a higher power rating.
RAGTECH_INTER_CMD_MS was raised to 500ms and ser_get_buf timeout was changed to 1 second during our debugging sessions, but once raw mode was enabled, the original 100ms values would likely work fine. We have not reverted those changes yet.
I'm are happy to run any additional tests or provide further strace output if needed to help land a clean fix upstream.

Hope this provides enough detail to land a clean fix in the driver. Really appreciate the work you put into this — and thank u for the probe script, it was absolutely useful in identifying the protocol behavior

[juslex]

Thank you — you nailed the real root cause. The canonical-mode (icanon) buffering is exactly it: the handshake drain couldn't see the ca ca because the kernel was holding the binary bytes waiting for a newline. On my own test host this was masked because the systemd unit sets stty raw in an ExecStartPre, so the port was already raw when the driver opened it — which is precisely the fragile external dependency you ran into without it.

I've moved the fix into the driver itself (upsdrv_initups now sets raw 8N1 mode, leaving baud untouched, with CLOCAL + ~HUPCL and forcing DTR/RTS low afterwards), so no manual stty is needed anymore. Pushed to the same feat/ragtech-fixes branch (driver 0.09) on PR #3504.

On the tcsetattr/DTR worry in the old comment: you were right not to see a shutdown — NUT's own ser_set_speed() sets raw mode via tcsetattr and ~50 serial drivers use it, and this UPS's shutdown is a register write, not a DTR edge. I kept the explicit DTR/RTS-low call right after as belt-and-suspenders, and cleared HUPCL as you suggested.

If you can pull the updated branch and confirm it now works without the manual stty raw, that closes the loop. No need to revert the ser_flush_io experiments — raw mode is the real fix; those flushes use tcflush and are fine to keep. And for your unit specifically, set va = 3200 in ups.conf to correct the rating (it reports the Easy 2200 TI id). Thanks again — the strace and the probe output made this easy to pin down.

[LanayAlves]

Hey @juslex! Everything worked perfectly as expected — the driver communicated flawlessly with the UPS and all data was being read correctly. The only issue I ran into was getting the automatic startup on boot working reliably with systemd.
Thanks again for the incredibly fast turnaround on the fix — really appreciated!

[LanayAlves]

Just wanted to share some findings that came out of further investigation after getting the driver working.
Unfortunately I ended up uninstalling NUT — at a certain point getting the driver to start automatically on boot became too much of a struggle despite several attempts, and in the process some of my Docker containers ended up freezing. Not worth the risk for a homelab that depends on those services running stably.
So I took a different route: reverse engineering the protocol directly on Windows using Wireshark + USBPcap to capture the raw communication between the Supervise 8 software and the UPS, then mapping the payload manually.
What I found (Easy Pro 3200VA GT, 30-byte main payload at 0x80..0x9D):
Idx 00 (0x80): STATUS FLAGS — 0x21 = operating
Idx 02 (0x82): LOAD % — direct byte value
Idx 04-07: MODE FLAGS — 0xFFFFFFFF = online; byte 07 drops below 0xFF and counts down when on battery
Idx 09-10: BATTERY V — 16-bit Little Endian / 2000 = V (e.g. 0xCED3 = 52947 → 26.47V)
Idx 11 (0x8B): INPUT V — direct byte value (V)
Idx 14 (0x8E): TEMPERATURE — direct byte (°C)
Idx 23 (0x97): FREQUENCY — raw × 0.978 ≈ Hz
Idx 25 (0x99): OUTPUT V — direct byte value (V)
Idx 26 (0x9A): MODEL ID — 0x12 = 3200VA GT
Idx 27-28: CHARGE CTR — rises progressively when recharging after AC is restored
Idx 29 (0x9D): CHECKSUM
Key findings:

Bytes 04-07 are all 0xFF during normal AC operation. The moment AC power is lost, byte 07 drops to a value in the 0xF0-0xFF range and decreases gradually — exact semantics unknown, but it reliably indicates on-battery state — making it a reliable on-battery indicator.
Battery voltage sits at indices 9-10 as a 16-bit LE value divided by 2000. Online readings (~25.5–26.5V) and on-battery readings (~26.2–26.5V) were both confirmed against Supervise 8 CSV logs exported from Windows.
Input voltage is at index 11 as a direct single-byte value in volts.
Indices 27-28 appear to be a charge counter that increments from zero as the battery recharges after AC is restored — not yet fully decoded.
Several bytes remain unknown (indices 03, 09, 12-13, 15, 18-22), but all critical monitoring fields are mapped.

The plan going forward is a lightweight Python script that reads /dev/ttyACM0 directly and publishes via MQTT — no NUT dependency needed. Sharing this in case it helps expand the model table or document the GT family protocol differences.
Thanks again for all the help — the probe script was what made this whole investigation possible!