J3R3M

Je n'ai pas regardé ce qui avait changé dans les conditions d'accès l'API, il n'est pas impossible qu'ils aient considérablement baissé le nombre de requêtes possibles vers leur API. Tu peux effectivement essayé avec la scène qui est dans mon post NetAtmo Welcome, mais, dans tous les cas, ne supprime pas celle existante pour le moment!

J'ai comme un doute... Vos scènes récupèrent les infos de quel(s) produit(s) NetAtmo ? Pour info, le script Cam Finder n'est utile qu'une seule fois afin de récupérer les infos à intégrer dans la Home Center. Sauf si je n'ai pas saisi l'utilisation qui en est faite ici ?

Pour régler cette nouvelle erreur, remplacez votre fonction getResponseData() par celle-ci : function getResponseData(url, body, func) local http = net.HTTPClient(); http:request(url, { options = { method = 'POST', headers = {['Content-Type'] = 'application/x-www-form-urlencoded;charset=UTF-8'}, data = body, checkCertificate = false }, success = function(response); func(json.decode(response.data)); end }) end J'ai mis mon sujet Netatmo Welcome à jour

Merci de cette réponse @Barelle! Cette fonction perdrait donc, d'après moi, une majeure partie de son utilité... Surtout qu'elle admet bien l'argument "pressButton" !

Effectivement, après vérification, j'ai une erreur similaire de mon côté également!

Dois-je en déduire que personne ne s'est déjà penché sur cette utilisation ?

Bonjour à tous, Dans le but de simplifier certains scripts, je me suis penché sur la fonction fibaro:callGroupAction(), dont il est possible d'en savoir un peu plus dans la documentation Fibaro: ICI. Seulement, toujours en train de chercher quelque chose de chiant à faire, j'aimerais utiliser cette fonction pour appuyer sur un bouton de plusieurs VD. Mes essais restent infructueux et mes recherches également. Quant-à la documentation, elle est loin d'être exhaustive, en plus de comporter quelques erreurs de syntaxes... Voici un code utilisé pour essayer d'appuyer sur le bouton 3 de deux de mes VDs : local data = { args = {1}, filters = { { filter="deviceID", value={89,112} } } } local a = fibaro:callGroupAction("pressButton", "3", data) for k,v in pairs(a) do print(v) end Ce qui me donne les messages suivants : Par contre, si je retire simplement l'argument "3", la fonction est executée et me retourne bien les IDs traités... Mais appuyer sur un bouton sans pour autant préciser lequel, ça ne sert pas à grand chose, bien évidemment! Avez-vous des idées, s'il-vous-plaît? Je vous souhaite un bon réveillon de Noël à tous!

Hello, De mon côté, en cas de gros plantage ou simplement si besoin de faire redémarrer la box (après une extinction ordonnée par le NAS), l'utilisation de la prise commandée fonctionne sans problème. Comme mentionné plus haut, il faut cependant attendre une bonne minute avant la coupure et le réarmement du secteur. À noter que je n'ai toujours pas fait la mise à jour en 4.510. Tu es sûr de ne pas t'être trompé et d'avoir branché une lampe sur cette prise commandée ?

J'ai fini par bidouiller ma scène pour qu'elle ne soit plus en autostart et qu'elle soit executée par les mouvements de mon domicile. Ainsi, je n'ai plus besoin d'interrompre un setTimeout, j'ai simplement ajouté une condition qui vérifie le nécessaire avant d'exécuter ou tuer la scène. Mais, si un jour, une personne passant par là a la solution à la question originale, ça pourrait être intéressant de nous en informer, merci

Pas du tout! En fait, c'est effectivement le plan B que j'ai en tête. À vrai dire, je pensais avoir une scène en autostart et une autre avec ma VG en trigger afin que chacune puisse arrêter l'autre en fonction de la situation. Dans un premier temps, je trouve cela dommage d'avoir deux scènes parfaitement similaires, à une condition près, mais si c'est la seule solution, je partirai pour ça! Ecoute, je n'en ai pas l'impression jusqu'à maintenant. Ou alors, chacune de mes vérifications était effectuée peu après la mise à jour! Je vais voir si je trouve des informations à ce sujet, puisque je ne pense pas qu'ils différencient les comptes développeur en fonction du produit acheté, cela me semble peu probable. Ça ne fonctionnera pas pour ce que je souhaite faire, puisque la prochaine vérification de la condition n'aura lieu que lors du prochain cycle du setTimeout(). Si le Mode absence est sur ON : La scène s'éxécute toutes les 20mn. Un mouvement est détecté. Mais la prochaine vérification de la valeur n'aura lieu qu'à la fin de ce délai de 20mn. Et je cherche à ce que le délai change dès la détection d'un nouveau mouvement

Je suis tout à fait d'accord avec toi. Si le script pouvait être exécuté toutes les 5 secondes, ça simplifierait grandement la problématique, bien que ça puisse charger quelques peu le CPU de la HC2 à mon avis. Malheureusement, l'API NetAtmo est bridée en nombre de requêtes par heure. Netatmo annonce un délai maximal de 2000 requêtes par heure pour chaque compte. Cependant, des tests ont démontré qu'il y avait souvent des problèmes au-dessus de 1000 requêtes par heure et le compte développeur NetAtmo était ensuite temporairement bloqué. La scène NetAtmo faisant deux appels API par cycle, il n'est pas possible de descendre en-dessous des 8 secondes, à condition de n'utiliser que l'API de la Welcome! C'est pourquoi je souhaite privilégier un petit taux de refresh lorsqu'il est nécessaire de reconnaître quelqu'un rapidement puis d'espacer ces vérifications ensuite, afin de ne surtout pas dépasser la limite imposée par NetAtmo

Ne sois pas désolé, c'est déjà super sympa de répondre à toutes mes interrogations qui doivent paraître sans fin! Merci de cette confirmation, ainsi que du code. Je pense comprendre un peu mieux le fonctionnement. Jusqu'alors, je pensais qu'on était capable de modifier uniquement une valeur spécifique. Dans cette situation, compte-tenu des réponses fournies à mes précédentes questions, je vais plutôt voir pour diviser les actions dans différentes VG en fonction des interactions des informations. Ça devrait d'ailleurs permettre un (minime) gain de temps de traitement si les tables sont moins complexes à parcourir :-) Avec toutes ces réponses, je devrais être capable de gagner un peu de temps sur certaines scènes et également, de comprendre certaines réactions que je n'étais pas capable d'expliquer auparavant! Un grand MERCI!

Je comprends la logique, mais j'ai mené la mienne sur un autre point de vue où c'est effectivement nécessaire. Je souhaite contrôler les délais de refresh de ma scène Netatmo : Si le mode absence est sur ON, refresh = 30mn Si mode absence récemment quitté et personne n'est identifié, refresh = 5s pendant 2mn (avant déclenchement alarme) Si quelqu'un est connu, refresh = 5mn Le refresh s'effectuant via setTimeout(), la scène doit obligatoirement être redémarrée pour que la nouvelle valeur de refresh soit prise en compte. Mon mode absence est géré par une VG et celle-ci se met automatiquement sur "ON" lorsque c'est nécessaire. Lorsque ce mode est quitté, ma scène gérant les pièces (trigger = mouvements) met simplement à jour cette VG avec le timestamp. Ainsi, si je mets la VG Absence en trigger, je dois pouvoir vérifier le contenu de celle-ci avant de redémarrer la scène, puisque sinon, la scène s'exécutera à chaque nouveau mouvement. Le but étant d'optimiser l'utilisation de la NetAtmo en fonction du nombre maximum de requêtes autorisées sur l'API. Le fait que la scène tourne toutes les 10s lorsqu'il y a personne au domicile n'a aucun intérêt. Par contre, lorsqu'une "intrusion" est détectée, il est plus important de remonter très régulièrement les informations de l'API pour une meilleure réactivité de la domotique.

Bonjour, Aujourd'hui, je me demande s'il existe une possibilité de tuer les autres instances d'une scène à certaines conditions. Il est effectivement possible de tuer les autres instances d'une scène automatiquement grâce à l'utilisation de %% killOtherInstances dans l'en-tête d'une scène. Seulement, j'aimerais pouvoir tuer les autres instances d'une scène si certaines conditions sont vérifiées. J'ai bien connaissance des fonctions fibaro:countScenes() et fibaro:killScene(), mais elles n'ont pas grand intérêt dans l'utilisation recherchée, puisque la seconde fonction tuera toutes les instances de la scène, y compris celle en cours. Si ce n'est vraiment pas possible, je pourrai bien évidemment me débrouiller en utilisant deux scènes différentes et les fonctions citées ci-dessus, mais si une fonction existait, ce serait top! Merci!

À la lecture de ce message, je crois comprendre que LUA peut être associé à d'autres Base de Données, encore fallait-il le savoir Je ne fais pas le procès du LUA, j'annonce simplement un ressenti par rapport à ce que j'ai pu constater auparavant. À l'époque, les scripts PHP étaient hébergés sur un serveur dédié de chez OVH, qui ne tournaient certainement pas avec un Atom, c'est certain. Je vais voir à cela, merci Je l'ai fait à distance, je ne vois pas de changement à l'heure actuelle (sur le graphisme de réseau Z-Wave). Idem. Mais c'est une tuerie !! On avait vu qu'une vérification des valeurs du tableau de VG était automatiquement effectuée par la HC2 avant de l'écrire (afin de ne pas la modifier inutilement si la valeur est la même), ce qui pourrait expliquer ce délai. Après, il faut effectivement réfléchir à l'intérêt d'enregistrer une valeur en DB afin d'optimiser le temps d'exécution.

Une nouvelle fois merci. Je ne pensais vraiment pas que LUA effectuait une recherche pour chaque sous-tableau. J'étais persuadé qu'il accédait directement à la valeur dont on spécifiait la clé et qu'il affichait une erreur si la clé n'était pas correcte. Qu'en est-il lorsqu'on réencode une seule clé d'un tableau? Par exemple, admettons que le tableau ci-dessus soit encodé est stocké dans une Variable Globale. On souhaite changer la valeur d'un de ses sous-tableaux : t = json.decode(fibaro:getGlobalValue("MA_VG")); t["EXEMPLE"].Suite.n.v = "carrément"; fibaro:setGlobal("MA_VG", json.encode(t)); Le tableau est donc entièrement relu et est ensuite ré-encodé avec seulement le changement de cette valeur, c'est cela? Ce qui signifierait que, si deux scènes cherchaient à mettre à jour au sein du même tableau, la valeur d'une clé différente et ce, simultanément, le résultat pourrait être aléatoire. J'ai à peu près pigé le principe ?

Désolé, mais plus maintenant que tu m'as donné la solution! Merci beaucoup !

Oups, une dernière question me vient à l'esprit... Dans l'utilisation d'un tableau json, sais-tu s'il met plus du temps à accéder à une valeur contenue dans une clé, qui est contenue dans une clé, qui elle-même est contenue dans une clé etc. etc., par rapport à une valeur accessible "directement" ? Je préfère toujours illustrer avec un petit exemple : t : {}; t["EXEMPLE"] = { Etat = 1, Bla = {A=1,B=2,C=3,D=4}, Suite = { k="on",l="ne",m="s'arrête",n={v="vraiment",w="plus"}} } Sera-t'il plus rapide d'accéder à t["EXEMPLE"].Etat plutôt qu'à t["EXEMPLE"].Suite.n.v ? Promis, après j'arrête d'abuser!

J'ai appris cela depuis peu et je suis actuellement en train de chercher à diminuer les vérifications non nécessaires dans mes scripts afin de gagner en temps d'exécution. Ça, c'est indéniable. J'ai dû créé plusieurs VD simplement pour afficher et gérer certaines valeurs de mon tableau sans avoir à éditer une scène... Et je suis une fois de plus d'accord avec toi. J'essaie de me faire violence pour commenter au maximum les scènes, mais il est évident que quiconque le relira aura surtout besoin de manger le code pour le comprendre... Oui et je te remercie infiniment du temps accordé pour chacune de tes réponses!

Quelle réactivité! Pour tout avouer, je n'ai jamais réussi à pouvoir lire les fichiers directement en local... J'ai passé 2-3 heures à faire des essais et ça m'a un peu saoulé je l'avoue, donc j'ai mis le lien de mon site web HTTP et ça a fonctionné directement. Mais avec au moins 20-25 secondes de latence! J'ai pourtant essayé en créant un compte Invité qui avait accès au dossier web/, mais non, quand ça veut pas, ça ne veut pas! Je me suis donc dit que mettre en cache les quelques mp3 pouvait être une solution Pour information, mon fichier est accessible sur le web à l'adresse http://www.domaine.fr/intrusion/Qui.mp3 Et, sur mon NAS, ils sont stockés dans le dossier /web/intrusion Pour le lire depuis Firefox, je dois accéder à cet URL : file:///web/intrusion/Qui.mp3 Il s'agit simplement d'un enregistrement de ma voix qui demande "C'est qui ?", lorsqu'il n'y avait personne chez moi auparavant...

J'avais quand même souvenir de gros codes PHP de plusieurs centaines de lignes, avec un paquet de vérifications et de boucles, qui s'exécutaient en quelques millisecondes, là où j'ai un peu l'impression qu'une grosse boucle ralentit considérablement l'exécution d'un script complet. Mais, c'était il y a plus de 10 ans encore une fois, et les accès à la base de données étaient sans doute plus rapides. C'est vrai que ça commence à bien dater, même s'il avait révolutionné le petit monde des CPU à sa sortie. J'ai encore un MSI Wind U100 qui traîne dans un tiroir d'ailleurs! Mais ça reste considérablement mieux que ce qu'il y a sur les Raspberry je présume?! Je suis en train de reprendre la programmation de mes scènes principales en essayant de supprimer au maximum les vérifications. J'ai déjà bien avancé, ce week-end sans bosser aura eu ce bénéfice! Et je dois avouer que je sens déjà l'allumage plus réactif dans l'ensemble et c'est plutôt agréable d'ailleurs. Mais cet allumage peut effectivement être plus long pour les capteurs les plus loins de la HC2, notamment lorsqu'il y a un gros mur à traverser. Je vais donc voir s'il existe une méthode pour faire un "reset" du maillage afin que chaque module puisse recalculer la route la plus rapide pour lui, bien qu'ils doivent tous être capables de communiquer directement avec la HC2 d'après-moi. Je vais d'ailleurs voir si je peux connaître l'état de connexion de chaque module à la HC2 Merci de cette suggestion @Lazer!

Bonjour à tous, J'ai parcouru quasiment toutes les réponses de ce post pour trouver une éventuelle réponse à ma question, mais il semble que non. J'utilise la fonction de streaming de fichier mp3, cela fonctionne parfaitement, mais je regrette cependant un certain délai. J'ai pu voir qu'il était possible de mettre en cache le ou les fichier(s) en question afin de pouvoir les lire quasiment instantanément. J'ai un NAS Synology et j'aimerais mettre cela en place, mais je ne vois pas comment. Est-il possible de me mettre sur la voie svp? Merci d'avance

Nous sommes donc d'accords que si on veut supprimer au maximum la latence, il faut également faire l'impasse sur le côté smart home. Il faut donc optimiser au maximum les scripts pour trouver un juste milieu Effectivement, je n'ai pas été assez clair dans mon exemple, je pensais à un interrupteur Z-Wave, donc sans le moindre câble Il est vrai que ça a plus de sens lorsqu'un détecteur allume une lumière, mais c'est effectivement bête et méchant. Il existe des déjà des appareils qui font ça parfaitement, pour des sommes très abordables, du moins bien moins que le coût des modules en domotique. Je ne me vexe pas Ce n'est pas tant que ça une usine à gaz, une architecture est respectée et le fonctionnement est très fiable, je ne déplore pas la moindre panne, si ce n'est une certaine lenteur quelques fois. Mais je pense dans un premier temps que reprogrammer la chose en évitant le décodage/encodage json réguliers aidera à gagner en performance. À une époque désormais lointaine (+ de 10ans), je programmais beaucoup en PHP et j'ai découvert le LUA il y a plus d'un an sur ce forum. Mes posts démontrent d'ailleurs l'évolution de mon apprentissage, puisque mes premiers étaient vraiment ceux d'un néophyte! Toujours est-il que je me rends maintenant compte que le LUA s'éxécute moins rapidement que le PHP, il suffit simplement de s'y habituer et apprendre à le contrer Je précise quand même que dans 85% des cas, lorsque le trigger est une caméra, la lumière s'allume en moins d'une demie seconde lorsqu'elle s'allume en un peu moins d'une seconde lorsque celui-ci est un FGMS. Mais, sans que je puisse l'expliquer, lorsqu'il n'y a pas eu de mouvements depuis un certain temps, c'est plus long pour procéder au premier allumage de la lumière de chaque pièce, là où les délais réduisent considérablement la fois suivante. C'est pour cela que je disais que ça donnait l'impression que la HC2 avait besoin de se remettre en jambe, puisqu'elle est peu sollicitée puis d'un seul coup, des scènes se manifestent?... Bref, c'est assez étrange, mais il n'y a rien très grave au final

En fait, j'essaie de généraliser mon cas afin qu'il puisse éventuellement servir à d'autres personnes, c'est pour cela que ça peut vite devenir sans queue ni tête D'ailleurs, une autre question me vient en tête, même si je pense connaître la réponse. Lorsque des données doivent être accessibles rapidement, je suppose qu'il est préférable de favoriser le stockage de celle-ci dans une VG qui lui est dédiée, plutôt que dans un gros tableau encodé en json? En fait, à partir du moment où j'ai commencé à maîtriser les tableaux, j'ai reprogrammé toutes mes scènes pour qu'elles exploitent le tableau contenu dans une seule VG, ce qui donne un bon gros tableau. Mais, finalement, pour des informations qui sont à la fois souvent modifiées, mais aussi souvent traitées, comme le dernier mouvement détecté dans une pièce à tout hasard, n'est-il pas préférable d'avoir une VG seulement pour cette information plutôt que le décodage d'un json + Accès en table pieces["NOMPIECE"].LastMove pour parler de mon cas?

Bon, la différence de temps d'accès est donc effectivement dérisoire, merci de cette précision! Ah oui, merci! Je n'avais pas fait attention que tu avais fait appel à fibaro:getGlobal, j'utilise toujours directement les fonctions appelant la valeur et le timestamp de modification. En tous cas, merci de ces éclaircissements et du temps accordé pour répondre à mes questions plus ou moins tordues!