Utilisation de microcontrôleurs basse consommation avec des modes veille et réveil sur événement

Dans certains cas, remplacement pur et simple des capteurs usés plutôt que de changer leurs batteries

Protocoles de sécurité allégés pour limiter la consommation

Suppression de la sécurité pour économiser l’énergie

Communication optimisée (envoi par lots, protocoles légers comme LoRa ou BLE)

Pour augmenter sa portée radio de communication

Pour sauvegarder des paramètres système ou des identifiants

Pour réduire le nombre de transmissions et ainsi économiser de l’énergie

Pour continuer à fonctionner même en mode déconnecté (offline)

Pour enregistrer temporairement des données issues des capteurs ou des journaux (logs)

Vrai

Faux

l'RTC est toujours externe

l'RTC a un grand impact sur la consommation de l'énergie de l'objet connecté

L’RTC peut réveiller le microcontrôleur à intervalles précis sans que celui-ci consomme d’énergie en permanence.

L’RTC fonctionne uniquement lorsque le microcontrôleur est alimenté.

Améliorer la portée radio et la qualité du signal

Réduire la consommation électrique du microcontrôleur

Offrir plus de flexibilité dans le placement, par exemple si le boîtier est métallique

Permettre une meilleure directivité en orientant le signal

S’adapter à différents protocoles et bandes de fréquences

L’hébergement peut se faire sur un serveur local ou dans le cloud.

Pour communiquer avec les objets, un dashboard doit toujours utiliser des protocoles propriétaires, les API REST ou MQTT ne suffisent pas.

Il sert à visualiser des données ; il ne peut pas envoyer de commandes aux objets.

Il peut inclure des alertes et notifications pour informer les utilisateurs d’événements critiques.

Le cloud permet de centraliser le stockage et le traitement des données de nombreux objets connectés.

Les objets connectés n’ont jamais besoin de traitement local si le cloud est utilisé.

Le cloud facilite l’accès aux dashboards et aux applications depuis n’importe où.

L’utilisation du cloud peut introduire de la latence pour des décisions temps réel critiques.

Permet de réduire la latence et la consommation de bande passante vers le cloud

Peut traiter des données critiques localement pour déclencher des actions instantanées

Ne peut inclure aucune fonction de chiffrement

Peut inclure des fonctions d'agrégation simples.

Le fog est une couche intermédiaire entre le cloud et les objets connectés

Le fog computing est identique à l’edge computing et n’a aucune différence conceptuelle

Peut fusionner les données de plusieurs edges

peut améliorer la réactivité et réduire le trafic réseau vers le cloud.

La fonction setup() s’exécute une seule fois au démarrage du microcontrôleur.

La fonction loop() contient la logique répétitive et s’exécute en boucle infinie.

Les bibliothèques et variables globales servent uniquement à initialiser les capteurs.

Cette organisation est commune à toutes les cartes Arduino.

On y inclut les bibliothèques nécessaires (#include) pour capteurs, Wi-Fi, Bluetooth, etc.

Elle sert à initialiser les périphériques matériels

Cette partie s’exécute en boucle infinie après setup().

On y définit des variables et objets accessibles dans tout le programme.

Elle s’exécute une seule fois au démarrage du microcontrôleur.

Elle permet d’initialiser les périphériques, capteurs, modules de communication.

Elle contient la logique répétitive et les traitements continus.

Elle est obligatoire dans tous les programmes Arduino/ESP32.

Elle s’exécute en boucle infinie après la fin de setup().

Elle s’exécute une seule fois au démarrage.

Elle peut fonctionner en parallèle avec d'autres tâches.

Elle contient les tâches répétitives comme lecture des capteurs, contrôle des actionneurs, envoi de données.