(de retour après quelques années où j’étais surtout focalisé sur la partie Linux de ma domotique )
J’envisage de refaire l’automatisation de mon poulailler (j’ai fait un RetEx dans la section “projet fini”). Plutôt que d'utiliser le WiFi qui tire trop sur la batterie, j’envisage de passer par du LoRa ce qui m’amène les questions suivantes :
La communication devrait se faire entre un ESP32 dans le poulailler et un SBC sous Linux côté maison : quel serait la meilleure solution côté maison,
ajouter un adaptateur LoRa sur mon SBC (I2C/SPI et GPIO dispo) et le contrôler depuis Linux ? Si oui, auriez-vous des conseils ?
utiliser un second ESP32 et l’utilise en pont WiFi ou Ethernet ?
Et Quelle que soit la solution, est-ce que l’ont peu faire passer du MQTT par dessus le LoRa ?
Si votre SBC dispose de broches GPIO ou d’un port SPI ou I2C libre, ajouter un module LoRa (eg un SX1276) directement dessus est une solution simple / efficace. Linux peut le piloter via un driver SPI ou une interface série, à l’aide d’un petit programme en C ou en Python utilisant une bibliothèque LoRa. C’est la méthode la plus directe et la plus économe en énergie.
Utiliser un second ESP32 comme passerelle LoRa–WiFi ou LoRa–Ethernet est une alternative plus flexible. Cela décharge votre SBC de la gestion des échanges radio et rend la passerelle indépendante, ce qui facilite les mises à jour ou les modifications ultérieures. A vous de définir ensuite comment cette passerelle centrale communiquera avec votre SBC (série, ...)
Pour MQTT, ce ne sera pas direct. Il vaut mieux adapter le payload LoRa à ce que vous souhaitez réellement transmettre, en envoyant uniquement les données brutes sous une forme compacte. La partie centralisée, sur le SBC ou le serveur, se chargera ensuite de reconstruire le message et de le publier en MQTT - n'oubliez pas les débits faibles et la latence du LoRa qui limitent cette approche à des messages courts (moins de 200 octets) et peu fréquents car en Europe, les communications LoRa utilisent la bande libre 868 MHz, soumise à une limite de 1 % de duty cycle ➜ Cela signifie qu’un émetteur ne peut transmettre que 36 secondes par heure sur une même fréquence.
Le temps d’émission dépend de ce qu'on appelle le spreading factor (SF), de la bande passante. À titre d’ordre de grandeur :
– Pour un SF de 7 et une BP de 125 kHz, l’envoi de 200 octets dure environ 0,5 seconde.
– Pour un SF de 12 et une BP de 125 kHz, la même trame prend environ 6 à 7 secondes.
Comme le spreading factor augmente la portée mais réduit le débit, il faut choisir un compromis entre distance et temps d’émission pour rester dans la limite légale du duty cycle.
➜ Le choix dépend de la portée, du débit nécessaire et de la complexité que vous souhaitez gérer.
Cela décharge votre SBC de la gestion des échanges radio
Malgré son grand age et qu’il fasse tourner toute la domotique de la maison (y compris un BDD et un site web), je n’y ai pas de problème de ressource.
Pour MQTT, ce ne sera pas direct
Arg, si je fais ça, je risque de n’avoir que des échanges dans un sens : impossible d’envoyer des commandes à la sonde vu qu’on ne sait pas par avance quand elle sera réveillée. Avec le MQTT, elles restent dans en attente dans le broker jusqu’au réveil de la sonde.
Je n’étais pas au courant pour ces limitations de duty cycle : comment ça se passe du coup pour les répéteurs de LoRaWan ?
Les répéteurs LoRaWAN doivent respecter le duty cycle de chaque canal utilisé, chaque transmission comptant dans la limite légale, sans exemption.
Concrètement, un répéteur doit inclure le temps d’émission de chaque message dans son duty cycle sur la fréquence utilisée, et pour respecter les limites légales, les implémentations répartissent les transmissions sur différents canaux uplink/downlink, privilégient des messages courts et peu fréquents, ou peuvent utiliser des "astuces" comme l’Adaptive Data Rate pour ajuster puissance et débit.
il existe le protocole MQTT-SN qui permet plus où moins de faire du MQTT sur du LoRa. Ce qui m’intéresserait ici serait d’utiliser le “retain” du MQTT pour envoyer des commandes au réveil des sondes … pas supporté.
cependant le MQTT-SN offre les “tags” ASLEEP (la sonde s’endore) et AWAKE (elle est de retour) qui permettraient de simuler le retain mais à faire à la main.
Enfin, s’il est de facto plus lourd que d’envoyer des trames directes, le MQTT-SN a l’avantage de fonctionner Quelle que soit la couche de com : LoRa mais aussi Zigbee par exemple.
peut-être un HC-12 serait plus adapté. la porté peut être assez grande et il y a quatre modes de fonctionnement sélectionnables via commandes AT :
➜ FU1 : mode basse consommation (80 µA en veille)
➜FU2 : mode ultra-basse consommation (3,6 mA en veille)
➜FU3 : mode usage général (mode par défaut)
➜FU4 : mode longue portée (jusqu’à 1 km)
vous vous mettez en mode FU1 et vous endormez votre ESP32. ça ne consomme pas grand chose et quand un message arrive depuis le central, la ligne Tx envoie l'info et si vous avez câblez cette ligne sur une pin qui écoute les interruptions, ça réveille votre ESP. (je ne l'ai pas fait avec un ESP mais une Arduino Nano de base)
c'est une communication série dans la bande des 433 MHz donc vous n'avez pas de duty cycle obligatoire (Il faut quand même respecter la puissance maximale autorisée).
PS/ j'oublierais le MQTT entre le poulailler et le central
Peux tu en dire plus sur la méthode utilisée ? Tout ce que je lis sur MQTT-SN mention UDP, ce qui élimine LoRa.
les communications LoRa utilisent la bande libre 868 MHz
Pas forcément on utilise aussi pour LoRa 433MHz avec les puces SX1278 (contrairement à LoRaWAN qui en Europe tourne actuellement exclusivement sur 868MHz)
LoRa sur 433MHz peut être un bon choix en alternative longue portée aux HC-12 sur la même bande de fréquences à puissance d’émission identique (le surplus de portée découlant de la plus grande sensibilité des récepteurs)
Si votre SBC dispose de broches GPIO ou d’un port SPI ou I2C libre, ajouter un module LoRa (eg un SX1276) directement dessus est une solution simple / efficace
SPI oui, I2C je doute mais pour le reste je pense que c’est une bonne solution y ajoutant le SX1278 si 433MHz est la bande choisie en alternative à 868 MHz
Merci pour le lien où MQTT-SN est combiné à LoRa dans des trames LoRa ‘hybrides’ si je comprend bien….
la carte que tu indiques dans ton 3e lien ( carte Heltec) combine un ESP32 et un SX1262
(les SX 1262, SX1268… se gèrent différement des SX1276 et SX1278 au niveau des registres, bibilothèque ou driver spécifique)
)