Intégration Arduino Azure IoT Edge

Utilisez cette skill lorsque l'utilisateur a besoin de connecter des appareils de classe Arduino à Azure IoT, en particulier dans des scénarios edge-heavy (passerelles, réseaux intermittents, mise en cache hors ligne et actuation locale).

Quand l'utiliser

Utilisez cette skill pour des demandes comme :

• « Je veux connecter des capteurs Arduino à Azure »
• « Comment envoyer de la télémétrie MQTT à IoT Hub ? »
• « J'ai besoin d'une passerelle edge pour les appareils de terrain »
• « Je veux des commandes cloud-vers-appareil et des mises à jour OTA de configuration »

Examen obligatoire de la documentation

Avant de recommander une topologie IoT Edge ou un comportement d'exécution, examinez :

• https://learn.microsoft.com/azure/iot-edge/

Si la documentation ne peut pas être consultée, procédez avec des hypothèses explicites et mettez-les en évidence dans une section dédiée.

Références Arduino officielles et bonnes pratiques (obligatoires)

Avant de proposer des détails de firmware, de câblage ou d'implémentation de communication, consultez d'abord les sources Arduino officielles :

• https://www.arduino.cc/en/Guide
• https://docs.arduino.cc/
• https://docs.arduino.cc/language-reference/
• references/arduino-official-best-practices.md

Lors du choix entre différentes alternatives d'implémentation, privilégiez les conseils Arduino officiels par rapport aux snippets communautaires sauf s'il y a une raison technique claire de dévier.

Objectifs

• Produire un chemin de référence sécurisé de bout en bout du dispositif Arduino aux insights cloud.
• Gérer les liaisons instables (store-and-forward, retries, idempotence).
• Définir un backlog d'appareil et cloud actionnable.

Modèles d'intégration

Modèle A : Arduino directement vers IoT Hub

À utiliser quand la connectivité est stable et la latence cloud acceptable.

• Protocole : MQTT sur TLS.
• Identité : credentials par appareil (SAS ou X.509).
• Payload de télémétrie : JSON compact avec timestamp, ID d'appareil, métriques et drapeaux de qualité optionnels.

Modèle B : Arduino vers passerelle locale, puis IoT Edge

À utiliser quand les liaisons sont contraintes, le contrôle local est requis, ou le batching améliore le coût/la fiabilité.

• Arduino communique avec une passerelle locale (série, BLE, MQTT local, RS-485, pont Modbus).
• La passerelle publie en amont via le runtime IoT Edge et achemine les données vers IoT Hub.
• Les modules locaux peuvent filtrer, agréger et déclencher des actions même lors de pannes cloud.

Flux de conception

1) Contrat d'appareil

Définissez :

• Catalogue de capteurs et unités.
• Fréquence d'échantillonnage et débit attendu.
• Stratégie de versioning du schéma de message.
• Propriétés du jumeau d'appareil souhaité/rapporté pour contrôler le comportement d'exécution.

2) Ligne de base de sécurité

Exigez :

• Identité unique par appareil.
• Aucun secret en dur dans le code source ou les artefacts firmware.
• Stratégie de rotation des credentials.
• Firmware signé et processus de mise à jour contrôlé si possible.

3) Fiabilité et comportement hors ligne

Planifiez et documentez :

• Backoff avec jitter.
• Stratégie de file d'attente/buffer locale avec taille bornée.
• Suppression des doublons ou traitement idempotent en aval.
• Fallback vers la dernière bonne configuration connue.

4) Routage cloud et edge

Définissez les routes pour :

• Télémétrie brute vers le stockage froid.
• Télémétrie curée vers l'analytique chaud.
• Alertes vers les canaux opérationnels.
• Commandes et configuration en retour vers edge/appareil.

5) Observabilité

Spécifiez la télémétrie opérationnelle minimale :

• Heartbeat d'appareil et version du firmware.
• Transitions d'état de connectivité.
• Compteurs de succès/erreur d'envoi de messages.
• Santé du module de passerelle et raisons de redémarrage.

Réutiliser d'autres skills

Quand approprié, combinez avec :

• azure-smart-city-iot-solution-builder pour l'architecture à l'échelle de la ville et le déploiement par phases.
• azure-resource-visualizer pour les diagrammes de relations.
• appinsights-instrumentation pour les modèles de télémétrie d'app et de service.

Utilisez aussi references/arduino-official-best-practices.md comme ligne de base de qualité pour les recommandations de firmware et matériel.

Sortie requise

Fournissez toujours :

1. Modèle de connectivité choisi et justification.
2. Contrat de message (champs, unités, exemple de payload).
3. Checklist de sécurité pour l'identité/credentials/mises à jour.
4. Plan de fiabilité (retry, buffering, dedupe).
5. Backlog d'implémentation (firmware, passerelle, cloud).

Modèle de sortie

1. Scénario et hypothèses
2. Architecture recommandée
3. Contrat d'appareil et de passerelle
4. Contrôles de sécurité et fiabilité
5. Plan de déploiement et tests de validation

Directives

• Ne proposez pas de déploiements en production avec des credentials partagés entre les appareils.
• Ne supposez pas une connectivité toujours active dans les déploiements de terrain.
• N'omettez pas l'autorisation de commandes et l'audit dans les scénarios d'actuation.