Lazer

Tu as bien désactivé le Wi-Fi de la Freebox ? Pour ne conserver que ton Wi-Fi interne, porté par les bornes Unifi ? Est-ce que la Freebox Delta supporte bien le routage en loopback ? C'était bien le cas pour les Freebox précédentes, mais vu que ça n'est pas possible sur les box des concurrents, je ne sais pas s'ils l'ont implémenté sur la Delta. Car si tu demandes à ton application Fibaro de se connecter sur ton IP publique, tu as besoin du routage en loopback pour accéder à ton propre réseau local.

Je l'ai installé sur ma box de dev, sans souci.... mais bon, il n'y a pas grand chose dessus. En tout cas j'aime bien leur cycle de développement ces deniers temps, les betas se rapprochent, avec de plus en plus de correctifs (aucune nouvelle fonction dans cette beta, malgré le long changelog, ce sont essentiellement des correctifs de bugs de la précédente beta qui d'ailleurs porte le même numéro de version 5.072.xx). D'ailleurs les équipes de dev Fibaro sont très actives sur le forum officiel depuis quelques semaines. Après leur intervention sur ma box pour les soucis de CPU, ils répondent activement aux sollicitations des utilisateurs et des différents bugs remontés, mineurs, comme majeurs. Au top Si seulement ça pouvait être toujours ainsi... Par contre l'appli mobile est toujours une plaie, ils n'ont pas l'air pressés....

5.072.25 BETA Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Important Notices: The following software update removes energy data collected during the use of version 5.071 beta due to a changed strategy for handling reports. For all Z-Wave devices which feature meter capabilities (power, energy, gas, water, etc.) soft-reconfiguration procedure is required due to improvements in support of those device types (not applicable to updates from version 5.072.14 beta). Update 5.072 includes a new version of the Z-Wave software (called Z-Wave 3.0). This version features expanded default device support, the ability to add products using Smart Start technology and many other changes. Please note that this is a beta version and its compatibility will be developed with further updates - not all Z-Wave devices are fully supported. ATTENTION - installing version 5.072 does not automatically change the existing Z-Wave 2.0 software to 3.0. In order to run version 3.0, it is necessary to restore the gateway to factory settings, requiring the system to be configured from scratch. In future updates we will work on extended device support and provide a mechanism to migrate your current system configuration to the new Z-Wave engine. Main features: 1. Z-Wave Software 3.0 Extended compatibility of Z-Wave devices (more devices, additional features). 2. Yubii Ecosystem (Home Center 3 & Yubii Home)* Support for configuring device parameters. Redesigned configuration wizard. 3. Energy Panel New Savings tab and Panel Settings window. What's new: Backup Warning before restoring a backup contains the Z-Wave engine version when it differs. Space for cloud backups is increased by 25MB on master HC3 for each connected gateway. Climate Wider range of temperature to be used in schedules. Dashboard Correct scrollbar in the main menu. Live refreshing the value on the right device control panel. Devices Possibility to upload the parameters template to Z-Wave device from .json file (ZW 3.0). Possibility to delete parameters template which overrides the official template (ZW 3.0). Extended list of official templates for Z-Wave devices (ZW 3.0). Support of scale and unit for Z-Wave devices in parameters templates (ZW 3.0). Console log of detecting the Z-Wave device and starting the adding process (ZW 3.0). New mechanism of devices calibration (ZW 3.0). Restoring the default device icon if uploaded icon no longer exists. Changes in energy data component on device advanced tab. Availability of configuration parameters based on device interfaces. Possibility of setting the virtual power metering and using it in energy panel. Support for Heatit Z-Smoke Battery version 4.1/4.2. Support for Qubino 3-Phase Smart Meter. Elero* Dedicated section in the main settings menu for Elero and Nice. Energy Panel Settings window which allows to configure more options related to costs. Possibility to choose the billing period by setting its length and start date. Possibility to set up the tariff by choosing the currency, main rate and additional rates. Possibility to set up the installation cost and installation date. New Savings tab including summary of consumption and energy balance in time. Toggle switch on General and Savings tabs to display data in kWh or using set currency. The interval for storing historical energy data changed from one hour to 15 minutes. Displaying the energy balance from the main energy meter if configured. General Setting the main energy meter available for devices with specified interface and rate type. Nice* Possibility of setting the configuration parameters. Redesigned wizard of adding new devices. Dedicated section in the main settings menu for Nice and Elero. Other Current Z-Wave engine (version 2.0) selected by default on engine selection window. Bug fixes: Access Mobile devices assigned to removed users are not deleted or reassigned. Backup Incorrect Z-Wave engine version in uploaded local backup (ZW 3.0). Dashboard Rebooting the gateway results in resetting the counter of used devices. Incorrect rounding of values with at least 2 decimal places. Devices No possibility to add custom icons after factory reset of the gateway. In some cases, removing the device from the Z-Wave network fails (ZW 3.0). For some devices setting the association fails (ZW 3.0). Incorrect multichannel reports handlings (ZW 3.0). Incorrect descriptions of parameters in Heatit Z-TRM3 device template. No possibility to switch off indications from the device for the energy panel. Elero* Device after binding is always assigned to default room. After adding and performing one action, the device is unavailable and does not respond. Energy Some data is not displayed when using the remote access connection. Energy consumed by a device with virtual power measurement is not saved each 15 minutes. Gateway Connection Master gateway does not update the device states after rebooting slave gateway. Network Wi-Fi module is always switched on after reboot of the gateway. In some cases, connecting to Wi-Fi network fails. Nice* No possibility to create and edit scene with Nice device. Notifications E-mail notifications for addresses containing a plus character are not sent. Other Z-Wave service status in Installer App is displayed incorrectly. Translations on Yubii Home are not generic and refer to FIBARO Home Center. Performance Problems with gateway start-up on large systems (ZW 3.0). Plugins Fibaro Heat Activator plugin does not work (ZW 3.0). The plugin view is not available in the mobile app. Profiles No actions available for devices (ZW 3.0). Quick Apps Error after updating the Quick App file containing a hyphen in its name. Save button is active even though there are no changes. The Quick App view is not available in the mobile app. Scenes No possibility to set scene with push notification if user with mobile device was removed. Incorrect property set when selected the disarmed condition block. Incorrect actions in block scenes for FIBARO Intercom. Update Never ending loader on devices update page when no devices to be updated (ZW 3.0). Known issues: Energy The energy data collected during the use of previous beta version (5.071) is removed. The ROI calculation functionality does not include a quantity factor. New Z-Wave engine 3.0 Overriding the temperature set in heating schedule is not possible for FGT-001. The schedule overwrite functionality of Z-Wave thermostats does not work properly. Not all Z-Wave devices are fully compatible with the new version of Z-Wave engine. In some cases, device adding/removing fails - gateway needs rebooting to retry. Gateway connection is not available in the new Z-Wave engine version. No support for FIBARO Heat Controller error notifications. * - does not apply to HC3L (Home Center 3 Lite) EDIT : la liste des différences : We would like to inform you that hot fix 5.072.25 has been released. The update improves the following: Dashboard: Incorrect rounding of values with at least 2 decimal places. Devices: No possibility to switch off indications from the device for the energy panel Elero: After adding and performing one action, the device is unavailable and does not respond Energy: Energy consumed by a device with virtual power measurement is not saved each 15 minutes. Plugins: The plugin view is not available in the mobile app. QuickApps: The Quick App view is not available in the mobile app.

Je n'y connais rien en TV/Téléphone, mais .... mince, tu as chopé le variant DELTA, tu es mal

Les condensateurs ça s'use, c'est de la chimie, ça peut finir par "cramer", alors il peuvent devenir passant (court circuit), donc il est tout à fait possible que l'usure des piles augmente à cause d'un simple condensateur. En plus, pour une station météo, exposée aux pires intempéries, c'est un scénario très probable. ça peut aussi être une diode ou un transistor, mais c'est plus rare (et le résultat serait plutôt du style : "ça ne marche plus du tout !") Cela dit, nettoyer les cosses me semble une bonne idée ça me rappelle quand je faisais ça avec les patins de voitures de mes circuits électriques... souvenirs

Tout à fait, et je n'ai jamais prétendu le contraire (ou alors je me suis mal exprimé ?) Je ne faisais pas référence au test de performance de @jang, mais à son message précédent Voilà, on est bien d'accord en fait. Désavantages de l'écriture en DB (que ça soit une variable QA ou Globale) : - lent - usure mémoire flash - mène à un crash aléatoire (à priori quand il y a trop d'écritures simultanées, j'ai l'impression que le process dédié à cette tâche dans la box le gère mal... problème connu depuis la v4 sur HC2... même si ça va mieux depuis) Donc oui, on évite autant que possible les écritures en DB. Je considère cette remarque valable pour toutes les écritures, donc aussi bien les variables que les propriétés des modules ("value", etc). Si tu regardes mes codes, tu verras que je m'applique à faire autant que possible une vérification de la valeur précédente, une comparaison, avant d"éventuellement stocker la nouvelle valeur si elle diffère. Cela permet d'afficher un petit message de log dans la console, cela réduit l'usure de la flash, les risques de plantage, et de façon assez intéressante, c'est plus rapide, bien que plus d'opérations soient impliquées. En effet, supposons que la variable/propriété ne change qu'une fois sur 10, alors 10 lecture et 1 écriture, c'est beaucoup plus rapide que 10 écritures seules. En tout cas, ce que tu stockes dans une variable QA/Globale, doit nécessairement avoir besoin d'être persistent, c'est à dire conservé au prochain reboot. L'exemple typique, ce sont les adresses IP configurées par l'utilisateur, le user/password, etc.... Il n'y a pas de raison de stocker une valeur pour le plaisir. Tu peux t'amuser à faire des petits benchmarks de performance, avec une petite boucle sur le modèle déjà partagé par @jang, pour écrire une VG, une Variable QA, un Label, etc... et la même chose en lecture... tu verras la différence flagrante de performance. Alors quelques microsecondes c'est rien, mais sur un système lourdement chargé, avec des dizaines de QA qui tournent en boucle, ça finit par faire beaucoup. PS : les labels ne sont pas persistants en DB sur HC3 contrairement à la HC2, mais leur écriture est tout de même relativement lente. En effet, chaque modification de label entraine l'émissions d'événements récupérables dans les API refreshStates et events/history, donc le rafraichissement des différentes interfaces graphiques (Web, appli mobile...)

Et ? La réponse apportée à la question est très claire, et abonde dans mon sens, puisqu'il déclare bien ses variables locales a et b avant de pouvoir les utiliser. Et @jang dit la même chose dans l'un de ses messages. Ce que précise @jang en complément, c'est que dans le cas de QuickApp:onInit(), il est exécuté après l'exécution du fichier. Du coup les variables locales ont bien été déclarées/définies. Du coup, je ne comprends pas ta remarque pour le QA Surveillance Station, car la fonction loop est déclarée comme étant un membre de la classe QuickApp, donc non concernée par la notion de "forward" (j'ai appris ce terme aujourd'hui d'ailleurs) function QuickApp:loop() end (et oui je sais, ça ne respecte pas ce que j'ai écris quelques messages plus haut, à savoir que cette boucle n'est pas censée être publiée et être partagée aux autres QA, mais c'est un vieux code, parmi mes premiers QA il y a 1 an)

Alors attention, car là aussi il y a confusion. Depuis le début de la discussion, on parlait de langage LUA, donc les notions de variables "locales" et "globales" sont propres au LUA, avec la portée inhérente. Maintenant, tu parles des variables au sens Fibaro, c'est à dire stockées dans la base de données de la box domotique : HC2, HC3, etc. => Ce qu'on appelle Variable Globale (=VG) sur le forum depuis des années. Ou plus récemment, les Variables de QuickApp depuis la HC3. Ces 2 types des variables portent mal leur nom, car elles induisent en erreur avec les "variables" au sens langage de programmation (LUA) Disons qu'elle sont un moyen de stocker des données de manière persistante, comme le ferait un logiciel sur un ordinateur/smartphone : dans un fichier, dans la base de registre, dans une base de données, etc. On lit ces données avec des fonctions getVariable() et getGlobalVariable(), qui retournent une valeur, qu'on stocke dans une variable (une vraie variable cette fois-ci, au sens LUA du terme), qu'elle soit d'une portée locale ou globale dans notre code LUA, c'est notre responsabilité de programmeur. Que la variable LUA soit globale ou locale, elle est perdue en cas de redémarrage du QA, donc il faut l'écrire avec setVariable() pour la mémoriser de manière persistante dans la box. Mais finalement, le principe est le même pour les variable de la box que les variables LUA => il faut réduire leur portée au strict nécessaire. En pratique sur HC2 on utilisait massivement les Variables Globales car on n'avait pas le choix, c'était notre seule méthode de stockage possible, et on s'en servait même pour échanger des données (communiquer) entre différents Modules Virtuels et Scènes. Sur HC3, cela est terminé, il n'y a quasiment plus aucune raison d'utiliser les Variables Globales, perso sur mon HC3 de production, j'en ai très très peu.

Reprenons : -- Cette fonction est membre de la classe QuickApp. Elle est donc automatiquement publiée et accessible depuis l extérieur du QA function QuickApp:test() self:debug("hello") end -- Cette fonction est "globale" (par défaut), c'est à dire accessible dans tous les fichiers du QA : function test(self) self:debug("hello") end -- Cette fonction est locale (car spécifié) donc accessible uniquement dans le fichier en cours (ou bloc de code en cours si la fonction a été définie à l'intérieur d'une autre fonction/boucle/etc) : local function test(self) self:debug("hello") end J'ajoute que l'utilisation des variables globales (et une fonction est en quelque sorte une variable au sens LUA) est à éviter autant que possible, car elles pourraient entrer en collision avec d'autres variables nommées à l'identique dans d'autres parties du code. Une bonne pratique est de limiter la portée des variables à leur strict nécessaire, et à les passer en paramètres des fonctions quand nécessaire. Cela devient de plus en plus important à mesure que notre code grossit, et qu'on réutilise des bouts de codes dans d'autres développements. Un autre impact a lieu également sur les performances, car les variables globales elles sont rangées dans une super table globale nommée _G que l'interpréteur LUA doit parcourir à chaque fois qu'on fait appelle à ladite variable (ou fonction). C'est par conséquent plus lent que l'utilisation d'une variable (fonction) locale. Pour une variable qui est appelée une fois par minute, ça ne change rien. Pour une boucle qui le ferait plusieurs fois par secondes, la différence devient sensible. Rappel :

Je comprends ton besoin de reformuler, mais je t'invite à oublier l'utilisation que tu fais des termes "local" et "global", car ils prêtent à confusion car ce sont des termes qui existent en LUA. Bref, tu as parfaitement compris la portée de la fonction hello() au sein du QA ou en dehors, mais ta formulation des fausse

Tu es certain ? J'avais pris cette habitude, car il me semble que dans mes tests ça ne fonctionnait pas sinon.

Tes 2 écritures sont totalement différentes. Dans la 1ère, la fonction test() n'est pas membre de la classe QuickApp. Elle est globale, c'est à dire qu'elle est accessible dans tous les fichiers LUA du QA. Mais vu qu'elle n'est pas membre de QuickApp, alors elle n'est pas accessible depuis l'extérieur (depuis un autre QA ou scène avec fibaro.call() ou via l'API HTTP) Dans la 2nde, la fonction test() est bien membre de la classe QuickApp. A titre de "best practices", je dirais que les fonctions qui doivent être publiées, c'est à dire accessibles depuis les autres QA, doivent être membre de QuickApp, tandis que les autres fonctions doivent être locales (donc avec le passage de self en paramètres si nécessaire). Pour le QuickApp:onInit(), tu le mets où tu veux, c'est selon les préférences. Souvent en codage, on retrouver les 1ère fonctions en bas du code, parce que lorsqu'elle sont exécutées, les autres fonctions ont déjà été définies préalablement, donc elles sont connues au moment de l'exécution. Exemple : function QuickApp:onInit() hello() -- Erreur : la fonction hello() n'a pas encore été définie end local function hello() print("world") end Il y a 2 façons de contourner le problème : Mettre onInit() à la fin du code : local function hello() print("world") end function QuickApp:onInit() hello() -- OK end déclarer la fonction au début du code, et la définir plus loin : local hello function QuickApp:onInit() hello() -- OK end hello = function() print("world") end

Ah ça, j'avais oublié, je vais tout supprimer, ça sera plus simple, car de toute façon je ne le met plus à jour depuis quelques années. Je parlais de la Box indiquée dans le cartouche à gauche, sous l'avatar

Si si j'avais fait ça fait mai, sur une bonne semaine, tranquillement. J'ai mis à jour la signature du coup. Il le reste juste 2 ou 3 modules virtuels sur HC2 que je j'ai pas encore récris sur HC3, du coup elle est toujours allumée.

J'ai un doute, mais je précise que j'ai déjà migré sur HC3. C'est la migration sur le moteur Z-Wave v3 que je ferai plus tard... déjà attendre qu'il sorte de Beta, puis que Fibaro propose la possibilité de migrer, puis qu'ils débuggent encore un peu, puis la fin de l'hiver.... donc l'été prochain, dans 1 an, me semble un délai raisonnable.

ah bah non, je vais pas casser une config qui fonctionne très bien. On verra, peut être dans 1 an, l'été prochain.

Oh oui Nico tu as le temps de voir venir. Déjà attendre que le moteur Z-wave passe en stable, ensuite ils ajouteront la possibilité de migrer de v2 vers v3, c'est pas avant la fin de l'année à mon avis (ils annonçaient 3 mois, mais on connait leur gestion des délais) @ericl78 non pas testé de reconfiguration, mais je n'ai pas de devices Z-Wave sur mon HC3 de test qui remontent une énergie, que des QA.

C'est tout à fait normal et conforme à ce qui a été annoncé lors de la beta précédente Pour une fois, ils ne sont pas (encore) en retard !

OK merci, voilà qui est mieux. J'étudierai ça plus tard. Tu as quel modèle d'aspirateur ? PS : pense toujours à commencer par faire la dernière mise à jour quand tu as un problème, règle valable pas uniquement pour la domotique, mais de façon générale pour n'importe quel sujet (ordinateur, téléphone, etc). Les mises à jour sont là pour corriger les bugs.

Question : tu as bien installé la version 2.01 proposée dans le topic ?

Pour y voir plus clair, dans ta fonction error() tu peux afficher le message d'erreur err : error = function(err) -- Gestion de l'erreur (connexion impossible) self:error("Echec du lancement de la requette :", err) end,

C'est une solution. Sinon avec VariableCache, je verrais bien le synoptique suivant, en 2 règles : - condition true => action : affectation de la valeur du label dans une VariableCache courante - condition : comparaison de la VariableCache courante avec la VariableCache précédente => action notification + mémorisation du nouveau label dans la VariableCache précédente

Ta syntaxe LUA semble OK, mais là ça coince du coté de ton serveur PHP, il n'aime pas la requête que tu as faite. Mais j'ai l'impression, d'après l'URL, que tu es censé envoyer des données à la page ecod2sql.php, ce que tu ne fais pas, car tu n'as rien dans options = {} Il faudrait y mettre une requête de type "POST" avec des data je suppose.

Euh.... bonne question... tu me poses une colle là

OK c'est plus clair, merci pour le log. Alors on voit bien qu'il commence à discuter, donc la communication réseau est OK. Puis.... plus de réponse.... Je vais étudier ça, mais plus tard, pas avant plusieurs jours.