Amelioration API plugin IPX800v4

Bonjour à tous!

C’est en regardant un peu le code du plugin que j’ai découvert le début d’API qui a été développé pour nos IPX dans le plugin ipx800v4…
De principe, c’est Jeedom qui vient récupérer à intervalles réguliers les différentes informations provenant de l’IPX (paramétrage de la fréquence dans la page de configuration du plugin)
Ce système a le mérite de limiter les échanges mais manque à mon sens cruellement de réactivité pour certains type d’équipements (notamment les capteurs d’alarmes).
Je suis donc parti en quête de trouver un moyen d’envoyer les informations souhaitées à l’initiative de l’IPX. Je ne suis attardé qu’à certains type de données (Entrées Digitales, Sorties Virtuelles et relais) mais il est envisageable de rajouter touts les types présent sur l’IPX.
Etant donnée la souplesse de l’IPX, je suis parti sur le principe de créer un push depuis l’IPX vers Jeedom lorsqu’un de ces types d’entrée change.
Alors que le nombre de scénario est limité sur l’IPX, j’ai remarqué qu’il existait une syntaxe qui permet en une seule requête push de remonter l’état de toutes les Entrées Digitales (ou bien toutes les Sorties Virtuelles, ou bien tous les relais). Bonheur!

Encore une fois, l’idée est de rendre l’ecosystème plus réactif plutôt que d’attendre que Jeedom fasse la requête à intervalle régulier.

J’ai donc modifié la function event de la classe ipx800v4 afin de pouvoir utiliser la syntaxe suivante dans un push IPX:

Voici la syntaxe à utiliser dans un push IPX pour

  • Mise à jour de toutes les entrées digitales:
    /core/api/jeeApi.php?type=ipx800v4&apikey=XXX&typeData=allD&data=$D

  • Mise à jour de tous les relais:
    /core/api/jeeApi.php?type=ipx800v4&apikey=XXX&typeData=allR&data=$R

  • Mise à jour de toutes les sorties virtuelles
    /core/api/jeeApi.php?type=ipx800v4&apikey=XXX&typeData=allVO&data=$VO

  • Mise à jour d’une seule variable:
    /core/api/jeeApi.php?type=ipx800v4&apikey=XXX&typeData=A&data=$B
    avec A qui prend les valeurs D, R ou VO
    et B qui prend la référence de la valeur à envoyer sur l’IPX(par exemple D1 ou VO1 ou R1…)

@Loic, si tu veux intégrer mon code dans le plugin, pas de souci…

1 « J'aime »

Salut
Je veux bien oui tu peux ouvrir une demande de support en te répondant tu pourras ensuite m’envoyer par mail le code.

J’ai ouvert la demande et j’ai mis directement la nouvelle classe dans le message.
Même si cela complexifie u peu le code, j’ai essayé de factoriser un peu et je suis passé par des constantes de classe afin de pouvoir faire évoluer le code…

Tu as fait une demande d’amélioration et non de support…

Bonjour Pierro,
J’ai moi aussi besoin de réactivité pour les retours d’état de l’ipx. (Tous les interrupteurs de la maison y sont connectés pour piloter un pont zigbee)

Pour l’instant, j’ai fait un push sur chaque entrée, c’est très réactif, mais peu pratique pour la config. J’avais fait un scénario qui parsait le push d’un onevent de l’ipx, mais ça me semblait être une usine à gaz…

Peux-tu me faire parvenir ton travail en MP pour que je regarde si ça répond à mon besoin ?

Merci d’avance !

Du coup je refais une demande en assistance technique, c’est bien ça? Je copie la classe directement dans le message?

Oui c’est ça pour que je regarde car chez moi j’ai dû push pour les entrée/sortie de l’ipx800 vers jeedom avec le code stable donc sans modification… De mémoire ya même l’URL a mettre dans l’ipx800 sur jeedom donc je comprends pas trop ce que fait la modification de plus

Par défaut l’API actuelle ne permet pas de remonter l’ensemble des états d’un type d’info en un seul push. Tu es obligé de faire autant de push que d’entrée à mettre à jour et le nombre de push et de scénario est limité sur IPX…
Par ailleurs, dans l’API actuelle, plutôt que de travailler sur les id de commande, je trouve qu’il est plus pratique de rester sur les noms des entreés vu côté IPX…
Ca reste plus lisible de voir un D1 ou VO1 ou R1 dans l’URL que l’IPX doit générer plutot que chercher l’id de la commande sous Jeedom…
Je renvoie ca…

Je dois pas comprendre chez moi j’ai un push pour tout entrée/sortie et tout sans envoi de l’entrée ou de la sortie. L’ipx800 dit juste j’ai une nouvelle info et jeedom se débrouille pour mettre à jour tous ce qu’il faut

Justement, à quoi bon demander à Jeedom d’aller chercher les infos puisque l’IPX peut les envoyer en direct quand il prévient Jeedom qu’il y a du nouveau!!?
En plus du polling régulier que Jeedom peut faire , tu charges encore plus l’IPX en lui demandant 4 pages complètes (‹ R ›, ‹ D ›, ‹ PW ›, ‹ XENO ›) alors qu’il y a peut être qu’une seule variable qui a changé…
Pour avoir pas mal discuté avec GCE, un polling trop agressif vers l’IPX peut provoquer des erreurs sur les JSON qui sont retrournés (JSON tronqués…)

Oui, actuellement avec l’url push fournie dans le plugin, on demande à jeedom de récupérer les infos.

Avec la methode Inclure des étiquettes dans les notifications (mail, push et GSM), les infos sont envoyées directement par l’IPX du coup c’est plus réactif.

Ok perso j’en ai 4 chez moi qui contrôle toute la maison depuis plus de 3ans et j’ai jamais eu de problème avec la méthode actuelle alors qu’elle se déclenche a chaque lumière qu’on allume ou qu’on éteint sans compter les sondes de température et autre

Alors imagine quand tu as une quinzaine de capteurs de mouvements, des sondes XTHL, que tu commandes toutes les lumières soit avec du X8R, soit avec du XDIMMER…

A non non pas d’extension sauf pour les volets. J’ai 3 ipx800 pour toute les lumières de la maison et oui doit avoir une quinzaine de xthl aussi et ya l’arrosage aussi sur un autre ipx800 sans compter l’alimentation des caméra et d’autres truc que j’ai oublié

moi j’ai un IPX800, un X24D, 4 XDIMMER, 3 X8R, 2 X4VR et 1 RT2.
Bref, si tu veux pas faire évoluer l’API alors que le boulot est déjà fait et que tu peux la proposer en beta, c’est dommage pour la communauté.
Je vais pas me battre pour ca! :grin:

J’ai pas dit ça je vais le faire tkt pas je veux juste bien comprendre c’est surtout ça je vais pas diffuser un truc chez des centaines d’utilisateur sans comprendre…

normal! après si tu veux que je reprenne le code sur des points qui te parraissent louches, hésite pas! Je suis pas codeur de formation mais comme beaucoup ici, je bidouille un peu…

Je viens de tester le code de Pierro,

La remontée d’info est instantanée et je ne remarque pas de différence notable de réactivité par rapport à mon système actuel (1 push par entrée).

Je vais voir si je le mets en prod car ça apporte vraiment un plus sur la facilité de config.

Ce qui me chagrine, c’est que j’ai déjà modifié le plugin deconz pour pouvoir piloter les groupes, et modifier les plugins de mon côté rajoute de la maintenance lors des mises à jour officielles.

Loïc a déjà une todo list longue comme le bras, donc à mon avis si intégration il y a, ça ne sera pas pour tout de suite…

Merci Pierro pour le boulot :slight_smile:

Pour information j’ai testé et ca semble ok ca passera donc surement dans la prochaine stable (si j’ai le temps de faire la doc)

1 « J'aime »

Attention, je t’ai renvoyé un mail car une erreur s’est glissée dans tes modifs…
Je t’ai renvoyé la ligne à corriger