Migration jeedom vers HA : conseils pour bien préparer et réaliser sa migration?

[Link953_1]

Mon problème

Bonjour à toutes et tous.

J’ai fait pas mal de recherche pour préparer des points que je pense bloquant dans ma migration mais j’aimerais des conseils d’ancien jeedomien, des alertes sur des problématiques qu’ils ont pu rencontrer et surtout éviter de réitérer de possible erreur. J’ai cherché un « guide de migration », mais pas trouvé

Je suis actuellement sous un jeedom en VM avec pas mal de matos: zigbee (zigbetomqtt), zwave (zwave JS), un ecodevice, 2 aspi xiaomi, des modules bluetooth pour la température, des cameras eufy & netatmo, une station météo également de cette marque, du HUE, robot tondeuse, du google home et homebridge … bref pas mal de matos et protocoles divers.

J’ai également HA en VM sur lequel je test des intégrations, actuellement j’ai timidement déployé les aspirateur ( les maps dans les cards font planter l’appli du constructeur et la map dans mon lovelace), philipps hue, l’écodevice, les cameras, la station meteo et quelques intégrations sympas en + etc…
j’ai rédigé quelques scenarii simples qui ne font pas intervenir zwave, zigbee ou blea.

Je ne vais pas dénigrer jeedom qui me rends pas mal de service mais si je change c’est parceque :
1 développement très lent et technologiquement dépassé.
2 Protocole d’avenir (thread, mater…) toujours pas intégré à jeedom
3 Communauté qui vivote
4 A afficher sur une tablette c’est une horreur et l’appli mobile … ( je ne dénigre pas j’ai dis)
5 Mise à jour qui ne font pas cet effet wahoo
6 j’y trouve de moins en moins d’avantage au fur et a mesure des builds HA

Je souhaite migrer depuis pas mal de temps mais une installation qui fonctionne est dure a migrer. Le temps nécessaire pour basculer me parait quand même important. J’ai plusieurs appréhensions :

• Alertes piles faibles (pas mal de matos sur pile), possible sur HA mais ça a l’air complexe.
• Pilotage des radiateurs simples et efficaces sur jeedom
• gestion des vollets roulant. Actuellement ils s’ouvrent et se ferment en fonction des présence/horaires et données environnementales intérieurs et extérieurs
• les modes de maison : j’ai bricoler quelques choses sur HA qui fonctionne, mais sur jeedom c’est plus simple.
• Si plus de communication avec du materiel sur jeedom je suis alerté, je ne trouve pas comment faire ça sur HA.
• Comment on fait marcher les SMS avec une clée 3G … c’est pas évident
  -Enfin et surtout migrer mon install zigbee (pas beaucoup de matos mais pas forcément accessible) et le zwave (gros réseau) me parait très complexe sans interrompre ma domotique pendant pas mal de temps.

En plus de ces points de blocages, je voulais avoir vos retours sur la façon de procéder (mqtt permet de faire des points entre HA et JEEDOM mais j’aimerai rapidement débrancher ce dernier). Un ordre par lequel attaquer. Est ce que je dois me préparer à mettre des choses en carafe (les habitants de la maison se sont bien habitués à la domotique ) et combien de temps faut-il compter ( a la louche)

Merci.

[pctetra]

Bonjour
J’ai commencé à « penser » à migrer avant l’été 2023, chacun ses méthodes, mais quand j’ai pris la décision, avant toute chose j’ai retravaillé mon jeedom avant la migration.

Pour moi la meilleure façon de migrer était d’utiliser mqtt,
Pour zigbee2mqtt c’était relativement facile puisque le plugin jeezigbee ou zigbeelinker peuvent fonctionner avec un zigbee2mqtt distant, j’ai donc « externalisé » zigbee2mqtt dans une VM

Pour zwave c’est un peu plus compliqué puisque le plugin jeedom zwave-js ne fonctionne pas en mode distant, comme je n’avais pas beaucoup d’équipements zwave, j’ai installé zwave-js dans une VM et migré sur JMQTT dans jeedom

A partir de là ayant un jeedom fonctionnel avec zigbee2mqtt et zwave-js dans des VM externes, c’était relativement facile de migrer progressivement en commencant par installer mosquitto (mqtt broker) dans home assistant et en faisant pointer les plugin jeedom et les VM sur le broker home assistant, après j’ai commencé par migrer les équipements zwave, (moins d’équipements, moins de scenarios)

J’avais aussi fait le ménage dans les scénarios jeedom avant la migration

Ce que je conseille c’est de commencer par les lumières pour se familiariser avec la philo home assistant le dashboard et surtout les automatisations (oublier de raisonner scenarios jeedom n’est pas des plus simple)

J’ai vraiment commencé à migrer en octobre 2023, j’étais opérationnel en deux mois environ, et je considère être complètement à l’aise depuis février - mars (surement moins de temps pour les jeunes)

mqtt comme je le décris est vraiment la bonne méthode pour moi, ça peut paraitre lourd pour certains mais comme j’ai commencé à migrer en prenant ma retraite, ça m’a occupé les mois d’hiver

[Gloup]

@pctetra

Pour zwave c’est un peu plus compliqué puisque le plugin jeedom zwave-js ne fonctionne pas en mode distant, comme je n’avais pas beaucoup d’équipements zwave, j’ai installé zwave-js dans une VM et migré sur JMQTT dans jeedom

Hello
Pas tout a fait d’accord, pour moi la partie Zwave ca a réellement été la plus simple avec pourtant plus de 60 équipements, et ca m’a permis de faire en duo jeedom/HA, le temps de migrer des scénarios vers les automation tranquillement sur le matériel zwave.

En gros dans jeedom, tu te connectes sur ton interface zwave js ui et dans les Settings, section Home Assistant, tu peux activer « WS server ». A partir de là, HA peut travailler en doublon sur les périphériques zwave si tu lui donne pour IP l’adresse de Jeedom.

Le top c’est de mettre pour chaque équipement la « Location » strictement identique au nom de tes pièces dans HA, et de renseigner un nom si ce n’est pas déjà fait, ainsi tout sera bien classé quand ça va remonter.

Ensuite si tu veux faire la bascule ca sera tout simple de mettre zwave js ui sur une VM et de mettre ta clé zwave dessus, puisque tes devices sont associés à la clé.
Il faudra juste avant de penser à faire un backup « Save or load nodes.json file with names and locations » dans zwave js ui de jeedom car ca n’est pas sauvegardé sur la clé zwave.

[ddfdom]

j’ai procédé exactement de la même façon, mqtt en etait la pierre angulaire et je continue de la garder pour la même raison etre décorrélé de HA et pour voir utiliser une autre solution en parallèle ou en remplacement
il m’a fallu 6 mois en prenant mon temps mais en quelques semaines les principaux scénarios étaient migrés (volets et éclairage) jamais meme supprimé mon conteneur jeedom il y’a 3 mois

[pctetra]

oui effectivement pour zwave je l’ai configuré comme ça maintenant, mais je ne savais pas à l’époque de ma migration qu’on pouvait fonctionner en doublon, comme quoi on en apprend toujours
du coup c’est encore plus simple pour migrer

[pctetra]

j’ai gardé jeedom dans un container LXC uniquement pour le plugin Enedis pour mes historiques energie en doublon de ma clé lixee.

[Link953_1]

Bonjour à tous et merci pour vos retours.

Vous confirmer largement ce que j’ai lu et commencé à mettre en place : le MQTT.

Donc si je résume, il faut que je décentralise zwave et zigbee dans un 3 eme VM ( en plus de celle pour HA et JEEDOM) de façon a décommissionner petit a petit jeedom au fur et a mesure que je bascule les scénarios dans HA.
Ca veut dire aussi que techniquement, je vais avoir jeedom ou HA qui vont publier dans un topic MQTT via le brocker distant, mettre à jour l’état et faire profiter de cette mise à jour HA et Jeedom. Est ce que je suis bon ?

Pour zwave, après relecture, la solution de @Gloup me parait la plus simple. dans 1er temps, j’envoi dans HA les devices de jeedom en paramétrant l’interface web de zwave UI, et quand je suis prêt je met une vm avec la conf actuelle de jeedom (et la clée zwave).
Ducoup @pctetra je comprends ta difficulté à l’époque

Est ce que la fonction auto-découverte de HA est possible pour ces 2 protocoles (j’ai découvert ça récemment et c’est génial ! les périphériques arrivent comme par magie)

@pctetra j’utilise également le plugin Enedis. pour mon info pourquoi gardes-tu de l’historique et à quel échelle ?

[Gloup]

Pour ce qui est du zwave, une fois que tu auras installé l’intégration zwave_js et configuré l’ip genre ws://ip_jeedom:3000, oui les périphériques zwave de ta clé vont arriver avec toutes les entités disponibles.

Z-Wave

D’où l’intérêt de bien renseigner avant un nom, et la location strictement identique à ta pièce configurée dans HA, c’est là que la magie opère !

[pctetra]

@Link953_1

j’utilise également le plugin Enedis. pour mon info pourquoi gardes-tu de l’historique et à quel échelle ?

quand j’ai migré sur HA j’ai installé un module TIC lixee sur mon compteur Linky mais je l’ai fait en janvier 2024 avec une mise en service réel en février, il me manque un mois 1/2 sur l’année 2024
je remonte ces données de jeedom via mqtt (lixee me remonte les données en temps réel et jeedom à J-1, comme je remonte les données via mqtt je compare les données)

De plus à priori on a pas trop de possibilité de récupérer l’historique dans la base de données HA, donc j’ai l’année 2023 et 2022 dans jeedom.

Au final il arrivera un moment ou j’arreterai complètement jeedom (mais ça m’a fait tellement plaisir de le migrer en V4.4 et de voir mes icones enedis et virtuel energie doubler de volume sur le dasboard , je blague, j’ai beaucoup apprécié jeedom pendant quelques années )

Le dashboard energie de home assistant est top

[Link953_1]

Je vais bien regarder avant de me lancer le nom et la location. J’ai pas accès a la webui de zwavejs, mais j’imagine que c’est là ou il faut configurer ces infos. De là HA va surement automatiquement me mettre les device au bon endroit c’est ça ?

@pctetra : je te rejoins complétement sur le panel Energie, j’avas une instance ha qui tournait bien avant l’arrivé de cette fonction mais c’est ça qui ma fait vraiment m’y intéressé, imprimé un support tablette et y installer une interface murale avec HA.

Ok du coup comment faites vous la remontée des piles faibles (jeedom permet de paramétrer simplement l’alerte)?
Pour les radiateurs électrique, jeedom et son plugin thermostat s’en sort bien, coté HA j’ai entendu parler de versatile thermostat ( pas sur du nom) qui semble être pas mal.

[pctetra]

@Link953_1

Ok du coup comment faites vous la remontée des piles faibles

tu as custom:auto-entities qui te permet de remonter l’état des batteries sur le dasboard, moi je ne remonte que celles à moins de 10%, il y a un sujet assez complet sur ce forum

Carte automatique pour suivi des batteries

J’ai aussi un peu galéré et en jouant avec le code dans les modèles, j’ai trouvé que c’est cette ligne qui empêche l’affichage: En regardant comment est structuré un de mes sensors ‹ batterie › j’ai vu que je n’ai pas d’attribut battery mais device_class = battery J’ai modifé comme cela: and (state.attributes.device_class == 'battery' and state.state | int < 75 or state.state == "unavailable") [image] En revanche j’ai appris comment tester la présence d’un attribut !! Merci @jerome6994 !…

[Gloup]

@Link953_1

Je vais bien regarder avant de me lancer le nom et la location. J’ai pas accès a la webui de zwavejs, mais j’imagine que c’est là ou il faut configurer ces infos. De là HA va surement automatiquement me mettre les device au bon endroit c’est ça ?

Honnêtement j’ai oublié par ou il fallait passer pour aller a l’interface depuis jeedom, on oublie vite ! Je me souviens que c’est dans le plugin et qu’il y a un bouton pour ouvrir l’interface, avec un message qui te déconseille de le faire !
A vérifier, mais j’ai souvenir que name/location n’est pas renseigné par jeedom, mais qu’ils ont mis un bouton pour envoyer le nom des équipements. Ca peut peut-être une bonne base pour gagner du temps.

Edit
J’ai retrouvé sur leur forum.
Le 4eme bouton pour envoyer les noms et les pièces de jeedom vers zwave js ui si c’est vide. Et le dernier bouton pour aller dans l’interface.

@Link953_1

Ok du coup comment faites vous la remontée des piles faibles (jeedom permet de paramétrer simplement l’alerte)?

Y’a pas mal de sujets qui en traitent sur le forum, même une intégration HACS (battery_notes) qui est pas mal du tout et qui a quelques blueprints tout fait (date de changement de pile en auto, notifications, …)

GitHub - andrew-codechimp/HA-Battery-Notes: A Home Assistant integration to...

Apres c’est à voir, a titre personnel je trouve que c’est totalement foireux la gestion des piles par les modules. Si je prends mon dashboard, j’ai ça :

Ils sont a 0% depuis 6 mois au moins, mais ça fonctionne tjs parfaitement… A contrario, j’ai déja eu des 90% HS.
Perso je suis maintenant parti plutôt sur une automation qui me notifie si un capteur sur pile n’a pas communiqué depuis x heures. C’est un truc que je faisais aussi sur jeedom.

[pctetra]

@Link953_1

J’ai pas accès a la webui de zwavejs, mais j’imagine que c’est là ou il faut configurer ces infos

http://ton_ip:8091 celle de jeedom s’il est intégré à jeedom mais avec :8091

Login : admin
Mdp : zwave

[oldneef]

Je suis dans la mème situation que toi mais un peu plus avancé…
pour moi :

• jeedoom sur rpi3 depuis 5ans RAS
  -HA en docker sur un NAS, (car la VM m’utilisais beaucoup trop de ressources proc)
• pour le zigbee pas de pb comme on te l’a conseillé plus haut zigbee2mqtt sur docker pour moi avec mosquitto, une fois la clé reconnue ca roule nikel, la colalboration avec jeedom ne pose aucun pb.
  -pour les piles j’ai trouvé un bluepirint :
  Low Battery Notifications & Actions
  ça fonctionne tres tres bien, les piles de tout mes sensors ont été reconnue par HA à l’intégration
• pour les verifications de matériels critiques aussi un blueprint :
  Monitor the state of an appliance - by leofabri ca fonctionne tres bien chez moi.
• pour la gestion du bluetooth, senor et NUT, donc le fameux plugin BLEA sou jeedom , y’a longtemps que je l’ai viré et remplacé par l’excellent soft sous esp32 openmqttgateway mes passerelles ont été reconnu en 5s et le tout opérationnel en 3 minutes. Les nut, ici tracker ont été reconnu et intégré dans l’outil de présence en deux deux. j’ai suivi ensuite un tuto ici, pour gerer plus finement la presence…
• pour les volets roulants c’est mon chat noir, j’utilisais le plugin « gestion de volets » sous jeedom, pour moi il a pas d’équivalent sous HA, enfin pas que je maîtrise à l’heure actuelle.

Voila ma maigre contrib, si cela peut t’aider.

[Link953_1]

Ta contribution m’aide beaucoup ! Je vais tester ce week-end le déménagement du zigbee et zwave avec les conseils plus haut, mais tes astuces batterie et matériels critiques ont l’air top aussi. Je testerai ce week end

La gestion des volets roulants me fait un peu peur aussi. Je suis dans le même cas que toi… je pense que nous allons devoir passer par des scenarios.

D’ailleurs j’ai pas trouvé dans les scenario HA, est qu’on peut programmer le lancement d’autre scenario et au besoin supprimer ces lancements ( comme avec remove_inat sous jeedom) ?

J’ai également trouvé ça sur le forum, ca peut aider ceux qui passent par la : Traduction Jeedom ↔ Home Assistant - Home Assistant - Tutoriels & Partages / Général - Home Assistant Communauté Francophone (hacf.fr)

[pctetra]

@Link953_1

D’ailleurs j’ai pas trouvé dans les scenario HA, est qu’on peut programmer le lancement d’autre scenario et au besoin supprimer ces lancements

Tu as les automatisations et les scripts, tu peux lancer un script via une automatisation, ou lancer une automatisation via une autre automatisation
service dans automatisation est très riche fonctionnellement tu peux faire tout ce que tu veux, tout au moins beaucoup de choses …

service: script
service: automatisation

[Pulpy-Luke]

Hello,

J’ai plus trop en tête ce que faisait le plugin volet (je crois que je l’ai jamais déployé) mais si c’est pour ouvrir/fermer etc il y a des blueprints assez balaises

☀️ Cover Control Automation (CCA) - a comprehensive and highly configurable...

[Sabjul33]

Ah plutôt balaise. Moi je cherche un truc pour « faire de la simulation » ouvrir et fermer les volets de manière aléatoire mais sur un plage horaire. Exemple : je veux ouvrir mes volets aléatoirement entre 8h et 9h30 et si possible pouvoir fixer plusieurs plages horaires (matin midi soir)…

[Pulpy-Luke]

Exactement ce que ça fait je pense…

Opening and closing the roller shutters (depending on brightness, sun-elevation and within time windows)

Bon après il y en plein d’autres (surement plus simple en plus) et avec une automatisation c’est ultra simple à gérer. Le truc dur c’est de comprendre comment fonctionne la mécanique

[Sabjul33]

faut que je me penche sur une automation, mais je me dis que si j’y ai pensé d’autres l’ont fait sûrement mieux que moi