Normes pour les appareils WiFi non connectés à Internet?


10

Je prévois de faire beaucoup de domotique. Pour cela, j'hébergerai un réseau WiFi privé isolé auquel tous mes appareils seront connectés. Les appareils seront des lumières simples, des bandes LED RGB (smd5050 et ws2812b), des thermostats, des ventilateurs, des ouvre-fenêtres, des contrôleurs de stores et des prises normales. En outre, des émetteurs IR pour simuler une télécommande afin de démarrer les téléviseurs, etc. Et un émetteur 433 MHz pour simuler une télécommande qui peut basculer les prises standard télécommandées.

Maintenant, je me demande s'il existe des normes sur le type d'interface que ces appareils devraient exposer au réseau WiFi.

Je pourrais bien sûr donner à chaque appareil un itinéraire http simple, puis écrire des applications qui comprennent mon interface, mais ce serait bien si je pouvais mettre en œuvre une norme qui me permettrait d'utiliser des applications et des programmes qui ont déjà été écrits et qui comprennent la norme .

Réponses:


7

À 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é:

http://www.slideshare.net/butler-iot/butler-project-overview-13603599

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.


1
"REST over http" est un peu vague. Même dans cet esprit, je pouvais penser à cent façons différentes de concevoir l'interface, en particulier pour les appareils qui comprennent plus que «marche» et «arrêt». Idéalement, je fournirais simplement l'adresse IP et le type d'appareil et le reste serait normalisé. Existe-t-il quelque chose comme ça?
Forivin

7

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.