on ne peut que te remercier, clair que ça a bien changé 
3 « J'aime »
Hello @g0m
Je suis en phase avec ta synthèse mais il y a quand même un biais : c’est difficile de comparer une application que l’on manipule depuis 5 ans (et avec laquelle on a ses habitudes) avec un truc plus récents.
N’utilsant plus que HA depuis maintenant plus de 6 mois (et en ayant tout migré), du coup, certains aspects sont à relativiser :
C’est vrai qu’il faut s’adapter mais tu as à probablement du faire pareil à un moment avec jeedom
Au final le YAML c’est pas plus mal. Le cap c’est la syntaxe, ensuite c’est intuitif
Là clairement on retrouve le notion de plugin… C’est exactement pareil. Sous HA par contre, c’est bien moins dépendant de l’ensemble : fini les réinstallations de dépendances, et les bidouilles sur le linux pour corriger… C’est de moins point de vue un gros avantage
A comparer avec les ID, les scénarios, les déclencheurs, les variables, les fonctions custom etc… Bref c’est lié à apprendre le vocabulaire et c’est plus compliqué quand on a des habitudes bien ancrées
C’est clair. Encore qu’avec le temps et l’usage du YAML c’est moins vrai. Mais ça reste pas accessible pour tout le monde malgré tout. Clairement Nodered est un indispensable.
Là aussi c’est subjectif. Sous jeedom, replacer un ID par un autre c’est pas toujours évident même pour un utilisateur confirmé… Au moins sous HA, tu peux mettre ce que tu veux, donc ça offre un peu de souplesse. Pour ma part, la notion de pièces que j’avais dans jeedom n’est pas transposable dans HA. Il y a bien des pièces aussi, mais ça sert à quasi rien sauf à informer. Défaut HA donc
Puisque tu cites dans les défauts jeedom les aspects de compatibilité, alors il faut aussi noter que ça existe sous HA (breacking changes). La différence majeure, c’est que c’est toujours explicitement indiqué dans HA (ils ont un vrai changelog) et que la gestion des mises à jour / retour arrière est bien plus simple que de devoir faire une restauration (et de perdre une partie de l’historique) de la totale.
Et pour ma part j’ajouterai un point positif chez HA : il n’y a pas de mise à jour dans ton dos, ou de suppression de package à la volée, voire du chmod 777 en pleine nuit … Alors certes un novice s’en fiche un peu, mais personnellement j’ai du mal à ne pas avoir le controle…
Malgré tout ça reste un choix personnel, Jeedom ou HA les deux fonctionnent tant qu’on y est bien pas besoin de partir
Bon pour le coup oui ca a bien changer mais pas comparable au screen du dessus.
Surtout que j’imagine qu’il a le même rendu sur mobile sans faire un design « spécial » pour la résolution mobile?
Euh ben j’ai le même rendu en mobile aussi …
Pour le pas comparable, on va pas comparer les gouts et les couleurs en effet, débat sans fin … Si tu préfère la v3, libre à toi, j’ai aucun soucis avec çà.
alors la tu n’es pas en mode design donc c’est pas comparable. Sur mon jeedom pour avoir qq chose de beau je devais choisir la résolution de l’écran (mode design) dès que je passe sur une tablette ou mobile il fallait faire un design propre au support.
Sur ton screen il n’y a aucun design juste les objets sur le dashboard.
Mais comme tu l’as dit c’est les gouts et les couleurs… les point importants c’est les +/- débattus plus haut.
Rien de fou, arrête, le design est ouf!
1 « J'aime »
Pour moi le Dashboard n’est qu’un outil de récap des équipements en effet. Au quotidien, j’utilise plutôt le design pour naviguer dans mon Jeedom.
Et ensuite est arrivé Jeemate 
l’ appli Jeedom tant attendue qui correspond à mon utilisation de l’appli Maison sur iPhone en prenant en compte les spécificités Jeedom (dont les plugins et designs pour un changement en douceur entre autres), une équipe de dev ultra réactive, un bonheur total du coup 
Et la compatibilité multi-plate-forme transparente inédite, la totale 
(Avec en bonus non visible, l’utilisation de Flutter particulièrement adaptée et performante pour cette utilisation)
pour le coup c’est vraiment ouf et je prend connaissance du bouzin. Je vais regarder de plus prêt.
Ce qui m’a toujours fait fuir dans Jeedom, ce sont les designs.
On peut faire de superbes designs mais, sauf erreur de ma part (que l’on me corrige si je me trompe), il faut faire un design par taille d’écran… Enfin sauf si les tailles changent peu…
Donc un design pour mobile, un design pour ordinateur… Si madame a une autre taille d’écran de smarpthone, encore un… Bref…
Et là je trouve que les App (JeeMate et JC) comblent le trou pour les mobiles (sauf que pour ma part). Surtout avec les versions Windows et MacOS qui arrivent (JeeMate).
Mais d’un autre côté, il faut tout de même souligné que l’on peut assez facilement faire des designs sympas avec les outils mis à disposition de Jeedom. Sans compter les partages de codes qui aident bien les débutants, les différents tutos, etc.
1 « J'aime »
Les designs (ou en tout cas leur maintenance, surtout apres le passage à la v4) ont été un vrai problème pour moi. J’y avais en effet passé un temps fou (principalement car je tatonnais sur le CSS) et quand la v4 est arrivé j’ai pas mal de choses qui ont été cassées.
Quand je vois Jeedom Connect et JeeMate, je fais le meme constat que toi: ca semble en effet combler une grosse lacune de Jeedom.
Merci pour ton retour.
Oui tout est à relativiser mais je reste convaincu que Jeedom est plus facile à prendre en main.
Le YAML il ne faut pas s’en faire une montagne dans HA je suis d’accord, mais ca reste un peu geekos quand meme.
Pour les plugins et ce concept de « kit » dont je parlais, à voir avec le temps. Si comme tu le dis c’est plus stable et facile à maintenir sur la durée…
Pour la nomenclature, franchement je reste convaincu que ca mériterait d’etre simplifié sur HA. Un simple exemple: Pourquoi avoir Blueprints, Automation, Scripts et Scenes (voire templates)? Dans Jeedom on a Scenarios et c’est TB comme ca.
Pour ce qui est de renommer les entités, il m’arrive que HA me dise simplement que je ne peux pas renommer leur ID(comme par exemples pour les devices Xiaomi). C’est d’ailleurs assez lourd car une entité a un nom et une ID or on ne peut utiliser que l’ID dans les automations et nodered. Je me retrouve donc à devoir travailler avec un capteur qui va s’appeler par exemple binary_sensor.door_window_sensor_158d0001b148dc au lieu de Bureau.Fenetre.Capteur. Obligé d’avoir un fichier excel à jour avec les ID qui correspondent aux bons devices qui eux meme correspondent aux entités
Dans jeedom, quand j’ajoutais un device, je pouvais renommer toutes ses commandes (equivalent d’entite) et travailler avec ces noms.
Bref, aucune solution n’est parfaite et chaucun saura trouver son bonheur j’imagine.
A date je n’envisage pas de retourner sur jeedom mais continue de suivre ses progrès avec plaisir.
Je suis assez d’accord. Mais la différence est de plus en plus faible (y compris en comparant les 6 derniers mois,)… Autant par la logique qui est plus rigoureuse sous HA que par la tendance au remplacement du YAML par la config toute graphique.
Quant aux scénarios, clair que de base HA c’est trop complexe, mais avec Node-red c’est à des années lumières d’avance sur ce que l’on peut faire sous jeedom.
Et puis vous en parlez dans le sujet mais les soucis de taille d’affichage, des variations d’affichage,css, mobile etc… c’est natif chez HA (et plus réactif que le php) et on se refait pas tout au changement de version.
Le dernier véritable atout de jeedom, ça reste ce forum français… L’équivalent HA est moins actif, il y a moins de monde, mais les réponses sont toutes aussi rapides et pertinentes.
Tu as les mêmes défauts par exemple 3 add-ons zigbee versus 3 plugins zigbee donc ça pose un problème de choix au départ… Mais les plugins sont indépendants les uns des autres, donc pas de souci de version de python ou de npm qui cohabitent mal, ni de droits, ni installation de dépendances… Et tu peux revenir à la version que tu veux déployer pour chacun d’eux… Donc si la version X.Y est plus à ton gout que le X.Z ça prends 10 secondes et ça fonctionne direct…Y compris sans backup et sans perte de données
Ce principe est identique pour le core.
Et je parle même pas du cycle de vie : Quand je suis partie la version jeedom 4.2 que j’utilisais au quotidien proposait de belles avancés… Bon ben elle est toujours pas en stable… Du coup plutôt que d’avoir des sauts de puce entre les versions, on se retrouve à avoir 10000 fonctions nouvelles d’un coup (et tous les incidents qui vont avec). Et si par malheur la structure de la base est modifiée, adieu le retour arrière facile
- Automation => Scénario jeedom
- Blueprint => Template scénario jeedom
- Script => Plugin Script jeedom (dans HA c’est natif
) - Scenes => Plugin Mode (natif HA, et plus intuif), mais aussi assez similaire aux scènes du plugin GH
Le découpage n’est pas le même (core/plugin/add-ons) mais les fonctions sont similaires, du coup la question du pourquoi a sa réponse : ça fait pas la même chose
J’ajouterai pourquoi un design / dashboard / synthèse / vue / vue 3D pour jeedom ?
A voir en détails par quelle intégration tu passes, mes équipement Xiaomi sont tous nommés à ma sauce sans souci. Le seul cas ou ça râle c’est quand le nom existe déjà (ou existe encore dans les historiques)
Je suis d’accord que le principe de objet => action sous jeedom est plus intuitif que type => entité sous HA.
Par contre renommer les noms des commandes, ce n’est pas pertinent sous jeedom… Il y a plein de trucs ou il faut se plier à la syntaxe jeedom (les on/off si on veut les boutons/retours/stats qui fonctionnent) et attention aux doublons quand il y a recréation des équipements (la màj de rfxcom en python par exemple)
Au début, je m’étais dit que je gardais ma config jeedom, parce que bon, les premiers jours, c’était pas si clair. Mais très honnêtement, je pourrais plus faire le retour arrière sous jeedom.
La difficulté m’est à mon sens pas dans la prise en main (pour peu qu’on soit assez logique dans sa tête) mais dans la bascule de l’un à l’autre. Globalement les habitués de chaque solution resteront dans un domaine qu’ils maitrisent mais je n’ai pas connaissance par contre de cas de bascule après 3/4 ans d’utilisation de HA vers jeedom… L’inverse existe pourtant.
2 « J'aime »
Rien de coucou, j’hallucine. Il est très sympa ton design
@naboleo, tu traines encore par ici 
.
Je pensais que tu avais quitté notre navire.
Content de te voir dans la communauté
Je pense que même si HA est un projet déjà ancien (10 ans) il reste très jeune pour ses fonctions matures. Donc pour l’instant il est tellement en progression et récupère des fonctionnalités intéressantes rapidement que le chemin HA vers autre chose n’a pas vraiment de sens.
En plus le communauté HA est encore assez soudée. Une fois qu’elle aura bien clashée une ou deux fois, qu’il y a aura des forks ou des dissensions, qu’on aura trois applis mobiles et même pas une officielle à jour, que certains pans de HA resteront à l’abandon faute d’intérêt, peut être que la situation sera moins évidente.
Cependant il y a une écoute extraordinaire des retours utilisateurs, les décisions sont documentées, certains choix sont remis en cause s’ils posent problème, jusqu’à présent le projet est très bien géré en concertation. De ce que je vois à mon niveau.
Mais vu l’approche prise, et la maitrise totale par la communauté, j’ai moins d’inquiétude sur le devenir de HA que de Jeedom.
En tous cas je ne peux que confirmer. J’ai vu autour de moi les gens abandonner leur solution domotique diverse vers HA. Au point que je ne connais plus personne dans mon entourage proche qui tournerait sous Jeedom. C’est fini. Plus de Domoticz non plus.
1 « J'aime »
Merci. Je traine encore de temps en temps pour voir ce qu’il se passe ici, mais c’est pas un véritable retour…
10 ans d’existence en temps informatique c’est long… C’est aussi à peu prêt l’âge de jeedom et les cycles de vie sont comparables, y compris avec la sortie des box et des nouvelles box. Je trouve que les choix techniques fait par HA sont sans aucun doute plus pérennes / actuels. Et c’est probablement ce qui permet et permettra une adaptation plus rapide à l’avenir.
Python 2.7 ça n’existe plus chez HA. Debian 11 c’est la base supportée le mois suivant sa sortie… Jeedom n’a pas encore franchis le cap sur ces 2 points.
Possible mais c’est pas arrivé chez HA… Jeedom est en avance de ce côté là. Et que dire de zwave ou de l’application mobile officielle qui stagnent.
Malgré tout je suis pas certain que ça arrive tout de suite. Niveau capacité de développement, taille de la communauté (mondiale), l’échelle n’est pas la même… Je pense que le seuil critique est très largement dépassé pour ha.
Oui c’est assez bluffant, comme l’ensemble des sources sont publiques il y a en plus beaucoup de contributions externes, qui sont réintégrées dans le core ou les add on… Et au final les choix sont vus avec beaucoup plus de points de vue externes et d’expertises techniques, les décisions sont de vrais consensus… Tant que ça reste ainsi, je ne pense pas que la situation de crise soit possible. Ton opinion sur l’avenir semble en tout cas assez proche de la mienne
Malgré tout jeedom ça reste un bon produit. Mais j’ai l’impression que la stratégie est tourné vers les professionnels. C’est sans doute un marché porteur en France. Je ne sais pas dans quelle mesure c’est pérenne et bon pour les utilisateurs individuels par contre.
2 « J'aime »
J’avoue que j’étais dernièrement assez inquiet. Le fait de voir une nouvelle ligne de boxs pour particulier et pro me rassure un peu. Reste à voir si la 4.2 sort bien cette année, et les évolutions sur les points les plus problématiques de Jeedom.
Sans donner de date bien sûr, la 4.2 est mure et c’est l’idée.
Le développement n’a jamais été si prolifique que ces deux dernières années (Core, traductions, docs etc). Et il y a eu énormément de dialogue entre devs et bêtatesteurs sur le cycle v4, ces derniers remontant beaucoup de choses, souvent corrigées dans l’heure (encore merci à eux même si ils coutent cher en café ).
Pour moi, en tant que pur utilisateur avec une prod conséquente et toute la maison automatisée, contrôle vocal etc, le seul point négatif actuellement est une véritable app mobile avec gestion des droits, gestion de plusieurs boxs/comptes (maison/boulot) etc.
HA est clairement un super produit aussi, et c’est tant mieux pour tout le monde Heureusement qu’on a pas tous les mêmes fringues, voitures, maisons etc … 
Y’a une vie en dehors de la domotique 
3 « J'aime »
On n’est pas dans le même univers 
Un projet opensource peut etre vu comme un bien public, commun. C’est pas nécessairement comme un produit commercial.
Ca ne t’enlève pas ton libre arbitre de choisir une solution parmi ce qui existe et l’avantage de faire ces choix, mais on en n’est pas à choisir Renault ou Peugeot là, tu as un socle commun que tu peux modeler selon tes besoins, dans certaines limites.
Donc pour moi un intérêt général à se rassembler autour d’un projet plutôt que de rester dans son coin. C’est comme ça que je vois les projets libres.
Clairement ! Et tu n’es pas étranger à cette activité intense 
Merci à toi
Quant aux méthodes de dev, HA est industrialisé : intégration continue, tests automatiques, pré validation des PR, roadmap et j’en passe. C’est juste pas comparable