Steven
-
Compteur de contenus
4 434 -
Inscription
-
Dernière visite
-
Jours gagnés
201
Tout ce qui a été posté par Steven
-
Pour mon, un VG n'a de l'intérêt que pour échanger de l'information entre scènes/VD, ... moins on y fait appel plus le scénario est performant. Stocker un VG signifie stocker des informations dans la base de données de la HC2. Donc stocker des données déjà présentent dans la base est, pour moi, inutile. Par exemple, les ID des modules d'une pièce sont déjà dans la base. Si la base de données de la HC2 est bien indexée, aller lire une VG devrait revenir au même que de demander la liste des modules d'une pièce. Mais je ne connais pas la structure de la base. Pour ce qui est des scénarios, je fais un peu comme toi. C'est à dire, regarder les déclencheurs et regrouper les actions par déclencheur. Mais cela reste un choix purement personnel, je ne pense pas qu'un solution soit meilleur qu'une autre. Est-ce mieux de déclencher 4-5 petites scènes bien optimisées ou 1 grosse scène ? Perso, je pense qu'il faut se baser uniquement sur "ses préférences" et "sa propre organisation". La HC2 est capable de supporter beaucoup de chose et se contraindre à la soulager est presque ridicule. Donc, pour résumé, je dirais que tu as raison car tu y vas selon ton feeling.
-
GEA.add({"Time", "06:15"}, 30, "Change CarHeater Time +2 H", {{"VirtualDevice", VD["CarHeater"], "2"},{"VirtualDevice", VD["CarHeater"], "2"}}) Simply like this.
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
Pour moi, cela dépends principalement du nombres d'interactions qu'on les modules entre eux. Mais cela uniquement car je n'aime pas les variables globales.
-
Pour les volets, je ferais aussi un peu attention.
-
Mais, mais, mais, je n'ai rien à dire sur les icônes, configuration, et autres que vous souhaitez mettre/afficher dans votre box. Je suis juste présent pour aider la communauté et prendre du plaisir. P.S. Elle est très bien avec le réveil, mais il faudrait plusieurs réveils pour le "multi"
-
Vraiment étrange car ton code semble bon. As-tu tenté de mettre une temporisation. Du style (code très sale) if (not i) then i = 0 end if i % 5 == 0 then --- ton code ici end Juste pour vérifier que si ton code est exécuté une fois sur 5, il ne plante pas.
-
Je ne crois pas que cela soit possible depuis le cloud fibaro.
-
Aurais-tu un autre script qui fait des setGlobal de la même variable ? Je pense à un "lock" quand 2 applications mettent à jour la même variable.
-
C'est cool, tu aurais du partager
-
Merci. Pris en compte pour la prochaine version . Par contre attention car il y a le même code à modifier dans le code mais ailleurs. Recherche "pluginscenario = " et regarde 11 lignes en dessous.
-
Un MainLoop qui tourne toutes les 3 secondes et qui plante sur 3 getGlobal et un setGlobal, ce n'est pas fréquent. A la lecture du code, j'ai l'impression qu'il n'y a que quelques variables globales qui doivent être vérifiée ou modifiée toutes les 3 secondes. Il serait bien de les identifier et d'aller chercher les autres qu'une seule fois. Exemple : local roomName = "salon" if (not room_zone) then room_zone = fibaro:getGlobalValue("zone_"..roomName) end ...
-
Omg, I missed something, someone (can't remember who yet) asked me to translate the VD Alarm and I missed it. The problem is that "Lu", "Ma", ... have no match in english except "Sa" Saturday or Samedi. I sure you use GEA in English so there is no matching. For now, you have to correct it manually by changing the code behind every "Days" buttons. Replace this : local jours = {"Lu", "Ma", "Me", "Je", "Ve", "Sa", "Di"} By this : local jours = {"Mo", "Tu", "We", "Th", "Fr", "Sa", "Su"} And it should works.
- 12 330 réponses
-
- 2
-
-
- support
- script lua
- (et 1 en plus)
-
v.6.11 ajouté le 13 novembre 2018 ... ICI mod : correction d'un bug dans checklabel add : {"Protection", <id>, <type_protection>, <On|Off>} by @971jmd add : {"MultiAlarm", <id vd>, <label>} by @drboss
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
J'ai encore, par curiosité, vérifier mon GEA. A aucun moment, je vérifie l'état d'un module avant d'effectuer une action dessus. Résultat, 0 plantée depuis des années. Le seul moment ou je vérifie est si je veux que le module s'éteigne après X temps, du style GEA.add( 128, 300, "Allumé depuis 300sec", {"turnOff"}) Car dans ce cas, je n'ai pas le choix.
-
D'un point de vue humain, je comprends le raisonnement de @pepite. Si on voit que la lampe est éteinte, on l'allume sinon on ne fait rien. D'un point de vue logique ... on s'en fiche de son état, on veux qu'elle soit allumée .. point final. Donc on laisse la box se débrouiller par elle-même. Après tout, à chacun son boulot
-
Pour ce qui concerne des relais et des VG, le test est selon moi inutile car la box le fait systématiquement. La HC2 vérifie systématiquement l'état d'un module et d'une VG avant de changer son état. Donc pour moi, il est quasiment inutile d'aller systématiquement l'interroger pour connaitre son état avant d'envoyer une demande. Si tu allume un module déjà allumé ... la box n'envoi pas de trame z-wave, ce qui signifie qu'elle a vérifié l'état du module par elle-même. Si tu change la valeur d'une VG par la même valeur, la box ne change pas la VG, elle ne met pas la date à jour et n'envoi pas les "triggers" pour enclencher les scénarios. Bref, elle fait déjà le travail par elle-même. Donc fréquemment, tu ferras une double vérification inutile et plus coûteux. Après ... c'est une HC2, elle est largement capable de supporter tout cela
-
Une fois que tu auras validé le contenu des variables globales par des fibaro:debug(...) Perso, j'optimiserais le code ainsi : local roomName = "salon" -- If the Heater Mode is Auto set the Heater Status associated to the Zone Mode if ("Auto" == fibaro:getGlobalValue("rad_"..roomName.."_mode")) then -- Get Room Zone & Zone Mode associated local room_zone = fibaro:getGlobalValue("zone_"..roomName) fibaro:setGlobal("rad_"..roomName.."_status", fibaro:getGlobalValue("zone_"..room_zone.."_heat_value")) end Il faut savoir que l'usage de getGlobal ne retourne pas que la valeur de la Variable Global mais aussi sa date de mise à jour. Il est donc préférable d'utiliser getGlobalValue. Après le code de fibaro, fait la même chose dans les 2 cas, mais on est jamais à l'abri d'une optimisation de leur part.
-
GEA.add({{"Global", "PresentState", "Home"}, {"Days", "Weekday"}, {"Time", "06:00"},{"Armed", id["MOTION_SALON"]}}, 60, "Alarme Rez désactivé à 6:00", {{"Portable", {phone["phone_nathalie"], phone["phone_thomas"]}}, {"setDisarmed", {id["PORTE_ENTREE"], id["PORTE_GARAGE"], id["MOTION_SALON"]}}, {"Scenario", 76}, {"turnOn", id["FER_EA_REPASSER"]}}}) Il manque une accolade.
-
Il semble manquer un } après le 536 et ce sur les 2 lignes
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
Adjugé , je l'ai déjà ajouté dans les plugins l'intégration dans la version 6.11 arrivera sous peu.
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
c'est bien cela.
-
Je ne peux pas faire une action qui s'appelle "protection" et qui reçoit "local", "rf", "off" ou "local_rf" puis deux autres conditions qui s'appelle autrement et qui reçoivent des paramètres différents, cela est trop compliqué pour l'utilisateur. En revanche, si tu souhaite garder ta version, il te suffit de la mettre dans ton "config()" et elle écrasera automatiquement ma proposition. Donc pas de soucis à se faire.
-
Je l'ai fait. Le retour sera "off", "local", "rf" ou "local_rf".
-
Ah non, de "protection". Pour le programmateur, j'ai déjà testé et validé celui de @drboss. Je ne connais même pas le tiens (désolé mais je n'arrive pas suivre).
-
Le tiens est déjà intégré, adapté et testé (j'attends quand même le retour de @pepite quand il pourra), prêt à être diffusé dans la prochaine version.
