Oui comme indiqué dans la doc, ce paramètre ne doit être utilisé que si la température interne est fiable ce qui n’est pas du tout ton cas, vu le yoyo qu’elle fait.
Après quelques jours, tu devrais pouvoir maintenant essayer les auto-regulation (d’abord une légère, …).
Postes moi les courbes au format plotly (cf readme) si tu as besoin d’aide pour le tuning. Si le thermomètre interne fait du yoyo tu vas en avoir besoin.
Merci @Jean-Marc_Collin d’être intervenu sur ce post.
Pour ton information, il ne s’agit pas ici d’une intégration avec le cloud, on est sur réseau local en modbus.
Effectivement j’ai oublié de parler de ce paramètre à @ChrysM34.
Il est important de comprendre que ce paramètre est utile dans le cas de split.
Dans notre cas, un gainable, avec un thermostat déporté et donc une prise de température à un endroit clé de la pièce, il ne faut pas l’utiliser, et je dirais même que l’auto-régulation n’est pas nécessaire car bien géré par le système. En tout cas c’est mon ressenti.
De mon côté j’ai quand même des ratés de remonté dans vtherm, mes enfants ont encore tendance à modifier directement sur les thermostats et ça ne remonte pas dans le vtherm.
Faut que je creuse le sujet.
Hello @bouracho
Même causes, même punition et pas de solutions.
Exact, c’est ce que j’avais constaté dans mes logs, mais j’avais des doutes sur mon utilisation de modbus (pas l’intégration décrite ici). Merci pour ton retour
Une question : les UE ont des puissances qui diminue avec le froid - hors la puissance requise pour gérer la temp ambiante, augmente avec le delta de température - ce qui impacte le temps de réponse, et génère une oscillation plus forte autour de la consigne
Est ce que vous imaginez que l’on peut approximer la courbe de puissance de l’UE (courbe constructeur) et ainsi modifier les paramètres de puissance du Vtherm?
Bonsoir @sinseman44 ,
je voulais retester ton integration suite à la correction du mutex mais impossible de la lancer après installation, j’obtiens :
dans les logs j’ai :
Si j’installe la 0.2.1 ça passe…
si tu as une idée…
Une des évolutions entre la v0.2.2 et la v0.2.1 est la mise à jour de la version de la librairie pymodbus. je suis passé de la version 3.5.4 (qui datait un peu) à la version 3.7.4 (qui a corrigé un bug de connexion pour l’installation de @ChrysM34). Ce qui a entrainé de redéfinir un import d’une classe de pymodbus dans l’intégration.
- from pymodbus.transaction import ModbusRtuFramer
+ from pymodbus.framer.rtu import FramerRTU
A quel moment tu as rencontré le message d’erreur ? directement lorsque tu lances la configuration de l’intégration ? ou la configuration se passe bien et c’est après ?
Quelle est ta version de Home Assistant Core et Supervisor ?
Je pense que la mise à jour de l’intégration n’a pas du te mettre à jour la librairie pymodbus.
Essaie de forcer une réinstallation de la version v0.2.2 via HACS.
Bonjour @sinseman44,
Voila ce que j’ai fait hier :
J’ai désinstallé toutes traces (je pense) des installations passées de ton intégration.
J’ai fait un reboot complet de HA.
L’installation de la 0.2.2 passe mais dès que je vais dans intégration>ajouter une intégration, j’ai ce message quand je selectionne ton intégration.
Si je désinstalle et que je fais l’installation de la 0.2.1, ça passe.
J’ai alors la maj 0.2.2 proposée mais je ne l’ai pas tenté.
Voici mes versions HA:
OK, donc mes doutes se confirment bien => cannot import name 'FramerType' from 'pymodbus' · pymodbus-dev/pymodbus · Discussion #2192 · GitHub
Maintenant, pourquoi il ne te pousse pas la bonne version de pymodbus à l’installation de l’intégration ?? je ne sais pas.
Tu as d’autres intégrations qui utilisent pymodbus ? J’ai une autre personne qui m’a remonté un bug parce qu’il utilisait une autre intégration modbus (Huawai solar integration en l’occurence) avec une autre version (3.6.9) de la librairie pymodbus.
Je viens également de faire le test sur mon HA (supprimer mon intégration et redémarrer HA) et tout réinstaller et je n’ai pas de problème.
Je vois que l’on a des différences de versions de HA (Core et OS). Voici ce que j’ai :
Peut-être qu’en mettant à jour HA Core et OS, ca résoudrait le problème (seulement une hypothèse).
Essaie de re-forcer le téléchargement de la version v0.2.2 via HACS
dernière possibilité, si tu n’y arrives toujours pas. Après téléchargement de la version v0.2.2, avant de lancer la configuration, modifie le fichier custom_components/koolnova_bms/koolnova/operations.py (ligne 13) et remplace :
from pymodbus.framer.rtu import FramerRTU
par
from pymodbus.transaction import ModbusRtuFramer
Le yoyo était artificiel c’est moi qui essayait de reproduire le bug (et ca a marché).
Je partagerai ça prochainement (déplacement toute la semaine et je fini suffisamment tard pour faire dormir les yeux direct).
Salut @sinseman44,
enchainement de jour rouge tempo, je testerai ce weekend, je préfère ne rien toucher pour le moment 
Je te comprends, je suis dans le même cas. Je fais pause jusqu’à ce weekend.
J’ai pu avancer : installation des cartes plotly et configuration dans la partie Affichage. J’ai rajouté un titre à la carte standard que tu proposes ici : https://github.com/jmcollin78/versatile_thermostat/blob/main/documentation/fr/additions.md#some-results
Mais pour le moment je ne peux rien te partager d’utile car :
Salut @sinseman44,
j’ai mis à jour HA dans les mêmes versions que toi et réinstallé ton intégration → même pb
L’autre intégration modbus que j’ai est tout simplement l’intégration native « modbus »
En regardant sur le git de HA je suis tombé sur ça dans la branche master :
Par contre dans la branche dev on a :
Je vais désactiver l’intégration native ou modifier ton code pour voir si ça vient de là
ben
bonsoir @sinseman44,
j’ai fait quelques tests ce soir et j’ai un doute sur le fonctionnement du mutex (ou une mauvaise compréhension de ma part).
J’ai installé la version 0.2.2 et j’ai fait la modif dont tu parles plus haut pour fonctionner avec pymodbus 3.6.9 (afin de garder l’intégration native fonctionnelle au cas ou)
A partir de là j’ai pu faire la configuration de l’intégration.
J’ai voulu tester une partie de mon automatisation « jour rouge » qui consiste à passer mes thermostats koolnova à 19° entre 5h et 6h pour préchauffer la maison.
Voici l’automatisation que j’ai écrite pour les tests :
alias: test integration koolnova
description: ""
triggers:
- at: "21:41:00"
trigger: time
conditions: []
actions:
- action: climate.set_temperature
metadata: {}
data:
hvac_mode: heat
temperature: 19
target:
entity_id:
- climate.koolnova_chambre_1
- climate.koolnova_chambre_2
- climate.koolnova_salon_sam
- climate.koolnova_chambre_3
mode: single
Dans ce cas, j’ai que 1 ou 2 thermostats qui passent à 19 en fonction de mes différents tests.
J’avais compris qu’en intégrant la notion de « mutex » au niveau de l’intégration cela permettrait de faire une file d’attente pour envoyer les requètes 1 à 1 au koolnova avec un délai permettant la prise en compte.
Par contre si je fais l’automatisation suivante en laissant 100ms entre chaque action, pas de soucis. En dessous de 100ms ça commence à déconner
alias: test integration koolnova
description: ""
triggers:
- at: "22:34:00"
trigger: time
conditions: []
actions:
- action: climate.set_temperature
metadata: {}
data:
temperature: 19
target:
entity_id: climate.koolnova_chambre_1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 100
- action: climate.set_temperature
metadata: {}
data:
temperature: 19
target:
entity_id: climate.koolnova_chambre_3
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 100
- action: climate.set_temperature
metadata: {}
data:
temperature: 19
target:
entity_id: climate.koolnova_salon_sam
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 100
- action: climate.set_temperature
metadata: {}
data:
temperature: 19
target:
entity_id: climate.koolnova_chambre_2
enabled: true
mode: single
Est ce que je fais fausse route ?
Ben
Salut @bouracho,
Comme la liaison Modbus est en Half-duplex (sur 2 fils), l’intégration ne peut (doit) faire qu’une action à la fois (action: requête de lecture ou d’écriture par le client et retour de l’état de la requête par le serveur) sous peine d’avoir des collisions de trames entrainant des erreurs de communication.
C’est pourquoi les fonctions de lecture et d’écriture de registres sont maintenant considérés comme des « sections protégées ». C’est à dire qu’on sérialise l’accès de sorte qu’une section protégée ne puisse être exécutée que par une seule tâche à la fois. La section protégée devient alors mutuellement exclusive (MUT-EX). Si le verrou est acquis, les tâches se bloquent et attendent l’accès.
De plus, dans la spécification Modbus sur RS485, un « délai de silence » doit être mise en place pour permettre la détection de la fin d’une trame et éviter les collisions ou les erreurs sur le bus de communication. Ce délai de silence minimal doit être de 3,5 fois le temps d’un caractère (1 bit de start, 8 bits de données et 1 bit de stop).
En théorie, à 9600 bauds, un caractère est envoyé en 1,04ms donc un délai de silence minimum serait de 3,5 x 1,04 = 3,64ms. (je suppose que tout ceci est pris en compte dans la librairie pymodbus 
).
On est quand même loin des 100ms que tu décris. 
Théoriquement, d’après ton automatisme, les 4 tâches asynchrones d’envoi de requêtes d’écriture d’une nouvelle consigne de température devrait envoyer la première requête (blocage des 3 autres), puis fin de la première requête (avec retour d’état) et déblocage de la section protégée pour la deuxième requête (blocage pour les 2 dernières) et ainsi de suite.
Est-ce que dans tes tests, tu as activé le debug de l’application et/ou de la librairie pymodbus ? j’ai ce log à chaque écriture vers le serveur (dans la section protégée) :
_LOGGER.debug("writing single register: {} - Slave: {} - Val: {}".format(hex(reg), self._addr, hex(val)))
Ca permettrait de voir si les 4 requêtes sont bien passées de manière « séquentielle ». et les logs de la librairie permettrait de voir les trames Modbus envoyées/reçues par HA.
(désolé pour le pavé de lecture 
)
Au contraire @sinseman44 un super pavé que j’ai pris plaisir à lire et qui me conforte dans ma compréhension (même si je pensais que seul les écritures posées pb) mais qui ne correspond pas à ce que je constate malheureusement.
J’avais activé les logs (en cochant la case pas dans le fichier configuration.yaml) et je n’ai vu qu’une écriture passée.
Je vais refaire des tests et te tiens au courant
bonsoir @sinseman44 ,
je continue mes tests ce soir.
J’ai désactivé l’intégration native modbus.
J’ai réinstallé ton intégration, je suppose que pymodbus s’est maj car je n’ai pas fait la modification dans le code
j’ai activé les logs de l’integration (fichier configuration.yaml)
Mon tests est une automatisation qui bascule 4 thermostats koolnova à 15° en même temps :
alias: test integration koolnova
description: ""
triggers:
- at: "19:12:00"
trigger: time
conditions: []
actions:
- action: climate.set_temperature
metadata: {}
data:
temperature: 15
target:
entity_id:
- climate.koolnova_chambre_esteban
- climate.koolnova_chambre_jules
- climate.koolnova_chambre_parents
- climate.koolnova_salon_sam
enabled: true
Voici ce que j’obtiens au niveau des logs
e[36m2024-12-20 19:12:00.237 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [Climate 5] set target temp - kwargs: {'temperature': 15.0, 'entity_id': ['climate.koolnova_chambre_esteban', 'climate.koolnova_chambre_jules', 'climate.koolnova_chambre_parents', 'climate.koolnova_salon_sam']}e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.device] idx found: 4e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] writing single register: 0x12 - Slave: 49 - Val: 0x1ee[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [Climate 1] set target temp - kwargs: {'temperature': 15.0, 'entity_id': ['climate.koolnova_chambre_esteban', 'climate.koolnova_chambre_jules', 'climate.koolnova_chambre_parents', 'climate.koolnova_salon_sam']}e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.device] idx found: 0e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [Climate 4] set target temp - kwargs: {'temperature': 15.0, 'entity_id': ['climate.koolnova_chambre_esteban', 'climate.koolnova_chambre_jules', 'climate.koolnova_chambre_parents', 'climate.koolnova_salon_sam']}e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.device] idx found: 3e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [Climate 3] set target temp - kwargs: {'temperature': 15.0, 'entity_id': ['climate.koolnova_chambre_esteban', 'climate.koolnova_chambre_jules', 'climate.koolnova_chambre_parents', 'climate.koolnova_salon_sam']}e[0m
e[36m2024-12-20 19:12:00.238 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.device] idx found: 2e[0m
e[36m2024-12-20 19:12:00.323 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] writing single register: 0x2 - Slave: 49 - Val: 0x1ee[0m
e[36m2024-12-20 19:12:00.412 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] writing single register: 0xe - Slave: 49 - Val: 0x1ee[0m
e[36m2024-12-20 19:12:00.495 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] writing single register: 0xa - Slave: 49 - Val: 0x1ee[0m
e[36m2024-12-20 19:12:00.573 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding registers: 0x0 - count: 64 - Slave: 49e[0m
e[36m2024-12-20 19:12:00.804 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x40 - Slave: 49e[0m
e[36m2024-12-20 19:12:00.889 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x48 - Slave: 49e[0m
e[36m2024-12-20 19:12:00.964 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x44 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.041 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x41 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.118 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x49 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.196 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x45 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.272 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x42 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.349 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x4a - Slave: 49e[0m
e[36m2024-12-20 19:12:01.427 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x46 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.530 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x43 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.607 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x4b - Slave: 49e[0m
e[36m2024-12-20 19:12:01.686 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x47 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.795 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x51 - Slave: 49e[0m
e[36m2024-12-20 19:12:01.874 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x4e - Slave: 49e[0m
e[36m2024-12-20 19:12:01.951 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x50 - Slave: 49e[0m
e[36m2024-12-20 19:12:02.027 DEBUG (MainThread) [custom_components.koolnova_bms.coordinator] Finished fetching koolnova_bms data in 1.705 seconds (success: True)e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC1] Troughput: 0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC1] Order temp: 0.0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC2] Troughput: 0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC2] Order temp: 0.0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC3] Troughput: 0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC3] Order temp: 15.0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC4] Troughput: 0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.sensor] [UPDATE] [ENGINE AC4] Order temp: 0.0e[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.select] [UPDATE] Global Mode: GlobalMode.HEATe[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.select] [UPDATE] Efficiency: Efficiency.LOWER_EFFe[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.select] [UPDATE] [ENGINE AC1] Order temp: FlowEngine.AUTOe[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.select] [UPDATE] [ENGINE AC2] Order temp: FlowEngine.AUTOe[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.select] [UPDATE] [ENGINE AC3] Order temp: FlowEngine.AUTOe[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.select] [UPDATE] [ENGINE AC4] Order temp: FlowEngine.AUTOe[0m
e[36m2024-12-20 19:12:02.028 DEBUG (MainThread) [custom_components.koolnova_bms.switch] [UPDATE] Switch State: Truee[0m
e[36m2024-12-20 19:12:02.029 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [UPDATE] [Climate 1] temp:20.0 - target:17.0 - state: ZoneState.STATE_ON - hvac:ZoneClimMode.HEAT - fan:ZoneFanMode.FAN_AUTOe[0m
e[36m2024-12-20 19:12:02.029 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [UPDATE] [Climate 2] temp:17.5 - target:18.0 - state: ZoneState.STATE_OFF - hvac:ZoneClimMode.HEAT - fan:ZoneFanMode.FAN_AUTOe[0m
e[36m2024-12-20 19:12:02.029 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [UPDATE] [Climate 3] temp:20.0 - target:17.0 - state: ZoneState.STATE_ON - hvac:ZoneClimMode.HEAT - fan:ZoneFanMode.FAN_AUTOe[0m
e[36m2024-12-20 19:12:02.029 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [UPDATE] [Climate 4] temp:19.0 - target:15.0 - state: ZoneState.STATE_ON - hvac:ZoneClimMode.HEAT - fan:ZoneFanMode.FAN_AUTOe[0m
e[36m2024-12-20 19:12:02.029 DEBUG (MainThread) [custom_components.koolnova_bms.climate] [UPDATE] [Climate 5] temp:18.0 - target:15.0 - state: ZoneState.STATE_ON - hvac:ZoneClimMode.HEAT - fan:ZoneFanMode.FAN_AUTOe[0m
Pour moi ils ne passent pas tous à 15 et je ne comprends pas pourquoi.
Dans les logs on voit les 4 « writing single register » mais après le refresh de l’intégration seulement 2 y sont passés
Arrive tu as reproduire ce simple cas ?
Merci d’avance
ben
Merci @bouracho pour tes logs.
C’est intéressant puisque les logs révèlent que ton automatisme passe par la fonction async def async_set_temperature() de l’entité climate et que cette fonction est appelée 4x puisque tu passes en paramètre les 4 entity_id.
La particularité de cette fonction (async_set_temperature()) est qu’elle appelle la fonction asynchrone (section protégée) d’écriture d’un registre (envoi du nouveau paramètre de température) et qu’elle se met ensuite en attente de la fonction asynchrone de mise à jour de tous les attributs du système pour garantir d’avoir une image « à jours » des toutes les informations à disperser sur les différentes entités de l’intégration (polling des infos à déployer sur toutes les entités).
La boucle d’évènements de HA a (d’après les logs) empilé les 4 tâches (climate n°5, puis n°1 puis n°4 et enfin n°3) d’écriture de registres (section protégée) pour chaque zone (climate) puis a due empiler les 4 tâches de lecture de registres pour la mise à jour des informations (je n’en voit qu’une sur tes logs qui doit être incomplet).
La boucle d’évènement exécute la première tâche (climate n°5 - registre 0x12 (hexa) = 18 (décimal)), acquiert le mutex, écrit le registre avec la nouvelle température (avec retour d’état du système koolnova), relâche le mutex puis passe la main à la seconde tâche (climate n°1 - registre 0x2 (hexa) = 2 (decimal)), puis la 3eme tâche (climate n°4 - registre 0xe (hexa) = 14 (décimal)), puis la 4ème (climate n°3 - registre 0xa (hexa) = 10 (décimal)), etc …
Voila pour la théorie.
Maintenant en pratique, d’après tes logs, seules les entités climate n°5 et n°4 ont la consigne de température modifiée à 15°C. Pourquoi ? bonne question !
Ca serait intéressant de refaire le test avec les logs de l’intégration ET les logs de pymodbus pour peut-être identifier une collision de trame ou autre erreur par la librairie pymodbus.
Ce qui m’embête également dans cet automatisme, c’est qu’en appelant la fonction set_temperature de l’entité climate, on va forcément empiler plusieurs fois dans la boucle d’évènement HA, la fonction de mise à jour de toutes les informations du système (inutile, car redondant, puisque l’on va bloquer le canal de communication pour x fois 1,7 secondes en moyenne).
Merci pour cette réponse pleine d’explications.
Je n’avais pas activé les logs pymodbus car vraiment très verbeux.
Je pense avoir tous mis en terme de log mais je vais refaire des essais.
Pour le fonctionnement de « set_temperature » je ne vois pas trop comment faire autrement.
Si je sépare par des actions unitaire, il va aussi faire l’appel x fois.
Je continue mes tests aujourd’hui et te fournis d’autres logs.
Penses tu que l’utilisation du module wifi (et non série) engendre une latence qui influerait sur la durée d’execution ?