最近行ったシリアルの変更に関係しているようです。

どのgpioピンを使用していますか？

それは、見てみましょう、私はあなたがポイントGijsを見つけたと思います:-)

esp01 = Gpio0 Gpio2（まだ問題は見られません）
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

ピーター

ここに2つのノードがあり、今日の午後にテストすることもできます

Ok、
障害は即時ではなく、しばらくすると送信を停止し、その状態が非常に長く続くため、再起動またはswのダウングレードでは、データを再度送信するのに十分ではありません。 パワーサイクルと、オフとオンの間に時間が必要です。

「しばらくして」はどれくらいですか？
これらのセンサーの1つを使用してノードをセットアップしたところ、BMP280も接続されています。
CO2センサーにはGPIO-14＆-12を使用しています。

数時間、昨日はすべてが機能していましたが、今朝は同じステータスの4つのうち3つがありました。

そして、それらがすべて動作を停止する前に、それらはすべてほぼ同時に起動しましたか？

はい、すべてが1時間以内に再起動/更新され、昨日の夜に更新されていたと思います。 そして夜の間に彼らは仕事をやめました

ノードを更新しようとしていましたが、幸運にもこれに気づきました。 @ TD-erは、あなたが推測しているシリアルへの変更前の最新リリースが原因である可能性がありますか？ または、同じ問題が発生するかどうかを確認するために最新バージョンをフラッシュした方が便利ですか？

不足している更新が大した問題ではない場合は、最新バージョンをお勧めします。
シリアルポートラッパーより前のバージョンを維持するには、20181231を使用できます（今年は変更をコミットしたと思います）

私は昨日3つの「問題のある」espを20181231にダウングレードしましたが、ハードウェアを変更せずにデータを送信していることを確認できます。現在24時間なので、これら3つのespはまだgpio12とgpio14を使用しています。

それをGijsで再現する運はありますか？

いいえ、私のノードはまだ値を送信しており、1月16日からビルドを実行しています。 （コア2.5.0）

私はそれらのノードでESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.binを使用しました。

@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はGpio14 / 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 Temp / 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メガバージョンを実行しているときに再び発生しました。以前と同じesp-logfileのエラー、他のセンサーは正常に動作します

また、19：05に、ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.binで実行されているesp02もクラッシュしました。上記と同じ状況で、データがなくなり、ログに同じエントリがあります。

今日も2回のヒックアップ、esp02とesp18の両方がログの同じ障害で再び失敗しました
関連するソフトウェア2バージョン、0116および0121、2.4.1コアおよび4Mbバージョンの両方
esp02のハードウェアはnodemcu-d1-miniです/ esp18はnodemcu-v2です両方ともgpio12 / gpio14を使用します

ノードの1つでこのビルドを試すことができますか？

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

MH-Z19を搭載したノードの1つで実行されており、稼働時間は54日23時間21分です。
それは停電以来です...
これは、CO2値の定期的な更新で正常に実行されています。

私はこれから、

しかし、バージョンメガ20181231コア2.4.1通常の4Mbまで、報告された安定性の問題はいずれも見られなかったので、なぜこの特定のバージョンなのか、その前にすでに述べましたか？

その特定のバージョンをダウンロードして、eesp02およびesp18 co2測定ノードにインストールしますが、私の謙虚な意見であるGijsの前ではなく、mega-2019 *の範囲で問題が発生しました。

OK、それならそれは本当に役に立たない。

その特定のバージョンは、（悲しいことに）安定しているように見える私が持っているバージョンで実行されています。
そして、その通りです。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であることに気付いたので、それはずっと昔のことで、異なっていますか？

Gijs、

私はこの問題について別の手がかりを見つけたかもしれません。

数分前、ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.binを実行している私のEsp08 A nodemcu ch340V24Mbが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：イベント：Clock＃Time = Wed、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

私がこの障害を見たのはこれが初めてです、多分..

チェックサムエラーは、より適切に処理する必要があります。
たぶん、新しい良いスタートを探すためにシフトを開始するタイミングにいくつかのしきい値を追加する必要があります。
または、再び同期するためのより良いアルゴリズム。
私の知る限り、このコードは1年以上変更されていません。 シリアルポート接続の作成方法が変更されただけなので、なぜこれらの問題が発生するのかはよくわかりません。

私は、mhz19センサー自体が、数時間の通信ミスの後、またはデータを取得できなかった結果として、「ブロックされた」状態になると考えています。 ？
動機：再起動または完全なsw-updateでさえそのステータスを解決しません、mhz19は生命を取り戻すために1分ほど無力でなければなりません、私はそれが次のようなステータスで立ち往生しているときにこの動作を見つけました：
MHZ19：エラー、読み取り中のタイムアウト
MHZ19：不明な応答：0 0 0 0 0 0 0 0 0

障害esp08は今朝、Webコンソールからのリモート再起動オプションでまだ解決可能だったので、数時間見つけて数回報告した後の完全なロックアップと同じではありませんでした。

しかし、後でこれを見つけました：
現地時間の約1800時に、ブロック状態になり、リセットし、コンソールの電源を入れ直して再起動しました。今回は何も機能しませんでした。デバイスはメガ20181231 4mbバージョンで再フラッシュする必要があり、その後再び動作しました。 Esp08はGpio12 / 14の組み合わせを使用しており、nodemcu v2ch340モデルでもあります

プラグインは新しいセンサーデータを収集するコマンドをMH-Z19に送信するため、非常に奇妙に聞こえます。
そのため、ソフトリブートでさえ機能しない理由がわかりません。
チェックサムエラーが発生する頻度を確認するために、いくつかの統計情報も追加します（受信側）
それが頻繁に発生する場合は、センサーにデータを送信するときにも発生する可能性があり、センサーが不明なコマンドモードに移行する可能性があります。
シリアルピンの構成方法を変更したときに、プルアップ抵抗の構成が変更された可能性がありますか？

かもしれない、

明日、または次の週末にそれをもう少し調べて、おそらく私は何かを見つけることができるでしょう、そのセンサーはそれほど広く使用されていないので、誰も同じ行動に苦しんでいませんか？

または、最新のビルドを実行している人は使用しません

私は2つのMH-Z19bを持っていますが、どちらも20190116テストビルドで問題なく実行されています

さて、テストビルドのどのコアバージョンとどのGpioを使用しているのか正確に知りたいですか？

1つはESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.binを実行しており、もう1つはESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.binを実行しています。 GPIO13および12に接続された両方のセンサー

つまり、これは別のコアであり、GPIO14 / 12の代わりに13/12を使用している他のGPIOです。ここで使用します

今日、私は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が再びロックされ、Webコンソールの再起動が機能せず、電源を切る必要がありました。
もう1つはまだ機能していますが、MHZ19もフリーズした場合はここに追加します

はい、もう1つのesp18は今夜19:05に妥当なCO2データの送信を停止したため、昨日のメガ202コア2.4.1では少なくとも障害が持続しています。
それが戻ってきて、20181231バージョンにアップグレードされました。

真夜中頃、3番目のesp、esp02はCo2の測定値で凍結し、これも20181231にダウングレードされました

ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.binでまだ実行されているのはGpio-0 / Gpio-2を使用しているものだけで、フリーズした他の3つはGpio14 / gpio12を使用しています。
これはもう偶然ではないと思いますが、

私はesp02の配線をGpio-0 / Gpio-2に変更し、それを0202バージョンのコア2.4.1に再度アップグレードします。このgpio変更後も、それが有効であるかどうかを確認できます。
終わり

読み取りを改善するためのコミットを追加しました。
https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7cを参照してください

そのためのテストバージョンを作成できますか、それとも私に作成してもらいたいですか？

あなたが私にビンを提供することができれば、私はespを実行しているgpio12 / 14の両方にそれを置いて幸せになります
そして、ファイルが同じであり、ローカルの影響などがないことは確かです。

OK、少し時間がかかりましたが、これがテストビルドです

とった、

現在、Esp08とesp18は2.4.1コアを備えたこのテストバージョンで実行されており、どちらもgpio12 / 14を使用しています。

どれどれ ！

また、処理された行数とCRC障害の数を示すインジケーターも表示されます。

はい、私も今コンソールにそれらを持っています！

それらの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およびメガ20190202バージョンコア2.4.1にmhz19を搭載しています。

バマーは誤ってここの投稿を削除しました、私の記憶から再作成してみてください：

昨日の夕方、私のespの02、08、18の3つがDomoticzで赤くなり、Co2センサーデータはありませんでした。
それらのうちの2つには、特別バージョンのコア2.4.1とgpio12 / 14があります。 Webコンソールの再起動はそれを解決せず、生成されただけです：MHZ19：不明な応答：0 0 0 0 0 0 0 0 0しかし、esp18 co2測定値は、約1時間後に寿命を取り戻し、0：56に再び適切な値を送信し始めました。

Esp08も再起動を受け取り、esp02も（gpio0 / 2がesp01と同じになっている）両方とも回復せず、今朝は両方とも2分間の電源切断が行われ、その後両方とも正常に動作しました。

esp02のソフトウェアバージョンをESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4に変更したので、コアバージョンもテストできます。gpiochnageは、古い（現在の2.4.1）バージョンの実行に違いはありませんでした。
esp02は、今日、単一のチェックサム障害を示しました。チェックサム（合格/不合格）：| 79/1

また、esp08のsyslogを最初にアクティブにしましたが、以下の設定が必要です。特定の設定が必要な場合は、お問い合わせください。

たぶん、あなたはまた、以下を示す投稿であなたの設定を項目化することができます（次の投稿でもありえます、これを編集する必要はありません）：

• あなたの内部ユニットnr（「02、08、18」のようなあなた自身の参照のために）
• 実行中のビルド
• 成功/失敗のnr（利用可能な場合）
• 一種の失敗/問題

項目別の情報は、説明文に比べて（私にとっては）わかりやすいです。
私も時々電話から返信します。

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

-凍結とは、CO2測定値を除いて正常に動作することを意味します

22:57 esp08が再びフリーズし、チェックサム（合格/不合格）に対抗：| 1077/2は、見つかったときにsyslogを脇に置きます。
05:05 esp18が再びフリーズし、チェックサム（合格/不合格）に対抗：| 1076/2
06:25 esp08が再びフリーズし、カウンターがなく、今回はespが完全にクラッシュし、syslogを取得しました
12：57esp18が再びフリーズしました。 カウンターチェックサム（合格/不合格）：| 116/2
20:43 esp18が再びフリーズし、チェックサム（合格/不合格）に対抗：| 316/2がmhzresetコマンドを試しました
変更はありません。センサーはmhz19の不明な応答を送信しています00 0 0 0 0 0 0
メッセージを何度も繰り返し、解決策がないまま何度か試行し、ノードの電源を入れ直しました。

Gijs、

私はesp08の最後のsyslogでいくつかの分析を行いました。それが実行されている時間の間に、78回の発生が見られました。
2019-02-08T05：27：07.581181 + 01：00hub08 EspEasy --- --EspEasy：MHZ19：不明な応答：ff 0 0 0 0 0 0 0 0

#catメッセージを使用した自動検索-crash-esp08-0625 | grep MHZ19 | grep応答| grep'ff 0 0 0 0 0 0 0 0 '| wc -l

そして、そのコマンドラインを2番目の不明な応答バリアントに変更した後、Linuxはこのラインの408倍をカウントしました。
2019-02-08T10：44：06.855432 + 01：00hub08 EspEasy --- --EspEasy：MHZ19：不明な応答：0 0 0 0 0 0 0 0 0

custom-debug-versionのチェックサムエラーカウンターは、過去2日間に見た限り、2を超えることはありませんでした。
最初のエラーメッセージ（MHZ19：不明な応答：ff 0 0 0 0 0 0 0 0）は、今朝フリーズする前に、6回ほどの直後に次々と表示されました。

センサー自体がクラッシュしているように見えますが、今それが起こっている理由は考えられません。
私たちのソースには、MH-Z19センサーのリセットを呼び出すためのコマンドがありますが、それはデータシートに記載されていません。
だから私はその状態を知りません。
このようにスタックしているノードでそのコマンドを呼び出してみてください。

編集：そのコマンドはmhzresetです

メガ201812312.4.1の後にいくつかの変更を加える必要があります。 私がまだ見つけた限り、MHZ19でこの結果を持っている4Mbバージョン。 その1つは、gpio12 / 14でも問題なく数週間実行されています。

次回何かが機能しなくなったときに試してみます。23：20にesp18がフリーズしていることがわかりましたが、mhzresetはそれを変更しませんでした。上記のログを参照してください。

mhzresetコマンドは、Webコンソールでコマンドウィンドウを開かず、syslogで何度か試行した後、[OK]などを報告しません。
<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：センサーリセットを送信しました！
送信されたと言うのはとても簡単ですが、mhz19が理解したり気に入ったりするフレーバーではないようです:-)

そのコマンドは、MH-Z19Aバージョンに対して何かを行うようです。

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はsystlogを脇に置きます。

念のために言っておきますが、これらのノードは古いファームウェアバージョンで正常に実行されていましたか？

はい、ESP_Easy_mega-20181231_normal_ESP8266_4096までは問題ありませんでしたが、引き続き問題ありません。
彼らは何週間も問題なく走りました

SWserialライブラリの最近の変更を調べました。これは、現在使用しているものだからです。
そこで行われた変更の1つは、9600ボーのTX転送で割り込みを使用しないことでした。
このテストビルドを試すことができますか？

注意：コア2.5.0ビルドも削除しました。これは、Webページを提供するときに奇妙な動作をするためです。

ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.binを実行しているEsp08およびEsp18
これらの2つは、データをsyslogサーバーに送信するため、ログデータが記録されます。

他の2つは明日続きます、それらの1つはMhz19Aであるかもしれません、そしてそれはそうです。

Hwconfigは次のようになりました。
Esp01のMHZ19Aはgpio0 / gpio2にあります
Esp02のMHZ19Bはgpio0 / gpio2にあります
Esp08にはgpio12 / gpio14にMHZ19Bがあります
Esp18にはgpio12 / gpio14にMHZ19Bがあります

それらはすべて、espの同じテストバージョンにあります-簡単に実行できます：
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

アップデート

06:01 esp08が再びフリーズし、カウンターが失われました（ユーザーが原因）syslogを脇に置きました。

05:21 Esp18がフリーズ、チェックサム（合格/不合格）：| 1460/0、syslogを脇に置いた
12:53 Esp08凍結、チェックサム（合格/不合格）：| 1351/28、syslogを脇に置いた

コア2.4.1ビルドはそのテストビルドに含まれていなかったので、そのコアバージョンのみを含むものを作成しました。 ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.binと同じコードのコア2.4.1ビルド
これは、古いバージョンのSoftwareSerialライブラリを使用しています。
それが機能している場合は、使用されているSWシリアルライブラリを変更します。

特別バージョンへのアップグレードを開始します：4つのノードすべてのfirmware.binは、12：30に終了しました

私が最初に気付いたのは、Esp08がフリーズし、このファームウェアアップデートがMHZ19Bを再起動し、それが元に戻ったことです。つまり、センサーが妥当なC02値を与えてくれます。これもはるかに速いようです。

私はテストノードでも古いSWserialライブラリを実行していますが、実際にははるかにうまく機能しています
たとえば、イーストロンのエネルギー監視では、受信した回線の約20〜30％が破損していましたが、これは現在完全に実行されています。 （失敗したチェックサムはまだありません）

HW / SWシリアルラッパーに関して多くの変更を加えた新しいテストビルドを作成しました。
SWserialとHWシリアルの両方でEastronプラグインで動作するようになり、SWserialは20180131まで使用していた古いライブラリを使用するようになりました。

したがって、これは実際には0202バージョンと同じですが、20181231バージョンと同じシリアルライブラリを使用して、直接アップグレードします..ちょっと待ってください

インストールされたESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
今Esp0 / 02/08/18に

どれどれ ..

はい、HWserial / SWserialラッパーが付いているので、正しいピンを使用するとすぐにHWserialに簡単に切り替えることができます。

HWserial0の追加オプションとしてGPIO2を追加する必要がありますが、コードで行う必要のあるクリーンアップがまだいくつかあります。

彼らが過ぎた最初の時間はまだ働いているので、最後の更新の後、私は未知のものを見ることができません
esp08またはesp18からのsyslogの応答ff7 x0または8x0メッセージはもうありません。

2つのノードのsyslog-dataを調べるのに少し時間がかかりました。
Esp08にはまだ不明な応答があり、コードがたまに変化しますが、
Esp18はまだ障害を生成していません

聞いて良かった。
センサーに送信されたデータが破損するという問題があったと思います。
そうするとセンサー自体がクラッシュするかもしれませんね。

Eastronプラグイン（より多くのデータを送信する）を使用すると、チェックサムエラーの数が大幅に減少しました。
SWserialを使用すると、メッセージの約20〜30％のCRCエラーからほぼ0まで。（10,000メッセージで1エラー）。

まだ正常に動作していますが、4つすべて

リリース20190215の修正リストを見ると、そのバージョンは、ここで4つのCo2測定ノードで実行しているバージョンと同じですか？

ほぼ同じ。
少なくともシリアルポートとプラグインのコードは同じです。

それから私はそれをそのままにして、「特別な」でテストを続けます

リリースに含まれているものと含まれていないものがわかりませんでしたが、いくつかの数字は一致していました。

うん、昨日マージした大きなPRは、先週行ったすべてのテストビルドのソースでした。

Esp08は14:17にフリーズし、チェックサム（合格/不合格）に対抗します：| 3292/70、syslogはさらなる分析のために取っておかれる

そして、ノードの単純な再起動（または設定の保存）でセンサーを再起動しましたか（電源を切るのではありません）？

次回は、カウンターを確認してから電源を入れ直してみます。

Esp08が再びフリーズし、チェックサム（合格/不合格）に対抗します。 2660/55

co2-deviceパラメータを保存すると、フリーズが解決されました。

Esp08 18:18が再びフリーズし、チェックサム（合格/不合格）に対抗します：| 2660/55

co2-deviceパラメータを保存すると、フリーズが解決されました。

OK、リセットが可能です。
N個の不明な応答のチェックを追加してから、initを再度実行します。

それはこの問題を完全に解決するかもしれません。

今のところ、それらすべてで発生していたシリアルの問題全体が、modelAと3つのMhz19Bモデルセンサーのうちの2つで発生したようです。
モデルBであるEsp08は、変数「不明な応答（変更されるたびに）16進値」がログファイルに残っているのを私が見た唯一のものです。このセンサーが悪い動作をしているときにプラグインからリセットされる可能性がある場合、それが解決策かもしれません。

すべてをMega2019020264Mbに今すぐアップグレードします。

私が最初に気付いたのは、Co2センサータイプmhz19Bが、新しい画像をフラッシュした直後に正しい値を提供していることです。これは、以前よりもはるかに高速です。

これは本当に有望に聞こえます！ 私はこのスレッドを見ていて、ようやくアップグレードできるようになるまでしばらく待っていました。 ：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のレポートをしばらく待つつもりでした（怠惰な私）。

現在のビルドから多くの変更があり、残念ながらすべてがポジティブというわけではないことを知っておいてください。
私たちがまだ取り組んでいる問題の1つは、ハードウェアウォッチドッグの再起動です。 したがって、現在の設定のバックアップを保持し、使用している現在のバージョンを書き留めておくことをお勧めします。 念のために。
今日の修正によってこれらの再起動を少し改善したいと思っていますが、これらの再起動にはいくつかの異なる原因があるため、今日の修正ですべてが処理されるとは思いません。

メモを取る。 ESPEasyのようなシステムでリグレッションを回避することの難しさを想像することしかできません。 アップグレードを行った後、リグレッションを報告します（もちろん別の問題として）。

ここにある2つのESPをアップグレードすることを計画しています。 それらだけに基づいて、MH-Z19、PMSx003、BMx280、TSL2561、DHT22センサー、またはOLEDSSD1306ディスプレイの処理にリグレッションがあるかどうかを観察できます。 他のESPのTSL2561も、ランダムにデータを返すのを停止する傾向があります（ただし、非常にまれです）。 ビルド「20102-メガ」を実行しています。

これはビルドではありませんが、内部ファイル形式です（私が知っているのは紛らわしいです）ビルド名/日付はsysinfoページにあります。

少なくとも「ビルド」フィールドにあります。 バイナリファイル名は「ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames」です。 私はおそらくPlatformIOから直接フラッシュしました。 ほぼ1年前と同じバージョンをフラッシュするのが難しいかもしれません。 タグは言うまでもなく、実際には何もメモしていません。 ：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.2PUYAサポート
Gitビルド：⋄| メガ-20191003
プラグイン：⋄| 46 [通常]
Md5をビルドする：| 3180a4d3e118166b3414444513a6169
Md5チェック：| 合格しました。
ビルド時間：⋄| 2019年10月3日02:15:29
バイナリファイル名：⋄| ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

ありがとう

うんと以前のバージョンも。
10月のものには他の問題があったので（先週かそこらで修正しています）、20190928ビルドで試してみることをお勧めします

プラグインページが数時間実行された後、プラグインページに表示される読み取りエラーの数を確認することもできます。

たとえば、自分のユニットの1つ（3日間の稼働時間）

注意：フィルター（スクリーンショットで「不安定を使用」に設定）は、MH-Z19Bセンサーでは意味がなく、-Aバージョンにのみ適用されます。

そしてもう1つ：

ご覧のとおり、失敗した読み取りの数は最小限です。
そこにエラーがある場合は、別の問題が発生している可能性があります。

プラグインを出し入れせずに再度起動しようとすると、これらの11のリセットが発生しますが、エラーが発生したことは覚えていませんが、別のショットを与えることができます。ソフトウェアシリアルを使用する必要がありますか？

ハードウェアシリアルの方が優れていますが、[ツール]-> [詳細設定]-> [シリアルポート]でシリアルポートを無効にする必要もあります。 （スクリーンショットに記載されているように:)）

ボード上の現在のUSB-シリアルアダプタが通信に影響を与える可能性があるかどうかはわかりません。
疑わしい場合は、ソフトウェアシリアルに変更できます。

ビルド：ESP_Easy_mega_20201130_normal_ESP8266_4M1M
FHEMへの報告。
同様の問題がありました。ハードウェアシリアルを使用すると、MH-Z190Bセンサーが数時間ごとにフリーズし、400に低下し続けます。
ソフトウェアシリアルに切り替えた後、それは正常に動作しているようで、もうフリーズしません。
2つのスクリーンショットが添付されています。

I2Cに接続されたBME280は正常に動作し、常にレポートを続けます

うーん、それは奇妙だ。
どのHWシリアルポートに接続されましたか？
ボードには他に何が接続されていますか？ （例：USBからシリアルチップ）
[ツール]-> [詳細設定]ページで[シリアルを使用]がオフになっていますか？

TXD0とRXD0を使用してUSBポート（CH340 ）Wemos D1miniの。
「シリアルを使用」は「シリアル設定-シリアルポートを有効にする：」がチェックされていることを意味しますか？ USBでメッセージを読めるように、これをチェックしたままにしました。

ESP8266のHWシリアルはSerial0を使用します。
同じシリアルポートにもログを送信すると、ログがそのポートを介して送信されたときに受信する「コマンド」を認識できないため、センサーがクラッシュする可能性があります。

HWシリアルポートに何かを接続する場合は、他のデータを送信しないでください。 したがって、ツール->詳細ページで「シリアルを使用」を無効にする必要があります。

昨日、2つ目のセンサーMH-Z19Cを入手しました。 これは、Serial2のHW-Serialで正常に動作するようです。 センサーはすべてピンD7（GPIO 13）とD8（GPIO 13）（RXD2とTXD2）に接続されていたので、私がいる限り、Serial0（ピンRXD0（GPIO3）とTXD0（GPIO1））と競合することはありません。ピン配置を理解する。 最初のセンサー（別のサプライヤーのMH-Z19B）は、まったく正しく機能していない偽物だったと思います...
したがって、これらのセンサーを購入するときは注意してください。 2つ目は、昨日入手した、Winsenロゴとテスト証明書が追加されたはるかに優れたパッケージでした。 サプライヤーは私に最初のものを売ったものよりも真剣なようです。