votre demande est certainement réalisable, bien que complexe.
J’y vois néanmoins un inconvénient : justement cette complexité, mais là vue du coté de l’utilisateur.
Par exemple : déjà le fait de n’avoir qu’un seul bouton pour la manœuvre de base. Votre VR est ouvert et vous voulez le descendre à 30% : clic descente clic arrêt. Vous voulez maintenant le descendre à 70° : clic montée, clic arrêt clic descente clic arrêt.
Cette situation arrivera aussi si vous entrez dans une pièce avec le VR dans une position intermédiaire et vous ne savez pas si il est descendu ou monté vers cette position. Vous ne saurez donc pas dans quel sens il va partir à votre 1er clic.
Si vous ajoutez la dessus une erreur de manip, double clic ou clic long involontaire…
Maintenant imaginez un invité pas au fait du système qui essaye de manipuler les VR ou l’acheteur de votre maison à qui vous faites une démo
A mon avis la domotique doit simplifier la vie des usagers et être la plus transparente possible.
Ma suggestion : 2 BP pour chaque VR, un Up et un Down, quitte à leur faire gérer le 50% par un appui long et un ou des BP dédié(s) pour gérer les commandes générales ou un X-Display si vous préférez.
C’est ce que j’ai fait chez moi et mon épouse, technophobe assumée, ne voit que les avantages de la domotisation, gestion automatisée des BSO en fonction de l’ensoleillement, chaleur, horaire…
Vous avez certainement raison. Maintenant, je ne vais pas attaquer mes cloisons à la meuleuse pour faire repasser des gaines, donc le plus simple est de faire avec un seul BP.
Disons que je simplifie le scenario:
1 appui « court » sur le BP => le VR monte
1 appui « long » sur le BP => le VR descend
1 appui court ou long PENDANT que le VR monte ou descend => le VR s’arrête
Les autres scenarios (mi-ouverture, etc…) gérés par menu dans le dashboard.
Je pense que c’est acceptable d’un point de vue technophobe.
Mais comment faire avec les options de l’IPX800 V5?
Pour votre première demande, je pense que c’est faisable en utilisant un compteur et 3 comparateurs
Une impulsion incrémente le compteur de 1, le comparateur utilisé dans 3 scènes différentes.
Et merci beaucoup pour les pistes que vous avez données. Je décrouvre l’IPX800 côté programmation (et la programmation domotique en général) et n’avais pas vu cette histoire de compteurs ni à quoi ils pouvaient servir. A priori, pas d’opération modulo donc. Il faut le faire « à la main ».
J’ai l’impression que c’est différent de la logique informatique « classique » certainement pour des raisons physiques d’implémentation des opérateurs dans les modules domotiques.
@GCE
Est-ce qu’il y a des protections qui empêchent physiquement dans l’X-4VR de fermer les relais « montée » et « descente » en même temps? J’aimerais éviter de cramer mes VRs et peut-être l’X-4VR si je fais une erreur de programmation…
Il doit y avoir un truc que je ne comprends pas dans la logique GCE… . Et comme il y a peu d’exemples facilement accessibles, je sèche.
J’essaye de faire un truc tout bête:
A chaque appui sur le BP, j’incrémente le compteur de 1
Pour ce faire je crée une règle dans laquelle en « Event » j’ai l’entrée digitale de l’X-24D sur laquelle est branché le BP et en « Result » l’incrémentation d’un compteur.
Pour vérifier le fonctionnement j’ai mis deux widgets dans un dashboard:
pour afficher si le BP est enfoncé
pour afficher la valeur du compteur « counter value »
Le premier widget passe à ON quand j’appuie sur le BP.
Par contre le second widget montre que le compteur n’est pas incrémenté (si je le fais manuellement en changeant sa valeur, le widget fonctionne bien).
Qu’est-ce qui ne va pas dans ma façon de procéder?
Par contre je n’avais pas mis d’action au résultat.
Je commence à comprendre la logique du truc. Il faut rajouter une action pour chaque brique ou suite de briques « Result ». Cette action étant corrélée au changement d’état de la règle spécifiée dans « Event ».
Donc, dans mon cas, si on veut que la brique de résultat correspondant à l’incrémentation du compteur soit activée il faut que l’action « ON » y soit attachée (passage de l’état 0 à 1 du BP reliée à l’entrée digitale du X-24D).
bonjour
il faut utiliser un objet Appui long en mode Auto Off.
La sortie standard peut alors engendrer une action et la sortie appui long une autre.
Il faudra une règle pour repasser la sortie appui long à off.
Le BP sera donc lié à l’entrée
Attention je vous ai donné un exemple simple mais il faut penser à changer la valeur du compteur si vous n’avez pas utilisé le stop par exemple.
Avec une tempo réglée à la durée de mouvement du volet et un SETVAL dans un scénario, ceci pour éviter de devoir appuyer plusieurs fois pour incrémenter le compteur pour rien.
Un objet Long Click est branché en sortie à deux monostables:
un sur la sortie OUTPUT
un deuxième sur la sortie LONGCLICK
Ainsi,
le premier monostable envoie une impulsion au compteur lors d’un appui court.
Le second monostable envoie deux impulsions (au passage à 1, puis au retour à 0) au compteur lors d’un appui long.
Mon problème:
Lors d’appuis courts le compteur s’incrémente bien de 1.
Lors d’appuis longs, le compteur s’incrémente bien de 2.
MAIS, lorsque je reprend un appui court après des appuis longs, le compteur n’est pas incrémenté lors du premier appui court (bien que le monostable qui lui est lié émet une impulsion sur sa sortie).
J’ai fait une dashboard de test pour vérifier ce comportement.
Très juste, je n’ai pas encore géré le cas où le volet part en butée.
On pourrait peut-être tester la position du VR et incrémenter le compteur lorsque 0% ou 100% est atteint (je ne sais pas si c’est possible).
Il faut déjà que je règle cette histoire de compteur qui ne veut pas s’incrémenter dans un cas précis alors qu’il reçoit bien une impulsion d’un monostable…
Si ma précédente question était trop longue, voilà mon problème:
J’ai deux monostables en entrée d’un INC+ d’un compteur.
J’aimerais savoir l’opération logique qui est réalisée entre les deux objets qui sont reliés sur cette entrée car je ne comprends pas le comportement.
Ce que j’observe avec cette séquence:
Impulsion Monostable 1 => INC+ OK
Impulsion Monostable 1 => INC+ OK
Impulsion Monostable 2 => INC+ OK
Impulsion Monostable 2 => INC+ OK
Impulsion Monostable 1 => INC+ KO
Impulsion Monostable 1 => INC+ OK
En résumé:
Quand Monostable 2 est activé alors la première impulsion du Monostable 1 ne fait pas incrémenter le compteur. Ensuite ça fonctionne de nouveau.
Quand le monostable 2 a été déclenché, le monostable 1 n’incrémente pas le compteur la première fois qu’il est actionné.
Quand le monostable 3 a été déclenché, le monostable 2 ou le monostable 1 n’incrémentent pas le compteur la première fois qu’il est actionné.
On dirait qu’il y a un effet mémoire au niveau de l’entrée INC+ quand on y branche plusieurs objets comme s’is étaient traités en cascade et que le n+1 enclenché bloquait les 0 à n autres objets lors de leur premier déclenchement.
Désolé pour le délai de réponse, congés estivaux
Il s’agit d’un bug ! J’ai ouvert un ticket en interne à ce sujet, il devrait être traité pour la prochaine version…
Je m’en doutais. J’attendais un peu avant d’ouvrir un ticket. J’imagine que c’est plus facile pour vous à gérer que de recevoir un message sur le forum.
De manière générale, s’il s’agit d’un bug et non d’une demande d’aide, la HelpDesk est généralement plus adaptée. Après, si je suis taggé dans le message, je vais finir par le voir à un moment ou à un autre
ou l’acheteur de votre maison à qui vous faites une démo 
