Bonjour,
J’avais le même problème et j’ai eu une solution par Domotic-Store.
1/ Supprimer l’équipement qui ne fonctionne pas.
2/ afficher les réseaux Zigbee
3/ puis les Noeuds
4/ Si il reste une ligne relative à l’équipement qui vient d’être supprimer, la supprimer.
5/ fermer la fenêtre des réseaux Zigbee
6/ synchroniser
7/ inclure de nouveau l’équipement.
Dans mon cas (Box Jeedom Atlas avec plugin Zigbee) cela a fonctionné.
Bonjour,
J’ai le même soucis avec ce module et lé Conbee2.
J’ai essayé 2 fois le tips proposé par @PhilippeM mais rien y fait, toujours la même erreur 
Pas vraiment envie d’avoir 2 clés Zigbee
Pas de fix du coté des dev du plugin Zigbee ?
Merci
Bonjour,
Juste pour signaler que j’ai exactement le même problème.
Conbee 2 et module ssm-u01
Jeedom entièrement à jour
J avais acheté le module exprès car présent dans la liste de comptabilité…
Encore une déception…
Bonsoir,
Exactement le même problème.
Pour info, je l utilisais avant sans aucun problème avec le plugin Deconz et ma clé conbee2.
Suite à différents problèmes avec Deconz j ai décidé de tout migrer sur le plugin zigbee et c est le seul module qui ne fonctionne pas ….
Quelqu’un a t’il ouvert une demande de support ?
Demande de support fait, voici la réponse :
Bonjour,
C’est un bug en cours du aux dernières mises à jour de firmware de Aquara qui cherche a couper toute compatibilités avec des plateformes autre que la leur. Malheureusement nous ne pouvons pas vous dire si nous arriverons a passer leur sécurité et si oui quand. En attendant le seul truc que vous pouvez faire c’est relancer l’installation des dépendances du plugin et refaire une inclusion (en maintenant bien le module éveillé même si c’est un module sur secteur) et voir si ca corrige.
cela n’a pas fonctionné.
Bonjour,
pareil pour moi !!!
je relance le sujet !!
+
Doudou
Bonjour,
Le fabricant a changé le firmware donc le module n’est plus compatible, vous pouvez essayer de relancer les dependances jusqu’a ce que ca marche (en gros jusqu’a ce que zigpy integre le nouveau firmware)
Hello
Je suppose que ça veut dire que le module ne va plus fonctionner avec le plugin Zigbee, quelle que soit la clé utilisée (Conbee II et EZSP pour moi) ?
A ce jour j’en ai 3 sur 5 installés qui ne fonctionnent plus (je n’ai pas vérifié le 6e de spare). Le 3e en défaut fonctionnait encore hier matin.
Est-ce que si je décoche la case de « Autoriser les mises à jour Over-The-Air » (comme je viens de le faire), ça va empêcher le firmware de se mettre à jour ? Est-ce que ça pourrait sauver les 2 qui restent (et le spare qui n’est pas branché) ? Ou si ça n’est pas la bonne option, y en a-t-il une autre ?
Merci d’avance. J’utilise ces modules pour mon chauffage, d’ici octobre pas trop de souci, mais d’ici là si c’est confirmé, il faut trouver une solution de repli.
Honnêtement je peux pas te répondre tous ce que j’ai dit n’est que des suppositions
Ah, je ne l’avais pas compris comme une supposition.
Du coup je suis allé voir sur 2 modules, un qui fonctionne pour l’instant et un qui ne fonctionne pas et dans « information sur le logiciel » j’ai la même chose :
Informations logiciel
ZCL Version : 3 APP Version : 21 Stack Version : 0 HW Version : 1 Date code : Aug 8 2020 Software version :
Août 2020, ça n’est pas récent comme firmware !
Est-ce que @fx95 qui a une une réponse du support (de qui, du reste ?) pourrait donner la version du module concerné ?
Merci d’avance
Le support c’est moi… Donc ça sera la même réponse… La désolé aucune idée du soucis c’est un truc avec le module mais le fabricant ne fait du support que si c’est utilisé avec son système…
Hello
Merci pour la réponse, mais j’avoue que je ne pige pas.
Je prends 2 modules identiques, avec la même version de firmware, et configurés de la même façon, SSM-U01 module Aqara avec neutre. Un qui fonctionne et un qui ne fonctionne pas.
Si je compare ligne à ligne les informations brutes, il n’y a que peu d’information qui changent, et elles me semblent normales :
{
{
"id": 31,
"status": 1,
"device_type": 256,
"profile_id": 260,
"manufacturer": null,
"model": null,
"output_clusters": [],
"input_clusters": [
{
"id": 12,
"name": "AnalogInput",
"attributes": [
{
"id": 85,
"name": "present_value",
"value": 15.36557388305664
La dernière value est à 0 pour l’équipement qui ne fonctionne plus alors qu’lelle est à 15.365xxxxxx pour celui qui fonctionne (copié ci-dessus).
Et c’est tout
Alors à moins que cette dernière valeur ne change tout, je ne vois pas pourquoi deux équipements identiques avec la même version de firmware, gérés sur la même machine dans le même logiciel avec la même configuration se mettent à réagir de manière différente alors qu’ils fonctionnaient tous les deux.
Est-ce que cette différence peut avoir une incidence quelconque ?
Merci d’avance
Non cette valeur est une valeur d’un capteur et n’a aucun influence. Malheureusement la je ne peux pas t’aider je ne sais pas non plus ce qui ne va pas…
Bon, je tente ma chance une dernière fois - dans l’intervalle j’ai essayé l’intégration sur un module neuf mais que je gardais en spare et que j’avais commandé en même temps que les 5 autres. Mais je ne parviens pas à faire l’intégration.
J’ai trouvé une différence qui n’a probablement aucune importance, mais qui se vérifie sur tous mes modules.
Dans la configuration Json.
Au début de la configuration Json des 2 modules qui fonctionnent, il y a :
{
"name": "LUMI.lumi.switch.n0agl1",
"configuration": {
"heating": [],
"cooling": [],
"stoping": [],
"window": [],
"failure": [],
"failureActuator": [],
"orderChange": [],
"existingMode": [],
"sendToHomebridge": "0"
},
Alors qu’au début de celle des 4 modules qui ne fonctionnent plus/pas il y a seulement :
{
"name": "LUMI.lumi.switch.n0agl1",
"configuration": {
"sendToHomebridge": "0"
},
Ensuite tout est pareil…
Je ne sais pas à quoi correspond cette différence, mais le fait que 2 modules qui fonctionnent aient la même chose, et les 4 qui ne fonctionnent soient identiques aussi entre eux m’interpelle.
Ai-je un moyen de forcer d’une manière ou d’une autre la config d’un module qui ne fonctionne pas afin qu’il ait une config identique à celle d’un qui marche ?
Je voudrais essayer au moins ça avant de tout jeter…
Merci beaucoup
Bonjour
Ça n’a rien a voir ça c’est interne jeedom et c’est pas la que se situe le soucis.
Hello, j’ai le même problème, et en faisant une « découverte des commandes d’information », bouton bleu en haut quand je suis dans un module, j’ai un nouvelle commande qui apparaît.
Elle ne réagit que dans un sens à l’interrupteur qui est devant (vers le haut, mais pas vers le bas), mais au moins j’ai un début de fonctionnement.
Mulb
Bonjour ,j’avais la même galère mais j’ai appliqué la solution d’ Audrey de Domadoo (Merci Audrey !) j’
Soit :
« Il faut savoir que le cluster 6 (celui du ON/OFF) ne remonte jamais à la première inclusion. Il faut supprimer le noeud dans le réseau zigbee et pas seulement supprimer l’équipement. Puis, ré-inclure le module. »
j’ai aussi actionné le module pendant l’inclusion (Je ne sais pas si c’était utile mais la doc dit de le maintenir éveillé pendant l’inclusion)
Voilà , en espèrant que cela règle votre pb
merci je vais ressayer… parce que ma solution fonctionne pas !
la commande qui apparait chez moi est celle de la consommation, du coup, ça se lance un peu n’importe quand, c’est pas dû à l’appui sur le bouton 
Hello
Je relance ce sujet car si, après l’avoir ouvert, l’an passé, j’étais finalement parvenu à récupérer le On Off, je suis à nouveau confronté au problème sur 2 modules qui ne communiquent plus et qui refusent de s’intégrer normalement. L’intégration passe, mais les commandes on off ne fonctionnent pas et retournent une erreur.
Je viens d’essayer une bonne vingtaine de fois sur un des modules, en le supprimant à chaque fois des noeuds, et en le supprimant ou pas de Jeedom selon les essais. J’ai essayé à la fois sur une clé EZSP Atlas et sur une clé Conbee, les deux étant rattachée au plugin Zigbee avec la même absence de résultat positif.
Toujours le même message d’erreur sur un On par exemple :
Erreur exécution de la commande [AutresEtage][sw-sam][On] : Erreur lors de la requete : http://127.0.0.1:8065/device/command(PUT), data : {"ieee":"54:ef:44:10:00:15:97:12","cmd":[{"endpoint":1,"cluster":"on_off","command":"on","await":1}],"allowQueue":false} erreur : {"state":"error","result":"[54:ef:44:10:00:15:97:12][zdevices.command] Cluster not found : on_off","code":0}
Pas de cluster…
Est-ce que quelqu’un aurait une explication ? Ou une solution ?
Merci d’avance
Edit : Alternativement, est-ce que quelqu’un aurait un module similaire d’une autre marque, d’au moins 10A et avec mesure de consommation (et moins récalcitrant) ?
Bonjour,
Sujet au meme probleme, et ne pouvant pas utiliser le ON/OFF a la première inclusion, le fait de supprimer le noeud et le module pour le réinclure, a fonctionné pour l’installation de 3 modules.
Le fait d’appuyer sur le bouton d’inclusion lors des 30 secondes de synchro, je ne sais pas si c’est utile, mais je l’ai fait.
Joël.