新手开发控制软件求助-流光模式启动失败、带mode参数启动set_power失败

感谢前面各位的指导,现在已经成功连接到了彩灯,并且写了一个简单的、还不太稳定的自用版YeeLight类,以便驱动。

目前测试过setcolor,setrgb,stopcf等功能,可以正常运行,在进入流光模式这个命令的时候发生了问题,灯没有响应。本以为需要切换模式,因此使用set_power来切换模式,发现按照文档例子没有问题,带上可选的mode参数却失败了,因此想请问下原因。

发送给灯的指令如下:
关于set_power:
{“id”:3,“method”:“set_power”,“params”:[“on”,“smooth”,200,4]}

关于start_cf:
{“id”:3,“method”:“start_cf”,“params”:[8,2,“100,1,16711680,100,200,1,65280,100,50,1,255,100,30,1,11141290,100,1000,1,16711680,20,30,1,65280,20,200,1,255,20,400,1,11141290,20”]}

贴一下response吧

好,我写那个类的时候没管response,我处理一下,一会儿贴上来

使用这两个命令的反馈都一样:
{“id”:1,“error”:{“code”:-5000,“message”:“general error”}}

灯升级最新固件了吗?

当前版本1.4.2_0026
最新版本1.4.2_0027

确实没有升级,我升级一下试试,测试后回复

当前固件版本1.4.2_0027

为两个灯单独测试输出:

ID:1
Method:start_cf
{“id”:1, “error”:{“code”:-5000,“message”:“general error”}}

ID:2
Method:start_cf
{“id”:1, “error”:{“code”:-5000,“message”:“general error”}}

而且有一个小问题就是单步调试查看了一下,id发送的时候就是上面我自己读取的id,回复ID没有变化~

你先搞个简单的start_cf试试,request的id和response的id是一对一的,为了做匹配

your start_cf parameters are:
100,1,16711680,100,
200,1,65280,100,
50,1,255,100,
30,1,11141290,100,
1000,1,16711680,20,
30,1,65280,20,
200,1,255,20,
400,1,11141290,20

the 1st of each four parameter is the DURATION, which according to the manual:
“Duration: Gradual change time or sleep time, in milliseconds, minimum value 50” - but you’ve entered 30 !

Please note the restriction for each parameter in the manual

从简单的开始,2个加到8个,现在好像流光有反应了,不知道为什么之前一直提示出错,后面成功过一次就没事儿了。。。。
不过返回的id还是有问题。。。我这里发送时候是正确的,很奇怪
ID:2
Method:start_cf
{“id”:1, “result”:[“ok”]}

ID:1
Method:start_cf
{“id”:1, “result”:[“ok”]}

另外想请问一下,咱们文档中明确说了每个tcp链接限制60commands/min,这个有办法突破么?因为局域网控制的话完全没有必要感觉,而且通过程序快速测试咱们的灯是可以实现的(时间间隔30ms发颜色命令,过程中正常,60次左右后停止工作)

我想用它做个快节奏的音乐闪灯,现在这个只能用流光来变通做了感觉,效果不太好

thanks a lot!

I miss this infomation. I thought it is the same duration like before.

请参考音乐模式命令。

谢谢,已看到相关说明,这就尝试~

我使用了音乐模式,不过是否也是最高限制?还是因为网络的原因?

在音乐模式下,我使用set_rgb这个命令速度好像能接受2/250ms也就8帧的速度
使用start_cf命令,每个要求至少50ms的duration,也就是差不多每秒能变20种颜色的样子

这个频率还不够么?很好奇你的需求是要什么要的变化。

每秒20种是够了的,不过如果是set_rgb这种就好了,流光就以为着我只能提供前面一小段时间声音而产生光的数据,这样就意味着延时。

比较希望能够达到无延时的相应这边发送的命令