Lazer

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)

Utilise plutôt le même filtre que j'ai mis dans mon exemple, il fonctionne chez moi depuis l'année dernière sur la HC3.

Et elles répondent chez toi les URL que j'ai donné Nico ? Ou bien ça fait comme flamalex, redirection vers la page d'accueil ?

Tu as le bouton de calibration en bas de ta 2ème capture d'écran. Sinon la manip avec les interrupteurs est indiquée dans la doc du module.

FGR plutôt que FGS non ? Tu as refait la calibration du volet ? Les problèmes que tu décris ressemblent à une calibration perdue / non faite. Je viens de vérifier avec un FGR-223, et tout fonctionne nickel en 5.120.10

Voici une fonction que j'utilise dans l'un de mes QuickApp pour éteindre toutes les lumières de la maison : -- LightOff -- Modules à exclure et fonction de traitement (pas raccordés à des lumières) -- Peut contenir un id ou un mot clés à chercher dans le nom du module local lightsToExclude = {12, 345, 678} -- -- Bouton : Éteint les lumières -- function QuickApp:LightOff(event) local function shouldExclude(device) for _, v in pairs(lightsToExclude) do if device.id == v or string.find(device.name, v) ~= nil then return true end end return false end local devices = api.get("/devices?property=isLight") if type(devices) == "table" then for i = 1, #devices do local device = devices[i] if not shouldExclude(device) then local value = tonumber(device.properties.value) if type(value) == "boolean" and value or type(value) == "number" and value > 0 then local roomName = fibaro.getRoomNameByDeviceID(device.id) self:trace("Found device", device.id, ":", device.name, roomName, "(value", tostring(value)..") => call turnOff") fibaro.call(device.id, "turnOff") end end end else self:error("Impossible de lister les modules") end end Il te suffit d'appeler la fonction LightOff() depuis un bouton de ton QuickApp. Et personnaliser les éventuelles lumières à exclure dans la table lightsToExclude

donc ils auraient intégralement retiré toute l'API locale c'est dramatique.... Du coup aucune chance que mon QA fonctionne chez toi...