Lazer

Ce sont les Custom Events, une fonctionnalité pas du tout mise en avant par Fibaro, et assez peu discutée sur le forum. Exemple d'utilisation ici : https://www.domotique-fibaro.fr/topic/15003-comment-simuler-les-properties-dun-qa/?do=findComment&comment=237702

Your 2 lines looks correct. - The first one will trigger on whatever alarm time is reached. - The second one will trigger only when the time of the second alarm is reached. You just need to past them in the setevents() function in the config file of the QuickApp, as explained on the first page of the tutorial : https://www.domotique-fibaro.fr/topic/14651-quick-app-gestionnaire-dévénements-automatique-gea-pour-hc3/

Ouais gros LOL J'aime bien leurs vidéos, c'est très divertissant Mais voilà, "divertissant", c'est le mot. On s'arrête là, pour la crédibilité on repassera. J'ai failli stopper la vidéo quand ils ont dit qu'avec esp32cam ils avaient la même qualité d'image qu'une caméra pro.... et tout est comme ça dans leurs vidéos, c'est bon pour se divertir dans la joie et la bonne humeur.

ah oui mais alors si c'est juste le problème de vitesse, alors là je ne sais pas. Sur HC2, d'après le code source, cette fonction se contente d'appeler l'API HTTP, ensuite on ne sait pas ce qui se passe : fibaro.callGroupAction = function(self, actionName, actionData) local response, status = api.post("/devices/groupAction/" .. actionName, actionData) if status ~= 202 then return nil end return response["devices"] end

ups.realpower.nominal * ups.load 540 * 12 / 100 = 64.80 Watts

Pour compléter, ça sera possible, un jour, quand Fibaro permettra officiellement d'utiliser les listes déroulantes dans l'interface des QuickApps. Ainsi l'utilisateur pourra facilement choisir une valeur dans la liste déroulante, limitée aux choix proposés. En attendant, tu peux faire plusieurs boutons, chaque bouton permettant de porter la valeur qui t'intéresse. Bon si par contre tu as une liste de choix parmi 10....20... 50 valeurs, créer autant de boutons ne va pas être une bonne solution.

Non... enfin il va falloir coder ta propre logique, mais rien n'empêcherait un utilisateur de modifier la variable à une valeur non autorisée directement via l'interface Web. Le principe des variables énumérées c'est de limiter les valeur à une liste de choix prédéfinie... du coup la réponse directe à ta question, c'est bien non.

Sur HC2 j'ai quelque chose qui ressemble à ce que tu as fait : un VD, avec une scène pour le pseudo retour d'état. Pour avoir un retour d'état fiable, j'ai supprimé la télécommande d'origine. Le contrôle du Velux se fait exclusivement au travers de la domotique, c'est à dire : - directement depuis la box HC2 (scénario, interface Web, application mobile) - directement sur le module FGS double-relais, que j'ai installé au mur avec un interrupteur double monté/descente (ce FGS agit directement sur le KLF-050, et également sur la HC2 car il déclenche la scène de mise à jour de l'état) Sur HC3, je n'ai pas encore trop réfléchi... Évidemment le QA sera typé comme un volet roulant, ça va de soi. Mais je voudrais éviter une scène à coté du QA, je veux que le QA soit 100% autonome. Cela implique donc l'utilisation de l'API refreshStates dans une boucle infinie, car les QA ne supportent les "triggers" comme les scènes. Je ne pense pas me lancer dans la gestion des modules enfants, donc ça sera 1 QA = 1 volet. J'avais prévu de faire ça d'ici fin mai... donc dans 1 mois.

Dans tes 2 exemples de règles, c'est strictement identique. Il y a quelques cas où l'ordre des conditions importes, c'est quand on utilise les attributs #value# #name# #room# etc, car par défaut il prendra la 1ère condition. Et sur la HC3 tu peux renommer les profils de base s'ils ne te plaisent pas, et en créer d'autres.

Je n'ai pas ce souci Tu as bien sélectionné "Obtenir l'heure du serveur NTP" ? Pour l'adresse, j'ai toujours utilisé directement pool.ntp.org, je pense qu'il y a plus de serveurs derrières et moins de chance de panne que d'utiliser fr.pool.ntp.org, forcément plus limité.

Tous les animaux. Chats, chiens, renards, oiseaux, pour l'instant je n'ai pas eu de souci chez moi. Je n'ai pas de cerf, mais vu que c'est aussi haut qu'un homme, ça pourrait poser problème.... J'ai expliqué le fonctionnement sur le topic Diagral, il doit même trainer un schéma des rayons IR, ça permet de bien se figurer le fonctionnement.

Exact c'est vrai, je l'utilise aussi pour surveiller ma fille quand elle joue seule dehors Les détecteurs d'alarme extérieurs sont prévus pour fonctionner avec les animaux, double faisceau IR, donc c'est pas trop un souci en pratique, ça marche vraiment bien. C'est en intérieur que c'est infernal, il y a 1 seul rayon IR, du coup n'importe quel animal les déclenche, le pire ce sont les chats qui montent partout. Je n'ai jamais essayé les bi-technos, je ne sais pas si ça se comporte mieux.

Voilà, tu devrais avoir un tableau vide dans la (ou les) répétitions suivantes.

Mouais... non... en fait l'assurance elle s'en fout, c'est avant tout notre problème. Dans le meilleur des cas elle remboursera la valeur des biens volés et les dommages causés, mais bien souvent moins.... sans compter le traumatisme. Et puisque tu parles de cambriolage, le rôle de la caméra n'a jamais été de les éviter, mais uniquement de faire de la lever de doute, et de l'analyse post-événement (= ce dont il est question dans notre discussion) Perso aucune intrusion n'a donné lieu à un cambriolage jusqu'à présent, merci les lumières automatiques du jardin, et l'alarme extérieure Les caméras m'aident à comprendre le mode opératoire des intrus et à améliorer la pré-détection et les scénarios de dissuasion active.

Oui mais tout est bon là, c'était @henri-allauch qui avait des événements en double, à cause de sa première écriture qui relançait les requêtes avec setInterval()

last=lastResfresh peut arriver par exemple si aucun nouvel événement durant la temps d'attente de la requête le problème n'est pas d'avoir last=lastResfresh mais d'avoir des événements en double, ce qui n'est pas censé arriver EDIT : bon bah voilà @jjacques68 tu fais les questions/réponses tout seul

Même, ça ne change rien. En journée, même une définition en 2K, ou intermédiaire en 4MP (donc à mi-chemin entre 2K et 4K.... ouais faut pas confondre les pixels et la définition horizontale), est suffisante pour identifier l'individu quand tu vas porter plainte et qu'on te montre une planche de photos. Par contre, la nuit, le gain de sensibilité est indispensable pour identifier correctement. Essaye d'identifier le mec quand tu as une bouillie de pixels, tous les détails sont mangés par le bruit numérique du capteur.... c'est pas simple. Les Megapixels ne t'apportent aucune aide dans cette situation (et justement c'est l'inverse, c'est le surplus de pixels qui est responsable de la mauvaise qualité d'image) Ma préférence est claire : une meilleure sensibilité en basse lumière est plus importante qu'une définition élevée, car elle permet de répondre à tous les cas de figure. Et puis, on est en train de comparer un capteur 4MP avec un capteur 8MP (4K), en pratique ça fait une très faible différence sur les détails de l'image (et ne pas oublier les défauts de l'optique qui n'est pas parfaite). Par contre ça fait une grosse différence sur la perte de sensibilité. C'est pas comme si on comparait avec une image 720p (soit 1MP environ) des vieilles caméras (ma Foscam dans la maison est encore comme ça !) Autre truc tout con, mais finalement pas si con que ça, la ColorVu permet de garder les couleurs (absence d'éclairage infra-rouge), et dans mon cas, le capuche orange du gars était un des éléments supplémentaires qui a été spécifié sur le PV, et ça faisait une concordance de plus dans le signalement qui correspond à l'individu attrapé plus tard dans la même nuit par les flics.

Merci Bon j'ai encore du mal à identifier les fonctionnalités présentes sur chaque aspirateur, idéalement il faudrait que je complète ma collection de logs, si quelqu'un a un autre modèle (par exemple S5 Max, S6, S6 Pure, S7, ...) je veux bien le log détaillé, merci. Ah oui et aussi il faut que je t'ajoute le nettoyage des zones et le Goto, c'est ça ? Comment tu avais fait pour calculer les coordonnées ? Tu as utilisé la méthode de @ADN182 ? Il n'y a pas plus simple ?

Elles existent les ColorVu en 4K (enfin je ne sais pas si elles sont dispos à la vente), mais comme j'expliquais, la sensibilité est inférieure (raison physique, et confirmé par la datasheet) Après tout dépend ta priorité : - tu veux un max de définition en pleine journée => 4K - tu veux une meilleure qualité d'image la nuit => 2K Perso mon choix est fait, les malfrat s'introduisent majoritairement la nuit, c'est à ce moment là que j'ai besoin de reconnaitre les visages. J'ai relaté il y a quelques pages la difficulté que j'ai eu à identifier un individu au commissariat, malgré que l'image de ma précédente caméra était déjà supérieure à 99% des caméras des gens. Parce que la tête du livreur Amazon / La Poste / Sushi en haute résolution, je m'en cogne un peu... M'enfin vous faites comme vous voulez, cette discussion me rappelle furieusement les débats stériles en photo (d'abord les appareils photos, puis maintenant les smartphones), des partisans du plus gros chiffre est forcément le meilleur.

Cool Tu pourrais m'envoyer le log détaillé depuis l'initialisation STP ? Dans cette versions spéciale, j'ai mis un getFeatures, je veux voir quelles sont les valeurs, l'idée à terme ça serait, si possible, de faire un QA qui s'adapte aux capacités de l'aspirateur (serpillère, etc)

J'ai dû louper l'univers dans lequel Z-Wave est très bien implanté. Dans le miens, Z-Wave (comme Zigbee d'ailleurs) est une techno confidentielle pour geeks barbus, qui n'est vendu que dans les boutiques spécialisées. Si CHIP abouti, les fabricants n'auront aucun mal à l'intégrer dans leurs produits commercialisés dans tous les supermarchés, grandes surfaces de bricolages, et autres magasins divers et variés. Le marché sera inondé et Z-Wave comme Zigbee resteront des technos ultra confidentielles pour gens déjà équipés ou qui ont des besoins ultra spécifiques... et encore, si on de la change, car ça pourrait tout aussi bien disparaitre. Puce dédiée, logiciel, tout ça, on ne sais pas encore....ils parlent de base open-source, donc il faut espérer que ça ne soit pas verrouillé, et que n'importe quel fabricant qui ne fasse pas partie de l'alliance puisse utiliser ce protocole. De toute façon c'est à cette seule condition que CHIP a un avenir, sinon il restera cantonné à un univers de geeks comme les Z-Wave, Zigbee, EnOcean, etc actuels. On verra bien...

Nickel, merci J'étudierai ça... plus tard (dans quelques jours), j'espère que ça n'est pas trop urgent pour toi.

Il faudrait le formater pareil pour en être certain.... mais en tout cas je l'ai testé chez moi et ça fonctionne (sur HC3, ce qui confirme que la syntaxe est la même que pour HC2)

Welcome to the forum

Non parce que ça va remettre lastRefresh = 0 C'est bien loop() qu'il faut appeler dans l'exemple du dessus.