Node-RED S7 : lire les variables d'un automate Siemens et les publier sur MQTT

Les flows Node-RED S7 sont un moyen pratique de sortir les données des automates Siemens S7-1200, S7-1500 et des anciens S7-300/400 pour les amener dans MQTT, sans trop modifier le programme de l'automate. Dans ce tutoriel, vous allez préparer l'automate dans TIA Portal, lire des variables de blocs de données avec node-red-contrib-s7 et les publier en JSON sur un broker MQTT à chaque changement. Vous ajouterez aussi un chemin d'écriture protégé pour les consignes et découvrirez les règles d'adressage à l'origine de la plupart des échecs lors d'une première mise en œuvre.

Comment Node-RED communique avec un automate S7

node-red-contrib-s7 utilise le protocole de communication S7 (ISO-on-TCP, port 102), également employé par les outils d'ingénierie et les IHM Siemens. Node-RED agit en tant que client : il se connecte à la CPU, lit une liste d'adresses à un temps de cycle fixe et peut éventuellement réécrire des valeurs. Aucun matériel supplémentaire ni licence automate n'est nécessaire, mais la CPU doit autoriser ce type d'accès, que les CPU modernes bloquent par défaut.

Une fois les valeurs dans Node-RED, MQTT prend le relais pour la distribution. Au lieu que chaque tableau de bord, historien et outil d'analyse se connecte à l'automate, une seule passerelle le lit et un broker livre des valeurs nommées à tous les abonnés. Pour une comparaison plus large des approches, le guide Siemens S7 et MQTT traite aussi des clients MQTT natifs des automates et des passerelles commerciales.

Étape 1 : préparer l'automate dans TIA Portal

Pour les CPU S7-1200 et S7-1500, effectuez deux modifications et chargez-les dans l'automate :

1. Autoriser PUT/GET. Ouvrez les propriétés de la CPU, allez dans Protection & Security → Connection mechanisms et activez « Permit access with PUT/GET communication from remote partner ».
2. Désactiver l'accès optimisé aux blocs pour chaque bloc de données que Node-RED doit lire. Faites un clic droit sur le bloc de données, ouvrez Properties → Attributes et décochez « Optimized block access ». Compilez le bloc ; il affiche désormais des offsets fixes pour chaque variable.

C'est la seconde étape qui donne un sens aux adresses absolues comme DB10,REAL0. Avec l'accès optimisé, l'automate réorganise les variables en interne et le protocole S7 ne peut pas les adresser par offset.

L'accès PUT/GET est un compromis de sécurité : tout client qui atteint le port 102 peut lire et écrire ces zones. Gardez l'automate sur un réseau OT isolé, ne laissez que la passerelle l'atteindre et privilégiez un bloc de données dédié qui ne contient que les valeurs que vous voulez exposer.

Les CPU S7-300 et S7-400 n'ont pas besoin de ces réglages. Utilisez pour elles le rack 0 et le slot 2, au lieu du slot 1 pour les familles plus récentes.

Étape 2 : concevoir un bloc de données pour la passerelle

Créez un bloc de données non optimisé, par exemple DB10 "GatewayData", et copiez-y depuis votre programme les valeurs à publier. Un bloc dédié garde une interface stable même lorsque le programme principal évolue.

Les autres zones utilisent la même syntaxe : M0.0 et MW10 pour les mémentos, I0.0 et IW64 pour les entrées, Q0.1 pour les sorties, et DB10,S20.16 pour une chaîne à l'offset 20 d'une longueur maximale de 16. Prenez toujours les offsets dans le bloc de données compilé de TIA Portal, sans les compter à la main.

Étape 3 : installer et configurer node-red-contrib-s7

Installez le paquet :

cd ~/.node-red
npm install node-red-contrib-s7
# redémarrez Node-RED ensuite

Ajoutez un nœud s7 in et créez une nouvelle configuration d'endpoint :

• Transport : Ethernet (ISO-on-TCP)
• Adresse : l'adresse IP de l'automate, par exemple 192.168.0.10, port 102
• Mode : Rack/Slot, rack 0, slot 1 (S7-1200/1500)
• Temps de cycle : 1000 ms
• Timeout : 2000 ms

Dans l'onglet Variables, ajoutez chaque ligne du tableau ci-dessus avec un nom et une adresse. Configurez ensuite le nœud s7 in lui-même :

• Mode : « All variables », qui émet un message dont le payload est un objet contenant toutes les variables.
• Activez « Emit only when value changes » pour que les cycles sans changement ne produisent aucun message.

Déployez et ajoutez un nœud debug. Vous devriez voir des payloads comme {"temperature":61.4,"speed":1480,"running":true,"partCount":20391,"setpoint":60}. Le statut du nœud affiche « online » lorsque la connexion est saine.

Étape 4 : mettre en forme les données et publier sur MQTT

L'objet brut est presque prêt pour MQTT, mais il vaut la peine d'ajouter un horodatage, d'arrondir les flottants et de construire un topic qui reflète la place de la machine dans l'usine. Un nœud function s'en charge :

// Nœud function "s7 to mqtt"
const v = msg.payload;
if (typeof v !== "object" || v === null) {
    return null;
}

const round = (x, d) => Math.round(x * Math.pow(10, d)) / Math.pow(10, d);

msg.topic = "connectmq/demo/a7f3k2/plant1/line3/press2/telemetry";
msg.payload = {
    temperature: round(Number(v.temperature), 1),
    speed: Number(v.speed),
    running: v.running === true,
    partCount: Number(v.partCount),
    setpoint: round(Number(v.setpoint), 1),
    ts: Date.now()
};
return msg;

Reliez-le à un nœud mqtt out avec un champ topic vide. Pour les tests, utilisez broker.connectmq.com sur le port 1883 avec un client ID unique ; c'est le serveur MQTT public gratuit. Remplacez a7f3k2 par votre propre chaîne aléatoire et n'y envoyez jamais de vraies données de production, car n'importe qui peut s'y abonner.

Vérifiez depuis un terminal :

mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-s7-a7f3k2 -v \
  -t 'connectmq/demo/a7f3k2/plant1/#'

Si vous préférez un topic par variable, ce qui convient aux conceptions Unified Namespace, choisissez plutôt le mode « All variables, one per message ». Chaque message porte alors le nom de la variable dans msg.topic, et le nœud function peut l'ajouter au chemin de la machine.

Publiez aussi l'état de santé de la passerelle elle-même. Ajoutez un nœud status limité au nœud s7 in et publiez son texte sur .../press2/gateway/status avec retain activé. Les abonnés peuvent alors faire la différence entre « la machine s'est arrêtée » et « la passerelle a perdu l'automate ».

Étape 5 : écrire des consignes depuis MQTT, avec des garde-fous

Le nœud s7 out écrit une seule variable définie dans la configuration de l'endpoint. Un chemin de commande sûr ressemble à ceci :

1. Un nœud mqtt in s'abonne à un topic dédié, connectmq/demo/a7f3k2/plant1/line3/press2/setpoint/set. Sur un système réel, il doit s'agir d'un broker privé et authentifié.
2. Un nœud function valide la valeur.
3. Un nœud s7 out configuré pour la variable setpoint l'écrit.
4. Le cycle de lecture suivant publie la nouvelle consigne dans la télémétrie, ce qui fait office de confirmation.

// Nœud function "validate setpoint" -> s7 out (variable : setpoint)
const MIN = 40.0;
const MAX = 80.0;
const value = Number(msg.payload);

if (!Number.isFinite(value) || value < MIN || value > MAX) {
    node.warn(`Rejected setpoint ${msg.payload}; allowed ${MIN}-${MAX}`);
    return null;
}

msg.payload = Math.round(value * 10) / 10;
node.status({ fill: "blue", shape: "dot", text: "wrote " + msg.payload });
return msg;

Laissez l'automate responsable de la sécurité. Le programme automate doit toujours borner la consigne et l'ignorer dans les modes où les modifications à distance ne sont pas autorisées. Une passerelle qui écrit directement dans la logique de commande sans de tels contrôles dans l'automate est un accident en puissance.

Dépanner les connexions Node-RED S7

Un test rapide du port depuis la machine passerelle évite bien des suppositions :

# Linux : réussit si le port 102 est joignable
nc -zv 192.168.0.10 102

Check-list de production

1. Utilisez un bloc de données dédié et non optimisé comme interface de la passerelle.
2. Limitez l'accès réseau au port 102 à la seule passerelle.
3. Publiez sur changement avec un heartbeat périodique, pas à chaque cycle.
4. Publiez l'état de santé de la passerelle dans un topic de statut retenu.
5. Validez chaque écriture dans Node-RED, puis de nouveau dans l'automate.
6. Utilisez un broker MQTT privé avec TLS et des identifiants par passerelle.
7. Versionnez vos flows pour que les changements d'adresses soient relus.

Et ensuite, où vont les données ?

Une fois les valeurs S7 sur MQTT, tout le reste devient un abonné : tableaux de bord, calculs de TRS, historiens et analyses cloud. La même approche fonctionne pour d'autres contrôleurs, comme le montrent le guide Node-RED Modbus et le tutoriel Node-RED OPC UA pour les équipements Modbus et les serveurs OPC UA. Pour une vue plus large de la remontée des données d'automates hors de l'atelier, lisez le guide de l'automate vers le cloud.

La passerelle ne se connecte qu'en sortie vers le broker, ce qui garde le réseau OT fermé au trafic entrant. Un broker MQTT managé comme ConnectMQ fournit à cette passerelle un endpoint TLS sur le port 8883, des identifiants générés dans le portail et le blocage des adresses IP après des tentatives de connexion échouées répétées. ConnectMQ reconnaît aussi les topics de style ISA-95 comme plant1/line3/press2/telemetry et liste les équipements selon ces niveaux, pour voir d'un coup d'œil quelles machines remontent des données. Si vous en êtes encore aux choix d'architecture, commencez par ce que fait un broker MQTT, et consultez le tutoriel Node-RED MQTT pour les bases des nœuds MQTT.

Connectez votre passerelle S7 à ConnectMQ

Inscrivez-vous sur app.connectmq.com avec l'offre gratuite Serverless, sans carte bancaire. Créez un broker, collez le nom d'utilisateur, le mot de passe et le client ID générés dans le nœud de configuration MQTT de Node-RED, activez TLS sur le port 8883 et retirez le préfixe de démo. Les valeurs de votre automate sont alors publiées de façon privée, et vous pouvez les voir arriver dans l'explorateur de topics en direct.

Questions fréquentes

Quels automates Siemens fonctionnent avec node-red-contrib-s7 ?

Il prend en charge les S7-1200 et S7-1500 ainsi que les anciennes CPU S7-300 et S7-400 via Ethernet. Les familles récentes nécessitent l'activation de l'accès PUT/GET et des blocs de données non optimisés.

Pourquoi Node-RED n'arrive-t-il pas à lire mon bloc de données S7-1500 ?

Le bloc de données utilise très probablement l'accès optimisé, qui n'a pas d'offsets fixes. Désactivez-le dans les attributs du bloc, recompilez, chargez et utilisez les nouveaux offsets dans Node-RED.

Quel rack et quel slot utiliser pour un automate S7 ?

Utilisez le rack 0 et le slot 1 pour les CPU S7-1200 et S7-1500, et le rack 0 et le slot 2 pour la plupart des CPU S7-300 et S7-400.

Est-il sûr d'écrire des valeurs dans l'automate depuis MQTT ?

Uniquement avec des garde-fous : un topic de commande dédié sur un broker authentifié, une validation dans Node-RED et des contrôles de plage dans le programme automate lui-même.