J’ai un problème avec le plugin TaHomaLocal.
A priori le même qu’ici.
Parfois, dans mon scénario de gestion des volets, j’ai cette ligne qui apparaît et mon volet n’est pas actionné :
Je n’ai pas tenté de déinstaller / réinstaller le plugin (je n’ai qu’un seul équipement, à la limite, je peux tenter si c’est une solution potentielle
Je l’ai désactivé / réactivé
J’ai passé les logs en mode debug pour voir mais je ne vois rien d’intéressant
J’ai tenté de jouer en activant/désactivant le cron mais j’ai lu qu’il ne fallait pas y toucher dans un autre thread similaire au mien. La phrase dans la doc n’est pas très claire sur le sujet du Cron, on se demande s’il faut le désactiver juste pendant l’installation ou si on doit laisser désactiver après l’installation en phase de run.
Le démon affiche une erreur liée au Cron d’ailleurs. Est-il normal qu’il soit en erreur ?
Les derniers logs TaHomaLocal mais on peut voir les actions que j’ai faites sur le cron ou la gestion automatique du démon pour voir si ça corrigeait quelque chose :
J’ai une réservation dans mon serveur DHCP avec l’adresse MAC de ma Tahoma Switch pour lui attribuer toujours la même IP. Ma Tahoma est bien visible sur le réseau, y compris depuis mon serveur srv-jeedom02, tous les flux sont ouverts entre les deux, en TCP et UDP.
J’ai lu qu’il pourrait s’agir d’un problème de déconnexion ponctuelle de la Tahoma du réseau Wifi, c’est tout à fait possible, mais, si c’était vraiment ça la cause du problème, serait-il possible de gérer ce cas avec un Try Catch ou autre (dsl je ne suis pas développeur du tout :-/) dans le code pour répéter la commande si la Tahoma n’a pas répondu ?
Voilà toutes les infos que je peux vous donner à ce stade, n’hésitez pas à me demander tout ce qui pourra vous aider à m’aider
De mon côté, pas vraiment d’amélioration constatée. Je rencontre toujours les même soucis.
J’ai vraiment l’impression que c’est lié à la connectivité wifi de la TaHoma.
Je monitore la TaHoma avec le plugin network, et l’erreur sur le cron arrive en même temps que la perte de la TaHoma.
Particulièrement depuis hier, les déconnexions/reconnexions sont intempestives (une dizaine aujourd’hui). Pourtant mon réseau wifi est sain.
J’envisage d’acheter l’adaptateur pour mettre la TaHoma en ethernet. Le plugin réagit correctement selon moi, mais en effet il serait intéressant d’obtenir une erreur si la commande n’a pas pu s’exécuter correctement.
J’ai également la TaHoma avec une réservation dans le DHCP.
Fiabiliser l’envoi de la commande serait une chose, mais ça ne résoudra pas le problème de fond je pense que c’est un produit vraiment mal conçu. C’est dommage. Je ne vois que la solution filaire pour pérenniser l’utilisation. Mais bon, 37,90€…pas cool Somfy.
Merci pour cette précieuse information.
Je vais tâcher de faire la même expérience pour voir de mon côté.
Donc le plugin n’est a priori pas en cause, mais je vous rejoins sur le fait qu’une meilleure prise en compte de l’erreur serait appréciable pour pallier aux problèmes de la TaHoma.
Après analyse et merci pour vos différentes interventions et observations, il semble que votre problème vous soit assez spécifique en effet.
Si il y avait un problème de fond au niveau du plugin, j’imagine que la communauté des utilisateurs de TaHomaLocal se serait manifestée depuis un certain temps.
Hors c’est plutot silence radio sur ce sujet et c’est tant mieux, cela prouve que le plugin marche plutot bien avec une certaine robustesse et une bonne fiabilité. C’est le but recherché
Pour en revenir aux déconnections intempestives et présumées de la box TaHoma Switch en WiFi, je n’ai pas d’expérience personnelle sur ce sujet.
Le monitoring proposé par @Selyjohns est une bonne approche, en effet et je vous laisse chacun en tirer les conclusions.
Dans sa version actuelle, le plugin remonte une Erreur PHP lorsque l’accès à la box est incorrect, ce qui est normal mais je vais regarder si je peux améliorer le traitement de cette erreur pour qu’il soit moins « violent ».
Ceci étant, soyons clairs, le plugin n’a pas vocation a palier aux défaillances du fonctionnement de votre réseau. Si un équipement est déconnecté, il n’y a pas de miracles à attendre et l’action demandée ne peut pas s’effectuer correctement.
Par contre, rien ne vous empêche de rendre un scénario plus robuste en y ajoutant une boucle action-réaction pour corriger ce type de fonctionnement incertain.
Dans tous les cas, mercis de vos retours.
Vos différentes interventions vont donner lieu à quelques modifications au niveau du plugin qui j’espère amélioreront le retour d’info.
Je regarde cela …
Je me suis permis de modifier un peu cURLCommand.class.php pour mesurer les temps de requête vers ma TaHoma (dsl si ce n’est pas très propre, je ne suis pas développeur) :
Et je me suis aperçu que le problème était peut-être lié à la résolution de nom de ma tahoma lors de l’utilisation de mDNS (à noter que j’utilise pfSense en tant que serveur DHCP et résolveur DNS local).
Je vous rappelle que vous pouvez choisir, dans la page de configuration du plugin, le Mode IP qui utilise donc l’adresse IPv4 à la place du hostname de type gateway-xxxx-xxxx-xxxx.local.
C’est donc déja prévu pour les configuration réseau un peu particulières
je pense que c’est un produit vraiment mal conçu. C’est dommage. Je ne vois que la solution filaire pour pérenniser l’utilisation. Mais bon, 37,90€…pas cool Somfy.
