Je dois améliorer le pilotage d’une VMC (capteur hygro), et de lampes (détecteurs de présence et de luminosité dans les pièces). J’ai donc besoin d’un peu de réactivité.
Je cherche les différence de vitesse d’acquisition entre les deux familles de capteurs :
« X-THL »
La doc indique des remontées automatiques vers IPX800v4 toutes les 5 secondes. Sous Jeedom, il suffit donc de régler le pulling du plugin sur cette valeur. C’est très réactif.
« SHT-X3 »
Je n’arrive pas à trouver les infos, je ne sais pas ce qui est le plus réactif.
Sous IPX800v3
-A quelle fréquence les valeurs sont remontées à l’IPX ?
-A quelle fréquence peut-on interroger l’IPX sans le surcharger ?
Sous IPX800v4
-Peut-on interroger l’IPX toutes les 5 secondes (comme X-THL) ?
il y a une différence fondamentale entre X-THL et SHT-X3, le 1er est relié au bus EBX, le 2nd à 3 entrées analogiques de l’IPX. Ceci implique des différences de fonctionnement :
le X-THL est interrogé toutes les 5 s, ça pourrait être plus rapide mais c’est largement suffisant pour des données variant lentement. Les entrées analogiques sont scrutées en permanence (plusieurs dizaines de fois par seconde). Dans les 2 cas les valeurs analogiques lues sont stockées et peuvent être consultées à la fréquence que l’on veut sans perte.
on peut connecter jusqu’à 14 X-THL sur une V4 (pas compatible V3), 1 seul SHT-X3 sur les entrées analogiques d’une IPX,
le bus EBX permet de déporter facilement les X-THL à plusieurs dizaines de mètres, c’est plus compliqué pour le SHT-X3.
Pour ce que je comprends de votre besoin, le SHT-X3 ne parait pas adapté.
Oui, 5 secondes c’est parfait. Est-ce que cela signifie que Jeedom peut interroger les entrées analogiques de l’IPX800v3 à cette fréquence sans surcharge ?
Je demande, car sur un autre IPX800v3, j’avais tenté de lire un XC-400T toutes les 2 mn via un scénario infini. Cela plantait au bout de quelques heures, ce qui m’a fait considérer qu’un capteur bus serait plus fiable.
Je précise le contexte…
Ma salle de bain est équipée d’un SHT-X3 raccordé à un IPX800v3. Le scénario de déclenchement VMC fonctionne très mal à cause de remontées « erratiques » de l’hygrométrie (pas de souci de câblage, température et luminosité sont OK).
Le capteur étant proche du plafond, j’ai pensé à une mauvaise implantation. J’utilise donc à la place et depuis un moment, un capteur d’humidité zwave (posé 30cm plus bas) qui est réactif et fiable.
Je note que la remontée des entrées analogiques sur l’IPX800v3 est quasi temps réel, donc je réalise que le souci est sans doute côté Jeedom :
IPX800v4 → RAS
On dispose d’un plugin, et d’un démon capable de lire chaque seconde.
IPX800v3 → KO
Il n’y a ni démon, ni plugin fonctionnel, les remontées analogiques s’effectuent par polling (lancement d’un scénario via cron toutes les X mn).
Avant de me revérifier l’incidence du capteur dans la pièce, je voudrais être certain de pouvoir l’exploiter de manière fiable.Que pensez-vous de :
laisser le polling à 5mn
déclencher la VMC sur push → Jeedom sur dépassement de valeur.
bonjour,
il manque l’information essentielle :
« La vmc est-elle branchée sur une sortie IPX ? »
Si oui, le menu analogique de l’ipx permet de piloter directement le relais sur dépassement de seuils.
NB : l’hystérésis doit être définie avec une très grande attention. Les entrées analogiques sur IPX800 V3 — GCE Electronics (gce-electronics.com)
Sur V4 vous pourrez piloter la VMC de la même manière avec les seuils analogiques.
Si la VMC est pilotée par jeedom uniquement :
vous pouvez effectivement laisser le polling à l’initiative de Jeedom toutes les 5 minutes pour historiser les valeurs.
Pour une plus grande réactivité la gestion de la clim doit impérativement être faite par l’ipx800 V3 .
Comme vous le présentiez, le dépassement de seuil sur analogique géré par IPX permet de lancer un push vers Jeedom (à la seule condition que la VMC ne soit pas connectée directement à l’IPX, sinon le pilotage est 100% ipx).
Vous pouvez par exemple basculer une IO virtuelle sur Jeedom, ou tout simplement forcer une màj de l’analogique en question pour que jeedom lance son script sur dépassement.
Il y a donc plusieurs façons de procéder.
Vous trouverez des exemples de push à l’initiative de l’ipx vers Jeedom dans ce post :
Oui la VMC est connectée à une sortie IPX, mais tout est piloté par Jeedom. Je préfère cette approche car tout est regroupé au même endroit.
Sur base de nos échanges, je m’apprêtais à migrer vers du polling Jeedom toutes les 5mn, + du push sur dépassement de seuils pour activer la vitesse haute aussi rapidement que possible.
Malheureusement, mes derniers tests de polling Jeedom vers IPX800v3 ne sont pas satisfaisants. Malgré un cron toutes les 5mn et une configuration « répéter les valeurs identiques » sur oui, les remontées restent irrégulières.
Vu IPX, tout est parfait, donc le problème est sans doute côté Jeedom. Je regrette que GCE n’ait pas développé un plugin Jeedom + démon pour l’IPX800v3.
Comme je viens de m’équiper d’un IPX800v4, et que les tests du X-THL sont excellents (régularité + rapidité), je vais migrer mes SHT-X3 vers des X-THL.
Certes, il y a un coût, mais le résultat est conforme à mes attentes.
Merci pour toutes les précisions et le lien vers le tuto complet.
