Lazer

Ca m'a l'air pas mal. Par contre il utilise ESXi 5.5, je te conseille la 5.1. Au pire plus tard tu feras la migration 5.1 vers 5.5 sans souci, mais d'ici à ce que t'en aies besoin, de l'eau aura coulée sur les ponts. Ah et aussi il utilises Xpenology Gnoboot, qui n'est pas la toute dernière, car je crois qu'on ne peut pas installer les dernières mises à jour. Il faut partir sur Nanoboot, mais je n'ai pas encore testé ça... Regardes là : http://cyanlabs.co.uk/tutorials/synology-dsm-4482-gnoboot-to-nanoboot Si tu veux un tuto en français pour ESXi, tu peux suivre celui que j'ai donné sur le site de l'informatique beaujolaise (quel drôle de nom...)

Voici quelques résultats de mes recherches sur les Main Loop d'un périphérique virtuel, en espérant que ça puisse aider les développeur de super modules. Le code LUA d'une Main Loop tourne en boucle avec un sleep de 3s. Si la main loop bouffe trop de ressources (allocation de variables locales à répétition), la HC2 finit par tuer le processus, et on est obligé de relancer la main loop en sauvegardant à nouveau le Virtual Device. Une solution a été trouvée par Krikroff, en gros, le principe est de créer une fonction et d'appeler celle-ci à chaque boucle, afin de ne pas ré-allouer les variables à chaque passage. Il faut s'inspirer de ses Virtual Device pour comprendre (genre Update Notifier). Malgré cela j'ai découvert que le module Update Notifier est affecté par un bug qui finit par arriver au but de plusieurs jours (en fonction de la fréquence de rafraichissement). C'est la fonction Net.FHttp() qui est responsable, car trop gourmande en ressources. Démonstration : Dans un premier temps, on crée une main loop toute simple, avec des lignes de codes qui s’enchainent, un un fibaro:sleep() à la fin, sachant que le temps d'attente total fera 3 secondes de plus, car le code interne de la HC2 effectue automatiquement un sleep de 3s : -------------------------------------------------- -- Exemple de Main loop -------------------------------------------------- -- System variables local selfID = fibaro:getSelfId() local ip = fibaro:get(fibaro:getSelfId(), 'IPAddress') local port = fibaro:get(fibaro:getSelfId(), 'TCPPort') local Web = Net.FHttp(ip, port) -- Main code local payload = "/url/a/appeler?avec&des&parametres" response, status, errorCode = self.Web:GET(payload) if tonumber(status) == 200 and tonumber(errorCode) == 0 then if (response ~= nil) then -- Actions à effectuer -- ... else fibaro:debug('Error : Can not connect to Web server, empty response') end else fibaro:debug('Error : Can not connect to Web server, status='..status..', errorCode='..errorCode) end -- Wait 60s fibaro:sleep(60*1000) Normalement, cette main loop sera tuée au bout de quelques heures, car les variables ne sont pas libérées, et surtout réallouées à chaque passage dans la boucle, donc on fini par dépasser une limite de mémoire utilisée. Dans un second temps, on applique la recette de Krikroff, en créant une sorte d'objet qui est défini une seule fois. Cet objet contient des variables (elles sont également définies une seule fois), et une ou plusieurs fonctions. La fonction principale est appelée à chaque passage dans la boucle : -------------------------------------------------- -- Exemple de Main loop -------------------------------------------------- if (MyObject == nil) then MyObject = { -- System variables ip = fibaro:get(fibaro:getSelfId(), 'IPAddress'), port = fibaro:get(fibaro:getSelfId(), 'TCPPort'), -- Main code main = function(self) local Web = Net.FHttp(self.ip, self.port) local payload = "/url/a/appeler?avec&des&parametres" response, status, errorCode = Web:GET(payload) if tonumber(status) == 200 and tonumber(errorCode) == 0 then if (response ~= nil) then -- Actions à effectuer -- ... else fibaro:debug('Error : Can not connect to Web server, empty response') end else fibaro:debug('Error : Can not connect to Web server, status='..status..', errorCode='..errorCode) end -- Wait 60s fibaro:sleep(60*1000) end } fibaro:debug("Function successfully loaded in memory") end -- Start MyObject:main(); Malgré tout, on finira par arriver à une situation où la boucle n'est pas tuée, mais la fonction Net.FHttp() renvoie les valeurs errorCode=<vide> et errorCode=2. C'est en tout cas ce que j'ai constaté sur le module Update Notifier, et sur mes propres essais. Donc il semblerait qu'encore une fois, bien que la variable Web soit située dans la fonction main(), la mémoire ne soit pas correctement libérée. Pour finir, en 3ème étape je pense avoir trouvé une solution stable, qui tourne depuis une 15zaine de jours chez moi, avec un passage dans la boucle toutes les 60 secondes, donc assez intensif. L'idée est de définir la variable Web une seule fois, et non plus dans le code de la fonction : -------------------------------------------------- -- Exemple de Main loop -------------------------------------------------- if (MyObject == nil) then MyObject = { -- System variables Web = Net.FHttp(fibaro:get(fibaro:getSelfId(), 'IPAddress'), 80), -- Main code main = function(self) local payload = "/url/a/appeler?avec&des&parametres" response, status, errorCode = self.Web:GET(payload) if tonumber(status) == 200 and tonumber(errorCode) == 0 then if (response ~= nil) then -- Actions à effectuer -- ... else fibaro:debug('Error : Can not connect to Web server, empty response') end else fibaro:debug('Error : Can not connect to Web server, status='..status..', errorCode='..errorCode) end -- Wait 60s fibaro:sleep(60*1000) end } fibaro:debug("Function successfully loaded in memory") end -- Start MyObject:main(); Si les experts ont un avis sur la question, je suis preneur. En attendant, j'espère que ça pourra servir. Dans tous les cas, j'espère que la v4 résoudra ces problèmes.

Après avoir bien lu toutes ces explications, je me rappelle maintenant du concept de base en programmation, qui est appelée portée des variables. Je ne crois pas avoir vu Krikroff ou Steven mentionner ce concept, mais je suis certain que vous connaissez parfaitement ça. Pourtant c'est bien de ça qu'il s'agit dans le cas présent. Finalement c'est le défaut des langages trop permissifs comme le LUA, le PHP, etc, qui permettent d'utiliser des variables sans les déclarer explicitement, avec comme conséquence des résultats imprévisibles, obligeant à mettre beaucoup de debug pour comprendre l'origine du problème. Avec des langages genre le Pascal où l'on était obligé de déclarer très précisément chaque variable, il n'y avait plus d’ambiguà¯té possible.

Pas de souci particulier depuis ce matin, avec tapatalk depuis mon ADSL Free, ou 4G Bandyou.

Arf et je ne peux pas t'aider, j'ai bien un module RGBW, mais je ne l'ai pas encore mis en service... ça fait partie des projets futurs. Je crois que Krikroff maitrise assez bien les appels d'API, tu peux tenter un message privé.

Fredo, c'est comme ça qu'on apprend, en cherchant soi-même Je viens de faire un test de perf de copie réseau rien que pour toi Source : HP Proliant N54L avec Xpenology dans une VM, lecture sur 1 disque Western Digital RED 4 To Réseau : 1 Gbit/s, traversée de 2 switchs (celui de la Freebox, et un Netgear) => Copie de fichiers MKV via un partage Windows CIFS Destination : Core i7, RAM 6Go, SSD (donc clairement ce n'est pas ce PC qui limite les perfs). Débit moyen de 91 Mo/s. D'après les graphs de performances de vSphere Client et de Xpenology, le disque dur était occupé à 65%, et le CPU à 30% (pointe à 50%) donc je pense avoir saturé le réseau (pour rappel 1 Gb/s = 100 Mo/s) A noter qu'en Benchmark sous Linux, j'ai atteind les perfs théoriques du disque, j'ai mesuré 140 Mo/s en début de disque (là où c'est le plus rapide). Donc même avec virtualisation, en mappant les disques en RDM, les perfs sont plus que correctes Si tu ne crées pas d'autre VM (genre Sarah), as-tu vraiment besoin de virtualisation ? Je ne peux pas trop répondre à ta place. Pour le serveur Web PHP MySQL & co, tout ça est intégré à DSM, donc ton Xpenology pourra faire tout ce qu'un Synology sais faire, virtualisation ou pas. Tu peux effectivement utiliser le lecteur DVD dans tous les cas, BIOS modifié ou pas. Mais euh, comment dire, y'a encore des gens qui utilisent des galettes de 12cm en 2014 ???

Ah sauvé Fredric, après avoir grillé, on a cru que tu t'étais pendu

En fait la Main Loop tourne en boucle avec un sleep de 3s. Si la main loop bouffe trop de ressources, la HC2 finit par tuer le processus, et on est obligé de relancer la main loop en sauvegardant à nouveau le VD. La solution est donnée par Krikroff, il faut s'inspirer de ses VD pour comprendre (genre Update Notifier) En gros, le principe est de créer une fonction et d'appeler celle-ci à chaque boucle, afin de ne pas ré-allouer les variables à chaque passage. En me basant sur ça, j'ai créé une main loop qui tourne depuis 15 jours sans pb, et pourtant elle fait des appels Net.FHTTP() toutes les 60 secondes. D'ailleurs faut que je partage ça dans le sujet qui va bien (c'est une évolution du module pour Surveillance Station)

Yop yop, me revoilà L'espèce de RAID propriétaire, appelé SHR par Synology, est en fait tout ce qu'il y a de plus standard sous n'importe quel Linux. Ce sont des partitions ext4, créées par dessus des Logical Volume du LVM, eux-même créés par dessus un RAID logiciel mdadm. C'est un bel empilement de technos, mais en fait tu peux prendre les disques et les mettre sur n'importe quel Linux pour relire les données, même en intervertissant tous les disques sur les différents ports SATA. Le seul truc est de ne pas oublier un disque dans la bataille, car les données sont réparties sur tous les disques. Donc, en utilisant RDM, on peut facilement passer d'un Xpenology natif à un Xpenology dans une VM. L'inverse est aussi vrai. Rappel : le Raw Device Mapping sous VMware consiste à mapper un disque entier à une VM, de sorte à ce que l'hyperviseur ESXi soit complètement transparent. En poussant plus loin le raisonnement, on peut prendre les disques d'un vrai Synology, et les mettre dans un serveur avec Xpenology pour retrouver toutes les données. L'inverse (Xpenology vers Synology) fonctionne également. Evidemment, il n'y a aucun support officiel pour toutes ces manipulations, donc c'est assez flippant de jouer avec ses données, pour cette raison une sauvegarde des données importantes est vitale. Perso, j'ai fait le choix de ne pas utiliser de SHR, et d'utiliser des "volumes simples", c'est à dire qu'il n'y a pas de protection RAID logiciel SHR. Voici ma réflexion personnelle sur le RAID. En général j'ai une pensée à contre-courant du discours de Synology, et des utilisateurs sur les forums en général. Pour situer le contexte, je suis consultant système stockage et sauvegarde, donc je pense connaitre un peu le sujet. Je travaille sur des baies SAN de plusieurs dizaines/centaines de disques, évidemment protégées en RAID matériel, et surtout sauvegardés sur un autre support (disque, cartouches magnétiques, évidemment ces dernières sont dupliquées et stockées hors site). Des disques qui lâchent, j'en vois tous les jours ou presque. Des RAID qui lâchent, j'en vois de temps en temps. C'est là que les sauvegardes entrent en jeu ! Et quand bien même le matos ne tombe pas en panne, c'est l'utilisateur qui fait une fausse manip et perd ses données. Là encore, la sauvegarde est la solution. Je suis surement victime de déformation professionnelle dans mes propos sur la sécurité des données, mais quand je vois de nombreux témoignage sur les forums de gens qui ont perdues leurs données, même protégées par du RAID, je me dis que j'ai bien raison. A noter que contrairement aux idées reçues le RAIS matériel n'est pas plus sécurisant que le RAID logiciel, il est simplement plus performant. Le RAID n'apporte pas de sécurité, mais de la continuité de service, c'est à dire qu'en cas de perte d'un disque, tu continues à travailler pendant que le RAID se reconstruit sur un autre disque. C'est nécessaire en entreprise, beaucoup moins à la maison. Si tu as des données importantes, il faut faire des sauvegardes sur support de stockage externe. Quant à la fiabilité du SHR, si tu regardes les discours de Syno, ça a l'air génial. Quand tu traines sur le forum officiel, tu trouves plus de gens qui ont perdu leurs données à cause d'un problème dans SHR (corruption suite à reboot violent, etc...) que à cause d'une panne matérielle de disque. Donc perso, le SHR ne passe pas par moi. Je fais des volumes simples, et les données importantes sont répliquées entre 2 disques, et surtout sauvegardées sur disque externe. Ces disques externes sont stockés dans un bâtiment différent de ma maison (ici mon garage, mais ça pourrait aussi être chez des amis/famille, ou au bureau). Je considère que les cartouches magnétiques ne sont pas rentables pour une utilisation personnelle comparée au coà»t au Go des disques durs. A terme, j'installerai un second serveur dans le garage, et les données importantes seront répliquées toutes les nuits entre les 2 serveurs. La sauvegarde sur disque externe sera bien sà»r maintenue. A noter que dans mon PC principal, j'ai une carte RAID matérielle, avec des disques durs adaptés au fonctionnent en RAID, car j'ai besoin de performance (utilisation retouche photo, et occasionnellement montage vidéo). Évidemment je sauvegarde sur disque externe. Si malgré tout tu fais du SHR, il faut commencer par les plus petits disques, pour ensuite étendre le volume avec des plus gros disques. L'inverse n'est pas possible. Un simulateur est disponible ici : http://www.synology.com/fr-fr/support/RAID_calculator Le SHR a quand même un gros avantage, c'est que ça permet de créer un gros volume virtuel, qui occupe tout l'espace de tous les disques durs (moins l'espace utilisé pour la sécurité). Donc pour une grosse médiathèque de films, c'est plus pratique que d'avoir plusieurs partages réseaux. Mais avec XBMC cet argument tombe à l'eau, car les médiathèques (films, séries, musiques, ...) permettent d'agréger plusieurs sources de façon invisible dans l'interface utilisateur. Fredo, ta procédure est bonne. Tu peux démarrer avec 2 Go de RAM, en utilisant ESXi 5.1 (qui prend environ 512 Mo de RAM, donc tu auras 1,5 Go pour la VM Xpenology ce qui est déjà confortable). J'ai tourné comme ça pendant 1 semaine en attendant de recevoir ma RAM. Evite ESXi 5.5 qui utilise plus de RAM et ne t'apportera pas de fonctionnalités utiles. Pour ESXi, il me semble qu'une clé de 1 Go doit suffire. Avec 2 Go c'est sur ça passe (j'ai testé en premier une veille clé promotionnelle de 2 Go toute lente, avant d'acheter une petite Sandisk de 4 Go pour quelques euros sur Amazon). En fait les performances de la clé importent peu, car au boot, une fois chargé en mémoire ESXi ne fait plus aucun accès à la clé, puisque tout se passe sur le Datastore (le disque de 250 Go est un candidat idéal pour commencer). Je te conseille de modifier le BIOS, ça prend 5 minutes et t'es tranquille pour l'avenir. Au moins t'es certain de pouvoir tirer le max de ton serveur quoi qu'il arrive. Quant à savoir si c'est nécessaire de mettre 2 HDD à la place du lecteur CD, c'est à toit de voir en fonction de tes besoins. Pour le moment je n'ai que 3 disques durs en tout dans mon serveur, mine de rien avec les 4 To on en stocke des données. Je rappelle quand même que la virtualisation ralentie les performances, donc à faire si vraiment tu souhaites mettre en place d'autres VM dans le futur (Windows Server pour Sarah, etc..)

Fait attention aux sondes de températures, si elles sont dans la même boite d'encastrement que le détecteur de mouvement et le module Fibaro, à seulement 90cm de hauteur par rapport au sol, tu auras des mesures faussées. Normalement pour une mesure précise, c'est à 1,5m de hauteur, et sur un mur intérieur, avec une grille pour une bonne prise d'air ambiante, et surtout pas un module derrière qui va chauffer en permanence (même 1W, c'est de la chaleur, surtout si elle n'a aucun moyen de s'évacuer). Perso, pour mes sondes 1-Wire dans les chambres, il n'y a que la sonde dans chaque boite d'encastrement, et j'ai des câbles de paires torsadées qui remontent dans la gaine jusqu'au grenier, là où j'ai mis mon Fibaro Universel, qui peut gérer à lui tout seul 4 sondes. Il faut faire attention à bien boucher la gaine sinon un courant d'air froid descend dans la gaine et fausse la mesure.

Juste un truc comme ça, tout ce qui est électrique doit obligatoirement être accessible selon la norme NFC machin-chose. Donc j'espère que tu as une trappe d'accès dans le faux plafond, avec les boites de dérivation qui sont àcoté.

Tu installes Xpenology sur la clé USB et tes 2 Go de RAM. En fait, c'est juste le Synoboot qui va sur la clé, un petit bout de code qui fait croire à DSM que tu as un vrai Synology. Ensuite, l'installation de DSM se fait sur tous les disques durs dans une petite partition dédiée. Ainsi, en cas de perte de l'un des disques, DSM peut toujours démarrer car il est stocké partout. Le jour où tu veux virtualiser avec ESXi, tu retires la clé USB, et tu installes ESXi sur une nouvelle clé USB. Tu démarre ESXi, tu crée un datastore sur un disque qui ne contient surtout pas de données provenant de Xpenology. Tu crée une première VM pour Xpenology, et tu lui affecte tous les disques que tu avais avant en mode RDM. Tu crée un disque virtuel sur ton datastore de 32Mo qui contient le synoboot (comme celui qui se trouvait sur l'ancienne clé USB). Tu démarres ta VM, et tu retrouves ton DSM, avec ta config et toutes tes données. Ca parait complexe, mais je pourrais t'assister le jour où tu voudras mettre en place la virtualisation.

Concernant ESXi, il s'agit d'un Hyperviseur, donc installé en natif sur le serveur. Au sein de celui-ci, on peut faire tourner plusieurs Virtual Machines complètement isolées les unes des autres, avec des OS différentes, des adresses IP différentes, etc... Il est gratuit pour une installation locale sur un seul poste, avec quelques limitations (pas de Cluster vSphere, 32 Go de RAM maxi, etc...) donc rien de bien méchant pour une utilisation perso. La licence gratuite est à demander sur le site de VMware. Il est conseillé d'installer ESXi sur une clé USB sur le slot interne du serveur. Un Datastore sera nécessaire, c'est à dire un disque dur (ou SSD) sur lequel seront créés les disques virtuels pour les VM. Sur le Proliant, on peut utiliser le disque de 250 Go fourni à cet effet. Les images ESXi toutes prêtes pour le Proliant N54L sont à télécharger ici : Customize VMware ESXi Images for HP ProLiant Servers Suivre ce tutoriel pour l'installation : Installer VMware vSphere ESXi 5.1 sur serveur HP ProLiant N54L et créer une VM Synology (DSM 4.2 et 4.3) avec XPenology Pour les disques de données pour Xpenology, afin d'avoir de la performance, il est conseiller de donner les disques "en entier" à la VM, en utilisant la technique du Raw Device Mapping : RDM mapping of local SATA storage for ESXi VMware Knowledge Base : Raw Device Mapping for local storage (1017530) Enfin la technique suivante permet de remonter les infos SMART des disques durs vers les VM. A noter que pour Xpenology cela ne fonctionne pas, il ne sera malgré tout pas capable de lire les infos SMART, il faut le faire manuellement via les commandes smartmontool : How To: Get SMART data passed on from ESXI 5.1 Host

Euh non désolé, je n'ai pas de lien, je n'en n'ai jamais utilisé en fait... Mais le truc aussi, c'est que les relais statiques sont plutôt utilisés en électronique, donc je ne suis pas certain que tu puisses en trouver un qui se commande en 230V. Sinon, je te dirais bien de remplacer ton relai et ton Fibaro Universel par un FGS ou FGD, qui sont alimentés en 230V et pourront être commandés directement pas le détecteur de mouvement, quitte à ne pas utiliser la sortie car tu vas faire une scène pour piloter ton module RGBW. C'est ce que j'ai fait ici : http://www.domotique-fibaro.fr/index.php/topic/171-fibaro-module-dimmer-fgd-211/?p=10170

Envoie un mail à l'adresse support@fibaro.com avec ton pseudo pour qu'ils débloquent ton compte sur le forum officiel. Source : http://www.domotique-fibaro.fr/index.php/topic/549-forum-officiel-fibaro/

Merci pour le partage Pour un relai silencieux, il faut que tu cherches un relai statique qui n'a pas de partie mécanique en mouvement.

Oui en effet. Je suppose que làles interrupteurs sont simplement démontés pour que le peintre puisse travailler tranquille, avec le module planqué derrière un scotch au fond de la boite d'encastrement. En tout cas c'est comme ça que je fait quand je repeint une pièce.

Même pas besoin d'interrupteur, si tu veux forcer l'état Always ON, tu fait un pontage avec un fil entre la phase et l'entée S1 afin de simuler un interrupteur fermé. Et avec le paramètre 14 en mode bi-stable.

J'ai reçu le FGRM-222. Au début j'ai cru qu'il était cramé, car un relai restait collé en position de travail en permanence, si bien que la sortie O1 était tout le temps alimenté. Bref ça commence mal. Je l'ai débranché, tapoté pour tenter de "décoller" la lame du relai, et effectivement maintenant le module fonctionne. Très étrange.... si ça reproduit, il repartira en garantie. Du coup j'ai quand même pu faire quelques tests après cet incident. Mais je viens de m'apercevoir que les relais que j'ai en stock sont pilotés en 24V DC, c'est dommage je vais devoir en commander des versions 230V AC pour mon montage. Donc j'ai testé le montage sans relai, c'est à dire en branchant alternativement les alims 24V sur les 2 sorties du FGRM, et le volet roulant Velux monte et descend. Évidemment pas de calibration dans ce mode de fonctionnement, je vais devoir attendre les nouveaux relais. A suivre...

En effet, c'est rapide en ce moment, si tu n'as touché àrien dans les bases, c'est que l'hébergeur doit avoir des faiblesses par moment.

Tu as 2 emplacements pour barrettes RAM. Une seule barrette de 2 Go est fournie, de type ECC (avec correction d'erreur, couramment utilisée dans les serveurs). Rien n'est soudé (enfin si, le CPU est soudé, mais ce n'est pas de la mémoire.). Pour étendre la capacité, tu dois ajouter le même type de barrette, donc de la ECC, par exemple une autre barrette ECC 2Go de la même taille qui provient du serveur de quelqu'un d'autre (la mienne ne me sert plus à rien, je peux la vendre, mais je n'ai jamais fait l'effort, surtout vu le faible prix de vente). OU ALORS, tu remplaces la barrette fournie par des barrettes normales, les mêmes qu'on a dans nos PC. Officiellement, le Proliant ne supporte que 8 Go (donc un kit de 2 x 4 Go), mais sur les liens tu trouveras plein de kits 16 Go (2 x 8 Go) qui fonctionnent. Moi j'ai pris un kit Kingston KHX16C10B1BK2/16X. Absolument aucun problème avec depuis le mois de janvier 2014. Et dans ce cas là , tu auras une barrette 2Go ECC à revendre (ou à conserver en spare au cas où...) Je crois l'avoir déjà dis, pour Xpenology uniquement, il n'y a pas besoin de plus de 2 Go de RAM. Pour la virtualisation, la RAM est nécessaire. Je ferai un autre post plus tard pour ESXi avec les explications et les liens qui vont bien.

OK si ça t'intéresse, je te balance plein de liens pour ESXi tout àl'heure. C'est gratuit et il faut l'installer en premier.

Non j'ai d'autres VM, du Linux pour jouer (façon de parler), et àterme je compte mettre des logiciels pro pour me faire un banc de test/démo/training : TSM, TPC, GPFS, etc...

Oui, apparemment Sarah a des gouts de luxe (c'est une femme ), un Intel Core semble conseillé. Un Intel Nuc est tout indiqué. Autrement, tu te montes ta config à base de carte mère mini-ITX, un bon petit CPU dessus, de la RAM, un petit boitier genre Lian-Li qui peut contenir quelques disques, et de la virtualisation avec WMware ESXi. Là tu pourras tout faire avec une seule machine, mais le prix va grimper très vite et tu seras loin du prix plancher du HP Proliant. A noter que le HP G7 N54L a un successeur, le G8, auquel on peut remplacer le Celeron par un Xeon, et là ça commencer à tabasser.... bon le prix par contre

Hum, en fait tu veux faire beaucoup de choses : - un Serveur NAS pour héberger tes données - un serveur Sarah pour parler à ta maison - un Media Center pour lire des films sur la TV - ... ??? Clairement, le mieux c'est toujours de séparer les fonctions sur des machines distinctes. Maintenant avec la virtualisation tu peux tout faire fonctionner sur la même machine, mais au prix d'une complexité supérieure, et de contraintes : par exemple, si ton media center n'est pas sous la TV, comment vas-tu le contrôler ? Avec un smartphone en Wifi ? Franchement, ce n'est pas hyper pratique...