Bonjour
Mon réseau zigbee semblait se stabiliser mais depuis 2 jours c’est la bérézina. Beaucoup de commandes ne passent plus.
Le seul élément nouveau est la MAJ du Z2M du 24/04. (et un routeur déplacé, exlu et réinclu)
Je constate une baisse générale de tous les LQI du réseau
Ca devient vraiment critique, je passe par Jeedom/z2m pour la gestion du chauffage de la maison, de la serre et l’irrigation. 90% du temps que je passe sur Jeedom est pour surveiller z2m …
Bonjour
Pour ma part j’ai obtenu des résultats « satisfaisants » avec la version 1.33, au dessus pas mal de soucis… Vérifie ta version, il suffit qu’il y ait eu une actualisation des dépendances pour que tu ais changé de version.
Je suis sur la dernière version depuis quelques temps 1.36.1, ça semblait « stable »
entre la version de Z2M, un module défaillant, jeezibee et le sens du vent impossible de dire d’où ça vient mais c’est archi instable
aucune erreur dans le log z2md donc :
concrètement ça veut dire quoi ? pour que ça ne soit pas dans les logs ça signifirait que la commande ne part pas ?
Repasse en 1.35 la 1.36 a pas mal de soucis dont exactement ce que tu décris. Pour info les maj du plugin jeedom n’ont aucun impact sur le réseau zigbee. Le plugin n’est pas acteur du réseau zigbee juste consommateur.
Bonjour
Dans les systèmes filaires Il y a toujours un moyen de supervision des communications, généralement un polling toutes les X secondes est réalisé, si l’équipement ne répond pas après x essais, l’équipement est considéré en rupture de communication. Cela m’a un peu perturbé quand j’ai installé mes équipements zigbee. J’ai donc cherché comment je pouvais monitoriser mes équipements. Jeedom a cette fonctionnalité que je paramétrais avant de toucher à quoi que ce soit, qui permettra de mesurer les améliorations:
Le timeout
1- Système → configuration → Log → Action sur alertes:
Si un équipement passe en timeout envoi d’un mail et sms.
2- Sur les équipements: Plugins → Protocoles domotique -->Jeezigbee → Equipement → Configuration avancée → Alertes
Cas d’une prise électrique Nous: 60 minutes
Tous mes équipements Zigbee sont paramétrés avec des temps différents en fonction du type d’équipement. Il ne faut pas diminuer trop le temps pour ne pas avoir de fausses alarmes.
Cela permettra après chaque modifications de mesurer l’amélioration ou la dégradation des communications. J’ai pu être averti d’un problème sur une sonde de température, je l’ai déplacé de 2 mètres et je n’ai plus d’alarmes.
Cela ne résoud pas le problème mais de mesurer.
Downgrade à la version 1.35.0 fait. A suivre
@echo
Le monitoring sur le time out ne m’aide pas, j’ai des modules qui communiquent vers jeedom mais pour lesquels les commandes ne passent pas, sans trace dans les logs
PS : j’ai vu un post sur le forum d’un gars qui installe en série des systèmes domotique jeedom/zigbee dans des nouveaux logments. J’imagine qu’il n’a pas les problèmes que je rencontre. Donc ma question est pourquoi moi je suis full time a chercher d’où ça déconne ?! je vais essayer de retouver ce post
Bonjour,
Car tu as zigbee2mqtt en 1.36 et qu’il est reputer pour avoir ce genre de soucis.
Pour le reste ca peut aussi venir du choix des modules zigbee c’est un peu la jungle et la certification n’est pas assez strict.
Je pense que c’est là que le bât blesse, j’ai du Xiaomi, Sonoff, Tuya, Ikea …
et quand je lis ça je comprends bien que c’est le souk ici:
Since Xiaomi devices do not fully comply to the Zigbee standard, it sometimes happens that they disconnect from the network.
Et pourquoi pas une « certification » Jeedom ?
On a pas les moyen humain pour ça ni financier. Faudrait tester les modules un par un et toute les combinaisons possible dans tous les cas possible (limite de porté et autre) et même en faisant ça j’aurai encore des cas ou chez les utilisateurs ça irait pas (interférences, firmware différent de celui testé et j’en passe)
Bonjour
Dès que je pourrai arrêter le chauffage je vais refaire l’inclusion de tous les modules du réseau (+/-50)
Voici comment je pense procéder :
Suppression des équipements de Z2M mais en gardant la config dans Jeedom
Reset des équipements
Inclusions des routeurs du plus près au plus loin du coordinateur.
Inclusion des end devices
L’idée est de refaire un maillage propre mais aussi d’identifier les eventuels équipements « défaillants » qui pourraient mettre le souk dans mon réseau.
Sachant que le shéma et les lqi sont a prendre avec précaution comment m’assurer au fur et à mesure que les équipements fonctionnenent correctement ?
Bonjour @emmanuel_be . Ou en es tu apres quelques mois passés ? l’install est devenue stable ?
J’ai un Jeedom avec z2m derniere version, un 1er ami avec une version Zigbee2MQTT 1.35.0 et un autre avec une version intermediaire (comme il est parti en vacs, on fera la mise a jour a son retour). Les versions z2m est la derniere sur toutes les install
Sur ces 3 installs et de facon aléatoire, j’ai aussi des soucis de commandes. Les remontées d’infos Zigbee fonctionnent toujours mais quelques commandes ne passent plus , comme ce soir chez moi avec ma lampe de présence qui ne s’est pas allumée.
J’ai toujours accès a l’interface Zigbee2MQTT
Juste obligé de redemarrer z2m pour que cela reviennent.
J’ai une clé Zigbee SONOFF-E sur toutes les install
@Loic , pourquoi le fait de relancer z2m deboque la situation ? Que fait cette relance exactement ? Comme j’ai un peu de temps a perdre, j’aimerai essayer de trouver un moyen de determiner ce blocage d’envoi de commande pour pouvoir a defaut de corriger au moins redemarrer automatiquement le module quand cela est necessaire
Merci
Bonjour,
Les lqi sont à titre informatif et donnés uniquement pour la ligne « device » - « controller » mais la table de routage, elle, prend en compte le meilleur chemin.
Que penser d’un lqi à 0 ? (Oui Oui, 0 !) 
Et pourtant cette prise marche TRES bien et est parfaitement réactive ! 
…parce que le maillage autour est très correct ! 
Il faut arréter de psychoter avec les lqi, il faut regarder le schéma donné par l’interface Z2M !
Bonjour,
Comme le dit la commande ca relance le demon; le demon c’est zigbee2mqtt donc ca relance zigbee2mqtt. Aucune idée ensuite de ce que ca fait nous ne faisons pas zigbee2mqtt mais je suppose que ca reset le buffer de la clef zigbee et donc debloque la situation.
Merci pour ton retour. Donc z2m relance automatiquement zigbee2mqtt ?
J’ai récupéré quelques logs que j’avais mis en mode DEBUG et j’ai vu quelque chose d’interessant
Tout d’abord, la commande d’allumage de la lampe n’est pas passée :
|[2024-08-17 20:33:02] debug: |z2m: Publishing 'set' 'state' to 'LampeRGBSalon'|
|---|---|
|[2024-08-17 20:33:02] debug: |zh:controller:endpoint: ZCL command 0xa4c1388b115429f6/1 genOnOff.on({}, {timeout:10000,disableResponse:false,disableRecovery:false,disableDefaultResponse:false,direction:0,srcEndpoint:null,reservedBits:0,manufacturerCode:null,transactionSequenceNumber:null,writeUndiv:false})|
Ensuite , apres redemarrage Daemon , la commande passe :
[2024-08-17 21:18:01] debug: z2m:mqtt: Received MQTT message on 'zigbee2mqtt/0xa4c1388b115429f6/set' with data '{"state":"ON"}'
[2024-08-17 21:18:01] debug: z2m: Publishing 'set' 'state' to 'LampeRGBSalon'
[2024-08-17 21:18:01] debug: zh:controller:endpoint: ZCL command 0xa4c1388b115429f6/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
[2024-08-17 21:18:01] debug: zh:ezsp: sendZclFrameToEndpointInternal 0xa4c1388b115429f6:12482/1 (0,0,2), timeout=10000
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: ==> sendUnicast: {"type":0,"indexOrDestination":12482,"apsFrame":{"profileId":260,"sequence":9,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"messageTag":10,"message":{"type":"Buffer","data":[1,5,1]}}
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: ==> {"_cls_":"sendUnicast","_id_":52,"_isRequest_":true,"type":0,"indexOrDestination":12482,"apsFrame":{"profileId":260,"sequence":9,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"messageTag":10,"message":{"type":"Buffer","data":[1,5,1]}}
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> DATA (5,0,0): 350001340000c23004010600010100010000090a03010501
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> [507721a9602a157069904b23aa5493499d4e27a2e7cd668efc29447e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: -?- waiting (6)
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- [0677a1a9602a154286957e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- DATA (0,6,0): 0677a1a9602a154286957e
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> ACK (1)
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> [8160597e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- ACK (6): 0677a1a9602a154286957e
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== Frame: 358001340000f0
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== 0x34: {"_cls_":"sendUnicast","_id_":52,"_isRequest_":false,"status":0,"sequence":240}
[2024-08-17 21:18:01] debug: zh:ezsp:uart: -+- waiting (6) success
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- [1677b1a96b2a157069904b23aa5493499c4e275be7ce679edb7e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- DATA (1,6,0): 1677b1a96b2a157069904b23aa5493499c4e275be7ce679edb7e
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> ACK (2)
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> [82503a7e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- ACK (6): 1677b1a96b2a157069904b23aa5493499c4e275be7ce679edb7e
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== Frame: 3590013f0000c23004010600010100000000f00a0000
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== 0x3f: {"_cls_":"messageSentHandler","_id_":63,"_isRequest_":false,"type":0,"indexOrDestination":12482,"apsFrame":{"profileId":260,"sequence":240,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":0},"messageTag":10,"status":0,"message":{"type":"Buffer","data":[]}}
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- [2677b1a90d2ad782afbd1e34216d53ed1cf227955d7e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- DATA (2,6,0): 2677b1a90d2ad782afbd1e34216d53ed1cf227955d7e
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> ACK (3)
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> [83401b7e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- ACK (6): 2677b1a90d2ad782afbd1e34216d53ed1cf227955d7e
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== Frame: 3590015900c230f62954118b38c1a480bc00
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== 0x59: {"_cls_":"incomingRouteRecordHandler","_id_":89,"_isRequest_":false,"source":12482,"longId":{"type":"Buffer","data":[164,193,56,139,17,84,41,246]},"lastHopLqi":128,"lastHopRssi":-68,"relay":{"type":"Buffer","data":[]}}
[2024-08-17 21:18:01] debug: zh:ezsp:driv: handleRouteRecord: nwk=12482, ieee=��8�T)�, lqi=128, rssi=-68, relays=
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- [3677b1a97d312a15b658924a24ab5593499c77a7172ffe9874f8de6682fd7d5e3d980a7e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- DATA (3,6,0): 3677b1a9112a15b658924a24ab5593499c77a7172ffe9874f8de6682fd7e3d980a7e
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> ACK (4)
[2024-08-17 21:18:01] debug: zh:ezsp:uart: --> [8430fc7e]
[2024-08-17 21:18:01] debug: zh:ezsp:uart: <-- ACK (6): 3677b1a9112a15b658924a24ab5593499c77a7172ffe9874f8de6682fd7e3d980a7e
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== Frame: 359001450000040106000101000100003980bcc230ffff0518050b010002
[2024-08-17 21:18:01] debug: zh:ezsp:ezsp: <== 0x45: {"_cls_":"incomingMessageHandler","_id_":69,"_isRequest_":false,"type":0,"apsFrame":{"profileId":260,"sequence":57,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"lastHopLqi":128,"lastHopRssi":-68,"sender":12482,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[24,5,11,1,0]}}
[2024-08-17 21:18:01] debug: zh:ezsp: processMessage: {"messageType":0,"apsFrame":{"profileId":260,"sequence":57,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"lqi":128,"rssi":-68,"sender":12482,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[24,5,11,1,0]}}
[2024-08-17 21:18:01] debug: zh:controller: Received payload: clusterID=6, address=12482, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=128, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":5,"commandIdentifier":11},"payload":{"cmdId":1,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}}
[2024-08-17 21:18:01] debug: z2m: Device 'LampeRGBSalon' reconnected
[2024-08-17 21:18:01] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/LampeRGBSalon/availability', payload '{"state":"online"}'
[2024-08-17 21:18:01] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/LampeRGBSalon', payload '{"brightness":152,"color":{"x":0.4657,"y":0.4118},"color_mode":"color_temp","color_temp":380,"device":{"applicationVersion":101,"dateCode":"","friendlyName":"LampeRGBSalon","hardwareVersion":1,"ieeeAddr":"0xa4c1388b115429f6","manufacturerID":4417,"manufacturerName":"_TZ3210_ifga63rg","model":"TS0505B_1","networkAddress":12482,"powerSource":"Mains (single phase)","stackVersion":0,"type":"Router","zclVersion":3},"last_seen":"2024-08-17T19:18:01.509Z","linkquality":128,"state":"OFF"}'
[2024-08-17 21:18:01] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/LampeRGBSalon', payload '{"brightness":152,"color":{"x":0.4657,"y":0.4118},"color_mode":"color_temp","color_temp":380,"device":{"applicationVersion":101,"dateCode":"","friendlyName":"LampeRGBSalon","hardwareVersion":1,"ieeeAddr":"0xa4c1388b115429f6","manufacturerID":4417,"manufacturerName":"_TZ3210_ifga63rg","model":"TS0505B_1","networkAddress":12482,"powerSource":"Mains (single phase)","stackVersion":0,"type":"Router","zclVersion":3},"last_seen":"2024-08-17T19:18:01.509Z","linkquality":128,"state":"ON"}'
[2024-08-17 21:16:26] debug: z2m:mqtt: Received MQTT message on 'zigbee2mqtt/0xa4c1388b115429f6/set' with data '{"state":"ON"}'
[2024-08-17 21:16:26] debug: z2m: Publishing 'set' 'state' to 'LampeRGBSalon'
[2024-08-17 21:16:26] debug: zh:controller:endpoint: ZCL command 0xa4c1388b115429f6/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
[2024-08-17 21:16:26] debug: zh:ezsp:uart: <-- [46dfb1a97d312a15b658944a24ab5593499cee531285829874f2cea583fd7d5e1f670932fe596b00e7dbd7c72b7e]
[2024-08-17 21:16:26] debug: zh:ezsp:uart: <-- DATA (4,6,0): 46dfb1a9112a15b658944a24ab5593499cee531285829874f2cea583fd7e1f670932fe596b00e7dbd7c72b7e
[2024-08-17 21:16:26] debug: zh:ezsp:uart: --> ACK (5)
[2024-08-17 21:16:26] debug: zh:ezsp:uart: --> [8520dd7e]
[2024-08-17 21:16:26] debug: zh:ezsp:uart: <-- ACK (6): 46dfb1a9112a15b658944a24ab5593499cee531285829874f2cea583fd7e1f670932fe596b00e7dbd7c72b7e
[2024-08-17 21:16:26] debug: zh:ezsp:ezsp: <== Frame: 9d900145000004010000010100010000a074b9684cffff0f08c60a010020c0e2ff2036e4ff200002
[2024-08-17 21:16:26] debug: zh:ezsp:ezsp: <== 0x45: {"_cls_":"incomingMessageHandler","_id_":69,"_isRequest_":false,"type":0,"apsFrame":{"profileId":260,"sequence":160,"clusterId":0,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"lastHopLqi":116,"lastHopRssi":-71,"sender":19560,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[8,198,10,1,0,32,192,226,255,32,54,228,255,32,0]}}
[2024-08-17 21:16:26] debug: zh:ezsp: processMessage: {"messageType":0,"apsFrame":{"profileId":260,"sequence":160,"clusterId":0,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"lqi":116,"rssi":-71,"sender":19560,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[8,198,10,1,0,32,192,226,255,32,54,228,255,32,0]}}
[2024-08-17 21:16:26] debug: zh:controller: Received payload: clusterID=0, address=19560, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=116, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":198,"commandIdentifier":10},"payload":[{"attrId":1,"dataType":32,"attrData":192},{"attrId":65506,"dataType":32,"attrData":54},{"attrId":65508,"dataType":32,"attrData":0}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}}
On voit bien que ca se bloque soit dans zh:controller, soit dans zh:ezsp
Ce qui est troublant c’est que la remontée des infos continuent de fonctionner et que certaines commandes passent toujours a priori
Je vais continuer a creuser. Je vais rajouter mes logs. Comme le phenomene reste aléatoire et rare, ca risque de prendre quelques temps…
Bonne journée
Le mieux serait d’ouvrir une issue sur le github de zigbee2mqtt directement c’est eux qui font zigbee2mqtt et donc ils pourront te repondre, ici pas sur que quelqu’un est le niveau d’expertise dont tu as besoin.
Oki, je vais faire ca comme ca
Je vais chercher aussi un peu de mon coté pour essayer de dégrossir, mais pas sur d’y arriver
C’est un peu frustrant car ca marche super bien, c’est plus cool , mais parfois juste un blocage comme ca
J’ai bien compris que les clés USB SONOFF ne semblent pas top mais quand on ne connait pas trop au départ, on se dit que ca devrait le faire
Merci en tout cas
Honnetement sur le marché ya pas de clef top en vrai c’est un peu frustrant mais les fabricants vendent des clefs mais ne font aucun suivi derriere ou le stric minimum… Perso de plus en plus quand je peux j’utilise le pont hue.
Bonjour @fcafca60,
Je ne partage pas vraiment ton avis et je suppose que tu as une clé USB Zigbee SONOFF … mais laquelle (La « P » ou la « E ») et avec quel firmware ?
Merci , bon a savoir si evolution chez moi