Lazer
-
Compteur de contenus
25 848 -
Inscription
-
Dernière visite
-
Jours gagnés
1 253
Tout ce qui a été posté par Lazer
-
OK, effectivement tu as bien un espace à la fin de la chaine de caractères... étrange, mais c'est comme ça. Donc ta configuration de GEA.portables est bonne.
-
Sur le forum officiel tout le monde se plaint des problèmes d'affichage des QA.... Je vois 2 solutions : - retour arrière - prendre son mal en patience et attendre une mise à jour
-
Et il existe même le zwave2mqtt !
-
Oui ça m'a l'air OK. Tu peux vérifier le nom EXACT des appareils en allant vérifier dans /api/iosDevices/ Ou bien utiliser l'ID de l'appareil mobile, que tu trouveras dans la même URL Je précise ça car je vois un espace à la fin de ta chaine de caractère, je ne sais pas si c'est OK ou pas.
-
Ta condition Sunset n'existe tout simplement pas ! Regarde dans la doc de syntaxe, il faut utiliser la condition Time, tu as des exemples permettant de limiter le déclenchement entre le Sunset et le Sunrise (la nuit quoi) Pareil pour ta notification, il n'y a aucune action qui s'appelle "iPad Pro de chris", GEA ne peut pas deviner que tu veux envoyer une notification. Le plus simple est de le mettre dans sa section config(), tu as une ligne GEA.portables=... dédiée à cet usage... présent dans la config par défaut de GEA, tu as juste à le compléter.
-
Quick App - DomoCharts - Graphiques sur NAS pour HC3
Lazer a répondu à un(e) sujet de Lazer dans Quick App Developpeur
Non pas du tout onInit() c'est juste une fonction, qui est appelée automatiquement lors du démarrage du QA, mais si celui-ci est déjà en fonctionnement quand on rappelle la fonction, selon comment le QA est codé, il va plus ou moins bien réagir au fait que le onInit soit relancé... Sinon l'astuce que j'avais employé à l'époque de la HC2 dans mon watchdog pour forcer le redémarrage d'un VD/Scène, c'était d'ajouter un saut de ligne à la fin du code LUA et de sauvegarder à nouveau... ce qui provoquait son redémarrage immédiat. Peut être que ça fonctionne aussi avec les QA, mais c'est un peu lourd à mettre en place en LUA. -
Quick App - DomoCharts - Graphiques sur NAS pour HC3
Lazer a répondu à un(e) sujet de Lazer dans Quick App Developpeur
Bizarre, pourquoi ne pas simplement modifier les variables du QA via l'interface graphique, tu n'y as pas accès ? Autrement tu peux modifier la variable d'un QA directement depuis une URL via l'API de la HC3 : /api/callAction?deviceID=128&name=setVariable&arg1=NAS_Address&arg2=192.168.1.66 ou, à tester : /api/callAction?deviceID=128&name=setVariable&arg1=NAS_Address&arg2="192.168.1.66" -
Quick App - Pilotage climatisation PAC Mitsubishi en local avec ESP32
Lazer a répondu à un(e) sujet de Lazer dans Quick App Developpeur
Ouh là là, c'est pas bon ça, l'ESP32 qui répond un paquet inconnu, comme si le protocole avait changé.... Pas le choix pour l'instant, il va falloir trouver le moyen de downgrader pour revenir à l'ancienne version de ESPHome... parce que reprendre le développement du QA, ça ne risque pas d'arriver avant un bon moment... pas du tout le temps pour ça en ce moment, surtout que son code LUA est loin d'être simple... -
Oui heureusement, mais il faut quand même que je m'occupe de corriger le problème avec EDF... désolé mais je n'ai pas eu trop de temps pour la domotique ces derniers temps.
-
Peut être que le header est mal formé et l'authentification non prise en compte. J'ai déjà eu des soucis similaires, non pas avec une box Homey, mais en ligne de commande avec curl ou bien encore avec HABridge. C'est après avoir trouvé la bonne syntaxe pour les headers que ça finit par fonctionner... normalement !
-
Ton URL est invalide, tu ne peux pas mettre le login / password dedans. ça fonctionne uniquement avec les navigateurs Web car ils décodent l'URL pour retirer le login/password et le mettre proprement dans les en-têtes (headers) de la requête HTTP (*) Je ne connais pas al Homey, mais il faut que tu trouves le moyen d'envoyer l'authentification proprement dans les headers. (*) Cela dit cet usage est déprécié depuis bien longtemps, les navigateurs le tolèrent encore mais ça ne durera peut être pas éternellement.
-
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 330 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)
