Aller au contenu
vravolta

Gestion roller shutter

Recommended Posts

J'ai des stores classiques commandés par un module Fibaro roller shutter. Actuellement, il y a un scenario qui tourne selon la logique de descendre les stores le matin quand il fait chaud et les remonter vers 16:00. Mais ce que je voudrais, c'est les descendre puis les mettre non pas totalement fermés mais en position qui permet quand même de voir dehors, ce qui s'obtient en les remontant 1s après qu'ils soient arrivés en bas. Donc j'avais pour idée d'attendre 60s (durée max de descente) puis de demander aux stores de se mettre à la position de 1% (ce qui correspond à 1s de remontée). Problème: je ne sais pas comment faire dans un scénario pour dire d'attendre une durée donnée avant de lancer une action. Je pourrais écrire toute une QA pour ca, mais je trouve dommage de devoir recoder l'équivalent de mon scénario en lua et de perdre la facilité de modification en déplacant graphiquement des triggers. Quelqu'un a une idée de comment gérer ce souci?

Partager ce message


Lien à poster
Partager sur d’autres sites

Tu parles de scénario, donc de scène je suppose ?
Dans ce cas, pas besoin de QuickApp (dont la logique de programmation est beaucoup plus complexe)


Ensuite, pourquoi t'embêter avec une temporisation ? Ce n'est pas du tout fiable.
Le module, tu fais la calibration du volet, et ensuite tu pourras le piloter simplement en demandant un pourcentage d'ouverture.
Par exemple sur l'un de mes volets, pour que les lames soient baissées tout en restant entrouvertes pour laisser passer la lumière, il me suffit de demander de mettre sa valeur à 25%.
Pas de tempo à gérer.

Pas de programmation LUA à faire, de scène, ou de QuickApp. Enfin si, il faut bien que le scénario soit programmé quelque part, en l’occurrence c'est dans GEA pour ma part, mais peu importe, c'est une seule ligne pour lui dire de se mettre à 0, 25, ou 99% selon la position désirée.

Partager ce message


Lien à poster
Partager sur d’autres sites

Alors dans mon cas, il s'agit de stores à lamelles. Quand on part de tout en haut pour les descendre, les lames se mettent à la verticale puis descendent. Si alors je remonte, les lames passent à l'horizontale la première seconde puis elles remontent.

Si je mets directement 25%, les lames descendront jusqu'à la position 25% mais resteront verticales. Je les voudrais horizontales, ce qui permet de bloquer le soleil direct sans pour autant bloquer la vision horizontale. Et cela ne s'obtient qu'en remontant de 1% après avoir baissé à la position souhaitée. J'ai donc besoin de faire une descente puis, une fois terminée, de remonter de 1%. En faisant une scène qui remonte de 1% et en la mettant à la fin de la liste des actions, le résultat est un store qui va directement à 1%. Ce dont j'ai besoin est un store qui va à 0% puis remonte à 1%.

Partager ce message


Lien à poster
Partager sur d’autres sites

OK, ça semble ressembler à des BSO en fait (ou store vénitien ?)

Tu as jeter un oeil au topic du module FGR ? Car il y a pas mal de discussions à ce sujet justement.

 

Cela dit, j'ai quand même l'impression que tu as donné la solution dans ton message.
Mettre le volet à 0%, puis le mettre à 1%.
Donc pas besoin de calculer finement une temporisation.
Il te suffit donc de mettre le volet à 0%, tu attends que la manoeuvre se fasse, avec une marge de sécurité (je connais pas ton store, mais disons 30s), puis tu donne la consigne à 1% et il va ouvrir les lamelles comme il faut.

 

Modifié par Lazer

Partager ce message


Lien à poster
Partager sur d’autres sites

Effectivement, l'idée est de faire 0%, attendre une minute puis 1%. Sauf que dans une scène, je n'ai pas trouvé comment lui dire d'attendre une minute avant de remonter à 1%: j'ai d'un coté des triggers qui quand ils sont vrais lancent toutes les actions en parallèle et donc je termine avec des stores à 1% sans être passés par la case 0% et donc en pratique, je ne vois jamais le paysage avec mon setup actuel.

Après, mais c'est un souci moindre, mes boutons de commande physique ont la possibilité d'être bloqués en position contact, typiquement pour descendre complètement un store sans devoir rester appuyé et quand ils sont dans la position contact fermé, ca donne des comportements bizarres. Mais je pense que je devrais trouver comment gérer la chose dans les paramètres des modules. 

Partager ce message


Lien à poster
Partager sur d’autres sites

En LUA il faut utiliser setTimeout()

Il y a plusieurs exemples d'utilisation sur le forum.

Et attention la durée donnée est en millisecondes, donc il faut indiquer 60000 si on veut une tempo d'une minute.

 

Tu peux utiliser la protection locale du module si tu veux bloquer l'action des interrupteurs.
Cela se configure dans les propriétés du module sur la box.
Si tu veux le faire programmatiquement, en LUA, par exemple pour interdire l'utilisation des bouton pendant certaines heures, tu peux le faire aussi, il faudra que tu trouves les instructions à utiliser en utilisant les outils de dév du navigateur pendant que tu paramètre le module afin d'intercepter les requêtes sur l'API.
 

Ou bien utilisez GEA, qui sait déjà faire tout ça nativement (volets, temporisation, protection locale, .... et tant d'autres)

Partager ce message


Lien à poster
Partager sur d’autres sites

Juste pour être bien sur, GEA, c'est l'interface dans laquelle on fait des scénarios avec du drag & drop, avec une colonne pour les triggers, l'autre pour les actions? Car c'est précisément là que j'ai voulu tenter la chose, mais je n'ai pas trouvé comment lui dire de lancer une action 1 minute après en avoir lancé une autre, d'où l'idée de basculer en LUA en me disant que si ce n'est pas possible avec l'interface graphique, ca doit l'être en codant. Mais si je peux le faire directement dans les scénarios (que je ne connais pas en détail), alors je serai le plus heureux!

Partager ce message


Lien à poster
Partager sur d’autres sites

Pas tout à fait... ce que tu décris, c'est l'interface de scènes en mode bloc proposé par Fibaro.
Effectivement, c'est très limité... beaucoup trop limité.

 

En LUA, tu peux tout faire, mais c'est relativement compliqué si tu ne connais ni le LUA, ni même aucun langage de programmation.

Cela dit LUA est un langage de programmation facile (surtout très lisible) par rapport à d'autres.

 

GEA c'est un moteur d'exécution de règles, qui permet d'écrire des scénarios très simples comme relativement complets (complexes ?) sans connaitre LUA :

 

Peut être pas évident à prendre en main au début, il faut se limiter à des règles très simples pour comprendre la logique, puis monter progressivement en complexité en ajoutant diverses conditions et actions.

 

Modifié par Lazer

Partager ce message


Lien à poster
Partager sur d’autres sites

La bonne nouvelle, c'est qu'on arrive à la même conclusion = les scénarios de la HC3 sont une impasse car bien trop limités en fonctionnalités: je n'avais jamais essayé jusque là car par principe, je me dis que ces trucs graphiques ne génèrent jamais ce dont on a vraiment besoin. Puis je me suis ravisé en me disant qu'après tout, les box domotiques ne sont pas utilisées que par des geeks comme moi qui savent raisonnablement coder et donc que mes problèmes basiques d'automation devraient avoir une solution native simple sur la box car sinon, 80% des gens avec une maison intelligente ne pourraient pas gérer des BSO en fonction de la luminosité. C'est là que je me suis planté. Je viens donc d'installer GEA et je vais me mettre dessus et ce d'autant que j'ai pas mal de choses qui attendaient que je les automatise mais comme je n'avais pas trouvé comment le faire dans les scènes, je me disais que ca venait du fait de mon ignorance de leur fonctionnement. Merci pour le tuyau!

Partager ce message


Lien à poster
Partager sur d’autres sites

×