Connecter zwavejsui en module complémentaire d'un autre HA

Bonjour,

J’ai zwaveui qui tourne via un module complémentaire sur un HA.
Je souhaite monter en // un autre HA.
Je n’arrive pas à connecter le module zwave à ce nouvel HA.
Je pense que je n’ai pas la bonne URL pour ls WS.
Sur le HA qui porte le module j’ai ça :
ws://a0d7b953-zwavejs2mqtt:3000
Ce nom de machine n’est pas résolu bien entendu sur mon réseau.
J’ai tenté de le remplacer par l’IP privée de la machine qui porte le module mais sans succès.
ws://192.168.1.240:3000
Une idée ?

Salut,

Regarde ça :

Merci @Pulpy-Luke.
Par le passé, j’avais zwavejs en externe aussi (sur une VM dédiée) et j’ai un utilisateur très satisfait de ton addon ! (merci encore au passage).
Mon souci est plus dans l’intégration des entités zwave sans mon HA secondaire.
Donc dans le paramétrage du zwave dans le 2ième HA :

1 « J'aime »

il faut configurer l’addon (le 2ème) pour exposer le port 3000

Et coté proxy, il faut utiliser l’ip de la machine+port

Pas sûr de bien comprendre.
Pour qu’on parle des mêmes machines, on va dire :
HA1 : mon home assistant principal qui porte le module complémentaire ZWAVEJSUI.
HA2 : le home assistant secondaire sur lequel je veux importer les appareils/entités zwave.

A date, le module complémentaire n’est déployé que sur HA1.
Sur HA1, j’ai le zwave qui pointe dessus et qui fonctionne très bien. (en ws sur le port 3000)

Tu me dis que je dois déployer le module complémentaire sur HA2 aussi ?

Tu as 2 choses à faire :

  • le fait de remonter les infos de HA1 vers HA2 c’est par le MQTT que ça doit se passer. Le HA2 doit aller chercher les données sur le MQTT sur lequel le HA1 envoie les états.
    Par défaut l’option MQTT n’est pas activée/indispensable au sein de HA1.
  • pour piloter le zwavejsui de HA1 sur HA2 , il faut configurer le proxy

Alors j’ai bien activé le mqtt et websocket sur le HA1 mais à date, je pense ne me servir que du ws sur le HA1.
Je récupère mes appareils sur l’intégration zwave (et non pas mqtt) sur HA1 grâce à ws.
J’aurai aimé faire pareil.
C’est possible ?

A mon avis, c’est pas une bonne idée (j’ai pas testé) mais la partie WS, c’est pas uniquement la remontée des infos, c’est aussi toute la partie controle/config…
Généralement 2 contrôleurs pour un seul service, c’est rarement idéal pour savoir qui a raison en cas de différence.

Je veux piloter en effet mes modules zwaves depuis HA2 aussi. (Sans passer par le remote HA.)
Je remonte une nouvelle instance en partant de 0 car mon HA1 est devenu surper leeeent et limite instable à force de jouer avec.
Mais vu tout ce que j’ai et que ma maison tourne sur HA1, je ne veux pas tout couper et tout remonter sur HA2 brutalement.
Je ne vois pas pourquoi avoir 2 ws poserait souci (en tout cas pas des gros), le dernier qui parle à raison dans ce cas. Et puis c’est juste l’histoire de quelques jours (on peut toujours rêver).
Pas d’idée de comment me connecter ou de ce qui bloque pour établir le ws de HA2 vers HA1 ?

C’est pas juste une question de qui parle le dernier… Si tu as des actions régulières (toutes les 5 minutes), ça double les actions au final (un refresh du status par exemple). Et si ce sont des actions contradictoires, tu vois vite le bazard…
La solution c’est de passer par MQTT (transitoire ou nom), tu peux essayer de te bricoler une solution autrement, mais c’est sans garantie et avec les risques potentiels. Et ça c’est en supposant que ce soit techniquement faisable.

Mouais, dis comme ça je ne suis pas convaincu de ce choix. J’aurai plutôt tendance à essayer d’identifier que qui fait que c’est lent, pour, à minima, éviter de le reproduire sur le HA2. Et encore mieux le corriger sur HA1 directement sans avoir à tout basculer.

Je suis d’accord avec toi et je préfèrerai ne pas avoir à tout refaire. J’ai fait pas mal de tests et je ne comprends pas ce qui cause ce comportement erratique. Il n’y a pas bcp de choses à voir sur HA lui-même.

  1. Les logs pour y trouver les erreurs
  2. Les charges CPU pour y trouver les consommateurs de ressources
  3. Les automatisations pour y trouver les trucs qui tourne 10 fois pour faire la même chose
  4. Les dashboards pour simplifier les structures, et optimiser le code
  5. Le recorder pour éviter de mettre 1000 trucs inutiles dans la BDD

Il n’y a pas de raison que certains arrivent à avoir un truc qui tourne aux petits oignons et pas toi