Lazer

Cool merci pour le retour Refresh à 1 seconde, tu es joueur toi, entre la charge sur la HC3, et plus encore sur l'IPX800 en fasse, c'est pas idéal.... la doc de GCE mentionne qu'il faut éviter de l'interroger trop souvent. Et j'ai déjà constaté quelques ralentissement sur mon IPX800 justement quand je fais trop d'interrogations dessus. Tu nous diras si ça tient bien la charge à la longue.

Nouvelle version 3.20 en première page et mise à jour du tuto. Ajout d'une variable HC3_BACKUP_HISTORY permettant de spécifier si la sauvegarde doit contenir l'historique ou pas Changement des noms HC3_VARIABLE_NAME et HC3_VARIABLE_IS_VALUE pour une meilleure compréhension Ajout de 2 nouveaux filtres sur le Profil actif permettant de bloquer la sauvegarde : HC3_PROFIL_IS_VALUE et HC3_PROFIL_NOT_VALUE Le nom du fichier sauvegardé sur le disque du NAS comporte maintenant la version et la mention beta/stable.

J'ai commencé à préparer une nouvelle version du script de backup sur NAS, et je constate dans la doc (Swagger) que l'API propose des nouvelles options relatives au backup automatique (local et cloud) Donc il faut s'attendre à des nouveautés de ce coté là dans un prochain firmware, le temps qu'ils codent une nouvelle case à cocher dans l'interface graphique. Accessoirement, ajouter de l'espace sur le cloud, c'est pas normal qu'avec une HC2 on puisse avoir 500 Mo, et qu'on soit limité à 50 Mo sur la HC3....

Il ne me semble jamais avoir eu de soucis avec "Inverse", pourtant j'en utilise beaucoup. La solution de contournement, c'est de tester la "Value" du module dans les conditions. Sur HC2, quelque chose comme : GEA.add({"Value", id["PORTE_JARDIN3"], "0"}, 60, ... Ou sur HC3 : GEA.add({"Value", id["PORTE_JARDIN3"], false}, 60, ...

Mais vous avez été si vilains que ça pour être punis à ce point ? SFR, c'est le pire des châtiments... La bonne nouvelle, c'est le moment de choisir un vrai opérateur !

[Blog Domadoo] FIBARO décline sa gamme d’appareillage Walli en couleur Anthracite

Non je n'ai pas ça sous la main. C'est pas en standard dans les Synology ? Sinon j'avais déjà partagé un script sur le forum qui permettait de détecter le changement d'adresse IP publique. Ensuite, il n'y a plus qu'à ajouter une fonction pour mettre à jour le DynDNS dès que l'IP a changé.

Tu peux faire la mise à jour de DynDNS depuis un NAS. Ou mieux, depuis la box domotique si tu veux t'amuser un peu en LUA !

Pour le FGD-212 je ne sais pas trop, mais je sais que le FGD-211 fonctionne très bien sans charge.

J'ai séparé ton message pour en faire un nouveau sujet dédié afin de ne pas mélanger l'application tablette avec l'application mobile/smartphone J'ajoute les preview officielles de Fibaro pour présenter un peu l'application (qui semble juste être l'application smartphone en plus grand, peu de différence significatives)

Bienvenue sur le forum

Bienvenue sur le forum

Unifi Door Access Pour fêter le vol des données sur le cloud Ubiquiti, ils lancent une gamme de produit autour de la serrure connectée, avec gestion centralisée. Le Cloud c'est bon, mangez en. Ou pas. https://unifi-network.ui.com/door-access L'offre a l'air sympa, mais clairement orientée entreprise, pas certain d'y trouver un intérêt pour les particuliers. Pour ceux qui veulent quand même tenter l'aventure : Aucune annonce de disponibilité en Europe (janvier 2021)

Tu utilises un EDRT2, et les types prédéfinis X400-CT-xxA sont pour les pinces de l'IPX800 (car elles sont assimilables à des entrées analogique virtuelles, donc retourne la valeur brute du convertisseur ADC, c'est pour cela qu'il faut appliquer une formule de calcul) Sur EDRT2 tu n'as pas besoin, car celui-ci présente déjà la bonne valeur. Car si tu appliques une formule sur la valeur, ça te sort un résultat délirant. Par ailleurs, quand tu vas chercher Index, tu n'obtiendras pas une puissance, mais un index (une énergie donc) Le seul moyen que j'ai trouvé pour lire les puissances instantanées (en W) des pinces sur EDRT2, c'est de les associer à des sous-postes, et d'aller lire leur valeur avec Get=S Tu peux t'inspirer de la ligne de config que j'ai donné en exemple pour attribuer la puissance à la propriété value de ton enfant PowerSensor : {device = {name = "Pince ECS", type = "PowerSensor"}, value = {command = "Get", argument = "S" , pin = "P1_SSP1"}},

Effectivement, merci pour la suggestion, j'apporterai cette modification du calcul du kWh dans la prochaine version. En ce qui concerne les FP, je pense plutôt que je vais faire exactement comme les Qubino. C'est à dire créer un child de type multilevelswitch (un dimmer quoi) ce qui permettra de piloter les 6 ordres. J'ai déjà remarqué dans la doc que les ordres sont inversés, ce n'est pas très logique, mais pas un souci. Je vais me charger de transcrire chaque numéro d'ordre vers une valeur du multilevel de 0 à 99 afin de correspondre à ce que fait le Qubino. De cette façon, ça sera générique et identique à l'intégration native d'un module Z-Wave. Ensuite, libre à chacun d'utiliser un QuickApp externe identique à ce qu'on fait pour les Qubino (d'ailleurs je pense que ça devrait être le même QuickApp), qui va permettra d'afficher 6 boutons avec les icônes associées, ou bien encore de type thermostat pour ceux qui veulent faire de la régulation depuis la box. Ou même un binary switch pour ceux qui veulent juste faire du Confort/Arrêt. Et non, pas possible en standard de personnaliser l'apparence des modules enfants...

Mais sinon, il y a moyen de le faire de façon plus élégante avec GEA lui-même (et cela peut s'appliquer à n'importe quel QuickApp) Puisque tu connais l'ID de ton icône, tu peux créer une règle qui ne se lance qu'au démarrage de GEA : GEA.add(true, 0, "", {"CurrentIcon", <id_module>, <no_icon>}) Ou bien via l'API http comme je disais hier : /api/callAction?deviceID=xx&name=updateProperty&arg1=deviceIcon&arg2=yy Bon ça ne résout pas le problème de devoir importer l’icône sur un autre module, pour ensuite aller chercher son ID à la main, mais ça devrait répondre à ton besoin.

Avec le mail d'Ubiquiti en question si certain ne l'ont pas reçu. En tout cas bien content de ne pas utiliser le contrôler via le cloud. PRODUCTS SHOP COMMUNITY SUPPORT Dear Customer, We recently became aware of unauthorized access to certain of our information technology systems hosted by a third party cloud provider. We have no indication that there has been unauthorized activity with respect to any user’s account. We are not currently aware of evidence of access to any databases that host user data, but we cannot be certain that user data has not been exposed. This data may include your name, email address, and the one-way encrypted password to your account (in technical terms, the passwords are hashed and salted). The data may also include your address and phone number if you have provided that to us. As a precaution, we encourage you to change your password. We recommend that you also change your password on any website where you use the same user ID or password. Finally, we recommend that you enable two-factor authentication on your Ubiquiti accounts if you have not already done so. We apologize for, and deeply regret, any inconvenience this may cause you. We take the security of your information very seriously and appreciate your continued trust. Thank you, Ubiquiti Team

Bof... non désolé, pas trop envie de mettre de rustine et de hack, ça ne sera pas pérenne. Je l'ai trop fait sur HC2... Attendons patiemment que Fibaro nous le permette en natif. D'ailleurs plutôt que de mettre une ligne de LUA dans le code, la modif peut être faite en passant par l'API http, à la limite je trouve ça presque plus propre.

J'ai ajouté dans le tuto le paragraphe pour la création des événement Push. Cette étape est facultative, mais elle permet de remonter instantanément les changements d'états des entrées sorties sans attendre que la boucle infinie du QuickApp ne mette à jour la valeur des modules. Indispensable si vous avez des détecteurs d'ouverture ou de mouvement branchés sur les entrées de l'IPX800. Utile pour tout ce qui est lumière, etc. Au final, l'intégration des modules de l'IP800 dans l'interface de la HC3 est tout à fait similaire à celle des modules Z-Wave, impossible à l'usage de voir la différence. Très confortable via l'application mobile.

Je pense que tu devrais regarder mon nouveau QuickApp, qui adresse le sujet des pinces ampèremétriques en permettant d'associer la consommation aux modules dans la HC3. D'ailleurs je vais faire de ce pas les captures d'écran pour mettre à jour le tuto avec le Push (états binaires, mais aussi consommation des tores)

Théoriquement oui (utiliser argument = "VR"), mais je n'ai pas pu tester car je ne dispose pas de cette extension.... donc je compte sur toi pour me faire un retour. Si ça ne fonctionne pas, il faudra copier/coller l'extrait du debug affiché.

Non, là tu n'as clairement pas édité le bon QuickApp (cela doit être l'un des tiens) Il faut importer le fichier fqa du tuto (d'ailleurs je viens de le renommer, il portait la mauvaise extension json, merci au lecteur de l'ombre qui se reconnaitra pour me l'avoir signalé ) Et c'est ce QuickApp qu'il faudra modifier, et uniquement le fichier config (pas le main) comme indiqué dans la capture d'écran du tuto. PS : si tu débutes, tu n'as pas choisi le QuickApp le plus simple... bon courage !!

@Dgille Tempo ça devrait fonctionner. Mais les FP ne sont pas encore supportés, je pense que ça sera sous forme de multilevelswitch comme les Qubino.

Et voilà enfin une version partageable du QuickApp pour IPX800 v4 et EcoDevice RT2 :

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