Les deux conditions, prise individuellement, fonctionnent mais le mélange de la condition analogique [x] =! [y] et de la condition numérique [Clignotant output] n’est pas acceptée : « Erreur - mélange IO/ANA ». En toute logique, le résultat de [x] =! [y], qui est numérique, devrait pouvoir être pris en compte.
Les 2 formulations, [x] =! [y] [ET] [Clignotant] ou [Clignotant] [ET] [x] =! [y] génèrent la même erreur.
Existe-t-il une autre formulation en dehors de la création de 2 règles ?
Donc utilisation de liens et d’une règle là où, logiquement, une seule règle aurait dû suffire. Cela participe à l’impression ambiante que l’PX800 v5, décidément, c’est compliqué.
Le fait de ne pas pouvoir prendre en compte le résultat binaire d’une comparaison analogique dans une équation binaire est-il :
un bug à corriger ?
une contrainte temporaire qui est prévue d’être levée ?
Evènement : [IO_1] OU [IO_2] => Résultat : Action attendue de la règle
Est-t-il possible de faire évoluer la logique des règles pour considérer qu’un ensemble de deux variables analogiques associées à une clause comparative devient une variable binaire pouvant être combinées avec d’autres variables binaires ?
En un mot, pouvoir combiner des clauses binaires et des clauses analogiques dans les règles.
Exemple : Evènement : [va] > [vb] OU [vc] == [vd] OU [IO_c]
Ou un jeux de parenthèse afin de prioriser des logiques combinatoires.
Ça serait étonnant que se ne soit pas prévu. Gardons en mémoire que la V5 est très jeune.
Merci pour ce post de 2021 qui m’a bien aidé à comprendre pourquoi j’avais cette erreur…
Comme on peut maintenant appeller une règle dans une condition d’une autre règle, j’ai pu du coup la résoudre en créant 2 règles :
Une règle avec les conditions en ANA
Une autre avec les conditions en IO + appel à la règle contenant les ANA
Plus de soucis mais de la lourdeur.
@GCE Avez-vous ce sujet en roadmap pour une prochaine release ?
bonjour @yvesbar ,
les comparateurs analogiques transposent une condition sur variable analogique en IO, dans une même scène, vous pouvez mélanger IO et comparateurs (donc analogiques) .
Dans la majorité des cas, les comparateurs apportent donc la solution.
Vous avez également la possibilité de faire appel au résultat d’une scène dans une autre.
Pour moi ce n’est pas de la lourdeur, mais de la souplesse quand on perçoit toutes les possibilités de programmation et de structuration permises par la fonctionnalité.
En effet le comparateur permet régler le problème. Pour moi je vois la création d’un objet nécessaire quand une opération est a répéter plusieurs fois. Dans le cas où cette opération n’est faite qu’une seule fois, il est plus lourd (consommateur de ressources) de créer un objet et l’utiliser dans une règle que d’utiliser directement les opérations mises à disposition dans les scénarios.
Ce qui est perturbant ici c’est qu’en logique combinatoire il n’y a pas d’erreur car le résultat d’une comparaison est un booléen tout comme une IO (0/1). Une habitude à prendre en espérant ne pas dépasser les 64 comparaisons possibles (mais ça laisse déjà de la marge).
Je n’avais rien trouvé à ce sujet dans la notice. Merci au forum
en espérant ne pas dépasser les 64 comparaisons possibles (mais ça laisse déjà de la marge).