Bonjour Ă tous,
Il y a quelques années de cela, j’avais déjà expliqué comment construire un simulateur de présence, en utilisant des IO clignotantes sur IPX V4. Cela permettait de générer des retards aléatoires avec une récurrence très faible.
Cette méthode est tout à fait adaptable sur la V5.
Pour ceux que cela intéresse, l’article est ici :
Simulateur de présence — GCE Electronics (gce-electronics.com)
Pour la V5, je voulais le faire avec des liens uniquement.
Après pas mal de recherche, je vous joins les prémices d’un simulateur de présence qui pourra piloter des tâches en ON et en OFF (éclairage, prises commandées, …).
Cela fera l’objet d’un wiki lorsque ce sera plus consistant.
Pour générer une valeur aléatoire, j’utilise un objet type FADER, avec l’entrée LOOP activée.
Le Fader varie sans cesse entre son minimum et son maximum.
La plus grande difficulté à contourner, c’est que les objets temps de la V5 réajustent sans cesse leurs sorties countdown en fonction des variations sur leur entrée TA ou TB, même pendant le décompte.
Exemple avec un Délai dont l’entrée TA est liée au Fader. Son décompte est perturbé par les variations sur son entrée TA.
Lier la sortie du fader directement à l’entrée TA d’un objet temps était donc inenvisageable sans blocage de la valeur.
Pour capter la valeur du Fader à un instant T (activation d’un Trigger), la solution la plus simple était bien entendu de faire un SetVal par un scénario, mais je souhaitais le faire avec des liens.
La solution a été d’activer l’objet fonction pendant une seconde grâce à une impulsion afin qu’il reçoive la valeur du Fader tournant en boucle, puis désactiver la fonction pour qu’elle conserve la dernière valeur reçue.
Le même principe sera donc mis en œuvre pour retarder l’arrêt de la tâche simulée lorsque le planning retombe à l’état OFF.
Principe du simulateur :
Un objet Planning TOR prévoit les plages d’activités simulées.
Un retard aléatoire est appliqué à chaque activation et désactivation de sa sortie.
Fonctionnement du simulateur :
A l’activation de la sortie du Planning TOR, une impulsion active l’objet Fonction ce qui provoque la sauvegarde de la valeur actuelle du FADER.
Dés la retombée de la sortie de cette impulsion, un second objet PULSE commence alors le décompte avec un retard (TA) égal à la valeur du résultat de la fonction. Une bascule RS sera activée à son tour, enclenchant alors les tâches simulées.
L’utilisation de 2 objets PULSE laisse le temps à l’objet Fonction de récupérer la valeur du Fader et de l’appliquer à l’objet "PUSLE ACTION " avant que le décompte ne commence.
A la désactivation de la sortie du planning, c’est exactement le même processus qui se met en marche.
Un nouveau retard est calculé lors d’une nouvelle sauvegarde de la valeur du Fader.
Une dernière impulsion désactive la bascule RS ce qui a pour effet d’arrêter la simulation.
Toutes les impulsions ont une durée Tb de 1s.
Remarque 1: la valeur du fader représente la durée du retard en nombre de minutes, la fonction transforme cette durée en secondes.
Remarque 2 : un objet Télérupteur pourrait être utilisé à la place de la bascule RS.
En cas de multiples plannings se chevauchant, il vaut mieux utiliser la bascule RS, le basculement pourra être maîtrisé via les ordres sur 2 entrées bien distinctes.
Ce simulateur de présence permet de générer des retards aléatoires durant entre 2 et 45 minutes, à chaque lancement ou arrêt d’une tâche.
Voici une petite démo. Pour une meilleure compréhension, le planning TOR est remplacé par un bouton, les retards sont en secondes au lieu des minutes.
Les 2 toggles du 2nd widget correspondent à la sortie des impulsions permettant l’activation des fonctions, provoquant ainsi la captation de la valeur du fader. La 1ère impulsion est lancée sur le front montant de la sortie du bouton, la 2ème impulsion est lancée sur le front descendant. Je rappelle que le bouton a été mis à la place du planning Tor pour les besoins de la démo.
Il est tout à fait possible d’utiliser des plannings TOR avec des plages personnalisées de date à date. Ceux-ci pourront définir des horaires différents en fonction des saisons.
Il est également possible d’utiliser l’heure de lever, du méridien et du coucher de soleil comme base horaire pour application de retards aléatoires.
Pour rappel, le méridien se calcule à partir de l’heure de lever et du coucher du soleil, en fonction de la position géographique.
Le plugin Météo fournit ces données automatiquement.
Il faut d’abord configurer et activer le plugin Météo (Weather), puis configurer cette formule dans un objet fonction :
$327688$ +(($327689$ - $327688$)/2)
$327688$ étant l’id de la variable « Heure lever » et $327689$ l’id de la variable « Heure coucher »
N’oubliez pas de configurer le résultat de la fonction en type RAW.
Pour ceux qui ne connaissent pas les variables sous la forme $ID$, voici les explications ici:
Utilisation des variables — GCE Electronics (gce-electronics.com)
Bonne journée