Bonjour.
J’ai un jeedom cible v3.3.39, il concentre les équipements jeelinks de boxs jeedom distantes.
Récemment j’ai monté un autre jeedom source en v4.0.37. J’ai créé des équipements sur ce jeedom source avec le plugin EIBD, et je les ai « envoyés » sur le jeedom cible.
Et là surprise, quelques équipements sont visibles sur la page des équipements jeelink, mais pas tous. Pour info j’ai créé des objets sur le jeedom cibles avec le même nom que ceux du jeedom source afin que l’affectation se fasse toute seule. J’envoie 168 équipements au total, et 78 se retrouvent sur le jeedom cible, affectés dans leurs objects respectifs. Les autres sont introuvables.
Du coup est-ce que j’aurais atteint une hypothétique limite du nombre d’équipements qui peut arriver sur un jeedom cible (228) ?
Est-ce un souci de compatiblité v3 <-> v4 ? Jeelink est à jour avec la dernière version stable disponible sur les deux jeedom.
J’ai tenté de resauvegarder la configuration du jeedom cible et les équipements affectés.
J’ai checké les logs sur les deux jeedom, rien de flagrant concernant ce souci.
J’ai redémarré le jeedom cible, rafraichi la page en vidant le cache du navigateur…
J’ai envoyé un nouvel équipement depuis un autre jeedom et il apparait tout de suite dans la liste sur le jeeodm cible.
J’ai supprimé un équipement qui était bien passé, ensuite j’ai resauvegardé pour « synchroniser » les deux jeelinks, la liste est restée telle quelle, l’équipement supprimé n’a pas laissé sa place à un nouvel équipement sur le jeedom cible. Quand j’ai de nouveau ajouté cet équipement à la liste d’équipements à envoyer, il est de nouveau apparu sur le jeedom cible.
Qu’est ce que j’aurais pu louper? je n’arrive pas à trouver de dénominateur communs aux équipements manquants…
Des idées?
Bonjour,
Il n’y a pas de limite normalement mais la le nombre que tu envoi est a mon avis trop et quand on arrive a ca il y a un soucis dans le design je pense. Faut bien se rendre compte que un jeelink ça allège pas vraiment la charge sur le jeedom cible ni le source au contraire ça induit du réseaux donc de la latence, des échange de clef, des ouverture/fermeture de connexion…
Après pour ton probleme il faudrait regarder les log http.error des 2 coté deja pour voir
Merci Loïc pour ta réponse.
Rien de particulier dans les logs http.error non plus. En théorie l’infra qui supporte le jeedom cible est dimensionée en conséquence et la VM qui héberge jeedom est assez beefy.
Après si c’est un souci de design c’est pas une bonne nouvelle pour moi, mais je comprends. J’ai peut être un peu sur-estimé ce que je peux tirer du plugin jeelink…
Chaque remonté d’info c’est une connexion http vers le jeedom cible c’est super consommateur…
Après ouvre un ticket avec accès support ouvert sur les 2 jeedoms et je regarde mais meme si je le fait marcher je recommande vivement de ne surtout pas envoyer plus de 50 équipements (même plus de 30 je dirais)
OK je regarde si je peux rectifier le tir, j’ouvrirai un ticket que si c’est vraiment nécessaire, je n’ai pas envie de vous prendre du temps si c’est pour une solution palliative. il me faut quelque chose de robuste et si ça veut dire changer le design, et ben j’y réfléchirai.
Mais merci d’avoir proposé une solution!
Update:
J’ai supprimé tous mes équipements jeelink sur le jeedom cible.
J’ai supprimé tous les équipements affectés à ce jeedom cible depuis la config jeelink du jeedom source et j’ai cliqué sur sauvegarder.
J’ai supprimé le jeedom cible depuis la config jeelink du jeedom source.
J’ai changé la clé API jeelink du jeedom cible.
J’ai redémarré le jeedom source.
J’ai vidé le cache des 2 jeedoms.
à ce stade j’ai estimé être retourné à une situation initiale « propre ».
J’ai de nouveau créé le jeedom cible, sous un autre nom pour être sûr.
J’ai affecté 30 équipements et sauvegardé.
Sur le jeedom cible seuls 3 sont apparus.
Les 2 plugins jeelink sont en mode debug mais rien dans les log. Le jeedom source en v4 n’a même pas de log jeelink.
Hypothèse : le plugin jeelink garde une trace quelque part de ce qui a été synchronisé avec lui, et du coup il ignore certains équipements qu’li aurait déja vu par le passé. Et ce n’est pas dans le cache jeedom puisqu’il a été vidé.
Compléments:
Les 2 jeedoms sont sur le mêne subnet du même réseau.
Ils sont à jour.
@Loic, une idée qui te vient comme ça ? Sinon j’ouvre un ticket, à ce stade ça me parait valoir la peine. Je ne vois pas qu’est-ce que je pourrais joindre comme élément qui puisse être utile mais je le fais avec plaisir si on me dit quoi ^^
effectivement si à chaque équipement lié entre un Jeedom cible et un Jeedom source, cela nécessite une connexion, avec plusieurs dizaines d"équipements cela peut commencer à générer de la charge sur les 2 Jeedom et sur le réseau éventuellement (même si j’imagine que les trames sont petites).
N’est-il pas possible de ne créer qu’une connexion (permanente) entre les 2 Jeedom cible/source et de faire transiter les requêtes de mises à jour d’état et de commande sur cette seule connexion?
Voire utiliser un pool de connexion pour optimiser le nombre de connexion et limiter la charge système de création/suppression de connexion?
Sinon que conseillez-vous pour permettre de communiquer entre plusieurs instance Jeedom?
L’utilisation d’un bus de messagerie comme MQTT?
