Lazer

Non en local c'est le mieux, il n'y a aucune raison de mettre ces variables dans l'objet quickApp (désigné par self) En effet, si le contenu du pcall() crash, cela sera intercepté et traité dans le code LUA juste en dessous (if not status then ...), donc on est bien dans le même "scope" de portée des variables locales. De manière générale, une bonne pratique en programmation est de toujours réduire au maximum la portée des variables utilisées. Ici la variable n'est exploitée qu'en locale, donc déclaration avec local xxx. Si à l'inverse on aurait eu besoin de traiter les variables dans une autre fonction du QuickApp, alors on peut au choix passer la variable en argument lors de l'appel de la fonction, ou bien si la variable est utilisée par plusieurs fonctions (potentiellement toutes les fonctions du QuickApp), alors on affecte cette variable à l'objet quickApp (donc déclaration avec self.xxx) Je ne vois pas le besoin de donner un exemple dans le contexte d'un QA, car c'est bien le sens de mon tuto (il est même plus général que ça en fait). Le code que tu vas protéger avec pcall(), il est forcément dans une fonction. Que cette fonction fasse partie du QuickApp, que ça soit une fonction locale, une fonction globale, ou bien encore une fonction d'un autre objet, cela ne change absolument rien à la syntaxe décrite dans le tuto. Bref, tu rajoutes ceci et tu as ton exemple : function QuickApp:maChereFonction(avec, de, beaux, arguments) -- ici n'importe lequel de mes exemples avec pcall() end Ta 2nde question est pertinente, j'ai oublié de le préciser dans le tuto, même si on peut le deviner quand je parle d'asynchronisme. Le setTimeout appelle une fonction en asynchrone (même en mettant un délai = 0), du coup tout ce qui s'exécute après n'est plus protégé par le pcal() ... C'est exactement comme pour l'appel de la fonction http:request(), la fonction success() appelle en asynchrone n'est pas protégée par le pcall(), donc on emploie un nouveau pcall() pour protéger le code LUA à l'intérieur, comme je l'ai montré avec le json.decode() Donc dans le cas d'une boucle infinie, on appelle dont une fonction à intervalle régulier avec fibaro.setTimeout(), par conséquent c'est le code de la fonction appelée qui doit contenir le pcall(), et non pas le code de la fonction appelante. Cela dit, une boucle infinie, elle s'appelle elle-même, du coup, bah.... il y a un pcall() à chaque fois. Exemple plus loin pour une meilleure compréhension. Mais avant, il faut aussi savoir que la fonction onInit() devrait faire le minimum de choses et rendre la main le plus vite possible au système. Cela implique que cette fonction onInit() doit appeler un minimum de fonction en synchrone, puis continuer l'exécution en asynchrone. Cela étant dire, un exemple de squelette de code : function QuickApp:onInit() -- Ici on effectue quelques initialisations : affichage de log, chargement des variables du QA, initialisaiton de variables, etc self:debug("Salut") self.refreshInterval = tonumber(self:getVariable("Refresh")) or 60 -- Maintenant on se prépare à rendre la main au système, donc on va lancer la boucle infinie en asynchrone : fibaro.setTimeout(0, function() self:loop() end) -- On constate que dans cet exemple, on appelle la loop avec un délai à 0. -- Donc elle s'exécutera tout de suite, mais en ashynchrone. -- Cela permet de rendre la main au système qui va pouvoir finir l'initilisation du QA juste avant d'exécuter loop() end function QuickApp:loop() local status, err = pcall(function() -- Ici le code fait tout plein de choses utiles -- ... end) if not status then -- Gestion de l'erreur attrapée par pcall() self:error(err) end -- Prochaine boucle ena asynchrone dans 1 minute (60000 millisecondes) fibaro.setTimeout(math.floor(self.refreshInterval*1000), function() self:loop() end) end Ne pas oublier que si la loop() appelle d'autres fonctions en asynchrone, alors celles-ci ne seront plus protégées par le pcall() de la loop() Mais si elle appelle des fonctions en synchrone, alors elles seront bien protégées. Exemples de fonctions synchrones : - toutes les fonctions natives du LUA : string.* math.*, etc - potentiellement n'importe laquelle des autres fonctions de notre QuickApp. Mais je dis bien potentiellement, car on peut aussi vouloir appeler ces autres fonctions en asynchrone, selon l'effet recherché.

Suite ici :

Version 5.070.42 Stable Important Notice In some cases (on large systems) update with automatic backup may fail due to the size of the database. Please create local backup manually, download it, then perform the update with "No backup before update (not recommended)" option selected. What's new: Alarm Added column with alarm scene ID. Backup Disabling backup creation button when reached the backups limit. Optional saving of the history content when creating backup manually. Storing historical data during backup creation deactivated by default. Auto-trimming to 500000*/1000000** events while creating backup for reducing backup size. Warning about not storing historical data in auto-backups created during update. Warning about possible loss of historical data before restoring backup. Dashboard Serial number displayed as a tooltip after hovering on logo. Exact value from the api displayed as a tooltip on device tile and on the right sidebar. Possibility to control com.fibaro.player devices from the right sidebar. Possibility to open video gate from the right sidebar. Thermostat preview available from the FIBARO Home Center app. Icons for opening and closing states of roller shutters. Unified text size and colour on the right sidebar. Status toasts after performing actions on devices using the right sidebar. No limit to the number of devices.* System notification after exceeding the recommended number of devices.* Devices Power consumption charts in device Advanced tab. Three new icon sets for valves. Unified content of Advanced tab for devices of the same type. Advanced tab for all types of linked devices. Current/total energy consumption view switch. Requiring confirmation before clearing the energy data. Sum function available for linked devices of the multilevel sensor type. Two possible configurations of the energy meter device. Support for FIBARO Walli Controller (FGWCEU-201). Support for FIBARO Smart Implant (FGBS-222) version 5.2. Support for Heatit Z-Smoke Detector 230V version 4.1/4.2. Support for Heatit Z-Temp2 version 1.1/1.2 Support for Heatit Z-TRM3 version 4.0. Support for Sensative Strips Guard in any version. Support for U-Fairy Valve Shut-Off Controller. Support for Steinel IS 140-2 version 1.0. Support for Steinel L810 LED iHF version 1.1. Gateway Connection** Unlocked feature of connecting two or more gateways: FIBARO Home Centers 3 may be connected only to other Home Centers 3. Slave gateway must be empty or will be restored to factory settings. All gateways must have the same version installed. Backing up connected gateways together using the master gateway. Updating connected gateways one after another starting from slave gateways. Possibility to update all gateways or master gateway only. Possibility to restore backup for all gateways or master gateway only. Possibility to access slave gateways via generated password. History Displaying events related to power consumption of devices. Improved displaying events from FIBARO RGBW Controllers. Network Possibility of adding a second Wi-Fi network for emergency auto-switching. Connecting to emergency network after losing connection to main network. Storing the credentials of added Wi-Fi networks after its disconnecting. Retrying to connect to main network each 30 minutes when connected to emergency network. Possibility of testing the connection to emergency network. Wireless network interfaces data included in system report. Added test button for networks with unknown status. Nice** Backing up Nice devices in the system configuration backup. Nice remotes available as scene triggers. Improved view of adding new device. Changes on the binding view. Support for NiceHome devices. Notifications Critical push notifications available as a new channel for life danger events. Other Beta version status displayed on the login screen and in General Settings. Tooltips on the interface menu icons. Possibility of skipping the ongoing first system configuration process at any step. Performance Optimized services performance and events handling. Optimized database write and read times. Added memory usage limit for power and temperature events to reduce overall memory load. Plugins Added Tedee lock plugin. Added Dahua camera plugin. Profiles Door locks available to open/close in any profile. Quick Apps Buttons and sliders available as actions in block scenes. Option of hiding the button. Rooms Possibility of choosing the main room energy meter. Scenes Redirection to expanded scene view from scenes dashboard. Update Notice of the necessary local connection to perform the update. Redirection to current system status after starting the update. Automatic backup during update procedure does not contain historical events data anymore. Bug fixes: Access Incorrect limit of characters when editing a user's e-mail address. No auto-logging when accessing the gateway via remote access. Alarm Possibility to add Z-Wave devices to Satel alarm zones. Cannot add alarm zones during the First Time Installation. Cannot arm the whole house if there are unconfigured alarm zones. Backup Cannot migrate cloud backups from one Home Center 3 to another. Incorrect states when creating backups. Cancellation of downloading an update stops creating/restoring the backup. Cameras No pause button on camera image preview. Complex stream paths are improperly translated. Climate Some thermostats controlled manually enter override mode despite the lack of schedule. Dashboard Unable to manually set the temperature on Fibaro Heat Controller from the right sidebar. Unable to override the temperature on third-party thermostats from the right sidebar. Devices Temperature setpoint chart is displayed incorrectly. Energy data on device Advanced tab is not cleared. No possibility to add FIBARO RGBW 2 (FGRGBW-442) in security mode. Scenes added from device Advanced tab are not displayed in this tab. Linked device of thermostat type is always equipped with all operating modes. Notifications from devices come too often and not according to selected interval. Possibility to set the ID of an icon that no longer exists. Issues with configuring parameters in devices without templates or with disabled template. Gateway Connection No central scene events from devices added to slave gateways. Scenes based on scene activation events from devices added to slave gateways do not work. Cannot change icons of devices added to slave gateways. Unable to force the removal of devices from slave gateways. Unable to change wakeup interval of battery devices added to slave gateway. Wrong message about restoring default password when removing disconnected slave gateway. No possibility to set polling time and run mesh reconfiguration on slave gateways. Error after removing a disconnected slave gateway. Restored local backup does not include slave gateways. Connect and Replace buttons available inadequately. Master gateway crashes when using Climate Panels with thermostats from Slave gateway. History Incorrect units for events from multilevel sensors. Filtering events by rooms does not work properly. Users see events from devices to which they do not have permission. Network Services do not start if there is a network connection without the Internet. Unexpected Wi-Fi connection loss.* Error 500 in some cases during connection with Wi-Fi network. Disconnected emergency network displayed as unknown after reboot. Nice** Scenes with Nice Mono and BiDi devices do not work. Notifications Critical push notifications are not sent. No notifications from BiDi Z-Wave device after rebooting the gateway. Duplicated notifications of available template after rebooting the gateway. Unexpected Nice radio protocol connection timeout notification. Other Chinese language version choice is not saved. Services do not start after leaving the stand-by mode. Power diode is not lit after leaving the stand-by mode. Numerical values are rounded incorrectly. Cannot close toast messages. Performance Significant delays in Z-Wave network communication. Few minutes after rebooting system is not available. In some cases, the gateway does not start after performing an update. Low gateway performance with MJPG stream preview.* Long gateway booting time.* Rare system crash on boot when system contains a large number of plugins/Quick Apps. Plugins Planika fireplace plugin status is refreshed too often and results in mobile app crash. Fibaro Heat Activator plugin turned off after adding by default. No data from YR Weather plugin. No support for rain state in YR Weather plugin. Profiles Scene in which the active profile is a condition does not start after rebooting. Cannot set actions in profile. Quick Apps Non-admin users get the login screen when opening the quick app on the mobile app. Non-admin users get only the custom part of quick app on the mobile app. The first letter in labels is automatically changed to a capital letter. No button for removing the device after leaving the edit mode. No family section in general device settings. Invalid support of 'secured' property for door locks. Push notifications from Quick Apps are always sent to all users. Recovery Large systems in some cases start up in recovery mode. Cannot upload beta version from local file when using Repair option. In some cases page does not load properly.* Scenes Scene Activation IDs are not displayed when creating block scene. Deactivation of a running scene does not stop the scene. Soft reconfiguration of the device is required to run scenes with Access Control Events. No protection against running the same scene at short time intervals. Value set on slider is zeroed and locked when editing existing block scene. Scenes based on sunrise and sunset do not function properly. In some cases, scenes require editing to work after creating backup. Syntax of fibaro.profile function is prompted incorrectly. Cannot select device in single device block. Inverted door lock condition states. Scene created from device settings is not filled automatically with Scene Activation Event. Update Possibility to start update before displaying auto-backup options. * - applies to Home Center 3 Lite ** - applies to Home Center 3

Elle n'est même pas encore référencée sur le forum officiel, cette mise à jour s'est peut être enfuie de sa prison toute seule

Nom de Zeus, cette rupture du continuum espace-temps, Fibaro ne nous avait pas habitué à cela

Le ZXT-120 avait exactement le même comportement, la sonde de température ne renvoyait pas la température automatiquement (ni à intervalle régulier, ni sur variation de température), si bien que j'avais fini par cacher la tuile dans l'interface de la HC2. Visiblement le ZXT-600 se comporte pareil, ça doit être un comportement voulu par Remotec, mais c'est bien idiot, car du coup on a une sonde de température inutile. Cependant je ne comprend pas ton mode de fonctionnement, le panneau de chauffage sert à donner une consigne de température, laquelle est ensuite transmise au module Z-Wave : le ZXT-600, qui est de type "thermostat" au sens Z-Wave du terme, mais n'est pas un thermostat au sens de la régulation de température, car il se contente d'envoyer à son tour cette consigne de température à la climatisation. C'est ensuite à la clim d'utiliser son thermostat interne pour réguler la température, et ajuster sa puissance de chaud/froid en conséquence. Du coup, dans ce mode de fonctionnement, à aucun moment tu n'as besoin de la sonde de température intégrée au ZXT-600 Après dans ma situation, le souci que j'avais rencontré, c'est que ma clim étant basique, le split mural installé en hauteur utilise sa propre sonde de température interne, qui ne capte donc que le température du plafond. Les clims plus haut de gamme ont une télécommande murale déportée qui intègre une sonde de température, à place à hauteur d'homme. Du coup, quand je demande 21°C, j'ai froid car c'est la température au plafond, et il fait beaucoup moins à 1m du sol (gradian de température variable selon la saison, la température extérieure, l'isolation, etc) Sur la HC2 je m'étais développé un module virtuel qui prend une sonde de température posée sur une étagère (le ST814 qui fonctionne très bien), ainsi qu'une sonde de température au plafond (j'ai un détecteur de fumée et un détecteur de mouvement). En fonction de la température ambiante, de la température du plafond, le module virtuel ajuste la température de consigne de la PAC. C'est d'ailleurs assez surprenant, car en plein hiver quand il fait bien froid, il monte la température de consigne du split jusqu'à 28°C . Dans tous les cas il fait toujours plus chaud au plafond, en ce moment on est entre 24 et 25°C de consigne, pour obtenir 20°C dans la pièce.

Je ne savais pas, mais à la réflexion ça ne me choque pas trop, sinon comment Alexa / G. Assistant feraient pour savoir à quelle box envoyer les ordres ?

Your GEA rule #7 on line 23 has a bad option, you must remove the space and use the following syntax : "Value+" Also, the second parameter is strange, a string containing "575" ? What is that, a module named 575 ? Or if you want to use its ID, you must use a numeric value, so just 575 is fine. Or its exact full name in a string enclosed with double quotes. So this rule is ignored, and no event trigger is recorded. You can still force a specific language by adding the following option in config() : GEA.language = "fr" (only French and English are recognized)

Moi aussi chez Free j'ai un bon ping et de bons débits, comme chez Orange, mais ça c'est en apparence. Ou plus précisément en situation de benchmark, sur un serveur Speedtest qui a été sélectionné car étant proche de chez toi, sur le même réseau (le réseau de Free) En pratique, session de surf, j'ai régulièrement des latences, notamment quand je consulte un nouveau site. Cela peut avoir plusieurs origines, des serveurs DNS qui sont lents à aller chercher l'adresse, des routeurs qui sont lents à calculer une nouvelle route, de mauvais accords de peering avec les réseaux des autres opérateurs. Et sur ce dernier points, Free est connu pour être très mauvais.... les problèmes avec Youtube par exemple, n'ont jamais été résolu. Même si en général ça fonctionne bien, il arrive régulièrement que je n'arrive pas à charger une vidéo, surtout aux heures de pointes, genre début de soirée. Et 1 heure après, comme par hasard, ça marche, chargement instantané même en 2160p. Chez Orange, je n'avais aucun de ces problèmes, mais l'abonnement était 2 fois plus cher... alors forcément, le réseau derrière n'est pas le même. Bref, Network Monitor a été conçu, avec tous ses paramètres, pour être adaptés à chaque cas d'usage. En ce qui concerne un serveur éteint la nuit, ou pendant les vacances, tu peux aussi utiliser les conditions dans le dernier champ pour exclure temporairement un appareil du monitoring grâce aux variables globales. J'ai donné des exemples dans le tuto.

A priori ce n'est pas nécessaire, car il y a toujours des événements sur la box, j'imagine qu'il avait détecté ce bug tout au début, sur une box sans rien. En tout cas dans GEA ne n'ai pas implémenté ce hack, et ça ne semble avoir jamais posé de problème. Et pourtant je n'ai que 5 modules Z-Wave.

C'est ta connexion Internet qui est trop lente ou instable, ça m'a fait le coup quand je suis passé d'Orange à Free (et là tu comprends la différence de prix....) Il faut que tu augmentes le timeout et le nombre de retry, par exemple pour Google tu mets : - timeout = 10 - retry = 10 Et là tu seras tranquille, si Networrk Monitor t'avertit que Google est injoignable, c'est que tu as une vraie panne Internet depuis 10*10 = 100 secondes Idem pour ton second NAS, s'il est trop vieux / trop lent, il faut augmenter les valeurs pour rendre Network Monitor moins sensible.

L'événement d'une Variable Globale : { "type": "GlobalVariableChangedEvent", "data": { "oldValue": "0", "newValue": "1", "variableName": "Vacances" }, "created": 1602618012 } J'ai cartographié beaucoup d'événements de mon coté, car je les utilise comme triggers dans GEA. C'est fou tout ce qui existe, et c'est vraiment super en fait, car on peut détecter tout ce qui se passe sur la box.

Parfaitement d'accord

Les messages "Connection error: Operation canceled" que tu vois, c'est quand la connexion n'arrive pas à aboutir (Internet saturé, serveur Netatmo trop lent, etc) Et c'est ce qui provoquait le plantage du QA avant la protection du request() avec pcall() Je n'ai pas encore regardé en détail les différences entre son fichier et le miens.

Pour ceux qui veulent copier le code source LUA original de GSmart, il l'a partagé sur son Github : https://github.com/gsmart-pl/Netatmo-QA-FIBARO-HC3/archive/2.5.1.zip C'est la version 2.5.1. Attention ce n'est pas le même code qu'hier, il a intégré un nouveau correctif aujourd'hui.

Réglages => Dispositifs => bouton "+" => Autre appareil : Puis Quick App :

J'ai failli l'écrire en plus tout à fait d'accord

Oui mais ton souci était lié au fait que tu avais un usage un peu extraordinaire des scènes : trop de déclencheurs La logique de Fibaro, c'est une scène = un événement => 1 action Dans cet usage, le mono instance ne devrait pas être un souci. Faut pas oublier qu'on est quelques uns ici à utiliser nos box de façon relativement intensive, du coup on est obligés de trouver des astuces.

Oui voilà, fait comme tu veux Non mais sérieusement, je n'ai pas de solution miracle, ou en tout cas, en l'état actuel de mes connaissances de la HC3, je ne sais pas quelle est la meilleure solution d'un point de vue utilisation des ressources de la box. Perso j'aime bien tout centraliser dans GEA, car je trouve que c'est un moyen clair de visualiser tous mes scénarios, mais peut être parce que je lis couramment la ligne de commande (façon Matrix lol... non juste Unixien inside...) Le risque de plantage ? Ben disons que c'est du tout ou rien, du coup si un truc ne marche pas, on le remarque immédiatement, ça ne risque pas de passer inaperçu. Et puis ça fait un seul truc à monitorer (avec un Watchdog), on ne risque pas d'oublier une scène à part dans un coin. J'ai 200 règles, je ne me vois pas devoir gérer autant de scènes, ça serait in-maintenable (et pour revenir sur les perfs, pas sûr que la box gère correctement les triggers sur autant de scènes différentes). Et puis chaque scène étant un processus Linux, la consommation en mémoire vive serait largement supérieure. Après pour des scénarios plus classiques, enfin surtout moins nombreux, le mécanisme de trigger des scènes proposé par Fibaro est très bien. L'essentiel est de trovuer chaussure à son pied... mais pour cela il faut souvent en essayer plusieurs.

Attention, seuls les modules Z-Wave sont transférés, pas les VD ni les scènes. Donc dans tous les cas, il faut que tu commences par préparer tes nouveaux QA et Scènes, pour être prêt à modifier uniquement les ID le moment venu, car tu ne peux pas les deviner, les ID apparaitront au moment où tu incluras les nouveaux modules ou que tu feras le transfert de contrôleur. J'ai mon HC3 depuis mai, je n'ai toujours pas migré, ça sera surement pour mai prochain, soit 1 an après. Déjà je ne veux pas faire ça pendant l'hiver, ma box gère tout le chauffage, et je n'ai pas envie de passer ne serait--ce que 24h sans chauffage (Mme encore moins lol) D'ici là, ça me laisse le temps de préparer mes nouveaux QA, pour que tout soit prêt le jour J. Je n'aurai qu'à adapter les ID... et c'est relativement simple, car 99% de mes scénarios sont dans GEA, donc un seul point unique, tous les ID dans un tableau. C'est plus simple que de devoir modifier 20 scènes un peu partout. Et je ne ferai pas de migration de contrôleur, alors OK c'est plus simple, mais tu récupères tous les problèmes dans les modules (j'ai des associations fantômes notamment). Donc je préfère exclure/inclure mes modules, et tant pis si ça me prend 2 jours, je ferai ça pendant ma semaine de congés à solder avec le 31 mai. Tu fais comme tu veux, comme tu le sens, mais surtout ne te précipite pas.

Aucune idée du fonctionnement interne....

Et pas besoin de créer une boucle qui teste l'heure dans le QA. La bonne méthode, à mon avis : - à intervalle régulier, la QA calcule (ou récupère en ligne ?) la nouvelle heure d'aube et crépuscule. - il calcule et définit un setTimeout pour déclencher une fonction - cette fonction émet le customEvent

D'après mes tests, pas besoin de les créer dans les onglets, le simple appel à l'API pour émettre un événement suffit. Du coup je ne sais pas trop à quoi sert cet onglet.... je me dit que c'est bien de les créer pour avoir une liste et s'y retrouver, sinon on a vite fait de les oublier

Sinon tu veux utiliser la procédure de migration, qui va transférer tous tes modules de la HC2 vers la HC3, en une seule fois, sans retour arrière possible, donc il faut être sûr de ton coup. Cela se passe via ton compte Cloud Fibaro

Ta dernière proposition me rappelle ce que fait @jang justement avec son Webhook QA : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/6/?tab=comments#comment-202423