Quel protocole dois-je utiliser pour les appareils d'automatisation dans un environnement domestique?


9

J'ai un projet pour automatiser des choses dans une maison. Je suis développeur mais débutant en électronique et IoT.

Que dois-je utiliser pour communiquer sans fil? Wi-Fi, Bluetooth ... Où dois-je chercher?

J'ai besoin d'une solution bon marché, à faible consommation et minuscule , par exemple en faisant un interrupteur de lumière sans fil supplémentaire, ou, essayez de faire des choses comme la triangularisation locale avec un brassard de circuit intégré de mes camarades de maison (il n'y a pas de prisonniers! La maison est grande et c'est pour avoir un "mode torche" - les lumières vous suivent, pour des économies d'énergie)

Nous cultivons également des aliments (champignons), afin d'optimiser les cultures à l'avenir. Je veux également ouvrir / fermer certaines portes.

Il doit être modulaire pour qu'une API à la fin puisse être cool.

Un circuit intégré Bluetooth sur IoT centralisé par Raspberry Pi (serveur) et contrôlable par Wi-Fi (ou directement via Bluetooth) est-il une bonne chose à regarder? Qu'est-ce que je rate?


3
Certainement pas le wifi en raison du problème d'alimentation, une faible consommation d'énergie Bluetooth possible, car comme il y a des défauts de conception de nombre dans la spécification, en particulier en ce qui concerne le partage, peut-être un schéma personnalisé entre les puces radio / MCU 2,4 GHz conçu pour répondre plus précisément à vos besoins. L'utilisation de BTLE a littéralement du sens si vous devez communiquer avec des appareils existants qui en ont, en particulier des téléphones.
Chris Stratton

1
Pour communiquer avec les téléphones, que se passe-t-il si je ne le fais pas directement mais que je gère les données du schéma personnalisé sur un Raspberry PI par exemple et que je gère mon serveur avec un service Web pour le téléphone / les applications? Avez-vous une bonne source pour apprendre le schéma personnalisé, etc.?
Morpheus

1
Ensuite, vous pouvez implémenter quelque chose de personnalisé aux deux extrémités. Gardez à l'esprit que les pi sont fragiles en raison de la dépendance à une carte SD qui n'aime pas la perte de puissance inopportune.
Chris Stratton

2
Je ne sais pas où vous avez eu l'idée que 2,4 GHz est cher, car cela est faux. Les émetteurs-récepteurs sont aussi peu qu'un dollar, en quantité unique. Cependant, 25 m peuvent être moins que fiables pour de nombreux mécanismes sans licence, du moins s'il y a des murs ou d'autres sources de bruit. Quelque chose comme LoRa est conçu pour parcourir des distances (beaucoup) plus longues avec une faible puissance, mais il y a des limites beaucoup plus faibles sur le débit et la quantité globale de données que vous pouvez y faire passer.
Chris Stratton

2
Je ne suis pas sûr qu'il y ait quoi que ce soit sur l'étagère, mais l'idée de BT-LE est sauvegardée par des nœuds connectés wifi pour obtenir une sonorité sensible.
Sean Houlihane

Réponses:


8

Ici, vous avez une belle liste de 11 protocoles IoT que vous devez connaître.

Voici un résumé au cas où le lien se casserait un jour

Norme Bluetooth : spécification de base Bluetooth 4.2 Fréquence: 2,4 GHz (ISM) Plage: 50-150 m (intelligent / BLE) Débits de données: 1 Mbps (intelligent / BLE)

Norme Zigbee : ZigBee 3.0 basé sur IEEE802.15.4 Fréquence: 2,4 GHz Plage: 10-100 m Débit de données: 250 kbps

Norme Z-Wave : Z-Wave Alliance ZAD12837 / UIT-T G.9959 Fréquence: 900 MHz (ISM) Plage: 30 m Débit de données: 9,6 / 40/100 kbit / s

6LowPAN Standard: RFC6282 Fréquence: (adapté et utilisé sur une variété d'autres médias réseau, y compris Bluetooth Smart (2,4 GHz) ou ZigBee ou RF à faible puissance (inférieure à 1 GHz) Plage: N / A Débits de données: N / A

Filetage standard: filetage, basé sur IEEE802.15.4 et 6LowPAN Fréquence: 2,4 GHz (ISM) Plage: N / A Débits de données: N / A

Norme Wi-Fi : basée sur 802.11n (utilisation la plus courante dans les foyers aujourd'hui) Fréquences: bandes 2,4 GHz et 5 GHz Plage: environ 50 m Débit de données: 600 Mbps maximum, mais 150-200 Mbps est plus typique, selon la fréquence du canal utilisé et le nombre d'antennes (la dernière norme 802.11-ac devrait offrir 500Mbps à 1Gbps)

Standard cellulaire : GSM / GPRS / EDGE (2G), UMTS / HSPA (3G), LTE (4G) Fréquences: 900/1800/1900 / 2100 MHz Plage: 35 km max pour GSM; 200 km max pour les débits de données HSPA (téléchargement standard): 35-170 kps (GPRS), 120-384 kbps (EDGE), 384Kbps-2Mbps (UMTS), 600kbps-10Mbps (HSPA), 3-10Mbps (LTE)

Norme NFC : ISO / IEC 18000-3 Fréquence: 13,56 MHz (ISM) Plage: 10 cm Débits de données: 100–420 kbps

Sigfox Standard: Sigfox Fréquence: 900 MHz Plage: 30-50 km (environnements ruraux), 3-10 km (environnements urbains) Débits de données: 10-1000 bps

Norme Neul : Fréquence Neul: 900 MHz (ISM), 458 MHz (Royaume-Uni), 470 à 790 MHz (espace blanc) Plage: 10 km Débit de données: quelques bps jusqu'à 100 kbps

Norme LoRaWAN : Fréquence LoRaWAN: Divers Plage: 2-5 km (environnement urbain), 15 km (environnement suburbain) Débit de données: 0,3-50 kbps.

Considérez simplement que:

  1. Plus la distance que vous souhaitez parcourir avec le signal est longue, plus vous avez besoin de puissance.

  2. Plus le débit de données dont vous avez besoin est élevé, plus la fréquence est élevée, donc plus de consommation d'énergie.

Je suggère donc d'opter pour un protocole basse fréquence; ZigBee fonctionne assez bien, consomme très peu et est très populaire. Le seul inconvénient est que le Raspberry Pi n'inclut pas d'émetteur ZigBee, vous pouvez avoir besoin d'un fruit supplémentaire.


Ceci est une bonne liste, ce serait bien de garder cela à jour. J'ajouterais quelques choses; Bluetooth 5 (changements de débit et de gamme) et capacités de maillage, LoRa pourrait aller jusqu'à 300 kbps (ce sont les modules que j'ai vus, mais je pense qu'il y en a qui pourraient aller encore plus).
dicobraz

6

En se référant à la liste des protocoles fournis dans la réponse de Snake, il semble que vous ayez besoin d'un protocole avec une portée de 20 à 100 m, de bonnes performances à faible puissance (idéalement passif, mais je ne connais aucune solution), et pas vraiment beaucoup de bande passante pour la partie portée. De plus, vous avez besoin de certains nœuds statiques qui peuvent être moins contraints du point de vue de la puissance.

BT-LE est le protocole le plus largement adopté. Malheureusement, je ne pense pas que vous puissiez réutiliser un téléphone portable de la même manière que vous utiliseriez un nœud (sauf si vous vous reposez sur des interactions purement passives avec le protocole). Cependant, les SoC qui fournissent ce protocole, ainsi que suffisamment de périphériques pour activer un tracker de fitness ou des écouteurs, sont courants (et améliorent les spécifications).

Si vous regardez les SoC les plus récents avec une radio 2,4 GHz, vous constaterez qu'ils prennent souvent en charge plus que le Bluetooth (il vous suffit de configurer la bonne pile logicielle), il vaut donc la peine d'étudier si vous pouvez obtenir de meilleurs résultats avec un protocole différent ( mais alors vous avez la pénalité de devoir ajouter une autre radio à vos nœuds statiques). Votre cas d'utilisation semble reposer sur une indication fiable de la force du signal (en supposant que la précision du temps de vol n'est pas nécessaire).

À ce stade de la conception, l'une des tâches les plus importantes consiste à définir un budget de puissance et un profil de charge pour l'appareil portable. Cela aura un impact sur les profils de sommeil et les fréquences de transmission. Vous voudrez probablement utiliser un accéléromètre pour adapter la vitesse de transmission (car la radio prendra probablement plus d'énergie à transmettre que le simple sondage pour vérifier le mouvement).


4

Un protocole non répertorié dans la réponse de Snake sont les modules radio pour 433 MHz / 868 MHz / 915 MHz, dont l'un couvrira la bande de loisirs / recherche dans votre pays, et peut être utilisé pour créer des nœuds de faible puissance. RFM69 et NRF24L01 +.

https://www.mysensors.org/ les a mis dans une configuration réseau avec protocole et passerelles, tous open source, qui parlent à une gamme de contrôleurs existants et offrent de nombreuses opportunités de développement aux extrémités du capteur / nœud et du contrôleur.


2

Je regarderais certaines des solutions de Nordic SoC qui ont des protocoles intégrés. C'est un bon moyen d'avoir une puce qui vous permettrait de tester différents scénarios, Nordic a des SoC avec la plupart des protocoles courants (Bluetooth, WiFi, IEEE, ANT, etc.) dans un seul chipset.

Je commencerais par Bluetooth, c'est la solution IMHO la plus simple et la plus polyvalente. Bien que je ne sois pas sûr de la triangulation locale, cela semble être une surpuissance pour vos besoins, peut-être cherchez des balises Bluetooth.

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.