ZLinky LoRa — quand le Linky est en bord de route de la maison

Si vous avez fait construire ces dernières années, ou si vous habitez dans un lotissement récent, vous le savez peut-être : Enedis n’installe plus systématiquement le compteur Linky chez vous. De plus en plus souvent, il termine sa course dans un coffret normalisé en bord de route à l’entrée du terrain. Parfois c’est 20 m, parfois 50, parfois 150 m !

Cette pratique facilite les relevés et la maintenance pour Enedis. Mais elle pose un vrai problème à ceux qui voudraient profiter du Linky pour suivre leur consommation en temps réel : les solutions habituelles ne portent pas jusque-là.

C’est exactement le problème que nous essayons de résoudre avec une nouvelle version du ZLinky, celle qui parle en LoRa 2.4 GHz. Spoiler : on vient d’atteindre 200 m de portée en milieu semi-urbain, à travers murs et obstacles, et le module fonctionne sans pile, sans alim externe, alimenté uniquement par la TIC du compteur.

Cet article fait le point sur le projet : pourquoi cette techno, ce qu’on a dû modifier, les premiers résultats et sur le défi de la passerelle.

 

1. Le contexte : le Linky qui s’éloigne

Le ZLinky actuel (en Zigbee 3.0) marche très bien. Branché sur la TIC du compteur, il rend les données Linky exploitables dans Jeedom, Home Assistant, Domoticz, ou n’importe quelle box Zigbee compatible. À condition que le coordinator Zigbee soit dans le périmètre du compteur.

Or, le Zigbee, c’est une portée typique de :

• 10-20 m en intérieur avec deux ou trois murs entre le device et la box ;
• 30-50 m en extérieur ligne directe ;
• Au-delà : il faut des routeurs Zigbee alimentés sur le trajet pour faire « pont » ou utiliser une rallonge SMA avec une antenne à fort gain.

Quand le compteur est en bord de route, à 60 ou 100 m du salon, le Zigbee n’est plus vraiment viable tout simplement. Le mesh ne peut pas étendre la portée s’il n’y a rien à mailler : pas de prises électriques entre la rue et la maison, pas de répéteur possible. Le ZLinky devient inutilisable, et c’est rageant parce que toute l’infrastructure logicielle existe déjà.

On nous remonte le cas régulièrement, surtout depuis la généralisation du Linky dans les constructions neuves. Il fallait une alternative.

---

2. Pourquoi pas le LoRa 868 MHz, le « vrai » LoRa ?

Quand on dit « LoRa » dans le monde IoT, on pense d’abord à LoRaWAN 868 MHz (en Europe). C’est la techno utilisée par les compteurs d’eau communicants, les capteurs agricoles, les trackers GPS. Portée fantastique (plusieurs km en zone dégagée), consommation minuscule. Le candidat idéal, sur le papier.

Sauf que le 868 MHz a un défaut rédhibitoire pour notre usage : le duty cycle réglementaire de 1 %.

Concrètement, en bande SRD 868 MHz, l’ETSI impose qu’un appareil ne transmette pas plus d’1 % du temps — soit 36 secondes maximum par heure. C’est une règle protégeant le partage du spectre.

Faisons le calcul pour le ZLinky :

• Une trame essentielle (puissance, mode, alertes) fait ~17 octets utiles
• À SF9 BW125 (typique 868), c’est environ 80 ms en l’air
• Si on transmet toutes les 2 secondes : 1800 trames par heure × 80 ms = 144 secondes / heure
• → Quatre fois au-dessus du quota légal

On pourrait descendre à une trame toutes les 8 secondes pour tenir le 1 %. Mais on perd le quasi-temps-réel, et on n’aurait même plus la place d’envoyer les trames étendues (index énergie par tarif, courants, tensions par phase, puissances max du jour, etc.) qu’on diffuse aujourd’hui en complément. Sans parler de la mise à jour OTA : envoyer ~200 ko de firmware en 1 % du temps prendrait plusieurs jours.

Bref, le 868 MHz est inadapté au use case du ZLinky qui veut remonter beaucoup et souvent. Voici un diagramme de décision expliquant le choix de la technologie selon contraintes.

---

3. Le LoRa 2.4 GHz, la techno qu’on ne connaît pas (encore)

Comme on vient de le voir. La plupart des gens confondent. Le LoRa, ce n’est pas qu’une bande de fréquence : c’est avant tout une modulation (Chirp Spread Spectrum) qui peut s’utiliser sur plusieurs bandes. Semtech, l’inventeur, propose le SX1280 depuis quelques années — un transceiver LoRa qui fonctionne dans la bande ISM 2.4 GHz. La même bande que le Wi-Fi, le Bluetooth, le Zigbee. Et surtout : sans restriction de duty cycle dans la plupart des pays.

Quels sont les avantages de cette bande pour notre projet ?

✅ Transmission libre

Pas de quota 1 %. On peut envoyer des trames toutes les secondes, voire en continu pour une OTA, sans enfreindre quoi que ce soit. C’est LE point critique pour le ZLinky en temps réel.

✅ Module compact

Les modules SX1280 du marché tiennent dans 13 × 14 mm, antenne PCB intégrée possible, antenne externe en option si on veut maximiser la portée.

✅ Disponibilité mondiale

La bande 2.4 GHz est libre partout sur Terre. Un seul produit pour tous les marchés, contrairement aux versions 868/915/923 du 868 MHz. Pour le moment, pas forcément utile pour le ZLinky mais pensez aux autres produits LiXee …

✅ Coût

Le SX1280 brut tourne autour de 3 €. Le module complet (TCXO + matching + antenne) à 6-8 €. Beaucoup moins cher qu’un module 868 certifié.

✅ Sensibilité largement suffisante

À SF11 BW406 (notre config par défaut), le SX1280 a une sensibilité d’environ -129 dBm. C’est un budget de liaison de plus de 140 dB entre TX à +10 dBm et RX, ce qui couvre largement quelques centaines de mètres en environnement réel.

❌ Mais le 2.4 GHz a aussi ses défauts

• Bande très polluée : Wi-Fi domestique, Bluetooth, micro-ondes, voisin qui regarde Netflix… Tout le monde tape là-dedans. Les CRC errors arrivent plus souvent qu’en 868 MHz.
• Atténuation par les obstacles plus forte : pour la même distance, le 2.4 GHz traverse moins bien le béton ou la pluie épaisse qu’un signal 868 MHz.
• Multipath plus présent : les réflexions sur les murs métalliques, les voitures, les structures urbaines, créent des évanouissements (fading) qu’il faut accepter.
• Nombre d’appareils Limités. La modulation LoRa impose une émission longue et le récepteur à canal unique impose un nombre restreint d’appareil LoRa sur un son canal (max 3-4). Bref, on se marche un peu sur les pieds

Pourquoi ces inconvénients ne posent pas (trop) de problème au ZLinky ?

Parce que le compteur est presque toujours en extérieur. Dans un coffret en façade en bord de route, le ZLinky a une vue « dégagée » vers la maison. C’est exactement la situation où le 2.4 GHz brille – peu d’obstacles, surtout pas le pire (béton armé épais). En intérieur le 868 aurait peut-être un léger avantage, mais en extérieur les deux se valent à 200 m, et le 2.4Ghz nous donne le duty cycle libre en bonus.

Pour la pollution radio : avec une modulation spread-spectrum LoRa à SF11, on récupère ~17 dB de gain de processus. Autrement dit, on décode des signaux enfouis sous le bruit WiFi. De plus, il est possible de jouer avec les canaux pour éviter les collisions. Aussi, nous n’avons pas besoin de faire plusieurs kilomètres. plusieurs centaines de mètres sont largement suffisants.

En pratique, on observe 90-95 % de paquets reçus correctement avec deux ZLinky qui transmettent en même temps et un WiFi voisin actif. C’est largement suffisant pour du suivi de consommation.

On ne pourra pas gérer plus de 2-3 appareils LoRa longues distances sur un seul canal LoRa mais ce sera suffisant, pour 1x Linky, 1x Compteur Gaz et 1x Compteur d’eau par exemple.

 

---

4. Ce qu’on a dû modifier sur le ZLinky

Le ZLinky d’origine est construit autour du JN5189 de NXP (Cortex-M4 avec radio Zigbee 2.4 GHz intégrée). Pour ajouter le LoRa, plusieurs choix.

Côté hardware

Le JN5189 a une radio Zigbee, pas une radio LoRa. On ne peut pas faire les deux avec la même radio : Zigbee et LoRa partagent la bande 2.4 GHz mais utilisent des modulations totalement différentes (Zigbee = O-QPSK, LoRa = CSS chirp). Il faut donc ajouter physiquement un transceiver SX1280.

Pour le premier prototype, on a ajouté :

• Un module NiceRF LORA1280-TCXO (SX1280 + TCXO 0.5 ppm + matching antenne, tout pré-fait)
• Une liaison SPI 1 MHz vers le JN5189 (4 fils + NSS)
• Trois GPIO en plus : RESET, BUSY, DIO1
• L’alimentation TCXO directement sur 3.3 V (le TCXO doit être toujours alimenté pour que la radio fonctionne)
• Changement d’un condensateur 680uF à la place de 100uF

Pas de modification du circuit d’alim TIC : on tient toujours dans les 130 mW max que fournit le Linky par la téléinfo. C’était une contrainte forte, et on est passé à un poil d’épaisseur.

Côté firmware

Là le travail a été important. Le firmware Zigbee d’origine a été dérivé en deux versions distinctes :

• Firmware Zigbee classique : inchangé fonctionnellement, pour ceux dont le compteur est proche.
• Firmware LoRa : Zigbee complètement désactivé, pile LoRa custom à la place, pour les cas bord-de-route.

Le passage de Zigbee à LoRa a libéré ~50 ko de flash, qu’on a pu réinvestir dans :

• Le driver SX1280 + HAL SPI (~10 ko)
• Un module crypto AES-128-CTR pour la confidentialité + CMAC tronqué 2 octets pour l’authentification (~8 ko, sans la SecLib du SDK NXP qu’on réutilise)
• Un module de pairing simplifié à un appui long sur le bouton (génération de clé partagée 128 bits, stockage PDM)
• Le parsing TIC complet (essential + 7 sous-types extended)
• Un module OTA over-the-air (mise à jour du firmware lui-même sur la liaison LoRa)
• Un support multi-canal : 8 canaux ISM (2400-2480 MHz, 10 MHz d’écart) sélectionnables, pour cohabiter avec le WiFi de la maison sans se marcher dessus

À l’arrivée, le binaire final fait ~197 ko. On a même de la marge pour quelques fonctions futures.

---

5. Les premiers résultats

Avec un proto câblé un peu à l’arrache, alim TIC, antenne PCB du module NiceRF, et un récepteur basé sur un STM32 + SX1280 sur breadboard, on a tapé 200 m de portée stables dans un quartier pavillonnaire (semi-urbain donc, avec maisons et voitures entre les deux). RSSI à -99 dBm, SNR à -9 , 95 % de paquets bien reçus.

L’émetteur

Le récepteur de test

Ce qui remonte côté box :

🔄 Toutes les secondes — paquet « essentiel » (17 octets, ~250 ms en l’air à SF11) :

• Puissances instantanées (SINSTS, SINST1, SINST2, SINST3, SINSTI)
• Mode du compteur (mono/tri, historique/standard)
• État & alertes (mot STGE : dépassement de seuil ADPS, état des contacts secs, sens du flux énergie, etc.)

🔁 En cycle complémentaire — paquets « étendus », 7 sous-types qui tournent en round-robin toutes les ~20 secondes :

1. Courants & tensions par phase (IRMS1/2/3, URMS1/2/3)
2. Index énergie principaux : EAST (total soutiré), EAIT (injection photovoltaïque), index tarifs 1 et 2
3. Index tarifs 3 à 6 (le full set pour les contrats multi-tarifs)
4. Statistiques : tensions moyennes UMOY, courants max IMAX
5. Puissances maximales du jour : SMAXSN soutirée, SMAXIN injectée, instantané injection, courbe de charge, config relais et tarification
6. Énergies journalières par tarif
7. Pointe mobile : début/fin de chaque période

En clair : toutes les données du Linky standard arrivent, juste un peu lissées dans le temps. Pour 99 % des usages domotiques, c’est largement assez réactif.

🔧 Bonus : mise à jour OTA over-LoRa. Quand un nouveau firmware est dispo, on n’a pas besoin de démonter le ZLinky : on le met en mode « recovery » via un appui long au boot (ça peut changer dans le futur), et le firmware part en LoRa depuis la box. Comptez 1 h pour ~200 ko de firmware à SF11 — pas rapide, mais c’est sans intervention physique sur le produit.

---

6. La première version intégrée

La première prod est validée et montée dans le boitier original du ZLinky Zigbee. Elle tourne, l’OTA fonctionne. Mais le projet n’est pas terminé. Il reste à :

• Tests longue durée : on a 7 jours de roulage sans crash, mais il faut valider sur des semaines avec plusieurs ZLinky en parallèle.
• Certification CE / RED pour la commercialisation européenne.

---

7. Le récepteur : et la Lixee-Box dans tout ça ?

Côté réception, une bonne nouvelle : on ne part pas d’une feuille blanche. La Lixee-Box existe déjà depuis un moment dans sa version Lite (le pack ZiWiFi32 Lite + ZLinky_TIC v2, vendu autour de 92 €) et elle fait déjà très bien plusieurs choses qui nous intéressent :

• elle embarque un ESP32-S3 avec WiFi 2.4 GHz et Bluetooth LE,
• elle joue le rôle de coordinator Zigbee 3.0 grâce à la ZiGate intégrée,
• elle expose toutes les données en MQTT avec auto-discovery Home Assistant, donc elle est immédiatement compatible avec Jeedom, Domoticz, Node-RED, openHAB, etc.,
• elle est open source, alimentée en USB-A 5V (<2 W), 100 % locale sans dépendance cloud,
• et elle accueille déjà des extensions comme le ZiPulses (eau, gaz) et pleins d’autres appareils zigbee via une mécanique de templates JSON.

Bref, toute l’infrastructure logicielle de passerelle MQTT + intégration domotique est déjà rodée. La question n’est donc pas « faut-il créer une box ? », mais plutôt « comment ajouter proprement la réception LoRa 2.4 GHz à l’écosystème LiXee-Box ?« . Et la réponse n’est pas évidente.

La bonne surprise : la Lite peut accueillir le LoRa

En regardant de près le hardware de la ZiWiFi32 Lite, on s’aperçoit qu’il y a des GPIO disponibles sur la carte, prévus précisément pour ce genre d’extension. Et l’ESP32-S3, avec ses deux cœurs cadencés à 240 MHz, son PSRAM et ses SPI matériels, a largement la marge pour gérer en plus du Zigbee/WiFi/BT le pilotage d’un module SX1280 et le décodage des trames LoRa toutes les 2 secondes. Le décryptage AES-CTR + vérification CMAC ne représente que quelques dizaines de microsecondes par trame, et le parsing TIC est trivial à côté du stack Zigbee qui tourne déjà en permanence.

Concrètement, un module SX1280 vient se brancher sur les GPIO disponibles (SPI + quelques broches GPIO pour RESET, BUSY et DIO1), et le firmware ZiWiFi32 s’étend pour gérer ce nouveau périphérique en parallèle du reste. La cohabitation des trois radios 2.4 GHz (WiFi, Zigbee, LoRa) demande un peu d’attention sur le timing et l’isolation antenne, mais c’est un problème qu’on sait gérer. L’ESP32 fait déjà cohabiter WiFi et Zigbee/BT au quotidien dans la Lite.

Bref, la Lite va pouvoir évoluer pour supporter le LoRa, et c’était au fond la vocation des GPIO laissés libres : permettre cette extension naturelle de l’écosystème.

Une version Pro ?

Si la Lite peut déjà faire WiFi + Zigbee + LoRa, on pourrait se demander s’il est intéressant de développer « LiXee-Box Pro ». La réponse est OUI, c’est : passer du module compact à la vraie box, avec ce qui va avec en termes de connectique et de fiabilité.

L’ajout phare : un port Ethernet RJ45. C’est le différenciateur qu’on attendait pour adresser le marché pro et semi-pro. Le WiFi de la Lite est très bien pour un usage domestique, mais dès qu’on parle de bailleurs sociaux, de syndics, de petites entreprises, d’intégrateurs, de copropriétés ou même de power users domotiques sérieux, on entend toujours la même chose : « il me faut du filaire ». Le filaire, c’est la stabilité de la connexion, l’absence de coupure liée à un changement de mot de passe WiFi, l’isolation réseau (VLAN), la PoE éventuelle, et la sécurité d’avoir une infra qui ne plante pas parce que le voisin a allumé son micro-ondes. La Pro embarquera donc une interface Ethernet 10/100 RJ45, qui peut fonctionner seule ou en parallèle du WiFi (basculement automatique, ou bonding selon configuration).

Une « vraie » box, pas un dongle. Là où la Lite a un format compact « stick » pensé pour être discret derrière la box internet ou dans un placard, la Pro adoptera un format boîtier classique : châssis plus généreux, finition pro, façade avec LEDs de statut par fonction (alim, WiFi, Ethernet, Zigbee, LoRa). Bouton d’appairage et bouton reset en façade. Boîtier compatible montage mural ou DIN-rail en option, pour les installations en tableau électrique ou en local technique.

La grosse différence technique : plusieurs SX1280 pour le multi-canal. C’est sans doute le point le plus structurant. On l’a expliqué plus haut : le SX1280 est mono-canal, il n’écoute qu’une seule fréquence à la fois. Sur la Lite (un seul SX1280), tous les ZLinky LoRa appairés doivent donc partager le même canal — et plus on ajoute d’appareils, plus les collisions radio augmentent (on l’a constaté nettement en test dès qu’on dépassait deux ou trois émetteurs sur le même canal). La Pro adoptera plusieurs SX1280 en parallèle (2, 3 voire 4 selon la version), chacun calé sur un canal différent. Conséquences directes :

• Beaucoup plus d’appareils LoRa gérés simultanément : on répartit la flotte de ZLinky sur plusieurs canaux au lieu d’un seul, ce qui divise mécaniquement le taux de collision.
• Réception réellement parallèle : pendant qu’un SX1280 reçoit un ZLinky sur le canal 1, un autre reçoit un ZLinky sur le canal 4 — au lieu de tout sérialiser sur une seule radio.
• Résilience : si un canal est pollué par le WiFi de la maison à un instant donné, les ZLinky des autres canaux continuent de passer sans être impactés.

C’est ce qui fait passer la box d’un usage « quelques compteurs d’une maison » à un usage « tout un lotissement ou un immeuble », là où une seule radio mono-canal sature vite.

Plus de place physique sur la carte. Une carte mère plus grande permet aussi de mieux séparer les antennes des radios 2.4 GHz (WiFi, Zigbee, et les multiples SX1280), et donc d’améliorer leur cohabitation. Connecteurs SMA externes optionnels pour antennes LoRa amplifiées dans les configurations difficiles.

L’idée n’est donc pas d’opposer Lite et Pro, mais de proposer deux niveaux de gamme cohérents :

• La Lite reste l’entrée de gamme accessible pour la majorité des utilisateurs domestiques : compact, alimentée USB, WiFi suffisant, avec maintenant en plus le support LoRa pour ceux qui en ont besoin.
• La Pro vise un cran au-dessus avec un vrai format box, Ethernet RJ45, meilleure capacité LoRa, pour les configurations exigeantes : bailleurs, syndics, intégrateurs, petites entreprises, power users domotiques.

Quel que soit le modèle : deux profils d’utilisateurs, un même produit

Que ce soit la Lite mise à jour ou la Pro, le principe d’usage reste le même, et c’est ce qui fait la force du positionnement LiXee. La box doit pouvoir servir deux profils d’utilisateurs très différents, sans option commerciale, sans configuration compliquée :

1. Les utilisateurs qui ont déjà une box domotique (Home Assistant, Jeedom, Domoticz, etc.). Pour eux, la LiXee-Box joue le rôle de passerelle MQTT pure. Elle expose ses topics sur le réseau local, et la box principale consomme les données. Avec l’auto-discovery Home Assistant déjà standardisé chez LiXee, les capteurs ZLinky LoRa apparaissent automatiquement dans HA sans configuration manuelle. Exactement comme le font déjà aujourd’hui les capteurs Zigbee de la Lite.
2. Les utilisateurs qui n’ont pas (encore) de box domotique : ceux qui veulent juste suivre leur conso Linky depuis leur smartphone, sans monter une infra Raspberry Pi maison, sans installer Home Assistant. Pour eux, la LiXee-Box est leur box domotique. Elle embarque un frontend web local, accessible via le réseau, avec dashboard temps réel, historique, graphes, alertes push.

Les deux modes tournent en permanence, en parallèle. Pas de switch à activer, pas de mode expert. L’utilisateur consomme ce qu’il veut, comme il veut. Et il peut basculer dans le temps : commencer sans box, découvrir la domotique grâce à l’interface LiXee, puis brancher plus tard un Home Assistant qui héritera des données via MQTT sans rien casser.

Un peu d’état du marché

Avant de se lancer, on a regardé ce qui existe en face. Verdict : quasiment rien, en tout cas dans le grand public.

Le LoRa 868 MHz est ultra-mature côté infrastructure : on trouve des gateways à tous les prix (RAKwireless, Kerlink, MultiTech, MikroTik, Dragino…), avec des concentrators qui écoutent 8 canaux simultanément et des stacks LoRaWAN éprouvées.

Le LoRa 2.4 GHz, lui, est un quasi-désert. Plusieurs raisons :

• Le SX1280 et son cousin LR1121 sont mono-canaux : pas d’équivalent du SX1302 pour écouter 8 fréquences en parallèle. Ça refroidit les constructeurs industriels.
• La bande 2.4 GHz est mentalement associée au WiFi/Bluetooth grand public, pas au LPWAN — l’image « longue portée » du LoRa s’est imposée sur le 868 MHz dans la tête des intégrateurs.
• LoRaWAN 2.4 GHz existe formellement, mais le déploiement reste confidentiel.

Stack logicielle et continuité avec la Lite

Le bon côté de cette approche, c’est que le firmware existant de la Lite est l’ossature de base pour les deux modèles. On part de ce qui tourne déjà depuis des mois en production chez les utilisateurs, et on l’étend avec un nouveau module radio.

Concrètement, l’ajout consiste à intégrer :

• Un pilote SX1280 en SPI côté firmware (capture continue sur le canal configuré).
• Le module crypto AES-128-CTR + CMAC déjà développé pour le ZLinky LoRa, simplement porté côté receiver.
• Le parsing TIC des trames essential + extended, qui n’est pas très différent de ce que fait déjà la Lite pour le ZLinky Zigbee — on traite la même donnée TIC, juste arrivée par un autre canal radio.
• L’enrichissement de l’auto-discovery MQTT pour publier aussi les capteurs ZLinky LoRa (avec leur MAC, RSSI, SNR, canal LoRa, etc.).
• L’extension du frontend web local avec les vues spécifiques LoRa : statut radio par ZLinky, diagnostic RSSI/SNR, pairing par QR code, OTA assisté depuis l’interface.

L’approche modulaire de la stack LiXee (les templates JSON pour la compatibilité device) facilite cette extension : on ajoute un nouveau type de device « ZLinky LoRa » dans la mécanique existante, sans tout réécrire.

---

8. Ce qu’il nous reste à faire côté récepteur (et notre roadmap)

Pour donner une idée concrète, voici le plan de marche actuel :

• Extension du firmware ZiWiFi32 pour piloter le SX1280 ajouté sur GPIO
• Validation du module LoRa add-on sur la Lite (réception + bridge MQTT + auto-discovery HA)
• Conception de la version Pro : format vraie box, Ethernet RJ45 + WiFi, LEDs de façade, meilleure isolation antennes 3 radios, option boîtier DIN-rail
• Frontend web étendu avec les vues spécifiques LoRa (RSSI, SNR, OTA assisté, pairing QR)
• Certification, manuel, packaging des deux modèles
• Logistique commerciale (gamme cohérente Lite + module LoRa optionnel / Pro tout intégré filaire)

Si tout se passe comme prévu, on vise une version early access pour la fin d’année auprès des early adopters intéressés, avec un produit grand public stabilisé dans la foulée. Comme aujourd’hui avec la Lite, le firmware restera open source : vous pourrez l’auditer, le forker, monter votre propre récepteur DIY si vous ne voulez pas attendre la box officielle.

---

9. Conclusion : un écosystème qui s’élargit

Ce qui a commencé comme une simple réponse à un problème ponctuel : « comment relever un Linky qui est trop loin pour le Zigbee ? » est en train de se transformer en un véritable élargissement de l’écosystème LiXee.

D’un côté, l’émetteur ZLinky LoRa s’apprête à rejoindre la gamme aux côtés du ZLinky Zigbee historique : même boîtier, même alim TIC, juste une techno radio adaptée aux configurations longue distance.

De l’autre, la LiXee-Box évolue naturellement pour accueillir le LoRa : la Lite existante pourra recevoir un module LoRa optionnel (les GPIO sont prévus pour ça depuis le départ), et une nouvelle déclinaison Pro viendra compléter la gamme avec un vrai format box, port Ethernet RJ45, écran de statut et finition adaptée aux usages semi-pro — pour ceux qui veulent une infrastructure plus solide, du filaire, et la cohabitation confortable des trois radios 2.4 GHz dans le même équipement.

Sur le marché, le terrain est libre. Aucun acteur grand public ne propose aujourd’hui de gateway LoRa 2.4 GHz packagée et orientée domotique. LiXee a une vraie carte à jouer sur ce créneau, en s’appuyant sur tout ce qui a déjà été construit autour de la Lite : firmware open source, intégrations domotiques rodées, communauté d’utilisateurs active.

La suite, c’est de finir le développement et de la mettre dans les mains des early adopters. On vous tient au courant à chaque étape.

À bientôt 👋