Cédrix
1 line
31 KiB
JSON
1 line
31 KiB
JSON
[{"uuid":"334bb56a-6ea0-4cbd-8cff-13af768a2b8e","slug":"teleinformation-compteur-electricite","title":"Télé-information client des compteurs d'électricité","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-19 07:03:16","created_at":"2025-11-19 07:03:16","updated_at":"2025-11-19 07:03:16","tags":[],"plain":"[Compteur électronique SAGEM S10-C4] Dans ce projet, je m'appuie sur un Rasbperry Pi pour réaliser un auto relevé. Il s'agit de retrouver un projet autour d'un Raspberry Pi pour récupérer de manière régulière et automatique les informations d'un compteur électronique d'électricité de votre distributeur d'électricité (alterna, direct energie, happ'e, proxelia, lampiris, engie, planete oui, edf, énergem, enercoop ...). On pourra relever l'intensité et la puissance instantanées, les index et quelques autres informations. Les compteurs électroniques, comme les SAGEM S10C1 S10C2 S10C3 et S10C4, possèdent une interface de communication. La réduction en volume et l'augmentation de la puissance de la micro informatique permettent de s'amuser avec ce port de communication, et faire un projet de domotique bien sympathique. Je vous invite avec une série d'articles à découvrir mes découvertes et tests. Table des matières\nIntroduction\nLe compteur électrique\n1. \n1. \n1. \nLe démodulateur\n1. \nLe Raspberry Pi\n1. \n1. \n1. \nL'ESP32\n1. \nLe protocole MQTT\n1. \nEnvoie des fichiers CSV à un service Web\n1. \n1."},{"uuid":"6f2639a5-58ed-4102-a6a2-0acbecf01de5","slug":"esp8266-commandes-at","title":"ESP8266 : prise en main des commandes AT","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 08:51","created_at":"2020-12-13 08:51:55","updated_at":"2026-05-13 18:23:54","tags":[],"plain":"Présentation\r\n\r\nL'ESP8266 est un microcontrôleur Wi-Fi développé par Espressif. Lorsqu'il sort d'usine, ou lorsqu'il est flashé avec le firmware AT officiel d'Espressif, il accepte un jeu d'instructions textuelles appelées commandes AT (ou commandes Hayes, du nom du fabricant de modems qui les a popularisées dans les années 1980).\r\n\r\nLe module ESP-01, le plus répandu pour découvrir l'ESP8266, est généralement livré avec ce firmware AT préchargé. Il est donc utilisable immédiatement, sans programmation, simplement en lui envoyant des commandes texte sur sa liaison série.\r\nPrérequis matériel : un ESP-01 connecté à un PC via un adaptateur USB-série, et un terminal série (moniteur série de l'IDE Arduino, , , PuTTY…) configuré à 115200 bauds avec fin de ligne CR+LF.\r\nNote sur les versions : la syntaxe et les codes retour des commandes AT varient selon la version du firmware. Les exemples ci-dessous correspondent à un firmware AT v1.x typique sur ESP-01. Pour les firmwares plus récents (AT v2.x sur ESP32), certaines commandes prennent des paramètres supplémentaires.\r\n\r\nTravaux pratiques\r\n\r\nL'enchaînement ci-dessous permet de mettre l'ESP-01 sur un réseau Wi-Fi, puis de le transformer en serveur HTTP minimaliste. Chaque commande est envoyée depuis le terminal série ; les lignes préfixées par représentent la réponse du module.\r\n\r\n1. Vérifier le mode Wi-Fi courant\r\n\r\n\r\n\r\nLe module répond avec un chiffre indiquant son mode courant (voir glossaire plus bas).\r\n\r\n2. Passer en mode dual (client + point d'accès)\r\n\r\n\r\n\r\nLe mode 3 active simultanément le mode station (le module se connecte à un Wi-Fi existant) et le mode AP (le module expose son propre point d'accès). C'est le mode le plus polyvalent pour expérimenter.\r\n\r\n3. Se connecter à un réseau Wi-Fi\r\n\r\n\r\n\r\nTrois événements sont remontés successivement :\r\nWIFI CONNECTED : association réussie au point d'accès ;\r\nWIFI GOT IP : adresse IP obtenue via DHCP ;\r\nOK : la commande est terminée avec succès.\r\n\r\n4. Lister les adresses IP et MAC du module\r\n\r\n\r\n\r\nEn mode dual, le module possède deux interfaces réseau :\r\nAP (point d'accès) : adresse fixe par défaut, sur laquelle se connectent les clients du Wi-Fi exposé par l'ESP ;\r\nSTA (station/client) : adresse attribuée par le routeur du réseau auquel l'ESP s'est connecté.\r\n\r\n5. Activer les connexions multiples\r\n\r\n\r\n\r\nPar défaut, l'ESP n'accepte qu'une seule connexion TCP simultanée. Le mode multi-connexion est obligatoire pour faire fonctionner le module en serveur (étape suivante).\r\n\r\n6. Démarrer un serveur TCP sur le port 80\r\n\r\n\r\n\r\nLe module écoute désormais sur le port 80 de son adresse STA. Un simple navigateur pointé sur (l'adresse retournée par ) déclenche une connexion HTTP.\r\n\r\n7. Observer une requête entrante\r\n\r\nLorsqu'un client se connecte, l'ESP recopie sur la liaison série l'événement de connexion, puis la requête HTTP brute, et enfin la fermeture de la connexion :\r\n\r\n\r\n\r\nLecture :\r\n: un client vient de s'associer ; est l'identifiant de connexion (link ID), utile en mode multi-connexion ;\r\n: l'ESP a reçu 341 octets sur la connexion ; ces octets suivent immédiatement (ici, l'en-tête HTTP envoyé par Firefox) ;\r\n: le client a fermé la connexion (ou un timeout est intervenu).\r\n\r\nÀ ce stade, l'ESP ne répond rien au client : il faut explicitement envoyer une réponse avec (voir glossaire). Le navigateur affichera donc une page vide ou un message d'erreur.\r\n\r\nPour aller plus loin : répondre au client\r\n\r\nPour renvoyer une page HTML minimale au client :\r\n\r\n\r\n\r\nLe module affiche et attend exactement le nombre d'octets annoncé, puis envoie le tout sur la connexion . Il faut ensuite fermer la connexion avec :\r\n--\r\n\r\nGlossaire des commandes AT\r\n\r\nConventions\r\n\r\nTrois formes coexistent pour la plupart des commandes :\r\nForme | Syntaxe | Rôle |\r\n---|---|---|\r\nInterrogation | | Lire la valeur courante |\r\nTest | | Lister les valeurs autorisées |\r\nAffectation | | Modifier la valeur |\r\n\r\nLes chaînes de caractères (SSID, mot de passe…) sont toujours encadrées par des guillemets droits.\r\n\r\nCommandes Wi-Fi\r\n\r\n— Mode de fonctionnement Wi-Fi\r\n\r\n\r\n\r\nValeurs de :\r\nValeur | Mode | Description |\r\n---|---|---|\r\n1 | STA | Station/client : le module se connecte à un Wi-Fi existant |\r\n2 | AP | Point d'accès : le module expose son propre Wi-Fi |\r\n3 | STA+AP | Mode dual : les deux à la fois |\r\n\r\nExemple :\r\n\r\n\r\n\r\n— Lister les points d'accès visibles\r\n\r\n\r\n\r\nRetourne une ligne par réseau détecté, sous la forme :\r\nChamp | Signification |\r\n---|---|\r\n| Chiffrement : ouvert, WEP, WPA-PSK, WPA2-PSK, WPA/WPA2-PSK |\r\n| Nom du réseau |\r\n| Puissance du signal en dBm (plus la valeur est proche de 0, plus le signal est fort) |\r\n| Adresse MAC du point d'accès (BSSID) |\r\n| Canal Wi-Fi (1 à 13 en Europe sur 2,4 GHz) |\r\n\r\nExemple :\r\n\r\n\r\n\r\nPrérequis : doit inclure le mode station (1 ou 3).\r\n\r\n— Se connecter à un point d'accès\r\n\r\n\r\n\r\nCodes d'erreur retournés en cas d'échec via :\r\nCode | Signification |\r\n---|---|\r\n1 | Délai de connexion dépassé |\r\n2 | Mot de passe incorrect |\r\n3 | SSID introuvable |\r\n4 | Échec de connexion (autre) |\r\n\r\nExemple d'échec :\r\n\r\n\r\n\r\nExemple de réussite :\r\n\r\n\r\n\r\n— Se déconnecter du point d'accès\r\n\r\n\r\n\r\nÀ ne pas confondre avec une commande de sauvegarde : signifie Quit AP, c'est-à-dire déconnexion. Les paramètres de connexion (SSID, mot de passe) sont en revanche automatiquement mémorisés en flash par les commandes et dans les versions classiques du firmware AT — le module se reconnectera donc au démarrage suivant.\r\n\r\n— Adresses IP et MAC locales\r\n\r\n\r\n\r\nRenvoie les adresses IP et MAC du module pour chaque interface active :\r\n/ : interface point d'accès (toujours par défaut) ;\r\n/ : interface station (attribuée par le DHCP du réseau rejoint).\r\n\r\nEn mode , seule la partie STA est retournée ; en mode 2, seule la partie AP.\r\n\r\nCommandes TCP/IP\r\n\r\n— Activer les connexions multiples\r\n: connexion unique (mode par défaut) ;\r\n: jusqu'à 5 connexions simultanées, chacune identifiée par un link ID de 0 à 4.\r\n\r\nPrérequis pour passer en mode 1 : aucune connexion ne doit être active, et le module ne doit pas déjà être en mode serveur.\r\n\r\n— Démarrer un serveur TCP\r\n: pour démarrer, pour arrêter ;\r\n: port d'écoute, optionnel (par défaut 333).\r\n\r\nPrérequis : doit avoir été exécuté au préalable.\r\n\r\nAprès un arrêt (), un redémarrage du module est nécessaire () pour libérer complètement le port.\r\n\r\n— Envoyer des données sur une connexion\r\n\r\n\r\n\r\nLe module affiche un prompt et attend exactement octets, puis transmet le bloc au client. Indispensable pour répondre à une requête HTTP entrante.\r\n\r\n— Fermer une connexion\r\n\r\n\r\n\r\nCommandes générales utiles\r\nCommande | Rôle |\r\n---|---|\r\n| Test de présence du module (doit répondre ) |\r\n| Redémarrer le module |\r\n| Afficher la version du firmware AT |\r\n| Changer le débit série (non persistant) |\r\n/ | Désactiver / activer l'écho des commandes |\r\n--\r\n\r\nRécapitulatif : déclarer un serveur HTTP minimal\r\n\r\nSéquence complète depuis un ESP-01 vierge :\r\n\r\n\r\n\r\nÀ partir de cet instant, toute connexion entrante sur est remontée sur le port série sous forme d'événements , à charge pour le programme côté PC (ou pour un firmware personnalisé) de les analyser et de répondre via .\r\n\r\nLimites du firmware AT\r\n\r\nLe firmware AT est pratique pour découvrir et tester l'ESP8266, mais il montre vite ses limites :\r\nlatence importante (chaque commande passe par le port série) ;\r\npas de TLS correct dans les anciennes versions ;\r\ncomplexité pour gérer plusieurs clients simultanés ;\r\ndépendance à un hôte qui pilote l'ESP en permanence.\r\n\r\nPour des projets plus aboutis, il est préférable de flasher l'ESP avec un firmware personnalisé (Arduino, ESP-IDF, MicroPython, Tasmota, ESPHome…) qui exécute directement la logique applicative sur le microcontrôleur, sans intermédiaire série.\r\n```"},{"uuid":"da8225be-1b25-4d02-9765-a576fc89c543","slug":"lithium-battery-charger-2s-a1","title":"Module de chargeur de batterie Li-ion","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2022-08-24 05:23:05","created_at":"2022-08-24 05:23:05","updated_at":"2022-08-24 05:23:05","tags":[],"plain":"Description\nChargeur de 2 batteries Lithium-Ion (Li-Ion) de 7.4V (2 x 3.7V) au format 18650. Interface d'entrée prise USB-C Caractéristiques\nCourant d'entrée : 1A Tension d'entrée : DC de 3.7V à 5V (tolérance de 3V à 6V) Courant de charge : 0.55A (0.40A si tension d'entrée à 3.7V) Tension de charge : 8.4V LED CR pour indiquer le statut de charge LED OK pou rindiquer que la charge est complète Température de fonctionnement : de -40°C à +85°C Fréquence de commutation jusqu'à 1MHz, compense la perte de tension en mode quadruple CV. La résistance interne et la résistance de suivi de la batterie sont chargées automatiquement. La tension de la batterie de Protection est inférieure à la tension d'entrée et au court-circuit de la batterie. Forte adaptabilité à l'alimentation d'entrée, la capacité de conduite est limitée batterie de protection contre les surtensions. Photos du produit Montage"},{"uuid":"5510b12a-d647-4b1a-90ba-d421a4927ff7","slug":"configurer-un-client-oauth-2-0-dans-keycloak-guide-complet","title":"Configurer un client OAuth 2.0 / OIDC dans Keycloak","category":"informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-05-16 23:33","created_at":"2025-05-16 23:33:31","updated_at":"2026-05-12 20:39:53","tags":[],"plain":"Keycloak est une solution open source de gestion des identités et des accès (IAM). Cet article décrit la configuration d'un client OAuth 2.0 / OpenID Connect dans Keycloak, en détaillant les options importantes et en montrant comment restreindre l'accès aux utilisateurs ou groupes autorisés.\r\nNote de version. L'interface d'administration a été refondue à partir de Keycloak 19. La notion d'Access Type ( / / ) a disparu au profit des toggles Client authentication et Authorization. Ce guide suit l'UI actuelle (Keycloak 24+).\r\n--\r\n\r\n1. Prérequis\r\nUne instance Keycloak fonctionnelle (version 24 ou supérieure recommandée).\r\nDes droits d'administration sur un realm.\r\nUne application destinée à s'authentifier via OAuth 2.0 / OIDC.\r\nTLS activé sur Keycloak et sur l'application cliente (obligatoire en production).\r\n--\r\n\r\n2. Qu'est-ce qu'un client dans Keycloak ?\r\n\r\nDans Keycloak, un client représente une application ou un service qui interagit avec le serveur d'authentification, soit pour authentifier des utilisateurs, soit pour obtenir des informations sur eux, soit pour protéger ses propres ressources. Il peut s'agir d'une application web, d'une API, d'une application mobile, d'un service interne ou d'un partenaire tiers.\r\n\r\nChaque client est rattaché à un realm (l'espace logique d'authentification) et identifié par un unique. Cet identifiant est transmis lors de toute demande d'authentification ou d'obtention de jeton.\r\n\r\nLa configuration d'un client définit notamment :\r\nles flux OAuth 2.0 autorisés (, , etc.) ;\r\nla capacité ou non du client à conserver un secret (client confidentiel vs public) ;\r\nles URI de redirection acceptées et les origines CORS ;\r\nla durée de vie des jetons et la composition des claims (mappers) ;\r\nles politiques d'autorisation associées (rôles, groupes, attributs).\r\n--\r\n\r\n3. Création du client\r\n\r\n1. Se connecter à la Keycloak Admin Console.\r\n2. Sélectionner le realm cible.\r\n3. Menu Clients > Create client.\r\n\r\nÉtape « General settings »\r\nChamp | Valeur recommandée | Description |\r\n------------------ | ----------------------------------- | ---------------------------------------------------------------------------- |\r\nClient type | | Protocole utilisé. Choisir uniquement pour des intégrations SAML 2.0. |\r\nClient ID | | Identifiant unique du client dans le realm. Apparaît dans les jetons (). |\r\nName | | Libellé d'affichage (facultatif, peut être localisé). |\r\nDescription | Texte libre | Aide à la maintenance. |\r\n\r\nÉtape « Capability config »\r\nToggle | Valeur recommandée | Détail |\r\n------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------ |\r\nClient authentication | pour un backend, pour un SPA | rend le client confidentiel (un secret est généré). rend le client public. |\r\nAuthorization | | À activer uniquement si l'on souhaite utiliser le moteur d'autorisations fine (RBAC/ABAC) de Keycloak. |\r\nStandard flow | | Active le flux Authorization Code, à utiliser systématiquement. |\r\nDirect access grants | | Flux — déconseillé par OAuth 2.1, à n'utiliser que pour des outils internes legacy. |\r\nImplicit flow | | Déprécié par OAuth 2.1, ne pas activer. |\r\nService accounts roles | si clientcredentials | Permet au client de récupérer un jeton pour son propre compte (machine-to-machine). |\r\nOAuth 2.0 Device Auth Grant | (sauf besoin spécifique) | Pour les appareils sans navigateur (TV, CLI sans IHM locale). |\r\nOIDC CIBA Grant | (sauf besoin spécifique) | Authentification déportée (canal hors-bande). |\r\n\r\nÉtape « Login settings »\r\nChamp | Exemple | Description |\r\n----------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------- |\r\nRoot URL | | URL de base de l'application. Permet d'utiliser des chemins relatifs dans les champs suivants. |\r\nHome URL | | Page par défaut après login. |\r\nValid redirect URIs | | URI exactes autorisées pour la redirection après authentification. Éviter les wildcards larges. |\r\nValid post logout redirect URIs | | URI autorisées pour la redirection après déconnexion (RP-Initiated Logout). |\r\nWeb origins | | Origines CORS autorisées. La valeur reprend automatiquement les redirect URIs ; est à proscrire. |\r\nAdmin URL | | Utilisé pour les notifications backchannel (logout global, push not-before). |\r\nBonne pratique. Les redirect URIs doivent être en en production (sauf pour le développement). Spécifier des chemins aussi précis que possible plutôt qu'un wildcard .\r\n--\r\n\r\n4. Authentification du client (Credentials)\r\n\r\nL'onglet Credentials n'apparaît que si Client authentication est sur . Plusieurs méthodes sont disponibles :\r\nMéthode | Usage |\r\n-------------------------------- | ---------------------------------------------------------------------- |\r\nClient Id and Secret | Secret partagé classique. À stocker dans un coffre-fort (Vault, env vars chiffrées). |\r\nSigned JWT | Le client signe un JWT d'assertion avec sa clé privée. Plus sûr qu'un secret. |\r\nSigned JWT with Client Secret | Variante symétrique (HMAC). |\r\nX.509 Certificate | mTLS — recommandé pour les contextes à forte exigence (FAPI, banque). |\r\nImportant. Le secret ne doit jamais être commité dans Git ni embarqué dans un binaire distribué. Pour un projet où les secrets vivent dans , ne commiter que .\r\n--\r\n\r\n5. Types de clients\r\n\r\nDepuis Keycloak 19, le « type » est déduit de la combinaison des toggles. La terminologie OAuth reste utile :\r\nType | Configuration Keycloak | Cas d'usage |\r\n--------------- | ------------------------------------------------------------------- | ------------------------------------------------------------ |\r\nConfidentiel | | Backend serveur (PHP, Node, Java…), BFF, service-to-service. |\r\nPublic | + + PKCE | SPA (React, Vue, Angular), application mobile, CLI native. |\r\nService account | + | Communication machine-to-machine (). |\r\n\r\nLe type « bearer-only » a été retiré : pour une API qui se contente de valider des jetons sans déclencher d'authentification, créer un client confidentiel et n'activer aucun flux.\r\n--\r\n\r\n6. PKCE — recommandé pour tous les clients\r\n\r\nPKCE (Proof Key for Code Exchange, RFC 7636) protège le flux Authorization Code contre l'interception du code d'autorisation. Conçu initialement pour les clients publics, il est aujourd'hui recommandé pour tous les clients, y compris confidentiels, et obligatoire dans OAuth 2.1.\r\n\r\nActivation dans Advanced > Proof Key for Code Exchange Code Challenge Method > .\r\nNe jamais utiliser ; est la seule valeur acceptable.\r\n--\r\n\r\n7. Restreindre l'accès aux utilisateurs ou groupes\r\n\r\nPar défaut, tout utilisateur du realm peut se connecter via n'importe quel client. Deux approches permettent de restreindre cet accès.\r\n\r\nApproche 1 — Authentification basée sur les rôles (simple)\r\n\r\n1. Créer un rôle client dédié, par exemple , dans l'onglet Roles du client.\r\n2. Assigner ce rôle aux utilisateurs ou groupes autorisés (Users > user > Role mapping, ou Groups > group > Role mapping).\r\n3. Dans Authentication > Flows, ajouter une exécution au flux Browser, configurée avec le rôle requis et .\r\n\r\nCette méthode bloque l'authentification elle-même : un utilisateur sans le rôle ne pourra pas se connecter au client.\r\n\r\nApproche 2 — Authorization Services (granulaire)\r\n\r\nÀ utiliser pour gérer des permissions plus fines (ressources, scopes, conditions).\r\n\r\n1. Activer Authorization sur le client.\r\n2. Onglet Authorization > Policies > créer une Group Policy ou Role Policy listant les utilisateurs/groupes autorisés.\r\n3. Onglet Permissions > créer une Scope-Based Permission ou Resource-Based Permission liée à la policy.\r\n4. Côté application, utiliser l'endpoint UMA ou l'adaptateur Keycloak pour évaluer les permissions.\r\n\r\nApproche 3 — Limiter le client scope « roles »\r\n\r\nDans Client scopes > > Scope, désactiver Full scope allowed et n'autoriser que les rôles pertinents. Cela réduit la taille des jetons et limite ce que le client peut « voir » des rôles utilisateurs.\r\n--\r\n\r\n8. Client scopes et mappers\r\n\r\nLes client scopes déterminent les claims présents dans les jetons ( et ).\r\nLes scopes Default sont systématiquement ajoutés à chaque jeton.\r\nLes scopes Optional ne sont ajoutés que si l'application les demande via le paramètre lors de l'authentification.\r\n\r\nPour exposer les groupes d'un utilisateur dans le token :\r\n\r\n1. Créer un client scope (ou réutiliser celui existant).\r\n2. Ajouter un mapper de type Group Membership :\r\nToken Claim Name : \r\nFull group path : (sauf besoin d'arborescence)\r\nAdd to ID token / Access token / Userinfo : selon l'usage.\r\n3. Attacher le scope au client (Default ou Optional).\r\n--\r\n\r\n9. Réglages avancés à connaître\r\nSection | Réglage | Recommandation |\r\n---------------------------------- | -------------------------------- | ---------------------------------------------------------------- |\r\nAdvanced > Fine grain OpenID Connect configuration | | (par défaut) ou pour FAPI. |\r\nAdvanced > Advanced settings | | . |\r\nAdvanced > Advanced settings | | sauf si l'application implémente correctement la spec OIDC Front-Channel Logout. |\r\nAdvanced > Advanced settings | | Renseigner pour une déconnexion globale propre. |\r\nAdvanced > Token Lifespan | | Court (5–15 min). Le refresh token prend le relais. |\r\nSessions | | Aligner sur la politique de session de l'organisation. |\r\n\r\nPour appliquer automatiquement un ensemble cohérent de règles, utiliser les Client Policies du realm (profils pré-définis et ).\r\n--\r\n\r\n10. Checklist de sécurité\r\n[ ] pour tout client qui peut conserver un secret.\r\n[ ] PKCE activé.\r\n[ ] Implicit flow et Direct access grants désactivés.\r\n[ ] Redirect URIs en et sans wildcard inutile.\r\n[ ] Web origins explicites (pas de ).\r\n[ ] Secret stocké dans un coffre-fort, jamais commité.\r\n[ ] Access token court (≤ 15 min) et refresh token rotatif.\r\n[ ] Accès restreint via rôle dédié ou Authorization Services.\r\n[ ] Full scope allowed désactivé si les rôles transportés doivent être limités.\r\n[ ] Logout backchannel ou front-channel configuré.\r\n--\r\n\r\nConclusion\r\n\r\nLa configuration d'un client OAuth 2.0 dans Keycloak repose sur quelques choix structurants — confidentiel ou public, flux activés, PKCE, restriction d'accès — qui ont chacun des implications de sécurité fortes. S'aligner sur OAuth 2.1 (PKCE systématique, pas d'implicit flow, pas de password grant) et utiliser les Client Policies** pour appliquer ces règles à l'échelle du realm évite la plupart des configurations à risque."},{"uuid":"6016aa4b-f42b-43ef-9957-b893fa030a0c","slug":"mosquitto","title":"Mosquitto : client et serveur MQTT","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-03-14 07:45:19","created_at":"2023-03-14 07:45:19","updated_at":"2023-03-14 07:45:19","tags":[],"plain":"Mosquitto est un courtier de messages (ou broker / serveur MQTT) MQTT open source. Plus d'infos sur MQTT à la page . Mosquitto peut être utilisé pour implémenter des scénarios tels que la collecte de données de capteurs, la surveillance de l'état des appareils et la gestion de l'IoT en général. Les clients MQTT peuvent se connecter à Mosquitto pour publier et/ou recevoir des messages sur des topics spécifiques, permettant une communication efficace et fiable entre les appareils. Dans cet article j'installe Mosquitto sur Rasbperry Pi. Le port par défaut 1883/tcp sera utilisé. Installer le service Mosquitto\nVoici les étapes générales pour installer Mosquitto sur Rasbperry Pi OS, Debian ou Ubuntu : Après l'installation, vous pouvez vérifier si Mosquitto est en cours d'exécution en utilisant la commande dans l'invite de commandes. Cela devrait afficher la version de Mosquitto et les informations de journalisation. Vérifier l’accessibilité du service\nPour vous assurer que le port Mosquitto est ouvert, vous pouvez utiliser un outil en ligne de commande comme nmap pour scanner votre adresse IP publique et vérifier si le port 1883 est ouvert. Par exemple, en utilisant la commande suivante : . Si le port Mosquitto est ouvert, vous devriez voir une ligne dans la sortie de la commande qui indique que le port 1883 est \"open\". Je conseille d’exécuter sur un autre ordinateur que celui qui exécute le service Mosquitto. Configurer la connexion identifiée\nLa connexion à Mosquitto peut être anonyme ou avec un nom d'utilisateur et un mot de passe, selon la configuration du serveur. Dans se paragraphe nous abordons la configuration d'un utilisateur. Pour créer un utilisateur et de définir un mot de passe afin d'accéder à Mosquitto, il faut utiliser l'utilitaire qui est installé avec Mosquitto et permet de gérer les informations d'identification des utilisateurs pour Mosquitto. sudo mosquittopasswd -c /etc/mosquitto/passwd UTILISATEUR Plus spécifiquement, cette commande effectue les actions suivantes :\npermet d'exécuter la commande avec des privilèges d'administrateur pour pouvoir écrire dans le dossier /etc/mosquitto où se trouve le fichier de mots de passe.\nest l'utilitaire de ligne de commande pour gérer le fichier de mots de passe.\ncrée un nouveau fichier de mots de passe s'il n'existe pas déjà, ou remplace un fichier existant.\nest le chemin d'accès complet au fichier de mots de passe à créer ou modifier.\nest le nom d'utilisateur à ajouter au fichier de mots de passe. Vous pouvez remplacer ce nom d'utilisateur par le nom que vous souhaitez utiliser. Une fois que vous avez créé le fichier de mots de passe et ajouté des utilisateurs, vous pouvez utiliser ces informations d'identification pour restreindre l'accès à Mosquitto, en configurant l'authentification basée sur le nom d'utilisateur et le mot de passe dans le fichier de configuration de Mosquitto. Cela est particulièrement important si vous utilisez Mosquitto dans un environnement de production ou si vous souhaitez sécuriser l'accès à votre broker MQTT. Vous devez modifier le fichier de configuration de Mosquitto pour autoriser l'authentification basée sur le nom d'utilisateur et le mot de passe. Ouvrez le fichier de configuration de Mosquitto. Le fichier peut être situé à différents endroits en fonction de votre installation. Par exemple, sur une installation standard de Mosquitto sous Linux, le fichier se trouve généralement dans . Ajoutez les lignes suivantes au fichier de configuration pour spécifier le chemin d'accès au fichier de mots de passe que vous avez créé avec , ainsi que les paramètres d'authentification : passwordfile /etc/mosquitto/passwd\n allowanonymous false Enregistrez le fichier de configuration et redémarrez le service Mosquitto pour que les modifications prennent effet :\n \n sudo systemctl restart mosquitto Après avoir suivi ces étapes, les utilisateurs devront s'authentifier avec un nom d'utilisateur et un mot de passe valides pour publier et souscrire à des messages dans Mosquitto. Si l'utilisateur n'a pas les bonnes informations d'identification, il sera refusé d'accès. Cette fonctionnalité de sécurité renforce la sécurité de Mosquitto et permet de restreindre l'accès à des utilisateurs de confiance uniquement.\n \nConfigurer la connexion anonyme\nLa connexion à Mosquitto peut être anonyme ou avec un nom d'utilisateur et un mot de passe, selon la configuration du serveur. Dans ce paragraphe nous abordons la configuration pour une connexion anonyme. Pour indiquer que la connexion au serveur MQTT est anonyme (sans nom d'utilisateur ni mot de passe), vous devez ajouter les lignes suivantes dans votre fichier de configuration : allowanonymous true Ceci autorisera les connexions anonymes au serveur MQTT. Si cette option n'est pas définie, toutes les connexions nécessiteront un nom d'utilisateur et un mot de passe valides. Assurez-vous de redémarrer le serveur MQTT après avoir modifié le fichier de configuration pour que les modifications prennent effet. Notez que l'utilisation de connexions anonymes peut présenter des risques de sécurité, car cela permet à n'importe qui de se connecter et de publier ou de recevoir des messages sans authentification. Il est donc recommandé d'utiliser des informations d'authentification sécurisées pour protéger votre serveur MQTT.\nEnvoyer / recevoir des messages MQTT\nMosquitto-clients est un outil en ligne de commande fourni avec le broker Mosquitto pour publier et souscrire à des messages MQTT à partir de la ligne de commande. En d'autres termes, Mosquitto-clients permet aux développeurs et aux administrateurs de système de tester et de déboguer des applications MQTT en utilisant des commandes simples pour publier et recevoir des messages. Cela peut être utile pour vérifier la connectivité, le flux de données et le traitement des messages entre les appareils et le broker Mosquitto. Pour installer les clients Mosquitto, y compris le client de ligne de commande et le client d'envoi , vous pouvez suivre ces étapes : sudo apt update\n sudo apt install mosquitto-clients Vous pouvez maintenant utiliser les clients Mosquitto pour publier et souscrire à des messages dans Mosquitto. Par exemple, vous pouvez utiliser la commande pour <u>publier des messages MQTT</u> à un topic : mosquittopub -h localhost -t sensor/elec -m 2546 Par exemple vous pouvez utiliser la commande pour souscrire au topic et <u>recevoir des messages MQTT</u> : mosquittosub -h localhost -t \"sensor/elec\""}] |