dans serveur, tu dois mettre l’adresse IP locale du home assistant, du genre 192.168.1.123
Forcément locale ? Mon HA est en SSL derrière duckdns, mais du coup le http est désactivé et à mon avis les appels API seront rejetés sur https://192.168.1.xxx vu que le certificat est émis pour le domaine duckdns non ?
Sur postman en tout cas, le push marche très bien vers l’url duckdns mais ne fonctionne pas avec l’IP locale (cause : certificat émis pour *.duckdns.org donc invalide pour 192.168.1.xxx)
duckdns et le ssl c’est pour les appels depuis internet, là logiquement tu es sur le même réseau local, donc l’ipx800 doit accéder à home assistant sur le port 8123 en local
On y accède en local, mais pas en http. Seulement en https. Or le certificat n’est pas émis pour l’ip locale mais bien pour les appels internet. Donc voila les tests (effectués depuis postman) :
- Si je push en http, vers l’ip locale ça ne répond pas (car HA n’écoute pas en http)
- Si je push en https, vers l’ip locale, ça répond erreur SSL : certificat invalide (ce qui est logique)
- Si je push en https, vers l’adresse internet, ça répond “OK” et ça fait bien l’action dans HA.
Hormis via API, le comportement est le meme si j’essaye juste d’ouvrir ma page HA : en http vers ip locale ça n’affiche rien, en https vers ip locale j’ai un warning comme quoi le certificat ne correspond pas au site affiché, et en https vers adresse internet c’est tout propre.
Je sais pas si je suis plus clair 
Merci
c’est clair mais je comprends pas pourquoi avoir désactivé le http ? il vaut mieux laisser la configuration http de base pour home-assistant, sur le port 8123, et ajouter l’add-on nginx qui écoute lui en HTTPS avec ton certificat, du coup tu exposes le port 443 sur internet, et le port 8123 est juste en local pour communiquer avec l’ipx par exemple
Oui j’ai pas réellement choisi de désactiver le http 
ça s’est fait tout seul quand j’ai installé le certificat…
Je vais essayer d’installer l’add-on nginx pour mieux gérer ça et ne pas avoir HA en unique point d’entrée en effet. Mais bon je maîtrise pas trop ces sujets network donc ça me prendra du temps… En attendant je suis condamné à attendre 60 secondes entre le moment ou j’appuie sur l’interrupteur et le moment où la lumière s’allume du coup .
Pour mon info, est ce que ça veut dire que l’IPX ne sait pas push en SSL ? Parce que y’a pourtant l’option “SSL” sur la config du push, et il me semble même avoir des push fonctionnels vers google assistant et Telegram… Je ne m’explique pas pourquoi ça ne marche pas avec la config actuelle…
Merci, je te tiens au courant quand j’ai fait le setup pour écouter en http.
SB
Hello @Mati24 !
Je viens aux news après avoir désactivé let’s encrypt côté HA, installé NGINX Proxy Manager (une tuerie cet add-on au passage ! Super bien fait !) et exposé tout ce bazar en proxy host + règles de routage.
Après j’ai modifié mon push sur l’IPX en http et sur l’ip locale et… ça marche !
C’est fou quand même non ? l’IPX n’arrive pas à gérer un flux HTTPS dans les pushs ?
Enfin bon, en tout cas c’est cool : ça fonctionne 
Par contre est-ce que tu peux me dire si ton API gère le l’envoi “all” ? (exemple : dataR=$R qui envoie l’état de tous les relais)
Cf. doc : API V4 — GCE Electronics
Je me dis que ça doit être possible puisque la config yaml IPX précise déjà l’ID du relai côté HA, donc si l’api reçoit dataR=00101100 alors les relais 3, 5 et 6 sont “ON”. Qu’en penses-tu ?
Bon en tout cas merci beaucoup pour ton intégration, qui fonctionne au top, pour ton aide et ta disponibilité sur le forum ;). Je suis bien content d’avoir découvert HA parce que je devenais un peu limité avec mon IPX
A la prochaine !
Super, bonne nouvelle
Ils pourraient ajouter une option pour ignorer la vérification du certificat en effet, mais le cas est assez rare ça ne doit pas être une priorité
Il faut que je retravaille sur la partie du PUSH pour être plus sécurisée, et que je puisse ensuite l’intégrer à HACS voir Home-Assistant directement, je vais voir pour gérer le all, mais de mémoire c’était pas si simple de retrouver les entités à partir des id, je mets ça sur ma TODO list 
Ah oui c’est vrai je voulais t’en parler : c’est carrément dangereux que ça soit open-bar pour la mise à jour de l’état de l’IPX imaginons le use-case suivant :
- j’ai un inter mural connecté à l’IPX
- sur un switch de cet inter mural, j’ouvre la porte du garage dans HA
Dans ce cas là, un appel externe non sécurisé peut déclencher l’ouverture du garage OKLM ^^
L’idéal serait de restreindre l’accès à l’API à une IP source (ie : l’ip locale de l’IPX) voir même de gérer un token mais je suis pas sûr que l’ipx puisse manipuler des tokens, je n’ai vu que du login/pwd.
Tu as une idée de la solution que tu souhaites mettre en place ?
SB
Au moins login/pw mais plus si possible
Par contre est-ce qu’il est nécessaire que tu fasses remonter l’état de ton inter mural dans HA ?
C’était un exemple théorique (que je n’ai pas implémenté chez moi), mais j’ai exactement le même fonctionnement avec un dimmer wifi de chez Tuya :
- mon inter est cablé à l’IPX
- HA contrôle mon dimmer TUYA
Quand j’actionne l’inter, son état remonte dans HA via le push, et une automation “switche” l’état du dimmer on/off
C’est pour ça que j’avais absolument besoin du push, sinon c’était un peu long d’attendre que HA veuille bien poll l’IPX
Ah ok je pensais que ça pilotait un appareil sur l’IPX, du coup oui le push est indispensable, et pour l’instant il faut mettre le nom de l’entité avec son id
Par contre pour le push de tous les états d’un coup, j’ai pas trouvé de solution pour récupérer les entity_id depuis la conf, du coup pour l’instant pas possible
Salut a tous
Désolé de réouvrir le topic mais je m’arrache les cheveux.
J’ai suivit la procédure de @Mati24.
Mon configuration.yaml est comme ca :
# Text to speech
tts:
- platform: google_translate
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
sensor: !include sensors.yaml
ipx800v4:
- name: IPX800
host: "192.168.0.XX"
api_key: "apikey"
port: "XXX"
username: "XXXX"
password: "XXXX"
devices:
- name: Lumière terasse
type: relay
component: light
id: 6
Cependant j’ai le message d’erreur suivant
[custom_components.ipx800v4] Cannot connect to the IPX800 named IPX800, check host, port or api_key
J’ai essayé en enlevant les " ", différentes configuration mais toujours le meme message d’erreur.
Je précise que je suis nouveau sous home assistant, que je teste sur une VM avant de migrer de jeedom.
Merci pour votre aide!
Essaie de stopper Jeedom le temps du test
merci pour ta reponse rapide.
Ca fonctionne maintenant : j’ai viré le port du fichier configuration, re-booté et avec un peu d’attente les equipement remontent…
Merci pour cette integration!
Plus je manipule HA et plus j’ai envie de migrer de jeedom a Home Assistant; qui a l’ai d’etre franchement puissant…mais complexe à manipuler!
Petite question subsidiaire
J’ai un compteur d’eau a impulsion relié a une entrée digitale de l’IPX. J’ai un virtuel sous jeedom qui me fait le calcul.
Je ne sais pas comment faire la manipulation pour recuperer les impulsions sous HA et faire les calculs de consommation…
tu as dans l’IPX des compteurs que tu peux ajouter sur home assistant après
Oui j’ai vu ca.
J’ai l’impression qu’il y a 2 manières de proceder :
-laisser l’ipx compter
-remonter uniquement l’etat du capteur dans HA et laisser HA faire le boulot.
Le probleme c’est le taux de rafraichissement…
il faut le faire côté IPX car pas besoin de mettre de push ou autres pour avoir la données en réel, de plus Home-Assistant est amené à redémarrer assez régulièrement (update, changement de conf…) du coup tu vas te retrouver avec un écart, du coup tu remontes que le compteur dans HA, que tu appelles depuis un sensor template de type total_increasing, que tu auras ensuite dans ton dashboard énergie