Voilà quelque temps que je tourne le problème dans tous les sens, et je voulais donc partager mes réflexions avec les autres utilisateurs du forum pour avoir vos avis et suggestions…
Dans certains cas, il peut être utile de déporter certaines fonctionnalités vers un logiciel de domotique. Pour cela, il existe des plugins qui se basent sur l’API de l’IPX pour connaître son état, celui des entrées, des sorties, etc.
Le problème c’est qu’à ma connaissance, la solution passe toujours par un « polling » régulier depuis le logiciel vers l’IPX pour mettre à jour l’information. Cela induit un délai parfois acceptable, mais il devient impossible de se baser sur des évènements fugitifs comme l’appui sur un bouton poussoir (entrée digitale) pour déclencher un scénario.
Pour pallier ce problème, j’envisageais de créer un scénario sur l’IPX sensible à l’ensemble des entrées qui m’intéressent et qui envoie via une requête http push vers le logiciel domotique une demande de rafraîchissement. Cela provoquerait un rechargement immédiat de l’état de l’IPX via l’API. Outre le fait que le scénario côté IPX ne serait pas très élégant, j’ai peur de manquer les évènements trop rapides qui seraient terminés avant que la requête de rechargement n’arrive pour les voir.
Je me demandais donc s’il existait une solution pour publier directement les évènements survenant sur l’IPX. Par exemple, une requête serait envoyée à chaque changement d’état d’une entrée qui contiendrait l’information de la nouvelle valeur de l’entrée. Je sais que c’est possible via le push http, mais si je dois créer autant de requêtes différentes et autant de scénarios que d’entrées à surveiller (j’ai 2 modules X24D en plus de l’IPX, et c’est sans compter les sorties relais et les entrées/sorties virtuelles) je vais rapidement avoir un problème d’échelle. Dans l’idéal, la solution serait donc intégrée directement au cœur de l’IPX, à coté du moteur de scénario. Il pourrait également être intéressant d’utiliser un protocole tel que mqtt en complément ou à la place d’un GET/POST http…
Voilà le résultat de mes cogitations. D’avance merci à tous pour vos retours !
Vous pouvez utiliser l’événement ON EVENT dans un scénario et faire un push UDP/HTTP avec la vignette appropriée.
Par exemple, pour gérer toutes vos entrées (y compris celles de vos X-24D), vous pouvez utiliser le scénario suivant
Événement : ON EVENT (Entrées physiques)
Action : ON
Résultat : PUSH (URL ON: ?inputs=$D, URL OFF: ?inputs=$D)
Ainsi, dès qu’un bouton poussoir sera pressé/relaché, votre IPX enverra une requête HTTP avec une liste de 56 0 ou 1 en fonction de l’état de chaques boutons
Merci beaucoup pour cette proposition de solution. Je n’étais au courant ni de la condition ON_EVENT, ni de la variable $D (ou son équivalent $R pour les sorties relais je suppose). Cela permet effectivement de réduire la quantité de scénarios et de requêtes push différentes.
J’ai fait quelques essais assez concluants, mais j’ai du mal à comprendre le sens de l’action ON/OFF associée à la condition ON_EVENT. J’ai l’impression que les deux requêtes (ON et OFF) sont systématiquement émises…
Maintenant, il ne me reste plus qu’à écrire le code qui va traiter ces requêtes (je pense utiliser « home assistant ») !
Merci. Je comprends bien l’idée de l’action on/off, mais dans le cas du on_event je ne vois pas bien ce que représente « l’état de l’événement » puisqu’il est sensible à l’ensemble des entrées. Est-ce que l’événement passe à 1 puis repasse à 0 à chaque changement de valeur sur l’une des entrées ? Dans ce cas, il suffirait de choisir l’action on ?
Je vois Là je pense que seul @Benjamin_GCE peut nous éclairer.
Qui plus est, lorsque j’ai voulu tester pour répondre, je me suis aperçus d’un truc pas normal (à mon sens) : en effet, avec le scénario décrit plus haut, si j’appuie longuement sur mon bouton poussoir (ie. je presse pendant plusieurs secondes), alors je reçois plusieurs mails ON et OFF !
L’événement « ON EVENT » doit être utiliser avec l’action ON. Actuellement, le bloc « ON EVENT » passe à 1 lorsqu’il y a un changement d’état et repasse à 0 après avoir effectué le scénario.
Donc si vous utilisez l’action ON/OFF, vous effectuerez l’action ON au passage de 0 à 1 puis l’action OFF lors de la descente de 1 à 0.
Merci pour cette précision, cela semble bien correspondre à ce que j’observe
J’avais également eu l’impression de recevoir des doublons en maintenant l’interrupteur, c’est à dire deux notifications consécutives pour lesquelles l’ensemble des valeurs des entrées reportées par l’étiquette $D était identique. Il faut que je regarde de plus près car j’ai pu me tromper en lisant mon log de requêtes http…
Là je pense que seul 
