Le nœud delay Node-RED retient les messages pendant un temps donné ou les libère à un débit fixe, ce qui en fait le moyen le plus simple de dompter des flux MQTT rapides. Dans ce tutoriel, vous allez l'utiliser pour réguler des données de capteurs haute fréquence avant publication, limiter le débit de chaque topic séparément, choisir entre mise en file et abandon, contrôler la file à l'exécution et rester confortablement sous les limites du broker.
Pourquoi la limitation de débit compte dans les flows MQTT
Un capteur échantillonné toutes les 100 millisecondes produit dix messages par seconde. Multipliez par quelques dizaines de capteurs et Node-RED envoie des centaines de messages par seconde vers ce qui se trouve en aval. Souvent, rien en aval n'a besoin d'un tel débit :
- Les brokers imposent des limites. Les brokers partagés et publics plafonnent le débit de messages par client. Le serveur MQTT public gratuit
broker.connectmq.com, par exemple, autorise 10 messages par seconde et par client. Au-delà, les messages sont rejetés ou le client est bridé. - Les tableaux de bord ne suivent pas. Un graphique de navigateur redessiné 50 fois par seconde est illisible et gaspille du CPU.
- Les bases de données et les API facturent à l'écriture. Écrire chaque échantillon brut dans une base cloud ou appeler une API HTTP à chaque message coûte cher et peut déclencher les limites de débit de l'API.
- Les notifications agacent. Une température qui oscille autour d'un seuil peut générer des dizaines d'alertes par minute.
Le nœud delay Node-RED résout tous ces problèmes sans code.
Les modes du nœud delay en un coup d'œil
Ouvrez un nœud delay : le menu déroulant Action propose deux familles de comportements :
| Mode | Option | Effet | Usage typique |
|---|---|---|---|
| Retarder chaque message | Délai fixe | Retient chaque message pendant la même durée | Anti-rebond, séquencement d'actions |
| Retarder chaque message | Délai aléatoire | Retient chaque message pendant une durée aléatoire dans une plage | Étalement de la charge, simulation d'appareils |
| Retarder chaque message | Délai remplacé par msg.delay |
Utilise le délai en millisecondes fourni par le message | Temporisation par message |
| Limitation de débit | Tous les messages | Libère au plus N messages par intervalle | Protéger un broker ou une API |
| Limitation de débit | Pour chaque msg.topic |
Limite chaque topic indépendamment en gardant la dernière valeur | Régulation multi-capteurs |
Le mode délai n'abandonne jamais rien ; il décale seulement les messages dans le temps. Le mode limitation de débit met en file les messages excédentaires ou les abandonne, selon l'option choisie.
Mettre en file ou abandonner : la décision qui compte
En mode limitation de débit avec All messages, le comportement par défaut est la mise en file : les messages au-delà du débit attendent en mémoire et sont libérés un par un. Cochez drop intermediate messages et les messages excédentaires sont abandonnés à la place. Les versions récentes de Node-RED permettent aussi d'envoyer les messages intermédiaires vers une seconde sortie, pour router le surplus ailleurs, par exemple vers un compteur.
Choisissez en vous demandant si chaque message compte :
- Chaque message compte (commandes, événements, comptages) : mettez en file. Assurez-vous que le débit d'entrée moyen est inférieur au débit de libération, sinon la file grossit indéfiniment.
- Seule la dernière valeur compte (températures, niveaux, positions) : abandonnez, ou utilisez le mode par topic. Vous gardez des données fraîches et la mémoire reste stable.
- Vous avez besoin des deux : envoyez le surplus vers la seconde sortie et agrégez-le, par exemple en moyenne.
Une file qui grossit sans limite est la panne classique du nœud delay. Si les producteurs dépassent le débit de libération pendant des heures, la mémoire grimpe jusqu'à ce que Node-RED ralentisse ou plante. Vous pouvez plafonner les files globalement avec le paramètre nodeMessageBufferMaxLength de settings.js, mais la meilleure solution est de choisir l'abandon pour la télémétrie.
Exemple : réguler un capteur rapide avant publication
Simulez un capteur bruité et régulez-le à un message toutes les deux secondes avant de le republier sur un topic de synthèse. Remplacez 3e5b par votre propre chaîne aléatoire pour garder des topics uniques sur le serveur public.
[
{"id":"tabdl","type":"tab","label":"Delay demo"},
{"id":"brkdl","type":"mqtt-broker","name":"ConnectMQ public","broker":"broker.connectmq.com","port":"1883","clientid":"nr-delay-3e5b","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true},
{"id":"tick","type":"inject","z":"tabdl","name":"every 200 ms","props":[{"p":"payload","v":"","vt":"date"}],"repeat":"0.2","once":true,"onceDelay":"1","x":130,"y":80,"wires":[["sim"]]},
{"id":"sim","type":"function","z":"tabdl","name":"simulate vibration","func":"msg.topic = 'connectmq/demo/3e5b/press1/vibration';\nmsg.payload = { mm_s: Number((2 + Math.random() * 3).toFixed(2)), ts: msg.payload };\nreturn msg;","outputs":1,"x":330,"y":80,"wires":[["rate"]]},
{"id":"rate","type":"delay","z":"tabdl","name":"1 msg / 2 s, drop","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"2","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"allowrate":false,"outputs":1,"x":540,"y":80,"wires":[["pub","dbgdl"]]},
{"id":"pub","type":"mqtt out","z":"tabdl","name":"publish","topic":"","qos":"0","retain":"false","broker":"brkdl","x":730,"y":60,"wires":[]},
{"id":"dbgdl","type":"debug","z":"tabdl","name":"released","active":true,"complete":"payload","x":740,"y":110,"wires":[]}
]
Cinq messages par seconde entrent ; un message toutes les deux secondes sort, toujours une mesure fraîche. Observez le résultat depuis un terminal :
mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-3e5b \
-t "connectmq/demo/3e5b/#" -v
Sans le nœud delay, ce flow publierait cinq messages par seconde depuis un seul client, soit déjà la moitié de la limite par client du serveur public. Ajoutez un second capteur et vous atteindriez la limite.
Limitation de débit par topic pour de nombreux capteurs
Lorsqu'un seul nœud mqtt in s'abonne avec un wildcard comme connectmq/demo/3e5b/+/telemetry, une limitation de débit simple traite tous les topics comme un seul flux. Un capteur bavard évincerait alors un capteur discret. Passez le nœud delay en Rate limit → For each msg.topic.
Dans ce mode, le nœud ne garde que le message le plus récent de chaque topic et les libère au débit configuré, en parcourant les topics à tour de rôle. Chaque capteur a son tour, et seule sa dernière valeur est envoyée. C'est exactement ce que veulent un tableau de bord ou un processus d'écriture en base. Vérifiez que msg.topic est correctement défini ; si tous les messages ont le même topic, le mode par topic se comporte comme une file unique d'un seul élément.
Contrôler la file à l'exécution
Un nœud delay en mode mise en file écoute des propriétés spéciales sur les messages entrants :
| Propriété | Effet |
|---|---|
msg.reset |
Vide la file sans rien envoyer |
msg.flush |
Envoie immédiatement les messages en file ; un nombre en envoie autant |
msg.rate |
En mode limitation de débit avec l'option « allow msg.rate to override », modifie le débit en millisecondes entre messages |
msg.delay |
En mode remplacement, définit le délai de ce message en millisecondes |
msg.reset est utile quand une machine s'arrête : les mesures en file d'avant l'arrêt n'ont plus de sens. msg.flush aide lorsqu'une connexion revient et que vous voulez libérer d'un coup les commandes mises en tampon. Reliez un nœud inject avec la propriété définie sur true pour les essayer.
Anti-rebond des alertes avec un délai
Les limitations de débit guérissent aussi les tempêtes d'alertes. Placez un nœud delay limité à un message toutes les 10 minutes avec drop intermediate messages avant un nœud de notification par e-mail ou messagerie. La première alerte part immédiatement ; les répétitions dans la fenêtre sont abandonnées. Pour des alertes par appareil, définissez msg.topic sur l'identifiant de l'appareil et utilisez le mode par topic, afin qu'un appareil ne puisse pas masquer l'alarme d'un autre. Si vous préférez garder cette logique dans du code, l'exemple de temporisation de notre guide des subflows Node-RED fait la même chose par topic.
Liste des erreurs courantes
- Mettre la télémétrie en file. Utilisez l'abandon ou le mode par topic quand seule la dernière valeur compte.
- Limiter le débit après l'étape coûteuse. Placez le nœud delay avant les écritures en base, les appels HTTP ou les nœuds function lourds, pas après.
msg.topicmanquant. Le mode par topic exige un topic significatif sur chaque message.- Confondre délai et limitation de débit. Le mode délai décale chaque message ; il ne réduit pas leur nombre.
- Réguler à la mauvaise couche. Si les appareils publient bien plus vite que nécessaire, corrigez la fréquence d'échantillonnage du firmware au lieu de jeter des données dans Node-RED.
- Ignorer les limites du broker. Connaissez les limites de débit et de taille de messages de votre broker et restez en dessous.
Pour les transformations avant ou après la régulation, consultez le guide du nœud function Node-RED, et pour les bases du câblage MQTT dans Node-RED, le tutoriel Node-RED MQTT. Les options du nœud delay sont aussi documentées dans l'aide intégrée et dans la documentation des nœuds de base de Node-RED.
Publiez des données régulées sur ConnectMQ
Une fois que votre flow publie à un débit raisonnable, passez-le sur un broker privé. ConnectMQ est un broker MQTT managé avec TLS sur le port 8883, l'expiration des messages MQTT 5 et des quotas par offre qui protègent chaque client contre le flood. L'offre Serverless gratuite prend en charge jusqu'à 25 connexions et des messages de 256 Ko, et les offres Serverless payantes ajoutent QoS 2 et les shared subscriptions quand vous montez en charge. Créez votre broker sur app.connectmq.com sans carte bancaire, puis passez le nœud broker en TLS avec vos identifiants générés. Pour comparer les modèles de déploiement, lisez notre guide du broker MQTT cloud.
Questions fréquentes
Quelle est la différence entre délai et limitation de débit dans le nœud delay Node-RED ?
Le mode délai retient chaque message pendant un certain temps mais laisse passer tous les messages. Le mode limitation de débit contrôle le nombre de messages qui sortent par intervalle et peut mettre en file ou abandonner les messages excédentaires.
Comment limiter le débit de chaque topic MQTT séparément dans Node-RED ?
Réglez l'action du nœud delay sur Rate limit et choisissez « For each msg.topic ». Le nœud garde le dernier message par topic et libère les topics à tour de rôle au débit configuré.
Comment vider la file d'un nœud delay ?
Envoyez un message avec msg.reset défini sur n'importe quelle valeur. La file est vidée sans envoyer les messages qui s'y trouvaient.
Le nœud delay peut-il causer des problèmes de mémoire ?
Oui, s'il met des messages en file plus vite qu'il ne les libère pendant de longues périodes. Utilisez l'abandon ou le mode par topic pour la télémétrie, ou limitez la taille de la file avec nodeMessageBufferMaxLength dans settings.js.
