Lazer

Hum, je ne sais pas quoi penser de ce message d'erreur apparu dans les notifications sur la HC3 : A priori, je pense que cet événement est apparu suite au reboot violent de la HC3 survenu lors d'une micro-coupure de courant (elle n'est pas sur onduleur). Je n'ai reçu aucune notification push ni email, je viens de m'en rendre compte en me reconnectant sur la HC3 environ 2 jours après. Cela ne m'inquiète pas plus que ça, car je n'utilise pas le protocole NICE, mais bon... voilà encore un joli bug. Firmware 5.050.13 stable

Bon, fini de déconner, je ferme ce topic Le monsieur mal élevé qui ne s'est pas présenté est prié de continuer la discussion sur le topic unique.

Aeotec "aërQ" Sonde de température et d'humidité Z-Wave Plus V2 (Gen7) Aeotec ZWA009-C : version initiale Aeotec ZWA039-C : nouvelle version avec meilleure autonomie et mesure plus fiable du niveau de pile Z-Wave Plus V2 (puce Série 700 / Gen7) Mesure la température de -10 à 65°C (+- 1°C) Mesure l'humidité de 10 à 95% Mesure le point de rosée de -10 à 65°C (+- 1°C) Indique le risque de moisissure via son voyant LED intégré et vers le système domotique Peut commander par association directe jusqu'à 5 appareils par groupes : sur température haute, température basse, humidité haute, humidité basse (seuils et commandes configurables) Peut transmettre à d'autres équipements la température mesurée (5, en plus de la box domotique) Seuils de transmission des mesures configurables : Températures : de 0,1 à 100°C Humidité : de 1 à 20% + cycliques toutes les 15min à 18h Communications sécurisées S0 ou S2 avec cryptage AES (grade bancaire) Installation simplifiée par flash code "SmartStart" Garantie 2 ans Indice de protection : IP20 => normalement prévu pour l'intérieur, aucune protection contre l'eau, à ne surtout pas utiliser sous la pluie Compact : 35 x 35 x 18 mm Alimentation par pile lithium 3V CR2477 fournie pour une durée de vie de 2 ans : Page officielle : https://aeotec.com/z-wave-home-automation/temperature-humidity-sensor.html Manuel : https://aeotec.freshdesk.com/support/solutions/articles/6000227918-aërq-temperature-and-humidity-sensor-user-guide- Spécifications techniques : https://aeotec.freshdesk.com/support/solutions/articles/6000227919-aërq-temperature-and-humidity-sensor-technical-specification- Disponibilité : début 2021

Bien vu, merci pour l'astuce

Étrange.... peut être l'un de tes codes LUA qui est parti dans une boucle infinie ?

Justement, de ce que j'ai compris, le thermostat est juste ... inutile ! Le thermostat d'ambiance dans le salon, c'est une relique du passé, à une époque où les logements étaient plus petits, qu'il n'y avait pas de têtes thermostatiques sur les radiateurs (juste un robinet mécanique standard) Donc le thermostat régulait la température dans la pièce principale... et tant pis pour la température dans les autres pièces qui étaient forcément plus froides (pour les chambres ce n'est pas un souci, pour la SDB c'est problématique) Aujourd'hui avec les têtes thermostatiques, tu vas régler la température indépendamment dans chaque pièce de la maison, y compris le salon, dans lequel il faut supprimer le thermostat d'ambiance. La logique derrière ça étant que la chaudière doit être toujours en fonctionnement pour que les têtes thermostatiques puissent réguler. Conséquence, une tête dans tout le réseau doit être toujours ouverte à fond (pour que le circulateur de la chaudière ne force pas), en général la salle de bain, qui devient la pièce la plus chaude de la maison. L'optimisation ultime, les 1% d'économies restantes, c'est justement de contrôler la chaudière avec un relai (FGBS, ou FGS, au choix) ou son circulateur (présence éventuelle d'un bypass). Il me semble que c'est @Yohan qui avait super bien expliqué le principe, avec @Nico et quelques autres. Les thermostat connectés à la mode que tu vois partout (Nest, Netatmo, etc), ça sert surtout pour ceux qui ne veulent rien domotiser. En gros, tu remplaces le thermostat d'ambiance du salon de grand-mère par ce thermostat connecté. Qui permet de faire des économies / améliorer le confort par la simple programmation des horaires (optimisé avec algo de détection de présence, et contrôle à distance depuis le smartphone pour le retour de vacances). Mais ça ne résout en rien le problème du chauffage des autres pièces de la maison, et comme tu le constates, cela empêche carrément le fonctionnement des têtes thermostatiques... donc il ne faut pas utiliser de thermostat central/d'ambiance/connecté quand on a têtes thermo.

Parfaitement de circonstance pour le réveillon seul à la maison

"commerciale" : tout est dit. Ce module va juste te permettre de piloter ta chaudière en mode contact sec. Ce module n'a aucune intelligence, et ce n'est pas lui qui va gérer ton chauffage. Il y a donc une grosse réflexion en amont sur la façon de gérer ton chauffage. Le pilotage de chauffage central est bien plus complexe que le chauffage électrique, perso je ne saurais pas t'aider, mais il y a déjà eu plusieurs discussions assez avancées sur le sujet sur le forum il y a quelques années, je te laisse les retrouver. De mémoire et en résumé, ça donnait : il est compliqué de gérer son chauffage central à la fois par les têtes thermostatiques + chaudière, mais c'est faisable..... même si le gain est très faible, car les têtes thermostatiques font 99% du boulot.

Il me plaît bien ce ZWA009 Vivement qu'il soit dispo

Tiens tiens... Bienvenue sur le forum @jluc2808

Tu fais comme tu le sens, mais je reste persuadé que toute la logique du réveil est déclenchable depuis le parent. Bon l'essentiel c'est que tu t'y retrouves dans ton propre code.

Oui voilà plus dans l'esprit de ta dernière suggestion. Cela dit, je pense que tu peux simplifier, pourquoi avoir Func1 et Func2, alors que tu pourrais en voir une seule et passer les arguments en paramètre. Enfin, je veux dire, si Func1 et Func2 font la même chose, alors il faut les regrouper en 1 seul avec un code commun, et des arguments en paramètre. Si elles font des choses différentes, dans ce cas, tu peux garder des fonctions différentes. Mais je maintiens ce que j'ai dis plus haut. Il ne devrait pas y avoir de Settimeout dans la classe enfant. Le settimeout devrait se faire dans une loop du parent (classe QuickApp), qui à chaque passage de boucle appelle une fonction des enfants : MyChild:update() ou un truc dans le genre Je pense qu'une bonne pratique, c'est de laisser l'intelligence et l'orchestration des actions dans le parent. Et ne donner aux enfants que des tâches le plus basiques possible. Cette bonne pratique éviterai les confusions avec des variables locales je pense. Bref, c'est une toute autre façon d'organiser son code

Ah oui exact mais tu as un souci avec self, au moment où tu appelles les fonctions locales, le self ne correspond plus à chaque child je t'ai dis que je n'aurais pas du tout écrit ces fonctions de cette façon là.... j'aurais simplement une méthode de WAKEUP qui s'appelle elle-même avec settimeout(), de cette façon tu es certain que self pointe bien sur le bon child en cours. Cela dit, il me semble que @jang nous avais dit un jour qu'un child n'est pas censé se mettre à jour tout seul. Tout cela devrait être supervisé par le parent, dans directement dans une méthode de QuickApp. A lui de parcourir les children et de les mettre à jour. C'est en tout cas la technique que j'utilise dans tous mes QA, et je n'ai jamais eu de souci de "mélange" de child.

je pense que c'est normal. Premier appel de wakeStart() : tu définies ta variables locale ainsi : local idLight = self:getVariable("idLight") Qui va prendre la valeur 731, et qu'il va conserver... jusqu'au 2nd appel de wakeStart(), moment où cette même variable locale sera écrasée avec la valeur du 2nd child : 732 Ensuite, il conservera indéfiniment 732 Il faut te méfier quand tu mélanges des variables locales avec plusieurs instances d'objets, chacun accessibles au travers de leur propriété self. Je n'aurais personnellement pas du tout écrit tes fonctions ainsi, car elles portent à confusion. Dans l'immédiat, tu peux essayer de remplacer la variable local par une variable stockée dans le child : self.idLight = self.idLight or self:getVariable("idLight") Déjà c'est bien plus efficace, car on conserve sa valeur tant que le QA n'est pas redémarré, donc on évite des appels inutiles à self:getVariable() (assez lent, puisqu'il va parcourir l'API) Ensuite, dans tes fonctions, tu utilises self.idLight, tu es certain que cette variable est associée à chaque child, indépendamment des valeurs des variables locales.

Bienvenue sur le forum

Pas tout à fait math, json, etc... font partie du LUA natif fibaro est un objet qui porte des fonctions spécifiques à la HC3 : fibaro.call(), fibaro.debug(), etc... Voir l'exploration des objets du topic : Tu y retrouveras Device, QuickApp, QuickAppBase, QuickAppChild ... qui sont des classes Element très intéressant, tu verras " quickApp ", qui est l'objet représentant notre QuickApp en cours, instancié à partir de la classe QuickApp (différence de majuscule) Justement, c'est exactement ce qu'on fait quand on crée des QA enfants : on définie notre propre classe qui hérite de QuickAppChild : class 'MyChild' (QuickAppChild) Ce qui nous permet d'ajouter nos propres fonctions personnalisées. Chaque objet child instancié depuis notre classe personnalisée, est stocké dans le tableau self.childDevices nul part.... elles ont leur propre moteur LUA qui est plus limité, il embarque moins de fonctions. Je ne suis même pas certain que le support des Classes existe dans les scènes, il faudrait tester pour le sport (mais quel intérêt ?)

En effet UDP et WebSockets ont été ajoutés dans des précédents firmwares.

Les QuickApps apparaissent bien dans les profils. Si tu ne les vois pas, c'est qu'ils doivent être mal typés. Ils ont surement le type par défaut com.fibaro.genericDevice ou deviceController

Je m'y attendais Mais j'ai un doute, cette option ne concerne que le cloud backup ? Ou également le backup local ? Parce que mon script sert à faire des backups locaux sur le NAS, où on n'est pas vraiment limité par la place disponible (disons qu'on n'est pas à 50 Mo près sur des disques de quelques To) De toute façon je vais faire une nouvelle version prochainement avec d'autres améliorations.

Non la table et la classe sont 2 choses bien distinctes C'est ce que j'ai essayé de te dire plus haut. La table, c'est facile à comprendre, c'est un mécanisme de base en LUA (et même global en LUA car tout, sans exception, est rangé dans des tables). Cela permet de "ranger" les fonctions qui vont ensemble, avec quelques variables de différents types (string, number, etc... ou encore des tables contenant d'autres choses). Une pseudo programmation orientée objet. Le mécanisme de "class", c'est de la vraie programmation orientée objet. Une classe est une représentation abstraite, qui décrit un concept, lequel sera ensuite instancié en objets distincts. Ce qui est intéressant, ce qu'une classe peut "hériter" d'une autre, et cela à l'infini. Prenons un exemple : Je crée une classe "être vivant" dans lequel je décrit le mécanisme des cellules, etc. Ensuite on a une classe "mammifères" qui hérite des propriétés de la classe parent "être vivant". Inutile de redécrire les cellules, cela a déjà été fait. Mais on va y ajouter la description du mode de reproduction, avec différentes fonctions comme accoucher() etc. Ensuite, on crée une classe "humain", avec des fonctions comme marcher(), etc. Puis 2 classes "homme" et "femme". Voilà, on a tout ce qu'il faut. Maintenant on va pouvoir instancier environ 3.5 milliards d'"objets" hommes, et autant de femmes objets (désolé elle était trop facile .... pas taper) Chaque objet aura des attributs (variables) qui lui seront propre : l'age, la couleur des cheveux, etc. Inutile de redéfinir les fonctions, cela a été fait au niveau des classes. Appliqué à la HC3, le principe de la programmation objet est utilisé pour décrire les modules, desquels on dérive les différents types et sous-types de modules (sensor => binary sensor => smoke sensor), mais également les QuickApps... et leurs enfants ! C'est pour cela que lorsqu'on veut utiliser des child devices, on doit créer une classe (on lui donne le nom qu'on veut.... MyClass dans l'exemple de Fibaro), et on précise de quelle classe parent elle hérite : QuickAppChild. Sachant qu'elle hérite elle-même de la classe QuickApp. Cela explique pourquoi dans un child on peut appeler des fonctions comme self:debug() puisque la fonction a été héritée de QuickAppChild qui a elle-même été héritée de QuickApp, qui l'a elle-même été héritée de ce qu'il y a au dessus (on ne le sais pas précisément, même si on peut le deviner en cherchant) On n'a jamais eu besoin de déclarer cette fonction self:debug(), pourtant on peut l'utiliser aussi bien dans notre QuickApp parent que nos QuickAppChild enfants. Mais on peu aussi décider de la redéclarer pour en modifier son comportement, c'est tout à fait possible... on parle alors de "surcharge". Revenons à notre code utilisateur personnel dans le QuickApp. A priori, pour 99% de nos codes LUA, on a aucun intérêt à utiliser le mécanisme de classes proposé par Fibaro. Pour la simple raison qu'on n'a pas besoin d'instancier plusieurs objets. Si je reprend mon onduleur, j'ai besoin d'un seul objet SNMP, donc aucun besoin d'en faire une classe instanciée en plusieurs objets distincts. Idem pour Surveillance Station, Kodi, etc. Là où on a besoin d'instancier des objets distincts, c'est pour les modules enfants... ça tombe bien, on utilise justement QuickAppChild comme imposé par Fibaro. Je me suis permis d'utiliser le mécanisme de class de Fibaro pour GEA car j'avais besoin d'instancier 2 objets distincts : l'instance qui tourne en permanence, et l'instance instantanée déclenchée sur trigger. C'est une autre façon (complètement différente) de gérer le multi-instance comme on l'avait pour les scènes sur la HC2. Et je dis bien complètement différente, ça n'a absolument rien à voir sur plein d'aspects. Mais attention, ce mécanisme de class n'est pas du LUA standard, c'est une implémentation spécifique de Fibaro. D'ailleurs quand tu fais un type(...) d'une classe ou d'un objet instancié depuis une classe, on n'obtient pas "table" mais "userdata". Car c'est un objet propriétaire, non standard LUA, qui a été codé en langage C par Fibaro. Petit inconvénient, on ne peut pas parcourir la classe ou l'objet avec une boucle for k,v in pairs(...) comme on le ferait pour une table, impossible donc de découvrir ce qu'il contient. Pour finir, ça rend le code moins portable (qui sait comment sera faite la HC4). Comme je le disais hier, j'étais bien content avec SNMP, j'ai pu porter le code en un temps record car c'était du LUA standard (sauf l'appel aux fonctions spécifiques UDPSocket) Et je dois aussi dire que malgré l'immense complexité de GEA, son organisation structurée m'a permis de le porter sans grandes difficultés, là où tout le monde pensait qu'il serait impossible de faire tourner GEA sur HC3. Bon OK ça n'a pas été simple pour autant.... Bref, je ne te conseille pas l'usage des classes dans tes codes LUA en dehors de l'utilisation qui nous intéresse : la gestion des QA enfants. Personnellement, je n'approuve pas. Dans main, je préfère y laisser tout ce qui a trait au QuickApp, donc typiquement la gestion des boutons, sliders, le onInit(), et la boucle principale (celle qui est relancée à intervalle régulier avec settimeout()) Et comme je le décrivais précédemment, on utilise les fichiers pour y ranger le reste : les outils génériques, les outils spécifiques (gestion de l'API du NAS, de Kodi, de l'IPX800, du protocole SNMP, etc)... Et dans chaque fichier, on y trouve une table (assimilable à un objet, même si comme je viens de l'expliquer c'est un faux objet) qui permet de regrouper les fonctions et les variables locales. Mécanisme simple et efficace : un objet = un fichier. Je trouve cela simple à maintenir, et la réutilisation partiel du code dans un autre QA est simplifiée : il suffit de reprendre tout le contenu d'un fichier (je pense à mes "tools" notamment) Mais c'est juste ma façon de voir les choses, je ne suis pas programmeur de métier. En résumé il propose un mécanisme pour charger des sous-modules dans les différents fichiers attachés au QA, permettant de gérer les situations qui pourraient se produire dans certains gros QuickApp communautaire développés par plusieurs personnes, dans lesquels on pourrait potentiellement avoir plusieurs librairies portant le même nom. En ce qui me concerne, je pense notamment à ma fameuse librairie tools donc le nom est tellement générique qu'il a également été utilisé par Steven dans GEA. Du coup se retrouver avec 2 tables appelées tools dans le même QuickApp, ça coince. La solution de jang permet de charger une librairie avec un nom personnalisé utilisable dans le reste du QuickApp. Mais j'avoue que c'est assez avancé, j'ai lu ça hier soir et j'ai eu un peu de mal à comprendre, surtout arrivé vers la fin. Et je trouve relativement lourd à l'usage.... parce que je n'ai pas l'habitude de cette manière de coder. Je ne sais pas si je vais l'adopter... à suivre

@Dragoniacs oui en effet, il faut se faire une liste des enfants avec un identifiant unique pour chacun afin de les identifier correctement, liste à reconstruire à chaque redémarrage du QuickApp, à chaque ajout, ou suppression d'un child device. Après selon les cas, l'identifiant utilisé sera différent. Par exemple pour l'IPX800, on identifie par le type et le numéro du port, par exemple D0, A1, R2, etc Pour Surveillance Station, c'est tout simplement l'ID de la caméra qui est retourné par l'API de DSM. Etc.

@Dragoniacs tu as testé le réimport de ton QA thermostat du coup ?

A priori les listbox existent dans les QA, mais on ne peut pas encore les utiliser. Sauf à hacker les QA, c'est à dire en les injectant directement dans leur JSON.... sauf que c'est déconseillé car tu ne peux alors plus modifier le design du QA via l'interface Web normale. Bref, patience, la personnalisation des QA finira bien par arriver, en attendant il vaut mieux se contenter de design simples et ne pas perdre trop de temps là-dessus.

ouais j'ose plus sortir

Comparaison de la sensibilité en basse lumière de ces 2 caméras, sachant qu'elles ont toutes les deux un capteur de 4 megapixels : DS-2CD2642FWD : 0,01 lux DS-2CD2T47G2 : 0.0005 lux Cette nouvelle caméra est donc 20x plus sensible que l'ancienne. Pour info mes DarkFigher en 2 megapixels sont données pour 0.005 lux (soit seulement 2 fois plus sensible que ma vieille DS-2CD2642) Donc les ColorVu 2.0 sont 10x plus sensibles que les Darkfighter sorties il y a 3 ans. Attention ces chiffres de sensibilité varient pour chaque capteur. Pour une génération de capteur donnée, plus il y a de pixels, moins c'est sensible (comme sur un appareil photo)