Répondre à ce post entièrement ferait dériver le fil principal.
Je peux toutefois en discuter avec toi en MP sur mon point de vue concernant les besoins de l’entreprise (version LTS) et ceux d’un utilisateur (fonctionnalités diverses), d’aide sur le projet, du fork ou d’HA.
La demande principale de ce fil est qu’on ait une communication de la part de Jeedom, notamment sur sa roadmap.
Les autres points qui ont été abordés ici par les différents post n’est que le résultat de la crainte générée.
Je ne vois pas en quoi l’un serait incompatible avec l’autre. Tous ceux qui génèrent du biz intégration sur des produits open source forkent de manière générale.
J’ai installé hier soir HA OS sur VM syno. Install en hybride avec connexion aux MQTT, dongle Zigbee toujours sur l’Atlas. Du no brainer, hyper simple. Pas encore creusé l’aspect scénario ou équivalant HA. A voir dans les semaines qui suivent.
En phase. Les intégrateurs vivent sur ces upgrades. Mais Jeedom est il une solution uniquement pro ? Un fork ? Les éditeurs Cloud du type Salesforce et autres ServiceNow te propose de choisir. Sur leur solution non privée ca upgrade tous les 3 mois.
Rien compris au reste de ta diatribe.
Sur la dernière phrase je pense que tout le monde travaille dans une entreprise. On est tous d’accord ce n’est ni l’enfer ni le diable
Pas compris le // entre bidouilleur informatique et HA. Je n’aurai pas mieux compris si le // était fait avec Jeedom.
Bon je stoppe là.
Je réagis sur ce dernier point et je repense à l’initative des quelques devs de créer un market alternatif https://nextdom.github.io/. Initiative tuée dans l’oeuf par jeedom SAS refusant tout ticket sur leur box et SP si installation de ce market alternatif. En un mot tu installais un plugin légacy mais à jour sur ce market alternatif, du type MiFlora (ou autre j’ai oublié) et refus par Jeedom SAS d’intervenir sur un ticket plugin Zwave core …
Cette initiative semble en sommeil. Il aurait fallu persévérer plusieurs années pour se faire accepter comme partenaire fiable.
Mon intérêt pour jeedom est, à terme, de monter une solution pour mon usine et objectivement, je n’utiliserai que des plugins officiels ou privés, développés spécifiquement par Jeedom SAS avec un partenaire capable d’intervenir en backup si besoin.
Un peu idéaliste, j’ai travaillé avec pas mal de startup dans le domaine informatique, ERP, gestion de production et la plupart ont disparu ; ça coute alors très cher à remplacer. Donc je comprends que Jeedom SAS soit prudent …
La communauté Ubuntu fonctionne relativement bien parce que la plupart du temps il y a un travail de groupe sur les développements d’applications et lorsqu’un développeur se retire, les projets ne meurent pas pour autant.
Ne faudrait-il pas que la communauté Jeedom s’engage à maintenir les plugins abandonnés par leurs développeurs pour garantir une confiance durable ? Quitte à imaginer un label « Maintenu par la communauté »
On a vu par le passé des plugins passer d’un dev à un autre, comme jMQTT par exemple et heureusement car il fait partie des plugins qui devraient même faire partie du core ou en tous cas êtres suivis et supportés pleinement par jeedom SAS.
Sans ce genre de plugins tiers Jeedom ne serait tout simplement plus en mesure de faire face aux évolutions aujourd’hui.
Le souci réside dans le fait qu’un ou deux développeurs pour un plugin tiers ne suffisent pas à garantir sa pérennité et que même le passage en legacy ne suffit pas à soutenir une évolution positive des plugins, tout au plus un maintient, par manque de ressources probablement.
La communauté ne dispose malheureusement pas d’assez de membres avec les compétences et la volonté de s’investir.
De plus, le modèle adopté par Jeedom SAS ne semble pas particulièrement les encourager. Ceux qui ont à la fois les compétences et la passion finissent souvent par se tourner vers des solutions entièrement ouvertes, plus modernes, avec un potentiel d’évolution plus conséquent, où ils ressentent une plus grande liberté.
Bonjour,
que dire également sur la partie materiel, où beaucoup attendent/abandonnent avec par exemple une smart en fin de vie avec une carte zwave 500. L’atlas qui pourrait faire office de remplacement, elle ne propose même pas un zwave intégré en 700.
Aussi une luna où il faut ré inclure tous les modules de 0… (manque réellement un outil de migration de protocole)
Je veux être libre mais avoir une box officiel pour soutenir le projet me parait cohérent.
Je suis un peu perdu sur mon evolution matériel et devient infidèle depuis peu en virtualisant la concurrence qui déroute sur son fonctionnement mais qui interpelle sur la suite.
Enfin il y a quand même un truc qui s’appelle la doc dans laquelle on trouve le changelog pour la v4.4 avec les corrections, les changements et autres…
Question, pourquoi ne pas plus ouvrir le code ? Et intégrer de nouveau développeurs / idées ? C’est ce que fait RedHat / Fedora par exemple et ça marche bien. Ça permettrait à Jeedom d’évoluer plus rapidement et ceux qui voudront de la stabilité irons sur les box Jeedom officielle. Genre avoir un Jeedom communautaire qui évolue vite, mais avec une roadmap leadée par Jeedom SA et une version « Pro » disponible sur les box et plus stable (moins d’évolution).
Bonjour
Car ça demande du temps homme et que jeedom sas les as pas. Actuellement la charge de l’équipe est au delà des 100% donc pour eux c’est pas possible. Je peux pas non plus faire ça car c’est pas mon truc et il est compliqué de prendre quelqu’un d’extérieur…
Je lisais ce fil depuis le debut en attendant le dérapage.
Je ne trouve pas que la remarque de @anon53349806 soit déplacée ou fausse.
Combien de questions ou reproches faits à Jeedom alors que les explications sont dans les docs.
A condition de chercher bien sûr ou d’en avoir la volonté.
Hé oui, le sujet initial, où va Jeedom ? c’est une question légitime
Vaste question, qui ne concerne pas seulement Jeedom Sas, petite société qui fabrique les box et gagne les sous sur les plugins officiels payants - à mon avis ça fait pas lourd… ça concerne aussi nous, la communauté. Le community.
On a vu les plugins non officiels mais quasi incontournables, jMQTT, Jeedom-Connect, Jeemate… Les lacunes du core sont facilement compensées par des plugins. Je suis même surpris qu’il n’y ait pas encore de Jeedom-Desktop, une app desktop qui viendrait se placer en front du core pour refaire certains interfaces / dashboard / … autre en version nodeJs par exemple. Si la doc est lacunaire, idem il ne tient qu’à nous de rajouter des pages comme qq1 l’a déjà signalé dans ce topic, il n’y a pas besoin d’être développeur pour faire de la doc, au contraire, je dirais que la meilleure documentation est celle faite par les utilisateurs. L’aventure Nextdom qui a fait long feu, à mon avis c’est dommage, ça aurait apporté à Jeedom aussi, au moins en notoriété, et peut être plus aussi (plugins, communauté, etc)
J’aurais juste 2 suggestions à faire à Jeedom SAS pour ouvrir la communcation :
déjà, ouvrir le forum dev, cette section n’a rien à cacher, il n’y a que des informations intéressantes pour les futurs développeurs qui viendraient ici sans s’enregistrer. Certes c’est un forum que en français c’est un peu domage pour l’ouverture à l’international, mais au moins déjà la communauté francophone pourrait y gagner plein d’informations. J’ai été frustré quand j’ai gagné le titer développeur, de voir tout ce qui était disponible alors que j’étais déjà sur mon 1er plugin depuis 2 mois, tout seul dans mon coin.
ensuite, nommer officiellement un « community manager » qui serait chargé de suivre le forum / poster une news de temps en temps / donner une direction / ou même juste nommer quelques personnes parmi la communauté qui feront le taff. En gros un groupe @Jeedom-Team avec au moins 1 officiel. Le groupe, il existe déjà, il sert à quoi aujourd’hui ?
C’est tout pour le moment évidemment c’était domage de lancer le sujet un 15 aôut au plus fort des vacances, faudra relancer le débat à la rentrée!
