洗衣店通常同时运行多台设备，不同设备的运行阶段、剩余时间、故障代码等状态信息如果只靠现场查看，管理效率很低。利用R语言可以在服务端快速搭建数据接收、解析和展示链路，将每台设备的状态数据通过网络定时上报，形成统一监控视图。本文以HTTP和JSON为例，说明如何设计设备状态报文、用R接收并解析数据，并通过异常检测规则和可视化面板辅助运维人员及时处理故障设备。
整体链路与数据传输思路
设备状态监控的数据流可以划分为三个环节。设备端的控制器读取洗衣机或烘干机的运行参数，按照约定格式组装成JSON报文，通过局域网或互联网发送到中心服务器。中心服务器上运行基于R的接口服务，接收报文后写入内存或数据库。最后R负责清洗、统计和展示数据。这套方案适合设备数量在几十到几百台的中小型洗衣房，也便于后续接入能耗分析等功能。
在传输协议选择上，洗衣店设备对实时性要求不高，状态变化通常在秒级或分钟级即可满足管理需求。因此可以使用HTTP定时上报，降低部署复杂度。设备端不具备HTTP能力时，也可以通过串口转以太网模块或边缘网关完成协议转换。服务端使用R的plumber包可以快速暴露API接口，无需依赖额外的Web服务器。
设备状态报文格式设计
状态报文需要同时兼顾可读性和传输效率。建议采用JSON格式，至少包含设备编号、时间戳、工作状态、剩余时间、温度和故障码等字段。设备编号用于唯一标识，工作状态使用枚举值如IDLE、RUNNING、ERROR、FINISHED，避免直接使用中文导致解析混乱。
{
"device_id": "WM-01",
"timestamp": "2026-01-15T14:32:08+08:00",
"status": "RUNNING",
"cycle_remaining": 18,
"temperature": 42.6,
"fault_code": null
}
时间戳建议使用ISO 8601格式并带时区信息，方便后端统一转换。故障码为null表示当前无故障，如果设备产生错误则填写对应的数字码，例如E03可以编码为3。状态值不要直接暴露给最终用户，应在服务端映射成中文描述。
字段数量应根据实际监控需求扩展。如果需要计算能耗，可以增加累计耗电量和本次耗电量字段。需要预警时，可以增加连续运行时长或桶内负载重量。设计时应注意所有字段尽量使用数值或短字符串，避免嵌入复杂嵌套结构，以降低解析失败概率。
R语言接收与解析状态数据
R服务端使用plumber包创建HTTP接口，接收设备端POST的JSON字符串。接口内部调用jsonlite包的fromJSON函数将JSON转为数据框，之后写入全局数据存储或追加到文件。以下代码定义了一个接收状态的接口，返回接收结果。
library(plumber)
library(jsonlite)
state_log <- data.frame()
#* @post /status
#* @param payload:character
function(payload = "") {
if (payload == "") {
return(list(code = 400, message = "payload is empty"))
}
record <- fromJSON(payload)
state_log <<- rbind(state_log, as.data.frame(record, stringsAsFactors = FALSE))
return(list(code = 200, message = "ok"))
}
这里的state_log使用全局变量保存数据，仅适合演示和小规模场景。实际部署时应替换为SQLite、PostgreSQL或ClickHouse等持久化存储。plumber接口可以通过Run命令直接启动，监听端口后即可接收设备数据。每次收到合法报文后，接口返回简单的成功状态，设备端可以根据返回值判断是否需要重传。
解析时需要注意JSON中的null值。jsonlite默认会将null转为缺失值，但不同版本可能略有差异。建议在接收后对字段类型做一次检查，尤其是时间戳和数值字段。如果设备端发送的时间格式不统一，可以使用lubridate包的解析函数统一转换。
异常检测与可视化监控
数据进入R环境后，可以通过规则引擎判断设备是否处于异常状态。例如设备连续2小时状态为RUNNING但剩余时间未变化，可能表示卡死或通信中断。也可以根据故障码触发告警。下面代码展示了基于状态持续时间的简单异常检测思路。
library(dplyr) state_log$timestamp <- as.POSIXct(state_log$timestamp, format = "%Y-%m-%dT%H:%M:%S%z") state_log <- state_log[order(state_log$device_id, state_log$timestamp), ] abnormal <- state_log |> group_by(device_id) |> mutate(prev_status = lag(status), duration = difftime(timestamp, lag(timestamp), units = "min")) |> filter(status == "RUNNING", prev_status == "RUNNING", duration > 120)
上面的代码使用dplyr计算同一设备相邻两次记录的时间差，当设备持续处于运行状态超过120分钟时标记为异常。实际规则应根据洗衣机和烘干机的正常洗涤周期调整，例如标准洗涤通常不超过60分钟，烘干可能更短。标记异常后可以通过邮件、企业微信等渠道通知运维人员。
可视化部分可以使用ggplot2绘制设备状态热力图或运行时长分布图，也可以使用Shiny创建可交互的监控页面。Shiny应用可以按月、周、日筛选设备，并展示实时状态、历史故障次数和平均运行时长。对于中小型洗衣店，一个单页面板足够支撑日常管理，无需投入商业物联网平台。
通过上述方案，R语言在智慧洗衣店网络中不仅承担数据分析角色，还能直接作为轻量级数据接入服务使用。将设备状态采集、传输、解析和展示统一到R技术栈中，可以降低工具链复杂度，让运维人员将精力集中在规则优化和异常处理上。