Petite suggestion d’amélioration à ajouter à la liste.
J’ai trouvé via Internet un module Enocean pour commander un fil pilote (pratique quand le câblage des fils pilotes n’existe pas dans l’installation électrique pour certains radiateurs).
Ce serait top si l’extension X-ENO pouvait le gérer (celle-ci a bien été étendue de la réception des interrupteurs à la commande de prise et la récupération d’infos T°, humidité… ).
Un widget fil pilote existant déjà pour l’extension X-FP, il existe donc déjà les éléments d’interface pour l’IPX. Il s’agirait donc d’étendre la gestion des fils pilotes à des modules pilotés par la X-ENO.
@gce, est-ce que c’est quelque chose que vous avez déjà prévu ou qui pourrait être fait à un horizon pas trop lointain ?
Il y a, en attendant, la possibilité de piloter des modules Ubiwizz avec un module diodes pour reproduire les 4 ordres de bases mais elle n’est ni aussi élégante, ni aussi efficace (pas de confort -1° ou -2°) que de piloter directement un module ad-hoc. Et c’est un investissement important et peu utile si ce module doit être interfacé bientôt (j’ai potentiellement 6 radiateurs à piloter et n’aurai pas l’usage de 6 modules Ubiwizz récupérés…).
Je ne sais pas si cela à déjà été proposé, mais il serait pas mal que les boutons « retour », « sauvegarder », etc… restent visibles dans les différentes fenêtres de configuration comme celles des entrées virtuelles, des scènes, etc…
Surtout qu’on ne peut pas aller directement en bas de page.
‹ ‹ Ce qui serait à priori relativement simple serait d’activer/désactiver un ou plusieurs scénario en résultat › ›
Cette option serait super dans tous les cas : actuellement, pour avoir le même résultat, il faut utiliser une VI et une copie d’un scénario existant en ajoutant la VI en données d’entrée.
Cela consomme des VI et des scénarios, et plus embêtant, en cas de modifications, il faut repasser sur tous les scénarios (et surtout ne pas en oublié…)
Je note, nous verrons si c’est intégrable sur la prochaine version.
Pour les modules FP Enocean, la question qui va et qui doit se poser reste où nous arrêtons nous ? Les modules Enocean sont extrêmement nombreux divers et varié. Nous ne pourrons pas tout intégrer et les ressources de la V4 sont déjà bien entamé par tout cela. Nous étudions les module VR actuellement, la possibilité de module de comptage pluri-canaux également. Je soumettrai l’hypothèse pour les FP.
Désolé pour la réponse tardive. Oui cela suffirai, en utilisant un scénario libre comme « zone tampon » afin de ne pas perdre les données du scénario qui sera écrasé.
Si on pouvait profiter du copier/coller d’un scénario pour l’exposer sous forme de texte on ferait d’une pierre 2 coups :
modifier simplement l’ordre des scénarios
sauvegarder/documenter/versionner nos règles de manière simple et rapide : en apportant du support à un utilisateur je me suis encore fait piéger par un écart entre mes notes et le contenu de mon IPX (je suis particulièrement mauvais dans les tâches répétitives )
L’activation/désactivation d’un scénario me semble déjà possible à travers une variable d’output virtuelle. De manière très concrète j’ai 2 conditions trop complexes pour être combinées par un « ou » qui doivent conduire au même traitement. Plutôt que de recopier le traitement sous chaque condition, j’active une variable virtuelle dont le changement d’état va déclencher le traitement. Une sous routine en quelque sorte.
Par soucis pratique, je me dis que ce serais bien de pouvoir déplacer les widgets d’un dashboard à l’autre plutôt que de devoir les reconstruire (notamment si l’on approche de la limite de capacité d’un dashboard et en plus ça limiterai le tique d’erreur )
Idée : une simple variable au niveau du widget spécifiant sur quel(s) dashboard(s) le widget doit s’afficher
Qu’en pensez vous ? (@Maxime_gce)
Pour le coup je ne m’occupe que très rarement des interfaces en elles mêmes mais à priori le fonctionnement de base du système (en terme de dashboard et de widget) ne permet pas de telles manipulations. Ce serait en tout cas extrêmement complexe. Pour info, sur l’EDRT le principe se dirigera vers ce genre de chose. Le problème est que sur la V4 les widget sont trop nombreux et personnalisable pour qu’une telle architecture soit viable en terme de ressource.
Je poserai le problème lors de la prochaine MAJ de V4 mais il me semble que nous avons déjà étudié la chose et que le développement serait assez conséquent Tout sera donc une question de temps vis-à-vis des autres évolutions prévues
Les MAJ de V4 sont pour le moment assez minimaliste en ce qui concerne l’interface donc pas de changement majeur de ce genre pour le moment. Je sais cependant que mon collègue travaille dessus mais ce n’est pas si simple que ça. Les dashboard étant totalement indépendant les uns des autres pour le moment.
@GCE
Je suis en train de faire un peu de rangement dans mes scénarios V4 et je m’aperçois qu’il n’y a pas de confirmation de suppression lorsqu’on clic sur « EFFACER ».
Peut être à ajouter lors d’une future mise à jour, cela pourrai éviter certains désagréments.
@GCE
Egalement lorsqu’on sélectionne une tuile « VOLET ROULANT » dans les scénarios, il faut sélectionner « Volet 1, Volet 2, Volet 3, Volet 4 ».
Serait il possible de pouvoir les renommer comme pour les Relais?
@GCE
Serait il possible d’augmenter le temps des TA et des TB?
Ne serait que pour avoir des valeurs d’1 heure.
Je pense pas être le seul à avoir parfois besoin de lancer certaines choses pendant un laps de temps supérieur à 13743 secondes (ou 13743 dixième de secondes puisque cette valeur n’est pas augmenter en étant en dixième de seconde)
Créer un minuteur avec compteur et SV est assez lourd à mettre en place pour chaque scénario que l’ont souhaite limiter à un laps de temps donné.
Est il possible d’augmenter ces valeurs? Ou tout simplement prendre en compte la division seconde/ dixième de secondes afin d’avoir une valeur de 137430 dixièmes de secondes.
La valeur des Ta/Tb étant stockée sur 2 octets, elle pourrait aller jusqu’à 216 - 1 = 65 535.
La limite imposée à 13 743 est due à une limitation au niveau hardware comme l’explique Maxime.
EDIT : d’après ce que je comprends, il serait possible d’aller jusqu’à 13 743 secondes (~ 3,8 heures) ou 65 535 dixièmes de secondes (~ 1.8 heures). Mais, pour l’instant, on est limité à 13 743 dixièmes de secondes (~ 0.4 heure).
Bonjour, qu’en est il des différentes proposition évoquées? Ont elles été prise en compte? Réalisable?
Quelles sont les futurs améliorations en vue pour la V4?
Merci
).
)
(
Tout sera donc une question de temps vis-à-vis des autres évolutions prévues 
