Empêcher le contrôle d'une prise zigbee aqara smart plug avec télécommande IKEA Strybar

Mon problème

Bonjour a tous,

Le contexte:

Sous home assistant OS, j’utilise une clé conbee 2 et Zigbee2mqtt. Pour étendre le réseau zigbee, (et surveiller la consommation de mon PC) j’ai une prise aqara qui fait donc aussi routeur zigbee :

J’ai aussi une télécommande IKEA Strybar que j’utilise pour gérer des lumières.

Le probleme :

Lorsque j’appuie sur les boutons allumer et éteindre de la télécommande, la prise aqara s’allume et s’éteint en même temps que les lumières que j’ai programmé dessus.

Je n’ai programmé aucune automatisation pour ça et ça ne se produit que si la télécommande est connectée à HA via la prise. (Si elle est connectée directement à la conbee 2 tout va bien.

Je pense que la commande on off envoyée par la télécommande est reconnue par la prise même si elle ne lui est pas destinée.
L’information est transmise jusqu’à ma lumière mais elle éteint aussi mon pc au passage.

Quelqu’un aurait-il déjà rencontré ce genre de soucis ou aurait une idée pour que la prise ne reagisse pas à cette télécommande ?
Ou pour forcer la télécommande a se connecter directement à la conbee 2 sans jamais passer par la prise ?

J’espère que je n’ai pas été trop confus dans mes explications et je vous remercie d’avance.

Ma configuration


System Health

version core-2022.6.4
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.12
os_name Linux
os_version 5.15.32-v8
arch aarch64
timezone Europe/Paris
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 5000
Installed Version 1.25.5
Stage running
Available Repositories 1049
Downloaded Repositories 36
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 8.1
update_channel stable
supervisor_version supervisor-2022.05.3
agent_version 1.2.1
docker_version 20.10.14
disk_total 234.3 GB
disk_used 17.1 GB
healthy true
supported true
board rpi4-64
supervisor_api ok
version_api ok
installed_addons Grafana (7.6.0), Node-RED (12.0.2), Terminal & SSH (9.4.0), File editor (5.3.3), RPC Shutdown (2.2), Mosquitto broker (6.1.2), Zigbee2mqtt Edge (edge), Let’s Encrypt (4.12.2), FTP (4.6.0), Samba share (9.6.1), Studio Code Server (5.1.0), Zigbee2mqtt (1.18.1-1), deCONZ (6.14.1), Samba Backup (5.0.0), MariaDB (2.4.0), phpMyAdmin (0.8.0), InfluxDB (4.5.0)
Dashboards
dashboards 2
resources 26
views 6
mode storage
Recorder
oldest_recorder_run 7 juin 2022, 22:17
current_recorder_run 13 juin 2022, 02:40
estimated_db_size 139.11 MiB
database_engine mysql
database_version 10.4.19

Salut, pour moi, ta télécommande est bindé sur la prise (en dehors de home assistant), il faut que tu fasse un reset de ta télécommande puis que tu la re-appairie dans zha (ou deconz ou zigbee2mqtt, enfin le soft zigbee que tu utilise )

1 « J'aime »

C’est ce que j’ai pensé aussi. J’ai essayé d’appairer plusieurs fois la télécommande et la prise séparément. Mais quand la télécommande est connectée directement à la conbee 2 la prise ne réagit pas. Du coup je ne pense pas que les 2 appareils soient bindés ensemble.

Salut.

Ce que tu visualises là c’est l'appairage (qui parle avec qui). Le bind c’est différent (qui commande qui).
D’où la proposition de @roumano qui a du sens de faire un reset. J’irai même jusqu’à faire celui de la prise et celui de la télécommande pour être sur.
Et pour être certain de la manip, je mettrai la prise dans un coin non branchée le temps de lier la télécommande avec l’ampoule. Ensuite quand c’est OK, repartir sur la mise en service de la prise

Oui j’ai bien compris la différence.
L’appairage c’est ma prise et ma télécommande Ikea qui sont reliés à HA via Zigbee2mqtt.
Le bind c’est la télécommande directement reliée à la prise et ça je ne peux pas le voir vu que ça ne passe pas par un serveur.
J’ai mis une capture de l’appairage pour illustrer le fait que la télécommande était directement connectée à la clé conbee 2 et que comme ça je n’avais pas d’actions sur la prise. C’était peut être maladroit.

J’ai essayé plusieurs choses.

1 reset de la prise (+ nouvel appairage a z2m)
2 reset de la telecommande ( + nouvel appairage a z2m)
Même souci
3 reset de la prise avec les piles de la télécommande retirées
Même souci
4 reset de la télécommande juste a côté de la conbee 2 pour la connecter directement.
La prise est branchée mais elle ne réagit pas.

Je savais que la télécommande Ikea pouvait être bindée sur des ampoules de la même marque mais je n’aurais jamais pensé sur une prise de marque chinoise. Après ça reste du zigbee donc pas impossible non plus mais étonnant.

Pour être sûr que le souci était résolu J’ai essayé d’appairer les 2 appareils ensemble sans passer par HA… Impossible
J’ai appairé les 2 appareils a HA via z2m comme je l’avais fait avant et en effet, ça continue à contrôler la prise même quand le raspberry est coupé.

Donc c’était bien ça le souci.
Mais après reset de la télécommande prise débranchée, ça le souci ne se pose plus… Jusqu’à ce que le signal repasse par la prise.

Comment je pourrais supprimer définitivement le lien entre la prise et la télécommande ?

1 « J'aime »

Comme dit plus haut fait un reset des 2 en premier. Si ça reviens ça voudrait dire que ta prise reste en mode binding permanent et que donc dès qu’elle capte la télécommande, elle s’associe.
Pour info le binding est visible sous z2m (forcement j’en ai pas)

Ah je ne savais pas qu’on pouvait le voir ici.
J’ai effectivement des choses dans l’onglet lien dès 2 appareils mais je ne peux rien modifier.meme après un redémarrage de z2m.



Je vais faire quelques tests voir si je trouve la logique a tout ça.
Je vais les réinitialiser séparément encore une fois mais en laissant un bon moment entre les 2 appairages.
Peut être qu’un des 2 appareils reste en mode appairage un moment même après avoir été ajouté dans z2m.
Je vais voir tout ça à tête reposée je reviendrais faire un retour
En tout cas merci beaucoup pour votre aide ça m’a donné des pistes.

il n’y a pas de lien entre appairage et binding :

  • l’appairage s’arrête seul sur la prise après réalisation (et que OK)
  • le mode appairage peut rester actif par la suite sur le coordinateur (conbee2), sans pour autant déclencher le binding
  • le binding est une procédure complétement à part !

Oui je comprends mais il n’y a rien qui me dit que la prise ou la telecommande sont en mode binding ou pas. Les voyants s’arrêtent de clignoter une fois associés a HA.
Il n’y a pas d’allusion a ca non plus dans les notices des appareils.
J’ai une 2eme télécommande Ikea (même modèle) qui ne s’est pas du tout associée avec la prise.
J’ai encore un peu d’espoir d’y arriver :sweat_smile:

J’ai tenté un nouvel appairage séparé des 2 appareils.
1 réinitialisation de la prise seule (piles de la télécommande retirées.
Attente 30 minutes pour être sûr que tout soit terminé puis j’ai débranché la prise
2 réinitialisation de la télécommande Ikea.(prise toujours débranchée)
Attente encore 30 J’ai ensuite rebranché la prise

Sur le coup aucun souci la télécommande est reliée directement au coordinateur (conbee 2)

30 minutes plus tard toujours aucun

Ce matin , la télécommande est de nouveau bindée sur la prise. (a savoir que mon HA redémarre pendant la nuit mais je ne pense pas que ça joue énormément)

Le routeur (prise) étant plus proche que le coordinateur (conbee2) la télécommande s’est connectée au routeur et s’est bindée dessus automatiquement.

Je pense que je ne peux rien y faire je vais utiliser cette prise pour autre chose que mon pc (si je ne veux pas l’éteindre sauvagement chaque fois que j’éteins la lumière :sweat_smile:)

Le réseau maillé zigbee se fait automatiquement du coup je ne pense pas que je puisse forcer la télécommande a rester connectée sur le coordinateur sans jamais se connecter au routeur.

En tout cas merci d’avoir pris du temps pour me venir en aide.

Bonsoir,

Je suis confronté au meme souci. J’esperais trouvé une solution a mon souci ici, petite deception :slight_smile:
On dirait que l’interpupeur et la prise se lie sans passe par HA, j’avais le meme souci quand j’etais sous Jeedom.

Une réinclusion regle le souci, pour une tres courte durée …

Bien à vous

Antoine

Bonjour,

Oui une très courte durée. Je n’ai pas trouvé la solution.
Je l’ai finalement placée suffisamment loin de mes télécommandes pour qu’elles ne puissent pas interférer.

Cela ne semble pas le cas pour les personnes ayant des soucis, mais quand on utilise zha, zha-toolkit permets de lire les bindings.

Un exemple et une partie de l’essentiel des réponses d’une lumière et une télécommande suivent. Pour la télécommande, il faut appuyer de façon répétée sur un bouton afin de la réveiller pour répondre aux requêtes.

service: zha_toolkit.binds_get
data:
  ieee: sensor.tyzb01_bngwdjsr_ts1001_power
  tries: 100
  event_done: zha_done

Et le résultat en écoutant l’événement zha_done:

event_type: zha_done
data:
  ieee_org: light.tz3000_odygigth_ts0505a_12c90efe_level_light_color_on_off
  command: binds_get
  success: true
  result:
    "0":
      # De l'objet vers le coordinateur
      src: 84:2e:14:ff:fe:0e:c9:12
      src_ep: 1
      cluster_id: "0x0006"
      dst:
        addrmode: 3
        dst_ieee: 00:12:4b:00:01:6a:41:0c
        dst_ep: 1
    "1":
      # De l'objet vers le coordinateur
      src: 84:2e:14:ff:fe:0e:c9:12
      src_ep: 1
      cluster_id: "0x0300"
      dst:
        addrmode: 3
        dst_ieee: 00:12:4b:00:01:6a:41:0c
        dst_ep: 1
    "2":
      # De l'objet vers le coordinateur
      src: 84:2e:14:ff:fe:0e:c9:12
      src_ep: 1
      cluster_id: "0x0008"
      dst:
        addrmode: 3
        dst_ieee: 00:12:4b:00:01:6a:41:0c
        dst_ep: 1
    "3":
      # De l'objet vers le coordinateur
      src: 84:2e:14:ff:fe:0e:c9:12
      src_ep: 1
      cluster_id: "0x0000"
      dst:
        addrmode: 3
        dst_ieee: 00:12:4b:00:01:6a:41:0c
        dst_ep: 1
    "4":
      # De l'objet vers le coordinateur
      src: 84:2e:14:ff:fe:0e:c9:12
      src_ep: 1
      cluster_id: "0x0019"
      dst:
        addrmode: 3
        dst_ieee: 00:12:4b:00:01:6a:41:0c
        dst_ep: 1
    "5":
      # De l'objet vers le groupe 2
      # Donc tous les objets qui écoutent le group 2  sont concernés
      src: 84:2e:14:ff:fe:0e:c9:12
      src_ep: 1
      cluster_id: "0x0000"
      dst:
        addrmode: 1
        group: "0x2"

Télécommande:

event_type: zha_done
data:
  ieee_org: sensor.tyzb01_bngwdjsr_ts1001_power
  command: binds_get
  result:
    "0":
      # De l'objet (télécommande) vers le coordinateur
      src: bc:33:ac:ff:fe:5e:56:b1
      src_ep: 1
      cluster_id: "0x0001"
      dst:
        addrmode: 3
        dst_ieee: 00:12:4b:00:01:6a:41:0c
        dst_ep: 1
    "4":
      # De l'objet vers le groupe 2
      src: bc:33:ac:ff:fe:5e:56:b1
      src_ep: 1
      cluster_id: "0x0008"
      dst:
        addrmode: 1
        group: "0x2"
    "5":
      # De l'objet vers le groupe 0
      src: bc:33:ac:ff:fe:5e:56:b1
      src_ep: 1
      cluster_id: "0x0008"
      dst:
        addrmode: 1
        group: "0x0"
    "6":
      # De l'objet vers le groupe 0
      src: bc:33:ac:ff:fe:5e:56:b1
      src_ep: 1
      cluster_id: "0x0006"
      dst:
        addrmode: 1
        group: "0x2"
    "7":
      # De l'objet vers le groupe 2
      src: bc:33:ac:ff:fe:5e:56:b1
      src_ep: 1
      cluster_id: "0x0008"
      dst:
        addrmode: 1
        group: "0x2"

Et pour la lampe, un zha_toolkit.get_groups permet de voir qu’il réagira aux groupe 2:

service: zha_toolkit.get_groups
data:
  ieee: light.tz3000_odygigth_ts0505a_12c90efe_level_light_color_on_off
  event_done: zha_done

Résultat (partielle):

event_type: zha_done
data:
  ieee_org: light.tz3000_odygigth_ts0505a_12c90efe_level_light_color_on_off
  ieee: "84:2e:14:ff:fe:0e:c9:12"
  command: get_groups
  groups:
    "1":
      name_support: 0
      groups:
        - 2
  success: true

Il se peut que la télécommande envoie vers le group 0 qui est le groupe général, ou bien vers un groupe dont la prise fasse partie.

Dans ce cas, les services zha_toolkit.remove_from_group et zha_toolkit.unbind_group peuvent vous être utiles en fonction des cas.
Le service zha_toolkit.binds_remove_all supprime tous les bindings, ce qui peut être un peu drastique et nécessite éventuellement de « réinitialiser » l’objet.
Il a été constaté que binds_remove_all est parfois « nécessaire » car même après avoir été désappairé ou « resetté », l’objet garde en mémoire ses bindings, remplissant cette mémoire « dédiée » pour atteindre la limite ce qui empêche de nouveau bindings.

Enfin, les services sont pour ZHA, pas Z2M ou Jeedom… Mais le principe reste le même.