Je regarderais plus en détails demain sur l’ordi si tu veux
Avec plaisir, c’est les 4 premières functions de la class
Ok, je le note dans la todolist…
Ça sera pas pour la beta de soir en tout cas !
Hello,
C’est fait ! Beta 0.0.2 dispo sur le market, changelog :
- Ajout vérification existence des commandes « start » et « stop » au cas où l’utilisateur les auraient supprimées manuellement
- Ajout vérifications lors des appels byId (robustification du code)
- Update liens Jeedom dans le template docs
- Ajout possibilité de vérifier que tous les triggers ou trigger_cancel soient valides pour déclencher (évaluation en ET)
- Mise à jour documentation
Pour l’évaluation en « ET » entre tous les triggers, j’ai fait des tests que sur des interrupteurs (booléen donc), ça manque peut-être un peu de debug… (c’était pas aussi simple que je ne le pensais…)
A+
AgP
1 « J'aime »
je ne souhaite pas prendre de beta de peur de perdre le support, donc je suis le sujt, ca parait sympa
Tu peux toujours installer le plugin et le désactiver le moment venu si nécessaire.
Tu ne perdras pas le support.
euh … je perd le support en cochant autoriser les betas, non ?
Non pas du tout, enfin ce n’est pas ce que j’ai vécu et à moins que ça est changé.
Quand j’ai dû posé une question au support, ça ne m’était pas possible tant que les plugins bêtas étaient actifs. Il m’a suffit de les désactiver pour pouvoir y accéder à nouveau.
Oui normalement c’est bien ca, tu ne perds l’accès au support que pendant la période où tu as des plugin bêta sur ton installation. Lorsqu’ils sont retirés c’est ok.
Sinon tu peux installer le plugin via github directement pour l’essayer sans avoir à activer les bêta !
Salut Agathe,
Déjà installé chez moi mais je n’arrive pas encore à voir, comme disait @kiboost, ce que je peux faire avec que je ne peux pas faire avec les scénarios.
Mais je continue.
Bon dimanche.
et bien même réponse : ça dépend de ce que tu veux faire ! Et aussi de ton niveau de maîtrise des scenarios !
J’avais déjà lu ta réponse qui est tout à fait valable
Ce n’est pas une critique, mais autant utiliser ce qui te sert réellement.
Installer un plugin que, au final, tu ne ne vas jamais utiliser ne présente pas d’intérêt.
C’est pareil, ça bloque l’accès au support
Alors j’ai crée une petite séquence … Je ne sais pas encore si elle marche : j’attends la pluie !
Un truc simple avec l’usage d’un tag
Coté déclencheur, j’ai utilisé une fonction au lieu d’un déclencheur. Je doute que ça marche (c’est pas prévu) mais pour le coup, il n’y pas d’erreur à la sauvegarde…Alors j’ai continué. A noter que le déclenchement manuel fonctionne et que j’ai coché la case "Tous les déclencheurs doivent être valides " … Donc incapable de dire si ça fonctionne ou pas …
Et ça envoie un bête message
Deux remarques de ce coté là :
- Le label reste toujours en gris « couleur de celui vide par défaut » et ne passe pas en « plus clair » quand il est renseigné. C’est dommage pour la lisibilité.
- L’usage du tag, c’est l’ancienne forme jeedom #tag1# est ok, tag(tag1,‹ ›) ne fonctionne pas. Pas gênant mais pas uniforme…
Une piste pour la todo …
- Coté action d’annulation, ça pourrait être plus simple d’avoir une liste déroulante avec les labels… ça éviterai les coquilles surtout
Coté doc, concernant l’onglet avancé, j’ai pas vu/compris l’usage de « Période » et « Prévision » …
Bref, c’est pas mal déjà et ça me donne quelques idées d’utilisation, mais juste avec les booléens, je suis un peu short sur les cas exploitables
Je te confirme que ca ne devrait pas marcher ! Le code évalue la cmd…
Uniquement sur les champs « label » ? Aussi sur les « Label action de référence » ? Il y a d’autres champs comme ca ? (J’utilise le design blanc, qui est ok, j’aurais du tester les autres…).
Tu es sur que c’est une histoire de « nouveau »/« ancien » ? Pour moi cette notation tag(tag1, ‹ ›) c’est pour les fonctions de calculs des scenarios uniquement, mais les tags #tag# sont toujours la norme, non ?
Oui, mais il faudrait imposer à l’utilisateur d’avoir enregistré l’équipement avant pour générer la liste…
Ce sont tes propres déclencheurs !! 
Pourquoi juste les booléens ? Tous les numériques sont ok (c’est moi hier soir qui n’ai testé qu’avec des booleens, mais le reste marche (normalement…)).
J’ai commencé a regarder pour ajouter les /matches/ mais c’est pas mal d’impact et un peu galère…
Tu peux me donner des exemples d’utilisation avec des conditions non numériques justement ?
Et merci pour tes tests !
AgP
Oui j’avais compris ça aussi … Pourtant ça ne bloque pas le déclenchement manuel … Sachant que j’ai un ET global c’est pas logique de prime abord que j’arrive à obtenir l’envoi du message du coup. Mystère sauf à dire que le déclenchement manuel ne prends pas en compte les tests …
Oui seulement « label » et « label action de référence », ceux du délai à coté fonctionnent bien
Dans les scénario, oui … que pour les calculs, pas certain… par exemple ça marche très bien avec
Le tag(nom, ’ ') c’est effectivement (avec valeur par défaut) que pour les tests
Oui. J’ai quand même l’habitude de sauvegarder plusieurs fois pendant la config, histoire de pas tout perdre si ça plante… Mais ça me semble être une petite contrainte, surtout vu le gain en terme de debug : 2 lettres inversées(par exemple uid et iud que je fais souvent), un espace caché ou simplement un truc pas visible parce que la valeur est tronquée à l’affichage c’est probablement un truc ultra courant. On passe vite plusieurs minutes à chercher. Et le jour ou on renomme d’un coté en oubliant l’autre …c’est la cata
Ok donc c’est juste pour ne pas avoir à passer par le testeur d’expression (ou il faut réécrire le test bien évidement) et avoir le test en direct ?
Oui, j’ai été trop vite/réducteur
Voir le 1er point, j’ai bien un test « >13 » mais incapable de dire s’il marche vraiment pour le moment.
Le « matches » c’est le top, mais tu peux reduire à un " var == ‹ string › " pour le moment , non ?
Là ça semble juste être la contrainte sur le ‹ type › dans le champs qui bloque
Le plugin infodujour par exemple renvoi les noms des saisons (en anglais)…
ça conditionne tout un tas de déclenchement de mode chez moi… Donc 1 scénario qui tourne 4 fois par an…
Ce cas d’usage est très proche de ce que pourrait faire ton plugin
Bon courage !
Hello,
Oui bien sur, le déclenchement manuel bypass tout le reste, sinon ca sert à rien !
Pareil pour la programmation.
Ok j’ai trouvé le soucis, je corrige ca de suite !
Non, c’est juste que quand tu crée un déclencheur avec une commande info, le plugin va re-créer une commande pour lui qui sert à mettre un « listener » sur cette commande. Le plugin va aussi par défaut historiser ces commandes. Et donc puisqu’elles sont créées, elles sont visibles dans cet onglet qui va permettre de choisir aussi si tu veux les rendre visibles sur le dashboard, supprimer l’historisation, et toutes les autres fonctions core usuelles sur les commandes…
En fait il y a 2 choses qui bloquent, le champ « Capteur » qui aujourd’hui ne sait évaluer qu’une commande info (donc il faudrait le modifier lui aussi pour prendre des variables)(edit : en fait avec des commandes ça marche aussi, sorry) et ensuite il faudrait ajouter le matches dans la liste déroulante et donc aussi dans l’algorithme(edit 2 : donc oui tu as raison, deja #cmd# == « string » c’est pas trop compliqué !). Et le soucis c’est plutôt le fait d’ouvrir à d’autres choses que des commandes « Info ». Mais c’est sur que le fait que ça soit accepté à la sauvegarde c’est pas bon, ça laisse penser que ça va marcher, je vais changer au moins ça pour la cohérence.
Pas vraiment, c’est pas vraiment intéressant d’utiliser mon plugin pour ne déclencher qu’une seule action, sans délai et sans actions d’annulation ! Pour moi le cœur intéressant du plugin est là et non pas dans les conditions de déclenchements. C’est notamment pour ça que j’ai ajouté par défaut la commande externe de déclenchement pour faire des déclenchements « compliqués » par ailleurs (scenario, autres plugin, Tasker, …). C’est pour ça que ça me dérange un peu de faire des modifs importantes sur cette partie « déclencheurs ». En tout cas c’est pas là dessus que je m’étais focalisée et c’est pas là que je vois la valeur ajoutée !
Mais je vais regarder plus en détail et essayer d’ajouter la prise en compte des variables et ensuite soit « matches » soit juste un == « string » pour la prochaine beta, ça sera toujours une amélioration !
A+
Bonjour à tous,
beta 3 disponible, changelog :
0.0.3 - 20 avril 2020
- Débug affichage champ label et label action de reference
- Ajout possibilité d’évaluer des « string » dans les conditions de declenchements
- Ajout exception si enregistrement avec des capteurs qui ne sont pas des commandes Jeedom
- Mise à jour doc en conséquence
Il est donc maintenant possible d’évaluer des « strings » mais uniquement sur des commandes Jeedom.
J’ai essayé d’ajouter les variables en déclencheurs mais c’était pas très concluant, il faut que je creuse encore un peu…
@naboleo, tu peux tester ?
(J’ai testé chez moi les string avec des « mode » du thermostat et retesté quasi tout le reste et le look avec les différents themes Jeedom). Si ok pour toi sur cette version je demanderai le passage en stable !
Merci !
AgP
Salut.
Tiptop ! Je fais quelques tests dans la soirée 
Ca marche chez moi.