Lazer

Oui et oui.

Il y a 1 heure, Nico a dit :

GHome en parallèle dans la pièce de vie, car pour les questions qu'on luis pose parfois, il est nettement plus intelligent moins bête qu'Alexa

IFIFY

Il y a 1 heure, Nico a dit :

Pour les 3 amplis, j'ai à chaque fois une Alexa ou un GHome dans la pièce qui stream dessus, cela fonctionne parfaitement, et rien de plus simple que de dire mais cette playlist, mets cette chanson etc

Comment tu fais pour allumer automatiquement l'ampli et se positionner sur la bonne source Bluetoth ?

Avec mes amplis Yamaha ce n'est pas possible, il n'y a pas de détection auto quand il est éteint, ou alors peut être qu'il faut trifouiller avec les skills Alexa ?

Jeedom n'intègre pas déjà le support des modules ESPHome ?

Sinon @Pascal66 est en train de préparer ça justement, avec un lien depuis le forum Jeedom vers ici.

Concernant git, je n'ai pas eu besoin de l'installer sous Windows, il a dû être installé automatiquement avec les dépendances lors de l'installation de Python je suppose.

En revanche j'avais testé dans une VM Debian, et là il avait fallu que j'installe Git manuellement.

Oui c'est sûr, mais attention Matter n'est pas un protocole radio.... c'est Thread qui l'est (remplaçant direct de Zigbee)

Matter est la surcouche logicielle, de haut niveau, qui est censé unifier tous les protocoles domotiques, dont Z-Wave... et pour cela il faudrait que les fabricants de contrôleur Z-Wave (Fibaro, HA, etc) se dépêchent d'ajouter le support de Matter pour faire la passerelle entre les différents mondes.

Mais pour l'instant, Matter a pris énormément de retard et peine à décoller... en même temps quand on constate qu'ils n'ont toujours pas intégré des sujets aussi élémentaires que la consommation électrique des modules, on mesure le chemin qu'il reste à parcourir...
On en avait largement parlé sur le topic dédié :

Il y a 13 heures, jluc2808 a dit :

est-ce qu'on a une solution pour être alerté ou même déclencher une scène de reboot si ça floode comme ça ?

Oui, en faisant un script LUA de monitoring de ce panneau.
Sur le topic de la version du firmware sur laquelle était apparu ce nouveau panneau, j'avais fait un récapitulatif de l'API utilisée, mais tu la retrouveras très facilement avec F12 sur ton navigateur.

il y a une heure, jojo a dit :

il ne m'affiche que les ID 2 à 118 

Etonnant ça, on a exactement le même nombre de modules Z-Wave

Je te rappelle que ce n'est pas l'ID du module qui est affiché, mais son numéro de noeud sur le réseau.

Mon noeud 118 correspond bien au dernier que j'ai installé.

Probablement un module qui floode le réseau.
Tu peux tenter d'utiliser le nouveau panneau de diagnostique Z-Wave pour essayer d'identifier ce module trop bavard, mais tu sembles avoir un coupable avec ton Wall Plug.

Oui effectivement.
Mon capteur est sous abris de la pluie et du soleil.

Il y a juste une petite période de l'année, vers le mois de juin, quand le soleil se lève très tôt au nord-est, les premiers rayons viennent sur le capteur, ce qui fait une petite "bosse" sur la courbe de mesure, mais c'est le soleil du matin, pas bien méchant. Clairement le module a plus chaud en fin de journée quand il est à l'ombre, surtout en période de canicule.

Pour qu'il ne reçoive plus le soleil du matin j'hésite à m'imprimer un petit abri pour qu'il soit bien ventilé, mais ça sera plus visible et c'est un peu moche... là où il est fixé, sur une poutre du porche de la maison, c'est très discret.

exemple :

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

Il y a 2 heures, flacon030 a dit :

l'ESP32 ne semble pas réagir si je manipule l'afficheur ou la télécommande

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.