Lazer

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)

Tu as bien résumé je pense. Si tu veux piloter tes volets, il faut passer par une box en passerelle.... Zibase, oui bien Jeedom et HASS avec un RFXcomm

Il est possible que l'une de tes scènes consomme réellement un max de mémoire, et que le problème revienne. Je ne les connais pas (à part Unifi présence)

Étrange, je n'ai jamais vu ça ! Tu as essayé de rebooter la box ?

La syntaxe me semble correcte Le true, c'était juste pour que la condition soit toujours vraie, donc que GEA déclenche les actions sans condition. L'idée c'est de faire des tests unitaires pour isoler le problème, comme toujours quand ça ne fonctionne pas.

Ce sujet de l'ID qui change est un problème chez Fibaro. Il manque toujours un truc sur la HC3, c'est la possibilité de se réaliser une vraie librairie d'outils partageables entre tous les QA. Difficile à stocker ça dans un QA quand tu sais que tu es lié à son ID.... qu'on ne peut pas choisir ! Il faudrait pouvoir nommer les QA (ou scènes) de manière unique pour les appeler sans ambuiguité depuis n'importe quel code LUA. L'ID on ne le choisit pas (et il change si on exporte/importe le module) Et le nom n'est pas unique car plusieurs QA peuvent porter le même nom. Il manque aussi un autre élément fondamental, c'est la possibilité de récupérer la valeur de retour d'une méthode appelée dans un autre QA. Là encore, @jang a proposé une solution, mais que je trouve un peu lourde, j'aurais préféré un truc prévu en standard par Fibaro, plus facilement maintenable. Donc en attendant, on organise notre code avec les fichiers, et l'appel de méthodes avec paramètres entre QA, c'est déjà un gros progrès par rapport à la HC2.

Performance : il est plus rapide d'appeler une fonction dans le QuickApp lui-même que dans un autre QuickApp (car cela va alors passer par l'API, communication entre processus différents, etc.... opérations relativement lourde) Mais il faut relativiser, ce serait un problème si tu envoyais 10 notifications par seconde. En pratique, des notifications, c'est de l'ordre de quelques unes par jour... donc il n'y a aucune souci de performance en pratique. Ce qui nous amène à la maintenabilité, et c'est bien là le plus important. Organiser son code LUA dans des fonctions dans des "objets" dans fichiers dans des QuickApps dans la box domotique L'essentiel est de s'y retrouver, de pouvoir facilement utiliser un bout de code nécessaire entre plusieurs QuickApps, etc. Je ne sais pas s'il y a une meilleure façon de faire. Mon objet de notifications, tu peux le voir dans quelques QuickApps (Network Monitor, Onduleur Eaton, etc), j'ai préféré la copier/coller. Elle me sert à uniformiser l'envoie d'email, notification push, etc. dans mes différents codes. Et je ne dépend pas d'un QuickApp externe (dont l'ID pourrait changer) pour envoyer des notifications aussi basiques que email et push Mais pour l'envoi des SMS, elle se base elle même sur un QuickApp dédié, pour JPI. Car j'ai considéré que JPI étant une application externe sur un smartphone externe, cela nécessité un QuickApp dédié. Et facilement partageable en plus, un QuickApp utilisable par tous en tant qu'outil prêt à l'emploi.

Exactement Basic d'un côté : lignes 10 20 30 etc Java de l'autre : full objet

En fait, QuickApp, tools, KODI, etc.... ce sont tous des tables contenant des fonctions, et leur utilisation permet de faire de la programmation orientée objet. Même si ce n'est pas de la vraie POO au sens C++ du terme, cela s'en approche pas mal. Par exemple, ma pseudo classe SNMP utilisée pour l'onduleur (en réalité une table avec des variables et des fonctions) a été portée en un temps record sur la HC3, il m'a juste suffit de modifier les appels aux fonctions propriétaires (sockets UDP), et la classe entière devenant utilisable comme par magie dans un QuickApp. Pour GEA j'ai poussé le concept plus loin encore, puisque j'utilise le mécanisme de "class" proposé par Fibaro et qu'on utilise pour les QA enfants. Je l'ai adapté à GEA, j'en ai fait une classe, ce qui me permet d'en instancier 2 objets, avec chacune leur constructeur (la fonction __init()), et leur espace mémoire propre et bien distinct. Pour le coup cela devient propriétaire car le mécanisme de class proposé par Fibaro est spécifique à la HC3. Mais l'esprit est totalement dans le style POO.

Oui il faut le déclarer en tant que table {}, avant de pouvoir y ajouter des functions(), ou n'importe quel autre variable de type string, number, boolean, etc Là encore, c'est du LUA pur, j'en usais largement dans mes VD sur HC2. Et pour tout dire, je me suis inspiré à l'époque des codes des maitres @Krikroff et @Steven Le LUA a ceci de génial que tout est "rangé" dans une table. Mêmes les variables dont la portée est globale (le cas de tools qui nous intéresse, mais aussi QuickApp.... et absolument toutes les fonctions qu'on utilise (fibaro.*, math.*, json.*, etc) font en réalité partie d'un super tableau appelé _G dont l'appel est implicite. Voir à ce sujet ma petite exploration (j'ai découvert après coup que @jang avait partagé un code tout à fait similaire sur le forum officiel.... promis cette fois-ci je n'ai pas copié)

Cela sera peut être plus clair ainsi, avec les parenthèses : local id = (type(self) == "userdata" and self ~= tools and self.id) or (type(self) == "number" and self > 0 and self) Ou bien en syntaxe traditionnelle : local id if type(self) == "userdata" and self ~= tools then id = self.id elseif type(self) == "number" and self > 0 then id = self end