Lazer

QuickApp GCE Electronics IPX800 v4 - EcoDevice RT2 Version 1.20 Présentation : Ce QuickApp permet de piloter les 2 produits suivants du fabricant français GCE Electronics : IPX800 v4 EcoDevice RT2 Remarques : Un même QuickApp ne peut pas piloter 2 produits différents, il faut donc importer 2 fois le QuickApp pour piloter un IPX800v4 et un EDRT2 (ou bien 2 IPX800v4 distincts) Un seul QuickApp peut piloter un IPX800v4 ou un EDRT2 avec toutes leurs extensions branchées derrière (cependant toutes les extensions ne sont pas encore supportées dans la version actuelle) C'est un QuickApp assez complexe, qui permet de piloter des appareils assez complexes (l'IPX800 à lui tout seul est presque une box domotique), avec de très nombreuses possibilités de configuration. Tout n'est pas encore supporté, et il peut subsister des bugs... Installation du QuickApp : Importer le QuickApp (fichier fqa) de façon habituelle sur la box Home Center 3, puis changer les paramètres suivants dans l'onglet Variables : Protocol : protocole à utiliser, normalement : http (le mode direct sur socket TCP n'est pas encore disponible) Address : adresse IP du NAS, par exemple : 192.168.1.1 Port : port de communication, normalement : 80 API_Key : clé API configurée, par exemple : apikey Refresh : intervalle de rafraichissement des informations en secondes, par exemple : 60 (il n'est pas forcément judicieux de baisser cette valeur, car la suite du tuto explique comment configurer la remontée instantanée des changements d'état en mode push) Configuration du QuickApp : C'est la partie la plus complexe, car il faut associer chaque module enfant à créer dans la HC3 avec les différentes entrées/sorties de l'appareil IPX800/EDRT. Chaque module enfant prendra donc la valeur (propriété value) correspondant à l'état de l'entrée/sortie physique ou virtuelle, qu'elle soit analogique ou numérique (improprement appelé digital, terme anglais, dans la doc officielle) En complément, si l'on dispose de pinces ampèremétriques (tores), on peut ajouter la mesure de puissance en Watts (propriété power) et de consommation en kWh (propriété energy) sur chaque module enfant concerné. Très pratique pour toutes les sorties de type relai. Ne modifier que le contenu du fichier config : CONFIG : obligatoire : table : Tableau contenant toute la configuration des modules enfants à créer avec leur association aux différentes entrées sorties de l'IP800 v4 ou EcoDevice RT2 device : obligatoire : table : Déclaration du module enfant à créer name : obligatoire : string : Nom du module enfant type : obligatoire : string : Type du module enfant parmi les valeurs suivantes : BinarySensor | MotionSensor | DoorSensor | WindowSensor | GateSensor | RainDetector | TemperatureSensor | HumiditySensor | LightSensor | MultilevelSensor | PowerSensor | PowerMeter | BinarySwitch | LightSwitch | EnergyMeter | WaterCounter | GazCounter | RollerShutter | FilPilote | Teleinfo unit : facultatif : string : Unité de mesure du module options : facultatif : table : Options spécifiques pour Teleinfo sur EDRT2 value : obligatoire : table : Définition de l'entrée sortie sur l'appareil GCE IPX800 v4 ou EDRT2 command : obligatoire : string : Commande de l'API, parmi les valeurs suivantes : Get | Index | DIndex | Price | DPrice argument : obligatoire : string : Argument de l'API, parmi les valeurs suivantes : A | VA | C | D | VI | PW | R | VO | VR | S | P | T | XTHL | XENO | TI | FP pin : obligatoire : string : Nom exact du port d'entrée/sortie retourné par l'API, par exemple "R1", "A2", "D3", "C4", "VR1-2", ... type : facultatif : string : Type du capteur prédéfini parmi les valeurs suivantes (applicable aux entrées analogiques) : "SHT-X3-Temp-TC5050" | "SHT-X3-SH100" | "SHT-X3-Light-LS100" | "TC100" | "X400-TC100" | "XTHL-Temp" | "XTHL-Hum" | "XTHL-Light" formula : facultatif : function : Fonction permettant de calculer la valeur finale, typiquement pour les capteurs analogiques non prédéfinis par leur type, ou bien pour inverser l'état d'une valeur binaire power : facultatif : table : Définition d'une entrée de comptage (tore) permettant d'ajouter la mesure de puissance (en Watts) au module enfant command : obligatoire : string : Commande de l'API, par exemple "Get" argument : obligatoire : string : Argument de l'API, par exemple "VA", "S", ... pin : obligatoire : string : Nom exact du port d'entrée retourné par l'API, par exemple "VA17", "P1_SSP1", ... type : facultatif : string : Type du capteur prédéfini parmi les valeurs suivantes : "X400-CT-10A" | "X400-CT-20A" | "X400-CT-50A" | "X400-CT-100A" formula : facultatif : function : Fonction permettant de calculer la valeur finale, typiquement pour les capteurs analogiques non prédéfinis par leur type energy : facultatif : table : Définition d'une entrée de comptage (tore) permettant d'ajouter la mesure d'énergie (en kWh) au module enfant command : obligatoire : string : Commande de l'API, par exemple "Get" argument : obligatoire : string : Argument de l'API, par exemple "C", ... pin : obligatoire : string : Nom exact du port d'entrée retourné par l'API, par exemple "C1", ... formula : facultatif : function : Fonction permettant de calculer la valeur finale, typiquement pour convertir les Wh en kWh Pour explorer les noms des entrées/sorties disponibles (pin), se référer à la documentation officielle du Wiki GCE : API IPX800 v4 : https://wiki.gce-electronics.com/index.php?title=API_V4 API EcoDevices RT2 : https://wiki.gce-electronics.com/index.php?title=API_EDRT Cas particulier : la Téléinfo sur l'EcoDevice. Ce module enfant est de type com.fibaro.energyMeter, et permet de remonter les 2 informations suivantes : puissance active (W) dans la propriété value, et énergie (kWh) dans la propriété energy (cette dernière propriété contient la somme de tous les index des différentes tranches horaires de l'abonnement en cours). Cependant il ne faut pas spécifier power et energy dans la ligne de configuration. La syntaxe comme donnée en exemple est correcte, en spécifiant pin = "EAST" (Energie Active Soutirée Totale) : {device = {name = "Téléinfo", type = "Teleinfo", options = {VG = "TELEINFO_Tarif"}}, value = {command = "Get", argument = "TI", pin = "EAST"}}, Note : cette ligne de configuration doit être recopiée telle quelle, quel que soit le mode de la téléinformation (standard/historique) ou le contrat d'abonnement (Base, HC/HP, Tempo, EJP, etc.). Remarquez également le paramètre VG qui permet de stocker le tarif en cours (HC/HP) dans une variable globale, information qui peut être utilisée dans des scénarios. Celle-ci est créée automatiquement : Si vous disposez d'un compteur Linky en mode Standard, avec des panneaux photovoltaïques, il est également possible de récupérer l'injection, en spécifiant pin = "EAIT" (Energie Active Injectée Totale) : {device = {name = "Injection", type = "Teleinfo"}, value = {command = "Get", argument = "TI", pin = "EAIT"}}, Création des modules enfants : Cliquer sur le bouton "Create Devices". Les modules enfants sont automatiquement créés dans l'interface.  Les appuis suivants sont inutiles, et sans danger, car les modules enfants ne seront pas créés plusieurs fois. Configuration des événements Push : Cette étape est facultative. Les événement Push permettant de remonter instantanément le changement d'état d'une entrée/sortie sans attendre au maximum 60 seconde que le QuickApp ne relise de lui-même la nouvelle valeur.L'idée est d'appeler la fonction push() de chaque module enfant identifié par son ID, en lui passant en argument la nouvelle valeur. Exemples de configuration sur IPX800 v4 : Pour un relai, ou de façon plus générale toutes les entrée/sortie de type numérique, c'est à dire prenant 2 valeurs binaires (ouvert/fermé, on/off, ...) Dans la configuration des Périphériques, créer un Push : Entrer les informations suivantes : - Adresse IP de la HC3 - utilisateur et mot de passe (il est formellement déconseiller d'utiliser le compte admin, il faut créer un compte dédié sur la HC3 avec les droits d'accès uniquement aux modules enfants créés par le QuickApp) - URL ON : /api/callAction?deviceID=93&name=push&arg1=1 - URL OFF : /api/callAction?deviceID=93&name=push&arg1=0 Remplacer uniquement l'ID par celui de votre module enfant. Notez sur seul la valeur de l'argument change entre ces 2 URL. Dans les Scénarios, créer une nouvelle Scène, avec une action ON/OFF : Choisir le relai qui déclenche l'événement : Choisir le Push créé précédemment : Tester le bon fonctionnement. Le changement d'état de l'entrée/sortie sur l'IPX800 doit être répercuté immédiatement dans la box HC3, que ça soit sur l'interface Web ou bien l'application mobile. De plus, la zone de debug du QuickApp doit faire apparaitre un message similaire : [11.01.2021] [21:38:20] [DEBUG] [QA_IPX800_46]: onAction: {"args":[1],"deviceId":93,"actionName":"push"} [11.01.2021] [21:38:20] [TRACE] [QA_IPX800_46]: Digital Output R1 #93 Néon établi R1 value changed from false to true Pince ampèremétrique, ou de façon générale toute entrée analogique (la pince ampèremétrique branchée sur l'extension X400-CT est un cas particulier qui est reconnue comme une entrée analogique virtuelle) Les URL à saisir sont un peu plus particulières, car on va passer 2 arguments : la valeur proprement dite de l'entrée analogique, ainsi que l'attribut "power" : - URL ON : /api/callAction?deviceID=93&name=push&arg1=$VA17&arg2=power - URL OFF : /api/callAction?deviceID=93&name=push&arg1=$VA17&arg2=power Cette fois-ci les 2 URL sont identiques, il faut juste remplacer l'ID et l'identifiant de l'entrée analogique Dans les Scénarios, créer une nouvelle Scène, avec une action ON/OFF : Choisir l'entrée analogique, avec les 2 seuils haut et bas qui déclenchent l'événement : Choisir le Push créé précédemment : Tester le bon fonctionnement. Par exemple en couplant un Push pour le changement d'état du relai comme décrit plus haut, et un push pour le passage de la consommation au dessus du seuil (47 W dans mon exemple), le log affiche les 2 événements qui s'enchainent instantanément : [11.01.2021] [21:38:20] [DEBUG] [QA_IPX800_46]: onAction: {"args":[1],"deviceId":93,"actionName":"push"} [11.01.2021] [21:38:20] [TRACE] [QA_IPX800_46]: Digital Output R1 #93 Néon établi R1 value changed from false to true [11.01.2021] [21:38:21] [DEBUG] [QA_IPX800_46]: onAction: {"args":[558,"power"],"deviceId":93,"actionName":"push"} [11.01.2021] [21:38:21] [TRACE] [QA_IPX800_46]: Digital Output R1 #93 Néon établi R1 power changed from 0.0 to 192.0 Graphiques Téléinfo sur NAS : Teaser Changelog : v1.00 : Janvier 2021 Version initiale v1.10 : Mars 2021 [IPX800] Correction de l'inversion des volets roulants [IPX800] Ajout des formules pour la sonde TC-100 (capteur de température) [IPX800/EDRT2] Ajout du support de l'extension X-THL (sonde de température/humidité/luminosité) [IPX800/EDRT2] Ajout du support de l'extension X-4FP (fil pilote) [EDRT2] Ajout du support des abonnements TEMPO et EJP [EDRT2] Ajout du support du compteur Linky en mode téléinfo standard [EDRT2] Ajout du support des commandes "DIndex", "Price" et "DPrice" v1.20 : Janvier 2022 Lorsque le QuickApp parent est désactivé (disabled), les enfants sont également désactivés automatiquement, et un message figure sous l’icône (log) => et donc exclus de DomoCharts Amélioration de l'état de nœud mort (dead) lors d'un problème de communication réseau Le QuickApp répond aux sollicitations de réveil (wakeUpDeadDevice) Ajout des nouveaux types EnergyMeter (com.fibaro.energyMeter) et PowerMeter (com.fibaro.powerMeter) Le type PowerSensor (com.fibaro.powerSensor) est déprécié par Fibaro et ne devrait plut être utilisé (mais il est toujours fonctionnel, comportement identique au nouveau type PowerMeter) Le type Teleinfo est maintenant de type "com.fibaro.energyMeter" afin d'être configurable comme Compteur d’énergie principal dans les paramètres de la HC3 Le type Teleinfo ne remonte plus la puissance apparence (en VA) dans sa propriété value (de toute façon c'était une information peu utile) Le type Teleinfo remonte l'index d'énergie (en kWh) dans sa propriété "value", et la puissance active (en W) dans sa propriété "power". Le type Teleinfo supporte l'injection dans le cas où le compteur Linky est paramétré en mode Standard Correctifs et améliorations divers Téléchargement : Nouvelle installation : importer le fichier suivant pour créer un nouveau QuickApp : GCE_v1.20.fqa Mise à jour : copier/coller le contenu des fichiers suivants dans le QuickApp existant : Fichier main : GCE v1.20 - Main.lua Fichier GCE : Library - GCE v1.21.lua Fichier tools : Library - tools v2.20.lua

Je ne sais pas si c'est disponible via l'interface Web, perso je passe par le JSON du module accessible par l'API HTTP grâce à son ID, par exemple pour 123 : /api/devices/123 Dedans tu verras toutes les propriétés disponibles, ainsi que les actions disponibles.

Une geekette

Bienvenue sur le forum

Non bien sûr, ça ne pose aucun souci vis à vis du fonctionnement du QuickApp. C'est juste que c'est sale, tu vas perdre la modif à chaque mise à jour, et ça ne posera pas de problème à Dragoniacs, mais conseiller ça à quelqu'un qui débute, ça va le perdre totalement. Bon, cela dit un débutant a peu de chance de se retrouver sur le topic de GEA.... Quoi que, l'objectif de GEA c'est de faire des scénarios avancés sans connaitre LUA.

Ah ouais, bizarre Parce que quand je regarde mon IPX800 v4, les entrées analogiques peuvent changer plusieurs fois par seconde, par exemple quand la température est entre 5.5 et 5.6°C comme c'est juste le cas maintenant. Il faut pouvoir configurer un hystérésis afin de ne pas flooder de messages.

Les gros constructeurs, qui produisent des maisons standardisés par centaines, n'ont pas besoin du passage du consuel. Ils doivent sous-traiter à des grosses sociétés d'électricien qui doivent avoir pignon sur rue et sont connues pour faire des installations conformes (ce qui ne veut pas dire de qualité..... )

Ah oui OK, je n'y étais pas du tout ! Je pensais aux connexions Push par HTTP dans la discussion. Je me souviens qu'on en avait parlé il y a quelques temps du M2M avec les sockets TCP (qui n'est pas du WebSockets, attention à ne pas confondre) Mais déjà que notre ami a du mal à faire 1 requête HTTP et récupérer la valeur, là tu vas définitivement le noyer Mais la connexion M2M n'a rien à avoir avec du Push, puisque tu dois ouvrir une socket TCP permanente vers l'IPX800, en échange de quoi celui-ci retourne une trame à chaque changement d'état. Je n'ai pas essayé sur l'IPX800 v4, je ne sais même pas si c'est disponible, je n'ai jamais vu cet écran. Enfin, je précise, le M2M existe, pour envoyer des commandes, ou pour lire des valeurs (en mode polling à intervalle régulieer), mais ce que je ne sais pas, c'est si l'IPX800 v4 envoie immédiatement une trame en cas de changement d'état (appelons-le Fake-Push ) EDIT pour préciser : Sur l'IPX800 v4, on peut ouvrir la socket pour le M2M, mais la case à cocher "send data on status change" n'existe pas, ni la sélection des inputs/outputs. (tient d'ailleurs, étonnant ce texte en anglais pour un produit franco-français) Tu remarqueras d'ailleurs que les entrées analogiques n'y sont pas, c'est logique, en vertu de ce que j'ai expliqué hier un peu plus haut sur la page.

Et 3 câbles Grade 3S dans une gaine de 25mm A passer dans la gaine en ligne droite avant de placer la gaine dans les murs !! Mais ça passe, j'ai pu amener 3 câbles à mon salon de cette façon (ce qui est insuffisant, j'ai rajouté en plus un switch)

Je pense que n'ai pas compris la question ? Il faut déclarer autant de push qu'il y a d'information à remonter... donc ça devient vite fastidieux si y'a des dizaines d'infos à remonter

OK So you can look at the DomoCharts project : Or @jjacques68 has done something like this on the forum, he pushes all data (not only sensors) to an external database.

Perso je n'ai pas encore fait de VLAN IOT, mais en faire un n'a d'intérêt que si tu bloques tout (via le firewall du routeur) entre le VLAN IOT et le VLAN interne. Idem entre le VLAN IOT et Internet. Du coup ça devient complexe, car il faut ouvrir tous les flux un par un, appareil par appareil, jusqu'à ce que ça fonctionne. Très largement au delà du simple contrôle parental, largement plus complexe. Exemples de règle : - caméras : aucun accès à Internet. Accès uniquement au Synology sur le LAN - Netatmo : aucun accès au LAN. Accès au site Web de Netatmo. - etc Si par contre tu choisis la solution simple des VLANs sans firewall entre les VLAN, bah... ça ne sert juste à rien, donc autant ne rien faire, c'est plus simple.

Mais t'as pas un bouton ajouter un paramètre tout en bas ? Sinon faut que tu décoches la case utiliser le template (car il n'y en a pas justement)

Un caprice sûrement

Non justement la loi imposant le réseau dans les maisons a été retiré il y a quelques années. Une belle aberration et un beau retour en arrière, mais c'est ainsi. Du coup c'est facultatif maintenant.

Y'a déjà un tuto pour çà Note : perso je ne l'utilise pas (encore ?), donc je ne pourrai pas beaucoup plus t'aider.

Mmh.... je crois qu'il n'existe rien en Unifi pour le contrôle parental, pour la simple et bonne raison que c'est du matos professionnel. La solution, c'est plutôt de contrôler le DNS, et pour cela PiHole est la meilleure solution (en plus de permettre de supprimer le pubs.... enfin c'était surtout l'usage premier même)

Q1 : euh.... c'est dans le contrat avec ton constructeur ça. Mais à mon avis t'es coincé, car les plaquistes, peintres, carreleurs, etc... ne pourront pas intervenir s'il n'y a pas d'éclairage, donc il faut bien qu'ils posent des interrupteurs... que tu vas jeter quand tu entreras dans la maison pour poser tes Walli. Reste le bon coin..... Q2 : à mon avis, tu leur dit de tirer des gaines vides, et tu passeras ton câble toi même. Avantage, tu pourras passer du bon câble (Grade 3s), sinon eux ils vont te passer du Cat5, voire pire, du cable téléphone (ça c'est vu)

Windows 3.x oui c'est sûr, c'était instable, je m'en souviens encore. Windows Meuh aussi (non... pire en fait) Le reste, l'histoire l'a fait. Le meilleur OS multiusage au monde, inégalé, mais sans cesse trollé parce que ça fait marrer les vieux geeks informatiques. Fibaro a eu au moins le mérite de faire tourner sa box sur un OS éprouvé pour se genre d'usage : Linux. Stable, une fois installé, on n'en entend plus parler. Dommage que leurs développements n'aient pas suivi..... Car justement, c'est bien le code de Fibaro qui "oublie" de killer l'ancienne instance de la scène avant de démarrer la nouvelle. Oui parce qu'au niveau de l'OS, chaque instance de scène (ou de VD), c'est un processus... donc qui vie sa vie de façon autonome tant qu'on le laisse faire.

Vu le succès de cette box sur le forum, j'ai peur que personne ne l'utilise par ici. Tu as dû le voir, ici c'est essentiellement Fibaro, ou plus généralement tout ce qui tourne autour du protocole Z-Wave. Un écosystème ouvert, sans limite, mais il est vrai, un peu complexe. Leroy Merlin a fait le choix des protocoles fermés par le biais des partenariats commerciaux avec quelques industriels. Alors peut-être que M. et Mme Michu en balade le dimanche à Leroy Merlin n'y verront que du feu, mais s'enfermer dans des technologies propriétaires, ce n'est clairement pas le choix qui permettra au Roi Pinpin de dominer le monde... Je crois qu'ils supportent EnOcean aussi, protocole ouvert, mais tellement limité (faible portée, peu de choix de module, etc) et couteux, que je ne suis pas certain que beaucoup de clients aient suivi. Le EnOcean, en dehors de quelques utilisations industrielles bien spécifiques, n'a jamais trouvé sa place sur le marché domestique (j'ai essayé, j'ai été déçu.... m'enfin au moins je suis fixé) Après je ne sais pas quelles sont tes attentes de la domotique... ton budget, et combien d'heures/jours/nuits/mois/années tu es prêt à y consacrer.

Oui le Push est plus pertinent (plus efficient surtout, en terme d'utilisation des ressources). Par exemple : partisan de .rump => Putch => Capitole Oup's, pas de politique Sérieux, le Push est adapté aux événements ponctuels, comme par exemple une entrée numérique (capteur qui passe de l'état ouvert à fermé, lumière allumée/éteinte, etc) En plus, cela est pertinent, car on connait immédiatement le changement d'état, pour agir en conséquence. Ex : mouvement => allumage auto de la lumière. Mais pas dans le cas d'une valeur analogique, qui par définition même, n'a pas de valeur finie, elle est perpétuelle variation parmi une infinité de valeur. Vu que l'IPX800 mesure les entrées analogique plusieurs fois par secondes, tu imagines le nombre de push du délire !! En plus, cette info n'est pas pertinente, jamais on a besoin de savoir en temps-réel que la température/humidité/luminosité vient de varier d'un 1/4 de poil de c....heveux. A la limite, tu peux te faire des triggers, des seuils (avec histérésis) sur l'IPX800 qui vont déclencher un push vers la HC3 en cas de dépassement de valeur analogique au delà d'un certain seuil. Là ça peut être utile, par exemple si la température passe en dessous de 19°C => Allumage du chauffage. Mais est-ce bien pertinent ? Je veux dire, avec un polling régulier de 60s, au pire, tu connaitra le passage de la température sous le seuil avec 60s de retard, ce qui ne change en rien l'inertie de la maison et le temps de réchauffer la température. J'avoue ne pas connaitre d'exemples pour lesquels un push immédiate d'une valeur analogique serait indispensable. Mon avis, le mieux c'est polling pour les valeurs analogiques, et push pour les valeurs binaires. Mais bien sûr, ça n'empêche pas de faire également du polling pour les valeurs binaires, comme je le fais dans mon futur QuickApp. L'avantage, c'est de récupérer quoi qu'il arrive les valeurs binaires, même si le push n'a pas eu lieu grâce à l'intervention de la police (oup's, encore.....)

Le truc à pas faire quoi, car cette modification sera perdue lors de la prochaine mise à jour de GEA... Mais sérieusement, je ne comprends pas l'intérêt de se prendre la tête juste changer l’icône de GEA ? Je veux dire, le module peut est caché, il n'apporte rien à l'interface, contrairement aux icônes des modules typés (sensor, actionneurs, etc) qui apportent soit une info (mesure), soit permette de faire une action (lumière, ...) A la limite, pour ceux qui utilisaient le VD Alarme de GEA, qui permet de programmer une heure de réveil (ou autre), l’icône a un intérêt car le module est visible et utile à l'interface. Mais pour GEA lui-même, comme dit ci-dessus, je trouve l'intérêt limité... surtout qu'il ne s'agit pas juste de cliquer sur un simple bouton ajouter icone.

Oui je pense aussi que nous n'aurons rien avant 1 an, comme ce fut le cas pour Z-Wave+ (500), puis la série 700

J'ai mis un screenshot justement => onglet de configuration avancé du module

It may be the case if the detection time of the motion sensor is below 30s (you can check its parameters) In that case, under certain circumstances, two consecutive regular GEA loops (every 30s) might not see the active motion sensor.... thus, GEA can never consider your second rule (the one with 60s) I am not sure to be clear.... First you could try to increase the motion sensor holding time to a value higher than 30s. Or you could try to add a "Repeat" action to GEA, but I am afraid of side effect : GEA.add(id["Hll_Pir"], 1*60, "", {{"Inverse"}, {"Repeat"}, {"Global", "Hll_Prsnc", "Absnc"}}) Or even better, something like that to test if the your global variable is different than "Absnc" AND no motion for at least 60s : GEA.add({id["Hll_Pir"], {"Global!", "Hll_Prsnc", "Absnc"}}, 1*60, "", {{"Inverse"}, {"Global", "Hll_Prsnc", "Absnc"}}) By the way, I am far from being an expert to advanced GEA usage, some people here have more experience and should help you... please