Release v6.6.4 · alithon/serial-port-utility

6.6.4 (2026-08-21)

云中继（Cloud Relay）——使用另一台计算机上的串口: 现场机器在"云 > 允许云中继"打开开关，操作端在端口列表选择"远端串口 (云中继)"，从账户下在线的计算机中挑一个串口，按下连接后它就像本地串口一样可用：波特率、数据位、校验、停止位、流控与 DTR/RTS 可远程设置，远端 CTS/DSR/RI/DCD 状态同步显示，X/YMODEM 文件传输与 Modbus 照常工作。两端只需能访问互联网，不需要公网地址、端口映射或 VPN。选择对话框会说明每台机器是否在线、是否允许中继；一个串口同一时刻只接受一个中继会话，串口被远程使用时本机会在状态栏提示；链路断开后不会自动重连，需要手动重新连接。中继流量计入账户的云流量额度
桥接端口被远程使用时会提示: 对外提供 RFC 2217 或 TCP 服务的桥接端口，现在会在客户端接入和离开时给出状态消息，面板徽标显示"正被 <客户端> 使用"并变为琥珀色，远程客户端修改串口参数或控制线也会逐条记录——与云中继遵循同一条原则：被别处驱动的串口必须让人看得出来

远端串口显示"远端当前"参数: RFC 2217 与云中继页面勾选"沿用远端串口的现有配置"时，不再显示灰掉的五行本地参数（容易把灰色的"115200"误读成远端实情），改为一行只读的"远端当前"，显示远端服务器报告的实际波特率、数据格式、流控及其签名
云菜单分组: "云控制台"总开关与三个"允许…"开关分组显示，云控制台关闭时三个开关一并置灰——它们都经由云控制台通道生效，此前平铺的菜单让人误以为彼此独立

日志被写进名为 NULL 的文件: 日志文件名在首次成功打开前只是一个占位符，而暂停、停止或自动重连打开端口后触发的写入没有识别它，于是在程序工作目录里生成了一个名叫 "NULL" 的文件；现在这些写入会先按配置的文件名模板解析，再写入正确的文件
DTR 指示灯变灰后不恢复: 在连接编辑器里选过 RFC 2217 或云中继后切回本地串口，DTR 灯一直保持灰色（意为"未置位"），而 RTS 灯会正常恢复；现在两者一致恢复为绿色
RFC 2217 客户端的 DTR/RTS 灯整个连接期间都是灰色: 勾选"沿用远端串口的现有配置"时客户端从不下发 DTR/RTS，服务端也就无从确认，两盏灯始终显示"未询问"；现在首次同步时会查询远端的当前电平，RFC 2217 与云中继两种模式下都能看到确认后的状态
云控制台 HTTP 回退路径的命令延迟: 服务端未提供 WebSocket 通道时，排队的命令现在随心跳应答一起下发，最长等待从 30 秒缩短到一次 20 秒心跳；云端快照缺失或过期时也会按服务端提示立即重传，选择中继目标时不必再等一轮快照请求

Cloud Relay — use a serial port on another computer: The site machine turns on Cloud > Allow Cloud Relay; the operator picks Remote Serial (Cloud Relay) in the port list, chooses a port on one of the account's online computers and presses connect — from there it behaves like a local port: baud rate, data bits, parity, stop bits, flow control and DTR/RTS can be set remotely, the remote CTS/DSR/RI/DCD states are shown, and X/YMODEM transfers and Modbus work as usual. Both ends need nothing more than outbound Internet access — no public address, port forwarding or VPN. The picker says whether each computer is online and whether relay is allowed there; a port accepts one relay session at a time, the sharing side shows a status line while its port is in remote use, and a dropped relay is never redialled silently — connect again deliberately. Relayed traffic draws on the account's cloud traffic quota
Remote use of a bridged port is visible on the sharing side: A bridge port served over RFC 2217 or plain TCP now announces clients arriving and leaving, the pane badge reads "in use by " and turns amber, and the serial parameters or control lines a remote client sets are logged line by line — the same rule Cloud Relay follows: a port driven from somewhere else must say so

Remote serial shows what the remote is running: With "Keep the remote port's own config" ticked on the RFC 2217 and Cloud Relay pages, the five greyed-out local parameter rows are hidden — a disabled "115200" was too easy to read as a fact about the remote — and a read-only "Remote now" row shows the baud rate, data format, flow control and server signature the remote actually reports
Cloud menu grouping: The Cloud Console master switch and the three Allow… consents are grouped, and the consents are disabled while the console is off — they all ride the Cloud Console channel, which the flat menu made look independent

Log written to a file called NULL: Until the first successful open the log file name is only a placeholder, and flushes triggered by pause, stop or a port opened by the reconnect supervisor did not recognise it, creating a file literally named "NULL" in the working directory. Those flushes now resolve the configured file name template first and log to the right file
DTR lamp stuck grey: After selecting RFC 2217 or Cloud Relay in the connection editor and switching back to a local port, the DTR lamp stayed grey — which reads as "not asserted" — while RTS recovered; both now return to green
DTR/RTS lamps grey for the life of an RFC 2217 client connection: With "Keep the remote port's own config" ticked the client never set DTR or RTS, so the server had nothing to confirm and both lamps showed "never asked" throughout. The first settings sync now queries the remote's current levels, so the confirmed state shows in both RFC 2217 client and Cloud Relay modes
Command latency on the Cloud Console HTTP fallback: When the backend offers no WebSocket channel, queued commands now ride the heartbeat reply, cutting the worst-case wait from 30 seconds to one 20-second beat; a missing or stale cloud snapshot is re-uploaded as soon as the server asks for it, so picking a relay target no longer waits out a snapshot round trip

Platform	File
Windows 10 1809 or later, 64-bit	`serial_port_utility_*.exe`
macOS 12 or later, Apple Silicon	`SerialPortUtility-*.dmg`
Linux x86_64 (Ubuntu 22.04 or later)	`serial-port-utility-*-linux-x86_64.tar.gz`

First-launch notes for each platform — Gatekeeper on macOS, the runtime libraries on Linux —
are in the README.

SHA-256 checksums are published with every build at
alithon.com/downloads.