看起来和我最近做的连载变化有关。

你用什么gpio pin？

可能是，让我们看看，我猜你已经找到了一点 Gijs :-)

esp01 = Gpio0 Gpio2（还没有发现问题）
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

彼得

我这里有两个节点我也可以在今天下午晚些时候测试

好的，
故障不是立即发生的，他们会在一段时间后停止发送，并且非常坚持这样，重新启动或 sw 降级不足以让他们再次发送数据。 他们需要一个电源循环以及关闭和打开之间的一些时间。

“一段时间后”是多久？
我刚刚使用这些传感器之一设置了一个节点，并且还连接了一个 BMP280。
它使用 GPIO-14 和 -12 作为 CO2 传感器。

几个小时，昨天一切正常，今天早上我有 4 个中的 3 个具有相同的状态。

他们都在同一时间启动，在他们都停止工作之前？

是的，我认为所有这些都在一小时内重新启动/更新，昨天晚上正在更新它们。 晚上他们停止工作

我正要更新我的节点，但幸运的是注意到了这一点。 @TD-er 哪个是您猜测 Serial 更改之前的最新版本可能是罪魁祸首？ 或者如果我刷新最新版本以查看我是否会遇到同样的问题会更有用吗？

如果任何丢失的更新不是什么大问题，我会建议最新版本。
要保持串行端口包装器之前的版本，您可以使用 20181231。（我想我今年提交了更改）

我昨天确实将 3 个“问题”esp 降级为 20181231，可以确认他们仍在发送数据而没有硬件更改，现在是 24 小时，所以这三个 esp 在我的情况下仍在使用 gpio12 和 gpio14

重新创建它 Gijs 有什么运气吗？

不，我的节点仍在发送值，并且从 1 月 16 日开始运行构建。 （核心 2.5.0）

我在那些节点上使用了 ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin，我相信它有 2.4.1 内核？

@pwassink没错。
您还可以在 sysinfo 页面中查看核心构建。

我确实将那个版本 ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin 安装回 esp02 这里，让我们看看它是否再次发生

唔，
也许星期几或月亮的位置有一定的影响，
在过去的几天里，我没有看到这里再次发生故障。

它似乎在这里也工作得很好。
你报道的时候刚好是满月，所以我想应该是这样的；）

更新，

我让 esp02 运行 ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin 版本，该版本仍在正常运行。

昨天我确实将其余节点更新为 ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

并且 esp-18 在当地时间 06:55 再次出现故障，除了 MHZ19 Co2 传感器外，所有功能都正常运行，在设备选项卡中，它从大约 07:00 开始再次显示“最后已知的良好值”在日志文件中具有相同的条目：
MHZ19：错误，尝试读取时超时
MHZ19：未知响应：0 0 0 0 0 0 0 0 0

Esp-18 正在使用 Gpio 14 / 12
它是来自 ali 的具有 Ch340 版本 2 的 3 的 Nodemcu
通过 Web 控制台远程重启无法解决问题
它再次显示上述条目数次
重启后
78640：MHZ19：错误，尝试读取时超时
78641：MHZ19：读取错误：校验和 = 202 / 0 字节读取 => 255/168/12/161/226/255/0/0/0/
78643：MHZ19：移动 1 个字节以尝试修复缓冲区对齐
再过一段时间：
255652：MHZ19：PPM 值：1584 温度/S/U 值：25/0/0.00
255656：事件：Rik-CO2#PPM=1584.00
255656：事件：Rik-CO2#PPM=1584.00 处理时间：1毫秒
255659：事件：Rik-CO2#Temperature=25.00
255659：事件：Rik-CO2#Temperature=25.00 处理时间：1毫秒
255662：事件：Rik-CO2#U=0.00
255662：事件：Rik-CO2#U=0.00 处理时间：1毫秒

它现在似乎又可以工作了，但是需要重新启动大约 2 分钟 没有电源

那一刻需要做些什么吗？ 可能会导致 ESP 上的 wifi 中断？

什么都没有，

当时没有计划的重置、重新启动、备份、wfi 重置、dhcp 清理或任何外部原因

wifi一直工作正常，只是mhz19的读数停止了，同一esp上的所有其他（基于i2c的）传感器仍然工作

今天早上 03:00 再次发生，Esp-18 运行 0121 Mega 版本，esp-logfile 中的错误与以前一样，其他传感器工作正常

并且在 19:05 运行 ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin 的 esp02 也崩溃了，情况与上述相同，不再有数据，并且日志记录中的条目相同。

今天又发生了 2 次打嗝，esp02 和 esp18 再次出错，日志中出现相同的故障
涉及软件 2 个版本，0116 和 0121 均为 2.4.1 内核和 4 Mb 版本
esp02 的硬件是 nodemcu-d1-mini / esp18 是 nodemcu-v2 都使用 gpio12/gpio14

你可以在你的一个节点上尝试这个构建吗？

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

它使用 MH-Z19 在我的一个节点上运行，现在的正常运行时间为 54 天 23 小时 21 分钟
那是因为停电...
这个运行良好，定期更新 CO2 值。

我将会，

但是我之前是否已经提到过，直到版本 mega 20181231 core 2.4.1 normal 4Mb 都没有看到报告的稳定性问题，那么为什么要这个特定版本？

我将下载该特定版本并将其安装到 eesp02 和 esp18 二氧化碳测量节点，但问题出现在 mega-2019* 范围内，而不是在我的拙见 Gijs 中。

好吧，那确实没用。

该特定版本在我拥有的版本上运行，该版本似乎（可悲的是不寻常）稳定。
你是对的，如果它在 20181231 之前运行良好，那么不值得尝试旧的。

尽管如此，
Esp02 和 esp18 现在在 ESP_Easy_mega-20181109_normal_ESP8266_4096.bin 上运行
Esp01 和 Esp08 在 ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin 上运行

我们会看到

备注，我刚刚注意到 1109 版本的内部版本号为 20102，所以这已经过去了并且不同了？

吉斯，

我可能在这个问题上找到了另一个线索。

几分钟前，我的 Esp08 A nodemcu ch340V2 4Mb 运行 ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin 也停止发送 co2data。

日志片段
370508579：UDP：60:01:94:0F:AF:9D,192.168.3.46,17
370508785：UDP：24:0A:C4:82:F2:B8,192.168.3.51,21
370509501：UDP：60:01:94:0C:2E:FD,192.168.3.48,19
370514624：UDP：5C：CF：7F：82：FD：47,192.168.3.31,2
370515674：MHZ19：读取错误：校验和 = 120 / 248 字节读取 => 255/134/5/183/71/128/15/112/248/
370515677：MHZ19：移动 1 个字节以尝试修复缓冲区对齐
370517702：事件：时钟#时间=星期三，12:19
370517755：事件：Clock#Time=Wed，12:19 处理时间：53毫秒
370520257：UDP：60:01:94:0B:94:5C,192.168.3.30,1
370520460：UDP：60:01:94:02:0E:E8,192.168.3.36,7
370523940：UDP：18：FE：34：E2：18：84,192.168.3.35,6
370529880: UDP : BC:DD:C2:EA:3D:BC,192.168.3.54,24

这是我第一次看到这个故障，也许..

应该更优雅地处理校验和错误。
也许我们应该在何时开始转向寻找新的良好开端时增加一些门槛。
或者更好的算法来再次同步。
据我所知，一年多来代码没有变化。 创建串行端口连接的方式只发生了变化，所以我真的不知道为什么会导致这些问题。

我的想法是 mhz19 传感器本身在几个小时的通信错误或由于无法获取数据而进入“阻塞”状态。 ?
动机：重新启动甚至完整的软件更新都不能解决该状态，mhz19 必须无能为力一分钟左右才能恢复生命，当它卡在如下状态时，我发现了这种行为：
MHZ19：错误，尝试读取时超时
MHZ19：未知响应：0 0 0 0 0 0 0 0 0

今天早上的故障 esp08 仍然可以通过 Web 控制台的远程重启选项解决，因此它与我发现并报告了几次后几个小时后的完全锁定不同。

但后来发现：
大约在当地时间 1800 点，它进入了被阻止状态，重置，通过控制台电源循环重新启动这次没有任何效果，设备需要用 mega 20181231 4mb 版本重新闪存，然后它又恢复了活力。 Esp08 使用 Gpio12/14 组合，也是 nodemcu v2 ch340 模型

听起来很奇怪，因为插件确实向 MH-Z19 发送了收集新传感器数据的命令
所以我不明白为什么即使软重启也不起作用。
我还将添加一些统计信息以查看校验和错误发生的频率（接收端）
如果这种情况经常发生，那么在向传感器发送数据时也可能发生这种情况，然后传感器可能会进入某种未知的命令模式。
当我改变串行引脚的配置方式时，可能一些上拉电阻配置发生了变化？？？

它可能，

明天或即将到来的周末会进一步研究它，也许我能找到一些东西，那个传感器不是被广泛使用以至于没有人遭受相同的行为吗？

或者不被运行最新版本的人使用

我有 2 个 MH-Z19b，都在 20190116 测试版本上运行，没有问题

好的，只是想知道您使用的是哪个核心版本的测试版本以及您使用的是哪个 Gpio？

我看到 1 正在运行 ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin，另一个 ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin。 在连接到 GPIO 13 和 12 的两个传感器上

所以这是你在 13/12 中使用的另一个核心和另一个 GPIO，而不是我在这里使用的 GPIO 14/12

今天我更新了 4 个中的 4 个到 ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin 版本

让我们来看看

现在想来，今年年初以来使用的 SWserial 库可能会发生另一次变化。
我们曾经拥有自己的 SWserial 库版本，我对其进行了修补以使用更少的 iRAM 内存。
但是现在我们使用的是核心库中包含的版本，对于核心 2.5.0，这可能是比以前更新的版本。
此外，在低速连接上使用中断可能会有一些变化。 （9600 波特及以下）
我也必须调查一下。

它仍然无法解释为什么传感器显然会变得如此混乱，以至于需要断电才能再次正常工作。

在更新到 ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin 后 3 小时内，我的 esp18 再次被锁定，webconsole 重启不起作用，需要再次关机。
另一个还在工作，如果它也冻结了 MHZ19，将在此处添加

是的，另一个 esp18 在今晚 19:05 停止发送合理的 CO2 数据，因此至少在昨天的 mega 202 core 2.4.1 中故障持续存在。
那个又回来了，现在也降级到 20181231 版本。

午夜左右，第三个 esp，esp02 冻结了 Co2 读数，现在也降级为 20181231

唯一仍在 ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin 上运行的是使用 Gpio-0/Gpio-2 的那个，其他三个确实冻结的是使用 Gpio14/gpio12。
我觉得这不再是巧合了

我将更改 esp02 的接线至 Gpio-0/Gpio-2 并再次将其升级到 0202 版本核心 2.4.1，我们可能会看到在此 gpio 更改后它是否仍然存在。
完毕

我刚刚添加了一个提交来对阅读进行一些改进。
见https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

您可以为它构建一个测试版本，还是要我构建一个？

如果你能给我提供一个垃圾箱，我很乐意把它放在仍在运行 esp 的 gpio12/14 上
然后确定文件是相同的，没有本地影响等..

好的，花了一些时间，但这是测试版本

知道了，

Esp08 和 esp18 现在运行在这个带有 2.4.1 内核的测试版本上，它们都使用 gpio12/14

让我们来看看 ！

您还应该看到一些指示器显示处理的行数和 CRC 失败的 nr

是的，我现在也将它们放在控制台中！

将离开那些 2 并以一定的间隔查看这些计数器是否增加。
保持联系 ..

测试节点上使用的两个传感器都是 B 版本，因此检测也有效

校验和（通过/失败）：| 11/0
-- 08 --
检测到：| MH-Z19B

校验和（通过/失败）：| 8/0
-- 18 --
检测到：| MH-Z19B

您是否还混合了 MH-Z19 A/B 或只有较新的 B 版本？
应该没关系，只是好奇。

您是否还混合了 MH-Z19 A/B 或只有较新的 B 版本？
应该没关系，只是好奇。

B版本，刚刚添加了该信息，检测也有效:-)

小更新，一切仍然运行良好，具有您的特殊版本 esp8 和 18 的那些显示计数器增加但仍然没有故障或校验和错误，当前值为：

Esp08：校验和（通过/失败）：| 1795/0
Esp18：校验和（通过/失败）：| 724/0

另一个失败的非常一致的 esp02 现在也仍在运行，使用已更改的 Gpio
因此 di-mini 现在在 Gpio-0/Gpio-2 和 mega 20190202 版本 core 2.4.1 上有 mhz19

Bummer不小心删除了这里的帖子，试着从我的记忆中重新创建：

昨天晚上，我的 esp 的 02、08 和 18 中的三个在 Domoticz 上变红了，没有二氧化碳传感器数据。
其中两个具有特殊版本 core 2.4.1 和 gpio 12/14。 网络控制台重启并没有解决它，只产生：MHZ19：未知响应：0 0 0 0 0 0 0 0 0 但 esp18 co2 测量在大约一小时后恢复了生命，在 0:56 它开始再次发送正确的值。

Esp08 也已重新启动，并且 esp02 也（现在与 esp01 具有 gpio0/2 相同）都没有恢复，今天早上都断电了 2 分钟，之后都恢复了正常。

我现在将 esp02 上的软件版本更改为 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 以便我们也可以测试该核心版本，gpio chnage 运行旧（当前 2.4.1）版本并没有什么影响变得清晰
esp02 今天确实显示了一个校验和失败：校验和（通过/失败）：| 79/1

我也只在开始时为 esp08 激活了 syslog，设置如下，如果您需要特定设置，请询问。

也许您还可以在帖子中逐项列出您的配置（也可以是下一个帖子，无需编辑此帖子），显示以下内容：

• 您的内部单位编号（供您自己参考，例如“02、08、18）
• 构建运行
• 成功/失败的数量（如果有）
• 失败/问题的种类

与描述性文本相比，逐项信息（对我而言）更容易理解。
我有时也会用手机回复。

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 核心 2.4.1 gpio12/14
esp01/02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

-- 冷冻意味着除了二氧化碳读数外一切正常

22:57 esp08 再次冻结，计数器校验和（通过/失败）：| 1077/2 找到后将系统日志放在一边。
05:05 esp18 再次冻结，计数器校验和（通过/失败）：| 1076/2
06:25 esp08 再次冻结，没有计数器，esp 这次完全崩溃了，得到了 syslog
12:57 esp18 再次冻结。 计数器校验和（通过/失败）：| 116/2
20:43 esp18 再次冻结，计数器校验和（通过/失败）：| 316/2 尝试了 mhzreset 命令
没有任何变化，传感器正在发送 mhz19 未知响应 0 0 0 0 0 0 0 0
一遍又一遍的消息，尝试了几次尝试没有解决方案，重新启动节点。

吉斯，

我对 esp08 的最后一个 syslog 进行了一些分析，在它运行的几个小时内，我看到了 78 个事件：
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy：MHZ19：未知响应：ff 0 0 0 0 0 0 0 0

使用#cat messages-crash-esp08-0625 |grep MHZ19 | 自动搜索 grep 响应 | grep 'ff 0 0 0 0 0 0 0 0' | wc -l

在将该 cmdline 更改为第二个未知响应变体之后，linux 计算了 408 次此行：
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy：MHZ19：未知响应：0 0 0 0 0 0 0 0 0

就我在过去几天看到的情况而言，您的自定义调试版本中的校验和错误计数器没有超过 2。
第一条错误消息（MHZ19：未知响应：ff 0 0 0 0 0 0 0 0）在今天早上冻结之前连续出现了六次左右。

看起来传感器本身正在崩溃，但我想不出它现在这样做的原因。
在我们的源代码中，有一个命令用于调用 MH-Z19 传感器的重置，但数据表中没有记录。
所以我不知道它的状态。
您可以尝试在像这样卡住的节点上调用该命令吗？

编辑：该命令是mhzreset

在巨型 20181231 2.4.1 之后必须进行一些更改。 据我所知，4Mb 版本在 MHZ19 上具有此结果。 即使在 gpio 12/14 上，它也可以运行数周而没有问题。

下次停止工作时会尝试，在 23:20 发现 esp18 被冻结，mhzreset 没有改变，见上面的日志。

mhzreset 命令不会在 web 控制台中打开命令窗口，也不会报告 Ok 回来左右，经过几次尝试后我在 syslog 中找到：
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy：MHZ19：发送传感器重置！
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy：MHZ19：发送传感器重置！
so easy 说它已发送，但它似乎不是 mhz19 理解或喜欢的风格:-)

该命令似乎确实对 MH-Z19 A 版本有所帮助。

127136: MHZ19: Sent sensor reset!
137272: MHZ19: Unknown response: ff ff ff ff ff ff ff ff ff
152275: MHZ19: Unknown response: ff 31 f5 4b 42 32 30 30 d
167277: MHZ19: Bootup detected! PPM value: 5000 Temp/S/U values: 23/1/15000.00
197279: MHZ19: Bootup detected! PPM value: 400 Temp/S/U values: 23/1/15000.00
<repeat a few times>
257279: MHZ19: PPM value: 906 Temp/S/U values: 24/64/11554.00

所以看起来它不能在B版上使用。

我可以假设在插件的启动/初始化中也使用了类似的命令？
这可以解释为什么没有电源循环的重启/重置不能解决问题。

直到今天下午才看到失败：
15:43 esp08 再次冻结，计数器校验和（通过/失败）：| 2316/2 将系统日志放在一边。

只是为了确定，这些节点在旧固件版本上运行良好？

是的，直到 ESP_Easy_mega-20181231_normal_ESP8266_4096 是并且仍然可以，
他们会运行数周而没有问题

我查看了 SWserial 库中的最新更改，因为那是我们现在正在使用的库。
其中一项更改是不再对 9600 波特的 TX 传输使用中断。
你可以试试这个测试版本吗？

注意我还删除了核心 2.5.0 构建，因为它们在提供网页时表现得很奇怪。

Esp08 和 Esp18 运行 ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
这两个也确实将他们的数据发送到系统日志服务器，以便记录日志数据

另外两个将在明天跟进，其中一个可能是 Mhz19A，它是。

硬件配置现在是：
Esp01 在 gpio0/gpio2 有 MHZ19A
Esp02 在 gpio0/gpio2 有 MHZ19B
Esp08 在 gpio12/gpio14 有 MHZ19B
Esp18 在 gpio12/gpio14 有 MHZ19B

他们现在都在 esp-easy 的同一个测试版本上，运行在：
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

更新

06:01 esp08 再次冻结，计数器丢失（用户引起）将系统日志放在一边。

05:21 Esp18 冻结，校验和（通过/失败）：| 1460/0，已将系统日志放在一边
12:53 Esp08 冻结，校验和（通过/失败）：| 1351/28，已将系统日志放在一边

核心 2.4.1 版本未包含在该测试版本中，因此我只制作了一个仅包含该核心版本的版本。 核心 2.4.1 构建与 ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin 中相同的代码
那个使用旧版本的 SoftwareSerial 库。
如果那行得通，那么我将更改使用的 SW 串行库。

现在开始升级到特殊版本：firmware.bin 用于所有 4 个节点，于 12:30 完成

我注意到的第一件事是，Esp08 被冻结，这个固件更新重新启动了 MHZ19B，它恢复了活力，我的意思是初始化：传感器给了我一个合理的 C02 值，这似乎也快得多

我也在测试节点上运行旧的 SWserial 库，确实它工作得更好
例如，Eastron 能源监控有大约 20 - 30% 的接收线路损坏，但现在运行良好。 （还没有失败的校验和）

我刚刚制作了一个新的测试版本，其中我对 HW/SW 串行包装器进行了很多更改。
它现在可以与用于 SWserial 和 HW 串行的 Eastron 插件一起使用，并且 SWserial 现在使用我们在 20180131 之前使用的旧库。

所以这实际上和0202版本一样但是和20181231版本有相同的serial lib，我将直接升级它们..稍等

安装ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
现在在 Esp0/02/08/18

让我们来看看 ..

是的，它有 HWserial/SWserial 包装器，因此只要您使用正确的引脚，就应该很容易切换到 HWserial。

我仍然需要添加 GPIO2 作为 HWserial0 的额外选项，并且在代码中还有一些清理工作要做。

由于最初几个小时过去了，他们仍在工作，在最后一次更新之后，我看不到任何未知数
不再响应来自 esp08 或 esp18 的 syslog 中的 ff 7 x 0 或 8 次 0 消息。

花了一些时间查看 2 个节点的系统日志数据：
Esp08 仍然有一个未知的响应，偶尔会有不同的代码，
Esp18 还没有产生任何故障

很高兴听到。
我认为我们遇到了一些问题，即发送到传感器的数据被破坏了。
然后传感器本身可能会崩溃，我猜。

使用 Eastron 插件（发送更多数据），校验和错误的数量显着减少。
使用 SWserial 从消息中大约 20 - 30% 的 CRC 错误到接近 0。（10'000 条消息中的 1 个错误）。

四个都还行

查看了发布 20190215 的固定列表，该版本现在与我在此处的 4 个 Co2 测量节点上运行的版本相同吗？

差不多一样。
至少串口的代码和你的插件是一样的。

然后我保持原样并继续使用“特殊”进行测试

我不清楚该版本中包含什么以及不包含什么，有些数字确实匹配。

是的，我昨天合并的大 PR 是我上周制作的所有测试版本的来源。

Esp08 在 14:17 冻结，计数器 Checksum (pass/fail): | 3292/70，syslog 搁置以供进一步分析

节点的简单重启（或保存设置）是否重启了传感器（不是断电）？

下次会尝试，只是在检查计数器后重新启动它。

Esp08 再次冻结，计数器校验和（通过/失败）：| 2660/55

保存 co2-device 参数确实解决了冻结问题！

Esp08 18:18 再次冻结，计数器校验和（通过/失败）：| 2660/55

保存 co2-device 参数确实解决了冻结问题！

好的，所以可以执行重置。
我将检查 N 个未知响应，然后再次执行初始化。

这可能会彻底解决这个问题。

现在，我们在所有这些传感器上发生的整个系列问题现在似乎在 modelA 和三个 Mhz19B 模型传感器中的两个上消失了。
Esp08 是 B 型，是我见过的唯一一个在日志文件中仍然存在变量“未知响应（每次更改）十六进制值”的传感器，如果该传感器在表现不佳时可以从插件中重置，这可能是解决方案。

现在全部升级到 Mega 201902026 4Mb。

我注意到的第一件事是，mhz19B 型 Co2 传感器在刷新新图像后几乎立即给出正确的值，也比以前快得多。

这听起来很有希望！ 我一直在看这个帖子，等了一会儿我终于可以升级了。 :grin: 我有一个连接了 MH-Z19 和 PMS7003 的节点。 MH-Z19 的工作时间超过 90%，但偶尔我不得不为此重置 ESP。

PMS7003 似乎失败了很多。 大多数情况下，即使重置也无济于事，但断开电源几秒钟可能会解决它。 我一直怀疑它的连接器可能是罪魁祸首，但还没有调试它。 这个线程让我很好奇它是否仍然与固件相关......当我可以确定它不会导致 MH-Z19 出现问题时，我会试一试，因为它的数据更重要。

是的，我注意到#2349 只涉及 MH-Z19 代码，但我正在运行的构建是“20100 - Mega (core 2_4_0)”，我认为它已经很老了。

我想说，一个问题的双方都如此坚持是很少见的。 我想很多人会在几天后放弃。 这位旁观者@TD-er 和@pwassink 向您致敬！

您可能需要再等 1 天才能升级。
我现在正在开发一些用于网络连接的补丁。

谢谢（你的）信息！ 不过，我本来打算等一下@pwassink的报告（懒惰我）。

只要知道自从您当前的构建以来发生了很多变化，遗憾的是并非都是积极的。
我们仍在尝试解决的问题之一是硬件看门狗重启。 因此，您可能需要保留当前设置的备份并记下您正在使用的当前版本。 只是要确定。
我希望通过今天的修复来改进这些重新启动，但由于这些重新启动有几个不同的原因，我认为今天的修复无法解决所有问题。

记下。 我只能想象在像 ESPEasy 这样的系统中避免回归的困难。 我将在升级后报告任何回归（当然作为单独的问题）。

我计划升级我这里的两个 ESP。 基于这些，我只能观察到 MH-Z19、PMSx003、BMx280、TSL2561、DHT22 传感器或 OLED SSD1306 显示处理是否存在回归。 另一个 ESP 上的 TSL2561 也倾向于随机停止返回数据（尽管非常罕见）。 它正在运行构建“20102 - Mega”。

那不是构建，而是内部文件格式（我知道令人困惑）您可以在 sysinfo 页面中找到构建名称/日期。

至少在“构建”领域。 二进制文件名是“ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames”。 我可能直接从 PlatformIO 闪过它。 我可能很难在几乎一年前闪烁相同的版本。 我并没有真正做任何笔记，更不用说标签了。 :joy: 好吧，如果我不够冒险的话，我想我可以备份固件。

sysinfo 页面中没有构建时间戳？

有一个时间戳，但它没有多大帮助，因为我不记得我是否在这样做之前拉入了最新的代码。 但当然它给出了一些大概。

这不是托管 MH-Z19 和 PMS7003 的 ESP。

但我想这已经离题了。 抱歉暂时劫持了线程，并感谢您回复我的评论！

这是在哪个版本中修复的？

几个小时后，我得到 MHZ19：未知响应：0 0 0 0 0 0 0 0 0
重启不会修复它必须拔下它并重新插入

我使用的是 wemos 1d mini pro，这个版本有修复吗？

构建：⋄ | 20104 - 超级
-- | --
系统库：⋄ | ESP82xx 核心 2_5_2，NONOS SDK 2.2.1(cfd48f3)，LWIP：2.1.2 PUYA 支持
Git 构建：⋄ | 巨型20191003
插件：⋄ | 46 [普通]
构建 Md5：| 3180a4d3e118166b3414444513a6169
Md5检查：| 通过了。
建造时间：⋄ | 2019 年 10 月 3 日 02:15:29
二进制文件名：⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

谢谢

是的，以前的版本也是。
我建议尝试使用 20190928 版本，因为 10 月版本还有一些其他问题（我将在上周左右修复）

您可能还想查看插件页面上显示的读取错误数，它已经运行了几个小时。

例如我自己的一个单位（3 天正常运行时间）

注意过滤器（在屏幕截图中设置为“使用不稳定”）在 MH-Z19B 传感器上没有意义，它仅适用于 -A 版本。

还有一个：

如您所见，失败的读取次数很少。
如果你有一些错误，你手头可能还有另一个问题。

那 11 次重置，我试图让它在没有插件的情况下重新启动，但我不记得看到任何错误，但我可以再试一次，我应该使用软件串行吗？

Hardware Serial 是更好的选择，但是您还必须在 Tools->Advanced->Serial Port 中禁用串行端口。 （如您的屏幕截图中所述:)）

我不确定板上是否有任何现有的 USB 到串行适配器可能对通信产生影响。
如有疑问，您可以更改为软件序列号。

构建：ESP_Easy_mega_20201130_normal_ESP8266_4M1M
向 FHEM 报告。
我遇到了类似的问题：MH-Z190B 传感器每隔几个小时就会冻结一次，当我使用硬件串行时，它会一直下降到 400。
切换到软件串行后，它似乎可以正常工作并且不再冻结。
附上2张截图。

带 I2C 的 BME280 工作正常，一直在报告

嗯，这很奇怪。
它连接到哪个硬件串行端口？
还有什么连接到板子的？ （例如USB转串口芯片）
工具->高级页面上的“使用序列号”是否未选中？

它连接到 GPIO-13 (D7) <- TX 和 GPIO-15 (D8) -> RX（首先在硬件中，现在在软件中），因为我想使用 TXD0 和 RXD0 通过 USB 端口（CH340）读取消息) Wemos D1 mini。
“使用串行”是否意味着“串行设置 - 启用串行端口：”已选中？ 我留下了检查，以便能够通过 USB 读取消息。

ESP8266 上的硬件串行使用 Serial0。
如果您还将日志发送到同一个串行端口，传感器可能会崩溃，因为它不理解通过该端口发送日志时收到的“命令”。

如果您将某些东西连接到硬件串行端口，则不应再发送其他数据。 因此，您应该在工具->高级页面上禁用“使用串行”。

昨天，我得到了第二个传感器 MH-Z19C。 这个似乎与 Serial2 上的 HW-Serial 一起工作得很好。 由于传感器都连接到引脚 D7（GPIO 13）和 D8（GPIO 13）（RXD2 和 TXD2），就我而言，与 Serial0（引脚 RXD0（GPIO3）和 TXD0（GPIO1））不应该有任何冲突了解引脚分配。 我认为第一个传感器（来自另一家供应商的 MH-Z19B）只是一个假货，根本无法正常工作，...
所以在购买这些传感器时要小心。 我昨天拿到的第二个包装更好，带有 Winsen 徽标和测试证书。 供应商似乎比第一个卖给我的供应商更严重。