Lazer

Oui complètement. Pas que les batteries d'ailleurs, c'est tout aussi vrai pour les bonnes vieilles piles. Mon message précédent n'était peut être pas très clair, mais entre le fait que mon module aërQ soit de première génération (ZWA009) ET installé dehors, je ne m'inquiète pas pour le niveau de batterie qui fait n'importe quoi. D'ailleurs Aeotec avait poussé une mise à jour de firmware pour ce module, qui avait sensiblement amélioré la gestion de la batterie, c'est beaucoup mieux, mais pas encore ça.... Autre raison de ne pas s'inquiéter, malgré le relevé assez "agressif" à 0.1°C près, ça fera bientôt 3 ans qu'il fonctionne dehors avec la même pile lithium d'origine : On voit bien debut 2021 avant la mise à jour du firmware !!! Et malgré la baisse générale sur ces 3 années, on reconnait la forme des saisons... le froid et son influence sur la chimie de la pile.

Ah ouais carrément EDIT : j'avais raconté l'expérience sur le forum je crois, de mon relais Finder, bien plus gros que ces micro-modules, avec des borniers eux aussi largement plus gros, et qui avaient noirci et commencé à fondre au bout de 2 ans d'utilisation. Heureusement que je m'en suis aperçu avant le drame. Je vais le dire clairement : faut être complètement débile pour brancher un micro-module sur un chauffe-eau. Après vous faites ce que vous voulez, c'est pas ma maison.... espérons juste qu'on ne soit pas voisin ! (ma maison n'est pas mitoyenne donc ouf, ça va)

Mouais, ça n'empêche pas les clients de voir 16A, chouette, je peux piloter mon chauffe-eau de 3 kW en direct avec et virer le contacteur de puissance, puis ça chauffe, ça fond, et dans le pire des cas ça prend feu, la sonde de température, ça sera trop tard. Il n'y a qu'à lire les forums pour voir le nombre de gens qui font n'importe quoi... ici même d'ailleurs parfois.

Aïe... bon bah falloir attendre la prochaine génération alors....

Je suis rassuré de voir que Shelly a revu ses prétentions à la baisse et est plus réaliste quant à la capacité de leurs modules à tenir de fortes puissances, puisque ils sont maintenant certifiés pour un courant de 8 A seulement, contre 16 A auparavant. Ils suivent donc la même voie que Fibaro pour ses micro-modules, avec quelques années de retard cependant, le temps de prendre en compte le retour d'expérience des modules qui ont cramé chez les clients. La sécurité n'a pas de prix, et comme je dit tout le temps, les lois de la physique sont les mêmes pour tout le monde, le marketing ne peut rien y faire. Voilà qui va dans le bon sens

Très bien, dans ce cas tu devrais pouvoir essayer une config comme ceci pour prendre en compte ton QA : { dbType = "water , fibaroType = "com.fibaro.multilevelSensor", unit = "mm , visible = "true", dead = "false", enabled = "true", property = "value" , dbField = "index", }, On le met dans la table water car elle supporte les index (qui croissent éternellement), d'ailleurs le paramètre dbField = index sert à ça. Oui comme tu peux le constater la table rain_day n'est pas graphable, car comme dit dans mon message précédent, c'est indémerdable entre les mm/5min, mm/h, mm/24h, etc... Les data sont tout de même mémorisées, ça permet toujours d'aller faire des requête SQL à la main pour extraire des stats personnalisées, ou bien utiliser Grafana pour des graphs custom. Mais toi, avec ton index, c'est dans les tables water que tu vas devoir aller chercher les données. Là aussi c'est compliqué, car il n'y a pas de mesure universelle pour l'eau, tantôt c'est une quantité, tantôt un débit, tantôt un index... Bref, voilà ce qui arrive quand on essaye de prendre en compte toutes les données dans une base unique. C'est tellement plus simple pour les température, humidité, puissance, énergie, etc, il y a une seule unité et on ne se pose pas de question, c'est simple à traiter.

If my memory is right, on HC2 you have a checkbox in the scene property to prevent it from being restarted.

Il faudrait que tu partages les caractéristiques exacte de des modules que tu souhaites remonter dans DomoCharts, mais les capteurs de pluie je n'ai jamais trouvé comment bien les gérer... entre ceux qui affichent des mm/5 minutes, des litres par heures, des litres cumulés sur 24h, c'est juste ingérable. Et je parles même pas des m3, non mais sérieux, c'est quoi cette unité à la con pour mesurer la pluie, le jour où on se prendra ça sur la tête, ce n'est plus de dérèglement climatique qu'on parlera, mais de fin du monde... En attendant, tu peux modifier la config de ton QuickApp DomoCharts. Exemple de config que tu dois déjà avoir pour les capteurs de pluie : { dbType = "rain" , fibaroType = "com.fibaro.rainSensor" , visible = "true", dead = "false", enabled = "true", property = "value" , }, Tu peux essayer d'ajouter ceci, il faudrait être ajuster en fonction des caractéristiques (type, unité, ...) de tes modules : { dbType = "rain" , fibaroType = "com.fibaro.multilevelSensor", unit = "mm/h" , visible = "true", dead = "false", enabled = "true", property = "value" , }, { dbType = "rain" , fibaroType = "com.fibaro.multilevelSensor", unit = "m3" , visible = "true", dead = "false", enabled = "true", property = "value" , }, Mais bon, mélanger des mm, des litres, et des m3 dans le même graph, ça ne va rien représenter d'intéressant...

Bienvenue sur le forum

Ouais bah ça c'est très embêtant, mais ça explique le comportement du QuickApp. Tant que ESPHome ne reçoit aucune données provenant du split, le QA ne changera pas de statut non plus... Je pense que c'est lié au port CN110 utilisé. Je suppose, que le split n'envoie par les changements de statut sur ce port, considérant qu'il est normalement utilisé uniquement pour le module MelCloud, qui n'a pas besoin de mise à jour en temps réel, mais seulement une fois toutes les .... X .... minutes ? Ce que tu peux tenter, c'est de laisser tourner quelques temps, et de voir si tu constates un changement de statut au bout d'un certains temps. Sinon... il faudrait trouver le moyen de forcer la lecture d'une mise à jour... d'après ton log, j'ai l'impression que c'est ce qui se produit lors de la première connexion, juste après le message SubscribeStatesRequest, puisqu'on reçoit en retour un ClimateStateResponse. Donc... ça signifie qu'il est impossible de s'abonner aux mises à jour instantanées des changements de status, mais qu'il faudra constamment faire une interrogation en boucle. Dis autrement, au lieu d'avoir du Push, il faudra forcer un Polling permanent... es espérant que ça fonctionne et qu'il n'y ai pas d'effet de bord.

Alors en fait le message "read() error : Operation canceled" c'est normal, car comme il interroge l'ESP32 toutes les 5 secondes, et que 99% du temps il ne se passe rien de nouveau, il n'y pas de réponse, donc le read() tombe en timeout, ce qui génère cette erreur "Operation canceled" à laquelle on est habitué avec le LUA de Fibaro. C'est une erreur du point de vue de la Socket TCP, mais ce n'est pas une erreur du point de vue du fonctionnement du QA, qui s'attend à ne pas avoir de réponse, et continue donc sa boucle infinie. Ce qu'il faut que tu fasses, c'est modifier le statut de ton split depuis un autre moyen (ton clavier/écran, ou bien la télécommande IR) et voir si le QA réagit à ce moment là (enfin, plus précisément dans les 5 secondes qui suivent du coup)

C'est ce qu'il fait justement... tu dois avoir un bug Tu peux activer le mode debug=true, et tu devrais le voir s'activer, attention le QA est alors extrêmement bavard, et tu devrais voir défiler des tonnes de messages indiquant qu'il interroge l'ESP32 toutes les 5 secondes (et cela indépendamment de la variable Refresh du QA qui est devenue inutile en v2)

Si si, normalement tu as bien le retour d'état, et cela instantanément (enfin, avec maximum 5s de délai, c'est quasi instantané)

C'est pourtant la triste vérité...

Non. Si tu as d'autres questions n'hésite pas

Ah oui OK merci Rien de tel que la vampirisation de connecteur

Voilà j'ai mis le nouveau fichier mitsubishi-room.yaml en première page, avec la procédure pour le customiser, car chaque ESP32 connecté à un Split dans la maison doit avoir son propre fichier de configuration afin de bien les distinguer.

J'en ai 1 en extérieur dont la pile fait n'importe quoi, mais vu que c'est la première génération "ZWA009" je suppose que c'est normal, en tout cas pas comparable à mes 2 modules ZWA039 installés récemment en intérieur.

Ah je sais pourquoi... il faut injecter un fichier de config YAML différent dans l'ESP32 Désolé j'avais oublié... je te prépare ça... Tu as fait comment pour trouver le bon connecteur à 4 broches pour le port CN1110, tu as la référence ? Si c'est la même marque ça doit être facile. Sur mes splits (récents) j'ai aussi le port CN110 sur lequel est connecté le module Melcloud, et aussi un port CN104 disponible, je me demande dans quelle mesure il pourrait être utilisé.

Et bah dis donc, tu as joué à l'apprenti sorcier là ! Intéressant ta trouvaille pour le port CN110, merci de l'info pour la régulation de tension. Mise en ligne de la version 2 du QuickApp, disponible au téléchargement sur le tutoriel de la 1ère page : Ajout du pilotage de la vitesse du ventilateur Ajout du pilotage de l'orientation verticale des ailettes (statique ou swing) Ajout de la prise en compte d'une sonde de température déportée dans la pièce pour la régulation du thermostat

Effectivement le support pourra peut être te forcer l'installation de la dernière stable, mais attention à ce qu'ils ne fassent pas une simple restauration à l'état antérieur, car tu perdrais alors toutes les modifications effectuées entre temps sur ta configuration, l'historique, etc.

Étrange, je n'ai jamais eu ce problème. Il faudrait que tu partages le log du Quickapp (fenêtre de débug) pour que je puisse analyser la situation, au moment où le bug se produit.

C'est bizarre ce que tu dis là... car la dernière Stable date du 6 décembre 2023, alors certes ça fait "quelques" mois, mais bon... ça ne fait surtout que 2 mois. La prochaine fois que tu installes une stable, restes-y et surtout assure toi de ne pas installer une Beta en cliquant trop vite sur le bouton.

Bienvenue sur le forum

Bienvenue sur le forum