Page : index.php?v=d&m=mode&p=mode&id=865
Jeedom_version : 4.0.61
Uname : Linux jeedom 3.14.79-94 #1 SMP PREEMPT Mon Nov 21 17:13:27 BRST 2016 aarch64 GNU/Linux
Message :
Bonjour,
Serait-il possible d’avoir une commande « mode suivant » afin de pouvoir gérer un changement de mode via un simple bouton poussoir (à chaque appui sur le bouton, je fais défiler les modes)
Cordialement…
Salut.
En attendant tu peux tout à faire ça avec un scénario
Et comment le plug-in saurait quel est le mode suivant ?
Ordre alphabetique ?
Ça me paraît un peu « foireux » comme action; ça lancerait a chaque fois toutes les actions d’entrée et de sortie de chaque mode; ou j’ai mal compris
3 « J'aime »
Oui ordre alphabétique par exemple, ou encore mieux, que l’on puisse choisir l’ordre.
EN fait j’utilise le plugin mode pour gérer les scènes de lumière des pièces via un simple BP, à chaque appui, changement de mode.
Si j’ai 5 ou 6 ambiances, le création du scénario est fastidieuse…
J’utilise le « mode précédent », mais ca ne marche que quand tu as 2 valeurs. Et ça plante quand jeedom redémarre par exemple, donc un « mode suivant » serait carrément le bienvenu.
Mouais, ça plantera pareil… Le mode suivant ou précédent de ‹ rien › (quand le cache est vide), c’est toujours ‹ rien ›
Un scénario, un tag avec une valeur ‹ next/prev › et on fait tout ce qu’on veux, dans l’ordre qu’on veut et avec des conditions vérifiables.
Un bête virtuel, avec 2 boutons qui appellent le scénario et zou, la partie graphique est là
j’ai 29 virtuels. je viens de faire un scénarion sur le #start#, histoire de remettre tout ça clean sur un redémarrage.
29 modes ? et 29 dont il faut définir une séquence ordonnée ?
j’utilise surtout « mode précédent » pour switcher entre 2 états. J’ai quelques modes avec plusieurs états, mais j’ai contourné en créant des virtuels etc pour mes design.
Mais si on part sur une action disponible « Etat suivant », il faudrait en effet pouvoir mettre dans l’ordre ces états dans le plugin (par glisser comme pour les commandes ou virtuels).
Et potentiellement avoir une case à cocher pour un état par défaut en cas de redémarrage.
Mes modes activent ou désactivent surtout tout mes automatismes dans ma domotique
Dans le cas d’un mode à 2 ‹ états ›, avoir des fonctions précédent/suivant, ça n’apporte rien. Suivant/précédent de l’un c’est toujours l’autre…
Je me pose même la question de l’intérêt du mode dans ce cas car ça peut être vite lourd. Par exemple, si c’est pour faire 1 action pour chaque action d’un mode, autant faire uniquement le Virtuel de type toggle… Mais bon c’est pas le sujet ici
J’ai fait un exemple ultra rapide (revu suite à idée de @mips)
ça fait le job
------------------------------------
[2020-08-26 18:26:19][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:26:19][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:26:19][SCENARIO] Lancement du scénario : NextPrev options : {"#Sens#":"Suivant"}
[2020-08-26 18:26:19][SCENARIO] Log : 2
[2020-08-26 18:26:19][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-08-26 18:26:24][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:26:24][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:26:24][SCENARIO] Lancement du scénario : NextPrev options : {"#Sens#":"Suivant"}
[2020-08-26 18:26:24][SCENARIO] Log : 3
[2020-08-26 18:26:24][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-08-26 18:26:26][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:26:26][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:26:26][SCENARIO] Lancement du scénario : NextPrev options : {"#Sens#":"Suivant"}
[2020-08-26 18:26:26][SCENARIO] Log : 1
[2020-08-26 18:26:26][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-08-26 18:26:27][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:26:27][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:26:27][SCENARIO] Lancement du scénario : NextPrev options : {"#Sens#":"Suivant"}
[2020-08-26 18:26:27][SCENARIO] Log : 2
[2020-08-26 18:26:27][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-08-26 18:26:30][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:26:30][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:26:30][SCENARIO] Lancement du scénario : NextPrev options : {"#Sens#":"Suivant"}
[2020-08-26 18:26:30][SCENARIO] Log : 3
[2020-08-26 18:26:30][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-08-26 18:26:34][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:26:34][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:26:34][SCENARIO] Lancement du scénario : NextPrev options : {"#Sens#":"Precedent"}
[2020-08-26 18:26:34][SCENARIO] Log : 2
[2020-08-26 18:26:34][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-08-26 18:39:41][SCENARIO] Start : Scenario lance manuellement.
[2020-08-26 18:39:41][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-08-26 18:39:41][SCENARIO] Lancement du scénario : NextPrev options : []
[2020-08-26 18:39:41][SCENARIO] Log : 1
[2020-08-26 18:39:41][SCENARIO] Fin correcte du scénario
T’es pas obligé de toujours les imbriquer non plus 
- soit tu les enchaines (sans les imbriquer, sans le SINON) et dans ce cas ci, si une condition est vrai les autres seront fausses: on va me dire qu’on « perd » plein de temps à faire des évaluations qui servent à rien… négligeable vraiment et on gagne tellement en lisibilité (en bloc SWITCH serait pratique dans les scénarios, un jour je m’y pencherai )
- soit, même solution que la première mais tu rajoutes un
stopà la fin du bloc => les tests suivants ne seront plus évalués et on « gagne » plein de temps
mais on ne peut faire cela que s’il n’y a pas d’autres actions à faire ensuite dans le scénario évidement.
Bref, perso, je n’imbrique plus mes SI dans les scénarios pour gagner en lisibilité (si la logique du scénario le permet)
Tu as raison, il y a pleins d’optimisations possibles. J’ai pondu ça rapidement
Oui, c’est souvent ce que je fais aussi. Par contre dans ce cas là il faut aussi rendre plus ‹ exclusive › la condition du SI… Sinon ça les enchaîne à les uns à la suite des autres : Suivant, tu passes à 1, qui valide la condition ==2 etc… Il y a pas de truc pratique là… Ou alors les mettre dans l’ordre inverse de la séquence pê…
A titre perso j’aime pas plus les switch (ça limite à 1 opération sur le case)… un elseif c’est plus polyvalent je trouve
Et ça existe en plus … J’vais me coucher moins con ce soir. 
A y réfléchir pour un besoin perso je pense que dans ce cas, je ferai ça avec un bloc code (surtout avec des modes ‹ numériques ›)
EDIT : scenario edité, avec les stops … Là c’est propre
Le problème vient surtout de la non initialisation des modes au démarrage jeedom.
« précédent » fonctionne si tu as au préalable setté ton mode sur les 2 &tats.
« suivant » fonctionnerait sans initialisation, ou à minima avec 1 seul état setté au démarrage.
Les modes sont la pierre angulaire de mon système domotique.
Il faut au moins une initialisation : suivant, c’est l’autre mais il faut fixer le point de départ
Je l’utilise aussi pas mal, mais pas pour autant de modes… Et je me passe complètement du mode précédent… Mais j’avoue que j’ai du mal à voir pourquoi autant chez toi et donc à ne pas mesurer l’impact…
mes modes gèrent principalement l’activation ou la désactivation d’automatismes :
- activation / désactivation de la gestion automatique d’un purificateur d’air,
- activation / désactivation de la gestion automatique d’un deshumidificateur d’air,
- activation / désactivation de la gestion automatique de différents éclairages,
- activation / désactivation de la gestion automatique de différentes alertes (ouvertures, éclairages, qualité de l’air, temps de trajets
- activation / désactivation de la prise en compte de différents devices dans la gestion de la présence automatique
- activation / désactivation de la gestion automatique de la présence (activant plein de chose comme l’alarme automatique)
- activation / désactivation de la gestion automatique / manuelle / intelligente du chauffage
- activation / désactivation de la gestion de l’arrosage automatique
- etc etc
J’ai une 50 aine de scénarios et les modes permettent de gérer leur déroulement ou non .
de plus, les modes permettent de réaliser des actions en entrée, sortie de mode. J’utilise cette fonction dans mon mode de présence (absent/nuit/présent). Ceci me permettant par exemple de désactiver des scénarios quand ils sont inutiles pour alléger la charge (exemple : mise à jour permanente des prochains horaires de bus n’est nécessaire que quand on est Présent car je les visualise sur ma tablette)
Ok, ça je vois bien le pourquoi
Par contre, si ça se limite à faire un On/Off ou activer/Désactiver un objet… ça me semble vachement coûteux : l’objet mode, le virtuel qui va avec etc… D’autant plus si tu n’exploites pas la valeur du mode. Dans ce cas, là moi je passerai plus par un scénario ou des groupes de scénario à activer/désactiver
L’important c’est que ça fonctionne mais si tu es obligé de bricoler des rustines pour initialiser le démarrage …
j’utilise directement la valeur des modes dans mes scénarios.
j’ai eu besoin de créer des virtuels pour chaque mode uniquement pour des besoins ultérieurs, pour gérer mon design. avant je n’en avais pas besoin.
Avec le recul, oui j’aurais mieux fait de passer par des virtuels directement, pour les mode à 2 états.
Là j’ai trop de criticité à changer, donc je reste comme ça.
Vos solutions sont en effet fonctionnelles, mais étant installateur, si on doit faire çà pour chaque installations, c’est du temps … Alors qu’avec un mode suivant on gagnerait beaucoup de temps