Lazer

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.

C'est tout de même étrange que le module ait perdu sa calibration lors de la mise à jour du firmware de la box... à se demander si le module était vraiment calibré en fait ! Je ne suis pas spécialiste de la calibration des volets, je l'ai fait une fois, ça marche, je n'y ai jamais retouché... Quoi qu'il en soit je pense qu'il serait plus adapté de continuer la discussion sur le topic du module en question : EDIT : bon OK tu as déjà posté là bas !

C'est bien gentil l'URL /home.json mais elle ne sert à rien, je veux dire qu'elle ne donne aucune info utile sur la production, consommation, etc. Cette catastrophe... c'était couru d'avance de toute façon, il y a 6 mois quand j'ai fait des recherches et développé mon propre QA avec les API locales en v5, Enphase disait déjà que l'API locale était amenée à disparaitre et ils poussaient vers l'API cloud. C'est finalement arrivé avec la v7. Je suis bien content de ne pas avoir suivi les mises à jours, je vais rester en v5 aussi longtemps que possible (ce qui exclu la possibilité d'étendre un jour mon installation avec les nouveaux IQ8... enfin s'ils arrivent un jour après 2 ans de retard...) Après j'ai vu qu'il est question de token... je n'ai pas vu où on génère le token... en ligne ? Il semble qu'on puisse l'utiliser en local ensuite pour une durée de vie limitée. ça me rappelle étrangement l'API Netatmo (sauf que celle-ci reste en cloud quoi qu'il arrive)

STP arrête de citer le message précédent le tient, c'est inutile et ça alourdi la lecture Un interrupteur monostable c'est un bouton poussoir, qui reprend sa place dès qu'on le relâche. Par opposition au bouton bistable, c'est à dire un interrupteur classique à l'ancienne (sans domotique) qui ne revient jamais à sa position d'origine, sauf si on vient appuyer manuellement dessus. Quand on met en place la domotique (dimmer, volets, etc), en général on en profite pour remplacer les vieux bistable par des monostable, ça apporte plein de fonctions en plus : le double clic, l'appui long, etc. Le bouton B c'est le petit bouton qui est sur le boitier noir du module... facilement accessible avec un petit tournevis/trombone. Je préfère le tournevis isolé, c'est plus sûr.

Sur les 214/224 la sortie est un contact sec libre de potentiel, tandis que sur les 213/223 la sortie est câblée sur l'entrée donc forcément 230V AC. Selon ce que tu veux faire, il faut choisir l'un ou l'autre. Cela dit, si tu câbles le IN des 214/224 sur la phase, alors le résultat est le même qu'avec les 213/223, donc les 214/224 sont plus universels (mais nécessitent un câble ou pontage supplémentaire du coup)