Cela semble être lié au changement de série que j'ai fait récemment.

Quelles broches gpio utilisez-vous?

C'est peut-être, voyons, je suppose que vous avez trouvé un point Gijs :-)

esp01 = Gpio0 Gpio2 (pas encore de problèmes vus)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Pierre

J'ai deux nœuds ici, je peux aussi tester plus tard cet après-midi

D'accord,
La faute n'est pas immédiate, ils arrêtent d'envoyer après un certain temps et persistent assez dans le sens où, le redémarrage ou la rétrogradation de sw ne suffit pas pour qu'ils envoient à nouveau des données. Ils ont besoin d'un cycle d'alimentation et d'un certain temps entre éteindre et allumer.

Combien de temps dure "après un certain temps" ?
Je viens de configurer un nœud utilisant l'un de ces capteurs et un BMP280 est également connecté.
Il utilise GPIO-14 & -12 pour le capteur de CO2.

quelques heures, hier tout fonctionnait, ce matin j'en avais 3 sur 4 avec le même statut.

Et ils ont tous démarré à peu près au même moment, avant qu'ils ne s'arrêtent tous de travailler ?

oui, tous ont été redémarrés / mis à jour en une heure, je pense, les mettaient à jour hier soir. et pendant la nuit ils ont arrêté de travailler

J'étais sur le point de mettre à jour mes nœuds, mais heureusement, j'ai remarqué cela. @TD-er quelle serait la dernière version avant les modifications apportées à Serial, vous pensez que cela pourrait être le coupable ? Ou serait-il plus utile que je flashe la dernière version pour voir si je rencontre le même problème ?

Si les mises à jour manquantes ne sont pas un gros problème, je suggérerais la dernière version.
Pour conserver la version avant le wrapper de port série, vous pouvez utiliser 20181231. (Je pense avoir validé les changements cette année)

J'ai rétrogradé les 3 esp "problèmes" à 20181231 hier, je peux confirmer qu'ils envoient toujours des données sans modification matérielle, maintenant pendant 24h, donc ces trois esp utilisent toujours gpio12 et gpio14 dans mon cas

Une chance de le recréer Gijs ?

Non, mon nœud envoie toujours des valeurs et il exécute la construction à partir du 16 janvier. (noyau 2.5.0)

J'ai utilisé ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin sur ces nœuds, qui a le noyau 2.4.1 je crois ?

@pwassink C'est exact.
Vous pouvez également voir la version principale dans la page sysinfo.

J'ai installé cette version ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin sur l'esp02 ici, voyons si cela se reproduit

Hmm,
Peut-être que le jour de la semaine ou la position de la lune a une certaine influence,
Je n'ai pas vu le défaut se reproduire ici au cours des derniers jours.

Il semble bien fonctionner ici aussi.
C'était à peu près la pleine lune quand vous l'avez signalé, donc je suppose que ça aurait dû être ça ;)

Mettre à jour,

J'ai laissé esp02 fonctionner avec la version ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin qui fonctionne toujours comme il se doit.

Hier, j'ai mis à jour le reste de mes nœuds vers ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

Et l'esp-18 est redevenu bozo à 06h55 heure locale, tout fonctionne comme il se doit, à l'exception du capteur MHZ19 Co2, dans l'onglet des appareils, il affiche la "dernière bonne valeur connue" à partir d'environ 07h00 et encore avec les mêmes entrées dans le Logfile :
MHZ19 : Erreur, délai d'attente lors de la tentative de lecture
MHZ19 : réponse inconnue : 0 0 0 0 0 0 0 0 0

Esp-18 utilise Gpio 14/12
c'est un Nodemcu avec Ch340 version 2 sur 3 d'ali
Le redémarrage à distance via la console Web n'a pas résolu le problème
encore une fois, il affiche les entrées mentionnées ci-dessus plusieurs fois
Après le cycle d'alimentation
78640 : MHZ19 : erreur, délai d'attente lors de la tentative de lecture
78641 : MHZ19 : Erreur de lecture : somme de contrôle = 202 / 0 octet lu => 255/168/12/161/226/255/0/0/0/
78643 : MHZ19 : décalé de 1 octet pour tenter de corriger l'alignement de la mémoire tampon
Après un peu plus de temps :
255652 : MHZ19 : valeur PPM : 1584 valeurs Temp/S/U : 25/0/0,00
255656 : ÉVÉNEMENT : Rik-CO2#PPM=1584,00
255656 : ÉVÉNEMENT : Rik-CO2#PPM=1584,00 Temps de traitement : 1 millisecondes
255659 : ÉVÉNEMENT : Rik-CO2#Température=25,00
255659 : ÉVÉNEMENT : Rik-CO2#Température=25,00 Temps de traitement : 1 millisecondes
255662 : ÉVÉNEMENT : Rik-CO2#U=0,00
255662 : ÉVÉNEMENT : Rik-CO2#U=0,00 Temps de traitement : 1 millisecondes

Il semble fonctionner à nouveau maintenant, mais il a fallu un cycle d'alimentation d'environ 2 minutes sans alimentation

Doit-il faire quelque chose à ce moment-là ? Peut-être quelque chose qui pourrait entraîner un accroc du wifi sur l'ESP ?

Rien du tout,

Il n'y a pas de réinitialisations planifiées, de redémarrages, de sauvegardes, de réinitialisations wfi, de nettoyages DHCP ou de toute autre raison externe à ce moment-là

Et le wifi continue de fonctionner correctement, c'est juste la lecture du mhz19 qui s'arrête, tous les autres capteurs (basés sur i2c) sur le même esp fonctionnent toujours

Ce matin à 03h00, cela s'est produit à nouveau avec Esp-18 exécutant la version 0121 Mega, mêmes erreurs dans esp-logfile qu'avant, les autres capteurs fonctionnent bien

Et à 19h05, l'esp02 fonctionnant avec l'ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin s'est également écrasé, même situation que ci-dessus, plus aucune donnée et mêmes entrées dans la journalisation.

Encore 2 hickups aujourd'hui, esp02 et esp18 ont tous deux mal tourné, mêmes défauts dans le journal
Logiciel 2 versions impliquées, 0116 et 0121 à la fois 2.4.1 core et version 4 Mo
le matériel d'esp02 est un nodemcu-d1-mini / esp18 est un nodemcu-v2 les deux utilisent gpio12/gpio14

Pouvez-vous essayer cette version sur l'un de vos nœuds ?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Il fonctionne sur l'un de mes nœuds avec un MH-Z19 et a maintenant une disponibilité de 54 jours 23 heures 21 minutes
C'est depuis une coupure de courant...
Celui-ci fonctionne bien avec des mises à jour régulières de la valeur de CO2.

Je vais,

mais ai-je déjà mentionné auparavant que jusqu'à la version mega 20181231 core 2.4.1 normal 4Mb aucun des problèmes de stabilité signalés n'a été vu, alors pourquoi cette version spécifique ?

Je vais télécharger cette version spécifique et l'installer sur les nœuds de mesure du co2 eesp02 et esp18, mais les problèmes sont apparus dans la gamme méga-2019 * pas plus tôt à mon humble avis Gijs ..

OK, alors ça ne sert à rien en effet.

Cette version spécifique fonctionne sur une version que j'ai qui semble être (malheureusement inhabituelle) stable.
Et vous avez raison, s'il fonctionnait bien jusqu'en 20181231, alors ce n'est pas vraiment la peine d'essayer les plus anciens.

Néanmoins,
Esp02 et esp18 fonctionnent sur ESP_Easy_mega-20181109_normal_ESP8266_4096.bin maintenant
Esp01 et Esp08 s'exécutent sur ESP-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

Et nous verrons

Remarque, mon œil vient de remarquer que la version 1109 a le numéro de build 20102, donc c'est loin et différent ?

Gijs,

J'ai peut-être trouvé un autre indice sur ce problème.

il y a quelques minutes, mon Esp08 A nodemcu ch340V2 4Mb exécutant ESP-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin a également cessé d'envoyer co2data.

Extrait de journal
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 : Erreur de lecture : somme de contrôle = 120 / 248 octets lus => 255/134/5/183/71/128/15/112/248/
370515677 : MHZ19 : décalé de 1 octet pour tenter de corriger l'alignement de la mémoire tampon
370517702 : ÉVÉNEMENT : Horloge#Heure=Mer,12:19
370517755 : ÉVÉNEMENT : Horloge#Heure=Mer, 12h19 Temps de traitement : 53 millisecondes
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

C'est la première fois que je vois ce défaut, peut-être..

Une erreur de somme de contrôle doit être gérée avec plus de grâce.
Peut-être devrions-nous ajouter un seuil sur le moment où commencer à changer pour rechercher un nouveau bon départ.
Ou un meilleur algorithme pour se synchroniser à nouveau.
Autant que je sache, il n'y a pas eu de changement dans le code pour cela depuis plus d'un an. Il n'y a eu qu'un changement dans la façon dont la connexion du port série est créée, donc je ne sais vraiment pas pourquoi cela conduit à ces problèmes.

J'ai l'idée que le capteur mhz19 lui-même entre dans un état "bloqué" après quelques heures de mauvaise communication ou parce qu'il ne peut pas obtenir de données. ?
Motivation : un redémarrage ou même une mise à jour complète ne résout pas ce statut, le mhz19 doit être impuissant pendant une minute environ pour reprendre vie, j'ai trouvé ce comportement lorsqu'il est bloqué dans le statut qui ressemble à :
MHZ19 : Erreur, délai d'attente lors de la tentative de lecture
MHZ19 : réponse inconnue : 0 0 0 0 0 0 0 0 0

La faute esp08 était ce matin était toujours résoluble avec une option de redémarrage à distance à partir de la console Web, donc ce n'était pas la même chose que le blocage complet après plusieurs heures que j'ai trouvé et signalé plusieurs fois.

Mais j'ai trouvé ça après :
à environ 1800 heure locale, il est entré dans l'état bloqué, réinitialisé, redémarré via le cycle d'alimentation de la console, rien n'a fonctionné cette fois, l'appareil avait besoin d'un nouveau flash avec la version méga 20181231 4 Mo, puis il a repris vie. Esp08 utilise la combinaison Gpio12/14 et est également un modèle nodemcu v2 ch340

Cela semble assez étrange, car le plugin envoie une commande pour collecter de nouvelles données de capteur au MH-Z19
Donc, je ne comprends pas pourquoi même un redémarrage en douceur ne fonctionne pas.
J'ajouterai également quelques statistiques pour voir à quelle fréquence une erreur de somme de contrôle se produit (fin de réception)
Si cela se produit souvent, cela peut également se produire lors de l'envoi de données au capteur et peut-être que le capteur est ensuite mis dans un mode de commande inconnu.
Peut-être que la configuration de la résistance de rappel a changé lorsque j'ai changé la façon dont les broches série sont configurées ???

Cela pourrait,

J'examinerai cela un peu plus loin demain ou pendant le week-end à venir, peut-être que je pourrai trouver quelque chose, ce capteur n'est-il pas si largement utilisé que personne ne souffre d'un comportement identique ?

Ou non utilisé par les personnes exécutant les dernières versions

J'ai 2 MH-Z19b, tous deux fonctionnant sur la version de test 20190116 sans problèmes

Ok, juste curieux de savoir quelle version de base de la version de test et quels Gpio utilisez-vous ?

Je vois que 1 exécute ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin, l'autre ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. Sur les deux capteurs connectés aux GPIO 13 & 12

C'est donc un autre noyau et un autre GPIO que vous utilisez en 13/12 au lieu de GPIO 14/12 que j'utilise ici

Aujourd'hui, j'ai mis à jour 4 sur 4 vers la version ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin

Voyons voir

Maintenant que j'y pense, il peut y avoir un autre changement dans la bibliothèque SWserial utilisée depuis le début de cette année.
Nous avions notre propre version de la bibliothèque SWserial, que j'ai corrigée pour utiliser moins de mémoire iRAM.
Mais maintenant, nous utilisons la version incluse dans la bibliothèque principale et pour le noyau 2.5.0, il peut s'agir d'une version plus récente qu'auparavant.
Il peut également y avoir des changements dans l'utilisation des interruptions sur les connexions à faible vitesse. (9600 bauds et moins)
Je dois me pencher là-dessus aussi.

Cela n'explique toujours pas pourquoi le capteur peut apparemment être si foiré qu'il a besoin d'une mise hors tension pour fonctionner à nouveau normalement.

Dans les 3 heures suivant la mise à jour vers ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin, mon esp18 a été à nouveau verrouillé, le redémarrage de la console Web n'a pas fonctionné, la mise hors tension était à nouveau nécessaire.
l'autre fonctionne toujours, ajoutera ici s'il gèle également le MHZ19

Oui, l'autre esp18 a cessé d'envoyer des données CO2 raisonnables à 19h05 ce soir, donc le défaut persiste dans le méga 202 core 2.4.1 d'hier au moins.
Celui-ci est de retour et rétrogradé à la version 20181231 maintenant aussi.

Vers minuit, le troisième esp, esp02 s'est figé avec les lectures de Co2, également rétrogradées à 20181231 maintenant

Le seul encore en cours d'exécution sur ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin est celui qui utilise Gpio-0/Gpio-2, les trois autres qui ont gelé utilisent Gpio14/gpio12.
Je ne pense plus que ce soit une coïncidence,

Je vais changer le câblage d'esp02 vers Gpio-0/Gpio-2 et le mettre à niveau vers la version 0202 core 2.4.1 à nouveau et nous verrons peut-être si cela reste en vie après ce changement de gpio.
Terminé

J'ai juste ajouté un commit pour faire quelques améliorations sur la lecture.
Voir https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

Pouvez-vous en créer une version de test ou voulez-vous que j'en crée une ?

Si vous pouviez me fournir un bac, je serai heureux de le mettre sur les deux toujours sur gpio12/14 en cours d'exécution esp's
et puis c'est certain que le fichier est le même, pas d'influences locales etc..

OK, ça a pris du temps, mais voici la version de test

J'ai compris,

Esp08 et esp18 fonctionnent sur cette version de test avec le noyau 2.4.1 maintenant, ils utilisent tous les deux gpio12/14

Voyons voir !

Vous devriez également voir un indicateur indiquant le nombre de lignes traitées et le nombre d'échecs CRC

Oui, je les ai aussi dans la console maintenant!

laissera ces 2 et verra à un certain intervalle si ces compteurs augmentent.
Vous tenir au courant ..

Les deux capteurs utilisés aux nœuds de test sont des versions B, de sorte que la détection a également fonctionné

Somme de contrôle (réussite/échec) : | 11/0
-- 08 --
Détecté : | MH-Z19B

Somme de contrôle (réussite/échec) : | 8/0
-- 18 --
Détecté : | MH-Z19B

Avez-vous également un mélange de MH-Z19 A/B ou seulement les nouvelles versions B ?
Cela ne devrait pas avoir d'importance, juste de la curiosité.

Avez-vous également un mélange de MH-Z19 A/B ou seulement les nouvelles versions B ?
Cela ne devrait pas avoir d'importance, juste de la curiosité.

Versions B, venez d'ajouter cette information, la détection a également fonctionné :-)

petite mise à jour, tous fonctionnent toujours bien, ceux avec votre version spéciale esp8 et 18 affichent des compteurs croissants mais toujours pas de défauts ou d'erreurs de somme de contrôle, les valeurs actuelles sont :

Esp08 : Somme de contrôle (réussite/échec) : | 1795/0
Esp18 : Somme de contrôle (réussite/échec) : | 724/0

et l'autre qui a échoué de manière assez cohérente esp02 est également toujours en cours d'exécution avec les Gpio modifiés
et donc di-mini a maintenant le mhz19 sur Gpio-0/Gpio-2 et mega 20190202 version core 2.4.1

Bummer a accidentellement supprimé le message ici, essayez de recréer à partir de ma mémoire :

Hier soir trois de mes esp's 02, 08 et 18 sont passés au rouge sur Domoticz, aucune donnée de capteur de Co2.
deux d'entre eux ont la version spéciale core 2.4.1 et gpio 12/14. Un redémarrage de la console Web ne l'a pas résolu et n'a produit que : MHZ19 : réponse inconnue : 0 0 0 0 0 0 0 0 0 mais les mesures de co2 esp18 ont repris vie après environ une heure, à 0 h 56, elles ont recommencé à envoyer les valeurs appropriées.

Esp08 a également reçu un redémarrage, et esp02 également (celui-ci a maintenant gpio0/2 identique à esp01) les deux n'ont pas récupéré, et ce matin, les deux ont été mis hors tension pendant 2 minutes, après quoi les deux sont revenus à la vie.

J'ai maintenant changé la version du logiciel sur esp02 en ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 afin que nous puissions également tester cette version principale, le changement gpio n'a pas fait de différence en exécutant l'ancienne version (actuelle 2.4.1) est devenu clair
esp02 a montré un seul échec de somme de contrôle aujourd'hui : Somme de contrôle (réussite/échec) : | 79/1

J'ai également activé syslog pour esp08 uniquement au début, avec les paramètres ci-dessous, si vous souhaitez un paramètre spécifique, veuillez demander.

Peut-être que vous pouvez également détailler vos configurations dans le message (peut également être le prochain message, pas besoin de modifier celui-ci) en indiquant ce qui suit :

• Votre numéro d'unité interne (pour votre propre référence comme "02, 08, 18)
• Construire en cours d'exécution
• nombre de succès/échec (si disponible)
• type de panne/problème

Les informations détaillées sont (pour moi) plus faciles à suivre par rapport au texte descriptif.
Je réponds aussi parfois depuis mon téléphone.

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

- congelé signifie qu'il fonctionne bien sauf pour les lectures de co2

22:57 esp08 gelé à nouveau, compteurs Checksum (pass/fail): | 1077/2 met syslog de côté lorsqu'il est trouvé.
05:05 esp18 gelé à nouveau, compteurs Checksum (pass/fail): | 1076/2
06:25 esp08 gelé à nouveau, pas de compteurs, esp a complètement planté cette fois, a obtenu syslog
12:57 esp18 gelé à nouveau. compteurs Somme de contrôle (réussite/échec) : | 116/2
20:43 esp18 gelé à nouveau, compteurs Checksum (pass/fail): | 316/2 a essayé la commande mhzreset
Aucun changement quoi que ce soit, le capteur envoie la réponse inconnue mhz19 0 0 0 0 0 0 0 0
message maintes et maintes fois, essayé plusieurs tentatives sans solution, redémarré le nœud.

Gijs,

J'ai fait quelques analyses sur le dernier syslog d'esp08, pendant les heures d'exécution, j'ai vu 78 occurrences de :
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy : MHZ19 : Réponse inconnue : ff 0 0 0 0 0 0 0 0

Recherche automatisée à l'aide de #cat messages-crash-esp08-0625 |grep MHZ19 | grep réponse | grep 'ff 0 0 0 0 0 0 0 0' | wc -l

et après avoir changé cette cmdline en la deuxième variante à réponse inconnue, Linux a compté 408 fois cette ligne :
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy : MHZ19 : Réponse inconnue : 0 0 0 0 0 0 0 0 0

Les compteurs d'erreurs de somme de contrôle dans votre version de débogage personnalisée n'ont pas dépassé 2 d'après ce que j'ai vu au cours des deux derniers jours.
le premier message d'erreur (MHZ19 : réponse inconnue : ff 0 0 0 0 0 0 0 0) est arrivé plusieurs fois six fois l'un après l'autre avant de se figer ce matin.

On dirait que le capteur lui-même plante, mais je ne vois pas pourquoi il le fait maintenant.
Dans notre source, il existe une commande pour appeler la réinitialisation du capteur MH-Z19, mais cela n'est pas documenté dans la fiche technique.
Je ne connais donc pas son statut.
Pourriez-vous essayer d'appeler cette commande sur un nœud qui est bloqué comme ça ?

Edit : cette commande est mhzreset

Il doit y avoir des changements apportés après le méga 20181231 2.4.1. Version 4Mb qui a ces résultats sur le MHZ19 pour autant que j'aie encore trouvé. celui là tourne depuis des semaines sans problème même sur gpio 12/14.

je l'essaierai la prochaine fois que quelque chose cessera de fonctionner, à 23h20, j'ai trouvé que esp18 était gelé, mhzreset n'a pas changé cela, voir le journal ci-dessus.

la commande mhzreset n'ouvre pas de fenêtre de commande dans la console Web, ne rapporte pas OK ou alors, après plusieurs tentatives, j'ai trouvé dans le syslog :
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy : MHZ19 : Réinitialisation du capteur envoyé !
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy : MHZ19 : Réinitialisation du capteur envoyé !
si facile dit qu'il a été envoyé, mais il ne semble pas dans une saveur que mhz19 comprend ou aime :-)

Cette commande semble faire quelque chose pour la version 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

Il semble donc qu'il ne puisse pas être utilisé sur la version B.

Je pourrais supposer que quelque chose comme cette commande est également utilisée d'une manière ou d'une autre dans le démarrage/init du plugin ?
ce qui pourrait expliquer pourquoi un redémarrage / réinitialisation sans cycle d'alimentation ne résout pas le problème.

Je n'ai pas vu d'échecs jusqu'à cet après-midi :
15:43 esp08 gelé à nouveau, compteurs Checksum (pass/fail): | 2316/2 mettre le systlog de côté.

Et juste pour être sûr, ces nœuds fonctionnaient bien sur les anciennes versions de firmware ?

Oui jusqu'à ce que l'ESP_Easy_mega-20181231_normal_ESP8266_4096 soit et est toujours ok,
Ils fonctionneraient pendant des semaines sans problèmes

J'ai examiné les changements récents dans la bibliothèque SWserial, puisque c'est celle que nous utilisons maintenant.
L'une des modifications apportées était de ne plus utiliser d'interruptions sur les transferts TX pour 9600 bauds.
Pouvez-vous essayer cette version de test ?

NB J'ai également supprimé les versions de base 2.5.0, car elles agissent étrangement lors de la diffusion de pages Web.

Esp08 et Esp18 exécutant ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
ces deux envoient également leurs données à un serveur syslog afin que les données du journal soient enregistrées

Les deux autres suivront demain, l'un d'eux pourrait être un Mhz19A, Et c'est le cas.

La configuration matérielle est maintenant :
Esp01 a le MHZ19A à gpio0/gpio2
Esp02 a le MHZ19B à gpio0/gpio2
Esp08 a le MHZ19B à gpio12/gpio14
Esp18 a le MHZ19B à gpio12/gpio14

Tous sur la même version de test d'esp-easy maintenant, fonctionnant sur :
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

mettre à jour

06:01 esp08 gelé à nouveau, compteurs perdus (causé par l'utilisateur) mettre le syslog de côté.

05:21 Esp18 gelé, Somme de contrôle (réussite/échec) : | 1460/0, ont mis syslog de côté
12:53 Esp08 gelé , Somme de contrôle (réussite/échec) : | 1351/28, ont mis syslog de côté

La version de base 2.4.1 n'était pas incluse dans cette version de test, donc je viens d'en créer une contenant uniquement cette version de base. version core 2.4.1 du même code que dans ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
Celui-ci utilise une ancienne version de la bibliothèque SoftwareSerial.
Si cela fonctionne, je changerai la bibliothèque série SW utilisée.

Démarrage de la mise à niveau vers la version spéciale : firmware.bin pour les 4 nœuds maintenant, terminé à 12h30

La première chose que j'ai remarquée, Esp08 a été gelé, cette mise à jour du firmware a redémarré le MHZ19B, il est revenu vivant, et l'init je veux dire: le capteur me donne une valeur C02 raisonnable, cela semblait aussi beaucoup plus rapide

J'exécute également l'ancienne bibliothèque SWserial sur un nœud de test et, en effet, cela fonctionne beaucoup mieux
Par exemple, la surveillance de l'énergie d'Eastron avait environ 20 à 30 % des lignes reçues corrompues, mais cela fonctionne maintenant parfaitement. (pas encore de sommes de contrôle échouées)

Je viens de faire une nouvelle version de test dans laquelle j'ai beaucoup changé concernant le wrapper série HW/SW.
Il fonctionne maintenant avec le plugin Eastron pour SWserial et HW serial et SWserial utilise maintenant l'ancienne bibliothèque que nous avons utilisée jusqu'en 20180131.

C'est donc en fait la même chose que la version 0202 mais avec la même bibliothèque de série que la version 20181231, je vais les mettre à jour directement .. juste un instant

ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin installé
sur Esp0/02/08/18 maintenant

Voyons voir ..

Oui et il a le wrapper HWserial/SWserial, il devrait donc être facile de passer à HWserial dès que vous utilisez les bonnes broches pour ceux-ci.

Je dois encore ajouter GPIO2 comme option supplémentaire pour HWserial0 et il reste encore du nettoyage à faire dans le code.

Comme les premières heures se sont écoulées, ils fonctionnent toujours, après la dernière mise à jour, je ne vois aucun inconnu
réponse ff 7 x 0 ou 8 fois 0 messages dans le syslog depuis esp08 ou esp18.

Il a fallu du temps pour examiner les données syslog de 2 nœuds :
Esp08 a toujours une réponse inconnue avec des codes variables de temps en temps,
Esp18 n'a pas encore produit de défauts

Bon à entendre.
Je pense que nous avons eu quelques problèmes où les données envoyées aux capteurs ont été corrompues.
Ensuite, le capteur lui-même peut planter, je suppose.

Avec le plugin Eastron (envoyant beaucoup plus de données), le nombre d'erreurs de somme de contrôle a été considérablement réduit.
D'environ 20 à 30 % d'erreurs CRC dans les messages à près de 0. (1 erreur sur 10 000 messages) en utilisant SWserial.

Ça marche toujours bien, tous les quatre

En regardant la liste fixe de la version 20190215, cette version est-elle maintenant la même que la version que j'exécute sur les 4 nœuds de mesure de Co2 ici ?

Presque la même.
Au moins le code pour le port série et votre plugin est le même.

Ensuite, je le laisse tel quel et continue les tests avec le "spécial"

Ce n'était pas clair pour moi ce qui était inclus dans la version et ce qui ne l'était pas, certains chiffres correspondaient.

Oui, le grand PR que j'ai fusionné hier était la source de toutes les versions de test que j'ai faites la semaine dernière.

Esp08 figé à 14h17, compteurs Checksum (pass/fail) : | 3292/70, syslog mis de côté pour une analyse plus approfondie

Et un simple redémarrage (ou sauvegarde des paramètres) du nœud a-t-il redémarré le capteur (et non éteint) ?

J'essaierai la prochaine fois, mettez-le sous tension après avoir vérifié les compteurs.

Esp08 gelé à nouveau, compteurs Checksum (pass/fail): | 2660/55

la sauvegarde des paramètres du co2-device a résolu le blocage !

Esp08 18:18 gelé à nouveau, compteurs Checksum (pass/fail): | 2660/55

la sauvegarde des paramètres du co2-device a résolu le blocage !

OK, il est donc possible d'effectuer une réinitialisation.
Je vais ajouter une vérification pour N réponses inconnues, puis effectuer à nouveau une initialisation.

Cela pourrait résoudre complètement ce problème.

Pour l'instant, tout le problème de série que nous avions survenu sur chacun d'eux semble maintenant disparu sur le modèle A et avec deux des trois capteurs du modèle Mhz19B.
Esp08, qui est un modèle B, est le seul que j'ai vu avec une variable "réponse inconnue (à chaque changement) valeur hexadécimale" toujours dans les fichiers journaux, si ce capteur pouvait être réinitialisé hors du plugin lorsqu'il se comporte mal, c'est peut être la solution.

Mise à niveau de tout vers Mega 201902026 4Mb maintenant.

La première chose que j'ai remarquée, le type de capteur Co2 mhz19B donne des valeurs correctes presque instantanément après le flash de la nouvelle image, beaucoup plus rapidement qu'avant aussi.

Cela semble vraiment prometteur ! J'ai regardé ce fil, en attendant un moment où je pourrais enfin mettre à jour. :grin: J'ai un nœud auquel sont attachés à la fois un MH-Z19 et un PMS7003. Le MH-Z19 a fonctionné > 90 % du temps, mais j'ai parfois dû réinitialiser l'ESP pour cela.

Le PMS7003 semble cependant échouer beaucoup plus. La plupart du temps, même la réinitialisation n'aide pas, mais une déconnexion de l'alimentation pendant quelques secondes peut résoudre le problème. Je soupçonne que son connecteur pourrait être le coupable, mais je n'ai pas commencé à le déboguer. Ce fil m'a rendu curieux de savoir s'il pouvait encore être lié au micrologiciel... Je vais essayer quand je serai sûr que cela ne causera pas de problèmes avec le MH-Z19 car ses données sont plus importantes.

Et oui, j'ai remarqué que # 2349 ne touchait que le code MH-Z19 mais la version que j'exécute est "20100 - Mega (core 2_4_0)" qui, je suppose, est assez ancienne.

Je tiens à dire qu'il est rare de voir une telle persistance des deux côtés d'un problème. Je pense que beaucoup auraient abandonné après quelques jours. Chapeau à vous de la part de ce spectateur @TD-er et @pwassink !

Vous voudrez peut-être attendre 1 jour de plus avant de procéder à la mise à jour.
Je travaille actuellement sur des correctifs pour la connectivité réseau.

Merci pour l'info! J'avais l'intention d'attendre les rapports de @pwassink pendant un moment de toute façon (je suis paresseux).

Sachez simplement que beaucoup de choses ont changé depuis votre version actuelle, et malheureusement pas toutes positives.
L'un des problèmes que nous essayons toujours de résoudre est le redémarrage du chien de garde matériel. Vous voudrez peut-être conserver une sauvegarde des paramètres actuels que vous avez et notez la version actuelle que vous utilisez. Juste pour être sûr.
J'espère améliorer un peu ces redémarrages avec les correctifs d'aujourd'hui, mais comme ces redémarrages ont plusieurs causes différentes, je ne pense pas que les correctifs d'aujourd'hui les géreront tous.

Remarque prise. Je ne peux qu'imaginer la difficulté d'éviter la régression dans un système comme ESPEasy. Je signalerai toute régression après avoir effectué la mise à niveau (en tant que problèmes distincts, bien sûr).

Je prévois de mettre à niveau deux ESP que j'ai ici. Sur la base de ceux-ci, je peux seulement observer s'il y a une régression sur la gestion de l'affichage MH-Z19, PMSx003, BMx280, TSL2561, DHT22 ou OLED SSD1306. TSL2561 sur l'autre ESP a également tendance à arrêter de renvoyer des données de manière aléatoire (assez rare cependant). Il exécute la version "20102 - Mega".

Ce n'est pas la construction, mais le format de fichier interne (confus je sais) Vous pouvez trouver le nom/la date de construction dans la page sysinfo.

C'est sur le champ "build" au moins. Le nom de fichier binaire est "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames". Je l'ai probablement flashé directement depuis PlatformIO. J'aurais peut-être du mal à flasher la même version qu'il y a presque un an. Je n'ai pas vraiment pris de notes sans mentionner de tag. :joy: Eh bien, je suppose que je peux juste faire une sauvegarde du firmware si je ne me sens pas assez aventureux.

Pas d'horodatage de build dans la page sysinfo ?

Il y a un horodatage mais cela n'aidera pas beaucoup car je ne me souviens pas si j'avais inséré le dernier code avant de le faire. Mais bien sûr, cela donne une idée.

Ce n'est pas l'ESP qui héberge le MH-Z19 et le PMS7003.

Mais je suppose que cela sort du sujet. Désolé d'avoir temporairement détourné le fil et merci d'avoir quand même répondu à mes commentaires !

dans quelle version cela a-t-il été corrigé ?

au bout de quelques heures j'obtiens MHZ19 : Réponse inconnue : 0 0 0 0 0 0 0 0 0
le redémarrage ne résoudra pas le problème, il faut le débrancher et le rebrancher

J'utilise un wemos 1d mini pro, cette version contient-elle le correctif ?

Construire :⋄ | 20104 - Méga
-- | --
Bibliothèques système :⋄ | ESP82xx Core 2_5_2, SDK NONOS 2.2.1(cfd48f3), LWIP : 2.1.2 Prise en charge de PUYA
Version Git :⋄ | méga-20191003
Plugins :⋄ | 46 [Normale]
Construire Md5 : | 3180a4d3e118166b3414444513a6169
Contrôle Md5 : | passé.
Temps de construction :⋄ | 3 octobre 2019 02:15:29
Nom de fichier binaire :⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

Merci

Oui et les versions précédentes aussi.
Je suggérerais d'essayer avec la version 20190928, car celle d'octobre avait d'autres problèmes (que je corrige depuis environ une semaine)

Vous pouvez également consulter le nombre d'erreurs de lecture affichées sur la page du plug-in, après quelques heures d'exécution.

Par exemple une de mes propres unités (3 jours de disponibilité)

NB le filtre (réglé sur "Use Unstable" dans la capture d'écran) n'a pas de sens sur le capteur MH-Z19B, il n'est applicable que pour la version -A.

Et un autre:

Comme vous pouvez le constater, le nombre d'échecs de lecture est minime.
Si vous avez des erreurs là-bas, vous pouvez avoir un autre problème à portée de main.

ces 11 réinitialisations où j'essayais de le faire redémarrer sans le rebrancher, je ne me souviens pas avoir vu d'erreurs, mais je peux lui donner une autre chance, devrais-je utiliser Software Serial?

Hardware Serial est le meilleur, mais vous devez également désactiver le port série dans Tools->Advanced->Serial Port. (comme indiqué dans votre capture d'écran :) )

Je ne sais pas si un adaptateur USB vers série présent sur la carte peut avoir un effet sur la communication.
En cas de doute, vous pouvez passer au logiciel série.

Version : ESP_Easy_mega_20201130_normal_ESP8266_4M1M
rendre compte à la FHEM.
J'ai eu un problème similaire : le capteur MH-Z190B se fige toutes les quelques heures et continue de chuter à 400 lorsque j'utilise le matériel série.
Après être passé au logiciel série, il semble fonctionner normalement et ne gèle plus.
2 captures d'écran jointes.

Le BME280 attaché avec I2C fonctionne bien et continue de rapporter tout le temps

Hum c'est étrange.
À quel port série HW était-il connecté ?
Quoi d'autre est connecté à la carte? (par exemple USB vers puce série)
Est-ce que "Utiliser série" est décoché sur la page Outils->Avancé ?

Il est connecté à GPIO-13 (D7) <- TX et GPIO-15 (D8) -> RX (d'abord en HW maintenant en SW) car je voulais utiliser les TXD0 et RXD0 pour lire les messages via le port USB (CH340 ) de la Wemos D1 mini.
Est-ce que "Utiliser série" signifie "Paramètres série - Activer le port série :" ? J'ai laissé cette case cochée pour pouvoir lire les messages par USB.

La série HW sur un ESP8266 utilise Serial0.
Si vous envoyez également des journaux au même port série, le capteur peut se bloquer car il ne comprend pas les "commandes" qu'il reçoit lorsque les journaux sont envoyés via ce port.

Si vous connectez quelque chose au port série HW, vous ne devez plus envoyer d'autres données. Ainsi, vous devez désactiver "Utiliser série" sur la page outils->Avancé.

Hier, j'ai reçu un deuxième capteur MH-Z19C. Celui-ci semble fonctionner correctement avec HW-Serial sur Serial2. Comme les capteurs étaient tous connectés aux broches D7 (GPIO 13) et D8 (GPIO 13) (RXD2 et TXD2), il ne devrait pas y avoir de conflit avec Serial0 (broches RXD0 (GPIO3) et TXD0 (GPIO1)) pour autant que je sois comprendre le Pinout. Je pense que le premier capteur (MH-Z19B d'un autre fournisseur) n'était qu'un faux ne fonctionnant pas du tout correctement, ...
Soyez donc prudent lorsque vous achetez ces capteurs. Le second, que j'ai reçu hier, était dans un bien meilleur emballage avec le logo Winsen et un certificat de test joint. Le fournisseur semble être plus sérieux que celui qui m'a vendu le premier.