[Plugin] Climatiseur Mitsubishi (interface série et non MELCloud)

[benbiais]

Merci pour votre suggestion qui peut faire avancer le sujet.
Malheureusement, l'appel de l'API sans nValue=[0,1,2] (ou avec nValue=0) ne fonctionne pas : le widget se met à jour, mais sans effet sur le ventilateur.
Sur la photo en PJ, on voit que la petite icône sur la gauche caractérisant le niveau de ventilation est resté inchangée et n'est plus cohérente avec le niveau 4 affiché. Cette incohérence peut peut-être expliquer le manque d'action sur le ventilateur. Avec votre connaissance de ce plugin qui est votre oeuvre, vous avez peut-être une idée de l'effet de cette incohérence ?

[Flying Domotic]

Il y a une désynchronisation entre l'envoi d'une commande et son retour par la clim. Le décalage peut aller jusqu'à une minute. On le constate quand on utilise l'UI Domoticz.

Cependant, ça devrait se recaler tout seul.

[benbiais]

En fonctionnement normal (soit par clic de souris, soit avec la commande commandArray), j'ai en effet constaté ce décalage (environ 30 secondes chez moi).
Mais avec la commande json, rien ne se synchronise et on reste ad vitam dans la situation figée montrée sur la photo.

[Flying Domotic]

Perso, j'utilise des scripts LUA pour changer les paramètres des clims, pas d'API Json ...

Ceci dit, il semble, d'après la doc de l'API Json, qu'il faille utiliser plutôt

Code : Tout sélectionner

/json.htm?type=command&param=switchlight&idx=99&switchcmd=Set%20Level&level=6

... car il elle précise

Code : Tout sélectionner

To update in Domoticz only without running it's device actions use /json.htm?type=command&param=udevice&idx=IDX&nvalue=[0,1,2]&svalue=LEVELNR

... ce qui a bien l'air de se passer (pas de d'action sur le device) ...

[benbiais]

Effectivement, c'était bien cela. Votre réponse résout parfaitement la question.
La commande
/json.htm?type=command&param=switchlight&idx=99&switchcmd=Set%20Level&level=60
est parfaitement efficace : le ventilateur démarre et la petite icône à gauche est cohérente.
Cette commande json est donc parfaitement équivalente à celle par commandArray.
Grand merci !

[Masure]

J'arrive après la guerre, merci d'avoir aiguillé benbiais.

Il y a une désynchronisation entre l'envoi d'une commande et son retour par la clim. Le décalage peut aller jusqu'à une minute. On le constate quand on utilise l'UI Domoticz.

Cependant, ça devrait se recaler tout seul.

J'agis en mode pessimiste plutôt qu'optimiste. J'envoie les ordres de changement à la clim et j'attends de recevoir les valeurs actuelles de sa part pour mettre à jour les valeurs côté Domoticz.

En mode optimiste, on mettrait à jour Domoticz directement avant que la clim nous ait indiqué la réelle survenue du changement. Au risque de montrer une valeur désynchronisée ou invalide.

C'est un choix d'architecture, discutable certes, mais j'aime bien comme ça

[Flying Domotic]

Ça permet surtout, de mon point de vue, d’avoir un statut conforme à la réalité

[Dr No]

Pardon Masure d'utiliser ce thread pour ma question. Je n'ai pas réussi à retrouver la rubrique d'easydomoticz traitant ces sujets.

Tout d'abord un énorme merci pour ce travail que j'utilise quasiment depuis le début je crois. J'ai 2 problèmes à résoudre :

1 - Je voudrais ajouter un second climatiseur, comment faire pour que domoticz voit 2 appareils différents. j'ai peur de créer la panique en branchant un second ESP8266sur une autre clim.

2 - Apparemment on peut envoyer le résultat d'un senseur de température externe au climatiseur. comment fait-on cela ? et quel est l'écart maximal entre 2 envois d'information.

Merci d'avance pour l'aide.

[Flying Domotic]

On peut connecter plusieurs clims sur le même serveur MQTT et la même instance de Domoticz (j'en ai 5 chez moi).

Il suffit d'utiliser des topics MQTT différents pour chaque clim et de créer autant d'instances du plugin que de clims. On spécifie le topic MQTT utilisé ("nomDeMaClim") dans le paramétrage de chaque instance dans le paramètre "Heatpump MQTT topic".

Si on utilise le code "standard" à https://github.com/SwiCago/HeatPump, le paramétrage du code à charger dans l'ESP se fait dans le fichier mitsubishi_heatpump_mqtt_esp8266_esp32.h, sur les items suivants :

Code : Tout sélectionner

const char* client_id					= "nomDeMaClim"; // Must be unique on the MQTT network
const char* heatpump_topic			= "nomDeMaClim";
const char* heatpump_set_topic		= "nomDeMaClim/set";
const char* heatpump_status_topic		= "nomDeMaClim/status";
const char* heatpump_timers_topic		= "nomDeMaClim/timers";

const char* heatpump_debug_topic		= "nomDeMaClim/debug";
const char* heatpump_debug_set_topic	= "nomDeMaClim/debug/set";

Remplacer "nomDeMaClim" par une valeur significative (par exemple "climSalon" ou "climChambrexxx")

A partir du moment où on gère plus d'une clim, il peut être habile de dupliquer le code dans un répertoire par clim, et de changer le nom "mitsubishi_heatpump_mqtt_esp8266_esp32" en "nomDeMaClim" pour les fichiers .h et .ino. Penser à modifier la ligne

Code : Tout sélectionner

#include "mitsubishi_heatpump_mqtt_esp8266_esp32.h" 

en

Code : Tout sélectionner

#include "nomDeMaClim.h" 

dans le fichier nomDeMaClim.ino.

Vérifier deux fois qu'on charge le bon fichier dans le bon ESP si on veut éviter des comportements rigolos.

Concernant la température externe, on peut utiliser un capteur de température existant dans Domoticz. Il faut préciser son IDX dans les paramètres du plugin, à la rubrique "Remote temperature device Idx (leave blank to use internal heatpump sensor)". Préciser également "Domoticz base url (required only if you use a remote temperature device)". Si la mise à jour date de plus de X minutes (précisé dans "Don't send remote temp after being unseen for X minutes"), alors la température ne sera pas envoyée et c'est celle de la clim qui sera utilisée.

[Dr No]

Merci beaucoup pour cette réponse détaillée et rapide.