MAM78 Posté(e) le 17 mars 2017 Auteur Signaler Posté(e) le 17 mars 2017 Après quelques temps, je me suis rendu compte d'une certaine limite à l'usage que cette solution, notamment lorsque l'on veut la solliciter la scène de façon intensive. En effet lorsqu'il y a un grand nombre d'appels de la scène créée dans un laps de temps très court, comme par exemple inférieur à la seconde (ou plus si, la scène effectue un grand nombre de traitements qui durent un certain temps), vous aurez un violant plantage de la Scène ou du VD qui sollicite la scène créée/appelée. Cela arrive dès lors que l'on dépasse le paramètrage du nombre maximum d'exécutions simultanées (Max. running instances) de la scène créée. Sachant que le maximum est limité à 10 instances simultanées. Donc avant de se lancer dans la création d'une scène comme un équivalent d'une fonction, il convient de se poser la question, combien de fois cette scène peut être appelée en parallèle.
Steven Posté(e) le 20 mars 2017 Signaler Posté(e) le 20 mars 2017 Maintenant, si on reste réaliste, on parle de domotique ... je vois mal quelqu'un s'amuser à allumer/éteindre une lampe plus de 2 fois par secondes En ce qui concerne le nombre d'appel en parallèle, même combat, si on doit appeler une scène plus de 10x en simultané, je pense qu'il y a un soucis de conception et non pas de limitation.
MAM78 Posté(e) le 20 mars 2017 Auteur Signaler Posté(e) le 20 mars 2017 Cela peut arriver par exemple, lorsque plusieurs détecteurs se déclencheraient en quasi-simultanés et pour lesquels la même scène serait sollicitée. Je te l'accorde cela correspond à des cas exceptionnels. Dans ce cas il convient de bien positionner le paramètre (Max. running instances). Mais le cas auquel je pense est surtout celui ou l'on utiliserait une scène qui consoliderait la gestion des traces dans une log centralisée et/ou l'envoi de messages (mail, SMS, Push, TTS) et là la probabilité d'avoir des exécutions simultanées peut être beaucoup plus importante. Pourquoi parler de problèmes de conception , il y a tout bonnement une limitation à 10 instances. D'où ma mise en garde puisqu'il y a un risque que certains lancements de la scène d'aboutissent pas. Il y a bien évidement la possibilité de contrôler le nombre d'instances de la scène et de faire une boucle d'attente (sleep) dans les scènes/vd appelants celle-ci, mais cela alourdirait leur code. CQFD 1
Steven Posté(e) le 20 mars 2017 Signaler Posté(e) le 20 mars 2017 Si tu as trop de requêtes qui partent en même temps, c'est pour moi un soucis de conception. Il suffit de bufferiser les infos et de les envoyer de temps en temps. Surchargé un réseau n'est jamais la solution. Pour la gestion des traces, personnellement, je ne connais aucun système qui n'utilise pas la bufferisation .. .même Windows le fait . Et je ne vois pas pourquoi on enverrais un plus d'un email/push/tts, ... par secondes ... c'est du spam mais ce n'est pas le débat. Perso, je pense que 10 appels simultanés .. c'est déjà énorme ... ou alors c'est que le traitement effectué par le scénario est trop long et n'est pas capable de ce terminer suffisamment tôt pour libérer les instances. Ce que tu essaie de mettre en place avec les logs ... n'est pas du domaine de la domotique mais de l'informatique. Ce besoin de connaître les logs n'intéresse réellement que les informaticiens et non pas les utilisateurs. Donc oui, tu as raison, il y a des limitations mais ces limitations sont là pour protéger un utilisateur qui aurait un mauvais code (boucle sans fin, trigger avec ID inutile, ...) .. ces limitations ont été volontairement ajoutés il y a pas si longtemps que cela. Et sérieusement, c'est un très bon garde fou pour éviter les soucis. Bref, ce que je veux dire par la est : "Tu mets en garde les utilisateurs que le système à ses limites et qu'il doivent faire attention à cela" et moi je dis "Si vous arriver aux limites c'est que vous devez sûrement revoir quelque chose". On parle donc de la même chose mais différemment. En aucun cas je ne remets en question ce que tu as réalisé (logs, ...) c'est juste un autre regarde sur ces fameuses limitations dont tu parles. P.S: Le sleep n'est plus le moyen a utiliser, il y a le setTimeout() qui ne consomme rien. P.S2 : Cela doit être la première fois que j'écris un message qui dit que Fibaro a fait un truc de bien blame on me. 3
MAM78 Posté(e) le 20 mars 2017 Auteur Signaler Posté(e) le 20 mars 2017 Tu peux développer ton idée de bufferisation. Dans quel registre mémoire tu vois ça et selon quel type de procédures/fonctions. Tu admettras que l'écart entre le domaine de la domotique et de l'informatique est tenu. Une boxe domotique, n'est plus ni moins qu'un ordinateur, avec un système d'exploitation et une couche applicative, basé le tout sur un OS couramment utilisé dans le monde de l'informatique. Pourquoi séparer les deux mondes si j'ai choisi d'acheter une Fibaro HC2 c'est bien pour pouvoir avoir accès au code et pouvoir développer ses propres fonctionnalités, sinon j'aurais acheté une boxe fermée comme un simple utilisateur Je n'ai pas de débat sur des limitations quelconques fixé par Fibaro. C'est leur droit, je ne critique pas (sauf sur l'indisponibilité de la fonction Net.F???? dans le scènes ) mais le propre de ce Forum il me semble, c'est de pouvoir échanger notamment (pas uniquement) sur ces limites et voir s'il est possible de les contourner sans pour autant se voir discrédité sur des logiques de conception. J'ai une expérience toute relative en informatique et je suis très loin de votre expérience/compétence (dont j'ai besoin pour progresser) en particulier sur cette boxe. C'est donc sans aucune prétention, que depuis moins de 2 mois que je participe activement au forum et que je partage mes expériences (déjà 7 Tutos en ligne et probablement d'autres à venir). Qui dit mieux ? Pour rappel, mon présent Tuto a pour objectif de partager avec vous l'utilisation de la fonction figaro:args() et en quoi elle nous permet notamment de simplifier la maintenance de nos codes en diminuant leur redondances dans nos VD/Scènes. D'ou l'idée d'utiliser cette fonction comme un moyen de créer ses propres fonctions avec passage de paramètres.
Steven Posté(e) le 20 mars 2017 Signaler Posté(e) le 20 mars 2017 Je ne peux pas développer l'idée de la bufferisation car je n'y ai jamais pensé et je n'en n'ai pas besoin. A vu d'oeil, sur la HC2, il n'y a que le coupe JSON/variable globales de disponible et c'est pas top. Heuuuu, prendre une HC2 pour pouvoir avoir accès au code me semble un choix étrange vu que cela reste une box fermée comme toutes les autres. Jeedom me semble plus ouvert et ton Synology encore plus. Moi j'ai l'excuse que Jeedom n'existait pas et que je suis un flemmard qui veux un truc qui fonctionne sans avoir besoin de mettre les mains dedans. La différence entre une box domotique et un PC est justement que la box est "fermée", "bridée" pour que l'utilisateur ne puisse faire que ce qu'on lui propose. Cela non pas de le but de l'embêter mais d'éviter les erreurs de manipulations. il y a 9 minutes, MAM78 a dit : sans pour autant se voir discrédité sur des logiques de conception Apparemment, j'ai mer*dé vu que tu as l'impression que j'ai discrédité quelque chose. Ce que j'ai juste voulu dire est que si on atteint une limite c'est souvent que le moyen pour y arrivé qui n'est pas le bon. il y a 13 minutes, MAM78 a dit : Qui dit mieux ? Je pourrais te citer quelques utilisateurs qui ont aussi ce mérite mais je suis 100% d'accord avec toi et c'est grâce à des gens comme toi que ce forum est l'un des plus utile et actif sur le sujet (voir le plus utile ET le plus actif). il y a 24 minutes, MAM78 a dit : Pour rappel, mon présent Tuto a pour objectif de partager avec vous l'utilisation de la fonction figaro:args() Ça, je crois que je suis au courant ... j'ai assez perdu de temps à savoir à quoi elle servait cette fonction et je trouve que d'en discuter est très utile. Tu as juste mis en post en disant "attention aux limitations" alors je me suis permis de réponde (apparemment maladroitement). Donc, excuse moi encore d'avoir donné mon avis sur les soucis de limitation de cette fonction en ayant utilisé les mauvais mots ("soucis de conception"). Mais je ne te promets pas de ne plus le faire car je suis naturellement maladroit 1
MAM78 Posté(e) le 20 mars 2017 Auteur Signaler Posté(e) le 20 mars 2017 Je confirme sujet du couple JSON/variables globales c'est pas top, notamment dans les cas d'accès simultanés à partir de VD/Scènes à une variable globale. Peut-être que je me suis trompé sur le choix de la boxe par rapport à Jeedom, mais j'ai eu une préférence sur l'interface utilisateur de la Fibaro qui est à mon gout plus WAF. Dommage que les plugins ne soient pas plus développés sur les HCx. La communauté côté Jeedon semble bien plus active de ce côté. L'avenir me dira si je me suis trompé Ok pas de PB, maintenant que je connais ta maladresse, je prendrais plus de recul 1
DonQuischopp Posté(e) le 14 avril 2017 Signaler Posté(e) le 14 avril 2017 Bonsoir J'ai une question, si je passe des lettres spéciales dans fibaro:args() comme "ä,ö,ü" dans la scene c'est pas écrit correct, il tourne comme ö ou autre chose. Avez-vous une idée comment je peu le faire marcher? Merci et salutations Don
Indyana Posté(e) le 18 avril 2017 Signaler Posté(e) le 18 avril 2017 Bonjour, J'ai le même problème que Donqui, comment avez vous résolu ce soucis svp? En passant les codes html?
DonQuischopp Posté(e) le 19 avril 2017 Signaler Posté(e) le 19 avril 2017 Pour le moment je transfère des messages pour TTS en Sonos. Pour cela je met une variable globale (seulement pour la message, les autre paramètres je laisse dans les paramètres pour la scène). Après dans la scène et reprends la variable dans l'autre scène. Je sais que ce n'est pas la bonne solution, mais ca marche pour maintenant.
MAM78 Posté(e) le 16 juillet 2017 Auteur Signaler Posté(e) le 16 juillet 2017 Le 24/2/2017 à 23:58, Krikroff a dit : Alors: oui, oui, oui la variable globale devient inutile, carrément, oui, asap Hello @Krikroff je viens de me rendre compte que je t'avais déjà posé la même question ci-dessus et tu m'avais répondu. Quand est-il tu as fais évolué ton Notification Center afin d'utiliser la fonction figaro:args() ? Je souhaite y intégrer d'autres fonctions de notification (TTS Sonos, Push avec popup, ...) mais je ne voudrais pas refaire ce que tu aurais déjà fais
Gazous Posté(e) le 20 juillet 2017 Signaler Posté(e) le 20 juillet 2017 Hello, je suis en train d'essayer d'utiliser ce passage de paramètres dans une scène appelée depuis l'extérieur via un script PHP. J'arrives bien à exécuter la scène mis je m'arrache les cheveux sur les arguments ! Je fais bien un POST avec le tableau JSON et la clé "args" mais à chaque fois dans la scène, fibaro:args() me renvoi nil. Quelqu'un a déjà testé ça ?
Gazous Posté(e) le 20 juillet 2017 Signaler Posté(e) le 20 juillet 2017 Bon j'ai fini par trouver et le format du JSON à passer en POST est : {"args":[{"prenom":"Toto"}, {"nom":"Titi"}]} 4
pepite Posté(e) le 20 juillet 2017 Signaler Posté(e) le 20 juillet 2017 Well done@gazous Envoyé de mon Nexus 5X en utilisant Tapatalk
Gazous Posté(e) le 21 juillet 2017 Signaler Posté(e) le 21 juillet 2017 Je suis content car grâce à cela, j'ai par implémenter les Callbacks de ma serrure Nuki ! Je suis contraint de passer par un intermédiaire (serveur Web Apache + PHP) qui récupère la callback et reformatte les données pour qu'elles entrent dans le format qui convient à la scène Figaro. Ca marche super et cela m'ouvre de nouvelles possibilités d'automatisations sur événements de serrures, Cool !
pepite Posté(e) le 21 juillet 2017 Signaler Posté(e) le 21 juillet 2017 Super. Si tu as le temps, tu peux partager. C'est sur que ça ouvre encore plus avec un intermédiaire php :-) Envoyé de mon Nexus 5X en utilisant Tapatalk
Gazous Posté(e) le 21 juillet 2017 Signaler Posté(e) le 21 juillet 2017 Alors pour le tuto, je ne garanti rien car déjà que j'ai eu du mal à trouver le temps pour ça...
Steven Posté(e) le 21 juillet 2017 Signaler Posté(e) le 21 juillet 2017 Embête toi pas avec un tuto, colle juste 2, 3 lignes de code et basta ... cela pourra déjà aider pas mal de gens, du moins aiguiller. Merci encore
Gazous Posté(e) le 22 juillet 2017 Signaler Posté(e) le 22 juillet 2017 Oui tu as raison, je vais tâcher de coller quelques lignes une fois que tout sera au propre. Je cherche justement à améliorer un truc dans mon code. Existe-t-il un moyen permettant d'exécuter une fonction en lua à partir de son nom récupéré dans une string ? Genre je récupère functionName = "toto" et plutôt que de faire if functionName == "toto" then toto() end je me disais qu'il ya avait peut-être plus élégant ?
Lazer Posté(e) le 22 juillet 2017 Signaler Posté(e) le 22 juillet 2017 Oui @Steven avait donné l'astuce ici, avec un tableau de fonctions : https://www.domotique-fibaro.fr/topic/5505-nodon-télécommande-murale-z-wave/#comment-92774
Gazous Posté(e) le 22 juillet 2017 Signaler Posté(e) le 22 juillet 2017 Merci @Lazer c'est pas mal comme astuce mais dans mon cas ça n'apporte pas beaucoup. Ceci dans dans certains cas c'est une très bonne astuce !
Lazer Posté(e) le 22 juillet 2017 Signaler Posté(e) le 22 juillet 2017 Il me semblait que ça répondait exactement à ton besoin, je n'ai pas compris ce que tu voulais faire alors
Steven Posté(e) le 22 juillet 2017 Signaler Posté(e) le 22 juillet 2017 il y existe dans d'autre langage la fonction evaluate() mais pas en LUA. Je fais ainsi comme décrit par @Lazer local f = { toto = function() print("Je suis toto") end, tata = function() print("Et moi sa soeur") end } f["tata"]()
Messages recommandés