MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 (modifié) Je ne suis pas certain de te suivre sur ta notion de design monolithique. C'est bien mon idée, c'est bien d'avoir dans le même VD l'ensemble du code qui le concerne Mais ce qui m'inquiète c'est la fréquence d'exécution du main loop versus la rapidité d'appui sur les boutons, au risque de louper certains appuis. Modifié le 5 janvier 2018 par MAM78
Lazer Posté(e) le 5 janvier 2018 Auteur Signaler Posté(e) le 5 janvier 2018 Il n'y a pas forcément du bonne façon de faire. Ce que je voulais dire, c'est que j'aime bien que la main loop soit 100% autonome. Par contre pour les boutons, répéter N fois le même code oblige à copier/coller N fois la même chose, ce qui n'est pas judicieux (rébarbatif à développer, consomme de la place dans la DB pour rien, allonge le retour JSON lors de l'appel à l'API, complique la maintenance, etc). Donc là je préfère maintenant mettre le code dans une scène, laquelle est appelée par tous les boutons, avec les paramètres passés en argument. Mais rien n'empêche de faire de même depuis la main loop, sauf que je n'ai pas testé. En terme de performance, c'est un sujet complexe, mais ce qui est certain, c'est que la main loop autonome est le plus performant, car pas besoin de faire d'appel de fonctions externes. Et c'est même pire que ça, car l'appel à une scène est déjà une fonction startscene(), laquelle initie une communication IPC inter-processus au niveau de Linux. Autant dire que ça peut devenir gourmand si tu as plein de VD avec chacun leur main loop qui font un appel à une scène toutes les 3 secondes. Mais encore une fois, je ne saurais pas dire quelle est la meilleure façon de faire, c'est juste ma vision des choses.
MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 C'est bien ce que je pensais, nous nous sommes pas compris, mon idée est que le main loop contiendrait l'ensemble du code qui est répété actuellement dans les boutons et sans le déporter dans une scène.
Lazer Posté(e) le 5 janvier 2018 Auteur Signaler Posté(e) le 5 janvier 2018 OK c'est clair. Mais dans ce cas, tu aurais un problème, la main loop a son sleep() de 3 secondes minimum, ce qui aboutie à une mauvaise réactivité. Je crois que c'est comme cela que fonctionnait le VD Sonos de Krikroff. Perso je veux éviter cette latence. A moins que tu aies une solution pour cela ? La scène, elle, n'a pas cette latence de 3s, elle s'exécute quasi instantanément après l'avoir appelé, c'est pour cela que j'ai fait ce choix dans mon prochain VD.
MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 Il y a 1 heure, MAM78 a dit : Mais ce qui m'inquiète c'est la fréquence d'exécution du main loop versus la rapidité d'appui sur les boutons, au risque de louper certains appuis. C'était effectivement ma question (ci-dessus), j'ai maintenant ma réponse Mais est-ce toutes les 3 secondes ou 1 seconde, comme indiqué sur les VD : In main loop you can enter LUA code to be executed each second Ce qui je te l'accord ne règle pas le fond du problème que tu exposes
Lazer Posté(e) le 5 janvier 2018 Auteur Signaler Posté(e) le 5 janvier 2018 OK donc maintenant j'ai bien compris ta question initiale. C'est bien 3s, c'est codé en dur dans le binaire exécutable : while true do fibaro:sleep(3000); Il y a donc bien un risque de louper des appuis de boutons, à cause de ce problème de latence. Bref, je préfère appeler une scène externe Disons que la scène externe peut être vue comme une sorte de librairie, tandis que les vraies librairies ne sont malheureusement pas possible sur la HC2 à cause du LUA bridé par Fibaro.
MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 Dommage, s'aurait été bien d'avoir tout le code relatif au VD dans le VD et non en partie distribué dans une scène
Lazer Posté(e) le 5 janvier 2018 Auteur Signaler Posté(e) le 5 janvier 2018 Oui tout à fait. Après tu peux toujours mettre la scène en variable dans la main loop, et au premier démarrage du VD créer la scène si celle-ci n'existe pas déjà, mais ça devient un peu lourd... et tu risques d'atteindre la taille maxi de la main loop car elle devra contenir son propre code ainsi que celui de la scène. Il n'y a pas de solution parfaite.
MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 Non effectivement, trop lourd. En plus faudrait la supprimer la scène dès lors que le code évoluerait. Dans ta solution avec l'utilisation d'une scène : Lorsque tu livre une nouvelle version de ton VD, ceux qui rechargeront ton VD devront désigner (modifier) le n° de scène dans chacun des boutons ? Est-ce que tu aurais trouver une solution pour contourner cette manipulation ?
Lazer Posté(e) le 5 janvier 2018 Auteur Signaler Posté(e) le 5 janvier 2018 Dans mes VD récents, les paramètres ne sont positionnés qu'à 2 endroits : - onglet propriétés avancées : IP et port - main-loop Donc rien dans les boutons, la Mian loop se chargeant de transmettre les infos aux boutons via une VG auto-crée. En ce qui concerne la scène, je vais éviter de devoir renseigner son ID dans la main loop. Elle devra juste avoir un nom imposé. De toute façon elle sera cachée, donc l'utilisateur s'en moque, ça n'apparait pas dans l'affichage de la page Web standard. Au premier chargement de la main loop, elle ira trouver la bonne scène toute seule. Pour gérer les versions, je ne sais pas encore, je pense que la main loop ira lire l'entête de la scène à la recherche du numéro de version, mais je n'ai pas encore testé cela. Sachant que les variable ont une taille maxi, si la scène est trop grosse, alors la main loop ne pourra pas charger la scène en mémoire. Donc à tester.
MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 Que veux-tu dire par ? il y a 5 minutes, Lazer a dit : si la scène est trop grosse, alors la main loop ne pourra pas charger la scène en mémoire.
Lazer Posté(e) le 5 janvier 2018 Auteur Signaler Posté(e) le 5 janvier 2018 Quand tu charges l'API des Scènes et que tu décodes le JSON, à cause du nombre de caractères dans la scène elle-même, j'ai peur de dépasser la taille maximum d'une variable. Cf ce topic : Mais en fait, juste avant de valider mon message, je viens de penser que le chargement de scène, c'est ce que je fais dans mon watchdog, juste avant d'ajouter un saut de ligne et de réencoder le JSON, et je n'ai jamais rencontré le moindre souci, même avec les grosses scènes comme GEA. Donc ce problème ne devrait pas se poser, hop problème résolu
MAM78 Posté(e) le 5 janvier 2018 Signaler Posté(e) le 5 janvier 2018 En fait ce que je ne comprends pas c'est : il y a 16 minutes, Lazer a dit : charger la scène en mémoire Tu veux dire qu'il y a une différence entre lancer (fibaro:startScene) une scène et un chargement en mémoire d'une scène ? Si oui, quelle est le différence ?
Lazer Posté(e) le 6 janvier 2018 Auteur Signaler Posté(e) le 6 janvier 2018 En fait, quand je dis "charger" une scène, c'est simplement accéder à /api/scenes/ID, puis décoder le JSON. Donc tout cela se passe dans une variable de la main loop du VD qui va "charger" la scène. J'ai besoin de ce "chargement" pour 2 raisons : - parcourir toutes les scènes pour trouver le nom qui correspond à celui attendu, et en déduire l'ID de la scène (ce qui évite à l'utilisateur de devoir spécifier manuellement l'ID de la scène dans le code LUA du VD, cf discussion d'hier) - analyser le code à la recherche du numéro de version de la scène, afin de mettre en garder si la version du VD ne correspond par à la version de la scène. Donc il n'y a aucune exécution de la scène à ce moment là, il ne faut pas le comparer à un startScene()
MAM78 Posté(e) le 6 janvier 2018 Signaler Posté(e) le 6 janvier 2018 Ok, j'ai capté. Ok pas d'exécution mais lecture du code de la scène
Messages recommandés