J’ai crée plusieurs équipements à partir d’une multiprise. Pour ne pas écouter sur le topic racine du multiprise MULTIPRISE/#, j’ai ajouté MULTIPRISE/+/3/# et ses commandes Puissance, On Off et Etat associées. Or le status de l’ multiprise se trouve à MULTIPRISE/status.
Je me prends peut-être mal et qu’il aurait fallu créer un seul équipement puis des équipements virtuels, mais je trouvais un peu lourd de tout mettre dans un unique équipement vu que j’ai 5 prises.
Pensez-vous qu’il serait possible d’ajouter la possibilité de choisir une commande pour le status ou dois-je plutôt changer ma logique ?
et pourquoi pas ?
Tu as en principe dans jMQTT défini un broker.
Il devrait être possible d’ajouter au broker plusieurs équipements jMQTT, inscrits au même topic racine de l’équipement physique,
et définir les sous topics souhaités dans les commandes de chaque équipement jMQTT.
référence : https://docs.bad.wf/fr_FR/jmqtt/stable/index
Je ne voulais pas charger le système, sinon autant faire zwave/# pour tous les équipements. là je ne voulais pas non plus faire zwave/MULTIPRISE/# car si 6 prises, alors 6 équipements avec zwave/MULTIPRISE/#
Utilise le topic racine zwave/MULTIPRISE/# pour ton équipement, ça ne surchargera pas le système, de toute façon tu vas charger tous les messages de ce topic avec zwave/MULTIPRISE/+/3/# sur différents équipements.
J’avais prévu de sortir une version où je retire le topic racine, au profit d’une souscription par commande, mais le temps me manque ces derniers 12 mois…
Si j’utilise zwave/MULTIPRISE/# avec 6 équipements, j’aurais donc 6 équipements avec cette base. Ca veut dire si une prise consomme plus que d’autres, ça va se répercuter sur les autres. C’est pour ça que j’ai fait zwave/MULTIPRISE/+/1/#, zwave/MULTIPRISE/+/2/#, zwave/MULTIPRISE/+/3/#…, ça rend un peu indépendant les prises entre eux même si c’est le même matériel.
L’idée d’une souscription par commande c’est pas plus lourde en ressource ? J’ai déjà plus de 200 topics racines, j’imagine même pas 200*n commandes en topics.
As-tu actuellement (ou déjà eu) des problèmes de performance avec jMQTT ?
Ne cherche pas à sur-optimiser les souscriptions. Il y a pleins d’optimisations dans le code pour éviter les problèmes de performance et délivrer au Core les valeurs le plus vite possible. La très grande majorité des problèmes de performance qu’ont rencontrés des utilisateurs est un ralentissement de l’arrivée des valeurs, et pour ça c’est le Core qui est limitant.
Après c’était même pas une question d’optimisation, je voulais juste une cohérence au départ, pourquoi écouter une multiprise entière, alors qu’il y a moyen de rendre indépendant chaque prise.
Hormis effectivement de temps en temps des payload long à traiter, je n’ai plus de souci avec jMQTT depuis longtemps. Je regarderais pour mettre plus haut le topic racine, c’était juste une idée de suggestion ma demande
