Suite à ma reprise du plugin MELCloud (via un fork) initialement développé par @floman321, je suis à la recherche de bêta testeur. Veuillez noter, que ce nouveau plugin a un ID différent mitsubishimelcloud, et que le tag associé sera prochainement créé par l’équipe Jeedom.
Donc, si vous posséder une pompe à chaleur Mitsubishi et que vous êtes intéressé, je vous invite à installer ce nouveau plugin, gratuit, Mitsubishi Melcloud et à me faire vos retours.
Veuillez noter que ce plugin peut fonctionner en parallèle d’autres plugins similaire (gratuit ou payant) sans engendrer de soucis de compatibilité.
Vous trouverez la documentation ici, et le changelog là.
Vous pourrez y voir que j’ai recréé le design de l’interface de Mitsubishi MELCloud, et aussi, que pour l’instant ce plugin n’existe que les PAC air/air.
Si vous posséder une PAC air/eau, je suis preneur de toute information me permettant de mettre à jour le plugin pour cette deuxième version.
Template en l’état actuel du développement :
Si vous voyez un bug, une amélioration, n’hésitez pas à le dire en réponse ci-dessous, et/ou à créer un PR sur le dépôt de ce plugin.
Bonjour.
Cela semble bien
Pour le moment je n’ai pas le temps de l’installer
Juste une chose attention au mode.
Si tu as plusieurs splits raccordés à la même pompe le mode doit être impérativement identique, as-tu prévu un basculement automatique de cette fonction sur tous les splits.
Attention car si pas identique il y a des risque de PB sur la pompe
Je n’ai rien prévu pour le moment. Mais l’idée de rajouter une alerte n’est pas inintéressante. Mais je ne sais pas trop comment l’implémenter pour que ce ne soit pas bloquant. Sachant qu’actuellement Mitsubishi te laisse faire à ta volonté et donc bloquer le fonctionnement (d’au moins) un split.
Je voie plusieurs possibilités, dites moi ce que vous en pensez :
Lors d’un changement de mode sur un split, Jeedom lève une alerte qu’il va y avoir un défaut car le mode est différent des autres split allumé, mais envoie quand même la commande.
Lors d’un changement de mode sur un split, Jeedom lève une alerte qu’il va y avoir un défaut si le mode est différent des autres split allumé, et n’envoie pas le changement de mode.
(méthode bourrin) Lors d’un changement de mode d’un split, Jeedom lève une alerte indiquant que le mode va changer pour tous les splits de la même pompe, et envoie les commandes de nouveaux mode à tous.
Je ne pense pas intégrer ceci au plugin. Car, de mon point de vue, il suffit de créer un scénario (déjà intégré à Jeedom).
.
Par contre, je réfléchis à créer un « split virtuel », c’est à dire à créer dans Jeedom une unité intérieure qui serait relié à plusieurs split réel. Ca permettrait ainsi d’agir sur plusieurs split avec la même consigne (par exemple, si on veut la même température de consigne, la même vitesse de ventilation, … (le même mode évidemment)) en n’agissant que sur 1 unité dans Jeedom (et donc réduire le nombre de manipulation).
Modification gestion cron. Passage à un cron journalier pour les informations de la PAC et le cron toutes les 5 minutes est remplacé par une récupération des informations des splits.
Correction d’un bug d’affichage qui faisait afficher des points de rafraichissement sur tous les équipements, au lieu de seulement celui sur lequel l’action a été lancé.
Le plus gros changement dans le code n’a pas beaucoup de changement du côté visible, mais ça me permet d’avoir une gestion plus facile des données reçu depuis MELCloud.
Le seul changement visible est la correction d’un bug que j’ai aperçu sur le bouton refresh.
Travaillant sur le bloc météo, j’ai besoin de votre aide pour récupérer le maximum d’icône météo.
Actuellement, j’ai déjà pu collecter les suivants (disponible dans ce dossier) :
Au vu de la numérotation, je pense qu’il en manque quelques un. Mais à part les prendre au fur et à mesure qu’ils apparaissent sur le site, je n’ai pas trouvé comment toutes les collecter rapidement.
Dans le plugin meteofrance, les images sont chargées au fur et à mesure. MF dit que c’est telle image qu’il faut. Si l’image est déjà en cache, elle est utilisée. Sinon elle est téléchargée sur le site de MF, mise en cache et utilisée. Cache dans le répertoire data/icones.
Peut-être n’êtes-vous pas dans le même contexte.
Merci. Ca m’a pris un peu de temps, mais je trouve ça bien de retrouver l’interface de l’app (qui est pas mal, en plus)
Tu veux dire qu’à côté de logs, sur l’image suivante, il n’y a pas le bouton bleu ?
Si c’est ceci, je ne peux rien faire. Cette partie est généré par le core. Et le bouton apparait dès qu’il y a eu quelque chose d’écrit dans les logs (ce qui n’est pas le cas lors d’une simple activation du plugin). Ca devient ainsi, ensuite :
Sinon, plus important,
Peux-tu mettre les logs en Debug, m’indiquer la démarche que tu utilises étape par étape (quel champ rempli, avant de cliquer sur quel bouton, …). Et m’indiquer les message affiché et les logs retourné ?
Je viens de faire un test sur une installe fresh, et ça fonctionne de mon côté. Mais, je ne peux tester qu’avec mon couple d’identifiant, donc je ne peux, actuellement, garantir que ça fonctionne ailleurs.
Enfin,
Merci.
Mais j’ai suivi la proposition de jpty, je l’ai implémenté dans ma version de test, donc plus besoin de chercher à récupérer les images manuellement. Ca devrait arriver, début de semaine prochaine (je suis en vacances cette semaine, donc plus de temps en famille).
Merci pour les informations.
Je voie que ce sont des erreurs javascript qui te sont affichés quand tu accèdes à la configuration du plugin. Je n’arrive pas à reproduire ceci, malgré différents navigateur (Firefox, Edge, Chrome). As-tu essayé un autre navigateur ?
Aussi, as-tu cette erreur en allant dans la configuration via Gestion des plugins ou depuis le bouton Configuration depuis le plugin, ou les 2 ?
Peux-tu m’en dire plus sur ton installation ? Version Jeedom, version debian (ou autre OS sur lequel est installé Jeedom), quel navigateur utilisé, … que j’arrive à reproduire pour trouver l’origine du problème.
Aussi, je te proposerais bien de cliquer sur réinstaller depuis le centre de mise à jour à propos de ce plugin, voir si ça corrige le soucis.
Une nouvelle version de la bêta viens d’être publiée. Elle contient l’ajout du bloc météo, et la correction du bug JavaScript remonté par @TiTiTG34 (que j’ai réussi à reproduire sur une nouvelle installation).
EDIT : ajout de la gestion de l’indisponibilité des données météos.
Je viens d’installer le plugin mais impossible pour moi de régler la consigne de température.
j’obtiens l’erreur suivante :
0000|[2022-11-08 20:20:10]ERROR : Erreur sur mitsubishimelcloud::SynchronizeSplit() : cURL error 28: Resolving timed out after 5000 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
Les commandes « On » et « Off » passent correctement et les informations s’actualisent bien.
Cette fonction SynchronizeSplit n’est lancé que lors de la sauvegarde de l’équipement, pour créer les commandes, puis via un cron régulier (toutes les 5 minutes, dont le but est de mettre à jour Jeedom en fonction de l’état réel du split (si changement via la télécommande, ou via l’application Mitsubishi)), mais pas lors de l’envoie d’échange de commande depuis Jeedom.
Il arrive que les serveurs de Mitsubishi ne répondent pas (j’ai souvent des erreurs la nuit entre 2 et 3h) ce qui remonte cette erreur. Je cherche à améliorer ceci pour éviter les remonté d’erreur trop fréquente.
Du coup, le non-envoie de la consigne de température n’a pas de lien avec cette erreur.
De mon côté, l’envoie de la commande de température se passe bien. Est-ce que tu peux mettre les logs du plugin et mode debug, tester à nouveau à nouveau un changement de température et me retourner les logs retourné ? Ils devraient commencé par quelque chose comme : 0000|[2022-11-09 09:30:59] DEBUG : New Temperature set : 20.5
Pas de problème dans les log mais depuis mon téléphone ou en web, pas de modification de température.
Je précise que je fais la modification clim éteinte (je ne sais pas si il y a un impact).
Si je demande le rafraichissement depuis le widget j’obtiens ceci dans les logs :
Ce qui veut dire que la consigne est bien envoyée et prise en considération par Mitsubishi ?
Ça n’a aucun impact, ça fonctionne dans les 2 cas.
Par contre, quand tu écris ceci :
Cela signifie que la consigne n’est pas correctement envoyée quand le plugin-thermostat interagit avec ce #plugin-mistubishimelcloud, c’est bien ça ?
Je ne me suis jamais servi du plugin thermostat. Mais je ne vois pas pourquoi l’interaction ne se déroule pas bien.
Est-ce que tu peux ouvrir un sujet à ce propos, en mettant en tag le plugin thermostat ? Je suivrai pour voir ce que je peux apporter pour une bonne intégration des 2 plugins ensemble.
