jjacques68

semble OK chez moi aussi. 6 min pour faire la mise à jour... taille des backups sans historiques : 3.4 Mo

en effet, punaise, je me souviens pas de tout ce que je dis moi

j'y ai pensé, mais alors je te dis pas le bordel pour contrôler cette pauvre TV, on a la total là : socket tcp, requete http, IFTTT pour google home et maintenant le zwave !! ça commence à faire... geek là ...

j'ai aussi 2 wallplug en version 3.52, j'ai pas de soucis. Mais j'ai désactivé toutes remontées d'énergie. Pas s-ur que ce soit ces paramètres à mettre à 0 pour un wallplug... faut que je regarde...

c'est pas nouveau ça, si ?

Ce GLOBAL CACHE fonctionne super bien ! Viens de me créer un QA parent qui intègre une gestion de socket vers lui, et une gestion de requete HTTP pour les device qui le supporte. actuellement 2 childs (ampli + tv) qui selon la commande demandée, utilisent les ressources du parent (donc socket ou requete). C'est juste nickel... Petit bémol, comment savoir si le device est allumé ou pas avec l'IR ?? ---> pas de retour d'état !! Donc si je demande l'extinction du device et qu'il est déjà éteint, ben il s'allume, vu que la commande ON = OFF en IR... J'ai pas ce problème avec le TV, car je l'éteins par la socket. et l'allume par l'IR, donc si elle est éteinte ben il se passe rien. Mais l'ampli, tout en IR, ça loupe pas...

ahhhhhhhh, faut que je relise à tête reposée...

oui tout à fait. et le coup du quickApp sans majuscule, c'est quoi une "bibliothèque" ?

donc si,je suis ce que tu dis, dans la fonction mainloop(), si je mets pas le self en argument, je ne peux pas utiliser les instructions self:debug() et autres ?

j'ai compris jusqu'au coup du quickApp sans majuscule

j'imagine bien oui, je te demande de le faire forcément toi même, je me dit que ça doit exister quand même !! une sorte de cartographie...

c'est réalisable de représenter le fonctionnement sur un schéma, une map, le rendre visuel quoi ? je encore pas trouvé de tel documents...

euh... franchement, sans vouloir te vexer, avec tout le respect, toute mon admiration, toutes ma sympathie et toute ma reconnaissance : NON

ben justement, j'ai vu passer des exemple avec eedomus, j'ai l'impression qu'une API accessible existe... Après vue le prix, je prends pas trop de risques... Mais je comprends pas pourquoi personnes n'a inventer une sorte de dôme à fixer au plafond, avec des led qui arrosent à 360°, avec connection ethernet POE, avec une API par socket ou HTTP, sans cloud, sans plein d'options inutiles, juste avec l'essentiel, en tenant compte des différentes fréquences pour être compatible avec tous les appareils, avec un mode d'apprentissage, ben voilà le cahier des charges est posé , pas compliqué quand même

c'est fait.

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