Repository navigation
Conversation
The Easy Way line (OEM device table family 14, "NEW/QUADRI", 21 models EASY WAY-TI/M1/M2 500..1600) shares the USB ids of the Easy Pro but speaks a different protocol: the UPS pushes, unasked, a 32-byte frame (55 55 AE, 27 registers, one tail byte, 8-bit sum) about every 1.3 s, and the PIC applies the line coding, so the port must really run at 2400 baud. Captures of the OEM software, including a mains cut and return, show no bulk OUT traffic at all, and the OEM table lists no actions for this family. Decode it without ever writing to the UPS: keep a small window of the newest received bytes, take the newest frame whose sync bytes and sum check out (the tail byte is not constant, so it is not tested), convert with the OEM formulas and publish voltages, frequency, load, battery voltage and charge, temperature, status (OL/OB, CHRG, LB, OVER) and ups.alarm. No instant commands are registered and upsdrv_shutdown fails; allow_shutdown is ignored with a warning. No valid frame for more than 5 s marks the data stale. A new ups.conf option "family" (auto, 10, 14) selects the protocol. In "auto", the default, the driver first listens for a few seconds, writing nothing, for a family 14 frame; if none shows up it restores the termios it had before the 2400 baud change and goes on with the family 10 poll as before. With family=10 the port is not touched beyond what earlier versions did. Driver version 0.10 -> 0.11. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: juslex <66561713+juslex@users.noreply.github.com>
Add the "family" option, a section on the read-only family 14 behaviour (push-only frames, 2400 baud, no commands, what was observed on hardware versus what is only inferred from the OEM bit names), list the 21 Easy Way models in data/driver.list.in, add a NEWS entry, and teach the spell-check dictionary the word QUADRI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: juslex <66561713+juslex@users.noreply.github.com>
|
Thank you for the quick support, I will test on Monday, as the UPS and computer are on my workplace. |
|
A ZIP file with standard source tarball and another tarball with pre-built docs for commit f4cfbf2 is temporarily available: NUT-tarballs-PR-3798.zip. |
jimklimov
added
enhancement
USB
serial port
Ragtech
|
It's working properly, thank you very much, see issue for the detailed test logs |
The Easy Way UART transmits at 2560 baud, the first speed listed for the family in the OEM devices.xml, not 2400. Read at 2400 the receiver samples bit 6 on the bit 6 / bit 7 boundary of the transmitter and bit 7 inside the stop bit, so bit 7 arrives set and bit 6 is unreliable: most frames failed the checksum and a few corrupted ones passed it, because the 8-bit sum does not notice two bytes that both gain bit 7. A real unit then showed ups.load 385, a 180 C temperature and an "Inverter fault". * New drivers/ragtech_speed.c sets an arbitrary speed: termios2 + BOTHER on Linux (kept in a file of its own, because <asm/termbits.h> cannot be included together with <termios.h>), a numeric speed_t on the BSDs and macOS. If it fails, the driver warns and falls back to 2400. The termios state is restored exactly on the auto -> family 10 path. * A frame is accepted only if registers 0x00..0x09 equal a reference confirmed by two consecutive checksum-valid frames (a new reference is allowed after 30 s of mismatches), and ACTUALTAP <= 3, load <= 150 %, temperature <= 100 C and battery voltage within 6..18 V. * ups.alarm (reg 0x0E bits 4..7), OVER and LB need two consecutive accepted frames to appear or to disappear. OL/OB/CHRG are not debounced. * Every checksum-valid frame in the receive window is now examined in order (not only the newest), and the first-frame wait goes from 10 to 15 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: juslex <66561713+juslex@users.noreply.github.com>
They are printed with %u; clang -Wformat (fatal in CI) rejected the int constants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: juslex <66561713+juslex@users.noreply.github.com>
|
✅ Build nut 2.8.5.5925-master completed (commit 793f88f620 by @juslex)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds read-only support for the Ragtech Easy Way units to
ragtech, as a second protocol family ("family 14", "NEW/QUADRI" in the OEM device table, 21 models). Closes #3755 once confirmed on hardware.Background
The Easy Way uses the same USB ids as the Easy Pro (
04d8:000a, CDC-ACM), but a different protocol. It does not answer the family 10 polls; instead it pushes, on its own, a 32-byte frame about every 1.3 s at 2400 baud 8N1:CSis the 8-bit sum of the 31 preceding bytes. The tail byte is not constant (0x09 on mains, 0x08 on battery), so the driver relies on the sync bytes plus the sum only. Unlike family 10, the PIC does apply the line coding here, so the port has to be at 2400.All of this comes from data that @pedroaugustosmribeiro collected in #3755: the Supervise 8.9.7
devices.xml, two USBPcap captures of the vendor software (one on mains, one with a mains cut and restore) and the matching Supervise CSV logs. The vendor software never sends anything to these units: there is no bulk OUT at all in either capture.What the change does
ups.confoptionfamily=auto(default) |10|14.autofirst listens passively at 2400 baud for up to 3 s, writing nothing. If a valid family 14 frame arrives, the unit is treated as family 14. Otherwise the termios state saved before the speed change is restored, DTR/RTS are forced low again, and the family 10 path runs as before.family=10skips the listen and leaves the port exactly as 0.10 did (recommended for existing Easy Pro setups, to avoid the ~3 s start-up delay).family=14requires the Easy Way protocol (recommended for Easy Way owners).static f14_*functions with its own model table. The family 10 code only gained the dispatch points.upsdrv_shutdownfails, andallow_shutdownis ignored with a warning. No write command is known for this family: the OEM table lists no actions for it, and none was seen in the captures.ups.mfr,ups.model,ups.firmware,ups.power.nominal,ups.temperature,ups.load,ups.status,ups.alarm,input.voltage(.nominal),output.voltage(.nominal),output.frequency(.nominal),battery.voltage(.nominal)andbattery.charge. The conversions follow the OEM table.driver.list.in(21 models),NEWS.adocandnut.dictupdated. Driver version 0.10 → 0.11.What was verified, and what was not
OL→OB→OLfollow the mains cut, using the firmware's on-battery flag (0x10bit 3), which the "no input" flag confirms. Resync cases were also exercised: starting mid-frame, a corrupted byte, back-to-back frames, buffer overflow and a false sync.CHRG(on mains with the battery-full flag clear; it stays clear for the whole recharge after the cut),LB,OVERand everyups.alarmentry.BOOST/TRIMand the beeper are not reported.sttyandcatas separate processes and came back empty, which is probably a tooling artefact; the driver sets the speed on the same open descriptor it reads from. @pedroaugustosmribeiro, a run withfamily = 14and-DDDDD(theRX14hex lines) would confirm it.clang -fsyntax-only -Wall -Wextra, C89-style declarations). CI will be the first full build.Note on other open PRs
#3716 (runtime model) and #3795 (
iout_caliboverride) also touchdrivers/ragtech.cand the driver version, so whichever lands later will need a rebase. I'm happy to do it on my side.🤖 Generated with Claude Code