Bonjour à tous, cela fait environ 2 ans que je suis sur jeedom, je commence à avoir pas mal de scénario en tout genre.
Par contre je me rend compte que dans pas mal de vos scénarios vous vous servez de variable, par contre moi j’en ai aucune.
À quoi me servirais de mettre des variables et comment m’y prendre pour que ce soit intéressant dans mes scénarios ?
Merci pour votre aide
Cordialement
Bonsoir,
(41) Variables Jeedom - Je vous dit tout - YouTube
La vidéo est bien faite et mon exemple en dessous d’une alerte lorsque ma machine à laver est terminée :
Bonsoir,
Le gros avantage des variables c’est que celle-ci perdurent, même après l’exécution d’un scénario, et peut donc resservir à d’autres scénarios. C’est donc un peu comme les tags, mais c’est plus simple en passant par une variable si ça intéresse plusieurs scénarios. Elles peuvent également servir pour stocker des constantes.
Quelques exemples : stockage des tarifs HC/HP EDF, des seuils de luminosité ambiantes (pour gérer l’éclairage), des seuils de puissance des luminaires, de l’heure de passage du facteur, des températures de consignes, du cumul de la production solaire, flags de programmation, etc…
Perso, j’en gère au moins une centaine dans mes 80 scénarios…
Salut,
D’après ce que j’avais compris d’un post de Loic, il vaut mieux utiliser un virtuel avec des commandes infos quand les valeurs changent souvent.
Du coup j’utilise peu de variable, plutôt en constantes (comme dit dans un post plus haut)
J’en utilise 3 (Eco Confort Confort+ qui ont des valeurs pour le chauffage)
Sinon j’ai créé un virtuel ‹ Variables › avec des commandes infos
Idem, pas de variables, que des virtuels.
Et puis il ne me semble pas que l’on puisse historiser une variable.
Je pense que dans mon cas le plus intéressant serait de s’en servir pour gerer les presences, car par moment il m’arrive d’avoir des loupés.
3 presences à gérer (meme si on est 4 a la maison lol) avec parfois des departs et des arrivées a heures différentes de la maison, donc il y a des moments ou il y a des couacs surtout le soir avec la gestion des l’allumage extérieure !
Je vais essayé de plancher dessus ppur voir si ca pourrait m’aider dans mes scénarios
Bonjour,
Et c’est très bien, moi non plus! (Une exception car pas le choix: le cas des ask)
Si vos scénarios tournent sans ça n’est pas une bonne idée de volontairement en introduire, vous n’allez rien y gagner (au contraire)
Bonjour,
Oui, c’est pas faux.
En fait il y a plusieurs solutions possibles, toutes étant équivalentes, en fonction des habitudes des uns et des autres. Ne maîtrisant pas les virtuels au début, je me servais exclusivement des variables dans mes premiers scénarios et ça marchait très bien. Aujourd’hui, je me sert aussi bien des variables que des virtuels, qui offrent en plus la possibilité de prendre une valeur en fonction d’un calcul simple (a+b) ou complexe, ou de tests (si a>b?1:0), plus l’historisation si besoin en effet.
N’oublions pas non plus que l’utilisation des virtuels est lié à l’installation d’un plugin qui, bien que développé par l’équipe de Jeedom SAS, n’est (curieusement) toujours pas intégré au noyau Jeedom ! Sans doute il y a-t-il une bonne raison pour cela, et ça viendra peut-être tant ce plugin est devenu indispensable et pratique…
En tout cas, dixit la doc: ’ Il ne faut pas abuser des virtuels car ils entrainent une surconsommation générale (cpu/mémoire/swap/disque), des temps de latence plus longs, une usure de la carte SD, etc… Il ne faut donc EN AUCUN CAS dupliquer (tous) les équipements en virtuel sans absolue nécessité ! Les virtuels sont des outils à utiliser avec parcimonie uniquement lorsque cela s’avère nécessaire.'. (
euh… aïe…c’est exactement ce que j’ai fait : 1 équipement réel = 1 virtuel systématique…).
Pour les variables, je ne sais pas s’il y a les mêmes restrictions.
Ceci dit, je n’ai pas constaté d’impact vraiment flagrant sur mon système vis à vis d’une 'utilisation (débridée ?) des uns et/ou des autres…
justement pas, c’est là le point 
variable = accès DB obligatoire, la db est (toujours) le point le plus lent et le plus critique dans une application
rien ne curieux, au contraire, et des plugins jeedom il y en a des centaines…
le core ne s’occupe jamais de gérer les équipements, ce sont toujours les plugins.
donc non ca ne sera jamais le cas.
ca c’est vrai, il ne faut pas en abuser donc dupliquer tous ses équipements avec des virtuels n’est pas une bonne pratique.
c’est fort probable, de manière isolée ca n’apporte aucun problème;
c’est un tout, un équilibre, et cela dépend aussi de la machine sur laquelle tourne jeedom
Merci pour ces éclaircissements.
Pour ce point particulier cité ci-dessus, la gestion des virtuels n’est donc pas (et ne sera jamais) considéré comme faisant partie des fonctions inhérentes au core ? Autant je le conçois très bien pour des plugins comme JeeZigbee, Thermostat, Infos du jour ou d’autres, autant pour les virtuels qui ne sont rattachés à aucun équipement en particulier et qui apporte un vrai plus pour l’ensemble du système (quel qu’il soit), j’ai un peu plus de mal. Je prendrai juste pour exemple récent l’intégration du plugin Widget depuis la v4.
Bon, c’est un point de vue purement philosophique et ça me va très bien tel quel, tant que ce plugin reste disponible et continue d’évoluer avec les versions du core jeedom .
non elle n’est pas.
et non dans la logique de jeedom, je pense que cela ne sera jamais intégré au core
mais soyons clair: je ne fait absolument pas partie de l’équipe, je ne décide pas de ce qu’on met dans jeedom ou pas
ceci dit, c’est un débat inutile, ca ne change absolument rien à l’utilisation que ca soit intégré ou pas, ca ne sera pas plus efficace au contraire;
En dev le mieux est quand même de bien définir les roles et responsabilités de chaque composants et que chacun fassent son boulot.
je l’attendais cet exemple et justement c’est un parfait contre exemple 
: c’est bien le role du core de gérer l’affichage du dashboard, des tuiles et des widgets des commandes
c’est donc cohérent comme choix que d’intégrer la gestion des widgets custom au core
Hello,
J’utilise beaucoup les variables et je vais te donner un exemple. On peu évidemment faire la même choses avec des virtuelles (pour stocker une valeur) mais ça nécessite de créer autant de virtuelles que d’informations contenant une variables. Non seulement ça te fait perdre du temps mais en plus, la Doc indique clairement que les virtuelles sont à utiliser avec parcimonie. Pour ma part, les variables sont essentielles dans de nombreux scénarios, je doit en avoir pas loin d’une trentaine, alors je te laisse imaginer si j’avais utilisé les virtuelles.
J’avais un besoin (ou plutôt une recommandation de ma femme 
) qui était d’envoyer le robot aspirer l’entrée et la buanderie 5 minutes après que je sois rentré du boulot. Les 5 minutes me permettent d’avoir le temps de me déchausser, de me laver les mains et de ranger d’éventuelles affaires qui traînent à l’entrée sans avoir le robot dans les pattes.
Mes horaires sont fixes, mais mon heure d’arrivée à la maison est variable. Je peux quitter plus tard, faire des courses ou aller à un rendez-vous avant de rentrer. Pour que l’automatisation ne s’exécute que lorsque je rentre du boulot et non pas à chaque fois que je rentre à la maison, il m’a fallu informer le système que je rentre du travail et pas seulement que suis « présence à la maison ».
Ainsi, dans mon scénario de programmation quotidienne qui programme diverses tâches à 3h00 du matin pour anticiper la journée, dont la programmation automatique des réveils en fonction des jours ou non jours de travail, ça définit une variable travail à « 1 » si c’est un jour de travail.
Dans le scénario qui détecte mon absence, ça vérifie la variable « travail ». Si la variable « travail » est égale à 1, alors dans 15 minutes, ça passe la variable « nettoyage » à 1 (signifie que je me suis absenté pour aller travailler), j’utilise une temporisation de 15 minutes afin de ne pas démarrer le robot aspirateur si j’oublie quelque chose qui me ferait revenir à la maison avant de partir au travail.
Ensuite, lorsque je suis détecté présent à la maison en rentrant du travail, le scénario vérifie la variable « nettoyage ». Si la variable « nettoyage » est égale à 1 (signifie que je rentre du travail), alors le robot aspirateur nettoie l’entrée et la buanderie dans 5 minutes. Ensuite, la variable « nettoyage » est remise à 0. Ainsi, je peux sortir de la maison après le travail, et en rentrant, le robot ne se lancera pas, car il s’est déjà lancé, la variable « nettoyage » étant à 0, le système sait que je ne rentre pas du travail mais que je rentre simplement.
Tout d’abord évidement chacun fait comme il veut et le principal c’est que chacun trouve SA solution qui lui convient et qu’il maitrise.
Mais oui il y a moyen de faire sans variable (et sans virtuel) et oui en théorie ca serait mieux (je répète, une variable = un accès DB obligatoire)
quelques précisions / corrections car je pense qu’il y a une mécompréhension:
ceci n’est pas vmt correct, à la limite il faut des commandes infos différentes mais certainement pas des équipements différents.
concernant l’usage des virtuels, le problème n’est pas d’en avoir des centaines.
le problème c’est d’avoir des centaines de virtuels qui seraient mis à jour par des commandes d’autres équipements (réels) => problème si on duplique tous ses équipements par des virtuels car lors de la mise à jours des infos d’un équipement, ca doit mettre à jour en cascade les équipements virtuels et cela potentiellement récursivement.
concernant ton exemple, quelques idées de solutions alternatives sans utiliser de variable ni de virtuel:
)C’est vrai, je ne l’ai pas vu sous cet angle. On peut regrouper nos différentes infos variables dans un virtuel et changer leur état en scénario avec des « évents » plutôt que de basculer par des commandes action « On/Off », mais il faut quand même créée des commandes l’info pour chaque variables.
Pour les alternatives concernant mon exemple, j’ai volontairement donné l’exemple le plus simple pour une meilleure compréhension d’utilisation, il y a évidemment plusieurs façons de gérer cette info variable. Cependant, ce ne sera pas toujours le cas dans certains contextes/scénarios, surtout si la variable conditionne plusieurs scénarios, une variable (ou un virtuel) sera nécessaire. Pour moi, la variable représente la simplicité; pas besoin de créer une commande info supplémentaire si l’historisation n’est pas nécessaire.
En ce qui concerne la consommation de ressources (ou db) des variables versus virtuel, je n’ai aucune notion là-dedans. Mais personnellement, avec une trentaine de variables, une quarantaine de plugins, plus d’une centaine de dévices Zigbee, une quinzaine en BT, une centaine de scénarios, dont certains assez complexes qui sont très souvent sollicités plusieurs fois par minutes, des équipements qui me remontent des infos chaques secondes (la fréquence cardiaque de nos montres par exemple, un capteur de lux au dessus d’un gradient ambilight) etc … je ne rencontre aucuns soucis de performance et de stabilité.
Concernant mon exemple, tester la date et si le robot a déjà aspiré (il y a x heures) ne fonctionnera pas, car ma femme peut très bien le lancer avant et même pendant que je rentre (d’ailleurs je teste d’abord son état avant de le lancer, et si l’entrée et la buanderie n’ont pas étaient aspirer, alors une fois le robot à sa base (en charge) il ira aspirer).
Pour l’alternative qui active/désactive le scénario, c’est justement ce que je faisais à mes début sur Jeedom avant de remplacer par la variable, car je ne suis pas fan des automatisations à base d’activation/désactivation, cela peut s’apparenter à du chipotage, mais c’est mon côté puriste des automatisations. Je suis capable de modifier une automatisation pleinement fonctionnelle juste pour la rendre plus « propre » à mes yeux et tout centraliser en un seul scénario par exemple, même si je doit m’en arracher les cheveux …
En bref, variable ou virtuelle, c’est avant tout une question feeling
Je suis d’accord sur le question de feeling. J’ai bien compris en lisant toute les réponses que toute les méthodes sont bonnes ou mauvaises suivant comment on voit le verre à moitie plein.
Mais en tout cas ton exemple avec le robot et surout le fait de rentrer du travail ou pas est l’exemple le plus clair que j’ai pu voir et qui pourrait surtout me convenir le plus.
Comme je l’avais dit j’ai des scénarios qui mériterait peut être d’avoir une variable pour éviter des ‹ bugs › de fonctionnement !
Un exemple : quand je rentre le soir et qu’il fait déjà noir, après l’ouverture de mon portail jeedom allume les lumières chez moi.
Mais quand je pars le matin pour le boulot à 5h du matin et que j’ouvre du coup mon portail jeedom allume la lumière aussi ce c**.
Alors je sais bien que certains me diront rajoute un si et un autre si, mais si une variable peut le faire je trouve çà cool.
En tout cas merci à tous pour vos réponses
Il y aura toujours plusieurs façons de remonter et de valider un événement, à chacun sa logique, son schéma d’automatisations. Ce que j’ai voulu faire comprendre en qualifiant les variables de plus « simples » (car créer une commande info en virtuelle n’est pas difficile), c’est que la variable offre une praticité. Tu écris ta variable en scénario et elle se « crée » automatiquement, tu n’as pas à quitter la construction de ton scénario (si tu n’avais pas anticipé la variable au moment de monter le scénario) pour aller créer ton info dans une virtuelle. Même si tu regroupes toutes tes variables dans une virtuelle, tu vas vite te retrouver avec autant d’info que de variables.
À titre d’exemple, pour le fonctionnement d’une seule automatisation, j’ai un équipement (groupe) composé de 5 variables différentes. Quand toutes les variables sont égales à 0 pendant plus d’une heure, ça affecte une autre variable qui démarre un scénario. Pour cette automatisation, aucune alternative n’existe, pas même un truc usine à gaz qui désactive un scénario et en active d’autres, ni avec des #triggers# ou #tag#. La seule alternative, c’est le virtuelle qui nécessiterait de créer 6 commandes infos pour le bon fonctionnement d’une seule automatisation.
J’ai aussi des scénarios qui ont à la fois des variables et des commandes infos en déclencheurs. Là aussi, pas d’autres alternatives, c’est soit la variable, soit une info virtuelle.
L’important, c’est que tu utilises ce qui te convient le mieux. Certains vont faire deux scénarios distincts pour exécuter des actions opposées, tandis que d’autres vont regrouper les actions en un seul scénario avec des #triggers#. Le fond sera le même, c’est juste la forme qui est différente, même si la forme n’est pas à prendre à la légère car selon la structure d’un scénario, elle peut nécessiter plus ou moins de ressources, mais pour ma part, et pour revenir aux variables, avec Jeedom qui tourne depuis bientôt 7 ans de manière intensive, comme expliqué dans mon précédent post, ma trentaine de variables n’a jamais impacté les performances ni la stabilité. Je précise quand même que je n’utilise pas de variables « dynamiques ». Ce ne sont pas des infos qui changent toutes les 5 minutes, où alors j’en ai peut-être une ou deux comme ça.
Et si une alternative existe, le bloc code.
Je pense que c’est plus dangereux pour un raspi et carte sd
Peut-être, mais l’auteur du post a demandé des exemples d’utilisation d’une variable afin de faciliter la construction de ses scénarios. Je ne pense pas qu’un bloc code soit « plus simple » qu’une variable. Tout le monde ne gère pas le code, c’est à mon sens une prise de tête supplémentaire pour ceux qui ne sont pas à l’aise avec ça, alors que les variables sont faites pour ça et se programment très simplement après une brève lecture de la documentation. Tu me diras, ça permet d’apprendre, donc ce n’est pas plus mal, mais j’insiste sur la praticité dans la comparaison.
J’en doute pas, car comme déjà dit, je n’ai aucune notion sur l’architecture même de Jeedom. Tu es beaucoup mieux calé que moi sur ça. D’ailleurs, j’ai oublié de préciser que je tourne sur SSD. C’est vrai que j’aurais dû le mentionner quand je disais que mes variables n’impactaient pas la db 
Après, c’est comme tout, parfois j’entends que telle chose peut affecter le bon fonctionnement de Jeedom, comme cloner des virtuelles, pour autant, je connais des personnes qui virtualisent à gogo tout leur équipement sans rencontre de soucis en particulier.
je répondais juste a ton exemple d’automatisation ou tu dis qu’il n’y a pas d’autre moyen.
Si tu veux bien, je te solliciterais peut-être pour m’expliquer (plus tard) comment faire avec un virtuel à la place des variables car je n’ai pas tout compris 
et j’ai compté j’ai 50 variables, aie aie erreur du début que je traine toujours.
