"🐛| [Bug]检测间隔/报警连续超过阈值判断/免打扰 可能存在问题 "

[GOUKI9999]

最新版本，这个问题似乎以前也出现过，并讨论过，但应该是没有妥善解决。

目前我粗浅理解为，关于检测并发出报警的可以自定义的参数包含3个，和一组默认参数：
免打扰下 选项：超过阈值总秒数 ott 免打扰时间 dnt
基本设置下：检测间隔时间 int

默认的报警阈值应该是5分钟，默认的免打扰时间是1小时（从推送内容tab下的文本说明可知）

由于检测间隔可以自定义，因此我理解
超过阈值的总秒数为时间段，期间根据检测间隔检测有限次，当第一次超过阈值的时候有一个计数，计数器的指等于ott/int，设为n，也就是比如设置阈值为300秒，检测间隔为60秒，则检测5次，其他同理，如果10秒检测一次就需要检测30次

当一次检测都超过阈值时，则达到报警计数条件，接下来的n-1次都超过阈值则触发报警，否则不触发并清除计数器，直到下一次超过阈值时重新开始计数

但这里有个模糊的地方是免打扰的情况下，如何进行计数清理和计数器重置以及重新开始计数
我期望的理解（两种）：
1，第一次发布报警之后的免打扰时间内，计数器直接不再工作，从第一次发布报警之后+免打扰时间之后重新工作，也就是说
当13:00第一次计数器工作，5分钟后达到阈值并发布报警，也就是13:05分时开始，那么下一次计数器开始工作为14:05，由于达到阈值需要5分钟，那么最快也需要到14:10才能接到第二次报警
2，第一次发布报警之后的免打扰时间内，计数器始终工作，第一次发布报警+免打扰时间后，立刻检查计数器并确定是否需要发布报警，也就是同上例子中，如果免打扰期间内一直高于阈值，则14:05分立刻就有第二次报警

但无论怎么理解，假设我在13:05接到报警后，理论上的剩下一个小时不应该接到报警，即使不设置免打扰，也实际应该有一个免打扰最小值，大约相当于报警阈值（也就是同时只有一个计数器工作），否则就会连续不停每一个int接到一个报警

目前我的设置：
间隔 60秒
持续超过阈值 1800秒
免打扰时间 3600秒

但实际上报警发布情况如下：

报警的间隔不仅不符合免打扰设定，实际上也很难解释工作机制，实际上能看出3个问题
一个是报警的阈值和设定不符（显示1分钟）
其次是间隔不正常
最后是免打扰应该没有正常工作

这里没看代码，大佬看着修一下吧，如果我理解正确，那么一个计数器应该能比较好地执行这个工作逻辑

[GOUKI9999]

粗看了一下，个人觉得是
$temp_last_overload_time
这里可能有点小问题，它的重置条件似乎不完全合理，这样可能会造成“连续超过阈值”的检测出现问题？
一点猜测，其实没完全看明白

[GOUKI9999]

离谱的地方出现了，我设置了温度报警参数较高的情况下（75），仍然会收到71度的报警，而且提示是“连续1分钟超过预设”
更离谱的是我关闭了CPU温度提示之后，重启服务甚至还能收到报警，我已经确认了/etc/config/wechatpush中已经没有了option temperature_threshold 参数，
确认了版本是3.5.6

日志显示两次温度报警之间间隔甚至不足10秒