@Jeremy_GCE
Bonjour, il est possible de générer un publish mqtt général à chaque fois qu’il y a un changement d’état dans l’ipx800v5 pour pouvoir piloter la totalité de l’ipx800 depuis des requêtes http via les api plutôt que de devoir le faire régulièrement pour avoir un état des IO de l’IPX800 dans une appli externe ?
Si oui comment ? si non serait-il possible de l’integrer dans une future release ( par exemple ajouter un coche « envoyer un publish a chaque changement d’état » avec un intervalle de temps configurable pour pas saturer l’ipx800)
Bonjour
Ça rejoint une idée que j’avais déjà soumis. Ça serait vraiment une évolution qui changerait la donne et décuplerait les possibilités de l’lipx800 et l’intégration avec d’autre module domotique.
Exemple on pourrait faire interagir l’ipx800 avec des esp (qui eux au passage y arrivent sans soucis a faire de l’envoi Mqtt pour chaque événement sur les sortie/entrée… Un comble quand on voit la différence de prix)
Bonjour,
l’ESP n’a pas autant d’entrées/sorties que l’ipx et ses extensions, la comparaison n’est pas possible.
effectivement, la trame MQTT est légère sur le réseau, mais la construction de la trame ne l’est pas forcément pour le processeur. Je pense qu’il faut vraiment blinder, comme déjà dit du coup dans le sujet qui fait doublon.
La je suis pas d’accord par défaut un esp32 à 34 GPIO, si tu enlèves les 4 pour le réseaux ca en laisse 30. Un ipx800v5 en à 28 donc on est sur le même nombre. Sachant qu’un esp32 est compatible i2c tu peux en plus en rajoutant autant que tu veux (et je parle même pas du futur esp32 qui a de mémoire 54 ou 56 GPIO pour un prix inférieure à 5€…).
donc il ne faudrait pas prendre les x-24D, X-8R, x-8D, X-Pool et autres extensions ?
pour rappel : 28 +10 X8R, 6 X-8D, 4 X-24D, soit 252 IO physiques pour le moment, sans compter celles qui sont sur des extensions comme le X-Pool.
Donc c’est bien ce que je dis, il va falloir blinder.
non, les adressages I2C sont limités.
Avez-vous testé les performances d’un ESP32 avec un max de GPIO extenders ? connaissez vous ses performances lorsqu’il doit envoyer la trame MQTT OnEvent complète ?
Dire que c’est possible, je suis d’accord, dire que c’est léger et que l’ESP32 ne peine pas et qu’il peut continuer à faire autre chose pendant ce temps, là je doute fortement En tout cas l’ipx doit assurer des tâches en continu, faire tourner son moteur de scénarios, …
Quand on voit les longs temps de réponse du serveur web embarqué de l’ESP32, j’imagine mal lui demander de lancer des requêtes à tout va.
Je me permets de le redire, comparer l’ipx à un ESP32 n’a pas de sens.
Pour conclure mes propos, je ne dis pas que c’est impossible avec l’IPX800 d’envoyer une trame complète en MQTT sur OnEvent, je dis juste que ça doit être blindé.
Pour rappel, dans un programme, tout traitement sur interruption doit être le plus court possible afin de ne pas figer le programme entier.
L’addresse I2C est limité certe mais au final on pourrait a mon avis avoir autant de GPIO que sur un IPX800. Et quand on voit le nouvel esp32-p4 je doute qu’il soit léger (dual core a 400mghz quand meme sans compter les little à coté).
Pour moi la comparaison est valable car je pense que l’ipx800 est (enfin je l’espere) plus puissant qu’un esp32.
Et je pense que GCE pourrait ajouter le onevent mqtt c’est 10 fois plus leger que le onvent http (surtout si c’est du https) et l’ipx800v4 faisait sans soucis le onevent http… Et surement pas pire qu’un pull toute les secondes pour connaitre l’état de l’ipx
Bonjour @fgtoul,
D’un coté, je ne suis pas sur qu’il y aurait tant d’événements que cela en tout cas dans le cas d’une automatisation domotique à moins de jouer le scénario jour/nuit /jour/nuit/etc du film « Les visiteurs » !!!
D’un autre coté, il doit pouvoir être possible de simplifier l’envoi, effectivement ce qui est demandé c’est d’avoir un retour de l’état externe des IO des modules GCE pilotés par l’IPX800V5, il s’agit donc juste d’avoir une trame par module par exemple pour l’ipx800V5 en se basant sur l’API on a
l’Id de l’IPX800V5: 9437184 puis l’état des IO que l’on peut ramener à un état binaire sur 28 bits car ce qui importe c’est juste savoir quelle IO a été modifiée
« ioDInput »: « off », « off », « off », « off », « off », « off », « off », « off »
« ioRelays »: « off », « off », « off », « off », « off », « off », « off », « off »
« ana_IPX_Input »: 0, 0, 0, 0
« ioCollInput »: « off », « off », « off », « off »
« ioCollOutput »: « off », « off », « off », « off »
Si on transcrit l’id puis les 28 bit en hexa, ca fait des trames mqtt toute petites, l’IPX800V5 devrait pas être saturé non, en rappelant qu’on est en présence de domotique donc des événements pas si fréquents et au pire il faudrait pouvoir décider dans une page supplémentaire quelle IO doit générer une trame de changement d’état ?
On doit pouvoir dériver ce mode de fonctionnement pour les états des autres modules sans que cela impacte tant que cela les performances de l’IPX800V5 !
je me suis sans doute mal fait comprendre.
Je ne parle pas de la lourdeur de la trame, mais du temps « Processeur » à extraire les états (requêtes sur BDD) et construction de la chaîne.
Je rappelle par exemple qu’un Get=ALL était possible sur V4, à condition de ne pas en demander trop souvent.
Je pense que dans le cas du OnEVENT en MQTT, ce sera pareil.
Ce n’est qu’un avis et @GCE tranchera.
voilà nous sommes exactement dans ce que je décrivais dans un autre post : nombre d’entre vous souhaite des fonctions nouvelles ou des modifications de fonctions, selon leur besoin.
Ce qui est génial, c’est que grâce à ce forum, vous êtes en dialogue direct avec le BE du constructeur.
Ce qui est frustrant est que GCE est obligé d’arbitrer entre toutes les demandes et de prioriser ce qui est important : corriger les bugs, créer de nouvelles extensions, puis ajouter de nouvelles fonctionnalités qui répondent à la demande du plus grand nombre. Et ce n’est pas parce que tel objet à 5€ le fait que c’est ou facile ou pertinent de le faire.
Donc continuez à demander de nouvelles fonctions, c’est ce qui fait vivre le produit, mais acceptez qu’elles ne soient pas (tout de suite) implantées.
Je suis toujours surpris par ceux qui voient toujours ce que ne fait pas un produit, en occultant toutes les autres fonctions utiles.
Concernant la V5 c’est quand meme un peu plus complexe que l’envoi d’un packet de quelques octets en hexa :). Les ressources sont dynamiques donc ils faut les affecter à MQTT, les surveiller en cas de suppressions et bien sur gérer les événements associés a chaque IO… Bref ce que vous faites en 3 minutes avec un ESP parce qu’il va faire que ça sur 10 IO, sera forcément plus long dans un noyau temps réel, multitâche qui gère 65536 IO. ça se fait bien sur, mais pas en quelques minutes ni quelques heures…ni n’importe comment !
C’est ce qui explique aussi la différence de prix car le code est écrit par des personnes qui travaille en France et que vous pouvez contacter en cas de soucis.
J’ai noté la demande, c’est une bonne idée mais on va prendre le temps qu’il faut pour y réfléchir.
Justement, sur la V4 il faut interroger fréquemment pour savoir si un changement d’état des IO s’est effectué ce qui génère du temps processeur de toute façon alors que là c’est l’IPX800V5 qui signifie à l’extérieur qu’il y a eu un changement d’état donc une utilisation processeur moindre !
Pour simplifier, on se retrouve avec 3 mode
1 er mode :
toute « l’intelligence » est gérée par l’IPX800V5 (pas de nécessité d’envoi d’état)
2 ème mode :
Une partie de « l’intelligence » est gérée par l’IPX800V5 et une autre partie par une solution externe type Jeedom, HA, Gladys (nécessité d’envoi d’état partiel ou total )
3 ème mode :
Toute « l’intelligence » est gérée par une solution externe type Jeedom, HA, Gladys (nécessité d’envoi d’état total mais du coup l’IPX800 n’a plus de scénarios internes à gérer donc soulagement du processeur)
Comme seule GCE sait comment la mayonnaise est montée dans l’IPX800V5 eux seuls peuvent déterminer ce qui est possible ou pas mais une chose est sure…des produits ouverts génèrent plus d’intérêts pour plus d’utilisateurs potentiels par exemple le plugin IPX800V5 sur Jeedom est un vrai plus (notamment couplé au module Heliotrope pour la gestion des volets) !
faire un get des io et ana toute les secondes à l’ipx800 (cas plugin jeedom et HA)
que l’ipx800 envoi une info mqtt lors de changement. A ce niveau GCE pourrait même pousser encore plus le truc en envoyant une trame mqtt en retain dans le topic homeassistant pour de l’autodecouverte. Comme ca plus de conf ou de plugin pour homeassistant, et pour jeedom prochainement aussi (l’auto découverte est en beta pour le moment).
Tout l’interêt est là, j’ai longtemps réfléchi aux solutions possibles (des fabricants comme Denkovi etc) au DIY (des cartes pas chères gérable en wifi ou ethernet mais quid de la sécurité et la prise en charge en cas de sinistre ???) et suis arrivé à la conclusion que la meilleure solution en termes de rapport qualité/prix était les produits GCE donc on paie un prix pour un produit mais aussi pour un service avant vente, pendant vente et après vente ! On peut échanger avec l’équipe en cas de problèmes et demander des améliorations qui quand elles sont possibles ou intéressantes sont intégrées ! D’ou l’utilité d’avoir un échange via ce forum avec GCE, pouvoir suggérer des améliorations auxquelles GCE n’aurait peut-être pas songé (c’est l’intérêt de GCE) et par ce biais avoir au final des produits au plus près des clients/usagers (c’est notre intérêt) !
Ce qui est cool aussi, c’est que cette fois le sujet génère plus de réactions et de discussions
Après, on peut faire avec les liens mais cela serait tellement plus pratique si était implanté en natif.
La comparaison entre l’IPX et un esp32 n’a pas lieu d’être. Je trouve cela très réducteur pour @GCE
@Adrien_GCE : peux tu jeter un œil sur le PR de Loïc ? S’il a la solution cela serait vraiment top
@GCE
Au pire, dans le code juste mettre une variable générale à 1 chaque fois qu’une IO est modifiée (je suppose dans la procédure de code qui active ou désactive ou interprète l’IO interne ou d’un module externe) ensuite il suffit de faire une interrogation dans une boucle générale en parallèle toute les x millisecondes de cette variable et si elle passe à 1 générer un mqtt pour indiquer « il y a un changement d’une IO » et remettre la variable à 0.
Comme cela il y a juste à permettre à l’utilisateur de paramétrer « activer la génération de changement d’état dans un mqtt » et le x milliseconde d’interrogation (avec une valeur mini pour pas saturer l’IPX800V5)
Ensuite l’utilisateur n’a plus qu’a s’abonner à ce publish de changement d’état de l’IPX800V5 et interroger en conséquence si il le veut pour savoir quelle IO est modifiée (dans celles qu’il veut surveiller) par rapport au précédent envoi (bien sur il stocke en externe dans jeedom ou autre l’interrogation précédente pour pouvoir comparer !)
On a ainsi une utilisation minimale du processeur et le déport du traitement à l’extérieur !
En tout cas l’ipx doit assurer des tâches en continu, faire tourner son moteur de scénarios, …
On peut échanger avec l’équipe en cas de problèmes et demander des améliorations qui quand elles sont possibles ou intéressantes sont intégrées ! D’ou l’utilité d’avoir un échange via ce forum avec GCE, pouvoir suggérer des améliorations auxquelles GCE n’aurait peut-être pas songé (c’est l’intérêt de GCE) et par ce biais avoir au final des produits au plus près des clients/usagers (c’est notre intérêt) ! 
