azure iot sdk c
LTS_08_2024
Le SDK de périphérique Azure IOT Hub permet aux applications écrites en C99 ou version ultérieure ou en C++ de communiquer facilement avec Azure IoT Hub, Azure IoT Central et Azure IoT Device Provisioning. Ce référentiel comprend le code source des bibliothèques, les instructions de configuration et des exemples illustrant des scénarios d'utilisation.
Pour les appareils limités , où la mémoire est mesurée en kilo-octets et non en mégaoctets, des options de SDK encore plus légères sont disponibles. Consultez Autres SDK Azure IoT pour en savoir plus.
Il est conseillé à tous les utilisateurs du SDK Azure IoT d’être informés des prochaines modifications du certificat TLS pour Azure IoT Hub et Device Provisioning Service qui auront un impact sur la capacité du SDK à se connecter à ces services. En octobre 2022, les deux services migreront de la racine actuelle de Baltimore CyberTrust CA vers la racine DigiCert Global G2 CA. Il y aura une période de transition au préalable au cours de laquelle vos appareils IoT devront disposer des certificats publics Baltimore et Digicert qui pourront être codés en dur dans leur application ou flashés sur votre module WiFi afin d'éviter les problèmes de connectivité.
Les appareils dotés uniquement du certificat public Baltimore perdront la possibilité de se connecter à Azure IoT Hub et au service de provisionnement d’appareils en octobre 2022.
Pour vous préparer à ce changement, assurez-vous que la pile TLS de votre appareil dispose de ces deux certificats racine de confiance publics configurés.
Pour une explication plus détaillée de la raison pour laquelle les services IoT font cela, veuillez consulter cet article.
Veuillez noter que pour les scénarios de périphériques contraints tels que mbed et Arduino, il existe des options SDK meilleures et plus légères. Consultez Autres SDK Azure IoT pour en savoir plus.
Le moyen le plus simple de démarrer avec les SDK Azure IoT sur les plateformes prises en charge consiste à utiliser les packages et bibliothèques suivants :
Arduino : bibliothèque SDK de périphérique dans l'IDE Arduino
Windows : SDK de périphérique sur Vcpkg
iOS : SDK de périphérique sur CocoaPod
Limites d'iOS
Pour une expérience iOS plus complète incluant les deux fonctionnalités manquantes ci-dessus, veuillez consulter notre exemple de bibliothèque Swift native construite sur le SDK Embedded C.
Pour les autres plates-formes, y compris Linux, vous devez cloner et créer le SDK directement. Vous pouvez également le créer directement pour les plateformes ci-dessus.
De nombreux exemples sont disponibles pour le SDK. Plus d’informations peuvent être trouvées ici.
La documentation de référence de l'API pour les SDK C peut être trouvée ici.
Pour trouver des SDK Azure IoT dans d’autres langues, veuillez consulter les instructions ici.
Pour en savoir plus sur la création d’applications Azure IoT, vous pouvez visiter le Centre de développement Azure IoT.
IoT Hub prend en charge plusieurs protocoles avec lesquels l'appareil peut se connecter : MQTT, AMQP et HTTPS. MQTT et AMQP peuvent éventuellement s'exécuter sur WebSockets. Le SDK Device Client permet de choisir le protocole au moment de la création de la connexion.
Le SDK client appareil/module permet en option la création d’appareils IoT Plug and Play.
Si vous ne savez pas quel protocole utiliser, vous devez utiliser MQTT ou MQTT-WS. MQTT nécessite beaucoup moins de ressources que AMQP et prend en charge beaucoup plus de fonctionnalités IoT Hub que HTTPS. Ni AMQP ni HTTPS ne sont assurés d'avoir des implémentations du SDK Device Client pour les nouvelles fonctionnalités à venir, telles que Azure IoT Plug and Play.
✔️ fonctionnalité disponible ✖️ fonctionnalité prévue mais non supportée ➖ aucun support prévu
| Caractéristiques | mqtt | mqtt-ws | amqp | amqp-ws | https | Description |
|---|---|---|---|---|---|---|
| Authentification | ✔️ | ✔️* | ✔️ | ✔️* | ✔️* | Connectez votre appareil à IoT Hub en toute sécurité grâce à l'authentification prise en charge, notamment la clé privée, SASToken, X-509 auto-signé et l'autorité de certification (CA) signée. *IoT Hub ne prend actuellement en charge que X-509 CA signé via AMQP et MQTT. |
| Envoyer un message de l'appareil au cloud | ✔️* | ✔️* | ✔️* | ✔️* | ✔️* | Envoyez des messages appareil vers cloud (256 Ko maximum) à IoT Hub avec la possibilité d’ajouter des propriétés personnalisées. Pour le moment, IoT Hub ne prend en charge que les envois par lots via AMQP et HTTPS. Ce SDK prend en charge l'envoi par lots via HTTP. * L'envoi par lots via AMQP et AMQP-WS et l'ajout de propriétés système sur les messages D2C sont en cours. |
| Recevez des messages du cloud à l'appareil | ✔️* | ✔️* | ✔️ | ✔️ | ✔️ | Recevez des messages cloud vers appareil et lisez les propriétés personnalisées et système associées depuis IoT Hub, avec la possibilité de compléter/rejeter/abandonner les messages C2D. *IoT Hub prend en charge l'option permettant de compléter/rejeter/abandonner les messages C2D via HTTPS et AMQP uniquement pour le moment. |
| Jumeaux d'appareil | ✔️* | ✔️* | ✔️* | ✔️* | ➖ | IoT Hub conserve un jumeau d’appareil pour chaque appareil que vous connectez à IoT Hub. L'appareil peut effectuer des opérations telles que obtenir des balises jumelles, s'abonner aux propriétés souhaitées. *L'envoi de la version des propriétés signalées et de la version des propriétés souhaitées est en cours. |
| Méthodes directes | ✔️ | ✔️ | ✔️ | ✔️ | ➖ | IoT Hub vous offre la possibilité d'appeler des méthodes directes sur des appareils depuis le cloud. Le SDK prend en charge le gestionnaire pour les opérations génériques et spécifiques à une méthode. |
| Télécharger un fichier vers un blob | ➖ | ➖ | ➖ | ➖ | ✔️ | Un appareil peut lancer un téléchargement de fichier et avertir IoT Hub lorsque le téléchargement est terminé. Le téléchargement de fichiers nécessite une connexion HTTPS, mais peut être lancé à partir du client en utilisant n'importe quel protocole pour d'autres opérations. |
| État de la connexion et rapport d'erreurs | ✔️* | ✔️* | ✔️* | ✔️* | ✖️ | Rapport d’erreurs pour le code d’erreur pris en charge par IoT Hub. *Ce SDK prend en charge le rapport d'erreurs sur l'authentification et le périphérique introuvable. |
| Réessayer les stratégies | ✔️* | ✔️* | ✔️* | ✔️* | ✖️ | La stratégie de nouvelle tentative pour les messages appareil-cloud infructueux propose deux options : aucun essai, interruption exponentielle avec instabilité (par défaut). *Une politique de nouvelle tentative personnalisée est en cours. |
| Multiplexage d'appareils sur une seule connexion | ➖ | ➖ | ✔️ | ✔️ | ✔️ | Il existe plus de limitations au multiplexage que ce qui est indiqué dans ce tableau. Consultez ce document pour plus d'informations. |
| Pooling de connexions - Spécification du nombre de connexions | ➖ | ➖ | ✖️ | ✖️ | ✖️ | |
| Prise en charge Plug-and-Play d'Azure IoT | ✔️ | ✔️ | ➖ | ➖ | ➖ | Possibilité de créer des appareils Azure IoT Plug and Play. |
Ce SDK contient également des options que vous pouvez définir et des fonctionnalités spécifiques à la plate-forme. Vous pouvez trouver la liste détaillée dans ce document.
Ce référentiel contient le SDK client de provisionnement pour le service de provisionnement de périphériques.
✔️ fonctionnalité disponible ✖️ fonctionnalité prévue mais non supportée ➖ aucun support prévu
| Caractéristiques | mqtt | mqtt-ws | amqp | amqp-ws | https | Description |
|---|---|---|---|---|---|---|
| Inscription individuelle au TPM | ➖ | ➖ | Nous annonçons l’abandon de la prise en charge de la bibliothèque utpm-c et de la prise en charge de l’authentification DPS-TPM au sein du C-SDK Azure IoT. À partir de mai 2023, Microsoft ne fournira plus de support pour cette bibliothèque. Les applications existantes utilisant cette bibliothèque continueront de fonctionner telles quelles. Nous vous recommandons fortement de passer à l'authentification DPS-X509 à l'aide du moteur OpenSSL tpm2tss. La connexion de votre appareil au service Device Provisioning via une inscription individuelle à l’aide du module Trusted Platform continuera à fonctionner telle quelle. Ce démarrage rapide explique comment créer un appareil simulé pour une inscription individuelle avec TPM. TPM sur MQTT n’est actuellement pas pris en charge par le service Device Provisioning. | |||
| X.509 Inscription individuelle | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | Ce SDK prend en charge la connexion de votre appareil au service Device Provisioning via une inscription individuelle à l'aide d'un certificat feuille X.509. Ce démarrage rapide explique comment créer un appareil simulé pour un enregistrement individuel avec X.509. |
| Groupe d'inscription X.509 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | Ce SDK prend en charge la connexion de votre appareil au service Device Provisioning via un groupe d'inscription à l'aide du certificat racine X.509. |
Le SDK de l’appareil IoT Hub pour C peut être utilisé avec une large gamme de plates-formes et d’appareils de système d’exploitation.
La configuration minimale requise est que la plate-forme de l'appareil prenne en charge les éléments suivants :
Les détails de la prise en charge de la plateforme peuvent être trouvés dans ce document. Vous pouvez trouver une liste exhaustive des plates-formes de système d’exploitation sur lesquelles les différents SDK ont été testés dans le catalogue d’appareils Azure Certified for IoT. Notez que vous pourrez peut-être toujours utiliser les SDK sur des systèmes d'exploitation et des plates-formes matérielles qui ne sont pas répertoriés sur cette page : tous les SDK sont open source et conçus pour être portables. Si vous avez des suggestions, des commentaires ou des problèmes à signaler, reportez-vous aux sections Contribution et Assistance ci-dessous.
Les SDK et bibliothèques C :
Dans le référentiel, vous trouverez des instructions et des outils de création pour compiler et exécuter le SDK du client de périphérique pour C sur les plates-formes Linux, Windows et microcontrôleurs (reportez-vous aux liens ci-dessus pour plus d'informations sur la compilation du client de périphérique pour C).
Si vous envisagez de porter le SDK client de périphérique pour C vers une nouvelle plate-forme, consultez le document guide de portage.
MBED OS
Voir également les dossiers obsolètes ci-dessous pour d'autres notes pertinentes.
Si vous rencontrez des bugs, avez des suggestions de nouvelles fonctionnalités ou si vous souhaitez devenir un contributeur actif à ce projet, veuillez suivre les instructions fournies dans les directives de contribution.
/c-utility, /deps, /umqtt, /uamqp -
Ce sont des sous-modules git qui contiennent du code, tel que des adaptateurs et des implémentations de protocoles, partagés avec d'autres projets.
/build, /build_all
Créez et enregistrez les dossiers liés à la porte.
/certs
Contient les certificats nécessaires pour communiquer avec Azure IoT Hub.
/doc
Ce dossier contient des guides de développement d'applications et des instructions de configuration des appareils.
/iothub_client
Contient les composants clients Azure IoT Hub qui fournissent les fonctionnalités de messagerie brute de la bibliothèque. Reportez-vous à la documentation et aux exemples de l'API pour savoir comment l'utiliser.
/provisioning_client
Ce dossier contient la bibliothèque client pour le client de provisionnement des appareils.
/samples
Contient des exemples illustrant des scénarios E2E plus complexes à l’aide du SDK.
/testtools
Contient les outils utilisés pour tester les bibliothèques.
/tools
Outils divers.
Les dossiers suivants sont obsolètes.
/iothub_service_client
Contient des bibliothèques qui permettent aux interactions avec le service IoT Hub d'effectuer des opérations telles que l'envoi de messages aux appareils et la gestion du registre d'identité des appareils.
/provisioning_service_client
Contient des bibliothèques qui permettent les interactions avec le service Device Proviosining pour effectuer des opérations telles que la définition d'une stratégie autour des inscriptions.
/serializer
Contient des bibliothèques qui fournissent des fonctionnalités de modélisation et de sérialisation JSON en plus de la bibliothèque de messagerie brute.
Le SDK C propose des versions pour de nouvelles fonctionnalités, des corrections de bogues critiques et un support à long terme (LTS). Les corrections de bugs généraux ne recevront pas de version distincte, mais seront contenues dans la version LTS. Le contrôle de version suit le contrôle de version sémantique, xyz ou major.minor.patch . Chaque fois que la version est mise à jour, elle sera étiquetée xyz .
De nouvelles fonctionnalités et corrections de bugs critiques (y compris des mises à jour de sécurité) seront publiées sur la branche principale. Ces versions seront étiquetées en utilisant la date au format yyyy-mm-dd . Une version de fonctionnalité supprimera la version minor et réinitialisera la version patch à 0. Une correction de bogue critique supprimera uniquement la version patch .
Les nouvelles versions LTS dérivent de main et seront étiquetées LTS_ . Une nouvelle version LTS héritera de la version de la branche principale au moment de la sortie. Les branches LTS sont nommées lts_mm_yyyy pour le mois et l'année de création de la branche.
Une version LTS mise à jour se produira lorsqu'un correctif de bogue critique (y compris les mises à jour de sécurité) sera porté depuis la branche principale. Ces versions mises à jour seront étiquetées de la même manière, à l'exception d'un Ref## modifié, par exemple LTS_ . La version patch sera également modifiée. Aucune nouvelle fonctionnalité ni aucune correction de bug général ne sera portée vers une mise à jour LTS.
Vous trouverez ci-dessous un tableau montrant le mappage des branches LTS avec les packages publiés.
| Emballer | Branche GitHub | Balise LTS | Date de début du LTS | Date de fin de maintenance |
|---|---|---|---|---|
| vcpkg: 2024-08-12 | lts_08_2024 | LTS_08_2024 | 2024-08-12 | 2025-08-12 |
| vcpkg: 2024-03-04 | lts_03_2024 | LTS_03_2024 | 2024-03-04 | 2025-03-04 |
« Date de fin de maintenance » fait référence à la fin de vie du support de la version associée.
Vous trouverez ci-dessous un exemple hypothétique de gestion des versions et de balisage pour le SDK C. les versions minor se distinguent par la couleur.
1.9.0 et la version est étiquetée 2020-02-23 .LTS_07_2020 . La branche principale passe à 1.10.0 et est étiquetée 1.10.0 .2020-08-02 .1.10.1 et la version est étiquetée 2020-09-28 . Le correctif de bogue critique est porté sur la version lts LTS_07_2020 (et toute autre branche LTS existante) en créant une branche avec le nom lts_07_2020_ref02 , sa version passe à 1.9.1 et est étiquetée 1.9.1 et LTS_07_2020_Ref02 . Tous les sous-modules qui faisaient partie de la correction de bogue critique seront étiquetés avec LTS_07_2020_Ref02 .1.11.0 et la version est étiquetée 2020-12-14 .Ce projet a adopté le code de conduite Microsoft Open Source. Pour plus d’informations, consultez la FAQ sur le code de conduite ou contactez [email protected] pour toute question ou commentaire supplémentaire.
Microsoft collecte des informations sur les performances et l'utilisation qui peuvent être utilisées pour fournir et améliorer les produits et services Microsoft et améliorer votre expérience. Pour en savoir plus, consultez la déclaration de confidentialité.
