En lien avec mon précédent sujet, je ne comprends pas vraiment le fonctionnement du plugin deConz Jeedom.
J’ai installé la gateway deConz sur un autre serveur. Je n’ai donc pas besoin que jeedom lance le process deConz en local. C’est pour çà que j’avais stoppé le daemon du plugin (car j’avais constaté qu’il essaie de lancer la commande deConz/de le killer lors de l’arrêt). J’ai simplement ajouté ma gateway distante dans la conf du plugin avec le token qui va bien.
Avec le daemon stoppé, les valeurs ne se synchronisent . Donc il faut bien le daemon lancé.
Ma question est donc la suivante : quelle configuration faut-il faire pour utiliser une gateway externe sans que le plugin deconz ne cherche à lancer/stopper un process deconz en local sur la machine jeedom ?
2ème problème remarqué : Quand le serveur hébergeant la gateway n’est pas joignable, le daemon n’essaie pas de se reconnecter à la websocket lorsque celui-ci revient. Pour ma part, c’est le cas chaque nuit quand je redémarre mes machines pour faire des backups. N’ayant pas de garantie sur l’ordre de redémarrage de mes serveurs, je me retrouve avec toutes mes sondes non fonctionnelles jusqu’à ce que je vienne à la main relancer le daemon. C’est pas très robuste comme fonctionnement du plugin.
Tu ne peux pas justement régler un ordre de boot ?
J’ai 3 VM, une jeedom, une Blea et une deCONZ.
Lorsque le nuc démarre alors dans l’ordre c’est Blea puis Deconz puis Jeedom en laissant une pause de 2 minutes entre chaques. Au moins quand la VM jeedom démarre je sais que tout est bien lancé.
Gateway Phoscon. La Gateway Phoscon et deCONZ c’est deux choses différentes
Fais un petit tour ici deCONZ for Dummies · dresden-elektronik/deconz-rest-plugin Wiki · GitHub pour bien comprendre les différents éléments deCONZ , REST API et Phoscon .
Ensuite imagine que Jeedom/Deconz et Phoscon sont de même niveau. Mais comme Jeedom/Deconz ne fait pas tout il utilise Phoscon pour compléter ce qu’il ne fait pas.
Oui bien sûr je pourrais forcer l’order de boot.
Mais ça rajouterait une plus grande période d’indispo de ma domotique la nuit (délai assez grand pour être certain que tout est ‹ up ›).
Et dans le fond ça ne fixe pas vraiment le problème. Pour toute action sur la VM hébergeant la gateway deConz (redémarrage, mise à jour, update de la gateway deconz…) ou incident (problème réseau sur le routeur, indispo temporaire pour raison X ou Y), la connexion websocket est perdue et n’est jamais restaurée correctement.
A mon sens ça n’est pas assez robuste pour installation domotique un peu sérieuse.
Si au moins je pouvais être alerté en cas de déconnexion, ça serait ‹ acceptable › (et encore…), mais comme les dates de dernière communication sont ok (je suppose que cette info ne dépend pas de la websocket), pas moyen de savoir que les valeurs ne remontent plus. Pas de log en erreur non plus, juste rien.
J’ai pas trop envie de faire du bricolage au cas par cas. J’ai payé le plugin, mais si ça n’est pas corrigé, j’envisagerais le développement d’une passerelle deconz2mqtt. Je commence vraiment à penser, comme pour le zwave, qu’il ne faut pas faire confiance à Jeedom pour la partie protocoles (le reste est top par contre).
Au lieu de râler ici, ça ne me dérangerait absolument pas de prendre le temps de regarder les sources du plugin pour aider à corriger, mais comme j’ai pas envie (ni le droit) de maintenir un fork et qu’il n’est pas envisageable de contribuer (cf discussion ici), je commence à me poser des questions sur la viabilité du modèle (combinaison de plugins payant + support aléatoire + pas d’acceptation de contributions de la communauté)
Oui abus de language, désolé j’ai pas été attentif.
Ne t’inquiètes pas, je comprends bien le fonctionnement global, j’ai même fait des développements sur la partie API REST, avec build custom pour mes volets profalux. C’est justement pour ça que j’ai déporté mon installation sur une autre machine.
J’ai bien une gateway (je reprends le terme de la doc du plugin jeedom) distante, correctement configurée dans Jeedom
Mais alors que la seule gateway configurée est distante, j’ai cette ligne dans les logs :
[2021-01-27 18:54:12.403][INFO] : Local DeconZ found
[2021-01-27 18:54:12.404][INFO] : Launching local DeconZ
[2021-01-27 18:54:12.404][INFO] : Kill all deCONZ process
Peut être le fait-il parce qu’il trouve l’exécutable, donc il se dit qu’il faut lancer deconz localement également ? Je vais tenter de supprimer le package (même si ça n’est pas explicite dans la documentation).
Edit: effectivement, il faut bien aller enlever le package deconz pour qu’il arrête de le démarrer
Bon j’ai fixé le problème localement. La gestion d’erreur/reconnexion sur la websocket était effectivement incorrecte dans le daemon du plugin. J’ai une version patchée testée qui marche bien.
Bonjour,
Oui je veux bien.
Pour le systeme de contirbuteur je veux bien mais ya pas de solution si on met le plugin en public sur github on ne le vendra plus si on le vend plus ya plus d’argent qui rentre si ya plus d’argent qui rentre on met la clef sous la porte et vous n’aurez plus aucun support, mise à jour, evolution et autre. A vous de nous dire ce que vous preferez.
Bah je pensais donner un accès aux sources aux gens qui ont payé le plugin (et qui en feraient la demande) => Ca permettrait de contribuer des correctifs. C’est pas envisageable ?
Je regarde pour t’envoyé le correctif en privé.
J’ai juste pas pris en compte le cas particulier quand la gateway est en local. Pourquoi dans ce cas ci tu ne voulais pas faire de retry sur la websocket ?
Ben si c’est possible de données accès au source pour les gens qui ont payé mais chaque personne nous 4$/mois donc il faudrait pour chaque plugin que vous acheter compenser ce prix. Sur 5 disons, ca fait 5124=240$, en € on doit etre autour des 200€. Il faut donc qu’on augmente le prix de chaque plugin de 200€ (sans compté la tva qu’il faut rajouter et les commissions bancaire et les semaines de dev pour gérer l’api github et l’obligation que chaque utilisateur ait un compte github).
Pour le soucis de gateway local je considere que si j’arrive plus a la joindre c’est que deconz est dans les choux donc je relance tout.
Ok, je ne sais pas sur quel infra et sur quel modèle de coût sont hébergées vos sources.
Là si je comprends bien vous payez par utilisateur et par mois => Pas évident effectivement. D’ailleurs je ne comprends pas pourquoi vous n’êtes pas sur le free plan Github (qui a changé il n’y a pas longtemps) qui permet un nombre illimité de collaborateurs et de repositories privés.
Sans connaitre en détails comment fonctionne votre infrastructure, étant donné que chaque utilisateur a ses droits (plugins achetés) connus au niveau du market, ça devrait pouvoir être jouable d’avoir un fork de chaque plugin hébergé dans la même infra que le market, dont les droits d’accès Git sont synchronisés avec les plugins achetés. Ca demanderait un peu de boulot de mise en place, mais à la fin ça coûte clairement pas 4$/user/mois. Sur le papier ça fonctionne et surtout ça évite d’avoir à faire ce choix de se couper presque totalement de l’apport d’une communauté sur la partie payante. C’est quand même hyper frustrant: t’as payé, mais c’est encore plus difficile de contribuer à améliorer que sur la partie gratuite de jeedom.
Encore une fois, même si je comprends les questions que vous vous posez, sur le long terme une communauté plus impliquée c’est plus de qualité, plus de features, des utilisateurs plus heureux et moins de travail pour vous.
PS: Peut être je me trompe, mais il me semble que les licenses de vos sources en GPL v3 n’interdisent absolument pas le repartage et l’usage gratuit de celles-ci. Quitte à aller au bout de la démarche « closed source », vous devriez vous protéger là dessus.
J’ai rien compris, nos sources sont sur github ca ca ne changera pas. Le market ne gère absolument pas les sources il héberge juste le dernier zip du plugin mais c’est tout, ce n’est absolument pas un repository.
Et non sur github on peut pas avoir des repos privés avec des droits d’utilisateur par repos spécifique gratuitement. La seul solution pour que ca soit gratuit c’est de données accès a tout a l’utilisateur ce qui n’est pas envisageable.
Et non on ne peut pas monter un gitlab ou autre pour gerer cela c’est trop risqué en cas de soucis d’ou l’utilisation de github qui nous decharge de toute la partie administration d’un truc aussi critique.
Pour la licence oui la gpl autorise tout a fait une fois les sources acquise (gratuitement ou non la licence gpl n’interdit pas de mettre en payant l’accès) de modifié et redistribuer. Il est hors de question de changer de licence (ou alors ca sera sans moi) et nous n’avons aucun besoin de nous proteger la dessus. C’est un choix assumer d’etre en opensource mais juste payant sur certaine source.
Bah si, c’est ce que je fais à titre perso sur d’autres sujets, tu peux controller qui a accès à quoi en plan gratuit au sein d’une organisation. J’ai des gens qui ne voient que certains repositories dans mon organisation, à qui je donne les droits que je veux sur chaque dépôt individuel. Ou alors j’ai pas bien compris la limitation dont tu parles…
Bah justement c’était au cas où ce ne soit pas possible sur Github (mais ça l’est…), ça serait possible en hébergeant des dépôts git sur l’infra du market en plus. Je comprends bien que ça n’est pas le cas aujourd’hui, j’essaie de proposer des idées c’est tout.
Vu que c’est possible sur github, pas besoin de se lancer là dedans effectivement
Donc toute personne ayant acquis le plugin peut librement le remettre en accès libre sur github. Du coup je ne comprends pas l’argument pour ne pas mettre en accès publique les sources de votre côté pour que les gens puissent contribuer, puisque n’importe qui a le droit de les mettre en accès libre du moment qu’il les a acheté. Je pense donc que vous avez un problème de licence, ou de cohérence.
Honnêtement je ne vais pas me battre contre de faux arguments. J’essaie de proposer des choses simples qui ne vous coûtent rien et permettraient d’améliorer Jeedom grâce à une plus grande implication de la communauté (surtout comme des personnes comme moi souhaitent aider). En retour j’ai des réponses assez sèches, qui montrent peu d’ouverture à la discussion. Grosso modo Jeedom et sa communauté sont comme ils sont, à prendre ou à laisser… Je comprend pourquoi je lis de plus en plus de personnes dans d’autres communautés domotique (HA particulièrement) qui expliquent pourquoi ils ont finalement abandonné Jeedom, malgré tout ce qu’ils aimaient dans cette solution domotique.
Pour ma part je vais maintenir mon fork privé du plugin dans mon coin, en attendant de voir si ça vaut le coup de poursuivre l’aventure et de chercher à contribuer d’une manière ou d’une autre.
En faite on essaye juste d’équilibrer le maximum d’ouverture possible tout en ne donnant pas un accès officiel au source facilement pour les plugins payant pour juste pouvoir survivre.
Je comprends bien la demande mais honnêtement j’ai pas les compétences pour la faire ca me dépasse complètement, j’essaye de faire au mieux avec mes maigres compétences mais on m’en demande toujours plus et c’est simplement pas possible. Je suis pris entre 2 d’un coté les utilisateurs qui veulent que tout soit facile gratuit et immédiat et de l’autre la société jeedom SAS qui s’en mémé parler de faire des bénéfices veut juste ne pas perdre d’argent. C’est pas une position qui me convient, toute cette partie licence, droit, vente et autre honnêtement j’en ai rien a faire. Mon truc c’est plutôt d’essayer d’aider les gens dans le code mais le reste ca m’intéresse vraiment. J’ai t’ai juste données les arguments de jeedom SAS, le seul truc que j’ai imposé à Jeedom SAS c’est que pour que je continue a faire du code pour jeedom la licence doit être la GPL c’est ma seul est unique contrainte.
Et pour github je sais pas quand je vais sur la page des membre de l’organisation si j’en veux plus ben je dois payer
Ca marche pas de mettre en outside collaborator ? Tu va dans le dépôt du plugin deconz => settings => Manage access => Invite teams or people => Tu saisis mon id github (vanackej) pour faire un test ?
Comme ça, les gens ne sont pas membres de la team, mais contributeurs externes, juste sur un dépôt. C’est possible en plan gratuit, je ne vois pas pourquoi ça ne serait pas possible en plan payant
Et pour préciser ma pensée : ça ne me dérange absolument pas de contribuer gratuitement à l’amélioration d’un plugin qui est payant. Mais je voudrais à minima que ce soit simple. Pas galère comme c’est aujourd’hui. Jeedom SAS aura d’autant plus de chances de s’en sortir et d’être profitable si sa communauté fonctionne bien et est bienveillante. Rendre compliqué la contribution sans pour autant vraiment protéger ses sources (au moins via une licence adaptée), ça me semble pas être la bonne solution.
Pour tes arguments je suis tout a fait d’accord mais ca ne dépend pas de moi je suis juste le messager je n’ai aucun pouvoir de décision la dessus. Après je comprend aussi les arguments de jeedom SAS car on sait par expérience que la plupart des PR qu’on a ont des soucis (regarde le dernier sur le core ca fait planter l’update faut le relancer 2 fois, le PR est valable mais ca va nous faire monter la charge de support de manière folle à la sortie de la 4.2 ce qui va obliger de mettre toute les personnes juste sur les tickets…). Donc si Jeedom SAS ouvre trop il faut qu’ils embauche une personne pour tester les PRs avec à chaque fois le matériels sinon les PRs ca sert a rien si ils n’arrivent pas a les traiter. C’est un sujet qui semble simple mais ne l’ai pas du tout… Et je suis pas la bonne personne pour en parler.
OK, au moins on aura essayé. Je ne comprends pas pourquoi c’est limité les outside collaborators, alors qu’en gratuit j’ai jamais rencontré la limite. Je vois pas de quelles features vous avez besoin en version payante, mais encore une fois je ne connais pas les détails de votre fonctionnement interne, ça doit donc être justifié personne ne donne 5$/mois/user juste pour le plaisir
Oui, c’est sûr qu’il faut controller la quantité de PR. On a vu beaucoup de projets opensource se faire complètement déborder par le nombre d’issues et de PR.
Je pensais là à la possibilité de donner individuellement, sur les plugins payants, des droits de contribution à quelques personnes bien identifiées. Mais votre compte github ne le permet pas donc c’est KO.
Après pour certain dev externe type kiboost on paye le prix de la place pour github tous les mois donc on le fait mais on donne pas les droits comme ca ca prend du temps
Je voulais te l’envoyer en message privé, mais visiblement c’est pas possible.
Voilà quand même ma version modifiée du daemon. Ca fonctionne bien comme je disais, il n’y a juste pas de prise en compte pour l’instant du déploiement local (=> pas de retry si ip = 127.0.0.1).
Renommé en .txt car pas possible d’inclure des fichiers .py ici. C’est quand même pas bien pratique de contribuer comme ça, réfléchissez y, vraiment, c’est dans l’intérêt de Jeedom…deconzd.txt (9,2 Ko)
