Espeasy: MQTT从20181008开始停止工作

在20181004中，以下内容已更改：

• [sendHttp]＃1830设置超时并在超时时提前退出
• [WiFiClient]设置超时并使其可为控制器配置
• [Core 2.4.1]从2.4.2返回到Core 2.4.1

而在20181006中：

• [WiFi]在ControllerSettings中增加连接尝试的延迟

您能否测试20181003版本，也许还测试其他2个版本以缩小问题范围？

我会尝试，但恐怕要到星期六才能做。 ;-)

您是否知道MQTT连接丢失需要多长时间？
它在某种程度上与wifi重新连接相吻合吗？

据我所知，没有Wifi损失。
今天早上（10分钟），MQTT连接丢失的速度非常快，但是根据IOBroker的最后一条记录，我也有几个小时...
今晚我将尝试至少启动三个版本之一。

只是作为支票； 您是自己构建还是使用每晚构建？

另一件事要检查：

您确定MQTT停止工作了吗？
我这里显示的是一段时间后的“ Connection LOST”，但一切仍在使用MQTT进行。

我看到的唯一错误是消息“连接丢失”，而一切仍在进行。
例如，我通过MQTT控制器获得正常运行时间。
一段时间（10分钟至10小时之间）后，我看到“连接丢失”，但分钟数仍然通过MQTT发送。

格蕾兹
萨沙

一旦检测到不再连接，MQTT应该立即进行重新连接。
另请参阅@ Sasch600xt其他相关问题：
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

在20180927之前的一些版本，您报告说可以正常运行的版本，我添加了一个针对MQTT控制器的修复程序，其中ESP上的MQTT客户端将为其提供一个新的客户端ID，以防止代理在以下情况下拒绝新的连接：代理仍然假定来自该客户端的现有连接，并且客户端认为该连接已断开。

您可以增加控制器的超时设置吗？ 在我介绍该设置之前，默认值为1000毫秒，而第一个版本的默认设置为100毫秒。 后来我将默认值（用于新设置）更改为300毫秒。
因此，也许您可​​以尝试将其设置为300或更高（不超过1000毫秒）。 （无论什么版本，至少一个曾经失败的版本）

我确实遇到过1个（共5个）单元的相同问题。 我在MQTT控制器设置（最小发送间隔，最大队列深度，最大重试次数和完整队列操作）上玩了一点； 本机现在可以使用的设置：1000ms，5/5和“删除最旧的”。

好消息...
看起来和12小时前blb4github谈论的是同一问题。 有了一个新的单位，它可以正常工作直到现在！ 看起来“旧”的确实存在内存问题或时序问题。 我会尽力增加这一限制...让您了解情况;-)
顺便说一句..（对不起..用Atom进行自我构建..因为我不想要所有插件...但是直到现在它总是很​​好..）你们在这方面都做得很棒...据我所知确实有这个问题（仅此一个（因此具有最新的SW））。 我会增加设置并通知您。

问候彼得

@fraeggle您是否可以在此处粘贴systeminfo页面的好模块和坏模块的屏幕截图？ （特别是和存储部分）

以及一些硬件描述。
例如，我感觉最近sonoff模块发生了一些变化。
Sonoff基本版和S20

@fraeggle您是否还可以对有问题的节点进行完全擦除并开始清理？
空的bin文件包含在版本ZIP文件中。

嗨，TD-er
我之前已经删除了错误的节点...因为我将超时设置更改为800ms
它是稳定的。 电压每120秒更新一次。

硬件没什么特别的...。因为仍在等待INA219到达.. ;-)

问候彼得

不幸的是，ups关闭了它。

但是我认为使用此“ workaroud”可以将其关闭...我真的认为现在这是单位问题。
您如何看待TD-er？

仍然奇怪的是，这方面的单位有所不同。
这表明一个单元的wifi稳定性更差

我同意，但我认为该装置的公差范围太大。 正如我告诉你的那样，由于我将时间更改为800毫秒，因此效果很好...
因此，如果您同意，由于可以更改超时，因此我将关闭此窗口。

谢谢你的帮助..

问候彼得

我发现“自20181007 MQTT Open Hab开始显示“ Connection Lost”（连接丢失）＃1873。
也许是同样的问题？
TD-er告诉我是否可以通过创建日志或类似方式来提供帮助...
使用Openhab（与IOBroker一起使用）。 但直到现在，将“超时”设置为800ms后，没有错误

是您正在运行的OpenHAB的MQTT代理，是安装在您自己的网络中的计算机上，还是安装在外部的计算机上？
如果是本地的，是否可以将其安装在缺少资源的计算机上？

自2018年10月394分钟以来，我还进行了一次测试。
超时时间为800毫秒。
有时，它会在24小时或更长时间后显示为“已断开连接”。 但是我从来没有达到2天。
再一次，在显示“ Connection Lost”（连接丢失）后，我仍然可以正常工作。 所以这只是消息，这让我感到困惑。 有消息通知你

连接丢失只是一条信息消息，指示...连接已丢失。
但是它应该重新启动一个新的连接。
在sysinfo页面中，您可以查看WiFi连接丢失和重建的频率，以及自从上一次（重新）连接到接入点以来连接WiFi的时间。

一旦WiFi连接中断，它还将假定必须重建MQTT连接，因此它将认为与MQTT代理的连接丢失。
直到4周前，MQTT代理可能仍不接受新的连接尝试，因为该代理仍认为客户端已连接。
当客户端继续尝试连接并且代理不接受连接时，这可能导致不确定的重新连接尝试。
我在每次重新连接时都更改了MQTT客户端ID（将重新连接的数量添加到客户端ID中），以便代理将其视为新客户端。
这导致快速重新连接，唯一的缺点是，由于代理假定客户端已断开连接，因此代理将发送LWT（最后遗嘱）。

如果这导致不良行为，我可以将其更改为新策略。
例如，在重新连接尝试失败的情况下，我可以尝试先发送适当的断开连接消息。

简而言之，有许多选择可以使与代理的连接丢失，并且我不确定在您的情况下为什么会丢失。
可能是超时，WiFi断开连接，代理的某些未知响应或任何其他原因。

好的，我知道了。
很好的声明，谢谢。
我现在在507分钟/打开HAB控制器/ 800ms超时。
到目前为止一切都很好:)

是否应将控制器的新实例的默认超时设置回1000毫秒？

好吧……再给我36个小时的时间.....那我对错误的了解也越来越多，无论是否也有800毫秒的时间。

629分钟现在没有问题...

奇怪的是...更改为800ms之后发现了以下内容。
上次断开连接的原因| （200）信标超时
号码重新连接| 3
das Beacon超时是什么意思？
MQTT仍在运行，但现在与Sasch600txt相同。 但是与以前不同... MQTT仍在工作
只有经纪人告诉此人未连接。

有关信标帧的更多信息，请参见Wikipedia。
简而言之，接入点会定期发送一个包含有关网络信息的数据包。
该间隔通常为100 TU（102.4毫秒）。
ESP模块每次都尝试收听此信标，但是由于多种原因，它可能会丢失信标帧。 超时时间超过100 TU，因此它必须错过许多这些信标帧才能报告信标超时。
错过这种信标帧的原因有：

• 太忙于处理其他阻止任务（很有可能）
• 接入点由于其他用户的高流量需求而未发送信标（取决于品牌/型号/设置）
• 射频干扰（不太可能发生这种情况）
• 时钟漂移（不太可能）

因此，“信标超时”不时在ESP节点上发生。
我正在努力使每个插件/控制器使用较短的时间片，以使任务尽可能少地被阻塞。

我可以确认所有的脆弱说。
今晚某个时候，我收到了“连接丢失”的信息

祝你周末愉快 ：）
萨沙

@fraeggle ：
如果显示为“连接丢失”，请尝试进入ESPEasy的Controllersettings，只需禁用控制器-> save，然后再次启用它-> save。 然后至少对我来说，它再次显示为已连接。 这不是解决方案，但至少很有趣：)您使用的是IPSymcon吗？

@ TD-er：
任务太忙了？ 好吧……我在这里运行的“ TEST UNIT”中，我每60秒只发送一次正常运行时间……在这个单元上没有更多的运行了……所以可能是最小的系统

@ Sasch600xt术语“太忙”可能不是描述真实问题的最佳方式。
Arduino的处理方式是：

• 致电setup()
• 一遍又一遍地调用loop() 。

最重要的是，ESP8266（和ESP32 Arduino）的Arduino版本正在Arduino部分的loop()之外运行一些任务。
这些任务与后台进程有关，例如处理网络连接和传入流量等。
后台任务仅在以下位置执行：

• loop()结尾
• 在Arduino空间中调用delay()或yield() 。

如果循环运行花费的时间超过102.4毫秒，并且没有调用yield（）或delay（），则ESP节点将丢失信标间隔。
同样，如果它正在运行几个阻止任务，这些任务在WiFi接入点发送信标的那一刻总是很忙，则会丢失许多信标。

查看串行日志（启用了调试级别）时，您将看到时序统计信息。
其中一些可能会花费数十毫秒的时间，因此是导致这些“断开连接”原因的候选者。

我可以向调度程序添加一个任务，以尝试每102.4毫秒收听一次信标。 唯一的事情是，我不确定何时看到这样的信标怎么看。

关于此问题，当连接丢失时，我可以研究MQTT的断开连接/重新连接。
您正在使用什么经纪人？ 我在这里使用蚊子，目前的行为效果很好。

好的，“太忙了”对我说的有点容易:)

我正在使用在MQTT经纪人的ipsymcon housecontrol eviroment中运行的脚本

格蕾兹
萨沙

嗨，Sascha ..使用IOBroker。
@ TD-er回到Build27092018。经纪人告诉我仍保持连接...
真令人困惑.. 14小时内没有错误（数字重新连接| 0）

我现在正在计算机上安装IObroker，只是为了看看发生了什么事情。

编辑：
45分钟后，我仍然无法让IObroker在我的计算机上运行。
不知道这里发生了什么，但是Windows安装程序无法正常工作（找不到服务蝙蝠文件），并且在Linux上的安装也没有完成。 它一直试图一次又一次地执行相同的npm安装。
在Intel CPU主机的Ubuntu 18.04和Windows的Bash上进行了测试（Ubuntu 18.04）

不确定与Windows ..我认为有一些软件依赖项。 在Raspberry上运行它。
适用于Windows ioBroker verwendet Node.js，平台和安装程序。 （下载：http：//nodejs.org/download/）首先必须安装node.js。

我也遇到了一个模块，该模块连接了4个DS18B20传感器。
我以为是RasPi，但拍摄了一个干净的Raspbian Streth图像，并在上面安装了mosquitto和node-red。 同样的问题，连接在6到12个小时后中断。

资讯主页： https ：
ESP的4条曲线分别是CV_aanvoer，CV_retour和Sanitair_warm，Sanitair_koud

@fluppie，如果您使用的是官方版本？

不，我使用PlatformIO / Atom构建自己
编辑：哈，我不太清楚，我会尝试正式构建。

让我们看这个！

你好

我有/遇到过同样的问题，我使用HomeAssistant，但是在ESPEasy_mega-20181111 fw之后，问题似乎已经解决了。

谢谢
Ť

2-3天后，我的连接仍在松动。 我将更新为：ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

让我们来看看！

我的失去了康恩。 1-10小时后。 我的正常运行时间约为10h30分钟，所有（5个）相关模块都已连接。 :-)

似乎值得尝试...仍在2709上，因为需要稳定的连接。 请及时通知我。 :-)）

您也可以通过以下网址进行跟踪：https://emoncms.org/Edegem/scrtmp2e并检查CV_和Sanitair_图是否存在:)。

1天的正常运行时间仍然可以。 :-)

您也可以通过以下网址进行跟踪：https://emoncms.org/Edegem/scrtmp2e并检查CV_和Sanitair_图是否存在:)。

:-D Sanitair_warm将近60 C？ 小篝火？ ;-)
我会尝试的..谢谢...

我在洗澡；-)

1天...仍在连接:-D
使用12112018

3天3小时后，我的一个设备失去了MQTT连接。 :-(（mega-20181112 4096 VCC固件）

@redskinhu ：
只是为了确定，在设备断开MQTT连接后，它是否仍然可以正常工作？
因为在我这边，它仅显示为“连接丢失”，但对于所有MQTT操作仍然可以正常工作。

格蕾兹
萨沙

确实，失去连接并不时常发生。
只要在没有人工干预的情况下重建连接，就不会有问题。
WiFi连接会不时地重置，您无法采取任何措施来阻止它。
一旦失去这种连接，它将通知同一节点上的MQTT客户端重新连接。

看起来是与LWT相关的问题。 MQTT并未完全断开连接，ESPEasy发送/接收了MQTT消息，但是LWT未更新，因此HomeAssistant在显示相关传感器/开关不可用之前未获得LWT连接消息。 这是我的理论

我的仍然连接，并且与我的第一篇文章不同，MQTT LWT也告诉我已连接。 看起来不错。

确实，失去连接并不时常发生。
只要在没有人工干预的情况下重建连接，就不会有问题。
WiFi连接会不时地重置，您无法采取任何措施来阻止它。
一旦失去这种连接，它将通知同一节点上的MQTT客户端重新连接。

可以，在这种情况下可以更新连接的LWT吗？

应该在更新连接的那一刻发送LWT。

我现在有一个节点，该节点在LWT中显示为已断开连接，并且它发送的测量值很好。 较旧的版本...也许这可以告诉您一些信息

GIT版本：| 巨型20181008
正常运行时间： 3天17小时36分钟

当ESP节点认为它已断开连接并需要重新连接时，我已经看到了奇怪的事情，但是代理不同意。

你好

我做了一个小调查。 看起来只是LWT是问题所在。 我的一位ESP再次产生了此MQTT“断开连接”的东西。

一切正常，传感器/开关。 但是家庭助理看不到它们，因为在配置中我提供了LWT详细信息。

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

我检查了MQTT流量：我得到了传感器数据，并且可以打开/关闭GPIO。 一切都很好，例如。 LWT。

在我发布了LWT“已连接”消息后，一切恢复了正常。

希望对您有所帮助。

Ť

PS：
我考虑了一个规则，如果LWT消息已断开，该规则可以发布LWT Connected消息，但可惜我无法导入MQTT字符串;-)

无论如何，我一直热切期待新的固件版本。 4个漫长的日子....

我星期一/星期二外出，之后的日子真的很忙;）

我将看看LWT，看看是否可以找到为什么它在重新连接时未发布。

MQTT代理的超时设置是什么？
我正在考虑代理可能会丢失连接的可能性，但是ESP节点仍然像它处于活动状态并且仍处于连接状态。

我尝试了100-1000毫秒。 现在是300。没关系。

不在控制器中，在代理中。
这些时间大约在10到15秒之间。
因此，请检查代理的配置中正在使用的超时时间。

我没有更改有关LWT超时的任何内容，也没有在Mosquitto配置中找到任何相关设置。 它必须是默认值。 我也没有在文档中找到任何LWT超时设置。

不，LWT超时不是代理的超时。
如果客户端在超时时间内未发送消息，则代理会将其视为已断开连接。
因此，如果客户端使用其他超时设置，则可能是代理认为客户端已断开连接，并且客户端未尝试重新连接。

从mqtt规范中我了解到，代理在未设置的由客户端设置的有效期限内收到来自客户端的消息时，代理会发送LWT。 无需在代理端进行配置。

参见https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over

和

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

没错，但是我想知道的是经纪人方面的“保持活跃期”是什么。
我知道它固定在ESPeasy方面。
但是，如果这些彼此之间不同步，您将看到奇怪的事情发生。

嗯，我没有任何可能设置这样的东西

但仍然说“已连接”。 4天:-D

刚刚有一个mega-20181006做了同样的事情。 LWT未更新为在线，但MQTT正常工作

@ jimmys01您可以在您的经纪人中看到它是否基于客户ID的决定吗？ （当连接断开时，这种情况会发生变化）
我在9月下旬的版本中添加了更改客户ID的功能。

@ TD-er，我找到了重现此方法的方法！ 我取消了对来自mikrotik路由器的wemos的身份验证，并立即恢复了连接，但是当mqtt仍在工作时，LWT仍处于脱机状态。 随意寄给我建物进行测试

您还能在MQTT代理中看到客户端ID吗？
如果它在客户端ID后面带有“ -1”或其他字样，则表示它接受新的客户端ID。
如果没有，那可能与我前一段时间更改客户端ID有关。

我还没有找到客户端ID在Mosquitto中的位置，但是日志显示好像没有客户端断开连接并且连接了一个新客户端，这可能是因为wifi取消身份验证和身份验证过程比MQTT协议的脉动更快。

重新启动esp和代理后的新连接

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

取消对客户端的身份验证，然后客户端重新连接。 经纪人这次出于某种原因使客户LWT保持在线状态...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

第二次取消验证

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

从此重新连接开始，在LWT保持脱机状态下，MQTT消息可以正常工作。 请注意客户端名称上的额外_1_1。

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

好的，那么我将还原客户端ID更改。
也许也可以检查远程是否认为客户端已连接？
当代理认为客户端仍然连接并且客户端尝试重新连接时，我已经看到连接被拒绝。
在短时间内重试将保持此状态，因此客户端永远无法重新连接。

有任何状态更新吗？

没呢还没。
但是，由于我们在其他稳定性问题上（终于）取得了一些进展，因此我认为它将排在我的清单上。
感谢您的ping;）

我可以选择在重新连接时更改客户端ID。 （工具=>高级，在其他MQTT设置旁边）

如果现在可以解决问题，请关闭该问题。
我将其设置为固定。

为什么仍要更改客户端ID？

有报告说，只要代理假定客户端仍处于连接状态，代理就会拒绝连接尝试。
因此客户被拒绝并再次尝试。
但是不知何故，那些重新连接触发了代理方的某些事情，将连接尝试视为该客户端的近期活动，因此，它永远不会认为该客户端已断开连接。

好的，可以解决这个问题，但是对于其他看到该复选框的解决方案，它并不自我解释。
可能会添加一个弹出窗口，如果失去wifi后出现重新连接问题，则会弹出一个说明，请勾选该弹出窗口
搜索tasmota问题将发现您有与MQTT保留相关的相似问题，看起来像是经纪人问题。
取消验证后，我也有一个客户端根本没有重新连接到wifi ...需要对此进行调查。

我们将其添加到文档中。
我们正在努力使文档更新，并将大量文档从Wiki移至ReadTheDocs。 这使得每个版本都有文档。
docs文件也包含在GitHub存储库中。

理想情况下，对代码中的修订的提交还将包含文档中的更新。
现在，我将关闭此问题。
如果您有提到的其他问题的更多信息，请为此打开新一期。

你好

我最近安装了20190110版本。 看起来很有希望。 测试5天后没有LWT问题。 :-)
我有几个启用了“ MQTT在重新连接时更改ClientId”选项的节点，有些则被禁用。

好消息！

Ť