Scène Déclencheur

Oui et non pour moi c’est aussi l’activation de la scène l’événement
ma scène c’est je demande l’activation de l’alarme et le fait que tous les capteurs soient ok déclenchent la poursuite vers l’activation (ou pas si un capteur est ko) de cette alarme (c’est ma logique, peut-être n’est elle pas bonne)
Pour donner un aperçu de ce que j’ai actuellement avec ma centrale HC2 de Myfox qui a été rachetée par Somfy mais dont ils ne fournissent plus de matériel juste le maintien du site web, donc au fur et à mesure que mes équipements tombe/tomberont en panne bah c’est mort (problème des détecteurs fumée notamment obligatoirement à changer tous les 10 ans) il me faut donc me tourner vers une autre solution, j’ai regardé les principales solutions Domoticz, Jeedom, Home-assistant et je dois dire que de loin Gladys est la plus simple au niveau du paramétrage mais pour certains besoins elle est aussi la moins puissante car limitée dans ce paramétrage, le bon équilibre entre les deux est certainement pas la plus facile des taches pour les développeurs mais Gladys a pour avantage d’avoir un développement qui suit tant faire se peut les demandes des utilisateurs.
Pour donner un exemple de ce que j’ai actuellement

Mes capteurs d’effraction


et leur paramétrages, ils sont de base intégrés dans la logique du système d’alarme mais ont un paramétrage fin quand même

Beau système bien concu mais fermé et comme il date de 2013 et n’est plus maintenu, il risque de pas tarder à être down que ce soit côté centrale ou des capteurs d’où mon orientation vers gladys…

L’avantage de Gladys est qu’il est ouvert au niveau du code (donc adaptable), au niveau des technologies qu’il supporte (donc perenne) , c’est pas une usine à gaz pour s’en servir ou le paramétrer, l’équipe de dev tente de répondre aux besoins des utilisateurs (même si parfois le dialogue est pas toujours simple car long par écrit et nécessite parfois la même approche de compréhension des choses, d’un coté les dev qui connaissent le code de Gladys donc savent ce qu’il est possible de faire et la complexité à le faire et de l’autre les utilisateurs qui demande des évolutions et dont la connaissance se situe entre néophyte qui découvre gladys et développeur de gladys, évolutions parfois justifiées et utiles à gladys avec une contrainte temporelle parfois impossible à réaliser techniquement parfois parce que la logique du fonctionnement de gladys n’est pas correctement comprise, mon cas parfois, mais pour moi si c’est pas compris cela peut aussi peut-être rebuter un futur utilisateur à l’adopter) .
Voilà j’ai été long mais espère avoir été clair (cette fois).

@pierre-gilles

Pour moi tu peut fermer cette demande, je pensais qu’elle simplifierait la programmation des scènes (ici dans le cas d’une alarme) mais peut-être la demande est mal formulée.
Peu-être l’idéal aurait été de pouvoir créer un device virtuel qui réunissent l’ensemble des capteurs assignés à l’alarme permettant ainsi de simplifier la création de scène…mais je ne ferais pas de demande rassures toi ! :blush:

Ps : un des avantages aussi de gladys c’est la simplicité du pilotage à distance il suffit de regarder comment faire sous HA ou jeedom pour s’en convaincre
C’est un atout pas toujours mis en avant, ce que peut faire gladys simplement qui est bien moins facile pour d’autres solution…

On a du mal à se comprendre je pense.
Je pensais que l’évènement (en fait le déclencheur de la scène) était le départ de la maison… donc je comprends finalement pas tout le reste.
En fait au départ tu présentes un ajout de toggle pour faire valider UN ou TOUS les critères de déclenchement.
Sauf que dans ces critères il y a le fait de quitter la maison (un évènement) et le fait de vérifier l’état d’une prise (un état). Ça n’a pas de sens de mettre ces deux choses dans le bloc DECLENCHEUR.

En tout logique le fait de quitter la maison doit déclencher la vérification de l’état des prises. Le fait d’ajouter le toggle ne peut pas changer le fonctionnement logique des scènes. Tu vois ce que je veux dire ?

oui en fait c’est plus dans un bloc après le bloc (l’utilisateur quitte la maison) à la limite que ce serait utile pour simplifier la programmation des scènes, dans mon esprit c’était

SI (l’utilisateur quitte la maison ET tous les capteurs présents sont ok)
ALORS ('l’alarme s’active)
SINON (envoie un message pour prévenir)

Actuellement le SINON n’existant pas

SI (l’utilisateur quitte la maison)
ALORS (récupère état capteur 1)
CONTINUE SI (capteur 1 est ok)
ALORS (passer l’alarme en mode « armée »)
SI (alarme et mode désarmé) 'suite à echec
ALORS (envoi un message)

la partie
ALORS (récupère état capteur 1)
CONTINUE SI (capteur 1 est ok)
étant fonction du nombre de capteurs possible il faut le répéter autant de fois, ca peut devenir fastidieux…et source d’erreurs !

Comme dit à @pierre-gilles, l’idéal serait de pouvoir créer un device virtuel dans l’integration mqtt pour regrouper l’état des capteurs nécessaire pour la gestion d’alarme et l’utiliser dans une scène ca deviendrait
SI (l’utilisateur quitte la maison)
ALORS (récupère état virtuel)
CONTINUE SI (virtuel est ok)
ALORS (passer l’alarme en mode « armée »)
SI (alarme et mode désarmé) 'suite à echec
ALORS (envoi un message)

et dans mon esprit cela deviendrait
SI (l’utilisateur quitte la maison ET virtuel ok)
ALORS ('l’alarme s’active)
SINON (envoie un message pour prévenir)

En fait je crois que c’est la notion événement qui est aussi un état et peut porter à confusion

l’utilisateur quitte la maison => passage de l’état « utilisateur présent » à « utilisateur absent » (pas de chat de schrodinger :thinking:)

ma logique est pour que la scène s’exécute donc que l’alarme (totale dans le cas présent) s’active il faut « utilisateur absent » ET « tous capteurs alarme totale ok »

Ok je pense que je comprends ta demande, même si il reste quelques points qui me chiffonnent dans ta logique :wink:

Finalement on se perd un peu car dans ce sujet tu exprimes 2 demandes distinctes.

Ta demande n°1 :

  • Créer un device virtuel qui regroupe les features de plusieurs devices physiques, avec de n’en avoir plus qu’un seul à tester dans le cadre de ta scène. (peut etre que cela rejoint la notion de « super device » dont j’avais déjà parlé ici > Créer un super device virtuel (mais qui avait été un échec cérébral pour moi ^^)

Demande n°2 :

  • Changer la manière dont une scène fonctionne > le fameux toggle UN <> TOUS mais qui ne peut pas avoir de sens dans la mesure où même si je comprends ta logique, Gladys doit traiter les informations les unes après les autres pour avancer de manière logique. Autrement dit un état d’un capteur ne peut pas être un déclencheur. Seul le changement d’état de celui-ci peut être un évènement déclencheur.
    Donc ta logique qui est :

pour que la scène s’exécute donc que l’alarme (totale dans le cas présent) s’active il faut « utilisateur absent » ET « tous capteurs alarme totale ok »

On pourra la retourner dans tous les sens, elle ne peut pas prendre cette forme dans Gladys (ni ailleurs je pense).

ca doit être mon coté Végan, je pense pas en 3D (les anciens comprendront la référence :blush:) pourtant adepte de la 1ère heure de la POO !

Dans le cas de l’alarme on peut imbriquer des scènes

Donc pouvoir fabriquer des scènes de base ayant des contraintes

CONDITIONS (utilisateur absent + capteur ok) => ACTION (arme l’alarme)

qu’on réutilise dans d’autres scènes.
la on a
Evenement (utilisateur sort) CONDITIONS (utilisateur absent + capteur ok) => ACTION (arme l’alarme)

Cela permet d’avoir des scène qui se déclenchent sur événement et des scène qui se déclenchent sur demande comme ci-dessus (mais dont l’exécution sera dépendante de condition) mais j’avais pas remarqué que c’était possible

image

c’était une suggestion à posteriori puisque ma demande semblait ne pas être possible mais c’est exactement l’idée (il serait intéressant d’avoir cette possibilité dans l’intégration mqtt de créer un appareil qui refléterait l’état de plusieurs autres)

Bah la si, on est bien en présence d’un état pas d’un événement…D’ailleurs je trouve que « Evenements » aurait été plus appropriés ou parlant que « Déclencheurs »

En fait, c’est vrai que la logique voudrait puisque des scènes peuvent déclencher d’autres scènes en ignorant la partie déclencheurs que ce soit dans la partie 2

que cela soit fait

avec la possibilité d’avoir ET en plus du OU et là pour le coup ça rentre pile poil dans ce que je voulais faire et que ce serait la manière la plus simple de faire…J’ose même plus faire la demande de fonctionnalités :woozy_face:

En réfléchissant 2 min , c’est possible de le faire actuellement.
Rien ne t’empêche de créer ton device virtuel dans MQTT.

Ensuite avec 2 scènes tu mets a jour ton device virtuel avec le changement d’etat de tes capteurs d’ouvertures, mouvement…

stp tu pourrais me montrer comment car je vois vraiment pas comment faire actuellement (mais j’ai peut-être loupé un truc, si si c’est possible ! :upside_down_face:)

Je te montre quand je rentre chez moi

1 « J'aime »

Alors j’ai trouvé un bug dans les scènes sur le déclencheur changement état appareil.

Je remonte le bug et j’essai de t’expliquer.

Pas de souci ! merci :wink:

Tout d’abord il faut créer un device MQTT

J’ai créer un device avec la fonctionnalité Ouverture (Oui/Non)

Ce n’est pas un capteur car on a besoin de le piloter depuis une scène dans Gladys.

Ensuite il faut créer 2 scène pour controller le device MQTT
Une scène détection ouverture qui va détecter le changement d’état d’un capteur d’ouverture par exemple. Dans ce cas on va passer le device MQTT à la valeur 1.
La deuxième scène sera pour détecter le changement d’état d’un capteur et ainsi on mettra le device MQTT à 0.

Les valeurs du device MQTT tu peux mettre l’inverse si tu veux. Ici ce n’est qu’un exemple.

image

  1. Création de la scène de détection d’ouverture

ATTENTION: Ici j’ai un bug sur le déclencheur changement d’état. Je vais mettre ici la vrai façon de faire mais cela ne fonctionnera pas à cause du bug. Pour que cela fonctionne il faudra inverser le choix ouvert / fermé.

Ici mettre dans les déclencheurs tous les capteurs que tu veux tester.Ainsi si un des capteurs passe à l’état ouvert alors cela veut dire que ta maison est ouverte. Pour l’exemple j’ai mis que 2 capteurs.


Je n’ai pas coché la case Exécuter seulement… comme cela à chaque envoi de ton capteur zigbee la scène sera executé.

Dans un bloc action mettre l’action Contrôler un appareil et mettre le commutateur sur l’état 1 / ON

La scène est terminé.

  1. Création de la scène de détection de fermeture

ATTENTION: Ici j’ai un bug sur le déclencheur changement d’état. Je vais mettre ici la vrai façon de faire mais cela ne fonctionnera pas à cause du bug. Pour que cela fonctionne il faudra inverser le choix ouvert / fermé.

Ici mettre dans les déclencheurs tous les capteurs que tu veux tester.Ainsi la scène sera executé à chaque fois que Gladys va recevoir un état fermé d’un des capteurs. Pour l’exemple j’ai mis que 2 capteurs.

Dans un premier bloc action on va récupérer l’état de tous les capteurs.
Contrairement à la scèe d’ouverture, ici il faut que tous les capteurs soient fermés pour considérer la maison fermée!

Dans un deuxième bloc action, on va ajouter une action Continuer seulement si pour chaque capteur.
Si la valeur est égal à 1 cela veut dire que ton capteur est fermé.

Ensuite dans un dernier bloc ajouter une action Contrôler un appareil et mettre ton device MQTT à 0 / OFF

Ensuite tu peux utiliser ton device MQTT dans tes scènes.

Par exemple faire une scène avec en déclencheur Départ de la maison.
Dans un bloc dessous récuperer l’état de ton device MQTT
Dans un autre bloc une action Continuer et seulement si pour vérifier la valeur à 0 ou à 1 de ton device MQTT
Ensuite ajouter d’autre bloc en fonction du but de ta scène.

Voila j’espère que c’est clair pour toi et que cela pourra t’aider.

Oui super clair, je te remercie :+1: je vais faire comme cela :wink:

Mais pour être honnête

  • autant la 1ère reste simple (test détection d’une ouverture)
  • autant c’est diablement fastidieux pour la 2de

Et je suis étonné de la logique que la 2de sous-tend, dans le premier cas c’est un changement d’un état qui est testé dans la 2de c’est un état des états !
Quoique comme on a le coche « exécuter seulement… » cela permet de tester sur un changement d’état

image

L’intitulé devrait être "état de l’appareil’ , le capteur d’ouverture envoie régulièrement un état et seulement un état ou également un evenement : changement d’état et c’est cela qui est détecté ? (les 2 selon plus haut le coche certainement mais c’est sans importance c’est de la tambouille interne :blush:)

Donc en fait finalement dans la zone déclencheurs on a
Cas 1
« Chaque déclencheur est indépendant. Lorsque les conditions de l’un ces déclencheurs sont respectées, la scène s’exécute. »
qui est adéquate pour tester si au moins un des capteurs est ouvert

Si on avait pu avoir le toggle que je proposais
Cas 2
« Chaque déclencheur est indépendant. Lorsque les conditions de tous ces déclencheurs sont respectées, la scène s’exécute. »
qui est adéquate pour tester si au moins tous les capteurs sont fermés

On pouvait dupliquer la scène 1 passer le toggle à « tous » passer les capteurs d’ouverts à fermés et c’était ok

on restait dans la même logique de fonctionnement et pas devoir se servir du
« récupérer dernier état » et « continuer seulement si » (j’ai 20 capteurs 3 détecteurs de fumée :smiling_face_with_tear:)

Mais bon, j’ai été trop ambitieux sur ce coup là ! :sob:

Mais je trouve que l’idée de proposer un capteur virtuel plus élaboré
fdc31878cb53739d373e2ce024813f41d05ec626_2_172x375
ou on pourrait mettre les différents capteurs comme ci dessous
5cabdac07fe33612edae1446cce92cf09b278186_2_417x375
serait pas mal non ?

Je me permet de coller le lien d’un message écrit ailleurs, qui peut fonctionner ici aussi.
J’ai tendance à penser que @cce66 tu as tendance à demander que Gladys s’adapte à ta manière de réfléchir alors que ce n’est pas le plus pertinent (et je ne dis pas que tu réfléchis mal ! J’ai eu un peu le même genre de problème au départ).

Non non, j’avais finalement convenu plus haut qu’effectivement l’événement était bien le déclencheur « l’utilisateur sort de la maison » et ensuite qu’il manquait dans la partie « conditions » la possibilité d’avoir le choix entre « ET » et « OU » dans les conditions
Comme ça on peut avoir :

  • Capteur1 fermé ET capteur2 fermé ET capteur3 fermé etc => CONDITION tous les capteurs sont fermés ACTION (on peut armer l’alarme ou alarme armée et tout va bien)
  • Capteur1 ouvert OU capteur2 ouvert OU capteur3 ouvert etc => CONDITION au moins un capteur ouvert ACTION (on ne peut pas armer l’alarme ou alarme armée donc effraction donc déclenchement sirène ou envoi d’un message etc)

Tu pense pas que serait plus clair et simple comme cela ?

[quote=« cce66, post:26, topic:8448 »]
En fait, c’est vrai que la logique voudrait puisque des scènes peuvent déclencher d’autres scènes en ignorant la partie déclencheurs que ce soit dans la partie 2

que cela soit fait

avec la possibilité d’avoir ET en plus du OU et là pour le coup ça rentre pile poil dans ce que je voulais faire et que ce serait la manière la plus simple de faire…J’ose même plus faire la demande de fonctionnalités :woozy_face:

Au lieu de mettre un bouton ET en plus du bouton OU, ce qui necessite un développement, tu peux juste rajouter une box Continuer si et seulement si à coté, dans le même bloc, cela fonctionnera comme un ET.

Décidemment je vois toujours pas le problème en fait.

Exemple :

Peut être que ce qui serait plus explicite, serait de réaliser la suggestion de @Tlse-vins (ils sont bons les gars du Sud ;)) , un simple changement cosmétique, pour que ça donne :

Ce serait peut-être mieux comme ça ?

1 « J'aime »

Pour me faire mieux comprendre j’ai fait les scènes correspondantes :

Au moins un détecteur ouvert


image

Tous detecteurs fermés version actuelle


Tous detecteurs fermés version que je trouves plus simple

version idéale

J’avais pas envisagé la solution que tu as proposé car en dehors de ma logique c’est vrai :thinking: :exploding_head:

Maintenant je ferais comme c’est, ma proposition n’était faite que pour améliorer les choses si elles peuvent l’être ! Il n’y avait ni urgence dans le demande ni tentative d’imposer ma vision ou ma façon de penser, juste une proposition (très mal formulée au départ c’est vrai mais c’est pas toujours évident de transposer par écrit quand il y a du visuel ou du fonctionnel !) mais je me rallie au vote de la majorité des gens sans problème, mais je suis un peu étonné de la réaction que cela a entrainé…

On m’aurait dit

  • c’est vrai que c’est plus clair, on garde l’idée sous le coude car pour l’instant on peut faire autrement et on a d’autres priorités dans le développement
    ou
  • c’est pas possible pour des raison techniques ou à cause du codage actuel
  • tu peux faire comme cela (mais pour moi ça reste moche :stuck_out_tongue_closed_eyes: :blush:)

j’aurais compris ! :wink:

Alors je vais tenter un résumé, car au final on parle beaucoup pour pas grand chose :wink:

La version que j’ai proposé, correspond à ce que tu as proposé comme « Tous détecteurs fermés version que je trouves plus simple ».
C’est juste que tu as besoin de quelques clics en plus (pas beaucoup sincèrement).
Donc finalement on se rejoint quasi totalement.

La direction à prendre, serait de demander à Pierre-Gilles si l’ajout d’un simple texte ET lors de l’ajout d’une action dans un même bloc lui parait intéressante, ou bien s’il a une autre proposition.

Petite digression :
Je reviens un dernier coup sur les problèmes de compréhension. Il a été très difficile de te suivre sur le forum, car d’après moi tu as écris tes messages au fur et à mesure de ta réflexion, en suivant ce que ta logique te disait.
Et lorsque quelqu’un te répondait que tu te trompais / que tu faisais fausse route, tu as insisté, comme si tu avais toujours une réponse, ce qui n’est pas évident à gérer pour tes lecteurs.
En plus comme tu le dis, à l’écrit c’est compliqué.

Je te comprends car je sais qu’à mes débuts ici j’ai eu plein d’idées, plein de suggestions… et j’étais super frustré quand Pierre-Gilles me disait que c’était pas interessant ou raccord avec le projet, soit que je faisais des hors sujets.
J’avais l’impression d’être un incompris :sweat_smile:

Finalement, plus j’ai compris le fonctionnement de Gladys et de son forum, mieux j’ai participé (enfin si je dis encore de la merde faites-moi signe hein ^^).
Tu as l’air passionné et c’est quelque chose de très positif, il manque juste un cadre un peu plus structuré pour faciliter nos échanges.

Donc mon conseil : prends le temps de bien comprendre ce que fait Gladys, dans quelle logique, et tu verras tout son potentiel. Tes suggestions pour l’améliorer n’en seront que plus pertinentes :wink: !!

1 « J'aime »

La version idéale que tu proposes tu peux déjà le faire sauf que c’est pas marqué ET. Tu ajoutes 3 actions Continuer seulement si dans le même box et ca fait ce que tu demandes en faite.

1 « J'aime »

Entièrement d’accord avec toi (au clic près exactement c’est la même chose)

Pour le reste, j’ai fait une demande pour répondre à mon besoin on me dit pas possible ou faut faire autrement, comme c’est frustrant je fais d’autre proposition autour qui pourrait contourner jusqu’à ce que @_Will_71 me propose une solution qui fonctionnes (merci encore :+1:) donc oui ma réflexion a évolué effectivement en fonction des réponses apportées et de ce que je comprenais en cours de route avec les réponses apportées (qui a dit c’est un macroniste dans la salle ? :rofl: « Seul les siths sont aussi absolu. » :crazy_face:)

Après ça reste le but d’un forum…et des fois il faut persévérer sans quoi je n’aurais pas réussi à relier Gladys à mon IPX800V5 via Node-red et piloter mes volets en fonction de la position du soleil, j’ai trouvé comment faire et partagé mon expérience via des mini-tutos :slight_smile: alors qu’initialement j’avais fait des demandes à @pierre-gilles (ou sur le forum dans les demande de features je me rappelle plus trop) et la réponse était dans l’actuel ce n’était pas possible et c’est au cours des discussions (car j’avais pas compris que la syntaxe mqtt soit pas standard) avec @pierre-gilles entre autre que j’ai compris comment fonctionnait gladys et donc comment faire en passant par Node-red, pareil pour la position du soleil, j’avais fait une requête pour cela on m’a répondu pas possible pour le moment j’ai contourné avec Node-red et maintenant je peux piloter les VR dans gladys en tenant compte de la position du soleil !
Ma démarche c’est « je veux faire quelque chose si je peux le faire en passant par la porte et bien essayons de voir si je peux le faire en passant par la fenêtre » et si j’y arrives j’en fait profiter les autres !

Là je comprend pas ta remarque en interne ce n’est pas la même logique d’un coté on a
OU dans la scène qui détecte si UN détecteur est ** OUVERT**

et de l’autre un ET dans ma 2de scène qui détecte si TOUS mes capteurs sont FERMES cela change la logique interne du traitement c’est pas juste un ajout de texte

Pour changer la façon dont sont interprétés les blocs il faudrait avoir le choix avec un toggle pour passer d’une logique « OU » à une logique « ET »

dans le 1er cas OU en algo
POUR CHAQUE BLOC
SI CONDITION REMPLIE ALORS SORT- DE-LA-SCENE
JUSQUA NOMBRE-DE-BLOCS

dans le 2d ET en algo
BLOCS-TESTES=0
POUR CHAQUE BLOC
SI CONDITION REMPLIE INCREMENTE BLOCS-TESTES
JUSQUA NOMBRE-DE-BLOCS
SI BLOCS-TESTES <> NOMBRE-DE-BLOCS ALORS SORT- DE-LA-SCENE

Pour tester j’ai posé la question à chatgpt
« écris moi avec les commentaires avec dans la seconde boucle la possibilité entre un traitement série ou parallèle selon un toggle qui s’appelle SceneSerieParallele dans l’UI le programme suivant » et j’ai mis le code du github
Gladys/server/lib/scene at master · GladysAssistant/Gladys · GitHub (du moins en cherchant le code du github il me semble que c’est là que cela se passe)

Il m’a retourné ça (merci chatgpt :slight_smile: ) je suis sur le cul ! :crazy_face:
Après pas sur que cela serait exploitable tel quel :thinking: :rofl: ni envisageable dans gladys (c’est vrai qu’il y a la structure de la base de données liée) mais ca me permet de découvrir et comprendre le code (pas ma tasse de thé ce langage :nauseated_face:) et ma foi voir ce qu’arrives à faire ChatGPT pour moi qui ai grandi en regardant la télé en noir et blanc et ou il fallait se lever le cul pour choisir entre la 1 et la 2 c’est bluffant même si cela faisait partie de mes rêves (« Planète interdite » !)

const Promise = require(‹ bluebird ›);
const { actionsFunc } = require(‹ ./scene.actions ›);
const { EVENTS, WEBSOCKET_MESSAGE_TYPES } = require(‹ …/…/utils/constants ›);
const { AbortScene } = require(‹ …/…/utils/coreErrors ›);
const logger = require(‹ …/…/utils/logger ›);

/**

  • @description Execute one action.
  • @param {object} self - Reference to the SceneManager.
  • @param {object} action - An Action from the db.
  • @param {object} scope - The scope passed to all actions.
  • @param {number} [columnIndex] - The X index of the action in the array of actions.
  • @param {number} [rowIndex] - The Y index of the action in the array of actions.
  • @returns {Promise} Resolve if the action was executed with success.
  • @example
  • executeAction(this, action, {});
    */
    async function executeAction(self, action, scope, columnIndex, rowIndex) {
    // Check if the action type is supported
    if (!actionsFunc[action.type]) {
    throw new Error(Action type "${action.type}" does not exist.);
    }

// Send a message to inform the UI that the action is being executed
if (columnIndex !== undefined && rowIndex !== undefined) {
self.event.emit(EVENTS.WEBSOCKET.SEND_ALL, {
type: WEBSOCKET_MESSAGE_TYPES.SCENE.EXECUTING_ACTION,
payload: { columnIndex, rowIndex },
});
}
try {
// Execute the action
await actionsFunc[action.type](self, action, scope, columnIndex, rowIndex);
} catch (e) {
if (e instanceof AbortScene) {
throw e;
} else {
logger.warn(e);
}
}

// Send a message to inform the UI that the action has finished being executed
if (columnIndex !== undefined && rowIndex !== undefined) {
self.event.emit(EVENTS.WEBSOCKET.SEND_ALL, {
type: WEBSOCKET_MESSAGE_TYPES.SCENE.FINISHED_EXECUTING_ACTION,
payload: { columnIndex, rowIndex },
});
}

return null;
}

/**

  • @description Execute an array of array of action.
  • @param {object} self - Reference to the SceneManager.
  • @param {object} actions - An array of array of actions from the db.
  • @param {object} scope - The scope passed to all actions.
  • @param {boolean} isParallel - Whether to execute actions in parallel or series based on the UI toggle.
  • @returns {Promise} Resolve if the action was executed with success.
  • @example
  • executeActions(this, actions, {}, true);
    */
    async function executeActions(self, actions, scope, isParallel = true) {
    // First level of the array should be executed in series
    await Promise.mapSeries(actions, async (parallelActions, columnIndex) => {
    // Then, the second level is executed based on the value of isParallel
    if (isParallel) {
    // Execute actions in parallel
    await Promise.map(parallelActions, async (action, rowIndex) => {
    await executeAction(self, action, scope, columnIndex, rowIndex);
    });
    } else {
    // Execute actions in series
    for (const [rowIndex, action] of parallelActions.entries()) {
    await executeAction(self, action, scope, columnIndex, rowIndex);
    }
    }
    });
    return null;
    }

module.exports = {
executeAction,
executeActions,
};

Un peu long mais si certains en lisant apprennent quelque chose de ce post tant mieux, c’est toujours çà de pris ! :slight_smile: