Hello,
J’ai un soucis avec le all off via homebridge, lorsque je demande de tout éteindre via commande vocale ou en utilisant l’application des lampes restent allumées de facon random, si je passe par un groupe de zigbee2mqtt avec toutes mes lampes ou un scénario jeedom je n’ai jamais le soucis, je ne vois pas trop ou chercher, j’ai essayé de passer les logs de homebridge en debug mais je ne vois pas passer les infos.
Merci d’avance pour votre aide.
avec quel plugin ?
Z2m, jeezigbee
l’officiel ?
ah moi j’ai le problème parfois avec zigbeelinker.
c’est le plugin zigbee qui ne supporte pas de recevoir autant de commandes en même temps, quand c’est le cas, il devrait mettre les commande en file d’attente ou envoyer avec le bon QOS (1 pour au moins une fois).
quand ça m’arrive, je dis juste une seconde fois à siri…
Oui j’ai le plugin officiel Z2m, jeezigbee, a priori ce n’est pas un problème du au plugin puisque par scénario ou groupe z2m ca marche sans problème.
Oui groupe c’est une seule commande (c’est z2m qui gère derrière) et le scénario est lent donc ça passe, tandis que la c’est direct et tous en même temps !
OK, je peux agir sur le QOS pour remédier tu penses ?
je ne connais pas le plugin officiel
Sur Z2m directement je pensais
non c’est sur le publish qu’on met le QOS donc le plugin
tu peux tenter avec jMQTT de mémoire ça fonctionne très bien par là !
sur mosquitto directement alors?
non sur celui qui effectue le publish sur mosquitto, donc ce n’est que le plugin !
je pense même que pour les actions multiples comme les lumières, je vais repasser par là, j’avais aucun problèmes
Petit retour,
1- j’ai défini directement dans le plugin mqtt2 un QOS à 1, cela n’a pas eu d’effet.
2- j’ai défini un QOS à 1 directement dans l’UI de Zigbee2mqtt, sur chaque module eclairage, après relance du deamon, j’avais un problème impossible de passer le deamon à OK dans les logs j’ai vue: > !!! Read this carefully
Refusing to start because configuration is not valid, found the following errors:
Devices/xxxx/homeassistant must be object, null
Jai donc modifié le configuration.yalm comme indiqué sur le github de Z2m puis c’est reparti, sans effet sur mon problème.
J’ai donc finalement suivi ton conseil 
.
3- En passant par jmqtt ou l’on peut définir le QOS sur le publisher directement, la plus de soucis.
@Loic, serait il envisageable à l’instar de jmqtt de prévoir une amélioration pour définir dans le plugin jeezigbee un QOS pour remédier aux problèmes rencontrés?
D’avance merci.
Ps: Deconz doit gérer l’envoie de commandes multiples correctement, car je n’avais jamais eu de problème, meme sur de tres grosses installations, pour info cette installation comporte 27 points lumineux et sur une installation deconz/homebridge jai 63 points lumineux et le all off via apple home fonctionne dans 100% des cas.
je pense que ça vient plutot du système de file d’attente des evenements de jMQTT plutot que du QOS… car un QOS de 1 ne sert à rien si le publish n’est jamais envoyé…
Ca je ne sais pas dire, j’ai remarqué que si j’envoie un all off via un scenario ou ou groupe Z2m ne me remonte pas d’erreur, si je passe par home j’ai des times out en masse sur le publish state off “exceed 1000”, cela veut dire que le publish nest pas transmit ?
Javais pensé à mettre une action après exécution de la commande state::OFF sur mes modules pour attendre 2 secondes puis renvoyer un off, je ne sais pas si cela peut être probant ou non? car lorsque que jenvoie un all off via home et que des lumières restent allumées si je renvoie le meme ordre dans la foulée cela éteint tt.
Mr @Bad, pourrais tu, me dire comment est géré le système de file d’attente des events sur jmqtt? il y a t’il une particularité?
J’essaye de comprendre pourquoi le all off ne pose pas de problèmes en passant par ton plugin, alors que sur jeezigbee cela pose problème.
D’avance merci
Hello @Maxcrouz,
Merci pour ton message, ravi que jMQTT réponde à ton cas d’usage.
Non il n’y a pas vraiment de particularité, d’ailleurs jMQTT n’impélmente pas (encore) toutes les subtilités liées à la QoS du protocole MQTT, car ça n’a pas été nécessaire pour le moment.
Par contre, une attention particulière (attendue par le protocole) est portée à l’ordre (dans lequel les messages sont traités) et au temps de traitement entrant ou sortant des messages MQTT :
Mais actuellement jMQTT ne garde pas de trace des id des messages envoyés pour les acquitter ou les retransmettre en cas d’échec.
Pour rappel sur la QoS en MQTT :
Donc je ne pense pas que ton problème soit lié à la QoS.
Pour analyser ce qui se passe, tu peux te connecter à ton Broker avec MQTT Explorer et regarder ce qui transite quand tu envoies l’ordre via jMQTT et via JeeZigbee.
Bad
Bonjour
Je pense tu ne comprends pas bien comment tout fonctionne le qos n’a rien à voir ton soucis. Le qos est au niveau du protocole Mqtt et zigbee donc tu pourras le changer autant que tu veux ça ne changera absolument rien car ton soucis est après dans le protocole zigbee.
