Mais je tourne autour du pot …
Ma culture est absolument Variables : Un nom, Une Valeur (+ Fonctions et Procédures sans oublier SQL et Langages de commande pour piloter le process ++± serait-on en 1998 ?)
L’approche Objet m’est vraiment étrangere (une révolution culturelle ça prend du temps et c’est SGDG)
.
Je veux creer un scenario qui mémorise les valeurs des InfoCommandes qui m’intéressent (Genre temperature, humidité, pression, …/…)
Ce scénario fixerait le lien entre le monde de l’objet Equipement et mon monde de Variables
Mes scénarios d’arrosage etc… s’appuieront sur mes variables sans avoir à se replonger dans un monde que je ne maitrise pas (et ne maitriserai jamais)
(genre EqLogic; getName de la méthode Weathercmd et je passe les heures à lire de l’hébreu - je remercie vivement les auteurs qui prennent sur leur temps libre et cherchent à aider Mais je parle un peu Anglais, et pas du tout l’Hébreu -
Parfois je fais des rencontres (e-Papy, Salvialf, Mips, le pere infatigable de WifiLightV2, et j’en oublie beaucoup)
Désolé mais même après avoir relu plusieurs fois, j’avoue que j’ai du mal a comprendre ce que tu veux faire…
Je ne comprend pas non plus ton bloc code, celui-ci comporte des erreurs.
Je veux bien comprendre que tu cherches à revenir sur ce que tu maîtrises mais là honnêtement tu te fais des nœuds au cerveau pour rien.
Dans Jeedom les commandes (infos disons) sont liées à des équipements, qui sont eux mêmes liés à des objets. Ce ne sont pas des objets au sens programmation du terme mais juste des « boîtes ».
Par exemple :
Objet : Salon
Équipement : Prise
Commande info : Etat
La valeur de la commande info Etat est accessible en demandant #[Salon][Prise][Etat]#
Si j’ai compris ce que tu veux faire, c’est mettre la valeur de cette commande dans une variable qui s’appellera disons EtatPriseSalon.
Ok alors d’un côté tu as une variable avec une valeur que tu devras aller chercher avec variable(EtatPriseSalon) et de l’autre la même valeur que tu peux aller chercher en appelant #[Salon][Prise][Etat]#
Franchement c’est pas plus compliqué à comprendre et il n’y a qu’à nommer correctement tes objets, tes équipements et tes commandes pour que ce soit très simple sans utiliser de variables
Bonjour et Merci,
Fixer le lien entre le monde des Equipements et mon monde de variables reste mon but. Un jour j’acheterai un capteur de temperature etc … et je le prefererai peut_être à Weather => le scenario unique à changer -ou ce genre de trucs.
Il est clair que mon probleme est basique car je n’arrive pas à atteindre
#[Baudino][Meteo_Saint_Raphael][Température]# dans mon scenario -qui ne marche pas, utilisant ou pas les variables & intermediaires -
Il me reste un truc -sans doute tout con- à comprendre pour acceder dans un scénario de type code aux variables d’equipement
Encore merci
PS ; J’avais essayé cette approche de nommer les variables d’équipement entre #, mais sans succes
Pour comprendre mon mode de fonctionnement je joins le scénario qui me fait passer des sunrise/sunset de base à mysunrise/mysunset bricolés à ma sauce
en un point unique : MySuntimes (scenario d’un groupe Clauderies - My Way en quelque sorte-)
Pour le dire autrement: considères que les commandes info sont des « variables » dans « ton » monde et les actions les « procédures ».
Il n’y a aucune connaissance de programmation objet ni autre à connaître et aucun besoin insurmontable
forçant à écrire des bloc code. (Étant dev perso je suis plutôt contre les bloc code, je pense que j’en ai 2 sur tout mes scénarios)
Au fait, il n’est plus nécessaire de calculer le lever et coucher du soleil, tu peux juste utiliser #sunrise# et #sunset# (c’est dans la doc et le changelog) donc arrêtes d’utiliser les bloc codes
Je pense que tu prend pas le bon chemin, Bison te l’a expliqué.
Dans ce cas il existe une option dans la configuration des commandes, exemple tu as un equipement weather : #[Baudino][Meteo_Saint_Raphael][Température]# qui porte l’id 1010 que tu souhaite remplacer par un nouvel équipement de type capteur que tu vient d’acheter #[Baudino][Mon nouveau capteur][Température]# qui porte l’id 1011.
Dans la configuration avancé de ce nouveau capteur il suffit de cliquer sur Cette commande remplace l'ID :
Une fenêtre s’ouvrira, et il ne te restera plus qu’a indiquer l’ID que tu veut remplacer : 1010
Une fois validé, l’ID 1010 qui est utilisé dans tes scénarios sera remplacé par l’ID 1011, ainsi que sont historique.
Bon, je vais essayer de continuer mes explications parce que je t’assure que tu vas t’embourber si tu veux continuer dans cette voie et ce serait dommage.
Imagine que dans ton scénario tu souhaites dire : Si la température que je relève est supérieur à 25°c alors je ferme les volets du bureau
Sans utiliser de bloc code (parce que ça ne sert à rien ici) et en passant absolument par une variable il faudrait faire :
Tu vois bien qu’il y a pas plus simple que d’aller chercher directement la commande dans son objet et dans son équipement.
Et quand tu auras été acheté un autre capteur de température il va te falloir nommer ta variable de la bonne façon parce que juste « temperature » ne va pas permettre de distinguer avec celui que tu as déjà. Et quand tu en auras 10 …
Et le pire c’est que tu alourdira l’ensemble du fonctionnement de Jeedom puisque systématiquement tu lui demandera de copier une valeur dans une variable avant d’appeler cette variable alors que l’information est déjà là … sans passer par une variable.
Non ce n’est pas ton besoin. Tu n’as toujours pas expliqué ton besoin. Avoir des variables qui se remplissent n’est pas un besoin. A quoi cela va servir? Pourquoi? Il sera là le besoin.
Tu es entêté à vouloir mettre en place une idée que tu as imaginée mais dont tu ne comprends pas tout (et qui est beaucoup trop complexe, après on va voir un post que jeedom s’est trop compliqué) et tu demandes de l’aide pour la mettre en place.
Ou dans le cas souvent utilisé du retranchement des informaticiens
Expliquez moi votre besoin, je vous dirai comment vous en passer !
Dans ta réponse, comme tres souvent, il y a la réponse à ma question :
Acceder a une variable info d’un équipement dans un bloc Code est tres complexe (un peu déstabilisant pour une demande que je croyais basique - suis-je vraiment le seul ? -
Ce type de variable d’environnement « globale » est détachée des équipements dans mon monde ou l’on prêche l’indépendance au matériel (Peut-etre creuser la voie d’un virtuel genre Mamétéo pour choisir associer tel ou tel équipement pour calculer mytempérature ou etc … Liberté vis-à-vis des équipements de Base - Evidemment à reserverer à de rares variables jugées globales -
Jeedomesques Remerciements + Admiration et Reconnaissance du gros travail apporté à la Communauté
PS : Dans ma Culture, il y a les .ini de W95. Pour la personnalisation des outils, j’ai adoré - faciles à maitriser + copies avant action risquée -
Les Pros ont inventé La Base des Registres en W98, j’ai jamais osé y toucher : trop complexe/dangereux. Les Pros jugeaient avec raison qu’on pouvait faire de grosses bêtises avec les .ini trop accessibles (cf Config.sys !!!), mais, bon…
les .ini ca existent toujours (même sous jeedom, si si c’est vrai) et perso je trouve ca plus raisonnable que cette « base de registres »
et quelque part on y revient avec la culture micro-service (indépendances des services, responsabilités définies et clairs etc) => la config d’un service est déployée avec le service et pas/plus centralisée dans un gros truc que personne ne maitrise; on a l’info l’a où on en a besoin;
c’est ma vision de la simplicité.
donc à mort les variables globales qui ne sont que ta base de registres à toi… my 2 cents.
bref, j’apprécie le hors sujet mais … est-ce que ca répond au problème?
ca serait plus sympa de philosopher la dessus avec un verre en terrasse.
Meaning/Usage: To give or share your opinion . Explanation: This came from the original expression, « my two pennies worth. » It has been shortened recently to just « my two cents. » This is a way of offering your opinion and saying that is only worth two pennies.
Merci pour cette nouvelle (pour moi) expression
One single cent would be largely enough for mine
PS ; En effet, je suis meilleur en Rosé de Saint Raphael qu"en Informatique d’àc’t’heur (du chti for a change). Ce serait un plaisir de le partager
Jeedomement
En effet !!! Je crois que ce & a traversé mon cerveau en droite ligne de Dialog Manager de TSO ou de NT ??? Bref; pas d’excuse
Merci, j’ai donc la solution pour continuer a m’obstiner
Pour les éventuels lecteurs, j’ai la solution que je cherchais.
Mais des experts préféraient d’autres voies
A toi lecteur de faire la part des choses
A half out of 2 cents
Bonjour,
J’avais bien pris note de ton code -que j’utilise souvent dans des cas de base-
Ce n’est que tres exceptionnellement, quand je veux mettre mon ordre que j’utilise des scénarios code. Ma demande est quasi idéologique : Boite noire qui fait des calculs voulus pour dèfinir d’exceptionnelles variables d’environnement (évite de répéter à plusieurs endroits une répétition d’actions)
Un Virtuel permettrait sans doute d’atteindre ce but (sans les multiplier inutilement)
Jeandhom m’a permis d’accéder à des PHPteries permettant d’aller au dela du niveau de base habituel. Je ne le crois pas plus que moi adepte du ‹ Pourquoi faire simple quand on peut faire compliqué ›. (moi, faut voir …)
Je précise bien à un éventuel lecteur que beaucoup d’experts sont assez anti-code et proposent d’autres solutions que celle que Jeandhom m’a permis d’atteindre.
Experts (ou non) qui ne comprennent pas toujours le coeur de ma demande. Ce probleme là est de mon côté. « Ce qui se concoit bien s’énonce clairement » : Ya des formations pour çà ?
Jeedomement
Bonjour,
Une commande info d’un équipement ce n’est pas seulement une valeur à un instant T que vous pouvez effectivement stocker dans une variable mais aussi un historique.
Il s’agit là d’un monde réel et les équipements sont imparfaits ; une température donnée par un équipement est très relative et il est souvent plus intéressant de connaître l’évolution de cette température plutôt que sa valeur brute.
Vous augmentez la consigne de votre chauffage parce que la température diminue car si la température augmente il faut juste attendre !
Comme vos variables d’environnement ne vous permettront pas d’utiliser les historiques des commandes info, vous allez mélanger, dans vos scénarios des commandes info et les variables qui s’y rapportent et vous obtiendrez le contraire de ce que vous cherchiez !
Vous avez une vision informatique de la domotique mais quoiqu’il arrive vous aurez à faire avec des choses physiques alors autant l’accepter !
Pour faire des choses complexes, en domotique, il vaut mieux apprendre à souder plutôt qu’à programmer des blocs codes !
Ouah ! Retour aux sources ou bien Pan sur le bec. Un beau post de toutes façons.
Pour ne pas finir K-O, quelque part vous me rejoignez en ne prenant pas, telle quelle, une variable d’équipement, mais vous l’adaptez à la réalité. Ca peut se faire, aussi, avec du code. Mais déformer vos propos est hors-jeu
Jeu, Set et Match comme on dit dans le tennis
Jeedomement
