j’ai le plugin Jeedore depuis plusieurs mois (je pense depuis l’été dernier donc ça remonte), avec une box Tydom1.0 sur laquelle sont connectés 10 VR et 23 éclairages. Dans l’app Tydom tout fonctionne très bien, mais dans Jeedom, depuis quelques semaines les retours d’état des volets et éclairages sont souvent incorrects. J’ouvre tous les volets le matin, Jeedom considère que la plupart d’entre eux sont encore fermés. La commande Position renvoie bien la valeur d’état fermé alors que le volet est ouvert. De même pour certains éclairages qui ne sont pas détectés comme allumés ou éteints alors qu’ils le sont.
Est-ce lié au passage en v4 de jeedom ?
Merci de vos retours, si quelqu’un a rencontré le même souci que moi. Aucun message d’erreur dans les logs, j’ai relancé une install des dépendances, vérifié les paramétrages ip etc. le daemon tourne sans souci.
D’ailleurs petite précision, si j’agis manuellement sur un objet avec le mauvais retour d’état, il devient correct. Par exemple, imaginons que j’ai un volet ouvert et qui est affiché fermé sur jeedom. Si depuis jeedom je l’ouvre, il va à partir de là avoir le bon retour d’état. Je sais pas vraiment à partir de quand ou quelle manipulation provoque le fait que le retour d’état ne se met plus à jour.
Pour info : Jeedom v 4.1.20 sur Rpi4.
Bonne journée à vous.
J’ai aussi un comportement exotique de l’état de mes volets (pas constaté sur les éclairages d’ailleurs… mais pas creusé) dont je soupçonnes le « mise à jour par »… @Tonyb0t77 avait remonté et solutionné le problème ici :
Mais personnellement, je n’ai pas osé faire la manip car elle ne me paraissait pas assez « focus » sur le problème.
J’avais justement l’intention depuis un moment de le relancer sur le sujet, savoir si il ne rencontrait pas d’effets de bord…
N’aurais-tu pas la commande id #100# dans « mise à jour par » de tes volets ?
Ah purée bien vu, j’avais regardé ce post en effet et j’ai fait la manip indiquée dedans mais ça n’a rien changé. Par contre en allant voir le détail du mis à jour par, sur par exemple le VR de notre chambre d’amis voici ce que je vois sur le détail de la commande Position :
J’avais pas eu le temps de répondre assez rapidement sur le fil d’origine pour le maintenir ouvert car à mon sens le problème reste entier…
Le retour d’état doit être fiable à 100% sinon nos bidules n’ont aucun intérêt imho.
Je vais tacher de me re-pencher dessus ce we et @Tonyb0t77 qui maitrise très bien le plugin va surement nous éclairer.
Se pose aussi la question en l’absence d’Eli de la maintenance de ce plugin incontournable qui ouvre un protocole très fermé et pourtant très répandu…
C’est vrai que c’est dommage si le plugin part aux oubliettes. Je pourrais m’y pencher et tenter de le rafistoler (je suis dév également et j’ai du matos deltadore donc pratique pour dev/test/debug) mais j’ai du boulot par dessus la tête et je veux pas me lancer dans un truc pour lequel je suis pas sûr d’avoir le temps et la dispo, et finir par dire « désolé les gars j’ai pas le temps je laisse tomber ».
Hello
J’ai enfin trouver du temps pour mettre le nez dans le callback.php…
Entre temps j’ai remarqué que la valeur de « Mise à jour par » n’est pas systématiquement #100# mais correspond à la value…
Pour moi le problème vient de la :
Mais en commentant la ligne telle que, chez moi la 296, il n’y a plus de valeur pour le « Mise à jour par » sur les levelcmd ou positioncmd mais elles subsistent sur les level et position…
To be continued…
Hello
Je teste ta solution depuis que tu la (re)suggérée : j’ai toujours des retours d’état incohérent et des « mise à jour par » correspondant à la value…
As-tu fait une manip supplémentaire ?
Je reviens sur le sujet car j’ai été frappé par la luminescence hier soir sur la route
Tout bêtement, supprimer / recréer tous les équipements ayant des commandes dont l’id est inférieur à 100.
Peut être monter jusqu’à 255 (voire plus) en fonction des équipements (module de lampe dimmable,…?).
Pour les retrouver, il suffit d’aller dans Réglages / Système / Configuration / OS/DB / Administration Base de données / Ouvrir puis rentrer la requete suivante :
SELECT eqLogic.id as eqLogic_id, eqLogic.name as eqLogic_name, cmd.id as cmd_id, cmd.name as cmd_name FROM cmd, eqLogic WHERE cmd.eqLogic_id=eqLogic.id and cmd.id<=100;
Mes excuses @Tonyb0t77 pour ta solution mais c’est mon coté DSI qui m’interdit, dans la mesure du possible, de tapper dans les bases…
Je viens seulement de faire la manip chez moi… feedback dans quelques jours.
Hello
Après une semaine d’utilisation manuelle, à distance (via Jeedom ou Tydom), sur programmation : plus de retour d’état incohérent !
Cela n’est pas une solution mais, à défaut, un contournement efficace.
Du reste, sans nouvelles d’Eli, il serait bon que la @Jeedom-Team prenne contact et en fonction envisage la reprise de ce plugin ouvrant un protocole très répandu et interopérable seulement avec Jeedom grâce à celui-ci.
Donc j’ai pu recréer mes équipements, il me reste juste le DNS Jeedom, je ne sais pas trop comment le recréer.
Ensuite je dois faire autre chose pour régler le pb de position des volets …?
Encore merci
Loic
Pas de problème
Par contre, pour les DNS Jeedom, n’en n’ayant pas besoin, je ne me suis jamais penché sur le sujet.
A priori, selon la doc, tout se règle par les paramètres de l’onglet réseau.
Peut être en revalidant le process cela va te recréer l’équipement ?
A réaliser sur le réseau local de ton Jeedom en cas de kwak-il-en-soit
J’ai essayé plusieurs trucs avec les DNS mais cela n’a pas changé les IDs des commandes. Dans tous les cas ce n’est pas grave car le souci avec la position des volets semble être réglé, un grand merci