Lazer
-
Compteur de contenus
26 052 -
Inscription
-
Dernière visite
-
Jours gagnés
1 296
Tout ce qui a été posté par Lazer
-
Le souci c'est que si le portail se referme en moins de 30s, alors la règle risque de ne pas être déclenchée si on met une durée = 0. Je préfère pour cette raison le déclenchement instantané avec -1. Reste que pour les autres conditions (Dates, Time...) il vaut mieux prendre le réflexe de les mettre entre parenthèse, on n'est pas à l'abri d'une évolution future de GEA... En ce qui concerne la condition Dates lors du changement d'année, je crois me souvenir qu'il y a un bug justement, l'année dernière mon sapin ne s'allumait plus correctement après le 1er janvier... il faudrait que je profite de la prochaine nouvelle année pour faire des tests et confirmer ou non le bug. Dans le doute, utiliser un "Or" avec 2 conditions dates, une qui se termine le 31/12, et l'autre qui commence le 01/01, permet de contourner le problème.
-
Après les Stable-pas-Stable, voici les Beta-pas-Stable-non-plus, ils ont repris le rythme chez Fibaro
-
Ah si c'est possible, je l'utilise dans plusieurs de mes QuickApps, il faut utiliser la librairie net.UDPSocket() Voir la doc : https://manuals.fibaro.com/home-center-3-quick-apps/ Il faudra tout de même coder à la main le protocole Syslog en LUA pour envoyer les bonnes trames sur le réseau. Pour récupérer tous les événements, tu peux t'inspirer du travail de @jjacques68 qui fait déjà un travail similaire dans une de ses bases de données perso. Je ne retrouve pas de topic, mais s'il passe par là il pourra te renseigner. Mais je pense qu'il faut partir de l'API refreshStates pour récupérer tous les événements de la HC3 :
-
Ah le grand retour des versions stables pas stables Heureusement qu'on a des hotfix
-
Ah oui complètement je n'avais pas vu ça. Bien vu, tu as donc une excellente vue
-
N'hésite pas non plus à bien regarder le log de GEA, en activant l'option GEA.debug = true dans ta config, ça permet de voir ce qui se passe en détail lors du test de chacune des conditions de ta règle. C'est plus facile en isolant la règle à étudier, pour cela il veut mieux faire tourner GEA avec uniquement la règle à debugguer, sinon l'affichage du log va être pollué par les messages des autres règles. Sonos je ne sais pas, j'ai abandonné cette marque depuis plusieurs années.
-
Rien de choquant dans tes règles GEA. Mais tu as vérifié les consommations de tes 3 appareils durant le cycle de fonctionnement, et après, c'est à dire en veille / à l'arrêt ? Le mieux pour ça est de regarder les courbes de consommation de ces appareils, soit dans l'interface graphique de la box, dans l'onglet de chaque module, ou bien dans DomoCharts si tu l'utilises. Tu aurais être quelques surprises, des machines qui ne consomment par forcément comme tu le penses.
-
Tu as des exemples dans la doc de syntaxe, dans la section "PLUGINS INTERNES GEA", en personnalisant GEA.options qui permet de créer ses propres options (conditions et/ou actions) mais aussi de redéfinir des options existantes. Ce second cas est finalement le plus facile, puisqu'il suffit de copier/coller le code d'une option existante (qu'on trouve dans le code LUA de GEA), et modifier juste ce dont on a besoin dedans. Dans ton cas, il s'agit de rajouter l'appel à la fonction self:getMessage() sur le contenu du titre de l'Email envoyé. Attention tout de même à être vigilant de bien remplacer self par GEA. Exemple (non testé) : GEA.options.email = {name = "Email", optimize = true, action = function(id, message, sujet) if type(id) ~= "table" then id = {id} end for i=1, #id do fibaro.call(GEA:findUserId(id[i]), "sendEmail", GEA:getMessage(sujet or GEA.emailSubject), tools:urlencode(GEA:getMessage(message))) end end, }
- 12 377 réponses
-
- 2
-
-
- support
- script lua
- (et 1 en plus)
-
Bienvenue sur le forum
-
C'est étrange... et inquiétant à la fois. Il faudrait que je fasse le test avec ma box de test, car je n'ai aucune envie de casser ma box de prod (même si bon... apparemment mon système PV produit 0 virgule 0 Watts depuis ce midi... merci la neige... et je ne suis même pas chez moi pour en profiter)
-
Hum.... les rétroéclairages des boutons je n'ai jamais joué avec, donc je n'ai aucun avis sur la question. En tout cas espérons que le support Fibaro finisse le ménage proprement... il faudra insister gentiment je pense. En revanche : Je n'ai pas compris cette phrase.
-
Hum OK je comprends.... malheureusement tu as toujours des traces des anciens modules dans la DB, cette fonctionnalité de reset du réseau Z-Wave a toujours été problématique chez Fibaro (HC2, HC3...), je me demande même pourquoi elle existe tant ça apporte plus de problèmes qu'autre chose. Essaye peut être de contacter le support Fibaro en leur expliquant le problème et en désignant bien les anciens modules récalcitrants, ils pourront peut être faire le ménage à la main dans la DB.
-
Oui tu peux faire le même genre de scène avec GEA, mais c'est justement ce qu'il ne faut PAS faire, car tu le dis toi même, ce scénario ne fonctionne pas. Ce qui est bien normal, durant son cycle, la machine peut être amenée à consommer moins que prévu, et donc ton script va interpréter cette valeur comme étant la fin du cycle, ce qui est faux. Il te faut une règle GEA qui vérifie que la fin du cycle est terminée depuis disons au moins 5 minutes... en vérifiant que la puissance "Power" de ton module est inférieure à 2W depuis une durée de 300 secondes. C'est un exemple très simple, tu en trouveras des tout à fait similaires dans la doc de GEA, dont tu peux t'inspirer pour écrire ta première règle, on t'aidera à terminer si tu n'y arrives pas.
-
Me semble que c'est un vieux bug, tu as cherché sur le topic ? Je pense qu'une réinitialisation du module permet de corriger ce problème (à faire de préférence après l'exclusion)
-
Le site de RTE a du avoir quelques difficultés temporaires, ça arrive. De toute façon apres 7h, il y a très peu de chance que la couleur de lendemain ne change, le QA ne fait la vérification jusqu'à 11h que pour être certain que ça n'est pas le cas.
-
Bonjour à tous les contributeurs de ce forum
Lazer a répondu à un(e) sujet de GerardDeToulon dans Nouveau ? Présentez-vous
Bienvenue sur le forum -
Quand tu dis que tu as réinitialisé le Z-Wave... tu as bien réinitialisé toute la box ? Parce que sinon, la box connait encore les anciens modules, stocké dans la base de données interne de la box.
-
Effectivement, pour savoir quels sont les options qui interprètent le contenu du texte, il faut chercher l'appel à la fonction "getMessage" dans le code source de GEA. Pour les emails, on constate que le contenu de l'email est bien concerné, mais pas le titre. Il y a un certain nombres d'autres options pour lesquelles c'est le cas. SI tu as besoin pour une option en particulier (QuickApp dans ton cas), alors tu peux surcharger l'option, tu peux simplement la redéfinir dans ton propre fichier de config et la modifier comme tu veux pour y ajouter le getMessage.
-
Oui il faut contacter leur support, généralement ils proposent la réparation des anciennes box. A voir en fonction du prix demandé... je ne suis pas sûr que ça soit pertinent de s'acharner sur une box qui a plus de 10 ans... il faut peser le pour et le contre face d'une migration vers des évolutions comme la HC3 pour rester chez Fibaro, ou bien les autre solutions du marché.
-
Oui c'est possible, il faut utiliser #duration# dans le texte de la notification : "Porte garage ouverte depuis #duration#"
-
Seulement les jours Blancs et Rouge, on a eu 2 jours blancs la semaine dernière et j'ai bien reçu toutes les notifications. Les jours bleus, ce sont les jours normaux, donc pas de notif. (je dois toujours corriger mon QA avec la nouvelle version de l'API EDF.... en attendant il fonctionne avec l'API RTE)
-
Pas besoin de grande compétence de programmation pour constater qu'il n'y pas d'instruction Quit après l'erreur "impossible d'obtenir la version" contrairement à la majorité des autres erreurs. C'est juste ce que j'ai fait ce matin pour comprendre ce qui s'est passé chez toi. Tu as réussi à trouver et modifier le titre de l'email, je suis sûr que tu aurais aussi réussi à arriver à la même conclusion pour cette erreur Pour le "fi", c'est une des particularités du langage Shell... chaque langage a sa syntaxe qui lui est propre. Là ils ont décidé d'inverser les lettres du "if" pour clore la section, tout comme LUA a décidé d'utiliser un "end", l'indentation (tabulations) en Python, ou encore l'accolade dans beaucoup d'autres langages, voire rien du tout (en C/PHP/etc, si une seule instruction après le if, on peut omettre tout élément délimiteur de section) Bref, rien qu'avec la tabulation de mon script (relativement simple), je pense qu'on comprend facilement que le fi ferme le bloc if/else précédent... oui bon désolé dans l'extrait de 3 lignes de mon message précédent, il manque le début du "if"... il faut aller voir le code source.
-
Parce que ce n'est pas une erreur bloquante, si tu regardes le code source, tu verras qu'après l'envoi du mail d'erreur, il ne stoppe pas l'exécution du code, il continue à la suite. else Error "Erreur : impossible d'obtenir la version : code de retour HTTP ${CODE}" "${JSON}" fi La seule conséquence, c'est que le nom du fichier de sauvegarde ne comportera pas la version et le type stable/beta, pas vraiment gênant, comme on le constate d'ailleurs dans le 2nd mail que tu as reçu. On pourrait voir cela comme un message d'avertissement plus que d'erreur Reste que je ne sais pas pourquoi cette erreur est survenue (des services pas complètement redémarrés probablement), et pourquoi ta modification du titre d'email n'a pas eu d'effet sur ce mail.
-
Si bien sûr. La clé USB interne est appairée avec la carte mère, pas leurs numéros de série respectifs, et le logiciel Fibaro vérifie cela au démarrage. Change le stockage interne n'a de sens que si on veut utiliser la carte mère pour un autre usage.... faire tourner un autre logiciel domotique par exemple. Bon après, vu la consommation (14W) de la bête, pas sûr que ça soit pertinent vis à vis d'un mini-PC trouvable pour pas cher en Chine.
-
Je me suis peut être mal exprimé.... si dans le code de ton QA Enphase, tu n'as pas implémenté une routine qui détecte que le token est expiré pendant son fonctionnement (et demande en conséquence un renouvellement du token), alors il ne sera pas renouvelé, sauf au prochain démarrage du QA lorsque tu appelles à nouveau la fonction getToken(). Extrait de mon propre code : elseif response.status == 401 and not self.retryLogin then tools:warning("Need new token") self.retryLogin = true self.token = nil self:getToken({ et ça se trouve dans la fonction getEnvoyAPI() qui est appelée très régulièrement pour interroger l'Envoy.
