Lazer

Il faudrait poser la question sur le forum officiel pour tirer cette histoire au clair, est-ce que c'est un changement voulu ou non, est-ce que ça s'applique aux QA ou aux autres modules, etc. Pas eu le temps de faire des tests/recherches de mon coté, mais tout cela semble bien flou pour l'instant.

A mon avis pas besoin de QA dédié pour gérer les échanges MQTT, ça alourdirait le fonctionnement du bouzin. Je ne suis pas fan des QA interdépendants les uns des autres, ça rend le système plus complexe à maintenir... suivi des versions, indisponibilité d'un QA qui impacte les autres, etc. En plus, l'utilisation de MQTT est vraiment facile, ça se fait en quelques lignes dans un QA, c'est pas beaucoup plus compliqué que de faire une requête HTTP, et moins compliqué que de faire des communications TCP/UDP avec une socket. Voir la doc de Fibaro qui donne la syntaxe à utiliser. Limite la doc est plus compliquée sur l'utilisation. Au moins pour une fois ils ont rédigé une doc complète sur le sujet. En fait comme toujours, la difficulté c'est d'organiser correctement la structure de son QA, puisque tu mentionnais sur un autre topic que tu n'es pas très à l'aise avec ça.

Bienvenue sur le forum

oui mais pas dans la section pour les nuls, ce sont des mini tutos en lecture seule. Je déplace du coup... dans éclairage vu le besoin.

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...)