Lazer

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.

Hum, d'après ce qu'il décrit, il s'agit de récupérer un jeton sur le site Web d'Enphase, qui pourra ensuite être utilisé en local sur la passerelle Envoy. C'est un moindre mal car la communication avec l'API se fait en local, mais la génération du jeton est dépendante du Cloud... et comme le gars l'explique sur son blog, la méthode de récupération du jeton n'est pas documentée par Enphase, considérant que l'utilisateur doit faire la manip manuellement... ce qui est assez antagoniste avec l'usage un script en domotique qui se doit d'être 100 autonome. Du coup le gars propose une méthode de "scrapping" consistant à parcourir la page Web pour récupérer le jeton... ce qui fonctionnera tant que la structure de la page Web ne change pas. @augur faire la mise à jour pour dépendre du cloud n'est pas ce que j'appelle à aller de l'avant, mais plutôt aller droit dans le mur.... Il est urgent d'attendre.... (pour mieux sauter ?)

C'est pour @flamalex qui a besoin de downgrader depuis la v7 pour récupérer l'usage des API locales qui étaient accessibles facilement en v5.

Franchement je ne sais pas du tout, comme dit, je n'ai jamais eu aucun problème avec les FGR. Donc juste des pistes, et pour moi ta seule option c'est la calibration avec le bouton B. Puisque les autres méthodes ne fonctionnent pas ou ne sont pas possible. Le paramètre 151 il définir le type de volet. Chez moi c'est la valeur 1 pour "roller blind (with positioning)", car j'ai un moteur Somfy 3 fils (1 phase montée, 1 phase descente, 1 neutre) tout ce qu'il y a de plus standard. Tu dis que tu as du PROFALUX, je ne connais pas du tout, mais si ça se trouve ce n'est pas standard et il faut configurer un autre type de volet au travers du paramètre 151. Fais une petite recherche, d'autres personnes ont peut être eu le cas.

Nico est non binaire

Mon script fait le test de la lumière allumée dans ces 2 lignes : local value = tonumber(device.properties.value) if type(value) == "boolean" and value or type(value) == "number" and value > 0 then Boolean c'est pour les binary switch, type FGS. Number c'est pour les dimmers, type FGD ou RGB

- Demander gentiment à Enphase - Demander lourdement à Enphase - Pleurer - Prier - Acheter une ancienne passerelle pas à jour - Autre ? @Nico du coup on ne sais pas trop si tu es en v5 ou v7....

Je suis bien en D5.0.62, c'est indiqué partout : en local sur l'adresse IP de l'Envoy, sur l'application mobile, et sur mon compte en ligne. Je ne cherche même pas à faire de mise à jour, pour cela il faut se connecter sur le Wi-Fi local de l'Envoy à partir de l'application mobile Toolkit.

Hum... le mystère s’épaissie

Je pense que tu n'as pas le choix, il faut trouver le moyen de relancer un calibrage automatique. Tu dis que l'appui sur le bouton dans l'interface Web de la box est sans effet. Et tu as des boutons bistable. Donc ta seule solution pour relancer une calibration c'est de trifouiller le "bouton B" situé sur le module lui-même. Il faut arriver à lancer la calibration comme indiqué dans la doc.