Ipx800 + X-4VR intégration Home Assistant

j’ai trouvé ça :

Le problème est que les fichiers sont dans un container docker.
J’arrive avec la commande

docker exec -it homeassistant /bin/bash

Ensuite

cd /usr/local/lib/python3.7/site-packages

Les commandes ci-dessus ne fonctionnent pas non plus.

Par contre, pour me connecter en SSH, j’ai installé l’Addon « server SSH » :

Et une ligne m’interpelle :
## Known issues and limitations

  • This add-on will not enable you to install packages or do anything as root.
    This is not working with Home Assistant.

Ca ne viendrai pas de là ?

Hormis ce package, je ne vois pas comment me connecter en SSH à Home assistant

Bonsoir,

j’ai fait quelques modifs pour les dépendances. Il faut récupérer la dernière version du custom_component sur Github et celui-ci devrait charger les modules dont il a besoin.
J’ai essayé avec un HA vierge et ça fonctionne. J’espère que ça ira aussi sous Hass.io
Merci de me dire ce que ça donne.

Salut

Désolé pour le retard, mais comme toi, je ne recois plus les notifs :frowning:

Je ne vois pas de « custom_component » sur ton Github…

c’est le projet HA_ipx800 à copier dans le dossier custom_components

Salut

J’ai donc créé un dossier « ipx800 » dans « custom_components » et copié le fichiers HA-ipx800 de ton repo, mais j’ai ce message en vérifiant la config:
« Component error: ipx800 - Integration ‹ ipx800 › not found. »

(J’ai bien les droits en lecture/écriture sur ce dossier)

Salut,
désolé pour le temps que ça m’a pris pour faire fonctionner un HA en virtualisé dans virtualbox.
J’ai installé le custom_component et j’avais le même problème.
En fait HA n’arrivait pas à se connecter à internet à cause d’un problème de DNS.
Au démarrage de HA il faut se logger en root puis taper « dns stats » qui doit répondre avec des infos et pas une erreur. Si c’est en erreur comme chez moi j’ai tapé « dns update » qui renvoi Processing…Done puis le « dns stats » qui donne son status.
J’avais d’ailleurs aussi la carte météo qui ne fonctionnait pas, est ce pareil ?

Merci @slashx57,

Juste un petit merci pour ton support et le partage avec la communauté de ton travail. Je pense que je vais réessayer home assistant prochainement vu les avancés côté intégration.

Bonne soirée.

Bonjour,

Pour information, il est possible d’intégrer l’IPX800 avec Nodered et MQTT tout les deux disponibles sur HA (ou en dehors). L’avantage : aucun développement, évolution plus simple et indépendant de HA. Dans Nodered utiliser « UDP Node » pour les PUSH et le protocole M2M de l’IPX800 pour récupérer les infos qu’il faudra parser puis les stocker dans MQTT. Pour rappel, MQTT est un standard gage de pérennité.

Cependant je précise que les Push TCP avec la méthode Post sur l’IPX800v4 ne fonctionne pas. J’ai ouvert un ticket auprès du support et je n’ai pas eu encore de réponse satisfaisante car on me propose d’utiliser la méthode Get qui elle fonctionne. Conclusion, je ne suis pas certain que l’IPX800v4 soit la meilleure solution en terme d’interopérabilité et de pérennité d’autant plus que le code source est fermé contrairement à d’autres solutions.

1 « J'aime »

Bonjour,
nous ne sommes pas au sein d’une organisation produisant de l’open-source, bien sûr que le code est fermé.
En terme d’inter-opérabilité, l’ipx800 ne souffre d’aucun manque majeur, son API est évolutive et permet l’interfaçage avec toutes les box via les requêtes http.

En ce qui concerne la pérennité, je pense qu’il n’y a pas à s’inquiéter :wink: .
Les anciennes versions de l’IPX800 ont plus de 10 ans et sont toujours produites et mises à jour gracieusement par @GCE . Pas sûr qu’il en soit de même dans 10 ans pour HA :wink:
cdt

Bonjour,

Le terme même de pérennité recèle ici une ambiguïté sémantique. Je parle ici de pérennité en terme de capacité aux codes d’intégrer les évolutions en terme de standard. A titre d’exemple, les requêtes HTTP avec la méthode POST ne semblent pas standardisées pour faire du PUSH. Manque de détails techniques sur le fonctionnement même du protocole HTTP (version 1.0, 1.1, entête, SSL/TLS, etc.), pas de logs pour faciliter le diagnostic. Je trouve qui serait intéressant d’avoir une roadmap. Nous n’avons pas d’information (officielle) sur le PIC32 (mémoire, etc.) peut-être est-ce une limite technique.

Après, je vous rejoins concernant la pérennité du produit et de l’entreprise :slight_smile: Concernant l’open source c’est un choix d’entreprise. Beaucoup d’entreprise ont du ouvrir leurs codes ou leurs plateformes pour des raisons de confiance, de pérennité, de dépendance et d’interopérabilité (descendante et ascendante). Personnellement, je reste convaincu qu’à l’heure de l’IoT cela fera une des différences pour choisir un produit. Beaucoup d’IoT ont une base ou des outils Open Source sans toujours le crier sur les toits !

OpenHAB, Domoticz, Jeedom ont 10 ans ou plus. Pour HA, qu’il disparaisse c’est possible … mais le cœur technologique est très intéressant en terme d’évolution et la communauté plutôt importante . Dans tous les cas c’est pourquoi je privilégie le MQTT pour le standard et Node Red (ETL). D’ailleurs, j’ai converti l’IPX800 vers MQTT. MQTT est un M2M standard.

Dans tous les cas votre solution est à code fermé mais bien ouverte en terme de communication par le M2M. Le seul problème immédiat que je rencontre est l’interopérabilité de la fonction PUSH sur le protocole HTTP. J’ai du contourné le problème en faisant du Push UDP (pas satisfaisant).

Cordialement,

Oui, et HoMiDoM a vécu 2 ans malgré une forte communauté opensource.

malheureusement, ce n’est pas ma solution, je suis utilisateur comme vous :wink:

Le code est protégé (« fermé » pour vous) car nous sommes sur des produits copiés.
Cependant, toute demande d’évolution est prise en considération. Vous pouvez contacter le bureau d’études directement par mail mailto:dev@gce-electronics.com

J’avais pas fait attention :wink: Merci pour l’info et l’email dev. Il vrai que l’open source n’est pas une garantie automatique de pérennité. Comme dans tout projet, l’analyse fondamental et technique est important pour la pérennité d’un projet ou d’une entreprise. D’ailleurs, je précise que l’Open Source est un facteur parmi d’autres. Personnellement, je favorise le « modèle économique Open Source » (par forcément gratuit selon de fausses légendes). Il permet souvent d’internationalisé un projet et/ou une entreprise.

Pour le code, il est bien « fermé » mais pas vraiment « protégé » car il peut être décompilé :wink: rien d’insurmontable pour les spécialistes du reverse engineering. Je ne les nommerai pas mais il existe des entreprises et des pays qui sont les champions de la copie industrielle.

on ne va ni jouer sur les mots, ni polémiquer, ni tourner en boucle.
Le code est protégé au sens légal. Le « Reverse Engeneering » est illégal.
On sort du sujet.

D’une part, ce n’est pas de polémiquer que de préciser le sens des mots afin de lever des incertitudes ou des confusions. C’est une discussion responsable, respectueuse et saine que de le faire pour les personnes qui nous lisent.

D’autre part, le « Reverse Engeneering », la légalité est fonction de de la finalité (à ne pas confondre avec la copie). Cette dernière est d’ailleurs enseignée afin de savoir s’il y a eu violation de brevets ( propriétaire ou open source qui est protégé aussi :)), d’interopérabilité, de sécurité (back door : Fortinet, Huawei, etc., failles), atteinte à la vie privée (Apple, etc.), etc.

Nous sommes probablement entrain de glisser vers le hors sujet quand bien même nous parlons toujours d’interopérabilité avec HA (et autres) ce qui peut avoir du sens afin de comprendre le fonctionnement d’un IPX800.

Pour finir, je vous rappelle que ma 1ère intervention était sur l’interopérabilité avec des standards comme MQTT (M2M) et Nodered pour éviter des développements spécifiques aux utilisateurs de ce forum et donc une meilleure pérennité. Dans cette démarche, j’avais souligné un bug gênant avec le Push HTTP et la méthode Post qui est resté sans réponse du support. J’ai sollicité l’équipe dev hier. Je relatais également un contournement par le Push UDP non satisfaisant.

Ceci étant dans l’IPX800 nous n’avons aucune information sur l’implémentation HTTP (en terme de standard) comme (version 1.0, 1.1, Head, SSL/TLS, cipher, etc.) ce qui plutôt gênant quand le sujet est l’interopérabilité autour d’une norme comme le HTTP.

Cordialement,

Bonjour,

Je ne prends pas position sur ce que devrait ou pas faire GCE pour améliorer l’inter-opérabilité de ses produits. Néanmoins je note quelques points intéressants dans votre discussion :

  • GCE peut choisir de limiter l’interopérabilité pour garder l’étiquette « automate / fiabilité » qu’ils donnent depuis le début. En effet être complètement ouvert c’est prendre le risque de voir ses produits vus comme du « bidouillage » plutôt que des solutions « semi-clés en main fiables ».

  • Je trouve important que GCE puisse répondre et /ou trouver une solution sur le POST TCP puisque c’est une fonctionnalité proposée à l’utilisateur. C’est peut être un autre sujet mais perso j’avais aussi rencontré des problèmes avec l’API de ma TV Sony que j’ai contourné par un script PHP sur le NAS mais ça rajoute une étape inutile. Pour mémoire, le push POST sur l’API me faisait redémarrer l’IPX.

  • Sans aucun jugement sur ce que sait faire ou pas faire l’IPX, je trouve intéressant de savoir l’étendue et limitations des possibilités d’inter-opérabilité. J’avais un peu regardé du côté de HA un moment et ça m’avait l’air bien compliqué (plusieurs retours avec des méthodes différentes). Je partage l’avis de j254y et trouve l’approche MQTT la plus fiable et d’autant plus intéressante si c’est implémentable « nativement » au sens d’utilisation de protocole déjà intégrés et reconnus.
    D’ailleurs je t’invite à partager un peu plus de détail sur ce que tu as mis en place car je pense que ça peut intéresser pas mal de forumeur

A+
Jon

Bonjour Jon,

Effectivement, dans ce sens MQTT permettrait de mieux contrôler ce qui est fait par l’automate en se reposant sur un standard. Il permettrai également d’éviter l’ouverture de certain accès directs de l’IPX800 en mode serveur. Je ferme la parenthèse. Voici une capture de mon flow Node Red qui :

Il permet de créer un serveur UDP sur le port 1881 pour intercepter les push de l’IPX800. Cela se déroule d’abord par une authentification (cf. la doc M2M de l’IPX800). Je parse le résultat de la requête pour récupérer le « Success » puis lors de la seconde requête, je récupère le résultat de « Get=D » que je parse pour extraire l’état des entrées le stocker en tant que topic dans le Broker MQTT (Mosquitto pour moi).

Chaque client s’abonne via le message vers le broker : le « topic » (information
de routage pour le broker) qui permettra au broker de réémettre les messages reçus des producteurs
de données vers les clients. Les clients et les producteurs n’ont ainsi pas à se connaître, ne communiquant qu’au travers des topics.

Cette architecture permet à des solutions hétérogènes de communiquer simplement, de façon sécurisée tout en permettant le mode asynchrone pour ne pas perdre un message par exemple (coupure réseau, redémarrage, etc.) => fiabilisation de l’automate.

Il serait possible de supprimer l’étape du Flow Node-RED en intégrant un client MQTT directement dans l’IPX800.

Node-RED (projet Open Source issu d’IBM) est un éditeur de flux fullweb qui facilite la connexion d’équipement tout comme Kura, Flogo, Apache Nifi, StreamSets.

Home Assistant n’est pas obligatoire. HA fonctionne plutôt très bien mais son approche innovante est déroutante car il utilise Docker et Yaml mais très efficace.

Je souligne que cette solution est applicable à toutes les box domotiques pour le peu d’avoir un client MQTT ou une API. Dans ce dernier cas, il faudra passer par Node-RED (ou équivalent). Et pour un terminer un IPX800 pourrait être client et/ou producteur au sens MQTT. Mon flow ne gère pas pour le moment les exceptions et il est aisément perfectible. J’y travaille.

Cordialement,

3 « J'aime »

Bonjour @moicphil,
Je viens aux nouvelles pour savoir si vous avez réussi à faire fonctionner le plugin sur HomeAssistant chez vous ?

Bonjour @slashx57,
Je voulais savoir ce que votre plugin permet de gérer les extensions type X-8R, X-Dimmer ou encore X-24D.

Est-il possible d’avoir une vue du résultat ?

Ci-joint ma config globale.

Bonsoir

J’ai essayé pas mal de choses sans résultats et malgré l’aide de slashx57 (que je remercie au passage). J’ai ensuite baissé les bras pour me concentrer sur autre chose. Je me remettrai dessus dans quelques temps.