Installation: ZHA - Sensor Zigbee - S31

Bonjour,
J’avance à Grand pas grace a votre aide, merci encore a tous :slight_smile:

J’ai donc pu ajouter ma clef Zigbee SOnoff , c’était un problème de db.
J’ai donc ajouter mes sensors temperature sonoff et une prise zigbee sonoff S31 (qui devrait fonctionner comme routeur).

Par contre je ne sais pas comment faire pour utiliser justement le S31 comme routeur afin de relayer le signal pour deux de mes sensor.

Également, ou puis je trouver la liste des devices compatibles avec cette clef? (Apparemment TUYA ne fonctionne pas)

Une idee svp ?

Voici la configuration : le rectangle (la clef zigbee), les rond (sensors temperature) et l’ovale (la prise S31)
Je démarre avec Zigbee et cette clef , alors peut etre avez vous besoin d’autres infos, n’hésitez pas :slight_smile:

Hello, personne n’a eu l’occasion d’utiliser un Sonoff S31 en fonction routeur ? L’idée est d’étendre mon réseau Zigbee.
Pareil,à propos des tuya, personne n’en utilise avec cette clef?
Merci :slight_smile:

Nouvel écran, c’est la première fois que j’utilise cet écran, il ne devait pas être à jour dans mon post précédent.

Je ne suis pas sûr, mais apparemment le S31 est bien répertorié comme routeur mais rien n’y est attaché.

Salut
Je ne sais pas comment fonctionne ZHA mais l’appairage doit avoir les même principes que z2m.
Dans mon cas, lors de l’appairage il est possible de préciser le routeur sur lequel l’appairage est actif

Merci Pulpy.
En fait ici avec ZHA je pense qu’il faut cliquer sur le device (ici S31) et choisir « ajouter un appareil », mais rien n’y fait. J’entends souvent parler de Z2M, est ce vraiment à la portée d’un débutant l’installation?

C’est pas plus difficile que le reste et puis tu n’es pas débutant.

https://forum.hacf.fr/t/zigbee2mqtt-monter-integrer-monitorer/224
Toute la partie programmation de la clé ne te concernera pas

As-tu essayer d’ajouter un appareil a partir du panneau d’information de ta prise S31, au lieu de le faire de ton dongle sonoff usb ?

Pulpy, intéressant. Il fautdrait donc que je rachète une autre clef. Je me retrouve déjà avec un hub Sonoff et maintenant une,clef Sonoff.:slight_smile: j’aurais dû attendre et lire tes conseils au,début :-)))
Merci encore

Warcozes, oui j’ai,cette manipulation également.
Je crois que j’ai tout essayé et hier soir très tard:-))) sans me rappeler comment, j’ai pu mettre un sensor sur le S31 et ce matin il était à nouveau déconnecté:-(

Salut.
Tu n’as pas bien lu ou je ne suis pas clair. Ta clé actuelle est déjà compatible.

Désolé Pulpy, j’ai pas du tout comprendre en effet.
Sur le lien que tu,as,partagé, ils expliquent l’utilité d’une « passerelle Universelle »: Zigate, Conbee et Zigbee2Mqtt
Et ensuite tout le matériel nécessaire pour « flasher » la clef, brancher et installation.
Donc j’ai pensé qu’il,fallait utiliser un autre matériel que celui que j’ai.
Je suis un peu perdu…

Puisque tu as déjà une clé (différente), la partie préparation ne te concerne pas (le matériel pour flasher, et la procédure de flash notamment). Par contre la section suivante Intégration à Home Assistant est applicable en l’état, la différence sera au niveau du nom de la clé

Quelques infos:

  • On ne peut pas vraiment « forcer » qu’un objet soit attaché à tel ou tel routeur - le réseau s’autorégule. Si la connexion directe est bonne, pourquoi passer par un intermédiaire?
  • Un objet qui fait routeur est représenté comme ovale - rien à faire en plus que de l’ajouter au réseau tout simplement.
  • Je pense que « Acutaliser la topologie » inititie une découverte des « chemins ». Ce n’est pas « immédiat », mais devrait se faire dans un délai raisonnable.
  • Les objets Tuya sont compatibles, mais parfois il faut essayer l’ajout des objets plusieurs fois. Des fois même cela semble mieux fonctionner juste après un rédémarrage (sur ma clef CC2531). L’incompatibilité ne se trouve pas tellement au niveau des couches les plus basses (envoyer des trames), mais les couches « logiques ». Tuya est assez « fort » pour faire les choses à sa sauce, mais cela n’empêche pas d’implémenter des contournements: zha-device-handlers/zhaquirks/tuya at dev · zigpy/zha-device-handlers · GitHub . Ces contournements sont présents sous ZHA - Z2M en a aussi.
  • En principe il n’y a pas besoin de changer de clef Zigbee.
  • Plus il y a de routeurs mieux c’est. La communication avec un routeur peut être temporairement perturbé, et s’il y a un deuxième pour prendre le relais c’est mieux.

J’ajoute 2 compléments

Certes il n’y a pas la main sur le chemin utilisé après, mais il est parfaitement possible de définir le routeur d’appairage.

A mon avis, c’est trop simpliste comme précision : avoir plusieurs routeurs certes ça garantie une alternative en cas de défaillance mais ça reste pas obligatoire.
Le gain le plus significatif c’est sur la surface couverte par une réseau mesh.
Quant à dire que plus il y en a, mieux c’est, ça veut aussi dire mettre de coté le brouhaha sur le réseau : entendre collisions/détections. C’est comme l’autoroute des vacances, ça va plus vite mais quand c’est saturé, ça marche pas forcement mieux

Oui, ce n’empêche pas que le lien de parenté change par la suite, donc on ne peut pas forcer le lien de parenté. Pouvoir le définir momentanément, n’est pas un forcage à mes yeux.

  • Il faut simplifier - ce qui joue aussi c’est l’orientation des antennes, leurs lobes, leur puissances, la sensibilité de réception, la cohabitation avec le WiFi, la performance des puces quant à tout cela.
    On peut aussi recommander les canaux 15, 20 et 25, recommander de fixer son canal WiFi assez loin en fréquence du canal zigbee, mesurer les WiFi des voisins (surtout en appartement), placer son coordinateur centralement, etc.
  • « La surface couverte » - mon propos simplifié est justement qu’il vaut mieux couvrir chaque espace (3D!) par les lobes de 2 routeurs que par un seul.
  • « colissions »: la durée maximum d’une transmission c’est 4.256 ms - ce qui voudrait dire 234 paquets l’une à la suite de l’autre en 1 seconde, mais il faut faire avec les ACK, etc. Selon un article on peut atteindre en pratique plus de 100 paquets suivi d’un ack par seconde. Je suppose que le CSMA/CA évite suffisamment les collissions (Carrier Sense Multiple Access with Collision Avoidance). En tous cas, en pratique il y a relativement peu de traffic sur un réseau Zigbee. En une grosse journée mes fichiers de capture représentent 12Mo (avec horodatage, etc). Soit 1.1kbps par seconde en première approximation, moins de 1% de la capacité du réseau.
    Je ne crois donc pas qu’il y a tant de colissions que cela - quand je sniffe les répétitions de paquets sans erreur de décodage, c’est plutôt indicateur d’une absence de colission.
    Par contre, j’ai déjà vu des objets qui répètent excessivement quand le ack n’arrive pas très rapidement, ayant pour effet de saturer le tampon de réception puisque chaque paquet doit être mémorisé et vérifié (somme de contrôle, vérification duplicata, etc). Entrainant donc plus d’absences d’ACK et des difficultés de communication en l’absence de colissions. C’est sûrement mieux avec les puces récentes, mais le CC2530 et CC2531 en souffrent.
  • « détections »: que devons nous comprendre? La détection du signal et l’ajustement de la chaine de pré-amplification à la puissance perçue rendant difficile la réception des signaux faible dans l’émetteur précédent avait un signal fort?

ça doit grandement dépendre du matériel. Sur le matériel récent, j’ai assez peu de doute sur la réalité de la ‹ bascule › … Sur du plus ancien c’est pas systématique. Par exemple mes DJT11LM sont indifféremment appariables à un router ou à la clé sans pour autant varier dans le temps

Je te rejoins sur les aspects position, orientation, 3D etc… Le souci c’est pour le commun des mortels il n’y a qu’une façon empirique de traiter tout ça. Et c’est valable dans toutes les topologies de réseau

Concernant les collisions il faut également prendre en compte que les messages sont généralement émis à des fréquences fixes (température toutes les minutes etc) Donc si on fait le calcul du nb de messages sur 24h ça à pour effet de lisser la répartition. D’autant plus que la plupart du temps 2 appareils qui se collisionnent auront tendance à le faire régulièrement justement à cause de cette fréquence.

Je constate aussi que le fonctionnement avec ma clé sonoff semble plus sain, c’est tant mieux si la version 3.0 corrige de genre de souci.

Détection n’est pas forcement le bon mot, on va plus dire un recalcul de la topologie. Cette partie est assez bavarde et donc plus on a de routeurs plus le calcul et long et fréquent.

En fait l’idée, c’était de dire que quand on ajoute des routeurs (et d’apareils), on a probablement une courbe de « la bonne santé du réseau » (au sens général) en forme de cloche.

Ok, merci Pulpy j’étais pas sûr :-))) je vais tenter cette intégration.

Le top, j’aimerais passer par le S31 car mes capteurs de température sont dans mon local technique en dehors de la maison. Ils perdent le signal assez rapidement.
J’avais réussi à lier un sensor sur le S31, mais le lendemain il était OFF Line. Même en actualisant la topologie, le fait est qu’il était vraiment déconnecté du réseau.
J’ai retenté ce matin de l’ajouter directement via le S31 mais rien n’y fait.
Je vais réessayer de le supprimer et de l’installer directement.
Si cela ne fonctionne toujours pas j’essayerais avec le Z2m

Bon alors j’ai re essaye de multiple manière et j’ai pu ajouter un sensor a S31, mais impossible d’en ajouter un autre…Donc c’est pas une solution qui est a 100% de mes besoins.

J’ai donc tente une installation de Z2MQTT. Par contre je me retrouve avec un écran noir sans informations…

  • doit on configurer la partie /config/zigbee2mqtt/configuration.yaml?
    D’ailleurs j’ai vu qu’il a change mon user name en « mqtt »…Concernant les channels a utiliser, idem je ne sais pas trop lequel choisir, il a mis « 11 » par défaut…:

  • dois je supprimer ZHA?

{
  "external_converters": [],
  "devices": [
    "devices.yaml"
  ],
  "groups": [
    "groups.yaml"
  ],
  "homeassistant": true,
  "permit_join": true,
  "mqtt": {
    "base_topic": "zigbee2mqtt",
    "server": "mqtt://192.168.xxxxx",
    "user": "mqtt",
    "password": "xxxxx"
  },
  "serial": {
    "port": "/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_bab65e0845c8eb11835ac5c3de5b81b4-if00-port0"
  },
  "advanced": {
    "log_level": "warn",
    "pan_id": 6754,
    "channel": 11,
    "network_key": [
      1,
      3,
      5,
      7,
      9,
      11,
      13,
      15,
      0,
      2,
      4,
      6,
      8,
      10,
      12,
      13
    ],
    "availability_blocklist": [],
    "availability_passlist": []
  },
  "device_options": {},
  "blocklist": [],
  "passlist": [],
  "queue": {},
  "frontend": {
    "port": 8099
  },
  "experimental": {},
  "availability": false
}

Ce soir le sensor que j’avais pu ajouter au SE1 est à nouveau déconnecte.
Dans le local technique j’ai beaucoup de Sonoff (en wifi), est ce que cela peut être une des raisons du décrochage récurent ? Je veux dire des interférences entre wifi et Zigbee?