Le serveur MQTT Mosquitto peut être facilement mis en service en le téléchargeant et en démarant le service. Cette solution est à la fois simple et fiable.
Cependant, par défaut, seul l'accès TCP sur le port 1883 est activé, ce qui empêche son utilisation directe depuis des pages web HTML.
En réalité, Mosquitto supporte l'écoute sur plusieurs ports. Il suffit d'ajouter une configuraton d'écoute supplémentaire dans le fichier de configuration pour activer cette fonctionnalité.
Voici la configuration à ajouter :
# Fichier de configuration pour mosquitto
#
# Voir mosquitto.conf(5) pour plus d'informations.
#
# Les valeurs par défaut sont affichées, décommentez pour les modifier.
#
# Utilisez le caractère # pour indiquer un commentaire, mais seulement si c'est
# le tout premier caractère de la ligne.
# =================================================================
# Configuration générale
# =================================================================
# Utiliser les paramètres de sécurité par écouteur.
#
# Il est recommandé de définir cette option avant toute autre.
#
# Si cette option est définie sur true, toutes les options d'authentification
# et de contrôle d'accès sont contrôlées par écouteur. Les options suivantes
# sont affectées :
#
# password_file acl_file psk_file auth_plugin auth_opt_* allow_anonymous
# auto_id_prefix allow_zero_length_clientid
#
# Notez que si défini sur true, un client persistant (c'est-à-dire avec clean session
# défini sur false) qui se déconnectera utilisera les paramètres ACL définis
# pour l'écouteur auquel il était connecté le plus récemment.
#
# Le comportement par défaut est que cette option soit définie sur false,
# ce qui maintient le comportement des versions précédentes de mosquitto.
#per_listener_settings false
# Si un client est abonné à plusieurs abonnements qui se chevauchent,
# par exemple foo/# et foo/+/baz, alors MQTT s'attend à ce que lorsque le
# broker reçoit un message sur un sujet qui correspond aux deux abonnements,
# tel que foo/bar/baz, le client ne reçoive le message qu'une seule fois.
# Mosquitto suit quels clients ont reçu un message pour répondre à ce
# besoin. L'option allow_duplicate_messages permet de désactiver ce
# comportement, ce qui peut être utile si vous avez un grand nombre de
# clients abonnés aux mêmes sujets et que vous êtes très soucieux de
# minimiser l'utilisation de la mémoire.
# Elle peut être définie sur true si vous savez à l'avance que vos clients
# n'auront jamais d'abonnements qui se chevauchent, sinon vos clients doivent
# pouvoir gérer correctement les messages dupliqués même avec QoS=2.
#allow_duplicate_messages false
# Cette option contrôle si un client est autorisé à se connecter avec un
# identifiant client de longueur nulle ou non. Cette option n'affecte
# que les clients utilisant MQTT v3.1.1 et versions ultérieures. Si
# définie sur false, les clients se connectant avec un identifiant client
# de longueur nulle sont déconnectés. Si définie sur true, les clients se
# verront attribuer un identifiant client par le broker. Cela signifie qu'elle
# n'est utile que pour les clients avec clean session défini sur true.
#allow_zero_length_clientid true
# Si allow_zero_length_clientid est true, cette option vous permet de définir
# un préfixe pour les identifiants clients générés automatiquement pour aider
# à la visibilité dans les journaux.
# Par défaut à 'auto-'
#auto_id_prefix auto-
# Cette option affecte le scénario où un client s'abonne à un sujet qui a
# des messages conservés. Il est possible que le client qui a publié le message
# conservé sur le sujet ait eu accès au moment de la publication, mais cet
# accès a été supprimé par la suite. Si check_retain_source est défini sur true,
# la valeur par défaut, la source d'un message conservé sera vérifiée pour les
# droits d'accès avant d'être republiée. Lorsqu'il est défini sur false, aucune
# vérification ne sera effectuée et le message conservé sera toujours publié.
# Cela affecte tous les écouteurs.
#check_retain_source true
# Les messages QoS 1 et 2 seront autorisés en vol par client jusqu'à ce que
# cette limite soit dépassée. Par défaut à 0. (Sans maximum)
# Voir aussi max_inflight_messages
#max_inflight_bytes 0
# Le nombre maximum de messages QoS 1 et 2 actuellement en vol par client.
# Cela inclut les messages qui sont en cours de handshake et ceux qui sont
# en cours de nouvelle tentative. Par défaut à 20. Défini sur 0 pour aucun
# maximum. Définir sur 1 garantira la livraison en ordre des messages QoS 1
# et 2.
#max_inflight_messages 20
# Pour les clients MQTT v5, il est possible que le serveur envoie une valeur
# "keepalive du serveur" qui remplacera la valeur keepalive définie par le
# client. Ceci est destiné à être utilisé comme un mécanisme pour dire que le
# serveur déconnectera le client plus tôt que prévu, et que le client devrait
# utiliser la nouvelle valeur keepalive. L'option max_keepalive vous permet de
# spécifier que les clients ne peuvent se connecter qu'avec un keepalive inférieur
# ou égal à cette valeur, sinon ils recevront un keepalive du serveur leur
# indiquant d'utiliser max_keepalive. Ceci ne s'applique qu'aux clients MQTT v5.
# La valeur maximale autorisée est 65535. Ne pas définir en dessous de 10.
#max_keepalive 65535
# Pour les clients MQTT v5, il est possible que le serveur envoie une valeur
# "taille maximale de paquet" qui indiquera au client qu'il n'acceptera pas de
# paquets MQTT de taille supérieure à max_packet_size octets. Ceci s'applique au
# paquet MQTT complet, pas seulement à la charge utile. Définir cette option sur
# une valeur positive définira la taille maximale du paquet sur ce nombre
# d'octets. Si un client envoie un paquet qui est plus grand que cette valeur,
# il sera déconnecté. Ceci s'applique à tous les clients quelle que soit la version
# du protocole qu'ils utilisent, mais les clients v3.1.1 et plus anciens ne
# recevront bien sûr pas les informations sur la taille maximale du paquet.
# Par défaut, pas de limite. Définir en dessous de 20 octets est interdit car
# cela risquerait d'interférer avec le fonctionnement normal des clients, même
# avec de très petites charges utiles.
#max_packet_size 0
# Les messages QoS 1 et 2 au-delà de ceux actuellement en vol seront mis en file
# d'attente par client jusqu'à ce que cette limite soit dépassée. Par défaut à 0.
# (Sans maximum)
# Voir aussi max_queued_messages.
# Si max_queued_messages et max_queued_bytes sont tous deux spécifiés, les
# paquets seront mis en file d'attente jusqu'à ce que la première limite soit
# atteinte.
#max_queued_bytes 0
# Le nombre maximum de messages QoS 1 et 2 à conserver dans une file d'attente
# par client au-delà de ceux qui sont actuellement en vol. Par défaut à 100.
# Défini sur 0 pour aucun maximum (non recommandé).
# Voir aussi queue_qos0_messages.
# Voir aussi max_queued_bytes.
#max_queued_messages 100
#
# Cette option définit le nombre maximum d'octets de mémoire heap que le broker
# allouera, et définit ainsi une limite stricte sur l'utilisation de la mémoire
# par le broker. Les demandes de mémoire qui dépassent cette valeur seront
# refusées. L'effet variera en fonction de ce qui a été refusé. Si un message
# entrant est en cours de traitement, le message sera supprimé et le client
# de publication sera déconnecté. Si un message sortant est en cours d'envoi,
# le message individuel sera supprimé et le client recevant sera déconnecté.
# Par défaut, pas de limite.
#memory_limit 0
# Cette option définit la taille maximale de la charge utile de publication que
# le broker autorisera. Les messages reçus qui dépassent cette taille ne seront
# pas acceptés par le broker. La valeur par défaut est 0, ce qui signifie que tous
# les messages MQTT valides sont acceptés. MQTT impose une taille maximale de
# charge utile de 268435455 octets.
#message_size_limit 0
# Cette option permet aux clients persistants (ceux avec clean session défini sur
# false) d'être supprimés s'ils ne se reconnectent pas dans un certain délai.
#
# Ceci est une option non standard dans MQTT V3.1 mais autorisée dans MQTT v3.1.1.
#
# Les clients mal conçus peuvent définir clean session sur false tout en utilisant
# un identifiant client généré aléatoirement. Cela conduit à des clients persistants
# qui ne se reconnecteront jamais. Cette option permet de supprimer ces clients.
#
# La période d'expiration doit être un entier suivi de l'une des valeurs h d w m y
# pour heure, jour, semaine, mois et année respectivement. Par exemple
#
# persistent_client_expiration 2m
# persistent_client_expiration 14d
# persistent_client_expiration 1y
#
# La valeur par défaut si non définie est de ne jamais expirer les clients persistants.
#persistent_client_expiration
# Écrire l'identifiant du processus dans un fichier. La valeur par défaut est une
# chaîne vide ce qui signifie qu'un fichier pid ne doit pas être écrit.
# Ceci devrait être défini sur /var/run/mosquitto.pid si mosquitto est exécuté
# automatiquement au démarrage avec un script d'init et start-stop-daemon ou similaire.
#pid_file
# Défini sur true pour mettre en file d'attente les messages avec QoS 0 lorsque
# un client persistant est déconnecté. Ces messages sont inclus dans la limite
# imposée par max_queued_messages et max_queued_bytes
# Par défaut à false.
# Ceci est une option non standard pour la spécification MQTT v3.1 mais est
# autorisée dans v3.1.1.
#queue_qos0_messages false
# Défini sur false pour désactiver le support des messages conservés. Si un client
# publie un message avec le bit retain défini, il sera déconnecté si ceci est
# défini sur false.
#retain_available true
# Désactiver l'algorithme de Nagle sur les sockets client. Ceci a pour effet de
# réduire la latence des messages individuels au potentiel coût d'une augmentation
# du nombre de paquets envoyés.
#set_tcp_nodelay false
# Intervalle en secondes entre les mises à jour de l'arbre $SYS.
# Défini sur 0 pour désactiver la publication de l'arbre $SYS.
#sys_interval 10
# La spécification MQTT exige que le QoS d'un message livré à un abonné ne soit
# jamais amélioré pour correspondre au QoS de l'abonnement. Activer cette option
# change ce comportement. Si upgrade_outgoing_qos est défini sur true, les messages
# envoyés à un abonné correspondront toujours au QoS de son abonnement.
# Ceci est une option non standard explicitement interdite par la spécification.
#upgrade_outgoing_qos false
# Lorsqu'il est exécuté en tant que root, abandonner les privilèges à cet utilisateur
# et à son groupe principal.
# Défini sur root pour rester en tant que root, mais ce n'est pas recommandé.
# Si exécuté en tant qu'utilisateur non root, ce paramètre n'a aucun effet.
# Notez que sous Windows cela n'a aucun effet et donc mosquitto devrait être
# démarré par l'utilisateur que vous souhaitez qu'il exécute.
#user mosquitto
# =================================================================
# Écouteur par défaut
# =================================================================
# Adresse IP/nom d'hôte pour lier l'écouteur par défaut. Si non
# spécifiée, l'écouteur par défaut ne sera pas lié à une adresse
# spécifique et donc sera accessible à toutes les interfaces réseau.
#bind_address adresse-ip/nom d'hôte
#bind_address
# Port à utiliser pour l'écouteur par défaut.
port 1883
# Lier l'écouteur à une interface spécifique. Ceci est similaire à
# bind_address ci-dessus mais est utile lorsqu'une interface a plusieurs
# adresses ou que l'adresse peut changer. Il est valide d'utiliser ceci
# avec l'option bind_address, mais faites attention à ce que l'interface
# à laquelle vous vous liez contienne l'adresse à laquelle vous vous liez,
# sinon vous ne pourrez pas vous connecter.
# Exemple: bind_interface eth0
#bind_interface
# Lorsqu'un écouteur utilise le protocole websockets, il est possible de
# servir des données http également. Définissez http_dir sur un répertoire
# qui contient les fichiers que vous souhaitez servir. Si cette option n'est
# pas spécifiée, aucune connexion http normale ne sera possible.
#http_dir
# Le nombre maximum de connexions client autorisées. Ceci est un paramètre
# par écouteur.
# Par défaut à -1, ce qui signifie un nombre illimité de connexions.
# Notez que d'autres limites de processus signifient qu'un nombre illimité
# de connexions n'est pas vraiment possible. Typiquement, le nombre maximum
# de connexions possible par défaut est d'environ 1024.
#max_connections -1
# Choisir le protocole à utiliser lors de l'écoute.
# Ceci peut être soit mqtt soit websockets.
# Le support websockets est actuellement désactivé par défaut au moment de la compilation.
# Le TLS basé sur les certificats peut être utilisé avec websockets, sauf que
# seules les options cafile, certfile, keyfile et ciphers sont supportées.
#protocol mqtt
protocol mqtt
# Définir use_username_as_clientid sur true pour remplacer l'identifiant client
# avec lequel un client s'est connecté par son nom d'utilisateur. Cela permet
# d'associer l'authentification à l'identifiant client, ce qui signifie qu'il est
# possible d'empêcher un client de déconnecter un autre en utilisant le même
# identifiant client.
# Si un client se connecte sans nom d'utilisateur, il sera déconnecté comme non
# autorisé lorsque cette option est définie sur true.
# Ne pas utiliser en conjonction avec clientid_prefixes.
# Voir aussi use_identity_as_username.
#use_username_as_clientid
# -----------------------------------------------------------------
# Support SSL/TLS basé sur les certificats
# -----------------------------------------------------------------
# Les options suivantes peuvent être utilisées pour activer le support SSL/TLS
# pour cet écouteur. Notez que le port recommandé pour MQTT sur TLS
# est 8883, mais cela doit être défini manuellement.
#
# Voir aussi la page de manuel mosquitto-tls.
# Au moins l'une des options cafile ou capath doit être définie. Elles définissent
# toutes deux des méthodes d'accès aux certificats d'autorité de certification
# PEM qui ont signé votre certificat serveur et que vous souhaitez faire confiance.
# cafile définit le chemin vers un fichier contenant les certificats CA.
# capath définit un répertoire qui sera recherché pour des fichiers
# contenant les certificats CA. Pour que capath fonctionne correctement, les
# fichiers de certificat doivent avoir ".crt" comme extension de fichier et vous
# devez exécuter "openssl rehash <chemin vers capath>" chaque fois que vous
# ajoutez/supprimez un certificat.
#cafile
#capath
# Chemin vers le certificat serveur encodé PEM.
#certfile
# Chemin vers le fichier de clé encodé PEM.
#keyfile
# Si vous avez require_certificate défini sur true, vous pouvez créer un fichier
# de liste de révocation de certificats pour révoquer l'accès à des certificats
# client spécifiques. Si vous avez fait cela, utilisez crlfile pour pointer vers
# le fichier de révocation encodé PEM.
#crlfile
# Si vous souhaitez contrôler quels chiffreurs de chiffrement sont utilisés,
# utilisez l'option ciphers. La liste des chiffreurs disponibles peut être obtenue
# en utilisant la commande "openssl ciphers" et doit être fournie dans le même
# format que la sortie de cette commande.
# Si non défini, par défaut à DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:@STRENGTH
#ciphers DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:@STRENGTH
# Pour permettre l'utilisation de l'échange de clés DH éphémère, qui fournit
# une sécurité forward, l'écouteur doit charger les paramètres DH. Ceci peut
# être spécifié avec l'option dhparamfile. Le fichier dhparamfile peut être généré
# avec la commande par exemple "openssl dhparam -out dhparam.pem 2048"
#dhparamfile
# Par défaut, un écouteur activé TLS fonctionnera de manière similaire à un
# serveur web activé https, en ce sens que le serveur a un certificat signé par
# une CA et le client vérifiera qu'il s'agit d'un certificat de confiance. L'objectif
# global est le chiffrement du trafic réseau. En définissant require_certificate sur true,
# le client doit fournir un certificat valide pour que la connexion réseau
# puisse se poursuivre. Cela permet de contrôler l'accès au broker en dehors
# des mécanismes fournis par MQTT.
#require_certificate false
# Cette option définit la version du protocole TLS à utiliser pour cet écouteur.
# La valeur par défaut autorise toutes les versions v1.3, v1.2 et v1.1. Les valeurs
# valides sont tlsv1.3, tlsv1.2 et tlsv1.1.
#tls_version
# Si require_certificate est true, vous pouvez définir use_identity_as_username sur true
# pour utiliser la valeur CN du certificat client comme nom d'utilisateur. Si ceci est
# true, l'option password_file ne sera pas utilisée pour cet écouteur.
# Ceci a la priorité sur use_subject_as_username.
# Voir aussi use_subject_as_username.
#use_identity_as_username false
# Si require_certificate est true, vous pouvez définir use_subject_as_username sur true
# pour utiliser la valeur complète du sujet du certificat client comme nom d'utilisateur.
# Si ceci est true, l'option password_file ne sera pas utilisée pour cet écouteur.
# Voir aussi use_identity_as_username
#use_subject_as_username false
# -----------------------------------------------------------------
# Support SSL/TLS basé sur les clés pré-partagées
# -----------------------------------------------------------------
# Les options suivantes peuvent être utilisées pour activer le support SSL/TLS
# basé sur PSK pour cet écouteur. Notez que le port recommandé pour MQTT sur TLS
# est 8883, mais cela doit être défini manuellement.
#
# Voir aussi la page de manuel mosquitto-tls et la section "Support SSL/TLS
# basé sur les certificats". Seul un support de chiffrement par certificat ou
# PSK peut être activé pour un écouteur donné.
# L'option psk_hint active le support de clé pré-partagée pour cet écouteur et
# agit également comme un identifiant pour cet écouteur. L'indice est envoyé aux
# clients et peut être utilisé localement pour aider à l'authentification. L'indice
# est une chaîne de forme libre qui n'a pas beaucoup de sens en soi, n'hésitez pas
# à être créatif.
# Si cette option est fournie, voir psk_file pour définir les clés pré-partagées
# à utiliser ou créer un plugin de sécurité pour les gérer.
#psk_hint
# Lors de l'utilisation de PSK, les chiffreurs de chiffrement utilisés seront choisis
# parmi la liste des chiffreurs PSK disponibles. Si vous souhaitez contrôler quels
# chiffreurs sont disponibles, utilisez l'option "ciphers". La liste des chiffreurs
# disponibles peut être obtenue en utilisant la commande "openssl ciphers" et doit
# être fournie dans le même format que la sortie de cette commande.
#ciphers
# Définir use_identity_as_username pour que l'identité PSK envoyée par le client
# soit utilisée comme son nom d'utilisateur. L'authentification sera effectuée
# en utilisant le PSK plutôt que le nom d'utilisateur/mot de passe MQTT et donc
# password_file ne sera pas utilisé pour cet écouteur.
#use_identity_as_username false
# =================================================================
# Écouteurs supplémentaires
# =================================================================
# Écouter sur une combinaison de port/adresse IP. En utilisant cette variable
# plusieurs fois, mosquitto peut écouter sur plusieurs ports. Si cette variable
# est utilisée et ni bind_address ni port ne sont spécifiés, alors l'écouteur
# par défaut ne sera pas démarré.
# Le numéro de port sur lequel écouter doit être donné. Optionnellement, une adresse
# IP ou un nom d'hôte peut être fourni comme deuxième argument. Dans ce cas,
# mosquitto tentera de lier l'écouteur à cette adresse et donc restreindra l'accès
# au réseau et à l'interface associés. Par défaut, mosquitto écoutera sur toutes les interfaces.
# Notez que pour un écouteur websockets, il n'est pas possible de se lier à un nom d'hôte.
#listener numéro-port [adresse IP/nom d'hôte]
listener 9988
# Lier l'écouteur à une interface spécifique. Ceci est similaire à
# la partie [adresse IP/nom d'hôte] de la définition de l'écouteur, mais est utile
# lorsqu'une interface a plusieurs adresses ou que l'adresse peut changer. Il est
# valide d'utiliser ceci avec la partie [adresse IP/nom d'hôte] de la définition
# de l'écouteur, mais faites attention à ce que l'interface à laquelle vous vous liez
# contienne l'adresse à laquelle vous vous liez, sinon vous ne pourrez pas vous connecter.
# Disponible uniquement sur Linux et nécessite des privilèges élevés.
#
# Exemple: bind_interface eth0
#bind_interface
# Lorsqu'un écouteur utilise le protocole websockets, il est possible de
# servir des données http également. Définissez http_dir sur un répertoire
# qui contient les fichiers que vous souhaitez servir. Si cette option n'est
# pas spécifiée, aucune connexion http normale ne sera possible.
#http_dir
# Le nombre maximum de connexions client autorisées. Ceci est un paramètre
# par écouteur.
# Par défaut à -1, ce qui signifie un nombre illimité de connexions.
# Notez que d'autres limites de processus signifient qu'un nombre illimité
# de connexions n'est pas vraiment possible. Typiquement, le nombre maximum
# de connexions possible par défaut est d'environ 1024.
#max_connections -1
# L'écouteur peut être restreint à fonctionner dans une hiérarchie de sujets
# en utilisant l'option mount_point. Ceci est réalisé en préfixant la chaîne
# mount_point à tous les sujets pour les clients connectés à cet écouteur. Ce
# préfixage n'est fait qu'intérieurement au broker ; le client ne verra pas
# le préfixe.
#mount_point
# Choisir le protocole à utiliser lors de l'écoute.
# Ceci peut être soit mqtt soit websockets.
# Le TLS basé sur les certificats peut être utilisé avec websockets, sauf que
# seules les options cafile, certfile, keyfile et ciphers sont supportées.
protocol websockets
# Définir use_username_as_clientid sur true pour remplacer l'identifiant client
# avec lequel un client s'est connecté par son nom d'utilisateur. Cela permet
# d'associer l'authentification à l'identifiant client, ce qui signifie qu'il est
# possible d'empêcher un client de déconnecter un autre en utilisant le même
# identifiant client.
# Si un client se connecte sans nom d'utilisateur, il sera déconnecté comme non
# autorisé lorsque cette option est définie sur true.
# Ne pas utiliser en conjonction avec clientid_prefixes.
# Voir aussi use_identity_as_username.
#use_username_as_clientid
# Changer la taille des en-têtes websockets. Ceci est une option globale,
# il n'est pas possible de la définir par écouteur. Cette option définit la
# taille du tampon utilisé dans la librairie libwebsockets lors de la lecture
# des en-têtes HTTP. Si vous passez de grandes données d'en-tête telles que
# des cookies, vous devrez peut-être augmenter cette valeur. Si non définie,
# ou définie sur 0, alors la valeur par défaut de 1024 octets sera utilisée.
#websockets_headers_size
# -----------------------------------------------------------------
# Support SSL/TLS basé sur les certificats
# -----------------------------------------------------------------
# Les options suivantes peuvent être utilisées pour activer le support SSL/TLS
# basé sur les certificats pour cet écouteur. Notez que le port recommandé
# pour MQTT sur TLS est 8883, mais cela doit être défini manuellement.
#
# Voir aussi la page de manuel mosquitto-tls et la section "Support SSL/TLS
# basé sur les clés pré-partagées". Seul un support de chiffrement par certificat
# ou PSK peut être activé pour un écouteur donné.
# Au moins l'une des options cafile ou capath doit être définie pour activer
# le chiffrement TLS basé sur les certificats. Elles définissent toutes deux des
# méthodes d'accès aux certificats d'autorité de certification PEM qui ont
# signé votre certificat serveur et que vous souhaitez faire confiance.
# cafile définit le chemin vers un fichier contenant les certificats CA.
# capath définit un répertoire qui sera recherché pour des fichiers
# contenant les certificats CA. Pour que capath fonctionne correctement, les
# fichiers de certificat doivent avoir ".crt" comme extension de fichier et vous
# devez exécuter "openssl rehash <chemin vers capath>" chaque fois que vous
# ajoutez/supprimez un certificat.
#cafile
#capath
# Chemin vers le certificat serveur encodé PEM.
#certfile
# Chemin vers le fichier de clé encodé PEM.
#keyfile
# Si vous souhaitez contrôler quels chiffreurs de chiffrement sont utilisés,
# utilisez l'option ciphers. La liste des chiffreurs disponibles peut être obtenue
# en utilisant la commande "openssl ciphers" et doit être fournie dans le même
# format que la sortie de cette commande.
#ciphers
# Si vous avez require_certificate défini sur true, vous pouvez créer un fichier
# de liste de révocation de certificats pour révoquer l'accès à des certificats
# client spécifiques. Si vous avez fait cela, utilisez crlfile pour pointer vers
# le fichier de révocation encodé PEM.
#crlfile
# Pour permettre l'utilisation de l'échange de clés DH éphémère, qui fournit
# une sécurité forward, l'écouteur doit charger les paramètres DH. Ceci peut
# être spécifié avec l'option dhparamfile. Le fichier dhparamfile peut être généré
# avec la commande par exemple "openssl dhparam -out dhparam.pem 2048"
#dhparamfile
# Par défaut, un écouteur activé TLS fonctionnera de manière similaire à un
# serveur web activé https, en ce sens que le serveur a un certificat signé par
# une CA et le client vérifiera qu'il s'agit d'un certificat de confiance. L'objectif
# global est le chiffrement du trafic réseau. En définissant require_certificate sur true,
# le client doit fournir un certificat valide pour que la connexion réseau
# puisse se poursuivre. Cela permet de contrôler l'accès au broker en dehors
# des mécanismes fournis par MQTT.
#require_certificate false
# Si require_certificate est true, vous pouvez définir use_identity_as_username sur true
# pour utiliser la valeur CN du certificat client comme nom d'utilisateur. Si ceci est
# true, l'option password_file ne sera pas utilisée pour cet écouteur.
#use_identity_as_username false
# -----------------------------------------------------------------
# Support SSL/TLS basé sur les clés pré-partagées
# -----------------------------------------------------------------
# Les options suivantes peuvent être utilisées pour activer le support SSL/TLS
# basé sur PSK pour cet écouteur. Notez que le port recommandé pour MQTT sur TLS
# est 8883, mais cela doit être défini manuellement.
#
# Voir aussi la page de manuel mosquitto-tls et la section "Support SSL/TLS
# basé sur les certificats". Seul un support de chiffrement par certificat ou
# PSK peut être activé pour un écouteur donné.
# L'option psk_hint active le support de clé pré-partagée pour cet écouteur et
# agit également comme un identifiant pour cet écouteur. L'indice est envoyé aux
# clients et peut être utilisé localement pour aider à l'authentification. L'indice
# est une chaîne de forme libre qui n'a pas beaucoup de sens en soi, n'hésitez pas
# à être créatif.
# Si cette option est fournie, voir psk_file pour définir les clés pré-partagées
# à utiliser ou créer un plugin de sécurité pour les gérer.
#psk_hint
# Lors de l'utilisation de PSK, les chiffreurs de chiffrement utilisés seront choisis
# parmi la liste des chiffreurs PSK disponibles. Si vous souhaitez contrôler quels
# chiffreurs sont disponibles, utilisez l'option "ciphers". La liste des chiffreurs
# disponibles peut être obtenue en utilisant la commande "openssl ciphers" et doit
# être fournie dans le même format que la sortie de cette commande.
#ciphers
# Définir use_identity_as_username pour que l'identité PSK envoyée par le client
# soit utilisée comme son nom d'utilisateur. L'authentification sera effectuée
# en utilisant le PSK plutôt que le nom d'utilisateur/mot de passe MQTT et donc
# password_file ne sera pas utilisé pour cet écouteur.
#use_identity_as_username false
# =================================================================
# Persistance
# =================================================================
# Si la persistance est activée, sauvegarder la base de données en mémoire
# sur disque toutes les autosave_interval secondes. Si défini sur 0, la base de
# données de persistance ne sera écrite que lorsque mosquitto se termine. Voir aussi
# autosave_on_changes.
# Notez que l'écriture de la base de données de persistance peut être forcée
# en envoyant à mosquitto un signal SIGUSR1.
#autosave_interval 1800
# Si true, mosquitto comptera le nombre de changements d'abonnement, de messages
# conservés reçus et de messages en file d'attente et si le total dépasse
# autosave_interval alors la base de données en mémoire sera sauvegardée sur disque.
# Si false, mosquitto sauvegardera la base de données en mémoire sur disque en
# traitant autosave_interval comme un temps en secondes.
#autosave_on_changes false
# Sauvegarder les données de message persistantes sur disque (true/false).
# Ceci sauvegarde des informations sur tous les messages, y compris
# les abonnements, les messages actuellement en vol et les messages
# conservés.
# retained_persistence est un synonyme de cette option.
#persistence false
# Le nom de fichier à utiliser pour la base de données persistante, sans
# inclure le chemin.
#persistence_file mosquitto.db
# Emplacement pour la base de données persistante. Doit inclure un /
# final. Par défaut est une chaîne vide (répertoire courant).
# Défini sur ex. /var/lib/mosquitto/ si exécuté en tant que service
# approprié sur Linux ou similaire.
#persistence_location
# =================================================================
# Journalisation
# =================================================================
# Lieux où journaliser. Utilisez plusieurs lignes log_dest pour plusieurs
# destinations de journalisation.
# Les destinations possibles sont : stdout stderr syslog topic file
#
# stdout et stderr journalisent sur la console sur la sortie nommée.
#
# syslog utilise la facility syslog userspace qui se termine généralement
# dans /var/log/messages ou similaire.
#
# topic journalise vers le sujet broker '$SYS/broker/log/<sévérité>',
# où sévérité est l'une de D, E, W, N, I, M qui sont debug, error,
# warning, notice, information et message. Le type de sévérité message
# est utilisé par les log_types subscribe/unsubscribe et publie des messages
# de journal vers $SYS/broker/log/M/susbcribe ou $SYS/broker/log/M/unsubscribe.
#
# La destination fichier nécessite un paramètre supplémentaire qui est le
# fichier vers lequel journaliser, ex. "log_dest file /var/log/mosquitto.log".
# Le fichier sera fermé et rouvert lorsque le broker reçoit un signal HUP.
# Une seule destination fichier peut être configurée.
#
# Notez que si le broker s'exécute en tant que service Windows, il sera
# par défaut à "log_dest none" et ni stdout ni stderr n'est disponible.
# Utilisez "log_dest none" si vous souhaitez désactiver la journalisation.
#log_dest stderr
# Types de messages à journaliser. Utilisez plusieurs lignes log_type pour
# journaliser plusieurs types de messages.
# Les types possibles sont : debug, error, warning, notice, information,
# none, subscribe, unsubscribe, websockets, all.
# Notez que les messages de type debug sont pour décoder les paquets
# réseau entrants/sortants. Ils ne sont pas journalisés dans "topics".
#log_type error
#log_type warning
#log_type notice
#log_type information
#log_type websockets
# Si défini sur true, les messages de connexion et de déconnexion client
# seront inclus dans le journal.
#connection_messages true
# Si vous utilisez la journalisation syslog (pas sur Windows), les messages
# seront journalisés dans la facility "daemon" par défaut. Utilisez l'option
# log_facility pour choisir parmi local0 à local7 pour journaliser à la place.
# La valeur de l'option devrait être une valeur entière, ex. "log_facility 5"
# pour utiliser local5.
#log_facility
# Si défini sur true, ajoutez une valeur d'horodatage à chaque message de journal.
#log_timestamp true
# Définir le format de l'horodatage du journal. Si non défini, c'est le nombre
# de secondes depuis l'époque Unix.
# Ceci est une chaîne de texte libre qui sera passée à la fonction strftime.
# Pour obtenir une datetime ISO 8601, par exemple :
# log_timestamp_format %Y-%m-%dT%H:%M:%S
#log_timestamp_format
# Changer le niveau de journalisation websockets. Ceci est une option globale,
# il n'est pas possible de le définir par écouteur. Ceci est un entier qui est
# interprété par libwebsockets comme un masque de bits pour son enum lws_log_levels.
# Voir la documentation de libwebsockets pour plus de détails. "log_type websockets"
# doit également être activé.
websockets_log_level 0
# =================================================================
# Sécurité
# =================================================================
# Si défini, seuls les clients ayant un préfixe correspondant sur leur
# identifiant client seront autorisés à se connecter au broker. Par défaut,
# tous les clients peuvent se connecter.
# Par exemple, définir "secure-" ici signifierait qu'un client "secure-
# client" pourrait se connecter mais un autre avec l'identifiant client "mqtt"
# ne pourrait pas.
#clientid_prefixes
# Valeur booléenne qui détermine si les clients qui se connectent
# sans fournir de nom d'utilisateur sont autorisés à se connecter. Si
# défini sur false, alors un fichier de mot de passe devrait être créé
# (voir l'option password_file) pour contrôler l'accès client authentifié.
#
# Par défaut à true si aucune autre option de sécurité n'est définie. Si
# `password_file` ou `psk_file` est défini, ou si un plugin d'authentification
# est chargé qui implique des vérifications nom d'utilisateur/mot de passe
# ou TLS-PSK, alors `allow_anonymous` par défaut à false.
#
#allow_anonymous true
# -----------------------------------------------------------------
# Authentification et contrôle d'accès aux sujets par défaut
# -----------------------------------------------------------------
# Contrôler l'accès au broker en utilisant un fichier de mot de passe. Ce fichier
# peut être généré en utilisant l'utilitaire mosquitto_passwd. Si le support TLS
# n'est pas compilé dans mosquitto (il est recommandé que le support TLS
# soit inclus) alors les mots de passe en texte clair sont utilisés, auquel
# cas le fichier devrait être un fichier texte avec des lignes au format :
# nom d'utilisateur:mot de passe
# Le mot de passe (et le deux-points) peut être omis si désiré, bien que cela
# offre très peu en matière de sécurité.
#
# Voir les options TLS client require_certificate et use_identity_as_username
# pour des options d'authentification alternatives. Si un auth_plugin est utilisé
# ainsi que password_file, la vérification de l'auth_plugin sera faite en premier.
#password_file
# L'accès peut également être contrôlé en utilisant un fichier de clé
# pré-partagée. Cela nécessite le support TLS-PSK et un écouteur configuré
# pour l'utiliser. Le fichier devrait être des lignes texte au format :
# identité:clé
# La clé devrait être en format hexadécimal sans un "0x" initial.
# Si un auth_plugin est utilisé en même temps, la vérification de l'auth_plugin
# sera faite en premier.
#psk_file
# Contrôler l'accès aux sujets sur le broker en utilisant un fichier de liste
# de contrôle d'accès. Si ce paramètre est défini, alors seulement les sujets
# listés auront accès.
# Si le premier caractère d'une ligne du fichier ACL est un #, il est traité
# comme un commentaire.
# L'accès au sujet est ajouté avec des lignes au format :
#
# sujet [read|write|readwrite] <sujet>
#
# Le type d'accès est contrôlé en utilisant "read", "write" ou "readwrite".
# Ce paramètre est optionnel (sauf si <sujet> contient un caractère espace) -
# si non donné alors l'accès est read/write. <sujet> peut contenir les
# caractères + ou # comme dans les abonnements.
#
# Le premier ensemble de sujets est appliqué aux clients anonymes, en supposant
# que allow_anonymous est true. Les ACL de sujet spécifiques à l'utilisateur
# sont ajoutées après une ligne utilisateur comme suit :
#
# utilisateur <nom d'utilisateur>
#
# Le nom d'utilisateur fait référence ici est le même que dans password_file.
# Ce n'est pas l'identifiant client.
#
#
# Il est également possible de définir des ACL basées sur la substitution de
# modèles dans le sujet. Les modèles disponibles pour la substitution sont :
#
# %c pour correspondre à l'identifiant client du client
# %u pour correspondre au nom d'utilisateur du client
#
# Le modèle de substitution doit être le seul texte pour ce niveau de hiérarchie.
#
# La forme est la même que pour le mot clé sujet, mais en utilisant pattern
# comme mot clé.
# Les ACL de modèle s'appliquent à tous les utilisateurs même si le mot clé
# "user" a été donné précédemment.
#
# Si vous utilisez des ponts avec des noms d'utilisateur et des ACL, les messages
# de connexion peuvent être autorisés avec le modèle suivant :
# pattern write $SYS/broker/connection/%c/state
#
# pattern [read|write|readwrite] <sujet>
#
# Exemple :
#
# pattern write capteur/%u/données
#
# Si un auth_plugin est utilisé ainsi que acl_file, la vérification de l'auth_plugin
# sera faite en premier.
#acl_file
# -----------------------------------------------------------------
# Options de plugin d'authentification et de contrôle d'accès externe
# -----------------------------------------------------------------
# L'authentification et le contrôle d'accès externes peuvent être supportés
# avec l'option auth_plugin. Ceci est un chemin vers un plugin chargeable.
# Voir aussi les options auth_opt_* décrites ci-dessous.
#
# L'option auth_plugin peut être spécifiée plusieurs fois pour charger
# plusieurs plugins. Les plugins seront traités dans l'ordre où ils sont
# spécifiés ici. Si l'option auth_plugin est spécifiée avec l'une des options
# password_file ou acl_file, alors les vérifications du plugin seront faites
# en premier.
#
#auth_plugin
# Si l'option auth_plugin ci-dessus est utilisée, définissez ici les options
# à passer au plugin comme décrit par les instructions du plugin. Toutes les
# options nommées en utilisant le format auth_opt_* seront passées au plugin,
# par exemple :
#
# auth_opt_db_host
# auth_opt_db_port
# auth_opt_db_username
# auth_opt_db_password
# =================================================================
# Ponts
# =================================================================
# Un pont est un moyen de connecter plusieurs brokers MQTT ensemble.
# Créez un nouveau pont en utilisant l'option "connection" comme décrit ci-dessous.
# Définissez les options pour les ponts en utilisant les paramètres restants.
# Vous devez spécifier l'adresse et au moins un sujet auquel s'abonner.
#
# Chaque connexion doit avoir un nom unique.
#
# La ligne d'adresse peut avoir plusieurs adresses hôte et ports spécifiés.
# Voir ci-dessous dans la description round_robin pour plus de détails sur le
# comportement du pont si plusieurs adresses sont utilisées. Notez que si vous
# utilisez une adresse IPv6, vous êtes obligé de spécifier un port.
#
# La direction dans laquelle le sujet sera partagé peut être choisie en
# spécifiant out, in ou both, où la valeur par défaut est out.
# Le niveau QoS de la communication pontée peut être spécifié avec l'option
# sujet suivante. Le niveau QoS par défaut est 0, pour changer le QoS, la
# direction du sujet doit également être donnée.
#
# Les options de préfixe local et distant permettent de mapper un sujet
# lorsqu'il est ponté depuis/vers le broker distant. Ceci fournit la possibilité
# de placer un arbre de sujet dans un emplacement approprié.
#
# Pour plus de détails, voir la page de manuel mosquitto.conf.
#
# Plusieurs sujets peuvent être spécifiés par connexion, mais faites attention
# à ne pas créer de boucles.
#
# Si vous utilisez des ponts avec cleansession défini sur false (par défaut),
# vous pouvez obtenir un comportement inattendu des sujets entrants si vous
# changez les sujets auxquels vous vous abonnez. Ceci est parce que le broker
# distant maintient l'abonnement pour l'ancien sujet. Si vous avez ce problème,
# connectez votre pont avec cleansession défini sur true, puis reconnectez avec
# cleansession défini sur false comme d'habitude.
#connection <nom>
#adresse <hôte>[:<port>] [<hôte>[:<port>]]
#sujet <sujet> [[[out | in | both] niveau-qos] préfixe-local préfixe-distant]
# Si un pont a des sujets avec direction "out", le comportement par défaut est
# d'envoyer une demande de désabonnement au broker distant sur ce sujet. Cela
# signifie que changer la direction d'un sujet de "in" à "out" ne continuera pas
# à recevoir les messages entrants. L'envoi de ces demandes de désabonnement n'est
# pas toujours souhaitable, définir bridge_attempt_unsubscribe sur false désactivera
# l'envoi de la demande de désabonnement.
#bridge_attempt_unsubscribe true
# Définir la version du protocole MQTT à utiliser pour ce pont. Peut être l'une
# des valeurs mqttv311 ou mqttv11. Par défaut à mqttv311.
#bridge_protocol_version mqttv311
# Définir la variable clean session pour ce pont.
# Lorsqu'il est défini sur true, lorsque le pont se déconnecte pour n'importe
# quelle raison, tous les messages et abonnements seront nettoyés sur le
# broker distant. Notez que avec cleansession défini sur true, il peut y avoir
# un nombre important de messages conservés envoyés lorsque le pont se reconnecte
# après avoir perdu sa connexion.
# Lorsqu'il est défini sur false, les abonnements et les messages sont conservés
# sur le broker distant, et livrés lorsque le pont se reconnecte.
#cleansession false
# Définir le délai d'inactivité pendant lequel un pont utilisant le type de
# démarrage paresseux doit être inactif avant d'être arrêté. Par défaut à 60 secondes.
#idle_timeout 60
# Définir l'intervalle keepalive pour cette connexion de pont, en
# secondes.
#keepalive_interval 60
# Définir l'identifiant client à utiliser sur le broker local. Si non défini,
# cela par défaut à 'local.<identifiant client>'. Si vous pontez un broker
# à lui-même, il est important que local_clientid et clientid ne correspondent pas.
#local_clientid
# Si défini sur true, publier des messages de notification vers les brokers
# locaux et distants donnant des informations sur l'état de la connexion
# du pont. Les messages conservés sont publiés sur le sujet
# $SYS/broker/connection/<identifiant client>/state sauf si l'option
# notification_topic est utilisée.
# Si le message est 1 alors la connexion est active, ou 0 si la connexion
# a échoué.
# Ceci utilise la fonctionnalité testamentaire (last will and testament).
#notifications true
# Choisir le sujet sur lequel les messages de notification pour ce pont
# sont publiés. Si non défini, les messages sont publiés sur le sujet
# $SYS/broker/connection/<identifiant client>/state
#notification_topic
# Définir l'identifiant client à utiliser sur l'extrémité distante de cette
# connexion de pont. Si non défini, cela par défaut à 'nom.nom d'hôte' où nom
# est le nom de la connexion et nom d'hôte est le nom d'hôte de cet ordinateur.
# Cela remplace l'ancienne option "clientid" pour éviter toute confusion.
# "clientid" reste valide pour le moment.
#remote_clientid
# Définir le mot de passe à utiliser lors de la connexion à un broker qui
# nécessite une authentification. Cette option n'est utilisée que si
# remote_username est également défini.
# Cela remplace l'ancienne option "password" pour éviter toute confusion.
# "password" reste valide pour le moment.
#remote_password
# Définir le nom d'utilisateur à utiliser lors de la connexion à un broker qui
# nécessite une authentification.
# Cela remplace l'ancienne option "username" pour éviter toute confusion.
# "username" reste valide pour le moment.
#remote_username
# Définir le délai d'attente qu'un pont utilisant le type de démarrage
# automatique attendra avant de tenter de se reconnecter.
# Cette option peut être configurée pour utiliser un délai constant en secondes,
# ou pour utiliser un mécanisme de backoff basé sur "Decorrelated Jitter", qui
# ajoute un degré de hasard à quand le redémarrage se produit.
#
# Définir un timeout constant de 20 secondes :
# restart_timeout 20
#
# Définir un backoff avec une base (valeur de départ) de 10 secondes et un plafond
# (limite supérieure) de 60 secondes :
# restart_timeout 10 30
#
# Par défaut à jitter avec une base de 5 et un plafond de 30
#restart_timeout 5 30
# Si le pont a plus d'une adresse donnée dans la configuration adresse/adresses,
# l'option round_robin définit le comportement du pont en cas d'échec de la
# connexion du pont. Si round_robin est false, la valeur par défaut, alors la
# première adresse est traitée comme la connexion principale du pont. Si la
# connexion échoue, les autres adresses secondaires seront essayées à tour de rôle.
# Tandis que connecté à un pont secondaire, le pont tentera périodiquement de
# se reconnecter au pont principal jusqu'à ce que cela réussisse.
# Si round_robin est true, alors toutes les adresses sont traitées comme égales.
# Si une connexion échoue, la prochaine adresse sera essayée et si réussie
# restera connectée jusqu'à ce qu'elle échoue
#round_robin false
# Définir le type de démarrage du pont. Ceci contrôle comment le pont démarre
# et peut être l'un des trois types : automatic, lazy et once. Notez que RSMB
# fournit un quatrième type de démarrage "manual" qui n'est pas actuellement
# supporté par mosquitto.
#
# "automatic" est le type de démarrage par défaut et signifie que la connexion
# du pont sera démarrée automatiquement lorsque le broker démarre et également
# redémarrée après un court délai (30 secondes) si la connexion échoue.
#
# Les ponts utilisant le type de démarrage "lazy" seront démarrés automatiquement
# lorsque le nombre de messages en file d'attente dépasse le nombre défini avec
# le paramètre "threshold". Il sera arrêté automatiquement après le temps défini
# par le paramètre "idle_timeout". Utilisez ce type de démarrage si vous souhaitez
# que la connexion ne soit active que lorsqu'elle est nécessaire.
#
# Un pont utilisant le type de démarrage "once" sera démarré automatiquement
# lorsque le broker démarre mais ne sera pas redémarré si la connexion échoue.
#start_type automatic
# Définir le nombre de messages qui doivent être mis en file d'attente pour
# un pont avec type de démarrage paresseux pour être redémarré. Par défaut à 10 messages.
# Doit être inférieur à max_queued_messages.
#threshold 10
# Si try_private est défini sur true, le pont tentera d'indiquer au broker
# distant qu'il s'agit d'un pont et non d'un client ordinaire. Si réussi,
# cela signifie que la détection de boucle sera plus efficace et que les
# messages conservés seront propagés correctement. Tous les brokers ne
# supportent pas cette fonctionnalité, il peut donc être nécessaire de définir
# try_private sur false si votre pont ne se connecte pas correctement.
#try_private true
# -----------------------------------------------------------------
# Support SSL/TLS basé sur les certificats
# -----------------------------------------------------------------
# Soit bridge_cafile soit bridge_capath doit être défini pour activer le support
# TLS pour ce pont.
# bridge_cafile définit le chemin vers un fichier contenant les certificats
# d'autorité de certification qui ont signé le certificat du broker distant.
# bridge_capath définit un répertoire qui sera recherché pour des fichiers
# contenant les certificats CA. Pour que bridge_capath fonctionne correctement,
# les fichiers de certificat doivent avoir ".crt" comme extension de fichier et vous
# devez exécuter "openssl rehash <chemin vers capath>" chaque fois que vous
# ajoutez/supprimez un certificat.
#bridge_cafile
#bridge_capath
# Si le broker distant a plus d'un protocole disponible sur son port, par exemple
# MQTT et WebSockets, alors utilisez bridge_alpn pour configurer quel protocole
# est demandé. Notez que le support WebSockets pour les ponts n'est pas encore
# disponible.
#bridge_alpn
# Lors de l'utilisation du chiffrement basé sur les certificats, bridge_insecure
# désactive la vérification du nom d'hôte du serveur dans le certificat du serveur.
# Ceci peut être utile lors des tests de configurations de serveur initiales,
# mais rend possible pour un tiers malveillant d'usurper votre serveur par exemple
# par spoofing DNS. Utilisez cette option en phase de test uniquement. Si vous avez
# besoin de recourir à cette option dans un environnement de production, votre
# configuration est défectueuse et il n'y a aucun point à utiliser le chiffrement.
#bridge_insecure false
# Chemin vers le certificat client encodé PEM, si requis par le broker distant.
#bridge_certfile
# Chemin vers la clé privée du client encodé PEM, si requis par le broker distant.
#bridge_keyfile
# -----------------------------------------------------------------
# Support TLS basé sur les clés pré-partagées
# -----------------------------------------------------------------
# Le chiffrement par clé pré-partagée fournit une alternative au chiffrement
# basé sur les certificats. Un pont peut être configuré pour utiliser PSK avec
# les options bridge_identity et bridge_psk. Il s'agit de l'identité PSK client,
# et de la clé pré-partagée en format hexadécimal sans "0x". Seul un des types
# de chiffrement par certificat et PSK peut être utilisé sur un
# pont à la fois.
#bridge_identity
#bridge_psk
# =================================================================
# Fichiers de configuration externes
# =================================================================
# Les fichiers de configuration externes peuvent être inclus en utilisant
# l'option include_dir. Ceci définit un répertoire qui sera recherché
# pour des fichiers de configuration. Tous les fichiers qui se terminent
# par '.conf' seront chargés comme un fichier de configuration. Il est
# préférable d'avoir ceci comme dernière option dans le fichier principal.
# Cette option ne sera traitée que depuis le fichier de configuration principal.
# Le répertoire spécifié ne doit pas contenir le fichier de configuration
# principal.
# Les fichiers dans include_dir seront chargés triés dans l'ordre alphabétique
# sensible à la casse, avec les lettres majuscules classées en premier. Si cette
# option est donnée plusieurs fois, tous les fichiers de la première instance
# seront traités avant la suivante. Voir la page de manuel pour des exemples.
#include_dir
Avec cette configuration, la page web peut accéder via le port 9988, en réalité c'est via websockets.
Voici un exemple d'implémentation JavaScript pour se connecter à un serveur MQTT via WebSockets :
<html>
<head>
<meta charset="utf-8" />
<title>Client MQTT Web</title>
<style>
body { font-family: Arial, sans-serif; margin: 20px; }
.container { max-width: 800px; margin: 0 auto; }
.input-group { margin-bottom: 15px; }
.input-group input { padding: 8px; width: 70%; }
.input-group button { padding: 8px 15px; margin-left: 10px; }
#messages { border: 1px solid #ddd; padding: 10px; height: 200px; overflow-y: scroll; margin-top: 20px; }
.message { margin-bottom: 5px; padding: 5px; border-bottom: 1px solid #eee; }
</style>
</head>
<body>
<div class="container">
<h1>Client MQTT Web</h1>
<div class="input-group">
<input type="text" id="messageInput" placeholder="Entrez votre message" />
<button id="sendButton">Envoyer</button>
</div>
<div class="input-group">
<input type="text" id="topicInput" placeholder="Sujet (ex: capteur/temp)" />
<button id="subscribeButton">S'abonner</button>
<button id="unsubscribeButton">Se désabonner</button>
</div>
<div id="messages"></div>
</div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/paho-mqtt/1.1.0/paho-mqtt.min.js"></script>
<script>
// Configuration du client MQTT
const brokerAddress = '192.168.0.3';
const brokerPort = 9988;
const clientId = `webClient_${Math.random().toString(16).substr(2, 8)}`;
const username = 'admin';
const password = 'password';
// État de l'application
let currentTopic = '';
let isConnected = false;
// Création du client MQTT
const client = new Paho.MQTT.Client(brokerAddress, brokerPort, clientId);
// Options de connexion
const options = {
timeout: 5,
keepAliveInterval: 60,
useSSL: false,
userName: username,
password: password,
onSuccess: onConnect,
onFailure: onFailure
};
// Connexion au broker
client.connect(options);
// Gestion de la connexion réussie
function onConnect() {
isConnected = true;
addMessage('Connecté au broker MQTT', 'success');
console.log('Connecté au broker MQTT');
}
// Gestion de l'échec de connexion
function onFailure(responseObject) {
isConnected = false;
addMessage(`Échec de connexion: ${responseObject.errorMessage}`, 'error');
console.error('Échec de connexion:', responseObject.errorMessage);
}
// Gestion de la perte de connexion
client.onConnectionLost = function(responseObject) {
isConnected = false;
if (responseObject.errorCode !== 0) {
addMessage(`Connexion perdue: ${responseObject.errorMessage}`, 'error');
console.log('Connexion perdue:', responseObject.errorMessage);
}
};
// Gestion des messages reçus
client.onMessageArrived = function(message) {
const topic = message.destinationName;
const payload = message.payloadString;
addMessage(`[${topic}] ${payload}`, 'message');
console.log(`Message reçu sur ${topic}: ${payload}`);
};
// Ajouter un message à l'interface
function addMessage(text, type) {
const messagesDiv = document.getElementById('messages');
const messageDiv = document.createElement('div');
messageDiv.className = `message ${type}`;
messageDiv.textContent = text;
messagesDiv.appendChild(messageDiv);
messagesDiv.scrollTop = messagesDiv.scrollHeight;
}
// Envoyer un message
document.getElementById('sendButton').addEventListener('click', function() {
const messageInput = document.getElementById('messageInput');
const messageText = messageInput.value.trim();
if (!isConnected) {
addMessage('Non connecté au broker', 'error');
return;
}
if (!currentTopic) {
addMessage('Veuillez d\'abord vous abonner à un sujet', 'warning');
return;
}
if (messageText) {
const message = new Paho.MQTT.Message(messageText);
message.destinationName = currentTopic;
client.send(message);
addMessage(`Message envoyé: ${messageText}`, 'success');
messageInput.value = '';
} else {
addMessage('Le message ne peut pas être vide', 'warning');
}
});
// S'abonner à un sujet
document.getElementById('subscribeButton').addEventListener('click', function() {
const topicInput = document.getElementById('topicInput');
const topic = topicInput.value.trim();
if (!isConnected) {
addMessage('Non connecté au broker', 'error');
return;
}
if (topic) {
currentTopic = topic;
client.subscribe(topic, { qos: 1 });
addMessage(`Abonné au sujet: ${topic}`, 'success');
console.log(`Abonné au sujet: ${topic}`);
} else {
addMessage('Veuillez entrer un sujet', 'warning');
}
});
// Se désabonner d'un sujet
document.getElementById('unsubscribeButton').addEventListener('click', function() {
if (!isConnected) {
addMessage('Non connecté au broker', 'error');
return;
}
if (currentTopic) {
client.unsubscribe(currentTopic);
addMessage(`Désabonné du sujet: ${currentTopic}`, 'success');
console.log(`Désabonné du sujet: ${currentTopic}`);
currentTopic = '';
} else {
addMessage('Aucun sujet actuel', 'warning');
}
});
// Gérer la touche Entrée dans les champs de saisie
document.getElementById('messageInput').addEventListener('keypress', function(e) {
if (e.key === 'Enter') {
document.getElementById('sendButton').click();
}
});
document.getElementById('topicInput').addEventListener('keypress', function(e) {
if (e.key === 'Enter') {
document.getElementById('subscribeButton').click();
}
});
</script>
</body>
</html>
Cet exemple implémente une interface web complète pour interagir avec un broker MQTT via WebSockets. Il inclut:
- Une connexino sécurisée au broker avec authentification
- La possibilité de s'abonner et de se désabonner de sujets
- L'envoi de messages à des sujets spécifiques
- Une interface utilisateur pour afficher les messages reçus
- Une gestion appropriée des erreurs et des états de connexion
L'interface est responsive et utilise un design moderne avec CSS pour une meilleure expérience utilisateur. Le code est également bien commenté pour faciliter la compréhension et la modification.