Zigbee et LoRaWAN répondent à des besoins radio différents. Zigbee transporte des lectures fréquentes de nombreux appareils rapprochés dans un bâtiment. LoRaWAN transporte quelques petites lectures par heure d’appareils répartis sur une grande surface. De nombreux sites énergétiques utilisent les deux : sous-comptage dense dans les tableaux de distribution et quelques compteurs de gaz, d’eau ou de niveau de cuve éloignés de l’alimentation et du réseau.
Dans un système EpiSensor, les appareils Zigbee rejoignent le maillage du Gateway ZGW-20, et Edge sur ce Gateway conserve leurs lectures. Les appareils LoRaWAN transmettent à une passerelle et à un serveur réseau LoRaWAN. Ce serveur décode chaque message montant et transmet les lectures à Edge par MQTT ou HTTPS. Edge rassemble ensuite les deux ensembles de lectures dans un même modèle de données. Il ne remplace pas le serveur réseau.
Choisir selon les besoins
| Besoin du projet | Point de départ | Vérification |
|---|---|---|
| Lectures de quelques secondes à quelques minutes sur de nombreux points d’un bâtiment | Maillage Zigbee | Placement des routeurs, plan des canaux Wi-Fi, nombre d’appareils par Gateway |
| Quelques lectures par heure d’appareils sur batterie dispersés | LoRaWAN | Couverture étudiée, facteur d’étalement à l’emplacement réel du compteur, temps d’émission et autonomie |
| Les deux cas sur un même site | Deux réseaux | Responsable du serveur réseau, horodatage conservé par chaque lecture et alignement des deux résolutions |
| Pilotage d’un équipement avec délai de réponse imposé | Aucun par défaut | Latence de bout en bout, état après perte d’un message et protections propres à l’équipement |
Un protocole sans fil n’est pas une fonction de sécurité. Définissez avec le fournisseur l’état sûr de l’équipement piloté, quelle que soit la radio utilisée pour la commande.
Zigbee sur le site
Zigbee fonctionne avec IEEE 802.15.4 à 2,4 GHz. La bande comporte 16 canaux numérotés de 11 à 26, dont les fréquences centrales sont séparées de 5 MHz entre 2 405 et 2 480 MHz. Le débit radio est de 250 kbit/s ; une trame ne dépasse pas 127 octets, en-têtes compris.
Le réseau a un coordinateur unique, le ZGW-20 dans un système EpiSensor. Les routeurs relaient les trames d’autres appareils. Les terminaux émettent et reçoivent uniquement par un routeur parent. Un terminal en veille se réveille, interroge son parent pour récupérer les messages gardés, puis se rendort. Un appareil alimenté sur secteur n’est pas nécessairement un routeur : vérifiez son type dans la fiche technique (voir les types de nœuds définis par Silicon Labs). Tous les appareils EpiSensor alimentés sur secteur relaient. Chacun atteint jusqu’à 50 m en intérieur et 300 m en extérieur et ajoute en moyenne environ 1 000 m² de couverture dans un bâtiment commercial. Un ZGW-20 prend en charge jusqu’à 250 appareils et 1 000 capteurs.
Chaque saut retransmet la trame sur le même canal. Une lecture située à trois sauts du Gateway utilise donc trois fois le canal. Une longue chaîne de routeurs dans un couloir sature le canal plus vite qu’un maillage plat avec plusieurs trajets possibles vers le Gateway.
Préparer les canaux face au Wi-Fi
Un canal Wi-Fi de 20 MHz occupe ±10 MHz autour de sa fréquence centrale. Les canaux Wi-Fi 1, 6 et 11 sont centrés à 2 412, 2 437 et 2 462 MHz. Ils couvrent respectivement 2 402 à 2 422, 2 427 à 2 447 et 2 452 à 2 472 MHz et chevauchent les canaux Zigbee 11 à 14, 16 à 19 et 21 à 24. Les canaux Zigbee 15 (2 425 MHz), 20 (2 450 MHz), 25 (2 475 MHz) et 26 (2 480 MHz) se situent dans les espaces restants. Silicon Labs a mesuré que ses radios 802.15.4 supportent un signal Wi-Fi jusqu’à 20 dB plus fort quand les deux fréquences sont éloignées que lorsqu’elles sont adjacentes.
Deux situations invalident ce plan. En Europe, le canal Wi-Fi 13 (2 472 MHz) est autorisé et couvre les canaux Zigbee 25 et 26. Un canal Wi-Fi de 40 MHz occupe deux fois la largeur d’un canal de 20 MHz. Relevez les canaux Wi-Fi utilisés avant de choisir le canal Zigbee et refaites ce relevé lors de l’ajout de points d’accès.
Défaillances Zigbee
- Un routeur est éteint, isolé pour la maintenance ou retiré. Ses terminaux doivent trouver un nouveau parent ; sans autre routeur à portée, ils cessent de transmettre jusqu’à son retour.
- Un appareil se trouve dans une enceinte en acier ou une chaufferie à porte métallique. Sa liaison au routeur voisin devient insuffisante. Placez un routeur hors de l’enceinte ou déplacez l’antenne.
- Un nouveau point d’accès Wi-Fi utilise un canal qui chevauche le canal Zigbee. Les rapports provenant de la périphérie du maillage arrivent en retard ou pas du tout.
Les trois problèmes se voient de la même façon dans les données : la dernière lecture d’un appareil date de plus de deux intervalles de transmission. Déclenchez une alarme pour cette condition, appareil par appareil, dès la mise en service.
LoRaWAN sur le site
LoRaWAN utilise la modulation LoRa dans des bandes inférieures à 1 GHz : 863 à 870 MHz en Europe (EU868) et 902 à 928 MHz en Amérique du Nord (US915). Les appareils ne relaient pas les messages d’autres appareils. Chaque message montant arrive directement à toutes les passerelles LoRaWAN à portée, qui le transmettent à un même serveur réseau. Celui-ci supprime les doublons, vérifie la trame et la transmet à l’application.
Le débit dépend du facteur d’étalement (SF). Un SF plus élevé donne davantage de portée et résiste mieux à l’atténuation, mais chaque incrément double à peu près le temps d’émission. Les paramètres régionaux EU868 fixent les limites suivantes pour les canaux de 125 kHz :
| Débit de données | Facteur d’étalement | Débit binaire | Charge utile applicative maximale |
|---|---|---|---|
| DR0 | SF12 | 250 bit/s | 51 octets |
| DR1 | SF11 | 440 bit/s | 51 octets |
| DR2 | SF10 | 980 bit/s | 51 octets |
| DR3 | SF9 | 1 760 bit/s | 115 octets |
| DR4 | SF8 | 3 125 bit/s | 222 octets |
| DR5 | SF7 | 5 470 bit/s | 222 octets |
Tout appareil EU868 doit utiliser 868,1, 868,3 et 868,5 MHz. Ces trois canaux se situent dans la sous-bande de 868,0 à 868,6 MHz, limitée par ETSI à un rapport cyclique de 1 % pour une puissance de 25 mW ERP. Le réseau public Sandbox de The Things Network ajoute une politique d’usage équitable de 30 s d’émission montante et 10 messages descendants par appareil et par jour. Un serveur réseau privé n’a pas cette limite d’usage équitable, mais reste soumis au rapport cyclique.
La portée dépend de la hauteur des antennes, du relief, des bâtiments et du SF. Une passerelle sur un mât peut joindre des appareils à plusieurs kilomètres en terrain dégagé. À l’intérieur des bâtiments et des sous-sols, prévoyez plutôt des centaines de mètres. Modélisez la couverture, puis testez-la avec un appareil à l’emplacement réel du compteur.
Exemple de temps d’émission
Un compteur envoie une charge utile applicative de 20 octets. LoRaWAN ajoute 13 octets d’en-tête et de contrôle d’intégrité : la radio envoie donc 33 octets. Avec un préambule de 8 symboles, un taux de codage de 4/5 et le CRC activé, le temps d’émission est :
| Facteur d’étalement | Temps d’émission | Intervalle minimal avec rapport cyclique de 1 % | Messages montants par jour en 30 s | Intervalle le plus court avec 30 s par jour |
|---|---|---|---|---|
| SF7 | 72 ms | 7 s | 417 | 3,5 minutes |
| SF9 | 247 ms | 24 s | 121 | 12 minutes |
| SF10 | 453 ms | 45 s | 66 | 22 minutes |
| SF12 | 1 810 ms | 179 s | 16 | 90 minutes |
Un intervalle de 15 minutes donne 96 messages montants par jour. Il respecte la limite d’usage du Sandbox de SF7 à SF9, mais pas à partir de SF10. Un compteur dans un regard de sous-sol qui ne se connecte qu’à SF12 peut transmettre environ toutes les 90 minutes sur le Sandbox. Pour chaque lecture, il consomme aussi environ 25 fois plus d’énergie de transmission qu’à SF7 : l’estimation d’autonomie doit utiliser le SF réellement obtenu.
Explorez le calcul de durée d’un paquet avec la trame radio complète de 33 octets de cet exemple. Modifier le facteur d’étalement change le temps d’émission ; le résultat ne démontre pas la conformité aux règles régionales d’accès au canal ni à une politique d’usage du réseau.
Classes d’appareils et commandes
Les trois classes d’appareils peuvent recevoir des messages descendants. Un appareil de classe A n’écoute que dans deux courtes fenêtres de réception après chacun de ses propres messages montants. Une commande à un compteur de classe A qui transmet chaque heure peut donc attendre jusqu’à une heure. La classe B ajoute des fenêtres de réception programmées par les balises des passerelles. La classe C écoute constamment, sauf pendant ses propres émissions : elle convient aux actionneurs alimentés sur secteur et consomme trop pour la plupart des appareils sur batterie. Aucune classe ne garantit un délai de livraison de bout en bout (voir les classes d’appareils LoRaWAN).
Défaillances LoRaWAN
- Un message montant non confirmé ne reçoit pas d’accusé de réception, mais peut être répété selon NbTrans. LoRaWAN L2 1.0.4 prévoit NbTrans transmissions pour les messages montants confirmés et non confirmés ; les répétitions non confirmées cessent lorsqu’un message descendant valide arrive dans une fenêtre de réception de classe A. Si aucune passerelle ne reçoit aucune transmission, la lecture est perdue. Comptez les répétitions configurées dans les budgets de temps radio et de batterie. Choisissez des appareils qui transmettent un index cumulatif, par exemple des kWh ou des m³ totaux, dans chaque message. Une lecture perdue réduit alors la résolution temporelle, sans perdre l’énergie totale.
- Avec les messages montants confirmés, le serveur réseau envoie une confirmation descendante pour chacun. Un appareil qui confirme une lecture toutes les 15 minutes demande 96 messages descendants par jour, bien au-dessus de la limite Sandbox de 10. Chaque message descendant empêche en outre la passerelle de recevoir pendant son émission. Réservez la confirmation aux lectures dont la perte coûte plus que le temps radio.
- Le débit adaptatif (ADR) réduit le SF quand la marge radio est bonne. Si la liaison se dégrade, l’appareil remonte vers SF12. Un appareil déplacé, ou placé derrière une porte habituellement ouverte, peut finir à SF12 et décharger sa batterie beaucoup plus vite que prévu. Surveillez le SF déclaré par chaque appareil au serveur réseau.
- Un appareil activé par personnalisation (ABP) conserve des clés de session fixes. S’il remet son compteur de trames à 0 après une coupure de courant, le serveur réseau ignore tous les messages dont le compteur reste inférieur à la dernière valeur vue. L’appareil transmet alors normalement, mais rien n’arrive. Préférez l’activation par radio (OTAA), qui établit de nouvelles clés de session et de nouveaux compteurs à chaque association.
- Une passerelle LoRaWAN perd sa liaison amont. Vérifiez si elle conserve les messages montants pendant la coupure. Si elle ne les transmet qu’en direct, les lectures de cette période sont perdues.
Exemples de sites hybrides
Campus avec compteurs éloignés
Un campus universitaire compte 20 bâtiments. Dans chacun, les moniteurs électriques des tableaux de distribution transmettent chaque minute ou plus souvent : c’est un usage Zigbee. Tout bâtiment dépassant 250 appareils, ou sans trajet radio vers ses voisins, reçoit son propre Gateway.
Sur le campus, des compteurs d’eau sont installés dans des regards, des compteurs de gaz en limite de propriété et des stations météo sur les toits. Ils transmettent toutes les 15 à 60 minutes, sans alimentation ni Ethernet à proximité. LoRaWAN leur convient. Positionnez les passerelles LoRaWAN d’après une étude de couverture avec un appareil de test descendu dans le regard le plus profond ; ne supposez pas qu’une seule passerelle en toiture couvre tout le campus.
Portefeuille de plusieurs sites
Un propriétaire suit 50 bâtiments commerciaux. Les grands sites ont chacun un Gateway et un maillage Zigbee pour le suivi par circuit. Les petits sites, tels les parkings et les locaux techniques sans personnel, n’ont besoin que d’un index du compteur principal et d’une température. Sur ces sites, un compteur d’impulsions ou un capteur de température LoRaWAN sur batterie, relié à un serveur réseau existant, évite une visite pour installer un Gateway sur chaque site. Vérifiez d’abord le budget de temps radio si le serveur est public.
Usine et réseaux extérieurs
Une usine agroalimentaire utilise Zigbee pour mesurer la puissance de chaque ligne de production. À l’extérieur, des appareils LoRaWAN lisent le compteur de gaz, celui de l’eau du forage et le niveau de la cuve de fioul. Les deux ensembles de lectures réunis dans Edge donnent une même chronologie pour le gaz, l’eau et l’électricité par équipe, ce qui permet de calculer l’énergie par tonne produite.
Architecture d’intégration
Trajet Zigbee. Appareil Zigbee, coordinateur ZGW-20, Edge sur le Gateway. Edge conserve les lectures localement et continue de fonctionner lorsque la liaison amont est coupée.
Trajet LoRaWAN. Appareil LoRaWAN, passerelle LoRaWAN, serveur réseau avec décodeur de la charge utile de l’appareil, intégration MQTT ou HTTPS, Edge. Le serveur réseau peut être privé ou public et appartenir au site ou à une autre équipe. Convenez du responsable du compte du serveur, des clés des appareils et de la version du décodeur avant de le raccorder. La liste des appareils LoRaWAN et la liste des appareils Zigbee dans l’Annuaire des appareils montrent le trajet de chaque modèle tiers et les lectures documentées.
Un site peut également envoyer les deux flux directement à sa plateforme sans faire passer LoRaWAN par Edge : lectures Zigbee depuis le Gateway et lectures LoRaWAN depuis le serveur réseau. Les mêmes règles d’horodatage et de résolution s’appliquent alors dans la plateforme.
Horodatages
Un rapport d’attribut Zigbee et un message montant LoRaWAN ne portent pas d’heure de mesure au niveau du protocole, sauf si l’appareil l’ajoute à sa charge utile. Le destinataire horodate chaque lecture. Pour Zigbee, c’est le Gateway, situé à un ou quelques sauts de l’appareil. Pour LoRaWAN, le serveur réseau enregistre l’heure de réception du message, que l’intégration peut livrer quelques secondes ou, après une panne, plusieurs heures plus tard. Associez à la lecture l’heure de réception du serveur réseau, et non l’heure de son arrivée dans Edge. Sinon, les données retransmises après une coupure apparaissent toutes au moment du retour de la liaison.
Mises à jour du micrologiciel
Les deux réseaux peuvent mettre à jour le micrologiciel des appareils par radio, à des vitesses très différentes. Le guide OTA compare le cluster OTA Zigbee à FUOTA LoRaWAN et explique la préparation d’une campagne.
Résolutions mixtes
Des lectures Zigbee chaque minute et LoRaWAN toutes les 30 minutes ne s’alignent pas spontanément. Pour la consommation, calculez la différence entre deux index cumulatifs aux bornes de l’intervalle. N’additionnez pas les valeurs ponctuelles de puissance. Pour un rapport à intervalle commun, par exemple 30 minutes, comparez les compteurs uniquement sur cet intervalle. Affichez l’âge de chaque lecture, pour qu’une valeur LoRaWAN vieille d’une heure ne paraisse pas aussi actuelle qu’une valeur Zigbee datant d’une minute.
Sécurité
Zigbee chiffre le trafic réseau avec une clé AES de 128 bits partagée entre les appareils du réseau. Le coordinateur joue le rôle de centre de confiance et transmet la clé réseau à chaque nouvel appareil. Les appareils Zigbee 3.0 doivent prendre en charge les codes d’installation. Un tel code fournit une clé de liaison propre à l’appareil qui protège la clé réseau lors de l’association. Sans lui, la clé réseau est envoyée sous une clé de liaison par défaut connue publiquement : une personne à l’écoute pendant la période d’association peut l’intercepter. N’autorisez les associations que pendant la mise en service et utilisez les codes d’installation lorsque les appareils les acceptent.
LoRaWAN 1.0.x utilise une clé racine AppKey par appareil pour OTAA. Chaque association en déduit une clé de session réseau (NwkSKey), que le serveur réseau utilise pour vérifier l’intégrité des messages, et une clé de session applicative (AppSKey), qui chiffre la charge utile entre appareil et serveur applicatif. LoRaWAN 1.1 sépare la clé racine en NwkKey et AppKey et utilise plusieurs clés de session réseau. Sur un serveur réseau public, l’exploitant peut détenir toutes ces clés. Consignez qui détient chacune et comment renouveler les clés d’un appareil transféré vers un autre serveur.
Protégez la liaison du serveur réseau vers Edge par TLS et des identifiants, comme toute intégration MQTT ou HTTPS. Le guide MQTTS : MQTT sur TLS présente les essais de mise en service.
Vérifications avant déploiement
Menez un pilote dans les emplacements les plus difficiles, et pas seulement auprès d’une passerelle. Convenez des critères de réception avec l’installateur et l’équipe plateforme :
- Consignez pour chaque point l’identité de l’appareil, son micrologiciel, ses unités, son échelle et son intervalle de transmission. Pour LoRaWAN, notez aussi le SF réellement adopté.
- Comparez les valeurs reçues à l’affichage du compteur ou à un instrument de référence. Conservez les index cumulatifs séparément de la consommation calculée.
- Vérifiez que la plateforme représente une lecture manquante comme manquante, et non comme zéro.
- Coupez tour à tour la liaison radio, l’alimentation du Gateway et la liaison amont. Notez quel composant garde les données et quelles lacunes ne peuvent être récupérées.
- Pour les commandes, vérifiez l’état mesuré de l’équipement, pas seulement l’accusé de réception applicatif.
- Transmettez la responsabilité des clés, des comptes du serveur réseau, des appareils de rechange et des contacts d’assistance avant de reproduire l’architecture sur d’autres sites.
Pour poursuivre la conception, consultez le guide du stockage et de l’architecture des données IoT et celui des plateformes de gestion énergétique. Si vous disposez d’un plan de site et d’une liste de points, contactez EpiSensor pour examiner les besoins de mesure et de connectivité.