Lazer

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)

Je vous met un crop dans l'angle de la caméra, snapshot que je reçois lorsque quelqu'un sonne. Je précise qu'il fait nuit noire de chez noire. Les ombres qu'on voit ne sont pas le soleil, mais juste le lampadaire de rue. Aucune assistance IR ou LED blanches. L'ancienne caméra était déjà pas mal dans son genre pour l'époque (2016), mais alors la nouvelle ColorVu 2.0 ..... je crois que ça se passe de commentaire Super content Avant / Après : Faut que je règle mieux la caméra, on voit un bout de rue, c'est pas bien

Je met ça ici car j'ai galéré pour intégrer ma dernière caméra dans la HC2. Je voyais bien l'image JPEG (en mode snapshot) sur la vignette de l'interface Web, mais invisible dans l'application mobile, et les mails reçu contenaient une image corrompue de 1 ko. Le souci c'est que Hikvision a renforcé la sécurité par défaut. Dans les paramètres de la caméra, il faut aller dans Système => Sécurité => Authentification => Authentification WEB => sélectionner digest/basic Ensuite sur la HC2 dans les paramètres de la caméra j'ai utilisé le chemin JPEG suivant : ISAPI/Streaming/channels/1/picture Et ça fonctionne enfin

Tu peux faire des boutons pour parcourir la liste des child. A chaque appui, il scanne les child, et passe au suivant (qu'il affiche dans un label pour que tu saches lequel a été sélectionné)

ça me semble pas mal

J'utilise : - Logiciel FHEM dans une VM sur mon serveur avec une clé USB pour le protocole EnOcean - Logiciel HABridge dans une VM sur mon serveur pour interfacer avec la télécommande et le hub Logitech Harmony - Module KLF-050 pour le protocole IO Homecontrol (volet roulant Velux ) Pas de 433 MHz chez moi (enfin si, la télécommande propriétaire du portail et du garage, ce n'est même pas le protocole RTS, c'est encore plus vieux... technologie d'il y a 20 ans) Le Raspberry PI, c'est attrayant, mais tout équipé, tu en as vite pour 100€, mais surtout le vrai problème c'est la carte SD, d'une durée de vie de 6 mois à 1 ou 2 ans max. C'est assez pénible.... Donc il faut soit utiliser des carte SD haute endurance, soit maitriser Linux pour tout monter en RAM et ne pas faire d'écriture sur la carte, ou bien encore... utiliser autre chose ! Il y a plein d'alternatives aux Raspberry PI, tu même format, mais équipés de mémoire eMMC qui fonctionnent comme un SSD et n'auront pas le problème d'usure des cartes SD.

euh.... je sais pas... j'utilise pas Jeedom mais il y a pas mal d'infos à ce sujet sur le forum, faut chercher un peu (ça concerne surtout la HC2, mais vu que l'API de la HC3 est quasi identique, ça doit être facilement transposable)