Nouveau sur Home Assistant avec synchro d'une eedomus

Bonjour,
Nouveau sur le forum, j’ai Home Assistant depuis quelques semaines. J’ai pris une box green avec une clé zigbee SkyConnect.
J’ai une eedomus+ avec du zwave depuis quelques années. Elle marche très bien mais elle est vieillissante.
Je voulais tester Home Assistant et le zigbee.
Pour l’instant, je garde mon eedomus et j’ai mis une synchro en place pour récupérer l’état de mes appareils et pouvoir les contrôler depuis mon interface Home Assistant.

Mes première impressions :

  • Home Assistant est puissant mais même avec une box green, on est encore loin du « plug and play »,
  • l’interface est moderne mais par défaut (sans HACS et sans taper du code), je trouve que ça manque de possibilités de paramétrage,
  • Homekit marche mieux avec Home assistant (je n’ai pas toujours le retour d’état dans HomeKit avec mon eedomus),
  • je n’ai pas réussi à configurer la connexion avec Alexa (ça se fait tout seul avec mon eedomus et c’est très stable).

Pour le zigbee :

  • ma clé zigate sur mon eedomus ne me donnait pas satisfaction, maintenant ça marche beaucoup mieux mais j’ai des problèmes de portée et de maillage de mon réseau, ce que je n’ai jamais eu en zwave,
  • l’intêret du zigbee est son prix et il a probablement plus d’avenir car il est choisi par de grandes marques mais j’ai des modules zwave de plus de dix ans qui sont plus stables et plus configurables…

Voila pour un premier point.
J’ai pas mal de questions et j’ouvrirai d’autres messages.
Pour ma « synchro » avec l’eedomus, je peux ouvrir un sujet si certains sont intéressés…

5 « J'aime »

Bonjour sbdomo ! Encore un ancien du forum Eedomus qui a migré ? Pour ma part j’ai commencé à batir HA tranquillement qu’avec du Zigbee au début (il y’a un an environ) et là depuis avril j’ai totalement migré le reliquat du Z-wave de ma Eedomus. J’utilise une clef z-wave.me …ça marche super bien, j’ai pu utiliser sans pb et regler les thermostats (têtes thermostatiques Fibaro) et je trouve l’intégration mieux faite que sur la Eedomus. Alors oui de base l’interface est ce qu’elle est (mais déjà je la trouve + joli que la « vieille » interface de la Eedomus). A part quand j’avais imperihome sur une tablette, jamais je n’osais trop montrer celle de la eedomus … :slight_smile:
Je ne me prononcerai pas sur la Zigate qu niveau qualitatif, mais sur HA les SONOFF et Skyconnect (Nabu Casa) sont je crois, celles les plus utilisées. J’utilise la Skyconnect sous Z2MQTT et j’ai zéro pb avec (le maillage se fait très bien y compris pour mon capteur d’ouverture de portail qui est à 30m environ (un aqara mis dans une boite imprimée en 3d) … bon apres j’ai également une clef SONOFF qui potentiellement sert de coordinateur pour les appareils les + éloignés (j’ignore si c’est vraiment utile mais je ne savais pas trop quoi en faire :slight_smile: ). Quant à alexa (ou Google Home) je crois qu’il faut l’abonnement annuel qui te donne également accès à HA depuis l’extérieur en 1 clic (pour moi le top, pas de prise de tête) …et ça contribue au projet Nabu Casa (tout comme l’achat de la clef zigbee Skyconnect) … Enfin, oui HACS est un impératif si tu veux faire des beaux dashboard …les cartes mushroom également et je dirai aussi apex graph pour faire des super graph très facilement … bref …ça ne manque pas de ressource !

3 « J'aime »

Bonjour,
bienvenue sur HACF.

Rebonjour,
Oui, je suis un ancien du forum eedomus.
Pour Alexa, il n’est pas impossible que je finisse par prendre l’abonnement Nabu Casa.
Pour l’instant, j’ai essayé les solutions gratuites. Et ma solution en passant par l’eedomus me convient pour l’instant…
Pour le zigbee, j’utilise ZHA que j’espérais plus stable car intégré à He Assistant. A voir si je change dans le futur…

Salut,
ZHA c’est bien car c’est intégrer directement a HA, mais supporte 3 fois moins de matériel que Z2M ( zigbee2mqtt ). Faut être patient pour l’ajout des nouveaux matériel , contrairement a Z2M ou c’est rapide.
Il manque des options sur les appareils sous ZHA, contrairement a Z2M.

Perso, Z2M au top.

Oui, j’avais vu les avis z2m vs zha pour la compatibilité. Comme je construit tranquillement mon réseau, je n’ai pris que des appareils compatibles. Je verrai si je trouve zha trop limité…

Sbdomo, du coup, tu conserves ta Eedomus en parallèle de HA pour le Z-wave ? Tu vas finir par tout migrer sur HA … :grin:
J’en ai profité pour remplacer certains modules fibaro un peu « usés » (presque 10 ans d’utilisation intense pour l’ouverture de mon portail par exemple) par du zigbee …ça me renforce le maillage par la même occasion …et c’est moins cher. Mais au final j’ai fini par tout enlever de ma Eedomus…et par la vendre récemment … pas besoin d’avoir 2 box qui tournent, HA suffit largement.

1 « J'aime »

Oui, pour l’instant je suis en phase de test et je garde les 2 box.
Pour enlever l’eedomus, il faudrait que je refasse tout mes automatismes et tout reassocier, il y a du boulot. Et pour Alexa pour l’instant je n’ai pas trouvé de solution gratuite sans ma eedomus.
À voir dans l’avenir.
J’ai aussi des Fibaro de plus de 10 ans mais ils marchent toujours sans problème, je les garde. À voir si les zigbee sont aussi durables…

Salut les anciens eedomusiens :grin: ,
ça faisait un bail que je n’avais pas taper « eedomus » dans le moteur de recherche ici.
Je vais donc suivre vos investigations aussi car perso, depuis que j’ai « monté » mon HA je traine les pieds à basculer dessus et mon eedomus reste le « coeur » de ma domotique.
Il va bien falloir que je m’y mette un jour, mais les trop nombreuses exclusions/ré-inclusions à faire me rebutent un peu…

1 « J'aime »

Bonjour,
Oui, on retrouve des anciens du forum eedomus ici…:grin:

J’utilise maintenant Home Assistant comme interface et pour le zigbee mais je risque aussi de garder longtemps l’eedomus pour le zwave et mon RFplayer.
Pour pouvoir utiliser mes modules de l’eedomus dans l’interface de Home Assistant, je n’ai pas eu envie de me lancer dans du Node Red, j’utilise des requêtes http pour synchroniser l’état de mes modules eedomus vers Home Assistant et pour les commander depuis l’interface Home Assistant. C’est rapide et simple à faire.
J’utilise aussi l’eedomus pour Alexa car je n’ai pas réussi à m’y connecter depuis Home Assistant. La cohabitation eedomus et Home assistant marche bien pour l’instant avec l’eedomus qui est devenu une sorte de périphérique d’Home Assistant.

Bonjour,
J étais aussi un fan de l eedomus et je suis passé progressivement a HA en synchronisant dans un premier temps les deux avec node red pour récupérer les statuts de l eedomus et restfull pour envoyer les ordres sur l eedomus
Maintenant j ai tout rebasculé sur HA(Zwave). J ai gardé l eedomus pour me permettre de rebooter à distance mon Rpi5 en cas de plantage de HA lorsque je suis en vacances.
Pour ce qui est du rfplayer je l ai remplacé par ESPSomfyRTS sur HA qui fonctionne à merveille. J ai laisse la clé rfplayer sur l eedomus qui permet de manœuvrer mes stores en cas de panne de HA mais en un an ce n est jamais arrivé.

Bonjour,
Il faudra que je creuse la piste de la solution ESPSomfyRTS. J’utilise le rfplayer effectivement essentiellement pour mes volets Somfy.
Merci pour l’info.
Pour la bascule du zwave, ce qui me décourage, c’est que c’est long à faire et que quand je vais commencer, ça risque de casser mon réseau pour les modules pas encore basculés…

On peut faire la migration zwave progressivement. Les 2 réseaux HA et Eedomus peuvent coexister sans problème.

Je n’ai pas fait de tests mais c’est juste que j’ai une maison assez grand avec des murs en pierres qui me posent des problèmes de portée en zigbee, ce que je n’ai jamais eu en zwave. En enlevant des modules du réseau sous eedomus j’ai peur de créer ce problème de distance entre modules si le maillage devient plus faible.
Je me disais qu’il faudrait que je le fasse par zone…

Bonjour, aller, encore un « presque » ancien d’eedomus. Je suis en cours de migration vers HA et j’avoue que je suis bluffé !
Mais encore novice, j’aimerais avoir vos conseils.

J’ai installé tous les devices (maintenant appareils/entités) ip sur HA et ça tourne en parallèle sans problème.
Pour la migration zwave, j’aimerais préparer le terrain : scènes, automatisations etc. puis migrer tranquillement les micromodules. J’avais envisagé d’utiliser des entrées avec un nom d’entité xxx pour simuler mes modules et tester les automatisations, puis de remplacer les entrées par les entités définitives (même nom d’entité), mais j’ai l’impression que ça va être plus compliqué que ça. Les entités dans HA ont un préfixe qu’on ne peut pas modifier et qui en plus définit les commandes et capteurs …

Avez-vous une idée ? Mon but est de créer toutes mes automatisations avant de migrer les micromodules zwave afin de limiter au maximum le temps de migration.

note : je ne crains pas de mettre les mains dans le code yaml :wink:

merci de votre aide.

1 « J'aime »

Bonsoir herric,

Malheureusement, sauf avis contraire de quelqu’un ici, je crains que tu ne sois obligé de modifier toutes tes entrées à chaque bascule de nouveau module.
Après, concernant le fichier « automation.yaml », tu pourras l’éditer (avec notepad ++ par exemple ou Studio Code Server intégrable à H.A) et rechercher/remplacer en vrac les composants à l’intérieur.

@Fab_Rice alors … avis contraire de moi même après quelques recherches avec LeChat :slightly_smiling_face:

Il est bien possible de simuler les micrommodules zwave en passant par les templates et les fichiers yaml : entrée virtuelle pour stocker l’état, template virtuelle pour simuler l’appareil.
On donnera le même id d’entité virtuel que l’id définitif. Avant d’inclure chaque micro-module zwave dans HA, il suffira de supprimer le couple entrée virtuelle/template virtuel.

Par exemple pour un appareil de type lumière on/off avec un fgs224 de chez Fibaro :

Étape 1 : Définir les entrées virtuelles dans configuration.yaml

Ajouter les entrées virtuelles nécessaires pour simuler le FGS-224 :

# config/configuration.yaml
input_boolean:
  fgs224_relais1_etat:
    name: "FGS-224 Relais 1 (État)"
    initial: off
    icon: mdi:light-switch

  fgs224_relais2_etat:
    name: "FGS-224 Relais 2 (État)"
    initial: off
    icon: mdi:light-switch

Étape 2 : Définir les lumières virtuelles dans templates/lights.yaml

Ajouter la configuration pour les deux relais du FGS-224 dans templates/lights.yaml :

# config/templates/lights.yaml
- name: "FGS-224 Relais 1"
  unique_id: fgs224_relais1
  state: "{{ is_state('input_boolean.fgs224_relais1_etat', 'on') }}"
  turn_on:
    - action: input_boolean.turn_on
      target:
        entity_id: input_boolean.fgs224_relais1_etat
  turn_off:
    - action: input_boolean.turn_off
      target:
        entity_id: input_boolean.fgs224_relais1_etat
  icon: >
    {% if is_state('input_boolean.fgs224_relais1_etat', 'on') %}
      mdi:lightbulb-on
    {% else %}
      mdi:lightbulb
    {% endif %}

- name: "FGS-224 Relais 2"
  unique_id: fgs224_relais2
  state: "{{ is_state('input_boolean.fgs224_relais2_etat', 'on') }}"
  turn_on:
    - action: input_boolean.turn_on
      target:
        entity_id: input_boolean.fgs224_relais2_etat
  turn_off:
    - action: input_boolean.turn_off
      target:
        entity_id: input_boolean.fgs224_relais2_etat
  icon: >
    {% if is_state('input_boolean.fgs224_relais2_etat', 'on') %}
      mdi:lightbulb-on
    {% else %}
      mdi:lightbulb
    {% endif %}

Étape 3 : Inclure les fichiers dans configuration.yaml
Ajouter la section template: dans configuration.yaml pour inclure les fichiers de templates :

# config/configuration.yaml

template:  
  - light: !include templates/lights.yaml

Donc pour le Relais 1, cela va créer une entité virtuelle : light.fgs224_relais1

On pourra ainsi tester toutes les automatisations.

Ensuite, il suffira de donner le même nom a l’entité définitive (après avoir supprimé celle virtuelle bien sûr)

Je vais aller au bout de ma migration en utilisant ce principe et je posterai mes résultats.

Salut herric,
Meilleurs vœux ! :grin:

Ca ne risque pas d’être un peu « long » tout ça, module par module ?

En ce qui me concerne, je préfère à ce jour refaire complètement les automatisations lorsque je décide de basculer des composants de l’eedomus vers H.A, essentiellement parce que :
1- H.A découvre en général plus de données à exploiter
2- Les automatisations sont quand même nettement plus poussées dans H.A (une fois qu’on connait bien sûr)

Salut meilleurs vœux aussi ! :slightly_smiling_face:

Moi aussi je vais reprendre toutes les automatisations pour profiter des avantages de HA.

C’est vrai que c’est du boulot, mais avec les copier/coller dans yaml ca se passe bien.

Le fait de passer par des éléments virtuels me permet de préparer et tester mes automatisations et ainsi minimiser l’interruption de service au moment de la bascule.