Merci pour tout ce taf.
J essaie de tester ça ce week-end.
J en demande beaucoup mais crois tu que tu pourrais un jour intégrer une gestion des ouvrants pour couper le chauffage ?
Salut,
Ce n’est malheureusement pas la vocation de cette intégration. Son objectif premier étant de communiquer avec le contrôleur Koolnova.
Il me semblait que tu utilisais déjà Versatile Thermostat ? Parce que cette intégration le fait déjà.
Tu pourras, normalement, toujours utiliser versatile thermostat avec l’intégration Koolnova. Il faudra juste reconfigurer les thermostats de l’intégration versatile thermostat en indiquant les bonnes entités « climate » du koolnova.
Je comprends pas de soucis.
J ai eu quelques pb avec versatile, je suis en train de debug pour essayer de comprendre si c’est versatile ou autre chose
Je voulais utiliser ton intégration sans pour rester au plus prêt des entités source et pas avoir de surcouche.
1 « J'aime »
Top
J’ai pu entre temps trouver la référence des télécommandes ce sont des Eternal Radio (noires en l’occurence) 100-ETER00 NOIR
cf https://koolnova.fr/commande-eternal-radio/ chez Koolnova France (je n’en vends pas je ne sais pas ce que ca « vaut »).
Intéressant, j’essaie de l’intégrer avec Versatile moi aussi. Mais je me pose la question de comment récupérer la température de chaque zone comme un sensor.temp mais je n’ai pas trouvé comment… C’est là où je bloque… pour le moment…
Ok, je comprend la problématique !
Effectivement, l’intégration koolnova n’implémente pas les températures de chaque zone comme des sensors mais les entités « climate » de chaque zone ont cette information :
Il suffit de transformer cette information en sensor dans un fichier sensor.yaml (ou configuration.yaml)
Exemple:
sensor:
- platform: template
sensors:
temperature_climate:
friendly_name: "Température Actuelle"
unit_of_measurement: "°C"
value_template: "{{ state_attr('climate.nom_de_ton_climate', 'current_temperature') }}"
1 « J'aime »
Effectivement for cher, merci, MI
Salut,
installation réalisée, je note 2 coquilles dans ta proc, dans les commandes mv et rm
remplacer
mv koolnova-BMS-integration/custom_components/koolnova_bms .
rm -rf koolnova-BMS-integration
par
mv koolnova-BMS-Integration/custom_components/koolnova_bms .
rm -rf koolnova-BMS-Integration
Concernant la conf, impossible de se connecter au koolnova.
J’ai bien désactivé mon intégration.
Sur mon pc avec modbusdoctor, pas de pb…
Si je remets l’intégration modbus pas de pb.
J’ai le message : « Impossible de se connecter au système Koolnova »
Je trouve cette ligne de log bizarre : reading holding register: 0x50 - Slave: 1 (cf çi dessous)
Dans ton code j’ai trouvé dans le fichier operation.py :
self._addr = 1 # Modbus Slave ID for the operations
J’ai remplacé par
self._addr = 49 # Modbus Slave ID for the operations
Redémarrage de HA et ça passse !!
2024-11-09 13:04:45.550 DEBUG (MainThread) [custom_components.koolnova_bms.config_flow] [config_flow|tcp] values received: {'Name': 'koolnova2', 'Address': '192.168.2.35', 'Port': 502, 'Retries': 3, 'Reconnect_delay_min': 0.1, 'Reconnect_delay_max': 300.0, 'Timeout': 5, 'Debug': True}
2024-11-09 13:04:45.551 DEBUG (MainThread) [pymodbus.logging] Connecting to 192.168.2.35:502.
2024-11-09 13:04:45.551 DEBUG (MainThread) [pymodbus.logging] Connecting comm
2024-11-09 13:04:45.560 DEBUG (MainThread) [pymodbus.logging] Connected to comm
2024-11-09 13:04:45.560 DEBUG (MainThread) [pymodbus.logging] callback_connected called
2024-11-09 13:04:45.561 DEBUG (MainThread) [custom_components.koolnova_bms.config_flow] test communication with koolnova system
2024-11-09 13:04:45.561 DEBUG (MainThread) [custom_components.koolnova_bms.koolnova.operations] reading holding register: 0x50 - Slave: 1
2024-11-09 13:04:45.561 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x50 0x0 0x1
2024-11-09 13:04:45.561 DEBUG (MainThread) [pymodbus.logging] Adding transaction 1
2024-11-09 13:04:50.563 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x50 0x0 0x1
2024-11-09 13:04:50.564 DEBUG (MainThread) [pymodbus.logging] Adding transaction 1
2024-11-09 13:04:55.565 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x50 0x0 0x1
2024-11-09 13:04:55.565 DEBUG (MainThread) [pymodbus.logging] Adding transaction 1
2024-11-09 13:05:00.567 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0x50 0x0 0x1
2024-11-09 13:05:00.567 DEBUG (MainThread) [pymodbus.logging] Adding transaction 1
2024-11-09 13:05:05.568 DEBUG (MainThread) [pymodbus.logging] Connection lost comm due to Server not responding
2024-11-09 13:05:05.569 DEBUG (MainThread) [pymodbus.logging] Getting transaction 1
2024-11-09 13:05:05.569 ERROR (MainThread) [custom_components.koolnova_bms.koolnova.operations] Modbus Error: Modbus Error: [Input/Output] ERROR: No response received after 3 retries
2024-11-09 13:05:05.569 ERROR (MainThread) [custom_components.koolnova_bms.koolnova.operations] Error retreive system status
2024-11-09 13:05:05.569 ERROR (MainThread) [custom_components.koolnova_bms.config_flow] Cannot connect to koolnova system
Traceback (most recent call last):
File "/config/custom_components/koolnova_bms/config_flow.py", line 111, in async_step_tcp
raise CannotConnectError(reason="Communication error")
custom_components.koolnova_bms.config_flow.CannotConnectError
2024-11-09 13:05:05.571 DEBUG (MainThread) [pymodbus.logging] Wait comm 100.0 ms before reconnecting.
2024-11-09 13:05:05.673 DEBUG (MainThread) [pymodbus.logging] Connecting comm
2024-11-09 13:05:05.694 DEBUG (MainThread) [pymodbus.logging] Connected to comm
2024-11-09 13:05:05.694 DEBUG (MainThread) [pymodbus.logging] callback_connected called
1 « J'aime »
Salut @bouracho,
Merci pour tes premiers retours ! 
Je n’ai pas compris, tu as mis les mêmes commandes ! 
C’est effectivement le gros doute que j’avais ! Comme j’ai fait mes tests sur un simulateur et pas le vrai contrôleur, je me suis planté la dessus. 
Je corrige ce bug ! Je rajoute dans les pages de configurations TCP le fait de pouvoir configurer l’adresse Modbus. 
Non il y a un i majuscule à integration 
1 « J'aime »
Bug corrigé et poussé sur le repo git.
1 « J'aime »
salut @sinseman44,
j’ai pu faire qq tests aujourd’hui en jouant avec mes thermostats physiques, virtuels et l’appli (même si toujours pas besoins de chauffage sur Toulouse )
Aucun souci de mon côté, tout fonctionne.
Tout est bien piloté et rafraichit en fonction de l’action sur les uns et les autres.
Un point cependant qui me gène, c’est d’avoir mis chaud et froid sur chaque thermostat ce qui pour moi ne représente pas le fonctionnement nominal des thermostats physique et de l’appli.
En effet, seul le thermostat maitre peut changer le mode de la clim. Je pense que l’entité global suffit à elle même et un thermostat virtuel avec heat/cool serait suffisant.
Je dirais même que ça peut entrainer des erreurs de manip et changer malencontreusement le mode de la clim reversible.
Je continue mes tests et te tiendrai au courant
Salut @bouracho
Ahhh mais on est voisin !!! 
Je suis dans le Nord Est Toulousain.
Impeccable !
C’est tout à fait vrai. et je m’en suis rendu compte à l’utilisation que l’on ne pouvais pas déclarer une zone en froid et l’autre en chaud ! Soit toutes les zones sont en froid, soit en chaud pour une seule et même machine Koolnova. (Je dirais pour 99% d’entres nous ).
Cependant, il n’y a pas que ces 2 modes la, il y a aussi la possibilité de faire de plancher chauffant et/ou « rafraichissant ». Est-ce que ca marche sur la même logique que pour le mode clim ou chauffage ? c’est à dire soit tout en plancher chauffant et donc plus de chauffage ? Est-ce que c’est un ou exclusif dans le choix des modes ? Je n’ai pas la réponse.
De plus, le maximum de zones déclarées peut être 16 (info trouvée dans la documentation). Pour faire 16 zones, je suppose (spoil: je ne suis pas sur de ce que je raconte) que l’on peut mettre en cascade plusieurs systèmes Koolnova (jusqu’à 4 « engines ») gérés par 1 seul contrôleur ! Si plusieurs systèmes, est ce qu’un système pourrait faire du froid tandis que l’autre ferait du chaud ? comment c’est géré par les commandes radios ? ect …
J’avoue, après, que je me suis fié (bête et méchant) à la spécification (récupérée chez Koolnova) des registres Modbus qui propose de pouvoir modifier le mode de fonctionnement pour chaque zone. Pourquoi l’avoir mis dans la doc si on ne peut pas s’en servir ? Est-ce un mode particulier ? Je n’ai pas la réponse.
Voila, quand je l’ai codé, je ne voulais pas faire de mon cas particulier (1 système avec 3 zones) une généralité, c’est pourquoi j’ai décidé de pouvoir tout remonter dans l’intégration et comme ca chaque utilisateur pourra adapter son utilisation en fonction de ses propres besoins.
salut @sinseman44 ,
Tout d’abord mes excuses à l’académie française :
Mais oui, on a échangé il y a qq mois par mail, tu m’avais envoyé la doc modbus.
Je suis côté ouest de Toulouse
Moi je comprends le fonctionnement comme suit et donc la nécessitée de ne pouvoir choisir froid ou chaud qu’à un endroit
Le gainable est composé de 3 partie, le plenum (koolnova), l’unité intérieur (daikin, mitsubishi…), l’unité extérieur (idem). Le plenum et lié à l’unité intérieur via un module présent sur le rail DIN, il envoie l’info de chauffe/froid à l’unité intérieur qui l’envoie à l’unité exterieur. Le compresseur ne pouvant faire que du chaud ou du froid, il est normal que l’installation soit tout en chaud ou tout en froid, d’ou une gestion centralisée de cette option.
Si tu as 2 gainable indépendants (cf personne fil de discussion) alors tu as 2 compresseurs donc la possibilité d’avoir un en chaud et l’autre en froid.
Si tu as des gainables chainés, j’ai lu la doc mais je ne me souviens plus s’il y a un gainable maitre global.
Dans tout les cas, je pense que c’est le fonctionnement normal car l’appli koolnova reprend exactement ça
Après tout est perfectible et je ne sais pas si on pourra faire des upgrade de firmware mais par ex, les thermostats physique ont l’humidité… il aurait été intéressant de pouvoir le remonter dans un registre modbus.
Sur ce point, est il possible de demander au moment de l’installation de l’intégration à l’utilisateur sa config afin d’avoir une liste déroulante adaptée ?
Bon lundi
1 « J'aime »
Merci @sinseman44 pour l’intégration ! J’avais forké ton repo pour faire la modif pour faire fonctionner la module wifi que j’ai chez moi. Mais de ce que je comprends tu as aussi fait cet ajout dans une branche, je vais pouvoir comparer et reswitcher sur ta version si tout est ok. J’aurais du te proposer un merge plus tôt !
Autre question (un peu en dehors de cette intégration), les prpframmmes koolnova fonctionnent bien chez vous ?
J´ai 2 programmes activés à la maison:
- 9h-23h 19degres
- 23h-9h 17degres
Le premier s’active bien, le symbole P est présent, mais le deuxième ne s’active pas et a 23h le thermostat indique off jusqu’au lendemain 9h… Une idée ?
1 « J'aime »
Salut @Pesto000,
N’hésites pas à faire ton retour sur l’intégration si tu l’utilises avec ton module WIFI. Tu pourrais m’indiquer la référence (vendeur/modèle) de ton module que je puisse l’indiquer dans le README de l’intégration (si tout fonctionne correctement), ca permettra d’en faire profiter la communauté sur quel matériel acheter.
Concernant le programmateur Koolnova, j’avoue que je ne l’utilise pas.
Je pense que ce n’est pas géré par Koolnova car je ne le vois pas dans l’application, mais les PAC ont un mode déshumidificateur & ventillation, ça existe dans la doc du modbus ?
Je te confirme qu’il n’y a rien dans la doc Modbus sur les modes « déshumidification » et « ventilation simple ».
1 « J'aime »
C’est celui que tu as déjà intégré dans la branche dédiée: Elfin EW11A.
Donc ça devrait être plug & play.
Je test ça dans la semaine et je te ferai un retour !
1 « J'aime »
Bonjour aux utilisateurs koolnova,
avez vous déjà eu des ratés de chauffe ? je veux dire consigne à 20° et température ambiante qui descend à 19° sans chauffe.
Sur quelle valeur de EFI êtes vous ?
Merci d’avance pour vos retours