Merci, super. J’ai trouvé. 
Je ne pourrai rien faire malheureusement, la liste (run,start,stop) n’est pas construite par l’API status mais par les fichiers de configuration à la création de commande uniquement. Parce que l’appareil fournit une liste vide à chaque rafraichissement d’infos.
Salut,
Tu as trouvé pour le problème des « ronds » sans écriture sur le template V2 c’est ça ?
Et pour le fait de pouvoir mettre à jour les commandes lors d’une mise à jour du plugin tu penses faire quoi ?
Parce que s’il faut supprimer X commandes et faire recréer parce que les commandes ont changées entre la version x et y tu va avoir plein de remontée lors de la mise à jour de la prochaine stables. Si c’est pas gérable automatiquement par le plugin il faudra bien mentionner les commandes à supprimer manuellement pour les recréer 
Oui, c’est corrigé.
Les noms de commande ? Ou les valeurs options des commande Liste ?
Faut que je force le nom des commandes à la mise à jour pense.
Je réfléchirai le jour venu.
Pour l’instant je veux stabiliser les modifications.
Beta sur le marché.
MAJ faite, OK pour le template dryerv2 
Je test dans l’après-midi pour les notifications et le regxp.
J’ai commenté la ligne 123 pour voir ce que ça donne sans le refresh dès que l’on change une commande comme le cycle de séchage pour voir s’il n’y a pas ce « soucis » qui fait que la commande est bien prise en compte mais que l’affichage attends le cron suivant pour être raccord.
if ($body['capability'] !== 'refresh' && $body['command'] !== 'refresh') {
// $eqLogic->refresh(); // Bison 05/02/2022
}
Edit :
@Flobul apparemment ça ne fonctionne pas, mon scénario détecte dès l’allumage du SL alors qu’il n’a pas encore tourné. Et puis en y réfléchissant si on fait 2 tournées dans la même journée ça va surement foirer même si on règle le regxp.
Dans le testeur :
#[Sous-sol][Sèche-linge][Dernière notification]# matches '/^(date('Y-m-d') (.*?) - Cycle terminé<(.*)>)$/'
EDIT : j’ai transformé comme ça, ça m’a l’air bon mais si l’appareil tourne 2 fois dans la journée, lors du 2eme cycle, dès qu’un évènement nouveau arrivera, la détection de fin de cycle sera à nouveau trouvé 
matches '/date('Y-m-d') (2[0-3]|[01]?[0-9]):([0-5]?[0-9]):([0-5]?[0-9]) - Cycle terminé/'
Merci pour ce retour.
Pour éviter d’avoir des problèmes de scénario pour des cas particuliers, je pense que je vais inclure une possibilité de notifier selon un message choisi (ici : Cycle terminé) directement depuis la commande Dernières notifications.
Si tu peux faire en sorte que ce soit plus simple pour intercepter un message dans la chaîne c’est clair que ça aiderait les suivants.
Je sais pas trop comment aider là dessus par contre sauf à tester.
Et pour l’histoire du refresh tu as une idée ? Je n’ai pas commenté la bonne ligne ?
Il faudrait si possible que l’envoi d’une action reste basée sur l’information liée Jeedom et que l’on n’attende pas le cron pour que ce soit mis à jour (l’histoire du #select# qui s’affiche).
Voilà ce que ça donne.
Marche avec scénario, commande message, même avec la commande notification de SmartThings
Au cas où la notification de SmartThings suffit pas, on peut la renvoyer.Je debug encore un peu avant de publier.
Bah j’ai pas cherché plus loin, vu que chez moi je ne reproduis pas et qu’à partir du moment ou la commande action est renseignée avec la bonne commande info, c’est le core qui gère le retour des valeurs.
J’ai commenté la ligne refresh dans smartthingsCmd.class.php et je modifie la valeur :
Chouette ! ça a l’air pas mal à voir à l’utilisation
Tu commentes quelle lignes dans le fichier ?
Lignes de 121 à 128 :
// Refresh après toutes les commandes sauf les commandes refresh de smartthings
if ($body['capability'] !== 'refresh' && $body['command'] !== 'refresh') {
// $eqLogic->refresh(); // Bison 05/02/2022
}
}
if (!preg_match('/v2/',$eqLogic->getConfiguration('listTemplate'))) {
$eqLogic->refreshWidget();
}
Le refresh() comme j’ai fais ou le refreshWidget() ?
Oui, c’est bien celui là.
Une petite vidéo de ce que ça me fait en changeant le cycle de séchage par exemple
Merci, ça m’a aidé.
Je viens de reproduire un truc similaire.
Ah ouf !
J’étais en train de voir dans un virtuel et ce n’est pas la même façon pour arriver à un résultat correct mais on a pas accès au mêmes champs.
En fait, en sélectionnant la valeur dans la liste :
- on envoie la valeur brute de la commande pour l’api SmartThings (Course_14), jusque-là OK,
- le core remplace le #select# par la valeur contenue dans la commande envoyée (Course_14), AÏE, c’est la valeur brute et non la valeur traduite associée (Coton)
Du coup, la liste des valeurs de la commande (Coton, eco…) ne reconnait pas la valeur brute parmi ses valeurs traduites.
J’ai une solution définitive à ça, mais un peu de travail : demander en Ajax à chaque changement de valeur la traduction.
Ah oui en effet. Mais donc c’est la même chose avec la vitesse de séchage alors que les valeurs sont 1,2,3. Ce que je pige pas trop c’est pourquoi tu n’avais pas le soucis de ton côté.
Pour l’instant, j’explique pas le fait que le core remplace pas le #select# chez toi.
Je vais déjà corriger ça, on verra le comportement ensuite.
Ha oui voilà c’est pas le même comportement chez toi.
Je suis en 4.1.8 encore et j’utilise Firefox. Je tenterai sur un autre navigateur…
Bonne nouvelle, j’ai trouvé une parade facile.
Je pousserai demain la mise à jour, je pense.
C’est sur le marché.
J’en parle ici : Plugin SmartThings - Documentation et actualités - #16 par Flobul
Cool, merci je teste ça demain je pense. Je vais adapter mon scénario pour prendre en compte cette nouvelle possibilité de gérer les notifications.
Je te validerai aussi si le coup du #select# est réglé chez moi et on pourra fermer ce sujet 