Espeasy: MQTTは20181008以降動作を停止します

20181004では、以下が変更されました。

• [sendHttp]＃1830タイムアウトを設定し、タイムアウト時に早期終了に達しました
• [WiFiClient]タイムアウトを設定し、コントローラー用に構成可能にする
• [コア2.4.1] 2.4.2からコア2.4.1に戻ります

そして2018 1006年：

• [WiFi] ControllerSettingsで接続試行に遅延を追加

20181003ビルドと、これらの他の2つをテストして、問題を絞り込むことができますか？

やってみますが、土曜日までできないのではないかと思います。 ;-)

MQTT接続が失われるまでにかかる時間について何か考えがありますか？
そしてそれはどういうわけかwifiの再接続と一致しますか？

私が見る限り、Wifiの損失はありませんでした。
MQTT接続が失われたことは今朝（10分）非常に速かったが、IOBrokerからの最後のエントリによると私も何時間もあった...
今夜、3つのビルドのうち少なくとも1つを開始しようとします。

小切手と同じように。 自分でビルドしますか、それともナイトリービルドを使用しますか？

チェックする別のこと：

MQTTが機能しなくなってもよろしいですか？
ここにある私のものはしばらくすると「接続が失われました」と表示されますが、すべてがまだMQTTで機能しています。

私が目にする唯一のバグは、すべてがまだ機能しているときに「接続が失われました」というメッセージです。
たとえば、MQTTコントローラーによって稼働時間の分を取得します。
しばらくすると（10分から10時間の間）、「接続が失われました」と表示されますが、それでも分はMQTTを介した送信でカウントされます。

グリーツ
サシャ

MQTTは、接続されなくなったことを検出するとすぐに再接続を実行する必要があります。
@ Sasch600xtの他の関連する問題も参照してください。
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

20180927より前のいくつかのビルドは、正常に機能していると報告されていますが、ブローカーが新しい接続を拒否するのを防ぐために、ESP上のMQTTクライアントが自身に新しいクライアントIDを与えるMQTTコントローラーの修正を追加しましたブローカーは引き続きそのクライアントからの既存の接続を想定しており、クライアントは接続が切断されていると見なします。

コントローラのタイムアウト設定を増やすことはできますか？ その設定を導入する前のデフォルトは1000ミリ秒で、最初のビルドのデフォルトは100ミリ秒でした。 後で、デフォルト（新しい設定の場合）を300ミリ秒に変更しました。
したがって、テストとして、300以上（1000ミリ秒以下）に設定してみることができます。 （バージョンに関係なく、少なくとも1つは失敗していました）

私は1つ（5つのうち）のユニットで同じ問題を経験しました。 MQTTコントローラーの設定（最小送信間隔、最大キュー深度、最大再試行、​​フルキューアクション）を少し試しました。 このユニットで現在機能する設定：1000ms、5/5、および「最も古いものを削除」。

わかりましたニュース...
12時間前にコメントされたblb4githubが話しているのと同じ問題のようです。 新しいユニットを取り、それは今まで問題なく動作します!!!! 「古い」ものにはメモリの問題やタイミングの問題があるようです。 私はこれでタイミングを上げようとします...あなたに知らせ続けてください;-)
ところで..（申し訳ありませんが..Atomを使用したセルフビルド..すべてのプラグインが必要なわけではないので...しかし今までは常にうまくいきました..）皆さんはこれについて素晴らしい仕事をしています...そして私が発見した限りではこの問題を抱えているのはこれだけです（したがって、最新のSWを備えたものです）。 設定を増やしてお知らせします。

よろしくピーター

@fraeggle良いモジュールと悪いモジュールのsysteminfoページのスクリーンショットをここに貼り付けることは可能ですか？ （特にストレージセクション）

そして、ハードウェアのいくつかの説明。
たとえば、最近、sonoffモジュールにいくつかの変更が加えられたと感じています。
ソノフベーシックとS20

@fraeggle問題のあるノードを完全にワイプして、クリーンに開始することもできますか？
空のbinファイルはリリースZIPファイルに含まれています。

こんにちはTD-er
以前に不良ノードを消去しました...タイムアウト設定を800msに変更したので
安定しています。 電圧は120秒ごとに更新されます。

ハードウェアは特別なものではありません....まだINA219が到着するのを待っているので.. ;-)

よろしくピーター

ups私は残念ながらそれを閉じました。

しかし、私はこの「workaroud」でそれを閉じることができると思います...私はそれが今ユニットの問題であると本当に思います。
TD-erについてどう思いますか？

それでも、この点でユニットが異なるのは奇妙です。
それはwifiの安定性が1つのユニットでより悪いことを示唆します

同意しますが、このユニットの許容範囲が広すぎると思います。 私があなたに言ったように、私は800ミリ秒に変更したのでそれはうまくいきます...
したがって、タイムアウトを変更する機能があるため、同意する場合はこれを閉じます。

ご協力いただきありがとうございます..

ピーターよろしく

「20181007MQTTOpen Habに「接続が失われました」＃1873が表示されるので。
多分同じ問題？
TD-erは、ログなどを作成することで支援できるかどうか教えてください...
Openhabの使用（IOBrokerを使用）。 しかし、タイムアウトを800msに設定した後、これまでエラーは発生しませんでした

実行しているOpenHAB用のMQTTブローカーは、独自のネットワーク内のコンピューターにインストールされていますか、それとも外部ですか？
また、ローカルの場合、リソースが不足しているコンピューターにインストールされている可能性がありますか？

20181020の394分からテストを実行しています。
800msでタイムアウトします。
24時間以上経過すると、切断済みとして表示される場合があります。 しかし、私は2日には達しませんでした。
繰り返しになりますが、「接続が失われました」と表示された後も、すべてが機能しています。 ですから、それは私にとって混乱しているメッセージにすぎません。 随時お知らせします

Connection Lostは、接続が失われたことを示す単なる情報メッセージです。
ただし、新しい接続を再開する必要があります。
sysinfoページでは、WiFi接続が失われて再構築された頻度と、アクセスポイントに最後に（再）接続してからWiFiに接続されている期間を確認できます。

WiFi接続が中断されるとすぐに、MQTT接続を再構築する必要があると見なされるため、MQTTブローカーへの接続が失われたと見なされます。
4週間前まで、ブローカーはクライアントが接続されていると見なしていたため、MQTTブローカーが新しい接続の試行を受け入れない可能性がありました。
これにより、クライアントが接続を試み続け、ブローカーが接続を受け入れない場合に、無期限の再接続が試行される可能性があります。
再接続のたびにMQTTクライアントIDを変更し（クライアントIDに再接続の数を追加）、ブローカーがそれを新しいクライアントと見なすようにしました。
これにより、迅速な再接続が実現しますが、唯一の欠点として、ブローカーはクライアントが切断されていると想定するため、LWT（遺言と遺言）を送信します。

その結果、望ましくない動作が発生する場合は、新しい戦略に変更できます。
たとえば、再接続の試行が失敗した場合、最初に適切な切断メッセージを送信しようと試みることができます。

要するに、ブローカーへの接続が失われる可能性のある多くのオプションがあり、あなたの場合にそれが失われる理由はわかりません。
タイムアウト、WiFi切断、ブローカーの不明な応答、またはその他の理由である可能性があります。

はい、わかった。
非常に良い声明、ありがとう。
私は今507分にいます/ HABコントローラーを開きます/ 800msのタイムアウト。
これまでのところすべてが良いです:)

コントローラの新しいインスタンスのデフォルトのタイムアウトを1000ミリ秒に戻す必要がありますか？

まあ......ギミー36時間以上.....それなら私はバグが800msで来るかどうかについてもっとよく知っています。

分629今問題なし...

奇妙な... 800msに変更した後に発見されました。
最後の切断理由| （200）ビーコンタイムアウト
番号の再接続| 3
das Beacon Timeoutとはどういう意味ですか？
MQTTはまだ実行中ですが、現在はSasch600txtと同じです。 しかし、以前とは異なります... MQTTはまだ機能しています
ブローカーだけがこれが接続されていないことを伝えます。

ビーコンフレームの詳細については、ウィキペディアを参照して
つまり、アクセスポイントは、ネットワークに関する情報を含むパケットを定期的に送信します。
この間隔は通常100TU（102.4ミリ秒）です。
ESPモジュールは毎回このビーコンをリッスンしようとしますが、いくつかの理由でビーコンフレームを見逃す可能性があります。 タイムアウトは100TUより長いため、ビーコンタイムアウトを報告するには、これらのビーコンフレームの数を見逃す必要があります。
このようなビーコンフレームを見逃す理由は次のとおりです。

• 他のブロッキングタスクの処理で忙しすぎる（非常に可能性が高い）
• 他の人のトラフィック需要が高いためにアクセスポイントがビーコンを送信しない（ブランド/モデル/設定によって異なります）
• RF障害（これが発生する頻度を考慮していない可能性があります）
• クロックドリフト（実際にはありそうもない）

そのため、「ビーコンタイムアウト」はESPノードで時々発生します。
私は、すべてのプラグイン/コントローラーが短いタイムスライスを使用して、タスクのブロックをできるだけ少なくするように懸命に取り組んでいます。

私はすべてのfraeggleが言ったことを確認することができます。
今夜いつか「接続が失われました」

良い週末を ：）
サシャ

@fraeggle ：
「接続が失われました」と表示された場合は、ESPEasyのコントローラー設定に移動してみてください。コントローラーを無効にして->保存し、再度有効にして->保存してください。 その後、少なくとも私にとっては、再び接続されているように見えます。 解決策ではありませんが、少なくとも興味をそそられます:)このIPSymconはあなたが使用していますか？

@ TD-er：
忙しすぎるタスク？ さて......ここで実行している「テストユニット」では、60秒ごとに稼働時間分を送信するだけです......このユニットではこれ以上実行されていません.....おそらく最小のシステム

@ Sasch600xt 「忙しすぎる」という用語は、実際の問題を説明するのに最適な用語ではないかもしれません。
Arduinoのやり方は次のとおりです。

• setup()電話する
• loop()を何度も呼び出します。

その上、ESP8266（およびESP32 Arduino）のArduinoバージョンは、Arduino部分のloop()外でいくつかのタスクを実行しています。
これらのタスクは、ネットワーク接続や着信トラフィックの処理などのバックグラウンドプロセスに関するものです。
バックグラウンドタスクは、次の場所でのみ実行されます。

• loop()終わり
• Arduinoスペース内からdelay()またはyield()を呼び出す場合。

ループの実行に102.4ミリ秒以上かかり、yield（）またはdelay（）の呼び出しが行われない場合、ESPノードはビーコン間隔を逃しています。
また、WiFiアクセスポイントがビーコンを送信している瞬間に常にビジーであるいくつかのブロッキングタスクを実行している場合、多くのビーコンが失われます。

（デバッグレベルが有効になっている）シリアルログを見ると、タイミング統計が表示されます。
それらのいくつかは数十ミリ秒を作る可能性があり、したがってこれらの「切断」理由を引き起こす可能性があります。

スケジューラーにタスクを追加して、102.4ミリ秒ごとにビーコンをリッスンしようとすることができます。 唯一のことは、そのようなビーコンがいつ見られたかをどうやって見るのかわからないということです。

この問題については、接続が失われたときのMQTTの切断/再接続を調べることができました。
どのブローカーを使用していますか？ ここではMosquitoを使用していますが、現在の動作で正常に動作しています。

わかりました、「忙しすぎる」とは少し簡単に言ってくれました:)

MQTTブローカーのipsymconhousecontroleviromentで実行されているスクリプトを使用しています

グリーツ
サシャ

こんにちはSascha..IOBrokerを使用しています。
@ TD-erはビルド27092018に戻りました。ブローカーはまだ接続されていると教えてくれます...
本当に紛らわしい..14時間以内にエラーはありません（再接続数| 0）

何が起こっているかを確認するために、現在コンピュータにIObrokerをインストールしています。

編集：
45分後、コンピュータでIObrokerを実行できなくなりました。
ここで何が起こっているのかわかりませんが、Windowsインストーラーが機能せず（service batファイルがどこにも見つかりません）、Linuxへのインストールが完了しません。 同じnpmインストールを何度も繰り返し試行し続けます。
IntelCPUホスト上のUbuntu18.04およびWindows上のBashでテスト済み（Ubuntu 18.04）

Windowsではわからない..ソフトウェアの依存関係があると思います。 ラズベリーで実行します。
Windows ioBroker verwendet Node.js als Plattform und setzt diesevorausの場合。 （ダウンロード：http：//nodejs.org/download/）最初のnode.jsをインストールする必要があります。

また、4つのDS18B20センサーが接続された1つのモジュールに問題があります。
私はそれが私の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の後、問題は修正されたように見えます。

THX
T

鉱山は2〜3日後もまだ接続を失っていました。 更新します：ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

どれどれ！

私は接続を失いました。 1〜10時間後。 稼働時間は約10時間30分で、関連するすべてのモジュール（5個）が接続されています。 :-)

安定した接続が必要なため、試してみる価値があるようです...まだ2709のままです。 plsは私に情報を提供し続けます。 :-)）

https://emoncms.org/Edegem/scrtmp2eからフォローして、CV_グラフとSanitair_グラフが存在するかどうかを確認することもできます:)。

1日の稼働時間で、それでも問題ありません。 :-)

https://emoncms.org/Edegem/scrtmp2eからフォローして、CV_グラフとSanitair_グラフが存在するかどうかを確認することもできます:)。

：-DSanitair_warmほぼ60C？ 小さなキャンプファイヤー？ ;-)
私は会社を試してみます..ありがとう...

私はシャワーを浴びていました;-)

1日...まだ接続されています:-D
12112018を使用

〜3日3時間後、私のユニットの1つがMQTT接続を失いました。 ：-（（mega-20181112 4096 VCC fw）

@redskinhu ：
念のため、ユニットがMQTT接続を失った後も正常に機能していますか？
私の側では、「接続が失われました」と表示されているだけですが、すべてのMQTTアクションで正常に機能しているためです。

グリーツ
サシャ

実際、接続が失われることは珍しいことではありません。
人間の介入なしに接続が再構築されている限り、問題はありません。
WiFi接続は時々リセットされ、それを防ぐためにできることは何もありません。
このような接続が失われるとすぐに、同じノード上のMQTTクライアントに再接続するよう通知します。

ある種のLWT関連の問題に見えます。 MQTTは完全に切断されておらず、ESPEasyはMQTTメッセージを送受信しますが、LWTは更新されないため、HomeAssistantはLWT接続メッセージを取得しなかったため、関連するセンサー/スイッチが使用できないことが示されます。 これが私の理論です...

私のはまだ接続されており、私の最初の投稿とは異なり、MQTTLWTでさえ接続されていると教えてくれます。 いいね。

実際、接続が失われることは珍しいことではありません。
人間の介入なしに接続が再構築されている限り、問題はありません。
WiFi接続は時々リセットされ、それを防ぐためにできることは何もありません。
このような接続が失われるとすぐに、同じノード上のMQTTクライアントに再接続するよう通知します。

この場合、接続されているLWTを更新する可能性はありますか？

接続を更新した時点でLWTを送信することになっています。

現在、LWTで切断されて表示されているノードがあり、測定値を正常に送信します。 少し古いビルド...多分これはあなたに何かを教えてくれます

GITバージョン：| メガ-20181008
稼働時間：| 3日17時間36分

ESPノードが切断されて再接続する必要があると判断したときに奇妙なことが見られましたが、ブローカーは同意しません。

こんにちは

ちょっと調べてみました。 LWTだけが問題のようです。 私のESPの1つが、このMQTTの「切断された」ものを再び生成しました。

センサー/スイッチ、すべてが正常に機能しています。 しかし、設定でLWTの詳細を指定したため、HomeAssistantはそれらを表示できませんでした。

- 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をオン/オフにできました。 すべてがOKです。 LWT。

そして、LWTの「接続済み」メッセージを公開した後、すべてが正常に戻りました。

お役に立てば幸いです。

T

PS：
LWTメッセージが切断された場合にLWTConnectedメッセージを公開できる1つのルールについて考えていますが、残念ながらMQTT文字列をインポートできません;-)

とにかく、私は新しいfwリリースを心待ちにしています。 長い4日間...

私は月曜日/火曜日に不在で、その後の日は本当に忙しかったです;）

LWTを調べて、再接続時に公開されない理由を見つけることができるかどうかを確認します。

MQTTブローカーのタイムアウト設定とは何ですか？
ブローカーが接続の喪失を想定している可能性について考えていますが、ESPノードはアクティブであり、接続されているように動作します。

私は100-1000ミリ秒を試しました。 今300。関係ありません。

コントローラーではなく、ブローカーです。
これらのタイミングは10〜15秒のオーダーです。
したがって、使用されているタイムアウトをブローカーの構成で確認してください。

LWTタイムアウトについては何も変更せず、Mosquitto構成に関連する設定が見つかりませんでした。 デフォルトである必要があります。 ドキュメントにもLWTタイムアウト設定が見つかりませんでした。

LWTタイムアウトではなく、ブローカーのタイムアウトです。
クライアントがタイムアウト期間内にメッセージを送信しない場合、ブローカーはメッセージが切断されたと見なします。
したがって、クライアントが別のタイムアウト設定を使用している場合、ブローカーはクライアントが切断されていると見なし、クライアントは再接続を試みない可能性があります。

mqtt仕様から理解できることは、クライアントによって設定されたKeep Alive期間内にクライアントからメッセージを受信しなかった場合、ブローカーは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

それは本当ですが、私が知りたいのは、この「KeepAlivePeriod」がブローカー側で何であるかです。
私はそれがESPeasy側で修正されていることを知っています。
しかし、これらが互いに同期していない場合は、奇妙なことが起こっているのがわかります。

うーん、このようなものを設定する可能性はありません

しかし、それでも「接続済み」と表示されます。 4日:-D

1つのメガ20181006に同じことをさせました。 LWTはオンラインに更新されていませんが、通常は機能しているMQTT

@ jimmys01ブローカーがクライアントIDに基づいて決定を下しているかどうかを確認できますか？ （これは接続が失われると変更されます）
このクライアントIDの変更は、9月下旬のビルドで追加したものです。

@ 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.

2回目の認証解除

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.

OK、クライアントIDの変更を元に戻します。
クライアントが接続されていると見なされるかどうかをリモートで確認することも可能ですか？
ブローカーがクライアントがまだ接続されていると見なし、クライアントが再接続を試みると、接続が拒否されるのを見てきました。
短い間隔で再試行すると、このステータスが維持されるため、クライアントは再接続できなくなります。

これに関するステータスの更新はありますか？

いいえ、まだです。
しかし、私たちは他の安定性の問題について（最終的に）ある程度の進歩を遂げているので、それが私のリストの次になると思います。
pingをありがとう;）

再接続時にクライアントIDを変更することをオプションにしました。 （[ツール] => [詳細]、他のMQTT設定の横）

現在機能している場合は、問題を閉じてください。
固定に設定します。

とにかくクライアントIDを変更するのはなぜですか？

ブローカーがクライアントがまだ接続されていると想定している限り、ブローカーが接続の試行を拒否するという報告がありました。
そのため、クライアントは拒否され、再試行されました。
しかし、どういうわけか、これらの再接続は、接続の試行をそのクライアントの最近のアクティビティと見なすためにブローカー側で何かをトリガーしたため、クライアントが切断されたとは見なされません。

わかりました、これはそれを解決しました、しかし解決策はそのチェックボックスを見る他の人にとって自明ではありません。
たぶん、wifiの喪失後に再接続の問題がある場合にそれをチェックすることを説明するポップアップを追加します
tasmotaの問題を検索すると、MQTTの保持に関連して、ブローカーの問題のように見える同様の問題があったことがわかります。
また、認証を解除した後、1つのクライアントがWi-Fiにまったく再接続していませんでした...それを調査する必要があります。

これをドキュメントに追加し
私たちはドキュメントを最新のものにするために非常に一生懸命取り組んでおり、また多くのドキュメントをwikiからReadTheDocsに移動しています。 これにより、バージョンごとにドキュメントを作成できます。
ドキュメントファイルもGitHubリポジトリに含まれています。

理想的には、コードの修正のコミットには、ドキュメントの更新も含まれます。
この問題を閉じます。
あなたが言及した他の問題についてさらに情報がある場合は、そのための新しい問題を開いてください。

こんにちは

最近、20190110リリースをインストールしました。 それは有望に見えます。 5日間のテスト後、LWTの問題はありません。 :-)
「MQTTは再接続時にClientIdを変更する」オプションが有効になっているノードがいくつかあり、一部は無効になっています。

朗報です！

T