Lazer

Par contre ils n'ont toujours pas résolu le bug que j'ai remonté sur le forum GCE, à savoir que l'EcoDevice RT2 "oublie" de compter les impulsions de certains compteurs. J'ai échangé avec le support, ils ne savent pas s'il vont pouvoir corriger le bug.... c'est pas qu'ils ne veulent pas, c'est que la nouvelle structure du code en v3 a considérablement ralenti les temps de traitement internes, donc il n'a pas le temps de compter toutes les impulsions. C'est complètement bloquant pour moi, en pratique j'ai un EcoDevice qui est devenu inutilisable, il ne me sert plus qu'à remonter la téléinfo.... C'est très fâcheux...

Alors, sans prendre le temps d'étudier ton code, il faut que tu comprennes la notion d'asynchronisme. Le code en cours d'exécution se termine, puis un nouveau thread est démarré qui va prendre le relai, etc. Donc il faut enchainer les appels de fonction dans le retour de la fonction success() à chaque appel. Etc. Et surtout ne jamais utiliser de sleep() Exemple ici pour des requêtes HTTP, mais c'est pareil pour le TCPsocket, sauf que tu dois faire plus d'enchainement connect => success => transmit => success => receive => success => disconnect...

Et bien... cette version Alpha aura au moins eu un mérite, c'est de me faire apparaitre mon premier message "Le système a récupéré d'une erreur inattendue" : Du coup... on en parlait récemment, pas sûr que ça soit un problème hardware comme je le suggérais, vu qu'une simple mise à jour de firmware permet de faire apparaitre ce message. Je laisse tourner encore quelques jours, on verra si le problème se reproduit.. Puis je ferai un retour arrière, et on verra si le problème disparait. Heureusement que c'est sur ma box de test.

à payer les retraites des "old" C'est un QuickApp enfant, ça permet de puis un QuickApp parent de gérer plusieurs enfants, avec le même code LUA. Exemples : Une station Netatmo : un module parent qui va chercher les infos sur le cloud Netatmo, et qui met à jour tous les enfants, avec un enfant pour chaque capteur : température, humidité, pression, etc

Attention aux mises à jour en beta, surtout celle de ce week-end, elle est bien buguée et a été retirée par Fibaro.

Tellement de questions... sans raccord avec le sujet du topic. Difficile de suivre Tu devrais ouvrir un nouveau sujet pour chaque thème abordé... ou poser tes questions sur des topics déjà existants, car tous ces sujets ont déjà été traités. En vrac : Un label c'est fait pour afficher une info pour l'utilisateur, mais pas pour stocker une information (car le label est non persistant = sa valeur est perdue en cas de redémarrage du QA). Partant de là, lire un label n'a aucun sens (même si c'est quand même possible) Pour stocker une info en mémoire non persistante, tu as les variables LUA (local, globale, membre d'une table self, etc), ou bien les variables du QA (dans l'onglet dédié), ou encore les propriétés du QA (exemples : value, power, energy, batterylevel, etc). Enfin il existe les variables globales de la HC3, assez peu utilisées depuis qu'on peut stocker des variables au niveau des QA directement. La portée des variables en LUA, ou plus généralement dans n'importe quel langage de programmation, est un concept à bien maitriser pour ne pas avoir de mauvaise surprise Il y a déjà 1 ou 2 topics à ce sujet sur le forum. Pour enchainer les connect/transmit/receive/disconnect, il faut manier les appels asynchrones de fonction. Pas évident à appréhender, et certainement l'un des aspects les plus complexes de la programmation LUA sur HC3.

Oui, boitier maçonnerie de forme carré. Pour la profondeur, je ne sais plus bien... je pense que 40mm doit est suffisant, mais si tu n'as pas de dominos qui rajoutent de l'épaisseur derrière.

C'est quoi une "vraie" régulation pour toi ? PID ? J'en doute...

5.131.52 BETA Important Notice Installation of this version is not recommend for systems using Gateway Connection feature. Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Main features: 1. New way of controlling devices from Dashboard sidebar Completely redesigned control of color controllers. Support of color temperature setting for the Zigbee devices. 2. New predefined scenarios designed to control lights based on time conditions and gates status What's new: Climate Added possibility to assign temperature sensors for climate zones. Added battery level indicators on devices tiles. Dashboard Possibility to add devices from the dashboard. Devices Optimised procedure for adding devices for all protocols. Improved UI/UX and performance for device page filters. Added filters clearing mechanism when leaving the page. Added the description field for every device type. Redesigned family of devices view. Energy Modified page layout for energy meters configuration in panel settings. Gateway connection Added an option to define Slave IP address manually. Added additional redundancies for unexpected changes in network configuration. Nice* Improved support for OXIBD status updates. Added generic support for legacy Bidirectional shutters. Improved support for device specific notifications. Other Improved algorithm for gateway overheating notifications. Minor UI/UX improvements. Plugins Added support for pulling the latch for the Tedee door lock. Improvements for Heat Activator plugin. Quick Apps Added support for the Base Shutter device type. Scenes Added the filters for Scenes page. Added "tolerance" option for Energy Panel block scenes. Improved blocks content loading performance for large systems. Added the description field for every scene type. Changed the order of steps for Scenarios. Update Added possibility to update all devices. Added additional warning before upgrading to the beta version of the hub. Zigbee Improved generic support for lights and color controllers. Z-Wave Added handling of suspended device interview during the adding procedure for battery-powered devices.** Support for different revisions of the Aeotec Multisensor 6. Support for the ZW800 series MCO IR2900 thermostat. Support for the Everspring SP103.** Bug fixes: Climate The zone control freezes if the last setpoint is set at 5:00am. Devices Issues with the display of some configuration parameters values. Elero* The RolSolar device is incorrectly marked as disconnected. Using favorite positions in group actions does not work. Energy Energy charts are malformed occasionally. Negative energy consumption data in the panel after clearing the energy data in some cases. Negative power consumption values for "Grid consumption" setting in some cases. FTI No masking of Wi-Fi password during the first configuration on Firefox. Gateway Connection Connection issues in specific network configurations. Nice* Losing possibility to control devices in some cases. Fixed issue with binding some mono-directional devices. Custom icons for mono-directional devices not visible. Other Added possibility to enable remote access for support from recovery system. Standard user cannot remove interactive push. Issues with controlling the linked-device thermostat in some configurations. System crash while deleting a non-existing notification. Wrong time in history after the change from winter time to summer time. Adding more than one Other device by clicking the add button excessively. The state of devices is not refreshed when pressed run scene button without refreshing the page. Other UI/UX fixes. Plugins Lack of live preview for Helios 2N plugin. Profiles Incorrect display of climate panel settings. Incorrect display of sliders in profiles settings. Quick Apps Secret variable value visible in the webUI after saving. Scenes Elero RolMotion blind is controlled even if excluded from a simple scenario. Incorrect display of sliders in block scenes. Cannot edit Scenarios via mobile app in remote connection. Zigbee Wrong time unit during the adding process. Z-Wave No possibility to update Z-Wave devices added in Security mode. Lack of handling unsolicited reports from devices using CC Basic.** Issues with updating devices from file in some cases.** Incorrect default role for the Zooz ZAC36 valve. Improved adding procedure when using S2U security level.** The exclusion process cannot be closed after an error has occurred. Known issues: Z-Wave Engine 3.0 Some Z-Wave devices are not fully compatible with the new version of Z-Wave engine. Gateway connection is not available in the new Z-Wave engine version. * - does not apply to HC3L (Home Center 3 Lite) ** - applies only to Z-Wave Engine 3.0

Oui, le A8-9, toutes les mesures sont OK

data.php ne permet pas de créer la table, mais d'accéder aux données dans la table (lecture/écriture) Il faut utiliser phoMyAdmin pour copier une table existante, par exemple domocharts_water_day Le reste des pages est facile à modifier, c'est du copier/coller. Là où tu vas galérer, c'est pour trend.php, la page qui sert à générer les données historiques dans les tables _day et _month. Car les requêtes SQL pour water sont parmi les plus complexes.

Là c'est direct dans la table water, elle sert à ça. Et il faut utiliser l'unité litre, suffit de faire la multiplication par 1000. A notre niveau, quand on manipule des unités de volumes, on est plus sur des litres que des mètres cubes. Perso je prend un douche de 50 litres, ou j'arrose le jardin avec 100 litres, mais je n'ai jamais pris de douche de 0,05 m² Et le débit de mon robinet est de 15 litres/minute, c'est plus pratique que 0,015m3/minute. D'ailleurs tous les compteurs d'eau sont en litres. Voire en quart de litres.

Oui la table self.childDevices est automatiquement générée.

Pourtant tu es le premier à réinventer la roue Attention quand même, cette fonction dans ma librairie tools facilite la création de QA enfants, mais ne permet pas de les gérer (identifier). Donc ça ne répondait pas aux questions posées.

@mprinfo c'est bien ce que @Bloug fait, il affecte la variable au QA enfant juste après sa création, regarde sa fonction QuickApp:createChild_BSS_3() @Bloug en effet, je pense que ta variable self.sondes est inutile.

Voilà, mprinfo a tout dit. Et si Nappe_1 ça ne te plait pas, tu peux utiliser le raccourcis N1, mais ça sera pareil, dans les 2 cas c'est une string.

Mais pourquoi "child n°1" ? Tu n'as pas une meilleure façon d'identifier tes modules ? Cela dit, un index de table nommé de la sorte est possible, c'est une simple chaine de caractères. Et tu parcoures la table avec pairs(ma_table)

mais ça ne sert à rien de stocker son propre ID dans ses variables, puisque l'ID est déjà une propriété connue du child : Forcément du coup... Oui je crois Mon message précédent n'était peut être pas clair, mais il te faut un moyen d'identifier tes enfants qui ne soit pas leur propre ID. Sinon c'est le serpent qui se mort la queue.

Il faut bien, parce que si j'attends après les retraites... comment dire... je suis mal barré Le gaz : - ne servait qu'à la gazinière dans le cas de l'appart dont il était question, et avantageusement replacée par une plaque à induction, électrique donc. A noter que le chauffage central est à gaz, et ça je ne peux rien y faire (et le pire, ça me coute 2 note de DPE.... le diagnostiqueur dit que replacer la chaudière gaz par une PAC ferait gagner direct 2 notes, c'est fou) - nécessite une installation complexe, couteuse, recours à un prestataire extérieur... - est dangereux, risque de fuite et d'explosion - pollue fortement (CO2 dans l'air extérieur, réchauffement climatique, tout ça...., et risque de CO dans le logement, asphyxie, mort, tout ça...) - n'est pas extrait en France, donc dépendance forte à des pays... qui ne sont pas franchement les plus politiquement stables ni les meilleurs partenaires commerciaux qu'on puisse avoir, donc forte incertitude de disponibilité à l'avenir. - est une ressource fossile, donc un jour, de toute façon, il n'y en aura plus. Bon toi tu t'en fous, tu seras mort avant, et moi aussi probablement... donc à la limite d'un point de vue purement égoïste on pourrait presque balayer cet argument - coute de plus en plus cher, j'ai failli l'oublier ! Justement c'est la conséquence de ce qui a été dit au dessus. Bon après on trouve toujours pire, y'a des gens qui ont encore du fuel... bon courage pour s'en débarrasser (surtout la cuve)

Mais en fait, y'a encore des gens qui ont des compteurs de gaz ? Je viens de faire rénover un appart, 1er truc que j'ai fait, c'est supprimer le raccordement au gaz (et j'ai gouté au bonheur des procédures de chez GRDF.... tu prends RDV 1 fois pour que le mec vienne retirer le compteur, puis tu prends RDV une seconde fois pour que le mec viennent retirer le tuyau.... le délire). Puis après on a attaqué la démolition des murs , plomberie, électricité, et toute la réno neuve. Sérieusement, désolé, mais je n'ai pas de gaz chez moi, je n'y ai pas pensé, et je n'ai pas souvenir que ça m'ai été demandé précédemment. Donc comme dit plus haut, si tu veux faire les choses proprement : créer une nouvelle table dédiée dans le DB, et retoucher légèrement les pages HTML, Javascript, et le code LUA de DomoCharts (copier/coller des lignes pertinentes et tu remplaces water par gaz par exemple) Rien de bien méchant. Ou bien tu attends une nouvelle version, mais ça risque de prendre pas mal de temps vu ma liste de choses en retard...

"armed" non plus du coup. "tamper", c'est la protection anti-violation du capteur. Traditionnellement sur un capteur d'alarme, c'est un contact qui touche le mur pour détecter l'arrachement du capteur. Sur les modules Fibaro, le temper est un détecteur de déplacement intégré (avec un accéléromètre) pour détecter si le FGMS a été saisi à la main par exemple (ou shooté avec un objet contondant...). Ou bien si le capteur d'ouverture de fenêtre a été... ouvert (le petit capot plastique)

Des quoi ? Il faudrait soit créer une table pour les m3, et tout ce qui va avec (modifier légèrement les pages HTML, Javascript, et le code LUA de DomoCharts) Ou bien faire la conversion en litre comme le propose Bloug, ça reste une unité de volume, il suffit de faire la multiplication par 1000.

ça n'existe plus. Le panneau d'alarme de la HC3 fonctionne comme une vraie alarme, contrairement à la HC2 qui avait une logique étrange. Tu mets des capteurs dans des zones d'alarmes (appelées partitions), et tu armes les zones selon tes besoins (et non pas les capteurs individuellement)

Ta variable self.devicesMap de type table n'existe pas quand tu essayes de lui affecter une valeur, donc il faut commencer par l'initialiser, quelque part dans ton code. Par exemple dans QuickApp:onInit() : self.devicesMap = {} La "map", ou cartographie en bon français, c'est à toi de la créer. Avec ta variable self.devicesMap justement. Ce que te fournis Fibaro au travers de la variable prédéfinie self.childDevices, c'est juste la liste des devices identifiés par leur ID. Donc insuffisant pour notre usage. C'est pour ce qu'on se crée une autre variable nous permettant de "mapper" (=associer) l'ID du device avec un autre paramètre nous permettant d'identifier facilement quel child device correspond à quoi. Par exemple pour les quelques QA que j'ai développé, ça peut être l'ID d'une caméra dans Surveillance Station, ou bien l'identifiant du port d'entrée/sortie d'un IPX800, ou bien l'identifiant des modules d'une station Netatmo, etc... donc à construire au cas par cas selon l'usage considéré. Cela pourrait aussi être basiquement un texte qui définie l'usage du QA enfant : "temperature", "humidite", etc Identifiant à stocker dans une variable du QA enfant (avec self.setVariable(), ou encore child.setVariable(), enfin ça dépend de la technique que tu utilises pour manipuler tes QA enfants)

C'est quoi d'habitude l'unité de comptage du gaz ? Des mètres cubes ? Ou directement des kWh ?