Lazer

En effet, dans ce cas précis il vaut mieux utiliser des Darkfighter je pense. A moins qu'ils aient amélioré le mode noir et blanc avec éclairage infrarouge sur les toutes dernières générations de Colorvue, là je n'en sais pas plus...

Indeed it is quite difficult to configure this QuickApp, as it require some basic network knowledge. There are many examples on first page that you can inspect to understand the different parameter values. Then it is up to you to create your custom configuration for devices on your network. As a general rule, I would say it is best to use HTTP mode when possible, because it is not only test whereas the device is powered on, but also if the output is valid, meaning the device is fully operational. It is easy to implement, you can just open a web page with your favorite browser and look for a text content that que QuickApp is able to interpret. The TCP mode is a more advanced way of testing a device state, when this one does not expose a HTTP service. For instance, you can check SSH connection for a Linux server that as no other exposed services (opened port). It is more complicated, you can use PuTTY or other similar tool to connect to a specific TCP port and see what text message is returned. But for some services no text message is returned. ICMP (ping) is unfortunately not available in LUA on Fibaro HC3. For notifications to specific QuickApp (SMS, Telegram, etc), there is an example in the tutorial on first page, you have to fill in the Notif_SMS variable.

En complément de la réponse de @mprinfo je dirais que la force des Colorvue, c'est de voir la nuit en couleur sans assistance infra-rouge. En revanche, elles sont plutôt mauvaises dès lors que tu allumes l'infrarouge. Du coup, le choix va dépendre de l'environnement à filmer : - coté rue publique, illuminé par l'éclairage publique => Cororvue avec IR désactivé (en mode couleur jour et nuit) - coté jardin, dans le noir complet => Darkfighter (génération précédente) avec IR activé (en mode couleur le jour, et mode noir et blanc la nuit)

Ah OK, oui alors en effet c'est plus compliqué. Bon ben désolé mais je ne sais vraiment pas te conseiller du coup. D'autres le pourront surement

Pourquoi HA-Bridge ? Après je ne suis pas la bonne personne pour te conseiller, je n'ai pas de Switchbot, et je suis allergique à IFTTT. Quand je regarde le truc ça m'énerve et après j'arrête pas de déverser ma haine envers le cloud partout sur le forum en expliquant à quel point les services dépendants du cloud c'est le mal incarné Du coup moi j'aurais pris le problème dans l'autre sens. Regarder comment domotiser le portail directement, il y a très certainement un contact sec que tu peux actionner avec un module FGS ou FGBS, directement en Z-Wave, et hop, plus de problème.

Je me doute bien PS pour contextualiser : même si je ne suis utilisateur de voiture depuis 20 ans, et pas du tout décidé à me passer de voiture, je ne suis pas franchement fan de voiture (la voiture n'est qu'un service pour mon usage, je n'ai jamais été propriétaire, toujours que des locations), du coup lors de mes recherches il m'est arrivé à plusieurs reprises de tomber sur automobile-propre car c'est une mine d'informations. Je connais le site depuis pas mal de temps. Mais je ne suis pas du tout membre actif (et même pas membre du tout en fait ) Ah non pas de fusible du tout, la sécurité c'est le rôle de ton tableau électrique. Avec des fusibles s'il est ancien, ou des disjoncteurs s'il a moins de 30 ans. Une prise de courant, c'est normalement un calibre de 16A, donc si tu mets un module prévu pour tenir 10A, et que derrière ce module tu branches une charge qui va tirer 12A (ça fait environ 2700 Watts, donc par exemple un bricoleur/artisan avec un outil électroportatif branché sur un aspirateur et tu es dedans), alors le module va au mieux fondre, au pire bruler. En effet. Perso comme j'ai des murs épais, j'ai défoncé le fond de la boite d'encastrement pour avoir la place d'insérer le module Walli... mais la problématique est exactement la même avec un module FGD/FGS/FGR situé derrière un interrupteur normal, 40mm est insuffisant, il faut au minimum 50mm. Ou bien il faut avoir des cloisons creuses en placo, et installer une boite de type chaussette en silicone permettant de glisser le module sur le coté. On en parle sur un topic du forum. Question de goût, et j'ai plein d'endroits où le Wall Plug est caché, donc au final, c'est plus simple, branché en 30 secondes, contre une bonne heure pour couper le courant, tester l'absence de tension, démonter une prise, défoncer le fond d'une boite, installer un Walli, et faire le ménage, puis remettre le courant. Bon après y'a plein de gens sur les forums qui installent le diable dans leurs murs justement... des micro-modules donnés pour 10A derrière une prise de courant... après faudra pas qu'ils viennent se plaindre si le diable met le feu avec le module ! Et puis l'assurance qui va s'en donner à coeur joie !!!

Pour le coup, bonne utilisation des citations Tiens ça me rappelle quelque chose Il y a quelques années ici-même. Et c'est un mode de fonctionnement propre à tous les forums je pense. juste renommer le domaine en automobile-moins-sale.com serait plus juste mais j'arrête là le HS car ce débat dégénère assez vite (pourtant je suis favorable au tout électrique) Y'a ingénieur en tout. Ce qui doit te manquer, ce sont des notions d'électricité, ce n'est pas une critique, juste une constatation. Du coup la compréhension est plus longue, nécessite plus de temps de recherches.... ... enchainement logique. Forcément si on ne sait pas par où commencer, c'est pas facile. La demande en tuto est légitime, mais on en revient au début de la discussion, il faut des gens motivés. Et en la matière, on en manque cruellement. Si je te résume l'activité de ce forum, il y a quelques années, Fibaro était à la mode, pas le biais des blogueurs et boutiques de l'époque. Donc beaucoup de participant. Comme souvent, 90% de gens que tu ne revoies jamais, mais statistiquement, plusieurs personnes motivées, qui se sont impliquées, on participé activement, ont proposé des tutos, des partages, etc. Puis le temps a passé, la mode à tourné, car la concurrence est arrivée. Beaucoup de gens sont partis sur les forums d'à coté (il y a eu une vague Jeedom, puis actuellement ça semble plutôt Home Assistant). Quelques personnes sont restées, mais le taux d'activité a très fortement chuté. Donc plus personne pour écrire des tutos. Et les membres actifs sont "experts", c'est à dire qu'ils ont tous une certaine expérience, une culture de la domotique/électricité/informatique pour savoir où chercher une info nouvelle. Tous ces membres ont appris avec le forum, ou avec des blogs (plusieurs ont fermé malheureusement... les blogs qu'on trouve aujourd'hui ont perdu en qualité... la faute au format vidéo Youtube surement et tout ce qui va avec : sponsoring, argent, fortune... ou pas) Quand un nouveau module (FGS xxx) sort, il remplace ou complète un précédent, alors les experts savent faire la différence, mais je comprends qu'un néophyte ne sache où chercher, car l'info didactique "de base" n'existe plus à cause des blogs fermés justement. Et le marché de la domotique vampirisé par les GAFA n'aide pas, à grand coup d'ampoule multicolore à visser sur une douille existante, c'est bien gentil, mais ça ne nous dit pas comment domotiser la maison... domotique versus objet connecté, 2 mondes qui s'affrontent. Non car une prise électrique (murale) c'est du 16A, et les modules ne sont donnés que pour 10A, donc il y a danger (d'incendie). Pour une prise, il faut utiliser une prise Fibaro Walli encastrée, ou bien brancher un Wall Plug par dessus une prise existante. Oui Oui, mais les 213 et 224 aussi. Mais comme derrière l'interrupteur on a 99% du temps une lumière, l'idéal c'est plutôt de s'assurer que l'ampoule des dimmable, et utiliser un module FGD 212 qui permettra la variation de lumière, beaucoup plus confortable au quotidien que du simple ON/OFF. Accessoirement le dimmer est silencieux, alors que le FGS est un relai qui "claque" lors des commutations. Du coup, les FGS on les utilise pour les circuits comportant une charge non dimmable (lumière non dimmable), VMC, moteur, contact sec (portail, porte de garage, etc)... avec quelques précautions par rapport au courant max sur les charges inductives (une LED, un moteur, etc ça peut appeler 100 ou 1000x plus de courant à l'allumage). Encore des notions d'électricité à acquérir au passage. La différence porte sur la tension de la charge. Si c'est du 230V, alors FGS 213/223 Sinon, il faut utiliser les FGS 214/224

Cool Normalement si tu suis le tuto ça doit le faire.

Oui il faut créer les VG dans l'interface de la HC3, je ne me souviens plus si le QA Network Monitor sait le faire tout seul. Sinon va faire un tour sur le topic de Network Monitor pour relire le tuto. Une fois que tu verras ta VG s'incrémenter, alors ça sera OK et tu pourras passer à GEA.

Le S5 Max est bien compatible. Et le S7 devrait l'être également.

Mais pourtant que j'ai expliqué que DomoCharts ne permettra pas de faire ce que tu veux, c'est lié à son mode de fonctionnement intrinsèque. Il ne te permettra ni de détecter les petites coupures de quelques secondes, si ne mesurer le temps des coupures... donc autant dire que ça ne répond pas du tout à ton expression de besoin. Grafana ne sera pas plus utile, puisqu'il exploite les données collectées par DomoCharts et stockée dans la BD. Pour les emails, il faut bien remplir les champ du serveur STMP de votre fournisseur d'accès. ça marche de la même façon que pour tous les équipements qui envoie des emails chez moi. Attention avec certains fournisseurs d'accès à Internet, qui bloquent le port SMTP 25 par défaut, pour bloquer les relais à Spam. Vérifiez ça dans votre compte. Perso je n'ai jamais eu de souci avec Orange et Free sur l'envoi d'emails en passant par leurs relais SMTP.

Bonne nouvelle, gsmart a travaillé sur une version du QuickApp Netatmo adapté à la nouvelle méthode d'authentification OAuth 2.0 imposée par Netatmo. Il a également créé une page web permettant de semi-automatiser le processus de récupération du jeton. Voir sur le forum officiel : https://forum.fibaro.com/topic/53868-the-“netatmo-weather-station-qa-for-hc3”-has-stoped-working-since-5063-installed/page/3/#comment-254076 Je n'ai pas encore testé de mon coté.

Au cas où, voici aussi la ligne de config pour ne QA Network Monitor : DEVICES = { {name = "Google", address = "www.google.fr", port = 80, protocol = "http", timeout = 10, url = "/", retcode = 200, retdata = "Recherche Google", retry = 2, interval = 5, notification = {"sms"}, vg = "Google", conditions = nil}, } Comme ça tu as tout ce qu'il faut

Allez, on ferme la discussion, ici c'est pour se présenter, ça fait déjà 2 message hors-sujet.

Bienvenue sur le forum

En fait, plus généralement, ce que tu veux c'est de pouvoir historiser dans DomoCharts le statut des capteurs binaires true/false (ouverture de porte/fenêtre, mouvement, etc... et bien sûr le QA Eaton). Actuellement DomoCharts ne le fait pas... car ça serait assez peu pertinent : - sur un graph, tu aurais des pics (valeur à 1 ou 100%, au choix), le reste du temps à 0. Sur le graph d'une semaine, un pic de quelques secondes serait tout simplement invisible, sauf à zoomer. Le reste du temps ça serait une courbe plate à 0. - si le capteur passe à l'état true pendant 59 secondes seulement, mais qu'il repasse à false lorsque DomoCharts interroge l'état des capteurs, il le verra à false... il aura donc raté le déclenchement du capteur - par défaut seule 1 semaine est affiché, ensuite les données sont historisées, c'est à dire consolidés par jour pour rétention longue... si on fait la moyenne de 1 pendant 1 minutes sur les 1440 minutes que comporte 1 journée, ça fait approximativement 0, donc données inexploitable Bref, DomoCharts n'est pas du tout l'outil à utiliser pour historiser les événement des capteurs (dont fait partie le QA Eaton) Il faudrait repartir des événements de la HC3, et les historiser dans une autre base de données conçue spécifiquement pour. C'est @jjacques68 qui avait fait un truc similaire je crois bien. Perso l'historique des coupures élec de l'onduleur je l'ai dans ma boite mail... car la carte de management de l'onduleur est paramétrée pour m'envoyer un email à chaque coupure/reprise du secteur.... indépendamment de la domotique. Mais attention l'onduleur est sensible, de temps en temps il passe en mode batterie pendant 1 seconde, par exemple s'il y a une légère sous-tension ou que sais-je... qui n'a même pas fait rebooter le PC qui n'est pas sur onduleur pourtant ! Pourtant, cela ne peut pas être considéré comme une coupure secteur.

Au cas où ça peut t'aider, je fais ça avec GEA (la connexion Free tombe parfois, et ma Freebox est en mode bridge, il y a un bug non résolu par Free dans ce cas précis qui fait que la Freebox ne retrouve pas la connexion automatiquement... donc reboot forcé. La Freebox est donc branchée sur un Wall Plug. J'utilise le QuickApp Network Monitor qui détecte si Google ne répond pas au bout de 5 tentatives, alors ça incrémente une variable globale Google, ce que détecte GEA et fait un reboot de la Freebox. -- Freebox GEA.add({"Global+", "Google", "5"}, 300, "Google ne répond pas, reboot Freebox", {{"Repeat"}, {"TurnOff", id["FREEBOX"]}, {"SMS", id["QA_JPI"], "Reboot Freebox"}, {"Sleep", 30, {"TurnOn", id["FREEBOX"]}}}, "Reboot Freebox") GEA.add(id["FREEBOX"], 60, "Freebox éteinte, allumage", {{"Inverse"}, {"Repeat"}, {"TurnOn"}}, "Allumage Freebox") Seule la 1ère ligne est utile (on remarque qu'elle envoie également un SMS via la passerelle JPI). La 2nde ligne est juste là par sécurité.

Pour rester dans le thème, je me suis dit que j'allais faire un QuickApp vite fait pour signaler les alertes sur le réseau électrique via Ecowatt. https://data.rte-france.com/catalog/-/api/consumption/Ecowatt/v4.0 Et.... il faut une authentification OAuth 2.0 Pour un service public, qui propose une information publique, qui n'a rien de confidentielle... là c'est n'importe quoi...

Mouais alors là je ne suis pas d'accord, car c'est plutôt l'inverse qui se passe. Ils sont tous ultra à la bourre en matière de sécurisation... et ils sont plutôt en mode pompier depuis quelques années. Y'a une faille, une brèche, une technique, une méthode.. qui permet de pirater, alors vite* on applique une rustine. Mais la sécurité ça coute cher, alors ils ne le font pas en amont. * et encore "vite", c'est vite dis... le nombre de failles qui ne sont jamais corrigées, c'est assez incroyable. Et ça ouvre la porte à plein d'attaque DDOS justement (c'est l'usage le plus courant je pense)

Voilà exactement. J'allais dire qu'il suffit d'avoir un peu de curiosité, et de temps, et d'aller naviguer sur les boutiques des revendeurs de domotique pour découvrir les modules existants et leurs possibilités, mais en fait @Nico a tout dit, domotique-store et ses tutos donne des informations vraiment complètes.

Non ce n'est pas ça. La politique économique de l'entreprise (Enphase dans le cas présent) c'est de ramener les utilisateurs (données et usages) vers le cloud. Cette centralisation des informations induis des risques de sécurité, qu'il faut couvrir par des mécanismes complexes (token JWT dans le cas présent, on pourrait parler de Netatmo et OAuth 2.0). Si cette sécurisation n'est pas faite, un piratage des serveurs pourrait potentiellement toucher tous les clients. Leurs données, mais aussi par rebond l'accès à leur passerelle, leur réseau, et les usages qui peuvent en découler (les bien connues attaques DDOS). Bien sûr, si on avait juste un accès local, nous on serait content. Mais ça n'est pas l'objectif des entreprises, car développer et maintenir (par les mises à jours) des objets disséminés ça et là, c'est couteux... et ça ne rapporte rien.

Oui il y a plusieurs modules enfants, mais normalement il faut uniquement utiliser celui qui est affiché par défaut (les autres sont cachés) Je crois me souvenir que la télécommande (remote) est affichée par défaut, perso je ne m'en sert pas donc je la cache afin de ne pas polluer l'affichage (la télécommande n'est utile que pour les scénarios rapide en mode graphique, ce que je n'utilise pas)

Le reset va complètement réinitialiser le module, il perdra tous ses paramètres et sera exclu du réseau Z-Wave... Je ne te le conseille pas, sauf en dernier recours. A priori aucun besoin de jeter le module, sauf s'il est cramé, mais je ne pense pas que ça soit le cas. Le souci en fait, semble être ton volet Profalux, qui ne peut pas être calibré. Du coup inutile de continuer à perdre ton temps avec la procédure de calibration (et le script proposé par mprinfo ne te sera d'aucune aide du coup) Après... perso je ne sais pas faire, mais tu sembles avoir as des bonnes pistes pour régler manuellement ton module avec les paramètres 151, 156 et 157

Le problème c'est de trouver quelqu'un de motivé pour l'écrire !

C'est nécessaire car les risque de sécurité sont de plus en plus importants, on voit tous les jours des sociétés de faire "pirater" (oh le vilain mot). Mais ces risques de sécurité sont aussi la conséquence de mauvais choix d'architecture... le tout connecté au cloud, dépendant de serveurs centraux, implique des risques de sécurités considérables en cas d'attaque. Et c'est là qu'on voit que ces problématiques de sécurité cachent le vrai problème, les mauvais choix d'architecture, la dépendance au cloud, qui sont dictés par d'uniques raisons de rentabilité financière... Alors qu'une bonne vieille connexion locale en tout autonomie, c'est moins couteux, plus pérenne, ça poserait tout un tas de problèmes de sécurité en mois, bref à l'avantage du client... mais ça, ce n'est pas l'avis des investisseurs. Je travaille dans une boite qui porte le mot "Cloud" dans son nom, alors on va dire que je connais un peu le problème de l'intérieur... c'est désespérant. Vraiment.