Le nœud switch de Node-RED est le moyen le plus simple d'envoyer chaque message MQTT sur le bon chemin : les températures vers une branche, l'humidité vers une autre, les valeurs hors plage vers une alerte. Dans ce tutoriel, vous allez combiner le nœud switch avec le nœud change pour router les messages par topic et par valeur, remodeler les payloads sans écrire de JavaScript et republier des alertes propres vers un broker. Vous terminerez avec un flow importable que vous pourrez tester en deux minutes.
Pourquoi router les messages MQTT dans Node-RED
Un seul nœud mqtt in abonné à un wildcard comme sensors/# reçoit tout ce qui se trouve sous ce niveau. C'est pratique, car un abonnement en remplace des dizaines, mais cela signifie que chaque nœud en aval voit chaque message. Sans routage, vous finissez par écrire un gros nœud function rempli de if que personne n'a envie de maintenir.
Le nœud switch résout ce problème de manière déclarative. Il évalue une propriété du message par rapport à une liste de règles et envoie le message sur le port correspondant. Le nœud change modifie ensuite le message sur chaque branche : il définit un nouveau topic, déplace un champ, supprime le bruit ou calcule une valeur avec une expression JSONata. Ensemble, ils couvrent la plupart des besoins de routage, et la logique reste visible dans l'éditeur, où un collègue peut la comprendre d'un coup d'œil.
Si vous découvrez l'éditeur, commencez par le tutoriel Node-RED MQTT et revenez ici une fois votre connexion au broker opérationnelle.
Comment fonctionne le nœud switch de Node-RED
Ouvrez un nœud switch : trois paramètres comptent.
- Property (propriété). La valeur à tester. Par défaut
msg.payload, mais il peut s'agir demsg.topic, d'un champ imbriqué commemsg.payload.value, d'une variable de contexte flow ou global, ou d'une expression JSONata. - Rules (règles). Chaque règle crée un port de sortie. Les règles sont évaluées dans l'ordre.
- Mode de vérification. « Checking all rules » envoie le message sur chaque port correspondant. « Stopping after first match » ne l'envoie que sur la première correspondance. Pour le routage, vous voulez presque toujours la seconde option, afin qu'une valeur n'atterrisse jamais par accident dans deux branches.
Les types de règles que vous utiliserez le plus souvent sont listés ci-dessous.
| Règle | Ce qu'elle vérifie | Usage MQTT typique |
|---|---|---|
==, != |
Égalité exacte | État d'un appareil, comme ON ou OFF |
<, <=, >, >= |
Comparaison numérique | Alertes de seuil |
| is between | Plage inclusive | Plage de fonctionnement normale |
| contains | Sous-chaîne | Le topic contient /alarm/ |
| matches regex | Expression régulière | Le topic se termine par /temperature |
| is true / is false | Booléen | Indicateurs de porte ouverte |
| is null / is not null | Valeurs manquantes | Écarter les mesures incomplètes |
| is of type | string, number, object, buffer... | Rejeter les payloads mal formés |
| has key | L'objet possède une propriété | Champs optionnels |
| JSONata exp | Toute expression qui renvoie true | Conditions sur plusieurs champs |
| otherwise | Aucune autre règle n'a correspondu | Fourre-tout et journalisation |
Ajoutez toujours une règle otherwise à la fin. Elle ne coûte rien et c'est le premier endroit où vous regarderez quand un message semble disparaître.
Comment fonctionne le nœud change
Le nœud change applique une liste d'opérations au message, dans l'ordre :
- Set : définit une propriété avec une chaîne, un nombre, un booléen, du JSON, une autre propriété du message, une valeur de contexte, un horodatage ou une expression JSONata.
- Change : remplace une partie d'une chaîne, en texte brut ou par expression régulière, ce qui est pratique pour réécrire des topics.
- Delete : supprime une propriété, par exemple un champ de debug qu'un appareil inclut dans chaque message.
- Move : déplace une propriété vers un nouvel emplacement, par exemple remonter
msg.payload.valueversmsg.payload.
C'est JSONata qui rend le nœud change puissant. Dans une expression, payload et topic désignent msg.payload et msg.topic : $round(payload.value * 9 / 5 + 32, 1) convertit des degrés Celsius en Fahrenheit et $split(topic, "/")[4] extrait le cinquième niveau du topic. Vous obtenez des valeurs calculées sans nœud function et sans quitter l'éditeur visuel.
Le flow d'exemple : router par topic, puis par valeur
Le flow que vous allez importer fait ceci :
- Il s'abonne à
connectmq/demo/a7f3k2/sensors/#sur le serveur MQTT public gratuit avec le type de payload réglé sur JSON parsé. - Un premier nœud switch Node-RED route selon
msg.topic: température, humidité ou autre. - Un second nœud switch répartit les températures en trois plages selon
msg.payload.value. - Les plages basse et haute passent par un nœud change qui construit un topic et un payload d'alerte, puis un nœud
mqtt outles publie. - Les mesures normales, l'humidité et les topics inconnus vont vers des nœuds debug.
Remplacez partout a7f3k2 par votre propre chaîne aléatoire avant de déployer. Le serveur public est lisible par tous : un préfixe unique isole votre trafic de test, et vous ne devez jamais y envoyer de données sensibles. Le client ID doit lui aussi être unique et non vide.
[
{"id":"cmq_broker","type":"mqtt-broker","name":"ConnectMQ public","broker":"broker.connectmq.com","port":"1883","clientid":"nr-switch-a7f3k2","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true},
{"id":"in_all","type":"mqtt in","name":"all sensors","topic":"connectmq/demo/a7f3k2/sensors/#","qos":"1","datatype":"json","broker":"cmq_broker","nl":false,"rap":true,"rh":0,"inputs":0,"x":140,"y":160,"wires":[["sw_topic"]]},
{"id":"sw_topic","type":"switch","name":"by measurement","property":"topic","propertyType":"msg","rules":[{"t":"regex","v":"/temperature$","vt":"str","case":false},{"t":"regex","v":"/humidity$","vt":"str","case":false},{"t":"else"}],"checkall":"false","repair":false,"outputs":3,"x":350,"y":160,"wires":[["sw_temp"],["dbg_hum"],["dbg_other"]]},
{"id":"sw_temp","type":"switch","name":"temperature band","property":"payload.value","propertyType":"msg","rules":[{"t":"lt","v":"5","vt":"num"},{"t":"btwn","v":"5","vt":"num","v2":"30","v2t":"num"},{"t":"gt","v":"30","vt":"num"},{"t":"else"}],"checkall":"false","repair":false,"outputs":4,"x":560,"y":100,"wires":[["chg_alert"],["dbg_ok"],["chg_alert"],["dbg_other"]]},
{"id":"chg_alert","type":"change","name":"build alert","rules":[{"t":"delete","p":"payload.debug","pt":"msg"},{"t":"set","p":"payload","pt":"msg","to":"{\"room\": $split(topic, \"/\")[4], \"value\": payload.value, \"level\": payload.value > 30 ? \"high\" : \"low\", \"fahrenheit\": $round(payload.value * 9 / 5 + 32, 1)}","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"\"connectmq/demo/a7f3k2/alerts/\" & payload.room","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":790,"y":60,"wires":[["out_alert","dbg_alert"]]},
{"id":"out_alert","type":"mqtt out","name":"publish alert","topic":"","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"cmq_broker","x":1000,"y":40,"wires":[]},
{"id":"dbg_alert","type":"debug","name":"alert","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":990,"y":90,"wires":[]},
{"id":"dbg_ok","type":"debug","name":"normal temperature","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":800,"y":120,"wires":[]},
{"id":"dbg_hum","type":"debug","name":"humidity","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":560,"y":200,"wires":[]},
{"id":"dbg_other","type":"debug","name":"unrouted","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":800,"y":240,"wires":[]}
]
Importez-le via Menu → Import, collez le JSON, puis cliquez sur Deploy. Le nœud mqtt in doit afficher un statut vert « connected » en quelques secondes.
Remarquez deux détails dans le nœud change. Le payload est d'abord reconstruit, puis la règle du topic lit payload.room dans le nouveau payload. L'ordre des règles compte : chaque règle voit le message tel que la règle précédente l'a laissé. Remarquez aussi que le champ topic du nœud mqtt out est vide : il publie donc sur le msg.topic défini par le nœud change. Si vous renseignez le champ topic du nœud, il écrase msg.topic et votre routage dynamique cesse de fonctionner sans le moindre avertissement.
Tester le routage en ligne de commande
Publiez quelques messages de test avec les clients Mosquitto. Chaque commande utilise son propre client ID.
# Normal temperature -> "normal temperature" debug output
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-1 \
-t connectmq/demo/a7f3k2/sensors/room1/temperature -m '{"value": 22.5}'
# High temperature -> alert published to connectmq/demo/a7f3k2/alerts/room1
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-2 \
-t connectmq/demo/a7f3k2/sensors/room1/temperature -m '{"value": 34.2, "debug": "fw-1.2"}'
# Humidity -> "humidity" debug output
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-3 \
-t connectmq/demo/a7f3k2/sensors/room1/humidity -m '{"value": 48}'
# Unknown measurement -> "unrouted" debug output
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-4 \
-t connectmq/demo/a7f3k2/sensors/room1/co2 -m '{"value": 640}'
Dans un second terminal, surveillez le topic d'alerte pour vérifier que le nœud change a construit le message attendu :
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-a7f3k2 -v \
-t 'connectmq/demo/a7f3k2/alerts/#'
Vous devriez voir {"room":"room1","value":34.2,"level":"high","fahrenheit":93.6}, sans le champ debug. Si vous ne savez pas exactement ce que chaque niveau de QoS change à la livraison dans ce test, le guide des niveaux de QoS MQTT explique pourquoi le flow utilise le QoS 1 pour les alertes.
Des modèles de routage à réutiliser
Une fois le flow de base fonctionnel, ces modèles couvrent la plupart des projets réels :
- Router par type d'appareil avec un niveau de topic. Au lieu d'une regex, réglez la propriété du switch sur l'expression JSONata
$split(topic, "/")[3]et comparez-la avec des règles==. C'est plus lisible qu'une regex quand les topics suivent une hiérarchie stricte. - Valider avant de router. Placez un nœud switch juste après
mqtt inavec une règle « is of type: object ». Les payloads mal formés partent sur le portotherwise, où vous pouvez les journaliser au lieu de les laisser faire planter un nœud function plus loin. - Dédupliquer les changements d'état. Associez le nœud switch à un nœud filter (mode report-by-exception) pour qu'un capteur de porte qui publie
opentoutes les secondes ne déclenche votre branche que lorsque la valeur change. - Normaliser les unités tôt. Utilisez un nœud change juste après le routage pour convertir les unités et renommer les champs, afin que tout ce qui suit voie un seul schéma.
- Enrichir avec le contexte. Un nœud change peut définir
msg.payload.limità partir deflow.limits[room], et le nœud switch suivant peut comparer avecmsg.payload.limitau lieu d'un nombre codé en dur. Les seuils sont alors centralisés.
Quand les conditions dépassent une poignée de règles, ou nécessitent des boucles et un état, le nœud function est le meilleur outil. Le guide du nœud function de Node-RED couvre cette étape, et le tutoriel du nœud JSON explique comment les payloads chaîne et objet interagissent avec ces règles de routage.
Dépannage des nœuds switch et change
| Symptôme | Cause probable | Solution |
|---|---|---|
| Rien ne sort du nœud switch | Le payload est une chaîne, pas un objet | Réglez la sortie de mqtt in sur « a parsed JSON object » ou ajoutez un nœud JSON |
| Une règle numérique ne correspond jamais | La valeur arrive sous la forme "34.2" (chaîne) |
Convertissez avec un nœud change : $number(payload.value) |
| Le message apparaît dans deux branches | « Checking all rules » est sélectionné | Passez à « stopping after first match » |
| Les alertes partent sur le mauvais topic | Le champ topic est renseigné dans mqtt out |
Laissez-le vide pour que msg.topic soit utilisé |
| Erreur JSONata dans la barre de debug | L'expression fait référence à msg.payload |
Dans JSONata, utilisez payload, pas msg.payload |
| La regex correspond à trop de choses | Ancre manquante | Terminez les motifs par $, par exemple /temperature$ |
Une bonne habitude : donnez à chaque nœud switch et change un nom explicite. La barre de debug affiche le nom du nœud, et « temperature band » est bien plus facile à suivre que « switch ».
Migrer le flow vers un broker privé
Le serveur public est idéal pour apprendre, mais les flows de routage en production doivent tourner sur votre propre broker, avec identifiants et TLS. Créez un broker dans le portail ConnectMQ, puis modifiez le nœud de configuration mqtt-broker :
- Server : l'hôte affiché dans le portail, port
8883, Use TLS activé. - Onglet Security :
YOUR_USERNAMEetYOUR_PASSWORD. - Client ID :
YOUR_CLIENT_ID, car ConnectMQ lie les client IDs aux identifiants qu'il émet.
Tous les nœuds mqtt in et mqtt out partagent ce nœud de configuration : la logique de routage elle-même ne change pas. Vous pouvez ensuite abandonner le préfixe connectmq/demo/a7f3k2 et utiliser une vraie hiérarchie comme site/area/line/device/measurement. Utiliser un broker MQTT managé signifie aussi que vous n'avez pas à patcher et surveiller un processus broker à côté de Node-RED.
Faites tourner vos flows Node-RED sur ConnectMQ
Vos nœuds switch et change méritent un broker qui reste disponible pendant que vous itérez. Inscrivez-vous sur app.connectmq.com, choisissez l'offre gratuite Serverless (sans carte bancaire), créez un broker et collez le nom d'utilisateur, le mot de passe et le client ID générés dans votre nœud de configuration Node-RED. L'explorateur de topics en direct du portail affiche vos topics d'alerte en temps réel, ce qui accélère nettement la vérification de votre logique de routage.
Questions fréquentes
Quelle est la différence entre le nœud switch et le nœud change dans Node-RED ?
Le nœud switch décide où va un message en testant une propriété par rapport à des règles et en choisissant un port de sortie. Le nœud change modifie le message lui-même en définissant, modifiant, supprimant ou déplaçant des propriétés.
Le nœud switch de Node-RED peut-il router sur msg.topic ?
Oui. Réglez la propriété sur msg.topic et utilisez des règles « matches regex », « contains » ou ==. C'est la méthode standard pour répartir le trafic issu d'un seul abonnement MQTT avec wildcard.
Pourquoi ma règle numérique ne correspond-elle pas aux valeurs MQTT ?
Les payloads MQTT arrivent sous forme de texte, sauf si le nœud mqtt in les parse. Vérifiez que le nœud produit un objet JSON parsé et convertissez les champs chaîne avec $number() dans un nœud change avant la comparaison.
Faut-il utiliser un nœud function plutôt que les nœuds switch et change ?
Utilisez les nœuds switch et change pour le routage et les transformations simples, car ils sont plus faciles à lire et à relire. Passez au nœud function quand vous avez besoin de boucles, d'un état complexe ou d'une logique qui demanderait plus que quelques règles.
