C'est un sujet auquel je pense depuis un moment, notamment parce que le concept "IoT" a beaucoup circulé ces derniers temps.
Je vais commencer par ce que je veux dire quand je dis "IoT" . Je sais que le terme IoT pourrait signifier différentes choses et qu'il est parfois mal utilisé. Ce pourrait être un terme qui n'est pas clairement défini et peut conduire à de grandes discussions sur ce que cela signifie exactement, je ne connais pas moi-même la définition correcte et largement acceptée du terme. Donc, pour moi, l'IoT est un concept, un concept qui définit la possibilité de se connecter à distance à un appareil embarqué via Internet, soit depuis un autre appareil embarqué, soit depuis un téléphone portable . Aussi simple que cela.
Dans ce contexte, l'objectif de la connexion n'a pas d'importance, si vous pouvez connecter un appareil dans votre bureau à un autre à la maison, ou si vous pouvez vous connecter à un appareil à la maison à partir de votre téléphone portable, tout cela via Internet, nous parlons ensuite des appareils IoT (les appareils embarqués, pas le téléphone).
Donc, après avoir convenu de ce que je veux dire par IoT, je vais maintenant décrire ce que j'essaie de réaliser.
Ce que j'essaie d'atteindre, c'est précisément ce que je décris dans ma définition de l'IoT.
Je veux avoir un ou plusieurs appareils embarqués à la maison connectés à mon routeur Internet, soit par Ethernet ou wifi et pouvoir me connecter à distance avec d'autres appareils embarqués dans un endroit distant (et par télécommande je veux dire pas sur le même réseau) et peut-être aussi pour pouvoir me connecter avec une application de surveillance sur mon téléphone
Par exemple, je peux avoir un simple appareil intégré agissant comme un interrupteur marche / arrêt accroché à mon ouvre-porte de garage et un autre appareil intégré agissant comme un gros bouton rouge sur mon bureau au travail afin que je puisse appuyer sur le bouton rouge de mon bureau et la porte du garage s'ouvre.
Un autre exemple serait d'avoir un appareil intégré avec des capacités ADC qui peut surveiller la température de ma maison et m'envoyer une alerte lorsqu'elle atteint un seuil. La notification peut être reçue soit par une simple application Android, soit par un autre appareil intégré avec un petit écran posé sur mon bureau au travail.
Ces exemples peuvent être stupides, mais ne sont que pour illustrer les scénarios possibles et les cas d'utilisation pour ce que j'essaie de réaliser. À la fin, l'idée est la même: connecter un appareil intégré à un autre via Internet.
Une autre chose à clarifier est que l'échange de données entre ces appareils sera très léger, seulement quelques octets à chaque fois, ce n'est pas que des centaines de kilo-octets soient nécessaires pour être échangés entre les appareils.
De plus, le type d '«appareils intégrés» dont je parle sont des appareils simples mais capables basés sur des microcontrôleurs cortex-m4 100 MHz ou 200 MHz. Et c'est important de clarifier car il n'y aura pas de Linux ou de bibliothèques complexes fonctionnant sur ces appareils. En fin de compte, c'est un tel gaspillage de ressources et complètement inutile d'avoir un processeur puissant exécutant Linux juste pour allumer et éteindre une ampoule . Dans tous les cas, je prévois d'utiliser un BeagleBoard, un Raspberry Pi ou toute autre carte comme celle-ci comme appareils intégrés. Juste des microcontrôleurs car pas plus de complexité que nécessaire.
Je ne connais pas grand-chose aux plateformes IoT et à ce genre de solutions complexes. Lorsque j'ai commencé ce voyage pour trouver un moyen de connecter un appareil intégré à un autre via Internet, je suis tombé sur deux sites avec des services IoT.
Je sais qu'il existe des services cloud IoT comme:
Juste pour en nommer quelques-uns. Les principaux problèmes avec ceux-ci sont le coût et la complexité. Vous devez payer pour obtenir ces services et vous devez également apprendre à mettre en œuvre tous les services dont ils disposent, au cas où vous en auriez besoin tous, et leurs API et peut-être un tas d'autres choses qui ne me semblent pas nécessaires pour être capable d'échanger seulement quelques octets entre les appareils. Je veux juste quelque chose de plus simple que ça, quelque chose que je peux faire moi-même.
Vous pouvez dire que l'implémentation de mon propre "cloud", si c'est quelque chose que je dois faire, n'est pas simple et qu'il est parfois préférable d'utiliser ce genre de services pour des raisons de simplicité, mais il y a deux raisons principales pour lesquelles je veux savoir comment implémenter mes propres services IoT.
La raison principale est que je veux le faire moi-même. Je ne veux pas compter sur une tierce partie pour connecter mes appareils entre eux et comme je développerai le code et le matériel de mes appareils, il est préférable de créer également mes propres moyens pour les connecter en tant qu'appareils IoT.
La deuxième raison est d'apprendre à le faire. En sachant tout ce dont j'ai besoin pour y parvenir, j'aurai une meilleure compréhension du monde IoT.
De plus, je tiens à mentionner que je maîtrise C et j'utilise Linux comme système d'exploitation de tous les jours au travail comme à la maison, alors s'il vous plaît, évitez les trucs Windows car cela ne me sert à rien. Je n'ai pas peur de tout ce que j'ai à implémenter en C pour mes appareils embarqués ou sur Linux pour implémenter tout ce qui est nécessaire pour atteindre mon objectif.
Ma question est donc la suivante: que faut-il mettre en œuvre et où, pour pouvoir connecter deux ou plusieurs appareils intégrés entre eux dans le but d'échanger des données entre eux?
Cette question Que puis-je utiliser pour créer un IoT sur notre propre serveur? ont quelque chose de similaire mais est fermé et n'a pas de réponse, suppose également qu'une infrastructure cloud déjà existante soit utilisée. Donc ça ne m'aide pas.
Cet autre article Quels services IoT sont disponibles pour stocker / envoyer / publier des données génériques dans le cloud? a une question similaire, mais le PO demande explicitement des services IoT et j'essaye de les éviter.
la source
Réponses:
J'ai peut-être manqué le point de la question, mais je pense que c'est un bon début pour une réponse.
Vous avez besoin de trois choses, au minimum.
N'oubliez pas la sécurité. En faisant cela, vous serez plus près d'ouvrir tout sur votre réseau domestique pour attaquer. Peut-être seulement un peu, mais il est bon d'être conscient du risque. Vous pouvez essayer de faire attention, mais supposez que vous ferez des erreurs.
la source
Les appareils légers et les taux de date de quelques octets demandent l'utilisation de MQTT , comme cela a déjà été mentionné. Vos nœuds de capteur peuvent être basés sur des modules autonomes ESP8266 suffisamment puissants pour héberger une implémentation client MQTT. Ou vous pouvez simplement utiliser ces modules en tant que module Wi-Fi contrôlé par la commande AT avec vos microcontrôleurs externes.
Vous pouvez implémenter votre propre solution MQTT sur des microcontrôleurs beaucoup moins puissants comme ce type qui a utilisé un Atmega48V avec 4 Ko de flash .
Vous pouvez héberger un courtier sur votre ordinateur, mais il serait plus économe en énergie d'exécuter un Raspberry Pi à la place. Encore une fois, si vous aimez le codage, vous pouvez implémenter votre propre courtier MQTT. Personnellement, j'ai trouvé Mosquitto idéal à cet effet.
Inconvénient que tous vos nœuds de capteur auraient besoin d'une connexion TCP / IP.
La solution conviviale pour la batterie pourrait être d'utiliser des nœuds de capteur / actionneur activés par LoraWAN ou ZigBee et d'implémenter une passerelle sur un Raspberry / BeagleBone qui peut également héberger un simple serveur Web accessible à partir de votre téléphone ou d'autres appareils.
Dans tous les cas, tout se résume à rendre votre hub, passerelle ou serveur accessible en dehors de votre réseau privé. Il y a plus de façons de le faire et la principale préoccupation est toujours la sécurité. C'est la partie la plus risquée à mon avis.
Les exigences de base sont assez bien résumées par @Sean.
la source
Vous avez remis en question les deux réponses précédentes sur la nécessité d'un contrôleur / concentrateur. Considérez que pour faire bouger les choses, vous avez besoin de règles pour exister. Si vous voulez appuyer sur un gros bouton rouge pour ouvrir une porte de garage, une règle doit lier le capteur (bouton) à l'action souhaitée (ouvrir la porte). Il y a deux façons d'y arriver: vous pouvez mettre la règle directement dans le bouton, ou vous pouvez mettre la règle dans un ordinateur distinct.
Réfléchissons davantage à la solution directe. Si vous enseignez le bouton sur la porte de garage, votre bouton contient les règles en interne. Le bouton a besoin de l'ID de la porte de garage, donc si vous remplacez la porte de garage, le bouton ne fonctionne pas. Si le bouton est sur votre bureau et que votre maison utilise un réseau propriétaire, le bouton doit connaître à la fois l'adresse de la passerelle de votre maison et l'adresse de la porte. Le bouton doit connaître le protocole spécifique pour signaler l'ouverture de votre porte - tous les fabricants fabriquent-ils des boutons compatibles qui connaissent tous les signaux de porte? Le bouton ne peut rien faire d'autre à moins que vous ne le reprogrammiez - avez-vous un programmeur flash pour la puce du bouton, et ce programmateur est-il compatible avec d'autres appareils? Si vous voulez que la porte du garage s'ouvre et se ferme 5 minutes plus tard, votre bouton a besoin de toutes les complexités du maintien d'une horloge en temps réel. Votre bouton ne connaîtra pas l'état de la porte, ce qui rend difficile de savoir si vous fermez ou ouvrez la porte. Et comment sauvegardez-vous les règles pour que si votre bouton casse, votre bouton de remplacement puisse faire le travail? Du côté positif, cela semble bon marché: vous n'avez pas besoin d'un ordinateur séparé.
Avec un contrôleur, les choses sont différentes. Tous les messages de tous les capteurs sont transmis au contrôleur. Chaque capteur est simple: envoyez le signal au contrôleur. Le contrôleur peut ensuite appliquer toutes les entrées nécessaires à des règles très complexes: il peut vérifier le capteur d'ensoleillement et ne pas allumer les lumières extérieures sauf s'il fait sombre, ou ne pas faire fonctionner les arroseurs si les précipitations moyennes pour le mois sont supérieures à la moyenne et la température actuelle est de cinq degrés au-dessous de la moyenne. Le contrôleur peut suivre l'état. Cela peut être important si vous voulez un bouton "fermer la porte du garage" mais pas un bouton "ouvrir la porte du garage" (quand je suis loin de chez moi, je veux rarement ouvrir la porte, mais je veux vraiment la fermer si elle est accidentellement laissé ouvert.)
Le contrôleur peut fournir la place aux pilotes de périphérique qui savent écouter les boutons et aux autres pilotes qui savent parler aux portes. Le contrôleur peut être plus évolutif vers de nouveaux appareils et types d'appareils qu'une petite puce cachée à l'intérieur d'un bouton.
Le contrôleur peut également avoir une logique plus complexe pour les tâches d'infrastructure telles que la livraison de messages en offrant certains niveaux de service. Par exemple, le protocole MQTT permet trois niveaux différents: essayez de remettre le message une fois, remettez-le à plusieurs reprises jusqu'à ce qu'il soit vu au moins une fois, ou remettez-le une seule fois.
Le contrôleur offre un emplacement logique sur le plan architectural pour consolider toute la messagerie vers et depuis une passerelle de communication, permettant l'utilisation d'une interface externe. Cela signifie que votre bouton et votre téléphone peuvent tous deux envoyer des signaux, et les règles peuvent déterminer que l'un ou l'autre est autorisé à ouvrir la porte du garage. La passerelle peut également assurer la sécurité. Vous n'avez pas besoin de mettre votre bouton et votre porte de garage sur Internet; vous pouvez les mettre sur des réseaux privés isolés et utiliser la passerelle pour transporter les signaux. Le contrôleur fournit également un point unique pour sauvegarder toutes les règles de votre système.
Les inconvénients du contrôleur sont une latence supplémentaire et une complexité supplémentaire. Étonnamment, un contrôleur ne fait pas augmenter le coût de manière appréciable. Vous pouvez implémenter un contrôleur sur un Raspberry Pi pour moins que le coût d'un interrupteur d'éclairage contrôlable à distance moyen. Ne négligez pas l'idée sur la seule base du coût.
la source