这个，不是可以实现上述控制条件执行时长问题
这个可以逻辑为 当前温度大于30，且距离温度变为大于30的时间点超过了1分钟。以下伪代码通过带条件的lag计算出温度变为大于30的时间点，然后用当前时间减去它得到持续时间。
SELECT * FROM demoStream WHERE temperature > 30 AND ts - lag(ts) ON (WHEN temperature > 30 AND lag(temperature) <= 30) > 1 min
没有，那边是基于 EMQX 规则引擎回答的。EMQX 规则引擎不支持有状态计算。
行吧，我还以为EMQX是类似MQTT的消息服务器，而不是规则引擎
ts 这个时间格式用什么，用时间戳吗
假设你的数据里有int64类型的时间戳，如果没有的话可以用 event_time() 函数
时间窗口适用这个场景吗
也可以吧，用1分钟的窗口，判断一下最小温度
SELECT * FROM demoStream GROUP BY TumblingWindow(ss, 60) HAVING min(temperature)>30
这个简单多了
哈哈，两个的意义略有区别。这个不会在大于30持续一分钟后立即触发，它相当于定时去检查的，延迟大概率都会超过一分钟
这个TumblingWindow里的参数必须是ss吗，能不能是demoStream的一个属性，好像会报错
挺复杂的，我没仔细看啊。初始运行的lag默认值可能跟你想的不一样。你可以先不要where，而是用select把所有这些变量打出来看看是否你需要的
上百台设备每隔一秒上报一条状态数据，ekuiper能顶住这个并发吗？另外就是用时间窗口还是分析函数实现好一点，对报警响应及时性要求高一些？
还有个问题请教下，这个分析函数，缓存数据机制是怎么样的，我看意思是最大值-最小值判断时间间隔的，会不会数据堆积太多
每个partition只缓存一条数据。比如你的例子即使只缓存一条数据。
跟数据的大小，规则复杂程度，规则条数以及你的部署机器的算力等等都有关系。不过这个不到10ms的数据频率应该是问题不大。及时性高是分析函数，他是事件触发的，就是每来一条数据就计算一次。时间窗口等时间到了才计算，就引入了延迟。
哦哦，那分析函数好一些，因为我想分析函数要找到历史的那条小于30温度，他是也把历史的那一条缓存了吗