Scheint mit der Änderung der Seriennummer zusammenzuhängen, die ich kürzlich vorgenommen habe.

Welche GPIO-Pins verwendest du?

Es könnte sein, mal sehen, ich denke, Sie haben einen Punkt Gijs gefunden :-)

esp01 = Gpio0 Gpio2 (noch keine Probleme gesehen)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Peter

Ich habe hier zwei Knoten, die ich auch später am Nachmittag testen kann

OK,
Der Fehler tritt nicht sofort auf, sie hören nach einer Weile auf zu senden und bleiben ziemlich hartnäckig, da ein Neustart oder ein sw-Downgrade nicht ausreicht, um sie dazu zu bringen, wieder Daten zu senden. Sie brauchen einen Powercycle und etwas Zeit zwischen Aus und Ein.

Wie lange ist „nach einer Weile“?
Ich habe gerade einen Knoten mit einem dieser Sensoren eingerichtet und auch ein BMP280 ist angeschlossen.
Es verwendet GPIO-14 & -12 für den CO2-Sensor.

Ein paar Stunden, gestern funktionierte alles, heute morgen hatte ich 3 von 4 mit dem gleichen Status.

Und sie haben alle ungefähr zur gleichen Zeit gebootet, bevor sie alle aufgehört haben zu arbeiten?

Ja, alle wurden innerhalb einer Stunde neu gestartet/aktualisiert, glaube ich, habe sie gestern Abend aktualisiert. und während der Nacht hörten sie auf zu arbeiten

Ich wollte gerade meine Knoten aktualisieren, habe dies aber zum Glück bemerkt. @TD-er, was wäre die neueste Version vor den Änderungen an Serial, von denen Sie vermuten, dass sie der Schuldige sein könnten? Oder wäre es nützlicher, wenn ich die neueste Version flashe, um zu sehen, ob das gleiche Problem auftritt?

Wenn fehlende Updates keine große Sache sind, würde ich die neueste Version vorschlagen.
Um die Version vor dem Serial Port Wrapper beizubehalten, könnten Sie 20181231 verwenden. (Ich glaube, ich habe die Änderungen dieses Jahr übernommen.)

Ich habe gestern die 3 "problematischen" ESPs auf 20181231 heruntergestuft, kann bestätigen, dass sie immer noch Daten ohne Hardwareänderungen senden, jetzt für 24 Stunden, sodass diese drei ESPs in meinem Fall immer noch gpio12 und gpio14 verwenden

Irgendein Glück mit der Neuerstellung von Gijs?

Nein, mein Knoten sendet immer noch Werte und führt den Build vom 16. Januar aus. (Kern 2.5.0)

Ich habe die ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin auf diesen Knoten verwendet, die den 2.4.1-Kern hat, glaube ich?

@pwassink Das ist richtig.
Sie können den Core-Build auch auf der Sysinfo-Seite sehen.

Ich habe diese Version ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin zurück zum esp02 hier installiert, mal sehen, ob es wieder passiert

Hmm,
Vielleicht hat der Wochentag oder die Position des Mondes einen gewissen Einfluss,
Ich habe in den letzten Tagen nicht gesehen, dass der Fehler hier wieder auftritt.

Auch hier scheint es gut zu funktionieren.
Es war gerade Vollmond, als du es gemeldet hast, also denke ich, das hätte es sein sollen ;)

Aktualisieren,

ich habe esp02 mit der Version ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin laufen lassen, die immer noch so läuft, wie sie sollte.

Gestern habe ich den Rest meiner Knoten auf ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin aktualisiert

Und esp-18 ging um 06:55 Ortszeit wieder bozo, alles funktioniert wie es sollte, außer dem MHZ19 Co2-Sensor, der auf der Registerkarte Geräte den "letzten bekannten guten Wert" ab ca. 07:00 und wieder anzeigt mit den gleichen Einträgen im Logfile :
MHZ19: Fehler, Timeout beim Leseversuch
MHZ19: Unbekannte Antwort: 0 0 0 0 0 0 0 0 0

Esp-18 verwendet Gpio 14 / 12
es ist ein Nodemcu mit Ch340 Version 2 von 3 von ali
Der Remote-Neustart über die Webkonsole hat das Problem nicht behoben
wieder zeigt es die oben genannten Einträge mehrmals an
Nach Powercycle
78640: MHZ19: Fehler, Timeout beim Leseversuch
78641: MHZ19: Lesefehler: Prüfsumme = 202 / 0 Bytes gelesen => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: Um 1 Byte verschoben, um zu versuchen, die Pufferausrichtung zu korrigieren
Nach einiger Zeit:
255652: MHZ19: PPM-Wert: 1584 Temp/S/U-Werte: 25/0/0,00
255656: EREIGNIS: Rik-CO2#PPM=1584,00
255656: EREIGNIS: Rik-CO2#PPM=1584,00 Verarbeitungszeit : 1 Millisekunde
255659: EREIGNIS: Rik-CO2#Temperatur=25.00
255659: EREIGNIS: Rik-CO2#Temperatur = 25,00 Verarbeitungszeit : 1 Millisekunde
255662: EREIGNIS: Rik-CO2#U=0.00
255662: EREIGNIS: Rik-CO2#U=0,00 Verarbeitungszeit : 1 Millisekunde

Es scheint jetzt wieder zu funktionieren, brauchte aber beim Powercycle ca. 2 Minuten keinen Strom

Muss es in diesem Moment etwas tun? Kann es etwas sein, was zu einem Schluckauf des WLANs auf dem ESP führen könnte?

Gar nichts,

Zu diesem Zeitpunkt gibt es keine geplanten Resets, Neustarts, Backups, WFI-Resets, DHCP-Bereinigungen oder andere externe Gründe

Und das WLAN funktioniert weiterhin gut, es ist nur das Auslesen des mhz19, das stoppt, alle anderen (i2c-basierten) Sensoren auf demselben ESP funktionieren noch

Heute Morgen um 03:00 passierte es wieder mit Esp-18 mit der 0121 Mega-Version. Dieselben Fehler im ESP-Logfile wie zuvor, andere Sensoren funktionieren einwandfrei

Und um 19:05 ist auch der esp02 mit dem ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin abgestürzt, gleiche Situation wie oben, keine Daten mehr und gleiche Einträge im Logging.

Wieder 2 Schluckauf heute, esp02 und esp18 gingen beide schief, wieder dieselben Fehler im Protokoll
Software 2 Versionen betroffen, 0116 und 0121, beide 2.4.1 Core und 4 MB Version
Hardware von esp02 ist ein nodemcu-d1-mini / esp18 ist ein nodemcu-v2 beide verwenden gpio12/gpio14

Können Sie diesen Build auf einem Ihrer Knoten ausprobieren?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Es läuft auf einem meiner Knoten mit einem MH-Z19 und hat jetzt eine Betriebszeit von 54 Tagen 23 Stunden 21 Minuten
Seit einem Stromausfall...
Dieser läuft gut mit regelmäßigen Updates des CO2-Wertes.

ich werde,

Aber habe ich bereits erwähnt, dass bis Version Mega 20181231 Core 2.4.1 Normal 4 MB keine der gemeldeten Stabilitätsprobleme aufgetreten sind, warum also diese spezielle Version?

Ich werde diese spezielle Version herunterladen und auf eesp02- und esp18-CO2-Messknoten installieren, aber die Probleme traten meiner bescheidenen Meinung nach nicht früher im Mega-2019 * -Bereich auf Gijs ..

OK, dann nützt es in der Tat nichts.

Diese spezifische Version läuft auf einer Version, die ich habe und die (leider ungewöhnlich) stabil zu sein scheint.
Und du hast Recht, wenn es bis 20181231 gut lief, dann lohnt es sich nicht wirklich, die älteren auszuprobieren.

Nichtsdestotrotz,
Esp02 und esp18 laufen jetzt auf ESP_Easy_mega-20181109_normal_ESP8266_4096.bin
Esp01 und Esp08 laufen auf ESP-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

Und wir werden sehen

Anmerkung, mir ist gerade aufgefallen, dass die 1109-Version die Build-Nummer 20102 hat, also ist das weit zurück und anders?

Gijs,

Ich könnte einen anderen Hinweis zu diesem Problem gefunden haben.

Vor ein paar Minuten hat mein Esp08 A nodemcu ch340V2 4Mb, auf dem ESP-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin ausgeführt wird, aufgehört, auch co2data zu senden.

Protokollausschnitt
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: Lesefehler: Prüfsumme = 120 / 248 Bytes gelesen => 255/134/5/183/71/128/15/112/248/
370515677: MHZ19: Um 1 Byte verschoben, um zu versuchen, die Pufferausrichtung zu korrigieren
370517702: EREIGNIS: Uhr#Zeit=Mi, 12:19
370517755: EVENT: Clock#Time=Mi, 12:19 Verarbeitungszeit : 53 Millisekunden
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

Dies ist das erste Mal, dass ich diesen Fehler sehe, vielleicht ..

Ein Prüfsummenfehler sollte eleganter behandelt werden.
Vielleicht sollten wir eine Schwelle hinzufügen, wann wir mit dem Schalten beginnen sollten, um nach einem neuen guten Start zu suchen.
Oder ein besserer Algorithmus, um wieder synchron zu werden.
Soweit ich weiß, hat sich der Code dafür seit über einem Jahr nicht geändert. Es hat sich nur die Art und Weise geändert, wie die serielle Schnittstelle hergestellt wird, daher weiß ich wirklich nicht, warum dies zu diesen Problemen führt.

Ich habe die Idee, dass der mhz19-Sensor selbst nach ein paar Stunden Fehlkommunikation in einen "blockierten" Zustand übergeht oder weil er keine Daten abrufen kann. ?
Motivation: Ein Neustart oder sogar ein vollständiges SW-Update löst diesen Status nicht, der mhz19 muss für eine Minute oder so stromlos sein, um das Leben wiederzuerlangen. Ich habe dieses Verhalten festgestellt, wenn er in dem Status feststeckt, der wie folgt aussieht:
MHZ19: Fehler, Timeout beim Leseversuch
MHZ19: Unbekannte Antwort: 0 0 0 0 0 0 0 0 0

Der Fehler esp08 war heute Morgen war immer noch mit einer Remote-Neustart-Option von der Webkonsole lösbar, also war es nicht dasselbe wie die vollständige Sperrung nach mehreren Stunden, die ich gefunden und ein paar Mal gemeldet habe.

Habe aber hinterher das gefunden:
um ca. 1800 Ortszeit ging es in den blockierten Status, zurücksetzen, Neustart durch Konsolen-Powercycle, diesmal funktionierte nichts, Gerät benötigte einen erneuten Flash mit Mega 20181231 4mb-Version, dann wurde es wieder zum Leben erweckt. Esp08 verwendet die Gpio12/14-Kombination und ist auch ein nodemcu v2 ch340-Modell

Es klingt ziemlich seltsam, da das Plugin einen Befehl zum Sammeln neuer Sensordaten an die MH-Z19 sendet
Ich verstehe also nicht, warum auch ein Soft-Reboot nicht funktioniert.
Ich werde auch einige Statistiken hinzufügen, um zu sehen, wie oft ein Prüfsummenfehler auftritt (empfangendes Ende).
Wenn das häufig passiert, kann es auch passieren, wenn Daten an den Sensor gesendet werden und der Sensor dann möglicherweise in einen unbekannten Befehlsmodus versetzt wird.
Vielleicht hat sich eine Pull-up-Widerstandskonfiguration geändert, als ich die Art und Weise geändert habe, wie serielle Pins konfiguriert sind ???

Es könnte,

werde morgen mal weiter nachforschen oder am kommenden wochenende vielleicht finde ich ja was, ist der sensor nicht so weit verbreitet, dass niemand ein identisches verhalten zeigt ?

Oder nicht von Leuten verwendet, die die neuesten Builds ausführen

Ich habe 2 MH-Z19b, beide laufen auf 20190116 Test Build ohne Probleme

Ok, nur neugierig, welche Core-Version des Test-Builds und welche Gpios Sie verwenden?

Ich sehe, dass 1 ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin läuft, das andere ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. An beiden Sensoren an GPIO 13 & 12 angeschlossen

Das ist also ein anderer Kern und ein anderer GPIO, den Sie verwenden, 13/12 anstelle von GPIO 14/12, den ich hier verwende

Heute habe ich 4 von 4 auf die Version ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin aktualisiert

mal sehen

Wenn ich so darüber nachdenke, könnte es seit Anfang dieses Jahres eine weitere Änderung in der verwendeten SWserial-Bibliothek geben.
Früher hatten wir unsere eigene Version der SWserial-Bibliothek, die ich gepatcht habe, um weniger iRAM-Speicher zu verwenden.
Aber jetzt verwenden wir die Version, die in der Kernbibliothek enthalten ist, und für den Kern 2.5.0 ist dies möglicherweise eine neuere Version als zuvor.
Außerdem kann es einige Änderungen bei der Verwendung von Interrupts bei langsamen Verbindungen geben. (9600 Baud und niedriger)
das muss ich mir auch anschauen.

Es erklärt immer noch nicht, warum der Sensor anscheinend so durcheinander gebracht werden kann, dass er ausgeschaltet werden muss, um wieder normal zu funktionieren.

Innerhalb von 3 Stunden nach dem Update auf ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin war mein esp18 wieder gesperrt, der Neustart der Webkonsole funktionierte nicht, das Herunterfahren war erneut erforderlich.
das andere funktioniert noch, wird hier hinzugefügt, wenn es die MHZ19 auch einfriert

Ja, der andere esp18 hat heute Abend um 19:05 Uhr aufgehört, vernünftige CO2-Daten zu senden, also ist der Fehler zumindest im gestrigen Mega 202-Kern 2.4.1 hartnäckig.
Dieser ist zurück und wurde jetzt auch auf die Version 20181231 heruntergestuft.

Gegen Mitternacht ist der dritte esp, esp02, mit den Co2-Messwerten eingefroren, jetzt auch auf 20181231 heruntergestuft

Der einzige, der noch auf ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin läuft, ist der, der Gpio-0/Gpio-2 verwendet, die anderen drei, die eingefroren sind, verwenden Gpio14/gpio12.
Ich glaube nicht, dass das ein Zufall ist,

Ich werde die Verdrahtung von esp02 auf Gpio-0/Gpio-2 ändern und es erneut auf die 0202-Version Core 2.4.1 aktualisieren, und wir werden sehen, ob das nach dieser gpio-Änderung am Leben bleibt.
Getan

Ich habe gerade ein Commit hinzugefügt, um das Lesen etwas zu verbessern.
Siehe https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

Können Sie eine Testversion dafür erstellen oder möchten Sie, dass ich eine baue?

Wenn Sie mir einen Behälter zur Verfügung stellen könnten, würde ich ihn gerne auf beide setzen, die noch auf gpio12/14 mit ESPs laufen
und dann ist es sicher die datei ist die selbe, keine lokalen einflüsse etc..

OK, hat etwas gedauert, aber hier ist der Testaufbau

Habe es,

Esp08 und esp18 laufen jetzt auf dieser Testversion mit dem 2.4.1 Kern, beide verwenden gpio12/14

Mal sehen !

Sie sollten auch eine Anzeige sehen, die die Anzahl der verarbeiteten Zeilen und die Anzahl der CRC-Fehler anzeigt

Ja, ich habe sie jetzt auch in der Konsole!

wird diese 2 verlassen und in bestimmten Intervallen sehen, ob diese Zähler steigen.
Auf dem Laufenden halten ..

Beide an den Testknoten verwendeten Sensoren sind B-Versionen, sodass auch die Erkennung funktionierte

Prüfsumme (bestanden/nicht bestanden): | 11/0
-- 08 --
Erkannt: | MH-Z19B

Prüfsumme (bestanden/nicht bestanden): | 8/0
-- 18 --
Erkannt: | MH-Z19B

Hast du auch einen Mix aus MH-Z19 A/B oder nur die neueren B-Versionen?
Es sollte keine Rolle spielen, nur neugierig.

Hast du auch einen Mix aus MH-Z19 A/B oder nur die neueren B-Versionen?
Es sollte keine Rolle spielen, nur neugierig.

B-Versionen, habe gerade diese Info hinzugefügt, die Erkennung hat auch funktioniert :-)

kleines update, alle laufen noch einwandfrei, die mit eurer speziellen version esp8 und 18 zeigen steigende zähler aber noch keine fehler oder checksummenfehler, aktuelle werte sind:

Esp08: Prüfsumme (bestanden/nicht bestanden): | 1795/0
Esp18: Prüfsumme (bestanden/nicht bestanden): | 724/0

und das andere, das ziemlich konsequent fehlgeschlagen ist, esp02 läuft jetzt auch noch mit den geänderten Gpio's
und somit hat di-mini jetzt die mhz19 auf gpio-0/gpio-2 und mega 20190202 version core 2.4.1

Schade, dass der Beitrag hier versehentlich gelöscht wurde. Versuchen Sie, ihn aus meiner Erinnerung neu zu erstellen:

Gestern Abend gingen drei meiner esp's 02, 08 und 18 auf Domoticz auf Rot, keine Co2-Sensordaten.
zwei von ihnen haben die spezielle version core 2.4.1 und gpio 12/14. Ein Neustart der Webkonsole hat das Problem nicht gelöst und nur Folgendes erzeugt: MHZ19: Unbekannte Antwort: 0 0 0 0 0 0 0 0 0, aber esp18-CO2-Messungen wurden nach ca.

Esp08 hat auch einen Neustart erhalten, und esp02 auch (das gpio0/2 hat jetzt das gleiche wie esp01), beide haben sich nicht erholt, und heute morgen wurden beide für 2 Minuten heruntergefahren, danach sind beide wieder zum Leben erwacht.

Ich habe jetzt die Software-Version auf esp02 auf ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 geändert, damit wir diese Core-Version auch testen können, die gpio-Änderung hat keinen Unterschied gemacht, wenn die alte (aktuelle 2.4.1) Version läuft, wurde klar
esp02 zeigte heute einen einzelnen Prüfsummenfehler: Prüfsumme (bestanden/nicht bestanden): | 79/1

Ich habe auch Syslog für esp08 nur am Anfang aktiviert, mit Einstellungen wie unten, wenn Sie eine bestimmte Einstellung wünschen, fragen Sie bitte.

Vielleicht können Sie Ihre Konfigurationen auch im Post auflisten (kann auch der nächste Post sein, Sie müssen diesen nicht bearbeiten), der Folgendes zeigt:

• Ihre interne Gerätenummer (für Ihre eigene Referenz wie "02, 08, 18)
• Laufen bauen
• Erfolgs-/Fehlernummer (falls verfügbar)
• Art von Fehler/Problem

Aufgeschlüsselte Informationen sind (für mich) einfacher zu verstehen als beschreibender Text.
Manchmal antworte ich auch von meinem Handy aus.

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

- Eingefroren bedeutet, dass es gut funktioniert, mit Ausnahme der CO2-Messwerte

22:57 esp08 wieder eingefroren, Zähler Prüfsumme (bestanden/nicht bestanden): | 1077/2 Syslog beiseite legen, wenn gefunden.
05:05 esp18 wieder eingefroren, Zähler Prüfsumme (bestanden/nicht bestanden): | 1076/2
06:25 esp08 wieder eingefroren, keine Zähler, esp war diesmal komplett abgestürzt, bekam Syslog
12:57 esp18 wieder eingefroren. Zähler Prüfsumme (bestanden/nicht bestanden): | 116/2
20:43 esp18 wieder eingefroren, Zähler Prüfsumme (bestanden/nicht bestanden): | 316/2 hat den mhzreset-Befehl ausprobiert
Keine Änderungen, der Sensor sendet die unbekannte mhz19-Antwort 0 0 0 0 0 0 0 0
Nachricht immer und immer wieder, mehrere Versuche versucht, keine Lösung, Power-Cycling den Knoten.

Gijs,

Ich habe das letzte Syslog von esp08 analysiert, während der Stunden, in denen es läuft, habe ich 78 Vorkommen von gesehen:
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Unbekannte Antwort: ff 0 0 0 0 0 0 0 0

Automatisierte Suche mit #cat messages-crash-esp08-0625 |grep MHZ19 | grep-Antwort | grep 'ff 0 0 0 0 0 0 0 0' | WC-l

und nach dem Ändern dieser cmdline in die zweite Variante mit unbekannter Antwort zählte Linux 408 Mal diese Zeile:
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Unbekannte Antwort: 0 0 0 0 0 0 0 0 0

Die Prüfsummenfehlerzähler in Ihrer benutzerdefinierten Debug-Version sind in den letzten Tagen nicht höher als 2 geworden, soweit ich das gesehen habe.
Die erste Fehlermeldung (MHZ19: Unbekannte Antwort: ff 0 0 0 0 0 0 0 0) kam ein paar Mal sechs oder so direkt hintereinander, bevor sie heute Morgen einfror.

Es sieht so aus, als würde der Sensor selbst abstürzen, aber ich kann mir keinen Grund vorstellen, warum er das jetzt tut.
In unserer Quelle gibt es einen Befehl zum Aufrufen des Reset des MH-Z19-Sensors, aber das ist nicht im Datenblatt dokumentiert.
Daher kenne ich seinen Status nicht.
Könnten Sie versuchen, diesen Befehl auf einem Knoten aufzurufen, der so feststeckt?

Bearbeiten: Dieser Befehl ist mhzreset

Es muss nach dem Mega 20181231 2.4.1 etwas geändert werden. 4 MB-Version, die diese Ergebnisse auf der MHZ19 aufweist, soweit ich sie noch gefunden habe. der läuft seit wochen problemlos auch auf gpio 12/14.

werde es das nächste mal versuchen wenn irgendwas nicht mehr funktioniert, um 23:20 festgestellt das esp18 eingefroren war, mhzreset hat das nicht geändert, siehe obiges log.

Der Befehl mhzreset öffnet kein Befehlsfenster in der Webkonsole, meldet kein Ok oder so, nach mehreren Versuchen habe ich im Syslog gefunden:
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Sensor-Reset gesendet!
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Sensor-Reset gesendet!
so einfach sagt, es wurde gesendet, aber es scheint nicht in einem Geschmack zu sein, den das mhz19 versteht oder mag :-)

Dieser Befehl scheint etwas für die MH-Z19 A-Version zu tun.

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

Es sieht also so aus, als ob es auf der B-Version nicht verwendet werden kann.

Ich könnte davon ausgehen, dass so etwas wie dieser Befehl auch irgendwie im Startup / Init des Plugins verwendet wird?
Dies könnte erklären, warum ein Neustart / Zurücksetzen ohne Ein- und Ausschalten das Problem nicht löst.

Habe bis heute Nachmittag keine Ausfälle gesehen:
15:43 esp08 wieder eingefroren, Zähler Prüfsumme (bestanden/nicht bestanden): | 2316/2 legt das Systlog beiseite.

Und nur um sicherzugehen, dass diese Knoten auf älteren Firmware-Versionen einwandfrei liefen?

Ja bis ESP_Easy_mega-20181231_normal_ESP8266_4096 war und ist noch ok,
Sie würden wochenlang ohne Probleme laufen

Ich habe mir die letzten Änderungen in der SWserial-Bibliothek angesehen, da wir diese jetzt verwenden.
Eine der darin vorgenommenen Änderungen bestand darin, bei TX-Übertragungen für 9600 Baud keine Interrupts mehr zu verwenden.
Können Sie diesen Testaufbau ausprobieren?

NB: Ich habe auch die Core 2.5.0-Builds entfernt, da sie sich beim Bereitstellen von Webseiten seltsam verhalten.

Esp08 und Esp18 mit ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
Diese beiden senden ihre Daten auch an einen Syslog-Server, damit die Protokolldaten aufgezeichnet werden

Die anderen beiden folgen morgen, einer davon könnte ein Mhz19A sein, und das ist er auch.

Hw config ist jetzt:
Esp01 hat die MHZ19A bei gpio0/gpio2
Esp02 hat die MHZ19B bei gpio0/gpio2
Esp08 hat die MHZ19B bei gpio12/gpio14
Esp18 hat die MHZ19B bei gpio12/gpio14

Alle von ihnen auf der gleichen Testversion von esp-easy jetzt, läuft auf:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

aktualisieren

06:01 esp08 wieder eingefroren, Zähler verloren (vom Benutzer verursacht) lege das Syslog beiseite.

05:21 Esp18 eingefroren, Prüfsumme (bestanden/nicht bestanden): | 1460/0, habe Syslog beiseite gelegt
12:53 Esp08 eingefroren , Prüfsumme (bestanden/nicht bestanden): | 1351/28, habe Syslog beiseite gelegt

Der Kern-Build 2.4.1 war nicht in diesem Test-Build enthalten, also habe ich einfach einen erstellt, der nur diese Kernversion enthält. Core 2.4.1 Build mit demselben Code wie in ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
Dieser verwendet eine ältere Version der SoftwareSerial-Bibliothek.
Wenn das funktioniert, werde ich die verwendete SW-Serienbibliothek ändern.

Upgrade auf die Spezial-Version: firmware.bin für alle 4 Knoten jetzt gestartet, fertig um 12:30

Das erste, was mir auffiel, Esp08 war eingefroren, dieses Firmware-Update startete den MHZ19B neu, es kam wieder lebendig, und die Init, die ich meine: Sensor gibt mir einen vernünftigen C02-Wert, das schien auch viel schneller zu sein

Ich führe die alte SWserial-Bibliothek auch auf einem Testknoten aus und tatsächlich funktioniert sie viel besser
Beim Eastron Energiemonitoring waren zB ca. 20 - 30% der empfangenen Leitungen gestört, aber das läuft jetzt einwandfrei. (noch keine fehlerhaften Prüfsummen)

Ich habe gerade einen neuen Test-Build erstellt, in dem ich viel bezüglich des HW/SW-Serial-Wrappers geändert habe.
Es funktioniert jetzt mit dem Eastron-Plugin sowohl für SWserial als auch für HW-Serien und SWserial verwendet jetzt die alte Bibliothek, die wir bis 20180131 verwendet haben.

Das ist also eigentlich das gleiche wie die 0202-Version, aber mit der gleichen seriellen Bibliothek wie die 20181231-Version, ich werde sie direkt aktualisieren ... einen Moment

ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin installiert
auf Esp0/02/08/18 jetzt

mal sehen ..

Ja, und es hat den HWserial/SWserial-Wrapper, also sollte es einfach sein, zu HWserial zu wechseln, sobald Sie die richtigen Pins dafür verwenden.

Ich muss noch GPIO2 als zusätzliche Option für HWserial0 hinzufügen und es gibt noch einige Aufräumarbeiten im Code.

Als die ersten Stunden vergangen sind, funktionieren sie immer noch, nach dem letzten Update kann ich keine Unbekannten sehen
Antwort ff 7 x 0 oder 8 mal 0 Meldungen im Syslog von esp08 oder esp18 mehr.

Es hat einige Zeit gedauert, in die Syslog-Daten von 2 Knoten zu schauen:
Esp08 hat ab und zu immer noch eine unbekannte Antwort mit unterschiedlichen Codes,
Esp18 hat noch keine Fehler produziert

Gut zu hören.
Ich glaube, wir hatten einige Probleme, bei denen die an die Sensoren gesendeten Daten beschädigt wurden.
Dann kann der Sensor selbst abstürzen, denke ich.

Mit dem Eastron-Plugin (sendet viel mehr Daten) wurde die Anzahl der Prüfsummenfehler deutlich reduziert.
Von etwa 20 - 30 % CRC-Fehler in den Nachrichten bis nahe 0. (1 Fehler in 10'000 Nachrichten) mit SWserial.

Immer noch gut, alle vier

Wenn Sie sich die feste Liste der Version 20190215 ansehen, ist diese Version jetzt dieselbe wie die Version, die ich hier auf den 4 Co2-Messknoten ausführe?

Fast das gleiche.
Zumindest der Code für die serielle Schnittstelle und Ihr Plugin ist identisch.

Dann lasse ich es so wie es ist und teste weiter mit dem "Spezial"

Mir war nicht klar, was in der Veröffentlichung enthalten war und was nicht, einige der Nummern stimmten überein.

Ja, die große PR, die ich gestern zusammengeführt habe, war die Quelle aller Test-Builds, die ich in den letzten Wochen erstellt habe.

Esp08 eingefroren um 14:17, Zähler Prüfsumme (bestanden/nicht bestanden): | 3292/70, Syslog zur weiteren Analyse beiseite gelegt

Und hat ein einfacher Neustart (oder Speichern der Einstellungen) des Knotens den Sensor neu gestartet (nicht ausgeschaltet)?

Werde das das nächste Mal versuchen, habe es einfach aus- und wieder eingeschaltet, nachdem ich die Zähler überprüft habe.

Esp08 wieder eingefroren, Zähler Prüfsumme (bestanden/nicht bestanden): | 2660/55

speichern der co2-geräteparameter hat das einfrieren behoben !

Esp08 18:18 wieder eingefroren, Zähler Prüfsumme (bestanden/nicht bestanden): | 2660/55

speichern der co2-geräteparameter hat das einfrieren behoben !

OK, also ist es möglich, einen Reset durchzuführen.
Ich werde eine Überprüfung auf N unbekannte Antworten hinzufügen und dann erneut eine Initialisierung durchführen.

Das könnte dieses Problem vollständig lösen.

Im Moment scheint das ganze Serienproblem, das wir bei allen hatten, jetzt beim Modell A und bei zwei der drei Sensoren des Mhz19B-Modells verschwunden zu sein.
Esp08, das ein Modell B ist, ist der einzige, den ich gesehen habe, mit einer Variable "unbekannte Antwort (jedes Mal ein sich ändernder) Hex-Wert " noch in den Logdateien, wenn dieser Sensor bei schlechtem Verhalten aus dem Plugin zurückgesetzt werden könnte, es könnte die Lösung sein.

Aktualisieren Sie jetzt alle auf Mega 201902026 4 MB.

Als erstes ist mir aufgefallen, dass der Co2-Sensor Typ mhz19B fast sofort nach dem Flashen eines neuen Bildes korrekte Werte liefert, viel viel schneller als zuvor.

Das klingt wirklich vielversprechend! Ich habe diesen Thread beobachtet und auf einen Moment gewartet, in dem ich endlich ein Upgrade durchführen könnte. :grin: Ich habe einen Knoten, an dem sowohl ein MH-Z19 als auch ein PMS7003 angeschlossen sind. MH-Z19 hat >90% der Zeit funktioniert, aber gelegentlich musste ich dafür das ESP zurücksetzen.

Der PMS7003 scheint jedoch viel mehr zu versagen. Meistens hilft sogar ein Zurücksetzen nicht, aber das Trennen der Stromversorgung für ein paar Sekunden könnte das Problem beheben. Ich habe vermutet, dass sein Anschluss der Übeltäter sein könnte, hatte mich aber noch nicht mit dem Debuggen beschäftigt. Dieser Thread hat mich neugierig gemacht, ob es immer noch Firmware-bezogen sein könnte ... Ich werde es versuchen, wenn ich sicher genug bin, dass es keine Probleme mit dem MH-Z19 verursachen wird, da seine Daten wichtiger sind.

Und ja, ich habe bemerkt, dass #2349 nur den MH-Z19-Code berührt hat, aber der Build, den ich ausführe, ist "20100 - Mega (Kern 2_4_0)", von dem ich annehme, dass er ziemlich alt ist.

Ich möchte sagen, dass es selten ist, eine solche Beharrlichkeit von beiden Seiten eines Problems zu sehen. Ich schätze, viele hätten nach ein paar Tagen aufgegeben. Hut ab vor diesem Zuschauer @TD-er und @pwassink!

Möglicherweise möchten Sie mit dem Upgrade noch einen Tag warten.
Ich arbeite jetzt an einigen Patches für die Netzwerkkonnektivität.

Danke für die Information! Ich hatte sowieso vor, @pwassink- Berichte für einen Moment zu warten (ich bin faul).

Seien Sie sich bewusst, dass sich seit Ihrem aktuellen Build viel geändert hat und leider nicht alles positiv.
Eines der Probleme, das wir immer noch zu lösen versuchen, sind die Neustarts des Hardware-Watchdogs. Sie sollten also eine Sicherungskopie Ihrer aktuellen Einstellungen erstellen und die aktuelle Version, die Sie verwenden, aufschreiben. Nur um sicher zu gehen.
Ich hoffe, diese Neustarts durch die heutigen Korrekturen ein wenig verbessern zu können, aber da diese Neustarts mehrere verschiedene Ursachen haben, glaube ich nicht, dass die heutigen Korrekturen sie alle behandeln werden.

Notiz genommen. Ich kann mir nur vorstellen, wie schwierig es ist, Regression in einem System wie ESPEasy zu vermeiden. Ich werde alle Regressionen melden, nachdem ich das Upgrade durchgeführt habe (natürlich als separate Probleme).

Ich plane, zwei ESPs zu aktualisieren, die ich hier habe. Nur anhand dieser kann ich feststellen, ob es eine Regression bei der Handhabung von MH-Z19-, PMSx003-, BMx280-, TSL2561-, DHT22-Sensoren oder OLED-SSD1306-Displays gibt. TSL2561 auf der anderen ESP neigt dazu, auch keine zufälligen Daten mehr zurückzugeben (allerdings ziemlich selten). Es läuft Build "20102 - Mega".

Das ist nicht der Build, sondern das interne Dateiformat (verwirrend, ich weiß). Möglicherweise finden Sie den Build-Namen/das Build-Datum auf der Sysinfo-Seite.

Es steht zumindest im "Build"-Feld. Der Name der Binärdatei lautet "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames". Ich habe es wahrscheinlich direkt von PlatformIO geflasht. Ich könnte einige Schwierigkeiten haben, die gleiche Version zu flashen wie vor fast einem Jahr. Ich habe mir nicht wirklich irgendwelche Notizen gemacht, ganz zu schweigen von einem Tag. :joy: Nun, ich denke, ich kann einfach ein Backup der Firmware machen, wenn ich mich nicht abenteuerlustig genug fühle.

Kein Build-Zeitstempel auf der Sysinfo-Seite?

Es gibt einen Zeitstempel, aber er wird nicht viel helfen, da ich mich nicht erinnere, ob ich vorher den neuesten Code abgerufen hatte. Aber natürlich gibt es etwas Baseballstadion.

Dies ist jedoch nicht das ESP, das den MH-Z19 und den PMS7003 hostet.

Aber ich denke, das geht am Thema vorbei. Tut mir leid, dass ich den Thread vorübergehend gekapert habe, und danke, dass du trotzdem auf meine Kommentare geantwortet hast!

in welcher Version wurde das behoben?

nach ein paar Stunden bekomme ich MHZ19: Unbekannte Antwort: 0 0 0 0 0 0 0 0 0
Ein Neustart bringt keine Abhilfe, muss den Stecker ziehen und wieder einstecken

Ich verwende ein Wemos 1D Mini Pro, enthält diese Version das Update?

Aufbau:⋄ | 20104 - Mega
-- | --
Systembibliotheken:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.1.2 PUYA-Unterstützung
Git-Build:⋄ | Mega-20191003
Plugins:⋄ | 46 [Normal]
Md5 erstellen: | 3180a4d3e118166b3414444513a6169
Md5 prüfen: | bestanden.
Bauzeit:⋄ | 3. Oktober 2019 02:15:29
Binärer Dateiname:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

Danke

Yep und frühere Versionen auch.
Ich würde vorschlagen, es mit dem 20190928-Build zu versuchen, da der Oktober-Build einige andere Probleme hatte (die ich in der letzten Woche oder so behebe).

Sie können sich auch die Anzahl der Lesefehler ansehen, die auf der Plugin-Seite angezeigt werden, nachdem sie einige Stunden gelaufen ist.

Zum Beispiel eine meiner eigenen Einheiten (3 Tage Betriebszeit)

Hinweis: Der Filter (im Screenshot auf „Use Unstable“ eingestellt) hat beim MH-Z19B-Sensor keine Bedeutung, er gilt nur für die -A-Version.

Und noch einer:

Wie Sie sehen können, ist die Anzahl der fehlgeschlagenen Lesevorgänge minimal.
Wenn Sie dort einige Fehler haben, haben Sie möglicherweise ein anderes Problem zur Hand.

Diese 11 Resets, bei denen ich versuche, es wieder hochzufahren, ohne es wieder ein- und auszustecken, ich erinnere mich jedoch nicht, dass ich irgendwelche Fehler gesehen habe, aber ich kann es noch einmal versuchen, sollte ich Software Serial verwenden?

Hardware Serial ist besser, aber dann müssen Sie auch den seriellen Port in Tools->Advanced->Serial Port deaktivieren. (wie in deinem Screenshot angegeben :))

Ich bin mir nicht sicher, ob ein vorhandener USB-zu-Seriell-Adapter auf der Platine die Kommunikation beeinflussen kann.
Im Zweifelsfall können Sie auf Software Serial wechseln.

Build: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
Berichterstattung an FHEM.
Ich hatte ein ähnliches Problem: Der MH-Z190B-Sensor friert alle paar Stunden ein und fällt immer wieder auf 400, wenn ich Hardware seriell verwende.
Nach dem Umschalten auf Software Serial scheint es normal zu funktionieren und friert nicht mehr ein.
2 Screenshots anbei.

Der mit I2C verbundene BME280 funktioniert einwandfrei und meldet die ganze Zeit

Hm das ist seltsam.
An welchen seriellen HW-Port war es angeschlossen?
Was ist sonst noch mit dem Board verbunden? (z. B. USB zu seriellem Chip)
Ist "Use Serial" auf der Seite Tools->Advanced deaktiviert?

Es ist mit GPIO-13 (D7) <- TX und GPIO-15 (D8) -> RX (zuerst in HW, jetzt in SW) verbunden, da ich TXD0 und RXD0 verwenden wollte, um die Nachrichten über den USB-Port (CH340 ) des Wemos D1 mini.
Bedeutet "Seriell verwenden", dass "Serielle Einstellungen - Seriellen Anschluss aktivieren:" aktiviert ist? Ich habe dies aktiviert gelassen, um die Nachrichten über USB lesen zu können.

Die HW-Seriennummer auf einem ESP8266 verwendet Serial0.
Wenn Sie auch Protokolle an denselben seriellen Port senden, kann der Sensor abstürzen, da er die "Befehle" nicht versteht, die er erhält, wenn die Protokolle über diesen Port gesendet werden.

Wenn Sie etwas an den seriellen Port der HW anschließen, sollten Sie keine anderen Daten mehr senden. Daher sollten Sie "Use Serial" auf der Seite Tools->Advanced deaktivieren.

Gestern habe ich einen zweiten Sensor MH-Z19C bekommen. Dieser scheint mit HW-Serial auf Serial2 gut zu funktionieren. Da die Sensoren alle an den Pins D7 (GPIO 13) und D8 (GPIO 13) (RXD2 und TXD2) angeschlossen waren, sollte es meiner Meinung nach keinen Konflikt mit Serial0 (Pins RXD0 (GPIO3) und TXD0 (GPIO1)) geben Verständnis der Pinbelegung. Ich denke, der erste Sensor (MH-Z19B von einem anderen Anbieter) war nur eine Fälschung, die überhaupt nicht richtig funktionierte, ...
Seien Sie also vorsichtig, wenn Sie diese Sensoren kaufen. Der zweite, den ich gestern bekommen habe, war in einer viel besseren Verpackung mit dem Winsen-Logo und einem Prüfzertifikat beigelegt. Der Lieferant scheint seriöser zu sein als der, der mir das erste verkauft hat.