Simulation scénario

[defmy]

L’idée n’est pas bête que ça. On retrouve pas mal la notion de dry-run sur de nombreux scripts, tester sans exécuter.

Mon idée pour l’implémentation serait un bouton simulation, jeedom détecte les commandes présentes dans le scénario, nous demande via un affichage/popup les valeurs associées aux commandes. Puis à partir de là, exécution du scénario en simulation avec les valeurs qu’on a renseigné.

[xav31190]

je pensais à un truc comme ça mais comment faire pour exécuter des actions sans les exécuter

[defmy]

Tu ne peux pas, puisque c’est une simulation, l’exécution n’est jamais lancée, sinon ce n’est pas une simulation^^

[defmy]

C’est comme si tu demandais de tester la suppression d’une valeur en simulation, ça supprime réellement dans la base puis comme tu as demandé la simulation, ça restaure la suppression via un rollback ou à partir d’une sauvegarde. T’imagines la complexité o_O

[Loic]

C’est ce dont je parlais plus haute en plus d’avoir plusieurs mois de dev la dessus ça ralentirait fortement l’exécution normal des scénarios et il faudrait que les plugins le prennent en charge.

Je comprends l’idée mais je suis pas que ça en vaille la chandelle. Car là ça veut dire plusieurs mois ou rien d’autre n’est développé (côté et plugin), un énorme breaking change pour les plugins (donc tous les plugins tierce plus compatible avec la nouvelle version du core jusqu’à mise à jour de ceux ci) et des scénarios plus lent pour tout le monde.

À la limite un mode où les actions ne sont pas exécutées (sans permettre de choisir les valeurs pour chaque commande info) ça serait possible. À noter que ça aurait aussi un impact sur les performances des scénarios.

[defmy]

Moi actuellement j’utilise le testeurs d’expression, puis j’avance séquentiellement pour tester mon scénario et j’essaye d’imaginer les valeurs qu’aurait tel et tel commande info. C’est vrai qu’une première exécution du scénario sans exécuter les commandes pourrait nous rassurer dans son fonctionnement.
Par contre des fois avec l’usage des tags et d’inter-dépendance entre scénarios, pas toujours simple de s’y retrouver. En général, pour ceux qui ont des complexités dans les scénarios de présence, d’alarme, solaire, chauffe-eau…, on ne touche plus de peur de tout péter. Je pense que dans l’ensemble une vision globale et de dépendance entre commandes et scénarios via un diagramme seraient plus à développer, dans l’idée de ce que fait le plugin plugin-diagrelationnel

[Loic]

Bonjour,
As tu essayé de cliquer sur le bouton lien en haut a droite ? Car ya deja un diagramme des dependances partout dans jeedom pour les commande/equipemement/objet/scénario/interaction…

[rennais35000]

Bonjour,
Sur qu’un jour on aura un bouton pour envoyer le scénario pour test et validation d’écriture à l’IA choisie par Jeedom.

[defmy]

Oui, sauf que je ne l’exploite pas car trop le fouillis,

• les scénarios désactivés sont présents,
• l’affichage des relations va trop loin (je m’intéresse à la commande Off dans le scénario mais je ne suis pas forcément intéressé par ce qui tourne autour de la commande Off avec d’autres scénarios, il faudrait peut-être une vue simple et une vue élargie),
• on ne voit pas le cheminement séquentiel du scénario, on pourrait voir 2 flèches, un pour le OUI et un autre pour le NON dans le cas d’une utilisation du SI, bon d’accord, je décris un peu le digramme d’activité UML,

PS : Je donne mon ressenti mais en aucun j’exige ou je critique le travail derrière.

[defmy]

Il sait bien écrire les scénarios Jeedom en plus^^

[Loic]

• les scénarios désactivés sont présents, => oui c’est normal
• l’affichage des relations va trop loin (je m’intéresse à la commande Off dans le scénario mais je ne suis pas forcément intéressé par ce qui tourne autour de la commande Off avec d’autres scénarios, il faudrait peut-être une vue simple et une vue élargie), => c’est configurable dans la configuration de jeedom
• • on ne voit pas le cheminement séquentiel du scénario, on pourrait voir 2 flèches, un pour le OUI et un autre pour le NON dans le cas d’une utilisation du SI, bon d’accord, je décris un peu le digramme d’activité UML, => tu as le type de trait qui te dis si le sens

Par contre non pas de si ou autre c’est pas but et ca n’est pas prévu.