Nouveau mode esclave

Comme vous le savez, nous sommes en train de revoir le mode esclave. Au début nous étions partis pour alléger le mode esclave en ne déployant plus de Jeedom sur eux uniquement les dépendances et le démon. Bien que cela soit une solution qui semble intéressante, elle est beaucoup trop complexe et surtout aurait demandé énormément de temps de développement pour le nombre d’utilisateurs se servant du mode déporté.

Nous avons donc pris le problème dans l’autre sens. Au lieu d’un système plus léger celui-ci sera plus lourd, mais plus simple à mettre en place pour nous les développeurs et plus complet pour vous. Pour cela, il n’y aura plus de maître/esclave à proprement parlé, juste des Jeedom déployés qui seront complets (dashboard, scénarios…). Dans les faits, on pourra indiquer à un Jeedom de remonter les informations des différents équipements/commandes (on pourra choisir) vers un autre Jeedom en temps réel. Celles-ci arriveront dans le second Jeedom sur des équipements virtuels.

Pourquoi faire cela ? c’est assez simple ! cela va vous permettre de faire des scénario sur le second Jeedom et d’avoir ceux-ci parfaitement fonctionnels si le premier Jeedom s’arrête. Cela permettra aussi de déporter réellement de la charge sur le second Jeedom (pas comme le mode esclave actuel où il n’y a  un report de charge que de l’ordre de 1 à 2 %).

Par contre pour ceux qui sont en mode déporté actuellement, il faudra absolument tout reconfigurer, et au niveau des plugins de protocoles tous les modules ne seront plus visibles directement sur le maître. En particulier par exemple sur le plugin openzwave, vous n’aurez plus le graph du réseau pour chaque esclave ; il faudra se connecter sur chacun d’entre eux pour le voir.

Voilà en espérant que malgré ces quelques changements dans le fonctionnement, les évolutions prévues vous plaisent quand même.

MAJ du 28/08/2016 : le plugin « Jeedom Link » qui permet de faire le lien entre plusieurs jeedom est disponible sur le market. Vous pouvez l’installer sur un jeedom 2.3. A noter quand même que :

  • le plugin sera plus rapide en jeedom 2.4 (optimisation des listenners et diminution des appels à la BDD)
  • le plugin n’a pas encore toutes ses fonctionnalités, mais il a celle de base qui vous permettront déja de configurer des liens entre Jeedom

Cet article a été lu 7706 fois

Vous aimerez aussi...

65 réponses

  1. poulpito dit :

    c’est juste une blague ….
    Avoir un jeedom déporté avec un dongle zwave me permet d’avoir jeedom sur un serveur vmware avec toute la flexibilité que cela propose …. et surtout un rpi qui ne va pas lacher tous les 4 matins avec la charge de jeedom dessus.
    je me vois mal devoir reconfigurer tous mes modules et que tout soit transféré en virtuel sur le main

    non vraiment la .. je comprends plus jeedom
    un topic sur le forum pour en discuter ?

    • loic dit :

      Non pas vraiment une blague juste la meilleure solution que l’on ai trouvé pour garder un mode esclave. Malheureusement nous n’avons pas les ressources nécessaires pour assurer une qualité suffisante sur l’ancien système.

      Par contre le nouveau il n’y aura rien à créer à la main sur le principal tous sera créé automatiquement.

      • golfvert dit :

        Moi aussi, j’ai cru à une blague. Il était annoncé un mode « léger ». Plus de jeedom sur les esclaves mais simplement un accès ssh. Je me suis dis, super, ça va être encore plus simple et pratique. Et là, virage à 180°. Ce n’est ni « moyen » (la situation actuelle) ni « léger » (le futur espéré) mais du « lourd ». Le mode esclave était super pratique avec un point unique de configuration et des rpi ou équivalent en distant pour la partie « gateway » vers les protocoles zwave et autres. Là, on abandonne complètement cette option. Je suis curieux de voir en combien de temps un évènement zwave vu sur le distant (ne l’appelons plus esclave) va remonter sur le « principal ». Aujourd’hui, ça prend autour de 2s. Je crains que ça ne soit encore pire.
        Vraiment dommage comme décision.
        Le mode esclave est vraiment un (des) plus de jeedom. Ca en fera un de moins.

  2. shikyo dit :

    et dans le cas ou on voudrait garder le fonctionnement actuel ? car mon jeedom primaire est une vm sur un esxi surgonflé donc suport largement la charge mon jeedom board déporté ne gère que le controleur zwave et enocean pour envoyer le traitement sur la vm donc pour moi cela est parfait actuellement

  3. Jayknight dit :

    Question bête, mais il n’y a pas moyen de laisser les deux modes actifs ? Le mode actuel « esclave » pour ceux qui l’utilisent et qui surtout veulent continuer de l’utiliser, et le nouveau mode « déployé » ?

    Je ne vois pas vraiment d’obligation à supprimer ce mode « esclave », me tromperais-je ?

    • loic dit :

      Car cela nous demandes beaucoup de ressources pour le maintenir et dans Jeedom et dans les plugins et malheureusement nous n’avons pas ces ressources

  4. barbo77 dit :

    Bonjour

    Je comprends les contraintes sur la maintenance.
    Par contre, j’ai 2 petites questions pour savoir comment organiser au mieux la futur solution.
    Aujourd’hui, j’ai recyclé des mini/mini+ en satellite (clef sms, enocean, zvawe, rfxcom) et j’ai mis toute l’intelligence sur un synology (les perfs sont top). 2 avantages : les cartes SD ne lâchent plus, et j’ai pu optimisé le positionnement des antennes (clef sms,…).

    Question 1 : au niveau de la configuration des satellites/deports, y aura t il une configuration pour limiter drastiquement les écritures sur les cartes SD ? (je pense que le serveur de log pourra être déporté sur le principal)
    Question 2 : pour limiter les écritures SD, est ce qu’il sera possible/conseillé de mettre les bases sql des ex satellites sur le serveur principal ?

    En tout cas, bon courage et (encore) merci de (toujours essayer) de trouver les meilleurs compromis.

    Cordialement

    • loic dit :

      Bonjour,
      1) non de notre côté mais oui pour vous en désactivant l’historique par exemple. De plus avec la 2.4 Jeedom utilisera encore plus le cache pour limiter les écritures en base donc si votre /tmp est en ram il n’y aura quasiment plus d’écriture en base
      2) non pas forcément car comme dit avant il y aura très peu d’écriture en base donc ça n’aura pas trop d’intérêt

      • Fabrice dit :

        « /tmp est en ram il n’y aura quasiment plus d’écriture en base »

        Bonjour Loic, même si ça ne me ravi pas trop comme les autres je vois que l’on ne peut pas y échapper donc peux tu m’indiquer comment déplacer /tmp? Je crains pour les SD.
        Autre chose je ne compte pas reprogrammer tous mes modules en 1jour, est ce que la màj sera optionnel durant qql mois?

        Merci

        • loic dit :

          Bonjour,
          1) Pour le tmpfs il faut faire en ssh :
          echo ‘tmpfs /tmp tmpfs defaults,size=64M 0 0’ >> /etc/fstab
          et redemarrer jeedom
          2) Comme toute mise à jour elle ne sera pas obligatoire, de plus cela n’arrivera que en 2.5 (vers décembre donc) et le plugin permettant le nouveau mode déporté arrivera dans environ 1 mois ce qui vous laissera environ 2 à 3 mois.

  5. quasarbla dit :

    Le mode escalve, pour moi aussi, était un gros plus de jeedom.
    Comme les utilisateurs ci-avant, j’ai mon jeedom sur un serveur ESXi costaud, et un esclave sur un RPI. De plus le serveur étant au sous-sol avec un plancher chauffant électrique, les ondes ne passent pas entre le sous-sol et le RDC. Le mode esclave me permettait de m’affranchir de ce problème.
    Je suis de plus en plus déçu des choix de l’équipe qui va vers la banalisation et l’abandon des éléments qui le différencie de la concurrence.
    A vouloir faire au plus simple, vous allez aussi rentrer dans le rang des autres box domotiques, et en rentrant dans le rang, vous disparaitrez je le crains, face à certains mastodontes qui apparaissent sur le marché.
    Au regard de tous les modules que j’ai acheté (un module ne coute pas grand chose, mais multiplié ça commence à chiffrer, même si ce n’est pas énorme non plus, je le reconnais), je me dis qu’il va falloir de nouveau me mettre en quête d’une solution qui tienne la route… Je pensais avoir trouvé LA bonne solution, je commence à avoir des doutes.

    Il y a un vrai boulot derrière tout ce que vous faites autour de jeedom, je le vois, j’en suis conscient et vous félicite, mais je suis de plus en plus déçu des orientations techniques, des revirements de road map au gré du vent, etc. Tout cela n’est pas très lisible et ne fait pas très pro.

    • loic dit :

      Bonjour,
      Ce nouveau mode (une fois reconfigurer) ne changera rien pour vous le rpi pourra toujours envoyer les informations à lesxi qui se chargera lui d’exécuter les scénarios.

  6. Benoit dit :

    Bonjour,
    Pour ce qui concerne les backups (et accessoirement la gestion des utilisateurs), comment cela va-t-il se passer? Il va falloir le gérer indépendamment sur chaque Jeedom?
    De plus je ne saisi pas très bien cette histoire de scénarios déportés et de reports de charge. En gros nous pourrons exécuter des scénarios sur différents jeedom et leurs charges d’exécution seront sur l’hôte sur lequel ils seront exécutés c’est bien ça? Donc nous aurons toujours une seule et unique fenêtre pour avoir un vue complète de tous les scénarios et nous aurons un peu comme un plugin le choix de son hôte d’exécution? J’ai peur de comprendre qu’il faille faire les scénarios sur chaque jeedom (si c’est le cas, je ne vois pas bien comment je pourrais les stopper ou les activer à distance simplement par exemple).
    Avez-vous penser à simplement un mode dynamique (load balancing) où en fonction de la charge des hôtes, jeedom décide lui même celui qui est le plus dispo?
    Je suis un peu du même avis que les posts précédents. L’intérêt de la domotique est de centraliser la gestion et l’intelligence de la maison. Là cela va à contre courant
    Cdt,

    • loic dit :

      Bonjour,
      Pour les backups et utilisateur cela sera comme sur le système actuel il faudra les gérer indépendamment sur chaque Jeedom.
      Pour les scénarios l’article dit juste qu’avec le nouveau système il sera possible de faire des scénarios sur tous les jeedoms au lieu d’être limité à les faire que sur le maître comme actuellement.
      Pour la répartition de charge en les Jeedom (load balancing) c’est complètement au dessus de nos compétences malheureusement.

      • Benoit dit :

        Pour les backups, j’ai un RFX déporté. Le backups de mon maitre contient les équipements et l’historique. Cela ne va donc pas changer? Un seul backup du maître contiendra tout. Car aujourd’hui, je ne restore jamais de backup sur mon esclave. Je remets juste le plugin.
        Cdt,

        • Benoit dit :

          Une fois que j’aurais tout reconfiguré bien entendu :).

        • loic dit :

          Si vous transmettez les commandes de l’esclave sur le maître et les historisaient alors le maître contiendra les même informations qu’avant et donc son backup contiendra bien tout.

          • Benoit dit :

            Ok, merci pour la réactivé. Je suis également la réponse d’en dessus. Une petite question m’intrigue (dans la logique de mes backups centralisés). Quand je devais relancer un plugin sur un esclave. Où frauda t-il le faire? Sur le maître comme actuellement?
            Cdt,

  7. yfo69 dit :

    Bonjour,

    Je ne comprends pas se revirement de situation …

    Ce mode esclave est un plus de Jeedom, permet de déporter « des antennes » tout en gardant un fonctionnement centralisé.
    Toute la conf est sur le maître et une fois l’esclave configuré, on y touche plus.

    Questions pour être certain de bien comprendre :

    1 / J’ai deux esclaves avec chacun un RFXcom. Faudra il que je configure les modules sur l’un ou l’autre en fonction des zones de couvertures ou sur les 2 ?
    (Actuellement je configure sur le maître sans me préoccuper de la position et de plus pour les zones de recouvrement de couverture cela sécurise les transmission en cas de panne de l’un ou l’autre)

    2 / Zwave géré par un esclave et modules configuré sur le maître. Faudra il que je reconfigure tous les modules sur le Jeedom déporté (si on peut l’appeler comme cela) ?

    C’est regrettable de voir un nouveau changement . A mon sens Jeedom à maintenant un nombre suffisant de fonctionnalité et je le trouve pour ma part stable. Il me semblerai plus judicieux de capitaliser sur l’existant plutôt que de modifier sans cesse le mode de fonctionnement qui oblige les utilisateurs à tout reconfigurer.

    La domotique est pour beaucoup un amusement et j’en fais parti mais reconfigurer sans cesse commence à lasser ….

    Cordialement

    • loic dit :

      Bonjour,
      1) oui il faudra reconfigurer les modules sur chaque esclave mais cela vous permettra de bien délimiter les zones et corrigera un soucis chez certain utilisateurs ou le module recevait plusieurs fois un ordre venant de plusieurs Jeedoms ce qui posé soucis lors de commande de type toggle.
      2)il faudra juste sur le Jeedom déporté cliquer sur synchroniser pour qu’il récupère la liste des modules. Et ensuite lui dire de transmettre les informations des modules au maître.

  8. Phil dit :

    Bonjour,

    Alors là je suis sans voix…. Vu ma configuration actuelle, Maitre dans un serveur (Syno) dans la baie 19″ du garage avec onduleur et esclave RPI Zwave/RFXCom/TTS dans le placard du salon, j’avais à la fois la sécurité et les perfs du Maitre et la situation géographique idéale de l’Esclave. Si demain je dois avoir deux box à sécuriser, car les deux seront des jeedom complet avec tous les problèmes qui vont avec (carte SD, coupure de courant etc…) je ne vois plus pour moi l’intérêt du maitre/esclave. Si j’ai tant aimer jeedom par rapport à la concurrence, c’était justement de pouvoir mettre en place ce genre d’architecture. J’avais même l’impression je cela faisait partie de son ADN.

    Si demain la solution pour moi c’est de remplacer mes deux systèmes par un seule, dans le salon, cela demande l’achat d’un nouveau matériel (mon RPi n’est pas assez puissant et sécurisé) et de prévoir une nouvelle alimentation sécurisé (et donc une sur-consommation etc…) Bref je me retrouve à devoir monter et maintenir une nouvelle plateforme complète. Pour moi c’est comme un nouveau départ et là, un peu las de devoir sans arrêt faire évoluer (tout casser) de système, je ne suis pas sûr de ne pas retourner vers le monde du propriétaire, moins évolutif mais au final plus reposant…

    Bonne réflexion et bon courage à vous
    Phil

  9. OlivierD dit :

    Je comprends la problématique coté mais c’est assez dommage côté utilisateurs… Comme dit précédemment nous qui utilisons les satellites ne sommes qu’une minorité et affecter trop de ressources sur une minorité est le meilleur moyen de déposer le bilan… Enfin je venais de finir mon ESXI et ma mini me servait d’antenne… Les performances n’avaient RIEN à voir (certains scénarios sont passé de 15 sec d’exec à moins de 1s)…
    Ben du coup je pense que je vais acheter un clé ZWave, la mettre sur le serveur et abandonner le satellite… Au moins j’aurais une configuration ‘canonique’ comme ca.

  10. poulpito dit :

    Quid de fournir une solution permettant d’appeler un module série via ip (un peu comme le mysensor)
    (dans la conf du plugin sur le maitre au lieu de port ou esclave + port actuellement)

    et de permettre aux gens soucieux de garder l’ancien mode de fonctionnement de convertir sur leur rpi distant un port serie en socket avec un netcat socat ou un service du genre
    service
    testservice
    {
    port = 5900
    socket_type = stream
    protocol = tcp
    wait = yes
    user = root
    server = /usr/bin/netcat
    server_args = « -l 5900 < /dev/ttyS0"
    }

    je pense pas que ce soit bien compliqué à rajouter au module existant et ca permettrait de garder le fonctionnement déporté sans tout le système esclave jeedom ?

    (oui j'ai vraiment envie de garder mon rpi minimal déporté pour capter zwave/rfxcomm, qu'il faille stopper les maj ou partir sur une autre solution domotique … même si je suis un adepte et propagateur de bonne parole de jeedom )

    • loic dit :

      Bien que l’idée soit bonne ce n’est pas si simple à mettre en place et à fiabiliser et je ne pense pas que ça soit compatible avec tous les protocoles malheureusement…

      • loic dit :

        Bonjour,
        Oui nous avons des statistiques la dessus grâce au market et nous avons moins de 7% des utilisateurs qui ont des esclaves.

        • Phil dit :

          Et m…de seulement 7%, pas de chance moi. Enfin en même temps si 7% quittent Jeedom à chaque changement de « stratégie » ça peut aller vite surtout en ce moment. Et surtout je pense que dans ces 7% il doit y avoir plutôt des utilisateurs « avancés » qui participent (ou pas) au développement et aussi à la promotion de Jeedom.

          • loic dit :

            Je ne sais pas quoi vous dire juste que c’est uns histoire de ressources on n’a pas les ressources suffisantes pour maintenir le mode esclave dans l’état actuel.

  11. Jonjbar dit :

    Assez déçu aussi par ce changement, j’espère que sur le long terme, tout bien considéré, ça vaudra le coup.
    Par contre vous dites qu’il y a peu d’utilisateurs du mode esclave. Je trouve ça surprenant: avez-vous des stats ? Car c’est un mode très utile pour diverses situations.

  12. Tigrou750 dit :

    Bonjour

    Je suis aussi un utilisateur d’une mini première du nom sur lequel j’ai mon zwave,rxfcom et sms. et le moteur sur syno.

    Si j’ai bien compris j’aurais de nouveau une mini avec juste les scénarios sur le maitre?

    • loic dit :

      Bonjour,
      Oui c’est cela ca ne changera pratiquement rien pour vous si ce n’est que la configuration des modules devra se faire sur la mini

  13. Dany21000 dit :

    Salut,

    En fait, sans le vouloir je m’y étais déjà préparé.
    C’est à dire que j’ai des virtuels qui vont chercher les infos de mes plugins (rfxcom, teleinfo) qui sont eux en esclave.

    En gros, je n’utilise pas les équipements issus des plugins. Je passe par des virtuels qui font abstraction de la couche plugins « protocolaires ».

    Du coup, si aujourd’hui une sonde de température qui arrive par rfxcom, est changée par une zwave ou autre… je n’ai qu’un seul changement à faire… la source du virtuel.

    Donc comment çà va se passer ?
    Est ce que sur l’esclave il faudra saisir l’ID de l’équipement virtuel du maître, ou est ce qu’il sera fait seul ?
    Pourra t’on de façon granulaire remonter seulement certaines commandes (esclave) sur des commandes (du maître) déjà existante ?

    Aussi, vas t’on perdre le visu et contrôle depuis le maître de l’état des démons des esclaves.

    En tous cas, il serai bon d’avoir une backup automatiquement exportée vers le maître, une désactivation ou envoi des logs sur le maitre.

  14. Asfaux Laurent dit :

    Les protocoles concernés par le mode esclave (Z-Wave, RFXcom, Téléinfo, etc…) sont surtout basés sur un périphérique USB.

    Or il existe des hubs USB vers Ethernet : jeedom peut donc rester bien au frais au garage avec des clés Z-Wave, RFXcom et compagnie branchées sur l’un de ces hubs.

    Source : http://forum.macbidouille.com/index.php?showtopic=116785

  15. barbo77 dit :

    Bonjour

    Après quelques jours de réflexion, positivons ! (oui je fais partie des 7%).

    En ayant la possibilité de faire des scénarios sur les déportés, nous allons pouvoir faire des scénario de supervision (exemple si le maitre a un soucis, je pourrais envoyer un sms,…).

    Ne l’oublions pas, le logiciel est encore très très jeune (-2 ans-), donc oui des changements pour être plus maintenable et robuste sont les bienvenus (même si, sur le moment, cela est -un peu- pénible à gérer).
    Avec le réseau actuel, j’ai quelques pb :
    – gestion des backup et des maj (perte d’information pendant les traitements). J’espere que les informations seront gérées en fifo post coupure (maintenance/backup). Ce serait le top et vraiment un autre plus.
    – je suis déjà obligé de me connecter aux esclaves pour configurer/relancer les plugin (choix des ports, dépendances) => cela ne modifiera pas structurellement mon travail.
    Par contre, il faudra que je duplique une partie de la configuration (envoi des emails sur pb, s’il y a des messages d’information) qui était prise en charge par le maitre…. Enfin cela dépendra des fonctionnalités qui seront disponibles sur le nouveau master.

    La démarche de l’équipe Jeedom est plutôt claire (et positive) : nous offrir le maximum (le plus vite possible) et parfois (hélàs pour le temps de travail investi) changer de stratégie (en fonction du retour d’expérience, des contraintes technico financières).

    Encore bravo à l’équipe….et prenez le temps (de vous reposer et de bien mettre en place ce nouveau module maitre/esclave).

    PS : j’utilise de plus en plus l’application mobile (versus l’application web app). Dans quelques mois, Jeedom sera super top ! L’été a été très riche en mises à jour et améliorations. MERCI BRAVO

    Cordialement

  16. Claneys dit :

    Possesseur d’une Mini+ depuis une petite année, j’ai acheté une solution packagée plutôt que faire du DYI et pour une fois être dans les clous pour la tranquillité de l’esprit. Mais depuis un moment maintenant j’allume un cierge à chaque mise à jour de plugin ou de core. Généralement à cause de pré-requis « surprise » dont on ne sait rien avant d’aller se faire allumer sur le forum.

    Je perd patience et j’ai bientôt plus de cierges.

    Je salue le travail fait sur Jeedom, c’est une solution qui offre tout et permet de quasiment tout faire. Ce n’est par contre pas un produit à mettre entre toutes les mains et clairement pas prêt pour le grand public, à mon avis. J’espère que la solution ira en se stabilisant que ce soit du côté core, où c’est plutôt mieux maintenant, que plugin.

  17. jonjbar dit :

    Du coup, avez-vous envisagé de supporter le développement d’un mode esclave « light » au travers d’un plugin payant ?
    Que disent vos calculs si une partie des 7% payaient pour ce fonctionnement ?

    • Phil dit :

      bonjour,

      Effectivement, je ne serais pas fermé à l’idée de payer (un peu) pour conserver ce mode de fonctionnement, encore faut t’il que ce mode soit « garantie » dans le temps.

      • Dany GINHOUX dit :

        Je suis d’accord aussi.

        Néanmoins, le fonctionnement proposé aussi n’est pas si gênant que cela. Il y a oui du travail coté utilisateur pour se mettre en conformité avec le nouveau mode de fonctionnement.

        Mais si cette solution vous permet d’avoir un développement plus rapide et une facilité de maintient, alors çà ne devrait pas être un problème.

        Par la suite, rien n’empêchera de mettre dans la todo list un mode d’esclave light.

        Pour le moment, vous avez raison et concentrer et de bien expliquer la démarche.
        Auriez vous la possibilité de faire un billet avec des chiffres parlant sur jeedom ? utilisateurs, antennes, CA, embauche, nombre de plugins … histoire que l’on se rende compte de l’évolution

    • loic dit :

      Bonjour,
      Non le développement d’un tel mode est vraiment trop lourd (sinon on l’aurait fait et en gratuit même) mais un mode léger c’est un développement sur chaque plugin que l’on veut rendre compatible + un développement énorme dans le core pour tous ce qui est gestion des démons, des dépendances, des logs…. Et faut ajouter à tous cela le maintient qui est représente une charge non négligeable. A faire cela on va se retrouver à passer 30% du temps à travailler pour moins de 7% des utilisateurs….

  18. Quasarbla dit :

    +1

  19. MicroFire dit :

    Avec la version 2.4 qui utilisera beaucoup moins d’écriture sur les cartes SD, je ne suis pas contre.

  20. niko34 dit :

    Salut,

    est-ce que vous avez une idée de la date pour cette évolution ?

    J’attendais avec impatience la refonte de la gestion des jeedom esclave car cela ne fonctionne pas bien chez moi. Les états des équipements de l’esclave ne s’affichent pas bien dans le maître (les valeurs sont ok dans la conf de l’équipement, mais quand je teste les commandes et regarde le Dashboard, elles ne sont pas bonnes).
    J’ai un contrôleur z-wave sur chaque jeedom (sur des RPI). Dans ce type de config, je pense que le fonctionnement annoncé n’est pas gênant si on peut afficher un équipement sur un autre jeedom (comme annoncé dans la news).

    Si le nouveau mode me permet de revenir à un fonctionnement normal, ça me va.

  21. Bphoque dit :

    Ce changement du mode esclave va grandement faciliter le déploiement de la nouvelle box jeedom prévue en fin d’année.
    Imaginer tout reconfigurer, les modules, etc… Je pense que c’est une bonne chose.

  22. gngh dit :

    Bonjour,

    Je fais aussi parti des 7% qui possède un « esclave » sur un RPI et le « master » sur un ESXI et je tiens à faire par ici de mon « expérience » Jeedom.

    Pour me présenter, je dirais que gère le cycle de vie d’applications bancaire dans une grande banque.
    Je vous laisse imaginer la disponibilité demandé et les contraintes de fonctionnement suite aux MEP (mise en production).

    J’ai jeedom depuis le commencement de l’appli et oui 2 ans déjà (il était en test car je possède déjà une Vera3 qui n’est jamais mis a jour, ni redémarrer et qui fonctionne parfaitement).
    Depuis le tout début, j’ai acheté le plugin OpenZwave car j’ai une clef USB (reliquat de test sur Domotiga pour les connaisseur)

    Seulement voila il y a peu un changement de direction sur le plugin Zwave impose d’utiliser le plugin OpenZwave qui est devenu gratuit.
    J’ai eu le malheur de demander ici même, ce que la DevTeam comptais faire pour ceux qui l’avais déjà acheté.
    Je me suis fait envoyer bouler en me disant que j’aurai du lire le forum.
    Premièrement je ne suis pas 24/7 sur le forum pour lire tous les topics, deuxièmement, et vous l’avez reconnu, plus de monde lis le Blog et troisièmement je ne pense pas qu’en novembre 2014 (date à laquelle j’ai acheté le plugin) l’idée de basculer tout le Zwave sur l’OpenZwave était déjà l’ombre du commencement d’une idée.
    Je passe sur les problèmes de siphonnage de pile en 4 semaines suite a ce changement.

    Il me semble que ce changement a été initier car certains clients avaient des problèmes avec la version 2 du plugin Zwave.
    Soit dit en passant je serais curieux de savoir si ils étaient plus que 7% à avoir ces problèmes.

    Et je suis resté sur Jeedom, j’ai même acheté d’autres plugin.
    Je suis en phase de migration de toute ma domotique de la Vera sur Jeedom.
    C’est que j’ai confiance en vous la DevTeam.

    Mais maintenant vous changer le mode de fonctionnement de la partie « Master/Slave ».
    Je ne suis plus sûr de vouloir tout migrer maintenant.
    S’ajoute à cette nouvelle, un plantage de tous les démons de mon Jeedom « esclave » suite à la mise à jour du 17/08.

    De pars mon métier je trouve que la gestion ne fait pas très pro, surtout pour une solution qui est commercialisable.
    Si vous voulez avoir des revenues stable pour grossir et pouvoir investir dans le développement de Jeedom, il va falloir la stabiliser et ne plus a avoir a allumer un cierge (comme j’ai pu le lire ici) ou croiser les doigts à chaque MàJ.

    Pourquoi ne cherchez vous pas quelles sont les raisons qui pousse les 7% d’utiliser un « esclave » ?
    On vas faire rapide, je pense que la raison première est de pouvoir déporter les éméteurs/récepteurs USB des serveurs (ESXI ou Syno) car ils n’en n’ont pas à foison et cela permet de les mettre où l’on veut.

    Imaginons une solution qui permettrais de faire reconnaître à Jeedom un périphérique USB connecté sur un RPI via le LAN ?
    Et la tout les clients sont content, c’est rapidement déployable.
    Car on peu imaginer qu’un plugin Jeedom permettrai de descendre une image pré-configurée sur une carte µSD via l’interface WEB.

    En informatique rien n’est impossible, il y a toujours une solution simple à un problème.
    Il suffit de la trouver.

    Cordialement,
    Gngh

    • loic dit :

      Bonjour,
      Nous sommes désolé d’apprendre que vous avez eu des soucis avec le plugin openzwave. Nous faisons tout pour rendre Jeedom et ses plugins le plus stable possible. Et croyez bien que faire des modifications lourdes nous ne amuse pas et que nous ne les faisons pas pour embêter les utilisateurs mais parceque nous pensons que c’est la meilleure solution pour la majorité.
      Pour la communication il est vrai que ce n’est pas notre fort et j’en prends l’entière responsabilité sans soucis. Mais pour être franc quelque soit la communication faite cela ne va jamais : le forum les gens le lisent pas, les changelog non plus et la communication sur le blog environ 3 a 4 mois avant la modification ça ne va pas. Déjà la communication c’est pas mon fort et ça ne me plaît absolument ben quand je vois les réactions ça ne me donne pas envie de faire des efforts. Donc pour que ça soit clair Jeedom évolue en permanence et subit souvent des modifications lourdes avec des défaut de communication ben le jour où ça ne sera plus le cas ça voudra dire que je ne serais plus là.
      Pour votre idée de déport usb sur le réseau bien que bonne celle-ci demande des compétences que nous n’avons pas nous ne pouvons donc mettre en place unyel système.

        • loic dit :

          J’avais testé ça il y a quelque temps et je n’ai jamais réussi à le faire marcher de manière fiable et facilement

          • barbo77 dit :

            Bonjour
            Moi, je loue vos efforts de communication ! Je suis époustouflé par rapport à l’année dernière ! C’est 100 fois mieux !
            Il y a une road map, des explications sur les choix de la stratégie, une communication longtemps à l’avance.
            Continuez ….

            PS i : pour la communication, quelque soit, il y aura toujours des insatisfaits (je connais le pb).
            PS ii : j’ai vu des commentaires (négatifs) sur les qualités de mise en production… j’ai trouvé que c’était un peu abusé. Il y a toujours des incidents et des risques (même dans les milieux bancaires/facturations). Non, je ne parlerai pas de Socrate (je suis un peu vieux, c’était le système de réservation de la SNCF il y a 20 ans).
            PS iii : pour le caractère grand public de jeedom…. je suis un peu embêté… Est ce que Windows est grand public (oui, si on rachete un pc tous les 3/5 ans) ? Est ce qu’on peut avoir un systeme domotique qui ne bouge pas pendant 3 ans…. c’est un vrai sujet.
            En attendant, merci pour toutes les évolutions et gains en fiabilité.

  23. Paqueuc dit :

    Un message pour remercier l’équipe pour le super boulot. Oui, tout n’est peut-être pas parfait et plus le temps va passer plus la complexité risque de submerger le projet. Mais en attendant, un tel projet maintenu par une équipe si réduite, je dis chapeau. Ne vous laissez pas démoraliser par les retours contrastés. Vous avez grossi et chaque nouveau post sur le blog va être scruté à la loupe avec son lot de mécontents. Il n’y a rien à faire et chaque nouveau post risque d’être une épreuve si vous avez le cuir tendre. Mais quelque part, la critique est aussi la reconnaissance du beau travail. Qui prendrait la peine de critiquer quelque chose dont il n’a rien à faire ? Gardez la foi, c’est super ce que vous faites, et MERCI pour ce beau jouet (contre lequel il m’arrive aussi de pester 😉 mais j’y reviens quand même).

  24. Bipbip dit :

    Bonjour,

    J’utilise Jeedom en déporté pour une raison simple : ma baraque a été construite en 4x, je n’ai que des murs en parpaing, aucune cloison. Le RFXCOM passait très mal, j’ai donc 2 raspberry à chaque angle de la maison, pour les sondes Oregon surtout, dont la portée est faible. Je n’ai pas le choix, si je colle un seul récepteur RFXCOM, il y a toujours des sondes qui ne remontent pas d’info.

    Mon Jeedom primaire tourne sur une VM, sur un serveur issue de mon taf (je boss dans un datacenter). Sans être un monstre, il est surdimensionné pour Jeedom (HP G5 bi-processeur Xeon avec 16Go de RAM). Les raspberry, par contre, j’en ai une de première génération, et une 2. Les changements que vous annonciez auraient été intéressant, mais là, je rejoins beaucoup d’autres commentaires : c’est une farce ! Vous allez nous coller un Jeedom bien lourd, qui va foutre à genoux mes Raspberry, et en plus il faudra se taper plusieurs jours de config pour cela (j’ai environs 30 modules, des dizaines de scénar, etc). Bref, avec un serveur qui hébergeait une application de paiement en ligne à mon taf, je vais me retrouver avec un Jeedom qui rame, ou à devoir investir, encore et toujours… C’est pas comme si la domotique était une « passion » peu cher !!

    Franchement si c’est pour cela, ne touchez à rien et laissez le tel qu’il est, il fonctionnait parfaitement ! Là, vous allez pourrir le mode déporté !! Si j’avais voulu 3 vrais Jeedom dans ma maison, j’en aurai installé 3 et je les aurait fait communiquer via l’API !!

    Vous faites du très bon taf, et je ne dis surtout pas le contraire, mais depuis quelques temps, je suis assez déçu. Rien qu’à voir l’application Android, qui est juste une catastrophe facturée 4€ (quand on fait payer une appli, on se doit qu’elle soit niquel, et surtout, TESTEE !! Mettre peu de fonctionnalité au début n’est pas dramatique, mais là, je ne peux même pas m’en servir ^^. Impossible de cliquer sur les pièces, etc. OU alors, on fait une appli gratuite, d’ailleurs, même avec mon ancienne Zipato, l’appli était gratuite !.).

    Je suis là depuis presque le début (octobre 2014), pour info… J’ai fais parti des premiers à tester le plugin Imperihome, qui activait tout dans la maison pendant 30min, alors que j’étais au taf… J’ai donné un nombre incalculable de fois des accès root à mon serveur pour que des devs chassent des bugs, dans les plugins et autres. J’ai participé comme j’ai pu à faire grandir Jeedom. Mais là, je suis désolé, sur ce point précis, on marche sur la tête ! Si vous nous imposez cela, je ne mettrai pas à jour mon Jeedom dans un premier temps, ce qui fonctionnera un temps, puis je me retrouverai à la ramasse. A ce moment là, je partirai sur une autre solution, à mon grand regret, mais vous ne me laissez pas le choix !

    • Gngh dit :

      Bonjour,

      Je suis tout a fait d’accord.

      Petite précision cependant, l’appli android est gratuite sur le GooglePlay.
      C’est le plugin qui est payant, mais sans le plugin tu ne peu pas utiliser l’appli. 😉

      Nous nous sommes tous enflammés sur Jeedom et ses possibilités.
      Le constat est amer vu l’investissement mais elle n’est pas prête à gérer une maison.
      Je me vois mal cette hiver ne plus avoir de chauffage pendant plusieurs jour.
      Il faut quand même se rappeler que la domotique gère notre quotidien, notre confort et notre sécurité.

      Même si vos choix sont discutable pour nous les « anciens ».
      Je sais très bien que vous faite ce que vous pouvez avec ce que vous avez.
      Et depuis le début la communauté de Jeedom est omniprésente et nous voulons que Jeedom progresse et devienne une appli de domotique adoptée par le plus grand nombre.
      Cela veut dire aussi des personnes qui ne sauront pas se connecter en SSH ou descendre une image sur une carte SD.

      Mais si vous voulez rivaliser, et je vous le souhaite car Jeedom le mérite, avec la vera, Eedomus, Fibaro etc…
      Il va falloir mettre les petits plats dans les grands (mais pas pour tout changer 😉 ) mais fiabiliser l’ensemble.
      Je sais que c’est moins valorisant la chasse au bug car on a l’impression que le reste n’avance pas mais c’est quelque chose d’essentiel surtout pour quelque chose destiné au public.

  25. Sshafi dit :

    Bonjour, je vais essayer de répondre à quelques inquiétudes lues dans les billets ci-dessus à propos du nouveau mode esclave :

    – Un jeedom complet sur l’esclave sera plus lourd qu’actuellement : Si vous gardez l’esclave juste comme antenne de protocoles, il ne sera pas beaucoup plus lourd car actuellement tourne sur un esclave : Serveur web/Base Mysql/PHP et les démons des plugins installés. Ce sera identique dans le future mode. Bien sûr si vous ajoutez des scénarios, des scripts, … Ca va alourdir l’esclave mais en même temps ce sont des fonctionnalités qui ne sont pas possibles actuellement avec le mode esclave…
    – Avec un jeedom complet la carte SD va flamber plus rapidement : Comme l’a dit loic avec la v2.4 il y aura une utilisation du cache plus poussée donc si le /tmp est en RAM ça limitera beaucoup les accès sd et de plus en désactivant l’historisation des données sur tous les périphériques au niveau de l’esclave (l’historisation pourra se faire sur le maître) et que vous ne vous servez de l’esclave que pour faire antenne (Pas de scénarios, …) ça limitera énormément les écritures dans la base de donnée. Donc en faisant tout ça les cartes sd devraient ne pas être trop solicitées…
    – Le mode esclave ETAIT un gros plus de jeedom face à la concurence : Il ne disparaît pas ! C’est juste son fonctionnement qui est modifié. Donc celà restera un gros plus de jeedom 😉
    – Sécurisation obligatoire de l’esclave : Pas plus qu’actuellement en utilisation similaire au mode actuel.
    – Reconfiguration de tous les périphériques : Là c’est sûr qu’il va y avoir du boulot à faire côté user, mais loic va diffuser le nouveau plugin bientôt et il l’a dit l’obligation de passer à ce nouveau mode n’apparaîtra pas avant la 2.5 (vers la fin de l’année). Et donc avec le plugin en place sur le maître et les esclaves vous pouvez faire une migration en douceur plugin par plugin, module par module à votre rythme en gardant le reste en fonctionnement. Ce n’est pas une opération à faire en one shot…Et précision : Les modules au niveau du maître serons dans un plugin spécifique, ça ne passera pas par le plugin virtuel.
    – Le temps de remontée d’un évènement distant : Selon nos tests actuels (On commence à peine), le temps n’est pas plus important. Par exemple un toggle entre maître et esclave à travers le web (dns jeedom sur les 2) met moins de 2s chez moi.

    La seule perte pour moi avec ce nouveau fonctionnement est la gestion centralisé des modules au niveau du maître, mais bon ouvrir un deuxième onglet du navigateur pour aller sur l’esclave c’est pas la mère à boire non plus et puis ce n’est pas tous les jours que l’on modifie les paramètres de ses modules. Tout ce qui est affichage est géré sur le maître. Et il y a quand même beaucoup d’avantages à ce nouveau mode :
    – Tous les plugins du market devraient être directement compatible.
    – Possibilité de mettre de l’intelligence au niveau de l’esclave : scénarios, surveillance,…
    – Possibilité de lier 2 jeedoms distants sans vpn, …
    – De multiples possibilités de topologie maître/esclave : Un maître & plusieurs esclaves, Plusieurs maîtres & un seul esclave, Un maître peut être esclave d’un autre maître, …….
    ….
    Un exemple avec une maison secondaire familiale : Un jeedom esclave (Ce jeedom peut lui même être maître de plusieurs esclaves pour couvrir toute la maison) dans la maison secondaire qui a sa propre intelligence pour la gestion au quoditien et qui peut être pilotée/supervisée par plusieurs jeedom qui sont chez les différents membres de la famille…..

    Enfin pour finir par rapport aux remarques sur la stabilité et performance, depuis la v2 (je crois) la team travaille beaucoup à ce niveau là et c’est pour ça que beaucoup de choses ont changées (avec des fois quelques pertes) et c’est justement dans ce cadre là que s’incsrit ce nouveau fonctionnement du mode esclave.

    • Phil dit :

      Merci pour toutes ces infos, certaines, si elles se confirment, devraient se trouver dans le premier message car elles sont peut être en mesure de nous rassurer (planning, nouveau plugin etc…).
      Par contre le coup des 2s, oui je sais ça passe par le web, mais à mon sens ce n’est pas un indicateur qui peut nous rassurer. Pour moi il était préférable de ne pas en parler tout de suite, car qui est capable de dire si ces 2s sont du fait du réseau ou alors du nouveau système, qui dans ce cas pour moi disqualifie la solution. Il y a déjà eu tellement de changement de « timming » sur le déclenchement de nos scénario suivant les versions, si on ajoute encore cet « aléas » cela va vraiment pas le faire.

      A suivre donc (ou pas).
      Bon courage
      Phil

      • Sshafi dit :

        Je ne fais pas parti de la team, je fais juste un commentaire pour essayer d’éclairer un peu.
        De plus je parle de ce que j’ai testé pour l’instant (Et j’ai dis moins de 2s 😉 ) étant parti pour l’instant pour tester ce mode en passant par le web.
        Je cite le retour d’un autre beta-testeur qui lui commence à tester sur sa prod avec du zwave en local (Son esclave est un pi2) : « je n’utilise aucun scenario sur mon esclave et j’ai une charge de 0.06 et c’est quasi instantané les remontées d’infos. En fait, je ne vois aucune différence avec l’ancien mode esclave. »
        C’est tout nouveau donc il va falloir attendre un peu avant d’avoir plus de retours 😉

    • Sshafi dit :

      Je me corrige car je me suis emmêler les pieds dans le tapis….
      Quand je dis : « Et donc avec le plugin en place sur le maître et les esclaves vous pouvez faire une migration en douceur plugin par plugin, module par module à votre rythme en gardant le reste en fonctionnement. Ce n’est pas une opération à faire en one shot… »
      Ca ne sera pas possible, un jeedom esclave (système actuel) n’a pas les infos… pour pouvoir faire fonctionner le plugin jeedom link. Mea coulpa !

  26. Yoguiti dit :

    Super encore une avancée ! Je fais partie des 93% qui n’utilisent pas encore le mode esclave, mais qui attendait que ce mode se stabilise pour l’utiliser.

    La proposition de l’équipe jeedom semble très pertinente, car ça me permet pour les jeedom déportés de faire des scénarios locaux. Par exemple, j’ai des capteurs de mouvement sur mon Raspberry avec jeedom. Toute la gestion des détecteurs est fait en local, et ce jeedom ne rapatriera vers le maître que des informations « presence » ou « personne present » plutôt que de remonter les on off de chaque capteur individuellement.

    Et surtout… C’est générique et logique. Plus de problème de mise à jour des plugin pour la compatibilité avec le mode esclave, etc….

    Mais je ne suis pas développeur, et si l’équipe pense que c’est ce qu’il y a de mieux, je leur fais 100% confiance, je n’ai que hâte de tester.
    J’espère que ce sera dans pas trop longtemps.

    Encore merci pour cette innovation et ce super produit qu’est Jeedom.

    Bonne continuation !

    Yoguiti

    • loic dit :

      Bonjour,
      Le plugin sera bientôt disponible il ne manque que l’icone et c’est bon et il sera bien sur gratuit. Il faudra bien lire la documentation.

  27. Anakin dit :

    Bonjour,

    Tout d’abord merci pour tout ce travail fourni.
    Déjà niveau communication, j’ai lu que ce n’était pas votre tasse de thé. Je dois signaler tout de même que j’allais tenter le mode esclave/maître jusqu’à ce que la roadmap tombe. Quand j’ai vu qu’il était précisé (à l’avance) qu’il y aurait une reconfiguration à faire j’ai mis en stand-by. Donc je trouve que la communication a été bonne. Après pour ceux qui sont déjà dans un mode/esclave je peux comprendre la frustration. Mais il y a du bon dans la nouvelle configuration comme pouvoir utiliser un scenario sur n’importe quel jeedom. Après c’est vrai que ceux qui utilisent des raspberry vont être un peu juste niveau hardware. Ils risquent de devoir changer de matériel, refaire la configuration et je peux donc comprendre que l’envie de partir vers un autre système domotique se pose.
    J’utilise actuellement un raspberry 2 pour une trentaine de modules ZWAVE. Cela devient juste et je vais tenter l’aventure jeedom sur un odroid c2 pour ne plus être embêté niveau performance. Le coup est un peu plus conséquent qu’un raspberry mais il reste un meilleur compromis pour les performances jeedom. Si je vois que la solution peut être pérenne alors je n’hésiterais pas à mettre également mes esclaves (on se comprend) sur ce hardware. Donc la nouvelle solution (plus lourde) sera supportée correctement.
    Concernant les MAJ, j’ai eu pas mal de soucis lors de certains passages mais bon, vous êtes une petite équipe et je me doute que tout ne peut pas être testé non plus. De plus je si j’avais fait des images de la SD je n’aurais pas galéré autant. Et puis, il ne faut pas être impatient et installer la mise à jour la semaine de sa sortie (surtout quand il n’y en pas eu depuis plusieurs semaines).
    J’ai également eu envie de partir vers un autre système genre domoticz. Mais jeedom a quand même a quand même plus d’avantages (à mon niveau) et certains plugins n’existent que sur jeedom (cozytouch par ex).
    Donc pour résumer, bravo pour le taf, et niveau communication vous pouvez certes faire mieux mais ce n’est pas la catastrophe non plus. Ce changement de cap fait certes perdre une fonctionnalité qui vous démarquez de la concurrence mais rien n’empêche que si avec la BOX, vous arrivez à faire grossir un peu la société, que vous reveniez en arrière dans quelques temps (ou dans un nouveau plugin payant par exemple).
    Bon courage.

    ++

  28. TouFou dit :

    Bonjour,

    Une question concernant le jour J du déploiement du nouveau mode: Quand jeedom me proposera la mise à jour (2.4 je crois), que devrais-je faire:
    – Faire la mise à jour sur le serveur et jeedom installera jeedom sur les « esclaves »?
    – Faire la mise à jour sur le serveur et ensuite ecraser/installer jeedom sur les « nouveaux esclaves »?
    Dans les deux cas, est-ce que lors de cette mise à jour Jeedom préviendra de facon explicite? histoire de ne pas faire la mise à jour du serveur et que les esclaves ne soient plus compatibles….

    Bon courage pour le taf à venir et un grand bravo à tous ceux qui participe au développement de jeedom. Depuis 2 ans, on voit vraiment une maturité apparaître dans le système. Meilleure stabilité, fonctions toujours de plus en plus simple et intuitive, etc… C’est pas la première fois que je fais des louanges mais quand je vois les commentaires négatifs (justifiés ou non) sans avoir vu la solution à l’œuvre, ça me semble important de montrer qu’il y a aussi beaucoup de gens TRES satisfaits!

    ps: J’ai lu les 3/4 des commentaires, je n’ai pas vu la meme question, si elle a déjà été postée, dite le moi je fouillerai.

    • loic dit :

      Bonjour,
      Pour le déploiement le mieux sera de repartir d’une installation vierge, pour le zwave il suffira de faire resynchroniser pour retrouver les équipements sans les reinclures. Pour les autre protocoles il faudra les créer à la main en repassant bien les ID et ca sera bon.
      En ce qui concerne le passage sur le maître la prochaine version de jeedom permettra le remplacement de commande et la copie d’historique. Ca prendra un peu de temps pour faire le passage aux plugin jeelink mais il n’y aura pas besoin de repasser sur tous les scénarios et il n’y aura pas de perte d’historique.

  29. yoguiti dit :

    Bonjour,
    J’ai enfin teste le plugin … qui marche super du premier coup. Rien a dire, les info sont remontees instantannements. C’est vraiment un gain enorme et au moins le fonctionnement est clair et transparent. Encore merci !
    Juste 1 question qui a deja ete abordee:
    je sais que les widget sont « perdus » lorsque les objets sont transferes au jeedom cible. Certains peuvent etre remis manuellement, mais pour d’autres (quand cela est integre a un plugin par exemple kodi, squeezebox, etc …) les widgets sont completements perdus. Est-t-il prevu dans une future version de les inclure ou pas?

    Ensuite, mais bien moins important (et non bloquant), ce serait pratique si l’on avait un export « automatique » (en option) de tout le jeedom source sans devoir ajouter manuellement chaque equipement. Cela eviterai tu travail. Heureusement, on peut partager les equipements (et pas les commandes, car cela ferait beaucoup!)

    Encore merci pour ce super boulot!

    yoguiti

  1. 21 août 2016

    […] Nouveau mode esclave : Blog Jeedom […]

  2. 18 novembre 2016

    […] différents Raspberry pour divers usages : Esclave domotique (plus pour longtemps), Mediaserver sur Librelec ou Platine SqueezeBox pour écouter PNL France Culture dans ma salle de […]

Laisser un commentaire

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