Lazer

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

Ah OK, c'est de l'optimisation de code LUA en une seule ligne avec uniquement des AND et OR, sans utiliser le lourd if .... then ... end Donc rien à avoir avec Fibaro, QuickApp, etc.... c'est du LUA pur et dur Mais cela rend le code moins compréhensible quand on n'a pas l'habitude Un peu dans l'esprit de ce qui est présenté dans ce mini benchmark (test n°5) : https://springrts.com/wiki/Lua_Performance#TEST_5:_Nil_Checks_.28.27if.27_vs._.27or.27.29

Tu pourrais regarder cette discussion, car la fonction push() que je crée sur mes enfants est utilisée aussi bien pour une mise à jour depuis l'API, que depuis le parent lui-même. Dans ton cas, ta fonction UpdateTemp() est similaire à ce que fait ma fonction push() Pour l'appeler pour chaque enfant instancié, il faut que tu parcoure ta table des enfants avec : for _, child in pairs(self.childDevices) do child:UpdateTemp(value) end

ouais mais si tu perds aussi les historiques de température et consommation lors du restore, c'est dommage. Enfin je sais pas, je n'ai pas testé

Pas besoin de me retaper les QA, puisqu'ils fonctionnent avec l'ancienne librairie tools Si par contre je souhaite reprendre le QA pour lui apporter des nouvelles possibilités, améliorations, corrections de bugs, etc, alors là c'est l'occasion de lui "installer" la nouvelle librairie. Cette ligne de code est une astuce pour récupérer l'ID du module passé en paramètre (variable self implicite correspondant au 1er paramètre lors de l'appel de la fonction) - SI type(self) == "userdata" (c'est à dire le quickapp lui-même ou l'un de ses enfants) ET que ce n'est pas tools lui-même (test inutile car en pratique tools est de type "table") ALORS on renvoie self.id - SI type(self) == "number" ET qu'il est positif (on ne sait jamais, dès fois qu'un ID négatif se perde par là), ALORS on renvoie directement le nombre lui-même (contenu dans self) Dans les commentaires je t'ai justement mis la façon de l'utiliser. Cette astuce, je l'utilise dans plusieurs de mes fonctions de cette librairie tools, c'est hyper pratique à l'usage, je peux faire ce que je veux sur un module, qu'il soit self, child, ou un ID quelconque. Tu verras tools 2.0 quand je le partagerai dans IPX800/EDRT, mais la version 1 a déjà été partagée dans des QA (Kodi, Surv Station, ...)

Ouais j'ai pas compris le truc du backup cloud là, j'ai cru qu'ils allaient faire lever la limitation, mais en fait non. Juste l'option pour pas sauvegarder les logs.... fausse joie Du coup mon script de backup local reste plus que jamais utile

Oui la cohérence est un problème, mais tant qu'on ne pourra pas travailler le design des QA, ça restera moche dans tous les cas (désolé, mais je trouve encore que les VD étaient plus jolis, même si très basiques) La Preview, je n'avais pas pensé à cela.... et Fibaro non plus apparemment

Les fichiers des QuickApp permettent de découper son code.... en plusieurs fichiers ! Exactement comme on le ferait avec n'importe quel langage de programmation, allant du C jusqu'au PHP L'idée, c'est plutôt que d'avoir un seul fichier monolithique de plusieurs milliers de lignes, on a plusieurs petits fichiers dans lesquels il est facile de retrouver la fonction recherchée. Après pour l'organisation, c'est à l'appréciation de chacun, mais perso ce que j'aime bien faire pour les QuickApp : - main : le code de QuickApp lui-même, c'est à dire toutes les fonctions qui appartiennent à la classe QuickApp, donc sont accessibles par l'utilisateur au travers de l'API fibaro.call(). On va retrouver la gestion de actions, des boutons, etc - tools : ma librairie d'outils avec pleins de fonctions utiles dans mes différents codes, et qui manquent dans le LUA natif proposé par Fibaro ("print" améliorés avec des couleurs, createChild amélioré, getVariable amélioré, createVG, Wake-on-LAN, round(), split(), base64(), log(), getView(), etc ...) - notification : pour envoyer des notifcations (Push, SMS, etc) - config : pour que l'utilisateur y stocke ses paramètres (s'ils sont trop nombreux pour tenir dans les variables du QA, comme par exemple GEA, Network Monitor, etc... et prochainement IPX800v4/EDRT2) - XXX : celui là est dépendant du QA, il contient le cœur du QA, c'est à dire toutes les fonctions spécifiques au QA. Donc ça va être SNMP pour l'onduleur Eaton, ou bien KODI pour gérer l'API Kodi, etc Dans cette liste, certains fichiers (notification, tools) vont se retrouver dans plusieurs QA différents, il me suffit de faire un copier/coller pour en bénéficier automatiquement, facile, rien à intégrer dans le code "main", c'est un fichier à part. Note : je n'utilise pas la méthode de recopie automatique des fichiers proposée par @jang, personnellement je n'aime pas ce genre d'automatisme, une nouvelle version de ma librairie tools pourrait casser la compatibilité avec l'existant et rendre inopérant toute une tripotée de QA existants. (pour des raisons un peu similaires, je n'utilise jamais, ou rarement, la dernière version des logiciels, aussi bien sur mon PC, que mon Smartphone, ou bien ma box domotique... je préfère faire les mises à jour manuellement en cliquant sur un bouton, avec un décalage, je n'ai pas envie d'avoir la primeur des nouveaux bugs qui s'installent automatiquement)

Il est en mode labo en test SOUS mon bureau depuis 1 mois... ça n'a toujours pas fumé Mais Krikroff a raison, méfiance quand même.

Bah moi... Je trouve ça pertinent Non sérieux, c'est logique que la vue par défaut propose les contrôles associées aux actions (fonction) obligatoire de chaque type de QuickApp. Par exemple pour un BinarySwitch, par défaut on a la possibilité de faire ON/OFF. Pour un Multilevel (lumière, volet), par défaut on a la possibilité de faire varier la valeur avec un slider. Il est donc tout à fait logique que Fibaro affiche automatiquement les boutons play pause stop volume etc sur un Player. Sur mon QA pour Kodi, j'avais justement ajouté manuellement les boutons manquants... dans la prochaine version je les supprimerai pour ne pas faire double emploi. Seul regret, on va perdre les jolis emojis en couleur que j'avais mis pour chaque bouton.... bon c'est pas forcément une grosse perte. Je trouve dommage qu'on ne puisse toujours pas travailler l'aspect des QuickApps en revanche @TonyC tu vas pouvoir tester le master/slave que tu attendais tant !