Un coordinateur Zigbee PoE pour le fond du jardin

Dans l'article précédent, j'expliquais les protocoles retenus pour la nouvelle maison. Pour la couverture Zigbee et Thread de l'habitation, mon choix s'est porté sur une SLZB-MR5U, mais ce sera le sujet d'un autre article.

Aujourd'hui je voudrais parler d'un besoin plus spécifique : atteindre les équipements éloignés de la maison. Je possède par exemple une station météo Ecowitt WS90, dans sa version Shelly, qui communique en Bluetooth et en Zigbee. Seul ce dernier protocole m'intéresse.

Une station météo doit être installée en hauteur, exposée directement au ciel et dégagée de tout obstacle. Le seul emplacement qui remplit ces conditions chez moi se trouve loin de la maison, hors de portée de mon réseau Zigbee principal.

Je pourrais étendre ce réseau à travers le jardin en semant des routeurs, mais je préfère monter un second réseau distinct : c'est plus simple à gérer, et ça évite qu'un problème d'un côté n'affecte l'autre.

Le module

Vous connaissez peut-être déjà Sylvain, c'est la personne qui fabrique le module T-InfoDIN dont je parlais dans mon article sur la télé-information du compteur Linky. Il produit également des modules Zigbee alimentés en PoE, à base d'une carte Olimex ESP32-POE et d'une puce CC2652P.

C'est exactement la réponse à mon besoin : un module posé au bout d'un câble réseau, alimenté par ce même câble, qui monte un réseau Zigbee complet précisément là où j'en ai besoin.

J'en possède deux : le premier acheté à sa sortie, le second offert par Sylvain, que je remercie.

Trois ans de recul

Je devais écrire cet article il y a trois ans, et je ne l'ai jamais fait. Désolé Sylvain.

Le seul avantage de ce retard, c'est que je peux aujourd'hui en parler avec du recul plutôt qu'avec l'enthousiasme du déballage. Trois ans de fonctionnement continu, et pas le moindre incident sur toute la période. Une fiabilité à toute épreuve, ce qui est exactement ce qu'on demande à un équipement qu'on installe et qu'on oublie.

Cerise sur le gâteau, l'ESP tourne sous ESPHome, ce qui me permet de rester dans un écosystème unique.

ESPHome

Voici la configuration que j'utilise. Elle s'appuie sur stream_server, un composant externe qui n'est pas fourni avec ESPHome : il est récupéré automatiquement depuis GitHub à la compilation, mais gardez en tête que c'est une dépendance tierce.

esphome:
  name: gateway-zigbee
  on_boot:
    priority: 600
    then:
      - switch.turn_on: zRST_gpio
      - delay: 15ms
      - switch.turn_off: zRST_gpio

esp32:
  board: esp32-poe-iso
  framework:
    type: arduino

ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk:
    pin: GPIO17
    mode: CLK_OUT
  phy_addr: 0
  power_pin:
    number: GPIO12
    ignore_strapping_warning: true

external_components:
  - source: github://tube0013/esphome-stream-server-v2

logger:
  baud_rate: 0

binary_sensor:
  - platform: stream_server
    stream_server: ss
    name: "Serial Connected"

button:
  - platform: template
    name: "Zigbee Module Reset"
    id: zRST
    on_press:
      - switch.turn_on: zRST_gpio
      - delay: 15ms
      - switch.turn_off: zRST_gpio

  - platform: template
    name: "Trigger Zigbee Module Bootloader"
    on_press:
      - script.execute: fw_update_mode

mdns:
  services:
    - service: "_gatewayzb"
      protocol: "_tcp"
      port: 6638
      txt:
        version: 1.0
        name: GatewayZB
        radio_type: znp
        baud_rate: 115200
        data_flow_control: software

script:
  - id: fw_update_mode
    then:
      - switch.turn_on: zBSL
      - delay: 1s
      - switch.turn_on: zRST_gpio
      - delay: 1s
      - switch.turn_off: zRST_gpio
      - logger.log: "Delaying ~10 seconds for cc2652p2 to settle"
      - delay: 11s
      - switch.turn_off: zBSL
      - logger.log: "Please try update with cc2538-bsl tool now"
      - logger.log: "cc-bsl usage: cc2538-bsl.py -p socket://ip-of-gw:6638 -evw firmware.hex"

switch:
  - platform: gpio
    pin: 13
    id: zRST_gpio
    inverted: yes
    restore_mode: ALWAYS_OFF

  - platform: gpio
    pin:
      number: 5
      ignore_strapping_warning: true
    name: "Gateway - Zigbee - Zigbee Module Bootloader Pin"
    id: zBSL
    inverted: yes
    restore_mode: ALWAYS_OFF
    disabled_by_default: true

uart:
  id: uart_bus
  rx_pin: GPIO36
  tx_pin: GPIO4
  baud_rate: 115200

stream_server:
  uart_id: uart_bus
  id: ss
  port: 6638

Zigbee2MQTT

Voici la configuration à utiliser sous Zigbee2MQTT pour vous connecter à ce module :

serial:
  rtscts: false
  port: tcp://adresse_ip_de_votre_module:6638
  adapter: zstack
  baudrate: 115200

Mettre à jour le firmware

Le module fonctionne dès la sortie de la boite, mais la puce CC2652 réclame de temps en temps une mise à jour de son firmware. Deux outils permettent de le faire :

• ZigStar Multi Tool, avec une interface graphique, de loin le plus simple
• cc2538-bsl, en ligne de commande, pour ceux qui préfèrent

Le firmware lui-même se récupère sur le dépôt Z-Stack de Koenkk. Attention à bien prendre la variante correspondant à votre puce : au moment où j'écris ces lignes, la dernière version pour le CC2652P est CC1352P2_CC2652P_launchpad_coordinator_20250321.

La procédure est assez simple : il suffit d'appuyer sur le bouton Trigger Zigbee Module Bootloader et d'attendre l'affichage de ce message dans les journaux :

Please try update with cc2538-bsl tool now
cc-bsl usage: cc2538-bsl.py -p socket://ip-of-gw:6638 -evw firmware.hex

Je vous invite à lire la documentation de l'outil que vous aurez choisi pour connaitre la marche à suivre. Quel que soit l'outil, l'adresse de mise à jour correspondra à l'adresse IP de votre module et au port 6638, celui renseigné dans la partie stream_server du code ESPHome.

Conclusion

Pour quelques dizaines d'euros et un câble réseau, on déporte un réseau Zigbee complet là où on veut. Difficile de faire plus simple, et trois ans plus tard je n'ai toujours rien à lui reprocher.