Closed Steph3147 closed 6 years ago
Normalement ca doit passer, au pire il va trouver de nouvelles commandes vu qu'il est repassé en mode "simple" (mais c'est vraiment volontaire, je n'aime pas faire des usines à gaz en options et pour l'utilisateur final c'est démoralisant si pour commencer il faut connaitre ca par coeur)
Merci, c'est passé sans régression :smiley:
Concernant ma 2ème question, j'essaierai peu-être la simplification proposée, mais je vois un risque que les commandes émises soient vues comme de nouveaux topics et soient recréés dans des objets différents.
Stéphane
Pour la deuxième question j'ai zappé, non ca ne créer pas de doublons de topics et je sais pas si on peut faire mieux et réutiliser la session de lecture
Bonjour Lunarok,
J'ai lu le code vis à vis du point discuté ci-dessus et j'ai noté des problèmes que j'ai confirmés en essayant sur une plateforme de test. Sur le forum, des problèmes sont également remontés depuis la dernière mise à jour.
Exemple: dans le code il reste le test sur mqttAuto au moment de la souscription des topics alors que celui-ci a été supprimé des paramètres. Conséquence: après installation du plugin, mqttAuto=0 et le code passe dans la branche souscrivant aux topics des équipements déjà détectés. Il ne souscrit donc à rien et il n'est pas possible de sortir de cette situation de blocage.
Point très important: il faut absolument conserver cette notion de souscription des équipements sur demande et pas obligatoirement auto (c'est l'équivalent de la fonction inclusion pour zwave ou rfxcom, qui pourrait d'ailleurs à terme se faire de cette manière par homogénéité) car sinon le plugin créera des équipements non désirés.
Pour les sous-topics, interne à l'équipement (=les commandes dans le monde Jeedom), je suis d'accord que l'automaticité s'impose pour la simplicité.
Si tu es d'accord sur cette approche, je peux te soumettre quelque chose ce week-end.
Stéphane
Non je remettrais pas de notion de souscription à des sujets spécifiques, ca n'a rien à voir avec l'inclusion zwave. Dans le principe, on choisit que tel ou tel objet envoit ses données vers le broker de Jeedom. Donc c'est maitrisé à la source. Si on veut se prendre la tête autrement, à faire en conf Mosquitto, mais je refuse de complexifier une utilisation dans Jeedom pour quelques cas. Après on se demande pourquoi MQTT ne prend pas plus de place dans les objets connectés.
Bonjour Lunarok,
Le problème est que le protocole MQTT est prévu pour être utilisé à l'inverse de ce que tu dis. Ce n'est pas la source qui décide vers qui elle envoie ses données: elle envoie au broker et les souscripteurs décident à quels sujets ils souscrivent.
Il est déconseillé de souscrire à # de manière permanente. La première raison est le risque de flooding: c'est expliquée sur MQTT Topics & Best Practices.
La deuxième raison est que tu écoutes tes propres commandes. Je viens de le tester après application du commit que tu as fait hier. J'ai un objet qui émet ses données de cette manière: ecs/temp 45.4 ecs/consigne 45 et qui reçoit la commande de changement de la consigne ainsi: ecs/consigne/set 40
Quand jeedom émet la commande ecs/consigne/set (créé manuellement dans l'équipement ecs découvert automatiquement), comme il écoute tout, il créé un nouvel équipement ecsconsigne avec la commande info ecs/consigne/set. Pas top.
Ce que je proposais dans mon message précédent permettait de s'affranchir de ces 2 problèmes tout en restant simple puisque seulement quelques lignes de code étaient à modifier. En mode auto (ou mode d'inclusion), on souscrit à # et on créé les équipements. Lorsque le mode auto est désactivé, on souscrit aux topics correspondant aux équipements créés (sans donner à l'utilisateur la possibilité de modifier le topic souscrit).
Je ne pense pas que j'arrive à te convaincre. Pas de problème, c'est ton plugin, je respecterai ta position et conserverai le grand respect pour tout le temps que tu consacres à Jeedom. Par contre je développerai un plugin de mon côté (et j'arrêterai de t'importuner sur MQTT... :smiley:).
Stéphane
C'est passé avec régressions :(
Le problème c'est que le plugin MQTT controle tous mes chauffages, cela peut devenir vite une catastrophe (surtout en hiver)...
Remove ctype test giving wrong results with mosquitoo_pub https://github.com/lunarok/jeedom_MQTT/commit/491bd8e5bc1ba16c773475ebf6827b8682c7ed59#diff-597cb49f51eefdb66c7beba9331e8a02
j'ai eu les logs qui ont commencé à se remplir de :
[2017-12-14 17:19:03][ERROR] : Le nom de l'équipement ne peut pas être vide : MQTT Object ( [id:protected] => [name:protected] => [logicalId:protected] => [object_id:protected] => [eqType_name:protected] => MQTT [eqReal_id:protected] => [isVisible:protected] => 0 [isEnable:protected] => 0 [configuration:protected] => {"topic":"","type":"topic"} [timeout:protected] => 0 [category:protected] => [display:protected] => [order:protected] => [comment:protected] => [_debug:protected] => [_object:protected] => [_needRefreshWidget:protected] => [_timeoutUpdated:protected] => [_batteryUpdated:protected] => [_cmds:protected] => Array ( ) )
J'ai du rollback d'urgence. (un petit tag git serait bienvenue à chaque MAJ, heureusement qu'il y a les commits de robots) Le pub semble fonctionner, le sub semble KO.
Bonjour Lunarok,
J'ai vu que tu as effectué un profond nettoyage du code comme annoncé :smile:. Est-ce que le fonctionnement est compatible ascendant? Autrement dit, peut-on procéder à l'update sans précautions particulières (autre que sauvegarde au cas où bien sûr)?
En regardant la fonction publishMosquitto je me demande pourquoi tu ouvres un client spécifique pour publier, ce qui oblige à faire une boucle d'attente peu élégante avant fermeture?... Il serait plus propre, et plus dans l'esprit MQTT (un seul client par objet pour recevoir et publier), d'utiliser le client ouvert dans la fonction daemon (mais peut-être que Jeedom ne le permet pas - je débute...).
Encore merci pour ta contribution immense. Stéphane (StephC sur le forum)