jjacques68

ok je comprends. euh..... la je comprends pas ducoup... C'est l'inverse, fonction à patient à la classe QuickApp !! à cause du self roah punaise ça m'a toujours rendu dingue ce truc !! Tu crois avoir compris... puis tu vois un autre exemple qui te flingue les neuronnes

je vais poser une question bête mais je la pose : pourquoi les "self" dans les arguments des fonctions ? comme : function startPolling(self,interval) ... end ... startPolling(self,1000) ou encore: DevicePropertyUpdatedEvent = function(self,d) ... end,

pfiou !! y en a des choses !!

héhé Global caché reçu C'est vraiment une solution de bricolo, avec les petit fil qui vont vers chaque équipements, mais bon, rien d'autre ... on va jouer un peu, premier essai à l'arrache = concluant. Tout se passe par socket TCP, donc ça va le faire J'ai aussi commandé un Boradlink pro, pour voir ce que ça donne

tu n'es pas obligé de traiter toutes les infos, moi, de mémoire, je traite les "DevicePropertyUpdateEvent", "NotificationCreatedEvent" et "CentralSceneEvent". Les autres trames passent aux oubliettes

il y a 2 cas de figure suivant l'option choisi dans les propriétés de la scène : Soit un nouvel événement annule l'instance en cours pour en commencer une nouvelle (alors là c'est une rupture net de l'instance en cours) Soit le nouvel événement est ignoré au profit de l'instance en cours.

bah en même temps, ils nous mettent les outils pour, on en profite...

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...