Lazer

Merci, donc tout à fait conforme à ce qui est attendu, j'ai eu exactement le même log chez moi ce matin à minuit Étrange, je veux bien te croire, un bug peut toujours se produire, il faudra être vigilant et la prochaine fois, bien reprendre le log, depuis minuit si possible, pour essayer d'analyser et comprendre ce qui se passe. Non non, j'ai bien activé les notifications, justement parce que c'est utile pour moi, afin de savoir à l'avance. J'ai au moins un cas d'usage qui ne peut pas être domotisé, car c'est "humain" : Puisqu'à 7h du matin le QA va chercher la couleur du lendemain, au réveil je connais la couleur du jour ET la couleur du lendemain, et ça me permet de choisir mes jours de télétravail ou de glandouille en présentiel au bureau. J'ai parfois des contraintes qui m'empêchent de choisir, mais quand j'en ai la possibilité, c'est toujours appréciable de pouvoir moduler dynamiquement en fonction de la couleur des 2 jours consécutifs. Dans le QA j'ai ajouté cette vérification de la correspondance des couleurs entre les différentes sources (RTE EDF et Téléinfo) comme étant une sécurité additionnelle, et depuis 2 mois que le QA fonctionne chez moi, cette sécurité n'a jamais eu besoin de me notifier (= jamais d'erreur) Je ne comprends pas pourquoi ça se produit chez toi, mais finalement ça donne tout son sens à cette vérification : on détecte le problème et on va le corriger (oui on va y arriver) Voilà, c'est ça qu'on va chercher à comprendre. Comme dit, la prochaine fois que le bug se produit, tu prends bien les logs, idéalement depuis minuit, et on va essayer de tirer ça au clair.

No sorry I did not try, I just made the screenshot quickly then closed the window ! EDIT : I guess we should use the new QuickApp's content display mode to be able to perform long press...

J'ai aussi pas mal de modules, Fibaro ou autre marque, qui ont N/A. Quand on cherche dans l'API, ce sont des modules qu'on ne trouve pas, donc pour une raison que j'ignore, le moteur Z-Wave n'a pas de statistique pour ces modules là : /api/apps/com.fibaro.zwave/diagnostics/transmissions Je n'avais pas fait attention qu'on était sur le topic où j'ai justement fait un topo sur cette nouvelle API de diagnostique Z-Wave, donc je renvoie vers le message en question qui décrit l'API. Après il reste à construire un script LUA pour analyser tout ça, fait des notifications, statistiques, ou que sais-je... je n'ai pas encore eu le temps, ou plutôt l'occasion vu que mon réseau est pleinement fonctionnel, pur me pencher plus que ça sur le sujet :

Alors, pour les appuis longs sur les boutons des QuickApps, cela se configure dans la fenêtre des propriétés du bouton, on a 2 nouveaux champs pour désigner les fonctions appelées dont le nom est parlant : onLongPressDown onLongPressReleased Cela vient donc en complément du onReleased qui existe depuis toujours, pour le clic simple sur le bouton.

Non malheureusement... Logiquement à minuit, mais je ne suis pas allé vérifié. J'ai ajouté le changement d’icône pour faire plaisir à quelques uns ici ( mprinfo ) mais perso je ne l'utilise pas, je suis informé par les notifications ça me suffit. Et surtout, ce sont les automatisations (dans GEA) qui font le job grâce aux variables globales. A part l'affichage de l'icone, le QA n'a pas de statut, il ne bascule donc pas. Ce sont les variables globales qui sont censées refléter le changement de jour. Dans ce cas tu peux utiliser le QA de @mprinfo car c'est comme cela que fonctionne le siens, si le fonctionnement est plus logique pour toi. Comme dit, je me suis calé sur les jours calendaires, comme les API RTE et EDF le font. J'en doute, normalement on utilise des variables globales différentes... après ça dépend comme tu as configuré les QA, je ne me souviens plus trop pour celui de mprinfo (que je n'utilise plus), mais pour le miens on peut personnaliser le nom des VG, du coup le risque existe de mettre les mêmes noms.

J'ose pas faire la mise à jour de l'app... tellement de changement que j'ai peur que ça casse tout... Sinon ça a l'air sympa cette nouveauté, je me demande quel peut être le cas d'usage : Support for long button press in Quick App.

Magnifique, merci pour le tuto Jeedom bien complet

A priori oui ça devrait fonctionner, j'ai retrouvé une syntaxe que j'avais testé : GEA.add({"Climate!", "Default Room", "Mode", "xxx"}, 0, "", {{"Test", "Zone #name# mode : #value#"}}) Règle toujours valide dans cet exemple vu que le Mode ne peut jamais avoir la valeur "xxx".

Nickel

C'est strictement supérieur ou inférieur. Extrait : if type(num1) == "number" and type(num2) == "number" then if plus then checked = num2 > num1 else checked = num2 < num1 end else checked = false end

Je doute fort que tu puisses interroger la Freebox avec de simples requêtes HTTP. Je crois bien que Free documente cela, tu devrais trouver ton bonheur sur leur site. Mais je pense que ça ne va pas être simple, car à l'époque de la HC2, @Krikroff avait développé un module virtuel complet pour s'interfacer avec la Freebox, mais il me semble que ça n'a pas été porté sur HC3 :

Effectivement aujourd'hui il y a eu un souci, c'est la première fois que je vois ça, EDF et RTE étaient en retard pour signaler la couleur du lendemain. Vu que c'est la CRE qui calcule la couleur du lendemain, je suppose que le problème vient de chez eux. Mon QA n'a obtenu la couleur depuis EDF qu'à 12h13, et RTE à 13h10. @RS600807 Ton log est illisible, est-ce que tu peux le mettre dans un fichier texte, avec l'extension LUA (car l'extension TXT est bloquée par le forum) et le partager STP ? Et prend bien toute la journée, à partir de minuit, parce que attention, à te lire, j'ai l'impression que tu n'as pas saisit un point important de mon QA. J'en avais parlé un peu plus haut, la couleur du jour n'est pas aligné sur la téléinfo (donc cycle débutant à 6h), mais sur l'API fournie par RTE et EDF, donc par journée calendaire (cycle débutant à 0h). Ton QA a dû passer en BLANC à minuit ce matin : La variable téléinfo_tarif n'est interrogée qu'à 7h du matin, afin de confirmer la couleur du jour, qu'on connait déjà depuis minuit du coup, et ça, ça a bien fonctionné aujourd'hui :

Commence déjà par les requête de type GET (avec ton navigateur, tout simplement) pour lire le statut du module. Si ça ne répond pas, c'est peut être parce que tu n'as pas saisis le bon nom de ton composant Climate, comme dit plus haut, ça se configure dans le fichier YAML.

La pastille verte c'est juste pour dire que les modules sont correctement configurés, et à priori pas du tout pour dire si leur fonctionnement est normal ou pas. Par exemple mes modules Qubino Fil Pilote, qui ne finissent pas l'inclusion correctement (bug de leur firmware) ont une pastille d'avertissement : On constate que les compteurs restent à 0 pour ces modules, néanmoins ils fonctionnent parfaitement. De manière similaire, leur table de routage reste désespérément vide, je n'ai jamais pu savoir s'ils utilisent le maillage ou non. J'ai envie de dire que la moindre erreur n'est pas normale et doit être analysée. Après si c'est une erreur tous les 36 du mois, c'est peut être pas bien gênant. Si c'est tous les jours, là on peu commencer à analyser la situation. Quant à l'API, c'est à toi de fixer tes règles, justement basé sur l'expérience et l'analyse du dessus. Un nœud mort, ça fait longtemps qu'on sait lever une alerte (avec GEA ou un script dédié).... on peut imaginer quelque chose de similaire en fonction de 2 conditions par exemple : - nombre d'erreur > 0 - nombre de frame/hour > à un certain seuil Là tout de suite, chez moi, ça monte à 492 frames/heure pour une multiprise Greewave, ce qui n'empêche pas le réseau de fonctionner parfaitement (pas de latence, ou alors assez rarement) Le second module est aussi une Greewave Powernode, puis c'est un module Qubino Flush Shutter DC pour Velux mais équipé d'une sonde de température déportée et réglée avec une sensibilité de 0.1°C donc bavard. En 4ème position, le relai Aeotec Heavy Duty de ma PAC, qui remonte la consommation électrique régulièrement. Chez moi, je n'ai aucun "failed communication"

Tu as lu la doc ? Parce que c'est indiqué clairement : - GET c'est pour lire - POST pour écrire C'est de l'API REST assez standard.

Qu'est ce que t'as encore fait comme bêtise pour mériter ça ?

OK, mais du coup tu as fait comment pour configurer ça ? Et pour l'utiliser, tu as réussi à utiliser une autre source que Amazon Music avec Alexa ?

Ah oui ESPEasy ça me dit quelque chose, c'est pas tout jeune je crois. Quand Home Assistant est arrivé, ils ont intégré nativement ESPHome qui est issu des mêmes équipes, après son passage ça a un peu balayé tous les anciens projets j'ai l'impression (Tasmota, etc...) Pour le reste, je ne pourrai pas t'aider beaucoup plus... Si tu veux attaquer ESPHome via l'API REST, c'est possible, c'est ce que j'ai utilisé dans la première version de mon QuickApp, mais il y a pas mal de limitations, comme l'absence de mise à jour en temps réel (il faut interroger à intervalle régulier), pas de contrôle de la vitesse du ventilateur (bug non corrigé), ni de l'orientation des ailettes (non prévu à priori). Tu peux t'aider de la doc que tu as peut être déjà : https://esphome.io/web-api/index.html Ce sont de simples requêtes GET et POST. Voici 2 exemples en ligne de commande issus de mes notes pendants mes tests, en supposant que le le composant climate s'appelle split_mitsubshi (configuré dans le fichier YAML envoyé vers l'ESP32 lors de la compilation de ESPHome) : curl "http://1.2.3.4/climate/split_mitsubishi/set?mode=OFF" -X POST --data-raw true curl "http://1.2.3.4/climate/split_mitsubishi/set?target_temperature=20.5" -X POST --data-raw true

Oui et oui.

IFIFY 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é :

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