Aller au contenu

vinzcenzo

Membres confirmés
  • Compteur de contenus

    59
  • Inscription

  • Dernière visite

Réputation sur la communauté

4 Neutral

À propos de vinzcenzo

  • Rang
    Membre interessé

Profile Information

  • Sexe :
    Homme
  • Ville :
    Bussigny, Switzerland
  • Intéret :
    ...
  • Box
    Home Center 2
    Home Center Lite
  • Version
    4.600

Visiteurs récents du profil

396 visualisations du profil
  1. vinzcenzo

    Centralisation de fonctions LUA dans une scène

    De mon côté ça fait plus de 20 ans que je fais de l'intégration IT en SSI dans le software dév. et dans les infrastructures réseau et sécurité (j'ai même eu l'occasion de créer et développer une société proposant produits pour le B2B sur des segments de niche) donc l'intégrateur pro je vois tout a fait ce qu'il a besoin... et effectivement un pro a besoin de ce que tu dis... mais pas que... Pour éviter de perdre de l'argent le pro à aussi besoin : d'un SAV digne de ce nom (ici en Suisse même les intégrateurs ont tout autant de problèmes à contacter et à être entendu par le support Fibaro!!!), c'est généralement le distributeur (qui est multi-marques) qui fait le job du constructeur.. c'est un peu ballaud quand même (lui aussi aimerai avoir plus de rentabilité j'imagine); d'outils de diagnostiques efficaces et professionnels, sans devoir faire du wireshark ou d'un analyseur de spectre de fréquence pour essayer de comprendre ce qui se passe dans la box de son client; de ne pas être obligé d'être lié à un système cloud pour des fonction de base tel que l'alerting ou le remote controle.... ceci pour ne pas être dépendant de l'infrastructure de Fibaro et pour des raison de confidentialité et du disponibilité du système; besoin de produits lui permettant de développer des services voir un écosystème à forte valeur ajoutée, donc un flexibilité et une toolbox digne de ce nom; Donc déjà nous sommes à des années lumière pour que Fibaro soit le produit idéal en terme d'intégration professionnelle... Ou alors ils ont vraiment foiré leur étude de marché, s'ils s'adressent qu'à ce type de personnes... Il ne faut dès lors pas se leurer, les box Fibaro vont rester pour une communauté de geeks ou d'utilisateurs démerdes. Monsieur et madame tout le monde auront plutôt tendance à se diriger vers du Apple HomeKit ou du Samsung SmartThings... contrôllé par du Siri, Google Assistant ou Alexa... Si aujourd'hui j’étais intégrateur, et devais intégrer professionnellement un produit domotique pour du Home Automation, je ne proposerait jamais du Fibaro, ou quelques autres solutions OpenSource soit dit en passant... Mais une vrais solution éprouvées dans le building automation fournis par un leader tel que par exemple ici en suisse Feller... mais nous ne sommes pas dans la même catégorie, et la tu ne peux dire que ça va pas plomber la rentabilité ou ne pas être fiable dans le temps... Question fiabilité, sécurité et stabilité rien à redire et ça fonctionne comme une horloge... Une blackbox c'est une chose... mais tu fournis la toolbox nécessaire à l'opération de ta solution... vu que tu bosses dans l'intégration UNIX, l'exemple VMware doit de parler. L'hyperviseur ESXi et très fermé voir limite blackbox et ce même sur une base Linux (base qui est devenu très propriétaire depuis un certaine nombre d'année maintenant). Mais d'un autre côté même en étant si fermée, ils offrent une palette d'outils de diagnostique et de déploiement phénoménal et l'hyperviseur n'en reste pas moins robuste... un ESXi tu le déploie sans problème jusqu'à la petit virgule de configuration en ligne de commande, ou avec des outils DevOPS tel que Ansible, et aussi tu peux valider tous tes métriques CPU/Memoire/Disques/Network avec un ESXTop. Et pour Linux/BSD tout à fait d'accord, et même au niveau distribution... un Ubuntu ne prendra pas le même temps à installer qu'une Gentoo ou qu'un Free/Net ou OpenBSD. Au final comme je l'ai dit auparavant, je ne chie pas du tout sur Fibaro... pour l'usage que j'en fait c'est cool. Par contre, il me manque indéniablement des choses pour que je soit OK de me diriger les yeux fermer sur une nouvelle HC3, sans remettre en question ce que j'ai, ce que je désire et ce que propose le constructeur...Heureusement qu'il y a une telle communauté de passionnés, parce que ça permet d’exploiter cette boite à fond et de na pas lâcher...
  2. vinzcenzo

    Centralisation de fonctions LUA dans une scène

    Je suis d'accord avec toi alors ... Oui, maintenant, la HC2 est bien stable, mais ça n'a pas toujours été le cas... même si souvent les problèmes de stabilités viennent de ce qu'on fait avec, mais encore une fois sans visibilité c'est compliqué de pouvoir diagnostiquer correctement et de savoir d'où ça vient Sinon pour rebondir aussi sur : Je pense que justement, si c'était vraiment l'orientation qu'ils voulaient donner, il y aurait un peu plus de possibilité de justement intégrer des choses "plus pro" et monitorer les choses par des professionnels. Il y a certes un pas dans ce sens avec la HC3... mais pas suffisamment à mon goût (je sais je suis un peu un chieur ) We'll see what happens...
  3. vinzcenzo

    Centralisation de fonctions LUA dans une scène

    Alors pour moi ce n'est pas qu'une question de prix... bien que ça me troue effectivement le cul de payer une box plus de 400€ pour un support inexistant! Avec Jeedom, Domoticz, HomeAssistant, openHAB (aussi) ça bouge quand même un peu plus... certes le côté app mobile est peut-être moins aboutie, mais ça évolue quand même assez rapidement et ça reste moins blackbox. Qu'on soit d'accord, je vais pas non plus chier sur Fibaro... car je trouve qu'il y a de très bonnes choses.... mais comme je l'ai dit dans un autre poste je peine à comprendre leur stratégie... j'aime bien leurs produits, mais leur approche client n'est pas à la hauteur de leurs prétentions marketing et je trouve dommage qu'il n'exploitent pas plus le potentiel qu'ils ont entre leurs mains!
  4. vinzcenzo

    Centralisation de fonctions LUA dans une scène

    Pour la HC3, je ne suis pas sûr que ce sera la solution pour moi... ce qui m'embête avec cette HC3 c'est de repartir dans la même logique d'utilisateur bêta testeur pendant de longues années, avec un produit qui marchotte de version en version, avant d'avoir un truc de stable. Ceci parce que Fibaro n'a pas su capitaliser sur sont expérience et a voulu repartir sur une feuille presque blanche. Mon premier objectif, avec cette centralisation, c'est d'épurer 5 ans de codage sur ma HC2... quand j'ai un bout de code avec min. 8 variantes mais qui font la même chose, je me dis que je peux mieux faire
  5. En évaluant le job que j’aurai potentiellement à faire pour changer de box, je me suis mis à inventorier le code LUA utilisé sur ma HC2. Je me suis rendu compte que j’avais dupliqué pas mal de code (fonctions, routines, etc.) et surtout lors de correction de certaines portions de code j’ai oublié de le corriger dans quelques scènes ou ce code était dupliqué… Alors ce week-end, j’ai planché sur une solution me permettant de simplifier mon code et de le centraliser. Donc voici ci-dessous, ce que j'ai effectué. Stratégie création d'une scène que j'ai nommée scGloFuncLib (id:186) et qui est structurée comme suit : VARIABLES/CONSTANTES PERSONNALISABLE PAR L'UTILISATEUR; variables et constantes, modifiable par l'utilisateur, lui permettant d'adapter les valeurs à son environnement; VARIABLES/CONSTANTES INTERNES (à ne pas modifier); variables et constantes, nécessaires au bon fonctionnement de la scène. La valeurs définies ici sont sensées être optimisées et ne devraient pas être modifiées par les utilisateurs => risques d'effets de bord non maîtrisés; LES FONCTIONS INTERNES les fonction internes sont les fonction qui ne sont pas appelée en dehors de la scène, mais qui sont utiles à aux fonctions "exposées"; LES FONCTIONS EXPOSÉES les fonctions exposées, sont les fonction accessibles avec un appel externe depuis une autre scène/VD; MAIN permet d'analyser les arguments et d'appeler les fonctions concernées en vérifiant et en passant les bons paramètres; appel de la scène susmentionnée depuis une autre scène/VD avec le code suivant : fibaro:startScene(186, { "myFunction1", "p1", "p2", "pN" }) Limitations La limitation de ce système pour l'instant et le retour de valeur entre la scène qui appelle la fonction et celle qui l'exécute. N'ayant pour l'instant pas ce besoin, je n'ai rien fait. Mais si cela devait changer, je procéderais certainement de la manière suivante : création d'une variable globale avant l'appel de la fonction; appelle de la fonction via la scène scGloFuncLib en passant le nom de la variable globale créée; récupération de la valeur de la variable globale; destruction de la variable globale. Squelette du code LUA ---- *********************************************************************** ---- VARIABLES/CONSTENTES PERSONNALISABLES PAR L'UTILISATEUR ---- *********************************************************************** ---- Description ---- variables et constantes, modifiable par l'utilisateur, lui ---- permettant d'adapter les valeurs à son système. ---- ------------------------------------------------------------------- ---- myFonction1 ---- ------------------------------------------------------------------- FUNCTION1_DEF_PARAM2 = "123456asdf"; ---- ------------------------------------------------------------------- ---- log_debug ---- ------------------------------------------------------------------- IS_DEBUG_MODE = true; ---- *********************************************************************** ---- VARIABLES/CONSTENTES INTERNES (à ne pas modifier); ---- *********************************************************************** ---- Description ---- variables et constantes, nécessaires au bon fonctionnement de la ---- scène. La valeurs définies ici sont ensées être optimisées et ne ---- devraient pas être modifiées par les utilisateurs => risques ---- d'effets de bord non maîtrisés. ---- ------------------------------------------------------------------- ---- System ---- ------------------------------------------------------------------- MD5_HASH = "cb2b8c02de4f322cd67fd8e7a88d420f"; ---- *********************************************************************** ---- LES FONCTIONS INTERNES ---- *********************************************************************** ---- Description ---- les fonction internes sont les fonction qui ne sont pas appelées ---- en dehors de cette scène, mais qui sont utiles aux fonctions ---- "exposées". ---- ------------------------------------------------------------------- ---- function : log_std ---- ------------------------------------------------------------------- ---- paramètres : ---- str : log a envoyer dans la fenêtre de debug ---- retour : <aucun> ---- ------------------------------------------------------------------- function log_std(str) if IS_DEBUG_MODE then fibaro:debug("<font color='yellow'>"..str.."</font>"); end end ---- *********************************************************************** ---- LES FONCTIONS EXPOSÉES ---- *********************************************************************** ---- Description ---- les fonctions exposées, sont les fonction accessibles avec ---- un appel externe depuis une autre scène/VD. ---- ------------------------------------------------------------------- ---- function : myFunction1 ---- ------------------------------------------------------------------- ---- paramètres ---- _param_no1 : paramètre1 ---- _param_no2 : paramètre2 ---- retour : <aucun> ---- ------------------------------------------------------------------- function myFunction1 (_param_no1, _param_no2) -- * exécution de ma fonction "exposée end ---- *********************************************************************** ---- MAIN ---- *********************************************************************** ---- Description : ---- la boucle principal permet d'analyser les arguments et d'appeler ---- les fonctions concernées en leurs passant les bons paramètres. ---- Arguments : ---- args[1] = <functionName> : nom de la fonction appelée ---- args[n] = <parameters> : parametres des fonctions appelées ---- ------------------------------------------------------------------- -- * première chose à faire vérifier s'il y a des arguments if fibaro:args() == nil then -- * pas d'argmuent alors on sort de la scène return else -- * arguments, alors on les entre dans une table func_args = fibaro:args(); -- * puis on vérifie que le premier argument (nom de la fonction) existe if func_args[1] == nil or func_args[1] == "" then -- * pas de args[1] alors on sort de la scène, car aucune fonction a appeler return -- * si args[1] = myFunction1 alors on traite les paramètres par rapport à cette fonction elseif func_args[1] =="myFunction1" then ---- ------------------------------------------------------------------- ---- calling myFunction1 function ---- ------------------------------------------------------------------- ---- Parameters : ---- args[2] = param_no1 (obligatoire) ---- args[3] = param_no2 ---- ------------------------------------------------------------------- local param_no1,param_no2 -- * vérificatio du premier paramètre args[2] qui est obligatoire if func_args[2] == nil or func_args[2] == "" then -- * le paramètre est obligatoire, alors si pas renseigné on sort de la scène return else -- * on attribue args[2] à la variable param_no1 param_no1 = func_args[2]; end -- * vérificatio du deuxième paramètre args[2] qui est facultatif if func_args[3] == nil or func_args[3] == "" then -- * le paramètre est facultatif, possibilité d'attribuer une valeur par défaut si vide ou null param_no2 = FUNCTION1_DEF_PARAM2; else -- * on attribue args[2] à la variable param_no2 param_no2 = func_args[3]; end myFunction1 (param_no1,param_no2); return else -- * si args[1] ne correspond à aucune des fonctions exposées (func_args[1] =="FunctionName") , alors on sort de la scène. return end -- fin de l'execution de la scène. end
  6. vinzcenzo

    Le futur de nos box HC2

    Merci Krikroff pour ton retour, ça me rassure un peu car, j’ai souvent lu que c’était un travail fastidieux de faire la transition HC2 -> HC3 et qu’il y avait encore pas mal de choses qui n’étaient pas encore au top… Mais effectivement Fibaro ne devrait pas faire régresser le produit avec la HC3, donc un transition 1:1 fonctionnelle c’est déjà bien. Cependant, avec la HC3 ce qui me fait peur c'est de repartir de longues années sur un produit qui va peu évoluer… je trouve qu’entre 2015 (année de mise en service ma box Fibaro) et 2020, il n’y a pas eu de transformations phénoménales du produit alors que 5 ans en année technologique ça fait long.. Et aussi, il y a trois points dans la stratégie de Fibaro que je peine à comprendre et que j’ai vu même vu régresser au fils des années : · obliger les utilisateurs de passer au travers de leur cloud pour : o les notifications intégrées, oui, on peut contourner ça, mais encore une fois pour des fonctionnalités sensées être built-in c’est dommage de toujours devoir trouver des work-arround ; o l’application mobile… impossible sur la nouvelle application HomeCenter de s’y connecter en local ou à distance sans passer par leur cloud ; · le manque de logs système sur le fonctionnement de la box, en effet près 20 ans dans le domaine de l’IT à y réfléchir c’est quand même bien la première fois que je rencontre un produit qui donne aussi peu d’accès aux informations sur les erreurs et la santé du système, pas facile pour le dépannage surtout qu’on est pas à l’abri d’erreur « algorithmiques » qui peuvent produire des problèmes sur le système; · limitation dans le LUA, j’imagine que c’est des questions de pseudo sécurité pour éviter que se glisse du code malveillant ou de trop exposer le système ; C’est un peu ça qui me refroidi aussi pour la suite… Mais sinon c’est vrai que la majeure partie de mes devices/sensors sont zwave et pour l’instant je ne pense pas massivement les changer.Donc fondamentalement ça ne devrait pas être le manque de protocoles supportés qui va me freiner pour la suite… surtout comme je l’ai écrit plus haut avec des RestAPI on doit pouvoir implémenter un joli « HUB » pilotable par une box Fibaro pour les autres protocoles.
  7. vinzcenzo

    Le futur de nos box HC2

    Pour cette question là... de mon côté je dirai : Zwave / 433Mhz / LoRa / Zigbee / Wifi / Bluetooth
  8. vinzcenzo

    Le futur de nos box HC2

    Alors le multi-protocol c'est effectivement ce qui pourrait me ferait changer de solutions... et encore... garder le "front-end" en Fibaro et intégrer une sorte de "HUB" opensource (pilotable avec des RestAPI/JSON) pourrait aussi être une solution intéressante de mon point de vue... mais le revers de la médaille : ça complexifie un peu les choses. Je trouvais intéressant la modularité (protocoles) de la Zipato... mais quitter pour repartir sur du propriétaire... je sais pas si ça vaut vraiment la peine...
  9. vinzcenzo

    Le futur de nos box HC2

    Bonsoir à tous, Un petit poste pour avoir vos avis sur le devenir de vos HC2… (j’espère être dans le bon chapitre ). Cela fait maintenant quelques mois, que je me pose des questions sur le sort que Fibaro va réserver à nos HC2. Quand on parle technologie on sait que les constructeurs n’aiment pas maintenir des vieux produits, car ils préfèrent se concentrer sur leur nouveau « flagships ». Et j’ai un peu l’impression que c’est ce qui se passe ou va se passer bientôt avec la HC3 chez Fibaro… Ne désirant pas me retrouver pris de court et les pieds au mur quand le « end of life » arrivera, j’essaie de réfléchir et de me projeter… mais j’ai de la peine à trouver la bonnes solutions et les bonnes réponses… L’herbe serait-elle plus verte ailleurs ? Produit open source, produit commercial… je ne crois pas avoir trouver le candidat parfait… les applications mobiles des concurrents sont souvent moins sexy et semblent être moins fonctionnelles… La HC3 serait-elle quand même intéressante ? mais suis-je prêt à recommencer une aventure avec un produit en perpétuelle bêta avec un support constructeur à côté de la plaque... au prix ou ils vendent la box, je ne suis pas sûr… Rester sur la HC2 en se faisant à l’idée de ne plus vraiment la voir évoluer et sans espoirs de voir ses points négatifs un jour améliorés… Voilà un peu ce qui me trotte dans la tête ... et accessoirement me bloque actuellement au niveau de la poursuite de mes projets d’intégration, ne sachant pas trop ou je peux/veux aller… Et vous ? Comment voyez-vous la suite de votre côté ?
  10. vinzcenzo

    Problèmes sur l'envoi d'emails d'alerte

    Si jamais, petit retour, pour ceux que ça intéresse Donc E-mails + alertes "Push" à nouveau fonctionnels dès 13h11 (+/- 10 minutes). Par contre, tous les mails qui sont partis entre hier env. 16h et aujourd'hui 13h11 aucune trace, ils ne sont jamais parvenu jusqu'au serveur SMTP de destination... Vive les boîtes noires !!
  11. vinzcenzo

    Problèmes sur l'envoi d'emails d'alerte

    Merci pour ta réponse. Alors, oui je suis sûr que seul les mails Fibaro sont concernés. J'ai deux autres utilisateurs (avec un mail un sur MS Office365 et un autre mail sur un serveur sendmail linux que je gère et qui n'a aucun anti-spam actif) qui ne recoivent pas non plus les mails d'alertes. Soit dit en passant, je ne reçois plus non plus de push sur l'application. La box Fibaro fait bien une connexion sur les serveurs fibaro à chaque envoi de mail, j'ai pu valider et vérifier ceci en générant des mails en LUA à interrvales régulières, puis avec une capture de paquets Wireshark, je vois bien des paquets cryptés qui sont envoyés sur les serveurs Fibaro aux mêmes moments. Donc je pense que je vais être patient et attendre…
  12. vinzcenzo

    Problèmes sur l'envoi d'emails d'alerte

    Bonsoir à tous, Je ne sais pas si je suis le seul dans ce cas, mais depuis quelques jour l'envoi des e-mails d'alerte de ma HC2 vacillent (délai de quelques heures entre l'événement et la réception du mail : fibaro -> gmail). Aujourd'hui depuis env. 16h plus de mail... Vu que tout passe par Fibaro sans que nous puissions contrôler la transmission d'alertes, est-ce que quelqu'un aurait une méthode miracle pour avoir plus d'info et ainsi savoir si c'est la box qui foire ou les serveurs Fibaro? Pour essayer d'y voir un peu plus claire sur les transmissions réseau, j'ai fait du WireShark, mais rien vu d'intéressant sur les paquets analysés (qui sont en grande partie crypté... heureusement pour la confidentialité ). Si jamais j'ai déjà redémarrer plusieurs fois ma HC2 (car dans le doute, reboot). Merci pour vos feedbacks.
  13. vinzcenzo

    Hc2 - Boitier Inacessible (Toutes Les Led Flashent Rapidement)

    ok effectivement si les paramètres restent, de même que l'heure et la date... Par contre, j'espère que tu ne mets pas tout tes espoirs dans le support fibaro, parce que pour moi il ne m'ont servi a rien... comme le H de Hawaii A l'époque je n'avais pas mis en copie la réponse qu'il m'avaient renvoyé (1 mois après que le ticket ait été ouvert) si jamais la voici, à savoir que dans le l'ouverture du ticket j'avais détaillé précisement le problème :
  14. vinzcenzo

    Hc2 - Boitier Inacessible (Toutes Les Led Flashent Rapidement)

    Réponse un peu tardive, mais comme on dit... vieux motard que jamais Pour moi le problème intervenait avant la sequence POST BIOS, elle se mettait sous tension correctement, mais ne démarrait pas la partie microcode sans devoir faire une sequence de touche improbable... Onduleur ou pas onduleur, ca n'aurai rien changé, ma box était juste déffectueuse. Pour en revenir au probleme de quack75, pour moi c'est plus un problème de configuration de BIOS. Si le BIOS ne garde pas la configuration, effectivement la pile être la cause la plus probable. Par contre dans ma HC2 la pile se retirait sans problème elle n'était pas encapsulée. @quack75 tu peux par contre vérifer facielement si c'est un réelle problème de pile, car généralement la date et l'heure reviennent à la date et heure de compilation du BIOS si tu enlève l'alimentation et que tu as bien déchargé toute l'életricité résiduelles dans les composants (en appuyant 5-10 second sur le bouton power après avoir enlevé l'alimentation). Dans mon cas le CMOS error n'était pas lié à la pile donc l'heure et la date restaient ok. Sinon, j'ai lu les points sur l'onduleur... Je suis du meme avis que quack75, meme si c'est recommandé, c'est pas ca qui devrait faire que sa box redémarre correctement après une coupure, mais bel et bien la configuration du paramètre dans le BIOS "After Power Faillure" -> "Power ON" ou éventuellement "Last State". L'onduleur va permettre de garder le système domotique fonctionnel lors d'une coupure local, si la coupure est générale que la domotique soit dispo ou pas ca devrait pas changer qqch . Et si la coupure continue, il arrivera peut être un moment ou la batterie de l'onduleur sera vide, donc la aussi ça serait bien que la box redémarre toute seule quand l'électricité revient! Enlever la prise et la remettre a part, de temps en temps, flinguer les alimentations, ne devrait pas avoir d'impact sur le matériel en lui meme, car vos PC et boxs ne fonctionnent pas directement en 230V AC, donc la tension est converties de AC en DC et de 230V en 12v/5v. Par contre, ce qui flingue le matériel ce sont les mauvaises isolations des composants, une différence de potentiels entre deux terre (oui oui ca existe, déjà vu), les décharges électrostatique, ... Si on essaie de faire une shutdown ou reboot propre d'une machines c'est pour réduire le risque de problèmes au niveau soft (DB, Data, OS, ...) principalement de corruption ou perte de données pouvant résulter à un non démarrage de l'OS. Mais là aussi, en plus de 20 ans d'informatique, et j'en ai fait des arrêts pas "propre" et même là les problèmes se comptent sur les doits d'une main (je ne ne suis même pas sur que la vrai cause provienne de l'arrêt brutal).
  15. Voici mon avis perso, j'ai dépensé de l'argent pour rien dans ce capteur : il n'a jamais vraiment bien fonctionné comparé à l'oeil (FGMS) de fibaro capteur de mouvement non réactif, je m'explique, il faut 5 à 10 minute pour remonter un "breach", bien qu'il soit branché sur USB et que j'aie configuré la sensibilité au maximum (level 5) du paramètre 4, que le paramètre 3 soit à 10s et que le paramètre 111 à 30s. UV toujours a 0 meme en plein soleil au plein milieu de l'été! Luminosité bof, un FGMS m'indique 19lux et le multisensor lui 5lux au meme endroit. Si je lui projette un même faissceau de lumière (un tube avec la même source lumineuse) résultat 564lux pour le Multi6 et 996lux (+- 20lux) pour mes différents FGMS. Température fausse et impossible de calibrer la valeur avec la paramètre 201 Humidité 10% inférieure à ce qu'indique mes netatmo et également impossible de calibrer la valeur avec le paramètre 202 pour mettre à jour le firmware, il faut un stick Z-wave USB de AEON labs à 40€ lorsqu'il était sur batteries (2 x CR123A), elles se vidaient au bout de 4 semaines! (bien que j'avais optimisé le Multi6 au niveau reporting et wakeup pour ne pas remonter trop souvent les données au controlleur). C'est domage car au niveau spec il me semblait bon, raison pour laquelle je l'avais acheté l'été passé. Soit j'ai la poisse (ce qui est fortement possible) et j'ai eu un Multisensor6 défectueux, soit c'est vraiment de la mmm. Ce qui est sur c'est que AEONLABS c'est fini pour moi.
×