Jai un irritant régulier sur mes équipements thermostats : si la sonde ne communique pas une nouvelle température dans le temps défini dans l’équipement thermostat, celui-ci se met en défaut et envoie un message d’erreur. J’ai beau passé le délai avant défaillance à 90 minutes, cela arrive encore car j’ai des températures plutôt stables dans mes pièces. Je ne souhaite pas non plus répéter les valeurs identiques sur les équipements sonde de température car ça crée beaucoup de valeurs.
Ma proposition serait donc de pouvoir paramètre plus finement le critère « Défaillance sonde » par exemple en vérifiant la dernière communication de l’équipement. Ou en tous cas en laissant la main à l’utilisateur de paramétrer d’avantage de critères pour définir si oui ou non c’est bien une défaillance sonde (dernière communication, niveau de batterie, …).
Que du bien pour ma part !
J’ai exactement le même constat. J’ai mis 180 minutes chez moi, mais je ne peux (veux) pas non plus augmenter indéfiniment cette valeur, car sinon une panne réelle du capteur ne serait jamais prise en compte… Cela n’arrive pas tout le temps bien sûr, mais ça arrive régulièrement quand même (et pas plus tard que ce matin par exemple…).
J’ai en parallèle tout un processus qui checke en permanence l’état de mes capteurs pour vérifier s’il a bien communiqué dans un délai fixé, et ça fonctionne très bien. C’est d’ailleurs bien plus fiable que de vérifier uniquement le niveau de la batterie qui, bien souvent, indique encore une capacité de 80% pour une batterie qui est bien à plat. Ou inversement, j’ai aussi quelques modules qui fonctionnent très bien, bien qu’ils m’affichent seulement plus que 1%… depuis plusieurs mois (ou même années) !
Donc plutôt OK avec la proposition de @rom.jou de prendre en compte -au moins- le paramètre ‹ dernière communication ›, plutôt qu’une variation aléatoire.
Bonjour
Sur beaucoup de sonde, il est possible de faire que la température remonte toute les heures, même si elle ne change ( par exemple sur les Sonoff SNB-02D), et avoir une info de température par me semble pas fou…
Toi oui ?
Ps : je viens de vérifier
Sur la sonde de ma chambre, je devrais avoir une commande chaque 1/2 h max
Mais cette nuit, température stable et 4 h sans mise à jour….
J’avais jamais fait gaf
C’est pourtant un paramètre qui apparaît explicite dans Z2M
Bref, sorry…
PS2 : j’ai l’option « répétition des valeurs » à « Non »
Il ne faudrait pas la passer à oui, pour que vous n’ayez pas le problème ?
(Je vais essayer cette nuit)
Non mes sondes zigbee ne permettent pas ça, en tous cas c’est pas ce que je comprends dans les paramètres de « report » dans z2m. Et votre analyse semble le confirmer.
Et comme dit plus haut je ne veux pas répéter les valeurs identiques pour ne pas avoir trop de valeurs justement.
Juste pour préciser, il faut savoir que le plugin thermostat, pour la température intérieur par exemple, ne vérifie pas l’équipement source mais bien sa propre commande « température » (getCollectDate) donc faire une défaillance sonde sur la dernière communication de cet équipement (lastCommunication) , reviendrai a s’auto vérifier, et donc aucun intérêt car elle sera forcément mis a jour par d’autres commandes (temp ext…).
Il faudrait donc revoir le code pour contrôler l’équipement source, ou au minimum vérifier le getCollectDate de la cmd source.
En faite en analysant plus en profondeur il y a bien un truc qui ne fonctionne pas, du moins le getCollectDate ne s’appliquera pas sur la cmd du thermostat alors qu’il s’appliquera bien sur la cmd source :
Admettons que la cmd source soit en repeatEventManagement → never, donc pas de répétition de valeur.
Si il y a une répétition de la valeur sur la cmd source, le getCollectDate sera bien mis a jour sur celle-ci, mais il ne déclenchera pas l’event sur le plugin thermostat, et donc le getCollectDate de la cmd du plugin ne sera pas mis à jours.
C’est une limitation du core et pas du plugin
Il faudrait au minimum que le plugin check le getCollectDate de la source pour échapper a ce cas.
Bonjour
C’est volontaire on ne vérifie pas la date de collecte mais la date de changement réel de la température. Pourquoi ? Pour vraiment détecter toute les défaillances possibles en particulier une qui arrive ou le capteur remonte une valeur mais qui change pas.
Pour le délai avant détection il est donc conseillé de mettre plusieurs heure (10h par exemple)
Merci pour votre réponse à tous les deux. J’entends bien la réponse de Loïc et vais donc passer à 10h quitte à louper d’autres défaillances pendant ce laps de temps.
Je trouvais pas mal l’idée de pouvoir, au choix de l’utilisateur, paramétrer plus en profondeur le mode de défaillance (critères + actions déclenchées) mais je ferai avec ce que j’ai.
Sinon pour contourner, il est toujours possible d’avoir un scénario qui tourne toutes les heures pour check les infos, pour ensuite exécuter des actions custom. il faut simplement mettre un cron inférieur au plugin pour capter l’info avant l’action de défaillance.
le thermostat (plugin) passerait lui même en défaillance en fonction du délai que tu lui a mis, c’est pour ca qu’il faut que le cron du scénario soit inférieur au délai du thermostat.
Ex :
le thermostat avec un délai 90mn.
Un scénario qui ce lance toutes les heure :
Vérif si getCollectDate source > getCollectDate thermostat
Si Oui → event sur la cmd du thermostat, ce qui mettra a jour le getCollectDate
Si Non → on fait rien, la source n’est pas plus a jour que le plugin, on laisse le plugin gérer jusqu’a une defaillance sonde ou un changement de valeur sur la cmd source.
Bonjour à tous,
je suis sur le même problème en ce moment, merci pour vos suggestions.
Effectivement, 10h c’est un peu long. S’il y a une défaillance de la sonde durant la nuit, on peut se réveiller au frais.
Pour l’instant, je mets les radiateurs en ECO en cas de défaillance dans l’idée que ça consomme pas trop et que la température ne tombe pas.
Je me demandais surtout pourquoi le thermostat ne revenait pas à l’état normal après retour de la sonde. Pour l’instant, les radiateurs restent en ECO même quand la sonde revient à la vie.
Je vais essayer la solution du scénario bien que j’ai déjà plusieurs scénarios « Watchdog » qui tournent pour surveiller le zigbee qui plante régulièrement.
Bon, je vais faire mon boulet (pour une fois…).
Comment fait-on ça ? En passant par du code ?
Autant je vois sans problème comment récupérer l’info date de collecte pour la source, autant pour moi l’information getCollectDate dans l’équipement défini dans le plugin Thermostat n’est pas disponible directement.
Je me trompe ?
Merci pour vos lumières…
Oui , et le collectDate n’est pas affecté a l’équipement (eqLogic) mais bien a une commande (cmd)
Le plugin thermostat a sa propre cmd info de température qui est mis a jour par la cmd info température source.
Voici un bloc code qui boucle sur les équipements thermostat, recherche si la date de collecte du source est plus récente que le plugin, et si $forceCollectDateFromSource = true;, cela forcera un event sur la cmd temperature du thermostat pour ainsi mettre a jour la date de la collecte :
$forceCollectDateFromSource = false;
//////////////////////////////////////
foreach (thermostat::byType('thermostat', true) as $thermostat) {
$scenario->setLog('--------------- ' . $thermostat->getHumanName() . ' ---------------');
$temperature = $thermostat->getCmd(null, 'temperature'); // recup cmd température du plugin.
$temperatureSource = cmd::byId(str_replace('#', '', $thermostat->getConfiguration('temperature_indoor',0))); // recup cmd température source.
if ($thermostat->getConfiguration('maxTimeUpdateTemp') != '') { // lancé que si délai existe dans le plugin.
$scenario->setLog($temperatureSource->getHumanName() . ' CollectDate : ' . $temperatureSource->getCollectDate() . ' (' . strtotime($temperatureSource->getCollectDate()) . ')');
$scenario->setLog($temperature->getHumanName() . ' CollectDate : ' . $temperature->getCollectDate() . ' (' . strtotime($temperature->getCollectDate()) . ')');
if(strtotime($temperatureSource->getCollectDate()) > strtotime($temperature->getCollectDate())) {
$scenario->setLog('La date de la collecte sur la source est plus récente.');
if ($forceCollectDateFromSource) {
$scenario->setLog('event sur la température du plugin pour mettre a jour la date de la collecte');
$temperature->event($temperature->execute());
}
}
} else {
$scenario->setLog('Pas de délai entre 2 changements de T° configuré dans le plugin.');
}
}
Laisser la variable a $forceCollectDateFromSource a false pour ne faire aucun action et simplement analyser les infos du log.
Attention, ce bloc code si il est utilisé, ne permettra plus de détecter ce genre de défaillance (même si celle-ci doit être assez rare je pense) :
Bonjour,
Quelle est la condition pour que le thermostat sorte du statut « Défaillance sonde » naturellement ?
Sur défaillance de la sonde (valeur qui n’a pas bougée pendant plus de 3h), je mets les radiateurs en HG. Et si une nouvelle valeur de la sonde est mise à jour, cela ne suffit pas à faire repartir le thermostat, je suis obligé de passer le mode à OFF puis remettre au mode CONFORT pour sortir de ce statut « défaillance sonde ».
Note : je n’ai pas la conf « répétition des valeurs » au niveau des sondes pour limiter le nombre de valeurs.
Pour ma part je n’ai pas ce problème que tu décides, mes thermostats reprennent un fonctionnement nominal quand une nouvelle valeur de la sonde est communiquée. Et je n’ai pas de répétition de valeur non plus.
