À propos des protocoles IoT, le plus souvent HTTP, CoAP et MQTT sont utilisés pour la communication.
HTTP et CoAP conviennent aux communications REST de type client (s) à serveur et MQTT prend en charge la communication multi-utilisateurs basée sur la publication et l'abonnement, dont l'origine peut facilement être de serveur à client, de client à serveur et même de client à client.
Répondre à la question:
Utilisez REST sur HTTP ou CoAP pour les communications un à un ou MQTT pour une utilisation du trafic multipoint.
Plus de détails
Après le commentaire ci-dessous, j'avoue que ma réponse était assez partielle, j'ai donc examiné et trouvé un peu plus:
Même les communications ont ce genre de gâchis de normes, si tout est calculé:
Source: EU Butler Project - Problèmes de communication
En outre postscapes.com a la liste suivante en fonction des différents aspects:
1 Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL)
2 Identification (ex: EPC, uCode, IPv6, URIs)
3 Comms / Transport (ex: Wifi, Bluetooth, LPWAN)
4 Discovery (ex: Physical Web, mDNS, DNS-SD)
5 Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, Node)
6 Device Management (ex: TR-069, OMA-DM)
7 Semantic (ex: JSON-LD, Web Thing Model)
8 Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit)
Comme on le voit dans la liste de chaque exemple, il y en a beaucoup et il y en a sûrement plus de personnalisés et propriétaires.
Vous devriez ouvrir ce lien et le lire, c'est époustouflant. Je crois que vous pouvez rencontrer dans votre (vos) projet (s) beaucoup de ces derniers, au moins si les capteurs sont de forme très compacte, c'est-à-dire. non seulement des composants dans le format le plus pur, mais des parties d'un écosystème déjà existant. Dans ces cas, vous ne pouvez peut-être pas négocier la façon dont vous les interfacez, il vous suffit de choisir entre les écosystèmes.
Le bon problème semble maintenant être de trouver un ensemble de produits ou un ensemble d'ensembles (groupe d'ensembles de produits) corrects avec des piles de protocoles identiques ou presque identiques sur le wifi, lorsque vous définissez l'objectif (en gardant à l'esprit que l'infrarouge est une solution hors de cette zone et là-bas). sont de nombreuses autres solutions de réseautage sans fil non Internet, auxquelles vous pouvez toujours faire face).
Les critères seraient d'identifier ce que vous pourriez vouloir faire et le nombre de piles que vous voudriez apprendre de cette façon. En apprenant, je veux dire que vous voulez toujours jouer peu avec les gadgets et être conscient du fonctionnement du protocole sous le capot.
Ma recommandation est MQTT. Polyvalent, léger et modulaire, il peut même fonctionner sur un ESP8266 (Hub et client). Le protocole MQTT est disponible pour de nombreuses plates-formes à partir d'appareils embarqués et mobiles et jusqu'aux gros OS tels que MAC, Windows et Linux.
Le protocole a un modèle Publisher, Subscriber pour la communication. Et une QoS pour qu'un Hub puisse se souvenir si un abonné a reçu un message d'un éditeur. Ainsi, un appareil de couchage peut se mettre à jour lorsqu'il se réveille et recherche ses messages.
Je lance mon serveur MQTT sur un petit Raspberry Pi Zero W, c'est comme une carte de crédit sur le mur et pour la logique j'utilise "Node Red" et j'ai commencé à chercher OpenHAB pour une solution plus compliquée.
J'ai également construit mes propres appareils Arduino / MQTT pour mes appareils 12v DC et utilise un produit basé sur ESP8266 pour mes appareils 230v AC.
la source