Auto-update blog content from Obsidian: 2026-04-29 20:40:29

content/post/6-ac-automation-home-assistant-node-red/index.fr.md

@@ -37,7 +37,7 @@ Node-RED ne remplace pas Home Assistant, il le renforce. Je ne détaillerai pas
 ## Ancien Workflow
 
 J’avais déjà une solution plutôt efficace pour contrôler ma climatisation via Home Assistant et Node-RED, mais je voulais l’améliorer pour qu’elle prenne aussi en compte le taux d’humidité dans l’appartement. Mon workflow actuel, bien qu’il fonctionne, n’était pas vraiment évolutif et assez difficile à maintenir :  
-![Ancien workflow Node-RED pour contrôler la climatisation](img/node-red-ha-ac-automation-before.png)
+![Ancien workflow Node-RED pour contrôler la climatisation](images/node-red-ha-ac-automation-before.png)
 
 ## Nouveau Workflow
 
@@ -54,12 +54,12 @@ Pour m’aider à faire tout ça, j’utilise 4 [capteurs de température et d
 ### Workflow
 
 Laissez-moi vous présenter mon nouveau workflow de climatisation dans Node-RED, et vous expliquer en détail comment il fonctionne :  
-![New Node-RED air conditioning workflow](img/node-red-new-ac-workflow-with-legend.png)
+![Nouveau workflow Node-RED pour la climatisation](images/node-red-new-ac-workflow-with-legend.png)
 
 #### #### 1. Capteurs de Température
 
 Dans le premier nœud, j’ai regroupé tous les capteurs thermiques dans un seul `trigger state node`, en ajoutant non seulement la température mais aussi le taux d’humidité géré par chaque capteur. Ce nœud contient donc une liste de 8 entités (2 pour chaque capteur). À chaque fois qu’une de ces 8 valeurs change, le nœud est déclenché :  
-![Nœud trigger state dans Node-RED avec les 8 entités](img/node-red-temperature-sensors-trigger-node.png)
+![Nœud trigger state dans Node-RED avec les 8 entités](images/node-red-temperature-sensors-trigger-node.png)
 
 Chacun de mes capteurs thermiques porte un nom de couleur en français, car ils ont tous un autocollant coloré pour les distinguer :
 - **Jaune** : Salon
@@ -93,7 +93,7 @@ return msg;
 ```
 
 Pour le dernier nœud, dans la majorité des cas, les capteurs envoient deux messages simultanés : l’un pour la température, l’autre pour l’humidité. J’ai donc ajouté un `join node` pour fusionner ces deux messages s’ils sont envoyés dans la même seconde :  
-![Join node in Node-RED to merge temperature and humidity](img/node-red-temperature-sensor-join-node.png)
+![Nœud join dans Node-RED pour fusionner température et humidité](images/node-red-temperature-sensor-join-node.png)
 
 #### 2. Notification
 
@@ -132,17 +132,17 @@ return null; // Don't send anything now
 ```
 
 Le second nœud est un `call service node` qui envoie une notification sur mon téléphone Android avec les informations fournies :  
-![Node-RED call service node for notification](img/node-red-call-service-node-notification.png)
+![Nœud call service dans Node-RED pour envoyer une notification](images/node-red-call-service-node-notification.png)
 
 #### 3. Curseurs de Température
 
 Pour pouvoir ajuster la température sans avoir à modifier tout le workflow, j’ai créé deux entrées (ou helper) Home Assistant, de type number, pour chaque unité de climatisation, ce qui me fait un total de 6 entrées :  
-![Curseur de température dans Home Assistant pour chaque unité](img/home-assistant-temperature-room-sliders.png)
+![Curseur de température dans Home Assistant pour chaque unité](images/home-assistant-temperature-room-sliders.png)
 
 Ces valeurs représentent la température de base utilisée pour le calcul des seuils, en fonction des offsets que je détaillerai plus loin.
 
 Le premier nœud est un `trigger state node` qui regroupe les 6 entités. Si je modifie l’une de ces valeurs, le nœud est déclenché :  
-![Node-RED trigger state node for sliders](img/node-red-trigger-state-mode-for-sliders.png)
+![Nœud trigger state dans Node-RED pour les curseurs](images/node-red-trigger-state-mode-for-sliders.png)
 
 Le deuxième nœud est un `function node`, qui permet de déterminer la pièce concernée :
 ```js
@@ -164,17 +164,17 @@ return msg;
 Dans Home Assistant, j’utilise d’autres entrées, mais cette fois sous forme de booléens. Le plus important est celui dédié à la climatisation, qui me permet de désactiver manuellement tout le workflow. J’en ai d’autres qui sont automatisés, par exemple pour le moment de la journée ou la détection de présence à la maison.
 
 J’utilise un autre `trigger state node` qui regroupe tous mes interrupteurs sous forme de booléens, y compris un bouton de test utilisé pour le débogage :  
-![Node-RED trigger state node for toggles](img/node-red-trigger-state-node-toggles.png)
+![Nœud trigger state dans Node-RED pour les interrupteurs](images/node-red-trigger-state-node-toggles.png)
 
 Comme ces interrupteurs impactent tout l’appartement (et non une seule unité), le nœud suivant est un `change node` qui définit la valeur de la pièce à `partout` :  
-![Node-RED change node to set room to partout](img/node-red-change-node-room-partout.png)
+![Nœud change dans Node-RED pour définir la pièce sur partout](images/node-red-change-node-room-partout.png)
 
 #### 5. Fenêtres
 
 Les derniers déclencheurs sont les fenêtres. Si j’ouvre ou ferme une fenêtre située près d’une unité, cela active le workflow. J’ai des capteurs d’ouverture sur certaines fenêtres, mais pour l’unité du couloir, j’utilise l’état des fenêtres Velux. Certaines pièces ayant plusieurs fenêtres, j’ai créé une entrée de type groupe pour les regrouper.
 
 Le premier nœud est le dernier `trigger state node`. La valeur retournée est une string qu’il faudra ensuite convertir en booléen :  
-![Node-RED trigger state node for windows](img/node-red-trigger-state-node-windows.png)
+![Nœud trigger state dans Node-RED pour les fenêtres](images/node-red-trigger-state-node-windows.png)
 
 Juste après, un autre `function node` permet d’identifier la pièce concernée :
 ```js
@@ -195,20 +195,20 @@ return msg;
 Quand j’ouvre une fenêtre, ce n’est pas forcément pour la laisser ouverte longtemps. Je peux simplement faire sortir le chat ou jeter un œil au portail. Je ne veux pas que la climatisation se coupe dès que j’ouvre une fenêtre. Pour contourner cela, j’ai mis en place un watchdog pour chaque unité, afin de retarder l’envoi du message pendant un certain temps.
 
 Le premier nœud est un `switch node`. En fonction de la pièce transmise par le nœud précédent, il envoie le message au _watchdog_ correspondant :  
-![Node-RED switch node based on the room for the watchdog](img/node-red-switch-node-room-selector-watchdog.png)
+![Nœud “switch” dans Node-RED basé sur la pièce pour diriger vers le bon _watchdog_](images/node-red-switch-node-room-selector-watchdog.png)
 
 Viennent ensuite les _watchdogs_, des `trigger nodes`, qui retardent le message pendant un certain temps, et prolongent ce délai si un autre message est reçu entre-temps :  
-![Node-RED trigger node for window watchdog](img/node-red-trigger-node-window-watchdog.png)
+![Nœud “trigger” dans Node-RED pour la surveillance des fenêtres](images/node-red-trigger-node-window-watchdog.png)
 
 #### 7. Climatisation Activée ?
 
 Tous ces déclencheurs arrivent maintenant dans la chaîne de traitement, qui va déterminer ce que le système doit faire. Mais avant cela, on vérifie si l’automatisation est activée. J’ai ajouté ce kill switch au cas où, même si je l’utilise rarement.
 
 Le premier nœud est un `delay node` qui régule le débit des messages entrants à 1 message par seconde :  
-![Node-RED delay node to limit the rate to 1 message per second](img/node-red-delay-node-1-msg-per-second.png)
+![Nœud delay dans Node-RED pour limiter le débit à 1 message par seconde](images/node-red-delay-node-1-msg-per-second.png)
 
 Le deuxième nœud est un `current state node` qui vérifie si le booléen `climatisation` est activé :  
-![Node-RED current state node for climatisation](img/node-red-current-state-node-climatisation-enabled.png)
+![Nœud current state dans Node-RED pour l’état de la climatisation](images/node-red-current-state-node-climatisation-enabled.png)
 
 #### 8. Configuration des pièces
 
@@ -223,7 +223,7 @@ Les unités de climatisation disposent de 4 modes :
 Pour déterminer quel mode utiliser, j’utilise des seuils pour chaque mode et la vitesse de ventilation, avec différents offsets selon la situation. Je peux ainsi définir un offset spécifique la nuit ou en cas d’absence. Je peux aussi définir un offset sur `disabled`, ce qui forcera l’arrêt de l’unité.
 
 Le premier nœud est un `switch node`, basé sur la valeur `room`, qui oriente le message vers la configuration associée. Si la pièce est `partout`, le message est dupliqué vers les 3 configurations de pièce :  
-![Node-RED switch node for room configuration](img/node-red-switch-node-room-config.png)
+![Nœud “switch” dans Node-RED pour sélectionner la configuration en fonction de la pièce](images/node-red-switch-node-room-config.png)
 
 Il est ensuite connecté à un `change node`, qui ajoute la configuration dans `room_config`. Voici un exemple avec la configuration du salon :
 ```json
@@ -445,13 +445,13 @@ return msg;
 ```
 
 Le troisième nœud est un `filter node`, qui ignore les messages suivants ayant un contenu similaire :  
-![Node-RED filter node to block similar message](img/node-red-filter-node-blocker.png)
+![Nœud de filtrage dans Node-RED pour bloquer les messages identiques](images/node-red-filter-node-blocker.png)
 
 Le quatrième nœud vérifie si un verrou est actif à l’aide d’un `current state node`. On regarde si le minuteur associé à l’unité est inactif. Si ce n’est pas le cas, le message est ignoré :  
-![Node-RED current state node for timer lock](img/node-red-current-state-node-lock-timer.png)
+![Nœud current state dans Node-RED pour vérifier le verrou temporaire](images/node-red-current-state-node-lock-timer.png)
 
 Le dernier nœud est un autre `current state node` qui permet de récupérer l’état actuel de l’unité et ses propriétés :  
-![Node-RED current state node to get current unit state](img/node-red-current-state-node-get-unit-state.png)
+![Nœud current state dans Node-RED pour obtenir l’état actuel de l’unité](images/node-red-current-state-node-get-unit-state.png)
 
 #### 10. État Cible
 
@@ -608,17 +608,17 @@ return msg;
 #### 11. Choix de l'Action
 
 En fonction de l’action à effectuer, le `switch node` va router le message vers le bon chemin :  
-![Node-RED `switch node` pour sélectionner l’action](img/node-red-switch-node-select-action.png)
+![Node-RED `switch node` pour sélectionner l’action](images/node-red-switch-node-select-action.png)
 
 #### 12. Démarrage
 
 Lorsque l’action est `start`, il faut d’abord allumer l’unité. Cela prend entre 20 et 40 secondes selon le modèle, et une fois démarrée, l’unité est verrouillée pendant un court laps de temps pour éviter les messages suivants.
 
 Le premier nœud est un `call service node` utilisant le service `turn_on` sur l’unité de climatisation :  
-![Node-RED call service node with turn_on service](img/node-red-call-service-node-turn-on.png)
+![Nœud `call service` dans Node-RED avec le service `turn_on`](images/node-red-call-service-node-turn-on.png)
 
 Le second nœud est un autre `call service node` qui va démarrer un minuteur de verrouillage (lock timer) pour cette unité pendant 45 secondes :  
-![Node-RED call service node to start the unit timer](img/node-red-call-service-node-start-timer.png)
+![Nœud `call service` dans Node-RED pour démarrer le minuteur de l’unité](images/node-red-call-service-node-start-timer.png)
 
 Le dernier est un `delay node` de 5 secondes, pour laisser le temps à l’intégration Daikin de Home Assistant de refléter le nouvel état.
 
@@ -629,12 +629,12 @@ Le dernier est un `delay node` de 5 secondes, pour laisser le temps à l’inté
 L’action `change` est utilisée pour passer d’un mode à un autre, mais aussi juste après l’allumage.
 
 Le premier nœud est un `call service node` utilisant le service `set_hvac_mode` sur l’unité de climatisation :  
-![Node-RED call service node with set_hvac_mode service](img/node-red-call-service-node-set-hvac-mode.png)
+![Nœud `call service` dans Node-RED avec le service `set_hvac_mode`](images/node-red-call-service-node-set-hvac-mode.png)
 
 Le nœud suivant est un `delay node` de 5 secondes.
 
 Le dernier vérifie, avec un `switch node`, si la température cible doit être définie. Cela n’est nécessaire que pour les modes `cool` et `heat` :  
-![Node-RED switch node for set_temp](img/node-red-switch-node-set-temp.png)
+![Nœud `switch` dans Node-RED pour définir la température cible](images/node-red-switch-node-set-temp.png)
 
 ---
 
@@ -643,7 +643,7 @@ Le dernier vérifie, avec un `switch node`, si la température cible doit être
 La température cible est uniquement pertinente pour les modes `cool` et `heat`. Avec une climatisation classique, vous définissez une température à atteindre — c’est exactement ce qu’on fait ici. Mais comme chaque unité utilise son propre capteur interne pour vérifier cette température, je ne leur fais pas vraiment confiance. Si la température cible est déjà atteinte selon l’unité, elle ne soufflera plus du tout.
 
 Le premier nœud est un autre `call service node` utilisant le service `set_temperature` :  
-![Node-RED call service node with set_temperature service](img/node-red-call-service-node-set-temperature-service.png)
+![Nœud `call service` dans Node-RED avec le service `set_temperature`](images/node-red-call-service-node-set-temperature-service.png)
 
 Encore une fois, ce nœud est suivi d’un `delay node` de 5 secondes.
 
@@ -652,20 +652,20 @@ Encore une fois, ce nœud est suivi d’un `delay node` de 5 secondes.
 L’action `check` est utilisée presque tout le temps. Elle consiste uniquement à vérifier et comparer la vitesse de ventilation souhaitée, et à la modifier si nécessaire.
 
 Le premier nœud est un `switch node` qui vérifie si la valeur `speed` est définie :  
-![Node-RED switch node to test if speed is defined](img/node-red-switch-node-fan-speed.png)
+![Nœud switch dans Node-RED pour tester si la vitesse est définie](images/node-red-switch-node-fan-speed.png)
 
 Le deuxième est un autre `switch node` qui compare la valeur `speed` avec la vitesse actuelle :  
-![Node-Red switch node to compare speed](img/node-red-switch-node-compare-speed.png)
+![Nœud switch dans Node-RED pour comparer la vitesse](images/node-red-switch-node-compare-speed.png)
 
 Enfin, le dernier nœud est un `call service node` utilisant le service `set_fan_mode` pour définir la vitesse du ventilateur :  
-![Node-RED call service node with set_fan_mode](img/node-red-call-service-node-set-fan-mode.png)
+![Nœud `call service` dans Node-RED avec le service `set_fan_mode`](images/node-red-call-service-node-set-fan-mode.png)
 
 #### 16. Arrêt
 
 Lorsque l’action est `stop`, l’unité de climatisation est simplement arrêtée.
 
 Le premier nœud est un `call service node` utilisant le service `turn_off` :  
-![Node-RED call service node with turn_off service](img/node-red-call-service-node-turn-off.png)
+![Nœud `call service` dans Node-RED avec le service `turn_off`](images/node-red-call-service-node-turn-off.png)
 
 Le deuxième nœud est un autre `call service node` qui va démarrer le minuteur de verrouillage de cette unité pour 45 secondes.
 
@@ -675,7 +675,7 @@ Parfois, pour une raison ou une autre, on souhaite utiliser la climatisation man
 Node-RED utilise son propre utilisateur dans Home Assistant, donc si une unité change d’état sans cet utilisateur, c’est qu’une intervention manuelle a eu lieu.
 
 Le premier nœud est un `trigger state node`, qui envoie un message dès qu’une unité AC change d’état :  
-![node-red-trigger-state-unit-change.png](img/node-red-trigger-state-unit-change.png)
+![node-red-trigger-state-unit-change.png](images/node-red-trigger-state-unit-change.png)
 
 Le deuxième est un `function node` qui associe l’unité avec son minuteur :
 ```js
@@ -690,13 +690,13 @@ return msg;
 ```
 
 Le troisième est un `switch node` qui laisse passer le message uniquement si le `user_id` **n’est pas** celui de Node-RED :  
-![Node-RED switch node not specific user_id](img/node-red-switch-node-user-id.png)
+![Nœud `switch` dans Node-RED pour vérifier que ce n’est pas l’ID utilisateur Node-RED](images/node-red-switch-node-user-id.png)
 
 Le quatrième est un autre `switch node` qui vérifie que le champ `user_id` **est bien défini** :  
-![Node-RED switch node check user_id not null](img/node-red-switch-node-check-user-id.png)
+![Nœud `switch` dans Node-RED pour vérifier que `user_id` n’est pas nul](images/node-red-switch-node-check-user-id.png)
 
 Enfin, le dernier nœud est un `call service node` utilisant le service `start` sur le minuteur de l’unité, avec sa durée par défaut (60 minutes) :  
-![Node-RED call service node start timer with default duration](img/node-red-call-service-node-start-unit-timer.png)
+![Nœud `call service` dans Node-RED pour démarrer le minuteur avec la durée par défaut](images/node-red-call-service-node-start-unit-timer.png)
 
 ## TL;DR
 

content/post/6-ac-automation-home-assistant-node-red/index.md

@@ -37,7 +37,7 @@ Node-RED does not replace Home Assistant, it empowers it. I won't cover the inst
 ## Previous Workflow
 
 I was already having a good solution to control my AC from Home Assistant with Node-RED, but I wanted to enhance it to also handle the humidity level at home. My current workflow, despite being functional, was not really scalable and quite hard to maintain:  
-![Ancien workflow Node-RED pour contrôler la climatisation](img/node-red-ha-ac-automation-before.png)
+![Old Node-RED workflow to control air conditioning](images/node-red-ha-ac-automation-before.png)
 
 ## New Workflow
 
@@ -54,12 +54,12 @@ To help me achieve that, I'm using 4 [Aqara temperature and humidity sensors](ht
 ### Workflow
 
 Let me introduce my new AC workflow within Node-RED and explain what it does in detail:  
-![New Node-RED air conditioning workflow](img/node-red-new-ac-workflow-with-legend.png)
+![New Node-RED air conditioning workflow](images/node-red-new-ac-workflow-with-legend.png)
 
 #### 1. Temperature Sensors
 
 In the first node, I combined all the temperature sensors together in one `trigger state node`, but I also added humidity levels in addition to the temperature, managed by the sensor. The node then contains 8 entities in a list (2 for each of my sensor). Each time one value change out of these 8 entities, the node is triggered:  
-![Nœud trigger state dans Node-RED avec les 8 entités](img/node-red-temperature-sensors-trigger-node.png)
+![Trigger state node in Node-RED with all 8 entities](images/node-red-temperature-sensors-trigger-node.png)
 
 Each of my temperature sensors are named with a color in French, because each has its own color sticker to distinguish them:
 - **Jaune**: Living room
@@ -93,7 +93,7 @@ return msg;
 ```
 
 For the last node, most of the time, the sensors will send two messages at the same time, one containing the temperature value and the other, the humidity level. I added a `join node` to combined the two messages if they are sent within the same second:  
-![Join node in Node-RED to merge temperature and humidity](img/node-red-temperature-sensor-join-node.png)
+![Join node in Node-RED to merge temperature and humidity](images/node-red-temperature-sensor-join-node.png)
 
 #### 2. Notification
 
@@ -132,17 +132,17 @@ return null; // Don't send anything now
 ```
 
 The second node is a `call service node` which send a notification on my Android device with the value given:  
-![Node-RED call service node for notification](img/node-red-call-service-node-notification.png)
+![Node-RED call service node for notification](images/node-red-call-service-node-notification.png)
 
 #### 3. Temperature Sliders
 
 To have a control over the temperature without having to change the workflow, I created two Home Assistant helper, as number, which I can adjust for each unit, giving me 6 helpers in total:  
-![Curseur de température dans Home Assistant pour chaque unité](img/home-assistant-temperature-room-sliders.png)
+![Home Assistant temperature slider for each unit](images/home-assistant-temperature-room-sliders.png)
 
 These values are the base temperature used for the calculation of the threshold, depending off the offset which I will detail further.
 
 The first node is a `trigger state node`, with all 6 entities combined. If I change one value, the node is triggered:  
-![Node-RED trigger state node for sliders](img/node-red-trigger-state-mode-for-sliders.png)
+![Node-RED trigger state node for sliders](images/node-red-trigger-state-mode-for-sliders.png)
 
 The second node is a `function node`, to determine the room affected:
 ```js
@@ -164,17 +164,17 @@ return msg;
 In Home Assistant, I'm using other helper but as boolean, the most important is the AC one, where I can manually disable the whole workflow. I have other which are automated, for the time of the day or for detect presence at home.
 
 I have another `trigger state node` with all my toggles as boolean, including a test button, for debug purpose:  
-![Node-RED trigger state node for toggles](img/node-red-trigger-state-node-toggles.png)
+![Node-RED trigger state node for toggles](images/node-red-trigger-state-node-toggles.png)
 
 As toggles affect the whole apartment and not a single unit, the next node is a `change node`, which set the room value to `partout` (everywhere):  
-![Node-RED change node to set room to partout](img/node-red-change-node-room-partout.png)
+![Node-RED change node to set room to partout](images/node-red-change-node-room-partout.png)
 
 #### 5. Windows
 
 The last triggers are my windows, if I open or close a window next to my unit, it triggers the workflow. I have door sensor for some of my doors, but for the hallway unit, I'm using the Velux windows state. Some rooms have more than one, I created a group helper for them.
 
 The first node is the last `trigger state node`, the returned value is a string which I will have to convert later into boolean:  
-![Node-RED trigger state node for windows](img/node-red-trigger-state-node-windows.png)
+![Node-RED trigger state node for windows](images/node-red-trigger-state-node-windows.png)
 
 Connected to it, again a `function node` to select the affect room:
 ```js
@@ -195,20 +195,20 @@ return msg;
 When I open a window, it is not necessarily to let it open for a long time. I could just let the cat out or having a look at my portal. I don't want my AC tuned off as soon as open it. To workaround that I created a watchdog for each unit, to delay the message for some time.
 
 The first node is a `switch node`, based on the room given by the previous node, it will send the message to the associated watchdog:  
-![Node-RED switch node based on the room for the watchdog](img/node-red-switch-node-room-selector-watchdog.png)
+![Node-RED switch node based on the room for the watchdog](images/node-red-switch-node-room-selector-watchdog.png)
 
 After are the watchdogs, `trigger nodes`, which will delay the message by some time and extend the delay if another message if received:  
-![Node-RED trigger node for window watchdog](img/node-red-trigger-node-window-watchdog.png)
+![Node-RED trigger node for window watchdog](images/node-red-trigger-node-window-watchdog.png)
 
 #### 7. AC Enabled ?
 
 All these triggers are now entering the computing pipeline, to determine what the system must do with the action. But before, it is checking if the automation is even enabled. I add this kill switch, just in case, but I rarely use it anyway.
 
 The first node is a `delay node` which regulate the rate of every incoming messages to 1 per second:  
-![Node-RED delay node to limit the rate to 1 message per second](img/node-red-delay-node-1-msg-per-second.png)
+![Node-RED delay node to limit the rate to 1 message per second](images/node-red-delay-node-1-msg-per-second.png)
 
 The second node is a `current state node` which checks if the `climatisation` boolean is enabled:  
-![Node-RED current state node for climatisation](img/node-red-current-state-node-climatisation-enabled.png)
+![Node-RED current state node for climatisation](images/node-red-current-state-node-climatisation-enabled.png)
 #### 8. Room Configuration
 
 The idea here is to attach the configuration of the room to the message. Each room have their own configuration, which unit is used, which sensors and more importantly, when should they be turned on and off. 
@@ -222,7 +222,7 @@ AC units have 4 mode which can be used:
 To determine which mode should be used, I'm using threshold for each mode and unit fan's speed, with different offset depending the situation. I can then define a offset during the night or when I'm away. I can also set the offset to `disabled`, which will force the unit to shut down.
 
 The first node is a `switch node`, based on the `room` value, which will route the message to the associated room configuration. When the room is `partout` (everywhere), the message is split to all 3 room configuration:  
-![Node-RED switch node for room configuration](img/node-red-switch-node-room-config.png)
+![Node-RED switch node for room configuration](images/node-red-switch-node-room-config.png)
 
 It is connected to a `change node` which will attach the configuration to the `room_config`, here an example with the living-room configuration:
 ```json
@@ -443,13 +443,13 @@ return msg;
 ```
 
 The third node is a `filter node`, which drops subsequent messages with similar payload:  
-![Node-RED filter node to block similar message](img/node-red-filter-node-blocker.png)
+![Node-RED filter node to block similar message](images/node-red-filter-node-blocker.png)
 
 The fourth node checks if any lock is set, with a `current state node`, we verify if the timer associated to the unit is idle. If not, the message is discarded:  
-![Node-RED current state node for timer lock](img/node-red-current-state-node-lock-timer.png)
+![Node-RED current state node for timer lock](images/node-red-current-state-node-lock-timer.png)
 
 The last node is another `current state node` which will fetch the unit state and properties:  
-![Node-RED current state node to get current unit state](img/node-red-current-state-node-get-unit-state.png)
+![Node-RED current state node to get current unit state](images/node-red-current-state-node-get-unit-state.png)
 
 #### 10. Target State
 
@@ -606,17 +606,17 @@ return msg;
 #### 11. Action Switch
 
 Based on the action to take, the `switch node` will route the message accordingly:  
-![Node-RED `switch node` pour sélectionner l’action](img/node-red-switch-node-select-action.png)
+![Node-RED switch node to select the action](images/node-red-switch-node-select-action.png)
 
 #### 12. Start
 
 When the action is `start`, we first need to turn the unit online, while this takes between 20 to 40 seconds depending on the unit model, it is also locking the unit for a short period for future messages.
 
 The first node is a `call service node` using the `turn_on` service on the AC unit:  
-![Node-RED call service node with turn_on service](img/node-red-call-service-node-turn-on.png)
+![Node-RED call service node with turn_on service](images/node-red-call-service-node-turn-on.png)
 
 The second node is another `call service node` which will start the lock timer of this unit for 45 seconds:  
-![Node-RED call service node to start the unit timer](img/node-red-call-service-node-start-timer.png)
+![Node-RED call service node to start the unit timer](images/node-red-call-service-node-start-timer.png)
 
 The last one is a `delay node` of 5 seconds, to give the time to the Home Assistant Daikin integration to resolve the new state.
 
@@ -625,19 +625,19 @@ The last one is a `delay node` of 5 seconds, to give the time to the Home Assist
 The `change` action is used to change from one mode to another, but also used right after the start action.
 
 The first node is a `call service node` using `the set_hvac_mode` service on the AC unit:  
-![Node-RED call service node with set_hvac_mode service](img/node-red-call-service-node-set-hvac-mode.png)
+![Node-RED call service node with set_hvac_mode service](images/node-red-call-service-node-set-hvac-mode.png)
 
 The following node is another delay of 5 seconds.
 
 The last one verify with a `switch node` if the target temperature needs to be set, this is only required for the modes `cool` and `heat`:  
-![Node-RED switch node for set_temp](img/node-red-switch-node-set-temp.png)
+![Node-RED switch node for set_temp](images/node-red-switch-node-set-temp.png)
 
 #### 14. Set Target Temperature
 
 The target temperature is only relevant for `cool` and `heat` mode, when you use a normal AC unit, you define a temperature to reach. This is exactly what is defined here. But because each unit is using its own internal sensor to verify, I don't trust it. If the value is already reached, the unit won't blow anything.
 
 The first node is another `call service node` using the `set_temperature` service:  
-![Node-RED call service node with set_temperature service](img/node-red-call-service-node-set-temperature-service.png)
+![Node-RED call service node with set_temperature service](images/node-red-call-service-node-set-temperature-service.png)
 
 Again, this node is followed by a `delay node` of 5 seconds
 
@@ -646,20 +646,20 @@ Again, this node is followed by a `delay node` of 5 seconds
 The `check` action is almost used everytime, it is actually only checks and compare the desired fan speed, it changes the fan speed if needed.
 
 The first node is a `switch node` which verify if the `speed` is defined:  
-![Node-RED switch node to test if speed is defined](img/node-red-switch-node-fan-speed.png)
+![Node-RED switch node to test if speed is defined](images/node-red-switch-node-fan-speed.png)
 
 The second is another `switch node` to compare the `speed` value with the current speed:  
-![Node-Red switch node to compare speed](img/node-red-switch-node-compare-speed.png)
+![Node-Red switch node to compare speed](images/node-red-switch-node-compare-speed.png)
 
 Finally the last node is a `call service node` using the `set_fan_mode` to set the fan speed:  
-![Node-RED call service node with set_fan_mode](img/node-red-call-service-node-set-fan-mode.png)
+![Node-RED call service node with set_fan_mode](images/node-red-call-service-node-set-fan-mode.png)
 
 #### 16. Stop
 
 When the `action` is stop, the AC unit is simply turned off
 
 The first node is a `call service noded` using the service `turn_off`:  
-![Node-RED call service node with turn_off service](img/node-red-call-service-node-turn-off.png)
+![Node-RED call service node with turn_off service](images/node-red-call-service-node-turn-off.png)
 
 The second node is another `call service node` which will start the lock timer of this unit for 45 seconds
 
@@ -668,7 +668,7 @@ The second node is another `call service node` which will start the lock timer o
 Sometime, for some reason, we want to use the AC manually. When we do, we don't want the workflow to change our manual setting, at least for some time. Node-RED is using its own user in Home Assistant, so when an AC unit change state without this user, this was manually done.
 
 The first node is a `trigger state node`, which will send a message when any AC unit is changing state:  
-![node-red-trigger-state-unit-change.png](img/node-red-trigger-state-unit-change.png)
+![node-red-trigger-state-unit-change.png](images/node-red-trigger-state-unit-change.png)
 
 The second is a `function node` which willassociate the unit with its timer:
 ```js
@@ -683,13 +683,13 @@ return msg;
 ```
 
 The third is a `switch node` that will let through the message when the user_id is not the Node-RED user's one:  
-![Node-RED switch node not specific user_id](img/node-red-switch-node-user-id.png)
+![Node-RED switch node not specific user_id](images/node-red-switch-node-user-id.png)
 
 The fourth is another `switch node` which checks if there are any `user_id`:  
-![Node-RED switch node check user_id not null](img/node-red-switch-node-check-user-id.png)
+![Node-RED switch node check user_id not null](images/node-red-switch-node-check-user-id.png)
 
 Lastly, the final node is a `call service node` using `start` service on the unit's timer with its default duration (60 minutes):  
-![Node-RED call service node start timer with default duration](img/node-red-call-service-node-start-unit-timer.png)
+![Node-RED call service node start timer with default duration](images/node-red-call-service-node-start-unit-timer.png)
 
 ## TL;DR