Page : index.php?v=d&m=mySensors&p=mySensors
Jeedom_version : 4.0.24
Uname : Linux pidom.trychlos.lan 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
Message :
Bonjour,
Soit un équipement (MySensors) qui supporte 35 commandes.
Pour mon confort et me permettre de m’y retrouver plus facilement, j’ordonne ces commandes en fonction du child_id dans l’onglet Commandes de l’équipement.
Toutefois ces commandes ne sont pas toutes visibles, car certaines ne sont affichées que via un équipement virtuel (ici, les commandes de configuration de l’équipement).
Problème, lorsque je modifie dans le dashboard la taille d’une tuile ou l’ordre des tuiles, les commandes visibles sont réordonnées.
En conséquence, lorsque je reviens dans l’onglet Commandes de l’équipement, l’ordre a changé alors que je ne l’ai pas modifié.
Bug n° 1 : les commandes sont réoordonnées à l’insu de mon plein gré
Bug n° 2 : dans l’onglet Commandes de l’équipement, l’ordre est compté à partir de zéro. Lorsque le dashboard est réécrit, l’ordre est compté à partir de 1 (pas grave, mais non consistant).
Bug n° 3 : lorsque le dashboard « réécrit » les commandes dans l’ordre qu’il constate, il ne peut traiter que les commandes visibles. En conséquence, on se retrouve avec des doublons dans l’ordre des commandes.
Ex: pour un senseur Teleinfo :
1/ après avoir réordonné les commandes dans l’onglet Commandes de l’équipement :
MariaDB [jeedom]> select a.name,a.id,b.name,b.id,b.order from eqLogic a,cmd b where a.name=‹ mysTeleinfo › and a.id=b.eqLogic_id order by b.order;
±------------±—±----------------------±-----±------+
| name | id | name | id | order |
±------------±—±----------------------±-----±------+
| mysTeleinfo | 50 | EepromReset | 678 | 0 |
| mysTeleinfo | 50 | DumpData | 748 | 1 |
| mysTeleinfo | 50 | MaxFrequencySet | 749 | 2 |
| mysTeleinfo | 50 | MaxFrequencySetSlider | 2565 | 3 |
| mysTeleinfo | 50 | MaxFrequency | 1081 | 4 |
| mysTeleinfo | 50 | UnchangedSet | 768 | 5 |
| mysTeleinfo | 50 | UnchangedSetSlider | 2566 | 6 |
| mysTeleinfo | 50 | Unchanged | 1082 | 7 |
| mysTeleinfo | 50 | DuplicateEnable | 769 | 8 |
| mysTeleinfo | 50 | DuplicateDisable | 770 | 9 |
| mysTeleinfo | 50 | TempDuplicate | 1083 | 10 |
| mysTeleinfo | 50 | Thread | 1084 | 11 |
| mysTeleinfo | 50 | AutoDumpSet | 1078 | 12 |
| mysTeleinfo | 50 | AutodumpSetSlider | 2567 | 13 |
| mysTeleinfo | 50 | AutoDump | 1085 | 14 |
| mysTeleinfo | 50 | DupPeriodSet | 2551 | 15 |
| mysTeleinfo | 50 | DupPeriodSetSlider | 2568 | 16 |
| mysTeleinfo | 50 | DupPeriod | 2552 | 17 |
| mysTeleinfo | 50 | ADSC | 2534 | 18 |
| mysTeleinfo | 50 | DATE | 2535 | 19 |
| mysTeleinfo | 50 | NGTF | 2536 | 20 |
| mysTeleinfo | 50 | LTARF | 2538 | 21 |
| mysTeleinfo | 50 | EASF01 | 2537 | 22 |
| mysTeleinfo | 50 | EASF02 | 2539 | 23 |
| mysTeleinfo | 50 | IRMS1 | 2540 | 24 |
| mysTeleinfo | 50 | URMS1 | 2541 | 25 |
| mysTeleinfo | 50 | PREF | 2542 | 26 |
| mysTeleinfo | 50 | SINSTS | 2544 | 27 |
| mysTeleinfo | 50 | SMAXSN | 2543 | 28 |
| mysTeleinfo | 50 | SMAXSN-1 | 2545 | 29 |
| mysTeleinfo | 50 | CCASN | 2546 | 30 |
| mysTeleinfo | 50 | CCASN-1 | 2547 | 31 |
| mysTeleinfo | 50 | PRM | 2549 | 32 |
| mysTeleinfo | 50 | NTARF | 2548 | 33 |
| mysTeleinfo | 50 | HCHP | 2550 | 34 |
±------------±—±----------------------±-----±------+
35 rows in set (0.01 sec)
2/ après avoir réécrit le dashboard (passage en modification, puis fin de modification sans avoir rien modifié) :
MariaDB [jeedom]> select a.name,a.id,b.name,b.id,b.isVisible,b.order from eqLogic a,cmd b where a.name=‹ mysTeleinfo › and a.id=b.eqLogic_id order by b.order;
±------------±—±----------------------±-----±----------±------+
| name | id | name | id | isVisible | order |
±------------±—±----------------------±-----±----------±------+
| mysTeleinfo | 50 | EepromReset | 678 | 1 | 1 |
| mysTeleinfo | 50 | MaxFrequencySet | 749 | 0 | 2 |
| mysTeleinfo | 50 | DumpData | 748 | 1 | 2 |
| mysTeleinfo | 50 | DuplicateEnable | 769 | 1 | 3 |
| mysTeleinfo | 50 | MaxFrequencySetSlider | 2565 | 0 | 3 |
| mysTeleinfo | 50 | MaxFrequency | 1081 | 0 | 4 |
| mysTeleinfo | 50 | DuplicateDisable | 770 | 1 | 4 |
| mysTeleinfo | 50 | TempDuplicate | 1083 | 1 | 5 |
| mysTeleinfo | 50 | UnchangedSet | 768 | 0 | 5 |
| mysTeleinfo | 50 | ADSC | 2534 | 1 | 6 |
| mysTeleinfo | 50 | UnchangedSetSlider | 2566 | 0 | 6 |
| mysTeleinfo | 50 | Unchanged | 1082 | 0 | 7 |
| mysTeleinfo | 50 | DATE | 2535 | 1 | 7 |
| mysTeleinfo | 50 | NGTF | 2536 | 1 | 8 |
| mysTeleinfo | 50 | LTARF | 2538 | 1 | 9 |
| mysTeleinfo | 50 | EASF01 | 2537 | 1 | 10 |
| mysTeleinfo | 50 | Thread | 1084 | 0 | 11 |
| mysTeleinfo | 50 | EASF02 | 2539 | 1 | 11 |
| mysTeleinfo | 50 | AutoDumpSet | 1078 | 0 | 12 |
| mysTeleinfo | 50 | IRMS1 | 2540 | 1 | 12 |
| mysTeleinfo | 50 | AutodumpSetSlider | 2567 | 0 | 13 |
| mysTeleinfo | 50 | URMS1 | 2541 | 1 | 13 |
| mysTeleinfo | 50 | AutoDump | 1085 | 0 | 14 |
| mysTeleinfo | 50 | PREF | 2542 | 1 | 14 |
| mysTeleinfo | 50 | DupPeriodSet | 2551 | 0 | 15 |
| mysTeleinfo | 50 | SINSTS | 2544 | 1 | 15 |
| mysTeleinfo | 50 | DupPeriodSetSlider | 2568 | 0 | 16 |
| mysTeleinfo | 50 | PRM | 2549 | 1 | 16 |
| mysTeleinfo | 50 | DupPeriod | 2552 | 0 | 17 |
| mysTeleinfo | 50 | NTARF | 2548 | 1 | 17 |
| mysTeleinfo | 50 | HCHP | 2550 | 1 | 18 |
| mysTeleinfo | 50 | SMAXSN | 2543 | 0 | 28 |
| mysTeleinfo | 50 | SMAXSN-1 | 2545 | 0 | 29 |
| mysTeleinfo | 50 | CCASN | 2546 | 0 | 30 |
| mysTeleinfo | 50 | CCASN-1 | 2547 | 0 | 31 |
±------------±—±----------------------±-----±----------±------+
35 rows in set (0.01 sec)
On constate les trois bugs décrits.
Suggestion : ajouter un flag dans l’équipement pour permettre/interdire la modification de l’ordre des commandes depuis le dashboard.
Merci de votre attention.
Cordialement,
Barbap’s
.
Bonjour,
Malheureusement nous ne pourront faire cette demande. On note en revanche qu’il faudrait qu’on améliore cette partie.
OK, c’est que j’appelle une litote.
Là encore, est-ce une question de principe, ou bien un patch pourrait-il être considéré ?
Non là le patch est trop compliqué a faire et demanderai trop de temps en comparaison de l’apport et de la demande. Par contre comme dit je note que ya une personne qui a une demande la dessus et voir si on peut répondre a ton besoin par une autre manière que celle proposée
Une option pour contourner le problème pourrait être de créer un virtuel dédié à l’affichage des commandes (super rapide avec la fonction dupliquer) => comme cela on réordonne le virtuel et ça ne touche pas à l’équipement.
Pour ma part, j’ai tout construit comme cela : des équipements avec différents protocoles qui servent d’entrées/sorties et sont sur des objets à part, et ensuite que des virtuels pour les pages à afficher dans le dashboard. Cela simplifie aussi la gestion des droits quand il y a plusieurs utilisateurs. Après, je crois que ce n’est pas forcément la méthode conseillée par l’équipe Jeedom, j’imagine que ça augment un peu les ressources nécessaires.
Oui effectivement on ne recommande pas ça augmente fortement la charge sur jeedom
Je fais ca aussi depuis le début de Jeedom, chaque module physique ou plugin est copié dans un virtuel et c’est ce virtuel que j’utilise dans les scénarios et l’affichage, c’est pratique en cas de changement de plugin ou de matériels, même si maintenant il y a des fonctions de copies ou de remplacement qui sont apparues mais je veux pas refaire toute ma configuration
Mais c’est pas nouveau du tout !
Ça fait au moins 2 ans que c’est possible de remplacer une commande partout dans Jeedom…
Il faut pas venir se plaindre des performances après…
Je n’ai pas parlé de nouveauté, ca fait plusieurs années que mon architecture est comme ca, et je me suis jamais plaint de problème de performance…
D’ailleurs par curiosité intellectuelle, en quoi le fait d’avoir une ou plusieurs commandes qui sont liés a une autre ralentie le système, c’est gourmande en ressource quand la commande mère se met a jour de devoir mettre a jour ses filles ?
Et c’est gourmande en quoi ? Ressource du système, sgbd ?
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.