Lazer

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 :

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.