Bloquage des temperature

Bonjour,

Ce n’est pas simple en effet de résoudre des Pbs aléatoire sur un BUS 1Wire d’autant plus à distance. Ces désordres peuvent être induit par un Objet 1Wire qui dysfonctionne et qui perturbe le BUS de façon aléatoire : composant +- défectueux, parasite électrique, Bus mal équilibré etc..

Une solution consiste à analyser les trames du BUS 1Wre comme évoqué dans un de mes Post : https://www.cartelectronic.fr/blog/?topic=probleme-sur-bus-1-wire&paged=2#post-10213.

Via ce petit module que je décrit, on peut trouver facilement les Objets 1Wire qui passe en erreur ou qui ne réponde pas correctement à chaque sollicitation du WES. Mais quand le phénomène est aléatoire, pas facile de tomber sur le problème lorsque qu’il arrive en plus à distance !.

D’après ce que j’ai pu analysé avec ce petit Module, le Serveur WES lance de façon cyclique, toutes les 30 secondes, 2 Trames de commandes 1Wire. Une première trame avec la commande FCT 0x44 Hexa est lancé sur le BUS afin de demander à toutes les Sondes de lire leur propre Température de façon interne, puis le WES lance 4 secondes après une lecture cyclique de toutes les Sondes Présente pour en extraire les Informations précédemment mémorisés par ces Sondes.

Le Serveur WES ne fait pas à ma connaissance de statistique sur les composants qui passe en Erreur. Le WES met bien les Sondes en grisées lorsqu’elles ne répondent plus, mais je ne sais pas au bout de combien de contrôle d’erreur le Serveur décide de passer l’Objet en erreur.

Il faudrait faire une analyse plus poussé pour mettre ces incidents aléatoire en évidence.

Chez moi j’ai réalisé, via un petit Microcontrôleur ESP8266, un POND 1WIRE qui me permet de gérer directement le BUS 1Wire de mon domicile depuis un Raspberry en Même Temps et en Parallèle avec le WES. Cela revient en deux mot à avoir 2 serveurs 1WIRE qui gère le même BUS 1Wire. Cela me permet de commander des Objets 1Wire depuis le BUS du Domicile qui ne sont pas gérés en Natif depuis le WES

En partant de ce principe, on peut remplacer le Raspberry par un autre Microcontrôleur ESP8266 qui pourrait analyser les Trames 1Wires reçus du 1er ESP8266 (Serveur 1Wire) et via son WIFI émettre par e-Mail le résultat des Trames 1Wire lorsque des erreurs sont constatés.

De cette façon vous avez une vue en temps réel des erreurs lorsqu’elles interviennent.

J’utilise des Microcontrôleur ESP8266 ou NODEMCU au regard des Prix très bas de ces composants, de leur capacité mémoire importante, de leur fréquence CPU d’utilisation (80mhz ou 160Mhz) et la facilité pour les programmer.

Je vous joint un Schéma qui reprend (en partie gauche du schéma) mon POND 1WIRE avec la sortie des deux BUS 1Wire (WES et Domicile) qui fonctionne chez moi associé à mon Raspberry PI.

Mais dans le Schéma que je vous joins j’ai couplé le ESP8266 Serveur 1Wire de base à un 2eme ESP8266 ( à la place de mon RASP) qui va gérer les requêtes e_MAIL via son WIFI.

Le 1er ESP8266 ne peut pas gérer en plus des interruptions matériels déjà traités par les Trames du BUS 1Wire et des Commandes I2C de la gestion et gérer en temps réel son WIFI pour emettre les e_MAIL. C ‘est pour cela qu’il faut passer par un 2eme ESP8266 pour gérer le WIFI.

Si vous pensez vouloir vous lancer dans ce montage, je peux vous fournir les SKETCH (programme) fonctionnel à télécharger dans chaque ESP8266 via le programme IDE Arduino. Faites moi savoir si cela vous intéresse.

Cette maquette vous enverra un e_Mail en temps réel avec un compte rendu et data fournis , lorsque des erreurs seront décelés sur un ou plusieurs OBJET 1Wire.

Cdt

RE: J’ai oublié de mentionner que le 1er ESP8266 (celui de gauche) qui est utilisé comme Serveur 1Wire Maître dans mon Schéma, Scanne le BUS 1Wire de mon domicile de façon cyclique toutes les Secondes, alors que le WES en fait un Scan complet que toutes les 30 secondes .

Donc j’accède beaucoup plus rapidement côté Gestion, via la communication I2C, aux Datas et Infos des Objets 1W connectés sur le Bus 1Wire Physique du Domicile.

On peux si l’on veut, augmenter ou diminuer cette tempo cyclique, Cela dépend du nombre d’Objets à analyser sur le BUS 1Wire Physique et de la gestion des datas que vous faites après par le biais de la communication I2C qui sert de passerelle vers un autre Microcontrôleur (Raspberry, ESP8266 Wifi Mail, autres..).

Re: Une dernière information, le ESP8266 Serveur 1Wire (ESP de gauche) répond par Interruption en Mode Esclave dans la communication I2C.

Donc on peut connecter sur son BUS I2C n’importe quel microcontrôleur en Mode Maître I2C pour faire la gestion du Bus 1Wire du Domicile, le tout en parallèle et sans nuire à la gestion 1Wire propre du WES.

Bonjour,

Pour @nicolas, afin de pouvoir faire une maintenance plus poussée depuis le WES et voir à corriger des erreurs aléatoires qui pourraient apparaître lors des échanges avec les composants 1Wire connectés sur le BUS 1Wire du WES, il serait bien d’avoir, via l‘activation provisoirement d’une OPTION, une surveillance type Débug du BUS 1Wire et d’enregistrer dans un fichier LOG, les Erreurs constatés dès l’accès à un ou des composants 1Wire connecté au BUS. L’enregistrement du n° de la Sonde ou Carte Relais vue en défaut à l’instant T, avec la date et l’heure suffirait.

Lorsque le Serveur WES interroge un Objet 1Wire, il lui est facile de voir si le composant répond correctement ou si une erreur se produit dans les échanges des Trames 1W avec cet Objet. Il serait bien d’avoir une vue d’ensemble, même si ces erreurs sont aléatoires et ne concerne qu’un échange épisodique.

La tache du WES qui scrute le Bus 1Wire n’est active actuellement que toutes les 30s, je pense qu’enregistrer en fin de séquence d’un cycle de lecture, un compte rendu LOG (si Option débug Activé) et uniquement si une erreur est constaté sur un ou des Objets 1Wre, ne devrait pas manger trop de ressource CPU.

Cela faciliterait l’équilibrage du BUS 1Wire et permettrait de mieux déceler les Objets 1W auprès desquels il serait utile de connecter une résistance de Pull Up de 4.7k afin de voir à réduire les erreurs avec ces Objets. De bien entendu, si le BUS physique n’est pas lui même réalisé conformes aux règles pour ce type de communication, l’ajout de résistance de 4.7K n’apportera rien sur les incidents.

Peut être serait t’il bien de voir la possibilité d’intégrer cette Option, assez facile à mettre en oeuvre, dans une prochaine Release.

Cdt