jjacques68

oui mais nan... sauf que... attention : La raison pour laquelle je me suis séparé des scènes est très simple : il n'y a plus de multi-instances possible !!! un exemple tout con parmi plusieurs que j'ai vécu : J'avais 1 scène unique qui me gère l'éclairage automatique des pièces via les PIR. J'avais tous les PIR en trigger pour cette scène. La scène allumait la lumière en fonction du trigger. C'était super bien foutu. (cette manière de faire était un héritage de la HC2) ça marchait nickel, MAIS... pour un célibataire... : Si 2 personnes entrent plus ou moins simultanément dans 2 pièces différentes, et bien qu'une seule s'allumera. Car tu n'as qu'une seule instance possible. Pour moi c'était pas acceptable. Sur la HC2 tu pouvais en avoir 10 max, fallait y aller pour que 10 personnes entrent simultanément dans 10 pièces différentes J'avais plusieurs mécanismes de ce genre qui fonctionnaient bien, mais avec des loupés (gestion des notification, log des evenements, ...) D'où mon passage par le refreshState, car là, quoi qu'il arrive, tu verras le changement d'état de tous les modules, (le FIFO des appels des méthodes, déjà expliqué par @Lazer je sais plus où), fera que tout ce passe bien... Après j'ai commencé à me servir du resfreshState avant que @Lazer ne code GEA... sinon je pense que j'aurai pris GEA... Et pareil, j'ai quasi 200 lignes dans ma liste de trigger , et dire qu'avant tout était dans des scènes... Depuis, je n'ai plus aucun soucis de ce genre.

c'était ma première version, je l'ai vite oublié, les trigger sont pas toujours évident à mettre en place et peu conviviaux... c'est ma solution actuelle : un seul et unique QA où j'ai : la fonction qui tourne en boucle pour analyser le refreshState la liste de tous les trigger avec action à faire (dans un tableau) Les actions peuvent être directement écrite dans la liste (si c'est simplement allumer qqch) ou faire appel à une méthode d'un autre QA si plus compliqué EDIT : vu comme ça, c'est franchement pas compliqué, mais après on rajoute des tonnes de trucs (gestion des notification, mémo des log, ...) c'est là que ça devient un peu l'usine à gaz...

et comment, faut faire un sacré tri @henri-allauch Je te donnerais bien mon script, mais pareil... il était simple au début, maintenant ça se complique...

oui oui, sinon tu vas devoir faire des reset du module...

allé, tu te prends une semaine de congé, et tu migres tout morceau par morceau... ou alors tu attends le prochain confinement...

alors non, un modules ne peut discuter qu'avec un seul contrôleur à la fois. et pour tes 33 modules, enlèves de la liste les modules enfants (sans nom), ça te réduira la liste Sinon bascule petit à petit, par secteur, ou par fonctionnalité, ce que j'avais fait il y a un an. Mais tu auras pas le choix si tu veux passer sur HC3, va falloir retrousser les manches...

et non, chez moi c'est des bons vieux 4 fils... c'est pour mes parents...

y aurait la box de Rexel, qui pilote nativement le RTS, mais ils disent pas si on peut lui envoyer des requêtes HTTP...

il existe pas de moyens moins "compliqué" pour piloter ces volets ? genre un module à mettre dans le tableau électrique avec une connexion ethernet et une API ?

@manulemalin : je veux pas faire de l'hors- sujet, mais tu pilotes quoi une passerelle RTS ? laquelle ?

moi, mais à l'ancienne, sans passer par le plugin Fibaro du GH.

t'aurais pas une vanne 1/4 de tour qui serait déréglée, tu crois qu'elle est ouverte, mais en fait pas entièrement... je sais pas si c'est possible, si on aurait forcé dessus...

ah oui et sans oublié le bon vieux classique : tirer le neutre dans les interrupteurs !!

tu récupères la valeur sous forme de chaine de caractères : "06:33"

ben voilà : tu récupères la valeur du sunrise/set de la box dans la variable. local maVar = api.get("/settings/info").sunriseHour

ah oui d'accord, oui donc tu as déjà fait les 3/4 du boulo

me suis fait avoir là...

curieux de voir comment tu vas faire... je sèche... à froid, je penserais ajouter un une fonction dans chaque QA pour ajouter un "log", et tester la présence de ce log... pffff super lourd...

pas sûr de comprendre ce que tu veux... il suffit de stocker l'heure dans une variable, et à chaque boucle, si l'heure en cours = l'heure de ta variable, tu déclenches...

ah oui c'est vrai exact aussi oui donc c'est plûtot l'arrêt que tu cherches !!

Moi j'ai utilisé le resfreshState pour intercepter les log... Quand y en a un de type "error", je m'envoie un mail avec les détails... Mais pas de notion de restart de QA...

allé un global cahé commandé, on verra...

ben voilà la version 1, ça reste simple on est d'accord

Voici la liste de référence à ce jour : 13/03/2021 self.listeParam = { ["ID-RF"] = { ["com.fibaro.remoteController"] = 0}, ["Fibargroup"] = { ["com.fibaro.FGMS001"] = 65535, ["com.fibaro.doorSensor"] = 64800, ["com.fibaro.FGMS001v2"] = 65535, ["com.fibaro.FGFS101"] = 86399, ["com.fibaro.lightSensor"] = 65535, ["com.fibaro.windowSensor"] = 64800, ["com.fibaro.temperatureSensor"] = 65535}, ["Danfoss"] = { ["com.fibaro.thermostatDanfoss"] = 600}, ["Horstmann Controls Limited"] = { ["com.fibaro.temperatureSensor"] = 86400}, ["Everspring"] = { ["com.fibaro.temperatureSensor"] = 16776000, ["com.fibaro.lightSensor"] = 16776000}, ["Philio Technology Corp"] = { ["com.fibaro.motionSensor"] = 432000}, } Je rappelle que le temps définit pour les Danfoss doit être personnalisé (cf. notice des vannes) le format de cette liste est le suivant : [zwaveCompany] = { [type1] = valeur max, [type2] = valeur max, },

Comme convenu, Voici un petit QA ultra simple, permettant de vérifier nos temps de réveil des modules sur batteries. Il permet également de mettre à jour ce paramètre. Tout se passe dans la console de debug. Le bouton "Liste les types" : permet de lister les différents fabriquant et le type des modules présent dans nos box (pour information uniquement) utilise la propriété "zwaveComapny" et "type" des devices. en vert, le fabriquant en blanc, les types Le bouton "Compare les temps" : permet de vérifier le temps de réveil "wakeUpTime" de chaque module par rapport à la liste de référence "self.listeParam" présent dans le onInit() du QA. En rouge, les devices avec le temps de réveil actuel, par rapport au temps maximum de référence Si un type de device n'est pas connu dans la liste de référence, une information sera affichée en bleu. La liste en question est visible dans le post suivant, que je mettrai à jour avec les futurs modules, ou si vous me postez vos infos, histoire d'avoir une base complète... Le bouton "Modifie les temps" : modifie le "wakeUpTime" de chaque module don la valeur n'est pas identique à la valeur présente dans la liste de référence. Ci-joint l'icone : (mon IHM est sous fond blanc, vous aurez compris...) Le QA étant de type générique, se référer à la méthode "barbare" (expliquée à gauche et à droite sur le forum) afin de mettre l'icone en place Et décommenter la la ligne suivante dans le onInit(), en mettant le bon numéro de l'icone (à la place de 1089). Ci-joint le QA : Version 1 - 13/03/2021 : WakeUpTime.fqa Version 2 - 16/06/2021 : WakeUpTime_2.fqa Subtilités : Penser à réveiller les modules pour que la modification prenne effet !! Si vous redémarrez la box après avoir cliquez sur le bouton "Modifie les temps", sans avoir réveillé les modules, la modification est à refaire (attention au reboot du backup auto...) Pour les vannes Danfoss, il ne faut pas mettre le wakeUpTime au max, sous peine de ne plus avoir de chauffage (chez moi, j'ai mis 10 min) Le cas des capteurs multiples (typiquement les FGMS) : Il y a plusieurs type ("temperaturSensor", "lightSensor", ...) pour le même device... J'ai essayé de contourner ce problème en utilisant plutôt la propriété "baseType" au lieu de "zwaveCompany", mais je n'arrive pas à faire un meilleur tri avec cette info. J'ai essayé de passer par le "parentID", mais idem, le type ne nous aide pas. Donc j'ai laissé tel quel, cela ne gène pas du tout le fonctionnement. Evolutions : Dans la liste de référence, ne sont présent que mes devices à ce jour. Si vous avez d'autres devices, ils seront donc visibles avec le bouton "Liste les types". Il faudra alors rechercher dans la documentation (hé oui pas le choix ), le temps maximum de réveil que supporte le module. Et ainsi mettre à jour la liste de référence, en la complétant ou la modifiant (sans oublier de publier votre mise à jour sur le fofo )