Lazer

Merci @jojo et bravo pour le travail Comme je le disais sur l'autre topic, je suis certain que ça fonctionnait avant car j'ai encore mon fichier des règles de GEA que j'ai testé avant partage sur le forum, ainsi que tout un tas d'URL de la forme suivante que j'ai utilisé dans mes tests pour forcer les propriétés de tel ou tel device directement à l'aide de la fonction updateProperty() depuis le navigateur web : /api/callAction?deviceID=100&name=updateProperty&arg1=value&arg2=true /api/callAction?deviceID=101&name=updateProperty&arg1=value&arg2=false /api/callAction?deviceID=102&name=updateProperty&arg1=value&arg2=0 /api/callAction?deviceID=103&name=updateProperty&arg1=dead&arg2=false Je pense donc qu'on est face à une modification non documentée de l'API de la part de Fibaro.

Tu étais au bon endroit C'est dans la sous-fonction action() que ça se passe. En fait toutes les fonctions des modules (Z-Wave, Zigbee, QuickApp, entité extra-terrestre...) ne sont pas listées dans la section actions du JSON. Normalement le updateProperty setProperty est systématiquement implémenté, ça fait partie des fonctions de bases de tous les modules, encore une fois qu'ils soient physiques ou virtuels. Je pourrais te prendre un autre exemple, c'est la fonction QuickApp:debug() qu'on utilise en long en large et en travers pour afficher des informations dans la fenêtre de debug. On ne l'a défini nul part dans notre propre code LUA, pourtant elle existe belle et bien. Pourtant elle n'est pas listées dans actions. En fait elle est héritée de la classe parente du QuickApp. Conséquence : appeler la fonction debug() d'un autre QuickApp permet de lui faire afficher n'importe quoi ! Donc là c'est un autre bug, on appelle la mauvaise fonction. Mais ça m'interpelle quand même, j'ai l'impression qu'on est face à une modification non documentée de l'API de la part de Fibaro. Il faudrait enquêter, car je suis certain que ça fonctionnait avant, j'ai encore mon fichier des règles de GEA que j'ai testé avant partage sur le forum. Du coup, rectificatif : modification incluse dans le "other minor fix" du changelog

à ma connaissance on ne peut pas, c'est pareil pour tous les modules (Z-Wave, Zigbee, QuickApps, etc), donc ce n'est pas lié à Zooz en particulier (je sais pas pourquoi le nom de cette marque me fait marrer ) On peut juste désactiver les notifications pour le monde en question.

Hitachi, aucune idée. Pourtant je suis formé et certifié Hitachi... ah non zut, c'est leurs baies de stockage, rien à avoir avec leurs climatisations, c'est incroyable l'étendue du portefeuille de ces conglomérats japonais. Qui pour piloter une pelleteuse de la même marque ? Dans mes recherches, j'étais tombé sur une ébauche de projet similaire pour Daikin, consistant à exploiter le port de communication local des splits. L'année dernière c'était en mode beta, je ne sais pas s'ils sont arrivé au bout, je n'ai pas suivi ni mémorisé le lien. Et pour la marque chinoise Midea ça existe déjà. Enfin les Midea récentes, car mon vieux split Midea de 9 ans d'âge n'a pas de port local, dommage (du coup pilotage par Remotec ZXT 600 en infra-rouge)

Pour avancer, et pour obtenir de l'aide, tu devrais décomposer ton besoin en plusieurs petits besoins élémentaires à traiter dans l'ordre, un à la fois. Et ouvrir un sujet correspondant dans la bonne section du forum.

Bienvenue sur le forum

OK bon, il faut reporter le bug sur le topic de dév GEA pour que je pense à l'analyser plus tard.

Bienvenue sur le forum

Non....

"Normalement" ça devrait fonctionner, maintenant on n'est pas à l'abri d'un bug... Sinon pour mettre à jour l’icône, tu as aussi l'action "DeviceIcon" que tu peux tenter, ainsi que l'alias "CurrentIcon"

Oui effectivement j'avais buté là dessus, et préféré ne pas mettre en production un QA utilisant cette fonctionnalité si elle est incomplète.

Bonne nouvelle ça, merci pour ton retour

T'excite pas ça ne fonctionne pas complètement J'ai testé, c'est tout buggué et pas vraiment utilisable en pratique. Comme pour les Buttons Switchs, il faudra attendre que les équipes de Fibaro débuguent tout ça...

En attendant mieux, il te faudra bidouiller et t'adapter au fait que ça soit juste inutilisable en pratique. https://forum.fibaro.com/topic/68518-514283-beta/?do=findComment&comment=270234 https://forum.fibaro.com/topic/69507-added-switch-type-button-to-qa/?do=findComment&comment=273344 EDIT : moi j'attends, après avoir testé...

Je n'avais pas compris que tu avais déjà cet afficheur. Pour le coup, c'est intéressant. Tu as donc un afficheur mural PAR-41MAA connecté sur chaque split ? J'attends ton retour pour savoir sur quel port il est connecté, et on avisera en fonction.

Pareil, depuis mars, je n'ai jamais mis en défaut MELCloud, c'est comme le cloud de chez Netatmo, dans l'ensemble plutôt très stable. En revanche, j'ai subit une ou deux pannes d'accès Internet, donc forcément, plus d'accès Cloud (Mitsu nous envoie un email dans ce cas là pour nous prévenir que notre PAC a perdu la connectivité). Quand ça arrive, on est obligé d'utiliser les télécommande infra-rouges (les miennes sont rangées, piles enlevées)... Ou bien d'utiliser mon QuickApp Effectivement, on ne fait aucune modification intrusive sur la climatisation, on se contente de venir se brancher sur le port de communication proposé en standard par le constructeur. Ce port est justement prévu pour les intégrations domotiques : normalement soit les partenaires : genre propriétaire comme Crestron etc, ou à moitié ouvert comme Intesis qui permet l'interconnexion avec une domotique plus ouverte puisque ce boitier fait office de passerelle... reste qu'au prix du boitier, ça fait cher la domotisation... par split !!! A noter que Intesis a pas mal été mis en avant par Domadoo car supporté par Jeedom (leur développement maison) ou bien encore leur propre solution de télécommande murale comme je l'ai évoqué au premier post. Nous on se contente de venir brancher notre petit montage à trois francs six sous (moins de 10€ par split), qui est totalement réversible sans laisser aucune trace. Il faut juste penser à couper l'alimentation électrique pendant la manipulation si on ne veut pas risquer un accident... D'ailleurs pour faire plus propre, on pourrait imprimer un boitier en 3D pour le module ESP32, même si ça n'apporterait pas grand chose vu que le module est complètement caché. La télécommande murale Mitsubishi justement, je ne pense pas qu'on puisse partager le port CN105 avec un autre montage. Sinon on part dans des solutions complexes, avec la passerelle ModBus proposée par Mitsu, qui permet de s'interconnecter avec de la domotique vu qu'il s'agit un protocole bien connu.. Autre piste, utiliser le port CN104, qui est un autre port de communication. Mais je n'ai pas trop creusé tout ça, il existe de la documentation chez Mitsu, mais c'est pas hyper clair car plutôt destiné aux installateurs formés et partenaires de Mitsu. Et vu que ça devient rapidement complexe et couteux, je n'ai pas trouvé l'intérêt de creuser cette questions plus que ça. A noter que la télécommande murale, en plus d'être bien WAF, présente un autre intérêt majeur : celui de pouvoir déporter la sonde de température, donc au lieu de prendre la sonde intégrée au split au plafond (non représentative de la température réelle de la pièce), le thermostat peut utiliser la sonde de la télécommande installée à bonne hauteur dans la pièce. Et justement, il se trouve que puisque notre montage ESP s'interface par ce même port CN105, on peut également déporter la sonde, et prendre n'importe quelle sonde qui serait intégrée à notre domotique, filaire ou sans-fil, du protocole de notre choix (Z-Wave, Zigbee, QuickApp, il n'y a plus de limite). Mais... ce n'est pas encore fonctionnel avec mon QuickApp. Donc ça fait partie des évolutions à venir, maintenant que la base est opérationnelle (ESPHome connecté au split), je vais m'attaquer à m'interfacer différemment avec ESPHome via Wi-Fi. Au lieu de communiquer par l'API Web (qui présente le bug du ventilateur), je vais essayer d'utiliser le protocole binaire de l'API officielle Home Assistant. Mais j'ai pas mal de travail pour ça, qui va m'occuper pendant les week-ends pluvieux d'hiver...

Le mieux c'est encore d'aller le chercher à la source : Parce qu'ici c'est le topic du plugin pour HC2, rien à avoir avec le QuickApp pour HC3

Yes Permet une intégration nickel, comme pour les spots. Perso c'est un peu particulier, car c'est ma salle cinéma, donc je veux faire un plafond un peu atypique, en tissu tendu et acoustiquement transparent, avec de la laine de roche derrière pour absorber le son.

Capteur de couple (probablement en mesurant le courant soutiré par le moteur) Met un obstacle sur la fermeture, mais aussi sur l'ouverture, et tu verras que le moteur va s'arrêter en milieu de course, alors qu'il n'est ni arrivé en position ouverte ou fermée. C'est une question de sécurité. D'ailleurs mon moteur ne se contente pas de s'arrêter, car il repars en sens inverse (ce qui est un peu idiot je trouve....)

Il va te falloir fouiller dans le fichier Xiaomi du QuickApp, car c'est un ensemble de fonctions interdépendantes les unes des autres, pour pouvoir encoder le paquet et décoder la réponse. Le point d'entrée c'est la fonction Xiaomi:startClean() C'est loin d'être aussi simple que tu ne donnes l'impression de le penser, car le protocole est binaire, propriétaire et chiffré. Ce n'est pas juste un appel d'une API HTTP REST comme ça peut l'être sur des appareils plus ouverts.

Sauf si la porte a été forcée.... auquel cas le capteur de vibration / d'inclinaison Zooz proposé ici serait un bon complément : Personnellement j'utilise des capteurs d'ouverture sans contact ILS, j'en ai mis un au sabot, et un sur le rail en position complètement ouverte, comme ça je sais si la porte est complètement fermée, complètement ouverte, ou entre les deux, par le biais d'un QuickApp. Et cela indépendamment de ce pense savoir le contrôleur du moteur... car en fait il n'en sait rien, il pense juste savoir (si tant est qu'un boitier d'électronique puisse penser...)

J'en ai un depuis des années, dont j'ai déjà fait 2 fois la mise à jour du firmware, inclus sur ma box de test, mais toujours pas utilisé en vrai. Depuis que je l'ai installé, je sais où il va être installé, alimenté par sa prise USB, sauf que.... il faut que je refasse le plafond pour l'encastrer justement ! (j'ai acheté la boite d'encastrement faite pour)

Effectivement c'est bien la même version que la mienne. Et.... mon QuickApp s'est arrêté de fonctionner cette nuit, avec la même erreur "Wrong status '1' in response! Check credentials".... en fait pile au moment du backup automatique de la box, c'est donc que le QuickApp n'a pas pu redémarrer à cause de l'expiration du token. Je viens de générer le nouveau Refresh Token, et ça repart. Il faudra surveiller ça... si Netatmo nous fait le coup trop souvent ça va être pénible....

Tu es sûr que tu as mon QuickApp ? Car moi je n'ai pas eu besoin de toucher aux tokens, ça fonctionne toujours. Tu as peut être la version de GSmart.pl

Chapitre 4 : Installation et utilisation du QuickApp Présentation :  Ce QuickApp de type Thermostat permet de visualiser l'état et de piloter chaque split de la pompe à chaleur, grâce à la communication HTTP directe vers le module ESP32 fonctionnant sous ESPHome connecté au port CN105. Un module enfant est automatiquement ajouté permettant de remonter la température de la sonde intégrée au split. Attention cette valeur n'a une précision qu'à 0.5°C près, et est celle de la température d'aspiration, donc proche du plafond, non représentative de la température dans la pièce. Le QuickApp remonte les informations suivantes : Mode de fonctionnement : Off, Auto, Heat, Cool, Dry, Fan Température de chauffage Température de refroidissement Vitesse du ventilateur : Auto, Diffuse, Low, Medium, Middle, High En revanche, attention, il n'est actuellement pas possible de piloter la vitesse du ventilateur à l'aide du QuickApp, à cause d'un bug dans ESPHome. En effet, l'implémentation de cette partie n'est pas faite dans le code source du serveur Web intégré, comme indiqué ici : https://community.home-assistant.io/t/how-do-you-update-climate-preset-fan-mode-etc-without-ha/546402 Depuis la v2 du QuickApp qui exploite l'API Native d'ESPHome, le contrôle de la vitesse du ventilateur, du mode de bascule des ailettes (swing), et la prise en charge d'une sonde de température déportée sont possibles. Le QuickApp étant un vrai thermostat dans l'interface de la box HC3, il peut être utilisé comme tel dans vos scénarios, GEA, zones de climats, etc. Installation du QuickApp :   Importer le QuickApp (fichier fqa) de façon habituelle sur la box Home Center 3, puis changer les paramètres suivants dans l'onglet Variables :  Configurer les variables comme suit : Protocol : protocole à utiliser, normalement : tcp Address : adresse IP du module ESPHome, par exemple : 192.168.1.2 Port : port de communication, normalement : 6053 RefreshInterval : intervalle de rafraichissement des informations en secondes, par exemple : 60 (note : n'est plus utile depuis le QuickApp v2) ID_Temperature : ID du module externe de type Temperature Sensor existant dans l'installation et qui sera utilisé comme référence pour la sonde de thermostat. Ce peut être un module Z-Wave, Zibgee, ou encore un autre QuickApp. Si valeur "0", alors le QuickApp prendra automatiquement la sonde de température par défaut de la pièce dans lequel il est installé. Voir à cet effet les propriétés de la pièce (room) Si non renseigné (valeur par défaut "-"), alors la sonde interne du split, situé au mur en hauteur, sera utilisé Téléchargement :    Nouvelle installation : importer le fichier suivant pour créer un nouveau QuickApp : Mitsubishi_v2.00.fqa