Lazer

Effectivement le Reboot ne fonctionnait plus depuis le firmware 5.050.13 : Si tu as une scène dans laquelle ça fonctionne, je veux bien que tu la partages, ça m'aidera à comprendre.

Oui @domo comme le précise Jojo, c'est pas cohérent, dans le commentaire tu parles de "ET" et dans ta règle tu mets un "OU". A mon avis il faut simplement que tu vires le "Or" et les accolades qui vont avec, car tu veux que les 2 conditions soient remplies simultanément, et non pas l'une OU l'autre.

Dans ta condition il y a quelques erreurs de syntaxe. Il faut bien regarder les accolades ouvrantes et fermantes que tu as mis (tu peux utiliser Notepad++ avec la colorisation syntaxique LUA pour aider). En fait tu as mis 2 conditions distinctes, séparées par une virgule : {"Value+", {"Value", id["Temp_EauPiscine"]}} et : {"VariableCache", "TempPiscineCache"} En outre, chaque condition n'est pas validée, car rien que dans la première tu as une erreur de syntaxe (des "Value" imbriquées), et puis tu compares à ... rien ! Idem pour la 2nde condition, il n'a pas de comparaison. Essaye plutôt comme ça : GEA.add({{"Value+", id["Temp_EauPiscine"], {"VariableCache", "TempPiscineCache"}}}, 5 * 60, "La température de la piscine a augmenté : #value#°C", {{"Repeat"}, {"VariableCache", "TempPiscineCache", {"Value", id["Temp_EauPiscine"]}}})

Bonjour, Merci

Tu devrais poser la question au support Fibaro... peut être un bug avec ce module en particulier ?

Alors, la cagnotte en est à 199,91 € Donc c'est bon pour juillet Mais encore trop juste pour janvier.

Étonnant, pas de power... pourtant il y a bien energy dans le JSON. Est-ce que tu peux regarder sur les autres modules enfants (probablement cachés), pour voir si le power ne s'y retrouverait pas sur l'un d'entre eux ?

Étonnant. Partage son JSON complet pour voir : /api/devices/ID Normalement on doit voir power dans les properties, ainsi que dans les interfaces.

Oui c'est une pratique courante, j'utilise GEA pour tous mes scénarios, et j'ai de nombreuses règles qui exploitent la consommation des équipements.

Oui c'est une bonne idée d'utiliser la consommation pour connaitre l'état de fonctionnement des appareils derrière. Mais attention effectivement à la consommation. Un moteur inductif, ça peut faire des appels de courant 10, 100, voire 1000 fois supérieur au courant nominal. La conséquence à terme, c'est de coller le micro-relai intégré au Wall Plug (le courant élevé crée un arc au niveau des lamelles du relai, ce qui crée un échauffement, et à la longue ça finit par coller le relai) J'ai collé des relais dans un Wall Plug et un FGS.avec des appareils qui consomment seulement 20W en nominal, à cause de l'appel de courant de ces charges inductives. Idéalement pour de telles charges, il faut un contacteur de puissance (Legrand, etc), piloté par un FGS. C'est plus cher, plus gros, mais plus durable et surtout plus sécurisé. Le problème avec ce montage, c'est que le module domotique ne voit plus la consommation de l'appareil, donc ça invalide le scénario envisagé de mesure de la conso pour connaitre l'état de fonctionnement de l'appareil.

Dans ton code LUA tu peux définir une variable dans ton QuickApp. Par exemple, très simplifié : au début de ta séquence : self.sequence_en_cours = true à la fin de ta séquence : self.sequence_en_cours = false Et dans le code de ton autre bouton, tu commence par faire le test de la variable : if not self.sequence_en_cours then -- OK on fait les actions... else print("Ah bah non alors, il faut attendre...") end

Après quelques tests avec différents modules, je pense avoir trouvé le fin mot de l'histoire : updateProperty fonctionne uniquement avec les QuickApps setProperty fonctionne avec tous les modules, Z-Wave et QuickApps Donc setProperty est plus universel et doit être utilisé. Je prépare une petite mise à jour de GEA avec quelques correctifs, à venir bientôt

Effectivement, le site de RTE affiche les infos.

Effectivement l'API de RTE semble hors-service : https://www.services-rte.com/fr/visualisez-les-donnees-publiees-par-rte/calendrier-des-offres-de-fourniture-de-type-tempo.html Le truc comme tu l'as constaté, c'est que l'interrogation RTE est faite le matin. Vu que tu as redémarré le QA, il a besoin d'interroger l'API RTE, sauf que si l'API est en panne cet après-midi, il n'y a rien que le QA puisse faire à part t'afficher un message d'insulte grossier Sur mes 2 box, comme je n'ai pas eu de redémarrage du QA dans l'après-midi, les infos RTE ont bien été obtenues le matin, et je ne me fais pas insulter ! Bref.... c'est bien une coincidence et il n'y a rien à faire à part attendre demain. On ne voit pas la suite de ton log, mais je suppose que le QA a obtenu l'info depuis l'API EDF, qui a l'air opérationnelle : https://particulier.edf.fr/fr/accueil/gestion-contrat/options/tempo.html#/ Donc pas de problème, c'est bien là tout l'intérêt de ce QA, d'obtenir l'information depuis plusieurs sources redondantes. PS : code d'erreur HTTP 500 c'est un problème coté serveur Web, aucune inquiétude ta HC3 va bien avec sa mise à jour

Cherche Homebridge sur le forum.

Alors ça non, car ce sont des fonctionnaires, d'ailleurs ce sont des agents et non des salariés. En dehors de ce "détail", je rappelle que le compteur communicant est une directive avant tout européenne. Parmi les bénéfices, il y a effectivement les économies réalisées sur le personnel, non pas en les virant, mais en les employant à d'autres tâches. Effectivement payer des gens à faire la tournée pour les relevés périodiques des compteurs et/ou les reprogrammation de calibre n'avait pas une grande valeur ajoutée. A plus long terme, ne pas remplacer les départs en retraite est aussi un autre moyen de faire des économies de personnel. Depuis que je suis producteur PV, je m'intéresse pas mal aux travaux techniques d'Enedis, mais pas à l'aspect ressources humaines. Il faudrait voir s'il existe des rapports sur l'évolution de la masse salariale. Mais vu l'ampleur des travaux à venir (adaptation aux énergies renouvelables et à l'évolution climatique), j'ai le sentiment que la quantité de travail va aller en augmentant. Reste à voir dans quelle proportion c'est sous-traité... Clairement oui. Rapide recherche : https://izi-by-edf.fr/blog/disjoncteur-abonne-fourniture/ Je pense qu'il faut que tu arrives à faire reconnaitre à Enedis (via ton fournisseur EDF, ou en direct auprès des services d'Enedis) que tu es bien face à un défaut de l'appareil. Afin qu'ils reconnaissent leur responsabilité.

Oui tout à fait C"est typiquement le genre de truc sur lequel on peut buter des heures alors qu'un œil extérieur peut le voir Ce qui fonctionne bien aussi, c'est d'arrêter, faire autre chose, et s'y remettre le lendemain avec un œil neuf justement !

Tu peux enlever le Content-Length et la Host. Apparemment d'après Postman les datas sont dans un double tableau imbriqué, essaye donc comme ceci : data = json.encode({{ ["cmd"]="Login", ["param"]={ ["User"]={ ["Version"]="0", ["userName"]="admin", ["password"]="xxxxxxxxxxxxxx" } } }})

Oui effectivement. Oui et non. Effectivement sur les nouvelles installations, Enedis règle le disjoncteur d'abonné (=AGCP) au plus gros calibre permis par les câbles installés (généralement c'est 60A), et laisse le compteur Linky faire la coupure en cas de dépassement de la puissance souscrite (c'est parfaitement documenté dans le document NOI-CPT_54E au Chapitre 7 : Contrôle de la puissance par l’organe de coupure du compteur. Et donc cela permet à Enedis de ne plus avoir à se préoccuper de ce disjoncteur, car la limitation de la puissance souscrite dans l'abonnement peut être programmé à distance dans Linky. A la clé, des économies (le technicien n'a plus besoin de se déplacer) et gain de temps (j'ai changé d'abonnement quand je suis passé à Tempo, j'ai appelé à 18h, c'était actif à minuit, génial) Mais, sur les anciennes installations (c'est mon cas), si on n'a jamais augmenté la puissance de son abonnement, alors le disjoncteur d'abonné reste à son calibre initial. Chez moi, il est toujours sur 45A, ce qui me pose des problèmes, car l'hiver dernier il a sauté un peu trop rapidement à mon gout, alors que d'autres fois j'ai tiré laaaaaaargement plus que mon abonnement, et il a tenu bon. C'est tout le problème avec ces vieux disjoncteurs, ils ne sont pas précis du tout, donc c'est problématique quand on s'amuse à s'approcher des limites. Le Linky réalise un calcul numérique de la puissance, c'est beaucoup plus précis, et la coupure intervient comme décrit dans le document cité plus haut. Ainsi, pas de mauvaise surprise (contrairement aux théories complotistes qui avaient cours il y a une dizaine d'année...) Bref c'était pas le sujet.... Reste que le disjoncteur d'abonné est toujours indispensable (et surtout obligatoire), même réglé sur un calibre supérieur (60A comme on l'a vu) à l'abonnement souscrit (45, voire 30A) En effet, d'une part il protège contre les court-circuits (courant très très élevé contre lequel l'organe de coupure du Linky ne peut rien faire), et d'autre part contre les fuites de courant puisqu'il intègre un différentiel de 500mA, ce qui ne sert pas à protéger les humains (il faut des différentiel à 30mA pour ça, dans le tableau de la maison), mais à empêcher les petits malins de se brancher entre la phase et la terre, sinon ça permettrait de consommer gratuitement.... Ouais le truc grippé.... perso j'ai jeté à la poubelle par précaution un vieil interrupteur différentiel qui bloquait de la même façon. Mais c'était possible car c'était dans mon tableau, là dans ton cas, l'histoire avec Enedis Pro je n'ai jamais entendu parler de ça perso. Je pense que @Did doit connaitre, mais il n'est plus trop actif... espérons qu'il t'entende

Super. Si, il y a une option cachée et non documentée ( ), c'est "Test", qui permet d'afficher ce qu'on veut dans le log de GEA. A utiliser dans les actions, donc par exemple : GEA.add({mes conditions}, durée, "notification", {{"Test", "La valeur de la première condition est #value#"})}) Oui tu peux utiliser value+ et value- pour faire toutes les comparisons numériques que tu veux, mais attention encore une fois dans ton exemple, tu as remis des guillemets autour de tes valeurs 12 et 14, ce qui en fait des string, et non des numbers.... par ailleurs l'ajout .0 est inutile. Note que ce sont des comparaisons "strictement" supérieur ou inférieur. Donc la règle se déclenchera uniquement si la température fait au minimum 12.1 degré et au maximum 13.9°C

Oui voilà, ça "aide", tout au plus. Le problème c'est que ça induis plus souvent en erreur que ça n'aide, alors perso j'ai du mal à la voir l'aide... Après je m'amuse bien pour générer des images à la con, c'est totalement inutile et donc amusant. Reprend les bases : la doc de syntaxe, tu as la syntaxe (forcément...) et quelques exemples basique d'utilisation VariableCache. Sinon, à l'ancienne, avec Google (ou ton autre moteur de recherche préféré), tu as des tonnes d'exemple d'utilisation sur le forum (enfin, sur ce topic essentiellement) Mais bon, déjà je peux te dire que ça s'utilise comme Global.

Le 1er souci, c'est que ChatGPT sait plein de trucs mais n'y comprends rien, résultat ce qu'il répond est à coté de la plaque dans la majorité des cas. Le pire dans l'histoire, c'est que parfois il tombe par hasard sur la bonne réponse, mais avec un argumentaire faux (souvenez vous quand vous étiez étudiants quand les profs notaient le raisonnement et la démonstration, même si le résultat du calcul était faux, bah là c'est l'inverse ). Quand les gens auront compris ça, ils arrêteront de s'abrutir avec cet outil ce jouet et se remettront à utiliser leur cerveau, à l'ancienne... ouais je sais c'est démodé... mais quelque chose me dit que ça n'arrivera pas. Tant pis. Le 2nd souci, c'est que les Variables Globales ne peuvent pas contenir autre chose qu'une chaine de caractères (string). Dans GEA le code "essaye" de gérer les VG qui contiennent des valeurs numériques, mais je ne suis pas sûr que ça soit fiable à 100%. Il faudrait déboguer, mais là ça va être difficile car je peux difficilement reproduire chez moi. Mais est-ce que tu as absolument besoin de stocker la valeur dans une VG ? Car si tu n'as pas besoin de la persistence, tu peux contourner le problème en stockant la valeur dans une VariableCache (qui pour rappel est perdu en cas de redémarrage de GEA), qui présente l'avantage de pouvoir stocker n'importe quel type de valeur (boolean, number, string, etc). Donc en travaillant avec des numbers dans toutes tes règles, depuis la récupération de la value de ton module, en passant par le stockage dans la VariableCache, puis la comparaison, ça devrait au moins éliminer le problème des comparaisons entre types de variables différents.

Du coup continue sur ta lancée et demande à ChatGPT, je suis curieux de voir la réponse (Jojo t'as répondu entre temps)

Moi ce qui me choque dans tes règles, c'est que tu compares des nombres (la value de id["Temp_Piscine"] est numérique, tu peux vérifier ça dans son JSON avec /api/devices/ID) avec des chaines de caractères "40.0" est une string au sens LUA. C'est certainement une écriture que tu as hérité depuis la HC2, mais dès le passage sur HC3, Fibaro a enfin modifié tous les types des champs value des différents modules pour qu'ils soient plus cohérents (number, boolean, etc). On en avait plusieurs fois parlé à l'époque lors des premières migrations de GEA HC2 vers HC3. Je m'étonne que tu aies encore ce type d'écriture et que ça fonctionne depuis tout ce temps !

Parfait comme ça