Domotique : Jeedom dévoile sa feuille de route pour 2020 et plusieurs gros chantiers

Domotique : Jeedom dévoile sa feuille de route pour 2020 et plusieurs gros chantiers

Et le design ?

Avatar de l'auteur
Sébastien Gavois

Publié dans

Hardware

05/02/2020 4 minutes
29

Domotique : Jeedom dévoile sa feuille de route pour 2020 et plusieurs gros chantiers

Cette année, Jeedom prévoit de nombreux changements, tant au niveau de ses services, de ses plugins ou de son application dont la v4 est attendue. Si la société donne les grandes lignes, elle ne détaille pour le moment pas ses priorité ou son calendrier précis.

Jeedom a commencé l’année en fanfare avec des indisponibilités en série à cause d’incidents sur son infrastructure hébergée chez Online. Mi-janvier, une migration de la communauté « sur la nouvelle infrastructure » a été effectuée. Il y a trois semaines, un message annonçait le retour de l'ensemble des services.

Le travail sur la nouvelle infrastructure continue

La société spécialisée dans les solutions domotiques peut donc revenir à ses fondamentaux et présente sa roadmap pour 2020. L'ensemble est encore un peu flou. Il ne s'agit d'ailleurs que d’une partie des nouveautés, « quelques surprises » devant être présentées plus tard dans l'année.

Une partie du travail consiste d’ailleurs à continuer de lourds changements lancés il y a quelques mois. C'est notamment le cas de la nouvelle infrastructure qui doit permettre de « traiter l’ensemble [des] services en ligne (SMS, backup, …) ou basés sur le cloud (Google, Alexa, …), de façon optimisée ».

Les utilisateurs doivent ainsi s'attendre de nouvelles fonctionnalités, une meilleure disponibilité et évolutivité, mais aussi des étapes de maintenance et de sauvegarde facilitées. Les services sont migrés petit à petit.

Des solutions maison pour le monitoring et la sauvegarde

Deux gros chantiers qui en découlent sont la refonte des services Monitoring et Backup. Zabbix et Nextcloud (fork de ownCloud) sont ainsi laissés de côté. 

Dans le premier cas, l'équipe promet un « système plus adapté », sans plus de détails. Elle précise que « Jeedom communiquera de façon régulière des informations (notamment celles de la page santé), et il vous informera en cas de problèmes où quand il n’aura pas reçu d’informations de votre Jeedom depuis un certain délai ».

Pour les sauvegardes, c'est une solution interne qui est désormais développée « afin de pouvoir y ajouter de nouvelles fonctionnalités et répondre à nos exigences de haute disponibilité ». Elle sera « cryptée » – on dit chiffrer ! – et proposera évidemment un dispositif incrémentiel. Mais là aussi on n'en saura pas plus pour l'instant.

Réécriture de Rfxcom, amélioration de Z-Wave et Zigbee

Parmi les autres gros chantiers en préparation, Jeedom annonce une réécriture complète du plugin Rfxcom en s’appuyant sur la documentation de l’API à laquelle la société a enfin officiellement accès. But de l’opération : « supporter l’intégralité des périphériques nativement supportés » par le protocole. 

Le plugin Z-Wave est aussi au centre des attentions afin d’y « intégrer toutes les fonctions et produits Z-Wave, et aussi d’appréhender l’avenir avec l’arrivée des périphériques à base de chipset série 700 puis plus tard des contrôleurs en série 700 ». Du côté de Zigbee, Jeedom dit vouloir être compatible avec « un maximum de produits ».

La v4 en 2020, des mises à jour pour l’application mobile

Lancée en bêta en mars 2019, la v4 de l'application Jeedom sera publiée en version stable dans le courant de l’année. La v3 « subsistera (afin de ne pas imposer de migration comme pour les précédentes versions) ».

L’application mobile, un peu délaissée en 2019, devrait avoir droit à un plan de mises à jour « très actif » cette année. Dans les grandes lignes, il est question d’optimiser la communication avec Jeedom, d’ajouter de nouvelles possibilités et de faire évoluer l’interface utilisateur.

De nouveaux site et blog sont enfin en préparation, avec un moteur dynamique pour le premier et une communication plus active pour le second. Jeedom veut également « mettre à disposition des développeurs tiers une plateforme de gestion du support technique des utilisateurs ». Tout un programme !

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le travail sur la nouvelle infrastructure continue

Des solutions maison pour le monitoring et la sauvegarde

Réécriture de Rfxcom, amélioration de Z-Wave et Zigbee

La v4 en 2020, des mises à jour pour l’application mobile

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (29)


Le sous-titre est juste, Jeedom est extrêmement puissant, les possibilités ne dépendent que du temps qu’on a à y consacrer. Et pour le design il faut également y passer des heures et des heures pour avoir quelque chose de présentable.


La version 4 n’est pas encore sortie ? J’ai la 4.0.38 et pourtant il ne me semblait pas avoir chopé une version beta.


La v4 étant sortie des bois, on espère surtout que tous les plugins étant devenus incompatibles vont suivre, et qu’ils vont prendre le recul sur le solution certes très complète, mais beaucoup trop complexe pour offrir des fonctionnalités offertes “basiquement” par toutes les solutions domotiques en quelques clics : programmer l’allumage / extinction d’une lampe à une heure donnée en 3 clics, recevoir des alertes en cas de mouvement dans la maison sans avoir à créer un scénario fastidieux qui demande préalablement d’avoir installé le plugin “email” puis créé le service qui permet d’envoyer des mails etc…



Et on ne parle pas de l’application mobile, à des années lumière de la moindre application Hue, Xiaomi, Somfy, Ikea…



Va falloir bosser l’expérience utilisateur !


Je suis pour une simplification de la création de scénari sur jeedom. Je trouve qu’actuellemznt on doit consacrer trop de temps à les créer et à vérifier la cohérence. Je propose pour débuter que des modèles soient présent nativement avec adaptation automatique ou via un assistant à nos équipements présents. Après on les modifie ou on s’ en inspire pour faire les nôtres.


C’est quoi Jeedom ?


Super article, très intéressant, je pensais déjà que Jeedom avait de l’avenir, maintenant avec la future intégration de Google Home et de Alexa, ça vas être un bon système de domotique !



Sinon, j’ai relevé deux fautes de frappes ;)



=> Les utilisateurs doivent ainsi s’attendre à de nouvelles fonctionnalités



=> Parmi les autres gros chantiers en préparation, Jeedom annonce une réécrire complète du plugin Rfxcom



;)


Je suis nouveau sur Jeedom et en domotique, et je suis assez d’accord avec les commentaires au dessus. Il faut passer pas mal de temps pour faire des scénarios pas forcement fous. Il faudrait peut-être qu’ils gardent le système actuel pour les trucs aux oignions, et avoir des outils plus grand public pour les scénarios plus courants.
En attendant, je pense que je vais aussi tester home assistant, mais d’après les vidéos que j’ai vu, ça n’a pas l’air bien mieux pour les scénarios (édition de fichier texte).


jeedom a un gros avantage: il a fait partie des pionniers dans le petit monde des soft domotique ouvert et multi-protocole. et il a su fédérer une communauté qui l’a enrichi au point d’être sans doute un (ou le ?) soft qui supporte le plus de protocoles.



Mais le revers de la médaille c’est qu’il traine une stack technique très datée et totalement déphasée avec le besoin initial.
Un serveur domotique c’est un démon qui doit communiquer avec d’autres entités, réagir à des événements et en initier lui même (scénarios, …). Et accessoirement, proposer une GUI pour les interactions avec l’utilisateur.m, entre autre.



Or jeedom a d’abord été pensé en tant que GUI avec une stack techno en rapport: Apache, php, mysql. Un truc dont le concept de base est de répondre à une requête faite par un utilisateur depuis son browser. D’où les contorsions inextricables pour faire rentrer les autres besoins au chausse pied dans cette stack pas faite pour. Genre:




  • Un plugin jeedom zwave, c’est un démon python qui va appeler des pages php à chaque fois qu’un événement se produit, et se fera appeler en retour par le php pour initier des actions.



  • Un scénario qui doit se déclencher à intervalles réguliers, c’est une tâche cron qui va appeler une page php pour initier une action. etc…




Le problème, c’est que comme la plus grosse force de jeedom c’est la somme des plugins et contributions passées, c’est pas demain la veille que jeedom pourra initier un big bang pour changer pour une stack adaptée. Et en attendant il va continuer à accumuler les pansements sur les jambes de bois avec une efficience de plus en plus douteuse.



Perso, si je dois conseiller un soft de domotique saupoudré d’open source et d’un poil de diy, je proposerai sans doute jeedom pour son écosystème. Mais à titre personnel, j’ai fini par le dégager et me coder mon propre soft aux petits oignons.



brazomyna a dit:


Un serveur domotique c’est un démon qui doit communiquer avec d’autres entités, réagir à des événements et en initier lui même (scénarios, …). Et accessoirement, proposer une GUI pour les interactions avec l’utilisateur.m, entre autre.Or jeedom a d’abord été pensé en tant que GUI avec une stack techno en rapport: Apache, php, mysql. D’où les contorsions inextricables pour faire rentrer les autres besoins au chausse pied dans cette stack pas faite pour. Genre:
Un plugin jeedom zwave, c’est un démon python qui va appeler des pages php à chaque fois qu’un événement se produit, et se fera appeler en retour par le php pour initier des actions.

Un scénario qui doit se déclencher à intervalles réguliers, c’est une tâche cron qui va appeler une page php pour initier une action. etc…




Je ne vois pas où est le pb d’appeler du PHP en ligne de commande, c’est parfaitement fonctionnel et plutôt adapté.
Apache est de fait un démon, que le code soit en PHP, Python ou js.node, n’est pas plus inadapté qu’un démon bash habituel.



fofo9012 a dit:


Je ne vois pas où est le pb d’appeler du PHP en ligne de commande, c’est parfaitement fonctionnel et plutôt adapté.




Exemple simple: j’ai un jeedom (soit un site Apache/Mysql/PHP + un plugin zwave (un démon tiers en Python, donc). Je suis l’utilisateur j’ai ouvert mon browser sur une page de jeedom qui me montre l’état des lampes de ma maison. Je ne fais aucune action dans le browser.



Tout à coup, quelqu’un appuie sur un interrupteur, une lampe s’allume ; la page web doit me refléter ce changement d’état et m’afficher le status de la lampe allumée.



Question: comment fait jeedom pour faire ça ; quel est le temps de réponse ; quelle a été la charge induite inutile sur le serveur ?



Réponse: Le démon zwave en pyhton va appeler un script PHP, qui va traiter l’event et le stocker quelque part. Puis le script se termine.
Un peu plus tard, la page web côté browser qui fait du polling avec une requête toutes les 2 ou 3 secondes va appeler la page (core/event.ajax.php) qui recharge complètement le contexte, ré-applique l’authentification de l’utilisateur, etc… etc… Il va ensuite rechercher s’il s’est passé quelque chose depuis ma dernière demande et me renvoie une liste d’évents des changements intervenus dans l’intervalle.



Et si, pas de bol, l’event est arrivé quelques ms après ma dernière reqûete ; je vais attendre 1 ou 2 secondes / la prochaine requête de polling avant d’être informé.



Question efficience et charge serveur, 99 fois sur 100 on aura réveillé le serveur (refait l’auth du user, rechargé le contexte etc… etc…) tout ça pour répondre “nan, y’a rien de nouveau qui s’est passé”.



Niveau 1) latence et 2) efficience, on est au niveau zéro.



A contrario, un petit démon (style nodejs, dans mon cas, ou autre) va tourner en permanence ; je garde tout le contexte en mémoire, pas besoin de le reconstruire à chaque requête toutes les 2 secondes, (ré-authentifier le user, etc…) j’ai une connexion websocket avec le browser ; quand j’ai à le notifier d’un event, on fait du push, le client le reçoit dans la milliseconde qui suit. Et quand il ne se passe rien, la charge serveur est de zéro.




fofo9012 a dit:


Apache est de fait un démon, que le code soit en PHP, Python ou js.node, n’est pas plus inadapté qu’un démon bash habituel.




Que le code soit en PHP, Python ou nodejs, c’est juste un langage, on est d’accord.



Par contre, Apache est un démon qui a un fonctionnement pensé pour réagir quand on lui envoie une requête web, et ne peut pas se ‘réveiller’ de façon spontanée pour faire quelque chose tant qu’une tierce partie ne l’a pas trigger.



brazomyna a dit:


blah blah




Le fonctionnement est strictement identique : un socket qui écoute, un cookie ou une variable de session pour se reconnaitre, la charge est côté browser javascript : https://developer.mozilla.org/en-US/docs/Web/API/notification
Après jeedom est peut-être codé avec les pieds, mais y’a aucune raison de pas pouvoir faire exactement la même chose entre un LAMP et NodeJS.



fofo9012 a dit:


la charge est côté browser javascript : https://developer.mozilla.org/en-US/docs/Web/API/notification




Tu me sors la notification API ? really ?



Ok, tu ne comprends pas plus de quoi je parle, ni même ce que toi-même tu quotes.




fofo9012 a dit:


Le fonctionnement est strictement identique




Ou pas. Mais tu ne sembles pas comprendre de quoi tu parles toi-même.



On va en rester là.



brazomyna a dit:





On se calme un peu. On peut être en désaccord sans être foncièrement désagréable :chinois:



David_L a dit:


On se calme un peu. On peut être en désaccord sans être foncièrement désagréable :chinois:




Ce n’est pas une question de désacoord, le bonhomme exprime un avis en agumentant totalement à côté de la plaque.



Parler de web-notif API quand on est dans le sujet de l’update en push/pull vie des websockets ou du polling en ajax, c’est pas un ‘désaccord’, c’est un non sens.



Si demain tu expliques dans un article que la RAM est un facteur important pour faire tourner plein de VMs sur une machine et qu’un gars arrive en te disant “super pas, tiens v’la un lien, ça passe sans stresser si la carte graphique elle a 4Go de RAM”., tu acquiesces ?



brazomyna a dit:





Désaccord ou non sens, ce n’est pas une raison pour monter dans les tours comme ça ;)



David_L a dit:


Désaccord ou non sens, ce n’est pas une raison pour monter dans les tours comme ça ;)




Si pour toi dire “vu ta réponse totalement décalée je préfère abréger plutôt que partir dans une discussion stérile” c’est “être désagréable” et “monter dans les tours”, pour moi on est dans le registre de l’hyper-sensibilité.



brazomyna a dit:





Tu vois, on peut être en désaccord et se le dire gentillement ;)



brazomyna a dit:





Merci pour l’explication détaillée. Effectivement, Jeedom a l’air peu efficace dans ce cas et cela gâche des ressources.


Est-ce que des membres ici ont testé plusieurs soft du genre et sont capables de brièvement donner leur avis concernant les forces et faiblesses de chaque ?
Je pense par exemple à Home-Assistant.



De préférence sans troll de bas étage hein, je ne veux pas lancer un débat iOS vs Android non plus ;)


Aller je commente quasiment jamais mais je me motive :)



J’ai tourné sur jeedom plusieurs années jusqu’au début de la v3 environ donc mon avis n’est peut-être plus totalement en phase avec les dernières nouveautés.
Mon ressenti : le soft est plutôt pas mal côté fonctionnalité, par contre ça fait un peu amateur : à chaque mise à jour c’était la galère, toujours des bugs à tenter de corriger, un design vraiment pas fou, très amateur, des commandes qui mettent plusieurs secondes à s’envoyer, idem pour les retours des équipements (lampe allumée par exemple), etc. Au faite le vrai problème de jeedom comme expliqué au dessus c’est les techno : php pour faire de la domotique c’est vraiment pas fait pour, du coup c’est plein de hacks pour tenter d’utiliser des librairies d’autres langages. Il y a notamment pas de bus d’événements ce qui est vraiment un gros manque à mon avis (notamment pour la partie interaction en direct).



Après de nombreuses recherches, je me suis intéressé à home assistant qui me paraissait le mieux au niveau des technos sous jacente et de la propreté du projet en général (je suis un développeur).
A cet époque (environ 1 an), la quasi totalité de la conf devait se faire dans un fichier de configuration à la main, rien n’était configurable dans l’interface. C’était pas très pratique mais au moins c’était propre et surtout beaucoup plus stable que jeedom.
J’ai donc migré dessus, et là j’ai commencé à aimer de plus en plus le projet.
Environ toutes les 3 semaines il y a une nouvelle mise à jour qui sort avec de nouvelles features dans l’interface, l’ajout de dizaines de matos supplémentaires supportés, etc.
Il y a juste une communauté incroyable et chaque patchnote est un plaisir à lire.
Aujourd’hui il doit y avoir environ 1500 matériel supportés avec chacun une doc super clair et surtout qui sont stables car intégrés au cœur de home assistant (là où jeedom seul le développeur du plugin peut toucher)
D’ailleurs tout est gratuit et maintenant tout est configurable directement depuis l’interface plus besoin de passer par conf textuel.
Je ne peux que vous le conseiller, même pour développer dedans la doc est ultra complète, c’est juste l’un des projets que je suis le plus satisfait.
Petit point bonus : à chaque mise à jour, il y a une partie breaking change qui permet de savoir ce qui a bougé. Du coup ils continuent à nettoyer le code pour avoir un soft toujours plus propre et puissant, tout en évitant de laisser les utilisateurs perdus comme sur jeedom avec des bugs d’incompatibilités avec des plugins notamment.



Cerise sur le gâteau : je fais maintenant tourné mmet mon home assistant sur mon nas synology dans un container docker. Plus besoin de s’occuper de quoi que ce soit. Pour les mises à jour il suffit de télécharger la nouvelle image docker, faire un clean du containeur (ça garde les datas évidemment) et paf la mise à jour est faite sans rien faire (la migration de python 3.7 vers 3.8 est complètement indolore par exemple, aucune lib python à installer ou upgrade à la main etc.).



Bon je m’arrête la j’ai fais un roman.
J’espère avoir était assez clair.



En résumé :




  • j’ai adoré jeedom au départ car c’était l’un des seuls projets opensource assez complet. Mais à l’usage j’ai trouvé que ça faisait assez amateur, aussi bien au niveau interface que stabilité.

  • je suis maintenant devenu fan de home assistant, c’est juste ultra propre et bien foutu, il existe des tonnes de plugins disponibles pour gérer tout et n’importe quoi, et surtout ils sont tous stables et extrêment bien documentés au contraire de ce qu’on peut trouver sur jeedom avec des plugins bêta pendant des années.



max13fr a dit:


Bon je m’arrête la j’ai fais un roman. J’espère avoir était assez clair.




Super retour d’xp détaillé, merci beaucoup.



J’ai pas personnellement testé home assistant, c’est une solution que j’avais écartée à l’époque (car je suis pas fan à titre perso du python, sa syntaxe me rebute), mais l’architecture technique du projet semble très bien pensée et ‘propre’ et la communauté active.



Perso, j’ai une installation principalement basée sur du zwave (quelque chose comme 80 modules à ce jour), et un gros atout de Jeedom était la qualité du support des périphériques zwave via le plugin initialement développé et maintenu par Nechry. (*)



Le support du zwave était avancé au point que perso, même après avoir décidé de me coder ma propre solution software perso pour dégager complètement jeedom, j’ai pendant encore longtemps continué à utiliser cet unique plugin comme proxy pour gérer mon zwave (temps révolu désormais).



A ce propos, je sais que home assistant supporte le zwave, mais je ne sais pas à quel point le zwave est ‘bien’ supporté, c’est à dire avec tous les raffinements qui font à la fois sa richesse et sa complexité. et à quel point il gère bien jusqu’aux périphériques zwave les plus exotiques.



(*) Pour la petite histoire, depuis 2017, c’est Jeedom qui a repris en interne le code du plugin (de façon moyennement propre d’ailleurs, dans le genre “t’es sympa, tu as passé un temps énorme en bénévole pour faire avancer un plugin vital pour Jeedom, maintenant on te reprend ton travail pour pérenniser notre business sans que t’aies ton mot à dire ni aucune compensation”. ambiance.


Essayer Home Assistant, c’est l’adopter en effet ;)



La démo parle d’elle-même : https://demo.home-assistant.io et c’est enfantin à configurer.



KiaN a dit:


Essayer Home Assistant, c’est l’adopter en effet ;)La démo parle d’elle-même : https://demo.home-assistant.io et c’est enfantin à configurer.




Ce que je regrette dans la plupart des solutions software de domotique c’est qu’elles sont plus l’immense majorité axée sur la fourniture de fonctionnalités de l’ordre de la ‘super télécommande’.



J’entends par là un axe de développement essentiellement orienté vers la fourniture d’une solution qui centralise, stocke, historise les informations d’une part, et fournit une GUI pour effectuer des actions, y compris quand on est loin de sa maison.
C’est déjà très bien (et ça correspond sans doute à ce que recherchent en premier lieu la plupart des utilisateurs qui rentrent dans le monde de la domotique).



Mais pour moi la plus grosse valeur ajoutée de la domotique c’est pas ça. Pour moi c’est la possibilité de définir facilement des scénarios et de la logique parfois un peu plus complexe qu’un IFTTT pour que la maison fasse des choses toutes seules, sans même que j’ai à lancer l’action à la main. A elle de prendre des décisions pertinentes en autonomie (tout en respectant évidemment toujours n’importe quelle action manuelle qui prend alors le pas sur une décision prise de façon ‘automatisée’)



De ce côté là, toutes les solutions proposent des mécanismes pour réagir à un événement simple et effectue de la logique et des actions en regard, mais dès qu’on veut raffiner un peu le truc on a vite tendance à être limité.



Un scénario du genre “lance telles actions quand il n’y a plus de mouvement dans la maison depuis plus de cinq minutes”. Souvent, tu vas être bon pour te taper une liste de périphériques à hard-coder dans ton scénario (faute de pouvoir faire une sorte de “SELECT all PERIPH qui ont un type MOUVEMENT) + un espèce de tâche récurrente qui se réveille toutes les 5 minutes pour voir si la condition était déjà remplie il y a 5 minutes et l’est toujours, etc…


A prioi, tu peux faire ça facilement sur Home Assistant :



https://www.home-assistant.io/docs/automation/editor/
https://www.home-assistant.io/docs/scripts/
https://www.home-assistant.io/docs/scene/editor/



Je n’ai pas encore tenté mais c’est prévu.



KiaN a dit:


A prioi, tu peux faire ça facilement sur Home Assistant




La notion de scénario, de déclencheur, etc… oui: c’est à peu près commun à tous les soft domotiques. Mais entre un moteur basique de ‘super télécommande + super programmateur’ et un moteur capable de proposer plus d’intelligence et d’autonomie, tout dépend des “raffinements” que proposent lesdits moteur de scénarios.



Ceci dit, home assistant semble un peu plus étoffé à première vue.
Merci pour les liens, je vais regarder ça dans le détail.


En ce qui me concerne, le point fort de Jeedom (je l’utilise depuis +3ans) c’est le moteur d’interaction .



J’aurais beaucoup de mal à m’en passer.



Concernant les scénarios, Jeedom est très (trop ?) puissant de ce côté. Il n’y a rien que je n’ai pas réussi à faire (même la gestion de plusieurs capteurs de présences) sans trop prise de tête. Le problème est surtout qu’il y a plusieurs façons d’arriver à un même résultat.



Pour la partie dette technique, je suis d’accord avec @brazomyna. Mais de grosses améliorations ont déjà été apportées ( peut-être un jour les ws …)



La WebUI s’est aussi améliorée avec la V4 et le moteur de design ainsi que la création de widget s’est grandement amélioré. (Je n’ai que très peut l’usage de la WebUI, car un système domotique se doit de se faire oublier)



Sur l’instabilité des MàJ, il y eu de gros couacs (je ne me jette jamais sur les MàJ et je fais un snapshot de la VM avant), là encore il y a eu un gros travaille de fait mais ça reste encore aléatoire, surtout sur les plugins tiers.



Le gros point noir de Jeedom, de mon point de vue, c’est justement les plugins tiers. Il y en a de très bon qui deviennent vite indispensables mais souvent maintenus par une personne. Le jour où la personne n’est pas/plus dispo, c’est problématique.



(c’est la première fois que j’écris autant sur Nxi/IH)



max13fr a dit:


Aller je commente quasiment jamais mais je me motive :)




Je te remercie bcp sur ton commentaire.
J’hésite pas mal a propos de ma future solution domotique, et je ne suis pas motivé pour aller vers du proprio ficelé, et très sceptique sur la qualité/pérennité de ce que je pouvais faire avec Jeedom. La pérennité, cela comprend à continuer à être motivé à maintenir un truc qui me convienne (montée des versions, qualité de l’architecture…).
Je vois ce que je vais essayer en premier.


merci pour les coms et les comparaisons :)
je teste Jeedom depuis janvier (en V4 sans que ce soit une BETA), mais sans grands raffinements. Je teste avant de déménager dans une maison, où je vais faire du contrôle de présence et d’ouvrants (pas en alarme je précise). Pour l’instant Jeedom me satisfait, mais j’avoue que le côté “affichage” (WAF oblige…) n’est pas très user-friendly. je n’en attends pas non plus une maison intelligente, mais plutôt une simplification et des alertes toutes bêtes, ou des infos de conso eau/électricité/gaz dans le futur.
Du coup je vais regarder HASS ;)


Perso je suis parti sur Jeedom, comme première solution après un tour assez rapide de solutions existante.



La solution fonctionne, mais on sent quelques limites du à son archi. Et franchement l’appli mobile (payante !) est juste honteuse.



Heureusement, mon utilisation de la domotique est relativement limitée (chauffage et quelques lampes). Mais je me tâte à changer…