C# TcpClient控制Yeelight灯泡仅首个连接设备响应异常排查

你的C#代码和可正常运行的NodeJS代码存在3处核心逻辑差异，和多线程、异步调用方式无关，是实现细节不符合Yeelight灯泡固件的TCP控制要求：

• 缺失唤醒报文：NodeJS版本连接建立后会先发送无效字符串asd\r\n，这一步是适配Yeelight固件的已知特性——新TCP连接上收到的第一份报文有极大概率被固件直接丢弃，必须先发一个无效包"唤醒"连接，再发实际控制指令。你的C#代码完全省略了这一步。
• 连接关闭时机过早：C#代码用using块包裹TcpClient和网络流对象，指令写入完成后会立刻退出using块，主动向设备发送TCP断开报文。而NodeJS版本发送完指令后不会主动关闭连接，会保持连接直到系统超时回收。Yeelight固件解析、执行控制指令是异步流程，刚收到报文就被断开连接的话，未处理的指令会被直接丢弃。
• 报文格式错误：你传入的控制指令末尾已经带了\r\n结束符，但WriteLineAsync方法会自动在内容末尾额外追加一个换行符，导致实际发送的报文末尾多了一个空行，不符合Yeelight的JSON报文格式要求，部分固件版本会直接丢弃格式非法的报文。
• 额外隐患：你用async void标记线程执行的控制方法，这种写法无法捕获方法内的异常，也没法等待方法执行完成，极端情况下会出现指令还没发出去线程就被回收的问题。

using System.Net.Sockets;
using System.Text;

async Task ControlYeelight(string ip, bool powerOn)
{
    TcpClient? client = null;
    try
    {
        client = new TcpClient();
        await client.ConnectAsync(ip, 55443);
        NetworkStream stream = client.GetStream();
        
        // 第一步：发送唤醒报文，和NodeJS逻辑对齐
        byte[] wakeupPayload = Encoding.ASCII.GetBytes("asd\r\n");
        await stream.WriteAsync(wakeupPayload);
        await stream.FlushAsync();
        // 预留100ms给设备完成连接唤醒
        await Task.Delay(100);

        // 第二步：发送控制指令，直接发原始字节，避免流包装类修改报文格式
        string command = $$"""{"id":1,"method":"set_power","params":["{{(powerOn ? "on" : "off")}}","sudden",0]}\r\n""";
        byte[] commandPayload = Encoding.ASCII.GetBytes(command);
        await stream.WriteAsync(commandPayload);
        await stream.FlushAsync();
        
        Console.WriteLine($"控制指令已发送至 {ip}");
        // 关键：发送完成后等待2秒，给设备留足解析执行指令的时间，再关闭连接
        await Task.Delay(2000);
    }
    catch (Exception ex)
    {
        Console.WriteLine($"控制设备 {ip} 失败：{ex.Message}");
    }
    finally
    {
        // 统一释放资源，避免提前断开连接
        client?.Close();
        client?.Dispose();
    }
}

// 两个设备并行发送指令，不需要间隔1秒等待
Task task1 = ControlYeelight("192.168.178.83", true);
Task task2 = ControlYeelight("192.168.178.84", true);
await Task.WhenAll(task1, task2);

Console.WriteLine("所有控制流程执行完成");

• 不要用StreamWriter/StreamReader处理Yeelight控制报文，这两个类内置了缓冲、自动追加换行的逻辑，很容易破坏原始报文格式，直接操作NetworkStream发送原始字节是最稳妥的方案。
• 如果并行控制仍有异常，先去掉并行逻辑，依次单独控制两个灯泡，确认单灯控制100%正常后再开启并行。
• 抓包对比时重点核对三个特征：是否发送了唤醒报文、发送控制指令后是否等待足够时间才发送TCP断开包、控制报文末尾是否只有一个\r\n结束符。

内容的提问来源于stack exchange，提问作者bgfxc4