Bonjour,
Je prends l’exemple d’un scénario du type SI alors, SINON.
Je ne sais pas si je me trompe, mais quand j’interdis la répétition au niveau du SI et que la condition est restée la même, alors il n’exécute pas les actions, c’est normal, MAIS il ne rentre pas dans le SINON.
Pouvez-vous confirmer et y a-t-il une solution ?
Merci pour votre aide.
Bonjour
Condition identique = action non répétée
SI
…Alors
…Sinon
Donc logiquement si au SI y a non exécution pr cause de valeur identique, ca s’arrête.
Donc ni ALORS ni SINON ne sont exécutés.
Et je dirai heureusement !
Oui, ce n’est pas faux. Je suis d’accord !
Mais le SINON me permettait de tester une autre condition.
Alors je suis obligé d’écrire une suite de SI, ce qui complique les tests afin que tous les SI soient exclusifs.
Explique ce que tu veux faire, peut être t’y prends tu mal
1 « J'aime »
C’est sûr que je m’y prends mal. Je me précipite.
J’ai une PAC Mitsubishi avec une console. Je la pilotais à +/- 0,5 °C avec Melcloud qui est actuellement défaillant.
Je me suis donc précipité sur l’infrarouge qui est à +/- 1 °C ce qui ne me convient pas.
Donc, dans un scenario, je surveille la température et la pente de la courbe dans le but de modifier la consigne PAC et la vitesse de ventilation selon les différents cas de figure.
Pour n’avoir qu’un seul cas à traiter (genre switch case) j’utilise des SI ALORS SINON imbriqués.
Là j’ai remarqué que si la condition du SI n’a pas changé, on n’exécute pas le ALORS : normal.
Mais si cette condition se trouve être fausse, on ne rentre pas dans le SINON. Du coup les autres cas ne sont pas traités.
Par conséquent, j’ai remplacé l’analyse par une suite de SI en renforçant les conditions de manière qu’à chaque exécution du scénario un seul SI soit exécuté (ou pas).
Je vais en rester là pour l’instant et essayer d’améliorer mon algorithme.
Merci à vous de vous intéresser à mon analyse.
C’est étonnant, c’est le principe du sinon.
De ce que je comprend tu voudrais que si le SI est vrai mais non exécuté pour cause de répétition, alors que le sinon soit exécuté dans ce cas?Si c’est bien cela ton but alors tu t’y prend mal.
Dans ce cas dans ton si il faut que tu test un front montant. Pour ce faire tu écrit dans le si ton « test » && variable(memEtatTest)<> « test »
Puis après ton bloc si/alors/sinon
Tu affect par un bloc action à la variable memEtatTest la valeur de ton « test »
Tu auras donc le alors exécuté au changement de valeur de « test » et toutes les autre fois le sinon
Absolument pas !
Il a coché
Donc si il interdit ben ca ne fait rien
J’ai bien compris mais il dit:
Mais si cette condition se trouve être fausse, on ne rentre pas dans le SINON
Dans tous les cas je crois que l’on a tous compris la même chose. Ça clause de non répétition fonctionne bien mais c’est l’utilisation du si, alors sinon qu’il en fait qui ne correspond pas.
D’où ma proposition de passer pas un front.
pour illustrer ma proposition , je te propose un exemple (sans intérêt précis)
Si tu veux déclencher une action lorsque une température passe en dessous d’une certaine valeur (dans mon exemple 20°) ET seulement au moment du passage en dessous et dans tous les autres cas de figures (température au dessus de 20 ou en dessous mais déjà en dessous à l’appel précédent) appeler une autre action:
Bonjour et merci à @lefilliatre et @anon53349806,
Je vous reçois 5/5. Actuellement je suis en phase de test de mes SI ALORS en cascade.
Selon les conditions il n’y a pour l’instant qu’un seul SI qui répond et c’est ce que je voulais.
Mais je suis têtu. Je maintiens que si on ne rentre pas dans le SI on doit pouvoir logiquement rentrer dans le SINON. C’est algorithmiquement logique. Mais je crois comprendre : ce n’est pas géré ainsi dans Jeedom, sinon 
on verrait le symbole d’interdiction à coté du SINON, cqfd … Ouf.
On a tous compris la même chose, avec des nuances un peu différentes. Je serai très attentif aux prochains SI ALORS SINON !!!
Pour moi c’est beaucoup plus clair, grâce à vous, et je vous en remercie.
Je clos le sujet 
On a pas tout à fait compris le même fonctionnement.
Le fonctionnement du si/alors/sinon dans Jeedom est le suivant:
1er cas sans l’interdiction de répétition:
Jeedom effectue le test de la condition SI. Si le résultat est vrai alors Jeedom exécute les actions du alors. Si le résultat est faux, Jeedom exécute les actions du sinon. Et cela quelque soit l’état lors de l’appel précédent
2ème cas avec l’interdiction de répétition:
Jeedom effectue le test de la condition SI. Si le test est vrai Et que lors au dernier appel du scénario le résultat était faux alors il exécute les action du alors. Si lors de l’appel précédent le résultat était déjà vrai alors il ne fait ni alors ni sinon.
Si le résultat du test est faux et que le résultat de l’appel précédent était vrai alors il exécute les actions du sinon. Mais si lors de l’appel précédent le résultat était déjà faux alors Jeedom ne fait ni l’un ni l’autre.
Comme expliqué sur le bouton, il ne répète pas les actions si les conditions n’ont pas changées.
1 « J'aime »
et pour moi c’est le seul comportement logique… on ne va pas executer un « sinon » dans le cas ou le test est vrai tout ca pcq la non-répétition est activée 
si je résume autrement:
- SI test vrai on execute le ALORS
- si non le SINON
c’est tout.
Ensuite vient l’histoire de la non-répétition qui décide si oui ou non on doit executer les actions.
ca me parait tellement limpide comme logique que je ne comprend pas pourquoi il y a tant d’échanges
Simplement parce que @jmu a posé une question. Personne n’a remis en cause le fonctionnement de la fonction. Mais visiblement @jmu avait besoin de précision ou tout du moins une alternative pour coder ce dont il avait besoin. Et si il a pris la peine de poster ça question la moindre des choses c’est qu’on lui répond le plus précisément possible. Sûrement en plus que pour une personne qui poste, 4 autres se posent la question sans oser la poser!
Bonjour,
Et honnêtement, j’en fait partie !
Non pas que je n’osais la poser cette question, mais c’est tout simplement une fonctionnalité qui ne m’avait jamais frappé, et donc encore jamais utilisée dans mes scénarios…
Comme quoi, on en découvre en permanence même après quelques années d’utilisation !
Et merci à @lefilliatre pour avoir clairement explicité celle-ci (et à @jmu d’avoir initié cette discussion), désormais je garderai ça dans un coin de ma mémoire…
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.