Passer votre jeedom tout-en-un à un couple master+antenne

Jeedom propose depuis quelques temps le plugin Jeedom Link. Celui-ci permet de partager des objets entre plusieurs Jeedom. Concrètement, si vous reliez 2 Jeedom entre eux, et choisissez de partager des composants du premier vers le deuxième; ce dernier pourra interagir avec ce composant distant comme s’il était physiquement attaché localement.

Ce plugin répond à 2 besoins :

  • faire discuter 2 Jeedom entre eux bien sur
    ceci était possible auparavant, mais c’était compliqué, il fallait passer par l’API via des appels http et le tocken API; tout cela unitairement …
  • remplacer le mode esclave qui va bientôt disparaître
    celui-ci permettait de déporter un plugin sur une autre machine, pour étendre ou déporter votre réseau Zwave ou RFX433 par exemple

 

Existant

mjeedom_network

Aujourd’hui, ma configuration est la suivante :

  • un raspberry pi 2 sur lequel est branché … tout !
    • du zwave
    • du 433MHz via RFXTRX
    • du SMS via une clef 3G
    • pleins d’autres trucs via le réseau cablé puis wifi comme par exemple du Philips Hue, de l’IPX800 ou encore du Netatmo …

Afin de fiabiliser un peu ce « cœur de réseau », je lui ai ajouté un SSD afin que la carte SD ne me lâche pas du jour au lendemain à cause des écritures récurrentes du système.

Ce raspberry exécute tout :

  • toutes les interfaces (zwave, rfx, sms …)
  • tous les scénarios
  • des scripts
  • de l’historisation
  • les IHMs

mjeedom_network_plugins

 

Le déclencheur

C’est extrêmement rare, mais c’est arrivé : une mise à jour de Jeedom a détruit mon système. Le système ne répondait tout simplement plus ! (même au ping) J’ai du entièrement réinstaller le jeedom et redescendre un backup. Cependant, pleins de choses étaient encore à faire (drivers, montage du SSD etc …)

Grosse galère donc, et rien pour se prémunir de cela. J’aurai pu faire une image de ma carte SD, mais à chaque mise à jour … Cela prend du temps, cela se fait à froid (dangereux de faire cela à chaud)…

Cela m’a donc motivé pour fiabiliser un peu mon système !

L’objectif

Ayant récemment recyclé un ancien PC en ESXi, il m’est à présent possible d’héberger des VMs. L’idée est donc de déporter le « coeur de réseau » en machine virtuelle afin de pouvoir facilement le backuper avant des mises à jour. Le raspberry conservera l’hébergement des « antennes ».

Il faut donc migrer le Jeedom historique en un maitre + antenne.

mjeedom_network_antenne

La migration

Voici step by step, chaque action que j’ai effectuée pour effectuer cette migration.

Etape 1 : configurer le Jeedom virtuel

mjeedom_etape1

Suite à cette étape, on a un nouveau Jeedom vierge à jour sur l’ESX. Inutile d’aller plus loin dans sa configuration, on va tout écraser plus tard 🙂

Etape 2 : transfert de la configuration

On effectue un backup du Jeedom source que l’on applique sur le Jeedom virtuel.

mjeedom_etape2

On désactive également les scenarios et le crontab de l’ancien Jeedom afin d’éviter que des choses se lancent pendant notre migration.

Etape 3 : spécialisation des Jeedoms

A  cette étape, vous avez 2 Jeedom identiques. On va donc :

  • Désactiver les plugins « antennes » du Jeedom virtuel
  • Désactiver tous les plugins autres que « antennes » du Jeedom physique

mjeedom_etape3

Etape 4 : nouvelle identité et mariage

On poursuit la spécialisation en générant une nouvelle clef API pour le nouveau Jeedom. Avec le recul, je pense qu’il est préférable de plutôt générer une nouvelle clef sur l’ancien Jeedom, le nouveau jeedom virtuel hérite de l’ancienne clef API. (J’en parle plus loin).

On installe également le plugin Jeedom Link sur les 2 Jeedom.

mjeedom_etape4

Etape 4-1 : créer une nouvelle clef API

Rendez vous sur la page d’administration, puis cliquez sur Generer . N’oubliez pas de sauvegarder!

mjeedom_reset_apikey

Etape 4-2 : Configuration de Jeedom Link

Rendez vous sur la page du plugin Jeedom Link sur l’antenne. Ici ce que l’on veut, c’est partager des objets de l’antenne vers le Jeedom Virtuel (on va l’appeler Main).

On renseigne donc :

  • l’adresse IP (fixe de préférence ! Vous pouvez aussi passer par le hostname + un DNS mais cela fera l’objet d’un autre billet)
  • la clef API fraîchement regénérée en étape 4-1
  • et un petit nom
  • le mode d’accès à « interne » permet de rester sur le réseau local et éviter de sortir sur internet, mais Jeelink fonctionne aussi via Internet (moyennant certaines précautions de sécurité)

mjeedom_conf_jlink

Partagez ensuite chaque objet via le deuxième onglet.

mjeedom_conf_jlink_partage_obj

Etape 5 : mise à jour des commandes

Cette étape est la plus fastidieuse, on va remapper chaque ID de commande de chaque objet déporté via jeelink.

mjeedom_etape5

Pour faire cela, rendez vous dans le plugin Jeelink du Jeedom Main, sur lequel vous devriez voir apparaître tous les objets que vous avez partagé en étape 4-2.

Sur chaque objet, on va remapper l’ID. Pour cela, on ouvre un objet depuis le plugin Jeelink, puis sa configuration:

mjeedom_conf_jlink_remapp1

Ce qui nous donne accès à chacune de ses commandes, on les ouvre une par une, et on utilise les boutons jaunes :

  • Cette commande remplace la commande : vous ouvre une popin permettant de choisir l’ancien objet « local » au main.
    Rappelez vous, on a pas encore supprimé tous les anciens objets zwave, RFX etc. Ici, on va remplacer leurs commandes une par une pour les faire pointer vers les commandes du remote (de l’antenne)
  • SINON, vous pouvez également, si vous êtes rusé, utiliser le bouton cette commande remplace l’id et écrire l’ID que vous retrouvez après « remote:: » dans le champ Logical Id.
    Vous pouvez utiliser cette astuce car vous avez remonté un backup du jeedom antenne, ce qui a maintenu les ID

mjeedom_conf_jlink_remapp2

Une fois que vous aurez enfin tout fini, (soyez rigoureux !), testez votre Jeedom Main : tout doit fonctionner à partir de ce point.

Etape 6 : le ménage

Cela n’aura jamais été aussi amusant de faire le ménage 🙂

Une fois vos vérifications effectuées (et éventuellement des backup effectués au cas où),

  • Sur le jeedom antenne, supprimez tous les plugins que vous aviez désactivés, ainsi que les objets associés
  • Sur le jeedom Main, supprimez tous les plugins qui sont à présent déportés sur le jeedom antenne, ainsi que leurs objets associés

mjeedom_etape6

Si vous ne vous sentez pas encore sereins pour toutes ces suppressions, laissez les objets désactivés en plan pour l’instant. Vous les supprimerez la semaine prochaine, lorsque vous aurez bien vérifié qu’ils ne sont plus nécessaires.

Retour d’expérience

Cette migration m’a pris environ une demi journée.

  • Je constate une amélioration très significative de la réactivité du système malgré le déport des antennes.
  • La liaison entre les 2 jeedom est donc très efficace.
  • Le jeedom antenne est plus réactif, car il a moins de choses à gérer.
  • Le Jeedom virtuel qui est à présent le cœur de réseau, est sur une machine 64bits beaucoup plus puissante, peut encaisser sans broncher des scénarios complexe et de la parallélisation de tâches.
  • Toutes les IHMs sont plus rapides (même sur mobile)

Avant chaque mise à jour, je peux à présent déclencher un snapshot sur ma VM, qui me permet de revenir très rapidement en arrière en cas de pb. Si le problème se produit sur l’antenne, je réapplique simplement une sauvegarde et je suis très rapidement à nouveau opérationnel vu que toute la complexité est sur la VM.

Je vous conseille donc une approche similaire pour fiabiliser votre propre système domotique sous Jeedom !

Une fois encore, je ne peux que saluer l’équipe Jeedom qui a produit une solution très satisfaisante! Merci de nous permettre toutes ces possibilités.

i_love_jeedom

 

7 thoughts to “Passer votre jeedom tout-en-un à un couple master+antenne”

  1. Bonjour

    Merci pour tes supers infos et pour tout le temps que tu dois y passer.

    Que ce passe t’il si un des 2 jeedom plante ?

    1. Bonjour Franck,
      Cela dépend de quel jeedom. Si c’est l’antenne, tout ce qui passe en RF ne fonctionne plus et il n’y a plus de remontée, mais l’interface web, l’appli et les autres périphérique type IPX, netatmo etc fonctionnent toujours bien. Si c’est le virtuel (ce qui est tout de même fort peu probable), il n’y a plus rien, sauf à passer en direct sur l’antenne, mais ce n’est pas très pratique.
      Pour l’instant, je n’ai eu aucun plantage ni aucune indispo liée à cette configuration 🙂

  2. Bonjour,

    Merci pour l’article. Je m’interroge sur pourquoi ne pas tout avoir déporté sur la VM au final ?
    Quel est l’intérêt de conserver déportés les « antennes » sur un Raspberry ?
    Personnellement, j’utilise aussi une VM avec en passthru les périphériques USB branchés au serveur ESXi. Ceci me permet de faire les backups comme vous.

    1. Bonjour Alex,

      Il y a 2 raisons pour déporter les « antennes » :

    2. impossibilité technique de passthru (certaines clefs 3G ou zwave sont galère à passthru sur l’esx…)
    3. positionner les antennes à un endroit plus central de la maison (lorsque le serveur esx est dans la cave/garage ou un placard déporté) ce qui permet de considérablement gagner en portée. Cela s’applique moins pour les technos maillée type zigbee ou zwave, mais pour du 433MHz, c’est très utile !
      1. Merci. Vous avez raison. Je n’avais pas pensé à la localisation des « antennes » (j’ai la chance que mon serveur soit en plein milieu de l’appartement donc pas de souci de ce côté là) et même en 433Mhz ça passe bien. 🙂
        Pour le moment, je n’ai pas eu de souci avec le passthru pour du RFXCom, une clé Zwave et une clé Plugwise. Je le précise pour d’éventuels autres lecteurs qui se poseraient la question 🙂
        Bonne continuation Xavier.

        1. Pour ma part, rfxtrx et onduleur APC passent bien en passthru! Par contre je n’ai pas réussi sur une clef zwave (Z-Wave Plus Z-Stick GEN5 – Aeon Labs) ni avec une vieille clef 3G Huawei Orange 🙁
          Merci, également Alex !

          1. A titre d’info, j’ai une clé USB Z-Wave Plus Zwave.me. Elle apparait en tant que « Sigma Designs Inc » sous Linux sur la VM Jeedom.

            alex@linjdom:~$ lsusb
            Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
            Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc.
            Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
            Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
            Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
            alex@linjdomlev02:~$ lsusb -v -t
            /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
            /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
            |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M
            |__ Port 1: Dev 4, If 0, Class=Communications, Driver=cdc_acm, 12M
            |__ Port 1: Dev 4, If 1, Class=CDC Data, Driver=cdc_acm, 12M

            Les autres périphériques USB (dont un onduleur APC aussi) sont situés sur une autre VM toujours en passthru. 😉 Bon weekend.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *