Très sympa le tuto.
Quelques idées en vrac pour compléter au besoin :
Le node (désolé, j’utilise principalement les termes anglais par habitude) debug. Le node debug donc -disais-je- est ton meilleur ami. Foutez-en partout quand vous créez un flow (dans la fenêtre d’affichage du debug il est possible de choisir le node qui est affiché (all/flow/current node) pour s’y retrouver).
C’est le meilleur moyen de comprendre la structure de message de NodeRed.
A titre perso, je conseille toujours de foutre un events: all + debug pour commencer. On choppe tout ce qui passe, mais ça donne une idée justement de comment les choses passent. Après on filtre sur ce qui est intéressant dans le flow.
La logique de base de NodeRed est plus ou moins linéaire/mono-tâche. C’est à dire que chaque message est géré avant que le suivant ne puisse être pris en compte. Inutile d’espérer interrompre un flow avec un autre message, mais l’outil dispose de routines qui ne sont pas dans le flow à proprement parler qu’on peut lancer avec un message et interrompre avec (un des) le suivant.
Une fois compris la manière dont les messages sont structurés, il est facile de les éditer. Beaucoup de nodes prennent en compte le contenu du message dans leur exécution. Un call_service par exemple peut être défini dans sa fenêtre de paramètres à la création, mais également dans le message qui lui parvient.
On pourra alors jouer avec des nodes change qui permettront de modifier le message à la volée pour envoyer les instructions souhaitées au node d’action (call_service par exemple).
2c de contribution à un bel OP