在Node-RED中，延时操作诸如sleep的动作可以通过delay或者trigger来实现，而delay和trigger在使用中也略有差别，这篇文章通过具体的示例来进行说明。
事前准备
以容器方式启动Node-RED服务，启动命令如下所示：
启动命令：docker run -it -p 1880:1880 -v $PWD/data:/data -e TZ=Asia/Shanghai --name nodered -d nodered/node-red:1.0.4
delay
下面使用一个delay节点的示例来对其使用进行说明
delay 5s节点为缺省设定，详细如下所示
其余各节点也均使用缺省设定，部署、手动多次触发后结果如下所示
从右侧输出结果可以看到，结果三次正常输出，三次延后输出，延后输出都是sleep 5秒之后输出的，与正常输出一一对应。
Trigger
使用场景：
虽然功能上也可以有扩展，但是delay在使用上主要就是sleep的概念。而trigger则需要结合具体的场景进行理解，Node-RED毕竟是个IOT领域的流程编辑引擎，比如需要连接的某个硬件传感器，需要定期检查是否有问题，如果没有问题则不需要进行任何处理，而仅当有问题时才需要进行后续处理，trigger就是用于这种场景的，可以理解为delay功能的加强。
使用一个类似的构成来对trigger节点进行说明。
trigger节点的设定详细如下图所示，设定Send nothing和等待时间为5s，其余均使用缺省设定
部署、手动多次触发后结果如下所示，可以看到和delay的一一对应不同，每5s会触发一次
- JSON格式的flow
[{"id":"d67f423d.4031","type":"inject","z":"73554227.4474dc","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":240,"y":520,"wires":[["3ddd10ea.96ab3","8a18d983.f05418"]]},{"id":"807440a3.65064","type":"debug","z":"73554227.4474dc","name":"超时输出","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":640,"y":580,"wires":[]},{"id":"3ddd10ea.96ab3","type":"debug","z":"73554227.4474dc","name":"正常输出","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":640,"y":520,"wires":[]},{"id":"8a18d983.f05418","type":"trigger","z":"73554227.4474dc","op1":"","op2":"5秒没有动作，请检查硬件","op1type":"nul","op2type":"str","duration":"5","extend":false,"units":"s","reset":"","bytopic":"all","name":"","x":420,"y":580,"wires":[["807440a3.65064"]]}]
总结
虽然功能不止于此，在这篇文章的两个对比示例中，delay的方式手动触发会一一对应触发，而trigger则是定期触发，而如果选中extend delay if new message arrives的复选框的情况下，则本文示例中的trigger的功能则变为只要有消息到来就一直不会超时。
