j’ai remarqué que l’ordre d’écriture des scénarios était très important, comme si l’Ipx ne savait pas les lire en parallèle mais ne les lisait que les un à la suite des autres.
Exemple :
Scene 5 : Si Compteur Seconde = 60 Alors Set Compteur Seconde =0
Scene 6 : Si Compteur Seconde = 60 Alors Incrémentation Compteur heure de 1
Et bien le compteur d’heure ne s’incrémente pas.
En revanche si je fais :
Scene 5 : Si Compteur Seconde = 60 Alors Incrémentation Compteur heure de 1
Scene 6 : Si Compteur Seconde = 60 Alors Set Compteur Seconde =0
La le compteur d’heure s’incrémente…
Est ce que cela est normal ?Il me semblequ’un automate ou une box domotique Type Jeedom sont capable de traité des scénarios en parallèle et que l’ordre d’écriture n’influençais en rien le résultat… Alors pourquoi L’ipx est il sensible à cela ?
Est ce un choix de GCE ?
bonjour en règle général en programmation on valide une action et cette validation doit déclenché l’étape suivante
l’ordre d’écriture des scénarios de IPX est sans importance ce qui est important c’est de ne pas demandé deux actions sur un état sans appliqué la priorité d’exécution…
il ne faut pas ce servir des temps de réaction pour validé deux états contraire dans le même cycle (chevauchement)
je pense que IPX exécute les scénarios en lecture de son état logique (elle valide une action si les conditions sont réunit dans la scène) donc vos scènes ne seront pas toujours exécuté (risque de perte d’incrémentation de vos compteurs)
sur votre exemple je ferais la validation de l’heure (minutes plutôt) à 59 et le set à 60 ainsi vous aurez au moins un cycle de lecture des scènarios et ainsi pas de chevauchement d’état
Si on analyse vous perdez à chaque fois une seconde dans votre comptage
cdt
Je pense que @dede3828 ne veut pas parler de l’ordre dans lequel les règles sont écrites mais de l’ordre de leur définition dans la liste des règles.
@dede3828 est tombé sur un cas qui démontre que l’ordre des règles est important et je pourrais en produire à l’envi. Je crois comprendre que vous ne partagez pas ce point de vue, ce qui ne me semble pas raisonnable, mais je ne connais pas tout.
Qu’est-ce que l’état logique de l’IPX et comment demander une priorité d’exécution ?
Cordialement,
P.S.
La perte d’une seconde est anecdotique sur une heure: il suffit de réassigner le compteur à 1 dans la scène 5.
Maintenant il ne faut pas non plus sur-estimer la précision de l’IPX qui n’est pas un système temps réel : un compteur de secondes a une dérive de 0,5 % sur un IPX très peu chargé (14 secondes d’écart sur une heure).
@didierm@Teebex vos réponses ne me semblent pas incompatibles
…perso je prends parfois la précaution de mettre un Ta dans certaines scènes par rapport à cela (c’est plus propre ), mais je peux tester que souvent il n’y en a pas besoin
Ce serait intéressant d’avoir un éclairage de @GCE@Maxime_gce
Je ne suis pas un pro en programmation, mais il me semble que d’autre système exécute les règles en parallèle non ?
La imaginons j’ai écris 20 règles, et j’ai la règle 11 et 12 qui sont lié, et je désir ajouter une 3ème règle fonctionnant avec elles. mais cette règle que je dois ajoutée dois obligatoirement être placé avant la 11 pour que cela fonctionne… comment faire pour décaler toute les règles ?
J’aurai trouvé plus simple de pouvoir la rajouter à la fin… mais après je le répète, je n’est pas pas logique d’un informaticien lol
avant d’avoir la logique d’une machine ou d’un informaticien,
… il suffit d’avoir la logique d’un homme simple : regardez les évènements en présence et identifiez ce qui doit être fait en conséquence, dans l’ordre de la réalité de ces évènements et des variables qu’ils impactent (SV, compteurs, relais, scènes…)
C’est la meilleure manière d’aborder votre sujet pour 2 raisons:
vous n’avez aucune garantie sur un ordre d’execution des taches**
vous vous y retrouverez beaucoup mieux dans quelques mois/années lorsque vous voudrez reprendre (comprendre puis modifier) votre programmation
Pensez à marquer un décalage de séquence à chaque fois qu’il peut il y avoir une ambiguité, comme décrit par @didierm, ou bien en rajoutant des Ta par ci par là.
** même si @Teebex a surement raison, vous ne pouvez pas baser l’intégralité de votre programmation sur une logique séquentielle qui n’est pas spécifiée ni garantie par GCE (sauf erreur de ma part). On pourrait donc imaginer que cette dernière soit potentiellement modifiable par une future évolution de firmware (pour x raisons propres à GCE) et on se retrouverait alors avec une logique d’execution différente.
Les deux « façons de faire » sont complètement valide et ont chacunes leurs avantages et inconvenients.
Personnellement, je pense que GCE a fait le bon choix pour leur automate, car cela permet une fiabilité quasi infaillible. Vous n’avez pas idées du nombre de problèmes que la « programmation parallèle » peut engendrer
Vous avez certainement raison, c’est juste que j’était bien habitué à Eedomus et maintenant a Jeedom, ou il n’y a aucune importance d’ordre de création des scénarios… Enfin je pense… car les scénario peuvent être crée et ensuite placer dans des sous groupe etc etc…
@ZogStriP, moi aussi, à titre personnel, je préfère un ordre d’exécution séquentiel, stable (et documenté - merci @GCE@Maxime_gce ) conduisant à un système fiable et maitrisable.
@dede3828 : d’un point de vue très pratique j’ai laissé des trous dans la liste des règles pour construire des blocs logiques que je peux compléter le cas échéant. De mémoire, dans Jeedom, les scénarios sont des blocs beaucoup plus conséquents qu’une règle dans l’IPX et ils sont indépendants les uns des autres, d’où la faculté de les exécuter dans n’importe quel ordre.
Bonjour je précise mon analyse @Teebex suivant le matériel IPX ou autre automate
les cycles de lecture des variables et état logique est dépendantes des puissances des machines et la structure de traitement cela est propre à chaque machines @dede3828 les peuvent être sur plusieurs tunnel de traitement (on est sur des système un peu plus cher que IPX )
Comme le précise @romher il faut avoir une logique de nos traitements avant de vouloir comprendre la machine
Ce qui est important peu importe comment la machine va le traiter c’est de ne pas avoir de situation critique comme avoir deux actions a faire avec un état qui sera en plus modifié par l’une des actions (set du compteur)
il faut dans ce cas ne pas hésiter à ajouté une scène (peu importe ou dans la liste) qui assure la première action pour déclenché la deuxième on donne ainsi la priorité d’exécution
pour notre exemple soit on décale à 59 pour l’incrémentatio et 60 pour le reset
soit on garde 60 pour incrémenté avec activation d’un tempo (décalage volontaire) pour le reset
Bien cordialement
Pour écrire une routine en programmation, quel que soit le langage, quelle que soit la machine, il faut mettre des ordres, les uns derrière les autres, c’est inévitable. Ils seront lus un à un, dans l’ordre de leur écriture, qu’ils soient compilés ou interprétés. Les ordres au sein d’une routine sont donc placés dans un ordre bien défini.
je fais alors un rapprochement entre la routine décrite ci-dessus et le scénario dans l’IPX (scenario = ensemble de scènes)
j’appellerais « scenario » un ensemble de scènes ciblant une même ressource matérielle (compteur, entrée, sortie, …) ou fonctionnant ensemble pour mener une même action. C’est certain que les scènes au sein d’un scenario doivent alors se succéder dans le bon ordre, puisqu’elles dépendent des états successifs des ressources qu’elles pilotent.
Maintenant, si les scenarii (donc ensembles de scènes) ne ciblent pas les mêmes ressources, peu importe l’ordre dans lequel ils sont écrits, et peu importe que l’IPX les lise en parallèle ou séquentiellement (j’ai bien dit « les scenarii », pas les scènes!). Ca ne changerait rien au résultat, ça changerait juste la vitesse d’exécution.
Par exemple, la j’ai du coup un réel problème… les 5 1er scènes de mon ipx sont la pour Gérer le hors gel de ma piscine… j’ai ensuite crée d’autres scènes qui n’ont rien à voir… et la je m’aperçois que je devrais rajouter une scène de gestion de mon hors gels… mais je ne peu pas l’intercaler… Enfin je ne pense pas pouvoir.
Bonjour,
je crois que c’est pour cela que @Teebex a écrit :
d’un point de vue très pratique j’ai laissé des trous dans la liste des règles pour construire des blocs logiques que je peux compléter le cas échéant
Si vous avez quelques scènes ou blocs non liés, vous pouvez peut-être les ré-écrire plus bas et générer un espace à l’endroit voulu, cela minimiserait le travail.
Nous avons le droit d’espérer que dans une version proche @gce nous permettra d’exporter nos scènes, puis de les ré-importer. Cela nous permettrait de travailler nos scenarii dans un fichier texte, plus souple avec fonctions avancées de déplacement, insertion …
C’est une bonne idée donc on l’ajoute à notre liste.
Cependant je vous rappelle qu’en ce moment nous avons des demandes tous les jours. C’est pas vraiment gérable.
On doit donc faire des priorités et veillez à bien utiliser le temps des développeurs qui sont déjà bien occupés.
La priorité est la sortie de la release pour la v4 et la sortie du nouvel Ecodevices.
Merci @gce, par contre oui, pouvez vous nous confirmer comment sont géré les ordres d exécution des règles ? En prenant mon post d origine en exemple. Histoire de voir si nous avons le bon raisonnement .
Merci, et je comprends tout à fais cette logique. En revanche moi qui est manipuler eedomus et jeedom, il ne me semble pas qu il y est d ordre à respecter dans l écriture des scénarios…
Mais comme il a été dis plus haut, ce sont dès système différent fonctionnant d une manière différente et plus complexe.
Il est vrai qu au moins Avec la logique d exécution de l ipx et la simplicité de programmation de l ipx on a un truc super fiable !
Bonjour,
il me semble que Jeedom fonctionne avec des conditions « SI, SINON, ALORS »
Idem pour les champs « Critères » dans eedomus
Les blocs doivent donc forcément être écrits dans un ordre précis, et je ne vois pas très bien comment il pourrait en être autrement pour traiter de l’évenementiel même sur des machines plus complexes (multi-thread).
Cdt
), mais je peux tester que souvent il n’y en a pas besoin 
)
