Lazer

Bienvenue sur le forum

Il est très facile de convertir une scène HC2 vers une fonction dans un QuickApp HC3, la logique du code asynchrone est la même, les fonctions http:request() sont les mêmes, etc. La récupération d'argument est encore plus simple puisqu'on les spécifie directement dans la définition de la fonction. La possibilité d'organiser son code en différents "fichiers" est aussi un énorme plus, pour se faire des librairies de fonction, ou comme dans le cas de GEA for HC3, de séparer le code utilisateur (n'est ce pas @971jmd ). Ca facilite la compréhension, et ultérieurement les mises à jours, puisqu'il suffira de copier/coller le nouveau code LUA du code principal (main) sans toucher au code utilisateur. Il n'y a que les triggers qui manquent dans les QuickApps, comme pour GEA, où j'ai dû utiliser l'API refreshStates à la place, dans une boucle. On verra à l'usage, mais ça semble bien fonctionner. A vrai dire, sur HC3 il n'y a pas vraiment de limitation... ou disons plus plutôt que les limitations qu'on a connu sur HC2 sont levées. Au fait, dans le futur Fibaro ajoutera l'import et la mise à jour automatique de QuickApps depuis le market (comme sur les solutions concurrentes....), donc l'avenir est vraiment aux QuickApps chez Fibaro. Bref, désolé du semi-HS sur ce topic dédié Support GEA, j'avais justement ouvert un topic à coté pour discuter des développements à faire pour "convertir" nos VD+Scènes HC2 en QuickApps HC3.

@971jmd non désolé ce n'est pas la bonne méthode, ni sur HC3, ni sur HC2 d'ailleurs Il ne faut pas toucher au code de GEA Ton option personnalisée doit être dans config() comme expliqué dans mon message précédent Par ailleurs ton numéro de ligne ne sert à rien, à partir du moment où tu as modifié le code de GEA, impossible de comprendre/reproduire chez moi. Commence donc par remettre ta config au propre, tu ne modifies que le fichier config du QuickApp comme expliqué dans le tuto, dans les fonctions config() et setEvents() De toute façon, il faut que tu commences par convertir ta scène dans un QuickApp distinct, qu'on pourra appeler par sa fonction, comme je le disais là aussi dans mon message précédent. @pepite : merci

@pepite Je pensais mettre à jour le fichier Syntaxe, mais si tu es motivé, je te laisse faire Normalement GEA.options est toujours OK : à configurer dans le fonction config() comme avant. Cependant je ne l'ai pas testé... si tu as un exemple concret d'option personnalisée à me donner, je le testerai. Là où ça se complique réellement, c'est que fibaro:args() n'existe pas sur HC3, et globalement tout ce qui touche aux scènes. Clairement, les scènes sur HC3 n'ont aucun intérêt, à part pour faire 2 ou 3 clics en mode bloc. Même quand on écris une scène en LUA, il est impossible de lui passer des arguments (ou alors je n'ai pas trouvé.... et ce n'est pas documenté). Pour moi cette fonctionnalité n'existe plus. Donc pour tout ce qui est écriture de code LUA, il faut utiliser les QuickApps et abandonner les scènes. C'est mon avis. En QuickApp, au contraire, ça devient très simple. Il suffit d'écrire la fonction de son choix, avec tous les arguments nécessaires. Sachant qu'on peut appeler n'importe quelle fonction publique d'un QA depuis un autre QA, c'est juste parfait. fibaro.call(ID_du_QA, "nom_de_la_fonction", argument1, argument2, ...) @971jmd Ton bloc telegram = {name="Telegram", ... tu le positionnes où dans ton code ? Là je ne vois pas. Comme je viens de dire à @pepite, normalement il est censé être dans la fonction options() Et donc il devrait commencer par GEA.options.telegram = {...} sinon je ne vois pas comment il pourrait le prendre en compte. J'espère juste que tu ne modifies pas directement le code de GEA, il ne faut surtout pas, sinon tu ne pourras plus installer les mises à jours. J'ai justement séparé exprès le code GEA du code utilisateur dans 2 fichiers distincts. Concernant ta scène, en vertu de ce que j'ai répondu à @pepite tu comprends bien que ce n'est plus possible. Il te suffit donc de mettre ton code LUA dans une fonction d'un QuickApp, puis il suffit d'appeler cette fonction depuis GEA. Pour simplifier, dans ton option telegram, au lieu d'appeler fibaro:startScene(), tu utiliseras fibaro.call() PS : vu que tu me présentes directement un cas compliqué, quelque part ça me rassure, ça veut dire que toutes les règles usuelles ont fonctionné du premier coup chez toi ?

Voici une première version beta de GEA pour HC3 : On conserve ce topic-ci pour le support sur la syntaxe et l'écriture des règles GEA.add(...)

Et voilà, amusez-vous bien

QuickApp "GEA Alarm" lié à GEA Ce QuickApp Alarme pour HC3 remplace les modules virtuels Alarme de @Steven et MultiAlarme de @drboss sur la HC2. Il faut importer autant de fois le QuickApp que nécessaire, et il permet de programmer un réveil simple ou des réveils multiples : Exemple avec horaires différents pour la semaine et le week-end : On peut ainsi programmer une semaines complète avec 7 horaires différents si on le souhaite. Cela permet de modifier à tout instant l'heure des scénarios depuis le QuickApp sans avoir à modifier la configuration de GEA, simplement depuis l'interface Web ou l'application mobile. Le QuickApp fonctionne ainsi : H+ / H- = Ajoute / enlève une heure [ ] = désactive l'heure M+ / M- = ajoute/enlève une minute Lu, Ma, Me, Je, Ve, Sa, Di = Active ou désactive le jours en question Choix Alarme : permet de sélectionner le réveil à régler Le choix du nombre de réveils se fait en modifiant la variable "Nombre_Alarme" dans le QuickApp : (ne pas toucher aux autres variables _HeureX et _JoursX situées en dessous, elles seront automatiquement créées ainsi que les labels) Utilisation dans les scénarios GEA : -- Syntaxe : {"Alarm", <id_qa>} -- Vérifie si la période (jour et heure) configurée sur n'importe quelle alarme de GEA_Alarm est atteinte {"Alarm", <id_qa>, <id_alarme>} -- Vérifie si la période (jour et heure) configurée sur l'alarme spécifiée de GEA_Alarm est atteinte -- Exemples : GEA.add( {"Alarm", id["QA_ALARM"]} , 0, "Debout fainéant", {{"TurnOn", id["LUMIERE"]}, {"Open", id["VOLET"]}}) GEA.add( {"Alarm", id["QA_ALARM"], 2}, 0, "Debout fainéant", {{"TurnOn", id["LUMIERE"]}, {"QuickApp", id["PLAYER"], "play"}}) id["QA_ALARM"] est l'identifiant du QuickApp GEA Alarme Il est possible d'avoir plusieurs GEA Alarm puisque chacun est identifié par son... identifiant ! Astuce : on peut modifier les programmations horaires depuis GEA à l'aide de la fonction setTime() : -- Réglage de l'heure de l'alarme n°2 sur 22h22 : GEA.add( {CONDITION}, 30, "", {"QuickApp", id["QA_ALARM"], "setTime", 2, "22:22"}) -- Désactivation de l'alarme n°2 : GEA.add( {CONDITION}, 30, "", {"QuickApp", id["QA_ALARM"], "setTime", 2, "--:--"}) Icones : Le QuickApp est de type "binary sensor", ainsi on peut configurer 2 icônes pour identifier d'un coup d’œil si un réveil est actif (= horaire programmé) ou non : Téléchargement  GEA_Alarme_v2.10.fqa

GEA Gestionnaire d’Événements Automatique Version 7.38 Voici le célèbre GEA de @Steven porté sur Home Center 3. Cette version de GEA est basée sur la version 6.13, les fonctionnalités sont donc identiques, à quelques différences près documentées plus bas. Ce n'est plus une scène, mais un QuickApp. La notion d'instances multiples des scènes n'a plus lieu d'être, car le QuickApp est mono-instance par nature, mais son principe d'exécution asynchrone du code LUA permet d'obtenir le même résultat, à savoir : - une boucle automatique de détection des événements à intervalle régulier de 30 secondes - un déclenchement instantané sur événement (avec le paramètre -1 pour la durée) Au sujet des événements, il n'y a plus besoin (et de toute façon il n'est pas possible) de définir des triggers pour le déclenchement. C'était une opération fastidieuse, car il fallait saisir manuellement les ID des modules dans l'en-tête de la scène. Cette nouvelle version de GEA détecte donc automatiquement les triggers, et surveille les événements via l'API refreshStates. Actuellement j'ai positionné cet intervalle de surveillance à 100 ms, c'est à dire un dixième de seconde. Ce n'est donc pas de l'instantanéité absolue, mais ça ne l'était de toute façon pas sur les scènes de la HC2, et ça reste inférieur au seuil de perception humain. Pour l'instant cela n'a posé aucun problème de performance lors de mes tests.... on verra ultérieurement s'il y a lieu de faire évoluer cet intervalle. La syntaxe de GEA est strictement identique à celle de la HC2 : GEA.add( ... ) Pour cette raison, ce topic est ouvert uniquement pour les discussions concernant le développement de GEA, les nouvelles fonctionnalités, et les rapports de bugs constatés. Pour les questions sur l'utilisation et la syntaxe de GEA, se reporter au topic unique "Support GEA" où vous trouverez toute l'aide nécessaire : En clair : Une règle GEA fonctionne sur HC2, mais ne fonctionne pas sur HC3 => je viens poster ici pour qu'on puisse corriger le bug Autrement : je supprimerai les messages sans préavis, j'ai autre chose à faire que de déplacer les messages postés sur le mauvais topic... avis aux contrevenants Le topic de référence concernant la syntaxe de GEA se trouve ici, comme d'habitude : Remarque : j'ai mis à jour le fichier de référence GEA_Syntaxe à télécharger en bas de ce message. Changements de GEA pour HC3 par rapport à HC2 Supprimé : "VirtualDevice", "VD" => remplacé par "QuickApp" et "QA" "SetrunConfigScenario" => remplacé par "SetRunModeScenario" et "RunModeScene" "RebootHC2" => remplacé par "RebootHC3" "ShutdownHC2" => remplacé par "ShutdownHC3" "multiAlarm" => remplacé par "Alarm" "setMode" => remplacé par "ThermostatMode" "setThermostatSetpoint" => remplacé par "CoolingThermostatSetpoint" et "HeatingThermostatSetpoint" "ThermostatLevel" "ThermostatTime" "DebugMessage" "PluginScenario" "Popup" Ajouté : "QuickApp" | "QA" : {"QuickApp", <id_module>, <méthode>, [paramètres]} "DeviceIcon" | "CurrentIcon" : {"CurrentIcon", <id_module>, <no_icon>} "Color" | "RGB" : {"Color", <id_module>, <intensité_rouge>, <intensité_vert>, <intensité_bleu>, <intensité_blanc>} "RunModeScene" | "SetRunModeScenario" : {"RunModeScene", <id_scene>} | {"SetRunModeScenario", <id_scene>, <run_valeur>} - <run_valeur> : "manual" | "automatic" "isSceneRunning" | "RunningScene" : {"isSceneRunning", <id_scene>} "ThermostatMode" : {"ThermostatMode", <id_thermostat>, <mode>} "ThermostatFanMode" : {"ThermostatFanMode", <id_thermostat>, <fan>} "CoolingThermostatSetpoint" : {"CoolingThermostatSetpoint", <id_thermostat>, <valeur>} "HeatingThermostatSetpoint" : {"HeatingThermostatSetpoint", <id_thermostat>, <valeur>} "Profile" : {"Profile", <id_profil>} "RebootHC3" : {"RebootHC3"} "SuspendHC3" : {"SuspendHC3"} "ShutdownHC3" : {"ShutdownHC3"} "Parameter" "Climate" "Breached" "VariableQuickApp" | "VariableQA" "CustomEvent" "WOL" "httpGet" "Call" "isEvenDay" Modifié : "Armed", "Disarmed", "setArmed", "setDisarmed" => Prend l'ID de la zone Amélioré : GEA.portables = {123, "Nokia 3310"} : ID du mobile, ou nom du mobile "Email" : ID du mobile, ou nom de l'utilisateur : {"Email", <id_user>, <"Message du mail">, <"Sujet du mail">} | {"Email", <id_user>, <"Message du mail">} "Picture" : ID ou nom de l'utilisateur : {"Picture", <id_camera>, <id_user>} | {"Picture", <id_camera>, <"nom_user">} "VariableCache" : utilisable dans les règles à déclenchement instantané avec -1 (en tant que condition, actions, mais pas comme déclencheur) "Alarm" : remplace "Alarm" et "MultiAlarm" : peut contenir autant d'alarmes que voulu "Ask" : exécute une scène, une méthode d'un QuickApp, ou une action GEA Les zones d'alarme, les profils, et les zones de climat peuvent être identifiés par leur nom Note : les actions "Reboot", "Suspend", et "Shutdown" ne fonctionnent plus depuis le firmware 5.050.13... Installation Importer le fichier fqa ci-joint. Ne modifier que le contenu de config pour vos propres règles : Mise à jour Copier/coller simplement tout le contenu du fichier LUA téléchargé dans le fichier main du QuickApp. Téléchargement Nouvelle installation : GEA_v7.38.fqa Mise à jour : Fichier main : GEA v7.38.lua Fichier tools : Library - tools v2.30.lua Documentation de référence sur la syntaxe : GEA v7.38 Syntaxe.lua

Bienvenue sur le forum

Oui tu as raison. Les intégrateurs, les vrais pros de la domotique (pas les électriciens/poseurs d'alarme et de volets qui installent 1 box domotique tous les 2 mois), font du KNX. C'est cher, valable uniquement en construction/rénovation lourde (donc cher aussi !), du coup le marché ne se développe pas (particulièrement en France) Les trucs pour le grand public vendus sur les étagères de la Fnac ou de l'AppStore pour la famille Michu, j'appelle pas ça de la domotique perso... Mais des objets connectés. Donc oui la domotique est un marché de niche, et le restera très longtemps. Soit tu veux un système fermé qui ne fait rien à part allumer les lumières depuis ton smartphone comme dans les publicités débiles, soit du veux une vraie domotique "intelligente" (ce terme ne veux rien dire, il vaut mieux parler de maison autonome, c'est à dire une maison bourrée de capteurs qui sait réagir seule aux différents événements)., dans ce cas pas le choix que de nous tartiner la configuration à la main. Rien n'existe sur l'étagère, et la domotique avancée restera longtemps un marché de niche pour geeks. J'ai coutume de comparer la domotique avec l'informatique.... des années 80/90 ! Parce que c'est bien là qu'on en est, c'est à dire avant l'an 2000 de l'informatique, l'explosion d'Internet, l’interopérabilité de tous les ordinateurs autour d'un réseau commun. La domotique, c'est le DOS des années 80, se tartiner des commandes à la main avec des profils config.sys personnalisés en fonction de l'usage car 640k de mémoire c'est pas assez. C'est le Windows des années 90 où chaque nouvelle version impose un reformatage complet de son système. C'est le Linux des années 90/2000, se recompiler des noyaux la nuit si tu veux intégrer le driver du dernier périphérique à la mode. Le document Office qui ne peut être ouvert sur autre chose que Office lui-même. Etc.... Tu m'étonnes que ça ne décolle pas ! Dans 10 ou 20 ans, on en reparlera. Ce qui me désole, c'est que ça fait 7 ans que je fais de la domotique, ça n'a pas évolué d'un pouce. Le Zigbee cartonne, alors qu'il est moins évolué que Z-Wave. EnOcean est un échec cuisant. Les tentatives de standardisation type OpenThread ont fait plouf. La mode est aux objets et modules connectés sur Wi-Fi.... youhou, on est vachement avancé avec ça... Bref, ce débat on l'a déjà eu 100x sur le forum, et les autres forums, rien de nouveau.... fait ton choix de "centrale domotique" en fonction de tes besoins, de tes compétences, du temps que tu es prêt à y consacrer, etc Perso comme dit, je reste chez Fibaro car c'est un environnement que je maitrise, j'en connais les limitations, mais surtout il est stable, c'est plus important que de pouvoir intégrer le dernier objet à la mode à mes yeux.

Bienvenue sur le forum

Justement non en fait. Un pro a besoin de vendre un truc qui marche, qui soit stable, et fiable dans le temps. Un truc qui ne lui plombe pas sa rentabilité en faisant du SAV à outrance chez les clients mécontents. Donc les trucs avancés, les moutons à 5 pâtes qui font papa maman, c'est bien pour les geeks qui ne comptent pas leurs heures, mais pas pour les pros. La HC3 (ou même la HC2) en fait déjà trop pour les besoins d'un pro, très clairement avec nos nombreux Modules Virtuels / Quick Apps, Scènes alambiquées, règles GEA, etc... on en fait déjà largement plus que ce que n'importe quel intégrateur va mettre en place chez un client. Et j'aimerais pas être à la place du pro qui tombe chez le client "à moitié geek", celui qui a vu qu'on pouvait connecter un module Zigbee Xiaomi ou un relai Wi-Fi Sonoff, et va demander à son intégrateur de lui fournir une solution interopérable avec tout. L'enfer du pro, se retrouver à déployer une solution qu'il ne maitrise pas, et qui va lui revenir à coup sûr dans la tronche quand le client qui a bidouillé va venir se plaindre que plus rien ne fonctionne. Mon métier c'est de l'informatique, et c'est vraiment pareil. Je déploie une solution fermée à base d'UNIX propriétaire, je sais que ça va fonctionner, le résultat est prévisible et parfaitement documenté par l'éditeur, jamais aucune surprise (sauf bug/plantage/panne, ça peut toujours arriver) Je vais déployer un Linux, c'est juste l'enfer tant les possibilités sont infinies, t'es incapable de prédire le temps que tu vas y passer, il n'y a pas 2 configurations identiques. (bon celui qui n'a jamais fait d'UNIX ne peut pas comprendre cela dit...)

Ah mais je ne dis pas le contraire, ça évolue plus vite sur les solutions open-source Je réagissais juste à ta phrase "repartir dans la même logique d'utilisateur bêta testeur pendant de longues années, avec un produit qui marchotte de version en version, avant d'avoir un truc de stable" parce que tu auras exactement la même chose sur les solutions open-source, et même, je pense à la lecture des forums, en pire : Non parce que sérieusement, en dehors des blogueurs qui font la promo de telle ou telle solution, quand tu vas fouiner sur le forums, tu te rends vite compte que l'herbe n'est pas plus verte ailleurs du point de vue de la stabilité, du support. J'ai même vu des gens en revenir pour dire que c'est plus stable chez Fibaro. Comme quoi... Après, ces solutions open-source, si tu es geek, que tu as une infra virtualisée, la possibilité de snapshoter pour revenir en arrière, là y'a moyen de s'éclater. Si tu veux piloter whatmille objets connectés aussi, tant les plugins sont nombreux. Si tu es développeur et que tu sais écrire tes propres plugins, il n'y a plus aucune limite. Bref, faut poser le pour et le contre, perso je reste chez Fibaro parce que ça marche bien (mon HC2 va fêter ses 7 ans le mois prochain), c'est bien plus stable que la lecture des forums ne le laisse croire (normal on entend toujours les râleurs, moi compris), et je maitrise la solution (la HC3 est différente en apparence, mais on retrouve beaucoup de concepts identiques). Et j'en ai rien à faire de piloter des objets connectés chinois à pas cher buggués de partout (coucou Xiaomi, Sonoff, ...). La relative "non-ouverture" de la HC3 ne me dérange pas, j'y trouve largement mon compte (elle permet déjà tellement plus que la HC2) Je suis d'accord avec tes remarques concernant Fibaro..... cependant leur stratégie est très claire, surtout depuis le rachat par NICE : offre orientée vers les pros (comprendre : les intégrateurs). Le grand public, l'utilisateur final, ils s'en moquent. De toute façon, même à l'époque de la HC2, ils n'ont jamais écouté les retours utilisateurs. On peut s'estimer heureux d'avoir la possibilité d'acheter la box en direct. En tout cas, ils ne cherchent absolument pas à concurrencer les solutions "open-sources qui savent tout faire", cela ne cible pas du tout la même population. Leur concurrent, c'est Somfy, qui pour rappel est le distributeur n°1, et de très loin, en box domotique. Sauf que quand tu compares la HC3 et une box Somfy, il y a un monde entre les deux. Il y a donc un potentiel énorme, reste à Nice d'arriver à promouvoir leur offre (au travers des intégrateurs justement... la domotique rentre en force chez les gens par l’automatisation du portail et des volets)

Oui je sais, c'est ce qui m'arrive avec l'IPX800 et l'EcoDevice RT2 Mais bon, ce n'était pas trop le sujet de ce topic à la base Autre chose quand même, je ne sais pas si tu as remarqué, les labels ne sont pas persistants. Leur valeur est perdue après le redémarrage du QuickApp (donc de la box), ce n'est vraiment pas le lieu pour y stocker une valeur, mais juste pour afficher une information pour l'utilisateur. D'ailleurs dans l'API, Fibaro a bien séparé les properties (valeur par défaut du label qui est repositionnée à chaque redémarrage) et les View (valeur courante du label).

Ose, tu nous raconteras

Ta première phrase, tu peux l'application à Jeedom, Domoticz, Home Assistant, ça sera exactement pareil. La seule différence c'est que c'est gratuit (enfin, faut quand même payer une machine pour l'héberger) Si tu veux un système stable, qui ne soit pas en développement, tu peux prendre une Somfy Box par exemple, tu pourras faire.... rien... avec. Sinon pour la logique du raisonnement de mutualisation des fonctions, je suis d'accord

OK je vois... mais je trouve surprenante ton utilisation des childs Toutes ces infos, elles devraient être dans des child "monofonction", et pas des labels. Avec le bon type, genre fibaro.multilevelsensor, etc... et la bonne unité Comme ça, c'est exploitable directement dans des scénarios (avec GEA, ou autre peu importe). Chaque child = une mesure de capteur. Et ça remonterait aussi dans Domocharts (dans la nouvelle version, j'ai supprimé les labels et les variables globales, car toutes les valeurs sont censées être dans des child, autant utiliser la HC3 comme... une HC3... et pas une HC2)

Je ne comprends pas bien.... car il n'y a rien à afficher sur un child, on ne peut pas personnaliser son affichage (boutons, labels, sliders)

C'est beau, mais..... si tu comptes passer sur HC3 : oublie les scènes qui ne sont clairement pas mises en avant : 1 seule instance maximum je n'ai pas trouvé comment passer des arguments toujours pas possible de récupérer le retour, sauf à utiliser la méthode bien lourde des variables globales les QuickApps c'est l'avenir justement, on peut maintenant définir des fichiers au sein de chaque QuickApp, super pratique pour décomposer son compte et utiliser des librairies de fonctions

Oui je suis d'accord, et je ne dis pas le contraire sur l'attention qu'il faut porter à cette instabilité. A ce sujet, je conseille de commencer par isoler le Quickapp ou la Scène qui est responsable de ce changement de comportement. Et si ça se trouve, cette recherche aboutira à désactiver tous les Quickapps/scènes pour se rendre compte que l'instabilité ne vient pas de là.... on ne sera pas plus avancé, mais on aura éliminé une piste. Quand au sleep, je ne suis pas si extrémiste, il est encore supporté, mais il faut l'utiliser avec parcimonie Pour l'instant je trouve cette HC3 très stable, pour mon usage (qui encore une fois comporte très peu de modules Z-Wave, juste pour tester, mais par contre j'ai beaucoup de QuickApps actifs) Ces discussions me rappellent celles qu'on a eu au sujet de la HC2, en v4, une fois que Fibaro avait corrigé tous les bugs de jeunesse, certains utilisateurs se plaignaient encore de plantage, et en arrivait à supprimer totalement les Main Loops de leurs modules virtuels. C'était bien selon moi un mauvais codage LUA des dites Main Loops. Dans un autre registre, dans mes codes j'ai toujours limité les écritures dans la DB (tant pour les performances, que pour l'usure de la mémoire flash). Que ce soit une variable globale, un label, etc.... je vérifie l'ancienne valeur, avant de potentiellement modifier la nouvelle valeur. Cela évite de réécrire inutilement une valeur identique. A l'époque de la HC2, à un moment donné j'avais même soupçonné que trop d'écriture simultanées dans la DB pouvaient occasionner des plantages par effet de bords de plusieurs écritures qui se télescopent (au passage en v4, Fibaro avait introduit un process au niveau de Linux par lequel étaient censées passer toutes les écritures) De même, il ne faut jamais supposer qu'une fonction va renvoyer une donnée attendue, il faut toujours la tester avant de l'exploiter dans la suite du code (tester son type, et sa valeur....) Ce sont quelques pistes, certes lourdes à mettre en place dans l’écriture de nos codes, mais qui les rendent plus robustes, et évitent bien des plantages.

Mouais... j'aurais pensé que via api.post(), donc en localhost sur 11111, ça serait passé sans auth, mais je constate une fois de plus que Fibaro modifie les API sans prévenir....

Thank you, this is exactly what I was looking for I cas see this command actually stops the code, but it doesn't restart the Quickapp, despite what its name would suggests. EDIT : Sorry, it's OK, the QuickApp actually restarts

Oui pareil pour le shutdown chez moi, je pense qu'il faut l'oublier et utiliser le suspend à la place, même si je n'ai pas trop compris la différence... Mais du coup tu utilises bien un header Authorization, c'est justement ce que je veux éviter, c'est juste aberrant quand le code tourne déjà sur la box elle-même....

Bravo Il doit également y avoir un paramètre pour lui demander de générer la page avec le thème sombre, faut que je cherche ça....

@TonyC bah justement, sur mon HC3 la première règle de GEA me signale par notification Push un redémarrage du Quickapp... et la 2nde me signale un redémarrage des services... et ce n'est justement pas le cas depuis que j'ai fait cette mise à jour Donc je ne rencontre pas ce souci, alors que vous êtes au moins deux. Donc il y a bien un souci sur vos 2 box. On a le même firmware, la différence, ce sont nos codes LUA. Et aussi les modules Z-Wave, dès fois que le problème vienne du moteur Z-Wave. Mais comme @Krikroff (qui a migré tous ses modules) n'a pas non plus de souci et que je lui fait confiance pour la qualité de ses codes LUA, je me dis que c'est vraiment là qu'il faut chercher. Dans le doute, faut désactiver les QuickApps et Scènes une par une jusqu'à identifier le fautif.... c'est fastidieux je sais. Pour en revenir aux sleep(), j'en utilise quelques-uns, mais dans des circonstances bien précises. Par exemple dans le déroulement d'un code séquentiel, je fais une action, et j'ai besoin d'attendre 1 seconde, puis de continuer. Là je le fais avec un sleep() Cela ne pose à priori pas de problème. A l'inverse, s'il s'agit d'une boucle infinie qui doit répéter une action à intervalle régulier (ou irrégulier d'ailleurs), là c'est bien le settimeout() qu'il faut utiliser.