Lazer

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.51 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 color : facultatif : string : Code couleur HTML permettant de colorer l'affichage dans la fenêtre de log, par exemple "green", "blue", "red", "#ff7f00", ... virtualPower:facultatif: boolean : Applicable uniquement aux devices de type "EnergyMeter", avec la value true permettant de calculer la puissance instantanée du module 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 color : facultatif : string : Code couleur HTML permettant de colorer l'affichage dans la fenêtre de log, par exemple "green", "blue", "red", "#ff7f00", ... 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 color : facultatif : string : Code couleur HTML permettant de colorer l'affichage dans la fenêtre de log, par exemple "green", "blue", "red", "#ff7f00", ... 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 de 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.). Si on dispose d'un contrat TEMPO, on peut également ajouter les champs VG_Jour et VG_Demain qui permettent de récupérer dans des variables globales les couleurs du jour et du lendemain respectivement : {device = {name = "Téléinfo", type = "Teleinfo", options = {VG = "TELEINFO_Tarif", VG_Jour = "TELEINFO_Jour", VG_Demain = "TELEINFO_Demain"}}, value = {command = "Get", argument = "TI", pin = "EAST"}}, Les paramètres VG, VG_Jour et VG_Demain permettent de stocker le tarif en cours (HC/HP) et les couleurs de l'abonnement TEMPO dans des variables globales, informations qui peuvent être utilisées dans des scénarios. Celles-ci sont créées 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"}}, De même, il est également possible de récupérer la tension et/ou le courant mesurés par le compteur Linky avec les types "TeleinfoVoltage" et "TeleinfoCurrent" sur les pins "URMS1" et "IRMS1" respectivement : {device = {name = "Secteur" , type = "TeleinfoVoltage"}, value = {command = "Get", argument = "TI", pin = "URMS1"}}, {device = {name = "Téléinfo", type = "TeleinfoCurrent"}, value = {command = "Get", argument = "TI", pin = "IRMS1"}}, Options globales : Par ailleurs, il est possible de configurer des options globales à l'aide du paramètre "config". L'exemple ci-dessous affecte les paramètres suivants à toutes les entrées de type Get=S : refresh : intervalle de rafraichissement rapide de 7 secondes seulement, cela permet d'être plus réactif sur les variations de puissance instantanée que l'intervalle par défaut de 60s appliqué automatiquement à tous les autres pins variation : pourcentage de variation (à la hausse comme à la baisse), qui lorsqu'il est dépassé, déclenche la mise à jour immédiate du module enfant step : valeur absolue de variation (à la hausse comme à la baisse), qui lorsqu'elle est dépassée, déclenche la mise à jour immédiate du module enfant {config = {command = "Get", argument = "S", options = {refresh = 7, variation = 99, step = 200}}}, 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 v1.30 : Mars 2022 Le type FilPilote est maintenant de type "com.fibaro.multiPositionSwitch" Ajout du paramètre optionnel "virtualPower" pour les devices de type energy permettant le calcul de la puissance instantanée Améliorations mineures v1.31 : Mai 2022 Bug fix v1.40 : Septembre 2023 Intervalle de rafraichissement personnalisable pour chaque API Ajout de la tension (voltage) depuis la Téléinfo avec Get=TI Connexion API M2M sur le port TCP 9870 Amélioration de la gestion du QuickApp disabled (https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/66/#comment-250596) v1.50 : Janvier 2024 Ajout du courant IRMS1 depuis la Téléinfo avec Get=TI Ajout du décodage du registre STGE de la Téléinfo depuis Get=TI, apportant notamment la récupération des couleurs de l'abonnement TEMPO Ajout du paramètre optionnel color permettant de configurer des couleurs personnalisées d'affichage des messages dans le log Correction de certaines traductions v1.51 : Mai 2025 Bug fix Téléchargement : Nouvelle installation : importer le fichier suivant pour créer un nouveau QuickApp : GCE_v1.51.fqa Mise à jour : copier/coller le contenu des fichiers suivants dans le QuickApp existant : Fichier main : GCE v1.51 - Main.lua Fichier GCE : Library - GCE v1.51.lua Fichier tools : Library - tools v2.30.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)