[Arduino] Module Bluetooth

 Le Bluetooth est un standard de communication qui permet l’échange de données bidirectionnel à très courte distance et qui utilise des ondes radio UHF.

Le module utilisé est un Bluetooth HC-05 ou « HC 05 » ; son code d’appareillage est « 1234 ».

Afin de sécuriser ce module, nous allons effectuer la modification du nom et du code. Nous allons utiliser des commandes AT (ATtention) afin d’effectuer la configuration.

1. Présentation du HC 05

Le module présente 6 broches pour permettre d’établir la connexion.

• VCC broche d’alimentation. Typiquement connectée à la broche 5V de l’Arduino.
• GND masse. Typiquement connectée à la broche GND de l’Arduino
• RX broche de réception. Typiquement connecté à la broche de transmission (TX) de l’Arduino
• TX broche de transmission. Typiquement connecté à la broche de réception (RX) de l’Arduino
• State retourne 1 lorsque le module est connecté
• Key ou EN doit être alimentée pour entrer dans le mode de configuration et ne doit pas être connecté pour être en mode communication.

La particularité du module est qu’il peut être utilisé en mode esclave (dans ce cas il est équivalent à un module HC-06 et s’utilise de la même manière) ou en mode maître, ce qui veut dire qu’il peut de manière autonome se connecté à un autre module Bluetooth.

2. Câblage du module avec l'Arduino

On commence par injecter le programme suivant. Attention, la vitesse est de 38400 Bauds.

Démarche de câblage :

Une fois le câblage précédent effectué, la LED du module Bluetooth doit normalement clignoter rapidement

• Débrancher le fil 5V <-> VCC
• Appuyer et maintenir le poussoir sur le module Bluetooth
• Rebrancher le fil 5V <-> VCC
• Relâcher le bouton poussoir du module Bluetooth
• La LED du module doit clignoter lentement (toutes les 2s)

Dans le moniteur série, vous devez déjà sélectionner « NL et CR » puis envoyer le message AT, et attendre la réponse OK.

Configuration :

Il est donc possible de changer le nom du module Bluetooth et son password.

Changer le nom : AT+NAME=Votre_Nom

Changer le password: AT+PSWD=Votre_Nom

Attention, il faut utiliser 12 caractères maximum et ne pas utiliser de lettres accentuées, ni d’espaces.

Par défaut, le nom est HC-05 et le pin est 1234.

Une fois le changement effectué (le module nous répond OK) :

• Débrancher le fil KEY
• Débrancher et rebrancher la carte Arduino
• Vérifier avec son smartphone en se connectant au module Bluetooth (par l’intermédiaire de la configuration Bluetooth de votre mobile Android).

Si les changements ne sont pas visibles, redémarrer l’étape de configuration.

Remarques :

Il existe d'autres commandes comme :

• AT+ROLE=<Param> pour modifier le rôle du module esclave ou maître (Ex: pour passer le module en maître AT+ROLE=1).
• AT+UART=<Param1>,<Param2>,<Param3> avec Param1, 2 et 3 les paramètres de communication série: le baud rate, le bit d’arrêt et le bit de parité  respectivement. (Par défaut, 9600,0,0. Ex: si vous voulez changer le baudrate en 115200 tapez AT+UART=115200,0,0).

Plus d'informations par ici

3. Exemple de code en mode esclave

Le module HC-05 sera connecté en esclave à une application smartphone.

[IT] Problème d'espace sur support amovible

 Il arrive que suite à des formatages voter clé USB (ou autre) n'affiche plus la capacité d'origine, mais complètement aberrante (par exemple 400 ou 500 Mo).

La capacité de stockage peut être rétablie par l'utilisation de 'Disk part'.

Attention : avant d'essayer cette méthode, assurez-vous qu'il n'y a pas de fichiers importants sur la clé USB pour éviter une perte de données.

•  Connectez la clé USB qui n'a plus sa capacité d'origine à votre ordinateur.
• Tapez « diskpart » dans la zone Exécuter, puis appuyez sur Entrée.

• Tapez « list disk » dans l'invite de commande pour afficher tous les disques en ligne.
• Choisissez votre USB en tapant la commande « select disk ». Ici, j'utilise « select disk 1 ».
• Tapez « clean » pour supprimer toutes les données sur la clé USB.
• Tapez « create partition primary » pour créer une nouvelle partition sur la clé USB.

Il arrive que l'opération échoue. Dans ce cas, je réalise l'opération une seconde fois.

[Electro] Protocole RS232

Le RS-232 (parfois appelée EIA RS-232, EIA 232 ou TIA 232) est une norme standardisant une voie de communication de type série. Disponible sur presque tous les PC depuis 1981 jusqu'au milieu des années 2000, il est communément appelé le « port série ». 

Sur les systèmes d'exploitation MS-DOS et Windows, les ports RS-232 sont désignés par les noms COM1, COM2, etc. Cela leur a valu le surnom de « ports COM », encore utilisé de nos jours. Il est graduellement remplacé par le port USB depuis l'apparition de ce dernier.

1. Historique :

Le protocole d'origine, RS-232, a été standardisé par l'EIA (Electronic Industries Alliance) en 1962. Des déclinaisons ont suivi, notamment les RS-232C en 1969 et RS-232D en 19864. Peu à peu tombé dans l'obsolescence, il finit par être remplacé par les ports USB et FireWire4 dans les années 2000.

Toutefois, les liaisons RS-232 sont encore utilisées dans l'industrie pour connecter différents appareils électroniques (automate, appareil de mesure, etc.).

2. Description :

Le standard RS-232 permet une communication sérielle, asynchrone et duplex entre deux équipements. La transmission des éléments d'information (ou bit) s'effectue bit par bit, de manière séquentielle.

La connectique de cette liaison se présente fréquemment sous la forme du connecteur DB-9 ou DB-25, mais peut aussi être d'un autre type (RJ25). Seule la version DB-25 est vraiment standardisée, la DB-9 est une adaptation d'IBM lors de la création du PC AT.

3. Protocole :

Pour établir une communication effective via RS-232, il est nécessaire de définir le protocole utilisé : notamment, le débit de la transmission, le codage utilisé, le découpage en trame, etc. La norme RS-232 laisse ces points libres, mais en pratique on utilise souvent des UART qui découpent le flux en trames d'un caractère ainsi constituées :

• 1 bit de départ ;
• 7 à 8 bits de données ;
• 1 bit de parité optionnel ;
• 1, 1.5 ou 2 bits d'arrêt.

Le bit de départ a un niveau logique "0" tandis que le bit d'arrêt est de niveau logique "1". Le bit de donnée de poids faible est envoyé en premier suivi des autres (on parle de "MSB" pour "Most Significant Bit" et de "LSB" pour "Least Significant Bit"). 

La spécification RS-232 prescrit des débits inférieurs à 20 000 bit/s. Cependant, les débits utilisés en pratique varient entre 75 bit/s et 115 200 bit/s.

4. Signal électronique :

Un niveau logique "0" est représenté par une tension de +3 V à +25 V et un niveau logique "1" par une tension de −3 V à −25 V (codage NRZ). D'ordinaire, des niveaux de +12 V et −12 V sont utilisés.

Il existe une "zone morte" allant de +3 V à -3 V qui est destinée à l'adsorption du bruit de ligne. Cependant, cette plage peut être différente. Par exemple, la définition V.10 a une "zone morte" de +0.3 V à -0.3 V.

La norme V.28 indique qu'un "0" est reconnu si la tension est supérieure à +3 V et qu'un "1" est reconnu si la tension est inférieure à −3 V

5. Limitations :

Le protocole RS-232 présente de sérieuses limitations en termes de performances de portée et de débit de données.

[IT] OPC-UA

 

Plus connu sous l’acronyme OPC UA, le protocole 'OPen Connectivity – Unified Architecture' est un standard d’échange de données adapté aux besoins des systèmes industriels. Il est particulièrement dédié à l’Internet Industriel des Objets (IoT ou IIoT).

1. Historique :

La norme OPC est maintenue par la fondation OPC, consortium industriel regroupant un ensemble hétéroclite de constructeurs qui crée et maintient les standards et les normes de l’automation.

Hormis la standardisation du dialogue entre machines et systèmes d’information, le protocole OPC-UA est d’abord élaboré pour la sécurisation des flux de données lors des échanges intra et/ou inter-équipements d’automatisme industriel.

Il est important de préciser que c’est un standard ouvert. Il est par exemple possible de partir du projet Open62541 directement disponible sur la plateforme de gestion de code source github. Cette version est écrite en C99 et C++. Mais il existe aussi des partages plus officiel comme l’OPC Foundation qui propose des librairies en .NET.

2. Architecture :

Ce protocole repose sur le principe de client-serveur. Un serveur OPC est un logiciel adapté à un ou plusieurs constructeurs d’automates/machines. Un serveur OPC "sert" des données au client qui les "réclame".

Le plus souvent installé sur le même serveur que l’application, ce serveur client se connecte aux automates par l’intermédiaire d’un réseaux Ethernet "classique".

Le client va sélectionner, trier et traduire les informations renvoyées par l’automate pour les traiter dans son logiciel.

Comme les serveurs peuvent à la fois être des clients eux-mêmes, ils peuvent aussi collecter et compiler des données d’autres serveurs à leurs propres clients, et ainsi de suite. Les informations échangées s’adaptent à chaque équipement.

3. Avantages :

• Un standard ouvert
• Il est conçu pour l’interopérabilité
• Son concept de "Publisher/subscriber"
• Il est conçu sur une architecture orientée service appelée SOA (Service oriented Architecture)
• La sécurité de transmission a été intégrée dès sa conception que ce soit au niveau de l’authentification ou lors des échanges de données
• Il est flexible et évolutif grâce aux nombreuses implémentations que ce soit en C/C++ mais aussi en Java, .NET, NodeJS ou encore Python
• Une large compatibilité dans l'industrie actuelle
• De grands industriels ont dores et déjà implémentés cette norme

[IT] MQTT

Plus connu sous l’acronyme MQTT, le protocole 'Message Queuing Telemetry Transport' est un protocole de messagerie léger adapté aux clients qui doivent utiliser peu de code et sont connectés à des réseaux peu fiables ou limités en bande passante.

1. Historique :

Créé par Andy Stanford-Clark et Arlen Nipper en 1999, MQTT est un protocole de messagerie qui, à son origine, visait à permettre aux capteurs utilisés dans l’industrie pétrolière et gazière d’envoyer leurs données à des serveurs distants. À l’époque, la seule solution pour ces cas de figure était la liaison satellite, une option extrêmement onéreuse. Les acteurs de l’industrie, qui avaient déployé des milliers de capteurs sur le terrain, avaient besoin d’un mode de communication capable de transmettre des données avec toute la fiabilité requise, tout en consommant un minimum de bande passante.

MQTT a été standardisé en tant que format ouvert par l’Organization for the Advancement of Structured Information Standards en 2013. À ce jour, l’OASIS gère encore le standard MQTT.

2. Architecture :

MQTT est un protocole de messagerie 'push-subscribe' basé sur le protocole TCP/IP. Dans l’architecture MQTT, il existe deux types de systèmes : les clients et les brokers (courtiers). 

Le broker est le serveur avec lequel les clients communiquent. Il reçoit les communications qui émanent des clients et les retransmet à d’autres clients. Ainsi, les clients ne communiquent pas directement entre eux, mais toujours par l’intermédiaire du broker. Chaque client peut être soit éditeur, soit abonné, soit les deux.

MQTT est un protocole orienté événements. Afin de minimiser le nombre de transmissions, les données ne sont envoyées ni à intervalles définis, ni en continu. Un client publie uniquement quand il a des informations à transmettre, et un broker n’envoie des informations aux abonnés que quand il reçoit de nouvelles données.

3. Architecture messages :

MQTT minimise également ses transmissions grâce à un système de messages à la construction allégée et bien cadrée. Chaque message se compose d’un en-tête fixe de 2 octets, auquel peut s’ajouter un en-tête facultatif. La charge utile des messages est, pour sa part, limitée à 256 Mo. Les trois niveaux de qualité de service laissent aux concepteurs de réseau le choix de minimiser le nombre de transmissions de données ou d’en maximiser la fiabilité. On parlera de 'QoS' (Quality of Service).

QoS 0 — c’est le niveau minimal de transmission de données. Quand on choisit ce niveau de QoS, chaque message est envoyé à l’abonné une seule fois, sans accusé de réception. Il est donc impossible de savoir si l’abonné l’a reçu. Dans ce niveau de qualité de service, les messages sont expédiés « au plus une fois ». Comme ce niveau de QoS part du principe que les messages sont systématiquement remis, ces derniers ne sont pas conservés en vue d’un envoi ultérieur aux clients qui seraient déconnectés au moment de leur transmission.

QoS 1 — le broker tente de remettre le message, puis attend un accusé de réception de la part de l’abonné. Si cet accusé n’est pas reçu dans le délai défini, le message est réexpédié. Avec cette méthode, l’abonné peut recevoir le message plus d’une fois si le broker ne reçoit pas de confirmation de réception dans le temps imparti. Dans ce niveau de QoS, les messages sont assurés d’arriver « au moins une fois ».

QoS 2 — le client et le broker utilisent deux paires de paquets pour s’assurer que le message a été remis, et pour vérifier qu’il n’a été reçu qu’une seule fois. Dans ce niveau de QoS, les messages sont assurés d’arriver « exactement une fois ».

4. Rubriques :

Sous MQTT, les messages sont publiés en tant que topics (rubriques), c’est-à-dire de structures hiérarchisées qui utilisent le caractère slash (/) comme délimiteur. Ces structures ressemblent à l’arborescence de l’explorateur Windows. 

Ainsi, une structure de type 'capteurs/PétroleetGaz/Pression/' permet à un abonné de préciser qu’il souhaite ne recevoir que les données émanant des clients publiant dans la rubrique Pression, ou peut-être, s’il souhaite élargir ses horizons, toutes les données du rubrique 'capteurs/PétroleetGaz'. 

Les rubriques ne sont pas créées sous MQTT à proprement parler : si un broker reçoit des données publiées sur une rubrique qui n’existe pas à ce moment-là, celle-ci sera automatiquement créée, après quoi les clients pourront s’y abonner.

5. Messages conservés :

Pour alléger au maximum le protocole, les messages reçus ne sont pas conservés sur le broker, sauf à ce qu’ils soient indiqués comme "conservés". On parle alors de messages conservés. Les utilisateurs qui veulent sauvegarder les messages qu’ils reçoivent devront le faire en dehors de MQTT. Il y a toutefois une exception à la règle.

6. Sécurité :

MQTT facilite le chiffrement des messages à l'aide de la couche de sécurité TLS et l'authentification des clients à l'aide de protocoles d'authentification modernes, tels que OAuth.

Certaines options de sécurité sont toutefois disponibles, au prix toutefois d’une augmentation du nombre de transmissions et du poids des données.

Sécurité réseau – Si l’on sécurise le réseau alors les transmissions de données MQTT non sécurisées est sans gravité. Dans un tel cas de figure, d’éventuels problèmes de sécurité proviendraient du réseau lui-même.

Identifiant et mot de passe — MQTT intègre un système d’identifiants et de mots de passe qui permet aux clients d’établir une connexion avec un broker. Cela étant, on déplorera que les identifiants et mots de passe soient transmis en clair.

SSL/TLS – Comme MQTT est basé sur TCP/IP, le protocole SSL/TLS apparaît comme la solution logique pour sécuriser les transmissions entre les clients et les brokers. Malheureusement, son recours alourdit nettement la charge d’un protocole dont la vocation première est de rester léger.

7. Mosquitto :

Mosquitto est le broker le plus souvent utilisé pour les projets ESP8266 (Arduino et Raspberry). Lancé en 2008, il est disponible sur toutes les plateformes (MacOS, Windows XP-10, Linux). Deux méthodes sont possibles pour l'installer : depuis le terminal d'un ordinateur, avant de le lancer depuis le terminal, ou de l'installer en utilisant putty (SSH) et en accédant au Root.

Sources : MQTT_1, MQTT_2, MQTT_3