Lazer

Ah mais oui complètement, cette histoire de tension de démarrage c'était justement l'une des raisons qui m'ont fait écarter les IQ7A, pas du tout pertinents pour mon installation. J'ai eu pas mal de bridage aujourd'hui avec les IQ7+, mais aucune perte financière, puisque c'est du surplus que je n'aurai de toute façon pas utilisé. J'ai plafonné à 4200 Watts entre 12h et 16h, en gros, c'est déjà beaucoup.

Ici on pratique de la domotique, donc une box (ou contrôleur, ou logiciel) domotique, avec différents capteurs et actionneurs répartis dans la maison pour tout contrôler. Si tu veux uniquement connecter ton portail, c'est évidemment too much, et j'ai peur que tu te sois trompé de forum. As-tu regardé sur Amazon ? Il y a des tonnes de produits à pas cher pour juste piloter son portail depuis le smartphone, avec une passerelle via le cloud. Rien de bien compliqué. Mais je doute que quelqu'un ici puisse t'apporter un retour d'expérience sur ces produits.

C'est vrai que c'est flou.... mais j'arrive à lire en zoomant (32" ici, donc ça laisse de la marge) Merci pour l'édit

Quelques watts oui, perso ça produit du lever du soleil au coucher du soleil (alors que le soleil n'éclaire pas encore les panneaux en direct, caché par les bâtiments) Attention après la configuration (changement de profil, déconnexion du relay Q, etc), les panneaux mettent quelques minutes pour recommencer à produire. Mais j'ai plusieurs fois débranché la passerelle, la production continuait bien. Tu peux le voir sur la téléinfo du compteur, si la consommation soutirée du réseau est diminuée (voire à 0 ) alors c'est que les panneaux+onduleurs produisent bien. J'ai aussi un compteur à impulsion sur le circuit PV, j'avais donné la référence sur le topic, ça permet de faire un suivi en local indépendamment de l'Envoy (qui ne sera surement pas éternelle...)

Non pas de problème pour lire, j'ai un grand écran, et puis en fin de compte ça permet de garder la couleur et rend donc le log plus lisible qu'un copier/coller en mode texte qui n'est pas toujours simple à lire (même s'il présente d'autres avantages, comme la recherche textuelle) (par contre, ta citation violente de l'intégralité du post pour écrire une petite ligne en dessous, elle est plutôt difficile à lire ) Quant au lldebug, si je ne l'ai pas documenté, c'est à raison, pour ne pas embrouiller les gens avec des options inutiles (sinon il faudrait documenter l'intégralité des options de GEA, et il y en a un paquet, surtout qu'il y en a quelques unes qui restent bien mystérieuses pour moi) Quand j'en ai besoin, je demande aux gens de l'ajouter, ça va bien ainsi (après s'ils ne savent pas faire un copier/coller c'est un autre problème ) Bref, merci @Fred.domotique à première vue j'ai l'impression qu'il y a tout ce qu'il faut. Il faudra que je me plonge dans l'analyse à l'occasion, mais très honnêtement ça ne sera pas pour tout de suite, car il faudra surement que je tente de reproduire chez moi. En attendant, vu que tu as une solution qui fonctionne en décalant la règle, je te conseille de procéder ainsi.

Les passerelle Envoy communique en CPL avec les micro-onduleurs, et il faut vraiment qu'ils ne soient pas loin... C'est d'ailleurs un problème pour moi, je suis obligé de brancher la passerelle sur le tableau du garage (là où arrivent les micro-onduleurs) Si je la branche sur le tableau de la maison, alors elle ne communique plus avec les onduleurs, pourtant il y a maxi 20m de câble (6mm²) entre la maison et le garage. Par contre, une fois la 1ère communication établie, et les microonduleurs initialisés (avec le profil VFR2019 France), ils continent à produire quoi qu'il arrive, même si la passerelle est débranchée. C'est juste que tu perdras le monitoring. L'application Toolkit, c'est uniquement pour la configuration en local via Wi-Fi. Il faut utiliser l'application Enlighten pour le monitoring, le suivi, etc. Tout passe par le cloud, les mêmes infos sur accessibles via l'application ou directement sur le site Web une fois que tu as créé ton compte.

Maintenant que tu le dis, je crois me souvenir que c'est @pepite qui nous avait rapporté que son volet était livré d'usine comme cela, et qu'il n'a jamais pu le piloter. Un test que tu peux faire, c'est brancher les 2 fils en direct sur l'alimentation entre le 0 et le +24V pour voir si le volet réagit, sans passer par le module Qubino. Et ensuite tu inverses les 2 fils. Normalement, dans un sens le volet doit monter, et dans l'autre il doit descendre. S'il ne réagit à aucun des 2 câblages, alors il est en mode "courant porteur" et n'obéira qu'au contrôleur officiel de Velux.

Attention, si tu as utilisé une fois ton volet avec l'alimentation/contrôleur Velux, alors il a été configuré en mode courant porteur, et ne peut plus être piloté par inversion de polarité (cas du Qubino) Sur les anciens modèles, il existait une procédure de reset du volet, permettant de le remettre en configuration usine, et donc de le piloter à nouveau avec un module domotique. Je ne suis pas certain que cette procédure de reset soit encore disponible, j'avais cru lire que Velux l'avais supprimé afin d'enfermer définitivement les clients dans son propre écosystème. Quoi qu'il en soit, il faudrait déjà retrouver la procédure de reset en question.... elle se trouve sur une page d'un forum quelque part sur la toile, je pense qu'on en a déjà fait référence ici, essayer de parcourir le topic... sinon Google est on ami.

Bienvenue sur le forum

debug => affichage de messages basiques, pour aider l'utilisateur à comprendre le fonctionnement (ou non) de ses propres règles lldebug (pour Low-Level) => affichage de messages supplémentaires pour aider les développeurs (= moi et quiconque voudrait bien se joindre à l'aventure) à comprendre les bugs dans GEA

cette histoire d'ordre des règles ressemble à un effet de bord dans la logique de gestion des statut des devices, mais je n'arrive pas à comprendre. Quelques remarques cependant : - je vois dans ton log que GEA est suspendu, c'est normal ça ? Parce que s'il est suspendu, il ne va pas gérer les règles correctement. - tu as mal dû positionner le GEA.lldebug = true, car il doit être dans la fonction config()

Oui pourquoi, tu as des soucis ? Si tu as des problèmes, il s'agit plus probablement d'incompatibilité avec le modèle de robot.

Welcome to the forum

La syntaxe semble correcte. Tu peux activer le mode GEA.lldebug = true et relancer, et surtout regarder les logs que tu as pour cette ligne, puis 10 secondes plus tard.

Il n'y a pas de raison, tout ce qui peut être fait en LUA peut également être fait par HTTP, pour la simple et bonne raison que tout passe par l'API. Pour les scènes, voir le Swagger : /api/scenes/ID/execute Cependant, sur HC3, il y a une limitation par rapport à la HC2, puisque les scènes ne peuvent plus recevoir de paramètres.

Oui ça m'a l'air bon.

Il faut que tu entoures les 2 actions par des accolades.

Effectivement, sur la VF aussi j'ai Integration pour le module GEA, c'est la 1ère fois que je vois ça, ils ont dû changer l'affichage lors d'une mise à jour intermédiaire, pourtant c'est bien le type com.fibaro.deviceController Je trouve que ce n'est pas parlant du tout, mais bon, la logique polonaise est parfois très différente ("Notation polonaise inverse" pour ceux qui connaissent, souvenirs de calculatrice HP...) En fait les fichiers FQA contiennent le JSON du QuickApp.

Tu as édité entre temps, mais je répond quand même à la question. Tous les types de QA ne sont pas dispos lors de la création d'un QA via l'interface Web. L'astuce consiste à créer un QA de type bidon (par exemple generic), de l'exporter, modifier le fichier fqa avec un éditeur de texte sur ton PC afin de changer la valeur du champs type, puis de le réimporter. Il aura alors le bon type. Et tu peux supprimer l'ancien que tu as utilisé temporairement avant l'extraction (ou l'utiliser pour autre chose) Bon pour toi le type rollerShutter existe bien de base donc l'astuce n'a pas lieu d'être : Je ne connais pas le type 'Integration', je ne vois pas de quoi tu veux parler.

Welcome to the forum

Rien de surprenant en fait, il a été confirmé que l'intervalle de réveil n'aurait aucun impact sur la lecture de la sonde, cf discussion ci-dessus. Tu dois avoir un paramètre dans le module qui permet de configurer l'intervalle d'envoi des mesures de températures. Je n'ai pas ces têtes thermostatiques donc je ne fais que supposer, mais en tout cas ça fonctionne ainsi pour tous les modules (Motion Sensor, etc...) EDIT : tu parles de mise à jour le 20 avril, mais de quoi ? Du module, de la box ? C'est une piste en tout cas.

Bienvenue sur le forum

Tu devrais poser ta question dans la section appropriée (éclairage) Mais perso je déteste les montages complexes (va et viens, permutateur, etc), c'est ingérable. Dès que j'ai au moins 2 points de contrôles, je fais un montage de type télérupteur. Simple et efficace.

L'ajout de boutons, sliders, labels etc sur un child device n'est officiellement pas supporté. On peut y arriver via un hack, mais c'est pas simple (surtout si tu n'es pas à l'aise en LUA avec l'API de Fibaro), et surtout aucune garantie que ça fonctionne éternellement. Bref, je ne te le conseille pas. Pour gérer les volets, le plus simple est de créer un QA du bon type, à savoir un rollerShutter, qui présentera d'office les boutons haut/bas nécessaires, ensuite tu as juste à coder le contenu des fonctions open et close. Le plus simple est de créer un QA tout simple du bon type via l'interface Web et de s'inspirer du code généré automatiquement par Fibaro.

Jarvis déjà entendu parler, Snowboy en revanche pas du tout. Mais je ne suis pas le bon interlocuteur pour le choix d'assistant vocal, car je n'aime tout simplement pas parler à la machine. Et cela indépendamment des problématique de vie privée, de toute façon Google possède déjà toute ma vie numérique, et ce depuis plus de 10 ans. Pour mon plus grand bénéfice, c'est un contrat gagnant/gagnant (jusqu'à présent en tout cas)