Eviter les erreurs de relevés de température

Bonjour,
Savez-vous comment éviter les erreurs de relevé de températures rendant le graph illisible (plus 1234 degrés et moins 200 degrés) ?
J ai essayé les modes 'sans' et 'sans changement' des sondes de températures dans msapp mais sans amélioration.
Exemple en pièce jointe.
Merci

Bonjour Tmf76.

Beaucoup parmi nous ont des problèmes de sondes.
Le soin apporté à la séparation du 220 des câbles servant aux sondes est important. Le type de câble également, mais parfois rien n'y fait, les problèmes subsistent. Parcours le forum, des fois, l'insertion d'un filtre suffit à régler le problème et parfois non.

Cette fois-ci, ça y est...

Après avoir essayé d'améliorer le circuit 5V (blindage du câblage des sondes, condensateurs, résistances série, pull-up, ...) sans succès, j'ai tenté d'améliorer le circuit 230V (alimentation de la résistance du ballon).

Le courant est haché pour moduler la puissance, ce qui génère des harmoniques et peut perturber les signaux transitants au voisinage. J'ai donc ajouté un
filtre passe-bas en sortie de SSR en n'y croyant qu'à moitié parce que je n'avais aucune idée de l ordre des harmoniques générées et donc de l'adéquation du
filtre (pas d'oscilloscope à la maison).

Et ça fonctionne ! Mesures précises, sans parasites ou valeurs aléatoires

www.aliexpress.com/item/32679738199.html

Si tes sondes de températures sont utiles dans la gestion du Mspvsun, essaie d'insérer des temporisations qui permettent d'éviter ces sauts. (dans mon cas ça marche très bien)
Néanmoins ces sauts apparaitront toujours dans les graphiques.

Si par contre, tes sondes ne sont là qu'à titre indicatif, patiente un peu, Patrick devrait prochainement mettre en ligne une version1.04 qui devrait régler tout ou partie des problèmes.

Je viens de faire quelques modifs au firmware wifi pour améliorer la lecture des sondes.

J'ai viré le petit bout de code qui envoyait le fameux 1234,5°C. C'est moi qui avait mis ça là pour que l'on voit bien quand les données ne passaient pas. Du coup ben ça se voyait un peu trop !

La surveillance des sondes se fait avant le traitement des températures par la boucle de régulation. Cette surveillance est prise en compte par les thermostats par exemple.
Et on peut mettre les compteurs de surveillance à zéro pour une réaction immédiate.

Sans configurer la surveillance, avec la config de base, si une sonde n'est pas lue correctement sa valeur ne change pas, elle reste sur la valeur précédente.

Tout ça sera dans la prochaine mise à jour 1.0.4a que j'espère pouvoir (enfin!) mettre en ligne dans quelques jours...

Rob_27 écrit:

Bonjour Tmf76.

Beaucoup parmi nous ont des problèmes de sondes.
Le soin apporté à la séparation du 220 des câbles servant aux sondes est important. Le type de câble également, mais parfois rien n'y fait, les problèmes subsistent. Parcours le forum, des fois, l'insertion d'un filtre suffit à régler le problème et parfois non.

Cette fois-ci, ça y est...

Après avoir essayé d'améliorer le circuit 5V (blindage du câblage des sondes, condensateurs, résistances série, pull-up, ...) sans succès, j'ai tenté d'améliorer le circuit 230V (alimentation de la résistance du ballon).

Le courant est haché pour moduler la puissance, ce qui génère des harmoniques et peut perturber les signaux transitants au voisinage. J'ai donc ajouté un
filtre passe-bas en sortie de SSR en n'y croyant qu'à moitié parce que je n'avais aucune idée de l ordre des harmoniques générées et donc de l'adéquation du
filtre (pas d'oscilloscope à la maison).

Et ça fonctionne ! Mesures précises, sans parasites ou valeurs aléatoires

www.aliexpress.com/item/32679738199.html

Si tes sondes de températures sont utiles dans la gestion du Mspvsun, essaie d'insérer des temporisations qui permettent d'éviter ces sauts. (dans mon cas ça marche très bien)
Néanmoins ces sauts apparaitront toujours dans les graphiques.

Si par contre, tes sondes ne sont là qu'à titre indicatif, patiente un peu, Patrick devrait prochainement mettre en ligne une version1.04 qui devrait régler tout ou partie des problèmes.

Je viens de faire quelques modifs au firmware wifi pour améliorer la lecture des sondes.

J'ai viré le petit bout de code qui envoyait le fameux 1234,5°C. C'est moi qui avait mis ça là pour que l'on voit bien quand les données ne passaient pas. Du coup ben ça se voyait un peu trop !

La surveillance des sondes se fait avant le traitement des températures par la boucle de régulation. Cette surveillance est prise en compte par les thermostats par exemple.
Et on peut mettre les compteurs de surveillance à zéro pour une réaction immédiate.

Sans configurer la surveillance, avec la config de base, si une sonde n'est pas lue correctement sa valeur ne change pas, elle reste sur la valeur précédente.

Tout ça sera dans la prochaine mise à jour 1.0.4a que j'espère pouvoir (enfin!) mettre en ligne dans quelques jours...

Ah super vivement la mise à jour alors, j'aimerais simplement dans mon cas, que si le routeur n'arrive pas à joindre/relever la sonde, qu'il reste sur sa dernière valeur connue plutot que d'envoyer des +1234° ou -200°...
--> Conséquence : aucune sur la programmation qui suit son cours, et aucune sur le graphique qui reste stable/lisible...

Merci @Patrick pour la modification.

Bonjour,

Vous savez si la mise à jour est sortie ?

Pas de News, je pense que Patrick est en congé.

Espérons que nous aurons cette mise a jour qui m'intéresse également très fortement à la rentrée

Bonjour, la mise à jour est sortie et installé chez moi, mais j'ai toujours des problèmes de relevés de température avec une configuration des sondes en mode 'sans changement'.

L'une T_ECS ne sort plus de valeurs délirantes, en revanche lorsqu'elle perd la sonde, elle affiche la dernière température relevé moins l'offset de calibrage réglé (voir graph), cela joue donc sur mes scénarios qui se basent sur la température (j'ai du ajouter +30° d'offset sur la sonde de l'ECS pour avoir une valeur à peu près cohérente).

L'autre T_SDB continue d'enregistrer des valeurs délirantes (-130/-180°...) rendant toujours le graphique illisible.

Et c'est très problématique, en effet avec mon scénario, des que le routeur envoi sur une sortie avec un peu de puissance, la sonde coupe, le routeur remonte la T_ECS a 55° (au lieu de 85°C) et je sors de ma regle (T_ECS> 75°), le routeur coupe toutes les sorties, injecte plusieurs wh dans le réseau le temps que la sonde remonte la bonne valeur de 85°, réactive les sorties, la sonde re-déconne, le routeur détecte 55° au lieu de 85°, coupe les sorties.... c'est un cercle sans fin me faisant injecter dans le réseau sans raison et coupant les sortie, les rallumant.... sans cesse.

@ Patrick : quelle serait une solution à ce sujet ? Je pense qu'il faudrait que le mode 'sans changement' de la sonde fonctionne correctement, c'est à dire qu'il prenne la dernière valeur connue et avec l'offset s'il y en a un.
Sinon il est impossible d'envisager des scénarios sérieux basés sur les sondes de températures.

Merci

Bonjour Tmf76.

Merci pour ton retour d'expérience. Ce dernier me conforte d'attendre encore un peu avant de changer de version. Comme toi j'attendais le règlement de ces sauts de sonde, car pour contourner ce problème, j'ai alourdi mon schéma avec des temporisations. Néanmoins cela fonctionne bien, même si les sauts apparaissent bien évidemment sur les schémas.
Si ca peut t'aider, regarde comment TMP6 retarde de 3min, la prise en compte de TH4 pour changer la commande de SOL1. En clair si la sonde T_Ball a une saute d'humeur pendant moins de 3 min, cela est sans conséquence.

Du coup, je vais attendre d'autres retours ou tout simplement cet hiver quand la production sera proche de zéro, pour modifier la version du routeur.

Rob_27 écrit:

Bonjour Tmf76.

Merci pour ton retour d'expérience. Ce dernier me conforte d'attendre encore un peu avant de changer de version. Comme toi j'attendais le règlement de ces sauts de sonde, car pour contourner ce problème, j'ai alourdi mon schéma avec des temporisations. Néanmoins cela fonctionne bien, même si les sauts apparaissent bien évidemment sur les schémas.
Si ca peut t'aider, regarde comment TMP6 retarde de 3min, la prise en compte de TH4 pour changer la commande de SOL1. En clair si la sonde T_Ball a une saute d'humeur pendant moins de 3 min, cela est sans conséquence.

Du coup, je vais attendre d'autres retours ou tout simplement cet hiver quand la production sera proche de zéro, pour modifier la version du routeur.

Bonjour Rob, merci pour ton retour.

Du coup comment se comporte la tempo ? je n'en utilise pas.

Elle est positionnée sur une sonde de température et attend x secondes/minutes que la temp est bien au-dessous/en dessous d'une certains valeur avant d'envoyer une commande de thermostat ou autre ?

Peux-tu m'envoyer des captures d'écran de ta configuration, je vais essayer de mettre ça en place, je pense que ce sera la seule solution viable.

Merci

patrick écrit:

tmf76 écrit:

@ Patrick : quelle serait une solution à ce sujet ? Je pense qu'il faudrait que le mode 'sans changement' de la sonde fonctionne correctement, c'est à dire qu'il prenne la dernière valeur connue et avec l'offset s'il y en a un.
Sinon il est impossible d'envisager des scénarios sérieux basés sur les sondes de températures.

Merci

Ben ça marche déjà comme ça:

remplaceme...ndes.avi

Quand le nom de la sonde s'affiche en jaune c'est que je l'ai débranchée, en blanc elle est rebranchée.

Par contre tu le dis toi même, tu as de gros soucis de parasitage du routeur sur la sonde.
Elle est placée à quelle distance de la résistance du CE ?
Le relais est dans le tableau élec ou à côté du CE ? Reliés avec quels type de câbles ?

Il y a quand même qlq chose que je pourrais améliorer pour supprimer ces valeurs négatives ou proches de zéro, j'en reparlerai...

J'ai mis dans mon cas 'sans changement' dans la partie gauche de l'encadré 'Surveillance Sondes' et également dans la partie droite (j'ai également supprimé le -30° initial sur le paramètre mini/discon pour mettre 0°), je vais essayer avec seulement la partie droite comme ton exemple Patrick.

En revanche je voulais apporter une précision, j'ai mis à jour msapp, les fichiers du serveur web et le firmware du routeur mais pas la configuration (j'ai tellement fait de modification/programmation que tout reprendre depuis la nouvelle conf 4x4 en v1.0.4a serait un gros travail), peut-être que la mise à jour de la configuration à son importance également ?

Mais effectivement le problème initial est un gros parasitage des sondes lorsque le ballon tire >1.5kw/2kw, la sonde est dans le doigt de gant du ballon, et passe également par le même fourreau que l'alim du ballon (sur 5m à peut près depuis le ssr qui est à coté du routeur qui est lui-même dans mon tableau électrique), le problème initial est ici mais je ne peux pas faire autrement, enfin si je pourrai mais il faudrait que je perce mon vide sanitaire et que je mette un second fourreau vers mon ballon, mais il resterait le parasitage de la sonde dans le doigt du gant du ballon.

Bonjour,

Je t'envoie mon pdf comme demandé.
Dans mon cas j'ai mis une tempo pour éviter les problèmes de sonde indiquant 1234,5.
Pour comprendre cet exemple regarde TH4, thermostat fonctionnant jusqu'à 68° avec en entrée une sonde T_Ball .
En Sortie de TH4, si la température n'est pas atteinte alors sa sortie "On" attaque une Tempo TMP6, qui bloque son action pendant 180sec. Passé ce délai, elle active SOL1 par le biais de TH7. TH7 ne sert à rien en tant que tel(valeur mise à 2000, donc impossible à atteindre) mais n'est présent que parce qu'un module Tempo ne peut pas activer un module SOL.
Donc, alors que la température du thermostat n'est pas réellement atteinte (moins de 68°) et que survient le saut à 1234,5°, SOL1 ne sera pas désactivé, sauf si cette valeur reste plus de 3 minutes.(cela ne m'est jamais arrivé). Au pire, pendant ce saut 1234.5°, le "val off" de TH4 m'active SOL2 en même temps que SOL1 (car les 3 minutes ne sont pas écoulées) mais ce n'est pas gênant.
Lorsque TH6 aura réellement atteint les 68°, au bout de 3min SOL1 se désactivera définitivement.
En espérant avoir été clair.

Voici le comportement de mon m'sun pv en vidéo au sujet de ces sondes de températures et ceci avec les même réglage que la vidéo de Patrick :
streamable.com/c8admc

patrick écrit:

Mickaël, comme tu es à fond dessus en ce moment pourrais-tu essayer cette maj, la 104b:

Fichier attaché :

Nom du fichier : fw-wifi_104b.zip
Taille du ficher :1,382 ko

Tu peux ne mettre à jour que le firmware wifi par l'interface web, le reste ne change pas de toutes façons.

J'ai pas mal blindé la lecture des sondes de température, les parasites ne devraient plus passer.
L'inconvénient c'est que l'affichage reste sur la dernière valeur OK.
On a quand même l'indication que qlq chose cloche par l'affichage en jaune du nom de la sonde.

Sur cette vidéo je simule un parasite en passant la commande 1 à 0 ou à 1:

parasite_sondes.avi

Super merci Patrick, je teste ça ce soir

patrick écrit:

Mickaël, comme tu es à fond dessus en ce moment pourrais-tu essayer cette maj, la 104b:

Fichier attaché :

Nom du fichier : fw-wifi_104b.zip
Taille du ficher :1,382 ko

Tu peux ne mettre à jour que le firmware wifi par l'interface web, le reste ne change pas de toutes façons.

J'ai pas mal blindé la lecture des sondes de température, les parasites ne devraient plus passer.
L'inconvénient c'est que l'affichage reste sur la dernière valeur OK.
On a quand même l'indication que qlq chose cloche par l'affichage en jaune du nom de la sonde.

Sur cette vidéo je simule un parasite en passant la commande 1 à 0 ou à 1:

parasite_sondes.avi

Bon, l'heure de la maj est arrivée, par wifi impossible et par usb j'ai l'erreur suivante.... (alors que la dernière fois c'est bien passé en wifi)

Les pilotes sont bons et a jour, le pc détecte bien le routeur, j'ai essayé deux câbles différents...
Je suis maudit