LoRaWAN est l'une des raisons pour lesquelles je me suis intéressé à l'IoT au départ.

Je me souviens encore du moment où le sans-fil longue portée à faible consommation a vraiment fait sens pour moi. On pouvait prendre un petit capteur alimenté par batterie, le placer loin de toute infrastructure habituelle, et recevoir quand même les données — sans Wi-Fi, sans modem cellulaire dans chaque appareil, et sans tirer des câbles partout.

C'était enthousiasmant. Ça l'est encore.

LoRaWAN a contribué à rendre l'IoT concret. Il a donné aux développeurs, aux villes, aux entreprises et aux makers un moyen de construire de vrais réseaux de capteurs sans infrastructure coûteuse à chaque site. Pour l'agriculture, le comptage, le suivi d'actifs, la supervision de bâtiments, les smart buildings et de nombreux réseaux de capteurs privés, LoRaWAN a beaucoup apporté au secteur.

LoRaWAN est une excellente technologie.

Ce n'est pas pour autant la meilleure technologie pour chaque problème.

Cette nuance compte. LoRaWAN a contribué à créer le marché LPWAN et bénéficie encore d'un écosystème de dispositifs bien plus mature que mioty. Si vous avez besoin de capteurs disponibles immédiatement, il y a tout simplement plus d'appareils LoRaWAN. C'est un vrai avantage, qu'il ne faut pas négliger.

Mais quand la question passe de « quel écosystème est le plus large ? » à « quelle techno est la meilleure pour des déploiements IoT industriels denses et soumis aux interférences ? », la réponse change.

Dans ces environnements, mioty a un avantage technique clair.

Premier arrivé ne veut pas toujours dire meilleur.

À mesure que l'IoT passe du pilote aux déploiements industriels réels, les exigences évoluent. C'est une chose de connecter quelques capteurs à une passerelle et d'afficher des données dans un tableau de bord. C'en est une autre de construire un réseau où des milliers, voire des dizaines de milliers de capteurs doivent remonter de manière fiable dans un environnement radio bruyant, autour de structures métalliques, à l'intérieur de bâtiments, à travers des sites de services publics, dans des cours logistiques ou dans des villes où de nombreux appareils se disputent le même spectre.

C'est là que la comparaison entre mioty et LoRaWAN devient importante.

Toutes deux sont des technologies LPWAN. Toutes deux sont conçues pour de l'IoT longue portée à faible consommation. Mais elles reposent sur des idées très différentes. LoRaWAN envoie des paquets via la couche physique LoRa et gère les appareils à travers des passerelles et des serveurs réseau. mioty utilise Telegram Splitting Multiple Access, ou TSMA, où chaque message est découpé en de nombreuses petites rafales radio envoyées dans le temps et la fréquence.

Cela ressemble à un détail technique, mais ça change le comportement du réseau dans le monde réel.

Capacité mioty vs LoRaWAN : pourquoi le débit fiable de paquets compte plus que les promesses sur le nombre d'appareils

Quand on compare les technologies LPWAN, on demande souvent combien d'appareils une passerelle ou une station de base peut prendre en charge.

C'est une question compréhensible, mais qui peut être trompeuse.

Un appareil qui envoie un message par jour n'a rien à voir avec un appareil qui en envoie un par minute. La vraie limite n'est pas seulement le nombre d'appareils enregistrés. C'est la quantité de trafic que le réseau peut transporter tout en délivrant les messages de façon fiable.

C'est là que mioty commence à se distinguer.

Fraunhofer IIS indique que mioty peut gérer environ 3,5 millions de messages par jour avec une seule station de base. La mioty Alliance positionne aussi mioty comme une technologie pour les réseaux IoT massifs, avec de très grandes flottes de terminaux et un volume quotidien de messages élevé.

On entend parfois cela simplifié sous la forme : « une station de base mioty supporte 160 000 appareils ». Ce chiffre peut faire sens sous un modèle de trafic donné, mais il a besoin de contexte. Si une station de base peut traiter environ 3,5 millions de messages par jour, et que chaque appareil envoie un message par heure, soit 24 par jour, on obtient environ 145 000 appareils émettant à l'heure.

C'est la bonne manière d'y penser.

Pas comme un chiffre magique figé, mais comme une question de capacité.

Si vos appareils émettent rarement, vous pouvez supporter une très grande flotte. S'ils émettent souvent, le chiffre change. Ce qui compte, c'est que mioty offre un budget de trafic bien plus important avant que le réseau ne commence à saturer.

Capacité de la passerelle LoRaWAN vs mioty : pourquoi 44 000 paquets par minute change la conversation

L'une des comparaisons les plus parlantes que j'ai vues vient d'une étude publiée comparant mioty et LoRa. L'étude a montré que mioty peut supporter environ 44 000 paquets par minute dans 1 MHz de bande à un taux de perte de 10 %. LoRa atteignait environ 600 paquets par minute dans un mode moins robuste, et environ 40 paquets par minute dans son mode le plus robuste.

C'est un énorme écart.

Mais il faut le dire correctement. Le chiffre de « 600 » ne désigne pas « 600 appareils ». Il désigne environ 600 paquets par minute sous une configuration LoRa précise. Dans un déploiement LoRaWAN réel, le nombre d'appareils par passerelle dépend de la taille de la charge utile, du facteur d'étalement, du plan de canaux, du duty cycle, des retransmissions, des acquittements, de la densité de passerelles et de la fréquence d'envoi de chaque appareil.

La comparaison reste importante parce qu'elle montre la direction prise par la technologie.

LoRaWAN passe bien à l'échelle quand les messages sont rares et les conditions gérables. mioty a été pensé pour le moment où le réseau devient dense, le trafic augmente et l'interférence fait partie du quotidien.

J'ai vu ce problème personnellement.

Quand je vais à des conférences TTN et à des événements LoRaWAN, je rencontre des gens qui construisent des appareils impressionnants. La créativité de cette communauté est l'une des raisons pour lesquelles LoRaWAN est devenu si important.

Mais j'en vois aussi très clairement les limites.

Dans une salle remplie de passerelles, de capteurs, de démos, et de gens qui essaient de présenter leurs appareils en même temps, l'interférence devient très réelle. Le plus difficile dans la démo n'est parfois pas le matériel. C'est de faire passer le message.

Et c'est tout l'enjeu.

Dans des environnements RF chargés, LoRaWAN souffre. On peut contourner, planifier, réduire le trafic, ajuster les facteurs d'étalement, ajouter des passerelles, concevoir avec soin. Mais le problème de fond demeure : plus la densité et l'interférence augmentent, plus la livraison des paquets devient difficile.

mioty a été conçu exactement pour ce problème.

C'est pour cela que je ne vois pas mioty comme une simple option LPWAN parmi d'autres. Je le vois comme la meilleure technologie pour des déploiements industriels denses où la fiabilité des messages compte.

Alternative à LoRaWAN pour des réseaux de capteurs denses : pourquoi mioty utilise le fractionnement de télégrammes

La différence centrale entre mioty et LoRaWAN, c'est le fractionnement de télégrammes.

Avec une approche classique par paquets, un appareil émet un paquet et le récepteur doit en recevoir suffisamment proprement. Si le paquet est touché par de l'interférence, une collision ou un mauvais signal, le message peut être perdu.

mioty fonctionne autrement.

Il découpe un message en de nombreux sous-paquets, souvent appelés rafales radio. Ces rafales sont émises à différents moments dans le temps et sur différentes fréquences. La station de base n'a pas besoin que chaque rafale arrive parfaitement. Grâce à la correction d'erreurs en aval (forward error correction), le récepteur peut reconstituer le message original même si une part importante des rafales est perdue.

Concrètement, mioty peut reconstruire l'information complète même si jusqu'à la moitié des morceaux du télégramme échouent ou sont mal transmis.

C'est cette partie qui rend mioty enthousiasmant à mes yeux.

Le fractionnement de télégrammes n'est pas qu'une astuce radio. C'est un autre état d'esprit. Il suppose que le monde réel est désordonné. Il suppose qu'il y aura de l'interférence. Il suppose qu'il y aura des collisions. Il suppose que certains morceaux du message peuvent disparaître.

Et il donne quand même au réseau un moyen de récupérer les données.

C'est la différence entre quelque chose qui marche bien en démo et quelque chose qui commence à ressembler à de l'infrastructure.

Meilleur LPWAN pour l'IoT industriel : pourquoi la résistance aux interférences compte plus que les performances en démo

L'interférence n'est pas un cas particulier rare dans l'IoT industriel. Elle fait partie de l'environnement.

Les usines ont des machines, des structures métalliques, des équipements mobiles, du bruit électrique, des murs, des tuyaux, des cuves et toutes sortes de réflexions de signal. Les villes ont des bâtiments, des sous-sols, des armoires techniques, d'autres systèmes sans fil et des populations d'appareils denses. Les cours logistiques ont des conteneurs, des camions, des véhicules, des entrepôts et des dispositions physiques qui changent constamment.

Un petit pilote peut ne pas révéler ces problèmes. Vous installez quelques appareils, placez une passerelle à proximité, obtenez de bonnes lectures et le tableau de bord est superbe. Puis le déploiement grandit. On ajoute des capteurs. Certains sont à l'intérieur. Certains sont derrière du béton. Certains sont près de machines. Certains émettent plus souvent que prévu. D'autres dispositifs sans fil apparaissent dans le même espace.

À ce moment-là, la question n'est plus de savoir si le capteur fonctionne.

La question est de savoir si le réseau continue de fonctionner quand le déploiement devient réel.

C'est là que le design de mioty compte. Parce que chaque message est réparti dans le temps et la fréquence, un événement d'interférence isolé a peu de chance de détruire le message entier. Le réseau peut perdre quelques morceaux et reconstruire les données.

C'est pourquoi la comparaison mioty/LoRaWAN devient particulièrement importante pour l'IoT industriel dense. Il ne s'agit pas seulement de la portée sur une fiche technique. Il s'agit de savoir si le réseau peut continuer à livrer les messages quand l'environnement radio devient encombré et imprévisible.

Portée mioty vs LoRaWAN : pourquoi une couverture fiable compte plus qu'une distance idéale en labo

La portée est toujours l'une des premières choses qu'on demande à propos d'une LPWAN.

Jusqu'où ça va ?

La question est utile mais incomplète. Dans l'IoT industriel, la meilleure question est : jusqu'où ça va tout en restant fiable dans l'environnement réel où ça doit fonctionner ?

Un test de portée en extérieur propre n'a rien à voir avec une usine, un port, un entrepôt, un réseau de services publics ou un smart building. Le métal réfléchit les signaux. Les machines créent du bruit. Murs, cuves, conteneurs, véhicules et personnes modifient l'environnement radio. En ville, beaucoup d'autres appareils partagent le spectre.

LoRaWAN peut atteindre une excellente portée dans de bonnes conditions, surtout avec des facteurs d'étalement élevés. Mais des facteurs d'étalement plus élevés augmentent le temps d'antenne, ce qui réduit la capacité du réseau et affecte l'autonomie. Ce compromis compte.

mioty adopte une autre approche. En répartissant les messages dans le temps et la fréquence, il réduit la probabilité qu'un événement d'interférence isolé détruise tout le message. Cela peut améliorer la portée effective du réseau dans des environnements difficiles, car le récepteur n'a pas besoin d'un paquet continu parfait. Il lui suffit d'avoir assez de rafales pour reconstruire le message.

C'est la différence entre la portée théorique et la portée utile.

Pour les services publics, les usines, les campus, les ports, les réseaux d'eau, les smart buildings et les smart cities, c'est la portée utile qui compte. Un réseau de capteurs IoT longue portée doit fonctionner après l'installation, pas seulement en test propre. Les zones d'ombre apparaissent rarement pendant le test le plus propre. Elles apparaissent au moment du déploiement réel.

Autonomie mioty vs LoRaWAN : comment une communication robuste réduit le gaspillage d'énergie

L'autonomie est un autre point où la comparaison est plus intéressante qu'elle n'en a l'air.

LoRaWAN peut être très efficace quand l'appareil est proche de la passerelle et peut utiliser un facteur d'étalement faible. Dans ce cas, le temps d'antenne est court et l'appareil peut passer la majeure partie de sa vie en veille. C'est une des raisons pour lesquelles LoRaWAN est utile.

Mais quand les conditions deviennent plus dures, LoRaWAN doit souvent monter en facteur d'étalement pour améliorer robustesse et portée. Un facteur d'étalement plus élevé signifie un temps d'antenne plus long. Un temps d'antenne plus long signifie plus d'énergie par message et moins de capacité réseau disponible.

La bonne comparaison n'est donc pas simplement : quelle techno consomme moins dans son mode le plus facile ?

La bonne comparaison est : quelle techno offre une livraison fiable tout en gardant l'appareil efficace ?

C'est ici que mioty devient intéressant. Parce que le fractionnement de télégrammes rend les messages plus résilients, mioty peut atteindre une forte robustesse sans dépendre d'un temps d'antenne continu long de la même manière. La mioty Alliance indique une consommation côté terminal de 17,8 μWh par message à 868 MHz et positionne mioty pour une autonomie de plus de 20 ans dans des déploiements adaptés.

Bien sûr, l'autonomie dépend toujours de l'appareil réel, de l'intervalle des messages, de la taille de la charge utile, de la chimie de la batterie, de la température, du firmware et du comportement du capteur. Aucun ingénieur sérieux ne devrait promettre « 20 ans » sans contexte.

Mais l'architecture compte.

Si la couche radio est plus résiliente, on dépense moins d'énergie à lutter contre l'environnement.

mioty vs LoRaWAN pour l'IoT industriel : pourquoi les pilotes échouent quand les réseaux deviennent denses

Beaucoup de pilotes IoT paraissent bons parce que les pilotes sont en général contrôlés.

Il y a quelques capteurs. La passerelle est proche. Le spectre n'est pas trop chargé. L'installateur sait ce qu'il teste. Le tableau de bord se met à jour. Tout le monde est enthousiaste.

Puis le projet passe au monde réel.

Soudain le réseau doit gérer plus d'appareils, de moins bons emplacements d'installation, des comportements moins prévisibles et des environnements physiques absents de la démo. Certains appareils sont en intérieur. Certains sont en sous-sol. Certains sont entourés de métal. Certains bougent. Certains sont placés là où c'est pratique pour l'exploitation, pas là où c'est idéal pour le RF.

C'est là que beaucoup de projets IoT deviennent plus difficiles que prévu.

Pas parce que l'IoT serait une mauvaise idée.

Mais parce que la couche sans fil a été traitée comme un détail.

Pour moi, c'est là que mioty mérite plus d'attention. Il a été pensé pour des réseaux de capteurs denses. Il a été pensé en partant du principe que les messages vont entrer en collision, que le spectre sera bruyant et que le réseau doit quand même récupérer des données utiles.

Cela le rend particulièrement pertinent pour les services publics, la supervision industrielle, les infrastructures de smart city, les cours logistiques, les ports, les entrepôts, la surveillance de cuves, la mesure environnementale et tout réseau LPWAN privé où des milliers de petits messages doivent passer de manière fiable.

À mes yeux, c'est là que l'IoT commence à devenir vraiment utile.

Pas quand on connecte un capteur.

Quand on peut faire confiance à des milliers de capteurs pour remonter du monde réel.

mioty vs LoRaWAN pour les systèmes de sécurité intelligents : du panneau de sortie à la guidance d'urgence en temps réel

Un exemple auquel je pense souvent, c'est la signalétique d'évacuation incendie.

La plupart des panneaux de sortie aujourd'hui sont stupides. Ils indiquent où est une sortie, mais ne savent pas si le couloir derrière le panneau est réellement sûr. En cas d'incendie, c'est un vrai problème. Un panneau peut diriger les gens vers une sortie, mais le couloir derrière peut être rempli de fumée, de chaleur, ou d'une zone d'incendie active.

Imaginez maintenant un bâtiment avec des capteurs sans fil fiables surveillant température, fumée, qualité de l'air et occupation par zone. Si ces capteurs peuvent remonter à travers les interférences et des conditions intérieures difficiles, la signalétique intelligente pourrait réagir en temps réel.

Un panneau vert signifierait que l'itinéraire de sortie est disponible.

Un panneau rouge signifierait : oui, il y a une sortie ici, mais ne passez pas par là, parce qu'il y a du feu ou de la fumée plus loin.

C'est le type d'application IoT qui m'enthousiasme.

Bien sûr, les systèmes de sécurité critiques nécessitent certification, redondance, conformité aux normes et ingénierie soignée. mioty seul ne remplacerait pas les alarmes incendie, l'éclairage de secours ni les normes de sécurité bâtimentaire. Mais comme couche d'une stratégie de sécurité de bâtiment intelligent, un sensing sans fil fiable pourrait rendre la guidance d'urgence plus dynamique et plus utile.

C'est le genre de chose qui me fait avancer.

Je ne m'enthousiasme pas pour les capteurs parce qu'ils produisent des graphes. Je m'enthousiasme pour les capteurs parce qu'ils permettent à des systèmes physiques de réagir à ce qui se passe vraiment.

mioty vs LoRaWAN pour les actifs en mouvement : pourquoi la mobilité rend la fiabilité sans fil plus difficile

Beaucoup d'actifs IoT industriels ne sont pas immobiles.

Les conteneurs traversent les cours. Les outils circulent sur les sites. Les équipements changent de bâtiment. Les véhicules bougent dans les dépôts. Les palettes traversent les entrepôts. Même les personnes et les équipements de sécurité bougent et modifient l'environnement radio.

Le mouvement complique le sans-fil. Le chemin du signal change. Les réflexions changent. La distance change. Les obstacles changent. Le réseau doit composer avec un monde physique qui n'est pas statique.

Lors de tests comparatifs entre mioty et LoRa, mioty a montré de fortes performances à des niveaux de mobilité élevés, tandis que LoRa était plus limité dans les conditions testées.

Tous les déploiements n'ont pas besoin de haute mobilité, évidemment. Un compteur d'eau ne se déplace pas sur l'autoroute. Mais le résultat compte parce qu'il rejoint le même schéma : mioty est conçu pour conserver une communication robuste quand les conditions ne sont pas idéales.

C'est le fil rouge de toute cette comparaison.

LoRaWAN fonctionne bien dans de nombreux déploiements pratiques.

mioty devient particulièrement convaincant quand le déploiement devient dense, bruyant, mobile ou critique.

Réseaux hybrides LoRaWAN et mioty : pourquoi la réponse pratique n'est pas un seul protocole partout

C'est là que la réponse pratique n'est pas dogmatique.

LoRaWAN a toujours du sens dans beaucoup de déploiements parce que l'écosystème est plus mature. Il y a plus d'appareils, plus de passerelles, plus d'intégrateurs, plus d'exemples, plus de documentation et plus de personnes qui savent déjà l'utiliser.

C'est important.

Si un client a besoin d'un capteur aujourd'hui et qu'une version LoRaWAN fiable existe déjà, ce peut être le bon choix. Si le déploiement est peu dense, le trafic faible, l'environnement RF gérable, et que l'application tolère les compromis classiques de LoRaWAN, il n'y a aucune raison d'imposer mioty juste parce qu'il est techniquement plus fort dans des environnements denses.

Mais là où des appareils mioty sont disponibles, et où le déploiement a besoin de plus de résistance aux interférences, de plus de capacité, d'une plus grande fiabilité ou de meilleures performances dans des conditions industrielles difficiles, mioty est le meilleur choix.

C'est pour cela que je pense que l'avenir n'est pas « LoRaWAN ou mioty ».

L'avenir est hybride.

Utiliser LoRaWAN là où l'écosystème offre la meilleure disponibilité d'appareils et le déploiement le plus rapide. Utiliser mioty là où le réseau doit être plus robuste, plus scalable et plus fiable sous pression.

Heureusement, c'est exactement ainsi que nous pensons Kilo Cloud. Kilo Cloud supporte à la fois LoRaWAN et mioty, pour que les développeurs et les entreprises n'aient pas à s'enfermer dans une seule technologie sans fil. La bonne approche est de choisir le meilleur protocole pour chaque partie du déploiement et de gérer les données dans une seule plateforme.

C'est beaucoup plus pragmatique que de prétendre qu'une seule LPWAN devrait résoudre tous les problèmes.

Serveur mioty open source : pourquoi KiloCenter rend l'infrastructure mioty pratique

C'est aussi pourquoi nous avons construit KiloCenter.

Plus j'ai regardé mioty, plus une chose est devenue évidente : la technologie radio n'est qu'une partie de l'histoire. Si mioty doit être utile dans des déploiements réels, les développeurs ont besoin d'infrastructure qu'ils peuvent vraiment lancer, inspecter et intégrer.

LoRaWAN a réussi en partie parce qu'on pouvait construire avec. On pouvait acheter des appareils, déployer des passerelles, se connecter à des serveurs réseau et expérimenter. mioty a besoin du même chemin pratique.

C'est ce que KiloCenter cherche à fournir.

KiloCenter est un serveur mioty open source pour les développeurs, les intégrateurs et les entreprises qui veulent travailler directement avec mioty. Il permet aux équipes de tester mioty, de connecter des stations de base, d'enrôler des terminaux, de traiter les uplinks, de gérer les downlinks et d'intégrer les données dans de vraies applications.

Et parce que Kilo Cloud supporte à la fois LoRaWAN et mioty, KiloCenter ne consiste pas à forcer tout le monde à abandonner LoRaWAN. Il s'agit de rendre mioty pratique là où mioty est le meilleur outil.

Pour moi, c'est important parce que l'infrastructure doit être quelque chose que les ingénieurs peuvent toucher.

Si nous voulons que mioty se développe, les gens ont besoin de plus que des promesses marketing sur la capacité et la portée. Ils ont besoin d'outils qui marchent. Ils ont besoin de code. Ils ont besoin d'un moyen de connecter du matériel, de recevoir des messages et de construire des applications autour des données.

C'est le rôle que je veux que KiloCenter joue.

Pas comme un produit ajouté à la fin d'un article, mais comme une vraie brique de l'écosystème mioty.

L'infrastructure open source rend cela possible.

mioty Service Center pour les développeurs : pourquoi l'auto-hébergement compte

L'une des raisons pour lesquelles l'infrastructure open source compte, c'est le contrôle.

Dans l'IoT industriel, beaucoup d'entreprises ne veulent pas que tout leur réseau soit caché derrière un système fermé. Elles veulent comprendre comment les données circulent. Elles veulent savoir comment les stations de base se connectent, comment les terminaux sont gérés, comment les uplinks sont traités, comment les downlinks sont envoyés et comment le système s'intègre au reste de leur infrastructure.

C'est pour cela qu'un serveur mioty auto-hébergé a de la valeur.

Il offre aux développeurs et aux opérateurs un moyen de tester les réseaux mioty directement, de construire des intégrations, de connecter des applications et de comprendre le chemin complet du capteur au serveur. Pour les intégrateurs systèmes et les équipes industrielles, c'est ce qui peut faire la différence entre considérer mioty comme un protocole intéressant et pouvoir vraiment le déployer.

KiloCenter cherche à rendre ce chemin plus simple.

Il donne aux équipes un point de départ pratique pour bâtir avec mioty, expérimenter avec des stations de base et des terminaux et brancher les données mioty dans de vraies applications.

Pour moi, c'est le point le plus important.

Un protocole devient utile quand les gens peuvent construire avec.

Conclusion mioty vs LoRaWAN : LoRaWAN a bâti le marché, mioty résout le problème d'échelle suivant

LoRaWAN a aidé beaucoup d'entre nous à imaginer ce que pouvait devenir l'IoT bas-débit basse consommation.

Il reste utile. Il reste pratique. Il a toujours l'écosystème d'appareils le plus fort. Dans beaucoup de déploiements, cela compte plus que la performance théorique.

Mais quand l'IoT industriel passe de petits déploiements à de l'infrastructure dense, les exigences deviennent plus sérieuses. L'interférence compte davantage. L'autonomie dans des conditions difficiles compte davantage. La capacité du réseau compte davantage. La fiabilité compte davantage.

Et quand un message représente quelque chose d'important — de la fumée dans un couloir, une rivière qui monte près d'une berge, une machine qui commence à défaillir, un itinéraire d'évacuation bloqué — la livraison du paquet n'est plus juste une métrique technique.

Elle devient la différence entre savoir et ne pas savoir.

C'est là que mioty est meilleur.

Le fractionnement de télégrammes est une façon plus réaliste de penser la communication dans des environnements désordonnés. Il admet que le monde est bruyant, que les paquets entrent en collision, et que tous les morceaux d'un message ne survivront pas. Puis il donne au réseau un moyen de récupérer quand même les données.

C'est ce genre d'ingénierie dont l'IoT industriel a besoin.

La vraie réponse n'est donc pas que chaque déploiement LoRaWAN devrait devenir un déploiement mioty. La vraie réponse est que l'IoT industriel a besoin des deux. LoRaWAN apporte la maturité et la disponibilité des appareils. mioty apporte une meilleure fiabilité et une meilleure scalabilité quand le réseau est sous pression.

Avec Kilo Cloud qui supporte à la fois LoRaWAN et mioty, et KiloCenter qui rend une infrastructure mioty open source accessible aux développeurs, les équipes n'ont pas à choisir un camp pour toujours.

Elles peuvent utiliser la bonne technologie sans fil pour le bon usage.

C'est ce qui rend cela enthousiasmant pour moi.

Pas le nom du protocole. Pas les buzzwords. Pas même les statistiques.

Ce qui est enthousiasmant, c'est ce qui devient possible quand le sensing sans fil devient assez fiable pour qu'on puisse s'y fier dans le monde réel.